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 .
This Office Action is in response to claims filed 07/28/2025.
Claims 1-6, 9-13, 16-18, and 20 are pending.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 6, 10, 11, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Spicer (US 2017/0063561 A1) in view of Rajadeva (US 2023/0102654 A1) in view of Dawson (US 2010/0313203 A1).
Regarding claim 1, Spicer teaches:
A computer program product, the computer program product being tangibly embodied on a non-transitory computer-readable storage medium and comprising instructions that, when executed by at least one computing device, are configured to cause the at least one computing device to: “Implementations may implemented as a computer program product, i.e., a non-transitory computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device ( e.g., a computer-readable medium, a tangible computer-readable medium), for processing by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. In some implementations, a non-transitory tangible computer-readable storage medium can be configured to store instructions that when executed cause a processor to perform a process.” [Spicer ¶ 76].
extract processor consumption within a first time interval “The information provided by the workload managers may include a most recent rolling average. In some implementations, the rolling average is a 4-hour-rolling-average (4HRA). The 4HRA is a rolling average of LPAR CPU consumption in millions of service units” [Spicer ¶ 25]. “The rolling average 240 is obtained from a workload manager and represents a rolling average of CPU consumption in e.g., MSUs for the billing entity…In some implementations, the workload manager refreshes the rolling average at regular intervals, for example every 10 seconds or every minute” [Spicer ¶ 39].
by a subset of processors of a plurality of processors of the at least one computing device, “…a mainframe computing system includes a central processor complex, a plurality of billing entities, a billing entity being a logical partition of the mainframe computing system or a group of logical partitions…” [Spicer ¶ 3 Examiner notes a logical partition (LPAR) is interpreted as a subset of the computing system resources including processors and thus, the billing entities are interpreted to encompass a plurality of processors].
the subset of processors providing a base capacity and a priority capacity; “The dynamic capping policy may include, for each billing entity identified in the policy, information from which to determine a millions of service unit (MSU) entitlement value and a cost entitlement value” [Spicer ¶ 4]. “The entitlement represents the maximum rolling average that a billing entity is entitled to, e.g., the number of MSUs that a billing entity may have as a rolling average without having to share MSUs” [Spicer ¶ 35]. “If low-importance work is not to be considered (705, No) the billing entity with the highest priority is selected from among the candidate entities. The priority may be assigned to each LPAR by the customer as part of the dynamic capping policy. Thus, the customer may adjust the effects of the policy by changing the priorities assigned to the billing entities in the dynamic capping policy. If only one entity has the highest priority (725, No), process 700 ends, having selected a favored entity” [Spicer ¶ 63 Examiner notes the MSU entitlement assigned to an LPAR of high priority is considered priority capacity]. “In this manner, the system provides extra MSUs to favored billing entities (e.g., LPARs or capacity groups) ahead of non-favored entities, ensuring maximum high importance throughput for the lowest possible cost, e.g., represented by the maximum MSU limit and the cost limit set by the customer in the dynamic capping policy” [Spicer ¶ 57 Examiner notes the MSU entitlement assigned to a non-favored LPAR is considered the base capacity].
update, based on the processor consumption, a rolling average of processor consumption of the subset of processors over a second time interval; “In some implementations, the rolling average is a 4-hour-rolling-average (4HRA). The 4HRA is a rolling average of LPAR CPU consumption in millions of service units. A service unit is a measure of CPU capacity (e.g., processing time)” [Spicer ¶ 25].
convert the rolling average to a consumption rate; “To determine the MLC, the mainframe operating system generates monthly reports that determine the customer's system usage (in MSU s) during every hour of the previous month using a rolling average (e.g., a 4-hour rolling average) recorded by each billing entity for the customer. The hourly usage metrics are then aggregated together to derive the total monthly, hourly peak utilization for the customer, which is used to calculate the bill for the customer.” [Spicer ¶ 1].
determine a consumption comparison of the consumption rate to the base capacity; “The system may determine whether the rolling average (consumption rate), as reported from a workload manager, for the selected billing entity is less than the entitlement value for the billing entity (405)” [Spicer ¶ 44]. “The system may repeat steps 405 to 420 for each billing entity identified in the dynamic capping policy (425, Yes). When all billing entities have been added to the entity pool or contributed to the service unit pool and cost pool (425, No), process 400 ends” [Spicer ¶ 46 Examiner notes when the comparison is made for a non-favored LPAR it is a comparison of the consumption rate to the base capacity].
allocate a workload of the at least one computing device using the subset of processors, based on the consumption comparison “The workload manager allocates processing time and other resources to work requested by application programs. In other words, the workload manager manages the scheduling of requested work on the physical processors… The workload manager uses a customer-defined workload service policy, e.g., stored in WLM policy files 146, to associate each request for work with a service class period and an importance level” [Spicer ¶ 23]. “The system may adjust the capacity limit of the favored entity using the service unit pool and cost pool (510). For example, the system may find the difference between the rolling average for the favored entity and the entitlement value of the favored entity (e.g., 4HRA-entitlement)” [Spicer ¶ 51].
…preserve the priority capacity for use by transactional jobs; “For example, if a first billing entity runs high importance work or runs a high-transaction work, the customer may decide that it is entitled to more MSUs than other billing entities” [Spicer ¶ 34].
Spicer fails to explicitly teach by constraining batch jobs to preserve the priority capacity and defer and process the batch jobs using the base capacity without consuming the priority capacity.
However, Rajadeva teaches:
by constraining (lower priority) batch jobs to preserve the priority capacity “In some embodiments, work may be prioritized into six levels of priority such that a level six priority workload takes priority over all tasks with a priority of level five priority or less and a level one priority workload may be the first workload displaced to make resources available for a pending workload of a higher priority. In such an embodiment, the relative displaceable capacity (base capacity) for a pending level six priority workload would include all of the free capacity in the system plus all of the capacity used for workloads of priority five or less. Similarly, the relative displaceable capacity for a pending level four priority workload would include all of the free capacity in the system plus all of the capacity used for workloads of priority three or less. The relativeness of the displaceable capacity depends on the priority of the workload pending deployment” [Rajadeva ¶ 26]. “To assign the pod 104, the scheduler 102 may displace (constrain) the BATLOW 160 workload if the pod 104 workload is of a higher priority than the BATLOW 160 workload, as shown in FIG. 1. Displacing the BATLOW 160 may include, for example, pausing, stopping, or re-allocating (e.g., moving to a different host) the BATLOW 160 work load. For example, the BATLOW 160 workload may be paused and/or canceled to await re-deployment and the pod 140 will be allocated the component displaceable capacity 144 of the second subsystem 140” [Rajadeva ¶ 44].
and defer and process the (lower-priority) batch jobs using the base capacity without consuming the priority capacity. “In another example, the system 200 may not have resources available to accommodate all workloads. The control plane 250 may identify a pod 246 is running a lower priority workload than the new workload, pause (defer) the pod 246, and use those resources to deploy the new workload” [Rajadeva ¶ 53]. “Displacing the BATLOW 160 may include, for example, pausing, stopping, or re-allocating (e.g., moving to a different host) the BATLOW 160 work load. For example, the BATLOW 160 workload may be paused and/or canceled to await re-deployment and the pod 140 will be allocated the component displaceable capacity 144 of the second subsystem 140” [Rajadeva ¶ 44]. “A workload may be considered displaceable only if a task awaiting resources is of a higher priority. For example, a workload with a moderate priority (e.g., a priority of 3) may be running on a host system; if a task with a low priority (e.g., a priority of 1) may be submitted to the system, the low priority task will wait for resources to become available whereas if a high priority task (e.g., a priority of 5) is submitted to the system, the moderate priority task may be paused such that the computational resources from the moderate priority task may be used for the high priority task” [Rajadeva ¶ 32].
Rajadeva is considered to be analogous to the claimed invention because it is in the same field of scheduling strategies for multiprogramming arrangements. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Spicer to incorporate the teachings of Rajadeva and include by constraining (lower priority) batch jobs to preserve the priority capacity and defer and process the (lower-priority) batch jobs using the base capacity without consuming the priority capacity. Doing so would allow for further optimization in workload scheduling considering different workload priority levels. “The present disclosure considers the optimization of scheduling container workloads into nodes hosted in virtual environments with co-resident workloads of various levels of priority sharing the same computing resources. Such optimizations may provide insights into selecting an optimal node” [Rajadeva ¶ 20].
Spicer in view of Rajadeva fails to explicitly teach by constraining batch jobs to preserve the priority capacity and process the transactional jobs using the priority capacity; and defer and process the batch jobs.
Spicer teaches process the transactional jobs using the (assigned) priority capacity; “The workload service policy enables the customer to assign work, e.g., batch jobs, online transactions, etc., with a service class, a service class period, an importance level, and an LPAR” [ Spicer ¶ 23]. “The entitlement represents the maximum rolling average that a billing entity is entitled to, e.g., the number of MSUs that a billing entity may have as a rolling average without having to share MSUs” [Spicer ¶ 35]. “For example, if a first billing entity runs high importance work or runs a high-transaction work, the customer may decide that it is entitled to more MSUs than other billing entities” [Spicer ¶ 3]. Spicer in view of Rajadeva fails to explicitly teach that the transactional jobs are given a priority capacity. However, Dawson teaches process the transactional jobs using the priority capacity. “Additionally, for example, if the EA tool 35 determines a transaction job (e.g., an OLAP/OLTP job) is above some critical level, e.g., a given transaction processing job is running at 70% of capacity and it typically only runs around 40% capacity (e.g., as determined by the HA tool 30), the scheduling tool 45 may delay a lower priority batch job until the transaction job drops below a predefined level” [Dawson ¶ 66 Examiner notes the transactional jobs are considered to have priority in that the batch jobs are lower priority].
Dawson further teaches:
by constraining batch jobs to preserve the priority capacity “Additionally, for example, if the EA tool 35 determines a transaction job (e.g., an OLAP/OLTP job) is above some critical level, e.g., a given transaction processing job is running at 70% of capacity and it typically only runs around 40% capacity (e.g., as determined by the HA tool 30), the scheduling tool 45 may delay a lower priority batch job until the transaction job drops below a predefined level” [Dawson ¶ 66].
and defer and process the batch jobs “Additionally, for example, if the EA tool 35 determines a transaction job (e.g., an OLAP/OLTP job) is above some critical level, e.g., a given transaction processing job is running at 70% of capacity and it typically only runs around 40% capacity (e.g., as determined by the HA tool 30), the scheduling tool 45 may delay a lower priority batch job until the transaction job drops below a predefined level” [Dawson ¶ 66].
Dawson is considered to be analogous to the claimed invention because it is in the same field of scheduling strategies for multiprogramming arrangements. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Spicer in view of Rajadeva to incorporate the teachings of Dawson and include constraining batch jobs to preserve the priority capacity and process the transactional jobs using the priority capacity; and defer and process the batch jobs. Doing so would allow for the system to maintain service level agreements of the transaction jobs. “According to further aspects of the invention, the Scheduling tool 45 is operable to invoke application job workload throttling whenever possible based on maintaining respective SLAs of current and pending processing jobs” [Dawson ¶ 66].
Regarding claim 2, Spicer in view of Rajadeva in view of Dawson teaches the computer program product of claim 1, as referenced above. Spicer further teaches:
wherein the at least one computing device includes at least one mainframe computing device, “A mainframe computing system comprising: a central processor complex; a plurality of billing entities…” [Spicer Claim 1].
and the subset of processors includes general purpose processors of a central processing complex of the at least one mainframe computing device, “Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer” [Spicer ¶ 78].
“a workload manager that schedules work requested by the plurality of billing entities on the central processor complex and tracks…” [Spicer Claim 1].
and remaining processors of the central processing complex include at least one special purpose processor. “Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer” [Spicer ¶ 78].
Regarding claim 6, Spicer in view of Rajadeva in view of Dawson teaches the computer program product of claim 1, as referenced above. Spicer further teaches wherein the instructions are further configured to cause the at least one computing device to: convert the rolling average to a consumption rate measured in millions of service units (MSUs) per hour. “To determine the MLC, the mainframe operating system generates monthly reports that determine the customer's system usage (in MSU s) during every hour of the previous month using a rolling average (e.g., a 4-hour rolling average) recorded by each billing entity for the customer. The hourly usage metrics are then aggregated together to derive the total monthly, hourly peak utilization for the customer, which is used to calculate the bill for the customer.” [Spicer ¶ 1].
Regarding claim 10, Spicer in view of Rajadeva in view of Dawson teaches the computer program product of claim 1, as referenced above. Spicer further teaches:
wherein the subset of processors includes general purpose processors of a central processing complex (CPC) of at least one mainframe computing device, “A mainframe computing system comprising: a central processor complex; a plurality of billing entities…” [Spicer Claim 1].
“Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer” [Spicer ¶ 78].
and remaining processors of the central processing complex include at least one special purpose processor, “Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer” [Spicer ¶ 78].
and further wherein the instructions are further configured to cause the at least one computing device to: query the CPC to determine the processor consumption. “…and a workload manager that schedules work requested by the plurality of billing entities on the central processor complex and tracks, by billing entity, a rolling average of millions of service units (MSUs)” [Spicer ¶ 3, Fig. 1].
Regarding claim 11, Spicer teaches:
A computer-implemented method, the method comprising: extracting processor consumption within a first time interval “The information provided by the workload managers may include a most recent rolling average. In some implementations, the rolling average is a 4-hour-rolling-average (4HRA). The 4HRA is a rolling average of LPAR CPU consumption in millions of service units” [Spicer ¶ 25]. “The rolling average 240 is obtained from a workload manager and represents a rolling average of CPU consumption in e.g., MSUs for the billing entity…In some implementations, the workload manager refreshes the rolling average at regular intervals, for example every 10 seconds or every minute” [Spicer ¶ 39].
by a subset of processors of a plurality of processors of at least one computing device, “…a mainframe computing system includes a central processor complex, a plurality of billing entities, a billing entity being a logical partition of the mainframe computing system or a group of logical partitions…” [Spicer ¶ 3 Examiner notes a logical partition (LPAR) is interpreted as a subset of the computing system resources including processors and thus, the billing entities are interpreted to encompass a plurality of processors].
the subset of processors providing a base capacity and a priority capacity; “The dynamic capping policy may include, for each billing entity identified in the policy, information from which to determine a millions of service unit (MSU) entitlement value and a cost entitlement value” [Spicer ¶ 4]. “The entitlement represents the maximum rolling average that a billing entity is entitled to, e.g., the number of MSUs that a billing entity may have as a rolling average without having to share MSUs” [Spicer ¶ 35]. “If low-importance work is not to be considered (705, No) the billing entity with the highest priority is selected from among the candidate entities. The priority may be assigned to each LPAR by the customer as part of the dynamic capping policy. Thus, the customer may adjust the effects of the policy by changing the priorities assigned to the billing entities in the dynamic capping policy. If only one entity has the highest priority (725, No), process 700 ends, having selected a favored entity” [Spicer ¶ 63 Examiner notes the MSU entitlement assigned to an LPAR of high priority is considered priority capacity]. “In this manner, the system provides extra MSUs to favored billing entities (e.g., LPARs or capacity groups) ahead of non-favored entities, ensuring maximum high importance throughput for the lowest possible cost, e.g., represented by the maximum MSU limit and the cost limit set by the customer in the dynamic capping policy” [Spicer ¶ 57 Examiner notes the MSU entitlement assigned to a non-favored LPAR is considered the base capacity].
updating, based on the processor consumption, a rolling average of processor consumption of the subset of processors over a second time interval; “In some implementations, the rolling average is a 4-hour-rolling-average (4HRA). The 4HRA is a rolling average of LPAR CPU consumption in millions of service units. A service unit is a measure of CPU capacity (e.g., processing time)” [Spicer ¶ 25].
Converting the rolling average to a consumption rate; “To determine the MLC, the mainframe operating system generates monthly reports that determine the customer's system usage (in MSU s) during every hour of the previous month using a rolling average (e.g., a 4-hour rolling average) recorded by each billing entity for the customer. The hourly usage metrics are then aggregated together to derive the total monthly, hourly peak utilization for the customer, which is used to calculate the bill for the customer.” [Spicer ¶ 1].
determining a consumption comparison of the consumption rate to the base capacity; “The system may determine whether the rolling average (consumption rate), as reported from a workload manager, for the selected billing entity is less than the entitlement value for the billing entity (405)” [Spicer ¶ 44]. “The system may repeat steps 405 to 420 for each billing entity identified in the dynamic capping policy (425, Yes). When all billing entities have been added to the entity pool or contributed to the service unit pool and cost pool (425, No), process 400 ends” [Spicer ¶ 46 Examiner notes when the comparison is made for a non-favored LPAR it is a comparison of the consumption rate to the base capacity].
allocating a workload of the at least one computing device using the subset of processors, based on the consumption comparison “The workload manager allocates processing time and other resources to work requested by application programs. In other words, the workload manager manages the scheduling of requested work on the physical processors… The workload manager uses a customer-defined workload service policy, e.g., stored in WLM policy files 146, to associate each request for work with a service class period and an importance level” [Spicer ¶ 23]. “The system may adjust the capacity limit of the favored entity using the service unit pool and cost pool (510). For example, the system may find the difference between the rolling average for the favored entity and the entitlement value of the favored entity (e.g., 4HRA-entitlement)” [Spicer ¶ 51].
…preserve the priority capacity for use by transactional jobs; “For example, if a first billing entity runs high importance work or runs a high-transaction work, the customer may decide that it is entitled to more MSUs than other billing entities” [Spicer ¶ 34].
Spicer fails to explicitly teach by constraining batch jobs to preserve the priority capacity and deferring and processing the batch jobs using the base capacity without consuming the priority capacity.
However, Rajadeva teaches:
by constraining (lower priority) batch jobs to preserve the priority capacity “In some embodiments, work may be prioritized into six levels of priority such that a level six priority workload takes priority over all tasks with a priority of level five priority or less and a level one priority workload may be the first workload displaced to make resources available for a pending workload of a higher priority. In such an embodiment, the relative displaceable capacity (base capacity) for a pending level six priority workload would include all of the free capacity in the system plus all of the capacity used for workloads of priority five or less. Similarly, the relative displaceable capacity for a pending level four priority workload would include all of the free capacity in the system plus all of the capacity used for workloads of priority three or less. The relativeness of the displaceable capacity depends on the priority of the workload pending deployment” [Rajadeva ¶ 26]. “To assign the pod 104, the scheduler 102 may displace (constrain) the BATLOW 160 workload if the pod 104 workload is of a higher priority than the BATLOW 160 workload, as shown in FIG. 1. Displacing the BATLOW 160 may include, for example, pausing, stopping, or re-allocating (e.g., moving to a different host) the BATLOW 160 work load. For example, the BATLOW 160 workload may be paused and/or canceled to await re-deployment and the pod 140 will be allocated the component displaceable capacity 144 of the second subsystem 140” [Rajadeva ¶ 44].
and deferring and processing the (lower-priority) batch jobs using the base capacity without consuming the priority capacity. “In another example, the system 200 may not have resources available to accommodate all workloads. The control plane 250 may identify a pod 246 is running a lower priority workload than the new workload, pause (defer) the pod 246, and use those resources to deploy the new workload” [Rajadeva ¶ 53]. “Displacing the BATLOW 160 may include, for example, pausing, stopping, or re-allocating (e.g., moving to a different host) the BATLOW 160 work load. For example, the BATLOW 160 workload may be paused and/or canceled to await re-deployment and the pod 140 will be allocated the component displaceable capacity 144 of the second subsystem 140” [Rajadeva ¶ 44]. “A workload may be considered displaceable only if a task awaiting resources is of a higher priority. For example, a workload with a moderate priority (e.g., a priority of 3) may be running on a host system; if a task with a low priority (e.g., a priority of 1) may be submitted to the system, the low priority task will wait for resources to become available whereas if a high priority task (e.g., a priority of 5) is submitted to the system, the moderate priority task may be paused such that the computational resources from the moderate priority task may be used for the high priority task” [Rajadeva ¶ 32].
Rajadeva is considered to be analogous to the claimed invention because it is in the same field of scheduling strategies for multiprogramming arrangements. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Spicer to incorporate the teachings of Rajadeva and include by constraining (lower priority) batch jobs to preserve the priority capacity and deferring and processing the (lower-priority) batch jobs using the base capacity without consuming the priority capacity. Doing so would allow for further optimization in workload scheduling considering different workload priority levels. “The present disclosure considers the optimization of scheduling container workloads into nodes hosted in virtual environments with co-resident workloads of various levels of priority sharing the same computing resources. Such optimizations may provide insights into selecting an optimal node” [Rajadeva ¶ 20].
Spicer in view of Rajadeva fails to explicitly teach by constraining batch jobs to preserve the priority capacity and processing the transactional jobs using the priority capacity; and deferring and processing the batch jobs.
Spicer teaches processing the transactional jobs using the (assigned) priority capacity; “The workload service policy enables the customer to assign work, e.g., batch jobs, online transactions, etc., with a service class, a service class period, an importance level, and an LPAR” [ Spicer ¶ 23]. “The entitlement represents the maximum rolling average that a billing entity is entitled to, e.g., the number of MSUs that a billing entity may have as a rolling average without having to share MSUs” [Spicer ¶ 35]. “For example, if a first billing entity runs high importance work or runs a high-transaction work, the customer may decide that it is entitled to more MSUs than other billing entities” [Spicer ¶ 3]. Spicer in view of Rajadeva fails to explicitly teach that the transactional jobs are given a priority capacity. However, Dawson teaches processing the transactional jobs using the priority capacity. “Additionally, for example, if the EA tool 35 determines a transaction job (e.g., an OLAP/OLTP job) is above some critical level, e.g., a given transaction processing job is running at 70% of capacity and it typically only runs around 40% capacity (e.g., as determined by the HA tool 30), the scheduling tool 45 may delay a lower priority batch job until the transaction job drops below a predefined level” [Dawson ¶ 66 Examiner notes the transactional jobs are considered to have priority in that the batch jobs are lower priority].
Dawson further teaches:
However, Dawson teaches:
by constraining batch jobs to preserve the priority capacity “Additionally, for example, if the EA tool 35 determines a transaction job (e.g., an OLAP/OLTP job) is above some critical level, e.g., a given transaction processing job is running at 70% of capacity and it typically only runs around 40% capacity (e.g., as determined by the HA tool 30), the scheduling tool 45 may delay a lower priority batch job until the transaction job drops below a predefined level” [Dawson ¶ 66].
and deferring and processing the batch jobs “Additionally, for example, if the EA tool 35 determines a transaction job (e.g., an OLAP/OLTP job) is above some critical level, e.g., a given transaction processing job is running at 70% of capacity and it typically only runs around 40% capacity (e.g., as determined by the HA tool 30), the scheduling tool 45 may delay a lower priority batch job until the transaction job drops below a predefined level” [Dawson ¶ 66].
Dawson is considered to be analogous to the claimed invention because it is in the same field of scheduling strategies for multiprogramming arrangements. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Spicer in view of Rajadeva to incorporate the teachings of Dawson and include constraining batch jobs to preserve the priority capacity and processing the transactional jobs using the priority capacity; and deferring and processing the batch jobs. Doing so would allow for the system to maintain service level agreements of the transaction jobs. “According to further aspects of the invention, the Scheduling tool 45 is operable to invoke application job workload throttling whenever possible based on maintaining respective SLAs of current and pending processing jobs” [Dawson ¶ 66].
Regarding claim 12, Spicer in view of Rajadeva in view of Dawson teaches the method of claim 11, as referenced above. Spicer further teaches:
wherein the subset of processors includes general purpose processors “Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer” [Spicer ¶ 78].
of a central processing complex of a mainframe system, “A mainframe computing system comprising: a central processor complex; a plurality of billing entities…” [Spicer Claim 1].
and remaining processors of the central processing complex include at least one special purpose processor. “Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer” [Spicer ¶ 78].
Regarding claim 17, Spicer in view of Rajadeva in view of Dawson teaches the method of claim 11, as referenced above. Spicer further teaches:
wherein the subset of processors includes general purpose processors of a central processing complex (CPC) of at least one mainframe computing device, “A mainframe computing system comprising: a central processor complex; a plurality of billing entities…” [Spicer Claim 1]. “Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer” [Spicer ¶ 78].
and remaining processors of the central processing complex include at least one special purpose processor, “Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer” [Spicer ¶ 78].
the method further comprising: querying the CPC to determine the processor consumption. “…and a workload manager that schedules work requested by the plurality of billing entities on the central processor complex and tracks, by billing entity, a rolling average of millions of service units (MSUs)” [Spicer ¶ 3, Fig. 1].
Regarding claim 18, Spicer teaches:
A mainframe system comprising: at least one memory including instructions; and at least one processor that is operably coupled to the at least one memory and that is arranged and configured to execute instructions that, when executed, cause the at least one processor to: “Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data.” [Spicer ¶ 78].
extract processor consumption within a first time interval “The information provided by the workload managers may include a most recent rolling average. In some implementations, the rolling average is a 4-hour-rolling-average (4HRA). The 4HRA is a rolling average of LPAR CPU consumption in millions of service units” [Spicer ¶ 25]. “The rolling average 240 is obtained from a workload manager and represents a rolling average of CPU consumption in e.g., MSUs for the billing entity…In some implementations, the workload manager refreshes the rolling average at regular intervals, for example every 10 seconds or every minute” [Spicer ¶ 39].
by a subset of processors of a plurality of processors of the mainframe system, “…a mainframe computing system includes a central processor complex, a plurality of billing entities, a billing entity being a logical partition of the mainframe computing system or a group of logical partitions…” [Spicer ¶ 3 Examiner notes a logical partition (LPAR) is interpreted as a subset of the computing system resources including processors and thus, the billing entities are interpreted to encompass a plurality of processors].
the subset of processors providing a base capacity and a priority capacity; “The dynamic capping policy may include, for each billing entity identified in the policy, information from which to determine a millions of service unit (MSU) entitlement value and a cost entitlement value” [Spicer ¶ 4]. “The entitlement represents the maximum rolling average that a billing entity is entitled to, e.g., the number of MSUs that a billing entity may have as a rolling average without having to share MSUs” [Spicer ¶ 35]. “If low-importance work is not to be considered (705, No) the billing entity with the highest priority is selected from among the candidate entities. The priority may be assigned to each LPAR by the customer as part of the dynamic capping policy. Thus, the customer may adjust the effects of the policy by changing the priorities assigned to the billing entities in the dynamic capping policy. If only one entity has the highest priority (725, No), process 700 ends, having selected a favored entity” [Spicer ¶ 63 Examiner notes the MSU entitlement assigned to an LPAR of high priority is considered priority capacity]. “In this manner, the system provides extra MSUs to favored billing entities (e.g., LPARs or capacity groups) ahead of non-favored entities, ensuring maximum high importance throughput for the lowest possible cost, e.g., represented by the maximum MSU limit and the cost limit set by the customer in the dynamic capping policy” [Spicer ¶ 57 Examiner notes the MSU entitlement assigned to a non-favored LPAR is considered the base capacity].
update, based on the processor consumption, a rolling average of processor consumption of the subset of processors over a second time interval; “In some implementations, the rolling average is a 4-hour-rolling-average (4HRA). The 4HRA is a rolling average of LPAR CPU consumption in millions of service units. A service unit is a measure of CPU capacity (e.g., processing time)” [Spicer ¶ 25].
convert the rolling average to a consumption rate; “To determine the MLC, the mainframe operating system generates monthly reports that determine the customer's system usage (in MSU s) during every hour of the previous month using a rolling average (e.g., a 4-hour rolling average) recorded by each billing entity for the customer. The hourly usage metrics are then aggregated together to derive the total monthly, hourly peak utilization for the customer, which is used to calculate the bill for the customer.” [Spicer ¶ 1].
determine a consumption comparison of the consumption rate to the base capacity; “The system may determine whether the rolling average (consumption rate), as reported from a workload manager, for the selected billing entity is less than the entitlement value for the billing entity (405)” [Spicer ¶ 44]. “The system may repeat steps 405 to 420 for each billing entity identified in the dynamic capping policy (425, Yes). When all billing entities have been added to the entity pool or contributed to the service unit pool and cost pool (425, No), process 400 ends” [Spicer ¶ 46 Examiner notes when the comparison is made for a non-favored LPAR it is a comparison of the consumption rate to the base capacity].
allocate a workload of the mainframe system using the subset of processors, based on the consumption comparison “The workload manager allocates processing time and other resources to work requested by application programs. In other words, the workload manager manages the scheduling of requested work on the physical processors… The workload manager uses a customer-defined workload service policy, e.g., stored in WLM policy files 146, to associate each request for work with a service class period and an importance level” [Spicer ¶ 23]. “The system may adjust the capacity limit of the favored entity using the service unit pool and cost pool (510). For example, the system may find the difference between the rolling average for the favored entity and the entitlement value of the favored entity (e.g., 4HRA-entitlement)” [Spicer ¶ 51].
…preserve the priority capacity for use by transactional jobs; “For example, if a first billing entity runs high importance work or runs a high-transaction work, the customer may decide that it is entitled to more MSUs than other billing entities” [Spicer ¶ 34].
Spicer fails to explicitly teach by constraining batch jobs to preserve the priority capacity and defer and process the batch jobs using the base capacity without consuming the priority capacity.
However, Rajadeva teaches:
by constraining (lower priority) batch jobs to preserve the priority capacity “In some embodiments, work may be prioritized into six levels of priority such that a level six priority workload takes priority over all tasks with a priority of level five priority or less and a level one priority workload may be the first workload displaced to make resources available for a pending workload of a higher priority. In such an embodiment, the relative displaceable capacity (base capacity) for a pending level six priority workload would include all of the free capacity in the system plus all of the capacity used for workloads of priority five or less. Similarly, the relative displaceable capacity for a pending level four priority workload would include all of the free capacity in the system plus all of the capacity used for workloads of priority three or less. The relativeness of the displaceable capacity depends on the priority of the workload pending deployment” [Rajadeva ¶ 26]. “To assign the pod 104, the scheduler 102 may displace (constrain) the BATLOW 160 workload if the pod 104 workload is of a higher priority than the BATLOW 160 workload, as shown in FIG. 1. Displacing the BATLOW 160 may include, for example, pausing, stopping, or re-allocating (e.g., moving to a different host) the BATLOW 160 work load. For example, the BATLOW 160 workload may be paused and/or canceled to await re-deployment and the pod 140 will be allocated the component displaceable capacity 144 of the second subsystem 140” [Rajadeva ¶ 44].
and defer and process the (lower-priority) batch jobs using the base capacity without consuming the priority capacity. “In another example, the system 200 may not have resources available to accommodate all workloads. The control plane 250 may identify a pod 246 is running a lower priority workload than the new workload, pause (defer) the pod 246, and use those resources to deploy the new workload” [Rajadeva ¶ 53]. “Displacing the BATLOW 160 may include, for example, pausing, stopping, or re-allocating (e.g., moving to a different host) the BATLOW 160 work load. For example, the BATLOW 160 workload may be paused and/or canceled to await re-deployment and the pod 140 will be allocated the component displaceable capacity 144 of the second subsystem 140” [Rajadeva ¶ 44]. “A workload may be considered displaceable only if a task awaiting resources is of a higher priority. For example, a workload with a moderate priority (e.g., a priority of 3) may be running on a host system; if a task with a low priority (e.g., a priority of 1) may be submitted to the system, the low priority task will wait for resources to become available whereas if a high priority task (e.g., a priority of 5) is submitted to the system, the moderate priority task may be paused such that the computational resources from the moderate priority task may be used for the high priority task” [Rajadeva ¶ 32].
Rajadeva is considered to be analogous to the claimed invention because it is in the same field of scheduling strategies for multiprogramming arrangements. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Spicer to incorporate the teachings of Rajadeva and include by constraining (lower priority) batch jobs to preserve the priority capacity and defer and process the (lower-priority) batch jobs using the base capacity without consuming the priority capacity. Doing so would allow for further optimization in workload scheduling considering different workload priority levels. “The present disclosure considers the optimization of scheduling container workloads into nodes hosted in virtual environments with co-resident workloads of various levels of priority sharing the same computing resources. Such optimizations may provide insights into selecting an optimal node” [Rajadeva ¶ 20].
Spicer in view of Rajadeva fails to explicitly teach by constraining batch jobs to preserve the priority capacity and process the transactional jobs using the priority capacity; and defer and process the batch jobs.
Spicer teaches process the transactional jobs using the (assigned) priority capacity; “The workload service policy enables the customer to assign work, e.g., batch jobs, online transactions, etc., with a service class, a service class period, an importance level, and an LPAR” [ Spicer ¶ 23]. “The entitlement represents the maximum rolling average that a billing entity is entitled to, e.g., the number of MSUs that a billing entity may have as a rolling average without having to share MSUs” [Spicer ¶ 35]. “For example, if a first billing entity runs high importance work or runs a high-transaction work, the customer may decide that it is entitled to more MSUs than other billing entities” [Spicer ¶ 3]. Spicer in view of Rajadeva fails to explicitly teach that the transactional jobs are given a priority capacity. However, Dawson teaches process the transactional jobs using the priority capacity. “Additionally, for example, if the EA tool 35 determines a transaction job (e.g., an OLAP/OLTP job) is above some critical level, e.g., a given transaction processing job is running at 70% of capacity and it typically only runs around 40% capacity (e.g., as determined by the HA tool 30), the scheduling tool 45 may delay a lower priority batch job until the transaction job drops below a predefined level” [Dawson ¶ 66 Examiner notes the transactional jobs are considered to have priority in that the batch jobs are lower priority].
Dawson further teaches:
by constraining batch jobs to preserve the priority capacity “Additionally, for example, if the EA tool 35 determines a transaction job (e.g., an OLAP/OLTP job) is above some critical level, e.g., a given transaction processing job is running at 70% of capacity and it typically only runs around 40% capacity (e.g., as determined by the HA tool 30), the scheduling tool 45 may delay a lower priority batch job until the transaction job drops below a predefined level” [Dawson ¶ 66].
and defer and process the batch jobs “Additionally, for example, if the EA tool 35 determines a transaction job (e.g., an OLAP/OLTP job) is above some critical level, e.g., a given transaction processing job is running at 70% of capacity and it typically only runs around 40% capacity (e.g., as determined by the HA tool 30), the scheduling tool 45 may delay a lower priority batch job until the transaction job drops below a predefined level” [Dawson ¶ 66].
Dawson is considered to be analogous to the claimed invention because it is in the same field of scheduling strategies for multiprogramming arrangements. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Spicer in view of Rajadeva to incorporate the teachings of Dawson and include constraining batch jobs to preserve the priority capacity and process the transactional jobs using the priority capacity; and defer and process the batch jobs. Doing so would allow for the system to maintain service level agreements of the transaction jobs. “According to further aspects of the invention, the Scheduling tool 45 is operable to invoke application job workload throttling whenever possible based on maintaining respective SLAs of current and pending processing jobs” [Dawson ¶ 66].
Claims 3 and 13, are rejected under 35 U.S.C. 103 as being unpatentable over Spicer (US 2017/0063561 A1) in view of Rajadeva (US 2023/0102654 A1) in view of Dawson (US 2010/0313203 A1) in view of Groetzner (US 2008/0082983 A1).
Regarding claim 3, Spicer in view of Rajadeva in view of Dawson teaches the computer program product of claim 2, as referenced above. Spicer further teaches:
wherein the instructions are further configured to cause the at least one computing device to: determine total processor consumption of the central processing complex; and “a dynamic capping master that monitors and adjusts the respective capacity limits of the subset of the plurality of billing entities, wherein the workload manager schedules work within the respective capacity limits so that the central processor complex executes the work without exceeding the maximum cost limit and the MSU limit…” [Spicer Claim 1 Examiner notes that the total processor consumption of the central processing complex must be determined in order to determine that it has not exceeded the MSU limit].
Spicer in view of Rajadeva in view of Dawson fails to explicitly teach extract the processor consumption by the general purpose processors from the total processor consumption.
However, Groetzner teaches extract the processor consumption by the general purpose processors from the total processor consumption. “…a workload manager usually offers a monitoring interface that provides data describing the activity of workloads such as resource consumption, performance indicators, and reasons why work was delayed” [Groetzner ¶ 11]. “In step 200, capacity provisioning manager 5 monitors the information provided by the workload manager 3” [Groetzner ¶ 64] “The provisioning manager checks first whether the operating system could consume additional processors in step 500…Then the physical utilization of the currently active zIIP processors is checked in step 520…The method is similarly applicable to regular processors (i.e. CPs), by replacing check 550” [Groetzner ¶ 66 Examiner notes checking whether the system could consume additional processors is inter