A patent claim chart is an evidentiary document that maps the language of a patent claim, limitation by limitation, against a specific target. The target may be an accused product or process in an infringement analysis, a prior-art reference in an invalidity analysis, or a licensee's implementation in a licensing context. A typical chart reproduces the claim language in one column, breaks it into discrete limitations, and places corresponding technical evidence alongside each limitation. A third column may be used to explain the analyst's reasoning where the relationship between the claim limitation and evidence is not self-evident. Evidence may include product documentation, screenshots, teardown photographs, datasheets, source-code excerpts, test results, or technical-standard provisions.The essential feature of a claim chart is element-by-element traceability. It is not enough to state that an accused product has the same general functionality as the patented invention. Each limitation must be connected to evidence showing that the particular product, process, or reference satisfies that limitation. For example, a claim requiring "a processor configured to adjust output gain based on a signal received from an accelerometer" cannot be adequately mapped merely by showing that the product contains a processor and an accelerometer. The evidence must establish the required causal relationship between the accelerometer signal and the processor's gain adjustment.Claim charts serve different purposes in litigation, licensing, and PTAB proceedings, so their evidentiary rigor can differ. In litigation, they support infringement or validity contentions; in licensing, they demonstrate why a prospective licensee's product allegedly practices a patent; and in IPR/PGR proceedings, they may map prior art to challenged claims. Regardless of context, a defensible chart should identify what is confirmed, what is inferred, and what remains unresolved rather than disguising evidentiary gaps with conclusory language.

A patent claim chart should be built as a structured, evidence-based comparison between the limitations of a patent claim and a defined target, such as an accused product or prior-art reference. The process should begin with understanding the scope of the claim and identifying the specific product version, implementation, or reference being analyzed. The objective is not simply to find similar features, but to establish a traceable connection between each claim limitation and reliable evidence.Identify and parse the claim. Break the claim into discrete limitations while preserving the relationships between them. Functional language such as "configured to," "in response to," "based on," or "wherein" may impose additional requirements and should not be overlooked.Review the claim's context and construction. Examine the patent's specification and prosecution history to understand potentially ambiguous or specialized terms. Where claim construction is disputed, document the interpretation being used and its supporting basis before performing the substantive mapping.Define the target precisely. Identify the exact accused product, model, hardware revision, software or firmware version, configuration, or prior-art reference. This prevents evidence from one implementation or version from being incorrectly generalized to another.Collect the strongest available evidence. Prioritize direct technical evidence such as source code, engineering documents, technical specifications, datasheets, regulatory filings, or physical inspection. Depending on the technology, supplement this with controlled testing, reverse engineering, protocol analysis, technical publications, or reliable third-party evidence.Map every limitation individually. For each claim element, identify the corresponding feature, structure, operation, or disclosure in the target and explain why it satisfies the limitation. Evidence for one element should not be assumed to establish another element merely because the two are technically related.Record the evidence precisely. Identify the document, version or date, page or section, figure, test condition, or other location from which the mapping is derived. Where a conclusion depends on inference rather than direct evidence, explicitly identify the inference and its confidence level.Test the chart for gaps and alternative explanations. Look for limitations that are unsupported, weakly supported, or dependent on assumptions. Where possible, consider evidence suggesting a different or non-infringing implementation rather than searching only for information that confirms the initial hypothesis.Perform an all-elements review. Before reaching an infringement conclusion, verify that every required limitation has been established under the applicable infringement theory. A product that satisfies most of a claim does not necessarily infringe if one required limitation remains absent or unsupported.A strong claim-charting process therefore produces more than a comparison table: it creates an auditable chain from claim language to technical evidence to analytical conclusion. The final chart should enable another reviewer to understand exactly how each limitation was mapped, what evidence supports it, where uncertainty remains, and what additional investigation may be required.

A good patent claim chart is precise, evidence-driven, transparent about uncertainty, and easy to audit. It should allow a technically qualified reviewer to move from a claim limitation to the supporting evidence and understand the reasoning without relying on unsupported assumptions. Its purpose is not to make every limitation appear satisfied, but to accurately represent the strength of the evidence for each one.It breaks the claim into meaningful limitations. Each material requirement of the claim should appear separately so that the analysis does not hide a missing element within a broader feature description.It uses evidence rather than conclusions. Instead of writing "the product has the claimed processor," the chart should identify the relevant technical documentation, source-code portion, photograph, test result, or other evidence establishing the processor and, where required, its particular operation.It addresses relationships between elements. If a claim requires one component to operate "based on" another component's output, evidence that both components independently exist is insufficient. The chart should establish the claimed interaction, sequence, dependency, or causal relationship.It uses evidence appropriate to the technology. A semiconductor claim may require die photographs or physical analysis; a software claim may require source code, API behavior, or binary analysis; and a telecommunications claim may require protocol traces or standards documentation. The strongest evidence is therefore determined by the limitation being investigated, not by a fixed charting template.It identifies the exact source and product scope. Citations should identify the relevant document and location and, where applicable, the product model, software version, firmware revision, configuration, and date. This prevents evidence from being detached from the particular implementation it actually describes.It distinguishes confirmed evidence from inference. A limitation directly established by source code should not be presented with the same confidence as a limitation inferred from external behavior. Labels such as "confirmed," "supported by testing," "inferred," or "not established" can make the chart's evidentiary strength much clearer.It contains difficult limitations rather than glossing over them. A professional chart should openly identify the limitation that presents the greatest evidentiary challenge. For example, if a claim requires a particular internal algorithm but only the product's external behavior can be observed, the chart should explain that limitation rather than treating functional similarity as proof of the internal implementation.It is capable of being challenged and independently verified. A reviewer should be able to examine the cited evidence, reproduce relevant testing where appropriate, understand the analyst's reasoning, and identify any assumptions. The chart should also acknowledge credible alternative explanations or non-infringing implementations.Ultimately, the best claim chart is not the one with the most favorable conclusions; it is the one that most accurately exposes the evidentiary position for every claim limitation. In litigation, licensing, or due-diligence work, that transparency makes the chart more useful because it shows both what the evidence establishes and precisely where further technical or legal analysis is needed.

An infringement claim chart maps a patent claim against an accused product, process, or system to determine whether the accused technology practices every limitation of the claim. An invalidity claim chart instead maps the claim against prior art or another invalidity reference to determine whether the claimed subject matter was already disclosed or rendered obvious. Thus, the basic table structure may look similar, but the legal and factual question being answered is fundamentally different.For anticipation under 35 U.S.C. §102, the focus is generally on whether a single prior-art reference discloses every claim limitation before the applicable critical date. Obviousness under §103 is different because an analysis may rely on a combination of references, together with an explanation of why a person of ordinary skill in the art would have combined their teachings. An invalidity chart therefore may need additional analysis explaining the relationship among multiple references and the motivation to combine them.The same claim construction should ordinarily be applied consistently across the analyses. Quietly broadening a claim when charting infringement and narrowing it when charting invalidity creates a methodological inconsistency that can be attacked by an opposing expert. This is particularly important when the same patent is being evaluated for both enforcement and validity: the claim should be constructed once using the appropriate record and then applied consistently to the competing theories.

Element-by-element mapping begins by decomposing the claim into its smallest meaningfully distinct limitations before gathering evidence. This includes not only nouns identifying components but also functional and relational language. For example, "a processor configured to adjust the output gain based on a signal received from the accelerometer" contains at least the processor, the accelerometer signal, and the causal relationship requiring the processor's gain adjustment to depend on that signal. The relationship cannot simply be assumed because the two components separately exist.Each limitation should then receive its own evidence assessment. The analyst identifies the most direct available source, quotes or describes the relevant disclosure accurately, and explains the connection to the claim. Evidence supporting one limitation should not silently be carried over to another. If the evidence establishes that a product has an accelerometer and a processor but does not establish that the processor performs the claimed operation in response to the accelerometer, that limitation remains unresolved.Once elements are enumerated, mapping proceeds limitation-by-limitation against the target, and this is the critical discipline: every limitation must be independently supported. It is not permissible to import evidence from one limitation's row to silently cover a gap in another; if the accelerometer-responsiveness limitation above has no direct evidence, the correct move is to flag it as unmapped or weakly inferred, not to rely on the processor and accelerometer rows being individually strong. The output should let a reader move down the chart term-by-term and see, for each discrete requirement of the claim, exactly what factual basis supports its presence in the target; this traceability is what makes the chart usable as litigation evidence rather than a narrative summary.

Patent infringement analysis generally has two principal stages: claim construction and comparison. First, determine what the relevant claim terms mean based on the claim language, specification, prosecution history, and any applicable claim-construction rulings. Only after the scope of the claim is understood should the analyst compare the properly construed claim against the accused product or process. Reading a patent only according to ordinary-language meanings can produce an incorrect result where the patent specification or prosecution history gives a term a more specific meaning.The second stage is the element-by-element comparison. For an independent claim, the accused product must satisfy every required limitation, either literally or, where legally available, under the doctrine of equivalents. The analysis should therefore be conducted claim-by-claim rather than by concluding that a product "generally practices the patent." A product can satisfy an independent claim but fail to satisfy a dependent claim because the dependent claim adds a limitation that is absent from the product.The conclusion should be expressed at the appropriate level of certainty. Depending on the evidence, the result may be "infringes," "does not infringe," or "insufficient evidence to determine." The last category is important in professional analysis: lack of accessible evidence should not automatically be converted into either infringement or non-infringement. The chart should instead identify the unresolved limitation and specify what additional evidence would be needed to close the gap.

The all-elements rule, also called the all-limitations rule, provides that an accused product or process must satisfy every limitation of the asserted claim, either literally or through a legally recognized equivalent. A product does not infringe merely because it copies the overall concept, performs a similar commercial function, or contains most of the patented features. The missing limitation must be separately addressed.For claim-charting purposes, this means that strong evidence cannot compensate for a completely unsupported limitation. A chart with nine strongly mapped limitations and one missing limitation does not establish infringement of the claim. The tenth limitation remains dispositive unless further evidence establishes it, a legally viable equivalents theory applies, or the applicable claim construction changes the analysis.The same discipline explains why claim charts are structured row by row rather than as narrative comparisons. Each row represents a requirement that must be satisfied. The analyst should therefore avoid "averaging" evidence across the claim and should instead ask, for every limitation: What does the claim require, what evidence establishes that requirement, and is the evidence sufficient under the applicable legal theory?

Mapping begins by identifying the exact accused product embodiment. Product families frequently contain different hardware revisions, firmware versions, software releases, regional configurations, or optional features. A chart that simply refers to "Product X" without specifying the relevant model, version, configuration, and evidence date may incorrectly generalize the findings across products that use different implementations.Once the target is fixed, each limitation is mapped using the evidence class most appropriate to the technology. Mechanical limitations may require CAD drawings, physical inspection, measurements, or teardown photographs. Software limitations may be supported by source code, API documentation, binaries, or observed input-output behavior. Standards-related limitations may be mapped to technical-standard provisions together with evidence that the accused product implements the relevant standard. The evidence strategy should therefore be adapted to the technology rather than forcing every product through the same research process.

Evidence for an infringement chart follows a rough hierarchy of reliability, from strongest to weakest: (1) the accused party's own technical documentation datasheets, API references, service manuals, FCC/regulatory filings (which often include internal photographs and block diagrams not otherwise public), patent filings by the accused party describing their own product, the official product pages, and source code (where accessible through discovery, open-source release, or public repositories); (2) independent third-party technical analysis teardown reports from firms that physically disassemble and test products, standards-compliance test reports, academic benchmarking papers; (3) the accused party's own marketing and user-facing documentation product pages, user manuals, press releases, which are useful for functional claims but weaker for precise structural claims because marketing language is imprecise by design; (4) behavioral/observational evidence the analyst's own testing of the product's inputs and outputs where source code or internals are unavailable; and (5) circumstantial or inferential evidence industry-standard practice, competitor teardowns of similar products from the same supplier, patent filings citing the accused product as prior art or in litigation elsewhere.A defensible chart draws primarily from tiers (1) and (2) and uses tiers (3)-(5) only to fill gaps, with the gap and the resulting confidence level explicitly noted. It is also good practice to actively seek disconfirming evidence, not just confirming evidence, checking whether the accused party's own documentation describes an alternative implementation that would avoid the claim (e.g., a competing sensor architecture, a different substrate material, an off-claim data flow), and addressing that possibility in the chart or methodology memo rather than ignoring it. Charts that read as if the analyst only searched for supportive evidence tend not to survive expert scrutiny.

The search process is target-specific but follows a consistent funnel: start with the manufacturer's own official channels (product pages, spec sheets, developer/API docs, published patents and patent applications by the same company; companies very often patent the exact feature you are trying to prove they practice, which makes their own patent portfolio an underused evidentiary source), then move to regulatory filings (FCC ID search for RF/wireless devices frequently surfaces internal photos and test reports not available anywhere else; medical devices have FDA 510(k) summaries; automotive features often appear in NHTSA or type-approval filings), then to independent teardown and benchmarking outlets (iFixit and similar for consumer hardware, academic and industry benchmark publications for chips and algorithms), and finally to the analyst's own testing where the product is physically or programmatically accessible.For software and cloud-delivered features, evidence-gathering differs meaningfully from hardware: browser/app network traffic inspection, API response inspection, changelog and release-note archaeology (the Internet Archive's Wayback Machine is frequently used to pin down when a feature was introduced, which matters for both infringement timing and prior-art dating), and where litigation posture permits formal discovery requests for source code are the primary tools, since a software feature's 'structure' is often not visible from the outside at all and functional/behavioral testing has to substitute for what a teardown photograph would show in hardware. In all cases, the search should be logged as it happens (source, date accessed, and a saved copy or archive link), because live web pages change or disappear, and an unarchived citation can become unusable evidence months later.

Software and AI claim charts face a structural evidence problem; hardware charts don't: the internal state a claim often recites a specific data structure, a training methodology, a decision boundary, an internal model architecture is frequently invisible from outside the product and not disclosed in marketing material. The practical workaround is a layered evidentiary approach: (1) developer-facing documentation (API references, SDK docs, published research papers by the company's own research team many AI companies publish papers describing exactly the architecture their product uses, which is often the single best source available), (2) open-source components, since many production AI systems are built on published model architectures, published training frameworks, or disclosed fine-tuning techniques that can be matched against the claim even when the exact production weights are proprietary, (3) observed input-output behavior carefully designed test queries that probe for a claimed capability (e.g., testing whether a system's outputs are consistent with a claimed 'personality trait persistence' mechanism by running controlled prompts across sessions), with the important caveat that behavioral testing can show a capability is present but rarely shows the specific internal mechanism the claim requires, so behavioral evidence alone typically supports only a weaker, inference-flagged row.AI and software claims also raise a construction issue that hardware claims rarely do: many software claims are written in means-plus-function or purely functional language ('a module configured to classify...'), which under 35 U.S.C. § 112(f) may be construed as limited to the specific algorithm disclosed in the specification plus equivalents, not any algorithm that achieves the same result. A chart-builder who maps a functional claim term to any product that produces the recited output without checking whether the claim is subject to § 112(f) and, if so, whether the accused product's algorithm is the same or equivalent to the specifically disclosed one risks a chart that overstates the claim's scope. This is a frequent point of dispute in AI patent litigation specifically because so many AI capabilities can be reached by materially different algorithms (rule-based, classical ML, deep learning, LLM-based), and 'achieves the same result' is not, by itself, sufficient for infringement of a means-plus-function claim.

Semiconductor claim charts rely heavily on physical evidence because the claimed structure is usually a literal circuit or die-level architecture, not observable behavior. The evidence hierarchy here typically runs: (1) manufacturer datasheets and application notes, which for many chip claims (pinouts, register maps, bus protocols, power management schemes) are sufficient on their own; (2) die photography and delayering analysis from specialized reverse-engineering firms, which physically strip a chip layer by layer and photograph the metal and diffusion layers to confirm circuit topology this is standard practice in semiconductor litigation and is often the only way to confirm claims reciting specific layout, layer stack, or transistor-level structure; (3) SEM (scanning electron microscope) cross-sections for claims reciting specific material composition, layer thickness, or 3D structure (e.g., FinFET geometry, memory cell stack); and (4) FCC filings and teardown reports, which frequently identify the specific chip part number inside a finished consumer product, letting the analyst then pull that chip's own datasheet or reverse-engineering report rather than analyzing the finished product directly.A recurring difficulty in semiconductor charts is that the same claimed function is often implemented by multiple different suppliers' chips inside product families sharing a brand name (e.g., different SKUs or regional variants of the 'same' consumer device using PMICs or sensor chips from different foundries), so a chart built against one teardown unit's specific chip may not extend to the whole product line. Good practice explicitly identifies the chip manufacturer and part number found in the specific unit torn down, and separately investigates (often via FCC filings for multiple submitted test units, or supply-chain/BOM analysis) whether other units in the same product line use a different chip that might not practice the claim.

Telecom claim charts split into two evidentiary regimes depending on whether the claim reads on a published wireless or network standard or instead covers proprietary, non-standardized functionality. For standard-essential claims, the strongest evidence is the standard specification itself: 3GPP technical specification (TS) documents for cellular technologies, IEEE 802.11 for Wi-Fi, and ETSI specifications for various European telecom standards, combined with a conformance or certification statement (for example, GCF or PTCRB certification for cellular devices, or Wi-Fi Alliance certification) showing the specific product implements the relevant version of that standard. Because standards compliance is typically mandatory for market access and independently verified through formal certification testing, this evidence class is unusually strong and is frequently sufficient on its own, without any further reverse engineering of the physical product.For proprietary telecom functionality, vendor-specific network management features, proprietary quality-of-service schemes, carrier-specific implementations that go beyond what any standard requires, the analyst instead has to build an evidence base from scratch, drawing on vendor technical documentation and datasheets, FCC equipment authorization filings (which frequently include internal photographs, block diagrams, and test reports not published anywhere else), and direct protocol traffic capture and analysis. Packet captures showing actual over-the-air or over-the-wire behavior are frequently decisive for protocol-level claims, since they demonstrate the exact message sequences, field values, and timing the accused product actually uses rather than what its documentation merely claims it does; interoperability and certification test reports from independent labs provide a further layer of corroboration where available.A telecom-specific difficulty worth flagging explicitly in any such chart is that many telecom claims recite a network-side or infrastructure-side element, a base station or core-network function, for instance, alongside a device-side element, which raises divided-infringement questions: no single party may perform every claimed step, since the carrier's network imposes some limitations while the handset or chipset performs others. Charting these claims requires identifying, limitation by limitation, which party device manufacturer, chipset supplier, or network operator is actually responsible for each element, and flagging any limitation performed by a party other than the primary chart target. This matters because it determines which infringement theory is legally available (direct infringement by a single actor, induced infringement, or joint infringement under a direction-or-control theory), and mischaracterizing this allocation is a frequent basis for early dismissal of an infringement claim.

Claim-charting a wireless communication standard involves breaking the patent claim into individual limitations and mapping each limitation to the specific technical requirement, procedure, or parameter defined by the applicable standard. The analyst should identify the exact standard version, then cite the relevant clause, table, figure, or protocol provision and explain how it satisfies each claim limitation. For example, when using the Qi wireless power-transfer standard, a claim concerning communication between a power transmitter and receiver could be mapped to the corresponding Qi provisions governing messages exchanged between those devices and the control of power transfer.The analysis should distinguish mandatory requirements from optional or conditional features, because not every feature described in a standard must be implemented by every compliant product. Finally, the standard-level mapping should be connected to evidence that the accused product actually implements the relevant standard requirements. A strong chart therefore follows the chain: claim limitation, standard requirement, precise specification citation, and product evidence, while recognizing that compliance with a standard does not, by itself, establish infringement of a particular patent.

When source code cannot be obtained (pre-litigation, or against a third party not subject to discovery), the analyst substitutes a triangulated evidentiary approach rather than any single silver-bullet source. Compiled/binary analysis, decompiling publicly distributed application binaries or firmware images, where legally and technically feasible, can recover meaningful structural information (function names, string tables, API call graphs, sometimes near-readable pseudocode from modern decompilers) without requiring the source. Network traffic and API analysis externally observe what data structures and parameters pass between client and server, which can confirm data-flow and architectural claims even without seeing implementation code. Patent filings by the target company describing their own product are, again, an underused resource; companies frequently patent the very software mechanism a chart-builder is trying to prove exists, which converts the target's own patent specification into third-party-quality documentary evidence of their product's internal design.Where none of these close the gap, the fallback is carefully designed black-box behavioral testing: constructing input sequences specifically chosen to distinguish between the claimed mechanism and plausible non-infringing alternatives, and documenting the outputs as evidence of the mechanism's presence. This is inherently weaker than direct code evidence behavior consistent with a claimed mechanism is not proof of that specific mechanism, since a different internal implementation could produce identical external behavior and a rigorous chart says so explicitly, presenting the behavioral finding as 'evidence consistent with, but not dispositive of' the claimed structure, and recommending source-code discovery or expert forensic examination before the chart is relied upon in a litigation filing.

Product documentation is the backbone of most sound claim charts, but it must be used with attention to what kind of document is being cited and what it can actually prove. Datasheets and technical/service manuals describe engineering specifications and are strong evidence for structural and parametric claims (voltages, dimensions, protocol parameters, register behavior). API and developer documentation is strong evidence for software behavioral and data-flow claims. Patent filings by the target company are strong evidence of internal architecture, frequently stronger than the product's own public documentation because patent specifications are written to disclose implementation detail (as required by the enablement requirement) that marketing and even service documentation typically omits. Marketing and user-facing material (product pages, ad copy, user guides) is the weakest documentary tier useful for establishing that a functional capability exists and is offered to users, but rarely precise enough to establish a specific structural or algorithmic limitation, and should not be relied upon alone for claims reciting internal mechanism.Each documentation citation in a chart should specify not just the document but its version and effective date, since manuals and datasheets are revised over a product's life and a limitation supported in a 2024 manual revision may not have been true of the 2021 shipping product; it matters acutely for damages periods and for prior-art dating. Where documentation is ambiguous or uses loose engineering language that doesn't map cleanly onto precise claim vocabulary, the chart should quote the documentation verbatim (within fair-use/quotation limits) alongside the analyst's bridging explanation, rather than silently substituting the claim's own words for the document's; conflating the two is a common way in which analysts unintentionally overstate what the documentation actually shows.

Reverse engineering supplies the evidence needed when public documentation doesn't disclose a claimed internal structure. For hardware, this typically means physical teardown and delayering, stripping a device or chip layer by layer under microscopy to confirm circuit topology, material composition, or mechanical structure. For software, it typically means decompiling distributed binaries or firmware images and conducting behavioral or black-box testing designed to distinguish the claimed internal mechanism from plausible alternatives. For wireless communication claims, it typically means RF and protocol analysis using spectrum analyzers and protocol sniffers to capture and decode actual over-the-air behavior. Its legal status varies by jurisdiction and by method: in the US, reverse engineering a lawfully-obtained product is generally permissible and does not itself infringe the patent or, typically, copyright, though contractual terms (EULAs, terms of service) can separately restrict it for software, and reverse engineering to defeat a technical protection measure can implicate the DMCA's anti-circumvention provisions independent of patent law a chart-builder relying on reverse engineering evidence should confirm the method used was lawful for the specific product and jurisdiction before relying on the resulting evidence in a formal filing.Methodologically, reverse-engineering evidence should be documented with the same rigor as any other lab result: the specific unit examined (serial number, purchase date and source, firmware/hardware revision), the exact procedure used (delayering steps, decompiler and version, test equipment and calibration for RF measurements), and ideally an independent confirmatory pass or a second unit examined, since a single teardown of a single unit is vulnerable to the argument that the examined unit was atypical, defective, or a pre-production sample rather than representative of the accused product line as sold to the public.

Ambiguity in a claim limitation should be resolved through claim construction before mapping, not papered over during mapping. The correct process, mirroring how a court would approach it, looks first to intrinsic evidence: the claim's own language (including parallel usage of the same term elsewhere in the claim set, since claim terms are presumed to be used consistently across a patent), the specification (which frequently defines a term explicitly, or implicitly narrows it through consistent use in describing embodiments a term used only in one specific context throughout the specification is at real risk of being construed narrowly even if its plain English meaning is broader), and the prosecution history (statements the applicant made to the examiner distinguishing prior art can narrow claim scope through prosecution disclaimer, even where the claim language alone would support a broader reading). Only if intrinsic evidence leaves genuine ambiguity should extrinsic evidence technical dictionaries, expert declarations, industry usage be brought in, and even then it cannot be used to contradict a construction the intrinsic record already supports.In practice, when a chart-builder encounters a genuinely ambiguous term (not just a term that requires research to understand, but one where two defensible constructions produce different infringement outcomes), the professional approach is to build the chart under both plausible constructions side by side, or at minimum to state the construction adopted explicitly in a methodology note and flag that the mapping outcome is construction-dependent. A worked example: a claim reciting a sensor 'directly coupled' to a substrate is ambiguous as to whether an intervening thermally-conductive adhesive layer defeats 'directly.' If the specification describes every disclosed embodiment as having such an adhesive layer while calling the coupling 'direct,' that is strong intrinsic evidence that 'directly coupled' tolerates a thin functional interface layer and excludes only intervening structural/mechanical components; a construction a chart should state and support with citation, not assume silently.

Literal infringement exists when the accused product contains, exactly as construed, every element of the claim; the product's structure or method corresponds precisely to the claim language for each limitation. Infringement under the doctrine of equivalents (DOE) applies when a limitation is not literally present but the accused product contains an element that performs substantially the same function, in substantially the same way, to achieve substantially the same result (the 'function-way-result' or 'triple identity' test from Graver Tank & Mfg. Co. v. Linde Air Products Co.), or, under the alternative 'insubstantial differences' test used in some circumstances, where the difference between the claimed and accused element would not have been substantial to a person of ordinary skill in the art. DOE is evaluated element-by-element, not on the invention as a whole; a product cannot escape a missing element by pointing to overall similarity, and equally cannot be found to infringe under DOE merely because it is similar in a general sense if a specific limitation-level equivalence isn't shown.DOE is constrained by several important doctrines a chart-builder must check before relying on it: prosecution history estoppel bars a DOE argument for any claim scope the applicant surrendered during prosecution (e.g., by narrowing a claim in response to a rejection, under Festo Corp. v. Shoketsu Kinzoku Kogyo Kabushiki Co.); the 'all elements rule' still applies to DOE analysis, meaning DOE cannot be used so broadly that it effectively reads a limitation out of the claim entirely (vitiation); and DOE generally cannot be invoked to cover subject matter disclosed in the specification but not claimed (the disclosure-dedication rule). A chart that proposes a DOE theory for a given limitation should therefore include a short prosecution-history check confirming the specific claim scope wasn't surrendered, since asserting DOE against an estopped scope is a well-known and easily attacked error.

A litigation-ready chart meets several standards beyond what a preliminary or licensing-stage chart requires. First, every claim limitation must be mapped with citation-grade evidence sources that could be produced as exhibits and survive an authentication challenge (public documents with capture dates/archive links, purchased and preserved physical units with chain-of-custody notes, lab reports from a source willing to testify or be deposed if needed, rather than evidence that is merely persuasive but not independently verifiable. Second, the chart must satisfy the applicable jurisdiction's local patent rules on timing and specificity (e.g., many US district courts require infringement contentions to identify the accused instrumentality with particularity and to chart each limitation of each asserted claim, not just representative claims, and prohibit later amendment absent good cause) a chart built loosely with the intent to 'fill in gaps later' frequently cannot be supplemented once the contentions deadline passes.Third, it must be internally consistent with the claim construction positions the party intends to advocate at Markman; a chart that implicitly relies on a broad construction of a term the party's own infringement contentions elsewhere argue narrowly (or vice versa for invalidity) creates impeachment material for the opposing expert. Fourth, it should be paired with a methodology memo documenting sources checked, sources rejected and why, confidence level per limitation, and product version/date scope. This becomes important both for expert deposition preparation and because opposing counsel routinely seeks this kind of work product during discovery disputes over chart preparation.Finally, a litigation-ready chart has been stress-tested against the strongest available non-infringement or invalidity counter-argument for each limitation; if the chart-builder cannot articulate what the defendant's best response to a given row will be, that row has not been adequately vetted, regardless of how confident the citation looks on its face.