`
`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
`PALO ALTO NETWORKS, INC.,
`Case No. 3:19-cv-02471-WHO
`PACKET INTELLIGENCE LLC’S
`Plaintiff and Counter-Defendant,
`OPENING CLAIM CONSTRUCTION
`BRIEF
` v.
`PACKET INTELLIGENCE LLC,
`Defendant and Counterclaimant.
`
`DEMAND FOR JURY TRIAL
`
`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
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
` CASE NO. 3:19-CV-02471-WHO
`
`Packet Intelligence LLC Exh 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 1 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 2 of 22
`
`
`
`Table of Contents
`
`
`INTRODUCTION ................................................................................................. 1
`I.
`II. BACKGROUND .................................................................................................. 1
`III. LEGAL STANDARDS .......................................................................................... 5
`IV. DISPUTED TERMS FOR CONSTRUCTION .......................................................... 6
`
`A. “conversational flow(s)”/ “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. “a flow-entry database” terms ................................................................ 10
`
`C. “the flow”/ “existing flow” / “new flow” ............................................... 13
`
`D. “a protocol/state identification mechanism…configured to determine the
`protocol and state of the conversational flow of the packet” ................ 14
`
`E. “claim preambles”................................................................................... 16
`
`V. CONCLUSION .................................................................................................. 17
`
`
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`i
`
`
`
`
`
` CASE NO. 3:19-CV-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 2 of 22
`
`
`
`
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 3 of 22
`
`Table of Authorities
`
`
`Cases
`3M Innovative Props. Co. v. Tredegar Corp.
` 725 F.3d 1315 (Fed. Cir. 2013) ................................................................................................. 10
`Allen Eng’g Corp. v. Bartell Indus., Inc.,
`299 F.3d 1336 (Fed. Cir. 2002) .................................................................................................. 16
`Aspex Eyewear, Inc. v. Marchon Eyewear, Inc.,
`672 F.3d 1335 (Fed. Cir. 2012) .................................................................................................. 16
`Cochlear Bone Anchored Sols. AB v. Octicon Med. AB,
`958 F. 3d 1348 (Fed. Cir. 2020) ........................................................................................... 16, 17
`Intervet Inc. v. Merial Ltd.,
`617 F.3d 1282 (Fed. Cir. 2010) .................................................................................................... 7
`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) .................................................................................................. 14
`Omega Eng’g, Inc. v. Raytek Corp.
` 334 F.3d 1314 (Fed. Cir. 2003) ................................................................................................. 10
`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) .................................................................................................... 17
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00450, Paper 8 .......................................................................................................... 8, 9
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00451, Paper 8 .......................................................................................................... 8, 9
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00629, Paper 8 .......................................................................................................... 8, 9
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00862, 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-00769, Paper 8 .......................................................................................................... 8, 9
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`ii
`
`
`
`
`
` CASE NO. 3:19-CV-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 3 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 4 of 22
`
`
`
`Teva Pharm. USA, Inc. v. Sandoz, Inc.,
` 135 S. Ct. 831 (2015) .................................................................................................................. 5
`Teva Pharm. USA, Inc. v. Sandoz, Inc.,
`789 F.3d 1335 (2015) ................................................................................................................... 9
`TomTom, Inc. v. Adolph,
`790 F.3d 1315 (Fed. Cir. 2015) .................................................................................................. 16
`U.S. Surgical Corp. v. Ethicon, Inc.,
`103 F.3d 1554 (Fed. Cir. 1997) .................................................................................................. 14
`Vitronics Corp. v. Conceptronic, Inc.,
`90 F.3d 1576 (Fed. Cir. 1996) ...................................................................................................... 6
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`iii
`
`
`
`
`
` CASE NO. 3:19-CV-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 4 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 5 of 22
`
`
`
`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-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 5 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 6 of 22
`
`
`
`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 46-3 (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:
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`2
`
`
`
`
`
` CASE NO. 3:19-CV-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 6 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 7 of 22
`
`
`
`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-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 7 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 8 of 22
`
`
`
`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-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 8 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 9 of 22
`
`
`
`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 guide to the meaning of a
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`5
`
`
`
`
`
` CASE NO. 3:19-CV-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 9 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 10 of 22
`
`
`
`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(s)”/ “conversational flow-sequence”
`
`Claim Term
`
`“conversational flow(s)”/
`“conversational flow-
`sequence”
`
`All Asserted Claims
`
`
`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 involve
`more than one connection,
`and some even involve more
`than one exchange of packets
`between a client and server”
`
`
`Palo Alto Networks’
`Construction
`Indefinite.
`
`Alternatively, “the sequence
`of packets that are exchanged
`in any direction as a result of
`specific software program
`activity (for instance, the
`running of a specific
`videoconference program),
`where such packets form
`multiple connection flows
`that are linked based on that
`activity (for instance, linking
`an audio connection and a
`video connection that result
`from the same
`videoconference).”
`
`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
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
`6
`
`
`
`
`
` CASE NO. 3:19-CV-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 10 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 11 of 22
`
`
`
`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.
`
`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.
`The core dispute concerns 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, and also that running an
`application on a networked device and communicating messages related to that application over
`the network constitutes an example of such 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.
`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
`7
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
` CASE NO. 3:19-CV-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 11 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 12 of 22
`
`
`
`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 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 over twenty-five pages of testimony about
`“conversational flow” from its expert, Dr. Schmidt, sidestepping page limitations on claim
`construction briefing. This “testimony” resembles attorney argument more than expert opinion
`supported by data. Indeed, Dr. Schmidt’s declaration is virtually devoid of any technical analysis.
`And the logical flaws in the declaration are readily apparent—for example, Dr. Schmidt builds
`much of his analysis on this core premise: “[a] POSITA reading the intrinsic evidence would have
`been led to believe that (a) a conversational flow is distinct from a connection flow, but also (b) a
`conversational flow can be a connection flow. But both of those things cannot be true.” ECF 46-2
`(Schmidt Dec.) ¶ 85. He provides no analysis or explanation for this conclusion. Id. Yet this
`statement is logically wrong on its face. For example: “dog” and “mammal” are distinct from one
`another, but also a “dog” can be a “mammal.” That Dr. Schmidt seems to not grasp basic
`hierarchical concepts—a cornerstone of computer science and communications—is of concern.
`8
`
`PI’S OPENING CLAIM CONSTRUCTION BRIEF
`
`
`
` CASE NO. 3:19-CV-02471-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 2066
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 12 of 22
`
`
`
`Case 3:19-cv-02471-WHO Document 63 Filed 06/04/20 Page 13 of 22
`
`
`
`But setting aside these facial flaws, the lack of concrete technical analysis in Dr. Schmidt’s
`declaration renders it of little use for claim construction. Teva Pharm. USA, Inc. v. Sandoz, Inc.,
`789 F.3d 1335, 1342 (2015) (“A party cannot transform into a factual matter the internal coherence
`and context assessment of the patent simply by having an expert offer an opinion on it.”).
`For example, Dr. Schmidt first alleges that the asserted claims are all indefinite. In support
`of this argument, he identifies several statements from IPRs in which Packet proposed this same
`construction. But Dr. Schmidt alleges that Packet’s IPR statements are “irreconcilably conflicting”
`with the construction itself. This is a remarkable premise, because in each of the IPRs relied on by
`Dr. Schmidt, the PTAB agreed with Packet’s proposal and adopted this same construction. See
`IPR2017-00450, Paper 8 at 7-10; IPR2017-00451, Paper 8 at 7-10; IPR2017-00629, Paper 8 at 7-
`9; Ex. J (IPR