How patent claim charts support licensing review

A claim chart is a two-column table. Left column: patent claim elements, verbatim. Right column: evidence showing how a specific product or system implements each element. That is it. No narrative. No argument. Just the mapping.

A claim chart can focus a licensing discussion by showing the evidence offered for each limitation. Its value depends on the quality and completeness of that evidence.

What makes a chart strong

Each claim limitation should point to a verifiable source, such as product documentation, technical papers, API references, architecture diagrams, published source code, or dated case studies. Inferences should be identified as such rather than presented as facts.

A weak chart says "the system processes blockchain data." A strong chart says "according to the technical documentation published at [URL], the data ingestion layer accepts structured objects from connected blockchain nodes via WebSocket connections, as described on page 12 of the system architecture guide dated March 2024." The second version is hard to dispute because it points to the target's own words.

Element-by-element coverage matters. If evidence supports only five of seven limitations, the chart should show the two gaps rather than imply a complete mapping. Disputed interpretations and weaker evidence should be labeled clearly for counsel to assess.

How patent breadth affects the chart

The '711 independent claim discussed here has seven limitations. That creates fewer rows than the '073 claim, but says nothing by itself about claim strength, validity, or whether the evidence is sufficient.

The '073 claim discussed here has thirteen limitations, including flagging, replacement, and addendum mechanisms. A chart requires evidence for each; exception handling as a general feature does not establish the complete mapping.

The '029 sits in the middle at ten elements. Criteria-based retrieval is the added specificity. For targets that filter blockchain data before processing, the '029 chart adds a layer of coverage that the '711 alone does not capture.

A reviewer may start with the shorter '711 claim and then examine the '029 retrieval or '073 exception-handling limitations where the evidence supports doing so. Each patent remains a separate analysis and does not automatically increase exposure.

Common mistakes in claim charting

Overgeneralizing the evidence. If the claim says "criteria-based retrieval" and the chart says "the system retrieves data," that is not a match. The chart needs to show that the system retrieves data based on specified criteria. The difference matters in claim construction.

Using the patent owner's interpretation without identifying supporting documentation weakens the chart. Separate sourced facts, reasonable inferences, disputed points, and legal conclusions so each can be evaluated on its own.

Ignoring dependent claims. Independent claims get the headlines, but dependent claims add specificity that can be harder to design around. Dependent claims covering report generation, external data sources, API access, and interaction object types map to real product features. Include them.

Why we provide templates

Building a claim chart from scratch is time-intensive work. It requires reading the patent claims carefully, researching the target's published materials, and mapping each element against specific evidence. That is hours of work per target, per patent.

We publish claim chart templates for all three patents at rockinnovationip.com. Each template includes the full claim text, a structured mapping table, and guidance on what types of evidence best support each element. The templates give patent counsel, whether working for us or for the target, a starting point.

Whether you are evaluating a licensing offer or assessing your own exposure, the claim chart is where the real conversation begins. Everything before it is preliminary.