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 .
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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 Ayyalasomayajula (US 2022/0342646, hereinafter Ayyalasomayajula ) in view of Zhu (US 2014/0222890, hereinafter Zhu) and Gasperowicz (US 2025/0232029, hereinafter Gasperowicz).
Regarding claim 1, Ayyalasomayajula discloses
A method for implementing an application programming interface (API) integration library by utilizing one or more processors and one or more memories, the method comprising: receiving an API call corresponding to a user request of a process flow to access one or more resources (paragraph [0006-0007]: receiving a user request of a process flow corresponding to develop, test, or manage a desired application; paragraph [0091, 0110, 0113]: access a data source… for a plurality of resources);
creating an API call configuration file having a reusable and standardized format, wherein the API call configuration file includes detail data that specifies how the API connects to the one or more resources to execute the user request, how to create a standardized request, how to map a standardized response back in response to the user request, how to handle retry attempts when the user request fails (paragraph [0007]: creating an index file… wherein the index file includes details data of how an API is executed; paragraph [0006]: configuration files… written using JSON… XML, YAML; paragraph [0110]: headers refers to the key-value pairs that need to be passed in for the headers of an API; body refers to the key-value pairs that need to be passed in for the body; paragraph [0113]: retry refers to a number that allows for the re-execution of the API in the event of a failure), environment-specific authentication configuration data for authenticating an API connection in an environment in which a desired application is to be deployed and environment-specific connection data including different uniform resource locators (paragraph [0075]: modules written for APIs for all environments; paragraph [0110]: “url” refers to the endpoint the system is trying to access);
causing an API integration library to receive the API call configuration file as input that utilizes the API call configuration file to process the user request (paragraph [0095]: causing a language agnostic packaging platform (i.e., spectrum (library) 510) to receive the index file 508 as input that utilizes the index file 508 to process the user request); and
automatically creating, by the API integration library, a desired application as output of the process flow based on the received API call configuration file (paragraph [0096]: automatically create the desired application 512 as output of the process flow based on the received index file 508).
Ayyalasomayajula does not explicitly detail environment-specific authentication configuration data… and environment-specific connection data including … different authentication mechanisms for corresponding environment levels, … wherein the API integration library abstracts out an API invocation and an authentication mechanism, for the API call.
Zhu discloses environment-specific authentication configuration data… and environment-specific connection data including … different authentication mechanisms for corresponding environment levels (paragraph [0039]: utilizing different authentication mechanisms (e.g., OAuth, Facebook Connect, OpenID) depending on the identity provider and platform requirements).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the API integration platform of Ayyalasomayajula to include different authentication mechanisms for corresponding environment levels as taught by Zhu. The motivation would have been to utilize the appropriate authentication protocols depending on the specific identity provider and platform requirements (Zhu paragraph [0039]).
Gasperowicz discloses wherein the API integration library abstracts out an API invocation and an authentication mechanism, for the API call (paragraph [0042]: adapters can streamline inter-agent communication by abstracting the intricacies of HTTP interactions… bypassing the need to handle the minutiae of network requests; paragraph [0082]: To maintain the security of sensitive information like API keys, the agent management platform provides API proxies that are pre-authenticated using keys stored within the session context. Using API proxies ensures that agents are not responsible for managing authentication credentials and are able to operate without direct access to secrets).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the API integration platform of Ayyalasomayajula in view of Zhu to have the library abstract out the API invocation and authentication mechanisms as taught by Gasperowicz. The motivation would have been to streamline communication by bypassing the need to handle the minutiae of network requests, and to ensure that agents are not responsible for managing authentication credentials and can operate without direct access to secrets (Gasperowicz paragraphs [0042], [0082]).
Regarding claim 12 referring to claim 1, Ayyalasomayajula discloses A system for implementing an application programming interface (API), the system comprising: a receiver that receives a user request of a process flow to access one or more resources; and a processor coupled to the receiver via a communication network, wherein the processor is configured to: … (paragraph [0015]: A system for implementing a language agnostic packaging platform… comprising: a receiver that receives a user request… a processor coupled to the receiver… configured to: create an index file… cause a language agnostic packaging platform to receive the index file… automatically create… the desired application; See also the rejection for claim 1).
Regarding claim 17 referring to claim 1, Ayyalasomayajula discloses A non-transitory computer readable medium configured to store instructions for implementing an application programming interface (API) integration library, wherein, when executed, the instructions cause a processor to perform the following: … (paragraph [0019]: A non-transitory computer readable medium configured to store instructions… cause a processor to perform the following: causing a receiver to receive a user request… creating an index file… automatically creating… the desired application; See also the rejection for claim 1).
Regarding claims 2 and 13, Ayyalasomayajula discloses
further comprising: creating the API call configuration file in any one of the following file formats: JSON, xml, and yml (paragraph [0008]: creating the index file in any one of the following file formats: index.json, index.xml, and index.yml).
Regarding claim 3, Ayyalasomayajula in view of Zhu does not explicitly detail further comprising: abstracting out from the user request the API invocation; and using an API portal to describe rules that an API gateway applies to each API invocation. Gasperowicz discloses further comprising: abstracting out from the user request the API invocation (paragraph [0042]: adapters can streamline inter-agent communication by abstracting the intricacies of HTTP interactions… bypassing the need to handle the minutiae of network requests); and using an API portal to describe rules that an API gateway applies to each API invocation (paragraph [0029]: A unified API gateway can provide an interface (i.e., API portal] for validating data (i.e., rules), generating documentation; paragraph [0041]: The API gateway 130 can manage and route API requests… provide a unified interface for invoking agents… The API gateway 130 can use predefined input schemas (i.e., rules) of each agent or swarm to validate incoming and outgoing data [applied to each API invocation], ensuring adherence to expected formats and facilitating the auto-generation of comprehensive documentation). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the API integration platform of Ayyalasomayajula in view of Zhu to implement an API gateway with an interface/portal to define and apply validation rules to each API invocation as taught by Gasperowicz. The motivation would have been to provide a unified interface to validate incoming and outgoing data, ensure adherence to expected formats, and fortify the platform’s security (Gasperowicz paragraphs [0041], [0042]).
Regarding claim 4, Ayyalasomayajula discloses
Further comprising: implementing a request attribute mapper module configured to manipulate the received user request with available values (paragraph [0010]: implementing a request mapper module configured to manipulate the received user request with available values; paragraph [0103]: request mapper module 434 may be configured to manipulate the request with available values).
Regarding claim 5, Ayyalasomayajula discloses
further comprising: further comprising: implementing a response attribute mapper module configured to rearrange the output of the process flow into a response format specified by the API call configuration file (paragraph [0011]: implementing a response mapper module configured to rearrange the output of the process flow in a desired manner; paragraph [0104]: response mapper module 436 may be configured to re-arrange the output of a process in the desired manner; paragraph [0112]: “post-process” refers to a set of key-value pairs that allow a user to modify the output of the API; paragraph [0115]: “post-process” refers to any formatting needs to be executed after executing the processes).
Regarding claims 6 and 14, Ayyalasomayajula discloses
further comprising: implementing a retry configuration module configured to specify … to handle the retry attempts when the user request fails (paragraph [0113]: “retry” refers to a number that allows for the re-execution of the API in the event of a failure, until the specified threshold is reached).
Ayyalasomayajula does not explicitly disclose to specify a read timeout and a connection time timeout to handle the retry attempts when the user request fails. Zhu discloses to specify a read timeout and a connection time timeout to handle the retry attempts when the user request fails (paragraph [0043]: The JSON protocol defines the message structure that accounts for the reliability (reconnect, retransmissions, timeouts etc) of the message; paragraph [0046]: Retransmission Queue 302A, 302B allows for retransmission of messages for which there is an error or lack of acknowledgement). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the retry module of Ayyalasomayajula to specify read and connection time timeouts, as taught by Zhu. The motivation would have been to effectively manage network reliability, retransmissions, and reconnects during retry attempts to prevent system hangs when endpoints are unresponsive (Zhu paragraphs [0043], [0046]).
Regarding claim 7, Ayyalasomayajula discloses
further comprising: implementing the retry configuration module configured to specify the retry attempts… for a predetermined number of times (paragraph [0113]: “retry” refers to a number that allows for the re-execution of the API in the event of a failure, until the specified threshold is reached).
Ayyalasomayajula does not explicitly disclose to specify the retry attempts based on an HTTP status and over a predetermined time interval. Zhu discloses specifying the retry attempts over a predetermined time interval (paragraph [0043]: The JSON protocol defines the message structure that accounts for the reliability (reconnect, retransmissions, timeouts etc) of the message). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the retry module of Ayyalasomayajula to specify the retry attempts over a predetermined time interval as taught by Zhu. The motivation would have been to account for the reliability of the message structure by properly managing reconnects, retransmissions, and timeouts (Zhu paragraph [0043]).
Gasperowicz discloses specifying the retry attempts based on an HTTP status (paragraph [0042]: adapters can streamline inter-agent communication by abstracting the intricacies of HTTP interactions… bypassing the need to handle the minutiae of network requests). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the retry module of Ayyalasomayajula in view of Zhu to specify the retry attempts based on an HTTP status as taught by Gasperowicz. The motivation would have been to streamline communication by abstracting the intricacies of HTTP interactions, thereby bypassing the need to manually handle the minutiae of network requests (Gasperowicz paragraph [0042]).
Regarding claims 8 and 15, Ayyalasomayajula discloses
further comprising: selectively accessing a communication model configured to define a sequence of operations for the user request based on requirements of the desired application (paragraph [0115]: “processes” refers to the order of execution of the resources; paragraph [0116]: The platform provided by the LAPM 406 allows a user simply to pick and choose specific sub-list processes to execute a desired process).
Regarding claims 9 and 19, Ayyalasomayajula discloses
a communication model (paragraph [0115]: “processes” refers to the order of execution of the resources).
Ayyalasomayajula does not explicitly disclose wherein the communication model is a synchronous communication model or an asynchronous communication model. Gasperowicz discloses wherein the communication model is an asynchronous communication model (paragraph [0040]: The message bus 116 provides a communication channel… allowing asynchronous and decoupled data exchange between agents, services, and nodes). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate an asynchronous communication model as taught by Gasperowicz into the process flow of Ayyalasomayajula in view of Zhu. The motivation would have been to allow for decoupled data exchange and non-blocking resource execution, thereby improving application performance (Gasperowicz paragraph [0040]).
Regarding claims 10 and 16, Ayyalasomayajula discloses
deploying to specific environments (paragraph [0139]: tailored to the specifications of any environment).
Ayyalasomayajula does not disclose further comprising; implementing an environment specific configuration module configured to define different authentication mechanisms at each environment level of the process flow. Zhu discloses further comprising; implementing an environment specific configuration module configured to define different authentication mechanisms at each environment level of the process flow (paragraph [0039]: their identities are authenticated via an Identity Provider Management Module (IDP) 210 that supports OAuth 212, Facebook Connect (FBC) 214 and other Identity Protocols… depending on the identity provider and platform requirements). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure environment-specific authentication mechanisms as taught by Zhu into the platform of Ayyalasomayajula. The motivation would have been to ensure that the application can be securely deployed across different environment levels using the appropriate authentication protocols depending on specific platform requirements (Zhu paragraph [0039]).
Regarding claim 11, Ayyalasomayajula discloses
one of the environment levels (paragraph [0139]: specifications of any environment).
Ayyalasomayajula does not disclose wherein one of the environment levels is selected from a group consisting of: a development environment, a testing environment, a staging environment, and a production environment. Gasperowicz discloses wherein one of the environment levels is selected from a group consisting of: a development environment, a testing environment, a staging environment, and a production environment (paragraph [0074]: a local development server… enabling developers to test and debug their agents in their local programming environment as well as deploy the developers’ agents to the agent management platform). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize these standard industry environments as taught by Gasperowicz in the system of Ayyalasomayajula in view of Zhu. The motivation would have been to facilitate a standard software lifecycle, allowing developers to safely test and debug applications in a local development environment before deploying them to a live platform (Gasperowicz paragraph [0074]).
Regarding claim 18, Ayyalasomayajula discloses
wherein, when executed, the instructions further cause the processor to perform the following: creating the API call configuration file in any one of the following file formats: JSON, xml, and yml (paragraph [0008]: creating the index file in any one of the following file formats: index.json, index.xml, and index.yml).
Regarding claim 19, Ayyalasomayajula discloses
wherein, when executed, the instructions further cause the processor to perform the following: selectively accessing a communication model configured to define a sequence of operations for the user request based on requirements of the desired application and … (paragraph [0115]: “processes” refers to the order of execution of the resources; paragraph [0116]: The platform provided by the LAPM 406 allows a user simply to pick and choose specific sub-list processes to execute a desired process).
Ayyalasomayajula does not explicitly disclose wherein the communication model is a synchronous communication model or an asynchronous communication model. Gasperowicz discloses wherein the communication model is an asynchronous communication model (paragraph [0040]: The message bus 116 provides a communication channel… allowing asynchronous and decoupled data exchange between agents, services, and nodes). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate an asynchronous communication model as taught by Gasperowicz into the process flow of Ayyalasomayajula in view of Zhu. The motivation would have been to allow for decoupled data exchange and non-blocking resource execution, thereby improving application performance (Gasperowicz paragraph [0040]).
Regarding claim 20, Ayyalasomayajula discloses
separating components (paragraph [0006]: separating each of these application and infrastructure resource components into a configuration).
Ayyalasomayajula does not explicitly disclose wherein, when executed, the instructions further cause the processor to perform the following: separate a business logic from an application logic to create, maintain or update the desired application. Gasperowicz discloses wherein, when executed, the instructions further cause the processor to perform the following: separate a business logic from an application logic to create, maintain or update the desired application ((paragraph [0076]: programmers are able to focus on defining the unique aspects of the programmers’ agents without being encumbered by the complexities of agent boilerplate, state management, instrumentation, and/or orchestration. The agent management platform abstracts these concerns… thus streamlining the path from agent conception to execution). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the separation of unique agent logic from underlying application boilerplate as taught by Gasperowicz to the platform of Ayyalasomayajula in view of Zhu. The motivation would have been to focus on defining the unique aspects of the programmers’ agents without being encumbered by the complexities of agent boilerplate, state management, instrumentation, and/or orchestration, and to abstract these concerns thus streamlining the path from agent conception to execution (Gasperowicz paragraph [0076]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Marquié (US 2024/0012821) discloses systems and methods for evaluating the accuracy and quality of application programming interface (API) integrations for a system of record using a test corpus and judgment list to determine an accuracy score (Abstract; paragraphs [0003]-[0004], [0038]-[0045]). This is highly relevant to the applicant’s disclosure regarding the testing, deployment, and management of API integrations and process flows across different environment levels.
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 [0037] 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 extension fee pursuant to [0037] 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7:30PM.
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, April Y. Blair can be reached on (571)270-1014. 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.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 9/13/2026
Prosecution Insights