Most patent assertions start with what is publicly available. An analyst pulls the accused product’s datasheet, product page, technical manual, or standards documents, maps what they describe against the patent’s claims, and builds a claim chart. At that stage the chart can look complete: every claim limitation, meaning each separate requirement the claim sets out, has a citation next to it.
Then the other side asks one question.
“How do you know the accused product actually implements the feature the way you have mapped it?”
That question separates two kinds of infringement position. One says the product appears to perform the claimed function, based on what its manufacturer has published. The other says the product was examined and the claimed feature was found implemented in a specific way. This article sets out a patent infringement analysis methodology for deciding when the first is enough, when to move to the second, and how to scope that move so it stays proportionate to what is actually in doubt.
Key Takeaways
- A paper-based claim rests on what the manufacturer chose to publish. An evidence-backed claim rests on what the product was observed to contain or do.
- Public documents often describe the result a product achieves. Many claims require a specific mechanism, and documents rarely show it.
- Product-level investigation should be driven by the claim: sort each limitation by how well it is supported, and investigate only the ones the public record cannot answer.
- A negative test result has value too. It removes a weak theory before the counterparty finds it.
- Evidence does not guarantee a licence. It stops the negotiation from stalling on whether the implementation was ever established.
Paper-Based vs Evidence-Backed: The Two Kinds of Infringement Claim
A paper-based infringement claim relies on public information: datasheets, specification sheets, application notes, user manuals, marketing materials, regulatory filings, and standards documents. It can still be detailed and careful. A good paper-based infringement analysis may include full claim charts, several technical references per limitation, and close reading of the accused product’s documented capabilities.
An evidence-backed claim ties individual claim limitations to the product itself. The method depends on the technology. For a semiconductor device, that can mean a teardown followed by delayering, where the chip is ground back layer by layer, and microscopy of the exposed structures. For a communications product, it can mean electrical measurement or protocol capture, which records the messages a device actually sends. For software, it can mean source code review where access is available, or analysis of the running application.
The difference lies in the source of the evidence rather than its volume. A paper-based position establishes what the manufacturer says about its product. An evidence-backed position establishes what the product contains or does. Under the basic rule of patent infringement, every element of at least one claim has to be found in the accused product, so the gap between those two sources becomes the gap a defendant will aim at.
Why Public Documentation Feels Sufficient
Patent owners start with public documents for good reason. A product page may describe a feature in words that closely track the claim language. A datasheet may name the relevant architecture. A manual may supply enough detail to cite something against every limitation. After technical and legal review, the resulting chart can look persuasive, as Figure 1 shows.
Patent Infringement Examples: Where Paper-Based Mapping Breaks Down
The same four failure modes come up repeatedly once a paper-based position meets resistance. Figure 2 summarises the documentary limits behind them.
The Document Shows the Result, Not the Mechanism
Suppose a claim requires a particular relationship between two circuit elements. The product literature confirms the device performs the relevant function but says nothing about how the circuit is built. The mapping works at the functional level. When the counterparty asks what evidence shows the claimed structure, a chart built from product literature has nothing to point to. This gap is widest where several different designs could produce the same outward behaviour.
The Chart Maps a Product Family, Not the Accused Configuration
A datasheet may cover several variants, operating modes, or revisions. A chart can cite a feature documented for the family while the specific accused unit uses a different implementation. Once the counterparty asks which SKU, die revision, firmware version, or configuration the chart addresses, a family-level mapping may no longer hold.
The Product Changed After the Document Was Published
Documentation does not always keep pace with the product. A manufacturer can revise a circuit, swap a component, update firmware, or move to a different process while keeping the same product name and outward behaviour. The documents may still be accurate about what the product does while no longer describing how the current version does it.
One Unsupported Limitation Becomes the Whole Argument
A broad technical narrative holds until the counterparty isolates one element. If a critical limitation rests on an inference that nothing independent supports, the discussion moves away from the overall strength of the claim and onto that single gap. This is the practical difference between a plausible mapping and a defensible one. For more on how weak chart cells fail under attack, see how claim chart quality changes litigation outcomes.
Product Mapping in Patent Infringement: A Claim-Driven Methodology
Check out our Claim Charts Services
Product mapping in patent infringement means comparing each claim element against the accused product to find evidence that the element is present. The methodology below keeps that work proportionate. Public research does the screening, and deeper technical work goes only where the public record runs out.
Step 1: Sort Every Limitation by Evidence Type
Start by grading each claim limitation on the evidence behind it:
- established directly by public documentation
- supported by several independent technical sources
- reasonably inferred from documented architecture
- requires confirmation through product behaviour
- not yet supported by any current evidence
The last two categories are where product-level investigation earns its cost. The first three usually do not need it.
Step 2: Cross the Line Only Where the Public Record Stops
Imagine a ten-element claim. Eight elements have strong public support. The ninth depends on an internal processing step the manufacturer never describes, and the tenth depends on how two internal components interact. Collecting more product pages will not help with those two, because the information was never published. More documents of the same kind add volume without adding evidence.
This is the point to change the type of evidence being collected. Depending on the limitation, that can mean reverse engineering, controlled product testing, firmware analysis, signal measurement, API monitoring, or network traffic inspection. The claim decides the method. If a claim requires a system to change a parameter when a set condition occurs, the test is to create that condition and watch whether the parameter changes as claimed.
Step 3: Replace Inferences With Observations
A paper-based mapping often contains a statement like this:
The product uses component A and component B, and therefore likely performs the claimed interaction.
That is a reasonable hypothesis. Product-level investigation can replace it with something like this:
Under the specified test condition, component A generated the observed signal, which component B then received and processed.
The first statement connects known facts through an inference. The second records an observed event. Testing does not settle infringement on its own, since the legal conclusion still depends on claim construction and the evidence as a whole, but it adds a layer of fact the counterparty has to address directly.
Step 4: Record the Evidence Chain
Product-level findings are only useful if a reviewer can follow them back to the claim. Each one should sit in a traceable chain:
Claim limitation → technical question → investigation method → observed behaviour → supporting artifact → claim chart entry.
The artifact might be a test result, a captured output, a protocol trace, a measurement, or a log. Record the model number, hardware revision, firmware version, configuration, operating conditions, and test date alongside it. That record defines exactly which product the evidence covers, which is what answers the product-family and version challenges described above.
Step 5: Treat a Negative Result as a Finding
Investigation tests an infringement theory in both directions. If testing shows a limitation is not implemented, the patent owner can move to a different product, a different configuration, or a revised mapping, or decide the target is not worth pursuing. Finding that out under controlled conditions costs far less than having the counterparty’s engineers find it during a negotiation.
How Evidence Changes the Licensing Negotiation
The difference shows most when the counterparty’s technical team joins the discussion. Against a paper-based position, they challenge a limitation and ask for more evidence. The patent owner then has to go back, run more analysis, or revisit its reading of the claim before replying, and the negotiation stalls while both sides argue about what the product literature means.
An evidence-backed position gives the counterparty a specific technical finding to rebut. They can still dispute the interpretation or propose a different implementation theory, but the argument is now about observed facts. In practice that tends to produce:
- faster technical responses, because fewer evidentiary gaps need filling after the first assertion
- earlier commercial discussion, since less time goes on relitigating basic technical questions
- more credibility with the counterparty’s engineers, who have something concrete to evaluate
- better readiness if the matter escalates from business teams to technical experts
Evidence quality also carries through to value. How a patent reads on a product shapes both licensing terms and, if the matter reaches court, damages for patent infringement. Our guide to patent valuation analysis explains how product-to-claim mapping feeds royalty and damages models, and an IP damages expert building an intellectual property damages opinion will rely on the same mapping. See Lumenci’s expert witness services for how that testimony is supported.
Some forums build the expectation into their rules. A complaint at the US International Trade Commission must show infringement, where practicable, with a chart applying each asserted independent claim to a representative accused article, together with photographs, drawings, or other visual representations of that article labelled to read against the chart, under 19 C.F.R. § 210.12.
When Paper-Based Analysis Is Enough
examining the product internally adds little. For some standards-based claims, the required implementation is public and specific enough to support a strong mapping without opening a particular device.
Commercial context counts as well. If the counterparty already accepts the technical position and is ready to discuss a licence, spending on more evidence first may not make economic sense. The useful question is what uncertainty remains in the position, and whether resolving it is worth the cost. A paper-based analysis is often the right first stage. The error is treating a completed claim chart as proof that every material implementation question has been answered.
When Paper-Based Analysis Is Enough
Product-level investigation is not needed for every assertion. If the infringing behaviour is visible from the outside, examining the product internally adds little. For some standards-based claims, the required implementation is public and specific enough to support a strong mapping without opening a particular device.
Commercial context counts as well. If the counterparty already accepts the technical position and is ready to discuss a licence, spending on more evidence first may not make economic sense. The useful question is what uncertainty remains in the position, and whether resolving it is worth the cost. A paper-based analysis is often the right first stage. The error is treating a completed claim chart as proof that every material implementation question has been answered.
When Paper-Based Analysis Is Enough
Product-level investigation is not needed for every assertion. If the infringing behaviour is visible from the outside, examining the product internally adds little. For some standards-based claims, the required implementation is public and specific enough to support a strong mapping without opening a particular device.
Commercial context counts as well. If the counterparty already accepts the technical position and is ready to discuss a licence, spending on more evidence first may not make economic sense. The useful question is what uncertainty remains in the position, and whether resolving it is worth the cost. A paper-based analysis is often the right first stage. The error is treating a completed claim chart as proof that every material implementation question has been answered.
How Lumenci Takes an Infringement Position From Paper to Product Evidence
The decision this article describes, which limitations to investigate and how, is where most of Lumenci’s infringement work starts.
- Limitation-by-limitation triage: our analysts grade each claim element by its evidence before any lab work is scoped, so reverse engineering and testing budgets go only to the limitations the public record cannot support.
- Method matched to the claim: teardown and die-level imaging for hardware structure, protocol capture for communications behaviour, and source code review for software, chosen by what each limitation requires.
- Version-locked evidence: every finding is recorded against a specific model, revision, firmware build, and test condition, which closes off the product-family and outdated-document challenges.
- Charts built on observation: findings flow into claim charts as traceable evidence chains that a testifying expert can walk through.
In an HDMI-CEC matter before the ITC, this approach combined source code review, firmware analysis, and more than 50 targeted device test iterations to produce reproducible evidence of how the accused streaming and television products practised three asserted patents. That evidence supported the client’s successful effort to obtain an injunction.
Talk to Lumenci about testing the evidence behind an infringement position.
Trying to Prove Infringement in a Consumer Device?
In a case involving HDMI-CEC technology, Lumenci reviewed the source code and tested the devices to build the infringement evidence.
Conclusion
Public documents are the right place to start an infringement analysis. They identify products, explain architectures, and support preliminary mappings quickly and cheaply. When a material limitation depends on an implementation detail the manufacturer never published, more desk research stops producing new evidence.
The patent infringement analysis methodology that holds up under negotiation follows a simple order: public evidence finds the opportunity, claim analysis finds the gap, targeted investigation tests the gap, and the claim chart records what was found. For portfolio-scale screening before that work begins, iLumOS, Lumenci’s expert-powered AI platform, flags the products and claims worth taking through it.
Table of Contents
Frequently Asked Questions
What is a patent infringement analysis methodology?
It is a structured process for comparing a patent’s claims against an accused product and deciding what evidence supports each claim element. A sound methodology starts with public documents and moves to product-level investigation only where those documents cannot answer a material question.
What is product mapping in patent infringement?
Product mapping compares each element of a patent claim against the accused product to identify evidence that the element is present. The result is usually recorded in a claim chart.
What is the difference between paper-based and evidence-backed infringement claims?
A paper-based claim relies on public materials such as datasheets and manuals. An evidence-backed claim ties claim limitations to what the product was observed to contain or do, through teardown, testing, protocol capture, or source code review.
When is public documentation enough for infringement analysis?
When the infringing behaviour is visible from outside the product, when a public standard defines the implementation precisely, or when the counterparty already accepts the technical position and further evidence would not change the outcome.
Can product testing prove patent infringement?
Testing produces factual evidence about how a product behaves under defined conditions. Whether that behaviour meets the claim still depends on how the claim is construed and on the evidence as a whole.
Why record the product version in an infringement analysis?
Products change through hardware revisions and firmware updates while keeping the same name. Recording the model, revision, firmware build, and test date defines exactly which product the evidence covers, which answers the most common challenge to a paper-based chart.
