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. A mapping compares a patent with a product or with another patent, 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. However, a new database doesn't start from zero: 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, and scanning the market for products that might infringe a patent family is another. Reusing an existing database saves the setup, but a verdict only holds for the scope it was made in. A dedicated database keeps that scope clear, so each conclusion is still 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 renewal fees that keep it alive also 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. That means that 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 and assignees are the current owners. Patalyze searches and displays the assignees. 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. That 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:

For example, a freedom-to-operate search for solid-state cell packaging might 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 in their numbers, 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. Attributes sit right under the title, and inside a database they also list every product or patent the patent is charted against, with the score of each charted claim. 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 has its own section right under the claims, which opens on the first paragraphs and shows how many remain. Its paragraphs are numbered the way the patent office numbers them, and "Open as 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 include 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 as 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, there is more you can do with a patent once it is open:

• 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.
• See what it already reads on: every product it is charted against has its own row among the attributes, with a badge per claim showing its score. Click a claim and the comparison opens right there, and from there you can open it as a page or in the panel beside the record. We cover mappings in full below.
• 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. With a good description, Patalyze can judge how a claim reads against the product. With a thin one, it is left to guess.

Patalyze reads a product in two layers. The product doc holds the substance of a single product, such as descriptions, diagrams, datasheets and captured pages, as blocks that Patalyze reads in depth. 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. If you already have the source material for a product, type or paste a description, then drop in PDFs and images such as specifications, brochures, datasheets and 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. It is also the single source that every mapping against the product 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.

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

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 can add any others from the column picker on a table. On the product page, every patent charted against the product also gets its own row among the attributes, with the score of each charted claim.

The attributes 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 sort the products in a database into kinds, so the product under analysis sits among its peers when you filter and group on tables and dashboards. You can edit any of these attributes 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 target, worked through claim by claim. The target is usually a product: 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. The target can also be another patent. In that case, the same chart reads the patent's claims against that reference's description, claims and figures, which is how a prior-art search ends: one invalidity chart per reference, each element cited to the paragraph that discloses it.

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 claim reads on a product. 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, so you can see at a glance how it reads. The cell plainly ships in the laminated pouch the claim ends on. It most likely has the solid-state stacks and the frame around them, though the datasheet stops short of saying so. However, 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.

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 or reference:

• 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 a patent you hold reads on someone else's product.
• 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.

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.

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 element 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.

Dependent claims work a bit differently. A dependent claim includes every element of the claim it refers to, so the agent marks the words that point to that claim, e.g. "the device of claim 1", as a claim reference. The score then counts the elements of both charts, i.e. the present elements of claims 1 and 2 divided by all counted elements of both, and a chain such as claim 3 on claim 2 on claim 1 adds up the same way. When a claim refers to several claims, e.g. "any one of claims 1 to 3", the referenced claim with the highest score counts. In the chart you see the reference underlined with that claim's score next to it, and clicking it opens the referenced chart.

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 that matters most: a patent that reads on your product, is in force and is owned by someone else. Patents in the lower bands are the ones 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. the product PDF, opened 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. Nothing is charted until you ask, since charting every patent against every product is rarely what you want. 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.

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 target too, picking another product or patent from the database or mapping the same claim to a new product. If you no longer need a chart, More... > Delete on the mapping page removes it together with the claim's score. 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 its target intersect, so a whole field of comparisons reads at a glance and the dangerous claims stand out by color. A product column on a patent table charts every row against that product. A patent column, on either table, charts that patent against every row. On a table of search results, that turns the rows into the prior art the patent is read against.

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 as 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, so you can 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 name and websites 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. Because the options belong to the attribute, renaming an option changes it on every record. Everything below is about custom attributes.

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 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" sits at the top of it and 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, at the bottom of the edit form, 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 under its title, 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. The agent 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. Add a filter from the toolbar, or open the attribute's header menu to filter by it directly. 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. 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.