Palo Alto Networks Inc v. Centripetal Networks LLC

1. Case Identification

• Case #: IPR2023-01353
• Patent #: 10,567,343
• Filed: September 5, 2023
• Petitioner(s): Palo Alto Networks, Inc.
• Patent Owner(s): Centripetal Networks, LLC
• Challenged Claims: 1-20

2. Patent Overview

• Title: Filtering Network Data Transfers
• Brief Description: The ’343 patent discloses a two-stage method for filtering network packets to prevent data exfiltration. The system first filters packets based on header field values (e.g., 5-tuple data) and then, for matching packets, inspects application header field values to apply a "packet transformation function" that either allows or blocks the packet.

3. Grounds for Unpatentability

Ground 1: Claims 1-20 are obvious over Sourcefire in view of Emerging Threats.

• Prior Art Relied Upon: Sourcefire (Sourcefire 3D System User Guide Version 4.10) and Emerging Threats (a 2010 publication of Snort rules).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Sourcefire, an Intrusion Protection System (IPS), discloses the foundational two-stage filtering system recited in the claims. Sourcefire’s system, which uses the industry-standard Snort rules engine, was capable of filtering packets based on a first criterion of 5-tuple header data (protocol, source/destination IPs, source/destination ports). Responsive to a match on this first criterion, the system could then inspect packet payloads for a second criterion corresponding to application-layer data, such as HTTP methods or SSL/TLS version information. The petition asserted that the key missing element from Sourcefire alone—a packet transformation function explicitly configured to "prevent an exfiltration operation," which was the basis for the patent's allowance—is supplied by Emerging Threats. Emerging Threats was a well-known public repository of Snort rules designed for use in systems like Sourcefire. It contained numerous rules specifically targeting data exfiltration. For example, rule SID:2003021 was designed to detect and block data exfiltration attempts using an outdated and insecure SSL v3.0 protocol on unusual ports. This rule first checks the 5-tuple data and then inspects the application header for the specific SSL version, which directly maps to the claimed two-stage process. Other cited rules from Emerging Threats were configured to block unauthorized transmission of password files or data sent via specific HTTP POST requests associated with malware.
  • Motivation to Combine: A Person of Ordinary Skill in the Art (POSITA) would be motivated to combine the references because Sourcefire was expressly designed to import and use third-party Snort rule sets to enhance its security capabilities. Emerging Threats was a leading, publicly available source of such rules, touted as a "de facto standard" for malware threat detection. The Sourcefire user guide provides explicit instructions for importing external rule files. A POSITA seeking to protect a network from a wide range of threats, including data exfiltration, would have naturally looked to a comprehensive rule set like Emerging Threats to implement in a compatible system like Sourcefire.
  • Expectation of Success: A POSITA would have a high expectation of success. The Emerging Threats rules were written in the Snort format, which is the native rules engine for the Sourcefire system. Sourcefire's user manual confirms the system's functionality for importing, enabling, and configuring external rules to either "alert" or "drop" (block) traffic. The combination represented the intended and ordinary use of both technologies.

4. Key Claim Construction Positions

• "operator": Petitioner argued that no express construction is required but provided a discussion due to the term's history in related litigation. Petitioner contended that in the context of the ’343 patent and computer science generally, an "operator" is a function that takes inputs (packets) and produces an output (a decision to allow or block). This function can be simple, applying a transformation like "ALLOW" based only on 5-tuple criteria, or more complex, such as the patent's "HTTP-EXFIL" operator, which inspects application header data (e.g., GET vs. POST methods) to determine the output. This interpretation aligns with Sourcefire's rules, where a rule header specifies the first criteria and the rule options specify the second, application-level criteria and the resulting action.

5. Arguments Regarding Discretionary Denial

• Petitioner argued that the Board should not exercise its discretion to deny institution under 35 U.S.C. §325(d). This petition was filed as a "copycat" of an already-instituted IPR (IPR2023-00446) and was accompanied by a motion for joinder. Petitioner contended that by agreeing to a passive role, the General Plastic factors are neutralized. Petitioner distinguished the case from the precedential Apple v. Uniloc II decision by asserting that at the time it filed its own earlier, unsuccessful IPR against the ’343 patent, it was unaware of the Emerging Threats reference, despite a diligent search. This new reference, which was not considered by the Examiner during prosecution, directly addresses the specific "exfiltration prevention" feature that was the basis for the patent's allowance, thus presenting a new issue for the Board's consideration.

6. Relief Requested

• Petitioner requests institution of an inter partes review and cancellation of claims 1-20 of the ’343 patent as unpatentable.