Cisco Systems Inc v. Centripetal Networks Inc

1. Case Identification

• Case #: IPR2018-01437
• Patent #: 9,160,713
• Filed: July 20, 2018
• Petitioner(s): Cisco Systems, Inc.
• Patent Owner(s): Centripetal Networks, Inc.
• Challenged Claims: 1-20

2. Patent Overview

• Title: Filtering Network Data Transfers
• Brief Description: The ’713 patent discloses systems and methods for filtering network data packets using a multi-stage, rule-based process at a Packet Security Gateway (PSG). The invention focuses on enhancing network security by inspecting packets and applying rules based on specific application-layer data, such as the version value of an encryption protocol like Transport Layer Security (TLS), to block traffic using versions with known vulnerabilities.

3. Grounds for Unpatentability

Ground 1: Claims 1-20 are obvious over Sourcefire in view of the general knowledge of a Person of Ordinary Skill in the Art (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 user manual, which describes the functionality of the Sourcefire 3D System Intrusion Prevention System (IPS), teaches all elements of the challenged claims. The Sourcefire system performs multi-stage packet filtering by first evaluating packet headers against a rule's "header" section, which specifies the 5-tuple (source/destination IP addresses and ports, and protocol), analogous to the ’713 patent’s first-stage filtering. The system then evaluates packet payloads against the rule's "options" section, which uses keywords to inspect application-layer data, analogous to the patent’s second-stage filtering.
  • Petitioner specifically pointed to Sourcefire’s SSL preprocessor, which is invoked by rule keywords to inspect encrypted traffic. The manual explicitly discloses an ssl_version keyword that allows a user to create rules that match against specific SSL and TLS versions, including tls1.0, tls1.1, and tls1.2. Sourcefire further teaches that rules can be configured with actions such as pass (forward) or drop (block) a packet that matches the rule criteria. Petitioner contended that this combination of features in Sourcefire directly maps to the claimed method of identifying a packet's TLS-version value and then forwarding or dropping the packet based on a corresponding rule.
  • Motivation to Combine (with POSA knowledge): Petitioner asserted that a POSA in March 2013 would have been well aware of the widely publicized security vulnerabilities in older encryption protocols, such as TLS 1.0. This general knowledge would provide a strong motivation to use the tools disclosed in the Sourcefire reference to enhance network security. A POSA would combine the knowledge of TLS 1.0's vulnerabilities with Sourcefire’s explicit teaching of an ssl_version rule keyword and a drop action. The motivation was simple and direct: to protect a network from known threats by implementing a rule to block traffic using the vulnerable TLS 1.0 protocol while allowing traffic using more secure versions like TLS 1.1 and 1.2.
  • Expectation of Success: The expectation of success in implementing this filtering scheme would have been high. The Sourcefire manual does not describe a theoretical system but provides detailed instructions for configuring an existing commercial product. It explicitly provides the necessary components: a keyword to identify the TLS version and actions to either block or allow the packet. Therefore, a POSA would have reasonably expected that creating a rule to filter traffic based on the TLS version would function as described and predictably result in improved network security.

4. Relief Requested

• Petitioner requests institution of an inter partes review (IPR) and the cancellation of claims 1-20 of Patent 9,160,713 as unpatentable under 35 U.S.C. §103.