DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 02/13/2026.
Claims 26, 33, 39, and 40 have been amended.
Claims 26-45 are currently pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AlA first to invent provisions.
Response to Arguments
Applicant’s arguments filed 02/13/2026 with respect to the double patenting rejections to claims 26-45 that “Applicant respectfully traverses and requests reconsideration” (Remarks pg. 8) have been fully considered but are unpersuasive. The double patenting rejections to claims 26-45 have accordingly been maintained.
Applicant’s arguments filed 02/13/2026 with respect to the rejections under 35 USC § 103 have been fully considered but are unpersuasive and/or moot in view of the new grounds of rejection as described below.
On pg. 9 of the Remarks Applicant essentially argues:
“In contrast, Grouzdev is directed to a course[sic] level system that is unaware of processor core level virtual machine power control setting requests that include a range of operating frequencies for one or more engines of a graphics processing core. The office action admits that Grouzdev does not "disclose a graphics processing core as an exemplary device" and cites to Gupta for teaching what Grouzdev lacks. The VM of Grouzdev is a coarse level control system that controls on a "device" level. Also, the "CPU device" is considered a separate device from a PCI device (see 0014-0016). Also Grouzdez teaches to use a course device control”
Examiner notes controlling the power level of an integrated circuit device at a ‘device level’ inherently controls the power level of at least one of functional component/block (engine) that forms the device, and Applicant’s claims as written do not preclude ‘coarse’/‘device level’ control actions from teaching the limitation. Regarding GPU subsystem/engine level control Examiner additionally refers to Alben et al. (US 2005/0268141 A1) cited in the rejections for claims 30, 37, and 43; Applicant admitted prior art AppSpec FIG. 1 and ¶0024-0025; and the references cited but not relied upon in the conclusion section of this action.
On pg. 9 of the Remarks Applicant essentially argues:
Also Grouzdez teaches to use a course device control and teaches for a device, simply to use "the maximum power state" from respective power states asserted by the virtual machines and states in cited paragraph 0014: "For example, the power state chosen for the device may be the maximum power state from the respective power states asserted by the virtual machines." There is no overlap as claimed being used in Grouzdev and no controller that controls a power level of at least one engine of the graphics processing core based on an overlap of minimum and maximum frequencies of at least one of the plurality of engines corresponding with the first virtual machine power control setting request and minimum and maximum frequencies of at least one of the plurality of engines corresponding with the second virtual machine power control setting request.
Examiner respectfully disagrees that “There is no overlap as claimed being used in Grouzdev and no controller that controls…based on an overlap of minimum and maximum frequencies”. Grouzdev VM’s requested performance state (P-state) represents the minimum processor device P-state required by the VM (“the device is not put into a state that results in lower power and/or lower performance of the device as requested by any of the virtual machines” (¶0034)). Thus, each request corresponds to a range of frequencies suitable for operating the VM delineated by the requested P-state’s frequency1 (minimum frequency) and the device’s highest supported frequency (maximum frequency), and the highest/maximum requested P-state, that is used as the controlling request, defines the area where the ranges overlap. This interpretation is consistent with the description in Applicant’s as-filed Specification (AppSpec) ¶0046 “Blending” example where one of the VM’s requests only specifies the (minimum) required frequency:
“Default graphics engine frequency range: 100 MHz to 900 MHz…Assume VM2 uses 4 displays. To support necessary display bandwidth, VM2 requires a graphics frequency at least 250 MHz and memory frequency at least 400 MHz. Therefore, VM2 has a graphics engine frequency range of 250 MHz to 900 MHz”
Given a plurality of requests in the form of exemplary VM2’s, Applicant’s ‘blended’ range overlap would be that defined by the largest/’maximum’ of the requested frequencies, equivalent to Grouzdev’s method.
Applicant’s remaining arguments regarding applying Grouzdev’s method to a graphics processing core (GPU) are moot in view of new grounds for rejection Nikazm a “multiple graphics processing core system” (¶0003) that employs an integrated graphics processing unit (iGPU) and PCI based a discrete graphics processing unit (dGPU) wherein “each GPU may itself be capable of running at different performance-states (p-states). P-states may generally refer to a processor's ability to operate at lower capability states. Specifically, a processor operating at a particular p-state may have certain attributes reduced or scaled back such as its clock frequency” (Nikazm ¶0021).
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 time-wise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory 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); 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 non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to:
www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 26-45 of the instant Application (“AppClaims”) are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-3, 5-7, 13, and 19-21 of U.S. Patent No. US 10,095,295 B2 (“PatClaims”) as shown in the mapping below.
AppClaim 26 Anticipated by --------------->
Broader limitations directed to essentially same subject matter.
A method comprising:
receiving a first virtual machine power control setting request associated with a first virtual machine and a second virtual machine power control setting request associated with a second virtual machine; and
controlling a power level of at least one engine of a plurality of engines of a graphics processing core based on an overlap of at least one operating range setting between the first and second virtual machine power control setting requests, the overlap being based on an overlap of minimum and maximum frequencies of at least one of the plurality of engines corresponding with the first virtual machine power control setting request and minimum and maximum frequencies of at least one of the plurality of engines corresponding with the second virtual machine power control setting request.
PatClaim 1
A method comprising:
processing a plurality of virtual machine power control setting requests including a first virtual machine power control setting request and a second virtual machine power control setting request by blending the plurality of virtual machine power control setting requests together to determine a power control request for a power management unit of a graphics processing core, wherein each of the first and second virtual machine power control setting requests is associated with a respective virtual machine requirement defined by a minimum frequency and a maximum frequency and wherein blending includes determining an overlap of the minimum and maximum frequencies of the first virtual machine power control setting request and the second virtual machine power control setting request; and
controlling power levels of the graphics processing core with the power management unit based on the determined overlap of the minimum and maximum frequencies between the first and second virtual machine power control setting requests.
AppClaim 27 Anticipated by --------------->
Limitation recited.
PatClaim 2
AppClaim 28 Anticipated by --------------->
Limitation recited.
PatClaim 3
AppClaim 29 Anticipated by --------------->
Limitation recited.
PatClaim 5
AppClaim 30 Anticipated by --------------------->
Limitation recited.
PatClaim 6
AppClaim 31 Anticipated by --------------------->
Limitation recited.
PatClaim 7
AppClaim 32 Anticipated by --------------------->
Limitation recited.
PatClaim 1
AppClaim 33 Anticipated by --------------------->
Broader limitations directed to essentially same subject matter
An apparatus comprising:
a graphics processing core comprising a plurality of engines and operative to host a first virtual machine and a second virtual machine;
a power management unit configured to control power levels of the graphics processing core based on a power control request; and
a controller in operative communication with the power management unit, and responsive to a first virtual machine power control setting request associated with the first virtual machine and a second virtual machine power control setting request associated with the second virtual machine, the controller being operable to generate the power control request that controls a power level of at least one engine of a plurality of engines of the graphics processing core based on an overlap of at least one operating range setting between the first and second virtual machine power control setting requests, the overlap being based on an overlap of minimum and maximum frequencies of at least one of the plurality of engines corresponding with the first virtual machine power control setting request and minimum and maximum frequencies of at least one of the plurality of engines corresponding with the second virtual machine power control setting request.
PatClaim 19
An apparatus comprising:
a graphics processing core operative to host a plurality of virtual machines;
a power management unit configured to control power levels of the graphics processing core based on a power control request; and
a blending and arbitration module in operative communication with the power management unit, the blending and arbitration module being operable to process a plurality of virtual machine power control setting requests including a first virtual machine power control setting request and a second virtual machine power control setting request to determine the power control request for use by the power management unit by blending the plurality of virtual machine power control setting requests together to determine the power control request for the power management unit, wherein each of the first and second virtual machine power control setting requests is associated with a respective virtual machine requirement defined by a minimum frequency and a maximum frequency and wherein blending includes determining an overlap of the minimum and maximum frequencies of the first virtual machine power control setting request and the second virtual machine power control setting request.
AppClaim 34 Anticipated by --------------------->
Limitation recited.
PatClaim 20
AppClaim 35 Anticipated by --------------------->
Limitation recited.
PatClaim 21
AppClaim 36 Obvious Variation of ------------->
Broader limitations directed to essentially same subject matter, differing in statutory category.
PatClaim 1 + 5
AppClaim 37 Anticipated by --------------------->
PatClaim 1
AppClaim 38 Anticipated by --------------------->
(Inherent) compare the first and second virtual machine power control setting requests and determine the power control request
PatClaim 19
blending the plurality of virtual machine power control setting requests together to determine the power control request…blending includes determining an overlap of the minimum and maximum frequencies of the first virtual machine power control setting request and the second virtual machine power control setting request
AppClaim 39 Anticipated by --------------------->
Broader limitations directed to essentially same subject matter; additionally recites the host CPU as an element, inherent to PatClaim 19.
A system comprising:
a first processor;
a second processor, operatively coupled to the first processor, and operative to host a first virtual machine and a second virtual machine, the second processor comprising a graphics processing core comprising a plurality of engines;
a power management unit configured to control power levels of the graphics processing core based on a power control request; and
a controller in operative communication with the power management unit, and responsive to a first virtual machine power control setting request associated with the first virtual machine and a second virtual machine power control setting request associated with the second virtual machine, the controller being operable to generate the power control request that controls a power level of at least one engine of a plurality of engines of the graphics processing core based on an overlap of at least one operating range setting between the first and second virtual machine power control setting requests, the overlap being based on an overlap of minimum and maximum frequencies of at least one of the plurality of engines corresponding with the first virtual machine power control setting request and minimum and maximum frequencies of at least one of the plurality of engines corresponding with the second virtual machine power control setting request.
PatClaim 19
An apparatus comprising:
[Inherent CPU running VMs/hypervisor]
a graphics processing core operative to host a plurality of virtual machines;
a power management unit configured to control power levels of the graphics processing core based on a power control request; and
a blending and arbitration module in operative communication with the power management unit, the blending and arbitration module being operable to process a plurality of virtual machine power control setting requests including a first virtual machine power control setting request and a second virtual machine power control setting request to determine the power control request for use by the power management unit by blending the plurality of virtual machine power control setting requests together to determine the power control request for the power management unit, wherein each of the first and second virtual machine power control setting requests is associated with a respective virtual machine requirement defined by a minimum frequency and a maximum frequency and wherein blending includes determining an overlap of the minimum and maximum frequencies of the first virtual machine power control setting request and the second virtual machine power control setting request.
AppClaim 40 Anticipated by --------------------->
Limitation recited.
PatClaim 20
AppClaim 41 Anticipated by --------------------->
Limitation recited.
PatClaim 21
AppClaim 42 Obvious Variation of ------------->
Broader limitations directed to essentially same subject matter, differing in statutory category.
PatClaim 1 + 5
AppClaim 43 Obvious Variation of ------------->
Broader limitations directed to essentially same subject matter, differing in statutory category.
PatClaim 1 + 6
AppClaim 44 Anticipated by --------------------->
(Inherent) compare the first and second virtual machine power control setting requests and determine the power control request for the power management unit based on the comparison.
PatClaim 19
blending the plurality of virtual machine power control setting requests together to determine the power control request…blending includes determining an overlap of the minimum and maximum frequencies of the first virtual machine power control setting request and the second virtual machine power control setting request
AppClaim 45 Obvious Variation of ------------->
Broader limitations directed to essentially same subject matter, differing in statutory category.
PatClaim 13
Claims 26-28, 31-35, 38-41, and 44 of the instant Application (“AppClaims”) are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 7, 10, and 12 of U.S. Patent No. US 11,782,494 B2 (“PatClaims”) as shown in the mapping below.
AppClaim 26 Anticipated by --------------->
Broader limitations directed to essentially same subject matter.
A method comprising:
receiving a first virtual machine power control setting request associated with a first virtual machine and a second virtual machine power control setting request associated with a second virtual machine; and
controlling a power level of at least one engine of a plurality of engines of a graphics processing core based on an overlap of at least one operating range setting between the first and second virtual machine power control setting requests,
the overlap being based on an overlap of minimum and maximum frequencies of at least one of the plurality of engines corresponding with the first virtual machine power control setting request and minimum and maximum frequencies of at least one of the plurality of engines corresponding with the second virtual machine power control setting request.
PatClaim 1 + 7
A method comprising:
receiving a plurality of virtual machine power control setting requests for a plurality of virtual machines…
…controlling power levels of the graphics processing core with the power management unit based on the selected power control request
[Clm 7]blending the plurality of virtual machine power control setting requests together to determine the determined power control request for the power management unit..
…each virtual machine power control setting request including a range of operating frequencies of a graphics processing core and having a different minimum operating frequency and wherein each of the range of operating frequencies is suitable for operating a respective one of the plurality of virtual machines
AppClaim 27 Anticipated by --------------->
Limitation recited in PatClaim 1.
PatClaim 1 + 7
AppClaim 28 Anticipated by --------------->
Limitation recited in PatClaim 1.
PatClaim 1 + 7
AppClaim 31 Anticipated by --------------------->
Inherent to “blending”.
PatClaim 1 + 7
AppClaim 32 Anticipated by --------------->
Limitation recited in PatClaim 1.
PatClaim 1 + 7
AppClaim 33 Anticipated by --------------------->
Broader limitations directed to essentially same subject matter
An apparatus comprising:
a graphics processing core comprising a plurality of engines and operative to host a first virtual machine and a second virtual machine;
a power management unit configured to control power levels of the graphics processing core based on a power control request; and
a controller in operative communication with the power management unit, and responsive to a first virtual machine power control setting request associated with the first virtual machine and a second virtual machine power control setting request associated with the second virtual machine, the controller being operable to generate the power control request that controls a power level of at least one engine of a plurality of engines of the graphics processing core based on an overlap of at least one operating range setting between the first and second virtual machine power control setting requests
the overlap being based on an overlap of minimum and maximum frequencies of at least one of the plurality of engines corresponding with the first virtual machine power control setting request and minimum and maximum frequencies of at least one of the plurality of engines corresponding with the second virtual machine power control setting request.
PatClaim 10 + 12
An apparatus comprising:
a graphics processing core operative to host a plurality of virtual machines;
a power management unit configured to control power levels of a plurality of engines of the graphics processing core based on a power control request; and
a blending and arbitration module in operative communication with the power management unit, the blending and arbitration module being operable to process a plurality of virtual machine power control setting requests corresponding to the plurality of virtual machines…determine the power control request for use by the power management unit by…blend the plurality of virtual machine power control setting requests together to determine the determined power control request for the power management unit...
each including a range of operating frequencies of the graphics processing core having a different minimum operating frequency and wherein each of the range of operating frequencies is suitable for operating a respective one of the plurality of virtual machines,
AppClaim 34 Anticipated by --------------------->
Limitation recited in PatClaim 10.
PatClaim 10 + 12
AppClaim 35 Anticipated by --------------------->
Limitation recited in PatClaim 10.
PatClaim 10 + 12
AppClaim 38 Anticipated by --------------------->
Inherent to “blending”.
PatClaim 10 + 12
AppClaim 39 Anticipated by --------------------->
Broader limitations directed to essentially same subject matter; additionally recites the host CPU as an element, inherent to PatClaim 19.
A system comprising:
a first processor;
a second processor, operatively coupled to the first processor, and operative to host a first virtual machine and a second virtual machine, the second processor comprising a graphics processing core comprising a plurality of engines;
a power management unit configured to control power levels of the graphics processing core based on a power control request; and
a controller in operative communication with the power management unit, and responsive to a first virtual machine power control setting request associated with the first virtual machine and a second virtual machine power control setting request associated with the second virtual machine, the controller being operable to generate the power control request that controls a power level of at least one engine of a plurality of engines of the graphics processing core based on an overlap of at least one operating range setting between the first and second virtual machine power control setting requests
the overlap being based on an overlap of minimum and maximum frequencies of at least one of the plurality of engines corresponding with the first virtual machine power control setting request and minimum and maximum frequencies of at least one of the plurality of engines corresponding with the second virtual machine power control setting request.
PatClaim 10 + 12
An apparatus comprising:
[Inherent CPU running VMs/hypervisor]
a graphics processing core operative to host a plurality of virtual machines;
a power management unit configured to control power levels of a plurality of engines of the graphics processing core based on a power control request; and
a blending and arbitration module in operative communication with the power management unit, the blending and arbitration module being operable to process a plurality of virtual machine power control setting requests corresponding to the plurality of virtual machines…determine the power control request for use by the power management unit by…blend the plurality of virtual machine power control setting requests together to determine the determined power control request for the power management unit…
…requests…each including a range of operating frequencies of the graphics processing core having a different minimum operating frequency and wherein each of the range of operating frequencies is suitable for operating a respective one of the plurality of virtual machines,
AppClaim 40 Anticipated by --------------------->
Limitation recited in PatClaim 10.
PatClaim 10 + 12
AppClaim 41 Anticipated by --------------------->
Limitation recited in PatClaim 10.
PatClaim 10 + 12
AppClaim 44 Anticipated by --------------------->
Inherent to “blending”.
PatClaim 10 + 12
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 26, 27, 29, 31, 33, 34, 36, 38-40, 42, 44, and 45 are rejected under 35 U.S.C. 103 as being unpatentable over Grouzdev (US 2010/0162242 A1) in view of Nikazm (US 2010/0138675 A1).
Claim 26:
Grouzdev discloses the limitations as shown in the following rejections:
receiving a first virtual machine [VM] power control setting request (ACPI power state assertions/requests/method invocations) associated with a first VM and a second VM power control setting request associated with a second VM (see at least ¶0014, 0017-0019, 0033-0036, 0044; FIG. 2).
controlling a power level of at least one engine (functional block/component) of a plurality of engines of a (see below in view of Nikazm regarding GPU) based on an overlap of at least one operating range (frequency range(s) defined by requested min performance states (P-states)) setting between the first and second VM power control setting requests (see at least ¶0014, 0034-0039).
“Where multiple virtual machines assert using the virtual ACPI functionality that the device should be in a respective power state, then embodiments of the invention determine a power state for the device from the power states as asserted by the virtual machines. For example, the power state chosen for the device may be the maximum power state from the respective power states asserted by the virtual machines (¶0014)…A virtual device state may comprise, for example, a power state, performance state and/or clock throttling state of the device. The "maximum" principle selects the maximum power state and/or maximum performance state for the device, or the clock throttling state that results in maximum performance of the device. Thus, the device is not put into a state that results in lower power and/or lower performance of the device as requested by any of the virtual machines, while at the same time at least some power saving or performance reduction may be achieved.”
the overlap being based on an overlap of minimum (requested performance state (p-state)) and maximum frequencies (highest p-state supported by processor) of at least one of the plurality of engines corresponding with the first virtual machine power control setting request and minimum and maximum frequencies of at least one of the plurality of engines corresponding with the second virtual machine power control setting request (see at least ¶0014, 0033-0036) disclosing each VM requesting a processor device performance state (P-state) representing the minimum P-state required by the VM for the device (“the device is not put into a state that results in lower power and/or lower performance of the device as requested by any of the virtual machines” (¶0034)). Thus, each request corresponds to a range of frequencies suitable for operating the VM delineated by the requested P-state’s frequency2 (minimum frequency) and the device’s highest supported frequency (maximum frequency), and the highest/maximum requested P-state, that is used as the controlling request, corresponds to the area where the ranges overlap. See ‘Response to Arguments’ above for further discussion.
As shown above, Grouzdev discloses (¶0034) P-state control for processor devices generally and discloses (¶0015, 0017, 0031, 0039) the power controlled “devices may include...expansion devices such as PCI cards” (¶0017), but does not specifically disclose a graphics processing core (GPU) as an exemplary device.
However, GPUs are a well-known type of PCI device and, as shown by Nikazm disclosing a “multiple graphics processing core system” (¶0003) that employs an integrated graphics processing unit (iGPU) and a discrete graphics processing unit (dGPU) connected “via a dedicated graphics interface such as a Peripheral Component Interconnect Express Graphics (PEG) interface” (¶0023). Nikazm further discloses (¶0021-0022, 0026-0027), that “each GPU may itself be capable of running at different performance-states (p-states). P-states may generally refer to a processor's ability to operate at lower capability states. Specifically, a processor operating at a particular p-state may have certain attributes reduced or scaled back such as its clock frequency” (Nikazm ¶0021).
It would have been obvious to one of ordinary skill in the art at the time of the invention to apply Grouzdev’s methods of coordinated power management to the GPU system of Nikazm in order to save power while maintaining VM performance (Grouzdev ¶0034), and because it represents the application of a known technique to improve similar devices (Grouzdev’s P-state enable processor and Nikazm’s P-state enable GPUs) in the same way (Nikazm ¶0021-0022).
Claim 27:
The combination of Grouzdev/Nikazm discloses the limitations as shown in the rejections above. Grouzdev further discloses selecting one of the first or second power control setting requests as a power control request for a power management unit (¶0014, 0034-0039).
Claim 29:
The combination of Grouzdev/Nikazm discloses the limitations as shown in the rejections above. Furthermore, the combination of Grouzdev/Nikazm discloses discloses wherein controlling the power level of at least one engine of the plurality of engines of the graphics processing core comprises turning the at least one engine of the graphics processing core on and off in at least Grouzdev {¶0038-0039 disclosing requests to control power levels for and turn on/off PCI devices (including constituent functional blocks) in view of Nikazm ¶0020-0022. See also Applicant FIG. 1.
Claim 31:
The combination of Grouzdev/Nikazm discloses the limitations as shown in the rejections above. Furthermore, Grouzdev discloses comparing the first and second VM power control setting requests and determining the power control request for a power management unit based on the comparison (¶0014, 0034-0039).
Claims 33 and 39:
Grouzdev discloses the limitations as shown in the following rejections:
a first processor; a second processor, operatively coupled to the first processor, and operative to host a first VM and a second VM, the second processor comprising [PCI device and/or processor device, see below in view of Nikazm regarding “graphics processing core”] comprising a plurality of engines; a power management unit (ACPI power control) configured to control power levels of the [PCI/processor device] based on a power control request (see at least ¶0013-0015, 0018, 0028, 0038-0039; FIG. 1).
a controller (VMM vACPI/ACPI control) in operative communication with the power management unit, and responsive to a first VM power control setting request (ACPI power state assertions/requests/method invocations) associated with the first VM and a second VM power control setting request associated with the second VM, the controller being operable to generate the power control request (actual power state setting) that controls a power level of at least one engine of a plurality of engines of the [PCI/processor device] based on an overlap of at least one operating range (frequency range(s) defined by requested min P-states) setting between the first and second VM power control setting requests ((see at least ¶0014, 0033-0039).
the overlap being based on an overlap of minimum (requested performance state (p-state)) and maximum frequencies (highest p-state supported by processor) of at least one of the plurality of engines corresponding with the first virtual machine power control setting request and minimum and maximum frequencies of at least one of the plurality of engines corresponding with the second virtual machine power control setting request (see at least ¶0014, 0033-0036) disclosing each VM requesting a processor device performance state (P-state) representing the minimum P-state required by the VM for the device (“the device is not put into a state that results in lower power and/or lower performance of the device as requested by any of the virtual machines” (¶0034)). Thus, each request corresponds to a range of frequencies suitable for operating the VM delineated by the requested P-state’s frequency (minimum frequency) and the device’s highest supported frequency (maximum frequency), and the highest/maximum requested P-state, that is used as the controlling request, corresponds to the area where the ranges overlap. See ‘Response to Arguments’ above for further discussion.
As shown above, Grouzdev discloses (¶0034) P-state control for processor devices generally and discloses (¶0015, 0017, 0031, 0039) the power controlled “devices may include...expansion devices such as PCI cards” (¶0017), but does not specifically disclose a graphics processing core (GPU) as an exemplary device.
However, GPUs are a well-known type of PCI device and, as shown by Nikazm disclosing a “multiple graphics processing core system” (¶0003) that employs an integrated graphics processing unit (iGPU) and a discrete graphics processing unit (dGPU) connected “via a dedicated graphics interface such as a Peripheral Component Interconnect Express Graphics (PEG) interface” (¶0023). Nikazm further discloses (¶0021-0022, 0026-0027), that “each GPU may itself be capable of running at different performance-states (p-states). P-states may generally refer to a processor's ability to operate at lower capability states. Specifically, a processor operating at a particular p-state may have certain attributes reduced or scaled back such as its clock frequency” (Nikazm ¶0021).
It would have been obvious to one of ordinary skill in the art at the time of the invention to apply Grouzdev’s methods of coordinated power management to the GPU system of Nikazm in order to save power while maintaining VM performance (Grouzdev ¶0034), and because it represents the application of a known technique to improve similar devices (Grouzdev’s P-state enable processor and Nikazm’s P-state enable GPUs) in the same way (Nikazm ¶0021-0022).
Claims 34 and 40:
The combination of Grouzdev/Nikazm discloses the limitations as shown in the rejections above. Grouzdev further discloses wherein the first processor comprises a virtual machine manager (VMM) configured to manage the first and second virtual machines; and wherein the controller is further configured to select a power control setting request from one of the first and second virtual machines as the power control request for the power management unit (¶0014, 0034-0039, FIG. 1).
Claims 36 and 42:
The combination of Grouzdev/Nikazm discloses the limitations as shown in the rejections above. Furthermore, the combination of Grouzdev/Nikazm discloses control the power level of at least one engine (functional block) of the plurality of engines of the graphics processing core by turning the at least one engine of the graphics processing core on and off in at least Grouzdev {¶0038-0039 disclosing requests to control power levels for and turn on/off PCI devices (including constituent functional blocks) in view of Nikazm ¶0020-0022. See also Applicant FIG. 1.
Claims 38 and 44:
The combination of Grouzdev/Nikazm discloses the limitations as shown in the rejections above. Furthermore, Grouzdev discloses compare the first and second virtual machine power control setting requests and determine the power control request for the power management unit based on the comparison (¶0014, 0035-0039).
Claim 45:
The combination of Grouzdev/Nikazm discloses the limitations as shown in the rejections above. Grouzdev further discloses memory, operatively coupled to the controller that stores the first and second VM power control setting requests and the generated the power control request (virtual ACPI and actual ACPI power states) in at least ¶0013-0015, 0018, 0028, 0033; FIG. 1 disclosing the received ACPI requests from VMs are stored as unique vACPI states for each VM.
Claims 28, 35, and 41 are rejected under 35 U.S.C. 103 as being unpatentable over Grouzdev in view of Nikazm in further view of Nathuji et al. (“VirtualPower: Coordinated Power Management in Virtualized Enterprise Systems”, 2007).
Claims 28, 35, and 41:
The combination of Grouzdev/Nikazm discloses the limitations as shown in the rejections above. The combination of Grouzdev/Nikazm does not disclose wherein the first or second VM power control setting request from a respective one of the first and second VMs is selected as the power control request for the power management unit when the respective one of the first and second VMs is scheduled to use the graphics processing core for a time slice greater than a predetermined threshold time length.
Nathuji, however, discloses analogous methods for coordinating power management for hardware devices shared by VMs which considers power-state setting requests received from different VMs (pg. 265, Abstract; pg. 266, col. 1, para. 4); and discloses a known approach that uses a time domain multiplexing (TDM) method (pg. 268, § 3.3) where the requested power management criteria/state (power control setting request) for a currently scheduled/executing VM is selected as the power control setting to utilize, which is only a viable technique when the hypervisor’s scheduling time granularity (time slice) for the VM is greater than the power management state transition time (predetermined threshold time length).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify Grouzdev/Nikazm to utilize the TDM technique of Nathuji under the described conditions as it represents the substitution of one known approach for arbitrating power management requests from different VMs with another known approach with predictable results.
Claims 30, 37, and 43 are rejected under 35 U.S.C. 103 as being unpatentable over Grouzdev in view of Nikazm in further view of Alben et al. (US 2005/0268141 A1).
Claims 30, 37, and 43:
The combination of Grouzdev/Nikazm discloses the limitations as shown in the rejections above.
30. The method of claim 27, comprising using the power control request to control power levels of a graphics engine, a display engine, a decoding engine and an encoding engine of the graphics processing core.
Furthermore, a graphics engine and a display engine are inherent components of the GPU disclosed by Nikazm, but the combination of Grouzdev/Nikazm does not specifically disclose using the power control request to control power levels of a graphics engine, a display engine, a decoding engine and an encoding engine of the graphics processing core.
Alben, however, discloses (¶0021-0024, 0032-0034, 0045 FIG. 1) a system and methods for power management of graphics processing device including subsystem (engine) power management operations for a device including a graphics, display interface, and MPEG (decoding/encoding) subsystems.
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify Grouzdev/Nikazm to employ the subsystem power management techniques of Alben in order to manage peak power requirements and reduce power consumption (Alben ¶0030).
Claim 32 is rejected under 35 U.S.C. 103 as being unpatentable over Grouzdev in view of Nikazm in further view of Khodorkovsky et al. (US 2008/0058999 A1)
Claim 32:
The combination of Grouzdev/Nikazm discloses the limitations as shown in the rejections above. As noted above, Grouzdev discloses VM power-state setting requests that specify a frequency range for CPUs, and VM power-state setting requests for PCI devices, but Grouzdev does not elaborate on supported device power states beyond on/off, and the combination of Grouzdev/Nikazm does not describe a GPU, or any other type of PCI device, with DVFS control and does not specifically disclose the first and second VM power control setting requests include at least one of either: a graphics engine frequency range or a memory frequency range.
Khodorkovsky, however, discloses (¶0018-0019, 0030-0036) an implementation of GPU power/performance device states, controlled by requests specifying the state, where “each state defines floor and ceiling values for only two operating parameters: clock frequency and voltage. Accordingly, each of the state descriptors 34 and 36 of FIG. 2 defines: a floor frequency; a ceiling frequency; a floor voltage 42; and a ceiling voltage 44. The clock frequency may represent a system clock frequency or a memory clock frequency for example” (¶0031).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify Grouzdev/Nikazm to utilize Khodorkovsky’s GPU power state implementation because it provides more precise power state control and reduced power consumption relative to conventional GPU power management (Khodorkovsky ¶0034, 0059).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Each of the following is directed DVFS control and/or power gating of individual GPU subsystems: US 20120146706 A1, US 20110148887 A1, US 20090201082 A1, “Application-Directed DVFS using Multiple Clock Domains on Graphics Hardware”.
Each of the following are directed to GPUs supporting multiple p-states US 20110154069 A1, US 8924752 B1.
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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
05/21/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
1 To ensure clarity of record regarding terminology, from “Power Management in Intel Servers”: “Processor performance states (P-states) are a predefined set of frequency and voltage combinations at which a given processor can operate correctly (pg. 4)...P-states: The processor P-state is the capability of running the processor at different voltage and/or frequency levels. Generally, P0 is the highest state resulting in maximum performance, while P1, P2, and so on, will save power but at some penalty to CPU performance” (pg. 12).
2 To ensure clarity of record regarding terminology, from “Power Management in Intel Servers”: “Processor performance states (P-states) are a predefined set of frequency and voltage combinations at which a given processor can operate correctly (pg. 4)...P-states: The processor P-state is the capability of running the processor at different voltage and/or frequency levels. Generally, P0 is the highest state resulting in maximum performance, while P1, P2, and so on, will save power but at some penalty to CPU performance” (pg. 12).
Prosecution Insights