CTNF 18/627,218 CTNF 86100 DETAILED ACTION 12-151 AIA 26-51 12-51 Status of Claims This action is in reply to the application filed on 04/04/2024. Claims 1-20 are currently pending and have been examined. Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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 § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 1, 4, 6-8, 10-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over McClure et al. (US 9,864,609 B1) in view of Ngoc et al. (“HyperTP: A unified approach for live hypervisor replacement in datacenters”, 2023) . Claims 1 and 18: McClure discloses the limitations as shown in the following rejections: A method, implemented in a virtual machine (VM) host computer system that includes a processor system, comprising: determining that an update is available for a host compute layer (HCL) (hypervisor container) of a guest VM operating at the VM host computer system; sending a message to the HCL of the guest VM (see at least col. 4, li. 1-16) “subsystem receives a communication 130 (FIG. 2) including a request to reboot the hypervisor/container without disrupting the guest operating system as shown in step 302. The communication may be sent from a remote management station 132 (FIG. 2) via the network… upgraded code, which may be included in the communication, may be copied over the existing code” wherein, based on the message, the HCL persists (maintains) an operating state of the [guest OS] including, pausing an execution of a guest operating system (OS) within the guest VM, and persisting the operating state after pausing the execution of the guest OS; (col. 4, li. 8-24), disclosing at least “In response to the request each container stops giving CPU cycles (access to the processing resources) to the associated guest operating system as indicated in step 134 in order to suspend operation of the associated guest operating system…state information associated with the guest operating system is maintained in place.” after sending the message to the HCL of the guest VM, stopping a virtual processor (VP) system (Guest OS threads) associated with the guest VM; setting a register (instruction pointer) at the VP system to a power-on value or a reset value 1 (boot code/newly loaded container code) , copying an updated HCL into a memory space of the HCL within the guest VM, and resuming the VP system, wherein, based on the register, the VP system executes the updated HCL, which…resumes the execution of the guest OS [using the preserved guest OS] operating state (col. 4, li. 20-32 and 49-63; FIG. 4) “. Suspending the guest operating system in preparation for the update includes quiescing all threads and disabling interrupts…associated with various different guest operating systems”. McClure discloses maintaining operating state of the guest OS but does not specifically disclose persisting the operating state of the hypervisor container ( HCL ) itself and/or restores the operating state of the hypervisor/ HCL. Ngoc, however, discloses an analogous method of performing an in place hypervisor upgrade/”transplant” to “quickly replace one running hypervisor H current with another H target without rebooting running VMs” (pg. 1, § 1), which fully accounts for the different types of VM state data (pg. 2-3, § 2.1) including “Guest state”, analogous to the states maintained by McClure, and “VM i State” ( operating state of the HCL ) which “corresponds to data structures that are specific to the execution of one VM, but are not necessarily visible to the VM in their raw form. An example of VM i State is 2D page tables (2DPT) or vCPU register states.” Ngoc further discloses (pg. 3, § 2.2) the in-place hypervisor transplant/update includes ([ text ] inserted to show mapping to claim limitations): “After pausing any running guest VMs to be transplanted ❷, we invoke the corresponding UISR translation functions to convert the corresponding Guest/ VM i State to the UISR format ❸ [ persisting the operating state after pausing the execution of the guest OS ]. We perform a micro-reboot to hand over control of the hardware to H target ❹, while passing to it any relevant UISR Guest/VM i States. H target [ updated HCL ] then converts the received Guest/VM i States into its own native format ❺, and uses these states to reconstruct the VMs ❻[ the VP system executes the updated HCL, which, restores the operating state ]. Finally, the VMs to be transplanted are resumed [ resumes the execution of the guest OS after restoring the operating state ]” It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify McClure’s non-disruptive hypervisor-container update to employ the VM i State handling of Ngoc’s in-place hypervisor transplant “to quickly replace one running hypervisor H current with another H target without rebooting running VMs for the purpose of speeding up preventative maintenance of virtualization infrastructure. Note that H target can be anywhere from an updated version of H current to a completely different hypervisor, allowing more flexibility in choosing an appropriate hypervisor for the required workload” (pg. 1, § 1). Claim 4: The combination of McClure/Ngoc discloses the limitations as shown in the rejections above. Ngoc further discloses wherein the operating state includes at least one of, a register value at the VP system (vCPU registers) that was written by the guest OS before the guest OS was paused, a first state of a virtual hardware device (emulated device) operated by the HCL, or a second state of a physical hardware device (passthrough device) assigned to the guest VM (see at least pg. 3, col. 1, 1 st bullet; pg. 5 § 3.1). Claims 6 and 7: The combination of McClure/Ngoc discloses the limitations as shown in the rejections above. Ngoc further discloses wherein persisting the operating state includes…saving the operating state to a memory block (memory pages storing UISR data including PRAM structure) within the memory space of the HCL … wherein restoring the operating state includes…loading the operating state from the memory block within the memory space of the HCL (see at least pg. 3, § 2.2; pg. 4, Fig. 1; pg. 6, § 3.2). Claim 8: The combination of McClure/Ngoc discloses the limitations as shown in the rejections above. Ngoc further discloses wherein, saving the operating state to the memory block within the memory space of the HCL includes sending an identity of a location (e.g. PRAM pointer) of the memory block within the memory space of the HCL to the host partition, and loading the operating state from the memory block within the memory space of the HCL includes receiving the identity of the location of the memory block within the memory space of the HCL from the host partition (see at least pg. 3, § 2.2; pg. 4, Fig. 1; pg. 6, § 3.2) disclosing pointer(s) to the memory page(s) storing VM State data ( the identity of the location of the memory block within the memory space of the HCL ) are provided as input to the microreboot procedure that loads the updated hypervisor to allow the VM to be reconstructed. “PRAM structure, which consists of metadata pages that record the physical location of a VM’s memory pages, allowing each VM’s memory to be reconstructed after the new hypervisor boots up…To protect the in-memory VM state information from being corrupted during transplantation, we…passed the PRAM pointer to the new host kernel during Kexec via its kernel command line. Knowing the PRAM structure’s location, we modified the target kernel (Xen and Linux) to protect the PRAM pages and VM memory contents from being accidentally overwritten. This protection is applied during each kernel’s early boot process. After the new kernel boots up, each VM’s memory is presented again in a virtual filesystem where it can be picked up and reinjected back to its corresponding VM” (pg. 6, § 3.2). Claim 10: Regarding the limitations of claim 10, claim 10 recites a broader version of the method of claim 1 and stands rejected in view of the combination of McClure/Ngoc under the same rationale described above for claim 1. Claim 11: Claim 11 stands rejected in view of the combination of McClure/Ngoc under the same rationale described above for claim 4. Claims 12-14: Claims 12-14 stand rejected in view of the combination of McClure/Ngoc under the same rationale described above for claims 6-8, respectively. Claim 16: The combination of McClure/Ngoc discloses the limitations as shown in the rejections above. Ngoc further discloses wherein booting the HCL includes excluding a memory block from use by HCL services in at least pg. 6, § 3.2 disclosing “To protect the in-memory VM state information from being corrupted during transplantation, we…reserved a dedicated memory location in which to load the new kernel to avoid Kexec itself from overwriting the relevant PRAM pages.” Claim 17: The combination of McClure/Ngoc discloses the limitations as shown in the rejections above. Ngoc further discloses allocating physical device queue within the memory block in at least pg. 5, § 3.1, para. 4-7 disclosing the retained VM state data includes the state of I/O devices ( physical device queue ). Examiner refers to “Introduction to VirtIO” for a detailed description of one of the example device interface examples cited by Ngoc (pg. 5, § 3., para. 5). Claim 18: McClure discloses the limitations as shown in the following rejections: A computer system, comprising: a processor system; and computer storage media that store computer-executable instructions that are executable by the processor (FIG. 2; col. 3, li. 16-50). at a host partition: determine that an update is available for a host compute layer (HCL) (hypervisor container) of a guest virtual machine (VM); send a message to the HCL (see at least col. 4, li. 1-16), “subsystem receives a communication 130 (FIG. 2) including a request to reboot the hypervisor/container without disrupting the guest operating system as shown in step 302. The communication may be sent from a remote management station 132 (FIG. 2) via the network… upgraded code, which may be included in the communication, may be copied over the existing code”. after sending the message to the HCL, stop a virtual processor (VP) system (Guest OS threads) associated with the guest VM, set a register (instruction pointer) at the VP system to a power-on value or a reset value 2 (boot code/newly loaded container code) , copy an updated HCL into a memory space of the HCL within the guest VM, and resume the VP system… and based on the host partition resuming the VP system, and based on the register at the VP system, boot the updated HCL, including…resuming the execution of the guest OS after restoring the operating state (col. 4, li. 20-32 and 49-63; FIG. 4) “. Suspending the guest operating system in preparation for the update includes quiescing all threads and disabling interrupts…associated with various different guest operating systems”. at the guest VM: based on receiving the message from the host partition, pause an execution of a guest operating system (OS) within the guest VM, and persist operating state after pausing the execution of the guest OS; (col. 4, li. 8-24), disclosing at least “In response to the request each container stops giving CPU cycles (access to the processing resources) to the associated guest operating system as indicated in step 134 in order to suspend operation of the associated guest operating system…state information associated with the guest operating system is maintained in place.”. McClure discloses maintaining operating state of the guest OS but does not specifically disclose persisting the operating state of the hypervisor container ( HCL ) itself and/or restores the operating state of the hypervisor/ HCL. Ngoc, however, discloses an analogous method of performing an in place hypervisor upgrade/”transplant” to “quickly replace one running hypervisor H current with another H target without rebooting running VMs” (pg. 1, § 1), which fully accounts for the different types of VM state data (pg. 2-3, § 2.1) including “Guest state”, analogous to the states maintained by McClure, and “VM i State” ( operating state of the HCL ) which “corresponds to data structures that are specific to the execution of one VM, but are not necessarily visible to the VM in their raw form. An example of VM i State is 2D page tables (2DPT) or vCPU register states.” Ngoc further discloses (pg. 3, § 2.2) the in-place hypervisor transplant/update includes ([ text ] inserted to show mapping to claim limitations): “After pausing any running guest VMs to be transplanted ❷, we invoke the corresponding UISR translation functions to convert the corresponding Guest/ VM i State to the UISR format ❸ [ persisting the operating state after pausing the execution of the guest OS ]. We perform a micro-reboot to hand over control of the hardware to H target ❹, while passing to it any relevant UISR Guest/VM i States. H target [ updated HCL ] then converts the received Guest/VM i States into its own native format ❺, and uses these states to reconstruct the VMs ❻[ the VP system executes the updated HCL, which, restores the operating state ]. Finally, the VMs to be transplanted are resumed [ resumes the execution of the guest OS after restoring the operating state ]” It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify McClure’s non-disruptive hypervisor-container update to employ the VM i State handling of Ngoc’s in-place hypervisor transplant “to quickly replace one running hypervisor H current with another H target without rebooting running VMs for the purpose of speeding up preventative maintenance of virtualization infrastructure. Note that H target can be anywhere from an updated version of H current to a completely different hypervisor, allowing more flexibility in choosing an appropriate hypervisor for the required workload” (pg. 1, § 1). Claim 19: The combination of McClure/Ngoc discloses the limitations as shown in the rejections above. Ngoc further discloses wherein the operating state includes at least one of, a register value at the VP system (vCPU registers) that was written by the guest OS before the guest OS was paused, a first state of a virtual hardware device (emulated device) operated by the HCL, or a second state of a physical hardware device (passthrough device) assigned to the guest VM (see at least pg. 3, col. 1, 1 st bullet; pg. 5 § 3.1). Claim 20: The combination of McClure/Ngoc discloses the limitations as shown in the rejections above. Ngoc further discloses wherein, persisting the operating state includes at least one of, sending the operating state to the host partition, or saving the operating state to a memory block within the memory space of the HCL, and restoring the operating state includes at least one of, receiving the operating state from the host partition, or loading the operating state from the memory block within the memory space of the HCL (see at least pg. 3, § 2.2; pg. 4, Fig. 1; pg. 6, § 3.2) 07-21-aia AIA Claim s 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over McClure in view of Ngoc in further view of Fries et al. (US 2009/0007105 A1) . Claims 2 and 3: The combination of McClure/Ngoc discloses the limitations as shown in the rejections above. The combination of McClure/Ngoc does not specifically disclose before sending the message to the HCL, determining that the guest VM is in a state that permits updating the HCL. Fries, however, discloses (¶0068-0070) an analogous method for VM updating comprising determining that the guest VM is in a state that permits updating including determining whether it is active/ running and deferring sending the command to initiate the update when it is determined to not be running. From ¶0068: “an update may require a VM to be active in order for the update to be applied…If updates requiring the VM to be active are indicated, the VM image may be flagged for subsequent update…update may be deferred until the VM is selected to be deployed and activated”. It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify McClure/Ngoc to confirm the VM is in a state that permits updating prior to initiating the update as taught by Fries (¶0068-0070) to ensure the update is carried out successfully . 07-21-aia AIA Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over McClure in view of Ngoc in further view of Dannowski (US 9,940,148 B1) . Claim 5: The combination of McClure/Ngoc discloses the limitations as shown in the rejections above. The combination of McClure/Ngoc does not specifically disclose before sending the message to the HCL, validating at least one of, that the updated HCL is compatible with the HCL, or that the updated HCL is valid . Dannowski, however, discloses an analogous method for performing an in-place hypervisor update which includes, prior to initiating the update validating at least one of, that the updated HCL is compatible with the HCL, or that the updated HCL is valid as disclosed in at least col. 4, li. 57 – col. 5, li. 53: “in preparation for the updating operation…the hypervisor image data 112 may need to be verified for valid data, for valid security credentials, for valid origin, and/or other such verification requirements.” It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify McClure/Ngoc to validate the update as taught by Dannowski to ensure that the update is authentic and secure (Dannowski col. 3, li. 1-10; col. 5, li. 1-57) . 07-21-aia AIA Claim s 9 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over McClure in view of Ngoc in further view of IntelTDX (“Intel® Trust Domain Extensions (Intel® TDX) Module Base Architecture Specification”, 2023) Claims 9 and 15: The combination of McClure/Ngoc discloses the limitations as shown in the rejections above. The combination of McClure/Ngoc does not specifically disclose the memory block is determined by the HCL based on convention, saving the operating state to the memory block within the memory space of the HCL includes writing a value indicating that the operating state is stored at the memory block, and loading the operating state from the memory block within the memory space of the HCL includes identifying the value indicating that the operating state is stored at the memory block . IntelTDX, however, discloses an analogous method of performing a state-preserving update of a “Trust Domain” (TD) VM ( HCL ) which includes (pg. 29, § 3.1.2.2; pg. 48, § 4.2.6; and pg. 49) saving the operating state (handoff data) to a memory block (handoff data range/region) is determined by the HCL based on convention (ISA) , saving the operating state to the memory block within the memory space of the HCL includes writing a value (marked as valid with Handoff Version (HV)) indicating that the operating state is stored at the memory block, and loading the operating state from the memory block within the memory space of the HCL includes identifying the value (recognized HV) indicating that the operating state is stored at the memory block . “prepares handoff data in a designated area in SEAM range called handoff data range. The handoff data contains any TDX module state (in SEAM range) required to preserve old TDs across TDX module updates…In preparation to TD-preserving TDX module update…the TDH.SYS.SHUTDOWN prepares handoff data with the requested syntax and semantics in the handoff data region; it marks the handoff data region as valid with the requested HV…the host VMM initializes the new TDX module, and calls its 35 TDH.SYS.UPDATE function which consumes the handoff data and marks it as invalid” (pg. 49). It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify McClure/Ngoc to employ the Trust Domain Extensions taught by IntelTDX to protect the confidentiality and integrity of the VM’s memory contents and its CPU state (IntelTDX pg. 18) . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure : “Introduction to VirtIO” provides a detailed description of the VirtIO device abstraction layer. The following references are directed to live/in-place hypervisor updating: US 20210089345 A1; US 20180203715 A1, “Hy-FiX: Fast In-Place Upgrades of KVM Hypervisors”, “Fast and Scalable VMM Live Upgrade in Large Cloud Infrastructure”. US 20170090897 A1 is directed to in service upgrade of kernel loadable modules. “Mitigating vulnerability windows with hypervisor Transplant” is related to reference Ngoc. Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482 . The Examiner can normally be reached on Monday- Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014 . Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /P. M./ Paul Mills 06/09/2026 /APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196 Application/Control Number: 18/627,218 Page 2 Art Unit: 2196 Application/Control Number: 18/627,218 Page 3 Art Unit: 2196 Application/Control Number: 18/627,218 Page 4 Art Unit: 2196 Application/Control Number: 18/627,218 Page 5 Art Unit: 2196 Application/Control Number: 18/627,218 Page 6 Art Unit: 2196 Application/Control Number: 18/627,218 Page 7 Art Unit: 2196 Application/Control Number: 18/627,218 Page 8 Art Unit: 2196 Application/Control Number: 18/627,218 Page 9 Art Unit: 2196 Application/Control Number: 18/627,218 Page 10 Art Unit: 2196 Application/Control Number: 18/627,218 Page 11 Art Unit: 2196 Application/Control Number: 18/627,218 Page 12 Art Unit: 2196 Application/Control Number: 18/627,218 Page 13 Art Unit: 2196 1 Limitation interpreted in view of AppSpec (¶0039, 0059) “copies updated HCL 124 into the memory space of context 113 (e.g., replacing prior HCL code), configures VP 120 to be in a power-on value or reset state (e.g., by setting a value of an instruction pointer register to a memory address at the beginning of HCL boot code) 2 Limitation interpreted in view of AppSpec (¶0039, 0059) “copies updated HCL 124 into the memory space of context 113 (e.g., replacing prior HCL code), configures VP 120 to be in a power-on value or reset state (e.g., by setting a value of an instruction pointer register to a memory address at the beginning of HCL boot code)
Prosecution Insights