KEY TAKEAWAY:  The USPTO, Central Reexamination Unit, and district court may not decide that a software limitation invokes § 112(f) merely by isolating “code” or “logic” and calling it generic. It must evaluate the complete limitation, the precise claimed function, the claim and specification context, and what the language would have conveyed to a skilled artisan.

The Central Reexamination Unit of the U.S. Patent and Trademark Office (USPTO) has routinely provided claim construction in reissue and reexamination cases where they have determined a functional term should be construed as a means-plus-function (MPF) limitation based on Williamson[1]. Patent Owners often disagree that the alleged function or nonce term should be construed under MPF but may not fully understand all the cases that they can rely on to respond to the Office’s allegations. A recent Federal Circuit case, TrackTime[2], provides a patent owner a summary of a number of tools to use from cases that have been decided since Williamson that can be used to limit when the CRU can try and convert what they consider a functional term or nonce term into an MPF analysis.

This article will discuss 35 U.S.C. § 112(f) and the many cases interpreting its proper use from Williamson to the recent decision in TrackTime. For district courts, TrackTime requires the inquiry to determine whether the entire limitation, read in full and in context, recites sufficient structure for performing the claimed function. The Federal Circuit’s analysis also provides a framework patent owners can invoke when § 112(f) is raised during USPTO proceedings.

Section 112(f) Is About the Line Between Function and Structure

Section 112(f) permits an element of a combination claim to be expressed as a means for performing a specified function without reciting the structure that performs that function. If § 112(f) applies, the limitation is construed to cover the corresponding structure described in the specification and equivalents. If the specification does not disclose sufficient corresponding structure, the claim may be indefinite under 35 U.S.C. § 112(b).

The threshold question is therefore often dispositive: is the limitation actually written in means-plus-function form? A limitation using “means” is presumptively governed by § 112(f). A limitation that omits “means” is presumptively outside the statute, although the presumption may be overcome if the challenger proves that the limitation recites function without sufficient structure for performing that function.

TrackTime is significant because the Federal Circuit found the district court’s approach inefficient that effectively stopped after labeling “executable program code” or “logic” generic. For software language, the USPTO or district court must ask what the complete limitation, read in technological and claim context, would have communicated to a person of ordinary skill in the art.

The Patents and the Disputed Limitations

TrackTime asserted U.S. Patent Nos. 8,856,638 and 8,862,978 against Amazon. The patents share a materially common specification directed to navigating multimedia on a mobile device using a time-correlated transcript, called a “synchronization index.” The disclosed system permits a user to select transcript text to reach a corresponding point in the multimedia and to annotate the transcript.

The § 112(f) appeal concerned two limitations in claims 1 and 2 of the ’978 patent:

  • “executable program code configured to facilitate annotation” of part of the synchronization index; and
  • “executable program code configured to synchronously play” the multimedia with the synchronization index.

Neither limitation uses the word “means.”

What the District Court Did

Amazon’s position.

Amazon advanced a two-step indefiniteness theory. First, it argued that the two “executable program code” limitations were means-plus-function limitations subject to § 112(f). Second, it argued that the specification did not disclose an adequate algorithm or other corresponding structure for the claimed annotation and synchronous-play functions. Amazon’s expert, Dr. Dan Schonfeld, opined that the terminology did not identify the underlying algorithms or instructions and that recitation of a mobile computing device supplied no additional structure.

TrackTime’s response.

TrackTime argued that § 112(f) did not apply because skilled artisans would have understood the limitations to refer to particular types of executable code found in known programs. Its expert, Dr. Maneesh Agrawala, identified existing software as examples. TrackTime also relied on the specification’s descriptions of subsidiary operations associated with annotation and synchronous playback as conveying sufficient structural content.

The district court’s ruling.

The U.S. District Court for the District of Delaware recognized the presumption against § 112(f), but held that Amazon had rebutted it. The court viewed “executable program code,” and similarly “logic,” as generic rather than sufficiently structural. Having determined that § 112(f) applied, the district court found no adequate algorithm or procedure explaining how the code carried out the recited functions and held the asserted ’978 claims indefinite.

The Federal Circuit’s Framework

The Federal Circuit collected and synthesized a substantial body of precedent addressing the distinction between function and structure. The cases do not establish a categorical rule for software. Instead, they require a contextual inquiry directed to whether the language identifies sufficient structure for performing the particular claimed function.

1. Williamson: The Governing Question Is “Sufficient Structure”

In Williamson, the threshold inquiry is whether the limitation recites function without reciting sufficient structure for performing that function. Williamson also supplies the rebuttable presumption against § 112(f) when the word “means” is absent. The inquiry is not whether the language conveys any structure, but whether it conveys sufficient structure for the claimed function.

2. Bosch and Egenera: A Functional Label Is Not Enough

Bosch[3] general held “program recognition device” was subject to means-plus-function treatment because the claim did nothing more than identify functions for the device to perform, and the specification passages merely explained those functions. And Egenera[4] generally held that the word “logic” did not escape § 112(f) merely because it might be implemented as software, firmware, or circuitry. The pertinent question remained whether the claim recited structure for the claimed functions, including relevant inputs, outputs, connections, and operation.

3. Greenberg and Related Cases: Structure Need Not Be a Single Physical Configuration

Greenberg[5] generally held that a term may designate a sufficiently understood class of structures even if it does not call to mind one specific physical configuration and even if the term has a functional origin. TrackTime also relied on the principles reflected in a line of cases[6] that structural significance may come from usage by skilled artisans and from the claim and specification context, not only from the naming of a single physical object.

4. Dyfan: Software Requires Attention to Operation

The Court spent a lot of time on Dyfan[7] and how it should be applied because Dyfan issued after the district court’s ruling and was a principal reason the Federal Circuit concluded that further analysis was necessary. Dyfan held that because code is partly defined by function, a court must review the alleged means-plus-function limitation in full and ask whether the recited operation would have connoted structure to skilled artisans. Dyfan treated the availability of off-the-shelf code capable of performing the recited functions as relevant to that inquiry. The Federal Circuit made clear that the analysis could not end with the observation that “executable program code,” standing alone, was generic.

The Parties’ Competing Positions on Appeal

TrackTime did not rely merely on the proposition that “program code” denotes some structure. It argued that “executable program code” configured to perform the specifically recited operations, read as a whole, would have been understood as well-known code for those operations. TrackTime cited examples of allegedly known prior-art code in support.

Amazon relied primarily on Robert Bosch and Egenera. It argued that generic technological terminology does not become structural merely because the claim states the result the software must achieve. Amazon also contended that the intrinsic record might distinguish or disclaim the prior-art software invoked by TrackTime.

The Federal Circuit did not adopt TrackTime’s construction. It expressly stated that TrackTime’s position “may well be wrong.” The problem was that the district court had not adequately analyzed or explained why a skilled artisan would not understand the full limitations in the structural manner TrackTime proposed.

Why the Federal Circuit Vacated and Remanded

The Federal Circuit vacated rather than reversed because the existing record did not establish that the disputed language was outside § 112(f). It established only that the district court’s analysis was insufficient to support the conclusion that Amazon had overcome the presumption against § 112(f). The remand requires the following more disciplined inquiry.

  • Parse the Limitation and Precisely Identify the Claimed Function

The district court and USPTO must separate the claimed function from the non-function language identifying what performs it. Correct identification of the function is necessary both to decide whether § 112(f) applies and, if it does, to identify corresponding structure.

The relevant functions here are not simply annotation and synchronous play in the abstract. They are annotation and synchronous play:

  1. on a mobile computing device; and
  2. integrable with the other functionality recited in the claims.
  • Evaluate the Limitation in Full and in Context

The proper inquiry is not whether “executable program code,” isolated from the rest of the limitation, describes a definite structure. The district court and USPTO must ask whether a skilled artisan would understand the complete phrase, including the stated operation and surrounding claim language, as identifying a sufficiently understood class of structures capable of performing the function.

  • Distinguish a Desired Result From an Operation

For software, the district court and USPTO must determine whether the limitation merely identifies a desired outcome or communicates how the software operates. The Federal Circuit observed that the claims, taken alone, were thin. Claim 1 recited little more than “user input” for annotation, while claim 2 supplied still less operational detail for synchronous play. The claims alone therefore did not describe the operations sufficiently to define structure, but that conclusion did not end the inquiry.

  • Determine Whether the Specification Gives the Claim Language Structural Meaning

The district court and USPTO must closely examine the portions of the specification that describe software operations and determine whether those disclosures properly inform or limit the meaning of the disputed claim language. The specification is relevant not only to the second-stage search for corresponding structure after § 112(f) applies. It may also inform the first-stage claim-construction question whether the limitation invokes § 112(f) at all. Apple described those inquiries as distinct but “inherently related.”

  • Determine What the Terminology Meant to Skilled Artisans

The district court and USPTO must determine whether, at the relevant time, persons of ordinary skill would have understood the disputed limitations, for the precise functions at issue, as naming known code or a recognized class of software structures. The Federal Circuit cited a line of cases[8] supporting examining whether terminology is used in common parlance or in the pertinent art to designate structure.

  • Consider Properly Focused Extrinsic Evidence

Extrinsic evidence may be important if the meaning of the terminology to skilled artisans is disputed. The existing declarations did not squarely answer the correct question. Amazon’s expert addressed the relatively bare words “executable” and “program code.” TrackTime’s expert identified code for annotation and synchronous play but did not squarely establish whether it was mobile-device software capable of integration with the other claimed functions. The district court and USPTO may therefore permit renewed submissions focused on the properly framed inquiry.

  • If the Intrinsic Record Alone Resolves the Issue, Explain Why

Extrinsic evidence is not required in every case. Diebold Nixdorf[9] recognizes that intrinsic evidence alone may overcome the presumption against § 112(f). But if the district court relies solely on the intrinsic record, TrackTime requires it to explain why that record resolves the threshold question to the required degree of clarity.

A Practical § 112(f) Checklist

Required inquiry Question for the USPTO or district court
Identify the function What exact function must the claimed software perform, including platform and integration requirements?
Identify the alleged structure What non-function language names or describes the component that performs the function?
Read the limitation as a whole Does the complete limitation convey more than a desired result?
Assess operation Do the claims or specification describe inputs, outputs, connections, interactions, or how the result is achieved?
Assess usage in the art Would a skilled artisan have understood the terminology to identify known code or a recognized class of software structures?
Evaluate evidence Do the intrinsic record and any focused expert or industry evidence answer that precise question?
Explain the burden Has the proponent of § 112(f) overcome the presumption by the applicable evidentiary standard?
Proceed to corresponding structure Only if § 112(f) applies, does the specification disclose adequate corresponding structure for the identified function?

TrackTime’s Practical Rule

For a software limitation that does not use “means,” a court cannot determine § 112(f) applicability simply by isolating a noun such as “code” or “logic,” labeling it generic, and proceeding directly to the corresponding-structure inquiry.

The district court and USPTO must determine whether the entire limitation, understood in its technological and claim context by a skilled artisan, recites sufficient structure for performing the particular claimed function. That inquiry may require consideration of the precise function, the claimed operation, surrounding limitations, specification disclosures, usage in the art, and focused extrinsic evidence.

TrackTime does not create a safe harbor for “code configured to” language. The Federal Circuit left open the possibility that either limitation could still be held subject to § 112(f), including on intrinsic evidence alone. The decision instead requires a rigorous explanation of why the challenger has overcome the Williamson presumption.

Conclusion

The Federal Circuit remanded because Dyfan was decided after the district court decision and held that the district court moved too quickly from the generic character of “executable program code” to application of § 112(f) and indefiniteness. Before deciding whether the specification discloses adequate corresponding structure, the district court and USPTO must rigorously determine whether § 112(f) applies at all.

The central lesson is one of sequence and precision: in software cases, a court and the USPTO may not ask only whether “code” sounds structural in the abstract. It must ask what the complete limitation communicates to a skilled artisan about structure for performing the specific claimed function. Only after answering that threshold question may the district court or USPTO proceed to the corresponding-structure and indefiniteness inquiries.


[1] Williamson v. Citrix Online, LLC, 792 F.3d 1339 (Fed. Cir. 2015)

[2] TrackTime, LLC v. Amazon.com Services LLC, No. 2024-1102 (Fed. Cir. July 2, 2026)

[3] Robert Bosch, LLC v. Snap-On Inc., 769 F.3d 1094 (Fed. Cir. 2014).

[4] Egenera, Inc. v. Cisco Systems, Inc., 972 F.3d 1367 (Fed. Cir. 2020).

[5] Greenberg v. Ethicon Endo-Surgery, Inc., 91 F.3d 1580 (Fed. Cir. 1996).

[6] Wenger Manufacturing v. Coating Machine Systems, Inc., 239 F.3d 1225 (Fed. Cir. 2001); MTD Products Inc. v. Iancu, 933 F.3d 1336 (Fed. Cir. 2019); Skky, Inc. v. MindGeek, s.a.r.l., 859 F.3d 1014 (Fed. Cir. 2017); Rembrandt Data Technologies, LP v. AOL, LLC, 641 F.3d 1331 (Fed. Cir. 2011); Inventio AG v. ThyssenKrupp Elevator Americas Corp., 649 F.3d 1350 (Fed. Cir. 2011); TEK Global, S.R.L. v. Sealant Systems International, Inc., 920 F.3d 777 (Fed. Cir. 2019); Linear Technology Corp. v. Impala Linear Corp., 379 F.3d 1311 (Fed. Cir. 2004); Lighting World, Inc. v. Birchwood Lighting, Inc., 382 F.3d 1354 (Fed. Cir. 2004); Personalized Media Communications, LLC v. International Trade Commission, 161 F.3d 696 (Fed. Cir. 1998).

[7] Dyfan, LLC v. Target Corp., 28 F.4th 1360 (Fed. Cir. 2022).

[8] Wenger Manufacturing v. Coating Machine Systems, Inc., 239 F.3d 1225 (Fed. Cir. 2001); MTD Products Inc. v. Iancu, 933 F.3d 1336 (Fed. Cir. 2019); Skky, Inc. v. MindGeek, s.a.r.l., 859 F.3d 1014 (Fed. Cir. 2017); Rembrandt Data Technologies, LP v. AOL, LLC, 641 F.3d 1331 (Fed. Cir. 2011); Inventio AG v. ThyssenKrupp Elevator Americas Corp., 649 F.3d 1350 (Fed. Cir. 2011); TEK Global, S.R.L. v. Sealant Systems International, Inc., 920 F.3d 777 (Fed. Cir. 2019); Linear Technology Corp. v. Impala Linear Corp., 379 F.3d 1311 (Fed. Cir. 2004); Lighting World, Inc. v. Birchwood Lighting, Inc., 382 F.3d 1354 (Fed. Cir. 2004); Personalized Media Communications, LLC v. International Trade Commission, 161 F.3d 696 (Fed. Cir. 1998).

[9] Diebold Nixdorf, Inc. v. International Trade Commission, 899 F.3d 1291 (Fed. Cir. 2018).

© 2026 Sterne, Kessler, Goldstein & Fox PLLC