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 .
DETAILED ACTION
The instant application having Application No. 18/649,909 filed on 4/29/2024 is presented for examination.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Drawings
The applicant’s drawings submitted are acceptable for examination purposes.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web.
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.
Claims 1-5, 10-14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Howley (US 20230259390) in view of Hashimoto (US 20210328864).
As per claim 1, Howley discloses an automated infrastructure-as-code cloud-infrastructure manager (Abstract “providing a simplified 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.”); comprising:
one or more computer systems, each containing one or more processors, one or more memories, and one or more data-storage devices (Paragraph 29); and
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 infrastructure-as-code cloud-infrastructure manager, the infrastructure-as-code cloud-infrastructure manager (Paragraph 30 “FIG. 2 shows a flow diagram illustrating processing performed by an IaC architecture in accordance with an example. In the context of the present example, it is assumed a cloud platform (e.g., a cloud platform providing an as-a-service cloud service offerings such as a CaaS service, a VMaaS service, and/or a BMaaS service)) implements an IaC service (e.g., IaC service 130) to process deployment requests issued by an end-user (e.g., service user 113) of the cloud platform.”), comprising:
a management interface configured to receive cloud-infrastructure-management commands and requests, including idempotent state commands that deploy and configure cloud infrastructure (Paragraph 65 “Instructions 530, upon execution, may cause processing resource 510 to provide an API (e.g., API 131) of an IaC service (e.g., IaC service 130) through which multiple IaC templates are available for use to deploy workloads against services within a cloud platform. Each of the IaC templates describes a workload according to an IaC tool of a plurality of IaC tools and specifies input parameters for the workload. The API thus abstracts operational details associated with the plurality of IaC tools. In one example, instructions 530 may be useful for performing block 210 of FIG. 2.”);
an execution engine configured to execute the received cloud-infrastructure-management commands and requests (Paragraph 19 “In the context of the present example, IaC architecture 100 includes an IaC service 130, an IaC database 140, and one or more IaC agents 150a-b. The IaC architecture 100 may also include or otherwise be coupled with a version control system 120 (e.g., Git, an open-source version-control system designed to handle very large projects that may be distributed over multiple repositories (e.g., repositories 121a-n)). Depending upon the particular use case, the IaC agent 150a-b may be deployed within a public cloud (e.g., cloud 110) or on-premise 160 in a data center or colocation.” See also, paragraph 27 “In the context of the present example, the IaC agents 150a-b are shown including mutators 151a-b. The mutators 151a-b may be responsible for managing the launching and orchestration of a particular IaC tool (e.g., Terraform, Pulumi, Ansible, Chef, or Puppet), parsing of that tool's output to determine the outcome or status, and persisting the state of the deployment (e.g., to the IaC database 140) to facilitate future updates via the API 131 and/or to allow the end-user to determine when the deployment has completed.”).
Howley does not expressly disclose but Hashimoto discloses parameterizer configured to generates a parameterized cloud-infrastructure template from one or more cloud-infrastructure-specification-and-configuration files (Abstract “generating a configuration file for configuring an information technology infrastructure is provided. The method may include receiving, from a first user at a first client, a first indication to publish an infrastructure module comprising a set of configurations to apply to an information technology infrastructure. The infrastructure module may be stored in a module registry in response to the first indication.” See also, paragraph 58 “Deploying the software application may require configuring an enterprise's information technology infrastructure to host the software application including, for example, by provisioning, modifying, and/or de-provisioning one or more hardware resources, software resources, network resources, and/or the like.”).
Therefore it would have been obvious to one of ordinary skill in the before the effective filing date of the claimed invention to modify the manager of Howley to include the teachings of Hashimoto because the IaC configuration files produce reusable parameterized IaC configurations which are suitable for executing in the IaC service of Howley which decreases the amount of time needed to create the configuration files.
As per claim 2, Hashimoto further discloses wherein the parameterizer generates a parameterized cloud-infrastructure template comprising:
one or more parameterized cloud-infrastructure-specification-and-configuration files; and a parameters file (Paragraph 136 “To select and/or add, for example, to the second configuration file 125b, the first module 116a and/or the second module 116b, the second user 145b at the second client 120b may navigate to a list of modules using the button 3085. The “Select Modules” page 3000 may display a filterable and/or searchable list 3030 of at least a portion of the modules available from the module registry 115. Any quantity of modules from the filterable and/or searchable list 3030 may be added to by clicking the button 3020. List 3040 may display a list of the selected modules.”)
As per claim 3, Howley further discloses wherein the parameters file contains a map that maps variable names to values, including string values and list values (Paragraph 35 “At block 230, the request is satisfied by internally executing the IaC tool associated with the particular template based on parameter values supplied for specified input parameters for the particular workload. For example, assuming a mode of IaC interaction in which the end-user invokes a method of the API (e.g., via a client of the cloud platform, a Representational State Transfer (REST) client or a CLI of the cloud platform), execution of the method may persist a new deployment request (e.g., create, apply, update get status, or destroy, as the case may be) to an IaC database (e.g., IaC database 140).”).
As per claim 4, Howley further discloses wherein the one or more parameterized cloud-infrastructure-specification-and-configuration files comprise:
one or more resource descriptors (Paragraphs 59-60);
one or more of a first type of parameter call that each replaces a value field in one or more of the resource descriptors (Paragraph 59 “In the above examples, definition of standard templates has been described in which a given template describes a specific workload based on some subset of the resources provided by the cloud service API. The associated parameter list for such a template establishes the constraints of the workload description and allows for a simplified means of workload deployment for an IaC service consumer.);
one or more of a second type of parameter call that each replaces a resource-identifier in one or more of the resource descriptors (Paragraph 24); and
one or more argument bindings that each replaces a resource identifier in one or more of the resource descriptors (Paragraph 24 “The persisted template records (e.g., service template 141) may include a reference to the source repository (e.g., one of repositories 121a-b), a version-control system reference (e.g., a git reference), identifying a specific revision when multiple revisions of the same template exist, and a path or name that identifies that template. The inclusion of a version-control system reference in each template provides flexibility. For example, different versions of the same workload can be requested (e.g., different deployments referring to different revisions of the same template). Additionally, the inclusion of a version-control system reference facilitates the creation of workloads based off development branches of a template (typically in a non-production environment).”).
As per claim 5, Howley further discloses wherein parameterizer that generates a parameterized cloud-infrastructure template from one or more cloud-infrastructure-specification-and-configuration files by:
validating the one or more cloud-infrastructure-specification-and-configuration files while compiling the one or more cloud-infrastructure-specification-and-configuration files into one or more equivalent cloud-infrastructure-specification-and-configuration files represented in a data-representation language (Paragraph 87 “For instance, the validation engine 170 may perform a first tier of validation by at least determining the structural validity of the configurations associated with the execution plan 190 including, for example, the syntactic validity and/or semantic validity of the configurations associated with the execution plan 190. If the configurations associated with the execution plan 190 successfully passes the first tier of validation, the validation engine 170 may perform a second tier of validation by at least determining whether the configurations comply with one or more policies including, for example, a first policy 175a, a second policy 175b, and/or the like. The first policy 175a and/or the second policy 175b may impose limitations on the resources allocated by the configurations associated with the execution plan 190. Upon determining that the configurations associated with the execution plan 190 comply with the one or more policies, the validation engine 170 may perform a third tier of validation by at least determining whether the configurations associated with the execution plan 190 meet one or more cost quotas including, for example, a first quota 175c, a second quota 175d, and/or the like. The first quota 175c and/or the second quota 175d may impose target values and/or limits on the projected costs of the configurations associated with the execution plan 190.”); and
processing the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language to generate the parameterized cloud-infrastructure template (Paragraph 88).
As per claims 11-15, they are method claims having similar limitations as cited in claims 1-5 and are rejected under the same rationale.
As per claim 20, it is a system claim having similar limitations as cited in claim 1 and is thus rejected under the same rationale.
Allowable Subject Matter
Claims 6-10 and 15-19 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.
The following is a statement of reasons for the indication of allowable subject matter:
The prior art fails to disclose or make obvious the following features:
Claim 6:
The automated infrastructure-as-code cloud-infrastructure manager of claim 5 wherein processing the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language to generate the parameterized cloud-infrastructure template further comprises:
processing the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language to generate a build-insights response that comprises:
for each resource descriptor in the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language:
a copy of the resource descriptor;
a list of paths to value fields in the resource descriptor; and
for each field value in the resource descriptor:
a list of paths to the field value; and
for each resource type in the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language:
a count of the number of resource descriptors of the resource type in the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language; and
for each path in the resource descriptors in the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language:
a count of the number of occurrence of the path in the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language;
indications of the different values referenced by the path; and
a uniqueness value; and
processing the build-insights response to generate the parameterized cloud-infrastructure template.
Claim 15:
The method of claim 14 wherein processing the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language to generate the parameterized cloud-infrastructure template comprises:
processing the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language to generate a build-insights response that comprises:
for each resource descriptor in the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language
a copy of the resource descriptor,
a list of paths to value fields in the resource descriptor, and
for each field value in the resource descriptor,
a list of paths to the field value, and
for each resource type in the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language,
a count of the number of resource descriptors of the resource type in the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language, and
for each path in the resource descriptors in the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language,
a count of the number of occurrence of the path in the equivalent cloud-infrastructure-specification-and-configuration files represented in the data-representation language,
indications of the different values referenced by the path, and
a uniqueness value; and
processing the build-insights response to generate the parameterized cloud-infrastructure template.
Any claim that depends on claim 6 or 15 is objected to for at least the same reason above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Khakare US 20210055917 discloses deploy cloud infrastructure. In one approach, a method includes creating a blueprint using a user interface displayed at a user device, automatically generating code based on the blueprint (e.g., generating the code using a server), and deploying the cloud infrastructure using the code (e.g., deploying to the AWS cloud).
Joukov US 20120054727 discloses discovering one or more instances of external resource access by statically analyzing application code. One or more locations of constants are identified in the application code and a configuration repository that specify addresses of discovered instances of external resource access. The application code and the configuration repository are updated to change values of the constants to enable migration.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY A MUDRICK whose telephone number is (571)270-3374. The examiner can normally be reached 9am-5pm Central Time.
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, Pierre Vital can be reached at (571)272-4215. 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.
/TIMOTHY A MUDRICK/Primary Examiner, Art Unit 2198/ 8/25/2026
Prosecution Insights