Paper No. 6
`
`Filed: April 28, 2017
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`___________________
`
`SANDVINE CORPORATION and SANDVINE INCORPORATED ULC,
`
`PETITIONERS,
`
`V.
`
`PACKET INTELLIGENCE, LLC,
`
`PATENT OWNER.
`
`___________________
`
`Case No. IPR2017-00450
`U.S. Patent No. 6,771,646
`___________________
`
`
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`UNDER 35 U.S.C. § 313 AND 37 C.F.R. § 42.107
`
`
`
`
`
`
`
`

`

`
`
`
`
`TABLE OF CONTENTS
`
`STATEMENT OF MATERIAL FACTS IN DISPUTE ................................ 1
`I.
`INTRODUCTION .......................................................................................... 1
`II.
`III. OVERVIEW OF THE TECHNOLOGY AND STATE OF THE PRIOR
`ART
` ........................................................................................................................ 2
`A. The OSI Model ............................................................................................... 4
`B. Data Encapsulation ......................................................................................... 6
`C. Prior Art Methods ........................................................................................... 9
`IV. OVERVIEW OF THE ‘646 INVENTION .................................................. 11
`A. Conversational Flow Classification Process Overview ............................... 13
`B. Benefits of Conversational Flows Over Prior Art Systems ......................... 18
`V.
`CLAIM CONSTRUCTION ......................................................................... 20
`A. Level of Ordinary Skill in the Art ................................................................ 22
`B. “Conversational Flow” (claims 1-3 and 7-20) ............................................. 23
`C. “State of the Flow” (claims 1, 12, 20) .......................................................... 25
`D. “State Operations” (claims 1, 12-14, 20) ..................................................... 28
`E. “Parser Record” (claims 7, 16, 18) ............................................................... 30
`F. “a state processor […] to perform any state operations required for the
`initial state of the new flow in the case that the packet is from an existing
`flow” (claim 12) ........................................................................................... 30
`THE PETITION DOES NOT SATISFY THE REQUIREMENTS FOR
`VI.
`INSTITUTING INTER PARTES REVIEW ............................................................. 31
`A. Overview of Engel ........................................................................................ 32
`1. Dialog in Engel ........................................................................................... 33
`2. Engel’s “State” Disclosure .......................................................................... 38
`B. Operation of Engel Compared to Operation of ‘646 Invention ................... 40
`
`
`
`i
`
`

`

`
`
`C. The Board Should Deny Institution Because Engel Fails To Disclose
`Conversational Flows ................................................................................... 46
`1. Application Level Dialogs .......................................................................... 49
`2. Application-Specific Server Statistics ........................................................ 53
`3. The Petition Fails to Articulate a Prima Facie Case of Obviousness ........ 54
`VII. CONCLUSION ............................................................................................ 56
`
`
`
`
`
`
`
`
`
`
`ii
`
`

`

`
`
`Cases
`
`TABLE OF AUTHORITIES
`
`Advanced Display Sys. Inc. v. Kent State Univ.,
`212 F.3d 1272 (Fed. Cir. 2000) ............................................................................ 21
`Anderson v. Eppstein,
`59 U.S.P.Q.2d 1280 (B.P.A.I. 2001) .................................................................... 51
`Apple, Inc. v. Achates Reference Publishing, Inc.,
`IPR2013-00080, Paper 22 (PTAB June 3, 2013) ................................................. 27
`Becton Dickinson & Co. v. C.R. Bard, Inc.,
`922 F.2d 792 (Fed. Cir. 1990) .............................................................................. 29
`Cisco Systems, Inc. v. C-Cation Techs., LLC,
`IPR2014-00454, Paper 12 (PTAB Aug. 29, 2014) .............................................. 50
`Cuozzo Speed Techs., LLC v. Lee,
`No. 15-446, 136 S. Ct. 2131 (June 20, 2016) ...................................................... 21
`Cynosure, Inc. v. Cooltouch, Inc.,
`660 F. Supp. 2d 128 (D. Mass. 2009) .................................................................. 55
`DeSilva v. DiLeonardi,
`181 F.3d 865 (7th Cir. 1999)................................................................................ 50
`Digital-Vending Services Int’l, LLC v. Univ. of Phoenix, Inc.,
`672 F.3d 1270 (Fed. Cir. 2012) ............................................................................ 30
`Douglas Dynamics, LLC v. Buyers Prods. Co.,
`No. 09-cv-261, 2014 U.S. Dist.,
` LEXIS 33812 (W.D. Wis. Mar. 13, 2014) ........................................................... 56
`Ecolab, Inc. v. FMC Corp.,
`569 F.3d 1335 (Fed. Cir. 2009) ............................................................................ 29
`In re Translogic Tech., Inc.,
`504 F.3d 1249 (Fed. Cir. 2007) ............................................................................ 21
`Microsoft Corp. v. Proxyconn, Inc.,
`789 F.3d 1292 (Fed. Cir. 2015) ............................................................................ 21
`Microsoft Corp. v. Proxyconn, Inc.,
`IPR2016-00026, Paper 17 (PTAB Dec. 21, 2012) .............................................. 25
`Net MoneyIN, Inc. v. VeriSign, Inc.,
`545 F.3d 1359 (Fed. Cir. 2008) ............................................................................ 54
`
`
`
`iii
`
`

`

`
`
`Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co.,
`No. 2016-1900, 2017 U.S. App.,
` LEXIS 4416 (Fed. Cir. Mar. 14, 2017) ................................................................ 55
`NTP, Inc. v. Research In Motion, Ltd.,
`418 F.3d 1282 (Fed. Cir. 2005) ............................................................................ 22
`S.S. Steiner, Inc. v. John I Hass, Inc.,
`IPR2014-01490, Paper 7 (PTAB March 16, 2015) ...................................... 47, 50
`SimpleAir, Inc. v. Google Inc.,
`No. 2:11-cv-416, 2014 U.S. Dist.,
` LEXIS 138027 (E.D. Tex. Sept. 30, 2014) .......................................................... 55
`Sys. Div., Inc. v. Teknek LLC,
`59 F. App’x 333 (Fed. Cir. 2003) ........................................................................ 22
`Thorner v. Sony Comp. Entm’t Am. LLC,
`669 F.3d 1362 (Fed. Cir. 2012) ............................................................................ 21
`U.S. Surgical Corp. v. Ethicon, Inc.,
`103 F.3d 1554 (Fed. Cir. 1997) ............................................................................ 55
`United States v. Dunkel,
`927 F.2d 955 (7th Cir. 1991)................................................................................ 51
`Zetec, Inc. v. Westinghouse Electric Company, LLC,
`IPR2014-00384, Paper 10 (PTAB July 23, 2014) ............................................... 27
`Statutes
`
`35 U.S.C. § 313 .......................................................................................................... 1
`35 U.S.C. § 314(a) .................................................................................................1, 2
`Rules
`
`37 C.F.R. § 42.100(b) .............................................................................................. 15
`37 C.F.R. § 42.107(a) .......................................................................................... 1, 28
`37 C.F.R. § 42.108(b) .............................................................................................. 28
`37 C.F.R. § 42.22(a)(2) ............................................................................................ 50
`37 C.F.R. § 42.23(a) ................................................................................................... 1
`37 C.F.R. § 42.6(a)(3) ....................................................................................... 44, 49
`37 C.F.R. 42.104(b)(3) ............................................................................................. 20
`37 CFR § 42.24(c)(1) ................................................................................................. 1
`37 CFR § 42.24(d) ..................................................................................................... 1
`
`
`
`iv
`
`

`

`
`
`I.
`
`STATEMENT OF MATERIAL FACTS IN DISPUTE
`
`Petitioners Sandvine, Inc. and Sandvine Incorporated ULC (“Petitioners”)
`
`did not submit a statement of material facts in its Petition for inter partes review.
`
`Paper 2 (Petition or “Pet.”). Accordingly, no response to a statement of material
`
`facts is due pursuant to 37 C.F.R. § 42.23(a), and no facts are admitted.
`
`II.
`
`INTRODUCTION
`
`Patent Owner Packet Intelligence, LLC (“Patent Owner”) respectfully
`
`submits this Preliminary Response under 35 U.S.C. § 313 and 37 C.F.R. §
`
`42.107(a), which is timely filed on or before April 30, 2017. 37 C.F.R. § 42.107(b).
`
`“The Director may not authorize an inter partes review to be instituted
`
`unless the Director determines that the information presented in the petition filed
`
`under section 311 and any response filed under section 313 shows that there is a
`
`reasonable likelihood that the petitioner would prevail with respect to at least 1 of
`
`the claims challenged in the petition.” 35 U.S.C. § 314(a). The Board should deny
`
`institution because Petitioners fail to establish that there is a reasonable likelihood
`
`that they will prevail on their invalidity arguments. Specifically, while there are
`
`many deficiencies in the Petition, the focus of this preliminary response is the
`
`failure of U.S. Patent No. 6,115,393 (“Engel”) (Ex. 1007), Petitioners’ primary
`
`reference, to disclose “conversational flows” as taught in U.S. Patent No.
`
`6,771,646 (“the ‘646 patent”) (Ex. 1001). Conversational flows are a fundamental
`
`
`
`1
`
`

`

`
`
`requirement of the challenged claims and an innovative feature of the ‘646 patent.
`
`In addition, while an expert declaration accompanies the Petition (Ex. 1006), it
`
`offers no opinions regarding the constructions of the terms identified by Petitioners
`
`or opinions regarding whether or not Engel discloses conversational flows. Rather
`
`the declaration focuses on describing the operation of certain aspects of Engel and
`
`a source code appendix, which Petitioners then incorporate by reference into the
`
`Petition, with little or no explanation as to how the incorporated sections allegedly
`
`support, what is otherwise, attorney argument.
`
`The Petition’s substantive shortcomings and procedural failings are fatal to
`
`Petitioners’ institution request. Pursuant to 35 U.S.C. § 314(a), Patent Owner
`
`respectfully requests that the Board deny institution of a trial on all challenged
`
`claims (i.e., claims 1-3 and 7-20) of the ‘646 Patent.
`
`III. OVERVIEW OF THE TECHNOLOGY AND STATE OF THE PRIOR
`ART
`
`The ‘646 patent intrinsic record discloses improved techniques for
`
`monitoring traffic over a computer network. Conventional prior art network
`
`monitors categorize network transmissions into “connection flows.” Ex. 1003 at
`
`2:34-37; Ex. 1005 at p. 3 lns. 3-10.1 A connection flow refers to all packets
`
`
`1 Because the related patents and applications have overlapping specifications,
`
`many of the citations contained herein are also found in the related patents and
`
`
`
`2
`
`

`

`
`
`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
`
`individual packets to one another into “conversational flows.” 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 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. Ex. 1003 at 2:34-
`
`48; Ex. 1005 at p. lns. 3-10.
`
`Essentially, the network monitor and methods disclosed in the ‘646 patent
`
`categorizes network transmissions into “conversational flows,” which relate
`
`individual packets and connection flows based on specific application activity. In
`
`addition, the ‘646 patent also teaches other innovative techniques, including the
`
`applications. See Exs. 1001 - 1005. Furthermore, the ‘646 patent specifically
`
`incorporates U.S. Patent No. 6,651,099 by reference twice, in addition to stating
`
`that the ‘646 patent relates to the ‘099 patent (Ex. 1003). See Ex. 1001 at Col.
`
`1:17-19, Col. 1:66-2:2. Furthermore, the ‘646 patent also incorporates Provisional
`
`Application No. 60/141,903 (Ex. 1005). See Ex. 1001 at Col. 1:5-11. Therefore,
`
`the ‘099 patent and Provisional Application are part of the intrinsic record and
`
`citations to these materials are included where relevant.
`
`
`
`3
`
`

`

`
`
`use of state operations and state of the flow analysis to assist in the identification of
`
`conversational flows. These teachings enable classification of all packets passing
`
`through a network providing detailed insight and information to network managers
`
`and operators.
`
`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 at ¶52. 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 communciaiton process into seven layers as shown below:
`
`
`
`4
`
`

`

`
`
`
`
`Ex. 1001 at 5:32-45; Ex. 1003 at 9:35-50; Ex. 2001 at ¶52.
`
`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. Ex. 2001 at ¶53. 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, in addition to standard protocols for audio
`
`and video—if required. Similarly, web browsers use the HTTP protocol. Such
`
`application level data is located at the Application layer of a data packet. Id.
`
`
`
`5
`
`

`

`
`
`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. Ex. 2001 at ¶54. The Physical layer (layer 1) includes
`
`protocols such as Ethernet, which control the transmission of raw data onto 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. Ex. 2001 at ¶55. 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.
`
`Ex. 2001 at ¶56. 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/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.
`
`
`
`6
`
`

`

`
`
`
`
`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. Ex. 2001 at ¶57. 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 help
`
`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
`
`constructed in conformance with the IP protocol. Ex. 2001 at ¶58. The IP protocol
`
`layer is layer 3. Id. Each of these IP packets includes a header with information
`
`
`
`7
`
`

`

`
`
`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, as the image above illustrates, follows the
`
`header. 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 multiple 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. Ex. 2001 at ¶59. 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 packets are placed
`
`directly on the wire for transmission. Ex. 2001 at ¶60. 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
`
`
`
`8
`
`

`

`
`
`the receiving computer, which is then processed by the appropriate application on
`
`the receiving computer. Id. In other words, once reassembled, the destination
`
`computer with 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. Ex. 2001 at ¶61. One
`
`of the earliest methods of application identification in network monitoring is
`
`referred to as “static packet filtering, whereby 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 in a data packet
`
`contains both destination and source computer port information. Certain services
`
`are know 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.
`
`Subsequent improvements in network monitoring led to “stateful packet
`
`filtering.” Ex. 2001 at ¶62. Stateful packet filtering operates on a connection flow
`
`
`
`9
`
`

`

`
`
`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.
`
`More complex methods of network monitoring that examine higher level
`
`OSI layer data are generally referred to as Deep Packet Inspection (“DPI”). Ex.
`
`2001 at ¶63. Depending on implementation, DPI has the ability to 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 the implementation of 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. 2001 at ¶63. Indeed, the
`
`invention teaches the ability to examine data packets and identify the protocols
`
`used and the applications responsible for generating them, permitting robust
`
`
`
`10
`
`

`

`
`
`network monitoring. Id. As will be discussed in more detail below, one of the
`
`novel ways this is achieved is via conversational flow analysis, which is simply
`
`beyond 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 (Ex. 1005). The ‘646
`
`patent is related to and incorporates by reference “U.S. Pat. No. 6,651,099 for
`
`METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A
`
`NETWORK…” Ex. 1001 at 1:66-2:2; see also 1:16-18. The specification
`
`specifically notes that the ‘646 patent relates to and incorporates by reference U.S.
`
`Patent No. 6,651,099 (Ex. 1003). Ex. 1002 at 1:66-2:14, 1:16-19. While the ‘646
`
`patent has multiple teachings, only those from the specification and intrinsic record
`
`germane to the arguments made in this preliminary response are discussed herein.
`
`One of the problems that the Patentees desired to solve concerns disjointed
`
`flows. Prior art monitors were able to keep track of connection flows. A “flow” is
`
`“a stream of packets being exchanged between any two addresses in the network.”
`
`Ex. 1003 at 12:4-5; Ex. 1005 at p. 40 lns. 4-5. A “connection flow” is “all the
`
`packets involved with a single connection.” Ex. 1003 at 2:35-37; Ex. 1005 at p. 3
`
`lns. 3-5. The problem with only tracking connection flows is that certain
`
`applications and protocols may generate multiple connections. In other words, a
`
`
`
`11
`
`

`

`
`
`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 computer A and B to conduct the call.
`
`There might be one connection which supplies setup information, a second
`
`connection for transmitting video information, and a third connection for
`
`transmitting audio information. Prior art monitors would consider these three
`
`separate connections even though they originated from a single Skype call.
`
`According to the the Patentees: “[i]n 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. If the clients were the same, the two packet exchanges would then be
`
`correctly identified as being part of the same conversational flow.” Ex. 1003 at
`
`3:1-6 (emphasis added).
`
`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.” Ex. 1003 at 2:37-
`
`45; Ex. 1005 at p. 3 lns. 5-10. One aspect that “distinguishes this invention from
`
`prior art network monitors is that it has the ability to recognize disjointed flows as
`
`
`
`12
`
`

`

`
`
`belonging to the same conversational flow.” Ex. 1003 at 3:48-51; see also Ex.
`
`1001 at 11:13-18; Ex. 1005 at p. 4 lns. 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. 1003 at 4:13-16; see also Ex. 1005 at p.
`
`25 lns. 3-5.
`
`A. Conversational Flow Classification Process Overview
`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…”:
`
`
`
`13
`
`
`
`

`

`
`
`Ex. 1001 at 3:40-43, Fig. 3; Ex. 1003 at 7:47-50, Fig. 3.
`
`The monitor and methods described in the ‘646 patent examines network
`
`traffic passing a connection point in a network. Ex. 1001 at 4:61-65; Ex. 1003 at
`
`Abstract, 5:12-15; see also Ex. 1005 at p. 15 lns. 7-8. The monitor receives packets
`
`from a network and passes them to a
`
`parser 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.
`Ex. 1001 at 8:5-15; Ex. 1003 at 12:12-22; see also Ex. 1005 at p. 18 lns. 4-10.
`
`The information from the parser sub-system is passed to an analyzer sub-
`
`system 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
`
`
`
`14
`
`

`

`
`
`flow.” Ex. 1001 at 9:45-52; Ex. 1003 at 13:54-61; see also Ex. 1005 at p. 41 lns.
`
`15-18.
`
`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
`the content of all the protocol levels, e.g., the ISO model protocol
`levels.
`Ex. 1001 at 6:18-27; Ex. 1003 at 10:24-33; see also Ex. 1005 at p. 16 lns. 1-7.
`
`Included in the analyzer sub-system is a state processor database 326, which
`
`provides information regarding “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.” Ex. 1001 at 8:40-47; Ex. 1003 at 12:47-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
`
`
`
`15
`
`

`

`
`
`(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.
`Ex. 1001 at 10:52-65; Ex. 1003 at 14:63-15:9; see also Ex. 1005 at p. 19 ln. 26 – p.
`
`20 ln. 3.
`
`The analysis of extracted packet information continues in the analyzer sub-
`
`system where additional state operations are applied to the packet
`
`until all those operations are completed that is, there are no more
`operations for this packet in this state. A process 332 decides if there
`are further states to be analyzed for this type of flow according to the
`state of the flow and the protocol, in order to fully characterize the
`flow. If not, the conversational flow has now been fully
`characterized and a process 334 finalizes the classification of the
`conversational flow for the flow.
`Ex. 1001 at 11:22-31; Ex. 1003 at 15:33-42; see also Ex. 1005 at P. 42 lns. 10-16.
`
`“Once a particular set of state transitions has been traversed for the first time and
`
`ends in a final state, a short-cut recognition pattern—a signature—can be generated
`
`that will key on every new incoming packet that relates to the conversational
`
`flow.” Ex. 1001 at 12:11-15; Ex. 1003 at 16:22-26; Ex. 1005 at p. 27 lns. 4-8.
`
`
`
`16
`
`

`

`
`
`If the packet is part of an existing flow, the monitor determines from a flow
`
`entry database if any further processing of the packet is required to classify the
`
`flow. If not, one or more statistics related to the packet in a flow-entry database are
`
`updated, and the packet is released to the network. Ex. 1001 at 10:38-45; Ex. 1003
`
`at 14:49-56, 6:44-7:11. If the state of protocol identification stored in the flow
`
`entry indicates further processing is required, parsing and state processor
`
`operations are performed on the packet to elucidate and identify the “application
`
`program content of the packet involved in the client/server conversational flow.”
`
`Ex. 1001 at 10:47-51; Ex. 1003 at 6:35-39, 14:58-62. The new state is recorded,
`
`and one or more statistics for the flow are updated. Ex. 1001 at 10:39-51; Ex. 1003
`
`at 14:49-62, 6:58-65. If the packet indicates that a new flow is created that relates
`
`to an existing flow, signatures are built to recognize the new packets as part of a
`
`conversational flow. Ex. 1001 at 11:57-12:9, 25:31-44; Ex. 1003 at 16:1-20, 29:58-
`
`30:4.
`
`One of the many advantages of the invention is described as “[p]roperly
`
`analyzing each of the packets exchanged between a client and a server and
`
`maintaining information relevant to the current state of each of these
`
`conversational flows.” Ex. 1003 at 4:64-67; Ex. 1005 at p. 5 lns. 23-25. The use of
`
`the term “state” in this context refers to the last known step in the process of
`
`identifying the application layer protocol through the analysis of packets belonging
`
`
`
`17
`
`

`

`
`
`to a flow, as well as any continued monitoring required of an identified protocol to
`
`identify other established connections that belong to the same conversational flow.
`
`Ex. 1001 at 6:18-30, 6:42-54; Ex.