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-00451
`Patent 6,839,751 B1
`____________
`
`Before ELENI MANTIS MERCADER, JUSTIN T. ARBES, and
`WILLIAM M. FINK, Administrative Patent Judges.
`
`ARBES, Administrative Patent Judge.
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`Packet Intelligence Ex. 2054 Page 1 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`
`Sandvine Corporation and Sandvine Incorporated ULC (collectively,
`“Petitioner”) filed a Petition (Paper 2, “Pet.”) requesting inter partes review
`of claims 1–21 of U.S. Patent No. 6,839,751 B1 (Ex. 1002, “the
`’751 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 ’751 Patent1
`The ’751 patent discloses “[a] method of and monitor apparatus for
`analyzing a flow of packets passing through a connection point on a
`computer network.” Ex. 1002, Abstract. The ’751 patent explains that there
`was a need in the art for “a real-time network monitor that can provide
`details as to the application programs being used.” Id. at col. 1, ll. 54–59.
`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 information to “build[] a
`
`
`1 Petitioner challenges patents related to the ’751 patent in Cases
`IPR2017-00450, IPR2017-00629, IPR2017-00630, IPR2017-00769,
`IPR2017-00862, and IPR2017-00863.
`
`
`
`2
`
`Packet Intelligence Ex. 2054 Page 2 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`signature for identifying the conversational flow of the packet,” and
`performing a lookup of “a database of flow records for previously
`encountered conversational flows to determine whether [the] signature is
`from an existing flow.” Id. at col. 2, ll. 11–43, col. 6, ll. 5–19, Fig. 1.
`Figure 3 of the ’751 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. 8, l. 47–col. 9, l. 2. 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. 9,
`l. 16–col. 10, l. 39, col. 29, l. 9–col. 31, l. 6 (describing an example of how
`
`
`
`3
`
`Packet Intelligence Ex. 2054 Page 3 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`the disclosed monitor builds signatures and flow states in the context of a
`Sun Remote Procedure Call (RPC), where, after all of the required
`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. 10, l. 56–col. 13, l. 44. The ’751 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. 13, ll. 11–27.
`
`
`
`
`4
`
`Packet Intelligence Ex. 2054 Page 4 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`
`B. Illustrative Claim
`Claim 1 of the ’751 patent2 recites:
`1. A method of analyzing a flow of packets passing
`through a connection point on a computer network, the method
`comprising:
`(a) receiving a packet from a packet acquisition device
`coupled to the connection point;
`(b) for each received packet, looking up a flow-entry
`database for containing one or more flow-entries for previously
`encountered conversational flows, the looking up to determine
`if the received packet is of an existing flow, a conversational
`flow including an exchange of a sequence of one or more
`packets in any direction between two network entities as a
`result of a particular activity using a particular layered set of
`one or more network protocols, a conversational flow further
`having a set of one or more states, including an initial state;
`(c) if the packet is of an existing flow, identifying the last
`encountered state of the flow, performing any state operations
`specified for the state of the flow, and updating the flow-entry
`of the existing flow including storing one or more statistical
`measures kept in the flow-entry; and
`d) if the packet is of a new flow, performing any state
`operations required for the initial state of the new flow and
`storing a new flow-entry for the new flow in the flow-entry
`database, including storing one or more statistical measures
`kept in the flow-entry,
`wherein every packet passing though the connection
`point is received by the packet acquisition device, and
`wherein at least one step of the set consisting of of step
`(a) and step (b) includes identifying the protocol being used in
`the packet from a plurality of protocols at a plurality of protocol
`layer levels,
`
`
`2 Claim 6 of the ’751 patent was corrected in a Certificate of Correction
`dated March 8, 2005.
`
`
`
`5
`
`Packet Intelligence Ex. 2054 Page 5 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`
`such that the flow-entry database is to store flow entries
`for a plurality of conversational flows using a plurality of
`protocols, at a plurality of layer levels, including levels above
`the network layer.
`
`
`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. 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 1–21 of the ’751 patent on the following
`grounds:
`Reference(s)
`
`Claim(s) Challenged
`
`Basis
`
`Engel
`
`35 U.S.C. § 102(e)4
`
`1–14, 17, and 19–21
`
`Engel and
`Graham-Cumming
`Engel and Colloff
`
`35 U.S.C. § 103(a)
`
`15 and 16
`
`35 U.S.C. § 103(a)
`
`18
`
`
`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 ’751 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. 2054 Page 6 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`
`E. Claim Interpretation
`The Board interprets claims in an unexpired patent using the “broadest
`reasonable construction in light of the specification of the patent in which
`[they] appear[].” 37 C.F.R. § 42.100(b); see also Cuozzo Speed Techs., LLC
`v. Lee, 136 S. Ct. 2131, 2144–46 (2016) (upholding the use of the broadest
`reasonable interpretation standard). Under this standard, we interpret claim
`terms using “the broadest reasonable meaning of the words in their ordinary
`usage as they would be understood by one of ordinary skill in the art, taking
`into account whatever enlightenment by way of definitions or otherwise that
`may be afforded by the written description contained in the applicant’s
`specification.” In re Morris, 127 F.3d 1048, 1054 (Fed. Cir. 1997).
`We presume that claim terms have their ordinary and customary meaning.
`See Trivascular, Inc. v. Samuels, 812 F.3d 1056, 1062 (Fed. Cir. 2016)
`(“Under a broadest reasonable interpretation, words of the claim must be
`given their plain meaning, unless such meaning is inconsistent with the
`specification and prosecution history.”); In re Translogic Tech., Inc., 504
`F.3d 1249, 1257 (Fed. Cir. 2007) (“The ordinary and customary meaning is
`the meaning that the term would have to a person of ordinary skill in the art
`in question.” (internal quotation marks omitted)). A patentee, however, may
`rebut this presumption by acting as his own lexicographer, providing a
`definition of the term in the specification with “reasonable clarity,
`deliberateness, and precision.” In re Paulsen, 30 F.3d 1475, 1480 (Fed. Cir.
`1994). The parties provide proposed interpretations for various claim
`limitations, and cite a district court decision construing certain limitations.
`See Pet. 2–7; Prelim. Resp. 21–30; Ex. 2005. For purposes of this Decision,
`
`
`
`7
`
`Packet Intelligence Ex. 2054 Page 7 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`however, we conclude that only one term requires interpretation:
`“conversational flow.”
`Claim 1 recites (emphases added):
`(b) for each received packet, looking up a flow-entry
`database for containing one or more flow-entries for previously
`encountered conversational flows, the looking up to determine
`if the received packet is of an existing flow, a conversational
`flow including an exchange of a sequence of one or more
`packets in any direction between two network entities as a
`result of a particular activity using a particular layered set of
`one or more network protocols, a conversational flow further
`having a set of one or more states, including an initial state;
`. . .
`such that the flow-entry database is to store flow entries
`for a plurality of conversational flows using a plurality of
`protocols, at a plurality of layer levels, including levels above
`the network layer.
`Claim 17 similarly recites (emphases added):
`(b) a memory for storing a database for containing one or
`more flow-entries for previously encountered conversational
`flows to which a received packet may belong, a conversational
`flow including an exchange of a sequence of one or more
`packets in any direction between two network entities as a
`result of a particular activity using a particular layered set of
`one or more network protocols, a conversational flow further
`having a set of one or more states, including an initial state;
`. . .
`wherein the database is to store flow entries for a
`plurality of conversational flows using a plurality of protocols,
`at a plurality of layer levels, including levels above the network
`layer.
`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
`
`
`
`8
`
`Packet Intelligence Ex. 2054 Page 8 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`‘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 made by the patentees during prosecution of the
`’751 patent and a related application, as well as the following disclosure in
`related U.S. Patent No. 6,651,099 B1 (Ex. 1003, “the ’099 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.
`Pet. 3–4 (quoting Ex. 1003, col. 2, ll. 34–45) (emphases omitted).
`Relying on the same disclosure from the ’099 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–26. 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 25–26 (citing Ex. 2005, 6).
`
`
`
`9
`
`Packet Intelligence Ex. 2054 Page 9 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`
`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 ’099 patent quoted above, and that the definition applies
`to the term as used in the ’751 patent.5 Patent Owner’s proposed
`interpretation also is consistent with how the term is used in the context of
`the challenged claims. For example, claim 1 recites “a conversational flow
`including an exchange of a sequence of one or more packets in any direction
`between two network entities as a result of a particular activity,” which is
`consistent with the “as a result of an activity” language in Patent Owner’s
`proposed interpretation. 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 1–14, 17, and 19–21 are anticipated by
`Engel under 35 U.S.C. § 102(e), citing the testimony of Bill Lin, Ph.D., as
`
`
`5 The ’751 patent states that the application that issued as the ’099 patent is
`incorporated by reference. Ex. 1002, col. 1, ll. 17–20. Also, the ’751 and
`’099 patents both claim the benefit of U.S. Provisional Patent Application
`No. 60/141,903, and have some of the same disclosure in their written
`descriptions. See Trustees of Columbia Univ. v. Symantec Corp., 811 F.3d
`1359, 1369 (Fed. Cir. 2016) (“where multiple patents ‘derive from the same
`parent application and share many common terms, we must interpret the
`claims consistently across all asserted patents’” (citation omitted)).
`
`
`
`10
`
`Packet Intelligence Ex. 2054 Page 10 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`support. Pet. 12–62 (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
`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.
`
`
`
`11
`
`Packet Intelligence Ex. 2054 Page 11 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`
`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
`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 1.
`Pet. 12–40. We focus on one limitation in particular, which is dispositive of
`Petitioner’s asserted ground. Claim 1 recites:
`
`
`
`12
`
`Packet Intelligence Ex. 2054 Page 12 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`
`(b) for each received packet, looking up a flow-entry
`database for containing one or more flow-entries for previously
`encountered conversational flows, the looking up to determine
`if the received packet is of an existing flow, a conversational
`flow including an exchange of a sequence of one or more
`packets in any direction between two network entities as a
`result of a particular activity using a particular layered set of
`one or more network protocols, a conversational flow further
`having a set of one or more states, including an initial state.
`For this limitation, Petitioner argues that Engel’s STATS database is a
`flow-entry database that stores “statistics relating to stations and dialogs
`encountered by the network monitor,” and “Engel uses lookup routines to
`determine whether a received frame belongs to a previously encountered
`flow stored in the STATS database.” Id. at 14–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 12–30.
`At the outset, we note that Petitioner’s arguments are premised on its
`position that 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.’” 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.
`48–49; 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
`
`
`
`13
`
`Packet Intelligence Ex. 2054 Page 13 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`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
`“Application Level Dialogs.” Pet. 16–23. 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 ’751 Patent.” Id. at
`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–17 (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 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
`
`
`
`14
`
`Packet Intelligence Ex. 2054 Page 14 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`File System (NFS)] mount request).” Id. (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 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 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–22 (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. 47–48 (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
`
`
`
`15
`
`Packet Intelligence Ex. 2054 Page 15 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`application activity between a client and server is insufficient because a
`conversational flow requires relating flows for specific application activities.
`Id. at 51–52 (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
`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
`
`
`
`16
`
`Packet Intelligence Ex. 2054 Page 16 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`
`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
`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. 38 (quoting Ex. 1007, col. 3,
`ll. 12–14; Ex. 2001 ¶ 74).
`
`
`
`17
`
`Packet Intelligence Ex. 2054 Page 17 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`
`Patent Owner provides the following illustration on page 43 of its
`Preliminary Response:
`
`
`
`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, col. 9, ll. 9–43
`(“a dialog is a communication between a sender and a receiver, which is
`
`
`
`18
`
`Packet Intelligence Ex. 2054 Page 18 of 24
`
`

`

`IPR2017-00451
`Patent 6,839,751 B1
`
`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. 16–23. 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. 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 in the cited paragraph how
`Engel searches for existing dialogs based on the client-server IP address
`pair, not based on application.6 See Pet. 21 (emphasis added); Ex. 1006
`
`
`6 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 statin