Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 1 of 25
`
`
`
`Brian A.E. Smith (SBN 188147)
`Alden KW Lee (SBN 257973)
`Jeffrey D. Chen (SBN 267837)
`Joseph J. Fraresso (SBN 289228)
`BARTZO ZANKEL BUNZEL & MILLER
`One Embarcadero Center, Suite 800
`San Francisco, CA 94111
`Telephone: (415) 956-1900
`bsmith@bzbm.com
`alee@bzbm.com
`jchen@bzbm.com
`jfraresso@bzbm.com
`
`Attorneys for Defendant and
`Counterclaimant Packet Intelligence LLC
`
`[Additional counsel listed on signature page]
`
`
`UNITED STATES DISTRICT COURT
`NORTHERN DISTRICT OF CALIFORNIA
`SAN FRANCISCO DIVISION
`PACKET INTELLIGENCE LLC,
` Case No. 3:19-cv-04741-WHO
`
`
`PLAINTIFF PACKET INTELLIGENCE
`
`Plaintiff,
`LLC’S OPENING CLAIM
`
`CONSTRUCTION BRIEF
` v.
`
`
`
`JUNIPER NETWORKS, INC.,
`
`
`DEMAND FOR JURY TRIAL
`
`Defendant.
`
`
`
`
`
`
`
`
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 1 of 25
`
`

`

`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 2 of 25
`
`Table of Contents
`
`INTRODUCTION ................................................................................................. 1
`I.
`BACKGROUND .................................................................................................. 1
`II.
`III. LEGAL STANDARDS .......................................................................................... 5
`IV. DISPUTED TERMS FOR CONSTRUCTION .......................................................... 6
`
`A. “conversational flow” / “conversational flow-sequence” ............................ 6
`
`1. The Specification Expressly Defines “Conversational Flow” ........... 6
`
`2. Defendant’s Arguments Fail to Negate the Express Definition of a
`“Conversational Flow” ................................................................................. 8
`
`B. “flow-entry database” .......................................................................................... 10
`
`C. “the flow” / “new flow” / “existing flow” ...................................................... 13
`
`D. “base protocol” ..................................................................................................... 15
`
`E. “slicer” ..................................................................................................................... 16
`
`F. “a protocol/state identification mechanism coupled to the state
`patterns/operations memory and to the lookup engine, the protocol/state
`identification engine configured to determine the protocol and state of
`the conversational flow of the packet” ............................................................. 17
`
`G. “claim preambles” ................................................................................................ 19
`
`V.
`
`CONCLUSION .................................................................................................. 20
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
` CASE NO. 3:19-CV-04741-WHO
`
`i
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 2 of 25
`
`

`

`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 3 of 25
`
`
`
`Table of Authorities
`
`Cases
`3M Innovative Props. Co. v. Tredegar Corp.
` 725 F.3d 1315 (Fed. Cir. 2013) ............................................................................................. 9, 10
`Allen Eng’g Corp. v. Bartell Indus., Inc.,
`299 F.3d 1336 (Fed. Cir. 2002) .................................................................................................. 19
`Applied Materials, Inc. v. Advanced Semiconductor Materials America, Inc.,
`98 F.3d 1563 (Fed. Cir. 1996) .................................................................................................... 20
`Aspex Eyewear, Inc. v. Marchon Eyewear, Inc.,
`672 F.3d 1335 (Fed. Cir. 2012) .................................................................................................. 19
`Cochlear Bone Anchored Sols. AB v. Octicon Med. AB,
`958 F. 3d 1348 (Fed. Cir. 2020) ........................................................................................... 19, 20
`Deere & Co. v. Bush Hog, LLC,
`703 F.3d 1349 (Fed. Cir. 2012) .................................................................................................. 20
`Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc.,
`381 F.3d 1111 (Fed. Cir. 2004) .................................................................................................. 20
`Intervet Inc. v. Merial Ltd.,
`617 F.3d 1282 (Fed. Cir. 2010) .................................................................................................... 6
`Markman v. Westview Instruments, Inc.,
`517 U.S. 370 (1996) ..................................................................................................................... 5
`O2 Micro Int’l Ltd. v. Beyond Innovation Tech. Co.,
`521 F.3d 1351 (Fed. Cir. 2008) .................................................................................................. 15
`Omega Eng’g, Inc. v. Raytek Corp.
` 334 F.3d 1314 (Fed. Cir. 2003) ................................................................................................... 9
`On-Line Techs., Inc. v. Bodenseewerk Perkin-Elmer GMBH
` 386 F.3d 1133 (Fed. Cir. 2004) ................................................................................................. 12
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) (en banc) ............................................................................... 5, 6
`Renishaw PLC v. Marposs Societa’ per Azioni,
`158 F.3d 1243 (Fed. Cir. 1998) .................................................................................................... 6
`Rowe v. Dror,
`112 F.3d 473 (Fed. Cir. 1997) .................................................................................................... 20
`Sandvine Corp, et al. v. Packet Intelligence, LLC,
`IPR2017-00451, Paper 8 .......................................................................................................... 8, 9
`Sandvine Corp., et al v. Packet Intelligence, LLC,
`IPR2017-00630, Paper 9 .......................................................................................................... 8, 9
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`
`IPR2017-00450, Paper 8 .......................................................................................................... 8, 9
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00629, Paper 8 .......................................................................................................... 8, 9
`ii
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 3 of 25
`
`

`

`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 4 of 25
`
`
`
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00769, Paper 11 ............................................................................................................ 9
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00769, Paper 6 .............................................................................................................. 9
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00769, Paper 8 .......................................................................................................... 8, 9
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00862, Paper 8 .......................................................................................................... 8, 9
`Teva Pharm. USA, Inc. v. Sandoz, Inc.,
` 135 S. Ct. 831 (2015) .................................................................................................................. 5
`TomTom, Inc. v. Adolph,
`790 F.3d 1315 (Fed. Cir. 2015) .................................................................................................. 19
`U.S. Surgical Corp. v. Ethicon, Inc.,
`103 F.3d 1554 (Fed. Cir. 1997) .................................................................................................. 15
`Vitronics Corp. v. Conceptronic, Inc.,
`90 F.3d 1576 (Fed. Cir. 1996) ...................................................................................................... 6
`
`
`
`
`
`
`
`iii
`
`
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 4 of 25
`
`

`

`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 5 of 25
`
`
`
`I.
`
`INTRODUCTION
`This 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”)
`(attached as Ex. F), and thus the Provisional forms part of the intrinsic evidence.
`The Patents-in-Suit generally address classifying and monitoring network traffic passing
`through one or more nodes or points in the network. Traffic classification involves detecting the
`underlying protocols implemented in the network traffic, 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, bill for use of the network,
`and ensure an appropriate quality of service on a per-user granular basis.
`Packet’s proposed constructions adhere to the well–known principles of claim construction
`and stem from the plain and ordinary meaning of the terms at issue, in light of the specification’s
`teachings. Defendant’s proposed constructions, on the other hand, generally seek to import
`extraneous limitations or ignore key disclosures to manufacture non-infringement and invalidity
`positions. Because Packet’s constructions follow the canons of patent law and properly balance
`granting the full scope of Applicants’ invention while ensuring that the public has proper notice of
`the scope of the invention, Packet respectfully requests that the Court adopt its proposed
`constructions for the disputed terms described below and reject Defendant’s proposed
`constructions.
`II. BACKGROUND
`Before discussing the invention, it is useful to understand certain fundamentals regarding
`
`network traffic. The Open Systems Interconnection (“OSI”) model represents the protocol layers
`
`1 The specifications of the Patents-in-Suit are similar. Generally, the patent that includes the claims
`at issue for a given term is cited here.
`
`1
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 5 of 25
`
`

`

`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 6 of 25
`
`
`
`often used in network communication. This model (as developed by the International Standards
`Organization) contains the seven layers shown below:
`
`
`See Ex. A (’099 Pat.) at 9:35–50; see also ECF 54-2 (Almeroth Dec.) ¶¶ 38, 49-52 (attached as Ex.
`G).
`
`The Application layer (layer 7) is the highest-level layer while the Physical layer (layer 1)
`is the lowest level layer. See Ex. G ¶¶ 39, 50. These layers provide a model for describing common
`formats used in network communications. Each layer serves a particular purpose within the network
`communication model. The Application layer represents the application protocol used in a network
`communication and is typically the protocol that the user’s application uses to communicate. For
`instance, the Skype application uses its proprietary protocol, along with standard protocols for
`audio and video, if required. Similarly, web browsers use the HTTP protocol.
`The Network layer (layer 3) includes protocols such as the Internet Protocol, also known as
`IP, used to support network routing decisions that guide traffic through the Internet. Id. ¶¶ 44-47.
`The Physical layer (layer 1) includes protocols such as Ethernet, which control the transmission of
`raw data onto the wire. Protocol layering is accomplished by encapsulation, which is taking a
`higher-level protocol message and packaging it up into one or more lower‐level protocol messages.
`Several layers, or protocols, may be involved in a network communication:
`
`
`
`2
`
`
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 6 of 25
`
`

`

`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 7 of 25
`
`
`
`See Ex. G ¶ 53. In forming a network transmission, an application writes a message in an application
`layer protocol, for example, HTTP or Skype protocol; this is OSI layer 7. See Ex. G ¶¶ 53-57.
`Before transmission, and after possible encapsulation in layers 6, 5, and/or 4, the message is broken
`into one or more IP messages (or packets) that are written in the IP protocol at layer 3. Id. Each of
`these IP packets typically includes a header with information specific to the IP protocol, such as
`the source IP address, destination IP address, a checksum (for error detection), and the length of
`the packet. Id. The header is followed by a data portion that includes a fragment (or portion) of the
`higher‐level protocol transmission. For example, the data portion of the message in the illustration
`above may be split into several smaller portions and sent separately, with each of those portions
`including an IP header. Id. At this point, the original message has been fragmented and encapsulated
`into multiple IP messages. Put differently, the layer 7 message is encapsulated into a set of layer 3
`messages. Id.
`Each of these layer 3 IP messages may be further encapsulated into one or more Ethernet
`messages (or packets) during the transmission process, as the message progresses from sender,
`through the Internet, to a recipient. Id. The Ethernet packets will have a header with Ethernet‐
`specific information that is added to the IP packet, while the data portion will contain the pieces of
`data that comprise the IP message. Id. The original message may get encapsulated several times
`during the transmission process. Id. At this point, the Ethernet packets are placed directly on the
`
`wire (e.g., the Ethernet) for transmission. The receiving client or server will receive the Ethernet
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`3
`
`
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 7 of 25
`
`

`

`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 8 of 25
`
`
`
`messages, and the messages will be unpacked and re‐combined to form the original message—first
`combining the Ethernet messages to create the IP messages. During this process, the headers of the
`Ethernet packets are removed and the data portions are concatenated to form an IP message. Id.
`Then, the IP messages will be combined to create the original message again—now on the receiving
`client or server—which is then processed by the appropriate application on the receiving
`client/server.
`Turning to the inventions disclosed in the Patents-in-Suit, conventional network monitors
`categorize network transmissions into “connection flows.” A connection flow refers to “all the
`packets involved with a single connection.” Ex. A (’099 Pat.) at 2:34-37. A connection is typically
`characterized by a tuple of elements including the (1) source IP address, (2) destination IP address,
`(3) source port, (4) destination port, and (5) transport protocol. Thus, a connection flow correlates
`to source and destination IP address/port pairs used on both ends of the connection. The network
`monitor disclosed in the Patents-in-Suit categorizes network transmissions into “conversational
`flows.” Unlike connection flows, which relate to a negotiated transmission between specific
`addresses on two devices, a conversational flow 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—which may include multiple connections, transmissions, or exchanges in
`either direction between the participants in the conversation. For example, a Voice Over IP (VOIP)
`call made between two parties using the Skype application may involve multiple connections as
`the VOIP call ensues. The ability to relate together the separate connections for a user activity and
`recognize the underlying application is a focus of the present invention. This allows the owner or
`administrator of the network to make intelligent decisions regarding certain usage of the network,
`while maintaining the quality of the network communications.
`Figure 3 of the Patents-in-Suit provides a high‐level overview of a preferred embodiment
`of the claimed network monitor, which can be implemented with computer hardware and/or
`software. See Ex. A (’099 Pat.) at 11:43-45. The disclosed packet monitor includes two significant
`
`components: (1) Parser 301; and (2) Analyzer 303. See id. at 11:59-65. The Parser maintains a
`database of parsing and extraction operations to be used on packets to extract identifying
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`4
`
`
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 8 of 25
`
`

`

`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 9 of 25
`
`
`
`information from the packet. See id. at 12:17-22; 12:65-13:20. This data is then passed to the
`Analyzer, which checks if the packet is of a new or existing flow. See id. at 13:54-61. The Analyzer
`maintains state information for each flow, and as new packets for a given flow are received, the
`state is updated accordingly. See id. at 13:37-41. The state information is used to ultimately classify
`or identify the application and/or protocol corresponding to the flow. See id. at 15:30-42. Unlike
`prior art monitors that relied on port numbers to identify application layer protocols, the Patents-
`in-Suit teach a progressive process that uses state operations programmed into the network monitor
`to discover the identity of the application layer protocol. See id. at 15:18-29. The Analyzer is also
`responsible for determining the status of conversational flows and determining when a flow is final.
`See id. at 15:55-65. The Asserted Patents disclose both hardware and software embodiments. See
`id. at 11:43-45.
`In identifying discrete or disjointed connections initiated by the same activity, one benefit
`of the disclosed invention is the ability to identify that seemingly discrete or disjointed connections
`are actually related to the same “conversational flow.” That is, unlike the prior art, the invention
`can parse and analyze the information in packets for classification into a “conversational flow.”
`III. LEGAL STANDARDS
`Courts construe the meaning of disputed claim terms as a matter of law that may contain
`underlying questions of fact. Markman v. Westview Instruments, Inc., 517 U.S. 370, 389-90
`(1996); Teva Pharm. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 839-40 (2015). In determining a
`term’s meaning, “[a] court looks to ‘those sources available to the public that show what a person
`of skill in the art would have understood disputed claim language to mean,’” including “‘the
`words of the claims themselves, the remainder of the specification, the prosecution history, and
`extrinsic evidence….’” Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005) (en banc).
`The intrinsic evidence (i.e., the claims, the patent specification, and the prosecution
`history, if in evidence) form a hierarchy of interpretive guides. The claims form the first tier of
`the hierarchy and “provide substantial guidance as to the meaning of particular claim terms.”
`
`Phillips, 415 F.3d at 1314-15. The rest of the specification forms the second tier and is “always
`highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`5
`
`
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 9 of 25
`
`

`

`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 10 of 25
`
`
`
`guide to the meaning of a disputed term.” Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576,
`1582 (Fed. Cir. 1996). Finally, the prosecution history “provides evidence of how the PTO and
`the inventor understood the patent.” Phillips, 415 F.3d at 1317.
`This hierarchy notwithstanding, “the claim construction inquiry…begins and ends in all
`cases with the actual words of the claim.” Renishaw PLC v. Marposs Societa’ per Azioni, 158
`F.3d 1243, 1248 (Fed. Cir. 1998) (citations omitted). The specification may inform the meaning
`of claim terms, but it does not change those meanings unless the patentee has chosen to be his
`own lexicographer. See Phillips, 415 F.3d at 1321; Vitronics, 90 F.3d at 1582.
`IV. DISPUTED TERMS FOR CONSTRUCTION
`
`A.
`
`“conversational flow” / “conversational flow-sequence”
`
`flow”/
`flow-
`
`Claim Term
`
`“conversational
`“conversational
`sequence”
`
`’099 claims 1, 5
`’725 claims 10, 17
`’646 claims 1, 7, 16;
`’751 claims 1, 17;
`’789 claims 1, 19, 44
`
`Packet Intelligence’s
`Construction
`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 involved more than one
`connection, and some even
`involve more
`than
`one
`exchange of packets between a
`client and server.
`
`Juniper’s Construction
`
` “The sequence of packets that
`are exchanged in any direction
`as a result of specific software
`program activity, where such
`packets
`form
`multiple
`connection
`flows
`that are
`linked based on that activity”
`
`Packet’s proposed construction tracks the definitional language from the specification and
`tracks prior constructions adopted by both a United States District Court and, separately, the Patent
`Trial and Appeals Board. None of the evidence cited by Defendant warrants varying from the
`specification’s express definition and decisions confirming this construction.
`1. The Specification Expressly Defines “Conversational Flow”
`
`First, Packet’s proposed construction tracks the definitional language from the
`
`specification. 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
`6
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 10 of 25
`
`

`

`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 11 of 25
`
`
`
`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.
`
`Ex. A (’099 Pat.) at 2:34-48 (emphases added); Ex. E (’789 Pat.) at 2:42-56; see also Ex. F
`(Provisional) at 3:3-12 (including a nearly identical statement). Both parties’ proposals incorporate
`much of the underlined language above.
`An initial dispute regards the notion of “activity” as recited in the specification’s definition
`of conversational flow. Packet’s proposal tracks the language in the specification. Defendant’s
`proposal, however, seeks to replace the exemplary definition of “activity” (e.g., “for instance, the
`running of an application on a server as requested by a client”) with “specific software program
`activity.” The specification does not use this language, and there is no reason to deviate from the
`specification’s exemplary definition of “activity,” which is embedded within its express definition
`of “conversational flow.”
`The core dispute regards whether a “conversational flow” always requires multiple
`connection flows. For the reasons below, it does not. The parties agree that a conversational flow
`includes packets exchanged in any direction as the result of an activity. This captures the nature of
`conversational flows. An activity could involve only a single connection. But often, application
`activity involves multiple connections and exchanges of packets. See, e.g., Ex. A (’099 Pat.) at
`2:49-3:6 (describing the multiple connections involved in an SAP print service activity). Thus, for
`a packet monitor to be capable of recognizing the claimed “conversational flows,” it must be
`capable of recognizing the times when application activities involve multiple connections or
`exchanges of packets. That is precisely what Packet has proposed, and the definition is directly
`from the specification.
`
`Second, each tribunal to have considered the proper construction for “conversational flow”
`has accepted Packet’s proposed construction, which stems from the specification’s explicit
`definition. For example, in Packet Intelligence LLC v. NetScout Sys., Inc., after first challenging
`the same construction on similar bases as those presented by Defendant here, the NetScout
`
`defendant eventually agreed to Packet’s construction. No. 2:16-cv-230-JRG (E.D. Tex.), Dkt. No.
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`7
`
`
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 11 of 25
`
`

`

`Case 3:19-cv-04741-WHO Document 57 Filed 06/04/20 Page 12 of 25
`
`
`
`66 (attached as Ex. H). As a result, the Court adopted the same construction Packet proposes here.
`Id.
`And a panel of three Patent Trial and Appeal Board administrative patent judges considered
`
`and approved Packet’s construction in six separate IPR proceedings under the “broadest reasonable
`interpretation” standard. See Sandvine Corp., et al. v. Packet Intelligence, LLC, IPR2017-00450,
`Paper 8 at 7-10; IPR2017-00451, Paper 8 at 7-10; IPR2017-00629, Paper 8 at 7-9; Ex. J (IPR2017-
`00630) Paper 9 at 7-9; IPR2017-00769, Paper 8 at 8-10; Ex. I (IPR2017-00862) Paper 8 at 7-10
`(all PTAB July 26, 2017). Two different APJs authored opinions endorsing Packet’s construction
`because of the express definition in the patent. In IPR2017-00862, the PTAB panel opinion written
`by Administrative Patent Judge Mercader explained the following about Packet’s proposed
`construction of “conversational flow”:
`we observe that the specification of the ’099 patent explicitly supports this
`construction. See Ex. 1003, 2:34–45. Accordingly, for purposes of this Decision,
`we agree that Patent Owner’s proposed construction, which mirrors the definition
`in the specification, is the broadest reasonable construction consistent with the
`specification.
`
`IPR2017-00862, Paper 8 at 9-10 (attached as Ex. I) (emphasis added). Similarly, in IPR2017-
`00630, the PTAB panel opinion written by Administrative Patent Judge Fink embraced Packet’s
`proposed construction. IPR2017-00630, Paper 9 at 9 (attached as Ex. J) (“We agree with Patent
`Owner that the term ‘conversational flow’ is expressly defined in the excerpt of the patent quoted
`above.” (emphasis added)). The other IPR decisions mirror the reasoning in these opinions. See
`citations supra.
`In sum: no matter the standard used, every tribunal to consider this issue agreed that the
`term “conversational flow” is expressly defined in the specification, as Packet contends.
`2. Defendant’s Arguments Fail to Negate the Express Definition of a “Conversational
`Flow”
`
`On the other hand, Defendant provides testimony from its expert, Dr. Bellovin suggesting
`
`that the Court should redefine the term “conversational flows” to require that “conversational
`flows” be “linked” only by “specific software program activity.” See, e.g., ECF 54-3 ¶ 89
`(“…where such packets form multiple connection flows that are linked based on that [specific
`software program] activity.”).
`
`To support his position, Dr. Bellovin identifies an IPR in which Packet distinguished the
`claims over the prior art. Id. ¶¶ 86-92. But those passages address the fact that the prior art in the
`IPRs was “not concerned” with applications (or activities) at all, and instead simply blindly
`8
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
` CASE NO. 3:19-CV-04741-WHO
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Packet Intelligence LLC Exh 2069
`Juniper Networks, Inc