DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/05/2026 has been entered.
Accordingly, claims 1-29 are pending in this application. Claims 11 and 15-16 are currently amended.
Response to Arguments
3. Applicant’s arguments with respect to amended pending claims filed on 1/05/2026 have been fully considered. In view of the claim amendment filed, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made.
Further, regarding the new limitations of “ wherein the uber node stores cybersecurity threat-specific metadata fields enabling automated cybersecurity threat mitigation actions directly from the uber node based on the cybersecurity threat-specific metadata fields stored in the uber node, and without issuing any additional queries to any underlying databases or data stores after generation of the uber node” recited in claims 1, 15, and 16, it is submitted that they are properly addressed by the new ground of rejection.
Furthermore, it is also submitted that all limitations in pending claims, including those not specifically argued, are properly addressed. The reason is set forth in the rejections. See claim analysis below for detail.
Claim Rejections - 35 USC § 103
4. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
5. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
6. Claims 1-29 are rejected under 35 U.S.C. 103 as being unpatentable over Leon-Garcia et al. (US 20210409295 A1) in view of Borra et al. (US 20200226156 A1) and Shemesh et al. (US-20240168792-A1, Earliest Priority Date: 2022-05-23).
Regarding Claim 1, Leon-Garcia discloses a method for improving computational efficiency in cybersecurity monitoring by generating a compact representation of a compute environment using an uber node data structure in a graph database from a plurality of sources ([0402]: The inventors have found that embodiments of the systems, methods and computer program products described herein can process events at least ten times more efficiently than existing “best approaches”… the monitoring data for the network can be processed and analyzed; [0276]: FIG. 7C is an example of a visual representation of a processing graph generated in this manner), comprising:
receiving object metadata ([0120]: As shown in FIG. 1, system 100 includes a plurality of data sources 110a-110n. Each data source 110a-110n can be configured to provide a corresponding stream 111a-111n of data) of a cloud entity ([0136]: the data stream processing system 105 may be implemented as a remote or cloud-based processing system) from a first cybersecurity monitoring system (Figs. 1-2A; [0117]: System 100 is an example of a data processing system that may be used to monitor and analyze a communication network) configured to detect a first set of cybersecurity threats associated with the cloud entity (Fig. 1; [0104]: monitoring application can provide real-time, or near real-time, feedback on the status of the communication network (and potential threats thereto));
receiving object metadata of the cloud entity from a second cybersecurity monitoring system operating independently of the first cybersecurity monitoring system (Figs. 1-2A; [0120]: As shown in FIG. 1, system 100 includes a plurality of data sources 110a-110n; [0119]: System 100 may also be implemented using multiple networks or virtual networks, which can be internetworked or isolated.) and configured to detect a second, distinct set of cybersecurity threats associated with the cloud entity ([0006]: These applications gather information about the network and analyze the received data to detect events of interest such as faults, anomalies and intrusions);
automatically mapping the received object metadata from the first and second cybersecurity monitoring systems source and the received object metadata from the second source into a unified data structure in a graph database ([0008]-[0010]: a plurality of operators connecting the data collection input, the plurality of data processing sub-units, and at least one data output unit in a directed acyclic graph; [0147]: incoming data streams 111 are connected to processed data stream outputs 121 through a plurality of processing components that are interconnected in a feed-forward graph structure),
wherein the unified data structure reduces computational overhead associated with redundant data representations by dynamically consolidating overlapping metadata ([0401]: The operators can also be configured to dynamically adjust the connections between data processing sub-units and data processing segments to facilitate resource scaling as required. This may reduce, or prevent, data throttling through the data stream processing system).
However, Leon-Garcia does not explicitly teach “generating an uber node representing the cloud entity based on a predetermined schema in a graph database, wherein the uber node provides a unified reference for initiating cybersecurity actions thereby reducing alert duplication and improving real-time threat responsiveness, wherein the uber node stores cybersecurity threat-specific metadata fields enabling automated cybersecurity threat mitigation actions directly from the uber node based on the cybersecurity threat-specific metadata fields stored in the uber node, and without issuing any additional queries to any underlying databases or data stores after generation of the uber node.”
On the other hand, in the same field of endeavor, Borra teaches
generating an uber node representing the cloud entity (Figs. 4A-B; [0079]: the entities… may even be merged into a single instance of an entity by graph creation engine 192… submitted via block 191 to graph creation engine 192 for implementation as a primary node in the graph 310; [0082]: graph creation engine 192… generates a relationships graph 310… The relationships graph includes nodes… that each represent one or more entities, and includes edges between any two nodes in the relationships graph to represent the identified relationships between the one or more entities represented by each of the two nodes)
based on a predetermined schema in a graph database ([0046]: Node labels may also serve to attach metadata to certain nodes; [0076]: In one embodiment, the relationships discovery engine 185 may make use of available meta-data from participating databases, like the DDL of a schema),
wherein the uber node provides a unified reference for initiating cybersecurity actions thereby reducing alert duplication and improving real-time threat responsiveness ([0017]: embodiments create a unified data fabric for applications to consume data using a graph query interface on top of heterogeneous SQL, NoSQL, and unstructured data stores; [0041]: The execution of relational queries… permits improving performance without modifying the logical structure of the database).
Additionally, Shemesh teaches wherein the uber node stores cybersecurity threat-specific metadata fields (Fig. 4; [0074]-[0075]: At S450, a check is performed to determine if the matched node corresponds to a previously determined risk factor… The risk factor may be indicated by metadata associated with the matched node. The metadata may be, for example, data fields which indicate that a risk factor is present. For example, a flag may indicate if a node has external network access) enabling automated cybersecurity threat mitigation actions directly from the uber node based on the cybersecurity threat-specific metadata fields stored in the uber node, and without issuing any additional queries to any underlying databases or data stores after generation of the uber node (Fig. 4; [0074]-[0075]: If the matched node corresponds to a previously determined risk factor execution continues at S460… a notification may be generated… and sent to the client device, user account(s), or both… to specify why the notification is generated, and what should be performed to mitigate the risk).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Leon-Garcia to incorporate the teachings of Borra and Shemesh to include generating an uber node representing the cloud entity based on a predetermined schema in a graph database, wherein the uber node provides a unified reference for initiating cybersecurity actions thereby reducing alert duplication and improving real-time threat responsiveness, wherein the uber node stores cybersecurity threat-specific metadata fields enabling automated cybersecurity threat mitigation actions directly from the uber node.
The motivation for doing so would be to execute a graph query against a set of databases, as recognized by Borra (Fig. 1; [0072] of Borra: In one embodiment, the graph query interface 193 implements an Application Programming Interface (API) through which queries may be executed against graph store 155D, and then, in turn, executed against the databases 155 or the other data stores), and to represent a vulnerability on a security graph by a node, as recognized by Shemesh ([0074]: In an embodiment a vulnerability may be represented on the security graph by a node).
Regarding Claim 2, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 1.
Leon-Garcia further teaches further comprising: determining that a first data field of the object metadata received from the first cybersecurity monitoring system matches a first data field of the object metadata received from the second cybersecurity monitoring system (Fig. 1; [0125]-[0126]: Examples of processing operations performed by the data stream processing system 105 can include data streams being parsed, filtered, matched).
Regarding Claim 3, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 1.
Leon-Garcia further teaches further comprising: determining that a first data field of the object metadata received from the first cybersecurity monitoring system matches the first data field of the object metadata received from the second cybersecurity monitoring system based on a common value Fig. 1; [0125]-[0126]: Examples of processing operations performed by the data stream processing system 105 can include data streams being parsed, filtered, matched).
Regarding Claim 4, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 3.
Leon-Garcia further teaches wherein the common value is any one of: an identifier, an IP address, a name, a unique identifier, a MAC address, or a combination thereof ([0238]: For instance, a block of data may be routed to data processing sub-units 333a or 333b according to whether it pertains to an IP address that is of ingress or egress type for a given network; Fig. 7; [0358]: For example, the conditional operator 715 may route data between the pair of downstream extractors 720 according to whether the received data 706 corresponds to an ingress or egress network IP address).
Regarding Claim 5, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 1.
Borra further teaches further comprising: generating a first node representing the cloud entity (Fig. 4A; [0079]: at step 407A… This information may be input at block 191 to a graph creation engine 192… for implementation as a primary node in the graph 310) based on only the object metadata from the first cybersecurity monitoring system ([0076]: a user can define mappings, relationships, edges between entities (fields) across all or a subset of participating databases… In one embodiment, the relationships discovery engine 185 may make use of available meta-data from participating databases); and
generating a vertex connecting the uber node to the first node ([0082]: Referring back to FIG. 4A, at logic block 410, graph creation engine 192… generates a relationships graph 310… The relationships graph includes nodes (vertices, e.g., vertex(1), vertex (2), vertex(Z) . . . vertex(N) in graph 310) that each represent one or more entities, and includes edges between any two nodes in the relationships graph to represent the identified relationships between the one or more entities represented by each of the two nodes).
Regarding Claim 6, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 5.
Borra further teaches further comprising: generating a second node representing the cloud entity based on only the object metadata received from the second cybersecurity monitoring system; and generating a vertex connecting the uber node to the second node ([0065]: Fig. 1, system 130; [0082]: Referring back to FIG. 4A, at logic block 410, graph creation engine 192… generates a relationships graph 310… The relationships graph includes nodes (vertices, e.g., vertex(1), vertex (2), vertex(Z) . . . vertex(N) in graph 310) that each represent one or more entities, and includes edges between any two nodes in the relationships graph to represent the identified relationships between the one or more entities represented by each of the two nodes).
Regarding Claim 7, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 1.
Leon-Garcia further teaches further comprising: detecting a conflict between data value of the object metadata from the first cybersecurity monitoring system and a corresponding data value of the object metadata from the second cybersecurity monitoring system ([0266]-[0267]: DSP manager 505 may then determine whether there is a mismatch between the existing processing requirements and the processing capabilities); and
generating a mitigating action based on the detected conflict ([0267]: The DSP manager 505 may identify updates that are required to the data processing graph to account for the mismatch in the data processing requirements and capabilities; [0144]: The system-monitoring dashboard may allow the administrator to implement mitigating actions in response to the feedback from the system 100).
Regarding Claim 8, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 1.
Leon-Garcia further teaches wherein the predetermined schema includes a first data field corresponding to metadata monitored by the first cybersecurity monitoring system and the second cybersecurity monitoring system (Fig. 2; [0028]: In some embodiments, the method also includes buffering the input data received at each of the data processing sub-units using a corresponding data buffer; [0049]-[0069]: In some embodiments, the method also includes buffering the input data received at each of the data processing sub-units using a corresponding data buffer; [0234]: load balancer operator 320 may be configured to transmit data to the data processing sub-units 323 using a pipe-based transmission schema).
Regarding Claim 9, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 8.
Leon-Garcia further teaches wherein the predetermined schema further includes a second data field received only from the first cybersecurity monitoring system (Fig. 1; [0128]: In some cases, only a subset of data analysis applications or data output streams may be coupled to a data storage application; [0199]: In some examples, output data stream 121a may receive processed data from only one of the input data streams 111a and 111b; Fig. 7B; [0365]: The filter operator 740 can be configured to select only data that corresponds to a pre-defined profile).
Regarding Claim 10, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 9.
Leon-Garcia further teaches wherein the predetermined schema further includes a third data field received only from the second cybersecurity monitoring system (Fig. 1; [0128]: In some cases, only a subset of data analysis applications or data output streams may be coupled to a data storage application; [0199]: In some examples, output data stream 121a may receive processed data from only one of the input data streams 111a and 111b; Fig. 7B; [0365]: The filter operator 740 can be configured to select only data that corresponds to a pre-defined profile).
Regarding Claim 11, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 1.
Borra further teaches further comprising: applying a control based on the uber node ([0031]-[0032]: Embodiments of the invention allow a database administrator, or a user, such as a customer or client (e.g., a tenant or a user of a tenant in a multi-tenant database system) of a cloud computing services provider, to define and/or view entities and the relationships between entities… For example, an ERD may represent things that a business needs to remember in order to perform business processes; Fig. 1; [0076]: User defined rules may also be input at block 191 through a user interface).
Regarding Claim 12, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 1.
Leon-Garcia further teaches further comprising: generating the predetermined schema based on a received input ([0234]: load balancer operator 320 may be configured to transmit data to the data processing sub-units 323 using a pipe-based transmission schema)
Regarding Claim 13, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 1.
Leon-Garcia further teaches further comprising: detecting a data field in the object metadata of the first cybersecurity monitoring system ([0103]: The network related data can be analyzed and monitored in an effort to detect network characteristics including events of interest such as faults, anomalies and intrusions; [0360]: The analysis application may perform operations on the extracted features in stream 712 to detect events of interest. For example, the analysis application may perform anomaly detection or threat correlation for the selected data stream); and
generating an updated predetermined schema based on the predetermined schema and the detected data field, wherein the predetermined schema includes a plurality of data fields, each data field of the detected data fields not corresponding to the detected data field ([0013]: determine whether the directed acyclic graph is configured to satisfy the processing request; and upon determining that the directed acyclic graph is not configured to satisfy the processing request, modify the directed acyclic graph to enable the directed acyclic graph to satisfy the processing request; [0116]: UDP may also allow the processing system to be updated on the fly; [0167]: The operators 210 can provide loose couplings… This may allow the data processing sequences and subgraphs to be updated while the system is operational).
Regarding Claim 14, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the method of claim 1.
Leon-Garcia further teaches wherein the first cybersecurity monitoring system is any one of: a cybersecurity monitoring scanner, a cloud infrastructure monitoring system, a vulnerability detection service, or a combination thereof ([0136]: Alternatively, the data stream processing system 105 may be implemented as a remote or cloud-based processing system that is in communication with a network to be monitored).
Regarding Claim 15, Leon-Garcia discloses a non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process for improving computational efficiency in cybersecurity monitoring ([0040]: In accordance with an aspect of this disclosure there is provided a computer program product comprising a non-transitory computer-readable medium; [0402]: The inventors have found that embodiments of the systems, methods and computer program products described herein can process events at least ten times more efficiently than existing “best approaches”… the monitoring data for the network can be processed and analyzed), the process comprising:
receiving object metadata ([0120]: As shown in FIG. 1, system 100 includes a plurality of data sources 110a-110n. Each data source 110a-110n can be configured to provide a corresponding stream 111a-111n of data) of a cloud entity ([0136]: the data stream processing system 105 may be implemented as a remote or cloud-based processing system) from a first cybersecurity monitoring system (Figs. 1-2A; [0117]: System 100 is an example of a data processing system that may be used to monitor and analyze a communication network) configured to detect a first set of cybersecurity threats associated with the cloud entity (Fig. 1; [0104]: monitoring application can provide real-time, or near real-time, feedback on the status of the communication network (and potential threats thereto));
receiving object metadata of the cloud entity from a second cybersecurity monitoring system operating independently of the first cybersecurity monitoring system (Figs. 1-2A; [0120]: As shown in FIG. 1, system 100 includes a plurality of data sources 110a-110n; [0119]: System 100 may also be implemented using multiple networks or virtual networks, which can be internetworked or isolated.) and configured to detect a second, distinct set of cybersecurity threats associated with the cloud entity ([0006]: These applications gather information about the network and analyze the received data to detect events of interest such as faults, anomalies and intrusions);
automatically mapping the received object metadata from the first and second cybersecurity monitoring systems source and the received object metadata from the second source into a unified data structure in a graph database ([0008]-[0010]: a plurality of operators connecting the data collection input, the plurality of data processing sub-units, and at least one data output unit in a directed acyclic graph; [0147]: incoming data streams 111 are connected to processed data stream outputs 121 through a plurality of processing components that are interconnected in a feed-forward graph structure),
wherein the unified data structure reduces computational overhead associated with redundant data representations by dynamically consolidating overlapping metadata ([0401]: The operators can also be configured to dynamically adjust the connections between data processing sub-units and data processing segments to facilitate resource scaling as required. This may reduce, or prevent, data throttling through the data stream processing system).
However, Leon-Garcia does not explicitly teach “generating an uber node representing the cloud entity based on a predetermined schema in a graph database, wherein the uber node provides a unified reference for initiating cybersecurity actions thereby reducing alert duplication and improving real-time threat responsiveness, wherein the uber node stores cybersecurity threat-specific metadata fields enabling automated cybersecurity threat mitigation actions directly from the uber node based on the cybersecurity threat-specific metadata fields stored in the uber node, and without issuing any additional queries to any underlying databases or data stores after generation of the uber node.”
On the other hand, in the same field of endeavor, Borra teaches
generating an uber node representing the cloud entity (Figs. 4A-B; [0079]: the entities… may even be merged into a single instance of an entity by graph creation engine 192… submitted via block 191 to graph creation engine 192 for implementation as a primary node in the graph 310; [0082]: graph creation engine 192… generates a relationships graph 310… The relationships graph includes nodes… that each represent one or more entities, and includes edges between any two nodes in the relationships graph to represent the identified relationships between the one or more entities represented by each of the two nodes)
based on a predetermined schema in a graph database ([0046]: Node labels may also serve to attach metadata to certain nodes; [0076]: In one embodiment, the relationships discovery engine 185 may make use of available meta-data from participating databases, like the DDL of a schema),
wherein the uber node provides a unified reference for initiating cybersecurity actions thereby reducing alert duplication and improving real-time threat responsiveness ([0017]: embodiments create a unified data fabric for applications to consume data using a graph query interface on top of heterogeneous SQL, NoSQL, and unstructured data stores; [0041]: The execution of relational queries… permits improving performance without modifying the logical structure of the database).
Additionally, Shemesh teaches wherein the uber node stores cybersecurity threat-specific metadata fields (Fig. 4; [0074]-[0075]: At S450, a check is performed to determine if the matched node corresponds to a previously determined risk factor… The risk factor may be indicated by metadata associated with the matched node. The metadata may be, for example, data fields which indicate that a risk factor is present. For example, a flag may indicate if a node has external network access) enabling automated cybersecurity threat mitigation actions directly from the uber node based on the cybersecurity threat-specific metadata fields stored in the uber node, and without issuing any additional queries to any underlying databases or data stores after generation of the uber node (Fig. 4; [0074]-[0075]: If the matched node corresponds to a previously determined risk factor execution continues at S460… a notification may be generated… and sent to the client device, user account(s), or both… to specify why the notification is generated, and what should be performed to mitigate the risk).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Leon-Garcia to incorporate the teachings of Borra and Shemesh to include generating an uber node representing the cloud entity based on a predetermined schema in a graph database, wherein the uber node provides a unified reference for initiating cybersecurity actions thereby reducing alert duplication and improving real-time threat responsiveness, wherein the uber node stores cybersecurity threat-specific metadata fields enabling automated cybersecurity threat mitigation actions directly from the uber node.
The motivation for doing so would be to execute a graph query against a set of databases, as recognized by Borra (Fig. 1; [0072] of Borra: In one embodiment, the graph query interface 193 implements an Application Programming Interface (API) through which queries may be executed against graph store 155D, and then, in turn, executed against the databases 155 or the other data stores), and to represent a vulnerability on a security graph by a node, as recognized by Shemesh ([0074]: In an embodiment a vulnerability may be represented on the security graph by a node).
Regarding Claim 16, Leon-Garcia discloses a system for improving computational efficiency in cybersecurity monitoring by generating a compact representation of a compute environment using an uber node data structure in a graph database from a plurality of sources ([0402]: The inventors have found that embodiments of the systems, methods and computer program products described herein can process events at least ten times more efficiently than existing “best approaches”… the monitoring data for the network can be processed and analyzed; [0276]: FIG. 7C is an example of a visual representation of a processing graph generated in this manner), comprising:
a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry ([0131]: In general, the components of system 100 may be implemented using one or more computers, each having a processor), configure the system to:
receive object metadata ([0120]: As shown in FIG. 1, system 100 includes a plurality of data sources 110a-110n. Each data source 110a-110n can be configured to provide a corresponding stream 111a-111n of data) of a cloud entity ([0136]: the data stream processing system 105 may be implemented as a remote or cloud-based processing system) from a first cybersecurity monitoring system (Figs. 1-2A; [0117]: System 100 is an example of a data processing system that may be used to monitor and analyze a communication network) configured to detect a first set of cybersecurity threats associated with the cloud entity (Fig. 1; [0104]: monitoring application can provide real-time, or near real-time, feedback on the status of the communication network (and potential threats thereto));
receive object metadata of the cloud entity from a second cybersecurity monitoring system operating independently of the first cybersecurity monitoring system (Figs. 1-2A; [0120]: As shown in FIG. 1, system 100 includes a plurality of data sources 110a-110n; [0119]: System 100 may also be implemented using multiple networks or virtual networks, which can be internetworked or isolated.) and configured to detect a second, distinct set of cybersecurity threats associated with the cloud entity ([0006]: These applications gather information about the network and analyze the received data to detect events of interest such as faults, anomalies and intrusions);
automatically map the received object metadata from the first and second cybersecurity monitoring systems source and the received object metadata from the second source into a unified data structure in a graph database ([0008]-[0010]: a plurality of operators connecting the data collection input, the plurality of data processing sub-units, and at least one data output unit in a directed acyclic graph; [0147]: incoming data streams 111 are connected to processed data stream outputs 121 through a plurality of processing components that are interconnected in a feed-forward graph structure),
wherein the unified data structure reduces computational overhead associated with redundant data representations by dynamically consolidating overlapping metadata ([0401]: The operators can also be configured to dynamically adjust the connections between data processing sub-units and data processing segments to facilitate resource scaling as required. This may reduce, or prevent, data throttling through the data stream processing system).
However, Leon-Garcia does not explicitly teach “generate an uber node representing the cloud entity based on a predetermined schema in a graph database, wherein the uber node provides a unified reference for initiating cybersecurity actions thereby reducing alert duplication and improving real-time threat responsiveness, wherein the uber node stores cybersecurity threat-specific metadata fields enabling automated cybersecurity threat mitigation actions directly from the uber node based on the cybersecurity threat-specific metadata fields stored in the uber node, and without issuing any additional queries to any underlying databases or data stores after generation of the uber node.”
On the other hand, in the same field of endeavor, Borra teaches
generate an uber node representing the cloud entity (Figs. 4A-B; [0079]: the entities… may even be merged into a single instance of an entity by graph creation engine 192… submitted via block 191 to graph creation engine 192 for implementation as a primary node in the graph 310; [0082]: graph creation engine 192… generates a relationships graph 310… The relationships graph includes nodes… that each represent one or more entities, and includes edges between any two nodes in the relationships graph to represent the identified relationships between the one or more entities represented by each of the two nodes)
based on a predetermined schema in a graph database ([0046]: Node labels may also serve to attach metadata to certain nodes; [0076]: In one embodiment, the relationships discovery engine 185 may make use of available meta-data from participating databases, like the DDL of a schema),
wherein the uber node provides a unified reference for initiating cybersecurity actions thereby reducing alert duplication and improving real-time threat responsiveness ([0017]: embodiments create a unified data fabric for applications to consume data using a graph query interface on top of heterogeneous SQL, NoSQL, and unstructured data stores; [0041]: The execution of relational queries… permits improving performance without modifying the logical structure of the database).
Additionally, Shemesh teaches wherein the uber node stores cybersecurity threat-specific metadata fields (Fig. 4; [0074]-[0075]: At S450, a check is performed to determine if the matched node corresponds to a previously determined risk factor… The risk factor may be indicated by metadata associated with the matched node. The metadata may be, for example, data fields which indicate that a risk factor is present. For example, a flag may indicate if a node has external network access) enabling automated cybersecurity threat mitigation actions directly from the uber node based on the cybersecurity threat-specific metadata fields stored in the uber node, and without issuing any additional queries to any underlying databases or data stores after generation of the uber node (Fig. 4; [0074]-[0075]: If the matched node corresponds to a previously determined risk factor execution continues at S460… a notification may be generated… and sent to the client device, user account(s), or both… to specify why the notification is generated, and what should be performed to mitigate the risk).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Leon-Garcia to incorporate the teachings of Borra and Shemesh to include generating an uber node representing the cloud entity based on a predetermined schema in a graph database, wherein the uber node provides a unified reference for initiating cybersecurity actions thereby reducing alert duplication and improving real-time threat responsiveness, wherein the uber node stores cybersecurity threat-specific metadata fields enabling automated cybersecurity threat mitigation actions directly from the uber node.
The motivation for doing so would be to execute a graph query against a set of databases, as recognized by Borra (Fig. 1; [0072] of Borra: In one embodiment, the graph query interface 193 implements an Application Programming Interface (API) through which queries may be executed against graph store 155D, and then, in turn, executed against the databases 155 or the other data stores), and to represent a vulnerability on a security graph by a node, as recognized by Shemesh ([0074]: In an embodiment a vulnerability may be represented on the security graph by a node).
Regarding Claim 17, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 16.
Leon-Garcia further teaches wherein the memory contains further instructions, which when executed by the processing circuitry further configures the system to: determine that a first data field of the object metadata received from the first cybersecurity monitoring system matches a first data field of the object metadata received from the second cybersecurity monitoring system (Fig. 1; [0125]-[0126]: Examples of processing operations performed by the data stream processing system 105 can include data streams being parsed, filtered, matched).
Regarding Claim 18, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 16.
Leon-Garcia further teaches wherein the memory contains further instructions, which when executed by the processing circuitry further configures the system to: determine that first data field of the object metadata received from the first cybersecurity monitoring system matches the first data field of the object metadata received from the second cybersecurity monitoring system based on a common value (Fig. 1; [0125]-[0126]: Examples of processing operations performed by the data stream processing system 105 can include data streams being parsed, filtered, matched).
Regarding Claim 19, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 18.
Leon-Garcia further teaches wherein the common value is any one of: an identifier, an IP address, a name, a unique identifier, a MAC address, or a combination thereof ([0238]: For instance, a block of data may be routed to data processing sub-units 333a or 333b according to whether it pertains to an IP address that is of ingress or egress type for a given network; Fig. 7; [0358]: For example, the conditional operator 715 may route data between the pair of downstream extractors 720 according to whether the received data 706 corresponds to an ingress or egress network IP address).
Regarding Claim 20, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 16.
Borra further teaches wherein the memory contains further instructions, which when executed by the processing circuitry further configures the system to: generate a first node representing the cloud entity (Fig. 4A; [0079]: at step 407A… This information may be input at block 191 to a graph creation engine 192… for implementation as a primary node in the graph 310) based on only the object metadata from the first cybersecurity monitoring system ([0076]: a user can define mappings, relationships, edges between entities (fields) across all or a subset of participating databases… In one embodiment, the relationships discovery engine 185 may make use of available meta-data from participating databases); and generate a vertex connecting the uber node to the first node ([0082]: Referring back to FIG. 4A, at logic block 410, graph creation engine 192… generates a relationships graph 310… The relationships graph includes nodes (vertices, e.g., vertex(1), vertex (2), vertex(Z) . . . vertex(N) in graph 310) that each represent one or more entities, and includes edges between any two nodes in the relationships graph to represent the identified relationships between the one or more entities represented by each of the two nodes).
Regarding Claim 21, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 20.
Borra further teaches wherein the memory contains further instructions, which when executed by the processing circuitry further configures the system to: generate a second node representing the cloud entity based on only the object metadata received from the second cybersecurity monitoring system; and generate a vertex connecting the uber node to the second node ([0082]: Referring back to FIG. 4A, at logic block 410, graph creation engine 192… generates a relationships graph 310… The relationships graph includes nodes (vertices, e.g., vertex(1), vertex (2), vertex(Z) . . . vertex(N) in graph 310) that each represent one or more entities, and includes edges between any two nodes in the relationships graph to represent the identified relationships between the one or more entities represented by each of the two nodes).
Regarding Claim 22, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 16.
Leon-Garcia further teaches wherein the memory contains further instructions, which when executed by the processing circuitry further configures the system to: detect a conflict between data value of the object metadata from the first cybersecurity monitoring system and a corresponding data value of the object metadata from the second cybersecurity monitoring system ([0266]-[0267]: DSP manager 505 may then determine whether there is a mismatch between the existing processing requirements and the processing capabilities); and
generate a mitigating action based on the detected conflict ([0267]: The DSP manager 505 may identify updates that are required to the data processing graph to account for the mismatch in the data processing requirements and capabilities; [0144]: The system-monitoring dashboard may allow the administrator to implement mitigating actions in response to the feedback from the system 100).
Regarding Claim 23, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 16.
Leon-Garcia further teaches wherein the predetermined schema includes a first data field corresponding to metadata monitored by the first cybersecurity monitoring system and the second cybersecurity monitoring system (Fig. 2; [0028]: In some embodiments, the method also includes buffering the input data received at each of the data processing sub-units using a corresponding data buffer; [0049]-[0069]: In some embodiments, the method also includes buffering the input data received at each of the data processing sub-units using a corresponding data buffer; [0234]: load balancer operator 320 may be configured to transmit data to the data processing sub-units 323 using a pipe-based transmission schema).
Regarding Claim 24, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 23.
Leon-Garcia further teaches wherein the predetermined schema further includes a second data field received only from the first cybersecurity monitoring system (Fig. 1; [0128]: In some cases, only a subset of data analysis applications or data output streams may be coupled to a data storage application; [0199]: In some examples, output data stream 121a may receive processed data from only one of the input data streams 111a and 111b; Fig. 7B; [0365]: The filter operator 740 can be configured to select only data that corresponds to a pre-defined profile).
Regarding Claim 25, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 24.
Leon-Garcia further teaches wherein the predetermined schema further includes a third data field received only from the second cybersecurity monitoring system (Fig. 1; [0128]: In some cases, only a subset of data analysis applications or data output streams may be coupled to a data storage application; [0199]: In some examples, output data stream 121a may receive processed data from only one of the input data streams 111a and 111b; Fig. 7B; [0365]: The filter operator 740 can be configured to select only data that corresponds to a pre-defined profile).
Regarding Claim 26, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 16.
Borra further teaches wherein the memory contains further instructions, which when executed by the processing circuitry further configures the system to: apply a control based on the uber node ([0031]-[0032]: Embodiments of the invention allow a database administrator, or a user, such as a customer or client (e.g., a tenant or a user of a tenant in a multi-tenant database system) of a cloud computing services provider, to define and/or view entities and the relationships between entities… For example, an ERD may represent things that a business needs to remember in order to perform business processes; Fig. 1; [0076]: User defined rules may also be input at block 191 through a user interface).
Regarding Claim 27, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 16.
Leon-Garcia further teaches wherein the memory contains further instructions, which when executed by the processing circuitry further configures the system to: generate the predetermined schema based on a received input ([0234]: load balancer operator 320 may be configured to transmit data to the data processing sub-units 323 using a pipe-based transmission schema).
Regarding Claim 28, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 16.
Leon-Garcia further teaches wherein the memory contains further instructions, which when executed by the processing circuitry further configures the system to: detect a data field in the object metadata of the first cybersecurity monitoring system ([0103]: The network related data can be analyzed and monitored in an effort to detect network characteristics including events of interest such as faults, anomalies and intrusions; [0360]: The analysis application may perform operations on the extracted features in stream 712 to detect events of interest. For example, the analysis application may perform anomaly detection or threat correlation for the selected data stream); and
generate an updated predetermined schema based on the predetermined schema and the detected data field, wherein the predetermined schema includes a plurality of data fields, each data field of the detected data fields not corresponding to the detected data field ([0013]: determine whether the directed acyclic graph is configured to satisfy the processing request; and upon determining that the directed acyclic graph is not configured to satisfy the processing request, modify the directed acyclic graph to enable the directed acyclic graph to satisfy the processing request; [0116]: UDP may also allow the processing system to be updated on the fly; [0167]: The operators 210 can provide loose couplings… This may allow the data processing sequences and subgraphs to be updated while the system is operational).
Regarding Claim 29, the combined teachings of Leon-Garcia, Borra, and Shemesh disclose the system of claim 16.
Leon-Garcia further teaches wherein the first cybersecurity monitoring system is any one of: a cybersecurity monitoring scanner, a cloud infrastructure monitoring system, a vulnerability detection service, or a combination thereof ([0136]: Alternatively, the data stream processing system 105 may be implemented as a remote or cloud-based processing system that is in communication with a network to be monitored).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIRLEY D. HICKS whose telephone number is (571)272-3304. The examiner can normally be reached Mon - Fri 7:30 - 4:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Charles Rones can be reached on (571) 272-4085. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S D H/Examiner, Art Unit 2168
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168