Trials@uspto.gov
`571-272-7822
`
`
`Paper 8
`Entered: July 26, 2017
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SANDVINE CORPORATION and SANDVINE INCORPORATED ULC,
`Petitioner,
`
`v.
`
`PACKET INTELLIGENCE, LLC,
`Patent Owner.
`____________
`
`Case IPR2017-00769
`Patent 6,651,099 B1
`____________
`
`
`Before ELENI MANTIS MERCADER, JUSTIN T. ARBES, and
`WILLIAM M. FINK, Administrative Patent Judges.
`
`MANTIS MERCADER, Administrative Patent Judge.
`
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`EX 1060 Page 1
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`
`I. INTRODUCTION
`Petitioner filed a Petition for inter partes review of claims 1–10 of
`U.S. Patent No. 6,651,099 B1 (Ex. 1003, “the ’099 patent”). Paper 1
`(“Pet.”). Patent Owner filed a Preliminary Response. Paper 6 (“Prelim.
`Resp.”). By statute, institution of an inter partes review may not be
`authorized “unless . . . the information presented in the petition . . . and any
`response . . . 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); see also 37 C.F.R. § 42.108.
`Upon consideration of the Petition and the Preliminary Response, we
`are not persuaded Petitioner demonstrated a reasonable likelihood of
`prevailing in establishing unpatentability of at least one claim of the ’099
`patent. Accordingly, we do not institute an inter partes review.
`A. Related Matters
`Patent Owner submits that the ’099 patent is the subject of a patent
`
`infringement lawsuit in the United States District Court for the Eastern
`District of Texas: (1) Packet Intelligence, LLC v. Sandvine Corp., Case No.
`2:16-cv-00147, which was consolidated for pretrial matters (except venue)
`with co-pending Packet Intelligence, LLC v. NetScout Systems, Inc., Case
`No. 2:16-cv-00230. Paper 5. Petitioner also filed petitions for inter partes
`review of United States Patent Nos. 6,839,751 B1 (IPR2017-00451);
`6,771,646 B1 (IPR2017-00450); 6,954,789 B2 (IPR2017-00629 and
`IPR2017-00630); and 6,665,725 B1 (IPR2017-00862 and IPR2017-00863).
`Id.
`
`
`
`2
`
`EX 1060 Page 2
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`
`B. The ’099 Patent
`The ’099 patent relates to examining packets passing through a
`connection point on a computer network to determine whether a packet is of
`an existing conversational flow. Ex. 1003, Abstract. Figure 3 of the ’099
`patent is reproduced below.
`
`
`
`Figure 3 above shows network packet monitor 300. Id. at 11:43–45.
`Parser 301 parses and extracts selected portions of packet 302 to
`generate an identifying signature and analyzer 303 analyzes the packet. See
`id. at 11:59–65. Compiler 310 provides protocol specific information to
`parser 301 and analyzer 303. Id. at 11:66–12:1. For each protocol there are
`several fields that are known, such as the destination (recipient) and the
`source (sender). Id. at 12:5–8. These are used by monitor 300 to identify
`
`3
`
`EX 1060 Page 3
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`the flow. Id. Parser 301 uses pattern recognition process 304 carried out by
`the pattern analysis and recognition (PAR) engine to parse packet 302 and
`determine the protocol types and associated headers for each protocol layer
`that exists in packet 302 by using parsing-pattern-structures supplied from
`parsing/extraction database 308. Id. at 12:12–22, 12:65–13:2.
`Extraction process 306, implemented by an extracting and information
`identifying (EII) engine in parser 301, extracts characteristic portions
`(signature information) from packet 302 using extraction masks supplied
`from the extraction-operations database (e.g., parsing/extraction database
`308) to identify information from the packet. Id. at 12:12–22, 13:14–25.
`This is required to recognize the packet as part of a flow. Id. at 13:14–25.
`The extracted information is put in a sequence that is processed in block 312
`to build a unique flow signature (also called a “key”) for the flow depending
`on the protocols used in the packet. Id. The flow signature depends on the
`protocols used in the packet and may include source and destination
`addresses. Id. at 13:23–29. Building a hash of the signature using a hash
`function allows for efficient searching. Id. at 13:30–36.
`A parser record that includes the signature, the hash, and the packet
`itself, is passed on to lookup process 314 carried out by the lookup engine
`(LUE) to determine whether the particular packet belongs to a known flow
`as indicated by the presence of a flow-entry matching the flow in a database
`of known flows 324. Id. at 13:54–61, 14:3–13.
`Flow-entry database 324 “stores flow-entries that include the unique
`flow-signature, state information, extracted information from the packet for
`updating flows,” and statistics about the flow. Id. at 14:14–18. If there is no
`flow-entry matching the signature (e.g., the signature is for a new flow), then
`
`4
`
`EX 1060 Page 4
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`protocol and state identification process 318 determines the state and
`protocol. Id. at 14:39–42. Process 318 determines the protocols and where
`in the state sequence for the protocol the packet belongs by making
`reference to database 326 of state patterns and processes. Id. at 14:41–46. If
`the packet is found to have matching flow-entry in database 324 (e.g., in the
`cache) then process 320 determines, from the looked-up flow entry, if more
`classification by state processing of the flow signature is necessary. Id. at
`14:49–53. If no further processing is needed, then process 322 updates the
`flow entry in flow-entry database 324. Id. at 14:53–54. If state processing is
`required, then state processor 328 carries out any state operations according
`to state instructions from state pattern and processes database 326. Id. at
`14:58–62.
`State processor 328 analyzes both new and existing flows in order to
`analyze all levels of the protocol stack, ultimately classifying flows by
`application (level 7 in the ISO model). Id. at 14:63–66. This is done by
`processing from state-to-state based on predefined state transition rules and
`state operations specified in state processor instruction database 326. Id. at
`14:66–15:1. By maintaining a state of flows, network traffic monitor 300
`provides for a single packet protocol recognition of flows and multiple-
`packet recognition of flows. Id. at 15:18–22. Process 334 finalizes the
`classification of the conversational flow. Id. at 15:39–41.
`C. Illustrative Claim
`Claim 1 of the challenged claims of the ’099 patent is independent.
`Claim 1 is illustrative of the claimed subject matter:
`1. A packet monitor for examining packets passing
`through a connection point on a computer network in real-time,
`the packets provided to the packet monitor via a packet
`
`5
`
`EX 1060 Page 5
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`
`acquisition device connected to the connection point, the packet
`monitor comprising:
`(a) a packet-buffer memory configured to accept a packet
`from the packet acquisition device;
`(b) a parsing/extraction operations memory configured to
`store a database of parsing/extraction operations that includes
`information describing how to determine at least one of the
`protocols used in a packet from data in the packet;
`(c) a parser subsystem coupled to the packet buffer and to
`the pattern/extraction operations memory, the parser subsystem
`configured to examine the packet accepted by the buffer, extract
`selected portions of the accepted packet, and form a function of
`the selected portions sufficient to identify that the accepted
`packet is part of a conversational flow-sequence;
`(d) a memory storing a flow-entry database including a
`plurality of flow-entries for conversational flows encountered by
`the monitor;
`(e) a lookup engine connected to the parser subsystem and
`to the flow-entry database, and configured to determine using at
`least some of the selected portions of the accepted packet if there
`is an entry in the flow-entry database for the conversational flow
`sequence of the accepted packet;
`(f) a state patterns/operations memory configured to store
`a set of predefined state transition patterns and state operations
`such that traversing a particular transition pattern as a result of a
`particular conversational flow-sequence of packets indicates that
`the particular conversational flow-sequence is associated with
`the operation of a particular application program, visiting each
`state in a traversal including carrying out none or more
`predefined state operations;
`(g) a protocol/state identification mechanism coupled to
`the state patterns/operations memory and to the lookup engine,
`the protocol/state identification engine configured to determine
`the protocol and state of the conversational flow of the packet;
`and
`
`6
`
`EX 1060 Page 6
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`
`(h) a state processor coupled to the flow-entry database,
`the protocol/state identification engine, and to the state
`patterns/operations memory, the state processor, configured to
`carry out any state operations specified
`in
`the state
`patterns/operations memory for the protocol and state of the flow
`of the packet,
`the carrying out of the state operations furthering the
`process of identifying which application program is associated
`with the conversational flow-sequence of the packet, the state
`processor progressing through a series of states and state
`operations until there are no more state operations to perform for
`the accepted packet, in which case the state processor updates the
`flow-entry, or until a final state is reached that indicates that no
`more analysis of the flow is required, in which case the result of
`the analysis is announced.
`Ex. 1003, 35:2–62.
`
`D. References
`Petitioner relies on the following references. Pet. 1–2.
`Reference Title
`Date
`Engel
`US 6,115,393
`Sep. 5, 2000
`(filed June 21,
`1995)
`Jan. 30, 2001
`(filed June 27,
`1997)
`Aug. 11, 1998
`
`July 30, 1985 Ex. 1034
`
`Ex. No.
`Ex. 1007
`
`Ex. 1010
`
`Ex. 1012
`
`US 6,182,146 B1
`
`US 5,793,954
`
`US 4,532,606
`
`Graham-
`Cumming
`Baker
`
`Phelps
`
`
`E. Asserted Grounds of Unpatentability
`Petitioner contends that claims 1–10 of the ’099 patent are
`
`unpatentable based on the following grounds:
`
`7
`
`EX 1060 Page 7
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`
`References
`Engel, Baker, and Graham-
`Cumming
`Engel, Baker, Graham-Cumming,
`and Phelps
`
`Basis
`§ 103(a)
`
`Challenged Claims
`1–5, 9, and 10
`
`§ 103(a)
`
`6–8
`
`
`Pet. 1–2. Petitioner also relies on the declaration of Bill Lin, Ph.D. (Ex.
`1006) for support. Id. at 2.
`
`II. ANALYSIS
`A. Claim Construction
`In an inter partes review, claim terms in an unexpired patent are given
`their “broadest reasonable construction in light of the specification of the
`patent in which they appear.” 37 C.F.R. § 42.100(b). Under the broadest
`reasonable construction standard, claim terms are given their ordinary and
`customary meaning, as would be understood by one of ordinary skill in the
`art in the context of the entire disclosure. In re Translogic Tech., Inc., 504
`F.3d 1249, 1257 (Fed. Cir. 2007). Only terms in controversy need to be
`construed, and only to the extent necessary to resolve the controversy. Vivid
`Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`Petitioner provides proposed constructions of the claim terms
`“conversational flow,” “state of the flow,” and “state operations” (in claims
`1–10). Pet. 2–8. Patent Owner provides proposed constructions of the same
`claim terms. Prelim. Resp. 22–29. Other than the term “conversational
`flow,” discussed below, we determine that no claim term requires express
`construction to resolve the issues before us.
`
`Petitioner contends that the broadest reasonable interpretation of the
`term “conversational flow,” in view of the intrinsic record, is “the sequence
`
`8
`
`EX 1060 Page 8
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`of packets that are exchanged in any direction as a result of an activity,”
`where a “conversational flow” is distinguished from a “connection flow” in
`that some of the conversational flows “involve more than one connection” or
`“involve more than one exchange of packets between a client and server.”
`Pet. 3–4 (citing Ex. 1003, 2:34–45). Petitioner acknowledges that the
`claimed systems and methods “require more than identifying and classifying
`‘only connection flows,’ as repeatedly stated throughout the intrinsic
`record.” Id. at 3 (emphasis added).
`
`Patent Owner contends the term “conversational flow” is expressly
`defined in the ’099 patent as
`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.
`
`Prelim. Resp. 11–12 (citing Ex. 1003, 2:34–45), 24 (citing Ex. 2001 ¶¶ 26–
`31).
`Patent Owner notes 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.” Id. at 12 (citing Ex.
`1003, 3:48–51). According to Patent Owner, 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 [Open Systems Interconnection
`(OSI)] model).” Id. at 12; Ex. 1003, 4:13–16.
`
`9
`
`EX 1060 Page 9
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`In the first place, we observe that both parties agree that
`
`“conversational flow” is defined as “the sequence of packets that are
`exchanged in any direction as a result of an activity” and that
`“conversational flow” is distinguished from the prior art “connection flow”
`in that some conversational flows “involve more than one connection, and
`some even involve more than one exchange of packets between a client and
`server.” Furthermore, we observe that the specification of the ’099 patent
`explicitly supports this construction. See Ex. 1003, 2:34–45. Accordingly,
`for purposes of this Decision, we agree that Patent Owner’s proposed
`construction, which mirrors the definition in the specification, is the broadest
`reasonable construction consistent with the specification. Therefore, we
`interpret “conversational flow” to mean 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), where some
`conversational flows involve more than one connection, and some even
`involve more than one exchange of packets between a client and server.1
`
`B. Asserted Obviousness Over Engel, Baker and Graham-Cumming:
`Claims 1–5, 9, and 10
`1. Engel (Ex. 1007)
`Engel is directed to monitoring communications “in a network of
`nodes, each communication being effected by a transmission of one or more
`packets among two or more communicating nodes, and each communication
`complying with a predefined communication protocol selected from among
`
`
`1 We also agree with the parties that “conversational-flow sequence” in the
`claims is used interchangeably with “conversational flow,” and means the
`same. See Pet. 3; Prelim. Resp. 22–24.
`
`10
`
`EX 1060 Page 10
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`protocols available in the network.” Ex. 1007, Abstract. “The contents of
`packets are detected passively and in real time, [and] communication
`information associated with multiple protocols is derived from the packet
`contents.” Id. Such communication information “is associated with
`multiple layers of at least one of the protocols.” Id. at 2:27–30. Network
`monitor 10 captures and analyzes all packets in a segment and extracts all
`items of interest from the frames. Id. at 6:58–61. A Real Time Parser (RTP)
`performs protocol parsing with appropriate parsing routines. Id. at 19:53–
`67, 21:15–30.
`Figure 4 of Engel is reproduced below.
`
`
`Figure 4 “illustrates the different layers of a communication between
`two nodes.” Id. at 4:45–46. In Figure 4, “Nodes A and B are exchanging
`packets and are engaged in multiple dialogs.” Id. at 9:31–33. A dialog is a
`communication at any layer between a sender and a receiver, which is
`composed of one or more packets being transmitted between them and often
`involves exchanges in both directions. Id. at 9:19–27. Layer 1 in Node A
`has a dialog with Layer 1 in Node B. Id. at 9:33–34. This is a data link
`layer and the nature of the dialog deals with the message length, number of
`
`11
`
`EX 1060 Page 11
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`messages, errors, and the guarantee of the delivery. Id. at 9:34–37.
`Simultaneously, Layer n of Node A is having a dialog with Layer n of node
`B. Id. at 9:37–39. This is an application layer dialog, which deals with
`virtual terminal connections and response rates. Id. at 9:39–41. All of the
`other layers (2 through n-1) are also having simultaneous dialogs. Id. at
`9:41–43.
`
`A dialog record is kept which contains the addresses of both ends of
`the dialog concatenated together to form a single address wherein the first
`and second addresses within the single address are designated as nodes 1
`and 2, respectively. Id. at 18:63–19:2.
`2. Baker (Ex. 1012)
`Figure 1 of Baker is reproduced below.
`
`
`
`
`Figure 1 shows database of protocol description files 22 used by
`
`network device control logic 16 to retrieve network frames based on
`extracted field values and filtering criteria contained in protocol description
`files 22. Ex. 1012, 5:56–67.
`
`12
`
`EX 1060 Page 12
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`Baker’s protocol description file includes a protocol control record
`
`that defines the overall structure of a network protocol and references other
`information relating to the network protocol. Id. at 7:9–15. Each protocol
`description file includes a total bit length of the protocol header, a number of
`fields required to describe the header, and field records, each describing a
`protocol header field, including a byte offset from the start of the protocol
`header and, if appropriate, an associated lookup structure for determining the
`next protocol control record to use. Id. at 7:9–12:3, Tables 1 and 2.
`
`Upon initialization of the system, the protocol and associated control
`record information is extracted from all protocol description files and a
`“ProtocolList” is constructed. Id. at 12:7–15. The ProtocolList is a sorted
`vector of all protocol records. Id. Each protocol description control record
`and all associated records are shown in Tables 1–11 as they appear when
`resident in memory. Id. at 11:18–25.
`3. Graham-Cumming (Ex. 1010)
`Figure 3 of Graham-Cumming is reproduced below.
`
`
`
`13
`
`EX 1060 Page 13
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`
`
`Figure 3 shows a functional model of identifying applications and
`
`network protocols from raw packet data. Ex. 1010, 5:14–16. Figure 3
`includes packet analysis module 100, application identifier module 102, and
`application-port mapping table 104. Id. at 5:16–19. “[A]pplication-port
`mapping table 104 stores associations between application identifiers and
`port numbers.” Id. at 5:23–24. “[A]pplication identifier module 102
`attempts to match portions of the packet data, including the payload or
`header, with defined patterns or attributes for each of a plurality of different
`applications.” Id. at 6:22–25. “Each application may have one or more such
`sequences which uniquely identifies it.” Id. at 6:29–31.
`4. Level of Ordinary Skill in the Art
`Section 103(a) forbids issuance of a patent when “the differences
`between the subject matter sought to be patented and the prior art
`are such that the subject matter as a whole would have been
`obvious at the time the invention was made to a person having
`ordinary skill in the art to which said subject matter pertains.”
`KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007) (quoting 35 U.S.C.
`
`14
`
`EX 1060 Page 14
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`§ 103(a)). Petitioner argues that a person of ordinary skill in the art at the
`time of the ’099 patent would have had
`at least a bachelor’s degree, or equivalent, in electrical
`engineering, computer engineering, computer science, or a
`related field or an equivalent number of years of working
`experience, and one to two years of experience in networking
`environments, including at least some experience with network
`traffic monitors, analyzers, and/or firewalls or other intrusion
`detection systems.
`Pet. 2 (citing Ex. 1006 ¶¶ 20–22). Patent Owner argues that a person of
`ordinary skill in the art would have had “the equivalent of a four-year degree
`from an accredited institution (usually denoted as a B.S. degree) in computer
`science, computer engineering or the equivalent and experience with, or
`exposure to, packet analysis techniques,” as well as “approximately 1–2
`years of professional experience with packet network communication
`protocols.” Prelim. Resp. 22 (citing Ex. 2001 ¶ 24). The parties’ proposed
`definitions are very similar. For example, experience with “network traffic
`monitors [and] analyzers” in “networking environments” (Petitioner’s
`proposed definition) likely would include experience with “packet network
`communication protocols” and “packet analysis techniques” (Patent Owner’s
`proposed definition). Based on this record, including our review of the
`’099 patent and the types of problems and solutions described in the
`’099 patent and cited prior art, we conclude that a person of ordinary skill in
`the art would have had a bachelor’s degree in electrical engineering,
`computer engineering, computer science, or a related field (or its
`equivalent), and one to two years of experience working in networking
`environments, including at least some experience with network traffic
`
`15
`
`EX 1060 Page 15
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`monitors and/or analyzers.2 We apply this level of ordinary skill in the art
`for purposes of this Decision.
`5. Analysis of Claim 1
`Petitioner relies on Engel as allegedly teaching the majority of the
`limitations of independent claim 1, and relies on Baker and Graham-
`Cumming for certain limitations. Pet. 11–52. Claim 1 requires, inter alia, a
`“parser subsystem configured to examine the packet accepted by the buffer,
`extract selected portions of the accepted packet, and form a function of the
`selected portions sufficient to identify that the accepted packet is part of a
`conversational flow-sequence,” “the carrying out of the state operations
`furthering the process of identifying which application program is
`associated with the conversational flow-sequence of the packet,” and
`“a memory storing a flow-entry database including a plurality of
`flow-entries for conversational flows encountered by the monitor” (emphasis
`added).
`Petitioner argues that two different aspects of Engel constitute
`“conversational flows”: “Application Level Dialogs” and
`“Application-Specific Server Statistics.” Pet. 18–19. At the outset, we note
`that Petitioner’s arguments are premised on its position that related
`U.S. Patent No. 6,839,751 B1 (Ex. 1002, “the ’751 patent”) “provides
`conversational flow examples where flows are determined and metrics
`reported ‘for a given application and either a specific Client-Server Pair or a
`
`
`2 We do not include in the definition experience with “firewalls or other
`intrusion detection systems,” as Petitioner proposes, because the relevant art
`is network monitoring and analysis. See, e.g., Ex. 1003, 1:40–43.
`
`
`16
`
`EX 1060 Page 16
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`specific Server and all of its clients.’”3 Pet. 18 (quoting Ex. 1002, 34:58–
`60). As Patent Owner points out, however, the cited portion of the
`’751 patent relates to tracking various statistics and does not mention
`conversational flows. See Prelim. Resp. 46–47; see Ex. 1002, 31:52–49:60
`(describing “how the monitor of the invention can be used to monitor the
`Quality of Service (QOS) by providing QOS Metrics”). The specific
`language quoted by Petitioner pertains to one such metric, “CSTraffic,”
`which “contains information about the volume of traffic measured for a
`given application and either a specific Client-Server Pair or a specific Server
`and all of its clients.” Ex. 1002, 34:55–60. However, we do not see how
`this language supports Petitioner’s position. Monitoring statistics is not the
`same as monitoring a conversational flow, which necessarily identifies a
`“sequence of packets,” under our interpretation. See supra Section II.A. In
`other words, tracking statistics for a given application between a particular
`client and server, or between a particular server and all of its clients, is not
`sufficient in and of itself; a conversational flow identifies a sequence of
`packets exchanged between two nodes as a result of specific activity (e.g., a
`“sequence of packets that are exchanged in any direction as a result of an
`activity”).
`We now turn to Petitioner’s two arguments as to how Engel allegedly
`
`
`3 The ’099 patent states that the application that issued as the ’751 patent is
`incorporated by reference. Ex. 1003, 1:21–27. Also, the ’099 and ’751
`patents were filed on the same date (June 30, 2000) and both claim the
`benefit of U.S. Provisional Patent Application No. 60/141,903. The ’099
`and ’751 patents have some of the same disclosure in their written
`descriptions.
`
`
`17
`
`EX 1060 Page 17
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`teaches conversational flows. First, Petitioner contends that Engel teaches
`“Application Level Dialogs.” Pet. 19–22. Petitioner argues that Engel
`“considers the nature of the communication (e.g., the application program
`being invoked) in addition to the Client-Server Pair involved in the
`communication in identifying an application level dialog, rendering such
`dialog a conversational flow within the meaning of the ‘099 Patent.” Id. at
`19 (citing Ex. 1007, 9:27–10:3). Petitioner relies on Engel’s definition of
`“dialog” as “the exchange of messages and the associated meaning and state
`that is inherent in any particular exchange at any layer.” Id. at 19–20 (citing
`Ex. 1007, 9:25–27). According to Petitioner, Engel discloses “creating and
`maintaining dialogs” and associated statistics at different layers. Id. at 20
`(citing Ex. 1007, 9:27–10:3). In particular, Petitioner asserts that the dialog
`at the application level “is an exchange of one or more packets in any
`direction between two nodes as a result of an activity (e.g., [a Network File
`System (NFS)] mount request).” Id. (citing Ex. 1007, 9:58–10:3). Petitioner
`concludes that tracking an application-level dialog constitutes tracking a
`conversational flow. Id.
`
`Petitioner further relies on Dr. Lin’s testimony to assert that, to the
`extent that conversational flows require the tracking of multiple connections,
`“Engel’s application level lookup_dialog routines search for existing dialogs
`based on application and the client-server IP address pair of the
`communication.” Pet. 21 (citing Ex. 1006 ¶ 89). Petitioner further
`contends, based on Dr. Lin’s testimony, that “Engel’s deallocation routines
`deallocate dialog records when the period of inactivity for a dialog address
`pair (measured from the last time an application-specific packet (e.g., NFS)
`between the IP address pair of the dialog was seen) has exceeded a defined
`
`18
`
`EX 1060 Page 18
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`application-specific threshold.” Id. (citing Ex. 1007, 17:2–16; Ex. 1006
`¶¶ 109–110).
`Patent Owner responds that Engel’s dialogs are different from
`conversational flows because they are merely “collections of statistics for
`each OSI layer across packets (regardless of application origin)” and do not
`relate packets that are the result of an application activity. Prelim. Resp. 45–
`46 (citing Ex. 1007, 4:23–32; Ex. 2001 ¶¶ 78–79). For example, noting
`Petitioner’s statement that “[e]ach application level dialog tracks all
`application activity between the client-server pair occurring on any
`connections until the dialog data structures are deallocated for reuse,” Patent
`Owner contends that relating all application activity between a client and
`server is insufficient because a conversational flow requires relating flows
`for specific application activities. Id. at 49–50 (citing Ex. 2001 ¶¶ 80–81).
`We agree with Patent Owner.
`Engel explains that a “dialog” is
`a concept which provides a useful way of conceptualizing,
`organizing and displaying information about the performance of
`a network—for any protocol and for any layer of the multi-level
`protocol stack.
`As noted above, the basic unit of information in
`communication is a packet. A packet conveys meaning between
`the sender and the receiver and is part of a larger framework of
`packet exchanges. The larger exchange is called a dialog within
`the context of this document.
` That is, a dialog is a
`communication between a sender and a receiver, which is
`composed of one or more packets being transmitted between the
`two. There can be multiple senders and receivers which can
`change roles. In fact, most dialogs involve exchanges in both
`directions.
`Stated another way, a dialog is the exchange of messages
`and the associated meaning and state that is inherent in any
`
`19
`
`EX 1060 Page 19
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`
`particular exchange at any layer. It refers to the exchange
`between the peer entities (hardware or software) in any
`communication. In those situations where there is a layering of
`protocols, any particular message exchange could be viewed as
`belonging to multiple dialogs. For example, in FIG. 4 Nodes A
`and B are exchanging packets and are engaged in multiple
`dialogs. Layer 1 in Node A has a dialog with Layer 1 in Node
`B. For this example, one could state that this is the data link layer
`and the nature of the dialog deals with the message length,
`number of messages, errors and perhaps the guarantee of the
`delivery. Simultaneously, Layer n of Node A is having a dialog
`with Layer n of node B. For the sake of the example, one could
`state that this is an application layer dialog which deals with
`virtual terminal connections and response rates. One can also
`assume that all of the other layers (2 through n-1) are also having
`simultaneous dialogs.
`Ex. 1007, 9:9–43 (emphases added).
`As shown in Figure 4 (reproduced supra Section II.B.1), Nodes A and
`
`B engage in a dialog at each layer (e.g., the application layer). Thus, Engel
`monitors communications exchanged between the nodes at a particular layer,
`and tracks statistics for all communications at that layer (to assist in
`diagnosing network problems and improving network performance). See,
`e.g., id. at 4:24–32 (Engel “organizes and presents network performance
`statistics in terms of dialogs which are occurring at any desired level of the
`communication”). Petitioner, however, does not point to any disclosure in
`Engel indicating that its disclosed system relates information from one
`packet to another as pertaining to a specific application activity. In other
`words, in Engel there is exchange of packets in the application layer
`constituting a dialog (see, e.g., id. at 9:39–43) and collection of respective
`statistics for that dialog (see, e.g., id. at 4:24–32). However, even if
`application activity causes the dialog to be created, Petitioner does not direct
`
`20
`
`EX 1060 Page 20
`
`

`

`IPR2017-00769
`Patent 6,651,099 B1
`
`us to teachings or disclosure of identifying a sequence of packets as being
`part of a specific application activity. Moreover, Patent Owner notes that in
`Engel “[k]eeping statistics for protocol layers may be temporarily suspended
`when parsing and statistics gathering is not rapid enough to match the rate of
`packets to be parsed,” which further suggests Engel does not relate
`sequence