`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-00450
`Patent 6,771,646 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
`
`EX 1056 Page 1
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`
`Sandvine Corporation and Sandvine Incorporated ULC (collectively,
`“Petitioner”) filed a Petition (Paper 2, “Pet.”) requesting inter partes review
`of claims 1–3 and 7–20 of U.S. Patent No. 6,771,646 B1 (Ex. 1001, “the
`’646 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 ’646 Patent1
`The ’646 patent discloses a network activity monitor with a cache
`subsystem. Ex. 1001, col. 1, l. 42–col. 3, l. 14. The ’646 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. 42–47. 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 signature for identifying the conversational flow of
`
`
`1 Petitioner challenges patents related to the ’646 patent in Cases
`IPR2017-00451, IPR2017-00629, IPR2017-00630, IPR2017-00769,
`IPR2017-00862, and IPR2017-00863.
`
`
`
`2
`
`EX 1056 Page 2
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`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. 1, l. 66–col. 2, l. 28, col. 4,
`l. 61–col. 5, l. 8, Fig. 1. The ’646 patent states that due to the high speed at
`which packets enter the system, it is advantageous to use a cache system for
`the memory containing the flow database. Id. at col. 2, ll. 37–62. “One
`desirable property of such a cache system is a least recently used (LRU)
`replacement policy that replaces the LRU flow-entry when a cache
`replacement is needed.” Id. at col. 2, ll. 53–56. “Replacing least recently
`used flow-entries is preferred because it is likely that a packet following a
`recent packet will belong to the same flow.” Id. at col. 2, ll. 56–58.
`Figure 3 of the ’646 patent is reproduced below.
`
`
`
`
`
`3
`
`EX 1056 Page 3
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`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. 7, ll. 36–58. 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. 8, l. 5–col. 9, l. 28,
`col. 27, l. 66–col. 29, l. 61 (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 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 (looking in the cache first),
`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. 9, l. 45–col. 12,
`l. 34, col. 19, l. 46–col. 20, l. 2, col. 30, l. 13–col. 36, l. 28, Fig. 11. The
`’646 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
`
`
`
`4
`
`EX 1056 Page 4
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`
`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—can 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. 11, l. 67–col. 12, l. 17.
`
`
`B. Illustrative Claim
`Claim 1 of the ’646 patent2 recites:
`1. A packet monitor for examining packets passing
`through a connection point on a computer network, each packet
`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) a memory for storing a database comprising
`flow-entries for previously encountered conversational flows to
`which a received packet may belong, a conversational flow
`being an exchange of one or more packets in any direction as a
`result of an activity corresponding to the flow;
`(c) a cache subsystem coupled to the flow-entry database
`memory providing for fast access of flow-entries from the
`flow-entry database;
`(d) a lookup engine coupled to the packet acquisition
`device and to the cache subsystem and configured to lookup
`whether a received packet belongs to a flow-entry in the
`
`2 Claims 1, 6, 7, 12, and 13 of the ’646 patent were corrected in Certificates
`of Correction dated September 21, 2004, November 16, 2004, and October
`15, 2013.
`
`
`
`5
`
`EX 1056 Page 5
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`
`flow-entry database, the looking up being via the cache
`subsystem; and
`(e) a state processor coupled to the lookup engine and to
`the flow-entry-database memory, the state processor being to
`perform any state operations specified for the state of the flow
`starting from the last encountered state of the flow in the case
`that the packet is from an existing flow, and to perform any
`state operations required for the initial state of the new flow in
`the case that the packet is not from an existing flow.
`
`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 Aug. 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 1–3 and 7–20 of the ’646 patent on the
`following grounds:
`References
`
`Basis
`
`Claims Challenged
`
`Engel and Colloff
`
`35 U.S.C. § 103(a)4
`
`1–3, 7–9, 12, and
`15–20
`
`
`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).
`
`
`
`6
`
`EX 1056 Page 6
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`
`References
`
`Engel, Colloff, and
`Baker
`Engel, Colloff, and
`Graham-Cumming
`
`
`
`Basis
`
`Claims Challenged
`
`35 U.S.C. § 103(a)
`
`10 and 11
`
`35 U.S.C. § 103(a)
`
`13 and 14
`
`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
`
`
`4 The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284
`(2011) (“AIA”), amended 35 U.S.C. § 103. Because the challenged claims
`of the ’646 patent have an effective filing date before the effective date of
`the applicable AIA amendment, we refer to the pre-AIA version of
`35 U.S.C. § 103.
`
`
`
`7
`
`EX 1056 Page 7
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`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–8; Prelim. Resp. 20–31; Ex. 2005. For purposes of this Decision,
`however, we conclude that only one term requires interpretation:
`“conversational flow.”
`Claim 1 recites “a memory for storing a database comprising
`flow-entries for previously encountered conversational flows to which a
`received packet may belong, a conversational flow being an exchange of one
`or more packets in any direction as a result of an activity corresponding to
`the flow.” Claim 7 recites “a memory for storing a database of one or more
`flow-entries for any previously encountered conversational flows, each
`flow-entry identified by identifying information stored in the flow-entry.”
`Claim 16 recites “looking up a flow-entry database comprising none or more
`flow-entries for previously encountered conversational flows, the looking up
`using at least some of the selected packet portions and determining if the
`packet is of an existing flow, the lookup being via a cache.”
`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
`
`
`
`8
`
`EX 1056 Page 8
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`than one connection’ or ‘involve more than one exchange of packets
`between a client and server.’” Pet. 3–4. Petitioner acknowledges that the
`claims “require more than identifying and classifying ‘only connection
`flows,’” citing statements made by the patentees during prosecution of the
`’646 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. 23–25. 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).
`The parties’ proposed interpretations are nearly identical. We agree
`with Patent Owner that the term “conversational flow” is expressly defined
`
`
`
`9
`
`EX 1056 Page 9
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`in the excerpt of the ’099 patent quoted above, and that the definition applies
`to the term as used in the ’646 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
`being an exchange of one or more packets in any direction as a result of an
`activity corresponding to the flow,” 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. Obviousness Ground Based on Engel and Colloff
`Petitioner contends that claims 1–3, 7–9, 12, and 15–20 are
`unpatentable over Engel and Colloff under 35 U.S.C. § 103(a), citing the
`testimony of Bill Lin, Ph.D., as support. Pet. 12–54 (citing Ex. 1006).
`
`
`5 The ’646 patent states that the ’099 patent is incorporated by reference.
`Ex. 1001, col. 1, ll. 12–18, col. 1, l. 66–col. 2, l. 7. Also, the ’646 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
`
`EX 1056 Page 10
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`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
`
`EX 1056 Page 11
`
`
`
`IPR2017-00450
`Patent 6,771,646 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. Colloff
`Colloff describes a memory system comprising a main memory and
`cache memory. Ex. 1011, Abstract. Colloff explains that
`[t]he aim of a cache is to keep the most useful data of a large
`amount of data in a small, fast memory in order to avoid having
`
`
`
`12
`
`EX 1056 Page 12
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`
`to retrieve the data from the larger, slower main memory. If the
`required data is in the cache, it is said that a “hit” has occurred;
`otherwise a “miss” has occurred. The percentage of misses is
`called the “miss rate.”
`Id. at col. 1, ll. 22–28.
`
`
`3. Level of Ordinary Skill in the Art
`Section 103(a) forbids issuance of a patent when “the
`differences between the subject matter sought to be patented
`and the prior art are such that the subject matter as a whole
`would have been obvious at the time the invention was made to
`a person having ordinary skill in the art to which said subject
`matter pertains.”
`KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007) (quoting 35 U.S.C.
`§ 103(a)). Petitioner argues that a person of ordinary skill in the art at the
`time of the ’646 patent would have had
`at least a bachelor’s degree, or equivalent, in electrical
`engineering, computer engineering, computer science, or a
`related field or an equivalent number of years of working
`experience, and one to two years of experience in networking
`environments, including at least some experience with network
`traffic monitors, analyzers, and/or firewalls or other intrusion
`detection systems.
`Pet. 2 (citing Ex. 1006 ¶¶ 20–22). Patent Owner argues that a person of
`ordinary skill in the art would have had “the equivalent of a four-year degree
`from an accredited institution (usually denoted as a B.S. degree) in computer
`science, computer engineering or the equivalent and experience with, or
`exposure to, packet analysis techniques,” as well as “approximately 1–2
`years of professional experience with packet network communication
`protocols.” Prelim. Resp. 22–23 (citing Ex. 2001 ¶ 24). The parties’
`proposed definitions are very similar. For example, experience with
`
`
`
`13
`
`EX 1056 Page 13
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`“network traffic monitors [and] analyzers” in “networking environments”
`(Petitioner’s proposed definition) likely would include experience with
`“packet network communication protocols” and “packet analysis
`techniques” (Patent Owner’s proposed definition). Based on this record,
`including our review of the ’646 patent and the types of problems and
`solutions described in the ’646 patent and cited prior art, we conclude that a
`person of ordinary skill in the art would have had a bachelor’s degree in
`electrical engineering, computer engineering, computer science, or a related
`field (or its equivalent), and one to two years of experience working in
`networking environments, including at least some experience with network
`traffic monitors and/or analyzers.6 We apply this level of ordinary skill in
`the art for purposes of this Decision.
`
`
`4. Analysis
`Petitioner relies on Engel as allegedly teaching the majority of the
`limitations of independent claim 1, and relies on Colloff solely for the
`“cache subsystem” aspect of claim 1. Pet. 14–37. We focus on one
`limitation in particular, which is dispositive of Petitioner’s asserted ground.
`Claim 1 recites “a memory for storing a database comprising flow-entries for
`previously encountered conversational flows to which a received packet may
`belong, a conversational flow being an exchange of one or more packets in
`any direction as a result of an activity corresponding to the flow.” For this
`limitation, Petitioner argues that Engel’s STATS database is a flow-entry
`
`
`6 We do not include in the definition experience with “firewalls or other
`intrusion detection systems,” as Petitioner proposes, because the relevant art
`is network monitoring and analysis. See, e.g., Ex. 1001, col. 1, ll. 35–39.
`
`
`
`14
`
`EX 1056 Page 14
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`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 13, 15–27.
`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”)7 “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.’”
`Pet. 16 (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
`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
`
`
`7 The ’646 patent states that the application that issued as the ’751 patent is
`incorporated by reference. Ex. 1001, col. 1, ll. 25–29. Also, the ’646 and
`’751 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.
`
`
`
`15
`
`EX 1056 Page 15
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`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
`teaches conversational flows. First, Petitioner contends that Engel teaches
`“Application Level Dialogs.” Pet. 16–21. 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–17 (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 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. 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, col. 9,
`l. 58–col. 10, l. 3). Petitioner concludes that tracking an application level
`dialog constitutes tracking a conversational flow. Id. at 18–19 (citing
`Ex. 1007, Fig. 7C, showing dialog records that point to dialog statistics data
`
`
`
`16
`
`EX 1056 Page 16
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`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 (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 20–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. 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
`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. 20; citing Ex. 2001 ¶¶ 80–81). We agree with
`Patent Owner.
`
`
`
`17
`
`EX 1056 Page 17
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`
`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 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,
`
`
`
`18
`
`EX 1056 Page 18
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`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).
`
`
`
`19
`
`EX 1056 Page 19
`
`
`
`IPR2017-00450
`Patent 6,771,646 B1
`
`
`Patent Owner provides the following illustration on page 43 of its
`Preliminary Response:
`
`
`
`The figure above depicts four packets exchanged between Nod