`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`Juniper Networks, Inc. & Palo Alto Networks, Inc.
`Petitioners,
`
`
`v.
`
`Packet Intelligence LLC,
`Patent Owner.
`
`
`Case IPR2020-00337
`U.S. Patent No. 6,771,646
`
`PATENT OWNER’S RESPONSE UNDER
`37 C.F.R. § 42.120
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`

`

`PATENT OWNER’S EXHIBIT LIST
`
`
`
`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`2003
`
`2004
`2005
`
`Exhibit No. Description
`2001
`Withdrawn
`Packet Intelligence LLC v. Sandvine Corp., No. 2:16-cv-00147, Dkt.
`2002
`No. 17 (E.D. Tex. June 1, 2017) (order consolidating cases)
`File History for U.S. Patent No. 6,771,646 – Feb. 10, 2004,
`Response to Office Action (annotated version of Ex. 1020)
`Reserved
`Palo Alto Networks, Inc. v. Packet Intelligence LLC (No. 19-cv-
`02471-WHO) and Packet Intelligence LLC v. Juniper Networks, Inc.
`(No. 19-cv-04741-WHO), Transcript of Case Management
`Conference on January 7, 2020
`Palo Alto Networks, Inc. v. Packet Intelligence LLC, No. 19-cv-
`02471-WHO, Dkt. No. 62 (May 15, 2020) (Order Granting Palo
`Alto Networks’ Proposed Modification to the Scheduling Order)
`Packet Intelligence LLC v. Juniper Networks, Inc., No. 3:19-cv-
`04741-WHO, Dkt. No. 48 (March 29, 2020) (Stipulated First
`Amended Scheduling Order)
`PAN Contentions A5 – (Riddle)
`PAN Contentions A13 – (Yu)
`JUN Contentions A6 - (Riddle and Ferdinand)
`JUN Contentions A7 - (Riddle and Ferdinand and Yu)
`JUN Contentions A8 - (Riddle and Ferdinand and Baker)
`JUN Contentions A9 - (Riddle and Ferdinand and Baker and Yu)
`JUN Contentions A10 - (Riddle and Ferdinand and RFC1945)
`JUN Contentions A11 - (Riddle and Ferdinand and Baker and
`RFC1945)
`JUN Contentions B6 - (Riddle and Baker)
`JUN Contentions B7 - (Riddle and Baker and Yu)
`JUN Contentions B8 - (Riddle and Baker and RFC1945)
`JUN Contentions C6 - (Riddle and Ferdinand and Wakeman)
`JUN Contentions C7 - (Riddle and Ferdinand and Wakeman and
`Yu)
`
`2006
`
`2007
`
`2008
`2009
`2010
`2011
`2012
`2013
`2014
`2015
`
`2016
`2017
`2018
`2019
`2020
`
`ii
`
`

`

`2021
`
`2022
`2023
`2024
`2025
`2026
`2027
`2028
`2029
`
`2030
`2031
`2032
`2033
`
`2034
`2035
`2036
`
`2037
`2038
`2039
`2040
`2041
`
`2042
`
`2043
`2044
`
`2045
`2046
`2047
`
`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`JUN Contentions C8 - (Riddle and Ferdinand and Wakeman and
`RFC1945)
`JUN Contentions D6 - (Riddle and Ferdinand)
`JUN Contentions D7 - (Riddle and Ferdinand and Yu)
`JUN Contentions D8 - (Riddle and Ferdinand and RFC1945)
`JUN Contentions E6 - (Riddle and Ferdinand)
`JUN Contentions E7 - (Riddle and Ferdinand and Yu)
`JUN Contentions E8 - (Riddle and Ferdinand and Wakeman)
`JUN Contentions E9 - (Riddle and Ferdinand and Wakeman and Yu)
`JUN Contentions E10 - (Riddle and Ferdinand and Wakeman and
`RFC1945)
`JUN Contentions E11 - (Riddle and Ferdinand and Baker)
`JUN Contentions E12 - (Riddle and Ferdinand and Baker and Yu)
`JUN Contentions E13 - (Riddle and Ferdinand and RFC1945)
`JUN Contentions E14 - (Riddle and Ferdinand and Baker and
`RFC1945)
`JUN Contentions E15 - (Riddle and Ferdinand and Hasani)
`JUN Contentions E16 - (Riddle and Ferdinand and Hasani and Yu)
`JUN Contentions E17 - (Riddle and Ferdinand and Hasani and
`RFC1945)
`U.S. Patent No. 7,748,002 (“Beser”)
`File History for USPN 7,748,002 - October 3, 2006 Office Action
`U.S. Patent No. 7,706,357 (“Dyckerhoff”)
`File History for USPN 7,706,357 - June 30, 2009 Office Action
`January 18, 2019 Letter to Palo Alto Networks re Notice of
`Infringement
`January 18, 2019 Letter to Juniper Networks Inc re Notice of
`Infringement
`Withdrawn
`Complaint in Palo Alto Networks, Inc. v. Packet Intelligence LLC,
`No. 3:19-cv-02471-WHO (N.D. Cal.)
`Petition in IPR2019-01289
`Petition in IPR2019-01290
`Petition in IPR2019-01291
`
`iii
`
`

`

`2048
`2049
`2050
`
`2051
`
`2052
`
`2053
`2054
`2055
`2056
`2057
`2058
`2059
`
`2060
`
`2061
`2062
`2063
`2064
`2065
`2066
`
`2067
`
`2068
`
`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`Petition in IPR2019-01292
`Petition in IPR2019-01293
`Stay Order in Uniloc 2017 LLC v. Apple, Inc., No. 19-cv-01904-
`WHO (N.D. Cal.)
`Joint Motion to Amend the Scheduling Order in Palo Alto Networks,
`Inc. v. Packet Intelligence LLC, No. 3:19-cv-02471-WHO (N.D.
`Cal.)
`Order Granting PAN’s Proposed Modification to the Scheduling
`Order in Palo Alto Networks, Inc. v. Packet Intelligence LLC, No.
`3:19-cv-02471-WHO (N.D. Cal.)
`Petition in IPR2017-00450
`Petition in IPR2017-00451
`Petition in IPR2017-00629
`Petition in IPR2017-00630
`Petition in IPR2017-00769
`Petition in IPR2017-00869
`Final Judgment in Packet Intelligence LLC v. NetScout Systems, Inc.
`et. al., No. 2:16-cv-00230-JRG (E.D. Tex.)
`Packet Intelligence LLC v. NetScout Systems, Inc., et al, No. 2019-
`2041 (Fed. Cir. July 14, 2020) Decision
`Declaration of Cathleen T. Quigley
`CV of Cathleen T. Quigley
`Reserved
`RFC 768 - User Datagram Protocol
`RFC 1340 - Assigned Numbers
`Palo Alto Networks, Inc. v. Packet Intelligence LLC, No. 19-cv-
`02471-WHO, Dkt. No. 63 (June 4, 2020) (Packet Intelligence LLC’s
`Opening Claim Construction Brief)
`Palo Alto Networks, Inc. v. Packet Intelligence LLC, No. 19-cv-
`02471-WHO, Dkt. No. 67 (July 2, 2020) (Palo Alto Networks’
`Responsive Claim Construction Brief)
`Palo Alto Networks, Inc. v. Packet Intelligence LLC, No. 19-cv-
`02471-WHO, Dkt. No. 68 (July 21, 2020) (Packet Intelligence
`LLC’s Reply Claim Construction Brief)
`
`iv
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`Packet Intelligence LLC v. Juniper Networks, Inc., No. 19-cv-
`04741-WHO, Dkt. No. 57 (June 4, 2020) (Packet Intelligence LLC’s
`Opening Claim Construction Brief)
`Packet Intelligence LLC v. Juniper Networks, Inc., No. 19-cv-
`04741-WHO, Dkt. No. 62 (July 2, 2020) (Juniper’s Responsive
`Claim Construction Brief)
`Packet Intelligence LLC v. Juniper Networks, Inc., No. 19-cv-
`04741-WHO, Dkt. No. 68 (July 21, 2020) (Packet Intelligence
`LLC’s Reply Claim Construction Brief)
`Packet Intelligence LLC v. Juniper Networks, Inc., No. 19-cv-
`04741-WHO, Dkt. No. 71 (August 5, 2020) (Juniper’s Sur-Reply
`Claim Construction Brief)
`U.S. Patent No. 5,917,821 - Gobuyan
`U.S. Patent No. 5,850,388 - Anderson
`
`
`
`2069
`
`2070
`
`2071
`
`2072
`
`2073
`2074
`
`
`
`
`v
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`
`
`TABLE OF CONTENTS
`
`I. Introduction ........................................................................................................ 1
`
`II. Background ........................................................................................................ 2
`
`III. The ‘646 Patent Was a Leap Forward in Network Monitoring .................... 5
`A. The Prior Art Network Monitoring Techniques Did Not Monitor
`Traffic Based on Conversational Flows ........................................................... 6
`
`B. The ‘646 Patent Uses Conversational Flows—a Major Leap
`Forward ............................................................................................................ 8
`
`SAP Conversational Flow Example ........................................................10
`1.
`Streaming Media Conversational Flow Example ....................................11
`2.
`C. Conversational Flow Classification Overview ...............................................12
`
`IV. Overview of the Asserted Art .........................................................................16
`A. Riddle ..............................................................................................................16
`
`B. Ferdinand ........................................................................................................20
`
`C. Yu.....................................................................................................................20
`
`D. RFC 1945 ........................................................................................................21
`
`V. Level of Ordinary Skill in the Art ..................................................................22
`
`VI. Claim Construction .........................................................................................22
`A. “conversational flow” ....................................................................................23
`
`B. “flow-entry database” ....................................................................................26
`
`C. “the flow”/ “new flow”/ “existing flow” .......................................................31
`
`D. All Remaining Terms .......................................................................................32
`
`VII.
`
`The Board Should Limit Its Analysis to the Petition ............................32
`
`VIII. Argument ...................................................................................................34
`A. Riddle Fails to Teach “conversational flows” (All Grounds) ........................34
`
`vi
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`1. A Conversational Flow Activity Occurs Between Participating
`Network Devices .....................................................................................34
`2. Riddle Fails to Recognize Activities Between Particular
`Entities .....................................................................................................40
`3. Riddle Separately Categorizes Inbound and Outbound Traffic ...............44
`B. No Art Teaches the Claimed Flow-Entry Database (All Grounds) ................45
`
`C. Yu is Not Prior Art and Fails to Teach Conversational Flows
`(Ground 2) .......................................................................................................46
`
`1. Yu Is Not Prior Art ..................................................................................46
`2. Yu In Combination with Other Art Still Fails to Teach
`Conversational Flows ..............................................................................48
`Petitioners Have Not Shown an Apparent Reason to Combine
`Riddle and Yu..........................................................................................50
`D. RFC 1945 Fails to Teach Conversational Flows (Ground 3) ........................52
`
`3.
`
`E. The Prior Art Does Not Teach Conversational Flow State-Based
`Analysis (All Grounds) ....................................................................................53
`
`1. Claims 1-3 Implicate State-Based Analysis ............................................53
`2.
`The Board Already Rejected Similar Reasoning .....................................55
`F. The Alleged Prior Art Fails to Teach Claim 3 (All Grounds) ........................57
`
`IX. Conclusion ........................................................................................................59
`
`
`
`
`
`
`vii
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`TABLE OF AUTHORITIES
`
`Cases
`Aylus Networks, Inc. v. Apple Inc.,
`856 F.3d 1353 (Fed. Cir. 2017) .........................................................................30
`
`Catalina Mktg. Int’l, Inc. v. Coolsavings.com, Inc.,
`289 F.3d 801 (Fed. Cir. 2002) ...........................................................................25
`
`Cisco Systems, Inc. v. C-Cation Technologies, LLC,
`IPR2014-00454, Paper 12 (PTAB, Aug. 29, 2014) ...........................................34
`
`Cultor Corp. v. A.E. Staley Mfg. Co.,
`224 F.3d 1328 (Fed. Cir. 2000) .........................................................................25
`
`Dynamic Drinkware, LLC v. Nat’l Graphics, Inc.
`800 F.3d 1375 (Fed. Cir. 2015) .........................................................................47
`
`Function Media, L.L.C. v. Google Inc.,
`708 F.3d 1310 (Fed. Cir. 2013) .........................................................................48
`
`In re Giacomini,
`612 F.3d 1380 (Fed. Cir. 2010) .........................................................................47
`
`Intex Recreation Corp. v. Team Worldwide Corp.,
`IPR2018-00859, Paper 128 (PTAB Oct. 21, 2019) ...........................................47
`
`Juniper Networks, Inc. v. Packet Intelligence LLC,
`IPR2020-00335, Paper 19 (PTAB August 27, 2020 .........................................18
`
`Limelight Networks, Inc. v. Akamai Techs., Inc.,
`IPR2016-01894, Paper 8 (PTAB Mar. 8, 2017) ................................................35
`
`Multiform Desiccants, Inc. v. Medzam, Ltd.,
`133 F.3d 1473 (Fed. Cir. 1998) .........................................................................25
`
`Omega Eng’g, Inc. v. Raytek Corp.,
`334 F.3d 1314 (Fed. Cir. 2003) .........................................................................30
`
`On-Line Techs., Inc. v. Bodenseewerk Perkin-Elmer GMBH,
`386 F.3d 1133 (Fed. Cir. 2004) .........................................................................30
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) (en banc) .........................................................33
`
`Sandvine Corp., et al . v. Packet Intelligence, LLC,
`IPR2017-00630, Paper 9 (PTAB July 26, 2017) ...............................................27
`
`Sandvine Corp., et al. v Packet Intelligence, LLC,
`IPR2017-00629, Paper 8 (PTAB July 26, 2017) ...............................................27
`
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
` IPR2017-00862, Paper 8 (PTAB July 26, 2017) ..............................................27
`
`viii
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00450, Paper 8 (PTAB July 26, 2017) ...............................................27
`
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00451, Paper 8 (PTAB July 26, 2017) ...............................................27
`
`Sandvine Corp., et al. v. Packet Intelligence, LLC,
`IPR2017-00769, Paper 8 (PTAB July 26, 2017) ...............................................27
`
`Sinorgchem Co. v. ITC,
`511 F.3d 1132 (Fed. Cir. 2007) .........................................................................25
`
`Vitronics Corp. v. Conceptronic, Inc.,
`90 F.3d 1576 (Fed. Cir. 1996) ...........................................................................25
`
`Williamson v. Citrix Online, LLC,
`792 F.3d 1339 (Fed. Cir. 2015) .........................................................................48
`
`Statutes
`35 U.S.C. 112(f) .......................................................................................................48
`
`Rules
`37 C.F.R. § 42.22(a)(2) ............................................................................................34
`
`37 C.F.R. § 42.6(a)(3) ..............................................................................................35
`
`37 C.F.R. § 42.65(a) .................................................................................................47
`
`37 C.F.R. §42.104(b)(3) ...........................................................................................48
`
`
`
`
`
`
`
`ix
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`I. Introduction
`
`The Board should find that Petitioners have failed to meet their burden for
`
`proving unpatentability of any of the ‘646 Patent claims challenged in its Petition,
`
`which consist of claims 1-3, 7, 16, and 18 (“the challenged claims”). The Petition
`
`relies on three references to purportedly disclose the novel “conversational flows”
`
`of the ‘646 Patent: Riddle, Ferdinand, Wakeman, Yu, and RFC1945. None of these
`
`references teach “conversational flows,” and thus the Petitioners have failed to meet
`
`their burden to show the challenged claims are unpatentable.
`
`Petitioners’ arguments hinge on the untenable position that categorizing
`
`similar traffic types into “traffic classes” is enough to teach “conversational flows.”
`
`The term “conversational flow” is expressly defined by the specification, and
`
`Petitioners’ application of that language here conflicts with a critical aspect of that
`
`definition: a conversational flow relates to a particular activity, which involves
`
`specific network devices. Broadly classifying all network traffic into “classes,” as
`
`taught by Petitioners’ references, is not enough to anticipate or render obvious this
`
`critical aspect of the invention.
`
`Moreover, Petitioners’ arguments fail in other ways as well. The Petition
`
`relies on implicit incorporation by reference of a 525-page expert declaration to
`
`circumvent the word limits imposed by this Board. The Petition fails to prove that
`
`the prior art of record anticipates or renders obvious the state-based limitations of
`
`the challenged claims. The Petition also fails to prove Yu is prior art, fails to prove
`
`it contains the limitations for which Petitioner relies, and fails to show a viable
`
`motivation to combine the teachings of Yu with Riddle. For all these reasons and
`
`1
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`those explained in more detail below, the Board should confirm the challenged
`
`claims are patentable over Petitioners’ references.
`
`II. Background
`
`The ‘646 Patent inventions relate to monitoring network traffic with “real-
`
`time elucidation of packets communicated within a data network, including,
`
`classification according to protocol and application program.” Ex. 1001 at 1:39-42.
`
`As explained by the ‘646 Patent, prior art network monitoring systems categorized
`
`network transmissions into “connection flows.” Ex. 1001 at 2:34-37; Ex. 1016 at 8
`
`(3:3-10).1 A connection flow refers to the sequence of packets transmitted during a
`
`single connection between two network devices. One of the novel features of the
`
`‘646 Patent is the ability to identify connection flows related to the same network
`
`activity between the same parties and thereby recognize that those related flows
`
`constitute a “conversational flow.” 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 (such as a video conference call) on a server as requested
`
`
`
` The ’646 Patent incorporates by reference U.S. Provisional Patent
`
`
`
` 1
`
`Application No. 60/141,903 (Ex. 1016) and U.S. Patent No. 6,651,099 (Ex. 1001).
`
`See Ex. 1003 at 1:5-17. Thus, most citations to the challenged family of patents will
`
`be to the ’099 Patent and Provisional.
`
`2
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`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. Ex. 1001 at 2:34-45; Ex. 1016 at 8 (3:3-10); Ex. 2061 ¶¶41-51.
`
`Essentially, the network monitor disclosed in the ‘646 Patent categorizes
`
`network transmissions into “conversational flows” by relating one or more
`
`connection flows based on specific application activity by a particular user or client
`
`device. The ‘646 Patent also teaches other innovative techniques, such as the use of
`
`state operations and state-based flow analysis to help recognize and correlate the one
`
`or more connection flows that comprise a particular conversational flow. This
`
`approach differs from prior methods of identifying connections by their well-known
`
`ports, which only requires analyzing information within a packet header. The
`
`teachings of the ʼ646 Patent enable classification of all packets passing through a
`
`network, providing detailed insight and information to network managers and
`
`operators about who is using the network as well as the activities being conducted
`
`by those users over the network.
`
`Before delving into specifics, it is useful to understand certain fundamentals
`
`about network traffic, including the layering model often used for understanding and
`
`describing layered network communications. In a layered network model, each
`
`lower-level layer encapsulates information from higher-level layers for transmission
`
`across the network. On reception, these layers are unpacked (de-encapsulated) and
`
`the original payload data is provided to the intended recipient.
`
`Information is transmitted across packet-based data networks, such as the
`
`Internet, as data packets. Data packets are formatted in compliance with established
`
`3
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`rules known as protocols. To facilitate communications across various networks, the
`
`International Standards Organization (“ISO”) developed the Open Systems
`
`Interconnection (“OSI”) model. The OSI model defines a framework for
`
`implementing communications between any two network devices and divides the
`
`communication process into seven layers as shown below:
`
`Ex. 1001 at 9:35-50.
`
`Each layer provides specific functions to support the layers above it. The
`
`Physical layer (layer 1) is the lowest layer, while the Application layer (layer 7) is
`
`the highest layer. These layers provide a model for describing network
`
`communications, and each layer serves a particular purpose or function within the
`
`model. The Physical layer and Data Link layer (layer 2) address interfacing to
`
`hardware (e.g., network interface cards and MAC) as well as physical hardware
`
`connections, which include the transmission of raw data. The Network layer (layer
`
`3), which is next up the protocol stack, includes protocols such as the Internet
`
`Protocol, also known as IP, used to support network routing decisions that guide
`
`traffic through the Internet. Layer 4 (the Transport layer) is responsible for end-to-
`
`4
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`end (or host-to-host) communications across the network via protocols such as TCP
`
`and UDP.
`
`Layers 5 and 6 (Session and Presentation, respectively) provide additional
`
`abstractions between the Transport Layer (layer 4) and the Application Layer (layer
`
`7). The Application layer represents the application protocol used in a network
`
`communication and is typically the protocol that a user’s application employs to
`
`communicate. Such applications include, for example, email programs (e.g.,
`
`Outlook, Gmail), file sharing programs (e.g., Dropbox, FTP clients), video
`
`conferencing programs (e.g., Skype, Zoom, Teams), and streaming programs (e.g.,
`
`Netflix, Amazon Prime, HBO Max). As one example, the Skype application uses a
`
`proprietary protocol along with standard protocols for audio and video. Such
`
`application-level data is located in the Application layer of a data packet.
`
`The OSI model provides a basic framework for understanding: (1) high level
`
`networking; (2) how certain hardware and software elements interact; and (3) the
`
`relationship of specific information contained within packet payloads and headers.
`
`It also provides a mechanism to separate computer networking functions into
`
`discrete functional groups.
`
`III. The ‘646 Patent Was a Leap Forward in Network Monitoring
`
`Whereas the prior art network systems merely evaluate packets using
`
`conventional methods—comparing information pulled from a log file or lower-level
`
`packet header to “classify” traffic into categories—the techniques taught in the ‘646
`
`Patent are more sophisticated. The ‘646 Patent teaches the ability to examine the
`
`sequence of data packets in a flow and use state-based analysis to progressively
`
`5
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`identify the protocols used and the applications responsible for generating it,
`
`permitting robust network management and security. As explained below, one of the
`
`novel ways this is achieved is by conversational flow analysis, which provides an
`
`improvement over the capabilities of prior art monitors. See Ex. 2061 ¶¶44-51
`
`A. The Prior Art Network Monitoring Techniques Did Not Monitor Traffic
`Based on Conversational Flows
`
`The field of network monitoring has progressed throughout the years to keep
`
`up with ever increasing network complexity and sophistication. Early solutions
`
`involved logging network activities and retroactively reviewing those log files to
`
`determine what occurred within the network. See Ex. 1001 at 1:65-2:3. This
`
`approach cannot be performed in real-time, and it also imposes significant
`
`processing and storage loads on the network nodes responsible for capturing log
`
`data. See id. at 2:4-6, 2:17-23.
`
`Another common network monitoring technique involves “connection”
`
`monitoring, in which information about each connection made over the network is
`
`separately maintained. These connections are typically defined by a 5-tuple of
`
`information: (1) source address; (2) destination address; (3) transport protocol; (4)
`
`source port; and (5) destination port. See, e.g., id. at 32:52-61 (describing the 5-tuple
`
`as shown in exemplary packets 206-209 shown in Figure 2); Ex. 2061 ¶¶45-46, 61.
`
`Monitoring such information is referred to in the ʼ646 Patent as monitoring
`
`“connection flows” because it defines the connections for the packet transmissions
`
`being monitored.
`
`6
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`Monitoring only connection flows may yield some limited information about
`
`the application running at the source computer that generates the data packets. One
`
`of the earliest methods of application identification in network monitoring is called
`
`port-based classification, in which port numbers are used as a proxy to identify
`
`applications responsible for certain connection flows. A port can be thought of as
`
`part of, or a supplement to, a network address, which in some cases is assigned to
`
`perform particular services. The transport layer (layer 4) in a data packet contains
`
`both destination and source port information. See, e.g., Ex. 1039 at 19 (illustrating
`
`TCP header with source and destination ports); Ex. 2064 at 1 (illustrating UDP
`
`header with source and destination ports).
`
`Certain services are designated to run on specific ports. For example, port 80
`
`is assigned to HTTP by the Internet Assigned Numbers Authority (IANA). See Ex.
`
`2065 at 12 (defining “80/tcp” and “80/udp” as “World Wide Web HTTP” ports); see
`
`also id. at 9-26 (listing well-known port numbers for TCP and UDP along with their
`
`corresponding description). Because of this, prior art monitors would classify data
`
`packets using port 80 as HTTP traffic without looking at other information within
`
`the packet (e.g., packet payload or application layer information) to confirm this
`
`assumption. Thus, monitors of this type operated by only looking at information in
`
`the transport-layer headers (e.g., TCP or UDP information) and did not inspect
`
`higher level OSI layers to determine the activity involved in a particular network
`
`transmission.
`
`7
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`B. The ‘646 Patent Uses Conversational Flows—a Major Leap Forward
`
`Industry leaders in the area of networking systems, including Cisco and
`
`Huawei, have licensed the innovative technology described and claimed by the ʼ646
`
`Patent. As noted in the prior section, conventional network monitoring systems
`
`tracked connection flows. But a problem that the ‘646 inventors sought to address
`
`was the fact that these monitors failed to recognize whether disjointed connection
`
`flows were in fact related to each other. See Ex. 1001 at 3:48-51. “A flow is a stream
`
`of packets being exchanged between any two addresses in the network.” Id. at 12:4-
`
`5; Ex. 1016 at 45 (40:4-5). A “connection flow” is “all the packets involved with a
`
`single connection.” Ex. 1001 at 2:35-37; Ex. 1016 at 8 (3:3-5). The problem with
`
`only tracking individual connection flows is that certain applications and protocols
`
`may generate multiple separate connections during a single conversation. In other
`
`words, a single application through use by an individual user may spawn multiple
`
`connections to support a single network activity. For example, if user A wants to
`
`have a Skype call with user B, the Skype application may create multiple
`
`connections between computers A and B to conduct the call. There might be one
`
`connection that supplies setup information, a second connection that transmits video
`
`information, and a third connection that transmits audio information. Prior art
`
`monitoring systems treated each of these three different connection flows separately.
`
`The ’646 Patent, however, teaches the ability to recognize that such flows
`
`correspond to an activity—in this case, conducting a Skype call between two
`
`network devices. The patent further teaches that this set of related flows may be
`
`associated with each other into a “conversational flow.” The ʼ646 Patent allows each
`
`8
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`individual connection flow, involving an application running on a network device,
`
`to be analyzed to determine whether it forms part of an existing conversation, and if
`
`so, the individual connection flows may be related by the network monitoring
`
`system. See Ex. 2061 ¶¶52-57 (discussing conversational flow analysis of a
`
`conference).
`
`According
`
`to
`
`the explicit definition provided by
`
`the Patentees, 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” and “some conversational flows involve more than one
`
`connection, and some even involve more than one exchange of packets between a
`
`client and server.” Ex. 1001 at 2:37- 45; Ex. 1016 at 8 (3:5-10). One aspect that
`
`“distinguishes this invention from prior art network monitors is that it has the ability
`
`to recognize disjointed [connection] flows as belonging to the same conversational
`
`flow.” Ex. 1001 at 3:48-51; see also Ex. 1016 at 9 (4:13-14). Conversational flows
`
`are established, in part, by the invention’s “capabil[ity] of examining up to whatever
`
`level is sufficient to uniquely identify to a required level, even all of the way to the
`
`application level (in the OSI model).” Ex. 1001 at 4:13-16; see also Ex. 1016 at 30
`
`(25:3-5).
`
`The ability to monitor and analyze conversational flows is vital to a network
`
`administrator to gain further insight into who is using the network and for what
`
`purposes. This information is invaluable as it allows a network administrator to: (1)
`
`monitor attempted attacks on the network; (2) regulate and charge users for network
`
`9
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`use; and (3) provide improved quality of service to the entities using the network.
`
`See Ex. 2061 ¶¶51, 57.
`
`1. SAP Conversational Flow Example
`
`The specification provides an example of how conversational flows relate
`
`connection flows for a given activity involving a network device. See Ex. 2061 ¶¶58-
`
`60. The example involves the use of the SAP (Service Advertising Protocol)
`
`developed by NetWare. See Ex. 1001 at 2:49-52. SAP “identif[ies] the services and
`
`addresses of servers attached to a network.” Id. at 2:51-52. In this example, a client
`
`might send an SAP request to determine the appropriate server to use for printing
`
`services. See id. at 2:52-53. In response, the SAP server would send an SAP reply
`
`identifying the address information for the print service. See id. at 2:53-56. At this
`
`point, the original client can send a print request to the identified service. Each
`
`exchange represents an individual connection flow—the first is between the client
`
`and SAP server; the second is between the client and print service. See id. at 2:64-
`
`67. “In order to eliminate the possibility of disjointed conversational exchanges, it
`
`is desirable for a network packet monitor to be able to ‘virtually concatenate’—that
`
`is, to link—the first exchange with the second.” Id. at 3:1-4. The network monitor
`
`associates these independent connection flows into a conversational flow by
`
`identifying that the clients were the same in both flows. Id. at 3:8-13 (“If the clients
`
`10
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`were the same, the two packet exchanges would then be correctly identified as being
`
`part of the same conversational flow.”)2.
`
`Conversely, if a second different client sends a print request to the print
`
`service, that exchange between the second client and print service represents a
`
`different conversational flow than the two exchanges from the same client detailed
`
`above—i.e., the second client is starting a different activity than the first client, even
`
`though both clients are requesting print services. See id. at 2:52-67. In that case
`
`(when the clients were not the same), the packet monitor would correctly recognize
`
`that the exchange from the second client represented a different conversational flow
`
`corresponding to a different print request activity than that of t