USING MACHINE LEARNING FOR EXECUTING BATCH JOBS IN DISTRIBUTED CLOUD ENVIRONMENT

Application No. 18/352,422

• Filed: Jul 14, 2023
• Examiner: SUN, ANDREW NMN
• Art Unit: 2195
• Tech Center: 2100 — Computer Architecture & Software
• Assignee: Oracle Financial Services Software Limited
• OA Round: 2 (Final)

Office Action

DETAILED ACTION
Claims 1, 3-15, and 17-20 are pending.
Claims 2 and 16 are canceled.
Claims 1, 3-15, and 17-20 are rejected.

Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .

Response to Arguments
Applicant's arguments with respect to the 35 U.S.C. 103 rejections (Remarks p. 12-15) have been fully considered and are unpersuasive.

1. The Applicant argues regarding reference Panikkar:

PNG
media_image1.png
352
626
media_image1.png
Greyscale

The applicant respectfully disagrees with this statement. The Examiner mapped the claimed “thread initialization time” to the disclosed difference between the “starting time” of the task and the time the threads are initialized. Since the “starting time” can be shifted left, it is not necessarily defined as always 0, and shifting the “starting time” left will reduce the thread initialization time.
Furthermore, Panikkar discloses, “If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072.
Here, an acceptable claimed “process execution time” is determined by possibly changing the number of threads based on possibly changing the maximum completion time (represented as a variable called “MAX_TIME”) and the “starting time”. The starting time is the thread initialization time, and process execution time is the maximum completion time minus the starting time. It can be seen that both the thread initialization time and the process execution time are mapped to explicit, separate values.

2. The Applicant argues regarding reference Johnson:

PNG
media_image2.png
330
630
media_image2.png
Greyscale

The applicant respectfully disagrees with this statement. Johnson was added specifically to teach a one-to-one correspondence between a thread and a virtual machine, in order for the combination of references used to teach selecting cloud virtual machines based on a list of thread counts and completion times. Johnson was not used to teach using a list of (thread count, completion time) pairs to drive matching to available cloud VMs or combinations, or ranking/selecting among available VMs or combinations by efficiency or cost for each pair, because Panikkar already teaches using such a list of pairs to match with available threads or combinations thereof, and Johnson is combined to have each thread correspond to a virtual machine. Ranking/selecting among virtual machines is done by references used later in the rejection, such as Agarwal or Thomas.

Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.

Claims 1, 3, 9-11, 17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Panikkar (US 20230168940 A1) in view of Ovsiankin (US 20150277980 A1), Johnson (WO 2013142983 A1), and Agarwal (US 20250036448 A1).
Regarding Claim 1, Panikkar teaches a computer-implemented method comprising: estimating a number of threads to execute a batch job within a maximum completion time by executing a thread estimation algorithm (
Panikkar discloses, “For example, in an illustrative inspection mode, the task manager finds the optimal number of threads (parallel processes) required for a given load to complete the task within the range of time configured, with less than a given percentage of resource utilization in that environment (e.g., even in production),” ¶ 0058, and “If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072.
The claimed “maximum completion time” is mapped to the disclosed time that is configured for a task to be completed, which is described as the “range of time configured” in paragraph 58, and also described as the “MAX_TIME” variable in paragraph 72. The MAX_TIME variable is configured initially to be the maximum time required to complete a task, and it can be increased if it is exceeded during the execution of a task.);
the executing the thread estimation algorithm comprising:
for each number of threads among a plurality of numbers of threads between 2 and a predetermined maximum number of threads, iteratively performing steps (a) to (e) until the predetermined maximum number of threads is reached (
Panikkar discloses, “In step 708, when inspection mode is selected, intelligent timekeeper 620 starts a single thread and starts the task, and records the time for a single record transaction to complete,” ¶ 0066, and “If, in step 716, inspection engine 622 determines that the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS is greater than or equal to MAX_TIME, then task configurator 626 instructs scheduler/orchestrator 612 to iteratively add one more thread and start parallel processing from step 708, until UNIT_ROUND_TRIP_TIME is less than MAX_TIME,” ¶ 0070.
This means that the process is initially started with 1 thread and for each loop an additional thread is added. This means that the claimed range between 2 and the predetermined maximum number of threads is included in the disclosed range between 1 and a predetermined maximum number of threads.):
(a) determining a thread initialization time for processing the batch job, based on a current number of threads in a current iteration among a plurality of iterations (
Panikkar discloses, “If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072.
The claimed “thread initialization time” is mapped to the disclosed difference between the “starting time” of the task and the time the threads are initialized. Since the “starting time” can be shifted left, it is not necessarily defined as always 0, and shifting the “starting time” left will reduce the thread initialization time.
Since the shifting of the starting time is based on PROBABLE_NUMBER_OF_MAX_THREADS, the thread initialization time is thus based on the current number of threads.),
(b) determining a process execution time as the maximum completion time less the thread initialization time (
Panikkar discloses, “If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072.
An acceptable “process execution time” is determined by possibly changing the number of threads based on possibly changing the maximum completion time (represented as a variable called “MAX_TIME”) and the “starting time”. The starting time is the thread initialization time, and process execution time is the maximum completion time minus the starting time.),
(c) providing(
Panikkar discloses, “In step 710, resource monitor 624 obtains the CPU and memory consumption percentage data of the server (or other underlying physical infrastructure) of container service orchestration platform 606 that ran the microservice for the single record transaction, and provides the data to inspection engine 622. Resource monitor 624 also records the total round trip time (RTT) associated with the request/response for this single record transaction during inspection mode, e.g., UNIT_ROUND_TRIP_TIME,” ¶ 0067, and “If, in step 716, inspection engine 622 determines that the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS is greater than or equal to MAX_TIME, then task configurator 626 instructs scheduler/orchestrator 612 to iteratively add one more thread and start parallel processing from step 708, until UNIT_ROUND_TRIP_TIME is less than MAX_TIME,” ¶ 0070, “If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072, and “Accordingly, by way of example of methodology 700 described above, when task manager 604 runs in production for the first time, it executes in inspection mode starting with a single thread and a single unit of process (e.g., single record transaction). Task manager 604 records information including the number of threads, data load (e.g., number of records), time taken, CPU consumption, and memory consumption,” ¶ 0074.
The claimed “predicted number of records” is mapped to the number of records that would be processed, equal to the maximum amount of time, represented by the variable “MAX_TIME”, divided by the variable “UNIT_ROUND_TRIP_TIME”.),
(d) determining whether the predicted number of records is greater than or equal to an expected number of records processable using the current number of threads (
Panikkar discloses, “Further, in step 704, user/system inputs 603 also specify to task manager 604 a (actual or approximate) largest number of data units, MAX_PROCESS_UNITS, expected to execute for the task, e.g., number of records, data sets, or number of rows in a source table in source data store 602,” ¶ 0064,
“If, in step 716, inspection engine 622 determines that the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS is greater than or equal to MAX_TIME, then task configurator 626 instructs scheduler/orchestrator 612 to iteratively add one more thread and start parallel processing from step 708, until UNIT_ROUND_TRIP_TIME is less than MAX_TIME,” ¶ 0070.
The claimed “expected number of records” is mapped to the “MAX_PROCESS_UNITS” variable that defines the maximum number of records that is processable.
The predicted number of records is MAX_TIME divided by the variable UNIT_ROUND_TRIP_TIME. The predicted number of records and expected number of records are compared by comparing the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS, with MAX_TIME.), and
(e) if the predicted number of records is greater than or equal to the expected number of records, providing, as an input to the ML model, the expected number of records, to obtain an actual completion time to process the expected number of records for the current iteration, and saving, in a list of threads and completion times, a pair comprising the current number of threads and the actual completion time (
Panikkar discloses, “If, in step 716, inspection engine 622 determines that the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS is greater than or equal to MAX_TIME, then task configurator 626 instructs scheduler/orchestrator 612 to iteratively add one more thread and start parallel processing from step 708, until UNIT_ROUND_TRIP_TIME is less than MAX_TIME,” ¶ 0070, and “Note that the metrics collected and/or computed by inspection engine 622 (MIN_TIME, MAX_TIME, MAX_PROCESS UNITS, UNIT_ROUND_TRIP_TIME, PROBABLE_NUMBER_OF_MAX_THREADS, as well as and any other metrics or other data) are stored in inspection metrics store 628, in step 722, for use in instructing scheduler/orchestrator 612 on how many threads or other processing units to instantiate for executing the task during run mode,” ¶ 0073.),
wherein, as a result of the steps (a) to (e), the list of threads and completion times is obtained that stores one or more combinations, each of the one or more combinations comprising a pair comprising a number of threads and an actual completion time (
Panikkar discloses, “Note that the metrics collected and/or computed by inspection engine 622 (MIN_TIME, MAX_TIME, MAX_PROCESS UNITS, UNIT_ROUND_TRIP_TIME, PROBABLE_NUMBER_OF_MAX_THREADS, as well as and any other metrics or other data) are stored in inspection metrics store 628, in step 722, for use in instructing scheduler/orchestrator 612 on how many threads or other processing units to instantiate for executing the task during run mode,” ¶ 0073.
The metrics collected include the number of threads and the multiplicative product of UNIT_ROUND_TRIP_TIME with MAX_PROCESS_UNITS for each number of threads, which is compared with MAX_TIME to see if it is under MAX_TIME. If so, the number of threads and the combination of threads that makes up the number is capable of executing the job within MAX_TIME.);
(f) for each pair of the one or more combinations in the list of threads and completion times:
identifying available threads or combinations thereof capable of executing the batch job with at least the number of threads and within a corresponding actual completion time of the pair (
Panikkar discloses, “Note that the metrics collected and/or computed by inspection engine 622 (MIN_TIME, MAX_TIME, MAX_PROCESS UNITS, UNIT_ROUND_TRIP_TIME, PROBABLE_NUMBER_OF_MAX_THREADS, as well as and any other metrics or other data) are stored in inspection metrics store 628, in step 722, for use in instructing scheduler/orchestrator 612 on how many threads or other processing units to instantiate for executing the task during run mode,” ¶ 0073.
The metrics collected include the number of threads and the multiplicative product of UNIT_ROUND_TRIP_TIME with MAX_PROCESS_UNITS for each number of threads, which is compared with MAX_TIME to see if it is under MAX_TIME.),
.
Panikkar does not teach providing, as an input to a machine learning (ML) model, the process execution time for the current iteration, to obtain a predicted number of records to be processed by the current number of threads; wherein the threads correspond to cloud virtual machines; or ranking the identified available cloud virtual machines or combinations thereof according to resource efficiency or cost, to obtain a ranked list for the pair; and selecting, from one or more ranked lists, an optimal virtual machine or an optimal virtual machine combination, the optimal virtual machine or the optimal virtual machine combination being capable of executing the batch job within the maximum completion time.
However, Ovsiankin teaches providing, as an input to a machine learning (ML) model, the process execution time for the current iteration, to obtain a predicted number of records to be processed by the current number of threads (
Ovsiankin discloses, “The predictive-optimization technique can generally include any machine-learning technique that can be used to predict an objective, such as the average execution time for a job, based on parameters associated with the job… Moreover, possible machine-learning techniques can include using: a neural network; a regression technique; a time-series model; a Bayesian classifier; simulated annealing; and a support-vector machine,” ¶ 0042.
After the combination of Panikkar with Ovsiankin, the model from Ovsiankin is used to obtain a predicted number of records and determine the actual completion time to process the expected number of records.).
Panikkar and Ovsiankin are both considered to be analogous to the claimed invention because they are in the same field of computer task scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar to incorporate the teachings of Ovsiankin and provide providing, as an input to a machine learning (ML) model, the process execution time for the current iteration, to obtain a predicted number of records to be processed by the current number of threads. Doing so would help improve performance in predicting the number of records to be processed using the model, thus aiding in performance of the tasks being run (Ovsiankin discloses, “Next, the system uses the predictive-optimization technique to determine resource-allocation parameters for the job based on associated input parameters to optimize an execution performance of the job, wherein the predictive-optimization technique uses a model that was trained running previous MapReduce jobs on the multi-tenant system,” Abstract.).
Panikkar in view of Ovsiankin does not teach wherein the threads correspond to cloud virtual machines; or ranking the identified available cloud virtual machines or combinations thereof according to resource efficiency or cost, to obtain a ranked list for the pair; and selecting, from one or more ranked lists, an optimal virtual machine or an optimal virtual machine combination, the optimal virtual machine or the optimal virtual machine combination being capable of executing the batch job within the maximum completion time.
However, Johnson teaches wherein the threads correspond to cloud virtual machines (
Johnson discloses, “We therefore define it from the ground up in terms of a virtual machine ( V ) with a single thread of control (no parallelism, no time-slicing),” Page 48.
Panikkar already teaches cloud-based infrastructure, stating “Accordingly, the term ‘information processing system’ as used herein is intended to be broadly construed, so as to encompass, for example, processing platforms comprising cloud and/or non-cloud computing and storage systems, as well as other types of processing systems comprising various combinations of physical and/or virtual processing resources. An information processing system may therefore comprise, by way of example only, at least one data center or other type of cloud-based system that includes one or more clouds hosting tenants that access cloud resources,” ¶ 0017.
After the combination of Panikkar in view of Ovsiankin with Johnson, the list of threads and completion times from Panikkar in view of Ovsiankin is used to determine the optimal virtual machine to use, as there is now a one-to-one correspondence between a thread and a virtual machine as specified by Johnson. The virtual machine from Johnson is also now hosted on the cloud-based infrastructure as specified by Panikkar.).
Panikkar in view of Ovsiankin, and Johnson are both considered to be analogous to the claimed invention because they are in the same field of server-based computing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin to incorporate the teachings of Johnson and provide wherein the threads correspond to cloud virtual machines. Doing so would help provide increased flexibility for specifying the configuration of the selected virtual machine, and reduce overhead of managing multiple threads within a virtual machine.
Panikkar in view of Ovsiankin and Johnson does not teach ranking the identified available cloud virtual machines or combinations thereof according to resource efficiency or cost, to obtain a ranked list for the pair; and selecting, from one or more ranked lists, an optimal virtual machine or an optimal virtual machine combination, the optimal virtual machine or the optimal virtual machine combination being capable of executing the batch job within the maximum completion time.
However, Agarwal teaches ranking the identified available cloud virtual machines or combinations thereof according to resource efficiency or cost, to obtain a ranked list for the pair (
Agarwal discloses, “In some embodiments, the candidate VM selection component 208 also includes a VM sorting component 211. In embodiments, the VM sorting component 211 scores one or more sets of candidate VMs based on a scoring function. In an example, the VM sorting component 211 uses a scoring function that measures a degree of imbalance between a stranded resource at the node and a bottleneck resource used by at least one VM at the node,” ¶ 0068, and “In embodiments, the VM sorting component 211 also sorts the VMs in descending order based on each VM's score… Referring to process flow 400, after operation of the VM sorting component 211 at step 404 (score and sort VMs), the set 401c of a subset of VMs on candidate node(s) becomes a set 401d of sorted VMs.,” ¶ 0072.
The claimed ranking is mapped to the disclosed sorting of the VMs based on each VM’s score.
As a result of the sorting of the sets of candidate VMs, they now form a ranked list. After the combination of Panikkar in view of Ovsiankin and Johnson, with Agarwal, this ranking is based on resource efficiency or cost, wherein a higher score now indicates greater resource efficiency or lower cost.
After the combination of Panikkar in view of Ovsiankin and Johnson, with Agarwal, this ranking is done for each pair of the number of threads, and the multiplicative product of UNIT_ROUND_TRIP_TIME with MAX_PROCESS_UNITS, from Panikkar.);
and selecting, from one or more ranked lists, an optimal virtual machine or an optimal virtual machine combination, the optimal virtual machine or the optimal virtual machine combination being capable of executing the batch job within the maximum completion time (
Agarwal discloses, “In embodiments, the VM sorting component 211 also selects the N highest scored VMs (with positive values) as a set of candidate VMs for migration,” ¶ 0073.
Here, the highest scored virtual machines are considered to be optimal. After the combination of Panikkar in view of Ovsiankin and Johnson, with Agarwal, the ranking is based on resource efficiency or cost, wherein a higher score now indicates greater resource efficiency or lower cost. The optimal virtual machine selected is now selected based on greatest resource efficiency or lowest cost, so said optimal virtual machine is capable of executing the batch job within the maximum completion time.).
Panikkar in view of Ovsiankin and Johnson, and Agarwal are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin and Johnson to incorporate the teachings of Agarwal and ranking the identified available cloud virtual machines or combinations thereof according to resource efficiency or cost, to obtain a ranked list for the pair; and selecting, from one or more ranked lists, an optimal virtual machine or an optimal virtual machine combination, the optimal virtual machine or the optimal virtual machine combination being capable of executing the batch job within the maximum completion time. Doing so would help ensure that the most efficient virtual machines can be selected more easily.

Regarding Claim 3, Panikkar in view of Ovsiankin, Johnson, and Agarwal teaches the computer-implemented method of claim 1, wherein the expected number of records is calculated by dividing a total number of records by the current number of threads (
Panikkar discloses, “Note that the metrics collected and/or computed by inspection engine 622 (MIN_TIME, MAX_TIME, MAX_PROCESS_UNITS, UNIT_ROUND_TRIP_TIME, PROBABLE_NUMBER_OF_MAX_THREADS, as well as and any other metrics or other data) are stored in inspection metrics store 628, in step 722, for use in instructing scheduler/orchestrator 612 on how many threads or other processing units to instantiate for executing the task during run mode,” ¶ 0073.
Here MAX_PROCESS_UNITS can be divided by PROBABLE_NUMBER_OF_MAX_THREADS to obtain the maximum number of process units per thread.);
and the step (e) further includes: obtaining, as an output the ML model, a running time corresponding to the expected number of records (
Ovsiankin discloses, “This predictive-optimization technique can be used to select resource-allocation parameters (e.g., number of mappers and reducers) to minimize an objective for the job. For example, the objective can include: (1) a total running time for the job, wherein the job comprises a plurality of tasks that can execute in parallel,” ¶ 0043.);
and calculating the actual completion time by adding the thread initialization time to the running time output by the ML model (
Panikkar discloses, “If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072.).
Panikkar and Ovsiankin are both considered to be analogous to the claimed invention because they are in the same fields of computer architecture and machine learning. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar to incorporate the teachings of Ovsiankin and provide obtaining, as an output the ML model, a running time corresponding to the expected number of records. Doing so would help increase accuracy/convenience of the predicted completion times by using the model.

Regarding Claim 9, Panikkar in view of Ovsiankin, Johnson, and Agarwal teaches a computer program product tangibly embodied in one or more non-transitory machine-readable storage media including instructions configured to cause one or more data processors to perform the computer-implemented method of claim 1 (
Panikkar discloses, “Further illustrative embodiments are provided in the form of a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps,” ¶ 0005.).

Regarding Claim 10, Panikkar in view of Ovsiankin, Johnson, and Agarwal teaches a computer system comprising: one or more data processors; and a non-transitory computer-readable medium storing instructions that, when executed by the one or more data processors, cause the one or more data processors to perform the computer- implemented method of claim 1 (
Panikkar discloses, “Further illustrative embodiments are provided in the form of a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further illustrative embodiments comprise an apparatus with a processor and a memory configured to perform the above steps,” ¶ 0005.).

Regarding Claim 11, Panikkar teaches a computer-implemented method comprising: for each of a plurality of candidate thread counts for processing a batch job within a maximum completion time (
Panikkar discloses, “For example, in an illustrative inspection mode, the task manager finds the optimal number of threads (parallel processes) required for a given load to complete the task within the range of time configured, with less than a given percentage of resource utilization in that environment (e.g., even in production),” ¶ 0058,
“In step 708, when inspection mode is selected, intelligent timekeeper 620 starts a single thread and starts the task, and records the time for a single record transaction to complete,” ¶ 0066,
“If, in step 716, inspection engine 622 determines that the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS is greater than or equal to MAX_TIME, then task configurator 626 instructs scheduler/orchestrator 612 to iteratively add one more thread and start parallel processing from step 708, until UNIT_ROUND_TRIP_TIME is less than MAX_TIME,” ¶ 0070, and
“If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072.
The claimed “maximum completion time” is mapped to the disclosed time that is configured for a task to be completed, which is described as the “range of time configured” in paragraph 58, and also described as the “MAX_TIME” variable in paragraph 72. The MAX_TIME variable is configured initially to be the maximum time required to complete a task, and it can be increased if it is exceeded during the execution of a task.):
determining a thread initialization time and a process execution time based on the candidate thread count and the maximum completion time (
Panikkar discloses, “If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072.
The claimed “thread initialization time” is mapped to the disclosed difference between the “starting time” of the task and the time the threads are initialized. Since the “starting time” can be shifted left, it is not necessarily defined as always 0, and shifting the “starting time” left will reduce the thread initialization time.
Since the shifting of the starting time is based on PROBABLE_NUMBER_OF_MAX_THREADS, the thread initialization time is thus based on the current number of threads.
An acceptable “process execution time” is determined by possibly changing the number of threads based on possibly changing the maximum completion time (represented as a variable called “MAX_TIME”) and the “starting time”.),
providing the process execution time as input (
Panikkar discloses, “In step 710, resource monitor 624 obtains the CPU and memory consumption percentage data of the server (or other underlying physical infrastructure) of container service orchestration platform 606 that ran the microservice for the single record transaction, and provides the data to inspection engine 622. Resource monitor 624 also records the total round trip time (RTT) associated with the request/response for this single record transaction during inspection mode, e.g., UNIT_ROUND_TRIP_TIME,” ¶ 0067, and “If, in step 716, inspection engine 622 determines that the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS is greater than or equal to MAX_TIME, then task configurator 626 instructs scheduler/orchestrator 612 to iteratively add one more thread and start parallel processing from step 708, until UNIT_ROUND_TRIP_TIME is less than MAX_TIME,” ¶ 0070.),
and if the predicted number of records is sufficient to process the batch job, determining (
Panikkar discloses, “If, in step 716, inspection engine 622 determines that the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS is greater than or equal to MAX_TIME, then task configurator 626 instructs scheduler/orchestrator 612 to iteratively add one more thread and start parallel processing from step 708, until UNIT_ROUND_TRIP_TIME is less than MAX_TIME,” ¶ 0070.),
and saving, for each candidate thread count in a list of candidate thread counts and actual completion times, a pair comprising the candidate thread count and a corresponding actual completion time (
Panikkar discloses, “Note that the metrics collected and/or computed by inspection engine 622 (MIN_TIME, MAX_TIME, MAX_PROCESS UNITS, UNIT_ROUND_TRIP_TIME, PROBABLE_NUMBER_OF_MAX_THREADS, as well as and any other metrics or other data) are stored in inspection metrics store 628, in step 722, for use in instructing scheduler/orchestrator 612 on how many threads or other processing units to instantiate for executing the task during run mode,” ¶ 0073.),
wherein the list of candidate thread counts and actual completion times is used to select, based on a list of available threads, threads or combinations thereof having sufficient resources to execute the batch job with at least a selected candidate thread count and within the corresponding actual completion time (
Panikkar discloses, “Note that the metrics collected and/or computed by inspection engine 622 (MIN_TIME, MAX_TIME, MAX_PROCESS UNITS, UNIT_ROUND_TRIP_TIME, PROBABLE_NUMBER_OF_MAX_THREADS, as well as and any other metrics or other data) are stored in inspection metrics store 628, in step 722, for use in instructing scheduler/orchestrator 612 on how many threads or other processing units to instantiate for executing the task during run mode,” ¶ 0073.
The metrics collected include the number of threads and the multiplicative product of UNIT_ROUND_TRIP_TIME with MAX_PROCESS_UNITS for each number of threads, which is compared with MAX_TIME to see if it is under MAX_TIME);
.
Panikkar does not teach providing the process execution time as input to a machine learning (ML) model to obtain, as output of the ML model, a predicted number of records processable by the candidate thread count within the process execution time; determining, by using the ML model, an actual completion time for the candidate thread count; wherein the threads correspond to cloud virtual machines; or selecting, from among the cloud virtual machines or combinations thereof, an optimal virtual machine or optimal virtual machine combination according to resource efficiency or cost, the optimal virtual machine or the optimal virtual machine combination being capable of executing the batch job within the maximum completion time.
However, Ovsiankin teaches providing the process execution time as input to a machine learning (ML) model to obtain, as output of the ML model, a predicted number of records processable by the candidate thread count within the process execution time; and determining, by using the ML model, an actual completion time for the candidate thread count (
Ovsiankin discloses, “The predictive-optimization technique can generally include any machine-learning technique that can be used to predict an objective, such as the average execution time for a job, based on parameters associated with the job… Moreover, possible machine-learning techniques can include using: a neural network; a regression technique; a time-series model; a Bayesian classifier; simulated annealing; and a support-vector machine,” ¶ 0042.
After the combination of Panikkar with Ovsiankin, the model from Ovsiankin is used to obtain a predicted number of records and determine the actual completion time to process the expected number of records.).
Panikkar and Ovsiankin are both considered to be analogous to the claimed invention because they are in the same field of task processing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar to incorporate the teachings of Ovsiankin and provide providing the process execution time as input to a machine learning (ML) model to obtain, as output of the ML model, a predicted number of records processable by the candidate thread count within the process execution time; and determining, by using the ML model, an actual completion time for the candidate thread count. Doing so would help improve performance in predicting the number of records to be processed using the model, thus aiding in performance of the tasks being run (Ovsiankin discloses, “Next, the system uses the predictive-optimization technique to determine resource-allocation parameters for the job based on associated input parameters to optimize an execution performance of the job, wherein the predictive-optimization technique uses a model that was trained running previous MapReduce jobs on the multi-tenant system,” Abstract.).
Panikkar in view of Ovsiankin does not teach wherein the threads correspond to cloud virtual machines; or selecting, from among the cloud virtual machines or combinations thereof, an optimal virtual machine or optimal virtual machine combination according to resource efficiency or cost, the optimal virtual machine or the optimal virtual machine combination being capable of executing the batch job within the maximum completion time.
However, Johnson teaches wherein the threads correspond to cloud virtual machines (
Johnson discloses, “We therefore define it from the ground up in terms of a virtual machine ( V ) with a single thread of control (no parallelism, no time-slicing),” Page 48.
Panikkar already teaches cloud-based infrastructure, stating “Accordingly, the term ‘information processing system’ as used herein is intended to be broadly construed, so as to encompass, for example, processing platforms comprising cloud and/or non-cloud computing and storage systems, as well as other types of processing systems comprising various combinations of physical and/or virtual processing resources. An information processing system may therefore comprise, by way of example only, at least one data center or other type of cloud-based system that includes one or more clouds hosting tenants that access cloud resources,” ¶ 0017.
After the combination of Panikkar in view of Ovsiankin with Johnson, the list of threads and completion times from Panikkar in view of Ovsiankin is used to determine the optimal virtual machine to use, as there is now a one-to-one correspondence between a thread and a virtual machine as specified by Johnson. The virtual machine from Johnson is also now hosted on the cloud-based infrastructure as specified by Panikkar.).
Panikkar in view of Ovsiankin, and Johnson are both considered to be analogous to the claimed invention because they are in the same field of server-based computing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin to incorporate the teachings of Johnson and provide wherein the threads correspond to cloud virtual machines. Doing so would help provide increased flexibility for specifying the configuration of the selected virtual machine, and reduce overhead of managing multiple threads within a virtual machine.
Panikkar in view of Ovsiankin and Johnson does not teach selecting, from among the cloud virtual machines or combinations thereof, an optimal virtual machine or optimal virtual machine combination according to resource efficiency or cost, the optimal virtual machine or the optimal virtual machine combination being capable of executing the batch job within the maximum completion time.
However, Agarwal teaches selecting, from among the cloud virtual machines or combinations thereof, an optimal virtual machine or optimal virtual machine combination according to resource efficiency or cost, the optimal virtual machine or the optimal virtual machine combination being capable of executing the batch job within the maximum completion time (
Agarwal discloses, “In some embodiments, the candidate VM selection component 208 also includes a VM sorting component 211. In embodiments, the VM sorting component 211 scores one or more sets of candidate VMs based on a scoring function. In an example, the VM sorting component 211 uses a scoring function that measures a degree of imbalance between a stranded resource at the node and a bottleneck resource used by at least one VM at the node,” ¶ 0068, and “In embodiments, the VM sorting component 211 also selects the N highest scored VMs (with positive values) as a set of candidate VMs for migration,” ¶ 0073.
As a result of the sorting of the sets of candidate VMs, they now form a ranked list. After the combination of Panikkar in view of Ovsiankin and Johnson, with Agarwal, this ranking is based on resource efficiency or cost, wherein a higher score now indicates greater resource efficiency or lower cost.
Here, the highest scored virtual machines are considered to be optimal. After the combination of Panikkar in view of Ovsiankin and Johnson, with Agarwal, the ranking is based on resource efficiency or cost, wherein a higher score now indicates greater resource efficiency or lower cost. The optimal virtual machine selected is now selected based on greatest resource efficiency or lowest cost, so said optimal virtual machine is capable of executing the batch job within the maximum completion time.).
Panikkar in view of Ovsiankin and Johnson, and Agarwal are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin and Johnson to incorporate the teachings of Agarwal and provide selecting, from among the cloud virtual machines or combinations thereof, an optimal virtual machine or optimal virtual machine combination according to resource efficiency or cost, the optimal virtual machine or the optimal virtual machine combination being capable of executing the batch job within the maximum completion time. Doing so would help ensure that the most efficient virtual machines can be selected more easily.

Regarding Claim 17, Panikkar in view of Ovsiankin, Johnson, and Agarwal teaches the computer-implemented method of claim 11, further comprising:
determining that the predicted number of records is sufficient to process the batch job by determining that the predicted number of records is greater than or equal to an expected number of records calculated by dividing a total number of records by the thread count (
Panikkar discloses, “If, in step 716, inspection engine 622 determines that the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS is greater than or equal to MAX_TIME, then task configurator 626 instructs scheduler/orchestrator 612 to iteratively add one more thread and start parallel processing from step 708, until UNIT_ROUND_TRIP_TIME is less than MAX_TIME,” ¶ 0070, and “Note that the metrics collected and/or computed by inspection engine 622 (MIN_TIME, MAX_TIME, MAX_PROCESS_UNITS, UNIT_ROUND_TRIP_TIME, PROBABLE_NUMBER_OF_MAX_THREADS, as well as and any other metrics or other data) are stored in inspection metrics store 628, in step 722, for use in instructing scheduler/orchestrator 612 on how many threads or other processing units to instantiate for executing the task during run mode,” ¶ 0073.
Here MAX_PROCESS_UNITS can be divided by PROBABLE_NUMBER_OF_MAX_THREADS to obtain the maximum number of process units per thread.);
obtaining, as an output the ML model, a running time corresponding to the expected number of records (
Ovsiankin discloses, “This predictive-optimization technique can be used to select resource-allocation parameters (e.g., number of mappers and reducers) to minimize an objective for the job. For example, the objective can include: (1) a total running time for the job, wherein the job comprises a plurality of tasks that can execute in parallel,” ¶ 0043.);
and calculating the actual completion time by adding the thread initialization time to the running time output by the ML model (
Panikkar discloses, “If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072..).
Panikkar and Ovsiankin are both considered to be analogous to the claimed invention because they are in the same fields of computer architecture and machine learning. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar to incorporate the teachings of Ovsiankin and provide obtaining, as an output the ML model, a running time corresponding to the expected number of records. Doing so would help increase accuracy/convenience of the predicted completion times by using the model.

Regarding Claim 19, Panikkar in view of Ovsiankin, Johnson, and Agarwal teaches a computer program product tangibly embodied in one or more non-transitory machine-readable storage media including instructions configured to cause one or more data processors to perform the computer-implemented method of claim 11 (
Panikkar discloses, “Further illustrative embodiments are provided in the form of a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps,” ¶ 0005.).

Regarding Claim 20, Panikkar in view of Ovsiankin, Johnson, and Agarwal teaches a computer system comprising: one or more data processors; and a non-transitory computer-readable medium storing instructions that, when executed by the one or more data processors, cause the one or more data processors to perform the computer-implemented method of claim 11 (
Panikkar discloses, “Further illustrative embodiments are provided in the form of a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further illustrative embodiments comprise an apparatus with a processor and a memory configured to perform the above steps,” ¶ 0005.).

Claims 4-7 and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Panikkar (US 20230168940 A1) in view of Ovsiankin (US 20150277980 A1), Johnson (WO 2013142983 A1), and Agarwal (US 20250036448 A1), Zu (US 20210117220 A1), and Thomas (US 20190250937 A1).
Regarding Claim 4, Panikkar in view of Ovsiankin, Johnson, and Agarwal teaches the computer-implemented method of claim 1. Panikkar in view of Ovsiankin, Johnson, and Agarwal does not teach further comprising: prior to step (f), selecting, from a list of available cloud virtual machines, a plurality of most efficient single virtual machines to include a most efficient single virtual machine available for use in each of a plurality of configurations, each of the plurality of configurations corresponding to a number of cores per single virtual machine; and arranging the plurality of most efficient single virtual machines in a list of the plurality of most efficient single virtual machines.
However, Zu teaches further comprising:
prior to step (f), selecting, from a list of available cloud virtual machines, a plurality of most efficient single virtual machines to include a most efficient single virtual machine available for use in each of a plurality of configurations, each of the plurality of configurations corresponding to a number of cores per single virtual machine; (
Zu discloses, “If a computing node is found to satisfy that Σ.sub.l.sup.n mem.sub.t is greater than memory required by the container/virtual machine and Σ.sub.l.sup.n cpu.sub.t is greater than the number of CPUs required by the container/virtual machine, the method goes to S3, otherwise it is considered that all computing nodes do not have enough available resources,” ¶ 0118.
Here, Zu selects the most efficient computing node that satisfies the number of CPUs required. After the combination of Panikkar in view of Ovsiankin, Johnson, and Agarwal, with Zu, the most efficient computing node is now the virtual machine that satisfies the number of CPUs required, and the selection process is repeated for each of the numbers of threads in Panikkar’s iteration.).
Panikkar in view of Ovsiankin, Johnson, and Agarwal, and Zu are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin, Johnson, and Agarwal to incorporate the teachings of Zu and provide further comprising: selecting, from the list of cloud virtual machines, a plurality of most efficient single virtual machines to include a most efficient single virtual machine available for use in each of a plurality of configurations, each of the plurality of configurations corresponding to a number of cores per single virtual machine. Doing so would help improve the scheduling of resources (Zu discloses, “the unified resource scheduling coordinator further includes: a traversing and determination unit configured to traverse every computing node and statistically determine available resources of NUMA nodes in a dedicated mode on the computing node when no computing node that meets the requirements is found using the nearest window query method,” ¶ 0022.)
Panikkar in view of Ovsiankin, Johnson, Agarwal, and Zu does not teach arranging the plurality of most efficient single virtual machines in a list of the plurality of most efficient single virtual machines.
However, Thomas teaches arranging the plurality of most efficient single virtual machines in a list of the plurality of most efficient single virtual machines (
Thomas discloses, “querying available security virtual machines within the virtualization environment from the guest virtual machine to obtain information about one or more other security virtual machines within the virtualization environment at the guest virtual machine, the information including one or more performance metrics, sorting the one or more other security virtual machines into a number of groups based on performance,” ¶ 0012.
After Panikkar in view of Ovsiankin, Johnson, Agarwal, and Zu is combined with Thomas, Panikkar in view of Ovsiankin, Johnson, Agarwal, and Zu’s virtual machines are sorted based on Zu’s efficiency as explained by Thomas.).
Panikkar in view of Ovsiankin, Johnson, Agarwal, and Zu, and Thomas, are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin, Johnson, Agarwal, and Zu to incorporate the teachings of Thomas and provide arranging the plurality of most efficient single virtual machines in a list of the plurality of most efficient single virtual machines. Doing so would help ensure that the most efficient/capable virtual machines can be selected. (Thomas discloses, “sorting the one or more other security virtual machines into a number of groups based on performance,” ¶ 0012.). Therefore, the capabilities of the virtual machines are matched to the tasks.

Regarding Claim 5, Panikkar in view of Ovsiankin, Johnson, Agarwal, Zu, and Thomas teaches the computer-implemented method of claim 4, wherein the one or more combinations in the list of threads and completion times comprises one combination, and step (f) further comprises: determining a virtual machine collection comprising a plurality of efficient virtual resources, each of the plurality of efficient virtual resources includes one from among a single virtual machine and a virtual machine combination that are determined from the list of the plurality of most efficient single virtual machines, wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time (
Agarwal discloses, “In some embodiments, the candidate VM selection component 208 also includes a VM sorting component 211. In embodiments, the VM sorting component 211 scores one or more sets of candidate VMs based on a scoring function. In an example, the VM sorting component 211 uses a scoring function that measures a degree of imbalance between a stranded resource at the node and a bottleneck resource used by at least one VM at the node,” ¶ 0068.
Zu already discloses, “If a computing node is found to satisfy that Σ.sub.l.sup.n mem.sub.t is greater than memory required by the container/virtual machine and Σ.sub.l.sup.n cpu.sub.t is greater than the number of CPUs required by the container/virtual machine, the method goes to S3,” ¶ 0118.
After the combination Panikkar in view of Ovsiankin, Johnson, and Agarwal, with Zu, each of the virtual machines that are selected from Agarwal must have a number of cores greater than or equal to the specified number of cores, as specified by Zu.);
and saving, in a list of efficient virtual resources, the plurality of efficient virtual resources in an order of decreasing efficiency, thereby obtaining the ranked list (
Agarwal discloses, “In embodiments, the VM sorting component 211 also sorts the VMs in descending order based on each VM's score,” ¶ 0072.
The sorting of the VMs results in a ranked list of VMs.),
and the selecting further comprises selecting the optimal virtual machine or the optimal virtual machine combination as a most efficient virtual resource from the list of efficient virtual resources (
Agarwal discloses, “In embodiments, the VM sorting component 211 also selects the N highest scored VMs (with positive values) as a set of candidate VMs for migration,” ¶ 0073.).
Panikkar in view of Ovsiankin and Johnson, and Agarwal are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin and Johnson to incorporate the teachings of Agarwal and provide wherein the one or more combinations in the list of threads and completion times comprises one combination, and step (f) further comprises: determining a virtual machine collection comprising a plurality of efficient virtual resources, each of the plurality of efficient virtual resources includes one from among a single virtual machine and a virtual machine combination that are determined from the list of the plurality of most efficient single virtual machines; and saving, in a list of efficient virtual resources, the plurality of efficient virtual resources in an order of decreasing efficiency, thereby obtaining the ranked list, and the selecting further comprises selecting the optimal virtual machine or the optimal virtual machine combination as a most efficient virtual resource from the list of efficient virtual resources. Doing so would help ensure that the most efficient virtual machines can be selected more easily.
Panikkar in view of Ovsiankin, Johnson, and Agarwal, and Zu are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin, Johnson, and Agarwal to incorporate the teachings of Zu and provide wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time. Doing so would help improve the scheduling of resources (Zu discloses, “the unified resource scheduling coordinator further includes: a traversing and determination unit configured to traverse every computing node and statistically determine available resources of NUMA nodes in a dedicated mode on the computing node when no computing node that meets the requirements is found using the nearest window query method,” ¶ 0022.).

Regarding Claim 6, Panikkar in view of Ovsiankin, Johnson, Agarwal, Zu, and Thomas the computer-implemented method of claim 5, wherein the selecting the optimal virtual machine or the optimal virtual machine combination as the most efficient virtual resource comprises determining one of the plurality of efficient virtual resources that has a lowest cost from the list of efficient virtual resources (
Agarwal discloses, “In an example, the VM sorting component 211 uses a scoring function that measures a degree of imbalance between a stranded resource at the node and a bottleneck resource used by at least one VM at the node. This measurement quantifies the contribution of individual VMs to causing the stranding of the stranded resource on the node,” ¶ 0068.
Here, each of the virtual machines has a cost measured regarding resource usage, which contributes to a stranding of a resource on the node. The “most efficient virtual machines” are the virtual machines that have the highest resource usage, and thus will have a lowest cost for running other tasks.).
Panikkar in view of Ovsiankin and Johnson, and Agarwal are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin and Johnson to incorporate the teachings of Agarwal and provide wherein the selecting the optimal virtual machine or the optimal virtual machine combination as the most efficient virtual resource comprises determining one of the plurality of efficient virtual resources that has a lowest cost from the list of efficient virtual resources. Doing so would help ensure that the most efficient virtual machines can be selected more easily.

Regarding Claim 7, Panikkar in view of Ovsiankin, Johnson, Agarwal, Zu, and Thomas teaches the computer-implemented method of claim 4, wherein:
the one or more combinations in the list of threads and completion times comprises a plurality of combinations (
Panikkar discloses, “If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072, and “Accordingly, by way of example of methodology 700 described above, when task manager 604 runs in production for the first time, it executes in inspection mode starting with a single thread and a single unit of process (e.g., single record transaction). Task manager 604 records information including the number of threads, data load (e.g., number of records), time taken, CPU consumption, and memory consumption. Then, task manager 604 increases the threads (parallel processes) and load systematically and records the various metrics. After a point of time, increasing the parallel threads will result in an increase in the time taken or start generating errors. Now, task manager 604 can find the optimal combination of parallel threads for a given load,” ¶ 0074.),
step (f) further comprises: for each of the plurality of combinations, iteratively performing (
Panikkar discloses, “If, in step 716, inspection engine 622 determines that the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS is greater than or equal to MAX_TIME, then task configurator 626 instructs scheduler/orchestrator 612 to iteratively add one more thread and start parallel processing from step 708, until UNIT_ROUND_TRIP_TIME is less than MAX_TIME,” ¶ 0070.).
Panikkar in view of Ovsiankin and Johnson does not teach determining a virtual machine collection comprising a plurality of efficient virtual resources, each of the plurality of efficient virtual resources includes one from among a single virtual machine and a virtual machine combination that are determined from the list of the plurality of most efficient single virtual machines, wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time, and saving, in a list of efficient virtual resources, the plurality of efficient virtual resources in an order of decreasing efficiency; and the selecting further comprises selecting, as the optimal virtual machine or the optimal virtual machine combination, a most efficient virtual resource based on a plurality of lists of efficient virtual resources obtained based on performing a plurality of iterations.
However, Agarwal teaches determining a virtual machine collection comprising a plurality of efficient virtual resources, each of the plurality of efficient virtual resources includes one from among a single virtual machine and a virtual machine combination that are determined from the list of the plurality of most efficient single virtual machines, wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time (
Agarwal discloses, “In some embodiments, the candidate VM selection component 208 also includes a VM sorting component 211. In embodiments, the VM sorting component 211 scores one or more sets of candidate VMs based on a scoring function. In an example, the VM sorting component 211 uses a scoring function that measures a degree of imbalance between a stranded resource at the node and a bottleneck resource used by at least one VM at the node,” ¶ 0068.
Zu already discloses, “If a computing node is found to satisfy that Σ.sub.l.sup.n mem.sub.t is greater than memory required by the container/virtual machine and Σ.sub.l.sup.n cpu.sub.t is greater than the number of CPUs required by the container/virtual machine, the method goes to S3,” ¶ 0118.
After the combination of Panikkar in view of Ovsiankin, Johnson and Agarwal, with Zu, each of the virtual machines that are selected from Agarwal must have a number of cores greater than or equal to the specified number of cores, as specified by Zu.),
and saving, in a list of efficient virtual resources, the plurality of efficient virtual resources in an order of decreasing efficiency (
Agarwal discloses, “In embodiments, the VM sorting component 211 also sorts the VMs in descending order based on each VM's score,” ¶ 0072.);
and the selecting further comprises selecting, as the optimal virtual machine or the optimal virtual machine combination, a most efficient virtual resource based on a plurality of lists of efficient virtual resources obtained based on performing a plurality of iterations (
Agarwal discloses, “In embodiments, the VM sorting component 211 also selects the N highest scored VMs (with positive values) as a set of candidate VMs for migration,” ¶ 0073.
After the combination of Panikkar in view of Ovsiankin and Johnson, with Agarwal, Agarwal’s selection of virtual machines is now done for each of Panikkar’s iterations through each number of threads.).
Panikkar in view of Ovsiankin and Johnson, and Agarwal are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin and Johnson to incorporate the teachings of Agarwal and provide determining a virtual machine collection comprising a plurality of efficient virtual resources, each of the plurality of efficient virtual resources includes one from among a single virtual machine and a virtual machine combination that are determined from the list of the plurality of most efficient single virtual machines, and saving, in a list of efficient virtual resources, the plurality of efficient virtual resources in an order of decreasing efficiency; and the selecting further comprises selecting, as the optimal virtual machine or the optimal virtual machine combination, a most efficient virtual resource based on a plurality of lists of efficient virtual resources obtained based on performing a plurality of iterations. Doing so would help ensure that the most efficient virtual machines can be selected more easily.
Panikkar in view of Ovsiankin, Johnson and Agarwal, and Zu are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin, Johnson and Agarwal to incorporate the teachings of Zu and provide wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time. Doing so would help improve the scheduling of resources (Zu discloses, “the unified resource scheduling coordinator further includes: a traversing and determination unit configured to traverse every computing node and statistically determine available resources of NUMA nodes in a dedicated mode on the computing node when no computing node that meets the requirements is found using the nearest window query method,” ¶ 0022.).

Regarding Claim 12, Panikkar in view of Ovsiankin, Johnson and Agarwal teaches the computer-implemented method of claim 11. Panikkar in view of Ovsiankin, Johnson and Agarwal does not teach wherein the selecting the optimal virtual machine or the optimal virtual machine combination further comprises: selecting, from the list of available cloud virtual machines, a plurality of most efficient single virtual machines to include a most efficient single virtual machine available for use in each of a plurality of configurations, each of the plurality of configurations corresponding to a number of cores per single virtual machine; and arranging the plurality of most efficient single virtual machines in a list of the plurality of most efficient single virtual machines.
However, Zu teaches wherein the selecting the optimal virtual machine or the optimal virtual machine combination further comprises:
selecting, from the list of available cloud virtual machines, a plurality of most efficient single virtual machines to include a most efficient single virtual machine available for use in each of a plurality of configurations, each of the plurality of configurations corresponding to a number of cores per single virtual machine (
Zu discloses, “If a computing node is found to satisfy that Σ.sub.l.sup.n mem.sub.t is greater than memory required by the container/virtual machine and Σ.sub.l.sup.n cpu.sub.t is greater than the number of CPUs required by the container/virtual machine, the method goes to S3, otherwise it is considered that all computing nodes do not have enough available resources,” ¶ 0118.
Here, Zu selects the most efficient computing node that satisfies the number of CPUs required. After the combination of Panikkar in view of Ovsiankin, Johnson and Agarwal, with Zu, the most efficient computing node is now the virtual machine that satisfies the number of CPUs required, and the selection process is repeated for each of the numbers of threads in Panikkar’s iteration.).
Panikkar in view of Ovsiankin, Johnson and Agarwal, and Zu are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin, Johnson and Agarwal to incorporate the teachings of Zu and provide wherein the selecting the optimal virtual machine or the optimal virtual machine combination further comprises: selecting, from the list of available cloud virtual machines, a plurality of most efficient single virtual machines to include a most efficient single virtual machine available for use in each of a plurality of configurations, each of the plurality of configurations corresponding to a number of cores per single virtual machine. Doing so would help improve the scheduling of resources (Zu discloses, “the unified resource scheduling coordinator further includes: a traversing and determination unit configured to traverse every computing node and statistically determine available resources of NUMA nodes in a dedicated mode on the computing node when no computing node that meets the requirements is found using the nearest window query method,” ¶ 0022.)
Panikkar in view of Ovsiankin, Johnson, Agarwal, and Zu does not teach arranging the plurality of most efficient single virtual machines in a list of the plurality of most efficient single virtual machines.
However, Thomas teaches arranging the plurality of most efficient single virtual machines in a list of the plurality of most efficient single virtual machines (
Thomas discloses, “querying available security virtual machines within the virtualization environment from the guest virtual machine to obtain information about one or more other security virtual machines within the virtualization environment at the guest virtual machine, the information including one or more performance metrics, sorting the one or more other security virtual machines into a number of groups based on performance,” ¶ 0012.
After Panikkar in view of Ovsiankin, Johnson, Agarwal, and Zu is combined with Thomas, the virtual machines are sorted based on Zu’s efficiency as explained by Thomas.).
Panikkar in view of Ovsiankin, Johnson, Agarwal, and Zu, and Thomas, are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin, Johnson, Agarwal, and Zu to incorporate the teachings of Thomas and provide arranging the plurality of most efficient single virtual machines in a list of the plurality of most efficient single virtual machines. Doing so would help ensure that the most efficient/capable virtual machines can be selected. (Thomas discloses, “sorting the one or more other security virtual machines into a number of groups based on performance,” ¶ 0012.). Therefore, the capabilities of the virtual machines are matched to the tasks.

Regarding Claim 13, Panikkar in view of Ovsiankin, Johnson, Agarwal, Zu, and Thomas teaches the computer-implemented method of claim 12, wherein the list of candidate thread counts and actual completion times comprises one pair, and the selecting the optimal virtual machine or the optimal virtual machine combination further comprises:
determining a virtual machine collection comprising a plurality of efficient virtual resources, each of the plurality of efficient virtual resources includes one from among a single virtual machine and a virtual machine combination that are determined from the list of the plurality of most efficient single virtual machines,
wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time (
Agarwal discloses, “In some embodiments, the candidate VM selection component 208 also includes a VM sorting component 211. In embodiments, the VM sorting component 211 scores one or more sets of candidate VMs based on a scoring function. In an example, the VM sorting component 211 uses a scoring function that measures a degree of imbalance between a stranded resource at the node and a bottleneck resource used by at least one VM at the node,” ¶ 0068.
Zu already discloses, “If a computing node is found to satisfy that Σ.sub.l.sup.n mem.sub.t is greater than memory required by the container/virtual machine and Σ.sub.l.sup.n cpu.sub.t is greater than the number of CPUs required by the container/virtual machine, the method goes to S3,” ¶ 0118.
After the combination of Panikkar in view of Ovsiankin, Johnson, and Agarwal, with Zu, each of the virtual machines that are selected from Agarwal must have a number of cores greater than or equal to the specified number of cores, as specified by Zu.);
saving, in a list of efficient virtual resources, the plurality of efficient virtual resources in an order of decreasing efficiency (
Agarwal discloses, “In embodiments, the VM sorting component 211 also sorts the VMs in descending order based on each VM's score,” ¶ 0072.);
and selecting the optimal virtual machine or the optimal virtual machine combination as a most efficient virtual resource from the list of efficient virtual resources (
Agarwal discloses, “In embodiments, the VM sorting component 211 also selects the N highest scored VMs (with positive values) as a set of candidate VMs for migration,” ¶ 0073.).
Panikkar in view of Ovsiankin and Johnson, and Agarwal are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin and Johnson to incorporate the teachings of Agarwal and provide wherein the list of candidate thread counts and actual completion times comprises one pair, and the selecting the optimal virtual machine or the optimal virtual machine combination further comprises: determining a virtual machine collection comprising a plurality of efficient virtual resources, each of the plurality of efficient virtual resources includes one from among a single virtual machine and a virtual machine combination that are determined from the list of the plurality of most efficient single virtual machines, wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time. Doing so would help ensure that the most efficient virtual machines can be selected more easily.
Panikkar in view of Ovsiankin, Johnson, and Agarwal, and Zu are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin, Johnson, and Agarwal to incorporate the teachings of Zu and provide wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time. Doing so would help improve the scheduling of resources (Zu discloses, “the unified resource scheduling coordinator further includes: a traversing and determination unit configured to traverse every computing node and statistically determine available resources of NUMA nodes in a dedicated mode on the computing node when no computing node that meets the requirements is found using the nearest window query method,” ¶ 0022.).

Regarding Claim 14, Panikkar in view of Ovsiankin, Johnson, Agarwal, Zu, and Thomas teaches the computer-implemented method of claim 13,
wherein the selecting the optimal virtual machine or the optimal virtual machine combination as the most efficient virtual resource comprises determining one of the plurality of efficient virtual resources that has a lowest cost from the list of efficient virtual resources (
Agarwal discloses, “In an example, the VM sorting component 211 uses a scoring function that measures a degree of imbalance between a stranded resource at the node and a bottleneck resource used by at least one VM at the node. This measurement quantifies the contribution of individual VMs to causing the stranding of the stranded resource on the node,” ¶ 0068.
Here, each of the virtual machines has a cost measured regarding resource usage, which contributes to a stranding of a resource on the node. The “most efficient virtual machines” are the virtual machines that have the highest resource usage, and thus will have a lowest cost for running other tasks.).
Panikkar in view of Ovsiankin and Johnson, and Agarwal are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin and Johnson to incorporate the teachings of Agarwal and provide wherein the selecting the optimal virtual machine or the optimal virtual machine combination as the most efficient virtual resource comprises determining one of the plurality of efficient virtual resources that has a lowest cost from the list of efficient virtual resources. Doing so would help ensure that the most efficient virtual machines can be selected more easily.

Regarding Claim 15, Panikkar in view of Ovsiankin, Johnson, Agarwal, Zu, and Thomas teaches the computer-implemented method of claim 12, wherein:
the list of candidate thread counts and actual completion times comprises a plurality of pairs (
Panikkar discloses, “If PROBABLE_NUMBER_OF_MAX_THREADS of the particular task takes more than MAX_TIME, then, in step 720, inspection engine 622 generates an error to the user/system for mitigation either by increasing MAX_TIME and shifting left the starting time or reducing the load (e.g., the number of records to be processed in a task),” ¶ 0072, and “Accordingly, by way of example of methodology 700 described above, when task manager 604 runs in production for the first time, it executes in inspection mode starting with a single thread and a single unit of process (e.g., single record transaction). Task manager 604 records information including the number of threads, data load (e.g., number of records), time taken, CPU consumption, and memory consumption. Then, task manager 604 increases the threads (parallel processes) and load systematically and records the various metrics. After a point of time, increasing the parallel threads will result in an increase in the time taken or start generating errors. Now, task manager 604 can find the optimal combination of parallel threads for a given load,” ¶ 0074.),
and the selecting the optimal virtual machine or the optimal virtual machine combination further comprises: for each of the plurality of pairs, iteratively performing (
Panikkar discloses, “If, in step 716, inspection engine 622 determines that the product of UNIT_ROUND_TRIP_TIME and MAX_PROCESS_UNITS is greater than or equal to MAX_TIME, then task configurator 626 instructs scheduler/orchestrator 612 to iteratively add one more thread and start parallel processing from step 708, until UNIT_ROUND_TRIP_TIME is less than MAX_TIME,” ¶ 0070.).
Panikkar in view of Ovsiankin and Johnson does not teach determining a virtual machine collection comprising a plurality of efficient virtual resources, each of the plurality of efficient virtual resources includes one from among a single virtual machine and a virtual machine combination that are determined from the list of the plurality of most efficient single virtual machines, wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time, and saving, in a list of efficient virtual resources, the plurality of efficient virtual resources in an order of decreasing efficiency; and selecting, as the optimal virtual machine or the optimal virtual machine combination, a most efficient virtual resource based on a plurality of lists of efficient virtual resources obtained based on performing a plurality of iterations.
However, Agarwal teaches determining a virtual machine collection comprising a plurality of efficient virtual resources, each of the plurality of efficient virtual resources includes one from among a single virtual machine and a virtual machine combination that are determined from the list of the plurality of most efficient single virtual machines,
wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time (
Agarwal discloses, “In some embodiments, the candidate VM selection component 208 also includes a VM sorting component 211. In embodiments, the VM sorting component 211 scores one or more sets of candidate VMs based on a scoring function. In an example, the VM sorting component 211 uses a scoring function that measures a degree of imbalance between a stranded resource at the node and a bottleneck resource used by at least one VM at the node,” ¶ 0068.
Zu already discloses, “If a computing node is found to satisfy that Σ.sub.l.sup.n mem.sub.t is greater than memory required by the container/virtual machine and Σ.sub.l.sup.n cpu.sub.t is greater than the number of CPUs required by the container/virtual machine, the method goes to S3,” ¶ 0118.
After the combination of Panikkar in view of Ovsiankin, Johnson, and Agarwal, with Zu, each of the virtual machines that are selected from Agarwal must have a number of cores greater than or equal to the specified number of cores, as specified by Zu.),
and saving, in a list of efficient virtual resources, the plurality of efficient virtual resources in an order of decreasing efficiency (
Agarwal discloses, “In embodiments, the VM sorting component 211 also sorts the VMs in descending order based on each VM's score,” ¶ 0072.);
and selecting, as the optimal virtual machine or the optimal virtual machine combination, a most efficient virtual resource based on a plurality of lists of efficient virtual resources obtained based on performing a plurality of iterations (
Agarwal discloses, “In embodiments, the VM sorting component 211 also selects the N highest scored VMs (with positive values) as a set of candidate VMs for migration,” ¶ 0073.
After the combination of Panikkar in view of Ovsiankin and Johnson, with Agarwal, Agarwal’s selection of virtual machines is now done for each of Panikkar’s iterations through each number of threads.).
Panikkar in view of Ovsiankin and Johnson, and Agarwal are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin and Johnson to incorporate the teachings of Agarwal and provide determining a virtual machine collection comprising a plurality of efficient virtual resources, each of the plurality of efficient virtual resources includes one from among a single virtual machine and a virtual machine combination that are determined from the list of the plurality of most efficient single virtual machines, wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time, and saving, in a list of efficient virtual resources, the plurality of efficient virtual resources in an order of decreasing efficiency; and selecting, as the optimal virtual machine or the optimal virtual machine combination, a most efficient virtual resource based on a plurality of lists of efficient virtual resources obtained based on performing a plurality of iterations. Doing so would help ensure that the most efficient virtual machines can be selected more easily.
Panikkar in view of Ovsiankin, Johnson, and Agarwal, and Zu are both considered to be analogous to the claimed invention because they are in the same field of computer scheduling. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin, Johnson, and Agarwal to incorporate the teachings of Zu and provide wherein each of the plurality of efficient virtual resources has a number of cores greater than or equal to a total number of cores to execute the batch job within the maximum completion time. Doing so would help improve the scheduling of resources (Zu discloses, “the unified resource scheduling coordinator further includes: a traversing and determination unit configured to traverse every computing node and statistically determine available resources of NUMA nodes in a dedicated mode on the computing node when no computing node that meets the requirements is found using the nearest window query method,” ¶ 0022.).

Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Panikkar (US 20230168940 A1) in view of Ovsiankin (US 20150277980 A1), Johnson (WO 2013142983 A1), and Agarwal (US 20250036448 A1), and Prasad (US 20200073639 A1).
Regarding Claim 8, Panikkar in view of Ovsiankin, Johnson and Agarwal teaches the computer-implemented method of claim 1. Panikkar in view of Ovsiankin, Johnson and Agarwal does not teach further comprising: generating a training dataset using training data related to a historical batch job of a certain type; and training an input model using the training dataset to generate the ML model for processing the batch job of the certain type, wherein the ML model comprises a regression model.
However, Prasad teaches further comprising: generating a training dataset using training data related to a historical batch job of a certain type (
Prasad discloses, “As further shown in FIG. 1A, and by reference number 120, process automation platform 110 may obtain process data. For example, process automation platform 110 may obtain process data from one or more server devices 115 storing historical process data relating to a set of processes previously completed (e.g., using a set of automated tools, by a set of developers, and/or the like),” ¶ 0017, and “In some implementations, process automation platform 110 may perform a data preprocessing procedure when generating the process analysis model. For example, process automation platform 110 may preprocess unstructured process data to remove non-ASCII characters, white spaces, confidential data, and/or the like. In this way, process automation platform 110 may organize thousands, millions, or billions of data entries for machine learning and model generation—a data set that cannot be processed objectively by a human actor,” ¶ 0025.
The claimed “historical batch job of a certain type” is mapped to the historical batch job consisting of a set of processes that have been previously completed, of which associated process data is available.
This is of a certain type because the batch job/set of processes is already complete, where the type is whether the job or process is complete or still running.);
and training an input model using the training dataset to generate the ML model for processing the batch job of the certain type, wherein the ML model comprises a regression model (
Prasad discloses, “As further shown in FIG. 1A, and by reference number 120, process automation platform 110 may obtain process data. For example, process automation platform 110 may obtain process data from one or more server devices 115 storing historical process data relating to a set of processes previously completed (e.g., using a set of automated tools, by a set of developers, and/or the like),” ¶ 0017, and “process automation platform 110 may train the process analysis model using, for example, an unsupervised training procedure and based on the training set of the data. In some implementations, process automation platform 110 may perform dimensionality reduction to reduce the data to a minimum feature set, thereby reducing processing to train the process analysis model, and may apply a classification technique, to the minimum feature set. In some implementations, process automation platform 110 may use a logistic regression classification technique to determine a categorical outcome,” ¶ 0028.).
Panikkar in view of Ovsiankin, Johnson and Agarwal, and Prasad are both considered to be analogous to the claimed invention because they are in the same field of machine learning. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin, Johnson and Agarwal to incorporate the teachings of Prasad and provide further comprising: generating a training dataset using training data related to a historical batch job of a certain type; and training an input model using the training dataset to generate the ML model for processing the batch job of the certain type, wherein the ML model comprises a regression model. Doing so would help allow faster processing of various batch jobs using the model (Prasad discloses, “Finally, automating the process for analyzing processes and selecting tools for automatic completion of the processes conserves computing resources (e.g., processor resources, memory resources, and/or the like) that would otherwise be wasted in attempting to manually and inefficiently complete processes that may be automatable, by ensuring that automated process completion procedures are implemented when available for a particular class of process,” ¶ 0015.).

Regarding Claim 18, Panikkar in view of Ovsiankin, Johnson, and Agarwal teaches the computer-implemented method of claim 11. Panikkar in view of Ovsiankin, Johnson, and Agarwal does not teach further comprising: generating a training dataset using training data related to a historical batch job of a certain type; and training an input model using the training dataset to generate the ML model for processing the batch job of the certain type, wherein the ML model comprises a regression model.
However, Prasad teaches further comprising: generating a training dataset using training data related to a historical batch job of a certain type (
Prasad discloses, “As further shown in FIG. 1A, and by reference number 120, process automation platform 110 may obtain process data. For example, process automation platform 110 may obtain process data from one or more server devices 115 storing historical process data relating to a set of processes previously completed (e.g., using a set of automated tools, by a set of developers, and/or the like),” ¶ 0017, and “In some implementations, process automation platform 110 may perform a data preprocessing procedure when generating the process analysis model. For example, process automation platform 110 may preprocess unstructured process data to remove non-ASCII characters, white spaces, confidential data, and/or the like. In this way, process automation platform 110 may organize thousands, millions, or billions of data entries for machine learning and model generation—a data set that cannot be processed objectively by a human actor,” ¶ 0025.
The claimed “historical batch job of a certain type” is mapped to the historical batch job consisting of a set of processes that have been previously completed, of which associated process data is available.
This is of a certain type because the batch job/set of processes is already complete, where the type is whether the job or process is complete or still running.);
and training an input model using the training dataset to generate the ML model for processing the batch job of the certain type, wherein the ML model comprises a regression model (
Prasad discloses, “As further shown in FIG. 1A, and by reference number 120, process automation platform 110 may obtain process data. For example, process automation platform 110 may obtain process data from one or more server devices 115 storing historical process data relating to a set of processes previously completed (e.g., using a set of automated tools, by a set of developers, and/or the like),” ¶ 0017, and “process automation platform 110 may train the process analysis model using, for example, an unsupervised training procedure and based on the training set of the data. In some implementations, process automation platform 110 may perform dimensionality reduction to reduce the data to a minimum feature set, thereby reducing processing to train the process analysis model, and may apply a classification technique, to the minimum feature set. In some implementations, process automation platform 110 may use a logistic regression classification technique to determine a categorical outcome,” ¶ 0028.).
Panikkar in view of Ovsiankin, Johnson, and Agarwal, and Prasad are both considered to be analogous to the claimed invention because they are in the same field of machine learning. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Panikkar in view of Ovsiankin, Johnson, and Agarwal to incorporate the teachings of Prasad and provide further comprising: generating a training dataset using training data related to a historical batch job of a certain type; and training an input model using the training dataset to generate the ML model for processing the batch job of the certain type, wherein the ML model comprises a regression model. Doing so would help allow faster processing of various batch jobs using the model (Prasad discloses, “Finally, automating the process for analyzing processes and selecting tools for automatic completion of the processes conserves computing resources (e.g., processor resources, memory resources, and/or the like) that would otherwise be wasted in attempting to manually and inefficiently complete processes that may be automatable, by ensuring that automated process completion procedures are implemented when available for a particular class of process,” ¶ 0015.).

Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sreedharan et al. (US 20160110217 A1): Optimizing Execution of Processes
Burgin et al. (US 10713072 B1): Computing Resource Provisioning
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW SUN whose telephone number is [phone]. The examiner can normally be reached Monday-Friday 8:00-5:00.
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, Aimee Li can be reached at [phone]. 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.

/ANDREW NMN SUN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195

Prosecution Timeline

• Jul 14, 2023: Application Filed
• Dec 06, 2023: Response after Non-Final Action
• Jan 07, 2026: Non-Final Rejection mailed — §103
• Feb 18, 2026: Applicant Interview (Telephonic)
• Feb 25, 2026: Examiner Interview Summary
• Mar 30, 2026: Response Filed
• Jun 17, 2026: Final Rejection mailed — §103 (current)