Patent Search Query Builder

Problem

Patent search often stalls when converting a technical solution into a database query. Engineers and patent practitioners may have a clear natural-language description, but still need to manually decompose keywords, synonyms, classification codes, and Boolean relationships, then adapt them to each platform's syntax. Novelty, invalidity, and FTO searches require different query topologies; missing competitor name variants or misusing broader/narrower terms can produce too many results, heavy noise, or missed key references.

How It Works

The skill compiles inputs into a structured search query through a staged pipeline:
- S1 Technical decomposition: extracts the technical field, problem, and searchable atomic elements from the description, then labels core/required/supporting features and their parallel, dependent, or alternative relationships.
- S2 Keyword expansion: generates synonyms, broader/narrower terms, morphological variants, IPC/CPC codes, and competitor name variants such as full names, abbreviations, subsidiaries, and truncations.
- S3 Query construction: combines intra-element variants with OR, constrains inter-element relationships with AND/NOT, selects topology for novelty, invalidity, or FTO, and formats the query for Patsnap, EPO, USPTO, Lens, and similar platforms.
- S5 Optimization: applies tightening or broadening adjustments based on result volume, noise, missed hits, or intent changes, and records version differences.

Boundaries

It is suitable for drafting and iterating queries when the solution, intent, and target platform are defined. It does not judge inventive height, nor does it guarantee completeness of competitor lists. When the innovation point is vague or broader/narrower relationships are uncertain, it flags the uncertainty and asks for confirmation; key applicants should still be validated separately for database name entry formats.