Mercury

Inspiration

University tech transfer offices hold large patent portfolios, and most of the mechanisms sitting in them never get licensed. There are plenty of patents. What there isn't is a way to search them by what they actually do. Keyword and classification search can't answer the question a TTO analyst has in front of them: does this claimed mechanism solve a problem in some field nobody thought to check? We built Mercury so an analyst can look at that cross-domain connection directly and decide for themselves.

What it does

Mercury is a patent-mechanism recycling engine. It pulls bounded causal mechanisms out of retrieved independent claims, then looks for patents in other technical contexts that share a compatible mechanism and transfer boundary. It works in both directions. You can start from a known portfolio patent and map it onto current technical bottlenecks, or start from a technical problem and search by mechanism instead of keyword. Every result shows the cited claim text, the claimed component/process/effect, and an underuse signal, and that underuse signal stays strictly separate from term and status evidence. A score never implies ownership, legal availability, or freedom to operate. Those are human verification tasks, and we left them there.

How we built it

FastAPI backend. A curated 10,000-record patent corpus, deterministic claim segmentation, and a versioned condition-aware mechanism ontology (condition-aware-autonomy-v1) feed a hybrid structural retrieval layer behind /match_industry and /match_patent. Supabase/Postgres holds the production-shaped corpus and the claim-graph artifacts. The frontend is a Next.js workspace that puts mechanism evidence, underuse, and term/status signals in their own panels rather than collapsing them into one blended number. Codex supported the engineering work throughout: pipeline design, implementation, testing, documentation, and UX refinement.

Challenges we ran into

Going from a small smoke-test set to 10,000 records surfaced edge cases we hadn't seen in claim segmentation and mechanism tuple extraction. We chased those down with iterative batch runs and LLM-assisted validation passes. The harder problem wasn't the extraction; it was the interface. Any system that surfaces a match will imply the patent is available unless you design against that on purpose, so we split mechanism underuse (a research-priority signal) from term and status evidence and kept a retrieval score from ever standing in for legal or ownership verification.

Accomplishments that we're proud of

The pipeline runs end to end against 10,000 real patent records: corpus curation, claim segmentation, versioned ontology, hybrid retrieval, and a Supabase-backed persistence layer, with verification checks anyone can rerun (/health, /match_industry, /match_patent, plus a full web build and typecheck). The legal boundary survived the build, which was less obvious than it sounds when a flashier demo was always one shortcut away.

What we learned

Explainability has to live in the data structures. The claim-graph and evidence-span model works because it was part of the extraction pipeline from day one, and it isn't the kind of thing you can bolt onto a black-box similarity score afterward. We also learned how steadily a research-led tool wants to drift into sounding like a legal answer, and how much attention it takes to keep pulling it back.

What's next for Mercury

Reviewer-guided ontology expansion, more validated cross-domain transfer narratives, and current market and licensee evidence. No learned terminology changes a retrieval result until a human reviewer approves it and versions it. Further out, we want to point Mercury at a real TTO's known portfolio and measure whether analysts reach stronger leads faster than with the keyword-first workflow they already have.

Built With

• cloudflare
• codex
• deepseek
• railway
• supabase