`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`___________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`___________
`
`CLOUDFLARE, INC. and
`SPLUNK INC.,
`Petitioners,
`
`v.
`
`SABLE NETWORKS, INC.
`Patent Owner.
`
`___________
`
`IPR2021-009091
`Patent 8,243,593 B2
`___________
`
`PETITIONER’S NOTICE OF APPEAL
`
`via P-TACTS
`Patent Trial and Appeal Board
`
`via FedEx
`Director of the United States Patent and Trademark Office
`
`via CM/ECF
`United States Court of Appeals for the Federal Circuit
`
`1 Splunk, Inc., which filed a petition in IPR2022-00228, has been joined as a
`petitioner in this proceeding.
`
`
`
`
`
`Case IPR2021-00909
`U.S. Pat. No. 8,243,593
`Petitioner Cloudflare, Inc. (“Petitioner”) hereby provides notice of appeal to
`
`the United States Court of Appeals for the Federal Circuit pursuant to 35 U.S.C.
`
`§§ 141, 142, and 391 and 37 C.F.R. §§ 90.2 and 90.3 from the Final Written
`
`Decision of the Patent Trial and Appeal Board on October 18, 2022 (Paper 42), the
`
`Decision Denying Petitioner’s Request on Rehearing of Final Written Decision on
`
`January 9, 2023 (Paper 46), and from all underlying orders, decisions, rulings, and
`
`opinions in IPR2021-00909. This notice is timely filed within 63 days of action on
`
`the request for rehearing. 37 C.F.R. § 90.3(b)(1).
`
`Copies of the Final Written Decision and the Decision Denying Petitioner’s
`
`Request for Rehearing are attached.
`
`In accordance with 37 C.F.R. § 90.2(a)(3)(ii), Petitioner states that the
`
`anticipated issues on appeal include at least: (i) Whether the Board erred in
`
`declining to consider whether dependent claims 17, 18, 37, and 38 of U.S. Patent
`
`No. 8,243,593 are unpatentable as obvious based on the combination of U.S. Patent
`
`No. 7,664,048 to Yung and U.S. Patent No. 7,185,368 to Copeland; and (ii)
`
`whether the Board erred in determining that Petitioner had not shown that claims
`
`17, 18, 37 or 38 would have been obvious; and (iii) any finding or determination
`
`supporting or related to the aforementioned issues, including claim constructions,
`
`as well as all other issues decided adversely to Petitioner in any order, decision,
`
`ruling, phone conference decision, and/or opinion, including without limitation the
`
`
`
`
`
`
`
`Board’s refusal to permit Petitioner to file a motion to correct the petition.
`
`Along with this submission, Petitioner is filing a true and correct copy of
`
`this Notice of Appeal with the Director of the United States Patent and Trademark
`
`Office and a true and correct copy of the same, along with the required docketing
`
`fee, with the Clerk of the United States Court of Appeals for the Federal Circuit as
`
`set forth in the accompanying Certificate of Service and Filing.
`
`Dated: March 10, 2023
`
`Respectfully submitted,
`
`
`
`
`
` /Daniel Callaway/
`Daniel Callaway
`Registration No. 74,267
`Attorney for Petitioner Cloudflare, Inc.
`
`
`
`
`
`
`
`
`
`
`
`
`CERTIFICATE OF SERVICE AND FILING
`
`I hereby certify that on March 10, 2023, in addition to being filed
`
`electronically through P-TACTS, a true and correct copy of the foregoing Notice
`
`of Appeal is being filed by FedEx with the Director of the United States Patent and
`
`Trademark Office at the following address:
`
`Director of the United States Patent and Trademark Office
`c/o Office of the General Counsel
`Madison Building East, 10B20
`600 Dulany Street
`Alexandria, VA 22314-5793
`
`
`In addition, I hereby certify that on March 10, 2023, the foregoing Notice of
`
`Appeal is being filed via CM/ECF with the Clerk’s Office of the United States
`
`Court of Appeals for the Federal Circuit.
`
`In addition, I hereby certify that on March 10, 2023, the foregoing Notice of
`
`Appeal was served on Patent Owner’s counsel of record via email, pursuant to
`
`agreement between the parties to be served by electronic means, to the following
`
`addresses:
`
`
`
`weatherwax@lowensteinweatherwax.com
`Sable_IPRs@lowensteinweatherwax.com
`
`
` /Daniel Callaway/
`Daniel Callaway
`Registration No. 74,267
`Farella Braun + Martel LLP
`235 Montgomery Street; 17th Floor
`San Francisco, CA 94104
`
`
`
`ATTACHMENTS
`ATTACHMENTS
`
`
`
`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 o