# The § 112(f) Survival Guide: What Software Patent Prosecutors Actually Need to Know ![[Means Plus Function.avif]] > Congress gave us a statute. The Courts gave us lots of "factors." Here's how to navigate both. **By Paul Roberts** | 🔍 Critical Spotlight\ ⌨️ **6,195 words** | ⏱️ **25 min read** #Legal_Guides #35_USC_112f #Critical_Spotlight #PatentLaw #Software December 27, 2024 --- ## What You're Up Against Software patent prosecutors face a brutal reality: use generic terms like "module" or "component," and examiners will invoke § 112(f) means-plus-function. If your spec lacks the "corresponding structure"—which for software means a specific algorithm—your claim dies under § 112(b) indefiniteness. The statute itself is simple. The case law? Not so much. This guide cuts through the confusion with five straightforward sections: I. **How § 112(f) Actually Works for Software**: What the statute says, how courts apply it, and why algorithms matter II. **Keeping Your Claims Definite**: Algorithm disclosure that survives § 112(b) challenges III. **Avoiding Accidental § 112(f) Invocation**: Drafting techniques that keep your structural claims structural IV. **Fighting Improper Examiner Rejections**: What to do when the USPTO gets it wrong V. **When to Use § 112(f) on Purpose**: Strategic advantages of means-plus-function claims The bottom line: § 112(f) is a tool, not a trap. But only if you know how to use it. --- ## I. How § 112(f) Actually Works for Software ### The Statute Says What It Says Here's the text of 35 U.S.C. § 112(f): > "An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof." **Translation:** You can claim by function if you use "means" or "step for." But your specification must disclose the actual structure that performs that function. For software, that structure is an algorithm—not just "a computer." The Federal Circuit got this exactly right in *Aristocrat*: > "In a means-plus-function claim in which the disclosed structure is a computer or a microprocessor programmed to carry out an algorithm, a corresponding structure must be a specific algorithm disclosed in the specification, rather than merely an algorithm executed by a computer." *Aristocrat Techs. Australia Pty Ltd. v. Int'l Game Tech.*, 521 F.3d 1328, 1331-32 (Fed. Cir. 2008). Why does this matter? Because software has no physical structure. The "structure" is the algorithm—the step-by-step instructions that transform a generic processor into your specific invention. ### The Two-Step Analysis: Where Things Get Complicated When your claim doesn't use the word "means," courts still might invoke § 112(f). They use a two-step test that, despite its simplicity, generates endless confusion. #### Step 1: Does Your Claim Term Have Sufficiently Definite Structure? **The Basic Question** Does the claim limitation, "read in light of the remaining claim language, specification, prosecution history, and relevant extrinsic evidence," convey sufficiently definite structure to someone skilled in the art? *Apple Inc. v. Motorola, Inc.*, 757 F.3d 1286, 1296 (Fed. Cir. 2014). **The Critical Principle** To survive Step 1, the structure must be in the claim term itself when read in light of the specification. *Williamson v. Citrix Online, LLC*, 792 F.3d 1339, 1350 (Fed. Cir. 2015). Here's what that means: Your claim term must describe **HOW** the function is achieved, not just **WHAT** the function is. **What "Structure" Means for Software** The Federal Circuit explained this in *Apple*: > "Because software does not contain physical structures, 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.'" *Apple*, 757 F.3d at 1298-99. > "A claim term relating to such an invention may also have sufficient structure where there is a description of the term's 'operation, such as its input, output, or connections.' The limitation's operation is more than just its function; it is **how the function is achieved** in the context of the invention." *Id.* at 1299 (emphasis added). **Translation:** For software patents, "structure" means: - The inputs and outputs - How the element interacts with other components - The integration with the rest of the system - The specific processing steps—the "how," not just the "what" **Apple v. Motorola: How to Win at Step 1** In *Apple*, the term "heuristic" avoided § 112(f) because the claims described what the heuristics actually did. The claims specified "the initial angle of a finger contact, the number of fingers making contact, the direction of movement of a finger contact, a specific swiping gesture, tapping a certain location on the screen, or the angle of movement of a finger on the screen." *Apple*, 757 F.3d at 1300-01, 1303. That's structure. Not because "heuristic" is a fancy word, but because the claims explained *how* the heuristics worked—their inputs, their rules, their outputs. **Williamson v. Citrix: How to Lose at Step 1** In *Williamson*, the claim recited "distributed learning control module" with three functions: "for receiving communications... and for relaying the communications... and for coordinating the operation..." The Federal Circuit held this invoked § 112(f). Why? Because the claim just listed functions without explaining how the module performed them. The court noted the limitation was "in a format consistent with traditional means-plus-function claim limitations" because it "replaces the term 'means' with the term 'module' and recites three functions." *Williamson*, 792 F.3d at 1350. **The Entire Phrase Matters** Courts don't just look at the introductory noun ("module," "unit," "component"). They examine "the entire claim phrase," including all the functional language that follows. *Joao Control & Monitoring Sys. LLC v. Protect Am., Inc.*, No. 1-14-CV-134-LY, at 12 (W.D. Tex. Aug. 18, 2015); *Williamson*, 792 F.3d at 1350. So if you write "authentication module for verifying user credentials and granting access," the court looks at the whole thing. If all you've done is list functions without explaining the "how," you're invoking § 112(f) whether you meant to or not. #### Step 2: Finding the Corresponding Structure (When Step 1 Fails) If your claim term lacks sufficient structure at Step 1, the court moves to Step 2. This has two parts: **Part A: Is There Corresponding Structure in the Specification?** The specification must disclose structure that performs the claimed function. For software, that means an algorithm. What counts as an algorithm? The Federal Circuit has accepted: - Step-by-step instructions - Flowcharts - Detailed operational descriptions - Pseudocode - Actual code What doesn't count: - Pointing to "a general-purpose computer" - Restating the function in different words - High-level functional descriptions **The General-Purpose Computer Exception (Which Barely Exists)** There's a narrow exception: if the function is so basic that any general-purpose computer can perform it without special programming, you might not need a specific algorithm. *In re Katz*, 639 F.3d 1303, 1316 (Fed. Cir. 2011). But this exception is vanishingly narrow. As the Federal Circuit made clear, it applies only to functions like "storing," "processing," or "receiving"—the kind of things any computer does as part of its standard operation. *Id.* If your function requires any specialized processing—and most software inventions do—you need to disclose an algorithm. **Part B: Is the Structure Clearly Linked to the Function?** Even if you've disclosed an algorithm somewhere in your spec, it must be clearly linked to the claimed function. Courts won't hunt through your specification to connect the dots. *Noah Systems, Inc. v. Intuit Inc.*, 675 F.3d 1302, 1312 (Fed. Cir. 2012). **Translation:** Use the same terminology in your specification that you use in your claims. If your claim recites "authentication module," your spec should explicitly describe "the authentication module" and its algorithm—not just describe authentication somewhere in Figure 5 without connecting it to the claimed element. ### When the Structure Is Missing: Indefiniteness Under § 112(b) Here's where things get brutal. If § 112(f) applies and your specification lacks the required corresponding structure, your claim is indefinite under § 112(b). The Federal Circuit has been consistent about this: **Advanced Ground Info. Sys. v. Life360**, 830 F.3d 1341 (Fed. Cir. 2016): "Symbol generator" invoked § 112(f), but the specification only described *what* the symbol generator did, not *how* it did it. The court held the claims indefinite because "one skilled in the art would not know what structure corresponds to the means or step-plus-function limitation." **Cypress Lake Software v. Samsung**, 382 F. Supp. 3d 586 (E.D. Tex. 2019): "Navigation element handler component" invoked § 112(f), but the specification disclosed no algorithm. Claims indefinite. The pattern is clear: § 112(f) plus no algorithm equals indefinite claims. ### Recent Developments: XR Communications The Federal Circuit's 2023 decision in *XR Communications* refined the test. The court emphasized that it's not enough to have *any* structure—you need "sufficient structure to perform the claimed functions." *XR Communications v. Arris Solutions*, No. 2022-1125 (Fed. Cir. 2023). **What this means:** Even if you've disclosed some structure, if it doesn't actually explain how to perform the claimed function, you haven't met the requirement. --- ## II. Keeping Your Claims Definite: The § 112(b) Compliance Framework If § 112(f) applies to your claims, you need to disclose the corresponding structure. For software, that means algorithms. Here's how to do it right. ### Algorithm Disclosure Requirements **What You Must Disclose** The Federal Circuit has been clear about what counts as adequate algorithm disclosure: 1. **Specific step-by-step process**: The algorithm must provide enough detail that a skilled artisan can implement it without undue experimentation. 2. **More than just the function restated**: Describing *what* the algorithm does is not enough. You must describe *how* it does it. 3. **Sufficient detail for the complexity**: Simple functions require less detail; complex functions require more. **What Formats Work** Courts have accepted algorithms disclosed as: - Written instructions (numbered steps) - Flowcharts with detailed descriptions - Pseudocode - Actual source code - Mathematical formulas - Detailed operational descriptions **What Doesn't Work** The following are insufficient: - Pointing to a "general-purpose computer" or "processor" - Describing the function in different words - Listing components without explaining how they interact - High-level block diagrams without operational detail - Referring to "conventional" or "well-known" techniques without explaining them ### The Linkage Requirement It's not enough to disclose an algorithm somewhere in your specification. You must clearly link it to the claimed function. **Good Linkage Examples:** "The authentication module performs the authentication function as shown in FIG. 4. As illustrated, the authentication module receives user credentials (step 402), compares them against stored credentials in database 210 (step 404), and generates an access token if they match (step 406)." "The encryption component encrypts the data according to the algorithm shown in FIG. 7 and described below. First, the component generates a random initialization vector (step 702)..." **Bad Linkage Examples:** ❌ "Authentication is performed using conventional techniques." ❌ "FIG. 4 shows an encryption process." (No connection to claimed element) ❌ "The system uses AES encryption." (Which component? How?) **The Test:** Could a skilled artisan, reading your specification, identify which algorithm corresponds to which claimed function without guessing? ### How Much Detail Is Enough? The Federal Circuit's test: "An algorithm in the specification need only disclose adequate defining structure to render the bounds of the claim understandable." *Typhoon Touch Techs., Inc. v. Dell, Inc.*, 659 F.3d 1376, 1385 (Fed. Cir. 2011). **Translation:** The algorithm must be detailed enough that someone skilled in the art would know what structure performs the function and could implement it. **Factors Courts Consider:** 1. **Complexity of the function**: More complex functions require more detailed algorithms. 2. **Skill in the art**: If the function is well-known to skilled artisans, less detail may be needed. 3. **Amount of detail in the claims**: Claims reciting specific details may require correspondingly detailed algorithms. ### Practical Checklist for Algorithm Disclosure For each claim element that might invoke § 112(f), ensure your specification includes: ✅ **Identification**: Explicitly identify the algorithm that performs the claimed function ✅ **Location**: Provide clear reference (e.g., "as shown in FIG. 4," "as described below") ✅ **Format**: Present the algorithm in a recognized format (steps, flowchart, pseudocode) ✅ **Detail**: Include enough detail that a skilled artisan could implement it ✅ **Linkage**: Use consistent terminology between claims and specification ✅ **Inputs/Outputs**: Specify what goes in and what comes out ✅ **Processing**: Explain the transformation or decision-making logic ✅ **Integration**: Show how the algorithm interacts with other components ### Special Considerations for Machine Learning Algorithms Machine learning presents unique challenges for algorithm disclosure. The Federal Circuit hasn't definitively addressed this, but practitioners should consider: **Disclose the Training Process:** - Data preprocessing steps - Feature extraction methodology - Model architecture (neural network layers, decision tree structure, etc.) - Training algorithm (gradient descent, backpropagation, etc.) - Hyperparameters **Disclose the Inference Process:** - Input processing - How the trained model processes new data - Output generation - Post-processing steps **Address the "Black Box" Problem:** Even if the trained model's internal weights are opaque, disclose the training and inference algorithms. Courts have accepted this approach for other adaptive systems. --- ## III. Avoiding Accidental § 112(f) Invocation: Drafting Techniques Here's what software prosecutors really want to know: How do I draft claims that *don't* invoke § 112(f)? ### The Central Principle: Describe the "How," Not Just the "What" *Williamson* changed the game. Before *Williamson*, if you avoided the word "means," you were probably safe. After *Williamson*, the test is whether your claim term has "sufficiently definite structure." *Williamson v. Citrix Online, LLC*, 792 F.3d 1339, 1348-49 (Fed. Cir. 2015) (en banc). **Translation:** Don't just list functions. Describe how those functions are performed in the context of your invention. ### Term Selection: What Works and What Doesn't #### High-Risk Terms (Frequently Invoke § 112(f)) These terms are often used purely functionally and tend to invoke § 112(f): **Generic Software Nouns:** - "module" - "unit" - "component" - "element" - "mechanism" - "device" - "system" (when used for a single functional element) **Why they're risky:** These are placeholders. They don't convey *how* something works—just that something exists to perform a function. **When they work:** If you pair them with structural detail explaining their operation, inputs, outputs, and connections. See *Apple* (discussing "heuristic"). #### Moderate-Risk Terms These can go either way depending on context: - "processor" (without describing what it processes or how) - "controller" (without describing control logic) - "interface" (without describing interface structure) - "engine" (without describing processing steps) **The key:** These terms need structural modifiers or operational detail to avoid § 112(f). #### Lower-Risk Terms These terms more naturally connote structure, but context still matters: - "circuit" (suggests physical structure) - "memory" (standard computer component) - "database" (implies organizational structure) - "register" (specific hardware component) - "buffer" (specific data structure) - "queue" (specific data structure with known operation) **Caution:** Even these terms can invoke § 112(f) if used purely functionally. The Federal Circuit looks at the entire claim phrase, not just the noun. ### Structural Modifiers That Help Adding structural detail to your claim terms can help avoid § 112(f): **Describe Inputs and Outputs:** - "authentication module configured to receive user credentials and output an access token" - "encryption component that receives plaintext data and generates encrypted data using a private key" **Describe Operation:** - "heuristic for determining touch input type based on finger contact angle relative to screen surface" - "analyzer that compares received signal strength against threshold values" **Describe Integration:** - "controller coupled to memory via data bus and configured to retrieve instructions from memory" - "processor in communication with sensor array and display module" **Use Specific Technical Terms:** - "finite state machine" (instead of "logic component") - "parser" (instead of "processing module") - "hash table" (instead of "data structure") ### The "Configured To" Formulation One common approach: use "configured to" or "operative to" with structural detail. **Example:** "A processor configured to: receive sensor data from the sensor array; apply filtering algorithm to remove noise components; and generate control signals based on filtered data." **Why this helps:** "Configured to" suggests the component has specific programming or circuitry to perform the function—not that you're just claiming the function itself. **Caution:** "Configured to" alone isn't magic. You still need to describe the "how"—the inputs, outputs, and operation—either in the claim or through clear linkage to the specification. ### Method Claims: The "-ing" Verb Rule For method claims, the rules are different and generally more favorable. **The Rule:** Method claim steps using "-ing" verbs (gerunds) do NOT invoke § 112(f). *O.I. Corp. v. Tekmar Co.*, 115 F.3d 1576, 1583 (Fed. Cir. 1997). **Example:** - ✅ "receiving user input" (does NOT invoke § 112(f)) - ✅ "processing the data" (does NOT invoke § 112(f)) - ✅ "transmitting a signal" (does NOT invoke § 112(f)) **The Exception:** Only "step for [function]" *without* reciting acts invokes § 112(f). **Example:** - ❌ "step for authenticating the user" (invokes § 112(f) if no acts recited) - ✅ "step for authenticating the user by comparing credentials against stored data" (does NOT invoke § 112(f) because acts are recited) **Translation:** For method claims, just avoid "step for" without acts. Otherwise, you're fine. ### Practical Drafting Strategies #### Strategy 1: Describe Operation in the Claim Include enough operational detail in the claim itself to convey the "how." **Weak (likely invokes § 112(f)):** "An authentication module for verifying user credentials." **Stronger:** "An authentication module configured to receive user credentials, compare the received credentials against stored credentials in a database, and generate an access token when the received credentials match the stored credentials." #### Strategy 2: Use Claim Differentiation Include both structural claims and explicit § 112(f) claims in your application. This helps establish that the structural claims don't invoke § 112(f). **Claim 1 (structural):** "A data processing system comprising: a processor configured to receive input data, apply filtering algorithm to remove noise, and output filtered data..." **Claim 10 (explicit MPF):** "The system of claim 1, further comprising: means for encrypting the filtered data..." The explicit means-plus-function claim in Claim 10 helps demonstrate that Claim 1's "processor" is structural, not functional. Otherwise, why would you need separate § 112(f) language? #### Strategy 3: Reference Detailed Disclosure When you can't fit all structural detail in the claim, reference your specification clearly. **Example:** "A navigation system comprising an analyzer as described with reference to FIG. 4 and configured to process GPS signals according to the algorithm of FIG. 5..." **Why this helps:** You're not just using "analyzer" as a placeholder. You're pointing to specific structural disclosure in your spec. #### Strategy 4: Use Multiple Dependent Claims Build structural detail progressively: **Claim 1:** "A system comprising a processor..." **Claim 2:** "The system of claim 1, wherein the processor is configured to receive sensor data and generate control signals." **Claim 3:** "The system of claim 2, wherein the processor applies a filtering algorithm to the sensor data before generating the control signals." Each claim adds more operational detail, making the structural nature clearer. ### When to Intentionally Use "Means" Sometimes you *want* § 112(f). Here's when: 1. **Broad functional claiming**: You want to cover all possible ways to perform a function, not just your disclosed structure. 2. **Claim differentiation strategy**: Explicit § 112(f) claims help protect structural claims. 3. **Prosecution flexibility**: § 112(f) claims can avoid prior art that discloses different structures. 4. **Future-proofing**: § 112(f) claims can reach future implementations using the doctrine of equivalents. More on this in Section V. --- ## IV. Fighting Improper USPTO Invocation: Response Strategies Examiners sometimes invoke § 112(f) when they shouldn't. Here's how to fight back. ### Understanding the Examiner's Burden The examiner must establish a *prima facie* case that § 112(f) applies. This requires: 1. Identifying the specific claim limitation at issue 2. Explaining why the limitation lacks sufficiently definite structure 3. Showing that the limitation is drafted in a means-plus-function format (generic term + function) MPEP § 2181 (9th ed., Rev. 10, 2020). If the examiner fails to do this, the rejection is improper. ### Response Strategy 1: Demonstrate Structural Detail in the Claim Show that your claim term describes the "how," not just the "what." **Example Response:** "The Examiner has incorrectly construed the claim term 'authentication module configured to receive user credentials, compare them against stored data, and generate access tokens' under § 112(f). This limitation recites sufficient structure to avoid § 112(f). As the Federal Circuit held in *Apple Inc. v. Motorola, Inc.*, 757 F.3d 1286, 1299 (Fed. Cir. 2014), software structure is conveyed through description of 'operation, such as its input, output, or connections.' The claim limitation here specifies: - **Input**: user credentials - **Operation**: compare against stored data - **Output**: access tokens - **Structure**: configuration to perform these specific operations This operational detail distinguishes the claim from generic functional claiming. The limitation describes *how* authentication is performed in the context of this invention—not merely *what* function is performed." ### Response Strategy 2: Reference the Entire Claim Phrase Examiners sometimes focus only on the introductory term ("module") while ignoring the structural detail that follows. **Example Response:** "The Examiner's rejection improperly focuses on the term 'module' in isolation. As the Federal Circuit held in *Williamson v. Citrix Online, LLC*, 792 F.3d 1339, 1350 (Fed. Cir. 2015), courts must examine 'the entire claim phrase' to determine whether it conveys structure. Here, the entire limitation recites 'encryption module that receives plaintext data, applies AES encryption algorithm using a 256-bit key, and outputs encrypted data.' This full phrase conveys sufficient structure through its description of inputs (plaintext data, 256-bit key), operation (AES encryption algorithm), and outputs (encrypted data). The claim does not merely recite 'encryption module for encrypting data'—which might invoke § 112(f). Instead, it specifies *how* encryption is performed in this invention." ### Response Strategy 3: Emphasize Software-Specific Structure Remind the examiner that software structure doesn't mean physical components. **Example Response:** "The Examiner's rejection appears to require physical structure, which is improper for software inventions. As the Federal Circuit explained in *Apple Inc. v. Motorola, Inc.*, 757 F.3d at 1298-99, software structure may be understood 'through, for example, an outline of an algorithm, a flowchart, or a specific set of instructions or rules.' The claim here provides such structure by describing the algorithm's operation: receive input, process according to specified rules, generate output. This satisfies the structural requirement for software claims." ### Response Strategy 4: Use Claim Differentiation If you have explicit § 112(f) claims, use them to support the structural nature of other claims. **Example Response:** "Applicant's claim set includes explicit means-plus-function limitations (see Claim 15: 'means for encrypting data'). The presence of these explicit § 112(f) claims demonstrates that the structural claims (Claims 1-10) were not intended to invoke § 112(f). As the Federal Circuit has recognized, the doctrine of claim differentiation creates a presumption that different claims have different scope. *Seachange Int'l, Inc. v. C-COR Inc.*, 413 F.3d 1361, 1369 (Fed. Cir. 2005). If Claim 1's 'encryption module' already invoked § 112(f), Claim 15's 'means for encrypting' would be redundant. Applicant clearly intended Claim 1 to recite structural limitations, while reserving § 112(f) for broader functional coverage in dependent claims." ### Response Strategy 5: Point to Specification Disclosure If the examiner invokes § 112(f) but then can't find corresponding structure, this proves the claim doesn't invoke § 112(f). **Example Response:** "The Examiner's rejection is internally inconsistent. The Examiner construes 'processing module' under § 112(f), but then finds the specification lacks corresponding structure. This proves the claim does not invoke § 112(f). As the Federal Circuit explained in *Flo Healthcare Solutions, LLC v. Kappos*, 697 F.3d 1367, 1374-75 (Fed. Cir. 2012), '[i]f the specification is so deficient that one skilled in the art cannot discern the corresponding structure in the specification, then the properly construed claim fails under [§ 112(b)].' But the claim here does not fail § 112(b) when properly construed as structural. The 'processing module' is described throughout the specification with sufficient detail (see, e.g., [cite specific disclosure]). The Examiner's inability to identify corresponding structure demonstrates that the claim should not be construed under § 112(f) in the first place." ### Response Strategy 6: Amend to Add Structural Detail Sometimes the most efficient response is to amend the claim to add more structural detail. **Example Amendment:** **Original Claim:** "A system comprising an authentication module for verifying user credentials." **Amended Claim:** "A system comprising an authentication module configured to: receive user credentials including username and password; retrieve stored credentials from database; compare received credentials against stored credentials using hash comparison; and generate access token when comparison indicates match." **Amendment Remarks:** "The claim has been amended to more explicitly recite the structural operation of the authentication module, including its inputs (user credentials), processing steps (retrieve, compare using hash comparison), and outputs (access token). These amendments clarify that the limitation recites structure, not merely function." **When to use this strategy:** If the examiner's interpretation has some basis, or if you want to avoid prolonged argument, amendment can be faster and more certain than argument. --- ## V. Strategic Use of § 112(f): When You Want Means-Plus-Function Claims Here's a truth many prosecutors miss: § 112(f) claims can be strategically valuable. The key is using them deliberately, not accidentally. ### Strategic Advantage #1: Claim Differentiation Having explicit § 112(f) claims helps protect your structural claims from § 112(f) construction. **The Strategy:** **Claim 1 (structural):** "A data encryption system comprising: a processor configured to receive plaintext data, apply AES encryption using a private key, and output encrypted data; and a memory storing the private key." **Claim 10 (explicit MPF):** "The system of claim 1, further comprising: means for authenticating users before granting access to encrypted data." **Why this works:** The explicit "means for" in Claim 10 demonstrates you know how to invoke § 112(f) when you want to. Therefore, when you didn't use "means for" in Claim 1, you didn't intend to invoke § 112(f). Courts recognize this. *Lighting World, Inc. v. Birchwood Lighting, Inc.*, 382 F.3d 1354, 1358 (Fed. Cir. 2004) ("The use of the term 'means' triggers a presumption that the inventor used the term advisedly to invoke the statutory mandates for means-plus-function clauses."). **Flip side:** If *all* your claims avoid "means," examiners and courts might conclude you're trying to get means-plus-function claiming without the requirements. Having some explicit § 112(f) claims strengthens your position that other claims are truly structural. ### Strategic Advantage #2: Prosecution Flexibility § 112(f) claims can help overcome prior art rejections. **The Scenario:** Examiner cites prior art that discloses a different structure for performing the same function. **Response with structural claim:** "The prior art's use of a lookup table differs from Applicant's hash function. Therefore, the prior art does not disclose the claimed processor configured to apply a hash function." **Problem:** Examiner might find another reference with a hash function, or argue the difference is obvious. **Response with § 112(f) claim:** "The claim is properly construed under § 112(f). The prior art's lookup table is not the 'corresponding structure' disclosed in Applicant's specification (the hash function of FIG. 4). Therefore, the prior art does not anticipate." **Why this works:** Under § 112(f), the claim is limited to the specific structure disclosed in your spec plus equivalents. Different structures don't anticipate, even if they perform the same function. **Caution:** This cuts both ways. § 112(f) also limits your claim scope. But in prosecution, it can be a useful tool. ### Strategic Advantage #3: Ambiguity and Negotiation Leverage § 112(f) creates uncertainty about equivalents scope, which can benefit patentees in litigation settlement. **The Dynamic:** When a claim is construed under § 112(f): - The claim covers your disclosed structure plus equivalents - But determining equivalents requires expert testimony and jury findings - This creates uncertainty even for sophisticated defendants **Why uncertainty favors patentees:** 1. **Litigation cost**: Resolving equivalents questions requires expensive expert discovery and potential jury trial. 2. **Risk premium**: Defendants can't precisely predict liability exposure, making settlement more attractive. 3. **Licensing leverage**: Uncertainty about equivalents scope gives patentees credibility when asserting claims against products with different structures. **Example:** Your claim recites "means for filtering noise from sensor data." Your spec discloses a Kalman filter algorithm. Defendant uses a particle filter instead. Is this an equivalent? That's a question for a jury after hearing expert testimony about function-way-result similarities. Defendant faces uncertainty about whether they infringe. That uncertainty has settlement value. **Caveat:** This strategy assumes your patent survives validity challenges. If § 112(f) invocation leads to indefiniteness because you didn't disclose an algorithm, the ambiguity doesn't help you. ### Strategic Advantage #4: Portfolio Diversification A strong patent portfolio includes multiple claim types covering different aspects of the invention. **The Mix:** 1. **Structural apparatus claims**: Specific implementation, harder to design around, more certain scope 2. **Method claims**: Different infringement analysis, can reach process patents 3. **§ 112(f) apparatus claims**: Broader functional coverage, covers multiple structures 4. **Jepson claims**: Useful for improvement patents **Why diversification matters:** Different claims serve different enforcement purposes. Structural claims might be easier to prove infringement. § 112(f) claims might cover more design-arounds. Method claims might reach process steps. Having all three types gives you multiple paths to proving infringement. ### Strategic Advantage #5: Future-Proofing Technology evolves. The structure you disclose today might be obsolete in five years. § 112(f) claims can help reach future implementations. **The Doctrine of Equivalents (for § 112(f))** § 112(f) has its own equivalents doctrine: "equivalents thereof" in the statute itself. For § 112(f) claims, a court determines equivalents by asking whether the accused structure performs the same function in substantially the same way to achieve substantially the same result. *Chiuminatta Concrete Concepts, Inc. v. Cardinal Indus., Inc.*, 145 F.3d 1303, 1309 (Fed. Cir. 1998). **Example:** Your 2024 patent discloses a convolutional neural network for image recognition. In 2028, a competitor uses a transformer architecture that didn't exist in 2024. **Structural claim:** Might not cover transformers because you didn't claim transformers, you claimed CNNs. **§ 112(f) claim:** Might cover transformers if they perform the same function (image recognition) in substantially the same way (neural network with learned weights) to achieve substantially the same result (classification accuracy). **The Risk:** Equivalents analysis is unpredictable. But it gives you a chance to reach technologies that didn't exist when you filed. ### Strategic Advantage #6: Litigation Positioning § 112(f) claims can create advantages in Markman hearings and expert testimony. **Markman Positioning:** In claim construction, you can argue: - The claim is properly construed under § 112(f) - The corresponding structure is [your specific algorithm] - Defendant's structure is not the corresponding structure and not an equivalent - Therefore, non-infringement (if advantageous) or infringement (if equivalent) **Expert Testimony Leverage:** Equivalents determination for § 112(f) requires expert testimony. This gives you opportunities to: - Present your expert's analysis of function-way-result - Challenge defendant's expert - Create factual disputes that survive summary judgment **Settlement Timing:** Markman hearings often drive settlement. § 112(f) construction can create settlement pressure because: - Equivalents questions remain unresolved until trial - Both sides face uncertainty - Trial costs loom large ### When NOT to Use § 112(f) Strategically § 112(f) claiming is not always advantageous. Avoid it when: 1. **Your specification lacks adequate algorithm disclosure**: You'll just get indefiniteness rejections/invalidity. 2. **Your invention is structurally novel**: If your specific structure is the innovation, claim it structurally. Don't invite design-arounds. 3. **Your field has standard structures**: If skilled artisans understand the structure from the function, § 112(f) adds complexity without benefit. 4. **You want maximum claim scope**: § 112(f) limits you to disclosed structure plus equivalents. Structural claims with broad functional language might cover more. 5. **Prosecution is already complex**: § 112(f) adds arguments about corresponding structure. Sometimes structural claims are simpler. ### Practical Implementation: The Hybrid Claiming Strategy The most robust approach combines structural and § 112(f) claims. **Example Claim Set:** **Claim 1 (Broadest structural):** "A data processing system comprising: a processor configured to receive sensor data, apply filtering to remove noise, and generate control signals based on filtered data." **Claim 2 (More specific structural):** "The system of claim 1, wherein the processor applies a Kalman filter algorithm to remove noise." **Claim 10 (Explicit § 112(f)):** "A data processing system comprising: means for receiving sensor data; means for filtering noise from the sensor data; and means for generating control signals based on filtered data." **Claim 11 (§ 112(f) with detail):** "The system of claim 10, wherein the means for filtering comprises the Kalman filter algorithm disclosed in FIG. 5." **Why this works:** - Claim 1: Structural, medium breadth, describes "how" through operation - Claim 2: Structural, narrower, specifies algorithm by name - Claim 10: § 112(f), potentially broader functional coverage - Claim 11: § 112(f), ties to specific disclosure This gives you multiple enforcement options, prosecution flexibility, and claim differentiation benefits. --- ## Quick Reference: Key Principles **Understanding § 112(f):** 1. **The statute is clear**: "Means" or "step for" invokes § 112(f). Corresponding structure must be in the spec. 2. **Software "structure" means algorithms, flowcharts, or detailed operation descriptions**—not just "a computer." 3. **Term selection matters, but context matters more**—even structural terms can invoke § 112(f) if used functionally. 4. **Always disclose specific algorithms in your spec**—supports both structural and MPF claims. 5. **Method claims using "-ing" verbs avoid § 112(f)**—only "step for" without acts invokes it. 6. **The general-purpose computer exception is vanishingly narrow**—when in doubt, disclose an algorithm. 7. **Clearly link algorithms to claimed functions** using consistent terminology. 8. **Recent cases emphasize "sufficient structure to perform the functions"**—not just any structure. **Avoiding Accidental § 112(f):** 9. **Describe the "how" in your claims**—inputs, outputs, connections, operation—not just the "what." 10. **The entire claim phrase matters**—not just the introductory noun. 11. **Use claim differentiation**—explicit § 112(f) claims protect structural claims. 12. **Reference detailed specification disclosure** when claims can't include all structural detail. **Fighting Improper Invocation:** 13. **Point to structural detail in the claim**—show you described operation, inputs, outputs. 14. **Reference the entire phrase**—examiners sometimes focus on isolated terms. 15. **Emphasize software-specific structure**—algorithm disclosure, not physical components. 16. **Use claim differentiation**—explicit MPF claims prove structural claims are structural. 17. **Consider amendment**—sometimes faster than argument. **Strategic Use:** 18. **Claim differentiation protects structural claims**—having some § 112(f) claims helps. 19. **Ambiguity creates settlement leverage**—equivalents uncertainty benefits patentees. 20. **Portfolio diversification**—combine structural, method, and § 112(f) claims. 21. **Future-proofing**—§ 112(f) equivalents can reach future implementations. 22. **Prosecution flexibility**—§ 112(f) can help overcome prior art. 23. **Litigation positioning**—creates expert testimony opportunities and factual disputes. --- ## The Bottom Line Congress gave us § 112(f) as a tool to claim by function when you disclose the structure. The Federal Circuit has spent decades clarifying what "structure" means for software—and it means algorithms, not generic computers. The rules are actually straightforward: **To avoid § 112(f):** Describe the "how"—the operation, inputs, outputs, connections—in your claim language. Don't just recite functions with placeholder nouns. **To use § 112(f) strategically:** Include explicit "means for" claims alongside structural claims. Make sure your spec discloses specific algorithms. Use the ambiguity and coverage benefits to your advantage. **To survive either way:** Always disclose detailed algorithms in your specification with clear linkage to claimed functions. This supports both structural claims (showing the structure that makes them structural) and MPF claims (providing the required corresponding structure). The key is understanding the difference between claiming structure and claiming function—and knowing when to do each deliberately. --- ## Table of Key Cases | Case | Holding | Key Principle | | -------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | *Williamson v. Citrix Online, LLC*, 792 F.3d 1339 (Fed. Cir. 2015) | Eliminated "strong presumption" against § 112(f) without "means" | Standard: does term have "sufficiently definite meaning as name for structure"? | | *[[Apple Inc. v. Motorola, Inc.]]*, 757 F.3d 1286 (Fed. Cir. 2014) | "Heuristic" had sufficient structure | Structure requires the "how" (operation, inputs, outputs, connections), not just the "what" | | *[[Aristocrat Techs v. Int'l Game Tech.]]*, 521 F.3d 1328 (Fed. Cir. 2008) | Software MPF requires specific algorithm | General-purpose computer insufficient unless function is truly standard | | *O.I. Corp. v. Tekmar Co.*, 115 F.3d 1576 (Fed. Cir. 1997) | Method claims: § 112(f) only for "step for" without acts | "-ing" verbs do NOT invoke § 112(f) | | *XR Communications v. Arris Solutions*, No. 2022-1125 (Fed. Cir. 2023) | Emphasized "sufficient structure to perform functions" | Not just any structure—must be adequate for claimed functions | | *In re Katz*, 639 F.3d 1303 (Fed. Cir. 2011) | Narrow exception for standard computer functions | General-purpose computer may suffice for truly standard functions only | | *Noah Systems v. Intuit*, 675 F.3d 1302 (Fed. Cir. 2012) | Structure must be clearly linked to function | Algorithm disclosure elsewhere insufficient without linkage | | *Advanced Ground Info. v. Life360*, 830 F.3d 1341 (Fed. Cir. 2016) | "Symbol generator" indefinite—no algorithm disclosed | Must disclose *how* function is performed, not just *what* it does | | *Corus Realty v. Zillow*, No. C18-0847JLR (W.D. Wash. 2019) | "Map generation unit" had sufficient structure | Describing inputs, outputs, and operation provides structure | | *Cypress Lake v. Samsung*, 382 F. Supp. 3d 586 (E.D. Tex. 2019) | "Navigation element handler component" indefinite | No specific algorithm disclosed in any form | --- ![[About the Author]] --- *This article is intended for informational purposes only and does not constitute legal advice. Practitioners should consult applicable case law and the Manual of Patent Examining Procedure for current guidance.*