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 .
Claims 1-20 are pending in this application.
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-2, 4, 6, 8, 10-12, 14-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gibson et al. (US Pub. No. 2021/0374319 A1 hereinafter Gibson) in view of Smith et al. (US Pub. No. 2015/0089511 A1 hereinafter Smith).
As per claim 1, Gibson teaches a computer readable storage medium having instructions (¶ [0058], “The systems, methods, devices, and logic described above, including the compute engines 101, 102, and 103 as well as the dynamic resource balancing engine 110, may be implemented in many different ways in many different combinations of hardware, logic, circuitry, and executable instructions stored on a machine-readable medium.”) that when executed perform a method comprising: a plurality of parameters for EDA (electronic design automation) jobs running in a compute system (¶ [0014], “In particular, the dynamic resource allocation features (also referred to as dynamic resource balancing features) described herein may provide specific criteria and mechanisms by which computing resources can be dynamically distributed during execution of EDA processes and underlying EDA operations. The various dynamic load balancing features described herein may be specific to EDA processes for circuit design, and example load balancing criteria include EDA operation-based resource reallocations and idle-based resource reallocations (e.g., at execution tails of EDA operations).” ¶ [0020], “As described in greater detail herein, the computing system 100 may dynamically balance computing resources assigned to different compute engines according to various balancing criteria. In doing so, the computing system 100 may increase computational efficiency by reallocating computing resources (e.g., physical CPUs, memory, or any other computational resource used for operation execution) according to a priority of EDA operations, idle compute engines, or various other factors. Such dynamic resource allocation and balancing may be performed by a dynamic resource balancing engine 110, e.g., as shown in FIG. 1.” See also para. 0028.); selecting some of the jobs for a compute resource upgrade based on the parameters (¶ [0022]-[0023], “As used herein, a computing resource may include any physical or logical resource that is used for execution of an EDA operation. Computing resources may thus include physical CPUs (including remote resources), network adapters, I/O bandwidth, memory (physical or virtual), scheduling slots for use of particular computational elements, etc. In operation, the dynamic resource balancing engine 110 may also reallocate a particular computing resource allocated to a first compute engine (e.g., compute engine 101) based on an operation priority of an EDA operation performed by a second compute engine (e.g., compute engine 102), an idle indicator for the first compute engine, or a combination of both. These and other dynamic resource balancing features are described in greater detail next. Various balancing criteria are described specific to execution of EDA applications, including computing resource reallocations based on specific EDA operations or operation types, idle-based reallocations (e.g., at EDA operation tails), and others.”); and providing the selected jobs with additional compute resources before they have finished running (¶ [0032]-[0035], “During execution of the EDA process, the dynamic resource balancing engine 110 may provision additional computing resources to any compute engine(s) executing EDA operations in the critical execution path of an EDA process. To do so, the dynamic resource balancing engine 110 may identify a particular compute engine performing an EDA operation on a critical execution path (e.g., of an EDA process) and reallocate computing resources assigned to a different compute engine executing an EDA operation that is not on the critical execution path…Responsive to a determination that the compute engine 103 (in this example) is executing an EDA operation on a critical execution path, the dynamic resource balancing engine 110 may reallocate computing resources from other compute engines to the compute engine 103. In the example shown in FIG. 3, the dynamic resource balancing engine 110 sends a reallocation instruction 240 to the compute engine 102, in response to which the computing engine 102 may release computing resources for acquisition/use by compute engine 103. FIG. 2 illustrates the reallocated computing resources 250, which may be released by the compute engine 102 and acquired by the compute engine 103 responsive to a reallocation instruction 240 issued by the dynamic resource balancing engine 110. In some implementations, the dynamic resource balancing engine 110 may reallocate computing resources based on specific EDA operation types. As EDA operations may vary in computational complexity, the dynamic resource balancing engine 110 may prioritize EDA operations with higher computational complexities, latencies, or timing requirements. Such operation priorities may be specified through operation priority indicator messages sent from compute engines (e.g., as part of the operation priority indicator 230), which may specify a prioritized EDA operation type being executed by a compute engine. The dynamic resource balancing engine 110 may issue reallocation instructions 240 responsive to receiving the operation priority indicator 230 from the compute engine 103 indicative of a high-priority EDA operation being executed by the compute engine 103.”).
Gibson fails to explicitly teach monitoring a plurality of parameters associated with EDA jobs.
However, Smith teaches monitoring a plurality of parameters for EDA jobs running in a compute system and selecting some of the jobs for a compute resource upgrade based on the monitored parameters (¶ [0036], “For another example, the task control system can adaptively assign processor cores to achieve the shortest turnaround time for a particular multi-scale simulation approach when results for a set of different input conditions are requested. In this case, the task control system can assign a small amount of compute resources to many short-running tasks while reserving a larger amount of compute resources for the longer-running tasks. Also, while the task control system monitors the compute time of each task of each split, it can dynamically adjust the amount of compute resources as other tasks complete. In addition, as the amount of compute resources is increased for a particular task, the task control system can dynamically determine the effectiveness of the additional compute resources in reducing the runtime of the task and for tasks that are not helped by the additional compute resources, the compute resource can be re-assigned to other tasks. Additionally, if the results of some tasks or approaches indicate that other materials cases slated for evaluation are not likely to have desired results, then the system can proactively terminate the execution of a task or prevent its execution altogether.”).
Gibson and Smith are considered to be analogous to the claimed invention because they are in the same field of task allocation / resource management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gibson with the task monitoring functionality of Smith to arrive at the claimed invention. The motivation to modify Gibson with the teachings of Smith is that monitoring currently executing tasks and dynamically upgrading their resources based on the monitoring results in an optimized turnaround time for circuit simulation (See Smith para. 0033.).
As per claim 2, Gibson and Smith teach the storage medium of claim 1. Smith also teaches wherein the plurality of parameters include a turn-around-time (TAT) gain parameter (¶ [0033], “FIG. 2 illustrates a flow chart of a method for optimizing turnaround time for a multi-scale simulation, such as the multi-scale simulation illustrated in FIG. 1. The method automatically and adaptively allocates computing resources for the multi-scale simulation. At step 202, a task control system initiates execution of one or more tasks of one or more approaches of a multi-scale simulation…Each task of the approaches of the multi-scale simulation is represented by a node in the directed graph data structure. The task control system performs the method for optimizing turnaround time for the multi-scale simulation by traversing the directed graph data structure.” ¶ [0035]-[0036], “At step 206, the task control system automatically assigns processor cores to a task based on its required computing resources. For example, the task control system can assign more processor cores to a task requiring a higher amount of computing resources. The task control system can adaptively assign processor cores to achieve the shortest turnaround time for the multi-scale simulation. The task control system can dynamically allocate computing resources by repeating the steps 202, 204, or 206 when appropriate. The task control system can adaptively assign processor cores such that some partial results can be provided first before all simulations are completed…For another example, the task control system can adaptively assign processor cores to achieve the shortest turnaround time for a particular multi-scale simulation approach when results for a set of different input conditions are requested…Also, while the task control system monitors the compute time of each task of each split, it can dynamically adjust the amount of compute resources as other tasks complete. In addition, as the amount of compute resources is increased for a particular task, the task control system can dynamically determine the effectiveness of the additional compute resources in reducing the runtime of the task and for tasks that are not helped by the additional compute resource, the compute resource can be re-assigned to other tasks”).
Refer to claim 1 for reason to combine.
As per claim 4, Gibson and Smith teach the storage medium of claim 2. Gibson teaches wherein the monitored parameters include a runtime progress parameter (¶ [0054], “In response to the completion of a particular task, the task control system can re-allocate available processor cores to at least some of the pending not-yet-executing tasks in accordance with time required to complete the tasks and constrained by the task dependencies, and to initiate execution of the tasks on allocated cores. The task control system can calculate and update time-to-completion of each task or type of task. In re-allocation of processor cores (step 812), the task control system can take into account the (updated) expected time-to-completion of each task.”).
As per claim 6, Gibson and Smith teach the storage medium of claim 1. Smith teaches wherein selecting includes filtering jobs based on whether they satisfy a remaining runtime threshold (¶ [0054], “In response to the completion of a particular task, the task control system can re-allocate available processor cores to at least some of the pending not-yet-executing tasks in accordance with time required to complete the tasks and constrained by the task dependencies, and to initiate execution of the tasks on allocated cores. The task control system can calculate and update time-to-completion of each task or type of task. In re-allocation of processor cores (step 812), the task control system can take into account the (updated) expected time-to-completion of each task.”).
Refer to claim 1 for reason to combine.
As per claim 8, Gibson and Smith teach the storage medium of claim 1. Gibson teaches wherein providing the selected jobs with additional compute resources includes downgrading selected other running jobs and re-allocating some of their resources to jobs selected for resource upgrade (¶ [0022], “In operation, the dynamic resource balancing engine 110 may allocate computing resources to a set of compute engines, such as the compute engines 101, 102, and 103. As used herein, a computing resource may include any physical or logical resource that used for execution of an EDA operation. Computing resources may thus include physical CPUs (including remote resources), network adapters, I/O bandwidth, memory (physical or virtual), scheduling slots for use of particular computational elements, etc. In operation, the dynamic resource balancing engine 110 may also reallocate a particular computing resource allocated to a first compute engine (e.g., compute engine 101) based on an operation priority of an EDA operation performed by a second compute engine (e.g., compute engine 102), an idle indicator for the first compute engine, or a combination of both.” See also para. 0028-0029.).
As per claim 10, Gibson teaches a computer readable storage medium, having instructions (¶ [0058], “The systems, methods, devices, and logic described above, including the compute engines 101, 102, and 103 as well as the dynamic resource balancing engine 110, may be implemented in many different ways in many different combinations of hardware, logic, circuitry, and executable instructions stored on a machine-readable medium.”) that when executed perform a method, comprising: in response to inputs from a user, generating an EDA tool job for execution on a compute system (¶ [0019], “EDA applications may be executed in various type of computing environments, including in whole or in part via cloud computing. As such, the computing system 100 (including the compute engines 101, 102, and 103) may be implemented in part via a public cloud, private cloud, or hybrid cloud. Additionally or alternative, EDA applications may be executed via a software-as-a-service (“SaaS”) distribution model (whether in whole or in part), and the computing resources that comprise the computing system 100 may be off-premise (e.g., with regards to EDA application users), on-premise, or a combination of both. The various EDA features described herein may be implemented as part of a SaaS distribution model or via cloud computing implementations.”); dividing the job into sequential stages (¶ [0028], “EDA operations may vary in computational complexity and some EDA operations may use (e.g., consume) outputs generated from other EDA operations. That is, EDA operations may have different timing, computing, or dependency requirements. To address such differences in requirements and complexity, the dynamic resource balancing engine 110 may reallocate resources among compute engines to prioritize execution of selected EDA operations.” ¶ [0038], “As yet another example of EDA operation-based priority, the dynamic resource balancing engine 110 may prioritize EDA operations with reduced-parallelization capability. In some implementations, compute engines may instantiate other compute engines to perform a sub-portion of EDA operations. In such cases, the compute engine may act, in effect, as a command server to initiate execution threads (e.g., through acquisition of local or remote computing resources) to process EDA operations or portions thereof.”); providing in the job one or more features that are used to enable the compute system to re-allocate compute resources while the job is running (¶ [0032]-[0035], “During execution of the EDA process, the dynamic resource balancing engine 110 may provision additional computing resources to any compute engine(s) executing EDA operations in the critical execution path of an EDA process. To do so, the dynamic resource balancing engine 110 may identify a particular compute engine performing an EDA operation on a critical execution path (e.g., of an EDA process) and reallocate computing resources assigned to a different compute engine executing an EDA operation that is not on the critical execution path…Responsive to a determination that the compute engine 103 (in this example) is executing an EDA operation on a critical execution path, the dynamic resource balancing engine 110 may reallocate computing resources from other compute engines to the compute engine 103. In the example shown in FIG. 3, the dynamic resource balancing engine 110 sends a reallocation instruction 240 to the compute engine 102, in response to which the computing engine 102 may release computing resources for acquisition/use by compute engine 103. FIG. 2 illustrates the reallocated computing resources 250, which may be released by the compute engine 102 and acquired by the compute engine 103 responsive to a reallocation instruction 240 issued by the dynamic resource balancing engine 110. In some implementations, the dynamic resource balancing engine 110 may reallocate computing resources based on specific EDA operation types. As EDA operations may vary in computational complexity, the dynamic resource balancing engine 110 may prioritize EDA operations with higher computational complexities, latencies, or timing requirements. Such operation priorities may be specified through operation priority indicator messages sent from compute engines (e.g., as part of the operation priority indicator 230), which may specify a prioritized EDA operation type being executed by a compute engine. The dynamic resource balancing engine 110 may issue reallocation instructions 240 responsive to receiving the operation priority indicator 230 from the compute engine 103 indicative of a high-priority EDA operation being executed by the compute engine 103.”).
Gibson fails to teach indicating transitions between stages and re-allocating resources for a next stage.
However, Smith teaches providing in the job one or more features to indicate to the compute system transitions between the stages to enable the compute system to re-allocate compute resources for a next stage while the job is running (¶ [0051], “As used herein, a "pending" task includes both tasks which have begun execution but have not yet completed, as well as tasks which have not yet begun execution. If any unpromising tasks are determined, the task control system can terminate any that are already executing, or prune the unpromising tasks that are not yet started (step 818). Not every task or sub-task causes re-allocation of processor cores after the task or sub-task completes. In one embodiment, the task control system only re-allocates processor cores after a TCAD task completes.”).
Gibson and Smith are considered to be analogous to the claimed invention because they are in the same field of task allocation / resource management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gibson with the reallocating resource between job stages functionality of Smith to arrive at the claimed invention. The motivation to modify Gibson with the teachings of Smith is that dynamically upgrading resources between job stages results in an optimized turnaround time for circuit simulation (See Smith para. 0033.).
As per claim 11, Gibson and Smith teach the storage medium of claim 10. Gibson teaches wherein the job is configured to expose to the compute system operating parameters to inform the compute system for re-allocating the compute resources (¶ [0014], “In particular, the dynamic resource allocation features (also referred to as dynamic resource balancing features) described herein may provide specific criteria and mechanisms by which computing resources can be dynamically distributed during execution of EDA processes and underlying EDA operations. The various dynamic load balancing features described herein may be specific to EDA processes for circuit design, and example load balancing criteria include EDA operation-based resource reallocations and idle-based resource reallocations (e.g., at execution tails of EDA operations).” ¶ [0020], “As described in greater detail herein, the computing system 100 may dynamically balance computing resources assigned to different compute engines according to various balancing criteria. In doing so, the computing system 100 may increase computational efficiency by reallocating computing resources (e.g., physical CPUs, memory, or any other computational resource used for operation execution) according to a priority of EDA operations, idle compute engines, or various other factors. Such dynamic resource allocation and balancing may be performed by a dynamic resource balancing engine 110, e.g., as shown in FIG. 1.” See also para. 0028.).
As per claim 12, Gibson and Smith teach the storage medium of claim 11. Gibson teaches wherein the parameters include core and memory parameters (¶ [0020], “As described in greater detail herein, the computing system 100 may dynamically balance computing resources assigned to different compute engines according to various balancing criteria. In doing so, the computing system 100 may increase computational efficiency by reallocating computing resources (e.g., physical CPUs, memory, or any other computational resource used for operation execution) according to a priority of EDA operations, idle compute engines, or various other factors. Such dynamic resource allocation and balancing may be performed by a dynamic resource balancing engine 110, e.g., as shown in FIG. 1.” ¶ [0045]-[0047], “A scenario may occur when multiple command compute engines reach the execution tail of EDA processes, during which the dynamic resource balancing engine 110 may reallocate idle computing resources to other compute engines to increase computational efficiency. In that regard, the dynamic resource balancing engine 110 may increase the overall utilization of computing resources in a computing environment, particularly during the “tail” of EDA operation execution. In operation, the dynamic resource balancing engine 110 may identify idle or unused computing resources during an EDA operation tail in various ways. In some implementations, the dynamic resource balancing engine 110 polls the various compute engines of a computing system to determine resource utilization rates. Such polling may occur at periodic or irregular (e.g., user triggered) times. As another example, the compute engines themselves may communicate idle indicators to alert the dynamic resource balancing engine 110 of idle computing resources of a computing engine. Examples of idle indicators are illustrated in FIG. 3. In FIG. 3, the compute engine 101 sends an idle indicator 310 to the dynamic resource balancing engine 110. The idle indicator 310 may take the form of any communication that indicates a compute engine has idle/unused computing resources. In some instances, the idle indicator 310 may specify the specific computing resources allocated to the compute engine 101 that are unused or a utilization percentage (e.g., 60% utilization rate, which may indicate 40% of assigned computing resources can be reallocated).”).
As per claim 14, Gibson and Smith teach the storage medium of claim 10. Gibson teaches wherein the job is executable using multiple threads on multiple cores (¶ [0018], “Each compute engine may be implemented as a combination of hardware and software, and may thus include physical computing resources (e.g., CPUs, memory, network resources, etc.) and processor-executable instructions (e.g., workflow processes, instruction scheduling logic, resource acquisition or thread activation instructions, etc.) to support EDA computations. In operation, the compute engines may operate in parallel, for example each serving as command servers that perform EDA operations on specific portions of an IC design or perform specific sets of EDA operations to provide parallelism and operation-level concurrency in EDA process execution. For example, the compute engines 101, 102 and 103 shown in FIG. 1 may perform EDA operations on a hierarchical dataset representative of an IC design.” See also para. 0038.).
As per claim 15, Gibson teaches a computer system comprising: at least one computing device having core and memory resources (¶ [0018], “Each compute engine may be implemented as a combination of hardware and software, and may thus include physical computing resources (e.g., CPUs, memory, network resources, etc.) and processor-executable instructions (e.g., workflow processes, instruction scheduling logic, resource acquisition or thread activation instructions, etc.) to support EDA computations.”), the memory resources including memory to store instructions that when executed facilitate a compute resource (CR) control engine to re-allocate resources from the core and/or the memory to a selected portion of the running jobs (¶ [0032]-[0035], “During execution of the EDA process, the dynamic resource balancing engine 110 may provision additional computing resources to any compute engine(s) executing EDA operations in the critical execution path of an EDA process. To do so, the dynamic resource balancing engine 110 may identify a particular compute engine performing an EDA operation on a critical execution path (e.g., of an EDA process) and reallocate computing resources assigned to a different compute engine executing an EDA operation that is not on the critical execution path…Responsive to a determination that the compute engine 103 (in this example) is executing an EDA operation on a critical execution path, the dynamic resource balancing engine 110 may reallocate computing resources from other compute engines to the compute engine 103. In the example shown in FIG. 3, the dynamic resource balancing engine 110 sends a reallocation instruction 240 to the compute engine 102, in response to which the computing engine 102 may release computing resources for acquisition/use by compute engine 103. FIG. 2 illustrates the reallocated computing resources 250, which may be released by the compute engine 102 and acquired by the compute engine 103 responsive to a reallocation instruction 240 issued by the dynamic resource balancing engine 110. In some implementations, the dynamic resource balancing engine 110 may reallocate computing resources based on specific EDA operation types. As EDA operations may vary in computational complexity, the dynamic resource balancing engine 110 may prioritize EDA operations with higher computational complexities, latencies, or timing requirements. Such operation priorities may be specified through operation priority indicator messages sent from compute engines (e.g., as part of the operation priority indicator 230), which may specify a prioritized EDA operation type being executed by a compute engine. The dynamic resource balancing engine 110 may issue reallocation instructions 240 responsive to receiving the operation priority indicator 230 from the compute engine 103 indicative of a high-priority EDA operation being executed by the compute engine 103.”).
Gibson fails to teach monitoring parameters from a plurality of jobs and re-allocating resources based on the monitored parameters.
However, Smith teaches monitor parameters from a plurality of jobs running on the core resources and to re-allocate resources to a selected portion of the job based on the monitored parameters (¶ [0036], “For another example, the task control system can adaptively assign processor cores to achieve the shortest turnaround time for a particular multi-scale simulation approach when results for a set of different input conditions are requested. In this case, the task control system can assign a small amount of compute resources to many short-running tasks while reserving a larger amount of compute resources for the longer-running tasks. Also, while the task control system monitors the compute time of each task of each split, it can dynamically adjust the amount of compute resources as other tasks complete. In addition, as the amount of compute resources is increased for a particular task, the task control system can dynamically determine the effectiveness of the additional compute resources in reducing the runtime of the task and for tasks that are not helped by the additional compute resource, the compute resource can be re-assigned to other tasks. Additionally, if the results of some tasks or approaches indicate that other materials cases slated for evaluation are not likely to have desired results, then the system can proactively terminate the execution of a task or prevent its execution altogether.”).
Gibson and Smith are considered to be analogous to the claimed invention because they are in the same field of task allocation / resource management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gibson with the task monitoring functionality of Smith to arrive at the claimed invention. The motivation to modify Gibson with the teachings of Smith is that monitoring currently executing tasks and dynamically upgrading their resources based on the monitoring results in an optimized turnaround time for circuit simulation (See Smith para. 0033.).
As per claim 16, Gibson and Smith teach the computer system of claim 15. Gibson teaches wherein the at least one computing device is a high performance computing (HPC) pool including a plurality of HPC machines and a batch manager to initiate running jobs on the HPC pool (¶ [0036], “EDA operation priority may be specified, identified, or determined in various ways. In some examples, the dynamic resource balancing engine 110 maintains a priority list of EDA operation types, and such a priority list may be user-configurable or preconfigured. In other examples, the dynamic resource balancing engine 110 may implement or consult specific load balancing criteria, which may specify particular EDA operations (or EDA operation types) and corresponding resource reallocation actions. As particular example EDA operation types, the dynamic resource balancing engine 110 may allocate additional computing resources to a compute engine executing fill operations, multi-patterning operations, high-performance compute (HPC) operations, or any other EDA operations identified otherwise specified as computationally complex.”).
As per claim 17, it is a system claim comprising similar limitations to claim 2, so it is rejected for similar reasons.
As per claim 19, it is a system claim comprising similar limitations to claim 4, so it is rejected for similar reasons.
As per claim 20, Gibson and Smith teach the computer system of claim 19. Gibson teaches wherein the monitored parameters include a priority parameter (¶ [0020], “In doing so, the computing system 100 may increase computational efficiency by reallocating computing resources (e.g., physical CPUs, memory, or any other computational resource used for operation execution) according to a priority of EDA operations, idle compute engines, or various other factors. Such dynamic resource allocation and balancing may be performed by a dynamic resource balancing engine 110, e.g., as shown in FIG. 1.” ¶ [0022], “In operation, the dynamic resource balancing engine 110 may also reallocate a particular computing resource allocated to a first compute engine (e.g., compute engine 101) based on an operation priority of an EDA operation performed by a second compute engine (e.g., compute engine 102), an idle indicator for the first compute engine, or a combination of both.” See also para. 0035-0037.).
Claim(s) 3, 5, 7, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gibson and Smith as applied to claim 2 above, and further in view of Salapura et al. (US Pub. No. 2011/0247002 A1 hereinafter Salapura).
As per claim 3, Gibson and Smith teach the storage medium of claim 2. Smith teaches monitored parameters (¶ [0036], “For another example, the task control system can adaptively assign processor cores to achieve the shortest turnaround time for a particular multi-scale simulation approach when results for a set of different input conditions are requested. In this case, the task control system can assign a small amount of compute resources to many short-running tasks while reserving a larger amount of compute resources for the longer-running tasks. Also, while the task control system monitors the compute time of each task of each split, it can dynamically adjust the amount of compute resources as other tasks complete. In addition, as the amount of compute resources is increased for a particular task, the task control system can dynamically determine the effectiveness of the additional compute resources in reducing the runtime of the task and for tasks that are not helped by the additional compute resource, the compute resource can be re-assigned to other tasks. Additionally, if the results of some tasks or approaches indicate that other materials cases slated for evaluation are not likely to have desired results, then the system can proactively terminate the execution of a task or prevent its execution altogether.”).
Gibson and Smith fail to teach the monitored parameters including a checkpoint parameter.
However, Salapura teaches wherein the plurality of parameters include a checkpoint parameter (¶ [0034]-[0035], “At appropriate time intervals (such as checkpoints, regular time intervals, job completion times, or times defined by some other criteria) the partitions are re-evaluated to determine if resources should be moved from one partition to another. Resources from the under-utilized partition are reassigned to the other partition. For example, if the number of jobs in one queue is under the low-water mark threshold, repartition the system and assign the resources from the underutilized partition (thus reducing the under-utilized partition) to the partition of the other queue. Thus, the resource allocation to available partitions is performed dynamically. This dynamic re-partitioning makes the system adaptable to a changing application mix and increases the number of completed jobs (throughput). The dynamic allocation changes can be evaluated and resources can be dynamically re-assigned (by evaluating demand and re-partitioning) at appropriate time intervals, which can be, by way of example and not limitation: job termination, job checkpoints, regular time intervals (such as time of day), requests by the currently running applications based on their state, triggered by a workflow manager, and/or at program phase change detected by performance monitors. Other time interval selections are also possible.”).
Gibson, Smith, and Salapura are all considered to be analogous to the claimed invention because they are all in the same field of task allocation / resource management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the monitored parameters of Gibson and Smith with the checkpoint parameter of Salapura to arrive at the claimed invention. The motivation to modify Gibson and Smith with the teachings of Salapura is dynamically allocating resources based on a checkpoint parameter makes a computing system adaptable to changes in applications and increases throughput (See Salapura para. 0034.).
As per claim 5, Gibson, Salapura, and Smith teach the storage medium of claim 3. Gibson teaches wherein the plurality of parameters include a priority parameter (¶ [0020], “In doing so, the computing system 100 may increase computational efficiency by reallocating computing resources (e.g., physical CPUs, memory, or any other computational resource used for operation execution) according to a priority of EDA operations, idle compute engines, or various other factors. Such dynamic resource allocation and balancing may be performed by a dynamic resource balancing engine 110, e.g., as shown in FIG. 1.” ¶ [0022], “In operation, the dynamic resource balancing engine 110 may also reallocate a particular computing resource allocated to a first compute engine (e.g., compute engine 101) based on an operation priority of an EDA operation performed by a second compute engine (e.g., compute engine 102), an idle indicator for the first compute engine, or a combination of both.” See also para. 0035-0037.).
As per claim 7, Gibson and Smith teach the storage medium of claim 1.
Gibson and Smith fail to teach selecting jobs based on the number of remaining checkpoints.
However, Salapura teaches wherein selecting includes determining if the jobs have a sufficient number of remaining checkpoints (¶ [0034]-[0035], “At appropriate time intervals (such as checkpoints, regular time intervals, job completion times, or times defined by some other criteria) the partitions are re-evaluated to determine if resources should be moved from one partition to another. Resources from the under-utilized partition are reassigned to the other partition. For example, if the number of jobs in one queue is under the low-water mark threshold, repartition the system and assign the resources from the underutilized partition (thus reducing the under-utilized partition) to the partition of the other queue. Thus, the resource allocation to available partitions is performed dynamically. This dynamic re-partitioning makes the system adaptable to a changing application mix and increases the number of completed jobs (throughput). The dynamic allocation changes can be evaluated and resources can be dynamically re-assigned (by evaluating demand and re-partitioning) at appropriate time intervals, which can be, by way of example and not limitation: job termination, job checkpoints, regular time intervals (such as time of day), requests by the currently running applications based on their state, triggered by a workflow manager, and/or at program phase change detected by performance monitors. Other time interval selections are also possible.”).
Gibson, Smith, and Salapura are all considered to be analogous to the claimed invention because they are all in the same field of task allocation / resource management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the monitored parameters of Gibson and Smith with the checkpoint parameter of Salapura to arrive at the claimed invention. The motivation to modify Gibson and Smith with the teachings of Salapura is dynamically allocating resources based on a checkpoint parameter makes a computing system adaptable to changes in applications and increases throughput (See Salapura para. 0034.).
As per claim 18, it is a system claim comprising similar limitations to claim 3, so it is rejected for similar reasons.
Claim(s) 9 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Gibson and Smith as applied to claims 1 and 10 above, and further in view of CAO et al. (US Pub. No. 2022/0292303 A1 hereinafter CAO).
As per claim 9, Gibson and Smith teach the storage medium of claim 1. Gibson teaches wherein providing the selected jobs with additional compute resources includes upgrading their allocated compute resources (¶ [0036], “For another example, the task control system can adaptively assign processor cores to achieve the shortest turnaround time for a particular multi-scale simulation approach when results for a set of different input conditions are requested. In this case, the task control system can assign a small amount of compute resources to many short-running tasks while reserving a larger amount of compute resources for the longer-running tasks. Also, while the task control system monitors the compute time of each task of each split, it can dynamically adjust the amount of compute resources as other tasks complete. In addition, as the amount of compute resources is increased for a particular task, the task control system can dynamically determine the effectiveness of the additional compute resources in reducing the runtime of the task and for tasks that are not helped by the additional compute resource, the compute resource can be re-assigned to other tasks. Additionally, if the results of some tasks or approaches indicate that other materials cases slated for evaluation are not likely to have desired results, then the system can proactively terminate the execution of a task or prevent its execution altogether.”).
Gibson and Smith fail to teach freezing the selected jobs and restoring the jobs after the resources have been upgraded.
However, CAO teaches wherein providing the job with additional compute resources includes issuing a freeze request for some of the selected jobs, upgrading their allocated compute resources, and issuing to them a restore request (¶ [0054], “In some embodiments, when the resource re-allocation is triggered, the RA-loop 412 can save ML job progress (e.g., a checkpoint), re-compute how much computing resources should be allocated among parameter servers and worker nodes, re-allocate the computing resources, and resume the ML job from the checkpoint. In a resource re-allocation, the idle resources from either parameter server or worker nodes can be reclaimed and re-allocated to other nodes with higher resource demand/utilization.”).
Gibson, Smith, and CAO are all considered to be analogous to the claimed invention because they are all in the same field of task allocation / resource management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gibson and Smith with the freezing and restoring functionality of CAO to arrive at the claimed invention. The motivation to modify Gibson and Smith with the teachings of CAO is that adaptive resource allocation results in efficient and stable resource allocation (See CAO para. 0054.).
As per claim 13, it is a storage medium claim comprising similar limitations to claim 9, so it is rejected for similar reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. McGaughy et al. (US Pub. No. 2014/0310722 A1) teaches dynamic load balancing for circuit simulation tasks based on task execution time.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 ET.
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, Lewis Bullock can be reached at (571)272-3759. 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.
/J.D.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights