DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed on 05/17/2023.
Claims 1-20 are pending.
Claim Objections
Claim 1 is objected to because of the following informalities: “inventory collectors that each collects inventory and configuration information from an underlying management system and publishes the collected information” should read “inventory collectors that each collect inventory and configuration information from an underlying management system and publish the collected information”. Appropriate correction is required.
Claims 7 and 18 are objected to because of the following informalities: “complex relationships that each represents a relationships between a pair of managed entities” should read “complex relationships that each represent a relationship between a pair of managed entities”. Appropriate correction is required.
Claims 1 objected to because of the following informalities: The claims recite the following limitation twice: “providing/provide an event-stream-system-implemented central data bus accessed by one or more of the multiple component microservices and one or more of the multiple streams/batch-processing components;”. Appropriate correction is required.
Claims 16 objected to because of the following informalities: “the ICMDB” should read “the CICMDB”. Appropriate correction is required.
Claims 17 and 18 are objected to because of the following informalities: The claims are dependent from claim 1 and appear to be substantial duplicates of claims 3 and 7 respectively which are also dependent from claim 1. However, claims 17 and 18 appear after independent claim 16. Examiner will interpret claims 17 and 18 to depend from claim 16. Appropriate correction is required.
Claims 2-15 and 17-19 depend, directly or indirectly, from objected to claims and do not resolve the deficiencies thereof and are therefore objected to for at least the same reasons.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7-15 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 7 and 18 recite the limitations "wherein the complex nodes are each one of a first type of complex node" in lines 4-5 and "wherein the complex relationships are each one of a first type of complex relationship". It is unclear whether these limitations means that of the complex nodes and complex relationships, there exists at least one of each of the following types or that each complex node and complex relationship belong to at least one of the following types. For the sake of compact prosecution, Examiner will interpret this to mean that of the complex nodes and each of the complex relationships there is at least one of each type.
Claim 8 recites the limitation "and a general set of properties, or a reference to a general set of labels" in line 8. This limitation is unclear in the context of the preceding limitation: “a general set of labels, or a reference to a general set of labels”, because it is unclear whether these limitations are meant to refer to different general sets of labels. For the sake of compact prosecution, Examiner will interpret this to mean “and a general set of properties, or a reference to a general set of properties”.
Claims 8-15 depend, directly or indirectly, from rejected claims and do not resolve the deficiencies thereof and are therefore rejected for at least the same reasons.
Claim Rejections - 35 USC § 103
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.
Claims 1-3, 16-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Datar (US 2023/0102572 A1) in view of Krishnan (US 2023/0138971 A1) in view of Tola (US 2020/0328885 A1).
With regard to claim 1, Datar teaches:
A meta-level management system that aggregates information contained in, and functionalities provided by, multiple underlying management systems, “In a complex system with multiple layers (also referred to herein as domains) in an infrastructure stack, there is a need for end-to-end visibility into alerts and issues. However, the full infrastructure stack includes multiple disparate layers of physical, virtualized, and clustered components. Each layer in the stack may provide visibility about the configuration of entities managed by that layer (underlying management system), but the data regarding each such layer may not provide a view of the full range of the stack. As a result, it is difficult to ascertain and evaluate the status of the full environment” [Datar ¶ 13]. “Examples described herein may provide for cross domain configuration extraction, topology mapping, and topology representation to provide application insights for layers of an infrastructure stack” [Datar ¶ 14].
the meta-level management system comprising: an MMS (schema) API that supports stitching; “Examples described herein may provide for stitching together a topology across the multiple disparate layers of an infrastructure stack, and providing a representation of the full topology for a user. The end-to-end topology may be across some or all layers such as the application, operating system (OS), virtualization, compute, and storage layers” [Datar ¶ 14]. “FIGS. 5A-5C illustrate example approaches for topology stitching. One or more approaches may be applied in performing topology stitching in end-to-end topology processing, such as topology stitching 360 performed by a backend server 350 as illustrated in FIG. 3” [Datar ¶ 42]. “The process 800 further proceeds with transforming the extracted data according to a schema at block 815, wherein the schema may include a schema that is agreed between a computing system and a backend server, such as schema 340 illustrated in FIG. 3. In some implementations, blocks 810 and 815 may be performed by a computing system (e.g., 300)” [Datar ¶ 83].
multiple stream/batch-processing components; “The delta configuration streams together with a last snapshot 518 are received by the topology stitcher job 550. For the delta configuration, the topology stitcher job 550 presents a node add/update stream 562, a relationship add/update stream 564, and a combination (or move) add/update stream 566 to the graph database connector 580” [Datar ¶ 60]. “As shown in FIG. 6, a topology stitching pipeline may include receiving configuration data from a first set of datastores at stage 600, wherein configuration values for each batch for VM, OS, and application are processed to identify latest values, such as by evaluating the relevant timestamps, and as a second set of datastores at stage 605 to identify the latest configuration values at stage 610” [Datar ¶ 74, Fig. 6].
multiple collectors that collect information and events “For example, the computing system 300 may utilize available collectors to obtain configuration values for each of the domains for the layers of the stack. Collectors may be open source, provided by vendors, or otherwise available, and may include, e.g., APIs (application programming interfaces), SDKs (software development kits), or other tools such as Prometheus or Telegraf)” [Datar ¶ 29]. “Configuration changes are identified (which may be performed by, for example, using a SQL lag function) to obtain a last value of a column (in, for example, SQL or Spark SQL), and comparing this last value with a new value. Such a configuration change could be any of the events (a)-(e) identified above” [Datar ¶ 59].
and input the collected information to the central data bus, “The multiple configuration collectors may be independently executable, with minimal dependency between entities or objects reported by a single collector” [Datar ¶ 39].
including inventory collectors that each collects inventory “The multiple configuration collectors (inventory collectors) may be independently executable, with minimal dependency between entities or objects reported by a single collector” [Datar ¶ 39]. “The DSL can be used to translate and categorize an event that has occurred to one of the below events: (a) New entity; (b) Deleted entity; (c) New property for existing entity; (d) Deleted property for existing entity; or (e) Changed property for existing entity. On premise collectors may not be capable of deriving the delta, and thus the events will need to be derived at the backend server 350 for example” [Datar ¶ 51-57].
and configuration information from an underlying management system “For example, the computing system 300 may utilize available collectors to obtain configuration values for each of the domains for the layers of the stack. Collectors may be open source, provided by vendors, or otherwise available, and may include, e.g., APIs (application programming interfaces), SDKs (software development kits), or other tools such as Prometheus or Telegraf)” [Datar ¶ 29].
a comprehensive, graph-database-based inventory-and-configuration-management database ("CICMDB"), “In terms of a graph database representation, the topology is a natural graph. Reported entities are reported as nodes (vertices) of the graph, where each vertex has a set of properties that get reported. Most of the "edges" (relationships) of the graph are derived based on these properties by the topology stitching algorithm” [Datar ¶ 78]. “The configuration files are then directed to a topology stitcher job 550, and to a graph database connector 580” [Datar ¶ 47].
that stores inventory and configuration information aggregated from the multiple underlying management systems; “The topology stitching 360 is performed by matching like attributes or properties in the configuration data from the different layers of the infrastructure stack to determine the interconnections between the layers and generate a full end-to-end view of the infrastructure stack. In one specific example, topology may be stitched together based on the domain knowledge of layers encapsulated in stitching metadata to create a relationship between a virtualization layer and an operating system layer if, for example, VM BIOS UUID from a virtualization layer collector is the same as host uuid from an OS collector. In this manner, the matching of attributes results in identifying sets of entities (which may be referred to as nodes) for which a relationship (which may also be referred to as an edge) should be created” [Datar ¶ 33].
and an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information from the central data bus and uses the collected information to update the inventory and configuration information stored by the CICMDB. “The generated topology of a configuration stack may be maintained in the form of a view or "snapshot" that represents the complete topology at a particular time. In the first approach, the complete topology is stitched every time new snapshots are received, with the prior topology graph being deleted and replaced with the new topology graph. Alternatively, the nodes and edges of the topology snapshots may be overwritten and merged with the existing topology graph. In this manner, a static view of a full end-to-end stack is presented” [Datar ¶ 48]. “The delta configuration streams together with a last snapshot 518 are received by the topology stitcher job 550. For the delta configuration, the topology stitcher job 550 presents a node add/update stream 562, a relationship add/ update stream 564, and a combination (or move) add/update stream 566 to the graph database connector 580” [Datar ¶ 60]. “However, overwriting all relationships and nodes with a graph database may be very expensive in terms of processing. Further, topology changes may be infrequent, and thus the dynamic portion of the topology may be a small fraction of nodes and relationships for a system … As alternatives to the overwrite/merge approach to topology stitching, the following approaches allow incremental topology stitching” [Datar ¶ 49-50].
Datar fails to teach an MMS API and multiple component microservices, each providing a microservice API; an event-stream-system-implemented central data bus accessed by one or more of the multiple component microservices and a comprehensive, graph-database-based inventory-and-configuration-management database ("CICMDB"), accessed by one or more of the multiple component microservices and the multiple stream/batch-processing components.
However, Krishnan teaches:
an MMS API “In embodiments, GraphQL may comprise a query language for an application programming interface (API) and/or a server-side runtime service for executing queries using a type system and/or the like that may be defined for content to be sought” [Krishnan ¶ 36]. “For example, API-side joins may combine all of the fields for a particular entity, even if spread across multiple subgraphs, so that a single integrated result may be returned to the client” [Krishnan ¶ 66].
multiple component microservices, each providing a microservice API; “Also, a federated GraphQL approach may not in at least some circumstances offer a durable and/or persistent store of data itself, but rather may be layered on top of underlying network services (e.g., GraphQL APIs, REST APIs, and/or microservices) that may in turn use a database or other data store” [Krishnan ¶ 53]. “A federated GraphQL approach may be agnostic to the underlying database or microservice technologies used and may be used to create a unified graph layer on top of multiple underlying microservices (e.g., REST APIs, gRPC, etc.) that may in turn each use different database technologies” [Krishnan ¶ 53].
an event-stream-system-implemented central data bus “Processor (e.g., processing device) 1120 and memory 1122, which may comprise primary memory 1124 and secondary memory 1126, may communicate by way of a communication bus 1115, for example” [Krishnan ¶ 156].
accessed by one or more of the multiple component microservices “Devices, such as IoT-type devices, for example, may include computing resources embedded into hardware so as to facilitate and/or support a device's ability to acquire, collect, process and/or transmit content over one or more communications networks” [Krishnan ¶ 2].
a comprehensive, graph-database-based inventory-and-configuration-management database ("CICMDB"), accessed by one or more of the multiple component microservices and the multiple stream/batch-processing components, “Also, a federated GraphQL approach may not in at least some circumstances offer a durable and/or persistent store of data itself, but rather may be layered on top of underlying network services (e.g., GraphQL APis, REST APis, and/or microservices) that may in turn use a database or other data store… In this way, one may spread the data for an entity across multiple database tables and/or may join them together using a SQL query that may then be processed by a database query planning engine to create a query plan, execute it by fetching data from the underlying database tables on disk and/or collate and return the results to the client. In a similar way, a federated approach may allow one to spread the implementation of entity types in a graph across multiple subgraphs where a GraphQL gateway can process a query and/or join entity fields together by dynamically creating a query plan at runtime to advantageously (e.g., optimally) fetch the entity fields from the respective subgraph API servers using entity keys” [Krishnan ¶ 53].
Krishnan is considered to be analogous to the claimed invention because it is in the same field of database structures for information retrieval. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar to incorporate the teachings of Krishnan and include: an MMS API and multiple component microservices, each providing a microservice API; an event-stream-system-implemented central data bus accessed by one or more of the multiple component microservices and a comprehensive, graph-database-based inventory-and-configuration-management database ("CICMDB"), accessed by one or more of the multiple component microservices and the multiple stream/batch-processing components. Doing so would allow for further optimization to the retrieval of information from different underlying management systems. “In a similar way, a federated approach may allow one to spread the implementation of entity types in a graph across multiple subgraphs where a GraphQL gateway can process a query and/or join entity fields together by dynamically creating a query plan at runtime to advantageously (e.g., optimally) fetch the entity fields from the respective subgraph API servers using entity keys” [Krishnan ¶ 53].
Datar in view of Krishnan fails to teach an event-stream-system-implemented central data bus accessed by … and one or more of the multiple streams/batch-processing components; and input the collected information to the central data bus, and an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information from the central data bus and uses the collected information to update.
However, Tola teaches:
an event-stream-system-implemented central data bus accessed by … and one or more of the multiple streams/batch-processing components; “The system of FIG. 1 may be configured to operate in connection with an event bus or equivalent bus-based command and control system” [Tola ¶ 90]. “The virtual security kernel may also comprise one or more data modules, such as an event manager module for applying policies or to translate device events into an appropriate format for processing” [Tola ¶ 103].
and input the collected information to the central data bus, “The LDC may be comprised of one or more databases, such as a domain database, a device agent, and any management platform, portal, or console sufficient to enable data interactions” [Tola ¶ 78]. “While each device agent is configured to immediately establish a secure connection with the associated LDC, the domain database of the LDC may also communicate and send updates (for example, via BUS commands) to other domain databases located outside the LDC, as shown in FIG. 1” [Tola ¶ 88].
and an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information from the central data bus and uses the collected information to update “In embodiments, the event bus is configured to send and receive data between local systems, or alternatively between known devices in a local system. In embodiments, an event manager distributes messages (command and control) to separately update the LDC database” [Tola ¶ 90].
Tola is considered to be analogous to the claimed invention because it is in the same field of database structures for information retrieval. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan to incorporate the teachings of Tola and include: an event-stream-system-implemented central data bus accessed by … and one or more of the multiple streams/batch-processing components; and input the collected information to the central data bus, and an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information from the central data bus and uses the collected information to update. Doing so would allow for communication to be sent between the systems of the managed entities. “In embodiments, the event bus is configured to send and receive data between local systems, or alternatively between known devices in a local system. In embodiments, an event manager distributes messages (command and control) to separately update the LDC database” [Tola ¶ 90].
With regard to claim 2, Datar in view of Krishnan in view of Tola teaches the meta-level management system of claim 1 as referenced above. Datar further teaches wherein each inventory collector collects inventory and configuration information from only one underlying management system. “Such collectors may be leveraged for each of the layers of the stack for which there is interest” [Datar ¶ 29]. “Examples described herein may include multiple modular, stack-layer-specific configuration collectors. In this manner, each configuration collector may operate consistently with the protocols for an associated or corresponding layer or layers” [Datar ¶ 38]. “… for example, VM BIOS UUID from a virtualization layer collector is the same as host uuid from an OS collector. In this manner, the matching of attributes results in identifying sets of entities (which may be referred to as nodes) for which a relationship (which may also be referred to as an edge) should be created” [Datar ¶ 33].
With regard to claim 3, Datar in view of Krishnan in view of Tola teaches the meta-level management system of claim 1 as referenced above. Datar further teaches wherein an inventory collector associates information, collected from the underlying management system regarding a particular managed entity known to and/or managed by the underlying management system from which the inventory collector collects inventory and configuration information, with an entity ID that uniquely identifies the managed entity and the underlying management system. “The configuration data includes identification of entities that are within a layer and attributes of these identified entities” [Datar ¶ 21]. “The stitching metadata 365 may include information regarding entities of the multiple domains and attributes of such entities and rules based on which attributes can be matched to formulate relationships” [Datar ¶ 36]. “… for example, VM BIOS UUID from a virtualization layer collector is the same as host uuid from an OS collector. In this manner, the matching of attributes results in identifying sets of entities (which may be referred to as nodes) for which a relationship (which may also be referred to as an edge) should be created” [Datar ¶ 33].
With regard to claim 16, Datar teaches:
A method that efficiently stores inventory and configuration information within a meta-level management system that aggregates information contained in, and functionalities provided by, multiple underlying management systems, the method comprising: “In a complex system with multiple layers (also referred to herein as domains) in an infrastructure stack, there is a need for end-to-end visibility into alerts and issues. However, the full infrastructure stack includes multiple disparate layers of physical, virtualized, and clustered components. Each layer in the stack may provide visibility about the configuration of entities managed by that layer (underlying management system), but the data regarding each such layer may not provide a view of the full range of the stack. As a result, it is difficult to ascertain and evaluate the status of the full environment” [Datar ¶ 13]. “Examples described herein may provide for cross domain configuration extraction, topology mapping, and topology representation to provide application insights for layers of an infrastructure stack” [Datar ¶ 14].
providing a comprehensive, graph-database-based inventory-and-configuration-management database ("CICMDB"); “In terms of a graph database representation, the topology is a natural graph. Reported entities are reported as nodes (vertices) of the graph, where each vertex has a set of properties that get reported. Most of the "edges" (relationships) of the graph are derived based on these properties by the topology stitching algorithm” [Datar ¶ 78]. “The configuration files are then directed to a topology stitcher job 550, and to a graph database connector 580” [Datar ¶ 47].
providing multiple stream/batch-processing components; “The delta configuration streams together with a last snapshot 518 are received by the topology stitcher job 550. For the delta configuration, the topology stitcher job 550 presents a node add/update stream 562, a relationship add/update stream 564, and a combination (or move) add/update stream 566 to the graph database connector 580” [Datar ¶ 60]. “As shown in FIG. 6, a topology stitching pipeline may include receiving configuration data from a first set of datastores at stage 600, wherein configuration values for each batch for VM, OS, and application are processed to identify latest values, such as by evaluating the relevant timestamps, and as a second set of datastores at stage 605 to identify the latest configuration values at stage 610” [Datar ¶ 74, Fig. 6].
for each underlying management system, launching and initializing an inventory collector that collects inventory and configuration information from the underlying management system “For example, the computing system 300 may utilize available collectors to obtain configuration values for each of the domains for the layers of the stack. Collectors may be open source, provided by vendors, or otherwise available, and may include, e.g., APIs (application programming interfaces), SDKs (software development kits), or other tools such as Prometheus or Telegraf)” [Datar ¶ 29]. “Configuration changes are identified (which may be performed by, for example, using a SQL lag function) to obtain a last value of a column (in, for example, SQL or Spark SQL), and comparing this last value with a new value. Such a configuration change could be any of the events (a)-(e) identified above” [Datar ¶ 59]. “The multiple configuration collectors (inventory collectors) may be independently executable, with minimal dependency between entities or objects reported by a single collector” [Datar ¶ 39]. “The DSL can be used to translate and categorize an event that has occurred to one of the below events: (a) New entity; (b) Deleted entity; (c) New property for existing entity; (d) Deleted property for existing entity; or (e) Changed property for existing entity. On premise collectors may not be capable of deriving the delta, and thus the events will need to be derived at the backend server 350 for example” [Datar ¶ 51-57].
and launching and initializing an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information “Overwrite/Merge-In a first approach, FIG. 5A illustrates topology stitching including an overwrite or merge operation. As illustrated, configuration files are received (such as from a computing system 300) for an infrastructure stack including multiple domains, such as the illustrated application configuration 502, OS configuration 504, virtualization configuration 506, compute configuration 508, and storage configuration 509. The configuration files are then directed to a topology stitcher job 550, and to a graph database connector 580” [Datar ¶ 47]. “The delta configuration streams together with a last snapshot 518 are received by the topology stitcher job 550. For the delta configuration, the topology stitcher job 550 presents a node add/update stream 562, a relationship add/ update stream 564, and a combination (or move) add/update stream 566 to the graph database connector 580” [Datar ¶ 60].
and uses the collected information to update the inventory and configuration information stored by the ICMDB. “The generated topology of a configuration stack may be maintained in the form of a view or "snapshot" that represents the complete topology at a particular time. In the first approach, the complete topology is stitched every time new snapshots are received, with the prior topology graph being deleted and replaced with the new topology graph. Alternatively, the nodes and edges of the topology snapshots may be overwritten and merged with the existing topology graph. In this manner, a static view of a full end-to-end stack is presented” [Datar ¶ 48]. “The delta configuration streams together with a last snapshot 518 are received by the topology stitcher job 550. For the delta configuration, the topology stitcher job 550 presents a node add/update stream 562, a relationship add/ update stream 564, and a combination (or move) add/update stream 566 to the graph database connector 580” [Datar ¶ 60]. “However, overwriting all relationships and nodes with a graph database may be very expensive in terms of processing. Further, topology changes may be infrequent, and thus the dynamic portion of the topology may be a small fraction of nodes and relationships for a system … As alternatives to the overwrite/merge approach to topology stitching, the following approaches allow incremental topology stitching” [Datar ¶ 49-50].
Datar fails to teach providing multiple component microservices, each providing a microservice API; providing an event-stream-system-implemented central data bus accessed by one or more of the multiple component microservices.
However, Krishnan teaches:
providing multiple component microservices, each providing a microservice API; “Also, a federated GraphQL approach may not in at least some circumstances offer a durable and/or persistent store of data itself, but rather may be layered on top of underlying network services (e.g., GraphQL APIs, REST APIs, and/or microservices) that may in turn use a database or other data store” [Krishnan ¶ 53]. “A federated GraphQL approach may be agnostic to the underlying database or microservice technologies used and may be used to create a unified graph layer on top of multiple underlying microservices (e.g., REST APIs, gRPC, etc.) that may in turn each use different database technologies” [Krishnan ¶ 53].
providing an event-stream-system-implemented central data bus “Processor (e.g., processing device) 1120 and memory 1122, which may comprise primary memory 1124 and secondary memory 1126, may communicate by way of a communication bus 1115, for example” [Krishnan ¶ 156].
accessed by one or more of the multiple component microservices “Devices, such as IoT-type devices, for example, may include computing resources embedded into hardware so as to facilitate and/or support a device's ability to acquire, collect, process and/or transmit content over one or more communications networks” [Krishnan ¶ 2].
Krishnan is considered to be analogous to the claimed invention because it is in the same field of database structures for information retrieval. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar to incorporate the teachings of Krishnan and include: providing multiple component microservices, each providing a microservice API; providing an event-stream-system-implemented central data bus accessed by one or more of the multiple component microservices. Doing so would allow for further optimization to the retrieval of information from different underlying management systems. “In a similar way, a federated approach may allow one to spread the implementation of entity types in a graph across multiple subgraphs where a GraphQL gateway can process a query and/or join entity fields together by dynamically creating a query plan at runtime to advantageously (e.g., optimally) fetch the entity fields from the respective subgraph API servers using entity keys” [Krishnan ¶ 53].
Datar in view of Krishnan fails to teach an event-stream-system-implemented central data bus accessed by … and one or more of the multiple streams/batch-processing components; for each underlying management system, launching and initializing an inventory collector … and publishes the collected information to the central data bus; and an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information from the central data bus.
However, Tola teaches:
an event-stream-system-implemented central data bus accessed by … and one or more of the multiple streams/batch-processing components; “The system of FIG. 1 may be configured to operate in connection with an event bus or equivalent bus-based command and control system” [Tola ¶ 90]. “The virtual security kernel may also comprise one or more data modules, such as an event manager module for applying policies or to translate device events into an appropriate format for processing” [Tola ¶ 103].
for each underlying management system, launching and initializing an inventory collector “Applicant's system preferably starts by placing a small software agent on every device and may be comprised of any combination of internal/external Operating System (OS) software as well as circuit board/hardware component features depending on the embodiment” [Tola ¶ 72]. “In one embodiment, the device agent is installed as a driver or otherwise as a no-UI application. This allows the device agent to acquire and process packets outside of an operating system, and preferably in a low-level application” [Tola ¶ 86].
and publishes the collected information to the central data bus; “The LDC may be comprised of one or more databases, such as a domain database, a device agent, and any management platform, portal, or console sufficient to enable data interactions” [Tola ¶ 78]. “While each device agent is configured to immediately establish a secure connection with the associated LDC, the domain database of the LDC may also communicate and send updates (for example, via BUS commands) to other domain databases located outside the LDC, as shown in FIG. 1” [Tola ¶ 88].
an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information collected inventory and configuration information from the central data bus “In embodiments, the event bus is configured to send and receive data between local systems, or alternatively between known devices in a local system. In embodiments, an event manager distributes messages (command and control) to separately update the LDC database” [Tola ¶ 90].
Tola is considered to be analogous to the claimed invention because it is in the same field of database structures for information retrieval. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan to incorporate the teachings of Tola and include: an event-stream-system-implemented central data bus accessed by … and one or more of the multiple streams/batch-processing components; for each underlying management system, launching and initializing an inventory collector … and publishes the collected information to the central data bus; and an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information from the central data bus. Doing so would allow for communication to be sent between the systems of the managed entities. “In embodiments, the event bus is configured to send and receive data between local systems, or alternatively between known devices in a local system. In embodiments, an event manager distributes messages (command and control) to separately update the LDC database” [Tola ¶ 90].
With regard to claim 17, Datar in view of Krishnan in view of Tola teaches the method of claim 1 as referenced above. Datar further teaches associating, by each inventory collector, information, collected from the underlying management system regarding a particular managed entity known to and/or managed by the underlying management system from which the inventory collector collects inventory and configuration information, with an entity ID that uniquely identifies the managed entity and the underlying management system. “The configuration data includes identification of entities that are within a layer and attributes of these identified entities” [Datar ¶ 21]. “The stitching metadata 365 may include information regarding entities of the multiple domains and attributes of such entities and rules based on which attributes can be matched to formulate relationships” [Datar ¶ 36]. “… for example, VM BIOS UUID from a virtualization layer collector is the same as host uuid from an OS collector. In this manner, the matching of attributes results in identifying sets of entities (which may be referred to as nodes) for which a relationship (which may also be referred to as an edge) should be created” [Datar ¶ 33].
With regard to claim 20, Datar teaches:
A data-storage device that stores processor instructions that, when executed by one or more processors of a meta-level management system, controls the meta-level management system to: “Examples may include subject matter such as a method, means for performing acts of the method, at least one machine-readable medium, such as a non-transitory machine-readable medium, including instructions that, when performed by a machine, cause the machine to perform acts of the method, or of an apparatus or system for facilitating operations according to examples described herein” [Datar ¶ 90]. “In a complex system with multiple layers (also referred to herein as domains) in an infrastructure stack, there is a need for end-to-end visibility into alerts and issues. However, the full infrastructure stack includes multiple disparate layers of physical, virtualized, and clustered components. Each layer in the stack may provide visibility about the configuration of entities managed by that layer (underlying management system), but the data regarding each such layer may not provide a view of the full range of the stack. As a result, it is difficult to ascertain and evaluate the status of the full environment” [Datar ¶ 13]. “Examples described herein may provide for cross domain configuration extraction, topology mapping, and topology representation to provide application insights for layers of an infrastructure stack” [Datar ¶ 14].
provide a single, comprehensive, graph-database-based inventory-and-configuration-management database ("CICMDB"); “In terms of a graph database representation, the topology is a natural graph. Reported entities are reported as nodes (vertices) of the graph, where each vertex has a set of properties that get reported. Most of the "edges" (relationships) of the graph are derived based on these properties by the topology stitching algorithm” [Datar ¶ 78]. “The configuration files are then directed to a topology stitcher job 550, and to a graph database connector 580” [Datar ¶ 47].
provide multiple stream/batch-processing components; “The delta configuration streams together with a last snapshot 518 are received by the topology stitcher job 550. For the delta configuration, the topology stitcher job 550 presents a node add/update stream 562, a relationship add/update stream 564, and a combination (or move) add/update stream 566 to the graph database connector 580” [Datar ¶ 60]. “As shown in FIG. 6, a topology stitching pipeline may include receiving configuration data from a first set of datastores at stage 600, wherein configuration values for each batch for VM, OS, and application are processed to identify latest values, such as by evaluating the relevant timestamps, and as a second set of datastores at stage 605 to identify the latest configuration values at stage 610” [Datar ¶ 74, Fig. 6].
for each underlying management system, launch and initialize an inventory collector that collects inventory and configuration information from the underlying management system “For example, the computing system 300 may utilize available collectors to obtain configuration values for each of the domains for the layers of the stack. Collectors may be open source, provided by vendors, or otherwise available, and may include, e.g., APIs (application programming interfaces), SDKs (software development kits), or other tools such as Prometheus or Telegraf)” [Datar ¶ 29]. “Configuration changes are identified (which may be performed by, for example, using a SQL lag function) to obtain a last value of a column (in, for example, SQL or Spark SQL), and comparing this last value with a new value. Such a configuration change could be any of the events (a)-(e) identified above” [Datar ¶ 59]. “The multiple configuration collectors (inventory collectors) may be independently executable, with minimal dependency between entities or objects reported by a single collector” [Datar ¶ 39]. “The DSL can be used to translate and categorize an event that has occurred to one of the below events: (a) New entity; (b) Deleted entity; (c) New property for existing entity; (d) Deleted property for existing entity; or (e) Changed property for existing entity. On premise collectors may not be capable of deriving the delta, and thus the events will need to be derived at the backend server 350 for example” [Datar ¶ 51-57].
and launch and initialize an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information “Overwrite/Merge-In a first approach, FIG. 5A illustrates topology stitching including an overwrite or merge operation. As illustrated, configuration files are received (such as from a computing system 300) for an infrastructure stack including multiple domains, such as the illustrated application configuration 502, OS configuration 504, virtualization configuration 506, compute configuration 508, and storage configuration 509. The configuration files are then directed to a topology stitcher job 550, and to a graph database connector 580” [Datar ¶ 47]. “The delta configuration streams together with a last snapshot 518 are received by the topology stitcher job 550. For the delta configuration, the topology stitcher job 550 presents a node add/update stream 562, a relationship add/ update stream 564, and a combination (or move) add/update stream 566 to the graph database connector 580” [Datar ¶ 60].
and uses the collected information to update the inventory and configuration information stored by the CICMDB. “The generated topology of a configuration stack may be maintained in the form of a view or "snapshot" that represents the complete topology at a particular time. In the first approach, the complete topology is stitched every time new snapshots are received, with the prior topology graph being deleted and replaced with the new topology graph. Alternatively, the nodes and edges of the topology snapshots may be overwritten and merged with the existing topology graph. In this manner, a static view of a full end-to-end stack is presented” [Datar ¶ 48]. “The delta configuration streams together with a last snapshot 518 are received by the topology stitcher job 550. For the delta configuration, the topology stitcher job 550 presents a node add/update stream 562, a relationship add/ update stream 564, and a combination (or move) add/update stream 566 to the graph database connector 580” [Datar ¶ 60]. “However, overwriting all relationships and nodes with a graph database may be very expensive in terms of processing. Further, topology changes may be infrequent, and thus the dynamic portion of the topology may be a small fraction of nodes and relationships for a system … As alternatives to the overwrite/merge approach to topology stitching, the following approaches allow incremental topology stitching” [Datar ¶ 49-50].
Datar fails to teach provide multiple component microservices, each providing a microservice API; providing an event-stream-system-implemented central data bus accessed by one or more of the multiple component microservices.
However, Krishnan teaches:
providing multiple component microservices, each providing a microservice API; “Also, a federated GraphQL approach may not in at least some circumstances offer a durable and/or persistent store of data itself, but rather may be layered on top of underlying network services (e.g., GraphQL APIs, REST APIs, and/or microservices) that may in turn use a database or other data store” [Krishnan ¶ 53]. “A federated GraphQL approach may be agnostic to the underlying database or microservice technologies used and may be used to create a unified graph layer on top of multiple underlying microservices (e.g., REST APIs, gRPC, etc.) that may in turn each use different database technologies” [Krishnan ¶ 53].
provide an event-stream-system-implemented central data bus “Processor (e.g., processing device) 1120 and memory 1122, which may comprise primary memory 1124 and secondary memory 1126, may communicate by way of a communication bus 1115, for example” [Krishnan ¶ 156].
accessed by one or more of the multiple component microservices “Devices, such as IoT-type devices, for example, may include computing resources embedded into hardware so as to facilitate and/or support a device's ability to acquire, collect, process and/or transmit content over one or more communications networks” [Krishnan ¶ 2].
Krishnan is considered to be analogous to the claimed invention because it is in the same field of database structures for information retrieval. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar to incorporate the teachings of Krishnan and include: provide multiple component microservices, each providing a microservice API; provide an event-stream-system-implemented central data bus accessed by one or more of the multiple component microservices. Doing so would allow for further optimization to the retrieval of information from different underlying management systems. “In a similar way, a federated approach may allow one to spread the implementation of entity types in a graph across multiple subgraphs where a GraphQL gateway can process a query and/or join entity fields together by dynamically creating a query plan at runtime to advantageously (e.g., optimally) fetch the entity fields from the respective subgraph API servers using entity keys” [Krishnan ¶ 53].
Datar in view of Krishnan fails to teach an event-stream-system-implemented central data bus accessed by … and one or more of the multiple streams/batch-processing components; for each underlying management system, launch and initialize an inventory collector … and publishes the collected information to the central data bus; and an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information from the central data bus.
However, Tola teaches:
an event-stream-system-implemented central data bus accessed by … and one or more of the multiple streams/batch-processing components; “The system of FIG. 1 may be configured to operate in connection with an event bus or equivalent bus-based command and control system” [Tola ¶ 90]. “The virtual security kernel may also comprise one or more data modules, such as an event manager module for applying policies or to translate device events into an appropriate format for processing” [Tola ¶ 103].
for each underlying management system, launch and initialize an inventory collector “Applicant's system preferably starts by placing a small software agent on every device and may be comprised of any combination of internal/external Operating System (OS) software as well as circuit board/hardware component features depending on the embodiment” [Tola ¶ 72]. “In one embodiment, the device agent is installed as a driver or otherwise as a no-UI application. This allows the device agent to acquire and process packets outside of an operating system, and preferably in a low-level application” [Tola ¶ 86].
and publishes the collected information to the central data bus; “The LDC may be comprised of one or more databases, such as a domain database, a device agent, and any management platform, portal, or console sufficient to enable data interactions” [Tola ¶ 78]. “While each device agent is configured to immediately establish a secure connection with the associated LDC, the domain database of the LDC may also communicate and send updates (for example, via BUS commands) to other domain databases located outside the LDC, as shown in FIG. 1” [Tola ¶ 88].
an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information collected inventory and configuration information from the central data bus “In embodiments, the event bus is configured to send and receive data between local systems, or alternatively between known devices in a local system. In embodiments, an event manager distributes messages (command and control) to separately update the LDC database” [Tola ¶ 90].
Tola is considered to be analogous to the claimed invention because it is in the same field of database structures for information retrieval. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan to incorporate the teachings of Tola and include: an event-stream-system-implemented central data bus accessed by … and one or more of the multiple streams/batch-processing components; for each underlying management system, launch and initialize an inventory collector … and publishes the collected information to the central data bus; and an inventory-ingest stream/batch-processing component that receives collected inventory and configuration information from the central data bus. Doing so would allow for communication to be sent between the systems of the managed entities. “In embodiments, the event bus is configured to send and receive data between local systems, or alternatively between known devices in a local system. In embodiments, an event manager distributes messages (command and control) to separately update the LDC database” [Tola ¶ 90].
Claims 4-6 are rejected under 35 U.S.C. 103 as being unpatentable over Datar (US 2023/0102572 A1) in view of Krishnan (US 2023/0138971 A1) in view of Tola (US 2020/0328885 A1) in view of Harris (US 2009/0112924 A1).
With regard to claim 4, Datar in view of Krishnan in view of Tola teaches the meta-level management system of claim 3 as referenced above. Datar further teaches:
wherein an entity ID includes: “The configuration data includes identification of entities that are within a layer and attributes of these identified entities” [Datar ¶ 21].
an instance field that stores an identifier for a particular underlying-management-system instance; “In one possible example, a rooted relationship may be represented as follows: … val src_domain: String” [Datar ¶ 70]. “In a complex system with multiple layers (also referred to herein as domains) in an infrastructure stack, there is a need for end-to-end visibility into alerts and issues” [Datar ¶ 13].
a type field that indicates the type of the particular managed entity referenced by the entity ID; “In one possible example, a rooted relationship may be represented as follows: … val src_type: String” [Datar ¶ 70].
and an identifier field that contains an identifier for the managed entity. “In one possible example, a rooted relationship may be represented as follows: … val src_uid: String” [Datar ¶ 70].
Datar in view of Krishnan in view of Tola fails to teach a provider field that contains an identifier for the type of the underlying management system.
However, Harris teaches a provider field that contains an identifier for the type of the underlying management system; “Provider ID field 606 may include a provider ID, which identifies an entity (e.g., a service provider 114, 116, FIG. 1) from which the traceable object was obtained. In some cases, the entity identified in the provider ID field 606 may actually generate the traceable object. In other cases, the entity identified in the provider ID field 606 may retrieve the traceable object from another system entity and/or from a database” [Harris ¶ 72].
Harris is considered to be analogous to the claimed invention because it is in the same field of database structures for information retrieval. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan in view of Tola to incorporate the teachings of Harris and include: a provider field that contains an identifier for the type of the underlying management system. Doing so would allow for the identification of relationships between entities based on their identified provider. “In an embodiment, the object usage information and its associated client-reported tracer information may be stored, related, and/or accessed based on any one or more parameters, including but not limited to, provider ID, sponsor ID …” [Harris ¶ 97].
With regard to claim 5, Datar in view of Krishnan in view of Tola in view of Harris teaches the meta-level management system of claim 4 as referenced above. Datar further teaches wherein the entity ID further includes: “The configuration data includes identification of entities that are within a layer and attributes of these identified entities” [Datar ¶ 21].
Datar in view of Krishnan in view of Tola fails to teach an orgID field; and a region field.
However, Harris teaches:
an orgID field; “Sponsor ID field 608 may include a sponsor ID (orgID), which identifies a sponsor entity (e.g., a sponsor entity 130-134, FIG. 1) having or associated with a sponsor asset such as a trademark, logo, product, service, web site, sponsor facility (e.g., a sponsor facility 140-148, FIG. 1) or other tangible or intangible asset that may be represented in the content (e.g., content 508, FIG. 5) of the traceable object” [Harris ¶ 73].
and a region field. “As used herein, the term "traceable object" means a distinct and portable data structure (e.g., a transportable object), which has a defined format that includes or identifies some type of content (e.g., information included within, associated with, or identified by the object), one or more entities (e.g., a provider and/or sponsor entity), and information that enables actions performed on the object to be tracked (e.g., an "object tracer") … A "traceable location object" may include, for example, content describing the geographical and/or physical location (region) of an entity (e.g., a sponsor entity, a residence, a physical device or a point-of-interest)” [Harris ¶ 26-27].
With regard to claim 6, Datar in view of Krishnan in view of Tola in view of Harris teaches the meta-level management system of claim 4 as referenced above. Datar further teaches wherein the entity ID further includes “The configuration data includes identification of entities that are within a layer and attributes of these identified entities” [Datar ¶ 21].
Datar in view of Krishnan fails to explicitly teach includes an attributes field which may contain a set of attribute name/value pairs.
However, Tola teaches includes an attributes field which may contain a set of attribute name/value pairs. “During start up and provisioning stages of a new system, the thin device agent may also complete a number of other functions, including creating a unique device key pair for each device. The thin agent preferably creates a device ID and a hash of the device ID, which are then stored in, for example, a trusted zone” [Tola ¶ 108].
Claims 7, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Datar (US 2023/0102572 A1) in view of Krishnan (US 2023/0138971 A1) in view of Tola (US 2020/0328885 A1) in view of Ramani (US 11,588,840 B2).
With regard to claim 7, Datar in view of Krishnan in view of Tola teaches the meta-level management system of claim 1 as referenced above. Datar further teaches wherein the CICMDB contains complex nodes that each represents a managed entity and complex relationships that each represents a relationships between a pair of managed entities; “In this manner, the matching of attributes results in identifying sets of entities (which may be referred to as nodes) for which a relationship (which may also be referred to as an edge) should be created” [Datar ¶ 33]. “However, other representations of the rooted relationship may also be used. For example, complex types in relational databases may be leveraged to represent node and edge as nested structures for relationships” [Datar ¶ 71].
wherein the complex nodes are each one of a first type of complex node “GraphDB-driven stitching-In this approach, a graph database query language is used to create relationships between entities. Additional statements are generated by the DDL to create unique constraints on nodes and edges as applicable for the domain” [Datar ¶ 66].
and wherein the complex relationships are each one of a first type complex relationship “The topology stitching 360 is performed by matching like attributes or properties in the configuration data from the different layers of the infrastructure stack to determine the interconnections between the layers and generate a full end-to-end view of the infrastructure stack. In one specific example, topology may be stitched together based on the domain knowledge of layers encapsulated in stitching metadata to create a relationship between a virtualization layer and an operating system layer if, for example, VM BIOS UUID from a virtualization layer collector is the same as host uuid from an OS collector. In this manner, the matching of attributes results in identifying sets of entities (which may be referred to as nodes) for which a relationship (which may also be referred to as an edge) should be created” [Datar ¶ 33].
Datar fails to teach a first type of complex node with only a primary data source, and a third type of complex node with both a primary data source and one or more secondary data sources; a first type of complex relationship with only a primary data source, and a third type of complex relationship with both a primary data source and one or more secondary data sources.
However, Krishnan teaches:
a first type of complex node with only a primary data source, “In contrast, a further federated approach such as discussed herein may provide and/or may enforce a single source of truth for all fields (primary data source) (e.g., by default) that may be relaxed with a "@shareable" directive to allow denormalization of fields across subgraphs for performance, for example, that may require all subgraph teams to agree that a particular field is "@shareable" in contrast to a particular federated approach discussed above wherein such safety mechanisms may not be provided” [Krishnan ¶ 80 Examiner notes a node for an entity with a single source of truth is considered to have only a primary data source].
and a third type of complex node with both a primary data source and one or more secondary data sources; “In contrast, a further federated approach such as discussed herein may provide and/or may enforce a single source of truth for all fields (e.g., by default) that may be relaxed with a "@shareable" directive to allow denormalization of fields across subgraphs for performance, for example, that may require all subgraph teams to agree that a particular field is "@shareable" in contrast to a particular federated approach discussed above wherein such safety mechanisms may not be provided. In the further federated approach, an enhanced shared-ownership model with improved multi-team collaboration properties may result from the combination of the equal ownership of federated entity types across all subgraphs, the single source of truth for all federated entity fields that can be relaxed with "@shareable", and/or a more flexible type merging model with support for incremental rollout of a new field on shared value types one subgraph at a time, for example” [Krishnan ¶ 80 Examiner notes a node for an entity with shareable fields is considered to have both a primary data source and one or more secondary data sources, the single source of truth that is relaxed is considered the primary data source].
a first type of complex relationship with only a primary data source, “In contrast, a further federated approach such as discussed herein may provide and/or may enforce a single source of truth for all fields (primary data source) (e.g., by default) that may be relaxed with a "@shareable" directive to allow denormalization of fields across subgraphs for performance, for example, that may require all subgraph teams to agree that a particular field is "@shareable" in contrast to a particular federated approach discussed above wherein such safety mechanisms may not be provided” [Krishnan ¶ 80 Examiner notes a relationship is considered to have the same data sources as the nodes for which it was created].
and a third type of complex relationship with both a primary data source and one or more secondary data sources. “In contrast, a further federated approach such as discussed herein may provide and/or may enforce a single source of truth for all fields (e.g., by default) that may be relaxed with a "@shareable" directive to allow denormalization of fields across subgraphs for performance, for example, that may require all subgraph teams to agree that a particular field is "@shareable" in contrast to a particular federated approach discussed above wherein such safety mechanisms may not be provided. In the further federated approach, an enhanced shared-ownership model with improved multi-team collaboration properties may result from the combination of the equal ownership of federated entity types across all subgraphs, the single source of truth for all federated entity fields that can be relaxed with "@shareable", and/or a more flexible type merging model with support for incremental rollout of a new field on shared value types one subgraph at a time, for example” [Krishnan ¶ 80].
Datar in view of Krishnan in view of Tola fails to teach a second type of complex node with only one or more secondary data sources, a second type of complex relationship with only one or more secondary data sources.
However, Ramani teaches:
a second type of complex node with only one or more secondary data sources, “The entity seeking the detection may access 208 the captured data. It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data. If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col. 12-13 Lines 65-67, 1-9].
a second type of complex relationship with only one or more secondary data sources, “The entity seeking the detection may access 208 the captured data. It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data. If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col. 12-13 Lines 65-67, 1-9 Examiner notes a relationship is considered to have the same data sources as the nodes for which it was created].
Ramani is considered to be analogous to the claimed invention because it is in the same field of database structures for information retrieval. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan in view of Tola to incorporate the teachings of Ramani and include: a second type of complex node with only one or more secondary data sources, a second type of complex relationship with only one or more secondary data sources. Doing so would allow for the system to collect and utilize entity data when this data is reported from an indirect source. “If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col.13 Lines 2-9].
With regard to claim 11, Datar in view of Krishnan in view of Tola in view of Ramani teaches the meta-level management system of claim 7 as referenced above. Datar further teaches the provider associated with the inventory collector; “For example, the computing system 300 may utilize available collectors to obtain configuration values for each of the domains for the layers of the stack. Collectors may be open source, provided by vendors, or otherwise available, and may include, e.g., APIs (application programming interfaces), SDKs (software development kits), or other tools such as Prometheus or Telegraf)” [Datar ¶ 29].
Datar in view of Krishnan in view of Tola fails to explicilty teach wherein the management subsystem from which an inventory collector collects inventory and configuration data is the provider and wherein each inventory collector collects data from the provider associated with the inventory collector during data-collection intervals that begin at scheduled collection times.
However, Ramani teaches:
wherein the management subsystem from which an inventory collector collects inventory and configuration data is the provider “The entity seeking the detection may access 208 the captured data. It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data. If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col. 12-13 Lines 65-67, 1-9].
and wherein each inventory collector collects data from the provider associated with the inventory collector “It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data. If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col. 12-13 Lines 66-67, 1-9]. “In the illustrated embodiment, an organization is hosted by a cloud service, and illustrated are one or more cloud account 502 which may be associated with a cloud service(s). For convenience we assume the cloud service(s) is Amazon Web Service (AWS) compatible, and providing Amazon Elastic Compute Cloud (EC2) environments and other service. Shown are one or more Virtual Private Cloud (VPC) 504 associated the cloud account(s). Each VPC may have one or more associated firewalls(s) 506, and it is assumed a VPC represents a private environment that appears from external perspective to be a conventional computing environment” [Ramani Col. 18 Lines 47-58].
during data-collection intervals that begin at scheduled collection times. “The detector may instruct a selected device to capture 206 (record) data traffic between the source and destination for a period of time, e.g., three minutes. One skilled in the art will recognize the time frame is arbitrary, the purpose is to collect enough data to allow meaningful analysis. The time could be longer or shorter, and results (or lack thereof) may be used as an indicator of need to adjust timing. In another embodiment, characteristics of data flowing past may help to determine when to start or stop data capture. For example, a TLS handshake where a server (destination) is authenticated by its certificate, has known "ClientHello" messaging along with a back and forth of negotiation messages until the server, sends a "Finished" message. The capture may therefore be triggered around the handshake with perhaps a window of data, if desired, buffered and captured to encompass a period before and after the handshaking” [Ramani Col. 12 Lines 48-55].
With regard to claim 18, Datar in view of Krishnan in view of Tola teaches the method of claim 1 as referenced above. Datar further teaches wherein the CICMDB contains complex nodes that each represents a managed entity and complex relationships that each represents a relationships between a pair of managed entities; “In this manner, the matching of attributes results in identifying sets of entities (which may be referred to as nodes) for which a relationship (which may also be referred to as an edge) should be created” [Datar ¶ 33]. “However, other representations of the rooted relationship may also be used. For example, complex types in relational databases may be leveraged to represent node and edge as nested structures for relationships” [Datar ¶ 71].
wherein the complex nodes are each one of a first type of complex node “GraphDB-driven stitching-In this approach, a graph database query language is used to create relationships between entities. Additional statements are generated by the DDL to create unique constraints on nodes and edges as applicable for the domain” [Datar ¶ 66].
and wherein the complex relationships are each one of a first type complex relationship “The topology stitching 360 is performed by matching like attributes or properties in the configuration data from the different layers of the infrastructure stack to determine the interconnections between the layers and generate a full end-to-end view of the infrastructure stack. In one specific example, topology may be stitched together based on the domain knowledge of layers encapsulated in stitching metadata to create a relationship between a virtualization layer and an operating system layer if, for example, VM BIOS UUID from a virtualization layer collector is the same as host uuid from an OS collector. In this manner, the matching of attributes results in identifying sets of entities (which may be referred to as nodes) for which a relationship (which may also be referred to as an edge) should be created” [Datar ¶ 33].
Datar fails to teach a first type of complex node with only a primary data source; and a third type of complex node with both a primary data source and one or more secondary data sources; a first type of complex relationship with only a primary data source, and a third type of complex relationship with both a primary data source and one or more secondary data sources.
However, Krishnan teaches:
a first type of complex node with only a primary data source; “In contrast, a further federated approach such as discussed herein may provide and/or may enforce a single source of truth for all fields (primary data source) (e.g., by default) that may be relaxed with a "@shareable" directive to allow denormalization of fields across subgraphs for performance, for example, that may require all subgraph teams to agree that a particular field is "@shareable" in contrast to a particular federated approach discussed above wherein such safety mechanisms may not be provided” [Krishnan ¶ 80 Examiner notes a node for an entity with a single source of truth is considered to have only a primary data source].
and a third type of complex node with both a primary data source and one or more secondary data sources; “In contrast, a further federated approach such as discussed herein may provide and/or may enforce a single source of truth for all fields (e.g., by default) that may be relaxed with a "@shareable" directive to allow denormalization of fields across subgraphs for performance, for example, that may require all subgraph teams to agree that a particular field is "@shareable" in contrast to a particular federated approach discussed above wherein such safety mechanisms may not be provided. In the further federated approach, an enhanced shared-ownership model with improved multi-team collaboration properties may result from the combination of the equal ownership of federated entity types across all subgraphs, the single source of truth for all federated entity fields that can be relaxed with "@shareable", and/or a more flexible type merging model with support for incremental rollout of a new field on shared value types one subgraph at a time, for example” [Krishnan ¶ 80 Examiner notes a node for an entity with shareable fields is considered to have both a primary data source and one or more secondary data sources, the single source of truth that is relaxed is considered the primary data source].
a first type of complex relationship with only a primary data source; “In contrast, a further federated approach such as discussed herein may provide and/or may enforce a single source of truth for all fields (primary data source) (e.g., by default) that may be relaxed with a "@shareable" directive to allow denormalization of fields across subgraphs for performance, for example, that may require all subgraph teams to agree that a particular field is "@shareable" in contrast to a particular federated approach discussed above wherein such safety mechanisms may not be provided” [Krishnan ¶ 80 Examiner notes a relationship is considered to have the same data sources as the nodes for which it was created].
and a third type of complex relationship with both a primary data source and one or more secondary data sources. “In contrast, a further federated approach such as discussed herein may provide and/or may enforce a single source of truth for all fields (e.g., by default) that may be relaxed with a "@shareable" directive to allow denormalization of fields across subgraphs for performance, for example, that may require all subgraph teams to agree that a particular field is "@shareable" in contrast to a particular federated approach discussed above wherein such safety mechanisms may not be provided. In the further federated approach, an enhanced shared-ownership model with improved multi-team collaboration properties may result from the combination of the equal ownership of federated entity types across all subgraphs, the single source of truth for all federated entity fields that can be relaxed with "@shareable", and/or a more flexible type merging model with support for incremental rollout of a new field on shared value types one subgraph at a time, for example” [Krishnan ¶ 80].
Datar in view of Krishnan in view of Tola fails to teach a second type of complex node with only one or more secondary data sources; a second type of complex relationship with only one or more secondary data sources.
However, Ramani teaches:
a second type of complex node with only one or more secondary data sources; “The entity seeking the detection may access 208 the captured data. It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data. If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col. 12-13 Lines 65-67, 1-9].
a second type of complex relationship with only one or more secondary data sources; “The entity seeking the detection may access 208 the captured data. It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data. If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col. 12-13 Lines 65-67, 1-9 Examiner notes a relationship is considered to have the same data sources as the nodes for which it was created].
Ramani is considered to be analogous to the claimed invention because it is in the same field of database structures for information retrieval. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan in view of Tola to incorporate the teachings of Ramani and include: a second type of complex node with only one or more secondary data sources; a second type of complex relationship with only one or more secondary data sources. Doing so would allow for the system to collect and utilize entity data when this data is reported from an indirect source. “If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col.13 Lines 2-9].
Claims 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Datar (US 2023/0102572 A1) in view of Krishnan (US 2023/0138971 A1) in view of Tola (US 2020/0328885 A1) in view of Ramani (US 11,588,840 B2) in view of Kancharla (US 2022/0358123 A1).
With regard to claim 12, Datar in view of Krishnan in view of Tola in view of Ramani teaches the meta-level management system of claim 11 as referenced above. Datar further teaches:
each complex node and complex relationship in the CICMDB for which the data collector receives inventory and configuration information from the provider associated with the inventory collector is updated by: “The delta configuration streams together with a last snapshot 518 are received by the topology stitcher job 550. For the delta configuration, the topology stitcher job 550 presents a node add/update stream 562, a relationship add/update stream 564, and a combination (or move) add/update stream 566 to the graph database connector 580” [Datar ¶ 60].
updating one or more general labels and/or general properties “The DSL can be used to translate and categorize an event that has occurred to one of the below events: (a) New entity; (b) Deleted entity; (c) New property for existing entity; (d) Deleted property for existing entity; or (e) Changed property for existing entity. On premise collectors may not be capable of deriving the delta, and thus the events will need to be derived at the backend server 350 for example” [Datar ¶ 51-57]. “In terms of a graph database representation, the topology is a natural graph. Reported entities are reported as nodes (vertices) of the graph, where each vertex has a set of properties that get reported. Most of the "edges" (relationships) of the graph are derived based on these properties by the topology stitching algorithm” [Datar ¶ 78].
of the complex nodes and complex relationships using the received inventory and configuration information; “In the first approach, the complete topology is stitched every time new snapshots are received, with the prior topology graph being deleted and replaced with the new topology graph. Alternatively, the nodes and edges of the topology snapshots may be overwritten and merged with the existing topology graph. In this manner, a static view of a full end-to-end stack is presented” [Datar ¶ 48].
updating one or more labels and/or properties “The DSL can be used to translate and categorize an event that has occurred to one of the below events: (a) New entity; (b) Deleted entity; (c) New property for existing entity; (d) Deleted property for existing entity; or (e) Changed property for existing entity. On premise collectors may not be capable of deriving the delta, and thus the events will need to be derived at the backend server 350 for example” [Datar ¶ 51-57]. “In terms of a graph database representation, the topology is a natural graph. Reported entities are reported as nodes (vertices) of the graph, where each vertex has a set of properties that get reported. Most of the "edges" (relationships) of the graph are derived based on these properties by the topology stitching algorithm” [Datar ¶ 78].
Datar in view of Krishnan in view of Tola fails to teach during a data-collection interval for a data collector, when the provider associated with the inventory collector is the primary data source for the complex node and when the provider associated with the inventory collector is a secondary data source for the complex node.
However, Ramani teaches:
during a data-collection interval for a data collector, “The firewall is presumed manageable and, after authenticating with the firewall, it may be configured 406 to perform data capture for a desired period of time. In another embodiment, the firewall is instructed when to start, and when to stop the capture. As discussed above, captured data may be analyzed” [Ramani Col. 15-16 Lines 64-67, 1-2].
when the provider associated with the inventory collector is the primary data source for the complex node, “The entity seeking the detection may access 208 the captured data. It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (provider) (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data” [Ramani Col. 12-13 Lines 65-67, 1-5].
and when the provider associated with the inventory collector is a secondary data source for the complex node, “It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data. If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col. 12-13 Lines 66-67, 1-9].
Datar in view of Krishnan in view of Tola in view of Ramani fails to explicitly teach updating … within a namespace associated with the secondary data source using the received inventory and configuration information.
However, Kancharla teaches updating … within a namespace associated with the secondary data source using the received inventory and configuration information. “Based on a cadence of the batch and/or real-time data sources, the computing device may update the namespace. For instance, if the real-time data source has an update cadence of once per minute, the computing device may add data to the namespace or replace data in the namespace. The computing device may be configured to modify a namespace based on one or more data source cadences in various other manners as well” [Kancharla ¶ 82]. “In some examples, such a namespace may be updated based on a cadence associated with the first data source and/or the second data source. For instance, if the first real-time data source has an update cadence of once per 30 minutes, the computing device may update the namespace once per 30 minutes (e.g., at the update cadence). The computing device may update such a namespace, for instance by re-executing the relational join query based on updated data received from the first and/or second real-time data sources” [Kancharla ¶ 91].
Kancharla is considered to be analogous to the claimed invention because it is in the same field of updating database structures. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan in view of Tola in view of Ramani to incorporate the teachings of Kancharla and include: updating … within a namespace associated with the secondary data source using the received inventory and configuration information. Doing so would allow for the joining of two datasets with data for the same entities that have different cadences. “Based on the key columns of the first and second datasets, the computing device may be configured to join the first and second datasets to form a namespace. Such a namespace may comprise a logical view that may contain attributes from one or more datasets (two datasets in this example) … By joining data sets in accordance with the techniques described herein, the overall surface area of datasets may be increased, which may allow for the creation of a single dataset that comprise data from multiple datasets having different cadences” [Kancharla ¶ 27].
With regard to claim 13, Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla teaches the meta-level management system of claim 12 as referenced above. Datar further teaches:
during which a data collector has collected inventory and configuration information from the provider associated with the data collector, “For example, the computing system 300 may utilize available collectors to obtain configuration values for each of the domains for the layers of the stack. Collectors may be open source, provided by vendors, or otherwise available, and may include, e.g., APIs (application programming interfaces), SDKs (software development kits), or other tools such as Prometheus or Telegraf)” [Datar ¶ 29]. “Configuration changes are identified (which may be performed by, for example, using a SQL lag function) to obtain a last value of a column (in, for example, SQL or Spark SQL), and comparing this last value with a new value. Such a configuration change could be any of the events (a)-(e) identified above” [Datar ¶ 59].
each complex node and complex relationship in the CICMDB for which the provider associated with the data collector is the primary data source and for which no information was reported by the data collector during the data-collection interval is deleted. “The generated topology of a configuration stack may be maintained in the form of a view or "snapshot" that represents the complete topology at a particular time. In the first approach, the complete topology is stitched every time new snapshots are received, with the prior topology graph being deleted and replaced with the new topology graph” [Datar ¶ 48]. “The DSL can be used to translate and categorize an event that has occurred to one of the below events: (a) New entity; (b) Deleted entity; (c) New property for existing entity; (d) Deleted property for existing entity; or (e) Changed property for existing entity. On premise collectors may not be capable of deriving the delta, and thus the events will need to be derived at the backend server 350 for example” [Datar ¶ 51-57].
Datar in view of Krishnan in view of Tola fails to explicitly teach wherein, following completion of a data-collection interval.
However, Ramani teaches wherein, following completion of a data-collection interval “The firewall is presumed manageable and, after authenticating with the firewall, it may be configured 406 to perform data capture for a desired period of time. In another embodiment, the firewall is instructed when to start, and when to stop the capture. As discussed above, captured data may be analyzed. In the illustrated embodiment, captured data packets may be analyzed 408 to determine Server Name Indication (SNI) data” [Ramani Col. 15-16 Lines 64-67, 1-4].
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Datar (US 2023/0102572 A1) in view of Krishnan (US 2023/0138971 A1) in view of Tola (US 2020/0328885 A1) in view of Ramani (US 11,588,840 B2) in view of Kancharla (US 2022/0358123 A1) in view of Greer (US 2017/0344430 A1).
With regard to claim 14, Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla teaches the meta-level management system of claim 12 as referenced above. Datar further teaches:
during which a data collector has collected inventory and configuration information from the provider associated with the data collector, “For example, the computing system 300 may utilize available collectors to obtain configuration values for each of the domains for the layers of the stack. Collectors may be open source, provided by vendors, or otherwise available, and may include, e.g., APIs (application programming interfaces), SDKs (software development kits), or other tools such as Prometheus or Telegraf)” [Datar ¶ 29]. “Configuration changes are identified (which may be performed by, for example, using a SQL lag function) to obtain a last value of a column (in, for example, SQL or Spark SQL), and comparing this last value with a new value. Such a configuration change could be any of the events (a)-(e) identified above” [Datar ¶ 59].
for each complex node and complex relationship in the CICMDB containing a namespace corresponding to the provider associated with the data collector, “In the first approach, the complete topology is stitched every time new snapshots are received, with the prior topology graph being deleted and replaced with the new topology graph” [Datar ¶ 48].
Datar in view of Krishnan in view of Tola fails to explicitly teach wherein, following completion of a data-collection interval.
However, Ramani teaches wherein, following completion of a data-collection interval “The firewall is presumed manageable and, after authenticating with the firewall, it may be configured 406 to perform data capture for a desired period of time. In another embodiment, the firewall is instructed when to start, and when to stop the capture. As discussed above, captured data may be analyzed. In the illustrated embodiment, captured data packets may be analyzed 408 to determine Server Name Indication (SNI) data” [Ramani Col. 15-16 Lines 64-67, 1-4].
Datar in view of Krishnan in view of Tola in view of Ramani fails to explicitly teach containing a namespace corresponding to the provider.
However, Kancharla teaches containing a namespace corresponding to the provider “For example, one or more datasets, database tables, namespaces, and/or metadata may be stored in database 136” [Kancharla ¶ 38]. “Additionally, once set up, the data for such namespaces may be saved and/or updated based on the cadences of the member datasets. For instance, data for such a namespace may be periodically updated based on a cadence of a real-time data source, as one possible example” [Kancharla ¶ 28]. “The computing device may update such a namespace, for instance by re-executing the relational join query based on updated data received from the first and/or second real-time data sources” [Kancharla ¶ 91].
Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla fails to explicitly teach the namespace corresponding to the provider associated with the data collector is deleted when no information regarding the complex node or complex relationship was reported by the data collector during the data-collection interval.
However, Greer teaches the namespace corresponding to the provider associated with the data collector is deleted when no information regarding the complex node or complex relationship was reported by the data collector during the data-collection interval. “Similarly, any logical blocks of the reference namespace for which data was deleted in the corresponding snapshot namespace may result in the deletion of the logical blocks (e.g., by marking the logical blocks as empty) in the reference namespace (and may also result in the erasure of the data from memory 116). For example, if data B had been deleted from LB 1 of the snapshot namespace, data B may be deleted from PA 1 of memory 116 and the pointer to PA 1 in the L2P table 124A' of the reference namespace 202' may be removed” [Greer ¶ 58]. “The vendor specific delete snapshot namespace command may result in the deletion of a snapshot namespace (which may involve unmapping logical blocks of the snapshot namespace to the reference namespace and the deletion or deallocation of physical blocks used to store updated data of the snapshot namespace)” [Greer ¶ 73].
Greer is considered to be analogous to the claimed invention because it is in the same field of updating storage structures. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla to incorporate the teachings of Greer and include: the namespace corresponding to the provider associated with the data collector is deleted when no information regarding the complex node or complex relationship was reported by the data collector during the data-collection interval. Doing so would allow for the freeing of unused space in memory. “Similarly, any logical blocks of the reference namespace for which data was deleted in the corresponding snapshot namespace may result in the deletion of the logical blocks (e.g., by marking the logical blocks as empty) in the reference namespace (and may also result in the erasure of the data from memory 116). For example, if data B had been deleted from LB 1 of the snapshot namespace, data B may be deleted from PA 1 of memory 116 and the pointer to PA 1 in the L2P table 124A' of the reference namespace 202' may be removed” [Greer ¶ 58].
Claims 15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Datar (US 2023/0102572 A1) in view of Krishnan (US 2023/0138971 A1) in view of Tola (US 2020/0328885 A1) in view of Ramani (US 11,588,840 B2) in view of Kancharla (US 2022/0358123 A1) in view of Greer (US 2017 /0344430 A1) in view of Oikarinen (US 2015/0277802 A1).
With regard to claim 15, Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla in view of Greer teaches the meta-level management system of claim 14 as referenced above. Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla in view of Greer fails to teach following deletion of a namespace corresponding to the provider associated with the data collector from a complex node or a complex resource of the second type, when the complex node or complex resource contains no namespaces, the complex node is deleted.
However, Oikarinen teaches following deletion of a namespace corresponding to the provider associated with the data collector from a complex node or a complex resource of the second type, when the complex node or complex resource contains no namespaces, the complex node is deleted. “When a namespace entry E is to be deleted (e.g., when the corresponding file or directory is deleted at a client's request), the EL node from which the entry is to be deleted may be found using the hash-based traversal technique outlined above, in which respective subsequences of the hash value for the name of the object are used as indexes at successive levels of the HDAG. The EL node from which the entry is to be removed may be referred to as the deletion target node. If the deletion target contains more than one entry, E's entry may simply be deleted or marked as free, and no additional operations may be required. However, if there were no other namespace entries at the deletion target (i.e., if removing E's entry would result in an empty entry list), then the deletion target node itself may have to be deleted … The Juliet entry may be deleted (as indicated by the "X" symbol and the accompanying label "1 ".) Because removing Juliet's entry results in an empty entry list at node 4950, node 4950 may itself have to be deleted” [Oikarinen ¶ 256, Fig. 49].
Oikarinen is considered to be analogous to the claimed invention because it is in the same field of updating database structures. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla in view of Greer to incorporate the teachings of Oikarinen and include: following deletion of a namespace corresponding to the provider associated with the data collector from a complex node or a complex resource of the second type, when the complex node or complex resource contains no namespaces, the complex node is deleted. Doing so would allow for the freeing of unused space in memory. “In addition, in the depicted embodiment, the deletion target node 4950 may be freed, e.g., by sending a request to release its storage space to the storage subsystem” [Oikarinen ¶ 257].
With regard to claim 19, Datar in view of Krishnan in view of Tola in view of Ramani teaches the method of claim 18 as referenced above. Datar further teaches:
the provider associated with the inventory collector; “For example, the computing system 300 may utilize available collectors to obtain configuration values for each of the domains for the layers of the stack. Collectors may be open source, provided by vendors, or otherwise available, and may include, e.g., APIs (application programming interfaces), SDKs (software development kits), or other tools such as Prometheus or Telegraf)” [Datar ¶ 29].
each complex node and complex relationship in the ICMDB for which the data collector receives inventory and configuration information from the provider associated with the inventory collector is updated by “The delta configuration streams together with a last snapshot 518 are received by the topology stitcher job 550. For the delta configuration, the topology stitcher job 550 presents a node add/update stream 562, a relationship add/update stream 564, and a combination (or move) add/update stream 566 to the graph database connector 580” [Datar ¶ 60].
updating one or more general labels and/or general properties using the received inventory and configuration information; “The DSL can be used to translate and categorize an event that has occurred to one of the below events: (a) New entity; (b) Deleted entity; (c) New property for existing entity; (d) Deleted property for existing entity; or (e) Changed property for existing entity. On premise collectors may not be capable of deriving the delta, and thus the events will need to be derived at the backend server 350 for example” [Datar ¶ 51-57]. “In terms of a graph database representation, the topology is a natural graph. Reported entities are reported as nodes (vertices) of the graph, where each vertex has a set of properties that get reported. Most of the "edges" (relationships) of the graph are derived based on these properties by the topology stitching algorithm” [Datar ¶ 78].
of the complex nodes and complex relationships using the received inventory and configuration information; “In the first approach, the complete topology is stitched every time new snapshots are received, with the prior topology graph being deleted and replaced with the new topology graph. Alternatively, the nodes and edges of the topology snapshots may be overwritten and merged with the existing topology graph. In this manner, a static view of a full end-to-end stack is presented” [Datar ¶ 48].
updating one or more namespace-associated labels and/or namespace-associated properties using the received inventory and configuration information; “The DSL can be used to translate and categorize an event that has occurred to one of the below events: (a) New entity; (b) Deleted entity; (c) New property for existing entity; (d) Deleted property for existing entity; or (e) Changed property for existing entity. On premise collectors may not be capable of deriving the delta, and thus the events will need to be derived at the backend server 350 for example” [Datar ¶ 51-57]. “In terms of a graph database representation, the topology is a natural graph. Reported entities are reported as nodes (vertices) of the graph, where each vertex has a set of properties that get reported. Most of the "edges" (relationships) of the graph are derived based on these properties by the topology stitching algorithm” [Datar ¶ 78].
…during which a data collector has collected inventory and configuration information from the provider associated with the data collector, “For example, the computing system 300 may utilize available collectors to obtain configuration values for each of the domains for the layers of the stack. Collectors may be open source, provided by vendors, or otherwise available, and may include, e.g., APIs (application programming interfaces), SDKs (software development kits), or other tools such as Prometheus or Telegraf)” [Datar ¶ 29]. “Configuration changes are identified (which may be performed by, for example, using a SQL lag function) to obtain a last value of a column (in, for example, SQL or Spark SQL), and comparing this last value with a new value. Such a configuration change could be any of the events (a)-(e) identified above” [Datar ¶ 59].
each complex node and complex relationship in the ICMDB for which the provider associated with the data collector is the primary data source and for which no information was reported by the data collector during the data-collection interval is deleted; “The generated topology of a configuration stack may be maintained in the form of a view or "snapshot" that represents the complete topology at a particular time. In the first approach, the complete topology is stitched every time new snapshots are received, with the prior topology graph being deleted and replaced with the new topology graph” [Datar ¶ 48]. “The DSL can be used to translate and categorize an event that has occurred to one of the below events: (a) New entity; (b) Deleted entity; (c) New property for existing entity; (d) Deleted property for existing entity; or (e) Changed property for existing entity. On premise collectors may not be capable of deriving the delta, and thus the events will need to be derived at the backend server 350 for example” [Datar ¶ 51-57].
during which a data collector has collected inventory and configuration information from the provider associated with the data collector, “For example, the computing system 300 may utilize available collectors to obtain configuration values for each of the domains for the layers of the stack. Collectors may be open source, provided by vendors, or otherwise available, and may include, e.g., APIs (application programming interfaces), SDKs (software development kits), or other tools such as Prometheus or Telegraf)” [Datar ¶ 29]. “Configuration changes are identified (which may be performed by, for example, using a SQL lag function) to obtain a last value of a column (in, for example, SQL or Spark SQL), and comparing this last value with a new value. Such a configuration change could be any of the events (a)-(e) identified above” [Datar ¶ 59].
for each complex node and complex relationship in the ICMDB containing a namespace corresponding to the provider associated with the data collector, “In the first approach, the complete topology is stitched every time new snapshots are received, with the prior topology graph being deleted and replaced with the new topology graph” [Datar ¶ 48].
Datar in view of Krishnan in view of Tola fails to explicilty teach wherein the management subsystem from which an inventory collector collects inventory and configuration data is the provider … wherein each inventory collector collects data from the provider associated with the inventory collector during data-collection intervals that begin at scheduled collection times; wherein, during a data-collection interval for a data collector, when the provider associated with the inventory collector is the primary data source for the complex node and when the provider associated with the inventory collector is a secondary data source for the complex node… wherein, following completion of a data-collection interval.
However, Ramani teaches:
wherein the management subsystem from which an inventory collector collects inventory and configuration data is the provider “The entity seeking the detection may access 208 the captured data. It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data. If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col. 12-13 Lines 65-67, 1-9].
wherein each inventory collector collects data from the provider associated with the inventory collector “It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data. If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col. 12-13 Lines 66-67, 1-9]. “In the illustrated embodiment, an organization is hosted by a cloud service, and illustrated are one or more cloud account 502 which may be associated with a cloud service(s). For convenience we assume the cloud service(s) is Amazon Web Service (AWS) compatible, and providing Amazon Elastic Compute Cloud (EC2) environments and other service. Shown are one or more Virtual Private Cloud (VPC) 504 associated the cloud account(s). Each VPC may have one or more associated firewalls(s) 506, and it is assumed a VPC represents a private environment that appears from external perspective to be a conventional computing environment” [Ramani Col. 18 Lines 47-58].
during data-collection intervals that begin at scheduled collection times. “The detector may instruct a selected device to capture 206 (record) data traffic between the source and destination for a period of time, e.g., three minutes. One skilled in the art will recognize the time frame is arbitrary, the purpose is to collect enough data to allow meaningful analysis. The time could be longer or shorter, and results (or lack thereof) may be used as an indicator of need to adjust timing. In another embodiment, characteristics of data flowing past may help to determine when to start or stop data capture. For example, a TLS handshake where a server (destination) is authenticated by its certificate, has known "ClientHello" messaging along with a back and forth of negotiation messages until the server, sends a "Finished" message. The capture may therefore be triggered around the handshake with perhaps a window of data, if desired, buffered and captured to encompass a period before and after the handshaking” [Ramani Col. 12 Lines 48-55].
wherein, during a data-collection interval for a data collector, “The firewall is presumed manageable and, after authenticating with the firewall, it may be configured 406 to perform data capture for a desired period of time. In another embodiment, the firewall is instructed when to start, and when to stop the capture. As discussed above, captured data may be analyzed” [Ramani Col. 15-16 Lines 64-67, 1-2].
when the provider associated with the inventory collector is the primary data source for the complex node, “The entity seeking the detection may access 208 the captured data. It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (provider) (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data” [Ramani Col. 12-13 Lines 65-67, 1-5].
and when the provider associated with the inventory collector is a secondary data source for the complex node, “It will be appreciated the access may be direct or indirect depending on what is capturing the data and who has responsibility for the detector. For example, a firewall (or other intermediary) may perform the detecting. If the firewall belongs to an organization (see, e.g., FIG. 5 item 504 discussion) the organization may have direct access to the data. If the detecting is performed by the cloud service provider, or other entity, e.g., a third party security entity, then the captured data may be stored in the firewall and/or stored in a data store (such as a database) and made available to an organization and/or the cloud service” [Ramani Col. 12-13 Lines 66-67, 1-9].
wherein, following completion of a data-collection interval “The firewall is presumed manageable and, after authenticating with the firewall, it may be configured 406 to perform data capture for a desired period of time. In another embodiment, the firewall is instructed when to start, and when to stop the capture. As discussed above, captured data may be analyzed. In the illustrated embodiment, captured data packets may be analyzed 408 to determine Server Name Indication (SNI) data” [Ramani Col. 15-16 Lines 64-67, 1-4].
wherein, following completion of a data-collection interval “The firewall is presumed manageable and, after authenticating with the firewall, it may be configured 406 to perform data capture for a desired period of time. In another embodiment, the firewall is instructed when to start, and when to stop the capture. As discussed above, captured data may be analyzed. In the illustrated embodiment, captured data packets may be analyzed 408 to determine Server Name Indication (SNI) data” [Ramani Col. 15-16 Lines 64-67, 1-4].
Datar in view of Krishnan in view of Tola in view of Ramani fails to explicitly teach updating one or more namespace-associated labels and/or namespace-associated properties … containing a namespace corresponding to the provider.
However, Kancharla teaches:
updating one or more namespace-associated labels and/or namespace-associated properties. “Based on the key columns of the first and second datasets, the computing device may be configured to join the first and second datasets to form a namespace. Such a namespace may comprise a logical view that may contain attributes from one or more datasets (two datasets in this example)” [Kancharla ¶ 27]. “Based on a cadence of the batch and/or real-time data sources, the computing device may update the namespace. For instance, if the real-time data source has an update cadence of once per minute, the computing device may add data to the namespace or replace data in the namespace. The computing device may be configured to modify a namespace based on one or more data source cadences in various other manners as well” [Kancharla ¶ 82]. “In some examples, such a namespace may be updated based on a cadence associated with the first data source and/or the second data source. For instance, if the first real-time data source has an update cadence of once per 30 minutes, the computing device may update the namespace once per 30 minutes (e.g., at the update cadence). The computing device may update such a namespace, for instance by re-executing the relational join query based on updated data received from the first and/or second real-time data sources” [Kancharla ¶ 91].
containing a namespace corresponding to the provider “For example, one or more datasets, database tables, namespaces, and/or metadata may be stored in database 136” [Kancharla ¶ 38]. “Additionally, once set up, the data for such namespaces may be saved and/or updated based on the cadences of the member datasets. For instance, data for such a namespace may be periodically updated based on a cadence of a real-time data source, as one possible example” [Kancharla ¶ 28]. “The computing device may update such a namespace, for instance by re-executing the relational join query based on updated data received from the first and/or second real-time data sources” [Kancharla ¶ 91].
Kancharla is considered to be analogous to the claimed invention because it is in the same field of updating database structures. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan in view of Tola in view of Ramani to incorporate the teachings of Kancharla and include: updating one or more namespace-associated labels and/or namespace-associated properties … containing a namespace corresponding to the provider. Doing so would allow for the joining of two datasets with data for the same entities that have different cadences. “Based on the key columns of the first and second datasets, the computing device may be configured to join the first and second datasets to form a namespace. Such a namespace may comprise a logical view that may contain attributes from one or more datasets (two datasets in this example) … By joining data sets in accordance with the techniques described herein, the overall surface area of datasets may be increased, which may allow for the creation of a single dataset that comprise data from multiple datasets having different cadences” [Kancharla ¶ 27].
Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla fails to explicitly teach the namespace corresponding to the provider associated with the data collector is deleted when no information regarding the complex node or complex relationship was reported by the data collector during the data-collection interval.
However, Greer teaches the namespace corresponding to the provider associated with the data collector is deleted when no information regarding the complex node or complex relationship was reported by the data collector during the data-collection interval; “Similarly, any logical blocks of the reference namespace for which data was deleted in the corresponding snapshot namespace may result in the deletion of the logical blocks (e.g., by marking the logical blocks as empty) in the reference namespace (and may also result in the erasure of the data from memory 116). For example, if data B had been deleted from LB 1 of the snapshot namespace, data B may be deleted from PA 1 of memory 116 and the pointer to PA 1 in the L2P table 124A' of the reference namespace 202' may be removed” [Greer ¶ 58]. “The vendor specific delete snapshot namespace command may result in the deletion of a snapshot namespace (which may involve unmapping logical blocks of the snapshot namespace to the reference namespace and the deletion or deallocation of physical blocks used to store updated data of the snapshot namespace)” [Greer ¶ 73].
Greer is considered to be analogous to the claimed invention because it is in the same field of updating storage structures. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla to incorporate the teachings of Greer and include: the namespace corresponding to the provider associated with the data collector is deleted when no information regarding the complex node or complex relationship was reported by the data collector during the data-collection interval. Doing so would allow for the freeing of unused space in memory. “Similarly, any logical blocks of the reference namespace for which data was deleted in the corresponding snapshot namespace may result in the deletion of the logical blocks (e.g., by marking the logical blocks as empty) in the reference namespace (and may also result in the erasure of the data from memory 116). For example, if data B had been deleted from LB 1 of the snapshot namespace, data B may be deleted from PA 1 of memory 116 and the pointer to PA 1 in the L2P table 124A' of the reference namespace 202' may be removed” [Greer ¶ 58].
Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla in view of Greer fails to teach and wherein, following deletion of a namespace corresponding to the provider associated with the data collector from a complex node or a complex resource of the second type, when the complex node or complex resource contains no namespaces, the complex node is deleted.
However, Oikarinen teaches and wherein, following deletion of a namespace corresponding to the provider associated with the data collector from a complex node or a complex resource of the second type, when the complex node or complex resource contains no namespaces, the complex node is deleted. “When a namespace entry E is to be deleted (e.g., when the corresponding file or directory is deleted at a client's request), the EL node from which the entry is to be deleted may be found using the hash-based traversal technique outlined above, in which respective subsequences of the hash value for the name of the object are used as indexes at successive levels of the HDAG. The EL node from which the entry is to be removed may be referred to as the deletion target node. If the deletion target contains more than one entry, E's entry may simply be deleted or marked as free, and no additional operations may be required. However, if there were no other namespace entries at the deletion target (i.e., if removing E's entry would result in an empty entry list), then the deletion target node itself may have to be deleted … The Juliet entry may be deleted (as indicated by the "X" symbol and the accompanying label "1 ".) Because removing Juliet's entry results in an empty entry list at node 4950, node 4950 may itself have to be deleted” [Oikarinen ¶ 256, Fig. 49].
Oikarinen is considered to be analogous to the claimed invention because it is in the same field of updating database structures. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Datar in view of Krishnan in view of Tola in view of Ramani in view of Kancharla in view of Greer to incorporate the teachings of Oikarinen and include: and wherein, following deletion of a namespace corresponding to the provider associated with the data collector from a complex node or a complex resource of the second type, when the complex node or complex resource contains no namespaces, the complex node is deleted. Doing so would allow for the freeing of unused space in memory. “In addition, in the depicted embodiment, the deletion target node 4950 may be freed, e.g., by sending a request to release its storage space to the storage subsystem” [Oikarinen ¶ 257].
Allowable Subject Matter
Claims 8-10 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, and rewritten to overcome the outstanding rejections under U.S.C. 112(b).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/A.F.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights