DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The Office Action is in response to claims filed 04/24/2026.
Claims 1-4, 7-10, 14-16, and 20 are pending.
Claim Objections
Claim 4 is objected to because claim 4 recites a redundant limitation. Claim 4 recites that the “preset time threshold is based on a workload resource usage limit.” Claim 1, from which claim 4 depends on, recites that the preset time threshold is “due to a central processing unit (CPU) limit.” The limitation in claim 1 is narrower than the limitation in claim 4, so the limitation in claim 4 is redundant. Appropriate correction is required.
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.
Claim(s) 1-4, 8-10, and 15-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dube et al. Pat. No. US 20160085587 A1 (hereafter Dube) in view of Dillenberger et al. Pat. No. US 20150248452 A1 and further in view of Di Balsamo et al. Pat. No. US 20150277987 A1 (hereafter Di Balsamo) and Antani et al. Pat. No. US 20120284721 A1 (hereafter Antani).
With regard to claim 1, Dube teaches a method comprising: grouping, by one or more processors, a plurality of batch jobs based on workload resource requests and dependencies of each batch job resulting in a plurality of groups, wherein a first group of batch jobs share a first table and a second group of batch jobs share a second table (¶ [0050] states “Workload scheduling program 150 is stored in persistent storage 708 for execution by one or more of the respective computer processors 704 via one or more memories of memory 706”. ¶ [0021] states “A request for execution of a computing job received in step 205 includes at least a list of tasks to be executed as part of the computing job, as well as any dependencies required for execution of those tasks … Additionally, a dependency for a task can also include a data dependency which prevents the execution of a task unless a specific portion of data is available”. ¶ [0021] also states “In the depicted embodiment, task 301 has no prerequisite tasks, and has a dependency of data set 311 in order to be executed.” ¶ [0023] states “In order to determine if a task can be executed by a data processing element, workload scheduling program 150 determines if the type of computation required for the task can be performed by a given data processing element”. ¶ [0023] also states “data set 311 is present on SSD 411 and HDD 412.” ¶ [0045] states “FIG. 6A depicts a first feasible execution mapping for executing computing job 120 on heterogeneous computing device 110, generally designated 600, in accordance with an embodiment of the present invention. Tasks listed inside of data processing elements represent tasks performed by those data processing elements, while data sets listed inside data storage elements represent data sets provided to data processing elements by those data storage elements”. Examiner’s Note: the workload scheduling manager is executed on a processor. Tasks can depend on another task or a specific data source. Additionally, tasks can depend on a specific computing resource is available. FIG. 4 shows the types of computing resources and data source available. FIG. 5 shows the tasks (the non-underlined numbers) grouped to each computing resource. Data set 311 is a specific portion of data);
scheduling, by the one or more processors, the plurality of batch jobs based on the plurality of groups (¶ [0024] states “Using the information represented in the task and data graph, workload scheduling program 150 assigns the task, or set of tasks, which must be executed first to one or more data processing elements identified as capable of executing that task in the resource graph”. ¶ [0037] states “Workload scheduling program 150 selects the mapping which receives the highest total value for execution on heterogeneous computing device 110”. Examiner’s Note: the workload scheduling program first creates potential schedules called mappings. Then the workload scheduling program selects the best mapping and schedules the task);
Dube does not explicitly teach groups of batch jobs sharing different tables.
However, in an analogous art, Dillenberger teaches a method comprising: grouping, by one or more processors, a plurality of batch jobs based on workload resource requests and dependencies of each batch job resulting in a plurality of groups, wherein a first group of batch jobs share a first table and a second group of batch jobs share a second table (¶ [0037] states “it can be detected that a conflict exists between OLTP Workload and Batch.sub.--1 workload but not between OLTP Workload and Batch.sub.--2 workload or between Batch.sub.--1 workload and Batch.sub.--3 workload.” ¶ [0027] states “identify data access conflicts (e.g., at a desired granularity).” ¶ [0047] states “the selected granularity comprises one of: (a) database table; (b) database page; (c) database record; (d) a database column; (e) a database; (f) a data set.” Examiner’s Note: OLTP workload and batch 2 do not have a data access conflict. Batch 1 and batch 3 also do not have a data access conflict. The data access conflict is based on a granularity level. Database tables are example granularity. Since OLTP and batch 2 do not have a conflict, they are accessing different tables).
reducing, by the one or more processors, a CPU quota of the first group of batch jobs based on the CPU limit of the one or more scheduled transaction workloads and based on the one or more scheduled transaction workloads not using the first table (¶ [0037] states “it can be detected that a conflict exists between OLTP Workload and Batch.sub.--1 workload but not between OLTP Workload and Batch.sub.--2 workload or between Batch.sub.--1 workload and Batch.sub.--3 workload. The OLTP Workload and Batch.sub.--2 workload may then be scheduled to run concurrently and after that, Batch.sub.--1 workload and Batch.sub.--3 workload may be scheduled to run concurrently.” ¶ [0027] states “identify data access conflicts (e.g., at a desired granularity).” ¶ [0047] states “the selected granularity comprises one of: (a) database table; (b) database page; (c) database record; (d) a database column; (e) a database; (f) a data set.” Examiner’s Note: based on the OLTP workload and batch workload accessing different database tables (a type of granularity), the OLTP workload and batch are scheduled to run concurrently)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the OLTP and batch workloads not accessing the same database table of Dillenberger with the job grouping of Dube. Dube teaches that tasks may depend on a data set. Data sets are example granularity as shown in Dillenberger ¶ [0047]. Since database tables are also a level of granularity, it would be obvious that tasks can depend on database table access. As a result, tasks/jobs are grouped based on database table access. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of optimize the scheduling of OLTP and batch workloads to increase resource utilization and completing both types of workloads with larger execution windows (¶ [0031] states “the optimized fine grain scheduling that is based on the simulation can be output and can be used to impact the scheduling of workloads in real-time and/or in the future … In one example, scheduling and/or system level settings may relate to provisioning more resources when contention is no longer an issue; or provisioning more threads for certain work such as I/O processing.” ¶ [0003] states “a larger amount of Batch data may require one or more Batch time windows to be widened. In another example, business growth from regional to nationwide or from nationwide to international of a banking institution widens the OLTP time window for business reasons and consequently shrinks the batch time window”).
Dube and Dillenberger do not explicitly teach monitoring, identifying, and reducing steps.
However, in an analogous art, Di Balsamo teaches monitoring, by the one or more processors, workload resource usage of system for running the plurality of batch jobs and a plurality of transaction workloads (¶ [0069] states “The resource manager 406 may monitor the resource pool and determine a resource pool parameter … For example, the resource pool parameter may include a CPU utilization level, the number of resources in the resource pool, or the ratio the number of jobs in the workload plan to the number of resources in the resource pool.” ¶ [0062] states “Jobs may include at least two types of workloads including batch jobs and transactional jobs. Batch jobs may be scheduled and stored in the workload plan 403 at time of creation of the workload plan 403 … Transactional jobs, however, may process data in real time and may not be known of prior to creation of the workload plan 403”. Examiner’s Note: the resources that resource manager monitors are for the execution of the jobs. Jobs can either be batch jobs or transaction workloads);
identifying, by the one or more processors, one or more scheduled transaction workloads will not be able to be completed in under a preset time threshold due to a central processing unit (CPU) limit (¶ [0073] states “Resource allocation 514 may also include determining whether the job forecast exceeds the job deadline 516.” ¶ [0043] states “The method may also include modifying the resource pool to bring a resource pool parameter within a resource range in response to determining that the job forecast exceeds a job deadline.” ¶ [0068] states “In an embodiment the resource range may have an upper resource limit set at eighty percent (80%) CPU utilization so that when the resource pool parameter is represented by a CPU utilization level, a greater than 80% CPU utilization violates the SLA policy. However the lower resource limit may be set at fifty percent (50%) CPU utilization so that when the resource pool parameter is represented by a CPU utilization level, a less than 50% CPU utilization will violate the SLA policy.” Examiner’s Note: the upper and lower resource limits are based on CPU utilization. Modifying a resource pool parameter to be in range of resource limits in response to job that will miss a deadline is identifying a workload will not be completed under a preset time due to CPU limit);
reducing, by the one or more processors, a CPU quota of the first group of batch jobs based on the CPU limit of the one or more scheduled transaction workloads and based on the one or more scheduled transaction workloads not using the first table (¶ [0077] states “In an embodiment the resource range 602 may have an upper resource limit 606 set at eighty percent (80%) CPU utilization so that when the resource pool parameter 608 is represented by a CPU utilization level, a greater than 80% CPU utilization violates the SLA policy. However the lower resource limit 604 may be set at fifty percent (50%) CPU utilization so that when the resource pool parameter 608 is represented by a CPU utilization level, a less than 50% CPU utilization will violate the SLA policy.” ¶ [0078] states “If the resource pool parameter 608 is outside the resource range 602, then the resource pool may be modified to bring the resource pool parameter 608 within the resource range 602.” Examiner’s Note: an expansion or reduction of a resource pool is done to bring a resource parameter within an upper and lower resource range, so it is based on the CPU limit. The resource pool parameter represents a CPU utilization level. The resource pool parameter is the CPU quota).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the monitoring of a resource pool parameter, the identification of a job that exceeds a deadline based on a CPU limit, and the resource modification based on upper and lower thresholds of Di Balsamo with the grouping of tasks of Dube and the data access patterns of Dillenberger. A person having ordinary skill in the art would have motivated to make this combination to “improve responses to changing components, changing workload, and changing environmental conditions, while minimizing the operating costs and reducing violations of the SLAs” (Di Balsamo ¶ [0042]).
Dube, Dillenberger, and Di Balsamo do not explicitly reducing a CPU quota of a group of batch jobs and providing the reduced CPU quota to a transaction workload.
However, in an analogous art, Antani teaches identifying, by the one or more processors, one or more scheduled transaction workloads will not be able to be completed in under a preset time threshold due to a central processing unit (CPU) limit (¶ [0004] states “there are Long Running Transactions ("LRTs") and OnLine Transactions (OLTs)”. ¶ [0040] states “The WLM 102 detects that the SLA for OLT 120 is not being met” and “the WLM 102 determines whether the OLT 120 requires access to one or more transactional and/or system resources 116 being used by the LRT 110. For example, the determination can be made based on the number of CPU cycles used by the OLT 120. If the WLM 102 finds that there is a low CPU usage by OLT 120, then it concludes that no OLT 120 work is being done.” ¶ [0048] states “The SLA metrics can include, but are not limited to, an MTBF metric, an MTR metric, a data rate metric, a throughput metric, a jitter metric, a transactional priority metric, a response time metric, and a transactional deadline metric.” Examiner’s Note: the LRTs and OLTs of Antani are analogous to the batch jobs and transactional jobs of Di Balsamo respectively. See ¶ [0004] for more detail. The OLT is not meeting an SLA. The SLA is based on a response time metric and/or a transactional deadline metric. Metric. It is understood that to have a “low CPU usage,” a limit is required, such as the number of CPU cycles),
reducing, by the one or more processors, a CPU quota of the first group of batch jobs based on the CPU limit of the one or more scheduled transaction workloads and based on the one or more scheduled transaction workloads not using the first table (¶ [0056] states “Step 226 involves identifying the transaction(s) that is(are) using resources needed by the OLT. More particularly, the CPM slows down the LRT(s) identified/selected in step 226 by adjusting how many records are to be processed in each sub-transaction of the LRT(s) and/or increases/decreases the time period between commit operations of the LRT(s). The number of records is adjusted by changing the value of parameter "X" of the above-described ALGORITHM 2. Similarly, the time period between commit operations is adjusted by changing the values of the parameter "X" and/or "Y" of the above-described ALGORITHM 2”. ¶ [0032] states “The value of "Y" may be decreased for purposes of yielding system resource (e.g., a CPU) to other transactions.” ¶ [0036] states “system resources (e.g., CPU and database).” ¶ [0040] states “the WLM 102 determines whether the OLT 120 requires access to one or more transactional and/or system resources 116 being used by the LRT 110. For example, the determination can be made based on the number of CPU cycles used by the OLT 120. If the WLM 102 finds that there is a low CPU usage by OLT 120, then it concludes that no OLT 120 work is being done by TPS 100.” Examiner’s Note: Antani teaches that by changing the resource values of “X” and “Y”, the OLT can acquire the resources it needs. In other words, because of the resources needed by the OLT, or transactional workload, the resources of the LRT, or batch job, are reduced. See ¶ [0030] – [0031] for a full description of “ALGORITHM 2”. ¶ [0036] and [0040] shows that these resources are system resources such as CPU. Therefore, applying “Algorithm 2” leads to a change in CPU quota. Additionally, the reduction is based on the CPU because ¶ [0040] shows that a low CPU usage causes a determination to be made)
providing, by the one or more processors, the reduced CPU quota to the one or more scheduled transaction workloads, wherein the one or more scheduled transaction workloads are completed using the provided CPU quota (¶ [0040] states “Consequently, WLM 102 determines that OLT 120 requires access to one or more transactional and/or system resources 116 being used by LRT 110.” ¶ [0036] states “system resources (e.g., CPU and database).” ¶ [0042] states “Once the CPM 104 identifies the transactions (e.g., LRTs) that are using resources needed by the OLT 120, it performs actions to speed up or slow down the processing related to the identified LRTs. The throttling of each LRT is achieved by selecting values for parameters "X" and "Y" of ALGORITHM 2, and setting parameters "X" and "Y" equal to the respective selected values.” ¶ [0057] states “If the SLA(s) is(are) being met or will be met [230:YES], then step 234 is performed.” Examiner’s Note: due to the LRT’s record processing speed being reduced, the OLT now has more resources, such as CPU quota. Once the SLA for the OLT is met, the OLT executes and completes).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the transfer of resources between LRT and OLT of Antani with the grouping of Dube, the data access patterns based on database table access of Dillenberger, and the resource pool and job deadline of Di Balsamo. As a result, Dube and Dillenberger teach that tasks are grouped based on the database tables they access. Dillenberger, Di Balsamo, and Antani teach that there are transactional workloads and batch job workloads. It can be then identified that a workload will miss a deadline due to CPU limits. Antani teaches the idea of reducing resources, wherein the resource is a system resource such as CPU), of an LRT and providing the resource to the OLT. The reduction of resources is based on a limit described by Di Balsamo’s SLA and upper and lower CPU utilization limits (¶ [0039], [0068], [0077]). The reduction of CPU quota is also based on the transaction workload not using the same table as the first group of batch jobs. Dillenberger teaches that batch jobs can be scheduled based on database table access so that different workloads can be scheduled concurrently and have no conflict. This is done to support scheduling OLTP and batch workloads together because “online transaction processing (sometimes referred to herein as "OLTP") work requires prompt response time” (Dillenberger ¶ [0001]). OLTP workloads have a deadline. Di Balsamo ¶ [0072] and Antani ¶ [0031] teach that adjusting resource allocation to meet a deadline. In other words, the idea Dillenberger teaches the idea of scheduling OLTP and batch workloads based on which database tables are accessed so that OLTP workloads can be completed on time. The combination of Dillenberger with Dube, Di Balsamo, and Antani results in a transfer of resources based on database table accesses so that transaction workloads meet an SLA and complete.
According to Antani ¶ [0019], “The present invention generally concerns systems and methods for autonomically controlling checkpoint intervals at a fine-grained level for LRTs. The term "autonomic", as used herein, refers to the ability to function independently without outside influence.” ¶ [0022] states “The LRTs and checkpoint mechanisms collectively facilitates efficient data processing.” Additionally, the process described in Antani ¶ [0052] – [0057] are for the purpose of reducing SLA violations. Therefore, a person having ordinary skill in the art would have been motivated to make this combination for the purpose of automating the adjustment of LRTs to reduce SLA violations and complete data processing in an efficient manner.
With regard to claim 2, Dube, Dillenberger, Di Balsamo, and Antani teach the method of claim 1. To reestablish the teaching, Di Balsamo teaches batch jobs (¶ [0062] states “Jobs may include at least two types of workloads including batch jobs and transactional jobs”). Dube additionally teaches wherein scheduling the plurality of batch jobs based on the grouping further comprises: scheduling, by the one or more processors, batch jobs of the plurality of batch jobs from different groups of the plurality of groups at a same time which lowers competition between resources (¶ [0040] states “Having no prerequisite connection between tasks 302 and 303 indicates that both tasks can execute simultaneously once task 301 completes execution”. ¶ [0041] states “As task 302 has no dashed line connections to any data sets, task 302 has no data dependencies and does not require any data sets to be available in order for it to execute. Task 303 has a data dependency of both data set 311 and 312”. Examiner’s Note: tasks can be substituted by batch jobs. ¶ [0040] and [0041] are referring to FIG. 3. Task 302 and 303 belong to different groups because although they both depend on task 301, task 303 also depends on data set 311 and 312. Once dependency task 301 is completed and task 303 has access to data sets 311 and 312, task 302 and 303 can be executed simultaneously. In other words, they can be scheduled for the same time slot).
With regard to claim 3, Dube, Dillenberger, Di Balsamo, and Antani teach the method of claim 1. Di Balsamo additionally teaches wherein the workload resource usage includes database table usage, CPU usage, and memory usage (¶ [0068] states “In an embodiment the resource range may have an upper resource limit set at eighty percent (80%) CPU utilization so that when the resource pool parameter is represented by a CPU utilization level, a greater than 80% CPU utilization violates the SLA policy” and “Other computing parameters may be used including, but not limited to, the quantity of free memory”. ¶ [0069] states “The resource manager 406 may monitor the resource pool and determine a resource pool parameter. The resource pool parameter may be a representation of computing resources in the resource pool”. Examiner’s Note: one of ordinary skill in the art would recognize that the quantity of free memory and used memory are interchangeable).
Antani also teaches wherein the workload resource usage includes database table usage, CPU usage, and memory usage (¶ [0008] states “WorkLoad Managers (WLMs) are typically found in TPSs”. ¶ [0048] states “The WLM continuously monitors transaction processing to determine when a transaction processing job is at risk of completion”. ¶ [0053] states “the LRT obtains an exclusive lock on transactional resources (e.g., a row in a table of a database 116 of FIG. 1)”. Examiner’s Note: the WLM monitors transaction processing which would include workload resource usage. ¶ [0053] states a database row is an example of a transactional resource. It would be obvious to one of ordinary skill the art that the lock could control the row or the table).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine database table usage of Antani with the workload resource usage including CPU and memory usage of Di Balsamo. A person having ordinary skill in the art would have motivated to make this combination for the purpose of “balancing how many records get locked during a transaction and for how long the records are locked. The balancing is done in the context of other transactional work in the TPS, the priorities of the transactional work and deadlines of the transactional work” (Antani ¶ [0028]). Balancing transactional resources with priorities of transactional work requires the monitoring of database tables along with the other resources. Additionally, the balancing of priorities aids in detecting if an SLA is being met and adjusting resource allocation (Antani ¶ [0008]) which has clear benefits.
With regard to claim 4, Dube, Dillenberger, Di Balsamo, and Antani teach the method of claim 1. Di Balsamo also teaches wherein identifying the one or more scheduled transaction workloads that will not be able to be completed in under the preset time threshold is based on a workload resource usage limit (¶ [0073] states “Resource allocation 514 may also include determining whether the job forecast exceeds the job deadline 516.” ¶ [0043] states “The method may also include modifying the resource pool to bring a resource pool parameter within a resource range in response to determining that the job forecast exceeds a job deadline.” ¶ [0068] states “In an embodiment the resource range may have an upper resource limit set at eighty percent (80%) CPU utilization so that when the resource pool parameter is represented by a CPU utilization level, a greater than 80% CPU utilization violates the SLA policy. However the lower resource limit may be set at fifty percent (50%) CPU utilization so that when the resource pool parameter is represented by a CPU utilization level, a less than 50% CPU utilization will violate the SLA policy.” Examiner’s Note: the upper and lower resource limits are based on CPU utilization. Modifying a resource pool parameter to be in range of resource limits in response to job that will miss a deadline is identifying a workload will not be completed under a preset time due to CPU limit. The CPU utilization SLA limits are an example of a workload resource usage limit).
Antani additionally teaches wherein identifying the one or more scheduled transaction workloads that will not be able to be completed in under the preset time threshold is based on a workload resource usage limit (¶ [0040] states “The WLM 102 detects that the SLA for OLT 120 is not being met” and “the WLM 102 determines whether the OLT 120 requires access to one or more transactional and/or system resources 116 being used by the LRT 110. For example, the determination can be made based on the number of CPU cycles used by the OLT 120. If the WLM 102 finds that there is a low CPU usage by OLT 120, then it concludes that no OLT 120 work is being done.” ¶ [0048] states “The SLA metrics can include, but are not limited to, an MTBF metric, an MTR metric, a data rate metric, a throughput metric, a jitter metric, a transactional priority metric, a response time metric, and a transactional deadline metric.” Examiner’s Note: the OLT is not meeting an SLA. The SLA is based on a response time metric and/or a transactional deadline metric. Metric. It is understood that to have a “low CPU usage,” a limit is required, such as the number of CPU cycles. A CPU cycle limit is a workload resource usage limit)
With regard to claim 8, Dube teaches a computer program product comprising: one or more computer readable storage media and program instructions collectively stored on the one or more computer readable storage media, to perform operations comprising (¶ [0056] states “The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention”):
grouping, by one or more processors, a plurality of batch jobs based on workload resource requests and dependencies of each batch job resulting in a plurality of groups, wherein a first group of batch jobs share a first table and a second group of batch jobs share a second table (¶ [0050] states “Workload scheduling program 150 is stored in persistent storage 708 for execution by one or more of the respective computer processors 704 via one or more memories of memory 706”. ¶ [0021] states “A request for execution of a computing job received in step 205 includes at least a list of tasks to be executed as part of the computing job, as well as any dependencies required for execution of those tasks … Additionally, a dependency for a task can also include a data dependency which prevents the execution of a task unless a specific portion of data is available”. ¶ [0021] also states “In the depicted embodiment, task 301 has no prerequisite tasks, and has a dependency of data set 311 in order to be executed.” ¶ [0023] states “In order to determine if a task can be executed by a data processing element, workload scheduling program 150 determines if the type of computation required for the task can be performed by a given data processing element”. ¶ [0023] also states “data set 311 is present on SSD 411 and HDD 412.” ¶ [0045] states “FIG. 6A depicts a first feasible execution mapping for executing computing job 120 on heterogeneous computing device 110, generally designated 600, in accordance with an embodiment of the present invention. Tasks listed inside of data processing elements represent tasks performed by those data processing elements, while data sets listed inside data storage elements represent data sets provided to data processing elements by those data storage elements”. Examiner’s Note: the workload scheduling manager is executed on a processor. Tasks can depend on another task or a specific data source. Additionally, tasks can depend on a specific computing resource is available. FIG. 4 shows the types of computing resources and data source available. FIG. 5 shows the tasks (the non-underlined numbers) grouped to each computing resource. Data set 311 is a specific portion of data);
scheduling, by the one or more processors, the plurality of batch jobs based on the plurality of groups (¶ [0024] states “Using the information represented in the task and data graph, workload scheduling program 150 assigns the task, or set of tasks, which must be executed first to one or more data processing elements identified as capable of executing that task in the resource graph”. ¶ [0037] states “Workload scheduling program 150 selects the mapping which receives the highest total value for execution on heterogeneous computing device 110”. Examiner’s Note: the workload scheduling program first creates potential schedules called mappings. Then the workload scheduling program selects the best mapping and schedules the task);
Dube does not explicitly teach groups of batch jobs sharing different tables.
However, in an analogous art, Dillenberger teaches a method comprising: grouping, by one or more processors, a plurality of batch jobs based on workload resource requests and dependencies of each batch job resulting in a plurality of groups, wherein a first group of batch jobs share a first table and a second group of batch jobs share a second table (¶ [0037] states “it can be detected that a conflict exists between OLTP Workload and Batch.sub.--1 workload but not between OLTP Workload and Batch.sub.--2 workload or between Batch.sub.--1 workload and Batch.sub.--3 workload.” ¶ [0027] states “identify data access conflicts (e.g., at a desired granularity).” ¶ [0047] states “the selected granularity comprises one of: (a) database table; (b) database page; (c) database record; (d) a database column; (e) a database; (f) a data set.” Examiner’s Note: OLTP workload and batch 2 do not have a data access conflict. Batch 1 and batch 3 also do not have a data access conflict. The data access conflict is based on a granularity level. Database tables are example granularity. Since OLTP and batch 2 do not have a conflict, they are accessing different tables).
reducing, by the one or more processors, a CPU quota of the first group of batch jobs based on the CPU limit of the one or more scheduled transaction workloads and based on the one or more scheduled transaction workloads not using the first table (¶ [0037] states “it can be detected that a conflict exists between OLTP Workload and Batch.sub.--1 workload but not between OLTP Workload and Batch.sub.--2 workload or between Batch.sub.--1 workload and Batch.sub.--3 workload. The OLTP Workload and Batch.sub.--2 workload may then be scheduled to run concurrently and after that, Batch.sub.--1 workload and Batch.sub.--3 workload may be scheduled to run concurrently.” ¶ [0027] states “identify data access conflicts (e.g., at a desired granularity).” ¶ [0047] states “the selected granularity comprises one of: (a) database table; (b) database page; (c) database record; (d) a database column; (e) a database; (f) a data set.” Examiner’s Note: based on the OLTP workload and batch workload accessing different database tables (a type of granularity), the OLTP workload and batch are scheduled to run concurrently)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the OLTP and batch workloads not accessing the same database table of Dillenberger with the job grouping of Dube. Dube teaches that tasks may depend on a data set. Data sets are example granularity as shown in Dillenberger ¶ [0047]. Since database tables are also a level of granularity, it would be obvious that tasks can depend on database table access. As a result, tasks/jobs are grouped based on database table access. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of optimize the scheduling of OLTP and batch workloads to increase resource utilization and completing both types of workloads with larger execution windows (¶ [0031] states “the optimized fine grain scheduling that is based on the simulation can be output and can be used to impact the scheduling of workloads in real-time and/or in the future … In one example, scheduling and/or system level settings may relate to provisioning more resources when contention is no longer an issue; or provisioning more threads for certain work such as I/O processing.” ¶ [0003] states “a larger amount of Batch data may require one or more Batch time windows to be widened. In another example, business growth from regional to nationwide or from nationwide to international of a banking institution widens the OLTP time window for business reasons and consequently shrinks the batch time window”).
Dube and Dillenberger do not explicitly teach monitoring, identifying, and reducing steps.
However, in an analogous art, Di Balsamo teaches monitoring, by the one or more processors, workload resource usage of system for running the plurality of batch jobs and a plurality of transaction workloads (¶ [0069] states “The resource manager 406 may monitor the resource pool and determine a resource pool parameter … For example, the resource pool parameter may include a CPU utilization level, the number of resources in the resource pool, or the ratio the number of jobs in the workload plan to the number of resources in the resource pool.” ¶ [0062] states “Jobs may include at least two types of workloads including batch jobs and transactional jobs. Batch jobs may be scheduled and stored in the workload plan 403 at time of creation of the workload plan 403 … Transactional jobs, however, may process data in real time and may not be known of prior to creation of the workload plan 403”. Examiner’s Note: the resources that resource manager monitors are for the execution of the jobs. Jobs can either be batch jobs or transaction workloads);
identifying, by the one or more processors, one or more scheduled transaction workloads will not be able to be completed in under a preset time threshold due to a central processing unit (CPU) limit (¶ [0073] states “Resource allocation 514 may also include determining whether the job forecast exceeds the job deadline 516.” ¶ [0043] states “The method may also include modifying the resource pool to bring a resource pool parameter within a resource range in response to determining that the job forecast exceeds a job deadline.” ¶ [0068] states “In an embodiment the resource range may have an upper resource limit set at eighty percent (80%) CPU utilization so that when the resource pool parameter is represented by a CPU utilization level, a greater than 80% CPU utilization violates the SLA policy. However the lower resource limit may be set at fifty percent (50%) CPU utilization so that when the resource pool parameter is represented by a CPU utilization level, a less than 50% CPU utilization will violate the SLA policy.” Examiner’s Note: the upper and lower resource limits are based on CPU utilization. Modifying a resource pool parameter to be in range of resource limits in response to job that will miss a deadline is identifying a workload will not be completed under a preset time due to CPU limit);
reducing, by the one or more processors, a CPU quota of the first group of batch jobs based on the CPU limit of the one or more scheduled transaction workloads and based on the one or more scheduled transaction workloads not using the first table (¶ [0077] states “In an embodiment the resource range 602 may have an upper resource limit 606 set at eighty percent (80%) CPU utilization so that when the resource pool parameter 608 is represented by a CPU utilization level, a greater than 80% CPU utilization violates the SLA policy. However the lower resource limit 604 may be set at fifty percent (50%) CPU utilization so that when the resource pool parameter 608 is represented by a CPU utilization level, a less than 50% CPU utilization will violate the SLA policy.” ¶ [0078] states “If the resource pool parameter 608 is outside the resource range 602, then the resource pool may be modified to bring the resource pool parameter 608 within the resource range 602.” Examiner’s Note: an expansion or reduction of a resource pool is done to bring a resource parameter within an upper and lower resource range, so it is based on the CPU limit. The resource pool parameter represents a CPU utilization level. The resource pool parameter is the CPU quota).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the monitoring of a resource pool parameter, the identification of a job that exceeds a deadline based on a CPU limit, and the resource modification based on upper and lower thresholds of Di Balsamo with the grouping of tasks of Dube and the data access patterns of Dillenberger. A person having ordinary skill in the art would have motivated to make this combination to “improve responses to changing components, changing workload, and changing environmental conditions, while minimizing the operating costs and reducing violations of the SLAs” (Di Balsamo ¶ [0042]).
Dube, Dillenberger, and Di Balsamo do not explicitly reducing a CPU quota of a group of batch jobs and providing the reduced CPU quota to a transaction workload.
However, in an analogous art, Antani teaches identifying, by the one or more processors, one or more scheduled transaction workloads will not be able to be completed in under a preset time threshold due to a central processing unit (CPU) limit (¶ [0004] states “there are Long Running Transactions ("LRTs") and OnLine Transactions (OLTs)”. ¶ [0040] states “The WLM 102 detects that the SLA for OLT 120 is not being met” and “the WLM 102 determines whether the OLT 120 requires access to one or more transactional and/or system resources 116 being used by the LRT 110. For example, the determination can be made based on the number of CPU cycles used by the OLT 120. If the WLM 102 finds that there is a low CPU usage by OLT 120, then it concludes that no OLT 120 work is being done.” ¶ [0048] states “The SLA metrics can include, but are not limited to, an MTBF metric, an MTR metric, a data rate metric, a throughput metric, a jitter metric, a transactional priority metric, a response time metric, and a transactional deadline metric.” Examiner’s Note: the LRTs and OLTs of Antani are analogous to the batch jobs and transactional jobs of Di Balsamo respectively. See ¶ [0004] for more detail. The OLT is not meeting an SLA. The SLA is based on a response time metric and/or a transactional deadline metric. Metric. It is understood that to have a “low CPU usage,” a limit is required, such as the number of CPU cycles),
reducing, by the one or more processors, a CPU quota of the first group of batch jobs based on the CPU limit of the one or more scheduled transaction workloads and based on the one or more scheduled transaction workloads not using the first table (¶ [0056] states “Step 226 involves identifying the transaction(s) that is(are) using resources needed by the OLT. More particularly, the CPM slows down the LRT(s) identified/selected in step 226 by adjusting how many records are to be processed in each sub-transaction of the LRT(s) and/or increases/decreases the time period between commit operations of the LRT(s). The number of records is adjusted by changing the value of parameter "X" of the above-described ALGORITHM 2. Similarly, the time period between commit operations is adjusted by changing the values of the parameter "X" and/or "Y" of the above-described ALGORITHM 2”. ¶ [0032] states “The value of "Y" may be decreased for purposes of yielding system resource (e.g., a CPU) to other transactions.” ¶ [0036] states “system resources (e.g., CPU and database).” ¶ [0040] states “the WLM 102 determines whether the OLT 120 requires access to one or more transactional and/or system resources 116 being used by the LRT 110. For example, the determination can be made based on the number of CPU cycles used by the OLT 120. If the WLM 102 finds that there is a low CPU usage by OLT 120, then it concludes that no OLT 120 work is being done by TPS 100.” Examiner’s Note: Antani teaches that by changing the resource values of “X” and “Y”, the OLT can acquire the resources it needs. In other words, because of the resources needed by the OLT, or transactional workload, the resources of the LRT, or batch job, are reduced. See ¶ [0030] – [0031] for a full description of “ALGORITHM 2”. ¶ [0036] and [0040] shows that these resources are system resources such as CPU. Therefore, applying “Algorithm 2” leads to a change in CPU quota. Additionally, the reduction is based on the CPU because ¶ [0040] shows that a low CPU usage causes a determination to be made)
providing, by the one or more processors, the reduced CPU quota to the one or more scheduled transaction workloads, wherein the one or more scheduled transaction workloads are completed using the provided CPU quota (¶ [0040] states “Consequently, WLM 102 determines that OLT 120 requires access to one or more transactional and/or system resources 116 being used by LRT 110.” ¶ [0036] states “system resources (e.g., CPU and database).” ¶ [0042] states “Once the CPM 104 identifies the transactions (e.g., LRTs) that are using resources needed by the OLT 120, it performs actions to speed up or slow down the processing related to the identified LRTs. The throttling of each LRT is achieved by selecting values for parameters "X" and "Y" of ALGORITHM 2, and setting parameters "X" and "Y" equal to the respective selected values.” ¶ [0057] states “If the SLA(s) is(are) being met or will be met [230:YES], then step 234 is performed.” Examiner’s Note: due to the LRT’s record processing speed being reduced, the OLT now has more resources, such as CPU quota. Once the SLA for the OLT is met, the OLT executes and completes).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the transfer of resources between LRT and OLT of Antani with the grouping of Dube, the data access patterns based on database table access of Dillenberger, and the resource pool and job deadline of Di Balsamo. As a result, Dube and Dillenberger teach that tasks are grouped based on the database tables they access. Dillenberger, Di Balsamo, and Antani teach that there are transactional workloads and batch job workloads. It can be then identified that a workload will miss a deadline due to CPU limits. Antani teaches the idea of reducing resources, wherein the resource is a system resource such as CPU), of an LRT and providing the resource to the OLT. The reduction of resources is based on a limit described by Di Balsamo’s SLA and upper and lower CPU utilization limits (¶ [0039], [0068], [0077]). The reduction of CPU quota is also based on the transaction workload not using the same table as the first group of batch jobs. Dillenberger teaches that batch jobs can be scheduled based on database table access so that different workloads can be scheduled concurrently and have no conflict. This is done to support scheduling OLTP and batch workloads together because “online transaction processing (sometimes referred to herein as "OLTP") work requires prompt response time” (Dillenberger ¶ [0001]). OLTP workloads have a deadline. Di Balsamo ¶ [0072] and Antani ¶ [0031] teach that adjusting resource allocation to meet a deadline. In other words, the idea Dillenberger teaches the idea of scheduling OLTP and batch workloads based on which database tables are accessed so that OLTP workloads can be completed on time. The combination of Dillenberger with Dube, Di Balsamo, and Antani results in a transfer of resources based on database table accesses so that transaction workloads meet an SLA and complete.
According to Antani ¶ [0019], “The present invention generally concerns systems and methods for autonomically controlling checkpoint intervals at a fine-grained level for LRTs. The term "autonomic", as used herein, refers to the ability to function independently without outside influence.” ¶ [0022] states “The LRTs and checkpoint mechanisms collectively facilitates efficient data processing.” Additionally, the process described in Antani ¶ [0052] – [0057] are for the purpose of reducing SLA violations. Therefore, a person having ordinary skill in the art would have been motivated to make this combination for the purpose of automating the adjustment of LRTs to reduce SLA violations and complete data processing in an efficient manner.
With regard to claim 9, Dube, Dillenberger, Di Balsamo, and Antani teach the computer program product of claim 8. To reestablish the teaching, Di Balsamo teaches batch jobs (¶ [0062] states “Jobs may include at least two types of workloads including batch jobs and transactional jobs”). Dube additionally teaches wherein the operations further comprise: scheduling batch jobs of the plurality of batch jobs from different groups of the plurality of groups at a same time which lowers competition between resources (¶ [0040] states “Having no prerequisite connection between tasks 302 and 303 indicates that both tasks can execute simultaneously once task 301 completes execution”. ¶ [0041] states “As task 302 has no dashed line connections to any data sets, task 302 has no data dependencies and does not require any data sets to be available in order for it to execute. Task 303 has a data dependency of both data set 311 and 312”. Examiner’s Note: tasks can be substituted by batch jobs. ¶ [0040] and [0041] are referring to FIG. 3. Task 302 and 303 belong to different groups because although they both depend on task 301, task 303 also depends on data set 311 and 312. Once dependency task 301 is completed and task 303 has access to data sets 311 and 312, task 302 and 303 can be executed simultaneously. In other words, they can be scheduled for the same time slot).
With regard to claim 10, Dube, Dillenberger, Di Balsamo, and Antani teach the computer program product of claim 8. Di Balsamo additionally teaches wherein the workload resource usage includes database table usage, CPU usage, and memory usage (¶ [0068] states “In an embodiment the resource range may have an upper resource limit set at eighty percent (80%) CPU utilization so that when the resource pool parameter is represented by a CPU utilization level, a greater than 80% CPU utilization violates the SLA policy” and “Other computing parameters may be used including, but not limited to, the quantity of free memory”. ¶ [0069] states “The resource manager 406 may monitor the resource pool and determine a resource pool parameter. The resource pool parameter may be a representation of computing resources in the resource pool”. Examiner’s Note: one of ordinary skill in the art would recognize that the quantity of free memory and used memory are interchangeable).
Antani also teaches wherein the workload resource usage includes database table usage, CPU usage, and memory usage (¶ [0008] states “WorkLoad Managers (WLMs) are typically found in TPSs”. ¶ [0048] states “The WLM continuously monitors transaction processing to determine when a transaction processing job is at risk of completion”. ¶ [0053] states “the LRT obtains an exclusive lock on transactional resources (e.g., a row in a table of a database 116 of FIG. 1)”. Examiner’s Note: the WLM monitors transaction processing which would include workload resource usage. ¶ [0053] states a database row is an example of a transactional resource. It would be obvious to one of ordinary skill the art that the lock could control the row or the table).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine database table usage of Antani with the workload resource usage including CPU and memory usage of Di Balsamo. A person having ordinary skill in the art would have motivated to make this combination for the purpose of “balancing how many records get locked during a transaction and for how long the records are locked. The balancing is done in the context of other transactional work in the TPS, the priorities of the transactional work and deadlines of the transactional work” (Antani ¶ [0028]). Balancing transactional resources with priorities of transactional work requires the monitoring of database tables along with the other resources. Additionally, the balancing of priorities aids in detecting if an SLA is being met and adjusting resource allocation (Antani ¶ [0008]) which has clear benefits.
With regard to claim 15, Dube teaches a computer system comprising: a processor set; one or more computer readable storage media; and program instructions collectively stored on the one or more computer readable storage media to cause the processor set to perform operations comprising (¶ [0056] states “The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention”. ¶ [0061] states “These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks”):
grouping, by one or more processors, a plurality of batch jobs based on workload resource requests and dependencies of each batch job resulting in a plurality of groups, wherein a first group of batch jobs share a first table and a second group of batch jobs share a second table (¶ [0050] states “Workload scheduling program 150 is stored in persistent storage 708 for execution by one or more of the respective computer processors 704 via one or more memories of memory 706”. ¶ [0021] states “A request for execution of a computing job received in step 205 includes at least a list of tasks to be executed as part of the computing job, as well as any dependencies required for execution of those tasks … Additionally, a dependency for a task can also include a data dependency which prevents the execution of a task unless a specific portion of data is available”. ¶ [0021] also states “In the depicted embodiment, task 301 has no prerequisite tasks, and has a dependency of data set 311 in order to be executed.” ¶ [0023] states “In order to determine if a task can be executed by a data processing element, workload scheduling program 150 determines if the type of computation required for the task can be performed by a given data processing element”. ¶ [0023] also states “data set 311 is present on SSD 411 and HDD 412.” ¶ [0045] states “FIG. 6A depicts a first feasible execution mapping for executing computing job 120 on heterogeneous computing device 110, generally designated 600, in accordance with an embodiment of the present invention. Tasks listed inside of data processing elements represent tasks performed by those data processing elements, while data sets listed inside data storage elements represent data sets provided to data processing elements by those data storage elements”. Examiner’s Note: the workload scheduling manager is executed on a processor. Tasks can depend on another task or a specific data source. Additionally, tasks can depend on a specific computing resource is available. FIG. 4 shows the types of computing resources and data source available. FIG. 5 shows the tasks (the non-underlined numbers) grouped to each computing resource. Data set 311 is a specific portion of data);
scheduling, by the one or more processors, the plurality of batch jobs based on the plurality of groups (¶ [0024] states “Using the information represented in the task and data graph, workload scheduling program 150 assigns the task, or set of tasks, which must be executed first to one or more data processing elements identified as capable of executing that task in the resource graph”. ¶ [0037] states “Workload scheduling program 150 selects the mapping which receives the highest total value for execution on heterogeneous computing device 110”. Examiner’s Note: the workload scheduling program first creates potential schedules called mappings. Then the workload scheduling program selects the best mapping and schedules the task);
Dube does not explicitly teach groups of batch jobs sharing different tables.
However, in an analogous art, Dillenberger teaches a method comprising: grouping, by one or more processors, a plurality of batch jobs based on workload resource requests and dependencies of each batch job resulting in a plurality of groups, wherein a first group of batch jobs share a first table and a second group of batch jobs share a second table (¶ [0037] states “it can be detected that a conflict exists between OLTP Workload and Batch.sub.--1 workload but not between OLTP Workload and Batch.sub.--2 workload or between Batch.sub.--1 workload and Batch.sub.--3 workload.” ¶ [0027] states “identify data access conflicts (e.g., at a desired granularity).” ¶ [0047] states “the selected granularity comprises one of: (a) database table; (b) database page; (c) database record; (d) a database column; (e) a database; (f) a data set.” Examiner’s Note: OLTP workload and batch 2 do not have a data access conflict. Batch 1 and batch 3 also do not have a data access conflict. The data access conflict is based on a granularity level. Database tables are example granularity. Since OLTP and batch 2 do not have a conflict, they are accessing different tables).
reducing, by the one or more processors, a CPU quota of the first group of batch jobs based on the CPU limit of the one or more scheduled transaction workloads and based on the one or more scheduled transaction workloads not using the first table (¶ [0037] states “it can be detected that a conflict exists between OLTP Workload and Batch.sub.--1 workload but not between OLTP Workload and Batch.sub.--2 workload or between Batch.sub.--1 workload and Batch.sub.--3 workload. The OLTP Workload and Batch.sub.--2 workload may then be scheduled to run concurrently and after that, Batch.sub.--1 workload and Batch.sub.--3 workload may be scheduled to run concurrently.” ¶ [0027] states “identify data access conflicts (e.g., at a desired granularity).” ¶ [0047] states “the selected granularity comprises one of: (a) database table; (b) database page; (c) database record; (d) a database column; (e) a database; (f) a data set.” Examiner’s Note: based on the OLTP workload and batch workload accessing different database tables (a type of granularity), the OLTP workload and batch are scheduled to run concurrently)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the OLTP and batch workloads not accessing the same database table of Dillenberger with the job grouping of Dube. Dube teaches that tasks may depend on a data set. Data sets are example granularity as shown in Dillenberger ¶ [0047]. Since database tables are also a level of granularity, it would be obvious that tasks can depend on database table access. As a result, tasks/jobs are grouped based on database table access. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of optimize the scheduling of OLTP and batch workloads to increase resource utilization and completing both types of workloads with larger execution windows (¶ [0031] states “the optimized fine grain scheduling that is based on the simulation can be output and can be used to impact the scheduling of workloads in real-time and/or in the future … In one example, scheduling and/or system level settings may relate to provisioning more resources when contention is no longer an issue; or provisioning more threads for certain work such as I/O processing.” ¶ [0003] states “a larger amount of Batch data may require one or more Batch time windows to be widened. In another example, business growth from regional to nationwide or from nationwide to international of a banking institution widens the OLTP time window for business reasons and consequently shrinks the batch time window”).
Dube and Dillenberger do not explicitly teach monitoring, identifying, and reducing steps.
However, in an analogous art, Di Balsamo teaches monitoring, by the one or more processors, workload resource usage of system for running the plurality of batch jobs and a plurality of transaction workloads (¶ [0069] states “The resource manager 406 may monitor the resource pool and determine a resource pool parameter … For example, the resource pool parameter may include a CPU utilization level, the number of resources in the resource pool, or the ratio the number of jobs in the workload plan to the number of resources in the resource pool.” ¶ [0062] states “Jobs may include at least two types of workloads including batch jobs and transactional jobs. Batch jobs may be scheduled and stored in the workload plan 403 at time of creation of the workload plan 403 … Transactional jobs, however, may process data in real time and may not be known of prior to creation of the workload plan 403”. Examiner’s Note: the resources that resource manager monitors are for the execution of the jobs. Jobs can either be batch jobs or transaction workloads);
identifying, by the one or more processors, one or more scheduled transaction workloads will not be able to be completed in under a preset time threshold due to a central processing unit (CPU) limit (¶ [0073] states “Resource allocation 514 may also include determining whether the job forecast exceeds the job deadline 516.” ¶ [0043] states “The method may also include modifying the resource pool to bring a resource pool parameter within a resource range in response to determining that the job forecast exceeds a job deadline.” ¶ [0068] states “In an embodiment the resource range may have an upper resource limit set at eighty percent (80%) CPU utilization so that when the resource pool parameter is represented by a CPU utilization level, a greater than 80% CPU utilization violates the SLA policy. However the lower resource limit may be set at fifty percent (50%) CPU utilization so that when the resource pool parameter is represented by a CPU utilization level, a less than 50% CPU utilization will violate the SLA policy.” Examiner’s Note: the upper and lower resource limits are based on CPU utilization. Modifying a resource pool parameter to be in range of resource limits in response to job that will miss a deadline is identifying a workload will not be completed under a preset time due to CPU limit);
reducing, by the one or more processors, a CPU quota of the first group of batch jobs based on the CPU limit of the one or more scheduled transaction workloads and based on the one or more scheduled transaction workloads not using the first table (¶ [0077] states “In an embodiment the resource range 602 may have an upper resource limit 606 set at eighty percent (80%) CPU utilization so that when the resource pool parameter 608 is represented by a CPU utilization level, a greater than 80% CPU utilization violates the SLA policy. However the lower resource limit 604 may be set at fifty percent (50%) CPU utilization so that when the resource pool parameter 608 is represented by a CPU utilization level, a less than 50% CPU utilization will violate the SLA policy.” ¶ [0078] states “If the resource pool parameter 608 is outside the resource range 602, then the resource pool may be modified to bring the resource pool parameter 608 within the resource range 602.” Examiner’s Note: an expansion or reduction of a resource pool is done to bring a resource parameter within an upper and lower resource range, so it is based on the CPU limit. The resource pool parameter represents a CPU utilization level. The resource pool parameter is the CPU quota).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the monitoring of a resource pool parameter, the identification of a job that exceeds a deadline based on a CPU limit, and the resource modification based on upper and lower thresholds of Di Balsamo with the grouping of tasks of Dube and the data access patterns of Dillenberger. A person having ordinary skill in the art would have motivated to make this combination to “improve responses to changing components, changing workload, and changing environmental conditions, while minimizing the operating costs and reducing violations of the SLAs” (Di Balsamo ¶ [0042]).
Dube, Dillenberger, and Di Balsamo do not explicitly reducing a CPU quota of a group of batch jobs and providing the reduced CPU quota to a transaction workload.
However, in an analogous art, Antani teaches identifying, by the one or more processors, one or more scheduled transaction workloads will not be able to be completed in under a preset time threshold due to a central processing unit (CPU) limit (¶ [0004] states “there are Long Running Transactions ("LRTs") and OnLine Transactions (OLTs)”. ¶ [0040] states “The WLM 102 detects that the SLA for OLT 120 is not being met” and “the WLM 102 determines whether the OLT 120 requires access to one or more transactional and/or system resources 116 being used by the LRT 110. For example, the determination can be made based on the number of CPU cycles used by the OLT 120. If the WLM 102 finds that there is a low CPU usage by OLT 120, then it concludes that no OLT 120 work is being done.” ¶ [0048] states “The SLA metrics can include, but are not limited to, an MTBF metric, an MTR metric, a data rate metric, a throughput metric, a jitter metric, a transactional priority metric, a response time metric, and a transactional deadline metric.” Examiner’s Note: the LRTs and OLTs of Antani are analogous to the batch jobs and transactional jobs of Di Balsamo respectively. See ¶ [0004] for more detail. The OLT is not meeting an SLA. The SLA is based on a response time metric and/or a transactional deadline metric. Metric. It is understood that to have a “low CPU usage,” a limit is required, such as the number of CPU cycles),
reducing, by the one or more processors, a CPU quota of the first group of batch jobs based on the CPU limit of the one or more scheduled transaction workloads and based on the one or more scheduled transaction workloads not using the first table (¶ [0056] states “Step 226 involves identifying the transaction(s) that is(are) using resources needed by the OLT. More particularly, the CPM slows down the LRT(s) identified/selected in step 226 by adjusting how many records are to be processed in each sub-transaction of the LRT(s) and/or increases/decreases the time period between commit operations of the LRT(s). The number of records is adjusted by changing the value of parameter "X" of the above-described ALGORITHM 2. Similarly, the time period between commit operations is adjusted by changing the values of the parameter "X" and/or "Y" of the above-described ALGORITHM 2”. ¶ [0032] states “The value of "Y" may be decreased for purposes of yielding system resource (e.g., a CPU) to other transactions.” ¶ [0036] states “system resources (e.g., CPU and database).” ¶ [0040] states “the WLM 102 determines whether the OLT 120 requires access to one or more transactional and/or system resources 116 being used by the LRT 110. For example, the determination can be made based on the number of CPU cycles used by the OLT 120. If the WLM 102 finds that there is a low CPU usage by OLT 120, then it concludes that no OLT 120 work is being done by TPS 100.” Examiner’s Note: Antani teaches that by changing the resource values of “X” and “Y”, the OLT can acquire the resources it needs. In other words, because of the resources needed by the OLT, or transactional workload, the resources of the LRT, or batch job, are reduced. See ¶ [0030] – [0031] for a full description of “ALGORITHM 2”. ¶ [0036] and [0040] shows that these resources are system resources such as CPU. Therefore, applying “Algorithm 2” leads to a change in CPU quota. Additionally, the reduction is based on the CPU because ¶ [0040] shows that a low CPU usage causes a determination to be made)
providing, by the one or more processors, the reduced CPU quota to the one or more scheduled transaction workloads, wherein the one or more scheduled transaction workloads are completed using the provided CPU quota (¶ [0040] states “Consequently, WLM 102 determines that OLT 120 requires access to one or more transactional and/or system resources 116 being used by LRT 110.” ¶ [0036] states “system resources (e.g., CPU and database).” ¶ [0042] states “Once the CPM 104 identifies the transactions (e.g., LRTs) that are using resources needed by the OLT 120, it performs actions to speed up or slow down the processing related to the identified LRTs. The throttling of each LRT is achieved by selecting values for parameters "X" and "Y" of ALGORITHM 2, and setting parameters "X" and "Y" equal to the respective selected values.” ¶ [0057] states “If the SLA(s) is(are) being met or will be met [230:YES], then step 234 is performed.” Examiner’s Note: due to the LRT’s record processing speed being reduced, the OLT now has more resources, such as CPU quota. Once the SLA for the OLT is met, the OLT executes and completes).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the transfer of resources between LRT and OLT of Antani with the grouping of Dube, the data access patterns based on database table access of Dillenberger, and the resource pool and job deadline of Di Balsamo. As a result, Dube and Dillenberger teach that tasks are grouped based on the database tables they access. Dillenberger, Di Balsamo, and Antani teach that there are transactional workloads and batch job workloads. It can be then identified that a workload will miss a deadline due to CPU limits. Antani teaches the idea of reducing resources, wherein the resource is a system resource such as CPU), of an LRT and providing the resource to the OLT. The reduction of resources is based on a limit described by Di Balsamo’s SLA and upper and lower CPU utilization limits (¶ [0039], [0068], [0077]). The reduction of CPU quota is also based on the transaction workload not using the same table as the first group of batch jobs. Dillenberger teaches that batch jobs can be scheduled based on database table access so that different workloads can be scheduled concurrently and have no conflict. This is done to support scheduling OLTP and batch workloads together because “online transaction processing (sometimes referred to herein as "OLTP") work requires prompt response time” (Dillenberger ¶ [0001]). OLTP workloads have a deadline. Di Balsamo ¶ [0072] and Antani ¶ [0031] teach that adjusting resource allocation to meet a deadline. In other words, the idea Dillenberger teaches the idea of scheduling OLTP and batch workloads based on which database tables are accessed so that OLTP workloads can be completed on time. The combination of Dillenberger with Dube, Di Balsamo, and Antani results in a transfer of resources based on database table accesses so that transaction workloads meet an SLA and complete.
According to Antani ¶ [0019], “The present invention generally concerns systems and methods for autonomically controlling checkpoint intervals at a fine-grained level for LRTs. The term "autonomic", as used herein, refers to the ability to function independently without outside influence.” ¶ [0022] states “The LRTs and checkpoint mechanisms collectively facilitates efficient data processing.” Additionally, the process described in Antani ¶ [0052] – [0057] are for the purpose of reducing SLA violations. Therefore, a person having ordinary skill in the art would have been motivated to make this combination for the purpose of automating the adjustment of LRTs to reduce SLA violations and complete data processing in an efficient manner.
With regard to claim 16, Dube, Dillenberger, Di Balsamo, and Antani teach the computer system of claim 15. To reestablish the teaching, Di Balsamo teaches batch jobs (¶ [0062] states “Jobs may include at least two types of workloads including batch jobs and transactional jobs”). Dube additionally teaches wherein the operations further comprise: scheduling batch jobs of the plurality of batch jobs from different groups of the plurality of groups at a same time which lowers competition between resources (¶ [0040] states “Having no prerequisite connection between tasks 302 and 303 indicates that both tasks can execute simultaneously once task 301 completes execution”. ¶ [0041] states “As task 302 has no dashed line connections to any data sets, task 302 has no data dependencies and does not require any data sets to be available in order for it to execute. Task 303 has a data dependency of both data set 311 and 312”. Examiner’s Note: tasks can be substituted by batch jobs. ¶ [0040] and [0041] are referring to FIG. 3. Task 302 and 303 belong to different groups because although they both depend on task 301, task 303 also depends on data set 311 and 312. Once dependency task 301 is completed and task 303 has access to data sets 311 and 312, task 302 and 303 can be executed simultaneously. In other words, they can be scheduled for the same time slot).
Claims 7, 14, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dube, in view of Dillenberger, Di Balsamo, and Antani, and further in view of Poothia et al. Pat. No. US 20200042338 A1 (hereafter Poothia).
With regard to claim 7, Dube, Dillenberger, Di Balsamo, and Antani teach the method of claim 1. To reestablish the environment involving batch jobs and transact workloads, Di Balsamo teaches scheduled transaction workloads and batch jobs (¶ [0062] states “Jobs may include at least two types of workloads including batch jobs and transactional jobs”)
Dube, Dillenberger, Di Balsamo, and Antani do not explicitly teach selecting, choosing based on history peak memory usage, reducing memory to history peak memory usage, releasing memory, and assigning released memory to scheduled transaction workloads.
However, in an analogous art, Poothia teaches selecting, by the one or more processors, one or more running batch jobs from different groups of the plurality of groups (¶ [0095] states “If the recommendation engine 305 finds a virtual machine (e.g., the virtual machines 320) to be constrained, at operation 430, the recommendation engine determines how much additional memory that particular virtual machine needs to become not constrained. Similarly, if a virtual machine is not constrained (e.g., has additional memory that is not used), the recommendation engine 305 may determine how much extra memory that particular virtual machine has, which may then be moved to constrained virtual machines”. Examiner’s Note: the recommendation engine is selecting a virtual machine. It is interpreted that virtual machines could be substituted with the batch jobs teaching of Di Balsamo as explained earlier);
choosing, by the one or more processors, from the selected one or more running batch jobs, at least one batch job whose history peak memory usage is lower than a memory quota for the at least one batch job (¶ [0104] states “The “upper baseline” identifies one or more peak or highest actual memory usage values of a particular virtual machine within the second predetermined time period (e.g., one day)”. ¶ [0111] states “if the memory resizing recommendation system 340 determines at the operation 520 that the upper baseline is within the predetermined threshold of the operation 520 (and/or does not have a high number of page faults), it means that the virtual machine is not consuming all or substantially all of its initial memory allocation”. ¶ [0109] states “In some embodiments, the predetermined threshold may be based on a specific percentage of the initial memory allocation”. ¶ [0114] states “Upon designating a virtual machine (e.g., one of the virtual machines 320) as constrained for memory, the memory resizing recommendation system 340 determines a revised or optimal memory allocation for that particular virtual machine via process 600 of FIG. 6”. ¶ [0125] states “The analysis for the not constrained case is same as outlined above in the process 600”. Examiner’s Note: the “upper baseline” represents the history peak memory usage. The initial memory allocation is the memory quota. Process 600 could be applied to when the virtual machine has extra memory, so process 600 involves choosing the virtual machine that has a previous peak that is lower than its initial allocation);
reducing, by the one or more processors, the memory quota of the at least one batch job to the history peak memory usage leaving a reserve amount of memory ([0104] states “The “upper baseline” identifies one or more peak or highest actual memory usage values of a particular virtual machine within the second predetermined time period (e.g., one day)”. ¶ [0125] states “When the process 600 is performed for a not constrained memory, the virtual machine being analyzed has more memory than it uses, and the process 600 determines how much extra memory the virtual machine has that may be taken away from that virtual machine … The analysis for the not constrained case is same as outlined above in the process 600”. ¶ [0115] states “the memory resizing recommendation system 340 may add a predetermined fraction to the upper baseline computed for active memory usage from the current memory usage profile. For example, if the predetermined fraction is 20% and the upper baseline is 100% of initial memory allocation, the memory resizing recommendation system 340 may compute the initial revised memory allocation as the sum of 100% upper baseline plus 20% such that the initial revised memory allocation is 120% of the initial memory allocation”. Examiner’s Note: in ¶ [0115], the memory resizing recommendation system resizes the memory in order to give the virtual machine additional memory. It does so by adding a predetermined fraction. When process 600 is applied to a virtual machine with extra memory, it is interpreted that the predetermined fraction would be subtracted from the upper baseline. In light of the upper baseline representing a previous peak memory usage, it would be obvious to one of ordinary skill in the art that as the predetermined fraction approaches and becomes zero, the new determined memory size would be equal to the upper baseline. In the case of shrinking memory allocation, setting the memory allocation to the upper baseline would mean setting the memory allocation to a previous peak memory usage);
releasing, by the one or more processors, the reserve amount of memory (¶ [0123] states “at the operation 625, the memory resizing recommendation system 340 adjusts the initial revised memory allocation based upon the historical memory usage and computes the final revised memory allocation for a future period of time. Upon determining the final revised memory usage values, the memory resizing recommendation system 340 outputs those values at operation 630. In some embodiments, the output may be sent to the management system 315”. ¶ [0080] states “The memory resizing recommendation system 340 may, in some embodiments, convey the revised memory allocation determinations to the management system 315, which can then adjust the memory allocated to a particular virtual machine”. Examiner’s Note: when process 600 is applied to a virtual machine with extra memory, the management system would lower its memory to the previous peak as explained previously. The difference between the initial allocation and the new allocation at the previous peak memory usage is the reserve amount of memory. Since it is no longer allocated to the original virtual machine, it is released);
and providing, by the one or more processors, the released reserve amount of memory to the one or more scheduled transaction workloads (¶ [0124] states “the memory resizing recommendation system 340 may be configured to run the processes 500 and 600 on one virtual machine at a time, on all of the virtual machines simultaneously, or on a subset of virtual machines at a time”. ¶ [0125] states “when the process 600 is performed for a constrained memory situation, the virtual machine being analyzed uses more memory than allocated, so the process 600 determines the additional amount of memory to allocate to that virtual machine” and “When the process 600 is performed for a not constrained memory, the virtual machine being analyzed has more memory than it uses, and the process 600 determines how much extra memory the virtual machine has that may be taken away from that virtual machine”. Examiner’s Note: the process 600 can either increase the memory allocation or decrease the memory allocation. ¶ [0124] explains that the process 500 and 600 can happen on multiple virtual machines simultaneously. Therefore, it would obvious to one of ordinary skill in the art that the process 600 could happen on two virtual machines on the same host, one that needs extra memory and on that has extra memory. The process 600 would determine to reallocate memory from the virtual machine with extra memory to the virtual machine that needs memory).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine virtual machine reallocation process of Poothia with the method of grouping and scheduling of batch jobs, the monitoring of workload resource usage, the database access patterns, the identifying of a job that will not meet a deadline, and the resource quota reduction of Dube, Dillenberger, Di Balsamo, and Antani. A person having ordinary skill in the art would have motivated to make this combination because when “memory is optimally used, workloads are run faster and with less disruption, and ultimately operation and performance of the virtual machines is improved” (Poothia ¶ [0027]).
With regard to claim 14, Dube, Dillenberger, Di Balsamo, and Antani teach the computer program product of claim 8. To reestablish the environment involving batch jobs and transact workloads, Di Balsamo teaches scheduled transaction workloads and batch jobs (¶ [0062] states “Jobs may include at least two types of workloads including batch jobs and transactional jobs”).
Dube, Dillenberger, Di Balsamo, and Antani do not explicitly teach selecting, choosing based on history peak memory usage, reducing memory to history peak memory usage, releasing memory, and assigning released memory to scheduled transaction workloads.
However, in an analogous art, Poothia teaches wherein the operations further comprise: selecting one or more running batch jobs from different groups of the plurality of groups (¶ [0095] states “If the recommendation engine 305 finds a virtual machine (e.g., the virtual machines 320) to be constrained, at operation 430, the recommendation engine determines how much additional memory that particular virtual machine needs to become not constrained. Similarly, if a virtual machine is not constrained (e.g., has additional memory that is not used), the recommendation engine 305 may determine how much extra memory that particular virtual machine has, which may then be moved to constrained virtual machines”. Examiner’s Note: the recommendation engine is selecting a virtual machine. It is interpreted that virtual machines could be substituted with the batch jobs teaching of Di Balsamo as explained earlier);
choosing, from the selected one or more running batch jobs, at least one batch job whose history peak memory usage is lower than a memory quota for the at least one batch job (¶ [0104] states “The “upper baseline” identifies one or more peak or highest actual memory usage values of a particular virtual machine within the second predetermined time period (e.g., one day)”. ¶ [0111] states “if the memory resizing recommendation system 340 determines at the operation 520 that the upper baseline is within the predetermined threshold of the operation 520 (and/or does not have a high number of page faults), it means that the virtual machine is not consuming all or substantially all of its initial memory allocation”. ¶ [0109] states “In some embodiments, the predetermined threshold may be based on a specific percentage of the initial memory allocation”. ¶ [0114] states “Upon designating a virtual machine (e.g., one of the virtual machines 320) as constrained for memory, the memory resizing recommendation system 340 determines a revised or optimal memory allocation for that particular virtual machine via process 600 of FIG. 6”. ¶ [0125] states “The analysis for the not constrained case is same as outlined above in the process 600”. Examiner’s Note: the “upper baseline” represents the history peak memory usage. The initial memory allocation is the memory quota. Process 600 could be applied to when the virtual machine has extra memory, so process 600 involves choosing the virtual machine that has a previous peak that is lower than its initial allocation);
reducing the memory quota of the at least one batch job to the history peak memory usage leaving a reserve amount of memory ([0104] states “The “upper baseline” identifies one or more peak or highest actual memory usage values of a particular virtual machine within the second predetermined time period (e.g., one day)”. ¶ [0125] states “When the process 600 is performed for a not constrained memory, the virtual machine being analyzed has more memory than it uses, and the process 600 determines how much extra memory the virtual machine has that may be taken away from that virtual machine … The analysis for the not constrained case is same as outlined above in the process 600”. ¶ [0115] states “the memory resizing recommendation system 340 may add a predetermined fraction to the upper baseline computed for active memory usage from the current memory usage profile. For example, if the predetermined fraction is 20% and the upper baseline is 100% of initial memory allocation, the memory resizing recommendation system 340 may compute the initial revised memory allocation as the sum of 100% upper baseline plus 20% such that the initial revised memory allocation is 120% of the initial memory allocation”. Examiner’s Note: in ¶ [0115], the memory resizing recommendation system resizes the memory in order to give the virtual machine additional memory. It does so by adding a predetermined fraction. When process 600 is applied to a virtual machine with extra memory, it is interpreted that the predetermined fraction would be subtracted from the upper baseline. In light of the upper baseline representing a previous peak memory usage, it would be obvious to one of ordinary skill in the art that as the predetermined fraction approaches and becomes zero, the new determined memory size would be equal to the upper baseline. In the case of shrinking memory allocation, setting the memory allocation to the upper baseline would mean setting the memory allocation to a previous peak memory usage);
releasing the reserve amount of memory (¶ [0123] states “at the operation 625, the memory resizing recommendation system 340 adjusts the initial revised memory allocation based upon the historical memory usage and computes the final revised memory allocation for a future period of time. Upon determining the final revised memory usage values, the memory resizing recommendation system 340 outputs those values at operation 630. In some embodiments, the output may be sent to the management system 315”. ¶ [0080] states “The memory resizing recommendation system 340 may, in some embodiments, convey the revised memory allocation determinations to the management system 315, which can then adjust the memory allocated to a particular virtual machine”. Examiner’s Note: when process 600 is applied to a virtual machine with extra memory, the management system would lower its memory to the previous peak as explained previously. The difference between the initial allocation and the new allocation at the previous peak memory usage is the reserve amount of memory. Since it is no longer allocated to the original virtual machine, it is released);
providing the released reserve amount of memory to the one or more scheduled transaction workloads (¶ [0124] states “the memory resizing recommendation system 340 may be configured to run the processes 500 and 600 on one virtual machine at a time, on all of the virtual machines simultaneously, or on a subset of virtual machines at a time”. ¶ [0125] states “when the process 600 is performed for a constrained memory situation, the virtual machine being analyzed uses more memory than allocated, so the process 600 determines the additional amount of memory to allocate to that virtual machine” and “When the process 600 is performed for a not constrained memory, the virtual machine being analyzed has more memory than it uses, and the process 600 determines how much extra memory the virtual machine has that may be taken away from that virtual machine”. Examiner’s Note: the process 600 can either increase the memory allocation or decrease the memory allocation. ¶ [0124] explains that the process 500 and 600 can happen on multiple virtual machines simultaneously. Therefore, it would obvious to one of ordinary skill in the art that the process 600 could happen on two virtual machines on the same host, one that needs extra memory and on that has extra memory. The process 600 would determine to reallocate memory from the virtual machine with extra memory to the virtual machine that needs memory).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine virtual machine reallocation process of Poothia with the method of grouping and scheduling of batch jobs, the monitoring of workload resource usage, the database access patterns, the identifying of a job that will not meet a deadline, and the resource quota reduction of Dube, Dillenberger, Di Balsamo, and Antani. A person having ordinary skill in the art would have motivated to make this combination because when “memory is optimally used, workloads are run faster and with less disruption, and ultimately operation and performance of the virtual machines is improved” (Poothia ¶ [0027]).
With regard to claim 20, Dube, Dillenberger, Di Balsamo, and Antani teach the computer system of claim 15. To reestablish the environment involving batch jobs and transact workloads, Di Balsamo teaches scheduled transaction workloads and batch jobs (¶ [0062] states “Jobs may include at least two types of workloads including batch jobs and transactional jobs”).
Dube, Dillenberger, Di Balsamo, and Antani do not explicitly teach selecting, choosing based on history peak memory usage, reducing memory to history peak memory usage, releasing memory, and assigning released memory to scheduled transaction workloads.
However, in an analogous art, Poothia teaches wherein the operations further comprise: selecting one or more running batch jobs from different groups of the plurality of groups (¶ [0095] states “If the recommendation engine 305 finds a virtual machine (e.g., the virtual machines 320) to be constrained, at operation 430, the recommendation engine determines how much additional memory that particular virtual machine needs to become not constrained. Similarly, if a virtual machine is not constrained (e.g., has additional memory that is not used), the recommendation engine 305 may determine how much extra memory that particular virtual machine has, which may then be moved to constrained virtual machines”. Examiner’s Note: the recommendation engine is selecting a virtual machine. It is interpreted that virtual machines could be substituted with the batch jobs teaching of Di Balsamo as explained earlier);
choosing, from the selected one or more running batch jobs, at least one batch job whose history peak memory usage is lower than a memory quota for the at least one batch job (¶ [0104] states “The “upper baseline” identifies one or more peak or highest actual memory usage values of a particular virtual machine within the second predetermined time period (e.g., one day)”. ¶ [0111] states “if the memory resizing recommendation system 340 determines at the operation 520 that the upper baseline is within the predetermined threshold of the operation 520 (and/or does not have a high number of page faults), it means that the virtual machine is not consuming all or substantially all of its initial memory allocation”. ¶ [0109] states “In some embodiments, the predetermined threshold may be based on a specific percentage of the initial memory allocation”. ¶ [0114] states “Upon designating a virtual machine (e.g., one of the virtual machines 320) as constrained for memory, the memory resizing recommendation system 340 determines a revised or optimal memory allocation for that particular virtual machine via process 600 of FIG. 6”. ¶ [0125] states “The analysis for the not constrained case is same as outlined above in the process 600”. Examiner’s Note: the “upper baseline” represents the history peak memory usage. The initial memory allocation is the memory quota. Process 600 could be applied to when the virtual machine has extra memory, so process 600 involves choosing the virtual machine that has a previous peak that is lower than its initial allocation);
reducing the memory quota of the at least one batch job to the history peak memory usage leaving a reserve amount of memory ([0104] states “The “upper baseline” identifies one or more peak or highest actual memory usage values of a particular virtual machine within the second predetermined time period (e.g., one day)”. ¶ [0125] states “When the process 600 is performed for a not constrained memory, the virtual machine being analyzed has more memory than it uses, and the process 600 determines how much extra memory the virtual machine has that may be taken away from that virtual machine … The analysis for the not constrained case is same as outlined above in the process 600”. ¶ [0115] states “the memory resizing recommendation system 340 may add a predetermined fraction to the upper baseline computed for active memory usage from the current memory usage profile. For example, if the predetermined fraction is 20% and the upper baseline is 100% of initial memory allocation, the memory resizing recommendation system 340 may compute the initial revised memory allocation as the sum of 100% upper baseline plus 20% such that the initial revised memory allocation is 120% of the initial memory allocation”. Examiner’s Note: in ¶ [0115], the memory resizing recommendation system resizes the memory in order to give the virtual machine additional memory. It does so by adding a predetermined fraction. When process 600 is applied to a virtual machine with extra memory, it is interpreted that the predetermined fraction would be subtracted from the upper baseline. In light of the upper baseline representing a previous peak memory usage, it would be obvious to one of ordinary skill in the art that as the predetermined fraction approaches and becomes zero, the new determined memory size would be equal to the upper baseline. In the case of shrinking memory allocation, setting the memory allocation to the upper baseline would mean setting the memory allocation to a previous peak memory usage);
releasing the reserve amount of memory (¶ [0123] states “at the operation 625, the memory resizing recommendation system 340 adjusts the initial revised memory allocation based upon the historical memory usage and computes the final revised memory allocation for a future period of time. Upon determining the final revised memory usage values, the memory resizing recommendation system 340 outputs those values at operation 630. In some embodiments, the output may be sent to the management system 315”. ¶ [0080] states “The memory resizing recommendation system 340 may, in some embodiments, convey the revised memory allocation determinations to the management system 315, which can then adjust the memory allocated to a particular virtual machine”. Examiner’s Note: when process 600 is applied to a virtual machine with extra memory, the management system would lower its memory to the previous peak as explained previously. The difference between the initial allocation and the new allocation at the previous peak memory usage is the reserve amount of memory. Since it is no longer allocated to the original virtual machine, it is released);
providing the released reserve amount of memory to the one or more scheduled transaction workloads (¶ [0124] states “the memory resizing recommendation system 340 may be configured to run the processes 500 and 600 on one virtual machine at a time, on all of the virtual machines simultaneously, or on a subset of virtual machines at a time”. ¶ [0125] states “when the process 600 is performed for a constrained memory situation, the virtual machine being analyzed uses more memory than allocated, so the process 600 determines the additional amount of memory to allocate to that virtual machine” and “When the process 600 is performed for a not constrained memory, the virtual machine being analyzed has more memory than it uses, and the process 600 determines how much extra memory the virtual machine has that may be taken away from that virtual machine”. Examiner’s Note: the process 600 can either increase the memory allocation or decrease the memory allocation. ¶ [0124] explains that the process 500 and 600 can happen on multiple virtual machines simultaneously. Therefore, it would obvious to one of ordinary skill in the art that the process 600 could happen on two virtual machines on the same host, one that needs extra memory and on that has extra memory. The process 600 would determine to reallocate memory from the virtual machine with extra memory to the virtual machine that needs memory).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine virtual machine reallocation process of Poothia with the method of grouping and scheduling of batch jobs, the monitoring of workload resource usage, the database access patterns, the identifying of a job that will not meet a deadline, and the resource quota reduction of Dube, Dillenberger, Di Balsamo, and Antani. A person having ordinary skill in the art would have motivated to make this combination because when “memory is optimally used, workloads are run faster and with less disruption, and ultimately operation and performance of the virtual machines is improved” (Poothia ¶ [0027]).
Response to Arguments
In response to the amendments, examiner has withdrawn the 35 U.S.C. § 101 rejection of claims 1-4, 7-10, 14-16, and 20.
Applicant's arguments filed 04/22/2026 have been fully considered but they are not persuasive.
With regard to the 35 U.S.C. § 103 rejections, applicant argues “Di Balsamo, which recites "reduce a resource pool 410" at a high level of generality, does not specifically disclose reducing "a CPU quota of the first group of batch jobs."
Applicant is reminded that when arguing against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Examiner does not solely rely on Di Balsamo to teach the limitation. Rather, examiner relies upon the combination of Dube, Dillenberger, Di Balsamo, and Antani to fully teach the limitation. Di Balsamo teaches modifying a resource pool to bring a resource pool parameter between an upper and lower range to satisfy an SLA (¶ [0077] – [0078]). Di Balsamo ¶ [0032] teaches “The value of "Y" may be decreased for purposes of yielding system resource (e.g., a CPU) to other transactions.” Further Di Balsamo ¶ [0042] teaches “Once the CPM 104 identifies the transactions (e.g., LRTs) that are using resources needed by the OLT 120, it performs actions to speed up or slow down the processing related to the identified LRTs. The throttling of each LRT is achieved by selecting values for parameters "X" and "Y" of ALGORITHM 2.” Di Balsamo shows that resource pools can be changed to modify (reduce) a resource pool parameter. Antani teaches that an LRT’s CPU resources can be reduced. The references in combination completely teach “reducing a CPU quota of the first group of batch jobs.” Therefore, examiner finds applicant’s argument unpersuasive.
Applicant additionally argues “the allocation within Di Balsamo is not completed "based on the CPU limit of the one or more scheduled transaction workloads and based on the one or more scheduled transaction workloads not using the first table."”
Applicant is reminded that when arguing against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Examiner does not solely rely on Di Balsamo to teach the limitation. Rather, examiner relies upon the combination of Dube, Dillenberger, Di Balsamo, and Antani to fully teach the limitation. Di Balsamo ¶ [0078] teaches “If the resource pool parameter 608 is outside the resource range 602, then the resource pool may be modified to bring the resource pool parameter 608 within the resource range 602.” The modification (including deallocation) of resources is based on a CPU utilization limit. Therefore, the allocation within Di Balsamo is completed based on a CPU limit. Di Balsamo ¶ [0062] that “Jobs may include at least two types of workloads including batch jobs and transactional jobs.” Antani more explicitly teaches that the CPU limit is related to a scheduled transaction workload by stating “the WLM 102 determines whether the OLT 120 requires access to one or more transactional and/or system resources 116 being used by the LRT 110. For example, the determination can be made based on the number of CPU cycles used by the OLT 120. If the WLM 102 finds that there is a low CPU usage by OLT 120, then it concludes that no OLT 120 work is being done by TPS 100.” It is understood that to have a “low CPU usage” a limit is required, similar to the limit in Di Balsamo. Therefore, the combination of Di Balsamo and Antani teach “based on the CPU limit of the one or more scheduled transaction workloads.” Dillenberger teaches “based on the one or more scheduled transaction workloads not using the first table” by stating that OLTP workloads and batch workloads can be scheduled together if they do not use the same database table (see ¶ [0037], [0027], and [0047]). This is done so that OLTP workloads can be completely in a timely banner (¶ [0001] states “online transaction processing (sometimes referred to herein as "OLTP") work requires prompt response time.” Therefore, Dillenberger teaches scheduling based on database table access to meet a deadline, which would be the motivation to combine with Di Balsamo and Antani to reduce resources such that an OLT can meet a deadline. Therefore, examiner finds applicant’s argument unpersuasive.
Applicant argues that Antani’s “adjusting how many records are to be processed in each sub-transaction of the LRT(s) and/or increases/decreases the time period between commit operations of the LRT(s)” and “adjusting how many records are to be processed” are not “providing the reduced CPU quota to the one or more scheduled transaction workloads.”
Applicant is reminded that when arguing against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Examiner disagrees with applicant’s argument because Antani ¶ [0032] states “The value of "Y" may be decreased for purposes of yielding system resource (e.g., a CPU) to other transactions.” The term “other transactions” is understood to be the OLT needed resources in ¶ [0040]. Antani ¶ [0042] also states “Once the CPM 104 identifies the transactions (e.g., LRTs) that are using resources needed by the OLT 120, it performs actions to speed up or slow down the processing related to the identified LRTs. The throttling of each LRT is achieved by selecting values for parameters "X" and "Y" of ALGORITHM 2, and setting parameters "X" and "Y" equal to the respective selected values.” From these quotations, it is clear that CPU quota is being provided to the OLT. Additionally, it is the combination of Dube, Dillenberger, Di Balsamo, and Antani that teach the entire limitation. Applicant is reminded that Di Balsamo also teaches a “reduced CPU quota” and “transaction workloads” (¶ [0078] and [0062]). Examiner finds applicant’s arguments unpersuasive.
Applicant argues “There is no disclosure within Sampathkumar that relates to two different types of transactions (e.g., "a scheduled transaction workload" versus "batch jobs") not sharing the same table for the purpose of determining to reduce "a CPU quota of the first group of batch jobs."”)
Examiner responds that the 35 U.S.C. § 103 rejection does not rely on Sampathkumar to teach these features.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20070234365 A1
teaches
Computer Resource Management For Workloads Or Applications Based On Service Level Objectives
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 PETER L YUAN whose telephone number is (571)272-5737. The examiner can normally be reached Mon-Fri 7:30am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at 571-272-3338. 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.
/PETER LI YUAN/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights