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
This action is in response to communication filed on 3/26/2026.
Claims 1, 3-12 and 14-23 are pending.
Claims 1, 3-12 and 14-23 have been amended.
Claims 2 and 13 have been canceled.
Claims 22 and 23 have been added.
Response to Arguments
Applicant’s argument(s) filed on 3/26/2026 with respect to claim(s) 1, 3-12 and 14-23 have been considered but are moot in view of the new ground(s) of rejection.
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 of this title, 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.
1. Claim(s) 1, 3-12 and 14-23 are rejected under 35 U.S.C. 103 as being unpatentable over HERZBERG (US 20230161869 A1) in view of Devarakonda (US 20250060984 A1) in view of Kavadimatti (US 20210028993 A1).
With respect to independent claims:
Regarding claim(s) 1, a method for recovering resources of a cloud computing environment to a pre-drift configuration, comprising:
HERZBERG teaches generating a plurality of first Infrastructure as Code (laC) configuration code objects at a first time, (HERZBERG, [0006] Further complicating matters is deployment of cloud environments utilizing infrastructure as code (IaC) systems. [0011] Certain embodiments disclosed herein also include a non-transitory computer readable medium having stored thereon causing a processing circuitry to execute a process, the process comprising detecting in a configuration code a plurality of code objects, each of the plurality of code objects corresponding to an instance deployed in a cloud computing environment; [0023] The deployed environment, also known as a production environment, differs over time from the initial deployment configuration, due for example to upgrades and patches implemented in production but not always updated in configuration code. [examiner notes: the time of the initial deployment configuration interprets to be the first time.]) each first code object including configuration code for an laC platform of a plurality of laC platforms and generated based on configuration data of a resource of a plurality of cloud infrastructure resources deployed in a cloud computing environment, (HERZBERG, [0006] Further complicating matters is deployment of cloud environments utilizing infrastructure as code (IaC) systems. [0056], FIG.2; at S210, configuration code is received. In an embodiment, the configuration code includes a plurality of code objects. In certain embodiments, a portion of the code objects correspond to instances which are deployed in a cloud computing environment. In an embodiment, the configuration code is scanned or otherwise inspected as a textual object. For example, a configuration code is searched for regular expressions (regex), strings, and the like. [0057] At S220, a first code object is extracted from the received code. Extracting a code object includes, in an embodiment, searching the text of a configuration code file for a predetermined string. For example, a code object may be a text field identifying a type of workload, a name of a workload, a network address, a name in a namespace, a role, a permission, and the like. In some embodiments, a plurality of code objects are extracted from the received code.)
HERZBERG does not teach wherein each cloud infrastructure resource is managed by an laC platform of the plurality of laC platforms; assigning to each first laC configuration code object of the first-plurality of first laC configuration code objects a timestamp corresponding to the first time; detecting at a second time configuration data of the cloud infrastructure resource; detecting a configuration drift based on a comparison between a first laC configuration code object, corresponding to the cloud infrastructure resource, and the configuration data detected at the second time; and generating a deployment plan of the cloud infrastructure resource to a pre-drift configuration in the cloud computing environment based on the first laC configuration code object.
Devarakonda however in the same field of computer networking teaches wherein each cloud infrastructure resource is managed by an laC platform of the plurality of laC platforms; (Devarakonda, [0030] The current application is directed to an IaC cloud-infrastructure-management service or system. In a first subsection, below, a detailed description of computer hardware, complex computational systems, and virtualization is provided with reference to FIGS. 1-7. In a second subsection, an overview of IaC cloud-infrastructure management is provided, with reference to FIGS. 8-11.)
assigning to each first laC configuration code object of the first-plurality of first laC configuration code objects a timestamp corresponding to the first time; (Devarakonda, [005] The current document is directed to an infrastructure-as-code (“IaC”) cloud-infrastructure-management service or system that allows users and upstream management systems to define and deploy infrastructure, such as virtual networks, virtual machines, load balancers, and connection topologies, within cloud-computing systems. [0083] FIG. 21C shows several relational-database tables that represent one implementation of database-stored enforced-state-management information used by the currently disclosed improved Idem service for persisting enforced-state-management information. The fields of the entries in the Resource States table include: (1) resource_ID 2172, a resourceID that uniquely identifies a resource; (2) enforced_state_ID 2174, the enforced_state_ID that identifies the enforced-state-management information; (3) enforced_state_version 2176, the enforced-state-version number of the enforced-state-management information represented by a row in the Resource States table; (4) previous_state 1578, an instance of the resource_state datatype that represents the most recent previous state of the resource; (5) current_state 1580, the current state of the resource; (6) SLS_archive_ID 1582, an identifier for the SLS data files that include the specification of the resource; (7) initial_timestamp 1584, the first timestamp associated with the deployment and configuration of the resource; and (8) current_timestamp 1586, a timestamp associated with the most recent state command or enforce request associated with the resource. The broken columns 1572 and 1574 in the Enforcement and Resource States tables indicate that additional fields may be included in various implementations. [0104] FIG. 25B shows execution details for state commands that represent requests for a new deployment and configuration. [examiner notes: initial_timestamp 1584 interprets to be the timestamp corresponding to the first time. A resource States table interpret to be configuration code objects.])
detecting at a second time configuration data of the cloud infrastructure resource;
(Devarakonda, [0005] The current document is directed to an infrastructure-as-code (“IaC”) cloud-infrastructure-management service or system that allows users and upstream management systems to define and deploy infrastructure, such as virtual networks, virtual machines, load balancers, and connection topologies, within cloud-computing systems. [0083] FIG. 21C shows several relational-database tables that represent one implementation of database-stored enforced-state-management information used by the currently disclosed improved Idem service for persisting enforced-state-management information. The fields of the entries in the Resource States table include: (1) resource_ID 2172, a resourceID that uniquely identifies a resource; (2) enforced_state_ID 2174, the enforced_state_ID that identifies the enforced-state-management information; (3) enforced_state_version 2176, the enforced-state-version number of the enforced-state-management information represented by a row in the Resource States table; (4) previous_state 1578, an instance of the resource_state datatype that represents the most recent previous state of the resource; (5) current_state 1580, the current state of the resource; (6) SLS_archive_ID 1582, an identifier for the SLS data files that include the specification of the resource; (7) initial_timestamp 1584, the first timestamp associated with the deployment and configuration of the resource; and (8) current_timestamp 1586, a timestamp associated with the most recent state command or enforce request associated with the resource. The broken columns 1572 and 1574 in the Enforcement and Resource States tables indicate that additional fields may be included in various implementations. [0104] FIG. 25B shows execution details for state commands that represent requests for a new deployment and configuration. [examiner notes: current_timestamp 1586 interprets to be the second time.])
and the configuration data detected at the second time; and (Devarakonda, [0083] FIG. 21C shows several relational-database tables that represent one implementation of database-stored enforced-state-management information used by the currently disclosed improved Idem service for persisting enforced-state-management information.; (5) current_state 1580, the current state of the resource; (6) SLS_archive_ID 1582, an identifier for the SLS data files that include the specification of the resource; (7) initial_timestamp 1584, the first timestamp associated with the deployment and configuration of the resource; and (8) current_timestamp 1586, a timestamp associated with the most recent state command or enforce request associated with the resource. The broken columns 1572 and 1574 in the Enforcement and Resource States tables indicate that additional fields may be included in various implementations. [0104] FIG. 25B shows execution details for state commands that represent requests for a new deployment and configuration. [examiner notes: current_timestamp 1586 interprets to be the second time.])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify HERZBERG by incorporating the teachings of Devarakonda. The motivation/suggestion would have been because there is a need to provide distributed-computer-systems and, in particular, to an infrastructure-as-code (“IaC”) cloud-infrastructure-management service or system that allows users and upstream applications to define and deploy cloud-based infrastructure, such as virtual networks, virtual machines, load balancers, and connection topologies (Devarakonda, [0002]).
HERZBERG does not teach detecting a configuration drift based on a comparison between a first laC configuration code object, corresponding to the cloud infrastructure resource, generating a deployment plan of the cloud infrastructure resource to a pre-drift configuration in the cloud computing environment based on the first laC configuration code object.
Kavadimatti however in the same field of computer networking teaches detecting a configuration drift based on a comparison between a first laC configuration code object, corresponding to the cloud infrastructure resource, (Kavadimatti, [0109] Example 6 includes the apparatus of example 5, wherein the drift determiner determines the drift value by comparing first properties of the first set of vertices with second properties of the second set of vertices, and determining a difference between a first degree of the first set of edges and a second degree of the second set of edges.
[0046] C=(V c ,E c) Equation 1
[0047] In Equation 1 above, the variable C represents the blueprint model 126, the variable VC represents a set of vertices of resources in the blueprint 106, and the variable EC represents a set of edges of the relationships between the resources in the blueprint 106. In addition, the example drift determiner 206 determines the inventory model 128 for the identified resource based on the identified resource and the corresponding relationships as included in the deployment 132 based on Equation 2 below.
I=(V i ,E i) Equation 2
[0050] The resource drift determiner 206 may determine a plurality of blueprint models 126 for each individual resource or, the resource drift determiner 206 may determine a single blueprint model 126 for all the identified resources, combined.)
generating a deployment plan of the cloud infrastructure resource to a pre-drift configuration in the cloud computing environment based on the first laC configuration code object. (Kavadimatti, [0024] Deployments of an infrastructure using an IaC process may encounter drift. As used herein, drift is defined as the deviation of the real-world state of an infrastructure from the state defined in the configuration (e.g., the blueprint). [0028] Drift detection may be provided at the deployment level or at the individual resource level. In examples disclosed herein, drift detection may be triggered by a user of the deployment or a user of the resource. Further, examples disclosed herein include providing the report and determining whether the resource(s) and/or deployment is to be synchronized back to the original blueprint. For example, a user (e.g., a data center administrator or a cloud administrator) may choose, in response to obtaining a drift report indicating a drift value, to synchronize the resource(s) and/or deployment with the original blueprint. As such, examples disclosed herein may re-apply the blueprint to the resource(s) and/or deployment. Additionally or alternatively, the blueprint may be updated to match the resource(s) and/or deployment. [examiner notes: the original blueprint interprets to be the pre-drift configuration.])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify HERZBERG by incorporating the teachings of Kavadimatti. The motivation/suggestion would have been because there is a need to detect drift in a hybrid cloud environment (Kavadimatti, [0002]).
Claim(s) 11 and 12 is/are substantially similar to claim 1, and is thus rejected under substantially the same rationale.
With respect to dependent claims:
Regarding claim(s) 3, the method of claim 1,
HERZBERG-Devarakonda-Kavadimatti teach further comprising: generating an laC configuration code object for each unique cloud infrastructure resource of the plurality of cloud infrastructure resources, wherein each laC configuration code object is included in the plurality of first laC configuration code objects. (HERZBERG, [0056] At S210, configuration code is received. In an embodiment, the configuration code includes a plurality of code objects. In certain embodiments, a portion of the code objects correspond to instances which are deployed in a cloud computing environment.)
Regarding claim(s) 4, the method of claim 1,
HERZBERG-Devarakonda-Kavadimatti teach further comprising: encoding a plurality of resource values into the plurality of laC configuration code objects, wherein each resource value indicates a configuration of a respective cloud infrastructure resource of the plurality of cloud infrastructure resources. (HERZBERG, [0056] At S210, configuration code is received. In an embodiment, the configuration code includes a plurality of code objects. In certain embodiments, a portion of the code objects correspond to instances which are deployed in a cloud computing environment. [0058] At S230, a security graph is traversed to detect a node in the graph corresponding to the extracted first code object. In an embodiment, traversing the security graph includes sending a request through an API of a graph database hosting the security graph to search the graph for a string, a value, and the like, which corresponds to the first code object.)
Regarding claim(s) 5, the method of claim 1,
HERZBERG-Devarakonda-Kavadimatti teach further comprising: determining expected resource values that represent an expected resource configuration for the cloud computing environment. (Kavadimatti, [0024] Deployments of an infrastructure using an IaC process may encounter drift. As used herein, drift is defined as the deviation of the real-world state of an infrastructure from the state defined in the configuration (e.g., the blueprint). A drift value in a deployment may occur when one or more resources defined in a blueprint are not actually instantiated have been terminated and/or have failed (e.g., broken, etc.))
The same motivation to combine as the independent claim 1 applies here.
Regarding claim(s) 6, the method of claim 5,
HERZBERG-Devarakonda-Kavadimatti teach further comprising: comparing a resource value encoded in a second laC configuration code object with an expected resource value encoded in the first laC configuration code object to detect the configuration drift. (Kavadimatti, [0024] Deployments of an infrastructure using an IaC process may encounter drift. As used herein, drift is defined as the deviation of the real-world state of an infrastructure from the state defined in the configuration (e.g., the blueprint). A drift value in a deployment may occur when one or more resources defined in a blueprint are not actually instantiated have been terminated and/or have failed (e.g., broken, etc.))
The same motivation to combine as the independent claim 1 applies here.
Regarding claim(s) 7, the method of claim 1,
HERZBERG-Devarakonda-Kavadimatti teach further comprising: generating declaration code based on the detected configuration drift, wherein the declaration code is compatible with an Infrastructure as Code (laC) platform; and (Kavadimatti, [0023] Utilizing an IaC process enables the ability to safely predict and/or otherwise manage the lifecycle of the infrastructure using declarative code. [0027] Examples disclosed herein provide drift detection ability for deployments to detect a drift associated with a resource in which alterations (e.g., infrastructure changes, resource changes, configuration changes, etc.) have been made outside of a cloud-based provisioning service (e.g., VMware Cloud Assembly). Once drift detection of a resource is complete, examples disclosed herein include generating a report showing the result of the drift detection. For example, if a resource in a deployment and/or infrastructure is altered, the report includes a representation of the deviation (e.g., drift) from the blueprint. The drift representation may be numeric and/or may be text-based to quantify an amount of different or drift between a blueprint-defined resource and the actual state of that resource in a deployment. Further, the example report may be created and/or otherwise generated for each resource that has deviated, along with information of properties of the resource(s) that do not match the expected values (e.g., the properties set forth in the blueprint). In such an example, a user (e.g., a data center administrator or a cloud administrator) may obtain such a report and take corrective actions on the resource(s) and/or deployment(s). Example corrective actions include synchronizing the resources and/or deployments with blueprint definitions. Such synchronization may involve updating a blueprint to reflect resource states of the actual deployment. Additionally or alternatively, such synchronization may involve updating portions of the deployment to match the blueprint.)
triggering deployment of resources to a pre-drift configuration by sending an instruction to an orchestrator of the Infrastructure as Code (laC) platform, wherein the instruction includes the generated declaration code and indicates that a configuration drift is detected. (Kavadimatti, [0021] In a virtual infrastructure, such as a multi-cloud management platform, an endpoint (e.g., a cloud) is a system and/or a service on which a user can provision resources. The endpoint may be a public cloud resource (e.g., a web service such as Amazon Web Services (AWS), etc), a virtual appliance (e.g., an external orchestrator appliance, etc.), a private cloud (e.g., hosted by VMware vSphere™, Microsoft Hyper-V™, etc.), etc. [0023] Utilizing an IaC process enables the ability to safely predict and/or otherwise manage the lifecycle of the infrastructure using declarative code. [0027] Examples disclosed herein provide drift detection ability for deployments to detect a drift associated with a resource in which alterations (e.g., infrastructure changes, resource changes, configuration changes, etc.) have been made outside of a cloud-based provisioning service (e.g., VMware Cloud Assembly). Once drift detection of a resource is complete, examples disclosed herein include generating a report showing the result of the drift detection. For example, if a resource in a deployment and/or infrastructure is altered, the report includes a representation of the deviation (e.g., drift) from the blueprint. The drift representation may be numeric and/or may be text-based to quantify an amount of different or drift between a blueprint-defined resource and the actual state of that resource in a deployment. Further, the example report may be created and/or otherwise generated for each resource that has deviated, along with information of properties of the resource(s) that do not match the expected values (e.g., the properties set forth in the blueprint). In such an example, a user (e.g., a data center administrator or a cloud administrator) may obtain such a report and take corrective actions on the resource(s) and/or deployment(s). Example corrective actions include synchronizing the resources and/or deployments with blueprint definitions. Such synchronization may involve updating a blueprint to reflect resource states of the actual deployment. Additionally or alternatively, such synchronization may involve updating portions of the deployment to match the blueprint.)
The same motivation to combine as the independent claim 1 applies here.
Regarding claim(s) 8, the method of claim 1,
HERZBERG-Devarakonda-Kavadimatti teach further comprising: detecting a configuration drift if a resource value from an laC configuration code of the first plurality of laC configuration code object differs from the expected resource value. (Kavadimatti, [0024] Deployments of an infrastructure using an IaC process may encounter drift. As used herein, drift is defined as the deviation of the real-world state of an infrastructure from the state defined in the configuration (e.g., the blueprint). A drift value in a deployment may occur when one or more resources defined in a blueprint are not actually instantiated have been terminated and/or have failed (e.g., broken, etc.))
The same motivation to combine as the independent claim 1 applies here.
Regarding claim(s) 9, the method of claim 1,
HERZBERG-Devarakonda-Kavadimatti teach further comprising: utilizing metadata to associate a subset of laC configuration code objects of the plurality of first laC configuration code objects with the timestamp. (Devarakonda, [005] The current document is directed to an infrastructure-as-code (“IaC”) cloud-infrastructure-management service or system that allows users and upstream management systems to define and deploy infrastructure, such as virtual networks, virtual machines, load balancers, and connection topologies, within cloud-computing systems. [0083] FIG. 21C shows several relational-database tables that represent one implementation of database-stored enforced-state-management information used by the currently disclosed improved Idem service for persisting enforced-state-management information. The fields of the entries in the Resource States table include: (1) resource_ID 2172, a resourceID that uniquely identifies a resource; (2) enforced_state_ID 2174, the enforced_state_ID that identifies the enforced-state-management information; (3) enforced_state_version 2176, the enforced-state-version number of the enforced-state-management information represented by a row in the Resource States table; (4) previous_state 1578, an instance of the resource_state datatype that represents the most recent previous state of the resource; (5) current_state 1580, the current state of the resource; (6) SLS_archive_ID 1582, an identifier for the SLS data files that include the specification of the resource; (7) initial_timestamp 1584, the first timestamp associated with the deployment and configuration of the resource; and (8) current_timestamp 1586, a timestamp associated with the most recent state command or enforce request associated with the resource. The broken columns 1572 and 1574 in the Enforcement and Resource States tables indicate that additional fields may be included in various implementations. [0104] FIG. 25B shows execution details for state commands that represent requests for a new deployment and configuration. [examiner notes: initial_timestamp 1584 interprets to be the timestamp corresponding to the first time. A resource States table interpret to be configuration code objects.)
The same motivation to combine as the independent claim 1 applies here.
Regarding claim(s) 10, the method of claim 1,
HERZBERG-Devarakonda-Kavadimatti teach further comprising: generating a plurality of second laC configuration code objects at the second time, each second laC configuration code object of the plurality of second laC configuration code objects generated based on configuration data of a cloud infrastructure resource of the plurality of cloud infrastructure resources; (HERZBERG, [0006] Further complicating matters is deployment of cloud environments utilizing infrastructure as code (IaC) systems. [0056], FIG.2; at S210, configuration code is received. In an embodiment, the configuration code includes a plurality of code objects. In certain embodiments, a portion of the code objects correspond to instances which are deployed in a cloud computing environment. In an embodiment, the configuration code is scanned or otherwise inspected as a textual object. For example, a configuration code is searched for regular expressions (regex), strings, and the like. [0057] At S220, a first code object is extracted from the received code. Extracting a code object includes, in an embodiment, searching the text of a configuration code file for a predetermined string. For example, a code object may be a text field identifying a type of workload, a name of a workload, a network address, a name in a namespace, a role, a permission, and the like. In some embodiments, a plurality of code objects are extracted from the received code.)
detecting the configuration drift based on a comparison between a first laC configuration code object, and a second laC configuration code object; and (Kavadimatti, [0024] Deployments of an infrastructure using an IaC process may encounter drift. As used herein, drift is defined as the deviation of the real-world state of an infrastructure from the state defined in the configuration (e.g., the blueprint). A drift value in a deployment may occur when one or more resources defined in a blueprint are not actually instantiated have been terminated and/or have failed (e.g., broken, etc.))
generating the deployment plan to the pre-drift configuration based on the detected configuration drift and the first laC configuration code object. (Kavadimatti, [0027] Example corrective actions include synchronizing the resources and/or deployments with blueprint definitions. Such synchronization may involve updating a blueprint to reflect resource states of the actual deployment. Additionally or alternatively, such synchronization may involve updating portions of the deployment to match the blueprint.)
The same motivation to combine as the independent claim 1 applies here.
Regarding claim(s) 22, the method of claim 1,
HERZBERG-Devarakonda-Kavadimatti teach wherein the configuration data includes an laC status, the laC status indicating whether the respective cloud infrastructure of the plurality of cloud infrastructure resources is actively managed or controlled by the laC platform. (Devarakonda, [0005] The current document is directed to an infrastructure-as-code (“IaC”) cloud-infrastructure-management service or system that allows users and upstream management systems to define and deploy infrastructure, such as virtual networks, virtual machines, load balancers, and connection topologies, within cloud-computing systems. The IaC cloud-infrastructure-management service or system includes a service frontend, a task manager, an event-processing component, and multiple Idem-service workers. The task manager manages execution of commands and requests received from the service frontend, using multiple queues, provides for prioritization of command-and-request execution by the multiple Idem-service workers, and provides for preemption of long-running executing commands and requests. The IaC cloud-infrastructure-management service or system enforces specified states of the cloud infrastructure using enforced-state identifiers and enforced-state versions supplied in state commands and enforce requests. [0030] The current application is directed to an IaC cloud-infrastructure-management service or system. In a first subsection, below, a detailed description of computer hardware, complex computational systems, and virtualization is provided with reference to FIGS. 1-7. In a second subsection, an overview of IaC cloud-infrastructure management is provided, with reference to FIGS. 8-11. [0051] FIG. 11 illustrates the cloud-management interface provided by the currently discussed IaC cloud-infrastructure-management service or system. The cloud-management interface 902 includes four different GraphQL application programming interfaces (“APIs”): (1) Submit Task 1102, through which deployment-and-configuration commands are input to the IaC cloud-infrastructure-management service or system; (2) Query Task 1103, through which status queries for previously submitted deployment-and-configuration commands and requests are input to the IaC cloud-infrastructure-management service or system; ()
The same motivation to combine as the independent claim 1 applies here.
Regarding claim(s) 23, the method of claim 7,
HERZBERG-Devarakonda-Kavadimatti teach further comprising: integrating the generated declaration into an laC configuration file. (Kavadimatti, [0021] In a virtual infrastructure, such as a multi-cloud management platform, an endpoint (e.g., a cloud) is a system and/or a service on which a user can provision resources. The endpoint may be a public cloud resource (e.g., a web service such as Amazon Web Services (AWS), etc), a virtual appliance (e.g., an external orchestrator appliance, etc.), a private cloud (e.g., hosted by VMware vSphere™, Microsoft Hyper-V™, etc.), etc. [0023] Utilizing an IaC process enables the ability to safely predict and/or otherwise manage the lifecycle of the infrastructure using declarative code. [0027] Examples disclosed herein provide drift detection ability for deployments to detect a drift associated with a resource in which alterations (e.g., infrastructure changes, resource changes, configuration changes, etc.) have been made outside of a cloud-based provisioning service (e.g., VMware Cloud Assembly). Once drift detection of a resource is complete, examples disclosed herein include generating a report showing the result of the drift detection. For example, if a resource in a deployment and/or infrastructure is altered, the report includes a representation of the deviation (e.g., drift) from the blueprint. The drift representation may be numeric and/or may be text-based to quantify an amount of different or drift between a blueprint-defined resource and the actual state of that resource in a deployment. Further, the example report may be created and/or otherwise generated for each resource that has deviated, along with information of properties of the resource(s) that do not match the expected values (e.g., the properties set forth in the blueprint). In such an example, a user (e.g., a data center administrator or a cloud administrator) may obtain such a report and take corrective actions on the resource(s) and/or deployment(s). Example corrective actions include synchronizing the resources and/or deployments with blueprint definitions. Such synchronization may involve updating a blueprint to reflect resource states of the actual deployment. Additionally or alternatively, such synchronization may involve updating portions of the deployment to match the blueprint.)
The same motivation to combine as the independent claim 1 applies here.
Claim(s) 13 is/are substantially similar to claim 2, and is thus rejected under substantially the same rationale.
Claim(s) 14 is/are substantially similar to claim 3, and is thus rejected under substantially the same rationale.
Claim(s) 15 is/are substantially similar to claim 4, and is thus rejected under substantially the same rationale.
Claim(s) 16 is/are substantially similar to claim 5, and is thus rejected under substantially the same rationale.
Claim(s) 17 is/are substantially similar to claim 6, and is thus rejected under substantially the same rationale.
Claim(s) 18 is/are substantially similar to claim 7, and is thus rejected under substantially the same rationale.
Claim(s) 19 is/are substantially similar to claim 8, and is thus rejected under substantially the same rationale.
Claim(s) 20 is/are substantially similar to claim 9, and is thus rejected under substantially the same rationale.
Claim(s) 21 is/are substantially similar to claim 10, and is thus rejected under substantially the same rationale.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WUJI CHEN whose telephone number is (571)270-0365. The examiner can normally be reached on 9am-6pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, VIVEK SRIVASTAVA can be reached on (571) 272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WUJI CHEN/
Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449
Prosecution Insights