search-applicant-technology-patents-ip

Search applicant technology patents

Build an auditable applicant-first patent search constrained to a confirmed technology topic. Preserve the applicant universe, topic logic, query provenance, deduplication levels, representative selection, and handoff artifacts.

Read both references before drafting formulas or executing retrieval:

• Applicant-topic patent retrieval workflow
• Topic limitation workflow

Read README.md before using live PatSnap data.

Execution modes

Choose one mode and state it in Step 0:

Default to formula_only_mode until the user asks for executed retrieval or datasets.

Non-negotiable formula firewall

The first substantive response must show Steps 0–7. Stop after Step 7 and request confirmation unless the user explicitly asks for a full draft including formulas.

Never output ANCS, TA_ALL, APPLICANT_TOTAL, APPLICANT_TOPIC_FINAL, a formal search strategy, an executable query, a count, or retrieval results before the visible pre-retrieval package is complete.

Use this fixed order:

Step 0: Original request and execution mode
Step 1: Applicant entity expansion table
Step 2: Technology topic definition
Step 3: Topic boundary confirmation table
Step 4: Technology topic decomposition table
Step 5: Search element matrix
Step 6: Noise and exclusion boundary table
Step 7: Gate status before search
Step 8: Search strategy and formulas

Step 8 is allowed only when all Step 0–7 gates are Pass or, in an explicitly requested full draft, Pending user confirmation. Any Fail is a hard stop.

Fixed meaning of each step

The following structures are invalid:

• Step 2: Solid-state battery keyword matrix; the keyword matrix belongs to Step 5.
• Step 2: Technology topic keyword expansion; Step 2 is a narrative definition.
• Step 3: IPC classification mapping; classifications belong to Step 5 or support Step 8.
• Step 3: Formal search strategy; Step 3 is the boundary table.
• Step 4: Final search formulas; formulas cannot begin before Step 8.

Invalid output:

Step 3: Formal search strategy
Applicant expression: ANCS:(...)
Topic expression: TA_ALL=(...)
Combined query: ANCS:(...) AND TA_ALL=(...)

It remains invalid even if introduced with “based on the analysis above” when the visible Step 0–7 package is missing.

Invalid output:

Step 2: Solid-state battery keyword matrix
TA_ALL=(...)
Step 3: Combined query
ANCS:(...) AND TA_ALL=(...)

Step 2 must define the topic and Step 3 must confirm its boundary.

Invalid output:

Step 2: Technology topic keyword expansion
Step 3: IPC classification mapping
Step 4: Recommended final formulas

This order misassigns all three steps and bypasses the mandatory gate.

Minimum visible evidence before formulas

Step 0: Preserve the request and establish scope

Quote the user's original request verbatim before interpreting it. Separate:

• user-confirmed facts;
• agent inferences; and
• assumptions pending user confirmation.

Capture the target applicant or group, technology topic, jurisdiction/database coverage, date range, patent type, legal-status filters, subsidiary/acquisition scope, purpose, seeds, and deliverable mode. Ask only for missing parameters that materially change the search.

Step 1: Disambiguate and expand applicant entities

If the input is a brand, abbreviation, group name, or historical name, do not select a legal entity silently. List plausible current and historical entities, their industry, relationship, and likely search path, then request confirmation when more than one route is reasonable.

For each candidate entity, record:

Do not treat a large company or group as one applicant expression. Include evidence-supported core entities, relevant parents, R&D and manufacturing entities, historical names, acquired entities when in scope, and local-language variants. Keep uncertain relationships Pending and outside the final formula.

The entity table must exist before any applicant count, topic presearch, scale estimate, or combined retrieval.

Confirm the applicant field

Require an explicit field selection before count validation, final applicant formulas, retrieval, merging, deduplication, or report completion.

Use a colon between field and value, for example {field}:("Applicant name"). Never use = and never use the invalid field ANSC.

Before confirmation, you may preserve the request, disambiguate entities, clarify group scope, draft a pending entity table, define the topic boundary, and choose an execution mode. You may not execute or finalize a query.

Use this field-confirmation prompt when the user has not chosen a field:

Before I run or finalize the search, confirm which applicant/assignee field to use.
I recommend ANCS (normalized current applicant/assignee), but I need your explicit selection.

Available fields:
- ALL_AN: all applicant/assignee fields
- AN: original applicant/assignee
- ANC: current applicant/assignee
- ANS: normalized original applicant/assignee
- ANS_EXACT: exact normalized original applicant/assignee
- ANCS: normalized current applicant/assignee (recommended)
- ANCS_EXACT: exact normalized current applicant/assignee

Reply with the field, for example: ANCS or ANC.

Do not perform evidence-backed entity expansion, count validation, retrieval, merge, deduplication, final topic combination, or final report completion before field confirmation. You may draft a pending expansion table, but label every unverified entity and assumption.

Steps 2–7: Build the topic preflight package

Follow topic-limitation-workflow.md in full.

Step 2: Technology topic definition

Write three to five sentences explaining what the topic is, what it is not, why the boundary matters for retrieval, and which terms are broad or noisy. Mark the status Confirmed, Pending user confirmation, or Agent-inferred.

Step 3: Topic boundary confirmation

Create a table covering the core technical object, must-have features, optional or adjacent technology, explicit exclusions, ambiguous terms, rationale, retrieval impact, and confirmation status.

Step 4: Technology topic decomposition

Cover object/material/component, function/effect/problem, mechanism/process/method, application/end product, classification anchors, and exclusions/noise. Assign each branch a Core, Recall, Precision, or Noise role.

Step 5: Search element matrix

Include local-language and English terms, abbreviations, spelling variants, lower concepts, representative members, trade/common/chemical names where relevant, field scope, proximity rule, formula role, and confirmation status. Use IPC/CPC anchors when supported. Treat local-language terms as query data, not interface prose.

Use $Wn, $PREn, $SEN, or $PARA when proximity or order materially improves precision. Use IPC_LOW or CPC_LOW when parent-group recall is intended; use exact codes only when the scope requires them.

Step 6: Noise and exclusion boundary

For each proposed exclusion, record the noise source, why it is noise, terms/classes, over-exclusion risk, and confirmation status. Do not use applicant names as a substitute for topic logic.

Step 7: Gate status

Show the evidence and status for the applicant entity table, topic definition, boundary, decomposition, search matrix, and noise rationale. Stop on any Fail.

Step 8: Construct and audit formulas

Build the applicant and topic layers independently before combining them.

Applicant layers:

• A0: seed or exact expressions;
• A1: verified entity expansion;
• APPLICANT_TOTAL and fully expanded APPLICANT_TOTAL_EXPANDED.

Topic layers:

• S0_TOPIC_SEED;
• S1_TOPIC_CORE;
• S2_TOPIC_RECALL;
• S3_TOPIC_PRECISION;
• S4_TOPIC_FINAL_BALANCED;
• optional N_* exclusions.

Provide fully expanded, executable formulas. Do not deliver unresolved shorthand such as A_TOTAL AND S1.

APPLICANT_TOPIC_FINAL_EXPANDED =
() AND ()

When exclusions are justified:

APPLICANT_TOPIC_PRECISION_EXPANDED =
() AND () NOT ()

Audit bidirectional consistency: every entity marked Yes must appear in the applicant formula, every formula entity must have a Yes row, and No/Pending entities must not appear.

MCP dependencies

Do not call the MCP before the relevant gate permits it. Use only tools actually discovered in the connected server; do not infer tool availability from this document.

If a connector, fallback path, or previous partial response jumps directly to formula generation, ignore that shortcut and return to the missing gate. A connection failure never authorizes a shallow search path. Downgrade to formula_only_mode or pause at the current gate and identify the missing input.

Execute retrieval and preserve provenance

In retrieval_dataset_mode, run checkpoints in this order:

1. Confirm all preflight artifacts exist.
2. Validate applicant expressions/counts.
3. Validate topic seed/core expressions/counts.
4. Run the applicant-topic combined query.
5. Run a justified precision/noise-filtered variant.
6. Review a sample when records are available.

For every batch preserve the normalized applicant group, matched entity, exact applicant expression, topic formula version, batch ID, source database, ISO 8601 retrieval date, jurisdiction/date/legal-status filters, retrieved count, included count, and notes.

Keep source/publication counts, application-level counts, and simple-family counts separate. Treat source hit counts as audit metrics, not downstream representative counts.

Merge, deduplicate, and select representatives

Preserve publication/application identifiers, matched applicant names, expression provenance, formula version, batch ID, family IDs, legal status, and patent type when available.

Report these levels when fields support them:

Choose representatives for the user's target market. Prefer a complete member in that jurisdiction; otherwise prefer WO/US/EP or another commercially relevant jurisdiction, then the record with the richest title, abstract and claims, useful legal-status certainty, and earliest application/priority context. If China is the selected market or the source task explicitly requires a China-first view, CN may be the first jurisdiction. Record the selection reason.

If family fields are unavailable, state:

simple_family_status: unavailable
downstream_dataset_type: application_level_representative_fallback

Required deliverables

In formula_only_mode, create __patent_search_strategy.md with the preflight package, expanded formulas, assumptions, limitations, and execution checklist.

In retrieval_dataset_mode, create:

• __patent_retrieval_report.md;
• __patent_retrieval_report.docx unless the user opts out;
• full source/hit dataset;
• application-level dataset when fields support it;
• simple-family representative dataset when fields support it; and
• query/audit appendix.

Use a scientific report structure: scope and mode, preflight package, method, formulas, provenance, datasets, validation, limitations, and appendices. Use sentence-case headings, accessible tables, source notes, print-safe styles, and restrained color. Do not use decorative gradients or dashboard card grids.

Required report content

Every report must contain:

• the original user request;
• execution mode and pre-retrieval gate status;
• the selected applicant field and evidence of user confirmation;
• applicant scope and entity expansion table;
• technology topic definition;
• topic boundary confirmation table and confirmation status;
• technology topic decomposition table;
• search element matrix;
• noise and exclusion table;
• applicant expression audit table;
• topic strategy table and layered topic formulas;
• APPLICANT_TOTAL_EXPANDED;
• TOPIC_FINAL_BALANCED_EXPANDED;
• APPLICANT_TOPIC_FINAL_EXPANDED;
• NOISE_TOTAL_EXPANDED when noise exclusions are proposed;
• APPLICANT_TOPIC_PRECISION_EXPANDED when exclusions are applied;
• retrieval batch log in retrieval_dataset_mode;
• merge and deduplication summary in retrieval_dataset_mode;
• downstream dataset selection in retrieval_dataset_mode;
• recall and precision validation guidance without unsupported performance claims;
• handoff gate; and
• data gaps, ambiguous entities, zero-hit expressions, boundary risks, and manual-review notes.

The first substantive section must be Step 0: Original request and execution mode. A report must not begin with Search strategy, Applicant expression, Technology topic keywords, or a formula.

Constraint checklist

• Never assume ANCS silently.
• Never infer an ambiguous applicant entity silently.
• Never skip the applicant entity expansion table for a well-known company or familiar abbreviation.
• Never use a short dimensions-plus-keywords table as the complete topic preflight package.
• Never output ANCS, TA_ALL, or a combined query before the visible Step 0–7 package.
• Never label formal strategy as Step 3, keyword expansion as Step 2, classification mapping as Step 3, or final formulas as Step 4.
• Never use applicant names in place of topic logic; applicant and topic formulas must both be explicit.
• Never rely only on literal synonyms of the user's topic; expand across multiple technical facets.
• Never run applicant-scale estimates, topic presearch, or combined retrieval before both applicant and topic preflight artifacts exist.
• Never deliver only shorthand formulas; provide fully expanded executable expressions.
• Never claim complete recall or precision without executed results and validation samples.
• Never include an ambiguous affiliate without evidence or user approval.
• Never hide applicant expressions, topic formulas, or query strings.
• Never use the full source hit list directly as the downstream representative dataset when application or family fields support deduplication.
• Never route directly to downstream screening/tagging unless the user explicitly requests that separate post-retrieval step.
• Never mark retrieval_dataset_mode complete without downstream_dataset_type, downstream_dataset_file, and downstream_dataset_count.
• Never omit the editable Word report in retrieval_dataset_mode unless the user opts out.

Validation and handoff

Do not claim recall or precision without executed results, sampled relevance labels, and independent recall samples. Classify misses as boundary disagreement, missing technical facet, field-scope issue, translation gap, classification gap, stable noise, or operator/bracket error, then update every affected table and formula consistently.

Before handoff verify applicant field confirmation, entity disambiguation, preflight order, formula-table consistency, expanded formulas, noise logic, retrieval provenance, deduplication, representative dataset, Word output requirement, and full-hit exclusion from downstream representative input.

Use one of these handoff blocks:

execution_mode: retrieval_dataset_mode
retrieval_mode: applicant_topic_limited_retrieval
target_applicant: 
applicant_field: 
technology_topic: 
topic_limitation: 
source_hit_count: 
source_hit_count_usage: audit_only
downstream_dataset_type: simple_family_representative
downstream_dataset_file: 
downstream_dataset_count: 
ready_for: downstream_review_or_analysis

execution_mode: formula_only_mode
retrieval_mode: applicant_topic_limited_formula
target_applicant: 
applicant_field: 
technology_topic: 
expanded_formula_status: complete
dataset_status: not_executed
ready_for: patsnap_execution