CTNF 18/607,191 CTNF 89904 DETAILED ACTION 07-03-aia AIA 15-10-aia 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). Double Patenting 08-33 AIA The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg , 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman , 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi , 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum , 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel , 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington , 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA/25, or PTO/AIA/26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp. Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of co-pending application no. 18/607,212. Although the conflicting claims are not identical, they are not patentably distinct from each other because both applications comprise substantially the same elements and cover the same subject matter. As can be seen from the table below, taking claim 1 as exemplary, both claims have similar features. This is a provisional statutory double patenting rejection since the claims directed to the same invention have not in fact been patented. Instant Application: 18607191 Co-Pending Application No. 18607212 1. A method of hypervisor lifecycle management in a virtualized computing system having a cluster of hosts, the method comprising: obtaining, by a lifecycle manager (LCM) agent executing in a host of the hosts, a desired state document, the desired state document defining a desired state of software in the host, the software including a hypervisor; comparing selection criteria in the desired state document against hardware information obtained from a hardware platform of the host to select an image of a plurality of images defined in the desired state document; and applying, by LCM agent, the selected image to the host. 1. A method of hypervisor lifecycle management in a virtualized computing system having a cluster of hosts, the method comprising: obtaining, by a lifecycle manager (LCM) agent executing in a host of the hosts, a desired state document, the desired state document defining a desired state of software in the host, the software including a hypervisor, the desired state including a plurality of images; comparing selection criteria in a software policy of the desired state document against hardware information obtained from a hardware platform of the host to select an image of the plurality of images defined in the desired state document; and applying, by LCM agent, the selected image to the host. 2. The method of claim 1, wherein the desired state document defines a default image and an alternative image, the alternative image associated with the selection criteria. 2. The method of claim 1, wherein the desired state document defines a default image and an alternative image, and wherein the software policy includes selection criteria for the alternative image. 3. The method of claim 2, wherein the default image is not associated with any selection criteria. 3. The method of claim 2, wherein the default image is not associated with any selection criteria in the software policy. 4. The method of claim 2, further comprising: determining, by the LCM agent, that the hardware information matches the selection criteria; wherein the selected image comprises the alternative image. 4. The method of claim 2, further comprising: determining, by the LCM agent, that the hardware information matches the selection criteria; wherein the selected image comprises the alternative image. 5. The method of claim 2, further comprising: determining, by the LCM agent, that the hardware information does not match the selection criteria; wherein the selected image comprises the default image. 5. The method of claim 2, further comprising: determining, by the LCM agent, that the hardware information does not match the selection criteria; wherein the selected image comprises the default image. 6. The method of claim 1, further comprising: receiving, at an LCM from a user, a draft of the desired state document; and committing, by the LCM, the draft to generate the desired state document. 6. The method of claim 1, further comprising: receiving, at an LCM from a user, a draft of the desired state document, the draft including specifications for each of the plurality of images and a software policy document defining the software policy; and committing, by the LCM, the draft to generate the desired state document. 7. The method of claim 1, wherein the selection criteria includes a host identifier or a hardware specification. 7. The method of claim 1, wherein the selection criteria includes a host identifier or a hardware specification. 8. A non-transitory computer readable medium comprising instructions to be executed in a computing device to cause the computing device to carry out a method of hypervisor lifecycle management in a virtualized computing system having a cluster of hosts, the method comprising: obtaining, by a lifecycle manager (LCM) agent executing in a host of the hosts, a desired state document, the desired state document defining a desired state of software in the host, the software including a hypervisor; comparing selection criteria in the desired state document against hardware information obtained from a hardware platform of the host to select an image of a plurality of images defined in the desired state document; and applying, by LCM agent, the selected image to the host. 8. A non-transitory computer readable medium comprising instructions to be executed in a computing device to cause the computing device to carry out a method of hypervisor lifecycle management in a virtualized computing system having a cluster of hosts, the method comprising: obtaining, by a lifecycle manager (LCM) agent executing in a host of the hosts, a desired state document, the desired state document defining a desired state of software in the host, the software including a hypervisor, the desired state including a plurality of images; comparing selection criteria in a software policy of the desired state document against hardware information obtained from a hardware platform of the host to select an image of the plurality of images defined in the desired state document; and applying, by LCM agent, the selected image to the host. 9. The non-transitory computer readable medium of claim 8, wherein the desired state document defines a default image and an alternative image, the alternative image associated with the selection criteria. 9. The non-transitory computer readable medium of claim 8, wherein the desired state document defines a default image and an alternative image, and wherein the software policy includes selection criteria for the alternative image. 10. The non-transitory computer readable medium of claim 9, wherein the default image is not associated with any selection criteria. 10. The non-transitory computer readable medium of claim 9, wherein the default image is not associated with any selection criteria in the software policy. 11. The non-transitory computer readable medium of claim 9, further comprising: determining, by the LCM agent, that the hardware information matches the selection criteria; wherein the selected image comprises the alternative image. 11. The non-transitory computer readable medium of claim 9, further comprising: determining, by the LCM agent, that the hardware information matches the selection criteria; wherein the selected image comprises the alternative image. 12. The non-transitory computer readable medium of claim 11, further comprising: determining, by the LCM agent, that the hardware information does not match the selection criteria; wherein the selected image comprises the default image. 12. The non-transitory computer readable medium of claim 11, further comprising: determining, by the LCM agent, that the hardware information does not match the selection criteria; wherein the selected image comprises the default image. 13. The non-transitory computer readable medium of claim 8, further comprising: receiving, at an LCM from a user, a draft of the desired state document; and committing, by the LCM, the draft to generate the desired state document. 13. The non-transitory computer readable medium of claim 8, further comprising: receiving, at an LCM from a user, a draft of the desired state document, the draft including specifications for each of the plurality of images and a software policy document defining the software policy; and committing, by the LCM, the draft to generate the desired state document. 14. The non-transitory computer readable medium of claim 8, wherein the selection criteria includes a host identifier or a hardware specification. 14. The non-transitory computer readable medium of claim 8, wherein the selection criteria includes a host identifier or a hardware specification. 15. A virtualized computing system having a cluster comprising hosts connected to a network, the virtualized computing system comprising: a distributed key-value store configured to store a desired state document; and a first host of the hosts configured to execute a lifecycle manager (LCM) agent, the LCM agent configured to: obtain the desired state document, the desired state document defining a desired state of software in the host, the software including a hypervisor; compare selection criteria in the desired state document against hardware information obtained from a hardware platform of the host to select an image of a plurality of images defined in the desired state document; and apply the selected image to the host. 15. A virtualized computing system having a cluster comprising hosts connected to a network, the virtualized computing system comprising: a distributed key-value store configured to store a desired state document; and a first host of the hosts configured to execute a lifecycle manager (LCM) agent, the LCM agent configured to: obtain the desired state document, the desired state document defining a desired state of software in the host, the software including a hypervisor, the desired state including a plurality of images; compare selection criteria in a software policy of the desired state document against hardware information obtained from a hardware platform of the host to select an image of the plurality of images defined in the desired state document; and apply the selected image to the host. 16. The virtualized computing system of claim 15, wherein the desired state document defines a default image and an alternative image, the alternative image associated with the selection criteria. 16. The virtualized computing system of claim 15, wherein the desired state document defines a default image and an alternative image, and wherein the software policy includes selection criteria for the alternative image. 17. The virtualized computing system of claim 16, wherein the default image is not associated with any selection criteria. 17. The virtualized computing system of claim 16, wherein the default image is not associated with any selection criteria in the software policy. 18. The virtualized computing system of claim 16, wherein the LCM agent is configured to: determine that the hardware information matches the selection criteria; wherein the selected image comprises the alternative image. 18. The virtualized computing system of claim 16, wherein the LCM agent is configured to: determine that the hardware information matches the selection criteria; wherein the selected image comprises the alternative image. 19. The virtualized computing system of claim 16, wherein the LCM agent is configured to: determine that the hardware information does not match the selection criteria; wherein the selected image comprises the default image. 19. The virtualized computing system of claim 16, wherein the LCM agent is configured to: determine that the hardware information does not match the selection criteria; wherein the selected image comprises the default image. 20. The virtualized computing system of claim 15, wherein the selection criteria includes a host identifier or a hardware specification. 20. The virtualized computing system of claim 15, wherein the selection criteria includes a host identifier or a hardware specification. Claim Rejections - 35 USC § 101 07-04 AIA 07-04-01 5 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. Claim 1 recites: comparing selection criteria in the desired state document against hardware information obtained from a hardware platform of the host to select an image of a plurality of images defined in the desired state document. Step a is a limitation that, as drafted, recites a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion, but for the recitation of generic computer components. Thus it is reasonable to identify these limitations as reciting a mental process under Prong 1 of Step 2A. See , MPEP 2106.04(a)(2) III C). For example, a can person perform the “comparing” step with mental evaluation and judgement. Other than reciting generic computing components, nothing in the claim element precludes the step from practically being performed in the mind. 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 for the following reasons: The additional elements of a “virtualized computing system having a cluster of hosts,” and “lifecycle manager (LCM) agent executing in a host of the hosts” 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)). The additional element of “obtaining, by a lifecycle manager (LCM) agent executing in a host of the hosts, a desired state document, the desired state document defining a desired state of software in the host, the software including a hypervisor” amounts to insignificant extra-solution data gathering activity (MPEP § 2106.05(g)). The additional element of “applying, by LCM agent, the selected image to the host” amounts to using a generic computing component as a tool to apply the abstract idea (MPEP § 2106.05(f)). 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 claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. It is noted here that the elements should be considered both individually and as an ordered combination. In this case, the claimed method, system, and non-transitory computer-readable medium are generically recited and thus do not add significantly more to the respective limitations. Taken as an ordered combination, the 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 include, as a non-limiting or non-exclusive examples: (i) mere instructions to implement the idea on a computer, and/or (ii) recitation of generic computer structure that serves to perform generic computer functions that are well-understood, routine, and conventional activities previously known to the pertinent industry. The limitations that recite specific computer elements do not add significantly more because they are simply an attempt to limit the abstract idea to a particular technological environment. (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.” 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. For the above reasons, the claims of this application are not patentable under 35 USC 101. Regarding claims 2, the additional element of “wherein the desired state document defines a default image and an alternative image, the alternative image associated with the selection criteria” appears to be an attempt to generally linking the use of a judicial exception to a particular technological environment or field of use. (MPEP § 2106.05(h)). Regarding claim 3, the additional element of “wherein the default image is not associated with any selection criteria” appears to be an attempt to generally linking the use of a judicial exception to a particular technological environment or field of use. (MPEP § 2106.05(h)). Regarding claim 4, The step of “ determining, by the LCM agent, that the hardware information matches the selection criteria” recites an additional mental process under Prong 1 since this step 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 recitation of the additional elements of an “LCM agent, 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. The additional element of “wherein the selected image comprises the alternative image” appears to be an attempt to generally linking the use of a judicial exception to a particular technological environment or field of use. (MPEP § 2106.05(h)). Regarding claim 5, the additional element of “further comprising: determining, by the LCM agent, that the hardware information does not match the selection criteria; wherein the selected image comprises the default image” recites an additional mental process under Prong 1 since this step 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 recitation of the additional elements of an “LCM agent, 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 6, the additional element of “receiving, at an LCM from a user, a draft of the desired state document; and committing, by the LCM, the draft to generate the desired state document” amounts to insignificant extra-solution data gathering/data transmission activity (MPEP § 2106.05(g)). Regarding claim 7, the additional element of “wherein the selection criteria includes a host identifier or a hardware specification” appears to be an attempt to generally linking the use of the judicial exception to a particular technological environment or field of use. (MPEP 2106.05(h)). Regarding claim 8, 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 “a non-transitory computer readable medium, 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, this claim is similar to claim 2 and is ineligible for the same reasons as claim 2. Regarding claim 10, this claim is similar to claim 3 and is ineligible for the same reasons as claim 3. Regarding claim 11, this claim is similar to claim 4 and is ineligible for the same reasons as claim 4. Regarding claim 12, this claim is similar to claim 5 and is ineligible for the same reasons as claim 6. Regarding claim 13, this claim is similar to claim 6 and is ineligible for the same reasons as claim 6. Regarding claim 14, this claim is similar to claim 7 and is ineligible for the same reasons as claim 6. Regarding claim 15, 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 “virtualized computing system,” and “a distributed key-value store configured to store a desired state document” 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 16, this claim is similar to claim 2 and is ineligible for the same reasons as claim 2. Regarding claim 17, this claim is similar to claim 3 and is ineligible for the same reasons as claim 3. Regarding claim 18, this claim is similar to claim 4 and is ineligible for the same reasons as claim 4. Regarding claim 19, this claim is similar to claim 5 and is ineligible for the same reasons as claim 5. Regarding claim 20, this claim is similar to claim 7 and is ineligible for the same reasons as claim 7. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-23-aia AIA 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. 07-21-aia AIA Claim s 1-14 are rejected under 35 U.S.C. 103 as being unpatentable over Haryadi et al. (US 20210311717 A1) in view of Li et al. (US 20220188091 A1) . As per claim 1, Haryadi teaches the invention substantially as claimed including a method of hypervisor lifecycle management in a virtualized computing system ([0021], a virtualized computing system 10 that implements a desired state model for managing the lifecycle of virtualization software according to embodiments) having a cluster of hosts ([0021], System 10 includes a cluster of hosts 131) , the method comprising: obtaining, by a lifecycle manager (LCM) agent executing in a host of the hosts, a desired state document ([0023], VM management server 100 is a physical or virtual server that communicates with hypervisor 150 of each host 131 to provision VMs 140 from the hardware resources of host 131; and [0026], Coordinator 114 communicates with image manager 152 of each of hosts 131 through an API call to install desired image 125 in each of hosts 131; Examiner Note: Haryadi’s VM Management Server includes Coordinator 114; Fig. 1, VM Mgmt Server 100 ) , the desired state document defining a desired state of software in the host ([0024], One example form for expressing the desired state is a software specification 105, which is generated based on selections made through UI 101. The selections that can be made through UI 101 include (1) base image, (2) add-on, (3) solution, (4) user component(s), and (5) firmware package (see FIG. 2). Image manager 112 consumes software specification 105 to composite a desired image that is modeled as a hierarchical software stack, including (1) the base image, which is the lowest layer of the software stack, (2) the add-on, which is layered on top of the base image, (3) firmware manifest corresponding to the selected firmware package in the layer above the add-on, and then on the top (4) solution drivers and agents and other user components), the software including a hypervisor ([0024], the end user expresses the desired state of the virtualization software (i.e., hypervisor 150) for the cluster of hosts through a UI 101 of VM management server 100); comparing selection criteria in the desired state document against hardware information ([0048], In response to the scan API, image manager 152 at step S3, accesses desired image 125 and retrieves the current state of the virtualization software from image database 153, and compares the two to determine if each item of desired image 125 other than the firmware manifest (e.g., base image, add-on, solution, or user component) is “incompatible” (which means that desired image 125 cannot be applied, e.g., when the current state is running a higher version of an item), “compliant” (which means that the current state matches the desired state), non-compliant (which means that the current state can be upgraded to the desired state), or unknown (which means that a comparison of the current state could not be made with the item in desired image 125 because the item in desired image 125 is unknown or not recognizable); and [0051], Coordinator 114 at step S8 issues a pre-check API to image manager 152 of each host 131 and to hardware support manager 170. In response to the pre-check API, image manager 152 of each host 131 at step S9 accesses desired image 125 and retrieves the current state of the virtualization software from image database 153, and compares the two to determine whether or not the virtualization software in the host can be upgraded to desired image 125 at that time, and performs several other checks on the host and at step S10 sends the results of the checks to coordinator 114) obtained from a hardware platform of the host ([0043], image manager 112 acquires the hardware inventory of the host, e.g., from a hardware discovery service that is running in VM management server 100) to select an image ...defined in the desired state document ([0039], image manager 112 at step 332 processes the firmware manifest corresponding to the selected firmware package to add and remove components in the same manner as the selected add-on was processed. Then, image manager 112 adds to the desired image and one or more user components selected by the user at step 336 and components for the selected solution at step 338; and [0052], Coordinator 114 determines whether or not to proceed with the application of desired image 125 to hosts 131 based on the results of the pre-check) ; and applying, by LCM agent, the selected image to the host ([0026], Coordinator 114 communicates with the image manager 152 of each of hosts 131 through an API call to install desired image 125 in each of hosts 131; [0052], Upon determining to proceed with the application of desired image 125 to hosts 131, coordinator 114 executes the stage subprocess; and [0055] coordinator 114 issues an apply API to each host 131. This API causes image manager 152 of each host 131 to update the current state of the virtualization software with the payloads of desired image 125 staged at step S14 and the payloads of the firmware staged at step S16. Also, at step S18, image manager 152 updates metadata of the virtualization software that is stored in image database 153 to reflect that the virtualization software in the host and the associated firmware have been updated to be compliant with desired image 125). Haryadi fails to specifically teach, s elect an image o f a plurality of images defined in the desired state document. However, Li teaches, select an image o f a plurality of images defined in the desired state document ([0042], recommendation engine 110 examines desired image 152 and evaluates different combinations of base images, add-ons, firmware packages, solutions, and user components for possible recommendation). Haryadi and Li are analogous because they are each related to software management including software installation. Haryadi teaches a method of installing a desired software configuration in accordance with a desired state configuration document: Abstract, in response to a user input, generating a software specification that specifies a desired state of the virtualization software; based on the software specification, preparing a desired image of the virtualization software and storing the desired image of the virtualization software in a storage location accessible to the hosts; and instructing each of the hosts to install the desired image of the virtualization software or upgrade a current image of the virtualization software to the desired image of the virtualization software). Li teaches a method of installing a desired configuration and selecting between a recommended configuration and alternate configurations within a desired configuration file: [0009], method of updating a desired state of a virtualization software to be installed in a cluster of hosts, wherein the virtualization software includes at least a base image and an add-on image, includes the steps of: in response to a notification of a change associated with the cluster, determining versions of the base image that are compatible with the cluster; for each compatible version of the base image, determining versions of the add-on image that are compatible with the compatible version of the base image and the cluster; presenting as a recommended image a complete image of the virtualization software, the complete image containing a first version of the base image that is compatible with the cluster and a first version of the add-on image that is compatible with the first version of the base image and the cluster; and upon acceptance of the recommended image, updating a software specification to include the recommended image, the software specification expressing the desired state of the virtualization software; and [0043], use of filters by recommendation engine 110 to generate pre-validated combinations of base images, add-ons, firmware packages, solutions, and user components for possible recommendation. 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 desired image mechanism taught by Haryadi would be modified with the with the desired image mechanism, which includes alternate versions within a desired image configuration, taught by Li resulting in a system that allows selection of various images within a desired image document. Therefore, it would have been obvious to combine the teachings of Haryadi and Li. As per claim 2, Li teaches, wherein the desired state document defines a default image ([0009], presenting as a recommended image a complete image of the virtualization software, the complete image containing a first version of the base image that is compatible with the cluster and a first version of the add-on image that is compatible with the first version of the base image and the cluster; [0031], VM management server 100 stores the end user's selections for the desired state in software specification 104. The end user's selections include (1) a base image, (2) an add-on, (3) a firmware package, (4) solutions , and (5) user components. In accordance with the method of FIG. 2, an image manager 122 in VM management server 100 uses software specification 104 to composite a desired image that is modeled as a hierarchical software stack; and [0098], recommendation engine 110 selects the right-most navigation path for recommendation. The right-most navigation path contains the combination of the latest available software versions) and an alternative image ([0009], for each compatible version of the base image, determining versions of the add-on image that are compatible with the compatible version of the base image and the cluster), the alternative image associated with the selection criteria ([0095], complete image filter 120 determines if the composited virtualization software image violates any dependencies or conflicts by performing software validation of the image. Software validation is described above in conjunction with FIG. 3. At step 1208, if there was a violation of a dependency or conflict, then the method of FIG. 12 moves to step 1216; and [0097], At step 1216, complete image filter 120 determines if there are any more navigation paths to traverse in the tree. If there is another path, then the method of FIG. 12 returns to step 1202, at which complete image filter 120 traverses through a new navigation path). As per claim 3, Li teaches, wherein the default image is not associated with any selection criteria ([0009], presenting as a recommended image a complete image of the virtualization software, the complete image containing a first version of the base image that is compatible with the cluster and a first version of the add-on image that is compatible with the first version of the base image and the cluster). As per claim 4, Li teaches, further comprising: determining, by the LCM agent, that the hardware information matches the selection criteria ([0009], determining versions of the base image that are compatible with the cluster; for each compatible version of the base image, determining versions of the add-on image that are compatible with the compatible version of the base image and the cluster; [0042], recommendation engine 110 examines desired image 152 and evaluates different combinations of base images, add-ons, firmware packages, solutions, and user components for possible recommendation); wherein the selected image comprises the alternative image ([0097], recommendation engine 110 recommends one or more of the complete images from the list of valid images to the end user via UI 102; Examiner Note: After Li’s system choses an alternate path at step 1216, the system choses an alternative image at step 1218: Fig. 12; and [0097], At step 1216, complete image filter 120 determines if there are any more navigation paths to traverse in the tree. If there is another path, then the method of FIG. 12 returns to step 1202, at which complete image filter 120 traverses through a new navigation path ). As per claim 5, Li teaches, further comprising: determining, by the LCM agent, that the hardware information does not match the selection criteria (Fig. 12, Step 1208 (Y); [0095], at step 1208, if there was a violation of a dependency or conflict, then the method of FIG. 12 moves to step 1216; and [0097], At step 1216, complete image filter 120 determines if there are any more navigation paths to traverse in the tree. If there is another path, then the method of FIG. 12 returns to step 1202, at which complete image filter 120 traverses through a new navigation path); wherein the selected image comprises the default image ([0094], complete image filter 120 composites a complete virtualization software image based on the nodes that are traversed). As per claim 6, Haryadi teaches, further comprising: receiving, at an LCM from a user, a draft of the desired state document ([0024], the end user expresses the desired state of the virtualization software (i.e., hypervisor 150) for the cluster of hosts through a UI 101 of VM management server 100. One example form for expressing the desired state is a software specification 105, which is generated based on selections made through UI 101) ; and committing, by the LCM, the draft to generate the desired state document ([0026], After image manager 112 composites the image of the virtualization software, image manager 112 validates the composited image in accordance with the method depicted in FIG. 4 and, if validated, stores the composited image in shared storage 160 as a desired image 125 that is to be installed in each host 131; and [0036], Image manager 112 then validates the composited image as described below in conjunction with FIG. 4, and commits the validated composited image of the virtualization software as desired image 125 in shared storage 160). As per claim 7, Haryadi teaches, wherein the selection criteria includes a host identifier or a hardware specification ([0024], The selections that can be made through UI 101 include ... (5) firmware package (see FIG. 2)). As per claim 8, this is the “non-transitory computer readable medium 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 9, this claim is similar to claim 2 and is rejected for the same reasons. As per claim 10, this claim is similar to claim 3 and is rejected for the same reasons. As per claim 11, this claim is similar to claim 4 and is rejected for the same reasons. As per claim 12, this claim is similar to claim 5 and is rejected for the same reasons. As per claim 13, this claim is similar to claim 6 and is rejected for the same reasons. As per claim 14, this claim is similar to claim 7 and is rejected for the same reasons . 07-21-aia AIA Claim s 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Haryadi et al. (US 20210311717 A1) in view of Wu et al. (US 20210133328 A1) and Li et al. (US 20220188091 A1) . As per claim 15, Haryadi teaches the invention substantially as claimed including a virtualized computing system having a cluster comprising hosts connected to a network, the virtualized computing system comprising: a ... store configured to store a desired state document ([0026], After image manager 112 composites the image of the virtualization software, image manager 112 validates the composited image in accordance with the method depicted in FIG. 4 and, if validated, stores the composited image in shared storage 160 as a desired image 125 that is to be installed in each host 131; and [0036], Image manager 112 then validates the composited image as described below in conjunction with FIG. 4, and commits the validated composited image of the virtualization software as desired image 125 in shared storage 160) ; and a first host of the hosts configured to execute a lifecycle manager (LCM) agent ([0023], VM management server 100 is a physical or virtual server that communicates with hypervisor 150 of each host 131 to provision VMs 140 from the hardware resources of host 131 and [0026], Coordinator 114 communicates with image manager 152 of each of hosts 131 through an API call to install desired image 125 in each of hosts 131; Examiner Note: Haryadi’s VM Management Server includes Coordinator 114; Fig. 1, VM Mgmt Server 100 ) , the LCM agent configured to: obtain the desired state document, the desired state document defining a desired state of software in the host ([0023], VM management server 100 is a physical or virtual server that communicates with hypervisor 150 of each host 131 to provision VMs 140 from the hardware resources of host 131; and [0026], Coordinator 114 communicates with image manager 152 of each of hosts 131 through an API call to install desired image 125 in each of hosts 131; Examiner Note: Haryadi’s VM Management Server includes Coordinator 114; Fig. 1, VM Mgmt Server 100 ) , the software including a hypervisor ([0024], the end user expresses the desired state of the virtualization software (i.e., hypervisor 150) for the cluster of hosts through a UI 101 of VM management server 100) ; compare selection criteria in the desired state document against hardware information ([0048], In response to the scan API, image manager 152 at step S3, accesses desired image 125 and retrieves the current state of the virtualization software from image database 153, and compares the two to determine if each item of desired image 125 other than the firmware manifest (e.g., base image, add-on, solution, or user component) is “incompatible” (which means that desired image 125 cannot be applied, e.g., when the current state is running a higher version of an item), “compliant” (which means that the current state matches the desired state), non-compliant (which means that the current state can be upgraded to the desired state), or unknown (which means that a comparison of the current state could not be made with the item in desired image 125 because the item in desired image 125 is unknown or not recognizable); and [0051], Coordinator 114 at step S8 issues a pre-check API to image manager 152 of each host 131 and to hardware support manager 170. In response to the pre-check API, image manager 152 of each host 131 at step S9 accesses desired image 125 and retrieves the current state of the virtualization software from image database 153, and compares the two to determine whether or not the virtualization software in the host can be upgraded to desired image 125 at that time, and performs several other checks on the host and at step S10 sends the results of the checks to coordinator 114) obtained from a hardware platform of the host ([0043], image manager 112 acquires the hardware inventory of the host, e.g., from a hardware discovery service that is running in VM management server 100) to select an image ... defined in the desired state document ([0039], image manager 112 at step 332 processes the firmware manifest corresponding to the selected firmware package to add and remove components in the same manner as the selected add-on was processed. Then, image manager 112 adds to the desired image and one or more user components selected by the user at step 336 and components for the selected solution at step 338; and [0052], Coordinator 114 determines whether or not to proceed with the application of desired image 125 to hosts 131 based on the results of the pre-check) ; and apply the selected image to the host ([0026], Coordinator 114 communicates with the image manager 152 of each of hosts 131 through an API call to install desired image 125 in each of hosts 131; [0052], Upon determining to proceed with the application of desired image 125 to hosts 131, coordinator 114 executes the stage subprocess; and [0055] coordinator 114 issues an apply API to each host 131. This API causes image manager 152 of each host 131 to update the current state of the virtualization software with the payloads of desired image 125 staged at step S14 and the payloads of the firmware staged at step S16. Also, at step S18, image manager 152 updates metadata of the virtualization software that is stored in image database 153 to reflect that the virtualization software in the host and the associated firmware have been updated to be compliant with desired image 125) . Haryadi fails to specifically teach, a distributed key-value store configured to store a desired state document; and select an image of a plurality of images defined in the desired state document. However, Wu a distributed key-value store configured to store a desired state document ([0121], distributed metadata store 1110 may be used as a distributed key value storage system. In one example, the distributed metadata store 1110 may comprise a distributed NOS% key value store database...A table (or a set of tables) may be used to store metadata information associated with one or more files stored within the distributed file system 1112. The metadata information may include the name of a file, a size of the file, file permissions associated with the file, when the file was last modified, and file mapping information associated with an identification of the location of the file stored within a cluster of physical machines, in one embodiment, a new file corresponding with a snapshot of a virtual machine may be stored within the distributed file system 1112 and metadata associated with the new file may be stored within the distributed metadata store 1110 ). Haryadi and Wu are analogous because they are each related to software management including software installation. Haryadi teaches a method of installing a desired software configuration in accordance with a desired state configuration document: Abstract, in response to a user input, generating a software specification that specifies a desired state of the virtualization software; based on the software specification, preparing a desired image of the virtualization software and storing the desired image of the virtualization software in a storage location accessible to the hosts; and instructing each of the hosts to install the desired image of the virtualization software or upgrade a current image of the virtualization software to the desired image of the virtualization software). Wu teaches a method of managing software images that are stored in a distributed key-value storage: [0121], distributed metadata store 1110 may include a distributed database management system that provides high availability without a single point of failure. In one embodiment, the distributed metadata store 1110 may comprise a database, such as a distributed document-oriented database. The distributed metadata store 1110 may be used as a distributed key value storage system. In one example, the distributed metadata store 1110 may comprise a distributed NOS% key value store database; and [0122], the distributed metadata store 1110 may be used to manage one or more versions of a virtual machine. Each version of the virtual machine may correspond with a full image snapshot of the virtual machine stored within the distributed file system 1112 . 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 image storage mechanism taught by Haryadi would be modified to include the distributed metadata store taught by Wu resulting in a system that allows high-availability of desired image data. Therefore, it would have been obvious to combine the teachings of Haryadi and Wu. The combination of Haryadi-Wu fails to specifically teach, select an image of a plurality of images defined in the desired state document. However, Li teaches, select an image o f a plurality of images defined in the desired state document ([0042], recommendation engine 110 examines desired image 152 and evaluates different combinations of base images, add-ons, firmware packages, solutions, and user components for possible recommendation). The combination of Haryadi-Wu and Li are analogous because they are each related to software management including software installation. Haryadi teaches a method of installing a desired software configuration in accordance with a desired state configuration document. Wu teaches a method of managing software images that are stored in a distributed key-value storage. Li teaches a method of installing a desired configuration and selecting between a recommended configuration and alternate configurations within a desired configuration file: [0009], method of updating a desired state of a virtualization software to be installed in a cluster of hosts, wherein the virtualization software includes at least a base image and an add-on image, includes the steps of: in response to a notification of a change associated with the cluster, determining versions of the base image that are compatible with the cluster; for each compatible version of the base image, determining versions of the add-on image that are compatible with the compatible version of the base image and the cluster; presenting as a recommended image a complete image of the virtualization software, the complete image containing a first version of the base image that is compatible with the cluster and a first version of the add-on image that is compatible with the first version of the base image and the cluster; and upon acceptance of the recommended image, updating a software specification to include the recommended image, the software specification expressing the desired state of the virtualization software; and [0043], use of filters by recommendation engine 110 to generate pre-validated combinations of base images, add-ons, firmware packages, solutions, and user components for possible recommendation. 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 desired image mechanism taught by the combination of Haryadi-Wu would be modified with the with the desired image mechanism, which includes alternate versions within a desired image configuration, taught by Li resulting in a system that allows selection of various images within a desired image document. Therefore, it would have been obvious to combine the teachings of the combination of Haryadi-Wu and Li. As per claim 16, this claim is similar to claim 2 and is rejected for the same reasons. As per claim 17, this claim is similar to claim 3 and is rejected for the same reasons. As per claim 18, this claim is similar to claim 4 and is rejected for the same reasons. As per claim 19, this claim is similar to claim 5 and is rejected for the same reasons. As per claim 20, this claim is similar to claim 7 and is rejected for the same reasons . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is as follows: Haryadi et al. (US 20220244944)- Teaches installing images in accordance with a desired state configuration document: Abstract, installing or upgrading method involves generating a software specification that specifies the desired state of a virtualization software in response to a user input. A desired image of the virtualization software is prepared based on the software specification by retrieving metadata of the desired state and determining components that make up the desired state. Each of the hosts (131) is instructed to install the desired image of the virtualization software or upgrade the current image of the virtualization software to the desired image Gondi et al. (US 20210311712 A1)-Teaches installing software and firmware packages on distributed hosts: Abstract, acquiring hardware inventory of hosts (131) to determine hardware devices installed in the hosts, and searching for firmware and driver in a hardware compatibility list (180). A determination is made whether or not the driver is compatible according to the hardware compatibility list for each driver included in the desired image of a virtualization software that corresponds to one of the hardware devices. The image of the software and a firmware package to be installed are validated, if each hardware device has a compatible driver and a compatible firmware in the image of the software and the package, where the list is implemented in a physical or virtual server G05B2219/32252 and/or G06Q10/0$ Sullivan et al. (US 10778664 B1)- Teaches creating an inventory of distributed software assets: Abstract, software asset management service obtains software asset information from various computer systems of a service provided by a service provider and available to customers of the service provider. Based on the obtained software asset information from the computer systems, the service updates a database to specify this information; and Column 9, Lines 24-26, software asset management service to obtain updated software configuration information for particular virtual machine instances 306 within the physical host 302 and the physical host 302 itself. 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 Application/Control Number: 18/607,191 Page 2 Art Unit: 2197 Application/Control Number: 18/607,191 Page 3 Art Unit: 2197 Application/Control Number: 18/607,191 Page 4 Art Unit: 2197 Application/Control Number: 18/607,191 Page 5 Art Unit: 2197 Application/Control Number: 18/607,191 Page 6 Art Unit: 2197 Application/Control Number: 18/607,191 Page 7 Art Unit: 2197 Application/Control Number: 18/607,191 Page 8 Art Unit: 2197 Application/Control Number: 18/607,191 Page 9 Art Unit: 2197 Application/Control Number: 18/607,191 Page 10 Art Unit: 2197 Application/Control Number: 18/607,191 Page 11 Art Unit: 2197 Application/Control Number: 18/607,191 Page 12 Art Unit: 2197 Application/Control Number: 18/607,191 Page 14 Art Unit: 2197 Application/Control Number: 18/607,191 Page 15 Art Unit: 2197 Application/Control Number: 18/607,191 Page 16 Art Unit: 2197 Application/Control Number: 18/607,191 Page 17 Art Unit: 2197 Application/Control Number: 18/607,191 Page 18 Art Unit: 2197 Application/Control Number: 18/607,191 Page 19 Art Unit: 2197 Application/Control Number: 18/607,191 Page 20 Art Unit: 2197 Application/Control Number: 18/607,191 Page 21 Art Unit: 2197 Application/Control Number: 18/607,191 Page 22 Art Unit: 2197 Application/Control Number: 18/607,191 Page 23 Art Unit: 2197 Application/Control Number: 18/607,191 Page 24 Art Unit: 2197 Application/Control Number: 18/607,191 Page 25 Art Unit: 2197 Application/Control Number: 18/607,191 Page 26 Art Unit: 2197 Application/Control Number: 18/607,191 Page 27 Art Unit: 2197 Application/Control Number: 18/607,191 Page 28 Art Unit: 2197
Prosecution Insights