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 11/21/2025 has been entered.
Claims 1 – 6, 8 – 14, and 16 – 21 are pending. Claims 7 and 15 are canceled. Claims 1, 9, 17, and 21 are amended.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This Office Action is in response to the applicant’s remarks and arguments filed on 11/21/2025.
Claims 1, 9, 17, and 21 were amended. Claims 7 and 15 were canceled. Claims 1 – 6, 8 – 14, and 16 – 21 remain pending in the application. Claims 1 – 6, 8 – 14, and 16 – 21 are being considered on the merits.
The previous rejection of claims 1 – 6, 8 – 14, and 16 – 21 under 35 U.S.C. §103 has been withdrawn due to the amendment to the claim filed on 11/21/2025. However, upon further consideration, a new ground(s) of rejection is made in view of a newly found prior arts (SOK et al. US Pub. No. US 20170322825 A1, and Atkinson et al. US Pat. No. US 6367012 B1), and in view of the previously cited prior art(s). Reference SOK and Atkinson, in combination with previously cited prior art(s), discloses each element of the claims highlighted by the applicant.
Response to Arguments
The applicant’s remarks and/or arguments, filed on 11/21/2025 have been fully considered with the following result(s).
The examiner is entitled to give claim limitations their broadest reasonable interpretation in light of the specification. See MPEP 2111 [R-1] Interpretation of Claims-Broadest Reasonable Interpretation. The applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Prater, 162 USPQ 541,550-51 (CCPA 1969).
Response to 35 U.S.C. §103 Remarks
Applicant's arguments in the applicant’s remarks and amendments of claims 1 – 6, 8 – 14, and 16 – 21, found on pages 7 – 10 and filed on 11/21/2025, have been fully considered and are persuasive. Therefore, the previous claim(s) rejection under 35 U.S.C § 103 has been withdrawn.
However, upon further consideration, a new ground(s) of rejection is made in view of a newly found prior arts (SOK et al. US Pub. No. US 20170322825 A1, and Atkinson et al. US Pat. No. US 6367012 B1), and in view of the previously cited prior art(s). Reference SOK and Atkinson, 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.
Claim(s) 1-3, 9-11, and 17-19, are rejected under 35 U.S.C. 103 as being unpatentable over Tsirkin et al. US Pat. No. US 9721091 B2 (hereafter Tsirkin), LUKACS et al. US Pub. No. US 20140137180 A1 (hereafter LUKACS), Bailloeul et al. US Pub. No. US 20110061092 A1 (hereafter Bailloeul), in further view of SOK et al. US Pub. No. US 20170322825 A1 (hereafter SOK)
As per claim 1, Tsirkin teaches the invention substantially as claimed a method comprising: creating, by a hypervisor running on a host computer system (FIG 1 illustrates the Hypervisor 125 runs within the computer system 100), a virtual device associated with a virtual machine (VM) managed by the hypervisor (FIG 1 illustrates the Executable manager 128 (as the Virtual Device) runs within the Hypervisor 125, and FIG 2 illustrates the connection between the Executable manager 128 with the Virtual Machine 130)
receiving, by the hypervisor .......... , a request to offload a binary file from the VM to the virtual device (Col 4, lines 17-19, “hypervisor 125 may include an executables manager 128 that is capable of receiving an executable from a virtual machine 130; Col 5, line 3-10, “the virtual machine may include an executables agent 295 that cooperates with the executables manager 128 of hypervisor 125 to ensure that running executable 290 would not compromise security of the virtual machine 130 and/or the computer system 100. In particular, the executables agent 295 provides executable 290 to the hypervisor 125 to be executed by the host computer system 100 on behalf of the virtual machine and to return the execution result to the executables agent; Col 5, lines 34-37- “At block 301, a virtual machine 130 uploads an executable (e.g., executable 290, etc.) of a guest application to host computer system 100 via guest operating system 220. The executable may be binary machine-code).
responsive to determining that [binary file is validated], enabling the virtual device to execute the binary file using a host operating system. (19 - Col 4, line 17-23: “hypervisor 125 may include an executables manager 128 that is capable of receiving an executable from a virtual machine 130, of instructing computer system 100 to verify the executable and, upon successful verification, of receiving a result returned by the executable, of performing one or more actions based on the returned result;” and 25 - Col 5, line 3-11 “In one embodiment, the virtual machine may include an executables agent 295 that cooperates with the executables manager 128 of hypervisor 125 to ensure that running executable 290 would not compromise security of the virtual machine 130 and/or the computer system 100. In particular, the executables agent 295 provides executable 290 to the hypervisor 125 to be executed by the host computer system 100 on behalf of the virtual machine and to return the execution result to the executables agent”)
wherein enabling the virtual device to execute the binary file using the host operating system comprises installing the binary file onto the host operating system (e.g. FIG. 1, FIG. 2, and 31 – col 5, lines 58 – 59: “At block 305, the executable is run via host operating system 120 on behalf of the virtual machine, possibly.”) The citation discloses at FIG. 2 that an executable 290 within the VM, and at col 5, lines 58 – 59 discloses the executable/binary file, can be run via host OS. Therefore, it implies that the executable/binary file must be installed within the host OS, because “install” could be interpreted as “loading and setting up the executable to run in the computing system.”, and since the “executable is run via host operating system”, it implies that the executable/binary file must be installed within the host OS.
and exposing the binary file to the virtual device. (Col 1, lines 29-37 (“Similarly, a virtual machine may comprise one or more “virtual devices,” each of which maps, typically in a one-to-one fashion, to a device of the host machine (e.g., a network interface device, a CD-ROM drive, etc.). The hypervisor manages these mappings in a transparent fashion, thereby enabling the guest operating system and applications executing on the virtual machine to interact with the virtual processors and virtual devices as though they were actual physical entities.” and 27 – col 5, lines 40 – 46: “The executable may also access a hardware resource of computer system 100 that is not accessible to virtual machine 130 (e.g., a graphics accelerator card [not depicted in FIG. 1], etc.). Examples of executables that may be uploaded at block 301 may include Berkeley Packet Filter bytecode, OpenCL-based executables, or any other type of executable that can be run by CPUs 160.” and 31 – col 5, lines 58 – 59: “At block 305, the executable is run via host operating system 120 on behalf of the virtual machine, possibly.”) This citation discloses at Col 1, lines 29-37 that the virtual device is mapped in a one-to-one fashion to a device of the host machine. Therefore, the virtual device could be a GPU of the host machine. at col 5, lines 40 – 46 discloses the executable/binary files can access the hardware resource of the computer system, so it implies that the executable/binary files are exposed to the hardware resource.
Tsirkin fails to teach wherein creating the virtual device comprises instructing the VM to load a device driver for the virtual device; receiving, by the hypervisor from the device driver, ..........; generating, by the hypervisor, a first measurement associated with the binary file, wherein metadata associated with contents of the binary file is excluded when generating the first measurement; determining, whether the first measurement associated with the binary file matches a second measurement stored in a database comprising a plurality of measurements and a corresponding plurality of approved binary files;
However, SOK teaches wherein creating the virtual device comprises instructing the VM to load a device driver for the virtual device; (e.g. FIG. 1 – FIG. 5 and [0029]: “First, the DomU virtual machine may transfer an input/output command, which is to be processed by using an input/output device, to the DomO virtual machine. In an operation where the DomU virtual machine transfers the input/output command, the DomU virtual machine may use a virtual driver instead of a physical driver, and the input/output command may be transferred to the DomO virtual machine through a virtual input/output path.”) The citation discloses the VM DomU contains/loads, with a virtual drivers/device driver, that used for accessing and transferring data between the VM DomU and the VM Dom0/virtual device. The VM Dom0 is equated as the virtual device because it has access to the actual device for processing request from the VM DomU.
receiving, by the hypervisor from the device driver, ..........; (e.g. FIG. 1 – FIG. 5, and [0039] – [0044]) The citation discloses the request transfers from VM DomU to VM Dom0 goes through the hypervisor. At [0040] discloses the hypervisor traps the request from VM DomU, or the request is received at the hypervisor, through the virtual driver/device driver.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein creating the virtual device comprises instructing the VM to load a device driver for the virtual device; receiving, by the hypervisor from the device driver, .........., as taught in SOK’s invention into Tsirkin’s invention because the addition features would provide clear and standardized interface for communication and interactions between the virtual device, virtual machine, and the hypervisor, which improves reliability and security, reducing errors and ensuring more secure and consistent of the entire system.
However, LUKACS teaches generating, by the hypervisor, a first measurement associated with the binary file, ......, wherein the first measurement comprises a hash value (e.g. [0053]: “The image file comprises a set of data representing a machine state of security VM 54. Before loading the image file onto memory, hypervisor 40 may compute a hash of the image file...... Computing the hash may comprise applying a hash function to the image, or to a part of the image;”) The citation discloses the hypervisor computes/generates, a hash/first measurement, which is a hash value, of the image file/binary file.
and wherein generating the first measurement comprises: computing, by the hypervisor, the hash value of the contents of the binary file by applying a hash function to the binary file (e.g. [0022]: “Unless otherwise specified, a hash is an output of a hash function. Unless otherwise specified, a hash function is a mathematical transformation mapping a sequence of symbols (e.g. characters, bits) into a number or bit string.” and [0053]: “The image file comprises a set of data representing a machine state of security VM 54. Before loading the image file onto memory, hypervisor 40 may compute a hash of the image file...... Computing the hash may comprise applying a hash function to the image, or to a part of the image; exemplary hash functions include checksum, cyclic redundancy check (e.g., CRC32), and various cryptographic hash functions such as message-digest algorithms (e.g., MD5) and secure hash algorithms (e.g., SHA256).”) The citation discloses at [0022] that a hash is an output of a hash function, and at [0053] discloses the hash function is used to compute a hash of an image file/binary file.
determining, by the hypervisor, whether the first measurement associated with the binary file matches a second measurement stored in a database ([0053]: “Before loading the image file onto memory, hypervisor 40 may compute a hash of the image file and compare the hash to a reference hash stored in a protected location of system 16, such as a trusted platform module (TPM) chip. When the hash of the image file matches the reference hash, indicating that the image file is authentic, hypervisor 40 launches trusted VM 54 by loading the image file into memory, to be executed by processor 20.”) The citation discloses after compute a hash, the hypervisor compares the hash to a reference hash/second measurement, which stored in a protected location/database.
a database comprising a plurality of measurements and a corresponding plurality of approved binary files ([0054]: “To perform such attestation operations, some embodiments of server 12 maintain a database of trusted hashes, such as hashes of security VM images in various configurations. Such hashes may be updated every time the respective VM images are updated.) The citation discloses a database of trusted hashes/measurements, and the trusted hashes associates with security VM images/approved binary files.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the generating, by the hypervisor, a first measurement associated with the binary file, ......, wherein the first measurement comprises a hash value, and wherein generating the first measurement comprises: computing, by the hypervisor, the hash value of the contents of the binary file by applying a hash function to the binary file; and determining, by the hypervisor, whether the first measurement associated with the binary file matches a second measurement stored in a database comprising a plurality of measurements and a corresponding plurality of approved binary files, as taught in LUKACS’s invention into Tsirkin’s invention because it helps to improve the system’s security by ensuring that the trusted binary file is being offloaded and executed by the system, which protects the system from malicious or unauthorized code.
However, Bailloeul teaches wherein metadata associated with contents of the binary file is excluded when generating the first measurement; ([0108]: “Next, the method computes 1204 a hash of the authorized digital document. In particular, the hash is computed of the digital document including the image of the seal, excluding the metadata.”) The citation discloses when computes the hash of the digital document/binary file, the metadata is excluded.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein metadata associated with contents of the binary file is excluded when generating the first measurement, as taught in Bailloeul’s invention into LUKACS and Tsirkin’s invention because by leaving out the metadata when creating the measurement of the binary files, the system would focus only on the important component of the binary files, which helps to improve the accurate and avoids mistakes when performing the comparison. As a result, the system can allow safe execution of the binary files without delays.
As per claim 2, Tsirkin, in view of LUKACS, SOK, and Bailloeul, discloses the method of claim 1, and LUKACS further teaches further comprising: responsive to determining that the first measurement does not match the second measurement denying the request (LUKACS – FIG. 7 and [0055]: “In a step 206, security server 12 determines whether attestation of client 16 succeeded, and if no, proceeds to a step 210...... When attestation did not succeed, in step 210, server 12 registers a security event indicating that client system 16 may be in an untrustworthy state, and in a step 212 applies a network isolation policy to client 16. Such network isolation policies may prevent the spread of malware on network(s) 18a-b.") The citation discloses that when the security server determines that attestation did not succeed, the client system 16 is not registered on the networks/denying the request.
As per claim 3, Tsirkin, in view of LUKACS, SOK, and Bailloeul, discloses the method of claim 1, and LUKACS further teaches wherein generating the first measurement associated with the binary file comprises: retrieving the second measurement from the database, ([0053]: “Before loading the image file onto memory, hypervisor 40 may compute a hash of the image file and compare the hash to a reference hash stored in a protected location of system 16, such as a trusted platform module (TPM) chip. When the hash of the image file matches the reference hash, indicating that the image file is authentic, hypervisor 40 launches trusted VM 54 by loading the image file into memory, to be executed by processor 20.”) The citation discloses after compute a hash, the hypervisor compares the hash to a reference hash/second measurement, which stored in a protected location/database.
wherein the plurality of approved binary files are associated with a plurality of hash values. ([0054]: “To perform such attestation operations, some embodiments of server 12 maintain a database of trusted hashes, such as hashes of security VM images in various configurations. Such hashes may be updated every time the respective VM images are updated.) The citation discloses a database of trusted hashes/measurements, and the trusted hashes associates with security VM images/approved binary files.
Regarding claim 9, the claim is a system claim that having similar limitations cited in claim 1. Thus, it is also rejected under the same rational.
Regarding claim 10, the claim is a system claim that having similar limitations cited in claim 2. Thus, it is also rejected under the same rational.
Regarding claim 11, the claim is a system claim that having similar limitations cited in claim 3. Thus, it is also rejected under the same rational.
Regarding claim 17, the claim is a non-transitory machine-readable storage medium claim that having similar limitations cited in claim 1. Thus, it is also rejected under the same rational.
Regarding claim 18, the claim is a non-transitory machine-readable storage medium claim that having similar limitations cited in claim 2. Thus, it is also rejected under the same rational.
Regarding claim 19, the claim is a non-transitory machine-readable storage medium claim that having similar limitations cited in claim 3. Thus, it is also rejected under the same rational.
Claim(s) 4, 5, 8, 12, 13, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable Tsirkin, LUKACS, SOK, and Bailloeul, in further view of Boulton US Pub. No. US 20190050576 A1
Regarding claim 4, Tsirkin, in view of LUKACS, SOK, and Bailloeul, discloses the method of claim 1, but fails to teach removing an approved binary file corresponding to the second measurement from the plurality of approved binary files of the database responsive to receiving an update file or a patch file for the approved binary file.
However, Boulton teaches removing an approved binary file corresponding to the second measurement from the plurality of approved binary files of the database responsive to receiving an update file or a patch file for the approved binary file ([0019]: “Client systems 108 comprise computing devices that receive binary software components and updates from the software deployment manager 106. In some cases, the client systems 108 can replace existing versions of the binary software components with new versions received from the software deployment manager 106, and can install new binary software components received from the software deployment manager 106.”) The citation discloses the replacing a binary with a newer version binary effectively equivalent to ‘remove’ that binary and would be effectively perform by a person having ordinary skill in the art.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the removing an approved binary file corresponding to the second measurement from the plurality of approved binary files of the database responsive to receiving an update file or a patch file for the approved binary file, as taught in Boulton’s invention into Tsirkin, LUKACS, SOK, and Bailloeul’s invention because it helps to ensure that the latest version of the files or software are available and ready to use.
Regarding claim 5, Tsirkin, in view of LUKACS, SOK, Boulton, and Bailloeul, discloses the method of claim 4, and LUKACS further teaches wherein the database stores measurement data for each version of the binary file. ([0054]: “To perform such attestation operations, some embodiments of server 12 maintain a database of trusted hashes, such as hashes of security VM images in various configurations. Such hashes may be updated every time the respective VM images are updated.) The citation discloses a database of trusted hashes/measurements, and the trusted hashes associates with security VM images/approved binary files.
Regarding claim 8, Tsirkin, in view of LUKACS, SOK, and Bailloeul, discloses the method of claim 1, but fails to teach using an update file or a patch file to install a new version of the binary file on the host operating system.
However, Boulton specifically teaches using an update file or a patch file to install a new version of the binary file on the host operating system. ([0019]: “Client systems 108 comprise computing devices that receive binary software components and updates from the software deployment manager 106. In some cases, the client systems 108 can replace existing versions of the binary software components with new versions received from the software deployment manager 106, and can install new binary software components received from the software deployment manager 106.”) The citation discloses a new version of the binary software is installed using the update binary software components received from the software deployment manager.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to combine the teachings of Dor with the teachings of Tsirkin, Bailloeul, LUKACS, and SOK’s, as disclosed in claim 1, in further view of Boulton to teach the installing of the binary file on a host operating system. A person having ordinary skill would have been motivated to make this combination of installing the binary file in an appropriate operating system to protect the whole system form overloading or failures due to overwhelming of requests.
Regarding claim 12, the claim is a system claim that having similar limitations cited in claim 4. Thus, it is also rejected under the same rational.
Regarding claim 13, the claim is a system claim that having similar limitations cited in claim 5. Thus, it is also rejected under the same rational.
Regarding claim 16, the claim is a system claim that having similar limitations cited in claim 8. Thus, it is also rejected under the same rational.
Regarding claim 20, the claim is a non-transitory machine-readable storage medium claim that having similar limitations cited in claim 4. Thus, it is also rejected under the same rational.
Claim(s) 6, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Tsirkin, LUKACS, SOK, Bailloeul, and Boulton, in further view of Mishra et al. US Pub. No. US 20120144383 A1 (hereafter Mishra)
Regarding claim 6, Tsirkin, in view of LUKACS, Boulton, and Bailloeul, discloses the method of claim 4. However, neither reference explicitly teaches responsive to removing the approved binary file corresponding to the second measurement, uninstalling the binary file from the host operating system.
However, Mishra teaches responsive to removing the approved binary file corresponding to the second measurement, uninstalling the binary file from the host operating system. (Claim 16 “receiving a request to update a component; performing a hash function on a first file of the component to generate a hash result; comparing the hash result with a hash key; in response to the hash result not being equal to the hash key: downloading a repair file corresponding to the first file; and overwriting the first file with the repair file; uninstalling the component; downloading an updated version of the component; and installing the updated version of the component” and [0020] “a collection of components, such as a software subsystem.”)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to combine the teachings of Dor with the teachings of Tsirkin, LUKACS, Boulton, and Bailloeul, as disclosed in claim 4, in further view of Mishra to create the claim invention of uninstalling the binary file in response to receive an update file or a patch file to remove the second measurement from a database. A person having ordinary skill would have been motivated to make this combination to ensure that the old binary file is going to be uninstalled to prevent any corruption of receiving an update or patch file and maintain the system stability and reliability. Mishra disclosed at ([0005]: “Improved computer system stability and reliability may be achieved with a method for repairing corrupt software. Repairing corrupt software components, for example, may allow old versions of components to be uninstalled such that updated components can be installed.”)
Regarding claim 14, the claim is a system claim that having similar limitations cited in claim 6. Thus, it is also rejected under the same rational.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Tsirkin, LUKACS, SOK, and Bailloeul, in further view of Atkinson et al. US Pat. No. US 6367012 B1 (hereafter Atkinson)
Regarding claim 21, Tsirkin, in view of LUKACS, SOK, and Bailloeul, discloses the method of claim 1, wherein generating the first measurement associated with the binary file comprises
LUKACS further teaches generating, by the hypervisor, the first measurement associated with the binary file, ([0053]: “The image file comprises a set of data representing a machine state of security VM 54. Before loading the image file onto memory, hypervisor 40 may compute a hash of the image file.”) The citation discloses the hypervisor computes/generates, a hash/first measurement, of the image file/binary file.
Bailloeul further teaches wherein a set of binary related data is excluded when generating the first measurement, ([0108]: “Next, the method computes 1204 a hash of the authorized digital document. In particular, the hash is computed of the digital document including the image of the seal, excluding the metadata.”) The citation discloses when computes the hash of the digital document/binary file, the metadata is excluded.
and wherein the set of binary related data comprises the metadata associated with the contents of the binary file (FIG.4A and [0074]) The citation discloses the images 402n comprises the component 406 as the document metadata/metadata.
Tsirkin, in view of LUKACS, SOK, and Bailloeul, does not clearly teach a set of binary related data is excluded when generating the first measurement, and wherein the set of binary related data comprises .......... and debug data associated with the binary file
Atkinson teaches a set of binary related data is excluded when generating the first measurement, and wherein the set of binary related data comprises .......... and debug data associated with the binary file; (e.g. claim 6: “wherein the generating step calculates a hash for the executable file, excluding the designated header field from the hash; wherein the generating step further excludes information for debugging the executable file from the hash.”, and 76 - col 19, lines 62 – 67 and col 20, lines 1 – 3: “Debug information may be considered advisory to debuggers and does not affect the integrity of the actual executable program. The debug information can be removed from an image file without affecting its functionality. (Deletion of debug information is sometimes used to reduce the size of distributed image files.) To exclude debug information from a message digest, the following information is excluded from that calculation: the debug entry of the data directory in with optional header and the debug section.”) The citation discloses the concept of excluding formation about debugging when the system calculates a hash for an executable file/binary.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the and a set of binary related data is excluded when generating the first measurement, and wherein the set of binary related data comprises .......... and debug data associated with the binary file, as taught in Atkinson’s invention into Bailloeul, LUKACS, SOK, and Tsirkin’s invention because by leaving out the debug data when creating the measurement of the binary files, the system would focus only on the important component of the binary files, which helps to improve the accurate and avoids mistakes when performing the comparison. As a result, the system can allow safe execution of the binary files without delays.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20160170784 A1 and US 20160313986 A1: the offload device can be operably coupled to the physical computing device via the interconnect interface. The interconnect interface can refer to a physical communication interface on the physical computing device. The offload device can host and emulate one or more virtual components that are used by the instantiated virtual machine instances substantially independent of one or more physical computing device resources. The virtual machine instance sends the I/O request to the virtual machine monitor. The I/O request is received and translated by the virtual machine monitor, then the I/O request is routed over the interface to the identified virtual component of the offload device. The I/O request is received and resolved by the virtual component, then the virtual component sends a response to the I/O request to the virtual machine monitor, then to the identified virtual machine instance from the virtual machine monitor.
US 20180336052 A1: an instruction executing on a virtual machine may trigger a VM exit, and in response to the VM exit, a hypervisor may invoke a VM exit handler (e.g., VM exit handler of the hypervisor. The VM exit handler may determine if the instruction has a characteristic (e.g., particular opcode, particular payload) indicating that the instruction should be handled by an accelerator device. Responsive to determining that the instruction has a characteristic indicating that the instruction should be handled by the accelerator device, the VM exit handler may offload processing of the instruction to the accelerator device. In response to receiving the offloaded instruction from the VM exit handler, the accelerator device may execute the instruction and return any resultant data to the VM exit handler. Responsive to receiving an indication of the completion of an offloaded instruction from the accelerator device or responsive to completion of a non-accelerated instruction handled by the VM exit handler, the VM exit handler may return a processing context from the VM exit handler and the hypervisor to the virtual machine, allowing operation of an application issuing the instruction to continue from the point at which the VM exit occurred.
US 20230195482 A1: Embodiments of the present disclosure is directed to techniques for transparently offloading packet processing programs from VMs (or more precisely, from guest vNIC drivers) to the hypervisor on which those VMs run, and efficiently executing the offloaded packet processing programs in the hypervisor. The techniques include adding infrastructure in the hypervisor to accept, verify, and compile (as needed) the offloaded packet processing programs; enabling multiple concurrent execution points in the hypervisor for each offloaded packet processing program (e.g., one in the host pNIC driver and another in host vNIC backends) and selecting the most appropriate/efficient execution point on a per-packet basis, and efficiently identifying, at the host pNIC driver, which of potentially multiple offloaded packet processing programs (if any) to execute for a given ingress network packet.
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