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-00629
`Patent 6,954,789 B2
`____________
`
`Before ELENI MANTIS MERCADER, JUSTIN T. ARBES, and
`WILLIAM M. FINK, Administrative Patent Judges.
`
`FINK, Administrative Patent Judge.
`
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`Packet Intelligence Ex. 2055 Page 1 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`
`Sandvine Corporation and Sandvine Incorporated ULC (collectively,
`“Petitioner”) filed a Petition (Paper 2, “Pet.”) requesting inter partes review
`of claims 19–43 of U.S. Patent No. 6,954,789 B2 (Ex. 1004, “the
`’789 patent”) pursuant to 35 U.S.C. § 311(a). Patent Owner Packet
`Intelligence, LLC filed a Preliminary Response (Paper 6, “Prelim. Resp.”)
`pursuant to 35 U.S.C. § 313. Pursuant to 35 U.S.C. § 314(a), the Director
`may not authorize an inter partes review unless the information in the
`petition and preliminary 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.” For the reasons that follow, we have
`decided not to institute an inter partes review.
`
`
`I. BACKGROUND
`A. The ’789 Patent1
`The ’789 patent discloses “[a] monitor for and a method of examining
`packets passing through a connection point on a computer network.” Ex.
`1002, Abstract. The ’789 patent explains that there was a need in the art for
`“a real-time network monitor that can provide alarms notifying selected
`users of problems that may occur with the network or site.” Id. at col. 2,
`ll. 3–5. The disclosed monitor receives packets passing in either direction
`through its connection point on the network and “elucidate[s] what
`application programs are associated with each packet” by extracting
`information from the packet, using selected parts of the extracted
`
`1 Petitioner challenges different claims of the ’789 patent in Case IPR2017-
`00630. Petitioner also challenges patents related to the ’789 patent in Cases
`IPR2017-00450, IPR2017-00451, IPR2017-00769, IPR2017-00862, and
`IPR2017-00863.
`
`
`
`2
`
`Packet Intelligence Ex. 2055 Page 2 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`information to identify this packet as part of a flow, “build[ing] a unique
`flow signature (also called a ‘key’) for this flow,” and “matching this flow in
`a database of known flows 324.” Id. at col. 9, ll. 6–9, col 13, ll. 21–28, col.
`13, ll. 60–65.
`Figure 3 of the ’789 patent is reproduced below.
`
`
`
`Figure 3 depicts various components of network packet monitor 300,
`including parser subsystem 301, analyzer subsystem 303, and database of
`known flows 324. Id. at col. 11, l. 50–col. 13, l. 65. Parser subsystem 300
`“parses the packet and determines the protocol types and associated headers
`for each protocol layer that exists in the packet 302,” “extracts characteristic
`portions (signature information) from the packet 302,” and builds the
`“unique flow signature (also called a ‘key’) for this flow.” Id. at col. 12,
`l. 19–col. 13, l. 28, col. 33, l. 30–col. 34, l. 33 (describing an example of
`how the disclosed monitor builds signatures and flow states in the context of
`a Sun Remote Procedure Call (RPC), where, after all of the required
`
`
`
`3
`
`Packet Intelligence Ex. 2055 Page 3 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`processing, “KEY-2 may . . . be used to recognize packets that are in any
`way associated with the application ‘a2’”), Fig. 2.
`Analyzer system 303 then determines whether the packet has a
`matching flow-entry in database of flows 324, and processes the packet
`accordingly, including, for example, determining whether the packet belongs
`to an existing conversational flow or a new (i.e., not previously encountered)
`flow and, in the case of the latter, performing state processing to determine
`whether the conversational flow has been “fully characterized” and should
`be finalized. Id. at col. 13, l. 60–col. 16, l. 52. The ’789 patent discloses
`that
`
`[f]uture packets that are part of the same conversational flow
`have their state analysis continued from a previously achieved
`state. When enough packets related to an application of interest
`have been processed, a final recognition state is ultimately
`reached, i.e., a set of states has been traversed by state analysis
`to completely characterize the conversational flow. The
`signature for that final state enables each new incoming packet
`of the same conversational flow to be individually recognized
`in real time.
`In this manner, one of the great advantages of the present
`invention is realized. 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—[c]an be generated
`that will key on every new incoming packet that relates to the
`conversational flow. Checking a signature involves a simple
`operation, allowing high packet rates to be successfully
`monitored on the network.
`Id. at col. 16, ll. 17–34.
`
`
`
`
`4
`
`Packet Intelligence Ex. 2055 Page 4 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`
`B. Illustrative Claim
`Claim 19 of the ’789 patent2 recites:
`1. A packet monitor for examining packets passing
`through a connection point on a computer network, each
`packets conforming to one or more protocols, the monitor
`comprising:
`(a) a packet acquisition device coupled to the connection
`point and configured to receive packets passing through the
`connection point;
`(b) an input buffer memory coupled to and configured to
`accept a packet from the packet acquisition device;
`(c) a parser subsystem coupled to the input buffer
`memory and
`including a slicer,
`the parsing subsystem
`configured to extract selected portions of the accepted packet
`and to output a parser record containing the selected portions;
`(d) a memory for storing a database comprising none or
`more flow-entries for previously encountered conversational
`flows, each flow-entry identified by identifying information
`stored in the flow-entry;
`(e) a lookup engine coupled to the output of the parser
`subsystem and to the flow-entry memory and configured to
`lookup whether the particular packet whose parser record is
`output by the parser subsystem has a matching flow-entry, the
`looking up using at least some of the selected packet portions
`and determining if the packet is of an existing flow; and
`(f) a flow insertion engine coupled to the flow-entry
`memory and to the lookup engine and configured to create a
`flow-entry in the flow-entry database, the flow-entry including
`identifying information for future packets to be identified with
`the new flow-entry, the lookup engine configured such that if
`the packet is of an existing flow, the monitor classifies the
`packet as belonging to the found existing flow; and if the packet
`is of a new flow, the flow insertion engine stores a new flow-
`
`2 Claims 6, 7, 15, 23, 26, 27, and 29 of the ’789 patent were corrected in
`Certificates of Correction dated March 7, 2006, and October 1, 2013.
`
`
`
`5
`
`Packet Intelligence Ex. 2055 Page 5 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`
`entry for the new flow in the flow-entry database, including
`identifying information for future packets to be identified with
`the new flow-entry,
`wherein the operation of the parser subsystem depends
`on one or more of the protocols to which the packet conforms.
`
`C. The Prior Art
`Petitioner relies on the following prior art:
`U.S. Patent No. 5,530,834, issued June 25, 1996
`(Ex. 1011, “Colloff”);
`U.S. Patent No. 5,793,954 issued August 11, 1998
`(Ex. 1012, “Baker”);
`U.S. Patent No. 6,115,393, filed July 21, 1995, issued
`Sept. 5, 2000 (Ex. 1007, “Engel”);3 and
`U.S. Patent No. 6,182,146 B1, filed June 27, 1997, issued
`Jan. 30, 2001 (Ex. 1010, “Graham-Cumming”).
`
`D. The Asserted Grounds
`Petitioner challenges claims 19–43 of the ’789 patent on the following
`grounds:
`Reference(s)
`
`Basis
`
`Claims Challenged
`
`Engel
`
`35 U.S.C. § 102(e)4
`
`19–22, 25, 26, 29–
`31, 36–40, and 42
`
`
`3 Engel references Appendices I–VI filed with the originally filed
`application. See, e.g., Ex. 1007, col. 1, ll. 10–15, col. 5, l. 52–col. 6, l. 3;
`Ex. 1008 (Appendices I–V); Ex. 1009 (Appendix VI).
`4 The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284
`(2011) (“AIA”), amended 35 U.S.C. §§ 102 and 103. Because the
`challenged claims of the ’789 patent have an effective filing date before the
`effective date of the applicable AIA amendments, we refer to the pre-AIA
`versions of 35 U.S.C. §§ 102 and 103.
`
`
`
`6
`
`Packet Intelligence Ex. 2055 Page 6 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`
`Reference(s)
`
`Basis
`
`Claims Challenged
`
`Engel and Baker
`
`35 U.S.C. § 103(a)
`
`23 and 24
`
`Engel and
`Graham-Cumming
`Engel and Colloff
`
`35 U.S.C. § 103(a)
`
`35 U.S.C. § 103(a)
`
`27, 28, 32, 41, and
`43
`33–35
`
`
`E. Claim Interpretation
`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,” “state operations,” and “parser
`record.” Pet. 2–7. Patent Owner provides proposed constructions of the first
`three 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 19 recites (emphasis added):
`(d) a memory for storing a database comprising none or
`more flow-entries for previously encountered conversational
`flows, each flow-entry identified by identifying information
`stored in the flow-entry;
`
`
`
`7
`
`Packet Intelligence Ex. 2055 Page 7 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`
`Petitioner argues that “conversational flow” should be interpreted to
`mean “‘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. Petitioner acknowledges that the
`claims “require more than identifying and classifying ‘only connection
`flows,’” citing statements in the ’789 patent:
`Some prior art packet monitors classify packets into connection
`flows. The term “connection flow” is commonly used to
`describe all the packets involved with a single connection. A
`conversational flow, on the other hand, 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. It is desirable to be able to identify and
`classify conversational flows rather than only connection flows.
`The reason for this is that some conversational flows involve
`more than one connection, and some even involve more than
`one exchange of packets between a client and server.
`Id. at 3–4 (quoting Ex. 1004, col. 2, ll. 42–53) (emphases omitted).
`Relying on the same disclosure from the patent, Patent Owner argues
`that the term “conversational flow” is expressly defined 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. 24. Patent Owner further notes that Petitioner agreed to the
`above interpretation in the related district court case, and the district court
`adopted it. Id. at 24–25 (citing Ex. 2005, 6).
`
`
`
`8
`
`Packet Intelligence Ex. 2055 Page 8 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`
`The parties’ proposed interpretations are nearly identical. We agree
`with Patent Owner that the term “conversational flow” is expressly defined
`in the excerpt of the patent quoted above. Accordingly, for purposes of this
`Decision, 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.
`
`
`II. DISCUSSION
`A. Anticipation Ground Based on Engel
`Petitioner contends that claims 19–22, 25, 26, 29–31, 36–40, and 42
`are anticipated by Engel under 35 U.S.C. § 102(e), citing the testimony of
`Bill Lin, Ph.D., as support. Pet. 10–56 (citing Ex. 1006). We are not
`persuaded that Petitioner has established a reasonable likelihood of
`prevailing on its asserted ground for the reasons explained below.
`
`
`1. Engel
`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.” 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
`
`
`
`9
`
`Packet Intelligence Ex. 2055 Page 9 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`associated with multiple layers of at least one of the protocols.” Id. at col. 2,
`ll. 27–30. A network monitor “collects packets on the network and performs
`some degree of analysis to search for actual or potential problems and to
`maintain statistical information for use in later analysis.” Id. at col. 6,
`ll. 52–65, Fig. 1. A Real Time Parser (RTP) performs layer-by-layer
`protocol parsing with appropriate routines. Id. at col. 11, ll. 25–30, col. 19,
`ll. 53–67, col. 21, ll. 15–30. “As each layer is parsed, the RTP invokes the
`appropriate functions in the statistics module (STATS) to update those
`statistical objects which must be changed.” Id. at col. 11, ll. 35–37.
`Figure 4 of Engel is reproduced below.
`
`
`Figure 4 “illustrates the different layers of a communication between two
`nodes.” Id. at col. 4, ll. 45–46. In Figure 4, “Nodes A and B are exchanging
`packets and are engaged in multiple dialogs.” Id. at col. 9, ll. 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 the two” and often “involve[s] exchanges in both directions.” Id. at
`col. 9, ll. 19–24. As shown in Figure 4, “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
`
`
`
`10
`
`Packet Intelligence Ex. 2055 Page 10 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`connections and response rates.” Id. at col. 9, ll. 37–41. Engel discloses
`keeping a dialog record that contains, inter alia, “the addresses of both ends
`of the dialog concatenated together to form a single address.” Id. at col. 18,
`l. 63–col. 19, l. 4.
`
`
`2. Analysis
`Petitioner argues that Engel discloses all of the limitations of claim
`19. Pet. 12–38. We focus on one limitation in particular, which is
`dispositive of Petitioner’s asserted ground. Claim 19 recites:
`(d) a memory for storing a database comprising none or
`more flow-entries for previously encountered conversational
`flows, each flow-entry identified by identifying information
`stored in the flow-entry;5
`For this limitation, Petitioner argues that Engel’s STATS database is a
`database that stores “statistics relating to stations and dialogs encountered by
`the network monitor.” Id. at 15. Petitioner contends that, through its packet
`processing and use of the STATS database, Engel monitors “conversational
`flows” in two different ways: via “Application Level Dialogs” and
`“Application-Specific Server Statistics.” Id. at 11–12, 15–28.
`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
`
`5 We note that although claim 19 recites “a database comprising none or
`more flow-entries for previously encountered conversational flows”
`(emphasis added), the claim requires “conversational flows” at least due to
`the language of limitation (f). Limitation (f) covers the situation where there
`is an “existing” conversational flow and the situation of storing a new
`flow-entry in the database for a “new” conversational flow.
`
`
`
`11
`
`Packet Intelligence Ex. 2055 Page 11 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`specific Client-Server Pair or a specific Server and all of its clients.’”6 Id. at
`15 (quoting Ex. 1002, col. 34, ll. 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.
`47–48; see Ex. 1002, col. 31, l. 52–col. 49, l. 65 (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, col. 34, ll. 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 I.E. 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
`discloses conversational flows. First, Petitioner contends that Engel teaches
`
`
`6 The ’789 patent states that the ’751 patent is incorporated by reference.
`Ex. 1004, col. 1, ll. 28–33. Also, both patents claim the benefit of U.S.
`Provisional Patent Application No. 60/141,903 and have some of the same
`disclosure in their written descriptions.
`
`
`
`
`12
`
`Packet Intelligence Ex. 2055 Page 12 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`“Application Level Dialogs.” Pet. 15–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 ’789 Patent.” Id. at
`15–16 (citing Ex. 1007, col. 9, l. 27–col. 10, l. 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 16 (quoting Ex. 1007, col. 9, ll. 24–27). According to
`Petitioner, Engel discloses “creating and maintaining dialogs” and collecting
`associated statistics at different layers. Id. at 16–17. 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. at 17 (citing Ex. 1007,
`col. 9, l. 58–col. 10, l. 3). Petitioner concludes that tracking an application-
`level dialog constitutes tracking a conversational flow. Id. at 17–21 (citing
`Ex. 1007, Fig. 7C, showing dialog records that point to dialog statistics data
`structures in the STATS database, and corresponding portions of the source
`code in Ex. 1009).
`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 20–21 (citing Ex. 1006 ¶ 86). Petitioner also
`contends, based on Dr. Lin’s testimony, that “Engel’s deallocation routines
`deallocate dialog records when the period of inactivity for a dialog address
`
`
`
`13
`
`Packet Intelligence Ex. 2055 Page 13 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`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 21 (citing Ex. 1007, col. 17,
`ll. 2–16; Ex. 1006 ¶¶ 106–107).
`Patent Owner responds that Engel’s dialogs are different from
`conversational flows because they are merely “collections of statistics for
`each [Open Systems Interconnection (OSI)] layer across packets (regardless
`of application origin)” and do not relate packets that are the result of an
`application activity. Prelim. Resp. 46–47 (citing Ex. 1007, col. 4, ll. 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 50–51 (quoting Pet. 21; 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
`
`
`
`14
`
`Packet Intelligence Ex. 2055 Page 14 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`
`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 simultaneous dialogs.
`Ex. 1007, col. 9, ll. 9–43 (emphases added).
`
`As shown in Figure 4 (reproduced above in Section II.A.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 col. 4, ll. 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
`
`
`
`15
`
`Packet Intelligence Ex. 2055 Page 15 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`constituting a dialog (see, e.g., id. at col. 9, ll. 37–43) and collection of
`respective statistics for that dialog (see, e.g., id. at col. 4, ll. 24–32).
`However, even if application activity causes the dialog to be created,
`Petitioner does not direct 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 sequences of packets to applications because
`some packets may be lost. Prelim. Resp. 37 (quoting Ex. 1007, col. 3, ll.
`12–14; Ex. 2001 ¶ 74).
`Patent Owner provides the following illustration on page 42 of its
`Preliminary Response:
`
`
`
`16
`
`
`
`Packet Intelligence Ex. 2055 Page 16 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`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 42–43,
`50–51 (“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, col. 9, ll. 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”); col. 9, l. 67–col. 10, l. 3 (“If in fact there exists more than one
`communication thread between Nodes A and B, then these would represent
`separate, different dialogs.”); Ex. 2001 ¶¶ 65–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. 15–22. 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 our interpretation of “conversational
`flow” above requires. See supra Section I.E; Ex. 1003, col. 3, ll. 56–59
`(“What distinguishes this invention from prior art network monitors is that it
`has the ability to recognize disjointed flows as belonging to the same
`
`
`
`17
`
`Packet Intelligence Ex. 2055 Page 17 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`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 in the cited paragraph how
`Engel searches for existing dialogs based on the client-server IP address
`pair, not based on application.7 See Pet. 21 (emphasis added); Ex. 1006
`¶ 86. Indeed, Petitioner acknowledges 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. 21. Nor are we persuaded by Petitioner’s argument
`regarding deallocation. See id. at 21–22. 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, col. 17, ll. 2–16); Prelim. Resp. 51.
`Second, Petitioner argues that Engel teaches “Application-Specific
`Server Statistics.” Pet. 22–28. According to Petitioner, “Engel recognizes
`disjointed flows as belonging to the same conversational flow by tracking
`
`
`7 We also note that Dr. Lin explains in his declaration how Engel’s disclosed
`system works, but does not opine that the reference discloses
`“conversational flows” or explain how any of the limitations of the claims
`are taught by Engel. See Ex. 1006 ¶¶ 51–108 (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”); Prelim.
`Resp. 46. Thus, we determine that Dr. Almeroth’s testimony that Engel
`does not disclose “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
`
`Packet Intelligence Ex. 2055 Page 18 of 22
`
`

`

`IPR2017-00629
`Patent 6,954,789 B2
`
`statistics for a given application and a specific Server and all of its clients.”
`Id. at 22–23. Petitioner argues that
`Engel discloses tracking application-specific server statistics
`(i.e., metrics for a given application and a specific Server and
`all of its clients). . . . Each 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.
`Id. at 23–25 (citing Ex. 1007, Fig. 7B (item 160), col. 18, ll. 41–62, col. 17,
`l. 32–col. 18, l. 40; Ex. 1009, 179, 245–248; Ex. 1006 ¶¶ 62–69).
`As explained above, however, Petitioner has only shown that Engel
`links packets (and tracks corresponding statistics) by layer and client-server
`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