Summary
striking untimely expert declaration, rejecting argument that the local patent rules do not require disclosure of a rebuttal expert, and rejecting argument that opposing party's noncompliance with the rules justified untimely disclosure
Summary of this case from Dynatemp Int'l v. R421A, LLCOpinion
Case No.17-cv-07179-HSG
04-16-2019
IPSILIUM LLC, Plaintiff, v. CISCO SYSTEMS, INC., Defendant.
CLAIM CONSTRUCTION ORDER AND ORDER GRANTING MOTION TO STRIKE
Re: Dkt. No. 53
On December 18, 2017, Plaintiff Ipsilium LLC ("Ipsilium") filed this patent infringement action against Defendant Cisco Systems, Inc. ("Cisco"). Dkt. No. 1. Ipsilium subsequently filed an amended complaint. Dkt. No. 15. The parties now seek construction of eight terms found in two patents: Patent Nos. 6,819,681 ("the '681 Patent") and 6,961,777 ("the '777 Patent") (collectively, "the Asserted Patents"). See Dkt. No. 75-1 ("Am. JCCS"). This order follows claim construction briefing, a technology tutorial, and a claim construction hearing ("Markman hearing"). See Dkt. Nos. 52 ("Op. Br."), 54 ("Resp. Br."), 55 ("Reply Br."), 69 ("Markman Tr."). At the Markman hearing, the Court instructed the parties to submit supplemental briefing, which the parties timely provided. See Markman Tr. 104:11-16; see also Dkt. Nos. 73 ("Pl.'s Supp. Br."), 74 ("Def.'s Supp. Br.").
The parties initially also sought construction of "means for determining a first value of the obtained field" from claim 16 of the '681 Patent and "means for determining the value of the obtained field" in claim 16 of the '777 Patent. The parties have since stipulated that the limitation has a function of "determining a first value of the obtained field" with a structure of "a processor or microprocessor executing instructions, hardwired circuitry, or silicon via combination of logic gates." See Resp. Br. at 7 n.1. Given this agreement, the Court adopts the parties' stipulated construction.
Also pending before the Court is Cisco's motion to strike the declaration of Ipsilium's expert, Dr. Daniel A. Menascé, briefing for which is also complete. Dkt. Nos. 53 ("Mot."), 57 ("Opp."), 62 ("Reply"). This order turns first to the motion to strike, because its resolution will determine whether the Court will consider Dr. Menascé's declaration in construing the disputed claims.
I. MOTION TO STRIKE
On August 15, 2018, the parties exchanged preliminary claim constructions, as required by this Court's June 29, 2018 scheduling order. See Dkt. No. 46 (setting deadline); Dkt. No. 53-3 (Cisco's Preliminary Claim Constructions); Dkt. No. 53-4 (Ipsilium's Preliminary Claim Constructions). Cisco's August 15 disclosure provided that it "may rely on the expert testimony of Dr. Kevin Almeroth" for various subjects. See Dkt. No. 53-3 at 3. Ipsilium's August 15 disclosure provided the following concerning expert testimony:
Further, Ipsilium does not believe that expert testimony is necessary for the court to understand the meaning of the claims. See Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1584 (Fed. Cir. 1996 (Reliance on expert testimony is unnecessary and improper "when the disputed terms can be understood from a careful reading for the public record.")[.] To the extent Cisco proposes to rely on any such expert testimony, Ipsilium reserves the right to offer rebuttal testimony from its expert(s).Dkt. No. 53-4.
As also required by this Court's scheduling order, the parties filed a Joint Claim Construction and Prehearing Statement on August 30, 2018. See Dkt. No. 46 (setting deadline); Dkt. No. 51 ("JCCS"). The JCCS provided the following regarding extrinsic evidence supporting the parties' proposed constructions of disputed terms:
A declaration from Cisco's expert, Dr. Kevin Almeroth is attached as Exhibit B. Ipsilium does not believe that expert testimony is necessary to construe the disputed terms but reserves the right to provide rebuttal testimony from its expert.
. . .
[In a corresponding footnote:] Any expert testimony, including declarations, on which Ipsilium intends to rely is due concurrently with this statement, per [Patent Local Rule] 4-3, and Cisco will oppose any attempt to rely on improper and out of time expert rebuttal testimony, which is not contemplated or permitted by the rules. Indeed, to avoid precisely this situation, counsel for Cisco specifically
confirmed the deadline to counsel for Ipsilium via email on August 10, 2018.JCCS at 2 & n.1. Cisco filed its expert declaration and served it on Ipsilium the same day. See JCCS Ex. B. Nearly three weeks later, Ipsilium filed its opening claim construction brief. See Dkt. No. 52. With it, Ipsilium included a declaration from its expert, Dr. Daniel A. Menascé. See Dkt. No. 52-1.
Pursuant to the Court's June 29, 2018 order, claim construction discovery closed on September 7, 2018—eleven days before Ipsilium disclosed the identity and opinions of its expert. See Dkt. No. 46. Cisco now moves to exclude Dr. Menascé's expert report as violative of Patent Local Rules 4-2 and 4-3.
A. Legal Standard
Federal Rule of Civil Procedure 37(c)(1) provides: "If a party fails to provide information or identify a witness as required by Rule 26(a) or (e), the party is not allowed to use that information or witness to supply evidence on a motion, at a hearing, or at a trial, unless the failure was substantially justified or is harmless." In addition, or instead, the court may also impose other appropriate sanctions provided for in Rule 37. See Fed. R. Civ. P. 37(c)(1)(A)-(C). "The party facing sanctions bears the burden of proving that its failure to disclose the required information was substantially justified or is harmless." R & R Sails, Inc. v. Ins. Co. of Pa., 673 F.3d 1240, 1246 (9th Cir. 2012).
Rule 37(c)(1) "gives teeth" to Rule 26's disclosure and supplementation requirements, including the requirement that parties disclose expert reports "at the times and in the sequence that the court orders." Yeti by Molly, Ltd. v. Deckers Outdoor Corp., 259 F.3d 1101, 1106 (9th Cir. 2001); Fed. R. Civ. P. 26(a)(2)(D). The Advisory Committee Notes to the 1993 amendments to Rule 37 describe subsection (c)(1) as a "self-executing," "automatic sanction [that] provides a strong inducement for disclosure of material" that must be disclosed pursuant to Rule 26. Rule 37(c)(1) sanctions based on failure to disclose evidence in a timely manner may be appropriate "even when a litigant's entire cause of action or defense" will be precluded. Yeti, 259 F.3d at 1106.
B. Discussion
Under the Court's scheduling order, the parties were required to exchange preliminary claim constructions on August 15, 2018, and to file the JCCS by August 30, 2019. Dkt. No. 46. As to the exchange of preliminary claim constructions, Patent Local Rule 4-2 provides that "[a]t the same time the parties exchange their respective 'Preliminary Claim Constructions,' each party shall . . . designate any supporting extrinsic evidence including . . . expert witnesses." Patent L.R. 4-2(b). As to the JCCS, Patent Local Rule 4-3 provides that the JCCS "shall contain . . . an identification of any extrinsic evidence known to the party on which it intends to rely either to support its proposed construction or to oppose any other party's proposed construction, including . . . expert witnesses." Patent L.R. 4-3(b).
Cisco now urges the Court to exclude Dr. Menascé's declaration due to Ipsilium's failure to comply with these local rules. Ipsilium opposes this request on several grounds. First, Ipsilium hopes to turn the tables and argue that Cisco is the party who has not followed the local rules. For example, Ipsilium claims that in the August 15 disclosures, Cisco raised several indefiniteness allegations for the first time, which purportedly "forc[ed] Ipsilium to address those elements for the first time in its Opening Claim Construction Brief." Opp. at 3. According to Ipsilium, Cisco's evasive tactics violated the local rules requirement to provide detailed disclosure of invalidity contentions. Id. at 4. But Ipsilium admits that it took no action in response to Cisco's allegedly deficient disclosures: "Rather than engage in time-consuming motion practice as to Cisco's insufficient invalidity disclosures, Ipsilium preferred to resolve this issue on the merits." Id.
The Court rejects Ipsilium's allegation of hypocrisy as irrelevant to the pending motion. First, Cisco's compliance, or noncompliance, with the local rules has nothing to do with Ipsilium's tactics. Second, and more important, even if Cisco's August 15 disclosure surprised Ipsilium, at most that might have justified Ipsilium's failure to disclose Dr. Menascé in its own August 15 disclosure, as required by Patent Local Rule 4-2. But that does not explain why Ipsilium failed to disclose Dr. Menascé in the JCCS, as required by Patent Local Rule 4-3, which the parties filed over two weeks later.
Ipsilium next argues that Dr. Menascé's report is only meant to rebut opinions offered by Cisco's expert, Dr. Almeroth. Id. at 4. And Ipsilium contends that Patent Local Rule 4-3 does not require disclosure of a rebuttal expert. Id. But Ipsilium's interpretation of the rule is incorrect: Patent Local Rule 4-3 plainly requires the disclosure of expert testimony "on which [the party] intends to rely either to support its proposed construction or to oppose any other party's proposed construction." Patent L.R. 4-3(b) (emphasis added).
Ipsilium separately argues that due process demands Ipsilium be "afforded the opportunity to see the evidence presented against it and prepare a response." Id. at 5-6. But Ipsilium fails to cite any binding authority to suggest that compliance with the Patent Local Rules somehow deprives parties of their due process rights. And to the extent Ipsilium's position is that compliance with the Patent Local Rules violates its due process rights, the Court rejects that argument.
Finally, Ipsilium asks the Court to deny the motion because Cisco failed to meet and confer before submitting the motion, as required by Local Rule 37-1. Ipsilium argues that, in violation of that rule, "Cisco did not raise any objection to [Dr. Menascé's] declaration for two weeks." Id. at 5. Rather, Cisco told Ipsilium it intended to file the present motion the same day it in fact filed the motion, when Ipsilium's lead counsel was busy. Id. In response, Cisco notes that it provided Ipsilium with ample warning of the present motion in the JCCS, where it said in plain terms that Cisco would oppose untimely expert disclosure. See Dkt. No. 51 at 2 n.1. Moreover, Ipsilium's failure to respond to Cisco's email the day Cisco filed this motion does not mean Cisco did not attempt to meet and confer.
Because Ipsilium failed to comply with a court order requiring the disclosure of expert testimony by a certain date, the Court cannot consider Dr. Menascé's declaration absent "substantial justification" or a showing of harmlessness. See Fed. R. Civ. Proc. 37(c)(1); Jarritos, Inc. v. Reyes, 345 F. App'x 215, 217 (9th Cir. 2009) (affirming exclusion of late-filed expert reports); Yeti, 259 F.3d at 1106. The burden of showing substantial justification or harmlessness falls on Ipsilium. See R & R Sails, Inc., 673 F.3d at 1246. But for the reasons set forth above, the Court finds that Ipsilium's conduct was not substantially justified, as it knowingly violated the Patent Local Rules. The Court also finds that Ipsilium's delay in filing Dr. Menascé's declaration was not harmless. Ipsilium's disclosure came after the close of claim construction discovery, and "[d]isruption to the schedule of the court and other parties . . . is not harmless." Wong v. Regents of Univ. of Cal., 410 F.3d 1052, 1062 (9th Cir. 2005).
For these reasons, the Court GRANTS Cisco's motion to strike.
II. CLAIM CONSTRUCTION
A. Legal Standard
Claim construction is a question of law to be determined by the Court. Markman v. Westview Instruments, Inc., 517 U.S. 370, 384 (1996). "The purpose of claim construction is to determine the meaning and scope of the patent claims asserted to be infringed." O2 Micro Int'l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351, 1360 (Fed. Cir. 2008) (quotation omitted).
Generally, claim terms should be "given their ordinary and customary meaning"—in other words, "the meaning that the term[s] would have to a person of ordinary skill in the art in question at the time of the invention." Phillips v. AWH Corp., 415 F.3d 1303, 1312-13 (Fed. Cir. 2005) (en banc) (quotation omitted). There are only two circumstances where a claim is not entitled to its plain and ordinary meaning: "1) when a patentee sets out a definition and acts as his own lexicographer, or 2) when the patentee disavows the full scope of a claim term either in the specification or during prosecution." Thorner v. Sony Comput. Entm't Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012).
When construing claim terms, the Federal Circuit emphasizes the importance of intrinsic evidence such as the language of the claims themselves, the specification, and the prosecution history. Phillips, 415 F.3d at 1312-17. The claim language can "provide substantial guidance as to the meaning of particular claim terms," both through the context in which the claim terms are used and by considering other claims in the same patent. Id. at 1314. The specification is likewise a crucial source of information. Id. at 1315-17. Although it is improper to read limitations from the specification into the claims, the specification is "the single best guide to the meaning of a disputed term." Id. at 1315 (noting that "the specification is always highly relevant to the claim construction analysis," and that "[u]sually, it is dispositive" (quotation omitted)); see also Merck & Co. v. Teva Pharm. USA, Inc., 347 F.3d 1367, 1371 (Fed. Cir. 2003) (explaining that "claims must be construed so as to be consistent with the specification").
Despite the importance of intrinsic evidence, courts may also consider extrinsic evidence— technical dictionaries, learned treatises, expert and inventor testimony, and the like—to help construe the claims. Phillips, 415 F.3d at 1317-18. For example, dictionaries may reveal what the ordinary and customary meaning of a term would have been to a person of ordinary skill in the art at the time of the invention. Frans Nooren Afdichtingssystemen B.V. v. Stopaq Amcorr Inc., 744 F.3d 715, 722 (Fed. Cir. 2014) ("Terms generally carry their ordinary and customary meaning in the relevant field at the relevant time, as shown by reliable sources such as dictionaries, but they always must be understood in the context of the whole document—in particular, the specification (along with the prosecution history, if pertinent)."). Expert testimony can also help "to ensure that the court's understanding of the technical aspects of the patent is consistent with that of a person of skill in the art, or to establish that a particular term in the patent or the prior art has a particular meaning in the pertinent field." Phillips, 415 F.3d at 1318. Extrinsic evidence is, however, "less significant than the intrinsic record in determining the legally operative meaning of claim language." Id. at 1317 (quotation omitted).
B. Disputed Terms
1. "reply packet" ('681 Patent and '777 Patent)
| Ipsilium's Construction | Cisco's Construction |
|---|---|
| "a packet in response to a received packet" | Plain and Ordinary Meaning (Noconstruction necessary)To the extent the Court determines that aconstruction is required, the plain andordinary meaning of "reply packet" is "aresponsive packet that is not a forward" |
The Court finds no construction is necessary, but that the plain and ordinary meaning is not limited to packets directed back to the originator of the received fields.
This disputed term appears in independent claims 2, 18, 31, 44, 49, 54, and 55 of the '681 Patent, as well as independent claims 44, 49, 54, and 55 and dependent claims 2, 18, and 31 of the '777 Patent. Am. JCCS at 1-2. Claim 54 of the '681 Patent is representative of how the term is used in the claim language: // //
| Claim 54 |
|---|
| 54. A computer-readable medium that stores instructions executable by one or moreprocessors to perform a method for generating responses to packets having a plurality offields, the packets being broken into one or more packets, before the packets are entirelyreceived, the method comprising:receiving one or more fields of the packet;predicting one or more other fields of the packet before the one or more other fields arereceived; andgenerating a reply packet based on the one or more received fields and the predicted oneor more other fields. |
Ipsilium has consistently asked the Court to construe "reply packet" as "a packet in response to a received packet." Op. Br. at 6-9; Reply Br. 1-3; Am. JCCS at 1. Cisco, on the other hand, has advanced several positions. Initially, Cisco proposed that "reply packet" ought to mean "[r]esponsive packet directed to received field's source." See JCCS Ex. A, at 1. In its opposition brief, however, Cisco retreated from its first proposal and argued that although it "initially proposed [in the JCCS] that 'reply packet' be construed as 'responsive packet directed to received field's source,' which is consistent with the term's plain and ordinary meaning," Cisco since determined that no construction is necessary and that the Court should give "reply packet" its plain and ordinary meaning. Resp. Br. 3-6. Cisco purportedly changed course "in the interest of streamlining this dispute." Id. at 3.
At the Markman hearing, the parties' dispute over this term crystalized at last: The parties disagree about where a reply packet may be sent and still qualify as a "reply." Cisco argues that a "reply packet" cannot mean a packet that is forwarded. Markman Tr. 56:17-20 ("I believe -- I guess one way to phrase it would be that 'a reply excludes a forward.' 'A reply packet is a -- a responsive packet that is not a forward' or something to that effect."); see also Am. JCCS at 1 (setting forth Cisco's current proposed construction). Ipsilium, on the other hand, continues to argue that a "reply packet" may be directed at the source of the received field or to other communication devices. Markman Tr. 52:7-9 ("In other instances, most instances, an incoming packet is forwarded to another destination, another device, that is -- or is closer to its ultimate -- the packet's ultimate destination.").
The Court finds that Cisco's newest position—that no construction is necessary and the plain and ordinary meaning of a "reply packet" is "a responsive packet that is not a forward"—is no more than a repackaging of Cisco's initial proposal—that a "reply packet" is a "responsive packet directed to received field's source." Broadly speaking, the claimed invention encompasses a method for receiving information, generating a "reply packet," and transmitting the "reply packet" to its destination. As a matter of logic, the "reply packet" can only be transmitted to one of two places: (1) back to the originator of the received information, or (2) somewhere else. To transmit the "reply packet" somewhere else, however, is precisely what Ipsilium contemplated when it spoke of "forwarding" at the Markman hearing. In turn, whether Cisco maintains that the reply packet (a) must be directed to the received field's source, or (b) must not be directed elsewhere, is logically the same position.
It is unhelpful that Ipsilium used the term "forward" at the Markman hearing, because in a real sense the reply packet is never "forwarded," for present purposes. To "forward" implies a passing along wholesale of some material or information. Here, however, the communication device itself generates the reply packet before transmitting it elsewhere. The reply packet is thus not "forwarded" in the traditional sense of the word. And for this reason, the Court finds it unsurprising that the word "forward" appears nowhere in the Asserted Patents—as pointed out by Cisco at the Markman hearing. Id. 53:22-54:2 ("But the more important point I just want to raise is that counsel, in his argument a moment ago, just used a word that hadn't come up at all before and, in fact, doesn't appear in the patent ever, which is 'forward.' I just did a search on the patent on my iPad. It's text-recognized. The word 'forward' never comes up once in the patent."). It is clear to the Court that Plaintiff's counsel's use of the term "forward" at the Markman hearing was simply an inelegant way of expressing that Ipsilium does not believe a "reply packet" must be directed to the received field's source, a position Ipsilium has maintained since its opening claim construction brief. See Op. Br. at 6-9.
With the parties' dispute properly framed, the question is whether a reply packet's destination may be somewhere other than the received field's source. Although the word "reply" often connotes a sense of directionality back to the source of whatever triggered the need for a reply—e.g., when one "replies" to an email, that necessarily means one received an email and is responding back to the received email's originator—that is not necessarily a universal truth, especially in the realm of network technology. To the contrary, a person having ordinary skill in the art of network technology could understand that a "reply packet," for present purposes, may be directed to either the received field's source or elsewhere, because the Asserted Patents' specifications often describe "reply packets" directed to destinations other than the received field's source. For example, the '777 Patent contemplates that—among other possible fields—received packets would have separate "source" and "destination" fields. See, e.g., '777 Patent, 6:29-31 ("The source and destination address fields include addresses, such as Internet addresses, of the source and destination, respectively."); see also '777 Patent Fig. 6 (showing separate "destination address" and "source address" fields). The '777 Patent then describes the creation of a reply packet, which is sent to its destination:
The processor 220 then processes the packets as necessary in accordance with the predictions [step 720]. For example, the processor 220 may begin preparing a reply packet based on the received and predicted fields and begin transmitting the reply packet to the destination (e.g., a communication device 110).'777 Patent, 8:4-9. Taken together, it would make little sense to mention several times that a received packet contains separate source and destination fields—and more important, explain that reply packets are prepared and transmitted based on such fields—if it was only ever contemplated that a "reply packet" would be sent back to the source. This intrinsic evidence instead demonstrates that "reply packets" were never meant to be limited to packets directed back to the originator of the received fields, and the Court will not now impose that narrower construction.
For these reasons, although the Court agrees that "reply packet" should be given its plain and ordinary meaning, to eliminate any confusion, the Court finds that the plain and ordinary meaning of "reply packet" is not limited to packets directed back to the originator of the received fields. // // //
2. "means for obtaining one of the fields of the packet" ('681 Patent and '777 Patent)
| Ipsilium's Construction | Cisco's Construction |
|---|---|
| Function: obtaining one of the fields of thepacketStructure: a communication interface (anytransceiver-like mechanism that enables thecommunication device to communicate withthe other devices and systems on thenetwork), and a processor or microprocessorexecuting instructions, hardwired circuitry, orsilicon via combination of logic gates.Further, to the extent the disclosed structureis a processor or microprocessor executinginstructions and that structure is held torequire a corresponding algorithm, thealgorithm disclosed by the specification is:• '681 Patent at Fig. 7A, 9, and 10 andaccompanying specificationdescriptions, 8:33-42• Provisional at Fig. 4 andaccompanying descriptions• '777 Patent, Fig. 7A andaccompanying specificationdescriptions, 7:32-34 | Function: obtaining one of the fields of thepacketStructure ('681 Patent): the"communication interface" disclosed at Col.4:60-61.Structure ('777 Patent): the"communication interface" disclosed at Col.4:7-8. |
The Court adopts Cisco's construction.
The disputed term appears in independent claim 16 of the '681 Patent and independent claim 16 of the '777 Patent. Am. JCCS at 8-9, 12-13. Claim 16 of the '681 Patent is representative of how the term is used in the claim language:
| Claim 16 |
|---|
| 16. A system for predicting one or more fields of a packet having a plurality of fields, thepacket belonging to a set of packets, each of the fields containing data representing a value,the system comprising:means for obtaining one of the fields of the packet;means for determining a first value of the obtained field;means for predicting a second value of one or more other fields of the packet based on acorrelation between the first value and a property of one or more other fields before theone or more other fields are obtained; and |
| means for processing the packet based on the obtained field and the predicted one or moreother fields. |
The parties agree that this is a means-plus-function term subject to 35 U.S.C. § 112 ("Section 112"). A claim invokes Section 112 if the claim limitation is drafted in the means-plus-function format. See Robert Bosch, LLC v. Snap-On Inc., 769 F.3d 1094, 1097 (Fed. Cir. 2014) ("The use of the term 'means' triggers a rebuttable presumption that § 112, ¶ 6 governs the construction of the claim term."). Here, the term expressly includes the word "means."
Given that Section 112 applies, the Court's analysis is two-fold: The Court (1) identifies the claimed function; and then (2) determines what structure, if any, is disclosed in the specification that corresponds to these functions. Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1351-52 (Fed. Cir. 2015). Structure disclosed in the specification must be "corresponding structure," which is satisfied "if the intrinsic evidence clearly links or associates that structure to the function recited in the claim." Id. at 1352. Even where structure is corresponding, it must also constitute "adequate corresponding structure to achieve the claimed function." Id. (quotation omitted). Where functions "can be performed by a general purpose processor," the written description need not disclose an algorithmic structure for implementing the claimed function. In re Katz, 639 F.3d 1303, 1317 (Fed. Cir. 2011). If, instead, functions "constitute specific computer-implemented functions," then "corresponding algorithms must be disclosed." Id.
The parties agree that the claimed function is "obtaining one of the fields of the packet." See, e.g., Am. JCCS at 8-9. The parties then agree that the structure corresponding to the claimed function at least includes the "communication interface." See, e.g., id. Ipsilium, however, contends that the structure also includes "a processor or microprocessor executing instructions, hardwired circuitry, or silicon via combination of logic gates." Id. And Ipsilium argues that this broader structure is disclosed in (1) claim 49 of the '681 Patent, which refers to "a memory configured to store instructions for obtaining one or more fields of the packet" and "a processor configured to execute the instructions in the memory"; (2) claim 57 of the '681 Patent, which refers to "logic configured to receive one or more fields of the packet"; and (3) Figure 7A of the '681 Patent, which notes that the "processor receives each field." See Op. Br. at 10; '681 Patent Fig. 7A, 15:45-53, 16:52-53. Finally, Ipsilium contends that although no algorithm is necessary, the specification discloses a sufficient algorithm for the processor structure. Op. Br. at 11.
As additional support, Ipsilium notes that Cisco's U.S. Patent No. 6,985,964 discloses that "[c]entral processor 110 receives packets through any of a number of means well-known in the art." Op. Br. at 11. The Court finds, however, that Ipsilium waived its ability to rely on Cisco's patent here because Ipsilium did not include this extrinsic evidence in its joint statement.
The Court finds the structure is limited to the communication interface, because any broader construal of the structure lacks a necessary corresponding algorithm. As a threshold matter, "obtaining" conceivably could mean something broad and thus capable of performance by a general purpose processor, which would not require disclosure of an algorithmic structure. But insofar as "obtaining" refers to a "narrower" concept requiring specific computer-implemented functions, a corresponding algorithm is necessary. See In re Katz, 639 F.3d at 1316.
When this framework is applied, Ipsilium's arguments crumble. To the extent "obtaining one of the fields of the packet" means broadly obtaining fields of packets, the communication interface undisputedly performs that function. All language that Ipsilium contends discloses a more expansive structure refers to a narrower sense of "obtaining," which requires specific computer-implemented functions and thus a corresponding algorithm is necessary. For example, both claim 49 and claim 57 refer to some configuring or programming, which would require computer-implemented functions. See '681 Patent, 15:45-53, 16:52-53. And contrary to Ipsilium's contention, the specification does not disclose a sufficient algorithm for the processor structure. Although Ipsilium cites to two portions of the specification for the '681 Patent, each portion merely recites functional language that in no sense details how a processor would obtain one of the fields of the packet. See '681 Patent Fig. 7A, Step 710 (providing that the "processor receives each field and analyzes value in field"), 8:39-41 ("The processor . . . received each field of the packet . . . and analyzes the value in the fields [step 710]."); see also Ergo Licensing, LLC v. CareFusion 303, Inc., 673 F.3d 1361, 1365 (Fed. Cir. 2012) (holding that mere functional language, which "[did] not contain any step-by-step process" was insufficient).
Cisco argues that Ipsilium may not rely on separate claims for corresponding structure. Resp. Br. at 7. Because the Court finds the separate claims would not provide corresponding structure, it need not determine now whether it is generally improper for separate claims to provide corresponding structure.
3. "means for predicting a second value of one or more other fields of the packet based on a correlation between the first value and a property of one or more other fields before the one or more other fields are obtained" (the '681 Patent) / "means for predicting how the packet will be processed by upper level protocols, application protocols or both based on the value of the obtained field and further predicting a value of at least one other field of the packet not yet received based on the prediction of how the packet will be processed" (the '777 Patent)
| Ipsilium's Construction | Cisco's Construction |
|---|---|
| Function: predicting a second value of one ormore other fields of the packet based on acorrelation between the first value and aproperty of one or more other fields beforethe one or more other fields are obtained('681 Patent) / predicting how the packet willbe processed by upper level protocols,application protocols or both based on thevalue of the obtained field and furtherpredicting a value of at least one other field ofthe packet not yet received based on theprediction of how the packet will beprocessed ('777 Patent)Structure: a processor or microprocessorexecuting instructions, hardwired circuitry,silicon via combination of logic gates.Further, to the extent the disclosed structureis a processor or microprocessor executinginstructions and that structure is held torequire a corresponding algorithm, thealgorithm disclosed by the specification ispredicting due to:'681 Patent• fragmentation ('8:64-9:7);• segmentation (9:18-32);• IP packet length (Prov. Appl. atIP000228-229); or• sequence number (Prov. Appl. atIP000071).'777 Patent• protocol field (7:33-8:3); | Function: predicting a second value of one ormore other fields of the packet based on acorrelation between the first value and aproperty of one or more other fields beforethe one or more other fields are obtained('681 Patent) / predicting how the packet willbe processed by upper level protocols,application protocols or both based on thevalue of the obtained field and furtherpredicting a value of at least one other field ofthe packet not yet received based on theprediction of how the packet will beprocessed ('777 Patent)Structure: a processor or microprocessorexecuting instructions and/or hardwiredcircuitry, silicon via combination of logicgates implementing the following algorithms:predicting due to:'681 Patent• fragmentation (8:64-9:7);• segmentation (9:18-32);• IP packet length (Prov. Appl. atIP000228-229); or• sequence number (Prov. Appl. atIP000071).'777 Patent• protocol field (7:33-8:3); |
| • flags field (7:33-8:3)• IP packet length (Prov. Appl. atIP000228-229); or• total length (Prov. Appl. at IP000412). | • flags field (7:33-8:3)• IP packet length (Prov. Appl. atIP000228-229); or• total length (Prov. Appl. at IP000412). |
The Court adopts Cisco's construction.
The disputed term appears in independent claim 16 of the '681 Patent and independent claim 16 of the '777 Patent. Am. JCCS at 10-11, 14-15. Claim 16 of the '681 Patent is representative of how the term is used in the claim language:
| Claim 16 |
|---|
| 16. A system for predicting one or more fields of a packet having a plurality of fields, thepacket belonging to a set of packets, each of the fields containing data representing a value,the system comprising:means for obtaining one of the fields of the packet;means for determining a first value of the obtained field;means for predicting a second value of one or more other fields of the packet basedon a correlation between the first value and a property of one or more other fieldsbefore the one or more other fields are obtained; andmeans for processing the packet based on the obtained field and the predicted one or moreother fields. |
As discussed at the Markman hearing and confirmed in the parties' supplemental briefs, although the parties once had several disagreements regarding this term, they have since narrowed their dispute significantly. See Markman Tr. 94:22-98:7; Pl.'s Supp. Br. at 7; Def.'s Supp. Br. at 1-3. The only remaining dispute concerns whether "hardwired circuitry" and "silicon via combination logic gates" as structure require an algorithmic disclosure. Ipsilium argues that under Katz, such "specialized hardware" is "distinct from a general-purpose computer and therefore [is] not limited to the algorithms disclosed in the patents—as only microprocessor and/or software claims require algorithms for non-generic functions." Pl.'s Supp. Br. at 7. Cisco disagrees with Ipsilium's characterization of Katz and counters that "because special programming is necessary to implement the claim limitation, an algorithm is required regardless of whether that programming occurs via a software or hardwiring." Def.'s Supp. Br. at 2.
The Court finds Cisco's arguments more persuasive. To start, Katz nowhere set forth Ipsilium's purported distinction. If anything, Katz weighed against such a conclusion: "If a function's corresponding structure is a type of computer or processor, indefiniteness analysis does not turn on the name of the structure that does the processing." 639 F.3d at 1317. As the Federal Circuit there explained, "[t]he key inquiry is whether one of ordinary skill in the art would understand the patent to disclose structure that sufficiently corresponds to the claimed function, which in the case of a specific function implemented on a general purpose computer requires an algorithm." Id. Turning then to the Asserted Patents, the Court finds that the specifications disclose that special programming is necessary to implement the claimed invention, whether the programming is executed through software or hardwiring. For example, as detailed in the '681 Patent:
The instructions may be read into local memory 230 for another computer-readable medium or from another device via the communication interface 260. Execution of the sequences of instructions contained in local memory 230 causes processor 220 to perform processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the present invention.'681 Patent, 5:34-42. As this excerpt demonstrates, some special programming is always necessary to implement the claimed invention—be it through software or hardwiring—which requires an algorithm.
Because the parties' sole dispute concerns the proper interpretation of Katz on this narrow point, which the Court resolves in Cisco's favor, the Court accordingly adopts Cisco's construction.
4. "means for processing the packet based on the obtained field and the predicted one or more other fields" ('681 Patent) / "means for processing the packet based on at least the obtained field and the predicted at least one other fields" ('777 Patent)
| Ipsilium's Construction | Cisco's Construction |
|---|---|
| Function: processing the packet based on theobtained field and the predicted one or moreother fields ('681 Patent) / processing thepacket based on at least the obtained field andthe predicted at least one other fields ('777Patent) | Function: processing the packet based on theobtained field and the predicted one or moreother fields ('681 Patent) / processing thepacket based on at least the obtained field andthe predicted at least one other fields ('777Patent) |
| Structure: a processor or microprocessorexecuting instructions, hardwired circuitry, orsilicon via combination of logic gates.Further, to the extent the disclosed structureis a processor or microprocessor executinginstructions and that structure is held torequire a corresponding algorithm, thealgorithm disclosed by the specification is:• '681 Patent at Fig. 7A, 7B andaccompanying specificationdescriptions; 9:37-9:43• Provisional at Title; at 3-8;IP000223-230; Fig. Fig. 4 andaccompanying descriptions• '777 Patent at Fig. 7A, 7B, Fig. 9, Fig.10 and accompanying specificationdescription; 8:4-11; 8:47-51 | Structure: Indefinite for failing to disclose astructure that performs the claimed function. |
|---|
The Court adopts Cisco's construction and finds the term indefinite for failing to disclose a structure that performs the claimed function.
The disputed term appears in independent claim 16 of the '681 Patent and independent claim 16 of the '777 Patent. Am. JCCS at 11-12. Claim 16 of the '681 Patent is representative of how the term is used in the claim language:
| Claim 16 |
|---|
| 16. A system for predicting one or more fields of a packet having a plurality of fields, thepacket belonging to a set of packets, each of the fields containing data representing a value,the system comprising:means for obtaining one of the fields of the packet;means for determining a first value of the obtained field;means for predicting a second value of one or more other fields of the packet based on acorrelation between the first value and a property of one or more other fields before theone or more other fields are obtained; andmeans for processing the packet based on the obtained field and the predicted one ormore other fields. |
The parties dispute whether the patent adequately discloses a structure that performs the claimed function. Ipsilium's proposed structure is "a processor or microprocessor executing instructions, hardwired circuitry, or silicon via combination of logic gates." Op. Br. at 16. As to the purported "hardwired circuitry or silicon via a combination of logic gates" structure, Ipsilium again argues that no algorithm is required under Katz. Id. at 17. As to the processor structure, Ipsilium contends that (1) the specification need not disclose an algorithm because the function of "processing" is generic and thus does not "require special programming"; and (2) even if an algorithm is required, the specification discloses an algorithm through Figure 7A and Column 4:35-41. Id.
Starting with the "hardwired circuitry or silicon via a combination of logic gates" structure, and for reasons detailed above, the Court finds that an algorithm is required. See supra II.3. As to the "processor" function, the Court finds that Katz's narrow exception does not apply, because "processing the packet based on the obtained field and the predicted one or more other fields" is not coextensive with a general purpose microprocessor. Although Katz held that "processing" was a generic function, the claim here calls for processing "based on the obtained field and predicted one or more other fields," which requires some special programming. Cf. Katz, 639 F.3d at 1316. In fact, by calling for the processor to process the packet "based on" certain information, the agreed function is instead a narrower sort of "processing," which Katz explained requires an algorithm. Katz, 639 F.3d at 1315 (finding several claims "clearly indefinite" because they "contain[ed] a means-plus-function limitation that recites a 'processing means . . . for receiving customer number data entered by a caller and for storing the customer number data . . . and based on a condition coupling an incoming call to the operator terminal, the processing means visually displaying the customer number data,'" where the patents "[did] not disclose an algorithm that corresponds to the 'based on a condition coupling an incoming call to the operator terminal' function").
The Court next finds that the Asserted Patents do not disclose a corresponding algorithm. First, Figure 7A only provides that the "processor processes packet as necessary," which is inadequate functional language, as it does not show "how the [processor] can be programmed to perform the claimed function." Aristocrat Techs. Austl. Pty Ltd. v. Int'l Game Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008). Second, Column 4:35-41 states, in full: //
In one implementation consistent with the present invention, the network 120 includes a packet-based network that operates according to a communications protocol, Such as Transmission Control Protocol and all related protocols, as specified in "Requirements for Internet Hosts Communication Layers," RFC1122, ftp://ftp.lisi.edu/innotes/rfc1122.txt, October 1989.'681 Patent, 4:35-41. But nowhere does this passage even reference the processor, nonetheless disclose an algorithm.
Accordingly, the Court finds the term indefinite for failure to disclose a necessary corresponding algorithm.
5. "predicting a [second] value of at least one other field of the packet not yet received" ('681 Patent and '777 Patent)
The parties' amended joint claim construction statement refers to both this version of the claim term and "predict a [second] value of one or more other fields not yet received." Am. JCCS at 4-5. The parties, however, have now narrowed the dispute to four claims, none of which include this alternate version.
| Ipsilium's Construction | Cisco's Construction |
|---|---|
| No construction necessary. | "predicting a [second] value of at least oneother field of the packet before that field isreceived"(with minor variations as necessary toaccount for slight differences in claimlanguage) |
The Court adopts Cisco's construction.
The disputed terms appear in independent claims 1 and 2 of the '681 Patent and independent claims 1 and 14 of the '777 Patent. Am. JCCS at 4-6. Claim 1 of the '681 Patent is representative of how the term is used in the claim language:
| Claim 1 |
|---|
| 1. A method for predicting one or more fields of a packet having a plurality of fields, thepacket belonging to a set of packets, each of the fields containing data representing a value,the method comprising:receiving one or more of the fields of the packet;analyzing a first value of at least one of the received fields;predicting a second value of at least one other field of the packet not yet received,based on a correlation between the first value and a property of the at least one other fieldnot yet received; and |
| processing the packet based on the one or more received fields and the predicted at leastone other field. |
The parties' dispute regarding this term only crystalized at the Markman hearing and through supplemental briefing. As it now stands, Ipsilium contends that the language "not yet received," as used in the disputed claims, applies to "packet." See Pl.'s Supp. Br. at 3. Cisco, on the other hand, contends that "not yet received" must apply to "field," and that by adopting Cisco's proposed construction, the Court could remove any ambiguity on this point. See Def.'s Supp. Br. at 3-6. And Cisco primarily asks the Court to reject Ipsilium's "plain meaning" interpretation because to construe "not yet received" as applying to "packet" would introduce at least two antecedent-basis errors. Id. at 5-6. First, Ipsilium's reading removes the antecedent basis for " the packet," because "there is no packet earlier in the claim that has not yet been received." Id. at 5. Second, Ipsilium's position eliminates the antecedent basis for " the at least one other field not yet received" from the correlation clause. Id. at 5-6.
At the Markman hearing, Ipsilium stated that "not yet received" could apply to either "packet" or field." Markman Tr. 26:3-7. Ipsilium's supplemental briefs clarified that it believes "not yet received" applies to just "packet" in the four disputed claims. Pl.'s Supp. Br. at 3 ("Ipsilium proposes a plain meaning, that 'predicting' . . . occurs . . . before the packet containing the predicted value of the field is received ('681 Claims 1, 2; '777 Claims 1, 14).").
Although Cisco discussed both of these antecedent-basis criticisms at the Markman hearing, see Markman Tr. 19:20-20:19, Ipsilium in its supplemental brief only proposed a reading of the claim to ameliorate the second of Cisco's antecedent-basis concerns:
The "correlation" language recites, "the at least one other field," and the antecedent basis comes earlier in the claim, "predicting a second value of at least one other field." No problem. The "not yet received" later independently modifies the "the at least one other field" that is part of "correlation." That does not mean, as Cisco argues, the previous "at least one other field" must also recite the phrase "not yet received." Indeed, following Cisco's reasoning would still not solve the alleged problem, as Cisco's construction still points to "the field." Instead, Cisco's circular logic requires the prior language of "a field not yet received," which does not exist. In any event, that is not how antecedent basis works, and more importantly, that is not what the claim language says. The claim language uses the phrase "packet not yet received" in the predicting limitation and "field not yet received" in the separate, correlation limitation. The phrase "not yet received" modifies different nouns. This language is easily understood and does not lead to indefiniteness due to an antecedent basis problem.Pl.'s Supp. Br. at 6. As tortured as this reading might be, if this were the only antecedent-basis issue, the Court might side with Ipsilium's reading of the claim. The Court, however, finds that no fair reading of the "predicting" limitation would provide an antecedent basis for " the packet," if the Court were to adopt Ipsilium's position. Claim 1 nowhere previously speaks of an unreceived packet. Rather, the claim speaks of "a packet" in the preamble, which provides an antecedent basis for both "the packet" from which a field is received and "the packet," which Ipsilium now maintains is not yet received. But Ipsilium cannot have it both ways: "the packet" cannot both (1) already have been received and provide a field and (2) not be received. Ipsilium provides no justification for this internally inconsistent "plain meaning" reading.
For these reasons, the Court adopts Cisco's construction. Because the parties have narrowed their dispute to four claims, the Court sets forth the following chart to quickly summarize how Cisco's construction applies to each:
| '681 Patent, Claim 1 |
|---|
| predicting a second value of at least one other field of the packet before that field isreceived |
| '681 Patent, Claim 2 |
| predicting a value of at least one other field of the packet before that field is received |
| '777 Patent, Claim 1 |
| predicting a value of at least one other field of the packet before that field is received |
| '777 Patent, Claim 14 |
| predicting a value of at least one other field of the packet before that field is received |
6. "correlation" terms ('681 Patent)
| Ipsilium's Construction | Cisco's Construction |
|---|---|
| No construction necessary. | "based on a correlation between the firstreceived value and a property of the not yetreceived field" |
The Court finds no construction is necessary, but that the plain and ordinary meaning does not permit the first correlate to be an unreceived field.
The disputed terms appear in independent claims 1, 16, 17, 18, 30, and 57 of the '681 Patent. Am. JCCS at 6-7. Claim 1 is generally representative of how the term is used in the claim language:
| Claim 1 |
|---|
| 1. A method for predicting one or more fields of a packet having a plurality of fields, thepacket belonging to a set of packets, each of the fields containing data representing a value,the method comprising:receiving one or more of the fields of the packet;analyzing a first value of at least one of the received fields;predicting a second value of at least one other field of the packet not yet received, basedon a correlation between the first value and a property of the at least one other fieldnot yet received; andprocessing the packet based on the one or more received fields and the predicted at leastone other field. |
The other claims' language, however, differ slightly:
| Claim 16 |
|---|
| . . . based on a correlation between the first value and a property of one or moreother fields before the one or more other fields are obtained; and |
| Claim 17 |
| . . . based on a correlation between the first value, and a property of one or moreother fields not yet received . . . . |
| Claim 18 |
| . . . based on a correlation between the first value and a property of one or moreother fields not yet received . . . . |
| Claim 30 |
| . . . based on a correlation between at least one of the one or more obtained fields anda property of at least one other field before the at least one other field is received; |
| Claim 57 |
| . . . based on a correlation between the first value and a property of one or moreother fields before the one or more other fields are received; and |
In the claim construction briefing, the parties disputed whether it was unclear which text is modified by the phrase "not yet received." See, e.g., Resp. Br. at 19. According to Cisco, "not yet received" in claim 1 might modify "first value," "property," and/or "field." Id. Cisco then argued that its redrafting "confirms that the required correlation is between (1) the first received value (in other words, the first value that has already been received) on the one hand, and (2) a property of the not yet received field on the other hand." Id. Ipsilium responds that Cisco is simply "manufactur[ing] confusion" here. Reply Br. at 13. From Ipsilium's perspective, the only fair reading is that "not yet received" modifies "field." Id.
The Court finds that no reasonable reading of claim 1 would find that "not yet received" modifies anything other than "field." To start, claim 1 sets out two correlates separated by the conjunction "and." It would make no grammatical sense for "not yet received" to modify the correlate on the other side of the conjunction: "first value." Focusing on the proper correlate—"a property of the at least one other field"—Cisco's argument requires finding ambiguity as to whether the modifier phrase "not yet received" relates to "property" or "field." Were "not yet received" to modify "property," however, the modifier phrase would be misplaced. More important, intrinsic evidence shows that it only makes sense for "not yet received" to modify "field." For example, whereas the '681 Patent describes "receiving" fields numerous times, it never once mentions receiving a property. See, e.g., '681 Patent 3:5-7 ("The system receives one or more fields of one or more packets and determines the value of at least one of the received fields."). It is thus clear that "not yet received" modifies "field," and the Court need not redraft the claim language to remove artificial confusion.
Although the claim construction briefing focused on the modifier phrase "not yet received," a separate dispute emerged in Ipsilium's reply brief and at the Markman hearing. This new dispute concerns whether the Court should find that "the first value" really means "the first received value." Cisco argued that, as written, it is ambiguous whether "the first value" has been received, but that its prior reception "is a necessary element of the claim." Markman Tr. 31:13-20. As support, Cisco notes that the specification only speaks of the first correlate as having already been received. See '681 Patent, 7:44-49 ("This may be accomplished because the packets received by the communication device 110 have useful correlation, or correlations, between some fields that have already been received and some other fields in the packet that have yet to arrive."). Cisco further stresses that limiting the first correlate to something already received was added during the prosecution history, to overcome a Section 103 rejection. Markman Tr. 32:9-13. Ipsilium, on the other hand, contends that it would be improper to read in a "received" limitation, because "the claimed correlation is with a 'first value,' independent of whether or not it is received." Reply Br. at 14.
The Court agrees that Ipsilium's position before the patent office to overcome a Section 103 rejection sufficiently contradicts its current position to meet the high threshold for disavowal. See Poly-America, L.P. v. API Indus., Inc., 839 F.3d 1131, 1136 (Fed. Cir. 2016) ("While disavowal must be clear and unequivocal, it need not be explicit."). In arguing for the patentability of the claimed method for prediction over U.S. Patent No. 5,056,058 to Hirata et al., Ipsilium stated:
Applicant's invention, on the other hand, is not simply predicting the next expected frame type based on the order of occurrence of the prior frames in an established sequence. Instead, Applicant's invention as defined in amended claims 1, 16, 17, 30 and 57 relates to predicting data fields in layer protocols, but not simply the expectation of the next type of frame, but also the values of the actual data fields, or type of header fields, based upon an already received value.Piepmeier Decl. Ex. D, at 17. Ipsilium's representation in this excerpt is also consistent with the '681 Patent's specification, which uniformly describes a process of predicting unreceived information based on already received information. See, e.g.,'681 Patent 3:7-11 ("The System predicts a value of at least one other one of the fields of one other one of the packets from the set of packets based on the value of the received field before the the other packet containing the other field is received.").
. . .
In order to enhance the claims and to further clarify these distinctions that the claims have over the cited references, claims 1, 16, 17, 30 and 57 have been amended herein to specifically recite that the prediction is based upon a correlation between the first value received and a property of the fields yet to be received. Accordingly, the claims as amended are not disclosed, taught or rendered obvious by the Hirata reference alone.
Although the Court rejects Ipsilium's position that the claimed correlation includes where a "first value" has not yet been received, it does not necessarily follow that the Court should entirely redraft six claims. Cisco proposes redrafting claims 1, 16, 17, 18, 30, and 57 to state: "based on a correlation between the first received value and a property of the not yet received field." But not all claims are as amenable to this rephrasing as claim 1. Claim 30, for example, does not even use the term "first value." Given the general aversion to rewriting claims, especially in Cisco's proposed wholesale fashion, the Court considers it more prudent to hold that no construction is necessary, but that the plain and ordinary meaning does not permit the first correlate to be an unreceived field.
7. Method Claims and Step Orders ('681 Patent and '777 Patent)
| Ipsilium's Construction | Cisco's Construction |
|---|---|
| No step order is required | The steps of each method claim must beperformed in order. |
The Court adopts Cisco's construction and finds that each disputed method claim must be performed in order.
This dispute concerns independent claims 1, 2, 44, and 55 and dependent claims 3, 5, 6, 7, 9, 10, 14, 45, and 46 of the '681 Patent, as well as independent claims 1, 14, 44, and 55 and dependent claims 2, 3, 4, 6, 8, 9, 45, and 46 of the '777 Patent. Am. JCCS at 7-8. Claim 44 of the '681 Patent is one example of how the term is used in the claim language:
| Claim 44 |
|---|
| 44. A method for replying to packets that have a plurality of fields, the packets beingbroken up into one or more packets, before the packets are entirely received, comprising:receiving one or more of the fields of the packet;predicting one or more other fields of the packet before the one or more other fields arereceived;generating a reply packet based on the one or more received fields and the predicted oneor more other fields; andtransmitting the reply packet. |
The parties dispute whether claim language throughout the Asserted Patents dictate that the steps of method claims must be performed in the order provided in the claims. Ipsilium argues against this requirement, contending that "[u]nless the steps of a method [claim] actually recite an order, the steps are not ordinarily construed to require one." See Op. Br. at 19 (citing Interactive Gift Express, Inc. v. Compuserve Inc., 256 F.3d 1323, 1342 (Fed. Cir. 2001) (citation omitted)). Ipsilium then adds that the Asserted Patents disclaim that "while a series of steps have been described with regard to FIGS. 7A and 7B, the order of the steps may be changed in other implementations consistent with the present invention." Id. (citing '681 Patent, 11:1-4). With regard to claim 44 in particular, Ipsilium maintains that "[w]hile the 'generating' and 'transmitting' steps necessarily follow an order . . . the 'receiving' and 'predicting' steps are completely independent of each other." Id. at 20.
In response, Cisco argues that the Court should construe method claims "to require that its steps be performed in order if the claim implicitly requires that order, such as where 'the steps of [the] method claim refer to the completed results of the prior step.'" Resp. Br. at 20 (citing E-Pass Techs., Inc. v. 3Com Corp., 473 F.3d 1213, 1222 (Fed. Cir. 2007). Claim 44, for example, contains several steps that refer to completed results of the prior step. And given that Ipsilium concedes that the "generating" and "transmitting" steps necessarily progress in that order—and after the "receiving" and "predicting" steps—the only dispute is whether the "receiving" step must come before the "predicting" step. See Markman Tr. 58:13-22. Cisco argues it must, because the "predicting" step refers to "other fields," which necessarily "implies that you have already received something else, which means predicting must occur after receiving step." Resp. Br. at 22. Regarding the disclaimer that the "order of the steps may be changed," Cisco characterizes that language as a "vague boilerplate statement [that] cannot change that the claims were drafted to mandate a particular order." Resp. Br. at 23. Finally, Cisco notes that the following language from the prosecution history supports a limited construction, in which even the "receiving" and "predicting" steps must be performed in that order:
In sharp contrast [to the Mattaway reference], Applicant receives a first field of a packet, predicts a second field, then proceeds with processing of the packet based on the predicted second field and the first received field while awaiting receipt of the second field. It is only upon receipt of the second field that Applicant checks for errors or even employs any error correction methods.See Resp. Br. at 22-23 (citing Resp. Br. Ex. A, '681 Patent File History, February 4, 2003 Letter to PTO at 8).
Although the parties seek construction regarding the performance order for numerous method claims, they only discuss claim 44 of the '681 Patent in any detail. Having reviewed each disputed method claim, the Court finds that only claim 44 of the '681 Patent is even open for debate. Claim 1 of the '861 Patent, for example, expressly contemplates that one field is received before any predicting step takes place. Turning then to claim 44, the Court agrees with Cisco that the claim implicitly requires that "receiving" occur before "predicting. The Court recognizes that "not every process claim is limited to the performance of its steps in the order written." Loral Fairchild Corp. v. Sony Corp., 181 F.3d 1313, 1322 (Fed. Cir. 1999). But "the sequential nature of the claim steps is apparent from the plain meaning of the claim language and nothing in the written description suggests otherwise." See Mantech Envtl. Corp. v. Hudson Envtl. Servs., Inc., 152 F.3d 1368, 1373 (Fed. Cir. 1998). As Cisco observes, the "predicting" step's reference to "other" fields implies something already took place, "which means predicting must occur after [the] receiving step." See Resp. Br. at 22. And nothing from the claim language, written description, or prosecution history demonstrates that the patentee ever contemplated a method of "predicting" before "receiving."
8. Preambles as Limiting ('681 Patent and '777 Patent)
| Ipsilium's Construction | Cisco's Construction |
|---|---|
| Preambles are not limiting | Preambles are limiting |
The Court withholds judgment as to whether preambles are limiting in the manner that Cisco requests.
This dispute concerns independent claims 1, 2, 16, 17, 18, 30, 31, 44, 49, 54, 55, and 57 of the '681 Patent, as well as independent claims 1, 14, 16, 17, 28, 30, 42, and 57 of the '777 Patent. Am. JCCS at 3-4. Claim 1 of the '681 Patent is one example of a disputed preamble:
| Claim 1 |
|---|
| 1. A method for predicting one or more fields of a packet having a plurality of fields,the packet belonging to a set of packets, each of the fields containing data representinga value, the method comprising:receiving one or more of the fields of the packet;analyzing a first value of at least one of the received fields; |
| predicting a second value of at least one other field of the packet not yet received, basedon a correlation between the first value and a property of the at least one other field notyet received; andprocessing the packet based on the one or more received fields and the predicted at leastone other field. |
Preambles generally "do[] not limit the claims." Georgetown Rail Equip. Co. v. Holland L.P., 867 F.3d 1229, 1236 (Fed. Cir. 2017) (quoting Allen Eng'g Corp. v. Bartell Indus., Inc., 299 F.3d 1336, 1346 (Fed. Cir. 2002)). A preamble may limit the claims, however, where (1) "it recites essential structure or steps"; (2) "claims depend[] on a particular disputed preamble phrase for antecedent basis"; (3) it "is essential to understand limitations or terms in the claim body"; (4) it "recit[es] additional structure or steps underscored as important by the specification"; or (5) there was "clear reliance on the preamble during prosecution to distinguish the claimed invention from the prior art." Id. (quoting Catalina Mktg. Int'l, Inc. v. Coolsavings.com, Inc., 289 F.3d 801, 808 (Fed. Cir. 2002)). Conversely, preambles are not limiting "where a patentee defines a structurally complete invention in the claim body and uses the preamble only to state a purpose or intended use for the invention." Id. (quoting Catalina Mktg. Int'l, Inc., 289 F.3d at 808). Courts determine whether to treat preambles as limiting based on a review of the entire patent, "to gain an understanding of what the inventors actually invented and intended to encompass by the claim." Id. (quoting Catalina Mktg. Int'l, Inc., 289 F.3d at 808).
Ipsilium argues that claim 1's preamble "merely sets the context and the intended use for the invention" and that "deleting the preamble would have no effect, as the claim body independently recites the structure or steps to accomplish the prediction." Op. Br. at 20-21. Cisco disagrees, and argues that the preamble "provides an antecedent basis for multiple terms appearing in the claim[] including 'packet,' 'set of packets,' and 'one or more fields.'" Resp. Br. at 24. According to Cisco, this shows that "the preamble is limiting because it is necessary to give meaning to at least three different terms recited in the bodies of the claims." Id.
The Court finds that it cannot at this stage adopt a blanket construction regarding all preambles. At the Markman hearing, Cisco maintained that the Court could lump together all disputed preambles into two general groups. Markman Tr. 73:3-9. Cisco's briefing, however, provides inconsistent information regarding what exactly Cisco seeks from the Court. At one point, in discussing claim 1 of the '681 Patent, Cisco's claim construction brief maintains that the preamble contained no less than three terms that provided an antecedent basis for terms appearing in the claims. Resp. Br. at 24 (arguing the preamble provides antecedent basis for at least "packet," "set of packets," and "one or more fields"). But in an exhibit attached to its brief—which Cisco represented as "highlight[ing] similar examples of antecedent bases found in the preambles of independent claims" throughout the Asserted Patents—Cisco only identified "packet" as the relevant term in various preambles that provide antecedent basis for terms appearing in claims. Compare Resp. Br. at 25 ("This reasoning applies to almost all of the asserted independent claims, as demonstrated in the attached Exhibit G-H, which highlights similar examples of antecedent bases found in the preambles of independent claims 1, 2, 16, 17, 18, 30, 31, 44, 49, 54, 55, and 57 of the '681 patent and claims 1, 14, 16, 17, 28, 30, 42, and 57 of the '777 patent."), with Resp. Br. Ex. G (highlighting only "packet" in various preambles, including for claim 1).
To determine whether preambles are limiting, the Court must review each preamble with an eye toward the patent as a whole. See Georgetown Rail Equip. Co., 867 F.3d at 1236. The Court is not persuaded that such an individualized and holistic approach is compatible with Cisco's request for a blanket conclusion as to all preambles, especially given the inconsistent information provided by Cisco. Thus, while a blanket approach might be warranted in some circumstance, this is not one of them. Accordingly, the Court withholds judgment as to whether preambles are limiting in the manner that Cisco requests.
III. CONCLUSION
The Court GRANTS Cisco's motion to strike. In addition, the Court CONSTRUES the disputed terms as follows: // // // //
| Patent | Claim Term | Construction |
|---|---|---|
| '681,'777 | "reply packet" | No construction necessary - Plain andordinary meaning is not limited topackets directed back to the originator ofthe received fields |
| '681,'777 | "means for obtaining one of the fields ofthe packet" | Function: obtaining one of the fields ofthe packetStructure ('681 Patent): the"communication interface" disclosed atCol. 4:60-61.Structure ('777 Patent): the"communication interface" disclosed atCol. 4:7-8. |
| '681,'777 | "means for predicting a second value ofone or more other fields of the packetbased on a correlation between the firstvalue and a property of one or more otherfields before the one or more other fieldsare obtained" (the '681 Patent) / "meansfor predicting how the packet will beprocessed by upper level protocols,application protocols or both based on thevalue of the obtained field and furtherpredicting a value of at least one otherfield of the packet not yet received basedon the prediction of how the packet willbe processed" (the '777 Patent) | Function: predicting a second value ofone or more other fields of the packetbased on a correlation between the firstvalue and a property of one or moreother fields before the one or more otherfields are obtained ('681 Patent) /predicting how the packet will beprocessed by upper level protocols,application protocols or both based onthe value of the obtained field andfurther predicting a value of at least oneother field of the packet not yet receivedbased on the prediction of how thepacket will be processed ('777 Patent)Structure: a processor or microprocessorexecuting instructions and/or hardwiredcircuitry, silicon via combination oflogic gates implementing the followingalgorithms:predicting due to:'681 Patent• fragmentation (8:64-9:7);• segmentation (9:18-32);• IP packet length (Prov. Appl. atIP000228-229); or• sequence number (Prov. Appl. atIP000071).'777 Patent• protocol field (7:33-8:3);• flags field (7:33-8:3)• IP packet length (Prov. Appl. atIP000228-229); or• total length (Prov. Appl. atIP000412). |
|---|---|---|
| '681,'777 | "means for processing the packet basedon the obtained field and the predictedone or more other fields" ('681 Patent) /"means for processing the packet basedon at least the obtained field and thepredicted at least one other fields" ('777Patent) | Function: processing the packet basedon the obtained field and the predictedone or more other fields ('681 Patent) /processing the packet based on at leastthe obtained field and the predicted atleast one other fields ('777 Patent)Structure: Indefinite for failing todisclose a structure that performs theclaimed function. |
| '681 Patent, claim 1: "predicting asecond value of at least one other fieldof the packet before that field isreceived" | ||
|---|---|---|
| '681,'777 | "predicting a [second] value of at leastone other field of the packet not yetreceived" | '681 Patent, claim 2: "predicting a valueof at least one other field of the packetbefore that field is received"'777 Patent, claim 1: "predicting a valueof at least one other field of the packetbefore that field is received"'777 Patent, claim 14: "predicting avalue of at least one other field of thepacket before that field is received" |
| '681 | "correlation" terms | No construction necessary - Plain andordinary meaning does not permit thefirst correlate to be an unreceived field |
| '681,'777 | Method Claims and Step Orders | The steps of each method claim must beperformed in order |
| '681,'777 | Preambles as Limiting | The Court withholds judgment as towhether preambles are limiting |
The Court SETS a further case management conference ("CMC") for May 22, 2019 at 2:00 p.m., to occur concurrently with the hearing on Ipsilium's pending motion for leave to file amended infringement contentions. The Court also DIRECTS the parties to meet and confer before the CMC to discuss a proposed case schedule through trial and to submit a joint CMC statement by May 15, 2019.
In the remaining briefing on Ipsilium's motion for leave to file amended infringement contentions, the Court expects the parties to discuss whether this order has any impact on the resolution of that motion.
IT IS SO ORDERED. Dated: 4/16/2019
/s/_________
HAYWOOD S. GILLIAM, JR.
United States District Judge