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 Amendment filed on 1/202026, claiming priority based on IN202241073622 dated 12/19/2022, wherein claims 1-20 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites, “…first container orchestration platform offering comprising a managed orchestration offering ….a second container orchestration platform offering comprising an unmanaged orchestration offering…based on the managed orchestration offering and the unmanaged orchestration offering identified…” (emphasis added).
Applicant’s specification states the following:
“…Kubernetes distribution (also referred to herein as a ‘Kubernetes offering’)….simplify management by providing pre-packaged versions of the Kubernetes platform that are easy to install. Such distributions may also offer built-in management tools to provide administrative functionality that is absent from Kubernetes itself, example Kubernetes distributions available today include VMware Tanzu Kubernetes Grid (TKG), Amazon Elastic Kubernetes Service (EKS), Google Kubernetes engine (GKS), Microsoft Azure Kubernetes Service (AKS), Mirantis Kubernetes Engine (MKE), Red Hat Openshift, and project Contour…” [0005]
“aspects herein are described with respect to a migration from a non-VMware TKG cluster (e.g., Amazon EKS, GKS, Microsoft AKS, MKE, red Hat OpenShift, or the like) to a VMware TKG cluster…”[0021] and
“…when migrating Kubernetes workloads from a non-TKG cluster to a TKG cluster….CRD objects associated with the non-TKG cluster may be converted to TKG CRD…” [0023]
Not only does the Specification never explicitly recites a managed orchestration offering and an unmanaged orchestration offering, above portions of Applicant’s specification teaches both the source and destination cluster environments are Kubernetes distributions where each clearly includes administrative/management functionalities, and common and well understood CRD file definition conversion between the different Kubernetes distributions. All exemplary source and destinations are Kubernetes distributions, all of which are known to include CRD support. Thus, the claim limitation cannot be interpreted as either migration between a Kubernetes offering to a non-Kubernetes offering. As applicant admits all exemplary platforms appears to support resource definitions, thus, it can also not be interpreted as migration between a platform with resource definitions and a platform without resource definitions. Moreover, neither such distinction are understood as related to commonly understood meaning of “managed” vs “unmanaged”. The scope of the claim limitation explicitly requires a managed orchestration offering vs an unmanaged orchestration offering. However, the Specification never teach either orchestration offerings, nor meaning of what unmanaged vs managed is, let alone specific basis for determining the difference between the two offerings or how they functionally differ.
Therefore, there is no teaching of, and it is not known or obvious to one of ordinary skill in the art before the effective filing date of the application that the Specification teaches a source orchestration platform with managed orchestration offering and destination orchestration platform with unmanaged orchestration offering.
As for claims 10 and 19, they contain similar defect as claim 1 above. Thus, they are rejected under the same rationales.
As for claims 2-9, 11-18 and 20, they are rejected for failure to cure the defect of claims upon which they depend.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The following claims are unclear and indefinite:
As for claim 1: it is unclear what is meant by “first container orchestration platform offering comprising a managed orchestration offering and….second container orchestration platform offering comprising an unmanaged orchestration offering…” because the Specification does not teach, nor is it well known in the art what are the distinction between the two claimed offerings or any implied functional differences. For the purpose of examination, Examiner assume the claim to mean any logically different virtual hosting platforms.
As for claims 10 and 19, they contain similar defect as claim 1 above. Thus, they are rejected under the same rationales.
As for claims 2-9, 11-18, and 20, they are rejected for failure to cure the defect of the claim upon which they depend.
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 comprising a managed orchestration offering and the destination cluster is provisioned via a second container orchestration platform offering comprising an unmanaged orchestration 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 paragraphs 9 and 29, “…Kubernetes…” teaching each of the cloud environments can be Kubernetes, a well-known container orchestration platform. As noted under 35 USC 112 rejection above, the claim limitation is interpreted as any 2 orchestration platform.);
obtaining a current state of the containerized workloads running on the source cluster based on provider-specific objects created for the source cluster, wherein the provider-specific 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 specific to the first/source environment and not the second environment because it requires transformation to work in the second, thus the snapshot reasonably reads upon the ”provider-specific” aspect.);
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…”), wherein the mutation logic is selected from a plurality of predefined conversion schemas based on the managed orchestration offering and the unmanaged orchestration offering identified in the migration specification (paragraph 45, “…identify environment 110 that resource snapshot 134 was created in and the new environment….that resource snapshot ….is being restored into and application transformer….can select the appropriate transformation from transformation library…”, in view of paragraph 53, “…select the appropriate transformation from transformation library 224 and apply it to resource snapshot…” and paragraph 43, “…transformation library 224 can contain one or more transformations, including the individual pieces of transformations…” Teaching selecting a schema from plurality of different transformation schemas that can be selected based on the source and destination environments determined, where each schema can have multiple operations);
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 resource 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 Kubernetes 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 Kubernetes 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.
Response to Arguments
Applicant's arguments filed on 1/20/2026 have been fully considered but they are not persuasive.
Applicant argues in the Remarks:
Argument I: “…Alpar does not teach migration from a managed orchestration offering to an unmanaged orchestration offering…” (App. Arg. Pg. 12-13).
Argument II: “…Alpar does not disclose the recited mutation logic…Alpar has not been shown to teach or suggest that the mutation logic might be ‘selected from a plurality of predefined conversion schemas based on the managed orchestration offerings and the unmanaged orchestration offering identified in the migration specification, ‘ as claim 1 requires…” (App. Arg. Pg. 13).
Examiner respectfully disagrees for the following reasons:
As for Argument I, see paragraph 13 above. In addition, Examiner note, as 35 USC 112 rejection articulated, the specification does not teach, nor is it obvious what is the meaning of managed orchestration offering vs unmanaged orchestration offering. Indeed, in view of specification description, both source and destination can be similar or different types of underlying virtualization platforms with no predefined amount of distinction between the offerings, nor specific distinctions, and the claim terms are understood as directed to any two logically distinct offerings (i.e., 2 difference instances of offerings that require translation, 2 different versions, 2 different layers, 2 different underlying architecture, or any other distinctions). Here, the Prior Art clearly teaches the translation of resource specification from one offering to another offering. Hence, Applicant’s argument is not persuasive.
As for Argument II, see paragraph 13 above. In addition, Examiner note, Prior art explicitly teaches each transformation is determined based on the source and destination environments and selected from different transformations in the transformation library. Thus, clearly teaches the amended limitation and applicants argument are not persuasive.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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