Trials@uspto.gov
`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)
`
`
`
`
`
`
`
`
`
`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
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
