Detailed Action
1. This office action is in response to communication filed December 29, 2025. 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 .
Response to Amendment
3. This Final Office Action is in response to the applicant’s remarks and arguments filed on
December 29, 2025.
Claims 1, 8, and 15 were amended. No claims have been cancelled. No claims are new. Claims 1-21 remain pending in the application. Claims 2-7, 9-14, and 16-21 filed on April 30, 2023 are being considered on the merits along with amended claims 1, 8, and 15.
Response to Arguments
4. Applicant's arguments filed December 29, 2025 have been fully considered but they are not persuasive.
On Page 7 of the Remarks, the Attorney respectfully submits that the claims as amended are not disclosed or suggested by the cited references.
The Examiner respectfully disagrees with the Attorney. The amendments to the independent claims including “the Python script execution request specifies a CPU size and an amount of memory” and “the primary service node dynamically allocates a new application worker node and assigns the pod to the new application worker node when there is no existing application worker node for the pod having capacity for the specified CPU size and the amount of memory” do not overcome the previous 103 rejections in the Non Final Rejection Office Action. As explained in the Claim Rejections - 35 USC § 103 section below, the primary reference Chawla et al. discloses the amendments. Further details and explanations appear below. As such, claims 1-21 remain rejected under 35 U.S.C. 103.
On pages 7-8 of the Remarks, the Attorney respectfully submits that “claims 1-7 are not directed to software per se but instead are directed to a system that includes various software and hardware components (e.g., cloud computing systems) and interactions between such components. The claims provide a technological solution to problems that arise solely in technology. Therefore, patent eligibility should be self-evident, but certainly the claims should be deemed patent eligible for providing a practical application of any abstract ideas or concepts that may be included in the claims.”
The Examiner respectfully disagrees with the Attorney. The amendments made to claim 1 do not overcome the software per se rejections from the Non-Final Rejection Office Action. The primary service node in claim 1 can be interpreted and implemented as software or a software module. The Attorney provided no support via Specification or Drawing references to conclude that the system provides structure. A cloud computing system does not clearly state structure. Additionally, dependent claims 2-7 do not provide any structure not previously seen in independent claim 1, so claims 1-7 remain rejected under 35 U.S.C. 101 as directing to software per se.
Information Disclosure Statement
5. 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 is illegible. Resubmission of the reference is suggested if a higher quality scan/document is available.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
6. Claims 1-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because the claims are directed to software per se wherein no claim language in claim 1 provides structure. The primary service node in claim 1 can be interpreted and implemented as software or a software module. Thus, the system claim is merely comprising the software module corresponding to the primary service node and therefore claim 1 is considered as software per se claim. Additionally, dependent claims 2-7 do not provide any structure not previously seen in independent claim 1, so claims 1-7 are rejected under 35 U.S.C. 101 as directing to software per se.
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.
7. 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” and Wei et al. (U.S. Pub. No. 2024/0111588) – hereinafter “Wei”.
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, … 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 assign the pod to an application worker node for execution including, when there is no existing application worker node for the pod having capacity for the specified CPU size and the amount of memory, dynamically allocating a new application worker node and assigning the pod to the new application worker node. (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 …
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.
The claimed invention is derived from the combining of the concept of execution of Python scripts in the secondary reference Hung with the concept of A system for execution of [programs] in a containerized, cloud-based, multi-tenant manner in the primary reference Chawla. Thus, the limitation of A system for execution of Python scripts in a containerized, cloud-based, multi-tenant manner is taught by the primary reference with support from the secondary reference.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add execution of Python scripts as seen in Hung's invention into Chawla's invention because these modifications allow applying a known technique to a known system ready for improvement to yield predictable results such that specifically Python scripts are to be ran rather than any multitude of programs so that the system is built to efficiently handle Python script execution.
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.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add a request validator, and a response controller and validate the request by the request validator and communicate the request to the primary service node as seen in Wei's invention into Chawla's invention because these modifications allow use of a known technique to improve similar systems in the same way such that authentication of requests is ensured so both the primary node and worker node have synchronization of data and have proper access to said data.
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.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the Python service API is a Representational State Transfer (REST) API as seen in Hung's invention into Chawla's invention because these modifications allow simple substitution of one known element for another to obtain predictable results such that simplicity and stable design occur in connection with a multitude of other APIs.
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.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add Python script execution as seen in Hung's invention into Chawla's invention because these modifications allow applying a known technique to a known system ready for improvement to yield predictable results such that specifically Python scripts are to be ran rather than any multitude of programs so that the system is built to efficiently handle Python script execution.
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.
The claimed invention is derived from the combining of the concept of execution of Python scripts in the secondary reference Hung with the concept of 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 in the secondary reference Wei. Thus, the limitation of 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 is taught by the secondary reference Hung with support from the secondary reference Wei.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add 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 as seen in Wei's invention into Chawla's invention because these modifications allow the use of a known technique to improve similar systems in the same way such that a node is to be freed up if a script execution takes an unreasonable amount of time to ensure no infinite executions occur.
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.
8. 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 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.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add Python script execution as seen in Hung's invention into Chawla's invention because these modifications allow applying a known technique to a known system ready for improvement to yield predictable results such that specifically Python scripts are to be ran rather than any multitude of programs so that the system is built to efficiently handle Python script execution.
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.
The claimed invention is derived from the combining of the concept of Python script execution in the secondary reference Hung with the concept of wherein the execution request includes parameters for retrieval of the [application] in the secondary reference Hebert. Thus, the limitation of wherein the Python script execution request includes parameters for retrieval of the Python script is taught by the secondary reference Hung with support from the secondary reference Hebert.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the execution request includes parameters for retrieval of the [application] as seen in Hebert’s invention into Chawla's invention because these modifications allow the use of a known technique to improve similar systems in the same way such that the selection of the script and its running environment are declared by the user requesting the execution of the Python script so that it is ran properly.
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.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add Python script(s) as seen in Hung's invention into Chawla's invention because these modifications allow applying a known technique to a known system ready for improvement to yield predictable results such that specifically Python scripts are to be ran rather than any multitude of programs so that the system is built to efficiently handle Python script execution.
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.
The claimed invention is derived from the combining of the concept of the Python script in the secondary reference Hung with the concept of wherein the application container retrieves the [application] based on the parameters in the secondary reference Hebert. Thus, the limitation of wherein the application container retrieves the Python script based on the parameters is taught by the secondary reference Hung with support from the secondary reference Hebert.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the application container retrieves the Python script based on the parameters as seen in Hebert’s invention into Chawla's invention because these modifications allow the use of a known technique to improve similar systems in the same way such that the pre-determined qualifications ensure that the Python script is ran in the environment exactly as the user expects.
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.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the parameters include a file name as seen in Hebert’s invention into Chawla's invention because these modifications allow the simple substitution of one known element for another to obtain predictable results such that the execution environment is to access the Python script within the user’s file system.
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.
9. 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.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the parameters include a URL as seen in Subramanian’s invention into Chawla's invention because these modifications allow the simple substitution of one known element for another to obtain predictable results such that the execution environment is to access the Python script from an online source.
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
10. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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. Additionally, 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.
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