DETAILED ACTION
This office action is in response to claims filed 6 March 2026.
Claims 1-20 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new reference (FURUSAWA, cited below) is not specifically challenged by the applicant’s arguments.
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, 4, 7-8, 13, and 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over SAMPATHKUMAR et al. Pub. No.: US 2018/0097874 A1 (hereafter SAMPATHKUMAR), in view of FURUSAWA et al. Pub. No.: US 2014/0208049 A1 (hereafter FURUSAWA).
SAMPATHKUMAR was cited previously.
Regarding claim 1, SAMPATHKUMAR teaches:
A method for dynamic migration of job processing between different execution environments, the method comprising:
initiating, by one or more processors, processing of a job at a first execution environment, wherein the job comprises a workload or a service request ([0029] As illustrated, workloads 501, 502, 503, and 504 are executing on host 1; workloads 505, 506, and 507 are executing on host 2; and workloads 508, 509, and 510 are executing on host 3 (i.e., hosts represent “execution environments”));
monitoring, by the one or more processors, the first execution environment and a second execution environment ([0021] Method 200 begins at step 210, where resource scheduler 110 (in particular, load measurer 112) receives resource utilization information (i.e., receiving resource utilization information represents “monitoring”) from each host in a cluster in response a request for the resource utilization information transmitted to the hosts. [0022] At step 220, resource scheduler 110 selects a first host and a second host for examination. In the illustrated embodiment, resource scheduler 110 selects the most loaded host (e.g., the first host) and the least loaded host (e.g., the second host));
determining, by the one or more processors, to migrate processing of the job to a second execution environment based at least in part on the monitoring ([0022] At step 230, resource scheduler 110 determines if the resource utilization difference between the first and second hosts exceeds the threshold difference, [0023] If resource scheduler 110 determines that the resource utilization difference between the first and second hosts exceeds the threshold difference, resource scheduler 110 triggers load balancing between the most loaded host and the least loaded host); and
migrating, by the one or more processors, processing of the job from the first execution environment to the second execution environment ([0023] At step 240, resource scheduler 110 selects one or more candidate workloads for migration from the most loaded host to the least loaded host).
While SAMPATHKUMAR discusses migration of job execution between environments based on monitoring, SAMPATHKUMAR does not explicitly teach:
initiating processing of failure recovery operations in response to a failure with respect to processing of the job at the second execution environment, wherein the failure recovery operations comprise:
reinitiating the processing of the job at the second execution environment based on a processing recovery parameter, wherein the processing recovery parameter comprises a threshold number of times the processing of the job is reinitiated at the second execution environment; and
initiating migration to a different execution environment in response to the failure of the processing recovery parameter.
However, in analogous art that similarly discusses migration of jobs between environments, FURUSAWA teaches:
initiating processing of failure recovery operations in response to a failure with respect to processing of the job at the second execution environment ([0132] The recovery process that is executed when an error occurs during the live migration will be described with reference to FIGS. 22 through 24), wherein the failure recovery operations comprise: reinitiating the processing of the job at the second execution environment based on a processing recovery parameter, wherein the processing recovery parameter comprises a threshold number of times the processing of the job is reinitiated at the second execution environment ([0133] FIG. 22 is a diagram illustrating an example of an operational sequence when an error has occurred, according to an embodiment. In a manner similar to FIG. 5, the administration unit 401 receives the live migration instruction from the management terminal 107 (S2201). The live migration instruction includes the migration table 601 and the retry limit count. The retry limit count is the number of retries that may be attempted when an error occurs during the live migration (i.e., retry limit count represents a “recovery parameter” because it comprises a number of attempts, or “times” that processing is tried after a migration to a second hypervisor, representing a second “environment”)); and
initiating migration to a different execution environment in response to the failure of the processing recovery parameter ([0137] The hypervisor 207 a, which has detected a live migration failure, performs the recovery process (S2211). [0139] The hypervisor 207 d determines that the hypervisor 207 b is a sender hypervisor 207, and sends a receiving instruction to the hypervisor 207 d (S2219). Then, the hypervisor 207 b performs the live migration (S2221). That is, the hypervisor 207 b transmits data of the virtual machine 209 c (virtual machine ID: 1010011) to the hypervisor 207 d (S2223) (i.e., hypervisor b represents a second environment, that, in response to the retry limit count being exceeded, migrates the virtual machine to hypervisor d representing a third, “different” execution environment)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined FURUSAWA’s teaching of migrating a virtual machine from a second environment to a different environment when a number of retries after a migration exceeds a limit, with SAMPATHKUMAR’s teaching of migrating jobs between environments, to realize, with a reasonable expectation of success, a system that migrates jobs between environments, as in SAMPATHKUMAR, that migrates jobs to other environments when an unsuccessful retry count is exceeded, as in FURUSAWA. A person having ordinary skill would have been motivated to make this combination to better handle situations where processing of migrated workloads fails.
Regarding claim 4, SAMPATHKUMAR further teaches:
monitoring a third execution environment; and
performing conflict resolution operations between the second execution environment and the third execution environment, wherein the conflict resolution is configured to determine whether the migrating is to be initiated with respect to the second execution environment or the third execution environment, wherein the processing of the job is migrated to the second execution environment or the third execution environment based on an outcome of the conflict resolution operations ([0021] Method 200 begins at step 210, where resource scheduler 110 (in particular, load measurer 112) receives resource utilization information from each host (i.e., at least first, second, and third execution environments) in a cluster in response a request for the resource utilization information transmitted to the hosts. [0022] At step 220, resource scheduler 110 selects a first host and a second host for examination. In the illustrated embodiment, resource scheduler 110 selects the most loaded host (e.g., the first host) and the least loaded host (e.g., the second host)) (i.e., in selecting the least loaded host as the target host, resource scheduler 110 performs “conflict resolution” by determining which of the remaining “conflicting” hosts is the least loaded host)).
Regarding claim 7, FURUSAWA further teaches:
initiating processing failure recovery operations in response to a failure with respect to processing of the job at the second execution environment ([0132] The recovery process that is executed when an error occurs during the live migration will be described with reference to FIGS. 22 through 24), wherein the failure recovery processing is configured to initiate migration to a different execution environment in response to failure of a processing recovery parameter ([0137] The hypervisor 207 a, which has detected a live migration failure, performs the recovery process (S2211). [0139] The hypervisor 207 d determines that the hypervisor 207 b is a sender hypervisor 207, and sends a receiving instruction to the hypervisor 207 d (S2219). Then, the hypervisor 207 b performs the live migration (S2221). That is, the hypervisor 207 b transmits data of the virtual machine 209 c (virtual machine ID: 1010011) to the hypervisor 207 d (S2223) (i.e., hypervisor b represents a second environment, that, in response to the retry limit count being exceeded, migrates the virtual machine to hypervisor d representing a third, “different” execution environment)).
Regarding claims 8, and 13, they comprise limitations similar to claim 1, and are therefore rejected for similar rationale. Regarding claims 16-19, they comprise limitations similar to claim 4, and are therefore rejected for similar rationale.
Claims 2-3, 9, and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over SAMPATHKUMAR, in view of FURUSAWA, as applied to claims 1, 8, and 13 above, and in further view of LAKSHMANAN et al. Pub. No.: US 2011/0047554 A1 (hereafter LAKSHMANAN).
LAKSHMANAN was cited previously.
Regarding claim 2, while SAMPATHKUMAR and FURUSAWA discusses migration of workloads, it does not explicitly teach:
initializing the second execution environment subsequent to determining to migrate processing of the job from the first execution environment to the second execution environment.
However, in analogous art that similarly teaches migration of workloads, LAKSHMANAN teaches:
initializing the second execution environment subsequent to determining to migrate processing of the job from the first execution environment to the second execution environment ([0057] Load migration and quiescing decisions must not occur simultaneously as they may provide conflicting results. Therefore, the one decision (load migration or quiescing) may be considered before or after the other (quiescing or load migration) is completed (i.e., making a quiescing decision may happen subsequent to determining to migrate a task). [0064] These initial considerations are followed by a detailed analysis of the benefits and costs of transitioning to quiescent mode. The costs of such a transition include: the total power cost associated with a transition including…(3) the power cost of any other nodes (i.e., “second execution environments”) which receive migrated tasks from this node and may transition from quiescent mode to active mode (i.e., transitioning from a quiescent mode to an active mode “initializes” the node for execution of the migrated job) as a result of receiving these tasks (i.e., the actual transition from a quiescent mode to an active mode happens subsequent to the decision to transition, and subsequent to the load migration decision)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined LAKSHMANAN’s teaching of transitioning a receiving node from a quiescent mode to an active mode subsequent to a decision to migrate a task to the receiving node, with SAMPATHKUMAR, and FURUSAWA’s teaching of making a decision to migrate a task to a receiving node, to realize, with a reasonable expectation of success, a system that makes a decision to migrate a task to a receiving node, as in SAMPATHKUMAR and FURUSAWA, which involves initializing the receiving node after the decision was made, as in LAKSHMANAN. A person of ordinary skill would have been motivated to make this combination to keep receiving nodes in a low power, quiescent state and activating them only when needed, to thereby save power.
Regarding claim 3, LAKSHMANAN further teaches:
monitoring the second execution environment subsequent to the initializing to detect a stabilization state of the second execution environment, wherein the migrating is initiated in response to detection that the second execution environment is in a stabilized state ([0093] The next criteria is target node load correlation. In addition to looking at average load on the target node, the load stability should also be examined. It has been demonstrated in published work [Xing, ICDE'05, supra] that it is not sufficient to simply take into account the average load on a target node before migrating tasks to this node. One must also examine the load variation on the node. In particular it would be useful if the load correlation coefficients between tasks on a node are negative. A negative load correlation coefficient between two tasks implies that when the load of one of the tasks peaks, the load of the other task does not. Therefore the calculation of load correlation coefficients between the target task being migrated and the tasks on the recipient machine are incorporated into the load migration decision making process (i.e., load on a target node must be in a stabilized state subsequent to the transition from quiescent state to active state in order for the target task to be migrated)).
Regarding claims 9, and 14-15, they comprise limitations similar to claims 2-3, and are therefore rejected for similar rationale.
Claims 5-6, are rejected under 35 U.S.C. 103 as being unpatentable over SAMPATHKUMAR, in view of FURUSAWA, as applied to claim 1 above, and in further view of BARTON et al. Pub. No.: US 2023/0236899 A1 (hereafter BARTON)
BARTON was cited previously.
Regarding claim 5, while SAMPATHKUMAR and FURUSAWA discusses migrating workloads between host execution environments, they do not explicitly teach:
the monitoring is configured to measure utilization of green or renewable energy utilized by the first execution environment and the second execution environment, and wherein the determination to migrate the processing of the job to the second execution environment is based on the utilization of green or renewable energy utilized by the first execution environment and the second execution environment.
However, in analogous art that similarly migrates workloads between host execution environments, BARTON teaches:
the monitoring is configured to measure utilization of green or renewable energy utilized by the first execution environment and the second execution environment, and wherein the determination to migrate the processing of the job to the second execution environment is based on the utilization of green or renewable energy utilized by the first execution environment and the second execution environment ([0048] FIG. 3 is a flowchart 300 illustrating a process for dynamically placing workloads using cloud service energy efficiency in a multi-cloud service environment. [0050] At 304, an energy analysis is performed. In some examples, the energy analysis may be performed by an ETE 108, or by some other device or component. Generally, the energy analysis includes determining an EEQ for each of the different host locations that can be used to host a workload 112. [0052] At 308, the host location for the workload is selected. As discussed above, the host location may be selected based on different criteria, such as a ranking of host locations, a classification of the host locations, a score of the host locations, and/or other data. [0018] In some configurations, the ETE ranks the host locations (e.g., different POPs of regions of available cloud services) according to the EEQs and/or other parameters as candidate host locations where a workload may be migrated. For example, a POP or data center withing a region of a cloud service provider which derives the majority of power through non-renewable energy sources (such as thermal or coal) would be placed lower in the list of host locations compared to a POP/data center which derives most of the energy through renewable sources (solar, wind) (i.e., workloads are migrated to host locations which are ranked based on utilization of renewable energy, where the highest ranked host location, representing the second execution environment, uses more renewable energy than a lower ranked host location, representing the first execution environment)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined BARTON’s teaching of migrating tasks to host execution environments using higher amounts of renewable energy, with SAMPATHKUMAR, and FURUSAWA’s teaching of migrating tasks between host execution environments, to realize, with a reasonable expectation of success, a system that migrates tasks between host execution environments, as in SAMPATHKUMAR and FURUSAWA, to improve the amount of renewable energy used to execute the tasks, as in BARTON. A person having ordinary skill would have been motivated to make this combination to achieve higher sustainability and reduce energy impact to the earth (BARTON [0002]).
Regarding claim 6, BARTON further teaches:
the monitoring is configured to monitor one or more additional metrics associated with processing of jobs, the one or more additional metrics comprising performance metrics, a completion status of the processing of the job, processing failure recovery metrics, or a combination thereof, and wherein the determination to migrate the processing of the job to the second execution environment is based on the utilization of green or renewable energy utilized by the first execution environment and the second execution environment and the one or more additional metrics ([0038] Other metrics may also be used to assist in determining a suitable candidate. These metric(s) 107 may also be used in placing workloads 112 on a cloud service 102 based on cloud service energy efficiency. The metric(s) may include but are not limited to packet loss metrics, latency metrics, jitter metrics, available bandwidth, capacity, response time metrics, network reachability, path changes, availability metrics, connect time metrics, and the like. When a suitable candidate host location meets both the performance and EEQ specifications is determined by the ETE 10, a workload 112 can be migrated to the selected host location (i.e., a workload is migrated to a host that uses an amount of renewable energy as well as has other characteristics including at least performance)).
Claims 10, 11, 12, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over SAMPATHKUMAR, in view of FURUSAWA as applied to claims 8, and 13 above, and in further view of GOPALAN et al. Pub. No.: US 2020/0104189 A1 (hereafter GOPALAN).
GOPALAN was cited previously.
Regarding claim 10, while SAMPATHKUMAR and FURUSAWA discusses migration of tasks between hosts, it does not explicitly teach:
track historical metrics associated with a plurality of execution environments;
apply a machine learning algorithm to the historical metrics to predict optimal migration of jobs between at least some execution environments of the plurality of execution environments; and
initiate migration of one or more the jobs to particular execution environments of the at least some execution environments based on predictions by the machine learning algorithm.
However, in analogous art that similarly teaches migration of tasks between hosts, GOPALAN teaches
track historical metrics associated with a plurality of execution environments; apply a machine learning algorithm to the historical metrics to predict optimal migration of jobs between at least some execution environments of the plurality of execution environments ([0057] At step 512, the workload placement engine 151 determines an estimated effective demand 306 of the target provider 202 if the workload 121 were to be migrated to the target provider 202. The effective demand 306 can be estimated by stacking the current demand 300 and forecasted demand 303 of the workload 121 on top of the current demand 300 and forecasted demand 303 of the target provider 202. [0026] In some examples, the data trends are determined according to machine learning models designed to accurately detect patterns in resource usage for a particular workload 121. The machine learning models can be trained according to the resource usage history of a one or more workloads 121 (i.e., machine learning models are trained on, or “applied to” resource usage history “metrics” to forecast demand in order yield an optimal workload migration)); and
initiate migration of one or more the jobs to particular execution environments of the at least some execution environments based on predictions by the machine learning algorithm ([0059] At step 518, the workload placement engine 151 or the management service 148 migrates the workload 121 to the target provider 202.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined GOPALAN’s teaching of using a machine learning model to forecast demand for use in workload migration, with SAMPATHKUMAR and FURUSAWA’s teaching of migrating workloads between hosts, to realize, with a reasonable expectation of success, a system that migrates workloads between hosts, as in SAMPATHKUMAR and FURUSAWA, based on a machine learning algorithm forecasting demand based on historical usage, as in GOPALAN. A person having ordinary skill would have been motivated to make this combination so that resource demand can be forecasted with a high degree of accuracy using machine learning.
Regarding claim 11, GOPALAN further teaches:
the machine learning algorithm comprises a clustering algorithm ([0026] In some examples, the data trends are determined according to machine learning models designed to accurately detect patterns in resource usage for a particular workload 121. The machine learning models can be trained according to the resource usage history of a one or more workloads 121 (i.e., since the machine learning model clusters usage history to identify patterns of similar data points, the machine learning model is considered a “clustering algorithm”))).
Regarding claim 12, it comprises limitations similar to claim 4, and is therefore rejected for similar rationale.
Regarding claim 20, it comprises limitations similar to claim 10, and is therefore rejected for similar rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195
Prosecution Insights