DETAILED ACTION
This action is responsive to Remarks and Claim amendments filed on March 16, 2026.
Claims 1, 4-12 and 15-21 have been amended. Claims 2-3 and 13-14 have been cancelled. Claims 22-25 have been newly added.
Claims 1, 4-12 and 15-25 are pending and are presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to amendments
The objection of claims 1-21 is withdrawn in view of applicant’s amendments.
Response to Applicant’s Arguments
Applicant’s arguments filed in response to the prior Office action have been fully considered but are unpersuasive in part for the reasons set forth below. The Examiner acknowledges that Applicant correctly identified an inaccuracy in the prior mapping of Lee’s “deployed state data 144” to the recited “second list,” and the present rejection clarifies the correct mapping.
Regarding Applicant’s Argument A (Lee’s “deployed state data 144” mapping):
Applicant correctly observes that Lee’s deployed state data 144 is generated by state generator 142 from provider schema data 110 and current state data 120 (Lee paragraphs [0039]–[0040]) and therefore reflects the actual cloud state, not the initially specified baseline. This argument is acknowledged. However, the rejection does not depend on mapping deployed state data 144 to the recited “second list.” The correct mapping is set forth below: the recited “second list cloud resources managed by the IaC tool” corresponds to Lee’s IAC 130 (and the configuration graph 148 generated therefrom), which expressly reflects the desired/baseline cloud infrastructure (Lee paragraph [0006], “the desired infrastructure that is reflected in the … IAC code that describes the desired infrastructure”. Paragraph [0018], “first infrastructure code that reflects a desired cloud infrastructure”. Paragraph [0029] and figure 1 (IAC 130 as input to remediation engine). Paragraph [0034] and figure 2 (configuration graph 148 representing the IaC). Paragraohs [0061]–[0063] (“Original Configuration Code” as the baseline IaC)). Under this mapping, every sub-element of the recited “second list” is taught: (a) it is retrieved from / managed by the IaC tool (Lee paragraphs [0029], [0034]); (b) it includes deployed states of managed cloud resources (Lee paragraph [0024] (resource blocks within IaC). Paragraph [0034] (provider/resource attribute schemas)); and (c) the deployed states correspond to an initially specified operation baseline (Lee paragraphs [0006], [0018], [0061]).
Regarding Applicant’s Argument B (direction of remediation):
Applicant argues that Lee remediates by updating the IaC code to reflect the actual cloud (Lee paragraphs [0018], [0029] “updated IAC 160”) rather than by applying configuration code to bring the cloud into alignment with the baseline, and therefore Lee does not teach “the current operational state matches the deployed state of the misaligned cloud resource.” This argument is acknowledged with respect to Lee taken in isolation. However, the present rejection is under 35 U.S.C. § 103, not § 102, and is set forth in view of Applicant’s admitted prior art (AAPA) per MPEP § 2129. Specifically, the present application’s specification at [006] expressly admits: “Existing laC tools, such as Terraform may detect drifts in cloud resources and apply a fix on such resources. … existing laC tools merely override the current state of a drifted resource with the initially configured state.” This admission establishes that applying configuration code via an IaC tool to override the current cloud state with the initially configured/deployed state is conventional in the art at the time of the invention. The combination of Lee’s automated drift detection and configuration-code generation with the AAPA’s automated apply-baseline-to-cloud step yields the recited limitation. Applicant cannot simultaneously distinguish Lee on directionality grounds while their own specification admits that the recited direction is the conventional behavior of existing IaC tools.
Regarding Applicant’s Argument C (claim 4 — unmanaged resources):
Applicant’s argument that Lee’s “trimming” phase at paragraphs [0067]–[0068] addresses the inverse direction (nodes in IaC but absent from the cloud) is acknowledged as to Lee taken in isolation. However, the present rejection introduces additional prior art — Jourdan, S., “Detect infrastructure drift and unmanaged resources with Snyk IaC,”, May 9, 2022 (hereinafter “Jourdan”); and the publicly available GoogleCloudPlatform/terraformer documentation (hereinafter “Terraformer”), as archived at the Internet Archive Wayback Machine on May 25, 2023 — each of which expressly teaches identifying cloud resources that are present in the cloud but absent from the IaC (i.e., “unmanaged” resources) and generating IaC configuration code therefor. Both references predate the effective filing date of the present application (September 15, 2023) by at least four months. The rejection of claims 4, 5, 15, 16, 22, and 24 is set forth below in view of Lee, AAPA, Jourdan, and Terraformer.
Claim Objections
Claims 1, 4-12 and 15-25 are objected to because of the following informalities: Claim 1 (and similar for claims 11-12) recites the limitation “receiving a first list of cloud resources, wherein the first list includes current operational state of the cloud resources in the cloud infrastructure;” in lines 3-4. Claim 1 (and similar for claims 11-12) recites the limitation “performing a query of an infrastructure-as-code (laC) tool;” in line 5. Claim 1 (and similar for claims 11-12) recites the limitation “retrieving a second list of cloud resources managed by the laC tool based on the query, wherein the second list includes deployed states of managed cloud resources and deployed states corresponding to an initially specified operation baseline;” in lines 6-8. Claim 4 recites “comparing the cloud resources in the first list to the cloud resources in the second list;” in lines 2-3. Appropriate correction is required. Please amend the claim language s suggested in bold.
Dependent claims 5-10 and 15-25 do not overcome the deficiency of the base claim and, therefore, are objected for the same reasons as the base claim.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 6-12, 17-21, 23 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US Pub. No. 2023/0004431 – hereinafter Lee – previously presented) in view of Applicant’s Admitted Prior Art (AAPA) at the present application’s specification [0006]. With respect to claim 1, (currently amended) Lee teaches a method for correcting misaligned states of cloud resources in a cloud infrastructure, comprising: receiving a first list of cloud resources, wherein the first list includes current operational states of the cloud resources in the cloud infrastructure (See Lee paragraph [0029] (current state data 120 as input to remediation engine 140). See paragraph [0035], “Current state data 120 is configuration code that reflects the current state of an enterprise’s infrastructure in a format recognizable to the cloud provider that implements the enterprise’s infrastructure”. See paragraph [0039] (current state data 120 reflecting state of deployed infrastructure)). querying an infrastructure-as-code (laC) tool (See Lee paragraph [0029] (remediation engine 140 receives IAC 130 as input from the IaC tool). See paragraph [0042] (graph generator 146 reads IAC 130). Examiner notes: Under broadest reasonable interpretation, accessing/reading the IaC tool’s stored configuration data constitutes querying the IaC tool). retrieving a second list cloud resources managed by the laC tool based on the query, wherein the second list includes deployed states of managed cloud resources and deployed states corresponding to an initially specified operation baseline (See Lee paragraph [0006], “the desired infrastructure that is reflected in the (e.g., Terraform) IAC code that describes the desired infrastructure”. See paragraph [0018], “first infrastructure code that reflects a desired cloud infrastructure for an enterprise”. See paragraph [0024] (resource blocks within IaC, each representing a managed cloud resource). See paragraph [0029] and figure 1 (IAC 130 input to remediation engine; configuration graph 148 generated from IAC 130). See paragraph [0034] and figure 2 (configuration graph 148 nodes representing infrastructure items — modules, resources, and data sources). See paragraphs [0061]–[0063] (“Original Configuration Code” illustrating the initially specified baseline IaC). Examiner notes: Lee’s IAC 130 / configuration graph 148 (and not deployed state data 144) corresponds to the recited “second list” because IAC 130 is, by Lee’s express definition, the IaC code describing the desired/baseline infrastructure). comparing the current operational state with the deployed state for each cloud resource included in the first list and second list (See Lee paragraph [0018], “infrastructure items indicated in the deployed state data are matched to infrastructure items indicated in the directed graph”. See paragraph [0030] (claims propagator 150 takes configuration graph 148 and deployed state data 144 as inputs and updates configuration graph 148 with claims). See paragraph [0057], “Claims propagator 150 takes configuration graph 148 and deployed state data 144 as input and updates configuration graph 148 with one or more claims. A claim is … a temporary assignment of an attribute value from deployed state data 144 to an attribute of a node in configuration graph 148”). identifying a misaligned state for each cloud resource based on the comparison, wherein the misaligned state of the cloud resource is when the current operational state differs from the deployed state for the respective cloud resource (See Lee paragraph [0006], “‘Drift’ happens when desired infrastructure deviates from real infrastructure”. See paragraph [0018], “Based on differences between the two sets of infrastructure items, the directed graph is updated”. See paragraph [0057] (a claim is generated whenever an attribute value in deployed state data differs from the corresponding configuration graph node)). for each cloud resource with the identified misaligned state, generating a configuration code (See Lee paragraph [0018], “second infrastructure code is automatically generated that is different than the first infrastructure code”. See paragraph [0029] (output “updated IAC 160”). See paragraph [0096], “remediation engine 140 (or another component thereof) generates updated IAC 160 based on the updated version of configuration graph 148. For example, for each node in configuration graph 148, a configuration block is generated and included in IAC 160”). Lee teaches generating updated infrastructure configuration code based on detected drift but does not expressly teach the further step of “applying, via the IaC tool, the generated configuration code on each misaligned cloud resource, wherein, upon application of the generated configuration code, the current operational state matches the deployed state of the misaligned cloud resource.” Lee instead generates updated IAC 160 to reflect the actual cloud state. However, this gap is closed by Applicant’s admitted prior art (AAPA).
AAPA teaches applying, via the laC tool, the generated configuration code on each misaligned cloud resource, wherein, upon application of the generated configuration code, the current operational state matches the deployed state of the misaligned cloud resource (See present application’s specification paragraph [006], “Existing laC tools, such as Terraform may detect drifts in cloud resources and apply a fix on such resources. … existing laC tools merely override the current state of a drifted resource with the initially configured state”). Examiner notes: per MPEP 2129, statements in the specification characterizing what “existing” or “conventional” IaC tools do are admissions of prior art usable in obviousness rejections. The admitted operation — applying a fix that overrides the current cloud state with the initially configured/deployed state — is the operation recited in the trailing limitation of claim 1.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine Lee’s automated drift detection and automated configuration-code generation with the AAPA’s automated apply-baseline-to-cloud operation, yielding the recited method. The motivation to combine arises from Lee’s express goal of automating drift remediation (Lee paragraph [0019], “automatically remediating drift in infrastructure code”) and from Lee’s recognition (paragraph [0007]) that drift remediation “requires manual intervention by one or more human operators” when operating at scale. A person of ordinary skill in the art (POSITA) seeking to fully automate the drift-remediation workflow that Lee partially automates would naturally apply the AAPA’s well-known IaC-tool-based apply step downstream of Lee’s code-generation step. The combination is the routine application of two known techniques to yield the predictable result of fully automated drift correction. See MPEP § 2143(I)(A) (combining prior art elements according to known methods to yield predictable results). With respect to claim 6 (currently amended), Lee teaches identifying a platform associated with the cloud infrastructure (See Lee paragraph [0033], “Different cloud providers have different schemas”. See paragraph [0035], “Current state data 120 is configuration code that reflects the current state of an enterprise’s infrastructure in a format recognizable to the cloud provider”. See paragraph [0038], “Current state data of a cloud infrastructure may indicate the provider schema to which the current state data conforms. This information assists state generator 142 in identifying the correct provider schema data given the current state data”). determining a representation format compatible with the laC tool based on the laC tool and the identified platform (See Lee paragraph [0034] (“provider_schemas. registry.terraform.io/hashicorp/azurerm. resource_schemas” — schema is identified by both the IaC tool (Terraform) and the platform (Azure)). See paragraphs [0033], [0038] (selecting correct provider schema based on identified platform)). converting a representation format of the current operational state into the representation format compatible with the laC tool for the identified platform (See Lee paragraph [0032], “Provider schema data 110 is used to convert current state data 120 to an equivalent configuration code”. See paragraph [0040], “with information from provider schema data 110 (such as field type and structure), state generator 142 generates equivalent data structures from current state data 120 using a statically typed language”) and validating the converted representation format based on the representation format (See Lee paragraph [0032] (the conversion process includes “removing corresponding ‘computed’: ‘true’ fields in provider schema data 110 from current state data 120” — a schema-conformance validation that filters out non-conforming attributes). See paragraph [0040] (generation of “equivalent data structures” using a statically typed language inherently performs type validation against the provider schema)). With respect to claim 7 (currently amended), Lee teaches scanning the cloud infrastructure to identify cloud resources and their current operational configuration (See Lee paragraph [0035], “Current state data 120 is configuration code that reflects the current state of an enterprise’s infrastructure”. See paragraph [0036] (current state data describing actual cloud infrastructure). See paragraph [0038] (current state data reflecting different cloud infrastructure). Obtaining current state data that reflects the actual state of the cloud infrastructure necessarily involves scanning the cloud infrastructure). With respect to claim 8 (currently amended), mapping, for the managed cloud resources, between the configuration code to the deployed state managed by the laC tool; mapping, for the managed cloud resources, between the configuration code to the operational state as in the cloud infrastructure; and generating mapping information based on the mapped managed cloud resources, wherein the configuration code is further based on the mapping information (See Lee paragraph [0018], “infrastructure items indicated in the deployed state data are matched to infrastructure items indicated in the directed graph”. See paragraph [0056], “Configuration graph 200 allows for the translation from (a) evaluated resource values of tracked cloud instances to (2) code edits in (e.g., Terraform) configuration code. Claims propagation and claims resolution details a methodology through which evaluated resource values of tracked cloud instances are mapped to configuration code edits”. See paragraph [0057] (claims propagator 150 maps deployed state attribute values to configuration graph nodes). See paragraph [0096] (the configuration graph with mapped/propagated claims is the basis for generating updated IAC 160 — i.e., the configuration code is based on the mapping information). Examiner notes: Lee’s configuration graph 148 (with claims propagated to its nodes) constitutes the recited mapping information that links configuration code (graph nodes derived from IaC) to both deployed state (graph node attributes) and operational state (claims from deployed state data 144 reflecting actual cloud)). With respect to claim 9 (currently amended), Lee teaches analyzing code corresponding to the current operational state of the misaligned state of the cloud resource; identifying dependent cloud resources of the cloud resource with the misaligned state based on the analyzed code; and generating configuration code for each of the identified dependent cloud resource (See Lee paragraph [0018] (directed graph comprising nodes representing infrastructure items and edges connecting nodes). See paragraph [0029] (configuration graph 148 with edges connecting nodes representing dependencies); FIG. 2 (configuration graph 200 with edges between resource nodes). See paragraph [0057], “a claim pertaining to a reference is always propagated (since the node that is pointed to by the reference is closer to the user input) … if M3 node 270 is a matching node in configuration graph 200 … and an attribute value of a particular attribute in M3 node 270 is a reference, then edge 286 is followed to input variable 280, and then edge 284 is followed to module node 238” (traversing edges to identify dependent nodes). See paragraph [0096] (generating a configuration block for each node in configuration graph 148, including dependent nodes). Examiner notes: Lee’s configuration graph nodes correspond to cloud resources (each “resource” block represents a cloud resource per Lee paragraph [0024]), and Lee’s edges represent references/dependencies between resources. Traversal of these edges from a misaligned node (i.e., a node with a propagated claim) identifies dependent cloud resources of the misaligned resource, and Lee paragraph [0096] generates configuration code for each such dependent node). With respect to claim 10 (currently amended), Lee teaches converting the current operational state into an intermediate representation, wherein the intermediate representation includes language constructs of a declarative language utilized by the laC tool (See Lee paragraph [0004] (“declarative configuration language” such as HCL or JSON utilized by Terraform). See paragraphs [0029]–[0030] (state generator 142 converts current state data 120 into deployed state data 144). See paragraph [0040] (“state generator 142 generates equivalent data structures from current state data 120”). See paragraph [0042] (graph generator 146 generates configuration graph 148 from IAC 130). The configuration graph and deployed state data are intermediate representations that include constructs of the declarative IaC language) and
compiling the intermediate representation into the declarative language (See Lee paragraph [0096], “remediation engine 140 (or another component thereof) generates updated IAC 160 based on the updated version of configuration graph 148. For example, for each node in configuration graph 148, a configuration block is generated and included in IAC 160” — the configuration graph (intermediate representation) is compiled into updated IAC 160 (declarative language code)).
With respect to claim 11 (currently amended), the claim is directed to a non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process that corresponds to the method recited in claim 1. Lee teaches a non-transitory medium and processing circuitry (Lee paragraph [0017], [0098] (“Example Computer System”) and figure 6). The combination of Lee in view of AAPA teaches the corresponding process as set forth in the rejection of claim 1 above.
With respect to claim 12 (currently amended), the claim is directed to a system comprising a processing circuitry and a memory containing instructions, the instructions configuring the system to perform operations corresponding to those recited in claim 1. Lee teaches such a system (Lee paragraph [0029] and figure 1 (system 100 for automatically performing drift remediation). See paragraph [0098] and figure 6 (computer system with processor and memory)). The combination of Lee in view of AAPA teaches the corresponding system as set forth in the rejection of claim 1 above.
With respect to claims 17-21 (currently amended), the claims are directed to a system that corresponds to the method recited in claims 6-10 (see the rejection of claims 6-10 above). With respect to claim 23 (new), Lee teaches selecting a dictionary mapping based on the laC tool and the identified platform, wherein converting the representation format is further based on the selected dictionary mapping (See Lee paragraph [0032], “Provider schema data 110 includes schema data that defines what attributes can and cannot be part of configuration. Provider schema data 110 is used to convert current state data 120 to an equivalent configuration code”. See paragraph [0033], “Different cloud providers have different schemas. Thus, provider schema data 110 may contain multiple provider schemas”. See paragraph [0034] (provider schemas keyed by IaC tool and platform, e.g., “provider_schemas.registry.terraform.io/hashicorp/azurerm.resource_schemas”). See paragraph [0038] (selecting the correct provider schema based on the platform indicated by the current state data). See paragraph [0040] (using the selected provider schema to perform the conversion). Examiner notes: Lee’s provider schema data 110 — a schema-based mapping of attribute names to types/structures, organized by IaC tool and cloud platform — corresponds to the recited “dictionary mapping based on the IaC tool and the identified platform.”).
With respect to claim 25 (new), the claim is directed to a system that corresponds to the method recited in claim 23 (see the rejection of claim 23 above).
Claims 4, 15, 22 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US Pub. No. 2023/0004431 – hereinafter Lee – previously presented) in view of Applicant’s Admitted Prior Art (AAPA) at the present application’s specification [0006] and further in view of Jourdan, S. (“Detect infrastructure drift and unmanaged resources with Snyk IaC,” - Snyk Blog, May 9, 2022 – hereinafter Jourdan). With respect to claim 4 (currently amended), Lee in view of AAPA is silent to disclose, however in an analogous art, Jourdan teaches comparing the cloud resources in the first list to the cloud resource in the second list; and identifying a subset of unmanaged cloud resources based on the comparison, wherein the subset of unmanaged cloud resources are the cloud resources present on the first list and absent from the second list (See Jourdan page 2, “Snyk Infrastructure as Code (Snyk IaC) now detects all types of infrastructure drift and reports them as Terraform resources … This includes changes or deletions of ‘managed’ (resources actually deployed from IaC) and ‘unmanaged’ resources (those are the ones not yet under IaC control). Page 3, “having a complete list of unmanaged Terraform resources categorized by cloud service and resource type will make them very visible”. Page 4, “Snyk IaC will combine all the Terraform states you feed it into one big aggregated map, and compare it to what it finds on your AWS account. The difference are drifts, reported as Terraform resources”. Page 4, command output “snyk iac describe --only-unmanaged” listing five unmanaged resources by service (aws_iam, aws_s3) and resource type (aws_iam_policy_attachment, aws_iam_user, aws_iam_user_policy, aws_s3_bucket). Page 5, “There are two S3 buckets (type: aws_s3_bucket) that are not in Terraform, and we are given their names”). Examiner notes: Jourdan’s aggregated Terraform-states map (corresponding to the recited “second list”) compared against the AWS account inventory (corresponding to the recited “first list”), where the difference is reported as unmanaged resources, directly reads on the recited identification of resources present on the first list and absent from the second list.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the drift detection and remediation framework of Lee and AAPA with Jourdan’s identification of unmanaged cloud resources, because Jourdan expressly addresses the same problem identified in Applicant’s specification at paragraph [007]: namely, that conventional IaC tools fix only managed resources and leave unmanaged cloud resources unaccounted for. Jourdan addresses this gap by extending drift management to unmanaged resources to provide “complete visibility” (Jourdan page 2). The motivation to combine is expressly provided by Jourdan page 3: “Improve our code coverage so that code can be analyzed for misconfigurations pre-deployment” and “Take immediate action, like delete the resource or revert the change before damage can be done.” See MPEP § 2143(I)(A) (combining prior art elements according to known methods to yield predictable results).
With respect to claim 15 (currently amended), the claim is directed to a system that corresponds to the method recited in claim 4 (see the rejection of claim 4 above). With respect to claim 22 (new), Lee in view of AAPA is silent to disclose, however in an analogous art, Jourdan teaches including the subset of unmanaged cloud resources with the cloud resources with the misaligned state (See Jourdan page 2 (Snyk IaC “detects all types of infrastructure drift and reports them as Terraform resources … includes changes or deletions of ‘managed’ … and ‘unmanaged’ resources” — unified reporting of both managed-drift and unmanaged resources in a single output). Pages 5–6 (combined report showing both “Changed Resources” (corresponding to misaligned managed resources) and “Missing Resources” / unmanaged resources within the same Test Summary)). Examiner notes: Jourdan’s unified reporting of misaligned-managed and unmanaged resources in the same drift report directly teaches the recited inclusion. The combination is the routine combination of Jourdan’s unified reporting with Lee/AAPA’s misaligned-resource detection, yielding the predictable result of unified drift remediation across both managed and unmanaged resources. See MPEP § 2143(I)(A).
With respect to claim 24 (new), the claim is directed to a system that corresponds to the method recited in claim 22 (see the rejection of claim 22 above).
Claims 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US Pub. No. 2023/0004431 – hereinafter Lee – previously presented) in view of Applicant’s Admitted Prior Art (AAPA) at the present application’s specification [0006] in view of Jourdan, S. (“Detect infrastructure drift and unmanaged resources with Snyk IaC,” - Snyk Blog, May 9, 2022 – hereinafter Jourdan) and further in view of GoogleCloudPlatform/terraformer – hereinafter Terraformer, archived at the Internet Archive Wayback Machine on May 25, 2023). With respect to claim 5 (currently amended), Lee in view of AAPA is silent to disclose, however in an analogous art, the combination of Jourdan and Terraformer teaches generating the configuration code for the subset of unmanaged cloud resources; and saving the generated configuration code in a code repository associated with the laC tool (See Terraformer README at page 1, “CLI tool to generate terraform files from existing infrastructure (reverse Terraform). Infrastructure to Code”. Page 1, “A CLI tool that generates tf / json and tfstate files based on existing infrastructure (reverse Terraform)”. Page 4 (Capabilities), item 1: “Generate tf / json + tfstate files from existing infrastructure for all supported objects by resource”; item 2: “Remote state can be uploaded to a GCS bucket”; item 4: “Save tf / json files using a custom folder tree pattern”. Page 4 (Demo GCP), demonstrating output of generated Terraform configuration files (compute_firewall.tf, outputs.tf, provider.tf, terraform.tfstate, variables.tf) saved to a structured directory). Examiner notes: Terraformer’s generation of Terraform configuration code from existing infrastructure (i.e., from cloud resources that are not yet under IaC control — the “unmanaged” resources of Jourdan) and saving such generated code to a structured directory or remote bucket directly reads on the recited generating-and-saving operation. Saving the generated code in a code repository associated with the IaC tool is further taught by Jourdan page 6 (Snyk IaC integration into pipelines and recurring checks).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to apply Terraformer’s reverse-Terraform code-generation capability to the subset of unmanaged cloud resources identified by Jourdan in the combination of Lee, AAPA, and Jourdan, because doing so brings the unmanaged resources under IaC control — the express objective of both Jourdan (page 3, “Improve our code coverage”) and Applicant’s specification (paragraph [007], identifying the limitation that existing IaC tools “fix only managed resources” as a problem the present invention addresses). The combination is the routine application of Terraformer’s known reverse-Terraform technique to the unmanaged-resource subset identified by Jourdan, yielding the predictable result of automated codification of unmanaged cloud resources. See MPEP § 2143(I)(A).
With respect to claim 16 (currently amended), the claim is directed to a system that corresponds to the method recited in claim 5 (see the rejection of claim 5 above).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6: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, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights