What vs. How: 10 Overlooked Evidence Sources That Make or Break an Infringement Claim Chart
Marketing pages tell you what a product does. These lateral sources prove how it does it, where claim charts are actually won.
A patent infringement claim chart or an evidence-of-use (EoU) chart lives or dies on one thing: how convincingly each limitation of a claim is mapped to something the accused product actually does. And this is where most charts quietly weaken. The evidence closest to hand is almost always the evidence a company wants you to see: the datasheet, the marketing page, the feature comparison. Those materials are excellent at telling you what a product does. They are almost useless at proving how it does it, the parameter that gets passed, the sequence of operations, the handshake on the wire, the module soldered to the board. "How" is exactly what a claim limitation describes, and "how" is where a chart becomes defensible instead of merely plausible.
The good news is that the "how" is rarely as hidden as it seems. It leaks, into developer documentation, into open code, into standards a product must comply with, into the packets it sends. Below are ten lateral evidence sources that experienced searchers mine when the obvious materials run out. We have grouped them into four families, because the real skill is not knowing the list, it is knowing which family answers the limitation in front of you, and how far each source can be trusted.
Implementation-level sources: how the system really operates
This first family is the closest thing to reading a product’s mind. These sources are written by engineers for engineers, so they expose logic rather than message. When a limitation turns on a specific operation, a request format, a called function, a configuration state, this is where you look first.
1. API documentation
API docs often give the most direct view of how a system truly operates. Unlike marketing content, they expose actual parameter flows, request structures, and response behaviours that reflect backend logic, and those frequently align, almost word for word, with claim limitations. A limitation reciting "transmitting a request comprising an authentication token and a resource identifier" is often provable straight from an endpoint’s documented request schema. Capture the versioned doc page (and its date), because APIs change; a limitation you prove today may read differently after the next release.
2. SDKs and developer guides
Where an API reference shows the interface, an SDK shows the implementation. Developer guides bundle sample code, setup parameters, and integration workflows that expose the exact sequence of operations behind a claimed method — invaluable for charting procedural or method claims, where the order of steps is itself a limitation. SDKs bridge the gap between design intent and real-world execution.
3. GitHub and open-source repositories
When any part of a product is open-sourced — or depends on a public library — the code itself becomes evidence. Commit histories, issue logs, and code snippets expose algorithms, file flows, and process handling that map directly to claim steps, and the commit timestamps double as dating evidence. Open code makes hidden functionality visible. Treat contributor identity and repository ownership carefully, though: a public repo proves how that code works, not automatically that the shipped commercial product uses it.
4. Cloud platform and service configuration pages
For products built on AWS, Azure, or Google Cloud, the provider’s own configuration and service documentation reveals backend structure and logic. Configuration options, orchestration flows, and runtime triggers map to claimed system behaviors and often expose architectural detail a vendor would never publish itself. Configuration options expose how the cloud really runs.
Physical and runtime proof: turning claims into observable facts
The second family answers a tougher challenge: a limitation that a defendant can simply deny. Documentation can be dismissed as aspirational; physical teardown and live traffic cannot. These sources convert an abstract assertion into something an expert can point at.
5. Product teardown and reverse-engineering reports
Hardware teardown reports reveal what is actually inside a product, undeniable evidence of component integration and functionality. Independent analyses from firms like iFixit, or from teardown and reverse-engineering houses, expose circuit layouts, chip identifiers, and module interconnections that link directly to physical claim elements ("a processor coupled to a wireless transceiver…"). Teardowns bridge the gap between documentation and physical proof, which is why they carry weight even against a resistant opponent.
6. Network captures and handshake analysis
Packet captures show what a product actually does at runtime. Tools like Wireshark or tcpdump reveal protocol flows, message exchanges, and state transitions that align directly with claimed operations, the digital equivalent of catching the behavior in the act. For a limitation describing a sequence of messages or a specific handshake, a capture turns an abstract claim into observable proof. Preserve the capture conditions (device, firmware, timestamp) so the evidence is reproducible.
Mandated behavior: when a standard dictates the "how"
7. Industry standards and interoperability specifications
Some of the most powerful evidence is behavior a product has no choice but to exhibit. Standards define how compliant products must operate. If a product claims IEEE, 3GPP, or ISO compliance, its implementation inherently follows the procedures those standards prescribe, so a limitation that mirrors a mandatory step in a standard can be charted through the compliance claim itself, without needing to crack open the device. Compliance links claims to implementation. This is the backbone of standard-essential patent (SEP) charting, and it is often the single strongest lateral source when it applies: the vendor’s own compliance badge does the work for you.
Contextual and temporal evidence: what existed, when, and how it behaves in the wild
The final family fills gaps the others leave: establishing a date, surfacing behavior no vendor documents, and previewing technology before it ships. These are powerful but also the most variable in reliability, which makes disciplined handling essential.
8. Archived web data and Wayback Machine snapshots
Archived pages capture how a product or feature existed during a specific time frame, even after the content has been modified or removed. That makes them the go-to source for the "what existed when" question that anchors both infringement timelines and damages periods. A word of caution familiar to anyone who has read our work on prior art: an archived snapshot proves technical existence, not automatically legal public accessibility, and its evidentiary weight is strongest when paired with authentication (for example, an Internet Archive affidavit) and corroborating sources. Used carefully, archived data preserves evidence of what existed when.
9. Product review discussions on Reddit, forums, and community boards
User discussions often expose real product behavior. Power users and testers share insights on internal functions, edge cases, and performance details that never make it into official documentation, sometimes with screenshots or logs attached. Real users reveal what official docs don’t. Treat these as leads to be corroborated rather than standalone proof: a forum post is a signpost pointing you toward primary evidence, and it is at its best when it surfaces an artifact (a config dump, a debug log) you can then verify independently.
10. Technical conference papers and open research
Research papers often preview real product implementations. Publications from IEEE, ACM, or arXiv reveal algorithms, architectures, and design flows later used in commercial products, especially when authored by engineers at the accused company itself, which ties the disclosure directly to the product. Research reveals product DNA before release, and the peer-reviewed, dated, and indexed nature of these papers makes them unusually clean evidence compared with most web sources.
From ten sources to one defensible chart
Knowing the sources is the easy part. The craft is in three moves that separate a chart that survives scrutiny from one that invites a rebuttal.
- Match the source to the limitation. An implementation-level source for a "how" step, a physical or runtime source when the opponent will deny it, a standard when compliance is claimed, a temporal source when the fight is about dates. The right family is faster and far more persuasive than forcing one source to answer everything.
- Layer evidence, don’t stack it. The strongest limitations are proved twice, an API doc corroborated by a network capture, a forum tip confirmed by open code. Independent sources that agree are much harder to dislodge than three variations of the same document.
- Weigh reliability up front. Standards and peer-reviewed papers are clean; archived pages and community posts need authentication or corroboration before they carry weight. Grading each source’s reliability as you build, not after a challenge, is what keeps a chart defensible.
Surface materials tell you a product exists. Lateral evidence proves how it works — and a claim chart is only as strong as the “how” behind each limitation.
Where iCuerious comes in
Mining these lateral sources, and knowing how far each one can be trusted, is the difference between a claim chart that reads well and one that holds up. For over a decade, iCuerious has built evidence-of-use and infringement charts that map every limitation to reliable, corroborated proof, drawing on exactly the sources above. If you are building a chart, evaluating a licensing target, or stress-testing evidence you already have, we would welcome the conversation.
Talk to the iCuerious evidence team → www.icuerious.com
