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 PRELIMINARY RESPONSE UNDER 37
`C.F.R. § 42.107 TO PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 6,771,646
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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 Exhibits
`
`EXHIBIT LIST
`
`Exhibit
`2001
`2002
`
`2003
`
`2004
`2005
`
`2006
`
`2007
`
`2008
`2009
`2010
`2011
`2012
`2013
`2014
`2015
`
`2016
`2017
`2018
`2019
`2020
`
`2021
`
`2022
`
`Description
`Almeroth Declaration
`Packet Intelligence LLC v. Sandvine Corp., No. 2:16-cv-00147,
`Dkt. 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)
`JUN Contentions C8 - (Riddle and Ferdinand and Wakeman and
`RFC1945)
`JUN Contentions D6 - (Riddle and Ferdinand)
`
`ii
`
`

`

`
`
`
`
`2023
`2024
`2025
`2026
`2027
`2028
`
`2029
`
`2030
`2031
`2032
`2033
`
`2034
`2035
`2036
`
`2037
`2038
`2039
`2040
`2041
`
`2042
`
`2043
`
`JUN Contentions D7 - (Riddle and Ferdinand and Yu)
`JUN Contentions D8 - (Riddle and Ferdinand and RFC1945)
`JUN Contentions E6 - (Riddle and Ferdinand) 789
`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
`Almeroth CV
`
`
`iii
`
`

`

`
`
`TABLE OF CONTENTS
`
`I.
`
`Introduction .......................................................................................................... 1
`
`II. Summary of the Argument .................................................................................. 1
`
`III. Background .......................................................................................................... 2
`
`A. The OSI Model ................................................................................................. 4
`
`B. Data Encapsulation ........................................................................................... 5
`
`C. Prior Art Methods ............................................................................................. 8
`
`IV. Overview of the ’646 Invention ........................................................................... 9
`
`A. Conversational Flow Classification Process Overview .................................12
`
`B. Benefits of Conversational Flows Over Prior Art Systems ...........................16
`
`V. Overview of Asserted Prior Art .........................................................................18
`
`A. Riddle ..............................................................................................................18
`
`B. Yu ...................................................................................................................19
`
`C. RFC 1945 ........................................................................................................20
`
`VI. Claim Construction ............................................................................................21
`
`A. Level of Ordinary Skill in the Art ..................................................................21
`
`B. “conversational flow”/“conversational flow-sequence” ................................21
`
`C. Remaining Terms ...........................................................................................26
`
`VII.
`
`Argument ....................................................................................................26
`
`A. The Board Should Deny Institution Under § 314(a) ......................................27
`1.
`Institution Would Not Provide an Effective and Efficient
`Alternative to Ongoing Litigation ...................................................28
`2. The General Plastic Factors Warrant Discretionary Denial
`Under § 314(a) .................................................................................34
`
`B. Ground 1 - Riddle Fails to Disclose “conversational flows” .........................37
`1. Service Aggregates Are Not “conversational flows” ..............................41
`2. Riddle’s Recognition of PointCast Traffic Fails to Disclose
`“conversational flows” .....................................................................43
`
`C. Ground 2 - There Is No Apparent Reason to Combine Yu with
`
`Riddle ..........................................................................................................44
`
`D. Ground 2 - Yu Fails to Disclose “conversational flows” ...............................46
`
`E. Ground 3 - RFC 1945 Fails to Disclose “conversational flows” ...................47
`
`iv
`
`

`

`
`
`VIII. Conclusion ..................................................................................................48
`VIII.
`Conclusion .................................................................................................. 48
`
`
`
`
`
`
`v
`
`

`

`
`
`TABLE OF AUTHORITIES
`
`Cases
`Advanced Bionics, LLC v. MED-EL Elektromedizinische Geräte GmbH,
`IPR2019-01469, Paper 6 (P.T.A.B. Feb. 13, 2020) ...........................................35
`
`Apple Inc. v. Fintiv, Inc.,
`IPR2020-00019, Paper 11 (P.T.A.B. Mar. 20, 2020) ........................................28
`
`Apple Inc. v. Fintiv, Inc.,
`IPR2020-00019, Paper 15 (P.T.A.B. May 13, 2020) ................................. 28, 29
`
`Aylus Networks, Inc. v. Apple Inc.,
`856 F.3d 1353 (Fed. Cir. 2017) .........................................................................23
`
`General Plastic Industrial Co., Ltd. v. Canon Kabushiki Kaisha,
`IPR2016-01357, Paper 19 (P.T.A.B. Sept. 6, 2017) .................................. 28, 34
`
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) ...........................................................................................45
`
`Microsoft Corp. v. Enfish, LLC,
`662 F. App’x 981 (Fed. Cir. 2016) ....................................................................45
`
`NHK Spring Co. Ltd. v. Intri-Plex Techs. Inc.,
`IPR2018-00752, Paper 8 (P.T.A.B. Sept. 12, 2018) .........................................28
`
`Omega Eng’g, Inc. v. Raytek Corp.,
`334 F.3d 1314 (Fed. Cir. 2003) .........................................................................23
`
`Packet Intelligence LLC v. Netscout Sys., Inc.,
`No. 2:16-cv-230, Dkt. No. 66 (E.D. Tex. Mar. 15, 2017) .................................22
`
`Sandvine Corp. v. Packet Intelligence, LLC,
`IPR2017-00450, Paper 8 (P.T.A.B. July 26, 2017) .......................................2, 21
`
`Sandvine Corp. v. Packet Intelligence, LLC,
`IPR2017-00451, Paper 8 (P.T.A.B. July 26, 2017) .......................................2, 22
`
`Sandvine Corp. v. Packet Intelligence, LLC,
`IPR2017-00629, Paper 8 (P.T.A.B. July 26, 2017) .......................................2, 22
`
`Sandvine Corp. v. Packet Intelligence, LLC,
`IPR2017-00630, Paper 9 (P.T.A.B. July 26, 2017) .......................................2, 22
`
`Sandvine Corp. v. Packet Intelligence, LLC,
`IPR2017-00769, Paper 8 (P.T.A.B. July 26, 2017) .......................................2, 22
`
`Sandvine Corp. v. Packet Intelligence, LLC,
`IPR2017-00862, Paper 8 (P.T.A.B. July 26, 2017) .......................................2, 22
`
`U.S. Surgical Corp. v. Ethicon, Inc.,
`103 F.3d 1554 (Fed. Cir. 1997) .........................................................................24
`
`vi
`
`

`

`
`
`Statutes
`35 U.S.C. § 314 ................................................................................................ passim
`
`35 U.S.C. § 316 ........................................................................................................30
`
`35 U.S.C. § 325 ........................................................................................................35
`
`Regulations
`37 C.F.R. § 42.100 ...................................................................................................26
`
`
`
`
`
`vii
`
`

`

`
`
`I. Introduction
`
`The Board should refuse to institute inter partes review of U.S. Patent No.
`
`6,771,646 (“the ’646 Patent,” Ex. 1003) because Petitioners have not shown a
`
`reasonable likelihood of prevailing on the invalidity grounds presented on claims 1-
`
`3, 7, 16, and 18 of the ’646 Patent (“the challenged claims”). The Petition relies on
`
`three references to purportedly disclose the novel “conversational flows” of the ’646
`
`Patent: U.S. Patent No. 6,412,000 (“Riddle,” Ex. 1008); U.S. Patent No. 6,625,150
`
`(“Yu,” Ex. 1011); and RFC 1945 (Ex. 1010). As detailed below, none of these
`
`references teach the claimed “conversational flows,” and thus the Petition fails to
`
`establish a reasonable likelihood that Petitioners will prevail in their IPR challenges.
`
`II. Summary of the Argument
`
`The instant petition is ripe for discretionary denial under 35 U.S.C. § 314(a)
`
`for at least two reasons. First, there are two parallel district court proceedings
`
`involving the same patents, the same parties, and the same asserted art. The district
`
`court expressed that it does not intend to enter a stay in these proceedings, and trial
`
`is set for both proceedings within days of the time a final written decision would
`
`likely be rendered. The parties have also invested considerable resources in the
`
`district court proceedings, including substantial discovery and ongoing claim
`
`construction. Given the state of the parallel proceedings, the Board should deny the
`
`instant petition to avoid duplicative efforts about essentially the same issues raised
`
`in this petition.
`
`Additionally, the ’646 Patent and its family members have been subjected to
`
`at least six other IPR Petitions filed by Sandvine Corporation, all of which were
`
`1
`
`

`

`
`
`conducted under the “broadest reasonable interpretation” standard that the Office
`
`applied at the time of those proceedings. 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; IPR2017-00630, Paper 9 at 7-9; IPR2017-
`
`00769, Paper 8 at 8-10; IPR2017-00862, Paper 8 at 7-10 (all P.T.A.B. July 26, 2017).
`
`The Board should further exercise its discretion under § 314(a) because the ’646
`
`Patent has been subjected to serial petitions in the past.
`
`Finally, none of the asserted art discloses or teaches the claimed
`
`“conversational flows” of the ’646 Patent. This is precisely the conclusion the Board
`
`reached in the earlier IPRs involving this same patent family. As detailed below,
`
`“conversational flows” relate to an activity performed by a user or a client. Thus,
`
`different users performing the same type of activity would yield different
`
`conversational flows. But, the art raised by Petitioners treats packets corresponding
`
`to the same type of activity identically—it does not differentiate between activities
`
`based on the underlying user or client performing or initiating the activity. For these
`
`reasons, the Board should decline to institute trial.
`
`III. Background
`
`The ’646 Patent discloses improved techniques for monitoring traffic over a
`
`computer network. Conventional prior art network monitors categorize network
`
`transmissions into “connection flows.” ’099 Patent at 2:34-37; Provisional at 3:3-10
`
`2
`
`

`

`
`
`(Ex. 1016 at 8).1 A connection flow refers to the sequence of packets involved in a
`
`single connection. One of the novel features of the ’646 Patent, and the focus of the
`
`arguments in this preliminary response, is the ability to relate different connection
`
`flows to one another into “conversational flows” to the extent that those connection
`
`flows relate to the same activity. As will be described in more detail below, 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 Skype
`
`call) 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. ’099 Patent at 2:34-45; Provisional at 3:3-10
`
`(Ex. 1016 at 8).
`
`Essentially, the network monitor disclosed in the ’646 Patent categorizes
`
`network transmissions into “conversational flows,” which relate one or more
`
`connection flows with each other based on specific application activity by a
`
`particular user or client. In addition, the ’646 Patent teaches other innovative
`
`techniques, including the use of state operations and state of the flow analysis to help
`
`identify conversational flows, which differs from prior methods of identifying
`
`applications by their well-known ports. These teachings enable classification of all
`
`
`
`1 The ’646 Patent incorporates by reference U.S. Provisional Patent Application No.
`
`60/141,903 (Ex. 1016, “Provisional”) and U.S. Patent No. 6,651,099 (Ex. 1001, “the
`
`’099 Patent”). See ’646 Patent at 1:7-18. Accordingly, most citations regarding the
`
`challenged family of patents will be to the ’099 Patent and Provisional.
`
`3
`
`

`

`
`
`packets passing through a network, providing detailed insight and information to
`
`network managers and operators regarding activity and bandwidth consumption
`
`occurring on the network.
`
`Before delving into specifics, it is useful to understand certain fundamentals
`
`regarding network traffic, as well as a brief, high-level overview of the evolution of
`
`network monitoring.
`
`A. The OSI Model
`
`Information is transmitted across networks, such as the Internet, as data
`
`packets. Ex. 2001 ¶ 44 (hereinafter “Almeroth”). Data packets are formatted in
`
`compliance with established rules known as protocols. Id. To facilitate
`
`communications across various networks, the International Standards Organization
`
`(“ISO”) developed the Open Systems Interconnection (“OSI”) model. Id. 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:
`
`’099 Patent at 9:35-50; Almeroth ¶ 44.
`
`4
`
`

`

`
`
`Each layer provides specific functions to support the layers above it. The
`
`Application layer (layer 7) is the highest layer, while the Physical layer (layer 1) is
`
`the lowest layer. Almeroth ¶ 45. These layers provide a model for describing
`
`common formats used in network communications. Id. Each layer serves a particular
`
`purpose within the network communication model. Id. 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 (for example, email
`
`program, web browser, etc.). Id. For instance, the Skype application uses a
`
`proprietary protocol along with standard protocols for audio and video—if required.
`
`Similarly, web browsers use the HTTP protocol. Such application level data is
`
`located in the Application layer of a data packet. Id.
`
`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. Almeroth ¶ 46. The Physical layer (layer 1) includes protocols
`
`such as Ethernet, which control the transmission of raw data on the wire. Id.
`
`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 a packet. Almeroth ¶ 47. It
`
`serves a generic means to separate computer networking functions into discrete
`
`functional groups. Id.
`
`B. Data Encapsulation
`
`Encapsulation enables protocol layering, which is taking a higher-level
`
`protocol message and packaging it into one or more lower‐level protocol messages.
`
`5
`
`

`

`
`
`Almeroth ¶ 48. Several layers, or protocols, may be involved in a single network
`
`communication. Id. At the beginning of a network transmission, an application
`
`writes a message or data in an application layer protocol, for example, HTTP or the
`
`Skype protocol—this is OSI layer 7. Id. The message is represented by the red block
`
`called “DATA” at the top right in the image below. Id.
`
`In order to send the actual message to another computer across a network, the
`
`application data (i.e., the “DATA” block in the image above) is encapsulated.
`
`Encapsulation appends additional headers for other lower level layers in the OSI
`
`model to the application layer data. Almeroth ¶ 49. The image above illustrates this
`
`by the addition of “H” blocks (i.e., headers) to the left of the application message at
`
`each lower OSI level. Id. Each header contains information that helps components
`
`in the network (switches, routers, gateways, etc.) route the data packet to its
`
`destination. Id.
`
`Before transmission, and after possible encapsulation in layers 6, 5, and 4, a
`
`message may be broken into one or more IP messages (or packets) that are
`
`6
`
`

`

`
`
`constructed in conformance with the IP protocol. Almeroth ¶ 50. The IP protocol
`
`layer is layer 3. Id. Each of these IP packets includes a header with information
`
`specific to the IP protocol, such as the source IP address, destination IP address, and
`
`the length of the packet. Id. A data portion that includes a fragment of the higher‐
`
`level protocol transmission follows the header, as the image above illustrates. Id. At
`
`this point, the original message has been fragmented and encapsulated into multiple
`
`IP messages. Id. Stated differently, a single layer 7 message is encapsulated into a
`
`set of layer 3 messages. Id. In relation to the image above, the “DATA” block seen
`
`in the Application layer, may be split into smaller blocks at the layer 3 and spread
`
`across several IP packets.
`
`Each of these layer 3 IP messages may be further encapsulated into one or
`
`more lower layer messages (or packets), such as Ethernet. Almeroth ¶ 51. The
`
`Ethernet packets will have a header with Ethernet‐specific information, while the
`
`data portion will contain the pieces of data that comprise the IP message. Id. The
`
`original message may undergo multiple encapsulation steps. Id.
`
`After the encapsulation process is complete, the Ethernet (layer 1) packets are
`
`placed directly on the wire for transmission. Almeroth ¶ 52. The receiving computer
`
`receives the Ethernet messages, where the messages will be unpacked and
`
`recombined to form the original message—first combining the Ethernet messages to
`
`create the IP messages. Id. During this process, the headers of the Ethernet packets
`
`are removed, and the data portions concatenated to form an IP message. Id. Then,
`
`the IP messages will be combined to create the original message again on the
`
`receiving computer, which is then processed by the appropriate application on the
`
`7
`
`

`

`
`
`receiving computer. Id. In other words, once reassembled, the destination computer
`
`will have the same “DATA” block originally transmitted. Id.
`
`C. Prior Art Methods
`
`The field of network monitoring has evolved throughout the years to keep up
`
`with ever increasing network complexity and sophistication. Almeroth ¶ 53. One of
`
`the earliest methods of application identification in network monitoring is called
`
`static packet filtering, in which port numbers are used as a proxy to identify
`
`applications. Id. A port can be thought of as part of an address for implementing
`
`services. Id. Specifically, the transport layer (layer 4) in a data packet contains both
`
`destination and source computer port information. Certain services are known to run
`
`on specific ports. Id. For example, HTTP traffic traditionally utilizes port 80. Id.
`
`Because of this, prior art monitors would classify any data packets utilizing port 80
`
`as HTTP traffic without looking at the packet’s payload to confirm this assumption.
`
`Id. The static packet filtering method only looks at information in the transport
`
`headers and does not delve further into higher level OSI layers to provide detailed
`
`information about the actual data being transmitted/received. Id.
`
`Later improvements in network monitoring led to “stateful packet filtering.”
`
`Almeroth ¶ 54. Stateful packet filtering operates on a connection flow basis and
`
`allows traffic from outside of a network to communicate with a device on the inside
`
`of a network on a bi-directional connection flow basis when the communication
`
`originated from inside the network. Id. This method has the same limitations as static
`
`packet filtering in terms of its ability to identify application layer protocols or
`
`applications. Id.
`
`8
`
`

`

`
`
`More complex methods of network monitoring that examine higher level OSI
`
`layer data are generally called Deep Packet Inspection (“DPI”). Almeroth ¶ 55.
`
`Depending on implementation, DPI can look beyond transport level headers, deeper
`
`into the packet, and provide detailed information about the actual data contained in
`
`a packet and the application responsible for generating such packets. Id. This more
`
`refined approach allows network operators to develop sophisticated rules for
`
`network operation and can help prevent viruses and other undesirable content from
`
`entering a network. Id. In addition, greater insight into network traffic allows for
`
`implementing business models such as bandwidth shaping and charging users for
`
`utilizing specific types of content (for example, video downloads or streaming).
`
`The techniques taught in the ’646 Patent are more sophisticated than
`
`traditional static filtering and stateful packet filtering. Almeroth ¶ 56. Indeed, the
`
`invention teaches the ability to examine data packets and identify the protocols used
`
`and the applications responsible for generating them, permitting robust network
`
`monitoring. Id. As will be 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. Id.
`
`IV. Overview of the ’646 Invention
`
`The ’646 Patent was filed on June 30, 2000, and claims priority to provisional
`
`application 60/141,903 filed on June 30, 1999.
`
`One problem that the ’646 inventors desired to solve concerns disjointed
`
`flows. Prior art monitors could keep track of connection flows. “A flow is a stream
`
`of packets being exchanged between any two addresses in the network.” ’099 Patent
`
`9
`
`

`

`
`
`at 12:4-5; Provisional at 40:4-5 (Ex. 1016 at 45). A “connection flow” is “all the
`
`packets involved with a single connection.” ’099 Patent at 2:35-37; Provisional at
`
`3:3-5 (Ex. 1016 at 8). The problem with only tracking connection flows is that
`
`certain applications and protocols may generate multiple connections. In other
`
`words, a single application may spawn multiple connections for a single 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 monitors would consider these three separate connections even
`
`though they originated from a single Skype call.
`
`According to 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.” ’099 Patent at 2:37-
`
`45; Provisional at 3:5-10 (Ex. 1016 at 8). One aspect that “distinguishes this
`
`invention from prior art network monitors is that it has the ability to recognize
`
`disjointed flows as belonging to the same conversational flow.” ’099 Patent at 3:48-
`
`51; see also Provisional at 4:13-14 (Ex. 1016 at 9). 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
`
`10
`
`

`

`
`
`application level (in the OSI model).” ’099 Patent at 4:13-16; see also Provisional
`
`at 25:3-5 (Ex. 1016 at 30).
`
`The specification provides an example that illustrates how conversational
`
`flows relate connection flows for an activity. The example involves the use of the
`
`SAP (Service Advertising Protocol) developed by NetWare. See ’099 Patent 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
`
`server would send an SAP reply identifying the appropriate server for handling print
`
`services. See id. at 2:53-56. At this point, the original client can send a print request
`
`to the identified server. Each of these exchanges represent a connection flow—the
`
`first is between the client and SAP server; the second is between the client and print
`
`server. 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. However, the specification contemplates another scenario in which a second
`
`(different) client sends a print request to the print server. See, e.g., id. at 2:58-64. In
`
`this scenario, the exchange between the second client and print server represents a
`
`different conversational flow than the two exchanges from the same client detailed
`
`above—i.e., the second client is initiating a different activity than the first client,
`
`even though both clients are requesting print services. See id. at 3:4-6 (“If the clients
`
`were the same, the two packet exchanges would then be correctly identified as being
`
`part of the same conversational flow.” (emphasis added)). Conversely, if the clients
`
`11
`
`

`

`
`
`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 the first client.
`
`A. Conversational Flow Classification Process Overview
`
`The following discussion describes a preferred embodiment of the invention
`
`as described in the patent specification. Figure 3 from the patent depicts “a functional
`
`block diagram of a process embodiment of the present invention that can operate as
`
`the packet monitor . . . ”:
`
`’099 Patent at 7:47-50, Fig. 3.
`
`The monitor described in the ’646 Patent examines network traffic passing a
`
`connection point in a network. ’099 Patent at Abstract, 5:12-15; see also Provisional
`
`at 15:7-8 (Ex. 1016 at 20). The monitor receives packets from a network and passes
`
`them to a
`
`12
`
`

`

`
`
`[p]arser subsystem 301 [that] examines the packets using pattern
`
`recognition process 304 that parses the packet and determines the
`
`protocol types and associated headers for each protocol layer that exists
`
`in the packet 302. An extraction process 306 in parser subsystem 301
`
`extracts characteristic portions (signature information) from the packet
`
`302. Both the pattern information for parsing and the related extraction
`
`operations, e.g., extraction masks, are supplied from a parsing-pattern-
`
`structures and extraction-operations database (parsing/extractions
`
`database) 308 filled by the compiler and optimizer 310.
`
`’099 Patent at 12:12-22; see also Provisional at 18:4-10 (Ex. 1016 at 23).
`
`The information from the parser sub-system is passed to an analyzer
`
`subsystem where the information extracted by the parser is compared to “an internal
`
`data store of records of known flows that the system has already encountered, and
`
`decides (in 316) whether or not this particular packet belongs to a known flow as
`
`indicated by the presence of a flow-entry matching this flow in a database of known
`
`flows 324. A record in database 324 is associated with each encountered flow.” ’099
`
`Patent at 13:54-61; see also Provisional at 41:15-18 (Ex. 1016 at 46). As seen in
`
`Figure 3, above, the analyzer sub-system contains an extensive flow chart for
`
`processing extracted packet information. According to the Patentees:
`
`[P]ackets may need to be examined before the conversational flow can
`
`be identified as being associated with the application program.
`
`Typically, monitor 108 is simultaneously also in partial completion of
`
`identifying other packet exchanges that are parts of conversational
`
`flows associated with other applications. One aspect of monitor 108 is
`
`its ability to maintain the state of a flow. The state of a flow is an
`
`indication of all previous events in the flow that lead to recognition of
`
`13
`
`

`

`
`
`the content of all the protocol levels, e.g., the ISO model protocol
`
`levels.
`
`’099 Patent at 10:24-33; see also Provisional at 16:1-7 (Ex. 1016 at 21).
`
`The analyzer sub-system preferably includes a state processor database 326,
`
`which provides information about “the different states and state transitions that occur
`
`in different conversational flows, and the state operations that need to be performed
`
`(e.g., patterns that need to be examined and new signatures that need to be built)
`
`during any state of a conversational flow to further the task of analyzing the
`
`conversational flow.” ’099 Patent at 12:50-55. The state processor database provides
`
`information to the state processor 328 which
`
`analyzes both new and existing flows in order to analyze all levels of
`
`the protocol stack, ultimately classifying the flows by application (level
`
`7 in the ISO model). It does this by proceeding from state-to-state based
`
`on predefined state transition rules and state operations as specified in
`
`state processor instruction database 326. A state transition rule is a rule
`
`typically containing a test followed by the next-state to proceed to if the
`
`test result is true…The state processor goes through each rule and each
`
`state process until the test is true, or there are no more tests to perform.
`
`’099 Patent at 14:63-15:9; see also Provisional at 19:26-20:3 (Ex. 1016 at 24-25).
`
`The analysis of extracted pac