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
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-6,8,10-13,15,17-20,23-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190065323 A1 (Dhamdhere) in view of US 20210014333 A1 (Singh).
Regarding claim 1, Dhamdhere teaches,
A method comprising:
storing in a memory, (par 32 - teaches an application instance request object specifying collecting deployment configuration files, pre- and post-snapshot scripts for containers, and a snapshot order in an application instance object) setup data specifying that each action of a set of actions is to be performed with respect to a corresponding container of a set of components upon receipt of a manual snapshot command with respect to a first component of a user application hosted on a cloud infrastructure;(par 43 - teaches that an application instance object instance may specify pre- and post-snapshot script(s) to run in container(s), as well as an order in which a snapshot should be taken; par 18 – teaches how the application instance object contains configuration information that includes components of the application such as services of the application ( for example, a number of services running in different containers), and other deployment details. The configuration information also includes user defined pre- and post-snapshot scripts to run in container(s) prior to and after taking an application consistent snapshot, respectively, and/or an order in which to take such a snapshot, among other things. par 18 “Particular configuration information specified by application instance object 112 and/or the configuration files may include components of the application such as services of the application ( e.g., a containerized application can include a number of services running in different containers), persistent data volumes, a deployment location such as a container pod, and so on.”)
wherein the user application comprises a plurality of components including the set of components and the first component, wherein the setup data also specifies, for each component of the set of components;( par 18 “Particular configuration information specified by application instance object 112 and/or the configuration files may include components of the application such as services of the application ( e.g., a containerized application can include a number of services running in different containers), persistent data volumes, a deployment location such as a container pod, and so on.”; par 18 – teaches how the application instance object contains configuration information that includes components of the application such as services of the application ( for example, a number of services running in different containers), and other deployment details. The configuration information also includes user defined pre- and post-snapshot scripts to run in container(s) prior to and after taking an application consistent snapshot, respectively, and/or an order in which to take such a snapshot, among other things. par 65 – teaches how each virtual machine in the system includes a guest operating system which supports the applications and services running in each virtual machine.)
receiving, by a management server, after the storing of the setup data, the manual snapshot command to capture a current state of the first component;(par 38 - teaches receiving a user-requested application snapshot through a Kubernetes resource object)
upon receipt of the manual snapshot command for the first component:(fig 4:410; par 38 – teaches step 410 where the container cluster service 120 receives a request to create a snapshot of the application instance. The request could be from a user requesting the creation of an application instance snapshot by creating a resource object, such as a Kubemetes object, that requests the snapshot of a particular application instance.)
inspecting, by the management server, the setup data in said memory to identify the set of actions to be performed, (fig 4:440,450; par 42 - teaches parsing stored application configuration to identify data volumes to snapshot) each container of the set of components with respect to which each action of the set of actions is to be performed, the component hosted on a container, (par 14 - teaches performing the snapshot in a specified order and executing specified pre- and post-snapshot scripts as part of the snapshot operation; par 18 - teaches customizable pre- and post-snapshot scripts for containers and an order for processing application services during the snapshot),
wherein said setup data indicates that a first action of the set of actions is to be performed with respect to the first component hosted on a first virtual machine of the plurality of virtual machines, and that a second action of the set of actions is to be performed with respect to a second container containing the second component, both of said first component and said second component being of the set of components, the first component being different from the second component; (par 14 - teaches performing the snapshot in a specified order and executing specified pre- and post-snapshot scripts as part of the snapshot operation; par 18 - teaches customizable pre- and post-snapshot scripts for containers and an order for processing application services during the snapshot)
capturing, by the management server, the current state of the first component by executing a set of copy actions(fig 4:460; par 44 - teaches connecting to the application cluster and taking snapshots of the identified application data volumes) to store data representing the current state to a non-volatile storage(par 23 - teaches copying an application snapshot object and snapshot volume between clusters and storage systems); and
performing, by the management server, the set of actions in addition to the set of copy actions for capturing the current state of the first component(fig 4:460; par 44 - teaches connecting to the application cluster and taking snapshots of the identified application data volumes; par 14 - teaches performing the snapshot in a specified order and executing specified pre- and post-snapshot scripts as part of the snapshot operation; par 18 - teaches customizable pre- and post-snapshot scripts for containers and an order for processing application services during the snapshot), wherein the management server performs the first action with respect to the first component hosted on the first virtual machine, and performs the second action with respect to the second component hosted on the second virtual machine.( fig 4:450; par 43 - teaches running pre-snapshot scripts specified in an application instance object. The application instance object corresponding to an application instance may specify multiple pre- and post-snapshot script(s) to run in multiple container(s), as well as an order in which a snapshot should be taken. par 18 “Particular configuration information specified by application instance object 112 and/or the configuration files may include components of the application such as services of the application ( e.g., a containerized application can include a number of services running in different containers), persistent data volumes, a deployment location such as a container pod, and so on.”; par 18 – teaches how the application instance object contains configuration information that includes components of the application such as services of the application ( for example, a number of services running in different containers), and other deployment details. The configuration information also includes user defined pre- and post-snapshot scripts to run in container(s) prior to and after taking an application consistent snapshot, respectively, and/or an order in which to take such a snapshot, among other things. par 65 – teaches how each virtual machine in the system includes a guest operating system which supports the applications and services running in each virtual machine.)
However, although Dhamdhere teaches pre- and post-snapshot scripts executed with respect to containers corresponding to application services, Dhamdhere does not expressly disclose setup data that separately identifies each application component, the action to be performed on that component, and the particular virtual machine hosting that component, outlined in limitations “a respective virtual machine of a plurality of virtual machines hosting the component in the cloud infrastructure”, and “the virtual machine on which the component is hosted,”, “and the virtual machine on which the component is hosted, wherein said setup data indicates that a first action of the set of actions is to be performed with respect to the first component hosted on a first virtual machine of the plurality of virtual machines, and that a second action of the set of actions is to be performed with respect to a second component hosted on a second virtual machine of the plurality of virtual machines, both of said first component and said second component being of the set of components”.
On the other hand, Singh teaches,
storing in a memory, setup data specifying that each action of a set of actions is to be performed with respect to a corresponding component of a set of components(par 80 – teaches specifying the name of an external script/runbook to the executed for installation of the package and/or service. Par 85 – teaches using external scripts/runbooks specified by the setup data to configure application components.) upon receipt of a manual snapshot command with respect to a first component of a user application hosted on a cloud infrastructure,
wherein the user application comprises a plurality of components including the set of components and the first component,(par 18 “the set of application components indicated in the setup data contains application services and infrastructure components, with the infrastructure components including a set of virtual machines (VMs) hosting the set of application components in the cloud infrastructure.”)
wherein the setup data also specifies, for each component of the set of components, a respective virtual machine of a plurality of virtual machines hosting the component in the cloud infrastructure;(par 18, 79 - teaches setup data which describes application services and the infrastructure components(virtual machines(VM)s) that the services are deployed on. Par 81-83 – teaches more details on how each deployment step has service/component packages to be deployed on different provisioned substrates(VMs). Fig 4A:421,422,423 – shows different components deployed into different environments. )
inspecting, by the management server, the setup data in said memory to identify the set of actions to be performed, each component of the set of components with respect to which each action of the set of actions is to be performed, and the virtual machine on which the component is hosted,(par 90 – teaches inspecting the setup data for the application profile. Par 91 – then determines the set of application components to be deployed in the cloud based on the setup data, giving examples of different packages/components to deploy. Fig 6A; par 92-94 – show how the packages are deployed on different VMs in the cloud environment.) wherein said setup data indicates that a first action of the set of actions is to be performed with respect to the first component hosted on a first virtual machine of the plurality of virtual machines, and that a second action of the set of actions is to be performed with respect to a second component hosted on a second virtual machine of the plurality of virtual machines, both of said first component and said second component being of the set of components,( par 81-83 – teaches more details on how each deployment step has service/component packages to be deployed on different provisioned substrates(VMs). Fig 4A:421,422,423 – shows different components deployed into different environments.)
It would have been obvious to one of ordinary skill in the art prior to the effective filing date to modify Dhamdhere’s application-snapshot system to incorporate Singh’s application-profile setup data associating application components and their corresponding scripts or runbooks with the virtual machines hosting those components. Dhamdhere already uses stored application configuration to identify and execute pre- and post-snapshot scripts, while Singh teaches setup data that identifies application services, actions performed through scripts or runbooks, and the corresponding VM substrates on which the services are hosted.
One of ordinary skill in the art prior to the effective filing date would have been motivated to make the combination because Singh’s setup data associating application components and their corresponding scripts would have predictably improved Dhamdhere by letting Dhamdhere explicitly identify the particular application component and hosting VM where the script/runbook should be run, which gives the benefit of reliably executing component-specific actions across a distributed cloud application. The combination would have involved applying a known technique taught by Singh to the similar system of Dhamdhere to improve a similar system in a predictable way.
Regarding claim 3, Dhamdhere and Singh teaches,
The method of claim 1,
Dhamdhere further teaches,
wherein said setup data further indicates that a third action of the set of actions is to be performed with respect to a third component of the set of components, ( par 18 - teaches customizable pre- and post-snapshot scripts for containers and an order for processing application services during the snapshot; Tables 1-2 - teach different container prefixes associated with different pre-snapshot scripts)
wherein the performing comprises executing, by the management server, a script to perform the set of actions, including the first action, the second action and the third action respectively with respect to the first component, the second component and the third component hosted on the respective virtual machines of the plurality of virtual machines.( par 18 - teaches customizable pre- and post-snapshot scripts for containers and an order for processing application services during the snapshot; Tables 1-2 - teach different container prefixes associated with different pre-snapshot scripts. Although Dhamdhere only gives two examples of pre- scripts(mysql-pre-script.sh and minio-pre-script.sh), it would be obvious to one of ordinary skill in the art to use a third script corresponding to a third component.)
Regarding claim 4, Dhamdhere and Singh teaches,
The method of claim 1,
Dhamdhere further teaches,
wherein the setup data is comprised in a blueprint file provided by an application deployer and the manual snapshot command is received from an operator.(par 32 - teaches a user-created application instance request object specifying deployment configuration files, pre- and post-snapshot scripts for containers, and a snapshot order)
Regarding claim 5, Dhamdhere and Singh teaches,
The method of claim 4,
Dhamdhere further teaches,
wherein the setup data further specifies that each action of a second set of restore actions to be performed with respect to a corresponding component of a second set of components upon receipt of a manual restore command with respect to the first component(fig 5:540,550; par 50 - teaches reading an application snapshot object to determine application configuration, volume snapshots, and actual data volumes), the method further comprising:
receiving, by the management server, after the storing of the setup data, the manual restore command to restore the first component to a previous state captured in a corresponding snapshot;(fig 5:510;par 47 - teaches receiving a request to deploy an application instance from an application snapshot object )
inspecting, by the management server, the setup data in said memory to identify the second set of restore actions to be performed, and each component of the second set of components with respect to which each action of the second set of actions is to be performed;(fig 5:540; par 50 - teaches reading an application snapshot object to determine application configuration, volume snapshots, and actual data volumes.)
performing, by the management server, each of the second set of restore actions with respect to the corresponding component in the second set of components along with restoring the first component to the previous state, (fig 5:540,550; par 50 - teaches reading an application snapshot object to determine application configuration, volume snapshots, and actual data volumes)
wherein the second set of actions includes a fourth action to start the first component and a fifth action to start the second component,(par 53 - teaches deploying a new application instance and using an orchestrator to start containers based on application configuration and volume references.)
wherein the performing further comprises starting the first component prior to starting the second component in view of the setup data indicating that the fourth action is to be performed prior to the fifth action.(par 53 - teaches deploying an application to a target cluster, mounting restored volumes, and using an orchestrator to start containers based on application configuration and volume references.)
However, Dhamdhere does not specifically go into how dependencies are ordered(limitations “wherein the second set of actions includes a fourth action to start the first component and a fifth action to start the second component, wherein the performing further comprises starting the first component prior to starting the second component in view of the setup data indicating that the fourth action is to be performed prior to the fifth action”).
On the other hand, Singh further teaches,
wherein the second set of actions includes a fourth action to start the first component and a fifth action to start the second component,(par 19 – teaches that the setup data describes dependencies among the set of application components, which describes the order that execution needs to happen. 4A:411,412,413; Par 68 – gives an example of dependencies in fig 4A with elements 411,412,413 being different services that have dependencies where one service needs to be executed before the next one. )
wherein the performing further comprises starting the first component prior to starting the second component in view of the setup data indicating that the fourth action is to be performed prior to the fifth action. (par 19 – teaches that the setup data describes dependencies among the set of application components, which describes the order that execution needs to happen. 4A:411,412,413; Par 68 – gives an example of dependencies in fig 4A with elements 411,412,413 being different services that have dependencies where one service needs to be executed before the next one. Par 78 – also teaches specifying dependencies in the setup data. )
Regarding claim 6, Dhamdhere and Singh teaches,
The method of claim 5,
Dhamdhere further teaches,
wherein all of the set of actions are performed before performing the capturing of the current state of the first component,(fig 4:450,460; par 43,44 – teaches pre-shapshot scripts that are run before the snapshot is taken.)
Singh further teaches,
wherein all of the second set of actions are performed after performing the restoring of the first component to the previous state.(par 80,85 – teach external scripts/runbooks that are used as part of the restoration process. They also teach inter-dependent configurations with each of the component’s dependencies. Par 58,59 – teaches extra configuration and data transfer steps executed once the service has been restored. par 19 – teaches that the setup data describes dependencies among the set of application components, which describes the order that execution needs to happen. 4A:411,412,413; Par 68 – gives an example of dependencies in fig 4A with elements 411,412,413 being different services that have dependencies where one service needs to be executed before the next one.)
Regarding claims 8,10,11 they are the non-transitory machine-readable medium storing one or more sequences of instructions, wherein execution of the one or more instructions by one or more processors contained in a digital processing system causes the digital processing system to perform the actions of the method of claims 1,3,4, and are rejected for the same reasons.
The extra limitations in claim 8 are taught by Dhamdhere and Singh. Those limitations are, A non-transitory machine-readable medium storing one or more sequences of instructions, wherein execution of the one or more instructions by one or more processors contained in a digital processing system causes the digital processing system to perform the actions of: (Dhamdhere par 6, Singh par 107-112) and wherein the setup data also specifies, for each component of the set of components, a respective virtual machine of said plurality of virtual machines hosting the component in the cloud infrastructure(Singh par 18, 79 - teaches setup data which describes application services and the infrastructure components(virtual machines(VM)s) that the services are deployed on. Par 81-83 – teaches more details on how each deployment step has service/component packages to be deployed on different provisioned substrates(VMs).)
Regarding claim 12, it is the machine-readable medium storing instructions to implement the method of claim 5, but with the last two limitations removed (“wherein the second set of actions includes a fourth action to start the first component and a fifth action to start the second component, wherein the performing further comprises starting the first component prior to starting the second component in view of the setup data indicating that the fourth action is to be performed prior to the fifth action”). Claim 12 is rejected for the same reasons as claim 5.
Regarding claim 13, it is the non-transitory machine-readable medium storing one or more sequences of instructions, wherein execution of the one or more instructions by one or more processors contained in a digital processing system causes the digital processing system to perform the actions of the method of claim 6 and is rejected for the same reasons.
Regarding claims 15,17-18, they are the digital processing system comprising: a random access memory (RAM) to store instructions; and one or more processors to retrieve and execute the instructions, wherein execution of the instructions causes the digital processing system to perform the method of claims 1,3-4 and are rejected for the same reasons.
The extra limitations in claim 15 are taught by Dhamdhere and Singh. Those limitations are, A digital processing system comprising: a random access memory (RAM) to store instructions; and one or more processors to retrieve and execute the instructions, wherein execution of the instructions causes the digital processing system to perform the actions of: (Dhamdhere fig 2; par 25,61; Singh par 102-104) and wherein the setup data also specifies, for each component of the set of components, a respective virtual machine of said plurality of virtual machines hosting the component in the cloud infrastructure(Singh par 18, 79 - teaches setup data which describes application services and the infrastructure components(virtual machines(VM)s) that the services are deployed on. Par 81-83 – teaches more details on how each deployment step has service/component packages to be deployed on different provisioned substrates(VMs).)
Regarding claim 19, it is the system that implements the method of claim 5, but with the last two limitations removed (“wherein the second set of actions includes a fourth action to start the first component and a fifth action to start the second component, wherein the performing further comprises starting the first component prior to starting the second component in view of the setup data indicating that the fourth action is to be performed prior to the fifth action”). Claim 19 is rejected for the same reasons as claim 5.
Regarding claim 20, it is the system that performs the method of claim 6 and is rejected for the same reasons.
Regarding claim 23, Dhamdhere and Singh teaches,
The method of claim 1,
Singh further teaches,
wherein the setup data specifies for each component of said plurality of components a corresponding component identifier of a plurality of component identifiers, wherein a first component identifier is specified for said first component;(fig 5A:”name”,”uuid”(UUID stands for Universally Unique Identifier.); par 78 – teaches setup data that specify details of application services, details that identify components from the other components. Fig 5B; par 80-82 – teaches another example of service/package names in the setup data.)
wherein the setup data, to specify the manual snapshot command with respect to the first component, comprises the first component identifier associated with a first plurality of pairs, with each pair having a component identifier and an action identifier to indicate that an action identified by the action identifier is to be performed with respect to a component identified by the component identifier,( Fig 5B:540; par 80-82 – teaches another example of service/package names in the setup data, with each package representing a service and packages including runbooks/scripts.)
wherein the first plurality of pairs includes a first pair and a second pair, with the first pair having the first component identifier and a first action identifier identifying the first action, and the second pair having a second component identifier identifying the second component and a second action identifier identifying the second action,(fig 5A,5B; par 78-80,84-85 – teaches separately identified first component MYSQL and second component APACHE_PHP, each with their own packages(pairs), containing setup data, like runbooks/scripts.)
wherein the received manual snapshot command specifies the first component identifier,(fig 3:340,360; par 54-56 teaches receiving a request to move a user application, and using the request details, identifying an application profile containing the identifiers of the cloud infrastructure targets for moving.)
wherein, for said inspecting, the management server inspects the setup data to determine the first plurality of pairs to identify the set of actions to be performed, and each component of the set of components with respect to which each action of the set of actions is to be performed.(par 23,56 – teaches using the move request details, identifying an application profile from the setup data to determine which packages to act on. Par 80,85 – teaches package(service/component) details, including scripts/runbooks to be run during deployment. Par 90-94 – teaches inspecting the setup data, identifying the specific set of application components/packages to be deployed, and how to deploy them using the identified packages.)
Regarding claim 24, Dhamdhere and Singh teaches,
The method of claim 23,
Singh further teaches,
wherein the setup data specifies for each virtual machine of said plurality of virtual machines a corresponding virtual machine identifier of a plurality of virtual machine identifiers,(fig 4A:421,422,423; par 67-69 – teaches services HAPROXY_AWS, APACHE_PHP_AWS, MYSQL_AWS and corresponding virtual machines HAPROXY_AWS_VM, APACHE_PHP_AWS_VM, MYSQL_AWS_VM that they run on.)
wherein the management server, when performing the first action and the second action, uses the component identifiers and the virtual machine identifiers in the setup data to determine the first virtual machine hosting the first component and the second virtual machine hosting the second component. (fig 4A:421,422,423; par 67-69 – teaches services HAPROXY_AWS, APACHE_PHP_AWS, MYSQL_AWS and corresponding virtual machines HAPROXY_AWS_VM, APACHE_PHP_AWS_VM, MYSQL_AWS_VM that they run on. Fig 5B,5C; Par 81-85 teach that the setup data includes application profiles which detail which virtual machine hosts each component, as well as runbooks/scripts to run to help set up those components.)
Regarding claim 25, Dhamdhere and Singh teaches,
The method of claim 24,
Singh further teaches,
wherein said setup data is comprised in a blueprint file,( par 52-53,75-76 – teaches structured setup data containing an application profile specifying the deployment details of the user application.) wherein the setup data further associates, with each component identifier, a respective virtual machine identifier,( fig 4A:421,422,423; par 67-69 – teaches services HAPROXY_AWS, APACHE_PHP_AWS, MYSQL_AWS and corresponding virtual machines HAPROXY_AWS_VM, APACHE_PHP_AWS_VM, MYSQL_AWS_VM that they run on. Fig 5B,5C; Par 81-85 teach that the setup data includes application profiles which detail which virtual machine hosts each component, as well as runbooks/scripts to run to help set up those components) and
wherein the management server, when performing the first action and the second action, uses the first component identifier and the second component identifier to respectively determine a first virtual machine identifier and a second virtual machine identifier identifying the first virtual machine and the second virtual machine.(fig 4A:421,422,423; par 67-69 – teaches services HAPROXY_AWS, APACHE_PHP_AWS, MYSQL_AWS and corresponding virtual machines HAPROXY_AWS_VM, APACHE_PHP_AWS_VM, MYSQL_AWS_VM that they run on. Fig 5B,5C; Par 81-85 teach that the setup data includes application profiles which detail which virtual machine hosts each component, as well as runbooks/scripts to run to help set up those components. Par 90-97 teach that the mobility server provisions the named VMs and hosts and configures the corresponding application services on those VMs.)
Claim(s) 14,21 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190065323 A1 (Dhamdhere) and US 20210014333 A1 (Singh) as applied to claims 13,1 above, and further in view of US 20220206902 A1 (Hoang).
Regarding claim 14, Dhamdhere and Singh teaches,
The non-transitory machine-readable medium of claim 13,
Singh further teaches,
wherein the second component dependent on the first component as a base component in that the first component is required to be executing for appropriate operation of the second component,( par 19 – teaches that the setup data describes dependencies among the set of application components, which describes the order that execution needs to happen. 4A:411,412,413; Par 68 – gives an example of dependencies in fig 4A with elements 411,412,413 being different services that have dependencies where one service needs to be executed before the next one.)
However, Dhamdhere and Singh does not explicitly teach wherein the setup data specifies that the first action is to stop the first component and that the second action is to stop the second component, wherein the setup data also specifies that said second action is to be performed prior to said first action, wherein the performing comprises stopping the second component followed by stopping the first component prior to the set of copy actions.
On the other hand, Hoang teaches,
wherein the second component dependent on the first component as a base component in that the first component is required to be executing for appropriate operation of the second component,(fig 3:301,303,305; par 57 - teaches an application template specifying quiesce/unquiesce commands and selectors that sequence dependent resources for application-consistent cluster backup; par 42 - teaches application-template labels, resource-specific hooks, and selectors that serialize resource backups in a specified order)
wherein the setup data specifies that the first action is to stop the first component and that the second action is to stop the second component, wherein the setup data also specifies that said second action is to be performed prior to said first action,( par 42 - teaches application-template labels, resource-specific hooks, and selectors that serialize resource backups in a specified order; fig 3:302,304,306,310; par 44 - teaches prehook/posthook pairs that suspend processes before backup, resume them afterward, and use selectors to order pod-level operations)
wherein the performing comprises stopping the second component followed by stopping the first component prior to the set of copy actions.(par 48 - teaches generating hook annotations and using selectors to sequence application pods before backing them up in the specified order)
It would have been obvious to one of ordinary skill in the art prior to the effective filing date to combine the snapshot preparation and snapshot system of Dhamdhere and Singh with the pre-backup suspension action of Hoang. Dhamdhere teaches executing pre-snapshot actions before performing the snapshot copy operations, while Singh teaches setup data identifying dependency relationships between application components, including a dependent component and its corresponding base component. Hoang further teaches using prehooks and selectors to suspend selected application resources in a specified sequence before backup so that application consistency is maintained.
One of ordinary skill in the art prior to the effective filing date would have been motivated to make the combination because the pre-backup suspension action from Hoang would have predictably improved Dhamdhere and Singh by solving the problem of maintaining application consistency while capturing the state of a multi-component application.(Hoang par 5 “What is needed, therefore, is a process that allows application ( e.g., database) pods to be quiesced and snap shotted in a specific order to ensure application consistency of the cluster deployments not only on a single node but across all the nodes in the cluster.”; Hoang par 4 “A common backup process for database protection involves quiescing databases prior to backups. However, Kubernetes does not currently provide any mechanism to natively specify the order in which pods belonging to an application can be quiesced for snapshot backups. Such quiescing or suspension of operations is often used in other dynamic applications in which data is constantly and quickly accessed and modified during usual user operations.”). The combination would have involved applying a known technique taught by Hoang to the similar system of Dhamdhere and Singh to improve a similar system in a predictable way. Hoang provides “an application template processing system for application consistent backup and restores of database applications in Kubernetes.”(Hoang par 20)
Regarding claim 21, it is the method that performs the instructions stored on the computer readable medium of claim 14 and is rejected for the same reasons.
Response to Arguments
Applicant’s arguments, see Remarks, filed 06/16/2026, with respect to the rejection(s) of claim(s) 1,3-6,8,10-15,17-21 under 35 U.S.C. 103 as being unpatentable over US 20190065323 A1 (Dhamdhere) in view of US 20220206902 A1 (Hoang) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. 103 as being unpatentable over US 20190065323 A1 (Dhamdhere) in view of US 20210014333 A1 (Singh).
With respect to the independent claims, the applicant has argued that Dhamdhere only teaches copy actions, not “the set of actions in addition to the set of copy actions”, outlined in claim 1 limitations “performing, by the management server, the set of actions in addition to the set of copy actions for capturing the current state of the first component”, explaining that Dhamdhere’s ordering only applies to taking snapshots, not running scripts. The examiner respectfully disagrees. Dhamdhere teaches in the cited (par 14 - teaches performing the snapshot in a specified order and executing specified pre- and post-snapshot scripts as part of the snapshot operation; par 18 - teaches customizable pre- and post-snapshot scripts for containers and an order for processing application services during the snapshot). The pre-snapshot scripts are run before the snapshot is taken, and are considered actions in addition to the set of copy actions(the snapshot operation). Additionally, the newly cited Singh also teaches in the cited (par 80 – teaches specifying the name of an external script/runbook to the executed for installation of the package and/or service. Par 85 – teaches using external scripts/runbooks specified by the setup data to configure application components.). This teaches or at least suggests the claimed “the set of actions in addition to the set of copy actions”.
With respect to the independent claims, the applicant has argued that Dhamdhere and Hoang does not teach limitations “each component of the set of components with respect to which each action of the set of actions is to be performed, and the virtual machine on which the component is hosted, wherein said setup data indicates that a first action of the set of actions is to be performed with respect to the first component hosted on a first virtual machine of the plurality of virtual machines, and that a second action of the set of actions is to be performed with respect to a second component hosted on a second virtual machine of the plurality of virtual machines, both of said first component and said second component being of the set of components, the first component being different from the second component;”, explaining that Dhamdhere acts on containers, not components on virtual machines, and that Hoang does not cover these new limitations either. The newly cited Singh teaches in the cited (fig 4A:421,422,423; par 67-69 – teaches services HAPROXY_AWS, APACHE_PHP_AWS, MYSQL_AWS and corresponding virtual machines HAPROXY_AWS_VM, APACHE_PHP_AWS_VM, MYSQL_AWS_VM that they run on. Fig 5B,5C; Par 81-85 teach that the setup data includes application profiles which detail which virtual machine hosts each component, as well as runbooks/scripts to run to help set up those components.). Under the broadest reasonable interpretation, this teaches or at least suggests the claimed “each component of the set of components with respect to which each action of the set of actions is to be performed, and the virtual machine on which the component is hosted, wherein said setup data indicates that a first action of the set of actions is to be performed with respect to the first component hosted on a first virtual machine of the plurality of virtual machines, and that a second action of the set of actions is to be performed with respect to a second component hosted on a second virtual machine of the plurality of virtual machines, both of said first component and said second component being of the set of components, the first component being different from the second component;”.
With respect to the independent claims, the applicant has argued that Dhamdhere and Hoang does not teach the limitations in the new claims 23-25. Please see the new grounds of rejection under 35 U.S.C. 103 as being unpatentable over US 20190065323 A1 (Dhamdhere) in view of US 20210014333 A1 (Singh) above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20220114059 A1 - Zhang - preflight check when restoring from snapshot to ensure that the restored image is working properly.
US 20210374011 A1 - Fitzsimons - data object backup, has instructions for how to do the backup. More like dependency and location instructions on how to back up.
US 20210365330 A1 - Kushnir - rehydrate OS disk - re-arrange point in time backups in the correct order to recover.
US 20210232420 A1 - Dhruvakumar - starting paused VMs and the re-build process.
US 20210224166 A1 - Luo - database periodic snapshots and transaction logs to restore to specific points.
US 20210200603 A1 - Battiprolu - identifies hanging thread and restores from snapshot with an identified script for resolving the match stuck thread scenario.
US 20210011816 A1 - Mitkar - prepares containerized applications for backup using a backup services container in a container orchestration pod. Figure 8 element 806. - Commvault
US 20190163578 A1 - Anami - places VM in a backup state before taking the snapshot.
US 20160110267 A1 - Earl - post restore operations when recovering. See fig 14 "OnPostRestore"
US 20230106269 A1 - Mitkar - has scripts that prepare the containerized application for backup operations.
US 20210011812 A1 - Mitkar - prepares containerized applications for backup using a backup services container.
US 20220121526 A1 - Kumar - backup copy of federated application.
US 20080229142 A1 - Anand – runs extra scripts after restoring from snapshot.
US 20220291998 A1 – Devaraj - backs up application data from cloud native applications
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 MICHAEL XU whose telephone number is (571)272-5688. The examiner can normally be reached Monday-Friday 8:00am - 5:00pm.
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, Bryce Bonzo can be reached at (571) 272-3655. 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.
/M.X./Examiner, Art Unit 2113 /BRYCE P BONZO/Supervisory Patent Examiner, Art Unit 2113
Prosecution Insights