DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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-3, 14 & 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Welch et al. (U.S. Pub 2021/0359920) hereinafter Welch, in view of Howley et al. (U.S. Pub 2023/0259390) hereinafter Howley.
As per Claim 1, Welch teaches An automated cloud-infrastructure manager comprising: one or more computer systems, each containing one or more processors, one or more memories, one or more data-storage devices, and one or more display devices; a set of cloud-infrastructure specification-and-configuration data files stored in one or more of the one or more memories and one or more data-storage devices; and (Fig. 1B, ¶27, ¶48, ¶49 wherein at least a portion of the information technology infrastructure 130 may be configured using infrastructure as code (IaC). That is, instead of and/or in addition to physical hardware configuration, the information technology infrastructure 130 may be configured via software using, for example, one or more configuration files specifying the configurations to apply to the information technology infrastructure 130 as well as one or more corresponding variables wherien the state controller 180 may be configured to track the changes that are applied to the configurations of the information technology infrastructure 130. For example, the state controller 180 may generate and store a state file prior to implementing an execution plan wherien The information technology infrastructure controller 110 may determine, based on one or more state files generated and stored by the state controller 180, a previous state of the information technology infrastructure 130 )
a graph-based user interface that displays, on one or more of the one or more display devices, a graph-based visual representation of cloud-infrastructure information contained in the set of cloud-infrastructure specification-and-configuration data files. (¶40, ¶41, ¶42 wherien The information technology infrastructure controller 110 may generate the execution plan 190, including by creating a corresponding dependency graph (e.g., a directed acyclic graph (DAG) and/or the like) having a plurality of nodes, at least some of which are interconnected by one or more directed edges )
However, Welch does not explicitly teach processor instructions, stored in one or more of the one or more memories that, when executed by one or more of the one or more processors, control the one or more computer systems to implement the automated cloud-infrastructure manager, the automated cloud- infrastructure manager comprising a management interface that receives cloud-infrastructure-management commands and requests, including idempotent state commands that deploy and configure cloud infrastructure according to the set of cloud-infrastructure specification-and- configuration data files, an execution engine that executes the received cloud-infrastructure- management commands and requests, and
Howley teaches processor instructions, stored in one or more of the one or more memories that, when executed by one or more of the one or more processors, control the one or more computer systems to implement the automated cloud-infrastructure manager, (Fig. 5, ¶62, ¶63 wherien rocessing resource 510 may include a microcontroller, a microprocessor, CPU core(s), GPU core(s), an ASIC, an FPGA, and/or other hardware device suitable for retrieval and/or execution of instructions from machine readable medium 520 to perform the functions)
the automated cloud- infrastructure manager comprising a management interface that receives cloud-infrastructure-management commands and requests, (Fig. 1, ¶58 wherein an IaC service (e.g., IaC service 130 of FIG. 1) may also allows a user to chain one or more deployment requests, whereby the outputs of one completed deployment are used as inputs for a subsequent deployment. For example, different IaC tooling can be chained together (e.g., Terraform or Pulumi can be used to deploy infrastructure and Ansible or Chef or Puppet can subsequently be used to run post-deployment configuration tasks. More specifically, a first deployment of a chain could be based on a Terraform template to configure a set of bare-metal hosts with an operating system and some basic network configuration. The output of the first deployment, including the assigned IP addresses for each host could then be used as input to a subsequent deployment based on an Ansible playbook to install and configure application software on the provisioned bare-metal hosts)
including idempotent state commands that deploy and configure cloud infrastructure according to the set of cloud-infrastructure specification-and- configuration data files, an execution engine that executes the received cloud-infrastructure- management commands and requests, and (¶36 , ¶49 wherein the end-user making an API request (at 401) to create a deployment based on the TF #1 template (one of a number of available service templates 441, which may each provide for deploying different workloads), supplying the parameter values for that template. This deployment is in turn persisted in the IaC database 440 wherien responsive to an IaC agent (e.g., IaC agent 150a) detecting and fetching the new deployment request, the IaC agent may retrieve the template code associated with the deployment request from the source repository (e.g., repository 121a) and may cause the relevant mutator component (e.g., mutator 151a) to spawn a new container to execute the corresponding IaC tool with the template and input deployment parameters supplied by the end-user. Execution of the container may result in one or more calls to the cloud service (e.g., a CaaS service, a VMaaS service, or a BMaaS service, as the case may be) used by the template to deploy the workload it describes. In one example, the state of the deployment is persisted to facilitate future updates via the API. For example, the IaC agent may report the status of the ongoing deployment, including its final status upon completion and persist the state to the IaC database. The end-user may invoke the API to retrieve the current status of its requested deployment and use the results of the call to determine when the deployment has completed)
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to utilize the teaching of infrastructure as code service of Howley with the teaching of ticket based provisioning of cloud infrastructure for a SAAS provider of Welch because Howley teaches providing a simplified and improved interface by a cloud platform to an IaC service. According to an example, operational details associated with multiple infrastructure as code (IaC) tools are abstracted by providing an application programming interface (API) of an IaC service through which multiple IaC templates are available for use to deploy workloads against multiple services within a cloud platform. Each IaC template describes a workload according to an IaC tool and specifies input parameters for the workload. A request to create a deployment based on a particular IaC template is received via the API. The request is satisfied by internally executing the IaC tool associated with the particular template based on parameter values supplied for the specified input parameters for the particular workload. (Abstract)
As per Claim 2, the rejection of claim 1 is hereby incorporated by reference; Welch as modified further teaches wherein graph-based visual representation of cloud-infrastructure information contained in the set of cloud-infrastructure specification-and-configuration data files is generated by: receiving the set of cloud-infrastructure specification-and-configuration data files; (Fig. 1B, ¶27, ¶48, ¶49 wherein at least a portion of the information technology infrastructure 130 may be configured using infrastructure as code (IaC). That is, instead of and/or in addition to physical hardware configuration, the information technology infrastructure 130 may be configured via software using, for example, one or more configuration files specifying the configurations to apply to the information technology infrastructure 130 as well as one or more corresponding variables wherien the state controller 180 may be configured to track the changes that are applied to the configurations of the information technology infrastructure 130. For example, the state controller 180 may generate and store a state file prior to implementing an execution plan wherien The information technology infrastructure controller 110 may determine, based on one or more state files generated and stored by the state controller 180, a previous state of the information technology infrastructure 130; as taught by Welch)
extracting resource objects from the cloud-infrastructure specification-and- configuration data files; interactively processing a next set of resource objects from the extracted resource objects to generate a next unit of graph information until the extracted resource objects have been processed; and (Fig. ¶42 wherien The information technology infrastructure controller 110 may generate the dependency graph by at least adding, to the dependency graph, one or more resource nodes corresponding to individual resources including, for example, one or more hardware resources 135a, software resources 135b, network resources 135c, and/or the like. The one or more resource nodes may be mapped to the corresponding provider nodes, for example, to identify the first provider 150a and/or the second provider 150b as being the provider of the resources associated with each of the resource nodes. Moreover, the information technology infrastructure controller 110 may generate the dependency graph by at least inserting one or more edges to interconnect, for example, the resource nodes and the provider nodes. An edge interconnecting a resource node to a provider node may identify the provider associated with the provider node as being a provider of the resource associated with the resource node. Meanwhile, an edge interconnecting two resource nodes may indicate a dependency between the resources associated with the two resource nodes; as taught by Welch)
incorporating each unit of graph information into a stored graph representation of cloud-infrastructure information contained in the set of cloud-infrastructure specification-and- configuration data files. (¶43 wherien To represent resources that require de-provisioning, the dependency graph may include one or more “orphan” resource nodes, which may be disconnected from the provider nodes and other resource nodes in the dependency graph. Alternatively and/or additionally, in order to represent the modification of an existing resource within the information technology infrastructure 130, the information technology infrastructure controller 110 may generate the dependency graph by at least splitting the corresponding resource node into a first resource node and a second resource node. The first resource node may correspond to the existing resource, which may be de-provisioned when the configurations specified in the execution plan 190 are applied to the information technology infrastructure 130. Meanwhile, the second resource node may correspond to the modified resource, which may be provisioned when the configurations specified in the execution plan 190 are applied to the information technology infrastructure 130; as taught by Welch)
As per Claim 3, the rejection of claim 2 is hereby incorporated by reference; Welch as modified further teaches wherein each resource object corresponds to specification and configuration information for a resource contained in the set of cloud-infrastructure specification-and-configuration data files. (Fig. 1B, ¶27, ¶48, ¶49 wherein at least a portion of the information technology infrastructure 130 may be configured using infrastructure as code (IaC). That is, instead of and/or in addition to physical hardware configuration, the information technology infrastructure 130 may be configured via software using, for example, one or more configuration files specifying the configurations to apply to the information technology infrastructure 130 as well as one or more corresponding variables wherien the state controller 180 may be configured to track the changes that are applied to the configurations of the information technology infrastructure 130. For example, the state controller 180 may generate and store a state file prior to implementing an execution plan wherien The information technology infrastructure controller 110 may determine, based on one or more state files generated and stored by the state controller 180, a previous state of the information technology infrastructure 130 ; as taught by Welch)
Claim 14 is similar in scope to Claim 2; therefore, Claim 14 is rejected under the same rationale as Claim 2.
Claim 22 is similar in scope to Claim 2; therefore, Claim 22 is rejected under the same rationale as Claim 2.
Allowable Subject Matter
Claims 4-13 & 15-21 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.
Related Art
Related art not relied upon Haprian et al. (U.S. Pub 2021/0209108) for teaching graph path search that triangulate based on landmark vertices to accelerate searching for a few shortest paths between a source vertex and a target vertex.
Inquiry
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANGIE BADAWI whose telephone number is (571)270-7590. The examiner can normally be reached Monday thru Wednesday 9:00am - 5:00pm EST with Thursdays and Fridays off.
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, Fred Ehichioya can be reached at (571) 272-4034. 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.
/ANGIE BADAWI/ Primary Examiner, Art Unit 2179