PTAB

IPR2018-01655

Cisco Systems Inc v. Centripetal Networks Inc

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Correlating Packets in Communications Networks
  • Brief Description: The ’176 patent describes a computing system for correlating network packets that traverse a network device performing Network Address Translation (NAT). The system identifies packets received from a host and packets transmitted by the device, generates log entries for both, correlates them by comparing the log entries, and generates rules to identify future packets based on the correlation.

3. Grounds for Unpatentability

Ground 1: Independent Claims 1, 11, and 21 are obvious over Ivershen, Rajan, Briggs, and Bloch.

  • Prior Art Relied Upon: Ivershen (Patent 8,219,675), Rajan (Patent 8,271,645), Briggs (Application # 2008/0320116), and Bloch (Patent 7,849,502).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Ivershen disclosed the core method of claim 1: a computing system that identifies and correlates packet flows on both sides of a NAT firewall. Ivershen’s system, however, stored entire captured packets. Rajan was cited to teach the claimed step of “generating a plurality of log entries” by disclosing the creation of trace logs that store only portions of network packets rather than the entire packet. For the final limitation of generating and provisioning rules based on the correlation, Petitioner combined Briggs and Bloch. Briggs taught analyzing network traffic to identify malicious devices behind a NAT and then initiating mitigation procedures, such as signaling a router to redirect the malicious traffic. Bloch explicitly taught that such mitigation involves a rule manager updating a firewall with rules based on the IP addresses of malicious hosts to block or redirect their traffic.
    • Motivation to Combine: A POSITA would combine Ivershen with Rajan to reduce memory storage requirements and decrease the processing load needed for correlation, as storing only partial packet data in logs is more efficient than storing full packets. A POSITA would further incorporate the teachings of Briggs and Bloch into the Ivershen/Rajan system to add a crucial security function. Identifying malicious traffic (as enabled by Ivershen's correlation) is the first step; the logical next step for a network security designer would be to automatically mitigate the threat by generating and applying firewall rules, as taught by Briggs and Bloch.
    • Expectation of Success: Petitioner asserted success would be predictable, as the combination involved applying known security techniques (threat identification and rule-based mitigation) to a known network monitoring architecture to achieve the expected benefit of improved network security.

Ground 2: Dependent Claims 2, 12, and 22 are obvious over Ivershen, Rajan, Briggs, Bloch, and Matityahu.

  • Prior Art Relied Upon: The combination from Ground 1, further in view of Matityahu (Patent 7,499,412).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground addressed claim 2, which adds that the communication paths to the network device comprise a "first tap" and a "second tap" that are provisioned with rules. Petitioner contended that Ivershen's "packet capture devices" are functionally equivalent to "taps." Matityahu was introduced to explicitly teach an improved, programmable network tap that can be provisioned with rules via a GUI to perform actions like deleting, replacing, or forwarding packets based on signature matches. The argument was that implementing Ivershen's packet capture devices as the programmable taps of Matityahu would render this limitation obvious.
    • Motivation to Combine: A POSITA would be motivated to use Matityahu's programmable taps in Ivershen's system to gain flexible functionality. This would allow the system not only to capture packets for logging (per Rajan) but also to actively inspect traffic and take immediate action (e.g., drop malicious packets) based on predefined rules, thus providing a more robust and responsive security solution than passive monitoring alone.
    • Expectation of Success: The combination was presented as predictable, as it involved replacing a basic component (a simple packet capturer) with a more advanced, well-understood version of the same component (a programmable tap) to gain known benefits of flexibility and active traffic management.

Ground 3: Dependent Claims 3, 13, and 23 are obvious over Ivershen, Rajan, Briggs, Bloch, and Frahim.

  • Prior Art Relied Upon: The combination from Ground 1, further in view of Frahim (a 2006 Cisco Press publication).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground addressed claim 3, which requires the correlation step to include "comparing one or more ports" from the pre-NAT and post-NAT log entries. Petitioner noted that while Ivershen taught that port numbers could be used for correlation, it preferred other methods because NAT devices often change port numbers. Frahim was introduced to teach the concept of a "static NAT," an implementation where the IP address is changed but the port number remains invariant as a packet traverses the firewall.
    • Motivation to Combine: A POSITA would be motivated to implement Ivershen's system with a static NAT as taught by Frahim in scenarios where external hosts need to initiate connections to internal servers. In such a static NAT environment, the port number becomes an "invariant" and thus a simple, reliable key for correlation. Using the now-stable port number for correlation in Ivershen's system would be a logical and beneficial design choice, simplifying the correlation process.
    • Expectation of Success: Success would be expected because using a static NAT is a known configuration choice in network design. Applying this known configuration to Ivershen's system would predictably make the port numbers invariant, thus making them a reliable and obvious choice for use in the system's correlation logic.
  • Additional Grounds: Petitioner asserted additional obviousness challenges for other dependent claims. Claims 6, 16, and 26 were challenged using Zhu (Patent 8,422,391) to teach correlating packets by comparing network-interface identifiers. Claims 8, 18, and 28 were challenged using Meloche (Patent 9,634,911) to teach generating and comparing timestamps in log entries as part of the correlation process.

4. Relief Requested

  • Petitioner requested the institution of an inter partes review and the cancellation of claims 1-3, 6, 8, 11-13, 16, 18, 21-23, 26, and 28 of the ’176 patent as unpatentable.