DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed May 29, 2025 have been fully considered but they are not persuasive.
Applicant argues – “Nowhere does the cited portion indicate that pods are mechanisms for clustering. Kubernetes is generally used to implement VNF instantiation instead of managing the cluster resources of virtual machines. While Kubernetes may invoke cluster resources as part of the container resource infrastructure, this orchestration merely supports the deployment of Kubernetes objects, such as pods, services, and the like.”
Applicant’s language of the claims are not specific to relationship of the cluster to the instantiation of the virtual network functions. The recitation of the cluster instances from the templates encompasses the clustering of a plurality of containers or in the case Hoang a plurality of pods.
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, 6-9, 15-16, 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cong-Phuoc Hoang et al., “an extended Virtual Network Functions Manager Architecture to Support Container” (hereafter referred to as Huang) in view of McKee et al., US 20230229467 A1 (hereafter referred to as McKee).
Claim 1, Hoang teaches a method for use in a container cluster management element (2.2 Kubernetes) method comprising:
generating a container cluster instance based on a container cluster descriptor (CCD) template (Hoang, p. 173, “The Kubernetes cluster is integrated to support launching container- based VNFs and provide high availability for VNFs while TOSCA simple profile is designed to describe container-based VNF templates.” And p. 175, “In the VNFM plugin, the request’s body includes a VNFD template which is then extracted to get VIM’s information and send the request to infra drivers (3).”), wherein the container cluster instance comprises at least one master node and at least one work node (Hoang, p. 175, Table 3), and
transmitting, to a management element, the container cluster instance for use in a life cycle management operation of at least one virtual network function (Hoang, p. 175, “In this case, Kubernetes driver will be used to verify and translate VNFD template to Kubernetes’ objects (4); and then orchestrate the new container-based VNF in Kubernetes cluster (5).”),
wherein the CCD template comprises pod attribute information, wherein the pod attribute information comprises at least one of a cluster name, a pod version or pod resource information (Hoang, p. 174, “When users deploy container-based VNFs, firstly they must prepare and define a VNFD template. The VNFD is a template that describes the compute and network resources of a VNF.” And p. 175, “Users can set detailed policy information for VDUs, which specifies the minimal, maximal of Pod’s replicas, and the CPU utilization percentage. “ And VNFD template, network attribute information = “mapping ports”, “ports”) or image information of the container cluster instance), for efficient management of pod resources for lifecycle (Hoang, p. 173, “Tacker has two main functional blocks, NFV orchestrator (NFVO) for deploying network services and VNFM for managing VNF’s lifecycle.” In Kubernetes the pod is the smallest unit of a cluster, thereby managing the pod resources manages the cluster.).
Hoang teaches containers implemented as pods but does not specifically describe clusters. However, in the same field of endeavor, McKee teaches the Kubernetes pods by clustering (p. 23, “Kubernetes can provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts. A pod in Kubernetes can include a scheduling unit. The pod can add a higher level of abstraction by grouping containerized components.”) and wherein the CCD template comprises cluster attribute information, wherein the cluster attribute information comprises at least one of a cluster name, a version or resource information (McKee, p. 21, “the cluster information may be represented in the form of a cluster blueprint, which may be used to define the cluster specifics including compute, storage and networking and how these are to be assembled to build a complete functional cluster (e.g., Kubernetes or Docker).” And p. 42, “cluster item 400 includes an ID, a name, a blueprintID, … The name may be a string representing a user-assigned name to the cluster and which may be displayed in the catalog …“). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hoang to incorporate cluster attribute information including a cluster name from McKee for the pod attribute information as an equivalent substitution. The motivation would have been to incorporate clusters as defined by a blueprint and thereby formulate the instantiate clusters for the VNFs.
Claim 2, Hoang-McKee teaches the method of claim 1, further comprising:
receiving a cluster generation request of generating the container cluster instance from at least one of the management element (Hoang, 3.2 The procedures of container based-based
VNF creation, p. 174), an operation support system (OSS) or a third party, wherein the cluster generation request comprises an identification of the CCD template (Hoang, p. 175, “For creating a VNF, the request is transferred to VNFM plugin (2). In the VNFM plugin, the request’s body includes a VNFD template which is then extracted to get VIM’s information and send the request to infra drivers”), or
receiving a request for a management of the container cluster instance, wherein the request for the management of the container cluster instance is received from the management element (alternative step), wherein the method further comprises:
transmitting, to the OSS (combination with Hoang where deploy thru OSS), a request for generating the container cluster instance (McKee, p. 26, “CaaS administrator 101 and CaaS users 102 may make use of the container SaaS portal 130 to perform various life-cycle management (LCM) operations relating to clusters (e.g., Kubernetes or Docker) that are based on the infrastructure 110, which may include physical and/or virtual infrastructure…”), and
receiving, from the OSS (combination with Hoang where deploy thru OSS), an agreement response comprising the CCD template or an identification of the CCD template (McKee, p. 26, “The status of cluster LCM operations may be tracked…”).
Claim 3, Hoang-McKee teaches the method of claim 1, wherein the container cluster instance is generated by:
requesting for allocating at least one of computing resources, storage resource or network resources for the at least one master node and at least one work node based on the CCD template (Hoang, p. 175, “In our design, Tacker can also provide scaling policies for container-based VNFs depending on CPU utilization, as depicted in the figure 3. Users can set detailed policy information for VDUs, which specifies the minimal, maximal of Pod’s replicas, and the CPU utilization percentage.” Table 3),
deploying, based on the CCD template, the at least one master node as at least one container infrastructure service manager (Hoang, p. 174, “instead of creating a new VNFM for managing container-based VNFs as current works, we just add new infrastructure drivers for container in Tacker. By doing this way, we can use one unified VNFM to manage both container-based and VM-based VNFs. “ “Through Kubernetes and OpenStack drivers in VNFM, Tacker can send requests to Kubernetes and OpenStack VIMs to respectively create resources such as VNFs and NSs. Kubernetes and OpenStack can be deployed on different or the same VMs or bare-metal machines.”), and
deploying, based on the CCD template (Hoang, p. 175, “In the VNFM plugin, the request’s body includes a VNFD template which is then extracted to get VIM’s information and send the request to infra drivers (3). For Kubernetes as shown in Fig.1, Tacker checks the VIM’s type to send to the right infrastructure plugin (OpenStack or Kubernetes). In this case, Kubernetes driver will be used to verify and translate VNFD template to Kubernetes’ objects (4); and then orchestrate the new container-based VNF in Kubernetes cluster (5).”), the at least one work node as at least one container infrastructure service instance (Hoang, p. 175, Table 3).
Claim 4, Hoang-McKee teaches the method of claim 1, further comprising:
receiving a request of CCD template on-boarding from at least one of the management element (Hoang, p. 175, “we define a TOSCA template for VNF and launch it on Kubernetes VIM. In the figure 3, we set the container-based VNF with one VDU ... We support scaling by setting the scaling range for VDU’s pod replicas from one to three.”), an operation support system (OSS), or a third party,
receiving the CCD template from at least one of the management element, the OSS or the third party (Hoang, p. 173, “The lifecycle of VNFs and network services (NSs) can be provided and managed by NFV management and orchestration (MANO) framework, like Tacker.”), and
transmitting an identification of the received CCD template to at least one of the management element, the OSS or the third party (Hoang, p. 173, “Tacker uses simple TOSCA NFV profile as the deployment template such as VNF Descriptor (VNFD) and Network Service Descriptor (NSD) to define network services.” And p. 175, “In Fig. 2, Tacker API server receives the VNF creation request (1) from users, Tacker depends on request’s URL to transfer request to the right plugin for processing user’s demand.”).
Claim 6, Hoang teaches a method for use in a management element, the method comprising:
receiving, from a container cluster management (CCM) element, a container cluster instance for use in a life cycle management operation of at least one virtual network function (Hoang, p. 174, “Kubernetes driver is added to VNFM functional block of Tacker as infrastructure driver for communicating to Kubernetes cluster. In our design, instead of creating a new VNFM for managing container-based VNFs as current works, we just add new infrastructure drivers for container in Tacker. By doing this way, we can use one unified VNFM to manage both container-based and VM-based VNFs.” And p. 173, “Tacker has two main
functional blocks, NFV orchestrator (NFVO) for deploying network services and VNFM for managing VNF’s lifecycle.”),
wherein the container cluster instance is generated based on a container cluster descriptor (CCD) template (Hoang, p. 175, “Kubernetes driver will be used to verify and translate VNFD template to Kubernetes’ objects (4); and then orchestrate the new container- based VNF in Kubernetes cluster (5).”) and comprises at least one master node and at least one work node (Hoang, p. 175, Table 3),
wherein the cluster attribute information comprises at least one of a pod name, a pod version or pod resource information (Hoang, p. 175, “In our design, Tacker can also provide scaling policies for container-based VNFs depending on CPU utilization, as depicted in the figure 3. Users can set detailed policy information for VDUs, which specifies the minimal, maximal of Pod’s replicas, and the CPU utilization percentage.”), for efficient management of pod resources for the life cycle management operation (p. 173, “Tacker has two main functional blocks, NFV orchestrator (NFVO) for deploying network services and VNFM for managing VNF’s lifecycle.”). Hoang teaches containers implemented as pods but does not specifically describe clusters. However, in the same field of endeavor, McKee teaches the Kubernetes pods by clustering (p. 23, “Kubernetes can provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts. A pod in Kubernetes can include a scheduling unit. The pod can add a higher level of abstraction by grouping containerized components.”) and wherein the CCD template comprises cluster attribute information, wherein the cluster attribute information comprises at least one of a cluster name, a version or resource information (McKee, p. 21, “the cluster information may be represented in the form of a cluster blueprint, which may be used to define the cluster specifics including compute, storage and networking and how these are to be assembled to build a complete functional cluster (e.g., Kubernetes or Docker).” And p. 42, “cluster item 400 includes an ID, a name, a blueprintID, … The name may be a string representing a user-assigned name to the cluster and which may be displayed in the catalog …“). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hoang to incorporate cluster attribute information including a cluster name from McKee for the pod attribute information as an equivalent substitution. The motivation would have been to incorporate clusters as defined by a blueprint and thereby formulate the instantiate clusters for the VNFs.
Claim 7, Hoang-McKee teaches the method of claim 6, further comprising:
transmitting, to the CCM element, a cluster generation request of generating the container cluster instance, wherein the cluster generation request comprises an identification of the CCD template (Hoang, p. 173, “Tacker uses simple TOSCA NFV profile as the deployment template such as VNF Descriptor (VNFD) and Network Service Descriptor (NSD) to define network services.” And p. 175, “In Fig. 2, Tacker API server receives the VNF creation request (1) from users, Tacker depends on request’s URL to transfer request to the right plugin for processing user’s demand.”), wherein the method further comprises:
transmitting, to the CCM element, a request for a management of the container cluster instance (Hoang, p. 175, “Once the number of pods increases, we also need load balancers to route traffics to all pods, thus the service object also is added to described VDU nodes.” “Tacker can also provide scaling policies for container-based VNFs depending on CPU utilization, as depicted in the figure 3.”).
Claim 8, Hoang-McKee teaches the method of claim 6, further comprising:
allocating at least one of computing resources, storage resource or network resources for the at least one master node and at least one work node based on the CCD template (Hoang, p. 175, “In our design, Tacker can also provide scaling policies for container-based VNFs depending on CPU utilization, as depicted in the figure 3. Users can set detailed policy information for VDUs, which specifies the minimal, maximal of Pod’s replicas, and the CPU utilization percentage.” Table 3) (McKee, p. 43, “The blueprint item 500 may declaratively describe the desired cluster, for example, including master and worker node sizes, amounts, and quality attributes (e.g., availability and performance).”).
Claim 9, Hoang-McKee teaches the method of claim 6, further comprising: transmitting, to the CCM element, a request of CCD template on-boarding (Hoang, p. 175, “In Fig. 2, Tacker API server receives the VNF creation request (1) from users, Tacker depends on request’s URL to transfer request to the right plugin for processing user’s demand.”), transmitting, to the CCM element, the CCD template (Hoang, p. 173, “Tacker uses simple TOSCA NFV profile as the deployment template such as VNF Descriptor (VNFD) and Network Service Descriptor (NSD) to define network services.”), and receiving, from the CCM element, an identification of the transmitted CCD template (Hoang, p. 175, “In the VNFM plugin, the request’s body includes a VNFD template which is then extracted to get VIM’s information and send the request to infra drivers (3).”).
Claim(s) 1-4, 6-9, 15-16, 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cong-Phuoc Hoang et al., “an extended Virtual Network Functions Manager Architecture to Support Container” (hereafter referred to as Huang) in view of McKee et al., US 20230229467 A1 (hereafter referred to as McKee) further in view of Melkild, USPN 11194609 B1 (hereafter referred to as Melkild).
Claim 11, Hoang teaches a method … , the method comprising:
transmitting, to a container cluster management (CCM) element, a request of a container cluster descriptor (CCD) template on-boarding (Hoang, p. 173, “Tacker uses simple TOSCA NFV profile as the deployment template such as VNF Descriptor (VNFD) and Network Service Descriptor (NSD) to define network services.” And p. 175, “In Fig. 2, Tacker API server receives the VNF creation request (1) from users, Tacker depends on request’s URL to transfer request to the right plugin for processing user’s demand.”), and
transmitting, to the CCM element, a CCD template (Hoang, p. 175, “In this case, Kubernetes driver will be used to verify and translate VNFD template to Kubernetes’ objects (4); and then orchestrate the new container-based VNF in Kubernetes cluster (5).”),
wherein the cluster attribute information comprises a cluster name, a version or resource information (Hoang, p. 175, “In our design, Tacker can also provide scaling policies for container-based VNFs depending on CPU utilization, as depicted in the figure 3. Users can set detailed policy information for VDUs, which specifies the minimal, maximal of Pod’s replicas, and the CPU utilization percentage.”), for efficient management of cluster resources for the life cycle management operation (p. 173, “Tacker has two main functional blocks, NFV orchestrator (NFVO) for deploying network services and VNFM for managing VNF’s lifecycle.”).
Hoang teaches containers implemented as pods but does not specifically describe clusters. However, in the same field of endeavor, McKee teaches the Kubernetes pods by clustering (p. 23, “Kubernetes can provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts. A pod in Kubernetes can include a scheduling unit. The pod can add a higher level of abstraction by grouping containerized components.”) and wherein the CCD template comprises cluster attribute information, wherein the cluster attribute information comprises at least one of a cluster name, a version or resource information (McKee, p. 21, “the cluster information may be represented in the form of a cluster blueprint, which may be used to define the cluster specifics including compute, storage and networking and how these are to be assembled to build a complete functional cluster (e.g., Kubernetes or Docker).” And p. 42, “cluster item 400 includes an ID, a name, a blueprintID, … The name may be a string representing a user-assigned name to the cluster and which may be displayed in the catalog …“). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hoang to incorporate cluster attribute information including a cluster name from McKee for the pod attribute information as an equivalent substitution. The motivation would have been to incorporate clusters as defined by a blueprint and thereby formulate the instantiate clusters for the VNFs.
Hoang-McKee does not specifically teach a method of OSS. However, in the same field of endeavor Melkild teaches a method of OSS (column 4, lines 43-49; “the MANO module 108 may be supplied a set of Network Service Descriptors (NSDs) 110, each of which is a set of metadata that describe the relationship between services, VNFs and any underlying infrastructure requirements. The NSDs and VNF packages 110 are owned by and stored in the OSS/BSS 102, but are used to interwork with the MANO module 108.”). It would have obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hoang-McKee to incorporate using in OSS from Melkild to complete using the container as a service orchestration implementation of Hoang-McKee and thereby provide robust orchestration of MANO.
Claim 12, Hoang-McKee-Melkild teaches the method of claim 11, further comprising:
generating the CCD template based on requirement information of a virtual network function (Hoang, p. 173, “Tacker uses simple TOSCA NFV profile as the deployment template such as VNF Descriptor (VNFD) and Network Service Descriptor (NSD) to define network services.”) and comprises at least one master node and at least one work node (Hoang, p. 175, Table 3)(McKee, p. 43, “The blueprint item 500 may declaratively describe the desired cluster, for example, including master and worker node sizes, amounts, and quality attributes (e.g., availability and performance).”), or receiving, from a third party, the CCD template (alternative limitation).
Claim 13, Hoang-McKee-Melkild teaches the method of claim 11, further comprising:
receiving, from the CCM element, an identification of the transmitted CCD template (Hoang, p. 173, “Tacker uses simple TOSCA NFV profile as the deployment template such as VNF Descriptor (VNFD) and Network Service Descriptor (NSD) to define network services.”).
Claim 15, Hoang teaches a method for use in a network management system, the method comprising:
transmitting, to a container cluster management (CCM) element, a cluster generation request of generating a container cluster instance based on a container cluster descriptor (CCD) template (Hoang, p. 173, “Tacker uses simple TOSCA NFV profile as the deployment template such as VNF Descriptor (VNFD) and Network Service Descriptor (NSD) to define network services.” And p. 175, “In Fig. 2, Tacker API server receives the VNF creation request (1) from users, Tacker depends on request’s URL to transfer request to the right plugin for processing user’s demand.”),
wherein the CCD template comprises at least one of cluster attribute information, master node attribute information, work node attribute information, network attribute information or image information of the pod cluster instance, and wherein the cluster attribute information comprises at least one of a cluster name, a version or resource information, for efficient management of pod resources for a life cycle management operation. Hoang teaches containers implemented as pods but does not specifically describe clusters. However, in the same field of endeavor, McKee teaches the Kubernetes pods by clustering (p. 23, “Kubernetes can provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts. A pod in Kubernetes can include a scheduling unit. The pod can add a higher level of abstraction by grouping containerized components.”) and wherein the CCD template comprises cluster attribute information, wherein the cluster attribute information comprises at least one of a cluster name, a version or resource information (McKee, p. 21, “the cluster information may be represented in the form of a cluster blueprint, which may be used to define the cluster specifics including compute, storage and networking and how these are to be assembled to build a complete functional cluster (e.g., Kubernetes or Docker).” And p. 42, “cluster item 400 includes an ID, a name, a blueprintID, … The name may be a string representing a user-assigned name to the cluster and which may be displayed in the catalog …“). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hoang to incorporate cluster attribute information including a cluster name from McKee for the pod attribute information as an equivalent substitution. The motivation would have been to incorporate clusters as defined by a blueprint and thereby formulate the instantiate clusters for the VNFs.
Claim 16, Hoang-McKee teaches the method of claim 15, wherein the cluster generation request comprises an identification of the CCD template (McKee, p. 21, “the cluster information may be represented in the form of a cluster blueprint, which may be used to define the cluster specifics including compute, storage and networking and how these are to be assembled to build a complete functional cluster (e.g., Kubernetes or Docker).” And p. 42, “cluster item 400 includes an ID, a name, a blueprintID, … The name may be a string representing a user-assigned name to the cluster and which may be displayed in the catalog …“).
Claim 18, Hoang teaches a method for use in network management systems, the method comprising:
receiving, from a container cluster management (CCM) element, a request for generating a container cluster instance (Hoang, p. 173, “Tacker uses simple TOSCA NFV profile as the deployment template such as VNF Descriptor (VNFD) and Network Service Descriptor (NSD) to define network services.” And p. 175, “In Fig. 2, Tacker API server receives the VNF creation request (1) from users, Tacker depends on request’s URL to transfer request to the right plugin for processing user’s demand.”), and
transmitting, to the CCM element, an agreement response comprising the CCD template or an identification of the CCD template (Hoang, p. 175, “In Fig. 2, Tacker API server receives the VNF creation request (1) from users, Tacker depends on request’s URL to transfer request to the right plugin for processing user’s demand.”),
wherein the cluster attribute information comprises at least one of a cluster name, a pod version or pod resource information (Hoang, p. 175, “In our design, Tacker can also provide scaling policies for container-based VNFs depending on CPU utilization, as depicted in the figure 3. Users can set detailed policy information for VDUs, which specifies the minimal, maximal of Pod’s replicas, and the CPU utilization percentage.”), for efficient management of cluster resources for the life cycle management operation (p. 173, “Tacker has two main functional blocks, NFV orchestrator (NFVO) for deploying network services and VNFM for managing VNF’s lifecycle.”). However, in the same field of endeavor, McKee teaches wherein the CCD template comprises cluster attribute information, wherein the cluster attribute information comprises at least one of a cluster name, a version or resource information (McKee, p. 21, “the cluster information may be represented in the form of a cluster blueprint, which may be used to define the cluster specifics including compute, storage and networking and how these are to be assembled to build a complete functional cluster (e.g., Kubernetes or Docker).” And p. 42, “cluster item 400 includes an ID, a name, a blueprintID, … The name may be a string representing a user-assigned name to the cluster and which may be displayed in the catalog …“). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hoang to incorporate cluster attribute information including a cluster name from McKee for the pod attribute information as an equivalent substitution. The motivation would have been to incorporate clusters as defined by a blueprint and thereby formulate the instantiate clusters for the VNFs.
Claim 19, Hoang-McKee teaches the method of claim 18, wherein the request for generating the container cluster instance comprises requirement information of at least one virtual network function (as cited above) and the method further comprises:
generating the CCD template based on the requirement information of the at least one virtual network function, or determining the identification of the CCD template based on the requirement information of the at least one virtual network function (Hoang, p. 173, “Tacker uses simple TOSCA NFV profile as the deployment template such as VNF Descriptor (VNFD) and Network Service Descriptor (NSD) to define network services.” And p. 175, “In Fig. 2, Tacker API server receives the VNF creation request (1) from users, Tacker depends on request’s URL to transfer request to the right plugin for processing user’s demand.”).
Claim(s) 5, 10, 17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hoang and McKee as applied to claims 1, 6, 15, 18 above, and further in view of Feng, WO 2020011214 A1 (hereafter referred to as Feng).
Claims 5 and 10 and 17 and 20, Hoang-McKee teaches wherein the CCD template further comprises at least one of master node attribute information, work node attribute information, network attribute information or image information of the container cluster instance (Hoang, ), wherein the network attribute information comprises at least one of network ports, internet protocol addresses of the at least one master node and the at least one work node (considered an alternative limitation), or network information of connections among the at least one master node and the at least one work node (considered an alternative limitation). Hoang-McKee does not specifically teach wherein the master node attribute information comprises at least one of the number of the at least one master node or deployment flavor information of the at least one master node. However, in the same field of endeavor, Feng teaches wherein the master node attribute information comprises at least one of the number of the at least one master node or deployment flavor information of the at least one master node (Feng, p. 16, “The related information of the nodes that are requested to be added here includes information such as the number of nodes that are requested to be added, the node type, and the performance requirements of the nodes.”),
wherein the deployment flavor information of the at least one master node comprises at least one of configuration information, deployment information or resource information, wherein the work node attribute information comprises at least one of the number of the at least one work node or deployment flavor information of the at least one work node (Feng, p. 16, “The related information of the nodes that are requested to be added here includes information such as the number of nodes that are requested to be added, the node type, and the performance requirements of the nodes.”), wherein the deployment flavor information of the at least one work node comprises at least one of configuration information, deployment information or resource information (Feng, p. 16, “node type”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hoang-McKee to substitute Feng attributes as an equivalent attributes to define in a template and thereby fully enable container cluster deployment.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hoang and McKee and Melkild as applied to claims 11 above, and further in view of Feng, WO 2020011214 A1 (hereafter referred to as Feng).
Claim 14, Hoang-McKee-Melkild teaches wherein the CCD template further comprises at least one of master node attribute information, work node attribute information, network attribute information or image information of the container cluster instance (Hoang, ), wherein the network attribute information comprises at least one of network ports, internet protocol addresses of the at least one master node and the at least one work node (considered an alternative limitation), or network information of connections among the at least one master node and the at least one work node (considered an alternative limitation). Hoang-McKee does not specifically teach wherein the master node attribute information comprises at least one of the number of the at least one master node or deployment flavor information of the at least one master node. However, in the same field of endeavor, Feng teaches wherein the master node attribute information comprises at least one of the number of the at least one master node or deployment flavor information of the at least one master node (Feng, p. 16, “The related information of the nodes that are requested to be added here includes information such as the number of nodes that are requested to be added, the node type, and the performance requirements of the nodes.”),
wherein the deployment flavor information of the at least one master node comprises at least one of configuration information, deployment information or resource information, wherein the work node attribute information comprises at least one of the number of the at least one work node or deployment flavor information of the at least one work node (Feng, p. 16, “The related information of the nodes that are requested to be added here includes information such as the number of nodes that are requested to be added, the node type, and the performance requirements of the nodes.”), wherein the deployment flavor information of the at least one work node comprises at least one of configuration information, deployment information or resource information (Feng, p. 16, “node type”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hoang-McKee to substitute Feng attributes as an equivalent attributes to define in a template and thereby fully enable container cluster deployment.
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.
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 PATRICE L WINDER whose telephone number is (571)272-3935. 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, KAMAL B DIVECHA can be reached at (571)272-5863. 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.
/Patrice L Winder/Primary Examiner, Art Unit 2453