Software patents rarely fail or succeed on product screenshots. They turn on what’s actually running underneath, and the only reliable record of that is the source code itself. This is what makes patent infringement analysis in software disputes fundamentally different from infringement analysis in mechanical or chemical patents: the evidence isn’t visible until an expert opens the codebase. As of mid-2024, software-related utility patents accounted for approximately 61.0% of all grants in the United States.
Getting a forensic finding is one problem. Turning that finding into an argument that survives a Markman hearing, a Daubert challenge, and cross-examination is another, and that’s the gap this piece addresses.
Key Takeaways
- Patent infringement analysis in software cases depends on source code discovery, but the protective order governing that discovery often determines what’s even possible to find.
- The Abstraction-Filtration-Comparison test applies to copyright disputes, not patent infringement; conflating the two weakens claim construction arguments.
- Chain of custody and FRE 702/Daubert compliance decide whether a forensic finding is admissible at all, independent of its technical accuracy.
- Willful infringement analysis post-Halo Electronics now turns on the defendant’s state of mind, not just pre-suit knowledge.
- SSPPU-based damages models require tight alignment between the technical discovery and the economic expert’s apportionment theory.
Why Patent Infringement Analysis Depends on Source Code
Forensic source code analysis is a structured review of code to uncover, document, and explain evidence relevant to legal disputes. By linking technical implementation details to patent claims, it gives IP counsel a reliable basis for discovery, depositions, and trial.
This analysis often begins before filing. Under Rule 11, a plaintiff must conduct a reasonable pre-suit investigation to support infringement claims. A software expert may review visible product features, map them to patent claims, identify possible infringement, and flag prior art under § 102 or § 103. Engaging the expert early as a consulting expert can also help protect work product while assessing case viability.
The forensic analyst’s inquiry centers on literal infringement and the doctrine of equivalents. Source code review can show literal infringement by matching claim elements to modules, functions, or execution paths. It can also support infringement where the product performs substantially the same function in substantially the same way to achieve the same result, despite nonmaterial code differences.
Source Code Discovery: Protective Orders and Secure Environments
Source code discovery is one of the most sensitive phases of patent litigation because the code often represents a company’s most valuable IP, its “crown jewels”. Courts and litigants therefore negotiate restrictive Protective Orders (POs) that govern access, handling, and presentation.
A strong protective order sets the limits of technical discovery and can determine whether claim mapping is practical. To reduce disclosure and trade secret risks, defendants often require review on a standalone, non-networked computer in a secure room, usually at outside counsel’s office. Sandboxed virtual machines further prevent file extraction or internet access.
Read More: Source Code Review in Patent Litigation: Best Practices for Attorneys & Experts in 2026
Forensic Methodologies Behind Patent Infringement Analysis
Forensic source code analysis combines static and dynamic methods to build a defensible technical narrative. Static analysis examines code without running it, helping experts identify structure, dependencies, logic flows, and modules tied to patent claims. Analysts use specialized tools to generate call graphs and dependency lists.
Functional Alignment and Claim Mapping
A core task is creating claim charts that map specific lines of code directly to each asserted claim limitation. This requires translating the patent’s functional language into the software’s actual implementation.
Dynamic Analysis and Behavioral Verification
Dynamic analysis shows what code does at runtime. By running the software in a controlled environment, experts can observe behaviour under specific conditions and verify low-level algorithms and backend logic that may not appear through surface testing. This helps confirm whether the software is literally or functionally equivalent to the claimed invention.
Analysts also investigate version control systems to trace the first appearance of a patented feature, which can be critical to damages. Commit logs, authorship records, and branch histories help show when a feature appeared or changed and whether it predates the patent priority date.
The AFC Test: Why It Doesn’t Apply to Patent Infringement Analysis
It is critical to distinguish between copyright and patent frameworks in software litigation. The Abstraction-Filtration-Comparison (AFC) test is most notably established in Computer Associates v. Altai case. This is a doctrine utilized specifically in copyright infringement cases to determine whether non-literal elements of computer programs are protectable.
While it is often discussed in broader software IP debates, characterizing AFC as a patent infringement framework is inaccurate. Patent infringement analysis is governed by claim construction (Markman hearings) and the comparison of accused products against the claims of the asserted patent, distinct from the copyright-based filtration of ‘ideas’ versus ‘expression.’ Relying on AFC in a patent context risk conflating two fundamentally different regimes of intellectual property protection.
Specialized Tooling for Source Code Discovery
Because modern applications can contain millions of lines of code, manual review alone is often impractical. Forensic experts therefore rely on professional tools that can manage large datasets while preserving evidence integrity and supporting a repeatable, defensible process.
Static Analysis and Code Search
For large-scale searching and logic tracing, analysts often utilize robust utilities such as WinGrep and PowerGREP for complex queries across thousands of files. Visual Studio and Notepad++ support navigation and line tracking, while command-line tools like Cygwin enable batch processing. SciTools Understand helps visualize call flows and dependency graphs for claim mapping.
Software Composition and Plagiarism Detection
In code theft or unauthorized reuse disputes, tools such as CodeSuite and CodeMatch detect matches even when names or signatures are changed. They compare files across codebases and rank results by the amount of matching code. SourceDetective and BitMatch help rule out coincidental similarities from third-party libraries or compare source code with executable binaries.
Software Composition Analysis (SCA) tools, such as Black Duck, are increasingly important in patent cases to identify open-source software components. Because much of modern code originates from open-source projects, these tools help parties determine whether an accused feature derives from a third-party project with a permissive license and generate a software bill of materials that highlights dependencies and potential license conflicts. A defendant may also use SCA results to support non-infringement or license-compliance arguments.
Obfuscation and Admissibility
Bad actors or competitors seeking to conceal infringement often employ obfuscation techniques to hide their tracks. Obfuscation systematically transforms source code into a form that is beyond human readability while maintaining the application’s functionality. For forensic analysts, detecting and reversing these transformations is a high-priority challenge.
Obfuscation usually falls into three main categories:
- Layout Obfuscation: Changes how code looks without changing how it works, such as renaming identifiers, removing comments, or altering spacing and formatting.
- Data Obfuscation: Hides how data is stored or processed using techniques like encoding, instruction substitution, or mixed Boolean arithmetic.
- Control Flow Obfuscation: Hides the program’s logic using methods such as control-flow flattening, junk code, dummy branches, or opaque predicates that always resolve the same way.
Forensic analysts evaluate obfuscation based on its potency, resilience, and cost, reflecting the difficulty it introduces for human analysis, automated tools, and system performance. Countering it requires strong knowledge of compiler theory and advanced de-obfuscation tools that can reveal the program’s underlying logic.
The Patent Claim Mapping Expert Witness: Role and Litigation Timeline
The software expert witness connects dense source code to the legal arguments presented to the court. These experts typically combine experience in computer science, software development, and digital forensics.
Explore Lumenci’s Expert Witness Testimony Service
Pre-Complaint and Discovery Phases
In the pre-complaint phase, the expert evaluates case strength and refines infringement contentions. During discovery, the expert reviews produced source code in a secure environment and identifies key evidence such as forked code, API calls, and hidden algorithms.
Claim Construction and Markman Hearings
During claim construction, usually six to nine months after filing, the expert clarifies the technical meaning of disputed terms. Phrases like “data processing unit” or “machine learning model” need context so the court’s interpretation aligns with industry practice and the patent record. These declarations help avoid overly broad or narrow interpretations.
Expert Reports, Depositions, and Trial
The forensic review culminates in an expert report that translates technical findings for judges and juries. It must be accurate, persuasive, and supported by traceable evidence. After submission, the expert faces a deposition and must defend the methods and conclusions under cross-examination.
At trial, the expert acts as a technical educator, explaining key code segments and linking them to claim limitations with clear visuals, call graphs, and annotated snippets. Explaining complex functionality in plain language without losing technical credibility can strongly influence the outcome.
Chain of Custody: Ensuring Admissibility in Patent Infringement Analysis
The validity of forensic source code findings depends on reliable evidence handling. Chain of custody records the collection, control, transfer, and analysis of digital evidence to show that the source code reviewed is authentic and unchanged. For electronically stored information, this usually requires verified copies, recorded details such as date, time, source, and custodian, and a complete log of each transfer, analysis step, and exhibit use. To be admitted as expert testimony, the findings must also satisfy Federal Rule of Evidence 702 and the Daubert factors.
Case Studies: Source Code Forensics in Patent Infringement Analysis
These landmark disputes show how source code can become the pivotal evidence in software litigation.
Oracle v. Google: Declaring vs. Implementing Code
The Oracle v. Google case highlighted the distinction between declaring code and implementing code. Although the Court found Google’s copying of 11,500 lines of declaring code to be fair use, the case set important forensic boundaries for API reuse.
License Compliance and OSS Enforcement
Forensic analysis is central to enforcing open-source license obligations. In Sebastian Steck v. AVM, it showed that the company released source code but not the scripts needed for compilation and installation under the LGPL. In Entr’ouvert v. Orange S.A., forensic findings helped secure nearly €1 million in damages after Orange distributed modified GPL-covered code without meeting source-code requirements.
Philips v. HTC: Tracing Functional Differences
In Philips v. HTC, forensic experts reviewed HTC’s Java source code to trace functional differences across versions. By mapping functions to patent claims, they identified flaws in Philips’ infringement contentions and supported HTC’s non-infringement defence.
AI, Distributed Systems, and the Future of Patent Infringement Analysis
As software evolves, forensic source code analysis faces new challenges from AI coding tools and distributed systems. Tools like GitHub Copilot and ChatGPT can generate code without clear license context, raising IP risks and making source tracing harder. Cloud-native and microservices architectures also spread code across containers, virtual machines, and remote platforms. Although AI can help spot patterns and threats, legal and technical compliance still depends on human experts using reliable methods.
Legal Frameworks Shaping Patent Infringement Analysis: Alice, Halo, SSPPU, and PTAB Strategy
Navigating §101 Eligibility (Alice v. CLS Bank)
The Alice two-step test remains the primary hurdle for software-based patent assertion. Litigation strategies must now aggressively front-load eligibility arguments. We emphasize not just that an invention is a “software improvement,” but that it solves a specific technological problem such as improving network throughput or reducing latency, rather than merely automating a business process. Documentation must demonstrate how the claimed invention transforms an abstract idea into a concrete, patent-eligible technical solution.
Wilful Infringement and Enhanced Damages
Following the standard set by Halo Electronics, Inc. v. Pulse Electronics, Inc., the threshold for proving wilful infringement has shifted. Evidence of pre-suit knowledge is no longer a standalone driver. Instead, we focus on the defendant’s state of mind and the reasonableness of their defences. Strategic preparation now requires a documented analysis of whether the defendant wilfully disregarded valid patent rights, which is vital for building a case for enhanced damages.
Damages Methodology
Apportionment and the SSPPU Damages theories must move beyond aggregate royalty demands. The shift toward the Smallest Saleable Patent Practicing Unit (SSPPU) dictates that experts isolate the specific value contributed by the patented feature within a complex DPU or network stack. Our approach requires tight alignment between technical discovery and economic modelling, ensuring that the damages theory is tethered to the specific technological improvement rather than the value of the entire product.
PTAB and IPR Strategy
The interplay between district court litigation and the Patent Trial and Appeal Board (PTAB) is no longer an afterthought. In fact, it is the primary venue for validity challenges. The ‘parallel track’ strategy requires synchronization between the infringement case and the inter partes review (IPR) filing. Success depends on pre-empting IPR arguments during the prosecution and claim construction phases, rather than reacting to them once the PTAB petition is filed.
U.S. vs. EU Enforcement Dynamics
While U.S. litigation is often driven by potential damages, EU patent enforcement offers a distinct tactical landscape. European courts, particularly in jurisdictions like Germany, provide a more streamlined path to injunctive relief. This creates a divergence: U.S. strategies prioritize the quantification of reasonable royalties, whereas EU strategies are frequently leveraged to secure market-exclusion injunctions, forcing faster settlement negotiations for implementers.
Why Lumenci for Patent Infringement Analysis
Lumenci sits at the intersection this article is about: the point where a source code finding has to become a legal argument. That’s a different skill set than running static analysis tools.
- Litigation-ready from day one. Every forensic finding is documented with the chain-of-custody rigor needed to survive a Daubert challenge, not assembled after the fact for a report.
- Claim mapping built for cross-examination. Our experts map code to claim limitations in a form that holds up when opposing counsel tries to pick it apart in deposition.
- Expert witnesses who’ve done this before. Our technical experts have testified through claim construction, expert reports, and trial, and know how to explain code logic to a jury without losing precision.
- Damages-aware technical work. Our source code findings are structured to plug directly into SSPPU-based damages models, so the technical and economic experts aren’t working from disconnected theories.
Talk to a Lumenci source code expert before your next protective order gets negotiated, not after.
Conclusion
The era of broad-brush patent assertion is effectively over. As software architectures become opaquer through obfuscation and advanced hardware offloading, the ability to decode the technical ‘how’ of an infringement is the single greatest determinant of success.
Moving forward, the primary differentiator in IP litigation will be the integration of deep technical discovery with strategic legal positioning. We anticipate three specific shifts in the market:
- Hardware-Level Forensics: As processing shifts to DPUs and intelligent NICs, infringement analysis must move past simple code comparison into hardware-level data path analysis.
- Data-Driven Licensing: Licensing models will move away from static, fixed-fee structures toward variable models that track actual utilization and value generated by the patented tech.
- Proactive Portfolio Pruning: Winners will be those who rigorously audit their portfolios to discard obsolete rights and focus resources on core innovations that align with the current 6G and cloud-infrastructure standards.
Success in this environment requires a departure from generic theories. It demands the ability to map claim limitations to actual, observable performance metrics. Organizations that prioritize this level of technical fidelity will be the ones that effectively leverage their portfolios to drive value, whether through licensing, litigation, or strategic market positioning.
Frequently Asked Questions
What is patent infringement analysis in a software case?
It’s the process of determining whether an accused product implements a patented claim, either literally or under the Doctrine of Equivalents. In software, this analysis depends almost entirely on source code, since surface-level product behavior rarely reveals how a feature is actually implemented.
How is source code discovery different from standard document discovery?
Source code discovery is governed by a protective order that typically restricts access to a standalone, non-networked computer with limited tools. This makes it far more procedurally constrained than a normal document production, and the terms negotiated upfront often determine what a technical expert can actually find.
Does the Abstraction-Filtration-Comparison test apply to patent infringement cases?
No. AFC is a copyright doctrine from Computer Associates v. Altai used to separate protectable expression from unprotectable ideas. Patent infringement analysis is governed by claim construction and direct comparison to the asserted claims, and treating AFC as a patent framework is a common but significant error.
What does a claim mapping expert witness actually do in litigation?
A claim mapping expert witness connects specific lines or modules of code to each limitation in an asserted patent claim, then defends that mapping through deposition and trial testimony. Their credibility often depends as much on communication clarity as on technical accuracy.
Can obfuscated or minified code still be analyzed for infringement?
Yes, though it requires specialized de-obfuscation techniques and strong knowledge of compiler theory. Analysts assess obfuscation by its potency and resilience, since heavier obfuscation slows analysis but doesn’t make the underlying logic unrecoverable.
How does the Smallest Saleable Patent Practicing Unit affect software patent damages?
SSPPU requires damages experts to isolate the value of the specific patented feature rather than the entire product or platform. This means the technical team’s source code findings need to map cleanly to the isolated feature, not just to general produc
