Obviousness

Obviousness Analysis of US11936693 under 35 U.S.C. § 103

This analysis aims to identify combinations of prior art references that would render the claims of US patent 11936693 obvious to a person having ordinary skill in the art (PHOSITA). The patent focuses on a system and method for applying policies on network paths in cloud environments, utilizing active inspection to validate reachability.

The independent claims of US11936693 (method, non-transitory computer-readable medium, and system) center on five core steps:

1. Selecting a reachable resource (cloud object with external network path).
2. Actively inspecting the network path (to determine external accessibility).
3. Applying a policy (with a conditional rule) on the accessible path.
4. Initiating a mitigation action (if the conditional rule is not met).
5. Applying the policy on another network path (if the conditional rule is met).

The patent itself lists several prior art documents as "Priority claimed from" applications. These are:

• US17/659,163 (which later issued as US12267326B2)
• US17/659,165 (which later issued as US12395488B2)
• US17/659,164 (which later issued as US12244627B2)
• US17/818,898 (which later issued as US12443720B2)

Additionally, US11936693 explicitly incorporates by reference the contents of U.S. Pat. No. 11,374,982, stating it discusses "a static analysis process for generating network paths, also known as determining reachability to a resource."

Given this, the following prior art references are considered for obviousness:

Primary Prior Art References:

• U.S. Pat. No. 11,374,982: This patent is explicitly referenced in US11936693 for its discussion of "static analysis process for generating network paths, also known as determining reachability to a resource." It would teach the concept of identifying network paths and determining reachability to cloud resources from external networks through static analysis.
• US17/659,165 (now US12395488B2): As a parent application, this would likely disclose aspects of active inspection, identifying reachable resources, and analyzing network paths for accessibility in cloud environments.
• US17/659,163 (now US12267326B2): Another parent application, likely contributing to the understanding of cloud environments, resource identification, and potentially elements of policy application or mitigation.
• US17/659,164 (now US12244627B2): Similar to the above, this parent application would add to the collective understanding of the technology space.
• US17/818,898 (now US12443720B2): Another related application, further enriching the prior art with disclosures pertinent to network security, cloud environments, and resource management.

Combinations and Rationale for Obviousness:

A PHOSITA in the field of cloud security, with knowledge of EASM (External Attack Surface Management), would have been motivated to combine the teachings of these prior art references to arrive at the claimed invention.

Combination 1: US11,374,982 + US17/659,165 (or US12395488B2)

• US11,374,982 teaches the fundamental concept of selecting a reachable resource and identifying network paths to access it through static analysis, specifically in cloud environments from an external network. This directly addresses step 1 of the independent claims. It also lays the groundwork for understanding what constitutes an accessible network path from an external network.
• US17/659,165 (or US12395488B2), as a continuation-in-part of which US11936693 is, would reasonably be expected to teach the concept of actively inspecting a network path to determine if it is accessible from the external network. The very title of US11936693, "System and method for applying a policy on a network path," implies a need to confirm the real-world accessibility of statically identified paths. Given the drawbacks of purely static analysis (e.g., a path appearing open but being blocked by an application, as discussed in US11936693's background), a PHOSITA would be motivated to introduce active inspection to validate these paths. Active scanning is a known EASM technique mentioned in the background of US11936693 itself. Therefore, applying active inspection (as described in the background of US11936693) to the network paths identified by static analysis (from US11,374,982) would be an obvious step to confirm actual vulnerability.

A PHOSITA would be motivated to combine these because static analysis alone, while identifying potential paths, does not confirm actual exploitability. Active inspection provides this crucial real-world validation. The motivation would be to improve the accuracy and efficiency of identifying genuine security vulnerabilities, reducing false positives generated by static analysis alone.

Combination 2: Combination 1 + US17/659,163 (or US12267326B2) / US17/659,164 (or US12244627B2) / US17/818,898 (or US12443720B2)

Once an accessible network path is identified through the combination of static analysis and active inspection, the next logical step for a PHOSITA in cloud security would be to apply a policy to manage or mitigate the exposure. The background of US11936693 discusses EASM technologies aiming to discover vulnerabilities "in order for a network administrator to secure the discovered vulnerabilities." This inherently suggests the need for policies and mitigation actions.

These additional priority applications (US17/659,163, US17/659,164, US17/818,898, and their issued patent numbers) are likely to contain disclosures related to security policies, rules, and actions within a cloud environment. Even if they don't explicitly detail the combination of active inspection with policy application on validated network paths, the general concept of applying security policies and initiating mitigation actions in response to detected vulnerabilities in a cloud environment would be well-known to a PHOSITA.

• A PHOSITA would be motivated to apply a policy (with a conditional rule) on an accessible network path (step 3) because confirming accessibility makes the path a real-world vulnerability that needs governance. Policies are standard mechanisms for defining desired security states.
• The motivation to initiate a mitigation action (step 4) when a conditional rule is not met is inherent in any security policy system. If a policy defines a desired state (e.g., a port should be closed) and that state is not met (e.g., the port is open and actively accessible), then an action must be taken to correct the undesired state. US11936693 itself lists common mitigation actions such as "revoking access, closing a port, generating a notification, generating an alert" (US11936693, "System where the mitigation action includes any one of: revoking access to the reachable resource, revoking access from the reachable resource, closing a port of the reachable resource, generating a notification, generating an alert, and any combination thereof."). These are conventional responses to security policy violations.
• Similarly, applying the policy on another network path (step 5) if the conditional rule is met (i.e., the path is compliant) is a logical extension for efficient policy enforcement across an environment. If one path is compliant, the system might then move to evaluate another, or apply a different set of rules, or even extend the successful policy to similar paths.

The combination of these elements, where a PHOSITA would take existing knowledge of static analysis, enhance it with active inspection for validation, and then integrate this validated information into a policy enforcement and mitigation framework, represents an obvious progression of security practices in cloud environments. The motivation would be to create a more robust and accurate security posture by focusing resources on actual, confirmed vulnerabilities and automating responses based on predefined rules.