DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment and Arguments
Applicant’s amendment filed on April 8, 2026 has been entered and made of record. Claims 1-20 are pending and are being examined in this application.
Applicant’s arguments with respect to 103 rejections have been considered, but are moot in view of the new ground(s) of rejection provided below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Akdeniz et al. (US Pub. 20230068386) in view of Capota et al. (US Pub. 20200410288).
Referring to claim 1, Akdeniz discloses A system comprising: a controller [fig. 12; pars. 127 and 263; a server] programmed to:
obtain information about a computation resource in each of a plurality of edge nodes [fig. 12; pars. 127 and 264; the server requests clients (i.e., edge nodes) to share their respective compute rates and communication times in order to estimate the total update time for each client], wherein the plurality of edge nodes are associated with a plurality of vehicles, and wherein the plurality of edge nodes comprise heterogeneous edge nodes [par. 1018-1039; note edge computing system supporting vehicle-to-vehicle, vehicle-to-everything, or vehicle-to-infrastructure scenarios and comprising various types of edge nodes] that differ in local data set size and the computation resource... [pars. 167 and 193; note local batchsize and various compute parameters for each client].
assign training steps to the plurality of edge nodes based on the information about the computation resource [par. 264; the clients are scheduled for training based on the total update time (i.e., based on respective compute rates)];
…upload frequencies of uploading local model parameters for one or more edge nodes of the plurality of edge nodes based on the assigned training steps [pars. 264, 273-277, 306, and 310; the server determines frequencies of model updates, ensuring that the clients are scheduled for training with at least a minimum frequency], wherein the frequencies are associated with at least one of a respective number of epochs for each of the plurality of edge nodes or respective training steps per epoch… [pars. 264, 273-277, 306, and 310; note the determined frequencies for the model updates and the scheduling of the clients for training (for each round/epoch); the number of training iterations per round/epoch is determined based on the number of training examples at each client];
receive local model parameters from one or more of the plurality of edge nodes based on the determined frequencies [pars. 273-277, 306, and 310; the model weights are sent by the clients to the server based on the determined frequencies]; and
update a global model based on the received local model parameters [pars. 122 and 273-277; a global model is updated based on the model weights].
Akdeniz does not appear to explicitly disclose wherein the computation resource corresponds to a power of at least one of a central processing unit or a graphical processing unit; and set the upload frequencies…wherein to set the upload frequencies is based at least in part on the computation resource for the one or more edge nodes.
However, Capota discloses wherein the computation resource corresponds to a power of at least one of a central processing unit or a graphical processing unit [pars. 42, 45, 53, 124, and 140; an edge device including a processor (e.g., a general processor or a graphical processing unit (GPU)) stores a device profile describing physical device properties such as processing/compute capabilities (i.e., processing power); see also Akdeniz, par. 264, disclosing compute rates]; and set the upload frequencies…wherein to set the upload frequencies is based at least in part on the computation resource for the one or more edge nodes [pars. 19, 20, 42, 45, 53, 56, 138, and 140; a frequency/number of transmissions from edge devices is configured by setting a threshold value (e.g., a number of data points, certain number of epochs, or other suitably defined iterations) for the devices to process in a local training session prior to sending an update to a server; in an example, the threshold value is set or updated for one or more workers (i.e., edge devices); the workers meet this constraint by processing the same number of data points indicated by the threshold value; if their processing power is the same, the workers have similar update rates when sending parameters (i.e., updates) to the server; no single worker dominates the dynamics of the aggregation in the server; machine learning workloads are distributed based on whether devices are capable of running a given model, each device including different hardware, different distributions and amounts of data, and different processing capabilities (e.g., certain devices may be configured to process data quicker or slower either as a result of physical specifications or user preferences); see also Akdeniz, par. 264, disclosing scheduling clients for training based on total update time (i.e., based on respective compute rates)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the model updates taught by Akdeniz so that the frequency of the model updates is configured by setting a threshold value as taught by Capota, with a reasonable expectation of success. The motivation for doing so would have been to improve the deployment and management of machine learning processes within distributed and heterogeneous environments [Capota, pars. 19 and 20].
Referring to claim 2, Akdeniz discloses The system of claim 1, wherein the controller is further programmed to: obtain a size of training data in each of the plurality of edge nodes [par. 263; the server polls each client to have the client share the number of training examples available to it]; determine a weight for each of the plurality of edge nodes based on the size of training data [pars. 122, 123, and 273-277; the training (i.e., for learning underlying model parameters such as the model weights) is performed based on the number of training examples (i.e., k)]; and update the global model by averaging the received local parameters using the weights [pars. 122 and 273-277; the server calculates the average of the model weights to update the global model].
Referring to claim 3, Akdeniz discloses The system of claim 1, wherein the controller is further programmed to: determine a time for implementing a predetermined number of training steps in each of the plurality of edge nodes based on the information about the computation resource; and assign training steps per epoch to the plurality of edge nodes based on the times for implementing the predetermined number of training steps [pars. 264 and 310; note the scheduling of the training (for each round/epoch) based on the total update time].
Referring to claim 4, Akdeniz discloses The system of claim 3, wherein the controller is further programmed to: determine the frequencies of uploading the local model parameters for the plurality of edge nodes based on the assigned training steps per epoch and a training step threshold; and instruct the plurality of edge nodes to upload the local model parameters based on the frequencies [pars. 264, 273-277, 306, and 310; note the determined frequencies for the model updates and the scheduling of the clients for training (for each round/epoch); the number of training iterations per round/epoch is determined based on the number of training examples at each client].
Referring to claim 5, Akdeniz discloses The system of claim 1, wherein the controller is further programmed to: transmit parameters of the updated global model to the one or more of the plurality of edge nodes [pars. 273-277; the server propagates the global model weights to the clients].
Referring to claim 6, Akdeniz discloses The system of claim 1, wherein the controller is further programmed to: determine whether local model parameters from two or more edge nodes are received during a single epoch; and in response determining that local model parameters from two or more edge nodes are received during the single epoch: update the global model based on the local model parameters received from the two or more edge nodes; and transmit parameters of the updated global model to the two or more edge nodes [pars. 264, 273-277, and 310; note the scheduling of the training (for each round/epoch) based on the total update time; also note the sending of the model weights from the clients (plural) to the server to update the global model].
Referring to claim 7, Akdeniz discloses The system of claim 1, wherein the controller is further programmed to: determine whether local model parameters from two or more edge nodes are received during a single epoch; and in response determining that local model parameters from less than two edge nodes are received during the single epoch, hold transmitting parameters of the global model to any of the plurality of edge nodes [pars. 186, 187, 308, 429, 548, and 600; if the model weights are received from less than an expected number of clients (e.g., two) during an optimized epoch time, the server first accounts for the missing model updates (by mimicking the local training at the clients from which the model updates were not received) and re-selects the clients before propagating the global model weights to the clients].
Referring to claim 8, Akdeniz discloses The system of claim 1, wherein the plurality of edge nodes include at least one of a connected vehicle or an edge server [par. 39; the clients may include autonomous vehicles].
Referring to claim 9, Akdeniz discloses The system of claim 1, wherein the local model parameters received from the one or more of the plurality of edge nodes are compressed parameters [pars. 194, 436, and 437; the server may receive compressed/encoded data (e.g., the model weights) from the clients].
Referring to claim 10, see the rejection for claim 1, which incorporates the claimed method.
Referring to claim 11, see the rejection for claim 2.
Referring to claim 12, see the rejection for claim 3.
Referring to claim 13, see the rejection for claim 4.
Referring to claim 14, see the rejection for claim 5.
Referring to claim 15, see the rejection for claim 6.
Referring to claim 16, see the rejection for claim 7.
Referring to claim 17, Akdeniz discloses A vehicle comprising: a controller [fig. 12; par. 39; an edge node (i.e., client) may be located in an autonomous vehicle] programmed to:
transmit information about a computation resource of the vehicle to a server... [fig. 12; pars. 127 and 264; a server requests clients to share their respective compute rates and communication times in order to estimate the total update time for each client];
receive a…frequency of uploading local model parameters of a model for image processing [par. 200; training is performed for modeling complex relationships in problems such as image recognition] from the server [pars. 264, 273-277, 306, and 310; clients are scheduled for the training based on the total update time; the server determines frequencies of model updates, ensuring that the clients are scheduled for training with at least a minimum frequency], wherein the frequency is based on the computation resource of the vehicle [pars. 264, 273-277, 306, and 310; note the scheduling based on the total update time to ensure at least a minimum frequency, where the total update time is based on respective compute rates], and associated with at least one of a number of epochs or training steps per epoch [pars. 264, 273-277, 306, and 310; note the determined frequencies for the model updates and the scheduling of the clients for training (for each round/epoch); the number of training iterations per round/epoch is determined based on the number of training examples at each client];
upload the local model parameters of the model based on the frequency to the server [pars. 273-277, 306, and 310; the model weights are sent by the clients to the server based on the determined frequencies];
receive a global model updated based on the local model parameters of the model from the server [pars. 273-277; the server propagates the global model weights to the clients]; and
implement processing of images captured by the vehicle using the received global model [pars. 119, 122, and 200; training is performed for modeling complex relationships in problems such as image recognition; once the global model is trained, the global model is used to perform machine learning tasks (e.g., image recognition)].
Akdeniz does not appear to explicitly disclose wherein the computation resource corresponds to a power of at least one of a central processing unit or a graphical processing unit; and that the frequency of uploading is set.
However, Capota discloses wherein the computation resource corresponds to a power of at least one of a central processing unit or a graphical processing unit [pars. 42, 45, 53, 124, and 140; an edge device including a processor (e.g., a general processor or a graphical processing unit (GPU)) stores a device profile describing physical device properties such as processing/compute capabilities (i.e., processing power); see also Akdeniz, par. 264, disclosing compute rates]; and that the frequency of uploading is set [pars. 19, 20, 42, 45, 53, 56, 138, and 140; a frequency/number of transmissions from edge devices is configured by setting a threshold value (e.g., a number of data points, certain number of epochs, or other suitably defined iterations) for the devices to process in a local training session prior to sending an update to a server; in an example, the threshold value is set or updated for one or more workers (i.e., edge devices); the workers meet this constraint by processing the same number of data points indicated by the threshold value; if their processing power is the same, the workers have similar update rates when sending parameters (i.e., updates) to the server; no single worker dominates the dynamics of the aggregation in the server; machine learning workloads are distributed based on whether devices are capable of running a given model, each device including different hardware, different distributions and amounts of data, and different processing capabilities (e.g., certain devices may be configured to process data quicker or slower either as a result of physical specifications or user preferences); see also Akdeniz, par. 264, disclosing scheduling clients for training based on total update time (i.e., based on respective compute rates)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the model updates taught by Akdeniz so that the frequency of the model updates is configured by setting a threshold value as taught by Capota, with a reasonable expectation of success. The motivation for doing so would have been to improve the deployment and management of machine learning processes within distributed and heterogeneous environments [Capota, pars. 19 and 20].
Referring to claim 18, Akdeniz discloses The vehicle of claim 17, wherein the controller is programmed to: compress the local model parameters of the model; and upload the compressed local model parameters to the server [pars. 194, 436, and 437; the server may receive compressed/encoded data (e.g., the model weights) from the clients].
Referring to claim 19, Akdeniz discloses The vehicle of claim 18, wherein the controller is programmed to: compress the local model parameters of the model using quantization or sparsification [par. 227; the encoding involves a sparse generator matrix using a Bernoulli distribution].
Referring to claim 20, Akdeniz discloses The vehicle of claim 17, wherein the controller is programmed to: transmit a size of training data in the vehicle to the server [par. 263; the server polls each client to have the client share the number of training examples available to it]; and receive a global model updated based on the local model parameters of the model and the size of training data from the server [pars. 122, 123, and 273-277; the training (i.e., for learning underlying model parameters such as the model weights) is performed based on the number of training examples (i.e., k); the server calculates the average of the model weights to update the global model].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GRACE PARK whose telephone number is (571)270-7727. The examiner can normally be reached M-F 8AM-5PM.
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, TAMARA KYLE can be reached at (571)272-4241. 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.
/Grace Park/Primary Examiner, Art Unit 2144
Prosecution Insights