DETAILED ACTION
Response to Amendment
The amendment filed on 24 April 2026 has been entered.
Claims 1-20 are pending.
Claims 1-2, 6-7, 12-15, 17, 19 are amended.
Applicant’s amendments to the Claims have overcome each and every objection and rejection under USC 35 112(b) and USC 35 101, previously set forth in the Non-Final Office Action mailed 26 January 2026.
Response to Arguments
Applicant’s remarks, regarding the rejections of claims under 35 USC 103, have been fully considered.
Applicant submits Ranganath et al. and Balasubramanian et al., taken alone or in combination, do not render obvious, a fine tune application that, based on a fine tune instruction from the xApp, adjusts at least one model weight of the machine learning model based on a received dataset, resulting in a tuned machine learning model, of amended Claims 1, 12, 17.
Applicant’s arguments have been considered, but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 12-14, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganath et al. (U.S. Pre-Grant Publication No. 20240259879, hereinafter ‘Ranganath'), in view of Pateromichelakis et al. (WIPO No. 2022048746, hereinafter ‘Pateromichelakis’).
Regarding claim 1 and analogous claims 12, 17, Ranganath teaches A serving hub device, comprising: at least one processor that processes data for a near real time radio access network intelligent controller; and at least one memory that stores executable instructions that, when executed by the at least one processor, facilitate performance of operations, comprising ([0057] The vRAN processors 3 c 52 are processors that include (or are configured with) one or more optimizations for vRAN functionality. The vRAN processors 3 c 52 may be COTS HW or application-specific HW elements. As examples, the vRAN processors 3 c 52 may be Intel® Xeon® D processors, Intel® Xeon® Scalable processors, AMD® Epyc® 7000, AMD® “Rome” processors, and/or the like. The vRAN accelerators 3 c 54 are HW accelerators that are configured to accelerate 4G/LTE and 5G vRAN workloads. As examples, the vRAN accelerators 3 c 54 may be Forward Error Correction (FEC) accelerators (e.g., Intel® vRAN dedicated accelerator ACC100m Xolinx® T1 Telco Accelerator Card, and the like), low density parity check (LDPC) accelerators (e.g., AccelerComm® LE500 and LD500), networking accelerators (e.g., Intel® FPGA PAC N3000), and/or the like. Additionally or alternatively, the vRAN processors 3 c 52 may be the same or similar as processor(s) 1752 of FIG. 17 , and the vRAN accelerators 3 c 54 may be the same or similar as the acceleration circuitry 1764 of FIG. 17 . Interaction between the vRAN processors 3 c 52 and vRAN accelerators 3 c 54 may take place via an acceleration abstraction layer (AAL) for standardized interoperability, via an inline HW accelerator pipeline or functional chains, via virtual input/output (vI/O) interfaces, via single root I/O virtualization (SR-IOV) interfaces, and/or via some other interface or mechanism. The HW platform layer 3 c 50 also includes platform compute HW 3 c 56, which includes compute/processor, acceleration, memory, and storage resources that can be used for UE-specific data processing and/or RANF-specific data processing. The compute, acceleration, memory, and storage resources of the platform compute HW 3 c 56 correspond to the processor circuitry 1752, acceleration circuitry 1764, memory circuitry 1754, and storage circuitry 1758 of FIG. 17, respectively.):
determining that the near real time radio access network intelligent controller has received, from a service management and orchestration device, first authentication data representative of a first authentication to deploy an xApp on the near real time radio access network intelligent controller ([0026] FIG. 1 depicts an example O-RAN architecture 100 including various determining that the near real time radio access network intelligent controller has received, from a service management and orchestration device interfaces between a RAN Intelligent Controller (RIC) 114 and service management and orchestration framework (SMO) 102. The SMO 102 may be the same or similar as the SMO 802, 902, 1002 and/or the MO 301, 3 c 02 discussed infra. The RIC 114 is an NF that also includes intelligent applications (apps) such as network ML/AI apps functioning with it to automate various NFs for predictive maintenance, enhanced operation, and the like. The O-RAN architecture 100 describes a model for RAN resource control, managed at the upper level by orchestration and automation components of the SMO 102 (e.g., policy, configuration, inventory, design, and non-RT RIC 112). These components control and communicate with the near-RT RIC 114 via the A1 interface. The near-RT RIC 114 provides management of and connectivity to RAN nodes (e.g., eNB/gNB 910, RU 816, DU 916, and the like). In some implementations, the near-RT RIC 114 may be the same or similar as the near-RT RIC 814 of FIG. 8 and/or the RIC 3 c 14 of FIG. 3 c , and some aspects of the near-RT RIC 114 may be described infra w.r.t FIG. 3 c . Additionally, a core set of services provided by the near-RT RIC 114 is extensible by custom third-party xApps, which are instantiated as cloud services and have low-latency connectivity to RAN nodes. first authentication data representative of a first authentication to deploy an xApp on the near real time radio access network intelligent controller xApps communicate with the RIC 114 and its managed RAN nodes via the E2 interface. O-RAN defines and clarifies the usage of various interfaces in the O-RAN architecture 100. These interfaces are summarized by Table 1.; [0035] FIG. 3 a depicts an example RAN intelligent xApp manager architecture 300 a in an O-RAN framework. In this example, the xApp manager architecture 300 a includes an xApp manager analytics engine 310-a implemented as an xApp 310 in an app layer 330 of the near-RT RIC 114, and a counterpart xApp manager measurement engine 320 implemented by the O-DU 115. The app layer 330 also includes a set of xApps 310-1 to 310-N (where N is a number). The xApps 310-a, 310-1 to 310-N (collectively referred to as “xApps 310”) may be the same or similar as xApps 410, 1110, and 1210 of FIGS. 4, 11, and 12.);
Ranganath fails to teach receiving, from the service management and orchestration device, second authentication data representative of a second authentication to deploy a machine learning model on the serving hub device, wherein the machine learning model is disaggregated from the xApp; and based on the first authentication to deploy the xApp and the second authentication to deploy the machine learning model, enabling authenticated communication for a model manager device that manages the machine learning model via a group of application programming interfaces, the group of application programming interfaces comprising:
a predict application programming interface in which the machine learning model receives a request from the xApp and, in response, provides a prediction to the xApp to satisfy the request; and a fine tune application that, based on a fine tune instruction from the xApp, adjusts at least one model weight of the machine learning model based on a received dataset, resulting in a tuned machine learning model, and calls a deploy application programming interface to deploy the tuned machine learning model on the serving hub device.
Pateromichelakis teaches receiving, from the service management and orchestration device, second authentication data representative of a second authentication to deploy a machine learning model on the serving hub device, wherein the machine learning model is disaggregated from the xApp ([0068] Figure IB depicts an O-RAN architecture 150 for configuring a predictive QoS adaptation pattern, according to embodiments of the disclosure. The O-RAN architecture includes a from the service management and orchestration device service and management plane 151 which includes a configuration, policy, inventory, and design function 152 and a non-real time RAN intelligent controller (“non-RT RIC”) 153, a near-real time RAN intelligent controller (“near-RT RIC”) 155, and a NR RAT plane 157.; [0070] The non-RT RIC 153 is a logical function that receiving second authentication data representative of a second authentication to deploy a machine learning model on the serving hub device enables non-real-time control and optimization of RAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in the near-RT RIC 155.; [0074] An xAPP 159 is an application designed to run on the near-RT RIC 155. Such an application 159 is likely to consist of one or more microservices and at the point of on-boarding will identify which data it consumes and which data it provides. The is disaggregated from the xApp xAPP 159 may be independent of the wherein the machine learning model near-RT RIC 155 and may be proprietary or provided by any third party. The E2 enables a direct association between the xAPP 159 and the RAN functionality.); and
based on the first authentication to deploy the xApp and the second authentication to deploy the machine learning model ([0108] As a pre-condition, it is assumed that the P-QoS based on the first authentication to deploy the xApp xAPP 401 has subscribed to receive QoS parameters for specific area or specific UEs from E2 node 173 (e.g., gNB 210 equivalent) via the RIC platform. In addition, it is assumed that one or more PDU sessions are established for the respective UEs (note that the UEs are note depicted in Figure 4).; [0111] At Step 2, a and the second authentication to deploy the machine learning model trained AI/ML model is sent to P-QoS xAPP 401 by the non-RT RIC 153 over Al interface / Open API (see messaging 413). Alternatively, the trained AI/ML model may be sent by the near-RT RIC 155 via Open API. The trained the model can be related to the UE expected behavior (expected location, traffic demand, sequence of handovers) and/or RAN expected status (expected performance downgrade, expected UL/DL traffic demand, expected backhaul conditions, expected DRB load) for a given time frame and area. Here, prior receiving the trained model, the P-QoS xAPP 401 may also request the type of AI/ML model to be used, or the expected accuracy / training configuration.),
enabling authenticated communication for a model manager device that manages the machine learning model via a group of application programming interfaces ([0111] At Step 2, a trained enabling authenticated communication for a model manager device that manages the machine learning model via a group of application programming interfaces AI/ML model is sent to P-QoS xAPP 401 by the non-RT RIC 153 over Al interface / Open API (see messaging 413). Alternatively, the trained AI/ML model may be sent by the near-RT RIC 155 via Open API.),
the group of application programming interfaces comprising: a predict application programming interface in which the machine learning model receives a request from the xApp and, in response, provides a prediction to the xApp to satisfy the request ([0111] At Step 2, a trained AI/ML model is sent to P-QoS xAPP 401 by the non-RT RIC 153 over a predict application programming interface Al interface / Open API (see messaging 413). Alternatively, the in response, provides a prediction to the xApp to satisfy the request trained AI/ML model may be sent by the near-RT RIC 155 via Open API. The trained the model can be related to the UE expected behavior (expected location, traffic demand, sequence of handovers) and/or RAN expected status (expected performance downgrade, expected UL/DL traffic demand, expected backhaul conditions, expected DRB load) for a given time frame and area. Here, prior receiving the trained model, the in which the machine learning model receives a request from the xApp P-QoS xAPP 401 may also request the type of AI/ML model to be used, or the expected accuracy / training configuration.); and
a fine tune application that, based on a fine tune instruction from the xApp, adjusts at least one model weight of the machine learning model based on a received dataset, resulting in a tuned machine learning model ([0111] Here, prior receiving the trained model, the based on a fine tune instruction from the xApp P-QoS xAPP 401 may also request the type of AI/ML model to be used, or the expected accuracy / training configuration.; [0076] Figure 2 depicts a procedure 200 for configuring a predictive QoS adaptation pattern, according embodiments of the disclosure. The procedure 200 involves a RAN control entity 205 (i.e., including an Al-enabled QoS adaptation function), a gNB 210, a trained AI- traffic/mobility model 215, and a 5G core network (“5GC”) 220. The RAN control entity 205 may be one embodiment of the intelligent control unit 115, the gNB 210 may be one embodiment of the base unit 111, and the 5GC 220 may be one embodiment of the mobile core network 120.; [0079] At step 2, upon receiving the QoS flow information, the a fine tune application that RAN control entity 205 requests and obtains resulting in a tuned machine learning model a trained AI/ML model (i.e., Al-traffic/mobility model 215) on the expected traffic of the target cell and/or the mobility for the respective UE (based on request or subscription, see messaging 230).; [0080] The AI/ML model(s) can be based on one of the following types:; [0081] 1) adjusts at least one model weight of the machine learning model based on a received dataset Supervised learning model using training data based with a known label: algorithms for this category can vary e.g. regression, k-means NN, decision tree algorithms, SVN, Bayesian algorithms etc. This allows that the ML training host and the ML model host are either co-located within the same entity (e.g. centralized Al function) or distributed in different entities (e.g. non-RT RIC 153 and near-RT RIC 155).), and
calls a deploy application programming interface to deploy the tuned machine learning model on the serving hub device ([0111] At Step 2, to deploy the tuned machine learning model on the serving hub device a trained AI/ML model is sent to P-QoS xAPP 401 by the non-RT RIC 153 over calls a deploy application programming interface Al interface / Open API (see messaging 413). Alternatively, the trained AI/ML model may be sent by the near-RT RIC 155 via Open API. The trained the model can be related to the UE expected behavior (expected location, traffic demand, sequence of handovers) and/or RAN expected status (expected performance downgrade, expected UL/DL traffic demand, expected backhaul conditions, expected DRB load) for a given time frame and area. Here, prior receiving the trained model, the P-QoS xAPP 401 may also request the type of AI/ML model to be used, or the expected accuracy / training configuration.).
Ranganath and Pateromichelakis are considered to be analogous to the claimed invention because they are in the same field of network and edge computing. In view of the teachings of Ranganath, it would have been obvious for a person of ordinary skill in the art to apply the teachings of Pateromichelakis to Ranganath before the effective filing date of the claimed invention in order to extend the QoS prediction and multi-QoS profile features by configuring a pattern of predicted QoS profiles for the QoS flow, based on an Al function (cf. Pateromichelakis, [0048] To solve the above discussed problems with QoS adaptation, the present disclosure uses AI/ML models to extend the QoS prediction and multi-QoS profile features by configuring a pattern of predicted QoS profiles for the QoS flow, based on an Al function.).
Regarding claim 2 and analogous claim 13, Ranganath, as modified by Pateromichelakis, teaches The serving hub device of claim 1 and The non-transitory computer-readable medium of claim 12, respectively.
Pateromichelakis teaches wherein the received dataset is a received first dataset ([0079] At step 2, upon wherein the received dataset is a received first dataset receiving the QoS flow information, the RAN control entity 205 requests and obtains a trained AI/ML model (i.e., Al-traffic/mobility model 215) on the expected traffic of the target cell and/or the mobility for the respective UE (based on request or subscription, see messaging 230).), and
wherein the group of application programming interfaces further comprises at least one of: the deploy application programming interface that enables authenticated deployment, to the serving hub device, of the machine learning model that was pre-trained by the model manager device according to a second dataset ([0095] At Step la, the gNB 210 subscribes to the Al function 305 to be notified on predictive and/or prescriptive analytics on the expected QoS adaptation pattern (see messaging 315). Alternatively, the the deploy application programming interface that enables authenticated deployment gNB 210 performs a one-time request to receive analytics and in this request, it configures the reporting which is needed by the Al function 305 (e.g., format, accuracy, periodicity, type of analytics). This is followed by a response (ACK/NACK) from the Al function 305 as acknowledgement. In the request/subscription message, the gNB 210 can also request to the serving hub device, of the machine learning model that was pre-trained by the model manager device according to a second dataset the type of AI/ML model to be used, or the expected accuracy / training configuration (and let the Al function 305 apply the most preferable algorithm).; [0096] At Step lb, the gNB 210, after the subscription / request for receiving the expected QoS adaptation pattern, provides the QoS parameters which are needed at the Al function to provide predictive/prescriptive analytics (see messaging 317).);
a retrain application programming interface that, based on a retrain instruction from the xApp, retrains all model weights of the machine learning model based on a received third dataset, resulting in a retrained machine learning model, and calls the deploy application programming interface to deploy the retrained machine learning model on the serving hub device ([0111] Here, prior receiving the trained model, the based on a retrain instruction from the xApp P-QoS xAPP 401 may also request the type of AI/ML model to be used, or the expected accuracy / training configuration.; [0076] Figure 2 depicts a procedure 200 for configuring a predictive QoS adaptation pattern, according embodiments of the disclosure. The procedure 200 involves a RAN control entity 205 (i.e., including an Al-enabled QoS adaptation function), a gNB 210, a trained AI- traffic/mobility model 215, and a 5G core network (“5GC”) 220. The RAN control entity 205 may be one embodiment of the intelligent control unit 115, the gNB 210 may be one embodiment of the base unit 111, and the 5GC 220 may be one embodiment of the mobile core network 120.; [0079] At step 2, upon receiving the QoS flow information, the a retrain application programming interface that RAN control entity 205 requests and obtains resulting in a retrained machine learning model a trained AI/ML model (i.e., Al-traffic/mobility model 215) on the expected traffic of the target cell and/or the mobility for the respective UE (based on request or subscription, see messaging 230).; [0080] The AI/ML model(s) can be based on one of the following types:; [0081] 1) retrains all model weights of the machine learning model based on a received third dataset Supervised learning model using training data based with a known label: algorithms for this category can vary e.g. regression, k-means NN, decision tree algorithms, SVN, Bayesian algorithms etc. This allows that the ML training host and the ML model host are either co-located within the same entity (e.g. centralized Al function) or distributed in different entities (e.g. non-RT RIC 153 and near-RT RIC 155).; [0111] At Step 2, to deploy the retrained machine learning model on the serving hub device a trained AI/ML model is sent to P-QoS xAPP 401 by the non-RT RIC 153 over calls the deploy application programming interface Al interface / Open API (see messaging 413). Alternatively, the trained AI/ML model may be sent by the near-RT RIC 155 via Open API. The trained the model can be related to the UE expected behavior (expected location, traffic demand, sequence of handovers) and/or RAN expected status (expected performance downgrade, expected UL/DL traffic demand, expected backhaul conditions, expected DRB load) for a given time frame and area. Here, prior receiving the trained model, the P-QoS xAPP 401 may also request the type of AI/ML model to be used, or the expected accuracy / training configuration.).
Ranganath and Pateromichelakis are combinable for the same rationale as set forth above with respect to claim 1.
Regarding claim 3 and analogous claim 14, Ranganath, as modified by Pateromichelakis, teaches The serving hub device of claim 1 and The non-transitory computer-readable medium of claim 12, respectively.
Ranganath teaches wherein the model manager device is situated in the near real time radio access network intelligent controller and uses resources of the near real time radio access network intelligent controller to process all calls to the group of application programming interfaces ([0070] The xApps 420 also includes an wherein the model manager device xApp manager 425, which is a logical element/entity that leverages observation data, and generates meaningful insights/knowledge using one or more AI/ML models 3 c 24. The observation data can include measurement data 415 and/or platform telemetry data (or profiling information). For example, the xApp manager 425 collects E2 measurement data 415 via the E2 mediation function 460 and telemetry data via a collection agent (see e.g., FIG. 5), and analyzes the collected E2 measurement data 415 and telemetry data to determine HW, SW, and/or NW resource allocations for individual xApps 410. This may involve, for example, determining to scale up or down HW, SW, and/or NW resources for individual xApps 410, E2 nodes, and/or other elements in the O-RAN framework. The uses resources of the near real time radio access network intelligent controller to process all calls to the group of application programming interfaces resource allocations can also be included in signaling and/or PDUs/messages that are provided to individual xApps 410 via the service bus 435, and/or in events 416 provided to individual E2 nodes via the E2 mediation function 460 and the E2 interface. In these implementations, the events 416 and/or PDUs/messages can include instructions, commands, and/or relevant information (e.g., scaling factors, configuration data, and/or the like) for re-allocating and/or adjusting HW, SW, and/or NW resources for individual xApps 410 and/or individual RANFs operating on or by one or more E2 nodes. The xApp manager 425 adjusts or otherwise determines HW, SW, and/or NW resource usage/allocations according to service requirements for one or more network slices or service slices. (e.g., as defined by KPIs, KPMs, and/or SLAs). The is situated in the near real time radio access network intelligent controller near-RT RIC's 414 (or the xApp manager's 425) control over xApps 410 and/or E2 nodes is steered or otherwise guided according to one or more policies 441 and/or enrichment information provided by the non-RT RIC 412 over the A1 interface.).
Ranganath and Pateromichelakis are combinable for the same rationale as set forth above with respect to claim 1.
Claims 4, 11, 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganath, in view of Pateromichelakis, and further in view of Balasubramanian et al. (NPL: "RIC: A RAN Intelligent Controller Platform for AI-Enabled Cellular Networks", hereinafter 'Balasubramanian').
Regarding claim 4, Ranganath, as modified by Pateromichelakis, teaches The serving hub device of claim 1.
Ranganath, as modified by Pateromichelakis, fails to teach wherein the model manager device is situated in the service management and orchestration device and uses resources of the service management and orchestration device to process specified calls to the group of application programming interfaces, while exposing the predict application programming interface in the serving hub device.
Balasubramanian teaches wherein the model manager device is situated in the service management and orchestration device and uses resources of the service management and orchestration device to process specified calls to the group of application programming interfaces, while exposing the predict application programming interface in the serving hub device ([ML-Based Control Loops, pg. 11-12] The life-cycle training and mapping of the AI/ML models for the three control loops is illustrated in Figure 4. Loop 3: wherein the model manager device is situated in the service management and orchestration device The ML/AI analytics engine for loop 3 uses RAN KPI statistics reported from the RAN nodes to SMO over the O1 interface as the training dataset to build its ML models. uses resources of the service management and orchestration device to process specified calls to the group of application programming interfaces, while exposing the predict application programming interface in the serving hub device SMO uses these models to make accurate decisions on policies and configuration of KPI objectives. These decisions are further communicated to the near-real-time RIC over A1. The aforementioned procedure is outlined in Steps 1–7 in Figure 4.; Loop 2: Due to the near-real-time nature of loop 2, the ML-based microservices at the RIC use hybrid models, comprising a mix of both offline and online ML. Online ML models (e.g., deep/recurrent neural networks, reinforcement learning) can achieve lower control loop latency since they are typically processed on a single stream of incoming RAN data to the RIC. However, since online ML models suffer from accuracy in generating optimized RRM decisions, complementary offline ML models are used leveraging historical information in R-NIB. Typically, while inferences are being made in loop 2 (in the order of millisecond), larger time-scale analysis is continuously being done in loop 3. Feedback on the precision and accuracy of the predictions in loop 2 is provided to the nonreal-time RIC in loop 3 via the O1 interface. This allows for fine tuning the ML models and guides the operation of the overall application toward a certain objective. If the ML models in loop 2 misbehave or exhibit degraded performance, the nonreal-time RIC may instruct loop 2 to terminate the ML model or switch to a more improved model. This results in enhanced RRM decisions at the RIC in near-real-time, as shown in Step 7; Loop 3: SMO offers policy guidance on the minimum fraction of traffic that should be split and served on any base station (eNB or gNB) participating in DC for any UE. It uses offline ML models built from large historical RAN KPI data reported over O1 to efficiently compute this threshold for more recent RAN conditions reflecting up to the current state. For example, offline ML models could suggest a load imbalance across the pairs of base stations, participating in DC, whose traffic split does not meet this minimum threshold. Such threshold fractions are communicated as policy guidance to the RIC over A1 and/or to the RAN over O1, and can be updated over coarser time scales.).
Ranganath, Pateromichelakis, and Balasubramanian are considered to be analogous to the claimed invention because they are in the same field of network and edge computing. In view of the teachings of Ranganath and Pateromichelakis, it would have been obvious for a person of ordinary skill in the art to apply the teachings of Balasubramanian to Ranganath before the effective filing date of the claimed invention in order to improve customer experience and optimize spectral efficiency by using machine learning (ML)-driven policies to tailor the RAN for unique spectrum position and geography based on a holistic area-wide network view (cf. Balasubramanian, [Introduction] Disaggregation lowers the barrier to entry for new entrants, expands the ecosystem beyond incumbent domain vendors, allows mixing and matching best of breed technology parts to reduce costs and foster innovation that ultimately improves the end-user Quality of Experience (QoE) by efficient network customization. Disaggregation improves customer experience and optimizes spectral efficiency by using machine learning (ML)-driven policies to tailor the RAN for unique spectrum position and geography based on a holistic area-wide network view. Finally, by decoupling the CP and UP, the RAN is more flexible and allows for independent scaling.).
Regarding claim 11, Ranganath, as modified by Pateromichelakis, teaches The serving hub device of claim 1.
Ranganath, as modified by Pateromichelakis, fails to teach wherein the operations further comprise performing a global sharing procedure in which a pre-trained machine learning model that is trained on global data or local data is shared by the service management and orchestration device to another service management and orchestration device.
Balasubramanian teaches wherein the operations further comprise performing a global sharing procedure in which a pre-trained machine learning model that is trained on global data or local data is shared by the service management and orchestration device to another service management and orchestration device ([DC Optimization, pg. 12] Loop 3: shared by the service management and orchestration device to another service management and orchestration device SMO offers policy guidance on the minimum fraction of traffic that should be split and served on any base station (eNB or gNB) participating in DC for any UE. It uses performing a global sharing procedure in which a pre-trained machine learning model that is trained on global data or local data offline ML models built from large historical RAN KPI data reported over O1 to efficiently compute this threshold for more recent RAN conditions reflecting up to the current state. For example, offline ML models could suggest a load imbalance across the pairs of base stations, participating in DC, whose traffic split does not meet this minimum threshold. Such threshold fractions are communicated as policy guidance to the RIC over A1 and/or to the RAN over O1, and can be updated over coarser time scales.).
Ranganath, Pateromichelakis, and Balasubramanian are combinable for the same rationale as set forth above with respect to claim 4.
Regarding claim 15, Ranganath, as modified by Pateromichelakis, teaches The non-transitory computer-readable medium of claim 12.
Ranganath, as modified by Pateromichelakis, fails to teach further comprising a model manager device that manages the machine learning model, wherein the model manager device is situated in the service management and orchestration device and uses resources of the service management and orchestration device to process a group of calls to the group of application programming interfaces.
Balasubramanian teaches further comprising a model manager device that manages the machine learning model, wherein the model manager device is situated in the service management and orchestration device and uses resources of the service management and orchestration device to process a group of calls to the group of application programming interfaces ([ML-Based Control Loops, pg. 11-12] The life-cycle training and mapping of the AI/ML models for the three control loops is illustrated in Figure 4. Loop 3: further comprising a model manager device that manages the machine learning model, wherein the model manager device is situated in the service management and orchestration device The ML/AI analytics engine for loop 3 uses RAN KPI statistics reported from the RAN nodes to SMO over the O1 interface as the training dataset to build its ML models. and uses resources of the service management and orchestration device to process a group of calls to the group of application programming interfaces SMO uses these models to make accurate decisions on policies and configuration of KPI objectives. These decisions are further communicated to the near-real-time RIC over A1. The aforementioned procedure is outlined in Steps 1–7 in Figure 4.; Loop 2: Due to the near-real-time nature of loop 2, the ML-based microservices at the RIC use hybrid models, comprising a mix of both offline and online ML. Online ML models (e.g., deep/recurrent neural networks, reinforcement learning) can achieve lower control loop latency since they are typically processed on a single stream of incoming RAN data to the RIC. However, since online ML models suffer from accuracy in generating optimized RRM decisions, complementary offline ML models are used leveraging historical information in R-NIB. Typically, while inferences are being made in loop 2 (in the order of millisecond), larger time-scale analysis is continuously being done in loop 3. Feedback on the precision and accuracy of the predictions in loop 2 is provided to the nonreal-time RIC in loop 3 via the O1 interface. This allows for fine tuning the ML models and guides the operation of the overall application toward a certain objective. If the ML models in loop 2 misbehave or exhibit degraded performance, the nonreal-time RIC may instruct loop 2 to terminate the ML model or switch to a more improved model. This results in enhanced RRM decisions at the RIC in near-real-time, as shown in Step 7; Loop 3: SMO offers policy guidance on the minimum fraction of traffic that should be split and served on any base station (eNB or gNB) participating in DC for any UE. It uses offline ML models built from large historical RAN KPI data reported over O1 to efficiently compute this threshold for more recent RAN conditions reflecting up to the current state. For example, offline ML models could suggest a load imbalance across the pairs of base stations, participating in DC, whose traffic split does not meet this minimum threshold. Such threshold fractions are communicated as policy guidance to the RIC over A1 and/or to the RAN over O1, and can be updated over coarser time scales.).
Ranganath, Pateromichelakis, and Balasubramanian are combinable for the same rationale as set forth above with respect to claim 4.
Regarding claim 16, Ranganath, as modified by Pateromichelakis and Balasubramanian, teaches The non-transitory computer-readable medium of claim 15.
Balasubramanian teaches wherein the model manager device exposes the predict application programming interface in the serving hub and uses resources of the near real time radio access network intelligent controller to process calls to the predict application ([ML-Based Control Loops, pg. 11-12] The life-cycle training and mapping of the AI/ML models for the three control loops is illustrated in Figure 4. Loop 3: The ML/AI analytics engine for loop 3 uses RAN KPI statistics reported from the RAN nodes to SMO over the O1 interface as the training dataset to build its ML models. wherein the model manager device exposes the predict application programming interface in the serving hub SMO uses these models to make accurate decisions on policies and configuration of KPI objectives. These decisions are further uses resources of the near real time radio access network intelligent controller to process calls to the predict application communicated to the near-real-time RIC over A1. The aforementioned procedure is outlined in Steps 1–7 in Figure 4.; Loop 2: Due to the near-real-time nature of loop 2, the ML-based microservices at the RIC use hybrid models, comprising a mix of both offline and online ML. Online ML models (e.g., deep/recurrent neural networks, reinforcement learning) can achieve lower control loop latency since they are typically processed on a single stream of incoming RAN data to the RIC. However, since online ML models suffer from accuracy in generating optimized RRM decisions, complementary offline ML models are used leveraging historical information in R-NIB. Typically, while inferences are being made in loop 2 (in the order of millisecond), larger time-scale analysis is continuously being done in loop 3. Feedback on the precision and accuracy of the predictions in loop 2 is provided to the nonreal-time RIC in loop 3 via the O1 interface. This allows for fine tuning the ML models and guides the operation of the overall application toward a certain objective. If the ML models in loop 2 misbehave or exhibit degraded performance, the nonreal-time RIC may instruct loop 2 to terminate the ML model or switch to a more improved model. This results in enhanced RRM decisions at the RIC in near-real-time, as shown in Step 7; Loop 3: SMO offers policy guidance on the minimum fraction of traffic that should be split and served on any base station (eNB or gNB) participating in DC for any UE. It uses offline ML models built from large historical RAN KPI data reported over O1 to efficiently compute this threshold for more recent RAN conditions reflecting up to the current state. For example, offline ML models could suggest a load imbalance across the pairs of base stations, participating in DC, whose traffic split does not meet this minimum threshold. Such threshold fractions are communicated as policy guidance to the RIC over A1 and/or to the RAN over O1, and can be updated over coarser time scales.).
Ranganath, Pateromichelakis, and Balasubramanian are combinable for the same rationale as set forth above with respect to claim 4.
Claims 10, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganath, in view of Pateromichelakis, and further in view of Pham et al. (NPL: "HexRIC: Building a Better Near-real Time Network Controller for the Open RAN Ecosystem", hereinafter 'Pham').
Regarding claim 10 and analogous claim 20, Ranganath, as modified by Pateromichelakis, teaches The serving hub device of claim 1 and The method of claim 17, respectively.
Ranganath, as modified by Pateromichelakis, fails to teach wherein the operations further comprise performing a global training procedure in which the machine learning model is trained on global data that is collected from at least one of: multiple different service management and orchestration devices or multiple different radio access network intelligent controllers.
Pham teaches wherein the operations further comprise performing a global training procedure in which the machine learning model is trained on global data that is collected from at least one of: multiple different service management and orchestration devices or multiple different radio access network intelligent controllers ([The MLOps Framework., pg. 17] With a view to simplifying ML-related operations within the RIC, HexRIC includes a novel MLOps Framework. The framework has been designed to address a number of challenges including: (i) enhancing ease-of-use, (ii) automating AI/ML workflows, (iii) improving scalability while reducing complexity, and (iv) ML model monitoring, evaluation, retraining, and redeployment on a near-RT timescale. As shown in Fig. 3, the framework consists of a Data Broker, a Model LCM component, a Monitoring and Evaluation (M&E) system, and a number of ML Executors and Serving Servers, in addition to a feature store from the Feast Project [3], an event monitoring service such as Prometheus [6], and MinIO [16] and MariaDB for storing models and artifacts. In particular, the performing a global training procedure in which the machine learning model is trained on global data that is collected from at least one of Data Broker aggregates and processes data from a number of sources, for e.g., xApps, the multiple different service management and orchestration devices RAN, external applications, and the multiple different radio access network intelligent controllers non-RT RIC. The processed data is then stored in the Feast feature store. Model LCM performs ML model lifecycle management and validation, while leveraging the ML Executors for model training and Serving Servers for inference. The ML Executor is a generic component used to execute any kind of ML file and decouples the MLOps Framework from specific ML libraries, thereby allowing for models to use all kinds of libraries, greatly enhancing ease-of-use.).
Ranganath, Pateromichelakis, and Pham are considered to be analogous to the claimed invention because they are in the same field of network and edge computing. In view of the teachings of Ranganath and Pateromichelakis, it would have been obvious for a person of ordinary skill in the art to apply the teachings of Pham to Ranganath before the effective filing date of the claimed invention in order to simplify and automate the life-cycle management of ML models within the near-RT RIC (cf. Pham, [A Machine Learning Operations Framework., pg. 16] HexRIC introduces a machine learning operations (MLOps) framework to simplify and automate the life-cycle management of ML models within the near-RT RIC. With HexRIC’s MLOps framework, ML scientists and engineers can focus on key model development tasks without having to worry about the complexities of the RIC.).
Claims 5-7, 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganath, in view of Pateromichelakis, and further in view of Li et al. (NPL: "DLHub: Simplifying publication, discovery, and use of machine learning models in science", hereinafter 'Li').
Regarding claim 5 and analogous claim 18, Ranganath, as modified by Pateromichelakis, teaches The serving hub device of claim 1 and The method of claim 17, respectively.
Ranganath, as modified by Pateromichelakis, fails to teach wherein the operations further comprise performing a caching procedure that determines, from among a group of machine learning models that is deployed on the serving hub device, a subscribed group of machine learning models that is to be placed in a cache.
Li teaches wherein the operations further comprise performing a caching procedure that determines, from among a group of machine learning models that is deployed on the serving hub device, a subscribed group of machine learning models that is to be placed in a cache ([4.3. Inference execution system, pg. 69] funcX: The funcX service implements a secure task execution model with hierarchical queues for reliability. Tasks are submitted to the funcX Web service where they are queued for execution. A Python Forwarder process is operated for each endpoint. The Forwarder retrieves tasks from the cloud-hosted queues and transmits them to the endpoint via a secure, low-latency, and reliable message communication channel. Once delivered to the endpoint, tasks are internally queued until they can be scheduled for execution on the resource. Results are returned via the same channel and deposited in a result queue until they can be retrieved by the user. funcX uses a Redis store to implement the cloud-based queues. Redis is an easy-to-scale, in-memory key–value store. Each function execution request is stored in a Redis hashmap and the task identifier is added to the endpoint’s queue. funcX uses ZeroMQ to establish high performance communication channels between the forwarder and endpoint.; DLHub and funcX: When a user publishes a model to DLHub, we performing a caching procedure that determines, from among a group of machine learning models that is deployed on the serving hub device, a subscribed group of machine learning models that is to be placed in a cache create and register a function with funcX and associate it with the DLHub servable container. This allows funcX to deploy the servable on-demand to perform DLHub invocations. When a user invokes a servable using DLHub the request is routed to a DLHub operated funcX endpoint. The funcX agent will then deploy the servable and, once the servable is ready, deliver the request for execution. The funcX agent is responsible for deploying and managing servables, monitoring incoming requests from DLHub (via the funcX service), and then executing waiting tasks. The funcX agent can be deployed in Docker environments, Kubernetes clusters, HPC resources via Singularity or Shifter, or locally via any of these containerization mechanisms.).
Ranganath, Pateromichelakis, and Li are considered to be analogous to the claimed invention because they are in the same field of network and edge computing. In view of the teachings of Ranganath and Pateromichelakis, it would have been obvious for a person of ordinary skill in the art to apply the teachings of Li to Ranganath before the effective filing date of the claimed invention in order to publish and share models and to serve them on a range of available computing resources (cf. Li, [Abstract, pg. 64] Machine Learning (ML) has become a critical tool enabling new methods of analysis and driving deeper understanding of phenomena across scientific disciplines. There is a growing need for ‘‘learning systems’’ to support various phases in the ML lifecycle. While others have focused on supporting model development, training, and inference, few have focused on the unique challenges inherent in science, such as the need to publish and share models and to serve them on a range of available computing resources. In this paper, we present the Data and Learning Hub for science (DLHub), a learning system designed to support these use cases. Specifically, DLHub enables publication of models, with descriptive metadata, persistent identifiers, and flexible access control. It packages arbitrary models into portable servable containers, and enables low-latency, distributed serving of these models on heterogeneous compute resources. We show that DLHub supports low-latency model inference comparable to other model serving systems including TensorFlow Serving, SageMaker, and Clipper, and improved performance, by up to 95%, with batching and memoization enabled. We also show that DLHub can scale to concurrently serve models on 500 containers. Finally, we describe five case studies that highlight the use of DLHub for scientific applications.).
Regarding claim 6, Ranganath, as modified by Pateromichelakis and Li, teaches The serving hub device of claim 5.
Li teaches wherein the caching procedure determines the subscribed group of machine learning models as a function of at least one of: a first criterion, satisfaction of which is indicative of a low latency constraint associated with the xApp ([DLHub and funcX:, pg. 69] When a user of machine learning models publishes a model to DLHub, we create and register a function with funcX and associate it with the DLHub servable container. This allows funcX to deploy the servable on-demand to perform DLHub invocations. When a user invokes a servable using DLHub the request is routed to a DLHub operated funcX endpoint. The funcX agent will then deploy the servable and, once the servable is ready, deliver the request for execution. The funcX agent is responsible for deploying and managing servables, monitoring incoming requests from DLHub (via the funcX service), and then executing waiting tasks. The funcX agent can be deployed in Docker environments, Kubernetes clusters, HPC resources via Singularity or Shifter, or locally via any of these containerization mechanisms.; [4.3. Inference execution system, pg. 69] DLHub coordinates the execution of inference tasks on remote resources. This architecture focuses on high performance and low latency model inference as well as flexibility in terms of where inference tasks are executed. Specifically, DLHub allows researchers to execute inference tasks on Kubernetes clusters, HPC resources, or clouds using various container technologies (e.g., Docker, Singularity or Shifter), on edge devices, or even on their own execution resources using any of these containerization mechanisms. DLHub supports both synchronous and asynchronous task execution. In asynchronous mode, the DLHub SDK returns a task UUID that can be used subsequently to monitor the status of the task and retrieve its result.; Implementation: DLHub’s on-demand inference is built on the funcX distributed Function-as-a-Service platform. We briefly describe funcX and outline how it is used by DLHub. funcX: funcX enables the managed execution of functions— snippets of Python code—on arbitrary remote resources. Users can register and discover functions through a cloud-hosted service and then execute those functions with arbitrary input parameters on arbitrary endpoints. Where an endpoint abstracts a specific compute resource, whether a single edge device or a supercomputer, in a manner defined by the funcX agent software. The funcX service implements a secure task execution model with hierarchical queues for reliability. caching procedure determines the subscribed group of machine learning models as a function of at least one of Tasks are submitted to the funcX Web service where they are queued for execution. A Python Forwarder process is operated for each endpoint. The Forwarder satisfaction of which is indicative of a low latency constraint associated with the xApp retrieves tasks from the cloud-hosted queues and transmits them to the endpoint via a secure, low-latency, and reliable message communication channel.),
a second criterion, satisfaction of which is indicative of a recency of use ([6.7. Discussion, pg. 73] We briefly discuss the lessons learned by using DLHub in these five use cases. Prior to using DLHub, these use cases required a substantial amount of human effort to manually manage model versions, publish and share models with others, deploy complex software environments on distributed computing resources, and reliably deploy models for real-time inferences at scale. DLHub provides several benefits: First, DLHub manages different versions of the same model, removing challenges associated with tracking model versions and using incorrect versions. A key side effect of this is that researchers are able to a second criterion, satisfaction of which is indicative of a recency of use deploy new versions of their models and compare the performance to any of the previously published versions. Second, DLHub’s on-demand inference system abstracts the complexity of deploying models at different computing resources and enables researchers to easily deploy their models at scale, without requiring expert knowledge of batch submission interfaces and computing architectures. Finally, the containerization of models allows researchers to securely share models with others, removing the burden of porting models and environments to other locations.),
a third criterion, satisfaction of which is indicative of a frequency of use, or a fourth criterion, satisfaction of which is indicative of a subscription flow to a given machine learning model of the group of machine learning models.
Ranganath, Pateromichelakis, and Li are combinable for the same rationale as set forth above with respect to claim 5.
Regarding claim 7 and analogous claim 19, Ranganath, as modified by Pateromichelakis, teaches The serving hub device of claim 1 and The method of claim 17, respectively.
Ranganath, as modified by Pateromichelakis, fails to teach wherein the operations further comprise performing a model searching procedure that, in response to a search query, determines, from among a group of machine learning models that is deployed on the serving hub device, at least one machine learning model that satisfies the search query and communicates documentation associated with the at least one machine learning model.
Li teaches wherein the operations further comprise performing a model searching procedure that, in response to a search query, determines, from among a group of machine learning models that is deployed on the serving hub device, at least one machine learning model that satisfies the search query and communicates documentation associated with the at least one machine learning model ([4.3. Inference execution system, pg. 69] Implementation: DLHub’s on-demand inference is built on the funcX distributed Function-as-a-Service platform. We briefly describe funcX and outline how it is used by DLHub. funcX: funcX enables the managed execution of functions— snippets of Python code—on arbitrary remote resources. Users can register and discover functions through a cloud-hosted service and then execute those functions with arbitrary input parameters on arbitrary endpoints. Where an endpoint abstracts a specific compute resource, whether a single edge device or a supercomputer, in a manner defined by the funcX agent software. The funcX service implements a secure task execution model with hierarchical queues for reliability. performing a model searching procedure that, in response to a search query, determines, from among a group of machine learning models that is deployed on the serving hub device Tasks are submitted to the funcX Web service where they are queued for execution. A Python Forwarder process is operated for each endpoint. The Forwarder retrieves tasks from the cloud-hosted queues and transmits them to the endpoint via a secure, low-latency, and reliable message communication channel. Once delivered to the endpoint, tasks are internally queued until they can be scheduled for execution on the resource. Results are returned via the same channel and deposited in a result queue until they can be retrieved by the user. funcX uses a at least one machine learning model that satisfies the search query and communicates documentation associated with the at least one machine learning model Redis store to implement the cloud-based queues. Redis is an easy-to-scale, in-memory key–value store. Each function execution request is stored in a Redis hashmap and the task identifier is added to the endpoint’s queue. funcX uses ZeroMQ to establish high performance communication channels between the forwarder and endpoint.).
Ranganath, Pateromichelakis, and Li are combinable for the same rationale as set forth above with respect to claim 5.
Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganath, in view of Pateromichelakis, Li, and further in view of Pham.
Regarding claim 8, Ranganath, as modified by Pateromichelakis and Li, teaches The serving hub device of claim 7.
Ranganath, as modified by Pateromichelakis and Li, fails to teach wherein the model searching procedure is configured to interpret a natural language search query by matching search keywords to model keywords entered as metadata model tags upon deployment to the serving hub device.
Pham teaches wherein the model searching procedure is configured to interpret a natural language search query by matching search keywords to model keywords entered as metadata model tags upon deployment to the serving hub device ([The MLOps Framework., pg. 18] The operational workflow of the framework has been shown in Fig. 4. First, we have the On-boarding Stage, which involves uploading an on-boarding package to the Model LCM entity. This wherein the model searching procedure is configured to interpret a natural language search query by matching search keywords to model keywords entered as metadata model tags upon deployment to the serving hub device on-boarding package consists of the model, a set of artifacts supporting the model, a manifest containing the model metadata such as versioning information, required libraries, etc., and a set of input and output parameter types. In a major step towards enhancing simplicity, preparing the on-boarding package requires no prior domain knowledge regarding the RIC, for e.g., there is no need for implementing yet another xApp each time a new ML model is added. The on-boarding package then undergoes a validation step, and, depending on the nature of the model, one of three possible stages are executed. For untrained models, the framework executes the Training Stage. As part of this stage, the ML Executor executes the provided untrained model which is then trained on data from the feature store. The trained model is then stored in the model and artifacts database. On the other hand, the Serving and Retraining Stage leverages models that have been trained previously (either internally as part of the Training Stage or externally at the non-RT RIC) and are ready for deployment. The output from such models is then sent over the messaging infrastructure to other xApps for consumption. Model performance is monitored by Prometheus and analyzed by M&E to identify model drift. Model drift is categorized as either sudden or incremental, with the former resulting in retraining, while the latter necessitates replacement with a previously trained model.).
Ranganath, Pateromichelakis, Li, and Pham are considered to be analogous to the claimed invention because they are in the same field of network and edge computing. In view of the teachings of Ranganath, Pateromichelakis, and Li, it would have been obvious for a person of ordinary skill in the art to apply the teachings of Pham to Ranganath before the effective filing date of the claimed invention in order to simplify and automate the life-cycle management of ML models within the near-RT RIC (cf. Pham, [A Machine Learning Operations Framework., pg. 16] HexRIC introduces a machine learning operations (MLOps) framework to simplify and automate the life-cycle management of ML models within the near-RT RIC. With HexRIC’s MLOps framework, ML scientists and engineers can focus on key model development tasks without having to worry about the complexities of the RIC.).
Regarding claim 9, Ranganath, as modified by Pateromichelakis, Li, and Pham, teaches The serving hub device of claim 8.
Li teaches wherein the model searching procedure uses at least one of a named entity recognition process or a syntactical and semantic matching process ([4.1. Management service and catalog, pg. 68] Model repository: The primary function of the Management Service is to support the publication and discovery of models. DLHub defines a general model schema that is used to describe all published models. The schema includes standard publication metadata (e.g., creator, date, a named entity recognition process name, description) as well as ML specific or a syntactical and semantic matching process metadata such as model type (e.g., Keras, TensorFlow) and input and output data types. These metadata are registered with a search catalog to enable flexible discovery. Model discovery: DLHub’s discovery interface supports fine grained, access-controlled search across registered model meta data. It provides a model searching procedure uses at least one of rich search model, in which model metadata can be queried using free text queries, partial matching, range queries, faceted search, and more through both the DLHub CLI and SDK.).
Ranganath, Pateromichelakis, Li, and Pham are combinable for the same rationale as set forth above with respect to claim 8.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAGGIE MAIDO whose telephone number is (703) 756-1953. The examiner can normally be reached M-Th: 6am - 4pm.
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, Michael Huntley can be reached on (303) 297-4307. 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.
/MM/Examiner, Art Unit 2129
/MICHAEL J HUNTLEY/Supervisory Patent Examiner, Art Unit 2129
Prosecution Insights