How the Patent-Disclosure-Skill System Handles Invention, Utility Model, and Design Patent Types

The system centralizes patent-type handling in a canonical parser at tools/shared/patent_type.py, defaults to "invention" when unspecified, and routes each type through distinct templates, schemas, and search behaviors.

The handsomestWei/patent-disclosure-skill repository automates the creation of patent disclosure documents for the Chinese patent system. To accommodate the three distinct categories recognized by the CNIPA (China National Intellectual Property Administration)—invention, utility model, and design—the codebase implements a type-aware pipeline that normalizes input, selects appropriate generation schemas, and organizes outputs accordingly.

Centralized Type Definition and Validation

All patent-type logic originates in tools/shared/patent_type.py. This module defines the authoritative list of supported categories and provides a strict normalization function used across the entire application.

The CANONICAL_TYPES list establishes the single source of truth:

# tools/shared/patent_type.py

CANONICAL_TYPES = ["invention", "utility_model", "design"]

def parse_type(raw: str) -> str:
    """Return a canonical patent type or raise ValueError."""
    raw = raw.strip().lower()
    if raw in ("inv", "invention"):
        return "invention"
    if raw in ("um", "utility", "utility_model"):
        return "utility_model"
    if raw in ("design", "appearance"):
        return "design"
    raise ValueError(
        f"unknown patent type {raw!r}; use one of {', '.join(CANONICAL_TYPES)}"
    )

Downstream modules import parse_type to enforce consistency. The function accepts common aliases—such as "inv" for invention or "um" for utility model—ensuring user-friendly input while maintaining internal type safety.

Type-Specific Processing Pipeline

The system adapts its document generation strategy based on the resolved patent type, using distinct templates and visualization approaches for each category.

Defaulting to Invention Patents

When users invoke the skill without explicitly specifying a type, the system assumes invention as the default. This behavior is implemented in the main entry point and the disclosure builder, ensuring that the most common patent category requires minimal configuration.

Template Selection and Content Generation

Each patent type triggers a specific template and schema workflow:

• Invention: Uses mermaid flow-charts for method and system descriptions, focusing on technical solutions and process flows.
• Utility Model: Prioritizes structural claims by first generating a figure_plan schema, then producing structural line-art representations.
• Design: Centers on appearance patents, generating design drawings and line-art focused on aesthetic characteristics rather than functional mechanics.

The template routing logic typically follows this pattern:

from tools.shared.patent_type import parse_type
from pathlib import Path

def build_disclosure(user_input: str, material_path: Path):
    p_type = parse_type(user_input)               # Normalizes to "utility_model"

    if p_type == "invention":
        template = "templates/invention.md"
    elif p_type == "utility_model":
        template = "templates/utility_model.md"
    else:  # design

        template = "templates/design.md"
    
    # Render type-specific disclosure document

Prior-Art Search Integration

The CNIPA EPub crawler (tools/crawl/cnipa_epub_search.py) accepts a --type flag that aligns search scope with the selected patent category. This ensures that prior-art searches query the appropriate publication databases:

• Invention searches cover "发明公布" and "发明授权" (invention publications and grants)
• Utility model searches target "实用新型" (utility model) publications
• Design searches focus on "外观设计" (design) databases

Example usage:

python -m tools.crawl.cnipa_epub_search \
    --type utility_model \
    --query "电动车桥"

The crawler documentation references tools/shared/patent_type.py for accepted type values, maintaining consistency across the CLI interface.

Schema-Driven Figure Planning

For utility model and design patents, the system generates a structured figure plan before creating the final disclosure. The schema definition in references/schemas/figure_plan.schema.yaml enforces type-aware validation:

# references/schemas/figure_plan.schema.yaml (excerpt)

type: object
properties:
  patent_type:
    enum: [invention, utility_model, design]
  figures:
    type: array
    items:
      $ref: "#/definitions/figure"
required: [patent_type, figures]

This schema drives the ordering of images and component numbering in the final output. The tools/patent_reader/vault/write_patent_obsidian_note.py module consumes these schema instances to render properly structured technical drawings and component lists.

Vault Organization and Output Structure

When configured to use an Obsidian vault (PATENT_READER_OBSIDIAN_VAULT), the system organizes generated notes into type-specific subdirectories. The directory layout defined in assets/obsidian/patents.base.yaml preserves distinct folder structures for each patent kind, preventing overlap between invention disclosures, utility model specifications, and design documentation.

Summary

• Canonical types are defined in tools/shared/patent_type.py with strict parsing via parse_type().
• Invention is the default type when users provide no explicit input.
• Type-specific templates handle distinct visualization needs: mermaid charts for inventions, structural plans for utility models, and appearance drawings for designs.
• Prior-art searches use the --type flag to query relevant CNIPA publication databases.
• Figure planning schemas enforce structured component numbering for utility models and designs.
• Obsidian integration stores outputs in type-specific folders to maintain organizational clarity.

Frequently Asked Questions

What happens if I don't specify a patent type?

The system defaults to invention patents. This behavior is hardcoded in the main skill entry point and the disclosure builder modules, ensuring that the most common patent category is assumed when no type parameter is provided.

How does the system normalize user input for patent types?

The parse_type() function in tools/shared/patent_type.py normalizes input by converting to lowercase and mapping common aliases—such as "inv", "um", or "appearance"—to canonical values. If the input matches none of the recognized aliases, the function raises a ValueError listing the valid options.

Where are the generated patent disclosures stored?

When using the Obsidian vault integration (PATENT_READER_OBSIDIAN_VAULT), disclosures are stored in type-specific subdirectories as defined in assets/obsidian/patents.base.yaml. This separation ensures that invention, utility model, and design documents remain organized in distinct folder structures within the vault.

Does the system support automatic patent type detection?

According to the interaction flow in SKILL.md and prompt templates under prompts/reader/type_hooks.md, the system can suggest appropriate types based on scanned project materials. For example, CAD-heavy projects may trigger recommendations to use utility model or design categories, though the final type selection requires user confirmation.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}