DETAILED ACTION
This office action is in response to application filed on 11/10/2023.
Claim 1 – 20 are pending.
Priority is claimed as CON of PCT/CN2022/076076 (filed on 2/11/2022), which claims priority to Chinese application CN20210528216.5 (filed on 5/14/2021).
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 .
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 limitation(s) uses 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. Such claim limitation(s) is/are: “computer node management apparatus”, “transceiver module” and “processing module” in claim 10; “computer node management apparatus”, “virtual device module” and “resource mapping manager module” in claim 12.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/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 § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1 – 8, 10 – 17, 19 and 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Alluboyina et al (US 20210064442, prior art part of IDS dated 9/4/2024, hereinafter Alluboyina).
As per claim 1, Alluboyina discloses: A computing node management method, applied to a first device, comprising:
obtaining first information indicating to the first device to create a task circuit instance, the first information comprising a task circuit descriptor, the task circuit descriptor comprising description information of a task circuit of the first device, and the description information comprising at least one of: a task circuit type of the task circuit or a task circuit specification of the task circuit; (Alluboyina figure 4 and [0040] – [0041]: “the orchestrator 112 receiving 402 the application manifest 204 of a bundled application 202 and generating 404 plans for implementing the computation, storage, and networking for implementing the application manifest 204… the computation plan may include identifying compute nodes 110 (which may be hybrid nodes) for hosting containers executing role instances 212 defined by the application manifest 204. The storage plan identifies the storage nodes 106 for hosting storage volumes defined by the application manifest 204. The networking plan defines network addresses to be assigned to containers executing role instances 212 as defined by the application manifest 204.”; [0049]: “The orchestrator 112 generating 412 pod specifications for the containers of the role instances 212 specified in the application manifest 204. In particular, the pod specification may specify such information as an identifier (e.g., IP address) of the specific compute node 110 on which a container is to be instantiated and a reference to an executable file (e.g., application binary file or files) to be instantiated as the role instance 212. The pod specification may also indicate a type of container to be instantiated, e.g. DOCKER, LXC, LCS, KVM, or the like. The pod specification may further reference a storage volume mounted to the specific compute node 110 as mounted at step 408. The pod specification may further include an identifier of the container as specified in the application manifest 204 or determined according to he compute plan at step 404.”. Examiner notes that the compute node 110 is mapped to the claimed first device.)
and creating the task circuit instance based on the task circuit descriptor. (Alluboyina [0052]: “the Kubernetes invokes a Kubelet 302 on the compute node 110 referenced by the pod specification to create a container as specified in the pod specification: install an instance of the container type in the pod specification and load an instance of the role instance 212 referenced by the pod specification.”)
As per claim 2, Alluboyina further discloses:
The method according to claim 1, wherein before the obtaining of the first information, the method further comprises: sending a resource registration request message, wherein the resource registration request message is used to request mapping the first device to a worker node, the resource registration request message comprises a resource identifier and task circuit type information of the first device, and the task circuit type information indicates a task circuit type that can be used by the first device. (Alluboyina figure 4 and [0041] – [0042])
As per claim 3, Alluboyina further discloses:
The method according to claim 1, wherein the method further comprises: obtaining a resource registration response message from a second device, wherein the resource registration response message comprises result information indicating to the first device that the first device is mapped to the worker node. (Alluboyina figure 4 and [0041] – [0042])
As per claim 4, Alluboyina discloses:
A computing node management method, applied to a first device, comprising:
determining a task circuit descriptor based on a scheduling circuit descriptor and a virtual node context, wherein the virtual node context indicates resource information of a worker node to which a second device is mapped, the resource information comprises a resource identifier and task circuit type information of the second device, the task circuit type information comprises a task circuit type that can be used by the second device, the task circuit descriptor comprises description information of a task circuit of the second device, and the description information comprises at least one of: a task circuit type of the task circuit or a task circuit specification of the task circuit; (Alluboyina figure 4 and [0040] – [0041]: “the orchestrator 112 receiving 402 the application manifest 204 of a bundled application 202 and generating 404 plans for implementing the computation, storage, and networking for implementing the application manifest 204… the computation plan may include identifying compute nodes 110 (which may be hybrid nodes) for hosting containers executing role instances 212 defined by the application manifest 204. The storage plan identifies the storage nodes 106 for hosting storage volumes defined by the application manifest 204. The networking plan defines network addresses to be assigned to containers executing role instances 212 as defined by the application manifest 204.”; [0049]: “The orchestrator 112 generating 412 pod specifications for the containers of the role instances 212 specified in the application manifest 204. In particular, the pod specification may specify such information as an identifier (e.g., IP address) of the specific compute node 110 on which a container is to be instantiated and a reference to an executable file (e.g., application binary file or files) to be instantiated as the role instance 212. The pod specification may also indicate a type of container to be instantiated, e.g. DOCKER, LXC, LCS, KVM, or the like. The pod specification may further reference a storage volume mounted to the specific compute node 110 as mounted at step 408. The pod specification may further include an identifier of the container as specified in the application manifest 204 or determined according to he compute plan at step 404.”.)
and sending first information to the second device, wherein the first information indicates to the second device to create a task circuit instance, and the first information comprises the task circuit descriptor. (Alluboyina [0051]: “The pod specifications from step 412 may then be submitted 414 to the Kubernetes master 114, which then attempts to implement 416 the pod specifications.”; [0052]: “the Kubernetes invokes a Kubelet 302 on the compute node 110 referenced by the pod specification to create a container as specified in the pod specification: install an instance of the container type in the pod specification and load an instance of the role instance 212 referenced by the pod specification.”)
As per claim 5, Alluboyina further discloses:
The method according to claim 4, wherein the determining of the task circuit descriptor based on the scheduling circuit descriptor and the virtual node context comprises: selecting a task circuit type on the worker node for a scheduling circuit based on the virtual node context; and determining the task circuit descriptor based on the scheduling circuit descriptor and the task circuit type. (Alluboyina [0040], [0041] and [0049])
As per claim 6, Alluboyina further discloses:
The method according to claim 4, wherein before the determining of the task circuit descriptor based on the scheduling circuit descriptor and the virtual node context, the method further comprises: obtaining a resource registration request message from the second device, wherein the resource registration request message comprises the resource information; and generating, based on the resource registration request message, the existing virtual node context when the second device is mapped to the worker node. (Alluboyina figure 4 and [0041] – [0042])
As per claim 7, Alluboyina further discloses:
The method according to claim 6, wherein the method further comprises: sending a resource registration response message to the second device, wherein the resource registration response message comprises result information indicating that the second device is mapped to the worker node. (Alluboyina figure 4 and [0041] – [0042])
As per claim 8, Alluboyina further discloses:
The method according to claim 6, wherein the method further comprises: generating a worker node descriptor of the worker node based on the virtual node context; sending the worker node descriptor to a control device; and obtaining the scheduling circuit descriptor sent by the control device based on the worker node descriptor. (Alluboyina [0040], [0041] and [0049])
As per claim 10, it is the apparatus variant of claim 1 and is therefore rejected under the same rationale. (Alluboyina figure 1)
As per claim 11, it is the apparatus variant of claim 2 and is therefore rejected under the same rationale.
As per claim 12, it is the apparatus variant of claim 3 and is therefore rejected under the same rationale.
As per claim 13, it is the apparatus variant of claim 4 and is therefore rejected under the same rationale. (Alluboyina figure 1)
As per claim 14, it is the apparatus variant of claim 5 and is therefore rejected under the same rationale.
As per claim 15, it is the apparatus variant of claim 6 and is therefore rejected under the same rationale.
As per claim 16, it is the apparatus variant of claim 7 and is therefore rejected under the same rationale.
As per claim 17, it is the apparatus variant of claim 8 and is therefore rejected under the same rationale.
As per claim 19, it is the non-transitory computer-readable storage medium variant of claim 1 and is therefore rejected under the same rationale. (Alluboyina [0077])
As per claim 20, it is the non-transitory computer-readable storage medium variant of claim 4 and is therefore rejected under the same rationale. (Alluboyina [0077])
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) 9 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Alluboyina, in view of Pang et al (USPAT 11397658, hereinafter Pang).
As per claim 9, Alluboyina further discloses:
The method according to claim 6, wherein the method further comprises: obtaining a migrate-out request message, wherein the migrate-out request message is used to request migrating out a task circuit context, and the task circuit context comprises a mapping relationship between the task circuit descriptor and the worker node; and sending the task circuit context.
However, Pang teaches:
The method according to claim 6, wherein the method further comprises: obtaining a migrate-out request message, wherein the migrate-out request message is used to request migrating out a task circuit context, and the task circuit context comprises a mapping relationship between the task circuit descriptor and the worker node; and sending the task circuit context. (Pang col 22, line 62 – col 23, line 6.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Pang into that of Alluboyina in order to obtain a migrate-out request message, wherein the migrate-out request message is used to request migrating out a task circuit context, and the task circuit context comprises a mapping relationship between the task circuit descriptor and the worker node; and sending the task circuit context. It is commonly known in the field of cloud based task execution system that containers or tasks can be migrated upon request to a destination better suited for high performance or high availability purpose. Applicants have thus merely claimed the combination of known parts in the field to achieve predictable results of maintaining performance and high availability for the cloud system, and is therefore rejected under 35 USC 103.
As per claim 18, it is the apparatus variant of claim 9 and is therefore rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Luciano et al (USPAT 10970123) teaches “Using these suitability scores, users are able to easily determine the suitability of VM instance types for supporting their workloads, and diagnose potential issues with the pairings of VM instance types and workloads, such as over-utilization and under-utilization of VM instances. Further, the techniques include training a model to determine VM instance types recommended for supporting workloads. The model may receive utilization data representing resource-usage characteristics of the workload as input, and be trained to output one or more recommended VM instance types that are optimized or suitable to host the workload. Thus, the service provider network may provide users with easily-digestible suitability scores indicating the suitability of VM instance types for workloads along with VM instance types recommended for their workloads.”;
Cai et al (US 20200278890) teaches “A processor may register a virtual node for handling tasks allocated by a scheduling node in a computing system, the computing system comprising the scheduling node and a group of actual computing nodes processing tasks allocated by the scheduling node, and the scheduling node takes the virtual node as an actual computing node. A performance level of the computing system is obtained. Capacity of the virtual node is set based on the obtained performance level, such that the scheduling node allocates tasks to the virtual node based on the capacity of the virtual node. In response to at least one task being allocated by the scheduling node to the virtual node, the at least one task is received by the virtual node.”;
Kambatla et al (US 20200192703) teaches “Embodiments are disclosed for a utilization-aware approach to cluster scheduling, to address this resource fragmentation and to improve cluster utilization and job throughput. In some embodiments a resource manager at a master node considers actual usage of running tasks and schedules opportunistic work on underutilized worker nodes. The resource manager monitors resource usage on these nodes and preempts opportunistic containers in the event this over-subscription becomes untenable. In doing so, the resource manager effectively utilizes wasted resources, while minimizing adverse effects on regularly scheduled tasks.”;
Gopalan et al (US 20200104189) teaches “Forecast data for workloads and providers during a predefined period of time in the future is considered when identifying stressed providers and the feasibility of a workload move. Workloads with demand spikes at different future times can be matched by stacking current demand and forecast demand by timestamps. The possibility of stress can be reduced by making moves preemptively and considering forecast demand when evaluating the feasibility of a workload move.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES M SWIFT whose telephone number is (571)270-7756. The examiner can normally be reached Monday - Friday: 9:30 AM - 7PM.
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, April Blair can be reached at 5712701014. 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.
/CHARLES M SWIFT/Primary Examiner, Art Unit 2196