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-00862
`Patent 6,665,725 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
`
`
`
`
`
`
`
`NOAC Ex. 1052 Page 1
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`
`I. INTRODUCTION
`Petitioner filed a Petition for inter partes review of claims 10, 12, 13,
`and 15–17 of U.S. Patent No. 6,665,725 B1 (Ex. 1033, “the ’725 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 ’725
`patent. Accordingly, we do not institute an inter partes review.
`A. Related Matters
`Patent Owner submits that the ’725 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 4. Petitioner filed a petition challenging claims 1
`and 2 of the ’725 patent in Case IPR2017-00863. 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,651,099 B1 (IPR2017-00769). Id.
`
`
`2
`
`NOAC Ex. 1052 Page 2
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`
`B. The ’725 Patent
`The ’725 patent relates to examining packets passing through a
`connection point on a computer network to determine whether a packet is of
`a conversational flow associated with an application program. Ex. 1033,
`7:12–26. Figure 3 of the ’725 patent is reproduced below.
`
`
`Figure 3 above shows network packet monitor 300. Id. at 8:48–13:50.
`
`
`Packet 302 is examined and evaluated by network 300 to determine its
`characteristics, such as all the protocol information in a multilevel model,
`including what server application produced the packet. Id. at 8:51–57.
`Initialization of the monitor to generate what operations need to occur on
`packets of different types is accomplished by compiler and optimizer 310,
`parsing and extraction of selected portions of packets to generate an
`
`3
`
`NOAC Ex. 1052 Page 3
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`
`identifying signature is accomplished by parser subsystem 301, and analysis
`of the packets is accomplished by analyzer 303. Id. at 8:64–9:3.
`
`Parser subsystem 301 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 packet 302. Id. at
`9:17–20. Protocol description language (PDL) files 336 “describe[] both
`patterns and states of all protocols that . . . occur at any layer, including
`how to interpret header information, how to determine from the packet
`header information the protocols at the next layer, and what information to
`extract for the purpose of identifying a flow, and ultimately, applications
`and services.” Id. at 9:29–35.
`
`The ’725 patent states that it incorporates by reference U.S. Patent
`Application No. 09/608,237, issued as U.S. Patent 6,651,099 B1 (Ex. 1003,
`“the ’099 patent”), which discloses “protocol specific operations on
`individual packets including extracting information from header fields in
`the packet used for building a signature for identifying the conversational
`flow of the packet and for recognizing future packets as belonging to a
`previously encountered flow.” Id. at 2:21–30. The parser recognizes
`different patterns in the packet identifying the protocols used. Id. at 2:30–
`32. For each protocol recognized, packet elements are extracted to form the
`flow signature (also called a “key”). Id. at 2:32–34.
` Compiler/optimizer 310 generates two sets of internal data structures. Id. at
`
`9:42–43, Fig. 3. The first is the set of parsing/extraction operations 308
`wherein “database 308 of parsing/extraction operations includes information
`describing how to determine a set of one or more protocol dependent
`extraction operations from data in the packet that indicate a protocol used in
`
`4
`
`NOAC Ex. 1052 Page 4
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`the packet.” Id. at 9:43–52. “The other internal data structure that is built
`by compiler 310 is the set of state patterns and processes 326.” Id. at 9:53–
`54. “These are 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 a conversational flow.” Id. at 9:54–60.
`Input to compiler/optimizer 310 “includes a set of files that describe
`each of the protocols that can occur.” Id. at 41:24–25. “These files are in a
`convenient protocol description language (PDL) which is a high level
`language.” Id. at 41:25–27. “The PDL file for a protocol provides the
`information needed by compilation process 310 to generate the database
`308.” Id. at 41:57–59. “That database in turn tells parser 301 how to parse
`and/or extract information, including one or more of what protocol-specific
`components of the packet to extract for the flow signature, how to use the
`components to build the flow signature, where in the packet to look for
`these components, where to look for any child protocols, and what child
`recognition patterns to look for.” Id. at 41:59–65.
`C. Illustrative Claim
`Claim 10 of the challenged claims of the ’725 patent is independent.
`Claim 10 is illustrative of the claimed subject matter:
`10. A method of performing protocol specific operations on a
`packet passing through a connection point on a computer
`network, the method comprising:
`
`
`
`
`(a) receiving the packet;
`
`5
`
`NOAC Ex. 1052 Page 5
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`
`(b) receiving a set of protocol descriptions for a plurality
`
`of protocols that conform to a layered model, a protocol
`description for a particular protocol at a particular layer level
`including:
`
`
`
`
`
`
`(i) if there is at least one child protocol of the
`
`protocol at the particular layer level, the-one or more child
`protocols of the particular protocol at the particular layer
`level, the packet including for any particular child protocol
`of the particular protocol at the particular layer level
`information at one or more locations In the packet related
`to the particular child protocol,
`
`
`
`(ii) the one or more locations in the packet where
`information is stored related to any child protocol of the
`particular protocol, and
`
`
`
`(iii) if there is at least one protocol specific
`operation to be performed on the packet for the particular
`protocol at the particular layer level, the one or more
`protocol specific operations to be performed on the packet
`for the particular protocol at the particular layer level: and
`
`
`(c) performing the protocol specific operations on the
`
`packet specified by the set of protocol descriptions based on the
`base protocol of the packet and the children of the protocols used
`in the packet,
`
`wherein the protocol specific operations include one or more
`parsing and extraction operations on the packet to extract
`selected portions of the packet to form a function of the selected
`portions for
`identifying
`the packet as belonging
`to a
`conversational flow.
`
`
`
`Ex. 1033, 96:24–57.
`
`
`
`
`6
`
`NOAC Ex. 1052 Page 6
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`
`D. Reference
`Petitioner relies on the following reference. Pet. 1.
`Reference Title
`Date
`Engel
`US 6,115,393
`Sep. 5, 2000
`(filed June 21,
`1995)
`
`Ex. No.
`Ex. 1007
`
`
`
`E. Asserted Ground of Unpatentability
`Petitioner contends that claims 10, 12, 13, and 15–17 of the
`
`’725 patent are unpatentable based on the following ground:
`
`Reference
`Engel
`
`Basis
`§ 102(e)
`
`Challenged Claims
`10, 12, 13, and 15–17
`
`
`Pet. 1. 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).
`
`7
`
`NOAC Ex. 1052 Page 7
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`Petitioner provides proposed constructions of the claim terms
`
`“conversational flow” (claims, 10, 15, and 17), “state of the flow”/”state of
`the conversational flow” (claims 16 and 17), and “processing operations that
`are a function of the state of the flow of the packet” (claim 16) / “state
`processing operations” (claim 17). Pet. 3–7. Patent Owner provides
`proposed constructions of the same claim terms. Prelim. Resp. 23–30.
`Other than the term “conversational flow,” discussed below, we determine
`that no claim term requires express construction to resolve the issues before
`us.
`Claim 10 recites that “the protocol specific operations include one or
`
`more parsing and extraction operations on the packet to extract selected
`portions of the packet to form a function of the selected portions for
`identifying the packet as belonging to a conversational flow.” Claim 17
`recites the following:
`the packet belongs to a conversational flow of packets having a
`set of one or more states, and wherein the protocol specific
`operations include one or more state processing operations that
`are a function of the state of the conversational flow of the
`packet, the state of the conversational flow of the packet being
`indicative of the sequence of any previously encountered packets
`of the same conversational flow as the packet.
`Petitioner contends that the broadest reasonable interpretation of the
`
`term “conversational flow,” in view of the intrinsic record, is “the sequence
`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
`
`8
`
`NOAC Ex. 1052 Page 8
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`claimed methods are able to “identify and classify conversational flows
`rather than only connection flows.” Id. at 4–5.
`
`Patent Owner contends the term “conversational flow” is expressly
`defined in the related ’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 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. 12 (citing Ex. 1003, 2:34–45), 24 (citing Ex. 2001 ¶¶ 26–31).1
`
`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 (quoting 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–13 (quoting Ex. 1003, 4:13–16).
`
`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
`
`
`1 The ’725 patent states that the application that issued as the ’099 patent is
`incorporated by reference. Ex. 1033, 1:17–21. Also, the ’725 and ’099
`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 ’725
`and ’099 patents have some of the same disclosure in their written
`descriptions.
`
`9
`
`NOAC Ex. 1052 Page 9
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`“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.
`
`B. Asserted Anticipation By Engel
`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 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
`
`10
`
`NOAC Ex. 1052 Page 10
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`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
`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.
`
`11
`
`NOAC Ex. 1052 Page 11
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`
`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. Analysis of Claim 10
`Petitioner relies on Engel as allegedly teaching the limitations of
`
`independent claim 10. Pet. 10–43. Claim 10 requires, inter alia, the
`limitation of “wherein the protocol specific operations include one or more
`parsing and extraction operations on the packet to extract selected portions
`of the packet to form a function of the selected portions for identifying the
`packet as belonging to a conversational flow.” (Emphasis added).
`Petitioner argues that two different aspects of Engel constitute
`“conversational flows”: “Application Level Dialogs” and
`“Application-Specific Server Statistics.” Pet. 35. 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 specific Server and
`all of its clients.’”2 Id. 35 (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.
`
`
`2 The ’725 patent states that the application that issued as the ’751 patent is
`incorporated by reference. Ex. 1033, 1:22–27. Also, the ’725 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 ’725 and ’751
`patents have some of the same disclosure in their written descriptions.
`
`
`12
`
`NOAC Ex. 1052 Page 12
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`Resp. 48; 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
`teaches conversational flows. First, Petitioner contends that Engel teaches
`“Application Level Dialogs.” Pet. 36–40. 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 ‘725 Patent.” Id. at
`36–37 (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 37
`(citing Ex. 1007, 9:25–27). According to Petitioner, Engel discloses
`
`13
`
`NOAC Ex. 1052 Page 13
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`“creating and maintaining dialogs” and associated statistics at different
`layers. Id. (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.” Id. at 38 (citing Ex. 1006 ¶ 108). 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
`application-specific threshold.” Id. at 38–39 (citing Ex. 1007, 17:2–16; Ex.
`1006 ¶¶ 128–129).
`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. 47–
`48 (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
`
`14
`
`NOAC Ex. 1052 Page 14
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`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 51–52 (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
`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
`
`15
`
`NOAC Ex. 1052 Page 15
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`
`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
`us to 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
`sequences of packets to applications because some packets may be lost.
`Prelim. Resp. 37 (quoting Ex. 1007, 3:12–14; Ex. 2001 ¶ 74).
`Patent Owner provides the following illustration on page 43 of its
`Preliminary Response:
`
`16
`
`NOAC Ex. 1052 Page 16
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`
`
`
`The Figure above depicts four packets exchanged between Nodes A
`
`and B, with each row representing a layer of the OSI model. Engel treats
`each layer separately. For example, packets 1 and 2 may both result from
`the same application (e.g., video and audio traffic using Skype), but Engel
`would not link them as being part of a single conversational flow. See id. at
`43–44, 51–52 (“Engel is not concerned with which application a specific
`packet originated from or which packets relate to one another based on the
`application that generated them.”). Patent Owner’s explanation is consistent
`with the disclosure of Engel and is supported by the testimony of its
`declarant, Kevin C. Almeroth, Ph.D. See, e.g., Ex. 1007, 9:9–43 (“a dialog
`is a communication between a sender and a receiver, which is composed of
`one or more packets being transmitted between the two,” where, for
`example, “Layer n of Node A is having a dialog with Layer n of node B”);
`9:67–10:3 (“If in fact there exists more than one communication thread
`
`17
`
`NOAC Ex. 1052 Page 17
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`between Nodes A and B, then these would represent separate, different
`dialogs.”); Ex. 2001 ¶¶ 66–85.
`Petitioner’s position appears to be that conversational flows exist in
`Engel simply because communications exist at the application layer and
`because those communications result from some application activity. See
`Pet. 36–38. As explained in connection with Patent Owner’s illustration
`above, however, we do not see—and Petitioner does not point to—anything
`in Engel indicating that it links communications by application (as opposed
`to by layer and client-server pair) as the construction of “conversational
`flows” above requires. See supra Section II.A; Ex. 1003, 3:48–51 (“What
`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.”). Petitioner argues that “Engel’s application level lookup_dialog
`routines search for existing dialogs based on application and the client-
`server IP address pair of the communication,” citing Dr. Lin’s testimony as
`support, but Dr. Lin only explains how Engel searches for existing dialogs
`based on the client-server IP address pair, not based on application.3 See
`Pet. 38 (emphasis added); Ex. 1006 ¶ 108. Indeed, Petitioner acknowledges
`
`
`3 We also note that Dr. Lin explains in his declaration how Engel’s disclosed
`system works, but does not opine that the reference teaches “conversational
`flows” or explain how any of the limitations of the claims are taught by
`Engel. See Ex. 1006 ¶¶ 54–140 (Dr. Lin stating that he “was asked to
`review Engel and the source code found in Engel’s Appendix VI and to
`provide an overview of the operation of the Engel packet monitor as
`disclosed in the Engel patent and the Appendix VI source code”). Thus, we
`determine that Dr. Almeroth’s testimony that Engel does not teach
`“conversational flows” does not create a genuine issue of material fact
`(which would be viewed in the light most favorable to Petitioner pursuant to
`37 C.F.R. § 42.108(c)).
`
`18
`
`NOAC Ex. 1052 Page 18
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`that Engel’s application level dialogs track “all application activity between
`the client-server pair,” without pointing to any specific disclosure in Engel
`of tracking activity by application. See Pet. 38 (emphasis added). Nor are
`we persuaded by Petitioner’s argument regarding deallocation. See id. at
`38–40. Engel deallocates dialog records after a period of inactivity “for a
`dialog address pair,” which does not support Petitioner’s contention that
`Engel links communications by application (as opposed to simply by layer
`and client-server pair). See id. (citing Ex. 1007, 17:2–16); Prelim. Resp. 51–
`52.
`
`Second, Petitioner argues that Engel teaches “Application-Specific
`Server Statistics.” Pet. 40–43. According to Petitioner, “Engel recognizes
`disjointed flows as belonging to the same conversational flow by tracking
`statistics for a given application and a specific Server and its clients.” Id. at
`40. Petitioner argues that Engel discloses tracking application-specific
`server statistics wherein
`[e]ach application-specific server record includes a dialog link
`queue with a linked list of all application dialogs in which the
`server has participated (i.e., dialogs for a given application and a
`specific Server and all of its clients), and therefore recognizes
`and links disjointed exchanges associated with a particular
`application, even if the clients were not the same. . . .
`Accordingly, Engel discloses recognizing flows for a given
`application and a specific Server and all of its clients and
`therefore recognizes and links disjointed flows as belonging to
`the same conversational flow within the meaning of the ’725
`Patent.
`Id. at 42 (citing Ex. 1007, Fig. 7B (item 160), 18:41–62, 17:32–18:40;
`Ex. 1009, 179, 247–48; Ex. 1006 ¶¶ 65, 68).
`As explained above, however, Petitioner has only shown that Engel
`links packets (and tracks corresponding statistics) by layer and client-server
`
`19
`
`NOAC Ex. 1052 Page 19
`
`

`

`IPR2017-00862
`Patent 6,665,725 B1
`
`pair, not by application. Thus, we are not persuaded that Engel links
`communications “associated with a particular application” as Petitioner
`contends. See id. We agree with Patent Owner and Dr. Almeroth that
`[b]ecause Engel considers dialogs unique and does not relate
`subsequent packets with previously seen packets, Engel is user-
`agnostic—no effort is made to relate packets to specific
`application activities. Rather, all packet dialogs at a given OSI
`level are treated uniformly and are indistinc