DETAILED ACTION
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 39, 40, and 44-54 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The intended scope of the phrase “fifth generation i membership” in line 7 of claim 44 is unclear.
The intended scope of the phrase “at least one request to start guidance for application aware radio access network guidance” in lines 4-5 of claim 49 is unclear.
There is insufficient antecedent basis for the following limitations:
“the near-real-time radio access node intelligent controller” in lines 2-3 of claim 39.
“the near-real-time radio access node intelligent controller” in lines 2-3 of claim 40.
“the at least one set of layer 2 group policies” in line 3 of claim 40.
“the near-real-time radio access node intelligent controller” in lines 2-3 of claim 45.
“the near-real-time radio access node intelligent controller” in lines 2-3 of claim 46.
“the near-real-time radio access node intelligent controller” in lines 2-3 of claim 47.
“the near-real-time radio access node intelligent controller” in lines 1-2 of claim 48.
“the near-real-time radio access node intelligent controller” in lines 3-4 of claim 49.
“the at least one application aware radio access network guidance xApp” in lines 2-3 of claim 49.
“the at least one requesting xApp” in line 5 of claim 49.
“the request to start guidance for application aware radio access network guidance” in lines 1-2 of claim 50.
“the near-real-time radio access node intelligent controller” in lines 3-4 of claim 51.
“the application aware radio access network detection xApp” in lines 2-3 of claim 52.
“the near-real-time radio access node intelligent controller” in lines 3-4 of claim 52.
“the application aware radio access network guidance xApp” in lines 2-3 of claim 53.
“the near-real-time radio access node intelligent controller” in lines 3-4 of claim 53.
“the key performance measurement data collector” in lines 2-3 of claim 54.
“the near-real-time radio access node intelligent controller” in lines 3-4 of claim 54.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 33, 37, 39-41, 43, 44, and 46-54 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Bai et al (US 2024/0305533).
Regarding claim 1: Bai discloses a method, comprising:
obtaining, with a near-real-time radio access node intelligent controller, at least one tier 1 policy (disclosed throughout; see [0138], for example, which discloses that the non-real time RIC 912 may provide policy-driven guidance to the near-real time RIC 914 over the A1 interface; this is interpreted as tier 1 policy information; see also [0159] and [0163], for example);
obtaining, with the near-real-time radio access node intelligent controller, layer 2 metadata from at least one E2 node (disclosed throughout; for example, see the RAN performance metrics 250 in Figure 3 and described in [0040], for example; the INSM may run on the near-RT RIC 914 and the RAN performance metrics are the layer 2 meta data and are received from an E2 node (such as a DU) via an E2 interface (see [0021] and [0037], for example); see also [0144], for example);
obtaining, with the near-real-time radio access node intelligent controller, application types run with user equipment served with the at least one E2 node (disclosed throughout; see the service requirements for network slices indicated via SLAs or other enrichment information 253 in [0037]; as indicated in [0019], the slices may be associated with application types (such as eMBB, URLLC, IIoT, etc.); see also [0061] and [0063], for example, which disclose that the provisioning and resource allocation is based at least in part on the type of the network slice);
computing, with the near-real-time radio access node intelligent controller, at least one optimized per user equipment guidance policy based on the at least one tier 1 policy, the layer 2 metadata, and the applications types (disclosed throughout; see [0041], for example, which discloses that the INSM (an xApp on the near-RT RIC) “determines how the RAN configuration should be updated”; this is based on the layer 2 metadata (the RAN/performance measurements), and the application types (the SLA information regarding the different application types implemented by each slice) as disclosed throughout (see [0037] and [0063], for example); the guidance policy is also determined based on the tier 1 policy receive via the A1 interface discussed above as the near-RT RIC runs the xApps using this policy information; as indicated in [0049]-[0050], for example, the policy/RAN configuration includes per-UE guidance via the dedicated resources); and
transmitting, with the near-real-time radio access node intelligent controller, the at least one computed optimized per user equipment guidance policy to the at least one E2 node (disclosed throughout; see [0155] and [0172], for example, which disclose that the near-RT RIC transmits policy and control messages to the E2 nodes in the RAN via the E2 interface; see also [0041], for example).
Regarding claim 33: Bai discloses an apparatus, comprising:
at least one processor (see processor 1552 of Figure 15, for example); and
at least one non-transitory memory storing instructions that, when executed with the at least one processor, cause the apparatus at least to (see memory 1560 and 1554/1558 as well as the associated instructions 1582 and 1583 of Figure 15, for example):
obtain at least one tier 1 policy (disclosed throughout; see [0138], for example, which discloses that the non-real time RIC 912 may provide policy-driven guidance to the near-real time RIC 914 over the A1 interface; this is interpreted as tier 1 policy information; see also [0159] and [0163], for example);
obtain layer 2 metadata from at least one E2 node (disclosed throughout; for example, see the RAN performance metrics 250 in Figure 3 and described in [0040], for example; the INSM may run on the near-RT RIC 914 and the RAN performance metrics are the layer 2 meta data and are received from an E2 node (such as a DU) via an E2 interface (see [0021] and [0037], for example); see also [0144], for example);
obtain application types run with user equipment served with the at least one E2 node (disclosed throughout; see the service requirements for network slices indicated via SLAs or other enrichment information 253 in [0037]; as indicated in [0019], the slices may be associated with application types (such as eMBB, URLLC, IIoT, etc.); see also [0061] and [0063], for example, which disclose that the provisioning and resource allocation is based at least in part on the type of the network slice);
compute at least one optimized per user equipment guidance policy based on the at least one tier 1 policy, the layer 2 metadata, and the applications types (disclosed throughout; see [0041], for example, which discloses that the INSM (an xApp on the near-RT RIC) “determines how the RAN configuration should be updated”; this is based on the layer 2 metadata (the RAN/performance measurements), and the application types (the SLA information regarding the different application types implemented by each slice) as disclosed throughout (see [0037] and [0063], for example); the guidance policy is also determined based on the tier 1 policy receive via the A1 interface discussed above as the near-RT RIC runs the xApps using this policy information; as indicated in [0049]-[0050], for example, the policy/RAN configuration includes per-UE guidance via the dedicated resources); and
transmit the at least one computed optimized per user equipment guidance policy to the at least one E2 node (disclosed throughout; see [0155] and [0172], for example, which disclose that the near-RT RIC transmits policy and control messages to the E2 nodes in the RAN via the E2 interface; see also [0041], for example).
Regarding claim 37: Bai discloses the limitations that the per user equipment guidance policy comprises at least one of a custom policy computed for an individual user equipment or at least one mapping of user equipment to at least one of the predefined group policies (disclosed throughout; see [0050], for example, which discloses that dedicated resources may be allocated to an individual user according to the policy).
Regarding claim 39: Bai discloses the limitations of calculate, with the near-real-time radio access node intelligent controller, at least one assignment of individual user equipment to one or more of the predefined group policies (disclosed throughout; the INSM is an intelligent network slice manager deployed on a near-RT RIC as indicated in [0019] and [0050], for example; further, the resources are allocated to the different UEs according to the requirements predetermined in an SLA as indicated in [0019]; the management of the resources via the groups of devices (corresponding to a slice) that utilize a particular predefined group policy is thus implemented in the near-RT RIC calculating which slice (and associated group policies) can be allocated to each of the UEs).
Regarding claim 40: Bai discloses the limitations of transmit, with the near-real-time radio access node intelligent controller, the at least one set of layer 2 group policies to the E2 node (disclosed throughout; see the network slicing configuration of Figure 7, for example, which are transmitted to the E2 node).
Regarding claim 41: Bai discloses the limitations that the at least one tier 1 policy comprises at least one set of generic policy parameters configured to compute individual per user equipment policies (disclosed throughout; see [0138], [0159], and [0163], for example, which disclose that the near-RT RIC receives generic policy information such as the declarative policies that are used to run the xApps and thus compute the individual per user policies).
Regarding claim 43: Bai discloses the limitations that the at least one tier 1 policy comprises at least one group policy (disclosed throughout; see [0159], for example, which discloses that the A1 policies ay handle dynamically defined groups of UEs).
Regarding claim 44: Bai discloses the limitations that the layer 2 metadata comprises at least one of: per cell/carrier scheduler data; per user equipment radio link control data; at least one list of cell carriers serving at least one given user equipment; multiple-input multiple-output rank of at least one given user equipment; fifth generation i membership; or network slice membership (disclosed throughout; as indicated in [0163], the information collected on the E2 interface may be per-cell data which is used to determine scheduling information).
Regarding claim 46: Bai discloses the limitations of compute, with the near-real-time radio access node intelligent controller, at least one per user equipment network guidance policy according to at least one optimization problem (disclosed throughout; see [0155], for example, which indicates that the near-RT RIC performs optimization when configuring the RAN elements).
Regarding claim 47: Bai discloses the limitations of assign, with the near-real-time radio access node intelligent controller, at least one individual user equipment to at least one group policy (disclosed throughout; see [0049]-[0050], for example, which discloses the use of the RRM policy member list for resource allocation; via this list, individual UEs are assigned to at least one group policy that corresponds to all UEs in the list).
Regarding claim 48: Bai discloses the limitations that the near-real-time radio access node intelligent controller comprises one or more of: at least one requesting xApp; at least one application aware radio access network guidance xApp; at least one application aware radio access network detection xApp; or at least one key performance measurement data collector (disclosed throughout; for example, [0165] discloses that the xApps generate request and thus the near-RT RIC includes a requesting xApp; further, as indicated in [0037], the INSM (which provides both RAN guidance and detection) can be implemented via on or more xApps; further, [0163] and [0181] discloses that the near-RT RIC includes an xApp for collecting key performance measurement information (near real-time information and the KPI monitor xApp)).
Regarding claim 49: Bai discloses the limitations of receive, at the at least one application aware radio access network guidance xApp of the near-real-time radio access node intelligent controller, at least one request to start guidance for application aware radio access network guidance from the at least one requesting xApp (disclosed throughout; see [0169]-[0170], for example, which discloses some of the ways xApps (including a requesting xApp) can send a request message to another xApp (such as the INSM providing RAN guidance); clearly, to access the functionality of the INSM providing guidance, another xApp sends a request to initiate or request the guidance be performed).
Regarding claim 50: Bai discloses the limitations that the request to start guidance for application aware radio access network guidance is associated with one or more of application type, targets, parameters, or policies (disclosed throughout; see [0172], for example, which discloses that these request messages can include at least parameters and/or policies).
Regarding claim 51: Bai discloses the limitations of receive, with the application aware radio access network detection xApp of the near-real-time radio access node intelligent controller, at least one request to start application type detection associated with at least one of application type, slice type, or bearer type (disclosed throughout; see [0169]-[0170], for example, which discloses some of the ways xApps (including a requesting xApp) can send a request message to another xApp (such as the INSM providing RAN detection); clearly, to access the functionality of the INSM providing RAN detection, another xApp sends a request to initiate or request the detection be performed).
Regarding claim 52: Bai discloses the limitations of initiate, with the application aware radio access network detection xApp of the near-real-time radio access node intelligent controller, key performance measurement reporting for detection (disclosed throughout; the INSM is implemented by one or more xApps (see [0019], [0037], for example) performing at least a detection function to initiate the collection of key network performance measurements (disclosed throughout; see [0037], [0040], for example)).
Regarding claim 53: Bai discloses the limitations of receive, with the application aware radio access network guidance xApp of the near-real-time radio access node intelligent controller, at least one indication that application type detection has started (disclosed throughout; the INSM is implemented by one or more xApps (see [0019], [0037], for example) performing at least a detection function associated with at least application types implemented by the slices; further, as indicated in [0040], the xApp may receive indication that this detection has started when it is implemented using event-triggering).
Regarding claim 54: Bai discloses the limitations of receive, with the key performance measurement data collector of the near-real-time radio access node intelligent controller, at least one request for key performance measurement data collection for target slice type, bearer type, and required pre-processing (disclosed throughout; see [0181], for example, which discloses that the RIC platform includes a KPI xApp which is available to the other xApps to request key performance measurement data collection; as indicated throughout (see [0040], for example), the performance metrics include slice and bearer (DRB) metrics and the xApp clearly performs the required pre-processing as the metrics are delivered to the INSM or other requesting xApp).
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.
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.
Claim 38 is rejected under 35 U.S.C. 103 as being unpatentable over Bai et al (US 2024/0305533) in view of Parekh et al (US 2021/0235277).
Regarding claim 38: Bai discloses the limitations of parent claim 33 as indicated above. Bai does not explicitly disclose the limitations of claim 38 of obtain the at least one tier 1 policy periodically or when the at least one tier 1 policy changes. However, Parekh discloses a tier 1 policy (the DSS policy) that is transmitted from the non-RT RIC to the near-RT RIC (see step 1 of Figure 5 or step 7002 of Figure 7, for example). Further, as indicated in step 19 of Figure 5 and step 7006 of Figure 7, the policy is obtained by the near-RT RIC when the at least one tier 1 (DSS) policy changes. Further, in [0076], for example, Parekh discloses that the “DSS policy may be dynamically updated based on periodic or real-time traffic requirements”. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Bai such that the near-RT RIC obtains the tier 1 policy from the non-RT RIC either when the tier 1 policy changes or periodically as suggested by Parekh. The rationale for doing so would have been to ensure that the near-RT RIC has up to date configuration information.
Claim 42 is rejected under 35 U.S.C. 103 as being unpatentable over Bai et al (US 2024/0305533).
Regarding claim 42: Bai discloses the limitations of parent claim 33 as indicated above. Bai does not explicitly disclose the limitations that the at least one tier 1 policy comprises at least one maximal aggregate amount of spectral resources configured to be used at a given cell for user equipment running at least one specific application type. However, Bai discloses throughout that the non-RT RIC sends A1 policy information to the near-RT RIC (see [0159], for example). Further, the near-RT RIC sends a configuration to the E2 nodes such as the DU that specifies the maximum amount of spectral resources (PRB) that can be allocated to users with a given application type (slice) as indicated in at least [0041], [0043], and [0046], for example. To the extent that Bai does not explicitly disclose that the non-RT RIC includes a higher level maximum resource limit for user equipment on a cell using a specific application type (slice), this would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention. In particular, it would have been obvious to provide the near-RT RIC a maximum PRB value per a slice on one of its cells to inform the limits on the max PRB ratio as imposed from a higher system level via the A1 policy information sent from the non-RT RIC. The rationale for doing so would have been to enable the non-RT RIC to control the maximum resources for a given application type throughout the system via the A1 policy.
Claim 45 is rejected under 35 U.S.C. 103 as being unpatentable over Bai et al (US 2024/0305533) in view of Fenoglio et al (US 2016/0283859).
Regarding claim 45: Bai discloses the limitations of parent claim 33 as indicated above. Bai does not explicitly disclose the limitations of claim 45 of identify, with the near-real-time radio access node intelligent controller, at least one application type that the user equipment served with the at least one E2 node is running using machine learning-based inference according to at least one pre-trained machine learning model based upon idle-burst signatures of end-to-end encrypted application traffic. However, Fenoglio discloses a system which utilizes at least one pre-trained machine learning model (see [0028]-[0030], [0049], and [0051], for example, which disclose the deep learning techniques; see the training data used in Figure 2) to classify an encrypted flow based on the traffic pattern (disclosed throughout; see [0011], which describes an example of the types of patterns used to classify encrypted traffic). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Bai to utilize a pre-trained machine learning model to classify the traffic types used in the Bai system as suggested by Fenoglio. The rationale for doing so would have been to enable encrypted traffic to be properly handled based on an inferred classification when the traffic type is not known as suggested by Fenoglio.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wang et al (US 2024/0422587) discloses a method for O-RAN based performance optimization and configuration.
Whinnett et al (US 2024/0162955) discloses a method for beamforming for MIMO modes in an O-RAN.
Pateromichelakis et al (US 2023/0328580) discloses a method for QoS profile adaptation in a wireless network.
Song et al (US 2023/0269622) discloses a method for controlling E2 nodes in a wireless communication system.
Song et al (US 2023/0239776) discloses a method for managing UEs in a wireless communication system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Robert C Scheibel whose telephone number is (571)272-3169. The examiner can normally be reached Monday-Friday 8:00 AM - 5:00 PM.
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, Hassan A Phillips can be reached at 571-272-3940. 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.
Robert C. Scheibel
Primary Examiner
Art Unit 2467
/Robert C Scheibel/Primary Examiner, Art Unit 2467 January 12, 2026