CTNF 18/631,028 CTNF 98872 Notice of Pre-AIA or AIA Status 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 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 cited in their 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. Claim Rejections - 35 USC § 112 07-30-02 AIA 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. 07-34-01 Claims 14-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. Claim 14 recites the limitation "the one or more processors, cause the processors" in lines 4-5. There is insufficient antecedent basis for this limitation in the claim. Specifically, only one processor is previously recited in the claim, so it is unclear what the “or more” processors are referring to. Claims 15-20 depend from claim 14 and therefore inherit the same deficiency. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 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 9-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the broadest reasonable interpretation of the claimed “ computer-readable media ” encompasses transitory signals (“signals per se”) which is not one of the four statutory categories. The Examiner recommends amending the claims to recite a “ non-transitory computer-readable media ” to overcome the rejection. Claim Rejections - 35 USC § 103 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-20-02-aia AIA This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. 07-21-aia AIA Claim s 1-2, 4-7, 9, 11-15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Hassine et al. (U.S. Pub. No. 2015/0242204), hereinafter Hassine, in view of Rao et al. (U.S. Pub. No. 2025/0310411), hereinafter Rao . Regarding claim 1, Hassine teaches A method of discovering a workload deployment, the method comprising: obtaining workload application identification information for a workload deployment deployed in an infrastructure ([0033] – “ the application 102 is a customized multi-tier application (e.g., modified from component templates) and is initially deployed in a deployment environment 104 ”; [0034] – “ deployment environment 104 provided by a cloud computing platform provider 110 […] The example cloud computing platform provider 110 of FIG. 1 may include any number of deployment environments 104, 112 .”) , the infrastructure comprising infrastructure resources comprising compute infrastructure resources, networking infrastructure resources, and storage infrastructure resources ([0002] – “ Enterprises may use IaaS as a business-internal organizational cloud computing platform (sometimes referred to as a "private cloud") that gives an application developer access to infrastructure resources, such as virtualized servers, storage, and networking resources .”; [0036] – “ The example cloud computing platform provider 110 provisions virtual computing resources (e.g., the VMs 114) and/or physical resources to provide the deployment environments 112 in which the administrator 116 and/or developer 118 can deploy multi-tier application(s) .”; [0039] – “ virtual computing resources (e.g., VMs, networking, storage) that may be provisioned from the cloud computing platform provider 110 ”) , the workload deployment comprising a plurality of workload components deployed across a plurality of the compute infrastructure resources ([0015] – “ virtual machines (VMs) hosting or implementing the application components ”; [0035] – “ application 102 of FIG. 1 includes multiple VMs 114. The example VMs 114 of FIG. 1 provide different functions within the application 102 (e.g., services, portions of the application 102, etc.). ”; [0038] – “ an application as a collection of application components executing on virtual computing resources […] Applications may be distributed across multiple CUs (e.g., one or more VMs, one or more physical machines, and/or a combination of one or more VMs and/or one or more physical machines) .”) , the workload application identification information comprising a workload application name and version reference associated with the workload deployment ([0045] – “ The example service analyzer 136 of FIG. 1 receives (e.g., from the administrator 116) a VM identifier (e.g., a VIN ID) and/or an IP address 150 of a currently-running VM 114, from which the service analyzer 136 may iteratively determine VMs belonging to the application 102. […] Additionally or alternatively, the example service analyzer 136 may receive an application identifier 152 for the application 102, such as a unique application name and an identifier of the deployment environment 104 in which the application 102 is deployed .”; [0040] – “ test prototypes (e.g., new application versions) […] deploy the application to different deployment environments 112 (e.g., testing, staging, production). ” The identifier of the deployment environment 104 is analogous to the claimed “version reference associated with the workload deployment”, since different versions of the application can be deployed in the different deployment environments, e.g., a testing version, a staging version, a production version, etc.) ; […] obtaining a set of automations for discovering metadata corresponding to or associated with all of the workload components of the workload deployment, the metadata comprising information about each of the workload components and corresponding dependent infrastructure resources ([0035] – “ The example application 102 of FIG. 1 includes multiple VMs 114. The example VMs 114 of FIG. 1 provide different functions within the application 102 (e.g., services, portions of the application 102, etc.). […] the services executing on the example VMs 114 may have dependencies on other ones of the VMs 114 .”; [0046] – “ the service analyzer 136 of the illustrated example may access and/or execute the discovery script(s) in the discovery script repository 146 to discover properties such as dependencies , node cluster definitions, and/or interfaces to other, unidentified ones of the VMs 114 in the application 102 . The example service analyzer 136 adds the discovered ones of the VMs 114 to a list of VMs to be analyzed by the CU analyzer 138 ”; [0056] – “ the discovery script(s) used by the service analyzer 136 to analyze and determine the application definition 148 […] For example, the service analyzer 136 calls a first discovery script to determine the application definition based on identification of a seed VM 114 " The discovery script(s), i.e., “automations”, are executed by the service analyzer to discover the VMs (implementing the application components) in the application 102 and their dependencies.) ; executing the set of automations obtained from the workload database ([0046] – “ execute the discovery script(s) in the discovery script repository 146” ; [0056] – “ the service analyzer 136 calls a first discovery script to determine the application definition based on identification of a seed VM 114, and the CU analyzer 138 calls a second discovery script to obtain the configurations of the VMs 114 when the application definition 148 is generated (e.g., via running the first discovery script)” ) ; obtaining, from the set of automations, workload component and dependent infrastructure resource metadata for all of the workload components, the workload component and dependent infrastructure resource metadata comprising, for each of the workload components, relationship information and compute resource identity information, the relationship information providing dependency information between workloads ([0017] –“ Example methods and apparatus use configuration discovery script(s) to scan deployed applications ”; [0043] – “ service analyzer 136 of FIG. 1 identifies the VMs 114 that are within an application definition 148. […] the application definition generator 142 generates the application definition based on scans of the VMs 114 by the service analyzer 136 ”; [0046] – “ the service analyzer 136 of the illustrated example may access and/or execute the discovery script(s) in the discovery script repository 146 to discover properties such as dependencies , node cluster definitions, and/or interfaces to other, unidentified ones of the VMs 114 in the application 102 . ”; [0081] –“ The example service analyzer 136 analyzes the selected VM 114 to determine dependencies for the application 102 (block 404). For example, the service analyzer 136 may determine other service(s) and/or VMs 114 on which services operating on the selected VM 114 depend .”; [0083] – “ The example service analyzer 136 of FIG. 1 analyzes the selected VM 114 to determine port configuration(s) for the application (block 408). For example, the VMs 114 implementing the application 102 may be configured to communicate with other ones of the VMs 114 at different IP addresses via designated ports. By identifying the port configuration(s), the example service analyzer 136 may obtain the IP addresses and/or identifiers of other VMs 114 that implement the application 102 .”; [0084] – “ The example service analyzer 136 of FIG. 1 analyzes the selected VM 114 to determine other VM identifiers for the application 102 (block 410) .”; [0085] – “ If VMs have been identified (block 412), the example service analyzer 136 adds any identified (e.g., newly-identified) VMs 114 to a list of VMs to be analyzed (block 414). The list of VMs to be analyzed may be used by the example service analyzer 136 to identify further VMs 114 that implement the application 102 ”) ; compiling the workload component and the dependent infrastructure resource metadata for the workload deployment into a data structure ([0046] – “ properties such as dependencies […] The example service analyzer 136 adds the discovered ones of the VMs 114 to a list of VMs to be analyzed by the CU analyzer 138 and provides any relevant configuration items to the example application definition generator 142. The example application definition generator 142 generates the application definition 148 based on the configurations and/or properties resulting from the configurations .”; [0056] – “ the service analyzer 136 calls a first discovery script to determine the application definition based on identification of a seed VM 114, and the CU analyzer 138 calls a second discovery script to obtain the configurations of the VMs 114 when the application definition 148 is generated (e.g., via running the first discovery script) ”; [0088] – “ the application definition generator 142 may generate the application definition 148 for the application 102 based on a list of VMs identified by the service analyzer 136 and VMs seeded to the example service analyzer 136 .”; [0089] – " VMs 114 that are within an application definition 148. ”) ; generating a workload abstraction corresponding to the data structure (FIG. 3, steps 302, 304, and 306 – “determine computing units within an application definition”, “identify properties for computing units that are within the application definition”, and “generate customized application blueprint based on the computing units and including the identified properties”; [0017] – “ the resulting application blueprint that describes the application .”; [0019] – “ Some example deployment systems enable a developer or "application architect" to create customized "application blueprints" from currently running or deployed applications .”; [0026] – “ the term "blueprint" refers to a logical topology of an application for deployment. A blueprint captures the structure of an application with logical nodes, their corresponding services and operating systems, dependencies, default configurations, and network topology requirements .”; [0038] – “ blueprints 126, 127 generally capture the structure of an application as a collection of application components executing on virtual computing resources .”) ; and performing a management operation using the workload abstraction (Fig. 3, steps 308 and 314 – “import customized application blueprint into application manager” and “manage deployed application using application manager”; [0036] – “ example application director 106 may also import a blueprint 127 from the example virtual infrastructure navigator 108 for deployment and/or management .”; [0041]-[0042] – “ the application director 106 may be utilized to monitor and/or modify (e.g., scale) the deployment. The virtual infrastructure navigator 108 of FIG. 1 generates the example application blueprint 127 based on the deployed application 102, which may be imported to the example application director 106 to be deployed and/or managed .”) .’ Hassine fails to expressly teach querying a workload database using the workload application identification information; and in response to the querying obtaining the set of automations. However, Rao teaches querying a workload database using the workload application identification information; and in response to the querying obtaining a set of automations to be executed ([0033] – “software resources 406 may generally include software applications”; [0041] – “ in response to receiving the information associated with the hardware resource 404A and the processes executed by and/or on the hardware resource 404A, the computational instance 400 may determine one or more discovery patterns usable by the agent 402A to discovery software resources on the client network 12 based on the received process information, such as the software resource 406. For example, the computational instance 400 may analyze the discovered processes to determine attributes and/or other aspects of the software resources indicated by the process information . The computational instance 400 may access a patterns database 412 (e.g., a patterns database of the remote network management platform) and identify patterns stored in the patterns database 412 usable by the agent 402A to discovery software resources based on the attributes and/or the other aspects of the software resources . For example, the patterns database 412 may store executable instructions representative of patterns that the agents 402 may execute to discover software resources of the client network 12 as determined based on information previously returned by the agent 402A .”; [0042] – “ In response to determining the discovery pattern based on the discovered process information and/or the patterns stored in the patterns database 412, the computational instance 400 may transmit the discovery pattern (e.g., executable instruction(s) indicative of the discovery pattern) to the agent 402A via the discovery server. In response to receiving the discovery pattern, t he agent 402A may execute the discovery pattern to discover (e.g., receive, collect) information associated with software resource s of the client network. In the illustrated embodiment, the agent 402A may discover information associated with the software resource 406. The information associated with the software resource 406 may include identification information of the software resource 406, attributes of the software resource 406, relationships between the software resource 406 and the hardware resource 404A, relationships between the software resource 406 and other hardware resources of the client network 12, relationships between the software resource 406 and other software resources of the client network 12, and other information associated with components of the client network 12 .”; [0048] – “ the computational instance 400 may determine one or more discovery patterns usable by the agent 402A to discovery software resources on the client network 12 based on the received process information .” A database is accessed, i.e., queried, using obtained process information (information indicating the processes, i.e., a workload or application, executing on a resource, analogous to the “workload application identification information”) to obtain discovery patterns executable by the agents to determine information about the software resources including relationship information and dependencies on hardware resources.). Hassine and Rao are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of discovering deployed workloads. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Hassine such that the set of automations obtained from a workload database (the “discovery script(s)” obtained from a “discovery script repository”) and executed to discover the claimed metadata as taught by Hassine are obtained in response to querying the database using the workload application identification information as taught by Rao. Incorporating the methods of Rao may reduce delays and require less information to perform discovery of hardware and software resources in a network (see Rao: [0006] and [0044]). Regarding claim 2, the combination of Hassine in view of Rao teaches The method of claim 1. Hassine further teaches wherein the compute infrastructure resources are virtual machines deployed in the infrastructure and the compute resource identity information comprises a virtual machine identifier ([0036] – “ The example cloud computing platform provider 110 provisions virtual computing resources (e.g., the VMs 114) and/or physical resources to provide the deployment environments 112 in which the administrator 116 and/or developer 118 can deploy multi-tier application(s) .”; [0038] – “ an application as a collection of application components executing on virtual computing resources […] Applications may be distributed across multiple CUs (e.g., one or more VMs, one or more physical machines, and/or a combination of one or more VMs and/or one or more physical machines). ”; [0084] – “ service analyzer 136 of FIG. 1 analyzes the selected VM 114 to determine other VM identifiers for the application 102 ”) . Regarding claim 4, the combination of Hassine in view of Rao teaches The method of claim 1. Hassine further teaches a particular compute resource that hosts a main component of the workload deployment ([0015] – “ virtual machines (VMs) hosting or implementing the application components ”; [0080] – “ the service analyzer 136 may be provided with an identification (e.g., the VIN ID/IP address 150 of FIG. 1) of a first VM 114 in the application 102 (e.g., implementing the application 102) as a seed VM .” As described with respect to Fig. 4 in paragraphs [0080]-[0088] of Hassine, other VMs implementing application components are identified using relationships of the seed VM with the other VMs, and the process is repeated for each of the VMs identified from the seed VM. Thus, the seed VM(s) may be considered to be hosting a “main component” of the workload deployment, since they are the main VMs (components) of the application from which additional components are identified.) . Rao further teaches wherein the obtaining of the workload application identification information comprises receiving the workload application identification information from a discover workload agent deployed to a compute resource that hosts a component of the workload deployment ([0008] – “ an agent as used herein may be a software application deployed within the network, such as on workstations within a local area network, that performs tasks ( e.g., discovery related tasks) […] The agent may initially perform the discovery steps of identifying hardware resources and processes executed on the hardware resources and transmitting the hardware resource information and process information to a managerial resource or application running on the computational instance. The computational instance may identify discovery pattern(s) from a database of known discovery patterns based on the process information and transmit the relevant discovery pattern(s) (as determined based on the reported hardware resources and processes) to the agent .”; [0033] – “ Agents 402 may be deployed (e.g., installed) on hardware resources 404 of the client network 12 and configured to discover and transmit hardware resource information, software resource information, and process information to the computational instance 400 ”). It would have been obvious to one of ordinary skill in the art to have modified the methods of Hassine to incorporate the agent of Rao such that the workload application identification information used to determine the automations for discovering metadata of the workload is received from a discover workload agent deployed to the resources hosting the workload as taught by Rao. Incorporating the methods of Rao may reduce delays and require less information to perform discovery of hardware and software resources in a network (see Rao: [0006] and [0044]). Regarding claim 5, the combination of Hassine in view of Rao teaches The method of claim 4. Hassine further teaches wherein the particular compute resource hosting the main component of the workload deployment is identified by: deploying a plurality of identify-workload-type agents on a plurality of virtual machines in the infrastructure ([0022] – “ the term "computing unit" refers to a virtual machine (VM) and/or a physical machine .”; [0050] – “ The example VMs 114 of FIG. 1 may additionally or alternatively be provided with monitoring agents 158 to execute corresponding discovery scripts. The example monitoring agents 158 execute discovery scripts to identify configurations of the nodes and generate discovery reports containing the identified configuration information. In some examples, discovery reports are formatted files containing configuration information discovered by the monitoring agent according to the discovery script. Example discovery scripts may search designated locations and/or types of locations on the CUs 114, 154 to determine, for example, whether particular configuration settings exist on the CU 114, 154, whether particular types or classes of configuration settings exist on the CU 114, 154, and/or to determine a configuration status of a configuration setting or type of configuration setting. The monitoring agents 158 and/or the monitoring agent server 156 provide the discovery reports to the example service analyzer 136, which parses the discovery reports to identify the CUs 114, 154 implementing the application 102 .”; [0104] – “ The monitoring agent server 156 of the illustrated example determines whether the selected CU 114, 154 has a monitoring agent installed (e.g., the monitoring agent 158 of FIG. 1) (block 704). If the selected CU 114, 154 does not have a monitoring agent 158 installed (block 704), the monitoring agent server 156 installs a monitoring agent on the selected computing unit ”) ; and receiving a notification of a presence of the main component on the particular compute resource from one of the plurality of identify-workload-type agents that is deployed on the particular compute resource ([0050] – “ The monitoring agents 158 and/or the monitoring agent server 156 provide the discovery reports to the example service analyzer 136, which parses the discovery reports to identify the CUs 114, 154 implementing the application 102 .”; [0052] – “ In some other examples, the monitoring agent server 156 instructions the monitoring agents 158 to transmit the discovery reports directly to the virtual infrastructure navigator 108 .”; [0105] – “ the monitoring agent 158 executes the discovery script to, for example, collect configuration information from the selected CU 114, 154 pertaining to node cluster configurations, port configuration(s), dependencies on other computing units, and/or any other configuration information associated with executing the application 102 .” The discovery report from each agent executing on a VM, e.g., the VM implementing the “main component”, includes information associated with executing the application, which implicitly indicates the presence of the application component on the particular VM.) . Regarding claim 6, the combination of Hassine in view of Rao teaches The method of claim 1. Hassine further teaches wherein at least one automation in the set of automations comprises executable code configured in a manner specific to the workload application identification information ([0045] – “ The example service analyzer 136 of FIG. 1 receives ( e.g., from the administrator 116) a VM identifier (e.g., a VIN ID) and/or an IP address 150 of a currently-running VM 114, from which the service analyzer 136 may iteratively determine VMs belonging to the application 102. The example service analyzer 136 analyzes the VM identifier 150 to determine, for example, IP addresses and/or credentials for the VM(s) 114. Additionally or alternatively, the example service analyzer 136 may receive an application identifier 152 for the application 102, such as a unique application name and an identifier of the deployment environment 104 in which the application 102 is deployed .”; [0056] – “ For example, the service analyzer 136 calls a first discovery script to determine the application definition based on identification of a seed VM 114 […] the application definition 148 is generated (e.g., via running the first discovery script)”; [0090] – “ loads a discovery script based on a type or function of the selected VM 114 .” As described in [0045], the identification of the seed VM may be considered additional (or alternative) to the workload application identification information; thus, a discovery script which is executed based on the VM identification may be considered to be “configured in a manner specific to the workload application identification information” since its execution is based on (i.e., “specific to”) information identifying the workload application (the identification of the seed VM of the application).) to discover all application components of the workload deployment ([0035] – “ application 102 of FIG. 1 includes multiple VMs 114. The example VMs 114 of FIG. 1 provide different functions within the application 102 (e.g., services, portions of the application 102, etc.). ”; [0056] – “ the service analyzer 136 calls a first discovery script to determine the application definition based on identification of a seed VM 114 ”; [0079]-[0088] – “ FIG. 4 is a flowchart representative of example machine readable instructions 400 which may be executed to implement the example service analyzer 136 of FIG. 1 to determine CUs in an application definition . […] The example service analyzer 136 of FIG. 1 selects an identified VM 114 (block 402). For example, the service analyzer 136 may be provided with an identification (e.g., the VIN ID/IP address 150 of FIG. 1) of a first VM 114 in the application 102 (e.g., implementing the application 102) as a seed VM . The example service analyzer 136 analyzes the selected VM 114 to determine dependencies for the application 102 (block 404). For example, the service analyzer 136 may determine other service(s) and/or VMs 114 on which services operating on the selected VM 114 depend. […] The example service analyzer 136 of FIG. 1 analyzes the selected VM 114 to determine other VM identifiers for the application 102 (block 410). […] The example service analyzer 136 of FIG. 1 determines whether additional VMs 114 have been identified from analysis of the selected VM (block 412). If VMs have been identified (block 412), the example service analyzer 136 adds any identified (e.g., newly-identified) VMs 114 to a list of VMs to be analyzed (block 414). The list of VMs to be analyzed may be used by the example service analyzer 136 to identify further VMs 114 that implement the application 102 […] the example service analyzer 136 determines whether additional VMs in the list of VMs are to be analyzed (block 416). […] the application definition generator 142 may generate the application definition 148 for the application 102 based on a list of VMs identified by the service analyzer 136 and VMs seeded to the example service analyzer 136 .” The service analyzer generates an application definition (by executing a discovery script based on a seed VM as disclosed in [0056]), which involves iteratively identifying all the VMs (i.e., components) of the application 102 as described with respect to Fig. 4.). Regarding claim 7, the combination of Hassine in view of Rao teaches The method of claim 6. Hassine further teaches wherein at least one automation in the set of automations comprises executable code configured to identify dependent infrastructure resources for each of the application components of the workload deployment ([0046] – “ the service analyzer 136 of the illustrated example may access and/or execute the discovery script(s) in the discovery script repository 146 to discover properties such as dependencies, node cluster definitions, and/or interfaces to other, unidentified ones of the VMs 114 in the application 102. The example service analyzer 136 adds the discovered ones of the VMs 114 ”; [0056] – “ the service analyzer 136 calls a first discovery script to determine the application definition based on identification of a seed VM 114, and the CU analyzer 138 calls a second discovery script to obtain the configurations of the VMs 114 when the application definition 148 is generated (e.g., via running the first discovery script) ”; [0079] – “ FIG. 4 is a flowchart representative of example machine readable instructions 400 which may be executed to implement the example service analyzer 136 of FIG. 1 to determine CUs in an application definition .”; [0081] – “ The example service analyzer 136 analyzes the selected VM 114 to determine dependencies for the application 102 (block 404). For example, the service analyzer 136 may determine other service(s) and/or VMs 114 on which services operating on the selected VM 114 depend .”; [0082] – “ The example service analyzer 136 analyzes the selected VM 114 to identify node clusters for the application (block 406) .”; [0083] – “ The example service analyzer 136 of FIG. 1 analyzes the selected VM 114 to determine port configuration(s) for the application (block 408). ”; [0085] – “ example service analyzer 136 adds any identified (e.g., newly-identified) VMs 114 to a list of VMs to be analyzed (block 414). The list of VMs to be analyzed may be used by the example service analyzer 136 to identify further VMs 114 that implement the application 102 ”) . Regarding claim 9, Hassine teaches A computer-readable media comprising computer-executable instructions that, upon execution by a processor, cause the processor to perform a method for discovering a workload deployment ([0071] – “ Flowcharts representative of example machine readable instructions for implementing the system 100 of FIG. 1 is shown in FIGS. 3, 4, 5, 6, and/or 7. In this example, the machine readable instructions comprise programs for execution by a processor such as the processor 812 shown in the example processor platform 800 discussed below in connection with FIG. 8. The programs may be embodied in software stored on a tangible computer readable storage medium ”; [0072] – “ the example processes of FIGS. 3-7 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium ”) , the method comprising: the method of claim 1. As such, claim 9 is rejected as being unpatentable over Hassine in view of Rao for the same reasons presented with respect to claim 1. Claims 11-13 recite substantially the same limitations as those recited in claims 4 and 6-7, applied to the computer-readable media of claim 9. As such, claims 11-13 are rejected as being unpatentable over Hassine in view of Rao for the same reasons presented with respect to claims 4 and 6-7. Regarding claim 14, Hassine teaches A system (processor platform 800) comprising: a processor (processor 812) ; and a set of machine-readable storage media (mass storage device 828, volatile memory 814, non-volatile memory 816) comprising at least one machine-readable storage medium storing computer-executable instructions (coded instructions 832) that, upon execution by the one or more processors, cause the processors to perform a method for discovering a workload deployment ([0071] – “ machine readable instructions for implementing the system 100 of FIG. 1 is shown in FIGS. 3, 4, 5, 6, and/or 7. In this example, the machine readable instructions comprise programs for execution by a processor such as the processor 812 shown in the example processor platform 800 ”; [0112] – “ FIG. 8 is a block diagram of an example processor platform 800 capable of executing the instructions of FIGS. 3, 4, 5, 6, and/or 7 to implement the application director 106 and/or the virtual infrastructure navigator 108 of FIG. 1. ”; [0120] – “ The coded instructions 832 of FIGS. 3-7 may be stored in the mass storage device 828, in the volatile memory 814, in the non-volatile memory 816, and/or on a removable tangible computer readable storage medium ”) , the method comprising: the method of claim 1. As such, claim 14 is rejected as being unpatentable over Hassine in view of Rao for the same reasons presented with respect to claim 1. Claim 15, 17, and 18-19 recite substantially the same limitations as claims 2, 4, and 6-7, applied to the system of claim 14. As such, claims 15, 17, and 18-19 are rejected as being unpatentable over Hassine in view of Rao for the same reasons presented with respect to claims 2, 4, and 6-7 . 07-22-aia AIA Claim s 3 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Hassine in view of Rao as applied to claim s 1 and 14 above, and further in view of KONO (U.S. Pub. No. 2017/0168866) . Regarding claim 3, the combination of Hassine in view of Rao teaches The method of claim 1. Hassine further teaches wherein the obtaining of the workload application identification information comprises receiving […] a compute resource identity ([0045] – “ example service analyzer 136 of FIG. 1 receives (e.g., from the administrator 116) a VM identifier ( e.g., a VIN ID) and/or an IP address 150 of a currently-running VM 114 ”; [0086] – “ administrator 116 (or another user) may seed an additional VM identifier to the service analyzer 136 to continue identifying the VMs 114 that implement the application 102. […] Additionally or alternatively, the example service analyzer 136 may receive an application identifier 152 for the application 102, such as a unique application name and an identifier of the deployment environment 104 in which the application 102 is deployed .”). The combination of Hassine in view of Rao fails to expressly teach receiving a workload type and the compute resource identity from a user interface. However, KONO teaches receiving a workload type and a compute resource identity from a user interface ([0108]-[0109] – “ The confirmation GUI 1600-B may include a number of fields providing information entered by the application administrator 1010 for confirmation. For example, field 1610-B may provide the application type and field 1620-B may provide the application name. Further, field 1630- B may provide the number of VMs which run the application. […] Column 1641-B may provide the name of the VM. This name may be created from application name 1620-B by the management program 2410 .”). KONO is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of managing complex workloads comprising a plurality of components. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Hassine in view of Rao such that the compute resource identifier received from an administrator in obtaining the workload application identification information as taught by Hassine is received with a workload type from a user interface as taught by KONO. Incorporating the application type and user interface used by an administrator as taught by KONO would improve the administrator’s ability to manage the deployed applications and the infrastructure, e.g., by helping them to make decisions regarding migrating or replacing one or more VMs based on the application type in order to optimize the infrastructure (see KONO: [0011]-[0013], [0048]). Claim 16 recites substantially the same limitations as claim 3, applied to the system of claim 14. As such, claim 16 is rejected as being unpatentable over Hassine in view of Rao, and further in view of KONO for the same reasons presented with respect to claim 3 . 07-22-aia AIA Claim s 8, 10, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hassine in view of Rao as applied to claim s 1, 9 and 14 above, and further in view of Bahl et al. (U.S. Pub. No. 2021/0019194), hereinafter Bahl . Regarding claim 8, the combination of Hassine in view of Rao teaches The method of claim 1, but fails to expressly teach wherein: a representation of the workload abstraction is presented to a user by a user interface that is generated by a management plane for the infrastructure; the performing of the management operation is in response to an instruction received from the user via the user interface, the instruction being applied by the user to the workload abstraction; and the performing of the management operation is redirected, using the data structure, by the management plane to a set of the workload components of the workload deployment or a set of the infrastructure resources corresponding to ones of the workload components of the workload deployment. However, Bahl teaches a representation of the workload abstraction is presented to a user by a user interface that is generated by a management plane for the infrastructure ([0068] – “ The management plane 410 can be used to deploy one or more applications that comprise multiple microservice containers interconnected via a service mesh that can span the multiple CSP networks 442 depending on TCOs, SLAs, and other governance information for the deployed applications .”; [0071] – “ The management plane 410 can include a User Interface (UI) 412 […] Administrators can utilize the UI 412 to deploy and manage a service mesh application ”; [0072] – “ the UI 412 may utilize a platform-independent and portable object model that combines infrastructure-automation and application-automation layers in a single, deployable blueprint (sometimes referred to as an application profile) . Application profiles can include TCO constraints, SLA requirements, and other criteria provisioning, deployment, and operation of an application, as well as outline the relationship between deployment environments, applications, application components , and so forth. The application profile can be encoded using Extensible Mark-up Language (XML), JavaScript® Object Notation (JSON), Yet Another Mark-up Language (YAML), or other suitable format, and can include a description of the topology of an application, infrastructure and network service requirements, a descriptions of deployment artifacts (e.g., packages, binaries, scripts, data, etc.), orchestration procedures needed to deploy, configure, and secure the application, run-time policies that guide ongoing lifecycle management, upgrade information, backup-and-restore information, and so forth .”; [0098] – “ the multi-cloud service mesh orchestration platform can include a user interface (e.g., the UI 412) to enable a user to define an application profile and to deploy a service mesh application or to update an application profile and modify an existing service mesh application . ”) ; the performing of the management operation is in response to an instruction received from the user via the user interface, the instruction being applied by the user to the workload abstraction ([0098] – “ an activity 506 in which the multi-cloud service mesh orchestration platform may receive a request to modify an existing service mesh application. In some embodiments, the multi-cloud service mesh orchestration platform can include a user interface (e.g., the UI 412) to enable a user […] to update an application profile and modify an existing service mesh application .”) ; and the performing of the management operation is redirected, using the data structure, by the management plane to a set of the workload components of the workload deployment or a set of the infrastructure resources corresponding to ones of the workload components of the workload deployment (FIGS. 5A, 5B, flow which goes through at least steps 506, 508, and 530; [0095] – “ the workflow 500 can be performed at least in part by a user interface (e.g., the user interface 412), a management plane (e.g., the management plane 410)”; [0099]-[0100] – “ From the activity 504 or the activity 506, the workflow 500 can proceed to an activity 508 in which the multi-cloud service mesh orchestration platform can partition the service mesh application to be deployed or updated per the received request into the application's constituent components (e.g., layers, services, microservices, etc.). In this example, the platform can determine the microservice containers that make up the service mesh application. For instance, the multi-cloud service mesh orchestration platform can parse the application profile for E_APP to determine that the service mesh application comprises microservice containers E_APP_MICRSVC_1, E_APP_MICRSVC_2, . . . , and E_APP_MICRSVC_N. After the platform determines the constituent components of the service mesh platform, the workflow 500 can continue to an activity 510, an activity 512, and an activity 514 that the multi-cloud service mesh orchestration platform can perform for each microservice container to determine the various deployment and operational parameters of the individual components of the service mesh application. For example, at the activity 510, the multi-cloud service mesh orchestration platform can instantiate microservice configuration objects for each microservice container .”; [0106] – “At the decision block 530, the multi-cloud service mesh orchestration platform can determine whether to migrate existing microservice containers”; [0116] – “the multi-cloud service mesh orchestration platform can include a user interface (e.g., the UI 412) to enable an administrator to define an application profile and to deploy a corresponding application or to update an application profile and modify an existing application corresponding to the updated application profile.” ) . Bahl is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of managing complex workloads comprising a plurality of components. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Hassine such that the management operation performed using the workload abstraction (the application blueprint taught by Hassine) is performed according the methods taught by Bahl. Hassine suggests allowing an administrator, i.e., user, to manage the application (see Hassine: [0078]), and doing so according the methods of Bahl would allow the administrator to more easily manage the multi-component application and enable the administrator to migrate components of the application across multiple clouds achieve the advantages provided by multi-cloud computing (see Bahl: [0002] and [0013]-[0018]). Claim 10 recites substantially the same limitations as claim 8, applied to the computer-readable media of claim 9. As such, claim 10 is rejected as being unpatentable over Hassine in view of Rao, and further in view of Bahl for the same reasons presented with respect to claim 8. Claim 20 recites substantially the same limitations as claim 8, applied to the system of claim 14. As such, claim 20 is rejected as being unpatentable over Hassine in view of Rao, and further in view of Bahl for the same reasons presented with respect to claim 8 . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Dahl et al. (U.S. Patent No. 12,353,856) teaches an application mapping engine retrieving, from an application dependency mapping database, information for mapping the architecture of an application, including application components, infrastructure components, and interconnections, determining dependency data based on monitored runtime data for the application, processing the determined dependency data into a JSON data structure, and generating a dependency visualization (see Abstract; Col. 1, lines 35-57, Col. 6, lines 1-24, and Col. 9, lines 36-55). Suit (U.S. Pub. No. 2012/0096142) teaches creating an ontology for a primary application indicated by a user by analyzing components of the network, using software agents deployed to the operating systems of VMs, which have “communicates_with” relationships in the defined executables of the primary application (see [0040] and [0059]). VRUDHALA et al. (U.S. Pub. No. 2023/0022079) teaches a method of application identification in a virtualized computing system, including executing process discovery agents for a plurality of VMs in the computing system, receiving process metadata from the process discovery agents describing processes executing on the VMs, generating signatures based on the process metadata, and determining application components by comparing the generated signatures with those in a database (see Abstract, [0033]). It further teaches metadata for components can be collected with custom collector scripts specific to an identified component type (see [0016]). Mohaban et al. (U.S. Pub. No. 2013/0325899) teaches a method for performing top-down discovery of applications by identifying an application associated with an entry point, then recursively identifying dependencies between each individual infrastructure element associated with the entry point until all infrastructure elements serving the application have been identified and a topology defining dependencies between the elements has been identified (see [0014]). Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 9:00 am - 5:00 pm. 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, Kevin Young can be reached at 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. /JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194 Application/Control Number: 18/631,028 Page 2 Art Unit: 2194 Application/Control Number: 18/631,028 Page 3 Art Unit: 2194 Application/Control Number: 18/631,028 Page 4 Art Unit: 2194 Application/Control Number: 18/631,028 Page 5 Art Unit: 2194 Application/Control Number: 18/631,028 Page 6 Art Unit: 2194 Application/Control Number: 18/631,028 Page 7 Art Unit: 2194 Application/Control Number: 18/631,028 Page 8 Art Unit: 2194 Application/Control Number: 18/631,028 Page 9 Art Unit: 2194 Application/Control Number: 18/631,028 Page 10 Art Unit: 2194 Application/Control Number: 18/631,028 Page 11 Art Unit: 2194 Application/Control Number: 18/631,028 Page 12 Art Unit: 2194 Application/Control Number: 18/631,028 Page 13 Art Unit: 2194 Application/Control Number: 18/631,028 Page 14 Art Unit: 2194 Application/Control Number: 18/631,028 Page 15 Art Unit: 2194 Application/Control Number: 18/631,028 Page 16 Art Unit: 2194 Application/Control Number: 18/631,028 Page 17 Art Unit: 2194 Application/Control Number: 18/631,028 Page 18 Art Unit: 2194 Application/Control Number: 18/631,028 Page 19 Art Unit: 2194 Application/Control Number: 18/631,028 Page 20 Art Unit: 2194 Application/Control Number: 18/631,028 Page 21 Art Unit: 2194 Application/Control Number: 18/631,028 Page 22 Art Unit: 2194 Application/Control Number: 18/631,028 Page 23 Art Unit: 2194
