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 .
Claims 20-38 are now presented for examination.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. The phrase “configured to” is generic functional language that does not represent specific structure and is used in the claim as a functional placeholder for performing the recited operations recited in the claim. Such claim limitations are: “management entity, configured to” (line 2) and “the CCM, configured to” (line 7) in claim 35. Accordingly, the “management entity” and “CCM” limitations are interpreted under 35 U.S.C. 112(f) as means-plus-function limitations.
The specification identifies the management entity as an NFV MANO management entity, such as an NFVO or VNFM ([0076]), implemented using a processor, memory, and communication interface ([0122]-[0124]) and/or processing and transceiver modules (0110]-[0113]). The corresponding acts for the recited functions are disclosed in Steps 501-503 of Fig. 5.
The specification also identifies the CCM as a container cluster management entity implemented using a processor, memory, and communication interface ([0127]-[0129]). The corresponding act for instantiating the container cluster is in Step 510 of Fig. 5.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claims 20-38 are rejected under 35 U.S.C. 103 as being unpatentable over XIE et al. (hereinafter XIE) (US 2024/0012674 A1) in view of FU et al. (hereinafter FU) (US 2021/0224093 A1).
As to claim 20, XIE teaches a method, comprising:
receiving, by a container cluster manager (CCM) (container cluster management entity, container cluster management, CCM), a first instantiation of a container cluster (container cluster instance or container infrastructure service cluster (CIS Cluster)) from a management entity (container cluster management entity, CCM, operations support system, OSS, etc.), wherein the first instantiation carries an instantiation parameter (deliver the container cluster descriptor (CCD) template, wherein the CCD template is defined for describing all attributes of the container cluster) of the container cluster (the OSS may deliver the CCD template to the CCM; the CCM creates the container cluster instance, e.g., when being requested)(Abstract; [0001]; [0052]; [0055]; [0074]-[0075]; [0092]; Figs 3-8); and
instantiating, by the CCM, the container cluster based on the instantiation parameter (via descriptor attribute/information of CCD template) of the container cluster, wherein the instantiation parameter of the container cluster is determined by the management entity (OSS) by accessing a container cluster descriptor (CCD) (Based on the information described in the CCD template, the CCM creates the container cluster instance) ([0074]-[0075]; Figs 4-8).
XIE does not explicitly teach the request as an “instantiation request message” nor explicitly state that such message carries the instantiation parameter for the CCM to act upon.
However, FU teaches initiating deployment of the first cluster by instantiating the first cluster in a first cluster configuration in accordance with a corresponding first cluster specification ([0006]). FU also teaches that orchestration refers to the coordination of tasks associated with a distributed system, including instantiation ([0018]; Figs 1-6). Therefore, FU’s initiating deployment by instantiating (i.e., an orchestration-issued deployment/instantiation initiation command/message) is equivalent to the claimed “instantiation request message.” FU’s cluster configuration determined from the system composition specification/cluster specification ([0006]) is equivalent to the claimed “instantiation parameter”.
It would have been obvious to one of ordinary skill in the art before the effective date of the application to apply FU’s parameter-determination and instantiation request message abilities to XIE’s descriptor-driven container cluster management. The suggestion/motivation for doing so would have been to provide the predicted result of having instantiation parameters that are clearly derived from the CCD before being provided to the CCM, thereby making deployment, provisioning, and/or management to be less error-prone (FU - [0005]). Introducing an explicit instantiation request message that carries the parameter set to the CCM is a predictable way to make the interface between the management entity and CCM clearer, more repeatable, and less error prone (FU – [0004]-[0005]).
As to claim 21, XIE in view of FU teaches the method according to claim 20, wherein instantiating, by the CCM, the container cluster based on the instantiation parameter of the container cluster comprises (XIE: [0074]-[0075]): obtaining an instantiation parameter (CCD template describes all attributes) of a container cluster node by (XIE: [0074]-[0075]): receiving, by the CCM, a second instantiation request message of a container cluster node from the management entity (XIE: from scaling that includes adding nodes, the scaling request functions as a node-instantiation request; [0095]; [0038]), wherein the second instantiation request message carries the instantiation parameter of the container cluster node (XIE: [0095]), and the instantiation parameter of the container cluster node is determined by the management entity by accessing a container cluster node descriptor (CCND) (FU: [00075]-[0076]); or accessing, by the CCM, the CCND to determine the instantiation parameter of the container cluster node (XIE: [0075]; FU: [0075]-[0076]); and instantiating, by the CCM, the container cluster node based on the instantiation parameter of the container cluster node (XIE – [0075]; [0089]), and instantiating a container infrastructure service management (CISM) instance (master node, etc.) or a container infrastructure service (CIS) instance on the container cluster node (work node, etc.) based on the instantiation parameter of the container cluster (XIE: [0061]; [0070]; [0089]).
As to claim 22, XIE teaches the method according to claim 21, wherein instantiating, by the CCM, the CISM instance and the CIS instance on the container cluster node based on the instantiation parameter of the container cluster comprises: creating, by the CCM, the CISM instance (master node configured as CISM) or the CIS instance (worker node configured as CIS) on the container cluster node ([0073]-[0075]; [0061]; [0070]; [0089]); or creating, by the CCM, the CISM instance on the container cluster node, and further creating, by the CISM instance, the CIS instance on the container cluster node.
As to claim 23, XIE teaches the method according to claim 20, wherein the instantiation parameter of the container cluster comprises one or more of the following: name or identification information of the CCD (an identifier of the CCD template), a size of the container cluster (size is adjusted from an increase/decrease in number of nodes and node resources; runtime information includes node quantity, node resources, etc.), a quantity of container infrastructure service management (CISM) instances and a quantity of container infrastructure service (CIS) instances (the CIS cluster is composed of one CISM instance and one or more CIS instances) created during initialization of the container cluster, or an affinity/anti-affinity rule between the CISM instances, between the CIS instances, and between the CISM instances and the CIS instances in the container cluster ([0070]; [0078]-[0079]; [0092]).
As to claim 24, XIE teaches the method according to claim 21, wherein the instantiation parameter of the container cluster node comprises one or more of the following: name or identification information of the CCND, a type (such as master node or worker node, etc.) of the container cluster node, or an affinity/anti-affinity group to which the container cluster node belongs ([0061]; [0075]).
As to claim 25, it is rejected for the same reasons as stated in the rejection of claim 20. In addition, XIE teaches a communication apparatus, comprising: a transceiver (communication unit 1120 transmits and receives the signals via at least one antenna 1122); at least one processor (processor 1100); and one or more memories (RAM, flash memory, etc.) coupled to the at least one processor and storing programming instructions (program code 1112) for execution by the at least one processor ([0159]; Fig. 11).
As to claim 26, it is rejected for the same reasons as stated in the rejection of claim 21.
As to claim 27, it is rejected for the same reasons as stated in the rejection of claim 22.
As to claim 28, it is rejected for the same reasons as stated in the rejection of claim 23.
As to claim 29, it is rejected for the same reasons as stated in the rejection of claim 24.
As to claim 30, XIE teaches a method, comprising:
accessing, by a management entity (the management entity comprises an operation support system (OSS) or a container cluster management entity), a container cluster descriptor (CCD) (CCD template) and an instantiation parameter of the container cluster (a container cluster descriptor (CCD) template is defined for describing all attributes of a container cluster) ([0074]);
sending, by the management entity (the management entity/OSS), the instantiation parameter of the container cluster to a container cluster management (CCM) (OSS may deliver the CCD template to the CCM) ([0074]; [0038]); and
instantiating, by the CCM, the container cluster based on the instantiation parameter of the container cluster (CCM instantiates/creates the container cluster based on descriptor-derived information, such as the instantiation parameters or information in CCD template sent by the management entity) ([0075]).
XIE only implicitly teaches that the container cluster instantiation parameters could be determined through the existence of the CCD template that describes all attributes of a container cluster, or from the OSS delivering the CCD template to the CCM, or from the CCM instantiation of the container cluster based on the CCD information ([0074]-[0075]).
XIE does not provide explicit teaching of the management entity “determining” a container cluster instantiation parameter.
FU is introduced to show explicit teaching of “determining, based on a system composition specification, one or more cluster configurations.” Furthermore, FU teaches initiating deployment of the cluster by instantiating the cluster in accordance with a corresponding cluster specification ([0006]).
It would have been obvious to one of ordinary skill in the art before the effective date of the application to apply FU’s parameter-determination abilities to XIE’s descriptor-driven container cluster management. The suggestion/motivation for doing so would have been to provide the predicted result of having instantiation parameters that are clearly derived from the CCD before being provided to the CCM, thereby making deployment, provisioning, and/or management to be less error-prone (FU - [0005]).
As to claim 31, it is rejected for the same reasons as stated in the rejection of claim 21.
As to claim 32, it is rejected for the same reasons as stated in the rejection of claim 22.
As to claim 33, it is rejected for the same reasons as stated in the rejection of claim 23.
As to claim 34, it is rejected for the same reasons as stated in the rejection of claim 24.
As to claim 35, it is rejected for the same reasons as stated in the rejection of claim 30.
As to claim 36, it is rejected for the same reasons as stated in the rejection of claim 21.
As to claim 37, it is rejected for the same reasons as stated in the rejection of claim 22.
As to claim 38, it is rejected for the same reasons as stated in the rejection of claim 21.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH TANG whose telephone number is (571)272-3772. The examiner can normally be reached Monday-Friday 7AM-3PM.
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, Bradley Teets can be reached at 571-272-3338. 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.
/KENNETH TANG/Primary Examiner, Art Unit 2197