`571-272-7822
`
`Paper 48
`Date: September 8, 2021
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`JUNIPER NETWORKS, INC. and PALO ALTO NETWORKS, INC.,
`Petitioner,
`v.
`PACKET INTELLIGENCE LLC,
`Patent Owner.
`
`IPR2020-00337
`Patent 6,771,646 B1
`
`
`
`
`
`
`
`
`
`Before STACEY G. WHITE, CHARLES J. BOUDREAU, and
`JOHN D. HAMANN, Administrative Patent Judges.
`BOUDREAU, Administrative Patent Judge.
`
`
`
`JUDGMENT
`Final Written Decision
`Determining Some Challenged Claims Unpatentable
`35 U.S.C. § 318(a)
`
`
`
`
`
`
`
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`
`INTRODUCTION
`I.
`This is a Final Written Decision in an inter partes review challenging
`the patentability of claims 1–3, 7, 16, and 18 (“the challenged claims”) of
`U.S. Patent No. 6,771,646 B1 (Ex. 1003, “the ’646 patent”). We have
`jurisdiction under 35 U.S.C. § 6 and enter this Decision pursuant to
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For the reasons set forth below,
`we determine that Petitioner has shown, by a preponderance of the evidence,
`that claims 1, 2, 7, 16, and 18 are unpatentable, but that Petitioner has not
`shown that claim 3 is unpatentable. See 35 U.S.C. § 316(e).
`II. BACKGROUND
`A. Procedural History
`Juniper Networks, Inc. and Palo Alto Networks, Inc. (collectively
`“Petitioner”) filed a Petition (Paper 3, “Pet.”) requesting inter partes review
`of claims 1–3, 7, 16, and 18 of the ’646 patent pursuant to 35 U.S.C. § 311.
`Petitioner supported its Petition with the Declaration of Dr. Jon B.
`Weissman. Ex. 1006. Packet Intelligence LLC (“Patent Owner”) filed a
`Preliminary Response. Paper 7 (“Prelim. Resp.”).1
`On September 10, 2020, pursuant to 35 U.S.C. § 314(a), we instituted
`trial to determine whether any challenged claim of the ’646 patent is
`unpatentable based on the grounds raised in the Petition:
`
`
`1 On our authorization (Paper 8), Petitioner also filed a Preliminary Reply
`(Paper 9), and Patent Owner filed a Preliminary Sur-reply (Paper 10) related
`to discretionary denial of institution under 35 U.S.C. § 314(a).
`
`2
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`Claims
`35 U.S.C. §2
`Challenged
`1–3, 7, 16, 18 103(a)
`1–3, 7, 16, 18 103(a)
`1–3, 7, 16, 18 103(a)
`
`References
`Riddle,3 Ferdinand,4 Wakeman5
`Riddle, Ferdinand, Wakeman, Yu6
`Riddle, Ferdinand, Wakeman, RFC19457
`
`Paper 20, 8, 56 (“Institution Decision” or “Inst. Dec.”).8
`Patent Owner filed a Response. Paper 26 (“PO Resp.”). Patent
`Owner supported its Response with the Declaration of Cathleen T. Quigley.
`Ex. 2061. Petitioner filed a Reply to Patent Owner’s Response. Paper 30
`(“Reply”). Patent Owner filed a Sur-reply. Paper 32 (“Sur-reply”).
`A combined oral hearing in this proceeding and IPR2020-00336,
`involving a related patent, was held on June 9, 2021. A transcript of the
`hearing is included in the record. Paper 47 (“Tr.”). The transcript of an oral
`hearing held the same day in cases IPR2020-00338, IPR2020-00339, and
`
`
`2 The Leahy-Smith America Invents Act (“AIA”) included revisions to
`35 U.S.C. § 103 that became effective on March 16, 2013. Because the
`’646 patent issued from an application filed before March 16, 2013, we
`apply the pre-AIA version of the statutory basis for unpatentability.
`3 Riddle et al., US 6,412,000 B1 (issued June 25, 2002) (Ex. 1008).
`4 Ferdinand et al., WO 92/19054 (published Oct. 29, 1992) (Ex. 1009).
`5 Wakeman et al., US 5,740,175 (issued Apr. 14, 1998) (Ex. 1014).
`6 Yu, US 6,625,150 B1 (issued Sept. 23, 2003) (Ex. 1011).
`7 T. Berners-Lee et al., Hypertext Transfer Protocol -- HTTP/1.0, Request
`for Comments: 1945, Network Working Group (May 1996) (Ex. 1010).
`8 Patent Owner filed a Request for Rehearing of the Institution Decision
`(Paper 24), which we denied (Paper 27).
`
`3
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`IPR2020-00486, also involving patents related to the ’646 patent, also is
`included in the record of this proceeding.9 Paper 46.
`Following oral hearing, we ordered the parties to provide additional
`briefing on the claim-construction arguments presented in the briefs and at
`oral hearing. Paper 41 (“Order”). Petitioner and Patent Owner each filed
`respective Opening Briefs on claim construction. See Paper 42
`(“Petitioner’s Opening Brief” or “Pet. Br.”); Paper 43 (“Patent Owner’s
`Opening Brief” or “PO Br.”). Petitioner filed a Responsive Brief to Patent
`Owner’s Opening Brief, Paper 44 (“Petitioner’s Responsive Brief” or “Pet.
`Resp. Br.”), and Patent Owner filed a Responsive Brief to Petitioner’s
`Opening Brief, Paper 45 (“Patent Owner’s Responsive Brief” or “PO Resp.
`Br.”).
`
`B. Real Parties in Interest
`Petitioner identifies Juniper Networks, Inc. and Palo Alto Networks,
`Inc. as its real parties in interest. Pet. 1. Patent Owner identifies Packet
`Intelligence LLC and Packet Intelligence Holdings LLC as its real parties in
`interest. Paper 6, 2.
`C. Related Matters
`The parties identify two district court litigations as related matters that
`involve the ’646 patent: Packet Intelligence LLC v. Juniper Networks, Inc.,
`3:19-cv-04741 (N.D. Cal.) and Palo Alto Networks, Inc. v. Packet
`Intelligence LLC, No. 3:19-cv-02471 (N.D. Cal). Pet. 1; Paper 6, 2. The
`parties also identify Packet Intelligence LLC v. NetScout Systems, Inc., 2:16-
`
`
`9 The parties had no objection to entering into this record the transcript from
`the oral hearing for IPR2020-00338, IPR2020-00339, and IPR2020-00486.
`Tr. 7:15–8:5; see also Paper 46, 5:22–6:10.
`
`4
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`cv-230-JRG (E.D. Tex.) and Packet Intelligence LLC v. NetScout Sys., Inc.,
`No. 19-2041 (Fed. Cir.) as related matters. Pet. 1; Paper 6, 2.
`The parties also identify as related matters IPR2017-00450 and
`IPR2019-01292, no longer pending before the Board, which challenged
`certain claims of the ’646 patent, as well as certain other earlier proceedings
`that challenged claims of various related patents. Pet. 2; Paper 6, 3–5.
`D. The ’646 Patent (Ex. 1003)
`The ’646 patent, titled “Associative Cache Structure for Lookups and
`Updates of Flow Records in a Network Monitor,” discloses a network
`activity monitor with a cache subsystem. Ex. 1003, code (54), 1:42–3: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 1: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
`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 1:66–2:28, 4:61–5: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 2: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 2:53–56.
`“Replacing least recently used flow-entries is preferred because it is likely
`
`5
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`that a packet following a recent packet will belong to the same flow.” Id.
`at 2:56–58.
`Figure 3 of the ’646 patent is reproduced below.
`
`
`Figure 3, above, depicts various components of network packet monitor 300,
`including parser subsystem 301, analyzer subsystem 303, and database of
`known flows 324. Ex. 1003, 7:36–58. Parser subsystem 301 “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 8:5–9:28, 27:66–29: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,
`
`6
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`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. Ex. 1003, 9:45–12:34, 19:46–20:2, 30:13–36: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
`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—an [sic] 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 11:67–12:17.
`
`7
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`E. The Challenged Claims
`Petitioner challenges claims 1–3, 7, 16, and 18 of the ’646 patent, of
`which claims 1, 7, and 16 are independent. Pet. 7. Claims 1 and 16,
`reproduced below, illustrate the claimed subject matter.
`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 flow-entry database, the looking up being via 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.
`16. A method of examining packets passing through a connection
`point on a computer network, each packets conforming to one or
`more protocols, the method comprising:
`
`8
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`(a) receiving a packet from a packet acquisition device;
`(b) performing one or more parsing/extraction operations
`on the packet to create a parser record comprising a
`function of selected portions of the packet;
`(c) 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;
`(d) if the packet is of an existing flow, classifying the
`packet as belonging to the found existing flow; and
`(e) if the packet is of a new flow, storing a new flow-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 parsing/extraction operations depend on one or more
`of the protocols to which the packet conforms.
`Ex. 1003, 36:39–67, 39:10–40:4, 44–47 (Certificates of Correction).
`III. ANALYSIS
`We have reviewed the parties’ respective briefs as well as the relevant
`evidence discussed in those papers. For the reasons discussed in detail
`below, we determine that Petitioner has shown by a preponderance of the
`evidence that claims 1–2, 7, 16, and 18 of the ’646 patent are unpatentable
`under 35 U.S.C. § 103 as having been obvious, but has not shown by a
`preponderance of the evidence that claim 3 is unpatentable.
`A. Legal Standards
`To prevail in its challenges to the patentability of the challenged
`claims, Petitioner must demonstrate by a preponderance of the evidence that
`the claims are unpatentable. 35 U.S.C. § 316(e); 37 C.F.R. § 42.1(d) (2019).
`“In an [inter partes review], the petitioner has the burden from the onset to
`
`9
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`show with particularity why the patent it challenges is unpatentable.”
`Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363 (Fed. Cir. 2016)
`(citing 35 U.S.C. § 312(a)(3) (2012) (requiring inter partes review petitions
`to identify “with particularity . . . the evidence that supports the grounds for
`the challenge to each claim”)). This burden of persuasion never shifts to
`patent owner. See Dynamic Drinkware, LLC v. Nat’l Graphics, Inc., 800
`F.3d 1375, 1378 (Fed. Cir. 2015); see also In re Magnum Oil Tools Int’l,
`Ltd., 829 F.3d 1364, 1375–78 (Fed. Cir. 2016) (discussing the burden of
`proof in inter partes review).
`A claim is unpatentable for obviousness if, to one of ordinary skill in
`the pertinent art, “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.” 35 U.S.C. § 103(a)
`(2006); see also KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007).
`The question of obviousness is resolved on the basis of underlying factual
`determinations including (1) the scope and content of the prior art; (2) any
`differences between the claimed subject matter and the prior art; (3) the level
`of ordinary skill in the art; and (4) when in evidence, objective evidence of
`nonobviousness.10 Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966). A
`petitioner cannot satisfy its burden of proving obviousness by employing
`“mere conclusory statements.” Magnum Oil, 829 F.3d at 1380. Moreover, a
`decision on the ground of obviousness must include “articulated reasoning
`with some rational underpinning to support the legal conclusion of
`
`
`10 The parties do not direct our attention to any evidence of objective indicia
`of nonobviousness.
`
`10
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`obviousness.” KSR, 550 U.S. at 418 (citing In re Kahn, 441 F.3d 977, 988
`(Fed. Cir. 2006)).
`We analyze Petitioner’s asserted grounds of unpatentability in
`accordance with the above-stated principles.
`B. Level of Ordinary Skill in the Art
`We consider the asserted grounds of unpatentability in view of the
`understanding of a person of ordinary skill in the art and, thus, begin with
`the level of ordinary skill in the art. The level of ordinary skill in the art is
`“a prism or lens through which . . . the Board views the prior art and the
`claimed invention” to prevent hindsight bias. Okajima v. Bourdeau, 261
`F.3d 1350, 1355 (Fed. Cir. 2001). In assessing the level of ordinary skill in
`the art, various factors may be considered, including the “type of problems
`encountered in the art; prior art solutions to those problems; rapidity with
`which innovations are made; sophistication of the technology; and
`educational level of active workers in the field.” In re GPAC Inc., 57 F.3d
`1573, 1579 (Fed. Cir. 1995). “[O]ne or more factors may predominate.” Id.
`Petitioner contends that an ordinarily skilled artisan 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.” Pet. 7–8 (citing,
`inter alia, Ex. 1006 ¶¶ 195–201). In our Institution Decision, we adopted
`Petitioner’s articulation of the level of skill in the art, which we determined
`was consistent with the ’646 patent and the asserted prior art. Inst. Dec. 25–
`26. In its Response, Patent Owner states that it “generally does not object to
`this finding.” PO Resp. 22.
`
`11
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`We apply Petitioner’s definition of the level of ordinary skill in the
`art, as we did in the Institution Decision. Inst. Dec. 25–26. We also
`maintain our determination that the definition offered by Petitioner is
`consistent with the teachings of the ’646 patent and the prior art of record.
`Cf. Okajima, 261 F.3d at 1355 (noting that the prior art itself may reflect an
`appropriate level of skill in the art).
`C. Claim Construction
`In interpreting the claims of the ’646 patent, we “us[e] the same claim
`construction standard that would be used to construe the claim[s] in a civil
`action under 35 U.S.C. [§] 282(b).” 37 C.F.R. § 42.100(b). The claim
`construction standard includes construing claims in accordance with the
`ordinary and customary meaning of such claims as would have been
`understood by one of ordinary skill in the art and the prosecution history
`pertaining to the patent. See id.; Phillips v. AWH Corp., 415 F.3d 1303,
`1312–14 (Fed. Cir. 2005) (en banc). We need not explicitly interpret every
`claim term for which the parties propose a construction. See 35 U.S.C.
`§ 314(a) (2012); Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795,
`803 (Fed. Cir. 1999) (“[O]nly those terms need be construed that are in
`controversy, and only to the extent necessary to resolve the controversy.”);
`see also Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co., 868 F.3d
`1013, 1017 (Fed. Cir. 2017) (applying Vivid Techs. in the context of an inter
`partes review).
`1. Incorporation by reference of previous disclosures
`The ’646 patent claims the benefit of U.S. Provisional Application
`No. 60/141,903, filed on June 30, 1999 (Ex. 1016, “the provisional
`application”). See Ex. 1003, code (60). The ’646 patent states that the
`contents of the provisional application, as well as the contents of several
`
`12
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`other U.S. patents and applications, including U.S. Patent No. 6,651,099,
`issued on November 18, 2003 (Ex. 1001, “the ’099 patent”), “are
`incorporated herein by reference.” See id. at 1:7–11 (incorporating by
`reference the provisional application), 1:16–18 (incorporating by reference
`the ’099 patent), 1:19–23 (incorporating by reference U.S. Patent No.
`6,665,725), 1:25–29 (incorporating by reference U.S. Patent Application No.
`09/608,126), 1:30–33 (incorporating by reference U.S. Patent Application
`No. 09/608,267). Throughout their papers, the parties refer to the
`disclosures of the ’099 patent and the provisional application, and state that
`the ’646 patent incorporates the entire contents of those disclosures. See,
`e.g., PO Resp. 2 n.1; Reply 2 n.1, 3–4.
`We agree with the parties that the ’646 patent incorporates the
`disclosures of the ’099 patent and the provisional application by specific
`reference to those documents. Ex. 1003, code (60), 1:7–11, 1:16–18; see
`also 37 C.F.R. § 1.57. Thus, we also refer to the ’099 patent and the
`provisional application when discussing claim construction—not only for
`consistency with the parties, but also for consistency throughout our final
`decisions involving related inter partes proceedings between these parties.
`See Advanced Display Sys., Inc. v. Kent State Univ., 212 F.3d 1272, 1282
`(Fed. Cir. 2000) (stating that material incorporated by reference is
`“effectively part of the host document as if it were explicitly contained
`therein”); see also Trs. of Columbia Univ. v. Symantec Corp., 811 F.3d
`1359, 1365–66 (Fed. Cir. 2016) (using statements in a provisional
`application to construe claim terms in a patent incorporating the provisional
`application by reference).
`
`13
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`2. Overview
`The only claim-construction dispute remaining in this proceeding
`concerns the meaning of “conversational flow[s],” as recited in independent
`claims 1, 7, and 16. See, e.g., Ex. 1003, 36:46–47 (claim 1 reciting “a
`memory for storing a database comprising flow-entries for previously
`encountered conversational flows”). At the heart of the parties’ dispute is
`the following passage from the ’099 patent:
`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.
`Ex. 1001, 2:37–45 (emphases added). In our Institution Decision, we
`preliminarily construed “conversational flow” as a “sequence of packets that
`are exchanged in any direction as a result of an activity.” Inst. Dec. 29. We
`declined to include the phrases “for instance, the running of an application
`on a server as requested by a client” and “some conversational flows involve
`more than one connection,[11] and some even involve more than one
`exchange of packets between a client and server” in the construction of
`“conversational flow,” as Patent Owner had requested. Id. We explained
`that those passages, because they begin with the phrases “for instance,”
`“where some,” and “some,” are “merely exemplary and non-limiting.” Id.
`
`
`11 The ’099 patent expressly defines “connection flow”: “The term
`‘connection flow’ is commonly used to describe all the packets involved
`with a single connection.” Ex. 1001, 2:35–37. Neither party disputes this
`definition of “connection flow.”
`
`14
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`Petitioner does not challenge our preliminary construction. Tr. 9:20–
`10:15. Patent Owner, however, argues that our construction captures only a
`“part of the definition in the specification,” and improperly “excludes some
`of the clarifying language that is also part of the explicit definition in the
`specification.” PO Resp. 23. According to Patent Owner, “[t]hat clarifying
`language is important for understanding the nature of a conversational flow.”
`Id.
`
`Specifically, Patent Owner argues that the written description of the
`’646 patent provides an express definition of the term “conversational flow”
`and that the express definition controls even though it contains exemplary
`language. Id. at 23–24 (citing Sinorgchem Co., Shandong v. Int’l Trade
`Comm’n, 511 F.3d 1132, 1137 (Fed. Cir. 2007)). Patent Owner argues that
`the language following “for instance” is necessary for understanding a
`“conversational flow,” because that language “makes apparent that
`‘conversational flow’ must relate to a conversation” and “involves an
`application activity involving the same client.” Id. at 26 (emphasis added);
`see also Sur-Reply 1 (arguing that an “‘activity’ occurs between specific
`entities”); PO Br. 1 (arguing that an activity “must relate to the actions of a
`particular client or end user”). “Ignoring that language,” Patent Owner
`argues, “risks losing the basic and fundamental requirement of a
`‘conversation.’” PO Resp. 26
`Patent Owner also argues our construction is incorrect because, prior
`to this inter partes review, “every tribunal to have considered the proper
`construction for ‘conversational flow’ has accepted . . . the same
`construction advanced by Patent Owner” here:
`the sequence of packets that are exchanged in any direction as a
`result of an activity—for instance, the running of an application
`
`15
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`on a server as requested by a client—and where some
`conversational flows involved more than one connection, and
`some even involve more than one exchange of packets between
`a client and server.
`PO Resp. 24–25. As an example, Patent Owner argues that the District
`Court for the Eastern District of Texas adopted this construction in Packet
`Intelligence LLC v. NetScout Systems, Inc., and that the Court of Appeals for
`the Federal Circuit “addressed conversational flows and connection flows
`when affirming the jury’s infringement verdict in NetScout, which
`necessarily hinged on applying the court’s claim construction of
`‘conversational flow.’” Id. at 25 (citing Ex. 2060, 3).
`3. Analysis
`Independent claims 1 and 7 recite a database that includes “flow-
`entries” for “previously encountered conversational flows.” Ex. 1003,
`36:46–47 (claim 1), 38:7–9 (claim 7). Independent claim 16 recites a
`“database comprising none or more flow-entries for previously encountered
`conversational flows.” See id. at 39:18–20. As explained above, the parties
`agree that “conversational flow” includes “the sequence of packets that are
`exchanged in any direction as a result of an activity,” but disagree about
`whether the phrases “for instance, the running of an application on a server
`as requested by a client” and “some conversational flows involve more than
`one connection, and some even involve more than one exchange of packets
`between a client and server” should limit the meaning of “conversational
`flow.” Patent Owner argues that those phrases are necessary because they
`make clear that a conversational flow is client-specific. Thus, the parties’
`basic dispute is whether a conversational flow is limited to a specific client
`or user, as Patent Owner argues, or may include multiple clients or users, as
`Petitioner contends. Compare, e.g., PO Resp. 26 (arguing that “the basic
`
`16
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`and fundamental requirement” of a “conversational flow” is that it “involves
`an application activity involving the same client”), with Reply 3 (contending
`that “[t]he definitional language of ‘conversational flow’ doesn’t contain any
`requirement for identifying flows based on a particular user or client”).
`Starting with the passage reproduced above that we identified as the
`heart of the parties’ dispute (Ex. 1001, 2:37–45), we determine that the “for
`instance” phrase is exemplary and does not limit a “conversational flow” to
`a specific client or user. The phrase “for instance” is synonymous with “for
`example,” and necessarily indicates that “the running of an application on a
`server as requested by a client” exemplifies, but does not limit, the
`conversational flow to a server and a specific client or user.
`Our determination that the “for instance” phrase is exemplary and
`non-limiting is consistent with Patent Owner’s argument in its Preliminary
`Response that the “some” phrase (“some conversational flows involve more
`than one connection, and some even involve more than one exchange of
`packets between a client and server”) is non-limiting. Specifically, Patent
`Owner argued that the use of the word “some” necessarily means that “some
`conversational flows involve multiple connections, while, some involve a
`single connection.” Prelim. Resp. 24. Similarly here, while “conversational
`flow” certainly may involve the running of an application on a server as
`requested by a single client or user, “conversational flow” is not limited to a
`single client or user.
`Indeed, the ’099 patent and the provisional application expressly
`contemplate classifying connection flows from different clients into the
`same conversational flow when those connections involve the same activity.
`These documents describe, in the context of identifying packets as part of a
`conversational flow, a client/server protocol known as Service Advertising
`
`17
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`Protocol (SAP), which is “used to identify the services and addresses of
`servers attached to a network.” Ex. 1016, 3:12–14; Ex. 1001, 2:49–52. The
`provisional application describes a packet exchange between a client and the
`server in which the client sends a SAP request to a server for print service,
`and the server sends a SAP reply that identifies the print service address:
`In a first exchange, a client sends a SAP request to a server, for
`example, for print service. The server sends a SAP reply that
`identifies a particular address, for example, SAP #5, as the print
`service on that server. Such may be responses used to update a
`table, for example in a router, known as the Server Information
`Table.
`Ex. 1016, 3:14–18; see also Ex. 1001, 2:53–58. The provisional application
`then describes a client who has “inadvertently seen” the SAP reply, and
`therefore does not need to make a SAP request, but may send a print request
`directly to SAP #5:
`A client who has inadvertently seen this reply or who has access
`to the table (via the router that has the Server Information Table,
`for example) would know that SAP #5 for such this [sic] server
`is a print service. Therefore, in order to print data on the server,
`such a client does not need to make the request for a print service,
`but simply to send data to be printed specifying SAP #5.
`Ex. 1016, 3:18–23; see also Ex. 1001, 2:58–64.
`
`The provisional application explains that the packet exchange between
`the client who has “inadvertently seen” the print service address and SAP #5
`is not connected to the initial packet exchange, “which was with a different
`client”:
`This sending of data to be printed again involves an exchange of
`data between a client and a server, disjoint [sic] from the previous
`exchange which was with a different client setting up that
`SAP #5 is a print service on this server is a second connection.
`
`18
`
`
`
`IPR2020-00337
`Patent 6,771,646 B1
`Ex. 1016, 3:23–25 (emphasis added). Similarly, the ’099 patent describes
`this packet exchange as “independent of the initial exchange.” Ex. 1001,
`2:64–67.
`The provisional application states that “[i]t is desirable for a network
`packet monitor to be able to ‘virtually concatenate’ the first exchange that
`defines SAP #5 as the print service on the server with the second exchange
`that uses the print service.” Ex. 1016, 3:25–28. In this case, the provisional
`application explains, the two packet exchanges (the first between a client
`and the server and the second between a client and SAP #5) “would then be
`correctly identified as being part of the same flow if the clients were the
`same,” but also, “[t]hey would even be recognized if the clients were not the
`same.” Id. at 3:28–30 (emphasis added). Similarly, the ’099 patent states
`that “because one features [sic] of the invention is to correctly identify the
`second exchange as being associated with a print service on that server, such
`exchange would even be recognized if the clients were not the same.”
`Ex. 1001, 3:44–48 (emphasis added).
`We interpret the SAP description in the provisional application and
`’099 patent as describing two seemingly disjointed packet exchanges
`involving two different clients or users (the first packet exchange between a
`client and the server and the second packet exchange between the client who
`has “inadvertently seen” the print service address and SAP #5) as belon