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 . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
DETAILED ACTION
This Final Office Action is in response Applicant communication filled on 06/23/2026.
Status of Claims
Claims 1,3,9,11,12,16,18, 19 have been amended with by Applicant’s 06/23/2026 amendment
Claims 1-20 are currently pending, under examination and have been rejected as follows.
Response to Amendments / Arguments
Applicant’s 06/23/2026 amendment necessitated new grounds of rejection in this office action.
Response to Applicant’s rebuttal arguments on 35 USC 112 rejections
112 rejections in prior act are withdrawn in view of Applicant’s amendment as suggested.
Response to Applicant’s rebuttal arguments on 35 USC 101 rejection
101 rejection in the prior act is maintained as detailed below.
Remarks 06/23/2026 p.10 ¶5 -p.11 ¶ 1 argues independent Claims 1,9,16 recite a specific technological solution to control and optimize operation of virtual machine operating system in virtualization environment, amended as: “wherein the reconstructed data structure and high-level semantic information are used to generate the write request or the program scheduling request, such that running parameters of the operating system of the virtual machine are accessed or modified through the Hypervisor to optimize an operating strategy of the operating system of the virtual machine, without modification of the operating system of the virtual machine”. Thus, Remarks 06/23/2026 p.11 ¶ 2 argues that the claimed semantic reconstruction is not an end in itself but used to enable subsequent Hypervisor-level write operations and program scheduling operations that control operation of the virtual machine operating system, argued as a specific technological use of the reconstructed semantic information that allegedly changes the operation of the virtual machine and its operating system. Remarks 06/23/2026 p.11 ¶4 argues that the claimed combinations improve the manner in which a Hypervisor interacts with and controls a virtual machine operating system by enabling Hypervisor-level modification of operating-system parameters and scheduling behavior based on reconstructed semantic information. Such improvements are argued as analogous to the types of computer-functionality improvements found eligible in Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016), and are unlike claims directed merely to analyzing information or performing mental processes. Finally, Remarks 06/23/2026 p.12 ¶2 argues that at minimum, the amended claims integrate any alleged abstract idea into a practical application because the claimed method is rooted in a specific virtualization architecture that includes a hypervisor, a virtual machine, memory access operations performed through the Hypervisor, reconstruction of operating-system semantic information outside the virtualization system, and subsequent Hypervisor-level modification and scheduling of operating-system operations. The claims therefore impose meaningful limits on any alleged abstract idea and apply it in a manner that improves operation of a particular technological environment.
Examiner fully considered the Applicant’s rebuttal arguments of the 101 rejection, but respectfully disagrees, finding them unpersuasive by stating that since the following 6 features of:
i. adaptive monitoring of network traffic data,
ii. identifying and characterizing errant electronic files,
iii. automatic transitioning of configuration settings among computer systems,
iv. screening emails and other data files for unwanted content,
v. routing email messages based on specific criteria (rules) and
vi. computer virus screening in a network, as identified by Non-Final Act 03/27/2026 p.6 ¶3-p.7 ¶2 did not preclude the claims to recite the abstract idea in Intellectual Ventures I LLC v Erie Indemnity Co, 711 Fed. Appx. 1012 (Fed Cir 2017) and Tranxition v. Lenovo (United States) Inc. 664 Fed. Appx. 968 (Fed. Cir. 2016), as cited by USPTO’s 35 U.S.C. 101 Examination Guidance and Training Materials, Section C. Information about Judicial Decisions, Subsection 1. Subject Matter Eligibility Court Decisions at respective Rows #21 and #41, it then follows that here, the analogous analysis or “introspection” by referring to, or “reconstructing” “semantic information” in a computer environment, analogous to the one exemplified by MPEP 2106.04(a)(2) III C #2, and recited here throughout independent Claims 1-20, would similarly not preclude the current claims to recite or at minimum to describe or set forth the abstract exception.
The fact that the Applicant has now amended each of said independent Claims 1,9,16 to include a limitation of “receiving a write request or a program scheduling request” followed by a “wherein” clause, does not necessarily render the claims less abstract and eligible, first because according to MPEP 2106.05(f)(2) use of a computer or other machinery to receive, store and transmit data represents mere invocation of such computers or machinery as tools, and second because according to MPEP 2111.04 an “wherein” clause, with recitations similar to intended use or intended result, can be argued to have limited patentable weight given their high level of generality introduced by the following words: “used to”, “such that”, and “without modification”. Specifically, such “wherein” clause is recited at high level of generality, namely “wherein the reconstructed data structure and high-level semantic information” [intended] “used1 to generate the write request or the program scheduling request, such that2 running parameters of the operating system of the virtual machine are accessed or modified through the Hypervisor to optimize an operating strategy of the operating system of the virtual machine, without modification3 of the operating system of the virtual machine” without any technological details on how the optimization occurs and how the modification is prevented.
Given such level of claim breath, and its underlining use of expressions analogous to intended use and/or intended breath at the last “wherein” clause, the Examiner finds that such last “wherein” limitation, as relied by Applicant above at Remarks 06/23/2026 p.10 ¶5 - p.11 ¶ 1, provides little if any of any technological details, and certainly does not provide the requisite amount of technological details needed to demonstrate an actual technological solution.
For example, here, the claims provide no details on “reconstructing” other than being based on a vaguely return[ed] “operation result”, and also provide no technological details on how
“a write request or a program scheduling request” “conforms to the reconstructed data structure and high-level semantic information” and how “the requested write operation or scheduling operation” is perform[ed] “through the Hypervisor” as recited at independent Claim 1 and similarly recited at each of sister independent Claims 19,16. Based on such legal findings, the Examiner submits that, when tested per MPEP 2106.05(f)(1), such recitations do constitute, along with the “wherein” limitation and the recitation of intended use, as introduced by the expression “such that”, and/or intended result, as introduced here by the expressions “to optimize” and “without modification”, an idea of a solution, rather than actual technological details on how the technological solution is performed, in a manner necessitated by MPEP 2106.05(f)(1).
Thus, the Applicant’s allegation at Remarks 06/23/2026 p.11 ¶ 2 that the reconstructed semantic information used to enable subsequent Hypervisor-level write operations and program scheduling operations would somehow control operation of the virtual machine operating system, does not yet raise above the idea of a solution to provide patent eligibility.
Also, the Examiner notes that the claims themselves do not yet recite an actual control operation of the virtual machine operating system as argued by Remarks 06/23/2026 p.11 ¶ 2. While the Applicant points at Remarks 06/23/2026 p.11 ¶3 to the Original Specification ¶ [0026], ¶ [0028]- ¶ [0029], ¶ [0030], the Examiner responds that the “101 inquiry must focus on language of Asserted Claims themselves” as in “Synopsys, Inc. v Mentor Graphics Corp, U.S. Court of Appeals Federal Circuit, No 2015-1599, October 17 2016 2016 BL 344522 839 F3d 1138” citing “Accenture Global Servs., GmbH
PNG
media_image1.png
1
1
media_image1.png
Greyscale
v
PNG
media_image1.png
1
1
media_image1.png
Greyscale
. Guidewire Software, Inc. 728
PNG
media_image1.png
1
1
media_image1.png
Greyscale
F.3d
PNG
media_image1.png
1
1
media_image1.png
Greyscale
1336, 1345 108 USPQ2d 1173 Fed Cir. 2013: admonishing that the important inquiry for a 101 analysis is to look to the claim”, citing “Content Extraction & Transmission LLC
PNG
media_image1.png
1
1
media_image1.png
Greyscale
v.
PNG
media_image1.png
1
1
media_image1.png
Greyscale
Wells Fargo Bank Nat’l Ass’n 776
PNG
media_image1.png
1
1
media_image1.png
Greyscale
F3d
PNG
media_image1.png
1
1
media_image1.png
Greyscale
1343, 1346 113 USPQ2d 1354 (Fed. Cir. 2014): We focus here on whether the claims of the asserted patents fall within the excluded category of abstract ideas”, cert. denied, 136 S Ct 119, 193 L. Ed. 2d 208 2015). This is consistent with MPEP 2103 I.C stating that “claims define the property rights provided by patent, thus require careful scrutiny. The goal of claim analysis is to identify boundaries of protection sought by applicant and to understand how claims relate to and define what applicant indicated is the invention. USPTO personnel must first determine the scope of a claim by thoroughly analyzing the language of claim before determining if claim complies with each statutory requirement for patentability”. Simply said “[T]he name of the game is the claim”.
In conclusion, given the actual recitation of the claims and their high level of generality, as identified above, the Examiner finds that expression “enable subsequent Hypervisor-level write operations and program scheduling operations” as argued above at Remarks 06/23/2026 p.11 ¶2, even if claimed, would at most be equivalent to the expression “apply it”, where such hypervisor, as tested per MPEP 2106.05(f)(2), would represent mere invocation of machinery that would not integrate the abstract exception into a practical appclaition or provide significantly more.
Accordingly, the Examiner reasons that the claims still recite, describe or set forth the abstract exception, with any invocation of machinery such a hypervisor, a virtual machine, memory access operations performed through the hypervisor, etc. as subsequently argued at Remarks 06/23/2026 p.12 ¶2 representing mere tools for application of the abstract idea of reconstructing semantic information without necessarily integrating it into a practical application or providing significantly more than what was already identified as the abstract exception.
Therefore, the Examiner reasons that the claims remain patent ineligible.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Response to Applicant’s rebuttal arguments on 35 USC 102/103 rejections
Remarks 06/23/2026 p.12 ¶4 - p.15 argues none of the prior art teaches or suggests:
- “wherein the reconstructed data structure and high-level semantic information are used to generate the write request or the program scheduling request, such that running parameters of the operating system of the virtual machine are accessed or modified through the Hypervisor to optimize an operating strategy of the operating system of the virtual machine, without modification of the operating system of the virtual machine” as amended at each of independent Claims 1,9,16.
Examiner fully considered the Applicant’s prior art argument but is moot in view of new grounds of rejection. Specifically, Lin et al, US 20150033227 A1 hereinafter Lin still teaches:
- “wherein the reconstructed data structure and high-level semantic information are used to generate the write request or the program scheduling request, such that running parameters of the operating system of the virtual machine are accessed or modified through the Hypervisor to optimize an operating strategy of the operating system of the virtual machine, without modification of the operating system of the virtual machine”
(Lin ¶ [0030] Introspection System keeps transparency to the guest OS in mind (being OS - agnostic), and the system achieve nearly full transparency against an in-guest OS kernel. For example, without any modification, the Introspection System may directly support a number of most recent released Linux kernels. ¶ [0031] 3rd sentence: the VMI-tools provided by Introspection System are generated from trusted OS code and the widely used and tested utilities without any modification; ¶ [0047] 3rd sentences: The end-user may only need to install the corresponding trusted version of in-guest OS on top of secure VM 102 (shipped in the Introspection system) and invoke the commonly used standard utility programs without any modification. For examples at
Lin ¶ [0101] If there is a data write on the redirected data, the Introspection System may perform COW at page level, as it may be desirable to avoid any side effect of the in-guest OS state. This time, the Introspection System may extend one of the reserved bits in page table entries to indicate whether this page is dirty (has been copied) and add one bit to the software STLB entry. Note that this is one of the advantages of instrumenting the VMM [or hypervisor] because the Introspection System may add whatever it wants in the emulated software, such as the STLB, even though the original hardware may not contain such an extension. Meanwhile, for the page table entry, the Introspection System may extend one of the reserved bits to achieve its goal. The Introspection System may also make a shadow page table and extend it with a dirty bit for page entry if there does not exist any reserved bit.
Lin ¶ [0102] If there is a memory write on a, the Introspection System may first check whether STLB [shadow translation lookaside buffer] hits. If so, the Introspection System may check whether the target page is dirty by querying the dirty bit in the STLB entry. If it is, then the Introspection System may directly derive its physical address from the STLB. Otherwise, if the page is not dirty (marked in the STLB entry) or STLB misses, the Introspection System perform the three-layer address translation by querying SCR3 and the page tables. Next, the Introspection System may check if the target page is not dirty (the first time data write on this page). The Introspection System may perform a target page copy and redirect the future access of this page to the new page. In the meantime, the Introspection System may set the dirty bit of the target page table entry and the STLB entry as well. If it is already dirty, the Introspection System does not copy the target pages and sets the STLB entry and the dirty bit. This is because next time any data write to this page will not have a problem as the whole page has already been copied. ¶ Lin ¶ [0105] Next, the Introspection System may perform the redirectable data tracking for i (line 5). That is, check each operand, and update the shadow state. After that, for each memory address access (other than the instruction address) involved in i (line 6), if it is a data read (line 7), the Introspection System may invoke the virtual to physical address translation function to get the corresponding address (line 8), and load the data (line 9). Otherwise (line 10), the Introspection System may check whether the target page is dirty or not (line 11). If not, the Introspection System may perform the COW operation (line 12) and update the page entry dirty bit, copying the page if necessary (line 13). After that, the Introspection System may obtain its physical address (line 14) and perform the write operation (line 15) ).
* While *
Lin ¶ [0024] 4th sentence recites: The introspection routine reconstruct the high level information by interpreting the low level data, and performs security check at ¶ [0102]-[0105] etc.
* Nevertheless *
Lin does not exactly recite that such security check is after introspection or reconstruction,
* However *
Tu in analogous art of automatically bridging semantic gap in machine introspection clarifies that such security check is performed after introspection or reconstruction:
Tu ¶ [0083] 3rd sentence: when a security check is performed after virtual machine introspection [or reconstruction] is triggered, the modified data is to be restored
Accordingly, Lin in view of Tu teaches the contested features.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 1-20 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 pre-AIA the applicant regards as the invention.
Claims 1,9,16, as amended, each recite, among others:
- “reconstructing” / “reconstruct” ,”semantic information based on the operation result, wherein the apparatus is located outside a virtualization system including the Hypervisor,
- “receiving” / … “receive a write request or a program scheduling request that conforms to the reconstructed data structure and high-level semantic information and performing the requested write operation or scheduling operation through the Hypervisor”, “and”
- “wherein the reconstructed data structure and high-level semantic information are used to generate the write request or the program scheduling request, such that running parameters of the operating system of the virtual machine are accessed or modified through the Hypervisor to optimize an operating strategy of the operating system of the virtual machine, without modification of the operating system of the virtual machine.” [bolded emphasis added].
Claims 1,9,16 are rendered vague and indefinite because:
- (i) it is unclear if “the reconstructed data structure” as repeatedly and subsequently recited at the “receiving” / “receive” limitation and the last “wherein” clause of each of independent Claims 1,9,16 above refers back to “semantic information” as antecedently recited at limitation “reconstructing” / “reconstruct”, “semantic information”.
- (ii) while there is antecedent basis for “a write request or a program scheduling request” at the “receiving” / “receive” limitation, there is no antecedent basis for “the” “operation” as in “the requested write operation or scheduling operation” as subsequently recited at the same
“receiving” / “receive” limitation.
- (iii) there is insufficient antecedent basis for “the operating system” as repeatedly recited three times at the “wherein” limitation.
Claims 1,9,16, are recommended to be amended, to each recite, among others, and as an example only:
- reconstructing / reconstruct ,semantic information based on the operation result, wherein the apparatus is located outside a virtualization system including the Hypervisor,
- receiving / … receive a write request or a program scheduling request that conforms to the reconstructed semantic information of the semantic information and performing the requested write or scheduling through the Hypervisor, and
- wherein the reconstructed semantic information the high-level of the semantic information are used to generate the write request or the program scheduling request, such that running parameters of an operating system of the virtual machine are accessed or modified through the Hypervisor to optimize an operating strategy of the operating system of the virtual machine, without modification of the operating system of the virtual machine.
Claims 2-8,10-15,17-20 are dependent and rejected based on rejected parent Claims 1,9,16.
Claims 2,3,10,17,20 each recite, among others: “data structure and high-level semantic information” rendering each of said claims vague and indefinite because it is unclear if “data structure and high-level semantic information” as subsequently recited in said claims, relate back to “data structure and high-level semantic information” as antecedently recited at the amended independent Claims 1,9,16.
Claims 4-8 are dependent and rejected based on rejected parent dependent Claim 3.
Clarifications and/or corrections are required.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea, here abstract idea) without significantly more. The claim(s) recite(s) describe or set forth the abstract implementing virtual machine introspection as summarized at preamble of independent Claims 1,9,16 and detailed throughout the body of Claims 1-20 in a manner not meaningfully different than adaptive monitoring of network traffic data found abstract at claim 2 of USPTO’s example 40. Here, as in Claim 2 of Example 40 other than recitation by Hypervisor of independent Claims 1,16, and the various modules of independent Claim 9, the independent Claims 1,9,16 encompasses “reconstructing semantic information” which sets for the computer-aided cognitive of semantic, syntactic, morphological, phonological or lexical reconstruction of MPEP 2106.04(a)(2) III C. To be clear, USPTO’s 35 U.S.C. 101 Examination Guidance and Training Materials, Section C. Information about Judicial Decisions, Subsection 1. Subject Matter Eligibility Court Decisions, cites at its Row #4 In re Wang Fed. Appx. (Fed Cir. 2018) CAFC Appeal No. 2017-1827 to state that Phonetic symbol system patent ineligible. It then similarly follows that here, the analogous reconstructing of semantic information would follow a similar ineligibility rationale. To be also clear, MPEP 2106.04(a)(2) III C explicitly states that:
# 1. Performing a mental process on a generic computer,
# 2. Performing a mental process in a computer environment, and
# 3. Using a computer as a tool to perform a mental process,
all, do not prelude the claims from reciting the abstract idea.
This is corroborated by USPTO’s 35 U.S.C. 101 Examination Guidance and Training Materials, Section C. Information about Judicial Decisions, Subsection 1. Subject Matter Eligibility Court Decisions at Row #21 citing Intellectual Ventures I LLC v. Erie Indemnity Co., 711 Fed. Appx. 1012 (Fed Cir. 2017), showing that identifying and characterizing errant electronic files, to be ineligible, and at Id. Row # 41 citing Tranxition v. Lenovo (United States) Inc. 664 Fed. Appx. 968 (Fed. Cir. 2016) to show that automatic transitioning of configuration settings among computer systems is ineligible, and finally at Id. Row # Row 55 citing Intellectual Ventures I v. Symantec Corp. 838 F.3d 1307, 120 U.S.P.Q.2d 1353 (Fed. Cir. 2016) to show that screening emails and other data files for unwanted content, and routing email messages based on specific criteria (rules) as well as computer virus screening in a telephone network to be ineligible.
Since the i. adaptive monitoring of network traffic data, ii. identifying and characterizing errant electronic files, iii., automatic transitioning of configuration settings among computer systems, iv. screening emails and other data files for unwanted content, v. routing email messages based on specific criteria (rules) and vi computer virus screening in a telephone network, as identified above, did not preclude the claims from reciting the abstract exception, it then follows that here the analogous virtual machine introspection as recited at independent Claims 1,9,16 and further narrowed at dependent Claims 2-8,10-15,17-20 would similarly not preclude the current claims from reciting or at minimum to describe or set forth the abstract idea.
Thus here, there is a preponderance of legal evidence to show that the character of the claims as a whole is abstract, regardless of the computerized environment where they are executed.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This judicial exception is not integrated into a practical application because per Step 2A prong two, because the individual or combination of additional, computer-based elements are/is found to merely apply the already recited abstract exception, as tested per MPEP 2106.05(f), and/or narrow it to a technological environment or field of use, as tested per MPEP 2106.05(h), neither of which integrates said abstract exception into a practical application.
Here, the degree of automation or computerization identified at the prior step not to preclude the claims from reciting, describing or setting forth the abstract exception. Now, when more granularly testing the additional, computer-based elements at Step 2A prong two, such computer components, including the Hypervisor of independent Claims 1,3, 7-9,11,12,16,18,19 and the various modules of independent Claims 9-12, the independent Claims 1,9,16, represent mere invocation of computer components or machinery to perform tasks to receive, store, and transmit data, which per MPEP 2106.05(f)(2) ¶1, does not integrate the abstract idea into a practical application. Also, when tested per MPEP 2106.05(f)(2)(iii),(v) such additional computer elements merely monitor audit log data executed on a computer components and requiring use of software to tailor information and provide on the computers. Yet MPEP 2106.05(f)(2) is clear that invocation of such computer elements or machinery to apply the aforementioned abstract exception does not integrate the abstract exception into a practical application.
The fact that the Applicant has now amended each of said independent Claims 1,9,16 to include a limitation of “receiving a write request or a program scheduling request” followed by a “wherein” clause, does not necessarily render the claims less abstract and eligible, first because according to MPEP 2106.05(f)(2) use of a computer or other machinery to receive, store and transmit data represents mere invocation of such computers or machinery as tools, and second because according to MPEP 2111.04 an “wherein” clause, with recitations similar to intended use or intended result, can be argued to have limited patentable weight given their high level of generality introduced by the following words: “used to”, “such that”, and “without modification”. Specifically, such “wherein” clause is recited at high level of generality, namely “wherein the reconstructed data structure and high-level semantic information” [intended] “used4 to generate the write request or the program scheduling request, such that5 running parameters of the operating system of the virtual machine are accessed or modified through the Hypervisor to optimize an operating strategy of the operating system of the virtual machine, without modification6 of the operating system of the virtual machine” without any technological details on how the optimization occurs and how the modification is prevented.
Given such level of claim breath, and its underlining use of expressions analogous to intended use and/or intended breath at the last “wherein” clause, the Examiner finds that such last “wherein” limitation, provides little if any of any technological details, and certainly does not provide the requisite amount of technological details needed to demonstrate an actual technological solution. For example, here, the claims provide no details on “reconstructing” other than being based on a vaguely return[ed] “operation result”, and also provide no technological details on how “a write request or a program scheduling request” “conforms to the reconstructed data structure and high-level semantic information” and how “the requested write operation or scheduling operation” is perform[ed] “through the Hypervisor” as recited at independent Claim 1 and similarly recited at each of sister independent Claims 19,16. Based on such legal findings, the Examiner submits that, when tested per MPEP 2106.05(f)(1), such recitations do constitute, along with the “wherein” limitation and the recitation of intended use, as introduced by the expression “such that”, and/or intended result, as introduced here by the expressions “to optimize” and “without modification”, an idea of a solution, rather than actual technological details on how the technological solution is performed, in a manner necessitated by MPEP 2106.05(f)(1).
Accordingly, the Examiner reasons that the claims still recite, describe or set forth the abstract exception, with any invocation of machinery such a hypervisor, a virtual machine, memory access operations performed through the hypervisor, etc. representing mere tools for application of the abstract idea of reconstructing semantic information without necessarily integrating it into a practical application.
Additionally, or alternatively, the level of automation or computerization, identified at Claims 1-20, when tested per MPEP 2106.05(h) vi., can also be argued as a narrowing of the abstract idea to a field of use or technological environment such as narrowing the combination of collecting information and analyzing it, to certain results of collection and analysis, related to a technological environment characterized here by the various elements associated with the “virtual machine introspection”. According to MPEP 2106.05(h), such narrowing of the abstract idea to a field of use or technological environment does not integrate the abstract idea into a practical application.
Thus, Examiner provided a preponderance of legal evidence to show that the automation or computerization elements above do not integrate the abstract idea into a practical application.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because Examiner follows MPEP 2106.05(d) II guidelines and carries over the above findings at MPEP 2106.05 (f) and/or (h) to submit that as shown above, the additional elements, merely apply the already recited abstract idea [MPEP 2106.05(f)] and/or narrow it to a field of use or technological environment [MPEP 2106.05(h)]. For these same reasons, said computer-based additional elements also do not provide significantly more than the abstract idea itself, in light of MPEP 2106.05(f) and/or (h) as sufficient option(s) for evidence without having to rely on the well understood routine and conventional test of MPEP 2106.05(d). Based on such legal evidence conferred by the MPEP 2106.05(f),(h) tests above, the Examiner submits that the additional computer-based elements do not provide significantly more without having to rely on the well-understood, routine and conventional test of MPEP 2106.05(d).
Yet, assuming arguendo, that further evidence would be required to demonstrate conventionality of the additional, computer-based elements, the Examiner would further point to MPEP 2106.05(d) to demonstrate that said additional elements remain well-understood, routine, conventional. In such case, Examiner would rely on the Original Specification as follows:
- Original Specification ¶ [00086] reciting at high level of generality: In the electronic apparatus, the processor 520 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. As an example and not limitation, the processor may also include an analog processor, a digital processor, a microprocessor, a multi-core processor, a processor array, a network processor, and the like.
- Original Specification ¶ [00087] reciting at high level: The processor 520 may execute instructions or codes stored in the storage 510, where the storage 510 may also store data. Instructions and data may also be transmitted and received through a network via a network interface device, wherein the network interface device may use any known transmission protocol.
- Original Specification ¶ [00088] reciting at high level of generality: The storage 510 may be integrated with the processor 520 as a whole, for example, random-access memory (RAM) or a flash memory arranged in an integrated circuit microprocessor or the like. In addition, the storage 510 may include an independent device, such as an external disk drive, a storage array, or other storage device that may be used by any database system. The storage 510 and the processor 520 may be operatively coupled, or may communicate with each other, for example, through an input/output (I/O) port, a network connection, or the like, so that the processor 520 may read files stored in the storage 510.
- Original Specification ¶ [00091] reciting at high level of generality: Those skilled in the art will understand that, without departing from the scope of the disclosure, embodiments of the disclosure can be modified according to the content already described. The present application is intended to cover any variations, uses, or adaptive changes of the present disclosure.
All of this preponderance of legal and/or factual evidence demonstrate that the additional computer-based elements fail to provide anything significantly more.
In conclusion, Claims 1-20, although directed to statutory categories (here “method” or process at Claims 1-8, “device” or machine at Claims 9-15 and “product” or article of manufacture at Claims 16-20) they still recite, or at least set forth or describe the abstract idea (Step 2A prong 1), with their additional, computer-based elements not integrating the abstract idea into a practical application (Step 2A prong 2) or providing significantly more than abstract idea (Step 2B).
Therefore, Claims 1-20 are patent ineligible.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Rejections under 35 § U.S.C. 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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1,3,9,11,12,16,18-20 are rejected under 35 U.S.C. 103 as being unpatentable over:
Lin et al, US 20150033227 A1 hereinafter Lin.
Tu et al, US 20150186643 A1 hereinafter Tu. As per,
Claims 1,9,16 Lin teaches A method of implementing virtual machine introspection (VMI), comprises: A device for implementing virtual machine introspection (VMI), comprises: / A computer program product for implementing virtual machine introspection (VMI), the computer program product being tangibly embodied on a non-transitory computer-readable storage medium and comprising instructions that, when executed by at least one computing device” (Lin ¶ [0022]
Fig.1 is a representation of machine introspection system 100. In cloud computing, secure virtual machines (secure-VMs 102) may be used to introspect, activity of other virtual machines (product- VMs 104 a,b,c) in machine introspection system 100 in Fig.1. The machine introspection system 100 comprises virtualization layer 106 and hardware layer 108. ¶ [0153] design, implementation, and evaluation of the Introspection System are presented. Such embodiments automatically bridge semantic gap and generate VMI tools. Through system wide instruction monitoring at VMM layer, the Introspection System automatically identify the introspection related kernel data and redirect their access to in-guest OS memory (which could be directly attached or from a snapshot). The experiments demonstrated that the Introspection System offers new features and capabilities. Particularly, it automatically enable the in-guest inspection program to become an introspection program and largely relieve the procedure of developing customized VMI tools. Finally the Introspection System may significantly remove the roadblock in VMI-based security including malware analysis and memory forensics and largely change their future daily practice. Additional details at Fig.16, ¶ [0154]-¶ [0160]) are configured to cause the at least one computing device to:
- “receiving, by a Hypervisor” / “a VMI message processing module configured to receive
by at least one processor, a read request to access a memory area of a virtual machine for reading read data”; (Lin ¶ [0123] 3rd sentence noting: [guest VM or] GVM 208 based on any virtualization layer 212, such as XEN®/KVM/VSPHERE/HYPERV. ¶ [0124] 2nd-3rd sentences: send GVM 208 data read-and-write request to a 3rd component, GVM Memory Mapping and Address Resolution 218. The GVM Memory Mapping and Address Resolution 218 component is responsible for mapping physical memory of GVM 208, resolving the corresponding kernel virtual address, and performing the read and write operations of the memory access to the GVM 208).
- “accessing, by the Hypervisor”, / “a data detection module configured to access by at least one processor” / “the memory area of the virtual machine for performing an operation for reading the read data according to the read request to return an operation result”;
(Lin ¶ [0123] 3rd sentence noting: [guest VM or] GVM 208 based on any virtualization layer 212, such as XEN®/KVM/VSPHERE/HYPERV. ¶ [0124] 3rd sentence: GVM Memory Mapping and Address Resolution 218 component is responsible for… performing the read and write operations of the memory access to GVM 208. ¶ [0145] 1st-2nd sentences: employ 2 approaches to map the PM of GVM 208 to SVM 206. One is online mapping, which directly maps the pages that belong to GVM 208 to SVM 206 with the support from the VMM (i.e hypervisor)) ) “and”
- “reconstructing, / a semantic information reconstructing module configured to reconstruct by at least one processor, / by an apparatus, semantic information based on the operation result”,
(Lin ¶ [0024] 4th-7th sentences: introspection routine reconstruct the high level info by interpreting low level data. Such interpretation may involve building an introspection routine that has a detailed, up-to-date knowledge of the internal OS kernel structures running in the inspected virtual machine. For example, to introspect the process ID (pid) of a running process in a Linux kernel, one has to traverse the corresponding task_struct to fetch its pid field. Acquiring such knowledge can be tedious and time-consuming, even for an OS whose source code is available).
- “wherein the apparatus is located outside a virtualization system including the Hypervisor”.
(Lin ¶ [0114] 2nd-5th sentences: Introspection System 200 supports running programs completely outside of the OS with same effect as running the program inside in terms of kernel state update, thanks to the powerful, programmable VMM [virtual machine monitor]. A direct outcome is that the trusted administration utilities can be executed to reconfigure the guest-OS and respond quickly to intrusions such as recovering the system from attacks (e.g., kill a rootkit created process, and rmmod a malicious kernel module) entirely from out of-VM, without any user account inside the guest-OS. Therefore, the administration of the guest-OS is made easier. Various embodiments facilitate a timely response to intrusions detected in the guest-OS.
Lin ¶ [0115] There are a number of reasons for out-of-VM program execution to manage the guest-OS. Besides benefits such as isolation, portability, and reliability while implementing the service out-of-VM, the following additional benefits may be obtained.
Lin ¶ [0116] 1st-2nd sentences: cyber attacks such as kernel rootkits have pushed defense software into the hypervisor or even hardware layers (i.e., out-of-VM). It may be much harder for attackers to tamper with the software running out-of-VM, because there is a world switch for the attacks from in-VM to out-of-VM (unless the VMM has vulnerabilities.
Lin ¶ [0117] 2nd sentence: By moving the execution of security software out-of-VM, higher privilege (same as hypervisor) and stealthiness can be achieved to make the security software invisible to attackers. ¶ [0112] 4th sentence: The trustworthiness of out-of-VM programs is thus ensured because they are located out-of-VM and there is a world switch (far from reaching) with the in-VM programs such as the in-VM malware)
Lin ¶ [0145] 1st -2nd sentences: Various embodiments employ two approaches to map the PM of the GVM 208 to the SVM 206. One is online mapping, which directly maps the pages that belong to the GVM 208 to the SVM 206 with the support from the VMM (i.e., hypervisor) ).
“
- “
- “wherein the reconstructed data structure and high-level semantic information are used to generate the write request or the program scheduling request, such that running parameters of the operating system of the virtual machine are accessed or modified through the Hypervisor to optimize an operating strategy of the operating system of the virtual machine, without modification of the operating system of the virtual machine”
(Lin ¶ [0030] Introspection System keeps transparency to the guest OS in mind (being OS - agnostic), and the system achieve nearly full transparency against an in-guest OS kernel. For example, without any modification, the Introspection System may directly support a number of most recent released Linux kernels. ¶ [0031] 3rd sentence: the VMI-tools provided by Introspection System are generated from trusted OS code and the widely used and tested utilities without any modification; ¶ [0047] 3rd sentences: The end-user may only need to install the corresponding trusted version of in-guest OS on top of secure VM 102 (shipped in the Introspection system) and invoke the commonly used standard utility programs without any modification. For examples at
Lin ¶ [0101] If there is a data write on the redirected data, the Introspection System may perform COW at page level, as it may be desirable to avoid any side effect of the in-guest OS state. This time, the Introspection System may extend one of the reserved bits in page table entries to indicate whether this page is dirty (has been copied) and add one bit to the software STLB entry. Note that this is one of the advantages of instrumenting the VMM [or hypervisor] because the Introspection System may add whatever it wants in the emulated software, such as the STLB, even though the original hardware may not contain such an extension. Meanwhile, for the page table entry, the Introspection System may extend one of the reserved bits to achieve its goal. The Introspection System may also make a shadow page table and extend it with a dirty bit for page entry if there does not exist any reserved bit.
Lin ¶ [0102] If there is a memory write on a, the Introspection System may first check whether STLB [shadow translation lookaside buffer] hits. If so, the Introspection System may check whether the target page is dirty by querying the dirty bit in the STLB entry. If it is, then the Introspection System may directly derive its physical address from the STLB. Otherwise, if the page is not dirty (marked in the STLB entry) or STLB misses, the Introspection System perform the three-layer address translation by querying SCR3 and the page tables. Next, the Introspection System may check if the target page is not dirty (the first time data write on this page). The Introspection System may perform a target page copy and redirect the future access of this page to the new page. In the meantime, the Introspection System may set the dirty bit of the target page table entry and the STLB entry as well. If it is already dirty, the Introspection System does not copy the target pages and sets the STLB entry and the dirty bit. This is because next time any data write to this page will not have a problem as the whole page has already been copied. ¶ Lin ¶ [0105] Next, the Introspection System may perform the redirectable data tracking for i (line 5). That is, check each operand, and update the shadow state. After that, for each memory address access (other than the instruction address) involved in i (line 6), if it is a data read (line 7), the Introspection System may invoke the virtual to physical address translation function to get the corresponding address (line 8), and load the data (line 9). Otherwise (line 10), the Introspection System may check whether the target page is dirty or not (line 11). If not, the Introspection System may perform the COW operation (line 12) and update the page entry dirty bit, copying the page if necessary (line 13). After that, the Introspection System may obtain its physical address (line 14) and perform the write operation (line 15) ).
* While *
Lin ¶ [0024] 4th sentence recites: The introspection routine reconstruct the high level information by interpreting the low level data, and performs security check at ¶ [0102]-[0105] etc.
* Nevertheless *
Lin does not exactly recite that such security check is after introspection or reconstruction, and thus does not recite to clearly anticipate: “wherein, after the semantic information is reconstructed the method further comprises” (Claim 1):
- “receiving a write request or a program scheduling request that conforms to the reconstructed data structure and high-level semantic information and performing the requested write operation or scheduling operation through the Hypervisor” (Claims 1,9,16) as claimed.
* However *
Tu in analogous art of automatically bridging semantic gap in machine introspection clarifies that such security check is performed after introspection or reconstruction, to teach/suggest:
“wherein, after the semantic information is reconstructed”, (Tu ¶ [0083] 3rd sentence: when a security check is performed after virtual machine introspection [or reconstruction] is triggered, the modified data is to be restored) “the method further comprises”:
- “receiving a write request or a program scheduling request that conforms to the reconstructed data structure and high-level semantic information and performing the requested write operation or scheduling operation through the Hypervisor”
(Tu ¶ [0076] the hardware transactional memory can monitor whether a write operation is executed on stored data corresponding to the memory address that is stored in the read set.
Tu ¶ [0081] 2nd sentence: When it is determined that a write operation is executed on data that needs to be protected, a transaction processing program of the hardware transactional memory is controlled to be redirected to the program for triggering virtual machine introspection, and a security check is performed according to a preset security check program. This is because
according to Tu ¶ [0005] 2nd sentence: Security of the VMM [or hypervisor], compared with conventional security software that runs inside the virtual machine, does not rely on the virtual machine itself, and therefore, even though the virtual machine might be infected by malware, the malware cannot interfere with execution of the VMM [or hypervisor])
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have better explained or at most have complementarily modified Lin’s teachings to have included Tu’s explanation that the security check is performed after virtual machine introspection [or reconstruction] as part of the sequence of operation as disclosed by Lin in view of Tu in order to have imperatively provided a more timely and effective security check triggering mechanism in the VMI system (Tu ¶ [0008]-¶ [0009] in view of MPEP 2143 G, C and/or D). The predictability of such modification would have been corroborated by the broad levels of skill of one of ordinary skills in the art as articulated by Lin ¶ [0021] in view of Tu ¶ [0056], ¶ [0150], and by the fact that Lin’s security prone introspection of ¶¶ [0030] , [0031] 3rd sentence, [0101], [0102], [0105] is complementary to Tu’s recognition at ¶ [0005] 2nd sentence that security of the VMM [or hypervisor], as compared with conventional security software that runs inside the virtual machine, does not rely on the virtual machine itself, and therefore, even though the virtual machine might be infected by malware, the malware cannot interfere with execution of the VMM.
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor, dealing with introspecting or bridging semantic gap. In such combination each element would have merely performed the same analytical and date processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Lin in view of Tu the to be combined elements would have fitted together as pieces of a puzzle in a complementary, technologically feasible and security desirable manner. Thus, in the sequence of operation above, as justified by the desire for security check, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
Claims 3,11,12,18,19,20 Lin / Tu teaches all limitations in claims 1,9,16, including the sequence of operations as explained by Tu to clarify the lapse of Lin above. Further, in such combination
Lin teaches “the receiving of the write request or the program scheduling request and the performing of the requested write operation or scheduling operation comprises”,
- “receiving the write request to access the memory area of the virtual machine through the Hypervisor for writing write data, and the Hypervisor accessing the memory area of the virtual machine to perform an operation of writing the write data according to the write request”;
(Claims 3,11,18)
(Lin ¶ [0027] 1st sentence: automatically generating introspection programs by reusing the code logics of an in-guest trusted OS kernel, and allow an expert to create introspection programs from the traces of the in-guest program. ¶ [0102] If there is a memory write on a, the Introspection System first check whether STLB hits. If so, the Introspection System may check whether the target page is dirty by querying the dirty bit in the STLB entry. If it is, then the Introspection System may directly derive its physical address from the STLB. Otherwise, if the page is not dirty (marked in the STLB entry) or STLB misses, the Introspection System may perform the three-layer address translation by querying SCR3 and the page tables. Next, the Introspection System may check if the target page is not dirty (the first time data write on this page). The Introspection System may perform a target page copy and redirect the future access of this page to the new page. In the meantime, the Introspection System may set the dirty bit of the target page table entry and the STLB entry as well. If it is already dirty, the Introspection System does not copy the target pages and sets the STLB entry and the dirty bit. This is because next time any data write to this page will not have a problem as the whole page has already been copied) “and”
- “receiving the program scheduling request for scheduling a virtual machine program in the operating system of the virtual machine in the Hypervisor, and the Hypervisor scheduling the virtual machine program to perform an operation according to the program scheduling request”,
(Claims 3,12,19)
(Lin ¶ [0037] 2nd sentence: Fig.4 shows system level behavior (in terms of system call trace) of user level getpid program. ¶ [0039] With introspection, to fully reuse OS and user level program code, data read which is only related to desired introspection functionality should be redirected. In the getpid example, the data redirect should be within getpid system call. For data in user space and other irrelevant kernel space, there may be no redirection and both kernel and other user processes may be kept running correctly. ¶ [0040] Thus Introspection System may function to:
(1) automatically identify the introspection execution context,
(2) automatically identify the data which is related to the introspection,
(3) automatically redirect data access in kernel code which is responsible for introspection
(4) keep all the processes running, at the VMM layer. Providing a solution to these problems can be a challenge since as the OS kernel may be designed to manage computer hardware resources (e.g., memory, disk, I/O, network) and provide common services (i.e., system calls) for application software, it has a very complicated control flow and data access. In particular, the kernel typically contain many resource (e.g., page tables, slab objects, device drivers) management routines, interrupt and exception handling routines (e.g. tinier, keyboard, page fault handler), context switch routines, and system call service routines. As such, when serving a system call, an interrupt, a page fault (an exception), or a context switch could occur. It may be adverse to redirect the kernel data access in context switches, page fault handlers, or interrupt service routines, or redirect the data access in the execution context of any other processes.
Lin [0125] Kernel System Call Context Identification-The Kernel System Call Context Identification 214 may be configured to identify the target-process kernel-level execution context, and pinpoint the exact system call context at the VMM layer
Lin ¶ [0145] 2nd sentence: directly map the pages that belong to the GVM 208 to the SVM 206 with the support from the VMM (i.e., hypervisor)
- “wherein, the write request and the program scheduling request conform to data structure and high-level semantic information of the operating system of the virtual machine obtained through the semantic information”
(Claims 3, 20)
(Lin ¶ [0024] 3rd-6th sentences: when performing introspection, the in-guest hardware-level state, such as processors, physical memory and devices, may be interpreted at outside VMM layer to obtain the high level semantic info. The introspection routine reconstruct the high level info by interpreting low level data. Such interpretation involve building an introspection routine that has a detailed, up-to-date knowledge of internal OS kernel structures running in the inspected virtual machine. For example, to introspect process ID (pid) of a running process in a Linux kernel, one has to traverse the corresponding task_struct to fetch its pid field.
Lin ¶ [0101] If there is a data write on the redirected data, the Introspection System perform COW at page level, as it may be desirable to avoid any side effect of the in-guest OS state. This time, the Introspection System extend one of the reserved bits in page table entries to indicate whether this page is dirty (has been copied) and add one bit to software STLB entry. Note that this is one of advantages of instrumenting the VMM because the Introspection System may add whatever it wants in the emulated software, such as STLB, even though original hardware may not contain such extension. Meanwhile, for page table entry, the Introspection System may extend one of reserved bits to achieve its goal. The Introspection System may also make a shadow page table and extend it with a dirty bit for page entry if there does not exist any reserved bit.
Lin ¶ [0102] If there is memory write on a, the Introspection System first check whether STLB hits. If so, the Introspection System may check whether the target page is dirty by querying the dirty bit in STLB entry. If it is, then the Introspection System directly derive its physical address from the STLB. Otherwise, if the page is not dirty (marked in the STLB entry) or STLB misses, the Introspection System perform the three-layer address translation by querying SCR3 and the page tables. Next, the Introspection System check if the target page is not dirty (1st time data write on this page). The Introspection System perform a target page copy and redirect the future access of this page to new page. In meantime, the Introspection System may set the dirty bit of the target page table entry and the STLB entry as well. If it is already dirty, the Introspection System does not copy the target pages and sets the STLB entry and the dirty bit. This is because next time any data write to this page will not have a problem as the whole page has already been copied.
Lin ¶ [0104] For the details of final data redirection procedure, Fig.10 illustrates example program code for redirecting kernel data according to an illustrative embodiment. As shown in, for each kernel instruction i, the Introspection System may check whether its execution is in a system call context (line 3). If so, the Introspection System may check whether the current system call data access needs to be redirected (line 4). If not, there will be no instrumentation for i.
Lin ¶ [0105] Next, the Introspection System may perform the redirectable data tracking for i (line 5). That is, check each operand, and update the shadow state. After that, for each memory address access (other than the instruction address) involved in i (line 6), if it is a data read (line 7), the Introspection System may invoke the virtual to physical address translation function to get the corresponding address (line 8) and load the data (line 9). Otherwise (line 10), the Introspection System may check whether the target page is dirty or not (line 11). If not, the Introspection System may perform the COW operation (line 12) and update the page entry dirty bit, copying the page if necessary (line 13). After that, the Introspection System may obtain its physical address (line 14) and perform the write operation (line 15) ).
Rationales to have modified/combined Lin / Tu, including the obviousness explanation of the security check after reconstruction was provided above.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 2,10,17 are rejected under 35 U.S.C. 103 as being unpatentable over:
Lin / Tu as applied to claims 1,9,16 as applied to claim, and in further view of
Hwang et al, US 20190044946 A1 hereinafter Hwang. As per,
Claims 2,10,17 Lin / Tu teaches all limitations in claims 1,9,16 above.
Lin / Tu does not recite:
- “parsing metadata included in the operation result using symbol table information and source code of an operating system of the virtual machine to generate parsed metadata”;
- “reconstructing data structure and high-level semantic information of the operating system of the virtual machine according to the parsed metadata” as explicitly claimed. Yet,
Hwang in analogous VM introspection (¶ [006]-¶ [0012]) teaches or suggests:
- “parsing metadata included in the operation result using symbol table information and source code of an operating system of the virtual machine to generate parsed metadata”;
(Hwang ¶ [0094], ¶ [0125]: parsing metadata of the target file system using the info about location at which data are stored in storage which is acquired by I/O information analyzer. First, Hwang ¶ [0055] 2nd-3rd sentences: a page frame, included in a disk cache managed by a guest OS inside a virtual machine, is tracked. Then, an event in which a task attempts to access file data in the page frame is detected, the task that is attempting to access the file data is identified, and info about the file data to which access is being attempted is checked. For example
Hwang ¶ [0146] in the method for monitoring file access in a virtual machine, based on <PFN, location_information>, sematic info (absolute path of a file etc) about a file, the data of which are stored in the page frame included in the disk cache, is extracted from the file system of the guest OS in the virtual machine. The extracted info is added in form of <PFN, file_information> to monitoring metadata connected with the page frame and managed by hypervisor at step S505.
Hwang ¶ [0061], ¶ [0079], ¶ [0107] noting each task is identified based on a register value that points to the location of a page table used by the task, and the task identification info of the task may be created based on info about the source image file of the corresponding task) “and”
- “reconstructing data structure and high-level semantic information of the operating system of the virtual machine according to the parsed metadata”
(Hwang ¶ [0007] reducing a sematic gap between a host and a guest using a Virtual Machine Introspection (VMI) for inspecting low-level VM states where semantic views inside a guest, such as files, processes, kernel modules, and the like, are reconstructed on a Virtual Machine Monitor (VMM) by casting guest OS data structures. Here, in order to acquire more accurate sematic views, the method of reconstructing sematic information on a hypervisor is used
Hwang ¶ [0012] The above-described information about the related art has been retained by the inventors for the purpose of developing the present invention or was obtained during the process of developing the present invention. To this end ¶ [0094] proposes acquiring the semantic information about the data stored in the used memory by backtracking metadata information of the disk cache by parsing the metadata of the target file system using the info about location at which the data are stored in the storage, which is acquired by I/O information analyzer 412. Thus
Hwang at ¶ [0095] discloses: When an event in which the page frame included in the disk cache 422 is accessed by a task has occurred, the disk cache access detector 414 creates <taskID, PFN> by acquiring the task identification info (taskID) of the task from the task identifier 411 and creates access event info using the created <taskID,PFN>. ¶ [0096] Here, when the disk cache 422 is directly accessed, event information in the form of <taskID, PFN, file_information> or <taskID, file_information> may be created using <PFN, file_information> of the corresponding page frame, which is previously collected and stored by the I/O information analyzer 412.
Hwang ¶ [0097] As described above, the event information created by the disk cache access detector 414 is sent to the decision module 415, whereby the validity of the access may be determined before actual access takes place. Here, the file information to be used may be the absolute path of the file in the file system, or may have a different form. ¶ [0098] The decision module 415 receives information in which the task identification information is linked with the path of the accessed file and checks whether the access by the task is allowed by an administrator.
Hwang ¶ [0099] Here, using a whitelist written in advance by the administrator, whether an entry corresponding to the received information is present in the whitelist is checked, whereby whether to allow the corresponding task to access the file may be decided.
Hwang ¶ [0100] When the corresponding entry is present in the whitelist, the access is determined to be allowed. Accordingly, a thread 430 is made to perform the task, and no further operation is performed. However, when the corresponding entry is not present in the whitelist, an operation set by the administrator may be performed. For example, when it is determined that the access is not allowed, the thread 430 may be instructed to stop the execution of the task.
Hwang ¶ [0101] Here, the decision module 415 may create an index table, which is a cache table for searching. This is because, for every file access by a task, the decision module 415 decides whether to allow file access through searching and comparison, but the use of invariable task identification information and file information causes repeated execution of code that is necessary in order to create a key value and a comparison value, which results in cumulative performance degradation.
Hwang ¶ [0102] That is, in order to reduce the amount of time taken to create the task identification information of a running task and to search a whitelist for an entry corresponding to the task, the decision module 415 may create an index table based on simplified task identification information and simplified file information (short file information) and use the index table.
Hwang ¶ [0103] Here, the index table may contain entries, each of which includes a pair comprising <short_taskID, short_file_information>. Each entry may be created and added along with information about whether to allow file access when each task first accesses a file. Also, the value of the simplified file information may be created in a simplified information form through which the corresponding file may be specified. Here, the simplified task identification information may be created by the task identifier 411).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Lin/ Tu’s method / device / product to have included Hwang’s teachings in order to have better monitored file access in the virtual machine, access to file date loaded from nonvolatile storage to memory is monitored by the hypervisor, whereby file access by task context that would have not been allowed to access a file would have been detected, and a suitable measure would have been taken in response thereto. Accordingly, the problem in which an attempt to access an already loaded file would have not been detected through storage I/O monitoring may have been be solved, and data security would have been improved (Hwang ¶ [0174[ in view of MPEP 2143 C,D and/or G) while at the same time also having provided improved security without having to install yet another additional module in the virtual machine (Hwang ¶ [0176] in view of MPEP 2143 C, D and/or G). The predictability of such modification would have been corroborated by the broad levels of skill of one of ordinary skills in the art as articulated by Lin ¶ [0021] in view of Tu ¶ [0056], ¶ [0150] and in further view of Hwang ¶ [0043].
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar VM introspection field of endeavor. In such combination each element merely would have performed same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Lin / Tu in further view of Hwang, the to be combined elements would have fitted together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 4-6, 8, and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over:
Lin / Tu as applied to claims 3,12 above, and in further view of
Zhou et al, US 20140115228 A1 hereinafter Zhou. As per,
Claims 4,13 Lin / Tu teaches all the limitations in claims 3,12 above.
Lin / Tu does not explicitly recite: “wherein, each of the read request, the write request and the program scheduling request is received from the apparatus and at least includes a virtual machine identifier (ID), an operation type, and a virtual address of a symbol” as claimed.
Zhou however in analogous virtual machines management teaches or suggests:
- “wherein, each of the read request, the write request and the program scheduling request is received from the apparatus and at least includes a virtual machine identifier (ID), an operation type, and a virtual address of a symbol” (Zhou ¶ [0013] 3rd-4th sentences: when an I/O read or write request reaches the cache module, the cache module identifies which VM the I/O request belongs to based by matching the process ID relating to the I/O request to the VM's unique identifier, which is used to track data blocks for the VM that are cached in the local SSD drive. The cache module can then perform VM-granular caching for the I/O request. In addition, a management agent service, daemon or process running in user world on the host (e.g. a process running on top of a kernel of the hypervisor) can obtain VM-specific caching policies from a centralized caching policy manager, for example, running on a computer system separate from the host, in order to, for example, a allocate an appropriate amount of space in the local SSD device to allocate to a VM for caching purposes. ¶ [0017] 3rd-4th sentences: by maintaining a VM's caching policy in global caching policy manager 126, such a VM can be migrated (e.g., via live migration technologies in certain embodiments, such as VMware's vMotion migration technology) from one host to another host while ensuring that the host to which the VM will be migrated can comply with the VM's caching policy once it is migrated. For example, hypervisor 108 on host 122 may be requested (e.g., by a VM data center management platform such as vCenter Server) to run a VM 118, upon which, management agent 120 on host 122 may receive a notification from hypervisor 108 (e.g., by registering with hypervisor 108 to request notification of certain VM related events, such as VM startup, migration, shutdown and the like) of the intention to start VM 118, and accordingly communicates with global policy manager 126 to obtain the caching policy for VM 118 to confirm whether host 122 can comply with the caching policy of VM 118.
Zhou ¶ [0025] As part of the I/O stack in hypervisor 108, cache module 110 receives read and write I/O requests originating from VM 118 (e.g., via MPIO framework 114 in the embodiment of Fig.1) and maintains a table or other data structure indicating the data blocks that are cached in SSD device 106. For example, in one embodiment, cache module 100 may have multiple tables or sub-tables of the data blocks that correspond to each VM's unique identifier (UUID) and that map such data blocks to physical locations in SSD device 106. In certain embodiments, in response to write I/O requests, cache module 110 may utilize SSD device 106 as a “write-through” cache, such that data is simultaneously written to both SSD device 106 and a virtual disk file in disk array 102. Alternative embodiments may utilize SSD device 106 as “write-back” or “write-behind” cache, where data is initially written only to SSD device 106. In response to a read I/O request, if the table maintained by cache module 110 indicates that the data relating to the I/O request has been cached in SSD device 106 (e.g., a cache hit), cache module 110 fetches data from the SSD device 106, and returns the data up the I/O stack of hypervisor 108 (e.g., back to MPIO framework 114 in the embodiment of Fig.1). If SSD device 106 does not contain the requests data, cache module 110 forwards the read I/O request to array plugin 112, which in turn fetches the data from disk array 102 (e.g., from the virtual disk file of VM 118). When array plugin 112 receives the data from disk array 102, it forwards the data to cache module 110, which writes the data to SSD device 106 in preparation for future read I/O requests. Similarly, in response to a write I/O request, cache module 110 passes the write I/O request to array plugin 112, and also writes the data blocks to SSD device 106 to invalidate existing “dirty” blocks in the cache that related to those data blocks.
Zhou ¶ [0026] Fig.4 presents a flowchart further illustrating the process of processing a read I/O request in a host that supports VM-specific second-level caching,. As previously discussed, during operation, cache module 110 receives a read I/O request (operation 402) from the I/O stack of hypervisor 108. In certain embodiments that utilize MPIO framework 114, for example, cache module 110 may receive the read I/O request from MPIO framework 114. Cache module 110 is able to determine the process ID that is associated with the read I/O request. As previously discussed, such a process ID or PID in certain embodiments may correspond to a vCPU ID or world ID of a particular vCPU process running on behalf of the VM that is handling the I/O read for the VM. It should be recognized that the process ID of an I/O request may be extracted from data structures or data frames that accompany an I/O request through various layers of any I/O stack, such as the I/O stack of hypervisor 108. Once cache module 110 identifies the process ID (e.g., world ID) handling the read I/O request, cache module 110 is able to map the process ID to the VM's unique identifier (UUID), as previously discussed.
Zhou ¶ [0027] If the VM corresponding to the UUID has second-level caching enabled (as indicated by the VM's caching policy) (operation 404), cache module 110 checks whether the data blocks corresponding to the read I/O request are cached in SSD 106 (operation 406). For example, in one embodiment as previously discussed, cache module 110 may check a table with entries corresponding to the VM's UIUD to see if such data blocks are cached for the VM's particular UUID. If the data blocks are cached, cache module 110 fetches the data blocks from SSD 106 device and forwards them back up the I/O stack of the hypervisor to the VM (operation 408). If the blocks are not cached, cache module 110 passes the read I/O request to array plugin 112 (or further down the I/O stack of the hypervisor in other embodiments that do not use array plugin 112), which in turn forwards the request to shared disk array 102 and subsequently receives the data blocks from shared disk array 102 (operation 411) and forwards the received data blocks back up the I/O stack to the VM (operation 414). As such, cache module 110 receives the data blocks and copies the received data blocks to SSD device 106 (operation 416). If the VM's allocated cache space is full, cache module 110 may invalidate or expire some older cached data to free up space for the newly received data. Returning to operation 404, if the VM does not have second-level caching enabled (e.g., has no second level caching policy or requirements), cache module 110 passes the read I/O request to array plugin 112 (or further down the I/O stack of the hypervisor), which forwards the request to shared disk array 102 (operation 410). Subsequently, array plugin 112 receives the data blocks from shared disk array 102 (operation 412), and forwards the received blocks back up the I/O stack to the VM (operation 414).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Lin/Tu’s “method” / “device” to have included Zhou’s teachings in order to have provided a more effective processing of virtual machines including improved I/O latency and throughout (Zhou ¶ [0002] in view of MPEP 2143 C, D and/or G) while, at the same time, having mitigated the difficulty of dynamically sharing among multiple virtual machines (Zhou ¶ [0003] in view of MPEP 2143 C, D and/or G). The predictability of such modification would have been corroborated by the broad levels of skill of one of ordinary skills in the art as articulated by Lin ¶ [0021] in view of Tu ¶ [0056], ¶ [0150], and in further view of Zhou ¶ [0011], ¶ [0035].
Further, the claimed invention could have also viewed as a mere combination of old elements in a similar virtual machines management field of endeavor. In such combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Lin / Tu in view Zhou, the to be combined elements would have fitted together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
Claims 5,14 Lin / Tu teaches all the limitations in claims 4,13 above.
Lin / Tu does not recite: wherein, the operation of reading the read data comprises:
- “determining a corresponding virtual machine, according to the virtual machine ID included in the read request”; .
- “determining the memory area of the virtual machine to be accessed, according to the determined virtual machine and the virtual address of the symbol included in the read request”;
- “and performing a read operation on the memory area of the virtual machine” as claimed.
Zhou however in analogous virtual machines management teaches or suggests:
“wherein, the operation of reading the read data comprises”:
- “determining a corresponding virtual machine, according to the virtual machine ID included in the read request”; (Zhou ¶ [0013] 2nd sentence: when I/O read or write request reaches cache module, the cache module identifies which VM the I/O request belongs to by matching the process ID relating to the I/O request to the VM’s unique identifier used to track data blocks for the VM that are cached in the local SSD drive. ¶ [0021] 5th sentence: When a VM transmits an I/O read or write request, the PID or vCPU ID of the VM's vCPU that is requesting the I/O is also passed through the various layers of the I/O stack of hypervisor 108, along with the I/O request itself, such that an I/O response can be ultimately be returned to the requesting PID or vCPU ID).
- “determining the memory area of the virtual machine to be accessed, according to the determined virtual machine and the virtual address of the symbol included in the read request”;
(Zhou ¶ [0025] As part of the I/O stack in hypervisor 108, cache module 110 receives read I/O requests originating from VM 118 (e.g via MPIO framework 114 in Fig.1) and maintains a table or other data structure indicating the data blocks that are cached in SSD device 106. For example, cache module 100 may have multiple tables or sub-tables of the data blocks that correspond to each VM’s unique identifier (UUID) and that map such data blocks to physical locations in SSD device 106. In certain embodiments, in response to write I/O requests, cache module 110 may utilize SSD device 106 as a write-through cache, such that data is simultaneously written to both SSD device 106 and virtual disk file in disk array 102. Alternative embodiments may utilize SSD device 106 as write-back or write-behind cache, where data is initially written only to SSD device 106. In response to a read I/O request, if the table maintained by cache module 110 indicates that the data relating to the I/O request has been cached in SSD device 106 (e.g., a cache hit), cache module 110 fetches data from the SSD device 106, and returns the data up the I/O stack of hypervisor 108 (e.g., back to MPIO framework 114 if Fig.1). If SSD device 106 does not contain the requests data, cache module 110 forwards the read I/O request to array plugin 112, which in turn fetches the data from disk array 102 (e.g. from virtual disk file of VM 118). When array plugin 112 receives the data from disk array 102, it forwards the data to cache module 110, which writes the data to SSD device 106 in preparation for future read I/O requests
Zhou ¶ [0026] Fig.4 illustrates processing a read I/O request in a host that supports VM-specific 2nd level caching. As previously discussed, during operation, cache module 110 receives a read I/O request (operation 402) from the I/O stack of hypervisor 108. In certain embodiments that utilize MPIO framework 114, for example, cache module 110 may receive the read I/O request from MPIO framework 114. Cache module 110 determine the process ID that is associated with the read I/O request. As previously discussed, such a process ID or PID in certain embodiments may correspond to a vCPU ID or world ID of a particular vCPU process running on behalf of the VM that is handling the I/O read for the VM. It should be recognized that the process ID of an I/O request may be extracted from data structures or data frames that accompany an I/O request through various layers of any I/O stack, such as the I/O stack of hypervisor 108. Once cache module 110 identifies the process ID (e.g., world ID) handling the read I/O request, cache module 110 is able to map the process ID to the VM's unique identifier (UUID), as previously discussed.
Zhou ¶ [0027] If the VM corresponding to the UUID has 2nd level caching enabled (as indicated by the VM's caching policy) (operation 404), cache module 110 checks whether the data blocks corresponding to the read I/O request are cached in SSD 106 (operation 406). For example, cache module 110 may check a table with entries corresponding to the VM's UIUD to see if such data blocks are cached for the VM's particular UUID. If the data blocks are cached, cache module 110 fetches the data blocks from SSD 106 device and forwards them back up the I/O stack of the hypervisor to the VM (operation 408). If the blocks are not cached, cache module 110 passes the read I/O request to array plugin 112 (or further down the I/O stack of the hypervisor in other embodiments that do not use array plugin 112), which in turn forwards the request to shared disk array 102 and subsequently receives the data blocks from shared disk array 102 (operation 411) and forwards the received data blocks back up the I/O stack to the VM (operation 414). As such, cache module 110 receives the data blocks and copies the received data blocks to SSD device 106 (operation 416). If the VM's allocated cache space is full, for example, cache module 110 may invalidate or expire some older cached data to free up space for the newly received data. Returning to operation 404, if the VM does not have second-level caching enabled (e.g., has no second level caching policy or requirements), cache module 110 passes the read I/O request to array plugin 112 (or further down the I/O stack of the hypervisor), which forwards the request to shared disk array 102 (operation 410). Subsequently, array plugin 112 receives the data blocks from shared disk array 102 (operation 412) and forwards the received blocks back up the I/O stack to the VM (operation 414) “and”
- “performing a read operation on the memory area of the virtual machine”.
(Zhou mid-¶ [0017] performs I/O to read data to virtual disk file that resides in shared disk array 102. ¶ [0026] 5th, 7th sentences: vCPU ID or world ID of a particular vCPU process running on behalf of the VM that is handling [or performing] the I/O read for the VM. Once cache module 110 identifies the process ID (e.g., world ID) handling [or performing] the read I/O request, cache module 110 maps the process ID to the VM's unique identifier (UUID), as previously discussed).
Rationales to have modified/combined Lin / Tu / Zhou are above and reincorporated.
Claims 6,15 Lin / Tu teaches all the limitations in claims 4,13 above.
Lin / Tu does not recite as explicitly claimed:
- “determining a corresponding virtual machine, according to the virtual machine ID included in the write request”;
- “determining the memory area of the virtual machine to be accessed, according to the determined virtual machine and the virtual address of the symbol included in the write request”;
- “and performing a write operation on the memory area of the virtual machine”.
Zhou however in analogous virtual machines management teaches or suggests:
- “determining a corresponding virtual machine, according to the virtual machine ID included in the write request”; (Zhou ¶ [0013] 2nd sentence: when I/O read or write request reaches cache module, the cache module identifies which VM the I/O request belongs to by matching the process ID relating to the I/O request to the VM's unique identifier used to track data blocks for the VM that are cached in local SSD drive. ¶ [0021] 5th sentence: When a VM transmits an I/O read or write request, the PID or vCPU ID of the VM's vCPU that is requesting the I/O is also passed through the various layers of the I/O stack of hypervisor 108, along with I/O request itself, such that an I/O response can be ultimately be returned to the requesting PID or vCPU ID).
- “determining the memory area of the virtual machine to be accessed, according to the determined virtual machine and the virtual address of the symbol included in the write request”;
(Zhou ¶ [0025] As part of the I/O stack in hypervisor 108, cache module 110 receives read and write I/O requests originating from VM 118 (e.g. via MPIO framework 114 in Fig.1) and maintains a table or other data structure indicating the data blocks that are cached in SSD device 106. For example, in one embodiment, cache module 100 may have multiple tables or sub-tables of the data blocks that correspond to each VM’s unique identifier (UUID) and that map such data blocks to physical locations in SSD device 106. In certain embodiments, in response to write I/O requests, cache module 110 may utilize SSD device 106 as a write-through cache, such that data is simultaneously written to both SSD device 106 and virtual disk file in disk array 102. Alternative embodiments may utilize SSD device 106 as write-back or write-behind cache, where data is initially written only to SSD device 106. In response to a read I/O request, if the table maintained by cache module 110 indicates that the data relating to the I/O request has been cached in SSD device 106 (e.g. a cache hit), cache module 110 fetches data from the SSD device 106, and returns the data up the I/O stack of hypervisor 108 (e.g., back to MPIO framework 114 if Fig.1). If SSD device 106 does not contain the requests data, cache module 110 forwards the read I/O request to array plugin 112, which in turn fetches the data from disk array 102 (e.g. from virtual disk file of VM 118). When array plugin 112 receives the data from disk array 102, it forwards the data to cache module 110, which writes the data to SSD device 106 in preparation for future read I/O requests. Similarly, in response to a write I/O request, cache module 110 passes the write I/O request to array plugin 112, and also writes the data blocks to SSD device 106 to invalidate existing dirty blocks in the cache that related to those data blocks.
Zhou ¶ [0028] Fig.5 presents a flowchart illustrating processing a write I/O request in a host that supports VM-specific 2nd level caching. During operation, the I/O stack of the hypervisor (e.g., MPIO framework 114) receives a write I/O request originating VM that includes a number of data blocks that should be written to a virtual disk file, for example (operation 502). The I/O stack may then send the write I/O request to array plugin 112 or any other subsequent layer of the I/O stack to handle the write I/O request (operation 510). In response, array plugin 112 writes the data blocks in the write I/O request to shared disk array 102 (operation 512).
Zhou ¶ [0029] Simultaneously, the I/O stack may sends the write I/O request to cache module 110 (operation 504). Similar to a read I/O request as discussed above, cache module 110 is able to determine the unique identifier (UUID) of the VM issuing the write I/O request by obtaining the process ID (world ID) of the process issuing the write I/O request. Once cache module 110 identifies the UUID of the VM, it is able to writes the data blocks to a portion of SSD device 106 that it has allocated to the VM for caching purposes (operation 506). Cache module 110 updates the data block tables that it maintains to reflect that the data blocks of the write I/O request are now cached in SSD device 106, so that future read I/O requests for these data blocks from the same VM world ID would result in cache hits (operation 508) “and”
- “performing a write operation on the memory area of the virtual machine”.
(Zhou ¶ [0029] 3rd – 4th sentences: Once cache module 110 identifies the UUID of the VM, it is able to writes the data blocks to a portion of SSD device 106 that it has allocated to the VM for caching purposes (operation 506). Cache module 110 updates the data block tables that it maintains to reflect that the data blocks of the write I/O request are now cached in SSD device 106, so that future read I/O requests for these data blocks from the same VM world ID would result in cache hits (operation 508).
Rationales to have modified Lin/Tu to have included Zhou are above and reincorporated.
Claim 8. Lin/Tu teaches all the limitations in claim 4 above.
Lin/Tu does not recite “wherein, the scheduling of the virtual machine program to perform the operation comprises”:
- “determining a corresponding virtual machine, according to the virtual machine ID included in the program scheduling request”;
- “determining the virtual machine program in the operating system of the virtual machine, according to the determined virtual machine and the virtual address of the symbol included in the program scheduling request”; “and”
- “scheduling the virtual machine program to perform an operation, in the Hypervisor”
Zhou however in analogous virtual machines management teaches or suggests:
“wherein, the scheduling of the virtual machine program to perform the operation comprises”:
- “determining a corresponding virtual machine, according to the virtual machine ID included in the program scheduling request”; (Zhou ¶ [0013] 2nd-3rd sentences: the cache module identifies which VM the I/O request belongs to based by matching the process ID relating to the I/O request to the VM's unique identifier, which is used to track data blocks for the VM that are cached in the local SSD drive.The cache module can then perform VM-granular caching for the I/O request. In addition, a management agent service, daemon or process running in user world on the host (e.g., a process running on top of a kernel of the hypervisor) can obtain VM-specific caching policies from a centralized caching policy manager, for example, running on a computer system separate from the host, in order to, for example, a allocate an appropriate amount of space in the local SSD device to allocate to a VM for caching purposes. ¶ [0018] 3rd sentence: in Fig.1, MPIO [multi-pathing] layer 104 sits within an I/O stack of hypervisor 108 that includes … (ii) a logical device I/O scheduler 116 that schedules block I/O to the logical storage devices for the VMs running in a hypervisor and, for example, enforces the fair sharing of logical storage devices between VMs. ¶ [0020] As previously described, cache module 110 manage SSD device 106 as a cache to VMs running on host 122 on a “per VM” basis. In order to perform caching of I/O on a per-VM basis, cache module 110 should be able to associate block I/O requests that it receives from the I/O stack of hypervisor 108 with the particular VMs that are performing such I/O requests. In one embodiment, cache module 110 obtains a unique identifier for VM 118 from management agent 120 which, for example, receives the unique identifier of the VM upon receipt of a VM startup notification, as previously discussed. In certain of such embodiments, such a unique identifier may be a “universally unique identifier” (UUID) that, for example, is based on an identifier of the physical host in which a VM has been instantiated and a pathname of the location of the VM's configuration file (e.g. a .vmx file in certain VMware technology based embodiments) that is stored in shared disk array 102. Cache module 110 may associate a VM's allocated cache space in SSD device 106 with this unique identifier)
- “determining the virtual machine program in the operating system of the virtual machine, according to the determined virtual machine and the virtual address of the symbol included in the program scheduling request”;
(Zhou ¶ [0021] Management agent 120 request and receive from hypervisor 108 (e.g., upon receiving a VM start notification, etc.) the identifiers or IDs of all processes associated with a VM running on hypervisor 108. For example, in certain embodiments, using VMware's vSphere Hypervisor as hypervisor 108, hypervisor 108 spawns a separate process or thread for each virtual CPU (vCPU) of a running VM-the process ID (PID) of each such vCPU process is sometimes referred to as a vCPU ID or world ID. In one embodiment, such as an embodiment using VMware's vSphere virtualization technologies, management agent 120 is able to obtain the vCPU IDs corresponding to a VM through an API provided by hypervisor 108 (e.g., in vSphere, referred to as the VMkernel Sysinfo Interface or VSI) and forward the vCPU IDs to cache module 110 in association with the VM’s unique identifier. Cache module 110 then maintains a mapping between the unique identifier of the VM (which also identifies the area of SSD device 106) which serves as a cache for such VM and the PIDs or vCPU IDs of the vCPU processes running in the VM. When a VM transmits an I/O read or write request, the PID or vCPU ID of the VM's vCPU that is requesting the I/O is also passed through the various layers of the I/O stack of hypervisor 108, along with the I/O request itself, such that an I/O response can be ultimately be returned to the requesting PID or vCPU ID. As such, when the I/O request reaches cache module 110, which is embedded in the I/O stack of hypervisor 108, cache module 110 is able obtain the PID or vCPU ID associated with the I/O request and map it to the unique identifier of the VM. In doing so, cache module 110 is thus able to access the cache in SSD device 106 that is associated with the unique identify of the VM to see if the I/O request can be handled by the cache.
Zhou ¶ [0022] 2nd-4th sentences: the start-up notification includes the VM's unique identifier (UUID) which management agent 120 then provides to hypervisor 108 to obtain vCPU or world IDs of the running vCPU processes for VM 118 (operation 204). Management agent further 120 provides the unique identifier of VM 118 to global caching policy manager 126 to obtain VM 118's caching policy, or an update to VM 118's caching policy (operation 206). Management agent 120 is thus able to transmits VM 118's world ID-to-UUID mapping information and caching policy information to cache module 110 (operation 208).
Zhou ¶ [0023] 3rd-5th sentences: In operation 304, hypervisor 108 checks to ensure that all virtual disk files of VM 118 reside on shared disk array 102, so that host 124 also access the virtual disk files of VM 118 on shared disk array 102 one VM 118 is migrated to host 124. Subsequently, in operation 306, hypervisor 108 begins a process of copying VM 118's memory (and device state) to the host 124. Once a sufficient amount of memory has been copied to host 124, hypervisor 108 then suspends or “stuns” VM 118, copies any remaining memory of VM 118 to host 124 and completes the migration of VM 118 to the target host in operation 308) “and”
- “scheduling the virtual machine program to perform an operation, in the Hypervisor”
(Zhou ¶ [0018] 3rd sentence: in Fig.1, MPIO [multi-pathing] layer 104 sits within an I/O stack of hypervisor 108 that includes… (ii) a logical device I/O scheduler 116 that schedules block I/O to the logical storage devices for the VMs running in a hypervisor and, enforces the fair sharing of logical storage devices between VMs. For example, at ¶ [0023] 3rd-4th sentences In operation 304, hypervisor 108 checks to ensure all virtual disk files of VM 118 reside on shared disk array 102, so host 124 can also access the virtual disk files of VM 118 on shared disk array 102 one VM 118 is migrated to host 124. Then in operation 306, hypervisor 108 begins process of copying VM 118’s memory (and device state) to host 124. Once a sufficient amount of memory has been copied to host 124, hypervisor 108 then suspends or stuns VM 118, copies any remaining memory of VM 118 to host 124 and completes migration of VM 118 to the target host in operation 308)
Rationales to have modified/combined Lin/Tu with/and Zhou are above and reincorporated.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim 7 are rejected under 35 U.S.C. 103 as being unpatentable over:
Lin / Tu as applied to claim 3, and in further view of
Kiperberg et al, US 20210049263 A hereinafter Kiperberg. As per,
Claim 7 Lin / Tu teaches all the limitations in claim 3 above.
Lin / Tu does not explicitly recite: “wherein, the scheduling of the virtual machine program to perform the operation is executed in the Hypervisor at an exception level 2 to support Virtualization Host Extension Features” as claimed.
Kiperberg in analogous art of virtual machines management teaches or suggests:
-“wherein, the scheduling of the virtual machine program to perform the operation is executed in the Hypervisor at an exception level 2 to support Virtualization Host Extension Features” (Kiperberg ¶ [0123] 1st-2nd sentences: on modern boards offering VHE extensions (such as ARMv8.2 architectures Cortex A-55 or Coretex A-75), the problem is solved using virtual host extension (VHE). With VHE, EL2 [exception level 2] has an additional translation table that maps the kernel address space).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention to have modified Lin/Tu’s method to have further included Kiperberg’s teachings in order to have executed the hyplet without endangering the hypervisor (Kiperberg ¶ [0123] 3rd sentence in view of MPEP 2143 C, D and/or G). The predictability of such modification would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Lin ¶ [0021] in view of Tu ¶ [0056], ¶ [0150] and in further view of Kiperberg ¶ [0025], ¶ [0151], ¶ [0160], ¶ [0162].
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar virtual machines management field of endeavor. In such combination each element would have merely performed same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Lin/Tu in view of Kiperberg, the to be combined elements would have fitted together like pieces of a puzzle in a logical, complementary, technologically feasible and/or econocmailly desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
Following art is made of record and considered pertinent to Applicant’s disclosure:
Jain et al, SoK, Introspections on Trust and the Semantic Gap, IEEE, 21 May 2014
EP 4086763 A1 Processing system for use in integrated circuit, has slave interface circuit for inhibiting forwarding read or write request to first circuit, where registers are programmable via software instructions executed by microprocessor
US 20130091568 A1 Systems and methods for secure in-vm monitoring
US 20120331465 A1 Virtual machine system, virtual machine control method, virtual machine control application, and semiconductor integrated circuit
US 9529614 B2 Automatically bridging the semantic gap in machine introspection
US 20190155638 A1 Cache allocation to a virtual machine
US 20150121135 A1 Virtual machine introspection facilities
US 20220114009 A1 Formally Verified Trusted Computing Base with Active Security and Policy
Enforcement
US 10514945 B2 Host-based virtual machine introspection with dynamic guest assistance
US 10089474 B2 Virtual machine introspection
US 20150013008 A1 Process Evaluation for Malware Detection in Virtual Machines
US 9117080 B2 Process evaluation for malware detection in virtual machines
US 20150295800 A1 Always-On Monitoring in the Cloud
US 20180321963 A1 Safe execution of virtual machine callbacks in a hypervisor
US 20140372717 A1 Fast and Secure Virtual Machine Memory Checkpointing
US 8875295 B2 Memory introspection engine for integrity protection of virtual machines
US 8387046 B1 Security driver for hypervisors and operating systems of virtualized datacenters
US 11113071 B1 Unified hypervisor image for multiple processor ISAs
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OCTAVIAN ROTARU whose telephone number is (571)270-7950. The examiner can normally be reached on 571.270.7950 from 9AM to 6PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICIA H MUNSON, can be reached at telephone number (571)270-5396. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Octavian Rotaru/
Primary Examiner, Art Unit 3624
July 7th, 2026
1 Such limitation can also be argued to have limited patentable weight as per the wherein clause test of MPEP 2111.04 I, the contingent clause test of MPEP 2111.04 II and/or the intended use of USPTO’s training entitled Focus on Computer/Software-related Claims dated May 2015 slides 16-17,20-21, which cites MPEP 2111.04
2 Such limitation can also be argued to have limited patentable weight as per the wherein clause test of MPEP 2111.04 I, the contingent clause test of MPEP 2111.04 II and/or the intended use or intended result test of USPTO’s training entitled Focus on Computer/Software-related Claims dated May 2015 slides 16-17,20-21, which cites MPEP 2111.04
3 Such limitation can also be argued to have limited patentable weight as per the wherein clause test of MPEP 2111.04 I, the contingent clause test of MPEP 2111.04 II and/or intended result test of USPTO’s training entitled Focus on Computer/Software-related Claims dated May 2015 slides 16-17,20-21, which cites MPEP 2111.04
4 Such limitation can also be argued to have limited patentable weight as per the wherein clause test of MPEP 2111.04 I, the contingent clause test of MPEP 2111.04 II and/or the intended use of USPTO’s training entitled Focus on Computer/Software-related Claims dated May 2015 slides 16-17,20-21, which cites MPEP 2111.04
5 Such limitation can also be argued to have limited patentable weight as per the wherein clause test of MPEP 2111.04 I, the contingent clause test of MPEP 2111.04 II and/or the intended use or intended result test of USPTO’s training entitled Focus on Computer/Software-related Claims dated May 2015 slides 16-17,20-21, which cites MPEP 2111.04
6 Such limitation can also be argued to have limited patentable weight as per the wherein clause test of MPEP 2111.04 I, the contingent clause test of MPEP 2111.04 II and/or intended result test of USPTO’s training entitled Focus on Computer/Software-related Claims dated May 2015 slides 16-17,20-21, which cites MPEP 2111.04
Prosecution Insights