Palo Alto Networks Inc v. Centripetal Networks Inc

1. Case Identification

• Case #: IPR2021-01156
• Patent #: 10,735,380
• Filed: July 19, 2021
• Petitioner(s): Palo Alto Networks, Inc.
• Patent Owner(s): Centripetal Networks, Inc.
• Challenged Claims: 1, 6-10, 15-21, 24-25, and 29-30

2. Patent Overview

• Title: Systems and Methods for Filtering Data Packets
• Brief Description: The ’380 patent discloses a two-stage filtering method for data packets leaving a protected network to prevent data exfiltration. A first stage filters packets based on header-field values (e.g., the 5-tuple), and a second, subsequent stage filters packets based on application-layer header criteria, such as specific HTTP methods, to identify and drop packets associated with exfiltration attempts.

3. Grounds for Unpatentability

Ground 1: Obviousness over Sourcefire - Claims 1, 6-10, 15-21, 24-25, and 29-30 are obvious over Sourcefire.

• Prior Art Relied Upon: Sourcefire (Sourcefire 3D System User Guide Version 4.10).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that the Sourcefire reference, a user manual for a network intrusion prevention system, teaches all limitations of the challenged claims. Sourcefire’s system uses a two-stage filtering process where intrusion rules have two logical parts: a "rule header" and "rule options." The rule header functions as the first filtering stage by evaluating packet header information, such as the 5-tuple (source/destination IP addresses, ports, protocol), to determine if a rule applies. If a packet matches the header criteria (e.g., is destined for a location outside the protected network), the system proceeds to the second stage, evaluating the "rule options." These options allow for inspection of application-layer data, such as HTTP methods (GET, PUT, POST) or SSL/TLS version information, which corresponds to the patent's second filtering stage. Sourcefire explicitly teaches that its system can be configured to "drop" packets that match these combined criteria, satisfying the "operator" limitation.
  • Motivation to Combine: Although based on a single reference, Petitioner argued a person of ordinary skill in the art (POSITA) would be motivated to configure the flexible rules taught by Sourcefire to implement the claimed two-stage filtering. Network exfiltration using protocols like HTTP was a known security concern. Sourcefire provides the tools and teaches writing custom rules to target specific traffic. Therefore, a POSITA would combine Sourcefire’s teachings on 5-tuple filtering (first stage) with its teachings on application-layer keyword inspection (second stage) to create a rule that identifies and blocks known exfiltration methods.
  • Expectation of Success: A POSITA would have had a high expectation of success because Sourcefire’s system was expressly designed to provide granular, rule-based packet inspection and filtering. Implementing a rule to block traffic based on a combination of destination IP address and a specific HTTP method was a straightforward application of the system's documented capabilities, providing the predictable benefit of enhanced network security.
  • Key Aspects: Petitioner’s argument heavily emphasized that claims of a related patent (the ’552 patent) were previously found unpatentable over the same Sourcefire reference in a prior IPR, a decision affirmed by the Federal Circuit. Petitioner argued Patent Owner was collaterally estopped from relitigating many of these issues.

4. Key Claim Construction Positions

• "operator": Petitioner argued this term has its plain and ordinary meaning, referring to a symbol or function that specifies an action to be performed on a packet, such as a "packet transformation function" (e.g., allow, block, or drop).
• "data transfer protocol": Petitioner proposed this term be construed to mean any protocol associated with data transfer, consistent with its usage in the claims and specification, to include protocols like HTTP, XMPP, and TLS.
• "data transfer request field": Petitioner contended this term should be construed to mean a field associated with a data transfer request, such as the HTTP method field, and is not limited to a specific field defined in the specification.

5. Arguments Regarding Discretionary Denial

• §314(a) (Fintiv): Petitioner argued against discretionary denial, asserting that the co-pending district court litigation was at a very early stage. At the time of filing, no trial date had been set, no scheduling conference had occurred, and Petitioner had filed a motion to stay the litigation pending the IPR. Petitioner also stressed the strong merits of the petition, citing the prior IPR decision against the related ’552 patent on the same art, which reduces the concern for inefficient parallel proceedings.
• §325(d): Petitioner argued that denial under §325(d) was inappropriate. While the Sourcefire reference was before the Examiner in an Information Disclosure Statement (IDS), it was never substantively discussed or applied in a rejection. Petitioner contended the Examiner materially erred by failing to appreciate Sourcefire’s teachings, especially given that the Board had already issued a Final Written Decision (FWD) finding similar claims in the parent ’552 patent unpatentable over Sourcefire at the time the ’380 patent was allowed.

6. Relief Requested

• Petitioner requests institution of an inter partes review and cancellation of claims 1, 6-10, 15-21, 24-25, and 29-30 of the ’380 patent as unpatentable.