Data Model

Patent research produces a lot of loosely connected material: search results, product brochures, claim charts, spreadsheets with your own classifications and a memo at the end. To let people and research agents work on the same study, Patalyze puts all of it into one well-defined data model. This page describes that model in detail.

Everything happens inside a database, a self-contained home for one analysis. It holds the patents you gather and the products you track. Wherever a patent and a product meet, a mapping compares them claim by claim, and that comparison is the evidence behind every result. Attributes enrich the records with whatever your analysis adds, e.g. a custom classification or a reviewer's verdict. On top of the data sit the pages that present it: the tables, dashboards and notes you build.

Databases#

Each database is fully isolated, so data never crosses from one into another. A new database never starts from zero though: the patents you add are drawn from our shared global corpus, and the products are discovered on the open web. What makes a database yours is the selection and the analysis you build on top.

In general, one database answers one question. Clearing a single product for launch is one question, scanning the market for products that might infringe a patent family is another. Reusing an existing database saves the setup, but a verdict is only as trustworthy as its scope, and a dedicated database keeps each conclusion easy to stand behind months later. Name it after the question it answers. When related databases pile up, group them in folders and tag them in the library.

Patents#

A patent is a time-limited, government-granted right to stop others from making, using or selling an invention. It is published as a document with a unique publication number, such as EP4309228B1, and its legally binding scope lives in its claims. Everything else in the document, i.e. the abstract, the description and the drawings, is there to explain and support those claims.

The right is a bargain with the state. In return for up to twenty years of exclusivity, the owner has to publish how the invention works, so the disclosure is the price of the monopoly. The right also runs out after twenty years, and the renewal fees that keep it alive climb over time, so a patent is only held as long as it is worth paying for. For the reasoning behind all this, see So why patents? What's the deal?

Inside a database, a patent is identified by its publication number alone. The full record does not live in your database. Give Patalyze a number and it gathers everything known about that patent from a global corpus of millions and normalizes it, so US, European and Japanese filings all read the same way.

Four things anchor every record:

• Identity: the publication number, and the status that says whether the patent is still in force.
• What it protects: the title, the abstract and, at the legal core, the claims.
• Classification: a set of technology codes you can search and filter on.
• Family: the same invention published in other countries.

Everything else, such as the dates, applicants, inventors, figures and the prosecution history, hangs off those four. Be aware that applicants are the parties who filed, while assignees are the current owners, which is what Patalyze searches and displays. On a table these fields appear as system attributes, ready to sort, filter and chart on. If publication numbers themselves are new to you, the guide to patent numbers walks you through how to read one.

Adding patents#

The header of a database offers two ways in. The Spawn agent button opens a research agent that does the work for you, and the Add data menu lets you bring in records yourself. Choosing Add patents opens the search dialog, and from there you can either search the global corpus for patents you do not know yet, or paste the numbers of the ones you already have in hand.

Search the corpus. Search runs over our shared global corpus, the same millions of patents behind every database and the Data API. A single query can combine three techniques, and a good search usually uses all of them. Keyword search matches exact words and phrases in a patent's title, abstract and claims. Terms combine with AND by default, and a trailing * stands in for any ending, so electrolyte* also catches electrolytes. Semantic search matches meaning instead of words: describe the invention in plain language, or drop in a claim or a whole patent, and Patalyze ranks the corpus by how close each patent sits in meaning, which surfaces filings that describe the same idea in different words. Filters narrow the field by the structured parts of a record. Each filter is a field, an operator and one or more values, and you can stack as many as you need, combined with And or Or:

A freedom-to-operate search for solid-state cell packaging might, for example, stack a Text filter set to similar to (ranking by meaning instead of exact words) with a classification code and an in-force status. Every filter narrows the count, which is shown live as you build, and the matches preview in a table underneath. When the field looks right, add the patents that fit and they drop into your database.

Enter publication numbers. Sometimes you already know exactly which patents you want, e.g. a competitor's filing a colleague flagged or the patents named in an earlier report. Skip the search and add a Number filter instead, then paste them in, such as US11831027B2 or EP4309228B1. A whole list goes in at once, separated by commas, semicolons or line breaks.

Either way, the import runs while you wait. The dialog stays open until every patent is really in the database, so by the time it closes the claims and dates are there to read. One import brings in up to 100,000 patents. The research itself carries on afterwards: whenever you ask an agent to fill an attribute or to chart mappings, it picks up each new patent in the background.

Reading a patent#

Open a patent and it fills the page as a single document: the title and abstract up top, then the full claim tree, the description, the figures, the family, a timeline of legal events, the register documents, the classifications and the patents it cites. Inside a database a Mappings section joins them and lists every claim already charted against a product with its score. Attributes sit in a column beside the text, and anything you open from the record, e.g. the PDF, the description or a figure, slides into a panel on the right. The tour below follows the order in which they matter.

Claims are the patent: the numbered, legally binding definition of what it protects. A claim is a single sentence broken into elements, and each element is a feature that has to be present for the claim to "read on" a product, i.e. to be fully present in it. Claim 1 stands on its own as an independent claim, and the claims after it can depend on it and narrow it by adding further elements. That element-by-element structure is exactly what a mapping works on: to compare a patent against a product, Patalyze takes each element in turn and judges whether the product has it. The claims are where any infringement analysis begins.

Family. A single invention is rarely filed once. File it in the US, Europe, Japan, China and Korea and you get five publications for one underlying invention. That matters for risk, because a competitor's patent filed across five offices is one threat rather than five, and the family ties the publications together so you can read them as one. Each member carries its own status, since the same invention can be in force in one country and lapsed in another. For the wider picture, the patent family tree is a good primer.

Classifications. Every patent is tagged with CPC and IPC codes that place it on a shared technology map, such as H01M for a broad area or H01M 50/124 for a narrow one. The codes are hierarchical, narrowing from a broad section down to a specific group. You can search and filter on them to keep a technology landscape in focus, or to surface patents a keyword would miss because they never use your vocabulary.

Legal events. A patent's life is a sequence of events: granted, renewed, assigned to a new owner, opposed, lapsed, revived. Patalyze gathers the legal events from every office that has touched the patent into one timeline, so you can see at a glance whether it is alive, who owns it now and what has happened along the way.

Register documents. For European patents, the EPO publishes the file, i.e. the documents exchanged during examination and opposition. Patalyze links them straight from the record, so you can open the examiner's communication or an opponent's notice without leaving the page.

Citations. A patent cites the prior art it was weighed against, and is cited in turn by later patents. Each reference is tagged by where it came up, e.g. the search report, the examination or an opposition, and linked out to the cited document.

Description. Behind the claims sits the full specification, often tens of pages, where the invention is set out in detail. It reads as a section of its own right under the claims, opens on its first paragraphs and shows how many remain. Its paragraphs are numbered the way the patent office numbers them, and "Open in panel" moves the text into the panel beside the record, where all of it is searchable. The description is also where the claim language is pinned down: a term that reads as broad in a claim is often narrowed by the examples here, so reading it is part of judging how far a claim really reaches.

Figures. Most patents carry drawings, and the drawings often carry detail the words skip. Patalyze shows them as a grid on the record. Click one and it expands in place to full width, the arrow keys step through the rest and Escape closes it again. "Open in panel" moves the expanded drawing into the panel beside the record, so you can hold a figure open while you read the claims that describe it. Figures referenced in the claims and the description also render inline where they are mentioned.

Working with a patent#

Beyond reading the record, a patent is a place to work. With one open you can:

• Read the source: open the full PDF, the description or a figure in the panel beside the record, without leaving the page.
• Put an agent on it: Spawn agent opens a research agent with the patent already in hand, and "Open in" hands its claims and bibliographic data to ChatGPT or Claude instead.
• See what it already reads on: the Mappings section lists every claim charted against one of your products with its score and opens the full comparison. The mappings section below covers it in full.
• Take it with you: copy a link to share the record, or download it as Excel, Word or PDF with its full metadata.

Products#

A product is any real-world offering whose features a patent's claims can be read against: a device, a system, a chemical formulation, a piece of software or a method as practiced. Whatever its form, it is the concrete thing infringement is judged on, i.e. the object on one side of the comparison, with a patent's claims on the other.

The product can be your own or someone else's. In freedom to operate, you map your own product against the field to ask whether it is clear to make, use and sell. In infringement detection, you map a competitor's product against your patents to ask whether it practices them.

What matters most about a product is how it actually works: its features, components and steps, described in enough detail that each claim element has something concrete to meet. Capture that well and Patalyze can judge how a claim reads against the product. Capture it thinly and the comparison is left to guess. Patalyze reads a product in two layers. The product doc holds its substance, such as descriptions, diagrams, datasheets and captured pages, as blocks Patalyze reads for depth on a single product. Attributes carry the lightweight metadata, e.g. category, manufacturer or territory, that works across the whole set, so you can filter, group and chart many products at once on tables and dashboards.

Adding products#

Choosing Add products from the Add data menu opens the same dialog the patents side uses, and there are three ways through it, depending on how much you already have in hand. A database holds up to 1,000 products.

Search the web. Search discovers products by their features and categories out on the open web, rather than looking them up in the patent corpus. Point it at a competitor and Patalyze surfaces matching products, which is handy when you want to see who else sits in the same space. You narrow the field with filters over what a product carries: features, name, website, territories, category, manufacturers and distributors, stacked with And or Or. The matches preview in a table as you build, and the ones you keep drop into your database as products of their own.

Start from a website. When you already know the site, the Website filter narrows discovery to it, so a product page or spec sheet on the open web becomes a product in your database. Unlike the patents side, this work is asynchronous: discovery returns straight away, products arrive as they are found and the table header shows how many sources have been scanned.

Write or upload. For a product you already hold the source material for, type or paste a description, then drop in PDFs and images: specifications, brochures, datasheets, photos. The description becomes the product doc, and Patalyze reads everything you give it to understand the product and fill in its attributes.

Every product that arrives this way gets its own research agent. It browses the product's website, writes a technical account into the product doc and saves the screenshots and PDFs it finds as evidence you can trace back to.

The product doc#

Every product opens as a document on its own page, the product doc. It works like a note: it holds a title you rename in place, a description and any source material you drop in, all as blocks in one place, and it is the single source every mapping reads from. The richer the blocks and the cleaner each one, the better Patalyze grasps what the product is, and the sharper every claim comparison that follows.

Inside the doc, type / to open the block menu. The doc is a full rich-text editor with headings, lists, tables, quotes and code for any notes you keep alongside the product, and a handful of blocks are made for the source material behind it:

Drawing. A whiteboard canvas inside the doc. Sketch a mechanism or a rough layout by hand. It opens full screen to draw and settles back into the doc as a preview.

Image. A picture with an optional caption. Product photos and diagrams give the analysis visual evidence to draw on.

Molecule. A 2D chemical structure rendered inline from a SMILES string, so the chemistry behind a product, e.g. an electrolyte additive, sits alongside its other source material.

PDF. An embedded datasheet or brochure with its first page previewed inline. Patalyze reads the PDF and folds what it finds into the product's features.

3D model. An STL file rendered in place, for a product whose geometry is the point. Useful when a claim element turns on a shape rather than a specification.

Screenshot. A page captured while the research agent browsed, labeled with the page it came from, so you can trace the product back to its source. The agent saves these itself. To place one in the doc by hand, pick it from the media picker rather than the block menu.

Replay. A session recording, i.e. an interactive product page preserved as something you can play back rather than a single frozen frame. Upload one and it sits alongside the screenshots as evidence.

Beside the doc, a product has two built-in attributes: its name and its websites, i.e. the addresses you supply or the agent finds. Everything else you want to know about a product at a glance, e.g. its categories, manufacturers, distributors or territories, is a custom attribute. The research agent creates the ones it needs while it researches a product and fills them from the sources, and you add any other from the column picker on a table. The ones the agent keeps are multi-selects whose options grow as values are written: a manufacturer named once is one chip everywhere, and the same name written again, in any casing, lands on that chip rather than a new one. Categories are what sorts a database into kinds of products, so the one under analysis sits among its peers when you filter and group on tables and dashboards. You can edit any of them inline on the product page, where "Show all attributes" reveals the ones still empty.

Mappings#

A mapping is the comparison between one patent and one product, worked through claim by claim. Patalyze takes each of the patent's claims, breaks it into the individual elements that must all be present for the product to infringe, and judges every element against the product's features, with the evidence behind each call.

This is the conceptual heart of Patalyze. A mapping is basically a claim chart, i.e. the document a patent practitioner builds to argue, element by element, whether a product reads on a claim. It turns a paragraph of dense legal language into a verdict you can scan in seconds and defend line by line.

Take one patent and its independent claim, here a cell-assembly claim of four elements. Patalyze splits the claim and marks each element against the product. In a single look you see that the cell plainly ships in the laminated pouch the claim ends on, that it most likely has the solid-state stacks and the frame around them, though the datasheet stops short of saying so, and that it plainly lacks the flat plate that carries a stack on either side. Three of the four elements are present, which makes 75% and a Medium read rather than a clean infringement.

Mappings pair well with a shared feature vocabulary, which is nothing more than an unscoped multi-select attribute holding the discriminating features you care about. Ask an agent to fill it and it reads them out of a patent's claims and a product's doc into one option pool. Because the attribute is unscoped, patents and products draw on the same pool, and that is what lets a dashboard chart the flow from patents through features to products.

A mapping is the unit of evidence behind almost every patent question. You build one whenever you need to know how a specific claim lines up against a specific product:

• Freedom to operate: before you ship, check your own product against the live patents around it to confirm it is clear to make, use and sell.
• Infringement detection: show, element by element, that someone else's product reads on a patent you hold.
• Invalidity: map a patent against an earlier product or reference to show its elements were already known.
• Portfolio valuation: see which patents actually read on real products, and how strongly, before you license or buy.

Element statuses and mapping scores#

A claim only reads on a product when every one of its elements is present, so the element is the unit of judgment. Each one gets one of five statuses:

• yes: the product clearly has this element.
• probably-yes: the product most likely has it, but the documents stop short of saying so outright.
• probably-no: the product most likely does not.
• no: the product clearly does not have it.
• omit: the element is set aside and left out of the score.

Once every element has a status, Patalyze rolls them up into a single score for the claim: the share of non-omitted elements judged present, counting both yes and probably-yes.

The score measures how close the read is. It is not the verdict on its own, because infringement is all-or-nothing: a claim reads on a product only when every element is present, and one missing element breaks the chain, however high the rest score. To keep that distinction visible, scores sort into four risk bands:

• Critical, at 100%, means every element is present (red).
• High, from 81 to 99%, means almost all elements are present (orange).
• Medium, from 61 to 80%, means a majority are present (yellow).
• Low, from 0 to 60%, means few or none are present (gray).

The band follows a claim's exact score, and the percentage shown on a cell is that score rounded to a whole number: a three-of-four read is 75% and sits in Medium, while a five-of-six read rounds to 83% and sits in High.

A Critical band on a live claim is the result the whole analysis exists to surface: a patent your product reads on, in force and owned by someone else. The lower bands are the patents you can set aside, at least for now.

Evidence and control#

The statuses are only half a mapping. Open one in full and each element sits beside the reasoning for its verdict, with links back to the exact document the call rests on, e.g. a reference opens the product PDF at the page the evidence came from. That chain from element to evidence is what makes a mapping something you can trust and defend.

Mappings start with an agent. Ask a research agent to chart one pair and it charts just that one. Ask it to check a product against a whole set of patents and our standard skills fan out a subagent per claim chart, so each one gets the depth a litigation-grade chart needs. Charting every patent against every product is rarely what you want, so nothing is charted until asked. You stay in control of the result: override a verdict you disagree with, or omit an element you have ruled out, and the score updates to match. With a mapping open you can swap the product side too, picking another product from the database or starting a fresh one from the same claim. The same edits are open to an agent through the Patalyze MCP server, which can read and adjust mappings without anyone opening the app.

Mappings in tables#

Mappings are built to be read in bulk. The per-claim score surfaces in any patent or product table as a colored cell where a patent and your product intersect, so a whole field of comparisons reads at a glance and the dangerous claims stand out by color. Filter the column to the Critical and High bands and the database narrows to the claims worth reading in full. Click a score and choose "Open in panel" to edit the mapping beside the table, or "Open as page" to drop into the full mapping and walk the evidence for each element in turn.

For the legal background on the different shapes a claim chart can take, see the different flavors of claim charts.

Attributes#

An attribute is a data field on a patent or a product. Attributes are how you organize, visualize and extend records.

Think of attributes as the light, sortable metadata on a record rather than its deep content. A patent's claims or a product's description are the substance you read one record at a time. Attributes are what you want to know at a glance, uniform enough to scan, filter and chart across a whole set of records at once. That breadth is the point: attributes are how you reason over many patents or products together.

Every attribute belongs to a single database. It can be scoped to patents or to products, or left unscoped so both sides share it. Each attribute is one of two kinds:

• System attributes are built in: a patent's title, applicants, inventors, dates, status and classifications, which come from the corpus, and a product's name and websites. You can edit a product's inline, but you cannot delete a system attribute or change its type, since the rest of Patalyze relies on these fields being present and shaped the way they are.
• Custom attributes are the ones you create, or an agent creates as it researches, for whatever you want to read across many records at once. A product's categories, manufacturers, distributors and territories live here, next to a reviewer's verdict or a priority, which is why renaming an option changes it on every record. Everything below is about them.

Attribute types#

Every attribute has a type, and the type decides what its values look like and how they behave when you sort, filter or chart on them. System attributes have pre-defined types that cannot be changed. For custom attributes you can choose from one of the types below:

Most types need nothing beyond a name. A few carry a little extra configuration:

• Currency takes a currency code (EUR by default) so amounts format correctly.
• Select and multi-select each carry a list of options that you label and color.
• User and users draw their choices from the people in your organization.
• Note takes no configuration, but its values are different in kind: a rich-text note per record. Clicking the cell opens it in the side panel next to the table, and it has its own page as well. The table cell shows a short summary of it, filters and the search box match that summary, and notes are not charted.

The type is the one thing you fix when you create an attribute. Everything else, i.e. its name, its description and its options, can change later.

Creating, editing and deleting#

You add a custom attribute from a table, and it lands there as a new column.

Click "Create" and it appears as a new column on the table, empty and ready to fill in.

The rest of the lifecycle lives in the attribute's header menu. "Edit attribute" reopens the same form to rename it, change its description, or add, rename, recolor and remove options. The type stays locked, since changing it would strand the values already stored against the attribute. There are two ways to make a column go away, and they are not the same thing:

• Don't show on this table hides the column from that one table without touching its data. You can add it back later from the column menu.
• Delete attribute removes the attribute itself, across the whole database.

Setting values#

A value is whatever you record for one attribute on one record. You set it in either of two places, and the editors are identical in both.

In a table cell. Click a cell to edit it in place: text opens for typing, a number takes a figure, a checkbox toggles and a date opens a calendar. A select opens its options to pick one, a multi-select to toggle as many as you like, and the user and users types work the same way over the people in your organization.

On the record itself. Open a single patent or product and the same attributes line up in a column beside it, with the same editors. It is the comfortable place to fill in several at once while you read a record, instead of reaching across a wide table. "Show all attributes" reveals the ones still empty.

Clearing a cell empties it, and empty cells are simply skipped when you filter, sort or chart.

Filling a column with AI#

Typing a hundred values by hand is the part nobody wants. Select the rows on a table and click "Ask agent" in the footer, or simply ask a research agent to fill the column, and it works from each record's own material: a patent's claims and abstract, a product's doc and the files attached to it. It splits the records into blocks and gives each block its own subagent, so a column across hundreds of records is one request rather than one long wait.

The attribute's description is what the agent reads to know what belongs in the column, so write one wherever the name alone would not settle it. For a select or multi-select, the agent reuses an existing option whenever the wording matches, in any casing, and adds a new option otherwise. So if you want a fixed vocabulary, define the options first and say so in the description.

Filtering, sorting and charting#

Once a value is set, a custom attribute filters and sorts like any built-in column, and the operators follow its type: text offers contains, is, starts with and their negations. Number, currency and date offer the comparisons plus a between range. Select and user filter by is and is any of, and multi-select and users by include and exclude. Add a filter from the toolbar, or open the attribute's header menu to filter by it directly. Sorting lives in the same header menu ("Sort ascending", "Sort descending", "Clear sorting"), and each type sorts the sensible way: numbers and dates by value, text alphabetically, and the option and checkbox types grouping like values together.

Any attribute can also become a chart without leaving the table. Open its header menu, choose "Visualize as chart" and a preview appears, binned to suit the type: a select or numeric attribute as a ranked bar of its values, a checkbox as a donut split, a date as a trend over time. The preview respects the table's filters, so it charts exactly the rows you are looking at. From there, "Add to dashboard" keeps the chart on an existing dashboard, or "Create dashboard" starts a new one. Clicking a bar pushes that value back onto the table as a filter, so the same attribute now drives what you see.