Data visualization studio
Look at the index, not just the answer.
Three views of the same 10.5M+ US patents the retrieval runs on. Same coordinate frame, same published endpoints; what changes is that you can see where a result sits relative to everything around it.
0.0M+
US patents in one coordinate frame
0.0M
points resident while you fly
0k
points per call, to render it yourself
The studio is open to anyone. Sign in and your API key is issued on the spot, which is what you would query this data with.
Sign inThe frame
Positions come from the retrieval, not from a taxonomy.
A patent's place in the space is derived from the same embedding the retrieval matches against, projected to three dimensions and then frozen. Nothing is arranged by CPC class or by assignee, so two filings land beside each other because their claims are close, not because they were filed under the same heading.
One frame serves every endpoint on the patent-map router. A coordinate returned to your code by /patent-map/locate is the coordinate this map draws, which is what makes a position worth pulling into your own product. Neighbour order is cosine similarity in the embedding space; distance on screen is the projection's approximation of it, and the two disagree often enough that the ranked list is the one to trust.
The views
One space, three questions.
Each view locks the map to one job: where an idea is already covered, where it is not covered yet, and what surrounds one particular filing.
Patent space
10.5M+ US patents, placed by what they claim
Every patent in the index sits at coordinates derived from its own claim embedding, so what reads as a neighbour on screen is a neighbour in the retrieval. Describe an invention and the camera flies to the rank-weighted centroid of the top hits; the points around where it lands are the art a search would have had to surface.
- Up to 1.2M points resident at once, streamed by viewport from an octree
- Colour by CPC section or by filing year, 1980 to 2026
- Rings the nearest art by embedding similarity or by citation
Same data fromPOST /patent-map/locate
Whitespace
The pockets the corpus has not filled, ranked
A void is a region with claims all around it and few inside. The atlas scores each one from 0 to 1, names the CPC codes that border it and the assignees working nearby, gives the median filing year of the surrounding art, and lists the patents closest to its edge. It is a precomputed artifact rebuilt on its own schedule, so two people looking at it a minute apart are looking at the same voids.
- Ranked by opportunity score, descending
- Bordering CPC codes with their fractions and titles, per void
- Exemplar patents at each edge, clickable straight into the map
Same data fromGET /patent-map/whitespace
Portfolio trail
Walk out from one filing and keep the path
Seed it with an application number. The map locates that filing, frames the neighbourhood around it, and records every patent opened afterwards as a breadcrumb, so the walk from a claim to the art near it can be retraced instead of remembered. Without a seed it opens on the whole space and starts the trail at the first patent picked.
- Seeds from ?patent=<application number> in the URL
- Keeps the last 20 hops in order; click any crumb to fly back
- Neighbour order is cosine similarity, not distance on screen
Same data fromGET /patent-map/patent/:appNum
Reading it back out
Everything a view tells you has a call behind it.
The point cloud streams from an internal tile service, because putting 10.5M positions in a browser needs an octree rather than a response body. What the views tell you is published: the fly-to, the ranked voids, a filing's neighbourhood and its citations are documented endpoints, and your client gets the same fields this page renders.
The studio runs unauthenticated, against a demo key held server-side. Running the same calls with your own key, and reading the raw JSON they answer with, is what the sandbox is for.
Bring art you already know.
The studio shows you where it lands. The sandbox shows you the call that put it there.