A patent claim chart is a table. Claim language on the left, evidence on the right, one row per element. That is the whole format, and its simplicity is the point — it forces the analysis to be done element by element rather than asserted as a conclusion.
It is the standard work product for infringement analysis, invalidity contentions, IPR petitions, licensing discussions and patent sales. If somebody in patent practice says they have looked at whether a product infringes, the question that follows is whether they charted it.
The structure
| Claim 1 element | Evidence |
|---|---|
| A method for processing data, comprising: | Preamble — see product overview, p.3 |
| receiving a request from a client device; | API documentation v4.2, §2.1: "the endpoint accepts requests from registered clients" |
| parsing the request to extract an identifier; | Same, §2.3, Figure 4 shows identifier extraction |
| querying a database using the identifier; | Architecture whitepaper p.11: "the service queries the primary store by ID" |
| returning a response comprising the queried record. | API documentation §2.6, sample response payload |
One row per limitation. Claims are usually punctuated with semicolons, and each clause between them is a limitation that needs its own row.
Every row must stand alone. A chart is only as strong as its weakest row, because the all-elements rule means a single unsupported limitation defeats the whole analysis.
Cite precisely. A page number, a figure, a section, a line of code, a timestamped screenshot. "The product does this" without a source is an assertion, not evidence, and it is the first thing an opponent will attack.
Infringement charts and invalidity charts
The claim column is identical. Everything else differs.
| Infringement chart | Invalidity chart | |
|---|---|---|
| Right column maps to | An accused product | A prior art reference |
| Evidence sources | Manuals, datasheets, teardowns, source code, specs | Patent text, journal articles, standards, manuals |
| Date logic | Product must be current | Reference must predate the priority date |
| Used in | Demand letters, complaints, licensing | IPR petitions, invalidity contentions |
| Also called | Evidence of use chart, EoU chart | Prior art chart |
An evidence of use chart is an infringement chart under a different name. The term is common in licensing and patent sales because it describes what the document demonstrates — evidence that a product uses the claimed invention.
When selling a patent, the EoU chart is frequently the most valuable document in the package. A patent offered with a chart showing it reads on a shipping product is a different proposition from one offered with a description of the technology. It converts "this patent covers an interesting idea" into "this patent covers what that company is selling right now".
Building an infringement chart
Start from the claims, not the abstract
Read the numbered claims at the end of the patent. The abstract and title are not the invention; the claims are. Charts built from a general understanding of what a patent is about consistently miss limitations that turn out to be decisive.
Chart independent claims first. If an independent claim is not infringed, no claim depending from it can be, because a dependent claim contains every limitation of its parent plus additional ones.
Break the claim into limitations
Most claims are a preamble followed by clauses separated by semicolons. Each clause is a limitation.
Some clauses contain more than one. "Receiving and validating a request" is two things, and charting them together hides whether the accused product does both. Split where the claim language does two jobs.
The preamble may or may not be limiting, depending on whether it gives life and meaning to the claim. Chart it, and note the ambiguity rather than resolving it silently.
Gather evidence
| Source | Strength | Availability |
|---|---|---|
| Published source code | Very strong | Occasionally |
| Technical specifications | Strong | Common for standards-based products |
| Product manuals and datasheets | Strong | Usually public |
| Teardown reports | Strong | Purchasable for consumer hardware |
| API documentation | Strong | Public for most software products |
| Marketing materials | Moderate | Always public, often imprecise |
| Inference from behaviour | Weak | Always available, easily attacked |
Public documentation is worth more than inference. A datasheet stating that the product performs a step is evidence. An argument that it must perform the step because otherwise it could not work is a theory, and the response will be that it works differently.
Preserve what you cite. Web pages change and product documentation is withdrawn. Archive captures with dates, and record when each source was accessed.
Handle the hard limitation honestly
Every chart has one row that is harder than the others. The chart is more credible, not less, if that row is marked as the difficult one with the best available evidence and a note about what would confirm it.
A chart that is equally confident about every row signals that the author did not identify the hard one. Anyone experienced reading charts looks for it immediately, and finding it unacknowledged undermines the rest of the document.
Building an invalidity chart
Same structure, different right-hand column — passages from a prior art reference rather than features of a product.
Date discipline is the first requirement. Confirm the reference predates the effective filing date before doing any mapping. A perfect reference published after the priority date is worthless, and this is the most common error in first-pass invalidity work.
For anticipation, one reference must cover every element. Under 35 U.S.C. 102, a single reference must disclose every limitation arranged as claimed. A chart mixing two references is an obviousness chart, whether or not it is labelled as one.
For obviousness, chart each reference separately and then address the combination. The Board and the courts want to see what each reference contributes and why a skilled person would have combined them with a reasonable expectation of success.
Cite specific passages. "The reference discloses this" with a citation to the whole document is not a mapping. Column and line numbers for a patent, page and paragraph for an article.
See prior art for what qualifies as a reference and how anticipation and obviousness differ.
Where charts are used
| Context | Purpose | Level of detail |
|---|---|---|
| Pre-suit analysis | Decide whether to assert | Complete, internal |
| Demand letter | Make the assertion specific | Often one claim only |
| Complaint | Plead infringement adequately | Varies by district |
| Infringement contentions | Local patent rules require them | Complete, per accused product |
| IPR petition | Map claims to prior art | Complete, precisely cited |
| Licensing negotiation | Demonstrate relevance | Often under NDA |
| Patent sale | Show a buyer the patent reads on something | Complete, as an EoU chart |
Local patent rules in the active districts require detailed contentions early, and a chart that was adequate for a demand letter is frequently not adequate for contentions. Building the complete chart at the outset avoids doing the work twice.
In an IPR petition, mapping quality drives the institution decision. With institution rates having fallen from roughly 65% in October 2024 to about 37% by February 2026, a petition with imprecise mapping is substantially less likely to be instituted than it would have been two years ago.
A worked example: the row that fails
A claim requiring "a processor configured to encrypt the payload prior to transmission". The accused product is a messaging application.
| Evidence considered | Assessment |
|---|---|
| Marketing page: "your messages are secure" | Insufficient — secure is not encrypted, and says nothing about timing |
| Help centre: "messages are encrypted" | Better, but silent on whether encryption precedes transmission |
| Technical whitepaper, p.14: "the client encrypts the payload before it leaves the device" | Sufficient — covers both the act and the ordering |
The limitation has two parts — encryption, and encryption occurring before transmission. The first two sources establish one and not the other, and a chart citing them would fail on cross-examination at exactly the point the defendant chose to attack.
The whitepaper covers both. That is the citation that goes in the chart, with the page number and the date it was retrieved.
Note what happened here. Two pieces of evidence that looked adequate were inadequate for a reason visible only when the limitation was read carefully. That is the work a claim chart forces, and the reason a charted analysis is worth more than an impression.
What makes a chart credible
Precision over volume. A chart citing one exact passage per row is stronger than one citing four vague ones.
A source for every assertion, with enough detail that a reader can verify it independently.
One row per limitation, matching the claim's own structure rather than a convenient summary of it.
Acknowledged weakness. Marking the difficult row and saying what evidence would resolve it.
Consistent claim construction. If a term is being read a particular way, the chart should apply that reading uniformly rather than shifting between rows to make each one work.
Automation and its limits
Tools can accelerate the first pass — locating candidate passages, suggesting mappings, and surfacing documents that might contain relevant disclosure. On a long claim against a large corpus, that saves substantial time.
The judgement remains human. Whether a cited passage actually meets a limitation depends on reading the claim precisely and understanding what the passage describes, and automated mappings submitted without review reliably contain rows that do not survive scrutiny.
The useful division is machine finds, human decides. A tool that narrows ten thousand documents to twenty candidates has done something valuable. A tool whose output goes into a petition unreviewed has created a liability.
Before you send or file a chart
- Chart from the numbered claims, not the abstract or title.
- One row per limitation, split where a clause does two jobs.
- Cite a precise source for every row — page, figure, section or line.
- Confirm dates on every prior art reference before mapping it.
- Identify the weakest row and say so rather than hoping nobody notices.
- Archive every source you cite, with the retrieval date.
- Decide what you are willing to disclose before sharing, because a chart gives away the theory as well as demonstrating it.