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 .
DETAILED ACTION
Claims 21-40 are presented for examination.
Examiner Notes
For claims 35-40, "computer storage media" is recited. The examiner cites the following paragraph ( [0068] of the specification that "Computer storage media does not include a carrier wave or other propagated or modulated data signal". Based on this, claims 35-40 are statutory under USC 101.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 21-27 are compared to claims 1-7 in US Patent 12056521 in the following table:
Instant Application
Patent number 12056521
Claim 21. A computer-implemented method for scheduling an execution of a
workload in a cloud server, the method comprising:
receiving a notification of a workload interruption, wherein the notification identifies an interrupted workload of a virtual machine (VM) and includes a virtual machine (VM) type of the
VM;
retrieving capacity prediction data, wherein the capacity prediction data includes a predicted eviction rate of the VM type, and
the predicted eviction rate is based on a trained machine-learning model predicting a capacity of available computing resources for allocation to
the VM type;
scheduling, based on a combination of a queuing policy of the interrupted workload and the predicted eviction rate, a redeployed VM for hosting the interrupted workload; and
causing a dispatch to execute the redeployed VM for hosting the interrupted workload
according to the predicted capacity of available computing resources.
Claim 1. A computer-implemented method for scheduling an execution of a workload in a cloud server, the method comprising:
receiving a notification associated with a workload interruption, wherein the notification identifies an interrupted workload and includes a virtual machine (VM) type associated with the interrupted workload;
determining a queuing policy associated with the interrupted workload;
retrieving capacity prediction data, wherein the capacity prediction data includes a predicted eviction rate of the VM type associated with the interrupted workload, and
wherein the predicted eviction rate is generated using a trained machine-learning model to predict a capacity of available computing resources for allocation to the VM type;
scheduling, based on a combination of the queuing policy and the predicted eviction rate, a redeployed VM for hosting the interrupted workload; and
causing a dispatch to execute the redeployed VM for hosting the interrupted workload, wherein the dispatch causes allocation of available computing resources for the redeployed VM based on the VM type.
Claim 22. The computer-implemented method according to claim 21, the method further comprising:
receiving system status data of available computing resources in the cloud server; retrieving the trained machine-learning model for predicting the capacity of available computing resources for allocation to the VM type; generating, based on the trained machine-learning model, the capacity prediction data;
and transmitting the capacity prediction data.
Claim 2. The computer-implemented method according to claim 1, the method further comprising: receiving system status data associated with available computing resources in the cloud server; retrieving the trained machine-learning model for predicting the capacity of available computing resources for allocation to the VM type; generating, based on the trained machine-learning model, the capacity prediction data; and transmitting the capacity prediction data.
Claim 23. The computer-implemented method according to claim 21, the method further comprising: receiving capacity signal history data, wherein the capacity signal history data includes history data of available computing resources for allocation to the VM type in the cloud server;
generating, based on the received capacity signal data, training data for a machine learning model; training the machine-learning model for predicting the capacity of available computing resources for allocation to the VM type; and storing the trained machine-learning model.
Claim 3. The computer-implemented method according to claim 1, the method further comprising: receiving capacity signal history data, wherein the capacity signal history data includes history data associated with available computing resources for allocation to the VM type in the cloud server; generating, based on the received capacity signal data, training data for a machine-learning model; training the machine-learning model for predicting the capacity of available computing resources for allocation to the VM type; and storing the trained machine-learning model.
Claim 24. The computer-implemented method according to claim 21, wherein the notification of the workload interruption includes the VM type of hosting the interrupted
workload, and wherein the VM type corresponds to an amount of computing resources allocated
to the VM.
Claim 4. The computer-implemented method according to claim 1, wherein the notification associated with the workload interruption includes the VM type associated with hosting the interrupted workload, and wherein the VM type corresponds to an amount of computing resources allocated to the VM.
Claim 25. The computer-implemented method according to claim 21, wherein the interrupted workload corresponds to one or more of: an application program, a set of instructions, or a job.
Claim 5. The computer-implemented method according to claim 1, wherein the interrupted workload corresponds to one or more of: an application program, a set of instructions, or a job.
Claim 26. The computer-implemented method according to claim 23, wherein the capacity signal history data includes one or more of: server data, VM data, or eviction data including history data of evicting workloads from VMs.
Claim 6. The computer-implemented method according to claim 3, wherein the capacity signal history data includes one or more of: server data, VM data, or eviction data including history data associated with evicting workloads from VMs.
Claim 27. The computer-implemented method according to claim 21, wherein the trained machine-learning model is generated based on one or more of: random forests, and
a neural network.
Claim 7. The computer-implemented method according to claim 1, wherein the trained machine-learning model is generated based on one or more of: random forests, and a neural network.
Claims 21-40 are provisionally rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-7 of US Patent 12056521.
Claims 28-34 and 35-40 are identical to claims 21-27 of the instant application and are rejected for the same reasons.
Although the conflicting claims are not identical (difference in claim 21 is shown in bold above), they are not patentably distinct from each other because the limitations of claims 1-7 of the patent, anticipates or otherwise renders obvious the limitations of 21-40, respectively of this instant 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 of this title, 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 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 21,23-28,30-35 and 37-40 are rejected under 35 U.S.C. 103 as being unpatentable over Mitra (US 2022/0374276 A1) in view of Zhang (US 2021/0247998 A1).
As per claim 21, Mitra teaches A computer-implemented method for scheduling an execution of a workload in a cloud server, the method comprising:
receiving a notification of a workload interruption, wherein the notification identifies an interrupted workload of a virtual machine (VM) and includes a virtual machine (VM) type of the VM; (Mitra [0047] The method 504 further includes receiving 714, from the designated instance 104a ... 104n, an indication that the job [workload] selected for execution has completed execution or an indication that the job selected for execution has been interrupted during the execution. When a job that is executing is interrupted or completes execution, the method 504 selects 704 the same job 102 (if not yet completed), or a different job, to be scheduled for execution based on the utility 202 and the remaining budget [remaining budget of the instance of VM] [0029] …Furthermore, additional data can be obtained from running other jobs on similar types of cloud computing instances [type of the VM] (i.e., discounted instances that can be interrupted)…. [0030] …This information about the rescheduling overhead and the mean time per epoch represents an estimate of the efficiency of the instance for executing a particular type of job (e.g., a machine learning training job). The efficiency, combined with the cost of executing the job 102 on the instance [type of VM], is used by the scheduler module 110 to select which jobs are to be scheduled on which instances 104a . . . 104n.)
scheduling, based on a combination of a queuing policy of the interrupted workload and the predicted eviction rate, a redeployed VM for hosting the interrupted workload; (Mitra [0027] As noted above, the utility of a given job is the amount of completion (measured as progress or validity of results) of the job at the point where the budget is consumed, including the overhead costs associated with rescheduling the job one or more times due to interruptions. If there are multiple jobs, there is a cost-benefit trade-off associated with the additional utility received for executing a given job versus the additional utility received for executing a different job such that the budget, which is fixed for executing any or all of the jobs, is spent on the job or jobs that have the greatest marginal utility gain [queuing policy] [0030] This information about the rescheduling overhead and the mean time per epoch represents an estimate of the efficiency of the instance for executing a particular type of job (e.g., a machine learning training job). The efficiency, combined with the cost of executing the job 102 on the instance, is used by the scheduler module 110 to select which jobs are to be scheduled on which instances 104a . . . 104n [0047] A different job may be selected if that job has a greater marginal utility gain.).
The examiner is interpreting “queueing policy” according to what is disclosed in the specification ([0025] The policy determiner 122 (i.e., a policy engine) determines a queuing policy for scheduling a VM for the interrupted workload. In particular, the policy determiner 122 determines a weight (e.g., a priority) for replenishing (e.g., scheduling, deploying) a redeployed VM). This seems to be queuing policy of the virtual machine (more than the workload).
Here the eviction rate will come from Zhang (see below). The combination makes sense because Mitra also mentions profiling of job and instances (virtual machines) ([0029] Thus, by running a set of known jobs on each of the instances multiple times, as discussed above, and tracking the number of times these jobs are interrupted, the profiler module 108 can update or otherwise modify the baseline distribution to provide a more accurate estimate of the actual distribution of interruptions. Furthermore, additional data can be obtained from running other jobs on similar types of cloud computing instances (i.e., discounted instances that can be interrupted). Note that for the purpose of determining the utility of a job, it is not necessary for the profiler module to execute each job end-to-end (i.e., to completion or validation). Rather, a sampling of several hundred epochs of execution provides a reasonable estimate of the job's utility for use by the scheduler module 110.)
causing a dispatch to execute the redeployed VM for hosting the interrupted workload according to the predicted capacity of available computing resources. (Mitra [0046] If a job 102 is interrupted prior to completion, the method 504 further includes restoring 712 the checkpoint (last known current state of the job) and rescheduling execution of the job on a new instance 104a . . . 104n, or on the same instance where the job was previously interrupted, by sending 706 the job, with the checkpoint data, to the designated instance. Note that an interrupted job may not necessarily be rescheduled, depending on how much the job has been processed, the utility function 202 of the job, and the remaining budget [capacity of available computing resource] after deducting the costs incurred for executing the interrupted job. Also see paragraph 27 which deal with profiling to see how this is a predicted capacity of an instance based on the profiling information)
Mitra does not teach retrieving capacity prediction data, wherein the capacity prediction data includes a predicted eviction rate of the VM type, and the predicted eviction rate is based on a trained machine-learning model predicting a capacity of available computing resources for allocation to the VM type.
However, Zhang teaches retrieving capacity prediction data, wherein the capacity prediction data includes a predicted eviction rate of the VM type, and the predicted eviction rate is based on a trained machine-learning model predicting a capacity of available computing resources for allocation to the VM type; (Zhang [0043] In block 206, managing device 102 determines costs for running application 104 by a plurality of types of virtual machines based on a length of the target time period and the interruption tolerance. The plurality of types of virtual machines are virtual machines from at least one cloud platform. To determine which type of virtual machine can be used for running application 104, it is necessary to determine a use cost of each type of virtual machine [0045] In some embodiments, managing device 102 determines the target type based on the determined cost and computing resource. Each type has resource information corresponding to this type. For example, a virtual machine type indicates a virtual machine having 2 cores. Managing device 102 can determine a number of required virtual machines of each type based on the computing resource. For example, a computing resource of 4 cores is required, and therefore, the number of required virtual machines of this type is 2. Therefore, based on the number of virtual machines required for each type and a cost for each type, a total cost associated with this type is determined. Then, a type with a minimum total cost is selected as the target type based on the total cost of each type [0051] In block 304, managing device 102 determines an interrupt rate of the first type of virtual machine [eviction rate] based on a length of a target time period and the reference value. In some embodiments, managing device 102 predicts the interrupt rate of the first type of virtual machine through a neural network model. Alternatively or additionally, the neural network model is a recurrent neural network model, e.g., a LSTM neural network. After inputting historical cost information corresponding to the first type of virtual machine, the length of the target time period, and the reference value into the neural network model, the corresponding interrupt rate will be obtained. [machine learning model] see Also Fig 4 and [0061] In some embodiments, virtual machine type determining module 410 may further determine number 414 of required virtual machines based on the computing resource predicted by resource prediction module 404 and target type 412.)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Zhang with the system of Mitra to find a predicted eviction rate of the VM type. One having ordinary skill in the art would have been motivated to use Zhang into the system of Mitra for the purpose of determining an interruption tolerance of the application based on a type of the application. (Zhang paragraph 06)
As per claim 23, Zhang teaches receiving capacity signal history data, wherein the capacity signal history data includes history data of available computing resources for allocation to the VM type in the cloud server; (Zhang Fig 2 Block 202 (Determining based on historical data associated ,with running of an application a target time period and a computing resource to be used for running the application within the target time period and [0043] In block 206, managing device 102 determines costs for running application 104 by a plurality of types [VM data] of virtual machines based on a length of the target time period and the interruption tolerance. The plurality of types of virtual machines are virtual machines from at least one cloud platform. To determine which type of virtual machine can be used for running application 104, it is necessary to determine a use cost of each type of virtual machine. A process of determining the cost is described in detail below in combination with FIG. 3.)
generating, based on the received capacity signal data, training data for a machine learning model; (Zhang [0037] In some embodiments, managing device 102 applies the historical data to a resource prediction model, to determine the target time period and the computing resource. In some embodiments, the resource prediction model is a recurrent neural network model. Alternatively or additionally, the recurrent neural network model is a long short-term memory (LSTM) neural network model. [0051] In block 304, managing device 102 determines an interrupt rate of the first type of virtual machine based on a length of a target time period and the reference value. In some embodiments, managing device 102 predicts the interrupt rate of the first type of virtual machine through a neural network model. Alternatively or additionally, the neural network model is a recurrent neural network model, e.g., a LSTM neural network. After inputting historical cost information corresponding to the first type of virtual machine, the length of the target time period, and the reference value into the neural network model, the corresponding interrupt rate will be obtained).
training the machine-learning model for predicting the capacity of available computing resources for allocation to the VM type; (Zhang [0037] In some embodiments, managing device 102 applies the historical data to a resource prediction model, to determine the target time period and the computing resource. In some embodiments, the resource prediction model is a recurrent neural network model. Alternatively or additionally, the recurrent neural network model is a long short-term memory (LSTM) neural network model. [0051] In block 304, managing device 102 determines an interrupt rate of the first type of virtual machine based on a length of a target time period and the reference value. In some embodiments, managing device 102 predicts the interrupt rate of the first type of virtual machine through a neural network model. Alternatively or additionally, the neural network model is a recurrent neural network model, e.g., a LSTM neural network. After inputting historical cost information corresponding to the first type of virtual machine, the length of the target time period, and the reference value into the neural network model, the corresponding interrupt rate will be obtained. And [0057] Then, virtual machine prediction module 406 determines costs corresponding to a plurality of different virtual machine types 408-1, 408-2, . . . , 408-M based on the interruption tolerance of application 104 and the length of the target time target, where M is a positive integer. Virtual machine prediction module 406 determines the costs for different virtual machine types through the neural network model)
storing the trained machine-learning model. (Zhang [0058] Managing device 102 further includes a virtual machine prediction module 406. Virtual machine prediction module 406 receives a type of application 104 and the target time period from application 402. An acceptable interruption tolerance of application 104 may be determined based on the type of application 104. Then, virtual machine prediction module 406 determines costs corresponding to a plurality of different virtual machine types 408-1, 408-2, . . . , 408-M based on the interruption tolerance of application 104 and the length of the target time target, where M is a positive integer. Virtual machine prediction module 406 determines the costs for different virtual machine types through the neural network model. For example, for virtual machine type 408-1, an interrupt rate corresponding to virtual machine type 408-1 is predicted based on the length of the target time target, a reference value of the cost which is given in advance, and historical cost data associated with virtual machine type 408-1. If the predicted interrupt rate does not meet the interruption tolerance, the reference value is increased. Then, the interrupt rate is recomputed using the neural network model based on the increased reference value, until a reference value of the cost meeting the interruption tolerance is obtained. Then, the reference value in this case is used as an actual value of the cost. Therefore, actual values of a plurality of costs may be determined for a plurality of virtual machine models).
As per claim 24, Mitra teaches wherein the notification of the workload interruption includes the VM type of hosting the interrupted workload, and wherein the VM type corresponds to an amount of computing resources allocated to the VM. (Mitra [0047] The method 504 further includes receiving 714, from the designated instance 104a ... 104n, an indication that the job selected for execution has completed execution or an indication that the job selected for execution has been interrupted during the execution. When a job that is executing is interrupted or completes execution, the method 504 selects 704 the same job 102 (if not yet completed), or a different job, to be scheduled for execution based on the utility 202 and the remaining budget [amount of computing resources of the VM], such as described above with respect to FIG. 3. For example, if a job 102 was interrupted but the remaining budget is insufficient to resume execution of that job, a different job can be selected if that job can be executed within the remaining budget, according to a solution of the optimization problem. A different job may be selected if that job has a greater marginal utility gain)
As per claim 25, Mitra teaches The computer-implemented method according to claim 21, wherein the interrupted workload corresponds to one or more of: an application program, a set of instructions, or a job. (Mitra [0047] The method 504 further includes receiving 714, from the designated instance 104a ... 104n, an indication that the job [workload] selected for execution has completed execution or an indication that the job selected for execution has been interrupted during the execution
As per claim 26, Zhang teaches The computer-implemented method according to claim 23, wherein the capacity signal history data includes one or more of: server data, VM data , or eviction data including history data of evicting workloads from VMs. (Zhang Fig 2 Block 202 (Determining based on historical data associated ,with running of an application a target time period and a computing resource to be used for running the application within the target time period and [0043] In block 206, managing device 102 determines costs for running application 104 by a plurality of types [VM data] of virtual machines based on a length of the target time period and the interruption tolerance. The plurality of types of virtual machines are virtual machines from at least one cloud platform. To determine which type of virtual machine can be used for running application 104, it is necessary to determine a use cost of each type of virtual machine. A process of determining the cost is described in detail below in combination with FIG. 3.)
As per claim 27, Zhang teaches The computer-implemented method according to claim 21, wherein the trained machine-learning model is generated based on one or more of: random forests, and a neural network. (Zhang [0037] In some embodiments, managing device 102 applies the historical data to a resource prediction model, to determine the target time period and the computing resource. In some embodiments, the resource prediction model is a recurrent neural network model. Alternatively or additionally, the recurrent neural network model is a long short-term memory (LSTM) neural network model. [0051] In block 304, managing device 102 determines an interrupt rate of the first type of virtual machine based on a length of a target time period and the reference value. In some embodiments, managing device 102 predicts the interrupt rate of the first type of virtual machine through a neural network model. Alternatively or additionally, the neural network model is a recurrent neural network model, e.g., a LSTM neural network. After inputting historical cost information corresponding to the first type of virtual machine, the length of the target time period, and the reference value into the neural network model, the corresponding interrupt rate will be obtained. [0054] In block 312, managing device 102 determines the interrupt rate of the first type of virtual machine again with the neural network model based on the length and the updated reference value, and then returns to block 306 to further determine whether the interrupt rate is lower than the interruption tolerance. [0057] In an embodiment of FIG. 4, managing device 102 includes application 104. Application 104 is provided with resource prediction module 404 corresponding to the application therein. Resource prediction module 404 is configured to predict a target time period in which a load rate of a computing resource exceeds a threshold load rate from a current moment and a computing resource to be used for running application 104 within the target time period. Resource prediction module 404 includes a neural network model. The neural network model is a recurrent neural network model, e.g., a LSTM neural network. Resource prediction module 404 achieves prediction of the target time period and the computing resource through the neural network model. [0058] Managing device 102 further includes a virtual machine prediction module 406. Virtual machine prediction module 406 receives a type of application 104 and the target time period from application 402. An acceptable interruption tolerance of application 104 may be determined based on the type of application 104. Then, virtual machine prediction module 406 determines costs corresponding to a plurality of different virtual machine types 408-1, 408-2, . . . , 408-M based on the interruption tolerance of application 104 and the length of the target time target, where M is a positive integer. Virtual machine prediction module 406 determines the costs for different virtual machine types through the neural network model. For example, for virtual machine type 408-1, an interrupt rate corresponding to virtual machine type 408-1 is predicted based on the length of the target time target, a reference value of the cost which is given in advance, and historical cost data associated with virtual machine type 408-1. If the predicted interrupt rate does not meet the interruption tolerance, the reference value is increased. Then, the interrupt rate is recomputed using the neural network model based on the increased reference value, until a reference value of the cost meeting the interruption tolerance is obtained. Then, the reference value in this case is used as an actual value of the cost. Therefore, actual values of a plurality of costs may be determined for a plurality of virtual machine models.)
As per claim 40, Zhang teaches wherein the capacity signal history data includes one or more of: server data, VM data, or eviction data including history data of evicting workloads from VMs, (Zhang Fig 2 Block 202 (Determining based on historical data associated ,with running of an application a target time period and a computing resource to be used for running the application within the target time period and [0043] In block 206, managing device 102 determines costs for running application 104 by a plurality of types [VM data] of virtual machines based on a length of the target time period and the interruption tolerance. The plurality of types of virtual machines are virtual machines from at least one cloud platform. To determine which type of virtual machine can be used for running application 104, it is necessary to determine a use cost of each type of virtual machine. A process of determining the cost is described in detail below in combination with FIG. 3.)
and wherein the trained machine-learning model is generated based on one or more of: random forests, and a neural network (Zhang [0037] In some embodiments, managing device 102 applies the historical data to a resource prediction model, to determine the target time period and the computing resource. In some embodiments, the resource prediction model is a recurrent neural network model. Alternatively or additionally, the recurrent neural network model is a long short-term memory (LSTM) neural network model. [0051] In block 304, managing device 102 determines an interrupt rate of the first type of virtual machine based on a length of a target time period and the reference value. In some embodiments, managing device 102 predicts the interrupt rate of the first type of virtual machine through a neural network model. Alternatively or additionally, the neural network model is a recurrent neural network model, e.g., a LSTM neural network. After inputting historical cost information corresponding to the first type of virtual machine, the length of the target time period, and the reference value into the neural network model, the corresponding interrupt rate will be obtained. [0054] In block 312, managing device 102 determines the interrupt rate of the first type of virtual machine again with the neural network model based on the length and the updated reference value, and then returns to block 306 to further determine whether the interrupt rate is lower than the interruption tolerance. [0057] In an embodiment of FIG. 4, managing device 102 includes application 104. Application 104 is provided with resource prediction module 404 corresponding to the application therein. Resource prediction module 404 is configured to predict a target time period in which a load rate of a computing resource exceeds a threshold load rate from a current moment and a computing resource to be used for running application 104 within the target time period. Resource prediction module 404 includes a neural network model. The neural network model is a recurrent neural network model, e.g., a LSTM neural network. Resource prediction module 404 achieves prediction of the target time period and the computing resource through the neural network model. [0058] Managing device 102 further includes a virtual machine prediction module 406. Virtual machine prediction module 406 receives a type of application 104 and the target time period from application 402. An acceptable interruption tolerance of application 104 may be determined based on the type of application 104. Then, virtual machine prediction module 406 determines costs corresponding to a plurality of different virtual machine types 408-1, 408-2, . . . , 408-M based on the interruption tolerance of application 104 and the length of the target time target, where M is a positive integer. Virtual machine prediction module 406 determines the costs for different virtual machine types through the neural network model. For example, for virtual machine type 408-1, an interrupt rate corresponding to virtual machine type 408-1 is predicted based on the length of the target time target, a reference value of the cost which is given in advance, and historical cost data associated with virtual machine type 408-1. If the predicted interrupt rate does not meet the interruption tolerance, the reference value is increased. Then, the interrupt rate is recomputed using the neural network model based on the increased reference value, until a reference value of the cost meeting the interruption tolerance is obtained. Then, the reference value in this case is used as an actual value of the cost. Therefore, actual values of a plurality of costs may be determined for a plurality of virtual machine models.)
As to claims 28 and 35, they are rejected based on the same reason as claim 21.
As to claim 28, Mitra teaches a processor (Fig 8 Block 810 (Processor))
a memory storing computer-executable instructions that when executed by the processor cause the system to: (Fig 8 Block 830 (non-Volatile Memory))
As per claim 35, Mitra teaches storage media ([0008] Any number of non-transitory machine-readable mediums (e.g., embedded memory, on-chip memory, read only memory, random access memory, solid state drives, and any other physical storage mediums) are used to encode instructions)
As to claims 30 and 37, they are rejected based on the same reason as claim 23.
As to claims 31 and 38, they are rejected based on the same reason as claim 24.
As to claims 32 and 39, they are rejected based on the same reason as claim 25.
As to claim 33, it is rejected based on the same reason as claim 26.
As to claim 34, it is rejected based on the same reason as claim 27.
Claims 22, 29 and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Mitra (US 2022/0374276 A1) in view of Zhang (US 2021/0247998 A1) in further view of Balasubramanian (US 2020/0409826 A1).
As per claim 22, Zhang teaches retrieving the trained machine-learning model for predicting the capacity of available computing resources for allocation to the VM type; generating, based on the trained machine-learning model, the capacity prediction data; (Zhang [0058] Managing device 102 further includes a virtual machine prediction module 406. Virtual machine prediction module 406 receives a type of application 104 and the target time period from application 402. An acceptable interruption tolerance of application 104 may be determined based on the type of application 104. Then, virtual machine prediction module 406 determines costs corresponding to a plurality of different virtual machine types 408-1, 408-2, . . . , 408-M based on the interruption tolerance of application 104 and the length of the target time target, where M is a positive integer. Virtual machine prediction module 406 determines the costs for different virtual machine types through the neural network model. For example, for virtual machine type 408-1, an interrupt rate corresponding to virtual machine type 408-1 is predicted based on the length of the target time target, a reference value of the cost which is given in advance, and historical cost data associated with virtual machine type 408-1. If the predicted interrupt rate does not meet the interruption tolerance, the reference value is increased. Then, the interrupt rate is recomputed using the neural network model based on the increased reference value, until a reference value of the cost meeting the interruption tolerance is obtained. Then, the reference value in this case is used as an actual value of the cost. Therefore, actual values of a plurality of costs may be determined for a plurality of virtual machine models).
Zhang does not teach receiving system status data of available computing resources in the cloud server and transmitting the capacity prediction data.
However, Balasubramanian teaches receiving system status data of available computing resources in the cloud server; (Balasubramanian [0148] Any suitable data about the system environment surrounding the application at the time of the performance event may be collected by data collecting agents 1250. Collected data may relate to hardware status, virtual infrastructure status, cloud resource status, CPU or other processor status, memory available and/or utilization, security structures and identified risks, traffic parameters including latency and/or call volume, runtime stack and/or other attributes of the runtime environment, JAVA stack, variable values, memory allocations, and the like).
Balasubramanian also teaches transmitting the capacity prediction data. (Balasubramanian Fig 4 and [0146] Monitoring application 1230 may correspond to monitoring application 430 of FIG. 4, but is illustrated with additional details of the smart database and machine learning aspects. Monitoring application 1230 may be configured to utilize monitoring interfaces 420 to monitor the status of application 401 and its dependencies, services 403a-n. Monitoring application 1230 may interface with intelligent services components including smart database 1247 and machine learning processes 1249 to enable use of artificial intelligence and/or machine learning techniques to generate predictions regarding system operating status and corrective actions [0163] At step 1325, the monitoring device may train a machine learning model based on a set of incident records. Once multiple event records are stored in the smart database, the machine learning processes may cluster the events and determine emergent trends and patterns of performance for use in generating predictions regarding operation of the monitored application.).
The examiner believes this is consistent with what is disclosed in the specification ([0038] The system status data 220 may include a snapshot of statuses of computing resources consumed and/or available in the cloud (or on a set of servers with virtual machines). For example, the capacity prediction generator 222 predicts capacity available and eviction rates on respective types of VMs).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Balasubramanian with the system of Mitra and Zhang to receive system status data of available computing resources in the cloud server. One having ordinary skill in the art would have been motivated to use Balasubramanian into the system of Mitra and Zhang for the purpose of providing for enhanced monitoring of application health and facilitate identifying dependencies causing reduced system performance. (Balasubramanian paragraph 10)
As to claims 29 and 36, they are rejected based on the same reason as claim 22.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20230055463 A1 – discloses determining third party network compliance with a host entity network is provided. The method may include generating a scanning file that includes host entity network compliance standards and transferring the scanning file to an intermediary entity network. The method may further include generating an executable file that may run a plug-in scanning file to scan hardware and software resident at the third-party network for compliance. The method may further include transferring the executable file from the intermediary entity network to the third party network. The method may further include executing the executable file, generating a log file upon the completion of the running of the plug-in scanning file and digitally signing the log file. The method may further include deciphering the log file at the intermediary entity network, generating a readable report based on the deciphering and transferring the readable report to the host entity network.
US 20220129798 A1 – discloses extending a semantic model, for use with an analytic applications, analytics cloud, or other type of business intelligence or data analytics environment. A semantic model extension process introspects a customer's data, for example as stored in a data warehouse instance, and evaluates metadata associated therewith to determine custom facts, custom dimensions, and/or other types of data source model extensions. A payload or indication of such extensions is used to extend or customize a semantic model that enables surfacing of business intelligence or data analytics at a presentation layer. In accordance with an embodiment, the system can include an administrative console application and user interface that allows a user to view and validate a customer's data as loaded from their source environment into a data warehouse instance for use with other types of data analytics environments.
US 20200314146 A1 – discloses quickly and easily create one or more courses of action for automatic response to a network threat. The courses of action are hardware and system agnostic, which allows a common response task to be implemented by an underlying response engine for any or multiple similar-function devices regardless of brand or version. The course of action builder allows the administrator to use a simple, graphic-based, business modeling concept to craft and design security response processes rather than having to hard code response routines specific to each piece of hardware on the network. The graphic interface model allows the user of the threat response software incorporating the course of action builder to easily understand the overall flow and paths the response may take, as well as understand the data requirements and dependencies that will be evaluated.
US 20190213104 A1 – discloses facilitating cloud validation using validation as a service (VaaS). A cloud validation service provider acquires and securely stores certification tests developed by cloud component providers, integrated solution providers, and others. Each test's executable portion tests hardware or software of a candidate cloud. The candidate may be on the premises of an enterprise, or instead be a hosted cloud on the premises of a hoster off the premises of the entity that pays for the hosting. Monitored testing is done using an infrastructure in the candidate cloud or in a public cloud. Results are uploaded to the VaaS provider, which provides an analysis of test results for use in determining whether to validate the candidate cloud. Test execution agents may be VaaS-cloud-resident or candidate-cloud-resident, and may use a mutex to prevent simultaneous execution of tests. Testing may be accomplished even when the candidate cloud has no internet-exposed communication endpoint.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHRAN KAMRAN whose telephone number is (571)272-3401. The examiner can normally be reached on 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached on (571)270-1014. 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.
/MEHRAN KAMRAN/ Primary Examiner, Art Unit 2196
Prosecution Insights