DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to the application filed on May 30th, 2023. Claims 1-20 are pending in the case. Claims 1, 11 and 20 are independent claims.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 120 as follows:
This application makes reference to subject matter disclosed in Provisional Application No. 63/492,964, filed March 29, 2023 in the Specification, however does not include the Provisional Application in the Application Data Sheet (ADS). If applicant desires to claim the benefit of a prior-filed application under 35 U.S.C. 119(e), 120, 121, 365(c) or 386(c), the instant application must contain, or be amended to contain, a specific reference to the prior-filed application in compliance with 37 CFR 1.78. Since the application was filed on or after September 16, 2012, the specific reference must be included in an ADS in compliance with 37 CFR 1.76. For benefit claims under 35 U.S.C. 120, 121, 365(c), or 386(c), the reference must include the relationship (i.e., continuation, divisional, or continuation-in-part) of the applications.
If the instant application is a utility or plant application filed under 35 U.S.C. 111(a), the specific reference must be submitted during the pendency of the application and within the later of four months from the actual filing date of the application or sixteen months from the filing date of the prior application. If the application is a national stage application under 35 U.S.C. 371, the specific reference must be submitted during the pendency of the application and within the later of four months from the date on which the national stage commenced under 35 U.S.C. 371(b) or (f), four months from the date of the initial submission under 35 U.S.C. 371 to enter the national stage, or sixteen months from the filing date of the prior application. See 37 CFR 1.78(a)(4) for benefit claims under 35 U.S.C. 119(e) and 37 CFR 1.78(d)(3) for benefit claims under 35 U.S.C. 120, 121, 365(c), or 386(c). This time period is not extendable and a failure to submit the reference required by 35 U.S.C. 119(e) and/or 120, where applicable, within this time period is considered a waiver of any benefit of such prior application(s) under 35 U.S.C. 119(e), 120, 121, 365(c), and 386(c). A benefit claim filed after the required time period may be accepted if it is accompanied by a grantable petition to accept an unintentionally delayed benefit claim under 35 U.S.C. 119(e) (see 37 CFR 1.78(c)) or under 35 U.S.C. 120, 121, 365(c), or 386(c) (see 37 CFR 1.78(e)). The petition must be accompanied by (1) the reference required by 35 U.S.C. 120 or 119(e) and by 37 CFR 1.78 to the prior application (unless previously submitted), (2) the applicable petition fee under 37 CFR 1.17(m)(1) or (2), and (3) a statement that the entire delay between the date the benefit claim was due under 37 CFR 1.78 and the date the claim was filed was unintentional. The presentation of a benefit claim may result in an additional fee under 37 CFR 1.17(w)(1) or (2) being required, if the earliest filing date for which benefit is claimed under 35 U.S.C. 120, 121, 365(c), or 386(c) and 1.78(d) in the application is more than six years before the actual filing date of the application. The Director may require additional information where there is a question whether the delay was unintentional. The petition should be addressed to: Mail Stop Petition, Commissioner for Patents, P.O. Box 1450, Alexandria, Virginia 22313-1450.
If the reference to the prior application was previously submitted within the time period set forth in 37 CFR 1.78 but was not included in the location in the application required by the rule (e.g., if the reference was submitted in an oath or declaration or the application transmittal letter), and the information concerning the benefit claim was recognized by the Office as shown by its inclusion on the first filing receipt, the petition under 37 CFR 1.78 and the petition fee under 37 CFR 1.17(m)(1) or (2) are not required. Applicant is still required to submit the reference in compliance with 37 CFR 1.78 by filing an ADS in compliance with 37 CFR 1.76 with the reference (or, if the application was filed before September 16, 2012, by filing either an amendment to the first sentence(s) of the specification or an ADS in compliance with pre-AIA 37 CFR 1.76). See MPEP § 211.02.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Huba et al. ("PAPAYA: Practical, Private, And Scalable Federated Learning", Huba et al., 25 April 2022) hereinafter Huba.
Regarding claim 1:
Huba teaches [a] system comprising:
a memory; and one or more processors coupled to the memory (Huba, page 7, col 2, ¶2 “This update is then pushed into an in-memory queue on the Aggregator. A different thread drains the queue by de-serializing the updates into trainable parameters and aggregating them. To speed up this aggregation, we parallelize the aggregation process across available cores” here the in-memory queue discloses the memory, and the threads and cores disclose the processors couples to the memory), the one or more processors being configured to:
determine, by a centralized process in a distributed data parallel training environment used to train a model via data parallelism (Huba, page 5, col 1, ¶3 “Coordinator. The Coordinator performs three main functions. First, it assigns FL tasks to Aggregators, as discussed in Section 6.3. Second, the Coordinator assigns clients to FL tasks, as described in Section 6.1. Finally, it provides centralized coordination and ensures that tasks progress in the face of Aggregator failures.”), a respective state of each training worker process (Huba, page 19, col 1, section E.2, ¶1 “For each client, the aggregator records initial model version to track staleness.” Here, the staleness of each client can be considered the state of the training worker process) from a plurality of training worker processes in the distributed data parallel training environment (Huba, page 1, col 1, ¶2 “In the context of FL, concurrency refers to the number of clients training simultaneously, and our aim is to develop systems that can accelerate training by training concurrently on more clients.”), the model comprising an artificial intelligence (AI) or machine learning (ML) model (Huba, page 1, section 1, ¶1 “Cross-device federated learning (FL) is a distributed learning paradigm where a large collection of clients collaborate to train a machine learning model while the raw training data stays on client devices.” It is noted the claim recites alternative language, and Huba teaches at least one of the alternatives.);
determine, by the centralized process based on the respective state of each training worker process, a respective task that one or more training worker processes of the plurality of training worker processes should perform with respect to at least one of a local replica of the model and training data associated with the local replica of the model (Huba, page 1, col 2, ¶1 “In each round, clients download the current server model, train this model locally on their respective data, and report a model update back to the server.”); and
send, by the centralized process to the one or more training worker processes, one or more instructions to perform the respective task (Huba, page 7, col 1, ¶4 “Task assignment. Once an eligible task list is constructed for a client, the Coordinator randomly assigns the client to an eligible task. Concretely, the Coordinator instructs Selectors to forward the client to the Aggregator responsible for the task.” Here, the forwarding of tasks for clients can be considered the sending of instructions to perform tasks to the clients) with respect to at least one of the local replica of the model and the training data (Huba, page 6, col 2, section 6.1 ¶3 “Next, the client trains the downloaded model on its local data.”).
Regarding claim 2:
Huba teaches [t]he system of claim 1, wherein the respective task comprises training the local replica of the model using additional training data (Huba, page 6, col 2, section 6.1, ¶3 “Next, the client trains the downloaded model on its local data.”).
Regarding claim 3:
Huba teaches [t]he system of claim 2, wherein the one or more processors are configured to:
receive, from the one or more training worker processes, an updated model parameter determined based on the training of the local replica of the model using the additional training (Huba, page 7, col 2, ¶2 “Once a client completes training, it uploads the trained serialized model update to the server.”);
and update the model based on the updated model parameter Huba, page 7, col 2, ¶2 “Once the cumulative number of aggregated model updates reaches the aggregation goal, the final aggregation is performed and a new server model is generated.” Here, the new generated server model based on worker updates can be considered the model update).
Regarding claim 4:
Huba teaches [t]he system of claim 1, wherein the respective task comprises evaluating at least one of the local replica of the model, the training data, and additional training data selected for additional training of the local replica of the model (Huba, page 8, col 1, ¶3 “We partition each client’s data into train, test, and validation sets randomly” here, the validation data set can be considered the additional training data, and validating a model using the validation set can be considered the evaluation).
Regarding claim 5:
Huba teaches [t]he system of claim 1, wherein determining the respective state of each training worker process from the plurality of training worker processes comprises receiving, by the centralized process, the respective state from each training worker process from the plurality of training worker processes (Huba, page 7, col 1, ¶2 “First, each Aggregator tracks client demand for the tasks that are assigned to it. When a client finishes training or fails, the Aggregator increases client demand for the associated task. Next, the Coordinator pools together information from all Aggregators into a consolidated view of client demand for every task in the system.”).
Regarding claim 6:
Huba teaches [t]he system of claim 1, wherein determining the respective state of each training worker process from the plurality of training worker processes comprises receiving, by the centralized process, the respective state from a state manager configured to receive state information from the plurality of training worker processes (Huba, page 7, col 1, ¶2 “First, each Aggregator tracks client demand for the tasks that are assigned to it.” Here, the aggregator can be considered the state manager which receives client demand which can be considered the state information).
Regarding claim 7:
Huba teaches [t]he system of claim 1, wherein the one or more processors are configured to identify, by the centralized process, an error associated with a training worker process of the plurality of training worker processes based on the respective state associated with that training worker process (Huba, page 18, col 2, section E.1, ¶1 , “An active client may become inactive for various reasons. The client may have completed execution, or it may be considered dead due to missed heartbeats or execution error.”), and identify, by the centralized process, a solution to the error based on the respective state associated with that training worker process (Huba, page 19, col 2, section E.4, ¶4 “Upon aggregator failure or unresponsiveness, coordinator detects failures after several missed heartbeats and reassigns all tasks to other aggregators, updates and distributes the new assignment map to selectors. Coordinator detects stale assignments in aggregator reports via sequence numbers and requests to stop executing stale assignments.”).
Regarding claim 8:
Huba teaches [t]he system of claim 7, wherein the error comprises at least one of a failure, a timeout (Huba, page 8, col 1, ¶2 “Similar to Bonawitz et al. (2019), a timeout is imposed to limit the client training time;”), and a stuck state, the stuck state comprising an inability by the training worker process to complete one or more tasks (Huba, page 19, col 2, section E.4, ¶4 “Upon aggregator failure or unresponsiveness, coordinator detects failures after several missed heartbeats and reassigns all tasks to other aggregators, updates and distributes the new assignment map to selectors.” It is noted the claim recites alternative language, and Huba teaches at least one of the alternatives. ).
Regarding claim 9:
Huba teaches [t]he system of claim 1, wherein the one or more processors are configured to save, by the centralized process, at least one of an overall state of the model and an overall state of a training of the model (Huba, page 19, col 2, section E.5, ¶1 “The mobile interpreter facilitates efficient cross-platform execution (Android, iOS, Linux) by providing common functionality to save and load model code and parameters, execute forward and backward passes, and optimizer steps.”).
Regarding claim 10:
Huba teaches [t]he system of claim 1, wherein the one or more processors are configured to:
determine, based on respective state of a first training worker process from the plurality of training worker processes, the respective task for the first training worker process (Huba, page 7, col 1, ¶1 “There are three important steps to assigning clients to tasks: tracking client demand for each task, tracking task eligibility for each client, and performing the actual assignment”);
determine, based on respective state of a second training worker process from the plurality of training worker processes, the respective task for the second training worker process (Huba, page 7, col 1, ¶1 “There are three important steps to assigning clients to tasks: tracking client demand for each task, tracking task eligibility for each client, and performing the actual assignment” furthermore, tasks are independent per client Huba, page 6, col 2, section 6.1, ¶1 “To enable asynchronous training, PAPAYA’s client protocol deliberately avoids any inter-client dependency.” );
and instruct, by the centralized process, the first training worker process to perform the respective task for the first training worker process and the second training worker process to perform the respective task for the second training worker process (Huba, page 7, col 1, ¶4 “Task assignment. Once an eligible task list is constructed for a client, the Coordinator randomly assigns the client to an eligible task. Concretely, the Coordinator instructs Selectors to forward the client to the Aggregator responsible for the task.” Here, each the forwarding of tasks to each client can be considered instructing a first and second worker to perform respective tasks).
Regarding claim 11:
Huba teaches [a] method comprising:
determining, by a centralized process in a distributed data parallel training environment used to train a model via data parallelism (Huba, page 5, col 1, ¶3 “Coordinator. The Coordinator performs three main functions. First, it assigns FL tasks to Aggregators, as discussed in Section 6.3. Second, the Coordinator assigns clients to FL tasks, as described in Section 6.1. Finally, it provides centralized coordination and ensures that tasks progress in the face of Aggregator failures.”), a respective state of each training worker process (Huba, page 19, col 1, section E.2, ¶1 “For each client, the aggregator records initial model version to track staleness.” Here, the staleness of each client can be considered the state of the training worker process) from a plurality of training worker processes in the distributed data parallel training environment (Huba, page 1, col 1, ¶2 “In the context of FL, concurrency refers to the number of clients training simultaneously, and our aim is to develop systems that can accelerate training by training concurrently on more clients.”), the model comprising an artificial intelligence (AI) or machine learning (ML) model (Huba, page 1, section 1, ¶1 “Cross-device federated learning (FL) is a distributed learning paradigm where a large collection of clients collaborate to train a machine learning model while the raw training data stays on client devices.” It is noted the claim recites alternative language, and Huba teaches at least one of the alternatives.);
determining, by the centralized process based on the respective state of each training worker process, a respective task that one or more training worker processes of the plurality of training worker processes should perform with respect to at least one of a local replica of the model and training data associated with the local replica of the model(Huba, page 1, col 2, ¶1 “In each round, clients download the current server model, train this model locally on their respective data, and report a model update back to the server.”); and
sending, by the centralized process to the one or more training worker processes, one or more instructions to perform the respective task (Huba, page 7, col 1, ¶4 “Task assignment. Once an eligible task list is constructed for a client, the Coordinator randomly assigns the client to an eligible task. Concretely, the Coordinator instructs Selectors to forward the client to the Aggregator responsible for the task.” Here, the forwarding of tasks for clients can be considered the sending of instructions to perform tasks to the clients) with respect to at least one of the local replica of the model and the training data (Huba, page 6, col 2, section 6.1 ¶3 “Next, the client trains the downloaded model on its local data.”).
Regarding claims 12-19:
The rejection of claims 1-7 and 9-10 are applicable to claims 12-19, respectively.
Regarding claim 20:
Huba teaches [a] non-transitory computer-readable medium having stored thereon instructions which, when executed by one or more processors (Huba, page 7, col 2, ¶2 “This update is then pushed into an in-memory queue on the Aggregator. A different thread drains the queue by de-serializing the updates into trainable parameters and aggregating them. To speed up this aggregation, we parallelize the aggregation process across available cores” here the threads and cores disclose the processors couples to the memory), cause the one or more processors to:
determine, by a centralized process in a distributed data parallel training environment used to train a model via data parallelism (Huba, page 5, col 1, ¶3 “Coordinator. The Coordinator performs three main functions. First, it assigns FL tasks to Aggregators, as discussed in Section 6.3. Second, the Coordinator assigns clients to FL tasks, as described in Section 6.1. Finally, it provides centralized coordination and ensures that tasks progress in the face of Aggregator failures.”), a respective state of each training worker process (Huba, page 19, col 1, section E.2, ¶1 “For each client, the aggregator records initial model version to track staleness.” Here, the staleness of each client can be considered the state of the training worker process) from a plurality of training worker processes in the distributed data parallel training environment (Huba, page 1, col 1, ¶2 “In the context of FL, concurrency refers to the number of clients training simultaneously, and our aim is to develop systems that can accelerate training by training concurrently on more clients.”), the model comprising an artificial intelligence (AI) or machine learning (ML) model (Huba, page 1, section 1, ¶1 “Cross-device federated learning (FL) is a distributed learning paradigm where a large collection of clients collaborate to train a machine learning model while the raw training data stays on client devices.” It is noted the claim recites alternative language, and Huba teaches at least one of the alternatives.);
determine, by the centralized process based on the respective state of each training worker process, a respective task that one or more training worker processes of the plurality of training worker processes should perform with respect to at least one of a local replica of the model and training data associated with the local replica of the model (Huba, page 1, col 2, ¶1 “In each round, clients download the current server model, train this model locally on their respective data, and report a model update back to the server.”); and
send, by the centralized process to the one or more training worker processes, one or more instructions to perform the respective task (Huba, page 7, col 1, ¶4 “Task assignment. Once an eligible task list is constructed for a client, the Coordinator randomly assigns the client to an eligible task. Concretely, the Coordinator instructs Selectors to forward the client to the Aggregator responsible for the task.” Here, the forwarding of tasks for clients can be considered the sending of instructions to perform tasks to the clients) with respect to at least one of the local replica of the model and the training data (Huba, page 6, col 2, section 6.1 ¶3 “Next, the client trains the downloaded model on its local data.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bendre et al. (US 10380504 B2) teaches a network system including a plurality of trainer devices and a computing system disposed within a remote network management platform. The computing system configured to: receive, from a client device of a managed network, information indicating (i) training data that is to be used as basis for generating a machine learning (ML) model and (ii) a target variable to be predicted using the ML model; transmit an ML training request for reception by one of the plurality of trainer devices; provide the training data to a particular trainer device executing a particular ML trainer process that is serving the ML training request; receive, from the particular trainer device, the ML model that is generated based on the provided training data and according to the particular ML trainer process; predict the target variable using the ML model; and transmit, to the client device, information indicating the target variable.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB Z SUSSMAN MOSS whose telephone number is (571) 272-1579. The examiner can normally be reached Monday - Friday, 9 a.m. - 5 p.m. ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kakali Chaki can be reached on (571) 272-3719. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.S.M./Examiner, Art Unit 2122
/KAKALI CHAKI/Supervisory Patent Examiner, Art Unit 2122