How the Patent Disclosure Skill Handles Invention, Utility Model, and Design Patents

The patent-disclosure-skill distinguishes between invention, utility model, and design patents using a three-tier inference system that normalizes user input, parses publication number kind-codes, and extracts keywords from bibliographic text.

The handsomestWei/patent-disclosure-skill repository centralizes patent type logic in a dedicated module shared across skills. Located at skills/patent-disclosure/tools/patent_type.py, this module defines canonical constants and implements hierarchical inference to ensure accurate type resolution for downstream EPUB generation and Google Patents search queries.

Canonical Type Definitions in patent_type.py

The module establishes four internal constants to standardize type representation throughout the codebase. These definitions appear at lines 12-15 in skills/patent-disclosure/tools/patent_type.py:

• TYPE_INVENTION = "invention"
• TYPE_UTILITY_MODEL = "utility_model"
• TYPE_DESIGN = "design"
• TYPE_ALL = "all"

These canonical strings serve as the single source of truth for type classification, ensuring consistency across the patent disclosure and patent reader skills.

Normalizing User Input with normalize_patent_type()

Before inference begins, the normalize_patent_type() function maps user-provided strings to canonical constants. This function handles multilingual input including English variants, Chinese terms, and common aliases through the _ALIASES dictionary defined at lines 65-79.

If the input string is empty or unrecognized, the system falls back to TYPE_ALL, ensuring the pipeline continues processing without failure. This normalization step standardizes inputs from CLI arguments, web forms, or bibliographic databases before the inference hierarchy executes.

Three-Tier Patent Type Inference Hierarchy

The resolve_reader_patent_type() function implements a priority-based decision tree. It evaluates three distinct data sources in sequence, returning a dictionary containing the canonical patent_type, Chinese label_zh, decision source, cleaned pub number, and confidence level (high, medium, or none).

Priority 1: User-Declared Types

When a user explicitly specifies a type via the --declared parameter, the system normalizes the input and returns it with high confidence. This bypasses automated inference entirely, giving operators direct control over classification when the source material is ambiguous or the input is already validated.

Priority 2: Publication Number Kind Codes

If no user declaration exists, infer_patent_type_from_pub() examines the publication number for trailing kind-letters. Implemented at lines 92-90, this function parses Chinese patent numbers like CN209861402U to extract:

• A/B/C → TYPE_INVENTION
• U/Y → TYPE_UTILITY_MODEL
• S → TYPE_DESIGN

Matches from kind-code parsing receive high confidence due to the standardized nature of patent numbering systems.

Priority 3: Bibliographic Text Analysis

When publication numbers lack kind-codes or are unavailable, infer_patent_type_from_biblio() scans bibliographic text for keywords. Lines 32-43 implement matching logic for terms like "外观设计" (design), "实用新型" (utility model), and "发明专利" (invention), including their English equivalents.

Detection via text analysis yields medium confidence, as it relies on natural language processing rather than structured metadata. If no keywords match, the function returns None with confidence set to none.

Downstream Utilities: EPUB Checkboxes and Google Patents Queries

Once resolved, patent types drive specialized formatting utilities. The epub_checkbox_states(patent_type) function (lines 6-8) converts types into the specific checkbox combinations required by the Chinese CNIPA e-publication form, ensuring compliance with official submission standards.

For web search integration, google_patents_websearch_query() constructs type-specific search strings. The function at lines 20-41 appends qualifiers like type:PATENT for invention and utility model searches, or type:DESIGN for design patents, while optionally incorporating CPC classification codes to narrow results.

Practical Implementation Examples

The following examples demonstrate the type resolution pipeline using the actual module API:

# Example 1: Explicit user declaration (high confidence)

from skills.patent_disclosure.tools.patent_type import resolve_reader_patent_type

result = resolve_reader_patent_type(user_declared="实用新型")

# → {'patent_type': 'utility_model', 'label_zh': '实用新型',

#    'source': 'user_declared', 'pub': None, 'confidence': 'high'}

# Example 2: Inference from Chinese publication number (high confidence)

result = resolve_reader_patent_type(pub="CN209861402U")

# → {'patent_type': 'utility_model', 'label_zh': '实用新型',

#    'source': 'pub_kind_code', 'pub': 'CN209861402U', 'confidence': 'high'}

# Example 3: Inference from bibliography text (medium confidence)

biblio = "本发明涉及一种外观设计专利"
result = resolve_reader_patent_type(biblio_text=biblio)

# → {'patent_type': 'design', 'label_zh': '外观设计',

#    'source': 'biblio_text', 'pub': None, 'confidence': 'medium'}

# Example 4: Building a Google Patents query for a design patent

from skills.patent_disclosure.tools.patent_type import google_patents_websearch_query

query = google_patents_websearch_query(
    keywords="LED灯具",
    patent_type="design",
    class_codes=["D05C 47/16"]
)

# → "LED灯具 country:CN D05C47/16"

Summary

• The patent type resolution system lives in skills/patent-disclosure/tools/patent_type.py and uses four canonical constants to represent invention, utility model, design, and "all" types.
• Input normalization via normalize_patent_type() handles multilingual aliases and defaults to TYPE_ALL when input is missing.
• Three-tier inference prioritizes user declarations (high confidence), then publication number kind-codes (high confidence), then bibliographic text keywords (medium confidence).
• Specialized utilities convert resolved types into CNIPA EPUB checkbox states and Google Patents search queries with appropriate type filters.

Frequently Asked Questions

How does the skill handle ambiguous or missing patent type information?

When type information is ambiguous or omitted, the system cascades through the inference hierarchy. If no user declaration, valid kind-code, or bibliographic keyword is found, resolve_reader_patent_type() returns None for the patent type with confidence set to none. This explicit null handling prevents false positives while allowing downstream components to apply default behaviors or prompt for clarification.

What publication number formats are supported for automatic type detection?

The infer_patent_type_from_pub() function specifically targets Chinese patent numbers following the CNIPA format, such as CN209861402U or CN306012345S. It extracts trailing kind-letters where A, B, or C indicate invention patents, U or Y indicate utility models, and S indicates design patents. The parser cleans the input before extraction, removing whitespace and standardizing delimiters.

Can the patent type module handle English and Chinese input interchangeably?

Yes, the normalize_patent_type() function accepts multilingual input through the _ALIASES dictionary mapping. It recognizes English terms like "invention", "utility", and "design" alongside Chinese equivalents such as "发明", "实用新型", and "外观设计". This bidirectional support enables the skill to process both domestic Chinese patent data and international search queries without requiring pre-translation.

How does the system integrate with CNIPA e-publication forms?

The epub_checkbox_states(patent_type) utility translates canonical types into the specific checkbox identifiers required by CNIPA electronic filing systems. By calling this function with a resolved type (invention, utility model, or design), the skill generates the correct binary state configuration for automated form filling, ensuring regulatory compliance during the disclosure submission process.

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