DETAILED ACTION
Claims 1, 9, and 17 are amended. Claims 4, 7-8, 12, 15-16, and 20 are cancelled. Claims 1-3, 5-6, 9-11, 13-14, and 17-19 are pending in the application.
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 .
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 (i.e., changing from AIA to pre-AIA ) 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.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Continued Examination Under 37 CFR 1.114
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 09/02/2026 has been entered.
Claim Rejections - 35 USC § 112(b)
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 1-3, 5-6, 8-11, 13-14, and 16-19 are 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.
The term “a similarity” in claim 1 (lines 18-19) is a relative term which renders the claim indefinite. The term “a similarity” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Specifically, referring to the limitation “a similarity between the at least two nodes based on input output parameters ”, it is not clear how the two nodes are determined as being “similar”, such as comparing nodes’ input/output parameter types, comparing nodes’ input/output parameter contents, comparing nodes’ input/output ages, comparing nodes’ security privileges associated with their input/output parameters, etc. As such, it is unclear how a person of ordinary skill in the art can ascertain two nodes as being similar or not.
For the following analysis, the Examiner will consider any nodes with input/output parameters presenting any similar features as being “similar” nodes.
Claims 2-3, 5-6, and 8 inherit the features of claim 1 and are rejected accordingly.
The terms “similar input parameters” and “similar output parameters” in claim 5 (line 2) are relative terms which render the claim indefinite due to similar reasons presented above with respect to claim 1.
For the following analysis, the Examiner will consider any nodes with input/output parameters presenting any similar features as being “similar”, respectively.
The term “a similarity” in claim 9 (line 18) is a relative term which renders the claim indefinite. The term “a similarity” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Specifically, referring to the limitation “a similarity between the at least two nodes based on input and output parameters ”, it is not clear how the two nodes are determined as being “similar”, such as comparing nodes’ input/output parameter types, comparing nodes’ input/output parameter contents, comparing nodes’ input/output ages, comparing nodes’ security privileges associated with their input/output parameters, etc. As such, it is unclear how a person of ordinary skill in the art can ascertain two nodes as being similar or not.
For the following analysis, the Examiner will consider any nodes with input/output parameters presenting any similar features as being “similar” nodes.
Claims 10-11, 13-14, and 16 inherit the features of claim 9 and are rejected accordingly.
The terms “similar input parameters” and “similar output parameters” in claim 13 (line 2) are relative terms which render the claim indefinite due to similar reasons presented above with respect to claim 9.
For the following analysis, the Examiner will consider any nodes with input/output parameters presenting any similar features as being “similar”, respectively.
The term “a similarity” in claim 17 (line 16) is a relative term which renders the claim indefinite. The term “a similarity” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Specifically, referring to the limitation “a similarity between the at least two nodes based on input output parameters ”, it is not clear how the two nodes are determined as being “similar”, such as comparing nodes’ input/output parameter types, comparing nodes’ input/output parameter contents, comparing nodes’ input/output ages, comparing nodes’ security privileges associated with their input/output parameters, etc. As such, it is unclear how a person of ordinary skill in the art can ascertain two nodes as being similar or not.
For the following analysis, the Examiner will consider any nodes with input/output parameters presenting any similar features as being “similar” nodes.
Claims 18-19 inherit the features of claim 17 and are rejected accordingly.
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.
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‐3, 5-6, 9-11, 13-14, and 17-19 are rejected under 35 U.S.C 103 as being unpatentable over Bahrami et al. (US 10,853,150 B1; hereinafter “Bahrami”) in view of Alli et al. (US 2016/0358354 A1; hereinafter “Alli”) and Sharma (US 2023/0129050 A1).
With respect to claim 1, Bahrami teaches: A method for integration of software products deployed on a container-based cluster, the method comprising:
extracting, by a computing system via a parameter extraction module (see e.g. Bahrami, Fig. 1: “Mining Module 120”), configuration parameters associated with a plurality of software products available on the container-based cluster in a predefined format based on Application Programming Interface (APls) associated with the plurality of software products (see e.g. Bahrami, column 3, lines 58-64: “The mining module 120 may then "mine" the API documentation of the corpus of API documentation 110. In some embodiments, mining the API documentation may include extracting triples from the API documentation. In some embodiments, a triple may include a Resource Description Framework (RDF) triple. A triple may include a subject, a predicate, and an object”), wherein an API descriptor of an API is parsed to identify a route to be called for a software product while extracting configuration the parameters (see e.g. Bahrami, column 11, lines 11-18: “The graph parser 370 may parse the nodes of the API knowledge graph 360 based on the SPARQL query 350 to identify a result 380 in response to the natural language text 310. For example, the graph parser 370 may identify a relevant API and an associated function and/or call of the API using the API knowledge graph 360. The graph parser 370 may execute the call of the API using the SPARQL query 350 to generate the result 380”);
generating, by the computing system via a node and event generation module (see e.g. Bahrami, Fig. 1: “Extension Module 150”), a plurality of integration nodes and events for the plurality of software products based on the configuration parameters, wherein each of the plurality of software products comprises a set of nodes and a set of events (see e.g. Bahrami, column 9, lines 23-29: “the extended OAS ontology nodes 216 may include nodes generated based on objects and instances such as the objects 125 and the instances 145 of FIG. 1. In these and other embodiments, the extended OAS ontology nodes 216 may also include nodes added based on objects with extensible properties”), and wherein each of the set of nodes comprises input parameters and output parameters (see e.g. Bahrami, column 8, lines 54-56: “user queries may involve the structure and/or functioning of the APIs themselves. For example, a user query may ask what the output is of a particular function”; and column 2, lines 26-29: “Each API may have its own definition of methods, parameters, attributes, input/output data types, and descriptions of each of these”), and wherein each of the set of nodes is assigned with a tag that represents a type for that node (see e.g. Bahrami, column 6, lines 11-19: “For example, the extension module 150 may infer a class associated with each instance 145 based on an OAS from the OAS repository. For example, the extension module 150 may compare field names, parameters, and attributes to determine that a particular object is an instance of an "operation object." Analogously, the extension module 150 may determine that a particular object is an instance of a parameter object or any other type of object”);
receiving, by the computing system (see e.g. Bahrami, Fig. 1)…, an input to connect at least two nodes from the plurality of integration nodes for integrating corresponding software products (see e.g. Bahrami, column 7, lines 16-20: “In these and other embodiments, the machine learning classifier 160 may connect nodes of the first extended OAS ontology 155 with nodes of the second extended OAS ontology 155 by adding additional nodes”. Note that, the first learning ontology’s nodes are mapped directly to the set of nodes from one of the corresponding software products, and the second ontology are mapped directly to a second set of nodes from a second corresponding software product. Bahrami explains that the ontologies are generated in a similar manner for each individual software product; see e.g. Bahrami, column 12, line 5-11: “In block 435, a first ontology may be generated based on the first API documentation and the first subset of semantic triples. The first ontology may include one or more first concepts associated with the first API, one or more first attributes associated with the one or more first concepts, and one or more first taxonomical relationships between the one or more first concepts”);
determining, by the computing system via a similarity determination module (see e.g. Bahrami, Fig. 1: “Machine Learning Classifier 160”), a similarity between the at least two nodes based on input and output parameters of the two nodes (see e.g. Bahrami, column 9, lines 47-53: “In some embodiments, the knowledge graph 220 may identify similar nodes between multiple APIs. For example, the class node 224A may be a class in the API 1 222A and the class node 224B may be a class in the API 2 222B. Each of the class node 224A and the class node 222B may be instances of the Swagger object 226”), wherein the similarity is determined using at least one of mapping techniques, and a deep learning model (see e.g. Bahrami, column 7, lines 4-29: “machine learning classifier 160 may be configured to classify objects into different but similar classes according to their features. For example, the machine learning classifier 160 may be configured to associate objects, properties, and/or classes from a first extended OAS ontology 155 with objects, properties, and/or classes from a second extended OAS ontology 155… the machine learning classifier 160 may connect nodes of the first extended OAS ontology 155 with nodes of the second extended OAS ontology 155 by adding additional nodes. For example, an "endpoint" in a 20 first extended OAS ontology 155 may correspond with an API REST endpoint. A "function" in a second extended OAS ontology 155 may also correspond with an API REST endpoint. The machine learning classifier 160 may add an API REST endpoint node and connect the node to both the "endpoint" and the "function" nodes with the "endpoint" and "function" both being instances of an API REST endpoint. Thus, the machine learning classifier 160 may generate a knowledge graph 165 as depicted in FIGS. 2a-2c”);
connecting the at least two nodes, based on the similarity, directly when the input and output parameters of the at least two nodes are the same (see e.g. Bahrami, column 9, lines 47-59: “the knowledge graph 220 may identify similar nodes between multiple APIs. For example, the class node 224A may be a class in the API 1 222A and the class node 224B may be a class in the API 2 222B. Each of the class node 224A and the class node 222B may be instances of the Swagger object 226. Thus, the knowledge graph 220 may depict to a user, such as a computer programmer, than the class 224A in the API 1 222A is similar and/or identical to the class 224B in the API 2 222B even if the class 224A and the class 224B have different names and/or descriptions in the API 1 222A and the API 2 222B and the associated API documentation”. Note that, the illustration to the user is directly mapped to the suggestion for when the API object is identical, meaning that the inputs and the outputs are also the same), or through a merging interface upon detection of a conflict while connecting nodes, wherein the at least two nodes are compatible nodes (see e.g. Bahrami, column 9, lines 47-59: “the knowledge graph 220 may identify similar nodes between multiple APIs. For example, the class node 224A may be a class in the API 1 222A and the class node 224B may be a class in the API 2 222B. Each of the class node 224A and the class node 222B may be instances of the Swagger object 226. Thus, the knowledge graph 220 may depict to a user, such as a computer programmer, than the class 224A in the API 1 222A is similar and/or identical to the class 224B in the API 2 222B even if the class 224A and the class 224B have different names and/or descriptions in the API 1 222A and the API 2 222B and the associated API documentation”. Note that, the illustration to the user is directly mapped to suggestion for when the API’s objects are similar but not necessarily identical. By depicting this difference to a user, this directly maps to the merging interface. Additionally, Bahrami explains that “The knowledge graph 165 may link objects of a first API with objects of a second API even if the first API and the second API refer to the objects differently” (in column 8, lines 24 to 26) which also directly maps with the function of the merging interface); and
Bahrami does not but Alli teaches:
via a web-based user interface (see e.g. Alli, paragraph 23: “The web application can provide a design time that exposes a plurality of user interfaces for a developer to design, activate, manage, and monitor an ICS integration flow”)
providing, by the computing system via a suggestion generation module (see e.g. Alli, paragraph 80: “auto suggestion engine”), a suggestion on possible connections for the corresponding software products based on the similarity between the at least two nodes (see e.g. Alli, paragraph 80: “the auto suggestion engine can generate mapping recommendations based on names of elements in the source and target data objects”; paragraph 81: “the auto suggestion engine can match elements with exact names or similar names from the source and target data objects”. Note that, the suggestion engine’s suggestion based on the similarity of names maps directly to the possible connection for the corresponding software products based on the similarity of the nodes);
Bahrami and Alli are analogous art because they are in the same field of endeavor: service integration design and management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Bahrami with the teachings of Alli. The motivation/suggestion would be to improve the software development process and administrative capabilities provided to the developers.
Furthermore, Bahrami does not but Sharma teaches:
learning a sequence comprising a conflict type and associated solution, and node connections, using a Machine Learning (ML) Model (see e.g. Sharma, paragraph 75: “the integration computing entity 100 processes, utilizing an integration machine learning model, the integration data object to identify one or more integration features at step/operation 306. As noted above, the integration machine learning model may comprise one or more machine learning models or components. For instance, the integration machine learning model may include one or more of a trained supervised machine learning model, similarity determination machine learning model, convolutional neural network model, a language-based model, combinations thereof, and/or the like”; and paragraph 78: “Then, at step/operation 312, the integration computing entity 100 generates, based at least in part on the one or more integration features, the API model”. Note that, the integration machine is able to identify and handle conflict of integration features, directly mapping with the use of Machine Learning as claimed), and storing the sequence in a database which is used for further integrations, in each integration cycle (see e.g. Sharma, paragraph 82: “As depicted in FIG. 4, the data structure 400 comprises a reference table defining a plurality of data types. As illustrated, each data structure row is associated with a data field (as depicted, customer number 401A, last name 401B, first name 401C, phone number 401D, address 401E and current balance 401F). Additionally, each data structure 400 column describes attributes (e.g., data type, data format, field size, description, example) associated with the data field. In various embodiments, the integration computing entity 100 may generate a data structure 400 based on analysis of an integration data object (e.g., one or more documents) associated with a provider. The data structure may be utilized to programmatically generate an API model/API that will be capable of processing (e.g., retrieving, utilizing, modifying) data from a database or repository that is associated with another computing entity (e.g., such that a provider system and a third-party system can exchange data via the API”. Note that, the processing of the data via the integration data object and storage of the processed data on the database is directly mapped to the claimed saving of a sequence on the database for later use in further integrations).
Bahrami and Sharma are analogous art because they are in the same field of endeavor: service integration design and management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Bahrami with the teachings of Alli. The motivation/suggestion would be to improve processing efficiency by enabling use of machine learning models that can quickly and efficiently derive connections between different integration features (see e.g. Sharma, paragraph 102).
With respect to claim 2, Bahrami as modified teaches: The method of claim 1, wherein generating the plurality of integration nodes further comprises creating an edge for each input parameter and for each output parameter, for the integration nodes (see e.g. Bahrami, from column 6, lines 65 to column 7, line 3: “the machine learning classifier 160 may be configured to generate a knowledge graph 165 from one or more extended OAS ontologies 155. The machine learning classifier 160 may generate a graph based on the extended OAS ontology 155 including its related objects 125 and instances 145”. Note that, by creating a graph based on the ontologies its clear the inputs and outputs are included in that generation and Bahrami explains the generation of the specific edges in column 9 lines 12-17: “Regular nodes may include nodes which are added to the knowledge graph 210 according to an OAS format. For example, ‘API Title: Twitter API' may be associated with a regular node 212 Twitter API’ and an edge ‘API Title.’ ").
With respect to claim 3, Bahrami as modified teaches: The method of claim 1, wherein generating the plurality of integration nodes further comprises:
based on the API descriptor:
generating validation rules for the input parameters and the output parameters (see e.g. Bahrami, column 6, lines 25-48: “the extension module 150 may create additional properties as nodes as described above. These self-defined properties and/or classes may not have classes assigned to them. In some embodiments, the extension module 150 may also modify classes to add additional properties to the classes. For example, the extension module 150 may add new properties "XXXItem" and "itemName" properties to PathsObject, HeadersObject, DefinitionsObject, ParametersDefinitionsObject, ResponsesDefinitionsObject, SecurityDefinitionsObject, and SchemaObject classes. In these and other embodiments, "XXX" in "XXXItem" may represent "path" (of "PathsObject"), "header" (of "HeadersObject"), etc. In these and other embodiments, adding the additional properties may reduce redundancy. Thus, in some embodiments, the extension module 150 may generate additional nodes in a knowledge graph or ontology. In some embodiments, the extension module 150 may alter self-defined properties that do not conform to naming rules of RDFs. For example, if a property begins with a number, it may be modified to begin with an underscore, "200" may be modified to "_200". Similarly, parentheses may be modified to underscores, "category(primary)" may be modified to "category_primary_”. Note that, the inclusion of additional parameters and altering of altering of properties to be in line with the expected structure are directly mapped to the claimed validation rules); and
selecting a template for a node, wherein templates are modified based on a type of the API (see e.g. Bahrami, column 9, lines 8-29: “As depicted in FIG. 2a, the knowledge graph 210 may include at least three types of nodes. For example, the knowledge graph 210 may include multiple regular nodes 212 (the nodes labeled "R" in FIG. 2a). Regular nodes may include nodes which are added to the knowledge graph 210 according to an OAS format. For example, "API Title: Twitter API" may be associated with a regular node 212 "Twitter API" and an edge "API Title." The knowledge graph 210 may also include multiple OAS ontology nodes 214 (the nodes labeled "0" in FIG. 2a). The OAS ontology nodes 214 maybe nodes generated and/or associated with the ontology from an OAS as the OAS is received from an OAS repository, such as the OAS repository 130 of FIG. 1. The knowledge graph 210 may also include multiple extended OAS ontology nodes 216 (the nodes labeled "E" in FIG. 2a)”. Note that, the different types of nodes that added to the knowledge graph are directly mapped to the different templates for nodes based on the API).
With respect to claim 5, Bahrami as modified teaches: The method of claim 1, wherein the compatible nodes correspond to nodes that have similar input parameters and similar output parameters (see e.g. Bahrami, column 9, lines 47-59: “the knowledge graph 220 may identify similar nodes between multiple APIs. For example, the class node 224A may be a class in the API 1 222A and the class node 224B may be a class in the API 2 222B. Each of the class node 224A and the class node 222B may be instances of the Swagger object 226. Thus, the knowledge graph 220 may depict to a user, such as a computer programmer, than the class 224A in the API 1 222A is similar and/or identical to the class 224B in the API 2 222B even if the class 224A and the class 224B have different names and/or descriptions in the API 1 222A and the API 2 222B and the associated API documentation”. Note that, the compatible nodes are directly mapped for when the API object is identical or at least similar, meaning that the inputs and the outputs are also the same or similar).
With respect to claim 6, Bahrami as modified teaches: The method of claim 1, further comprising:
Bahrami does not but Alli teaches:
rejecting the connection between the at least two nodes when the at least two nodes are incompatible (see e.g. Alli, paragraph 45: “an JCS developer can view a particular recommended mapping, and determine whether to accept/use the recommended mapping or reject it, based on its associated rating”. Note that, the user or developer is able to determine the compatibility of the recommended mapping, and reject if desired. This directly maps to the rejection of the connection between two nodes based on their incompatibility as claimed); and
generating a notification upon detection of the conflict in node connection (see e.g. Alli, paragraph 5: “The system can include a recommendation engine that provides recommended mappings between the source and target data objects, so that the recommended mappings can be graphically displayed in a mapping interface. The recommended mappings can be filtered based one or more filtering criteria. Each recommended mapping can be displayed differently from an actual mapping, and can be associated with a reliability/quality indicator”. Note that, the graphically displaying of the mapping interface with a reliability/quality score is directly mapped to the generation of a notification of some conflict as claimed).
With respect to claims 9-11 and 13-14: Claims 9-11 and 13-14 are directed to a system comprising a processor and a memory communicatively coupled to the processor, wherein the memory stores processor-executable instructions, which, on execution, causes the processor to implement active functional steps corresponding to the method disclosed in claims 1-3 and 5-6, respectively; please see the rejections directed to claims 1-3 and 5-6 above which also cover the limitations recited in claims 9-11 and 13-14. Note that, Bahrami also discloses a computing system 502 comprising a processor 550 and a memory 552 comprising instructions to implement the method disclosed in claims 1-3 and 5-6 (see e.g. Bahrami, column 13, lines 7-15; and Fig. 5).
With respect to claims 17-19: Claims 17-19 are directed to a non-transitory computer-readable medium storing computer-executable instructions configured for implementing active functional steps corresponding to the method disclosed in claims 1-3, respectively; please see the rejections directed to claims 1-3 above which also cover the limitations recited in claims 17-19. Note that, Bahrami also discloses a memory 552 storing instructions to implement the method disclosed in claims 1-3 (see e.g. Bahrami, from column 13, line 53 to column 14, line 9).
Response to Arguments
Applicant's arguments filed 09/02/2026 have been fully considered but they are not persuasive. In detail:
(i) Regarding Applicant’s arguments with respect to the rejections under 35 U.S.C. §112(b) concerning the use of the terms “similar” and “similarity” in the claims (Remarks, pages 10-11), the Examiner notes that neither the sections of the specification highlighted by the applicant nor the rest of the original disclosure provide a description that would reasonably enable one of ordinary skill in the art to ascertain whether two nodes are similar or not.
For example, consider two nodes: node 1 and node 2 wherein node 1 takes input-11 as an input parameter and produces output-11 as an output, and node 2 takes input-22 as an input and produces output-22 as an output.
Based on the description provided with the original disclosure, input-11 is compared to input-22 and output-11 is compared to output-22 in order to determine whether node 1 is similar to node 2. However, no criteria for this comparison is provided; thus rendering the terms “similar” and “similarity” in the claims indefinite.
Examiner further notes that at least paragraph [0043] (also highlighted by the applicant) states “The process leverages tags extracted by the nodes based on the compatibility of the input and output of every node and a JSON line by line comparison in the JSON fields to establish how much they are similar” which indicates the “similarity” is a quantitative measure. Without the details for answering the question of “how much” two nodes are similar, determining “similarity” between the nodes becomes no more than a guesswork.
Consequently, the Examiner maintains the corresponding rejections under 35 U.S.C. §112(b). For more details, please see the Claim Rejections - 35 USC § 112(b) section above.
(ii) Regarding Applicant’s arguments with respect to the limitations “learning a sequence comprising a conflict type and associated solution, and node connections, using a Machine Learning (ML) Model, and storing the sequence in a database which is used for further integrations, in each integration cycle” recited in claim 1 (Remarks, pages 11-15), the Examiner notes the features upon which applicant relies (i.e., the ML model learning a mapping resolution created for conflict handling by utilizing a merging interface which is then used for future conflict resolutions) are not recited in the rejected claim(s). Specifically, the claim merely states “a sequence comprising a conflict type and associated solution”, but does not identify how the conflict type and the solution are identified and/or how the conflict type and the solution are later utilized for conflict resolution. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Accordingly, note that Sharma discloses an API integration system that enables API integration of two systems (i.e. nodes) while providing integration solutions according to integration features associated with the systems by utilizing an integration machine learning model (see e.g. Sharma, paragraphs 3-5).
Specifically, Sharma describes API features (e.g. an API model type or service type, a country, a spoken or written language API, target parameters, etc.) that present potential conflicts for API integrations which had to be resolved manually (see e.g. Sharma, paragraphs 3-4). As a solution, Sharma provides an integration machine learning model (i.e. a machine learning model) to identify and handle such integration features (see e.g. Sharma, paragraph 75: “the integration computing entity 100 processes, utilizing an integration machine learning model, the integration data object to identify one or more integration features at step/operation 306. As noted above, the integration machine learning model may comprise one or more machine learning models or components. For instance, the integration machine learning model may include one or more of a trained supervised machine learning model, similarity determination machine learning model, convolutional neural network model, a language-based model, combinations thereof, and/or the like”; and paragraph 78: “Then, at step/operation 312, the integration computing entity 100 generates, based at least in part on the one or more integration features, the API model”).
That is, the integration machine learning model identifies and handles conflict of integration features for integrating APIs between different systems.
Therefore, Sharma teaches the limitations “learning a sequence comprising a conflict type and associated solution, and node connections, using a Machine Learning (ML) Model”.
Sharma further discloses the integration computing entity generating a data structure 400 that stores these learned features for utilization in integrating APIs and generating corresponding API models (see e.g. Sharma, paragraph 82: “As depicted in FIG. 4, the data structure 400 comprises a reference table defining a plurality of data types. As illustrated, each data structure row is associated with a data field (as depicted, customer number 401A, last name 401B, first name 401C, phone number 401D, address 401E and current balance 401F). Additionally, each data structure 400 column describes attributes (e.g., data type, data format, field size, description, example) associated with the data field. In various embodiments, the integration computing entity 100 may generate a data structure 400 based on analysis of an integration data object (e.g., one or more documents) associated with a provider. The data structure may be utilized to programmatically generate an API model/API that will be capable of processing (e.g., retrieving, utilizing, modifying) data from a database or repository that is associated with another computing entity (e.g., such that a provider system and a third-party system can exchange data via the API”).
That is, the processing of the data via the integration data object and storage of the processed data in the database teaches the limitation “storing the sequence in a database which is used for further integrations, in each integration cycle”.
Consequently, Bahrami in view of Sharma teaches the limitations “learning a sequence comprising a conflict type and associated solution, and node connections, using a Machine Learning (ML) Model, and storing the sequence in a database which is used for further integrations, in each integration cycle” as recited in claim 1. For more details, please see the rejection directed to claim 1 above.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Samudrala (US 2021/0191715 A1) discloses a machine learning model for conflict resolution associated with a code integration process (see paragraph 5).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached at (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194
