DETAILED ACTION
This Office Actions is in response to communication (Amendment) filed on 11/06/2025
Claims 1 – 20 are pending. Claims 1, 14, and 20 are in independent form. Claims 1, 2, 4 – 7, and 14 – 20 were amended. This action is Final.
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 .
Response to Amendment
This Office Action is in response to the applicant’s remarks and arguments filed on 11/06/2025.
Claims 1, 2, 4 – 7, and 14 – 20 were amended. Claims 1 – 20 remain pending in the application. Claims 1 – 20 are being considered on the merits.
The Objection of claim 14 has been withdrawn due to the amendment to the claims filed on 11/06/2025
The Rejection of claims 20 under 35 U.S.C § 101 has been withdrawn due to the amendment to the claims filed on 11/06/2025.
The Rejection of claims 14 – 19 under 35 U.S.C § 112(b) has been withdrawn due to the amendment to the claims filed on 11/06/2025.
The Rejection of claims 1 – 20 under 35 U.S.C § 103 has been withdrawn due to the amendment to the claims filed on 11/06/2025. However, upon further consideration, a new ground(s) of rejection is made in view of a newly found prior art Mooring US Pub. No. US 20220137996 A1 and in view of the previously cited prior art(s). Reference Mooring, in combination with previously cited prior art(s), discloses each element of the claims highlighted by applicant.
Response to Arguments
The applicant’s remarks and/or arguments, filed on 11/06/2025 have been fully considered with the following result(s).
The examiner is entitled to give claim limitations their broadest reasonable interpretation in light of the specification. See MPEP 2111 [R-1] Interpretation of Claims-Broadest Reasonable Interpretation. The applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Prater, 162 USPQ 541,550-51 (CCPA 1969).
Response to Claims Objection Remarks
Applicant’s argument filed on 11/06/2025 regarding the Claims Objection has been fully considered and they are persuasive. The previous Claims Objection has been withdrawn.
Response to 35 U.S.C § 101 Rejection Remarks
Applicant’s argument filed on 11/06/2025 regarding the 35 U.S.C § 101 Rejection has been fully considered and they are persuasive. The 35 U.S.C § 101 Rejection has been withdrawn
Response to 35 U.S.C § 112(b) Rejection Remarks
Applicant’s argument filed on 11/06/2025 regarding the 35 U.S.C § 112(b) Rejection has been fully considered and they are persuasive. The 35 U.S.C § 112(b) Rejection has been withdrawn.
Response to 35 U.S.C § 103 Rejection Remarks
Applicant's arguments in the applicant’s remarks and amendments of independent claims 1, 14 and 20, found on pages 7 – 9 and filed on 11/06/2025, have been fully considered and are persuasive. Therefore, the previous claim(s) rejection under 35 U.S.C § 103 has been withdrawn.
However, upon further consideration, a new ground(s) of rejection is made in view of a newly found prior art Mooring US Pub. No. US 20220137996 A1 and in view of the previously cited prior art(s). Reference Mooring, in combination with previously cited prior art(s), discloses each element of the claims highlighted by applicant.
For further details, please see below claims rejections under 35 U.S.C § 103.
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.
Claims 1, 12, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mooring US Pub. No. US 20220137996 A1, Chakraborty et al. US Pub. No. US 20190196858 A1 (hereafter Chakraborty), in further view of Stupachenko et al. US Pat. No. US 11875159 B1 (hereafter Stupachenko)
Regarding claim 1, Mooring teaches the invention substantially as claimed: A method, implemented at a computer system that includes a processor, for providing a virtual machine (VM) management capability via guest firmware, (e.g. FIG. 2A and [0041]: “FIG. 2A is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein. FIG. 2A also shows a separation kernel hypervisor 100 executing on native hardware platform resources (where the native platform resources may include a plurality of CPUs, buses and interconnects, main memory, Network Interface Cards (NIC), Hard Disk Drives (HDD), Solid State Drives (SSD), Graphics Adaptors, Audio Devices, Mouse/Keyboard/Pointing Devices, Serial I/O, USB, and/or Raid Controllers, etc.), where the separation kernel hypervisor may support the execution, isolated and/or partitioning in time and space, between a plurality of guest operating system protection domains.” and [0042]: “Further, the virtualization assistance layer 400 may assist the separation kernel hypervisor in virtualizing portions of the platform resources exported to a given guest operating system (e.g., Virtual CPU/ABI, Virtual chipset ABI, set of virtual devices, set of physical devices, and/or firmware, etc., assigned to a given guest operating system 300 and/or guest virtual machine protection domain 200).) The citation discloses the system comprise CPUs/processor that can perform various functions and features, including managing multiples VMs. At [0042] discloses the firmware within the VM.
the method comprising: creating, using a hypervisor, (i) a first guest privilege context of a guest partition that operates as the VM, and (ii) a second guest privilege context of the guest partition, (e.g. FIG. 2A and [0037]: “Here, a guest operating system domain may be an entity that is established and maintained by the separation kernel hypervisor in order to provide a secure and isolated execution environment for software. Referring to FIG. 1, a separation kernel hypervisor 100 is shown executing on top of the native hardware platform resources 600. Further, the separation kernel hypervisor 100 supports the execution of a guest operating system virtual machine protection domain 200.” and [0042]: “FIG. 2A shows both a guest operating system 300, and a virtualization assistance layer 400 executing within the same guest operating system virtual machine protection domain 200.” and [0044]: “The guest operating system 300 and the virtualization assistance layer 400 (which may include VAL mechanism(s) 500) are isolated from each other by the separation kernel hypervisor 100.”) The citation discloses at [0042] the guest operating system virtual machine, which is the guess partition, comprise the VAL mechanisms 500 and/or virtualization assistance layer 400, which is the first guest privilege context, and the guest OS 300, which is the second guest privilege context, within the guest operating system virtual machine. At [0037] and [0044] discloses the Hypervisor 100 provide a secure and isolated execution environment for software.
wherein: the first guest privilege context has higher privilege within the guest partition than the second guest privilege context; (e.g. FIG. 2A and [0044]: “The guest operating system 300 and the virtualization assistance layer 400 (which may include VAL mechanism(s) 500) are isolated from each other by the separation kernel hypervisor 100........ For example, the VAL mechanisms 500, within the given virtualization assistance layer 400, may read and/or modify portions of the guest operating system 300 and resources to which the Guest Operating System 300 has been granted access (by the Separation Kernel Hypervisor 100), while none of the Guest Operating System 300 nor the resources to which has access may modify any portion of the VAL mechanisms 500 and/or virtualization assistance layer 400.”) The citation discloses the VAL mechanisms 500 and/or virtualization assistance layer 400, which is the first guest privilege context, can access/modify the portion of the guest OS 300, which is the second guest privilege context, while the guest OS 300 cannot access/modify the portion of the VAL mechanisms 500 and/or virtualization assistance layer 400. Therefore, it would imply that the VAL mechanisms 500 and/or virtualization assistance layer 400 has a higher privilege, within the guest operating system virtual machine/within the guess partition.
the second guest privilege context is restricted by the hypervisor from accessing memory within the guest partition that is associated with the first guest privilege context (e.g. FIG. 2A and [0035]: “The separation kernel hypervisor may host a plurality of guest operating system virtual machine protection domains and may host a plurality of VAL mechanisms such as virtual hardware presentation mechanisms which may execute within such guest operating system virtual machine protection domains. These VAL mechanisms may execute in an environment where guest operating systems cannot tamper with, bypass, or corrupt the mechanisms” and [0044]: “The guest operating system 300 and the virtualization assistance layer 400 (which may include VAL mechanism(s) 500) are isolated from each other by the separation kernel hypervisor 100........ For example, the VAL mechanisms 500, within the given virtualization assistance layer 400, may read and/or modify portions of the guest operating system 300 and resources to which the Guest Operating System 300 has been granted access (by the Separation Kernel Hypervisor 100), while none of the Guest Operating System 300 nor the resources to which has access may modify any portion of the VAL mechanisms 500 and/or virtualization assistance layer 400.”) The citation discloses the guest OS 300 and virtualization assistance layer 400 are isolated from each other by the hypervisor, and the guest OS 300 cannot access/modify the portion of the VAL mechanisms 500 and/or virtualization assistance layer 400. Therefore, it would imply that any resources (including memory) assigned to the virtualization assistance layer 400 are restricted from the OS 300.
and the second guest privilege context is configured to operate a guest operating system (OS); FIG. 2A and [0042]: “FIG. 2A shows both a guest operating system 300, and a virtualization assistance layer 400 executing within the same guest operating system virtual machine protection domain 200.”) The citation discloses the guest OS 300, which is the second guest privilege context, within the VM domain 200.
operating the guest firmware exclusively within the first guest privilege context of the guest partition; (e.g. FIG. 2A and [0042]: “Further, the virtualization assistance layer 400 may assist the separation kernel hypervisor in virtualizing portions of the platform resources exported to a given guest operating system (e.g., Virtual CPU/ABI, Virtual chipset ABI, set of virtual devices, set of physical devices, and/or firmware, etc., assigned to a given guest operating system 300 and/or guest virtual machine protection domain 200).” and [0044]: “The guest operating system 300 and the virtualization assistance layer 400 (which may include VAL mechanism(s) 500) are isolated from each other by the separation kernel hypervisor 100) The citation discloses the guest OS 300 and virtualization assistance layer 400 are isolated from each other by the hypervisor, so it would imply that any software (including firmware), within the virtualization assistance layer 400, are isolated/ exclusively, within that region.
Mooring fails to teach and at the guest firmware, establishing a communications channel between the first guest privilege context and a client device; receiving, over the communications channel, a request for performance of a management operation against the VM; and based on the request, initiating the management operation.
However, Chakraborty teaches and at the guest firmware, establishing a communications channel between the first guest privilege context and a client device; (e.g. [0005]: “As such, in a remote computing system, a client can connect to a virtual machine or a virtual desktop session running therein, where an authentication of the client is managed. Data such as user input data or graphics data to be transmitted from the client to the virtual machine is initially transmitted to a network interface card (NIC) on the host partition and then re-routed to the virtual machine.” and FIG. 2, FIG. 3, and [0045]: “In another embodiment, a remote client computer 310 can be connected to one of the virtual desktops using the broker 340 and a pool manager (not shown). The pool manager may be disposed within the broker 340. The broker 340 assigns the virtual desktops to the remote client computer 310 when the remote client computer 310 is connected to a virtual desktop hosted on a virtual machine (VM), and the pool manager indicates which of the virtual desktops are available to be assigned.” and [0047] FIG. 4 illustrates an example virtual machine environment, with a plurality of virtual machines. A virtualized computer system 400 can be used to implement the remote server computer 220 of FIG. 2 and the remote server computers 320(A-N) of FIG. 3.) The citations disclose the remote client computer establish the connection to the virtual machine/guest firmware. By combining with the teaching of Mooring about the structure of the VM, one of ordinary skills in the art would be able to come up with the claim invention.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the and at the guest firmware, establishing a communications channel between the first guest privilege context and a client device, as taught in Chakraborty’s invention into Mooring’s invention because the additional features would improves VM management, enable faster and more reliable control while maintain the strong isolation between the components, as the commands or information can be exchanged directly and securely.
However, Stupachenko teaches receiving, over the communications channel, a request for performance of a management operation against the VM; (81 – Col 19, lines 4 – 13: “The GUI Application 274 provides a GUI through which a user creates a VM, manages its state (start/stop/pause/resume/shutdown, etc.), and operates with the Guest OS 280 virtual display that shows the user interface of the Guest OS 280. A GUI Application 274 may run as a regular Host OS 272 process with the privileges of the current user and establishes a connection to the Dispatch Service 273 using the Unix domain socket, through which it sends commands and receives events that enable managing within, to and from a VM.” and 83 - Col 19, lines 42 – 46: “Client System 270 may also support similar software and functionality as Client Device 220 and/or Mobile Device 210 allowing it support both VMs directly established upon itself or VMs indirectly established upon Remote Access System 230.”) The citation discloses at Col 19, lines 4 – 13 the request to create and manage a VM. at Col 19, lines 42 – 46 discloses the client system can be access via the remote access system.
and based on the request, initiating the management operation (e.g. Col 17, lines 55 – 62: “managing the lifecycle of the executed VM and its states (e.g., start/stop/pause/restart/shutdown VM, create a snapshot, revert to snapshot, etc.), emulating VM devices (e.g. CPU, timer, interrupt controller, network, disk, sound, etc.), and processing requests for execution of operations on virtual devices signaled by the VM through the Hypervisor 273 and mapping results back to the VM via the Hypervisor 273.”) the citation discloses the managing of a VM, including start/stop a VM.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the receiving, over the communications channel, a request for performance of a management operation against the VM; and based on the request, initiating the management operation, as taught in Stupachenko’s invention into Chakraborty’s invention because the additional features would improves performance and control of the management of the VMs, as the firmware can act on the request directly, reduce delay while still maintaining strong isolation between the components.
Regarding claim 12, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, and Mooring further teaches wherein the guest OS is unaware of the first guest privilege context. (e.g. FIG. 2A and [0044]: “The guest operating system 300 and the virtualization assistance layer 400 (which may include VAL mechanism(s) 500) are isolated from each other by the separation kernel hypervisor 100........ For example, the VAL mechanisms 500, within the given virtualization assistance layer 400, may read and/or modify portions of the guest operating system 300 and resources to which the Guest Operating System 300 has been granted access (by the Separation Kernel Hypervisor 100), while none of the Guest Operating System 300 nor the resources to which has access may modify any portion of the VAL mechanisms 500 and/or virtualization assistance layer 400.”) The citation discloses the guest OS 300 and virtualization assistance layer 400 are isolated from each other by the hypervisor, and the guest OS 300 cannot access/modify the portion of the VAL mechanisms 500 and/or virtualization assistance layer 400. Therefore, it would imply that the OS 300 is unaware of the virtualization assistance layer 400.
Regarding claim 13, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, and Mooring further teaches wherein a memory region associated with the guest partition is inaccessible to a host OS. (e.g. [0038]: “The separation kernel hypervisor 100 may also support the execution of a plurality of guest operating system virtual machine protection domains, e.g., 200 to 299 in FIG. 1. In some implementations, the separation kernel hypervisor may provide time and space partitioning in a secure and isolated manner for a plurality of guest operating system virtual machine protection domains, e.g., 200 to 299 in FIG. 1” and [0039]) The citation discloses the VMs are operates within the secure and isolated manner.
Further, Chakraborty also teaches at (e.g. FIG. 4 and [0048]: “Here, a guest partition is the basic unit of isolation supported by hypervisor microkernel 402. A guest partition may also be known as a child partition. Hypervisor microkernel 402 can isolate processes in one partition from accessing another partition's resources. Each guest partition can be mapped to a set of hardware resources, e.g., memory, devices, processor cycles, etc., that is under control of the hypervisor microkernel 402.”) The citation discloses the guest partition is an isolation unit, so it operates on its own, without accessing or being accessed by other partitions.
Further, Stupachenko also teaches at (74 – Col 17, lines 63 – 67: “A VM Application 276 may be started by the Host OS 272 and run as a regular process such that it falls under all the regular process restrictions like virtual memory space isolation, file permissions etc., as with any other system process.”) The citation discloses the VM runs at regular process restrictions like virtual memory space isolation, and since the VM’s memory is isolation, no other component can access that memory.
Regarding claim 20, the claim is a computer program product claim that has similar limitation of the claims 1, 12, and 13. Thus, the claim is rejected under the same rational.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty, and Stupachenko, in further view of Wang et al. US Pub. No. US 20100218183 A1 (hereafter Wang)
Regarding claim 2, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, and Stupachenko further teaches wherein initiating the management operation includes changing the power state of the VM, (e.g. Col 17, lines 55 - 62: "managing the lifecycle of the executed VM and its states (e.g., start/stop/pause/restart/shutdown VM, create a snapshot, revert to snapshot, etc.), emulating VM devices (e.g. CPU, timer, interrupt controller, network, disk, sound, etc.), and processing requests for execution of operations on virtual devices signaled by the VM through the Hypervisor 273 and mapping results back to the VM via the Hypervisor 273.") the citation discloses the managing of a VM, including start/stop a VM.
Mooring, in view of Chakraborty and Stupachenko, fails to teach including at least one of starting a virtual processor associated with the guest partition or stopping the virtual processor.
However, Wang teaches including at least one of starting a virtual processor associated with the guest partition or stopping the virtual processor. (e.g. [0064] In embodiments of the invention, a virtual processor may be placed by a guest operating system into the idle state until the virtual processor is needed again to execute functions on behalf of the virtual machine and/or guest operating system. And [0065]: “The virtual machine environment may be adapted to wake a virtual processor from the idle state upon arrival of interrupt requests for the virtual processor, to ensure that functionality of the virtual machine is not disrupted when a virtual processor is placed in the idle state.”) The citation discloses the virtual processor can be placed into idle state/stopping, or waking state/starting.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the including at least one of starting a virtual processor associated with the guest partition or stopping the virtual processor, as taught in Wang’s invention into Mooring, Stupachenko and Chakraborty’s invention because this features provide more details on how the VM is managed, which would improve efficiency, reliability and flexibility of VM operations and managements, as the tasks can be executed more precisely, with less overhead.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty and Stupachenko, in further view of Steinberg et al. US Pat. No. US 10108446 B1 (hereafter Steinberg)
Regarding claim 3, Mooring, in view of Chakraborty and Stupachenko discloses the method of claim 1, but fails to teach wherein initiating the management operation includes stopping or restarting the guest OS, including setting an Advanced Configuration and Power Interface (ACPI) state.
However, Steinberg teaches wherein initiating the management operation includes stopping or restarting the guest OS, including setting an Advanced Configuration and Power Interface (ACPI) state. (49 – Col 15, lines 62 – 67 and col 16, lines 1 – 30: “The late load technique may leverage the suspend and resume functions by triggering a suspend event that directs the guest operating system kernel 230 to suspend (i.e., cease operation) and save (i.e., capture) the states of the resources (including the security-critical devices) and, thereafter, trigger a resume event to restore those states in the VM. For example, an application programming interface (API) of the guest operation system may be available to activate the suspend and resume functions (i.e., execute suspend and resume code) such that the guest operating system kernel performs the work of capturing and saving of the states of the hardware resources and later restoring those states on behalf of the virtualization layer. After the suspend completes, the CPU(s) 210 are halted such that control passes to the platform ACPI layer which awaits a resume event to continue operation of the node. In an embodiment where the guest operating system does not have the suspend and resume API exposed or cannot otherwise trigger such an event, the suspend and resume functions may be triggered manually (e.g., by user invoking a hardware trigger of the suspend function). Illustratively, the suspend and resume functions of guest operating system and/or ACPI layer may be modified (a first modification) so as to return control to the ring 0 driver 510 after completing the suspend rather than returning control to the ACPI layer 550 (denoted in FIG. 5 as indicator “7”). Accordingly, the suspend and resume code of the guest operating system (and/or the ACPI layer) is further modified (a second modification) so that at least one CPU core is not shut down, allowing control to be returned to the (still running) CPU core. Notably, using the suspend function triggered within the guest operating system ensures that pending (e.g., in-flight) DMA operations complete according to the states of the devices 270 as managed by the guest operating system, thereby ensuring no I/O data is lost and operation of the node appears seamless upon a later resume.”) The citation discloses the stopping and restarting of the Guest OS through suspend and resume events, where the CPU halts and control passes to the ACPI layer to await a resume event, thereby showing management of the guest OS using ACPI states.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein initiating the management operation includes stopping or restarting the guest OS, including setting an Advanced Configuration and Power Interface (ACPI) state, as taught in Steinberg’s invention into Mooring, Stupachenko and Chakraborty’s invention because this feature would improve system control and enhances compatibility and stability when managing the VM, because ACPI is the standardized power management functions that are widely supported and reliable, in which makes the VM managements more consistent, and also reducing complexity and errors.
Claims 4 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty and Stupachenko, in further view of Lambert et al. US Pub. No. US 20100306763 A1 (hereafter Lambert)
Regarding claim 4, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, but fails to teach wherein initiating the management operation includes presenting the serial console associated with the guest OS.
However, Lambert teaches wherein initiating the management operation includes presenting the serial console associated with the guest OS. (e.g. [0020]: “More specifically, the system includes a dynamic port count virtual serial concentrator coupled with a virtualization device to map emulated serial ports to virtual machines along with a remote plugin that provide dynamic concurrent serial access to many virtual machine serial consoles under a secure and collaborative friendly environment.”)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein initiating the management operation includes presenting the serial console associated with the guest OS, as taught in Lambert’s invention into Mooring, Stupachenko and Chakraborty’s invention because this would improves the VM management by giving administrators simple and reliable ways to monitor and control the guess OS, in which brings the advantages of faster troubleshooting and recovery, and increases system reliability.
Regarding claim 5, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, but fails to teach wherein initiating the management operation includes presenting a graphical console associated with the guest OS.
However, Lambert teaches wherein initiating the management operation includes presenting a graphical console associated with the guest OS. (e.g. [0027]: “Because the remote access controller sent the host names and mappings, the client side plugin allows for easier identification of the desired virtual machine in a similar fashion to a KVM appliance access to graphics consoles.”)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein initiating the management operation includes presenting a graphical console associated with the guest OS, as taught in Lambert’s invention into Mooring, Stupachenko and Chakraborty’s invention because this features improves the usability by allowing users to interact with the VM in a more familiar and intuitive way, which brings the advantage of easier monitoring and control, reduces management complexity, and makes VM’s operations and management more accessible and efficient.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty and Stupachenko, in further view of Park et al. US Pub. No. US 20140359619 A1 (hereafter Park)
Regarding claim 6, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, but fails to teach wherein initiating the management operation includes updating the firmware associated with the guest partition, and wherein a firmware is one of: the guest firmware; a Basic Input Output System (BIOS) firmware used by the guest OS; or a Unified Extensible Firmware Interface (UEFI) firmware used by the guest OS.
However, Park teaches wherein initiating the management operation includes updating the firmware associated with the guest partition, and wherein the firmware is one of: the guest firmware; (e.g. [0086]: “The term device management for VM indicates management of firmware update or software installation/update/deletion, remote control, etc. of a VM and is an extension of a management function of a terminal to a virtual machine, which is similar to a device management function of a terminal.”) the citation discloses the concept of updating the VM firmware/guest firmware.
a Basic Input Output System (BIOS) firmware used by the guest OS;
or a Unified Extensible Firmware Interface (UEFI) firmware used by the guest OS.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein initiating the management operation includes updating the firmware associated with the guest partition, and wherein the firmware is one of: the guest firmware, as taught in Park’s invention into Mooring, Stupachenko and Chakraborty’s invention because this would improves reliability and security, and reducing downtime, since the VM can receive critical fixes and feature updates without needing complex processes, in which enables smoother maintenance and better protection of the VM.
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty and Stupachenko, in further view of HU et al. US Pub. No. US 20190138324 A1 (hereafter HU)
Regarding claim 7, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, wherein initiating the management operation includes managing a virtual device presented by the first guest privilege context, but fails to teach and wherein the virtual device is one of a virtual network interface over which the communications channel is established; a virtual console device over which the graphical or the serial console is presented; or a hardware interface device presented to the second guest privilege context.
However, HU teaches a virtual network interface over which the communications channel is established (e.g. FIG. 2 and [0002]: “The method includes providing the connection between the client machine and the remote desktop application to exchange remote desktop protocol data by using a first virtual network interface card (VNIC) on a virtual machine (VM)”) The citation discloses the connection between the client device and the VM/guest firmware via the VNIC.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the a virtual network interface over which the communications channel is established, as taught in HU’s invention into Mooring, Stupachenko and Chakraborty’s invention because the additional features would improve control and reliability by ensuring that the connection between the VM and the client device remains stable and configurable, and maintaining secure and uninterrupted management access, and enhances flexibilities of VM operations.
Regarding claim 8, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, wherein establishing the communications channel between the first guest privilege context and the client device but fails to teach comprises establishing the communications channel between a virtual network interface created by the guest firmware and the client device.
However, HU teaches comprises establishing the communications channel between a virtual network interface created by the guest firmware and the client device. (e.g. FIG. 2 and [0002]: “The method includes providing the connection between the client machine and the remote desktop application to exchange remote desktop protocol data by using a first virtual network interface card (VNIC) on a virtual machine (VM)”) The citation discloses the connection between the client device and the VM/guest firmware via the VNIC.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the comprises establishing the communications channel between a virtual network interface created by the guest firmware and the client device, as taught in HU’s invention into Mooring, Stupachenko and Chakraborty’s invention because this features improve flexibilities and isolation, more secure and reliable management access, since the channel can be set up without relying on the guest OS or external configuration.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty and Stupachenko, in further view of Cardona et al. US Pub. No. US 20190349294 A1 (hereafter Cardona)
Regarding claim 9, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, and Chakraborty discloses at [0005] “The virtual machine sends the processed data to the host partition for further processing on the underlying physical resources. The host partition further processes and sends the data back to the virtual machine for authentication with the client. The virtual machine packages and re-routes the data back to the host partition for transmission over the host partition NIC to the client.”) the data communication between host partition and virtual machine/guest firmware at the first guest privilege context, but fails to teach wherein establishing the communications channel between the first guest privilege context and the client device comprises establishing the communications channel between the guest firmware and a proxy component operating at a host partition.
However, Cardona teaches wherein establishing the communications channel between the first guest privilege context and the client device comprises establishing the communications channel between the guest firmware and a proxy component operating at a host partition. (e.g. FIG. 4 and [0101] : “The channel client library (465) provides services to the network VSP and network VSC (44n) to create a VM bus channel A VM bus channel is a virtual communication bus that passes control and data messages between the host partition and a guest partition. Specifically, the VM bus channel passes control and data messages between the network VSP of the host partition and the network VSC of the guest partition. FIG. 4 shows a VM bus channel (46n) between the virtual switch proxy (441), for the network VSP in the host partition, and the network VSC (44n) in the guest partition n. A different VM bus channel can similarly pass control and data messages between the host partition and each other guest partition.”) The citation discloses the virtual switch proxy 441/proxy component that execute in the host partition, which enable the data transfers between VMs and host partitions.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein establishing the communications channel between the first guest privilege context and the client device comprises establishing the communications channel between the guest firmware and a proxy component operating at a host partition, as taught in Cardona’s invention into Mooring, Stupachenko and Chakraborty’s invention because this feature would improve security control and safer, more efficient communication, since the proxy can manage and filer interactions between the client device and the VM, and allows management operations to be performed without exposing the VM to external connections.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty and Stupachenko, in further view of STOYANOV et al. US Pub. No. US 20220342976 A1 (hereafter STOYANOV)
Regarding claim 10, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, but fails to teach wherein establishing the communications channel between the first guest privilege context and the client device comprises negotiating an encryption protocol with the client device
However, STOYANOV teaches wherein establishing the communications channel between the first guest privilege context and the client device comprises negotiating an encryption protocol with the client device. (e.g. [0042]: “The connection 202 enables a communication between the secure computing resource 124 and the client device 102. For example, the connection 202 can be a secure encrypted connection between the secure computing resource 124 and the client device 102.” and [0071]: “The gateway 111 is configured to insert the reference object 158 into a connection 202 between the client device 102 and the virtual machine 124A enabling access to the virtual machine 124A without requiring the user to provide the set of credentials 151 for access to the virtual machine 124A.”) The citation discloses the connection 202 between the client device and the VM is a secure encrypted connection.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein establishing the communications channel between the first guest privilege context and the client device comprises negotiating an encryption protocol with the client device, as taught in STOYANOV’s invention into Mooring, Stupachenko and Chakraborty’s invention because this features would improve security and provide safer remote management, by protecting management data from being intercepted or tampered during transmission, and ensures that VM operations and managements can be performed reliable across the networks.
Claims 11, 14, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty and Stupachenko, in further view of Day et al. US Pub. No. US 20120131574 A1 (hereafter Day)
Regarding claim 11, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, but fails to teach further comprising creating the first guest privilege context and the second guest privilege context based on one or more of second-level address translation or nested virtualization.
However, Day teaches further comprising creating the first guest privilege context and the second guest privilege context based on one or more of second-level address translation
or nested virtualization. (e.g. FIG. 1, FIG. 3, and [0012]: “In some types of virtualization, the virtual machines within which the operating systems run may be nested over a number of nested virtualization levels. For example, a root hypervisor runs on the computing device, and manages the creation and deletion of first virtual machines within a first nested virtualization level. A first nested virtualization level hypervisor may itself run on one of these first virtual machines, and manage the creation and deletion of second virtual machines within a second nested virtualization level within the first nested virtualization level.”) The citation discloses the nested virtualization levels that managing different VMs at each level.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the further comprising creating the first guest privilege context and the second guest privilege context based on one or more of second-level address translation or nested virtualization, as taught in Day’s invention into Mooring, Stupachenko and Chakraborty’s invention because this would improves isolation and efficiency, and stronger security, and faster performance, since these hardware assisted techniques allow memory and privilege boundaries to be enforced with lower overhead, and enables the VM to be managed safely and effectively while reducing the complexity of context separation.
Regarding claim 14, Mooring, in view of Chakraborty and Stupachenko, discloses the method of claim 1, which has similar limitation of claim 14, but fails to teach based on one or more of second-level address translation or nested virtualization
However, Day teaches based on one or more of second-level address translation
or nested virtualization (e.g. FIG. 1, FIG. 3, and [0012]: “In some types of virtualization, the virtual machines within which the operating systems run may be nested over a number of nested virtualization levels. For example, a root hypervisor runs on the computing device, and manages the creation and deletion of first virtual machines within a first nested virtualization level. A first nested virtualization level hypervisor may itself run on one of these first virtual machines, and manage the creation and deletion of second virtual machines within a second nested virtualization level within the first nested virtualization level.”) The citation discloses the nested virtualization levels that managing different VMs at each level.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the further comprising creating the first guest privilege context and the second guest privilege context based on one or more of second-level address translation or nested virtualization, as taught in Day’s invention into Mooring, Stupachenko and Chakraborty’s invention because this would improve isolation and efficiency, and stronger security, and faster performance, since these hardware assisted techniques allow memory and privilege boundaries to be enforced with lower overhead, and enables the VM to be managed safely and effectively while reducing the complexity of context separation.
Regarding claim 15, Mooring, in view of Chakraborty, Stupachenko and Day, discloses the method of claim 14, and Stupachenko further teaches wherein initiating the management operation includes changing a power state of the VM, (e.g. Col 17, lines 55 – 62: “managing the lifecycle of the executed VM and its states (e.g., start/stop/pause/restart/shutdown VM, create a snapshot, revert to snapshot, etc.), emulating VM devices (e.g. CPU, timer, interrupt controller, network, disk, sound, etc.), and processing requests for execution of operations on virtual devices signaled by the VM through the Hypervisor 273 and mapping results back to the VM via the Hypervisor 273.”) the citation discloses the managing of a VM, including start/stop a VM.
Regarding claim 19, Mooring, in view of Chakraborty, Stupachenko and Day, discloses the method of claim 14, and Stupachenko further teaches wherein initiating the management operation includes managing a virtual device presented by the first guest privilege context. (e.g. Col 17, lines 55 – 62: “managing the lifecycle of the executed VM and its states (e.g., start/stop/pause/restart/shutdown VM, create a snapshot, revert to snapshot, etc.), emulating VM devices (e.g. CPU, timer, interrupt controller, network, disk, sound, etc.), and processing requests for execution of operations on virtual devices signaled by the VM through the Hypervisor 273 and mapping results back to the VM via the Hypervisor 273.”) The citation discloses the operation of virtual device that relates to the VM.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty, Stupachenko and Day, in further view of Steinberg et al. US Pat. No. US 10108446 B1 (hereafter Steinberg)
Regarding claim 16, Mooring, in view of Chakraborty, Stupachenko and Day, discloses the method of claim 14, but fails to teach wherein initiating the management operation includes stopping or restarting the guest OS.
However, Steinberg teaches wherein initiating the management operation includes stopping or restarting the guest OS (49 – Col 15, lines 62 – 67 and col 16, lines 1 – 30: “The late load technique may leverage the suspend and resume functions by triggering a suspend event that directs the guest operating system kernel 230 to suspend (i.e., cease operation) and save (i.e., capture) the states of the resources (including the security-critical devices) and, thereafter, trigger a resume event to restore those states in the VM. For example, an application programming interface (API) of the guest operation system may be available to activate the suspend and resume functions (i.e., execute suspend and resume code) such that the guest operating system kernel performs the work of capturing and saving of the states of the hardware resources and later restoring those states on behalf of the virtualization layer. After the suspend completes, the CPU(s) 210 are halted such that control passes to the platform ACPI layer which awaits a resume event to continue operation of the node. In an embodiment where the guest operating system does not have the suspend and resume API exposed or cannot otherwise trigger such an event, the suspend and resume functions may be triggered manually (e.g., by user invoking a hardware trigger of the suspend function). Illustratively, the suspend and resume functions of guest operating system and/or ACPI layer may be modified (a first modification) so as to return control to the ring 0 driver 510 after completing the suspend rather than returning control to the ACPI layer 550 (denoted in FIG. 5 as indicator “7”). Accordingly, the suspend and resume code of the guest operating system (and/or the ACPI layer) is further modified (a second modification) so that at least one CPU core is not shut down, allowing control to be returned to the (still running) CPU core. Notably, using the suspend function triggered within the guest operating system ensures that pending (e.g., in-flight) DMA operations complete according to the states of the devices 270 as managed by the guest operating system, thereby ensuring no I/O data is lost and operation of the node appears seamless upon a later resume.”) The citation discloses the stopping and restarting of the Guest OS through suspend and resume events, where the CPU halts and control passes to the ACPI layer to await a resume event, thereby showing management of the guest OS using ACPI states.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein initiating the management operation includes stopping or restarting the guest OS, as taught in Steinberg’s invention into Mooring, Stupachenko and Chakraborty and Day’s invention because this feature would improve system control and enhances compatibility and stability when managing the VM, because ACPI is the standardized power management functions that are widely supported and reliable, in which makes the VM managements more consistent, and also reducing complexity and errors.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty, Stupachenko and Day, in further view of Lambert et al. US Pub. No. US 20100306763 A1 (hereafter Lambert)
Regarding claim 17, Mooring, in view of Chakraborty, Stupachenko and Day, discloses the method of claim 14, but fails to teach wherein initiating the management operation includes presenting a serial console associated with the guest OS or presenting a graphical console associated with the guest OS.
However, Lambert teaches wherein initiating the management operation includes presenting the serial console associated with the guest OS. (e.g. [0020]: “More specifically, the system includes a dynamic port count virtual serial concentrator coupled with a virtualization device to map emulated serial ports to virtual machines along with a remote plugin that provide dynamic concurrent serial access to many virtual machine serial consoles under a secure and collaborative friendly environment.”)
or presenting the graphical console associated with the guest OS. (e.g. [0027]: “Because the remote access controller sent the host names and mappings, the client side plugin allows for easier identification of the desired virtual machine in a similar fashion to a KVM appliance access to graphics consoles.”)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein initiating the management operation includes presenting the serial console associated with the guest OS or presenting the graphical console associated with the guest OS, as taught in Lambert’s invention into Mooring, Stupachenko and Chakraborty and Day’s invention because this features improves the usability by allowing users to interact with the VM in a more familiar and intuitive way, which brings the advantage of easier monitoring and control, reduces management complexity, and makes VM’s operations and management more accessible and efficient
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Chakraborty, Stupachenko and Day, in further view of Park et al. US Pub. No. US 20140359619 A1 (hereafter Park)
Regarding claim 18, Mooring, in view of Chakraborty, Stupachenko and Day, discloses the method of claim 14, but fails to teach wherein initiating the management operation includes updating a firmware associated with the guest partition.
However, Park teaches wherein initiating the management operation includes updating a firmware associated with the guest partition (e.g. [0086]: “The term device management for VM indicates management of firmware update or software installation/update/deletion, remote control, etc. of a VM and is an extension of a management function of a terminal to a virtual machine, which is similar to a device management function of a terminal.”) the citation discloses the concept of updating the VM firmware/guest firmware.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein initiating the management operation includes updating the firmware associated with the guest partition, as taught in Park’s invention into Mooring, Stupachenko and Chakraborty and Day’s invention because this would improves reliability and security, and reducing downtime, since the VM can receive critical fixes and feature updates without needing complex processes, in which enables smoother maintenance and better protection of the VM.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
US 20180336346 A1: A pool of virtual environments, such as virtual machine instances and containers, can be maintained by an intermediary service, where the virtual environments can execute a specified application or service. When a request is received from a client for a connection to a resource, the intermediary service can allocate one of the virtual environments for the client and enable the client and virtual environment to communicate as if the virtual environment is executing on dedicated hardware. The virtual environment can be virtually isolated on a host machine, whereby session data for the client is stored locally in memory and then deleted at the end of the session when the virtual environment is destroyed, in order to prevent the data from being accessible between sessions and preventing multiple clients or customers from sharing the same environment over time.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c).
When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TUAN M NGUYEN whose telephone number is (703)756-1599. The examiner can normally be reached Monday-Friday: 9:30am - 5: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, Pierre Vital can be reached on (571) 272-4215. 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.
/TUAN M NGUYEN/Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198