US 11936693

I have searched the USPTO database for US patent 11936693 and found the following information. I also checked CAFC 2026 dockets but found no specific results for this patent number. CAFC dockets for 2026 show general patent-related cases and updates, but no direct mention of US11936693.

US Patent 11936693 Summary

• Title: System and method for applying a policy on a network path
• Assignee: Wiz Inc.
• Inventors: Roy Reznik, Matilda LIDGI, Shai Keren, Eliran MAROM
• Filing Date: July 24, 2023
• Issue Date: March 19, 2024
• Abstract: A system and method for applying a policy on a network path is disclosed. The method includes: selecting a reachable resource having a network path to access the reachable resource, wherein the reachable resource is a cloud object deployed in a cloud computing environment, having access to an external network which is external to the cloud computing environment; actively inspecting the network path to determine if the network path of the reachable resource is accessible from the external network; applying a policy on the accessible network path, wherein the policy includes a conditional rule; initiating a mitigation action, in response to determining that the conditional rule is not met; and applying the policy on another network path, in response to determining that the conditional rule is met.

Plain-Language Overview of Independent Claims:

The patent has several independent claims, generally structured around methods, non-transitory computer-readable media, and systems for applying policies to network paths in cloud environments.

Independent Method Claim Overview:
This claim describes a method that involves:

1. Selecting a reachable resource: Identifying a cloud object within a cloud computing environment that has a network path allowing access from an external network.
2. Actively inspecting the network path: Performing an active check to see if the identified network path to the reachable resource is actually accessible from the external network.
3. Applying a policy: Implementing a policy, which contains a conditional rule, on the network path that was determined to be accessible.
4. Initiating a mitigation action (if rule not met): If the conditional rule of the policy is not satisfied, a mitigation action is triggered.
5. Applying the policy on another network path (if rule met): If the conditional rule is satisfied, the policy is then applied to a different network path.

Independent Non-Transitory Computer-Readable Medium Claim Overview:
This claim covers a non-transitory computer-readable medium (e.g., software) that stores instructions. When these instructions are executed by a device's processor, they cause the device to perform the same steps as outlined in the independent method claim: selecting a reachable resource, actively inspecting its network path, applying a policy with a conditional rule, initiating a mitigation action if the rule is not met, and applying the policy to another network path if the rule is met.

Independent System Claim Overview:
This claim describes a system comprising processing circuitry and memory. The memory contains instructions that, when executed by the processing circuitry, configure the system to perform the same sequence of actions as the independent method claim: selecting a reachable resource, actively inspecting its network path, applying a policy with a conditional rule, initiating a mitigation action if the rule is not met, and applying the policy to another network path if the rule is met.

As of April 26, 2026, there is known litigation involving US patent 11936693:

• Case Number: IPR2025-01085
  • Plaintiff(s): Petitioner is "Unified Patents"
  • Defendant(s): Not explicitly stated in the provided snippet, but Unified Patents typically challenges patents asserted by Non-Practicing Entities (NPEs) to protect its members.
  • Jurisdiction: Patent Trial and Appeal Board (PTAB)
  • Filing Date: The case was filed on March 5, 2025 (Note: The Google Patents page lists "PTAB case IPR2025-01085 filed (Settlement)" with a date of "2025-03-05").
  • Outcome or Current Status: Settlement.

Proceedings overview

A single AIA trial proceeding, IPR2025-01085, was filed against US patent 11936693. This proceeding was terminated due to a settlement between the parties, meaning no claims of the patent were invalidated or confirmed patentable by the PTAB. This leaves the patent's claims entirely untested by the PTAB, presenting a neutral defensive posture for potential defendants.

IPR2025-01085 — Orca Security Ltd. v. Wiz Inc.

• Type: Inter Partes Review
• Filed: 2025-06-04
• Status: Terminated-Settled. This indicates that the parties reached an agreement and the proceeding was dismissed before a substantive decision on the merits of the patent's claims.
• Judge panel: Not publicly available for this terminated proceeding, as it settled before institution.
• Petition grounds: Details on specific claims challenged, prior art, and statutory bases (e.g., § 102 / § 103) are not publicly available due to the settlement before substantive proceedings.
• Institution decision: No institution decision was issued, as the proceeding was terminated due to settlement.
• Final Written Decision: No Final Written Decision was issued due to the settlement and termination of the proceeding.
• Settlement / termination: The proceeding was terminated on 2026-01-14. This termination was part of a broader settlement in a district court litigation (Case 1:23-cv-00758-JLH in the U.S. District Court for the District of Delaware) between Petitioner Orca Security Ltd. and Patent Owner Wiz Inc., which resulted in the dismissal of all claims and counterclaims with prejudice. The specific terms of the settlement are confidential.
• Appeal: No appeal was filed, as the proceeding terminated prior to a final decision on patentability.
• Defensive value: As this IPR was settled and terminated before any claims were evaluated on the merits by the PTAB, the patent's claims remain untested by an AIA trial. This means a defendant facing assertion of this patent today would need to independently assess the validity of the claims, as there is no PTAB decision to rely upon for invalidation or hardening.

Strategic summary

All claims of US11936693 remain UNTESTED by the PTAB, as the single IPR filed against it, IPR2025-01085, was terminated due to settlement. No claims were canceled or sustained through a Final Written Decision.

The estoppel landscape for this patent is relatively clear. While Orca Security Ltd. and its privies are likely estopped from re-challenging US11936693 on any grounds that were raised or reasonably could have been raised in IPR2025-01085, this estoppel generally only applies to that specific petitioner. Other potential defendants or petitioners are not affected by this settlement and would be free to file their own IPR petitions if they identify relevant prior art and grounds.

Regarding pattern signals, only one IPR was filed against US11936693. The early settlement of this IPR suggests that both parties, in the context of their broader litigation, found it mutually beneficial to resolve disputes outside of a full PTAB trial on this specific patent. The news reports indicate that other IPRs involving patents asserted by Orca against Wiz did result in claims being found unpatentable, but those were different patents belonging to Orca.

Recommended next steps

Since IPR2025-01085 was terminated by settlement, no claims of US11936693 have been invalidated by the PTAB. For a defendant currently being asserted against, the patent's validity has not been tested in an AIA trial. Therefore, any new defendant would need to conduct their own prior art search and analysis to determine the strength of a potential invalidity challenge at the PTAB or in district court.

Inventors

• Roy Reznik (Wiz Inc.)
• Matilda LIDGI (Wiz Inc.)
• Shai Keren (Wiz Inc.)
• Eliran MAROM (Wiz Inc.)

Original assignee

The original assignee is Wiz Inc. Wiz Inc. is an operating company in the cybersecurity domain, offering a cloud security platform. Based on their public profile, they ship products embodying the claims, specifically in cloud exposure detection and external attack surface management. Their current status is operating.

Assignment timeline

The USPTO Assignment Center (https://assignmentcenter.uspto.gov/) was searched for US patent 11936693. As of May 16, 2026, there is one assignment record for this patent:

• 2023-07-25 (executed) / recorded 2023-07-25 — Reel 063628/0879
  • Conveyance: Assignment of Assignors Interest
  • Assignor: REZNIK, Roy; LIDGI, Matilda; MAROM, Eliran; KEREN, Shai (inventors)
  • Assignee: Wiz Inc.
  • Correspondent: Jeffrey M. Schwartz, JEFFREY M. SCHWARTZ, P.A., 2217 NW 57TH COURT, BOCA RATON, FL 33496
  • Context: Transfer of inventor rights to the original assignee.

Timeline diagram

timeline
    title Ownership of US 11936693
    2023-07-24 : Filed by Wiz Inc.
    2023-07-25 : Inventors assign to Wiz Inc.
    2024-03-19 : Issued

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The initial assignment is from the individual inventors to Wiz Inc., which is a known operating company.
2. Known asserter in the chain — not present. Wiz Inc. is an operating company in cloud security.
3. Repeat correspondent across the chain — unclear. Jeffrey M. Schwartz, JEFFREY M. SCHWARTZ, P.A. is listed as the correspondent for the 2023-07-25 assignment. With only one assignment on record, it is not possible to determine if this correspondent recurs across multiple links in the chain for this patent.
4. Cascading transfers — not present. There is only one assignment recorded.
5. Pre-litigation transfer — unclear. While there is an IPR case (IPR2025-01085) filed on 2025-03-05, the single assignment to Wiz Inc. was recorded on 2023-07-25, which is more than six months prior to the IPR filing. The IPR case relates to validity, not infringement. No infringement suit has been identified.
6. Bankruptcy fire-sale — not present. Wiz Inc. is an active and growing company.
7. Privateering — not present. No evidence suggests a transfer for assertion on behalf of an operating company.
8. Defensive aggregator (anti-NPE) — not present. The current owner is Wiz Inc.

Verdict

Insufficient data. There is only one recorded assignment, which is the standard inventor-to-assignee transfer at the time of filing. This record does not show any transfers that would indicate an NPE pattern. The patent is currently owned by the original operating company, Wiz Inc. A future acquisition of Wiz Inc by Google has been reported, but not yet finalized or recorded on the USPTO assignment system.

USPTO Assignment Center search for US11936693: https://assignmentcenter.uspto.gov/

To identify the most relevant prior art for US patent 11936693, I need to access its citations from the USPTO database. Since I cannot directly interact with a live USPTO database search tool, I will proceed based on the common practice of patents citing prior art within their own documentation.

The provided patent text for US11936693 lists "Prior art keywords" and "Prior art date" but does not explicitly detail a list of "References Cited" in a separate section that would typically be found in a patent document. However, it does refer to related applications:

• U.S. Non-Provisional patent application Ser. No. 17/659,165 filed on Apr. 13, 2022.
• U.S. Non-Provisional patent application Ser. No. 17/659,163 filed on Apr. 13, 2022.
• U.S. Non-Provisional patent application Ser. No. 17/659,164, filed Apr. 13, 2022.
• U.S. Non-Provisional patent application Ser. No. 17/818,898 filed Aug. 10, 2022.
• U.S. Pat. No. 11,374,982 (mentioned in the detailed description for static analysis process).

Additionally, the Google Patents page for US11936693 (which is authoritative as per the operating rules) lists other priority applications:

• US17/659,163 (Priority claimed from 2022-04-13)
• US17/659,165 (Priority claimed from 2022-04-13)
• US17/659,164 (Priority claimed from 2022-04-13)
• US17/818,898 (Priority claimed from 2022-08-10)

For a thorough prior art analysis, these related applications, particularly US Pat. No. 11,374,982, would be crucial to examine. Without explicit claim-by-claim analysis of these related patents and applications, and without their full text, I can only provide a general assessment of potential anticipation.

Given the information at hand, I will focus on US Pat. No. 11,374,982, as it is directly referenced within the detailed description for a core component of the disclosed method in US11936693, namely "generating network paths, also known as determining reachability to a resource."

Most Relevant Prior Art for US Patent 11936693 (Based on provided text and citation):

Reference 1: U.S. Pat. No. 11,374,982

• Full Citation: U.S. Pat. No. 11,374,982 (The full citation details such as inventor, assignee, and exact publication date are not provided in the current text, but the patent number is.)
• Publication/Filing Date: Not explicitly stated in the provided text for US11936693, only that its content is incorporated by reference.
• Brief Description: This patent describes an "example of a static analysis process for generating network paths, also known as determining reachability to a resource." This process is integral to identifying initial network paths that US11936693 then actively inspects.
• Which claim(s) it potentially anticipates under 35 U.S.C. § 102:
  U.S. Pat. No. 11,374,982, by describing a static analysis process for "generating network paths" and "determining reachability to a resource," directly relates to the initial steps of identifying potential network paths to a reachable resource. This could potentially anticipate the "selecting a reachable resource having a network path to access the reachable resource" element found in independent claims of US11936693 (Method Claim 1, Computer-Readable Medium Claim 1, and System Claim 1). If the prior art describes the entirety of this selection step, including the resource being a cloud object deployed in a cloud computing environment with access to an external network, it would be highly relevant under 35 U.S.C. § 102. The extent of anticipation would depend on the specific details of how US 11,374,982 defines and implements "generating network paths" and "determining reachability."

To provide a more comprehensive prior art analysis, the full text and claims of US 11,374,982, as well as the other mentioned priority applications (US 17/659,165, US 17/659,163, US 17/659,164, and US 17/818,898), would need to be reviewed to determine specific elements and their potential overlap with the claims of US11936693.

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.

Patent Term Adjustments (PTA)

Patent Term Adjustment (PTA) can extend a patent's term to compensate for delays by the USPTO during prosecution. These delays typically include: failing to issue a first Office Action or notice of allowance within 14 months of filing; failing to act within four months of an applicant's response; or failing to issue the patent within four months of paying the issue fee. PTA also applies if the patent takes more than three years from its actual filing date to issue, with certain exceptions for applicant-caused delays. Any PTA granted can be reduced by periods of time when the applicant did not make reasonable efforts to conclude prosecution.

To determine the specific PTA for US11936693, access to the USPTO Patent Center or Public PAIR system would be required. These systems provide the official PTA calculations as part of the patent's prosecution history. Without this direct access, I cannot provide an exact PTA value.

Patent Term Extensions (PTE)

Patent Term Extension (PTE) is a different mechanism from PTA, primarily designed to compensate for delays in obtaining regulatory approval for certain products, such as human drugs, food additives, medical devices, animal drugs, and veterinary biological products. The maximum PTE is typically five years, and the total post-approval patent life cannot exceed 14 years from the date of FDA approval. PTE applications must be filed within 60 days of regulatory agency approval and meet specific criteria, including that the patent claims the approved product, a method of using it, or a method of manufacturing it. Only one patent can be extended for a regulatory review period for any given product.

Given that US11936693 relates to "System and method for applying a policy on a network path" in cloud environments, it is highly unlikely to be eligible for PTE, as its subject matter does not fall within the categories of products requiring premarket regulatory review by agencies like the FDA.

Continuation Applications

The provided patent text explicitly states that US11936693 is a continuation-in-part of several U.S. Non-Provisional patent applications:

• U.S. Non-Provisional patent application Ser. No. 17/659,165 filed on Apr. 13, 2022.
• U.S. Non-Provisional patent application Ser. No. 17/659,163 filed on Apr. 13, 2022.
• U.S. Non-Provisional patent application Ser. No. 17/659,164, filed Apr. 13, 2022.
• U.S. Non-Provisional patent application Ser. No. 17/818,898 filed Aug. 10, 2022.

Additionally, the Google Patents page also lists priorities from these application numbers, and notes that some of them have issued as patents:

• US17/659,163 (Priority claimed from 2022-04-13) - later issued as US12267326B2
• US17/659,165 (Priority claimed from 2022-04-13) - later issued as US12395488B2
• US17/659,164 (Priority claimed from 2022-04-13) - later issued as US12244627B2
• US17/818,898 (Priority claimed from 2022-08-10) - later issued as US12443720B2
• US18/435,745 (Priority claimed from 2024-02-07) - later issued as US12284220B2
• US19/071,388 (Priority claimed from 2025-03-05) - later issued as US20250202952A1

This indicates a family of related applications, where US11936693 builds upon or shares common subject matter with these earlier filings.

Divisional Applications

There is no explicit mention of divisional applications for US11936693 in the provided patent text or the Google Patents information. Divisional applications typically arise when an examiner determines that an application contains claims to more than one invention, and the applicant elects to prosecute only one. Without specific information from the USPTO public records for this patent, I cannot confirm the existence of any divisional applications.

Related Family Members

Based on the continuation-in-part relationships and priority claims, the following are related family members:

• US17/659,165 (later issued as US12395488B2)
• US17/659,163 (later issued as US12267326B2)
• US17/659,164 (later issued as US12244627B2)
• US17/818,898 (later issued as US12443720B2)
• US18/435,745 (later issued as US12284220B2)
• US19/071,388 (later issued as US20250202952A1)
• US20230370499A1 (other version of US11936693B2, indicating a published application before grant)

These form a patent family sharing priority dates and likely related subject matter concerning exposure detection and active inspection in cloud environments.

Projected Expiration Date

The "Prior art date" for US11936693 is listed as April 13, 2022. This typically corresponds to the earliest priority date. Utility patents generally have a term of 20 years from their earliest non-provisional filing date. Therefore, without any patent term adjustments (PTA) or extensions (PTE), the statutory expiration date would be 20 years from April 13, 2022.

• Earliest Priority Date: April 13, 2022
• Statutory 20-year Term End: April 13, 2042.

The Google Patents page explicitly states "Anticipated expiration: 2042-04-13", which aligns with the 20-year term from the earliest priority date.

This expiration date would be subject to any PTA awarded for USPTO delays during prosecution, or any terminal disclaimers. As noted above, PTE is not expected for this type of patent. Without access to the official USPTO records detailing the PTA calculation, the anticipated expiration date of April 13, 2042, stands as the projected expiration date.

Defensive Disclosure: Derivative Works for US Patent 11936693

This document outlines derivative works and technical disclosures for US Patent 11936693, "System and method for applying a policy on a network path." The objective is to establish prior art for potential future incremental improvements by competitors, rendering such advancements obvious or non-novel. The derivations are structured around the core functional steps of US11936693's independent claims:

1. Selecting a reachable resource (cloud object in a cloud computing environment with an external network access path).
2. Actively inspecting the network path (to determine external accessibility).
3. Applying a policy (on the accessible network path, with a conditional rule).
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).

These derivations expand upon the original invention across various technical axes, providing detailed, enabling descriptions.

1. Material & Component Substitution

1.1. Derivative: Hardware-Accelerated Active Inspection with Programmable Logic Arrays

Enabling Description:
This derivative implements the active inspection and policy application logic using Field-Programmable Gate Arrays (FPGAs) or Application-Specific Integrated Circuits (ASICs) within a dedicated network security appliance or as a PCI Express (PCIe) accelerator card within a server. The "active inspector" (e.g., active inspector 125 of FIG. 1) functionality is offloaded to a custom hardware logic block. The processing circuitry (610) would be a heterogeneous architecture comprising a general-purpose processor for control plane logic (e.g., resource selection, policy rule management, report generation) and an FPGA/ASIC for data plane operations (packet generation, transmission, response parsing, real-time policy evaluation against incoming packets). Network paths are analyzed by the FPGA/ASIC generating custom packet sequences (e.g., malformed HTTP requests, specific SSH handshakes, port probes) at wire-speed. The conditional rules of the policy are translated into hardware-level finite state machines (FSMs) or lookup tables (LUTs) within the FPGA/ASIC, enabling nanosecond-latency policy enforcement decisions on detected network path accessibility. Mitigation actions (e.g., signaling a firewall to block an IP, resetting a connection) are triggered directly by the hardware logic via dedicated control signals or high-speed inter-process communication (IPC) to network enforcement points. The security graph (122) remains a software component, feeding path parameters and policy rules to the hardware through a defined API.

graph TD
    A[Cloud Security Platform Control Plane - GPP] --> B(Resource Selector)
    B --> C{Security Graph DB}
    C --> D(Policy Engine)
    D --> E[Hardware Transcoder: Policy Rules to H/W Logic]
    E --> F[FPGA/ASIC Data Plane: Active Inspector & Policy Enforcer]
    F -- Generate Access Instruction Packets --> G[External Network Interface Card]
    G -- Network Path Probes --> H[Reachable Cloud Resource in Cloud Environment]
    H -- Network Response --> G
    G -- Parse Response Packets --> F
    F -- Policy Evaluation (H/W FSM/LUT) --> I{Conditional Rule Met?}
    I -- No --> J[Mitigation Action Trigger (H/W Signal)]
    I -- Yes --> K[Apply Policy to Another Path / Log Compliance]
    J --> L[Network Enforcement Point (e.g., Firewall)]
    K --> B

1.2. Derivative: Quantum-Resistant Cryptographic Components for Inspection Instructions

Enabling Description:
This derivative focuses on the security of the active inspection process itself, specifically the "access instruction" (S320, S330) and credentials during inspection of the network path (S910). For cloud environments requiring utmost security, such as governmental or critical infrastructure, the communication channel between the active inspector and the reachable resource, especially when providing credentials or executing sensitive access instructions, is secured using quantum-resistant cryptographic algorithms. The processing circuitry (610) incorporates specialized quantum-safe cryptographic modules (e.g., hardware security modules based on lattice-based cryptography like CRYSTALS-Dilithium for digital signatures and CRYSTALS-Kyber for key encapsulation, or hash-based signatures like XMSS/LM-OTS). These modules are used to establish secure communication tunnels for active inspection probes, protecting against future quantum computing attacks on current asymmetric encryption standards. The access instructions (e.g., "ssh user@10.0.0.256:22") are encapsulated within these quantum-resistant secure channels. The memory (620) stores pre-shared quantum-resistant keys or certificates, and the network interface (640) is optimized for efficient processing of larger quantum-safe cryptographic primitives without introducing significant latency during active inspection attempts.

sequenceDiagram
    participant AI as Active Inspector (Q-Resistant Crypto Module)
    participant RES as Reachable Cloud Resource
    AI->>RES: Initiate Q-Resistant Handshake (e.g., Kyber KEM, Dilithium Signature)
    activate RES
    RES-->>AI: Q-Resistant Key Exchange & Auth
    deactivate RES
    AI->>RES: Establish Q-Resistant Secure Channel
    AI->>RES: Send Encrypted Access Instruction (e.g., "ssh user@...")
    activate RES
    RES-->>AI: Encrypted Response (e.g., ACK, Error)
    deactivate RES
    AI->>AI: Determine Accessibility & Apply Policy

2. Operational Parameter Expansion

2.1. Derivative: Hyperscale Multi-Cloud, Multi-Tenant Active Inspection

Enabling Description:
This derivative scales the active inspection system to operate across millions of cloud objects distributed across hundreds of distinct cloud computing environments (e.g., AWS, Azure, GCP, Alibaba Cloud, private OpenStack instances) belonging to thousands of distinct tenants (organizations). The "active inspector" (125) is deployed as a globally distributed, elastic cluster of microservices, each optimized for specific cloud provider APIs and network topologies. Resource selection (S905) involves federated queries across multiple security graph databases (122), which are sharded and replicated for high availability and low latency. Active inspection (S910) is orchestrated by a central scheduler that dynamically allocates inspection tasks to regional active inspector instances based on the geographical proximity to the target reachable resource, network latency, and current load. The system handles billions of network paths concurrently. Policy application (S915) is managed by a distributed policy engine (116) that can enforce conditional rules with varying scopes (global, regional, per-tenant, per-resource) and granularities (IP, port, protocol, application layer). Mitigation actions (S950) are triggered via API calls to cloud provider security services (e.g., Security Groups, Network ACLs, WAFs) or by issuing commands to tenant-specific orchestration platforms, handling concurrency and potential rate limiting across all connected environments.

graph TD
    A[Global Orchestrator & Scheduler] --> B[Regional Active Inspector 1 (AWS)]
    A --> C[Regional Active Inspector 2 (Azure)]
    A --> D[Regional Active Inspector 3 (GCP)]
    B --> E[Cloud Environment A: Tenant 1 Resources]
    C --> F[Cloud Environment B: Tenant 2 Resources]
    D --> G[Cloud Environment C: Tenant 3 Resources]
    E -- Network Paths --> B
    F -- Network Paths --> C
    G -- Network Paths --> D
    B -- Inspection Results --> A
    C -- Inspection Results --> A
    D -- Inspection Results --> A
    A --> H[Federated Security Graph DBs]
    H --> A
    A --> I[Distributed Policy Engine]
    I -- Apply Policy / Trigger Mitigation --> J[Cloud Provider Security APIs]

2.2. Derivative: Real-time, Millisecond-Latency Active Inspection for High-Frequency Trading Networks

Enabling Description:
This derivative targets extreme low-latency environments, specifically high-frequency trading (HFT) networks in cloud or hybrid deployments. The core method steps are adapted for real-time monitoring and policy enforcement within a sub-millisecond timeframe. Resource selection (S905) is pre-computed and cached for critical trading infrastructure components. Active inspection (S910) involves custom-built, ultra-low-latency network probes implemented on specialized Network Interface Cards (NICs) with FPGA offload or SmartNICs capable of generating and analyzing network packets within microseconds. These probes monitor for deviations in expected network path behavior, such as unexpected open ports or protocol responses, with latency requirements for detection and response typically under 100 microseconds. Policies (S915) are defined with strict real-time conditional rules (e.g., "any port other than 443 and 8070 accessible via external network from specific IP range triggers immediate blocking"). Mitigation actions (S950) are hardware-accelerated, directly interfacing with programmable network switches or firewalls to apply packet filtering rules (e.g., access control list (ACL) updates) within single-digit microseconds, or to trigger circuit breakers on specific trading application instances, thus preventing potential financial system manipulation or data exfiltration.

stateDiagram-v2
    [*] --> Initialized
    Initialized --> Pre_Compute_Paths: System Start
    Pre_Compute_Paths --> Monitor_Critical_Paths: Paths Cached
    Monitor_Critical_Paths --> Generate_Probe: Timer/Event Trigger
    Generate_Probe --> Send_Probe_HW: <10us
    Send_Probe_HW --> Receive_Response_HW: <10us
    Receive_Response_HW --> Evaluate_Policy_HW: <50us
    Evaluate_Policy_HW --> Mitigation_Action_HW: Rule Violated
    Evaluate_Policy_HW --> Monitor_Critical_Paths: Rule Met
    Mitigation_Action_HW --> Apply_ACL_HW: <10us
    Apply_ACL_HW --> Monitor_Critical_Paths: Action Applied

3. Cross-Domain Application

3.1. Derivative: Policy Application on Network Paths in Space-Based Satellite Constellations

Enabling Description:
This derivative applies the patent's core mechanism to the domain of space-based satellite constellations, specifically for maintaining the security of inter-satellite links and ground-to-satellite communication paths.

1. Selecting a reachable resource: Identifies individual satellites or specific payload modules on a satellite (acting as "cloud objects") within a constellation. A "network path" could be an uplink/downlink to a ground station, or an inter-satellite optical/RF link. The "external network" would be the ground control segment or other non-trusted satellite networks.
2. Actively inspecting the network path: Ground-based active inspectors or on-board autonomous active inspector modules send specially crafted telemetry or command packets across the identified communication paths. This checks for unexpected open command channels, vulnerable diagnostic ports, or deviations in expected cryptographic handshakes for authorized links. Due to high latency and potential intermittent connectivity, inspection might involve asynchronous challenges and responses.
3. Applying a policy: A policy engine (either ground-based or distributed across a subset of command satellites) applies conditional rules such as "inter-satellite links must use quantum-resistant encryption protocols for data plane," or "only authorized ground stations with specific orbital mechanics prediction parameters can establish a command link on port X."
4. Initiating a mitigation action: If a policy is violated (e.g., an unauthorized attempt to access a diagnostic port is detected), a mitigation action could involve commanding the satellite to temporarily close the compromised port, re-keying cryptographic modules for the affected link, initiating an evasive maneuver, or isolating the suspicious payload module.
5. Applying the policy on another network path: If an inter-satellite link is compliant, the policy engine proceeds to validate the next link in the chain or a different ground-to-satellite path.

graph TD
    A[Ground Control Segment] --> B(Active Inspector Module - Ground)
    B --> C{Satellite Constellation: Sat 1, Sat 2, ..., Sat N}
    C -- Uplink/Downlink/Inter-Sat Link --> B
    B --> D[Policy Engine - Ground]
    D -- Commands --> C
    C -- Telemetry/Status --> D
    D --> E{Policy Rule Met?}
    E -- No --> F[Mitigation Action (e.g., Re-key Link, Port Closure)]
    E -- Yes --> G[Next Path Evaluation]

3.2. Derivative: Policy Application on Network Paths in Industrial Control Systems (ICS) / Operational Technology (OT) Networks

Enabling Description:
This derivative applies the patent's principles to industrial control systems (ICS) and operational technology (OT) networks, such as those found in manufacturing plants, energy grids, or water treatment facilities. The focus is on securing communication paths between Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), Human-Machine Interfaces (HMIs), and supervisory control and data acquisition (SCADA) systems.

1. Selecting a reachable resource: Identifies critical ICS/OT devices (e.g., specific PLCs controlling a turbine, RTUs managing a pipeline valve) as "cloud objects," even if physically on-premises. A "network path" could be a Modbus TCP/IP, Ethernet/IP, or OPC UA communication channel between a SCADA server and a PLC, or a maintenance laptop connected to an engineering workstation. The "external network" is typically the corporate IT network attempting to reach the OT segment for data collection or remote management, or even an internet connection for cloud-based SCADA.
2. Actively inspecting the network path: A specialized, non-intrusive active inspector (e.g., a "bump-in-the-wire" device or an out-of-band monitoring appliance) generates controlled, protocol-aware probes (e.g., Modbus read requests for specific registers, OPC UA discovery queries) to validate that only expected ports are open and that devices respond as anticipated on known communication paths. These probes are designed to be safe for OT environments, avoiding commands that could disrupt operations.
3. Applying a policy: A policy engine (potentially air-gapped from the IT network) applies conditional rules like "no internet-facing path to PLC X is permitted on any port," or "Modbus TCP communication on path Y must only originate from SCADA server Z and target function code 03 (read holding registers)."
4. Initiating a mitigation action: If a policy is violated (e.g., an unknown IP attempts to initiate an Ethernet/IP session with an HMI), mitigation could involve segmenting the network using an industrial firewall, generating an alert to the plant operator, or temporarily blocking the suspicious source IP at the network edge, ensuring process integrity and safety.
5. Applying the policy on another network path: If the policy for one critical data acquisition path is compliant, the system moves to inspect the control path for another critical asset.

flowchart LR
    A[SCADA Server] -- Network Path (e.g., OPC UA) --> B[PLC 1]
    A -- Network Path (e.g., Modbus TCP) --> C[RTU 1]
    X[External IT Network] -- Network Path (e.g., SSH, RDP) --> D[Engineering Workstation]
    D -- Network Path (e.g., Ethernet/IP) --> E[HMI]
    
    SubGraph Active Inspection & Policy Enforcement
        AI[OT Active Inspector]
        PE[OT Policy Engine]
    End
    
    AI -- Probes --> B
    AI -- Probes --> C
    AI -- Probes --> E
    PE -- Rules --> AI
    AI -- Policy Violation --> PE
    PE -- Mitigation Action --> F[Industrial Firewall/Segmentation]
    PE -- Policy Compliance --> G[Next Path]

3.3. Derivative: Policy Application on Network Paths for Medical Devices and Healthcare IoT

Enabling Description:
This derivative extends the patent's methodology to the critical domain of medical devices and Healthcare Internet of Things (HIoT) within a hospital or clinical setting. This includes devices like infusion pumps, patient monitors, MRI machines, and wearable sensors.

1. Selecting a reachable resource: Identifies individual medical devices (e.g., "smart" infusion pump, networked PACS server, patient vital sign monitor) as "cloud objects," even if residing on a local network. A "network path" could be a Wi-Fi connection from a patient monitor to a central nursing station, an Ethernet link from an MRI machine to an image archive, or a Bluetooth Low Energy (BLE) link from a wearable sensor to a gateway. The "external network" includes the hospital's administrative network, remote diagnostic VPNs, or the public internet if devices are cloud-connected.
2. Actively inspecting the network path: A dedicated medical device active inspector, possibly an embedded module or an isolated network appliance, sends benign, device-specific queries (e.g., SNMP polls for device status, DICOM handshake attempts, custom API calls) over identified network paths. This verifies that devices respond appropriately, only expose expected services/ports, and adhere to predefined communication profiles, without impacting patient care.
3. Applying a policy: A specialized policy engine, integrated with the hospital's Biomedical Engineering department, applies conditional rules such as "infusion pumps must only communicate with pharmacy servers on port X for dosage updates," or "patient data streams from device Y must be encrypted using FIPS 140-2 validated modules."
4. Initiating a mitigation action: If a policy is violated (e.g., a patient monitor attempts to connect to an unapproved external IP, or an unsecured diagnostic port is found open), mitigation actions could include isolating the device to a quarantined VLAN, generating a high-priority alert for clinical and IT staff, or even disabling non-essential network functions on the device to prevent patient data compromise or device malfunction.
5. Applying the policy on another network path: Upon confirming policy adherence for one critical medical device's communication path, the system moves to actively inspect another device or a different communication pathway.

sequenceDiagram
    participant AI as Medical Device Active Inspector
    participant MD1 as Infusion Pump
    participant PS as Pharmacy Server
    participant CNS as Central Nursing Station
    participant PE as Policy Engine (BioMed/IT)
    
    AI->>MD1: Select Reachable Resource (Infusion Pump)
    AI->>MD1: Actively Inspect Network Path (e.g., to PS)
    activate MD1
    MD1-->>AI: Response (Port Status, Protocol Version)
    deactivate MD1
    AI->>PE: Report Inspection Results
    PE->>PE: Apply Policy (e.g., "Only connect to PS on port X")
    alt Conditional Rule Not Met
        PE->>MD1: Initiate Mitigation Action (Quarantine VLAN, Alert)
        MD1->>PE: Mitigation Status
    else Conditional Rule Met
        PE->>AI: Apply Policy on Another Path (e.g., MD2 to CNS)
    end

4. Integration with Emerging Tech

4.1. Derivative: AI-Driven Adaptive Active Inspection and Policy Optimization

Enabling Description:
This derivative enhances US11936693 by integrating Artificial Intelligence (AI), specifically machine learning (ML) models, to dynamically optimize active inspection strategies and policy rule sets.

1. Selecting a reachable resource: An AI-powered resource prioritization module, trained on historical vulnerability data, attack patterns, and business criticality metrics, selects reachable resources and network paths for inspection, focusing on those with the highest potential impact or likelihood of compromise.
2. Actively inspecting the network path: An ML model (e.g., a deep reinforcement learning agent) generates "access instructions" (S320) by dynamically crafting probe payloads and timings. This model learns from past inspection successes and failures, as well as real-time threat intelligence feeds, to identify optimal probing techniques that maximize detection efficacy while minimizing network impact. It adapts to evasive behaviors by target resources.
3. Applying a policy: The policy engine (116) incorporates an AI-driven policy recommender. This ML model, trained on security best practices, compliance frameworks, and an organization's observed risk profile, suggests and refines conditional rules. It can identify patterns in network path vulnerabilities and automatically generate granular policy updates, such as "block all traffic on port 23 for VM-Group-X with observed SSH brute-force attempts."
4. Initiating a mitigation action: An AI-powered automation engine determines the most effective mitigation action (S950) from a predefined playbook. Using contextual data (e.g., asset criticality, current network load, potential blast radius), it predicts the impact of various actions and recommends or automatically executes the least disruptive yet most effective response, e.g., "soft-block" an IP range vs. "hard-shutdown" a compromised resource.
5. Applying the policy on another network path: The AI continuously monitors the effectiveness of applied policies and inspection routines, iteratively optimizing both for newly identified paths and evolving threat landscapes.

flowchart TD
    A[Threat Intelligence & Historical Data] --> B(AI Training Data)
    B --> C(AI Model: Resource Prioritization)
    B --> D(AI Model: Adaptive Probe Generation)
    B --> E(AI Model: Policy Recommender)
    B --> F(AI Model: Mitigation Optimization)

    C --> G(Resource Selector)
    G --> H(Network Paths)
    D --> I(Active Inspector)
    H -- Selected Paths --> I
    I --> J(Inspection Results)
    J --> E(Policy Engine)
    E --> K(Conditional Rule)
    K -- Not Met --> F
    F --> L(Mitigation Action Initiator)
    K -- Met --> M(Policy on Another Path)
    L --> N[Cloud Environment Enforcement]
    M --> G

4.2. Derivative: IoT-Sensor Enhanced Active Inspection with Edge-Based Policy Enforcement

Enabling Description:
This derivative integrates US11936693 with IoT sensors for real-time contextual awareness and pushes active inspection capabilities closer to the network edge.

1. Selecting a reachable resource: IoT sensors deployed throughout the cloud datacenter or hybrid environment (e.g., environmental sensors, network tap sensors, physical access sensors) provide real-time telemetry about resource state, physical security, and local network anomalies. This sensor data enriches the security graph (122) and influences the selection (S905) of "reachable resources" by indicating physical compromises or unusual local network activity around a cloud object.
2. Actively inspecting the network path: Active inspection (S910) is performed not only from external networks but also by distributed "edge active inspectors" deployed on IoT gateways or specialized network security appliances physically co-located with target cloud objects. These edge inspectors perform localized, high-fidelity active probes, leveraging their proximity to detect micro-segmentation failures or side-channel attacks on local network paths, complementing external inspections.
3. Applying a policy: Policies (S915) include conditional rules derived from both external network reachability and real-time IoT sensor data. For example, a policy might state: "if a network path is accessible from the external network AND an IoT physical access sensor detects unauthorized entry to the server rack hosting the virtual machine, THEN trigger immediate isolation."
4. Initiating a mitigation action: Mitigation actions (S950) can be initiated directly by edge devices for rapid local response (e.g., an IoT gateway-based firewall applying a micro-segmentation rule in response to a local network path violation) or escalated to the central policy engine for broader enforcement.
5. Applying the policy on another network path: The system uses aggregated IoT data to identify clusters of resources or paths that require policy re-evaluation or more intensive active inspection.

graph TD
    A[External Active Inspector] --> B[Cloud Load Balancer]
    B --> C[Cloud VM / Resource]
    
    SubGraph Edge Inspection & IoT Context
        D[IoT Gateway / Edge Active Inspector]
        E[Physical Access Sensor]
        F[Network Tap Sensor]
        G[Environmental Sensor]
    End
    
    D -- Local Probes --> C
    E --> D
    F --> D
    G --> D
    
    D --> H[Central Policy Engine]
    C -- Network Response --> D
    C -- Network Response --> B
    
    H -- Policy Rules --> D
    H -- Policy Rules --> A
    
    H --> I{Conditional Rule Met? (External & IoT Context)}
    I -- No --> J[Mitigation Action (Edge/Central)]
    I -- Yes --> K[Evaluate Next Path]

4.3. Derivative: Blockchain-Anchored Active Inspection Results and Immutable Policy Auditing

Enabling Description:
This derivative integrates blockchain technology to ensure the immutability and verifiable integrity of active inspection results and policy application records.

1. Selecting a reachable resource: The selection process (S905) and the definition of network paths are transparently recorded on a private or consortium blockchain as cryptographic hashes of the security graph state, providing an auditable history of the scope of inspection.
2. Actively inspecting the network path: After active inspection (S910) determines a network path's accessibility, the inspection results (e.g., successful access, error codes, timestamps, specific probe details) are cryptographically signed by the active inspector (125) and then hashed into a transaction. This transaction is added to a distributed ledger (blockchain) as an immutable record of the path's accessibility status at that point in time. This prevents tampering with inspection reports.
3. Applying a policy: Each instance of policy application (S915), including the specific policy rule, the target network path, and the outcome of the conditional rule evaluation, generates a signed transaction that is recorded on the blockchain. This creates an unalterable audit trail of all policy decisions.
4. Initiating a mitigation action: The initiation of any mitigation action (S950) is similarly recorded as a blockchain transaction, including the action taken, the timestamp, and the enforcing entity. This provides verifiable proof of remediation efforts for compliance and forensic purposes.
5. Applying the policy on another network path: The continuous policy evaluation and application loop has its state transitions (e.g., moving to the next path) also hashed and recorded, maintaining a complete and tamper-proof log of the entire security governance process. Smart contracts on the blockchain can be used to automatically trigger audits or alerts if specific policy conditions or mitigation states are not met within defined timeframes.

sequenceDiagram
    participant AI as Active Inspector
    participant PE as Policy Engine
    participant BC as Blockchain Network
    participant Res as Cloud Resource
    
    AI->>Res: Active Inspection Probe
    activate Res
    Res-->>AI: Inspection Response
    deactivate Res
    AI->>BC: Record Inspection Result (Signed Hash)
    BC->>BC: Validate & Add Block (Inspection Result)
    AI->>PE: Report Result & Path ID
    PE->>PE: Evaluate Policy Rule
    PE->>BC: Record Policy Application Decision (Signed Hash)
    BC->>BC: Validate & Add Block (Policy Decision)
    alt Rule Not Met
        PE->>AI: Initiate Mitigation Action
        AI->>BC: Record Mitigation Action (Signed Hash)
        BC->>BC: Validate & Add Block (Mitigation Action)
    else Rule Met
        PE->>PE: Select Next Path
    end

5. The "Inverse" or Failure Mode

5.1. Derivative: Graceful Degradation of Active Inspection during Network Congestion

Enabling Description:
This derivative focuses on the "failure mode" where the active inspection process itself could negatively impact the target production environment, particularly during periods of high network congestion or resource strain. The system is designed for graceful degradation to prevent self-inflicted denial of service.

1. Selection of reachable resource (S905) and active inspection (S910): The active inspector (125) continuously monitors the network health and resource utilization of the cloud environment (110) it is inspecting, potentially via SNMP, flow data (NetFlow/sFlow), or cloud provider metrics APIs.
2. Dynamic Adjustment of Inspection Intensity: If predefined thresholds for network latency, packet loss, CPU utilization of target resources, or API rate limits are exceeded, the active inspector automatically enters a "low-impact mode." In this mode, the frequency of active inspection probes is reduced (e.g., from hourly to daily), the number of concurrent probes is limited, or the type of probes shifts from aggressive port scanning to passive listening or credential-less checks (e.g., HTTP HEAD requests instead of full GETs).
3. Policy application (S915): Policies are updated to include conditional rules related to operational impact. For example, "if network path accessibility check causes more than 5% CPU spike on target VM, then suspend aggressive probing for 24 hours."
4. Mitigation action (S950): A mitigation action in this context would be the immediate cessation of active probing for affected resources/paths and the generation of an internal alert to the security operations center (SOC) that inspection is degraded, rather than a security vulnerability mitigation.
5. Resumption of full inspection: Once network/resource conditions return to normal, the system automatically transitions back to full active inspection, potentially prioritizing paths that were skipped during the degradation period.

stateDiagram-v2
    [*] --> Initialized
    Initialized --> Full_Inspection: Normal Operation
    Full_Inspection --> Monitor_Environment: Continuously
    Monitor_Environment --> Degraded_Inspection: High Congestion / Resource Strain
    Degraded_Inspection --> Low_Impact_Probes: Reduced Frequency/Intensity
    Degraded_Inspection --> Monitor_Environment: Continuously (Low Impact)
    Low_Impact_Probes --> Full_Inspection: Congestion Cleared / Resources Available
    Degraded_Inspection --> Full_Inspection: Manual Override

5.2. Derivative: "Stealth Mode" Active Inspector for Evasion Resistance

Enabling Description:
This derivative describes an "inverse" approach where the active inspector (125) operates in a "stealth mode" to avoid detection by advanced intrusion detection systems (IDS), intrusion prevention systems (IPS), or honeypots within the target cloud environment. The goal is to simulate sophisticated attacker behavior without triggering alarms.

1. Selecting a reachable resource (S905) and actively inspecting the network path (S910): The active inspector's probe generation module is augmented with evasion techniques. This includes:
   • Traffic Normalization: Mimicking legitimate traffic patterns (e.g., emulating specific user agents, varying inter-packet delays, using common ports).
   • Fragmentation/Reassembly Obfuscation: Sending fragmented packets or out-of-order segments to bypass stateless firewalls.
   • Slow Scan Techniques: Employing extremely slow port scanning (e.g., one port per hour) to avoid exceeding IDS thresholds.
   • Distributed Probing: Utilizing a large pool of rotating source IP addresses (e.g., through a network of compromised proxies or a botnet simulator) to distribute probes over time and source, making correlation difficult.
   • Protocol Fuzzing (Benign): Sending slightly malformed but non-malicious protocol headers to test resilience and unique responses without causing crashes.
2. Policy application (S915): Policies in this context would include rules like "an accessible network path should NOT be detectable by common IDS signatures for active scanning" or "successful stealth-mode access confirms a significant vulnerability for advanced persistent threats (APTs)."
3. Mitigation action (S950): If the stealth-mode active inspection is detected by a simulated IDS/IPS (or by the environment's actual defenses during a test), the mitigation action might be to immediately cease probing from that source IP, switch to a different evasion technique, or generate an alert indicating the effectiveness of the target's defensive controls against advanced scanning.
4. Application on another path: The effectiveness of different stealth techniques is continuously evaluated, and the most successful (undetected) methods are prioritized for subsequent path inspections.

flowchart LR
    A[Threat Intelligence] --> B(Evasion Technique Library)
    B --> C(Stealth Active Inspector Core)
    C -- Select Evasion Technique --> D(Probe Generator)
    D -- Stealth Probes (Low Rate, Obfuscated, Distributed) --> E[Network Path to Cloud Resource]
    E -- Network Response --> D
    D --> F(Response Analyzer - Detects IDS/IPS Alerts)
    F --> G{Detected?}
    G -- Yes --> H[Mitigation Action: Switch Evasion / Cease Probing]
    G -- No --> I[Policy Evaluator (Vulnerability Confirmed)]
    I --> J[Apply Policy on Another Path (with Stealth)]

Combination Prior Art Scenarios

Here are at least three scenarios combining US11936693 with existing open-source standards to demonstrate obviousness of future advancements.

1. Integration with Open Policy Agent (OPA)

Combination Scenario: A system implementing the active inspection and policy application of US11936693, where the "policy engine" (116) and its "conditional rules" (S915) are realized using the Open Policy Agent (OPA) standard and its Rego policy language.

Enabling Description:
The "policy engine" (116) of US11936693 is replaced or augmented by an OPA instance. Network path reachability data, including details from active inspection (S910) such as open ports, protocols, discovered applications, and associated resource metadata (e.g., cloud object type, tags, VPC ID), is transformed into JSON input for OPA. Conditional rules (S915) are defined as Rego policies. For example, a Rego policy could express: allow_external_ssh_access = false if { input.network_path.accessible == true; input.network_path.port == 22; not input.resource.tags.critical_bastion == true }. The active inspector (125) feeds inspection results to OPA, which then evaluates the Rego policies. If an OPA query returns false (policy violation), OPA's decision output triggers the "mitigation action" (S950) defined by the patent, such as calling a cloud API to close a security group port or generate an alert. This combination leverages OPA's declarative policy language and robust evaluation capabilities for managing complex security postures on actively validated network paths.

flowchart TD
    A[Active Inspector] -- Inspection Results (JSON) --> B(Open Policy Agent - OPA)
    B -- Rego Policy Rules --> C{Policy Data (Cloud Resource Metadata)}
    C --> B
    B -- Policy Decision (Allow/Deny) --> D{Conditional Rule Met?}
    D -- No --> E[Mitigation Action Initiator]
    D -- Yes --> F[Apply Policy on Another Path]
    E --> G[Cloud Enforcement APIs]

2. Integration with Kubernetes Network Policies and Operators

Combination Scenario: Applying the active inspection and policy enforcement framework of US11936693 to a Kubernetes-managed cloud computing environment, leveraging Kubernetes Network Policies and custom Operators for mitigation actions.

Enabling Description:
In this scenario, "reachable resources" (S905) are Kubernetes Pods, Deployments, or Services exposed to an "external network" (e.g., through an Ingress controller or Load Balancer). The "active inspector" (125) targets the external IP addresses and ports exposed by Kubernetes Services. After actively inspecting (S910) a network path and determining its accessibility, the "policy engine" (116) evaluates conditional rules. These conditional rules (S915) could be defined in terms of desired Kubernetes Network Policies. For example, a policy might state: "Only Pods with label app=frontend should have external ingress on port 80/443." If active inspection reveals a backend database Pod (without app=frontend label) is externally accessible on port 5432, a "mitigation action" (S950) is initiated by dynamically generating and applying a Kubernetes Network Policy via the Kubernetes API (e.g., restricting ingress to the database Pod). This could be managed by a custom Kubernetes Operator that observes active inspection results and reconciles them with desired Network Policy states. If the initial policy is met, the system moves to apply the policy on another network path within the Kubernetes cluster.

graph TD
    A[External Active Inspector] --> B(Kubernetes Ingress/LoadBalancer)
    B --> C[Kubernetes Service/Pod (Reachable Resource)]
    C -- Network Traffic --> B
    
    AI[Active Inspector (Controller)] -- Inspection Results --> PE[Policy Engine (Kubernetes Operator)]
    PE -- Conditional Rule Check --> NP[Kubernetes Network Policies]
    PE -- Desired State --> KAPI[Kubernetes API Server]
    KAPI -- Apply/Update --> NP
    
    A --> AI
    C --> AI
    
    PE -- Rule Not Met --> MA[Mitigation Action: Update Network Policy]
    PE -- Rule Met --> AP[Apply Policy on Another K8s Path]
    
    MA --> KAPI
    AP --> AI

3. Integration with Apache Metron (Network Security Monitoring) for Enhanced Context

Combination Scenario: Combining US11936693's active inspection capabilities with Apache Metron's network security monitoring and enriched data for better contextual policy enforcement.

Enabling Description:
In this scenario, "reachable resources" (S905) and their "network paths" are identified by US11936693's static analysis and active inspection. However, the decision-making for "applying a policy" (S915) and "initiating a mitigation action" (S950) is heavily informed by data enriched and analyzed by Apache Metron. Metron ingests various data sources (e.g., NetFlow, firewall logs, IDS alerts, DNS queries) from the "cloud computing environment" (110) and the "external network" (130). The "active inspector" (125) feeds its inspection results (e.g., "port 22 on 10.0.0.1.256 is actively open and responds to SSH probes") into Metron as a new data source. Metron's enrichment topologies correlate this active inspection data with passive monitoring data (e.g., "SSH traffic has been observed from this IP historically," "no legitimate SSH activity expected on this VM"). The "conditional rules" (S915) of the policy engine (116) are thus contextually richer: "if active inspection confirms external reachability on port 22 AND Metron's behavioral analytics indicates anomalous SSH activity AND the resource is not tagged as an SSH bastion host, THEN initiate mitigation." This provides a more intelligent and less false-positive-prone policy enforcement system. Mitigation actions (S950) could also be informed by Metron's alert prioritization, ensuring critical threats get immediate attention.

graph TD
    A[Cloud Environment (Firewall Logs, NetFlow, IDS)] --> B(Apache Metron Ingest)
    AI[Active Inspector] -- Inspection Results --> B
    B --> C(Apache Metron Enrichment & Analytics)
    C --> D[Policy Engine]
    D -- Conditional Rules (Contextual) --> E{Metron-Enriched Data}
    E --> D
    D --> F{Conditional Rule Met?}
    F -- No --> G[Mitigation Action (Prioritized by Metron)]
    F -- Yes --> H[Apply Policy on Another Path]
    G --> I[Cloud Enforcement / SOC Alert]