In a previous article, I introduced the three primary approaches for establishing Evidence of Use (EoU) in patent matters involving software and firmware: analysis of publicly available information, device and application testing, and reverse engineering. That piece outlined what each approach involves and when each is most appropriate.
This article goes deeper into the software side — how software reverse engineering (RE) and dynamic testing are conducted, what tools and methods are available, and how the results connect to the claim elements that matter in patent litigation and licensing.
When Publicly Available Information Is the Starting Point
Software RE becomes necessary when publicly available information on the structure or functionality of the product under investigation does not provide sufficient evidence. But before committing to RE, it is worth understanding how far publicly available sources can take you.
In some cases, the answer is surprisingly far. Manufacturers of Linux-based devices, for example, are obligated to make the Linux kernel source code used in those devices available to device owners. This provides a cost-effective entry point for analysis.
The source code for complex applications can be extensive, but there are software tools designed to assist with navigation, program flow tracing, and function call mapping. Emulation tools can assist by allowing the analyst to trace how functions are executed, where they are called from, and confirm that they are actively used during program operation. This combination of source code analysis and emulation can, in many cases, produce strong EoU without the cost and complexity of deeper RE.
When publicly available source code is not accessible — as is typically the case with some devices and many proprietary applications — the investigation moves to testing and, where necessary, reverse engineering of the compiled software.
Dynamic Program Analysis: Watching Software in Action
Static analysis examines code without running it. Dynamic program analysis takes the next step — running the software on an actual or simulated processor and observing its behavior in real time. For EoU purposes, dynamic analysis can confirm that a function of interest is not merely present in the code but is actually invoked during normal device operation.
Dynamic analysis relies on instrumentation — the process of adding monitoring capabilities to a system so that a programs execution can be observed and recorded. There are two primary forms, each suited to different circumstances.
Source instrumentation involves adding monitoring instructions directly to a program’s source code. The modified code is compiled and installed on the target device or on an emulator with the same processing architecture. During execution, the instrumented code generates trace data showing which functions are called, in what order, and under what conditions. For EoU work, this trace data can provide direct evidence that specific patented methods are practiced during operation.
Binary instrumentation, often called Dynamic Binary Instrumentation (DBI), takes a different approach. Rather than modifying source code, DBI injects monitoring code into a running process. The injected code is transparent to the application — it does not alter the program’s behavior — and allows the analyst to follow execution steps systematically. DBI tools provide APIs that support flow analysis, taint analysis, code coverage measurement, and debugging, enabling a structured approach to identifying and documenting the runtime behavior that corresponds to patent claim elements.
Debuggers, Emulators, and the Test Environment
In practice, dynamic testing often involves connecting a debugger to the target device or application. Debuggers such as GDB (GNU Debugger) and LLDB (Low-Level Debugger) allow the analyst to set breakpoints at specific functions within a running program. When the program reaches a breakpoint, execution pauses, and the analyst can inspect memory, examine the call stack, and verify that the target function was called as part of normal operation.
For applications running on devices that cannot be easily instrumented — because they cannot be rooted, for example — emulation provides a practical alternative. For example, an Android emulator can be configured to execute a target application extracted from a mobile device, with a debugger attached to monitor runtime behavior. While the execution environment is simulated, the software under analysis is the same code that runs on the commercial product. This approach provides fine-grained access to runtime operation and llows the analyst to stimulate specific behaviors, monitor responses, and document the operational details that connect to claim limitations.
The test environment itself can vary significantly depending on the product category. For PCs and laptops, firmware and software are often accessible through the operating system’s file system, and standard debugging tools can be attached with relative ease. For smartphones, the security environment is tighter — accessing runtime behavior may require debug tools such as ADB (Android Debug Bridge) or placing the device in a special flashing or bootloader mode. In each case, the goal is the same: to observe the software executing the functions of interest under conditions that reflect real-world use.
Connecting the Analysis to Patent Claims
The technical rigor of the RE and testing work matters only insofar as it produces evidence that maps to the specific limitations recited in the patent claims. This is where the intersection of technical expertise and intellectual property knowledge becomes critical.
An analyst who can extract and trace a function call is essential. But translating that finding into a clear, defensible EoU chart — one that connects the observed behavior to the language of the claim — requires an understanding of claim construction, the doctrine of equivalents, and the evidentiary standards that patent holders and their counsel must meet. At Ocean Tomo, a part of J.S. Held, we structure our engagements so that IP expertise guides the technical investigation from the outset, ensuring that tests, traces, and documented function calls serve the broader litigation or licensing strategy.
Managing Scope and Cost Through a Phased Approach
One of the most common concerns from patent holders and outside counsel is cost predictability. Software RE and dynamic testing can range from straightforward to highly complex depending on the product, the claims at issue, and the depth of evidence required.
To manage this, we use a phased engagement model. An initial assessment identifies the most efficient path to the needed evidence — starting with publicly available information, escalating to testing, and moving to deeper RE only when the earlier phases do not yield sufficient results. Each phase produces findings that inform the scope and approach of the next, allowing clients to make informed decisions about investment at every stage. The objective is always to obtain the required EoU at the lowest practical cost, without compromising evidentiary strength.
When Software-Level Analysis Is Not Enough
In many cases, software RE and dynamic testing provide the evidence needed to support a patent holder’s position. But when the functionality of interest is implemented not in user-installed software but in proprietary firmware — stored on a device’s flash memory and tightly integrated with the hardware — a different set of tools and methods is required. In my paper I walk through the firmware reverse engineering process, from physical extraction through disassembly, de-compilation, and analysis.
Next month I’ll explore Firmware Reverse Engineering in greater detail.
Learn more about Ocean Tomo’s Software Analysis capabilities or contact Christopher Furlough at [email protected].