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
Applicant’s submission dated 20 Apr. 2026—in which claims 1, 4, 8, 9, 12, 15, 16, 18, 21, 25, 26, 28, and 29 are amended, new claims 30 and 31 are added, and claims 1-31 are now pending—has been entered and is fully considered herein.
The amendment to claim 15 overcomes the previous objection thereto. Accordingly, the objection to claim 15 is hereby withdrawn.
Response to Arguments
Applicant’s arguments—set forth at pp. 10-14 in the Remarks with respect to independent claims 1-29—have been fully considered but are moot because the new grounds of rejection rely on one or more reference not applied in the prior rejection of record for some teaching or matter specifically challenged in the argument.
Applicant's amendment necessitated the new grounds 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).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate subsection(s) of 35 U.S.C. § 102 that forms the basis for the rejections under this section made in the Office Action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, 5, 7, 9, 12, 13, 16, 17, 19, 22, 25, 28, and 29 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by US 2020/0106536 (hereinafter, “BEDEKAR”).
Regarding claim 1, BEDEKAR comprises:
An apparatus (NCE 190) configured for wireless communications, comprising:
one or more memories (memory 171); and
one or more processors (processor 175) coupled to the one or more memories, the one or more processors being configured to cause the apparatus to:
provide, to a network entity (RAN node 170), an indication of cross-node machine learning information used for a cross-node machine learning session between the apparatus and a user equipment (UE), (UE 110) (¶¶ 0187-0189: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE, the UE capabilities, and the like; and Provide information 446 on the selected Scell (e.g., indication of the best Scell or top-N Scells) to the RAN node. The RAN node would then provide RRC reconfiguration information to the UE to configure information on the selected Scell(s). See block 450; ¶0180: [M]odel 430 takes as input a UE's measurements on a given Pcell (cell1) and outputs a prediction of the UE's CQI on a given Scell (cell2). With this approach, for each (cell1, cell2) pair, we would have a different model) wherein the network entity comprises an E2 node, (¶ 0135: There is an E2 reference point 230 (in ORAN) between the RIC near-RT 210 and the RAN node 170; ¶ 0152: Scell prediction module 420 also supports an interface towards a RAN node 170 for (i) receiving data from the RAN node 170; and (ii) providing a prediction 435 of the achievable SINR or SE achievable by a given UE. The interface is mappable to E2 interface in ORAN) and wherein the apparatus comprises a radio access network intelligent controller (RIC); (¶ 0117: NCE 190 includes a RIC module 140, comprising one of or both parts 140-1 and/or 140-2; ¶ 0122: RIC near-RT 210 and the RIC non-RT 220 could be implemented by a single NCE 190 or by multiple NCEs 190)
obtain machine learning information associated with the UE; and (¶ 0210: In step 635, the RAN node 170 transmits and the Scell prediction module 420 (as part of the RIC near-RT 210) receives Pcell, Scell measurements from UEs already assigned to Scells. In step 640, the Scell prediction module 420 (as part of the RIC near-RT 210) transmits and the model training module 410 (as part of RIC near-RT 210) receives Pcell, Scell measurements from UEs already assigned to Scells (see block 460 of FIG. 4); Fig. 5, block 455: Receive UE channel feedback/measurements on Pcell (470-2))
control the cross-node machine learning session based at least in part on the machine learning information. (¶ 0172: [T]raining by the model training module 410, the training based on the data 460 of UEs that have been assigned Scells; ¶ 0209: Pcell and Scell measurements can be gathered from the UEs 110 that have been assigned Scells 320. These measurements can be passed to the model training module 410 (at the RIC non-RT 220) to update the model training; ¶ 0213: [M]odel training module 410 updates the Scell channel quality prediction model, represented as AI/ML model 430 in FIG. 4. This updating occurs in block 643; ¶ 0226: [M]odel training can be performed at the RIC non-RT 220, e.g., by the model training module 410)
Regarding claim 2, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR further discloses:
wherein the cross-node machine learning information comprises one or more parameters supported by the apparatus in association with the cross-node machine learning session. (¶ 0152: An Scell prediction module 420 (which can be hosted at the RIC near-RT 210) may be used to predict the channel quality (e.g., spectral efficiency (SE) or SINR or CQI) achievable by a UE 110 on a given candidate Scell 320. The Scell prediction module 420 also supports an interface towards a RAN node 170 for (i) receiving data from the RAN node 170; and (ii) providing a prediction 435 of the achievable SINR or SE achievable by a given UE. The interface is mappable to E2 interface in ORAN; ¶ 0168: The Scell prediction module 420 supports an interface towards RIC non-RT 220 to facilitate Scell channel prediction model training by the model training module 410. The interface is mappable to Al interface in ORAN/xRAN; ¶ 0187: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE)
Regarding claim 5, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR further discloses:
wherein the one or more processors are configured to cause the apparatus to:
obtain capability information associated with the UE; and (¶ 0187: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE, the UE capabilities, and the like)
in response to obtaining the capability information, provide, to the network entity, an indication of a configuration associated with the cross-node machine learning session for the UE. (¶ 0188-0189: Provide information 446 on the selected Scell (e.g., indication of the best Scell or top-N Scells) to the RAN node. The RAN node would then provide RRC reconfiguration information to the UE to configure information on the selected Scell(s). See block 450)
Regarding claim 7, BEDEKAR, as applied above, anticipates the apparatus of claim 5. BEDEKAR further discloses:
wherein the one or more processors are configured to cause the apparatus to select a machine learning function or model for the UE to use for the cross-node machine learning session based at least in part on the capability information, (¶ 0187: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE, the UE capabilities, and the like)
wherein the indication of the configuration comprises an indication of the selected machine learning function or model. (¶ 0188-0189: Provide information 446 on the selected Scell (e.g., indication of the best Scell or top-N Scells) to the RAN node. The RAN node would then provide RRC reconfiguration information to the UE to configure information on the selected Scell(s). See block 450)
Regarding claim 9, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR further discloses:
wherein:
the one or more processors are configured to cause the apparatus to obtain, from the network entity, an indication of the cross-node machine learning session between the apparatus and the UE, and (Abstract: At a RAN node, the set of data is sent toward an S cell prediction module for the module to determine information suitable to enable Scell selection for the specific UE. . . . A node may train the ML algorithm using UE-related measurements; ¶ 0153: The Scell prediction module 420 receives from the RAN node 170 a list 490 of one or more candidate Scells. . . . The Scell prediction module 420 receives data from the RAN node 170 related to one or more UEs, comprising radio/channel measurements made by the UE on its primary carrier. See block 455)
to control the cross-node machine learning session, wherein the one or more processors are configured to cause the apparatus to control the cross-node machine learning session based at least in part on the indication of the cross-node machine learning session between the UE and the apparatus. (¶ 0209: Pcell and Scell measurements can be gathered from the UEs 110 that have been assigned Scells 320. These measurements can be passed to the model training module 410 (at the RIC non-RT 220) to update the model training)
Regarding claim 12, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR further discloses:
wherein:
the apparatus is configured to communicate with the network entity via an E2 interface; and (Fig. 2; ¶ 0135: There is an E2 reference point 230 (in ORAN) between the RIC near-RT 210 and the RAN node 170; ¶ 0152: Scell prediction module 420 also supports an interface towards a RAN node 170 for (i) receiving data from the RAN node 170; and (ii) providing a prediction 435 of the achievable SINR or SE achievable by a given UE. The interface is mappable to E2 interface in ORAN)
the network entity comprises a central unit (CU). (CU 196)
Regarding claim 13, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR further discloses:
wherein to control the cross-node machine learning session, the one or more processors are configured to cause the apparatus to:
determine a model structure based at least in part on the machine learning information; and (¶ 0179: [I]nformation (info.) 441 is information that defines the AI/ML model(s) 430 or corresponding machine-learning algorithm 431. For instance, for a NN or DNN, the information 441 can define and indicate weights and structure (e.g., number of layers and nodes, inputs, outputs) of the corresponding NN/DNN; ¶ 0213: [M]odel 430 may be defined by layer information and weights, for a neural network for instance)
provide, to the network entity, an indication of the determined model structure to be used by the UE. (¶ 0165: Scell prediction module 420 determines a prediction 435 of channel quality (e.g., spectral efficiency or SINR or CQI or some combination of these) achievable by the UE 110 on one or more Scells. The prediction can use AI/ML techniques such as a neural network in model 430 (or neural networks in models 430). Additional details are described below. The Scell prediction module 420 provides to the RAN node 170 the prediction 435 of the achievable channel quality (e.g., SINR or SE or CQI) of the UE on one or more Scells; ¶ 0166: RAN node 170 can then make (see block 445) a selection of the best Scell (possibly multiple Scells 320) for the UE 110 based on the channel quality prediction as well as other factors such as load of the Scell)
Regarding claim 16, BEDEKAR discloses:
An apparatus (RAN node 170) configured for wireless communications, comprising:
one or more memories (memory 155); and
one or more processors (processor 152) coupled to the one or more memories, the one or more processors being configured to cause the apparatus to:
obtain, from a network entity (NCE 190), an indication of cross-node machine learning information used for a cross-node machine learning session between the network entity and a user equipment (UE), (UE 110) (¶¶ 0187-0189: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE, the UE capabilities, and the like; and Provide information 446 on the selected Scell (e.g., indication of the best Scell or top-N Scells) to the RAN node. The RAN node would then provide RRC reconfiguration information to the UE to configure information on the selected Scell(s). See block 450; ¶0180: [M]odel 430 takes as input a UE's measurements on a given Pcell (cell1) and outputs a prediction of the UE's CQI on a given Scell (cell2). With this approach, for each (cell1, cell2) pair, we would have a different model) wherein the network entity comprises a radio access network intelligent controller (RIC), and (¶ 0117: NCE 190 includes a RIC module 140, comprising one of or both parts 140-1 and/or 140-2; ¶ 0122: RIC near-RT 210 and the RIC non-RT 220 could be implemented by a single NCE 190 or by multiple NCEs 190) wherein the apparatus comprises an E2 node; (¶ 0135: There is an E2 reference point 230 (in ORAN) between the RIC near-RT 210 and the RAN node 170; ¶ 0152: Scell prediction module 420 also supports an interface towards a RAN node 170 for (i) receiving data from the RAN node 170; and (ii) providing a prediction 435 of the achievable SINR or SE achievable by a given UE. The interface is mappable to E2 interface in ORAN)
provide, to the UE, a configuration for the cross-node machine learning session based at least in part on the cross-node machine learning information; (¶ 0166: RAN node 170, in response to the selection of the best Scell, sends RRC reconfiguration (reconfig) information to provide Scell information to the UE 110 for the selected Scell. See block 450. It is noted that if the RAN node sends Scell reconfig information (see block 450) for multiple Scells, the UE should try to connect to all of them)
obtain, via the cross-node machine learning session, machine learning information associated with the UE; (¶ 0210: In step 635, the RAN node 170 transmits and the Scell prediction module 420 (as part of the RIC near-RT 210) receives Pcell, Scell measurements from UEs already assigned to Scells. In step 640, the Scell prediction module 420 (as part of the RIC near-RT 210) transmits and the model training module 410 (as part of RIC near-RT 210) receives Pcell, Scell measurements from UEs already assigned to Scells (see block 460 of FIG. 4); Fig. 5, block 455: Receive UE channel feedback/measurements on Pcell (470-2))
provide, to the network entity via the cross-node machine learning session, the machine learning information; (¶ 0213: (and the RAN node 170 transmits [to the RIC) UE Pcell measurements in step 650)
obtain, from the network entity, output data generated from the machine learning information; and (¶ 0213: Scell prediction module 420 provides, in step 660, a new Scell channel quality prediction for the UE to the RAN node; ¶ 0188: [I]nformation 446 on the selected Scell (e.g., indication of the best Scell or top-N Scells) to the RAN node)
communicate with the UE based at least in part on the output data. (¶ 0189: The RAN node would then provide RRC reconfiguration information to the UE to configure information on the selected Scell(s). See block 450)
Regarding claim 17, BEDEKAR, as applied above, anticipates the apparatus of claim 16. BEDEKAR further discloses:
wherein the cross-node machine learning information comprises one or more parameters supported by the network entity in association with the cross-node machine learning session. (¶ 0152: An Scell prediction module 420 (which can be hosted at the RIC near-RT 210) may be used to predict the channel quality (e.g., spectral efficiency (SE) or SINR or CQI) achievable by a UE 110 on a given candidate Scell 320. The Scell prediction module 420 also supports an interface towards a RAN node 170 for (i) receiving data from the RAN node 170; and (ii) providing a prediction 435 of the achievable SINR or SE achievable by a given UE. The interface is mappable to E2 interface in ORAN; ¶ 0168: The Scell prediction module 420 supports an interface towards RIC non-RT 220 to facilitate Scell channel prediction model training by the model training module 410. The interface is mappable to Al interface in ORAN/xRAN; ¶ 0187: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE)
Regarding claim 19, BEDEKAR, as applied above, anticipates the apparatus of claim 16. BEDEKAR further discloses:
wherein the one or more processors are configured to cause the apparatus to:
provide, to the network entity, capability information associated with the UE; and (¶ 0187: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE, the UE capabilities, and the like)
in response to providing the capability information, obtain, from the network entity, an indication of the configuration associated with the cross-node machine learning session for the UE. (¶ 0188-0189: Provide information 446 on the selected Scell (e.g., indication of the best Scell or top-N Scells) to the RAN node. The RAN node would then provide RRC reconfiguration information to the UE to configure information on the selected Scell(s). See block 450)
Regarding claim 22, BEDEKAR, as applied above, anticipates the apparatus of claim 16. BEDEKAR further discloses:
wherein the one or more processors are configured to cause the apparatus to:
select the configuration for the cross-node machine learning information based at least in part on the indication of the cross-node machine learning information. (¶ 0166: RAN node 170, in response to the selection of the best Scell, sends RRC reconfiguration (reconfig) information to provide Scell information to the UE 110 for the selected Scell. See block 450. It is noted that if the RAN node sends Scell reconfig information (see block 450) for multiple Scells, the UE should try to connect to all of them)
Regarding claim 25, BEDEKAR, as applied above, anticipates the apparatus of claim 16. BEDEKAR further discloses:
wherein:
the apparatus comprises a central unit (CU) (CU 196) configured to communicate with the network entity via an E2 interface. (¶ 0135: There is an E2 reference point 230 (in ORAN) between the RIC near-RT 210 and the RAN node 170; ¶ 0152: Scell prediction module 420 also supports an interface towards a RAN node 170 for (i) receiving data from the RAN node 170; and (ii) providing a prediction 435 of the achievable SINR or SE achievable by a given UE. The interface is mappable to E2 interface in ORAN)
Regarding claim 28, BEDEKAR discloses:
A method of wireless communication by an apparatus (NCE 190), comprising:
providing, to a network entity (RAN node 170), an indication of cross-node machine learning information used for a cross-node machine learning session between the apparatus and a user equipment (UE), (UE 110) (¶¶ 0187-0189: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE, the UE capabilities, and the like; and Provide information 446 on the selected Scell (e.g., indication of the best Scell or top-N Scells) to the RAN node. The RAN node would then provide RRC reconfiguration information to the UE to configure information on the selected Scell(s). See block 450; ¶0180: [M]odel 430 takes as input a UE's measurements on a given Pcell (cell1) and outputs a prediction of the UE's CQI on a given Scell (cell2). With this approach, for each (cell1, cell2) pair, we would have a different model) wherein the network entity comprises an E2 node (¶ 0135: There is an E2 reference point 230 (in ORAN) between the RIC near-RT 210 and the RAN node 170; ¶ 0152: Scell prediction module 420 also supports an interface towards a RAN node 170 for (i) receiving data from the RAN node 170; and (ii) providing a prediction 435 of the achievable SINR or SE achievable by a given UE. The interface is mappable to E2 interface in ORAN), and wherein the apparatus comprises a radio access network intelligent controller (RIC) (¶ 0117: NCE 190 includes a RIC module 140, comprising one of or both parts 140-1 and/or 140-2; ¶ 0122: RIC near-RT 210 and the RIC non-RT 220 could be implemented by a single NCE 190 or by multiple NCEs 190);
obtaining machine learning information associated with the UE; and (¶ 0210: In step 635, the RAN node 170 transmits and the Scell prediction module 420 (as part of the RIC near-RT 210) receives Pcell, Scell measurements from UEs already assigned to Scells. In step 640, the Scell prediction module 420 (as part of the RIC near-RT 210) transmits and the model training module 410 (as part of RIC near-RT 210) receives Pcell, Scell measurements from UEs already assigned to Scells (see block 460 of FIG. 4); Fig. 5, block 455: Receive UE channel feedback/measurements on Pcell (470-2))
controlling the cross-node machine learning session based at least in part on the machine learning information. (¶ 0210: In step 635, the RAN node 170 transmits and the Scell prediction module 420 (as part of the RIC near-RT 210) receives Pcell, Scell measurements from UEs already assigned to Scells. In step 640, the Scell prediction module 420 (as part of the RIC near-RT 210) transmits and the model training module 410 (as part of RIC near-RT 210) receives Pcell, Scell measurements from UEs already assigned to Scells (see block 460 of FIG. 4); Fig. 5, block 455: Receive UE channel feedback/measurements on Pcell (470-2))
Regarding claim 29, BEDEKAR discloses:
A method of wireless communication by an apparatus (RAN node 170), comprising:
obtaining, from a network entity (NCE 190), an indication of cross-node machine learning information used for a cross-node machine learning session between the network entity and a user equipment (UE), (UE 110) (¶¶ 0187-0189: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE, the UE capabilities, and the like; and Provide information 446 on the selected Scell (e.g., indication of the best Scell or top-N Scells) to the RAN node. The RAN node would then provide RRC reconfiguration information to the UE to configure information on the selected Scell(s). See block 450; ¶0180: [M]odel 430 takes as input a UE's measurements on a given Pcell (cell1) and outputs a prediction of the UE's CQI on a given Scell (cell2). With this approach, for each (cell1, cell2) pair, we would have a different model) wherein the network entity comprises a radio access network intelligent controller (RIC), and (¶ 0117: NCE 190 includes a RIC module 140, comprising one of or both parts 140-1 and/or 140-2; ¶ 0122: RIC near-RT 210 and the RIC non-RT 220 could be implemented by a single NCE 190 or by multiple NCEs 190) wherein the apparatus comprises an E2 node; (¶ 0135: There is an E2 reference point 230 (in ORAN) between the RIC near-RT 210 and the RAN node 170; ¶ 0152: Scell prediction module 420 also supports an interface towards a RAN node 170 for (i) receiving data from the RAN node 170; and (ii) providing a prediction 435 of the achievable SINR or SE achievable by a given UE. The interface is mappable to E2 interface in ORAN)
providing, to the UE, a configuration for the cross-node machine learning session based at least in part on the cross-node machine learning information; (¶ 0166: RAN node 170, in response to the selection of the best Scell, sends RRC reconfiguration (reconfig) information to provide Scell information to the UE 110 for the selected Scell. See block 450. It is noted that if the RAN node sends Scell reconfig information (see block 450) for multiple Scells, the UE should try to connect to all of them)
obtaining, via the cross-node machine learning session, machine learning information associated with the UE; (¶ 0210: In step 635, the RAN node 170 transmits and the Scell prediction module 420 (as part of the RIC near-RT 210) receives Pcell, Scell measurements from UEs already assigned to Scells. In step 640, the Scell prediction module 420 (as part of the RIC near-RT 210) transmits and the model training module 410 (as part of RIC near-RT 210) receives Pcell, Scell measurements from UEs already assigned to Scells (see block 460 of FIG. 4); Fig. 5, block 455: Receive UE channel feedback/measurements on Pcell (470-2))
providing, to the network entity via the cross-node machine learning session, the machine learning information; (¶ 0213: (and the RAN node 170 transmits [to the RIC) UE Pcell measurements in step 650)
obtaining, from the network entity, output data generated from the machine learning information; and (¶ 0213: Scell prediction module 420 provides, in step 660, a new Scell channel quality prediction for the UE to the RAN node; ¶ 0188: [I]nformation 446 on the selected Scell (e.g., indication of the best Scell or top-N Scells) to the RAN node)
communicating with the UE based at least in part on the output data. (¶ 0189: The RAN node would then provide RRC reconfiguration information to the UE to configure information on the selected Scell(s). See block 450)
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 the 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.
Claims 3, 4, 6, 18, 20, and 30 are rejected under 35 U.S.C. § 103 as being unpatentable over BEDEKAR, as applied above, in view of O-RAN Working Group 3; Near-RT RIC Architecture, Technical Specification R003-v04.00 (hereinafter, “O-RAN WG3”) (copy appended to Applicant’s IDS of 5 Mar. 2025).
Regarding claim 3, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR does not explicitly disclose:
wherein the one or more processors are configured to cause the apparatus to:
obtain a registration request associated with an application, the registration request comprising an indication of one or more parameters supported by the application in association with the cross-node machine learning session; and
in response to the registration request, provide a registration response indicating the application is registered.
In the same field of endeavor, however, O-RAN WG3 teaches:
obtain a registration request associated with an application, the registration request comprising an indication of one or more parameters supported by the application in association with the cross-node machine learning session; and (¶ 9.4.1: Step 1 (M): xAPP sends xAPP registration request to the Management Function Component in the Near-RT-RIC platform. passing relevant information needed to manage the xAPP)
in response to the registration request, provide a registration response indicating the application is registered. (¶ 9.4.1: Step 3 (M): The Management Function send the registration response to the xAPP)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide application-specific registration as taught by O-RAN WG3 to provide registration with a management function component in the Near-RT-RIC platform. See O-RAN WG3, at ¶ 0010.
Regarding claim 4, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR further discloses:
wherein to provide the indication of the cross-node machine learning information, the one or more processors are configured to cause the apparatus to provide the indication of the cross-node machine learning information via a RIC . . . . (¶ 0117: NCE 190 includes a RIC module 140, comprising one of or both parts 140-1 and/or 140-2; ¶ 0122: RIC near-RT 210 and the RIC non-RT 220 could be implemented by a single NCE 190 or by multiple NCEs 190)
BEDEKAR does not explicitly disclose:
a RIC subscription request.
In the same field of endeavor, however, O-RAN WG3 teaches:
a RIC subscription request. (¶ 9.3.2.1: Step 2 (M): xAPP sends E2 related API: E2 Subscription request with message contents . . . for a specific E2 Node)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide an E2 subscription request as taught by O-RAN WG3 to provide registration with a management function component in the Near-RT-RIC platform. See O-RAN WG3, at ¶ 0010.
Regarding claim 6, BEDEKER, as applied above, anticipates the apparatus of claim 5. BEDEKAR does not explicitly disclose:
wherein to provide the indication of the configuration for the UE, the one or more processors are configured to cause the apparatus to provide the indication of the configuration via a RIC control request.
In the same field of endeavor, however, O-RAN WG3 teaches:
wherein to provide the indication of the configuration for the UE, the one or more processors are configured to cause the apparatus to provide the indication of the configuration via a RIC control request. (¶ 9.3.2.4: Step a2 (M): xAPP sends E2 related API: E2 Control request with message contents . . . for a E2 Node, to E2 Termination)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide a RIC control request as taught by O-RAN WG3 to provide registration with a management function component in the Near-RT-RIC platform. See O-RAN WG3, at ¶ 0010.
Regarding claim 18, BEDEKAR, as applied above, anticipates the apparatus of claim 16. BEDEKAR further discloses:
wherein to obtain the indication of the cross-node machine learning information, the one or more processors are configured to cause the apparatus to obtain the indication of the cross-node machine learning information via a RIC . . . . (¶ 0106: [N]etwork entity 802 may be a DU (such as the DU 708 of FIG. 8), CU-UP, (such as the CU-UP 714 of FIG. 7) or a radio access network (RAN) intelligent controller (RIC). The CU-XP 716 may send a machine learning model setup request message to the network entity 802, requesting that the network entity 802 set up the second machine learning model for performing at least a portion of the machine learning-based wireless communications management procedure)
BEDEKAR does not explicitly disclose:
a RIC subscription request.
In the same field of endeavor, however, O-RAN WG3 teaches:
a RIC subscription request. (¶ 9.3.2.1: Step 2 (M): xAPP sends E2 related API: E2 Subscription request with message contents . . . for a specific E2 Node)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide an E2 subscription request as taught by O-RAN WG3 to provide registration with a management function component in the Near-RT-RIC platform. See O-RAN WG3, at ¶ 0010.
Regarding claim 20, BEDEKAR, as applied above, anticipates the apparatus of claim 19. BEDEKAR does not explicitly disclose:
wherein to obtain the indication of the configuration for the UE, the one or more processors are configured to cause the apparatus to obtain the indication of the configuration via a RIC control request.
In the same field of endeavor, however, O-RAN WG3 teaches:
wherein to obtain the indication of the configuration for the UE, the one or more processors are configured to cause the apparatus to obtain the indication of the configuration via a RIC control request. (¶ 9.3.2.4: Step a2 (M): xAPP sends E2 related API: E2 Control request with message contents . . . for a E2 Node, to E2 Termination)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide a RIC control request as taught by O-RAN WG3 to provide registration with a management function component in the Near-RT-RIC platform. See O-RAN WG3, at ¶ 0010.
Regarding claim 30, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR further discloses:
to provide the indication of the cross-node machine learning information, the one or more processors are configured to cause the apparatus to provide the indication of the cross-node machine learning information via a RIC . . . , (¶ 0117: NCE 190 includes a RIC module 140, comprising one of or both parts 140-1 and/or 140-2; ¶ 0122: RIC near-RT 210 and the RIC non-RT 220 could be implemented by a single NCE 190 or by multiple NCEs 190)
the cross-node machine learning information comprises one or more parameters supported by the apparatus in association with the cross-node machine learning session, and (¶ 0152: An Scell prediction module 420 (which can be hosted at the RIC near-RT 210) may be used to predict the channel quality (e.g., spectral efficiency (SE) or SINR or CQI) achievable by a UE 110 on a given candidate Scell 320. The Scell prediction module 420 also supports an interface towards a RAN node 170 for (i) receiving data from the RAN node 170; and (ii) providing a prediction 435 of the achievable SINR or SE achievable by a given UE. The interface is mappable to E2 interface in ORAN; ¶ 0168: The Scell prediction module 420 supports an interface towards RIC non-RT 220 to facilitate Scell channel prediction model training by the model training module 410. The interface is mappable to Al interface in ORAN/xRAN; ¶ 0187: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE)
the one or more parameters comprise one or more of:
one or more machine learning functions,
one or more machine learning features,
one or more machine learning models, or
one or more machine learning model structures. (¶ 0179: [I]nformation (info.) 441 is information that defines the AI/ML model(s) 430 or corresponding machine-learning algorithm 431. For instance, for a NN or DNN, the information 441 can define and indicate weights and structure (e.g., number of layers and nodes, inputs, outputs) of the corresponding NN/DNN; ¶ 0213: [M]odel 430 may be defined by layer information and weights, for a neural network for instance)
BEDEKAR does not explicitly disclose:
a RIC subscription request
In the same field of endeavor, however, O-RAN WG3 teaches:
a RIC subscription request. (¶ 9.3.2.1: Step 2 (M): xAPP sends E2 related API: E2 Subscription request with message contents . . . for a specific E2 Node)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide an E2 subscription request as taught by O-RAN WG3 to provide registration with a management function component in the Near-RT-RIC platform. See O-RAN WG3, at ¶ 0010.
Claims 8, 21, and 31 are rejected under 35 U.S.C. § 103 as being unpatentable over BEDEKAR, as applied above, in view of US 2022/0012645 (hereinafter, “YING”).
Regarding claim 8, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR does not explicitly disclose:
wherein:
the one or more processors are configured to cause the apparatus to obtain a RIC query message requesting to initiate the cross-node machine learning session between the UE and the apparatus,
wherein to provide the indication of the cross-node machine learning information, the one or more processors are configured to cause the apparatus to provide the indication of the cross-node machine learning information via a RIC query response in response to the RIC query message.
In the same field of endeavor, however, YING teaches:
the one or more processors are configured to cause the apparatus to obtain a radio access network (RAN) intelligent controller (RIC) query message requesting to initiate the cross-node machine learning session between the UE and the apparatus, (¶¶ 0065-0066: The method 800 begins at operation 802 with the A1-ML consumer 306 of the non-RT RIC 212 sending a “get . . . /mlCaps” query with data 806. The data 806 is the query for ML capabilities (Caps). [0066] The ML capabilities query queries the A1-ML producer 312 of the Near-RT RIC 214 for the capabilities of the A1-ML services of the Near-RT RIC 214. The Non-RT RIC 212 can query for all supported ML capabilities in the Near-RT RICs. or it can query a specific ML capability (e.g., support of FL). The A1-ML consumer 306 uses HTTP GET request, in some embodiments, to solicit a get response from A1-ML producer 312)
wherein to provide the indication of the cross-node machine learning information, the one or more processors are configured to cause the apparatus to provide the indication of the cross-node machine learning information via a RIC query response in response to the RIC query message. (¶¶ 0065-0066: The method 800 begins at operation 802 with the A1-ML consumer 306 of the non-RT RIC 212 sending a “get . . . /mlCaps” query with data 806. The data 806 is the query for ML capabilities (Caps). [0066] The ML capabilities query queries the A1-ML producer 312 of the Near-RT RIC 214 for the capabilities of the A1-ML services of the Near-RT RIC 214. The Non-RT RIC 212 can query for all supported ML capabilities in the Near-RT RICs. or it can query a specific ML capability (e.g., support of FL). The A1-ML consumer 306 uses HTTP GET request, in some embodiments, to solicit a get response from A1-ML producer 312)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to identify supported ML capabilities in the Near-RT RICs as taught by YING such that A1-ML consumer 306 uses HTTP GET request to solicit a get response from A1-ML producer 312. See YING, at ¶ 0066.
Regarding claim 21, BEDEKAR, as applied above, anticipates the apparatus of claim 16. BEDEKAR does not explicitly disclose:
wherein:
the one or more processors are configured to cause the apparatus to provide, to the network entity, a RIC query message requesting to initiate the cross-node machine learning session between the UE and the network entity,
wherein to obtain the indication of the cross-node machine learning information, the one or more processors are configured to cause the apparatus to obtain the indication of the cross-node machine learning information via a RIC query response in response to the RIC query message.
In the same field of endeavor, however, YING teaches:
the one or more processors are configured to cause the apparatus to provide, to the network entity, a radio access network (RAN) intelligent controller (RIC) query message requesting to initiate the cross-node machine learning session between the UE and the network entity, (¶¶ 0065-0066: The method 800 begins at operation 802 with the A1-ML consumer 306 of the non-RT RIC 212 sending a “get . . . /mlCaps” query with data 806. The data 806 is the query for ML capabilities (Caps). [0066] The ML capabilities query queries the A1-ML producer 312 of the Near-RT RIC 214 for the capabilities of the A1-ML services of the Near-RT RIC 214. The Non-RT RIC 212 can query for all supported ML capabilities in the Near-RT RICs. or it can query a specific ML capability (e.g., support of FL). The A1-ML consumer 306 uses HTTP GET request, in some embodiments, to solicit a get response from A1-ML producer 312)
wherein to obtain the indication of the cross-node machine learning information, the one or more processors are configured to cause the apparatus to obtain the indication of the cross-node machine learning information via a RIC query response in response to the RIC query message. (¶¶ 0065-0066: The method 800 begins at operation 802 with the A1-ML consumer 306 of the non-RT RIC 212 sending a “get . . . /mlCaps” query with data 806. The data 806 is the query for ML capabilities (Caps). [0066] The ML capabilities query queries the A1-ML producer 312 of the Near-RT RIC 214 for the capabilities of the A1-ML services of the Near-RT RIC 214. The Non-RT RIC 212 can query for all supported ML capabilities in the Near-RT RICs. or it can query a specific ML capability (e.g., support of FL). The A1-ML consumer 306 uses HTTP GET request, in some embodiments, to solicit a get response from A1-ML producer 312)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to identify supported ML capabilities in the Near-RT RICs as taught by YING such that an A1-ML consumer uses HTTP GET request to solicit a get response from an A1-ML producer. See YING, at ¶ 0066.
Regarding claim 31, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR further discloses:
wherein:
the cross-node machine learning information comprises one or more parameters supported by the apparatus in association with the cross-node machine learning session, and (¶ 0152: An Scell prediction module 420 (which can be hosted at the RIC near-RT 210) may be used to predict the channel quality (e.g., spectral efficiency (SE) or SINR or CQI) achievable by a UE 110 on a given candidate Scell 320. The Scell prediction module 420 also supports an interface towards a RAN node 170 for (i) receiving data from the RAN node 170; and (ii) providing a prediction 435 of the achievable SINR or SE achievable by a given UE. The interface is mappable to E2 interface in ORAN; ¶ 0168: The Scell prediction module 420 supports an interface towards RIC non-RT 220 to facilitate Scell channel prediction model training by the model training module 410. The interface is mappable to Al interface in ORAN/xRAN; ¶ 0187: Select (see block 445-1) the best Scell (or top-N Scells) for the UE taking into account both the load on Scells as well as the UE's achievable channel quality on the Scells, and other factors may be taken into account such as the band or carrier combinations supported by the UE)
the one or more parameters comprise one or more of:
one or more machine learning functions,
one or more machine learning features,
one or more machine learning models, or
one or more machine learning model structures. (¶ 0179: [I]nformation (info.) 441 is information that defines the AI/ML model(s) 430 or corresponding machine-learning algorithm 431. For instance, for a NN or DNN, the information 441 can define and indicate weights and structure (e.g., number of layers and nodes, inputs, outputs) of the corresponding NN/DNN; ¶ 0213: [M]odel 430 may be defined by layer information and weights, for a neural network for instance)
BEDEKAR does not explicitly disclose:
the one or more processors are configured to cause the apparatus to obtain a RIC query message requesting to initiate the cross-node machine learning session between the UE and the apparatus,
to provide the indication of the cross-node machine learning information, the one or more processors are configured to cause the apparatus to provide the indication of the cross-node machine learning information via a RIC query response in response to the RIC query message,
In the same field of endeavor, however, YING teaches:
the one or more processors are configured to cause the apparatus to obtain a RIC query message requesting to initiate the cross-node machine learning session between the UE and the apparatus, (¶¶ 0065-0066: The method 800 begins at operation 802 with the A1-ML consumer 306 of the non-RT RIC 212 sending a “get . . . /mlCaps” query with data 806. The data 806 is the query for ML capabilities (Caps). [0066] The ML capabilities query queries the A1-ML producer 312 of the Near-RT RIC 214 for the capabilities of the A1-ML services of the Near-RT RIC 214. The Non-RT RIC 212 can query for all supported ML capabilities in the Near-RT RICs. or it can query a specific ML capability (e.g., support of FL). The A1-ML consumer 306 uses HTTP GET request, in some embodiments, to solicit a get response from A1-ML producer 312)
to provide the indication of the cross-node machine learning information, the one or more processors are configured to cause the apparatus to provide the indication of the cross-node machine learning information via a RIC query response in response to the RIC query message, (¶¶ 0065-0066: The method 800 begins at operation 802 with the A1-ML consumer 306 of the non-RT RIC 212 sending a “get . . . /mlCaps” query with data 806. The data 806 is the query for ML capabilities (Caps). [0066] The ML capabilities query queries the A1-ML producer 312 of the Near-RT RIC 214 for the capabilities of the A1-ML services of the Near-RT RIC 214. The Non-RT RIC 212 can query for all supported ML capabilities in the Near-RT RICs. or it can query a specific ML capability (e.g., support of FL). The A1-ML consumer 306 uses HTTP GET request, in some embodiments, to solicit a get response from A1-ML producer 312)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to identify supported ML capabilities in the Near-RT RICs as taught by YING such that an A1-ML consumer uses HTTP GET request to solicit a get response from an A1-ML producer . See YING, at ¶ 0066.
Claims 10 and 23 are rejected under 35 U.S.C. § 103 as being unpatentable over BEDEKAR, as applied above, in view of US 2025/0287249 (hereinafter, “FILIN”).
Regarding claim 10, BEDEKAR, as applied above, anticipates the apparatus of claim 9. BEDEKAR does not explicitly disclose:
wherein the indication of the cross-node machine learning session between the UE and the apparatus comprises a UE identifier associated with the UE and one or more machine learning models used at the UE for the cross-node machine learning session.
In the same field of endeavor, however, FILIN teaches:
wherein the indication of the cross-node machine learning session between the UE and the apparatus comprises a UE identifier associated with the UE and one or more machine learning models used at the UE for the cross-node machine learning session. (¶¶ 0315-0316: The identifier of the UE in the BS 2101 may comprise an AI/ML model UE identifier. [0316] The AI/ML model UE identifier and AI/ML model BS identifier may be identifiers that may be configured, assigned, and/or allocated to any element in an AI/ML system that sends and/or receives training data, feedback, and/or other AI/ML modeling related information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide a UE identifier as taught by FILIN to provide an AI/ML model UE identifier so that such identifiers may be configured, assigned, and/or allocated to any element in an AI/ML system that sends and/or receives training data, feedback, and/or other AI/ML modeling related information. See FILIN, at ¶ 0316.
Regarding claim 23, BEDEKAR, as applied above, anticipates the apparatus of claim 22. BEDEKAR does not explicitly disclose:
wherein the indication of the cross-node machine learning session between the UE and the network entity comprises a UE identifier associated with the UE and one or more machine learning functions or models used at the UE for the cross-node machine learning session.
In the same field of endeavor, however, FILIN teaches:
wherein the indication of the cross-node machine learning session between the UE and the network entity comprises a UE identifier associated with the UE and one or more machine learning functions or models used at the UE for the cross-node machine learning session. (¶¶ 0315-0316: The identifier of the UE in the BS 2101 may comprise an AI/ML model UE identifier. [0316] The AI/ML model UE identifier and AI/ML model BS identifier may be identifiers that may be configured, assigned, and/or allocated to any element in an AI/ML system that sends and/or receives training data, feedback, and/or other AI/ML modeling related information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide a UE identifier as taught by FILIN to provide an AI/ML model UE identifier so that such identifiers may be configured, assigned, and/or allocated to any element in an AI/ML system that sends and/or receives training data, feedback, and/or other AI/ML modeling related information. See FILIN, at ¶ 0316.
Claims 11 and 24 are rejected under 35 U.S.C. § 103 as being unpatentable over BEDEKAR, as applied above, in view of US 2024/0129759 (hereinafter, “REN”).
Regarding claim 11, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR does not explicitly disclose:
wherein the one or more processors are configured to cause the apparatus to:
provide, to the network entity, an indication to report status information associated with the UE; obtain, from the network entity, the status information associated with the UE; and in response to obtaining the status information, provide, to the network entity, an indication of a configuration associated with the cross-node machine learning session for the UE.
In the same field of endeavor, however, REN teaches:
provide, to the network entity, an indication to report status information associated with the UE; obtain, from the network entity, the status information associated with the UE; and in response to obtaining the status information, provide, to the network entity, an indication of a configuration associated with the cross-node machine learning session for the UE. (¶ 0021: [T]ransmitting, to a UE, ML model information defining an ML model for the UE, transmitting, to the UE, a configuration for the UE to report a status of the ML model, and receiving, from the UE, a report message indicating the status of the ML model based on the configuration)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s mutli-node ML learning procedure to provide status information reporting as taught by REN to provide a report message indicating the status of the ML model based on the configuration, so as to effectively determine if an ML model is performing relatively poorly (e.g., below a performance threshold), report status information related to the ML model, and determine whether to fallback from operating using the ML model to operating in a different (e.g., default) mode. See REN, at ¶ 0005.
Regarding claim 24, BEDEKAR, as applied above, anticipates the apparatus of claim 16. BEDEKAR does not explicitly disclose:
wherein the one or more processors are configured to cause the apparatus to:
obtain, from the network entity, an indication to report status information associated with the UE; provide, to the network entity, the status information associated with the UE; and in response to providing the status information, obtain, from the network entity, an indication of the configuration associated with the cross-node machine learning session for the UE.
In the same field of endeavor, however, REN teaches:
obtain, from the network entity, an indication to report status information associated with the UE; provide, to the network entity, the status information associated with the UE; and in response to providing the status information, obtain, from the network entity, an indication of the configuration associated with the cross-node machine learning session for the UE. (¶ 0021: [T]ransmitting, to a UE, ML model information defining an ML model for the UE, transmitting, to the UE, a configuration for the UE to report a status of the ML model, and receiving, from the UE, a report message indicating the status of the ML model based on the configuration)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide status information reporting as taught by REN to provide a report message indicating the status of the ML model based on the configuration, so as to effectively determine if an ML model is performing relatively poorly (e.g., below a performance threshold), report status information related to the ML model, and determine whether to fallback from operating using the ML model to operating in a different (e.g., default) mode. See REN, at ¶ 0005.
Claims 14, 15, 26, and 27 are rejected under 35 U.S.C. § 103 as being unpatentable over BEDEKAR in view of US 2023/0100253 (hereinafter, “ZHU”).
Regarding claim 14, BEDEKAR, as applied above, anticipates the apparatus of claim 1. BEDEKAR does not explicitly disclose:
wherein the one or more processors are configured to cause the apparatus to:
perform a cross-node machine learning inference that is based at least in part on the machine learning information to generate output data; and
provide the output data to the network entity.
In the same field of endeavor, however, ZHU teaches:
perform a cross-node machine learning inference that is based at least in part on the machine learning information to generate output data; and (¶ 0037: RAN side model activation may be achieved by the base station informing the inference and/or training nodes to start running the model, once the model and parameter set are ready; ¶ 0117: Radio access network (RAN) side model activation may be achieved by the base station 110 informing the inference and/or training nodes of the network entity 802 to start running the model, once the model and parameter set are ready. More specifically, at time 1, the CU-CP 712 transmits a model activation message to the CU-XP 716. In response, at time 2, the CU-XP 716 transmits a model activation message to the network entity 802 that performs training and/or inference; ¶ 0113: [A] centralized unit control plane (CU-CP) and/or centralized unit machine learning plane (CU-XP) may decide to configure a network model for inference and/or training)
provide the output data to the network entity. (¶ 0110: UE 120 and/or network entity 802 may perform the machine learning-based wireless communications management procedure using the at least one machine learning model based on the activation signal[, which] may include inputting one or more input variables to the at least one machine learning model and obtaining an output from the at least one machine learning model based on the one or more input variables)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide an ML inference as taught by ZHU to provide output data such that a neural network model for training or inference is stored for use at UE 120 or network entities, such as a centralized unit (CU) 706, a distributed unit (DU) 708, or radio access network (RAN) intelligent controller (RIC). See ZHU at ¶ 0093.
Regarding claim 15, the combination of BEDEKAR and ZHU, as applied above, renders obvious the apparatus of claim 14. BEDEKAR does not explicitly disclose:
wherein:
the machine learning information comprises encoded channel state information generated at the UE; and
the output data comprises decoded channel state information associated with a communication link between the UE and the network entity.
In the same field of endeavor, however, ZHU teaches:
the machine learning information comprises encoded channel state information generated at the UE; and (¶ 0054: At the base station 110, a transmit processor 220 may receive data from a data source 212 for one or more UEs, select one or more modulation and coding schemes (MCS) for each UE based at least in part on channel quality indicators (CQIs) received from the UE, process (e.g., encode and modulate) the data for each UE based at least in part on the MCS(s) selected for the UE, and provide data symbols for all UEs; ¶ 0090: [M]achine learning-based wireless communications management procedures may include cell reselection procedures, idle or inactive mode measurement procedures, radio resource management (RRM) measurement procedures, channel state feedback, compression)
the output data comprises decoded channel state information associated with a communication link between the UE and the network entity. (¶ 0035: A UE model may be configured together with the network model, for example, to compress and decompress channel state feedback; ¶ 0087: [C]ompression and decompression of channel state feedback may be implemented with neural network models running on both the UE and the network entity, which may be, for example a base station; ¶ 0113: A UE model may be configured together with the network model, for example, to compress and decompress channel state feedback (CSF) transmitted across the wireless interface; ¶ 0096: [A] capability to perform a (machine learning-based) channel state information (CSI) measurement procedure)
Regarding claim 26, BEDEKAR, as applied above, anticipates the apparatus of claim 16. BEDEKAR does not explicitly disclose:
wherein the output data comprises decoded channel state information associated with a communication link between the UE and the apparatus.
In the same field of endeavor, however, ZHU teaches:
wherein the output data comprises decoded channel state information associated with a communication link between the UE and the apparatus. (¶ 0087: [C]ompression and decompression of channel state feedback may be implemented with neural network models running on both the UE and the network entity, which may be, for example a base station. The neural network models may also be referred to as machine learning models; ¶ 0096: [T]he radio capability of the UE 120 may indicate . . . a capability to perform a (machine learning-based) channel state information (CSI) measurement procedure)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BEDEKAR’s multi-node ML training procedure to provide an ML inference as taught by ZHU to provide output data such that a neural network model for training or inference is stored for use at UE 120 or network entities, such as a centralized unit (CU) 706, a distributed unit (DU) 708, or radio access network (RAN) intelligent controller (RIC). See ZHU at ¶ 0093.
Regarding claim 27, the combination of BEDEKAR and ZHU, as applied above, renders obvious the apparatus of claim 26. BEDEKAR does not explicitly disclose:
wherein the one or more processors are configured to cause the apparatus to control the communication link between the UE and the apparatus based at least in part on the decoded channel state information.
In the same field of endeavor, however, ZHU teaches:
wherein the one or more processors are configured to cause the apparatus to control the communication link between the UE and the apparatus based at least in part on the decoded channel state information.
(¶ 0113: A UE model may be configured together with the network model, for example, to compress and decompress channel state feedback (CSF) transmitted across the wireless interface)
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.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Garth D Richmond whose telephone number is (703)756-4559. The Examiner can normally be reached M-F 8 a.m. - 5 p.m. ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, Applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Kathy Wang-Hurst can be reached at 571-270-5371. 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.
/GARTH D RICHMOND/Examiner, Art Unit 2644
/KATHY W WANG-HURST/Supervisory Patent Examiner, Art Unit 2644
Prosecution Insights