Cisco Systems Inc v. Centripetal Networks Inc

1. Case Identification

• Case #: IPR2018-01436
• Patent #: 9,124,552
• Filed: July 20, 2018
• Petitioner(s): Cisco Systems, Inc.
• Patent Owner(s): Centripetal Networks, Inc.
• Challenged Claims: 1-21

2. Patent Overview

• Title: Filtering Network Data Transfers
• Brief Description: The ’552 patent discloses systems and methods for filtering network data packets to prevent data exfiltration. The invention uses a two-stage filtering process, where a first stage filters packets based on "5-tuple" header information (e.g., IP addresses, ports), and a second stage applies rules based on application-layer header values, such as the specific version of an encryption protocol (e.g., TLS 1.1) or a specific HTTP method (e.g., GET, PUT).

3. Grounds for Unpatentability

Ground 1: Claims 1-21 are obvious over Sourcefire in view of the knowledge of a POSA.

• 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 an intrusion prevention system (IPS), disclosed the entire two-stage filtering process claimed in the ’552 patent. Sourcefire’s system used customizable intrusion rules that performed the same two-stage filtering.
    • The first stage, filtering based on the 5-tuple, was disclosed in Sourcefire’s "rule header," which defined the protocol, source/destination IP addresses, and ports for which a rule applies. This directly corresponded to the first-stage filtering of independent claim 1.
    • The second stage, filtering based on application-layer data, was disclosed in Sourcefire’s "rule options," which used keywords to inspect application payloads. Petitioner asserted that the critical limitation of filtering based on TLS version was explicitly taught by Sourcefire’s ssl_version keyword. A user could write a rule to block or allow packets based on specific SSL/TLS versions (e.g., tls1.0, sslv3). Similarly, dependent claims reciting filtering based on HTTP methods were taught by Sourcefire’s HTTP inspection keywords that could identify methods like GET and PUT.
  • Motivation to Combine (for §103 grounds): The petition asserted that a person of ordinary skill in the art (POSA) would have been motivated to use the features described in Sourcefire to achieve the claimed invention for predictable security benefits. By the patent’s priority date of March 2013, it was widely known that older encryption protocols like SSLv2, SSLv3, and TLS 1.0 had significant security vulnerabilities. A POSA would have been motivated to write a rule using Sourcefire’s ssl_version keyword to block traffic using these insecure protocols, thereby increasing network security. This was a straightforward application of a known tool (Sourcefire’s filtering rules) to solve a known problem (vulnerabilities in older TLS versions).
  • Expectation of Success (for §103 grounds): A POSA would have had a high expectation of success because Sourcefire explicitly provided the necessary functionality. The user guide described precisely how to create rules using the ssl_version keyword to identify and act upon packets with a specific TLS version, ensuring the outcome would be predictable and effective.
  • Key Aspects: The core of Petitioner's argument was that the ’552 patent claimed a routine combination of well-known network security techniques that were already consolidated and documented in a single commercial product’s user manual (Sourcefire). The patentability of the claims hinged on the specific second-stage filter for TLS version, a feature Petitioner argued was explicitly provided for in the prior art.

4. Relief Requested

• Petitioner requests institution of an inter partes review (IPR) and cancellation of claims 1-21 of the ’552 patent as unpatentable under 35 U.S.C. §103.