DETAILED ACTION
This office action is in response to claims filed 26 January 2026.
Claims 1-18 are pending.
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 Arguments
Applicant’s arguments, on page 6 of the remarks filed 26 January 2026, with respect to the rejections made under § 35 U.S.C. 112b have been fully considered and are persuasive. The rejections have been withdrawn.
Applicant’s arguments, on pages 6-7 of the remarks filed 26 January 2026 with respect to the rejections made under § 35 U.S.C. 103 have been fully considered but are moot because they do not address the current prior art (AASHEIM, cited below) used in the current rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1-3, 7-9, and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over WAGNER Pub. No.: US 2013/0297849 A1 (hereafter WAGNER), in view of VEMURI et al. Pub. No.: US 2014/0173113 A1 (hereafter VEMURI), in view of AASHEIM. Pub. No.: US 2012/0317568 A1 (hereafter AASHEIM).
WAGNER and VEMURI were cited previously.
Regarding claim 1, WAGNER teaches the invention substantially as claimed, including:
An information handling system comprising:
at least one processor; and
a storage resource having a bare-metal [hypervisor] thereon ([0034] FIG. 4 is a flow chart of a method 400 for nesting a bare-metal hypervisor (i.e., bare-metal hypervisor represents a bare-metal “operating system”) and a second hypervisor. The bare-metal hypervisor may be appropriate to perform functions of the first hypervisor 110. [0035] In operation 410, the first hypervisor 110 may install itself on a processor 220);
wherein…the bare-metal [hypervisor] is configured to:
deploy a hypervisor to be executed by the at least one processor ([0012] The first hypervisor 110 may run (i.e., “deploy”) a second hypervisor 130 (i.e., the claimed “hypervisor”) such that the second hypervisor 130 may be said to be "nested" with the first hypervisor 110. The second hypervisor 130 may be a commercially available hypervisor, and the second hypervisor 130 may be referred to as a cloud hypervisor. The second hypervisor may also be a bare-metal hypervisor that is, however, different from the first hypervisor); and
implement a device enumeration protocol mapping virtual objects associated with the bare-metal [hypervisor] to virtual device objects associated with the hypervisor ([Claim 21] Detecting, by the first bare-metal hypervisor, that the second hypervisor has initialized a first virtual machine by examining a virtual memory table corresponding to the second hypervisor; determining, by the first bare-metal hypervisor, addresses for locations of interest on the first virtual machine; and generating a page fault condition, the page fault condition indicating that an entry is missing in the virtual memory table, to cause the second hypervisor to provide memory contents for memory at the location of interest (i.e., the virtual memory table represents “mappings” defining a “protocol” between memory content associated with the second hypervisor, representing “virtual device objects associated with the hypervisor” and addresses for locations of interest associated with the first hypervisor, representing “virtual objects associated with the bare-metal operating system)).
While WAGNER discloses deployment of a hypervisor by a bare-metal hypervisor, WAGNER does not explicitly disclose that the bare-metal hypervisor is :
a bare-metal operating system.
However, in analogous art that similarly teaches bare-metal hypervisors, VEMURI teaches:
a bare-metal operating system ([0030] In one embodiment, the hypervisor is in the form of a hardware level or "bare metal" hypervisor 307, and acts as the functioning operating system (i.e., “bare-metal operating system”) for the VMs 305 and any additional virtualization environment software).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined VEMURI’s teaching of a bare-metal hypervisor acting as a bare-metal operating system, with WAGNER’s teaching of a bare-metal hypervisor deploying another hypervisor, to realize, with a reasonable expectation of success, a system that deploys a hypervisor using a bare-metal hypervisor, as in WAGNER, that acts as a bare-metal operating system, as in VEMURI. A person having ordinary skill would have been motivated to make this combination to better provide varying quality of service to different VMs and applications based on service level agreements with customers (VEMURI [0006]).
While WAGNER discloses installation/deployment of bare-metal hypervisors by bare-metal OSes, WAGNER and VEMURI does not explicitly disclose:
upon a first boot of the information handling system…deploy a hypervisor to be executed by the at least one processor
However, in analogous art that similarly teaches execution of bare metal operating systems, AASHEIM teaches:
upon a first boot of the information handling system…deploy a hypervisor to be executed by the at least one processor ([0016] The software hypervisor installs itself during the device boot process prior to operating system (OS) initialization).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have simply substituted AASHEIM’s teaching of installing bare-metal hypervisors upon booting a device, into WAGNER and VEMURI’s teaching of deploying bare-metal hypervisors by bare-metal operating systems, because 1) WAGNER and VEMURI’s teaching differs from the claimed device because it does not disclose installing bare-metal hypervisors upon booting of a device, 2) deploying bare-metal hypervisors upon booting of a device was known in AASHEIM, and 3) one of ordinary skill in the art could have substituted AASHEIM’s element into WAGNER and VEMURI to achieve the predictable result of a system that deploys a bare-metal hypervisor by a bare-metal OS, as in WAGNER and VEMURI, upon a first boot of a host information handling system, as in AASHEIM.
Regarding claim 2, WAGNER further teaches:
the hypervisor is a bare-metal hypervisor configured to execute directly on the information handling system ([0012] The second hypervisor 130 may be a commercially available hypervisor, and the second hypervisor 130 may be referred to as a cloud hypervisor. The second hypervisor may also be a bare-metal hypervisor that is, however, different from the first hypervisor).
Regarding claim 3, WAGNER further teaches:
the hypervisor is a cloud-based hypervisor ([0012] The second hypervisor 130 may be a commercially available hypervisor, and the second hypervisor 130 may be referred to as a cloud hypervisor. The second hypervisor may also be a bare-metal hypervisor that is, however, different from the first hypervisor).
Regarding claims 7-9, and 13-15, they comprise limitations similar to those of claims 1-3, and are therefore rejected for similar rationale.
Claim 4-5, 10-11, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over WAGNER, in view of VEMURI, in view of AASHEIM, as applied to claims 1, 7, and 13 above, and in further view of GADALIN et al. Patent No.: US 11,803,407 B1 (hereafter GADALIN).
Regarding claim 4, while WAGNER, VEMURI, and AASHEIM teaches virtual machines associated with a mapping table that represents a device enumeration protocol, WAGNER, VEMURI, and AASHEIM does not explicitly teach:
the device enumeration protocol is an architecture-independent protocol configured to allow for execution of workloads associated with a plurality of different processor architectures.
However, in analogous art that similarly executes virtual machines using a hypervisor, GADALIN teaches
the device enumeration protocol is an architecture-independent protocol configured to allow for execution of workloads associated with a plurality of different processor architectures ([Column 3, Lines 3-15] Various embodiments of the present disclosure introduce an emulation layer to allow virtual machine instances (i.e., virtual machine instances executes applications representing “workloads”) configured for one type of computer architecture to be transparently executed in another type of computer architecture (i.e., emulation layer enables virtual machines to be architecture-independent”). In a first set of embodiments, customers of a cloud provider are able to launch virtual machine instances from a virtual machine image configured for a first architecture or platform in a different architecture or platform without having to reconfigure the virtual machine image. For example, using an emulation layer, a customer may launch an x86 machine image on an ARM-based computer system that is faster and less costly under a utility computing model rather than a native x86-based computer system (i.e., the mapping table of WAGNER is associated with virtual machines which execute application workloads independent of the virtual machine or application architecture as in GADALIN))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined GADALIN’s teaching of virtual machines that execute workloads in an architecture independent manner, with the combination of WAGNER, VEMURI, and AASHEIM’s teaching of hosting virtual machines on a bare-metal hypervisor, to realize, with a reasonable expectation of success, a system that hosts virtual machines associated with a mapping table on a bare-metal hypervisor, as in WAGNER, VEMURI and AASHEIM, that execute applications independently of architecture, as in GADALIN. A person of ordinary skill would have been motivated to make this combination to realize potential performance gains through emulation (GADALIN Column 3, Lines 15-21).
Regarding claim 5, GADALIN further teaches:
the plurality of different processor architectures includes at least x86-64 and AARCH64 ([Column 3, Lines 3-15] Various embodiments of the present disclosure introduce an emulation layer to allow virtual machine instances configured for one type of computer architecture to be transparently executed in another type of computer architecture. In a first set of embodiments, customers of a cloud provider are able to launch virtual machine instances from a virtual machine image configured for a first architecture or platform in a different architecture or platform without having to reconfigure the virtual machine image. For example, using an emulation layer, a customer may launch an x86 machine image on an ARM (i.e., “AARCH64”)-based computer system that is faster and less costly under a utility computing model rather than a native x86-based computer system).
Regarding claims 10-11, and 16-17, they comprise limitations similar to those of claims 4-5, and are therefore rejected for similar rationale.
Claim 6, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over WAGNER, in view of VEMURI, in view of AASHEIM, as applied to claims 1, 7, and 13 above, and in further view of BELKAR et al. Pub. No.: US 2022/0261263 A1 (hereafter BELKAR).
Regarding claim 6, while WAGNER, VEMURI, and AASHEIM teach a bare-metal operating system implementing a bare-metal hypervisor, WAGNER, VEMURI, and AASHEIM does not explicitly teach:
the bare-metal operating system is further configured to provide a driver reload protocol configured to allow the hypervisor to reload at least one driver associated with the information handling system without a reboot.
However, in analogous art that similarly implements a bare-metal hypervisor/VMM, BELKAR teaches:
the bare-metal operating system is further configured to provide a driver reload protocol configured to allow the hypervisor to reload at least one driver associated with the information handling system without a reboot ([0006] a computing device in communication with an input/output, I/O, device providing virtualized hardware resources for use by a plurality of virtual function (VF), drivers of a plurality of virtual machines (VM), the computing device executing a virtual machine manager (VMM) (i.e., “hypervisor” which is not hosted by any host operating system (according to Fig. 2) and is therefore considered to be a “bare-metal” hypervisor), that implements a physical function (PF), driver and a plurality of base address registers (BAR), exposed by the I/O device. [0015] the PF device is further configured to: in response to receiving the request message from the VF driver, transmit data to the VM that triggers an unloading of the VF driver, in respond to unloading of the VF driver, adapting the at least one of the BARs exposed by the I/O device is adapted according to the request message, in response to completing the adaptation to the at least one of the BARs exposed by the I/O device, transmit instructions to the VM to perform a hot-swap by reloading the VF driver without rebooting the VM).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined BELKAR’s teaching of a hypervisor providing a protocol enabling a VF driver to be reloaded without a reboot, with the combination of WAGNER, VEMURI and AASHEIM’s teaching of a bare metal operating system providing a nested hypervisor, to realize, with a reasonable expectation of success, a system including a bare-metal operating system that provides a hypervisor, as in WAGNER, VEMURI, and AASHEIM, that allows a hypervisor to enable a VF driver to be reloaded without a reboot, as in BELKAR. A person having ordinary skill would have been motivated to make this combination to avoid the delay involved with rebooting a VM when updating VF drivers.
Regarding claims 12, and 18, they comprise limitations similar to those of claim 6, and are therefore rejected for similar rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195
Prosecution Insights