Centripetal Networks, Inc. v. Cisco Systems, Inc.

CourtCourt of Appeals for the Federal Circuit
DecidedMarch 10, 2021
Docket20-2057
StatusUnpublished

This text of Centripetal Networks, Inc. v. Cisco Systems, Inc. (Centripetal Networks, Inc. v. Cisco Systems, Inc.) is published on Counsel Stack Legal Research, covering Court of Appeals for the Federal Circuit primary law. Counsel Stack provides free access to over 12 million legal documents including statutes, case law, regulations, and constitutions.

Bluebook
Centripetal Networks, Inc. v. Cisco Systems, Inc., (Fed. Cir. 2021).

Opinion

Case: 20-2057 Document: 34 Page: 1 Filed: 03/10/2021

NOTE: This disposition is nonprecedential.

United States Court of Appeals for the Federal Circuit ______________________

CENTRIPETAL NETWORKS, INC., Appellant

v.

CISCO SYSTEMS, INC., Appellee ______________________

2020-2057 ______________________

Appeal from the United States Patent and Trademark Office, Patent Trial and Appeal Board in No. IPR2018- 01760. ______________________

Decided: March 10, 2021 ______________________

PAUL J. ANDRE, Kramer Levin Naftalis & Frankel LLP, Menlo Park, CA, for appellant. Also represented by JAMES R. HANNAH; CRISTINA MARTINEZ, JEFFREY PRICE, New York, NY.

PATRICK D. MCPHERSON, Duane Morris LLP, Washing- ton, DC, for appellee. Also represented by PATRICK C. MULDOON, CHRISTOPHER JOSEPH TYSON; MATTHEW CHRISTOPHER GAUDET, Atlanta, GA; JOSEPH POWERS, Phil- adelphia, PA. Case: 20-2057 Document: 34 Page: 2 Filed: 03/10/2021

______________________

Before MOORE, SCHALL, and TARANTO, Circuit Judges. TARANTO, Circuit Judge. Centripetal Networks, Inc. owns U.S. Patent No. 9,413,722, which addresses “rule-based network-threat de- tection.” ’722 patent, col. 1, lines 45–46. In September 2018, Cisco Systems, Inc. petitioned for an inter partes re- view of all claims of the ’722 patent, alleging that the claimed inventions in all claims (1–25) would have been ob- vious to a relevant artisan under 35 U.S.C. § 103 in view of a User Guide for the Sourcefire 3D System—a manual the parties have called “Sourcefire.” That reference is also be- fore us in Centripetal Networks, Inc. v. Cisco Systems, Inc., Fed. Cir. Nos. 20-1635, -1636, which involves other Cen- tripetal patents and which we decide today (20-1635 Deci- sion). A common issue in this matter and in our 20-1635 Decision is whether Sourcefire was a “printed publica- tion[]” under 35 U.S.C. § 311(b). A distinct issue here is whether Sourcefire teaches identifying “network-threat in- dicators” as required by the ’722 patent’s claims. The Patent Trial and Appeal Board instituted an inter partes review, and in May 2020, it ruled that Sourcefire was a printed publication and that the claimed inventions in claims 1–7, 10–12, 14–21, 24, and 25 in the ’722 patent would have been obvious to a relevant artisan in view of Sourcefire. Cisco Systems, Inc. v. Centripetal Networks, Inc., IPR2018-01760, 2020 WL 2549613 (P.T.A.B. May 18, 2020) (Board Decision). Centripetal appeals. We have ju- risdiction under 28 U.S.C. § 1295(a)(4). We affirm. I A Unauthorized requests for data and large volumes of network traffic are two examples of what the ’722 patent calls “network threats” to the Internet. See ’722 patent, col. Case: 20-2057 Document: 34 Page: 3 Filed: 03/10/2021

CENTRIPETAL NETWORKS, INC. v. CISCO SYSTEMS, INC. 3

1, lines 16–19. Information about such threats, the patent says, was traditionally compiled by an organization’s net- work devices into “logs,” which were then reviewed for “data corresponding to the network-threat indicators pro- vided by [network-threat] services.” Id., col. 1, lines 24–29. The patent asserts that because these logs were “generated based on the traffic processed by the network devices with- out regard to the network-threat indicators,” reviewing them was “time consuming” and “exacerbated by the con- tinuously evolving nature of potential threats.” Id., col. 1, lines 29–34. The ’722 patent proposes an improvement in the form of a “rule-based network-threat detection” system using a “packet-filtering device” that receives data packets travel- ing through the Internet and determines whether each packet “corresponds to criteria specified by a packet-filter- ing rule.” Id., col. 1, lines 45–52. The criteria in each rule may “correspond to one or more of the network-threat indi- cators.” Id., col. 1, lines 52–53. Network-threat indicators may include “network addresses, ports, fully qualified do- main names (FQDNs), uniform resource locators (URLs), [and] uniform resource identifiers (URIs)” that are “associ- ated with . . . network threats,” such as phishing malware. Id., col. 3, lines 18–33.

Packet-filtering rules also specify an “operator,” which is “configured to cause packet-filtering device 144 to either prevent packets corresponding to the criteria from contin- uing toward their respective destinations (e.g., a BLOCK operator) or allow packets corresponding to the criteria to continue toward their respective destinations (e.g., an ALLOW operator).” Id., col. 5, lines 13–24. In addition to allowing and blocking packets, the packet-filtering device “generate[s] a log entry comprising information from the packet-filtering rule,” including information about (1) whether the packets corresponded to “one or more network- threat indicators” and (2) whether the packet-filtering de- vice allowed the packet to continue or blocked it from Case: 20-2057 Document: 34 Page: 4 Filed: 03/10/2021

reaching its destination. Id., col. 16, lines 8–19. The packet-filtering device communicates such information to a “user device,” id., col. 16, lines 22–24, which permits a user to alter the rules based on the log information by “in- struct[ing] the packet-filtering device to reconfigure the op- erator” so that, for example, the operator “prevent[s] future packets corresponding to the criteria from continuing to- ward their respective destinations,” id., col. 2, lines 1–10. See also id., Fig. 7 (depicting an example of the rules-based network-threat detection system). Claim 1 is representative and recites: 1. A method comprising: receiving, by a packet-filtering device, a plurality of packet-filtering rules configured to cause the packet-filtering device to identify packets corre- sponding to at least one of a plurality of network- threat indicators; receiving, by the packet-filtering device, a plurality of packets, wherein the plurality of packets com- prises a first packet and a second packet; responsive to a determination by the packet-filter- ing device that the first packet satisfies one or more criteria, specified by a packet-filtering rule of the plurality of packet-filtering rules, that correspond to one or more network-threat indicators of the plu- rality of network-threat indicators: applying, by the packet-filtering device and to the first packet, an operator specified by the packet-filtering rule and configured to cause the packet-filtering device to allow the first packet to continue toward a desti- nation of the first packet; communicating, by the packet-filtering de- vice, information from the packet-filtering Case: 20-2057 Document: 34 Page: 5 Filed: 03/10/2021

CENTRIPETAL NETWORKS, INC. v. CISCO SYSTEMS, INC. 5

Free access — add to your briefcase to read the full text and ask questions with AI

Related

Cite This Page — Counsel Stack

Bluebook (online)
Centripetal Networks, Inc. v. Cisco Systems, Inc., Counsel Stack Legal Research, https://law.counselstack.com/opinion/centripetal-networks-inc-v-cisco-systems-inc-cafc-2021.