DETAILED ACTION
This communication is in response to the application filed on March 29, 2024 in which
claims 1-20 are pending in the application. Claims 1, 11, and 20 are in independent form.
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 .
Drawings
The drawings are objected to under 37 CFR 1.83(a). The drawings must show every feature of the invention specified in the claims. Therefore, the file executor in claims 6 and 16 must be shown or the feature(s) canceled from the claim(s). No new matter should be entered.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
[0030] recites "this indication may be based on a user 103 entering a command associated with the function, Based on this query, the function may be called by a processor associated with the user environment." The comma before "Based" joins two sentences and the passage should recite "... a command associated with the function. Based on this query, ...".
[0038] recites "a variable that is compatible with user environment" (should recite "with the user environment.
Appropriate correction is required.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 1, 3-5, 9-11, 13-15, 19, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Thakur et al. (US 2021/0294679 A1) (hereinafter Thakur) in view of Lucas et al. (US 2020/0311085 A1) (hereinafter Lucas) in view of Wagner et al. (US 2016/0092250 A1) (hereinafter Wagner).
As per claim 1, Thakur primarily teaches the invention as claimed including:
A method for application programming interface (API) generation comprising:
constructing a query schema for a computing environment ([0023] a query orchestrator, such as the Apollo Federation Server, at a request gateway can expose an API to external services and software applications based on the declarative schemas associated with each service in the collection of services; [0027] request gateway 110 may expose the API as a graph projection in which a graph query language is used to define a function invoked by a received request; [0030] API generator 120 can generate an updated graph projection of the API and deploy the updated graph projection of the API to request gateway 110);
constructing an orchestrator for the query schema and the computing environment ([0023] a query orchestrator, such as the Apollo Federation Server, at a request gateway; [0028] to algorithmically build the graph projection of the API, request gateway 110 composes together the declarative schemas stored in declarative schema data store 130 defining each of the services 150 in computing environment 100; [0037] API generator 120 generally uses declarative schemas associated with each of a plurality of services 150 in computing environment 100 to generate and deploy ... a graph projection of an API to request gateway 110),
Thakur's query orchestrator at request gateway 110, such as the Apollo Federation Server, corresponds to the claimed orchestrator, and the declarative schemas associated with the services 150 correspond to the claimed query schema. The orchestrator is constructed for the query schema because it is generated from the declarative schemas and exposes the API based on them ([0023] and [0028]). It is constructed for the computing environment because the schemas define the services 150 in computing environment 100, to which the query orchestrator routes each received request for execution ([0028] and [0026]).
wherein: the orchestrator is configured to interact with the query schema in order to determine responses to requests received via an API ([0026] request gateway 110 can examine the received request against information defining the API to identify the one or more services to which the request is to be routed for execution ... request gateway 110 collects responses from the identified one or more services to produce a response for the requesting external source (e.g., an external client application) and [0032] request gateway 110 may persist the updated declarative schema to a central data store ... and persist a mapping from the schema to service operations defined by the declarative schema); and
Thakur does not explicitly teach:
the orchestrator is written in a domain specific language associated with the computing environment; and
exposing, by a container service of the computing environment, the API based on the query schema and the orchestrator.
However, Lucas teaches:
the orchestrator is written in a domain specific language associated with the computing environment ([0026] schema blueprint data comprising a plurality of different service definitions, each of the service definitions composed in a domain specific language (DSL), each service definition comprising identification of an endpoint and one or more schema definition language elements; [0093] schema blueprint data comprises a plurality of service definitions composed in a DSL that control the structure of a combined schema or API once generated; [0028] generating a first resolver function to resolve the first field in the combined schema with the first resource and generating a second resolver function to resolve the second field in the combined schema with the second resource).
Lucas's service definitions composed in the DSL, together with the resolver functions generated from them, correspond to the claimed orchestrator written in a domain specific language. The DSL is associated with the computing environment because each service definition identifies the endpoint of a service in that environment ([0026]). In the combination, Thakur's query orchestrator is written in Lucas's domain specific language, its service definitions composed in the DSL and its resolver logic generated from them.
Thakur and Lucas are both concerned with generating a combined graph API that exposes the functions of a plurality of underlying services and are therefore combinable/modifiable.
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 Thakur in view of Lucas by composing the service definitions of Thakur's query orchestrator in a domain specific language that captures the endpoint and the schema elements of each service in a single service definition.
Motivation would improve consistency of the combined schema because the service definitions composed in the domain specific language control the structure of the combined schema once generated and prevent clashes between field elements as taught by Lucas ([0093] and [0094]).
Thakur in view of Lucas do not explicitly teach:
exposing, by a container service of the computing environment, the API based on the query schema and the orchestrator.
Thakur discloses exposing the API based on the query schema and the orchestrator. The query orchestrator at request gateway 110 exposes the API to external services and software applications based on the declarative schemas ([0023]). The schema sets which requests the API accepts ([0026] and [0027]), and the orchestrator produces each response ([0026]). Thakur's exposure is made from the request gateway itself, and the gateway's hosting is a generic computer system ([0090]). Exposing the API from a gateway on a generic computer system is not exposing it by a container service of the computing environment.
However, Wagner teaches:
exposing ([0025] the frontend 120 processes all the requests to execute user code on the virtual compute system 110 ... the frontend 120 serves as a front door to all the other services provided by the virtual compute system 110 and [0027] the frontend 120 may receive the request to execute such user codes in response to Hypertext Transfer Protocol Secure (HTTPS) requests from a user), by a container service of the computing environment ([0040] the worker manager 140 may create a new container on such an instance, assign the container to the request, and cause the user code to be loaded and executed in the container; [0028] the user request is a ZIP file containing the user code and any libraries (and/or identifications of storage locations thereof)), the API based on the query schema and the orchestrator ([0026] the user code as used herein may refer to any program code (e.g., a program, routine, subroutine, thread, etc.) written in a specific program language ... in connection with a particular web application or mobile application developed by the user).
Wagner's virtual compute system 110 receives the code to be run as files, the ZIP file of [0028], and executes it, matching the specification as filed [0019] a container service (e.g., a program configured to receive and execute files). Wagner's user code may be any program code ([0026]), so in the combination the deployed code is Thakur's orchestrator, with the query schema as the accompanying file it uses, and Thakur's exposure of the API is performed by Wagner's container service.
Thakur, Lucas, and Wagner are all concerned with executing server-side code to service client requests and are therefore combinable/modifiable.
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 Thakur in view of Lucas in view of Wagner so that the API is exposed by a container service that receives and executes Thakur's query schema and orchestrator on demand.
Motivation would improve responsiveness of the exposed API because the container service creates each container on a virtual machine instance already booted and loaded with operating systems and language runtimes by the time requests are received as taught by Wagner ([0014]).
As per claim 3, Lucas further teaches wherein interacting with the query schema comprises extracting information from the query schema based on a request received via the API ([0045] when a client issues a query to a GraphQL endpoint, each field on each type is resolved by a resolver function at the GraphQL endpoint. The resolver function defines how data is fetched for that field and returns data for that field and [0044] once the schema is defined, resolver functions are used for fetching data from remote endpoints).
As per claim 4, the combination of references above teaches wherein the request references a function associated with the orchestrator (Lucas [0045] each field on each type is resolved by a resolver function at the GraphQL endpoint and Thakur [0027] a graph query language is used to define a function invoked by a received request).
As per claim 5, Lucas further teaches wherein the extracting of the information from the query schema is based on the function including logic that references the query schema ([0028] generating a first resolver function to resolve the first field in the combined schema with the first resource and generating a second resolver function to resolve the second field in the combined schema with the second resource and [0045] the resolver function defines how data is fetched for that field and returns data for that field).
As per claim 9, Thakur further teaches wherein the query schema is based on a declarative language ([0023] based on the declarative schemas associated with each service in the collection of services and [0027] a graph projection in which a graph query language is used to define a function invoked by a received request).
As per claim 10, Thakur further teaches determining not to execute the orchestrator based on detecting an error in the query schema or the orchestrator ([0033] if, however, request gateway 110 experiences a failure to validate the updated schema ... request gateway 110 may declare the update as a failed update ... request gateway 110 may further take one or more fallback actions, such as reloading a previous version of the schema or blocking execution of invalid code, so that failures in validating the updated schema do not cause operations within computing environment 100 ... to fail in an unhandled or unexpected manner).
As per claim 11, it has similar limitations as claim 1 and is therefore rejected using the same rationale. Thakur further teaches one or more processors; and a memory comprising instructions that, when executed by the one or more processors, cause the system to perform the operations ([0090] CPU 602 may retrieve and execute programming instructions stored in the memory 608 ... the CPU 602 may retrieve and store application data residing in the memory 608).
As per claim 13, it has similar limitations as claim 3 and is therefore rejected using the same rationale.
As per claim 14, it has similar limitations as claim 4 and is therefore rejected using the same rationale.
As per claim 15, it has similar limitations as claim 5 and is therefore rejected using the same rationale.
As per claim 19, it has similar limitations as claim 9 and is therefore rejected using the same rationale.
As per claim 20, it has similar limitations as claim 1 and is therefore rejected using the same rationale. The combination of references above further teaches:
the orchestrator comprises logic for extracting information from the query schema in order to determine responses to requests received via an API (Lucas [0028] generating a first resolver function to resolve the first field in the combined schema with the first resource and [0044] once the schema is defined, resolver functions are used for fetching data from remote endpoints);
receiving, via the API, a request from a user for particular information (Lucas [0045] when a client issues a query to a GraphQL endpoint and [0004] a strongly typed runtime which allows clients to dictate what data is needed);
executing the logic of the orchestrator to extract the particular information from the query schema based on the request (Lucas [0088] the graph endpoint executes the first resolver function to resolve the first field in the combined schema with the first resource and also executes the second resolver function to resolve the second field in the combined schema with the second resource);
providing a response to the request based on the extracted particular information (Lucas [0045] returns data for that field and Thakur [0026] request gateway 110 collects responses from the identified one or more services to produce a response for the requesting external source).
Claim(s) 2 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Thakur in view of Lucas in view of Wagner in view of Mazon et al. (US 2016/0092297 A1) (hereinafter Mazon).
As per claim 2, Thakur in view of Lucas in view of Wagner disclose the claimed invention as detailed above for claim 1 but do not explicitly teach:
constructing one or more configuration files and providing the configuration files to the container service, wherein the orchestrator is configured to use the configuration files to configure the API.
However, Mazon teaches:
constructing one or more configuration files and providing the configuration files to the container service ([0015] a gateway developer portal 102 may include an editor allowing developers to enter code, policies and configuration details to be added to dynamic scripts 104, 106, 108 which are then validated and added to the production script. The new script may then be pushed out to any updated instances of the gateway. The files are used as read only repositories), wherein the orchestrator is configured to use the configuration files to configure the API ([0016] the dynamic scripts 104, 106 and 108 provide the system with the data it needs to process requests. A properties file 104 provides general configuration settings, such as the location of data ... an API definition file 108 includes all the information related to the service and the API that the system needs ... technical details are included such as service identification details, the origin URL, and environment and [0020] the gateway performs pre-routing 302, which may include authenticating 304 the request by looking up the key 106 and API definition 108, to ensure that the requestor is allowed access to the system and service, and what kind of access is allowed).
Mazon's API gateway, the code base executed to receive and route client requests to the registered services, corresponds to the claimed orchestrator. The gateway uses the configuration files to configure the API because the files carry the settings the API runs on, the location of data, the origin URL of the service behind the API, and the access and rate limit policies, and the gateway looks the files up in processing each request ([0016] and [0020]). In the combination, the gateway code in the orchestrator's place is Thakur's query orchestrator, as detailed above for claim 1, and the configuration files pushed to its instances are provided to the container service that runs them.
Thakur, Lucas, Wagner, and Mazon are all concerned with executing server-side code to service client requests and are therefore combinable/modifiable.
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 Thakur in view of Lucas in view of Wagner in view of Mazon to push Thakur's query orchestrator to the container service together with configuration files that the orchestrator uses to configure the API.
Motivation would improve reliability of the exposed API because the configuration files provide all the details required for handling requests and responses, so serving the API depends on nothing outside the running system, as taught by Mazon ([0005]).
As per claim 12, it has similar limitations as claim 2 and is therefore rejected using the same rationale.
Claim(s) 6, 7, 16, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Thakur in view of Lucas in view of Wagner in view of Lucovsky et al. (US 2011/0265164 A1) (hereinafter Lucovsky).
As per claim 6, Thakur in view of Lucas in view of Wagner disclose the claimed invention as detailed above for claim 1. Wagner further teaches wherein the query schema is constructed in a compressed file format ([0028] the user request is a ZIP file containing the user code and any libraries (and/or identifications of storage locations thereof)); the orchestrator is constructed in a compressed file format ([0028]).
Thakur in view of Lucas in view of Wagner do not explicitly teach:
the container service comprises a file executor that is configured to expose the API based on decompressing the query schema and the orchestrator.
However, Lucovsky teaches:
the container service comprises a file executor that is configured to expose the API based on decompressing the query schema and the orchestrator ([0028] deployment agent 428 unpacks the web application deployment package and installs runtime environment 430 (e.g., Apache Tomcat application server, etc), including loading the WAR file (or other package) associated web application 125 into the appropriate directory of the runtime environment; [0023] generates a start script file that can be executed by a container VM to start a runtime environment and launch the submitted web application; [0020] router 136 receives the web browser's access request (e.g., a uniform resource locator or URL) and routes the request to container VM).
Thakur, Lucas, Wagner, and Lucovsky are all concerned with executing server-side code to service client requests and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify Thakur in view of Lucas in view of Wagner in view of Lucovsky with a deployment agent that unpacks Thakur's compressed query schema and orchestrator from the delivered package inside the container and launches them.
Motivation would improve flexibility of the container service because the deployment package carries its own runtime environment, installed into the container when the package is unpacked, so the container service can run code built for any of a plurality of application frameworks and runtime environments, as taught by Lucovsky ([0003] and [0004]).
As per claim 7, Thakur in view of Lucas in view of Wagner in view of Lucovsky disclose the claimed invention as detailed above for claims 1 and 6, and further teach wherein the container service is configured to automatically update the API based on receiving and decompressing an additional query schema or an additional orchestrator (Thakur [0030] update operations may be invoked by a service 150 having an updated declarative schema by the service 150 transmitting the updated declarative schema to request gateway 110 for processing; Thakur [0032] a graph projection of the API may be reloaded from the schemas; Wagner [0068] the versioning and deployment manager 150 detects that the code associated with the request is an updated version of a code that has already been loaded onto the virtual compute system 110; Wagner [0071] causes a subsequent code execution request associated with the updated version of the code to be processed with the updated version of the code loaded onto one of the containers; Lucovsky [0028] deployment agent 428 unpacks the web application deployment package).
Thakur, Lucas, Wagner, and Lucovsky are all concerned with executing server-side code to service client requests and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify Thakur in view of Lucas in view of Wagner in view of Lucovsky to have the container service automatically update the API when an additional query schema or an additional orchestrator is received with the versioning manager loading the new version.
Motivation would avoid any latency increase when the query schema or orchestrator is updated because requests continue to be serviced with the older version while the versioning manager downloads new version, as taught by Wagner ([0051]).
As per claim 16, it has similar limitations as claim 6 and is therefore rejected using the same rationale.
As per claim 17, it has similar limitations as claim 7 and is therefore rejected using the same rationale.
Claim(s) 8 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Thakur in view of Lucas in view of Wagner in view of Yu et al. (US 2009/0019525 A1) (hereinafter Yu).
As per claim 8, Thakur in view of Lucas in view of Wagner disclose the claimed invention as detailed above for claim 1 but do not explicitly teach:
wherein the domain specific language is a declarative language.
However, Yu teaches:
the domain specific language is a declarative language ([0042] the first is a declarative language, BASS, for server-side scripting and [0021] in the area of declarative web programming, domain-specific language constructs have been used to program web applications).
Thakur, Lucas, Wagner, and Yu are all concerned with executing server-side code to service client requests and are therefore combinable/modifiable.
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 Thakur in view of Lucas in view of Wagner in view of Yu by making the domain specific language of Thakur's orchestrator a declarative language.
Motivation would improve security of the orchestrator code because the declarative language handles the low-level details of processing web input instead of the programmer, guaranteeing that the values obtained always have the expected types and that the forged requests from the attackers are rejected, as taught by Yu ([0076]).
As per claim 18, it has similar limitations as claim 8 and is therefore rejected using the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pilli et al. (US 2024/0394248) discloses generating a GraphQL API schema comprising a set of objects and a set of resolver functions based on the selected elements (abstract), which relates to the claimed constructing of a query schema and an orchestrator for the query schema.
Islam et al. (US 9,904,585) discloses a workflow interpreter service that interprets a workflow definition language for specifying a workflow definition (abstract), which relates to the claimed orchestrator written in a domain specific language associated with the computing environment.
Tseng et al. (US 2020/0082413) discloses that fraud detection is achieved using a flexible scripting language and syntax that simplifies the generation of fraud detection rules (abstract), which relates to the claimed determining not to execute the orchestrator based on detecting an error.
Sanchez et al. (US 2021/0200527) discloses a code execution service to receive a request to trigger execution of a serverless function and to determine deployment status information for a previous serverless function version based on the request (abstract), which relates to the claimed container service configured to automatically update the API.
Khillar et al. (US 2021/0248143) discloses that the server can identify a schema file for operating the API query language on the data source ... translate the API query language operation into an SQL operation using the API query language schema file configured for the data source (abstract), which relates to the claimed orchestrator configured to interact with the query schema in order to determine responses to requests received via an API.
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THANH NGO whose telephone number is (571)270-3019. The examiner can normally be reached M-F 9am to 6pm ET, first F of biweek off.
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, Pierre Vital can be reached at (571)272-4215. 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.
/T.N./ Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights