DETAILED ACTION
Claims 1, 5, 6, 9, 13, 14, and 17 are amended. Claims 4, 7, 12, 15, and 20 are cancelled. Claims 1-3, 5-6, 8-11, 13-14, and 16-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.
Response to Amendment
Amendments to claims 1, 9, and 17 are fully considered and are satisfactory to overcome the rejections under 35 U.S.C. §101 directed claims 1-3, 8-11, and 16-19 in the previous Office Action.
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).
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).
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); and
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.
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).
Claims 8 and 16 are rejected under 35 U.S.C 103 as being unpatentable over Bahrami in view of Alli as applied to claims 1 and 9 above, in further view of Sharma (US 2023/0129050 A1; hereinafter Sharma).
With respect to claim 8, Bahrami as modified teaches: The method of claim 1,
Bahrami does not but Sharma teaches:
further comprising 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).
With respect to claim 16: Claim 16 is 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 claim 8; please see the rejection directed to claim 8 above which also covers the limitations recited in claim 16.
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.
Response to Arguments
Applicant's arguments filed 03/09/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-13), the Examiner notes that:
a. This rejection is not based on the terms being directed to abstract concepts (Remarks, page 10, item 1) and/or to mental activity (Remarks, page 12, item 4), but is based on the terms being relative terms (such as “hot” soup, “tall” building, “fast” car, etc.). Without a description in the original disclosure that defines how to determine whether two given nodes are similar or not, one of ordinary skill in the art would not be able to ascertain the scope of the invention.
b. Paragraphs [0042]-[0043] and paragraph [0021] (Remarks, pages 11-12, items 2-3) describe evaluating compatibility of the nodes, comparing input/output parameters of the nodes and using a similarity determination module that utilizes mapping techniques and/or deep learning models. However, neither these paragraphs nor the rest of the specification provide a specific details to ascertain whether two nodes are similar or not; they name techniques and concepts to determine the similarity without providing any details for such techniques and/or concepts (e.g. how an input parameter of a first node is compatible with an input parameter of a second node, how an output parameter of a first node is similar to an output parameter of a second node, etc.).
For example, if a first node has an integer parameter “age” as an input and a second node has a double parameter “age” as an input, are these two nodes similar? Or, if a first node produces a string “first name” as a first output and a string “last name” as a second output and a second node produces a string “full name” as an output, are these nodes similar? Or, if a first node produces integer “age” as an output and a second node produces the string “The age value is” followed with an integer “age” as its output, are these nodes similar? The specification provides no description regarding such evaluations in order to enable one of ordinary skill in the art to ascertain what is being considered “similar” nodes.
As for the disclosure provided in paragraphs [0021] and [0042]-[0043], the description provided therein identifies methods used for determining the “similarity” at a high-level of generality which still lacks the particulars for determining the “similarity”. For example, for the term “hot” soup, a similar description would be “Temperature of a soup is determined by a thermometer. If it is above a threshold temperature, then the soup is determined to be hot”; without a particular threshold value, it won’t be possible to ascertain what is considered as being “hot” soup.
Consequently, it is not apparent to one of ordinary skill in the art to determine if two parameters are similar or not, and thus it is not clear how to ascertain two nodes are similar nodes. As such, 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 claim 1, Applicant argues that Bahrami in view of Alli fails to teach the limitations “providing, by the computing system via a suggestion generation module, a suggestion on possible connections for the corresponding software products based on the similarity between the at least two nodes” and “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, or through a merging interface upon detection of a conflict while connecting nodes, wherein the at least two nodes are compatible nodes” as recited (Remarks, pages 40-47).
First, the Examiner would like to clarify that the rejection refers to Alli as disclosing providing suggestions regarding possible connections and refers to Bahrami as disclosing the connections between the nodes.
Specifically, Alli discloses an auto suggestion engine (i.e. a suggestion generation module) that provides mapping recommendations between source and target data objects (i.e. recommendations for possible connections between the source and target data objects) based on elements with exact or similar names (see Alli, paragraph 80: “auto suggestion engine can generate mapping recommendations based on names of elements in the source and target data objects”; and paragraph 81: “auto suggestion engine can match elements with exact names or similar names from the source and target data objects”).
That is, Alli discloses providing, by the auto suggestion engine, a recommendation of possible mappings between source and target data objects (i.e. connections between software elements) based on the similarity between the element names of the source and target data objects.
Therefore, Alli teaches the limitation “providing, by the computing system via a suggestion generation module, a suggestion on possible connections for the corresponding software products based on the similarity between the at least two nodes”.
Regarding Bahrami, note that the ontology disclosed therein corresponds to an actual network ontology of nodes; that is, Bahrami is not limited to only a design of a network but actually implements the connections between these nodes, such as by establishing communication paths between the nodes (see Bahrami, column 5, lines 1-5: “OAS JSON file may include “paths”.fwdarw.‘/post_message’ which may be addressed as: “paths” as an endpoint (according to the OAS format) and the value or instance may be “/post_message.””; and column 7, lines 18-19: “connect nodes of the first extended OAS ontology 155 with nodes of the second extended OAS ontology 155”).
As such, the connections between the nodes shown in the knowledge graph 220 correspond to actual connections between these nodes within the network with corresponding paths and endpoints (see Bahrami, column 2, lines 22-25: “generating application programming interface (API) knowledge graphs. APIs may be used to allow different machines to interact with each other”; and column 8, lines 24-26: “knowledge graph 165 may link objects of a first API with objects of a second API”).
Further note that, these connections are established by identifying similar nodes (see 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”).
This identification includes determining when a class in API 1 is identical to a class in API 2 which inherently discloses the input and output parameters of corresponding class objects as being same (see Bahrami, column 9, lines 53-56: “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”).
That is, Bahrami teaches the limitation “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”.
The similar node identification process further includes determining when a class in API 1 is similar to a class in API 2 even though they have different names and/or descriptions (i.e. a conflict) and still providing a link between their corresponding objects (see Bahrami, column 9, lines 53-59: “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”; and column 8, lines 24-26: “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”). That is, Bahrami teaches the limitation “through a merging interface upon detection of a conflict while connecting nodes, wherein the at least two nodes are compatible nodes”.
Therefore, Bahrami teaches the limitation “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, or through a merging interface upon detection of a conflict while connecting nodes, wherein the at least two nodes are compatible nodes” as recited in claim 1.
Consequently, the Examiner maintains the rejection directed to claim 1. For more details, please see the corresponding rejection above.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ravi et al. (US 10,430,464 B1) discloses establishing connections between nodes based on a similarity measure between the nodes (see column 22, lines 6-23).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
Prosecution Insights