PTAB

IPR2018-01505

Cisco Systems Inc v. Centripetal Networks Inc

Key Events
Petition

1. Case Identification

2. Patent Overview

  • Title: System and Method for Protecting a Secure Network
  • Brief Description: The ’205 patent discloses methods and systems for network security using "packet security gateways" (PSGs) located at network boundaries. These PSGs receive and apply a "dynamic security policy" from a central "security policy management server" (SPMS) to perform packet transformation functions on network traffic.

3. Grounds for Unpatentability

Ground 1: Obviousness over Jungck, Ingate, and RFC 2003 - Claims 49, 52-53, 55, 58-60, 63, 66-67, 69, 72-74, 77, 80-81, 83, 86-88 are obvious over Jungck in view of Ingate and RFC 2003.

  • Prior Art Relied Upon: Jungck (Application # 2009/0262741), Ingate (a 2008 SIP Security Best Practice document), and RFC 2003 (an IETF standard for IP Encapsulation within IP).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Jungck taught the core architecture of the ’205 patent, including packet interceptor gateways (PSGs) at network boundaries that are controlled by an external management device (an SPMS) to apply dynamic rules for network security. Ingate was cited for its disclosure of specific techniques for filtering Voice-over-IP (VoIP) traffic, including rules based on a combination of network addresses and Session Initiation Protocol (SIP) Uniform Resource Identifiers (URIs) to combat Denial of Service (DoS) attacks. For the claimed packet transformation function, Petitioner asserted that RFC 2003 taught IP-in-IP encapsulation, a well-known and standardized method for rerouting packets to an intermediate destination without modifying the original packet header.
    • Motivation to Combine: A Person of Ordinary Skill in the Art (POSITA) would combine Jungck’s general framework for programmable network security with Ingate’s specific teachings on SIP security to protect increasingly common VoIP systems. To implement the rerouting of suspicious packets for analysis (a function described in Jungck and Ingate), a POSITA would have looked to known, standardized methods. RFC 2003 provided a simple and efficient encapsulation technique that was preferable to alternatives because it allowed packets to be rerouted while preserving the original header, facilitating subsequent forwarding to the intended destination.
    • Expectation of Success: Petitioner contended that combining these references involved applying known security techniques (SIP filtering, packet encapsulation) to a known system architecture (centrally managed gateways). This combination would have yielded the predictable result of a more secure network for VoIP traffic.

Ground 2: Obviousness over Jungck, Ingate, RFC 2003, and RFC 4253 - Claims 59, 73, and 87 are obvious over Jungck in view of Ingate, RFC 2003, and RFC 4253.

  • Prior Art Relied Upon: Jungck, Ingate, RFC 2003 (as described in Ground 1), and RFC 4253 (an IETF standard for the Secure Shell (SSH) Transport Layer Protocol).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground built upon the combination in Ground 1 to address dependent claims requiring a PSG with a network-addressable management interface secured at the application, link, or transport level. Petitioner argued the base combination disclosed the PSG and its management interface. The incremental reference, RFC 4253, was cited for its disclosure of SSH, the industry-standard protocol for securing remote login and other network services at the application layer. Jungck itself explicitly suggested using SSH to secure its disclosed systems.
    • Motivation to Combine: A POSITA, having designed the system of Ground 1, would have been motivated to secure the management interface between the SPMS and the PSGs to prevent unauthorized access and ensure system integrity. Given that Jungck suggested SSH and RFC 4253 provided the standard for implementing it, a POSITA would have found it obvious to use RFC 4253 to secure the management communications.
    • Expectation of Success: Applying the standard SSH protocol to secure a management interface was a routine design choice in network security. A POSITA would have had a high expectation of success in implementing this well-known protocol for its intended and predictable purpose.

4. Key Claim Construction Positions

  • "Dynamic Security Policy": Petitioner argued this term should be construed according to its explicit definition in the ’205 patent: "any rule, message, instruction, file, data structure, or the like that specifies criteria corresponding to one or more packets and identifies a packet transformation function to be performed." This was presented as being broader than a "non-static set" of rules, a construction allegedly advanced by the Patent Owner in related litigation.
  • "Packet Transformation Function": Petitioner contended this term should be understood to include a range of actions such as forwarding, dropping, accepting, queueing, or routing packets. This construction was based on the specification and claim language (e.g., claims requiring a function other than forwarding or dropping) and was argued to be contrary to a narrower litigation position taken by the Patent Owner that sought to exclude forwarding and dropping from the term's scope.

5. Arguments Regarding Discretionary Denial

  • Petitioner argued that discretionary denial under §325(d) or §314(a) was not warranted. It asserted that this petition presented different prior art combinations and challenged different groups of claims than those considered during prosecution or in other IPR petitions involving the ’205 patent. Furthermore, the petition relied on a new declaration from its expert, Dr. Kevin Jeffay, which had not been previously presented to the USPTO. Petitioner contended that instituting review would be an efficient use of the Board's resources as the merits of these specific grounds had not yet been addressed.

6. Relief Requested

  • Petitioner requested the institution of an inter partes review and the cancellation of claims 49, 52-53, 55, 58-60, 63, 66-67, 69, 72-74, 77, 80-81, 83, and 86-88 of the ’205 patent as unpatentable.