`
`THE UNITED STATES DISTRICT COURT
`FOR THE EASTERN DISTRICT OF TEXAS
`MARSHALL DIVISION
`
`
`
`
`
`
`PACKET INTELLIGENCE LLC,
`
`v.
`
`NETSCOUT SYSTEMS, INC., et al.
`
`
`
`
` CASE NO. 2:16-CV-230-JRG
`
`
`
`§
`§
`§
`§
`§
`§
`§
`
`CLAIM CONSTRUCTION
`MEMORANDUM AND ORDER
`
`Before the Court is Plaintiff Packet Intelligence LLC’s (“Plaintiff’s”) Opening Claim
`
`Construction Brief (Dkt. No. 55). Also before the Court are Defendants NetScout Systems, Inc.,
`
`Sandvine Corporation, and Sandvine Incorporated ULC’s (collectively, “Defendants’”) response
`
`(Dkt. No. 57) and Plaintiffs’ reply (Dkt. No. 58).
`
`The Court held a claim construction hearing on March 2, 2017.
`
`
`
`
`
`Table of Contents
`
`I. BACKGROUND ....................................................................................................................... 2
`
`II. LEGAL PRINCIPLES ............................................................................................................ 3
`
`III. AGREED TERMS................................................................................................................. 5
`
`IV. DISPUTED TERMS .............................................................................................................. 5
`
`A. “conversational flow[s]” and “conversational flow sequence” ............................................ 6
`
`B. “flow-entry database” ............................................................................................................ 7
`
`C. “parser record” .................................................................................................................... 10
`
`V. CONCLUSION...................................................................................................................... 16
`
`
`
`
`
`
`
`
`
`
`- 1 -
`
`NOAC Ex. 1020 Page 1
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 2 of 17 PageID #: 2252
`
`I. BACKGROUND
`
`
`
`Plaintiff brings suit alleging infringement of United States Patents No. 6,651,099 (“the
`
`’099 Patent”), 6,665,725 (“the ’725 Patent”), 6,771,646 (“the ’646 Patent”), 6,839,751 (“the ’751
`
`Patent”), and 6,954,789 (“the ’789 Patent”) (collectively, the “patents-in-suit,” which are also
`
`sometimes referred to as the “Asserted Patents”) (Dkt. No. 55, Exs. A–E). Plaintiff submits that
`
`the patents-in-suit “are generally directed to classifying and monitoring network traffic.” (Dkt.
`
`No. 55, at 1.)
`
`
`
`The ’099 Patent, for example, is titled “Method and Apparatus for Monitoring Traffic in a
`
`Network” and issued on November 18, 2003. The Abstract of the ’099 Patent states:
`
`A monitor for and a method of examining packets passing through a connection
`point on a computer network. Each packets [sic] conforms to one or more
`protocols. The method includes receiving a packet from a packet acquisition
`device and performing one or more parsing/extraction operations on the packet to
`create a parser record comprising a function of selected portions of the packet.
`The parsing/extraction operations depend on one or more of the protocols to
`which the packet conforms. The method further includes looking up a flow-entry
`database containing flow-entries for previously encountered conversational flows.
`The lookup uses the selected packet portions and determining [sic] if the packet is
`of an existing flow. If the packet is of an existing flow, the method classifies the
`packet as belonging to the found existing flow, and if the packet is of a new flow,
`the method stores a new flow-entry for the new flow in the flow-entry database,
`including identifying information for future packets to be identified with the new
`flow-entry. For the packet of an existing flow, the method updates the flow-entry
`of the existing flow. Such updating may include storing one or more statistical
`measures. Any stage of a flow, state is maintained, and the method performs any
`state processing for an identified state to further the process of identifying the
`flow. The method thus examines each and every packet passing through the
`connection point in real time until the application program associated with the
`conversational flow is determined.
`
`The patents-in-suit all claim priority to, and incorporate by reference, Provisional
`
`
`
`Application No. 60/141,903, filed on June 30, 1999. The applications that led to the ’099 Patent,
`
`the ’725 Patent, the ’646 Patent, and the ’751 Patent were all filed on June 30, 2000. The
`
`application that led to the ’789 Patent was filed on October 14, 2003, and the ’789 Patent is a
`
`
`
`
`- 2 -
`
`NOAC Ex. 1020 Page 2
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 3 of 17 PageID #: 2253
`
`continuation of the ’099 Patent. Plaintiff submits that “[t]he specifications of the Asserted
`
`Patents are similar . . . .” (Dkt. No. 55, at 6 n.4.) Also, the patents-in-suit filed on June 30, 2000,
`
`incorporate each other by reference. ’099 Patent at 1:11–36; ’724 Patent at 1:12–38; ’646 Patent
`
`at 1:12–33; ’751 Patent at 10:7–35. The Court therefore cites the specification of only the ’099
`
`Patent unless otherwise indicated.
`
`II. LEGAL PRINCIPLES
`
`
`
`This Court’s claim construction analysis is 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
`
`reiterated that “the claims of a patent define the invention to which the patentee is entitled the
`
`right to exclude.” 415 F.3d at 1312 (quoting Innova/Pure Water, Inc. v. Safari Water Filtration
`
`Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). “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.” Id. at 1316 (quoting Renishaw PLC v. Marposs Societa' per
`
`Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998)).
`
`In claim construction, patent claims are generally given their ordinary and customary
`
`meaning, which “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 1312-13. 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
`
`
`
`
`- 3 -
`
`NOAC Ex. 1020 Page 3
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 4 of 17 PageID #: 2254
`
`specification.” Id. The written description set forth in the specification, for example, “may act
`
`as a sort of dictionary, which explains the invention and may define terms used in the claims.”
`
`Markman, 52 F.3d at 979. Thus, as the Phillips court emphasized, the specification is “the
`
`primary basis for construing the claims.” Phillips, 415 F.3d at 1314–17. However, it is the
`
`claims, not the specification, which 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 prosecution history also plays an important role in claim interpretation as 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. Phillips, 415 F.3d at 1314–17; see also 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”). In this sense, 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 prosecution history,
`
`however, “represents an ongoing negotiation between the PTO and the applicant,” it may
`
`sometimes lack the clarity of the specification and thus be less useful in claim construction. Id.
`
`
`
`Courts are also permitted to rely on extrinsic evidence, such as “expert and inventor
`
`testimony, dictionaries, and learned treatises,” id. (quoting Markman, 52 F.3d at 980), but
`
`Phillips rejected any claim construction approach that sacrifices the intrinsic record in favor of
`
`extrinsic evidence. Id. at 1319. Instead, the court assigned extrinsic evidence, such as
`
`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 or particular sequence of steps.
`
`
`
`
`- 4 -
`
`NOAC Ex. 1020 Page 4
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 5 of 17 PageID #: 2255
`
`Id. at 1323–25. Rather, Phillips held that a court must attach the appropriate weight to the
`
`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 cases where . . . subsidiary facts are in
`
`dispute, courts will need to make subsidiary factual findings about [the] extrinsic evidence.
`
`These are the ‘evidentiary underpinnings’ of claim construction [discussed] in Markman, and
`
`this subsidiary factfinding must be reviewed for clear error on appeal.” Teva Pharm. USA, Inc.
`
`v. Sandoz, Inc., 135 S. Ct. 831, 841 (2015).
`
`III. AGREED TERMS
`
`
`
`In their December 9, 2016 Joint Claim Construction and Prehearing Statement (Dkt.
`
`No. 53, at 2) and their February 17, 2017 Joint Claim Construction Chart (Dkt. No. 59, at 4), the
`
`parties set forth their agreement as to the following term in the patents-in-suit:
`
`Term
`
`
`“child protocol”
`
`
`
`IV. DISPUTED TERMS
`
`Agreement
`
`“a protocol that is encapsulated within
`another protocol”
`
`
`
`
`The Court herein addresses the disputed terms in the order in which they have been
`
`presented in the Joint Claim Construction and Prehearing Statement and the Joint Claim
`
`Construction Chart filed by the parties. (Dkt. No. 53, at Exs. A & B; Dkt. No. 59.)
`
`
`
`The parties appear to agree that the disputed terms should have the same construction
`
`across all of the patents-in-suit. (See Dkt. No. 55, at 6; see also Omega Eng’g, Inc, v. Raytek
`
`Corp., 334 F.3d 1314, 1334 (Fed. Cir. 2003) (“we presume, unless otherwise compelled, that the
`
`same claim term in the same patent or related patents carries the same construed meaning”).)
`
`
`
`
`- 5 -
`
`NOAC Ex. 1020 Page 5
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 6 of 17 PageID #: 2256
`
`A. “conversational flow[s]” and “conversational flow sequence”
`
`Plaintiff’s Proposed Construction
`
`Defendants’ Proposed Construction
`
`“sequence of packets that are exchanged in
`any direction as a result of an application
`program activity that may involve more than
`one connection and more than one exchange
`of packets between a client and server related
`to a particular application program”
`
`“the sequence of packets that are exchanged
`in any direction as a result of an application
`program activity, where some such sequences
`of packets involve more than one connection”
`
`
`(Dkt. No. 53, Ex. A, at 1; id., Ex. B, at 2; Dkt. No. 55, at 20; Dkt. No. 57, at 2; Dkt. No. 59, at 2.)
`
`The parties submit that the term “conversational flow[s]” appears in Claim 1 of the ’099 Patent,
`
`Claims 10, 15, and 17 of the ’725 Patent, Claims 1, 7, and 16 of the ’646 Patent, Claims 1 and 17
`
`of the ’751 Patent, and Claims 1, 19, and 44 of the ’789 Patent. (Dkt. No. 53, Ex. A, at 1; id.,
`
`Ex. B, at 2.) The parties submit that the term “conversational flow sequence” appears in
`
`Claims 1 and 5 of the ’099 Patent and Claim 32 of the ’789 Patent. (Dkt. No. 53, Ex. A, at 1; id.,
`
`Ex. B, at 2.)
`
`
`
`At the March 2, 2017 hearing, the parties reached agreement that “conversational flow”
`
`and “conversational flow sequence” should be construed to mean “the sequence of packets
`
`that are exchanged in any direction as a result of an activity—for instance, the running of
`
`an application on a server as requested by a client—and where some conversational flows
`
`involve more than one connection, and some even involve more than one exchange of
`
`packets between a client and server.”
`
`
`
`
`- 6 -
`
`NOAC Ex. 1020 Page 6
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 7 of 17 PageID #: 2257
`
`B. “flow-entry database”
`
`Plaintiff’s Proposed Construction
`
`Defendants’ Proposed Construction
`
`No construction necessary. However, to the
`extent the Court determines a specific
`construction is warranted:
`“an organized electronic collection of
`flow entries”
`
`“a database configured to store entries that
`individually describe a previously
`encountered single connection flow and
`entries that individually describe a previously
`encountered flow involving more than one
`connection”
`
`
`(Dkt. No. 53, Ex. A, at 2; id., Ex. B, at 3; Dkt. No. 55, at 14; Dkt. No. 57, at 8; Dkt. No. 59, at 2–
`
`3.) The parties submit that this term appears in Claims 1, 3, and 6 of the ’099 Patent, Claim 15
`
`of the ’725 Patent, Claims 1, 7, 9, 16, and 19 of the ’646 Patent, Claims 1 and 17 of the ’751
`
`Patent, and Claims 1, 11, 19, 22, 33, and 44 of the ’789 Patent. (Dkt. No. 53, Ex. A, at 2; id.,
`
`Ex. B, at 3; Dkt. No. 55, at 14; Dkt. No. 59, at 2.)
`
`
`
`
`
`(1) The Parties’ Positions
`
`Plaintiff argues that “a ‘flow-entry database’ is simply an electronic collection of flow
`
`entries,” and “the claim language confirms [Plaintiff’s] interpretation of this disputed term.”
`
`(Dkt. No. 55, at 15 & 16.) Plaintiff also submits that “[t]he term ‘flow-entry database’ is never
`
`used to describe anything more than an electronic collection of individual flow entries.” (Id.,
`
`at 16.) Plaintiff concludes that “no specific construction is necessary because this term would be
`
`easily understood and applied by a jury.” (Id., at 17.) Further, Plaintiff argues, Defendants’
`
`proposed construction merely repeats the words of the disputed term while adding several
`
`unsupported limitations. (Id., at 17–18.)
`
`
`
`Defendants respond that this is “not a generic term,” and the term has no meaning apart
`
`from the patents-in-suit. (Dkt. No. 57, at 9.) Defendants also highlight that “every single
`
`independent claim involving this limitation recites that a flow-entry database includes flow
`
`entries for ‘previously encountered conversational flows.’” (Id.) Defendants conclude that
`
`
`
`
`- 7 -
`
`NOAC Ex. 1020 Page 7
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 8 of 17 PageID #: 2258
`
`“[a] database that is not configured to store conversational flow entries cannot possibly carry out
`
`the claimed inventions, and cannot possibly maintain consistency with the claim limitations in
`
`which this term resides.” (Id., at 11.)
`
`
`
`Plaintiff replies that “the Applicants specifically defined ‘flow’ as ‘a stream of packets
`
`being exchanged between any two addresses in a network.’” (Dkt. No. 58, at 5 (citing Dkt.
`
`No. 55, at 14; citing ’099 Patent at 12:4–5).) Plaintiff also argues that “[i]t is unclear what
`
`Defendants mean by ‘individually describe,’ nor did they cite support in the specification for
`
`such a requirement.” (Id., at 6.)
`
`
`
`At the March 2, 2017 hearing, Plaintiff argued that Defendants are improperly conflating
`
`the term “flow” with the term “conversational flow.” Plaintiff also argued that Defendants’
`
`proposal would require, without support, that each flow must be associated with only a single
`
`entry. Defendants responded that they would be amenable to removing the word “individually”
`
`from their proposed construction.
`
`
`
`
`
`
`
`(2) Analysis
`
`Claim 1 of the ’099 Patent, for example, recites in relevant part (emphasis added):
`
`. . .
`(d) a memory storing a flow-entry database including a plurality of flow-
`
`entries for conversational flows encountered by the monitor;
`
`(e) a lookup engine connected to the parser subsystem and to the flow-
`entry database, and configured to determine using at least some of the selected
`portions of the accepted packet if there is an entry in the flow-entry database for
`the conversational flow sequence of the accepted packet; . . . .
`
`Thus, the “flow” in the term “flow-entry database” can include “conversational flows.”
`
`As noted above, the parties have agreed upon a construction for “conversational flow.”
`
`
`
`Plaintiff argues that the claims themselves adequately explain the meaning of “flow-entry
`
`database.” Although above-quoted Claim 1 of the ’099 Patent, for example, recites that a “flow-
`
`
`
`
`- 8 -
`
`NOAC Ex. 1020 Page 8
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 9 of 17 PageID #: 2259
`
`entry database” includes a plurality of flow entries, Plaintiff has not shown that the claims
`
`sufficiently describe the meaning of “flow-entry.” (See Dkt. No. 55, at 18–19.) Further, Plaintiff
`
`has not shown that the recital of specific limitations, such as in dependent claims, necessarily
`
`precludes such limitations from being part of the meaning of the disputed term. See, e.g.,
`
`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). On balance, the Court rejects Plaintiff’s argument that “this term
`
`would be easily understood and applied by a jury.” (Dkt. No. 55, at 17.)
`
`
`
`As to the proper construction, the specification discloses that a “flow entry” is a database
`
`entry that describes a flow:
`
`A flow is a stream of packets being exchanged between any two addresses in the
`network.
`
` *
`
` * *
`
`
`
`The parser record is passed onto lookup process 314 which looks in an internal
`data store of records of known flows that the system has already encountered, and
`decides (in 316) whether or not this particular packet belongs to a known flow as
`indicated by the presence of a flow-entry matching this flow in a database of
`known flows 324. A record in database 324 is associated with each encountered
`flow.
`
` *
`
` * *
`
`
`The flow-entry database 324 stores flow-entries that include the unique flow-
`signature, state information, and extracted information from the packet for
`updating flows, and one or more statistical [sic] about the flow. Each entry
`completely describes a flow.
`
`’099 Patent at 12:4–5, 13:54–61 & 14:14–18 (emphasis added); see id. at 32:5–9 (“A new
`
`signature (i.e., a key) will be created and the creation of the server state (904) will be stored as an
`
`
`
`
`- 9 -
`
`NOAC Ex. 1020 Page 9
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 10 of 17 PageID #: 2260
`
`entry identified by the new signature in the flow-entry database. That signature now may be
`
`used to identify packets associated with the server.”); see also 3M Innovative Props. Co. v.
`
`Tredegar Corp., 725 F.3d 1315, 1321 (Fed. Cir. 2013) (“Idiosyncratic language, highly technical
`
`terms, or terms coined by the inventor are best understood by reference to the specification.”).
`
`
`
`As to Defendants’ proposal that the flow entries must “describe a previously encountered
`
`single connection flow” and “describe a previously encountered flow involving more than one
`
`connection,” Defendants themselves have submitted that “encountered” and “conversational
`
`flows” appear in surrounding claim language. (See Dkt. No. 57, at 9–10.) For example, above-
`
`quoted limitation (d) in Claim 1 of the ’099 Patent recites (emphasis added): “a memory storing a
`
`flow-entry database including a plurality of flow-entries for conversational flows encountered by
`
`the monitor.” Because such limitations are recited by other claim language, the Court hereby
`
`expressly rejects Defendants’ proposal to include such limitations as part of the construction of
`
`“flow-entry database.”
`
`
`
`Therefore, the Court construes “flow-entry database” to mean “a database configured
`
`to store entries, where each entry describes a flow.”
`
`C. “parser record”
`
`Plaintiff’s Proposed Construction
`
`Defendants’ Proposed Construction
`
`No construction necessary. However, to the
`extent the Court determines a specific
`construction is warranted:
`“information from a
`parsing/slicing/extraction operation”
`
`
`
`“a data structure containing a flow signature
`for a packet, a hash and at least parts of the
`packet’s payload for further processing”1
`
`
`1 Defendants previously proposed: “a data structure containing a flow signature for a packet and
`at least parts of the packet’s payload not used to build the signature.” (Dkt. No. 53, Ex. B, at 4.)
`
`
`
`
`- 10 -
`
`NOAC Ex. 1020 Page 10
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 11 of 17 PageID #: 2261
`
`(Dkt. No. 53, Ex. A, at 4; id., Ex. B, at 4; Dkt. No. 55, at 7; Dkt. No. 57, at 11; Dkt. No. 59, at 3.)
`
`The parties submit that this term appears in Claims 7 and 16 of the ’646 Patent and Claims 1, 17,
`
`19, 42, and 44 of the ’789 Patent. (Dkt. No. 53, Ex. A, at 4; id., Ex. B, at 4; Dkt. No. 55, at 7;
`
`Dkt. No. 59, at 3.)
`
`
`
`
`
`(1) The Parties’ Positions
`
`Plaintiff argues that “the claims themselves define the meaning of ‘parser record,’” and
`
`“none of these claims require that the parser record contain a ‘flow signature’ as Defendants
`
`propose.” (Dkt. No. 55, at 10.) Also, Plaintiff argues that Defendants’ proposed phrase “flow
`
`signature” is unclear. (Id., at 12.) Plaintiff further argues, as to Defendants’ previously proposed
`
`construction, that “there is nothing in the claim language supporting Defendants’ ‘parts of a
`
`packet payload not used to build a signature’ limitation.” (Id., at 13.)
`
`
`
`Defendants respond that this is a “coined term” and that there is no evidence that this
`
`term has any meaning outside of the patents-in-suit, and Defendants argue that their proposed
`
`construction “gives the term the meaning attributed to it by the Asserted Patents.” (Dkt. No. 57,
`
`at 12.) Defendants also submit that “the specification explains what a flow signature is and how
`
`it is built, and it also explains what a hash is and how it is generated.” (Id., at 14.) Finally,
`
`Defendants argue that “[t]he alternative construction proposed by Plaintiff is actually
`
`inconsistent with the specification, because a ‘parser record’ is not simply information that has
`
`been parsed, sliced or extracted from a packet.” (Id., at 16.)
`
`
`
`Plaintiff replies that Defendants’ proposal imports limitations from a preferred
`
`embodiment. (Dkt. No. 58, at 2.)
`
`
`
`
`- 11 -
`
`NOAC Ex. 1020 Page 11
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 12 of 17 PageID #: 2262
`
`
`
`
`
`(2) Analysis
`
`The specification refers to a “parser record” that has “data from [a] packet” and that
`
`includes a “signature”:
`
`These extraction operations (in the form of commands and associated parameters)
`are passed to the extraction process 306 implemented by an extracting and
`information identifying (EII) engine that extracts selected parts of the packet,
`including identifying information from the packet as required for recognizing this
`packet as part of a flow. The extracted information is put in sequence and then
`processed in block 312 to build a unique flow signature (also called a
`“key”) for this flow. A flow signature depends on the protocols used in the
`packet. For some protocols, the extracted components may include source and
`destination addresses. For example, Ethernet frames have end-point addresses
`that are useful in building a better flow signature. Thus, the signature typically
`includes the client and server address pairs. The signature is used to recognize
`further packets that are or may be part of this flow.
`
`In the preferred embodiment, the building of the flow key includes generating a
`hash of the signature using a hash function. The purpose if [sic] using such a
`hash is conventional—to spread flow-entries identified by the signature across a
`database for efficient searching. The hash generated is preferably based on a
`hashing algorithm and such hash generation is known to those in the art.
`
`In one embodiment, the parser passes data from the packet—a parser record—
`that includes the signature (i.e., selected portions of the packet), the hash, and the
`packet itself to allow for any state processing that requires further data from the
`packet. An improved embodiment of the parser subsystem might generate a
`parser record that has some predefined structure and that includes the signature,
`the hash, some flags related to some of the fields in the parser record, and parts of
`the packet’s payload that the parser subsystem has determined might be required
`for further processing, e.g., for state processing.
`
`’099 Patent at 13:14–47; see id. at 20:16–18 (“The process starts at 801 from FIG. 7 with the
`
`parser record that includes a signature, the hash and at least parts of the payload.”); see also id.
`
`at 16:21–28 (“a short-cut recognition pattern—a signature”).
`
`
`
`These disclosures of a “signature,” a “hash,” and “parts of the packet’s payload,”
`
`however, are specific features of particular embodiments that should not be imported into the
`
`claims. See Phillips, 415 F.3d at 1323 (“although the specification often describes very specific
`
`
`
`
`- 12 -
`
`NOAC Ex. 1020 Page 12
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 13 of 17 PageID #: 2263
`
`embodiments of the invention, we have repeatedly warned against confining the claims to those
`
`embodiments”). The disclosure of a “hash” being used “[i]n the preferred embodiment” is
`
`consistent with disclosing that a hash is optional.
`
`
`
`Defendants urged at the March 2, 2017 hearing that Defendants’ proposed construction is
`
`supported by consistent disclosure in the specification. In some circumstances, consistent usage
`
`of a term in the specification “can inform the proper construction of that term.” Wi-LAN USA,
`
`Inc. v. Apple Inc., 830 F.3d 1374, 1382 (Fed. Cir. 2016); see also Nystrom v. TREX Co., 424 F.3d
`
`1136, 1144 (Fed. Cir. 2005). Here, however, the specification discusses a “parser record”
`
`primarily in terms of the purpose that it serves rather than the content that must be stored in the
`
`record:
`
`The parser record is passed onto lookup process 314 which looks in an internal
`data store of records of known flows that the system has already encountered, and
`decides (in 316) whether or not this particular packet belongs to a known flow as
`indicated by the presence of a flow-entry matching this flow in a database of
`known flows 324. A record in database 324 is associated with each encountered
`flow.
`
`’099 Patent at 13:53–60. Further, although Defendants have argued that all of the disclosed
`
`parser records include at least a signature, a hash, and at least portions of the payload, differences
`
`between the various disclosed parser records are noteworthy. For example, whereas some parser
`
`records are disclosed as containing entire packets (and thus entire payloads), some are disclosed
`
`as containing only portions of payloads. See id. at 13:37–47. Likewise, whereas some parser
`
`records are disclosed as containing flags, others are not. See id.
`
`
`
`On balance, surrounding claim language sufficiently explains the meaning of “parser
`
`record.” Claim 7 of the ’646 Patent, for example, recites (emphasis added):
`
`7. A packet monitor for examining packet[s] passing through a connection point
`on a computer network, each packet[] conforming to one or more protocols, the
`monitor comprising:
`
`
`
`
`- 13 -
`
`NOAC Ex. 1020 Page 13
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 14 of 17 PageID #: 2264
`
`a packet acquisition device coupled to the connection point and configured
`
`to receive packets passing through the connection point;
`
`an input buffer memory coupled to and configured to accept a packet from
`the packet acquisition device;
`a parser subsystem coupled to the input buffer memory, the parsing
`
`subsystem configured to extract selected portions of the accepted packet and to
`output a parser record containing the selected portions;
`
`a memory [for] storing a database of one or more flow-entries for any
`previously encountered conversational flows, each flow-entry identified by
`identifying information stored in the flow-entry;
`
`a lookup engine coupled to the output of the parser subsystem and to the
`flow-entry memory and configured to lookup whether the particular packet whose
`parser record is output by the parser subsystem has a matching flow-entry, the
`looking up using at least some of the selected packet portions and determining if
`the packet is of an existing flow;
`
`a cache subsystem coupled to and between the lookup engine and the
`flow-entry database memory providing for fast access of a set of likely-to-be-
`accessed flow-entries from the flow-entry database; and
`
`a flow insertion engine coupled to the flow-entry memory and to the
`lookup engine and configured to create a flow-entry in the flow-entry database,
`the flow-entry including identifying information for future packets to be identified
`with the new flow-entry,
`
`the lookup engine configured such that if the packet is of an existing flow,
`the monitor classifies the packet as belonging to the found existing flow; and if
`the packet is of a new flow, the flow insertion engine stores a new flow-entry for
`the new flow in the flow-entry database, including identifying information for
`future packets to be identified with the new flow-entry,
`
`wherein the operation of the parser subsystem depends on one or more of
`the protocols to which the packet conforms.
`
`Claim 16 of the ’646 Patent likewise recites, in relevant part (emphasis added):
`
`. . .
`(b) performing one or more parsing/extraction operations on the packet to create a
`parser record comprising a function of selected portions of the packet; . . . .
`
`Claims 1, 17, 19, 42, and 44 of the ’789 Patent are similar. For example, Claim 19 of the
`
`
`
`’789 Patent recites in relevant part (emphasis added):
`
`. . .
`(c) a parser subsystem coupled to the input buffer memory and including a slicer,
`the parsing subsystem configured to extract selected portions of the accepted
`packet and to output a parser record containing the selected portions; . . . .
`
`
`
`
`
`- 14 -
`
`NOAC Ex. 1020 Page 14
`
`
`
`Case 2:16-cv-00230-JRG Document 66 Filed 03/15/17 Page 15 of 17 PageID #: 2265
`
`
`
`Thus, surrounding claim language, such as set forth above, sufficiently explains the
`
`meaning of “parser record” as used in the claims in which “parser record” appears.
`
`
`
`As to Defendants’ proposal of “signature,” Plaintiff has also argued claim differentiation
`
`as to Claim 18 of the ’646 Patent and Claims 6 and 48 of the ’789 Patent. Claim 18 of the ’646
`
`Patent, for example, recites (emphasis added):
`
`18. A method according to claim 16, wherein the function of the selected portions
`of the packet forms a signature that includes the selected packet portions and that
`can identify future packets, wherein the lookup operation uses the signature and
`wherein the identifying information stored in the new or updated flow-entry is a
`signature for identifying future packets.
`
`Although Claim 18 thus recites more than merely a “signature,” see Wenger, 239 F.3d
`
`
`
`at 1233 (quoted above), it is noteworthy that a “signature” limitation is recited in this dependent
`
`claim rather than in independent Claim 16. See Phillips, 415 F.3d at 1315 (“the presence of a
`
`dependent claim that adds a particular limitation gives rise to a presumption that the limitation in
`
`question is not present in the independent claim”). Similarly, Plaintiff has argued claim
`
`differentiation as to “hash,” such as in dependent Claim 9 of the ’646 Patent and dependent
`
`Claim 22 of the ’78