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 .
Information Disclosure Statement
The IDS filed on 7/31/2025 has been considered.
Response to Amendment
The amendment filed on 9/30/2025 has been entered. Claims 1-14 and 16-21 remain pending in this application. Applicant’s amendments to claim 21 have overcome the 35 U.S.C. § 101 non-statutory subject matter rejection previously set forth in the Non-Final Office Action; therefore, Examiner withdraws the 35 U.S.C. § 101 non-statutory subject matter rejection of claim 21. Applicant’s amendments to claims 1 and 14 have overcome the 35 U.S.C. § 101 non-statutory subject matter rejection previously set forth in the Non-Final Office Action; therefore, Examiner withdraws the 35 U.S.C. § 101 non-statutory subject matter rejection of claims 1-14 and 16-20.
Claim Objections
Claim 5 is objected to because of the following informalities: The claim recites "wherein the second workload is configured to provide telephony functionality and the first workload is net configured to provide a different functionality." The underlined term appears to an unintended amendment to the claim. Appropriate correction is required.
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-14 and 16-21 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.
Claims 1, 14, and 21 recite the limitation “using one or more manager pods of the first workload environment to propagate the first lifecycle management state to the second workload, the one or more manager pods mapped to units of the second workload environment that manage the second workload.” The underlined portion above indicates that the manager pods are mapped to “units” in the second workload environment, and those “units” manage the second workload. In other words, the second workload environment has native manager “units” that manage the workloads within the second workload environment, and the manager pods of the first workload environment are in communication with/mapped to these native manager “units” of the second workload environment. This structure and functionality is not present in the specification and directly contradicts Fig. 7 which shows no manager “units” in the VM (second workload) environment. Thus, the underlined portion above constitutes new matter under 35 U.S.C. § 112(a).
Claims 2-13 and 16-20 are dependent claims of claims 1 and 14, respectively, so, they are rejected for similar reasons.
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 6-10 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.
Claim 6 recites “wherein the first workload environment comprises an additional workload configured to provide telephony functionality.” Claim 7 then recites “wherein the additional workload is configured to perform lifecycle management in relation to the second workload.” How can a workload be configured to provide telephony functionality and perform lifecycle management? It appears that claim 6 and claim 7 are referencing two distinct workloads, one that provides telephony functionality and one that performs lifecycle management.
Claims 8-10 are dependent claims of claims 6 and 7, so they are rejected for similar reasons.
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, 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-4, 11-12, 14, 16, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson et al. (US Patent No. 9,645,852 B2 hereinafter Anderson) in view of McLaughlin et al. (US Pub. No. 2020/0401116 A1 hereinafter McLaughlin) in view of Singh et al. (US Patent No. 9,256,467 B1 hereinafter Singh) in view of Shukla (US Pub. No. 2021/0203681 A1).
As per claim 1, Anderson teaches a method of performing lifecycle management in a data processing system (See Abstract), the method comprising: instantiating a first workload in a first workload environment executing in the data processing system (Col. 2 & 3, lines 59-67 & 1-14, “The set of workloads may include an original workload running on an original computer environment. The original computer environment may be a private cloud…The method and system may work on a number of devices and operating systems.” See also Col. 8, lines 6-36.); wherein the second workload is instantiated in a second, different workload environment executing in the data processing system (Col. 2 & 3, lines 59-67 & 1-14, “Aspects of the present disclosure include establishing a shadow workload on a shadow computer environment, wherein the shadow workload is a copy of the original workload. Establishing the shadow workload on the shadow computer environment may include assigning, to a set of cloud nodes of the shadow computer environment, a workload resource usage estimation.” See also Col. 8, lines 6-36.).
Although Anderson does teach the first and second workloads exchanging information with each other, Anderson fails to explicitly teach the first and second workloads aligning their respective states.
However, McLaughlin teaches using a first container to align a first lifecycle management state of the first container and a second lifecycle management state of a second container (¶ [0060], “In the redundancy relationships, the redundancy has an initial synchronization as to the initial state of the containers and subsequently, any changes that happen as the control is being executed are sent from the primary to the secondary container so that the secondary container continually has an up-to-date state so if the primary fails the secondary can immediately take over and become the new primary.”).
Anderson and McLaughlin are considered to be analogous to the claimed invention because they are in the same field of managing virtual environments. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the workload managing method of Anderson with the state synchronization functionality of McLaughlin to arrive at the claimed invention. The motivation to modify Anderson with the teachings of McLaughlin is that synchronizing states across workloads can be useful in detecting and remediating problems among workloads.
Although Anderson and McLaughlin teach using containers to align the lifecycle states across different workloads. They fail to teach a manager pod being responsible for propagating the lifecycle management states to a second workload.
Accordingly, Singh teaches using one or more manager pods of the first workload environment to propagate the first lifecycle management state to the second workload (Col. 13 & 14, lines 51-67 & 1-38, “The container agents 222 may be software applications configured to run in instances owned by the customers 202 and may act as an interface between their respective container instances 218 and other services and entities, such as the container manager backend services 214. For examples, the container agents 222 may act as intermediaries between the running tasks of their respective container instances 218 and other entities and services such that all communication to or from a container passes through the container agent…This may allow changes to be made to the particular container encapsulation system without requiring updates to be made to the tasks or task definitions; i.e., only the container agents 222 may need to be updated to reflect the changes to the particular encapsulation system…The container agent may, itself, be a container configured to monitor its respective container instance and may provide information to the system usable to launch containers, track containers, and monitor cluster state. The container agent may also perform functions of registering and deregistering its respective container instance, starting and stopping tasks within its respective container instance…The container agents 222 may be configured to monitor the health of the containers within the respective container instances 218 (e.g., report heartbeats signaling that the container instance is operating, report lifespans of containers, and report container statuses and occurrences of container errors), and may further be configured to perform actions based on the occurrence of certain events. For example, if a container agent detects that a container has encountered an error and ceased operation, the container agent may automatically cause a new container to be generated to replace the malfunctioning container.” Col. 14, lines 54-63, “The container agent 222 may register or deregister container instances 218, receive instructions from the container manager backend services 214, and ensure that a telemetry agent 224 has been started and is running. The container agent 222 may also enable updates to containers in the container instances 218 and monitor the state of containers running in the container instances 218 via an event stream.”).
Anderson, McLaughlin, and Singh are all considered to be analogous to the claimed invention because they are all in the same field of managing virtual environments. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the workload managing method of Anderson and McLaughlin with the container agents/manager pods of Singh to arrive at the claimed invention. The motivation to modify Anderson and McLaughlin with the teachings of Singh is that having container agents/manager pods being responsible for managing the health and lifecycles of workloads allows for automated, efficient, and optimized creation, healing, starting, stopping, etc. of workloads without the need for a system administrator.
It is necessary to bring in an additional reference showing the relationship between workloads and containers in order to clarify the above combination of references.
Therefore, Shukla shows the relationship between workloads and containers (¶ [0015], “The workloads may be virtual machines, containers, or any other type of virtualized computer processing component. Likewise, workload orchestration platform 101 handles the configuration of one or more networks, such as logical network 102 and logical network 103, that connect the workloads under workload orchestration platform 101's management.”).
Anderson, McLaughlin, Singh, and Shukla are all considered to be analogous to the claimed invention because they are all in the same field of managing virtual environments. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method for managing workloads of Anderson and McLaughlin with the teachings of Shukla to show that workloads can be implemented using containers. Therefore, McLaughlin’s technique of synchronizing states between containers can be used in Anderson’s workload management environment.
As per claim 4, Anderson, McLaughlin, Singh, and Shukla teach the method of claim 1. Shukla teaches wherein the second workload is a virtual machine (¶ [0015], “The workloads may be virtual machines, containers, or any other type of virtualized computer processing component.”).
As per claim 12, Anderson, McLaughlin, Singh, and Shukla teach the method of claim 1. McLaughlin teaches using the first workload to provide status report data in relation to the second workload (¶ [0045], “For example, the platform would need to provide communication services. The platform would also need to provide schedular services to ensure that the process execution exercising the control functions operates in a real time manner. The platform would need to provide communication services between two or more containers running on the same hardware platform.” ¶ [0050], “The container platforms are part of a high availability management network that connects the set of container platforms together provide the container run times of those platforms. Through the high availability management network, the platforms communicate with one another so that the status of each is known. For example, which containers are running on each specific node and which containers across the nodes are running which specific applications are known. In the event of a failure of one specific node, the remaining container platforms detect the failure through the intercommunication of the container platforms via the high availability management network.” The communication platform allows the containers to communicate with each other and such communication can include a container’s status.).
As per claim 14, it is a system claim comprising similar limitations to claim 1, so it is rejected for similar reasons. Anderson also teaches a processor and memory (Col. 5, lines 46-52, “The components of computer system/server 12 may include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including system memory 28 to processor 16.”).
As per claim 16, Anderson, McLaughlin, Singh, and Shukla teach the system of claim 14. Shukla teaches wherein the first workload environment is a containerized environment (¶ [0015], “The workloads may be virtual machines, containers, or any other type of virtualized computer processing component.”).
As per claim 21, it is a system claim comprising similar limitations to claim 1, so it is rejected for similar reasons. Anderson also teaches a data processing system comprising one or more servers (Col. 5, lines 46-52, “As shown in FIG. 1, computer system/server 12 in cloud computing node 10 is shown in the form of a general-purpose computing device. The components of computer system/server 12 may include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including system memory 28 to processor 16.”).
Claim(s) 2-3 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson, McLaughlin, Singh, and Shukla as applied to claim 1 above, and further in view of Cherunni (US Pub. No. 2020/0412596 A1).
As per claim 2, Anderson, McLaughlin, Singh, and Shukla teach the method of claim 1. Shukla teaches workloads established on a workload orchestration platform (¶ [0015], “The workloads may be virtual machines, containers, or any other type of virtualized computer processing component. Likewise, workload orchestration platform 101 handles the configuration of one or more networks, such as logical network 102 and logical network 103, that connect the workloads under workload orchestration platform 101's management.”).
Anderson, McLaughlin, Singh, and Shukla fail to explicitly teach the workload orchestration platform being Kubernetes.
However, Cherunni teaches wherein the first workload environment is a Kubernetes environment (¶ [0022]-[0023], “The separate platform may include a container management platform. The container management platform may be implemented using Kubernetes… Kubernetes can include an open-source container orchestration system for automating application deployment, scaling, and management. Kubernetes can provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts.” See also Fig. 3.).
Anderson, McLaughlin, Singh, Shukla, and Cherunni are all considered to be analogous to the claimed invention because they are all in the same field of managing virtual environments. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the first workload environment of Anderson, McLaughlin, Singh, and Shukla in a Kubernetes platform as taught by Cherunni.
As per claim 3, Anderson, McLaughlin, Singh, and Shukla teach the method of claim 1.
Anderson, McLaughlin, Singh, and Shukla fail to explicitly teach the first workload performing lifecycle management of the second workload.
However, Cherunni teaches wherein the first workload performs lifecycle management of only the second workload (¶ [0061]-[0065], “The VNFM 314 may manage VNFs 324, that is, the virtualized network elements such as router VNFs, switch VNFs, etc. In some examples, the VNFM 314 may manage the life cycle of the VNFs 324. For example, the VNFM 314 may create, maintain and terminate VNF 324 instances that may be installed on the VMs and which the VIM 316 may create and manage…In some examples, there may be multiple VNFMs 314 managing separate VNFs 324 or there may be one VNFM 314 managing multiple VNFs 324…Also as noted, there may be multiple VNFMs 314 managing their respective VNFs 324…The VNFDs may be used by the VNFM 314 in the process of VNF 324 instantiation and lifecycle management of VNF 324 instances.” The VNFMs are instantiated in a Kubernetes environment (i.e., the first workload environment), and the VNFs are instantiated on VMs or containers (i.e., the second workload). See also Fig. 3.).
Anderson, McLaughlin, Singh, Shukla, and Cherunni are all considered to be analogous to the claimed invention because they are all in the same field of managing virtual environments. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of managing workloads of Anderson, McLaughlin, Singh, and Shukla with the VNFMs that perform lifecycle management of Cherunni to arrive at the claimed invention. The motivation to modify Anderson, McLaughlin, Singh, and Shukla with the teachings of Cherunni is that using a first workload to manage a second workload allows for automated configuration and easy maintaining of the second workload.
Claim(s) 5-6 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson, McLaughlin, Singh, and Shukla as applied to claims 1 and 14 above, and further in view of Cobbold et al. (US Pub. No. 2019/0034233 A1 hereinafter Cobbold).
As per claim 5, Anderson, McLaughlin, Singh, and Shukla teach the method of claim 1. Anderson teaches the first workload is configured to provide a different functionality (Col. 7, lines 50-59, “Examples of workloads and functions which may be provided from this layer include: mapping and navigation; software development and lifecycle management; virtual classroom education delivery; data analytics processing; transaction processing; and workload management.”)
Anderson, McLaughlin, Singh, and Shukla fail to explicitly teach workloads being configured to provide telephony functionality.
However, Cobbold teaches wherein the second workload is configured to provide telephony functionality (¶ [0042], “As described above, a VNF 320 represents a virtualization of specific telecommunication functions that were previously performed by specialized pieces of hardware. Examples of a VNF 320 include, but are not limited to, an SBC, an Internet Protocol (IP) Multimedia Subsystem (IMS) core, and a telephony application server. A VNF 320 may include a number of components, or instances of an application, that run within the virtual machine environment.”).
Anderson, McLaughlin, Singh, Shukla, and Cobbold are all considered to be analogous to the claimed invention because they are all in the same field of managing virtual environments. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Anderson, McLaughlin, Singh, and Shukla with the teachings of Cobbold to show that virtual environment are able to support telephony functionality.
As per claim 6, Anderson, McLaughlin, Singh, and Shukla teach the method of claim 1.
Anderson, McLaughlin, Singh, and Shukla fail to explicitly teach workloads being configured to provide telephony functionality.
However, Cobbold teaches wherein the first workload environment comprises another workload configured to provide telephony functionality (¶ [0042], “As described above, a VNF 320 represents a virtualization of specific telecommunication functions that were previously performed by specialized pieces of hardware. Examples of a VNF 320 include, but are not limited to, an SBC, an Internet Protocol (IP) Multimedia Subsystem (IMS) core, and a telephony application server. A VNF 320 may include a number of components, or instances of an application, that run within the virtual machine environment.”).
Refer to claim 5 for motivation to combine.
As per claim 17, it is a system claim comprising similar limitations to claim 5, so it is rejected for similar reasons.
As per claim 18, it is a system claim comprising similar limitations to claim 6, so it is rejected for similar reasons.
Claim(s) 7 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson, McLaughlin, Singh, Shukla, and Cobbold as applied to claim 6 above, and further in view of Cherunni.
As per claim 7, Anderson, McLaughlin, Singh, Shukla, and Cobbold teach the method of claim 6.
Anderson, McLaughlin, Singh, Shukla, and Cobbold fail to explicitly teach the workload performing lifecycle management.
However, Cherunni teaches wherein the other workload is configured to perform lifecycle management in relation to the second workload (¶ [0061]-[0065], “The VNFM 314 may manage VNFs 324, that is, the virtualized network elements such as router VNFs, switch VNFs, etc. In some examples, the VNFM 314 may manage the life cycle of the VNFs 324. For example, the VNFM 314 may create, maintain and terminate VNF 324 instances that may be installed on the VMs and which the VIM 316 may create and manage…In some examples, there may be multiple VNFMs 314 managing separate VNFs 324 or there may be one VNFM 314 managing multiple VNFs 324…Also as noted, there may be multiple VNFMs 314 managing their respective VNFs 324…The VNFDs may be used by the VNFM 314 in the process of VNF 324 instantiation and lifecycle management of VNF 324 instances.” The VNFMs are instantiated in a Kubernetes environment (i.e., the first workload environment), and the VNFs are instantiated on VMs or containers (i.e., the second workload). See also Fig. 3.).
Anderson, McLaughlin, Singh, Shukla, and Cherunni are all considered to be analogous to the claimed invention because they are all in the same field of managing virtual environments. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of managing workloads of Anderson, McLaughlin, Singh, Shukla, and Cobbold with the VNFMs that perform lifecycle management of Cherunni to arrive at the claimed invention. The motivation to modify Anderson, McLaughlin, Singh, Shukla, and Cobbold with the teachings of Cherunni is that using a first workload to manage a second workload allows for automated configuration and easy maintaining of the second workload.
As per claim 19, it is a system claim comprising similar limitations to claim 7, so it is rejected for similar reasons.
As per claim 20, Anderson, McLaughlin, Singh, Shukla, Cobbold, and Cherunni teach the system of claim 19. Anderson teaches the other workload is configured to perform lifecycle management in relation to a further workload in the second workload environment (¶ [0061]-[0065], “The VNFM 314 may manage VNFs 324, that is, the virtualized network elements such as router VNFs, switch VNFs, etc. In some examples, the VNFM 314 may manage the life cycle of the VNFs 324. For example, the VNFM 314 may create, maintain and terminate VNF 324 instances that may be installed on the VMs and which the VIM 316 may create and manage…In some examples, there may be multiple VNFMs 314 managing separate VNFs 324 or there may be one VNFM 314 managing multiple VNFs 324…Also as noted, there may be multiple VNFMs 314 managing their respective VNFs 324…The VNFDs may be used by the VNFM 314 in the process of VNF 324 instantiation and lifecycle management of VNF 324 instances.” The VNFMs are instantiated in a Kubernetes environment (i.e., the first workload environment), and the VNFs are instantiated on VMs or containers (i.e., the second workload). See also Fig. 3.).
Claim(s) 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson, McLaughlin, Singh, Shukla, Cobbold, and Cherunni as applied to claim 7 above, and further in view of Toeroe (US Provisional App. # 62/939,954).
As per claim 8, Anderson, McLaughlin, Singh, Shukla, Cobbold, and Cherunni teach the method of claim 7. Cherunni teaches wherein the lifecycle management performed by the other workload comprises causing the second workload to be deleted comprising the first workload no longer being used to perform lifecycle management in relation to the second workload (¶ [0061]-[0062], “For example, the VNFM 314 may create, maintain and terminate VNF 324 instances that may be installed on the VMs and which the VIM 316 may create and manage…The VNFM 314 may provide for the fault, configuration, accounting, performance and security (“FCAPS”) management of the VNFs 324. Moreover, the VNFM 314 may scale up or scale down the VNFs 324 which may result in scaling up and scaling down of corresponding resource usage (for example, CPU usage). In some examples, there may be multiple VNFMs 314 managing separate VNFs 324 or there may be one VNFM 314 managing multiple VNFs 324.” VNFMs are able to delete VNFs when necessary. If a VNFM is only managing one VNF and deletes said VNF, then the VNFM is no longer performing lifecycle management of the VNF.).
Anderson, McLaughlin, Singh, Shukla, Cobbold, and Cherunni fail to explicitly teach deleting one workload causes the deletion of another.
However, Toeroe teaches a well-known technique of the second workload being deleted in response to a deletion condition comprising the first workload no longer being used (Pg. 7, lines 1-9, “Instantiating the target VNF may in other words be performed to temporarily scale out the source VNF in the underlying NS (i.e., the NS to which the source VNF belongs) until all traffic is redirected to the target VNF and, afterwards, a scale in operation may be performed to remove the source VNF. Since the source VNFM may not be needed anymore either, the source VNFM may be removed as well.).
Anderson, McLaughlin, Singh, Shukla, Cobbold, Cherunni, and Toeroe are all considered to be analogous to the claimed invention because they are all in the same field of managing virtual environments. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify they method of managing workloads of Anderson, McLaughlin, Singh, Shukla, Cobbold, and Cherunni with the well-known technique of one deletion causing another deletion as taught in Toeroe to arrive at the claimed invention. This modification would have yielded predictable results under MPEP § 2143 because all references deal with managing virtual environments.
As per claim 9, Anderson, McLaughlin, Singh, Shukla, Cobbold, Cherunni, and Toeroe teach the method of claim 8. Cherunni teaches wherein the other workload is configured to perform lifecycle management in relation to a further workload that is in the second workload environment (¶ [0061]-[0062], “For example, the VNFM 314 may create, maintain and terminate VNF 324 instances that may be installed on the VMs and which the VIM 316 may create and manage…The VNFM 314 may provide for the fault, configuration, accounting, performance and security (“FCAPS”) management of the VNFs 324. Moreover, the VNFM 314 may scale up or scale down the VNFs 324 which may result in scaling up and scaling down of corresponding resource usage (for example, CPU usage). In some examples, there may be multiple VNFMs 314 managing separate VNFs 324 or there may be one VNFM 314 managing multiple VNFs 324.”).
As per claim 10, Anderson, McLaughlin, Singh, Shukla, Cobbold, Cherunni, and Toeroe teach the method of claim 9. Cherunni teaches wherein the further workload is in a third workload environment, the third workload environment being different from the first and second environments (¶ [0030], “Containers can be used along with virtual machines in NFV environments. The deployment of VNFs can be virtual machine only, containers only, or hybrid. In the hybrid mode, the container may run in VMs providing security and isolation features. The containers may also be run in a heterogeneous mode where some of VNFs will run in VM, some in containers and mix of both.” Thus, a VNF/workload managed by a Kubernetes platform (i.e., second environment) can be instantiated in a VM (i.e., second environment) or in a container (i.e., a third workload environment).
Claim(s) 11 is rejected under 35 U.S.C. 103 as being unpatentable over Anderson, McLaughlin, Singh, and Shukla as applied to claim 1 above, and further in view of Duggal et al. (US Pub. No. 2019/0052549 A1 *cited in IDS*).
As per claim 11, Anderson, McLaughlin, Singh, and Shukla teach the method of claim 1.
Anderson, McLaughlin, Singh, and Shukla fail to teach the first workload transmitting an authentication token to the second workload environment.
However, Duggal teaches using the first workload to transmit an authentication token to the second workload environment (¶ [0263]-[0293], “In step 2312, an AUTH Token is requested. In some embodiments, a REST request (POST) is sent to the management port of OpenStack to generate a token for all further API interactions with OpenStack. It is parameterized with the login credentials, tenant ID and auth-codes found in the VIM object. In step 2314, the AUTH Token is returned. In some embodiments, the response token is memoized in the EnterpriseWeb Agent so it can be used in future operations.” The management platform (i.e., the first workload environment) transmits an AUTH token to the virtual machine environment (i.e., the second workload environment), and this token is used in order to facilitate secure communication across environments.).
Anderson, McLaughlin, Singh, Shukla, and Duggal are all considered to be analogous to the claimed invention because they are all in the same field of managing virtual environments. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of managing workloads of Anderson, McLaughlin, Singh, and Shukla with the authentication token of Duggal to arrive at the claimed invention. The motivation to modify Anderson, McLaughlin, Singh, and Shukla with the teachings of Duggal is that requiring an authentication token in order to establish communications across different environments ensures secure communication between environments.
Claim(s) 13 is rejected under 35 U.S.C. 103 as being unpatentable over Anderson, McLaughlin, Singh, and Shukla as applied to claim 1 above, and further in view of Corrie (US Pat. No. 11,550,513 B2).
As per claim 13, Anderson, McLaughlin, Singh, and Shukla teach the method of claim 1.
Anderson, McLaughlin, Singh, and Shukla fail to explicitly teach lifecycle states relating to creating a workload or readiness of a workload.
However, Corrie teaches wherein the second lifecycle management states relate to one of: creating the second workload; or readiness of the second workload (Col. 5, lines 35-58, “In the embodiments described herein, an image object 108's state may be one of five values: “created,” “resolving,” “fetching,” “ready,” or “failed.” An image object 108 is in the “created” state upon creation in its respective namespace.” Image objects relate to container images.).
Anderson, McLaughlin, Singh, Shukla, and Corrie are all considered to be analogous to the claimed invention because they are all in the same field of managing virtual environments. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of managing workloads of Anderson, McLaughlin, Singh, and Shukla to incorporate the states of Corrie to arrive at the claimed invention.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-14 and 16-21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Applicant has amended the claims with new limitations that change the scope of the claimed invention. Therefore, the amended claims necessitate new rejections, addressed above. The amended claims are not allowable over prior art cited previously along with an additional reference, necessitated by amendment, for reasons indicated above.
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 JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 ET.
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 at (571)272-3759. 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.
/J.D.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199