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 .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Alok Kumbhare et. al. (Prediction-Based Power Oversubscription in Cloud Platforms, 2021), hereinafter Kumbhare.
Regarding claim 1, Kumbhare recites:
A processing system, comprising: a first compute group having a first power target; a second compute group having a second power target; and a hypervisor configured to allocate at least a portion of the first compute group or at least a portion of the second compute group to a virtual machine based on whether a performance setting of the virtual machine indicates the first power target or the second power target. (see e.g., page [011], right column, paragraph [01-02], “We have deployed our per-VM capping controller and ML models on thousands of servers in multiple datacenters." The capping mentioned is power capping (and the cap itself could be considered a "target", just as setting a maximum [language is funny like that])) (See also e.g., page [011], right column, paragraph [02-03], “Instead, we had to extend the hypervisor to (1) add the capability to dynamically specify the frequency for a VM, and (2) carry the frequency to whichever cores it schedules the VM on during the context switch.”)
Regarding claim 2, Kumbhare recites:
The processing system of claim 1, wherein the processing system further comprises: a first power rail configured to provide a first voltage to the first compute group; and a second power rail configured to provide a second voltage to the second compute group, wherein the first voltage is different from the second voltage. (see e.g., page [01], right column, paragraph [01], “This is achieved by continuously monitoring the power draw at each level and using power capping (via CPU voltage/frequency and memory bandwidth throttling), when necessary.”) The Examiner would like to clarify that the power rail is not defined in the specification, and the common definition would not make sense in this context (copper etchings on motherboards and other circuit boards), so the term is being treated as something to transfer voltages to compute groups, which is covered by the following quote: (see e.g., page [006], left column, paragraph [04-05], “Upon receiving an alert from the chassis manager, the perVM power controller compares the server's power draw to its budget. If the current draw is higher than the budget, the controller immediately lowers the frequency of the low-priority cores to the minimum p-state, i.e. half of the maximum frequency; the lowering of the frequency may entail a lower voltage as well.”) The power controller lowers the frequency/voltage, and that must be done through some form of power transfer. In this case, there being multiple VMs with different voltages means that there must be something delivering that power separately, otherwise the voltage would not be different.
Regarding claim 3, Kumbhare recites:
The processing system of claim 2, further comprising: a dynamic voltage and frequency scaling circuitry configured to: modify the first voltage based on a trigger event. (see e.g., page [006], left column, paragraph [04-05], “Upon receiving an alert from the chassis manager, the perVM power controller compares the server's power draw to its budget. If the current draw is higher than the budget, the controller immediately lowers the frequency of the low-priority cores to the minimum p-state, i.e. half of the maximum frequency; the lowering of the frequency may entail a lower voltage as well.”) The trigger event is an the “current draw is higher than the budget” comparison in response to the chassis manager alert.
Regarding claim 4, Kumbhare recites:
The processing system of claim 3, wherein the trigger event includes at least one selected from a group consisting of a predetermined number of VMs being launched, a predetermined amount of time elapsing, or a power emergency occurring. (see e.g., page [006], left column, paragraph [04-05], “Upon receiving an alert from the chassis manager, the per-VM power controller compares the server's power draw to its budget. If the current draw is higher than the budget, the controller immediately lowers the frequency of the low-priority cores to the minimum p-state, i.e. half of the maximum frequency; the lowering of the frequency may entail a lower voltage as well.”) The power draw being higher than its budget would be an indication of how many VMs are active, and a chassis manager alert could be considered an “emergency” as well (i.e., something that must be taken care of immediately).
Regarding claim 5, Kumbhare recites:
The processing system of claim 1, wherein the processing system further comprises: a first clock circuitry configured to provide a first clock signal to the first compute group; and a second clock circuitry configured to provide a second clock signal to the second compute group, wherein the first clock signal is different from the second clock signal. (see e.g., page [006], left column, paragraph [04-05], “Upon receiving an alert from the chassis manager, the perVM power controller compares the server's power draw to its budget. If the current draw is higher than the budget, the controller immediately lowers the frequency of the low-priority cores to the minimum p-state, i.e. half of the maximum frequency;”) The power controller could be considered a clock circuitry, and as there is one per VM, each signal would be separate and distinct as the VM is separate and distinct.
Regarding claim 6, Kumbhare recites:
The processing system of claim 1, wherein: the first power target is associated with a first voltage and the second power target is associated with a second voltage that is different from the first voltage. (see e.g., page [011], right column, paragraph [02-03], “Instead, we had to extend the hypervisor to (1) add the capability to dynamically specify the frequency for a VM, and (2) carry the frequency to whichever cores it schedules the VM on during the context switch.") (see also e.g., page [006], left column, paragraph [04-05], “the lowering of the frequency may entail a lower voltage as well.”) (see e.g., page [006], left column, paragraph [04-05], “Upon receiving an alert from the chassis manager, the perVM power controller compares the server's power draw to its budget. If the current draw is higher than the budget, the controller immediately lowers the frequency of the low-priority cores to the minimum p-state, i.e. half of the maximum frequency;”) (see e.g., page [008], right column, paragraph [03-04], “The frequency curve depicts the adjustments that our controller makes to the performance of the non-user-facing VM. The steep drop to the lowest frequency occurs when the controller abruptly lowers the frequency to the minimum value when the power first exceeds the target. After that, its feedback component smoothly increases and decreases the frequency.”) Each VM’s power target (target voltage) is set via the power controller, which is managed separately from the other VMs, as each VM has its own controller (see: perVM power controller)
Regarding claim 7, Kumbhare recites:
The processing system of claim 1, wherein the first compute group includes a first set of processor cores of one or more chiplets and the second compute group includes a second set of processor cores of one or more other chiplets, and wherein the first set of processor cores is different from the second set of processor cores. (see e.g., page [002], right column, paragraph [01], “Similarly, although we focus on VMs, our contributions also apply to containers running on bare-metal servers. As providers want to maximize the use of their servers via multi-tenancy, each container typically runs on a lightweight VM for security isolation [3, 32]. We can treat these VMs like any other. For scenarios where isolation between containers is not required, we can treat the whole server as a single workload or adapt our software to treat containers as we treat VMs.”) If each VM is separate in the focus of this paper, but they say it can be applied directly to containers running on a VM, that would mean that those containers would inherit the qualities that the paper is describing (containers would be separate), and would be able to do the other tasks described by the paper.
Claim 8 recites A method, comprising: the same steps that the processing system of claim 1 is configured to perform. Therefore, claim 8 is rejected for the same reasons provided for claim 1.
Claims 9, 10, and 14 recites substantially the same limitations as claims 2, 5, and 7 respectively, but applied to the method of claim 8.
Regarding claim 11, Kumbhare recites:
The method of claim 10, further comprising: modifying the first clock signal based on a trigger event. (see e.g., page [006], left column, paragraph [04-05], “Upon receiving an alert from the chassis manager, the perVM power controller compares the server's power draw to its budget. If the current draw is higher than the budget, the controller immediately lowers the frequency of the low-priority cores to the minimum p-state, i.e. half of the maximum frequency; the lowering of the frequency may entail a lower voltage as well.”) The examiner would like to note that the Specification mentions that the clock signal is something provided to the various compute islands in order to change the target operating frequency or the target operating voltage or both. Therefore, any request to change those things can be considered a clock signal.
Regarding claim 12, Kumbhare recites:
The method of claim 11, wherein the trigger event includes at least one selected from a group consisting of a predetermined number of VMs being launched, a predetermined amount of time elapsing, or a power emergency occurring. (see e.g., page [006], left column, paragraph [04-05], “Upon receiving an alert from the chassis manager, the per-VM power controller compares the server's power draw to its budget. If the current draw is higher than the budget, the controller immediately lowers the frequency of the low-priority cores to the minimum p-state, i.e. half of the maximum frequency; the lowering of the frequency may entail a lower voltage as well.”)
Regarding claim 13, Kumbhare recites:
The method of claim 8, wherein: the first power target is associated with a first operating frequency and the second power target is associated with a second operating frequency that is different from the first operating frequency. (see e.g., page [011], right column, paragraph [02-03], “Instead, we had to extend the hypervisor to (1) add the capability to dynamically specify the frequency for a VM, and (2) carry the frequency to whichever cores it schedules the VM on during the context switch.") (see also e.g., page [006], left column, paragraph [04-05], “the lowering of the frequency may entail a lower voltage as well.”)
Claim 15 recites A system on a chip, comprising: a first set of processor cores assigned a first power target; a second set of processor cores assigned a second power target; and a dynamic voltage and frequency scaling circuitry configured to: perform the same steps that the processing system described by claim 1. Therefore, claim 15 is rejected for the same reasons provided for claim 1.
Regarding claim 16, Kumbhare recites:
The system on a chip of claim 15, further comprising: a first power rail configured to provide a first voltage to the first set of processor cores; and a second power rail configured to provide a second voltage to the second set of processor cores, wherein the first voltage is different from the second voltage. (see e.g., page [01], right column, paragraph [01], “This is achieved by continuously monitoring the power draw at each level and using power capping (via CPU voltage/frequency and memory bandwidth throttling), when necessary.”) The Examiner would like to clarify that the power rail is not defined in the specification, and the common definition would not make sense in this context (copper etchings on motherboards and other circuit boards), so the term is being treated as something to transfer voltages to compute groups, which is covered by the following quote: (see e.g., page [006], left column, paragraph [04-05], “Upon receiving an alert from the chassis manager, the perVM power controller compares the server's power draw to its budget. If the current draw is higher than the budget, the controller immediately lowers the frequency of the low-priority cores to the minimum p-state, i.e. half of the maximum frequency; the lowering of the frequency may entail a lower voltage as well.”) The power controller lowers the frequency/voltage, and that must be done through some form of power transfer. In this case, there being multiple VMs with different voltages means that there must be something delivering that power separately, otherwise the voltage would not be different. The trigger event is an the “current draw is higher than the budget” comparison in response to the chassis manager alert.
Regarding claim 17, Kumbhare recites:
The system on a chip of claim 16, wherein the dynamic voltage and frequency scaling circuitry is configured to: modify the second voltage based on the trigger event such that the second set of processor cores is changed from the operating frequency associated with the first power target to the operating frequency associated with the second power target. (see e.g., page [006], left column, paragraph [04-05], “the lowering of the frequency may entail a lower voltage as well.”)
Claims 18, 19, and 20 recite substantially the same limitations as claims 5, 11, and 13 respectively, applied to the system on a chip of claim 15. Therefore, claims 18, 19, and 20 are rejected for the same reasons provided for claims 5, 11, and 13 respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Connor Imiola Blackburn whose telephone number is (571)272-6547. The examiner can normally be reached M-Th 7-5.
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, Kevin Young can be reached at (571) 270 - 3180. 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.
/C.I.B./ Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights