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
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/23/26 has been entered.
Response to Arguments
Applicant’s arguments with respect to independent claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claim/s 1, 2, 5, 11, 12, 15, 20, 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over
Tsirkin_875 (Pub. No. US 2023/0305875) in view of Tsirkin_344 (Pub. No. US 2021/0216344)
Claim 1, 11, 20 Tsirkin_875 teaches “A method, implemented at a computer system that includes a processor system, comprising: receiving a request at a hypervisor, wherein the request is received from a first guest partition that operates at the hypervisor, and requests to create a second guest partition as a child of the first guest partition; identifying, by the hypervisor, a configuration specification for the second guest partition, the configuration specification including: an identification of a memory portion, which is allocated to the first guest partition, that is to be mapped into the second guest partition, and a virtual processor (VP) configuration that is to be utilized by the second guest partition; creating, at the hypervisor, the second guest partition, based on the configuration specification, wherein the second guest partition executes directly on the hypervisor ([0017] In some implementations, a Level 1 VM can request a Level 0 hypervisor to create another VM on behalf of the Level 1 VM and allocate a portion of the computing resources (e.g., memory and/or vCPUs) (i.e. configuration) provided to the Level 1 VM to be used for the newly created VM. In these systems, the Level 1 VM can be referred to as a step-parent (SP) VM and the other VM created by the Level 0 hypervisor can be referred to as the step-child (SC) VM as it runs on a subset of the resources provided to the step-parent VM but is not fully nested within it (i.e., the SP VM may have incomplete access to resources allocated to the SC VM [0034] In some implementations, responsive to receiving a request from SP VM 120A to create an SC VM 120B, the hypervisor 112 can create an SC VM 120B. [Fig. 1] second hypervisor 120B executing on hypervisor 110); creating, at the hypervisor, a VP for the second guest partition based on the VP configuration ([0017] In some implementations, a Level 1 VM can request a Level 0 hypervisor to create another VM on behalf of the Level 1 VM and allocate a portion of the computing resources (e.g., memory and/or vCPUs) provided to the Level 1 VM to be used for the newly created VM. In these systems, the Level 1 VM can be referred to as a step-parent (SP) VM and the other VM created by the Level 0 hypervisor can be referred to as the step-child (SC) VM as it runs on a subset of the resources provided to the step-parent VM but is not fully nested within it (i.e., the SP VM may have incomplete access to resources allocated to the SC VM).)”.
However, Tsirkin_875 may not explicitly teach details of the virtual processors.
Tsirkin_344 teaches “scheduling, by the hypervisor, the VP for the second guest partition for execution on physical processor resources ([0012] An overcommitted processor may refer to a physical processor where two or more virtual processors are running concurrently.) according to a hypervisor-controlled scheduling policy that is independent of any scheduling decisions made within the first guest partition ([0035] At operation 211, the processing logic at time t1 may detect task t2 of vCPU1 of VM1 being executed on the CPU. In implementations, the CPU may be implementing a thread executing vCPU1 of VM1. The processing logic may then decide to hot-unplug vCPU1 to enable task t1 to be executed by CPU. Subsequently, the processing logic at operation 212 may add a hot-unplug of vCPU1 interrupt to an execution queue at time t2. The execution queue may store the hot-unplug interrupt for a certain period of time or until a certain condition is satisfied, before sending the interrupt to VM1 for execution. In implementations, the processing logic may decide to queue the interrupt instead of transmitting it to VM1 in order to avoid introducing latencies and performance penalties by unplugging a vCPU while the VM is in the middle of execution. In implementations, the processing logic may decide to transmit the hot-unplug interrupt to VM1 when one of the vCPUs of VM1 goes idle. [0038] At operation 218, the processing logic may cause vCPU1 to be hot-unplugged from VM1 at time T5, thus allowing task t1 to be executed by the CPU. In implementations, one of the vCPUs of the VM may execute the interrupt to hot-unplug vCPU1 from VM1. Hot unplugging a vCPU from the VM may refer to removing the vCPU from a set of vCPUs associated with the VM without causing the VM to shut down. [Claim 3] 3. The method of claim 2, wherein the task is a second thread implementing a second vCPU of a second VM. [0029] In certain implementations, processor overcommit management component 182 may be implemented as a software component invoked by hypervisor 180. Alternatively, functions of processor overcommit management component 182 may be performed by hypervisor 180 (i.e. independent of the first guest).)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings Tsirkin_344 with the teachings of Tsirkin_875 in order to provide a system that teaches details of allocating VCPU to a second guest. The motivation for applying Tsirkin_344 teaching with Tsirkin_875 teaching is to provide a system that allows for sharing of virtual resources. Tsirkin_875, Tsirkin_344 are analogous art directed towards virtual allocation. Together Tsirkin_875, Tsirkin_344 teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Tsirkin_344 with the teachings of Tsirkin_875 by known methods and gained expected results.
Claim 2, 12 the combination teaches the claim, wherein Tsirkin_875 teaches “the method of claim 1, wherein the configuration specification also includes at least one of: a feature of the VP, a hypervisor enlightenment to expose to the second guest partition, a hypervisor persona to expose to the second guest partition, or a virtualization permission for the second guest partition ([0017] In some implementations, a Level 1 VM can request a Level 0 hypervisor to create another VM on behalf of the Level 1 VM and allocate a portion of the computing resources (e.g., memory and/or vCPUs) (i.e. configuration) provided to the Level 1 VM to be used for the newly created VM. In these systems, the Level 1 VM can be referred to as a step-parent (SP) VM and the other VM created by the Level 0 hypervisor can be referred to as the step-child (SC) VM as it runs on a subset of the resources provided to the step-parent VM but is not fully nested within it (i.e., the SP VM may have incomplete access to resources allocated to the SC VM [0034] In some implementations, responsive to receiving a request from SP VM 120A to create an SC VM 120B, the hypervisor 112 can create an SC VM 120B.)”.
Claim 5, 15, 21 the combination teaches the claim, wherein Tsirkin_875 teaches “the method of claim 1, wherein the first guest partition provides a VP resource control used by a first scheduler at the hypervisor ([0017] In some implementations, a Level 1 VM can request a Level 0 hypervisor to create another VM on behalf of the Level 1 VM and allocate a portion of the computing resources (e.g., memory and/or vCPUs) (i.e. configuration) provided to the Level 1 VM to be used for the newly created VM. In these systems, the Level 1 VM can be referred to as a step-parent (SP) VM and the other VM created by the Level 0 hypervisor can be referred to as the step-child (SC) VM as it runs on a subset of the resources provided to the step-parent VM but is not fully nested within it (i.e., the SP VM may have incomplete access to resources allocated to the SC VM [0034] In some implementations, responsive to receiving a request from SP VM 120A to create an SC VM 120B, the hypervisor 112 can create an SC VM 120B.)”.
Rationale to claim 1 is applied here.
Claim/s 3, 6, 7, 9, 13, 16, 17, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tsirkin_875, Tsirkin_344 in further view of Tsirkin (Pub. No. US 2023/0185593).
Claim 3, 13 the combination may not explicitly teach the limitation.
Tsirkin teaches “the method of claim 1, wherein creating the second guest partition at the hypervisor based on the configuration specification comprises creating a second level address translation (SLAT) table for the second guest partition, the SLAT table mapping a system physical address (SPA) associated with the memory portion into a memory space of the second guest partition ([0036] Each of the guest memory 220A of the list of guest memory 220A provided to the translation table generation component 122 includes a guest physical address of the guest memory 220A and a guest physical address of the guest memory 230A corresponding to the guest physical address of the guest memory 220A. To generate a translation table 124, the translation table generation component 122 maps each guest physical address of the guest memory 230A (e.g., PA 0-4) associated with the physical device to a host virtual address associated with the physical device (e.g., HVA 0-4). [0037] To map each guest physical address of the guest memory 230A (e.g., PA 0-4) associated with the physical device to a host virtual address associated with the physical device (e.g., HVA 0-4), the translation table generation component 122 translates the guest physical address of the guest memory 230A to a guest physical address of the guest memory 220A. As previously described, the guest physical address of the guest memory 230A may be translated to the corresponding guest physical address of the guest memory 220A using a guest page table that is managed by a hypervisor of virtual machine 220 and exposed to Level 0 hypervisor 210.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings Tsirkin with the teachings of Tsirkin_875, Tsirkin_344 in order to provide a system that teaches details of allocating resources to a second guest. The motivation for applying Tsirkin teaching with Tsirkin_875, Tsirkin_344 teaching is to provide a system that allows for sharing of virtual resources. Tsirkin_875, Tsirkin_344, Tsirkin are analogous art directed towards virtual allocation. Together Tsirkin_875, Tsirkin_344, Tsirkin teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Tsirkin with the teachings of Tsirkin_875, Tsirkin_344 by known methods and gained expected results.
Claim 6, 16 the combination may not explicitly teach the limitation.
Tsirkin teaches “the method of claim 1, wherein: the memory portion is a first memory portion; and the configuration specification includes a second memory portion, which is allocated to the first guest partition, that is to be donated to the hypervisor for management of the second guest partition ([0034] Nested virtualization system 205 may run virtual machine 230 (e.g., Level 2 VM) in virtual machine 220 (e.g., Level 1 VM). Virtual machine 220 may request hypervisor 210 to create a nested virtual machine 230 of virtual machine 220. Hypervisor 210, responsive to the received request, creates nested virtual machine 230 within virtual machine 220 and provides, to the newly created nested virtual machine 230, guest memory 230A. Guest memory 230A refers to a portion of guest memory 220A that has been exposed to the nested virtual machine 230. In addition to the request to create the nested virtual machine 230, the virtual machine 220 may notify the hypervisor 210 that the nested virtual machine 230 will be using the physical address of the guest memory 230A as the virtual address of the physical device 240. Accordingly, virtual machine 220 provides the hypervisor 210 the guest memory 220A that was exposed to the nested virtual machine 230 as well an identification of the physical device 240 to be exposed to the nest virtual machine 230 (e.g., metadata associated with identity of the physical address to exposed).)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings Tsirkin with the teachings of Tsirkin_875, Tsirkin_344 in order to provide a system that teaches details of allocating resources to a second guest. The motivation for applying Tsirkin teaching with Tsirkin_875, Tsirkin_344 teaching is to provide a system that allows for sharing of virtual resources. Tsirkin_875, Tsirkin_344, Tsirkin are analogous art directed towards virtual allocation. Together Tsirkin_875, Tsirkin_344, Tsirkin teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Tsirkin with the teachings of Tsirkin_875, Tsirkin_344 by known methods and gained expected results.
Claim 7, 17 the combination may not explicitly teach the limitation.
Tsirkin teaches “the method of claim 1, wherein the configuration specification includes a direct assignment of a physical device to the second guest partition ([0035] Upon receiving notification that the nested virtual machine 230 will be using the physical address of the guest memory 230A as the virtual address of the physical device 240, the hypervisor 210 provides the translation table generation component 122 a list of guest memory 220A that was exposed to the nested virtual machine 230 and the identification of the physical device 240. ), the method further comprising: configuring an input/output memory management unit (IOMMU) to use a second level address translation (SLAT) table for the second guest partition in connection with direct memory access (DMA) by the physical device ([0039] Accordingly, the translation table generation component 122 stores in the translation table 124 the guest physical address of the guest memory 230A (e.g., PA 0-4) and the corresponding host virtual address (e.g., HVA 0-4). [0040] In response to a request to access the physical device 240, the hypervisor 210 receives the physical address of the guest memory 230A (e.g., PA 3) used as a virtual address for the physical device 240 from the virtual machine 220. The hypervisor 210 translates the physical address of the guest memory 230A (e.g., PA 3), via the translation table 124, to a host virtual address (e.g., HVA 3) to access to physical device 240.), rather than using a SLAT table for the first guest partition ([0025] Once the guest physical address of virtual machine 114D is obtained, the hypervisor 120A translates the guest physical address of virtual machine 114D to a host physical address. The mappings of guest physical addresses to corresponding host physical addresses may be stored in a memory data structure, such as an extended page table (EPT).)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings Tsirkin with the teachings of Tsirkin_875, Tsirkin_344 in order to provide a system that teaches details of allocating resources to a second guest. The motivation for applying Tsirkin teaching with Tsirkin_875, Tsirkin_344 teaching is to provide a system that allows for sharing of virtual resources. Tsirkin_875, Tsirkin_344, Tsirkin are analogous art directed towards virtual allocation. Together Tsirkin_875, Tsirkin_344, Tsirkin teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Tsirkin with the teachings of Tsirkin_875, Tsirkin_344 by known methods and gained expected results.
Claim/s 9, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tsirkin_875, Tsirkin_344 in further view of Evans (Pub. No. US 2023/0259464).
Claims 9, 18 the combination may not explicitly teach the limitations of the claim.
Evans teaches “the method of claim 1, wherein a root partition uses second level address translation (SLAT) to configure the first guest partition to be outside of a trusted computing base (TCB) of the second guest partition ([0049] In embodiments where the hosted software 106 includes a VM, the memory manager 114 may allocate permissions for a device, function, process, etc., based at least on the entity (e.g., an endpoint) being moved into the TEE of the VM. For example, in response to a request to move the entity into the TEE, the memory manager 114 may generate and/or assign one or more permissions to the entity (e.g., one permission per entity, process, and/or function). As a further example, a permission may be generated or assigned in response to an address translation request from the entity. In at least one embodiment, the memory manager 114 may store permissions in the PAAPT(s) 118 by entity, function, process, and/or session. [0047] The memory manager 114 and/or other components of the memory access system 100 may use the transaction mapping table(s) 124 for address translation. For example, the transaction mapping table 124 may be used to map a transaction to a transaction stream and its corresponding translation context. In at least one embodiment, a permission granting access to an entity or endpoint may be terminated in association with invalidation of the entity or endpoint's translation cache (e.g., upon determining a pre-determined period of time having elapsed, upon determining an entity of the hosted software 106 has revoked access to and/or modified a translated address, upon determining a translated address no longer belongs to the entity, based on terminating the entity owning the translated address, etc.).)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings Evans with the teachings of Tsirkin_875, Tsirkin_344 in order to provide a system that teaches details of allocating resources to a second guest. The motivation for applying Evans teaching with Tsirkin_875, Tsirkin_344 teaching is to provide a system that allows for sharing of virtual resources. Tsirkin_875, Tsirkin_344, Evans are analogous art directed towards virtual allocation. Together Tsirkin_875, Tsirkin_344, Evans teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Evans with the teachings of Tsirkin_875, Tsirkin_344 by known methods and gained expected results.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WYNUEL S AQUINO whose telephone number is (571)272-7478. The examiner can normally be reached 9AM-5PM EST M-F.
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 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.
/WYNUEL S AQUINO/Primary Examiner, Art Unit 2199