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 .
DETAILED ACTION
Claims 1 – 20 are pending in this application. Claims 1, 10 and 17 are independent.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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.
Claim(s) 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Curic, Maja (US-20240098568-A1, hereinafter simply referred to as Maja).
Regarding independent claim(s) 1, Maja teaches:
A method (e.g., flowchart (FIG. 2) of Maja), comprising: receiving, from a first extended application (xApp) (e.g., xApp (FIG. 1) of Maja) and by a device (e.g., user equipment (UE) device of Maja) comprising a processor (e.g., processor of Maja), a request to configure a control parameter (See at least Maja, ¶ [0013]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…"), wherein the control parameter is configured to control operation of a process of network equipment that is part of a radio access network (RAN) (See at least Maja, ¶ [0013]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…"); determining, by the device, whether adjustment of the control parameter is controlled by a second xApp (See at least Maja, ¶ [0056, 0061]; FIG. 2; "…a first type of xApps 132 can subscribe to rApps 130 and implement the policies that the rApps 130 issue over the interface A1. Second type of xApps 132 can execute independently from rApps 130 and govern the network behavior according to their own logic. xApps 132 execute in parallel of each other and conflicts can occur…", "…O-RAN Alliance specifies a conflict mitigation component which provides a E2 Guidance response that indicates whether the proposed changes from the xApp 132 conflict with changes from other xApps 132. If yes, conflict management can recommend modification for the proposed changes to the xApp 132 to attempt to avoid the conflict(s)…"); determining, by the device, whether the second xApp has granted permission for the first xApp to adjust the control parameter (See at least Maja, ¶ [0075]; FIG. 2; "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter)…"); and in response to the determining whether the second xApp has granted the permission indicating that the second xApp has granted the permission for the first xApp to adjust the control parameter, adjusting, by the device, the control parameter in accordance with the request received from the first xApp (See at least Maja, ¶ [0014, 0075]; FIG. 2; "…in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN…The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter…", "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter). Accordingly, the near-RT RIC 114 adjusts the xApps 132 based on one or more policies that are dynamically adjusted by the non-RT RIC 112 to avoid/mitigate conflicts…").
Maja teaches the subject matter of the claimed inventive concept as expressed in the rejections above. However, the teachings are taught in separate embodiments.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maja taught in separate embodiments for the desirable and advantageous purpose of providing technical solutions that facilitate automated conflict detection and detecting indirect and implicit conflicts among operations of a near-RT RICs, regardless of whether the conflicts occur on the same or different (neighboring) Near-RT RICs while supporting increased capacity, reducing the costs of RAN deployment and improving scalability and upgradeability of the RAN equipment, as discussed in Maja (See ¶ [0031, 0032]); thereby, achieving the predictable result of improving the overall efficiency and speed of the system with a reasonable expectation of success while enabling others skilled in the art to best utilize the invention along with various implementations and modifications as are suited to the particular use contemplated.
Regarding independent claim 10, Maja teaches:
A system (e.g., FIG. 3 of Maja), comprising: at least one processor (e.g., processor of Maja), and a memory (e.g., memory of Maja) coupled to the at least one processor and having instructions stored thereon, wherein, in response to execution by the at least one processor, the instructions facilitate performance of operations, comprising: receiving a configuration request from a first extended application (xApp) (See at least Maja, ¶ [0013]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…"), wherein the configuration request is to configure a control parameter utilized in a radio access network (RAN) (See at least Maja, ¶ [0013]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…"); determining that the control parameter is assigned to a second xApp (See at least Maja, ¶ [0056, 0061]; FIG. 2; "…a first type of xApps 132 can subscribe to rApps 130 and implement the policies that the rApps 130 issue over the interface A1. Second type of xApps 132 can execute independently from rApps 130 and govern the network behavior according to their own logic. xApps 132 execute in parallel of each other and conflicts can occur…", "…O-RAN Alliance specifies a conflict mitigation component which provides a E2 Guidance response that indicates whether the proposed changes from the xApp 132 conflict with changes from other xApps 132. If yes, conflict management can recommend modification for the proposed changes to the xApp 132 to attempt to avoid the conflict(s)…"); identifying, in the configuration request, a first configuration to be applied by the first xApp to the control parameter (See at least Maja, ¶ [0059]; FIG. 2; "…the near-RT RIC 104 checks the parameters that certain xApp 132 is attempting to modify before the update is implemented in the network…"); determining whether the first configuration conflicts with a second configuration applied to the control parameter by a second xApp (See at least Maja, ¶ [0059, 0061]; FIG. 2; "…the near-RT RIC 104 checks the parameters that certain xApp 132 is attempting to modify before the update is implemented in the network…", "…O-RAN Alliance specifies a conflict mitigation component which provides a E2 Guidance response that indicates whether the proposed changes from the xApp 132 conflict with changes from other xApps 132. If yes, conflict management can recommend modification for the proposed changes to the xApp 132 to attempt to avoid the conflict(s)…"); and in response to determining that the first configuration conflicts with the second configuration, denying the configuration request received from the first xApp (See at least Maja, ¶ [0075]; FIG. 2; "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter)…").
Maja teaches the subject matter of the claimed inventive concept as expressed in the rejections above. However, the teachings are taught in separate embodiments.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maja taught in separate embodiments for the desirable and advantageous purpose of providing technical solutions that facilitate automated conflict detection and detecting indirect and implicit conflicts among operations of a near-RT RICs, regardless of whether the conflicts occur on the same or different (neighboring) Near-RT RICs while supporting increased capacity, reducing the costs of RAN deployment and improving scalability and upgradeability of the RAN equipment, as discussed in Maja (See ¶ [0031, 0032]); thereby, achieving the predictable result of improving the overall efficiency and speed of the system with a reasonable expectation of success while enabling others skilled in the art to best utilize the invention along with various implementations and modifications as are suited to the particular use contemplated.
Regarding independent claim 17, Maja teaches:
A computer program product (e.g., ¶ [0112] of Maja) stored on a non-transitory computer-readable medium and comprising machine-executable instructions, wherein, in response to being executed, the machine-executable instructions cause a machine to perform operations, comprising: assigning a control parameter to a first extended application (xApp) (See at least Maja, ¶ [0072, 0073, 0075]; FIG. 2; "…the non-RT RIC 112 creates a respective set of policies for each near-RT RIC 114…", "…Upon reception of such policies, the conflict mitigator (402) aligns to them by updating the operational logic of the near-RT RIC 114…", "…The conflict mitigator 402 receives the conflict-mitigation policies… and retrieve when needed, i.e., every time when new E2 Guidance request arrives from each xApp 132. The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies…"), wherein the control parameter is configured to control operation of a feature of network equipment that is part of a radio access network (RAN) (See at least Maja, ¶ [0013, 0057]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…", "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…"); receiving, from a second xApp, a configuration request, wherein the configuration request comprises a first configuration to be applied to the control parameter (See at least Maja, ¶ [0013, 0057]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…", "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…"); determining whether the first configuration conflicts with a second configuration (See at least Maja, ¶ [0059, 0061]; FIG. 2; "…the near-RT RIC 104 checks the parameters that certain xApp 132 is attempting to modify before the update is implemented in the network…", "…O-RAN Alliance specifies a conflict mitigation component which provides a E2 Guidance response that indicates whether the proposed changes from the xApp 132 conflict with changes from other xApps 132. If yes, conflict management can recommend modification for the proposed changes to the xApp 132 to attempt to avoid the conflict(s)…"), wherein the control parameter is currently configured with the second configuration (See at least Maja, ¶ [0057, 0059, 0061]; FIG. 2; "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…", "…the near-RT RIC 104 checks the parameters that certain xApp 132 is attempting to modify before the update is implemented in the network…", "…O-RAN Alliance specifies a conflict mitigation component which provides a E2 Guidance response that indicates whether the proposed changes from the xApp 132 conflict with changes from other xApps 132. If yes, conflict management can recommend modification for the proposed changes to the xApp 132 to attempt to avoid the conflict(s)…"); and in response to a result of the determining being that the first configuration conflicts with the second configuration, denying the configuration request received from the second xApp (See at least Maja, ¶ [0013, 0057]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…", "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…").
Maja teaches the subject matter of the claimed inventive concept as expressed in the rejections above. However, the teachings are taught in separate embodiments.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maja taught in separate embodiments for the desirable and advantageous purpose of providing technical solutions that facilitate automated conflict detection and detecting indirect and implicit conflicts among operations of a near-RT RICs, regardless of whether the conflicts occur on the same or different (neighboring) Near-RT RICs while supporting increased capacity, reducing the costs of RAN deployment and improving scalability and upgradeability of the RAN equipment, as discussed in Maja (See ¶ [0031, 0032]); thereby, achieving the predictable result of improving the overall efficiency and speed of the system with a reasonable expectation of success while enabling others skilled in the art to best utilize the invention along with various implementations and modifications as are suited to the particular use contemplated.
Regarding dependent claim 2, Maja teaches:
in response to the determining whether the second xApp has granted the permission indicating that the second xApp has denied the permission for the first xApp to adjust the control parameter: denying, by the device, the request from the first xApp (See at least Maja, ¶ [0013, 0057]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…", "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…"); and maintaining, by the device, the control parameter with a current configuration applicable to the control parameter (See at least Maja, ¶ [0013, 0057]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…", "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…").
Regarding dependent claim 3, Maja teaches:
wherein the indicating that the second xApp has denied the permission comprises the indicating that the second xApp has denied the permission for the first xApp to adjust the control parameter for a specified period of time (e.g., control loops of different time scales for different operation and optimization processes (¶ [0046]) of Maja) (See at least Maja, ¶ [0013, 0057]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…", "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…").
Regarding dependent claim 4, Maja teaches:
assigning, by the device, the control parameter to the second xApp, wherein the assigning comprises instructing the second xApp that any adjustment of the control parameter by the first xApp is to be authorized by the second xApp prior to the adjustment of the control parameter by the first xApp (See at least Maja, ¶ [0013, 0057]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…", "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…").
Regarding dependent claim 5, Maja teaches:
determining, by the device, whether the first xApp has a first capability to access the control parameter (See at least Maja, ¶ [0057, 0059, 0061]; FIG. 2; "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…", "…the near-RT RIC 104 checks the parameters that certain xApp 132 is attempting to modify before the update is implemented in the network…", "…O-RAN Alliance specifies a conflict mitigation component which provides a E2 Guidance response that indicates whether the proposed changes from the xApp 132 conflict with changes from other xApps 132. If yes, conflict management can recommend modification for the proposed changes to the xApp 132 to attempt to avoid the conflict(s)…"); and in response to the determining whether the first xApp has the first capability to access the control parameter indicating that the first xApp has the first capability to access the control parameter, excluding, by the device, an access to the control parameter by a third xApp (e.g., xApps 132 of Maja) having a second capability to access the control parameter (See at least Maja, ¶ [0057, 0059, 0061]; FIG. 2; "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…", "…the near-RT RIC 104 checks the parameters that certain xApp 132 is attempting to modify before the update is implemented in the network…", "…O-RAN Alliance specifies a conflict mitigation component which provides a E2 Guidance response that indicates whether the proposed changes from the xApp 132 conflict with changes from other xApps 132. If yes, conflict management can recommend modification for the proposed changes to the xApp 132 to attempt to avoid the conflict(s)…").
Regarding dependent claim 6, Maja teaches:
wherein the excluding of the access to the control parameter by a third xApp (e.g., xApps 132 of Maja) is for a specified period of time (See at least Maja, ¶ [0046, 0055]; FIG. 2; "…O-RAN integrates automated operations into its overall architecture by providing three control loops of different time scales for different operation and optimization processes. The non-real-time control loop (involving the non-RT RIC 112 in SMO 102) has above-second time-frame, the near-real time control loop (involving the near-RT RICs 114) has sub-second time-frame, and finally, the real-time control loop (involving the O-DU 120) has the time-frame that is below 10 ms…", "…due to their proximity to the network entities (CUs 118, DUs 120, etc.), near-Real Time RICs 104 are used to host the xApps 132 that identify and enforce delay sensitive optimization policies that require insight in the domain state only. Accordingly, xApps 132 operate leveraging the near-real time control loop that is executed in under 1 s…"), and further comprising: upon expiry of the specified period of time, enabling, by the device, the access to the control parameter by the third xApp (e.g., xApps 132 of Maja) (See at least Maja, ¶ [0046, 0055]; FIG. 2; "…O-RAN integrates automated operations into its overall architecture by providing three control loops of different time scales for different operation and optimization processes. The non-real-time control loop (involving the non-RT RIC 112 in SMO 102) has above-second time-frame, the near-real time control loop (involving the near-RT RICs 114) has sub-second time-frame, and finally, the real-time control loop (involving the O-DU 120) has the time-frame that is below 10 ms…", "…due to their proximity to the network entities (CUs 118, DUs 120, etc.), near-Real Time RICs 104 are used to host the xApps 132 that identify and enforce delay sensitive optimization policies that require insight in the domain state only. Accordingly, xApps 132 operate leveraging the near-real time control loop that is executed in under 1 s…").
Regarding dependent claim 7, Maja teaches:
determining, by the device, that the second xApp is subsequently configuring the control parameter according to an updated configuration that is different than a current configuration applied to the control parameter (See at least Maja, ¶ [0013, 0057]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…", "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…"); and determining, by the device, whether a modification of the control parameter by the first xApp conflicts with the updated configuration applied by the second xApp (See at least Maja, ¶ [0057, 0059, 0061]; FIG. 2; "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…", "…the near-RT RIC 104 checks the parameters that certain xApp 132 is attempting to modify before the update is implemented in the network…", "…O-RAN Alliance specifies a conflict mitigation component which provides a E2 Guidance response that indicates whether the proposed changes from the xApp 132 conflict with changes from other xApps 132. If yes, conflict management can recommend modification for the proposed changes to the xApp 132 to attempt to avoid the conflict(s)…"); in response to the determining whether the modification of the control parameter by the first xApp conflicts with the updated configuration indicating that the modification of the control parameter by the first xApp conflicts with the updated configuration, terminating, by the device, the modification of the control parameter by the first xApp (See at least Maja, ¶ [0057, 0059, 0061]; FIG. 2; "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…", "…the near-RT RIC 104 checks the parameters that certain xApp 132 is attempting to modify before the update is implemented in the network…", "…O-RAN Alliance specifies a conflict mitigation component which provides a E2 Guidance response that indicates whether the proposed changes from the xApp 132 conflict with changes from other xApps 132. If yes, conflict management can recommend modification for the proposed changes to the xApp 132 to attempt to avoid the conflict(s)…"); and applying the updated configuration of the second xApp to the control parameter (See at least Maja, ¶ [0013]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…").
Regarding dependent claim 8, Maja teaches:
wherein the device is located in one of a real-time RAN intelligent controller (RIC) or a near-real-time RIC (See at least Maja, ¶ [0013]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…").
Regarding dependent claim 9, Maja teaches:
monitoring, by the device, operational history of the RAN (See at least Maja, ¶ [0013]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…"); determining, by the device, assignment of the control parameter to the second xApp is detrimental to operation of the RAN (See at least Maja, ¶ [0057, 0059, 0061]; FIG. 2; "…O-RAN Alliance has specified following conflict types between the xApps 132. Direct conflict: Different xApps 132 request to modify the same parameter (e.g., first xApp 132 requests increased antenna downtilt, and second xApp 132 requests decrease in the antenna downtilt)…", "…the near-RT RIC 104 checks the parameters that certain xApp 132 is attempting to modify before the update is implemented in the network…", "…O-RAN Alliance specifies a conflict mitigation component which provides a E2 Guidance response that indicates whether the proposed changes from the xApp 132 conflict with changes from other xApps 132. If yes, conflict management can recommend modification for the proposed changes to the xApp 132 to attempt to avoid the conflict(s)…"); and removing, by the device, assignment of the control parameter to the second xApp (See at least Maja, ¶ [0013]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…").
Regarding dependent claim 11, Maja teaches:
wherein the operations further comprise: assigning the control parameter to the second xApp (See at least Maja, ¶ [0014, 0075]; FIG. 2; "…in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN…The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter…", "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter). Accordingly, the near-RT RIC 114 adjusts the xApps 132 based on one or more policies that are dynamically adjusted by the non-RT RIC 112 to avoid/mitigate conflicts…"), wherein access to the control parameter is determined based on one or more configurations implemented by second xApp (See at least Maja, ¶ [0014, 0075]; FIG. 2; "…in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN…The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter…", "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter). Accordingly, the near-RT RIC 114 adjusts the xApps 132 based on one or more policies that are dynamically adjusted by the non-RT RIC 112 to avoid/mitigate conflicts…").
Regarding dependent claim 12, Maja teaches:
wherein the operations further comprise: reviewing operational history of the RAN (See at least Maja, ¶ [0110]; FIG. 2; "…the non-RT RIC can create network wide policy based on operational intents and historical action impact analysis from across all of the near-RT RICs…"); determining current operation of the RAN can be improved by reassigning the control parameter to a third xApp (e.g., xApps 132 of Maja) (See at least Maja, ¶ [0014, 0075]; FIG. 2; "…in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN…The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter…", "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter). Accordingly, the near-RT RIC 114 adjusts the xApps 132 based on one or more policies that are dynamically adjusted by the non-RT RIC 112 to avoid/mitigate conflicts…"); terminating assignment of the control parameter to the second xApp; and assigning the control parameter to a third xApp (e.g., xApps 132 of Maja) (See at least Maja, ¶ [0013]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…").
Regarding dependent claim 13, Maja teaches:
wherein the operations further comprise: in response to determining the first configuration does not conflict with the second configuration, applying the first configuration to the control parameter (See at least Maja, ¶ [0014, 0075]; FIG. 2; "…in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN…The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter…", "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter). Accordingly, the near-RT RIC 114 adjusts the xApps 132 based on one or more policies that are dynamically adjusted by the non-RT RIC 112 to avoid/mitigate conflicts…").
Regarding dependent claim 14, Maja teaches:
wherein the first xApp is denied access to the control parameter for a defined period of time (See at least Maja, ¶ [0013, 0046]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…", "…O-RAN integrates automated operations into its overall architecture by providing three control loops of different time scales for different operation and optimization processes. The non-real-time control loop (involving the non-RT RIC 112 in SMO 102) has above-second time-frame, the near-real time control loop (involving the near-RT RICs 114) has sub-second time-frame, and finally, the real-time control loop (involving the O-DU 120) has the time-frame that is below 10 ms…").
Regarding dependent claim 15, Maja teaches:
wherein the operations further comprise: upon expiry of the defined period of time, determining whether the first configuration conflicts with the second configuration applied to the control parameter by the second xApp (See at least Maja, ¶ [0046, 0055]; FIG. 2; "…O-RAN integrates automated operations into its overall architecture by providing three control loops of different time scales for different operation and optimization processes. The non-real-time control loop (involving the non-RT RIC 112 in SMO 102) has above-second time-frame, the near-real time control loop (involving the near-RT RICs 114) has sub-second time-frame, and finally, the real-time control loop (involving the O-DU 120) has the time-frame that is below 10 ms…", "…due to their proximity to the network entities (CUs 118, DUs 120, etc.), near-Real Time RICs 104 are used to host the xApps 132 that identify and enforce delay sensitive optimization policies that require insight in the domain state only. Accordingly, xApps 132 operate leveraging the near-real time control loop that is executed in under 1 s…"); and in response to determining no conflict exists between the first configuration and the second configuration after the expiry of the defined period of time, applying the first configuration received from the first xApp (See at least Maja, ¶ [0014, 0075]; FIG. 2; "…in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN…The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter…", "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter). Accordingly, the near-RT RIC 114 adjusts the xApps 132 based on one or more policies that are dynamically adjusted by the non-RT RIC 112 to avoid/mitigate conflicts…").
Regarding dependent claim 16, Maja teaches:
wherein the operations further comprise: while determining whether the first configuration conflicts with the second configuration, preventing access to the parameter by a third xApp (e.g., xApps 132 of Maja) (See at least Maja, ¶ [0014, 0075]; FIG. 2; "…in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN…The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter…", "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter). Accordingly, the near-RT RIC 114 adjusts the xApps 132 based on one or more policies that are dynamically adjusted by the non-RT RIC 112 to avoid/mitigate conflicts…").
Regarding dependent claim 18, Maja teaches:
the operations further comprise: in response to a determination that the first configuration does not conflict with the second configuration, applying the configuration request received from the second xApp to the control parameter (See at least Maja, ¶ [0014, 0075]; FIG. 2; "…in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN…The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter…", "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter). Accordingly, the near-RT RIC 114 adjusts the xApps 132 based on one or more policies that are dynamically adjusted by the non-RT RIC 112 to avoid/mitigate conflicts…").
Regarding dependent claim 19, Maja teaches:
wherein the configuration request received from the second xApp is denied for a defined duration of time (See at least Maja, ¶ [0046, 0055]; FIG. 2; "…O-RAN integrates automated operations into its overall architecture by providing three control loops of different time scales for different operation and optimization processes. The non-real-time control loop (involving the non-RT RIC 112 in SMO 102) has above-second time-frame, the near-real time control loop (involving the near-RT RICs 114) has sub-second time-frame, and finally, the real-time control loop (involving the O-DU 120) has the time-frame that is below 10 ms…", "…due to their proximity to the network entities (CUs 118, DUs 120, etc.), near-Real Time RICs 104 are used to host the xApps 132 that identify and enforce delay sensitive optimization policies that require insight in the domain state only. Accordingly, xApps 132 operate leveraging the near-real time control loop that is executed in under 1 s…"), wherein the operations further comprise: in response to a determination that the predefined duration of time has expired, re-determining whether the first configuration conflicts with the second configuration (See at least Maja, ¶ [0014, 0075]; FIG. 2; "…in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN…The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter…", "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter). Accordingly, the near-RT RIC 114 adjusts the xApps 132 based on one or more policies that are dynamically adjusted by the non-RT RIC 112 to avoid/mitigate conflicts…"); and in response to a result of the re-determining being that the first configuration does not conflict with the second configuration, applying the configuration request received from the second xApp to the control parameter (See at least Maja, ¶ [0014, 0075]; FIG. 2; "…in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN…The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter…", "…The conflict mitigator 402 determines whether the update (included in the E2 Guidance request) should be confirmed (i.e., applied) or rejected based on the received policies (i.e., policies allowing the xApp to update (or adjust) the parameter). Accordingly, the near-RT RIC 114 adjusts the xApps 132 based on one or more policies that are dynamically adjusted by the non-RT RIC 112 to avoid/mitigate conflicts…").
Regarding dependent claim 20, Maja teaches:
the operations further comprise, while determining whether the first configuration conflicts with the second configuration, preventing access to the parameter by a third xApp (e.g., xApps 132 of Maja) (See at least Maja, ¶ [0013]; FIG. 2; "…In response to receiving a request from an xApp from the several xApps to update a parameter of the RAN, the near-RT RIC updates the parameter based on the policy allowing the xApp to update the parameter, and the near-RT RIC maintains the parameter unchanged based on the policy restricting the xApp from updating the parameter…").
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure: See the Notice of References Cited (PTO–892)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IDOWU O OSIFADE whose telephone number is (571)272-0864. The Examiner can normally be reached on Monday-Friday 8:00am-5:00pm EST.
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, ANDREW MOYER can be reached on (571) 272 – 9523. The fax phone number for the organization where this application or proceeding is assigned is (571) 273 – 8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov.
Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at (866) 217 – 9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786 – 9199 (IN USA OR CANADA) or (571) 272 – 1000.
/IDOWU O OSIFADE/Primary Examiner, Art Unit 2675