DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This Office Action is sent in response to Applicant’s Communication received 3/2/2023 for application number 18/116,750. The Office hereby acknowledges receipt of the following and placed of record in file: Specification, Drawings, Abstract, Oath/Declaration, claims.
3. Claims 1 – 20 are presented for examination.
Claim Rejections - 35 USC § 112
4. 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.
5. Claims 3 and 13 recite the limitation "wherein the software code …" There is insufficient antecedent basis for this limitation in the claim. It is assumed for examination purposes that the noted claims should depend from claims 2 and 12, respectively, in which the term “software code” is first recited.
Claim Rejections - 35 USC § 101
6. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 – 20 are directed to an abstract idea without significantly more. Independent claim 1 recites a computer-implemented method comprising: registering a new version of an application programming interface with an application programming interface registry; transforming the new version of the application programming interface to a first knowledge graph; comparing the first knowledge graph to a second knowledge graph to determine a difference graph, wherein the second knowledge graph is transformed from a prior version of the application programming interface, wherein the difference graph connects the second knowledge graph to the first knowledge graph and identifies changes from the second knowledge graph to the first knowledge graph; and sending the difference graph to selected entities who have subscribed to the application programming interface registry, wherein the first and second knowledge graph respectively comprise a plurality of nodes representing metadata objects and data values associated with the corresponding versions of the application programming interface and a plurality of edges connecting the plurality of nodes, wherein the plurality of edges define hierarchical relationship between the metadata objects and data values represented by the plurality of nodes.
The limitations, as drafted, describe a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. The abstract idea limitations are “transforming the new version of the application programming interface to a first knowledge graph” and “comparing the first knowledge graph to a second knowledge graph to determine a difference graph, wherein the second knowledge graph is transformed from a prior version of the application programming interface, wherein the difference graph connects the second knowledge graph to the first knowledge graph and identifies changes from the second knowledge graph to the first knowledge graph” in Prong I step 2A. Other limitations including “registering a new version of an application programming interface with an application programming interface registry” and “sending the difference graph to selected entities who have subscribed to the application programming interface registry …” are considered pre/post-activity solutions for receiving version information and performing an action (sending a difference graph to subscribers) which is merely an applied application which insignificantly amounts to a judicial exception. Thus, these claims are directing to abstract idea under 35 USC 101.
Other than “a computer-implemented method” there is nothing in the claim elements preclude the steps from practically being performed in the mind. All of the non-abstract limitations are pre/post-activity solutions for getting/obtaining/manipulating/displaying data without significantly more. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the components in the determining step are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of receiving information, executing a function and making a decision) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Additionally, the steps of “registering a new version of an application programming interface with an application programming interface registry” and “sending the difference graph to selected entities who have subscribed to the application programming interface registry …” are pre/post-activity solutions as gathering/manipulating data that are insignificant under Prong II step 2A and 2B. See Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015) (Storing and retrieving information in memory) as noted in MPEP 2106.05(d)(II)(iv).
Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a computer to perform the noted steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible. Independent claims 11 and 20 are rejected on the same basis as independent claim 1. Additionally, dependent claims 2 – 10 and 12 - 19 are similarly rejected as being directed to an abstract idea since these claims are either further detailing the abstract idea by analyzing/processing the data or the elements are insignificant. More specifically, the dependent claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception.
As per claims 2 and 12, wherein the transforming comprises: converting software code of the new version of the application programming interface to a text-based application programming interface specification document using a converter adapted to parse the software code; and converting the text-based application programming interface specification document to the first knowledge graph” recite generic computer components for applying the abstract idea.
As per claims 3 and 13, “wherein the software code is written in web services description language or a representational state transfer web service” recites generic computer components for applying the abstract idea.
As per claims 4 and 14, storing the first knowledge graph in a repository of the application programming interface registry, wherein the repository stores subject-predicate-object expressions defined by the plurality of nodes and the plurality of edges of the first knowledge graph” is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claims 5 and 15, “comparing the first knowledge graph to the second knowledge graph comprises: comparing the first knowledge graph to an intermediate knowledge graph to determine a first difference graph connecting between the intermediate and first knowledge graphs and identifying changes from the intermediate knowledge graph to the first knowledge graph; comparing the intermediate knowledge graph to the second knowledge graph to determine a second difference graph connecting between the second and intermediate knowledge graphs and identifying changes from the second knowledge graph to the intermediate knowledge graph; and merging the first difference graph with the second difference graph, wherein the intermediate knowledge graph is transformed from an intermediate version of the application programming interface, wherein the intermediate version is between the prior version and the new version” recites generic computer components for applying the abstract idea.
As per claims 6 and 16, “editing, via a graphical user interface, one or more edges of the difference graph that connect the second knowledge graph to the first knowledge graph” recites generic computer components for applying the abstract idea.
As per claims 7 and 17, “creating subscription configuration files for a plurality of entities who have subscribed to the application programming interface registry, wherein the subscription configuration files specify application programming interface change conditions that trigger the difference graph to be sent from the application programming interface registry to the respective plurality of entities” recites generic computer components for applying the abstract idea.
As per claims 8 and 18, wherein the application programming interface change conditions comprise a creation of a new node in the first knowledge graph, a deletion of a node in the second knowledge graph, or a datatype change for a node that is shared by both the first and second knowledge graphs” recites generic computer components for applying the abstract idea.
As per claims 9 and 19, identifying the selected entities from the plurality of entities who have subscribed to the application programming interface registry, wherein the identified changes from the second knowledge graph to the first knowledge graph satisfy one or more application programming interface change conditions specified in respective subscription configuration files of the selected entities” is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 10, “wherein the transforming comprises: creating a root node identifying the application programming interface; creating one or more value nodes representing data values associated with the application programming interface; and creating one or more sub-nodes representing the metadata objects associated with the application programming interface, wherein the root node is directly connected to at least one value node representing the new version” recites an additional mental process.
Claim Rejections - 35 USC § 103
7. 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.
8. 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.
9. 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.
10. Claims 1, 3, 4, 11, 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over in Bahrami et al. (U.S. Patent 10,853,150) (Bahrami hereinafter) in view of Evans et al. (U.S. Publication 2021/0089291) (Evans hereinafter) (Identified by Applicant in IDS) and McCreary et al. (U.S. Publication 2023/0342587) (McCreary hereinafter).
11. As per claim 1, Bahrami discloses transforming the new version of the application programming interface to a first knowledge graph [“a knowledge graph of the first API and the second API may be generated based on the first ontology, the second ontology, and the correlating the first ontology with the second ontology,” col. 12, lines 26 – 29];
comparing the first knowledge graph to a second knowledge graph to determine a difference graph, wherein the second knowledge graph is transformed from a prior version of the application programming interface, wherein the difference graph connects the second knowledge graph to the first knowledge graph and identifies changes from the second knowledge graph to the first knowledge graph [“The knowledge graph 165 may be used to answer users' queries and/or to present information about multiple APIs at once to a user to allow a user to understand how different APIs are structured, to determine similarities between different APIs, and/or to understand how to use different APIs. For example, 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. For example, the first API may refer to an object as an “endpoint” and a second API may refer to an object as a “function” but both the “endpoint” and the “function” may be associated with and/or operate as am API REST endpoint. In this manner, the knowledge graph 165 may allow a user to understand two different terminologies that may be used to refer to equivalent and/or similar information,” col. 8, lines 19 – 33; presenting similarities between different APIs suggests a difference graph]; and
wherein the first and second knowledge graph respectively comprise a plurality of nodes representing metadata objects and data values associated with the corresponding versions of the application programming interface and a plurality of edges connecting the plurality of nodes, wherein the plurality of edges define hierarchical relationship between the metadata objects and data values represented by the plurality of nodes [“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. In block 440, a second ontology may be generated based on the second API documentation and the second subset of semantic triples. The second ontology may include one or more second concepts associated with the second API, one or more second attributes associated with the one or more second concepts, and one or more second taxonomical relationships between the one or more second concepts. In block 445, the first ontology may be correlated with the second ontology based on the one or more first concepts of the first ontology and the one or more second concepts of the second ontology. In some embodiments, the first ontology may be correlated with the second ontology using an unsupervised learning process to find similarities between the one or more first concepts and the one or more second concepts. In block 450, a knowledge graph of the first API and the second API may be generated based on the first ontology, the second ontology, and the correlating the first ontology with the second ontology,” col. 12, lines 5 – 29; attributes mapped to metadata, ontology including taxonomical relationships suggests hierarchical relationships].
Bahrami does not explicitly disclose but Evans discloses a computer-implemented method comprising: registering a new version of an application programming interface with an application programming interface registry [“a method for migrating a service from using a first version of an API to using a second version of the API,” ¶ 0004; “the specification component 340 is configured to obtain first and second specifications for the first version 320 and the second version 330 of the API, respectively, from a database 375 of API specifications,” ¶ 0049; database of API specifications mapped to registration/registry].
It would have been obvious to one of ordinary skill in the art, having the teachings of Bahrami and Evans available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Bahrami to include the capability of migrating a service to an API version as taught by Evans, thereby providing a mechanism to enhance system efficiency and maintainability by coordinating API updates.
Evans and Bahrami do not explicitly disclose but McCreary discloses sending the difference graph to selected entities who have subscribed to the application programming interface registry [“The disclosure generally describes devices, systems, and methods for a computing system, or other similar systems (e.g., a cloud computing system), to determine the potential impact of changes in a knowledge graph (also referred to as an “ontology graph”) and outputting updates containing the changes to users of the ontology graph. The computing system may generate a change graph illustrating the changes to an ontology graph. The computing system may determine the potential impact of the changes to an ontology graph and/or other related systems by using deterministic rules and/or by applying a machine learning technique to the change graph. The computing system may publish the change graph and the impact score of the change graph to one or more users (e.g., to subscriber systems of the users), e.g., via one or more publishing systems,” ¶ 0019].
It would have been obvious to one of ordinary skill in the art, having the teachings of Bahrami, Evans and McCreary available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Bahrami and Evans to include the capability of distributing knowledge graph changes as taught by McCreary, thereby providing a mechanism to enhance system maintainability by coordinating API updates with interested subscribers.
12. As per claim 3, Bahrami, Evans and McCreary teach the method of claim 1. Bahrami further teaches wherein the software code is written in web services description language or a representational state transfer web service [“The APIs may be REST APIs, JavaTM APIs, or any other type of API,” col. 3, lines 45 – 46].
13. As per claim 4, Bahrami, Evans and McCreary teach the method of claim 1. Bahrami further teaches storing the first knowledge graph in a repository of the application programming interface registry, wherein the repository stores subject-predicate-object expressions defined by the plurality of nodes and the plurality of edges of the first knowledge graph [“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,” col. 3, lines 58 – 64].
14. As per claim 11, it is a system claim having similar limitations as cited in claim 1. Thus, claim 11 is also rejected under the same rationale as cited in the rejection of claim 1 above.
15. As per claim 13, it is a system claim having similar limitations as cited in claim 3. Thus, claim 13 is also rejected under the same rationale as cited in the rejection of claim 3 above.
16. As per claim 14, it is a system claim having similar limitations as cited in claim 4. Thus, claim 14 is also rejected under the same rationale as cited in the rejection of claim 4 above.
17. Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami, Evans and McCreary in further view of Peddada et al. (U.S. Publication 2023/0171244) (Peddada hereinafter).
18. As per claim 2, Bahrami, Evans and McCreary teach the method of claim 1. Bahrami further teaches converting the text-based application programming interface specification document to the first knowledge graph [“the method 400 may include obtaining a first open API specification (OAS) associated with the first API. The first ontology may be further based on the first OAS. The method 400 may include obtaining a second OAS associated with the second API. The second ontology may be further based on the second OAS. The method 400 may include generating first instances of the first objects using the first OAS. The first instances may be examples of respective first objects. The method 400 may include generating second instances of the second objects using the second OAS. The second instances may be examples of respective second objects. In these and other embodiments, generating the knowledge graph of the first API and the second API may include generating the knowledge graph based on the first ontology, the second ontology, the first instances, the second instances, and the correlating the first ontology with the second ontology,” col. 12, lines 45 – 62].
Bahrami, Evans and McCreary do not explicitly disclose but Peddada discloses converting software code of the new version of the application programming interface to a text-based application programming interface specification document using a converter adapted to parse the software code [“The API specification may be generated by processing source code for the administration API,” ¶ 0123].
It would have been obvious to one of ordinary skill in the art, having the teachings of Bahrami, Evans, McCreary and Peddada available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Bahrami, Evans and McCreary to include the capability of code conversion as taught by Peddada, thereby providing a mechanism to enhance system maintainability by documenting software structure in specification format.
19. As per claim 12, it is a system claim having similar limitations as cited in claim 2. Thus, claim 12 is also rejected under the same rationale as cited in the rejection of claim 2 above.
20. Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami, Evans and McCreary in further view of Roy et al. (U.S. Publication 2024/0184829) (Roy hereinafter).
21. As per claim 5, Bahrami, Evans and McCreary teach the method of claim 1. Bahrami further teaches wherein comparing the first knowledge graph to the second knowledge graph comprises: comparing the first knowledge graph to an intermediate knowledge graph to determine a first difference graph connecting between the intermediate and first knowledge graphs and identifying changes from the intermediate knowledge graph to the first knowledge graph; comparing the intermediate knowledge graph to the second knowledge graph to determine a second difference graph connecting between the second and intermediate knowledge graphs and identifying changes from the second knowledge graph to the intermediate knowledge graph [“The knowledge graph 165 may be used to answer users' queries and/or to present information about multiple APIs at once to a user to allow a user to understand how different APIs are structured, to determine similarities between different APIs, and/or to understand how to use different APIs. For example, 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. For example, the first API may refer to an object as an “endpoint” and a second API may refer to an object as a “function” but both the “endpoint” and the “function” may be associated with and/or operate as am API REST endpoint. In this manner, the knowledge graph 165 may allow a user to understand two different terminologies that may be used to refer to equivalent and/or similar information,” col. 8, lines 19 – 33; presenting similarities between different APIs suggests a difference graph].
Bahrami, Evans and McCreary do not explicitly disclose but Roy discloses merging the first difference graph with the second difference graph, wherein the intermediate knowledge graph is transformed from an intermediate version of the application programming interface, wherein the intermediate version is between the prior version and the new version [“A knowledge graph combiner 611 combines the integrator knowledge graph 605 with the current global knowledge graph 602 to output a new global knowledge graph 606,” ¶ 0097].
It would have been obvious to one of ordinary skill in the art, having the teachings of Bahrami, Evans, McCreary and Roy available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Bahrami, Evans and McCreary to include the capability of knowledge graph management as taught by Roy, thereby providing a mechanism to enhance system maintainability by tracking and storing version changes.
22. As per claim 15, it is a system claim having similar limitations as cited in claim 5. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of claim 5 above.
23. Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami, Evans and McCreary in further view of Kessler (U.S. Patent 11,790,892) (Kessler hereinafter).
24. As per claim 6, Bahrami, Evans and McCreary teach the method of claim 1. Bahrami, Evans and McCreary do not explicitly disclose but Kessler discloses editing, via a graphical user interface, one or more edges of the difference graph that connect the second knowledge graph to the first knowledge graph [“The user may modify existing elements within the GUI 462. FIG. 4E depicts an exemplary computing environment 460 including a GUI 462 for performing application prototyping that may correspond to the GUI 462 of FIG. 4D. The user may utter a command via the voice input field 464. For example, the user may utter “move to center.” The GUI module 122 may include instructions for maintaining a reference to the most recently edited node or nodes within the knowledge graph corresponding to the GUI 462,” col. 18, lines 18 – 26].
It would have been obvious to one of ordinary skill in the art, having the teachings of Bahrami, Evans, McCreary and Kessler available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Bahrami, Evans and McCreary to include the capability of knowledge graph editing as taught by Kessler, thereby providing a mechanism to enhance system maintainability by facilitating user access to knowledge graph details.
25. As per claim 16, it is a system claim having similar limitations as cited in claim 6. Thus, claim 16 is also rejected under the same rationale as cited in the rejection of claim 6 above.
26. Claims 7 – 9 and 17 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami, Evans and McCreary in further view of Yan et al. (U.S. Publication 2020/0226185) (Yan hereinafter).
27. As per claim 7, Bahrami, Evans and McCreary teach the method of claim 1. Bahrami, Evans and McCreary do not explicitly disclose but Yan discloses creating subscription configuration files for a plurality of entities who have subscribed to the application programming interface registry, wherein the subscription configuration files specify application programming interface change conditions that trigger the difference graph to be sent from the application programming interface registry to the respective plurality of entities [“the intelligent analysis engine 210 may retrieve 241 the stored customization request trees 233 from the customized subscribe requests repository 225, retrieve 242 the registered REST API specifications that are previously stored in the REST API repository 227, and perform change-detections based on the retrieved customization request tree 233 and the retrieved registered REST API specifications. For a specific customization request tree 233 retrieved from the customized subscribe requests repository 225, the intelligent analysis engine 210 may identify a set of REST API specifications in the REST API repository 227 that satisfy the conditions and criteria as specified in the specific customization request tree 233. In other words, the intelligent analysis engine 210 may search through the REST API repository 227 and identify the matching REST API specifications by evaluating the monitoring-elements in the specific customization request tree 233 with the corresponding parameters and values in the REST API specifications. The matched REST API specifications may be deemed “registered REST API specifications” for subsequent change-detection and change-notification,” ¶ 0048].
It would have been obvious to one of ordinary skill in the art, having the teachings of Bahrami, Evans, McCreary and Yan available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Bahrami, Evans and McCreary to include the capability of publishing API changes based on subscriber requests as taught by Yan, thereby providing a mechanism to enhance system maintainability by facilitating user access to API changes.
28. As per claim 8, Bahrami, Evans, McCreary and Yan teach the method of claim 7. Bahrami further teaches wherein the application programming interface change conditions comprise a creation of a new node in the first knowledge graph, a deletion of a node in the second knowledge graph, or a datatype change for a node that is shared by both the first and second knowledge graphs [“the extension module 150 may start with the open API specification associated with a particular API as the ontology. The extension module 150 may extend the ontology by adding the objects 125 and the instances 145 to the ontology. In some embodiments, the extension module 150 may modify the ontology in different manners depending on the class, properties, and data types of the ontology. For example, with properties with well-defined ranges, path item objects may be added to the ontology. For example, a node may be added for each property in the object,” col. 5, lines 45 – 55].
29. As per claim 9, Bahrami, Evans, McCreary and Yan teach the method of claim 7. Yan further teaches identifying the selected entities from the plurality of entities who have subscribed to the application programming interface registry, wherein the identified changes from the second knowledge graph to the first knowledge graph satisfy one or more application programming interface change conditions specified in respective subscription configuration files of the selected entities [“the PSS 150 may continuously monitor 152 the REST APIs configured in the RSP 130 for changes and update events such as REST API subscriptions, un-subscriptions, publications, un-publications, additions, and modifications. Once a change is detected, the PSS 150 may evaluate the customized requests previously provided by the subscribers 120. For each of these subscribers 120, the PSS 150 may generate a corresponding change report 122 based on the detected changes and the subscriber's request. Afterward, the notification module 153 may distribute 123 the change report 122 to the specific subscriber 120, informing that the REST APIs it is interested in may have been changed,” ¶ 0020].
It would have been obvious to one of ordinary skill in the art, having the teachings of Bahrami, Evans, McCreary and Yan available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Bahrami, Evans and McCreary to include the capability of publishing API changes based on subscriber requests as taught by Yan, thereby providing a mechanism to enhance system maintainability by facilitating user access to API changes.
30. As per claim 17, it is a system claim having similar limitations as cited in claim 7. Thus, claim 17 is also rejected under the same rationale as cited in the rejection of claim 7 above.
31. As per claim 18, it is a system claim having similar limitations as cited in claim 8. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of claim 8 above.
32. As per claim 19, it is a system claim having similar limitations as cited in claim 9. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of claim 9 above.
33. As per claim 20, it is a media claim having similar limitations as cited in claims 1, 7 and 9. Thus, claim 20 is also rejected under the same rationale as cited in the rejections of claim 1, 7 and 9 above.
34. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Bahrami, Evans and McCreary in further view of Roy et al. (U.S. Publication 2021/0385124) (Roy ‘124 hereinafter).
35. As per claim 10, Bahrami, Evans and McCreary teach the method of claim 1. Bahrami further teaches wherein the transforming comprises: creating a root node identifying the application programming interface [“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,” col. 12, lines 5 – 11].
Bahrami, Evans and McCreary do not explicitly disclose but Roy’124 discloses creating one or more value nodes representing data values associated with the application programming interface, creating one or more sub-nodes representing the metadata objects associated with the application programming interface; and wherein the root node is directly connected to at least one value node representing the new version [“The graph creation for the API is then completed by plotting the relationships between parent nodes p={p1, p2, . . . , p.sub.n} and metadata feature set m={m1, m2, . . . , m.sub.n}. The validity of the knowledge graph is ascertained by reference to the business process corpus or repository, and the knowledge graph is then stored in the database and output by the model. This output can then be used to develop, configure, and deploy the subsequent integration solution. In other words, by generating intelligent insights about the proposed integration flow and the end-to-end dynamics of the desired environment, an integration solution can be provided that is fine-tuned to the needs and priorities of the users,” ¶ 0058; end-to-end dynamics suggest root/value node connection].
It would have been obvious to one of ordinary skill in the art, having the teachings of Bahrami, Evans, McCreary and Roy’124 available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Bahrami, Evans and McCreary to include the capability of documenting API call tracing as taught by Roy’124, thereby providing a mechanism to enhance system maintainability by facilitating API-based system deployments.
Conclusion
36. Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM C WOOD whose telephone number is (571)272-5285. The examiner can normally be reached Monday - Friday, 8:00 am - 4:30 pm.
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, Chat C Do can be reached at 571-272-3721. 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.
/WILLIAM C WOOD/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193