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 .
DETAILED ACTION
This Office Actions is in response to claims filed 01/23/2023
Claims 1 – 20 are cancelled, claims 21 – 40 are pending.
Claim Objections
Claim 32 is objected to because of the following informalities: “Virtual machine’s ROM”. The examiner suggests to fully spell out the acronym “ROM”.
Appropriate correction is required.
Claim 39 is objected to because of the following informalities: “a read or write I/O operation.”. The examiner suggests to fully spell out the acronym “I/O”.
Appropriate correction is required.
Double Patenting
The non-statutory 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 non-statutory 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 non-statutory 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 non-statutory 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 21 – 40 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1 – 20 of U.S. Patent No. 11,556,458 B2. Although the claims at issue are not identical, they are not patentably distinct from each other as seen below. For brevity:
claims 21 – 27 are show below recite “A method for fuzz testing virtual devices” having similar limitations to “A method for fuzz testing virtual devices” of claims 1 – 7, of U.S. Patent No. 11,556,458 B2.
claims 28 – 34 are show below recite “A non-transitory, computer-readable medium” having similar limitations to “A non-transitory, computer-readable medium” of claims 8 – 12, 18, and 19, of U.S. Patent No. 11,556,458 B2.
claims 35 – 40 are show below recite “A host system for fuzz testing virtual devices” having similar limitations to “A host system for fuzz testing virtual devices” of claims 13 – 17, and 20, of U.S. Patent No. 11,556,458 B2
Current application 18/083,145
US Patent 11,556,458 B2
21. A method for fuzz testing virtual devices, the method including:
receiving, at a virtual machine hosted by a host system, a first operation to be performed against one or more virtual devices,
the first operation populated with one or more parameters;
executing, by a fuzzer module located at the virtual machine, the first operation against the one or more virtual devices using the populated parameters, the fuzzer module configured as firmware on the virtual machine operating independent of the virtual machine's random access memory (RAM); and
sending a request, by the fuzzer module, to a hypervisor for a second operation to be performed against the one or more virtual devices,
wherein an operation table is embedded in the fuzzer module, the operation table including a plurality of operations available to execute against the one or more virtual devices.
1. A method for fuzz testing virtual devices, the method including:
determining, at a hypervisor located on a host system, a first operation to be performed against one or more virtual devices; ......... transmitting the first operation and the populated parameters to a fuzzer module located on a virtual machine hosted by the host system
....... populating, at the hypervisor, one or more parameters of the first operation using a random or pseudorandom input generator; and
the fuzzer module configured as firmware on the virtual machine operating independent of the virtual machine's random access memory (RAM);
executing the first operation, by the fuzzer module, against the one or more virtual devices using the populated parameters; and
sending a request, by the fuzzer module, to the hypervisor for a second operation to be performed against the one or more virtual devices,
wherein an operation table is embedded in the fuzzer module, the operation table including a plurality of operations available to execute against the one or more virtual devices.
22. The method of claim 21,
wherein the populated parameters are generated by a random or pseudorandom input generator.
1. A method for fuzz testing virtual devices, the method including ......
populating, at the hypervisor, one or more parameters of the first operation using a random or pseudorandom input generator;
23. The method of claim 22, wherein the random or pseudorandom input generator is a pseudorandom input generator.
3. The method of claim 1, wherein the random or pseudorandom input generator is a pseudorandom input generator.
24. The method of claim 21, further including, after execution of the first operation by the fuzzer module:
transmitting, from the virtual machine to the hypervisor, in-use space associated with the one or more virtual devices to obtain updated state information associated with the one or more virtual devices.
4. The method of claim 1, further including, after execution of the first operation by the fuzzer module:
querying, by the hypervisor, in-use space associated with the one or more virtual devices to obtain updated state information associated with the one or more virtual devices.
25. The method of claim 24, further including: determining, at the hypervisor, the second operation based at least in part on the updated state information
5. The method of claim 4, further including: determining, at the hypervisor, the second operation based at least in part on the updated state information.
26. The method of claim 21, further including, before determining the first operation:
transmitting, from the virtual machine to the hypervisor, a copy of the operation table embedded in the fuzzer module.
6. The method of claim 1, further including, before determining the first operation:
receiving, at the hypervisor, a copy of the operation table embedded in the fuzzer module; and
storing the copy of the operation table in RAM outside the virtual machine.
27. The method of claim 26, wherein determining the first operation is based at least in part on the copy of the operation table.
7. The method of claim 6, wherein determining the first operation is based at least in part on the copy of the operation table.
28. A non-transitory, computer-readable medium including instructions that, when executed by a processor, performs stages for fuzz testing virtual devices, the stages including:
initializing fuzzer firmware in a virtual machine that operates independent of the virtual machine's random access memory (RAM);
receiving, at the virtual machine, an operation to be performed against one or more virtual devices,
the first operation populated with one or more parameters;
executing, by the fuzzer firmware, the operation against the one or more virtual devices using the populated parameters; and
transmitting a request, by the fuzzer firmware, to a hypervisor for another operation to be performed against the one or more virtual devices,
wherein an operation table is embedded in the fuzzer firmware, the operation table including a plurality of operations available to execute against the one or more virtual devices.
8. A non-transitory, computer-readable medium including instructions that, when executed by a processor, performs stages for fuzz testing virtual devices, the stages including:
initializing fuzzer firmware in a virtual machine that operates independent of the virtual machine's random access memory (RAM);
transmitting a request for an operation from the fuzzer firmware to a hypervisor located at a host system outside the virtual machine;
receiving, at the fuzzer firmware, the operation from the hypervisor, the operation being associated with one or more virtual devices and
including one or more parameters populated using a random or pseudorandom input generator at the hypervisor;
executing the operation, including the populated parameters, by the fuzzer firmware against the one or more virtual devices; and
transmitting a request for another operation from the fuzzer firmware to the hypervisor,
wherein an operation table is embedded in the fuzzer firmware, the operation table including a plurality of operations available to execute against the one or more virtual devices.
29. The non-transitory, computer-readable medium of claim 28, wherein the populated parameters are generated by a random or pseudorandom input generator.
8. including one or more parameters populated using a random or pseudorandom input generator at the hypervisor;
30. The non-transitory, computer-readable medium of claim 28, further including, after executing the operation by the fuzzer firmware:
transmitting, from the virtual machine to the hypervisor, in-use space associated with the one or more virtual devices to obtain updated state information associated with the one or more virtual devices.
18. The non-transitory, computer-readable medium of claim 8, further including, after execution of the first operation by the fuzzer firmware:
querying, by the hypervisor, in-use space associated with the one or more virtual devices to obtain updated state information associated with the one or more virtual devices.
31. The non-transitory, computer-readable medium of claim 30, further including:
determining, at the hypervisor, the another operation based at least in part on the updated state information.
19. The non-transitory, computer-readable medium of claim 18, further including:
determining, at the hypervisor, the another operation based at least in part on the updated state information.
32. The non-transitory, computer-readable medium of claim 28, wherein the fuzzer firmware is implemented in the virtual machine's ROM.
9. The non-transitory, computer-readable medium of claim 8, wherein the fuzzer firmware is implemented in the virtual machine's ROM.
33. The non-transitory, computer-readable medium of claim 32, wherein no operating system is installed on the virtual machine.
10. The non-transitory, computer-readable medium of claim 9, wherein no operating system is installed on the virtual machine.
34. The non-transitory, computer-readable medium of claim 28, wherein the operation received from the hypervisor by the fuzzer firmware is one of the available operations included in the operation table.
12. The non-transitory, computer-readable medium of claim 8, wherein the operation received from the hypervisor by the fuzzer firmware is one of the available operations included in the operation table.
35. A host system for fuzz testing virtual devices, the system including:
a memory storage including a non-transitory, computer-readable medium including instructions; and
a computing device including a processor that executes the instructions to carry out stages including:
receiving, at a virtual machine hosted by a host system, a first operation to be performed against one or more virtual devices,
the first operation populated with one or more parameters;
executing, by a fuzzer module located at the virtual machine, the first operation against the one or more virtual devices using the populated parameters, the fuzzer module configured as firmware on the virtual machine operating independent of the virtual machine's random access memory (RAM); and
sending a request, by the fuzzer module, to a hypervisor for a second operation to be performed against the one or more virtual devices,
wherein an operation table is embedded in the fuzzer module, the operation table including a plurality of operations available to execute against the one or more virtual devices.
13. A host system for fuzz testing virtual devices, the system including:
a memory storage including a non-transitory, computer-readable medium including instructions; and
a computing device including a processor that executes the instructions to carry out stages including:
determining, at a hypervisor located on the host system, a first operation to be performed against one or more virtual devices;
....... transmitting the first operation and the populated parameters to a fuzzer module located on a virtual machine hosted by the host system.....
populating, at the hypervisor, one or more parameters of the first operation using a random or pseudorandom input generator;
the fuzzer module configured as firmware on the virtual machine operating independent of the virtual machine's RAM;
executing the first operation, by the fuzzer module, against the one or more virtual devices using the populated parameters; and
sending a request, by the fuzzer module, to the hypervisor for a second operation to be performed against the one or more virtual devices,
wherein an operation table is embedded in the fuzzer module, the operation table including a plurality of operations available to execute against the one or more virtual devices.
36. The system of claim 35, wherein the populated parameters are generated by a random or pseudorandom input generator.
13. populating, at the hypervisor, one or more parameters of the first operation using a random or pseudorandom input generator;
37. The system of claim 35, wherein the random or pseudorandom input generator includes a file containing random data for populating portions of the first operation.
15. The system of claim 13, wherein the random or pseudorandom input generator includes a file containing random data for populating portions of the first operation.
38. The system of claim 35, wherein no operating system is installed on the virtual machine.
16. The system of claim 13, wherein no operating system is installed on the virtual machine.
39. The system of claim 35, wherein the first operation is a read or write I/O operation.
17. The system of claim 13, wherein the first operation is a read or write I/O operation.
40. The system of claim 35, further including transmitting, from the virtual machine to the hypervisor, a copy of the operation table embedded in the fuzzer module.
20. The system of claim 13, further including: receiving, at the hypervisor, a copy of the operation table embedded in the fuzzer module;
and storing the copy of the operation table in RAM outside the virtual machine.
As per claims 21, while the current application 18/083,145 recites “receiving, at a virtual machine hosted by a host system, a first operation to be performed against one or more virtual devices the first operation populated with one or more parameters;”, and the US Patent 11,556,458 B2 recites “determining, at a hypervisor located on a host system, a first operation to be performed against one or more virtual devices; ......... transmitting the first operation and the populated parameters to a fuzzer module located on a virtual machine hosted by the host system....... populating, at the hypervisor, one or more parameters of the first operation using a random or pseudorandom input generator”, the examiner would like to point out that with the broadest reasonable interpretation, it implies and obvious that when the action of “transmitting ...... to a fuzzer module located on a virtual machine” would read on the “receiving, at a virtual machine”. In addition, while the current application 18/083,145 recites “the first operation populated with one or more parameters;”, and the US Patent 11,556,458 B2 recites “populating, at the hypervisor, one or more parameters of the first operation using a random or pseudorandom input generator;”, the examiner would like to point out that the underline limitation of the US Patent 11,556,458 B2 is similar to the claim 22 of the current application 18/083,145, and since claim 22 depended on claim 21, it would imply that the underline limitation is also within claim 21. Similar analyzations are applied to the claims 28 and 35.
As per claims 24, while the current application 18/083,145 recites “transmitting, from the virtual machine to the hypervisor”, and the US Patent 11,556,458 B2 recites “querying, by the hypervisor”, the examiner would like to point out that with the broadest reasonable interpretation, the two limitations can be equivalent, because both describe the same functional result, which is delivery information from the VM to the hypervisor, and the distinction of which component initiates the transferring does not materially change the scope of the claim. Similar analyzations are applied to the claim 30.
As per claims 26, while the current application 18/083,145 recites “transmitting, from the virtual machine to the hypervisor” and the US Patent 11,556,458 B2 recites “receiving, at the hypervisor”, the examiner would like to point out that with the broadest reasonable interpretation, the two limitations can be equivalent, because both describe the same data transfer event in which information flows from the VM to the hypervisor, with the different being only matter of sender vs receiver. Similar analyzations are applied to the claim 35.
Therefore, while the conflicting claims are not identical, they are 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).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 26, 27, and 37 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 26 recites the limitation "before determining the first operation". There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear where or when the step of “determining the first operation” is recited to be considered as “before”. The independent claim 21 does not disclose the limitation “determining the first operation”.
Regarding claim 27, the claim recites the limitation "determining the first operation". There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear where or when the limitation of “determining the first operation” is recited. The independent claim 21 does not disclose the limitation “determining the first operation”.
Regarding claim 37, the claim recites the limitation "the random or pseudorandom input generator". There is insufficient antecedent basis for this limitation in the claim, as the claim 37 is a dependent claim of the independent claim 35, and the independent claim 35 does not disclose the limitation “random or pseudorandom input generator”. Applicant can change the claim 35 to depend on claim 36 to overcome the rejection.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 23 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claim 23 recites the limitation “wherein the random or pseudorandom input generator is a pseudorandom input generator.”. As claim 23 is depended on claim 22, and claim 22 recites the limitation of “a random or pseudorandom input generator.”. Therefore, claim 23 fails to further limit the subject matter of the claim upon which it depends.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements
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 21, 26, 28, 32, 35, and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Chiou et al. US Pat. No. US 9436491 B1, in further view of LIAO et al. US Pub. No. US 20180144134 A1 (hereafter LIAO) and Cornea et al. US Pub. No. US 20160203016 A1 (hereafter Cornea),
As per claim 21, Chiou teaches the invention substantially as claimed A method for fuzz testing virtual devices, (6 – col 1, lines 61 – 65: “The present invention proposes a computer system and method for testing hardware device based on virtual machine, in which the computer system is allowed to utilize a virtual hardware to simulate operational functions of the peripheral hardware device”) The citation discloses the concept of performing testing on a virtual hardware
executing, by a fuzzer module located at the virtual machine, the first operation against the one or more virtual devices using the populated parameters, the fuzzer module configured as firmware on the virtual machine (e.g. FIG. 2, FIG. 5, 24-25 - Col 7, lines 49 – 64: “Referring to FIG. 5, cooperatively with FIG. 2, there is shown a flow chart of a method for testing hardware device based on virtual machine according to another embodiment of the present invention. When the computer system 100 is intended for testing the virtual hardware 133, step S331 is firstly executed, such that a sequence of test instructions 1530 are issued by the guest driver 153, and the test instructions 1530 are transmitted to the expansion test module 131. Subsequently, in step S333, the test instructions 1530 are transmitted to the virtual hardware 133 by the expansion test module 131. In step S335, after the test instructions 1530 are received, the virtual hardware 133 is allowed to process these test instructions 1530 so as to generate at least one response signal 1330, and this response signal 1330 is then transmitted to the expansion test module 131.” and Col 1, lines 23 – 29: “In the former hardware or firmware development of hardware devices, it is practical for testing personnel to connect a hardware device under development to a host computer, and install a firmware driver of a driving device into the host operating system of the host computer. After that, the driver is used to issue a sequence of test instructions to the hardware device.”) The citation discloses the guest driver 153/fuzzer module, sends the test instruction/operation, to the virtual hardware/virtual device, for testing the virtual hardware. As the test instruction comes from the guest driver for testing the virtual hardware, it implies that the guest driver execute the test indirectly again the virtual hardware. At Col 1, lines 23 – 29 discloses the guest driver could be a firmware, as the guest driver could issue a sequence of test instructions.
and sending a request, by the fuzzer module, to a hypervisor for a second operation to be performed against the one or more virtual devices, (e.g. FIG. 2, FIG. 5, 24-25 - Col 7, lines 49 – 64: “Referring to FIG. 5, cooperatively with FIG. 2, there is shown a flow chart of a method for testing hardware device based on virtual machine according to another embodiment of the present invention. When the computer system 100 is intended for testing the virtual hardware 133, step S331 is firstly executed, such that a sequence of test instructions 1530 are issued by the guest driver 153, and the test instructions 1530 are transmitted to the expansion test module 131. Subsequently, in step S333, the test instructions 1530 are transmitted to the virtual hardware 133 by the expansion test module 131. In step S335, after the test instructions 1530 are received, the virtual hardware 133 is allowed to process these test instructions 1530 so as to generate at least one response signal 1330, and this response signal 1330 is then transmitted to the expansion test module 131.” and Col 2, lines 9 – 10: “a hypervisor comprising an expansion test module” and Col 2, lines 9 – 10: “the virtual machine comprising a guest operating system, the guest operating system comprising a guest driver installed in the guest operating system and used for issuing a sequence of test instructions”) The citation discloses the guest driver 153/fuzzer module, sends the test instruction/operation, to the expansion test module 131. As the expansion test module is a component of the hypervisor, and there are more than one test instructions are sent to the test module, it implies that the second test instruction/operation, are sent to the hypervisor.
wherein an operation table is embedded in the fuzzer module, the operation table including a plurality of operations available to execute against the one or more virtual devices. (FIG. 1, FIG. 2, and Col 5, lines 43 – 48: “When the computer system 101 is intended for testing whether the guest driver 153 is capable of controlling the virtual hardware 133 to operate normally or not, the guest driver 153 is requested to issue a sequence of test instructions 1530. These test instructions 1530 are transmitted to the virtual hardware 133 via the expansion test module 131.”) The citation discloses the guest driver having the test instructions/operation table (used for testing the virtual hardware), locates inside the guest driver.
Chiou fails to teaches the method including: receiving, at a virtual machine hosted by a host system, a first operation to be performed against one or more virtual devices, the first operation populated with one or more parameters; ....... the fuzzer module ...... operating independent of the virtual machine's random access memory (RAM);
LIAO teaches the method including: receiving, at a virtual machine hosted by a host system, a first operation to be performed against one or more virtual devices, the first operation populated with one or more parameters; (e.g. FIG. 2, FIG. 4, and [0047]: In one embodiment, the first testing machine VM1 and the second testing machine VM2 are constructed on the virtual machine management device VMM.” and [0049]: “In step 410, the sample format module 240 receives a to-be tested file and determines a file format of the to-be tested file. The file format indicates the name of the operation system for opening or executing the to-be tested file.” and [0050]: “The sample format module 240 can determine the to-be tested file should be operated by Windows operation system, Linux operation system or other operation system and then notify the central scheduling module 250 to select the correct testing machine to execute the to-be tested file.”) The citation discloses the second testing machine/Virtual machine, comprise sample format module 240 that receive the to-be tested file/operation. As the sample format module 240 is a component of the second testing machine/Virtual machine, it implies that the VM receives the to-be test file. As the sample format module 240 can determine which operating system to operate the to-be testes files, it implies that the one or more parameters are within the to-be tested files.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to combine the method including: receiving, at a virtual machine hosted by a host system, a first operation to be performed against one or more virtual devices, the first operation populated with one or more parameters, as taught in LIAO’s invention into Chiou’s invention because additional feature would improves the fuzz testing process by providing the virtual devices with structured and meaningful input from the start, which allows the fuzzer to more effectively test device behavior, uncover errors, and making the testing faster and more reliable.
Cornea further teaches the fuzzer module ...... operating independent of the virtual machine's random access memory (RAM); (e.g. FIG. 1, [0026]: “In this example, each portion of logical disk 110 may be configured differently and/or comprise different types of storage mediums, e.g., random-access memory (RAM)” and [0035]: “In some embodiments, SROM 102 may include or store VM OS 104 and/or other information usable by VM 1 120 and/or VM 2 122. For example, where SROM 102 is shared by VM 1 120 and VM 2 122, each VM may execute VM OS 104 or instances thereof from SROM 102.”) The citation discloses at FIG. 1 that the VM 120 has the logical disk 110 comprise different portion. At [0026] discloses a portion of the logical disk 110 could be RAM of the VM. As SROM and RAM are located in different portion, it implies that they are independent. At [0035] discloses the SROM is used for storing other information related to the VM 102, which could be used to store the fuzzer module/firmware of the VM, as fuzzer module is taught by Chiou
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to combine the fuzzer module ...... operating independent of the virtual machine's random access memory (RAM), as taught in Cornea’s invention into Chiou’s invention because this would help the system avoids being slowed down or interrupted by memory conflicts or crashes inside the VM, making the fuzz testing more stable and consistent, since the fuzzer can keep operating even if the VM experiences memory errors, leading to more reliable detection of issues in the virtual device.
Regarding claim 26, Chiou, in view of LIAO and Cornea, discloses the method of claim 21, and Chiou further teach further including, before determining the first operation: transmitting, from the virtual machine to the hypervisor, a copy the operation table embedded in the fuzzer module. (FIG. 2, and Col 5, lines 43 – 48: “When the computer system 101 is intended for testing whether the guest driver 153 is capable of controlling the virtual hardware 133 to operate normally or not, the guest driver 153 is requested to issue a sequence of test instructions 1530. These test instructions 1530 are transmitted to the virtual hardware 133 via the expansion test module 131.” and Col 2, lines 9 – 10: “a hypervisor comprising an expansion test module”) The citation discloses the guest driver having the test instructions/operation table (used for testing the virtual hardware), locates inside the guest driver, and is transmitted to the expansion test module. The transmitting of the operation table from the virtual machine to the hypervisor before sending to the virtual hardware, so it implies that the hypervisor must store a copy of the operation table before sending it out to the virtual device.
Regarding claim 28, it is a non-transitory, computer-readable medium claim having similar limitations cited in claim 21, so it is also rejected under the same rational.
Regarding claim 32, Chiou, in view of LIAO and Cornea, discloses the non-transitory, computer-readable medium of claim 28, and Cornea further teaches wherein the fuzzer firmware is implemented in the virtual machine's ROM. (e.g. FIG. 1, [0026]: “In this example, each portion of logical disk 110 may be configured differently and/or comprise different types of storage mediums, e.g., random-access memory (RAM)” and [0035]: “In some embodiments, SROM 102 may include or store VM OS 104 and/or other information usable by VM 1 120 and/or VM 2 122. For example, where SROM 102 is shared by VM 1 120 and VM 2 122, each VM may execute VM OS 104 or instances thereof from SROM 102.”) The citation discloses at FIG. 1 that the VM 120 has the logical disk 110 comprise different portion. At [0026] discloses a portion of the logical disk 110 could be RAM of the VM. As SROM and RAM are located in different portion, it implies that they are independent. At [0035] discloses the SROM is used for storing other information related to the VM 102, which could be used to store the fuzzer module/firmware of the VM, as fuzzer module is taught by Chiou.
Regarding claim 35, it is system claim having similar limitations cited in claim 21, so it is also rejected under the same rational.
Regarding claim 40, it is a system claim having similar limitations cited in claim 26, so it is also rejected under the same rational.
Claims 22, 23, 29, 36, and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Chiou, LIAO, and Cornea, in further view of DELEEUW et al. US Pub. No. US 20160350555 A1 (hereafter DELEEUW)
Regarding claim 22, Chiou, in view of LIAO and Cornea, discloses the method of claim 21, but fail to teach wherein the populated parameters are generated by a random or pseudorandom input generator.
However, DELEEUW teaches the populated parameters are generated by a random or pseudorandom input generator (e.g. [0041]: “In some embodiments, apparatus 300 may comprise a random number generator (RNG) 310. RNG 310 may comprise logic, circuitry, and/or instructions operative to generate random numbers for use by CIMM 308. In various embodiments, RNG 310 may comprise a digital random number generator (DRNG).”)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the populated parameters are generated by a random or pseudorandom input generator, as taught in DELEEUW’s invention into Chiou, LIAO and Cornea’s invention because by ensuring a wider variety of unpredictable inputs, more diverse, and less predictable condition, are applied to the virtual devices, would help to improve the fuzz testing, increase the chances of uncovering hidden errors or weaknesses, and lead to stronger and more through validation.
Regarding claim 23, Chiou, in view of LIAO and Cornea, discloses the method of claim 22, and DELEEUW further teaches wherein the random or pseudorandom input generator is a pseudorandom input generator ([0099]: “In some embodiments, apparatus 1000 may comprise a pseudorandom number generator (PRNG) 1034. In various embodiments, PRNG 1034 may comprise logic, circuitry, and/or instructions operative to generate pseudorandom numbers 1035 based on seeds 1032.”)
Regarding claim 29, it is non-transitory, computer-readable medium claim having similar limitations cited in claim 22, so it is also rejected under the same rational.
Regarding claim 36, it is a system claim having similar limitations cited in claim 22, so it is also rejected under the same rational.
Regarding claim 37, Chiou, in view of LIAO and Cornea, discloses the system of claim 35, and DELEEUW further teaches wherein the random or pseudorandom input generator includes a file containing random data for populating portions of the first operation. ([0099]: “In some embodiments, apparatus 1000 may comprise a pseudorandom number generator (PRNG) 1034. In various embodiments, PRNG 1034 may comprise logic, circuitry, and/or instructions operative to generate pseudorandom numbers 1035 based on seeds 1032. In some embodiments, PRNG 1034 may be operative to generate pseudorandom numbers 1035 by using seeds 1032 as starting seeds for a pseudorandom number generation algorithm.”)
Claims 24 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Chiou, LIAO, and Cornea, in further view of YAMASAKI et al. US Pub. No. US 20110289501 A1 (hereafter YAMASAKI)
Regarding claim 24, Chiou, in view of LIAO and Cornea, discloses the method of claim 21, but fails to teach further including, after execution of the first operation by the fuzzer module: transmitting, from the virtual machine to the hypervisor, in-use space associated with the one or more virtual devices to obtain updated state information associated with the one or more virtual devices.
However, YAMASAKI teaches further including, after execution of the first operation by the fuzzer module: transmitting, from the virtual machine to the hypervisor, in-use space associated with the one or more virtual devices to obtain updated state information associated with the one or more virtual devices. ([0165]: “The cache operation unit 56 queries whether there is the instructed storage area to the virtual device 50. When a notification of the existence of the instructed storage area is received from the virtual device 50, the cache operation unit 56 determines that the attached recording medium 2 is the recording medium 2 to which the unreflected data should be written.”) The citation discloses the concept of the VM designates a storage area for unelected data/in-use space of the virtual device, then transmitted from the VM to the host-side cache operation unit, which queries the virtual device and return the confirmation of the storage area’s existence.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the further including, after execution of the first operation by the fuzzer module: transmitting, from the virtual machine to the hypervisor, in-use space associated with the one or more virtual devices to obtain updated state information associated with the one or more virtual devices, as taught in YAMASAKI’s invention into Chiou, LIAO and Cornea’s invention because the new feature would improve fuzz testing, by allowing the fuzzer to make more informed decisions for the operations, which increases the accuracy and effectiveness of testing while reducing the risk of missing errors caused by outdated device states.
Regarding claim 30, it is non-transitory, computer-readable medium claim having similar limitations cited in claim 24, so it is also rejected under the same rational.
Claims 25 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Chiou, LIAO, Cornea, and YAMASAKI, in further view of JOHANSSON et al. US Pub. No. US 20200151007 A1 (hereafter JOHANSSON)
Regarding claim 25, Chiou, in view of LIAO and Cornea and YAMASAKI, discloses the method of claim 24, but fails to teach further including: determining, at the hypervisor, the second operation based at least in part on the updated state information.
However, JOHANSSON teaches further including: determining, at the hypervisor, the second operation based at least in part on the updated state information. (e.g. abstract: “A method to obscure a control execution flow in a computer program includes initializing a state variable, q, and a switching variable, selecting a code block for execution using a present value of the switching variable, executing the code block, updating the state variable based on a present value of the state variable and a block-dependent constant that is associated with the code block to generate an updated state variable, and by applying a state update function to the updated state variable, and updating the switching variable by processing the state variable through a non-injective output function that generates a new value of the switching variable based on the state variable. The operations of selecting the code block, executing the code block, updating the state variable and updating the switching variable are repeated to control execution flow.“) The citation discloses concept of updating state variable after executing a code block and using that updated state to select the next code block for execution, which is similar to the claim invention wherein the second operation is determined base on updated state information, as both rely on prior execution results for selecting the next action.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the further including: determining, at the hypervisor, the second operation based at least in part on the updated state information, as taught in JOHANSSON’s invention into Chiou, LIAO, Cornea and YAMASAKI’s invention because by allowing each subsequent test to reflect the current condition, the system can improve the effectiveness of the fuzz testing, increase the chances of uncovering hidden errors and ensures that the testing adapts dynamically.
Regarding claim 31, it is non-transitory, computer-readable medium claim having similar limitations cited in claim 25, so it is also rejected under the same rational
Claim 27 is rejected under 35 U.S.C. 103 as being unpatentable over Chiou, LIAO, and Cornea, in further view of Tabuchi et al. US Pat. No. US 6212533 B1 (hereafter Tabuchi)
Regarding claim 27, Chiou, in view of LIAO and Cornea, discloses the method of claim 21, but fails to teach wherein determining the first operation is based at least in part on the copy of the operation table.
However, Tabuchi teaches wherein determining the first operation is based at least in part on the copy of the operation table. (e.g. FIG. 5 and 12-Col 3, lines 35 – 41: “Referring to FIG. 5, the function index 40 pointed by function table pointer 22 has pairs of a function name 41 and a function pointer 42. The function name 41 is referenced to look-up a required function. The function pointer 42 holds an address in a function table 50. The function table 50 stores functions corresponds to the function index 40. These functions are applied to the image data 29.”) The citation discloses the function table/operation table and an index-pointer used to select a function for application, showing that execution is determined based on the table contents, which is similar to the concept of the claim.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein determining the first operation is based at least in part on the copy of the operation table, as taught in Tabuchi’s invention into Chiou, LIAO and Cornea’s invention because this would improve fuzz testing by giving the hypervisor or VMM full visibility of the available operations, it allows the hypervisor to select the operations smarter and more accurate, ensuring that tests are relevant and better uncover potential issues in the virtual device.
Claims 33 and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Chiou, LIAO, and Cornea, in further view of Lin et al. US Pub. No. US 20160154674 A1 (hereafter Lin)
Regarding claim 33, Chiou, in view of LIAO and Cornea, discloses the non-transitory, computer-readable medium of claim 32, but fails to teach wherein no operating system is installed on the virtual machine.
However, Lin teaches wherein no operating system is installed on the virtual machine. ([0037]: “The main difference between the data processing system 300 and the data processing system 200 is that the data processing system 300 comprises a virtual machine 302 which is without a guest operating system.”)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein no operating system is installed on the virtual machine, as taught in Lin’s invention into Chiou, LIAO and Cornea’s invention because this setup helps to reduce overhead and potential interference from OS processes, increase testing speed and reliability, ensure that there are no conflicts between the fuzzer and an OS.
Regarding claim 38, it is non-transitory, computer-readable medium claim having similar limitations cited in claim 32, so it is also rejected under the same rational.
Claim 39 is rejected under 35 U.S.C. 103 as being unpatentable over Chiou, LIAO, and Cornea, in further view of Authement et al. US Pub. No. US 20160179557 A1 (hereafter Authement)
Regarding claim 39, Chiou, in view of LIAO and Cornea, discloses the system of claim 35, but fails to teach wherein the first operation is a read or write I/O operation.
However, Authement teaches wherein the first operation is a read or write I/O operation. (e.g. [0091]: “Some embodiments of the present invention may further include one, or more, of the following features, characteristics and/or advantages: (i) all operations identified as “I/O” operations (such as read or write) are saved to a file if recording is “enabled”.”)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein the first operation is a read or write I/O operation, as taught in Authement’s invention into Chiou, LIAO and Cornea’s invention because by indicating the first operation is a read or write I/O operation, which is the fundamental interactions that are most likely to affect the virtual device behavior, would help to improve fuzz testing to be more effective and relevant, and increase the chances of detecting errors.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 10970196 B1 Described herein are techniques related to the functional testing of a database management system. Functional testing involves various technological approaches to evaluating the features and operation of a database management system. Typically, functional testing involves executing valid test cases to determine if the features of the database are operating as intended. In contrast, testing for security vulnerabilities, particularly using fuzz testing, involves the execution of test cases which are invalid, in the sense that they test the database's reaction to unexpected or nonsensical input, rather than testing the designed features of the database. Because fuzz testing is generally directed to invalid test cases, the techniques associated with it are not typically employed to do functional testing.
US 20190339958 A1 Provided herein are systems, methods, and computer program products for testing a firmware update in a secure virtual environment prior to actually installing the firmware update in a device or system. In one embodiment, a firmware update is received. The system is rebooted after receivi