DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to application filed on 2/9/2023, claiming priority based on IN202241073622 dated 12/19/2022, wherein claims 1-20 are pending.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-2, 4-8, 10-11, 13-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Alpar et al. (US PGPUB 2022/0291859)
As for claim 1, Alpar teaches a method for migrating containerized workloads across different container orchestration platform offerings (Abstract, in view of paragraph 29), the method comprising:
receiving a migration specification for the containerized workloads identifying at least a source cluster [first configuration] where the containerized workloads are currently running and a destination cluster [second environment] where the containerized workloads are to be migrated to (paragraph 56, “…receives a selection of source snapshot …in a first configuration…application transformer 220 can receive the selection…” paragraph 60, “…application transformer 220 receives a selection of the second environment…” teaching the application transformer receiving both the first configuration/environment and second environment for transformation of the configuration file of a workload, in view of paragraph 10 and 11 “… back up their application and restore them to different devices…” and “…restoring an application to a device operating in a different environment….from a first configuration that the resource snapshot was created in to a second configuration for an environment to which the application in the resource snapshot is to be restored….” teaching the system is directed to moving of a currently executing application at a current environment to a destination environment that is different environment than where the application was executing. Paragraph 29, “…resource snapshot 134 can be a cloud resource document or configuration file, or a combination….Kubernetes is a cloud environment…” teaches the workloads can be executing in a cluster environment that runs Kubernetes (i.e., containerized execution)), wherein the source cluster is provisioned via a first container orchestration platform offering and the destination cluster is provisioned via a second container orchestration platform offering (paragraph 25, “…environment 110 can have its own cloud environment. For example, environment 110A can run a MS Windows OS…environment 110B can run a Linux OS…and environment 11C can run Amazon Web Services…110A can run a first version of AWS….environment 110B runs a second version…” teaching the source and destination environments can be directed to different providers/products, builds, etc. in view of paragaraphs 9 and 29, “…Kubernetes…” teaching each of the cloud environments can be Kubernetes, a well-known container orchestration platform.);
obtaining a current state of the containerized workloads running on the source cluster based on objects created for the source cluster, wherein the objects comprise a first object supported by the first orchestration platform offering of the source cluster and not the second orchestration platform offering of the destination cluster (Fig. 5, and paragraph 56, in view of 63, teaching the resource snapshot is a resource state of the workload as it runs on the first environment, where the objects/resource snapshot will subsequently be mutated/transformed into a second configuration for the second environment, thus, it is clear the resource snapshot is supported by the first/source environment and not the second environment because it requires transformation to work in the second);
applying mutation logic to convert the first object to a second object supported by the second orchestration platform offering of the destination cluster (paragraph 63, “….application transformer…applies the transformation to selected resource snapshot…..transform the configuration of resource snapshot…from the first configuration to the second configuration…”);
storing one or more images associated with the containerized workloads on the destination cluster (paragraph 65 and 69, “…where transformation verifier …determines that the transformation succeeded…proceeds to 370…” and “In 370, ….restores resource snapshot 134 based on the second configuration…..can restore, install, or instantiate application 115…”. While the prior art does not explicitly use the word “one or more images associated with the….workload”, the prior art teaches the system can “restore, install, or instantiate application 115”, thus, it would be obvious to a person of ordinary skill in the art before the effective filing date of the application to recognize that restoring, installing, or instantiate the application inevitably requires storing and configuring of the workload/software code representing the workload at the destination, thus, such software code at the second environment/destination is understood as one or more images associated with the workload because doing so allows for execution of workload on a specific system.); and
configuring the containerized workloads at the destination cluster using the second object (paragraph 67, “….based on the second configuration…..restore, install, or instantiate application 115 that is backed up…..in target environment 110 that uses or requires the second configuration….”).
As for claim 2, Alpar also teaches the second object is not supported by the first orchestration platform offering of the source cluster or is further supported by the first orchestration platform offering of the source cluster (paragraph 59 in view of paragraph 1. Examiner note, the claim limitation is directed to all possible outcomes, thus, any outcome reads upon the claim. Moreover, Examiner note, determining of need to translate the resource snapshot is a determining of if it is supported by the first orchestration platform or not (i.e., if the resource snapshot format needed at the destination is the same/different from the first orchestration system). Here, clearly the system determines if the transformation is required to have first orchestration format into a second one, reading on both outcomes claimed).
As for claim 4, Alpar also teaches storing, at the destination cluster, an indication of a number of instances of each of the containerized workloads that are running on the source cluster (paragraph 69. Examiner note, similar to dependent claims below, it is clear the number of instances of containerized workloads can be one or more. Thus, here, the existence of the restource snapshot for a specific application to restore/install/instantiate is functionally an indication of the instance of the containerized workload that is to be restored/install/instantiated.).
As for claim 5, Alpar also teaches storing the indication of the number of instances is based on the migration specification indicating a migration type of a stage migration or a disaster recovery migration (paragraph 69, “…restore, install, instantiate…”).
As for claim 6, Alpar also teaches instantiating one or more instances of each of the containerized workloads on the destination cluster using the stored one or more images, a number of the one or more instances being based on a number of instances of the containerized workloads that are running on the source cluster (paragraph 69. Examiner note the application claims 1 or more instances of each workload, that corresponds to the number of instances of the workload on the source cluster. Thus, it clearly encompasses 1 instance of workload that is subsequently restored, installed, or instantiated in the target environment as taught.).
As for claim 7, Alpar also teaches instantiating the one or more instances of each of the containerized workloads is based on the migration specification indicating a migration type of a copy migration, a dry run migration, or a move migration (paragraph 69, “restore, install, or instantiate application…in target environment 110 that uses or requires the second configuration…”).
As for claim 8, Alpar teaches the migration specification further identifies the containerized workloads for migration based on an identification of a namespace on the source cluster where the containerized workloads are running (paragraph 16, “…transformation …require replacing portions of path or value labels …” teaching the move of the workload from source cluster to destination includes identifying paths (i.e., name space) of the workload in the source cluster).
As for claims 10-11, 13-17, they contain similar limitations as claims 1-2, 4-8 above. Thus, they are rejected under the same rationales.
As for claim 19, it contain similar limitations as claim 1 above. Thus, it is rejected under the same rationales.
Claim(s) 3, 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Alpar et al. (US PGPUB 2022/0291859), in view of Dornemann et al. (US PGPUB 2021/0157628).
As for claim 3, Alpar does not explicitly teach a third object supported by both the first and second cluster and use the third object to convert to a object understood by the destination.
However, Dornemann teaches a known method of virtualized workload migration between source and destination nodes running different virtualization platforms (Abstract and paragraph 241) including the objects created for the source cluster further comprise a third object supported by both the first virtualization platform offering of the source cluster and the second virtualization platform offering of the destination cluster (paragraph 60, “….hypervisor-independent format, one or more configuration parameters…” Here, examiner note the hypervisor-independent format is created on the source node, thus, constructively supported by the first virtualization platform, and manipulatable by the destination node as well, thus, also supported by the destination node. See, e.g., paragraph 361.); and the mutation logic to convert the third object to a fourth object supported by the second orchestration platform offering of the destination cluster and not the first orchestration platform offering of the source cluster (paragraph 361, “…converts the one or more configuration parameters from the hypervisor-independent format obtained from the first full back up copy into a format suitable for the second…” In addition, Examiner note, as claimed, if the third object is supported by both the first and second virtualization platform, the conversion of the object to a fourth one that is only understood by the second platform make no logical sense and is a gratuitous step with no functional benefit to the migration process. Thus, for the purpose of examination, examiner understood the 3rd object as a platform independent format that can be operated on at the source and destination.). This known technique is applicable to the system of Alpar as they both share characteristics and capabilities, namely, they are directed to migration of /moving of virtualized workloads from source node to destination node on different virtualization platforms.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Dornemann would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Dornemann to the teachings of Alpar would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtualized workload execution features into similar systems. Further, applying third object that is understood by both first and second virtualization platforms and mutating the third object to a fourth object understood by the destination virtualization platform to Alpar with source and destination clusters running virtualized workloads in containers where source and destination clusters comprise different virtualization platforms accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved speed to restore operation of a virtualized workload in a different platform. (Dornemann, paragraph 5-6)
As for claims 12 and 20, they contain similar limitations as claim 3 above. Thus, they are rejected under the same rationales.
Claim(s) 9 are rejected under 35 U.S.C. 103 as being unpatentable over Alpar et al. (US PGPUB 2022/0291859), in view of Kumatagi et al. (US PGPUB 2020/0356397)
As for claim 9, while it is known in the art that Kubernetes containers as disclosed in Alpar runs in pods. Nevertheless, in the interest of compact prosecution, Examiner note Alpar does not explicitly teach the environments include containers implemented in PODS explicitly.
However, Kumatagi teaches a known method of migration/moving of container from source to destination including the source cluster is running on a first site that is a set of one or more first containers of one or more first pods running on one or more first nodes and the destination cluster is running on a second site that is a set of one or more second containers of one or more second pods running on one or more second nodes (paragraph 76, “….provides ability to freeze…running container in a source and restore the container in a destination…” and paragraph 63, “In Kubernetes, …containers run in a pod…”) This known technique is applicable to the system of Alpar as they both share characteristics and capabilities, namely, they are directed to migration of moving of containers from source node to destination node where containers runs in kubernete orchestration systems.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Kumatagi would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Kumatagi to the teachings of Alpar would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such container based workload execution features into similar systems. Further, applying the source cluster is running on a first site that is a set of one or more first containers of one or more first pods running on one or more first nodes and the destination cluster is running on a second site that is a set of one or more second containers of one or more second pods running on one or more second nodes to Alpar with source and destination clusters running containers in Kubernete container orchestrators accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved ability to migrate containerized workloads in response to detected issues. (Kumatagi, paragraph 1)
As for claim 18, it contain similar limitations as claim 9 above. Thus, it is rejected under the same rationales.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached M-F 10am-6pm.
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, Lewis Bullock can be reached on 5712723759. 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.
/KEVIN X LU/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights