DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. Claims 1–20 are presented for examination in a non-provisional application filed on 04/12/2024.
Drawings
3. The drawings were received on 04/12/2024 (in the filings). These drawings are acceptable.
Examiner’s Remarks
4. Examiner refers to and explicitly cites particular pages, sections, figures, paragraphs or columns and lines in the references as applied to Applicant’s claims to the extent practicable to streamline prosecution.
Although the cited portions of the references are representative of the best teachings in the art and are applied to meet the specific limitations of the claims, other uncited but related teachings of the references may be equally applicable as well. It is respectfully requested that, in preparing responses to the rejections, the Applicant fully considers not only the cited portions of the references, but also the references in their entirety, as potentially teaching, suggesting or rendering obvious all or one or more aspects of the claimed invention.
Abbreviations
5. Where appropriate, the following abbreviations will be used when referencing Applicant’s submissions and specific teachings of the reference(s):
i. figure / figures: Fig. / Figs.
ii. column / columns: Col. / Cols.
iii. page / pages: p. / pp.
References Cited
6. (A) Balcha et al., US 2023/0082186 A1 (“Balcha”).
(B) Liu et al., US 2016/0202923 A1 (“Liu”).
(C) Natanzon et al., US 10,929,245 B1 (“Natanzon”).
(D) Peter et al., US 2008/0082575 A1 (“Peter”).
(E) Hoang et al., US 2023/0281082 A1 (“Hoang”).
Notice re prior art available under both pre-AIA and AIA
7. 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 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.
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.
A.
8. Claims 1–4, 7, 9–15, and 17–20 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Balcha in view of (B) Liu.
See “References Cited” section, above, for full citations of references.
9. Regarding claim 1, (A) Balcha teaches/suggests the invention substantially as claimed, including:
“A computer-implemented method for migrating data, the method comprising:
performing one or more first operations to orchestrate execution [[of one or more first scripts]] … in one or more first virtual computing instances, wherein the execution [[of the one or more first scripts]] causes data associated with the one or more first virtual computing instances to be backed up to at least one first disk;
(Figs. 3 and 4, and ¶ 42: CONTAINER-BASED APPLICATION data protection backup in a continuous restore method;
¶ 43: In a first step 302, a backup process is triggered. The trigger for a backup can take many forms including, for example, being a scheduled trigger, trigger or triggers that are defined by a policy, user initiated, one-click initiated, and other forms of triggers;
¶ 45: In a fifth step 310, the application data is backed up to a storage volume, or volumes. In some embodiments, the stateful set of services of the application are determined and the data in the storage volumes associated with the application are stored in a backup storage volume);
copying the data from the at least one first disk to at least one second disk; and
(¶ 49: In some embodiments, restoration is provided with a copy to a new location or availability zone. Also, in some embodiments, the restore process migrates an application or applications to a new Kubernetes cluster;
¶ 78: replicating the applications in multiple locations;
Figs. 8A and 8B, and ¶ 81: file system level replication where each file is replicated to remote sites consistently. FIG. 8B illustrates a system diagram 850 for a known embodiment of container-based application storage-level data replication and recovery using file-level replication);
performing one or more second operations to orchestrate execution [[of one or more second scripts]] … in one or more second virtual computing instances, wherein the execution [[of the one or more second scripts]] causes the data to be restored from the at least one second disk to the one or more second virtual computing instances”
(Figs. 3 and 4, and ¶ 47: method of container-based application data protection restore in a continuous restore method;
¶ 48: in a first step 402, a restore process is triggered. The trigger for the restoration can take many forms including, for example, being a scheduled trigger, trigger or triggers that are defined by a policy …;
¶ 53: In an eighth step 416, the application skeleton is rebooted. The reboot of the application skeleton thus successfully restores the application and its associated stateful information associated with the particular backup information (files and data in storage volumes) that was chosen to be restored).
Balcha does not teach “execution of one or more first scripts in one or more first virtual computing instances” and “execution of one or more second scripts in one or more second virtual computing instances” to perform the backup and restore.
(B) Liu, in the context of Balcha’s teachings, however teaches or suggests implementing
“execution of one or more first scripts in one or more first virtual computing instances”
(Fig. 2 and ¶ 35: in response to a need of backing up the application, a first set of scripts is executed. The first set of scripts is used for, prior to the backup, coordinating the multiple virtual machines to have them enter into a preparation state;
¶ 40: when the application comprises an application server, the first set of scripts includes a script having the application server of the application enter into a backup state; the second set of scripts comprises a script having the application server of the application restore its running. For example, the first set of scripts may execute the following operations: stopping the application server and setting the application server to only accept a read request. Correspondingly, the second set of scripts performs an operation contrary to the first set of scripts, for example, restoring the running of the application server, and setting the application server to be capable of accepting a read request;
Fig. 3B and ¶ 47: FIG. 3B shows a schematic diagram of a backup agent being located in a virtual machine according to one embodiment of the present invention. In this embodiment, the backup agents are set up within respective virtual machines where the application is located. This embodiment is more common, because in many cases, the user does not directly have operation rights for the physical node; therefore, it is required to implant a backup agent within the virtual machine, such that the backup operation for the data related to the application within the virtual machine may be performed by triggering the backup agent … Besides, the backup/restore agents are located within respective virtual machines; therefore, each backup/restore agent has rights within the virtual machines to perform backup operation on the data related to the application);
and
“execution of one or more second scripts in one or more second virtual computing instances” (to perform the backup and restore).
(Fig. 4 and ¶ 59: in response to receiving an instruction of restoring the application, a first set of restore scripts are invoked and executed, the first set of restore scripts being for re-deploying the application on multiple newly created virtual machines to enter into a restore preparation state;;
¶ 40: when the application comprises an application server, the first set of scripts includes a script having the application server of the application enter into a backup state; the second set of scripts comprises a script having the application server of the application restore its running. For example, the first set of scripts may execute the following operations: stopping the application server and setting the application server to only accept a read request. Correspondingly, the second set of scripts performs an operation contrary to the first set of scripts, for example, restoring the running of the application server, and setting the application server to be capable of accepting a read request;
Fig. 3B and ¶ 47: FIG. 3B shows a schematic diagram of a backup agent being located in a virtual machine … the backup/restore agents are located within respective virtual machines; therefore, each backup/restore agent has rights within the virtual machines to perform backup operation on the data related to the application);
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of B) Liu with those of (A) Balcha to coordinate and perform backup and restore operations using distributed scripts. The motivation or advantage to do so is to provide automated execution of backup and restores across different applications/services.
10. Regarding claim 2, Balcha teaches or suggests:
“wherein the one or more second operations to orchestrate execution of the one or more second scripts are performed in response to detecting the data has been copied to the at least one second disk”
(Fig. 9 and ¶ 85: a container-based application continuous restore failover system 900 … A restored application runs at the remote site and connects to the persistent volume 908. The remote persistent volume 908 is synchronized to the backup target 906 using a data synch pod that copies the latest backup delta;
¶ 98: e) recovering the containerized application at the second cluster based on at least some of the application data moved to the persistent volume on the second cluster such that the recovered containerized application is operational at a most recent backup point-of-time of the backup plan schedule).
11. Regarding claim 3, Balcha and Liu teach or suggest:
“wherein the one or more first virtual computing instances include a plurality of containers associated with a plurality of pods, and performing the one or more first operations to orchestrate execution of the one or more first scripts comprises iteratively causing one or more containers associated with each pod included in the plurality of pods to execute the one or more first scripts”
(Balcha, Fig. 2 and ¶ 36: containerized application stack 200 for an application that is included in a continuous restore policy executing on a Kubernetes cluster of the present teaching. The application 202 includes three microservices, a web server service 204, a middleware service 206, and a database service 208. Each microservice 204, 206, 208 runs using multiples pods;
Fig. 5 and ¶ 55: systems that run and/or develop applications using a container-based approach. Application pods 508, 508', Pod A and Pod B, have stateful information data in persistent volumes 510, 510', PV-A, PV-B. In some embodiments the persistent volumes 510, 510' are network file system (NFS). For a data backup, a snapshot 512 of PV-A volume 510 can be created and a new persistent volume 514 is created from the snapshot. The new persistent volume 514 is attached to a data mover pod 516. The data mover service copies the persistent volume 514 to a repository 518. A data synch pod 520 also performs reads and writes with repository 518. The data synch pod 520 is spun up to synchronize existing PV data from the latest backup images to a remote site PV as described herein;
Figs. 3 and 4, and ¶ 42: CONTAINER-BASED APPLICATION data protection backup in a continuous restore method;
¶ 43: In a first step 302, a backup process is triggered. The trigger for a backup can take many forms including, for example, being a scheduled trigger, trigger or triggers that are defined by a policy, user initiated, one-click initiated, and other forms of triggers;
¶ 45: In a fifth step 310, the application data is backed up to a storage volume, or volumes. In some embodiments, the stateful set of services of the application are determined and the data in the storage volumes associated with the application are stored in a backup storage volume;
¶ 87: coordination of backup applications running at different locations for data protection;
See ¶ 20: methods of the present teachings may be performed in any order and/or simultaneously;
Liu, Fig. 2 and ¶ 35; ¶ 40; Fig. 3B and ¶ 47; Fig. 4 and ¶ 59, as applied in rejecting claim 1 above, teaching performing backup and restore operations using sets of scripts).
12. Regarding claim 4, Balcha and Liu teach or suggest:
“wherein the one or more first virtual computing instances include one or more first containers associated with a first pod and one or more second containers associated with a second pod, and the one or more first containers execute a first set of scripts included in the one or more first scripts that is different from a second set of scripts included in the one or more first scripts and executed by the one or more second containers”
(Balcha, Fig. 2 and ¶ 36: In Kubernetes, a pod is a grouping of one or more containers that operate together. The web server service 204 uses four pods 210, 210’, 210’’, 210’’’’. The middleware service 206 uses four pods 212, 212’, 212’’, 212’’’’. The database service 208 uses five pods 214, 214’’, 214’’, 214’’’, 214’’’’. In some embodiments, each pod comprises one or more Docker containers;
¶ 37: Each application pod 210, 210’, 210’’, 210’’’’, 212, 212’, 212’’, 212’’’’, 214, 214’’, 214’’, 214’’’, 214’’’’may have an associated stateful data set, and thus, an associated persistent storage volume. This is sometimes referred to as a persistent volume or PV;
Liu, Fig. 2 and ¶ 35; ¶ 40; Fig. 3B and ¶ 47; Fig. 4 and ¶ 59, as applied in rejecting claim 1 above, teaching performing backup and restore operations using sets of scripts;
¶ 39: when the application comprises a database, the first set of scripts includes a script having the database of the application enter into a backup state;
¶ 40: when the application comprises an application server, the first set of scripts includes a script having the application server of the application enter into a backup state;
the Examiner notes: backing up different applications and stateful data to each applications respective associated persistent storage volume required or renders obvious using different scripts).
13. Regarding claim 7, Balcha teaches or suggests:
“wherein the one or more first virtual computing instances are included in a first cluster of virtual computing instances executing at a first location, and the one or more second virtual computing instances are included in a second cluster of virtual computing instances executing at a second location”
(Fig. 2 and ¶ 36: containerized application stack 200 for an application that is included in a continuous restore policy executing on a Kubernetes cluster of the present teaching. The application 202 includes three microservices, a web server service 204, a middleware service 206, and a database service 208. Each microservice 204, 206, 208 runs using multiples pods;
¶ 49: In some embodiments, restoration is provided with a copy to a new location or availability zone. Also, in some embodiments, the restore process migrates an application or applications to a new Kubernetes cluster;
Fig. 5 and ¶ 55: systems that run and/or develop applications using a container-based approach. Application pods 508, 508', Pod A and Pod B, have stateful information data in persistent volumes 510, 510', PV-A, PV-B. In some embodiments the persistent volumes 510, 510' are network file system (NFS). For a data backup, a snapshot 512 of PV-A volume 510 can be created and a new persistent volume 514 is created from the snapshot. The new persistent volume 514 is attached to a data mover pod 516. The data mover service copies the persistent volume 514 to a repository 518. A data synch pod 520 also performs reads and writes with repository 518. The data synch pod 520 is spun up to synchronize existing PV data from the latest backup images to a remote site PV as described herein;
14. Regarding claim 9, Balcha teaches or suggests:
“wherein the one or more first virtual computing instances execute within at least one of a first cloud computing system or a first data center, and the one or more second virtual computing instances execute within at least one of a second cloud computing system or a second data center”
(¶ 29: method and system of the present teaching provides continuous restore for distributed computing environments, such as private and public clouds, private data centers and hybrids of these environments;
¶ 31: various types of computing environments, including computing resources and services available in private and public data centers and/or cloud and/or enterprise environments).
15. Regarding claim 10, Balcha teaches or suggests:
“wherein the one or more first virtual computing instances execute a first version of an application, and the one or more second virtual computing instances execute a second version of the application”
(¶ 22: protect data using backup and recovery solutions to recover data and applications in the event of total outage, data corruption, data loss, version control (roll-back during upgrades);
¶ 54: In an optional step 418, the application template is upgraded. For example, an upgrade can be desired if a new version of software involved in the application workload is available, and the upgrade will move the version of the restored upgraded application to the new version).
16. Regarding claims 11–13, 15, and 19, they are the corresponding computer program product claims reciting similar limitations of commensurate scope as the method of claims 1–4 and 10, respectively. Therefore, they are rejected on the same basis as claims 1–4 and 10 above.
17. Regarding claim 14, Balcha and Liu teach or suggest:
“wherein the one or more second virtual computing instances include a plurality of containers associated with one or more pods, and performing the one or more second operations to orchestrate execution of the one or more second scripts comprises iteratively causing one or more containers associated with each pod included in the one or more pods to execute the one or more second scripts”
(Balcha, Fig. 2 and ¶ 36: containerized application stack 200 for an application that is included in a continuous restore policy executing on a Kubernetes cluster of the present teaching. The application 202 includes three microservices, a web server service 204, a middleware service 206, and a database service 208. Each microservice 204, 206, 208 runs using multiples pods;
Fig. 5 and ¶ 55: systems that run and/or develop applications using a container-based approach. Application pods 508, 508', Pod A and Pod B, have stateful information data in persistent volumes 510, 510', PV-A, PV-B. In some embodiments the persistent volumes 510, 510' are network file system (NFS). For a data backup, a snapshot 512 of PV-A volume 510 can be created and a new persistent volume 514 is created from the snapshot. The new persistent volume 514 is attached to a data mover pod 516. The data mover service copies the persistent volume 514 to a repository 518. A data synch pod 520 also performs reads and writes with repository 518. The data synch pod 520 is spun up to synchronize existing PV data from the latest backup images to a remote site PV as described herein;
Figs. 3 and 4, and ¶ 42: CONTAINER-BASED APPLICATION data protection backup in a continuous restore method;
¶ 43: In a first step 302, a backup process is triggered. The trigger for a backup can take many forms including, for example, being a scheduled trigger, trigger or triggers that are defined by a policy, user initiated, one-click initiated, and other forms of triggers;
¶ 45: In a fifth step 310, the application data is backed up to a storage volume, or volumes. In some embodiments, the stateful set of services of the application are determined and the data in the storage volumes associated with the application are stored in a backup storage volume;
¶ 87: coordination of backup applications running at different locations for data protection;
¶ 48: in a first step 402, a restore process is triggered. The trigger for the restoration can take many forms including, for example, being a scheduled trigger, trigger or triggers that are defined by a policy …. The trigger can occur on a regular time pattern, or the trigger can occur at random times;
See ¶ 20: methods of the present teachings may be performed in any order and/or simultaneously;
Liu, Fig. 2 and ¶ 35; ¶ 40; Fig. 3B and ¶ 47; Fig. 4 and ¶ 59, as applied in rejecting claim 1 above, teaching performing backup and restore operations using sets of scripts).
18. Regarding claim 17, Balcha and Liu teach or suggest:
“wherein each virtual computing instance included in the one or more first virtual computing instances comprises a container or a virtual machine (VM)”
(Balcha, Fig. 2 and ¶ 36: containerized application stack 200 for an application that is included in a continuous restore policy executing on a Kubernetes cluster of the present teaching. The application 202 includes three microservices, a web server service 204, a middleware service 206, and a database service 208. Each microservice 204, 206, 208 runs using multiples pods;
Fig. 5 and ¶ 55: systems that run and/or develop applications using a container-based approach. Application pods 508, 508', Pod A and Pod B, have stateful information data in persistent volumes 510, 510', PV-A, PV-B. In some embodiments the persistent volumes 510, 510' are network file system (NFS). For a data backup, a snapshot 512 of PV-A volume 510 can be created and a new persistent volume 514 is created from the snapshot. The new persistent volume 514 is attached to a data mover pod 516. The data mover service copies the persistent volume 514 to a repository 518. A data synch pod 520 also performs reads and writes with repository 518. The data synch pod 520 is spun up to synchronize existing PV data from the latest backup images to a remote site PV as described herein;
¶ 35: applications executing using containers that execute on virtual machines and/or physical machines;
Liu, Fig. 2 and ¶ 35; ¶ 40; Fig. 3B and ¶ 47; Fig. 4 and ¶ 59).
19. Regarding claim 18, Balcha teaches or suggests:
“wherein the one or more first virtual computing instances execute within a first cloud
computing system, and the one or more second virtual computing instances execute within a second cloud computing system”
(¶ 29: method and system of the present teaching provides continuous restore for distributed computing environments, such as private and public clouds, private data centers and hybrids of these environments;
¶ 31: various types of computing environments, including computing resources and services available in private and public data centers and/or cloud and/or enterprise environments).
20. Regarding claim 20, it is the corresponding system claim reciting similar limitations of commensurate scope as the method of claim 1. Therefore, it is rejected on the same basis as claim 1 above, including the following rationale:
Liu teaches or suggests the configuration of “one or more memories storing instructions; and one or more processors that are coupled to the one or more memories and, when executing the instructions, are configured to …” (Fig. 1 and ¶¶ 24 and 28)
B.
21. Claims 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Balcha in view of (B) Liu, as applied to claims 1 and 11 above, and further in view of (C) Natanzon.
22. Regarding claim 5, Balcha and Liu teaches or suggests “one or more first operations to be performed to orchestrate execution of the one or more first scripts.”
(Balcha, Figs. 3 and 4, and ¶ 42: CONTAINER-BASED APPLICATION data protection backup in a continuous restore method;
¶ 43: In a first step 302, a backup process is triggered. The trigger for a backup can take many forms including, for example, being a scheduled trigger, trigger or triggers that are defined by a policy, user initiated, one-click initiated, and other forms of triggers;
¶ 45: In a fifth step 310, the application data is backed up to a storage volume, or volumes. In some embodiments, the stateful set of services of the application are determined and the data in the storage volumes associated with the application are stored in a backup storage volume;
Liu, Fig. 2 and ¶ 35; ¶ 40; Fig. 3B and ¶ 47; Fig. 4 and ¶ 59, as applied in rejecting claim 1 above, teaching performing backup and restore operations using sets of scripts;
Balcha and Liu do not teach “in response to receiving a user request, creating a job based on a time configuration that causes the one or more first operations to be performed …”
(C) Natanzon, in the context of Balcha and Liu’s teachings, however teaches or suggests implementing:
“in response to receiving a user request, creating a job based on a time configuration that causes the one or more first operations to be performed …”
(Col. 3, lines 8–12: the backup job scheduler includes a user interface that enables users to specify user-customized backup policies that enable flexibility in scheduling execution times;
Col. 5, lines 32–42: For each backup job a customer defines a flexible, or soft, backup policy on the backup job policy repository via a backup scheduler user interface (UI) 212, as will be described in further detail in FIG. 3. Rather than defining a fixed time slot, backup job policy 123 will allow customers a degree of freedom in selecting, through the backup scheduler UI 212, an exact time or range of execution times at which their backup job is scheduled;
Col. 6, lines 13–18: calculates a customer's expected charges for a backup job based on the actual and predicted resource availability during the requested backup time period and the type of backup requested).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (C) Natanzon with those of (A) Balcha and (B) Liu to enable user input/selection of a backup policy or schedule. The motivation or advantage to do so is provide for flexible job scheduling based on backup requirements or customer preferences, cost, and/or resource availability.
23. Regarding claim 16, it is the corresponding computer program product claim reciting similar limitations of commensurate scope as the method of claim 5. Therefore, they are rejected on the same basis as claim 5 above.
C.
24. Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over (A) Balcha in view of (B) Liu, as applied to claim 1 above, and further in view of (D) Peter.
25. Regarding claim 6, Balcha teaches or suggests “wherein the data is copied from the at least one first disk to the at least one second disk”
(¶ 49: In some embodiments, restoration is provided with a copy to a new location or availability zone. Also, in some embodiments, the restore process migrates an application or applications to a new Kubernetes cluster;
¶ 78: replicating the applications in multiple locations;
Figs. 8A and 8B, and ¶ 81: file system level replication where each file is replicated to remote sites consistently. FIG. 8B illustrates a system diagram 850 for a known embodiment of container-based application storage-level data replication and recovery using file-level replication).
Balcha and Liu do not teach “… via an enterprise application integration (EAI) route.”
(D) Peter, in the context of Balcha and Liu’s teachings, however teaches or suggests implementing:
“… via an enterprise application integration (EAI) route”
(¶ 33: Generally, enterprise application integration middleware 175 may be any tool or software that can centrally manage or facilitate management of data conversion (especially XML file conversion) logic to allow mediating between different interfaces. In certain embodiments, enterprise application integration middleware 176 integrates different versions of systems implemented on different platforms, such as Java, ABAP, and so forth. In other words, the enterprise application integration middleware 176 generally allows for the exchange of information from a first object, component, or system to a second object, component, or system over network 112 by using standardized interfaces).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (D) Peter with those of (A) Balcha and (B) Liu to incorporate an EAI middleware software to support data backups (transfers). The motivation or advantage to do so is to integrate and allow for the exchange of data across different system versions, interfaces on different platforms.
D.
26. Claims 8 is rejected under 35 U.S.C. 103 as being unpatentable over (A) Balcha in view of (B) Liu, as applied to claim 1 above, and further in view of (E) Hoang.
27. Regarding claim 8, Balcha and Liu do not teach “wherein the one or more first operations are performed in response to receiving a call to an application programming interface (API) exposed by the first cluster of virtual computing instances.”
(E) Hoang, in the context of Balcha and Liu’s teachings, however teaches or suggests implementing:
“wherein the one or more first operations are performed in response to receiving a call to an application programming interface (API) exposed by the first cluster of virtual computing instances”
(¶ 31: Within the control plane is an API server that allows a user to configure many of Kubernetes' workloads and organizational units. It also is responsible for making sure that the etcd store (which stores configuration data to be used by the nodes) and the service details of deployed containers are in agreement. It acts as the bridge between various components to maintain cluster health and disseminate information and commands. The API server implements a RESTful interface, which means that many different tools and libraries can readily communicate with it;
¶ 52: FIG. 4, system 400 includes a data management system (e.g., PowerProtect Data Management, PPDM) system 402, that backs up data from Kubernetes cluster 404 to deduplicated back storage 406, which may be a Data Domain, or similar appliance. The Kubernetes cluster 404 includes an API server 406 and a data management (e.g., PPDM) controller 408. Controller 408 listens to the creation event of backup job on API server 406. Upon initiation of a backup job by PPDM 402, the controller 408 detects the creation of backup job on API server 406 and the controller then sends a backup command back to the API server to back up the specified namespace using the metadata migration process 410).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (E) Hoang with those of (A) Balcha and (B) Liu to implement an API server (interface) within a pod cluster. The motivation or advantage to do so is to provide for a communications interface between the cluster controlling/management services and cluster administrators.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
(a) WANG et al., US 2024/0202077 A1, teaching service cluster instance backup and recovery.
(b) Polimera et al., US 2023/0109510 A1, teaching failover orchestration jobs that invoke recovery resources on demand in a cloud computing environment.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN C WU whose telephone number is (571)270-5906. The examiner can normally be reached Monday through Friday, 8:30 A.M. to 5:00 P.M..
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, Aimee J. Li can be reached on (571)272-4169. 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.
/BENJAMIN C WU/Primary Examiner, Art Unit 2195
August 21, 2026
Prosecution Insights