DETAILED ACTION
See Examiner note regarding effective filing date and continuations-in-part.
Claims 1-20 rejected under 35 USC § 103.
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 .
Examiner Note
Due to the complexity of priority claims via continuations-in-part in this application, Examiner requests that subsequent claim amendments include express citation to the parent case relied upon for each claim. This is necessary to establish an agreed upon effective filing date of the claimed invention. See MPEP 2152.01(B). In particular, it is difficult to establish the exact priority date for the “artificial intelligence plugin” features in this application.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rangasamy et al., U.S. PG-Publication No. 2016/0124742 A1, in view of Pollock, U.S. PG-Publication No. 2019/0034199 A1.
Claim 1
Rangasamy discloses a method for managing Application Programming Interfaces (APIs) in a microservices architecture. Rangasamy discloses a “development framework to facilitate application development for microservice-based application architectures,” wherein the framework “extends microservice development, platform, and deployment tools to … systematically develop highly-scalable applications made up of loosely-coupled microservices.” Rangasamy, ¶ 5.
Rangasamy discloses the method comprising: communicatively coupling a plurality of APIs organized into a microservices application architecture. The development framework includes “microservices, the orchestrator, and plugins,” wherein “a microservice implements a set of focused and distinct features or functions.” Each microservice in the development framework “adheres to a well-defined Application Programming Interface (API) specified in the corresponding service definition and may be orchestrated, by invoking the API of the microservice, according to a workflow performed by the orchestrator.” Id. at ¶ 7; See Also ¶¶ 13-15 (describing microservice platform for developing and executing a plurality of microservices).
Rangasamy discloses coordinating, by an API management platform, data associated with the plurality of APIs of the microservices application. The orchestrator component coordinates “generated and implemented microservices based on rules or workflow defined for various APIs exposed by the orchestrator.” The development framework provides “code structuring … for easily scaffolding APIs defined for microservices, as well as facilitating the iterative development or microservices and orchestration workflows by providing automated tools for regenerating scaffolding up on the recalibration of API definitions.” Id. at ¶¶ 7-8.
Rangasamy discloses automatically updating, a documentation file associated with the first API. Figure 21 illustrates a “development framework that facilitates the scaffolding, building, testing, and deployment of microservice-based applications.” Orchestrator platform 2000 comprises an “interface documentation/publication (API documentation engine 2004).” Id. at ¶ 191. Figure 26 illustrates interface 2500 comprising “a documentation and testing page for a microservice interface.” The framework “may automatically generate a microservice/API catalog for the application,” the API catalog is based on an API contract “describing all microservices and their exposed functionality.” For example, interface 2500 “presents HTTP operations 2500A-2500D automatically generated by the development framework.” Id. at ¶¶ 208-209.
Rangasamy does not expressly disclose providing, to an artificial intelligence plugin, parameter names or parameter data types of a first API of the plurality of APIs, wherein output of the artificial intelligence plugin indicates an expected operation of the first API based on the parameter names or parameter data types; and automatically updating, a documentation file associated with the first API based on the output of the artificial intelligence plugin.
Pollock discloses providing, to an artificial intelligence plugin, parameter names or parameter data types of a first API of the plurality of APIs, wherein output of the artificial intelligence plugin indicates an expected operation of the first API based on the parameter names or parameter data types; and automatically updating, a documentation file associated with the first API based on the output of the artificial intelligence plugin. Pollock discloses methods for “automatic generation of API documentation via implementation-neutral analysis of API traffic.” The documentation is “automatically generated in real-time or based on logged API traffic.” The method includes “receiving an API interaction, determining at least one interaction parameters based on the API interaction, and automatically generating the documentation based on the at least one interaction parameter.” Pollock, ¶ 19. In one embodiment, the method is performed by an “analyzer 120” (i.e., plugin). The analyzer 120 “is configured to generate API documentation based on traffic data.” Analyzer 120 “collects data based on an API interaction” including “hostname, HTTP method, security protocol used, … authentication path, parameter such as URI and POST body” and “response code, response message, response data, or the like” and also collects “data by determining the grammatical structure of an API interaction such as the structure of the request and any verbs or requested actions included in the API interaction.” Analyzer 120 determines “request parameter types, whether a request parameter is option or required, content type, security type, or the like” and determines the “response data scheme or the like.” Id. at ¶¶ 22-24; See Also ¶ 32 (Table 1 shows exemplary interaction data); ¶ 37 (describing parsing API interaction “to determine parameters such as syntactical elements, flags, and other attributes”). The documentation includes “a description of how an API interaction can be used,” (i.e., expected operation) such as “definitions and/or descriptors for the determined interaction parameters” (i.e., based on the parameters names or parameter data types). Id. at ¶ 63. Further, Pollock discloses that “the analyzer may be trained by machine learning techniques such as supervised learning to improve its analytical activities” (i.e., trained using artificial intelligence). Id. at ¶ 46; See Also ¶ 59 (feedback used as validation set “to train a machine learning model to improve the automatic documentation of API interactions”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the microservice API development framework of Rangasamy to incorporate the automatic API documentation method taught by Pollock. One of ordinary skill in the art would be motivated to integrate the automatic API documentation into Rangasamy, with a reasonable expectation of success, in order to improve the user experience, because “APIs that are well-documented are well-received and more likely to be adopted and used,” and “facilitates integration of APIs into various systems and infrastructure.” Pollock, ¶ 19; See Also ¶ 15 (if the API documentation “is inadequate, users of the API may find it difficult to use the API, e.g., to automate the user’s own systems”).
Claim 2
Pollock discloses wherein said automatically updating by the artificial intelligence plugin is based on training of the artificial intelligence plugin connected to semantic interpretation. Analyzer 120 “collects data based on an API interaction” including “hostname, HTTP method, security protocol used, … authentication path, parameter such as URI and POST body” and “response code, response message, response data, or the like” and also collects “data by determining the grammatical structure of an API interaction such as the structure of the request and any verbs or requested actions included in the API interaction.” Analyzer 120 determines “request parameter types, whether a request parameter is option or required, content type, security type, or the like” and determines the “response data scheme or the like.” Pollock, ¶¶ 22-24; See Also ¶ 32 (Table 1 shows exemplary interaction data); ¶ 37 (describing parsing API interaction “to determine parameters such as syntactical elements, flags, and other attributes”). The documentation includes “a description of how an API interaction can be used,” (i.e., expected operation) such as “definitions and/or descriptors for the determined interaction parameters” (i.e., based on the parameters names or parameter data types). Id. at ¶ 63. Further, Pollock discloses that “the analyzer may be trained by machine learning techniques such as supervised learning to improve its analytical activities” (i.e., trained using artificial intelligence). Id. at ¶ 46; See Also ¶ 59 (feedback used as validation set “to train a machine learning model to improve the automatic documentation of API interactions”).
Claim 3
Pollock discloses wherein the parameter data types or the parameter names are drawn from a proxied request/response transaction with the first API, and the output of the artificial intelligence plugin is further based on the proxied request/response transaction. In one embodiment, “the analyzer generated documentation based on traffic data observed as part of proxying logic.” Pollock, ¶ 22.
Claim 4
Pollock discloses wherein the output by the artificial intelligence plugin is based on training of the artificial intelligence plugin connected to a historical model of a request/response schema. Feedback is provided “as part of a validation set to train a machine learning model to improve the automatic documentation of API interaction.” Pollock. ¶ 59. The method determines “a response data schema based on an API response,” wherein “the schema may indicate names or properties that will be returned such as title and data type.” Id. at ¶ 44.
Claim 5
Rangasamy discloses providing a memory architecturally separate from the plurality of APIs, the memory including a program code library configured to execute functionalities common to execution of the plurality of APIs on a node in communication with the memory. Orchestration engine 704 uses an “in-memory grid caching using an in-memory and persistent disk database” (i.e., separate memory architecture). The orchestrator 706 implements “workflows that invoke multiple microservices 706 in a defined ordering to satisfy an API contract.” Rangasamy, ¶¶ 138-140.
Claim 6
Rangasamy discloses wherein the documentation file is in the form of a Swagger file, an OpenAPI Specification, a JSON file, a RAML file, or an API Blueprint file. The API definition file is edited using “Swagger or YAML.” Rangasamy, ¶ 198; FIG.22 (block 2104); See Also ¶¶ 192, 195
Claim 7
Pollock discloses generating a notification displayed to a user indicative that the parameter names or parameter data types of the first API of the plurality of APIs are
inconsistent with an observed traffic index of the microservices architecture. Figure 6 illustrates “a process for generating API documentation and providing an alert” (alert → notification). At 606, the method determines “whether a change is observed in an API response.” At 608, “an alert is output,” wherein the alert may be a “visual … alert on a user interface.” The process includes “identifying changes to API documentation and provide an alert if there is a change.” For example, “if the addition of new parameters is detected, an alert may be generated” or “if an error rate associated with an API call meets a threshold (or trends change over time), an alert may be generated” (i.e., parameters inconsistent with an observed traffic index). Pollock, ¶¶ 67-71.
Claim 8
Rangasamy discloses a method for managing Application Programming Interfaces (APIs) in a microservices architecture. Rangasamy discloses a “development framework to facilitate application development for microservice-based application architectures,” wherein the framework “extends microservice development, platform, and deployment tools to … systematically develop highly-scalable applications made up of loosely-coupled microservices.” Rangasamy, ¶ 5.
Rangasamy discloses the method comprising: communicatively coupling a plurality of APIs organized into a microservices application architecture, the plurality of APIs and, by extension, the microservices application architecture maintained by an API management platform. The development framework includes “microservices, the orchestrator, and plugins,” wherein “a microservice implements a set of focused and distinct features or functions.” Each microservice in the development framework “adheres to a well-defined Application Programming Interface (API) specified in the corresponding service definition and may be orchestrated, by invoking the API of the microservice, according to a workflow performed by the orchestrator.” Id. at ¶ 7; See Also ¶¶ 13-15 (describing microservice platform for developing and executing a plurality of microservices). The orchestrator component coordinates “generated and implemented microservices based on rules or workflow defined for various APIs exposed by the orchestrator.” The development framework provides “code structuring … for easily scaffolding APIs defined for microservices, as well as facilitating the iterative development or microservices and orchestration workflows by providing automated tools for regenerating scaffolding up on the recalibration of API definitions.” Id. at ¶¶ 7-8.
Rangasamy discloses receiving, by the API management platform, user input of a predetermined type associated with a first API of the plurality of APIs of the microservices application, the user input configured to cause the API management platform to modify the first API. Rangasamy discloses that a developer may “begin development of an application by editing an API definition using, e.g., Swagger or YAML.” The developer “may explore and test the API” (i.e., execute a runtime test → user input). Id. at ¶¶ 198-200.
Rangasamy does not expressly disclose; providing data descriptive of the first API in parallel with modification of the first API to an artificial intelligence plugin as at least a portion of a query prompt that causes the artificial intelligence plugin to generate or update a documentation file associated with the first API based on the data descriptive of the first API; and receiving, by the API management platform, the documentation file.
Pollock discloses methods for “automatic generation of API documentation via implementation-neutral analysis of API traffic.” The documentation is “automatically generated in real-time or based on logged API traffic.” The method includes “receiving an API interaction, determining at least one interaction parameters based on the API interaction, and automatically generating the documentation based on the at least one interaction parameter.” Pollock, ¶ 19. In one embodiment, the method is performed by an “analyzer 120” (i.e., plugin). The analyzer 120 “is configured to generate API documentation based on traffic data.” Analyzer 120 “collects data based on an API interaction” including “hostname, HTTP method, security protocol used, … authentication path, parameter such as URI and POST body” and “response code, response message, response data, or the like” and also collects “data by determining the grammatical structure of an API interaction such as the structure of the request and any verbs or requested actions included in the API interaction.” Analyzer 120 determines “request parameter types, whether a request parameter is option or required, content type, security type, or the like” and determines the “response data scheme or the like.” Id. at ¶¶ 22-24; See Also ¶ 32 (Table 1 shows exemplary interaction data); ¶ 37 (describing parsing API interaction “to determine parameters such as syntactical elements, flags, and other attributes”).
Pollock discloses providing data descriptive of the first API in parallel with modification of the first API to an artificial intelligence plugin as at least a portion of a query prompt that causes the artificial intelligence plugin to generate or update a documentation file associated with the first API based on the data descriptive of the first API; and receiving, by the API management platform, the documentation file. Pollock discloses that “breaking changes that are undocumented may cause frustration because the API does not perform as expected.” Id. at ¶ 14. The API documentation “may provide advice about … changes to APIs.” Figure 3 illustrates how “API documentation may be updated to cover previously undocumented API interactions.” Id. at ¶¶ 25-26. At 304, the method “determines whether an undocumented API interaction has been detected,” and “if an undocumented API interaction is detected, the process proceeds to generate new API documentation (306)” corresponding to the undocumented API interaction.” Id. at ¶¶ 50-53. The API gateway “may forward the API interaction (here, a request and response) to analyzer 120” (request and response → query prompt). Based on the request and response data “analyzer 120 generated API documentation 104,” and is “further configured to update API documentation and/or generate an alert if a change is detected.” Id. at ¶¶ 32-33.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the microservice API development framework of Rangasamy to incorporate the automatic API documentation method taught by Pollock. One of ordinary skill in the art would be motivated to integrate the automatic API documentation into Rangasamy, with a reasonable expectation of success, in order to improve the user experience, because “APIs that are well-documented are well-received and more likely to be adopted and used,” and “facilitates integration of APIs into various systems and infrastructure.” Pollock, ¶ 19; See Also ¶ 15 (if the API documentation “is inadequate, users of the API may find it difficult to use the API, e.g., to automate the user’s own systems”).
Claim 9
Pollock discloses wherein the artificial intelligence plugin is based on training connected to semantic interpretation. Analyzer 120 “collects data based on an API interaction” including “hostname, HTTP method, security protocol used, … authentication path, parameter such as URI and POST body” and “response code, response message, response data, or the like” and also collects “data by determining the grammatical structure of an API interaction such as the structure of the request and any verbs or requested actions included in the API interaction.” Analyzer 120 determines “request parameter types, whether a request parameter is option or required, content type, security type, or the like” and determines the “response data scheme or the like.” Pollock, ¶¶ 22-24; See Also ¶ 32 (Table 1 shows exemplary interaction data); ¶ 37 (describing parsing API interaction “to determine parameters such as syntactical elements, flags, and other attributes”). The documentation includes “a description of how an API interaction can be used,” (i.e., expected operation) such as “definitions and/or descriptors for the determined interaction parameters” (i.e., based on the parameters names or parameter data types). Id. at ¶ 63. Further, Pollock discloses that “the analyzer may be trained by machine learning techniques such as supervised learning to improve its analytical activities” (i.e., trained using artificial intelligence). Id. at ¶ 46; See Also ¶ 59 (feedback used as validation set “to train a machine learning model to improve the automatic documentation of API interactions”).
Claim 10
Rangasamy discloses wherein the documentation file is in the form of a Swagger file, an OpenAPI Specification, a JSON file, a RAML file, or an API Blueprint file. The API definition file is edited using “Swagger or YAML.” Rangasamy, ¶ 198; FIG.22 (block 2104); See Also ¶¶ 192, 195
Claim 11
Rangasamy discloses wherein the user input of the predetermined type is any of: completion of a developer session that logs out a developer user; executing a runtime test; causing an active file to be saved; a lack of changes to the first API over a predetermined time period; or a first API changelog indication that a threshold change has been made to source code of the first API. Rangasamy discloses that a developer may “begin development of an application by editing an API definition using, e.g., Swagger or YAML.” The developer “may explore and test the API” (i.e., execute a runtime test → user input). Rangasamy, ¶¶ 198-200.
Claim 12
Pollock discloses wherein the data descriptive of the first API is any of: existing documentation files; an OpenAPI specification; a collection of test results of the first API; or
data describing live traffic through an API gateway, ingress controller or service mesh. Pollock discloses that “breaking changes that are undocumented may cause frustration because the API does not perform as expected.” Pollock, ¶ 14. The API documentation “may provide advice about … changes to APIs.” Figure 3 illustrates how “API documentation may be updated to cover previously undocumented API interactions.” Id. at ¶¶ 25-26. At 304, the method “determines whether an undocumented API interaction has been detected,” and “if an undocumented API interaction is detected, the process proceeds to generate new API documentation (306)” corresponding to the undocumented API interaction.” Id. at ¶¶ 50-53. The API gateway “may forward the API interaction (here, a request and response) to analyzer 120” (request and response → query prompt). Based on the request and response data “analyzer 120 generated API documentation 104,” and is “further configured to update API documentation and/or generate an alert if a change is detected.” Id. at ¶¶ 32-33.
Claim 13
Pollock discloses wherein the data descriptive of the first API is includes a query call to the artificial intelligence plugin indicating how the documentation file is to be generated based on the data descriptive of the first API. Pollock discloses that “breaking changes that are undocumented may cause frustration because the API does not perform as expected.” Pollock, ¶ 14. The API documentation “may provide advice about … changes to APIs.” Figure 3 illustrates how “API documentation may be updated to cover previously undocumented API interactions.” Id. at ¶¶ 25-26. At 304, the method “determines whether an undocumented API interaction has been detected,” and “if an undocumented API interaction is detected, the process proceeds to generate new API documentation (306)” corresponding to the undocumented API interaction.” Id. at ¶¶ 50-53. The API gateway “may forward the API interaction (here, a request and response) to analyzer 120” (request and response → query prompt). Based on the request and response data “analyzer 120 generated API documentation 104,” and is “further configured to update API documentation and/or generate an alert if a change is detected.” Id. at ¶¶ 32-33.
Claim 14
Pollock discloses generating a notification displayed to a user indicative that the parameter names or parameter data types of the first API of the plurality of APIs are inconsistent with an observed traffic index of the microservices architecture. Figure 6 illustrates “a process for generating API documentation and providing an alert” (alert → notification). At 606, the method determines “whether a change is observed in an API response.” At 608, “an alert is output,” wherein the alert may be a “visual … alert on a user interface.” The process includes “identifying changes to API documentation and provide an alert if there is a change.” For example, “if the addition of new parameters is detected, an alert may be generated” or “if an error rate associated with an API call meets a threshold (or trends change over time), an alert may be generated” (i.e., parameters inconsistent with an observed traffic index). Pollock, ¶¶ 67-71.
Claims 15-20
Claims 15-20 are rejected utilizing the aforementioned rationale for Claims 8-13; the claims are directed to a system performing the method.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK D MILLS whose telephone number is (571)270-3194. The examiner can normally be reached M-F 10-6 ET.
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 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.
/FRANK D MILLS/Primary Examiner, Art Unit 2194 June 9, 2026
Prosecution Insights