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 05/04/2026 has been entered.
Claims 1-8 and 10-21 are pending. Claims 1, 14, and 20 are in independent form. Claims 1, 14, and 20 were amended. Claim 9 is canceled. Claim 21 is newly added.
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 05/04/2026.
Claims 1, 14, and 20 were amended. Claim 9 was canceled. Claim 21 was newly added. Claims 1-8 and 10-21 remain pending in the application. Claims 1-8 and 10-21 are being considered on the merits.
The previous claim(s) Rejection of claims 1-8 and 10-21 under 35 U.S.C § 103 has been withdrawn due to the amendment to the claims filed on 05/04/2026. However, upon further consideration, a new ground(s) of rejection is made in view of a newly found prior art Cath et al. US Pub. No. US 20170220796 A1 (hereafter Cath) and in view of the previously cited prior art(s). Reference Cath, 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 05/04/2026 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 35 U.S.C § 103 Rejection Remarks
Applicants’ arguments in the applicant’s remarks and amendments of independent claims 1, 14 and 20, found on pages 7-9 and filed on 05/04/2026, 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 Cath et al. US Pub. No. US 20170220796 A1 (hereafter Cath) and in view of the previously cited prior art(s). Reference Cath, 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, Cath et al. US Pub. No. US 20170220796 A1 (hereafter Cath), 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 comprises 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, at the guest firmware operating within the first guest privilege context, a communications channel between the first guest privilege context and a client device that is external to the computer system;
However, Cath teaches and at the guest firmware, establishing, at the guest firmware operating within the first guest privilege context, a communications channel between the first guest privilege context and a client device that is external to the computer system; (e.g. FIG. 1, [0017]: “Further, a key is used to establish a secure connection between the isolated virtual machine and a client device executing a client browser in an operating system with no isolation capability.” and [0018]: “The key 104 may be used to establish a secure connection with a virtual machine 124. Virtual machine container 122 may operate on operating system A which allows for isolation of virtual machines. The script and key are received by virtual machine container 122 and used to create virtual machine 124. Virtual machine 124 may be configured to require key 104 to establish a connection with virtual machine 124. After being configured and initialized, virtual machine container 122 may provide server 210 a confirmation that virtual machine 124 is initialized along with an address for virtual machine 124.” and [0019]) The citations disclose the client 130, which is external to the server 120, establish the connection to the virtual machine 124/ first guest privilege context, wherein the guest Partition is the VM 122. At [0019] discloses the connection is established, and the client 130 can communicate perform actions at VM 124. Because VM 124 is an isolated VM, it would imply that VM 124 has higher privilege than other components within VM 122. In addition, because the system establishes a secure connection between VM 124 and the client 130, it would imply that there is component/software/firmware, within the VM 124 that handles the establishment of the secure connection.
Both Mooring and Cath are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add the at the guest firmware, establishing, at the guest firmware operating within the first guest privilege context, a communications channel between the first guest privilege context and a client device that is external to the computer system, as taught in Cath’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. (Cath-[0003])
Mooring fails to teach receiving, at the guest firmware and 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, Stupachenko teaches receiving, at the guest firmware and 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.
Both Mooring and Stupachenko are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add the receiving, at the guest firmware and 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 Cath’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. (Stupachenko – Col 22, lines 21-28)
Regarding claim 12, Mooring, in view of Cath 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 Cath 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, 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 limitations to 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, Cath, and Stupachenko, in further view of Wang et al. US Pub. No. US 20100218183 A1 (hereafter Wang)
Regarding claim 2, Mooring, in view of Cath 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 Cath 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.
Both Mooring and Wang are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath’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 power consumption for the system. (Wang-[0002])
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Cath and Stupachenko, in further view of Steinberg et al. US Pat. No. US 10108446 B1 (hereafter Steinberg)
Regarding claim 3, Mooring, in view of Cath 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.
Both Mooring and Steinberg are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath’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 improve system security. (Steinberg – Col 1, lines 51-57 and Col 2, lines 1-6)
Claims 4 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Cath and Stupachenko, in further view of Lambert et al. US Pub. No. US 20100306763 A1 (hereafter Lambert)
Regarding claim 4, Mooring, in view of Cath 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.”)
Both Mooring and Lambert are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath’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. (Lambert-[0004])
Regarding claim 5, Mooring, in view of Cath 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.”)
Both Mooring and Lambert are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath’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. (Lambert-[0004])
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Cath and Stupachenko, in further view of Park et al. US Pub. No. US 20140359619 A1 (hereafter Park)
Regarding claim 6, Mooring, in view of Cath 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.
Both Mooring and Park are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath’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. (Park-[0003])
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Cath and Stupachenko, in further view of HU et al. US Pub. No. US 20190138324 A1 (hereafter HU)
Regarding claim 7, Mooring, in view of Cath 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.
Both Mooring and HU are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath’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. (HU-[0050])
Regarding claim 8, Mooring, in view of Cath 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.
Both Mooring and HU are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath’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. (HU-[0050])
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Cath and Stupachenko, in further view of STOYANOV et al. US Pub. No. US 20220342976 A1 (hereafter STOYANOV)
Regarding claim 10, Mooring, in view of Cath 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.
Both Mooring and STOYANOV are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath’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. (STOYANOV-[0027])
Claims 11, 14, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Cath and Stupachenko, in further view of Day et al. US Pub. No. US 20120131574 A1 (hereafter Day)
Regarding claim 11, Mooring, in view of Cath 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.
Both Mooring and Day are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath’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. (Day-[0014])
Regarding claim 14, Mooring, in view of Cath and Stupachenko, discloses the method of claim 1, which has similar limitation to 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.
Both Mooring and Day are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath’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. (Day-[0014])
Regarding claim 15, Mooring, in view of Cath, 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 Cath, 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, Cath, 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 Cath, 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.
Both Mooring and Steinberg are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath 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. (Steinberg – Col 1, lines 51-57 and Col 2, lines 1-6)
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Cath, 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 Cath, 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.”)
Both Mooring and Lambert are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath 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. (Lambert-[0004])
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Cath, 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 Cath, 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.
Both Mooring and Park are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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 Cath 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. (Park-[0003])
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Mooring, Cath, Stupachenko, and Day, in further view of HU et al. US Pub. No. US 20190138324 A1 (hereafter HU)
Regarding claim 21, Mooring, in view of Cath, Stupachenko, and Day, discloses the computer system of claim 14, 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.
Both Mooring and HU are in the same field of endeavor, and both references relate running virtualized environment comprising virtual machines and under control of a hypervisor, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skill 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, Cath, and Day’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. (HU-[0050])
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, to prevent the data from being accessible between sessions and preventing multiple clients or customers from sharing the same environment over time.
US 20140040997 A1: a method of securing a virtual machine to be executed on a host machine includes authenticating, by the virtual machine, an identity of the host machine utilizing an initial boot routine of the virtual machine, and deleting data associated with the virtual machine, if the authentication of the host machine fails.
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
