Patent Prior Art & Freedom to Operate (FTO)
Collision Scanner, Prior Art Search, FTO Risk Analysis and Claims Matrix Comparer — the risk-screening core of the add-on.
What this group does
These four screens are the legal/technical risk-screening core of the add-on: before a company files a patent or ships a product, it needs to know whether the idea is novel (Prior Art), whether it collides with a specific competitor patent (Collision Scanner), whether a target patent’s claims are actually infringed element-by-element (Claims Matrix Comparer), and whether the product can be sold in a given territory without blocking IP (FTO Risk Analysis).
All four screens share the same two-stage hybrid engine (see Overview): a Stage 1 Embedding Engine that always runs on the user’s local Ollama instance, and a Stage 2 AI Engine that routes through whichever writer engine the user selected in Settings → Agentic. Every corpus these screens search (competitor patents, prior art references, territory-specific blocking patents) is a small, static, embedded example set — not a live connection to EPO/USPTO/WIPO/CNIPA. That’s a deliberate scoping choice: a real external patent database integration is a separate, much larger project.
1. Patent Collision Scanner
Purpose: A Freedom-to-Operate pre-screen that compares a pasted R&D specification (or invention disclosure) against competitor patents and produces a collision/infringement risk level.
Stage 1 — Embedding Engine
Vectorises the pasted R&D text via the user’s configured Ollama embedding model and compares it against a fixed, embedded set of 5 example competitor patents (COMPETITOR_CANDIDATES) using cosine similarity. Never calls the server — goes straight from the browser to 127.0.0.1:11434. If no embedding model is configured, the screen shows a degraded-mode warning and the candidate list stays empty rather than crashing.
Stage 2 — AI Engine
runCollisionOverlapAnalysis() sends the target spec and the selected competitor patent’s claim text to the routed AI engine, which returns a risk level (critical overlap / moderate risk / safe & low risk), a 2–4 sentence overlap summary, and a list of conflicting claim limitations.
Ledger columns
Scan ID (COL-2026-XXXX), target R&D spec, matching patent number, IPC class, vector similarity score, risk level, scan date, overlap summary, flag status.
Gauge
Collision Risk Index — the percentage of all scans at critical or moderate risk, shown as a horizontal bar (green under 20%, yellow 20–50%, red above 50%).
Key actions
- Run Scan — opens the modal, runs Stage 1 then Stage 2, saves a new scan record
- Flag to R&D & Legal — updates the scan’s flag status (critical → flagged to both teams, moderate → flagged to R&D); no live notification is sent yet, it’s a status field for now
- Delete a scan record
2. Prior Art Search Engine
Purpose: Evaluates an invention’s novelty and inventive step against a multi-source corpus — patent publications, academic papers, and conference specs — rather than a single competitor patent. Where Collision Scanner asks “does this infringe a specific patent?”, this screen asks “has anything like this already been published anywhere?”
Stage 1 — Embedding Engine
Uses the generic rankDocsByEmbedding() function (shared with Claims Matrix Comparer and FTO Risk Analysis) against a 6-record embedded corpus (PRIOR_ART_CORPUS: 2 patent publications, 2 academic papers, 2 conference specs). IPC and source-type filters narrow the pool before vectorisation. Same local-Ollama-only rule and degraded-mode fallback as Collision Scanner.
Stage 2 — AI Engine
executePriorArtSearch() sends all selected candidates (default: top 3 matches auto-selected) in one prompt and asks the model to classify each reference’s novelty impact — blocking art / background art / non-relevant — plus a technical relevance score (0–100) and a one-sentence novelty summary, all in the same order as submitted.
Ledger columns
Reference ID (REF-2026-XXXX), source type, title, author, publication year, IPC class, technical relevance score, novelty impact, search query, novelty summary, linked invention disclosure.
Gauge
Novelty & Inventive Step Meter — an overall patentability score starting at 100 and penalised per reference (−30 for each blocking-art hit, −8 for each background-art hit).
Key actions
- New Search — runs Stage 1 + Stage 2 and saves one reference record per selected candidate (one search can produce several records)
- Attach a reference to an invention disclosure (feeds Invention Disclosure Review once that record exists)
3. FTO Risk Analysis
Purpose: Turns technical/legal analysis into a business decision — can this product/component be launched in a specific commercial territory (Turkey, EU-27, US, China) without blocking IP, and if not, what design-around is needed?
Stage 1 — Embedding Engine
Uses rankDocsByEmbedding() against a territory-specific embedded corpus (TERRITORY_CORPUS — two example blocking-patent records per territory: TR, EU-27, US, CN). Only matches at or above 35% similarity, capped at the top 3, are passed to Stage 2 — low-similarity noise is filtered out before it reaches the AI prompt.
Stage 2 — AI Engine
runFtoRiskSynthesis() takes the candidate blocking patents (if any) and asks the model for three things: how many candidates are genuinely blocking (not every high-similarity match counts), an overall clearance status (cleared for market / conditional design-around needed / blocked by IP), and a concrete, technical design-around recommendation.
Ledger columns
Assessment ID (FTO-2026-XXXX), product/component name, territory, total patents reviewed, active blocking patents count, clearance status, clearance date, design-around recommendation, design-around task log (append-only).
Gauge
Market Launch Readiness — the percentage of all assessments at “cleared for market”.
Key actions
- New Assessment — runs Stage 1 + Stage 2 for a product/territory pair
- Trigger Design-Around Task — appends a technical spec to the assessment’s task log; if the assessment was blocked, it downgrades to conditional (a design-around underway is no longer a dead end) — see Screen Workflows
Known limitation
If Stage 1 finds no candidate patents (empty corpus match, or embedding degraded), Stage 2 receives an empty candidate list and tends toward a “cleared for market” conclusion by default — a known simplification, not a guarantee of real-world clearance.
4. Claims Matrix Comparer
Purpose: Produces a formal “claim chart” — the legal document format that maps a target patent’s claim limitations against a product’s feature specification element-by-element. Where the other three screens ask “is anything relevant?”, this screen assumes the target patent is already identified and asks “does every single claim element actually read on our product?”
Stage 1 — Embedding Engine (per-element)
Unlike the other three screens, this one runs Stage 1 once per claim element: for N claim-element pairs (claim clause + product feature spec) the user builds, rankDocsByEmbedding() is called N separate times, each as an independent 1-query/1-candidate comparison. The resulting semantic similarity score (0–100) per element is passed to Stage 2 only as a supporting signal — it never overrides the AI’s legal judgment. If embedding fails for an element, that element’s score is simply treated as 0; the flow doesn’t stop.
Stage 2 — AI Engine
runClaimMatrixCompare() sends all claim-element pairs plus their similarity scores in one prompt. For each element, in order, the model returns a match status — literal match / doctrine of equivalents / non-infringing — and a 1–2 sentence assessment note. It also produces one overall legal reasoning summary (3–5 sentences) synthesising all elements into an infringement/design-around conclusion.
Data model — deliberately different shape
Where Collision Scanner and Prior Art Search each save one record per scan/reference, a Claims Matrix comparison is one record containing multiple element rows — the standard structure of a real legal claim chart.
Ledger columns
Comparison ID (CLM-2026-XXXX), comparison title, target patent number, element rows (claim element number, claim clause, product feature spec, match status, assessment note), overall legal reasoning summary.
Gauge
Element Overlap Density — the percentage of all claim elements across all comparisons that are matched (literal match + doctrine of equivalents combined).
Key actions
- New Comparison — add/remove claim-element rows (at least one must remain), then run Stage 1 + Stage 2 together
- Expand a comparison row (accordion) to see the element-by-element table and the AI legal reasoning card
- Export Claim Chart (
generateClaimChartReport()) — there is no PDF rendering pipeline in this codebase yet, so this persists the record and returns a plain-text rendering for copy/paste; it does not generate an actual PDF - Delete a comparison (removes all its element rows)
Known limitation
Stage 1 makes one Ollama call per claim element — a comparison with 10+ elements can noticeably slow down before Stage 2 even starts.