Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 1 of 38 PageID #: 3451
`
`IN THE UNITED STATES DISTRICT COURT
`FOR THE EASTERN DISTRICT OF TEXAS
`MARSHALL DIVISION
`
`
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`
`
`
`Civil Action No. 2:14-cv-252-JRG
`
`
`Jury Trial Requested
`
`Plaintiff,
`
`
`
`v.
`
`
`PACKET INTELLIGENCE LLC,
`
`
`
`
`
`CISCO SYSTEMS, INC.,
`
`
`
`
`
`Defendant.
`
`PACKET INTELLIGENCE LLC’S
`OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`
`
`
`
`
`EX 1078 Page 1
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 2 of 38 PageID #: 3452
`
`
`
`
`
`TABLE OF CONTENTS
`
`I.
`
`Introduction and Overview of Patented Technology .......................................................... 1
`
`II. Legal Principles of Claim Construction .............................................................................. 1
`
`III. Terms for Construction Without MPF Proposals ............................................................... 1
`
`A.
`
`“conversational flow” and “conversational flow sequence” (Ex. L, Terms 5, 6) ......... 1
`
`B.
`
`“child protocol” (Ex. L, Term 4) .................................................................................. 3
`
`C.
`
`“parser record” (Ex. L, Term 15) ................................................................................. 5
`
`D.
`
`“flow entry” (Ex. L, Term 7) ........................................................................................ 7
`
`E.
`
`“none or more” (Ex. L, Term 13) ............................................................................... 10
`
`IV. Terms for Construction With MPF Proposals .................................................................. 11
`
`A.
`
`“parser subsystem” (Ex. L, Term 16) ......................................................................... 12
`
`B.
`
`“analyzer subsystem” (Ex. L, Term 3) ....................................................................... 15
`
`C.
`
`“lookup engine” (Ex. L, Term 11) .............................................................................. 18
`
`D.
`
`“flow insertion engine” (Ex. L, Term 8) .................................................................... 20
`
`E.
`
`F.
`
`“protocol/state identification mechanism” (Ex. L, Term 18) ..................................... 22
`
`“mechanism of building a hash” (Ex. L, Term 12) .................................................... 24
`
`V. Cisco’s Additional Terms Proposed for Construction ...................................................... 25
`
`A.
`
`“packet monitor” (Ex. L, Term 14) ............................................................................ 26
`
`B.
`
`C.
`
`D.
`
`E.
`
`“A method of examining packets passing through a connection point on a
`computer network” (Ex. L, Term 2) ...................................................................... 28
`
`“A method for analyzing a flow of packets passing through a connection point on
`a computer network” (Ex. L, Term 1) ................................................................... 28
`
`“performing one or more parsing/extraction operations on the packet to create a
`parser record comprising a function of selected portions of the packet” (Ex.
`L, Term 17) ........................................................................................................... 28
`
`“looking up a flow-entry database comprising none or more flow-entries for
`previously encountered conversational flows, the looking up using at least
`some of the selected packet portions and determining if the packet is of an
`
`i
`
`EX 1078 Page 2
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 3 of 38 PageID #: 3453
`
`
`
`
`
`
`
`
`
`existing flow” / looking up a flow-entry database for containing one or more
`flow-entries for previously encountered conversational flows, the looking up
`to determine if the received packet is of an existing flow” (Ex. L, Terms 9,
`10) ......................................................................................................................... 30
`
`VI. Conclusion ........................................................................................................................ 30
`
`
`
`ii
`
`EX 1078 Page 3
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 4 of 38 PageID #: 3454
`
`
`
`Cases
`
`TABLE OF AUTHORITIES
`
`Allen Eng’g v. Bartell Indus.,
` 299 F.3d 1336 (Fed. Cir. 2002) ............................................................................................... 26
`
`Altiris, Inc. v. Symantec Corp.,
` 318 F.3d 1363 (Fed. Cir. 2003) ......................................................................................... 26, 28
`
`Apex Inc. v. Raritan Comp., Inc.,
` 325 F.3d 1364 (Fed. Cir. 2003) ............................................................................................... 12
`
`Apple Inc. v. Motorola, Inc.,
` 757 F.3d 1286 (Fed. Cir. 2014) ................................................................................... 11, 12, 14
`
`Aspex Eyewear, Inc. v. Marchon Eyewear, Inc.,
` 672 F.3d 1335 (Fed. Cir. 2012) ................................................................................................. 7
`
`Cardiac Pacemakers, Inc. v. St. Jude Med., Inc.,
` 381 F.3d 1371 (Fed. Cir. 2004) ......................................................................................... 29, 30
`
`CollegeNet, Inc. v. ApplyYourself, Inc.,
` 418 F.3d 1225 (Fed. Cir. 2005) ................................................................................................. 9
`
`Finisar Corp. v. DirecTV Grp., Inc.,
` 523 F.3d 1323 (Fed. Cir. 2008) ............................................................................................... 14
`
`Intervet Inc. v. Merial Ltd.,
` 617 F.3d 1282 (Fed. Cir. 2010) ................................................................................................. 2
`
`Libel-Flarsheim Co. v. Medrad, Inc.,
` 358 F.3d 898 (Fed. Cir. 2004) ................................................................................................... 9
`
`Lighting World, Inc. v. Birchwood Lighting, Inc.,
` 382 F.3d 1354 (Fed. Cir. 2004) ............................................................................. 11, 12, 14, 22
`
`Masco Corp. v. United States,
` 303 F.3d 1316 (Fed. Cir. 2002) ......................................................................................... 29, 30
`
`Micro Chem., Inc. v. Great Plains Chem. Co.,
` 194 F.3d 1250 (Fed. Cir. 1999) ......................................................................................... 15, 22
`
`Mobilemedia Ideas LLC v. HTC Corp.,
` No. 2:10-cv-112 (E.D. Tex. Dec. 12, 2012) .............................................................................. 1
`
`Nautilus, Inc. v. Biosig Instruments, Inc.,
` 134 S. Ct. 2120 (2014) ............................................................................................................. 10
`
`
`
`iii
`
`EX 1078 Page 4
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 5 of 38 PageID #: 3455
`
`
`
`Ne. Univ. v. Google, Inc.,
` 2010 U.S. Dist. LEXIS 118977 (E.D. Tex. Nov. 9, 2010) ...................................................... 25
`
`Personalized Media Communs., LLC v. ITC,
` 161 F.3d 696 (Fed. Cir. 1998) ........................................................................................... 13, 25
`
`Phillips v. AWH Corp.,
` 415 F.3d 1303 (Fed. Cir. 2005) (en banc) ......................................................................... 1, 7, 9
`
`SciMed Life Sys. v. Advanced Cardiovascular Sys.,
` 242 F.3d 1337 (Fed. Cir. 2001) ................................................................................................. 6
`
`Teleflex, Inc. v. Ficosa N. Am. Corp.,
` 299 F.3d 1313 (Fed. Cir. 2002) ............................................................................................... 26
`
`Teva Pharm. USA, Inc. v. Sandoz, Inc.,
` No. 13-854 (S. Ct. Jan. 20, 2015) .............................................................................................. 1
`
`Toro Co. v. Textron, Inc.,
` 502 F. Supp. 2d 904 (D. Minn. 2007) ................................................................................ 15, 22
`
`Typhoon Touch Techs., Inc. v. Dell, Inc.,
` 659 F.3d 1376 (Fed. Cir. 2011) ............................................................................................... 14
`
`Vitronics Corp. v. Conceptronic,
` 90 F.3d 1576 (Fed. Cir. 1996) ................................................................................................... 9
`
`Widevine Techs., Inc. v. Verimatrix, Inc.,
` 2009 U.S. Dist. LEXIS 102768 (E.D. Tex. Nov. 4, 2009) ...................................................... 17
`
`Williamson v. Citrix Online, LLC,
` 770 F.3d 1371 (Fed. Cir. 2014) ........................................................................................ passim
`
`Young v. Lumenis, Inc.,
` 492 F.3d 1336 (Fed. Cir. 2007) ............................................................................................... 10
`
`Statutes
`
`35 U.S.C. § 112(f) ......................................................................................................................... 11
`
`
`
`
`
`
`
`iv
`
`EX 1078 Page 5
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 6 of 38 PageID #: 3456
`
`
`
`I. INTRODUCTION AND OVERVIEW OF PATENTED TECHNOLOGY
`
`The instant case involves five related patents: U.S. Patent Nos. 6,651,099 (“the ‘099
`
`Patent”) (attached as Ex. A); 6,665,725 (“the ‘725 Patent”) (attached as Ex. B); 6,771,646 (“the
`
`‘646 Patent”) (attached as Ex. C); 6,839,751 (“the ‘751 Patent”) (attached as Ex. D); and
`
`6,954,789 (“the ‘789 Patent”) (attached as Ex. E) (collectively “the Patents-in-Suit”).1 Each of
`
`the patents claims priority to and incorporates by reference Provisional Application No.
`
`60/141,903 (“Provisional”), and thus the Provisional forms part of the intrinsic evidence. The
`
`Patents-in-Suit are generally directed to classifying and monitoring network traffic. Traffic
`
`classification involves detecting the underlying protocols being used as well as the applications
`
`or user activity responsible for generating the network traffic. Traffic monitoring involves
`
`tracking the state of the underlying protocols along with relevant network traffic statistics. Such
`
`classification and monitoring provide network administrators with detailed information about
`
`their networks that can be used to diagnose network problems, control bandwidth allocation, and
`
`ensure an appropriate quality of service for users.
`
`II. LEGAL PRINCIPLES OF CLAIM CONSTRUCTION
`
`This Court is very familiar with the general tenets of claim construction, which we do not
`
`repeat here. See Mobilemedia Ideas LLC v. HTC Corp., No. 2:10-cv-112, at 7-13 (E.D. Tex. Dec.
`
`12, 2012); Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc); Teva Pharm. USA,
`
`Inc. v. Sandoz, Inc., No. 13-854, slip op. at 7 (S. Ct. Jan. 20, 2015) (claim construction may
`
`involve subsidiary fact-findings based on extrinsic evidence).
`
`III. TERMS FOR CONSTRUCTION WITHOUT MPF PROPOSALS2
`
`A. “conversational flow” and “conversational flow sequence” (Ex. L, Terms 5, 6)
`
`Packet’s Proposal
`that are
`sequence of packets
`“the
`exchanged in any direction as a result of an
`
`Cisco’s Proposal
`“the sequence of packets that are exchanged in any
`direction as a result of an application program
`
`
`1 The specifications of the Patents-in-Suit are similar. Generally throughout this brief, the patent
`that includes the claims at issue for a given term is cited.
`2 Exhibit L includes a table with the parties’ claim construction positions for all disputed terms.
`Exhibit K includes a list of agreed constructions.
`
`
`
`
`
`- 1 -
`
`
`
`EX 1078 Page 6
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 7 of 38 PageID #: 3457
`
`
`
`that may
`application program activity
`involve more than one connection and
`more than one exchange of packets related
`to a particular application program”
`
`
`activity and are recognized as belonging to the
`same flow, even if they involve more than one
`connection and more than one exchange of packets
`related to a particular application program”
`
`Coined terms like conversational flow “are best understood by reference to the
`
`specification.” Intervet Inc. v. Merial Ltd., 617 F.3d 1282, 1287 (Fed. Cir. 2010). The
`
`specification defines “conversational flow” as:
`
`Some prior art packet monitors classify packets into connection flows. The term
`“connection flow” is commonly used to describe all the packets involved with a
`single connection. A conversational flow, on the other hand, is 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. It is
`desirable to be able to identify and classify conversational flows rather than only
`connection flows. The reason for this is that some conversational flows involve
`more than one connection, and some even involve more than one exchange of
`packets between a client and server. This is particularly true when using
`client/server protocols such as RPC, DCOMP, and SAP, which enable a service to
`be set up or defined prior to any use of that service.
`
`‘099 Patent at 2:34-48 (emphases added); ‘789 Patent at 2:42-56; see also Provisional at 3:3-12
`
`(including a nearly identical statement). The parties’ proposals generally incorporate the
`
`language emphasized above. Cisco, however, adds to this definitional statement the limitation
`
`“and are recognized as belonging to the same flow.” The sole dispute is whether Cisco’s
`
`additional requirement should be incorporated into the construction of this term. It should not.
`
`It is not disputed that a conversational flow includes a “sequence of packets that are
`
`exchanged in any direction as a result of an application program activity.” To further require that
`
`the sequence of packets “[is] recognized as belonging to the same flow,” as Cisco proposes, is
`
`almost nonsensical. There are three potential interpretations of the “flow” recited in Cisco’s
`
`proposed construction, and in each instance, the resulting construction should be rejected. The
`
`three possible interpretations are that the “flow” is (1) a conversational flow; (2) a connection
`
`flow; or (3) some other flow.
`
`If the recited flow is a “conversational flow”, the proposed construction reads as follows:
`
`the sequence of packets that are exchanged in any direction as a result of an
`application program activity and are recognized as belonging to the same
`
`
`
`
`
`- 2 -
`
`
`
`EX 1078 Page 7
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 8 of 38 PageID #: 3458
`
`
`
`[conversational flow], even if they involve more than one connection and more
`than one exchange of packets related to a particular application program
`
`This interpretation of Cisco’s construction creates a metaphysical quandary—to constitute a
`
`“conversational flow,” the exchange of packets must be recognized as belonging to that same
`
`“conversational flow.” Contrary to Cisco’s construction, a conversational flow exists without
`
`regard to whether it is “recognized” as such. This interpretation of Cisco’s construction requires
`
`that a conversational flow be recognized as being a conversational flow before it actually is a
`
`conversational flow, a logical impossibility. Such a construction is nonsensical and cannot
`
`possibly be correct.
`
`The recited flow in Cisco’s proposal cannot be a “connection flow” either because both
`
`parties’ proposed constructions and the definition in the specification provide that a
`
`“conversational flow” may include one or more connections. The specification states that “[t]he
`
`term ‘connection flow’ is commonly used to describe all the packets involved with a single
`
`connection.” ‘099 Patent at 2:35-37 (emphasis added). Thus, a conversational flow involving
`
`more than one connection, or “connection flow,” would be impossible under Cisco’s proposal if
`
`the recited flow is a “connection flow.” This interpretation cannot stand either because it is
`
`inconsistent with the specification’s definition of “conversational flow,” which states that “some
`
`conversational flows involve more than one connection.”
`
`Finally, the recited flow in Cisco’s proposal might suggest some undefined other flow,
`
`but that construction has no support in the specification. The specification discloses
`
`“conversational flows” and “connection flows,” both of which have been addressed. Further,
`
`leaving Cisco’s proposal as-is—i.e., not clarifying the meaning of the recited “flow”—creates an
`
`ambiguous construction, which should be rejected.
`
`For these reasons, Cisco’s proposal to include the additional limitation “and are
`
`recognized as belonging to the same flow” should be rejected.
`
`B. “child protocol” (Ex. L, Term 4)
`
`Cisco’s Proposal
`Packet’s Proposal
`“a protocol that is encapsulated within another “protocol from a higher protocol stack
`
`
`
`
`
`- 3 -
`
`
`
`EX 1078 Page 8
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 9 of 38 PageID #: 3459
`
`
`
`protocol”
`
`
`layer”
`
`The specification discusses child protocols in the context of encapsulation, layers, and
`
`protocol stacks. Encapsulation indicates that the child protocol message (or a portion of that
`
`message) is included within the parent protocol message. See, e.g., ‘725 Patent at 6:62-7:5.
`
`Protocol layer refers to the conceptualization of network communications as layered, i.e., data
`
`from one protocol is encapsulated within another. See, e.g., id. at 6:32-54 (discussing the ISO
`
`protocol layer model as an example). There can be many layers in a communication; thus, the
`
`data being communicated may be encapsulated many times over. Finally, protocol stack refers to
`
`the “stack” of protocol layers in use. See id. Packet’s proposed construction accurately tracks the
`
`claim requirements, whereas Cisco’s proposed construction imports requirements not present in
`
`the claims.
`
`Cisco’s proposal is improper because it imports a “higher protocol stack layer” limitation
`
`that is not required in the claims. More specifically, Cisco’s proposal imposes a particular
`
`layering constraint on the child protocols that is not required by the claims. In particular, Claim
`
`31 of the ‘789 Patent recites “children protocols,” which is a plural form of “child protocol.” But
`
`neither this Claim nor Claim 19 on which it depends, reference protocol layering at all. Thus,
`
`Cisco’s proposed construction would improperly import the layering requirement into these ‘789
`
`Patent Claims. See ‘789 Patent at 37:61-38:6.
`
`Other asserted claims include a layering requirement, but do not specify a layering
`
`requirement for the “child protocol.” The relevant ‘725 Patent claims—1, 10, and 17—each
`
`include the following requirements:
`
`(b) receiving a set of protocol descriptions for a plurality of protocols that
`conform to a layered model, a protocol description for a particular protocol at a
`particular layer level including:
`
`(i) if there is at least one child protocol of the protocol at the particular layer level,
`the one or more child protocols of the particular protocol at the particular layer
`level, the packet including for any particular child protocol of the particular
`protocol at the particular layer level information at one or more locations in the
`packet related to the particular child protocol,
`
`(ii) the one or more locations in the packet where information is stored related to
`
`
`
`
`
`- 4 -
`
`
`
`EX 1078 Page 9
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 10 of 38 PageID #: 3460
`
`
`
`any child protocol of the particular protocol, and
`
`‘725 Patent at 95:6-21, 96:28-42, 98:5-19 (emphases added). The claims require that the plurality
`
`of protocols described “conform to a layered model.” They further require that each protocol
`
`description correspond to a particular protocol at a particular protocol layer level. Finally, each
`
`protocol description includes information about potential child protocols—namely, (1)
`
`identification of the child protocols for a particular protocol being described; and (2) the location
`
`(e.g., index) of information within a packet that is related to a child protocol of the particular
`
`protocol being described. See id. While the claims require that the protocols conform to a layered
`
`model, the claims do not require that the child protocol conform to a layered model. Rather, the
`
`protocol description identifies the location within the packet where information related to the
`
`child protocols can be found. See also ‘725 Patent at 4:2-6 (the protocol description for a
`
`particular protocol at a particular layer level includes child protocols, and for those child
`
`protocols, the protocol description identifies where in the packet the information for that child
`
`protocol may be found). Cisco’s proposal imposes a layering limitation for the child protocols
`
`that is not present in these claims.
`
`Cisco’s proposed construction should also be rejected because it is ambiguous. The term
`
`“higher” is a comparative term when discussing a layering model, yet Cisco’s proposal provides
`
`no basis for determining if a protocol stack layer is higher or lower, nor does Cisco provide a
`
`reference point for this comparison.
`
`A protocol that is encapsulated within another protocol is “located” within that protocol.
`
`Packet’s proposed construction aligns with the relevant claim language of the ‘725 Patent and
`
`how one of skill in the art would interpret “child protocol” in light of the specification.
`
`C. “parser record” (Ex. L, Term 15)
`
`Packet’s Proposal
`No construction necessary
`
`Cisco’s Proposal
`“a record that includes a signature, the hash, and at least parts of
`the packet payload”
`
`
`
`
`
`
`
`The meaning of “parser record” is clear to one of skill in the art when read within the
`
`- 5 -
`
`
`
`EX 1078 Page 10
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 11 of 38 PageID #: 3461
`
`
`
`context of the claims. Cisco’s construction is wrong for at least three reasons. First, Cisco
`
`commits the “cardinal sin” of claim construction by importing limitations into the claims;
`
`namely, “a signature, the hash, and at least parts of the packet payload.” See SciMed Life Sys. v.
`
`Advanced Cardiovascular Sys., 242 F.3d 1337, 1340 (Fed. Cir. 2001). Second, Cisco erroneously
`
`limits the claims to a preferred embodiment. And Third, Cisco’s construction violates the
`
`doctrine of claim differentiation.
`
`Claim 7 of the ‘646 Patent recites: “a parser subsystem . . . configured to extract selected
`
`portions of the accepted packet and to output a parser record containing the selected portions.”
`
`‘646 Patent at 38:3-6. The claim requires that the “parser record” includes “selected portions.” It
`
`does not, however, dictate the inclusion of a signature or hash, as Cisco proposes. Further, it does
`
`not require that the “selected portions” are from a packet payload. In some instances, for
`
`example, the selected portions may originate from the header information in the packet. See, e.g.,
`
`‘646 Patent at 13:25-31 (“The protocol table includes the parameters needed by the pattern
`
`analysis and recognition process 304 (implemented by PRE 1006) to evaluate the header
`
`information in the packet that is associated with that protocol, and parameters needed by
`
`extraction process 306 (implemented by slicer 1007) to process the packet header.”). Claim 16,
`
`similarly, does not require that a “parser record” includes a hash, signature, or parts of the packet
`
`payload: “performing one or more parsing/extraction operations on the packet to create a parser
`
`record comprising a function of the selected portions of the packet.” ‘646 Patent at 39:15-17.
`
`Finally, claims 1, 17, 19, 42, and 44 of the ‘789 Patent all include the term “parser record”;
`
`however, none of these claims requires that the parser record include the hash, signature, or
`
`payload portions as proposed by Cisco.
`
`Cisco identifies the following specification passage as supporting its proposed
`
`construction:
`
`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,
`
`
`
`
`
`- 6 -
`
`
`
`EX 1078 Page 11
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 12 of 38 PageID #: 3462
`
`
`
`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.
`
`‘646 Patent at 9:29-39 (emphasis added). The passage describes three things that a parser record
`
`may contain in “one embodiment”—“the signature (i.e., selected portions of the packet), the
`
`hash, and the packet itself.” The claim limitation at issue expressly recites one of these items:
`
`“selected portions of the accepted packet.” Despite the clear intent of the drafter to incorporate
`
`only one requirement, Cisco’s proposed construction incorporates all three. Cisco’s proposed
`
`construction is a classic example of improperly importing a limitation into the claims. See
`
`SciMed Life Sys., 242 F.3d at 1340.
`
`Further, Cisco violates the doctrine of claim differentiation which counsels that “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.” Aspex Eyewear, Inc. v.
`
`Marchon Eyewear, Inc., 672 F.3d 1335, 1348 (Fed. Cir. 2012) (quoting Phillips, 415 F.3d at
`
`1315). Dependent claims of the ‘646 Patent include limitations requiring that a hash or signature
`
`be included in the claimed “parser record.” Claim 9 of the ‘646 Patent requires a hash in the
`
`parser record: “A monitor according to claim 7, further including a mechanism for building a
`
`hash from the selected portions, wherein the hash is included in the input for a particular packet
`
`to the lookup engine . . . .” ‘646 Patent at 38:40-43 (emphasis added). Claim 18 of the ‘646
`
`Patent requires that the “parser record” include a signature: “wherein the function of the selected
`
`portions of the packet forms a signature that includes the selected packet portions . . . .” ‘646
`
`Patent at 40:8-11. Because these limitations are present in dependent claims, it is presumed that
`
`they are not present in the independent claims. Accordingly, Cisco’s proposed construction
`
`requiring that “parser record” include a “hash” and “signature” should be rejected.
`
`Because Cisco’s construction violates all of these doctrines of claim construction, it
`
`cannot possibly be correct and should be rejected.
`
`D. “flow entry” (Ex. L, Term 7)
`
`Packet’s Proposal
`
`Cisco’s Proposal
`
`
`
`
`
`- 7 -
`
`
`
`EX 1078 Page 12
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 13 of 38 PageID #: 3463
`
`
`
`No construction necessary
`
`
`“a database record that completely describes a conversational flow
`and includes the unique flow-signature, state information, extracted
`information from the packet for updating flows, and one or more
`statistical measures about the conversational flow”
`
`The claims of each Patent-in-Suit generally recite that flow-entries are maintained in a
`
`database for conversational flows. See ‘099 Patent Claim 1 (“flow-entries for conversational
`
`flows”); ‘725 Patent Claim 15 (“flow-entry for each previously encountered conversational
`
`flow”); ‘646 Patent Claim 1 (“flow-entries for previously encountered conversational flows”);
`
`‘751 Patent Claim 1 (same); ‘789 Patent Claim 1 (same). Based on the claim language, one of
`
`ordinary skill in the art would understand that a “flow entry” is simply an entry related to a flow.
`
`Thus, no construction is necessary. Cisco’s construction, instead of being a serious attempt to
`
`construe “flow entry,” is a transparent attempt to use the term as a vehicle to import numerous
`
`limitations into the claims.
`
`Certain claims require that a “flow entry” include “identifying information.” See, e.g.,
`
`‘725 Patent, Claim 15 (flow-entry “include[s] identifying information for future packets to be
`
`identified with the new flow-entry”); ‘789 Patent, Claim 1 (same); ‘646 Patent, Claim 2
`
`(“wherein each flow-entry is identified by identifying information stored in the flow-entry”).
`
`Other claims require that the flow-entry include “statistical measures.” See, e.g., ‘099 Patent,
`
`Claim 9 (“wherein one or more statistical measures about a flow are stored in each flow-entry”);
`
`‘751 Patent, Claim 1 (“including storing one or more statistical measures kept in the flow-
`
`entry”); ‘789 Patent, Claim 4 (“wherein updating includes storing one or more statistical
`
`measures stored in the flow-entry of the existing flow”). And at least one claim requires that a
`
`“signature” be stored in the claimed “flow-entry.” See ‘646 Patent, Claim 18 (“wherein the
`
`identifying information stored in the new or updated flow-entry is a signature for identifying
`
`future packets”).
`
`As indicated by the many claims cited above, the patentee dictated the contents of a flow-
`
`entry in certain claims and not in others. When a claim does not include such requirements, the
`
`patentee presumably did not intend to so limit the contents of a “flow-entry.” See Phillips, 415
`
`
`
`
`
`- 8 -
`
`
`
`EX 1078 Page 13
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 14 of 38 PageID #: 3464
`
`
`
`F.3d at 1312 (“[W]e look to the words of the claims themselves . . . to define the scope of the
`
`patented invention.” (quoting Vitronics Corp. v. Conceptronic, 90 F.3d 1576, 1586 (Fed. Cir.
`
`1996))). The claims themselves are clear regarding whether a claimed “flow-entry” contains
`
`specific information. Accordingly, “flow-entry” should not be limited to include the specific
`
`elements recited in Cisco’s proposal: “unique flow-signature, state information, extracted
`
`information from the packet for updating flows, and one or more statistical measures about the
`
`conversational flow.”
`
`Additionally, many of Cisco’s proposed limitations violate the doctrine of claim
`
`differentiation. For instance, dependent claim 2 of the ‘099 Patent requires that the “flow-entry
`
`includes the state of the flow.” However, independent claim 1 has no such requirement.
`
`Likewise, dependent claim 9 of the ‘099 Patent requires “statistical measures”; however, claim 1
`
`does not. Finally, dependent claim 18 of the ‘646 Patent requires “a signature,” but independent
`
`claim 16 does not. Limitations present in dependent claims should not be imported into the
`
`underlying independent claims. See Phillips, 415 F.3d at 1314-15 (“[T]he 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.” (citing Libel-Flarsheim Co. v. Medrad, Inc.,
`
`358 F.3d 898, 910 (Fed. Cir. 2004))).
`
`Cisco’s proposal should also be rejected because it imports limitations from the preferred
`
`embodiment into the claims. Figure 3 of the Patents-in-Suit discloses an embodiment of the
`
`claimed invention. See ‘099 Patent at 7:47-50. Cisco’s proposed construction is taken, almost
`
`verbatim, from a description of this embodiment. See id. at 14:14-18 (“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.”). It is improper to import limitations of a disclosed
`
`embodiment into the claims. See CollegeNet, Inc. v. ApplyYourself, Inc., 418 F.3d 1225, 1231
`
`(Fed. Cir. 2005) (“[T]his court will not at any time import limitations from the specification into
`
`the claims.”). Accordingly, Cisco’s proposed construction should be rejected.
`
`
`
`
`
`- 9 -
`
`
`
`EX 1078 Page 14
`
`

`

`Case 2:14-cv-00252-JRG Document 89 Filed 01/26/15 Page 15 of 38 PageID #: 3465
`
`
`
`E. “none or more” (Ex. L, Term 13)
`
`Packet’s Proposal
`No construction necessary
`
`Alternative: “may include one or more”
`
`
`Cisco’s Proposal
`
`Indefinite
`
`Packet proposes that no construction is necessary, while Cisco argues that this term is
`
`indefinite. The patent statute’s definiteness provision requires “that a patent’s