DETAILED ACTION
This Office Action is in response to claims filed 01/12/2026
Claims 1-20 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, see page 9 of remarks, filed 1/12/2026, with respect to the claim objection of claim 1 has been fully considered and are persuasive. The objection of 12/17/2025 has been withdrawn.
Applicant's arguments filed 1/12/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
Claims 2-3, 11-12, and 19-20 are rejected on the ground of non-statutory double patenting as being unpatentable over 2-3, 9-10, and 16-17 of U.S. Application No. 18/160,731 in view of U.S. Publication No. 2023/0136615 (hereinafter “Guim Bernat”). The Applicant respectfully holds this rejection in abeyance until all other issues on the merits have been resolved for this patent application.
With regard to point (a), Examiner has considered Applicant’s remark. However, because the basis for the rejection remains unchanged and no terminal disclaimer has been filed, the non-statutory double patenting rejection raised in the previous Office Action, filed 08/12/2025, continues to stand and will be reiterated below.
Applicant’s arguments with respect to claim(s) 1, 10, and 18 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 2-3, 11-12, and 19-20 are provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claims 2-3, 9-10, and 16-17 of co-pending Application No. 18/160,731 (hereinafter ‘731) in view of Guim Bernat et al. Pub. No. US 2023/0136615 A1 (hereinafter Guim Bernat). Although the claims are issue are not identical, they are not patentably distinct from each other because the claims of 18/160,731, in view of Guim Bernat, would be recognized by a person of ordinary skill in the art as an obvious variant.
This is a provisional non-statutory double patenting rejection.
Instant Application
Co-pending Application: 18/160,731
2. The method of claim 1, wherein the function command is received at an emulated physical function of the device controller intermediary.
2. The method of claim 1, wherein the function command is received at an emulated remote function of the device controller intermediary.
3. The method of claim 2, wherein the function command is forwarded to a physical function of the peripheral device, wherein the physical function is associated with the emulated physical function.
3. The method of claim 2, wherein the function command is forwarded to a physical function of the remote peripheral device, wherein the physical function is associated with the emulated remote function.
11. The non-transitory computer readable medium of claim 10, wherein the function command is received at an emulated physical function of the device controller intermediary.
9. The non-transitory computer readable medium of claim 8, wherein the function command is received at an emulated remote function of the device controller intermediary.
12. The non-transitory computer readable medium of claim 11, wherein the function command is forwarded to a physical function of the peripheral device, wherein the physical function is associated with the emulated physical function.
10. The non-transitory computer readable medium of claim 9, wherein the function command is forwarded to a physical function of the remote peripheral device, wherein the physical function is associated with the emulated remote function.
19. The computing device of claim 18, wherein the function command is received at an emulated physical function of the device controller intermediary.
16. The computing device of claim 15, wherein the function command is received at an emulated remote function of the device controller intermediary.
20. The computing device of claim 19, wherein the function command is forwarded to a physical function of the peripheral device, wherein the physical function is associated with emulated physical function.
17. The computing device of claim 16, wherein the function command is forwarded to a physical function of the remote peripheral device, wherein the physical function is associated with the emulated remote function.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided by the 2019 Patent Eligibility guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-9 are directed to method and fall within the statutory category of processes; Claims 10-17 are directed to non-transitory computer readable medium and fall within the statutory category of articles of manufacture and Claims 18-20 are directed to systems and fall within the statutory category of machines. Therefore, “Are the claims to a process, machine, manufacture, or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claim 1: The limitation of “making a determination that the function command does not violate the emulated function policy” as drafted, is a process that, but for the recitation of the generic computing components, under its broadest reasonable interpretation, covers performance of the limitation of the mind. For example, the limitation “making a determination” in the context of the claim broadly encompasses a person observing attributes or indicators and mentally evaluating, with or without the use of pencil and paper, such attributes to inform a conclusion.
Therefore, Yes, claim 1 recite judicial exceptions.
The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2:
Claim 1: The judicial exception is not integrated into a practical application. In particular, the claim recites the following additional elements – “a device controller intermediary”, “a peripheral device”, and “a virtual machine” which are recitations of generic computing components or other machinery merely as tools to apply the abstract idea (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Further, the claim recites the following additional elements – “performing a lookup, in a function policy database to identify an emulated function policy associated with the function command” and “in response to the determination: forwarding the function command to the peripheral device” which are recitations of mere instructions to apply the abstract idea (see MPEP § 2106.05(f)). The “performing a lookup” and “forwarding” function is cited at such a high level of generality that these additional elements do not integrate a judicial exception into practical application. Further still, the claims recite the following additional elements – “wherein the function command is associated with a peripheral device”, “wherein the function command results in a function operation of a set of function operations”, “wherein the set of function operations comprises: toggling power to the peripheral device; toggling one or more functionalities of the peripheral device; changing a mode of the peripheral device; partitioning resources of the peripheral device; creating a virtual function; process input/output requests to utilize the peripheral device; and changing global settings of the peripheral device”, and “wherein the emulated function policy specifies prohibited function operations, including: power cycling the peripheral device; allocating already-allocated virtual functions; changing properties of the peripheral device that would affect all virtual functions” which are recitations of field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate the judicial exception into practical application. Moreover, the claims recite the following additional elements – “obtaining, by a device controller intermediary, a function command from a virtual machine“ which is recitation of insignificant extra-solution activity amounting to mere data gathering (see MPEP § 2106.05(g)). This element will be further analyzed below at step 2B with regard to being Well-Understood, Routine, and Conventional.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into practical application?” No, these additional elements do not integrate the abstract idea into practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is direct to an abstract idea.
After having evaluated the inquires west forth in Steps 2A Prong 1 and 2, it has concluded that claim 1 not only recites a judicial exception by the claim is directed to the judicial exception and has not been integrated into practical application.
Step 2B:
Claim 1: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic components or other machinery as tools to apply the abstract idea and more than mere instructions to apply the abstract idea which do no amount to significantly more than the abstract idea. Moreover, the recitation of insignificant pre-solution data gathering activity is also Well-Understood, Routine, and Conventional. See MPEP § 2106.05 (d)(I) “2. A factual determination is required to support a conclusion that an additional element (or combination of additional elements) is well-understood, routine, conventional activity.” The evidentiary requirement referenced here is found in MPEP § 2106.07 (a)(III) “(B) A citation to one or more of the court decisions discussed in MPEP § 2106.05 (d), subsection II, as noting the well-understood, routine, and conventional nature of the additional element(s).” See MPEP § 2106.05(d)(II) “The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g. at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network, e.g., using the Internet to gather data.” That is, in the instant claims these limitations merely receive data which is Well-Understood, Routine, and Conventional.
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception?” No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claim 1 does not recite patent eligible subject matter under 35 U.S.C . § 101.
With regard to claim 2, it recites additional elements of “wherein the function command is received at an emulated physical function of the device controller intermediary” which is recitation of insignificant extra-solution activity amounting to mere data gathering (see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application and is also Well-Understood, Routine, and Conventional. See MPEP § 2106.05 (d)(I) "2. A factual determination is required to support a conclusion that an additional element (or combination of additional elements) is well-understood, routine, conventional activity." The evidentiary requirement referenced here is found in MPEP § 2106.07 (a)(III) "(B) A citation to one or more of the court decisions discussed in MPEP § 2106.05 (d), subsection 11, as noting the well-understood, routine, and conventional nature of the additional element(s)." See M PEP§ 2106.05(d)(II) "The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g. at a high level of generality) or as insignificant extra solution activity. i. Receiving or transmitting data over a network, e.g., using the Internet to gather data." That is, in the instant claims the limitation merely receives data which is Well-Understood, Routine, and Conventional. Claim 2 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 2 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as it has not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 2 does not recite patent eligible subject matter under 35 § U.S.C. 101.
With regard to claim 3, it recites additional elements of “wherein the function command is forwarded to a physical function of the peripheral device” which is recitation of mere instructions to apply the abstract idea (see MPEP § 2106.05(f)). The “forwarding” function is cited at such a high level of generality that these additional elements do not integrate a judicial exception into practical application. Further, the claim recites additional element of “wherein the physical function is associated with the emulated physical function” which is merely recitation of field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Claim 3 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 3 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 3 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 4, it recites additional elements of “wherein the function policy database comprises a function entry” and “wherein the function entry comprises the emulated function policy and an emulated function identifier associated with the emulated physical function” which are merely recitations of field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Claim 4 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 4 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 4 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 5, it recites additional elements of “wherein the function command specifies a function operation” which is merely recitation of field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Claim 5 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 5 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 5 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 6, it recites additional elements of “generating an emulated virtual function associated with the virtual function”
With regard to claim 7, the above analysis is incorporated herein by substantial similarity to claim 1 as it applies equally to claim 7. Claim 7 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 7 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 7 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 8, the above analysis is incorporated herein by substantial similarity to claim 1 as it applies equally to claim 8, except that in claim 8 recites additional elements not included in claim 1: “rejecting the second function command” which is recitation of mere instructions to apply the abstract idea (see MPEP § 2106.05(f)). The “rejecting” function is cited at such a high level of generality that these additional elements do not integrate a judicial exception into practical application. Claim 8 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 8 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 8 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 9, it recites additional elements of “identifying that a function operation, of the function command, specifies making a global change to the peripheral device” which are recitations of field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate the judicial exception into practical application. Claim 9 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 9 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 9 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 10, the above analysis is incorporated herein by substantial similarity to claim 1 as it applies equally to claim 10, except that in claim 10 recites additional elements not included in claim 1: “a non-transitory computer readable medium comprising instructions which, when executed by a processor, enables the processor to perform a method for processing a function command for a peripheral device” which are recitations of generic computing components or other machinery merely as tools to apply the abstract idea (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Claim 10 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 10 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 10 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 11, the above analysis is incorporated herein by substantial similarity to claim 2 as applies equally to claim 11. Claim 11 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 11 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 11 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 12, the above analysis is incorporated herein by substantial similarity to claim 3 as it applies equally to claim 12. Claim 12 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 12 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 12 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 13, the above analysis is incorporated herein by substantial similarity to claim 4 as it applies equally to claim 13. Claim 13 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 13 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 13 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 14, the above analysis is incorporated herein by substantial similarity to claim 5 as it applies equally to claim 14. Claim 14 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 14 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 14 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 15, the above analysis is incorporated herein by substantial similarity to claim 6 as it applies equally to claim 15. Claim 15 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 15 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 15 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 16, the above analysis is incorporated herein by substantial similarity to claim 8 as it applies equally to claim 16. Claim 16 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 16 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 16 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 17, the above analysis is incorporated herein by substantial similarity to claim 9 as it applies equally to claim 17. Claim 17 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 17 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 17 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 18, the above analysis is incorporated herein by substantial similarity to claim 1 as it applies equally to claim 18. Claim 18 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 18 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 18 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 19, the above analysis is incorporated herein by substantial similarity to claim 2 as it applies equally to claim 19. Claim 19 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 19 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 19 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 20, the above analysis is incorporated herein by substantial similarity to claim 3 as it applies equally to claim 20. Claim 20 does not recite any additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 20 fails both Step 2A prong 2, thus the claim is directed to a judicial exception as they have not been integrated into practical application and fails Step 2B as not amounting to significantly more. Therefore, Claim 20 does not recite patent eligible subject matter under 35 U.S.C. § 101.
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, 7-12, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over O'Dowd et al. Pub. No. US 2015/0363513 A1 (hereinafter O'Dowd) in view of Ogasawara et al. "Nioh: Hardening The Hypervisor by Filtering Illegal I/O Requests to Virtual Device" (hereinafter Ogasawara in view of Brown et al. Pub. No. US 2009/0144731 A1 (hereinafter Brown) in view of Shacham et al. Pub. No. US 2015/0346795 A1 (hereinafter Shacham).
With regard to claim 1, O’Dowd teaches a method for processing a function command for a peripheral device, the method comprising (Abstract, An adjunct I/O virtualization may also be included to abstract the guarded input peripheral interfaces, such that all attempts to turn them on from within the operating system are automatically redirected by the I/O virtualization mechanism to the peripheral control domain; [0018], In certain embodiments, a method of domain isolation is disclosed, comprising):
obtaining, by a device controller intermediary ([0016], In certain embodiments, a portable computing device is disclosed comprising: … an I/O virtualization mechanism configured to be interposed between the operating system domain and the peripheral control domain), a function command from a virtual machine, wherein the function command is associated with a peripheral device ([0018], Receiving an input peripheral access request from at least one portable device operating system).
performing a lookup, in a function policy database to identify an emulated function policy associated with the function command ([0016], The peripheral control domain may comprise: a physical peripheral control component; and a policy component for deciding how to handle input peripheral requests originating from the operating system);
making a determination that the function command does not violate the emulated function policy ([0016], The policy component may be configured to perform a local, autonomous decision regarding whether to allow input peripheral access based at least in part on at least one detectable condition. The at least one detectable condition may comprise at least one of a geolocation, one or more fixed policy settings, and an active connection to a trusted network), …; and
in response to the determination ([0014], The peripheral control 130 may then conduct a policy-driven decision process via peripheral access policy module 140 to either allow, disallow, or request manual/explicit authorization of these access attempts):
forwarding the function command to the peripheral device ([0014], If access is permitted, such physical access may be performed by physical peripheral control domain 130)
O’Dowd reasonably teaches portable computing devices comprising a machine virtualization module (O’Dowd, [0016]) and an operating system issuing a request to access the peripheral (O’Dowd, Abstract). However, O’Dowd does not explicitly teach the function command request is from a virtual machine.
Ogasawara teaches a function command from a virtual machine (Pg. 545, Figure 3, Request made from Guest VMs; Pg. 545, 4.1 Architectural Overview, We introduce an additional layer between guest VMs and virtual devices. Figure 3 shows the architectural overview of Nioh. Regarding an original hypervisor (a), I/O requests issued by guest VMs directly reach virtual devices without any inspections. Regarding a hypervisor with Nioh (b), however, all requests are inspected using Nioh before reaching virtual devices; Pg. 548, 4.4 Implementation, To apply Nioh with KVM+QEMU , we add some hooks to the QEMU. When an I/O request to virtual devices occurs in a guest VM, a CPU issues VMExit with sorting I/O request information into VM-exit information fields of the VM control structure (VMCS)
wherein the emulated function policy specifies prohibited function operations (Pg. 545, To distinguish illegal I/O requests from benign ones, Nioh models a device specification as a device automaton. Hardware devices have states in which the device is either waiting for an I/O command, executing an I/O command, or waiting for interrupts In each state, a device specification denotes what types of I/O requests are valid and acceptable), including:
power cycling the peripheral device;
allocating already-allocated virtual functions (Pg. 544-545, Figure 2 shows how to exploit a hypervisor using VENOM vulnerability in the READ_ID command. The blue liens are legal operations and red lines are illegal operations in this command. After the command code and associated parameters are written in the command phase, QEMU’s virtual FDC makes a transition to the execution phase. Before asserting an interrupt, the virtual FDC sets a timer to emulate the delay in the hardware FDC that corresponds to seek latency. The FDC specification forbids the FIFO buffer from being accessed in the execution phase, in which the READ_ID command is executed. In fact, the MSR indicates that the FDC is busy in this phase. However, the virtual FDC allows the access to the FIFO buffer, and resulting in the buffer overflow (Examiner notes: such that a buffer overflow attack is an allocation of already-allocated memory) … Our approach filters out illegal I/O requests before they reach virtual devices);
changing properties of the peripheral device that would affect all virtual functions (Pg. 542, Device emulation is a hotbed of vulnerabilities in hypervisors … VENOM [11] in 2015 is a vulnerability in a QEMU emulated floppy disk controller (FDC). VENOM results in VM Escape because attackers can gain a hypervisor’s privilege and run arbitrary code in the hypervisor (Examiner notes: wherein the privilege escalation of hypervisor affects all virtual functions) … Nioh inspects I/O requests VMs and rejects those that violate the device specification. For example … the FDC must not accept I/O requests that access the FIFO buffer when executing READ_ID or DRIVE_SPECIFICATION_COMMAND)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Ogasawara with the teachings of O’Dwod in order to provide a method that teaches function command association with a virtual machine and prohibited function operations in response to known vulnerabilities. The motivation for applying Ogasawara teaching with O’Dwod teaching is to provide a method that allows for server workloads to be distributed among highly efficient and isolated computing instances such that a plurality of virtual machines can be managed and multiplexed to different hardware resources while maintaining safety and stability of the devices performing such workloads and operations (Ogasawara, Pg. 542). O’Dwod and Ogasawara are analogous art directed towards hypervisor-specific management and security arrangements for peripheral components. Therefore, it would have been obvious for one of ordinary skill in the art to combine Ogasawara with O’Dwod to teach the claimed invention in order to provide efficient and isolated management of resources of peripheral devices through a virtualized environment.
However, the combination does not explicitly teach the performance of a function command resulting in a function operation from a set of function operations.
Brown teaches wherein the function command results in a function operation of a set of function operations, wherein the set of function operations comprises ([0073], FIG. 8A is an exemplary diagram illustrating a definition of a set of exemplary CRQ hypervisor events in accordance with one illustrative embodiment; [0088], FIG. 9 is an exemplary diagram illustrating a definition of a set of exemplary Logical Partition (LPAR) to platform firmware calls in accordance with one illustrative embodiment):
toggling power to the peripheral device ([0105], The hypervisor 625 and IMP 603 may also be informed by the HMC 609 when to power up and power down an I/O adapter or endpoint. This may be accomplished through the power up/down IOA request 1010);
toggling one or more functionalities of the peripheral device ([0108], The dynamic add/remove of a VF request 1016 to an IMP 603 informs the IMP 603 to add or remove the resources for a VF, e.g., the CRQ mechanism and any supporting structures necessary to support a specific VF, and to begin or terminate communications with the client partition 604 via the CRQ mechanism that there is a VF available to be added or that is time to remove a VF that was previously allocated to that client partition 604);
changing a mode of the peripheral device ([0081], The “Enable Load/Store to VF” request 822 requests that the IMP 603 allow the unblocking of MMIO Load and Store operations to the VF, as when the VF is in an error state (Examiner notes: where state used herein is substantially similar to the operating mode of the peripheral device);
partitioning resources of the peripheral device ([0074], As shown in FIG. 8A, “the partner partition connected” event 802 is a way for the hypervisor, e.g., hypervisor 625 in FIG. 6, to inform the IMP, e.g., IMP 603 in FIG. 6, and client partition, e.g., client partition 604 in FIG. 6, that both ends of the connection between the IMP 603 and a client partition 604 are ready);
creating a virtual function ([0106], There are several HMC to platform requests 1012-1016 that are used by the HMC to direct the dynamic addition of an IOV adapter 615 to the system 601 or VF to a client partition 604, i.e. while the system is operational and after initial configuration. The dynamic assignment of an IOV adapter requests 1012 is used by the HMC 609 to inform the hypervisor 625 to allocate an IOV adapter 614 to an IMP 603 along with the system resources necessary to operate that adapter; [0107], Once the hypervisor 625 has completed the dynamic add of an IOV adapter request 1012, the IMP 603 may be informed of any additions. The dynamic add of an IOV adapter to an IMP request 1014 informs the IMP 603 that a new IOV adapter 614 to be added);
process input/output requests to utilize the peripheral device ([0089], as shown in FIG. 9, the add command (request) or response to CRQ of partner LPAR call 902 is a call used to send a command/request or response to the CRQ 607 or 608. This call may be used by the client partitions 604 and the IMP 603); and
changing global settings of the peripheral device ([0078], The client to IMP requests in FIG. 8B further include a configuration request 814 which is used by the client partition 604 to get the IMP 603 to perform a configuration read operation on the configuration space of the VFs and PFs of the IOV enabled adapter/endpoint 614 … Similarly, the client to IMP requests further include configuration write requests 816 which is used by the client partition 604 to get the IMP 603 to perform a configuration write operation to the configuration space of VFs and PFs of the IOV enabled endpoint 614)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Brown with the teachings of O’Dowd and Ogasawara in order to provide a method that teaches a set of function operations that can be processed on a peripheral device. The motivation for applying Brown teaching with O’Dowd and Ogasawara teaching is to provide a method that combines the known methods of peripheral device processing of a set of operations with the known methods of function operation policy access management to yield predictable results, with a high probability of success. O’Dowd and Ogasawara and Brown are analogous art directed towards hypervisor specific management. Therefore, it would have been obvious for one of ordinary skill in the art to combine Brown with O’Dowd and Ogasawara to teach the claimed invention in order to provide peripheral device management to a set of different operations and requests that can be processed on such device.
The combination reasonably teaches filtering of prohibited function operations through command inspection associated with function policy of a device (Ogasawara. Pg. 546). However, the combination does not explicitly teach that a prohibited function operation including power cycling the peripheral device.
Shacham teaches power cycling the peripheral device ([0034], The MHPC 232 in some aspects mays also include an MHPC control register 304 that is used by virtualization management software (such as VMM 108, as a non-limiting example) to indicate which of the I/O clients 104(0)-104(N) are permitted to vote for power mode control of the flash-memory-based storage device 106 … power mode change requests for one of the I/O clients 104(0)-104(N) that is not permitted to vote for power control are “trapped”)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Shacham with the teachings of O’Dowd, Ogasawara, and Brown in order to provide a method that teaches function policies incorporating prohibited functions including power cycling a peripheral device. The motivation for applying Shacham teaching with O’Dowd, Ogasawara, and Brown teaching is to provide a method that allows for restricting power-cycling operations of devices to be performed only by authorized entities in order to preserve system stability supporting a plurality of hosts (Shacham, [0008]). O’Dowd, Ogasawara, and Brown and Shacham are analogous art directed towards peripheral device arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Shacham with O’Dowd, Ogasawara, and Brown to teach the claimed invention in order to provide power cycling operation detection and restriction associated with peripheral devices.
With regard to claim 2, O’Dowd reasonably teaches receiving function commands at a device controller intermediary. However, O’Dowd does not explicitly teach that the function command is directed towards an emulated physical function of the device controller intermediary.
Ogasawara teaches the method of claim 1, wherein the function command is received at an emulated physical function of the device controller intermediary (Pg. 547, 4.3 Nioh’s Framework, To determine to which state to make a transition, Nioh must determine what value is read from or written to device registers. In read requests, Nioh cannot obtain the value before emulation in virtual devices. Thus, after the emulation in a virtual device, Nioh intercepts the control and obtains a value read from the device register. This flow is shown with the red lines in Figure 6).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Ogasawara with the teachings of O’Dowd, Brown, and Shacham in order to provide a method that teaches function command received by an emulated physical function of the device controller intermediary. The motivation for applying Ogasawara teaching with O’Dowd, Brown, and Shacham teaching is to provide a method that allows for an emulated component for verifying the nature of the request to provide instruction isolation, such that enables protection at the hypervisor which executes the instruction (Ogasawara, Pg. 548). O’Dowd, Brown, Schacham and Ogasawara are analogous art directed towards hypervisor-specific management and security arrangements for peripheral components. Therefore, it would have been obvious for one of ordinary skill in the art to combine Ogasawara with O’Dowd, Brown, and Shacham to teach the claimed invention in order to provide an isolation execution environment to securely perform intrusion prevention and enable device scalability.
With regard to claim 3, Ogasawara teaches the method of claim 2, wherein the function command is forwarded to a physical function of the peripheral device (Pg. 546, 4.2 Filtering Model, Nioh inspects every request from the guest OS. If the current state has a transition that matches the request, the request is considered legal and is forwarded to the virtual device), wherein the physical function is associated with the emulated physical function (Pg. 547, Figure 6: Nioh’s Framework, I/O request is routed to Nioh process and, if valid, is then routed to emulated physical function; Pg. 547, 4.3 Nioh’s Framework, When Nioh receives I/O request information containing an address, value, and direction (e.g., read or write) of I/O, it creates an operation_info object from the information and passes it to the device_manager object. The device_manager looks up a device object corresponding to the operation_info and request the inspection to the device object … To inspect the I/O request, Nioh must determine which device the I/O request is for. The device_manager object is responsible for this task. The device_manager object has maps from the PIO port addresses, MMIO addresses and IRQ numbers to device objects).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Ogasawara with the teachings of O’Dowd, Brown, and Shacham in order to provide a method that teaches command routing to an emulated function of the peripheral device. The motivation for applying Ogasawara teaching with O’Dowd, Brown, and Shacham teaching is to provide a method that allows for inspection of the command in accordance with the device specification from a plurality of specifications (Ogasawara, Pg. 547). O’Dowd, Brown, Shacham and Ogasawara are analogous art directed towards hypervisor-specific management and security arrangements for peripheral components. Therefore, it would have been obvious for one of ordinary skill in the art to combine Ogasawara with O’Dowd, Brown, and Shacham to teach the claimed invention in order to provide request validation for a command using the proper device filter associated with the command.
With regard to claim 7, O’Dowd teaches the method of claim 1, wherein after forwarding the function command to the peripheral device, the method comprises:
obtaining a second function command from a second virtual machine (Abstract, An adjunct I/O virtualization may also be included to abstract the guarded input peripheral interfaces, such that all attempts to turn them on from within the operating system are automatically redirected by the I/O virtualization mechanism to the peripheral control domain; [0016], In certain embodiments, a portable computing device is disclosed comprising: … an I/O virtualization mechanism configured to be interposed between the operating system domain and the peripheral control domain; [0005], Portable device operating systems employ a number of security controls aimed at preventing unauthorized manipulation of input peripherals (Examiner notes: a plurality of machines transmitting a plurality of request attempts to a plurality of peripherals); [0030], While the above description contains many specifics, these should not be construed as limitations on the scope of the invention, but rather as an exemplification of certain embodiments thereof. The invention includes any combination or subcombinations of the elements from the different species and/or embodiments disclosed herein (Examiner notes: The disclosure is not limited to only a single computing instance attempting a single peripheral access request), wherein the function command is associated with a peripheral device ([0018], Receiving an input peripheral access request from at least one portable device operating system);
performing a second lookup, in a function policy database to identify a second emulated function policy associated with the second function command ([0016], The peripheral control domain may comprise: a physical peripheral control component; and a policy component for deciding how to handle input peripheral requests originating from the operating system);
making a second determination that the function command does not violate the second emulated function policy ([0016], The policy component may be configured to perform a local, autonomous decision regarding whether to allow input peripheral access based at least in part on at least one detectable condition. The at least one detectable condition may comprise at least one of a geolocation, one or more fixed policy settings, and an active connection to a trusted network); and
in response to the determination ([0014], The peripheral control 130 may then conduct a policy-driven decision process via peripheral access policy module 140 to either allow, disallow, or request manual/explicit authorization of these access attempts):
forwarding the second function command to the peripheral device ([0014], If access is permitted, such physical access may be performed by physical peripheral control domain 130).
O’Dowd reasonably teaches portable computing devices comprising a machine virtualization module (O’Dowd, [0016]) and a plurality of attempts by operating systems to access peripheral devices (O’Dowd, Abstract). However, O’Dowd does not explicitly teach the function command request is from a virtual machine. Further, O’Dowd does not explicitly teach the second iteration of the method for a second function command from a second virtual machine.
Ogasawara teaches obtaining a second function command from a second virtual machine (FIG. 1 and FIG. 3, Plurality of VMs performing request to peripheral devices; Pg. 542, Introduction, Virtualization allows many VMs to run on a single physical machine in an isolated manner. To give an illusion that there are many virtual devices, a hypervisor multiplexes a physical hardware device and mediates access from multiple VMs; Pg. 543, Introduction, To demonstrate the effectiveness of Nioh, we have implemented a prototype of Nioh in Rust [8], a type-safe language, for KVM + QEMU. The use of a type-safe language improves the overall security of Nioh. The prototype provides a software framework that encapsulates the interactions between device automata and the underlying hypervisors. This separation enhances the reusability of the device automaton (Examiner notes: Performance of the method can be repeated for a plurality of VMs and peripheral devices)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Ogasawara with the teachings of O’Dowd in order to provide a method that explicitly teaches a second repetition of the method for a plurality of function commands received by virtual machines. The motivation for applying Ogasawara teaching with O’Dowd teaching is to provide a method that allows for uniform and consistent enforcement of command filtering across all VMs in a system, such that ensures that no single VM becomes an entry point for an attack (Ogasawara, Pg. 543). O’Dowd and Ogasawara are analogous art directed towards hypervisor-specific management and security arrangements for peripheral components. Therefore, it would have been obvious for one of ordinary skill in the art to combine Ogasawara with O’Dowd to teach the claimed invention in order to provide proactive protection against a variety of attacks across all VMs attempting peripheral access in the system.
With regard to claim 8, O’Dowd teaches the method of claim 1, wherein after forwarding the function command to the peripheral device the method further comprises:
obtaining a second function command from a second virtual machine (Abstract, An adjunct I/O virtualization may also be included to abstract the guarded input peripheral interfaces, such that all attempts to turn them on from within the operating system are automatically redirected by the I/O virtualization mechanism to the peripheral control domain; [0016], In certain embodiments, a portable computing device is disclosed comprising: … an I/O virtualization mechanism configured to be interposed between the operating system domain and the peripheral control domain; [0005], Portable device operating systems employ a number of security controls aimed at preventing unauthorized manipulation of input peripherals (Examiner notes: a plurality of machines transmitting a plurality of request attempts to a plurality of peripherals); [0030], While the above description contains many specifics, these should not be construed as limitations on the scope of the invention, but rather as an exemplification of certain embodiments thereof. The invention includes any combination or subcombinations of the elements from the different species and/or embodiments disclosed herein (Examiner notes: The disclosure is not limited to only a single computing instance attempting a single peripheral access request), wherein the function command is associated with a peripheral device ([0018], Receiving an input peripheral access request from at least one portable device operating system);
performing a second lookup, in a function policy database to identify a second emulated function policy associated with the second function command ([0016], The peripheral control domain may comprise: a physical peripheral control component; and a policy component for deciding how to handle input peripheral requests originating from the operating system);
making a second determination that the function command does not violate the second emulated function policy ([0016], The policy component may be configured to perform a local, autonomous decision regarding whether to allow input peripheral access based at least in part on at least one detectable condition. The at least one detectable condition may comprise at least one of a geolocation, one or more fixed policy settings, and an active connection to a trusted network); and
in response to the determination ([0014], The peripheral control 130 may then conduct a policy-driven decision process via peripheral access policy module 140 to either allow, disallow, or request manual/explicit authorization of these access attempts):
O’Dowd reasonably teaches portable computing devices comprising a machine virtualization module (O’Dowd, [0016]) and a plurality of attempts by operating systems to access peripheral devices (O’Dowd, Abstract). However, O’Dowd does not explicitly teach the function command request is from a virtual machine. Further, O’Dowd does not explicitly teach the second iteration of the method of a second function command from a second virtual machine.
Ogasawara teaches obtaining a second function command from a second virtual machine (FIG. 1 and FIG. 3, Plurality of VMs performing request to peripheral devices; Pg. 542, Introduction, Virtualization allows many VMs to run on a single physical machine in an isolated manner. To give an illusion that there are many virtual devices, a hypervisor multiplexes a physical hardware device and mediates access from multiple VMs; Pg. 543, Introduction, To demonstrate the effectiveness of Nioh, we have implemented a prototype of Nioh in Rust [8], a type-safe language, for KVM + QEMU. The use of a type-safe language improves the overall security of Nioh. The prototype provides a software framework that encapsulates the interactions between device automata and the underlying hypervisors. This separation enhances the reusability of the device automaton (Examiner notes: Performance of the method can be repeated for a plurality of VMs and peripheral devices)
Rationale to claim 7 applied here.
Examiner notes: It would be obvious for one of ordinary skill in the art to understand how to apply the teachings of Ogasawara to multiple attempts by multiple computing instances with operating systems.
Further still, O’Dowd reasonably teaches policy-driven access control to peripheral devices (O’Dowd, [0014]). However, O’Dowd does not explicitly disclose rejecting a second function command.
Ogasawara teaches rejecting the second function command (Pg. 545, Figure 3: Architectural Overview, Hypervisor with Nioh depicts rejection of invalid request; Pg. 543, When an I/O request is issued from a VM, the automaton checks if the request matches the outgoing edges. If there is a match, the request is accepted and passed to a device emulator. Otherwise, it is filtered out, and the issuing VM is destroyed)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Ogasawara with the teachings of O’Dowd, Brown, and Shacham in order to provide a method that teaches rejection of a second function command in response to a policy violation. The motivation for applying Ogasawara teaching with O’Dowd, Brown, and Shacham teaching is to provide a method that allows for function command intrusion prevention such that upon violation, the system performs preventive actions to prevent unauthorized commands from being executed. As such, the method preserves the system’s integrity (Ogasawara, Pg. 545). O’Dowd, Brown, Shacham, and Ogasawara are analogous art directed towards hypervisor-specific management and security arrangements for peripheral components. Therefore, it would have been obvious for one of ordinary skill in the art to combine Ogasawara with O’Dowd, Brown, and Shacham to teach the claimed invention in order to provide proactive inspection of function commands and contingency to isolate and remove commands in violation of established security policies.
With regard to claim 9, Ogasawara teaches the method of claim 8, wherein making the second determination comprises:
identifying that a function operation, of the function command, specifies making a global change to the peripheral device (Pg. 544, 2.3 Example Vulnerability: VENOM, VENOM allows attackers in guest VMs to execute arbitrary code in a hypervisor by exploiting the buffer overflow vulnerability in the FDC’s FIFO buffer. This vulnerability arises from wrong emulation that does not follow the device specification. When the FDC is executing READ_ID or DRIVE_SPECIFICATION_COMMAND commands, the hardware FDC rejects I/O requests that write data into its FIFO buffer. However, the QEMU’s emulated FDC accepts those request when those commands are executed and does not check the index of its FIFO buffer (Examiner notes: The I/O requests specify global change to the peripheral device); Pg. 545, 2.3 Example Vulnerability: VENOM, The problem behind VENOM is the mis-emulation of the hardware device; the virtual FDC accepts illegal I/O requests that do not follow the FDC’s specification. Our approach (Examiner notes: Identify invalid global I/O requests) filters out illegal I/O request before they reach virtual devices. Generally, a software module is extensively tested for expected inputs but not sufficiently tested for unexpected or invalid inputs. Nioh rejects unexpected or invalid inputs to virtual devices).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Ogasawara with the teachings of O’Dowd, Brown, and Shacham in order to provide a method that teaches identification of global I/O request to a peripheral device. The motivation for applying Ogasawara teaching with O’Dowd, Brown, and Shacham teaching is to provide a method that allows for interception of requests, inspection of requests, and determination of request intent, such that enables intrusion prevention of malicious I/O request that do not comply with device specification (Ogasawara, Abstract). O’Dowd, Brown, Shacham, and Ogasawara are analogous art directed towards hypervisor-specific management and security arrangements for peripheral components. Therefore, it would have been obvious for one of ordinary skill in the art to combine Ogasawara with O’Dowd, Brown, and Shacham to teach the claimed invention in order to provide I/O request inspection in order enable request filtering to defend against hypervisor vulnerabilities in device emulation.
With regard to claim 10, O’Dowd teaches a non-transitory computer readable medium comprising instructions which, when executed by a processor, enables the processor to perform a method for processing a function command for a peripheral device, the method comprising (Abstract, An adjunct I/O virtualization may also be included to abstract the guarded input peripheral interfaces, such that all attempts to turn them on from within the operating system are automatically redirected by the I/O virtualization mechanism to the peripheral control domain; [0026], As described in detail above, computing device 200 may perform operations based on software instructions that may be read into memory 210 from another computer-readable medium, such as data storage 220, or from another device via communication interface 235):
obtaining, by a device controller intermediary ([0016], In certain embodiments, a portable computing device is disclosed comprising: … an I/O virtualization mechanism configured to be interposed between the operating system domain and the peripheral control domain), a function command from a virtual machine, wherein the function command is associated with a peripheral device ([0018], Receiving an input peripheral access request from at least one portable device operating system).
performing a lookup, in a function policy database to identify an emulated function policy associated with the function command ([0016], The peripheral control domain may comprise: a physical peripheral control component; and a policy component for deciding how to handle input peripheral requests originating from the operating system);
making a determination that the function command does not violate the emulated function policy ([0016], The policy component may be configured to perform a local, autonomous decision regarding whether to allow input peripheral access based at least in part on at least one detectable condition. The at least one detectable condition may comprise at least one of a geolocation, one or more fixed policy settings, and an active connection to a trusted network), …; and
in response to the determination ([0014], The peripheral control 130 may then conduct a policy-driven decision process via peripheral access policy module 140 to either allow, disallow, or request manual/explicit authorization of these access attempts):
forwarding the function command to the peripheral device ([0014], If access is permitted, such physical access may be performed by physical peripheral control domain 130)
O’Dowd reasonably teaches portable computing devices comprising a machine virtualization module (O’Dowd, [0016]) and an operating system issuing a request to access the peripheral (O’Dowd, Abstract). However, O’Dowd does not explicitly teach the function command request is from a virtual machine.
Ogasawara teaches a function command from a virtual machine (Pg. 545, Figure 3, Request made from Guest VMs; Pg. 545, 4.1 Architectural Overview, We introduce an additional layer between guest VMs and virtual devices. Figure 3 shows the architectural overview of Nioh. Regarding an original hypervisor (a), I/O requests issued by guest VMs directly reach virtual devices without any inspections. Regarding a hypervisor with Nioh (b), however, all requests are inspected using Nioh before reaching virtual devices; Pg. 548, 4.4 Implementation, To apply Nioh with KVM+QEMU, we add some hooks to the QEMU. When an I/O request to virtual devices occurs in a guest VM, a CPU issues VMExit with sorting I/O request information into VM-exit information fields of the VM control structure (VMCS)
wherein the emulated function policy specifies prohibited function operations (Pg. 545, To distinguish illegal I/O requests from benign ones, Nioh models a device specification as a device automaton. Hardware devices have states in which the device is either waiting for an I/O command, executing an I/O command, or waiting for interrupts In each state, a device specification denotes what types of I/O requests are valid and acceptable), including:
power cycling the peripheral device;
allocating already-allocated virtual functions (Pg. 544-545, Figure 2 shows how to exploit a hypervisor using VENOM vulnerability in the READ_ID command. The blue liens are legal operations and red lines are illegal operations in this command. After the command code and associated parameters are written in the command phase, QEMU’s virtual FDC makes a transition to the execution phase. Before asserting an interrupt, the virtual FDC sets a timer to emulate the delay in the hardware FDC that corresponds to seek latency. The FDC specification forbids the FIFO buffer from being accessed in the execution phase, in which the READ_ID command is executed. In fact, the MSR indicates that the FDC is busy in this phase. However, the virtual FDC allows the access to the FIFO buffer, and resulting in the buffer overflow (Examiner notes: such that a buffer overflow attack is an allocation of already-allocated memory) … Our approach filters out illegal I/O requests before they reach virtual devices);
changing properties of the peripheral device that would affect all virtual functions (Pg. 542, Device emulation is a hotbed of vulnerabilities in hypervisors … VENOM [11] in 2015 is a vulnerability in a QEMU emulated floppy disk controller (FDC). VENOM results in VM Escape because attackers can gain a hypervisor’s privilege and run arbitrary code in the hypervisor (Examiner notes: wherein the privilege escalation of hypervisor affects all virtual functions) … Nioh inspects I/O requests VMs and rejects those that violate the device specification. For example … the FDC must not accept I/O requests that access the FIFO buffer when executing READ_ID or DRIVE_SPECIFICATION_COMMAND)
Rationale to claim 1 applied here.
However, the combination does not explicitly teach the performance of a function command resulting in a function operation from a set of function operations.
Brown teaches wherein the function command results in a function operation of a set of function operations, wherein the set of function operations comprises ([0073], FIG. 8A is an exemplary diagram illustrating a definition of a set of exemplary CRQ hypervisor events in accordance with one illustrative embodiment; [0088], FIG. 9 is an exemplary diagram illustrating a definition of a set of exemplary Logical Partition (LPAR) to platform firmware calls in accordance with one illustrative embodiment):
toggling power to the peripheral device ([0105], The hypervisor 625 and IMP 603 may also be informed by the HMC 609 when to power up and power down an I/O adapter or endpoint. This may be accomplished through the power up/down IOA request 1010);
toggling one or more functionalities of the peripheral device ([0108], The dynamic add/remove of a VF request 1016 to an IMP 603 informs the IMP 603 to add or remove the resources for a VF, e.g., the CRQ mechanism and any supporting structures necessary to support a specific VF, and to begin or terminate communications with the client partition 604 via the CRQ mechanism that there is a VF available to be added or that is time to remove a VF that was previously allocated to that client partition 604);
changing a mode of the peripheral device ([0081], The “Enable Load/Store to VF” request 822 requests that the IMP 603 allow the unblocking of MMIO Load and Store operations to the VF, as when the VF is in an error state (Examiner notes: where state used herein is substantially similar to the operating mode of the peripheral device);
partitioning resources of the peripheral device ([0074], As shown in FIG. 8A, “the partner partition connected” event 802 is a way for the hypervisor, e.g., hypervisor 625 in FIG. 6, to inform the IMP, e.g., IMP 603 in FIG. 6, and client partition, e.g., client partition 604 in FIG. 6, that both ends of the connection between the IMP 603 and a client partition 604 are ready);
creating a virtual function ([0106], There are several HMC to platform requests 1012-1016 that are used by the HMC to direct the dynamic addition of an IOV adapter 615 to the system 601 or VF to a client partition 604, i.e. while the system is operational and after initial configuration. The dynamic assignment of an IOV adapter requests 1012 is used by the HMC 609 to inform the hypervisor 625 to allocate an IOV adapter 614 to an IMP 603 along with the system resources necessary to operate that adapter; [0107], Once the hypervisor 625 has completed the dynamic add of an IOV adapter request 1012, the IMP 603 may be informed of any additions. The dynamic add of an IOV adapter to an IMP request 1014 informs the IMP 603 that a new IOV adapter 614 to be added);
process input/output requests to utilize the peripheral device ([0089], as shown in FIG. 9, the add command (request) or response to CRQ of partner LPAR call 902 is a call used to send a command/request or response to the CRQ 607 or 608. This call may be used by the client partitions 604 and the IMP 603); and
changing global settings of the peripheral device ([0078], The client to IMP requests in FIG. 8B further include a configuration request 814 which is used by the client partition 604 to get the IMP 603 to perform a configuration read operation on the configuration space of the VFs and PFs of the IOV enabled adapter/endpoint 614 … Similarly, the client to IMP requests further include configuration write requests 816 which is used by the client partition 604 to get the IMP 603 to perform a configuration write operation to the configuration space of VFs and PFs of the IOV enabled endpoint 614)
Rationale to claim 1 applied here.
The combination reasonably teaches filtering of prohibited function operations through command inspection associated with function policy of a device (Ogasawara. Pg. 546). However, the combination does not explicitly teach that a prohibited function operation including power cycling the peripheral device.
Shacham teaches power cycling the peripheral device ([0034], The MHPC 232 in some aspects mays also include an MHPC control register 304 that is used by virtualization management software (such as VMM 108, as a non-limiting example) to indicate which of the I/O clients 104(0)-104(N) are permitted to vote for power mode control of the flash-memory-based storage device 106 … power mode change requests for one of the I/O clients 104(0)-104(N) that is not permitted to vote for power control are “trapped”) which is substantially similar to claim 1 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 1 is being substantially recited again as limitations for the non-transitory computer readable medium of claim 10.
With regard to claim 11, Ogasawara teaches the non-transitory computer readable medium of claim 10, wherein the function command is received at an emulated physical function of the device controller intermediary (Pg. 547, 4.3 Nioh’s Framework, To determine to which state to make a transition, Nioh must determine what value is read from or written to device registers. In read requests, Nioh cannot obtain the value before emulation in virtual devices. Thus, after the emulation in a virtual device, Nioh intercepts the control and obtains a value read from the device register. This flow is shown with the red lines in Figure 6) which is substantially similar to claim 2 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 2 is being substantially recited again as limitations for the non-transitory computer readable medium of claim 11.
With regard to claim 12, Ogasawara teaches the non-transitory computer readable medium of claim 11, wherein the function command is forwarded to a physical function of the peripheral device (Pg. 546, 4.2 Filtering Model, Nioh inspects every request from the guest OS. If the current state has a transition that matches the request, the request is considered legal and is forwarded to the virtual device), wherein the physical function is associated with the emulated physical function (Pg. 547, 4.3 Nioh’s Framework, When Nioh receives I/O request information containing an address, value, and direction (e.g., read or write) of I/O, it creates an operation_info object from the information and passes it to the device_manager object. The device_manager looks up a device object corresponding to the operation_info and request the inspection to the device object … To inspect the I/O request, Nioh must determine which device the I/O request is for. The device_manager object is responsible for this task. The device_manager object has maps from the PIO port addresses, MMIO addresses and IRQ numbers to device objects) which is substantially similar to claim 3 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 3 is being substantially recited again as limitations for the non-transitory computer readable medium of claim 12.
With regard to claim 16, O’Dowd teaches the non-transitory computer readable medium of claim 10, wherein after forwarding the function command to the peripheral device, the method further comprises:
obtaining a second function command from a second virtual machine (Abstract, An adjunct I/O virtualization may also be included to abstract the guarded input peripheral interfaces, such that all attempts to turn them on from within the operating system are automatically redirected by the I/O virtualization mechanism to the peripheral control domain; [0016], In certain embodiments, a portable computing device is disclosed comprising: … an I/O virtualization mechanism configured to be interposed between the operating system domain and the peripheral control domain; [0005], Portable device operating systems employ a number of security controls aimed at preventing unauthorized manipulation of input peripherals (Examiner notes: a plurality of machines transmitting a plurality of request attempts to a plurality of peripherals); [0030], While the above description contains many specifics, these should not be construed as limitations on the scope of the invention, but rather as an exemplification of certain embodiments thereof. The invention includes any combination or subcombinations of the elements from the different species and/or embodiments disclosed herein (Examiner notes: The disclosure is not limited to only a single computing instance attempting a single peripheral access request), wherein the function command is associated with a peripheral device ([0018], Receiving an input peripheral access request from at least one portable device operating system);
performing a second lookup, in a function policy database to identify a second emulated function policy associated with the second function command ([0016], The peripheral control domain may comprise: a physical peripheral control component; and a policy component for deciding how to handle input peripheral requests originating from the operating system);
making a second determination that the function command does not violate the second emulated function policy ([0016], The policy component may be configured to perform a local, autonomous decision regarding whether to allow input peripheral access based at least in part on at least one detectable condition. The at least one detectable condition may comprise at least one of a geolocation, one or more fixed policy settings, and an active connection to a trusted network); and
in response to the determination ([0014], The peripheral control 130 may then conduct a policy-driven decision process via peripheral access policy module 140 to either allow, disallow, or request manual/explicit authorization of these access attempts):
O’Dowd reasonably teaches portable computing devices comprising a machine virtualization module (O’Dowd, [0016]). However, O’Dowd does not explicitly teach the function command request is from a virtual machine. Further, O’Dowd does not explicitly teach the second iteration of the method of a second function command from a second virtual machine.
Ogasawara teaches obtaining a second function command from a second virtual machine (FIG. 1 and FIG. 3, Plurality of VMs performing request to peripheral devices; Pg. 542, Introduction, Virtualization allows many VMs to run on a single physical machine in an isolated manner. To give an illusion that there are many virtual devices, a hypervisor multiplexes a physical hardware device and mediates access from multiple VMs; Pg. 543, Introduction, To demonstrate the effectiveness of Nioh, we have implemented a prototype of Nioh in Rust [8], a type-safe language, for KVM + QEMU. The use of a type-safe language improves the overall security of Nioh. The prototype provides a software framework that encapsulates the interactions between device automata and the underlying hypervisors. This separation enhances the reusability of the device automaton (Examiner notes: Performance of the method can be repeated for a plurality of VMs and peripheral devices)
Rationale to claim 7 applied here.
Examiner notes: It would be obvious for one of ordinary skill in the art to understand how to apply the teachings of Ogasawara to multiple attempts by multiple computing instances with operating systems.
Further still, O’Dowd reasonably teaches policy-driven access control to peripheral devices (O’Dowd, [0014]). However, O’Dowd does not explicitly disclose rejecting a second function command.
Ogasawara teaches rejecting the second function command (Pg. 545, Figure 3: Architectural Overview, Hypervisor with Nioh depicts rejection of invalid request; Pg. 543, When an I/O request is issued from a VM, the automaton checks if the request matches the outgoing edges. If there is a match, the request is accepted and passed to a device emulator. Otherwise, it is filtered out, and the issuing VM is destroyed) which is substantially similar to claim 8 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 8 is being substantially recited again as limitations for the non-transitory computer readable medium of claim 16.
With regard to claim 17, Ogasawara teaches the non-transitory computer readable medium of claim 16, wherein the second determination comprises:
identifying that a function operation, of the function command, specifies making a global change to the peripheral device (Pg. 544, 2.3 Example Vulnerability: VENOM, VENOM allows attackers in guest VMs to execute arbitrary code in a hypervisor by exploiting the buffer overflow vulnerability in the FDC’s FIFO buffer. This vulnerability arises from wrong emulation that does not follow the device specification. When the FDC is executing READ_ID or DRIVE_SPECIFICATION_COMMAND commands, the hardware FDC rejects I/O requests that write data into its FIFO buffer. However, the QEMU’s emulated FDC accepts those request when those commands are executed and does not check the index of its FIFO buffer (Examiner notes: The I/O requests specify global change to the peripheral device); Pg. 545, 2.3 Example Vulnerability: VENOM, The problem behind VENOM is the mis-emulation of the hardware device; the virtual FDC accepts illegal I/O requests that do not follow the FDC’s specification. Our approach (Examiner notes: Identify invalid global I/O requests) filters out illegal I/O request before they reach virtual devices. Generally, a software module is extensively tested for expected inputs but not sufficiently tested for unexpected or invalid inputs. Nioh rejects unexpected or invalid inputs to virtual devices) which is substantially similar to claim 9 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 9 is being substantially recited again as limitations for the non-transitory computer readable medium of claim 17.
With regard to claim 18, O’Dowd teaches a computing device, comprising (Abstract, An adjunct I/O virtualization may also be included to abstract the guarded input peripheral interfaces, such that all attempts to turn them on from within the operating system are automatically redirected by the I/O virtualization mechanism to the peripheral control domain; [0023], FIG. 2 is an exemplary diagram of a computing device 200 that may be used to implement aspects of certain embodiments of the present invention):
a processor ([0023], Computing device 200 may include … one or more processors 205); and
memory storing instructions which, when executed by the processor, enables the processor to perform a method for processing a function command for a peripheral device, the method comprising ([0024], Processor 205 may include any type of conventional processor, microprocessor, or processing logic that interprets and executes instructions. Main memory 210 may include a random-access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processor 205):
obtaining, by a device controller intermediary ([0016], In certain embodiments, a portable computing device is disclosed comprising: … an I/O virtualization mechanism configured to be interposed between the operating system domain and the peripheral control domain), a function command from a virtual machine, wherein the function command is associated with a peripheral device ([0018], Receiving an input peripheral access request from at least one portable device operating system).
performing a lookup, in a function policy database to identify an emulated function policy associated with the function command ([0016], The peripheral control domain may comprise: a physical peripheral control component; and a policy component for deciding how to handle input peripheral requests originating from the operating system);
making a determination that the function command does not violate the emulated function policy ([0016], The policy component may be configured to perform a local, autonomous decision regarding whether to allow input peripheral access based at least in part on at least one detectable condition. The at least one detectable condition may comprise at least one of a geolocation, one or more fixed policy settings, and an active connection to a trusted network), …; and
in response to the determination ([0014], The peripheral control 130 may then conduct a policy-driven decision process via peripheral access policy module 140 to either allow, disallow, or request manual/explicit authorization of these access attempts):
forwarding the function command to the peripheral device ([0014], If access is permitted, such physical access may be performed by physical peripheral control domain 130)
O’Dowd reasonably teaches portable computing devices comprising a machine virtualization module (O’Dowd, [0016]) and an operating system issuing a request to access the peripheral (O’Dowd, Abstract). However, O’Dowd does not explicitly teach the function command request is from a virtual machine.
Ogasawara teaches a function command from a virtual machine (Pg. 545, Figure 3, Request made from Guest VMs; Pg. 545, 4.1 Architectural Overview, We introduce an additional layer between guest VMs and virtual devices. Figure 3 shows the architectural overview of Nioh. Regarding an original hypervisor (a), I/O requests issued by guest VMs directly reach virtual devices without any inspections. Regarding a hypervisor with Nioh (b), however, all requests are inspected using Nioh before reaching virtual devices; Pg. 548, 4.4 Implementation, To apply Nioh with KVM+QEMU , we add some hooks to the QEMU. When an I/O request to virtual devices occurs in a guest VM, a CPU issues VMExit with sorting I/O request information into VM-exit information fields of the VM control structure (VMCS))
wherein the emulated function policy specifies prohibited function operations (Pg. 545, To distinguish illegal I/O requests from benign ones, Nioh models a device specification as a device automaton. Hardware devices have states in which the device is either waiting for an I/O command, executing an I/O command, or waiting for interrupts In each state, a device specification denotes what types of I/O requests are valid and acceptable), including:
power cycling the peripheral device;
allocating already-allocated virtual functions (Pg. 544-545, Figure 2 shows how to exploit a hypervisor using VENOM vulnerability in the READ_ID command. The blue liens are legal operations and red lines are illegal operations in this command. After the command code and associated parameters are written in the command phase, QEMU’s virtual FDC makes a transition to the execution phase. Before asserting an interrupt, the virtual FDC sets a timer to emulate the delay in the hardware FDC that corresponds to seek latency. The FDC specification forbids the FIFO buffer from being accessed in the execution phase, in which the READ_ID command is executed. In fact, the MSR indicates that the FDC is busy in this phase. However, the virtual FDC allows the access to the FIFO buffer, and resulting in the buffer overflow (Examiner notes: such that a buffer overflow attack is an allocation of already-allocated memory) … Our approach filters out illegal I/O requests before they reach virtual devices);
changing properties of the peripheral device that would affect all virtual functions (Pg. 542, Device emulation is a hotbed of vulnerabilities in hypervisors … VENOM [11] in 2015 is a vulnerability in a QEMU emulated floppy disk controller (FDC). VENOM results in VM Escape because attackers can gain a hypervisor’s privilege and run arbitrary code in the hypervisor (Examiner notes: wherein the privilege escalation of hypervisor affects all virtual functions) … Nioh inspects I/O requests VMs and rejects those that violate the device specification. For example … the FDC must not accept I/O requests that access the FIFO buffer when executing READ_ID or DRIVE_SPECIFICATION_COMMAND)
Rationale to claim 1 applied here.
However, the combination does not explicitly teach the performance of a function command resulting in a function operation from a set of function operations.
Brown teaches wherein the function command results in a function operation of a set of function operations, wherein the set of function operations comprises ([0073], FIG. 8A is an exemplary diagram illustrating a definition of a set of exemplary CRQ hypervisor events in accordance with one illustrative embodiment; [0088], FIG. 9 is an exemplary diagram illustrating a definition of a set of exemplary Logical Partition (LPAR) to platform firmware calls in accordance with one illustrative embodiment):
toggling power to the peripheral device ([0105], The hypervisor 625 and IMP 603 may also be informed by the HMC 609 when to power up and power down an I/O adapter or endpoint. This may be accomplished through the power up/down IOA request 1010);
toggling one or more functionalities of the peripheral device ([0108], The dynamic add/remove of a VF request 1016 to an IMP 603 informs the IMP 603 to add or remove the resources for a VF, e.g., the CRQ mechanism and any supporting structures necessary to support a specific VF, and to begin or terminate communications with the client partition 604 via the CRQ mechanism that there is a VF available to be added or that is time to remove a VF that was previously allocated to that client partition 604);
changing a mode of the peripheral device ([0081], The “Enable Load/Store to VF” request 822 requests that the IMP 603 allow the unblocking of MMIO Load and Store operations to the VF, as when the VF is in an error state (Examiner notes: where state used herein is substantially similar to the operating mode of the peripheral device);
partitioning resources of the peripheral device ([0074], As shown in FIG. 8A, “the partner partition connected” event 802 is a way for the hypervisor, e.g., hypervisor 625 in FIG. 6, to inform the IMP, e.g., IMP 603 in FIG. 6, and client partition, e.g., client partition 604 in FIG. 6, that both ends of the connection between the IMP 603 and a client partition 604 are ready);
creating a virtual function ([0106], There are several HMC to platform requests 1012-1016 that are used by the HMC to direct the dynamic addition of an IOV adapter 615 to the system 601 or VF to a client partition 604, i.e. while the system is operational and after initial configuration. The dynamic assignment of an IOV adapter requests 1012 is used by the HMC 609 to inform the hypervisor 625 to allocate an IOV adapter 614 to an IMP 603 along with the system resources necessary to operate that adapter; [0107], Once the hypervisor 625 has completed the dynamic add of an IOV adapter request 1012, the IMP 603 may be informed of any additions. The dynamic add of an IOV adapter to an IMP request 1014 informs the IMP 603 that a new IOV adapter 614 to be added);
process input/output requests to utilize the peripheral device ([0089], as shown in FIG. 9, the add command (request) or response to CRQ of partner LPAR call 902 is a call used to send a command/request or response to the CRQ 607 or 608. This call may be used by the client partitions 604 and the IMP 603); and
changing global settings of the peripheral device ([0078], The client to IMP requests in FIG. 8B further include a configuration request 814 which is used by the client partition 604 to get the IMP 603 to perform a configuration read operation on the configuration space of the VFs and PFs of the IOV enabled adapter/endpoint 614 … Similarly, the client to IMP requests further include configuration write requests 816 which is used by the client partition 604 to get the IMP 603 to perform a configuration write operation to the configuration space of VFs and PFs of the IOV enabled endpoint 614)
Rationale to claim 1 applied here.
The combination reasonably teaches filtering of prohibited function operations through command inspection associated with function policy of a device (Ogasawara. Pg. 546). However, the combination does not explicitly teach that a prohibited function operation including power cycling the peripheral device.
Shacham teaches power cycling the peripheral device ([0034], The MHPC 232 in some aspects mays also include an MHPC control register 304 that is used by virtualization management software (such as VMM 108, as a non-limiting example) to indicate which of the I/O clients 104(0)-104(N) are permitted to vote for power mode control of the flash-memory-based storage device 106 … power mode change requests for one of the I/O clients 104(0)-104(N) that is not permitted to vote for power control are “trapped”) which is substantially similar to claim 1 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 1 is being substantially recited again as limitations for the computing device of claim 18.
With regard to claim 19, Ogasawara teaches the computing device of claim 18, wherein the function command is received at an emulated physical function of the device controller intermediary (Pg. 547, 4.3 Nioh’s Framework, To determine to which state to make a transition, Nioh must determine what value is read from or written to device registers. In read requests, Nioh cannot obtain the value before emulation in virtual devices. Thus, after the emulation in a virtual device, Nioh intercepts the control and obtains a value read from the device register. This flow is shown with the red lines in Figure 6) which is substantially similar to claim 2 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 2 is being substantially recited again as limitations for the computing device of claim 19.
With regard to claim 20, Ogasawara teaches the computing device of claim 19, wherein the function command is forwarded to a physical function of the peripheral device, wherein the physical is associated with the emulated physical function (Pg. 547, 4.3 Nioh’s Framework, When Nioh receives I/O request information containing an address, value, and direction (e.g., read or write) of I/O, it creates an operation_info object from the information and passes it to the device_manager object. The device_manager looks up a device object corresponding to the operation_info and request the inspection to the device object … To inspect the I/O request, Nioh must determine which device the I/O request is for. The device_manager object is responsible for this task. The device_manager object has maps from the PIO port addresses, MMIO addresses and IRQ numbers to device objects) which is substantially similar to claim 3 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 3 is being substantially recited again as limitations for the computing device of claim 20.
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over O'Dowd in view of Ogasawara in view of Brown in view of Shacham as applied to claim 2 and 11 respectively above, and further in view of Tameshige et al. Pub. No. US 2013/0346584 A1 (hereinafter Tameshige).
With regard to claim 4, Tameshige teaches the method of claim 2, wherein the function policy database comprises a function entry wherein the function entry comprises the emulated function policy ([0124], FIG. 12 shows the command management table 227. The command management table 227 defines operations corresponding to commands issued by the system administrator from an input apparatus (not shown); [0127], A column 1202 stores contents of the commands. A column 1203 stores operations corresponding to the commands in column 1202. As a result, such definitions as restraining the command execution and permitting the command execution can be made) and an emulated function identifier associated with the emulated physical function ([0126], A column 1201 stores command identifiers 1201. The identifier only needs to identify a command, and an original identifier may be generated and stored, or may be an UUID or the like).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tameshige with the teachings of O’Dowd, Ogasawara, Brown, and Shacham in order to provide a method that teaches a policy database defining a policy and emulated function identifier. The motivation for applying Tameshige teaching with of O’Dowd, Ogasawara, Brown, and Shacham teaching is to provide a method that allows for management of command executed on devices, such that enables user-defined compliance and security of transmitted commands, particularly to commands causing changes in state (Tameshige, [0125]). O’Dowd, Ogasawara, Brown, Shacham and Tameshige are analogous art directed towards hypervisor-specific management. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tameshige with of O’Dowd, Ogasawara, Brown, and Shacham to teach the claimed invention in order to provide a framework for implementing function command inspection in accordance to rules and regulations set forth by regulation and security best practices.
With regard to claim 13, Tameshige teaches the non-transitory computer readable medium of claim 11, wherein the function policy database comprises a function entry, wherein the function entry comprises the emulated function policy ([0124], FIG. 12 shows the command management table 227. The command management table 227 defines operations corresponding to commands issued by the system administrator from an input apparatus (not shown); [0127], A column 1202 stores contents of the commands. A column 1203 stores operations corresponding to the commands in column 1202. As a result, such definitions as restraining the command execution and permitting the command execution can be made) and an emulated function identifier associated with the emulated physical function ([0126], A column 1201 stores command identifiers 1201. The identifier only needs to identify a command, and an original identifier may be generated and stored, or may be an UUID or the like) which is substantially similar to claim 4 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 4 is being substantially recited again as limitations for the non-statutory computer readable medium of claim 13.
Claims 5-6 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over O'Dowd in view of Ogasawara in view of Brown in view of Shacham as applied to claim 1 and 10 respectively above, and further in view of Tsirkin Pub. No. US 2023/0409367 A1 (hereinafter Tsirskin).
With regard to claim 5, Tsirkin teaches the method of claim 1, wherein the function command specifies a function operation to generate a virtual function on the peripheral device ([0019], When the virtual machine 122 is deployed, the virtualized layer may include a virtual page table 128 for the physical function 138 and virtual page table entries 130a-b for potential virtual functions 146 that correspond to the pre-allocated page table 112 and page table entries 114a-b. This can allow the virtual machine 122 to be aware of pre-allocated memory for creating and removing virtual functions 146 with the virtualized layer. The virtual machine 122 may send a request to create a virtual function 146).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tsirkin with the teachings of O’Dowd, Ogasawara, Brown, and Shacham in order to provide a method that teaches a function command specified for generating a virtual function of the peripheral device. The motivation for applying Tsirkin teaching with O’Dowd, Ogasawara, Brown, and Shacham teaching is to provide a method that allows for virtual machines to associated with a virtual function wherein the virtual function serves as an interface for the virtual machines to obtain peripheral device resources such that provides scalability (Tsirkin, [0012]). O’Dowd, Ogasawara, Brown, Shacham, and Tsirkin are analogous art directed towards hypervisor-specific management. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tsirkin with O’Dowd, Ogasawara, Brown, and Shachato teach the claimed invention in order to provide efficient resource allocation through partitioning of peripheral device resources into virtual function accessible to requesting virtual machines.
With regard to claim 6, Tsirkin teaches the method of claim 5, wherein after the forwarding the function command to the peripheral device, the method further comprises:
generating an emulated virtual function with the virtual function ([0019], For example, the virtual machine 122 may send the request to a virtual SR-IOV device in the virtual machine 122. Instead of being received by the virtual SR-IOV device, the request may be intercepted and forwarded to the SR-IOV device 108. In one example, the host hypervisor 118 may intercept and forward the request. The SR-IOV device 108 can create the virtual function 146 using memory in the SR-IOV device 108. The IOMMU can update the page table entry 114 corresponding to the virtual function 146 to include a function number and device memory address in the SR-IOV device 108. The host hypervisor 118 can translate the device memory address into a virtual device memory address to transmit to the virtual machine 122. The virtual machine 122 may use the virtual device memory address to enable the virtual function 146 and may assign the virtual function 146).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tsirkin with the teachings of O’Dowd, Ogasawara, Brown, and Shacham in order to provide a method that teaches generation of an emulated virtual function. The motivation for applying Tsirkin teaching with O’Dowd, Ogasawara, Brown, and Shacham teaching is to provide a method that allows for provisioning of virtual function resources to virtual machines, advantageously using single root input-out virtualization (SR-IOV) capabilities to better distribute peripheral resources while maintaining an isolated environment (Tsirkin, [0001] and [0008]). O’Dowd, Ogasawara, Brown, Shahcham and Tsirkin are analogous art directed towards hypervisor-specific management. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tsirkin with O’Dowd, Ogasawara, Brown, and Shacham to teach the claimed invention in order to provide virtual machines access to peripheral device resources through means of coupling a virtualized instance of the peripheral to obtain resource management and security benefits.
With regard to claim 14, Tsirkin teaches the non-transitory computer readable medium of claim 10, wherein the function command specifies a function operation to generate a virtual function on the peripheral device ([0019], When the virtual machine 122 is deployed, the virtualized layer may include a virtual page table 128 for the physical function 138 and virtual page table entries 130a-b for potential virtual functions 146 that correspond to the pre-allocated page table 112 and page table entries 114a-b. This can allow the virtual machine 122 to be aware of pre-allocated memory for creating and removing virtual functions 146 with the virtualized layer. The virtual machine 122 may send a request to create a virtual function 146) which is substantially similar to claim 5 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 5 is being substantially recited again as limitations for the non-transitory computer readable medium of claim 14.
With regard to claim 15, Tsirkin teaches the non-transitory computer readable medium of claim 14, wherein after forwarding the function command to the peripheral device, the method comprises:
generating an emulated virtual function associated with the virtual function ([0019], For example, the virtual machine 122 may send the request to a virtual SR-IOV device in the virtual machine 122. Instead of being received by the virtual SR-IOV device, the request may be intercepted and forwarded to the SR-IOV device 108. In one example, the host hypervisor 118 may intercept and forward the request. The SR-IOV device 108 can create the virtual function 146 using memory in the SR-IOV device 108. The IOMMU can update the page table entry 114 corresponding to the virtual function 146 to include a function number and device memory address in the SR-IOV device 108. The host hypervisor 118 can translate the device memory address into a virtual dev ice memory address to transmit to the virtual machine 122. The virtual machine 122 may use the virtual device memory address to enable the virtual function 146 and may assign the virtual function 146) which is substantially similar to claim 6 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 6 is being substantially recited again as limitations for the non-transitory computer readable medium of claim 15.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM EST.
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.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195