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 .
This office action is in response to claims filed 08/07/2024. Claims 1-20 are pending.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tormasov et al. (US 8938723 B1 ) in view of Saxena et al. (US 20160328562 A1), hereinafter referred to as Tormasov and Saxena, respectively.
Regarding Claim 1, Tormasov discloses One or more processors comprising: one more circuits to: detect, using a guest operating system (OS) of a virtual machine (VM) (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up.; In yet another embodiment, a system for employing a GPU in a virtual environment includes a CPU, a GPU coupled to the CPU, and a memory coupled to the CPU. A Virtual Machine Monitor (VMM) has virtualization means and supporting a Virtual Machine (VM) implemented on the computer system. Please note that the VMM of the system for employing a GPU in a virtual environment including a CPU corresponds to Applicant’s processor comprising a circuit. Additionally, the VMM supporting the VM implemented on the computer system that detects computationally intensive VM operations which may be associated with guest OSes of the main computing system which uses the main CPU corresponds to Applicant’s detecting using a guest OS of a VM.),
the target level based on at least one of (i) a characteristic of the workload or (ii) operation of another of the processing units (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up.; In yet another embodiment, a system for employing a GPU in a virtual environment includes a CPU, a GPU coupled to the CPU, and a memory coupled to the CPU. A Virtual Machine Monitor (VMM) has virtualization means and supporting a Virtual Machine (VM) implemented on the computer system. Please note that the VMM supporting the VM implemented on the computer system that detects computationally intensive VM operations, where the code may be off-loaded to the GPU based on CPU load corresponds to Applicant’s target level being based on the operation of another of the processing units, i.e., the GPU being available to have the CPU load offloaded to it. Additionally, as it is detected whether the VM operations are computationally intensive, this corresponds to the target level being based on the characteristic of the workload as well.);
provide, to a host OS, based at least on the condition, an instruction to reduce operation of the one of the processing units (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up. Please note that freeing up the host system CPU once the offload is completed corresponds to Applicant’s providing an instruction to reduce operation of the one of the processing units to the host OS based on the condition.);
and modify, by the host OS, behavior of the processing units based on the instruction (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up. Please note that carrying out the operation that frees up the host system CPU by offloading the code to the GPU based on the CPU load corresponds to Applicant’s modifying behavior of the processing units based on the instruction by the host OS.).
Tormasov does not explicitly disclose a condition of a workload of the VM being executed on processing units including a central processing unit (CPU) and a graphics processing unit (GPU), the condition indicative of operation of one of the processing units being different than a target level of operation
However, Saxena discloses a condition of a workload of the VM being executed on processing units including a central processing unit (CPU) and a graphics processing unit (GPU) ([0042] based on a current workload of the CPU 108 and/or a current workload of the GPU 106. Please note that the current workload of the CPU 108 and the current workload of the GPU 106 corresponds to Applicant’s condition of a workload of the VM being executed on processing units including a CPU and a GPU),
the condition indicative of operation of one of the processing units being different than a target level of operation ( [0022] Examples disclosed herein alleviate, mitigate, and/or eliminate negative impacts of executing computing tasks (e.g., security tasks and/or any other type of computing task(s)) on the CPU by offloading one or more computing tasks (e.g., security tasks) to a graphics processing unit (GPU). Computing tasks offloaded to the GPU by examples disclosed do not consume CPU cycles, thereby reducing the computation burden of the CPU and the amount of power consumed by the CPU. As the number of CPU cycles consumed by an application and/or an amount of CPU-related power consumed by the application are often used to measure performance of an application, examples disclosed herein are especially attractive to, for example, independent software vendors (ISVs) and other types of developers required to meet restrictions or limitations (e.g., benchmarks) placed on CPU cycle and/or power consumption. Please note that the methods allowing the system to meet restrictions or limitations placed on CPU cycle and power consumption, where the CPU cycles consumed are measured, corresponds to Applicant’s condition indicative of operation of one of the processing units being different than a target level of operation, i.e., assessing that there are more CPU cycles being consumed than the limitation level. )
Tormasov and Saxena are both considered to be analogous to the claimed invention because they are in the same field of managing resources of computing platforms. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Tormasov to incorporate the teachings of Saxena to modify the system with a processor with a circuit to use a guest OS of a VM to perform detection, assess the target level based on a characteristic of the workload and the operation of another of the processing units, provide an instruction to reduce operation of one of the processing units to a host OS and modify behavior of the processing units based on the instruction by the host OS to do so based on a condition of a workload of the VM being executed on processing units including a CPU and a GPU, with the condition indicating operation of the processing units being different than a target level of operation , allowing for improved resource usage and power consumption, as described in Saxena.
Regarding Claim 2, Tormasov-Saxena as described in Claim 1, Tormasov further discloses execute the VM, and wherein the VM is configured to cause the CPU and the GPU to execute the workload (Col. 1, Lines 57- 65- A Virtual Machine technology requires employing hardware of a real physical machine or a processor for support of a VM. A hardware element that is increasingly used for acceleration of physical machines is a Graphic Processing Unit (GPU). General-purpose computing on graphics processing units (GPGPU, also referred to as GPGP) is a technique of employing the GPU, which typically handles only computations related to computer graphics, for performing computations for other applications traditionally handled by the CPU. Please note that the GPU performing computations that can also be handled by the CPU for the implementation of Virtual Machine technology corresponds to Applicant’s executing the VM and the VM being configured to cause the CPU and GPU to execute the workload.).
Saxena further discloses the CPU and the GPU to execute the workload ([0042] a current workload of the CPU 108 and/or a current workload of the GPU 106. Please note that a current workload of the CPU 108 and the GPU 106 corresponds to Applicant’s CPU and GPU to execute the workload.)
Regarding Claim 3, Tormasov-Saxena as described in Claim 1, Saxena further discloses detect the condition based at least on one of: i) a load of the GPU, ii) an occupancy of a queue of the GPU, or iii) a resolution characteristic ([0043] bases a frequency and/or timing of the scans on […] a current load on the GPU 108. Please note that basing the scan timing on a current load on the GPU 108 corresponds to Applicant’s detecting the condition based on a load of the GPU. As the limitation states “at least one of” the bases for the condition detected, this is interpreted by the Examiner as fulfilling the requirements of the Claim.).
Regarding Claim 4, Tormasov-Saxena as described in Claim 1, Tormasov further discloses communicate the instruction to the host OS using a channel from a guest OS to the host OS (Col. 5, Lines 30-33- a system architecture that provides communication channel between a guest system and a host system, including interrupt delivery, data transmission and guest system memory sharing. Please note that the system architecture providing a communication channel between a guest and host system, including data transmission, corresponds to Applicant’s communicating the instruction to the host OS using a channel from a guest OS to the host OS.).
Regarding Claim 5, Tormasov-Saxena as described in Claim 1, Tormasov further discloses wherein one or more characteristics of the workload used to detect the condition are not provided to the host OS (Col. 2, Lines 44-50- code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. Please note that the appropriate results of code execution and interpretation being transmitted to only the guest OS of the main computing system corresponds to Applicant’s one or more characteristics of the workload used to detect the condition not being provided to the host OS, as they are provided to the guest OS instead.).
Regarding Claim 6, Tormasov-Saxena as described in Claim 1, Saxena further discloses detect the condition by evaluating a characteristic of at least one of the workload, the operation of the CPU, or the operation of the GPU, using one or more rules, policies, or heuristics ([0073] the example scheduler 304 of FIG. 3 obtains the status of the tasks being executed (e.g., in parallel) on the GPU 106. For example, the scheduler 304 of FIG. 3 determines whether a particular task has been initiated, has been preempted, has been completed, etc. Please note that obtaining the status of tasks being executed on the GPU corresponds to Applicant’s detecting the condition by evaluating a characteristic of the operation of the GPU and of the workload, and determining whether a particular task has been initiated, preempted, completed, etc. corresponds to Applicant’s detecting the condition using rules. As the limitations state “at least one of” the characteristics being evaluated and using “one or more of” the methods of evaluation, this is interpreted by the Examiner as fulfilling the requirements of the Claim.).
Regarding Claim 7, Tormasov-Saxena as described in Claim 1, Saxena further discloses wherein the workload is a real-time workload of the VM ([0039] one or more patterns detected on one or more of the other computing platforms may be conveyed to the network interface 110 in real time (e.g., without delay or as soon as reasonably possible); [0042] a current workload of the CPU 108 and/or a current workload of the GPU; [0082] utilize the information received at the example real time receiver 404 of FIG. 4 to adjust or alter scheduled, pending, and/or current memory scans. Please note that the patterns detected in the computing platform being conveyed in real time, where the information is received at the real time receiver, corresponds to Applicant’s workload being a real-time workload of the VM.).
Regarding Claim 8, Tormasov-Saxena as described in Claim 1, Tormasov further discloses wherein the one or more processors are comprised in at least one of: a system incorporating one or more VMs; a system for performing simulation operations; a system for performing light transport simulation; a system implemented using an edge device; a system implemented using a robot; a system for performing collaborative content creation for 3D assets; a system comprising one or more large language models (LLMs); a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for generating synthetic data; a system for performing digital twin operations; a system for performing conversational AI operations; a system for performing deep learning operations; a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources (Col. 1, Lines 57-59- A Virtual Machine technology requires employing hardware of a real physical machine or a processor for support of a VM. Please note that the virtual machine technology requiring the employing of hardware of a real processor for the support of the VM corresponds to Applicant’s one or more processors being comprised in a system incorporating VMs. As the limitations state being comprised in “at least one of” the systems, this is interpreted by the Examiner as fulfilling the requirements of the Claim. ).
Regarding Claim 9, Tormasov discloses A system, comprising: one or more processing units; and one or more memory units storing instructions that, when executed by the one or more processing units, cause the one or more processing units to execute operations (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up.; In yet another embodiment, a system for employing a GPU in a virtual environment includes a CPU, a GPU coupled to the CPU, and a memory coupled to the CPU. A Virtual Machine Monitor (VMM) has virtualization means and supporting a Virtual Machine (VM) implemented on the computer system. Please note that the VMM of the system for employing a GPU in a virtual environment including a CPU, where the system comprises a CPU, a GPU coupled to the CPU, and a memory coupled to the CPU, where there is source code that needs to be executed corresponds to Applicant’s system comprising processing units and memory units storing instructions that cause the processing units to execute operations when executed by them.) comprising:
detecting, using a guest operating system (OS) of a virtual machine (VM) (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up.; In yet another embodiment, a system for employing a GPU in a virtual environment includes a CPU, a GPU coupled to the CPU, and a memory coupled to the CPU. A Virtual Machine Monitor (VMM) has virtualization means and supporting a Virtual Machine (VM) implemented on the computer system. Please note that the VMM supporting the VM implemented on the computer system that detects computationally intensive VM operations which may be associated with guest OSes of the main computing system which uses the main CPU corresponds to Applicant’s detecting using a guest OS of a VM.),
the target level based on at least one of (i) a characteristic of the workload or (ii) operation of the other of the CPU or GPU (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up.; In yet another embodiment, a system for employing a GPU in a virtual environment includes a CPU, a GPU coupled to the CPU, and a memory coupled to the CPU. A Virtual Machine Monitor (VMM) has virtualization means and supporting a Virtual Machine (VM) implemented on the computer system. Please note that the VMM supporting the VM implemented on the computer system that detects computationally intensive VM operations, where the code may be off-loaded to the GPU based on CPU load corresponds to Applicant’s target level being based on the operation of another of the processing units, i.e., the GPU being available to have the CPU load offloaded to it. Additionally, as it is detected whether the VM operations are computationally intensive, this corresponds to the target level being based on the characteristic of the workload as well.);
providing, to a host OS, based at least on the condition, an instruction to reduce operation of the one of the CPU or the GPU (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up. Please note that freeing up the host system CPU once the offload is completed corresponds to Applicant’s providing an instruction to reduce operation of the one of the processing units to the host OS based on the condition.);
and modifying, by the host OS, behavior of the one or more processing units based on the instruction (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up. Please note that carrying out the operation that frees up the host system CPU by offloading the code to the GPU based on the CPU load corresponds to Applicant’s modifying behavior of the processing units based on the instruction by the host OS.).
Tormasov does not explicitly disclose a condition of a workload of the VM being executed on a central processing unit (CPU) and on a graphics processing unit (GPU) through the VM, the condition indicative of operation of one of the CPU or GPU being different than a target level of operation
However, Saxena a condition of a workload of the VM being executed on a central processing unit (CPU) and on a graphics processing unit (GPU) through the VM([0042] based on a current workload of the CPU 108 and/or a current workload of the GPU 106. Please note that the current workload of the CPU 108 and the current workload of the GPU 106 corresponds to Applicant’s condition of a workload of the VM being executed on processing units including a CPU and a GPU),
the condition indicative of operation of one of the CPU or GPU being different than a target level of operation ( [0022] Examples disclosed herein alleviate, mitigate, and/or eliminate negative impacts of executing computing tasks (e.g., security tasks and/or any other type of computing task(s)) on the CPU by offloading one or more computing tasks (e.g., security tasks) to a graphics processing unit (GPU). Computing tasks offloaded to the GPU by examples disclosed do not consume CPU cycles, thereby reducing the computation burden of the CPU and the amount of power consumed by the CPU. As the number of CPU cycles consumed by an application and/or an amount of CPU-related power consumed by the application are often used to measure performance of an application, examples disclosed herein are especially attractive to, for example, independent software vendors (ISVs) and other types of developers required to meet restrictions or limitations (e.g., benchmarks) placed on CPU cycle and/or power consumption. Please note that the methods allowing the system to meet restrictions or limitations placed on CPU cycle and power consumption, where the CPU cycles consumed are measured, corresponds to Applicant’s condition indicative of operation of one of the processing units being different than a target level of operation, i.e., assessing that there are more CPU cycles being consumed than the limitation level. )
Tormasov and Saxena are both considered to be analogous to the claimed invention because they are in the same field of managing resources of computing platforms. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Tormasov to incorporate the teachings of Saxena to modify the system with a processor with a circuit to use a guest OS of a VM to perform detection, assess the target level based on a characteristic of the workload and the operation of another of the processing units, provide an instruction to reduce operation of one of the processing units to a host OS and modify behavior of the processing units based on the instruction by the host OS to do so based on a condition of a workload of the VM being executed on processing units including a CPU and a GPU, with the condition indicating operation of the processing units being different than a target level of operation , allowing for improved resource usage and power consumption, as described in Saxena.
Regarding Claim 10, Tormasov-Saxena as described in Claim 9, Tormasov further discloses executing the VM, and wherein the VM is configured to cause the CPU and the GPU to execute the workload (Col. 1, Lines 57- 65- A Virtual Machine technology requires employing hardware of a real physical machine or a processor for support of a VM. A hardware element that is increasingly used for acceleration of physical machines is a Graphic Processing Unit (GPU). General-purpose computing on graphics processing units (GPGPU, also referred to as GPGP) is a technique of employing the GPU, which typically handles only computations related to computer graphics, for performing computations for other applications traditionally handled by the CPU. Please note that the GPU performing computations that can also be handled by the CPU for the implementation of Virtual Machine technology corresponds to Applicant’s executing the VM and the VM being configured to cause the CPU and GPU to execute the workload.).
Saxena further discloses the CPU and the GPU to execute the workload ([0042] a current workload of the CPU 108 and/or a current workload of the GPU 106. Please note that a current workload of the CPU 108 and the GPU 106 corresponds to Applicant’s CPU and GPU to execute the workload.)
Regarding Claim 11, Tormasov-Saxena as described in Claim 9, Saxena further discloses detecting the condition based at least on one of: i) a load of the GPU, ii) an occupancy of a queue of the GPU, or iii) a resolution characteristic ([0043] bases a frequency and/or timing of the scans on […] a current load on the GPU 108. Please note that basing the scan timing on a current load on the GPU 108 corresponds to Applicant’s detecting the condition based on a load of the GPU. As the limitation states “at least one of” the bases for the condition detected, this is interpreted by the Examiner as fulfilling the requirements of the Claim.).
Regarding Claim 12, Tormasov-Saxena as described in Claim 9, Tormasov further discloses communicating the instruction to the host OS using a channel from a guest OS to the host OS (Col. 5, Lines 30-33- a system architecture that provides communication channel between a guest system and a host system, including interrupt delivery, data transmission and guest system memory sharing. Please note that the system architecture providing a communication channel between a guest and host system, including data transmission, corresponds to Applicant’s communicating the instruction to the host OS using a channel from a guest OS to the host OS.).
Regarding Claim 13, Tormasov-Saxena as described in Claim 9, Tormasov further discloses wherein one or more characteristics of the workload used to detect the condition are not provided to the host OS (Col. 2, Lines 44-50- code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. Please note that the appropriate results of code execution and interpretation being transmitted to only the guest OS of the main computing system corresponds to Applicant’s one or more characteristics of the workload used to detect the condition not being provided to the host OS, as they are provided to the guest OS instead.).
Regarding Claim 14, Tormasov-Saxena as described in Claim 9, Saxena further discloses detect the condition by evaluating a characteristic of at least one of the workload, the operation of the CPU, or the operation of the GPU, using one or more rules, policies, or heuristics ([0073] the example scheduler 304 of FIG. 3 obtains the status of the tasks being executed (e.g., in parallel) on the GPU 106. For example, the scheduler 304 of FIG. 3 determines whether a particular task has been initiated, has been preempted, has been completed, etc. Please note that obtaining the status of tasks being executed on the GPU corresponds to Applicant’s detecting the condition by evaluating a characteristic of the operation of the GPU and of the workload, and determining whether a particular task has been initiated, preempted, completed, etc. corresponds to Applicant’s detecting the condition using rules. As the limitations state “at least one of” the characteristics being evaluated and using “one or more of” the methods of evaluation, this is interpreted by the Examiner as fulfilling the requirements of the Claim.).
Regarding Claim 15, Tormasov discloses A method, comprising: detecting, using a guest operating system (OS) of a virtual machine (VM) (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up.; In yet another embodiment, a system for employing a GPU in a virtual environment includes a CPU, a GPU coupled to the CPU, and a memory coupled to the CPU. A Virtual Machine Monitor (VMM) has virtualization means and supporting a Virtual Machine (VM) implemented on the computer system. Please note that the VMM supporting the VM implemented on the computer system that detects computationally intensive VM operations which may be associated with guest OSes of the main computing system which uses the main CPU corresponds to Applicant’s method comprising detecting using a guest OS of a VM.),
the target level based on at least one of (i) a characteristic of the workload or (ii) operation of another of the processing units (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up.; In yet another embodiment, a system for employing a GPU in a virtual environment includes a CPU, a GPU coupled to the CPU, and a memory coupled to the CPU. A Virtual Machine Monitor (VMM) has virtualization means and supporting a Virtual Machine (VM) implemented on the computer system. Please note that the VMM supporting the VM implemented on the computer system that detects computationally intensive VM operations, where the code may be off-loaded to the GPU based on CPU load corresponds to Applicant’s target level being based on the operation of another of the processing units, i.e., the GPU being available to have the CPU load offloaded to it. Additionally, as it is detected whether the VM operations are computationally intensive, this corresponds to the target level being based on the characteristic of the workload as well.);
provide, to a host OS, based at least on the condition, an instruction to reduce operation of the one of the processing units (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up. Please note that freeing up the host system CPU once the offload is completed corresponds to Applicant’s providing an instruction to reduce operation of the one of the processing units to the host OS based on the condition.);
and modify, by the host OS, behavior of the processing units based on the instruction (Col. 2, Lines 44-67- In one embodiment, source code .Net, Python or Java code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. The code (or portions thereof) is off-loaded to the GPU based on CPU load and on a number of VMM exist triggered by execution of the code.; According to another exemplary embodiment, the computationally intensive VM operations are detected by a VMM (virtual machine monitor) and off-loaded to the host system GPU, and the host system CPU is advantageously freed up. Please note that carrying out the operation that frees up the host system CPU by offloading the code to the GPU based on the CPU load corresponds to Applicant’s modifying behavior of the processing units based on the instruction by the host OS.).
Tormasov does not explicitly disclose a condition of a workload of the VM being executed on processing units including a central processing unit (CPU) and a graphics processing unit (GPU), the condition indicative of operation of one of the processing units being different than a target level of operation
However, Saxena discloses a condition of a workload of the VM being executed on processing units including a central processing unit (CPU) and a graphics processing unit (GPU) ([0042] based on a current workload of the CPU 108 and/or a current workload of the GPU 106. Please note that the current workload of the CPU 108 and the current workload of the GPU 106 corresponds to Applicant’s condition of a workload of the VM being executed on processing units including a CPU and a GPU),
the condition indicative of operation of one of the processing units being different than a target level of operation ( [0022] Examples disclosed herein alleviate, mitigate, and/or eliminate negative impacts of executing computing tasks (e.g., security tasks and/or any other type of computing task(s)) on the CPU by offloading one or more computing tasks (e.g., security tasks) to a graphics processing unit (GPU). Computing tasks offloaded to the GPU by examples disclosed do not consume CPU cycles, thereby reducing the computation burden of the CPU and the amount of power consumed by the CPU. As the number of CPU cycles consumed by an application and/or an amount of CPU-related power consumed by the application are often used to measure performance of an application, examples disclosed herein are especially attractive to, for example, independent software vendors (ISVs) and other types of developers required to meet restrictions or limitations (e.g., benchmarks) placed on CPU cycle and/or power consumption. Please note that the methods allowing the system to meet restrictions or limitations placed on CPU cycle and power consumption, where the CPU cycles consumed are measured, corresponds to Applicant’s condition indicative of operation of one of the processing units being different than a target level of operation, i.e., assessing that there are more CPU cycles being consumed than the limitation level. )
Tormasov and Saxena are both considered to be analogous to the claimed invention because they are in the same field of managing resources of computing platforms. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Tormasov to incorporate the teachings of Saxena to modify the system with a processor with a circuit to use a guest OS of a VM to perform detection, assess the target level based on a characteristic of the workload and the operation of another of the processing units, provide an instruction to reduce operation of one of the processing units to a host OS and modify behavior of the processing units based on the instruction by the host OS to do so based on a condition of a workload of the VM being executed on processing units including a CPU and a GPU, with the condition indicating operation of the processing units being different than a target level of operation , allowing for improved resource usage and power consumption, as described in Saxena.
Regarding Claim 16, Tormasov-Saxena as described in Claim 15, Tormasov further discloses executing the VM, and wherein the VM is configured to cause the CPU and the GPU to execute the workload (Col. 1, Lines 57- 65- A Virtual Machine technology requires employing hardware of a real physical machine or a processor for support of a VM. A hardware element that is increasingly used for acceleration of physical machines is a Graphic Processing Unit (GPU). General-purpose computing on graphics processing units (GPGPU, also referred to as GPGP) is a technique of employing the GPU, which typically handles only computations related to computer graphics, for performing computations for other applications traditionally handled by the CPU. Please note that the GPU performing computations that can also be handled by the CPU for the implementation of Virtual Machine technology corresponds to Applicant’s executing the VM and the VM being configured to cause the CPU and GPU to execute the workload.).
Saxena further discloses the CPU and the GPU to execute the workload ([0042] a current workload of the CPU 108 and/or a current workload of the GPU 106. Please note that a current workload of the CPU 108 and the GPU 106 corresponds to Applicant’s CPU and GPU to execute the workload.)
Regarding Claim 17, Tormasov-Saxena as described in Claim 15, Saxena further discloses detecting the condition based at least on one of: i) a load of the GPU, ii) an occupancy of a queue of the GPU, or iii) a resolution characteristic ([0043] bases a frequency and/or timing of the scans on […] a current load on the GPU 108. Please note that basing the scan timing on a current load on the GPU 108 corresponds to Applicant’s detecting the condition based on a load of the GPU. As the limitation states “at least one of” the bases for the condition detected, this is interpreted by the Examiner as fulfilling the requirements of the Claim.).
Regarding Claim 18, Tormasov-Saxena as described in Claim 15, Tormasov further discloses communicating the instruction to the host OS using a channel from a guest OS to the host OS (Col. 5, Lines 30-33- a system architecture that provides communication channel between a guest system and a host system, including interrupt delivery, data transmission and guest system memory sharing. Please note that the system architecture providing a communication channel between a guest and host system, including data transmission, corresponds to Applicant’s communicating the instruction to the host OS using a channel from a guest OS to the host OS.).
Regarding Claim 19, Tormasov-Saxena as described in Claim 15, Tormasov further discloses wherein one or more characteristics of the workload used to detect the condition are not provided to the host OS (Col. 2, Lines 44-50- code that needs to be executed is launched in the VM or in a container placed on the GPU. Secure or optimized object code or other appropriate results of code execution, compilation or interpretation are then transmitted to the host or guest OS(es) of the main computing system, which uses the main CPU. Please note that the appropriate results of code execution and interpretation being transmitted to only the guest OS of the main computing system corresponds to Applicant’s one or more characteristics of the workload used to detect the condition not being provided to the host OS, as they are provided to the guest OS instead.).
Regarding Claim 20, Tormasov-Saxena as described in Claim 15, Saxena further discloses detect the condition by evaluating a characteristic of at least one of the workload, the operation of the CPU, or the operation of the GPU, using one or more rules, policies, or heuristics ([0073] the example scheduler 304 of FIG. 3 obtains the status of the tasks being executed (e.g., in parallel) on the GPU 106. For example, the scheduler 304 of FIG. 3 determines whether a particular task has been initiated, has been preempted, has been completed, etc. Please note that obtaining the status of tasks being executed on the GPU corresponds to Applicant’s detecting the condition by evaluating a characteristic of the operation of the GPU and of the workload, and determining whether a particular task has been initiated, preempted, completed, etc. corresponds to Applicant’s detecting the condition using rules. As the limitations state “at least one of” the characteristics being evaluated and using “one or more of” the methods of evaluation, this is interpreted by the Examiner as fulfilling the requirements of the Claim.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Krishnan et al. (US 20190324820 A1) discloses load balancing, providing hardware resources to a virtual machine, a host OS and a guest OS, a workload domain with power considerations, utilizing GPUs and CPUs for the workload, and determining the satisfaction of a health status relating to performance and capacity of the workload domain (see [0018-0020, 0030-0032]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARAZ T AKBARI whose telephone number is (571)272-4166. The examiner can normally be reached Monday-Thursday 9:30am-7:30pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached at (571)270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/FARAZ T AKBARI/Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights