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-00630
`U.S. Patent No. 6,954,789
`___________________
`
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`UNDER 35 U.S.C. § 313 AND 37 C.F.R. § 42.107
`
`
`
`
`
`
`
`
`NOAC Ex. 1044 Page 1
`
`

`

`
`
`
`
`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 ........................................................................................... 8
`IV. OVERVIEW OF THE ‘789 INVENTION .................................................. 10
`A. Conversational Flow Classification Process Overview ............................... 12
`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” (all claims) .............................................................. 23
`C. “State of the Flow” (claims 13, 44) .............................................................. 25
`D. “State Operations” (claims 13, 15, 17-8, 44-49) .......................................... 27
`E. “Parser Record” (claims 1, 17, 44) ............................................................... 30
`VI.
`THE PETITION DOES NOT SATISFY THE REQUIREMENTS FOR
`INSTITUTING INTER PARTES REVIEW ............................................................. 30
`A. Overview of Engel ........................................................................................ 31
`1. Dialog in Engel ........................................................................................... 32
`2. Engel’s “State” Disclosure .......................................................................... 37
`B. Operation of Engel Compared to Operation of ‘789 Invention ................... 39
`C. The Board Should Deny Institution Because Engel Fails To Disclose
`Conversational Flows ................................................................................... 45
`1. Application Level Dialogs .......................................................................... 48
`2. Application-Specific Server Statistics ........................................................ 52
`
`
`
`i
`
`NOAC Ex. 1044 Page 2
`
`

`

`
`
`3. The Petition Fails to Articulate a Prima Facie Case of Anticipation or
`Obviousness ................................................................................................ 53
`VII. CONCLUSION ............................................................................................ 55
`
`
`
`
`
`
`
`
`
`
`ii
`
`NOAC Ex. 1044 Page 3
`
`

`

`
`
`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) .................................................................... 50
`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) .............................................. 49
`Cuozzo Speed Techs., LLC v. Lee,
`No. 15-446, 136 S. Ct. 2131 (June 20, 2016) ...................................................... 20
`Cynosure, Inc. v. Cooltouch, Inc.,
`660 F. Supp. 2d 128 (D. Mass. 2009) .................................................................. 54
`DeSilva v. DiLeonardi,
`181 F.3d 865 (7th Cir. 1999)................................................................................ 49
`Digital-Vending Services Int’l, LLC v. Univ. of Phoenix, Inc.,
`672 F.3d 1270 (Fed. Cir. 2012) ............................................................................ 29
`Douglas Dynamics, LLC v. Buyers Prods. Co.,
`No. 09-cv-261, 2014 U.S. Dist.,
` LEXIS 33812 (W.D. Wis. Mar. 13, 2014) ........................................................... 55
`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) ............................................................................ 20
`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) .............................................. 24
`Net MoneyIN, Inc. v. VeriSign, Inc.,
`545 F.3d 1359 (Fed. Cir. 2008) ............................................................................ 53
`
`
`
`iii
`
`NOAC Ex. 1044 Page 4
`
`

`

`
`
`Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co.,
`No. 2016-1900, 2017 U.S. App.,
` LEXIS 4416 (Fed. Cir. Mar. 14, 2017) ................................................................ 54
`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) ...................................... 46, 49
`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) ........................................................................ 21
`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) ............................................................................ 54
`United States v. Dunkel,
`927 F.2d 955 (7th Cir. 1991)................................................................................ 50
`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
`
`NOAC Ex. 1044 Page 5
`
`

`

`
`
`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,954,789 (the ‘789 patent”) (Ex. 1004). Conversational flows are a fundamental
`
`
`
`1
`
`NOAC Ex. 1044 Page 6
`
`

`

`
`
`requirement of the challenged claims and an innovative feature of the ‘789 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-8, 11-18 and 44-49) of the ‘789 patent.
`
`III. OVERVIEW OF THE TECHNOLOGY AND STATE OF THE PRIOR
`ART
`
`The ‘789 patent discloses improved techniques for monitoring traffic over a
`
`computer network. Conventional prior art network monitors categorize network
`
`transmissions into “connection flows.” Ex. 1004 at 2:42-45; Ex. 1003 at 2:34-37;
`
`
`
`2
`
`NOAC Ex. 1044 Page 7
`
`

`

`
`
`Ex. 1005 at p. 3 lns. 3-10.1 A connection flow refers to all packets involved in a
`
`single connection. One of the key novel features of the ‘789 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. 1004 at 2:42-53; Ex. 1003 at
`
`2:34-48; Ex. 1005 at p. lns. 3-10.
`
`Essentially, the network monitor and methods disclosed in the ‘789 patent
`
`categorizes network transmissions into “conversational flows,” which relate
`
`individual packets and connection flows based on specific application activity. In
`
`addition, the ‘789 patent also teaches other innovative techniques, including the
`
`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
`
`
`1 Because the related patents and applications have overlapping specifications,
`
`many of the citations contained herein are also found in the related patents and
`
`applications. See Exs. 1001 - 1005.
`
`
`
`3
`
`NOAC Ex. 1044 Page 8
`
`

`

`
`
`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:
`
`Ex. 1004 at 9:45–57; Ex. 1003 at 9:35-50; Ex. 2001 at ¶52.
`
`
`
`4
`
`
`
`NOAC Ex. 1044 Page 9
`
`

`

`
`
`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.
`
`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
`
`
`
`5
`
`NOAC Ex. 1044 Page 10
`
`

`

`
`
`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.
`
`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.
`
`
`
`
`
`6
`
`NOAC Ex. 1044 Page 11
`
`

`

`
`
`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
`
`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
`
`
`
`7
`
`NOAC Ex. 1044 Page 12
`
`

`

`
`
`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
`
`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
`
`
`
`8
`
`NOAC Ex. 1044 Page 13
`
`

`

`
`
`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
`
`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
`
`
`
`9
`
`NOAC Ex. 1044 Page 14
`
`

`

`
`
`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 ‘789 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
`
`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 ‘789 INVENTION
`The ‘789 patent, filed on October 14, 2003, is a continuation of application
`
`number 09/608,237 filed on June 30, 2000, which issued as U.S. Patent No.
`
`6,651,099 (Ex. 1003), and claims priority to provisional application 60/141,903
`
`filed on June 30, 1999 (Ex. 1005).
`
`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
`
`
`
`10
`
`NOAC Ex. 1044 Page 15
`
`

`

`
`
`“a stream of packets being exchanged between any two addresses in the network.”
`
`Ex. 1004 at 12:11-12; 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. 1004 at 2:43-45;
`
`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 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. 1004 at
`
`3:9-14 (emphasis added); Ex. 1003 at 3:1-6.
`
`
`
`11
`
`NOAC Ex. 1044 Page 16
`
`

`

`
`
`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. 1004 at 2:45-
`
`53; 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 belonging to the same conversational flow.” Ex. 1004 at 3:56-
`
`59; Ex. 1003 at 3:48-51; see also 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. 1004 at 4:20-23; 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…”:
`
`
`
`12
`
`NOAC Ex. 1044 Page 17
`
`

`

`
`
`
`
`Ex. 1004 at 7:57-60, Fig. 3; Ex. 1003 at 7:47-50, Fig. 3.
`
`The monitor and methods described in the ‘789 patent examine network
`
`traffic passing a connection point in a network. Ex. 1004 at Abstract, 5:18-21; 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)
`
`
`
`13
`
`NOAC Ex. 1044 Page 18
`
`

`

`
`
`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. 1004 at 12:19-29; 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
`
`flow.” Ex. 1004 at 13:60-67; Ex. 1003 at 13:54-61; Ex. 1001 at 9:45-52; Ex. 1002
`
`at 10:56-63; 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
`
`
`
`14
`
`NOAC Ex. 1044 Page 19
`
`

`

`
`
`the content of all the protocol levels, e.g., the ISO model protocol
`levels.
`Ex. 1004 at 10:31-40; 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. 1004 at 12:55-62; 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
`(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. 1004 at 15:1-14; 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
`
`
`
`15
`
`NOAC Ex. 1044 Page 20
`
`

`

`
`
`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. 1004 at 15:39-48; 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. 1004 at 16:28-33; Ex. 1003 at 16:22-26; Ex. 1005 at p. 27 lns. 4-8.
`
`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. 1004 at 14:54-61, 6:51-
`
`7:18; 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. 1004 at 6:42-46, 14:63-67; Ex. 1003 at 6:35-39, 14:58-
`
`62. The new state is recorded, and one or more statistics for the flow are updated.
`
`
`
`16
`
`NOAC Ex. 1044 Page 21
`
`

`

`
`
`Ex. 1004 at 14:54-67, 6:65-7:5; 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. 1004 at
`
`16:7-26, 30:1-14; 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. 1004 at 5:2-5; 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 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. 1004 at 6:58-62, 10:31-43, 10:55-67; Ex. 1003 at 6:51-55,
`
`10:23-36, 10:48-60. Note that connection flows include packets exchanged in both
`
`directions of the connection. See Ex. 1004 at 30:15-31; Ex. 1003 at 30:5-21;
`
`(describing packets traveling in both directions during the two-way handshake of
`
`the TCP transport layer protocol as belonging to the same connection flow and not
`
`as separate connections forming a conversational flow).
`
`
`
`17
`
`NOAC Ex. 1044 Page 22
`
`

`

`
`
`B.
`
`Benefits of Conversational Flows Over Prior Art Systems
`
`The ‘789 specifi