DETAILED ACTION
This Office Actions is in response to communication filed on 07/19/2023. Claims 1-20 are pending. Claims 1, 11, and 17 are in independent form.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/16/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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-3, 5-7, 11, 12, 14, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Ghosh et al. US Pub. No. US 20090125902 A1 (hereafter Ghosh), in further view of GREST et al. US Pub. No. US 20240211288 A1 (hereafter GREST).
Regarding claim 1, Ghosh teaches the invention substantially as claimed: A virtual machine (VM) operating system (OS) device assignment system, comprising: a processor, (e.g. FIG. 1-4, and [0022]: FIG. 1 shows the architecture of an embodiment of the present invention. The off-the-shelf components are commodity microprocessors, operating systems, software applications and virtual machine technology. The design can use commodity personal computer 110 containing microprocessors including those based on the Intel/AMD x86 family of microprocessors and the PowerPC microprocessor.”)
configured to execute: a host VM, arranged to generate a driving signal for driving a booting of a guest VM; (e.g. FIG. 1-4, and [0032]: “As shown in this figure, the virtual pool management machine 150 in FIG. 1 has been replaced by virtual machine pool manager 246 running on the host machine 240. Virtual pool management machine 150 and virtual machine pool manager 246 may perform essentially the same functions. However, in FIG. 2, these functions reside solely on host machine 140.” and [0043]: “In this example, the virtual machine pool handler 246 determines that the request 443 should be forwarded to virtual machine 160. If virtual machine 160 was not running or awake, the virtual machine pool handler 246 may send commands to the virtual machine monitor to create or wake up the machine 160.”) The citation discloses the host machine/host VM, that comprise the VM pool manager 246. At [0043] The VM pool manager 246 sends commands/signal, to the VMM to create/boot, the machine 160/guest VM.
a hypervisor, arranged to generate a first trigger signal according to the driving signal, for creating VM (e.g. FIG. 1-4, and [0043]: “In this example, the virtual machine pool handler 246 determines that the request 443 should be forwarded to virtual machine 160. If virtual machine 160 was not running or awake, the virtual machine pool handler 246 may send commands to the virtual machine monitor to create or wake up the machine 160.”) the citation discloses the virtual machine monitor/hypervisor, create the machine 160 based on the commands of the VM pool handler of the host machine 240.
a device assigner, arranged to modify a descriptor file to generate a modified descriptor file ……, (e.g. FIG. 1, FIG. 2, FIG. 12, FIG. 13A-13B, [0030], and [0070-0072]) The citation discloses the processes of updating or patching an image, or creating a new operating system reference image/modify a descriptor file, to generate a modified descriptor file. At [0030] discloses that the function of the virtual machine pool manager 246 could also perform by virtual pool management machine 150/device assigner.
and install the modified descriptor file into a protected memory; (e.g. [0017]: “Access to persistent storage may be made using an authentication procedure to prove to the system that the access is approved by a user and not a malicious program.” and [0071]: “A user may copy the software or patch to persistent storage at 1340 for further use by a host or guest machine.” and [0072]: “Finally, the snapshot may be copied to persistent storage at 1390 for further use by a host or guest machine.”) The citation discloses the persistent storage/memory, could comprise authentication procedure to access, so it would imply that the persistent storage of this system is protected.
and the guest VM, wherein an OS of the guest VM is configured according to the modified descriptor file. (e.g. [0072]: “FIG. 13B is a flow diagram showing how to create a new operating system reference image 145 using the downloaded software or software patch. A second virtual machine may be created at 1350. The new software or patch may be loaded into that virtual machine at 1350....... Finally, the snapshot may be copied to persistent storage at 1390 for further use by a host or guest machine.”) The citation discloses the new OS reference image is stored and could be used by a host or guest machine. Therefore, it would imply that when the guest machine is created using the new OS reference image, the guess machine OS is configured according to the new OS reference image.
The teaching of Ghosh discloses the multiple VM could share computer hardware within the system (FIG. 1-4), but does not clearly teach the assigning the amount of hardware resources/devices, to each VM, or Warszawski fails to teach for triggering assignment of at least one device among a plurality of devices for the guest VM; …... for assigning the at least one device to the guest VM
However, GREST teaches for triggering assignment of at least one device among a plurality of devices for the guest VM; (e.g. FIG. 1, FIG. 5A, and [0023]: “As shown, in computer architecture 100, a hypervisor 108 executes directly on hardware 102. In general, hypervisor 108 partitions hardware resources (e.g., processor(s) 103, memory 104) among a root partition 112 within which a host OS 115 executes, as well as one or more guest partitions.”, [0032], [0047], and [0048]: “Method 500a also comprises an act 505 of creating a guest partition for the child VM. In some embodiments, act 505 comprises creating the second guest partition at the hypervisor based on the set of configuration parameters. In an example, partition management component 203 instructs hypervisor 108 to create guest partition 114a, using the resources donated by guest partition 113a (e.g., as identified in act 504). The citation discloses the partition management component 203 (component within the Hypervisor) creates the guest partition 114a/guest VM and allocating resources to the guest partition 114a.
…... for assigning the at least one device to the guest VM (e.g. [0050]: “In some embodiments, guest partition 113a may donate an entire directly-assigned hardware device (e.g., network interface card, graphical processing unit, storage controller) to guest partition 114a. In embodiments, based on this donation, the hypervisor configuration component 204 configures an IOMMU, such that the IOMMU uses a SLAT table for guest partition 114a”) The citation discloses guest partition 113a/device assigner, donate/assign, resources to the guest partition 114a/guest VM.
Both Ghosh and Warszawski are in the same field of endeavor, and both references disclose the concept of virtualization technologies facilitate creation of virtual machines (VMs) that each execute guest software, such as a guest operating system (OS) and applications, 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 for triggering assignment of at least one device among a plurality of devices for the guest VM; …... for assigning the at least one device to the guest VM, as taught in GREST’s invention into Ghosh’s invention because the newly added limitation would enable the system to provide the VM with the device resources it needs, which improves the overall system performance by allowing the VM obtains the resources required for its operation in a timely and controlled manner, thereby supporting proper VM startup and device usage.
Regarding claim 2, Ghosh, in view of GREST, discloses the VM OS device assignment system of claim 1, and Ghosh further teaches wherein the host VM comprises: a VM monitor, arranged to generate a monitor signal in response to the guest VM being required to be generated; (e.g. FIG. 2 and [0043]: “In this example, the virtual machine pool handler 246 determines that the request 443 should be forwarded to virtual machine 160. If virtual machine 160 was not running or awake, the virtual machine pool handler 246 may send commands to the virtual machine monitor to create or wake up the machine 160. Once the virtual machine pool manager 246 believes virtual machine 160 is running, it responds back to request handler 448 to forward the IE request 443 to virtual machine 160.”) The citation discloses the VM pool manager/VM monitor, that is responsible for sending command to generate the VMs when requested.
and GREST further teaches and an OS driver, arranged to generate the driving signal according to the monitor signal. (e.g. FIG. 1 and [0024]: “Additionally, host OS 115 is illustrated as including a host virtualization stack 117, which uses application program interface (API) calls to hypervisor 108 to create, manage, and destroy at least L1 guest partitions operating at hypervisor 108.”) The citation discloses the OS 115/OS driver, that located within the Root partition/host VM, and to request the Hypervisor to manage the guest partition/guest OS.
Regarding claim 3, Ghosh, in view of GREST, discloses the VM OS device assignment system of claim 1, and Ghosh further teaches wherein the host VM is further arranged to provide the descriptor file to a host VM memory, (e.g. FIG. 2 and [0036]: “Although reference image(s) 145 are shown residing with the host operating system 144, one skilled in the art will recognize that these image(s) 145 could be located elsewhere. For example, they could be stored directly in the computer hardware 110 memory or in an external disk drive or other type of persistent storage device accessible by the host operating system 144.”) the citation discloses the image 145/the descriptor file, could be stored at a persistent storage that accessible by the host OS.
and the device assigner is further arranged to obtain the descriptor file from the host VM memory. (e.g. FIG. 13A-13B, [0071] and [0072]) The citation discloses the processes of updating/patching image 145, so it would imply that the current image 145 must be obtained from the persistent storage to update/patch.
Regarding claim 5, Ghosh, in view of GREST, discloses the VM OS device assignment system of claim 1, and GREST further teaches wherein the hypervisor comprises: a pre-booting manager, arranged to: generate the first trigger signal according to the driving signal; (e.g. FIG. 1, FIG. 2, and [0029]: “In embodiments, configuration component 202 identifies a configuration specification associated with creation of the requested child guest partition. This configuration specification could be received as part of a request to create a child guest partition, or could be received separately (e.g., via shared memory, using API calls).”) The citation discloses at FIG. 1 the hypervisor comprises the hierarchical virtualization component 110, and FIG discloses the hierarchical virtualization component 110 comprises the configuration component 202/pre-booting manager, that identifies a configuration specification for the creation of child guest partition.
and after the modified descriptor file is installed into the protected memory, generate a second trigger signal for triggering the booting of the guest VM; (e.g. FIG. 5, [0044] – [0047]) the citation discloses the process of identify a configuration for the child partition that performs by the component 202 at block 502; After that, the process moves to block 505 for creating the child partition.
and a booting manager, arranged to receive the second trigger signal, and perform the booting of the guest VM according to the second trigger signal. (FIG. 1, FIG. 2, FIG. 5, [0033]: “In embodiments, partition management component 203 creates a requested child guest partition at hypervisor 108, using the resources donated by a parent guest partition.” and [0048]: In an example, partition management component 203 instructs hypervisor 108 to create guest partition 114a, using the resources donated by guest partition 113a (e.g., as identified in act 504).”) the citation discloses the partition management component 203/booting manager, perform the creation of the child partition.
Regarding claim 6, Ghosh, in view of GREST, discloses the VM OS device assignment system of claim 1, and Ghosh further teaches wherein the device assigner is a VM generated by the hypervisor. (e.g. FIG. 1 and [0023]: “The embodiment of the architecture shown in FIG. 1 uses the standard virtual machine architecture with the Virtual Machine Monitor (VMM) 130 running on the hardware 110, and operating systems (144, 154, 164, 174, and 194) running on top of the VMM 130. A Management VM 150 may be bootstrapped along with the Host OS 144 and a reference guest OS 145 that is used for clones of the guest OS reference image 145. The Management VM 150 is used for command, control, and lifecycle maintenance of the guest OSs (164, 174 and 194) based on the instructions from the host OS 144. The number of guest OSs instantiated may be dependent on the number of protected applications launches and the performance limits of the underlying hardware. The VMM (130) and VM (150) should support live capture of the full system state in a file for subsequent replay. This file is called a "snapshot" of system state.”) The citation discloses the Management VM 150/device assigner, that runs and is managed by the VMM 130/Hypervisor.
Regarding claim 7, Ghosh, in view of GREST, discloses the VM OS device assignment system of claim 1, and Ghosh further teaches wherein the device assigner is implemented by an application (APP) generated by the hypervisor.. (e.g. FIG. 1 and [0023]: “The embodiment of the architecture shown in FIG. 1 uses the standard virtual machine architecture with the Virtual Machine Monitor (VMM) 130 running on the hardware 110, and operating systems (144, 154, 164, 174, and 194) running on top of the VMM 130. A Management VM 150 may be bootstrapped along with the Host OS 144 and a reference guest OS 145 that is used for clones of the guest OS reference image 145. The Management VM 150 is used for command, control, and lifecycle maintenance of the guest OSs (164, 174 and 194) based on the instructions from the host OS 144. The number of guest OSs instantiated may be dependent on the number of protected applications launches and the performance limits of the underlying hardware. The VMM (130) and VM (150) should support live capture of the full system state in a file for subsequent replay. This file is called a "snapshot" of system state.”) The citation discloses the Management VM 150/application, that runs and is managed by the VMM 130/Hypervisor.
Regarding claim 11, it is a method claim having similar limitations cited in claim 1, so it is also rejected under the same rational.
Regarding claim 12, it is a method claim having similar limitations cited in claim 3, so it is also rejected under the same rational.
Regarding claim 14, Ghosh, in view of GREST, discloses VM OS device assignment method of claim 11, and Ghosh further teaches further comprising: receiving, by the device assigner, a control signal from a host VM; (e.g. FIG. 1, FIG. 4, FIG. 5, FIG. 7, and [0043]: “The request handler 448 then queries the virtual machine pool handler 246 for a virtual machine to forward the request to at 405. In this example, the virtual machine pool handler 246 determines that the request 443 should be forwarded to virtual machine 160. If virtual machine 160 was not running or awake, the virtual machine pool handler 246 may send commands to the virtual machine monitor to create or wake up the machine 160”) The citation discloses the virtual machine pool handler 246/device assigner, receives the request for awaking/starting a VM).
wherein the step of modifying, by the device assigner, the descriptor file to generate the modified descriptor file comprises: obtaining the descriptor file after the control signal is received, and modifying the descriptor file to generate the modified descriptor file. (e.g. FIG. 1, FIG. 4, FIG. 5, FIG. 7, FIG. 13A-13B) The citation discloses the processes of updating/patching image 145, so it would imply that the current image 145 must be obtained from the persistent storage to update/patch.
Regarding claim 16, it is a non-transitory machine-readable medium claim having similar limitations cited in claims 6 or 7, so it is also rejected under the same rational.
Regarding claim 17, it is a non-transitory machine-readable medium claim having similar limitations cited in claim 1, so it is also rejected under the same rational.
Regarding claim 18, it is a non-transitory machine-readable medium claim having similar limitations cited in claim 3, so it is also rejected under the same rational.
Claims 4, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ghosh, in view of GREST, in further view of Williamson US Pub. No. US 20170147370 A1.
Regarding claim 4, Ghosh, in view of GREST, discloses the VM OS device assignment system of claim 1, but fails to teach wherein the hypervisor comprises a device manager, and the device manager is arranged to manage the plurality of devices, and transmit a management result to the device assigner for the assignment of the at least one device according to the first trigger signal, wherein the management result comprises information related to unassigned devices among the plurality of devices.
However, Williamson teaches wherein the hypervisor comprises a device manager, (e.g. FIG. 1 and [0043]: “Hypervisor 125 may additionally include device configuration space 126, device data structure 127, and multi-function device manager 128.”) the citation discloses the multi-function device manager/device manager.
and the device manager is arranged to manage the plurality of devices, (e.g. [0044]: “Multi-function device manager 128 can facilitate PCI slot hot-addition deferral for multi-function devices, as described in detail below with respect to FIGS. 4-7. Multi-function device manager 128 may create the configuration space for the main function 141 and sub-functions 142-1 through 142-N in device configuration space 126”)
and transmit a management result to the device assigner for the assignment of the at least one device according to the first trigger signal, (e.g. FIG. 2, FIG. 3, and [0047]: “Multi-function device manager 128 may subsequently send the hotplug notification to guest OS 135 once the main function of the multi-function device 140 is available for the guest OS 135. Responsive to receiving the hotplug notification, guest OS 135 may send access request 2 to obtain access to the configuration space associated with multi-function device 140.”)
wherein the management result comprises information related to unassigned devices among the plurality of devices. (e.g. FIG. 2, FIG. 3, and [0050]) The citation discloses the multi-function device manager/device manager, responsible for updating the availability of the multi-function device 140 when the guest OS 135 of the VM 130 requests.
Both Williamson and Ghosh are in the same field of endeavor, and both references disclose the concept relating to virtualized computer systems, 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 the hypervisor comprises a device manager, and the device manager is arranged to manage the plurality of devices, and transmit a management result to the device assigner for the assignment of the at least one device according to the first trigger signal, wherein the management result comprises information related to unassigned devices among the plurality of devices, as taught in Williamson’s invention into Ghosh and GREST’s invention because the newly added limitation would enable the hypervisor to identify available devices and provide that information to the device assigner, which helps to improve the overall system performance by only select the available device to assign, reducing conflicts with devices already in use, and making the device assignment process more efficient and reliable.
Regarding claim 13, it is a method claim having similar limitations cited in claim 4, so it is also rejected under the same rational.
Regarding claim 19, it is a non-transitory machine-readable medium claim having similar limitations cited in claim 4, so it is also rejected under the same rational.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Ghosh, in view of GREST, in further view of Takahashi US Pub. No. US 20100023939 A1.
Regarding claim 8, Ghosh, in view of GREST, discloses the VM OS device assignment system of claim 1, but fails to teach wherein the guest VM comprises: a boot loader, arranged to perform a check operation upon the modified descriptor file, to generate a checked descriptor file; wherein the OS of the guest VM is configured according to the checked descriptor file.
However, Takahashi teaches wherein the guest VM comprises: a boot loader, arranged to perform a check operation upon the modified descriptor file, to generate a checked descriptor file; (e.g. [0041]: “The configuration-information checking unit 32 determines whether resources identical to the resources accepted by the virtual-machine configuration-information input unit 31 is stored in the configuration-information storage unit 22. Specifically, in the example explained above, the configuration-information checking unit 32 determines whether hardware resources identical to the number of CPUs "2", the memory amount of "1024", and the disk capacity of "20480" accepted by the virtual-machine configuration-information input unit 31 are stored in the configuration-information storage unit 22.”) the citation discloses the configuration-information checking unit/boot loader, checking the availability of the hardware resources for generating VM.
wherein the OS of the guest VM is configured according to the checked descriptor file. (e.g. [0042]: “When it is determined by the configuration-information checking unit 32 that the identical hardware resources are stored in the configuration-information storage unit 22, the virtual-machine generating unit 33 generates a new virtual machine and duplicates basic software of the virtual machine having the identical hardware resources. With this, a basic-software introducing process of introducing basic software of the generated new virtual machine is performed as many times as the number of machines for which it is determined that the identical hardware resources are stored in the configuration-information storage unit 22.”) The citation discloses the generation of a VM, after performing the checking of the availability of the configuration requirement.
Both Takahashi and Ghosh are in the same field of endeavor, and both references disclose the concept relating to virtualized computer systems, 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 the guest VM comprises: a boot loader, arranged to perform a check operation upon the modified descriptor file, to generate a checked descriptor file; wherein the OS of the guest VM is configured according to the checked descriptor file, as taught in Takahashi’s invention into Ghosh and GREST’s invention because the newly added limitation would improve the device assignment and OS configuration process, improve the overall system by helping prevent an incorrect or invalid device configuration from being used by the guest VM, so the OS can be configured from verified descriptor information and operate the assigned device more reliably.
Claims 9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ghosh, in view of GREST, in further view of Antony et al. US Pub. No. US 20170139697 A1 (hereafter Antony),
Regarding claim 9, Ghosh, in view of GREST, discloses the VM OS device assignment system of claim 1, but fails to teach wherein the device assigner comprises the descriptor file and a device adder, the device adder is arranged to perform the assignment of the at least one device, and the host VM is further arranged to generate and output a control signal to the device assigner for controlling the device assigner to inject the descriptor file into the device adder.
However, Antony teaches wherein the device assigner comprises the descriptor file and a device adder, the device adder is arranged to perform the assignment of the at least one device, (e.g. FIG. 1 and [0015]: “Computing system 100 also comprises a VMDK tool install catalog 104. Tool install catalog 104 stores information about the software tools installed on each VM 112, as described in further detail below. Tool install catalog 104 may store information about the guest OS for each VM 112, along with information about one or more tools installed on each VM 112. VM tools manager 102 is configured to scan through each VM 112 and determine the guest OS and tools information for each VM 112, and then populate that information into tool install catalog 104. This information may include the version number of any tools installed on each of the VMs 112. VM tools manager 102 utilizes the information stored in tool install catalog 104 to determine if updated tools are available, and then updates the tools on a VM 112 when the VM 112 is provisioned. VM tools manager 102 takes control of a VM 112 to install or upgrade tools when the VM 112 is in a powered off state, as described in further detail below.”) The citation discloses the concept of adding/assigning new devices to a VM while the VM is running, that is performed by the VM tools manager/device adder. By combining the function of performing by Antony, with the components virtual pool management machine 150/device assigner (the VM that responsible for managing other VMs) from Ghosh, one with ordinary skill in art would be able to come up with the claim invention.
and the host VM is further arranged to generate and output a control signal to the device assigner for controlling the device assigner to inject the descriptor file into the device adder; (e.g. FIG. 1 and [0015]: “VM tools manager 102 utilizes the information stored in tool install catalog 104 to determine if updated tools are available, and then updates the tools on a VM 112 when the VM 112 is provisioned. VM tools manager 102 takes control of a VM 112 to install or upgrade tools when the VM 112 is in a powered off state, as described in further detail below.”) the citation discloses the information that stored in the tool install catalog 104/descriptor file, is sent to the VM tools manager 102/device adder. The control signal is taught by Ghosh (e.g. FIG.1, FIG.4, FIG.7, and [0043]: “The request handler 448 then queries the virtual machine pool handler 246 for a virtual machine to forward the request to at 405. In this example, the virtual machine pool handler 246 determines that the request 443 should be forwarded to virtual machine 160. If virtual machine 160 was not running or awake, the virtual machine pool handler 246 may send commands to the virtual machine monitor to create or wake up the machine 160”, which discloses the virtual machine pool handler 246 receives the request for awaking/starting a VM).
Both Antony and Ghosh are in the same field of endeavor, and both references disclose the concept relating to virtualized computer systems, 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 the device assigner comprises the descriptor file and a device adder, the device adder is arranged to perform the assignment of the at least one device, and the host VM is further arranged to generate and output a control signal to the device assigner for controlling the device assigner to inject the descriptor file into the device adder, as taught in Antony’s invention into Ghosh and GREST’s invention because the newly added limitation would improves the coordination and control of the device assignment process by allowing the host VM directly control when the descriptor file is injected into the device that perform the assignment, which improve the overall system performance, helping the device assignment use the appropriate descriptor information when assigning the device to the VM.
Regarding claim 20, it is a non-transitory machine-readable medium claim having similar limitations cited in claim 9, so it is also rejected under the same rational.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Ghosh, in view of GREST and Antony, in further view of Williamson US Pub. No. US 20170147370 A1.
Regarding claim 10, Ghosh, in view of GREST and Antony, discloses the VM OS device assignment system of claim 9, but fails to teach wherein the hypervisor comprises a device manager, and the device manager is arranged to manage the plurality of devices, and transmit a management result to the device adder for the assignment of the at least one device according to the first trigger signal, wherein the management result comprises information related to unassigned devices among the plurality of devices.
However, Williamson teaches wherein the hypervisor comprises a device manager, (e.g. FIG. 1 and [0043]: “Hypervisor 125 may additionally include device configuration space 126, device data structure 127, and multi-function device manager 128.”) the citation discloses the multi-function device manager/device manager.
and the device manager is arranged to manage the plurality of devices, (e.g. [0044]: “Multi-function device manager 128 can facilitate PCI slot hot-addition deferral for multi-function devices, as described in detail below with respect to FIGS. 4-7. Multi-function device manager 128 may create the configuration space for the main function 141 and sub-functions 142-1 through 142-N in device configuration space 126”)
and transmit a management result to the device adder for the assignment of the at least one device according to the first trigger signal, (e.g. FIG. 2, FIG. 3, and [0047]: “Multi-function device manager 128 may subsequently send the hotplug notification to guest OS 135 once the main function of the multi-function device 140 is available for the guest OS 135. Responsive to receiving the hotplug notification, guest OS 135 may send access request 2 to obtain access to the configuration space associated with multi-function device 140.”)
wherein the management result comprises information related to unassigned devices among the plurality of devices. (e.g. FIG. 2, FIG. 3, and [0050]) The citation discloses the multi-function device manager/device manager, responsible for updating the availability of the multi-function device 140 when the guest OS 135 of the VM 130 requests.
Both Williamson and Ghosh are in the same field of endeavor, and both references disclose the concept relating to virtualized computer systems, 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 the hypervisor comprises a device manager, and the device manager is arranged to manage the plurality of devices, and transmit a management result to the device assigner for the assignment of the at least one device according to the first trigger signal, wherein the management result comprises information related to unassigned devices among the plurality of devices, as taught in Williamson’s invention into Ghosh, GREST, and Antony’s invention because the newly added limitation would improve the device selection and assignment process within the hypervisor by allowing the hypervisor to determine which devices are currently unassigned, avoiding the assignment conflicts with devices already in use, and making the device assignment process more efficient and reliable.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Ghosh, in view of GREST, in further view of Szeredi et al. US Pub. No. US 20200250092 A1 (hereafter Szeredi)
Regarding claim 15, Ghosh, in view of GREST, discloses the VM OS device assignment method of claim 11, but fails to teach further comprising: transferring the modified descriptor file from the protected memory to a guest VM memory of the guest VM by utilizing a hypervisor.
However, Szeredi teaches further comprising: transferring the modified descriptor file from the protected memory to a guest VM memory of the guest VM by utilizing a hypervisor (e.g. FIG. 1 and [0023]: “The hypervisor 120 may manage memory for the host operating system 118 as well as memory allocated to the guests 122 and 124 and guest operating system 196A-B such as guest memory 195A-B provided to guest OSes 196A-B.”) The citation discloses the Hypervisor managing the memory allocated/access of the VM.
Both Szeredi and Ghosh are in the same field of endeavor, and both references disclose the concept relating to virtualized computer systems, 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: transferring the modified descriptor file from the protected memory to a guest VM memory of the guest VM by utilizing a hypervisor, as taught in Szeredi’s invention into Ghosh and GREST’s invention because the newly added limitation would enable the Hypervisor to take control of delivering the device configuration to the guest VM, which improve the overall device allocation of the system, and ensuring that the VM receives the correct configuration without directly accessing the protected memory.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20130139153 A1: systems and methods for tuning operating systems, comprises a host controller monitors virtual machine hosts for a tuning event. Upon detecting a tuning event, the host controller identifies at least one virtual machine potentially affected by the tuning event and determines whether a corresponding guest operating system should be tuned. If so, the host controller obtains configuration data for the corresponding guest operating system and provides the configuration data to the corresponding guest operating system. The guest operating system then modifies its configuration parameters based on the configuration data.
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 at (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
Prosecution Insights