DETAILED ACTION Claims 1-15 are pending in this application. 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. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim s 1, 6 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pat. No. US 10,841,152 B1 issued to Humphreys et al. in view of U . S . Pat. No. 11 , 928 , 503 B2 issued to Huo et al. and further in view of U.S. Pub. No. 2020/0334022 A1 to Bhatnagar et al. A s to claim 1, Humphreys teaches a pod deployment method, comprising: obtaining, by a computing device, requirement information ( release template) from an application management cluster computer system (“… The service broker creates a deployment manifest (220). As described above, the service broker can generate the deployment manifest based on a release template for the cluster and a cloud computing platform on which the cluster will be deployed. The deployment manifest defines the components and properties of the cluster to be deployed. In general, the deployment manifest instructs a deployment manager on how to deploy the cluster. The deployment manager that will create the clusters can be tied to a particular cloud computing platform. The service broker can generate the deployment manifest based on the particular cloud computing platform… A release template is identified for a cluster based on a cluster name (310). As described above, a service broker can receive a request to create a cluster and the request can specify the cluster name. Each cluster name can be associated with a release template that includes the cluster components, e.g., Kubernetes cluster components, the application to be deployed in the cluster, e.g., including jobs, packages, and source code for the application, instructions on how to deploy the application, data specifying a cloud provider on which to deploy the cluster, and/or other appropriate data for the cluster. The release template can be generated by a user, e.g., an application developer… An updated deployment manifest is generated based on the request (420). For example, a manifest generator can obtain the deployment manifest for the cluster and update the deployment manifest based on the requested update. If the requested update is to update to a different version of the container orchestrator, the manifest generator can update the deployment manifest to instruct the deployment manager to deploy the new version of the container orchestrator on the cluster. The manifest generator can also update the deployment manifest based on any other properties specified by the deployment manager that should be updated based on capabilities of the updated version of the container orchestrator … ” Col. 7 Ln. 24-35, Col. 8 Ln. 23-34 , Col. 9 Ln. 23-34 ) ; and determining, by the computing device, a target node (a particular cloud computing platform/Step 320) used to deploy the quantity M of pods ( cluster(s)) , wherein M is an integer greater than or equal to 1 (“…The service broker creates a deployment manifest (220). As described above, the service broker can generate the deployment manifest based on a release template for the cluster and a cloud computing platform on which the cluster will be deployed. The deployment manifest defines the components and properties of the cluster to be deployed. In general, the deployment manifest instructs a deployment manager on how to deploy the cluster. The deployment manager that will create the clusters can be tied to a particular cloud computing platform. The service broker can generate the deployment manifest based on the particular cloud computing platform… Properties of the computing platform on which the cluster will execute are identified (320). As described above, the deployment manager can create, configure, and manage clusters on various different cloud computing platforms and local computing platforms. A user can specify which computing platform on which the cluster(s) identified by the cluster name will be deployed. In another example, the deployment manager can be tied to a particular computing platform. In some implementations, data specifying the computing platform is stored in the release template …” Col. 7 Ln. 24-35, Col. 8 Ln. 35-44) . Humphrey s is silent with reference to wherein the requirement information comprises a time period and a user quantity corresponding to the time period, and the pod annotation indicates a user quantity supported by a single pod, determining, by the computing device based on the user quantity corresponding to the time period and the user quantity supported by the single pod, a quantity M of pods that need to be deployed in the time period, and generating, by the computing device, a deployment plan based on the quantity M of pods that need to be deployed in the time period and the target node used to deploy the quantity M of pods. Huo teaches wherein the requirement information comprises a time period ( Table 1 column 11 independent response time for the existing pod ) and a user quantity ( Table 1 column 8 concurrency count for the existing pod ) corresponding to the time period, and the pod annotation indicates a user quantity supported by a single pod ( Table 1 column 8 concurrency count for the existing pod ) (“… The concurrency count of the requested pod refers to an expected number of users and/or expected number of requests from end users who will interact with the software application of the requested pod. When the request 206 is made, the operator or administrator may input the projected value for the concurrency count for the requested pod, and/or the concurrency count may be a predetermined value for requested pod…Further, software application 204 can utilize, employ, and/or call various techniques, algorithms, and models to individually determine the predicted API response time for each candidate node based on the resource information and the node type information for each candidate node and based on the (Docker) image layer information and the concurrency count of the requested pod. In one or more embodiments …” Col. 7 Ln. 15-22 / 55-62 , Col. 10 Ln. 1-10 ) , and determining, by the computing device based on the user quantity corresponding to the time period and the user quantity supported by the single pod ( requested pod) , a quantity M of pods that need to be deployed in the time period (“… The concurrency count of the requested pod refers to an expected number of users and/or expected number of requests from end users who will interact with the software application of the requested pod. When the request 206 is made, the operator or administrator may input the projected value for the concurrency count for the requested pod, and/or the concurrency count may be a predetermined value for requested pod…Further, software application 204 can utilize, employ, and/or call various techniques, algorithms, and models to individually determine the predicted API response time for each candidate node based on the resource information and the node type information for each candidate node and based on the (Docker) image layer information and the concurrency count of the requested pod. In one or more embodiments …” Col. 7 Ln. 15-22/55-62, Col. 10 Ln. 1-10) . It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Humphreys with the teaching of Huo because the teaching of Huo would improve the system of Humphreys by providing methods for scheduling and deploying a pod by deploying the pod on a node based at least in part on having the best predicted response time (Col. 1 Ln. 62-67). Bhatnagar teaches generating, by the computing device, a deployment plan ( Virtualized Deployments 112/ A deployment can be implemented with a quantity of physical servers and VMs intended to support a population of users of a certain size ) based on the quantity M of pods ( VMs) that need to be deployed and the target node used to deploy the quantity M of pods (“…The virtualized deployments 112 can include customer deployments that are implemented using a common virtualization platform, such as VMWARE VSPHERE. The virtualized deployments 112 can be implemented on behalf of one or more enterprises and implement applications at various scales . In the context of this disclosure, the term scale means a number of users that a deployment is expected to support. For example, a CRM application deployed to support approximately 10,000 users is associated with a scale of approximately 10,000 users … The virtualized deployments 112 can include physical servers that are executing VMs powered by the virtualization platform. The virtualized deployments 112 can be configured with software that reports back to the platform provider certain information about the deployment. The information reported by a respective virtualized deployment 112 can include operational data 111 about the health and status of the VMs in the virtualized deployment 112. The operational data 111 can identify the enterprise for which a particular deployment was implemented, an indicator of the industry in which the enterprise operates, and the application for the enterprise that the VM is supporting. The operational data 111 can also include an indicator of the scale of the deployment as well. In some examples, the operational data 111 can identify details about the physical servers on which the virtualized deployment 112 is implemented. In this way, the size of the virtualized deployment 112 can be obtained or deduced from the operational data 111 that is generated by and collected from the respective deployments…The application type 149 can identify the application deployed within the virtualized deployment 112. For example, in the case of a CRM deployment, the application type 149 can identify that the application is a CRM application as well as the vendor and version of the CRM service utilized in the virtualized deployment 112. The scale 151 represents an indicator of the size of the deployment. The scale 151 can represent a number of users to be supported by the deployment. A deployment can be implemented with a quantity of physical servers and VMs intended to support a population of users of a certain size. When the application is deployed, the VMs that report operational data 111 back to the data extractor 141 can report an indicator of the scale 151 of the deployment…” paragraphs 0015/0016/0023). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Humphreys and Huo with the teaching of Bhatnagar because the teaching of Bhatnagar would improve the system of Humphreys and Huo by providing a process for selecting a number of targets and users that will optimally execute virtual machines. As to claim s 6 and 11 , see the rejection of claim 1 above, expect for a memory, a processor and a non-transitory computer-readable storage medium. Humphreys teaches a memory ( memory ) , a processor ( processor ) and a non-transitory computer-readable storage medium ( Computer-readable media) (‘… Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry …” Col. 11 Ln. 14-22) . Claim s 4, 9 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pat. No. US 10,841,152 B1 issued to Humphreys et al. in view of U.S. Pat. No. 11,928,503 B2 issued to Huo et al. and further in view of U.S. Pub. No. 2020/0334022 A1 to Bhatnagar et al. as applied to claim s 1 , 6, and 11 above, and further in view of U.S. Pub. No. 2015 / 0347170 A1 to Mohammed et al. As to claim 4, Humphreys as modified by Huo and Bhatnagar teaches t he method according to claim 1, however it is silent with reference to ( BUT, Mohammed teaches ) wherein the requirement information further comprises an application identifier ( unique application ID) , and the pod annotation further comprises an application identifier of an application running in the pod ( unique VM ID1) ; and wherein the obtaining, by the computing device, the requirement information and the pod annotation from the application management cluster computer system ( Application Management Server 110) comprises: for a same application, obtaining, by the computing device by using an application programming interface (API) server in the application management cluster computer system ( Application Management Server 110) , requirement information and a pod annotation that correspond to an application identifier of the same application (“… Referring to FIG. 3, once the cloud-based application is modeled at step 310, method 300 proceeds to step 320. At step 320, application management server 110 receives a request to deploy the modeled application to a cloud infrastructure. In response to receiving the deployment request at step 320, application management server 110 generates, at step 330, a unique application ID that corresponds to the modeled application. With reference to FIG. 4, AppID1 (which is stored in table 225 within application management server 110) corresponds to the modeled application … Once the unique application ID has been generated, method 300 proceeds to step 340. At step 340, a unique VM ID1 is generated for a next virtual machine that is modeled within the cloud-based application. In the example depicted in FIG. 4, a three-VM cloud based application is modeled in application management server 110. Hence, at step 340, VMID1.sub.— a is generated and stored for the first of the three virtual machines … In the present embodiment, method 300 then proceeds to step 350, where the virtual machine whose VM ID1 has been generated at step 340 is deployed to (or instantiated in) the cloud. In embodiments, deployment of a VM to the cloud comprises transmitting a deployment request for the VM from application management server 110 to IaaS 120. The deployment request includes the generated application ID and VM ID1 (e.g., AppID1 and VMID1.sub.— a , from FIG. 4). IaaS 120 then transmits a further request to the cloud infrastructure (e.g., to VM management server 130) to instantiate a VM corresponding to the deployment request. As shown in FIG. 4, IaaS 120 receives a deployment request for the first VM modeled in application management server 110 (i.e., the VM identified by VMID1.sub.— a ). IaaS 120 stores AppID1 and VMID1.sub.— a in table 230, and transmits an instantiation request to VM management server 130 corresponding to the VM identified in application management server 110 by VMID1.sub.— a . VM management server 130 then instantiates a first virtual machine (i.e., VM 140.sub.1). As shown in FIG. 4, VM 140.sub.1 stores metadata that includes AppID1 and VMID1.sub.— a . In addition, as a result of the instantiation of VM 140.sub.1, VM management server 130 generates VMID2.sub.— a , which is stored in (or is logically associated with) VM 140.sub.1 … Once the next VM modeled in the application is deployed to the cloud (i.e., instantiated in the cloud), method 300 proceeds to step 360. At step 360, the generated VM ID2, which, as previously mentioned, is generated by the cloud (e.g., VM management server 130) when the cloud instantiates a VM, is received by IaaS 120 from the cloud. Thus, with reference to FIG. 4, at step 360, VM management server 130 transmits VMID2.sub.— a (which VM management server 130 generates at step 350) to IaaS 120 … At step 370, IaaS 120 associates VMID2.sub.— a received at step 360 with application ID AppID1 and VM ID1 VMID1.sub.— a , which are generated, respectively, in steps 330 and 340. Thus, as shown in FIG. 4, IaaS 120 receives VMID2.sub.— a from VM management server 130 and stores it in the entry of table 230 that contains AppID1 and VMID1.sub.— a . Thus, in this way, an association is established between AppID1 and VMID1.sub.— a (which uniquely identify, from the perspective of application management server 110, the first modeled virtual machine) with VM 140.sub.1 (which is the corresponding virtual machine instantiated within VM management server 130) … At step 380, method 300 determines whether there are more VMs modeled as part of the cloud-based application in application management server 110. If there are more VMs, then method 300 proceeds back to step 340, where a next VM ID1 is generated for the next VM. Thus, referring to FIG. 4, VMID1.sub.— b is generated for the second VM. Method 300 then proceeds through steps 350-370 to deploy the second VM to the cloud and to associate the deployed second VM with the second VM as modeled in application management server 110. As shown in FIG. 4, VM management server 130 instantiates VM 140.sub.2 and generates VMID2.sub.— b . AppID1 and VMID1.sub.— b are then associated with VMID2.sub.— b in the second entry of table 230. It should be noted that method 300 proceeds through steps 340-370 in like manner for the third virtual machine modeled in application management server 110 (i.e., the virtual machine identified by VMID1.sub.— c ) … If, at step 380, method 300 determines that there are no more VMs modeled as part of the cloud-based application in application management server 110, then all application VMs are deployed and method 300 terminates …” paragraphs 00- 0039) . It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Humphreys, Huo and Bhatnagar with the teaching of Mohammed because the teaching of Mohammed would improve the system of Humphreys, Huo and Bhatnagar by providing a process for uniquely identifying virtual machines and appropriately deploying the virtual machines. As to claims 9 and 14, see the rejection of claim 4 above. Claim s 5, 10 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pat. No. US 10,841,152 B1 issued to Humphreys et al. in view of U.S. Pat. No. 11,928,503 B2 issued to Huo et al. and further in view of U.S. Pub. No. 2020/0334022 A1 to Bhatnagar et al. as applied to claim s 1 , 6 and 11 above, and further in view of U.S. Pat. No. 8 , 850 , 419 B1 issued to Fitzgerald et al. As to claim 5, Humphreys as modified by Huo and Bhatnagar teaches the method according to claim 1, however it is silent with reference with ( BUT , Fitzgerald teaches ) wherein after the generating, by the computing device, the deployment plan, the method further comprises: indicating, by the computing device based on the deployment plan ( Deployment Plan 410 ) before a start moment of the time period, the application management cluster computer system to deploy each pod of the quantity M of pods on the target node; corresponding to the pod ( when/ should occur during periods of off-peak demand for the application/ demand cycle) ; and/ or indicating, by the computing device based on the deployment plan after an end moment of the time period, the application management cluster computer system to delete ( terminate ) each of the quantity M of pods from t he target node corresponding to the pod ( paid-for time period) (“…Once the update preferences 408 have been specified for an update 402, the deployment component 214 utilizes the update preferences 408 to create a deployment plan 410. The deployment plan 410 specifies how and when the update 402 , and potentially other updates 402 in the update queue 406, is to be applied to the application in view of the specified update preferences 408. In one embodiment, for example, the deployment plan 410 might specify instructions for deploying an update 402 in a manner that optimizes the update process according to the factors set forth by the owner or maintainer of the application in the update preferences 408. The deployment plan 410 is then utilized to deploy the update 402 to the application. For instance, the update 402 might be deployed to the instances 206A-206G executing on the server computers 202A-202C of the customer fleet 302… The deployment plan 410 might also indicate that deployment of updates 402 to an application should occur during periods of off-peak demand for the application. In one embodiment, a demand cycle for the application is identified through monitoring demand for the application or in another fashion. The demand cycle might be based upon a diurnal cycle, a monthly cycle, a yearly cycle, or another type of regular cycle. Once the demand cycle has been identified, the updates 402 to the application might be applied during periods of off-peak demand , thereby potentially reducing the cost of deployment of the updates 402. Additional details regarding this process are provided below with respect to FIG. 11… The deployment plan 410 might also indicate how and when unneeded instances may be de-scaled during or following deployment of an update 402. For instance, it may be necessary or desirable to de-scale one or more instances 206 in a customer fleet 302 following the deployment of an update 402. The deployment plan 410 might specify that instances 206 should be de-scaled according to the percentage of a paid-for time period that has been utilized . In this manner, the customer of the PES platform 108 will receive full benefit of the paid for time period prior to termination of instances. The deployment plan 410 might also specify that the instances 206 are not to be terminated until the end of a paid-for time period. Additional details regarding this process will be provided below with reference to FIG. 12…” Col. 10 Ln. 36-50, Col. 11 Ln. 44-67, Col. 12 Ln. 1-2). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Humphreys , Huo and Bhatnagar with the teaching of Fitzgerald because the teaching of Fitzgerald would improve the system of Humphreys, Huo and Bhatnagar by providing a process for configurating settings of when to optimally deploy software components . As to claims 10 and 15, see the rejection of claim 5 above. Allowable Subject Matter Claims 2, 3, 7, 8, 12 and 13 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Reasons for Allowance The following is an examiner’s statement of reasons for allowance: The closest prior art of records, ( U.S. Pat. No. US 10,841,152 B1 issued to Humphreys et al. and U.S. Pat. No. 11,928,503 B2 issued to Huo et al. ), taken alone or in combination do not specifically disclose or suggest the claimed recitations (claims 2, 3, 7, 8, 12 and 13), when taken in the context of claims as a whole. Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.” Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. U.S. Pat. No. 11,469,944 B1 issued to Lindholm et al. and directed to techniques for migrating worker nodes within clusters to a new manager instance. U.S. Pub. No. 2015 / 0350101 A1 to Sinha et al. and directed to a cloud management server configured to manage a plurality of virtual machines deployed in a cloud infrastructure. When a cloud-based application is deployed to the cloud infrastructure, a deployment plan for the cloud-based application . U.S. Pub. No. 2022 / 0136722 A1 to Sharma et al. and directed to system and method for designing and deploying a building-related service in a building automation management system (BAMS). U.S. Pub. No. 2020 / 0241909 A1 to Govomdaraju et al. and directed to techniques for determining host computing systems to deploy virtual machines based on disk specifications are disclosed. A blueprint to deploy a virtual machine in a cloud computing environment may be received and disk specifications required to deploy the virtual machine retrieved from the blueprint. U.S. Pat. No. 8 , 799 , 888 B1 issued to Fitsgerald et al. and directed to a deployment component that provides functionality for deploying updates to an application. U.S. Pub. No. 2019/0026135 A1 to Chen et al. and directed to a method to manage a virtual machine deployment in a cloud environment includes generating a blueprint comprising a blueprint component corresponding to an application storage policy for all endpoints associated with an infrastructure source in the cloud environment. U.S. Pub. No. 2015 / 0067168 A1 to Hegdal et al. and directed to a virtual machine deployment and management engine deploys virtual machines to physical host computers based on a deployment time matrix. U.S. Pub. No. 2011/0161491 A1 to Sekiguchi and directed to a migration control apparatus for controlling migration of a virtual machine includes a monitoring section, a planning section, a time estimation section, a comparing section, and a plan execution section. U.S. Pub. No. 2020 / 0192690 A 1 to Gupta et al. and directed an a pplication deployment in a container management system . U.S. Pub. No. 2016/0269806 A1 to Uchiumi et al. and directed to a deployment instruction creation module for creat ing a deployment plan of virtual machine s. Any inquiry concerning this communication or earlier communications from the examiner should be directed to FILLIN "Examiner name" \* MERGEFORMAT CHARLES E ANYA whose telephone number is FILLIN "Phone number" \* MERGEFORMAT (571)272-3757 . The examiner can normally be reached FILLIN "Work Schedule?" \* MERGEFORMAT Mon-Fir. 9-6pm . 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, FILLIN "SPE Name?" \* MERGEFORMAT KEVIN YOUNG can be reached at FILLIN "SPE Phone?" \* MERGEFORMAT 571-270-3180 . 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. /CHARLES E ANYA/ Primary Examiner, Art Unit 2194