Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 2-7 and 15-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 2, is indefinite because it recites “allowing execution of the first virtual machine” when the first thread is idle without clarifying this condition in relation to the condition recited in claim 1. Claim 2 does not specify whether SMT protection remains enable or disable when the first thread is idle as a result the execution condition of the first virtual machine is unclear
Regarding claim 3, is indefinite because it depends from claim 2, which requires that the first thread is idle, claim 3 recites “ in response to identifying that the first thread is executing”. This conditions are contradictory and renders the scope of claim 3 unclear
Regarding claim 4, is indefinite because it depends from claim 1, which recites preventing “preventing execution of the first virtual machine responsive”. Claim 4 contradicts this condition it recites “the first virtual machine is executing”. The execution of the virtual machine is unclear under the combine limitations.
Regarding claims 2-12, 14, and 16-20, dependent claims inherit the deficiencies of the respective parent claim.
Regarding claim 15, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2.
Regarding claim 16, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 .
Regarding claim 17, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claims 5-7, and 18-20, dependent claims inherit the deficiencies of the respective parent claim.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 8 and 12-16 are rejected under 35 U.S.C. 103 as being unpatentable over by Saito (US 20130081016 A1).
Regarding claim 1, Saito teaches:
A method comprising: (Claim 22. A control method for controlling a virtual machine system, the virtual machine system including a plurality of processors and for causing a plurality of virtual machines to operate, each processor being placed in any of:)
in response to receiving, at a simultaneous multithreading (SMT) processor, a request to execute a first virtual machine, identifying whether a first thread is executing at the SMT processor, wherein the first thread is associated with first software different than the first virtual machine; and ([0095] FIG. 4 is a functional structure diagram showing the main functional blocks constituting the virtual machine system 100, in a state where three virtual machines are allocated to the processor A 101 and one virtual machine is allocated to the processor C 103.[0096] As shown in FIG. 4, the virtual machine system 100 includes a hypervisor 440 and a plurality of virtual machines (virtual machines A 411, B 412, C 413, and D 414 in the present example). [0149] Upon completion of step S730, the virtual machine allocation unit 442 causes all the virtual machines to operate on the processor A 101, based on the virtual machine information stored in the virtual machine information storage unit 445 (step S740). [0152] The system update processing is processing of dynamically changing the attribute of each processor, based on a change in the number of tasks existing in each task queue managed by the OS operating in each virtual machine, and dynamically changing the allocation of the virtual machines to the processors. [0402] The allocation unit 3501 allocates each virtual machine to any processor that is supplied with power. For example, the allocation unit 3501 is realized as one of the functions of the hypervisor 440 in Embodiment 1 (see FIG. 4).) ([0163] If the number of tasks is equal to or greater than the first predetermined number (such as 30) in step S910, the virtual machine allocation unit 442 checks whether another virtual machine is allocated to, and operating on, the processor on which the virtual machine identified by the selected virtual machine ID is operating (step S920) . [0164] If another virtual machine is allocated to and operating on the processor in step S920 (step S920: Yes), the virtual machine allocation unit 442 checks whether a processor having the attribute of "standby" exists (step S930). [0168] When the virtual machine allocation change processing is started by the virtual machine system 100, the virtual machine allocation unit 442 checks whether a target virtual machine in the moving source processor is performing processing (step S1100). EN: Figures 4, 15, 22, 34 clearly show a task, e.g. thread can execute on certain VMs. The prior art demonstrates that incoming VMs are either allowed or disallowed to run on a particular processor that is already running a VM having tasks, i.e. threads, based on the mode set by the processor.)
in response to identifying that the first thread is executing, preventing execution of the first virtual machine responsive to security control information indicating that SMT protection is enabled for the first virtual machine. ([0123] Each of the attributes 602 is information indicating the attribute of a processor identified by a corresponding processor ID. [0124] Each of the processors A 101 to D 104 is associated with one of four attributes, i.e., "exclusive", "share", "standby", and "off".[0125] The attribute of "exclusive" indicates that the processor operates in the normal operation mode in which the supply voltage is 1.2 V and the operating frequency is 1 GHz, and the number of virtual machines operating on the processor is limited to one. [0169] If the target virtual machine in the moving source processor is performing processing in step S1100 (step S1100: Yes), the virtual machine allocation unit 442 saves the state of the target virtual machine that is performing processing (i.e., a data set necessary for restoring the processing of the target virtual machine, such as data stored in each register) into a predetermined area of the RAM 114 (step S1110).[0170] In step S1100, if the target virtual machine in the moving source processor is not performing processing (step S1100: No), the target virtual machine is in a state where data thereof is saved by time sharing. Accordingly, the state of the target virtual machine is saved in a predetermined area of the RAM 114 (step S1120).; EN: Figures 4, 15, 22, 34 clearly show a task, e.g. thread can execute on certain VMs. The prior art demonstrates that incoming VMs are either allowed or disallowed to run on a particular processor that is already running a VM having tasks, i.e. threads, based on the mode set by the processor.)
However, Saito does not appear to explicitly teach: the mode is security control information
[0124] Each of the processors A 101 to D 104 is associated with one of four attributes, i.e., "exclusive", "share", "standby", and "off". [0125] The attribute of "exclusive" indicates that the processor operates in the normal operation mode in which the supply voltage is 1.2 V and the operating frequency is 1 GHz, and the number of virtual machines operating on the processor is limited to one. [0126] The attribute of "share" indicates that the processor operates in the normal operation mode in which the supply voltage is 1.2 V and the operating frequency is 1 GHz, and the number of virtual machines operating on the processor is equal to or greater than one.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Saito before them to use the “exclusive” attribute with limits the execution of single virtual machine in the processor. This executions prevents the concurrent execution of multiple virtual machines on the same processor a result providing isolation and protection against other executing software.
Regarding claim 2, Saito teaches:
The method of claim 1, further comprising: in response to identifying that the first thread is idle, allowing execution of the first virtual machine. ([0148] Upon completion of step S720, the processor management unit 444 generates the processor information such that: the attribute of the processor A 101 is "share"; the attribute of the processor B 102 is "standby"; the attribute of each of the processors C 103 and D 104 is "off"; the number of virtual machines associated with the processor A 101 is the total number of virtual machines targeted for execution; and the number of virtual machines associated with each of the processors B 102, C 103, and D 104 is "0" which is an initial value, and stores the processor information thus generated into the processor information storage unit 446 (step S730). [0164] If another virtual machine is allocated to and operating on the processor in step S920 (step S920: Yes), the virtual machine allocation unit 442 checks whether a processor having the attribute of "standby" exists (step S930). [0165] If a processor having the attribute of "standby" exists in step S930 (step S930: Yes), the virtual machine allocation unit 442 causes the processor management unit 444 to update the processor information stored in the processor information storage unit 446, such that the attribute of the processor is changed from "standby" to "exclusive" (step S940).[0166] Upon completion of step S940, the virtual machine allocation unit 442 changes the processor to which the virtual machine identified by the selected virtual machine ID is allocated to operate, from the processor to which the virtual machine is currently allocated to operate (hereinafter "moving source processor") to the processor whose attribute has been changed from "standby" to "exclusive" in step S940 (hereinafter "moving destination processor") (step S950: virtual machine allocation change processing).)
Regarding claim 3, Saito teaches:
The method of claim 2, further comprising: in response to identifying that the first thread is executing, allowing execution of the first virtual machine responsive to security control information indicating that SMT protection is disabled for the first virtual machine. ([0161] After selecting one virtual machine ID, the virtual machine allocation unit 442 reads (i) the virtual machine information stored in the virtual machine information storage unit 445 and (ii) the processor information stored in the processor information storage unit 446, and checks whether the attribute of the processor on which the virtual machine identified by the selected virtual machine ID is operating is "share" (step S900).[0162] If the attribute of the processor on which the virtual machine identified by the selected virtual machine ID is operating is "share" in step S900 (step S900: Yes), the virtual machine allocation unit 442 checks whether the number of tasks corresponding to the virtual machine is equal to or greater than a first predetermined number (such as 30) (step S910).)
Regarding claim 8, Saito teaches:
A method, comprising: (A control method for controlling a virtual machine system, the virtual machine system including a plurality of processors and for causing a plurality of virtual machines to operate, each processor being placed in any of:)
in response to receiving, at a simultaneous multithreading (SMT) processor an interrupt associated with first software while a first thread of the first software is in an idle state: ([0152] The system update processing is processing of dynamically changing the attribute of each processor, based on a change in the number of tasks existing in each task queue managed by the OS operating in each virtual machine, and dynamically changing the allocation of the virtual machines to the processors. [0165] If a processor having the attribute of "standby" exists in step S930 (step S930: Yes), the virtual machine allocation unit 442 causes the processor management unit 444 to update the processor information stored in the processor information storage unit 446, such that the attribute of the processor is changed from "standby" to "exclusive" (step S940). [0166] Upon completion of step S940, the virtual machine allocation unit 442 changes the processor to which the virtual machine identified by the selected virtual machine ID is allocated to operate, from the processor to which the virtual machine is currently allocated to operate (hereinafter "moving source processor") to the processor whose attribute has been changed from "standby" to "exclusive" in step S940 (hereinafter "moving destination processor") (step S950: virtual machine allocation change processing). EN: Figures 4, 15, 22, 34 clearly show a task, e.g. thread can execute on certain VMs. The prior art demonstrates that incoming VMs are either allowed or disallowed to run on a particular processor that is already running a VM having tasks, i.e. threads, based on the mode set by the processor.)
responsive to determining that a first virtual machine is executing at the processor, preventing the first thread from executing responsive to the interrupt. ([0164] If another virtual machine is allocated to and operating on the processor in step S920 (step S920: Yes), the virtual machine allocation unit 442 checks whether a processor having the attribute of "standby" exists (step S930). [0165] If a processor having the attribute of "standby" exists in step S930 (step S930: Yes), the virtual machine allocation unit 442 causes the processor management unit 444 to update the processor information stored in the processor information storage unit 446, such that the attribute of the processor is changed from "standby" to "exclusive" (step S940). [0166] Upon completion of step S940, the virtual machine allocation unit 442 changes the processor to which the virtual machine identified by the selected virtual machine ID is allocated to operate, from the processor to which the virtual machine is currently allocated to operate (hereinafter "moving source processor") to the processor whose attribute has been changed from "standby" to "exclusive" in step S940 (hereinafter "moving destination processor") (step S950: virtual machine allocation change processing). EN: Figures 4, 15, 22, 34 clearly show a task, e.g. thread can execute on certain VMs. The prior art demonstrates that incoming VMs are either allowed or disallowed to run on a particular processor that is already running a VM having tasks, i.e. threads, based on the mode set by the processor.)
Regarding claim 12, Saito teaches:
The method of claim 8, wherein preventing the first thread from executing comprises preventing the first thread from executing responsive to an SMT protection mode being enabled for the first virtual machine. ([0123] Each of the attributes 602 is information indicating the attribute of a processor identified by a corresponding processor ID. [0124] Each of the processors A 101 to D 104 is associated with one of four attributes, i.e., "exclusive", "share", "standby", and "off". [0125] The attribute of "exclusive" indicates that the processor operates in the normal operation mode in which the supply voltage is 1.2 V and the operating frequency is 1 GHz, and the number of virtual machines operating on the processor is limited to one. [0178] If another virtual machine is not allocated to the processor to operate in step S920 (step S920: No), the virtual machine allocation unit 442 causes the processor management unit 444 to update the processor information stored in the processor information storage unit 446, such that the attribute of the processor is changed from "share" to "exclusive" (step S990). [0179] If the attribute of the processor on which the virtual machine identified by the selected virtual machine ID is operating is not "share" in step S900, i.e., the attribute of the processor is "exclusive" (step S900: No), the virtual machine allocation unit 442 checks whether the number of tasks corresponding to the virtual machine is equal to or less than a second predetermined number (such as 25) (step S1000 of FIG. 10). EN: Figures 4, 15, 22, 34 clearly show a task, e.g. thread can execute on certain VMs. The prior art demonstrates that incoming VMs are either allowed or disallowed to run on a particular processor that is already running a VM having tasks, i.e. threads, based on the mode set by the processor.)
Regarding claim 13, Saito teaches:
The method of claim 12, further comprising executing the first thread responsive to the SMT protection mode being disabled for the first virtual machine. ([0161] After selecting one virtual machine ID, the virtual machine allocation unit 442 reads (i) the virtual machine information stored in the virtual machine information storage unit 445 and (ii) the processor information stored in the processor information storage unit 446, and checks whether the attribute of the processor on which the virtual machine identified by the selected virtual machine ID is operating is "share" (step S900). [0162] If the attribute of the processor on which the virtual machine identified by the selected virtual machine ID is operating is "share" in step S900 (step S900: Yes), the virtual machine allocation unit 442 checks whether the number of tasks corresponding to the virtual machine is equal to or greater than a first predetermined number (such as 30) (step S910). [0163] If the number of tasks is equal to or greater than the first predetermined number (such as 30) in step S910, the virtual machine allocation unit 442 checks whether another virtual machine is allocated to, and operating on, the processor on which the virtual machine identified by the selected virtual machine ID is operating (step S920).)
Regarding claim 14, Saito teaches:
A simultaneous multithreading (SMT) processor comprising: a processor core to receive a request to execute a first virtual machine; and secure hardware to. (Claim 12. A virtual machine system including a plurality of processors and for causing a plurality of virtual machines to operate, each processor being placed in any of: )
The claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale
Regarding claim 15, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 16, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Claims 4-7, 9-11 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Saito (US 20130081016 A1) in view of Tsirkin (US 11106481 B2).
Regarding claim 4, Saito does not appear to explicitly teach:
The method of claim 1, further comprising: in response to receiving an interrupt associated with the first software while the first thread is in an idle state and the first virtual machine is executing: preventing the first thread from executing responsive to the interrupt.
However, Tsirkin teaches: (col 6, line 51-67. In some implementations, logical processor management module 243 may send an inter-processor interrupt (IPI) to logical processor 202-B by invoking interrupt processing module 244. The IPI can cause logical processor 202-B to cause virtual processor 231-B to return control to the hypervisor 235. Thus, virtual processor 231-B should not execute a VM related task while hypervisor 235 retains execution control of logical processor 202-A. Once logical processor 202-B has returned control to hypervisor 235 (e.g., the logical processor has been halted), logical processor management module 243 can then send an instruction to logical processor 202-A to transfer execution control to hypervisor 235. In some implementations, logical processor management module 243 may determine that logical processor 202-B has returned control to hypervisor 235 by receiving a notification from logical processor 202-B that it has returned control.)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Saito and Tsirkin before them, to include Tsirkin’s interrupt feature Saito’s virtual machine management system. Incorporating Tsirkin’s teaching would merely involve applying a known technique of interrupt based execution control to a virtual machine management framework yielding predictable result of preventing execution of thread or virtual processors while handling interrupts .
Regarding claim 5, Tsirkin teaches:
The method of claim 4, further comprising: in response to receiving the interrupt while the first thread is in an idle state and the first virtual machine is executing: notifying the first virtual machine of the interrupt; and exiting execution of the first virtual machine in response to the notifying. (col 8, line37-52. At block 305, processing logic detects a VM exit issued by first virtual processor of a virtual machine, where the first virtual processor is associated with a first logical processor of a host CPU. At block 310, processing logic determines that a second virtual processor of the virtual machine is associated with a second logical processor of the host CPU. At block 315, processing logic determines an execution state of the second virtual processor. In some implementations, processing logic makes this determination by receiving a notification from the second virtual processor that the second virtual processor has executed a VM exit to return control to the hypervisor. At block 320, processing logic determines whether the execution state of the second virtual processor indicates that it is running. If so, processing proceeds to block 325. If so, processing continues to block 325. Otherwise, processing proceeds to block 335.)
Same motivation as claim 4
Regarding claim 6, Tsirkin teaches:
The method of claim 5, wherein notifying the first virtual machine comprises triggering an inter-processor interrupt (IPI) to the first virtual machine. (col 6, line 44-58. Responsive to virtual processor management module 242 determining that the execution state of virtual processor 231-B indicates that it is running, logical processor management module 243 may be invoked to send an instruction to logical processor 202-B (the logical processor associated with virtual processor 231-B) to cause the virtual processor 202-B to return control to hypervisor 235. In some implementations, logical processor management module 243 may send an inter-processor interrupt (IPI) to logical processor 202-B by invoking interrupt processing module 244. The IPI can cause logical processor 202-B to cause virtual processor 231-B to return control to the hypervisor 235. Thus, virtual processor 231-B should not execute a VM related task while hypervisor 235 retains execution control of logical processor 202-A.)
Same motivation as claim 4
Regarding claim 7, Tsirkin teaches:
The method of claim 6, wherein notifying the first virtual machine comprises writing a specified value to a register to trigger the IPI. (col 7, line 60-67. As noted above, this instruction could be an IPI instruction. Alternatively, logical processor management module 243 may set an indicator that prevents the hypervisor from executing a hypervisor related task using logical processor 202-A. In some implementations, this indicator may be stored in a register, data structure, memory space, or other similar structure, that is checked by hypervisor 235 prior to executing a hypervisor related task.)
Same motivation as claim 4
Regarding claim 9, Tsirkin teaches:
The method of claim 8, further comprising: in response to receiving the interrupt while the first thread is in the idle state and the first virtual machine is executing: notifying the first virtual machine of the interrupt; and exiting execution of the first virtual machine in response to the notifying. (col 8, line37-52. At block 305, processing logic detects a VM exit issued by first virtual processor of a virtual machine, where the first virtual processor is associated with a first logical processor of a host CPU. At block 310, processing logic determines that a second virtual processor of the virtual machine is associated with a second logical processor of the host CPU. At block 315, processing logic determines an execution state of the second virtual processor. In some implementations, processing logic makes this determination by receiving a notification from the second virtual processor that the second virtual processor has executed a VM exit to return control to the hypervisor. At block 320, processing logic determines whether the execution state of the second virtual processor indicates that it is running. If so, processing proceeds to block 325. If so, processing continues to block 325. Otherwise, processing proceeds to block 335.)
Same motivation as claim 4
Regarding claim 10, Tsirkin teaches:
The method of claim 9, wherein notifying the first virtual machine comprises triggering an inter-processor interrupt (IPI) to the first virtual machine. (col 6, line 44-58. Responsive to virtual processor management module 242 determining that the execution state of virtual processor 231-B indicates that it is running, logical processor management module 243 may be invoked to send an instruction to logical processor 202-B (the logical processor associated with virtual processor 231-B) to cause the virtual processor 202-B to return control to hypervisor 235. In some implementations, logical processor management module 243 may send an inter-processor interrupt (IPI) to logical processor 202-B by invoking interrupt processing module 244. The IPI can cause logical processor 202-B to cause virtual processor 231-B to return control to the hypervisor 235. Thus, virtual processor 231-B should not execute a VM related task while hypervisor 235 retains execution control of logical processor 202-A.)
Same motivation as claim 4
Regarding claim 11, Tsirkin teaches:
The method of claim 10, wherein notifying the first virtual machine comprises writing a specified value to a register to trigger the IPI. (col 7, line 60-67. As noted above, this instruction could be an IPI instruction. Alternatively, logical processor management module 243 may set an indicator that prevents the hypervisor from executing a hypervisor related task using logical processor 202-A. In some implementations, this indicator may be stored in a register, data structure, memory space, or other similar structure, that is checked by hypervisor 235 prior to executing a hypervisor related task.)
Same motivation as claim 4
Regarding claim 17, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 18, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like
assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199