throbber
Trials@uspto.gov
`Tel: 571-272-7822
`
`
`Paper 42
`Entered: October 18, 2022
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`CLOUDFLARE, INC. and
`SPLUNK INC.
`Petitioner,
`v.
`SABLE NETWORKS, INC.,
`Patent Owner.
`____________
`
`IPR2021-009091
`Patent 8,243,593 B2
`____________
`
`
`Before STACEY G. WHITE, GARTH D. BAER, and
`JULIET MITCHELL DIRBA, Administrative Patent Judges.
`
`DIRBA, Administrative Patent Judge.
`
`
`
`
`JUDGMENT
`Final Written Decision
`Determining Some Non-Disclaimed Challenged Claims Unpatentable
`35 U.S.C. § 318(a)
`
`
`
`1 Splunk, Inc., which filed a petition in IPR2022-00228, has been joined as
`a petitioner in this proceeding.
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`On November 19, 2021, we instituted an inter partes review of claims
`1–44 of U.S. Patent No. 8,243,593 B2 (Ex. 1001, “the ’593 patent”).
`Paper 16 (“Inst. Dec.”). After institution, claims 1, 2, 4–8, 14–16, 25–28,
`and 34–36 of the ’593 patent were statutorily disclaimed (see Ex. 2006), so
`this Decision does not address the patentability of those claims. Having
`considered the full record at trial, we determine that Petitioner has shown
`that claims 3, 9–13, 19–24, 29–33, and 39–44 of the ’593 patent are
`unpatentable under 35 U.S.C. § 103(a), and we determine that Petitioner has
`not shown that claims 17, 18, 37, and 38 of the ’593 patent are unpatentable.
`
`I. BACKGROUND
`A. History of this Proceeding
`On May 7, 2021, Cloudflare, Inc. and SonicWall Inc. 2 filed a Petition
`requesting inter partes review of claims 1–44 of the ’593 patent. Paper 1
`(“Pet.”). Petitioner submitted a declaration from Dr. Kevin Jeffay in
`support. See Ex. 1003. Sable Networks, Inc. 3 (“Patent Owner”) filed a
`Preliminary Response. Paper 8. The parties also filed an authorized pre-
`institution reply and sur-reply to address discretionary denial under
`35 U.S.C. § 314. Papers 9, 11. After reviewing the preliminary record, we
`determined that Cloudflare had demonstrated a reasonable likelihood that it
`would prevail in establishing the unpatentability of at least one challenged
`claim, and we instituted an inter partes review of all challenged claims on
`all grounds asserted in the Petition. Inst. Dec. 57.
`
`2 SonicWall Inc. was subsequently terminated from this proceeding
`following a settlement with Patent Owner. Paper 15 (Termination Order).
`3 Patent Owner also identifies Sable IP, LLC as a real party in interest.
`Paper 5, 1.
`
`2
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`After institution, Patent Owner filed a statutory disclaimer under
`35 U.S.C. § 253(a) of claims 1, 2, 4–8, 14–16, 25–28, and 34–36 of the ’593
`patent. Ex. 2006; see also Paper 29 (Updated Mandatory Notice); accord
`Paper 32, 4 (determining that the identified claims have been disclaimed).
`This disclaimer effectively eliminates these claims from the ’593 patent,
`leaving the patent as if those claims never existed. See Sanofi-Aventis U.S.,
`LLC v. Dr. Reddy’s Labs., Inc., 933 F.3d 1367, 1373 (Fed. Cir. 2019). As a
`result, we determine (and the parties agree) that claims 1, 2, 4–8, 14–16, 25–
`28, and 34–36 are no longer part of this proceeding. See PO Resp. 11–12;
`Pet. Reply 1.
`Meanwhile, Splunk Inc. 4 filed a petition for inter partes review and a
`motion for joinder in IPR2022-00228, requesting that Splunk be joined as a
`petitioner in this proceeding. Paper 32 (Joinder Order), 1. After considering
`the parties’ papers, we instituted trial in IPR2022-00228, granted Splunk’s
`motion, and added Splunk as a petitioner to this proceeding. Id. at 5–8. As
`a result, this Decision uses “Petitioner” to refer to Cloudflare and Splunk.
`During the trial, Patent Owner filed a Response (Paper 30, “PO
`Resp.”), Petitioner filed a Reply (Paper 33, “Pet. Reply”), and Patent Owner
`filed a Sur-reply (Paper 36, “PO Sur-reply”).
`An oral hearing in this proceeding was held on September 7, 2022,
`and a transcript of the hearing is included in the record. Paper 41 (“Tr.”).
`Petitioner objects to Patent Owner’s demonstratives (Paper 40), and for the
`reasons explained below, that objection is dismissed as moot.
`
`
`4 Splunk also identifies Critical Start Inc. as a real party in interest.
`IPR2022-00228, Paper 2 (Petition), 76.
`
`3
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`B. Related Matters
`The parties indicate that the ’593 patent has been asserted in several
`district court lawsuits, including Sable Networks, Inc. v. Splunk Inc., 5:21-
`cv-00040 (E.D. Tex.), Sable Networks, Inc. v. Cloudflare, Inc., 6:21-cv-
`00261 (W.D. Tex.), Sable Networks, Inc. v. SonicWall Inc., 6:21-cv-00190
`(W.D. Tex.). Pet. xii–xiii; Paper 5, 1–3.
`
`C. Non-Disclaimed Challenged Claims
`Claims 3, 9–13, 17–24, 29–33, and 37–44 are the claims currently
`challenged in this proceeding. 5 Of these, claims 3, 9, and 29 are
`independent. Claim 9 is illustrative of the claimed subject matter:
`9. A machine implemented method for processing a
`flow, the flow comprising a series of information packets, the
`method comprising:
`maintaining a set of behavioral statistics for the flow,
`wherein the set of behavioral statistics is updated based on each
`information packet belonging to the flow, as each information
`packet belonging to the flow is processed, regardless of the
`presence or absence of congestion; and
`computing, based at least partially upon the set of
`behavioral statistics, a badness factor for the flow, wherein the
`badness factor provides an indication of whether the flow is
`exhibiting undesirable behavior.
`Ex. 1001, 11:63–12:8.
`
`
`5 The Petition challenged all 44 claims of the ’593 patent (see Pet.);
`however, during the trial, Patent Owner filed a statutory disclaimer
`(Ex. 2006), which eliminated claims 1, 2, 4–8, 14–16, 25–28, and 34–36
`from the scope of this proceeding (see supra § I.A),
`
`4
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`D. The Grounds
`Petitioner asserts the following challenges to the patentability of
`claims 3, 9–13, 17–24, 29–33, and 37–44 (Pet. 1; see also infra § II.F):
`
`35 U.S.C. §
`Claim(s) Challenged
`103(a)6
`17, 18, 37, 38
`9–13, 19–24, 29–33, 39–44 103(a)
`
`Reference(s)/Basis
`Yung7
`Yung, Copeland8
`
`3
`
`103(a)
`
`Yung, Four-Steps Whitepaper9
`
`E. Summary of the ’593 Patent
`The ’593 patent is titled “Mechanism for Identifying and Penalizing
`Misbehaving Flows in a Network,” and the application that led to this patent
`was filed on December 22, 2004. Ex. 1001, codes (54), (22).
`The Specification begins by explaining that “peer-to-peer (P2P) traffic
`on the Internet has grown immensely in recent years . . . despite the fact that
`the number of P2P users is quite small.” Ex. 1001, 1:7–13. As a result, this
`traffic uses a disproportionate amount of bandwidth, so it is viewed by
`Internet service providers as “abusive/misbehaving traffic that should be
`controlled and penalized.” Id. at 1:14–18. Previously, P2P traffic could be
`
`
`6 The Leahy-Smith America Invents Act (“AIA”), Pub. L. No. 112-29, 125
`Stat. 284, 285–88 (2011), revised 35 U.S.C. § 103 effective March 16, 2013.
`Because the challenged patent was filed before March 16, 2013, we refer to
`the pre-AIA version of § 103.
`7 US 7,664,048 B1, filed Nov. 24, 2003, issued Feb. 16, 2010 (Ex. 1005).
`8 US 7,185,368 B2, filed Nov. 30, 2001, issued Feb. 27, 2007 (Ex. 1007).
`9 “Four Steps to Application Performance Across the Network with
`Packeteer’s PacketShaper®,” retrieved from https://web.archive.org/web/
`20030317051910/http:/packeteer.com/PDF_files/4steps.pdf (Ex. 1006).
`
`5
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`identified by port numbers or signatures, but the ’593 patent explains that
`protocols evolved to evade these identification techniques. Id. at 1:19–45.
`The ’593 patent addresses this problem by identifying P2P traffic (and
`other “misbehaving information packet flows”10) using its “observed
`behavior,” which “cannot be hidden.” Ex. 1001, 1:46–67. Specifically, the
`Specification describes a method that: (1) maintains “behavioral statistics”
`for a flow, (2) determines whether the flow is “exhibiting undesirable
`behavior” based on the statistics, and (3) if so, enforces a penalty on the
`flow. Id. at 2:1–51; see also id. at Fig. 3. The “behavioral statistics” of a
`flow include, for example:
`a total byte count (sum of all of the bytes in all of the packets of
`the flow that have been processed up to the current time), a life
`duration (how long the flow has been in existence since
`inception), a flow rate (derived by dividing the total byte count
`by the life duration of the flow), and an average packet size
`(derived by dividing the total byte count by the total number of
`packets in the flow that have been processed).
`Id. at 2:6–13; see id. at Fig. 4, 7:20–29 (describing example flow block
`storing behavioral statistics). The method may involve computing a
`“badness factor,” which “provides an indication as to whether the flow is
`exhibiting undesirable behavior” and may also indicate “the degree to which
`the flow is misbehaving.” Id. at 2:20–26; see id. at 7:54–65 (exemplary
`badness factor calculation). The penalty that is enforced on the flow may be
`“an increased drop rate,” which may have the effect of correcting the flow’s
`
`
`10 “For purposes of the present invention, a flow is a series of packets that
`are related in some manner.” Ex. 1001, 5:16–17. The header of a packet is
`used to associate it with a particular flow. Id. at 5:17–24; see id. at 7:3–13.
`
`6
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`behavior. Id. at 2:27–51; see id. at 9:52–10:3 (explaining how dropping a
`packet can correct a flow’s behavior).
`
`II. ANALYSIS OF PATENTABILITY
`A. Legal Standards
`In an inter partes review, the petitioner has the burden of proving
`unpatentability by a preponderance of the evidence. 35 U.S.C. § 316(e).
`That burden never shifts to the patentee. Dynamic Drinkware, LLC v. Nat’l
`Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015).
`A patent claim is unpatentable under 35 U.S.C. § 103(a) if the
`differences between the claimed subject matter 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). The legal 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 obviousness or nonobviousness. 11 Graham v. John
`Deere Co. of Kansas City, 383 U.S. 1, 17–18 (1966). One seeking to
`establish obviousness based on more than one reference also must articulate
`sufficient reasoning with rational underpinnings to combine teachings. See
`KSR, 550 U.S. at 418.
`
`
`11 The record does not include allegations or evidence of objective indicia of
`obviousness or nonobviousness.
`
`7
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`B. The Level of Ordinary Skill in the Art
`Our reviewing court has explained that “the level of skill in the art is a
`prism or lens through which a judge, jury, or the Board views the prior art
`and the claimed invention.” Okajima v. Bourdeau, 261 F.3d 1350, 1355
`(Fed. Cir. 2001) (citing Al-Site Corp. v. VSI International, Inc., 174 F.3d
`1308, 1324, (Fed. Cir. 1999)). “This reference point prevents these
`factfinders from using their own insight or, worse yet, hindsight, to gauge
`obviousness.” Id.
`Petitioner asserts that the level of ordinary skill in the art corresponds
`to “an undergraduate degree (or equivalent) in electrical engineering,
`computer science, or comparable subject” and “3–5 years of academic or
`industry experience in computer networking or comparable industry
`experience.” Pet. 11 (citing Ex. 1003 ¶ 27). In the Institution Decision, we
`adopted this articulation of the level of ordinary skill. Inst. Dec. 15. At trial,
`neither party disputed our preliminary finding. See PO Resp.; Pet. Reply.
`We remain persuaded that this articulation of the level of skill in the
`art is supported by the ’593 patent, the asserted prior art, and Dr. Jeffay’s
`testimony. See Inst. Dec. 15 (citing Ex. 1003 ¶ 27). Accordingly, we
`determine that the level of ordinary skill in the art corresponds to an
`undergraduate degree (or equivalent) in electrical engineering, computer
`science, or comparable subject and 3–5 years of academic or industry
`experience in computer networking or comparable industry experience.
`
`C. Claim Construction
`We interpret claim terms using “the same claim construction standard
`that would be used to construe the claim in a civil action under 35 U.S.C.
`282(b).” 37 C.F.R. § 42.100(b) (2019). Under the principles set forth by
`
`8
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`our reviewing court, the “words of a claim ‘are generally given their
`ordinary and customary meaning,’” as would be understood by a person of
`ordinary skill in the art in question at the time of the invention. Phillips v.
`AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc) (quoting
`Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)).
`
`1. Means-plus-function limitations
`Petitioner contends the challenged claims include means-plus-function
`limitations that should be interpreted under 35 U.S.C. § 112 ¶ 6, and for
`each, Petitioner identifies a construction for use in this proceeding. Pet. 11–
`14. 12 Petitioner submits that no other terms require construction for
`purposes of this proceeding. Id. at 12.
`In the Institution Decision, we agreed with Petitioner that the
`identified limitations are means-plus-function limitations. Inst. Dec. 16
`(citing Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1349 (Fed. Cir.
`2015) (en banc) (holding that “use of the word ‘means’ creates a
`presumption that § 112, ¶ 6 applies”)). We also stated that we were
`persuaded that Petitioner had correctly identified the recited functions and
`the components in the Specification that perform those functions. Id. at 16–
`17. As a result, we preliminarily adopted the following constructions:
`Limitation
`Function
`Structure
`“means for maintaining a set
`maintaining a set of
`MFM 210
`of behavioral statistics for the
`behavioral statistics
`implemented on
`flow…” (claim 29)
`for the flow
`processors
`
`12 The Petition also contends that claims 25 and 27 include means-plus-
`function limitations that should be interpreted under 35 U.S.C. § 112 ¶ 6
`(Pet. 11–14); however, those claims have been disclaimed and are no longer
`part of this proceeding, so we do not address those limitations here.
`
`9
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`
`Limitation
`“means for computing…a
`badness factor for the flow”
`(claim 29)
`“means for determining…a
`penalty to impose on the
`flow” (claim 31)
`“means for
`enforcing…[a/the] penalty on
`the flow” (claim 32)
`“means for determining an
`increased drop rate to impose
`on one or more information
`packets belonging to the
`flow” (claim 37)
`
`“means for imposing [an/the]
`increased drop rate on the
`flow” (claim 38)
`“means for receiving a
`particular information packet
`belonging to the flow”
`(claims 43 and 44)
`“means for determining
`whether to forward the
`particular information packet
`to a destination” (claim 43)
`“means for updating […] the
`set of behavioral statistics to
`reflect processing of the
`particular information
`packet” (claims 43 and 44)
`Id. at 17–18.
`
`Function
`computing a badness
`factor for a flow
`
`determining a penalty
`to impose on a flow
`
`enforcing a penalty on
`the flow
`
`determining an
`increased drop rate to
`impose on one or
`more information
`packets belonging to a
`flow
`imposing an increased
`drop rate on a flow
`
`receiving a particular
`information packet
`belonging to a flow
`
`determining whether
`to forward a particular
`information packet to
`a destination
`updating the set of
`behavioral statistics to
`reflect processing of
`the particular
`information packet
`
`Structure
`MFM 210
`implemented on
`processors
`MFM 210
`implemented on
`processors
`MFM 210
`implemented on
`processors
`MFM 210
`implemented on
`processors
`
`MFM 210
`implemented on
`processors
`MFM 210
`implemented on
`processors
`
`MFM 210
`implemented on
`processors
`
`MFM 210
`implemented on
`processors
`
`10
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`
`At trial, neither party disputes any of our preliminary claim
`constructions. See PO Resp.; Pet. Reply; see also Inst. Dec. 18 (instructing
`the parties to “directly address any claim construction adopted in [the
`Institution Decision] if the party contends we should not adopt that
`construction in the final written decision”). Accordingly, for the reasons
`explained above and in the Institution Decision, we adopt these undisputed
`constructions for purposes of this Decision.
`
`2. “a badness factor for the flow”
`Patent Owner contends that claims 9 and 29 both “recite computing a
`‘badness factor’ for each flow.” PO Resp. 23. According to Patent Owner,
`these claims should be construed to include this requirement because the
`Specification only describes embodiments that compute a badness factor
`“for each flow regardless of whether the flow is misbehaving.” PO Resp. 23
`(citing Ex. 1001, 6:25–31, 7:51–52, 8:12–17); see also PO Sur-reply 17–18
`(arguing “there is not a single embodiment hinting that the badness factor is
`computed for only some flows”).
`However, as we previously explained, Patent Owner’s argument is not
`commensurate with language of the claim:
`In particular, claim 9 recites a method for processing a flow that
`includes computing a badness factor for the flow. Ex. 1001,
`11:63–8. Patent Owner identifies (and we perceive) no
`limitation that requires a badness factor to be computed for
`each flow.
`Inst. Dec. 44 (addressing substantially similar argument presented in
`preliminary response); see also Ex. 1001, 13:32–44 (claim 29). During trial,
`Patent Owner neither responds to this analysis nor points to a claim
`limitation that allegedly includes this requirement.
`
`11
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`Instead, Patent Owner points to the Specification, but this also fails to
`support Patent Owner’s contention. Although claims are read in view of the
`Specification (Phillips, 415 F.3d at 1315), they are not limited to the
`embodiments disclosed in it (id. at 1323). Patent Owner identifies (and we
`perceive) no passage in the Specification that could be read as redefining
`this claim phrase or disavowing part of its scope. See Thorner v. Sony
`Computer Ent. Am. LLC, 669 F.3d 1362, 1365, 1367 (Fed. Cir. 2012). In
`fact, the passages cited by Patent Owner are directed to the handling of a
`single flow, and none expressly indicates that an identical method must be
`used for each flow processed. See Ex. 1001, 6:25–31, 7:51–52, 8:12–17.
`Thus, we determine that the Specification does not justify importing the
`limitation proposed by Patent Owner into the claims.
`Accordingly, having reviewed the intrinsic record, we disagree with
`Patent Owner’s contention that claims 9 and 29 require computing a badness
`factor for each flow or all flows; rather, this claim limitation may be
`satisfied by computing a badness factor for a single flow.
`
`3. Other constructions
`The parties do not propose constructions for any other terms or
`phrases. See Pet. 11–14; PO Resp. Based on the record before us, we do not
`find it necessary to provide express claim constructions for any other terms
`or phrases. See Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co.,
`868 F.3d 1013, 1017 (Fed. Cir. 2017) (noting that “we need only construe
`terms ‘that are in controversy, and only to the extent necessary to resolve the
`controversy’” (quoting Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d
`795, 803 (Fed. Cir. 1999))).
`
`12
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`D. Summary of Asserted Prior Art References
`1. Yung (Ex. 1005)
`Yung is titled “Heuristic Behavior Pattern Matching of Data Flows in
`Enhanced Network Traffic Classification.” Ex. 1005.
`Yung classifies data flows by comparing them to “known application
`behavior patterns.” Ex. 1005, Abstract. According to Yung, its technique
`allows for classification of encrypted, compressed, or proprietary network
`traffic. Id. at 5:43–6:1; see id. at 4:43–60 (noting that peer-to-peer
`applications employ encryption and compression to obscure identification).
`For each flow, Yung stores a data block object (also called a flow object)
`that includes “various attributes of the flow,” such as “packet count, byte
`count, first packet time, last packet time, etc.” Id. at 8:5–11, 17:42–52,
`25:8–11. Yung uses the data block object to classify the data flow. E.g., id.
`at 24:13–18, 24:27–51. Yung may also enforce bandwidth utilization
`controls on the flow, such as a discard policy that causes packets to be
`dropped. E.g., id. at 19:53–58, 20:13–15, 24:63–25:1.
`Figure 3 (reproduced below) is a block diagram of an exemplary
`bandwidth management device 130 that implements Yung’s techniques.
`Ex. 1005, 6:21–23, 16:8–10.
`
`13
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`
`
`Figure 3 (above) shows bandwidth management device 130 that includes
`packet processor 131, flow control module 132, and traffic classification
`engine 137. Yung explains that packet processor 131 detects new data flows
`and “construct[s] data structures including attributes characterizing the data
`flow.” Id. at 16:15–17, 17:42–49. Flow control module 132 “enforce[s]
`bandwidth utilization controls on data flows traversing bandwidth
`management device 130.” Id. at 16:17–19. Traffic classification engine 137
`“analyze[s] data flow attributes and identif[ies] traffic classes corresponding
`to the data flows.” Id. at 16:20–22.
`Figure 7 (reproduced below) includes a flow chart of an exemplary
`method of bandwidth management device 130. Ex. 1005, 23:16–20.
`
`14
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`
`
`As shown above, in Figure 7, packet processor 131 receives a data packet
`(step 202), determines whether a control block object already exists
`corresponding to the data flow (step 204), and if not, constructs a control
`block object for the flow (step 212). Id. at 23:23–30, Fig. 7. A traffic class
`may be identified (step 214), and ultimately, the packet is passed to flow
`
`15
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`control module, which enforces appropriate bandwidth utilization controls
`on the data packet (step 222). Id. at 24:13–18, 24:63–25:1, Fig. 7. Finally,
`“packet processor 131 also records or updates various measurement values
`in the control block object that characterize the flow (e.g., last packet time,
`packet count, byte count, etc.)” (step 224). Id. at 25:8–11, Fig. 7.
`
`2. Copeland (Ex. 1007)
`Copeland describes a “system for detecting intrusions in computer
`communication networks” by collecting and analyzing statistics for flows
`traversing the network. Ex. 1007, Abstract, 3:18–35. If a flow appears
`suspicious, Copeland assigns a “concern index value” to the flow. Id. at
`Abstr., 3:32–35.
`In particular, Copeland collects “information about and statistics
`associated with each flow” and stores this data in a flow data structure
`corresponding to that flow. Ex. 1007, 7:38–45, 16:12–30. The flow data
`structure includes, for example, the number of bytes, the number of packets,
`and time information (such as the time of the first packet and time of the last
`packet). Id. at 7:49–54, 16:37. Copeland analyzes the data to determine if
`the flow appears to be legitimate traffic or possible suspicious activity. Id. at
`7:55–57. If a flow appears suspicious, Copeland assigns a concern index
`(CI) value that “[has] been derived heuristically from extensive network
`traffic analysis.” Id. at 7:57–62. In Figure 6, Copeland provides a table with
`an exemplary set of concern index values for various events. Id. at 7:64–67,
`18:19–20. Petitioner annotates this table to show that Copeland describes
`using the number of packets as a concern index value. Pet. 51. Petitioner’s
`annotation is reproduced below.
`
`16
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`
`
`
`Copeland’s Figure 6 illustrates concern index values for client/server flows.
`Ex. 1007, 4:8–9. As shown above, Petitioner annotates the first row of the
`table in Figure 6: in the “NAME” column, Petitioner places a red box
`around the first entry, which states “POTENTIAL TCP PROBE,” and
`Petitioner places a green box in the same row of the “CI VALUE” column,
`where the entry states “NUMBER OF PACKETS.”
`
`3. Four-Steps Whitepaper (Ex. 1006)
`The Four-Steps Whitepaper is a technical product overview for the
`PacketShaper® product line from Packeteer, Inc. Ex. 1006, 1. This
`document describes a bandwidth-management strategy that: (1) classifies
`network traffic; (2) analyzes traffic; (3) controls traffic; and (4) reports
`results. Id. at 2. In the second step, PacketShaper collects measurements
`regarding traffic flows, including “[t]hroughput in units of bytes, packets,
`transactions, connections,” “[c]ounts and percentages of retransmitted,
`received, tossed, dropped, and good TCP packets,” and “[c]ounts and
`percentages of TCP connections that were denied by a policy.” Id. at 18.
`
`17
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`E. Obviousness Ground Based on Yung and Copeland
`Petitioner contends that the subject matter of claims 9–13, 19–24, 29–
`33, and 39–44 would have been obvious over the combination of Yung and
`Copeland. Pet. 43–61.
`Patent Owner argues that Petitioner fails to show a “badness factor”
`for each flow, which Patent Owner contends is required by the independent
`claims (PO Resp. 16–24), and fails to articulate a sufficient rationale to
`combine Yung and Copeland (id. at 24–28). 13
`
`1. Independent claim 9
`“A machine implemented method for processing a flow, the
`flow comprising a series of information packets, the method
`comprising . . . .”
`Petitioner contends that Yung discloses the preamble of claim 9.
`Pet. 48 (citing id. at 19–21 (discussing preamble of claim 1)). In particular,
`Petitioner points to Figure 7 of Yung, which depicts a “method directed to
`enforcing bandwidth utilization controls on data flows.” Id. at 19 (quoting
`Ex. 1005, 6:35–36). Petitioner contends that this method processes a flow,
`such as TCP/IP network data traffic, which is composed of a plurality of
`packets. Id. at 19–20 (citing Ex. 1005, 2:58–61, 8:3–5, 11:60–62, 12:30–35,
`24:13–18, 24:63–25:1, Fig. 7; Ex. 1003 ¶ 120). Petitioner further contends
`
`
`13 Patent Owner has forfeited any arguments for patentability not raised in
`Patent Owner Response (Paper 30), even if the argument was raised in the
`Preliminary Response (Paper 8). Paper 17 (Scheduling Order), 8 (cautioning
`Patent Owner that “any arguments not raised in the response may be deemed
`waived”); see also In re NuVasive, Inc., 842 F.3d 1376, 1379–82 (Fed. Cir.
`2016) (holding patent owner waived an argument addressed in the
`preliminary response by not raising it in the patent owner response).
`
`18
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`that the method is implemented by a machine (e.g., a bandwidth
`management device or a gateway). Id. at 21 (citing Ex. 1005, 6:8–11, 7:12–
`18, 15:44–47, Fig. 2).
`Patent Owner does not dispute these contentions. See PO Resp.
`We are persuaded that Yung discloses the preamble of this claim. 14
`Yung describes a method for processing a flow that includes a series of data
`packets. E.g., Ex. 1005, Abstr., 12:30–35, 24:13–18, Fig. 7; see also id. at
`2:58–61.
`
`“maintaining a set of behavioral statistics for the flow, wherein
`the set of behavioral statistics is updated based on each
`information packet belonging to the flow, as each information
`packet belonging to the flow is processed, regardless of the
`presence or absence of congestion”
`Petitioner contends that Yung discloses this limitation. Pet. 48 (citing
`id. at 21–30 (discussing limitations in claim 1); Ex. 1003 ¶ 207). In
`particular, Petitioner asserts that “Yung tracks ‘various measurement values
`in [a] control block object that characterize the flow (e.g., last packet time,
`packet count, byte count, etc.),’” and Petitioner maps these values to the
`claimed “behavioral statistics for the flow.” Id. at 25–26 (quoting Ex. 1005,
`25:8–11; citing id. at 8:5–11, 9:5–8, 11:36–38, 12:4–6, 17:42–49, 25:8–11).
`Petitioner also asserts that Yung’s packet processor 131 receives a data
`packet, passes it to the flow control module, and then updates the control
`block object’s measurement values. Id. at 28–29 (quoting Ex. 1005, 25:8–
`11; citing id. at 25:11–15, Fig. 7 (steps 202, 222, 224)); see id. at 21–23
`
`
`14 Because Petitioner has shown that the recitations in the preamble are
`satisfied by Yung, we need not determine whether the preamble is limiting.
`See Nidec Motor, 868 F.3d at 1017.
`
`19
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`(addressing creation of the control block object). Petitioner further asserts
`that Yung updates statistics for “each packet” because Yung provides
`aggregate statistics for the flow, such as total byte count and total packet
`count. Id. at 29 (citing Ex. 1003 ¶¶ 151–152; Ex. 1005, 25:11–15).
`Moreover, according to Petitioner, Yung continuously tracks these statistics,
`regardless of the presence of absence of congestion, and in any event, it
`would have been obvious to do so to allow for traffic classification in all
`situations. Id. at 27 (citing Ex. 1005, Abstr., 9:21–25, 25:11–15, Fig. 7;
`Ex. 1003 ¶¶ 147–148); see also id. at 30.
`Patent Owner does not dispute these contentions. See PO Resp.
`We are persuaded that Yung discloses this limitation. Yung’s packet
`processor 131 receives a data packet, identifies (or constructs) a
`corresponding control block object, and passes the packet to a rate control
`module that enforces bandwidth utilization controls on the data packet flow.
`Ex. 1005, 23:23–30, 24:11–13, 24:63–25:1, Fig. 7. Packet processor 131
`then “records or updates various measurement values in the control block
`object that characterize the flow (e.g., last packet time, packet count, byte
`count, etc.).” Id. at 25:8–11, Fig. 7 (step 224). We are persuaded that an
`ordinary artisan would have understood Yung to update these values for
`“each” packet “regardless of the presence or absence of congestion,” as
`required by the claim. See Ex. 1003 ¶¶ 147–148, 151–153; see also id.
`¶ 207. In particular, Dr. Jeffay testifies that “Yung would not be able to
`leverage/provide the aggregate statistics (e.g., total byte count, total packet
`count) if the statistics were not updated as each packet belonging to said
`flow is processed” or were stored “only when congestion arises.” Id. ¶¶ 148,
`
`20
`
`

`

`IPR2021-00909
`Patent 8,243,593 B2
`151 (emphasis omitted). We credit Dr. Jeffay’s testimony on this point
`because he provides a logical explanation that is supported by the reference.
`
`“computing, based at least partially upon the set of behavioral
`statistics, a badness factor for the flow, wherein the badness
`factor provides an indication of whether the flow is exhibiting
`undesirable behavior”
`Petitioner contends that Copeland discloses this limitation. Pet. 49–
`51. Specifically, Petitioner points to Copeland’s “concern index” (CI)—a
`value assigned to a flow that appears to be suspicious—as the claimed
`“badness factor.” Id. at 49 (citing Ex. 1007, 3:31–35, 18:15–19, 26:22–27).
`Petitioner asserts that “Copeland’s CI value indicates whether the flow
`exhibits ‘suspicious activity,’” which is undesirable behavior. Id. at 49–50
`(quoting Ex. 1007, 7:55–61; citing id. at 18:4–13; Ex. 1003 ¶ 212).
`Petitioner further asserts that Copeland computes the CI value based on
`statistics associated with a flow, noting that the CI value may be set to the
`number of packets, for example, as shown by the first row of Table I in
`Figure 6. Id. at 50 (citing Ex. 10

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket