Patent 10193917

Prior art

Earlier patents, publications, and products that may anticipate or render the claims unpatentable.

Active provider: Google · gemini-2.5-pro

Prior art

Earlier patents, publications, and products that may anticipate or render the claims unpatentable.

✓ Generated

Based on a review of the "References Cited" in the patent file for US Patent 10,193,917, the following prior art references are among the most relevant to the patent's claims. The analysis below considers potential anticipation under 35 U.S.C. § 102, which requires a single prior art reference to disclose every element of a claim.

Key Prior Art Analysis

The core invention of US 10,193,917 lies in a specific workflow:

  1. A filtering device uses rules based on threat intelligence.
  2. A rule can be set to "allow" traffic, which simply logs the event with a specific threat identifier from the rule itself.
  3. This log data is sent to a user interface.
  4. The user interface displays the event and provides an interactive element allowing the user to reconfigure the original rule's action from "allow" to "block."

The most relevant prior art teaches some, but not necessarily all, of these integrated steps.


1. US Patent 9,106,675 B2 ("the '675 patent")

  • Full Citation: US Patent 9,106,675 B2, "Network security system providing real-time notification of security events," assigned to McAfee, Inc.
  • Dates: Filed January 31, 2013; Issued August 11, 2015.
  • Brief Description: The '675 patent describes a network security device that, upon detecting a security event, sends a real-time notification to a registered user device, such as a smartphone. The notification includes details about the event. The user can then use their device to send a command back to the security device, instructing it to take action, such as blocking the offending traffic.
  • Potential Anticipation Analysis:
    • Claim 1 (Method): This reference is highly relevant and discloses many elements of claim 1. It teaches detecting a threat, generating a notification (analogous to a log entry), communicating it to a user device, displaying it in an interface, and allowing the user to initiate a "block" action. However, it may not anticipate claim 1 because it doesn't explicitly describe a rule with a pre-set "ALLOW" operator being reconfigured. Instead, it describes a system that detects an event and then allows a user to create a new blocking instruction. The '917 patent's claim is specific about reconfiguring an existing rule's operator.
    • Claim 11 (Apparatus): Similarly, the apparatus described in the '675 patent includes the components to perform the above method. It discloses a security device (processor, memory) and a user device. The potential difference lies in whether the processor is configured to specifically reconfigure an operator within an existing rule versus applying a new, separate blocking command based on user input.

2. US Patent 8,839,436 B2 ("the '436 patent")

  • Full Citation: US Patent 8,839,436 B2, "Enforcing network security policies based on threat levels," assigned to Palo Alto Networks, Inc.
  • Dates: Filed July 13, 2012; Issued September 16, 2014.
  • Brief Description: This patent details a network security device that receives threat intelligence, including indicators (like malicious IP addresses) and associated threat levels (e.g., high, medium, low). The device enforces policies based on these levels. For example, a policy could be set to automatically block "high" level threats but only log traffic from "medium" level threats. This allows for differentiated actions based on the severity of the threat indicator.
  • Potential Anticipation Analysis:
    • Claim 1 (Method): The '436 patent discloses receiving threat indicators (rules), applying an operator (block or log/allow), and generating a log entry with threat information. However, it does not appear to disclose the interactive loop where a user is notified of a specific "allowed" event and is presented with an immediate option in the same interface to reconfigure that rule to "block." The policy actions in '436 are based on pre-defined threat levels, not real-time user feedback on specific traffic flows. Therefore, it is unlikely to anticipate all elements of claim 1.
    • Claim 11 (Apparatus): The apparatus in the '436 patent is designed to enforce policies based on threat levels. It lacks the claimed functionality of generating an interactive interface for a user to reconfigure a rule's operator in response to a specific logged event.

3. US Patent Application Publication 2012/0255001 A1 ("the '001 application")

  • Full Citation: US 2012/0255001 A1, "Dynamic network defense," assigned to Cisco Technology, Inc.
  • Dates: Filed March 30, 2011; Published October 4, 2012.
  • Brief Description: The '001 application describes a comprehensive system where a central controller gathers threat intelligence from various sources and uses it to automatically create and distribute updated security policies to network enforcement devices (e.g., firewalls, routers). The system focuses on automating the response to emerging threats by pushing new rules to devices across a network.
  • Potential Anticipation Analysis:
    • Claim 1 (Method): This reference clearly teaches receiving packet-filtering rules based on network-threat indicators. It also teaches applying an operator (allow/block) and presumably logging the results. However, its focus is on the automated generation and distribution of rules by a central controller. It does not describe the specific user-centric feedback loop claimed in '917, where an end-user or administrator reviews a log of allowed threat traffic and reconfigures the rule to block it. This crucial interactive element appears to be missing.
    • Claim 11 (Apparatus): The system described includes a policy server and enforcement points, but the processors in these devices are configured for automated policy deployment rather than the specific interactive user notification and reconfiguration workflow of the '917 patent.

Generated 4/30/2026, 5:18:11 AM