DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 13, 15, 29, and 31-35 were canceled in the preliminary amendment.
Claims 1-12, 14, 16-28, and 30 are now presented for examination.
This office action is in response to the Amendment/Remarks on 1/26/26. Applicant’s arguments have been fully considered but were not found to be persuasive.
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-12, 14, 16-28, and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Prakash et al. (hereinafter Prakash) (US 2019/0138934 A1).
As to claim 1, Prakash teaches a method for generating a machine learning model, the method being performed by an entity (distributed machine learning in MEC system 200 or master node or central server, etc.) (Abstract; [0036]-[0038]; Fig. 4), the method comprising:
in response to receiving model parameters of a plurality of machine learning models (each compute node has its own local model and is decentralized; refined model or model updates and additional updates, and/or partial gradients via federated learning) ([0034]-[0035]; [0096]; Fig. 4):
generating a machine learning model (the central server averages the received models to obtain/generate the final global model) based on the model parameters of the plurality of machine learning models (global model is generated/updated using its local data; the master node 2112 aggregates the partial gradients to obtain a complete gradient), each of the plurality of machine learning models being trained by a different network node (edge compute nodes 101/201 or different heterogeneous compute nodes) of a network functions virtualization (NFV architectures and infrastructures may be used to virtualize one or more network functions), NFV, architecture based on data that is local (updates the global model using its local data) to that network node, wherein the data is not shared (the uncoded data (or raw data) and/or security keys are not shared with the master node 2112 or other edge compute nodes 2101) with the entity (local training data at each edge compute node; each edge compute node 2101 locally computes partial gradients and communicates those partial gradients to the master node 2112) ([0035]; [0131]; [0043]-[0045]; [0053]; [0082]; [0096]; [0125]).
As shown above, Prakash discloses systems and methods for distributed and federated machine-learning model training in a multi-access computing (MEC) environment implemented within a network functions virtualization architecture.
Although Prakash does not explicitly use the term “model parameters,” it instead discloses the terms “partial gradients” and “updated models.” Specifically, Prakash discloses that “Each client compute node fetches a global model, updates the global model using its local data, and communicates the updated model to the central server” ([0035]). Furthermore, Prakash discloses “each edge compute node 2101 computes a partial gradient, and at operation 224, the edge compute nodes 2101 individually provide their respective partial gradients to the master node 2112 once they complete their local calculations. At operation 227, the master node 2112 aggregates the partial gradients to obtain a complete gradient” ([0096]).
It would have been obvious to one of ordinary skill in the art before the effective date of the application to represent or exchange the partial gradients or updated models of Prakash as model parameters, because doing so constitutes a simple substitution of one known equivalent element for another to achieve the same predictable result (KSR Rationale B; see MPEP 2143). Gradient descent-based machine learning is known to operate on model parameters (weights, coefficients, etc.). One of ordinary skill in the art would have understood that partial gradients and model parameters are mathematically equivalent representations of the same information defining the model state, and thus, interchanging these forms would be an obvious substitution yielding the same distributed training functionality.
As to claim 2, Prakash teaches the method as claimed in claim 1, wherein: the data is about at least one virtualized network function, VNF, that is local to the network node (virtualize one or more network node functions or VNF and MEC elements/entities are deployed in an NFV environment) ([0080]-[0083]; [0180]-[0182]; [0185]-[0187]).
As to claim 3, Prakash teaches the method as claimed in claim 2, wherein: the at least one VNF is hosted by one or both of: one or more virtual machines; and one or more containers ([0358]; [0159]).
As to claim 4, Prakash teaches the method as claimed in claim1, wherein one or both of: the entity is a virtualized entity (MEC system 200/master node 2112 implements as a virtualized network function running on NFV infrastructure, NFVI 804) ([0082]); and one or more of the different network nodes (edge compute nodes 101/201 or different heterogeneous compute nodes) are virtualized network nodes (virtualization infrastructure, e.g., VI 638 and/or NFVI 804) ([0042]; [0181]; [0355]).
As to claim 5, Prakash teaches the method as claimed in claim 1, wherein: each of the plurality of machine learning models is trained by a different network node of a group of network nodes ([0041]-[0043]; [0053]; [0125]-[0127]).
As to claim 6, Prakash teaches the method as claimed in claim 5, wherein: each network node of the group of network nodes is local to a VNF that has at least one characteristic in common with a VNF that is local to another network node of the group of network nodes (MEC system groups and assigns tasks based on shared operational or network characteristics such as latency, traffic load, and link quality, a number of active UEs 101, etc.) ([0045]-[0050]).
As to claim 7, Prakash teaches the method as claimed in claim 6, wherein: the at least one characteristic comprises any one or more of: a traffic pattern (The fronthaul and/or backhaul link conditions may include network performance information related to network traffic measurements (e.g., measurements of the amount and type of traffic flowing through or across one or more network nodes), as well as various performance measurements) ([0050]); a number of subscribers (number of active UEs 101) ([0050]); and a deployment environment (deployment factors such as latency, energy, and channel conditions) ([0050]).
As to claim 8, Prakash teaches the method as claimed in claim 1, the method comprising: acquiring (by the master node 2112), from the different network nodes, the model parameters of the respective plurality of machine learning models (each client or edge compute node sends its updated model parameters to the master node) ([0124]-[0125]; [0131]).
As to claim 9, Prakash teaches the method as claimed in claim 1, wherein: generating the machine learning model based on the model parameters of the plurality of machine learning models comprises: generating the machine learning model based on an average of the model parameters of the plurality of machine learning models (as part of the federated learning, the central server averages the received models to obtain the final global model) ([0035]).
As to claim 10, Prakash teaches the method as claimed in claim 1, the method comprising: initiating transmission (via central server/master/MEC entity) of model parameters of the generated machine learning model (final global model or aggregated model) towards each of the different network nodes (edge/client compute nodes) ([0035]; [0095]-[0096]; [0124]-[0127]).
As to claim 11, Prakash teaches the method as claimed in claim1, the method comprising: initiating transmission of model parameters of a base machine learning model (the initial or global model that is distributed from the master node to the edge nodes for local training), wherein the base machine learning model is the machine learning model that is trained by the different network nodes (each node updates the base model using its own local data) ([0035]; [0095]-[0096]; [0124]-[0127]).
As to claim 12, Prakash teaches the method as claimed in claim1, wherein: the data comprises data indicative of traffic in the NFV architecture (network performance information related to network traffic measurements (e.g., measurements of the amount and type of traffic flowing through or across one or more network nodes); NFV or NFVI) ([0050]; [0082]; [0164]).
As to claim 14, it is rejected for the same reasons as stated in the rejection of claim 1.
As to claim 16, Prakash teaches a method for use in generating a machine learning model, the method being performed by a network node of a network functions virtualization, NFV, architecture the method comprising (Abstract; [0035]; [0080]-[0083]; [0180]):
training a machine learning model based on data that is local to the network node (training data sets may be locally available or accessible at each of the edge compute nodes 101, 201) ([0053]);
initiating transmission of model parameters of the machine learning model (each network node transmits/sends its trained model’s gradients or weights to a central entity such as the master node) towards an entity (Master node 2112 that aggregates the gradients) to allow the entity to generate a machine learning model based on the model parameters of a plurality of machine learning models (global model is generated/updated using its local data; the master node 2112 aggregates the partial gradients to obtain a complete gradient), each of the plurality of machine learning models being trained by a different network node (edge compute nodes 101/201 or different heterogeneous compute nodes) based on data that is local to that network node (local training data at each edge compute node; each edge compute node 2101 locally computes partial gradients and communicates those partial gradients to the master node 2112) ([0103]; [0127]; [0035]; [0043]-[0045]; [0053]; [0096]; [0125]).
As shown above, Prakash discloses systems and methods for distributed and federated machine-learning model training in a multi-access computing (MEC) environment implemented within a network functions virtualization architecture.
Although Prakash does not explicitly use the term “model parameters,” it instead discloses the terms “partial gradients” and “updated models.” Specifically, Prakash discloses that “Each client compute node fetches a global model, updates the global model using its local data, and communicates the updated model to the central server” ([0035]). Furthermore, Prakash discloses “each edge compute node 2101 computes a partial gradient, and at operation 224, the edge compute nodes 2101 individually provide their respective partial gradients to the master node 2112 once they complete their local calculations. At operation 227, the master node 2112 aggregates the partial gradients to obtain a complete gradient” ([0096]).
It would have been obvious to one of ordinary skill in the art before the effective date of the application to represent or exchange the partial gradients or updated models of Prakash as model parameters, because doing so constitutes a simple substitution of one known equivalent element for another to achieve the same predictable result (KSR Rationale B; see MPEP 2143). Gradient descent-based machine learning is known to operate on model parameters (weights, coefficients, etc.). One of ordinary skill in the art would have understood that partial gradients and model parameters are mathematically equivalent representations of the same information defining the model state, and thus, interchanging these forms would be an obvious substitution yielding the same distributed training functionality.
As to claim 17, it is rejected for the same reasons as stated in the rejection of claim 2.
As to claim 18, it is rejected for the same reasons as stated in the rejection of claim 3.
As to claim 19 , it is rejected for the same reasons as stated in the rejection of claim 4.
As to claim 20, it is rejected for the same reasons as stated in the rejection of claim 5.
As to claim 21, it is rejected for the same reasons as stated in the rejection of claim 6.
As to claim 22, it is rejected for the same reasons as stated in the rejection of claim 7.
As to claim 23, Prakash teaches the method as claimed in claim 16, the method comprising: acquiring the data that is local to the network node (accessible training datasets that are locally available at each of the edge compute nodes 101, 201) ([0053]; [0101]).
As to claim 24, Prakash teaches the method as claimed in claim 23, wherein: the data is acquired from one or both of: a probe configured to monitor data that is local to the network node (IoT sensors/remote sensor/sensor circuitry 1021) ([0053]; [0056]; [0229]) and a memory (memory circuitry 920) configured to store the monitored data (the locally available/accessible datasets may be stored in local storage/memory circuitry of the edge compute nodes 101, 201) ([0053]; [0199]).
As to claim 25, Prakash teaches the method as claimed in claim 16, the method comprising: receiving model parameters of the machine learning model generated by the entity (at operation 230, the master node 2112 provides the updated or refined model back to the edge compute nodes 2101 for the next epoch in the iterative training process) ([0095]-[0096]; [0124]-[0127]; [0035]).
As to claim 26, Prakash teaches the method as claimed in claim 16, the method comprising: receiving, from the entity, model parameters of a base machine learning model (the initial or global model that is distributed from the master node to the edge nodes for local training), wherein training the machine learning model comprises training the received base machine learning model (each node updates the base model using its own local data) ([0035]; [0095]-[0096]; [0124]-[0127]).
As to claim 27, Prakash teaches the method as claimed in claim 16, wherein: an operator data center of the network, an edge node of the network, a gateway of the network, or an end device of the network comprises the network node ([0045]; [0048]).
As to claim 28, it is rejected for the same reasons as stated in the rejection of claim 12.
As to claim 30, it is rejected for the same reasons as stated in the rejection of claim 16.
Response to Arguments
Regarding claim 1, Applicant argues that Prakash does not teach the amended limitation that “the data is not shared with the entity.”
In response, Prakash teaches model updating using local data ([0035]) and that the uncoded data (or raw data) and/or security keys are not shared with the master node 2112 or other edge compute nodes 2101 ([0131]). This disclosure teaches the limitation of the data is not shared with the entity.
Applicant traverses the rejection of claim 9 and argues that paragraph [0035]’s recitation of “The central server averages the received models to obtain the final global model” relates to a federated learning embodiment that Prakash alleges is in the prior art and that Prakash criticizes.
In response, Applicant appears to rely on a different embodiment of Prakash while ignoring the embodiment expressly relied upon by the rejection. Paragraph [0035] explicitly discloses that the central server averages the received models to obtain the final global model, which teaches the limitation of claim 9. Furthermore, Prakash does not criticize or discourage averaging model parameters received from distributed nodes. Instead, Prakash identifies federated learning as a known distributed learning technique and expressly explains that the central server averages the received models to obtain a global model.
Conclusion
THIS ACTION IS MADE FINAL. 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH TANG whose telephone number is (571)272-3772. The examiner can normally be reached Monday-Friday 7AM-3PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KENNETH TANG/Primary Examiner, Art Unit 2197
Prosecution Insights