DETAILED ACTION
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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
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 an abstract idea without significantly more.
In adhering to the 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG), Step 1 is directed to determining whether or not the claims fall within a statutory class. Herein, the claims fall within statutory class of process, machine or manufacture. Hence, the claims qualify as potentially eligible subject matter under 35 U.S.C §101. With Step 1 being directed to a statutory category, the analysis directed to Step 2A.
Step 2A is a two prong inquiry. Prong 1 considers whether the claim recites a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon). In this case independent claim 1 recites mental processes as applied to human activity (i.e. concepts performed in the human mind but for the recitation of generic computing components). For example, the following claimed steps are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion:
grouping a first subset of the plurality of status reports corresponding to proper operations and collecting hypervisor information of the first subset of the plurality of status reports;
grouping a second subset of the plurality of status reports corresponding to improper operations and executing respective repair applications in corresponding hypervisors associated with the second subset of the plurality of status reports; and
generating, by the processing device, a report summarizing the hypervisor information of the first subset of the plurality of status reports and repairment status of the corresponding hypervisors associated with the second subset of the plurality of status report.
But for the recitation of generic computing components, steps a-c can be completed in the human mind with the aid of pen and paper through observation, evaluation, judgment, and/or opinion. “As the Federal Circuit has explained, ‘[c]ourts have examined claims that required the use of a computer and still found that the underlying, patent-ineligible invention could be performed via pen and paper or in a person’s mind.’ Versata Dev. Group v. SAP Am., Inc., 793 F.3d 1306, 1335, 115 USPQ2d 1681, 1702 (Fed. Cir. 2015).” (MPEP 2106.04(a)(2) (III)). Steps a-c describe collecting, analyzing, and displaying information at a high level of generality. According to the MPEP, these steps are examples of mental processes, thus it is reasonable to identify these limitations as reciting mental processes. (MPEP 2106.04(a)(2) III (A), claims do recite a mental process when they contain limitations that can practically be performed in the human mind, including for example, observations, evaluations, judgments, and opinions. Examples of claims that recite mental processes include: a claim to “collecting information, analyzing it, and displaying certain results of the collection and analysis,” where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016)).
Since the claims are directed toward a judicial exception, analysis flows to Prong 2. Prong 2 considers whether the judicial exception is integrated into a practical application. In this case, the judicial exception is not integrated into a practical application because the claim language merely describes steps of collecting data, field of use/technological environment, and using a computer as a tool to apply the abstract idea and fails to describe an improvement to the functioning of a computer or other technical field. The additional elements recited in the claim do not integrate the judicial exception into a practical application for the following reasons:
The additional elements of “hypervisors,” “processing device,” and “diagnostic applications” are recited at a high level of generality and amounts to using a generic computing component as a tool to apply the abstract idea (MPEP § 2106.05(f)). These additional elements also appear to be an attempt to generally link the use of the judicial exception to a particular technological environment or field of use. (MPEP 2106.05(h));
The additional element of “executing, by a processing device, respective diagnostic applications in the plurality of hypervisors” amounts to insignificant extra-solution data gathering/data transmission activity (MPEP § 2106.05(g)); and
The additional element of “collecting, from the plurality of hypervisors, a plurality of status reports for the plurality of hypervisors, wherein each of the plurality of status reports indicates whether a corresponding hypervisor is operating properly” amounts to insignificant extra-solution data gathering/data transmission activity (MPEP § 2106.05(g)).
Therefore the abstract idea has not been integrated into practical application and the claims are directed to the abstract idea.
Since the claims are directed to the determined judicial exception, the analysis flows to Step 2B. Therein, the elements and combination of elements are examined in the claims to determine whether the claims as a whole amounts to significantly more than the judicial exception. In this case, the additional elements identified at Step 2A Prong 2, individually or in an order combination, also do not amount to significantly more than the abstract idea for the same reasons as given in Step 2A Prong 2 and further because:
The claimed “hypervisors” “processing device,” and “diagnostic applications” are generically recited as mere instructions to implement an abstract idea on a computer. Thus, these steps do not add significantly more to the respective limitations. Taken as an ordered combination, the afore-mentioned limitations are directed to limitations referenced in Alice Corp. (also called the Mayo test) that are not enough to qualify as significantly more when recited in a claim with an abstract idea. (MPEP § 2106.05 (I)(A)), “Limitations that the courts have found not to be enough to qualify as “significantly more” when recited in a claim with a judicial exception include: i… mere instructions to implement an abstract idea on a computer.”
The additional element of “executing, by a processing device, respective diagnostic applications in the plurality of hypervisors” amounts to well‐understood, routine, and conventional functions because the step is claimed in a merely generic manner (e.g., at a high level of generality) and as insignificant extra-solution activity. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network.” (MPEP 2106.05(d) (II)).
The additional element of “collecting, from the plurality of hypervisors, a plurality of status reports for the plurality of hypervisors, wherein each of the plurality of status reports indicates whether a corresponding hypervisor is operating properly” amounts to well‐understood, routine, and conventional functions because the step is claimed in a merely generic manner (e.g., at a high level of generality) and as insignificant extra-solution activity. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network.” (MPEP 2106.05(d) (II)).
“A claim directed to a judicial exception cannot be made eligible “simply by having the applicant acquiesce to limiting the reach of the patent for the formula to a particular technological use.” Diamond v. Diehr, 450 U.S. 175, 192 n.14, 209 USPQ 1, 10 n. 14 (1981). Thus, limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application.” (MPEP 2106.05 (h)).
Employing generic computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment, does not add significantly more, similar to how limiting the abstract idea in Flook to petrochemical and oil-refining industries was insufficient. (MPEP 2106.05 (h)).
Viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself (Note MPEP 2106.05(a)).
Since there are no elements or ordered combination of elements that amount to significantly more than the judicial exception, the claims are not eligible subject matter under 35 USC §101.
Regarding claim 2: the steps of “periodically executing the respective diagnostic applications in the plurality of hypervisors at a time interval; or executing, in response to a trigger condition being satisfied, the respective diagnostic applications in the plurality of hypervisors, wherein the trigger condition comprises detecting, by the processing device, that a virtual machine of the plurality of hypervisors has hung” amounts to insignificant extra-solution data gathering/data transmission activity (MPEP § 2106.05(g)).
Regarding claim 3: the steps of :
wherein grouping the first subset of the plurality of status reports corresponding to proper operations and collecting hypervisor information of the first subset of the plurality of status reports comprise:
placing an indicator in each hypervisor corresponding to the first subset of the plurality of status reports of proper operations; and
printing, with the indicator for each hypervisor in the generated report, the collected hypervisor information of the first subset of the plurality of status reports.”
recite additional mental processes under Prong 1 since the “grouping,” “placing,” and “printing” steps can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion but for the recitation of generic computing components. For example a person can think and evaluate to group a subset of hypervisors in a report. A person can also think and evaluate place an indicator (i.e. label) on hypervisors associated with the subset in a report and print the report. The additional element of “collecting hypervisor information of the first subset of the plurality of status reports comprise” amounts to insignificant extra-solution data gathering/data transmission activity (MPEP § 2106.05(g)) under Prong 2. Therefore, these additional elements do not integrate the judicial exception into a practical application. (MPEP 2106.05(f)). Under Step 2B, since these additional elements merely recite generic computer components to carry out the abstract idea, they do not amount to significantly more than the judicial exception.
Regarding claim 4: is not eligible for the following reasons:
The steps of
evaluating status for a plurality of virtual machines running in the plurality of hypervisors;
grouping a third subset of the plurality of VM status reports corresponding to proper VM operations and collecting VM information of the third subset of the plurality of VM status reports;
grouping a fourth subset of the plurality of VM status reports corresponding to improper operations and executing respective repair applications in corresponding virtual machines associated with the fourth subset of VM status reports; and
generating, by the processing device in the report, a VM summary of the VM information of the third subset of the plurality of VM status reports and repairment status of the corresponding virtual machines associated with the fourth subset of VM status reports.
recite additional mental processes under Prong 1 since the “evaluating,” “grouping a third subset,” “grouping a fourth subset,” and “generating” steps can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion but for the recitation of generic computing components.
The additional element of “collecting, from the plurality of virtual machines, a plurality of virtual-machine (VM) status reports for the plurality of virtual machines, wherein each of the plurality of VM status reports indicates whether a corresponding virtual machine is operating properly” amounts to insignificant extra-solution data gathering/data transmission activity (MPEP § 2106.05(g)) under Prong 2. Therefore, these additional elements do not integrate the judicial exception into a practical application. (MPEP 2106.05(f)). Under Step 2B, since these additional elements merely recite generic computer components to carry out the abstract idea, they do not amount to significantly more than the judicial exception.
Regarding claim 5: the additional element of “wherein the repairment status of the corresponding virtual machines comprise identifications of irreparable virtual machines” appears to be an attempt to generally link the use of the judicial exception to a particular technological environment or field of use. (MPEP 2106.05(h)). The additional element of “virtual machines” is recited at a high level of generality and amounts to using a generic computing component as a tool to apply the abstract idea (MPEP § 2106.05(f)).
Regarding claim 6: the additional element of “wherein the VM summary of the VM information of the third subset of the plurality of VM status reports comprises: resources occupied by properly operating virtual machines of the plurality of hypervisors; and identifications of the properly operating virtual machines of the plurality of hypervisors” appears to be an attempt to generally link the use of the judicial exception to a particular technological environment or field of use. (MPEP 2106.05(h)). The additional elements of “resources,” “virtual machines,” and “hypervisors” are recited at a high level of generality and amounts to using a generic computing component as a tool to apply the abstract idea (MPEP § 2106.05(f)).
Regarding claim 7: the step of “disabling one or more hypervisors in the plurality of hypervisors based on the resources occupied by the properly operating virtual machines; or creating one or more hypervisors in the plurality of hypervisors based on the resources occupied by the properly operating virtual machines” is ineligible under Prong 1 since these steps can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion but for the recitation of generic computing components. For example, a person can think and evaluate to disable hypervisors based on a report or create hypervisors based on a report.
The additional element of “hypervisors,” “resources,” and “virtual machines” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea under Prong 2. Therefore, these additional elements do not integrate the judicial exception into a practical application. (MPEP 2106.05(f)). Under Step 2B, since these additional elements merely recite generic computer components to carry out the abstract idea, they do not amount to significantly more than the judicial exception.
Regarding claim 8: the additional step of “determining one or more hypervisors having executed respective repair applications to be irreparable; and removing the one or more irreparable hypervisors from the plurality of hypervisors” is ineligible under Prong 1 since these steps can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion but for the recitation of generic computing components.
The additional element of “hypervisors,” “repair applications” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea under Prong 2. Therefore, these additional elements do not integrate the judicial exception into a practical application. (MPEP 2106.05(f)). Under Step 2B, since these additional elements merely recite generic computer components to carry out the abstract idea, they do not amount to significantly more than the judicial exception.
Regarding claim 9: the additional element of “wherein the plurality of hypervisors comprises hypervisors belonging to various servers” appears to be an attempt to generally link the use of the judicial exception to a particular technological environment or field of use. (MPEP 2106.05(h)). The additional element of “hypervisors” and “servers” are also recited at a high level of generality and amounts to using a generic computing component as a tool to apply the abstract idea (MPEP § 2106.05(f)).
Regarding claim 10: this claim is not patent eligible for the same reasons given for claim 1 for the common limitations. The recitation of the additional elements of an “apparatus,” and a “memory” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea under Prong 2. Therefore, these additional elements do not integrate the judicial exception into a practical application. (MPEP 2106.05(f)). Under Step 2B, since these additional elements merely recite generic computer components to carry out the abstract idea, they do not amount to significantly more than the judicial exception.
Regarding claim 11: this claim is ineligible for the same reasons given for claim 2.
Regarding claim 12: this claim is ineligible for the same reasons given for claim 3.
Regarding claim 13: this claim is ineligible for the same reasons given for claim 4.
Regarding claim 14: this claim is ineligible for the same reasons given for claim 5.
Regarding claim 15: this claim is ineligible for the same reasons given for claim 6.
Regarding claim 16: this claim is ineligible for the same reasons given for claim 7.
Regarding claim 17: this claim is ineligible for the same reasons given for claim 8.
Regarding claim 18: this claim is not patent eligible for the same reasons given for claim 1 for the common limitations. The recitation of the additional element of a “non-transitory computer-readable storage medium” merely recites instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea under Prong 2. Therefore, these additional elements do not integrate the judicial exception into a practical application. (MPEP 2106.05(f)). Under Step 2B, since these additional elements merely recite generic computer components to carry out the abstract idea, they do not amount to significantly more than the judicial exception.
Regarding claim 19: this claim is ineligible for the same reasons given for claim 2.
Regarding claim 20: this claim is ineligible for the same reasons given for claim 3.
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.
Claim 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The following claim language is unclear and indefinite:
As per claim 1, term “operating properly” is a relative term which renders the claim indefinite. The term “operating properly” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Independent claims 10 and 18 contain similar language and is rejected for the same reasons. Dependent claims 2-9, 11-17, and 19-20 are rejected due to their dependency on independent claims 1, 18, and 18.
As per claim 4, term “operating properly” is a relative term which renders the claim indefinite. The term “operating properly” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Claim 13 contains similar language and is rejected for the same reasons.
As per claim 4, term “improper operations” is a relative term which renders the claim indefinite. The term “operating properly” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Claim 13 contains similar language and is rejected for the same reasons.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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, 2, 9, 10, 11, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Court et al. (US 20180173550) in view of Cruz et al. (US 20110258701) and Le et al. (ReHype: Enabling VM Survival Across Hypervisor Failures, March 9, 2011, ACM SIGPLAN Notices, Volume 46, Issue 7, Pgs. 63-74).
As per claim 1, Court teaches the invention substantially as claimed including a method of verifying operational status of a plurality of hypervisors, the method comprising:
executing, by a processing device ([0033], because the hypervisor reporters 28, in operation, are components of some computing device (in this example the computing device 26), functionality implemented by a hypervisor reporter 28 may be attributed to the computing device 26 generally), respective diagnostic applications [in the plurality of hypervisors] ([0023], Reporting processes, referred to herein as hypervisor reporters, are capable of generating reports about hypervisors and the virtual machines associated with such hypervisors, and report such information to a monitoring node; and [0032], hypervisor reporters 28 interact with the hypervisors 20 to identify the VMs 24 that are associated with the hypervisors 20. In the example of a hypervisor framework 22, the respective hypervisor reporter 28 may interact with the hypervisor framework 22 to learn about the hypervisors 20 that are part of the hypervisor framework 22, as well as the VMs 24 associated with such hypervisors 20);
collecting, [from the plurality of hypervisors], a plurality of status reports for the plurality of hypervisors ([0032], hypervisor reporters 28 interact with the hypervisors 20 to identify the VMs 24 that are associated with the hypervisors 20. In the example of a hypervisor framework 22, the respective hypervisor reporter 28 may interact with the hypervisor framework 22 to learn about the hypervisors 20 that are part of the hypervisor framework 22, as well as the VMs 24 associated with such hypervisors 20; [0046], the hypervisor reporter 28-1 may request from the hypervisors 20-1, 20-2 information regarding the VMs 24 that are currently associated with the hypervisors 20-1, 20-2; and [0052], The hypervisor reporter 28-2 obtains the status of the hypervisors 20-1, 20-2 and generates a full report for each of the hypervisors 20-1, 20-2 (step 2040)), wherein each of the plurality of status reports indicates whether a corresponding hypervisor is operating properly ([0031], each hypervisor reporter 28 is configured to generate reports about one or more hypervisors 20 over time that identify a status of the hypervisor 20. The term “status” in this context refers to information about a hypervisor 20 as well as the VMs 24 associated with the hypervisor 20); and
grouping a first subset of the plurality of status reports corresponding to proper operations ([0039], monitoring node 14 generates information 40 based on the reports received from the hypervisor reporters 28. The information 40 may include, for example, a record 42-1-42-3 that corresponds to each hypervisor 20-1-20-3. The record 42-1 may include, for example, an identifier 44 that uniquely identifies the respective hypervisor 20-1. The record 42-1 includes status info 46 that identifies the status of the hypervisor 20-1 at the instant of time of FIG. 1. By way of non-limiting example, the status info 46 may include ... a current state of the VMs 24-1A and 24-2A. For example, a state of the VMs 24-1A and 24-2A may be “paused,” “running,” “stopping,” or the like) and collecting hypervisor information of the first subset of the plurality of status reports ([0039], The record 42-1 may include, for example, an identifier 44 that uniquely identifies the respective hypervisor 20-1. The record 42-1 includes status info 46 that identifies the status of the hypervisor 20-1 at the instant of time of FIG. 1);
generating, by the processing device, a report summarizing the hypervisor information of the first subset of the plurality of status reports ([0039], monitoring node 14 generates information 40 based on the reports received from the hypervisor reporters 28. The information 40 may include, for example, a record 42-1-42-3 that corresponds to each hypervisor 20-1-20-3. The record 42-1 may include, for example, an identifier 44 that uniquely identifies the respective hypervisor 20-1. The record 42-1 includes status info 46 that identifies the status of the hypervisor 20-1 at the instant of time of FIG. 1. By way of non-limiting example, the status info 46 may include identifiers that identify the VMs 24-1A and 24-2A, and metadata associated with the hypervisor 20-1 and that of the VMs 24-1A and 24-2A, such as a current state of the VMs 24-1A and 24-2A) [and repairment status of the corresponding hypervisors associated with the second subset of the plurality of status reports].
Although Court teaches diagnostic applications (i.e. “hypervisor reporters” ) interacting with hypervisors, Court fails to specifically teach respective diagnostic applications in the plurality of hypervisors; and collecting, from the plurality of hypervisors, a plurality of status reports for the plurality of hypervisors.
However, Cruz teaches, respective diagnostic applications in the plurality of hypervisors ([0011], a hypervisor 54 (54a-d) includes a platform agent (PA) 62 (62a-d); and [0024], platform agent 62 may monitor the behavior of hypervisor 54 to detect potential attacks); and
collecting, from the plurality of hypervisors, a plurality of status reports for the plurality of hypervisors ([0011], a hypervisor 54 (54a-d) includes a platform agent (PA) 62 (62a-d) ; [0024], platform agent 62 may report the behavior to platform manager 40).
Court and Cruz are analogous because they are each related to monitoring virtualized environments. Court teaches a method of monitoring hypervisors and their corresponding virtual machines and generating reports based on the monitored information. ([0023], Reporting processes, referred to herein as hypervisor reporters, are capable of generating reports about hypervisors and the virtual machines associated with such hypervisors, and report such information to a monitoring node). Cruz teaches an agent within each hypervisor that performs monitoring and hypervisor lifecycle management including performing hypervisor repairs ([0024], Platform agent 62 may perform any suitable operations. For example, platform agent 62 may monitor the behavior of hypervisor 54 to detect potential attacks... If platform agent 62 detects a potential threat, platform agent 62 may report the behavior to platform manager 40. As another example, platform agent 62 may recognize an attack by using known attack signatures; and [0025], in response to instructions by platform manager 40, platform agent 62 may also perform operations to respond to a potential attack. In the embodiments, platform agent 62 may clean, for example, a hypervisor 54 and/or configure the cleaned hypervisor 54). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, Court’s hypervisor and diagnostic application (i.e. “hypervisor reporter”) would be modified to include Cruz’s mechanism for incorporating its diagnostic application (i.e. “platform agent”) within its hypervisor resulting in a hypervisor-based mechanism for monitoring and reporting hypervisor information. Therefore, it would have been obvious to combine the teachings of Court and Cruz.
The combination of Court-Cruz fails to specifically teach, grouping a second subset of the plurality of status reports corresponding to improper operations; and generating, by the processing device, a report summarizing the hypervisor information of the first subset of the plurality of status reports and repairment status of the corresponding hypervisors associated with the second subset of the plurality of status reports.
However, Le teaches, grouping a second subset of the plurality of status reports corresponding to improper operations (Table 2; and Section 5, Pg. 71, As summarized in Table 2, the outcome of each injection run is classified as: detected (VMM crash/hang), [or] silent (undetected failure); and Section 5, Pg. 71, A fault injection campaign consists of many fault injection runs...At the end of each run, fault injection logs and benchmark output are retrieved and stored for analysis) and executing respective repair applications in corresponding hypervisors associated with the second subset of the plurality of status reports (Section 2.2., Pg. 64, Repair is initiated when the detection mechanism invokes a failure handler. Corrupted VMM state can then be repaired by either identifying and fixing the specific parts of the VMM state that are corrupted or simply booting a new VMM instance); and
generating, by the processing device, a report summarizing the hypervisor information of the first subset of the plurality of status reports (Section 5, Pg. 71, As summarized in Table 2, the outcome of each injection run is classified as:...non-manifested... .. Non-manifested means that no errors are observed; and Section 5, Pg. 71, A fault injection campaign consists of many fault injection runs. A single fault injection run that uses the 1AppVM system configuration consists of first booting the VMM along with the PrivVM and AppVM. The AppVM begins running the blkbench benchmark and a fault is injected into the VMM...At the end of each run, fault injection logs and benchmark output are retrieved and stored for analysis) and repairment status of the corresponding hypervisors associated with the second subset of the plurality of status reports (Table 3; Table 4; Section 4, Pg. 69, As shown in Table 3, with the Basic recovery scheme (Section 3), the successful recovery rate is only 5.6%. A large fraction of recovery failures (44%) occur because the failure handler is unable to initiate the VMM microreboot ...Table 3 shows an increase in recovery success rate to 17.6% when these fixes are used. Only 8.2% of the failures are now caused by an inability to initiate the VMM microreboot; Section 4, Pg. 70, As shown in Table 4, with the 3AppVM setup, the reinitialize locks mechanism results in a recovery success rate of 90.2%. Hence, there is a small decrease in the success rate compared to the 1AppVM setup. Out of the remaining recovery failures, 25% are due to the VMM hanging immediately after recovery).
Le also teaches, grouping a first subset of the plurality of status reports corresponding to proper operations (Table 2; and Pg. 71, Section 5, As summarized in Table 2, the outcome of each injection run is classified as:...non-manifested) and collecting hypervisor information of the first subset of the plurality of status reports (Table 2, “Non-manifested;” and Pg. 71, Section 5, As summarized in Table 2, the outcome of each injection run is classified as: detected (VMM crash/hang), silent (undetected failure), or non-manifested... Non-manifested means that no errors are observed).
The combination of Court-Cruz and Le are analogous because they are each related to monitoring virtualized environments. Court teaches a method of monitoring hypervisors and their corresponding virtual machines and generating reports based on the monitored information. Cruz teaches an agent within each hypervisor that performs monitoring and hypervisor lifecycle management including performing hypervisor repairs. Le teaches a method of hypervisor monitoring and reporting including reporting the status of hypervisor repair actions. (Section 1, Pg. 63, This paper introduces and evaluates a mechanism for recovery from hypervisor failures called ReHype. To the best of our knowledge, ReHype is the first mechanism that allows VMs to survive hypervisor failure without any loss of work in progress and without any performance overhead during normal operation. Upon hypervisor failure, ReHype boots a new hypervisor instance while preserving the state of running VMs; and Section 5, Pg. 71, A fault injection campaign consists of many fault injection runs... At the end of each run, fault injection logs and benchmark output are retrieved and stored for analysis). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the hypervisor management mechanisms taught by the combination of Court-Cruz would be modified with the logging and hypervisor recovery mechanisms taught by Le resulting in a system that monitors, repairs, and creates reports for hypervisors and their associated virtual machines. Therefore, it would have been obvious to combine the teachings of the combination of Court-Cruz and Le.
As per claim 2, Court teaches, wherein executing, by the processing device, the respective diagnostic applications in the plurality of hypervisors comprises at least one of:
periodically executing the respective diagnostic applications in the plurality of hypervisors at a time interval ([0031], each hypervisor reporter 28 is configured to generate reports about one or more hypervisors 20 over time that identify a status of the hypervisor 20; [0048], hypervisor reporter 28-1 may learn about such changes, for example, by periodically or intermittently polling the hypervisors 20-1, 20-2 at a current time and comparing the status to a previously determined status that was determined at a previous time. In some examples the hypervisor reporter 28-1 may poll the hypervisors 20-1, 20-2 every second, or every two seconds, or at any other desirable period; [0050], Periodically, the hypervisor reporter 28-2 may send the monitoring node 14 a “heartbeat” communication indicating that the hypervisor reporter 28-2 is still executing and communicating (step 2030); and [0078], waiting a period of time; not sending a report about the first hypervisor over the period of time; and sending, to the monitoring node, at the end of the period of time, a communication that indicates that the hypervisor reporter is still functioning), or
executing, in response to a trigger condition being satisfied, the respective diagnostic applications in the plurality of hypervisors , wherein the trigger condition comprises detecting, by the processing device, that a virtual machine of the plurality of hypervisors has hung.
As per claim 9, Court teaches, wherein the plurality of hypervisors comprises hypervisors belonging to various servers ([0028], Each computing device 18-1-18-3 includes a corresponding hypervisor 20-1-20-3 (generally, hypervisor 20 or hypervisors 20)).
As per claim 10, this is the “apparatus claim” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 11, this claim is similar to claim 2 and is rejected for the same reasons.
As per claim 18, this is the “non-transitory computer-readable storage medium” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 19, this claim is similar to claim 2 and is rejected for the same reasons.
Claims 3, 4, 6, 12, 13, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Court-Cruz-Le as applied to independent claims 1, 10, and 18 and in further view of Frascadore et al. (US 20140331277).
As per claim 3, Le teaches, wherein grouping the first subset of the plurality of status reports corresponding to proper operations and collecting hypervisor information of the first subset of the plurality of status reports comprise:
placing an indicator in each hypervisor corresponding to the first subset of the plurality of status reports of proper operations (Section 5, Pg. 71, As summarized in Table 2, the outcome of each injection run is classified as: detected (VMM crash/hang), [or] silent (undetected failure); and Section 5, Pg. 71, A fault injection campaign consists of many fault injection runs...At the end of each run, fault injection logs and benchmark output are retrieved and stored for analysis) .
The combination of Court-Cruz-Le fails to specifically teach, printing, with the indicator for each hypervisor in the generated report, the collected hypervisor information of the first subset of the plurality of status reports.
However, Frascadore teaches, printing, with the indicator for each hypervisor in the generated report, the collected hypervisor information of the first subset of the plurality of status reports ([0041], compliance monitor 218 of FIG. 3 includes the example reporter 318 to generate reports based on information stored in the compliance database 308. For example, the reporter 318 of the illustrated example retrieves assessment results stored in the results database 312 and generates a report identifying the assessment results for a computing resource(s), a policy (or policies) that was/were tested, satisfied and/or failed, the virtual computing environment 100, etc... the reporter 318 retrieves compliance scores from the scores database 314 and generates a report identifying the compliance scores for a computing resource(s), a policy (or policies), the virtual computing environment 100, etc. In some examples, the reporter 318 retrieves rankings from the priority order database 316 and generate a report identifying the ranked order of the assessment results to facilitate correcting issues in an order consistent with past practices. The example reporter 318 of FIG. 3 may generate reports as documents for printout, as a graphical user interface for display via, for example, a monitor, etc.).
The combination of Court-Cruz-Le and Frascadore are analogous because they are each related to monitoring virtualized environments. Court teaches a method of monitoring hypervisors and their corresponding virtual machines and generating reports based on the monitored information. Cruz teaches an agent within each hypervisor that performs monitoring and hypervisor lifecycle management including performing hypervisor repairs. Le teaches a method of hypervisor monitoring and reporting including reporting the status of hypervisor repair actions. Frascadore teaches a method of monitoring, grouping, and repairing detected events in a virtualized system. ([0034], the core services controller 216 may include ... an example statistics logger 234 (to log and report performance and resource usage statistics of computing resources such as virtual machines, hosts, storage devices, and/or clusters), an example alarms and events manager 236 (to track and warn users about potential resource overuse or event conditions); [0035], the core services controller 216 includes an example compliance monitor 218 to monitor policy compliance of the virtual computing environment 100). Frascadore also teaches creating and printing reports based on monitoring information. ([0041], The example compliance monitor 218 of FIG. 3 includes the example reporter 318 to generate reports based on information stored in the compliance database 308; and [0171], aggregates defects into defect classes by grouping the defects sharing a common asset class and having the same repair action... The example reporter 318 of FIG. 3 may generate reports as documents for printout, as a graphical user interface for display via, for example, a monitor, etc.). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the hypervisor management mechanisms taught by the combination of Court-Cruz-Le would be modified with the monitoring and reporting, including printing reports, mechanisms taught by Frascadore resulting in a system that monitors, repairs, and creates reports for hypervisors and their associated virtual machines. Therefore, it would have been obvious to combine the teachings of the combination of Court-Cruz-Le and Frascadore.
As per claim 4, Court teaches, further comprising:
evaluating status for a plurality of virtual machines running in the plurality of hypervisors ([0023], A report generated by a hypervisor reporter...may identify each virtual machine associated with each hypervisor, as well as metadata associated with the virtual machines, such as a status of the virtual machine, and the like; and [0039], record 42-1 includes status info 46 that identifies...the status info 46 may include identifiers that identify the VMs 24-1A and 24-2A, and metadata associated with the hypervisor 20-1 and that of the VMs 24-1A and 24-2A, such as a current state of the VMs 24-1A and 24-2A. For example, a state of the VMs 24-1A and 24-2A may be “paused,” “running,” “stopping,” or the like);
collecting,[from the plurality of virtual machines], a plurality of virtual-machine (VM) status reports for the plurality of virtual machines ([0023], A report generated by a hypervisor reporter in such an environment can contain a substantial amount of data, because the report may identify each virtual machine associated with each hypervisor, as well as metadata associated with the virtual machines, such as a status of the virtual machine, and the like), wherein each of the plurality of VM status reports indicates whether a corresponding virtual machine is operating properly ([0023], A report generated by a hypervisor reporter in such an environment can contain a substantial amount of data, because the report may identify each virtual machine associated with each hypervisor, as well as metadata associated with the virtual machines, such as a status of the virtual machine, and the like; [0031], each hypervisor reporter 28 is configured to generate reports about one or more hypervisors 20 over time that identify a status of the hypervisor 20. The term “status” in this context refers to information about a hypervisor 20 as well as the VMs 24 associated with the hypervisor 20; and [0046], The full report may include any desired information, such as, by way of non-limiting example, metadata about the hypervisors 20, and metadata about the VMs 24); and
grouping a third subset of the plurality of VM status reports corresponding to proper VM operations ([0039], record 42-1 includes status info 46 ...the status info 46 may include identifiers that identify the VMs 24-1A and 24-2A, and metadata associated with the hypervisor 20-1 and that of the VMs 24-1A and 24-2A, such as a current state of the VMs 24-1A and 24-2A. For example, a state of the VMs 24-1A and 24-2A may be “paused,” [and] “running,”) and collecting VM information of the third subset of the plurality of VM status reports ([0023], A report generated by a hypervisor reporter in such an environment can contain a substantial amount of data, because the report may identify each virtual machine associated with each hypervisor, as well as metadata associated with the virtual machines, such as a status of the virtual machine, and the like; and [0039], record 42-1 includes status info 46 ...the status info 46 may include identifiers that identify the VMs 24-1A and 24-2A); and
generating, by the processing device in the report, a VM summary of the VM information of the third subset of the plurality of VM status reports ([0039], record 42-1 includes status info 46 ...the status info 46 may include identifiers that identify the VMs 24-1A and 24-2A, and metadata associated with the hypervisor 20-1 and that of the VMs 24-1A and 24-2A, such as a current state of the VMs 24-1A and 24-2A. For example, a state of the VMs 24-1A and 24-2A may be “paused,” [and] “running,” “stopping,” ...) and repairment status of the corresponding virtual machines associated with the fourth subset of VM status reports.
Court fails to specifically teach, collecting, from the plurality of virtual machines, a plurality of virtual-machine (VM) status reports for the plurality of virtual machines; and grouping a fourth subset of the plurality of VM status reports corresponding to improper operations and executing respective repair applications in corresponding virtual machines associated with the fourth subset of VM status reports.
However, Frascadore teaches, collecting, from the plurality of virtual machines, a plurality of virtual-machine (VM) status reports for the plurality of virtual machines ([0044], test the identified computing resource(s) for policy compliance; and [0068], compliance assessor 302 includes the example timer 516 to maintain a regular polling interval between batch tests. For example, the timer 516 may initiate the batch tester 514 periodically (e.g., every thirty minutes) to batch test the virtual computing environment 100. In some examples, the polling interval may be dynamic and vary based on, for example, a workload. In this manner, the example compliance assessor 302 may perform event-driven assessments (e.g., via the event monitor 510) and regular (e.g., periodic) batch tests (e.g., via the batch tester 514); Examiner Note: Frascadore’s “computing resources” include virtual machines: [0021], Computing resources include ... virtual machines...); and
grouping a fourth subset of the plurality of VM status reports corresponding to improper operations ([0041], example reporter 318 to generate reports based on information stored in the compliance database 308. For example, the reporter 318 of the illustrated example retrieves assessment results stored in the results database 312 and generates a report identifying the assessment results for a computing resource(s), a policy (or policies) that was/were tested, satisfied and/or failed, the virtual computing environment 100, etc... the reporter 318 retrieves compliance scores from the scores database 314 and generates a report identifying the compliance scores for a computing resource(s), a policy (or policies), the virtual computing environment 100, etc. In some examples, the reporter 318 retrieves rankings from the priority order database 316 and generate a report identifying the ranked order of the assessment results to facilitate correcting issues in an order consistent with past practices; Examiner Note: Frascadore’s “computing resources” include virtual machines: [0021], Computing resources include ... virtual machines...) and executing respective repair applications in corresponding virtual machines associated with the fourth subset of VM status reports ([0166], When a defect is generated, the associated computing resource and rule, including the scope condition results and the rule check condition, may be logged. In the illustrated example, each defect has an associated repair action to correct the defect).
The same motivation used in the rejection of claim 3 is applicable to the instant claim.
As per claim 6, Court teaches, wherein the VM summary of the VM information of the third subset of the plurality of VM status reports comprises:
resources occupied by properly operating virtual machines of the plurality of hypervisors ([0046], full report may include any desired information, such as, by way of non-limiting example, metadata about the hypervisors 20, and metadata about the VMs 24, such as the number of central processing unit cores for each VM 24, the memory assigned to each VM 24, and any other suitable information); and
identifications of the properly operating virtual machines of the plurality of hypervisors ([0023], the report may identify each virtual machine associated with each hypervisor, as well as metadata associated with the virtual machines, such as a status of the virtual machine, and the like; and [0039], the status info 46 may include identifiers that identify the VMs 24-1A and 24-2A, and metadata associated with the hypervisor 20-1 and that of the VMs 24-1A and 24-2A, such as a current state of the VMs 24-1A and 24-2A. For example, a state of the VMs 24-1A and 24-2A may be “paused,” [or] “running,”...).
As per claim 12, this claim is similar to claim 3 and is rejected for the same reasons. The same motivation used in the rejection of claim 3 is applicable to the instant claim.
As per claim 13, this claim is similar to claim 4 and is rejected for the same reasons.
As per claim 15, this claim is similar to claim 6 and is rejected for the same reasons.
As per claim 20, this claim is similar to claim 3 and is rejected for the same reasons. The same motivation used in the rejection of claim 3 is applicable to the instant claim.
Claims 5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Court-Cruz-Le-Frascadore as applied to dependent claims 3 and 12 and in further view of Macha et al. (US 20190205180).
As per claim 5, the combination of Court-Cruz-Le-Frascadore fails to specifically teach, wherein the repairment status of the corresponding virtual machines comprise identifications of irreparable virtual machines.
However, Macha teaches, wherein the repairment status of the corresponding virtual machines comprise identifications of irreparable virtual machines (Figs. 6B1-6B8, App # column and CR columns; [0174], Figure sequence 6B1-6B7 is an example implementation of how the BCHA system 200 works to identify and remediate the failure of an BCHA computing resource 240/250 and redeployment of redistribution elements associated with the failed BCHA computing resource 240/250... Each of the FIGS. 6B1-6B7 illustrate the key operational states associated with each of the steps the BCHA system executes to remediate a Resource Failure Detection as Execution Timeline 699; and [0186], Resource Failure Detection remediation state determination demonstrates that BCHA system goals (1) and (1A) have been met, 1B fails because if at least one BCHA application 268 High Availability Requirement is not met, BCHA system High Availability Requirement also fail; Examiner Note: Macha’s “computing resource” comprises a virtual machine: [0069], a BCHA machine or a BCHA computing resource can be a physical machine or a virtual machine with an operating system capable of hosting one or more BCHA applications).
The combination of Court-Cruz-Le-Frascadore and Macha are analogous because they are each related to monitoring virtualized environments. Court teaches a method of monitoring hypervisors and their corresponding virtual machines and generating reports based on the monitored information. Cruz teaches an agent within each hypervisor that performs monitoring and hypervisor lifecycle management including performing hypervisor repairs. Le teaches a method of hypervisor monitoring and reporting including reporting the status of hypervisor repair actions. Frascadore teaches a method of monitoring, grouping, and repairing detected events in a virtualized system. Macha teaches a method of maintaining high availability in a virtualized environment including monitoring resources, reporting monitoring information, and remediating resources based on monitoring information. ([0058], the disclosed technology monitors and reports a key performance indicator (KPI) such as BCHA system and/or BCHA computing resource availability and generates operational system metrics/recommendations for system operators to achieve the real time reliability and availability targets established for a particular BCHA system; and [0074], BCHA system availability may be established with additional thresholds that initiate remediative action based on risk tolerances of a system operator, the characteristics/operational constraints associated with a particular process and/or application, and/or a variety of other operational metrics). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the hypervisor management mechanisms taught by the combination of Court-Cruz-Le-Frascadore would be modified with the monitoring and remediation mechanisms taught by Macha resulting in a system that performs monitoring and remediates errors in virtual resources. Therefore, it would have been obvious to combine the teachings of the combination of Court-Cruz-Le-Frascadore and Macha.
As per claim 14, this claim is similar to claim 5 and is rejected for the same reasons. The same motivation used in the rejection of claim 5 is applicable to the instant claim.
Claims 7, 8, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Court-Cruz-Le-Frascadore as applied to dependent claims 4 and 13 and in further view of Kaila et al. (US 20230004413) .
As per claim 7, Cruz teaches, creating one or more hypervisors in the plurality of hypervisors based on the resources occupied by the properly operating virtual machines ([00025], Platform agent 62 may also move a virtual machine 56 from one hypervisor 54 to another hypervisor 54 in response to an instruction by platform manager 40. The new hypervisor may be ready to accept new virtual machines 56; and [0029], Platform manager 40 may also generate new hypervisors 54 to replace hypervisors that may have been subject to a potential attack).
The combination of Court-Cruz-Le-Frascadore fails to specifically teach, further comprising: disabling one or more hypervisors in the plurality of hypervisors based on the resources occupied by the properly operating virtual machines.
However, Kaila teaches, further comprising: disabling one or more hypervisors in the plurality of hypervisors based on the resources occupied by the properly operating virtual machines ([0002], hypervisor can include a maintenance mode where the VMs running thereon are migrated to other host(s) in the cluster with spare capacity, which frees the hypervisor to be patched/upgraded/configured without affecting VM operations; and [0035], At step 416, remediation software 153 requests migration of VMs 140 from host 120 to oilier host(s) 120 in host cluster 118 and requests hypervisor 150 enter into maintenance mode. Maintenance mode for hypervisor 150 allows hypervisor 150 to perform lifecycle operations).
The combination of Court-Cruz-Le-Frascadore and Kaila are analogous because they are each related to monitoring virtualized environments. Court teaches a method of monitoring hypervisors and their corresponding virtual machines and generating reports based on the monitored information. Cruz teaches an agent within each hypervisor that performs monitoring and hypervisor lifecycle management including performing hypervisor repairs. Le teaches a method of hypervisor monitoring and reporting including reporting the status of hypervisor repair actions. Frascadore teaches a method of monitoring, grouping, and repairing detected events in a virtualized system. Kaila teaches a method executing repair actions on virtual resources based on monitored system information. (Abstract, obtaining, by remediation software executing in a host of the hosts, a host state document from a distributed key-value store, the host state document defining a desired state of software in the host, the software including a hypervisor; and performing, by the remediation software in coordination with other hosts of the hosts through the distributed key-value store, a lifecycle operation on the software of the host in response to determining that a current state of the software does not match the desired state; and [0002], A hypervisor can include a maintenance mode where the VMs running thereon are migrated to other host(s) in the cluster with spare capacity, which frees the hypervisor to be patched/upgraded/configured without affecting VM operations). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the hypervisor taught by the combination of Court-Cruz-Le-Frascadore would be modified with the repair mechanisms taught by Kaila resulting in a system that performs monitoring and remediates errors in virtual resources. Therefore, it would have been obvious to combine the teachings of the combination of Court-Cruz-Le-Frascadore and Kaila.
As per claim 8, the combination of Court-Cruz-Le fails to specifically teach, wherein grouping the second subset of the plurality of status reports corresponding to improper operations and executing respective repair applications in corresponding hypervisors associated with the second subset of the plurality of status reports comprise: determining one or more hypervisors having executed respective repair applications to be irreparable; and removing the one or more irreparable hypervisors from the plurality of hypervisors.
However, Kaila teaches, wherein grouping the second subset of the plurality of status reports corresponding to improper operations and executing respective repair applications in corresponding hypervisors associated with the second subset of the plurality of status reports comprise:
determining one or more hypervisors having executed respective repair applications to be irreparable ([0034], remediation software 153 can check the desired state specified in host state document 142 for any errors. If at step 410 host state document 142 is invalid, method 400 proceeds to step 412, where remediation software 153 exists with invalid status indicating that the remediation operation is not successful; Examiner Note: Kaila’s “remediation software” monitors a hypervisor and manages its lifecycle: [0027], Remediation software 153 performs lifecycle operations on hypervisor 150; a[0029], remediation software 153 in a host 120 detects or is notified of host state document 142. For example, remediation software 153 can periodically monitor DKVS 171 to determine if a new host state document is available. In another example, remediation software 153 can receive a notification from DKVS 171 or virtualization management server 116 that a new host state document is available; and [0030], remediation software 153 determines compliance of hypervisor 150 with host state document 142 ); and
removing the one or more irreparable hypervisors from the plurality of hypervisors ([0035], At step 416, remediation software 153 requests migration of VMs 140 from host 120 to oilier host(s) 120 in host cluster 118 and requests hypervisor 150 enter into maintenance mode. Maintenance mode for hypervisor 150 allows hypervisor 150 to perform lifecycle operations; and [0036], remediation software 153 executes one or more lifecycle operations to make hypervisor 150 compliant with the desired state as specified in host state document 142. Example lifecycle operations include...changing the configuration of hypervisor 150).
The same motivation applied to the rejection of claim 7 is applicable to the instant claim. The same motivation applied to the rejection of claim 7 is applicable to the instant claim.
As per claim 16, this claim is similar to claim 7 and is rejected for the same reasons. The same motivation applied to the rejection of claim 7 is applicable to the instant claim.
As per claim 17, this claim is similar to claim 8 and is rejected for the same reasons. The same motivation applied to the rejection of claim 7 is applicable to the instant claim.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Cao et al. (US 20150331761): Teaches hypervisor monitoring and responding to hypervisor failures (Abstract, The host swap hypervisor resides on the physical host computer that runs the primary hypervisor, and monitors failure indicators of the primary hypervisor. When the failure indicators exceed a threshold, the host swap hypervisor is then autonomically swapped to become the primary hypervisor on the physical host computer. The original primary hypervisor may then be re-initialized as the new host swap hypervisor; and [0062], monitor 520 of the host swap hypervisor 322 shown in FIG. 5 actively monitors the host environment and continually refreshes information about the state of the environment); and
Bhide et al. (US 20170075714): Teaches monitoring and reporting in virtualized systems: ([0025], performance data is stored as “events,” wherein each event comprises a collection of performance data and/or diagnostic information that is generated by a computer system and is correlated with a specific point in time;; and [0070], Virtual center 730 additionally obtains performance-related data from hypervisors 704, 714 and 724. This performance-related data is sent to a forwarder 101, which forwards the performance-related data to an indexer 102, wherein indexer 102 stores the data in data store 103).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MELISSA A HEADLY whose telephone number is (571)272-1972. The examiner can normally be reached Monday- Friday 9-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MELISSA A HEADLY/Examiner, Art Unit 2197
Prosecution Insights