# Managing § 112(b) and § 112(f) in Software Patents: A Comprehensive Framework > A Systematic Treatment of Algorithms, Structure, Drafting, and Strategic Use **By Paul Roberts** | 📊 Comprehensive Guide\ ⌨️ **19,943 words** | ⏱️ **80 min read** #Legal_Guides #35_USC_112f #Comprehensive #PatentLaw #Software December 27, 2024 --- ## Abstract This article provides a comprehensive, systematic framework for managing § 112(b) indefiniteness and § 112(f) means-plus-function issues in software patents. The framework addresses five discrete areas: **First**, the article examines how means-plus-function claiming operates for software patents, including the statutory basis, the two-step analytical framework, and software-specific structural requirements. **Second**, the article details § 112(b) compliance requirements, including algorithm disclosure standards, linkage requirements, and strategies for avoiding indefiniteness rejections. **Third**, the article presents techniques for preventing unintended § 112(f) invocation through careful claim drafting, including term selection guidance and structural detail requirements. **Fourth**, the article provides strategies for responding to improper § 112(f) invocation by USPTO examiners. **Fifth**, the article analyzes strategic uses of means-plus-function claims, including claim differentiation benefits, equivalents coverage, and portfolio diversification. Through systematic case law analysis, detailed technical examples, and comprehensive checklists, this article equips practitioners with the complete set of tools needed to draft compliant claims and specifications, respond effectively to examiner rejections, and strategically leverage means-plus-function claims when appropriate. --- ## I. Introduction: The Dual Challenge Software patent practitioners routinely confront two related but analytically distinct challenges under 35 U.S.C. § 112: A. **Section 112(b) Indefiniteness Rejections**: Claims that fail to "particularly point[] out and distinctly claim[] the subject matter which the inventor... regards as the invention" B. **Section 112(f) Means-Plus-Function Construction**: Claims construed as functional claiming limited to disclosed structures and equivalents thereof These challenges frequently arise in combination. A claim term may be construed under § 112(f), and if the specification lacks adequate corresponding structure, the claim becomes indefinite under § 112(b). This dual vulnerability creates significant prosecution and litigation risks. ### A. The Software Patent Context The problem manifests with particular acuteness in software patents, where "structure" has a distinct meaning from mechanical patents: 1. **Mechanical Patents**: Structure consists of physical components—gears, levers, springs, materials 2. **Software Patents**: Structure consists of algorithms, flowcharts, operational descriptions, and logical relationships Generic software terms—"module," "unit," "component," "element," "device"—prove increasingly susceptible to § 112(f) construction, especially when they lack sufficient structural detail in the claims themselves. ### B. Article Organization This article provides a comprehensive framework for managing these challenges, organized into five parts: **Part II** examines means-plus-function claiming in software patents, including: - The statutory framework (Section II.A) - The two-step analysis for determining § 112(f) application (Section II.B) - Software-specific structural requirements (Section II.C) - Method claim distinctions (Section II.D) **Part III** addresses § 112(b) compliance requirements, including: - Algorithm disclosure requirements (Section III.A) - Linkage standards (Section III.B) - The general-purpose computer trap (Section III.C) - Adequate disclosure standards (Section III.D) **Part IV** presents techniques for preventing unintended § 112(f) invocation, including: - Understanding susceptibility factors (Section IV.A) - Claim drafting techniques (Section IV.B) - Specification support requirements (Section IV.C) - Claim differentiation strategies (Section IV.D) **Part V** provides response strategies for improper USPTO invocation, including: - Structural arguments (Section V.A) - Specification support arguments (Section V.B) - Amendment strategies (Section V.C) **Part VI** analyzes strategic uses of means-plus-function claims, including: - Equivalents doctrine advantages (Section VI.A) - Claim differentiation benefits (Section VI.B) - Portfolio diversification strategies (Section VI.C) --- ## II. Means-Plus-Function in Software Patents: Comprehensive Analysis ### A. The Statutory Framework #### 1. Statutory Text 35 U.S.C. § 112(f) (formerly § 112, ¶ 6) provides: > "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." #### 2. The Statutory Bargain The statute creates a specific accommodation: **Permission Granted**: Inventors may claim by function ("means for X") rather than structure ("component Y configured to perform X") **Limitation Imposed**: Such claims cover only: - The specific structures disclosed in the specification - Equivalents thereof This represents a quid pro quo: functional claiming flexibility in exchange for scope limitation to disclosed embodiments. #### 3. Software-Specific Requirements For software inventions, the "corresponding structure" requirement has unique implications. The Federal Circuit has consistently held: > "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). **Key Principle**: For software means-plus-function claims, the structure *is* the algorithm. A general-purpose computer, without more, does not constitute adequate structural disclosure. ### B. The Two-Step Analysis Framework When claim language omits the word "means," courts apply a two-step analysis to determine whether § 112(f) applies. Each step requires careful analysis. #### 1. Step One: Does the Claim Term Connote Sufficiently Definite Structure? ##### a. The Standard The court must determine whether the claim limitation, "read in light of the remaining claim language, specification, prosecution history, and relevant extrinsic evidence," has sufficiently definite structure to a person of ordinary skill in the art (PHOSITA). *Apple Inc. v. Motorola, Inc.*, 757 F.3d 1286, 1296 (Fed. Cir. 2014). ##### b. The Burden The party asserting § 112(f) application bears the burden of rebutting the presumption that arises when "means" is absent from the claim. *Lighting World, Inc. v. Birchwood Lighting, Inc.*, 382 F.3d 1354, 1358 (Fed. Cir. 2004). ##### c. The Critical Inquiry The claim term must specify *how* the function is achieved in the context of the invention, not merely *what* function is performed. *Apple*, 757 F.3d at 1299. This distinction proves dispositive: **Insufficient (Function Only)**: "processing module for analyzing data" - Describes *what* is accomplished - Recites function without operational context **Sufficient (Structure)**: "processing module that receives data packets from the network interface, extracts header information based on protocol specifications, validates fields against predetermined criteria, and routes valid packets to the application handler" - Describes *how* the module operates - Provides inputs, processing steps, outputs, and integration ##### d. Software-Specific Structure For software patents, "structure" has a unique meaning. The Federal Circuit explained 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.'" *Id.* at 1299. **Operational Context as Structure**: For software claims, describing operation constitutes structural disclosure. The limitation's operation is "how the function is achieved in the context of the invention." *Id.* ##### e. Elements Establishing Software Structure To avoid § 112(f) at Step 1, software claim terms must describe: **First**: Inputs the claimed element receives - What data enters the element? - From what source? - In what format? **Second**: Processing performed by the element - What operations occur? - In what sequence? - Under what conditions? **Third**: Outputs the element generates - What results are produced? - In what format? - To what destination? **Fourth**: Integration with other system components - How does the element connect to other components? - What data flows between components? - How do components coordinate? ##### f. Case Study: *Apple Inc. v. Motorola, Inc.* The term "heuristic" provides instructive analysis. **Facts**: Claims recited "heuristics" for distinguishing one-dimensional scrolling from two-dimensional translation on a touchscreen device. **Analysis**: The court found sufficient structure because: 1. **Inputs Specified**: The claims described specific inputs the heuristics received: - Initial angle of finger contact - Number of fingers making contact - Direction of movement - Specific swiping gestures - Tapping locations - Angle of movement 2. **Processing Described**: The claims detailed how heuristics processed inputs: - Comparing finger angle to threshold (27° from vertical) - Determining whether movement exceeded angular threshold - Distinguishing vertical scrolling from diagonal translation 3. **Outputs Defined**: The claims specified resulting commands: - Vertical scrolling commands (if angle < 27°) - Two-dimensional translation commands (if angle > 27°) 4. **Operational Context Provided**: The specification and claims together described how heuristics operated within the touchscreen system. **Holding**: "Heuristic" connoted sufficient structure. *Apple*, 757 F.3d at 1300-01. **Significance**: The "how" detail—inputs, processing rules, outputs, integration—transformed what might appear to be a functional term ("heuristic" as problem-solving approach) into a structural description. ##### g. Case Study: *Williamson v. Citrix Online, LLC* The term "distributed learning control module" provides contrasting analysis. **Facts**: Claims recited "distributed learning control module" with three functional recitations: - "for receiving communications" - "for relaying the communications" - "for coordinating the operation" **Analysis**: The court found insufficient structure because: 1. **Generic Placeholder Term**: "Module" serves as generic placeholder, similar to "means" 2. **Pure Functional Language**: The claim recited only functions—receiving, relaying, coordinating—without describing *how* these functions operated 3. **Traditional MPF Format**: Despite avoiding "means," the claim followed the format: - [Generic term] + for + [function 1] - [Generic term] + for + [function 2] - [Generic term] + for + [function 3] 4. **No Operational Context**: The claim provided no detail regarding: - What communications were received or from where - How relay destinations were determined - What algorithms coordinated operations - How the module integrated with other components **Holding**: "Distributed learning control module" invoked § 112(f). *Williamson v. Citrix Online, LLC*, 792 F.3d 1339, 1350 (Fed. Cir. 2015) (en banc). **Significance**: This decision clarified that the presumption against § 112(f) when "means" is absent can be overcome when generic terms are coupled with pure functional language. ##### h. The Complete Claim Phrase Analysis Courts examine "the entire claim phrase," not merely the introductory term. *Joao Control & Monitoring Sys. LLC v. Protect Am., Inc.*, No. 1-14-CV-134-LY, at 12 (W.D. Tex. Aug. 18, 2015). **Implication**: The structural analysis considers: - The claim term itself ("module," "unit," "component") - All language modifying that term - Functional language following that term - The complete limitation as a unified whole **Example**: - Introductory term alone: "processing module" - Complete phrase: "processing module for analyzing data" - Further complete phrase: "processing module that receives data packets, extracts headers, validates fields, and routes results" The first two may invoke § 112(f); the third likely avoids it through operational detail. ## III. Ensuring § 112(b) Compliance: Algorithm Disclosure and Linkage ### A. The Definiteness Requirement #### 1. Constitutional Foundation The definiteness requirement emerges from the Constitution's Progress Clause, which permits Congress to grant exclusive rights only for "limited Times" to promote useful arts. A patent that fails to define its boundaries effectively grants rights indefinitely—both temporally and spatially. The public cannot determine: - What falls within the patent's scope - When the patent's exclusive rights expire - How to design around the claimed invention Such grants frustrate constitutional purpose. #### 2. Statutory Basis 35 U.S.C. § 112(b) requires that claims "particularly point[] out and distinctly claim[] the subject matter which the inventor... regards as the invention." #### 3. The *Nautilus* Standard The Supreme Court articulated the modern definiteness standard in *Nautilus, Inc. v. Biosig Instruments, Inc.*, 572 U.S. 898 (2014): > Claims must inform those skilled in the art about the scope of the invention "with reasonable certainty." **Application to Means-Plus-Function Claims**: For claims construed under § 112(f), definiteness depends on adequate structural disclosure in the specification. ### B. Algorithm Disclosure Requirements for Software #### 1. The Fundamental Requirement When software patents invoke § 112(f)—either intentionally through "means" or unintentionally through functional claiming—the corresponding structure is typically a specific algorithm. **Consequence of Non-Disclosure**: Failure to disclose the algorithm renders the claim indefinite under § 112(b). #### 2. Rationale for Algorithmic Disclosure For mechanical inventions: - Structure described through drawings, dimensions, materials - Visual representation possible - Physical embodiments understandable For chemical inventions: - Structure described through molecular formulas - Synthesis pathways specified - Composition determinable For software inventions: - Structure exists in logical operations - Algorithm transforms inputs to outputs - Implementation requires operational specification **Without Algorithmic Disclosure**: The public cannot determine: - What the patentee actually invented - How to perform the claimed function - The claim's scope and boundaries - Whether accused devices infringe #### 3. Examples Demonstrating Necessity **Claim**: "means for sorting data" **Potential Algorithms**: - Quicksort (O(n log n) average case, in-place sorting) - Mergesort (O(n log n) worst case, requires additional memory) - Heapsort (O(n log n) worst case, in-place sorting) - Insertion sort (O(n²) worst case, efficient for small datasets) - Bubble sort (O(n²) worst case, simple but inefficient) - Timsort (hybrid approach, optimized for real-world data) Each algorithm has different: - Performance characteristics - Memory requirements - Implementation complexity - Stability properties - Suitability for different data types **Scope Determination**: The claim's scope—and thus validity and infringement analysis—depends entirely on which algorithm(s) the specification discloses. #### 4. Dual Function of Algorithmic Disclosure Algorithmic disclosure serves two essential purposes: **First**: Satisfies § 112(a) enablement - Teaches one skilled in the art how to perform the claimed function - Provides sufficient detail for implementation - Enables practice of the invention **Second**: Defines § 112(f) claim scope - Identifies specific structures the claim covers - Limits scope to disclosed implementations and equivalents - Provides notice to the public These requirements work in tandem: the enabling disclosure becomes the limiting disclosure. ### C. The Linkage Requirement: Connecting Function to Structure #### 1. The General Principle Disclosure alone does not suffice. The specification must clearly link each disclosed algorithm to its corresponding claimed function. **Rationale**: This prevents a common evasion where specifications disclose numerous algorithms without identifying which performs which function. #### 2. Example Demonstrating the Problem **Specification Content**: Discloses five sorting algorithms: - Quicksort (paragraphs [0020]-[0025]) - Mergesort (paragraphs [0026]-[0031]) - Heapsort (paragraphs [0032]-[0037]) - Insertion sort (paragraphs [0038]-[0041]) - Bubble sort (paragraphs [0042]-[0045]) **Claim**: "means for sorting data" **Problem**: Which algorithm constitutes the corresponding structure? **Consequence Without Linkage**: - The claim is indefinite - The public cannot determine claim scope - Multiple potential structures exist - The specification provides no guidance #### 3. Tests for Adequate Linkage Courts employ several approaches to determine adequate linkage: ##### a. Explicit Association **Strongest Form**: Direct statement connecting claim to structure. **Example**: > "The 'means for sorting data' recited in claim 1 operates using the quicksort algorithm described in paragraphs [0020]-[0025] and illustrated in Figure 2." **Advantages**: - Unambiguous - Leaves no room for dispute - Provides clear notice **Implementation Guidance**: - State explicitly in specification - Reference specific claim numbers - Cite specific paragraphs and figures - Use declarative language ("operates using," "implements," "employs") ##### b. Contextual Association **Common Form**: Specification describes algorithm immediately after introducing claimed function. **Example Structure**: - Paragraph [0015]: "The data sorting means arranges elements in ascending order." - Paragraphs [0016]-[0020]: Detailed description of quicksort algorithm - Use of consistent terminology throughout **Adequacy**: Courts generally accept contextual linkage where the association is apparent from specification organization and terminology. **Implementation Guidance**: - Introduce function first - Immediately follow with algorithm description - Maintain consistent terminology - Avoid intervening unrelated material ##### c. Terminological Association **Implicit Form**: Specification uses identical or substantially similar terms when describing both function and structure. **Example**: - Claim: "means for authenticating users" - Specification paragraph [0030]: "The user authentication module implements a challenge-response protocol..." - Specification paragraphs [0031]-[0035]: Detailed description of challenge-response algorithm **Adequacy**: The consistent use of "authentication" and "challenge-response" creates linkage. **Implementation Guidance**: - Use identical terms for function and algorithm - Apply terms consistently throughout specification - Avoid synonyms that could create confusion - Reinforce connection through repeated use ##### d. Insufficient Linkage **What Fails**: Algorithms disclosed in specification without connection to claimed functions. **Example of Failure**: Specification contains: - Section 2: "Data Processing Techniques" (describes five different algorithms) - Section 3: "System Components" (describes various modules) - No clear association between algorithms in Section 2 and modules in Section 3 **Result**: Even though algorithms are disclosed, lack of linkage renders claims indefinite. **Common Failure Patterns**: 1. Algorithm disclosure in background section without connection to claims 2. Multiple algorithms disclosed without indication of which applies 3. Generic algorithm description not tied to specific claimed functions 4. Inconsistent terminology between claims and specification #### 4. Multiple Functions Requiring Individual Linkage When claims recite multiple means-plus-function limitations, the specification must link structure to *each* function individually. **Example Claim**: > "An apparatus comprising: > - means for encrypting data; > - means for compressing encrypted data; and > - means for transmitting compressed data." **Required Linkage**: The specification must: 1. Disclose encryption algorithm and link it to "means for encrypting" 2. Disclose compression algorithm and link it to "means for compressing" 3. Disclose transmission protocol and link it to "means for transmitting" **Specific Linkage Requirements**: **For Encryption**: - Identify specific algorithm (e.g., AES-256) - Describe key parameters (key length, mode of operation) - Link explicitly: "The means for encrypting implements AES-256..." **For Compression**: - Identify specific algorithm (e.g., LZW, DEFLATE) - Describe operational parameters - Link explicitly: "The means for compressing employs LZW compression..." **For Transmission**: - Identify specific protocol - Describe transmission parameters - Link explicitly: "The means for transmitting uses TCP protocol..." **Failure Consequence**: If linkage fails for any single limitation, the entire claim may be indefinite. ### D. Adequate Disclosure: Form and Detail Requirements #### 1. The Fundamental Question How much algorithmic detail satisfies the disclosure requirement? **Answer**: The disclosure must enable one skilled in the art to understand how to perform the claimed function. **Key Principle**: Form matters less than clarity and completeness. #### 2. Acceptable Forms of Disclosure ##### a. Flowcharts **Advantages**: - Visual representation aids understanding - Shows decision points clearly - Illustrates flow and sequence - Accessible to practitioners **Recommended Elements**: 1. Start and end points clearly marked 2. Input receipt and validation steps 3. Decision points with branching logic 4. Processing operations in sequence 5. Output generation and delivery 6. Error handling paths **Example Application**: Bubble sort flowchart showing: **Step 1**: Start - Receive array of elements **Step 2**: Initialize - Set swap flag to false, set counter to zero **Step 3**: Loop - For each element from position 0 to n-2: - **Step 3a**: Compare current element to next element - **Step 3b**: Decision - Is current > next? - **If yes**: Swap elements, set swap flag to true - **If no**: Continue to next pair **Step 4**: Increment counter **Step 5**: Decision - Did this pass perform any swaps? - **If yes**: Return to Step 2 (another pass needed) - **If no**: Array is sorted, proceed to Step 6 **Step 6**: End - Return sorted array **Best Practices for Flowcharts**: - Use standard flowchart symbols (diamonds for decisions, rectangles for processes) - Label all arrows clearly - Number steps for reference - Include loop counters and termination conditions - Show error handling paths - Cross-reference to specification paragraphs ##### b. Pseudocode **Advantages**: - Precise logical specification - Language-independent - Shows control structures clearly - Familiar to programmers **Example - Bubble Sort**: ``` FUNCTION bubbleSort(array) n = length(array) FOR i FROM 0 TO n-1 swapped = false FOR j FROM 0 TO n-i-2 IF array[j] > array[j+1] THEN SWAP array[j] AND array[j+1] swapped = true END IF END FOR IF NOT swapped THEN BREAK END IF END FOR RETURN array END FUNCTION ``` **Best Practices for Pseudocode**: - Use clear control structure keywords (IF/THEN/ELSE, FOR/WHILE, etc.) - Indent nested structures consistently - Include variable declarations - Show data type information where relevant - Comment complex operations - Use meaningful variable names - Show function parameters and return values **Acceptable Pseudocode Styles**: 1. **Structured English**: "For each element, if condition, then action" 2. **Mathematical Notation**: Using standard symbols (∀, ∃, →) 3. **Programming-Style**: Using syntax similar to common languages 4. **Hybrid Approach**: Combining prose with code-like structures ##### c. Prose Descriptions **Advantages**: - Accessible to non-programmers - Can explain rationale - Provides context - Flexible detail level **Example - Bubble Sort (Basic)**: > "The sorting algorithm receives an array of data elements and sorts them in ascending order through the following process. The algorithm makes repeated passes through the array. During each pass, the algorithm compares each pair of adjacent elements. If a pair is in the wrong order (the first element is greater than the second), the algorithm swaps them. The algorithm continues making passes through the array until a complete pass occurs with no swaps, indicating all elements are in correct order." **Example - Bubble Sort (Detailed)**: > "The bubble sort algorithm operates as follows: > > **Initialization**: The algorithm receives an input array containing n data elements. The algorithm initializes a swap counter to zero and a pass counter to zero. > > **Outer Loop - Passes**: The algorithm performs multiple passes through the array. Each pass is numbered, starting from pass 0. > > **Inner Loop - Comparisons**: During each pass i, the algorithm examines adjacent pairs of elements from position 0 to position (n-i-2). For each pair at positions j and j+1: > - The algorithm compares array[j] to array[j+1] > - If array[j] > array[j+1], the algorithm swaps the two elements and increments the swap counter > - If array[j] ≤ array[j+1], the algorithm proceeds to the next pair > > **Termination Check**: After completing each pass, the algorithm checks the swap counter: > - If swap counter = 0, no swaps occurred during this pass, indicating the array is sorted, and the algorithm terminates > - If swap counter > 0, the algorithm resets the swap counter to zero and performs another pass > > **Optimization**: The algorithm performs one fewer comparison with each successive pass, as the largest elements progressively 'bubble' to their final positions at the end of the array. > > **Output**: The algorithm returns the sorted array when termination condition is met." **Best Practices for Prose**: - Use clear section headings (Initialization, Processing, Output) - Number steps explicitly - Define all variables and data structures - Explain decision criteria - Describe loop conditions and termination - Include optimization details - Explain the rationale behind algorithmic choices ##### d. Mathematical Formulas **Appropriate For**: Algorithms based on mathematical transformations. **Example - Linear Transformation**: > "The scaling algorithm applies the following transformation to each input value x: > > y = mx + b > > where: > - m is the scaling factor (default: 2.0, range: 0.1 to 10.0) > - b is the offset value (default: 0.0, range: -1000.0 to 1000.0) > - x is the input value > - y is the output value > > The algorithm processes each element in the input array sequentially, applying this transformation and storing results in the output array." **Example - Signal Processing**: > "The filtering algorithm applies a discrete Fourier transform (DFT) to the input signal: > > X[k] = Σ(n=0 to N-1) x[n] · e^(-j2πkn/N) > > where: > - X[k] is the frequency domain representation > - x[n] is the time domain input signal > - N is the number of samples > - k is the frequency bin index (0 to N-1) > - j is the imaginary unit (√-1) > > The algorithm computes X[k] for each frequency bin k, producing a complete frequency spectrum of the input signal." **Best Practices for Mathematical Formulas**: - Define all variables and symbols - Specify ranges and constraints - Explain physical or logical meaning - Provide units where applicable - Show how formula integrates with overall algorithm - Include edge case handling (division by zero, overflow, etc.) ##### e. Source Code **Generally Unnecessary**: Courts do not require actual source code. **When Helpful**: - Complex algorithms difficult to describe in prose - Novel or non-obvious algorithmic contributions - Specific implementation details matter for claim scope - Industry standard to express algorithm in code **Example - Hash Function Implementation**: ```python def compute_hash(data, seed=0): """ Computes 32-bit hash of input data using custom algorithm. Args: data: Input byte array seed: Initial hash seed value (default: 0) Returns: 32-bit unsigned integer hash value """ hash_value = seed for byte in data: hash_value = ((hash_value << 5) + hash_value) ^ byte hash_value &= 0xFFFFFFFF # Keep 32-bit return hash_value ``` **Caution Regarding Source Code**: **Potential Limitations**: - May unnecessarily limit claim scope to specific implementation - Language-specific details may not be essential to invention - Implementation choices (variable names, optimizations) may narrow scope - Creates potential prosecution history issues **When to Include Source Code**: 1. Algorithm is novel and code is clearest expression 2. Implementation details are inventive contribution 3. Specific optimization techniques are claimed 4. Industry expects code-level disclosure **When to Avoid Source Code**: 1. Prose or pseudocode adequately describes algorithm 2. Specific language choices are not inventive 3. Risk of limiting scope to particular implementation 4. Algorithm is well-known but applied in novel way ##### f. Combination Approaches **Most Effective Strategy**: Combine multiple forms for clarity and completeness. **Recommended Structure**: **Level 1 - High-Level Overview** (Prose): > "The sorting module implements a quicksort algorithm, chosen for its O(n log n) average-case performance and in-place sorting capability. The algorithm recursively partitions data around pivot elements, sorts each partition, and combines results." **Level 2 - Visual Representation** (Flowchart): > "Figure 3 illustrates the quicksort process, showing how the algorithm recursively partitions the data around pivot elements selected using median-of-three selection." **Level 3 - Detailed Logic** (Pseudocode): ``` FUNCTION quicksort(array, low, high) IF low < high THEN pivot_index = partition(array, low, high) quicksort(array, low, pivot_index - 1) quicksort(array, pivot_index + 1, high) END IF END FUNCTION FUNCTION partition(array, low, high) pivot = select_pivot(array, low, high) i = low - 1 FOR j FROM low TO high - 1 IF array[j] <= pivot THEN i = i + 1 SWAP array[i] AND array[j] END IF END FOR SWAP array[i + 1] AND array[high] RETURN i + 1 END FUNCTION ``` **Level 4 - Mathematical Analysis** (Formulas): > "The partition step arranges elements such that for all i < pivot_index, array[i] ≤ pivot, and for all i > pivot_index, array[i] > pivot. The expected number of comparisons is O(n log n)." **Level 5 - Operational Details** (Detailed Prose): > "The quicksort algorithm operates as follows: > > **Base Case**: If the partition contains fewer than two elements (low ≥ high), the algorithm returns immediately as the partition is already sorted. > > **Pivot Selection**: The algorithm selects a pivot element using median-of-three selection. It examines the elements at positions low, (low+high)/2, and high, and selects the median value as the pivot. This approach reduces the likelihood of worst-case performance on already-sorted or reverse-sorted data. > > **Partitioning**: The algorithm partitions elements such that all elements less than or equal to the pivot are positioned before elements greater than the pivot. This is accomplished through a two-pointer approach: > - Pointer i starts at low-1 > - Pointer j scans from low to high-1 > - When array[j] ≤ pivot, i is incremented and array[i] and array[j] are swapped > - After the scan, the pivot is swapped into position i+1 > > **Recursive Sorting**: The algorithm recursively sorts two sub-partitions: > - Elements from low to pivot_index-1 > - Elements from pivot_index+1 to high > > **Termination**: Recursion terminates when all partitions contain zero or one element, at which point the entire array is sorted." **Benefits of Combination Approach**: 1. **Multiple Learning Styles**: Visual (flowchart), logical (pseudocode), verbal (prose) 2. **Different Detail Levels**: Overview to implementation 3. **Redundancy for Clarity**: Same information presented multiple ways 4. **Patent Office Acceptance**: Demonstrates thorough disclosure 5. **Litigation Support**: Multiple ways to demonstrate enablement #### 3. Detail Level Determination ##### a. The "One Skilled in the Art" Standard The disclosure must enable one skilled in the art—not a layperson, not an expert in all fields—to understand and implement the algorithm. **PHOSITA Definition Factors**: 1. Level of education in the field 2. Years of experience 3. Knowledge of related arts 4. Awareness of current state of the art **Field-Specific Variations**: **Computer Science Software**: - PHOSITA: Bachelor's degree in computer science or equivalent - Experience: 2-5 years software development - Knowledge: Standard algorithms and data structures - Less detail needed for well-known algorithms (sorting, searching) - More detail needed for novel combinations or optimizations **Signal Processing**: - PHOSITA: Master's degree in electrical engineering or computer science - Experience: 3-7 years in DSP applications - Knowledge: Fourier analysis, filter design, sampling theory - Less detail for standard transforms (FFT, DFT) - More detail for custom filter implementations **Machine Learning**: - PHOSITA: Advanced degree in computer science, statistics, or related field - Experience: 3-5 years in ML applications - Knowledge: Neural networks, optimization, statistical methods - Less detail for standard architectures (CNN, RNN) - More detail for novel training procedures or architectures **Cryptography**: - PHOSITA: Advanced degree in mathematics, computer science, or related field - Experience: 5+ years in security applications - Knowledge: Number theory, complexity theory, standard algorithms - Less detail for standard algorithms (AES, RSA) - More detail for novel key exchange or encryption schemes ##### b. Well-Known Algorithms **Question**: Must the specification detail every aspect of well-known algorithms? **Answer**: Generally no, but the specification must: - Identify the specific algorithm used - Describe any modifications or variations - Explain how the algorithm integrates with the claimed invention - Provide sufficient detail that one skilled in the art can implement the specific embodiment **Example - Sufficient for Well-Known Algorithm**: > "The encryption module implements the Advanced Encryption Standard (AES) algorithm with 256-bit key length, operating in Cipher Block Chaining (CBC) mode with a randomly generated initialization vector. The algorithm receives plaintext data blocks of 128 bits from the input buffer, applies the AES-256 transformation using the session key retrieved from the key storage module, and produces ciphertext blocks that are transmitted to the output buffer. The initialization vector is prepended to the ciphertext stream to enable decryption." **Analysis of Sufficiency**: - **Algorithm Identified**: AES-256 (well-known, standardized) - **Mode Specified**: CBC (well-known operating mode) - **Key Parameters Detailed**: - Key length: 256 bits - Block size: 128 bits (standard for AES) - IV: randomly generated - **Integration Described**: Input buffer → encryption → output buffer - **Implementation Guidance**: IV handling for decryption - **Relies on Well-Known Nature**: Does not detail internal AES rounds, S-boxes, etc. (unnecessary for well-known algorithm) **Example - Insufficient for Well-Known Algorithm**: > "The system encrypts data using encryption techniques known in the art." **Why Insufficient**: - No specific algorithm identified - No parameters specified - No integration described - Provides no implementation guidance - Too generic to enable skilled artisan ##### c. Novel or Modified Algorithms **Requirement**: Provide complete disclosure enabling implementation without undue experimentation. **Necessary Elements**: 1. **Complete Algorithmic Steps**: - All operations in sequence - Decision criteria at each branch - Loop conditions and termination - Variable initialization and updates 2. **All Parameters and Their Values**: - Default values - Acceptable ranges - Units and scales - How parameters affect operation 3. **Decision Criteria and Thresholds**: - Comparison operators - Threshold values - How thresholds determined - Impact of threshold selection 4. **Special Cases and Error Handling**: - Edge cases (empty input, single element, etc.) - Error conditions (invalid input, overflow, etc.) - Recovery procedures - Fallback algorithms 5. **Integration with Other Components**: - Input sources and formats - Output destinations and formats - Shared resources - Synchronization requirements 6. **Expected Inputs and Outputs**: - Data types and structures - Value ranges - Format specifications - Examples demonstrating operation **Example - Novel Algorithm Disclosure**: > "The adaptive compression algorithm adjusts compression parameters dynamically based on data characteristics, achieving superior compression ratios compared to standard approaches. > > **Initialization**: > The algorithm initializes with: > - Window size W = 4096 bytes > - Match length threshold T = 3 bytes > - Hash table size H = 65536 entries > - Compression ratio target R = 2.0 > > **Analysis Phase**: > For each input block of B bytes (default B = 16384): > > 1. Compute entropy E using Shannon entropy formula: > E = -Σ(p(i) · log2(p(i))) > where p(i) is the probability of byte value i > > 2. Analyze byte value distribution: > - If standard deviation σ < 30, data is low-variance (homogeneous) > - If σ > 100, data is high-variance (heterogeneous) > - Otherwise, data is moderate-variance > > 3. Adjust parameters based on entropy and variance: > - High entropy (E > 7.0) AND high variance: W = 8192, T = 4 > - High entropy (E > 7.0) AND low variance: W = 2048, T = 2 > - Low entropy (E < 5.0) AND high variance: W = 4096, T = 3 > - Low entropy (E < 5.0) AND low variance: W = 1024, T = 2 > > **Compression Phase**: > Using adjusted parameters: > > 1. Maintain sliding window of W bytes of previously processed data > > 2. For each position in current input: > a. Compute hash of next T bytes: h = (b1 << 16) ^ (b2 << 8) ^ b3 > b. Look up hash in hash table to find potential matches > c. For each potential match position m: > - Compare bytes at current position to bytes at m > - Find longest match length L > - If L ≥ T, emit (distance, length) pair and advance position by L > - Otherwise, emit literal byte and advance position by 1 > d. Update hash table with current position > > 3. Monitor compression ratio C = output_bytes / input_bytes: > - If C > R (compression worse than target), increase W by 50% > - If C < R/2 (compression much better than target), decrease W by 25% > - Clamp W to range [1024, 32768] > > **Edge Cases**: > - Empty input: Return empty output > - Single byte: Emit as literal > - No matches found: Emit all as literals > - Window size adjustment limited to once per block to prevent oscillation > > **Output Format**: > - Header: 4 bytes encoding final W and T values > - Body: Sequence of literals (1 byte) and (distance, length) pairs (3 bytes) > - Footer: 4 bytes CRC-32 checksum" **This Novel Algorithm Disclosure Includes**: - ✅ Complete step-by-step procedure - ✅ All parameters with values and ranges - ✅ Mathematical formulas (entropy, hash function) - ✅ Decision criteria with specific thresholds - ✅ Adaptive adjustment logic - ✅ Edge case handling - ✅ Input/output format specifications - ✅ Sufficient detail for implementation ### E. The General-Purpose Computer Trap: Detailed Analysis #### 1. The Problem Statement Perhaps no doctrine in software patent law creates more confusion than the "general-purpose computer" trap. **Common Misconception**: Disclosing that functions are performed by "a computer" or "a processor" satisfies the structural disclosure requirement. **Reality**: A general-purpose computer, standing alone, typically does not constitute adequate structural disclosure for computer-implemented means-plus-function claims. #### 2. The Underlying Rationale ##### a. General-Purpose Computers Can Execute Any Algorithm A computer, by its nature, is a universal Turing machine capable of executing any algorithm given appropriate programming. **Implication**: Stating that "a computer performs function X" provides no information about *how* function X is performed. **Analogy to Mechanical Patents**: Claiming "a computer" without specifying the algorithm is like claiming: - "A tool" without specifying hammer, wrench, or screwdriver - "A machine" without specifying lathe, mill, or press - "A fastener" without specifying screw, bolt, or rivet The hardware platform (computer) is not the structure; the algorithm (programming) is the structure. ##### b. The Algorithm Is the Structure For software inventions: - **The hardware** (computer, processor, memory) = the platform - **The algorithm** (programming, logic, data structures) = the structure - **Disclosing platform without algorithm** = disclosing material without shape **Key Principle**: It is the algorithmic programming—not the underlying hardware—that constitutes corresponding structure for software means-plus-function claims. **Comparison**: | Patent Type | Platform | Structure | |-------------|----------|-----------| | Mechanical | Steel/aluminum | Gear configuration | | Chemical | Elements | Molecular structure | | Software | Computer/processor | Algorithm | ## III. Ensuring § 112(b) Compliance (Continued) ### E. The General-Purpose Computer Trap (Continued) #### 3. Case Law Development ##### a. *Aristocrat Technologies* - The Foundational Case The foundational case establishing the algorithm requirement: > "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). **Holding**: General-purpose computer insufficient; specific algorithm required. **Facts**: Patent claimed means for controlling slot machine game presentation. Specification disclosed that functions were performed by a microprocessor but failed to disclose specific algorithms. **Analysis**: The court found claims indefinite because: 1. Specification disclosed general-purpose microprocessor 2. No specific algorithm disclosed for claimed functions 3. General-purpose processor can execute any algorithm 4. Specification failed to limit scope to particular implementation **Impact**: Established that for software means-plus-function claims, the algorithm is the structure, not the processor. ##### b. *Advanced Ground Information Systems* - Application to Indefiniteness The court found claims indefinite where the specification disclosed that functions were performed by "a computer" without disclosing specific algorithms. *Advanced Ground Info. Sys. v. Life360, Inc.*, 830 F.3d 1341 (Fed. Cir. 2016). **Key Finding**: "The specification must disclose the algorithm that transforms the general purpose microprocessor to a special purpose computer programmed to perform the disclosed function." *Id.* at 1349. **Facts**: Patent claimed means for generating symbols on a map display. Specification stated functions were performed by "computer" or "processor." **Analysis**: Claims indefinite because: 1. No algorithm disclosed for symbol generation 2. Specification merely invoked general-purpose computer 3. No flowchart, pseudocode, or detailed description 4. One skilled in art could not determine how function performed **Significance**: Affirmed that algorithmic disclosure requirement applies strictly; invoking "computer" or "processor" is insufficient. ##### c. Consistent Federal Circuit Jurisprudence The Federal Circuit has consistently required algorithmic disclosure across numerous cases: **Noah Systems, Inc. v. Intuit Inc.**, 675 F.3d 1302 (Fed. Cir. 2012): - Held: Algorithm must be clearly linked to function - Found: Claims indefinite where algorithms disclosed but not linked to specific functions **Typhoon Touch Technologies, Inc. v. Dell, Inc.**, 659 F.3d 1376 (Fed. Cir. 2011): - Held: General-purpose processor insufficient - Found: Claims indefinite lacking algorithmic disclosure **Ergo Licensing, LLC v. CareFusion 303, Inc.**, 673 F.3d 1361 (Fed. Cir. 2012): - Held: Microprocessor alone inadequate - Found: Must disclose algorithm transforming processor into special-purpose device **Function Media, L.L.C. v. Google Inc.**, 708 F.3d 1310 (Fed. Cir. 2013): - Held: Programming details required for computer-implemented functions - Found: Claims invalid where specification lacked algorithmic detail **Consistent Principle**: Across all cases, the Federal Circuit requires specific algorithmic disclosure, rejecting general-purpose computer references as inadequate structure. #### 4. Practical Implications ##### a. What Fails - Insufficient Disclosures **Pattern 1: Generic Computer Reference** > "A computer performs the authentication function" **Why It Fails**: - No algorithm specified - No detail about how authentication occurs - Could encompass any authentication method - Provides no structural limitation **Pattern 2: Processor Without Programming** > "A processor executes the sorting algorithm" **Why It Fails**: - States that sorting occurs but not how - "The sorting algorithm" is conclusory - No specific algorithm identified - No implementation detail provided **Pattern 3: Software Without Specifics** > "The system includes a microprocessor for data processing" **Why It Fails**: - "For data processing" is pure function - No algorithm disclosed - Microprocessor is platform, not structure - Fails to specify what processing occurs or how **Pattern 4: Generic Programming Reference** > "Software running on the device analyzes the data" **Why It Fails**: - "Software" without specifics is meaningless - "Analyzes" describes function, not algorithm - No detail about analytical method - Could encompass any analysis technique ##### b. What Succeeds - Sufficient Disclosures **Example 1: Identified Algorithm with Parameters** > "A processor executes the quicksort algorithm, described in detail in paragraphs [0025]-[0030], to arrange data elements in ascending order. The quicksort implementation uses median-of-three pivot selection, partitions elements around the selected pivot, recursively sorts partitions smaller than 10 elements using insertion sort, and combines results in-place without requiring additional memory allocation." **Why It Succeeds**: - Specific algorithm identified: Quicksort - Implementation details provided: Median-of-three, hybrid with insertion sort - Cross-reference to detailed description - Operational parameters specified **Example 2: Step-by-Step Protocol** > "The authentication module implements a challenge-response protocol wherein: (1) the server generates a random nonce using a cryptographically secure pseudo-random number generator; (2) transmits the nonce to the client; (3) receives a response comprising the nonce encrypted with the client's private key using RSA-2048 encryption; (4) decrypts the response using the client's public key; and (5) validates that the decrypted value matches the original nonce, granting access if validation succeeds or denying access if validation fails." **Why It Succeeds**: - Specific protocol steps enumerated - Cryptographic methods identified (RSA-2048) - Decision criteria specified (match validation) - Complete operational sequence described **Example 3: Algorithm with Integration** > "The compression engine applies the Lempel-Ziv-Welch (LZW) algorithm as follows. The engine maintains a dictionary of previously encountered byte sequences, initially populated with all single-byte values (0-255). For each input byte sequence, the engine searches the dictionary for the longest match, outputs the dictionary index of the match to the compressed data stream, adds the match plus one additional byte to the dictionary with a new index, and continues processing from the next unmatched byte. When the dictionary reaches maximum size (4096 entries), the engine resets it to initial state. The compressed output stream consists of 12-bit dictionary indices packed into bytes with appropriate byte-alignment padding." **Why It Succeeds**: - Specific algorithm: LZW - Data structures described: Dictionary with size and population method - Operational logic detailed: Search, output, update cycle - Parameters specified: Dictionary size (4096), index size (12-bit) - Output format defined #### 5. Drafting Recommendations ##### a. Always Disclose Algorithms **Best Practice**: For every computer-implemented function—whether in means-plus-function claims or claims potentially susceptible to means-plus-function construction—disclose a specific algorithm in the specification. **Benefits**: 1. **Supports Structural Claim Interpretations**: Algorithmic disclosure in specification can be read into claims to establish structural character (Step 1 avoidance) 2. **Provides Means-Plus-Function Fallback**: If claims are construed under § 112(f), algorithmic disclosure satisfies Step 2 requirement 3. **Avoids Indefiniteness Rejections**: Clear algorithmic disclosure prevents § 112(b) rejections 4. **Satisfies Enablement Requirements**: Algorithmic detail ensures § 112(a) compliance 5. **Creates Prosecution Flexibility**: Multiple disclosed algorithms provide options for amendment and argument ##### b. Link Algorithms to Claims Use consistent terminology between claims and specification to create clear linkage. **In Claims**: "authentication module" **In Specification**: > "The authentication module implements the following protocol..." (paragraph [0025]) > > "As described above, the authentication module (element 120 in Figure 2) performs user validation through the challenge-response protocol detailed in paragraphs [0025]-[0030]." (paragraph [0045]) **Cross-References**: - Use identical terms in claims and specification - Reference figure numbers and elements - Cite specific paragraph ranges - Reinforce connection through repetition ##### c. Describe Integration Show how algorithms integrate with the complete system: **Example**: > "The authentication module (Figure 2, element 120) receives credentials from the login interface (element 110), applies the SHA-256 hash function to the password component, compares the resulting hash to the stored hash value retrieved from the user database (element 130), and upon successful match, generates a session token using the HMAC algorithm with the server's private key, returning the token to the session manager (element 140) for delivery to the client." **Integration Elements Demonstrated**: - Input source: Login interface (element 110) - Processing steps: Hash computation, comparison, token generation - Data storage interaction: User database (element 130) - Output destination: Session manager (element 140) - System architecture: References to Figure 2 and numbered elements --- ## IV. Preventing Unintended § 112(f) Invocation ### A. Understanding Susceptibility Factors #### 1. Overview *Williamson v. Citrix Online, LLC* identified several factors suggesting claim terms lack sufficient structure and therefore may invoke § 112(f) despite avoiding the word "means." Understanding these factors enables practitioners to: - Identify vulnerable claim language during drafting - Add structural detail proactively - Avoid unintended means-plus-function construction - Respond effectively to examiner rejections #### 2. Factor One: Generic Placeholder Terms ##### a. Identified Terms Terms particularly susceptible to § 112(f) construction: **Primary Vulnerable Terms**: - "module" - "unit" - "component" - "element" - "device" **Secondary Vulnerable Terms**: - "mechanism" - "assembly" - "apparatus" (when used for individual limitations) - "system" (when used for individual limitations) - "circuitry" (without structural detail) ##### b. Why These Terms Are Vulnerable These terms serve as generic placeholders that can encompass any structure: **"Module"**: - Could be hardware, software, firmware, or combination - Provides no information about implementation - Describes function grouping, not structure - Example: "processing module" could be ASIC, FPGA, software routine, or dedicated processor **"Unit"**: - Generic subdivision without structural meaning - Could be any functional grouping - Provides no implementation guidance - Example: "storage unit" could be RAM, ROM, hard drive, SSD, or tape **"Component"**: - Generic part designation - No inherent structural character - Could be any constituent element - Example: "filter component" could be hardware filter, software algorithm, or analog circuit **"Element"**: - Most generic term possible - Merely identifies existence of something - Provides zero structural information - Example: "data element" could be bit, byte, word, record, or entire database **"Device"**: - Generic apparatus designation - Could be any electromechanical implementation - No specificity about construction - Example: "input device" could be keyboard, mouse, touchscreen, or voice interface ##### c. Degree of Vulnerability **Highly Vulnerable**: Bare term without modification **Examples of High Vulnerability**: - "a processing module" - "a communication unit" - "a control element" - "a storage device" - "a filtering component" **Analysis**: These provide no structural information beyond functional grouping. The term alone conveys nothing about how the element operates or what structure it possesses. **Moderately Vulnerable**: Term with functional modification **Examples of Moderate Vulnerability**: - "a processing module for analyzing data" - "a communication unit for transmitting messages" - "a control element for coordinating operation" **Analysis**: Adding "for [function]" makes vulnerability worse, as it mirrors traditional means-plus-function format. The term still provides no operational detail. **Lower Vulnerability**: Term with operational modification **Examples of Lower Vulnerability**: - "a processing module that receives data packets from the network interface, extracts headers based on protocol specifications, validates fields against predetermined criteria, and routes valid packets to the application handler" - "a communication unit connected to the message queue, configured to retrieve outbound messages from the queue, format the messages according to protocol specifications retrieved from the configuration database, and transmit formatted messages via the network interface controller while monitoring acknowledgment signals" **Analysis**: Operational detail describes how the element functions: inputs, processing, outputs, integration. This operational context provides the structural definition necessary to avoid § 112(f). #### 3. Factor Two: Functional Recitation ##### a. The "For [Verb]ing" Construction Claim language reciting functions through "for [verb]ing" constructions signals functional rather than structural claiming: **Pattern**: [Generic term] + for + [function] **Examples**: - "module for receiving data" - "unit for processing information" - "component for transmitting results" - "element for controlling operation" - "device for coordinating functions" ##### b. Why This Construction Is Problematic **Mirrors Traditional MPF Format**: **Traditional MPF**: "means for receiving data" **Generic Term Variant**: "module for receiving data" **Comparison**: - Both use generic placeholder ("means" vs. "module") - Both use "for" to introduce function - Both describe what is accomplished - Neither describes how operation occurs **The Only Difference**: Substitution of "module" for "means" **Court's Analysis**: Merely replacing "means" with another generic term while maintaining functional format does not avoid § 112(f). *Williamson*, 792 F.3d at 1350. ##### c. Distinction from Operational Description **Functional (Vulnerable)**: > "a validation module for checking data integrity" **Analysis of Vulnerability**: - Generic term: "module" - Functional connector: "for" - Function only: "checking data integrity" - No operational detail: Doesn't describe how checking occurs **Operational (Structural)**: > "a validation module configured to compute a checksum of received data using the CRC-32 algorithm, compare the computed checksum to a checksum value embedded in the data packet header, and generate an error signal to the error handling controller upon detecting a mismatch" **Analysis of Structural Character**: - **Inputs identified**: Received data, embedded checksum value - **Processing specified**: CRC-32 computation, comparison operation - **Outputs defined**: Error signal to error handling controller - **Algorithm named**: CRC-32 (specific checksum algorithm) - **Decision logic**: Mismatch detection triggers error signal - **Integration shown**: Connection to error handling controller **Key Distinction**: Operational version describes *how* validation occurs (specific algorithm, specific operations, specific data flow), not merely *what* is accomplished (checking integrity). ##### d. Multiple Functional Recitations Multiple "for" recitations in a single limitation heighten vulnerability. **Example from *Williamson***: > "distributed learning control module for receiving communications transmitted between the presenter and the audience member computers and for relaying the communications to an intended receiving computer and for coordinating the operation of the streaming data module" **Analysis of High Vulnerability**: **Three Separate Functional Recitations**: 1. "for receiving communications" 2. "for relaying the communications" 3. "for coordinating the operation" **Each Recitation**: - Describes function only - Provides no operational detail - Explains what, not how **Cumulative Effect**: Multiple functional recitations reinforce conclusion that the term connotes no definite structure. The claim is essentially: > [Generic term] + for + [function 1] + for + [function 2] + for + [function 3] This mirrors the traditional means-plus-function format multiple times within a single limitation, making § 112(f) application nearly inevitable. #### 4. Factor Three: Format Similarity to Traditional MPF ##### a. The Pattern Claims that follow the format "[term] + for + [function]" mirror traditional means-plus-function claiming: **Traditional MPF Format**: > "means for [function]" **Generic Term Format**: > "[module/unit/component] for [function]" **Structural Comparison**: | Element | Traditional MPF | Generic Term Variant | |---------|----------------|---------------------| | Placeholder | means | module/unit/component | | Connector | for | for | | Content | function | function | | Structural Detail | none | none | ##### b. Court's Recognition of Pattern The Federal Circuit in *Williamson* explicitly recognized this pattern: > "The claim limitation... replaces the term 'means' with the term 'module' and recites three functions performed by the 'distributed learning control module.'" *Williamson*, 792 F.3d at 1350. **Key Finding**: The format itself—generic term + for + function—creates strong indication of functional claiming, regardless of the specific placeholder term used. ##### c. Mitigation Strategies **Strategy One: Replace "for" with Operational Language** **Functional Format**: > "module for processing data" **Operational Format**: > "module configured to receive data packets, apply transformation rules specified in the configuration table, and generate output formatted according to the protocol specification" **Improvement**: "Configured to" + specific operations replaces "for" + generic function. **Strategy Two: Describe Operation, Not Function** **Functional Format**: > "component for error detection" **Operational Format**: > "component that compares received checksums against checksums computed using the CRC-32 polynomial, identifies mismatches indicating corrupted data, and flags corrupted packets for retransmission" **Improvement**: Describes how error detection occurs (checksum comparison, mismatch identification) rather than merely stating that error detection is performed. **Strategy Three: Integrate with System Description** **Functional Format**: > "element for data storage" **Operational Format**: > "element comprising a non-volatile flash memory array organized in 4KB pages, wherein each page stores data blocks indexed by logical block addresses maintained in a mapping table stored in RAM, and wherein a wear-leveling algorithm distributes write operations across pages to extend memory lifespan" **Improvement**: Describes specific storage architecture, data organization, indexing method, and operational algorithms rather than merely stating storage function. #### 5. Factor Four: Lack of Operational Context ##### a. The Requirement To convey structural meaning for software inventions, claim terms must describe operational context: **Required Operational Elements**: 1. **Inputs**: - What data the element receives - From what source - In what format 2. **Processing**: - What operations the element performs - In what sequence - Under what conditions 3. **Outputs**: - What results the element generates - In what format - To what destination 4. **Integration**: - How the element connects to other components - What data flows between components - How components coordinate ##### b. Examples Demonstrating Requirement **Lacks Operational Context (Vulnerable)**: > "a data analysis module" **Analysis of Deficiency**: - **No inputs specified**: What data? From where? - **No processing described**: What analysis? How performed? - **No outputs defined**: What results? To where? - **No integration shown**: How does module fit in system? **Result**: The term provides no information beyond the functional label "analysis." One skilled in the art cannot determine what structure is claimed. **Includes Operational Context (Structural)**: > "a data analysis module that receives time-series data from the sensor interface at 100 Hz sampling rate, applies a discrete Fourier transform to identify frequency components in 0-50 Hz range, compares identified frequencies against threshold values stored in the configuration register, and outputs an alert signal to the notification controller when any frequency component exceeds its corresponding threshold" **Analysis of Sufficiency**: **Inputs Specified**: - Data type: Time-series data - Source: Sensor interface - Format: 100 Hz sampling rate **Processing Described**: - Algorithm: Discrete Fourier transform (DFT) - Parameters: 0-50 Hz frequency range - Decision logic: Threshold comparison - Data source for thresholds: Configuration register **Outputs Defined**: - Result: Alert signal - Destination: Notification controller - Trigger condition: Threshold exceedance **Integration Shown**: - Input connection: Sensor interface - Configuration source: Configuration register - Output destination: Notification controller - Operational flow: Continuous monitoring at specified rate **Result**: The operational context transforms "data analysis module" from a generic functional label into a structural description of a specific signal processing implementation. ##### c. Operational Context for Different Element Types **For Processing Elements**: **Minimum Required Context**: - Input data types and sources - Processing algorithms or operations - Decision criteria and branching logic - Output data types and destinations - Error handling procedures **Example**: > "a packet processing engine that receives IP packets from the ingress port buffer, extracts destination IP addresses from packet headers, performs longest-prefix matching of destination addresses against routing table entries using a binary trie data structure, identifies the next-hop interface for each packet based on the matched routing entry, and forwards packets to the appropriate egress port buffer while updating packet forwarding statistics" **For Storage Elements**: **Minimum Required Context**: - Storage medium and organization - Data indexing and retrieval methods - Capacity and allocation strategy - Access patterns and performance characteristics **Example**: > "a cache memory comprising 256 KB of SRAM organized as 4-way set-associative structure with 64-byte cache lines, wherein data is indexed by memory address bits [12:6] for set selection and bits [31:13] for tag comparison, and wherein a least-recently-used (LRU) replacement policy evicts the least-recently-accessed line when cache misses occur and all ways in a set are occupied" **For Communication Elements**: **Minimum Required Context**: - Communication protocol and format - Source and destination identification - Data encoding and error handling - Flow control and synchronization **Example**: > "a network interface controller that retrieves outbound messages from the transmission queue, encapsulates each message in an Ethernet frame with 14-byte header containing source MAC address, destination MAC address, and EtherType field, computes a 32-bit CRC checksum appended as frame check sequence, transmits the frame via the PHY interface at negotiated link speed (10/100/1000 Mbps), and monitors for collision detect signal indicating transmission conflicts" #### 6. Factor Five: Specification Treatment ##### a. Specification Reinforcement of Functional Nature If the specification describes the claim term only in functional terms, this reinforces the conclusion that the term lacks structural character. **Example of Reinforcing Functionality**: **Claim**: "processing module for analyzing network traffic" **Specification** (paragraph [0025]): > "The processing module analyzes network traffic to identify security threats and anomalous behavior patterns." **Analysis of Deficiency**: - Specification merely repeats functional description - No operational detail provided - No algorithm disclosed - No structural characteristics described **Effect**: Specification treatment reinforces that "processing module" is a functional placeholder. The specification confirms that the term connotes no definite structure. ##### b. Specification Provision of Structural Context Conversely, detailed specification description can support structural character even when claim language is minimal. **Example of Supporting Structure**: **Claim**: "traffic analysis module" **Specification** (paragraphs [0030]-[0045]): > "The traffic analysis module (Figure 2, element 200) comprises several interconnected components operating in concert to provide comprehensive network security monitoring. > > **Packet Capture Component** (element 210): Receives network packets from the network interface controller, buffering incoming packets in a 1 MB ring buffer organized as FIFO queue. The component extracts packets at line rate (up to 10 Gbps) without packet loss. > > **Deep Packet Inspection Engine** (element 220): Examines packet contents against signature databases stored in flash memory. The engine implements the Aho-Corasick string matching algorithm (illustrated in Figure 3) to efficiently search packet payloads for known attack signatures. When a signature match occurs at payload offset i, the engine records the packet identifier, matched signature identifier, and offset position. > > **Statistical Analysis Component** (element 230): Maintains sliding-window histograms of traffic patterns over configurable time intervals (default: 60 seconds). The component computes statistical metrics including: > - Packet rate (packets per second) > - Byte rate (bytes per second) > - Protocol distribution (TCP/UDP/ICMP percentages) > - Source/destination address entropy > > The component applies chi-square testing to detect anomalies, comparing observed distributions against baseline profiles stored in the configuration database. When chi-square statistic exceeds threshold (default: χ² > 50 for p < 0.05), the component flags anomalous behavior. > > **Alert Generator** (element 240): Receives both signature match notifications from the DPI engine and anomaly flags from the statistical component. The generator formats alert messages according to the Common Event Format (CEF) standard, including: > - Timestamp (UTC) > - Source IP and port > - Destination IP and port > - Alert type (signature match or statistical anomaly) > - Severity level (1-10) > - Detailed description > > Formatted alerts are transmitted to the security operations console via syslog protocol over TLS-encrypted connection." **Analysis of Structural Support**: **Component Breakdown**: - Four distinct components identified - Each component structurally described - Interconnections specified **Operational Detail**: - Algorithms named: Aho-Corasick, chi-square testing - Data structures specified: Ring buffer, histogram, signature database - Parameters provided: Buffer size (1 MB), time windows (60 sec), thresholds (χ² > 50) - Protocols identified: CEF formatting, syslog transmission, TLS encryption **Integration Description**: - Data flow between components clear - Triggering conditions specified - Output formatting detailed **Effect**: This specification support establishes that "traffic analysis module," read in light of the specification, connotes definite structure. Even though the claim term itself is somewhat generic, the detailed specification description provides the structural context necessary to support structural interpretation. ### B. Claim Drafting Techniques #### 1. Technique One: Describe Operational Architecture ##### a. The Principle Rather than merely naming components, describe how they operate within the system. ##### b. Template Structure **General Template**: > "[Component term] that [receives/processes/generates] [specific inputs/operations/outputs] [from/to specific system elements]" **Enhanced Template with Full Detail**: > "[Component term] [configured to/that] [receive(s)] [specific input data] from [specific source], [perform(s)] [specific processing operations] [under specific conditions], and [generate(s)/output(s)] [specific results] to [specific destination]" ##### c. Progressive Examples **Level 1 - Generic (Inadequate)**: > "a data processing module" **Analysis**: Provides only functional label. No operational detail. **Level 2 - Basic Operation (Minimal)**: > "a data processing module that processes sensor data" **Analysis**: Adds "processes sensor data" but still functional. Describes what, not how. **Level 3 - Operational (Good)**: > "a data processing module that receives raw sensor data from the data acquisition interface, applies calibration coefficients, performs moving-average filtering, and stores processed results in the output buffer" **Analysis**: Describes inputs (raw sensor data from data acquisition interface), processing (calibration, filtering), and outputs (to output buffer). Provides operational context. **Level 4 - Detailed Operational (Better)**: > "a data processing module that receives raw sensor data from the data acquisition interface at 100 Hz sampling rate, retrieves calibration coefficients from the calibration table based on sensor identifier, applies the coefficients through multiplicative scaling (y = mx + b), performs moving-average filtering with a configurable window size (default: 10 samples), and stores processed results in the output buffer organized as timestamped records" **Analysis**: Adds specific parameters (100 Hz sampling, 10-sample window), specific algorithms (y = mx + b), data organization (timestamped records), and configuration details. Comprehensive operational description. **Level 5 - Comprehensive Integration (Best)**: > "a data processing module that receives raw sensor data from the data acquisition interface at 100 Hz sampling rate, retrieves calibration coefficients from the calibration table indexed by sensor identifier, applies the coefficients through linear transformation (y = mx + b where m and b are retrieved coefficients), performs moving-average filtering using a sliding window maintained in a circular buffer with configurable size (default: 10 samples, range: 5-50 samples), validates that processed values fall within acceptable ranges stored in the validation criteria table, generates error flags when out-of-range values are detected, and stores both processed results and any error flags in the output buffer organized as timestamped records with associated quality indicators" **Analysis**: Complete operational architecture including: - Input specifications with rates - Data retrieval with indexing methods - Specific algorithms with formulas - Data structures (circular buffer) - Configuration parameters with defaults and ranges - Validation logic - Error handling - Output organization - Quality metadata ## IV. Preventing Unintended § 112(f) Invocation (Continued) ### B. Claim Drafting Techniques (Continued) #### 2. Technique Two: Specify Integration with Other Components ##### a. The Principle Software structure emerges partly from relationships. Describing component connections and interactions provides structural definition beyond individual component operation. ##### b. Integration Elements to Specify **Data Flow**: 1. What data flows between components? 2. In what direction? 3. In what format? 4. At what rate or frequency? **Control Signals**: 1. What signals coordinate component operation? 2. What triggers component activation? 3. What indicates completion? 4. What error signals exist? **Shared Resources**: 1. What resources do components share? 2. How is access coordinated? 3. What synchronization mechanisms apply? 4. How are conflicts resolved? **Dependencies**: 1. What components depend on others? 2. In what order do components operate? 3. What preconditions must be satisfied? 4. What postconditions are guaranteed? ##### c. Example Demonstrating Integration **Without Integration (Weak)**: > "An apparatus comprising: a data collection module; a processing module; and a storage module." **Analysis of Deficiency**: - Three components named - No relationships described - No data flow specified - No operational sequence - Components appear independent - No system architecture evident **With Integration (Strong)**: > "An apparatus comprising: > > a data collection module configured to receive sensor measurements at 100 Hz sampling rate and forward timestamped measurement packets to a shared data bus; > > a processing module connected to the shared data bus, configured to monitor the bus for a data-ready signal, retrieve measurement packets from the bus when the data-ready signal is asserted by the collection module, process the measurements according to algorithms specified in a configuration file stored in non-volatile memory, and write processed results to the shared data bus accompanied by a results-ready signal; and > > a storage module connected to the shared data bus, configured to monitor the bus for the results-ready signal, retrieve processed results from the bus when the results-ready signal is asserted by the processing module, and store the results in non-volatile flash memory organized by timestamp index." **Analysis of Structural Sufficiency**: **Data Flow Specified**: - Collection module → shared bus → processing module - Processing module → shared bus → storage module - Format: Timestamped measurement packets - Format: Processed results with timestamps - Rate: 100 Hz sampling **Control Signals Identified**: - Data-ready signal (collection → processing) - Results-ready signal (processing → storage) - Signal-based coordination mechanism **Shared Resource Described**: - Shared data bus - All three modules connect to bus - Bus serves as communication medium **Dependencies Established**: - Processing module depends on collection module's data-ready signal - Storage module depends on processing module's results-ready signal - Sequential operation: collection → processing → storage **Synchronization Mechanism**: - Signal-based handshaking - Modules monitor bus for specific signals - Assertion of signal triggers retrieval **Additional Structural Elements**: - Configuration source: Configuration file in non-volatile memory - Data organization: Timestamp indexing - Storage medium: Flash memory ##### d. Integration Patterns for Different System Types **Pattern 1: Pipeline Architecture** **Characteristics**: - Data flows through sequential stages - Each stage processes and forwards - Output of stage N becomes input of stage N+1 **Example**: > "An image processing apparatus comprising: > > a pixel capture stage that receives raw pixel data from an image sensor at 60 frames per second, performs demosaicing using bilinear interpolation to generate RGB pixel values, and outputs RGB frames to a pixel buffer; > > a color correction stage that retrieves RGB frames from the pixel buffer, applies a 3×3 color transformation matrix to adjust white balance and color saturation, and writes color-corrected frames to a processing buffer; and > > a compression stage that retrieves color-corrected frames from the processing buffer, applies JPEG compression with quality factor retrieved from a configuration register, and stores compressed image data to a file system." **Integration Elements**: - Sequential flow: capture → correction → compression - Buffer-based communication: pixel buffer, processing buffer - Frame rate specification: 60 fps - Clear input/output for each stage - Configuration source: configuration register - Final output: file system **Pattern 2: Event-Driven Architecture** **Characteristics**: - Components respond to events - Event dispatcher coordinates - Asynchronous operation **Example**: > "A network monitoring system comprising: > > a packet capture component that receives network packets from a network interface controller, extracts packet metadata (source IP, destination IP, protocol, timestamp), and publishes packet-received events to an event queue; > > an analysis component subscribed to packet-received events, that retrieves events from the event queue, applies pattern matching rules stored in a rule database, identifies rule violations, and publishes alert events to the event queue; and > > a logging component subscribed to alert events, that retrieves alert events from the event queue, formats alert messages according to Common Event Format specification, and transmits formatted messages to a syslog server via UDP port 514." **Integration Elements**: - Event queue as central coordination - Publish/subscribe pattern - Event types: packet-received, alert events - Asynchronous operation - External systems: network interface, rule database, syslog server **Pattern 3: Shared Memory Architecture** **Characteristics**: - Components share memory regions - Coordination through locks or semaphores - Concurrent access management **Example**: > "A data processing system comprising: > > a producer component that acquires mutex lock on a shared memory region, writes sensor data to a circular buffer maintained in the shared memory, updates a write pointer indicating the next available buffer position, releases the mutex lock, and signals a data-available semaphore; > > a consumer component that waits on the data-available semaphore, acquires the mutex lock on the shared memory region upon semaphore signal, reads sensor data from the circular buffer starting at a read pointer position, updates the read pointer to reflect consumed data, and releases the mutex lock; and > > wherein the circular buffer wraps when the write pointer reaches buffer end, and wherein buffer overflow is prevented by comparing write pointer to read pointer before writing." **Integration Elements**: - Shared resource: Shared memory region with circular buffer - Synchronization: Mutex lock prevents concurrent access - Signaling: Semaphore indicates data availability - Pointers: Write pointer and read pointer coordinate access - Overflow prevention: Pointer comparison logic #### 3. Technique Three: Use Structurally Descriptive Terms ##### a. The Spectrum of Structural Character Some terms inherently convey more structural meaning than others. **High Structural Character**: **"Parser"**: - Implies lexical analysis - Suggests grammar rules - Indicates token generation - Connotes specific parsing algorithm (LL, LR, recursive descent) **"Compiler"**: - Implies multi-phase processing - Suggests lexical analysis phase - Indicates syntax analysis phase - Connotes code generation phase - Implies symbol table management **"Controller"**: - Implies control logic - Suggests state machine - Indicates signal generation - Connotes coordination function **"Engine"**: - Implies processing core - Suggests defined inputs/outputs - Indicates transformation capability - Connotes specific algorithm implementation **"Interface"**: - Implies boundary definition - Suggests protocol specification - Indicates signal mapping - Connotes connection methodology **"Buffer"**: - Implies storage structure - Suggests specific organization (FIFO, LIFO, circular) - Indicates capacity constraints - Connotes access patterns **"Cache"**: - Implies fast storage - Suggests hierarchy (L1, L2, L3) - Indicates replacement policy (LRU, LFU, random) - Connotes associativity (direct-mapped, set-associative, fully-associative) **Low Structural Character**: **"Module"**: - Generic container - No inherent structure - Could be hardware or software - Provides no implementation guidance **"Unit"**: - Generic component - No inherent meaning - Could be any subdivision - Conveys no architectural information **"Element"**: - Most generic possible - No structural implication - Could be anything - Provides zero specificity **"Device"**: - Generic apparatus - No inherent configuration - Could be any implementation - Lacks specificity **"System"**: - Generic collection - No inherent organization - Could encompass anything - Too broad for individual limitations ##### b. Application Strategies **Strategy One: Prefer Structurally Descriptive Terms When Accurate** **Generic (Weak)**: > "data processing module" **Structurally Descriptive (Strong)**: > "data processing engine with input buffer, transformation pipeline, and output queue" **Analysis of Improvement**: - "Engine" suggests processing core (more structural than "module") - "Input buffer" specifies storage structure for inputs - "Transformation pipeline" indicates sequential processing architecture - "Output queue" specifies FIFO storage for outputs - Overall: Architectural description rather than generic label **Strategy Two: Combine Generic Terms with Structural Modifiers** **Generic (Weak)**: > "communication module" **Modified with Structure (Strong)**: > "communication module comprising a message queue interface, a protocol formatter, and a network interface controller" **Analysis of Improvement**: - Breaks down module into structural components - "Message queue interface" specifies queue-based architecture - "Protocol formatter" suggests transformation function - "Network interface controller" identifies hardware interface - Overall: Internal architecture described **Strategy Three: Use Technical Terms of Art from the Field** **Generic (Weak)**: > "sorting component" **Field-Specific Term (Strong)**: > "quicksort processor with median-of-three pivot selection logic and recursive partition handling" **Analysis of Improvement**: - "Quicksort processor" identifies specific algorithm - "Median-of-three pivot selection" specifies pivot strategy - "Recursive partition handling" describes algorithmic approach - Uses terms of art from computer science (quicksort, median-of-three, recursion) - Overall: Specific algorithm and strategy identified ##### c. Caution Regarding Term Selection Alone **Important Limitation**: Term selection alone cannot overcome pure functional claiming. **Examples Showing Limitation**: **Example 1**: > "parser for processing data" **Analysis**: - "Parser" is structurally descriptive term - "For processing data" is pure functional language - Combination still functional despite better term - Describes what (processing data) not how **Example 2**: > "compiler for generating code" **Analysis**: - "Compiler" strongly suggests structure - "For generating code" is still functional - No operational detail provided - Generic function despite structural term **Example 3**: > "cache for storing data" **Analysis**: - "Cache" implies specific storage architecture - "For storing data" provides no detail - Missing: cache organization, replacement policy, associativity - Generic despite structural term **Key Principle**: Term selection supports structural interpretation but does not substitute for operational description. The most structurally descriptive term becomes generic when coupled with pure functional language lacking operational detail. **Better Approach**: Combine structurally descriptive terms with operational detail: > "a recursive descent parser that tokenizes input source code using a lexical analyzer, builds an abstract syntax tree according to grammar rules stored in a parse table, performs semantic analysis to validate type compatibility, and generates intermediate representation code" **Analysis**: - Structurally descriptive term: "recursive descent parser" - Operational detail: tokenization, AST building, semantic analysis, IR generation - Data structures: parse table, abstract syntax tree - Processing sequence: lex → parse → semantic → codegen - Both term selection AND operational description working together #### 4. Technique Four: Avoid Pure Functional Recitation ##### a. The Distinction: "How" Versus "What" Claims should describe *how* elements operate, not merely *what* they accomplish. **Functional Language ("What")**: - Describes desired result - States objective or goal - Provides no operational detail - Focuses on function performed **Structural Language ("How")**: - Describes operational steps - Explains mechanism - Provides implementation detail - Focuses on method of operation ##### b. Transformation Examples with Analysis **Example 1: Encryption** **Functional (What)**: > "means for encrypting data" **Analysis of Functional Language**: - States function: encryption - No algorithm specified - No parameters provided - Could encompass any encryption method - Pure functional claiming **Structural (How)**: > "an encryption engine that applies the AES-256 cipher in Cipher Block Chaining (CBC) mode using a session key derived from user credentials via the PBKDF2 key derivation function with 10,000 iterations and a 128-bit salt" **Analysis of Structural Language**: - Algorithm specified: AES-256 - Mode specified: CBC - Key derivation detailed: PBKDF2 with parameters - Iteration count: 10,000 - Salt size: 128 bits - Complete operational specification **Example 2: Validation** **Functional (What)**: > "a validation component for checking data integrity" **Analysis of Functional Language**: - Generic component: "validation component" - Functional connector: "for" - Generic function: "checking data integrity" - No mechanism described - No algorithm identified **Structural (How)**: > "a validation component that computes a SHA-256 hash of received data blocks, compares the computed hash to a hash value extracted from a message authentication code field appended to the data, and generates an error signal to the error handling controller upon detecting a mismatch between computed and received hash values" **Analysis of Structural Language**: - Algorithm: SHA-256 hashing - Input: Received data blocks - Comparison: Computed hash vs. received hash - Error detection: Mismatch triggers signal - Output: Error signal to error handling controller - Complete validation mechanism described **Example 3: Control** **Functional (What)**: > "a control module for coordinating device operation" **Analysis of Functional Language**: - Generic term: "control module" - Functional connector: "for" - Vague function: "coordinating device operation" - No control mechanism described - No operational logic provided **Structural (How)**: > "a control module that maintains a finite state machine with four states (idle, active, error, shutdown), transitions between states based on sensor inputs read from an input register and timer expirations tracked by a hardware timer, generates control signals to peripheral devices according to a control signal mapping table indexed by current state, and logs all state transitions to a state history buffer with timestamps" **Analysis of Structural Language**: - Control mechanism: Finite state machine - States enumerated: idle, active, error, shutdown - Transition triggers: Sensor inputs, timer expirations - Input source: Input register - Timing mechanism: Hardware timer - Output generation: Control signal mapping table - State-dependent behavior: Signals vary by state - Logging: State history with timestamps - Complete control architecture described ##### c. The "Configured To" Language Pattern **Effective Pattern**: Use "configured to" or "that" followed by specific operational steps. **General Template**: > "[Component] configured to: > - [specific operation 1]; > - [specific operation 2]; and > - [specific operation 3]" **Alternative Template**: > "[Component] that [performs operation 1], [performs operation 2], and [performs operation 3]" **Example Application: Packet Processing** **Using "Configured To" with Bullet Format**: > "a packet processing module configured to: > - receive data packets from a network interface buffer; > - extract destination IP addresses from packet headers by parsing bytes 16-19 of the IPv4 header; > - perform longest-prefix matching of destination addresses against routing table entries stored in a TCAM (ternary content-addressable memory) structure; and > - forward packets to output interfaces associated with matched routing entries while updating packet forwarding counters maintained in hardware registers." **Using "That" with Inline Format**: > "a packet processing module that receives data packets from a network interface buffer, extracts destination IP addresses from bytes 16-19 of the IPv4 packet header, performs longest-prefix matching against routing table entries stored in TCAM, and forwards packets to output interfaces associated with matched entries while incrementing forwarding counters" **Analysis of Both Formats**: **Benefits of "Configured To" Bullet Format**: - Visual clarity through bulleted structure - Each operation clearly delineated - Easy to read and understand - Suitable for complex multi-step processes **Benefits of "That" Inline Format**: - More natural language flow - Compact presentation - Traditional claim format - Suitable for moderate complexity **Both Formats Provide**: - Specific operations enumerated - Implementation detail included - Data structures identified (TCAM) - Processing sequence clear - Integration shown (network interface, routing table, output interfaces) ### C. Specification Support Requirements Regardless of claim language, comprehensive specification disclosure provides critical support for both structural and means-plus-function claim interpretations. #### 1. Dual-Purpose Disclosure Strategy **Optimal Approach**: Draft specifications to support *both*: A. Structural claim interpretation (avoiding § 112(f) at Step 1) B. Means-plus-function fallback (satisfying Step 2 if § 112(f) applies) **Implementation**: ##### a. For Structural Support Provide detailed operational descriptions that can be read into the claims: **Elements to Include**: 1. Describe inputs, outputs, processing, integration 2. Use consistent terminology with claims 3. Provide flowcharts and diagrams showing operation 4. Explain how components interact 5. Detail data flow and control flow 6. Specify parameters and configuration options **Example Specification Section**: > "The packet validation module (Figure 2, element 200) operates within the network security system to ensure data integrity and detect corrupted transmissions. The module receives network packets from the packet capture interface (element 110) at line rate (up to 10 Gbps). For each received packet, the module extracts a 32-bit checksum value from the packet trailer (bytes N-4 through N-1, where N is the packet length). The module then computes a CRC-32 checksum of the packet payload using the polynomial 0x04C11DB7, comparing the computed value against the extracted checksum. If the values match, the packet is forwarded to the protocol analysis module (element 300) with a validity flag set to TRUE. If the values do not match, indicating data corruption during transmission, the module discards the packet, increments an error counter, and optionally generates an error log entry if logging is enabled in the configuration register." **Structural Support Provided**: - Operational context: How module operates within system - Input source: Packet capture interface (element 110) - Input rate: Up to 10 Gbps - Processing detail: Checksum extraction and computation - Algorithm: CRC-32 with specific polynomial - Decision logic: Match comparison - Output paths: Forward to element 300 or discard - Error handling: Counter increment, optional logging - Configuration: Logging enable in configuration register ##### b. For MPF Fallback Provide algorithmic disclosures that satisfy Step 2: **Elements to Include**: 1. Disclose specific algorithms for all functions 2. Link algorithms clearly to claimed functions 3. Provide sufficient detail for implementation 4. Include multiple embodiments where appropriate 5. Use flowcharts, pseudocode, or detailed prose 6. Specify all parameters and their ranges **Example Specification Section**: > "For means-plus-function claims, the following algorithmic disclosures apply: > > **Means for Validating Packets** (Claim 10): The packet validation algorithm operates as illustrated in Figure 4 and described below: > > Step 1: Receive packet from input buffer > Step 2: Extract packet length N from header > Step 3: Extract checksum_received from bytes (N-4) to (N-1) > Step 4: Compute checksum_calculated over payload bytes 0 to (N-5): > Initialize CRC register to 0xFFFFFFFF > FOR each byte b in payload: > XOR CRC register with (b << 24) > FOR i = 0 to 7: > IF MSB of CRC register is 1 THEN > Left-shift CRC register by 1 > XOR CRC register with polynomial 0x04C11DB7 > ELSE > Left-shift CRC register by 1 > END IF > END FOR > END FOR > Complement CRC register (bitwise NOT) > checksum_calculated = CRC register > Step 5: IF checksum_calculated == checksum_received THEN > Mark packet as valid > Forward to next processing stage > ELSE > Mark packet as invalid > Discard packet > Increment error counter > END IF > > This algorithm provides the corresponding structure for the 'means for validating packets' recited in claim 10." **MPF Support Provided**: - Explicit linkage: "means for validating packets (Claim 10)" - Complete algorithm: Step-by-step procedure - Specific polynomial: 0x04C11DB7 - Initialization value: 0xFFFFFFFF - Bit-level operations: Shifts, XORs - Decision logic: Equality check - Alternative outcomes: Valid vs. invalid paths - Figure reference: Figure 4 - Explicit statement: "provides the corresponding structure" #### 2. Specification Organization Strategy ##### a. Recommended Structure **Section 1: Field of the Invention** - Brief statement of technical field - General area of innovation **Section 2: Background** - Prior art discussion - Problems with prior approaches - Need for improvement **Section 3: Summary** - High-level system description - Major components and interactions - Key advantages over prior art **Section 4: Brief Description of Drawings** - List of figures - Brief description of each figure **Section 5: Detailed Description** **Subsection 5.1: System Overview** - Complete system architecture - Major components identification - Data flow overview - Control flow overview **Subsection 5.2: Component Descriptions** - Detailed description of each component - Operational context (inputs, outputs, processing) - Integration with other components - References to detailed algorithm sections **Subsection 5.3: Algorithmic Disclosures** - Specific algorithms for each function - Flowcharts with accompanying text - Pseudocode or prose descriptions - Link to corresponding claims - Multiple embodiments where applicable **Subsection 5.4: Data Structures** - Database schemas - Memory layouts - Message formats - Configuration structures **Subsection 5.5: Alternative Embodiments** - Variations on main embodiment - Different algorithmic approaches - Alternative implementations - Modification possibilities **Subsection 5.6: Implementation Details** - Hardware platforms - Software languages and frameworks - Performance considerations - Scaling approaches **Section 6: Claims** ##### b. Benefits of This Organization **For Structural Claims**: - Sections 5.1-5.2 provide operational context - Consistent terminology links claims to description - Integration descriptions show relationships - Supports Step 1 structural interpretation **For MPF Claims**: - Section 5.3 provides algorithmic disclosures - Clear organization facilitates linkage - Multiple embodiments expand scope - Satisfies Step 2 requirements **For Examination**: - Logical organization aids examiner understanding - Clear linkages simplify finding corresponding structure - Comprehensive disclosure reduces rejections - Alternative embodiments provide amendment options **For Litigation**: - Well-organized specification aids claim construction - Clear algorithmic disclosures support validity - Multiple embodiments demonstrate enablement breadth - Detailed descriptions support infringement theories --- ## V. Responding to Improper USPTO Invocation ### A. Overview of Examiner Errors 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. #### 1. Common Examiner Error Patterns **Error Pattern 1: Focus on Term in Isolation** **Examiner Action**: Examiner identifies generic term ("module," "unit") and immediately applies § 112(f) without considering complete claim phrase. **Example**: - **Claim**: "a processing module that receives data packets, extracts headers, validates fields, and routes results" - **Examiner**: "The term 'module' is generic and lacks structure. Section 112, ¶ 6 applies." **Error**: Examiner ignored operational detail in complete phrase. **Error Pattern 2: Overlooks Operational Detail** **Examiner Action**: Examiner sees functional keywords ("for," "processing," "analyzing") and reflexively applies § 112(f) without analyzing whether operational context exists. **Example**: - **Claim**: "a data analysis engine configured to apply Fourier transforms, compare frequencies against thresholds, and generate alerts" - **Examiner**: "This limitation recites analyzing data, which is functional. Section 112, ¶ 6 applies." **Error**: Examiner missed specific algorithm (Fourier transform) and operational steps. **Error Pattern 3: Fails to Credit Software Structure Principles** **Examiner Action**: Examiner applies physical structure standards to software claims, requiring physical components. **Example**: - **Claim**: "a parser that tokenizes source code according to grammar rules and builds an abstract syntax tree" - **Examiner**: "The specification does not disclose physical structure. Section 112, ¶ 6 applies." **Error**: Software structure consists of algorithms and operational descriptions, not physical components. **Error Pattern 4: Applies § 112(f) to All Generic Terms** **Examiner Action**: Examiner treats all uses of "module," "unit," or "component" as automatically invoking § 112(f). **Example**: - **Claim**: Set of 10 claims using "module" throughout with extensive operational detail - **Examiner**: "All limitations using 'module' are construed under Section 112, ¶ 6." **Error**: Blanket application without individualized analysis of each limitation. #### 2. Response Strategy Overview When improper invocation occurs, practitioners must: **First**: Demonstrate claim term connotes sufficient structure (Step 1 defense) **Second**: Prove specification provides adequate corresponding structure (Step 2 fallback) **Third**: Avoid unnecessary amendments that create prosecution history issues **Priority**: Always prioritize Step 1 arguments (avoiding § 112(f)) over Step 2 arguments (accepting § 112(f) but showing adequate disclosure). Accepting § 112(f) application narrows claim scope even if specification is adequate. ### B. Structural Arguments (Step 1 Defense) The primary response should demonstrate that the claim term has "sufficiently definite meaning as the name for structure" to one skilled in the art. #### 1. Argument One: Point to Complete Claim Phrase ##### a. The Principle The two-step analysis examines "the entire claim phrase," not merely the introductory term. *Apple Inc. v. Motorola, Inc.*, 757 F.3d 1286, 1296 (Fed. Cir. 2014). ##### b. Response Template > "**I. The Office Has Improperly Analyzed the Claim Limitation in Isolation** > > The Office's rejection focuses on the term '[module/unit/component]' without considering the complete claim limitation. However, the Federal Circuit has clearly held that the structural analysis must examine 'the entire claim phrase,' not merely the introductory term. *Apple Inc. v. Motorola, Inc.*, 757 F.3d 1286, 1296 (Fed. Cir. 2014). > > The complete limitation recites: '[full claim language including all operational detail].' > > This complete phrase describes how the [element] operates within the claimed invention, including: > > - **Inputs**: [specify inputs and sources] > - **Processing**: [specify operations and algorithms] > - **Outputs**: [specify results and destinations] > - **Integration**: [specify connections to other components] > > Such operational detail provides the 'how' that constitutes software structure under Federal Circuit precedent. *Apple*, 757 F.3d at 1298-99." ##### c. Detailed Example Response **Examiner Rejection**: > "The term 'processing module' in claim 1 is a generic placeholder that does not connote sufficient structure to one skilled in the art. Accordingly, the Office construes this limitation under 35 U.S.C. § 112, sixth paragraph [now § 112(f)]. The specification does not disclose adequate corresponding structure. Claim 1 is rejected under 35 U.S.C. § 112, second paragraph [now § 112(b)] as indefinite." **Applicant Response**: > "**RESPONSE TO REJECTION UNDER 35 U.S.C. § 112(b)** > > **I. The Claim Limitation Does Not Invoke § 112(f)** > > Respectfully, the Office has improperly analyzed the claim limitation by focusing on the term 'processing module' in isolation, without considering the complete claim phrase as required by Federal Circuit precedent. > > **A. The Complete Claim Phrase Must Be Analyzed** > > In *Apple Inc. v. Motorola, Inc.*, 757 F.3d 1286, 1296 (Fed. Cir. 2014), the Federal Circuit held that the structural analysis must examine 'the entire claim phrase,' not merely the introductory term. Similarly, in *Joao Control & Monitoring Systems LLC v. Protect America, Inc.*, No. 1-14-CV-134-LY (W.D. Tex. Aug. 18, 2015), the court emphasized that 'the entire claim phrase' determines whether sufficient structure exists. > > **B. The Complete Claim Limitation Recites Operational Structure** > > Claim 1 does not merely recite 'a processing module.' Rather, the complete limitation recites: > > > 'a processing module that receives data packets from the network interface controller, extracts header information from each packet based on protocol specifications stored in a configuration table, validates the extracted header fields against predetermined criteria including source address verification and checksum validation, and routes packets determined to be valid to the application handler while discarding packets that fail validation.' > > This complete phrase describes how the processing module operates, providing extensive operational detail: > > **Inputs Specified**: > - Data type: Data packets > - Source: Network interface controller > - Format: Packets with headers and payloads > > **Processing Described in Detail**: > - Header extraction based on protocol specifications > - Protocol specifications retrieved from configuration table > - Field validation against predetermined criteria > - Specific validation types: source address verification, checksum validation > - Routing decision based on validation result > > **Outputs Defined**: > - Valid packets: Routed to application handler > - Invalid packets: Discarded > > **Integration with System Components**: > - Input from: Network interface controller > - Configuration from: Configuration table > - Output to: Application handler > > **C. Software Structure Is Understood Through Operational Description** > > For software inventions, the Federal Circuit has held that structure may be understood '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. The Court further explained that a software claim term 'may also have sufficient structure where there is a description of the term's operation, such as its input, output, or connections.' *Id.* at 1299. > > The claim limitation provides exactly this type of operational description: > > - **Operation**: Packet reception, header extraction, validation, routing > - **Inputs**: Data packets from network interface controller > - **Outputs**: Valid packets to application handler, invalid packets discarded > - **Connections**: Network interface controller (input), configuration table (parameters), application handler (output) > > The limitation describes 'how the function is achieved in the context of the invention,' not merely 'what' function is performed. *Id.* > > **D. Conclusion** > > The complete claim phrase, when properly analyzed as required by *Apple* and *Joao*, provides sufficient structural detail to avoid § 112(f) construction. The limitation describes the processing module's operation, inputs, outputs, and integration within the system—the very elements that constitute software structure according to Federal Circuit precedent. > > Accordingly, Applicant respectfully requests withdrawal of the rejection under § 112(b), as the claim limitation does not invoke § 112(f) and is therefore not indefinite for lack of corresponding structure." ## V. Responding to Improper USPTO Invocation (Continued) ### B. Structural Arguments (Continued) #### 2. Argument Two: Reference Software-Specific Structure Principles ##### a. The Principle For software patents, structure is properly understood through algorithmic and operational descriptions, not physical components. ##### b. Response Template > "**Software Structure Consists of Algorithms and Operational Descriptions** > > The Office appears to be applying physical structure standards to a software invention. For software patents, the Federal Circuit has repeatedly held that structure may be understood through algorithmic and operational descriptions rather than physical components. > > As the Court explained in *Apple Inc. v. Motorola, Inc.*, 757 F.3d 1286, 1298-99 (Fed. Cir. 2014): > > > '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.' > > The claims describe the [element's] algorithmic operation—the specific processing steps it performs—providing structural definition appropriate for software inventions." ##### c. Detailed Example Response **Examiner Rejection**: > "The specification discloses that the 'authentication engine' is implemented in software. Software is not structure. The Office construes this limitation under § 112, ¶ 6. No adequate structure is disclosed." **Applicant Response**: > "**II. Software Has Structure—Structure Defined by Algorithms** > > **A. The Office Has Misapplied the Law Regarding Software Structure** > > Respectfully, the Office's statement that 'software is not structure' misapplies Federal Circuit precedent. Software inventions do have structure, but that structure manifests through algorithms and operational descriptions rather than physical components. > > **B. Federal Circuit Precedent on Software Structure** > > The Federal Circuit has consistently recognized that software structure exists and is properly understood through algorithmic disclosure: > > *Apple Inc. v. Motorola, Inc.*, 757 F.3d 1286, 1298-99 (Fed. Cir. 2014): > > '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.' > > *Id.* at 1299: > > '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 Court emphasized that for software claims, 'the limitation's operation is more than just its function; it is **how the function is achieved** in the context of the invention.' *Id.* (emphasis added). > > **C. The Claims Describe Software Structure** > > The claims recite: 'an authentication engine that receives credentials from the login interface, compares them against stored credentials using hash comparison, and generates session tokens upon successful authentication.' > > This claim language describes the authentication engine's algorithmic operation: > > - **Inputs**: User credentials from login interface > - **Processing**: Hash comparison against stored credentials > - **Outputs**: Session tokens upon successful authentication > - **Algorithm**: Hash-based comparison (specific comparison method) > - **Decision Logic**: Token generation conditional on successful match > > This operational description constitutes structure for software inventions under *Apple*. > > **D. The Specification Provides Additional Structural Detail** > > Moreover, the specification (paragraph [0034]) provides extensive algorithmic detail: > > > '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 using the HMAC algorithm with the server's private key.' > > This specification disclosure identifies: > - Specific hash algorithm: SHA-256 > - Specific token generation algorithm: HMAC > - Data source: User database > - Token characteristics: Time-limited, access privileges encoded > - Cryptographic key: Server's private key > > **E. Conclusion** > > The claim limitation describes *how* the authentication engine operates, providing the operational and algorithmic detail that constitutes structure for software inventions. The Office's application of physical structure standards to a software invention is inconsistent with Federal Circuit precedent. > > Accordingly, Applicant respectfully requests withdrawal of the rejection." #### 3. Argument Three: Demonstrate Operational Context ##### a. The Principle Claims providing operational context—inputs, outputs, processing, integration—describe how elements work, establishing structural character. ##### b. Response Template > "**The Claim Provides Operational Context Establishing Structure** > > The claim limitation provides operational context that establishes structural character: > > - **Inputs**: [Specify inputs and sources] > - **Processing**: [Specify operations] > - **Outputs**: [Specify results and destinations] > - **Integration**: [Specify connections] > > This operational description explains *how* the [element] operates within the system, not merely *what* function it performs. This 'how' detail constitutes structure under Federal Circuit precedent." ##### c. Detailed Example Response **Examiner Rejection**: > "The term 'communication controller' in claim 5 is a generic placeholder that does not recite sufficient structure." **Applicant Response**: > "**III. The Complete Claim Limitation Provides Extensive Operational Context** > > **A. The Complete Claim Language** > > The Office's rejection addresses only the term 'communication controller' without considering the complete claim limitation. Claim 5 recites: > > > 'a communication controller 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.' > > **B. Operational Context Establishing Structure** > > This limitation provides extensive operational context: > > **System Integration**: > - Connected to: Message queue (input source) > - Retrieves specifications from: Protocol handler > - Transmits via: Network interface > - Reports status to: Queue status tracker > > **Operational Flow**: > 1. Retrieve messages from queue > 2. Format according to protocol specifications > 3. Transmit via network interface > 4. Monitor acknowledgment signals > 5. Return status to tracker > > **Data Flow**: > - Input: Outbound messages from message queue > - Configuration: Protocol specifications from protocol handler > - Output: Formatted messages to network interface > - Feedback: Acknowledgment signals to queue status tracker > > **C. This Operational Detail Constitutes Software Structure** > > As the Federal Circuit held in *Apple*, operational description including 'input, output, or connections' establishes software structure. 757 F.3d at 1299. > > The claims provide exactly this level of detail: > - **Inputs**: Messages from queue, specifications from protocol handler, acknowledgment signals from network > - **Outputs**: Formatted messages to network interface, status to queue tracker > - **Connections**: Queue, protocol handler, network interface, status tracker > - **Operation**: Retrieve, format, transmit, monitor sequence > > This operational context describes *how* the communication controller operates within the system architecture, not merely *what* function it performs. > > **D. Conclusion** > > The complete claim limitation, properly analyzed, provides operational context that establishes structural character under Federal Circuit precedent. Section 112, ¶ 6 does not apply." #### 4. Argument Four: Claim Differentiation ##### a. When Applicable This argument applies when the application includes both claims using generic terms and explicit means-plus-function claims using "means for" language. ##### b. The Principle The doctrine of claim differentiation creates a presumption that different claims have different scope. *Kraft Foods, Inc. v. Int'l Trading Co.*, 203 F.3d 1362, 1368 (Fed. Cir. 2000). ##### c. Response Template > "**IV. Claim Differentiation Supports Structural Interpretation** > > The application includes [explicit means-plus-function claims using 'means for' language]. The doctrine of claim differentiation creates a presumption that different claims have different scope. > > If the Office's construction were correct—treating [generic term claims] as means-plus-function—then [generic term claims] and [MPF claims] would have identical scope, violating the presumption of claim differentiation. > > The presence of explicit 'means for' language in [MPF claims] demonstrates that Applicant knows how to invoke § 112(f) when desired. The use of different language in [generic term claims] indicates different scope was intended." ##### d. Detailed Example Response **Examiner Rejection**: > "Claims 1-9 recite 'processing module' which is construed as means-plus-function under § 112, ¶ 6." **Applicant Response** (when application also includes Claim 10 with explicit MPF): > "**IV. Claim Differentiation Supports Structural Interpretation of Claims 1-9** > > **A. The Application Includes Both Structural and MPF Claims** > > The application includes: > - Claims 1-9: Recite 'processing module that receives data packets, extracts headers, validates fields, and routes results' > - Claim 10: Recites 'means for receiving data packets; means for extracting headers; means for validating fields; and means for routing results' > > **B. The Doctrine of Claim Differentiation** > > The Federal Circuit has held that the doctrine of claim differentiation creates a presumption that different claims have different scope: > > *Kraft Foods, Inc. v. Int'l Trading Co.*, 203 F.3d 1362, 1368 (Fed. Cir. 2000): > > 'The doctrine of claim differentiation... creates a presumption that each claim in a patent has a different scope.' > > **C. Application to Present Claims** > > If the Office's construction were correct—that 'processing module' in Claims 1-9 invokes § 112, ¶ 6—then Claims 1-9 and Claim 10 would be construed identically: > > - Claims 1-9 under Office construction: Means-plus-function, limited to disclosed structures > - Claim 10: Explicitly means-plus-function, limited to disclosed structures > - Result: Identical scope > > This identical scope would violate the presumption of claim differentiation. > > **D. Applicant's Intent Is Clear** > > The presence of explicit 'means for' language in Claim 10 demonstrates that Applicant knows how to invoke § 112, ¶ 6 when desired. The fact that Applicant used different language in Claims 1-9 ('processing module that [describes operation]') versus Claim 10 ('means for [function]') indicates different claim scope was intended. > > **E. Claims 1-9 Include Operational Detail Absent from Claim 10** > > Moreover, Claims 1-9 include operational detail not present in Claim 10: > > Claims 1-9: 'processing module that receives data packets, extracts headers, validates fields, and routes results' > - Describes specific operations > - Describes operational sequence > - Describes data flow > > Claim 10: 'means for receiving... means for extracting... means for validating... means for routing' > - Recites functions only > - No operational detail > - Generic functional language > > This difference in claim language supports different treatment: Claims 1-9 as structural (describing *how*), Claim 10 as means-plus-function (describing *what*). > > **F. Conclusion** > > The presumption of claim differentiation supports interpreting Claims 1-9 as structural claims that do not invoke § 112, ¶ 6." ### C. Specification Support Arguments (Step 2 Response) If structural arguments fail or as alternative position, demonstrate that specification provides adequate corresponding structure even if § 112(f) applies. #### 1. Argument One: Identify Disclosed Algorithm ##### a. The Approach Point to specific specification passages disclosing algorithms, flowcharts, or operational descriptions. ##### b. Response Template > "**Alternative Argument: Specification Discloses Adequate Structure** > > Without conceding that § 112, ¶ 6 applies (which Applicant respectfully submits it does not for reasons stated above), if the Office maintains its position, the specification discloses adequate corresponding structure. > > Paragraph(s) [XXX] describe(s) the [function] as follows: [quote or summarize algorithm] > > This algorithmic disclosure satisfies the corresponding structure requirement under *Aristocrat Technologies Australia Pty Ltd. v. International Game Technology*, 521 F.3d 1328 (Fed. Cir. 2008)." ##### c. Detailed Example Response **Examiner Rejection (Alternative Position)**: > "If the Office maintains its position that § 112, ¶ 6 applies, Applicant respectfully submits that the specification discloses adequate corresponding structure, rendering the claims definite. > > **V. The Specification Discloses Specific Algorithms Constituting Corresponding Structure** > > **A. Algorithmic Disclosure in Specification** > > Paragraph [0034] describes the authentication process in detail: > > > 'The authentication engine receives user credentials including username and password from the login interface. The engine applies the SHA-256 cryptographic hash function to the received password, generating a 256-bit hash value. The engine retrieves the stored hash value associated with the username from the user database. The engine performs a bitwise comparison of the computed hash to the stored hash. Upon finding a match (all 256 bits identical), the engine generates a time-limited session token. The token generation uses the HMAC (Hash-based Message Authentication Code) algorithm with the server's private key and includes encoded user access privileges. The token is transmitted to the session manager for delivery to the client.' > > **B. This Disclosure Provides Corresponding Structure** > > The specification disclosure provides: > > **Algorithm Identification**: > - Password hashing: SHA-256 (specific cryptographic hash algorithm) > - Token generation: HMAC (specific message authentication code algorithm) > > **Inputs**: > - User credentials (username, password) from login interface > - Stored hash from user database > - Server's private key > - User access privileges > > **Processing Steps**: > 1. Apply SHA-256 to received password > 2. Retrieve stored hash from database > 3. Perform bitwise comparison > 4. Upon match, generate HMAC token > 5. Encode access privileges in token > 6. Transmit to session manager > > **Outputs**: > - Session token to session manager > > **C. Federal Circuit Standard Is Satisfied** > > The Federal Circuit has held that for software means-plus-function claims, 'a corresponding structure must be a specific algorithm disclosed in the specification.' *Aristocrat Techs. Australia Pty Ltd. v. Int'l Game Tech.*, 521 F.3d 1328, 1331-32 (Fed. Cir. 2008). > > The specification satisfies this requirement by identifying: > - Specific algorithms: SHA-256, HMAC > - Complete operational sequence > - All inputs and outputs > - Data sources and destinations > > **D. The Specification Does Not Merely Recite a General-Purpose Computer** > > The specification does not state merely that 'a computer performs authentication.' Rather, it discloses: > - The specific cryptographic hash algorithm (SHA-256) > - The specific comparison method (bitwise comparison of 256-bit values) > - The specific token generation algorithm (HMAC) > - The specific cryptographic key (server's private key) > - The complete operational flow > > This level of algorithmic detail 'transforms the general purpose microprocessor to a special purpose computer programmed to perform the disclosed function.' *Advanced Ground Info. Sys. v. Life360, Inc.*, 830 F.3d 1341, 1349 (Fed. Cir. 2016). > > **E. Conclusion** > > Even if § 112, ¶ 6 were to apply (which Applicant respectfully submits it does not), the specification discloses adequate corresponding structure, and the claims are therefore not indefinite under § 112(b)." #### 2. Argument Two: Demonstrate Clear Linkage ##### a. The Requirement The specification must clearly link disclosed algorithms to claimed functions. *Noah Sys., Inc. v. Intuit Inc.*, 675 F.3d 1302, 1311 (Fed. Cir. 2012). ##### b. Response Template > "**The Specification Clearly Links the Algorithm to the Claimed Function** > > The specification clearly links the disclosed algorithm to the claimed function through: > - [Explicit linkage / Contextual linkage / Terminological linkage] > > This linkage satisfies the requirement articulated in *Noah Systems* that the specification 'clearly link or associate' disclosed structure with claimed function." ##### c. Detailed Example Response **Continuing Previous Example**: > "**VI. The Specification Clearly Links the Algorithm to the Claimed Function** > > **A. Explicit Linkage** > > Paragraph [0034] begins with explicit linkage language: > > > 'The authentication engine performs user credential validation as follows...' > > This sentence explicitly connects the disclosed algorithm to the claimed 'authentication engine.' > > **B. Terminological Consistency** > > The specification uses 'authentication engine' consistently throughout: > > - Overview (paragraph [0015]): 'The authentication engine validates user credentials...' > - Detailed Description (paragraph [0034]): 'The authentication engine receives user credentials...' > - Figure 3 Caption: 'Authentication Engine Processing Flow' > - Algorithm Section (paragraph [0045]): 'The authentication engine algorithm operates as follows...' > > This consistent terminology creates clear linkage between the claimed function and the disclosed algorithm. > > **C. Contextual Placement** > > The algorithm description (paragraphs [0034]-[0040]) immediately follows the introduction of the authentication function (paragraph [0033]), making the association clear from specification organization. > > **D. Figure Cross-Reference** > > Figure 3, specifically labeled 'Authentication Engine Flowchart,' illustrates the disclosed algorithm, reinforcing the connection between the claimed function and the disclosed structure. > > **E. Federal Circuit Standard Is Satisfied** > > The Federal Circuit requires that the specification 'clearly link or associate' disclosed structure with claimed function. *Noah Sys., Inc. v. Intuit Inc.*, 675 F.3d 1302, 1311 (Fed. Cir. 2012). > > The specification satisfies this requirement through: > - Explicit introductory language > - Consistent terminology > - Contextual organization > - Figure cross-references > > **F. Conclusion** > > The specification clearly links the disclosed SHA-256 and HMAC algorithms to the claimed authentication function, satisfying the linkage requirement." ### D. Amendment Strategies If arguments prove unsuccessful, strategic amendments can overcome rejections while preserving maximum claim scope. #### 1. Strategy One: Add Operational Detail to Claims ##### a. The Approach Amend claims to include operational context establishing structure. ##### b. Amendment Example with Remarks **Original Claim**: > "1. An apparatus comprising: a data processing module for analyzing network traffic." **Amended Claim**: > "1. An apparatus comprising: a data processing module configured to receive network packets from a packet capture interface, extract packet metadata including source address, destination address, and port information from packet headers, compare the metadata against traffic pattern rules stored in a rule database, identify packets matching suspicious patterns, and forward matching packets to an alert generation system." **Amendment Remarks**: > "**AMENDMENTS TO THE CLAIMS** > > Claim 1 has been amended to add operational detail describing how the data processing module operates within the claimed system. > > **A. The Amendment Adds Structural Detail** > > The amended language describes: > > - **Inputs**: Network packets from packet capture interface > - **Processing**: Metadata extraction from headers, pattern matching against rule database > - **Decision Logic**: Identification of suspicious patterns > - **Outputs**: Forwarding to alert generation system > > **B. The Amendment Establishes Structural Character** > > This operational detail establishes that 'data processing module' connotes sufficient structure to avoid § 112, ¶ 6, consistent with *Apple Inc. v. Motorola, Inc.*, 757 F.3d 1286 (Fed. Cir. 2014). > > The amendment describes *how* the module operates (specific operations, data flow, integration), not merely *what* function it performs. > > **C. The Amendment Finds Support in the Specification** > > The added language finds support in: > - Paragraph [0025]: Network packet reception from packet capture interface > - Paragraph [0026]: Metadata extraction from packet headers > - Paragraph [0027]: Pattern matching against rule database > - Paragraph [0028]: Suspicious pattern identification > - Paragraph [0029]: Forwarding to alert generation system > - Figure 2: System architecture showing data processing module connections > > **D. The Amendment Does Not Narrow Claim Scope** > > The amendment clarifies the structural character of the data processing module without limiting the claim to a specific implementation. Any data processing module operating in the described manner falls within the claim scope. > > **E. Request for Reconsideration** > > In view of the amendments, Applicant respectfully requests reconsideration and withdrawal of the rejection under § 112(b). The amended claim recites sufficient structural detail to avoid § 112, ¶ 6 construction and is therefore not indefinite." #### 2. Strategy Two: Reference Specification Embodiments ##### a. The Approach Amend to incorporate structural details from specification embodiments while maintaining some flexibility through "as described" language. ##### b. Amendment Example **Original Claim**: > "5. The apparatus of claim 1, further comprising: a sorting module for arranging data elements." **Amended Claim**: > "5. The apparatus of claim 1, further comprising: a sorting module that arranges data elements using a divide-and-conquer approach wherein elements are partitioned around pivot values selected from the elements, partitions are recursively processed, and results are combined, as described in paragraphs [0042]-[0045] and illustrated in Figure 4." **Amendment Remarks**: > "**AMENDMENTS TO CLAIM 5** > > Claim 5 has been amended to incorporate structural details from the specification while maintaining claim breadth through 'as described' language. > > **A. The Amendment Incorporates Algorithmic Structure** > > The amended language describes: > - Algorithmic approach: Divide-and-conquer > - Partitioning methodology: Elements partitioned around pivot values > - Pivot selection: From the elements themselves > - Processing method: Recursive > - Result handling: Combination of processed partitions > > **B. Cross-Reference to Specification** > > The amendment includes explicit cross-reference to: > - Paragraphs [0042]-[0045]: Detailed algorithmic description > - Figure 4: Flowchart illustrating the sorting process > > This cross-reference creates clear linkage between the claim and the detailed disclosure. > > **C. Flexibility Through 'As Described' Language** > > The 'as described' language allows the claim to encompass variations and modifications disclosed in the specification, including: > - Different pivot selection strategies (paragraphs [0043]-[0044]) > - Hybrid approaches combining with other algorithms (paragraph [0045]) > - Optimization techniques (paragraph [0046]) > > **D. Request for Reconsideration** > > The amended claim incorporates structural detail sufficient to avoid § 112, ¶ 6 while maintaining appropriate claim breadth. Applicant respectfully requests withdrawal of the rejection." --- ## VI. Strategic Use of Means-Plus-Function Claims ### A. When MPF Claims Serve Strategic Purposes #### 1. Avoiding Prior Art ##### a. The Scenario Prior art discloses numerous structures that perform the claimed function, creating anticipation or obviousness issues for broadly-claimed structural claims. ##### b. The MPF Advantage Means-plus-function claims, limited to disclosed structures and equivalents, may avoid prior art by distinguishing the specific disclosed implementation from prior approaches. ##### c. Example **Prior Art Landscape**: - Reference A: Discloses bubble sort algorithm - Reference B: Discloses insertion sort algorithm - Reference C: Discloses selection sort algorithm - Reference D: Discloses merge sort algorithm - Reference E: Discloses heap sort algorithm **Structural Claim Challenge**: > "An apparatus comprising: a sorting processor." This broad structural claim likely reads on all prior art references, as each discloses a sorting processor. **MPF Claim Advantage**: > "An apparatus comprising: means for sorting data." If specification discloses only quicksort algorithm, claim is limited to quicksort (and equivalents). Prior art references A-E use different structures (bubble sort, insertion sort, etc.) and therefore do not anticipate. **Result**: MPF claim avoids prior art that structural claim cannot avoid. #### 2. Equivalents Coverage Through Doctrine of Equivalents ##### a. The Doctrine Means-plus-function claims cover not only disclosed structures but also equivalent structures—those performing substantially the same function in substantially the same way to achieve substantially the same result. ##### b. The Strategic Advantage This creates uncertainty for competitors regarding infringement, favoring patentees in negotiations and litigation. **Competitor's Analysis Burden**: 1. Identify all disclosed structures in specification 2. Determine if accused product uses identical structure (literal infringement) 3. If not identical, analyze whether accused structure is equivalent: - Same function? (Usually yes for functional claims) - Same way? (Requires detailed technical analysis) - Same result? (Usually yes if same function) 4. Requires expert analysis and testimony 5. Expensive, time-consuming, uncertain **Patentee's Advantage**: - Competitor cannot easily determine infringement risk - Uncertainty drives settlement discussions - Design-around requires both structural avoidance AND equivalents avoidance - Multiple theories of infringement available ### B. Claim Differentiation Benefits #### 1. Supporting Structural Interpretation Including explicit MPF claims supports structural interpretation of companion claims using generic terms. **Claim Set Example**: - Claims 1-9: "processing module that receives data, extracts information, validates fields, and routes results" - Claim 10: "means for receiving data; means for extracting information; means for validating fields; means for routing results" **Presumption**: Claims 1-9 intended as structural (different scope from Claim 10's MPF scope) **Benefit**: Claim differentiation doctrine supports Step 1 arguments that Claims 1-9 avoid § 112(f). #### 2. Providing Multiple Enforcement Options Different claim types enable different enforcement strategies: **Structural Claims**: - Broad literal scope - Cover implementations with additional features - May read on wide range of products **MPF Claims**: - Narrow literal scope (disclosed structures only) - But equivalents doctrine provides flexibility - May cover implementations avoiding structural language **Strategic Deployment**: - Assert structural claims against straightforward copies - Assert MPF claims against design-arounds using equivalent structures - Plead both claim types in litigation for maximum coverage ### C. Comprehensive Checklist Framework #### 1. Claim Drafting Checklist **For Each Claim Limitation**: □ Does limitation use "means" or generic term ("module," "unit," "component")? □ If generic term, does limitation describe HOW element operates? □ Are inputs specified (data type, source, format)? □ Are processing operations detailed (algorithms, sequence, conditions)? □ Are outputs specified (results, destination, format)? □ Is integration described (connections, data flow, control signals)? □ Does limitation avoid "for [verb]ing" functional format? □ Have I used structurally descriptive terms where accurate? □ Does specification provide detailed support for this limitation? #### 2. Specification Drafting Checklist **Algorithm Disclosure**: □ Have I disclosed specific algorithm for each functional element? □ Is algorithm disclosed through flowchart, pseudocode, or detailed prose? □ Does disclosure include sufficient detail for implementation? □ Have I disclosed multiple embodiments where appropriate? **Linkage**: □ Is each algorithm clearly linked to its corresponding claimed function? □ Have I used consistent terminology between claims and specification? □ Are cross-references to figures and paragraphs included? □ Is the connection between function and structure explicit? **General-Purpose Computer Avoidance**: □ Have I avoided mere "computer" or "processor" references? □ Does disclosure explain HOW computer performs each function? □ Are specific algorithms, not just hardware, disclosed? □ Have I shown transformation from general to special-purpose computer? **Organization**: □ Does specification include clear sections for overview, detailed description, and algorithms? □ Are all components described with operational detail? □ Is system architecture clearly illustrated in figures? □ Are alternative embodiments disclosed? #### 3. Prosecution Response Checklist **When Examiner Improperly Invokes § 112(f)**: **Step 1 Arguments (Primary)**: □ Have I pointed to the complete claim phrase (not just the term)? □ Have I explained software structure principles from *Apple*? □ Have I demonstrated operational context (inputs, outputs, processing, integration)? □ Have I cited claim differentiation if applicable? □ Have I provided declaration evidence if necessary? **Step 2 Arguments (Fallback)**: □ Have I identified specific disclosed algorithms? □ Have I demonstrated clear linkage to claimed functions? □ Have I addressed general-purpose computer issues? □ Have I shown adequate detail for implementation? **Amendment Strategies**: □ Have I considered adding operational detail to claims? □ Have I evaluated referencing specification embodiments? □ Have I assessed impact on claim scope? □ Have I drafted remarks supporting structural interpretation? --- ## VII. Conclusion ### A. Summary of Key Principles Managing § 112(b) and § 112(f) issues in software patents requires systematic application of established principles: **First: Understanding the Framework** 1. The statutory basis for means-plus-function claiming 2. The two-step analysis for determining § 112(f) application 3. Software-specific structural requirements (algorithms, not general-purpose computers) 4. The distinction between apparatus and method claims **Second: Ensuring Compliance** 1. Algorithm disclosure for all computer-implemented means-plus-function claims 2. Clear linkage between algorithms and functions 3. Adequate disclosure detail (flowcharts, pseudocode, prose, or combinations) 4. Avoidance of general-purpose computer trap **Third: Preventing Unintended Invocation** 1. Structure must be in claim term itself (read with specification) 2. Describe inputs, outputs, processing, integration 3. Avoid pure functional language ("for [verb]ing") 4. Use structurally descriptive terms where accurate 5. Provide comprehensive specification support **Fourth: Responding to Improper USPTO Actions** 1. Emphasize complete claim phrase analysis 2. Reference software structure principles 3. Demonstrate operational context 4. Use claim differentiation when applicable 5. Provide specification support arguments as fallback 6. Amend strategically when necessary **Fifth: Strategic MPF Use** 1. Claim differentiation supports structural claims 2. Equivalents provide future-proofing and negotiation leverage 3. Portfolio diversification maximizes protection 4. Different claim types serve different enforcement strategies ### B. Comprehensive Master Checklist #### I. Claim Drafting **A. Structural Character Assessment** For each limitation: 1. □ Term selection evaluated (generic vs. structurally descriptive) 2. □ Inputs specified with sources and formats 3. □ Processing operations detailed with algorithms/sequence 4. □ Outputs specified with destinations and formats 5. □ Integration described (connections, data flow, signals) 6. □ "For [verb]ing" format avoided 7. □ Operational detail sufficient to describe "how" not just "what" 8. □ Specification support verified **B. Claim Set Diversity** 1. □ Method claims included (using active verbs) 2. □ Structural apparatus claims included (with operational detail) 3. □ Explicit MPF claims considered (for claim differentiation) 4. □ Dependent claims add structural detail 5. □ Hybrid claims evaluated (structural + MPF mix) #### II. Specification Drafting **A. Algorithm Disclosure** For each functional element: 1. □ Specific algorithm identified 2. □ Form selected (flowchart, pseudocode, prose, formula, or combination) 3. □ Detail sufficient for implementation 4. □ All parameters and ranges specified 5. □ Decision criteria and thresholds provided 6. □ Edge cases and error handling described 7. □ Multiple embodiments disclosed where appropriate **B. Linkage Requirements** 1. □ Explicit linkage statements included 2. □ Consistent terminology used throughout 3. □ Contextual organization supports connection 4. □ Figure cross-references provided 5. □ Each function linked to corresponding structure **C. Organization** 1. □ System overview section included 2. □ Component descriptions with operational detail 3. □ Algorithm section with detailed disclosures 4. □ Alternative embodiments section 5. □ Implementation details provided 6. □ Clear section headings and structure **D. General-Purpose Computer Avoidance** 1. □ Specific algorithms disclosed (not just "computer") 2. □ Transformation from general to special-purpose explained 3. □ Data structures specified 4. □ Processing steps detailed 5. □ Integration and data flow described #### III. Prosecution **A. Office Action Analysis** When § 112(f) invoked: 1. □ Identified whether invocation is proper 2. □ Evaluated complete claim phrase 3. □ Assessed operational detail in claims 4. □ Reviewed specification support 5. □ Determined response strategy (structural vs. spec support) **B. Structural Arguments (Step 1)** 1. □ Complete claim phrase analyzed 2. □ Software structure principles cited (*Apple*, *Williamson*) 3. □ Operational context demonstrated 4. □ Claim differentiation argued (if applicable) 5. □ Declaration evidence considered **C. Specification Support Arguments (Step 2)** 1. □ Disclosed algorithms identified 2. □ Linkage demonstrated 3. □ General-purpose computer issues addressed 4. □ Adequate detail shown **D. Amendment Strategy** 1. □ Operational detail addition considered 2. □ Specification embodiment references evaluated 3. □ Claim scope impact assessed 4. □ Prosecution history implications considered 5. □ Remarks drafted supporting structural interpretation #### IV. Strategic Considerations **A. Portfolio Architecture** 1. □ Multiple claim types included 2. □ Claim differentiation established 3. □ Breadth vs. validity balanced 4. □ Future amendment options preserved 5. □ Enforcement flexibility maintained **B. MPF Strategic Use** 1. □ Prior art avoidance evaluated 2. □ Equivalents coverage considered 3. □ Negotiation leverage assessed 4. □ Future-proofing potential evaluated 5. □ Litigation positioning considered ### C. Final Recommendations **1. Always Disclose Algorithms** Even when not strictly required (e.g., for structural claims avoiding § 112(f)), algorithmic disclosure: - Supports structural interpretation - Provides MPF fallback - Satisfies enablement - Avoids indefiniteness - Creates prosecution flexibility **Best Practice**: Disclose specific algorithms for all computer-implemented functions, regardless of claim format. **2. Describe the "How"** Claims and specifications should consistently describe: - How elements operate (not just what they accomplish) - How functions are achieved (specific mechanisms) - How components integrate (system architecture) - How data flows (input to output paths) **Best Practice**: Every functional element should have corresponding operational description. **3. Use Claim Differentiation** Include multiple claim types in each application: - Structural claims with operational detail - Method claims with active verbs - Explicit MPF claims for differentiation - Hybrid approaches for flexibility **Best Practice**: Draft comprehensive claim sets covering multiple protection strategies. **4. Maintain Dual-Purpose Specifications** Draft specifications to support both: - Structural interpretation (Step 1 avoidance) - MPF interpretation (Step 2 compliance) **Best Practice**: Provide both operational context AND algorithmic disclosure for all elements. **5. Strategic MPF Deployment** Consider MPF claims for: - Avoiding dense prior art - Obtaining equivalents coverage - Creating claim differentiation - Future-proofing against technology evolution - Maximizing negotiation leverage **Best Practice**: Include at least one explicit MPF independent claim in each application for strategic flexibility. ### D. The Bottom Line Software patent prosecution requires navigating the intersection of § 112(b) definiteness and § 112(f) means-plus-function claiming with systematic attention to detail. **Success Depends On**: 1. **Understanding** the legal framework, case law development, and software-specific requirements 2. **Drafting** claims with operational detail and specifications with algorithmic disclosure and clear linkage 3. **Responding** effectively to improper examiner constructions while preserving claim scope and avoiding prosecution history issues 4. **Strategizing** using claim differentiation and MPF claims for maximum protection and enforcement flexibility **The Systematic Approach Yields**: - Compliant claims surviving examination and litigation - Specifications enabling both structural and MPF interpretations - Comprehensive protection through diversified claim portfolios - Strategic advantages in prosecution, licensing, and enforcement By following this comprehensive framework systematically—from initial claim drafting through examination responses to final allowance—practitioners can draft compliant applications, respond effectively to rejections, and strategically leverage both structural and means-plus-function claims to maximize patent value and enforcement options. --- ## VIII. Table of Key Cases | Case | Citation | Holding | Key Principle | |------|----------|---------|---------------| | *Williamson v. Citrix Online, LLC* | 792 F.3d 1339 (Fed. Cir. 2015) (en banc) | "Distributed learning control module" invoked § 112(f) | Standard is whether term has "sufficiently definite meaning as the name for structure"; eliminated "strong presumption" language | | *Apple Inc. v. Motorola, Inc.* | 757 F.3d 1286 (Fed. Cir. 2014) | "Heuristic" had sufficient structure | Structure requires describing "how" (operation, inputs, outputs, connections), not just "what"; software structure understood through algorithms, flowcharts, operational descriptions | | *Aristocrat Techs. Australia v. Int'l Game Tech.* | 521 F.3d 1328 (Fed. Cir. 2008) | Software MPF requires specific algorithm | General-purpose computer insufficient; corresponding structure must be specific algorithm | | *Nautilus, Inc. v. Biosig Instruments, Inc.* | 572 U.S. 898 (2014) | Definiteness standard | Claims must inform skilled artisans about scope "with reasonable certainty" | | *Noah Systems, Inc. v. Intuit Inc.* | 675 F.3d 1302 (Fed. Cir. 2012) | Linkage requirement | Structure must be clearly linked to function; mere disclosure elsewhere insufficient | | *In re Katz* | 639 F.3d 1303 (Fed. Cir. 2011) | Narrow exception for standard functions | General-purpose computer may suffice for truly standard functions (processing, receiving, storing) | | *O.I. Corp. v. Tekmar Co.* | 115 F.3d 1576 (Fed. Cir. 1997) | Method claims framework | § 112(f) applies only to "step[s] for" without acts; "-ing" verbs describe acts, not functions | | *Advanced Ground Info. Sys. v. Life360* | 830 F.3d 1341 (Fed. Cir. 2016) | "Symbol generator" indefinite | Must disclose algorithm transforming general-purpose computer to special-purpose device | | *Lighting World v. Birchwood Lighting* | 382 F.3d 1354 (Fed. Cir. 2004) | Presumption framework | When "means" absent, presumption arises against § 112(f); party asserting bears burden | | *Joao Control & Monitoring Sys. v. Protect Am.* | No. 1-14-CV-134-LY (W.D. Tex. 2015) | Complete phrase analysis | Court examines "entire claim phrase," not just introductory term | | *Kraft Foods v. Int'l Trading Co.* | 203 F.3d 1362 (Fed. Cir. 2000) | Claim differentiation | Presumption that different claims have different scope |