Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on September 8, 2026 has been entered.
Claims 1, 2, 4-10, 12-18, and 21-24 are pending. Claims 1, 9, 17, 21, 23 and 24 are amended. Claims 3, 11, 19 and 20 have been cancelled.
Response to Arguments
Referring to the 35 USC 101 rejection of claims 9, 10, 12-18, 23 and 24, Applicant’s amendments are acknowledged. As such, the 35 USC 101 rejection of the aforenoted claims is withdrawn.
Referring to the objections to claims 9 and 17, Applicant’s amendments to the claims are acknowledged. As such, the objections to the claims are withdrawn.
Referring to the 35 USC 112(b) rejection of claims 1, 2, 4-10, 12-18 and 21-24, Applicant’s amendments to the claims are acknowledged. As such, the 35 USC 112(b) rejection of the aforenoted claims is withdrawn.
Applicant’s arguments with respect to claims 1, 2, 4-10, 12-18, and 21-24, as amended, have been considered but are moot in view of the new grounds of rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 5-10, and 13-18, and 21-24 are rejected under 35 U.S.C. 103 as being unpatentable over US 2023/0297851 by Sbodio et al (hereafter Sbodio), in view of US 2025/0094835 by Lowinger et al (hereafter Lowinger), and further in view of US 2019/0303367 by Hsiao et al (hereafter Hsaio).
Referring to claim 1, Sbodio discloses a method [Abstract] comprising:
generating a domain-specific knowledge graph related to a network of computation resources comprising domain-specific data descriptive of the computation resources, the domain-specific knowledge graph comprising a plurality of domain-specific features connected via a plurality of domain-specific relationships [wherein an initial knowledge graph is created with one or more curated and focused datasets of elements and relationships to a subject (e.g. type of vehicle), para 12-14, 20; Fig 3, element 302, para 51; knowledge graph is a semantic network, para 1], wherein a machine learning model assigns weights to the plurality of domain-specific relationships [controller assigns weights to crawled data that matches knowledge graph data, para 20, 28, 34];
responsive to receiving an input tag, locating in the domain-specific knowledge graph, an input node corresponding to the input tag, extracting a subset of domain-specific features of the plurality of domain-specific features connected to the input node via a subset of domain-specific relationships of the plurality of domain-specific relationships [second set of data on one or more domains of entity is received and public repositories or the like within the domain are crawled to identify data that matches nodes of the initial knowledge graph and underlying data detailing the association (i.e. relationships), para 52, Fig 3, element 304; wherein the nodes of the initial knowledge graph are analyzed to identify domains of the entity as a potential domain for searching within, after which the crawling takes place, para 52], and extracting a subset of weights assigned to the domain-specific relationships of the plurality of domain-specific relationships corresponding to the subset of domain-specific features [controller crawls across databases to identify data that may match the knowledge graph. If the controller finds any data that appears to match (whether as a node or an edge or both), the controller may input this into the knowledge graph along with the respective score/weights for this data, para 20];
generating a metadata score algorithm for the input tag that weights the subset of domain-specific features according to the subset of weights [confidence and reliability scores are calculated for each probabilistic edge and pertaining to each element and extracted relation, para 28, 53, Fig 3, element 306; the generation of probabilistic knowledge graphs is performed by generating and applying machine learning algorithms, para 48], wherein each domain-specific feature in the subset of domain-specific features represents a variable parameter of the metadata score algorithm [entities are variable, e.g. entity could be a human or a material, para 24];
computing a respective metadata tag score corresponding to the input tag for each respective computation resource of the computation resources by obtaining respective metadata descriptive of the respective computation resource, the respective metadata comprising values for attributes corresponding to the subset of domain-specific features, populating variable parameters of the metadata score algorithm corresponding to the subset of domain-specific features with the values from the respective metadata descriptive of to the computation resources [confidence scores that include a first element reflecting a likelihood of the probability relating to the entity, and a second element quantifying/reflecting a reliability of the underlying data, are calculated for each probabilistic edge and pertaining to each element, para 53-54, Fig 3, element 306; probabilistic data related to the entity that are crawled by controller 110 and their attributes are determined with respect to whether they should be added to the probabilistic KG 120, para 26-32; each relation between the entities is assigned a combined score (i.e. reads on: metadata tag score) that reflects the probability score and reliability of the data source associated with the selected relation- score may be adjusted if there is support from more trusted data sources, para 31-33; machine learning algorithm is applied to enable controller to identify certain types of data within domain data 140 that is found to be more predictive and/or useful for different types of entities, para 48; machine learning algorithm is applied, para. 48], and executing the populated metadata score algorithm for the respective computation resource [Controller 110 finishes the act of completing the initial knowledge graph by extending the probabilistic knowledge graph with the n-ary relations calculated for each group of relations associated with an entity, para 31-33];
tagging the computation resources with the input tag by updating the metadata descriptive of each respective computation resource with the input tag and the respective metadata tag score computed for the respective computation resource [probabilistic KG is generated and stored such that confidence scores are stored as metadata associated with each respective edge as a combined confidence score/weight and/or sub scores/weights relating to individual factors, para 34; each relation between the entities is assigned a combined score that reflects the probability score and reliability of the data source associated with the selected relation- score may be adjusted if there is support from more trusted data sources, para 31]; and
configuring the network of computation resources by clustering the computation resources according to the updated metadata descriptive of the computation resources [confidence scores are normalized in clusters within a given probabilistic KG, para 54; downstream evaluations using probabilistic KG, para 55, Fig 3, element 308].
While Sbodio discloses all of the above claimed subject matter and also discloses that controller 110 can query domain knowledge 140 for data and gather and extract data that relates to the entity (i.e. reads on metadata) that might be incorporated into probabilistic KG 120 [para 25-26] and that the probabilistic KG is used to execute downstream evaluations [para 54-55], it remains silent as to the domain-specific knowledge graph being generated by a machine learning model; the query for metadata being received via an API; and directing data traffic within the network.
Lowinger discloses that LLMs are used to extract information identifying constructors, constructs and categories of constructs, which are used by the data layer to store a knowledge graph with the extracted data [para 164, 296].
Sbodio and Lowinger are analogous art because they are directed to the same field of endeavor- analysis of data within knowledge graphs. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the initial knowledge graph of Sbodio to include the use of the LLMs of Lowinger in generating the initial knowledge graph because it would achieve predicable results.
The ordinary skilled artisan would have been motivated to make this modification since both Sbodio and Lowinger are directed to the use of machine learning analysis for data with the knowledge graphs. The use of the LLMs in Lowinger provides a refinement to the type of machine learning model used.
Still referring to claim 1, while Sbodio/Lowinger discloses all of the above claimed subject matter, also discloses that controller 110 can query domain knowledge 140 for data [Sbodio, para 26] and that the probabilistic KG is used to execute downstream evaluations [Sbodio, para 54-55], it remains silent as to the query for metadata being received via an API; and directing data traffic within the network.
Hsiao discloses that a Java DataBase Connectivity (JDBC) API may be used to execute a combined query, to retrieve metadata attributes (e.g., column names, column order) for data obtained from each data source for the query [para 74, 129, Fig 8, element 804]. Hsiao furthermore discloses analysis of real-time event data related to network performance measuring tools such as network monitoring and traffic management applications [para 184].
Sbodio, Lowinger and Hsaio are analogous art because they are directed to the same field of endeavor- analysis of data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the input queries by the controller in Sbodio to include the query API within the data insight layer of Hsiao and to modify the downstream evaluations applications in Sbodio to include the network traffic monitoring of Hsiao because it would achieve predicable results.
The ordinary skilled artisan would have been motivated to make these modifications because the query API of Hsiao refines the source that the query of Sbodio comes from and the network traffic monitoring application of Hsiao further refines the type of downstream evaluations of data taught by Sbodio.
Referring to claim 9, the limitations of the claim are similar to those of claim 1 in the form of a system [Sbodio, para 2, Fig 1, environment 100] comprising a memory storing instructions [Sbodio, para 23, Fig 1]; and at least one processor [Sbodio, para 23, Fig 1]. As such, claim 9 is rejected for the same reasons as claim 1.
Referring to claim 17, Sbodio discloses a non-transitory computer-readable storage medium storing instructions that, when executed by a processor [memory 230, processor 220, para 44, Fig 2], cause the processor to:
construct a domain-specific knowledge graph comprising domain-specific data descriptive of a network of computation resources, the domain-specific knowledge graph comprising a plurality of domain-specific features connected via a plurality of domain-specific relationships [wherein an initial knowledge graph is created with one or more curated and focused datasets of elements and relationships to a subject (e.g. type of vehicle), para 12-14, 20; Fig 3, element 302, para 51; knowledge graph is a semantic network, para 1], wherein a machine learning model assigns weights to the plurality of domain-specific relationships [controller assigns weights to crawled data that matches knowledge graph data, para 20, 28, 34];
generate a metadata score algorithm for one or more input tags, received from a user device, based on the domain-specific knowledge graph [second set of data on one or more domains of entity is received, para 52, Fig 3, element 304; generation of probabilistic KG 120 includes probabilities, para 53, Fig 3, element 306], wherein generating the metadata score algorithm comprises locating, in the domain-specific knowledge graph, input nodes corresponding to the one or more input tags, extracting subsets of domain-specific features of the plurality of domain-specific features connected to the input nodes via subsets of domain-specific relationships of the plurality of domain-specific relationships [second set of data on one or more domains of entity is received and public repositories or the like within the domain are crawled to identify data that matches nodes of the initial knowledge graph and underlying data detailing the association (i.e. relationships), para 52, Fig 3, element 304; wherein the nodes of the initial knowledge graph are analyzed to identify domains of the entity as a potential domain for searching within, after which the crawling takes place, para 52], and extracting subsets of weights assigned to the subsets of domain-specific relationships, wherein the metadata score algorithm weights the subset of domain-specific features according to the subset of weights [controller crawls across databases to identify data that may match the knowledge graph. If the controller finds any data that appears to match (whether as a node or an edge or both), the controller may input this into the knowledge graph along with the respective score/weights for this data, para 20], wherein each domain-specific feature in the subsets of domain-specific features represents a variable parameter of the metadata score algorithm [entities are variable, e.g. entity could be a human or a material, para 24];
determine a respective metadata tag score corresponding to the one or more input tags for each respective computation resource of the computation resources by obtaining respective metadata descriptive of the respective computation resources, the respective metadata comprising values for attributes corresponding to the subset of domain-specific features, populating variable parameters of the metadata score algorithm with values from the respective metadata descriptive of the respective computation resource [confidence scores that include a first element reflecting a likelihood of the probability relating to the entity, and a second element quantifying/reflecting a reliability of the underlying data, are calculated for each probabilistic edge and pertaining to each element, para 53-54, Fig 3, element 306; probabilistic data related to the entity that are crawled by controller 110 and their attributes are determined with respect to whether they should be added to the probabilistic KG 120, para 26-32; each relation between the entities is assigned a combined score (i.e. reads on: metadata tag score) that reflects the probability score and reliability of the data source associated with the selected relation- score may be adjusted if there is support from more trusted data sources, para 31-33; machine learning algorithm is applied to enable controller to identify certain types of data within domain data 140 that is found to be more predictive and/or useful for different types of entities, para 48; machine learning algorithm is applied, para. 48]; and executing the populate metadata score algorithm for the respective computation resource [Controller 110 finishes the act of completing the initial knowledge graph by extending the probabilistic knowledge graph with the n-ary relations calculated for each group of relations associated with an entity, para 31-33];
update the metadata descriptive of each respective computation resource to include the one or more input tags and the respective metadata tag score computed for the respective computation resource [probabilistic KG is generated and stored such that confidence scores are stored as metadata associated with each respective edge as a combined confidence score/weight and/or sub scores/weights relating to individual factors, para 34; each relation between the entities is assigned a combined score that reflects the probability score and reliability of the data source associated with the selected relation- score may be adjusted if there is support from more trusted data sources, para 31]; and
configure the network of computation resources by determining a configuration of the network of computation resources from the updated metadata descriptive of the computation resource [confidence scores are normalized in clusters within a given probabilistic KG, para 54; downstream evaluations using probabilistic KG, para 55, Fig 3, element 308].
While Sbodio discloses all of the above claimed subject matter and also discloses that controller 110 can query domain knowledge 140 for data [para 26] and gather and extract data that relates to the entity (i.e. reads on metadata) that might be incorporated into probabilistic KG 120 [para 25-26] and that the probabilistic KG is used to execute downstream evaluations [para 54-55], it remains silent as to the domain-specific knowledge graph being generated by an LLM; the query for metadata being received via an API; and directing data traffic within the network.
Lowinger discloses that LLMs are used to extract information identifying constructors, constructs and categories of constructs, which are used by the data layer to store a knowledge graph with the extracted data [para 164, 296].
Sbodio and Lowinger are analogous art because they are directed to the same field of endeavor- analysis of data within knowledge graphs. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the initial knowledge graph of Sbodio to include the use of the LLMs of Lowinger in generating the initial knowledge graph because it would achieve predicable results.
The ordinary skilled artisan would have been motivated to make this modification since both Sbodio and Lowinger are directed to the use of machine learning analysis for data with the knowledge graphs. The use of the LLMs in Lowinger provides a refinement to the type of machine learning model used.
Still referring to claim 17, while Sbodio/Lowinger discloses all of the above claimed subject matter, also discloses that controller 110 can query domain knowledge 140 for data [Sbodio, para 26] and that the probabilistic KG is used to execute downstream evaluations [Sbodio, para 54-55], it remains silent as to the query for metadata being received via an API; and directing data traffic within the network.
Hsiao discloses that a Java DataBase Connectivity (JDBC) API may be used to execute a combined query, to retrieve metadata attributes (e.g., column names, column order) for data obtained from each data source for the query [para 74, 129, Fig 8, element 804]. Hsiao furthermore discloses analysis of real-time event data related to network performance measuring tools such as network monitoring and traffic management applications [para 184].
Sbodio, Lowinger and Hsaio are analogous art because they are directed to the same field of endeavor- analysis of data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the input queries by the controller in Sbodio to include the query API within the data insight layer of Hsiao and to modify the downstream evaluations applications in Sbodio to include the network traffic monitoring of Hsiao because it would achieve predicable results.
The ordinary skilled artisan would have been motivated to make these modifications because the query API of Hsiao refines the source that the query of Sbodio comes from and the network traffic monitoring application of Hsiao further refines the type of downstream evaluations of data taught by Sbodio.
Referring to claims 2 and 10, Sbodio/Lowinger/Hsiao discloses that the machine learning model comprises a Large Language Model (LLM) [Lowinger, para 164, 296].
Referring to claims 5 and 13, Sbodio/Lowinger/Hsiao discloses inputting data descriptive of the computation resources into the machine learning model as the domain-specific data [Lowinger, LLMs extract information identifying constructors, constructs and categories of constructs, which are used by the data layer to store a knowledge graph with the extracted data, para 164, 296].
Referring to claims 6 and 14, Sbodio/Lowinger/Hsiao discloses that the domain-specific knowledge graph comprises a plurality of nodes representing the plurality of domain-specific features and a plurality of connections between the plurality of nodes representing the plurality of domain-specific relationships [Sbodio, knowledge graph has nodes and edges, para 11-12, 20; Lowinger, LLM, para 164, 296].
Referring to claims 7 and 15, Sbodio/Lowinger/Hsiao discloses that the input tag corresponds to an input node of the domain-specific knowledge graph and the subset of domain-specific features corresponds to a subset of nodes of the domain-specific knowledge graph connected to the node [Sbodio, nodes of initial knowledge graph, para 52].
Referring to claims 8 and 16, Sbodio/Lowinger/Hsiao discloses that extracting the subset of domain-specific features and the subset of domain-specific relationships comprises: locating the input node, on the domain-specific knowledge graph, corresponding to the input tag; and identifying the subset of nodes of the plurality of nodes connected to the input node, wherein the subset of domain-specific relationships correspond to connectors connecting the input node to each of the subset of nodes [Sbodio, second set of data on one or more domains of entity is received and public repositories or the like within the domain are crawled to identify data that matches nodes of the initial knowledge graph and underlying data detailing the association (i.e. relationships), para 52, Fig 3, element 304].
Referring to claim 18, Sbodio/Lowinger/Hsiao discloses that the domain-specific knowledge graph comprises a plurality of nodes connected via a plurality of connectors, wherein the plurality of nodes are based on a plurality of domain-specific features and the plurality of connectors are based on a plurality of domain-specific relationships between the plurality of nodes, wherein the plurality of domain-specific features and the plurality of domain-specific relationships are determined by the one or more LLMs from the domain-specific data [Sbodio, knowledge graph has nodes and edges, para 11-12, 20; Lowinger, LLM, para 164, 296].
Referring to claims 21, 23 and 24, Sbodio/Lowinger/Hsiao grouping the computation resources according to the updated metadata descriptive of the computation resources and backing up traffic data to computation resources associated with a group having higher metadata tag scores [Sbodio, clustered similar candidate relations are selected with highest relation type score combined with score reflecting probability of the fact, para 31; downstream evaluations such as by a data analyst include determining what types of fact patterns are likely to occur in the future for a specific individual based on the generated probabilistic KG, Sbodio, para 35-37; Hsiao, network traffic monitoring and management application, para 184].
Referring to claim 22, Sbodio/Lowinger/Hsiao discloses classifying the computation resources into categories according to the metadata tag scores; and updating the metadata descriptive of the computation resources by reordering the metadata descriptive of the computation resources according to the categories [Sbodio, para 48].
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Sbodio, in view of Lowinger, in view Hsiao, as applied to claims 1 and 9 above, and further in view of US 2023/0196242 by Kumar et al (hereafter Kumar).
Referring to claims 4 and 12, Sbodio/Lowinger/Hsiao discloses that the computation resources with the knowledge graph comprise conceptual elements [Sbodio, para 11-12], however it remains silent as to the elements comprising one or more virtual machines [Kumar, para 112, Fig 9].
Kumar discloses that a knowledge graph can comprise nodes that represent one or more virtual machines [para 112, Fig 9].
Sbodio, Lowinger, Hsiao and Kumar are analogous art because they are directed to the same field of endeavor- analysis of data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data elements in the knowledge graph of Sbodio to include the one or more virtual machines of Kumar because it would achieve predicable results.
The ordinary skilled artisan would have been motivated to make this modification because the virtual machine nodes of Kumar further refine the type of data elements represented by the knowledge graph of Sbodio.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ganti (US 20140280287) directed to: assisted query formulation that includes querying of APIs for metadata [Abstract; para 79, Fig 11].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHERYL M SHECHTMAN whose telephone number is (571)272-4018. The examiner can normally be reached on M-F: 10am-6: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, Amy Ng can be reached on 571-270-1698. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
CHERYL M SHECHTMANPatent Examiner
Art Unit 2164
/C.M.S/
/AMY NG/Supervisory Patent Examiner, Art Unit 2164
Prosecution Insights