# The Structure of Software: Understanding § 112(f) and the Architecture of Innovation > On Algorithms, Ambiguity, and the Patent System's Grand Compromise **By Paul Roberts** | 🏛️ Policy\ ⌨️ 8,136 words** | ⏱️ **30 min read** #Legal_Guides #35_USC_112f #Policy #PatentLaw #Software December 27, 2024 --- ## Abstract The tension between § 112(b)'s demand for definiteness and § 112(f)'s accommodation of functional claiming represents one of patent law's enduring dialogues—a conversation between precision and flexibility, between the inventor's need to claim broadly and the public's need to understand the boundaries of the grant. For software inventions, this dialogue becomes particularly acute. Where mechanical patents speak in the language of gears and levers, software patents must describe structure through algorithms, flowcharts, and operational relationships—a vocabulary that challenges traditional notions of what "structure" means. This article examines that challenge through five lenses: First, we explore how means-plus-function claiming works for software patents, recognizing that "structure" in this domain means something fundamentally different than in mechanical arts. Second, we consider § 112(b)'s definiteness requirement and what it demands when structure is algorithmic rather than physical. Third, we address the art of preventing unintended means-plus-function construction through careful claim drafting—a task requiring practitioners to navigate between Scylla and Charybdis. Fourth, we examine strategies for responding when the USPTO improperly invokes § 112(f). Finally, we consider when and how to strategically embrace means-plus-function claiming, recognizing that what appears as constraint may also serve as opportunity. Through this framework, we seek not merely to catalog rules but to understand the principles that animate them—principles that reflect fundamental choices about how patent law balances competing values in an age where innovation increasingly occurs in software rather than hardware. --- ## Introduction: The Paradox of Software Structure In 1952, when Congress enacted what is now § 112(f), software patents barely existed. The provision contemplated "means" and "structure" in physical terms—mechanisms, materials, and mechanical arrangements. Yet today, we confront a paradox: the fastest-growing category of patents describes inventions whose "structure" exists only as instructions executed by general-purpose computers. This creates a conceptual challenge. When a mechanical patent claims a "lever," we understand what that means—there is a rigid bar pivoting on a fulcrum. But when a software patent claims a "module," what have we claimed? Is it the silicon and copper of the processor? The electrons flowing through circuits? The magnetic domains on a hard drive? The abstract logic of the algorithm? The answer matters profoundly. If § 112(f) applies, the claim's scope collapses to the specific structures disclosed in the specification (and their equivalents). If it does not, the claim may cover any structure capable of performing the recited function. The difference can determine whether a patent covers all future implementations or only the particular solution the inventor devised. Software patent practitioners thus navigate between two perils. Claim too structurally, and you may forfeit the breadth that makes the patent valuable. Claim too functionally, and you risk either § 112(f)'s narrow construction or § 112(b)'s indefiniteness ax. The Federal Circuit's evolving jurisprudence offers guidance, but the line between structural and functional claiming remains one that practitioners must draw with care and intention. This article provides a framework for walking that line. We examine not merely what the cases hold, but why they reach those holdings—what principles of patent policy and statutory construction animate the doctrine. For it is only by understanding the "why" that practitioners can confidently navigate the "how" when confronting novel claim language in novel technological contexts. --- ## I. The Architecture of Functional Claiming: How § 112(f) Works for Software ### A. The Statutory Accommodation Section 112(f) represents a congressional choice—a decision to permit inventors to claim their inventions in functional terms, subject to a compensating limitation. The quid pro quo is elegant: You may claim by what your invention does, but if you do, your claim covers only the structures you actually disclosed, not all structures capable of performing that function. For mechanical inventions, this bargain operates with relative clarity. Claim "means for fastening," and you get the screws, bolts, and rivets described in your specification, plus their equivalents. The structure is tangible, the disclosure observable, the boundaries comprehensible. Software upends this model. Here, "structure" manifests not in physical form but in logical relationships—in algorithms, decision trees, and data transformations. As the Federal Circuit observed in *Apple Inc. v. Motorola, Inc.*, persons skilled in the art may understand a software invention's structure "through, for example, an outline of an algorithm, a flowchart, or a specific set of instructions or rules." 757 F.3d 1286, 1298-99 (Fed. Cir. 2014). This recognition—that software structure exists in algorithmic rather than physical form—represents a conceptual evolution in patent law. It acknowledges that the statutory category "machine" encompasses not merely hardware but the configured hardware that executes specific logic. The computer becomes structural not through its physical arrangement but through its programming—through the transformation of a general-purpose device into a special-purpose tool. ### B. The Two Inquiries: Structure and Sufficiency When claim language omits the word "means," courts undertake a two-step analysis that reflects the statute's dual concerns: first, whether the claim invokes functional claiming at all; second, if it does, whether the specification provides the compensating disclosure the statute demands. #### The First Inquiry: Does the Claim Term Connote Structure? This threshold question asks whether the claim term, read in the context of the full claim, the specification, and the understanding of those skilled in the art, describes *how* the claimed element operates, not merely *what* it accomplishes. The distinction is subtle but fundamental. Consider the term "heuristic" at issue in *Apple*. Standing alone, "heuristic" might seem purely functional—it describes a problem-solving approach, not a specific solution. Yet the court found structure because the claims and specification described the heuristics' operation: the inputs they received (finger contacts at particular angles), the processing they performed (comparing angles to thresholds), and the outputs they generated (scrolling or translation commands). This operational context transformed "heuristic" from a functional placeholder into a structural description. The court's reasoning reveals an important principle: For software inventions, structure emerges from description of operation, integration, and relationship. A claim term connotes structure when it specifies not merely the desired result but the mechanism—even if that mechanism is algorithmic rather than mechanical. This stands in sharp contrast to *Williamson v. Citrix Online, LLC*, where "distributed learning control module" invoked § 112(f) despite replacing "means" with "module." 792 F.3d 1339 (Fed. Cir. 2015). The difference? The *Williamson* claim recited only functions—"receiving," "relaying," "coordinating"—without describing how those functions operated within the system. The term "module" added nothing; it served merely as a verbal substitute for "means." The lesson is that term selection alone cannot overcome functional claiming. Whether one writes "means," "module," "unit," "component," or "element" matters less than whether the claim describes the operational architecture—the "how" that transforms function into structure. #### The Second Inquiry: If § 112(f) Applies, Is There Corresponding Structure? Should the first inquiry fail—should the claim term prove insufficiently structural—the analysis proceeds to identify "corresponding structure" in the specification. For software inventions, this typically requires disclosure of a specific algorithm, not merely acknowledgment that a general-purpose computer executes the function. This requirement reflects a judicial recognition that software's "structure" is its algorithm. As the Federal Circuit held in *Aristocrat Technologies Australia Pty Ltd. v. International Game Technology*, "a corresponding structure must be a specific algorithm disclosed in the specification, rather than merely an algorithm executed by a computer." 521 F.3d 1328, 1331-32 (Fed. Cir. 2008). The algorithmic disclosure need not follow a particular form. The specification might provide: - **Step-by-step pseudocode** describing the logic flow - **Flowcharts** showing decision points and processing paths - **Prose descriptions** of inputs, processing, and outputs - **Mathematical formulas** defining transformations - **Source code** (though this is rarely necessary) What matters is that one skilled in the art could understand *how* to perform the claimed function—not merely *that* it can be performed. Yet even algorithmic disclosure proves insufficient if the specification fails to link that algorithm to the claimed function. The linkage requirement—articulated in cases like *Noah Systems, Inc. v. Intuit Inc.*, 675 F.3d 1302 (Fed. Cir. 2012)—demands that the specification clearly associate the disclosed algorithm with the specific function recited in the claim. Mere presence of an algorithm somewhere in the specification does not satisfy this obligation; the connection must be apparent to one skilled in the art. This linkage requirement serves patent law's notice function. The patent must enable the public to understand not merely what the inventor discovered but what the inventor claims. When a specification discloses multiple algorithms without clearly associating each with its corresponding claimed function, the public cannot determine the claim's scope. The definiteness requirement prohibits such ambiguity. ### C. The Narrow Exception: Standard Computer Functions The Federal Circuit has recognized a narrow exception to the algorithm requirement for truly standard computer functions—operations so basic and ubiquitous that one skilled in the art would understand them without algorithmic detail. *In re Katz*, 639 F.3d 1303 (Fed. Cir. 2011), exemplifies this exception: "processing," "receiving," and "storing" performed by a general-purpose computer may not require algorithmic disclosure if the function is entirely conventional. Yet the exception's boundaries remain tightly constrained. Courts apply it skeptically, recognizing that even seemingly simple operations may involve implementation choices that affect performance, efficiency, or capability. The exception applies, if at all, to functions that truly involve no inventive contribution—where the computer operates in its most generic capacity. Practitioners should approach this exception cautiously. Relying on it amounts to wagering that your claimed function is sufficiently conventional that no algorithm disclosure is required—a wager that, if lost, renders your claim indefinite. The safer course is to disclose algorithms for all computer-implemented functions, preserving both structural claim interpretations and means-plus-function fallback positions. ### D. Method Claims: A Different Framework Method claims follow distinct rules that reflect structural differences between apparatus and process claims. While apparatus claims describe tangible objects, method claims describe sequences of actions. This distinction matters for § 112(f). The statute applies to method claims only when they recite "step[s] for" performing a function "without the recital of acts in support thereof." Critically, this means that method claims using active verbs—"receiving," "processing," "transmitting"—generally avoid § 112(f) altogether. As the Federal Circuit held in *O.I. Corp. v. Tekmar Co.*, 115 F.3d 1576 (Fed. Cir. 1997), gerund forms ("-ing" verbs) describe acts, not mere functions, and therefore do not invoke the statute. This distinction provides method claims significant advantage. A claim reciting "receiving user input" describes an act; a claim reciting "means for receiving user input" describes a function. The former avoids § 112(f); the latter invokes it. Practitioners drafting method claims should therefore employ active verbs, describing the steps performed rather than functions achieved. --- ## II. Definiteness and Disclosure: The § 112(b) Imperative ### A. The Constitutional Foundation The definiteness requirement emerges from the Constitution's Progress Clause, which permits Congress to grant exclusive rights only for "limited Times" and only to promote useful arts. A patent grant that fails to define its boundaries effectively claims indefinitely—both in temporal and spatial terms. The public cannot determine when the patent expires or what falls within its scope. Such grants frustrate the constitutional purpose. Section 112(b) operationalizes this constitutional principle, requiring that claims "particularly point[] out and distinctly claim[] the subject matter which the inventor... regards as the invention." The definiteness inquiry asks whether the claim, read in light of the specification and prosecution history, informs those skilled in the art about the scope of the invention "with reasonable certainty." *Nautilus, Inc. v. Biosig Instruments, Inc.*, 572 U.S. 898, 910 (2014). For means-plus-function claims, definiteness depends on structural disclosure. If the claim invokes § 112(f) but the specification fails to disclose corresponding structure—or if that structure is disclosed so ambiguously that one skilled in the art cannot determine the claimed scope—the claim is indefinite. ### B. The Algorithmic Imperative for Software When software patents invoke § 112(f)—either intentionally through "means" or unintentionally through functional claiming—the corresponding structure is, as we have seen, typically a specific algorithm. The failure to disclose that algorithm renders the claim indefinite. This principle reflects software's unique nature. For mechanical inventions, the specification might describe structure through drawings, dimensions, and material specifications. For chemical inventions, through molecular formulas and synthesis pathways. For software, structure exists in logical operations—in the algorithm that transforms inputs into outputs. Without algorithmic disclosure, the public cannot determine what the patentee actually invented. A claim to "means for sorting data" might cover quicksort, mergesort, heapsort, or any of countless other algorithms. Each has different performance characteristics, memory requirements, and implementation complexity. The claim's scope—and thus its validity and infringement analysis—depends entirely on which algorithm the specification discloses. The algorithmic disclosure serves two essential functions. First, it satisfies § 112(a)'s enablement requirement by teaching one skilled in the art how to perform the claimed function. Second, it defines the claim's scope under § 112(f) by identifying the specific structures the claim covers. These requirements work in tandem: the enabling disclosure becomes the limiting disclosure. ### C. The Linkage Requirement: Connecting Function to Structure Disclosure alone, however, does not suffice. The specification must clearly link each disclosed algorithm to its corresponding claimed function. This linkage requirement prevents a common evasion: the specification that discloses numerous algorithms without clearly identifying which performs which claimed function. Consider a specification that describes five different sorting algorithms—quicksort, mergesort, heapsort, insertion sort, and bubble sort. If the claim recites "means for sorting data," which algorithm constitutes the corresponding structure? Without clear linkage, the claim is indefinite. The public cannot determine the claim's scope because multiple potential structures exist, and the specification provides no guidance as to which the patentee intended to claim. Courts employ several tests for adequate linkage: **Explicit Association**: The specification might state, "The sorting means of claim 1 operates using the quicksort algorithm described below." **Contextual Association**: The specification might describe the sorting algorithm immediately after introducing the claimed function, in a manner that makes the connection apparent. **Consistent Terminology**: The specification might use identical terms when describing both the claimed function and the disclosed algorithm, creating implicit linkage. What fails is mere disclosure without connection—algorithms floating untethered in the specification, available for post-hoc association during litigation but providing no notice to the public during the patent term. ### D. The General-Purpose Computer Trap Perhaps no doctrine in software patent law creates more confusion than the "general-purpose computer" trap. Courts repeatedly emphasize that a general-purpose computer or microprocessor, standing alone, typically does not constitute adequate structural disclosure for a computer-implemented means-plus-function claim. The reasoning is straightforward: A general-purpose computer can execute any algorithm. Disclosing that claimed functions are performed by "a computer" or "a processor" therefore provides no information about *how* those functions are performed. It is the algorithmic programming—not the underlying hardware—that constitutes structure for software inventions. This principle creates practical challenges. Many software patent specifications, particularly older ones, describe their inventions in terms of "a computer programmed to perform function X" without disclosing the specific programming. Such specifications fail to provide the structural disclosure § 112(f) requires. The claims, if construed under § 112(f), become indefinite. The trap proves particularly dangerous because it creates false comfort. The specification appears to disclose structure—after all, it describes a computer, which is certainly structural. Yet this apparent structure proves illusory when subjected to § 112(f) analysis. The computer is merely the platform; the algorithm is the structure. Practitioners must therefore ensure that every computer-implemented function—whether in a means-plus-function claim or a claim susceptible to means-plus-function construction—has a corresponding algorithm disclosed in the specification. The algorithm need not be complex or novel, but it must be specific enough that one skilled in the art can understand *how* to perform the claimed function using the disclosed structure. ### E. Adequate Disclosure: What Satisfies the Requirement The question naturally arises: How much algorithmic detail satisfies the disclosure requirement? Must specifications provide source code? Pseudocode? Flowcharts? Prose descriptions? The answer reflects patent law's essential pragmatism: The disclosure must enable one skilled in the art to understand how to perform the claimed function. The form matters less than the clarity. Some algorithms—particularly complex ones—benefit from flowcharts or pseudocode. Others can be adequately described in prose, explaining inputs, processing steps, decision points, and outputs. Consider these examples: **Adequate Prose Description**: > "The sorting algorithm receives an array of data elements and sorts them in ascending order by repeatedly comparing adjacent elements and swapping them if they are in the wrong order. This process continues, with each pass through the array comparing one fewer element (since the largest elements bubble to the end), until a complete pass produces no swaps, indicating the array is sorted." This describes bubble sort with sufficient specificity that one skilled in the art could implement it. **Inadequate Description**: > "The system sorts data using appropriate sorting techniques known in the art." This provides no algorithmic specificity. One skilled in the art could implement *a* sorting algorithm but could not determine *which* algorithm the patentee disclosed as corresponding structure. **Flowchart Alternative**: A flowchart showing: 1. Start with first element 2. Compare to next element 3. If out of order, swap 4. Move to next pair 5. Repeat until end of array 6. If any swaps occurred, repeat from step 1 7. If no swaps, array is sorted This graphically represents the same algorithm, providing equivalent disclosure. The Federal Circuit has accepted all these forms. What matters is whether the disclosure provides sufficient specificity that one skilled in the art can understand the algorithmic approach without undue experimentation. --- ## III. The Art of Structural Claiming: Preventing Unintended § 112(f) Construction ### A. The Strategic Choice Every software patent claim presents a choice: describe the invention structurally (by *how* it operates) or functionally (by *what* it accomplishes). This choice determines whether § 112(f) applies and, consequently, the claim's scope. Structural claiming offers breadth. A claim describing structure may cover any implementation that includes that structure, regardless of what other functions the implementation performs. Functional claiming offers precision. A means-plus-function claim covers structures that perform the specific claimed function, potentially avoiding prior art that performs different functions. Neither approach is inherently superior. The choice depends on the invention, the prior art landscape, and the strategic goals. But the choice must be intentional. Unintended means-plus-function construction—where the drafter intended structural claiming but the courts applied § 112(f)—combines the worst of both worlds: narrow scope without the precision that makes narrow claims valuable. Preventing unintended construction requires understanding what makes claims susceptible to § 112(f) and employing techniques to establish structural character. ### B. The Susceptibility Factors *Williamson* identified several factors that suggest a claim term lacks sufficient structure: 1. **Generic Placeholder Terms**: "Module," "unit," "component," "element," and "device" are susceptible because they serve as generic placeholders for structure rather than describing specific structural implementations. 2. **Functional Recitation**: Claim language that recites functions ("for receiving," "for processing," "for transmitting") without describing operational detail signals functional rather than structural claiming. 3. **Format Similarity to Traditional MPF**: Claims that, despite avoiding "means," follow the format "term + for + function" mirror traditional means-plus-function claiming. 4. **Lack of Operational Context**: Terms used without describing inputs, outputs, connections, or integration with other components lack the operational context that creates software structure. 5. **Specification Silence**: Specifications that describe the claim term only in functional terms, without operational or algorithmic detail, suggest the term connotes no definite structure. Claims exhibiting multiple factors face heightened risk of § 112(f) construction. A claim reciting "communications module for transmitting data," particularly if the specification describes this element only as "transmitting data to remote devices," presents classic § 112(f) characteristics despite avoiding "means." ### C. Structural Claiming Techniques To establish structural character and avoid unintended § 112(f) construction, practitioners can employ several techniques: #### 1. Describe Operational Architecture in Claims Rather than merely naming components, describe how they operate within the system: **Weak (Susceptible)**: > "a processing module for analyzing user input" **Strong (Structural)**: > "a processing module that receives user input from the interface controller, parses the input into discrete commands based on delimiter characters, validates each command against a predefined command set, and forwards validated commands to the execution engine" The strong version describes inputs (from interface controller), processing (parsing, validation), and outputs (to execution engine), providing the operational context that creates software structure. #### 2. Specify Integration with Other Components Structure in software emerges partly from relationships. Describing how a component connects to and interacts with other components provides structural definition: **Weak**: > "a communication unit for exchanging data" **Strong**: > "a communication unit connected to the message queue, configured to retrieve outbound messages from the queue, format the messages according to the protocol handler's specifications, and transmit the formatted messages via the network interface while monitoring acknowledgment signals returned to the queue status tracker" The strong version establishes structure through described connections (to message queue, protocol handler, network interface, status tracker) and specific operational flow. #### 3. Use Structurally Descriptive Terms Some terms inherently connote more structure than others: **More Structural**: - "parser" (implies specific parsing algorithm) - "compiler" (implies lexical analysis, syntax analysis, code generation) - "controller" (implies control logic and state management) - "engine" (implies processing mechanism with inputs/outputs) **Less Structural**: - "module" (generic container) - "unit" (generic component) - "element" (generic part) - "device" (generic apparatus) While term selection alone cannot overcome functional claiming, structurally descriptive terms support structural interpretation. #### 4. Avoid Pure Functional Recitation Claims should describe *how* elements operate, not merely *what* they accomplish: **Functional (Weak)**: > "means for sorting data in ascending order" **Structural (Strong)**: > "a quicksort engine that partitions data around pivot elements selected using median-of-three selection, recursively sorts the partitions, and combines the results" Even stronger—integrate the operational description with system context: > "a quicksort engine that receives unsorted data from the data buffer, partitions the data around pivot elements selected using median-of-three selection from the first, middle, and last elements of each partition, recursively processes partitions smaller than the current partition in depth-first order, and stores the sorted result in the output buffer" This describes not merely the algorithm but its integration with the larger system. #### 5. Provide Algorithmic Specification Detail While claims need not recite complete algorithms, the specification should provide detailed algorithmic descriptions for every functional element: - **Inputs**: What data does the element receive? In what format? - **Processing**: What operations does the element perform? In what sequence? - **Decision Points**: What conditions trigger different processing paths? - **Outputs**: What results does the element produce? Where do they go? - **State Management**: Does the element maintain state? How is it updated? Detailed specification support enables structural claim interpretation. Even if a claim term receives § 112(f) construction, adequate specification disclosure preserves claim validity. ### D. The Claim Differentiation Strategy When drafting patent applications, consider including both structural and explicit means-plus-function claims. This provides multiple strategic benefits: **Establishes Structural Intent**: The presence of explicit means-plus-function claims (using "means") suggests that claims not using "means" were intended as structural claims. Courts employ the doctrine of claim differentiation, presuming that different claims have different scope. **Provides Fallback Protection**: If structural claims receive § 112(f) construction, explicit means-plus-function claims remain available for enforcement, avoiding total claim loss. **Creates Uncertainty for Competitors**: Potential infringers must analyze whether structural claims cover their implementations directly *and* whether means-plus-function claims cover them under the doctrine of equivalents. **Preserves Prosecution Flexibility**: Different claim types provide different arguments against prior art, increasing likelihood of allowance. The claim differentiation strategy reflects a fundamental principle: redundancy in patent claiming is not waste but insurance. The cost of additional claims is minimal; the cost of losing all claims to unexpected construction is potentially catastrophic. --- ## IV. Responding to Improper USPTO Invocation: When Examiners Get It Wrong ### A. The Examination Reality USPTO examiners, working under time constraints with varying levels of expertise in software patent prosecution, sometimes improperly invoke § 112(f) for claim terms that possess sufficient structural character. When this occurs, practitioners must respond effectively to overcome the rejection while preserving claim scope. The challenge is threefold: demonstrate that the claim term connotes sufficient structure; prove that even if § 112(f) applies, adequate corresponding structure exists; and avoid amendments that unnecessarily narrow claim scope or create prosecution history estoppel. ### B. Structural Arguments: Establishing Step 1 The primary response should focus on demonstrating that the claim term has "sufficiently definite meaning as the name for structure" to one skilled in the art. This requires: #### 1. Point to Claim Language Context Emphasize that the two-step analysis considers the *entire claim phrase*, not merely the introductory term. As *Apple* held, "the entire limitation in question" determines whether § 112(f) applies. 757 F.3d at 1296. **Example Response**: > "The Office improperly focuses on the term 'processing module' in isolation. The complete limitation recites 'a processing module that receives data packets from the network interface, extracts header information from each packet based on the protocol specification, validates the header fields against predetermined criteria, and routes valid packets to the application handler.' This complete phrase describes the module's operation, including its inputs (data packets from network interface), processing (header extraction, validation), decision logic (validity checking), and outputs (routing to application handler). Such operational detail provides the 'how' that constitutes software structure under Apple." #### 2. Reference Software-Specific Structure Principles Remind the examiner that software structure may be understood through "an outline of an algorithm, a flowchart, or a specific set of instructions or rules." *Apple*, 757 F.3d at 1298-99. **Example Response**: > "For software inventions, structure is properly understood through algorithmic and operational descriptions. As the Federal Circuit held in Apple, 'persons skilled in the art may understand a computer-implemented invention's structure through, for example, an outline of an algorithm, a flowchart, or a specific set of instructions or rules.' The claims describe the module's algorithmic operation—the specific processing steps it performs—providing structural definition appropriate for software inventions." #### 3. Demonstrate Operational Context Highlight how the claim describes the element's operation within the larger system, including inputs, outputs, and connections to other components: **Example Response**: > "The claim provides operational context that establishes structure. The 'authentication engine' receives credentials from the login interface, compares them against stored credentials in the user database using hash comparison, generates session tokens upon successful authentication, and returns the tokens to the session manager. These inputs, processing steps, and outputs describe *how* the engine operates, not merely *what* it accomplishes. This operational description provides the structural definition necessary to avoid § 112, ¶ 6." #### 4. Cite Declaration Evidence If necessary, provide a declaration from one skilled in the art stating that the claim term, in context, connotes definite structure: **Example Declaration Content**: > "As one skilled in the art of network security systems, I understand the term 'authentication engine that receives credentials from the login interface, compares them against stored credentials using hash comparison, and generates session tokens' to describe a specific structural implementation. The limitation describes the engine's inputs (credentials from login interface), its processing methodology (hash comparison against stored credentials), and its outputs (session tokens). This level of detail would enable me to implement the authentication engine without requiring further structural information. The claim term, in context, has sufficiently definite meaning as the name for structure." ### C. Specification Support Arguments: Addressing Step 2 Even if the examiner persists in applying § 112(f), demonstrate that the specification provides adequate corresponding structure: #### 1. Identify Disclosed Algorithms Point to specific passages in the specification that disclose algorithms, flowcharts, or operational descriptions for the claimed function: **Example Response**: > "Even if § 112, ¶ 6 were to apply (which applicant respectfully submits it does not), the specification discloses adequate corresponding structure. Paragraph [0034] describes the authentication process: 'The authentication engine receives user credentials including username and password, applies the SHA-256 hash function to the received password, compares the hash result to the stored hash value associated with the username in the user database, and upon finding a match, generates a time-limited session token encoded with the user's access privileges.' This algorithmic disclosure satisfies the requirement for corresponding structure." #### 2. Demonstrate Clear Linkage Show that the specification clearly associates the disclosed algorithm with the claimed function: **Example Response**: > "The specification clearly links the disclosed algorithm to the claimed function. The claim recites 'authentication engine for validating user credentials.' The specification, at paragraph [0034], introduces the authentication engine by stating: 'The authentication engine performs user credential validation as follows...' This explicit connection satisfies the linkage requirement articulated in Noah Systems." #### 3. Address the General-Purpose Computer Issue If the examiner argues that the specification merely recites a general-purpose computer, demonstrate that specific algorithmic detail supplements the hardware description: **Example Response**: > "While the specification discloses that the authentication engine may be implemented using a general-purpose processor, it provides the specific algorithmic detail required by Aristocrat Technologies. The specification does not merely state that 'a computer performs authentication.' Rather, it discloses the specific hash algorithm (SHA-256), the specific comparison methodology (hash comparison against stored values), and the specific token generation approach (time-limited encoding of access privileges). This level of algorithmic detail transforms the general-purpose processor into a special-purpose authentication engine—the corresponding structure required by § 112, ¶ 6." ### D. Amendment Strategies: When Arguments Fail If arguments prove unsuccessful, consider strategic amendments. The goal is to add sufficient structural detail to overcome the rejection while preserving maximum claim scope. #### 1. Add Operational Detail to Claims Amend the claim to include operational context that establishes structure: **Original Claim**: > "a data processing module for analyzing network traffic" **Amended Claim**: > "a data processing module configured to receive network packets from the packet capture interface, extract packet metadata including source address, destination address, and port information, compare the metadata against traffic pattern rules stored in the rule database, identify packets matching suspicious patterns, and forward matching packets to the alert generation system" This amendment adds "configured to" language followed by operational detail, establishing that the module's structure includes the capability to perform these specific operations in this specific sequence. #### 2. Reference Specification Embodiments Amend to incorporate structural details from specification embodiments: **Original Claim**: > "a sorting module for arranging data elements" **Amended Claim**: > "a quicksort module that partitions data elements around pivot elements selected using median-of-three selection, recursively processes partitions, and combines sorted results, as described in Fig. 3 and paragraphs [0042]-[0045]" This amendment incorporates specific algorithmic structure while maintaining flexibility through the "as described" language. #### 3. Add Structural Terms Replace generic terms with more structurally descriptive alternatives: **Original**: "processing unit" **Amended**: "processing engine" **Original**: "communication module" **Amended**: "communication controller" **Original**: "data element" **Amended**: "data parser" While term substitution alone may not suffice, combining it with operational detail strengthens the structural character. ### E. Strategic Considerations When responding to improper § 112(f) invocation, consider: **Preserve Prosecution History**: Amendments and arguments create prosecution history that may limit claim scope during litigation. Avoid conceding that terms lack structure or that § 112(f) applies unless absolutely necessary. **Maintain Consistency**: If the application includes multiple claims with similar terms, ensure amendments and arguments apply consistently across all claims. **Future-Proof Applications**: When drafting new applications, include detailed operational descriptions in both claims and specifications to prevent § 112(f) issues before they arise. **Consider RCE Strategy**: If initial arguments fail, consider a Request for Continued Examination (RCE) with more detailed declaration evidence rather than immediately amending claims. --- ## V. Strategic Use of Means-Plus-Function Claims: Turning Constraint into Opportunity ### A. The Strategic Paradox Means-plus-function claiming appears constraining—it narrows claim scope to disclosed structures and their equivalents. Yet this apparent weakness can become strategic strength. The question is not whether MPF claims are good or bad, but when and how they serve the patentee's interests. Consider three scenarios: **Scenario 1: Broad Prior Art** Prior art discloses numerous structures that perform the claimed function. A structural claim would likely face anticipation or obviousness rejections. But an MPF claim, limited to your specific disclosed structure, may avoid the prior art by distinguishing your particular implementation from prior approaches. **Scenario 2: Rapidly Evolving Technology** Technology evolves such that future implementations may perform the same function using entirely different structures. An MPF claim, through the doctrine of equivalents, may cover these future implementations if they perform substantially the same function in substantially the same way. A structural claim, tied to current implementation details, might prove too narrow. **Scenario 3: Portfolio Strategy** You seek comprehensive protection through a portfolio of claims with different scopes and vulnerability profiles. MPF claims provide an additional layer of protection, covering implementations that avoid the specific structural language of other claims but perform equivalent functions. These scenarios illustrate that MPF claiming is not inherently inferior—it serves different strategic purposes than structural claiming. ### B. The Equivalents Advantage The doctrine of equivalents provides MPF claims with a unique advantage: they cover not only disclosed structures but also equivalent structures—those that perform substantially the same function in substantially the same way to achieve substantially the same result. This creates strategic uncertainty for competitors. Analyzing whether an alternative implementation constitutes an equivalent requires fact-intensive inquiry, often resolvable only through expert testimony at trial. Potential infringers facing MPF claims must therefore assess not only whether their implementation matches disclosed structures but also whether it might constitute an equivalent—a significantly more difficult and expensive analysis. This uncertainty benefits patentees in several ways: **Settlement Leverage**: Uncertain claim scope favors settlement over litigation risk. **Design-Around Difficulty**: Competitors cannot simply study disclosed structures and design around them; they must also consider equivalents. **Future Implementation Coverage**: Technologies not yet invented may constitute equivalents if they perform the same function in substantially the same way. **Prosecution Flexibility**: During prosecution, MPF claims provide arguments unavailable to structural claims—you can distinguish prior art based on structural differences even when functional similarities exist. ### C. The Claim Differentiation Strategy Revisited The most powerful use of MPF claims comes through claim differentiation—including both structural and MPF claims in the same patent. This strategy provides: #### 1. Presumption of Different Scope Courts presume different claims have different scope. Explicit MPF claims (using "means") create a presumption that claims not using "means" are structural. This helps prevent unintended § 112(f) construction of structural claims. #### 2. Dual Protection Paths Structural claims may cover implementations that perform functions beyond those claimed, while MPF claims specifically target implementations performing the claimed functions regardless of additional capabilities. #### 3. Prosecution Benefits During prosecution, you can amend structural claims to overcome prior art while maintaining MPF claims, or vice versa. Different claim types provide different arguments and amendment options. #### 4. Litigation Flexibility During litigation, you can assert different claims against different defendants based on their specific implementations. Some infringers may practice structural limitations literally; others may infringe under equivalents doctrine applicable to MPF claims. ### D. Disclosure Strategy for MPF Claims When intentionally using MPF claims, specification disclosure becomes critical. The specification should: #### 1. Disclose Multiple Embodiments Provide multiple structural implementations for each claimed function. This expands the literal scope (multiple disclosed structures) while also supporting broader equivalents (demonstrating various ways to achieve the function). **Example**: > "The sorting means may be implemented using any of several algorithms known in the art, including but not limited to quicksort, mergesort, heapsort, or timsort. In one embodiment, shown in Fig. 3, the sorting means implements a quicksort algorithm with median-of-three pivot selection. In another embodiment, shown in Fig. 4, the sorting means implements a mergesort algorithm with optimized memory allocation. In yet another embodiment, the sorting means implements a hybrid approach using insertion sort for small partitions and quicksort for larger partitions." #### 2. Describe Equivalence Principles Explain what makes different implementations equivalent, establishing a framework for later equivalents analysis: **Example**: > "While specific sorting algorithms are disclosed, those skilled in the art will recognize that the invention is not limited to these particular implementations. Any sorting algorithm that achieves O(n log n) average-case performance through divide-and-conquer methodology would serve the same function in substantially the same way." #### 3. Include Algorithmic Detail Provide sufficient algorithmic detail for each disclosed embodiment to satisfy § 112(b) definiteness: **Example**: > "The quicksort implementation (Fig. 3) operates as follows: (1) if the partition contains fewer than two elements, return; (2) select pivot using median-of-three from first, middle, and last elements; (3) partition elements into those less than pivot and those greater than pivot; (4) recursively sort each partition; (5) combine results." #### 4. Link Functions to Structures Clearly associate each claimed function with its corresponding disclosed structure(s): **Example**: > "The 'means for sorting data' recited in claim 1 corresponds to the sorting algorithms described in paragraphs [0042]-[0058] and illustrated in Figures 3-5, including the quicksort implementation of Figure 3, the mergesort implementation of Figure 4, and the hybrid approach of Figure 5." ### E. Portfolio Architecture: Combining Claim Types A sophisticated patent portfolio employs multiple claim types strategically: #### 1. Method Claims Describe the process, avoiding § 112(f) issues through active-voice verbs: **Example**: > "A method for processing network data, comprising: receiving data packets from a network interface; extracting header information from each packet; validating the header information against predetermined criteria; and routing valid packets to an application handler." Method claims provide process coverage, target direct infringers who perform the method, and typically avoid § 112(f) construction issues. #### 2. Structural Apparatus Claims Describe the system structure, providing detailed operational context: **Example**: > "A network processing system comprising: a packet receiver configured to receive data packets from a network interface and extract header information; a validation engine configured to compare extracted header information against predetermined criteria and identify valid packets; and a routing controller configured to direct valid packets to an application handler." Structural claims provide broad apparatus coverage and may capture implementations that perform additional functions beyond those claimed. #### 3. Means-Plus-Function Claims Claim functions explicitly, covering disclosed structures and equivalents: **Example**: > "A network processing apparatus comprising: means for receiving data packets and extracting header information; means for validating the header information against predetermined criteria; and means for routing valid packets to an application handler." MPF claims provide equivalents protection and prosecution flexibility while creating claim differentiation that supports structural interpretation of non-MPF claims. #### 4. Hybrid Claims Combine structural limitations with MPF limitations in a single claim: **Example**: > "A network processing system comprising: a packet receiver configured to receive data packets from a network interface; means for validating header information against predetermined criteria; and a routing controller configured to direct valid packets to an application handler." Hybrid claims allow structural claiming for well-developed aspects while using MPF for aspects where equivalents coverage is desired or where structural claiming might face prior art issues. ### F. Litigation Considerations The choice between structural and MPF claiming affects litigation strategy: #### 1. Claim Construction Hearings MPF claims require identification of corresponding structure during Markman proceedings. This frontloads specification interpretation but also creates opportunities to demonstrate multiple disclosed embodiments and broad equivalents. #### 2. Expert Testimony MPF equivalents analysis typically requires expert testimony regarding whether accused implementations perform substantially the same function in substantially the same way. This increases litigation costs but also creates settlement pressure. #### 3. Jury Instructions MPF claims require special jury instructions on equivalents, which can complicate but also enrich the infringement case by providing multiple theories of liability. #### 4. Invalidity Defense Defendants challenging MPF claims must prove both that claims invoke § 112(f) *and* that specifications lack adequate structure. This two-part burden can make invalidity harder to prove than for structural claims, where definiteness is the sole inquiry. ### G. Future-Proofing Through MPF Claims Perhaps MPF claiming's greatest strategic value lies in future-proofing. Technology evolves rapidly, and claims that seem broad today may prove narrow tomorrow as new implementation approaches emerge. MPF claims, through equivalents doctrine, can adapt to technological evolution. A claim to "means for encrypting data" disclosed with AES-256 in 2025 might cover quantum-resistant encryption algorithms in 2035 if those algorithms perform substantially the same function (securing data against unauthorized access) in substantially the same way (mathematical transformation rendering data unintelligible without key) achieving substantially the same result (confidentiality protection). Structural claims, by contrast, risk obsolescence. A claim to "an AES-256 encryption engine" likely does not cover quantum-resistant algorithms because the structural implementation differs, even if the function and result are identical. This future-proofing value makes MPF claims particularly attractive for foundational inventions in rapidly evolving fields where current implementations will inevitably be superseded. --- ## Conclusion: The Architecture of Choice The tension between § 112(b)'s definiteness requirement and § 112(f)'s functional claiming accommodation reflects a fundamental truth about patent law: it asks inventors to describe their inventions with both precision and foresight, to claim specifically enough that the public understands the boundaries of the grant, yet broadly enough that the claims capture the invention's value. For software patents, this tension manifests in questions of structure. What makes a claim structural rather than functional? When must specifications disclose algorithms? How much operational detail suffices? These questions have no formulaic answers because they depend on context—the specific claim language, the specification's teachings, the understanding of those skilled in the art, and the strategic goals the patent serves. Yet through the cases we have examined—*Williamson* and *Apple*, *Aristocrat* and *Noah Systems*—certain principles emerge: **First**, structure in software means algorithmic operation, not physical form. Claims describe software structure through inputs, outputs, processing steps, and integration with other components. **Second**, the word "means" matters less than the operational detail. Claims that describe *how* elements operate connote structure regardless of terminology; claims that describe only *what* elements accomplish invite § 112(f) construction. **Third**, specifications must disclose algorithms for computer-implemented functions and clearly link those algorithms to claimed functions. General-purpose computers without algorithmic programming do not constitute adequate structure. **Fourth**, the choice between structural and MPF claiming is strategic, not absolute. Both approaches serve legitimate purposes; the question is which serves the particular invention's needs given its prior art landscape, technology evolution, and enforcement goals. **Fifth**, claim differentiation—employing both structural and MPF claims in the same patent—provides the most robust protection by combining the breadth of structural claims with the equivalents coverage of MPF claims. These principles guide, but they do not dictate. Each patent presents unique challenges requiring judgment calls about how to balance breadth against validity, present coverage against future flexibility, and prosecution efficiency against litigation positioning. The practitioner's task is to make these choices intentionally, with full awareness of their implications. To draft claims that achieve the client's strategic objectives while satisfying the statute's requirements. To build specifications that support both structural interpretations and MPF fallback positions. To respond to improper examiner constructions while preserving maximum claim scope. This requires technical skill, legal knowledge, and strategic vision. But it also requires something more fundamental: understanding that patent law's complexity reflects not bureaucratic excess but genuine difficulty—the difficulty of describing tomorrow's technology in today's language, of balancing private incentives with public knowledge, of creating clear boundaries for innovations whose very nature resists fixed definition. Software structure exists in algorithms and logic, in relationships and operations, in transformations of data from one form to another. It is real structure, but structure of a different kind than the mechanical arts contemplated when patent law's foundations were laid. The doctrine we have examined represents the law's effort to adapt ancient principles to modern circumstances, to preserve the patent system's grand bargain—exclusive rights in exchange for public disclosure—in an age where innovation increasingly occurs in code. The cases will continue to evolve. Technology will continue to advance. But the fundamental principles will endure: Claims must provide notice. Specifications must enable and disclose. The public must understand what the patent claims. And inventors who satisfy these requirements earn the exclusive rights the Constitution contemplates. Navigate the doctrine with care and intention. Draft with precision and strategic purpose. And remember that every choice about claim structure shapes not merely prosecution outcomes but the patent's entire life—from examination through enforcement, from today's technology to tomorrow's innovations. --- ## Key Principles: Twenty Guideposts for Practice **Understanding Means-Plus-Function:** 1. The presence or absence of "means" creates presumptions, but operational context and structural detail ultimately determine § 112(f) application. 2. For software inventions, structure emerges from algorithmic disclosure—flowcharts, pseudocode, or detailed operational descriptions. 3. Generic placeholder terms ("module," "unit," "component") face heightened scrutiny and require strong operational context to avoid § 112(f). 4. The general-purpose computer exception is narrow—algorithmic disclosure remains the prudent course for all computer-implemented functions. 5. Method claims using active verbs ("-ing" forms) generally avoid § 112(f); only "step[s] for" without recited acts invokes the statute. **Ensuring Definiteness:** 6. Specifications must disclose specific algorithms for all computer-implemented means-plus-function claims. 7. Algorithmic disclosure serves dual purposes: satisfying § 112(a) enablement and defining § 112(f) scope. 8. Disclosed algorithms must be clearly linked to claimed functions through explicit association, contextual placement, or consistent terminology. 9. Multiple algorithms disclosed without clear linkage create indefiniteness—the public cannot determine which structure corresponds to which function. 10. Adequate disclosure varies in form (flowcharts, pseudocode, prose) but must enable one skilled in the art to understand *how* to perform the claimed function. **Preventing Unintended Construction:** 11. Claims should describe *how* elements operate (inputs, outputs, processing, connections), not merely *what* they accomplish. 12. Operational context within the claim itself provides the strongest defense against unintended § 112(f) construction. 13. Specification support matters—detailed algorithmic descriptions support structural claim interpretations while providing MPF fallback. 14. The entire claim phrase determines structure, not the introductory term in isolation. **Responding to USPTO:** 15. When examiners improperly invoke § 112(f), emphasize operational detail in the complete claim phrase, not just the claim term. 16. Software structure includes algorithmic and operational descriptions—physical structure is not required. 17. Demonstration that one skilled in the art would understand the claim term to connote definite structure defeats § 112(f) application. 18. Strategic amendments should add operational context while preserving maximum scope and avoiding unnecessary prosecution history. **Strategic Use:** 19. Claim differentiation—including both structural and explicit MPF claims—provides optimal protection through breadth plus equivalents coverage. 20. MPF claims offer strategic advantages: narrowing to avoid prior art, equivalents coverage for future implementations, and settlement leverage through scope uncertainty. --- ## Table of Authorities | Case | Citation | Principle | |------|----------|-----------| | *Williamson v. Citrix Online, LLC* | 792 F.3d 1339 (Fed. Cir. 2015) | Eliminated "strong presumption" language; standard is whether term has "sufficiently definite meaning as the name for structure" | | *Apple Inc. v. Motorola, Inc.* | 757 F.3d 1286 (Fed. Cir. 2014) | Software structure emerges from describing operation (*how*), including inputs, outputs, connections; "heuristic" had structure | | *Aristocrat Techs. Australia v. Int'l Game Tech.* | 521 F.3d 1328 (Fed. Cir. 2008) | Corresponding structure for software MPF must be specific algorithm, not merely general-purpose computer | | *Nautilus, Inc. v. Biosig Instruments, Inc.* | 572 U.S. 898 (2014) | Claims must inform those skilled in the art about scope "with reasonable certainty" | | *Noah Systems, Inc. v. Intuit Inc.* | 675 F.3d 1302 (Fed. Cir. 2012) | Disclosed algorithm must be clearly linked to claimed function; mere presence in specification insufficient | | *In re Katz* | 639 F.3d 1303 (Fed. Cir. 2011) | Narrow exception for standard computer functions like "processing," "receiving," "storing" | | *O.I. Corp. v. Tekmar Co.* | 115 F.3d 1576 (Fed. Cir. 1997) | Method claims: § 112(f) applies only to "step[s] for" without recited acts; "-ing" verbs describe acts | | *Advanced Ground Info. Sys. v. Life360* | 830 F.3d 1341 (Fed. Cir. 2016) | "Symbol generator" indefinite because specification failed to disclose *how* function performed | | *XR Communications v. Arris Solutions* | No. 2022-1125 (Fed. Cir. 2023) | Emphasized need for "sufficient structure to perform the claimed functions," not merely any structure | | *Joao Control & Monitoring Sys. v. Protect Am.* | No. 1-14-CV-134-LY (W.D. Tex. 2015) | Court examines "entire claim phrase," not just introductory term | | *Corus Realty Holdings v. Zillow* | No. C18-0847JLR (W.D. Wash. 2019) | "Map generation unit" had structure through description of inputs, outputs, and operation | | *Cypress Lake Software v. Samsung* | 382 F. Supp. 3d 586 (E.D. Tex. 2019) | "Navigation element handler component" indefinite—no algorithm disclosed in any form | --- *This article is intended for informational purposes only and does not constitute legal advice. Patent law continues to evolve through court decisions and USPTO guidance. Practitioners should consult current authorities and consider obtaining professional legal counsel for specific matters.*