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. In response to the Office action mailed on 5/4/2026, the applicants have filed a response: claims 1, 3, 4, 6, 7, 9, 11, 13, 14, 16, 17, 19 and 20 have been amended. Claims 1 – 20 are pending.
Claim Rejections - 35 USC § 101
3. 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 for improved automated application programming interface change management comprising: registering, by a registration unit of an application programming interface registry, a new version of an application programming interface; transforming, by a knowledge graph generator of the registration unit, the new version of the application programming interface to a first knowledge graph; retrieving a second knowledge graph from a knowledge graph repository of the application programming interface registry, the second knowledge graph being transformed from a prior version of the application programming interface; comparing, by a transformation unit of the application programming interface registry, the first knowledge graph to the second knowledge graph to identify changes of the application programming interface from the prior version to the new version, wherein identifying changes comprises comparing topology of the first knowledge graph and the second knowledge graph; generating a difference graph connecting the second knowledge graph to the first knowledge graph, wherein the difference graph identifies the changes of the application programming interface from the prior version to the new version; and sending, by a subscription unit of the application programming interface registry, the difference graph to selected entities who have subscribed to the application programming interface registry for implementing the changes of the application programming interface, 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” “comparing … the first knowledge graph to the second knowledge graph to identify changes … “ and “generating a difference 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,” “by a registration unit of an application programming interface registry,” “by a knowledge graph generator of the registration unit,” “by a transformation unit of the application programming interface registry” and “by a subscription unit of the application programming interface registry” 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 the knowledge graph 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, “receiving edits, 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, “maintaining 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 of the application programming interface 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
4. 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.
5. 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.
6. 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.
7. Claims 1 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan (U.S. Publication 2013/0326481) (Kannan 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, Kannan discloses transforming, by a knowledge graph generator of the registration unit, the new version of the application programming interface to a first knowledge graph; retrieving a second knowledge graph from a knowledge graph repository of the application programming interface registry, the second knowledge graph being transformed from a prior version of the application programming interface [“graph models relating to multiple software releases (e.g., a first release and a second release) may be generated and stored. The multiple graph models may then be compared to one another in order to identify and/or track any changes and/or differences between the multiple software releases. Advantageously, the multiple graph models may be traversed or reviewed in order to efficiently identify and/or track the delta between the multiple software releases. The comparison of the multiple graph models and identification of any changes enables the system to identify and/or track any potential Application Programming Interface (API) breakages and/or Application Binary Interface (ABI) breakages. In this regard, the graph models may be employed to track, monitor, and manage software package dependencies and API/ABI breakages across software release cycles,” ¶ 0017];
comparing, by a transformation unit of the application programming interface registry, the first knowledge graph to the second knowledge graph to identify changes of the application programming interface from the prior version to the new version, wherein identifying changes comprises comparing topology of the first knowledge graph and the second knowledge graph; generating a difference graph connecting the second knowledge graph to the first knowledge graph, wherein the difference graph identifies the changes of the application programming interface from the prior version to the new version [“the first graph model and the second graph model are compared in order to identify any changes in the new release (e.g., the second release) relative to the existing software (e.g., the first release). In block 304, the graph models are reviewed in accordance with an appropriate search algorithm to identify the one or more changes in the respective modeling information (e.g., the package information, the dependency information, the package properties, the function properties, etc.). In an embodiment, the search algorithms may be used to query the graph models for dependency information,” ¶ 0034]; 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 [“a graph model is generated which represents the modeling information. The graph model associated with the software release is stored in a data store (e.g., graph model data store 114 in FIG. 1), in block 208. In an embodiment, the graph model includes a node for each package (e.g., a package node) and a node for each function (e.g., a function node) of the software release. According to embodiments of the present invention, the nodes (e.g., package and function nodes) may include properties relating to and/or defining the underlying package or function represented by the node,” ¶ 0028; ”the nodes of the graph model may be connected to each other by indicators representing the relationship between and among the nodes. For example, the indicators may be lines or arrows including a label identifying the type of relationship, as shown in the examples illustrated in FIGS. 4A and 4B). In one example, a package nodes may be connected to another package node using an indicator (e.g. an arrow) denoting a `depends` relationship between the two package nodes. In another example, a package node may be connected to a function node using an indicator denoting a `provides` relationship between the package node and the function node,” ¶ 0029].
Kannan does not explicitly disclose but Evans discloses a computer-implemented method for improved automated application programming interface change management comprising: registering, by a registration unit of an application programming interface registry, a new version of an application programming interface [“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 Kannan and Evans available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Kannan 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.
Kannan and Evans do not explicitly disclose but McCreary discloses sending, by a subscription unit of the application programming interface registry, the difference graph to selected entities who have subscribed to the application programming interface registry for implementing the changes of the application programming interface [“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 Kannan, 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 Kannan 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.
8. 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.
9. Claims 2, 3, 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan, Evans and McCreary in further view of Bahrami et al. (U.S. Patent 10,853,150) (Bahrami hereinafter) and Peddada et al. (U.S. Publication 2023/0171244) (Peddada hereinafter).
10. As per claim 2, Kannan, Evans and McCreary teach the method of claim 1. Kannan, Evans and McCreary do not explicitly disclose but Bahrami discloses 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].
It would have been obvious to one of ordinary skill in the art, having the teachings of Kannan, Evans, McCreary and Bahrami available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Kannan, Evans and McCreary to include the capability of storing knowledge graphs as taught by Bahrami, thereby providing a mechanism to enhance system maintainability by storing graphs in a commonly-utilized format.
Kannan, Evans, McCreary and Bahrami 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 Kannan, Evans, McCreary, Bahrami 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, McCreary and Bahrami 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.
11. As per claim 3, Kannan, Evans, McCreary, Bahrami and Peddada teach the method of claim 2. 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].
It would have been obvious to one of ordinary skill in the art, having the teachings of Kannan, Evans, McCreary and Bahrami available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Kannan, Evans and McCreary to include the capability of storing knowledge graphs as taught by Bahrami, thereby providing a mechanism to enhance system maintainability by storing graphs in a commonly-utilized format.
12. 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.
13. 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.
14. Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan, Evans and McCreary in further view of Bahrami.
15. As per claim 4, Kannan, Evans and McCreary teach the method of claim 1. Kannan, Evans and McCreary do not explicitly disclose but Bahrami discloses storing the first knowledge graph in the knowledge graph 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].
It would have been obvious to one of ordinary skill in the art, having the teachings of Kannan, Evans, McCreary and Bahrami available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Kannan, Evans and McCreary to include the capability of storing knowledge graphs as taught by Bahrami, thereby providing a mechanism to enhance system maintainability by storing graphs in a commonly-utilized format.
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 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan, Evans, McCreary and Bahrami in further view of Roy et al. (U.S. Publication 2024/0184829) (Roy hereinafter).
18. As per claim 5, Kannan, Evans and McCreary teach the method of claim 1. Kannan, Evans and McCreary do not explicitly disclose but Bahrami discloses 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].
It would have been obvious to one of ordinary skill in the art, having the teachings of Kannan, Evans, McCreary and Bahrami available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Kannan, Evans and McCreary to include the capability of storing knowledge graphs as taught by Bahrami, thereby providing a mechanism to enhance system maintainability by storing graphs in a commonly-utilized format.
Kannan, Evans, McCreary and Bahrami 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 Kannan, Evans, McCreary, Bahrami and Roy available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Kannan, Evans, McCreary and Bahrami 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.
19. 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.
20. Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan, Evans and McCreary in further view of Kessler (U.S. Patent 11,790,892) (Kessler hereinafter).
21. As per claim 6, Kannan, Evans and McCreary teach the method of claim 1. Kannan, Evans and McCreary do not explicitly disclose but Kessler discloses receiving edits 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 Kannan, 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 Kannan, 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.
22. 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.
23. Claims 7, 9 and 17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan, Evans and McCreary in further view of Yan et al. (U.S. Publication 2020/0226185) (Yan hereinafter).
24. As per claim 7, Kannan, Evans and McCreary teach the method of claim 1. Kannan, Evans and McCreary do not explicitly disclose but Yan discloses maintaining 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 Kannan, 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 Kannan, 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.
25. As per claim 9, Kannan, 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 of the application programming interface 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 Kannan, 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 Kannan, 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.
26. 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.
27. 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.
28. 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.
29. Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan, Evans, McCreary and Yan et al. (U.S. Publication 2020/0226185) (Yan hereinafter) in further view of Bahrami.
30. As per claim 8, Kannan, Evans, McCreary and Yan teach the method of claim 7. Kannan, Evans, McCreary and Yan do not explicitly disclose but Bahrami discloses 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].
It would have been obvious to one of ordinary skill in the art, having the teachings of Kannan, Evans, McCreary, Yan and Bahrami available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Kannan, Evans, McCreary and Yan to include the capability of storing knowledge graphs as taught by Bahrami, thereby providing a mechanism to enhance system maintainability by storing graphs in a commonly-utilized format.
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. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Kannan, Evans and McCreary in further view of Bahrami and Roy et al. (U.S. Publication 2021/0385124) (Roy ‘124 hereinafter).
33. As per claim 10, Kannan, Evans and McCreary teach the method of claim 1. Kannan, Evans and McCreary do not explicitly disclose but Bahrami discloses 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].
It would have been obvious to one of ordinary skill in the art, having the teachings of Kannan, Evans, McCreary and Bahrami available before the effective filing date of the claimed invention, to modify the capability of generating API knowledge graphs as disclosed by Kannan, Evans and McCreary to include the capability of storing knowledge graphs as taught by Bahrami, thereby providing a mechanism to enhance system maintainability by storing graphs in a commonly-utilized format.
Kannan, Evans, McCreary and Bahrami 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 Kannan, Evans, McCreary, Bahrami 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 Kannan, Evans, McCreary and Bahrami 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.
Response to Arguments
Claim Rejections - 35 USC § 101
34. Applicant's arguments have been fully considered but they are not persuasive.
35. Applicant argues on page 13 that the human mind is simply not capable of performing the noted steps of the independent claims without explaining why or providing supporting evidence or persuasive authority. Each claim, as well as the individual limitations, are analyzed and identified as abstract ideas or additional elements that implement or support the abstract idea limitations, including pre/post solution activities which are insignificant extra-solution activities relative to the abstract ideas.
36. Applicant argues on page 14 that the identified independent claim limitations are not found in the prior art of record and thus amount to a practical application that improves automated API change management. However, as recited above, the prior art of record does in fact teach the claimed invention. Additionally, applicant’s reliance on Ex parte Desjardins is not persuasive; the subject matter of Desjardins relates to artificial intelligence and machine learning models and is thus not analogous to the instant subject matter.
37. Applicant argues on page 17 that the noted features of claim 1 are novel and nonobvious in light of the cited prior art. As stated above, this is not the case. Prior art is cited that renders the claimed invention obvious and thus not novel but rather well understood and conventional.
Claim Rejections - 35 USC § 103
38. Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
39. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
40. 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
Prosecution Insights