Doctrine of Equivalents in Software

The doctrine of equivalents extends literal claim scope to capture implementations that are substantially equivalent to the claimed invention: GENERAL DOE STANDARD: an accused product infringes under the doctrine of equivalents if it: performs substantially the same FUNCTION in substantially the same WAY to achieve substantially the same RESULT as the claimed invention (triple-identity or function-way-result test); OR the differences between the accused product and the claim are insubstantial; SOFTWARE DOE CHALLENGES — FUNCTION: software claims are often written in functional terms (e.g., 'a module configured to classify inputs'); the function element is easy for the accused product to meet — different code achieving the same function; the WAY element becomes critical: does the accused product achieve the function in substantially the same way as the claimed invention?; SOFTWARE DOE CHALLENGES — WAY: in software, the 'way' may be interpreted as the algorithm, data structure, or process used; if the claim uses Algorithm A and the accused product uses Algorithm B that achieves the same result, is the 'way' substantially the same?; EXAMPLE: claim requires 'generating a hash value using MD5'; accused product uses SHA-256; both are cryptographic hash functions achieving the same result (data integrity verification) but by a different way; DOE may apply if the algorithmic difference is insubstantial; PROSECUTION HISTORY ESTOPPEL: if the applicant amended claims during prosecution to add the specific algorithm (e.g., to overcome a prior art rejection), estoppel bars DOE claims for surrendered subject matter; ALL-LIMITATIONS RULE: each element of the claim must find a corresponding equivalent in the accused product — DOE cannot effectively read out a claim limitation entirely.

The 'way' element in the function-way-result test is frequently the battleground in software DOE litigation: DIFFERENT ALGORITHMIC APPROACHES: many programming problems have multiple algorithmic solutions (e.g., sorting algorithms, search algorithms, encryption schemes, data structures); when the accused product uses a completely different algorithm that happens to achieve the same result, the 'way' question becomes complex; EXAMPLE — SORTING: claim requires 'sorting data using a bubble sort algorithm'; accused product uses quicksort; both sort data (function) to the same result (sorted array); is the way substantially the same? No — bubble sort and quicksort are fundamentally different algorithms with different computational complexity, different implementations, and different performance characteristics; FUNCTIONAL CLAIMING AMBIGUITY: broadly functional software claims may have such a vague 'way' that almost any implementation of the function qualifies; this is why the all-limitations rule and prosecution history estoppel are especially important in software; ALGORITHMIC ABSTRACTION LEVEL: at a high level of abstraction, all sorting algorithms 'compare and rearrange elements' — the same way; at a low level, bubble sort and merge sort are completely different; the appropriate level of abstraction for the 'way' analysis is unsettled in software; WABASH NATIONAL CORP. v. BODYGUARD PRODUCTS (Fed. Cir. 2001) approach: courts look at whether the modification results in 'a changed role' for the corresponding element — if the different code plays the same structural and functional role in the accused product as in the claim, equivalence may be found; SPECIFIC VS. FUNCTIONAL CLAIMS: narrowly specified algorithmic claims create a clear 'way' (the specific algorithm) that is either matched or not; broadly functional claims make the 'way' analysis nearly meaningless.

Prosecution history estoppel is a major limitation on DOE in software cases, particularly given the frequent claim narrowing during examination: FESTO RULE: Festo Corp. v. Shoketsu Kinzoku Kogyo Kabushiki (S.Ct. 2002): any narrowing amendment made for a substantial reason related to patentability presumptively surrenders the full scope of subject matter between the original and amended claim; PRESUMPTION: the surrender is presumed to be complete (a 'complete bar'); the patent owner bears the burden of rebutting the presumption by showing: (a) the equivalent was unforeseeable at the time of the amendment; (b) the rationale for the amendment bears no more than a tangential relation to the equivalent; (c) there is 'some other reason' why the patentee could not have described the equivalent; SOFTWARE DOE AND FESTO: software patent prosecution frequently involves claim narrowing to overcome § 101 Alice rejections, § 103 obviousness rejections, or § 112 indefiniteness rejections; when narrowing adds specific algorithmic limitations to overcome prior art, the applicant surrenders the scope of equivalent algorithms; EXAMPLE: original claim: 'a system configured to process data'; amended to add 'using a neural network' to overcome a § 103 rejection citing a decision tree system; post-amendment, DOE is limited — the patent owner cannot recapture the decision tree system under DOE because the amendment surrendered that equivalent; TANGENTIAL RELATION EXCEPTION: if the claim was narrowed to address an issue unrelated to the specific equivalence claimed, the surrender may not apply; PROSECUTION STRATEGY: in software prosecution, avoid unnecessary narrowing amendments; if you must narrow, consider the DOE implications and whether the amendment surrenders important equivalents.

Software's multi-implementation nature raises specific DOE questions about language, platform, and architecture variations: PROGRAMMING LANGUAGE: if a claim does not specify a programming language, the claim likely covers all languages by literal infringement (language-neutral); DOE is not needed; if a claim specifies Python and accused product uses Java, DOE analysis applies — the function and result are identical; the way (Python vs. Java) involves the same algorithmic approach; likely the same way for most purposes; PLATFORMS AND OPERATING SYSTEMS: implementations across different OS (Windows vs. Linux), mobile platforms (iOS vs. Android), or processor architectures (x86 vs. ARM) typically achieve the same result by the same way; platform-specific implementation differences are usually insubstantial for DOE purposes; DIFFERENT ARCHITECTURE (MONOLITH vs. MICROSERVICES): an application may be implemented as a monolithic application or as microservices; for DOE, if the microservices collectively perform the same functions by the same methods, architectural decomposition typically does not create a substantial difference; HARDWARE vs. SOFTWARE IMPLEMENTATIONS: a claim for a software-implemented function may capture a hardware implementation under DOE; Miller v. Bridgeport Machines (Fed. Cir. 1985) and subsequent cases have found hardware and software equivalents; however, if the claim specifically requires a 'software module' or 'computer-executable instructions,' the hardware may not be equivalent; CLOUD vs. ON-PREMISE: a claimed on-premise system may capture a cloud implementation under DOE if the cloud architecture performs the same functions in the same way; jurisdictional issues arise when the cloud components are distributed across locations.

Defendants use several strategies to defeat DOE infringement claims in software patent litigation: STRATEGY 1 — ATTACK 'WAY' ELEMENT: argue the accused product uses a fundamentally different algorithm, data structure, or computational approach; expert testimony identifying the specific algorithmic differences; software engineers explaining why the different implementation is not 'substantially the same way'; STRATEGY 2 — PROSECUTION HISTORY ESTOPPEL: research the patent's file history for narrowing amendments during prosecution; identify § 103, § 101, or § 112 rejections that prompted narrowing of algorithmic claims; argue those amendments surrendered the equivalence claimed; STRATEGY 3 — ALL-LIMITATIONS RULE: argue the DOE argument would read out an entire claim limitation; if the plaintiff's DOE argument effectively ignores one claim element (finding no equivalent), the argument fails under the all-limitations rule; STRATEGY 4 — CLAIM VITIATION: argue that accepting the equivalent as 'substantially the same' would vitiate a claim limitation — reduce it to meaninglessness; if the claimed 'neural network' limitation would be satisfied by any data processing system, the limitation is vitiated; STRATEGY 5 — REVERSE DOE: argue the accused product is so fundamentally different in principle that literal infringement, even if technically satisfied, should not be found (rare in software); STRATEGY 6 — § 112(f) MEANS-PLUS-FUNCTION: if the claim uses means-plus-function language, the claim is limited to the structure disclosed in the specification and equivalents; software MPF claims are limited to the algorithm disclosed and structurally equivalent algorithms — this is narrower than DOE analysis outside MPF.