Detailed Action
1. This office action is in response to communication filed May 22, 2026. Claims 1-21 are currently pending and claims 1, 8, and 15 are the independent claims.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
3. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 5, 2026 has been entered.
Response to Amendment
4. This Non-Final Office Action is in response to the applicant’s remarks and arguments filed on May 22, 2026.
Claims 1, 8, and 15 were amended. No claims have been cancelled. No claims are new. Claims 1-21 remain pending in the application.
Response to Arguments
5. Applicant’s arguments, see Remarks pages 8-9, filed May 22, 2026, with respect to 35 U.S.C. 101 have been fully considered and are persuasive. The rejection of claims 1-21 under 35 U.S.C. 101 has been withdrawn.
On pages 8-9 of the Remarks, the Attorney respectfully submits that the 101 rejections are “wholly defective”.
The Examiner has removed the rejections made under 35 U.S.C. 101 in this Non-Final Rejection. After further review by the Examiner, the 101 rejections no longer stand following amendments to the claims, so they have been withdrawn from the Office Action.
6. Applicant’s arguments, see Remarks pages 7-8, filed May 22, 2026, with respect to the rejections of claims 1-21 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of 35 U.S.C. 103.
On Pages 7-8 of the Remarks, the Applicant respectfully submits that the claims are non-obvious, and the Applicant respectfully submits that the claimed invention is not obvious in view of the cited references.
The Examiner respectfully disagrees with the Attorney. The Examiner has reviewed the previous 103 rejections over the amendments to the independent claims including “determine if there is an existing application worker node for the pod having capacity for the CPU size and the amount of memory specified in the Python script execution request, assign the pod to the existing application worker node for execution when the existing application worker node has capacity for the specified CPU size and the amount of memory” and has withdrawn the previous 103 rejections. Following further search by the Examiner, the Examiner has submitted new 103 rejections for the independent claims as being unpatentable over Chawla et al. (NPL, “Building Microservices Applications on Microsoft Azure”) – hereinafter “Chawla”, in view of Hung et al. (U.S. Pub. No. 2019/0102411) – hereinafter “Hung”, Wei et al. (U.S. Pub. No. 2024/0111588) – hereinafter “Wei”, and Tang et al. (U.S. Pub. No. 2026/0236270) – hereinafter “Tang”. The new reference, Tang, discloses the amendments to the independent claims, so the non-obviousness of the independent claims is not agreed upon by the Examiner and as explained in the Claim Rejections - 35 USC § 103 section below, the Examiner has rejected claims 1-21 under 35 U.S.C. 103.
Information Disclosure Statement
7. The IDS submitted on January 5, 2026 was considered by the Examiner, but one reference has been denied. The “Amazon AWS SageMaker Developer Guide – first 400 pages” was received by the Examiner, but was illegible. The reference was resubmitted in legible format on May 5, 2026. However, the reference was once again not considered because a reference itself is not a properly filed IDS. The Applicant must refile the NPL doc and the IDS citing said doc for consideration.
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.
8. Claims 1-3, 8-10, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Chawla et al. (NPL, “Building Microservices Applications on Microsoft Azure”) – hereinafter “Chawla”, in view of Hung et al. (U.S. Pub. No. 2019/0102411) – hereinafter “Hung”, Wei et al. (U.S. Pub. No. 2024/0111588) – hereinafter “Wei”, and Tang et al. (U.S. Pub. No. 2026/0236270) – hereinafter “Tang”.
Regarding independent claim 1, Chawla discloses:
A system for execution of [programs] in a containerized, cloud-based, multi-tenant manner (Page 2, “… we will delve into the technology and infrastructure details to host microservices-based applications on Microsoft Azure Cloud.” and Page 34-35 “An important area of discussion is whether to host microservices on virtual machines or on containers. Both options can be implemented on-premise and on cloud platforms like Microsoft Azure ... Using containers to implement microservices is the most preferred option") The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the Azure cloud implements containerized application execution.
the system comprising:
a primary service node executing in a cloud computing system, the primary service node comprising a pod generator and a scheduler; and (Page 153 “kube-apiserver. The API server exposes underlying Kubernetes APIs to interact with management tools, such as kubectl or the Kubernetes dashboard” and “kube-scheduler. The scheduler is responsible for allocating the compute and storage required to create and scale containerized applications. The scheduler determines which nodes can accommodate the workload, and runs it on them.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the kube-apiserver and kube-scheduler are master node components that create and schedule pods.
at least one worker service node executing in the cloud computing system, each worker service node executing a service instance comprising a service application program interface (API) … wherein: (Page 154 “Kubernetes pods run your applications and supporting services” and Page 166 “In this section, we create an ASP.Net Core web API in Visual Studio. It will deploy a web API container on AKS.") The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the containerized application API will run in the pod just like the rest of the application.
each service instance is configured to receive an execution request from a client via the service API specifying a CPU size and an amount of memory required for execution of the Python script, … receive an output from execution of the [program], and asynchronously communicate the output to the client … and (Page 30 “If communication is required, asynchronous communication should take priority over synchronous communication because ft reduces coupling between services ..... If a return response is expected, it comes as a different message and the client assumes that the reply will not be received immediately, or there may not be a response at all.” and Figure 2-4 and Page 154 “A Kubernetes cluster can have multiple nodes, and each node translates into an Azure virtual machine and hosts the services. Depending on your application's resource needs, you can choose the VM size to make sure that you have enough CPU, memory, and storage.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the web server instance receives a request specifying resource needs including CPU, memory, and storage via server API and sends an output to the client.
the primary service node is configured to generate a pod containing an application container for the [program] … and otherwise dynamically allocate a new application worker node and assign the pod to the new application worker node for execution when the existing application worker node does not have capacity for the specified CPU size and the amount of memory. (Page 153 " kube-scheduler. The scheduler is responsible for allocating the compute and storage required to create and scale containerized applications. The scheduler determines which nodes can accommodate the workload, and runs it on them.'' and Page 155 "When creating a pod, you can specify the required resource limits, and kube-scheduler tries to run the pod on the node where the required resources are available.") The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the kube-scheduler creates and schedules pods when there are no available ponds corresponding to the CPU/memory requests of a client.
Chawla does not explicitly disclose:
… execution of Python scripts …
… a request validator, and a response controller …
… validate the request by the request validator, communicate the request to the primary service node …
… determine if there is an existing application worker node for the pod having capacity for the CPU size and the amount of memory specified in the Python script execution request, assign the pod to the existing application worker node for execution when the existing application worker node has capacity for the specified CPU size and the amount of memory …
However, Hung discloses:
… execution of Python scripts … ([0127] “Rule 450 may send request 460 to request broker 470, such as by using a REST request to send JSON, XML, or other CGI data over HTTP. In an embodiment, request 460 includes an executable script such as JavaScript, SQL, python, or a shell script, for execution by asynchronous job 480. Based on request 460 and configuration details 465, request broker 470 may create asynchronous job 480 whose execution may be deferred …”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the requests can include executable Python scripts.
Both Chawla and Hung are in the same field of endeavor as they are both in the request handling art and, therefore, are combinable/modifiable.
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 Chawla's request handling because Hung's request handling is based upon executable scripts of a certain programming language, specifically Python in the case of this invention, that performs an asynchronous job.
Motivation comes from Hung's invention to improve request handling based upon allowing an executable script from a plurality of programming languages to be run by a service providing “sandbox environment” resources that a user requires for demanding tasks across a network as taught by Hung [0015].
Chawla in combination with Hung does not explicitly disclose:
… a request validator, and a response controller …
… validate the request by the request validator, communicate the request to the primary service node …
… determine if there is an existing application worker node for the pod having capacity for the CPU size and the amount of memory specified in the Python script execution request, assign the pod to the existing application worker node for execution when the existing application worker node has capacity for the specified CPU size and the amount of memory …
In addition, Wei discloses:
… a request validator, and a response controller … (Fig. 2 and [0044] “API server 214 processes and validates resource availability requests and updates state of API objects in data store 212, thereby allowing users (e.g., customers, administrators, or the like) to configure workloads across worker nodes in worker node cluster 204.” and [0046] “Worker node 3 220 includes serverless workflow runtime 234 and message broker 236. Serverless workflow runtime 234 collects runtime information from process A 224, process B 226, process D 230, and process E 232 and sends the runtime information to API server 214, which API server 214 in turn shares with process manager 208.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the requests are validated and information is communicated and sent between the worker node and process manager.
… validate the request by the request validator, communicate the request to the primary service node … (Fig. 2 and [0044] “API server 214 processes and validates resource availability requests and updates state of API objects in data store 212, thereby allowing users (e.g., customers, administrators, or the like) to configure workloads across worker nodes in worker node cluster 204.” and [0046] “Worker node 3 220 includes serverless workflow runtime 234 and message broker 236. Serverless workflow runtime 234 collects runtime information from process A 224, process B 226, process D 230, and process E 232 and sends the runtime information to API server 214, which API server 214 in turn shares with process manager 208.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the requests are validated and information is communicated and sent between the worker node and process manager.
Chawla, Hung, and Wei are in the same field of endeavor as they are in the cloud environment request handling art and, therefore, are combinable/modifiable.
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 Chawla's and Hung’s request handling because Wei’s request handling is based upon request validating before distributing the request to a worker node for processing.
Motivation comes from Wei’s invention to improve request handling based upon authentication of requests so both the primary node and worker node have synchronization of data and have proper access to said data as taught by Wei [0036].
Chawla in combination with Hung and Wei do not explicitly disclose:
… determine if there is an existing application worker node for the pod having capacity for the CPU size and the amount of memory specified in the Python script execution request, assign the pod to the existing application worker node for execution when the existing application worker node has capacity for the specified CPU size and the amount of memory …
In addition, Tang discloses:
… determine if there is an existing application worker node for the pod having capacity for the CPU size and the amount of memory specified in the Python script execution request, assign the pod to the existing application worker node for execution when the existing application worker node has capacity for the specified CPU size and the amount of memory … ([0064] “In a practical application, the user may log in to an application code file creation interface of the function computing service system, complete editing of the personal application code file on the interface, and trigger a confirmation operation such as “save” or “submit” after completing the editing. During the editing, operations such as setting the runtime environment configuration information and selecting a compression format further need to be performed. The runtime environment configuration information includes, for example, a quantity of CPU cores to be used, memory capacity, network configuration, or a language environment.” and [0072] “When the control plane component receives an update request for the application code file triggered by the client, if the update request only indicates that the runtime environment configuration information of the original application code file is updated, the control plane component sends a corresponding notification to the server in which a container corresponding to the application code file has been created, so that the server updates runtime environment configuration information of the created container, for example, adjusting a quantity of CPU cores or memory capacity as indicated in the update request.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the user submits a request specifying CPU cores and memory capacity necessary for the runtime environment of the container/pod.
Chawla, Hung, Wei, and Tang are in the same field of endeavor as they are in the request handling art and, therefore, are combinable/modifiable.
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 Chawla's, Hung’s, and Wei’s request handling because Tang's request handling is based upon specifying CPU cores and memory capacity requirements for a runtime environment to ensure the specific requests being handled have the proper container specifications.
Motivation comes from Tang's invention to improve following container specification requirements based upon deploying the exact environment a user requests in terms of CPU cores and memory capacity to handle user request execution as taught by Tang [0005].
Regarding claim 2, Chawla discloses the system of claim 1, but does not explicitly disclose:
wherein the Python service API is a Representational State Transfer (REST) API.
However, Hung discloses:
wherein the Python service API is a Representational State Transfer (REST) API. ([0084] “In an embodiment, the asynchronous job framework provides representational state transfer (REST) APIs for clients to submit requests which are then translated into asynchronous jobs.” and [0127] “Rule 450 may send request 460 to request broker 470, such as by using a REST request to send JSON, XML, or other CGI data over HTTP. In an embodiment, request 460 includes an executable script such as JavaScript, SQL, python, or a shell script, for execution by asynchronous job 480. Based on request 460 and configuration details 465, request broker 470 may create asynchronous job 480 whose execution may be deferred …”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the REST requests submitted via the REST API can include executable Python scripts.
Both Chawla and Hung are in the same field of endeavor as they are both in the request handling art and, therefore, are combinable/modifiable.
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 Chawla's request handling because Hung's request handling is based upon executable scripts of a certain programming language, specifically Python in the case of this invention, that performs an asynchronous job.
Motivation comes from Hung's invention to improve request handling based upon allowing an executable script from a plurality of programming languages to be run by a service providing “sandbox environment” resources that a user requires for demanding tasks across a network and that request can be submitted specifically through a REST API as taught by Hung [0015] and [0127].
Regarding claim 3, Chawla discloses the system of claim 1, but does not explicitly disclose:
wherein the Python script execution request includes a timeout value, and wherein the application worker node executing the Python script terminates execution of the Python script if execution is not completed within the timeout value.
However, Hung discloses:
… Python script execution … ([0127] “Rule 450 may send request 460 to request broker 470, such as by using a REST request to send JSON, XML, or other CGI data over HTTP. In an embodiment, request 460 includes an executable script such as JavaScript, SQL, python, or a shell script, for execution by asynchronous job 480. Based on request 460 and configuration details 465, request broker 470 may create asynchronous job 480 whose execution may be deferred …”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the requests can include executable Python scripts.
Both Chawla and Hung are in the same field of endeavor as they are both in the request handling art and, therefore, are combinable/modifiable.
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 Chawla's request handling because Hung's request handling is based upon executable scripts of a certain programming language, specifically Python in the case of this invention, that performs an asynchronous job.
Motivation comes from Hung's invention to improve request handling based upon allowing an executable script from a plurality of programming languages to be run by a service providing “sandbox environment” resources that a user requires for demanding tasks across a network as taught by Hung [0015].
However, Wei discloses:
wherein the execution request includes a timeout value, and wherein the application worker node executing the Python script terminates execution of the Python script if execution is not completed within the timeout value. ([0052] “Process manager 208 utilizes timeout handler 244 to mark deployment of the additional process as failed when the additional process is not scheduled and finished running within a total timeout time. Administrative user 248 or another user defines the total timeout time based on, for example, user need.” and [0054] “However, it should be noted that alternative serverless workflow cloud process management environment 300 includes backfill handler 308 and timeout handler 310 in serverless workflow runtime 312 of worker node 3 314 instead of process manager 316. Process manager 316 is similar to process manager 208 in FIG. 2, except process manager 316 only includes process analyzer 318 and process predictor 320.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the timeout handler on the worker node terminates execution/marks deployment as failed if it is not complete within the timeout value that is defined by the user submitting the execution request.
Chawla, Hung, and Wei are in the same field of endeavor as they are in the cloud environment request handling art and, therefore, are combinable/modifiable.
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 Chawla's and Hung’s request handling because Wei’s request handling is based upon request validating before distributing the request to a worker node for processing.
Motivation comes from Wei’s invention to improve request handling based upon authentication of requests so both the primary node and worker node have synchronization of data and have proper access to said data and ensuring a request is not blocking other requests for a long enough time that a timeout is deemed necessary so that no infinite execution occurs as taught by Wei [0036] and [0052-0054].
Regarding claim 8, it is a computer-implemented method claim having the same limitations as cited in system claim 1. Thus, claim 8 is also rejected under the same rationale as addressed in the rejection of claim 1 above.
Regarding claim 9, it is a computer-implemented method claim having the same limitations as cited in system claim 2. Thus, claim 9 is also rejected under the same rationale as addressed in the rejection of claim 2 above.
Regarding claim 10, it is a computer-implemented method claim having the same limitations as cited in system claim 3. Thus, claim 10 is also rejected under the same rationale as addressed in the rejection of claim 3 above.
Regarding claim 15, it is a computer program product claim having the same limitations as cited in system claim 1. Thus, claim 15 is also rejected under the same rationale as addressed in the rejection of claim 1 above.
Regarding claim 16, it is a computer program product claim having the same limitations as cited in system claim 2. Thus, claim 16 is also rejected under the same rationale as addressed in the rejection of claim 2 above.
Regarding claim 17, it is a computer program product claim having the same limitations as cited in system claim 3. Thus, claim 17 is also rejected under the same rationale as addressed in the rejection of claim 3 above.
9. Claims 4-5, 7, 11-12, 14, 18-19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Chawla et al. (NPL, “Building Microservices Applications on Microsoft Azure”) – hereinafter “Chawla”, in view of Hung et al. (U.S. Pub. No. 2019/0102411) – hereinafter “Hung” and Wei et al. (U.S. Pub. No. 2024/0111588) – hereinafter “Wei” and Tang et al. (U.S. Pub. No. 2026/0236270) – hereinafter “Tang”, and further in view of Hebert et al. (U.S. Pub. No. 2018/0262558) – hereinafter “Hebert”.
Regarding claim 4, Chawla discloses the system of claim 1, but does not explicitly disclose:
wherein the Python script execution request includes parameters for retrieval of the Python script.
However, Hung discloses:
… Python script execution … ([0127] “Rule 450 may send request 460 to request broker 470, such as by using a REST request to send JSON, XML, or other CGI data over HTTP. In an embodiment, request 460 includes an executable script such as JavaScript, SQL, python, or a shell script, for execution by asynchronous job 480. Based on request 460 and configuration details 465, request broker 470 may create asynchronous job 480 whose execution may be deferred …”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the requests can include executable Python scripts.
Both Chawla and Hung are in the same field of endeavor as they are both in the request handling art and, therefore, are combinable/modifiable.
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 Chawla's request handling because Hung's request handling is based upon executable scripts of a certain programming language, specifically Python in the case of this invention, that performs an asynchronous job.
Motivation comes from Hung's invention to improve request handling based upon allowing an executable script from a plurality of programming languages to be run by a service providing “sandbox environment” resources that a user requires for demanding tasks across a network as taught by Hung [0015].
In addition, Hebert discloses:
wherein the execution request includes parameters for retrieval of the [application]. ([0027] “Each client, e.g., client(s) 102(1)-102(N), can be implemented as a computing entity, including but not limited to, a computer, a phone (e.g. a smart phone), a tablet, a virtual machine, among others. Each client accesses a server, e.g., server(s) 104, such as by issuing a request to execute an application. Each client also accesses, such as by using network 106A, user data that is stored using third-party storage 110. Each client also stores, using network 106A, user data at third-party storage 110. Each client provides one or more parameters to the server. These parameters can include location and/or type of data, operation(s) to be performed on this data, type and/or name of application(s) to be executed, among others.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the request to execute an application includes parameters for correct execution/retrieval.
Chawla, Hung, and Hebert are in the same field of endeavor as they are in the cloud environment request handling art and, therefore, are combinable/modifiable.
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 Chawla's and Hung’s request handling because Hebert’s request handling is based upon request parameters specifying the types of data, operations, and applications to be executed in the request.
Motivation comes from Hebert’s invention to improve request handling based upon clear specification by the user of the specific applications to be executed via the request as a required parameter so the requests are handled properly by the computing system as taught by Hebert [0004] and [0027].
Regarding claim 5, Chawla discloses the system of claim 4, but does not explicitly disclose:
wherein the application container retrieves the Python script based on the parameters.
However, Hung discloses:
… the Python script … ([0127] “Rule 450 may send request 460 to request broker 470, such as by using a REST request to send JSON, XML, or other CGI data over HTTP. In an embodiment, request 460 includes an executable script such as JavaScript, SQL, python, or a shell script, for execution by asynchronous job 480. Based on request 460 and configuration details 465, request broker 470 may create asynchronous job 480 whose execution may be deferred …”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the requests can include executable Python scripts.
Both Chawla and Hung are in the same field of endeavor as they are both in the request handling art and, therefore, are combinable/modifiable.
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 Chawla's request handling because Hung's request handling is based upon executable scripts of a certain programming language, specifically Python in the case of this invention, that performs an asynchronous job.
Motivation comes from Hung's invention to improve request handling based upon allowing an executable script from a plurality of programming languages to be run by a service providing “sandbox environment” resources that a user requires for demanding tasks across a network as taught by Hung [0015].
However, Hebert discloses:
wherein the application container retrieves the [application] based on the parameters. ([0029] “Server module 114 selects an application based on this request. For example, the request can include parameters that indicate operation(s) to be performed on data, and thus server module 114 selects an application that can perform such operation(s). Server module 114 selects computing resources for such an application. Server module 114 then communicates over network 106B with compute nodes 112(1)-112(N) to send communications (e.g., jobs) to execute the application using the selected computing resources with one or more compute nodes 112.” and [0030] “Each compute node 112(1)-112(2) may include one or more computing resources. A compute node, e.g., compute node 112(1), receives communication, over network 106B, (e.g., based on a workflow) from server module 114 to execute an application using one or more computing resources. The application accesses the data from third-party storage 110 during such execution, as specified by the parameters. The compute node(s) also return results of the application execution to server module 114.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the application is selected based on the request’s parameters.
Chawla, Hung, and Hebert are in the same field of endeavor as they are in the cloud environment request handling art and, therefore, are combinable/modifiable.
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 Chawla's and Hung’s request handling because Hebert’s request handling is based upon request parameters specifying the types of data, operations, and applications to be executed in the request.
Motivation comes from Hebert’s invention to improve request handling based upon clear specification by the user of the specific applications to be executed via the request as a required parameter so the requests are handled properly by the computing system as taught by Hebert [0004] and [0027].
Regarding claim 7, Chawla discloses the system of claim 4, but does not explicitly disclose:
wherein the parameters include a file name.
However, Hebert discloses:
wherein the parameters include a file name. ([0027] “Each client, e.g., client(s) 102(1)-102(N), can be implemented as a computing entity, including but not limited to, a computer, a phone (e.g. a smart phone), a tablet, a virtual machine, among others. Each client accesses a server, e.g., server(s) 104, such as by issuing a request to execute an application. Each client also accesses, such as by using network 106A, user data that is stored using third-party storage 110. Each client also stores, using network 106A, user data at third-party storage 110. Each client provides one or more parameters to the server. These parameters can include location and/or type of data, operation(s) to be performed on this data, type and/or name of application(s) to be executed, among others.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the request to execute an application includes parameters including file name for the application.
Chawla, Hung, and Hebert are in the same field of endeavor as they are in the cloud environment request handling art and, therefore, are combinable/modifiable.
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 Chawla's and Hung’s request handling because Hebert’s request handling is based upon request parameters specifying the types of data, operations, and applications to be executed in the request.
Motivation comes from Hebert’s invention to improve request handling based upon clear specification by the user of the specific applications and the files/data attached to those applications that are to be executed via the request as a required parameter so the requests are handled properly by the computing system as taught by Hebert [0004] and [0027].
Regarding claim 11, it is a computer-implemented method claim having the same limitations as cited in system claim 4. Thus, claim 11 is also rejected under the same rationale as addressed in the rejection of claim 4 above.
Regarding claim 12, it is a computer-implemented method claim having the same limitations as cited in system claim 5. Thus, claim 12 is also rejected under the same rationale as addressed in the rejection of claim 5 above.
Regarding claim 14, it is a computer-implemented method claim having the same limitations as cited in system claim 7. Thus, claim 14 is also rejected under the same rationale as addressed in the rejection of claim 7 above.
Regarding claim 18, it is a computer program product claim having the same limitations as cited in system claim 4. Thus, claim 18 is also rejected under the same rationale as addressed in the rejection of claim 4 above.
Regarding claim 19, it is a computer program product claim having the same limitations as cited in system claim 5. Thus, claim 19 is also rejected under the same rationale as addressed in the rejection of claim 5 above.
Regarding claim 21, it is a computer program product claim having the same limitations as cited in system claim 7. Thus, claim 21 is also rejected under the same rationale as addressed in the rejection of claim 7 above.
10. Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Chawla et al. (NPL, “Building Microservices Applications on Microsoft Azure”) – hereinafter “Chawla”, in view of Hung et al. (U.S. Pub. No. 2019/0102411) – hereinafter “Hung” and Wei et al. (U.S. Pub. No. 2024/0111588) – hereinafter “Wei”, and further in view of Hebert et al. (U.S. Pub. No. 2018/0262558) – hereinafter “Hebert” and Subramanian et al. (U.S. Pub. No. 2024/0111831) – hereinafter “Subramanian”.
Regarding claim 6, Chawla discloses the system of claim 4, but does not explicitly disclose:
wherein the parameters include a URL.
However, Subramanian discloses:
wherein the parameters include a URL. ([0165] “To perform a web services request, a network-based services client may assemble a message including the request and convey the message to an addressable endpoint (e.g., a Uniform Resource Locator (URL)) corresponding to the web service, using an Internet-based application layer transfer protocol such as Hypertext Transfer Protocol (HTTP).”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the request contains a URL as a parameter.
Chawla and Subramanian are in the same field of endeavor as they are in the cloud environment request handling art and, therefore, are combinable/modifiable.
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 Chawla's request handling because Subramanian’s request handling is based upon web services request parameters specifying a URL with which the request is conveyed.
Motivation comes from Subramanian’s invention to improve request handling based upon allowing web services requests on top of API requests (which have previously been described) to handle more examples of user execution requests as taught by Subramanian [0029] and [0165].
Regarding claim 13, it is a computer-implemented method claim having the same limitations as cited in system claim 6. Thus, claim 13 is also rejected under the same rationale as addressed in the rejection of claim 6 above.
Regarding claim 20, it is a computer program product claim having the same limitations as cited in system claim 6. Thus, claim 20 is also rejected under the same rationale as addressed in the rejection of claim 6 above.
Conclusion
11. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This prior art includes:
- Krishna Singuru (U.S. Patent No. 10,656,980), Panikkar (U.S. Pub. No. 2023/0123350), and Sathe et al. (U.S. Patent No. 12,360,817) that all involved containerized workload management. They specifically involve workers and worker managers similar to the application at hand.
- Moussaoui (U.S. Pub. No. 2022/0357995) discloses system physical resources allocated by a cluster management node to a cluster node running an application in a Kubernetes Pod such that Pods are generated to ensure that applications have enough resources necessary to handle their requests.
- Beveridge (U.S. Pub. No. 2024/0241763) which discloses grid server components 161 can identify the subset of the grid nodes that have a respective CPU capacity and memory capacity equal to or greater than a specified minimum CPU capacity and a minimum memory capacity.
- Ono et al. (U.S. Pub. No. 2022/0058044) which discloses a VM creation request outlining CPU cores, memory capacity, and OS information for the VM which is very similar to the invention outlining container/pod specifications for handling the user’s request.
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.
When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c).
When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL B TRAINOR whose telephone number is (571)272-3710. The examiner can normally be reached Monday-Friday 9AM-5PM.
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.
/D.T./Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
