US 11722554

US Patent 11722554, titled "System and method for analyzing network objects in a cloud environment," was granted to Wiz Inc. The inventors are Shai Keren, Danny Shemesh, Roy Reznik, Ami Luttwak, and Avihai Berkovitz. The patent was filed on August 12, 2022, and issued on August 8, 2023.

Abstract:
The patent describes a method and system for identifying abnormal configurations of network objects within a cloud computing environment. This involves collecting data on various network objects, building a network graph (which includes a visual representation of these objects), determining the relationships and connections between them, and then analyzing this graph and relationships to produce insights. These insights specifically include a list of abnormal connections between the identified network objects.

Independent Claims Overview:

• Independent Claim 1 (Method Claim): This claim outlines a method for detecting abnormal configurations of network objects in a cloud environment. It involves collecting data about network objects, creating a visual network graph from this data, identifying relationships (connections) between the objects in the graph, analyzing these relationships and the graph to generate "insights" (which must include abnormal connections), and finally, tagging the network objects for which insights are generated.
• Independent Claim 11 (Non-Transitory Computer Readable Medium Claim): This claim is for a non-transitory computer-readable medium that stores instructions. When these instructions are executed by processing circuitry, they cause the circuitry to perform the same method steps as described in Claim 1: collecting network object data, constructing a visual network graph, determining relationships between identified objects, analyzing the graph and relationships to generate insights (including abnormal connections), and tagging the relevant network objects.
• Independent Claim 12 (System Claim): This claim describes a system designed to detect abnormal network object configurations in a cloud environment. The system comprises processing circuitry and memory containing instructions. When executed by the circuitry, these instructions configure the system to perform the same steps as detailed in Claim 1: collecting network object data, building a visual network graph, identifying relationships between objects, analyzing the graph and relationships to produce insights (including abnormal connections), and tagging network objects associated with the insights.

Litigation Search:
As of April 26, 2026, a search of CAFC 2026 dockets for US Patent 11722554 or the assignee Wiz Inc. did not yield any explicit docket entries in the provided search results. The patent text itself indicates a PTAB case, IPR2025-01083, was filed but "Not Instituted - Merits."

Known litigation involving US patent 11722554 includes the following:

PTAB Case:

• Case Number: IPR2025-01083
• Plaintiff(s): Orca Security Ltd.
• Defendant(s): Wiz Inc.
• Jurisdiction: Patent Trial and Appeal Board (PTAB)
• Filing Date: 2025-06-04
• Outcome/Current Status: Not Instituted - Merits (as of 2025-12-15)

The patent itself also indicates "First worldwide family litigation filed" with a link to Darts-ip (patents.darts-ip.com/?family=83007647&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US11722554(B2)). However, specific details such as plaintiff(s), defendant(s), jurisdiction, case number, filing date, and outcome or current status for this worldwide family litigation were not directly retrievable from the provided search results.

Proceedings overview

There is one AIA trial proceeding on file for US Patent 11722554, with a status of "Institution Denied." This indicates that the patent has survived a challenge at the PTAB, which strengthens its defensive posture as none of its claims have been invalidated.

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

• Type: Inter Partes Review
• Filed: 2025-06-04
• Status: Institution Denied. The PTAB declined to institute the inter partes review.
• Judge panel: KARL D. EASTHOM, NABEEL U. KHAN, and LISA A. MURRAY, Administrative Patent Judges.
• Petition grounds: The petition challenged claims of the '554 patent. The specific prior art and statutory bases (§ 102 / § 103 / § 112) for the challenge are not explicitly detailed in the provided search results, beyond a general reference to "unpatentability of the claims challenged in the Petition".
• Institution decision: Denied — 2025-12-15. The PTAB determined that the petitioner, Orca Security Ltd., did not demonstrate a "reasonable likelihood that the petitioner would prevail with respect to at least 1 of the claims challenged in the petition" under 35 U.S.C. § 314(a).
• Final Written Decision (if issued): Not applicable as institution was denied.
• Settlement / termination: The related district court litigation between Orca Security Ltd. and Wiz Inc. was dismissed with prejudice on January 7, 2026, with each side bearing its own legal costs and attorneys' fees. This suggests a broader settlement or resolution between the parties, although the specific terms regarding IPR2025-01083 are confidential if they extend beyond the dismissal of the district court case.
• Appeal: No Federal Circuit appeal on this specific IPR decision as institution was denied. Appeals typically follow a Final Written Decision.
• Defensive value: The denial of institution for IPR2025-01083 means that all claims of US11722554 that were challenged in this petition remain intact and have not been invalidated by the PTAB. This strengthens the patent owner's position, as this particular attempt to invalidate the patent was unsuccessful. Any future challenger would need to present new and compelling arguments to overcome this prior denial of institution.

Strategic summary

All claims of US11722554 remain SUSTAINED as the single IPR proceeding filed against it resulted in a denial of institution. This means that no claims of the patent were canceled or narrowed through this PTAB challenge.

The estoppel landscape for US11722554 is favorable to the patent owner. Since institution was denied in IPR2025-01083, the petitioner, Orca Security Ltd., and its privies would likely be estopped under 35 U.S.C. § 315(e)(1) from asserting in future district court actions or other PTAB proceedings any ground of invalidity that it raised or reasonably could have raised during the IPR petition process against the challenged claims. This significantly limits the prior-art grounds available to Orca Security Ltd. should they attempt another challenge on the same claims.

The context of this IPR suggests a pattern of defensive action by Wiz Inc. against Orca Security Ltd. in a broader patent dispute. Wiz Inc. also challenged the validity of Orca's patents through IPRs, successfully having claims in three of Orca's patents found unpatentable, which contributed to the dismissal of their dueling lawsuits. The IPR on US11722554 was part of Orca's counter-petitions against Wiz's patents.

Recommended next steps

As a defendant currently facing assertion of this patent, the denial of institution for IPR2025-01083 is a positive signal. While the full institution decision document for IPR2025-01083 (Paper 12) would provide the detailed reasoning of the PTAB panel, the publicly available information confirms that the petition was denied. This means that, for the claims challenged in this IPR, the patent owner has successfully defended against a PTAB validity challenge. If your demand letter cites claims that were part of this IPR, the patent owner would likely assert that the PTAB has already reviewed and implicitly affirmed the patentability of those claims by denying institution. You should review the specific claims challenged in IPR2025-01083 to understand the exact scope of the PTAB's decision.

Inventors

• Shai Keren
• Danny Shemesh
• Roy Reznik
• Ami Luttwak
• Avihai Berkovitz

Employer at time of filing: All inventors are associated with Wiz Inc. based on the current assignee information and the filing date.

Original assignee

The entity named on the issued patent is Wiz Inc.

Wiz Inc. is a cybersecurity company that provides cloud security solutions, including a "Cloud Native Application Protection Platform (CNAPP)" which likely embodies aspects of the claimed "System and method for analyzing network objects in a cloud environment."
Current status: Operating.

Assignment timeline

The USPTO Assignment Center (https://assignmentcenter.uspto.gov/patent/index.html) has no recorded post-issuance assignments for US11722554.

Timeline diagram

timeline
    title Ownership of US 11722554
    2020 : Priority Date
    2022 : Filed by Wiz Inc
    2023 : Issued to Wiz Inc

NPE / troll-pattern signals

1. Shell-entity transfer — not present
2. Known asserter in the chain — not present
3. Repeat correspondent across the chain — not present
4. Cascading transfers — not present
5. Pre-litigation transfer — not present
6. Bankruptcy fire-sale — not present
7. Privateering — unclear
8. Defensive aggregator (anti-NPE) — not present

Verdict

Insufficient data
There are no recorded assignments for US11722554 in the USPTO Assignment Center (https://assignmentcenter.uspto.gov/patent/index.html). Therefore, there is insufficient data to determine any NPE or troll-pattern signals beyond the original assignment to Wiz Inc.

To identify the most relevant prior art for US Patent 11722554, I will examine the patent's cited references. A prior art reference anticipates a claim under 35 U.S.C. § 102 if it discloses every element of the claimed invention, either expressly or inherently, in a single reference.

Here are the prior art references cited in US Patent 11722554:

Cited U.S. Patent Documents:

• US11431786B1

  • Full Citation: US 11,431,786 B1
  • Publication/Filing Date: Publication date: September 6, 2022. Filing date: December 2, 2020.
  • Brief Description: This patent shares a similar title, "System and method for analyzing network objects in a cloud environment." It describes a system and method for determining abnormal configuration of network objects in a cloud environment by collecting data, constructing a network graph with visual representation, determining relationships, analyzing the graph to generate insights (including abnormal connections), and tagging network objects. This patent is explicitly identified as a continuation of U.S. patent application Ser. No. 17/109,883, filed Dec. 2, 2020, which is the parent application for US11722554B2.
  • Potential Anticipated Claims: Given that US11722554B2 is a continuation of US17/109,883 (which matured into US11431786B1), US11431786B1 is highly likely to anticipate all claims (Claims 1-10, and 11-21) of US11722554B2 that were present in the parent application and not substantively changed. Specifically, the abstract and independent claims of US11431786B1 appear to disclose all elements of independent claims 1, 11, and 12 of US11722554B2. Therefore, it potentially anticipates claims 1-21.

• US20220394082A1

  • Full Citation: US 2022/0394082 A1
  • Publication/Filing Date: Publication date: December 8, 2022. Filing date: August 12, 2022.
  • Brief Description: This is a patent application with a similar title and abstract to US11722554B2, describing a method and system for determining abnormal configuration of network objects in a cloud computing environment. It was published before US11722554B2 and shares the same filing date and inventors. This is the published application for US11722554B2.
  • Potential Anticipated Claims: As this is the published application for US11722554B2, it directly corresponds to the granted patent. Therefore, it would anticipate all claims (Claims 1-21) if its publication date precedes the effective filing date of any newly added claims in US11722554B2 not present in the original application. However, since it is the application that led to this patent, it is typically cited for continuity rather than as anticipatory prior art in the traditional sense, unless there were specific claim amendments that changed the scope significantly and introduced new matter not present in the application as filed.

To perform a complete analysis for anticipation under 35 U.S.C. § 102, a detailed comparison of each claim of US11722554B2 against the full disclosure of each prior art reference would be necessary, focusing on whether every element of a claim is found in a single prior art reference. Given the direct relationship between US11722554B2 and US11431786B1 (continuation) and US20220394082A1 (published application), these documents represent very close prior art.

A Person Having Ordinary Skill in the Art (POSA) in the context of US Patent 11722554 would be an individual with practical experience and knowledge in network administration, cloud computing, cybersecurity, and data visualization or graph theory. This individual would be familiar with existing tools and methods for managing and analyzing network infrastructure, particularly in distributed cloud environments.

The background section of US11722554 describes various existing network analysis solutions and their limitations, which a POSA would be aware of and motivated to overcome. These descriptions serve as the basis for identifying prior art concepts for the purpose of this obviousness analysis.

Prior Art References (as described in US11722554 Background):

• Reference A (Manual and Specialized Network Analysis): This includes "manual review of devices, connections, and networks" and "solutions directed to the monitoring of specific device types, such as, for example, firewall control systems," or "protocol-specific analysis solutions." These solutions are noted for being thorough for individual elements but prohibitive for large networks, or failing to provide streamlined monitoring for diverse devices and protocols.
• Reference B (Protocol-Agnostic Traffic Management): These solutions "provide for overall traffic management" but are criticized for being "over-broad, providing irrelevant or redundant information," requiring "specification of connections to monitor," and failing to provide "device-specific insights" or "integrated device and connection analysis."
• Reference C (Cloud Network Complexity and Vulnerabilities): The general state of "large, multi-layered network systems," particularly "code-to-cloud systems" in "cloud environments," which are increasingly vulnerable to "cyber-threats" and present difficulties in "management of network access and use." This reference highlights the problem space the invention seeks to address.
• Reference D (Graph Representation and Relationships): The core concept of representing networks as graphs with interconnected objects and relationships is implicitly acknowledged by the patent's "Prior art keywords" (network, objects, graph, relationships, identified) and is a foundational aspect of network engineering.
• Reference E (Data Tagging): The general concept of associating labels or tags with data or objects for organization, categorization, searching, and filtering is a well-known technique in data management and information retrieval. The patent itself describes tagging as enabling "enriched querying."

Obviousness Analysis under 35 U.S.C. § 103:

The independent claims of US11722554, such as Claim 1, outline a method for determining abnormal configurations by: (1) collecting network object data in a cloud environment; (2) constructing a visual network graph; (3) determining relationships; (4) analyzing to generate insights (abnormal connections); and (5) tagging network objects for which insights are generated. A POSA would have found it obvious to combine the prior art references described above to arrive at the claimed invention, driven by the explicit problems identified in the patent's background.

Combination 1: Reference A + Reference B + Reference C + Reference D (Covers Claim 1, elements 1-4)

• Motivation: A POSA, faced with the significant challenges of managing and securing "large, distributed network systems" and "multi-layer network systems" in "cloud environments" (Reference C), would immediately recognize the limitations of existing "manual review," "specific device type monitoring," "protocol-specific analysis" (Reference A), and "protocol-agnostic solutions" (Reference B). These prior art approaches are described as insufficient for integrated analysis, often providing irrelevant information, or being too time-consuming.
  • To overcome these deficiencies, a POSA would be motivated to adopt a more comprehensive and visual approach. Representing complex networks using a "network graph" (Reference D) is a known and intuitive method for visualizing interconnections and relationships. Therefore, it would be obvious to take the network object data collected by existing methods (Reference A and B's data collection aspects) and use it to "construct a network graph" (Claim 1, element 2) that includes a "visual representation of network objects" to better understand the network's topology and "determine relationships between the identified network objects" (Claim 1, element 3).
  • Once a comprehensive graph is available, the natural progression for a POSA concerned with "new vulnerabilities" and "management of network access and use" (Reference C) would be to "analyze the network graph and the determined relationships to generate insights" (Claim 1, element 4). This analysis would specifically target "abnormal connections" to address the critical security and configuration issues that prior art solutions failed to adequately detect or integrate. The patent's background explicitly calls out the failure of prior solutions to provide "device-specific insights" and "integrated device and connection analysis," directly motivating the claimed analysis step.

Combination 2: Combination 1 + Reference E (Covers Claim 1, element 5)

• Motivation: Having generated valuable insights, such as lists of abnormal connections, from the network graph analysis, a POSA would seek to make these insights actionable and easily manageable. In any system dealing with large amounts of data or numerous objects, "tagging" or labeling (Reference E) is a conventional and well-understood technique for categorization, organization, search, and filtering. The patent itself states that "tagging of network objects at S 250 may provide for enriched querying of graphs."
  • Therefore, it would be obvious for a POSA to apply this known data management technique to "tag network objects in the network graph for which the insight is generated" (Claim 1, element 5). This step directly enhances the utility of the generated insights, allowing administrators to efficiently query, filter, and track specific abnormal configurations or vulnerabilities identified by the system, thereby improving overall network security and administration.

In conclusion, the claimed invention, while addressing a real problem in cloud network security, combines known elements in a manner that would have been obvious to a POSA. The motivation for combining these elements is clearly articulated within the patent's own background section, which highlights the shortcomings of existing network analysis techniques and the pressing need for improved visibility and anomaly detection in complex, distributed cloud environments.

To provide a comprehensive overview of patent term adjustments, extensions, family members, and expiration date for US patent 11722554, I will use information available through the USPTO.

Patent Term Adjustments (PTA)

Patent Term Adjustment (PTA) can extend the term of a patent to compensate for delays caused by the USPTO during the prosecution of a utility or plant patent application. These delays can include:

• Failure to issue a first Office Action or notice of allowance within 14 months of filing.
• Failure to respond to an applicant's reply to an Office Action within four months.
• Failure to issue a patent within four months of the payment of the issue fee.
• The application being pending for more than three years, with certain exclusions for applicant-caused delays.

Applicant delays can reduce any awarded PTA. The patent document itself or the USPTO Patent Center would provide the specific PTA calculation for US11722554.

Patent Term Extensions (PTE)

Patent Term Extensions (PTE) are distinct from PTA and are generally available for patents claiming products (e.g., human drugs, medical devices, food additives, veterinary biological products) that require premarket regulatory approval from agencies like the FDA. This extension aims to restore patent term lost during the regulatory review process. There is no indication in the provided patent text that US11722554 relates to such products. Therefore, it is highly unlikely to have a PTE.

Continuation and Divisional Applications

The patent text for US11722554 explicitly states that it is a continuation of U.S. patent application Ser. No. 17/109,883, filed on December 2, 2020.

• A continuation application is a second application for the same invention claimed in a prior-filed, co-pending nonprovisional application. It allows for new claims to be introduced and for further examination by the USPTO.
• Divisional applications arise when an earlier application claimed two or more independent and distinct inventions.

The provided information indicates that US11722554 is a continuation, but does not explicitly mention any divisional applications.

Related Family Members

The patent states that US11722554 is a continuation of U.S. patent application Ser. No. 17/109,883. The Google Patents page for US11722554 also lists several "Priority Applications" and "Applications Claiming Priority," all stemming from the December 2, 2020, priority date. These include:

• US17/819,442 (which is US11722554B2 itself).
• US18/341,134, which led to US12381939B2.
• US18/478,534, which led to US11985185B2.
• US18/479,573, which led to US12273412B2.
• US18/887,753, which led to US12192270B1.
• US18/888,981, which led to US12255948B2.
• US19/047,259, which led to US20250358330A1.

Additionally, US17/109,883 led to US11431786B1. This demonstrates a robust patent family built around the initial December 2, 2020, priority date.

Projected Expiration Date

The term of a U.S. utility patent generally expires 20 years from the earliest filing date of the patent application, or the earliest filing date of a parent application to which it claims priority. Any PTA would extend this term.

For US11722554, the priority date is December 2, 2020. Therefore, the anticipated expiration date, before any Patent Term Adjustments, would be December 2, 2040. The Google Patents page for US11722554 lists an "Anticipated expiration" date of 2040-12-02, which aligns with the 20-year term from the priority date. Without access to the specific PTA calculation from the USPTO for patent 11722554, it is not possible to provide a definitively adjusted expiration date.

Here are derivative variations and combination prior art scenarios for US Patent 11722554, framed as a Defensive Disclosure.

---

Defensive Disclosure for US Patent 11722554

Introduction

This document outlines several derivative works and combinations with existing open-source standards related to US Patent 11722554, "System and method for analyzing network objects in a cloud environment." The purpose is to broaden the scope of prior art, potentially rendering future incremental improvements by competitors as obvious or non-novel to a person skilled in the art. The analysis focuses on extending the core claims, particularly Independent Claim 1, across various technical axes.

Derivative Variations

1. Material & Component Substitution: Hardware-Accelerated Graph Processing for Real-time Analysis

• Enabling Description: The network graph construction (S220), relationship determination (S230), and graph analysis for insight generation (S240) steps can be significantly accelerated through the deployment of specialized hardware. Specifically, Field-Programmable Gate Arrays (FPGAs) or Application-Specific Integrated Circuits (ASICs) are integrated into the processing circuitry (410) of the cyber-security system (150). These accelerators are configured to perform parallel computations on graph data structures, such as adjacency matrices or lists, for operations like shortest-path algorithms, centrality calculations, and pattern matching for anomaly detection. For instance, an FPGA fabric can be programmed with custom data paths to execute a breadth-first search (BFS) or depth-first search (DFS) across millions of graph nodes and edges in microsecond latency. The data collection (S210) from cloud provider APIs remains software-driven, but the subsequent graph processing pipelines are offloaded to these hardware units, allowing for real-time anomaly detection in large-scale cloud environments. The FPGAs would be reprogrammable to adapt to evolving graph schemas or new anomaly detection algorithms.

• Mermaid Diagram:

  flowchart TD
      A[Collect Network Object Data (S210)] --> B{Hardware-Accelerated Graph Construction (S220)}
      B -- Graph Data Stream --> C{FPGA/ASIC-based Relationship Determination (S230)}
      C -- Processed Graph Edges --> D[Parallel Graph Analysis for Insights (S240)]
      D --> E[Tag Network Objects (S250)]
  
      subgraph Cyber-Security System 150 (FIG. 4)
          A
          B
          C
          D
          E
      end
  
      subgraph Hardware Acceleration Module
          FPGA[FPGA Array / Custom ASIC]
          GPU[GPU (optional for ML-based analytics)]
      end
  
      C -. utilizes .-> FPGA
      D -. utilizes .-> GPU
  

2. Material & Component Substitution: Quantum-Resistant Cryptographic Modules for Secure Data Ingestion

• Enabling Description: To future-proof the secure collection of network object data (S210) from diverse cloud computing platforms (Claim 2) via APIs (Claim 3), the cyber-security system (150) and cloud orchestrators (115) incorporate quantum-resistant cryptographic modules. These modules, implemented as dedicated hardware security modules (HSMs) or software libraries utilizing post-quantum cryptography (PQC) algorithms (e.g., lattice-based cryptography such as CRYSTALS-Kyber for key exchange, or hash-based signatures like XMSS/SPHINCS+ for authentication), encrypt and authenticate API requests and responses. This ensures the confidentiality and integrity of highly sensitive cloud configuration data and network object metadata during transit, safeguarding against potential compromise by future quantum computers. The network interface (440) of the cyber-security system (150) would feature these PQC-enabled communication stacks.

• Mermaid Diagram:

  sequenceDiagram
      participant CSS as Cyber-Security System 150
      participant QRCM_CSS as Quantum-Resistant Cryptographic Module (CSS)
      participant CloudAPI as Cloud Platform API
      participant QRCM_Cloud as Quantum-Resistant Cryptographic Module (Cloud)
      participant Orchestrator as Orchestrator 115
  
      CSS->>QRCM_CSS: Initiate Data Collection Request (S210)
      QRCM_CSS->>CloudAPI: Encrypt & Sign Request (PQC)
      CloudAPI->>QRCM_Cloud: Forward Encrypted Request
      QRCM_Cloud->>Orchestrator: Decrypt & Verify Request
      Orchestrator->>QRCM_Cloud: Generate & Sign Data Response (PQC)
      QRCM_Cloud->>CloudAPI: Encrypt & Sign Response
      CloudAPI->>QRCM_CSS: Transmit Encrypted Response
      QRCM_CSS->>CSS: Decrypt & Verify Response; Deliver Data
  

3. Operational Parameter Expansion: Ultra-Low Latency, Micro-Segmentation Policy Validation

• Enabling Description: This derivative pushes the operational speed and granularity to extremes, focusing on validating micro-segmentation policies within highly dynamic, containerized cloud environments (e.g., Kubernetes deployments mentioned in the description). The network object data collection (S210) would occur at sub-millisecond intervals via eBPF (extended Berkeley Packet Filter) probes deployed directly on host kernels, capturing granular flow data and process-level network calls. The network graph (S220) would be a continuously updated, ephemeral, in-memory graph representing inter-process and inter-container communication flows. Relationship determination (S230) would involve real-time policy evaluation against a predefined micro-segmentation matrix, identifying unauthorized deviations from "least privilege" access in near real-time. Insights (S240) would pinpoint policy violations within 10-50 microseconds of occurrence, facilitating automated enforcement. Tagging (S250) would immediately label offending processes or containers with "policy-violation" or "quarantine" tags. This requires specialized, high-throughput network interfaces (440) and processing circuitry (410) optimized for parallel stream processing.

• Mermaid Diagram:

  sequenceDiagram
      participant HostKernel as Host Kernel (eBPF)
      participant CNOC as Containerized Network Object
      participant ELDC as Ultra-Low Latency Data Collector (S210)
      participant IMGDB as In-Memory Graph DB (S220)
      participant RTPV as Real-Time Policy Validator (S230)
      participant ULRIG as Ultra-Low Latency Insight Generator (S240)
      participant ANOMTAG as Anomaly Tagger (S250)
      participant Enforcer as Automated Policy Enforcer
  
      HostKernel->>ELDC: Stream eBPF Flow Data (<10µs)
      CNOC->>ELDC: Push Config Updates
      ELDC->>IMGDB: Update Ephemeral Graph (<20µs)
      IMGDB->>RTPV: Notify Graph Change Event
      RTPV->>ULRIG: Identify Policy Violation (<50µs)
      ULRIG->>ANOMTAG: Generate & Apply "Policy_Violation" Tag
      ANOMTAG->>Enforcer: Trigger Enforcement Action
      Enforcer->>HostKernel: Apply Network Rule / Quarantine
  

4. Operational Parameter Expansion: Multi-Temporal Graph Analysis for Predictive Anomaly Detection

• Enabling Description: This derivative introduces a temporal dimension to the network graph analysis, operating at multiple time scales to enable predictive anomaly detection. Instead of a single snapshot or a continuously updating current graph, the system (150) maintains a series of historical network graphs (S220) at varying fidelities (e.g., hourly, daily, weekly aggregates). Data collection (S210) includes historical configurations and traffic patterns. Relationship determination (S230) then involves comparing the current network graph state and its relationships against these historical baselines. Machine learning models (e.g., recurrent neural networks or time-series analysis) are applied to these multi-temporal graphs to identify trends, predict future "normal" states, and detect deviations that indicate emerging abnormal configurations or events before they fully materialize. Insights (S240) would include "predicted abnormal connection in T+X hours" or "configuration drift detected, likely leading to exposure." Tagging (S250) would include a "predictive_alert" tag with a confidence score and predicted time horizon. This requires vast storage (430) and computational resources for historical graph processing.

• Mermaid Diagram:

  graph TD
      subgraph Cyber-Security System 150
          A[Collect Network Object Data (S210)]
          B[Build Current Network Graph (S220)]
          C[Maintain Historical Graph Archive]
          D[Multi-Temporal Relationship Determiner (S230)]
          E[Predictive Insight Generator (S240)]
          F[Temporal Object Tagger (S250)]
      end
  
      A --> B
      B --> C: Archive Current Graph
      C --> D: Provide Historical Baselines
      B --> D: Provide Current Graph
      D --> E: Detect Anomalous Trends/Predictions
      E --> F: Tag with Prediction Metadata
      F -- "Predicted Anomaly Alerts" --> G[Security Operations]
  

5. Cross-Domain Application: Industrial Control Systems (ICS) and Operational Technology (OT) Networks

• Enabling Description: The system and method are adapted for analyzing the complex and often air-gapped or segmented networks found in Industrial Control Systems (ICS) and Operational Technology (OT) environments (e.g., critical infrastructure like power grids, manufacturing plants). Here, "network objects" (105) would include Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), Human-Machine Interfaces (HMIs), SCADA servers, and specialized industrial protocols (e.g., Modbus/TCP, OPC UA). The "cloud computing environment" (103) would be a segmented industrial DMZ or a secure on-premise industrial data historian. Data collection (S210) would involve passively sniffing industrial network traffic or querying asset management systems, carefully avoiding active interaction with sensitive control devices. The network graph (S220) would represent logical and physical connections within the OT network. Relationship determination (S230) would focus on identifying deviations from expected command flows, unauthorized peer-to-peer communication between control devices, or attempts to modify PLC logic. Insights (S240) would detect abnormal configurations such as a rogue HMI attempting to issue commands, unexpected device-to-device communication, or changes in industrial protocol parameters, with tagging (S250) categorizing threats as "safety_critical" or "operational_integrity_violation."

• Mermaid Diagram:

  graph TD
      subgraph Industrial Control Network (OT)
          PLC1[PLC 1] -- Modbus/TCP --> HMI[HMI Console]
          SCADAS[SCADA Server] -- OPC UA --> PLC2[PLC 2]
          Historian[Data Historian] -- Data Sync --> SCADAS
          IDS[Industrial IDS (Passive Sensor)]
      end
  
      subgraph Cyber-Security System 150 (OT-Optimized)
          OT_Collector[OT Data Collector (S210)]
          OT_Graph[OT Network Graph (S220)]
          OT_Relations[OT Relationship Determiner (S230)]
          OT_Insights[OT Insight Generator (S240)]
          OT_Tagger[OT Object Tagger (S250)]
      end
  
      IDS -- Traffic Mirror --> OT_Collector
      Historian -- Config/Logs --> OT_Collector
      OT_Collector --> OT_Graph
      OT_Graph --> OT_Relations
      OT_Relations --> OT_Insights
      OT_Insights --> OT_Tagger
      OT_Tagger -- "OT Security Alerts" --> ICS_SOC[ICS Security Operations Center]
  

6. Cross-Domain Application: Healthcare Interoperability and Medical Device Networks

• Enabling Description: This invention can be applied to monitoring and securing the complex network of medical devices and healthcare IT systems within a hospital or a regional health network. "Network objects" (105) would include patient monitoring systems, infusion pumps, imaging devices (MRI, CT), Electronic Health Record (EHR) systems, lab equipment, and patient portals. The "cloud computing environment" (103) could be a hospital's private cloud, a hybrid cloud infrastructure for data archiving, or a secure health information exchange (HIE). Data collection (S210) would involve querying device configuration APIs, network access logs, and communication protocols specific to healthcare (e.g., DICOM, HL7). The network graph (S220) would visualize the flow of protected health information (PHI) between devices and systems, the control pathways for medical equipment, and administrative access points. Relationship determination (S230) would identify authorized vs. unauthorized data sharing (e.g., PHI moving to an unapproved endpoint), unusual command patterns to medical devices, or misconfigured access controls on EHR systems. Insights (S240) would flag abnormal configurations such as an infusion pump attempting to communicate with an external IP, an EHR system exposing PHI due to a misconfiguration, or an unauthorized device attempting to join the medical network, with tagging (S250) indicating "PHI_exposure_risk" or "patient_safety_impact."

• Mermaid Diagram:

  graph LR
      subgraph Healthcare Cloud Environment 103
          PMS[Patient Monitoring System] -- HL7 --> EHR[EHR System]
          InfusionP[Infusion Pump] -- DICOM --> ImagingD[Imaging Device]
          LabEq[Lab Equipment] -- Data --> EHR
          PatientPortal[Patient Portal] -- HTTPS --> EHR
      end
  
      subgraph Cyber-Security System 150 (Healthcare-Optimized)
          HC_DC[Healthcare Data Collector (S210)]
          HC_NGB[Healthcare Network Graph (S220)]
          HC_RD[Healthcare Relationship Determiner (S230)]
          HC_IG[Healthcare Insight Generator (S240)]
          HC_OT[Healthcare Object Tagger (S250)]
      end
  
      PMS -- API/Logs --> HC_DC
      EHR -- API/Logs --> HC_DC
      InfusionP -- Logs --> HC_DC
      HC_DC --> HC_NGB
      HC_NGB --> HC_RD
      HC_RD --> HC_IG: Detect PHI Misconfigurations / Device Anomalies
      HC_IG --> HC_OT
      HC_OT -- "Compliance/Security Alerts" --> HospitalSOC[Hospital Security Operations Center]
  

7. Integration with Emerging Tech: AI-Driven Contextual Anomaly Detection with Explainable AI (XAI)

• Enabling Description: This derivative integrates advanced AI, specifically Explainable AI (XAI), into the insight generation (S240) process. Machine learning models, such as Graph Neural Networks (GNNs) or deep learning autoencoders, are used to analyze the network graph and relationships (S230) to identify subtle, non-obvious patterns indicative of abnormal behavior that might be missed by rule-based systems. However, unlike black-box AI, this derivative incorporates XAI techniques (e.g., SHAP values, LIME, attention mechanisms in GNNs) to provide human-understandable explanations for why a particular connection or configuration is flagged as abnormal. For example, an insight (S240) might state: "VM 'Web-App-Prod-02' is exhibiting anomalous outbound traffic to 'unknown.evil.com' (detected by GNN). The XAI model highlights its unusual port activity (port 22, typically SSH, now used for HTTP) and its atypical connection frequency as the primary contributing factors for this 'abnormal connection' tag." This significantly improves the actionable nature of the generated insights, reducing false positives and accelerating incident response. The processing circuitry (410) would be heavily GPU-accelerated for AI model inference.

• Mermaid Diagram:

  flowchart TD
      A[Collect Network Object Data (S210)] --> B[Construct Network Graph (S220)]
      B --> C{AI-Enhanced Relationship Determination (S230)}
      C --> D{XAI-Powered Insight Generation (S240)}
      D --> E[Tag Network Objects with Explanations (S250)]
  
      subgraph AI/XAI Components
          GNN_Model[Graph Neural Network Model]
          XAI_Engine[Explainable AI Engine]
      end
  
      C -. feeds .-> GNN_Model
      D -. interprets .-> GNN_Model
      D -. generates explanations .-> XAI_Engine
      E -. includes explanations .-> User[Security Analyst]
  

8. Integration with Emerging Tech: IoT Sensors for Correlated Physical-Cyber Anomaly Detection

• Enabling Description: The data collection (S210) is augmented by integrating real-time data from a network of IoT sensors deployed within the physical infrastructure underpinning the cloud environment (103). These sensors would monitor environmental parameters (temperature, humidity, airflow), physical access (door/cabinet open/close, motion detection), and power consumption at the rack, server, and even component levels. The collected network object data (S210) now includes both virtual/logical configurations and physical telemetry. The analysis (S240) correlates logical network abnormalities with physical environmental anomalies. An insight (S240) detecting an "abnormal connection" on a virtual machine could be cross-referenced with "unusual temperature spikes" on its host server or "unauthorized physical access" to the server rack, providing a holistic view of the threat. This allows for the detection of sophisticated attacks that blend cyber and physical components, or physical failures masquerading as cyber incidents. The cyber-security system (150) would include an IoT data ingestion and correlation engine.

• Mermaid Diagram:

  graph TD
      subgraph Cloud Environment 103
          CPL[Cloud Platform Logical Layer]
          CPH[Cloud Platform Hardware Layer]
          IoTS[IoT Sensors (Physical Environment, Access, Power)]
      end
  
      subgraph Cyber-Security System 150
          API_DC[API Data Collector (S210)]
          IoT_DC[IoT Data Collector (S210)]
          Fusion_Engine[Data Fusion Engine]
          NGB[Network Graph Builder (S220)]
          Corr_IG[Correlated Insight Generator (S240)]
          Tag_Corr[Tag with Physical Context (S250)]
      end
  
      CPL -- Logical Configs --> API_DC
      CPH -- Physical Status --> IoTS
      IoTS -- Telemetry Stream --> IoT_DC
      API_DC --> Fusion_Engine
      IoT_DC --> Fusion_Engine
      Fusion_Engine --> NGB
      NGB --> Corr_IG
      Corr_IG --> Tag_Corr
      Tag_Corr -- "Integrated Cyber-Physical Alerts" --> SOC[Security Operations Center]
  

9. The "Inverse" or Failure Mode: Stealthy Threat Emulation and "Dark Network" Probing

• Enabling Description: This derivative implements the "inverse" of anomaly detection: actively generating and analyzing "abnormal connections" in a controlled, isolated "dark network" or sandbox environment to emulate advanced persistent threats (APTs) and test the resilience of detection mechanisms. The "cloud computing environment" (103) here is a dedicated threat emulation sandbox. Data collection (S210) focuses on logging all actions of emulated threats and their impact on honeypot "network objects" (e.g., intentionally vulnerable virtual machines, containers). The network graph (S220) maps the attack kill chain, showing how an emulated threat establishes "abnormal relationships" (e.g., lateral movement, command and control communication). Relationship determination (S230) actively seeks to identify successful exploitations and lateral movement paths. Insights (S240) document the adversary tactics, techniques, and procedures (TTPs) used to create these "abnormal connections," providing threat intelligence that informs the defense of production environments. Tagging (S250) categorizes these simulated abnormal connections by attack type, severity, and mitigation strategy. This represents an "inverse" application where the system is designed to facilitate and learn from generated "failures" (successful attacks).

• Mermaid Diagram:

  stateDiagram-v2
      state "Threat Emulation Sandbox" as Sandbox
      state "Emulated Adversary Activity" as ThreatActivity
      state "Monitoring & Data Collection" as Monitoring
      state "Network Graph Generation" as GraphGen
      state "Attack Chain Analysis" as AttackAnalysis
      state "Threat Intelligence Generation" as ThreatIntel
  
      [*] --> Sandbox: Initialize Sandbox Environment
      Sandbox --> ThreatActivity: Deploy Emulated Threat
      ThreatActivity --> Monitoring: Execute Attack Steps (generate "abnormal" connections)
      Monitoring --> GraphGen: Collect Object & Connection Data (S210, S220)
      GraphGen --> AttackAnalysis: Determine Attack Relationships (S230)
      AttackAnalysis --> ThreatIntel: Generate TTP Insights (S240)
      ThreatIntel --> ThreatIntel: Tag Attack Patterns (S250)
      ThreatIntel --> [*]: Output Threat Intelligence
  

10. The "Inverse" or Failure Mode: Secure Decommissioning and "Zero-Configuration" Verification

• Enabling Description: This derivative applies the patent's methodology in an "inverse" context: to verify the secure decommissioning of network objects and to ensure a "zero-configuration" state for non-operational components. When a network object (e.g., a virtual machine, a container) is intended to be decommissioned or isolated, the system (150) performs data collection (S210) to confirm all network object data indicates a complete shutdown or removal. A network graph (S220) is constructed for the decommissioned component's intended state. Relationship determination (S230) actively looks for the absence of any relationships or connections, or the presence of only explicit "isolation" relationships. Insights (S240) are generated for "abnormal connections" if any unexpected relationships are detected (e.g., a "decommissioned" VM still has an active network interface or a connection to a storage bucket). The goal is to detect the "failure" to achieve a fully isolated or removed state, preventing resource leaks or security vulnerabilities from lingering components. Tagging (S250) would indicate "decommissioning_failed," "residual_connection," or "zero_config_violation."

• Mermaid Diagram:

  graph TD
      subgraph Decommissioning Process
          DO[Decommission Object] --> Verify[Verify Decommissioned State]
      end
  
      subgraph Cyber-Security System 150 (Decom-Mode)
          DC[Data Collector (S210)]
          NGC[Network Graph Constructor (S220)]
          RD[Relationship Determiner (S230)]
          IG[Insight Generator (S240)]
          OT[Object Tagger (S250)]
      end
  
      Verify -- Query Decommissioned Object(s) --> DC
      DC --> NGC: Construct Graph of Decom State
      NGC --> RD: Determine *Existing* Relationships
      RD --> IG: Generate Insight: "Abnormal (Undesired) Connections"
      IG --> OT: Tag with "Decommission_Failure"
      OT -- Report --> Auditor[Auditor/Compliance Team]
  

Combination Prior Art Scenarios with Open-Source Standards

1. US11722554 + Open-Source Graph Databases (e.g., Apache TinkerPop with JanusGraph or Neo4j Community Edition):
   The patent's methodology of constructing a network graph (S220) and determining relationships (S230) for cloud objects is directly implementable using existing open-source graph database technologies. For instance, Apache TinkerPop provides a graph computing framework (Gremlin API) that can be used for graph traversal and analysis. When combined with a graph database implementation like JanusGraph (which can use Apache Cassandra or Apache HBase for storage) or Neo4j Community Edition, the collection of network object data (S210) can be ingested and modeled as nodes and edges. The relationship determination (S230) would then involve executing Gremlin queries or Cypher queries to discover connections and dependencies. The analysis (S240) for insights could use standard graph algorithms available in these platforms to identify abnormal patterns (e.g., detecting isolated nodes, unexpected hub-and-spoke patterns). The visual representation (S220) could be achieved via integration with open-source graph visualization libraries (e.g., D3.js). This combination renders the fundamental graph-based analysis as obvious to one skilled in the art.

2. US11722554 + Cloud Native Computing Foundation (CNCF) Kubernetes API and Prometheus Monitoring:
   Claim 3 describes collecting network object data via an API, including platform-specific APIs for cloud platforms. The Kubernetes API, a widely adopted CNCF standard, provides comprehensive programmatic access to the state and configuration of containerized network objects (pods, services, deployments, network policies) within a Kubernetes cluster (a specific type of cloud platform 104 or container orchestration system mentioned in the patent description). Combining the data collection (S210) with the Kubernetes API to gather real-time configuration data is an obvious application. Furthermore, for relationship determination (S230) using observational methods (Claim 7) and detecting "spikes of network activity" (Claim 4), integrating with Prometheus (another CNCF project and open-source monitoring solution) to collect metrics on network traffic, connection counts, and resource utilization from Kubernetes-managed objects makes the monitoring aspect straightforward. The patent's insight generation (S240) then becomes the application of anomaly detection logic to this readily available data.

3. US11722554 + Open Policy Agent (OPA) with Rego Policy Language:
   The patent mentions determining "impermissible relationships" (Claim 5) and generating insights about "unauthorized connections" (Claim 4). Open Policy Agent (OPA), an open-source, general-purpose policy engine, allows for defining policies as code using its Rego language. When combined with US11722554, the determined relationships (S230) between network objects can be fed into OPA as input. OPA then evaluates these relationships against predefined security and compliance policies written in Rego (e.g., "no public access to database VMs," "only specific subnets can communicate with specific services"). The output of OPA (policy violations) directly informs the "abnormal connections" insights generated at S240, effectively automating the "permissibility analysis" described in the patent. This external, standardized policy engine makes the logic for identifying unauthorized or impermissible connections readily apparent to those in the cloud security domain.