Opinion
CASE NO. 2:18-CV-53-JRG
04-15-2019
IMPLICIT, LLC, v. NETSCOUT SYSTEMS, INC., et al.
CLAIM CONSTRUCTION MEMORANDUM AND ORDER
Before the Court is the Opening Claim Construction Brief (Dkt. No. 89) filed by Plaintiff Implicit, LLC ("Plaintiff" or "Implicit"). Also before the Court are Defendants NetScout Systems, Inc. and Sandvine Corp.'s ("Defendants'") Responsive Claim Construction Brief (Dkt. No. 93) and Plaintiff's reply (Dkt. No. 96).
The Court held a claim construction hearing on April 11, 2019.
Table of Contents
I. BACKGROUND ....................................................................................................................... 2
II. LEGAL PRINCIPLES ........................................................................................................... 3
III. AGREED TERMS ................................................................................................................. 7
IV. DISPUTED TERMS .............................................................................................................. 8
A. "sequence of [two or more] routines" ................................................................................... 8
B. "list of conversion routines" ................................................................................................ 14
C. "state information" .............................................................................................................. 15
D. "process subsequent packets in the message using the sequence of routines indicated in the stored path" and Related Terms .................................................................................... 19
E. "the packet of the message" ................................................................................................ 20
F. "convert one or more packets having a TCP format into a different format" and Related Terms .................................................................................................................................. 23
G. "execute a Transmission Control Protocol (TCP)" and Related Terms ............................. 29
V. CONCLUSION ...................................................................................................................... 36
I. BACKGROUND
Plaintiff has alleged infringement of United States Patents No. 8,694,683 ("the '683 Patent"), 9,270,790 ("the '790 Patent"), and 9,591,104 ("the '104 Patent") (collectively referred to as "the patents-in-suit," "the Balassanian Patents," or "the Demulitplexing Patents"). (See Dkt. No. 89, Exs. 1-3.) Plaintiff submits that the patents-in-suit relate to computer networking. (See Dkt. No. 89, at 1-2.)
The '683 Patent, for example, titled "Method and System for Data Demultiplexing," issued on April 8, 2014, and bears an earliest priority date of December 29, 1999. The '790 Patent is a continuation of the '683 Patent. The '104 Patent, in turn, is a continuation of the '790 Patent. These patents therefore share a common specification. The Abstract of the '683 Patent states:
A method and system for demultiplexing packets of a message is provided. The demultiplexing system receives packets of a message, identifies a sequence of message handlers for processing the message, identifies state information associated with the message for each message handler, and invokes the message handlers passing the message and the associated state information. The system identifies the message handlers based on the initial data type of the message and a target data type. The identified message handlers effect the conversion of the data to the target data type through various intermediate data types.
The Court previously construed terms in the '683 Patent, the '790 Patent, and the '740 Patent in Implicit, LLC v. Trend Micro, Inc., No. 6:16-CV-80, Dkt. No. 115, 2017 WL 1190373 (E.D. Tex. Mar. 29, 2017) (Gilstrap, J.) ("Trend Micro") and in Implicit, LLC v. Huawei Technologies USA, Inc., et al., 6:17-CV-182, 2018 WL 1169137 (E.D. Tex. Mar. 6, 2018) (Gilstrap, J.) ("Huawei," sometimes referred to as "PAN," which is an acronym for Palo Alto Networks, Inc., the only remaining defendant in the Huawei case at the time of the claim construction hearing).
The '683 Patent has also been the subject of claim construction in the Northern District of California in Implicit Networks, Inc. v. F5 Networks, Inc., No. 3:14-CV-2856, Dkt. No. 57, 2015 WL 2194627 (N.D. Cal. May 6, 2015) (Illston, J.) ("F5 Networks II"). Further, the Northern District of California construed terms in an ancestor patent, United States Patent No. 6,629,163 ("the '163 Patent"), in Implicit Networks, Inc. v. F5 Networks, Inc., No. 3:10-CV-3365, Dkt. No. 93, 2012 WL 669861 (N.D. Cal. Feb. 29, 2012) (Illston, J.) ("F5 Networks I"). Defendants also submit that the '163 Patent was the subject of ex parte Reexamination No. 90/010,356 ("'163 ex parte Reexam") and inter partes Reexamination No. 95/000,659 ("'163 inter partes Reexam").
The patents-in-suit all resulted from continuations of the '163 Patent.
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with preliminary constructions with the aim of focusing the parties' arguments and facilitating discussion. Those preliminary constructions are noted below within the discussion for each term.
II. LEGAL PRINCIPLES
It is understood that "[a] claim in a patent provides the metes and bounds of the right which the patent confers on the patentee to exclude others from making, using or selling the protected invention." Burke, Inc. v. Bruno Indep. Living Aids, Inc., 183 F.3d 1334, 1340 (Fed. Cir. 1999). Claim construction is clearly an issue of law for the court to decide. Markman v. Westview Instruments, Inc., 52 F.3d 967, 970-71 (Fed. Cir. 1995) (en banc), aff'd, 517 U.S. 370 (1996).
"In some cases, however, the district court will need to look beyond the patent's intrinsic evidence and to consult extrinsic evidence in order to understand, for example, the background science or the meaning of a term in the relevant art during the relevant time period." Teva Pharms. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 841 (2015) (citation omitted). "In cases where those subsidiary facts are in dispute, courts will need to make subsidiary factual findings about that extrinsic evidence. These are the 'evidentiary underpinnings' of claim construction that we discussed in Markman, and this subsidiary factfinding must be reviewed for clear error on appeal." Id. (citing 517 U.S. 370).
To ascertain the meaning of claims, courts look to three primary sources: the claims, the specification, and the prosecution history. Markman, 52 F.3d at 979. The specification must contain a written description of the invention that enables one of ordinary skill in the art to make and use the invention. Id. A patent's claims must be read in view of the specification, of which they are a part. Id. For claim construction purposes, the description may act as a sort of dictionary, which explains the invention and may define terms used in the claims. Id. "One purpose for examining the specification is to determine if the patentee has limited the scope of the claims." Watts v. XL Sys., Inc., 232 F.3d 877, 882 (Fed. Cir. 2000).
Nonetheless, it is the function of the claims, not the specification, to set forth the limits of the patentee's invention. Otherwise, there would be no need for claims. SRI Int'l v. Matsushita Elec. Corp., 775 F.2d 1107, 1121 (Fed. Cir. 1985) (en banc). The patentee is free to be his own lexicographer, but any special definition given to a word must be clearly set forth in the specification. Intellicall, Inc. v. Phonometrics, Inc., 952 F.2d 1384, 1388 (Fed. Cir. 1992). Although the specification may indicate that certain embodiments are preferred, particular embodiments appearing in the specification will not be read into the claims when the claim language is broader than the embodiments. Electro Med. Sys., S.A. v. Cooper Life Sciences, Inc., 34 F.3d 1048, 1054 (Fed. Cir. 1994).
This Court's claim construction analysis is substantially guided by the Federal Circuit's decision in Phillips v. AWH Corporation, 415 F.3d 1303 (Fed. Cir. 2005) (en banc). In Phillips, the court set forth several guideposts that courts should follow when construing claims. In particular, the court reiterated that "the claims of a patent define the invention to which the patentee is entitled the right to exclude." Id. at 1312 (quoting Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). To that end, the words used in a claim are generally given their ordinary and customary meaning. Id. The ordinary and customary meaning of a claim term "is the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention, i.e., as of the effective filing date of the patent application." Id. at 1313. This principle of patent law flows naturally from the recognition that inventors are usually persons who are skilled in the field of the invention and that patents are addressed to, and intended to be read by, others skilled in the particular art. Id.
Despite the importance of claim terms, Phillips made clear that "the person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification." Id. Although the claims themselves may provide guidance as to the meaning of particular terms, those terms are part of "a fully integrated written instrument." Id. at 1315 (quoting Markman, 52 F.3d at 978). Thus, the Phillips court emphasized the specification as being the primary basis for construing the claims. Id. at 1314-17. As the Supreme Court stated long ago, "in case of doubt or ambiguity it is proper in all cases to refer back to the descriptive portions of the specification to aid in solving the doubt or in ascertaining the true intent and meaning of the language employed in the claims." Bates v. Coe, 98 U.S. 31, 38 (1878). In addressing the role of the specification, the Phillips court quoted with approval its earlier observations from Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998):
Ultimately, the interpretation to be given a term can only be determined and confirmed with a full understanding of what the inventors actually invented and intended to envelop with the claim. The construction that stays true to the claim
language and most naturally aligns with the patent's description of the invention will be, in the end, the correct construction.Phillips, 415 F.3d at 1316. Consequently, Phillips emphasized the important role the specification plays in the claim construction process.
The prosecution history also continues to play an important role in claim interpretation. Like the specification, the prosecution history helps to demonstrate how the inventor and the United States Patent and Trademark Office ("PTO") understood the patent. Id. at 1317. Because the file history, however, "represents an ongoing negotiation between the PTO and the applicant," it may lack the clarity of the specification and thus be less useful in claim construction proceedings. Id. Nevertheless, the prosecution history is intrinsic evidence that is relevant to the determination of how the inventor understood the invention and whether the inventor limited the invention during prosecution by narrowing the scope of the claims. Id.; see Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1350 (Fed. Cir. 2004) (noting that "a patentee's statements during prosecution, whether relied on by the examiner or not, are relevant to claim interpretation").
Phillips rejected any claim construction approach that sacrificed the intrinsic record in favor of extrinsic evidence, such as dictionary definitions or expert testimony. The en banc court condemned the suggestion made by Texas Digital Systems, Inc. v. Telegenix, Inc., 308 F.3d 1193 (Fed. Cir. 2002), that a court should discern the ordinary meaning of the claim terms (through dictionaries or otherwise) before resorting to the specification for certain limited purposes. Phillips, 415 F.3d at 1319-24. According to Phillips, reliance on dictionary definitions at the expense of the specification had the effect of "focus[ing] the inquiry on the abstract meaning of words rather than on the meaning of claim terms within the context of the patent." Id. at 1321. Phillips emphasized that the patent system is based on the proposition that the claims cover only the invented subject matter. Id.
Phillips does not preclude all uses of dictionaries in claim construction proceedings. Instead, the court assigned dictionaries a role subordinate to the intrinsic record. In doing so, the court emphasized that claim construction issues are not resolved by any magic formula. The court did not impose any particular sequence of steps for a court to follow when it considers disputed claim language. Id. at 1323-25. Rather, Phillips held that a court must attach the appropriate weight to the intrinsic sources offered in support of a proposed claim construction, bearing in mind the general rule that the claims measure the scope of the patent grant.
In general, prior claim construction proceedings involving the same patents-in-suit are "entitled to reasoned deference under the broad principals of stare decisis and the goals articulated by the Supreme Court in Markman, even though stare decisis may not be applicable per se." Maurice Mitchell Innovations, LP v. Intel Corp., No. 2:04-CV-450, 2006 WL 1751779, at *4 (E.D. Tex. June 21, 2006) (Davis, J.); see TQP Development, LLC v. Intuit Inc., No. 2:12-CV-180, 2014 WL 2810016, at *6 (E.D. Tex. June 20, 2014) (Bryson, J.) ("[P]revious claim constructions in cases involving the same patent are entitled to substantial weight, and the Court has determined that it will not depart from those constructions absent a strong reason for doing so."); see also Teva Pharm. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 839-40 (2015) ("prior cases will sometimes be binding because of issue preclusion and sometimes will serve as persuasive authority") (citation omitted); Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1329 (Fed. Cir. 2008) (noting "the importance of uniformity in the treatment of a given patent") (quoting Markman v. Westview Instruments, Inc., 517 U.S. 370, 390 (1996)).
III. AGREED TERMS
The parties have submitted the following agreed-upon construction (Dkt. No. 85, at p. 2 of 5; Dkt. No. 89, at 4), which the Court adopts:
| Term | Construction |
|---|---|
| "message" | "a collection of data that is related in some way, such as astream of video or audio data or an email message" |
IV. DISPUTED TERMS
A. "sequence of [two or more] routines"
Plaintiff previously proposed: "an ordered arrangement of [two or more] software routines that was not identified (i.e., configured) prior to receiving a first packet of the message." (Dkt. No. 85, Ex. A, at 1.)
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with the following preliminary construction: "an ordered arrangement of [two or more] software routines that was not configured before receiving a first packet of a message."
(1) The Parties' Positions
Plaintiff submits that the proper construction for this term has been thoroughly addressed in prior litigation and, moreover, "NetScout and Sandvine seek to limit the claims to an impossibility." (Dkt. No. 89, at 5.)
Defendants respond that "[t]his term is limited in scope by a disclaimer in the prosecution history." (Dkt. No. 93, at 1.) Defendants argue that "Implicit's interpretation of the F5 [Networks] II construction seeks to recapture the same claim scope it clearly and unambiguously disclaimed - i.e., selecting from pre-configured paths - and should not be adopted." (Id., at 5.) Defendants also submit that "Defendants are amenable to removing the word 'possible' from [their] proposal to remove any redundancy." (Id., at 10.)
Defendants have also cited Rule 30(b)(6) testimony by one of the named inventors (see Dkt. No. 93, Ex. 11, June 5, 2018 Balassanian dep. at 71:13-23, 72:12-73:10 & 74:6-77:5; see also id. at 47:13-48:18, 72:8-25 & 94:15-18), but this testimony does not significantly affect the Court's analysis in these claim construction proceedings. Cf. Howmedica Osteonics Corp. v. Wright Med. Tech., Inc., 540 F.3d 1337, 1346-47 (Fed. Cir. 2008) (noting that inventor testimony is "limited by the fact that an inventor understands the invention but may not understand the claims, which are typically drafted by the attorney prosecuting the patent application").
Plaintiff replies that "[f]our prior courts have limited the . . . disclaimer to only the single embodiment that stored pre-configured sequences of routines." (Dkt. No. 96, at 1.) Plaintiff also submits that "Implicit perceives no meaningful distinction between Defendants' use of the word 'selected' and the Court's use of the phrase 'identified (i.e., configured).'" (Id., at 2.) Plaintiff argues that "Defendants have cobbled together a construction that lacks clarity, results in impossible scenarios, and is internally inconsistent." (Id., at 3.)
At the April 11, 2019 hearing, Defendants expressed concern that the word "configured" in the Court's preliminary construction might be misinterpreted as allowing for identifying pre-existing paths. Plaintiff responded that the word "configured" is sufficiently clear, and Plaintiff argued that Defendants' concerns relate to questions of fact regarding infringement rather than any legal question for claim construction.
(2) Analysis
The Background section of the specification provides context by stating: "A computer system in certain situations . . . can be expected to receive data and to provide data in many different formats that may not be known until the data is received. The overhead of statically providing each possible series of conversion routines is very high." '683 Patent at 1:54-59. Claim 1 of the '683 Patent, for example, recites (emphasis added):
1. A first apparatus for receiving data from a second apparatus, the first apparatus comprising:
a processing unit; and
a memory storing instructions executable by the processing unit to:
create, based on an identification of information in a received packet of a message, a path that includes one or more data structures that indicate a sequence of routines for processing packets in the message;
store the created path; and
process subsequent packets in the message using the sequence of routines indicated in the stored path, wherein the sequence includes a routine that is used to execute a Transmission Control Protocol (TCP) to convert one or more packets having a TCP format into a different format.
In F5 Networks II, the Northern District of California construed "sequence of routines" to mean a "sequence of software routines that was not identified (i.e., configured) prior to receiving a first packet of the message." F5 Networks II at 17-24.
In Trend Micro, the Court construed "sequence of routines" to mean "an ordered arrangement of software routines that was not identified (i.e., configured) prior to receiving a first packet of the message" and similarly construed "sequence of two or more routines" to mean "an ordered arrangement of two or more software routines that was not identified (i.e., configured) prior to receiving a first packet of the message." Trend Micro at 13-20.
In Huawei, the parties there agreed that "sequence of [two or more] routines" means "an ordered arrangement of [two or more] software routines that was not identified (i.e., configured) prior to receiving a first packet of the message." Huawei at 8.
Those prior constructions focused on the patentee's statements regarding the "Mosberger" reference during reexamination of the '163 Patent. The parties here agree that the patentee's statements amount to a disclaimer, but the parties dispute how that disclaimer should be given effect in the Court's construction.
F5 Networks I and F5 Networks II identified the "Mosberger" reference as: "David Mosberger, 'Scout: A Path-Based Operating System,' Doctoral Dissertation Submitted to the University of Arizona." F5 Networks I at 3; F5 Networks II at 3.
In particular, the parties dispute the meaning of the phrase "identified (i.e., configured)" in the prior constructions. When distinguishing Mosberger, the patentee argued:
The following discussion of Mosberger will assist the Examiner in understanding the patentable distinctions, including those distinctions that arise because the Mosberger system configures paths (formed from a sequence of components) before receiving the "first packet of the message." As shown below, the quoted claim language is directed to a much different system that configures paths at run-time (i.e., after the first packet is received).
* * *
Because Mosberger teaches to configure paths that define the sequence of software modules used to process particular types of data prior to "build-time," the only decision made at runtime is the determination of which pre-configured path should begin processing the incoming data. Once the path is chosen, it is instantiated (what Mosberger refers to as "path creation"). The process of recognizing which preconfigured paths to use is illustrated in Figure 3.6 of Mosberger, reproduced below.
Image materials not available for display.
As seen in Figure 3.6 above (cited by the Examiner), there are a number of pathways (p1-p5) for the data to travel, but the selection of modules for each path is configured before receipt of the message packets. The beginning point for the
paths in this example is with the Ethernet module ("ETH"). The ETH module "employs a classifier to decide whether a packet should be processed using path p1, p2, or p3." (Mosberger, page 87). The only variation in Mosberger is which path through the predefined sequence will be taken. In this example, the ETH module selects the initial pathway (i.e., pathway p1, p2, or p3) based on the protocol header in the first packet of the message. (Mosberger, pages 88-89). If the protocol header is completely intact and suggests that the packet is UDP, then the packet classification process will result in the selection of pre-configured path 1. If, however, the packet has been fragmented by IP and does not include higher level headers, then the classification process will result in selection of pre-configured path 2. (Mosberger, page 87). At that point, after the packet has been reassembled, the IP module's packet classifier will determine whether the packet is a UDP or TCP packet and route the packet accordingly (i.e., down preconfigured path 4 or pre-configured path 5). (Mosberger, page 87). Importantly, however, those sequences of IP-UDP via pathway p4 and IP-TCP via pathway p5 have also been identified prior to run-time. In other words, the p2/p4 path and the p2/p5 path are pre-configured at build time. Again, the only question resolved at run time is which preconfigured path - with predetermined sequences of modules - should be selected.(Dkt. No. 93, Ex. 12, Sept. 1, 2009 Amendment and Response to Office Action Mailed July 7, 2009, at 11 & 14-15; see id. at 20 ("During operation (i.e., at 'run time'), Mosberger simply recognizes which of the predefined pathways will be used to process the data packets") & 28 ("a routing decision in Mosberger is merely a selection between multiple predefined pathways").)
* * *
As one skilled in the art will appreciate, the [Mosberger] pseudo-code shows that the possible list of software modules is already predetermined for the example module [i.e., software routine] and that the only choice for the example module is to select from amongst several possible pre-defined paths. Thus, dynamic routing, as described in the context of the 'paths' in Mosberger, is essentially a series of 'If...Then...' computer instructions coded into the modules at build time that control the selection of the predefined paths through a series of predefined software modules that a developer has arranged in a module graph in such a way as to ensure their interface compatibility.
In a subsequent Interview Summary, the patentee stated:
By selecting the sequence of components that form the path at build-time (i.e., before receiving a packet), Mosberger does exactly the opposite of what is claimed, namely, affirmatively selecting the sequence of components after receiving a packet. This is the difference between a dynamic system (the '163 invention) and
a static, inflexible system (Mosberger) that merely selects - at run-time - previously created paths. In response to a question by Examiner Ferris, lmplict's counsel pointed out that Mosberger's selection of pre-configured paths after receiving a packet is not covered by the claims because, by definition, Mosberger has already identified the sequence of components at that point, and therefore, does not perform the claimed "identifying" after receiving the packet.(Id., Ex. 14, Oct. 23, 2009 Interview Summary, at 3.)
The patentee later similarly stated:
Importantly, this set of paths is finite; Mosberger does not teach to create new paths after initialization. Further, this set of paths is created before any message/packet is received.(Id., Ex. 15, Feb. 8, 2019 Amendment, at 16 (citations omitted).)
* * *
Thus, paths in Mosberger are not dynamically created based on the receipt of a message. Rather, Mosberger teaches that when a message is received, a path is selected (or "found") from a set of possible paths, which were created and predefined before the message was even received.
During prosecution of the '683 Patent, the patentee likewise stated:
[T]his set of paths is finite; Mosberger does not teach creation of new paths after initialization.(Id., Ex. 13, June 6, 2013 Preliminary Amendment, at 11 & 12.)
* * *
. . . Mosberger teaches that when a message is received, a path is selected (or "found" or "picked") from a set of possible paths, which were created before the message was received.
The parties essentially agree as to the substantive effect of the patentee's statements regarding Mosberger. The patentee did not disclaim the existence of software routines prior to receiving a first packet of the message. The patentee explained that the claimed invention uses software routine arrangements that were not created prior to receiving a first packet of the message. The construction of "sequence of [two or more] routines" can be refined to avoid the potential confusion that might arise from the phrase "identified (i.e., configured)" and to more clearly reflect the patentee's statements regarding Mosberger. Although the specification frequently uses the words "identify," "identifies," and "identified," using the word "created" will more clearly reflect the patentee's statements regarding Mosberger and will be more readily understandable in the context of the claims.
See, e.g., '683 Patent at 4:15-17 ("The demux routine may in tu[rn] invoke the label map get routine 104 to identify a sequence of conversion routines for processing the packet.") (emphasis added); id. at 8:38-44 ("The routine loops identifying the next binding (edge and protocol) that is to process the message and 'nailing' the binding to a session for the message, if not already nailed."); id. at 10:42-51 ("If there is no next binding, then the routine invokes the routine label map get to identify the list of edges ('trails') that will map the output label to the target label.").
The Court therefore hereby construes "sequence of [two or more] routines" to mean "an ordered arrangement of [two or more] software routines that was not selected from a set of arrangements created before receiving a first packet of the message."
B. "list of conversion routines"
Plaintiff previously proposed: "an ordered arrangement of software routines for changing the form of data that was not identified (i.e., configured) prior to receiving a first packet of the message." (Dkt. No. 85, Ex. A, at 1.)
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with the following preliminary construction: "an ordered arrangement of software routines that is for changing the form of data and that was not configured before receiving a first packet of the message."
(1) The Parties' Positions
Plaintiff states that it "is willing to agree to the NetScout/Sandvine language 'software conversion routines.'" (Dkt. No. 89, at 8.) Plaintiff submits that the other disputes regarding this term will be resolved by construction of the "sequence of [two or more] routines" term addressed above. (Id.)
Defendants respond as to this term together with the term "sequence of [two or more] routines" (addressed above). (See Dkt. No. 93, at 1-11.)
(2) Analysis
The parties have presented substantially the same dispute for the term "list of conversion routines" as for the term "sequence of [two or more] routines," which is addressed above.
The Court therefore hereby construes "list of conversion routines" to mean "an ordered arrangement of software conversion routines that was not selected from a set of arrangements created before receiving a first packet of the message."
C. "state information"
Plaintiff previously proposed: "Plain and ordinary meaning. No construction necessary." (Dkt. No. 85, Ex. A, at 3.)
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with the following preliminary construction: "information specific to a software routine for a specific message that is not information related to an overall path."
(1) The Parties' Positions
Plaintiff argues that "[n]othing in the language of the claims themselves requires that state information be maintained for all packets of the message," and "the specification does not contain a definitional statement or clear intent to limit 'state information' to information maintained for all packets of the message." (Dkt. No. 89, at 9.) Further, Plaintiff argues that "[t]he prosecution history and extrinsic evidence identified by Defendants for their construction likewise fail to provide the clear and unmistakable support necessary to limit the claims as they suggest." (Id., at 10.)
Defendants respond that "the Court was not presented with Implicit's clear and unequivocal disclaimers from the '163 inter partes Reexam in [the Huawei] case." (Dkt. No. 93, at 23.)
Plaintiff replies that "none of the citations Defendants proffer as evidence of a 'clear and unequivocal' disclaimer expressly address whether state information must be maintained for all packets of the message." (Dkt. No. 96, at 4.)
(2) Analysis
Plaintiff proposes the construction that the Court reached in Huawei, which is the same as the construction reached in F5 Networks I. See Huawei at 16-23; see also F5 Networks I at 13-14.
Claim 1 of the '104 Patent, for example, recites (emphasis added):
1. An apparatus, comprising:
a processing unit; and
a memory storing instructions executable by the processing unit to:
The specification discloses:receive one or more packets of a message;
determine a key value using information in the one or more packets;
identify, using the key value, a sequence of two or more routines, wherein the sequence includes a routine that is used to execute a Transmission Control Protocol (TCP) to process packets having a TCP format;
create a path that includes one or more data structures that indicate the identified sequence of two or more routines, wherein the path is usable to store state information associated with the message; and
process subsequent packets in the message using the sequence of two or more routines indicated in the path.
[S]ince the conversion routines may need to retain state information between the receipt of one packet of a message and the next packet of that message, the conversion system maintains state information as an instance or session of the conversion routine. The conversion system routes all packets for a message through the same session of each conversion routine so that the same state or instance information can be used by all packets of the message.'683 Patent at 3:1-9 (emphasis added).
Likewise, during reexamination of the '163 Patent, the patentee cited similar disclosure in the '163 Patent and stated that "the specification is abundantly clear that all packets are required to form a message." (Dkt. No. 93, Ex. 20, Comments to ACP, at 18.) Further, again citing this disclosure, the patentee submitted that "state information is essential for a message-centric system that depends on state information being available for the processing of each packet in the message." (Id., at 13-14.) The patentee also explained that "[a] message-based technology fundamentally differs from a packet-based technology in that it is concerned with not just the processing of individual packets, but with the processing of a message as a whole, i.e., processing all the packets of the message." (Id., at 2 (emphasis modified); see id., at 10-11 ("using state information across the packets of a message") (emphasis omitted); see also id., at 11, 13-14 (contrasting "hard state" with "soft state"), 26-28 & 38-39.)
Defendants have not shown that handling all packets of a particular message necessarily requires maintaining state information "for" all packets of the message, which is what Defendants' proposed construction might be interpreted as requiring. That is, the above-cited evidence can be fairly read as relating to state information for a message but not necessarily state information specific to every packet of the message. (See, e.g., id., at 27 ("use message-specific state information for every packet of a message"); id., at 28 ("the '163 claims require per-message state that is persistent across the lifetime of an entire message—in other words, state that is collected and maintained for all packets of a message") & 38 ("collect, retain and apply state information from packet-to-packet for the entire message").) To whatever extent the specification can be read as disclosing such a feature, this disclosure relates to "one embodiment" and should not be imported into the claims. See '683 Patent at 3:7-9; see also id. at 2:45 ("in one embodiment").
Defendants have also cited Plaintiff's claim construction arguments in F5 Networks I. (See, e.g., Dkt. No. 93, Ex. 25, at 10 ("In flow-based processing, a 'session' is created to ensure that all packets of a flow are treated similarly.").) Even assuming that these statements are probative, Defendants have not shown that these statements are binding on Plaintiff in the present case. Defendants' reliance on these statements is unpersuasive.
At the April 11, 2019 hearing, Defendants urged that state information must be maintained in the sense that it cannot be "flushed" until all packets of a message have been processed. In addition to the above-cited evidence, Defendants emphasized the patentee's statements, during reexamination of the '163 Patent, regarding "hard state" and "soft state." Defendants argued that the patentee disclaimed "soft state" and explained that the claimed invention is limited to "hard state":
The message-specific claim limitations also highlight the type of state that the '163 Patent technology uses: hard state. Hard state is required for correct function and cannot be flushed randomly without regard to the processing of the entire message.
In other words, it is inextricably intertwined with the message and must be maintained for the duration of the entire message. If it is discarded before the entire message is processed, all mid-message processing would fall apart, and the system would be useless. In contrast, IP routers do not use this kind of hard state, since hard state is tied to the processing of entire messages and routers are not guaranteed to see all packets of entire messages. In short, because routers do not process entire messages, they also cannot use the hard state that is used to process entire messages. Instead, routers use soft state-state that can be discarded, regenerated or replaced as needed, as further explained below.(Dkt. No. 93, Ex. 20, Comments to ACP, at 11.)
The patentee thus distinguished routers, which can "discard[], regenerate[] or replace[]" the state because routers do not necessarily operate on entire messages. The patentee's statements in this regard are consistent with disclosure in the specification of the patents-in-suit that "the same state or instance information can be used by all packets of the message." '683 Patent at 3:1-9 (emphasis added).
The Court therefore hereby construes "state information" to mean "information that is specific to a software routine for a specific message, that can be used for all packets of the message, and that is not information related to an overall path."
D. "process subsequent packets in the message using the sequence of routines indicated in the stored path" and Related Terms
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
|---|---|
| "apply[ing] one or more routines to a packet,where at least one such routine is a conversionroutine" | These claim phrases do not include a systemthat avoids applying the same processing stepsto subsequent packets of a message. |
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with the following preliminary construction: "process/processing . . . packets" means "apply/applying one or more routines to a packet, where at least one such routine is a conversion routine."
At the April 11, 2019 hearing, the parties reached agreement that these terms should be given their plain meaning.
The Court therefore hereby construes "process subsequent packets in the message using the sequence of routines indicated in the stored path" ('683 Patent, Claim 1), "process subsequent packets of the message using sessions specified in the created path" ('683 Patent, Claim 10), "process subsequent packets of the message using the sequence of routines referenced by the one or more data structures" ('683 Patent, Claim 24), "process the one or more received packets using the sequence of routines indicated in the identified path" ('790 Patent, Claims 1, 15), "process the one or more received packets using the identified sequence of routines" ('790 Patent, Claim 8), "process subsequent packets in the message using the sequence of two or more routines indicated in the path" ('104 Patent, Claim 1), "process subsequent packets in the message using the identified sequence of two or more routines" ('104 Patent, Claim 10), and "processing . . . subsequent packets in the message using the particular sequence" ('104 Patent, Claim 16) to have their plain meaning.
E. "the packet of the message"
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
|---|---|
| Plain and ordinary meaning. No constructionnecessary.Alternatively, should the Court decide that thisterm should be construed:"the one or more received packets of themessage used to create a path" | "the received packet of the message that wasused to create the path" |
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with the following preliminary construction: "the one or more received message packets used to create a path."
(1) The Parties' Positions
Plaintiff "respectfully requests that the Court apply black letter to [sic] law to Claims 1 and 9 and hold that 'a received packet of a message' in Claim 1 and the 'the packet of the message' in Claim 9 (whose antecedent basis is Claim 1) includes 'one or more' packets of a message by virtue of Claim 1's use of the article 'a.'" (Dkt. No. 89, at 16.)
Defendants respond that "[f]or there to be a discernable point where 'subsequent packets' begins, there must be a singular packet of the message that was used to create the path." (Dkt. No. 93, at 26.)
Plaintiff replies that "[t]here is no need to limit the packet that creates the path to a single packet to know where in the transmission the 'subsequent packets' begin." (Dkt. No. 96, at 6.)
(2) Analysis
Claims 1, 8, and 9 of the '683 Patent recite (emphasis added):
1. A first apparatus for receiving data from a second apparatus, the first apparatus comprising:
a processing unit; and
a memory storing instructions executable by the processing unit to:
create, based on an identification of information in a received packet of a message, a path that includes one or more data structures that indicate a sequence of routines for processing packets in the message;
store the created path; and
process subsequent packets in the message using the sequence of routines indicated in the stored path, wherein the sequence includes a routine that is used to execute a Transmission Control Protocol (TCP) to convert one or more packets having a TCP format into a different format.
8. The first apparatus of claim 1, wherein the memory stores instructions executable by the processing unit to identify an address associated with the information, wherein the address indicates the routines in the sequence of routines of the created path.
9. The first apparatus of claim 8, wherein the memory stores instructions executable by the processing unit to use the address to select the sequence of routines from a plurality of sequences of routines that are stored by the first apparatus prior to receiving the packet of the message.
In Trend Micro, the Court construed "the packet of the message" to mean "the received packet of the message that was used to create the path." See Trend Micro at 24-27.
In the present case, the parties do not dispute the antecedent basis but rather dispute whether "the packet of the message" must be singular, that is, must be one single packet.
"[A]n indefinite article 'a' or 'an' in patent parlance carries the meaning of 'one or more' in open-ended claims containing the transitional phrase 'comprising.'" Convolve, Inc. v. Compaq Computer Corp., 812 F.3d 1313, 1321 (Fed. Cir. 2016) (citation and internal quotation marks omitted).
That "a" or "an" can mean "one or more" is best described as a rule, rather than merely as a presumption or even a convention. The exceptions to this rule are extremely limited: a patentee must evince[ ] a clear intent to limit "a" or "an" to "one." The subsequent use of definite articles "the" or "said" in a claim to refer back to the same claim term does not change the general plural rule, but simply reinvokes that non-singular meaning. An exception to the general rule that "a" or "an" means more than one only arises where the language of the claims themselves, the specification, or the prosecution history necessitate a departure from the rule.Baldwin Graphic Sys., Inc. v. Siebert, Inc., 512 F.3d 1338, 1342-43 (Fed. Cir. 2008) (citations and internal quotation marks omitted).
On balance, Defendants have failed to demonstrate that the claim language "necessitate[s] a departure from the rule." Id. at 1343. For example, Defendants have not persuasively supported their assertion that "[t]he structure of the claims require a singular packet that allows the system to create the 'path' such that 'subsequent packets' are processed using the created 'sequence of routines.'" (Dkt. No. 93, at 26.) Defendants' reliance on the analysis in Trend Micro, which did not address this issue, is unavailing. See Trend Micro at 26. The Court thus rejects Defendants' argument that "the packet" is limited to a single packet.
The Court therefore hereby construes "the packet of the message" to mean "the one or more received message packets used to create a path."
F. "convert one or more packets having a TCP format into a different format" and Related Terms
| "convert one or more packets having a TCP format into a different format"('683 Patent, Claim 1; '790 Patent, Claims 1, 15)"convert one of the packets of the message into a different format"('790 Patent, Claim 8) | |
|---|---|
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
| Plain and ordinary meaning. No constructionnecessary. | "convert the packet(s) outermost headerstructure from TCP to another type of headerstructure" |
| "convert one or more packets in a transport layer format into a different format"('683 Patent, Claim 10) | |
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
| Plain and ordinary meaning. No constructionnecessary. | "convert the packet(s) outermost headerstructure from a transport layer protocol headerto another type of header structure" |
| "convert packets of the different format into another format"('683 Patent, Claim 2; '790 Patent, Claim 3) | |
|---|---|
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
| Plain and ordinary meaning. No constructionnecessary. | "convert each packet's outermost headerstructure from the different protocol headerinto another type of header structure" |
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with the following preliminary constructions: "convert the outermost header structure of the packet(s) from TCP to another type of header structure"; "convert the outermost header structure of the packet(s) from a transport layer protocol header to another type of header structure"; and "convert each packet's outermost header structure from the different protocol header into another type of header structure."
(1) The Parties' Positions
Plaintiff argues that "[t]here is no requirement that the header of interest for a particular packet must be the 'outermost' header of the packet." (Dkt. No. 89, at 17.)
Defendants respond that "the 'format' of a packet is its outermost header structure." (Dkt. No. 93, at 11.) Defendants have cited disclosures in the specification as well as statements by the patentee during reexamination of the ancestor '163 Patent. (Id., at 11-12.)
Defendants have also cited Rule 30(b)(6) testimony by one of the named inventors (see Dkt. No. 93, Ex. 11, June 5, 2018 Balassanian dep. at 58:3-14; see also id., Ex. 22, May 31, 2012 Balassanian dep. at 298:19-22), but this testimony does not significantly affect the Court's analysis in these claim construction proceedings. Cf. Howmedica, 540 F.3d at 1346-47 (noting that inventor testimony is "limited by the fact that an inventor understands the invention but may not understand the claims, which are typically drafted by the attorney prosecuting the patent application").
Plaintiff replies that "the claims use the terms 'outermost header' and 'format' separately, and if the patentee wanted to limit converting a 'format' to converting the 'outermost header,' he knew how to do so, as in claim 20 [of the '683 Patent]." (Dkt. No. 96, at 8.)
(2) Analysis
Claim 1 of the '683 Patent, for example, recites (emphasis added):
1. A first apparatus for receiving data from a second apparatus, the first apparatus comprising:
a processing unit; and
a memory storing instructions executable by the processing unit to:
create, based on an identification of information in a received packet of a message, a path that includes one or more data structures that indicate a sequence of routines for processing packets in the message;
store the created path; and
process subsequent packets in the message using the sequence of routines indicated in the stored path, wherein the sequence includes a routine that is used to execute a Transmission Control Protocol (TCP) to convert one or more packets having a TCP format into a different format.
Plaintiff has noted that dependent Claim 20 of the '683 Patent recites "wherein the particular routine is executable to convert packets by removing an outermost header of the packets," but Claim 20 does not depend from any of the claims here at issue. Further, as Defendants have argued, Claim 20 is limited to removing an outermost header, as opposed to perhaps merely modifying an outermost header. Plaintiff's argument as to Claim 24 of the '683 Patent similarly fails. Plaintiff has not shown how Claim 20 or Claim 24 purportedly demonstrates that "format" is necessarily broader than the outermost header.
During inter partes reexamination of the '163 Patent, the patentee explained that the format of a packet is defined by its header structure: "Whether a packet is an IP format is determined by the structure of its header." (Dkt. No. 93, Ex. 20, Comments to ACP, at 12.) The patentee reinforced this principle by asserting that "[t]he format of the IP packet is not changed unless the actual structure of the header itself is changed from that shown in Figure 2 to a different type of header (e.g., a TCP header)." (Id., at 24; see id., at 12 (Fig. 2).) The patents-in-suit resulted from continuations of the '163 Patent, and these statements as to the meaning of "format," which is a term used extensively in the specification that is common to all of these patents, are probative as to the patents-in-suit. See, e.g., Alloc, Inc. v. Int'l Trade Comm'n, 342 F.3d 1361, 1372 (Fed. Cir. 2003).
During inter partes reexamination of related United States Patent No. 7,711,857, the patentee submitted an expert declaration opining that "only the structure of the outermost header determines whether the packet is an IPv4 packet or whether it employs some other protocol." (Id., Ex. 21, Ng Decl., at ¶ 6.) The '857 Patent, like the patents-in-suit, resulted from continuations of the '163 Patent, and this statement as to the meaning of "format" is probative as to the patents-in-suit. See Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1349-50 (Fed. Cir. 2004) (considering statements by patentee during prosecution of related patent); see also SightSound Techs., LLC v. Apple Inc., 809 F.3d 1307, 1316 (Fed. Cir. 2015).
Also, although Defendants have not shown or asserted that Plaintiff's positions in prior litigation are binding here, it is nonetheless noteworthy that Plaintiff stated in F5 Networks II that "[e]ach message packet can include different layers in different data formats" and, for example, "software routines associated with an Ethernet protocol will process the packet first, as the outermost layer of the packet is in an Ethernet format." (Dkt. No. 93, Ex. 18, F5 Networks II, Dkt. No. 43, Implicit's Patent Local Rule 4-5 Opening Claim Construction Brief, at 4-5.) Plaintiff thus evidently understood that the relevant "format" of a packet is determined by its outermost header.
Plaintiff has cited disclosure in the specification regarding advancing a reference past a header:
Although the conversion system has been described in terms of various embodiments, the invention is not limited to these embodiments. Modification within the spirit of the invention will be apparent to those skilled in the art. For example, a conversion routine may be used for routing a message and may perform no conversion of the message. Also, a reference to a single copy of the message can be passed to each conversion routine or demuxkey routine. These routines can advance the reference past the header information for the protocol so that the reference is positioned at the next header. After the demux process, the reference can be reset to point to the first header for processing by the conversion routines in sequence.'683 Patent at 14:4-16. This disclosure of "advanc[ing] the reference past the header information for the protocol so that the reference is positioned at the next header" suggests that a packet could be handled in a manner that is at least somewhat independent of its outermost header.
Yet, this disclosure relates to an operation that "may perform no conversion of the message." Id. Plaintiff has failed to demonstrate that anything in this disclosure is inconsistent with the patentee's understanding, as apparent in the above-discussed evidence, that the format of a packet is determined by its outermost header. To whatever extent Plaintiff contends that the terms "convert one or more packets having a TCP format into a different format," "convert one or more packets in a transport layer format into a different format," and "convert packets of the different format into another format" encompass merely moving a reference, the Court hereby expressly rejects any such interpretation as lacking support in the record.
For example, at least some of the prosecution history of the '683 Patent, cited by Defendants, implies that "converting" requires modifying headers:
Assuming arguendo that Decasper's plugins or flows correspond to the "sequence of routines" of claim 26 (which Applicant does not concede), Decasper does not teach or suggest that any of the plugins operates on "packets having a TCP format" let alone "convert[ing]" such packets "into a different format," as recited in that
claim. Rather, as discussed at length above, Decasper's packet classification scheme relies on IP headers remaining with packets throughout the IP core.(See Dkt. No. 93, Ex. 13, June 6, 2013 Preliminary Amendment, at 19 (emphasis added).)
Likewise, to whatever extent Plaintiff continues to rely on dependent Claim 20 of the '683 Patent (reciting "wherein the particular routine is executable to convert packets by removing an outermost header of the packets"), Plaintiff has not demonstrated the applicability of claim differentiation or any other relevant doctrine. See Wenger Mfg., Inc. v. Coating Mach. Sys., Inc., 239 F.3d 1225, 1233 (Fed. Cir. 2001) ("Claim differentiation, while often argued to be controlling when it does not apply, is clearly applicable when there is a dispute over whether a limitation found in a dependent claim should be read into an independent claim, and that limitation is the only meaningful difference between the two claims.") (emphasis added). Plaintiff has not demonstrated any inconsistency between Defendants' proposed constructions and the recitals of "format" in Claim 16 and "outermost header" in Claim 20.
Plaintiff argues that the Court in Huawei necessarily found that Claim 16 of the '683 Patent encompasses moving a reference. (Dkt. No. 96, at 8.) This argument fails. Huawei found that the limitation of "convert packets by removing an outermost header of the packets" in Claim 20 "involves modifying the packets rather than merely moving a reference" because Claim 16, from which Claim 20 depends, recites "convert packets from an input format to an output format." Huawei at 26. In other words, the Huawei analysis did not rely on claim differentiation, as Plaintiff has suggested here. (Dkt. No. 96, at 8.) Rather, Huawei read Claim 20 in light of the limitations recited in Claim 16 because Claim 20, as a dependent claim, includes all of the limitations of Claim 16. See Huawei at 26.
Finally, Defendants have submitted an extrinsic technical treatise that is consistent with their proposed constructions:
Layer 3 decides which of the outgoing lines to use and passes the packets to layer 2. Layer 2 adds not only a header to each piece, but also a trailer, and gives the resulting unit to layer 1 for physical transmission. At the receiving machine the message moves upward, from layer to layer, with headers being stripped off as it progresses. None of the headers for layers below n are passed up to layer n.(Dkt. No. 93, Ex. 23, Andrew S. Tanenbaum, Computer Networks 20 (3d ed. 1996).)
The Court therefore hereby construes the disputed terms as set forth in the following chart:
| Term | Construction |
|---|---|
| "convert one or more packets having a TCPformat into a different format"('683 Patent, Cl. 1; '790 Patent, Cls. 1, 15)"convert one of the packets of the messageinto a different format"('790 Patent, Cl. 8) | "convert the outermost header structure ofthe packet(s) from TCP to another type ofheader structure" |
| "convert one or more packets in a transportlayer format into a different format"('683 Patent, Cl. 10) | "convert the outermost header structure ofthe packet(s) from a transport layerprotocol header to another type of headerstructure" |
| "convert packets of the different formatinto another format"('683 Patent, Cl. 2; '790 Patent, Cl. 3) | "convert each packet's outermost headerstructure from the different protocol headerinto another type of header structure" |
G. "execute a Transmission Control Protocol (TCP)" and Related Terms
| "execute a Transmission Control Protocol (TCP)"('683 Patent, Claim 1; '790 Patent, Claim 1, 15)"executable to perform a Transmission Control Protocol (TCP)"('790 Patent, Claim 8) | |
|---|---|
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
| Plain and ordinary meaning. No constructionnecessary. | "operate on one or more packets whoseoutermost header is a TCP header at theendpoint of a connection" |
Defendants previously proposed: "'operate on [packets/at least one of the subsequent packets] whose outermost header is a TCP header at the endpoint of a connection to implement at least the minimum requirements of TCP as specified in RFC 793 at pp.44-50 (including the Open (causes a connection to be established), Send (causes data in a specified buffer to be sent on an indicated connection), Receive (allocates a receiving buffer associated with a specified connection), Close (causes a connection specified to be closed), and Abort (causes all pending send and received commands to be aborted) commands received from a user program)' / Alternatively, Indefinite." (Dkt. No. 85, Ex. B, at p. 26 of 35.)
Defendants previously proposed: "'operate on packets whose outermost header is an application-level protocol to perform the minimum requirements of the application-level protocol as specified in the RFC defining the application-level protocol' / Alternatively, Indefinite." (Dkt. No. 85, Ex. B, at pp. 26-27 of 35.)
Defendants previously proposed: "'operate on packets whose outermost header is a protocol different from the transport layer protocol to perform the minimum requirements of the different protocol as specified in the RFC defining the different protocol' / Alternatively, Indefinite." (Dkt. No. 85, Ex. B, at p. 27 of 35.)
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with preliminary constructions as set forth in the following chart:
| Term | Preliminary Construction |
|---|---|
| G.(1a) "execute a Transmission ControlProtocol (TCP)"('683 Pat., Cl. 1; '790 Pat., Cl. 1, 15) | "operate on one or more packets whoseoutermost header is a TCP header" |
| G.(1b) "executable to perform aTransmission Control Protocol (TCP)"('790 Pat., Cl. 8) | "operable on one or more packets whoseoutermost header is a TCP header" |
| G.(2) "execute a second, different protocol"('683 Pat., Cl. 2; '790 Pat., Cl. 3)"execute a third, different protocol"('683 Pat., Cl. 2) | "operate on packets whose outermost headeris a [second/third], different protocol header" |
| G.(3) "execute a Transmission ControlProtocol (TCP) to process packets having aTCP format"('104 Pat., Cls. 1, 16)"execute TCP to process at least one of thesubsequent packets having a TCP format"('104 Pat., Cl. 10) | "operate on one or more packets whoseoutermost header is a TCP header" |
| G.(4) "execute a second protocol to processpackets having a format other than the TCPformat, wherein the second protocol is anapplication-level protocol"('104 Pat., Cl. 3) | "execute a second protocol to operate onpackets whose outermost header is other thana TCP header, wherein the second protocol isan application-level protocol" |
| G.(5) "another session associated with adifferent protocol that is executed, whereinthe different protocol corresponds to thedifferent format"('683 Pat., Cl. 10) | Plain meaning |
(1) The Parties' Positions
Plaintiff argues that "a protocol typically refers to a set of rules or procedures for transmitting data between electronic devices, and that protocol may or may not be standardized in an RFC," and Plaintiff argues that the Court properly rejected arguments regarding "endpoint of a connection" in Huawei. (Dkt. No. 89, at 19 & 23.)
Defendants respond that "the overwhelming weight of the intrinsic and extrinsic evidence points to the same conclusion that these two concepts—outermost header being a TCP header and operation occurring at the endpoint of a connection—are precisely what it means to 'execute a TCP.'" (Dkt. No. 93, at 16.)
Defendants have also cited Rule 30(b)(6) testimony by one of the named inventors (see Dkt. No. 93, Ex. 11, June 5, 2018 Balassanian dep. at 162:11-164:1), but this testimony does not significantly affect the Court's analysis in these claim construction proceedings. Cf. Howmedica, 540 F.3d at 1346-47 (noting that inventor testimony is "limited by the fact that an inventor understands the invention but may not understand the claims, which are typically drafted by the attorney prosecuting the patent application").
Plaintiff replies that "[i]t is undisputed that the term 'endpoint' does not appear in the Patents," and "while a TCP connection may be between endpoints, the functionality of executing TCP to convert packets having a TCP format into a different format can happen at any device through which packets of the connection flow—not only the endpoints." (Dkt. No. 96, at 10.)
(2) Analysis
Claim 1 of the '683 Patent, for example, recites (emphasis added):
1. A first apparatus for receiving data from a second apparatus, the first apparatus comprising:
a processing unit; and
a memory storing instructions executable by the processing unit to:
create, based on an identification of information in a received packet of a message, a path that includes one or more data structures that indicate a sequence of routines for processing packets in the message;
store the created path; and
process subsequent packets in the message using the sequence of routines indicated in the stored path, wherein the sequence includes a routine that is used to execute a Transmission Control Protocol (TCP) to convert one or more packets having a TCP format into a different format.
First, the dispute as to Defendants' proposals that the "outermost header is a TCP header" presents substantially the same dispute that the parties have presented as to the terms "convert one or more packets having a TCP format into a different format," "convert one or more packets in a transport layer format into a different format," and "convert packets of the different format into another format," which are addressed above. As further support for the present disputed terms, Defendants also note the patentee's statements during prosecution of the '683 Patent. (See Dkt. No. 93, Ex. 13, June 6, 2013 Preliminary Amendment, at 19 n.4 ("executes the TCP protocol (i.e., operates on a packet whose outermost header is a TCP header)").)
Defendants have not shown, however, how their arguments in this regard are applicable to the final disputed term, namely "another session associated with a different protocol that is executed, wherein the different protocol corresponds to the different format" ('683 Patent, Claim 10). At the April 11, 2019 hearing, Defendants withdrew their proposed construction for this term. As set forth below, the Court construes this term to have its plain meaning.
Second, Defendants have failed to persuasively support their proposal of referring to an "endpoint of a connection." The parties agree that "Transmission Control Protocol" ("TCP") is a standard protocol for network communications. See Vizio, Inc. v. Int'l Trade Comm'n, 605 F.3d 1330, 1336-37 (Fed. Cir. 2010) (construing claims in light of the MPEG-2 digital television standard). Also, Defendants have submitted that the Background section of the specification frames the claimed invention in the context of "when data is generated on one computer system and is transmitted to another computer system to be displayed . . . ." '683 Patent at 1:27-29.
Yet, no "endpoint" limitation is recited or implied in the claim language, no disclosure in this regard appears in the specification, and Defendants have not demonstrated that Transmission Control Protocol (TCP) is relevant only at endpoints of a connection. Even the portions of the TCP standard cited by Defendants do not persuasively support Defendants' proposal of limiting the disputed terms to endpoints. (See Dkt. No. 93, Ex. 24, RFC 793, Transmission Control Protocol at § 1 ("The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks.") (emphasis added); see also id., Ex. 23, Andrew S. Tanenbaum, Computer Networks 521 (3d ed. 1996) ("TCP (Transmission Control Protocol) was specifically designed to provide a reliable end-to-end byte stream over an unreliable internetwork.") (emphasis added).)
(See id., at p. 80 (defining "host" as: "A computer. In particular a source or destination of messages from the point of view of the communication network.").)
Defendants have emphasized a statement by the patentee during prosecution of the '683 Patent that "it is well known that the Transmission Control Protocol (TCP) is implemented at the endpoints of a connection." (Dkt. No. 93, Ex. 13, June 6, 2013 Preliminary Amendment, at 19 n.4; see id., at 19; see also id., at 14 n.3 ("Decasper's EISR [(Extended Integrated Services Router)] architecture is not focused on communication 'end-systems' that implement protocols such as TCP.").) Also, during inter partes reexamination of the ancestor '163 Patent, the patentee stated that "the '163 Patent technology functions at the end-point level." (Id., Ex. 20, Comments to ACP, at 12.) These statements that TCP is implemented at endpoints, however, do not preclude TCP from functioning elsewhere. On balance, no relevant disclaimer is apparent as to the disputed terms, and to whatever extent an endpoint of a connection is necessitated by a particular limitation in a particular claim by virtue of using TCP, Defendants' proposal of "endpoint of a connection" is unnecessary.
The Court therefore hereby construes the disputed terms as set forth in the following chart:
| Term | Construction |
|---|---|
| "execute a Transmission Control Protocol(TCP)"('683 Patent, Cl. 1; '790 Patent, Cl. 1, 15) | "operate on one or more packets whoseoutermost header is a TCP header" |
| "executable to perform a TransmissionControl Protocol (TCP)"('790 Patent, Cl. 8) | "operable on one or more packets whoseoutermost header is a TCP header" |
| "execute a second, different protocol"('683 Patent, Cl. 2; '790 Patent, Cl. 3)"execute a third, different protocol"('683 Patent, Cl. 2) | "operate on packets whose outermostheader is a [second/third], different protocolheader" |
| "execute a Transmission Control Protocol(TCP) to process packets having a TCPformat"('104 Patent, Cls. 1, 16)"execute TCP to process at least one of thesubsequent packets having a TCP format"('104 Patent, Cl. 10) | "operate on one or more packets whoseoutermost header is a TCP header" |
|---|---|
| "execute a second protocol to processpackets having a format other than the TCPformat, wherein the second protocol is anapplication-level protocol"('104 Patent, Cl. 3) | "execute a second protocol to operate onpackets whose outermost header is otherthan a TCP header, wherein the secondprotocol is an application-level protocol" |
| "another session associated with a differentprotocol that is executed, wherein thedifferent protocol corresponds to thedifferent format"('683 Patent, Cl. 10) | Plain meaning |
V. CONCLUSION
The Court adopts the constructions set forth in this opinion for the disputed terms of the patents-in-suit, and in reaching conclusions the Court has considered extrinsic evidence. The Court's constructions thus include subsidiary findings of fact based upon the extrinsic evidence presented by the parties in these claim construction proceedings. See Teva, 135 S. Ct. at 841.
The parties are ordered that they may not refer, directly or indirectly, to each other's claim construction positions in the presence of the jury. Likewise, the parties are ordered to refrain from mentioning any portion of this opinion, other than the actual definitions adopted by the Court, in the presence of the jury. Any reference to claim construction proceedings is limited to informing the jury of the definitions adopted by the Court.
SIGNED this 15th day of April, 2019.
/s/_________
ROY S. PAYNE
UNITED STATES MAGISTRATE JUDGE