Obviousness

Based on the provided prior art, here is an analysis of the obviousness of the claims of US Patent 10,193,917 under 35 U.S.C. § 103.

---

Obviousness Analysis of US Patent 10,193,917

Legal Standard for Obviousness

Under 35 U.S.C. § 103, a patent claim is invalid as "obvious" if the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (PHOSITA). An obviousness analysis can be based on a combination of multiple prior art references, but there must be a reasoned explanation for why a PHOSITA would have been motivated to combine their teachings to arrive at the claimed invention.

Core Inventive Concept of US 10,193,917

The central concept of the '917 patent, particularly in independent claims 1 and 11, is a closed-loop, user-driven system for escalating network security rules. The process involves:

1. Using a threat intelligence rule to allow but log traffic from a known threat.
2. The log entry must contain a specific threat identifier from the rule itself.
3. This log entry is presented to a user in a dedicated interface.
4. The interface provides a direct, interactive option for the user to reconfigure the existing rule's operator from "ALLOW" to "BLOCK."

Combination of Prior Art Rendering the Claims Obvious

The claims of US 10,193,917 are rendered obvious by the combination of US Patent 8,839,436 B2 (the '436 patent) and US Patent 9,106,675 B2 (the '675 patent).

• Primary Reference: The '436 Patent (Palo Alto Networks)
  The '436 patent teaches the foundational elements of the '917 system. It discloses a network security device that receives threat intelligence, which includes indicators and associated threat levels (e.g., high, medium, low). Critically, it describes enforcing policies based on these levels, such as blocking high-level threats while only logging traffic from medium-level threats. This directly teaches the core concept of having a rule for a known threat indicator that is intentionally set to "allow and log" rather than "block." The log entry would necessarily contain information identifying the threat that was triggered, analogous to the "Threat ID" in claim 1 of the '917 patent, in order to be useful to an administrator.

  Therefore, the '436 patent discloses:

  • Receiving packet-filtering rules based on network-threat indicators.
  • Applying a differentiated operator (e.g., allow/log for some threats, block for others).
  • Generating a log entry with information about the specific threat.

• Secondary Reference: The '675 Patent (McAfee)
  The '675 patent addresses the question of what to do with the information generated by a system like the one in '436. It teaches a system for providing a real-time notification of a security event to a user's device. Most importantly, it discloses an interface on that device that allows the user to send a command back to the security appliance to take a responsive action, such as blocking the offending traffic.

  Therefore, the '675 patent teaches:

  • Communicating security event data to a user device.
  • Displaying the event information in an interface.
  • Providing an interactive element for the user to initiate a "block" command in response to the event.

Motivation to Combine

A person of ordinary skill in the art of network security in the 2015 timeframe (the prior art date) would have been motivated to combine the teachings of the '436 patent and the '675 patent for a clear and predictable purpose: to improve the efficiency and speed of responding to detected threats.

1. Addressing a Known Problem: The '436 patent creates a system that generates logs for "medium" or otherwise non-critical threats. A network administrator using such a system would be faced with the task of reviewing these logs and manually deciding whether to escalate the response. This manual process introduces delay, increasing the network's exposure to the threat.

2. Applying a Known Solution: The '675 patent provides an elegant and known solution to this exact problem of response latency. It teaches that security events can be sent directly to the administrator, who can then take immediate action through an interface.

3. Predictable Result: Combining these two systems would be a straightforward engineering step. A PHOSITA would take the logging-and-notification functionality from '436 and, instead of requiring a manual, out-of-band response, would integrate the interactive user response mechanism taught by '675. The predictable result would be a system where an administrator sees a log of an "allowed" threat event (from '436's methodology) and can immediately click a button to block future traffic related to that specific threat (using '675's mechanism).

The specific implementation of this "block" command would most logically be to modify the existing rule in the '436 system for that threat indicator—that is, to "reconfigure the operator" from "allow/log" to "block." This is a more direct and efficient implementation than creating a new, redundant rule for the same indicator.

Conclusion

The '436 patent teaches the foundation of a system that uses threat-based rules to allow and log specific traffic, including the necessary threat identifiers. The '675 patent teaches an interactive user interface for acting upon such security notifications to initiate a block. Combining these references would lead directly to the system claimed in US 10,193,917. The motivation to combine—to reduce threat response time—was a well-understood goal in the field of network security. Therefore, the invention claimed in US 10,193,917 would have been obvious to a person of ordinary skill in the art at the time of the invention. This conclusion is consistent with the findings of the PTAB and CAFC, as noted in the litigation summary.