DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to application filed 12/18/2023, claiming priority based on Chinese application CN202110968564.4 dated 8/23/2021, wherein claims 1-15, 17-19 and 22 are pending based on preliminary amendment filed on 12/18/2023.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-15, 17-19, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (CN 113112029), in view of Unknown author (“TensorFlow Training (TFJob)”, www.kubeflow.org/docs/components/training/tftraining/, retrieved from wayback machine dated April 18, 2021) (hereafter as “TFJob”).
As for claim 1, Wang teaches a method for deploying a federated learning task based on a container, wherein a federated learning task is deployed to a plurality of service party devices by using a container management platform, the federated learning task is executed by using the plurality of service party devices (Abstract, Pg. 4, “…federated learning management and control platform 101 and a plurality of federated learning participant computing devices…one of the federal learning participant computing devices serves as a task initiator and the other devices serve as cooperative computing parties…”) and the method is performed by using the container management platform and comprises:
receiving a task description file for the federated learning task, wherein the task description file comprises the plurality of service party devices and first configuration information (Pg. 5-6, “…submitting …by a Federal learning participant….Federal learning task flow definition form data and Federal parameter definition form data….submitted in a JSON format…the flow direction definition of federal learning operators…inter—operator data and models included…entry and exit parameters, hyper-parameter definition and the like….” operators corresponds to the service party devices and configurations can be understood as any of the operators, data and models definitions and the various parameters.);
respectively generating container description files for the plurality of service party devices based on the task description file, wherein the container description files respectively comprise second configuration information for the corresponding service party devices (Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” In view of Pg. 2, “…pulls the corresponding container mirror image ….for deployment according to the computing device architecture…” and Pg. 13, “container management arrangement ….supporting heterogeneous nodes is installed…container image pushed using k3s server…” Any extracted per participant data and data for invocation of the containers/container images are understood as corresponding to the container description file(s)); and
respectively sending the plurality of generated first container description files to the corresponding service party devices, so that the plurality of service party devices create containers based on the respective first container description files, and execute the federated learning task by using the created containers (Pg. 13, “container mirror images of relevant application modules are deployed…deployed on federal task initiator computing equipment….container mirror images of the federal learning application module are deployed on ….cooperative computing party…using the Rancher K3s container management orchestration tool, resource status can be checked….container image pushed using k3s server….deploying k3s agent at each participant and joining a cluster of containers controlled by the hosting platform…” in view of (Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” teaching pushing deployment instructions to each participant’s k3s agent over the internal network, each node running a federal learning container locally.).
While the Federal circuit has repeated found recitation of objects in plurality can include one or more objects, thus Wang’s teaching of container deployment corresponding to any of the initiator or collaborators can reasonably read upon the first container group and the corresponding first container group description files. Moreover, the k3s container orchestration system disclosed in the prior art is a Kubernetes system, which is well-known to be deployable using Pods. However, in the interest of compact prosecution, Examiner note in the event the first container group refers to a POD like group of containers that is located within a POD, Wang does not explicitly teach such an interpretation of “first container group”.
However, TFJob teaches a known method of machine learning workload (Tensorflow) deployment using Kubernetes orchestration including generating first container group description files for the plurality of service party devices (Pg. 1, “…TFJob is a Kubernetes custom resource …use to run TensorFlow training jobs on Kubernetes…is a resource with a YAML representation…” Pg. 2 – TFJob internal information including field “replicas” which is the number of replicas of this type to spawn for the TFJob, Pg. 3-4, “…distributed tensorflow job typically contains …the following processes….Chief…Ps…Worker…Evaluator….tfReplicaSpecs ….contains a map from the type of replica (as listed above) to the TFReplicaSpec for that Replica…TFReplicaSpec consists of …Replicas…template - a PodTemplateSpec that describes the pod to create for each replica …restartPolicy….Always…OnFailure…ExitCode…Never…” and Pg. 8, “…Conditions…resources (e.g. services/pods)….scheduled and launched and the job is running…”, teaches TF job implement on hardware resources, including creating podtempleteSpec for each replica’s pod of containers used for implementing replica . Each replica is understood as a component/service that is part of/for the ML workload, and each instance is an instance of said component/service), and sending the plurality of generated first container group description files to the corresponding service party devices (Pg. 4, “…tfReplicaSpecs…maps from the type of replica …..to the TFReplicaSpec….a PodTemplateSpec that describes the pod to create for each replica….restartPolicy ….” All teaches the information used to create/manage the pods for each replica.)
It would be obvious to a person of ordinary skill in the art to incorporate TFJob’ teaching of generating first container group description files for the plurality of service party devices and sending the plurality of generated first container group description files to the corresponding service party devices into Wang with generating container description files for the plurality of service party devices based on the task description file and sending the container description files for the plurality of service party devices to the corresponding plurality of service party devices because they are directed toward implementation of ML workloads in Kubernetes environments and because doing so allows for improved implementation of ML training jobs on Kubernetes (TFJob, Pg. 1).
As for claim 2, Wang also teaches receiving the task description file obtained based on an input operation performed by a user (Pg. 3, “…providing a network calling interface for calling and initiating federal training and federal prediction by a user… …federal learning participator submits a federal learning task application and the process definition form data and the parameter definition form data…” teaching user initiates the federal training/learning/prediction, that leads to the submission of related learning task application requests and definition form data.).
As for claim 3, Wang also teaches wherein the federated learning task is executed by using a server and the plurality of service party devices (Abstract, Pg. 4, “…federated learning management and control platform 101 and a plurality of federated learning participant computing devices…one of the federal learning participant computing devices serves as a task initiator and the other devices serve as cooperative computing parties…”); the container management platform is configured to deploy the federated learning task to the server and the plurality of service party devices (Pg. 3, “federal learning control platform informs all the participants to start iterative training according to the federal learning task flow….”); the task description file further comprises the server and the first configuration information further comprises configuration information related to the server (Pg. 3, “…inform all the participants…according to the federal learning task flow definition form data and the federal parameter definition form data…”);
TFJob also teaches generating a second container group description file for the server based on the task description file, wherein the second container group description file comprises third configuration information for the server (Pg. 1, “…TFJob is a Kubernetes custom resource …use to run TensorFlow training jobs on Kubernetes…is a resource with a YAML representation…” Pg. 2 – TFJob internal information including field “replicas” which is the number of replicas of this type to spawn for the TFJob, Pg. 3-4, “…distributed tensorflow job typically contains …the following processes….Chief…Ps…Worker…Evaluator….tfReplicaSpecs ….contains a map from the type of replica (as listed above) to the TFReplicaSpec for that Replica…TFReplicaSpec consists of …Replicas…template - a PodTemplateSpec that describes the pod to create for each replica …restartPolicy….Always…OnFailure…ExitCode…Never…” and Pg. 8, “…Conditions…resources (e.g. services/pods)….scheduled and launched and the job is running…”, teaches TF job implement on hardware resources, including creating podtempleteSpec for each replica’s pod of containers used for implementing replica . Each replica is understood as a respective container group implementing component/service that is part of/for the ML workload, and each instance is a instance of said component/service within the container group.); and
sending the generated second container group description file to the server, so that the server creates a container group based on the second container group description file, and executes the federated learning task by using the created container group (Pg. 4, “…tfReplicaSpecs…maps from the type of replica …..to the TFReplicaSpec….a PodTemplateSpec that describes the pod to create for each replica….restartPolicy ….” In view of Pg. 7 showing spec used and creation of container pod output. All teaches the information used to create/manage the pods for each replica). Rationale to combine is same as claim 1 above.
As for claim 4, Wang teaches for any service party device, determining, from the task description file, an interaction device that interacts with the service party device in the federated learning task, and second configuration information for the service party device (Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” And Pg. 5, “…flow direction definitions of federal learning operators, inter-operator data ….is included….” Teaching information between input/output of operators, thus, the 2 end points are understood as interaction device and the service party device. Moreover, plurality of configurations are included, thus, this information can be understood as 2nd configuration information relative to any of the other configuration information extracted/determined.); and generating a first container group description file for the service party device based on the determined interaction device and the determined second configuration information for the service party device (Pg. 6, “analyze the ……extracts all federal participants, data required by role definition and training and the like…informs all the participants….” In view of Pg. 5, “…flow direction definitions of federal learning operators, inter-operator data…”).
As for claim 5, TFJob also teaches setting a restart field in the first container group description file to "Always", wherein the restart field is used to indicate whether to perform a container group restart operation upon determining that a container group restart condition is met (Pg. 2, “…restartPolicy…” Pg. 4, “…restartPolicy…always….onFailure….ExitCode….”). Rationale to combine same as claim 1 above.
As for claim 6, Wang also teaches determining, from the task description file, an interaction device that interacts with the server in the federated learning task (pg. 5-6, “….flow direction definitions of federal learning operators, inter-operator data….are mainly described….role definition of all federal participants are mainly described, and entry and exit parameters, hyper-parameter definition and the like of each federal learning operator….analyzes the received….definition form data…extracts….data required…”), and the third configuration information for the server (Pg. 5-6, “flow direction definitions…inter-operator data and models…role definitions….and entry and exit parameters, hyper-parameter definitions….”); and generating the second container group description file based on the determined interaction device and the determined third configuration information for the server (Pg. 6, “analyze the received ….definition form data….extracts all federal participants, data required by role definition and training and the like….informs all the participants ….”).
As for claim 7, TFJob also teaches setting a restart field in the second container group description file to "Never", wherein the restart field is used to indicate whether to perform a container group restart operation when upon determining that a container group restart condition is met (Pg. 4, “…restartPolicy….Never….”). Rationale to combine is same as claim 1 above.
As for claim 8, Wang also teaches the configuration information comprises executable file information and image file information (pg. 5-6, “….flow direction definitions of federal learning operators, inter-operator data….are mainly described….role definition of all federal participants are mainly described, and entry and exit parameters, hyper-parameter definition and the like of each federal learning operator….analyzes the received….definition form data…extracts….data required…” and Pg. 13, “container mirror images of relevant application modules are deployed…deployed on federal task initiator computing equipment….container mirror images of the federal learning application module are deployed on ….cooperative computing party…using the Rancher K3s container management orchestration tool, resource status can be checked….container image pushed using k3s server….deploying k3s agent at each participant and joining a cluster of containers controlled by the hosting platform…”); executable file information in the third configuration information is different from executable file information in the second configuration information (pg. 5-6, “….flow direction definitions of federal learning operators, inter-operator data….are mainly described….role definition of all federal participants are mainly described, and entry and exit parameters, hyper-parameter definition and the like of each federal learning operator….analyzes the received….definition form data…extracts….data required…”); and image file information in the third configuration information is the same as or different from image file information in the second configuration information (Pg. 13, “container mirror images of relevant application modules are deployed…deployed on federal task initiator computing equipment….container mirror images of the federal learning application module are deployed on ….cooperative computing party…using the Rancher K3s container management orchestration tool, resource status can be checked….container image pushed using k3s server….deploying k3s agent at each participant and joining a cluster of containers controlled by the hosting platform…”).
As for claim 9, Wang also teaches obtaining a container group running status of the server and determining, based on the container group running status of the server, whether the federated learning task is completed (Pg. 6, “…synchronously executes the state between all the participants and the control platform after execution of each module operator in the ….definition is completed…collects information….aggregates the model parameters……after each federal learning operator…..is executed and finished by each participants….”); and when upon determining that the federated learning task is completed, stop, by communicating with the plurality of service party devices, the container groups that are in the plurality of service party devices and that are used to run the federated learning task (Pg. 13, “….container …images of the federal learning application module are deployed….participants ….can be checked and the update container image pushed….after the system deployment is completed…..submits a federal task request for training….determines that … stopping training…the trained model maybe released…””).
TFJob also teaches delete the container groups that are in the plurality of service party devices and that are used to run the federated learning task (Pg. 5, “…Delete it…kubectl -n Kubeflow delete tfjob mnist…” and Pg. 10, “…deletion of pods when a job terminates…”)
As for claim 10, Wang teaches A method for deploying a federated learning task based on a container, wherein a federated learning task is deployed to a plurality of service party devices by using a container management platform, the federated learning task is executed by using the plurality of service party devices, and the method is performed by using any service party device (Abstract, Pg. 4, “…federated learning management and control platform 101 and a plurality of federated learning participant computing devices…one of the federal learning participant computing devices serves as a task initiator and the other devices serve as cooperative computing parties…” in view of Pg. 13, “…container…images of the federal learning application module are deployed….using the Rancher k3s container management orchestration tool…..automatically deploying, expanding, and managing ‘containerized applications….”) and comprises:
receiving a first container group description file sent by the container management platform, wherein the first container group description file comprises second configuration information for the service party device, the first container group description file is generated based on a task description file for the federated learning task, and the task description file comprises the plurality of service party devices and first configuration information (Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” In view of Pg. 2, “…pulls the corresponding container mirror image ….for deployment according to the computing device architecture…” and Pg. 13, “container management arrangement ….supporting heterogeneous nodes is installed…container image pushed using k3s server…” Any extracted per participant data and data for invocation of the containers/container images are understood as corresponding to the container description file(s). In addition, Pg. 5-6, “…submitting …by a Federal learning participant….Federal learning task flow definition form data and Federal parameter definition form data….submitted in a JSON format…the flow direction definition of federal learning operators…inter—operator data and models included…entry and exit parameters, hyper-parameter definition and the like….” Teaches the task description file used to generate the information required.); and
creating containers based on container description file, and running the created containers to execute the federated learning task (Pg. 13, “container mirror images of relevant application modules are deployed…deployed on federal task initiator computing equipment….container mirror images of the federal learning application module are deployed on ….cooperative computing party…using the Rancher K3s container management orchestration tool, resource status can be checked….container image pushed using k3s server….deploying k3s agent at each participant and joining a cluster of containers controlled by the hosting platform…” in view of (Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” teaching pushing deployment instructions to each participant’s k3s agent over the internal network, each node running a federal learning container locally.)
While the Federal circuit has repeated found recitation of objects in plurality can include one or more objects, thus Wang’s teaching of container deployment corresponding to any of the initiator or collaborators can reasonably read upon the first container group and the corresponding first container group description files. Moreover, the k3s container orchestration system disclosed in the prior art is a Kubernetes system, which is well-known to be deployable using Pods. However, in the interest of compact prosecution, Examiner note in the event the first container group refers to a POD like group of containers that is located within a POD, Wang does not explicitly teach such an interpretation of “container group”.
However, TFJob teaches a known method of machine learning workload (Tensorflow) deployment using Kubernetes orchestration including creating container group based on container group description file, and running the created container group to execute the federated learning task (Pg. 1, “…TFJob is a Kubernetes custom resource …use to run TensorFlow training jobs on Kubernetes…is a resource with a YAML representation…” Pg. 2 – TFJob internal information including field “replicas” which is the number of replicas of this type to spawn for the TFJob, Pg. 3-4, “…distributed tensorflow job typically contains …the following processes….Chief…Ps…Worker…Evaluator….tfReplicaSpecs ….contains a map from the type of replica (as listed above) to the TFReplicaSpec for that Replica…TFReplicaSpec consists of …Replicas…template - a PodTemplateSpec that describes the pod to create for each replica …restartPolicy….Always…OnFailure…ExitCode…Never…” and Pg. 8, “…Conditions…resources (e.g. services/pods)….scheduled and launched and the job is running…”, teaches TF job implement on hardware resources, including creating podtempleteSpec for each replica’s pod of containers used for implementing replica . Each replica is understood as a component/service that is part of/for the ML workload, and each instance is a instance of said component/service), and sending the plurality of generated first container group description files to the corresponding service party devices (Pg. 4, “…tfReplicaSpecs…maps from the type of replica …..to the TFReplicaSpec….a PodTemplateSpec that describes the pod to create for each replica….restartPolicy ….” All teaches the information used to create/manage the pods for each replica. Pg. 5, “…#submit the TFJob kubectl apply -f tf_job_mnist.yaml…” teaches executing the job in Kubernetes.)
It would be obvious to a person of ordinary skill in the art to incorporate TFJob’ teaching of generating first container group description files for the plurality of service party devices and sending the plurality of generated first container group description files to the corresponding service party devices into Wang with creating containers based on the container description file because they are directed toward implementation of ML workloads in Kubernetes environments and because doing so allows for improved implementation of ML training jobs on Kubernetes (TFJob, Pg. 1).
As for claim 11, Wang teaches obtaining an image file for the federated learning task (Pg. 2, “…pulls the corresponding container mirror image …for deployment …”); and running the image file for the federated learning task in the created container based on the second configuration information (Pg. 3, “…participator pulls the corresponding container mirror image … for deployment …” Pg. 5-6, “…submitting Federal learning task flow definition form data and Federal parameter definition form data…submitted in a JSON format and the flow direction definitions of federal operators, inter-operator data and models…selection and role definition….entry and exit parameters, hyper-parameter definition and the like of each federal learning operator…analyze….extracts all federal participants, data required by role definition and training…informs all the participants to start training…”, and interacting with an interaction device indicated in the first container description file, to execute the federated learning task (Pg. 3, “…input and output parameters of a federal learning agent…transmits encrypted model parameters…aggregates the encrypted model parameters of each participant…” and alternatively Pg. 2, “…participator obtains data used for model predictions…calls model prediction service through a network call interface….for initiating the federal prediction…”)
As for claim 12, TFJob also teaches receiving a deletion message that is sent by the container management platform and that indicates to delete the container group, and deleting the container group (Pg. 5, “…Delete it…kubectl -n Kubeflow delete tfjob mnist…”, Pg. 8, “…deletion of pods…”, Pg. 10, “…CleanPodPolicy in the TFJob spec controls deletion of pods when a job terminates…running…all…”.).
As for claim 13, Wang teaches a method for deploying a federated learning task based on a container, wherein a federated learning task is deployed to a server and a plurality of service party devices by using a container management platform, the federated learning task is executed by using the server and the plurality of service party devices, and the method is performed by using the server (Abstract, Pg. 4, “…federated learning management and control platform 101 and a plurality of federated learning participant computing devices…one of the federal learning participant computing devices serves as a task initiator and the other devices serve as cooperative computing parties…” in view of Pg. 13, “…container…images of the federal learning application module are deployed….using the Rancher k3s container management orchestration tool…..automatically deploying, expanding, and managing ‘containerized applications….”) and comprises:
receiving a second container description file sent by the container management platform, wherein the second container description file comprises third configuration information for the server, the second container description file is generated based on a task description file for the federated learning task, and the task description file comprises the server, the plurality of service party devices, and first configuration information (Pg. 13, “container mirror images of relevant application modules are deployed…deployed on federal task initiator computing equipment….container mirror images of the federal learning application module are deployed on ….cooperative computing party…using the Rancher K3s container management orchestration tool, resource status can be checked….container image pushed using k3s server….deploying k3s agent at each participant and joining a cluster of containers controlled by the hosting platform…” in view of Pg. 5-6, ‘…flow direction definitions of federal learning operators, inter-operator data and models…role definition…entry and exit parameters, hyper-parameter definitions…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….”); and
creating containers based on the second container description file, and running the created containers to execute the federated learning task (Pg. 13, “container mirror images of relevant application modules are deployed…deployed on federal task initiator computing equipment….container mirror images of the federal learning application module are deployed on ….cooperative computing party…using the Rancher K3s container management orchestration tool, resource status can be checked….container image pushed using k3s server….deploying k3s agent at each participant and joining a cluster of containers controlled by the hosting platform…” in view of (Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” teaching pushing deployment instructions to each participant’s k3s agent over the internal network, each node running a federal learning container locally.)
.
While the Federal circuit has repeated found recitation of objects in plurality can include one or more objects, thus Wang’s teaching of container deployment corresponding to any of the initiator or collaborators can reasonably read upon the first container group and the corresponding first container group description files. Moreover, the k3s container orchestration system disclosed in the prior art is a Kubernetes system, which is well-known to be deployable using Pods. However, in the interest of compact prosecution, Examiner note in the event the first container group refers to a POD like group of containers that is located within a POD, Wang does not explicitly teach such an interpretation of “container group”.
However, TFJob teaches a known method of machine learning workload (Tensorflow) deployment using Kubernetes orchestration including creating container group based on container group description file, and running the created container group to execute the federated learning task (Pg. 1, “…TFJob is a Kubernetes custom resource …use to run TensorFlow training jobs on Kubernetes…is a resource with a YAML representation…” Pg. 2 – TFJob internal information including field “replicas” which is the number of replicas of this type to spawn for the TFJob, Pg. 3-4, “…distributed tensorflow job typically contains …the following processes….Chief…Ps…Worker…Evaluator….tfReplicaSpecs ….contains a map from the type of replica (as listed above) to the TFReplicaSpec for that Replica…TFReplicaSpec consists of …Replicas…template - a PodTemplateSpec that describes the pod to create for each replica …restartPolicy….Always…OnFailure…ExitCode…Never…” and Pg. 8, “…Conditions…resources (e.g. services/pods)….scheduled and launched and the job is running…”, teaches TF job implement on hardware resources, including creating podtempleteSpec for each replica’s pod of containers used for implementing replica . Each replica is understood as a component/service that is part of/for the ML workload, and each instance is a instance of said component/service), and sending the plurality of generated first container group description files to the corresponding service party devices (Pg. 4, “…tfReplicaSpecs…maps from the type of replica …..to the TFReplicaSpec….a PodTemplateSpec that describes the pod to create for each replica….restartPolicy ….” All teaches the information used to create/manage the pods for each replica. Pg. 5, “…#submit the TFJob kubectl apply -f tf_job_mnist.yaml…” teaches executing the job in Kubernetes.).
In addition, TFJob also teaches receiving a second container description file sent by the container management platform, wherein the second container description file comprises third configuration information for the server (Pg. 5, “…Submit the TFJob kubectl apply -f tf_job_mnist.yaml…” in view of Pg. 2),
It would be obvious to a person of ordinary skill in the art to incorporate TFJob’ teaching of generating first container group description files for the plurality of service party devices and sending the plurality of generated first container group description files to the corresponding service party devices into Wang with creating containers based on the container description file because they are directed toward implementation of ML workloads in Kubernetes environments and because doing so allows for improved implementation of ML training jobs on Kubernetes (TFJob, Pg. 1).
As for claim 14, Wang also teaches obtaining an image file for the federated learning task (Pg. 2, “…pulls the corresponding container mirror image ….for deployment according to the computing device architecture…” and Pg. 13, “container management arrangement ….supporting heterogeneous nodes is installed…container image pushed using k3s server…”; and running the image file for the federated learning task in the created container based on the third configuration information (Pg. 2, “…pulls the corresponding container mirror image ….for deployment according to the computing device architecture…” and Pg. 13, “container management arrangement ….supporting heterogeneous nodes is installed…container image pushed using k3s server…” Any extracted per participant data and data for invocation of the containers/container images are understood as corresponding to the container description file(s) here, the third configuration information can be any information required for running of the participant, such as those listed in Pg. 5-6, i.e., input/output, parameters, etc.), and interacting with an interaction device indicated in the second container group description file, to execute the federated learning task (Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” And Pg. 5, “…flow direction definitions of federal learning operators, inter-operator data ….is included….” Teaching information between input/output of operators, thus, the 2 end points are understood as interaction device and the service party device. Moreover, plurality of configurations are included, thus, this information can be understood as 2nd configuration information relative to any of the other configuration information extracted/determined).
TFJob also teaches created container group based on the third configuration information (Pg. 1, “…TFJob is a Kubernetes custom resource …use to run TensorFlow training jobs on Kubernetes…is a resource with a YAML representation…” Pg. 2 – TFJob internal information including field “replicas” which is the number of replicas of this type to spawn for the TFJob, Pg. 3-4, “…distributed tensorflow job typically contains …the following processes….Chief…Ps…Worker…Evaluator….tfReplicaSpecs ….contains a map from the type of replica (as listed above) to the TFReplicaSpec for that Replica…TFReplicaSpec consists of …Replicas…template - a PodTemplateSpec that describes the pod to create for each replica …restartPolicy….Always…OnFailure…ExitCode…Never…” and Pg. 8, “…Conditions…resources (e.g. services/pods)….scheduled and launched and the job is running…”). Rationale to combine same as claim 13 above.
As for claim 15, Wang also teaches when upon determining that execution of the federated learning task is completed, exiting the container, and sending a running status indicating that the container in the server is successfully exited to the container management platform (Pg. 6).
In addition, TFJob also teaches determining the execution status of federated learning task is completed, exiting the container group and sending a running status of the container group (Pg. 4, “…exitCode…0 indicates the process completed successfully…” Pg-7 showing return of status for pod. Pg. 8, “TFJobStatus…TFJOBSucceeded means the job completed successfully…”). Rationale to combine same as claim 13 above.
As for claim 17, Wang teaches A container management platform, configured to deploy a federated learning task to a plurality of service party devices, wherein the federated learning task is executed by using the plurality of service party devices, and the container management platform comprises a manager and a controller ((Abstract, Pg. 4, “…federated learning management and control platform 101 and a plurality of federated learning participant computing devices…one of the federal learning participant computing devices serves as a task initiator and the other devices serve as cooperative computing parties…” in view of Pg. 13, “…container…images of the federal learning application module are deployed….using the Rancher k3s container management orchestration tool…..automatically deploying, expanding, and managing ‘containerized applications….”. Examiner note, applicant specification teaches the management platform includes a manager and a controller each having specific functionality, where no separate depiction of manager and controller in any Figs. Instead, only depicts container management platform as a single entity. Thus, under the BRI, the manager and controller are understood as including 2 different software functionalities of a single software package. Similar to the federated learning management and control platform 101 disclosed in the prior art);
the manager is configured to receive a task description file for the federated learning task, and send the task description file to the controller, wherein the task description file comprises the plurality of service party devices and first configuration information (Pg. 5-6, “…submitting …by a Federal learning participant….Federal learning task flow definition form data and Federal parameter definition form data….submitted in a JSON format…the flow direction definition of federal learning operators…inter—operator data and models included…entry and exit parameters, hyper-parameter definition and the like….” operators corresponds to the service party devices and configurations can be understood as any of the operators, data and models definitions and the various parameters.);
the controller is configured to respectively generate first container description files for the plurality of service party devices based on the task description file, and send the first container description files to the manager, wherein the first container description files comprise second configuration information for the corresponding service party devices (Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” In view of Pg. 2, “…pulls the corresponding container mirror image ….for deployment according to the computing device architecture…” and Pg. 13, “container management arrangement ….supporting heterogeneous nodes is installed…container image pushed using k3s server…” Any extracted per participant data and data for invocation of the containers/container images are understood as corresponding to the container description file(s)); and
the manager is configured to respectively send the plurality of received first container description files to the corresponding service party devices, so that the plurality of service party devices create container based on the respective first container description files, and execute the federated learning task by using the created container (Pg. 13, “container mirror images of relevant application modules are deployed…deployed on federal task initiator computing equipment….container mirror images of the federal learning application module are deployed on ….cooperative computing party…using the Rancher K3s container management orchestration tool, resource status can be checked….container image pushed using k3s server….deploying k3s agent at each participant and joining a cluster of containers controlled by the hosting platform…” in view of (Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” teaching pushing deployment instructions to each participant’s k3s agent over the internal network, each node running a federal learning container locally).
While the Federal circuit has repeated found recitation of objects in plurality can include one or more objects, thus Wang’s teaching of container deployment corresponding to any of the initiator or collaborators can reasonably read upon the first container group and the corresponding first container group description files. Moreover, the k3s container orchestration system disclosed in the prior art is a Kubernetes system, which is well-known to be deployable using Pods. However, in the interest of compact prosecution, Examiner note in the event the first container group refers to a POD like group of containers that is located within a POD, Wang does not explicitly teach such an interpretation of “first container group”.
However, TFJob teaches a known method of machine learning workload (Tensorflow) deployment using Kubernetes orchestration including generating first container group description files for the plurality of service party devices (Pg. 1, “…TFJob is a Kubernetes custom resource …use to run TensorFlow training jobs on Kubernetes…is a resource with a YAML representation…” Pg. 2 – TFJob internal information including field “replicas” which is the number of replicas of this type to spawn for the TFJob, Pg. 3-4, “…distributed tensorflow job typically contains …the following processes….Chief…Ps…Worker…Evaluator….tfReplicaSpecs ….contains a map from the type of replica (as listed above) to the TFReplicaSpec for that Replica…TFReplicaSpec consists of …Replicas…template - a PodTemplateSpec that describes the pod to create for each replica …restartPolicy….Always…OnFailure…ExitCode…Never…” and Pg. 8, “…Conditions…resources (e.g. services/pods)….scheduled and launched and the job is running…”, teaches TF job implement on hardware resources, including creating podtempleteSpec for each replica’s pod of containers used for implementing replica . Each replica is understood as a component/service that is part of/for the ML workload, and each instance is a instance of said component/service), and sending the plurality of generated first container group description files to the corresponding service party devices (Pg. 4, “…tfReplicaSpecs…maps from the type of replica …..to the TFReplicaSpec….a PodTemplateSpec that describes the pod to create for each replica….restartPolicy ….” All teaches the information used to create/manage the pods for each replica.)
It would be obvious to a person of ordinary skill in the art to incorporate TFJob’ teaching of generating first container group description files for the plurality of service party devices and sending the plurality of generated first container group description files to the corresponding service party devices into Wang with generating container description files for the plurality of service party devices based on the task description file and sending the container description files for the plurality of service party devices to the corresponding plurality of service party devices because they are directed toward implementation of ML workloads in Kubernetes environments and because doing so allows for improved implementation of ML training jobs on Kubernetes (TFJob, Pg. 1).
As for claim 18, Wang also teaches wherein the federated learning task is executed by using a server and the plurality of service party devices (Abstract, Pg. 4, “…federated learning management and control platform 101 and a plurality of federated learning participant computing devices…one of the federal learning participant computing devices serves as a task initiator and the other devices serve as cooperative computing parties…”); the container management platform is configured to deploy the federated learning task to the server and the plurality of service party devices (Pg. 3, “federal learning control platform informs all the participants to start iterative training according to the federal learning task flow….”); the task description file further comprises the server and the first configuration information further comprises configuration information related to the server (Pg. 3, “…inform all the participants…according to the federal learning task flow definition form data and the federal parameter definition form data…”);
TFJob also teaches the controller is further configured to generate a second container group description file for the server based on the task description file, wherein the second container group description file comprises third configuration information for the server (Pg. 1, “…TFJob is a Kubernetes custom resource …use to run TensorFlow training jobs on Kubernetes…is a resource with a YAML representation…” Pg. 2 – TFJob internal information including field “replicas” which is the number of replicas of this type to spawn for the TFJob, Pg. 3-4, “…distributed tensorflow job typically contains …the following processes….Chief…Ps…Worker…Evaluator….tfReplicaSpecs ….contains a map from the type of replica (as listed above) to the TFReplicaSpec for that Replica…TFReplicaSpec consists of …Replicas…template - a PodTemplateSpec that describes the pod to create for each replica …restartPolicy….Always…OnFailure…ExitCode…Never…” and Pg. 8, “…Conditions…resources (e.g. services/pods)….scheduled and launched and the job is running…”, teaches TF job implement on hardware resources, including creating podtempleteSpec for each replica’s pod of containers used for implementing replica . Each replica is understood as a respective container group implementing component/service that is part of/for the ML workload, and each instance is a instance of said component/service within the container group.); and
The manager is further configured to send the received second container group description file to the server, so that the server creates a container group based on the second container group description file, and executes the federated learning task by using the created container group (Pg. 4, “…tfReplicaSpecs…maps from the type of replica …..to the TFReplicaSpec….a PodTemplateSpec that describes the pod to create for each replica….restartPolicy ….” In view of Pg. 7 showing spec used and creation of container pod output. All teaches the information used to create/manage the pods for each replica). Rationale to combine is same as claim 17 above.
As for claim 19, Wang also teaches the manager is further configured to receive a container group running status sent by the server; the controller is further configured to obtain a container group running status of the server from the manager, and determine, based on the container running status of the server, whether the federated learning task is completed (Pg. 6, “…synchronously executes the state between all the participants and the control platform after execution of each module operator in the ….definition is completed…collects information….aggregates the model parameters……after each federal learning operator…..is executed and finished by each participants….”); and send a stop message to the manager when upon determining that the federated learning task is completed, wherein the stop message is used to indicate to stop the container that are in the plurality of service party devices and that are used to run the federated learning task, and the manager when in response to receiving the stop message, stop, by communicating with the plurality of service party devices, the container that are in the plurality of service party devices and that are used to run the federated learning task Pg. 13, “….container …images of the federal learning application module are deployed….participants ….can be checked and the update container image pushed….after the system deployment is completed…..submits a federal task request for training….determines that … stopping training…the trained model maybe released…” stop the training is understood as functionally stop the execution of the participants.).
TFJob also teaches delete the container groups that are in the plurality of service party devices and that are used to run the federated learning task (Pg. 5, “…Delete it…kubectl -n Kubeflow delete tfjob mnist…” and Pg. 10, “…deletion of pods when a job terminates…”)
As for claim 22, Wang also teaches A system for deploying a federated learning task based on a container, comprising a container management platform and a plurality of service party devices, wherein the system deploys a federated learning task to the plurality of service party devices by using the container management platform, and the federated learning task is executed by using the plurality of service party devices (Abstract, Pg. 4, “…federated learning management and control platform 101 and a plurality of federated learning participant computing devices…one of the federal learning participant computing devices serves as a task initiator and the other devices serve as cooperative computing parties…” in view of Pg. 13, “…container…images of the federal learning application module are deployed….using the Rancher k3s container management orchestration tool…..automatically deploying, expanding, and managing ‘containerized applications….”. Examiner note, applicant specification teaches the management platform includes a manager and a controller each having specific functionality, where no separate depiction of manager and controller in any Figs. Instead, only depicts container management platform as a single entity. Thus, under the BRI, the manager and controller are understood as including 2 different software functionalities of a single software package. Similar to the federated learning management and control platform 101 disclosed in the prior art);
the container management platform is configured to receive a task description file for the federated learning task, wherein the task description file comprises the plurality of service party devices and first configuration information (Pg. 5-6, “…submitting …by a Federal learning participant….Federal learning task flow definition form data and Federal parameter definition form data….submitted in a JSON format…the flow direction definition of federal learning operators…inter—operator data and models included…entry and exit parameters, hyper-parameter definition and the like….” operators corresponds to the service party devices and configurations can be understood as any of the operators, data and models definitions and the various parameters.);
respectively generate first container group description files for the plurality of service party devices based on the task description file, wherein the first container group description files respectively comprise second configuration information for the corresponding service party devices ((Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” In view of Pg. 2, “…pulls the corresponding container mirror image ….for deployment according to the computing device architecture…” and Pg. 13, “container management arrangement ….supporting heterogeneous nodes is installed…container image pushed using k3s server…” Any extracted per participant data and data for invocation of the containers/container images are understood as corresponding to the container description file(s)); and
respectively send the plurality of generated first container description files to the corresponding service party devices and any service party device is configured to receive the first container description file sent by the container management platform, create a container based on the first container description file, and run the created container to execute the federated learning task (Pg. 13, “container mirror images of relevant application modules are deployed…deployed on federal task initiator computing equipment….container mirror images of the federal learning application module are deployed on ….cooperative computing party…using the Rancher K3s container management orchestration tool, resource status can be checked….container image pushed using k3s server….deploying k3s agent at each participant and joining a cluster of containers controlled by the hosting platform…” in view of (Pg. 6, ‘…analyze the received ….task flow definition form data and …parameter definition form data, extracts all federal participants, data required by role definition and training and the like…to determines equipment availability and data availability of all the participants…informs all the participants to start training ….” teaching pushing deployment instructions to each participant’s k3s agent over the internal network, each node running a federal learning container locally..
While the Federal circuit has repeated found recitation of objects in plurality can include one or more objects, thus Wang’s teaching of container deployment corresponding to any of the initiator or collaborators can reasonably read upon the first container group and the corresponding first container group description files. Moreover, the k3s container orchestration system disclosed in the prior art is a Kubernetes system, which is well-known to be deployable using Pods. However, in the interest of compact prosecution, Examiner note in the event the first container group refers to a POD like group of containers that is located within a POD, Wang does not explicitly teach such an interpretation of “first container group”.
However, TFJob teaches a known method of machine learning workload (Tensorflow) deployment using Kubernetes orchestration including generating first container group description files for the plurality of service party devices (Pg. 1, “…TFJob is a Kubernetes custom resource …use to run TensorFlow training jobs on Kubernetes…is a resource with a YAML representation…” Pg. 2 – TFJob internal information including field “replicas” which is the number of replicas of this type to spawn for the TFJob, Pg. 3-4, “…distributed tensorflow job typically contains …the following processes….Chief…Ps…Worker…Evaluator….tfReplicaSpecs ….contains a map from the type of replica (as listed above) to the TFReplicaSpec for that Replica…TFReplicaSpec consists of …Replicas…template - a PodTemplateSpec that describes the pod to create for each replica …restartPolicy….Always…OnFailure…ExitCode…Never…” and Pg. 8, “…Conditions…resources (e.g. services/pods)….scheduled and launched and the job is running…”, teaches TF job implement on hardware resources, including creating podtempleteSpec for each replica’s pod of containers used for implementing replica . Each replica is understood as a component/service that is part of/for the ML workload, and each instance is a instance of said component/service), and sending the plurality of generated first container group description files to the corresponding service party devices (Pg. 4, “…tfReplicaSpecs…maps from the type of replica …..to the TFReplicaSpec….a PodTemplateSpec that describes the pod to create for each replica….restartPolicy ….” All teaches the information used to create/manage the pods for each replica.)
It would be obvious to a person of ordinary skill in the art to incorporate TFJob’ teaching of generating first container group description files for the plurality of service party devices and sending the plurality of generated first container group description files to the corresponding service party devices into Wang with generating container description files for the plurality of service party devices based on the task description file and sending the container description files for the plurality of service party devices to the corresponding plurality of service party devices because they are directed toward implementation of ML workloads in Kubernetes environments and because doing so allows for improved implementation of ML training jobs on Kubernetes (TFJob, Pg. 1).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached M-F 10am-6pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached on 5712723759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KEVIN X LU/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights