More details: In an earlier post (here), I discussed the claim construction opinion for this same infringement suit. Several independent claims included "circuitry" elements: "call progress detector circuitry for detecting [a first or second call waiting signal];" and "circuitry to recognize a first signal [indicative of the first or second call waiting signal." As noted in my earlier post, the District Court construed the term "circuitry" in both elements to include software-based implementations, i.e., a processor performing the claimed function.
The accused device ("Catch-a-Call") implemented both the detecting and the recognizing functions with code executing on a processor. On Summary Judgment, the court found that the Catch-a-Call did not literally infringe because it "uses a single element - an Atmel brand microprocessor running a software program developed by [the manufacturer defendant] ... while the [patent in suit] claims two discrete elements to accomplish these functions."
The court further explained that this situation does not preclude a finding of infringement through the doctrine of equivalents, citing to Eagle Comtronics, Inc. v. Arrow Comm'n Lab's, 305 F.3d 1030, 1317 (Fed. Cir.2002). However, in this particular case the Plaintiff only asserted doctrine of equivalents for one of the disputed means, and did not even develop particularized evidence during discovery with respect to the other.
My two cents: Using one element instead of two to perform a function is precisely why we have the Doctrine of Equivalents. I'm no expert on the function-way-result test, but my gut feeling is that an accused infringer using one processor instead of two would be covered by Doctrine of Equivalents. I have no idea why the patentee did not pursue a Doctrine of Equivalents theory.
That said, I'm not so sure the one-is-different-than-two rule from Unique Concepts is appropriate in the software context. The reasoning used by Unique Concepts was that A and B must be construed differently than A and A, because otherwise reciting both types (A and B) is redundant. That makes sense when A and B are "linear border piece" and "right angle piece" — A and B really are different. But I think Kernius is really a case of A ("circuitry") and A ("circuitry"), not A ("circuitry for X") and B ("circuitry for Y").
Under Kernius, do you need five claim permutations to get literal coverage of a software implementation of functions A, B, and C?
- first processor doing A, B, and C;
- first processor doing A and B and second processor doing C;
- first processor doing A and second processor doing B and C;
- first processor doing A and C and second processor doing B;
- first processor doing A, second processor doing B, and third processor doing C;