Introduction
The Federal Circuit’s decision in TrackTime, LLC v. Amazon.com Services LLC, Case No. 2024-1102 (Fed. Cir. July 2, 2026), clarifies how courts must determine whether software claim language invokes means-plus-function treatment under 35 U.S.C. § 112(f), particularly when a claim recites “executable program code” configured to perform specified operations.
The court vacated a judgment that claims of TrackTime’s U.S. Patent No. 8,862,978 were indefinite. Importantly, however, the Federal Circuit did not decide whether the disputed “executable program code” limitations ultimately invoke means-plus-function treatment under 35 U.S.C. § 112(f). Instead, it held that the district court failed to conduct the complete analysis required by existing precedent. Although “executable program code” may be generic when viewed in isolation, courts must determine the precise claimed function and evaluate the limitation as a whole, in its technological context, before deciding whether the language conveys sufficiently definite structure to a person of ordinary skill in the art.
At the same time, the Federal Circuit affirmed a jury verdict that a separate TrackTime patent was anticipated by an earlier commercial transcript-management program. That portion of the decision illustrates the difficulty of overturning a jury’s resolution of competing expert testimony, particularly when the patent specification itself broadly defines the claimed technology.
Charles Gideon Korrell notes that the decision does not establish that “code” is inherently structural. Instead, it requires courts to analyze what the claimed code does, how it interacts with other components, and how a person skilled in the art would have understood the limitation at the relevant time.
Background: Navigating Multimedia Through Synchronized Transcripts
TrackTime’s U.S. Patent Nos. 8,856,638 and 8,862,978 share a materially identical specification directed to navigating multimedia files through time-correlated transcripts displayed on mobile devices.
The patented technology associates words in an electronic transcript with locations in an audio or video file. A user can select text on a touchscreen and jump to the corresponding point in the multimedia. The system also permits users to annotate portions of the transcript and share those annotations.
The specification acknowledged that transcript-management, multimedia-navigation, and annotation tools already existed. TrackTime characterized the shortcomings of those systems as their dependence on full desktop versions of Microsoft Windows and the distribution of related functionality across separate applications. The patents proposed software suitable for mobile computing devices that combined transcript navigation, synchronous playback, and annotation.
TrackTime sued Amazon in the District of Delaware. Two distinct patent disputes eventually reached the Federal Circuit.
For the ’978 patent, the district court held that limitations reciting “executable program code configured to facilitate annotation” and “executable program code configured to synchronously play” multimedia invoked § 112(f). Because the court found that the specification did not disclose an adequate algorithm or other corresponding structure, it held the asserted claims indefinite.
For claim 9 of the ’638 patent, a jury found both noninfringement and invalidity on several grounds, including anticipation by LiveNote, a preexisting commercial transcript-management program. The district court denied TrackTime’s motions for judgment as a matter of law and a new trial.
The § 112(f) Framework After Williamson
Section 112(f) allows a claim element to be expressed as a means for performing a function without reciting supporting structure. When the provision applies, the limitation covers the corresponding structure disclosed in the specification and its equivalents.
The consequence can be substantial. If the specification fails to disclose adequate corresponding structure for the claimed function, the claim is indefinite.
The modern framework as it relates to software derives principally from the 2015 decision Williamson v. Citrix Online, LLC. When a claim uses the word “means,” § 112(f) presumptively applies. When the claim does not use “means,” the opposite presumption applies, but that presumption can be rebutted by showing that the limitation recites a function without sufficient structure for performing it.
The inquiry therefore does not turn on whether the limitation contains some noun that could loosely be called structural. Courts must determine whether the language identifies sufficient structure for the particular claimed function.
That distinction explains why terms such as “module,” “mechanism,” “element,” “device,” and “logic” may function as substitutes for “means” in some claims but identify meaningful structure in others. Context controls.
Williamson remains the Federal Circuit’s principal modern decision governing software-related means-plus-function analysis. By abandoning the earlier requirement that the presumption against applying § 112(f) be overcome only by “strong” evidence, Williamson shifted the inquiry toward whether the claim language itself would have conveyed sufficiently definite structure to skilled artisans. Since then, disputes have focused less on the presence or absence of particular words and more on whether terms sometimes characterized as nonce words actually identify a recognized class of structures within the relevant technology.
The Federal Circuit’s precedents also recognize that a structural term need not identify a single physical configuration. A term can denote a class of structures familiar to skilled artisans. Even a name derived from function, such as “screwdriver” or “detector,” may convey structure because it has an established meaning in the relevant field.
Why the District Court’s Analysis Was Incomplete
The district court correctly began with the presumption that § 112(f) did not apply because the claims omitted the word “means.” It nevertheless concluded that the presumption had been overcome because “executable program code,” like “logic,” was generic and did not identify definite structure.
The Federal Circuit did not hold that this conclusion was necessarily wrong. It held that the analysis stopped too soon. That distinction explains the procedural posture of the appeal. The Federal Circuit did not conclude that the district court necessarily reached the wrong answer. Rather, it concluded that the court had not completed the analysis required by Williamson and related precedent before reaching its conclusion. On remand, the district court may ultimately determine that § 112(f) applies, but only after identifying the precise claimed functions and evaluating whether the complete claim limitations, viewed in context, convey sufficient structure to skilled artisans.
A court cannot isolate the alleged structural noun from the surrounding claim language and ask whether the noun, standing alone, identifies structure. It must first identify the precise claimed function and then consider whether the limitation as a whole would convey sufficient structure for performing that function.
That requirement is especially important for software. Software is commonly identified in part by what it does. Treating every functionally described software term as nonstructural would sweep a large category of software claims into § 112(f), even when skilled programmers would understand the language to identify known classes of code or established operations.
The Federal Circuit therefore directed the district court to evaluate the complete limitations, including the recited annotation and synchronous-play functions, their implementation on a mobile computing device, and their integration with the other functionality assigned to the same software.
Charles Gideon Korrell observes that this emphasis on integration is an important feature of the decision. The claimed code was not merely required to annotate text or play media in isolation. The claims contemplated software capable of operating on a mobile device while performing multiple coordinated functions within one system. Whether that combined description conveys structure is a different question from whether the phrase “executable program code” is structural in the abstract.
The Central Role of Dyfan v. Target
The district court issued its ruling before the Federal Circuit decided Dyfan, LLC v. Target Corp. In Dyfan, the court concluded that software “code,” when read together with language describing how it operated within the claimed invention, conveyed sufficient structure to avoid § 112(f). The decision did not establish that software code is inherently structural. Rather, it demonstrated that otherwise generic software terminology may acquire structural meaning when the claims, viewed as a whole, would communicate a known class of software to persons of ordinary skill in the art.
TrackTime applies that same analytical framework rather than announcing a new one. The court expressly declined to decide whether the disputed “executable program code” limitations ultimately invoke § 112(f). Instead, it held that Dyfan required a more complete inquiry into whether the recited operations, technological context, and understanding of skilled artisans together gave structural meaning to the claimed software language.
TrackTime does not transform Dyfan into a categorical rule. The court expressly left open the possibility that the limitations may still invoke § 112(f). But Dyfan required a more complete inquiry into whether the recited operations and the understanding of skilled artisans give structural meaning to otherwise generic software terminology.
The panel contrasted that analysis with cases such as Robert Bosch, LLC v. Snap-On Inc. and Egenera, Inc. v. Cisco Systems, Inc. In Robert Bosch, the term “program recognition device” did little more than state a desired function. In Egenera, “logic to modify” lacked structural limitations concerning inputs, outputs, connections, or operation.
By comparison, Apple Inc. v. Motorola, Inc. and Dyfan recognized that software language may convey structure when the claims explain how the software operates within the invention, rather than merely stating the result it must achieve.
The line separating those cases is not whether the claim uses the word “code.” It is whether the claim and the relevant technical understanding disclose something about how the claimed result is produced.
Extrinsic Evidence May Determine Whether Software Language Conveys Structure
The Federal Circuit also faulted the absence of meaningful factual findings concerning how skilled artisans used and understood the disputed terminology.
The opinion also reinforces that intrinsic evidence remains the starting point for the § 112(f) inquiry. Claims, the specification, and the prosecution history ordinarily provide the primary basis for determining whether a limitation conveys structure. Extrinsic evidence becomes significant when assessing how persons of ordinary skill would have understood the disputed language at the time of the invention, particularly where the intrinsic record does not conclusively resolve that question.
TrackTime had submitted expert evidence identifying earlier software that allegedly performed annotation and synchronous-play operations. Amazon’s expert maintained that the claimed language did not disclose algorithms or instructions for carrying out those functions.
The district court mentioned the competing declarations but did not resolve the underlying factual dispute. Nor did the existing evidence squarely address the precise functions later identified by the Federal Circuit, including mobile implementation and integration with the remaining claimed functionality.
On remand, the district court may permit new expert submissions. It must determine whether “executable program code,” read together with the complete functional language, was commonly understood to identify known code capable of performing the claimed operations.
The court may still resolve the question based on intrinsic evidence alone. But if it does so, it must explain why the claims, specification, or prosecution history conclusively establish whether the limitations convey sufficient structure.
According to Charles Gideon Korrell, this aspect of the opinion provides an important litigation lesson: parties addressing § 112(f) should not submit generalized expert opinions about whether “code,” “logic,” or “software” is structural. The evidence should address the exact function, technological environment, inputs, outputs, interactions, and state of the art reflected in the disputed limitation.
Anticipation by the LiveNote System
The Federal Circuit reached a different result for claim 9 of the ’638 patent, affirming the jury’s finding that LiveNote anticipated the claim.
Claim 9 covered using a synchronization index and a mobile computing device to display transcript text, receive a touchscreen gesture selecting a word or phrase, determine the corresponding multimedia time, and seek to that location.
TrackTime argued that LiveNote did not disclose a data lookup, a mobile computing device, or the claimed touch-sensitive input interface. The court rejected each argument.
TrackTime forfeited its data-lookup argument by failing to present it adequately to the district court. As to mobile computing, the LiveNote materials expressly described operation on a tablet PC, and TrackTime’s own patent treated a tablet computer as an example of a mobile computing device.
TrackTime contended that LiveNote’s tablet functionality was limited to annotation rather than multimedia navigation. But the user materials did not state that the tablet version omitted other program functions, and Amazon’s expert testified that LiveNote’s features could be used on a tablet.
The LiveNote documentation also disclosed operation with a tablet pen. TrackTime had not obtained a construction limiting “touch-sensitive input interface” to direct human contact, and the jury could reasonably find that a pen-operated tablet fell within the ordinary meaning of the limitation.
Equally important was the standard of appellate review. Because anticipation had been tried to a jury, the Federal Circuit reviewed the denial of judgment as a matter of law under the substantial-evidence standard. The court therefore did not decide whether it would have reached the same factual conclusions in the first instance. Instead, it asked whether a reasonable jury could credit Amazon’s evidence. Having concluded that substantial evidence supported the verdict, the court declined to reweigh competing expert testimony or revisit the jury’s credibility determinations.
The appeal therefore presented, at most, a conventional dispute between experts. The jury was entitled to credit Amazon’s evidence, and the verdict was not so contrary to the record that it required a new trial.
Practical Implications for Software Patents
TrackTime reinforces that software claims using terms such as “code,” “logic,” or “module” cannot be classified under § 112(f) through word-by-word formalism. Courts must identify the claimed function precisely and evaluate the full limitation in technological context.
Patent drafters should nevertheless avoid relying on generic software labels followed only by statements of desired results. Software patent claims are more likely to convey structure when they describe relevant operations, information flows, inputs, outputs, interfaces, interactions among software components, or other technological constraints that would be recognized by skilled artisans. Likewise, specifications should disclose sufficient implementation detail, including algorithms where appropriate, to support either possible claim construction. If § 112(f) ultimately applies, those disclosures may become the corresponding structure. If it does not, they may nevertheless help demonstrate that the claim language conveyed recognized software structure at the time of filing.
Specifications should also describe implementation in sufficient detail to support either possible claim construction. If § 112(f) applies, disclosed algorithms and procedures may become the corresponding structure. If it does not, those same disclosures may help demonstrate that the claim language had recognized structural meaning.
For litigants, TrackTime makes expert framing critical. The relevant question is not whether software has physical structure in the traditional mechanical sense. It is whether skilled artisans would understand the complete limitation to identify a known class of code or a sufficiently described operation capable of performing the precise claimed function.
The anticipation ruling offers a complementary drafting lesson. Patent applicants frequently define claim terms broadly to maximize infringement coverage, but those same definitions may later broaden the universe of qualifying prior art. TrackTime illustrates that a patent owner cannot readily disavow an expansive definition adopted in its own specification when attempting to distinguish prior art during litigation.
Finally, the anticipation ruling shows the risks created by broad definitions in a patent specification. TrackTime could not plausibly exclude tablet PCs from “mobile computing devices” after its own patent expressly included them. Nor could it add a human-finger limitation to “touch-sensitive” during appellate review when no such construction had been secured below.
Charles Gideon Korrell believes the decision ultimately demands symmetry from patent owners. Functional software language must be interpreted in context when deciding whether it conveys structure, but the same contextual approach applies when earlier technology is evaluated against the asserted claims.
Conclusion
TrackTime does not resolve whether the ’978 patent’s “executable program code” limitations ultimately invoke § 112(f). Instead, it clarifies the analytical sequence courts must follow before answering that question. Consistent with Williamson and Dyfan, a court must identify the precise claimed function, evaluate the complete claim limitation in its technological context, and determine whether persons of ordinary skill in the art would have understood the language to convey sufficiently definite structure. Only after completing that inquiry may the court decide whether § 112(f) governs the limitation.
A court must identify the precise claimed function, read the limitation as a whole, consider how the software operates within the claimed system, and address relevant evidence concerning the understanding of skilled artisans. Generic terminology may still trigger § 112(f), but it cannot be treated as a nonce term merely because it appears generic in isolation.
For software patent disputes, that distinction may determine whether a claim receives its ordinary scope or is restricted to disclosed corresponding structure and potentially invalidated for indefiniteness.
Key Takeaways
- Whether “executable program code” invokes § 112(f) depends on the complete claim limitation, its technological context, and how a person of ordinary skill in the art would have understood the language, not on the generic nature of the word “code” viewed in isolation.
- Dyfan requires courts to consider whether recited software operations would convey structure to a person skilled in the art.
- Expert evidence should address the precise claimed functions, implementation environment, and availability of known code, rather than software terminology in the abstract.
- Patent owners cannot narrow broadly drafted terms during an anticipation challenge when the specification and trial record support the prior art’s inclusion.