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 1-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/17/2025 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f), is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f), except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f), except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a cloud management component to” detect, disable, enable, determine in claim 16.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f), it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f), applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 16-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
The following claim languages are not clearly understood and indefinite:
Claim limitation “a cloud management component” to detect, disable, enable, determine in claim 16 invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed functions and to clearly link the structure, material, or acts to the function. A review of the specification [0038-0051] finds no support for the structure of the limitation that performs the functions (detect, disable, enable, determine). Examiner notes that for computer-implemented technologies, structural support may be derived from a “computer” + “algorithm”, see MPEP § 2181, however, Examiner finds no support in the specification for a specific definite structure nor a general-purpose processor/computer programmed to carry out an algorithm corresponding the functions performed by the limitation which invokes 35 U.S.C. 112 (f),
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
As per claims 17-20, they are rejected as being dependent on rejected claim 16.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 16-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AlA), first paragraph, as failing to comply with the written description requirement.
The claim 16 contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AlA the inventor(s), at the time the application was filed, had possession of the claimed invention. As described above in 112(f) interpretation for the limitation “a cloud management component”, the disclosure does not provide adequate structure to perform the claimed functions. The specification does not demonstrate that applicant has made an invention that achieves the claimed function because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention. See MPEP § 2181(II)(B) “When a claim containing a computer-implemented 35 U.S.C. 112(f) claim limitation is found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, it will also lack written description under 35 U.S.C. 112(a)’.
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 filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 4-9 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (U.S. Pub. No. 20180121222 A1) in view of Pillilli et al. (U.S. Patent No. 11157064 B2), further in view of Liu et al. (U.S. Pub. No. 20250190249 A1), and further in view of Kaplan et al. (US 20240220295 A1).
As per claim 1, Sharma teaches the invention substantially as claimed including computer-implemented method comprising:
detecting a request associated with a new workload to be executed by a virtual machine deployed on a core of a central processing unit (CPU) (par. 0016 the hardware processor 120 executes instructions 132 to receive a virtual network function specifying a particular function to be performed by at least one virtual machine par. 0018 virtual machine having one virtual CPU running on one quad-core processor),
wherein the virtual machine utilizes a first virtual CPU (vCPU) and a second vCPU of the core (par. 0007 virtual machine configuration options may be … resource configuration options … Examples of resource configurations include number of virtual CPUs (vCPU), size of memory),
wherein a CPU feature is enabled on the first vCPU and the second vCPU, wherein an existing workload utilizes the CPU feature enabled on the first vCPU (par. 0016 receive a virtual network function specifying a particular function to be performed by at least one virtual machine. Virtual network functions may include, for example, a network firewall function, a network load balancing function; par. 0007 resource configurations include number of virtual CPUs (vCPU); par. 0008 an infrastructure configuration that specifies which software and hardware features are to be used/enabled for virtual machines that perform a particular VNF).
Sharma does not expressly teach: wherein the new workload is to be executed with the second vCPU without utilizing the CPU feature; providing an instruction to disable the CPU feature enabled on the second vCPU; causing the new workload to be executed by the second vCPU of the virtual machine after providing the instruction to disable the CPU feature and configuring the instruction intercept.
However, Pillilli teaches: wherein the new workload is to be executed with the second … [device] without utilizing the CPU feature; providing an instruction to disable the CPU feature …; causing the new workload to be executed by the second … [device] of the virtual machine after providing the instruction to disable the CPU feature … (col. 11, lines 34-49, The scheduler 306 can determine workload resource requirements by reading workload metadata that contains the workload resource requirements … The workload resource requirements may specify which processing and memory requirements [features] are needed to process the workload, and the scheduler 306 may determine accelerator devices, resources, and circuitry to enable and/or disable based on requirements. Moreover, the scheduler 306 may determine which nodes 101 including the accelerator devices, resources, and circuitry are available and to perform power operations. The scheduler 306 directs [instructs] a management controller of a node 101 to perform a power operation to enable or disable one or more accelerator devices and infrastructure devices based on the workload resource requirements).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of disabling/enabling features/accelerators based on workload requirements of Pillilli with the system and method of Sharma resulting in a system and method which provides for disabling CPU features for virtual processing units of a virtual machine. One of ordinary skill in the art would have been motivated to make this combination for the purpose of achieving optimal performance (col. 13, lines 41-37).
Sharma and Pillilli do not expressly teach: providing an instruction to disable the CPU feature enabled on the second vCPU.
However, Liu teaches: providing an instruction to disable the CPU feature enabled on the second vCPU (par. 0091 in case of determining that the current running state is a non-exit function state, disabling, based on the exit function strategy, the non-exit function of the virtual CPU of the virtual machine).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of disabling a non-exit function of a virtual CPU of Liu with the system and method of Sharma and Pillilli resulting in a system and method which provides for disabling a CPU feature of a virtual CPU. One of ordinary skill in the art would have been motivated to make this combination for the purpose of ensuring that unnecessary physical CPU resources are not consumed, as well as enabling the non-exit function(s) of the virtual CPU(s) to improve application performance of the virtual CPU(s) (par. 0019).
Sharma and Pillilli and Liu do not expressly teach: configuring an instruction intercept, for the second vCPU, to prevent execution of one or more instructions that cause the CPU feature to be executed by the second vCPU.
However, Kaplan teaches configuring an instruction intercept, for the second vCPU, to prevent execution of one or more instructions that cause the CPU feature to be executed by the second vCPU (par. 0011 the system hardware intercepts the event, and prevents execution of any operations requested by the event, such as execution of instructions).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of intercepting an event to prevent execution of operations/instructions requested by the event of Kaplan with the system and method of Sharma, Pillilli and Liu resulting in a system and method which provides for intercepting instructions that cause a CPU feature/function to be executed by a virtual CPU as in Kaplan. One of ordinary skill in the art would have been motivated to make this combination for the purpose of improving overall system security (par. 0011).
As per claim 4, Sharma teaches: detecting a second request associated with a third workload to be executed by the virtual machine, wherein the new workload is to be executed with the CPU feature (par. 0048 A virtual network function is received specifying a particular function to be performed by at least one virtual machine). Pillilli teaches providing an instruction to enable the CPU feature on a third vCPU of the core; and causing the third workload to be executed by the third vCPU (col. 11, lines 34-49, The scheduler 306 can determine workload resource requirements … The workload resource requirements may specify which processing and memory requirements [features] are needed to process the workload … The scheduler 306 directs [instructs] a management controller of a node 101 to perform a power operation to enable or disable one or more accelerator devices and infrastructure devices based on the workload resource requirements). Liu further teaches providing an instruction to enable the CPU feature on a third vCPU of the core (par. 0094 Specifically, the kernel scheduler informs the monitoring layer of the virtual machine to modify the VMCS of the virtual CPU, to enable the CPU_BASED_HLT EXITING bit).
As per claim 5, Sharma further teaches: adjusting a number of vCPUs associated with the virtual machine (par. 0026 A single component VNF may be scaled by increasing [modifying] the virtualized hardware resources [virtual processors] of the virtual machine; par. 0036 for example, the virtual processors allocated for the virtual machine(s) 220 deployment increased from 1 processor to 4).
As per claim 6, Sharma further teaches: wherein adjusting the number of vCPUs comprises: assigning the number of vCPUs to a number threshold of cores of the CPU (par. 0018 virtual machine having one virtual CPU running on one quad-core processor; par. 0036 the virtual processors allocated for the virtual machine(s) 220 deployment increased from 1 processor to 4).
As per claim 7, Pillilli further teaches: wherein the CPU feature is an accelerator feature of an accelerator (col. 3, lines 30-37 A accelerator device 112 may be hardware (processor) accelerator device designed to provide hardwired logic to accelerate specific processing tasks, such as graphics, mathematical operations, cryptographic operations, media processing, image processing, and so forth).
As per claim 8, Pillilli further teaches: wherein the accelerator feature is included on the core (col. 5, lines 65-67 The one or more infrastructure devices 114 include one or more of integrated processors (IPs), field-programmable gate array(s) (FPGA(s)), one or more cores, calculation units).
As per claim 9, Pillilli further teaches: wherein the accelerator feature is shared by multiple cores of the CPU (col. 2, lines 64-67 In the illustrated example, the node 101 includes a multi-chip package (MCP) 102 having a central processing unit (CPU) 110, one or more accelerator devices 112-x; col. 3, lines 7-8, CPUs 110 may include a number of processing cores to process data).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma in view of Pillilli, Liu and Kaplan, and further in view of Chin et al. (U.S. Pub. No. 20140007097 A1).
As per claim 2, Sharma, Pillilli, Liu and Kaplan do not expressly teach: causing the new workload to be executed without restarting the virtual machine.
However, Chin teaches: causing the new workload to be executed without restarting the virtual machine (par. 0074 launched VM may launch and execute a program or set of programs that facilitate and enable dynamic modifications to the resources allocated to the VM; par. 0075 hypervisor 118 then causes the modification to occur dynamically without having to stop, reboot, or restart the VM).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of dynamically modifying resources/features of a virtual machine and executing programs without having to stop, reboot, or restart the virtual machine of Chin with the system and method of Sharma, Pillilli, Liu and Kaplan resulting in a system and method which provides for modifying CPU units/resources of a virtual machine without having to stop, reboot, or restart the virtual machine as in Chin. One of ordinary skill in the art would have been motivated to make this combination for the purpose of significantly improves utilization of limited resources (par. 0208).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma in view of Pillilli, Liu and Kaplan, and further in view of Mansur et al. (U.S. Pub. No. 20140258335 A1).
As per claim 3, Sharma further teaches: detecting a second request associated with a third workload to be executed by the virtual machine, wherein the third workload is to be executed with the CPU feature (par. 0048 A virtual network function is received specifying a particular function to be performed by at least one virtual machine). Pillilli further teaches providing an instruction to enable the CPU feature …; causing the third workload to be executed by the second vCPU of the virtual machine (col. 11, lines 34-49, The scheduler 306 can determine workload resource requirements … The workload resource requirements may specify which processing and memory requirements [features] are needed to process the workload … The scheduler 306 directs [instructs] a management controller of a node 101 to perform a power operation to enable or disable one or more accelerator devices and infrastructure devices based on the workload resource requirements). Liu further teaches: providing an instruction to enable the CPU feature on the second vCPU (par. 0094 Specifically, the kernel scheduler informs the monitoring layer of the virtual machine to modify the VMCS of the virtual CPU, to enable the CPU_BASED_HLT EXITING bit, and to switch the virtual CPU to HLT exit; par. 0091 disabling, based on the exit function strategy, the non-exit function of the virtual CPU of the virtual machine).
Sharma, Pillilli, Liu and Kaplan do not expressly teach: removing the instruction intercept to prevent execution of one or more instructions that cause the CPU feature to be executed.
However, Mansur teaches: removing the instruction intercept to prevent execution of one or more instructions that cause the CPU feature to be executed (par. 0058 all AAI intercepts are removed and all subsequent calls in the job are passed directly to the IMS interface).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of removing instruction intercepts of Mansur with the system and method of Sharma, Pillilli, Liu and Kaplan resulting in a system and method which provides for removing instruction intercepts that prevent execution of CPU features by a virtual CPU. One of ordinary skill in the art would have been motivated to make this combination for the purpose of allowing the virtual processor to execute a processor feature/function.
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (U.S. Pub. No. 20180121222 A1) in view of Liu et al. (U.S. Pub. No. 20250190249 A1), further in view of Kaplan et al. (U.S. Pub. No. 20240220295 A1), and further in view of Mansur et al. (U.S. Pub. No. 20140258335 A1).
As pe claim 10, Sharma teaches the invention substantially as claimed including a computer program product comprising:
one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media (par. 0015 A machine-readable storage medium, such as 130, may be … storage device that contains or stores executable instructions), the program instructions comprising:
… CPU feature is associated with a virtual machine (par. 0008 an infrastructure configuration that specifies which software and hardware features are to be used/enabled for virtual machines that perform a particular VNF),
program instructions to adjust a number of vCPUs associated with the virtual machine (par. 0023 computing device 110 may adjust the resource configuration, e.g., by adding CPUs and/or cores; par. 00bloom26 A single component VNF may be scaled by increasing [modifying] the virtualized hardware resources [virtual processors] of the virtual machine).
Sharma does not expressly teach: program instructions to detect a request associated with a central processing unit (CPU) feature associated with a virtual CPU (vCPU) of a CPU, wherein the CPU feature is associated with a virtual machine; program instructions to disable the CPU feature on the vCPU … when the request indicates that the CPU feature is to be enabled; program instructions to enable the CPU feature on the vCPU.
However, Liu teaches: program instructions to detect a request associated with a central processing unit (CPU) feature associated with a virtual CPU (vCPU) of a CPU, wherein the CPU feature is associated with a virtual machine; program instructions to disable the CPU feature on the vCPU … when the request indicates that the CPU feature is to be enabled; program instructions to enable the CPU feature on the vCPU (par. 0091 disabling, based on the exit function strategy, the non-exit function of the virtual CPU of the virtual machine; par. 0094 the exit function strategy is aimed at making the virtual CPU execute the exit operation normally when receiving [detecting] the exit instruction; so the kernel scheduler can disable the non-exit function of the virtual CPU … Specifically, the kernel scheduler informs the monitoring layer of the virtual machine to modify the VMCS of the virtual CPU, to enable the CPU_BASED_HLT_EXITING bit, and to switch the virtual CPU to HLT exit).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of disabling a non-exit function of a virtual CPU of Liu with the system and method of Sharma resulting in a system and method which provides for disabling a CPU feature of a virtual CPU. One of ordinary skill in the art would have been motivated to make this combination for the purpose of ensuring that unnecessary physical CPU resources are not consumed, as well as enabling the non-exit function(s) of the virtual CPU(s) to improve application performance of the virtual CPU(s) (par. 0019).
Sharma and Liu do not expressly teach: configure an instruction intercept to prevent execution of the CPU feature by the vCPU when the request indicates that the CPU feature is to be disabled.
However, Kaplan teaches: configure an instruction intercept to prevent execution of the CPU feature by the vCPU when the request indicates that the CPU feature is to be disabled (par. 0011 the system hardware intercepts the event, and prevents execution of any operations requested by the event, such as execution of instructions).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of intercepting an event to prevent execution of operations/instructions requested by the event of Kaplan with the system and method of Sharma and Liu resulting in a system and method which provides for intercepting instructions that cause a CPU feature/function to be executed by a virtual CPU as in Kaplan. One of ordinary skill in the art would have been motivated to make this combination for the purpose of improving overall system security (par. 0011).
Sharma, Liu and Kaplan do not expressly teach: remove an instruction intercept that prevents the execution of the CPU feature by the vCPU when the request indicates that the CPU feature is to be enabled.
However, Mansur teaches: remove an instruction intercept that prevents the execution of the CPU feature by the vCPU when the request indicates that the CPU feature is to be enabled (par. 0058 all AAI intercepts are removed and all subsequent calls in the job are passed directly to the IMS interface).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of removing instruction intercepts of Mansur with the system and method of Sharma, Liu and Kaplan resulting in a system and method which provides for removing instruction intercepts that prevent execution of CPU features by a virtual CPU. One of ordinary skill in the art would have been motivated to make this combination for the purpose of allowing the virtual processor to execute a processor feature/function.
As per claim 11, Sharma further teaches: program instructions to detect a request to disable the CPU feature; and program instructions to determine whether the CPU feature is to be disabled on a plurality of vCPUs that include the vCPU (par. 0016 the hardware processor 120 executes instructions 132 to receive a virtual network function specifying a particular function [feature] to be performed by at least one virtual machine; par. 0032 configuration 216 depicts multiple infrastructure options and their status for each iteration, e.g., enabled or disabled. For example, infrastructure configuration A 216A depicts three enabled infrastructure options (A, B, and D) and two disabled options (C and E)).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma in view of Liu, Kaplan and Mansur, and further in view of Pillilli et al. (U.S. Patent No. 11157064 B2).
As per claim 12, Liu further teaches: program instructions to detect a request to enable the CPU feature (par. 0094 the exit function strategy is aimed at making the virtual CPU execute the exit operation normally when receiving [detecting] the exit instruction; so the kernel scheduler can disable the non-exit function of the virtual CPU … Specifically, the kernel scheduler informs the monitoring layer of the virtual machine to modify the VMCS of the virtual CPU, to enable the CPU_BASED_HLT_EXITING bit, and to switch the virtual CPU to HLT exit).
Sharma, Liu, Kaplan and Mansur do not expressly teach: program instructions to identify a core, of the CPU, that includes the CPU feature. However, Pillilli further: program instructions to identify a core, of the CPU, that includes the CPU feature (col. 2, lines 9-11 the scheduler may determine which nodes include the accelerator devices [features], resources, and circuitry are available and to perform power operations, e.g., enabling and disabling power for accelerator devices [features]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of disabling/enabling features/accelerators based on workload requirements of Pillilli with the system and method of Sharma resulting in a system and method which provides for disabling CPU features for virtual processing units of a virtual machine. One of ordinary skill in the art would have been motivated to make this combination for the purpose of achieving optimal performance (col. 13, lines 41-37).
Claims 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma in view of Liu, Kaplan and Mansur, and further in view of Hepkin et al. (U.S. Pub. No. 20090300317 A1).
As per claim 13, Sharma, Liu, Kaplan and Mansur do not expressly teach: program instructions to determine whether the vCPU is to be instantiated on a core of the CPU based on a number of vCPUs currently instantiated on the core.
However, Hepkin teaches program instructions to determine whether the vCPU is to be instantiated on a … [partition] of the CPU based on a number of vCPUs currently instantiated on the … [partition] (par. 0030 unfolding vCPUs, provided the current number of vCPUs is less than the "desired" number of vCPUs [vCPU number threshold] specified during partition creation; par. 0041 A determination is made as to whether the current number of virtual CPUs assigned to this partition is equal to the entitled value of virtual CPUs assigned to this partition).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of unfolding or increasing number of vCPUs of a partition based on a current number of vCPUs not exceeding a threshold number vCPUs of Hepkin with the system and method of Sharma, Liu, Kaplan and Mansur resulting in a system and method in which additional vCPUs are instantiated for a processor core based on a current number of vCPUs being less/equal to threshold number vCPUs as in Hepkin. One of ordinary skill in the art would have been motivated to make this combination for the purpose of increasing the amount of computing resources (processing capacity) assigned in order to increase service time (par. 0004). Further, this would have provided for enhanced performance, lower latency, and optimized resource efficiency.
As per claim 14 Liu further teaches: program instructions to enable the CPU feature on the vCPU after instantiating the vCPU (par. 0094 par. 0094 the exit function strategy is aimed at making the virtual CPU execute the exit operation normally when receiving [detecting] the exit instruction; so the kernel scheduler can disable the non-exit function of the virtual CPU … Specifically, the kernel scheduler informs the monitoring layer of the virtual machine to modify the VMCS of the virtual CPU, to enable the CPU_BASED_HLT_EXITING bit, and to switch the virtual CPU to HLT exit). Hepkin further teaches program instructions to determine whether the number of vCPUs currently instantiated on the … [partition] satisfy a vCPU number threshold; program instructions to instantiate the vCPU on the … [partition] based on determining whether the number of vCPUs currently instantiated on the core satisfy the vCPU number threshold (par. 0030 unfolding vCPUs, provided the current number of vCPUs is less than the "desired" number of vCPUs [vCPU number threshold] specified during partition creation; par. 0041 A determination is made as to whether the current number of virtual CPUs assigned to this partition is equal to the entitled value of virtual CPUs assigned to this partition; 0042 step 690, the number of virtual CPUs assigned to the partition is increased ("unfolded") to a value that is less than or equal to the partition's entitlement value).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma in view of Liu, Kaplan and Mansur, and further in view of Hepkin et al. (U.S. Pub. No. 20090300317 A1), and further in view of Sok et al. (US Pub. No. 20160274932 A1).
As per claim 15, Sharma, Liu, Kaplan and Mansur do not expressly teach: program instructions to determine whether a number of vCPUs instantiated on a core satisfy a vCPU number threshold.
However, Hepkin teaches: program instructions to determine whether a number of vCPUs instantiated on a core satisfy a vCPU number threshold (par. 0030 unfolding vCPUs, provided the current number of vCPUs is less than the "desired" number of vCPUs [vCPU number threshold] specified during partition creation; par. 0041 A determination is made as to whether the current number of virtual CPUs assigned to this partition is equal to the entitled value of virtual CPUs assigned to this partition).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of unfolding or increasing number of vCPUs of a partition based on a current number of vCPUs not exceeding a threshold number vCPUs of Hepkin with the system and method of Sharma, Liu, Kaplan and Mansur resulting in a system and method in which additional vCPUs are instantiated for a processor core based on a current number of vCPUs being less/equal to threshold number vCPUs as in Hepkin. One of ordinary skill in the art would have been motivated to make this combination for the purpose of increasing the amount of computing resources (processing capacity) assigned in order to increase service time (par. 0004). Further, this would have provided for enhanced performance, lower latency, and optimized resource efficiency.
Sharma, Liu, Kaplan, Mansur and Hepkin do not expressly teach: program instructions to cause the virtual machine to be executed on a second core of the CPU based on the number of vCPUs satisfying the vCPU number threshold.
However, Sok teaches: program instructions to cause the virtual machine to be executed on a second core of the CPU based on the number of vCPUs satisfying … threshold (par. 0069 Virtual Machine 830 is below the threshold value, the hypervisor 850 may move the second general Virtual Machine 830 to the second core 860).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of moving a virtual machine to a second core based on a threshold value with the system and method of Sharma, Liu, Kaplan, Mansur and Hepkin resulting in a system and method that provides for executing a virtual machine on a second core based on current number of vCPUs of a core. One of ordinary skill in the art would have been motivated to make this combination for the purpose of reducing a time of response of a general Virtual Machine, and improve the input/output performance (par. 0019).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (U.S. Pub. No. 20180121222 A1) in view of Liu et al. (U.S. Pub. No. 20250190249 A1), and further in view of Kaplan et al. (U.S. Pub. No. 20240220295 A1).
As per claim 16, Sharma teaches the invention substantially as claimed including a system comprising: a cloud management component (par. 0016 a cloud computing system) to:
… the CPU feature is associated with a virtual machine (par. 0008 an infrastructure configuration that specifies which software and hardware features are to be used/enabled for virtual machines that perform a particular VNF),
determine whether to adjust a number of vCPUs associated with the virtual machine (par. 0023 a resource configuration may be adjusted by determining that the results of the performance of the VNF indicate that a particular virtualized hardware resource met a threshold measure of utilization … computing device 110 may adjust the resource configuration, e.g., by adding CPUs and/or cores; par. 0026 A single component VNF may be scaled by increasing [modifying] the virtualized hardware resources [virtual processors] of the virtual machine).
Sharma does not expressly teach: detect a request associated with a central processing unit (CPU) feature associated with a virtual CPU (vCPU) of a CPU, wherein the CPU feature is associated with a virtual machine; disable the CPU feature on the vCPU … when the request indicates that the CPU feature is to be disabled; enable the CPU feature on the vCPU when the request indicates that the CPU feature is to be enabled.
However, Liu teaches: detect a request associated with a central processing unit (CPU) feature associated with a virtual CPU (vCPU) of a CPU, wherein the CPU feature is associated with a virtual machine; disable the CPU feature on the vCPU … when the request indicates that the CPU feature is to be disabled; enable the CPU feature on the vCPU when the request indicates that the CPU feature is to be enabled (par. 0091 disabling, based on the exit function strategy, the non-exit function of the virtual CPU of the virtual machine; par. 0094 the exit function strategy is aimed at making the virtual CPU execute the exit operation normally when receiving [detecting] the exit instruction; so the kernel scheduler can disable the non-exit function of the virtual CPU … Specifically, the kernel scheduler informs the monitoring layer of the virtual machine to modify the VMCS of the virtual CPU, to enable the CPU_BASED_HLT_EXITING bit, and to switch the virtual CPU to HLT exit).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of disabling a non-exit function of a virtual CPU of Liu with the system and method of Sharma resulting in a system and method which provides for disabling a CPU feature of a virtual CPU. One of ordinary skill in the art would have been motivated to make this combination for the purpose of ensuring that unnecessary physical CPU resources are not consumed, as well as enabling the non-exit function(s) of the virtual CPU(s) to improve application performance of the virtual CPU(s) (par. 0019).
Sharma and Liu do not expressly teach configure an instruction intercept to prevent execution of the CPU feature by the vCPU.
However, Kaplan teaches configure an instruction intercept to prevent execution of the CPU feature by the vCPU (par. 0011 the system hardware intercepts the event, and prevents execution of any operations requested by the event, such as execution of instructions).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of intercepting an event to prevent execution of operations/instructions requested by the event of Kaplan with the system and method of Sharma and Liu resulting in a system and method which provides for intercepting instructions that cause a CPU feature/function to be executed by a virtual CPU as in Kaplan. One of ordinary skill in the art would have been motivated to make this combination for the purpose of improving overall system security (par. 0011).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma in view of Liu and Kaplan, and further in view of Hepkin et al. (U.S. Pub. No. 20090300317 A1), and further in view of Sok et al. (US Pub. No. 20160274932 A1).
As per claim 17, Sharma, Liu, Kaplan do not expressly teach: determine whether a number of vCPUs instantiated on the CPU satisfy a vCPU number threshold.
However, Hepkin teaches: determine whether a number of vCPUs instantiated on the CPU satisfy a vCPU number threshold (par. 0030 unfolding vCPUs, provided the current number of vCPUs is less than the "desired" number of vCPUs [vCPU number threshold] specified during partition creation; par. 0041 A determination is made as to whether the current number of virtual CPUs assigned to this partition is equal to the entitled value of virtual CPUs assigned to this partition).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of unfolding or increasing number of vCPUs of a partition based on a current number of vCPUs not exceeding a threshold number vCPUs of Hepkin with the system and method of Sharma, Liu, Kaplan and Mansur resulting in a system and method in which additional vCPUs are instantiated for a processor core based on a current number of vCPUs being less/equal to threshold number vCPUs as in Hepkin. One of ordinary skill in the art would have been motivated to make this combination for the purpose of increasing the amount of computing resources (processing capacity) assigned in order to increase service time (par. 0004). Further, this would have provided for enhanced performance, lower latency, and optimized resource efficiency.
Sharma, Liu and Kaplan and Hepkin do not expressly teach: cause the virtual machine to be executed on a second core of the CPU based on the number of vCPUs satisfying the vCPU number threshold.
However, Sok teaches: cause the virtual machine to be executed on a second core of the CPU based on the number of vCPUs satisfying … threshold (par. 0069 Virtual Machine 830 is below the threshold value, the hypervisor 850 may move the second general Virtual Machine 830 to the second core 860).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of moving a virtual machine to a second core based on a threshold value with the system and method of Sharma, Liu, Kaplan, Kaplan and Hepkin resulting in a system and method that provides for executing a virtual machine on a second core based on current number of vCPUs of a core. One of ordinary skill in the art would have been motivated to make this combination for the purpose of reducing a time of response of a general Virtual Machine, and improve the input/output performance (par. 0019).
Claims 18-19 rejected under 35 U.S.C. 103 as being unpatentable over Sharma in view of Liu, Kaplan, Hopkin and Sok, and further in view of Pillilli et al. (U.S. Patent No. 11157064 B2).
As per claim 18, Sharma, Liu and Kaplan, Hopkin and Sok do not expressly teach wherein the CPU feature is an accelerator feature of an accelerator.
However, Pillilli further: wherein the CPU feature is an accelerator feature of an accelerator (col. 3, lines 30-37 A accelerator device 112 may be hardware (processor) accelerator device designed to provide hardwired logic to accelerate specific processing tasks, such as graphics, mathematical operations, cryptographic operations, media processing, image processing, and so forth).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of providing hardwired logic/features to accelerate processing tasks of Pillilli with the system and method of Sharma, Liu and Kaplan resulting in a system and method which provides hardwired logic/features as accelerator features to accelerate processing tasks. One of ordinary skill in the art would have been motivated to make this combination for the purpose of achieving optimal performance (col. 13, lines 41-37).
As per claim 19, Pillilli further teaches: wherein the accelerator feature is included on a core (col. 5, lines 65-67 The one or more infrastructure devices 114 include one or more of integrated processors (IPs), field-programmable gate array(s) (FPGA(s)), one or more cores, calculation units).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma in view of Liu and Kaplan, and further in view of Chin et al. (U.S. Pub. No. 20140007097 A1).
As per claim 20, Liu further teaches: disable the CPU feature on the vCPU … (par. 0091 disabling, based on the exit function strategy, the non-exit function of the virtual CPU of the virtual machine; par. 0094 the exit function strategy is aimed at making the virtual CPU execute the exit operation normally when receiving [detecting] the exit instruction; so the kernel scheduler can disable the non-exit function of the virtual CPU … Specifically, the kernel scheduler informs the monitoring layer of the virtual machine to modify the VMCS of the virtual CPU, to enable the CPU_BASED_HLT_EXITING bit, and to switch the virtual CPU to HLT exit). Kaplan further teaches configure the instruction intercept (par. 0011 the system hardware intercepts the event, and prevents execution of any operations requested by the event, such as execution of instructions).
Sharma, Liu and Kaplan do not expressly teach: configure … without restarting the virtual machine.
However, Chin teaches: configure … without restarting the virtual machine (par. 0075 hypervisor 118 then causes the modification to occur dynamically without having to stop, reboot, or restart the VM).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique of dynamically modifying resources/features of a virtual machine and executing programs without having to stop, reboot, or restart the virtual machine of Chin with the system and method of Sharma, Liu and Kaplan resulting in a system and method which provides for modifying CPU units/resources of a virtual machine without having to stop, reboot, or restart the virtual machine as in Chin. One of ordinary skill in the art would have been motivated to make this combination for the purpose of significantly improves utilization of limited resources (par. 0208).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Willy W. Huaracha whose telephone number is (571)270-5510. The examiner can normally be reached on M-F 8:30-5:00pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached on (571) 272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WH/
Examiner, Art Unit 2195
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights