Monitor Patent Litigation Risk Ip

Monitor Patent Litigation Risk

Purpose and boundary

Create an evidence-backed monitoring report for one primary target and, optionally, up to four comparison parties. Preserve the source workflow's patent discovery, public-record verification, family expansion, claim comparison, legal-history review, litigation timeline, case analysis, inventor activity, three-dimensional conclusions, and target-centric HTML output.

Act as an intelligence analyst, not as counsel, a court, a tribunal, or a prediction service. Do not provide legal advice or state that a party will win, lose, infringe, obtain an injunction, invalidate a patent, or settle. Separate:

• discovery signals from verified proceedings;
• allegations from findings and holdings;
• procedural rulings from merits dispositions;
• patent legal status from enforceability;
• patent-family coverage from commercial or litigation exposure;
• descriptive inventor activity from causal predictions; and
• source facts from analyst inference.

Treat Patsnap legal-event data as a patent-data and discovery source. Verify material case facts using primary tribunal, court, agency, or official-register records current to the report cutoff.

Suitable requests

Use this skill for requests such as:

• monitor patent litigation involving a named company;
• identify patents reported as asserted against or by a target;
• expand asserted patents to their INPADOC families;
• build a proceeding timeline with asserted patent numbers;
• compare representative family claims across material jurisdictions;
• review litigation posture, defenses, outcomes, and appeals;
• map recent activity of inventors linked to the reviewed families; or
• create a target-centric litigation-risk monitoring report.

Do not use this skill as the primary workflow for a standalone novelty opinion, inventive-step opinion, invalidity search, infringement opinion, FTO legal opinion, or open-ended technology landscape without named parties.

Input contract

Do not stop for routine confirmations once inputs are sufficient. Record reasonable assumptions and continue. Ask only when party identity is genuinely ambiguous or a missing choice materially changes the requested scope.

Target-centric rule

Use the first party as the grammatical and analytical subject of the report. Classify the target's role for every proceeding and asserted patent as one of:

• plaintiff;
• defendant;
• counterclaimant;
• co_party; or
• other.

Do not organize chapters around a comparison party as though it were the monitored target. Do not infer a role from patent ownership alone. Verify roles from the actual proceeding record.

Evidence model

Assign stable identifiers:

• cases: CASE-001, CASE-002, and so on;
• patents: publication number plus a stable record ID if needed;
• sources: S001, S002, and so on;
• search runs: Q001, Q002, and so on;
• findings: F001, F002, and so on.

For each material fact, preserve:

Use reporting, press releases, law-firm notes, and database signals as secondary leads. Never cite a search-results page as proof of a court fact when a primary source is available.

Verified Patsnap MCP mappings

Confirm each connector's live tool schema at runtime. Do not invent source tool names or parameters.

Global Core Patent Database — required

Use for patent search, detailed legal events, simple status, full text, images, and reexamination or invalidation data.

• Connector key: global_core_patent_database
• Marketplace: https://open.patsnap.com/marketplace/mcp-servers/core-patents
• Official marketplace page: https://open.patsnap.com/marketplace/mcp-servers/core-patents

Patent Briefing — required

Use for bibliography, legal status, family relationships, technical summaries, intelligent attached images, claims, descriptions, and translations.

• Connector key: patent_briefing
• Marketplace: https://open.patsnap.com/marketplace/mcp-servers/patent-briefing
• Official marketplace page: https://open.patsnap.com/marketplace/mcp-servers/patent-briefing

Advanced Patent Search — optional

Use for broader assignee, inventor, classification, keyword, and technology retrieval when its search routes improve coverage.

• Connector key: advanced_patent_search
• Marketplace: https://open.patsnap.com/marketplace/mcp-servers/patent-search
• Official marketplace page: https://open.patsnap.com/marketplace/mcp-servers/patent-search

Never expose or reproduce a real API key. Obtain the current connection URL through the official marketplace Connect action.

Patsnap MCPs do not replace jurisdiction-specific court and tribunal sources. Use available public-source research for discovery and primary-source verification, and log every query, filter, date, and limitation.

Execution workflow

Step 1 — Normalize parties and freeze scope

1. Confirm the primary target and comparison parties.
2. Build an alias table using verified corporate names, former names, subsidiaries, and spelling variants.
3. Distinguish parent, subsidiary, affiliate, and acquired entity; do not collapse them without evidence.
4. Record material jurisdictions, date range, business context, family definition, review cap, and cutoff.
5. Create an explicit exclusion list for false-positive names.
6. Record whether the request concerns incoming claims, offensive enforcement, both, or general monitoring.

Step 2 — Dual-route litigation-patent screening

Run patent-data discovery and public-record discovery independently.

Patent-data route

Search normalized assignee and applicant variants using Global Core Patent Database and, when useful, Advanced Patent Search. Review legal-event fields for litigation, infringement, complaints, injunctions, invalidity, opposition, administrative review, licensing disputes, or comparable jurisdiction-specific events.

Do not equate a keyword or event label with a verified asserted patent. Store candidates separately from verified asserted patents.

Public-record route

Search party aliases with jurisdiction-appropriate terms for complaints, cases, dockets, decisions, appeals, investigations, oppositions, reviews, and patent numbers. Prefer:

1. court or tribunal dockets and orders;
2. official agency or patent-office registers;
3. filed pleadings from reliable repositories;
4. company regulatory filings;
5. reputable reporting and practitioner commentary as secondary sources.

Identifier extraction

Extract patent and application identifiers using jurisdiction-aware patterns. Preserve the displayed identifier and record normalization separately. Support, as evidence requires, publication, grant, application, PCT, design, utility-model, and local registration formats.

Do not assume a ZL or CN format, strip digits indiscriminately, or infer a publication number from an application number. Verify every normalized identifier through patent data.

Merge and triage

De-duplicate by verified publication/application identity and family relationship. For each candidate, assign:

• patent_data_signal;
• public_record_signal;
• both_signals; or
• user_supplied_lead.

Then classify as:

• verified asserted patent;
• case-related but assertion unclear;
• legal-event lead only;
• false positive; or
• unresolved.

Record why the item changed state.

Step 3 — Verify proceedings and target roles

For each candidate proceeding, verify:

• official case name and case number;
• tribunal, jurisdiction, and division;
• plaintiffs, defendants, counterclaimants, intervenors, and other parties;
• filing date and current procedural posture;
• asserted patents and, where available, asserted claims;
• allegations and causes of action;
• defenses and counterclaims;
• material orders, stays, transfers, institution decisions, trials, and appeals;
• settlement, dismissal, consent order, judgment, or other disposition;
• verification date and primary-source locator.

Do not describe a dismissal without prejudice, settlement, preliminary ruling, institution decision, or appeal as a final merits victory. If the public record is incomplete, state exactly what remains unverified.

Build a case record compatible with scripts/orchestrator.py.

Step 4 — Expand families and analyze patents

For each verified or materially unresolved asserted patent:

1. Retrieve bibliography, family, legal status, full text, claims, translations, images, and material legal details.
2. Extract the canonical Patsnap or public patent locator from returned data; never fabricate an internal ID or UUID.
3. State the family definition and de-duplicate consistently.
4. Preserve continuation, divisional, continuation-in-part, national-stage, grant, reissue, and related relationships where material.
5. Verify legal status separately for each family member and state the as-of date.
6. Identify which family member and claims are actually asserted; do not transfer assertion to all relatives.
7. Select representative jurisdictions based on the case, business markets, family coverage, and claim availability—not a fixed CN/US/EP trio.

For representative claims, compare:

• independent-claim category;
• principal limitations;
• scope emphasis;
• material prosecution or amendment differences;
• translation provenance;
• apparent overlap and divergence; and
• limitations relevant to the alleged product or conduct, if verified.

Do not perform a dispositive claim-construction or infringement analysis unless separately requested and appropriately sourced.

Step 5 — Retrieve and handle drawings safely

Use Patent Briefing's intelligent attached-image capability or another verified patent-record image source. Prefer a stable local copy or validated base64 payload for a portable report.

• Validate media type and size.
• Reject active content, javascript: URLs, non-HTTP(S) remote URLs, and malformed base64.
• Do not rely on expiring signed URLs for the final report.
• Use descriptive alt text.
• If no verified image is available, show a textual Image not available state.
• Do not fail the substantive report because an image is missing.

Step 6 — Build the litigation timeline

Create a single chronological timeline with:

Include a patent number at each node when the event actually concerns a patent. Do not attach every case patent to every procedural event. Distinguish filing, service, answer, counterclaim, claim-construction, stay, institution, trial, order, settlement, judgment, and appeal.

Normalize dates to ISO format while preserving uncertain or partial source dates.

Step 7 — Perform case deep dives

For each verified case, cover:

1. parties and target role;
2. forum and procedural posture;
3. asserted patents and claims;
4. accused products or conduct, if publicly identified;
5. allegations, clearly labeled;
6. defenses and counterclaims, clearly labeled;
7. disputed technical and legal issues;
8. material orders and reasoning;
9. outcome and appeal status;
10. operational monitoring triggers;
11. primary and secondary sources; and
12. evidence gaps.

Attach [S###] citations to every material fact. Quote sparingly and within applicable copyright limits. Prefer paraphrase plus a precise locator.

Step 8 — Analyze core inventor activity

Aggregate inventors from the reviewed patent families, rank by transparent criteria, and select up to the source default of ten. Search the configured recent period, default three years, using verified inventor identity and assignee context.

For each inventor, report:

• normalized identity and ambiguity;
• recent filing count and counting method;
• annual counts;
• top classifications;
• three to five evidence-backed technology themes;
• representative publications and links; and
• source and cutoff.

Inventor activity is descriptive. Do not treat it as proof of future litigation, employee movement, strategic intent, or product launch.

Step 9 — Synthesize three dimensions

Geographic exposure

For each material jurisdiction, consider verified proceedings, asserted patents, current family members, business activity supplied by the user, and procedural posture. Use states:

• Elevated;
• Moderate;
• Lower on reviewed evidence; or
• Not assessable.

Family count or active-patent count alone cannot determine exposure.

Litigation alert

Summarize disputed issues, target role, procedural posture, defenses, counterparties, asserted claims, material deadlines only when verified, and monitoring actions. Do not impose a word quota; write enough to make evidence, uncertainty, and action clear.

Technology trend

Describe recent filing directions from the inventor and family evidence. Separate observed filing activity from inferred strategy and forecast scenarios. Provide near-, medium-, and long-term monitoring hypotheses only when evidence supports them, with explicit uncertainty.

Step 10 — Produce artifacts

Create:

1. one target-centric HTML report;
2. one structured JSON evidence record compatible with scripts/orchestrator.py when requested or useful; and
3. CSV exports for cases, asserted patents/families, timeline, inventors, and sources when requested.

Do not add these generated outputs to the skill package itself.

Active report structure

Use the following continuous report order:

0. Executive summary
1. Scope, target, method, cutoff, and limitations
2. Target overview and party-to-patent mapping
3. Litigation timeline
4. Target's verified asserted patents and family details
5. Proceeding deep dives
6. Core inventor activity
7. Three-dimensional conclusions
8. Action register
9. Patent/family summary list
10. Sources, search log, assumptions, and limitations

Use seven concise navigation tabs by grouping adjacent chapters:

• Summary
• Scope and Overview
• Timeline
• Patents
• Cases
• Inventors
• Conclusions and Sources

Counting semantics

Never mix these counts:

• query matches reported by a source;
• records returned;
• unique publications reviewed;
• candidate litigation-linked patents;
• verified asserted patents;
• family members;
• patent families;
• verified proceedings; and
• procedural events.

State the family definition, jurisdiction coverage, date range, de-duplication rule, pagination limit, and unresolved records next to every material count.

Visual and HTML specification

Use one portable, static, English HTML file with a restrained Western scientific/legal design:

• white or neutral paper surface;
• navy and slate hierarchy;
• system sans-serif typography;
• compact metadata band and executive facts;
• semantic tables, evidence cards, and timeline;
• text labels in addition to color;
• responsive table wrappers;
• print CSS and repeated table headers;
• no decorative emoji, gradients, faux gauges, or unsupported precision.

Do not require Chart.js, a CDN, remote JavaScript, analytics, trackers, or external fonts. Use simple HTML/CSS tables or accessible static SVG only when a chart materially improves comprehension.

Escape all external text. Reject unsafe URLs. Do not embed API keys, local paths, session IDs, hidden prompts, source credentials, or expiring signed links. Confirm every required chapter, case, patent, and citation appears in the final output.

Direct evidence-backed HTML authoring is the default. The source-retained scripts/render_report.py is an optional safe deterministic export and test surface; it is not an excuse to populate placeholders or synthetic facts. SKILL.md.bak_v9_css is a localized historical specification and is not authoritative.

Script contracts

scripts/config.py

Read when defaults, report section names, target roles, evidence states, risk states, or field semantics are needed.

scripts/orchestrator.py

Use to create an empty JSON skeleton and validate cross-field references. It never retrieves data. Populate its records only from evidence gathered by the agent.

Example:

$env:PYTHONDONTWRITEBYTECODE='1'
python scripts/orchestrator.py --parties "Target Corp,Comparison Corp" --cutoff-date 2026-08-07 --out report_data.json

scripts/render_report.py

Use only after the record is populated and validated. The renderer escapes text, rejects unsafe URLs, and creates an offline HTML file.

$env:PYTHONDONTWRITEBYTECODE='1'
python scripts/render_report.py --data report_data.json --out litigation_report.html --lang en

scripts/tests/smoke.py

Run offline to test schema validation, safe rendering, required content, and removal of active-content payloads.

scripts/main.py

Retain as the source package's minimal entry point. It reports helper availability and does not claim to execute the evidence workflow.

Failure and fallback behavior

• If a connector is unavailable, document which capability is missing and continue only with sources that can be verified.
• If primary case records are inaccessible, retain the item as partially_verified or unverified; do not elevate reporting to a holding.
• If patent and court identifiers conflict, preserve both, investigate, and mark conflicting.
• If party identity is ambiguous, exclude or isolate the record until resolved.
• If legal status lacks an as-of date, do not present it as current.
• If an asserted claim is not public, state that the patent is reported as asserted but claim-level scope is not verified.
• If an image cannot be safely embedded, omit it and keep the patent analysis.
• If inventor identity cannot be disambiguated, aggregate only verified records and disclose the limitation.
• If counts are truncated or sampled, label them as returned or reviewed counts, not totals.
• If no verified cases remain, deliver a negative-result monitoring report with search coverage and limitations; do not manufacture examples.

Final self-check

• The target and comparison parties are correctly identified and normalized.
• Every case has a stable ID, verified role, tribunal, case number, source, and as-of date.
• Every asserted patent is linked to a case or explicitly marked unresolved.
• Candidate signals are not presented as verified assertions.
• Allegations, orders, holdings, dispositions, and inferences are distinguishable.
• Patent numbers, family relationships, status, claims, and images are verified.
• Family definition and count semantics are stated.
• Representative claim jurisdictions are selected for materiality, not by a fixed country list.
• Timeline nodes cite the specific event and relevant patents.
• Inventor trends are descriptive and use a stated identity/count method.
• Geographic, alert, and trend conclusions cite evidence and uncertainty.
• Global Core Patent Database, Patent Briefing, and any Advanced Patent Search use is logged accurately.
• Primary public sources verify material case facts.
• All external content is escaped and all links are safe.
• HTML is complete, offline, responsive, printable, accessible, and free of secrets.
• JSON and CSV outputs, when generated, reconcile with displayed counts.
• No placeholder, fabricated patent ID, invented case, or unsupported prediction remains.

Structured record reference

Use this reference to reconcile direct HTML, JSON, and CSV outputs. Do not populate absent facts with empty-looking prose; preserve an empty value plus an explicit limitation.

Root record

Target object

Keep subsidiaries and affiliates in the alias register only when the relationship and relevant dates are sourced. Otherwise represent them as separate parties.

Scope object

Each search entry should contain:

• stable search ID;
• connector or public source;
• discovered tool name;
• query and aliases;
• filters and jurisdictions;
• date range;
• execution timestamp;
• matched count if source-reported;
• returned count;
• reviewed count;
• selected records;
• de-duplication rule; and
• limitations or errors.

Overview object

Use only reconciled values:

Patent record

For each element of litigated_patents, preserve:

Do not use a patent card to imply that every listed family member was asserted. Mark the asserted member and the relationship explicitly.

Family member record

Preserve, when available:

• publication number;
• application number;
• jurisdiction;
• relationship type;
• filing date;
• publication date;
• grant date;
• priority date;
• legal status;
• status as-of date;
• representative-claim reason;
• source-language status;
• translation provenance; and
• source locator.

Claim comparison record

For each compared representative claim, record:

• family identifier;
• publication number;
• jurisdiction;
• claim number;
• claim category;
• exact source-language text locator;
• English working translation source;
• principal limitations;
• protection emphasis;
• material amendment or prosecution context;
• overlap with other representatives;
• material differences;
• relevance to the proceeding; and
• analysis limitation.

Case record

For each element of cases, preserve:

Timeline event

Each event should include:

• ISO or source-preserved date;
• case ID;
• event label;
• neutral description;
• event type;
• relevant patents;
• relevant claims;
• target role;
• source ID and locator;
• evidence state; and
• uncertainty note.

Inventor record

Each inventor entry should include:

• normalized name;
• source variants;
• disambiguation method;
• identity confidence;
• recent filing count;
• counting method;
• yearly statistics;
• top classifications;
• technology themes;
• representative publications;
• current assignee only when verified;
• source and cutoff; and
• limitations.

Conclusion record

Each geographic item should contain jurisdiction, evidence-qualified state, verified proceedings, asserted patents, family context, business-context input, reasoning, uncertainty, trigger, and action.

The litigation alert should contain current posture, disputed issues, verified deadlines or events, target role, counterparties, defenses, open evidence questions, monitoring cadence, and responsible owner.

The technology trend should contain observed period, counting basis, themes, representative evidence, alternative explanations, near-term hypothesis, medium-term hypothesis, long-term hypothesis, and confidence.

Each action should contain:

• priority;
• concrete action;
• owner;
• trigger;
• due date only when verified or user assigned;
• dependent evidence;
• source IDs; and
• completion criterion.

Source record

For each element of sources, preserve:

• source ID;
• source type;
• title or label;
• issuing body;
• stable URL or record locator;
• docket entry, page, paragraph, claim, or event locator;
• publication or filing date;
• access date;
• language;
• translation provenance;
• coverage;
• limitation; and
• associated case, patent, event, or finding IDs.

CSV exports

When CSV is requested, create separate files for:

1. cases.csv;
2. asserted_patents.csv;
3. family_members.csv;
4. timeline.csv;
5. inventors.csv;
6. search_log.csv; and
7. sources.csv.

Use UTF-8, stable headers, ISO dates, explicit empty values, and semicolon-separated stable IDs for many-to-many fields. Do not flatten allegations or holdings into an unlabeled free-text cell.

Cross-artifact reconciliation

Before delivery, verify:

• JSON case IDs equal the set referenced by patents and timeline events;
• verified case count equals verified case records;
• verified asserted patent count equals qualifying patent records;
• family-member count follows the stated family and de-duplication rule;
• CSV row counts reconcile with JSON arrays;
• every HTML case and patent has a JSON counterpart;
• every material HTML fact has a source ID;
• every action has a trigger or rationale;
• no source ID points to a missing source record; and
• the displayed cutoff matches every output artifact.