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. Claim Objections Claim 20 objected to because of the following informalities: “ The computer program product according to claim 15, wherein the machine is one of a real-time RAN intelligent controller (RIC), a near-real-time RIC, or a non-real-time RIC . ” Applicant should amend claim language to state” The computer program product according to claim 16 , wherein the machine executable instructions is one of a real-time RAN intelligent controller (RIC), a near-real-time RIC, or a non-real-time RIC. Appropriate correction is required. Claim Rejections - 35 USC § 102 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 ( i.e., changing from AIA to pre-AIA ) 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 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)(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. Claim(s) 1-4, 7, 8, 10-14 and 16-19 is/are rejected under 35 U.S.C. 102 (a1) as being anticipated by White et al. (US11711719) (hereinafter White) . Per claim 1, A method, comprising: receiving, by a device comprising a processor (col.9 lines 41-44, processor load) , a request to onboard a first application ( xApp ) (col. 7, lines 27-36, Fig 1a , i.e. Application 203 may further request (at 206) monitoring profile information for application 203, based on attributes of UE 201, from application provider 103. Application provider 103 may select (at 208) a particular reporting profile, associated with the particular application 203 [ i.e., App_1 in this example ] , based on association information 207. Association information 207 may be or may include some or all of the example information described above with respect to data structure 105 ) , wherein the first xApp is configured to adjust a first metric of a radio access network (RAN) (col.10 lines 12-21, i.e. Fig 3 and Fig 5, For example, application provider 103 may receive and/or access (at 318) the aggregated KPI information associated with application 203 (and/or one or more other applications with which application provider 103 is associated), in order to analyze such information and identify potential parameters or factors that may be modified to improve performance associated with application 203 ) ; and determining, by the device, whether adjustment of the first metric causes a conflict with current operation of the RAN (col. 10 lines 30-37, Fig 3 and 5, for RAN , i.e. For example, UE KPIs [ e.g., as received at 310 ] associated with one or more UEs 201 executing application 203 may indicate increased processor load when performing a particular function of application 203. Application provider 103 may modify aspects of application 203 [ e.g., modify source code, modify application libraries, etc. ] in order to reduce processor load of UEs 201 utilizing the particular function of application 203 ). Per claim 2, White discloses t he method according to claim 1, further comprising: determining, by the device, whether the RAN is able to support adjustment of the first metric by the first xApp ; and in response to the RAN being determined to be unable to support adjustment of the first metric by the first xApp (col. 2 lines 47-50, i.e. For example, in one scenario, the KPI monitoring system of some embodiments may determine that an end-to-end latency associated with a given application is higher than a threshold latency and col.2 lines 56-67, i.e. and In such scenarios, the UE and/or the application provider may be alerted as to the detected processor load, in order to allow a user of the UE and/or the application provider to make adjustments (e.g., the user may close other running applications, the application provider may modify one or more parameters of the application in order to reduce processor utilization, etc.). Further, in such a scenario, adjustments to the network may not be made, as the primary factor in the end-to-end latency exceeding the threshold latency may be the processor load of the UE rather than parameters of the network. ) , denying, by the device, an onboarding request from the first xApp to operate the first xApp at the RAN (col. 7 lines 17-26 , Fig 3 and 5 [RAN info] , For example, application 203 may instruct (e.g., via UE API 205) UE 201 to present a prompt (e.g., a visual prompt, an audible prompt, etc.) requesting user consent to monitor and/or report UE KPIs and/or attributes when using application 203. , examiner interprets that user of the device did not give consent if in situations where end to end latency exceeds a threshold latency via APP 1). Per claim 3, White discloses t he method according to claim 1, further comprising: determining, by the device, a second metric adjusted by a second xApp ( col. 3 lines 38-47, i.e. For example, application provider 103 may register a particular application for monitoring of KPIs associated with one or more UEs that install and/or execute the application. As noted above, the monitoring of KPIs associated with execution of the application at such UEs [ e.g., relating to processing resources, memory resources, storage resources, device attributes, etc. ] may provide further insight as to the performance of the application and/or the UEs, based on which modifications to the application, the UEs, one or more networks, etc. may be determined and see col . 11 lines 5-11, i.e. A user of UE 201 may be alerted to take action to improve the signal strength [ e.g., move to a location that is closer to a wireless access point , remove obstructions or objects that may affect signal strength, etc. ] , and/or UE 205 may modify parameters of UE 201 to improve signal strength [ e.g., increase an antenna gain of one or more antennas of UE 201, modify beamforming parameters associated with UE 201, etc. ] , where examiner interprets that moving to location closer to wireless access point which may involve App 2 and associated profile information [Profile C] and KPI metrics, see Fig 1a) , wherein the first metric of the first xApp and the second metric of the second xApp have a common control target (see Fig 1a and 1b, profile A & B and Token A&B associated with App 1 and Profile C and token C associated with App 2 , common control target, see col. 2 lines 34-41, see below as it relates to the Application/ kpis associated end to end quality of services are met ) ; and in response to determining, by the device, the first metric of the first xApp and the second metric of the second xApp have a common control target (col. 2 lines 34-41, i.e. Based on these UE-specific KPIs and/or attributes, the KPI monitoring system may be better able to determine end-to-end KPIs associated with the application. The determination of such end-to-end KPIs may allow the determination (e.g., by a provider of the application and/or service, and/or by a provider of the network) to determine whether one or more QoS thresholds associated with the application and/or service are met ) , further determining , by the device, whether the first metric of the first xApp deleteriously affects operation of the common control target as a function of operation of the common control target adjusted by the second metric of the second xApp (col. 11 lines 5-11, A user of UE 201 may be alerted to take action to improve the signal strength [e.g., move to a location that is closer to a wireless access point, remove obstructions or objects that may affect signal strength, etc. ], and/or UE 205 may modify parameters of UE 201 to improve signal strength [e.g., increase an antenna gain of one or more antennas of UE 201, modify beamforming parameters associated with UE 201, etc. ], where examiner interprets that moving to location closer to wireless access point which may involve App 2 and associated profile information [Profile C] and KPI metrics, see Fig 1a , and see lines 34-41 as it relates to the Application/ kpis associated end to end quality of services are met) . Per claim 4, , White discloses t he method according to claim 3, further comprising: in response to the first metric of the first xApp being determined to be deleteriously affecting the operation of the common control target as a function of the operation of the common control target adjusted by the second metric of the second xApp (refer to claim 3 rationale) , denying, by the device, an onboarding request from the first xApp to operate the first xApp at the RAN (col.10 lines 51-57, i.e. . UE API 205 and/or a user of the first UE 201 may therefore be alerted that the performance of application 203 is not as expected due to the processor load of UE 201, and may take action to remedy the increased processor load of UE 201. Such action may include uninstalling or disabling particular applications or features of UE 201, or other suitable actions , examiner interprets col. 11 lines 5-11, if App 2 , A user of UE 201 may be alerted to take action to improve the signal strength [e.g., move to a location that is closer to a wireless access point , where App 2 becomes suitable for install or load, where examiner interprets parts of App 1 may not be required such as profile B[F i g 1a ] , where that portion the App will be disabled or uninstalled. Per claim 7, refer to the same rationale as explained in claim 4, however instead of denying a request, Examiner interprets White may adjust in Figure 1A, ref. 105 , where third metric may have negative impacts where profile A , the network latency may be below a certain threshold, where App 1 profile B may have adjust ed the app latency and App 2 , profile C may have adjust ed the CPU load, which may have caused the negative impact of the network latency in App1, profile A Per claim 8, White discloses t he method according to claim 7, further comprising: terminating, by the device, execution of the first xApp (col. 12 lines 24-34, As discussed above, UE 201 may proceed to monitor the KPIs in conjunction with execution of the application, such as at times that correspond to when the application sends and/or receives traffic (e.g., to and/or from MEC 303, an application server, network 301, and/or some other device or system), times at which application 203 is opened or closed, times at which application 203 performs particular functions (e.g., starts or stops a voice call or videoconference, performs a particular computation, calls a particular subroutine, etc.), and/or at other suitable times associated with the execution of application 203). Per claim 10 , refer to the same rationale as explained in claim 1 and 3, (see claim 3 portion [the second metric ] of the second xApp have a common control target, further determining, by the device, whether the first metric of the first xApp deleteriously affects operation of the common control target as a function of operation of the common control target adjusted by the second metric of the second xApp ). Per claim 1 1 , refer to the same rationale as explained in claim 4, instead of denying a request, see (col.10 lines 51-57, i.e. . UE API 205 and/or a user of the first UE 201 may therefore be alerted that the performance of application 203 is not as expected due to the processor load of UE 201, and may take action to remedy the increased processor load of UE 201. Such action may include uninstalling or disabling particular applications or features of UE 201, or other suitable actions , examiner interprets col. 11 lines 5-11, if App 2 , A user of UE 201 may be alerted to take action to improve the signal strength [e.g., move to a location that is closer to a wireless access point, where App 2 becomes suitable for install or load, where examiner interprets parts of App 1 may not be required such as profile B[Fig 1a], where that portion the App 1 will be disabled or uninstalled. Per claim 12, Wh ite discloses t he system of claim 10, wherein the operations further comprise: in response to determining that the control of the second metric by the second xApp (Fig 1a, ref. 105, App2, profile C, for example , app latency , also see col.3 lines 7-17, adjustments to the network (e.g., modifications of QoS parameters, modifications of routing parameters, etc.) may be made in order to reduce latency introduced by the network. Further, adjustments to the UE and/or the application may not be made, as the primary factor in the end-to-end latency exceeding the threshold latency, in this example, may be related to the parameters of the network, rather than the processor load of the UE ) is being adversely affected by the control of the first metric by the first xApp , operating the first xApp (Fig 1a, ref. 105, App 1, profile A, for example network latency , also see col.3 lines 7-17, adjustments to the network (e.g., modifications of QoS parameters, modifications of routing parameters, etc.) may be made in order to reduce latency introduced by the network. Further, adjustments to the UE and/or the application may not be made, as the primary factor in the end-to-end latency exceeding the threshold latency, in this example, may be related to the parameters of the network, rather than the processor load of the UE ) for a first period of time; and operating the second xApp for a second period of time, wherein the first period of time and the second period of time are non-overlapping and disparate (col.8 lines 57-63, i.e. For example, UE API 205 and application 203 may communicate in order to monitor some or all of the KPIs associated with the particular monitoring profile. For example, application 203 may indicate times at which application traffic has been sent or received by application 203, amounts of application traffic sent or received by application 203, times at which communication sessions [ e.g., voice calls, video conferences, gaming sessions, etc. ] associated with application 203 have started or ended, or other suitable information , examiner interprets non overlapping with no conflicts or operating at above thresholds) . Per claim 13, similar rationale to the claim language in claims 4 and 7, instead of denying onboard request , terminating the first app, (col.10 lines 51-57, i.e. . UE API 205 and/or a user of the first UE 201 may therefore be alerted that the performance of application 203 is not as expected due to the processor load of UE 201, and may take action to remedy the increased processor load of UE 201. Such action may include uninstalling or disabling particular applications or features of UE 201, or other suitable actions see examiner interprets col. 11 lines 5-11, if App 2 , A user of UE 201 may be alerted to take action to improve the signal strength [e.g., move to a location that is closer to a wireless access point, where App 2 becomes suitable for install or load, where examiner interprets parts of App 1 may not be required such as profile B[Fig 1a], where that portion the App will be disabled or uninstalled. As it relates to the third metric, Examiner interprets White may adjust in Figure 1A, ref. 105 , where third metric may have negative impacts where profile A, the network latency maybe below a certain threshold, where App 1 profile B may have adjusted the app latency and App 2, profile C may have adjusted the CPU load, which may have caused the negative impact of the network latency in App1, profile A , where the first App is terminated Per claim 14, White discloses t he system of claim 10, wherein the first metric has a key performance indicator (KPI) configured to identify operation of the first metric, and wherein the first metric relates to at least one of coverage of the RAN, capacity of the RAN, or an energy-related performance of the RAN (col. 3 lines 23-30 , 56-67 and col. 4 lines 1-5, i.e. . As shown in FIG. 1A, KPI monitoring system 101 may receive (at 102) identifying information for one or more applications from application provider 103. For example, application provider 103 may communicate with KPI monitoring system 101 via one or more networks, an API, a web portal, a configuration interface, and/or some other suitable communication pathway provided by or otherwise associated with KPI monitoring system 101 and For example, the KPIs and/or attributes may include a measure of load of one or more Central Processing Units (“CPUs”) and/or other types of processors of the UE, processor speed, quantity of processor cores, memory (e.g., RAM) capacity, a measure of available and/or utilized memory, a measure of storage capacity, a measure of available and/or utilized storage, a measure of network latency (e.g., a measure of round trip delay between the UE and one or more devices or systems via one or more networks), a measure of application latency (e.g., a measure of delay between an input to the application and an output generated by the application), a measure of signal strength and/or quality (e.g., Signal-to-Interference-and-Noise-Ratio (“SINR”), Received Signal Strength Indicator (“RSSI”), Channel Quality Indicator (“CQI”) and etc.) . Per claim 16, refer to the same rationale as explained in claim 10, instead of first and second metric, replaced with first and second operational characteristics, which is a threshold level (col. 2 lines 50-63, i.e. The KPI monitoring system may further determine that network latency associated with communications, between the UE and an application server, MEC, etc. that provides services associated with the application, is relatively low [ e.g., below a threshold ] , but that processing resources associated with the UE are relatively overloaded [ e.g., above a threshold level of processor load ] . In such scenarios, the UE and/or the application provider may be alerted as to the detected processor load, in order to allow a user of the UE and/or the application provider to make adjustments [ e.g., the user may close other running applications, the application provider may modify one or more parameters of the application in order to reduce processor utilization, etc. ]) . Per claim 17, refer to the same rationale as explained in claim 4. Per claim 18, refer to the same rationale as explained in claim 16, wherein claim 18 no negatively affected threshold levels for first and second App, therefore no adjustments are required, where it’s interpreted that both App1 and App2 operate as normal. Per claim 1 9 , refer to the same rationale as explained in claim 4, instead of denying a request, see (col.10 lines 51-57, i.e. . UE API 205 and/or a user of the first UE 201 may therefore be alerted that the performance of application 203 is not as expected due to the processor load of UE 201, and may take action to remedy the increased processor load of UE 201. Such action may include uninstalling or disabling particular applications or features of UE 201, or other suitable actions, examiner interprets col. 11 lines 5-11, if App 2 , A user of UE 201 may be alerted to take action to improve the signal strength [e.g., move to a location that is closer to a wireless access point, where App 2 becomes suitable for install or load, where examiner interprets parts of App 1 may not be required such as profile B[Fig 1a], where that portion the App 1 will be disabled or uninstalled. 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. Claim (s) 5 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over White in view of Ryan et al. (US20150052251) (hereinafter Ryan) . Per claim 5, White discloses t he method according to claim 3, discloses further comprising: in response to the first metric of the first xApp being determined to be deleteriously affecting the operation of the common control target as a function of the operation of the common control target adjusted by the second metric of the second xApp (see claim 4 rationale) , but fails to disclose applying, by the device, a first priority to the first xApp and a second priority to the second xApp , wherein the first priority has a higher priority than the second priority; based on the higher priority, executing, by the device, the first xApp ; terminating, by the device, operation of the first xApp ; and executing, by the device, the second xAp p . In an analogous field of endeavor, Ryan discloses the first priority has a higher priority than the second priority (paragraph 0048, Fig 5, Thus, first application 500a has a higher priority (1) than second application 500b (2), which in turn has a higher priority than third application 500c ) ; based on the higher priority, executing, by the device, the first xApp ; terminating, by the device, operation of the first xApp (paragraph 0056, i.e. w hen first application 600a terminates and associated configuration parameters are unlocked, data is written from the master record 604 to the current record 602 ) ; and executing, by the device, the second xApp (paragraph 0056, i.e. second application 600b writes data to first master record 604, which is a database that holds long term default parameter settings for network elements, etc. ) . Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Ryan into the invention White, where White provides a n application, executed by a User Equipment (“UE”), may receive an identifier, which may be used to monitor Key Performance Indicators (“KPIs”) associated with the UE. Such KPIs may be monitored in conjunction with execution of the application, such as at times that the application sends and/or receives traffic and Ryan provides A method for managing multiple processes simultaneously in a communications network includes running a first application controlling a parameter of a network element, launching a second application, comparing a priority of the first application to a priority of the second application to determine a higher priority application and a lower priority application in order to provide a better quality of services via automated system for optimization and management of communication networks when conflicts in the network arise such as load imbalances or out of service network cells, see Ryan, paragraphs 0006 and 0007. Per claim 6, White and Ryan discloses t he method according to claim 5, wherein White discloses the operation of the first xApp is terminated based on a configured duration of time (col. 12 lines 24-34, As discussed above, UE 201 may proceed to monitor the KPIs in conjunction with execution of the application, such as at times that correspond to when the application sends and/or receives traffic (e.g., to and/or from MEC 303, an application server, network 301, and/or some other device or system), times at which application 203 is opened or closed, times at which application 203 performs particular functions (e.g., starts or stops a voice call or videoconference, performs a particular computation, calls a particular subroutine, etc.), and/or at other suitable times associated with the execution of application 203 ) . 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. Claim (s) 9 , 15 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over White further in view of Lee et al . (US20230112127) (hereinafter Lee) Per claim 9, White discloses t he method according to claim 1, but fails to disclose wherein the RAN is an open-RAN (O-RAN). In an analogous filed of endeavor, Lee discloses wherein the RAN is an open-RAN (O-RAN) ( paragraph 0030, t he RAN 150 may be an open RAN [ O-RAN ]) . Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Lee into the invention White, where Lee provides a n electronic device and an operation method thereof according to various embodiments may determine a node to which an xAPP is to be deployed based on information related to a message processed by at least one E2 node in order to provide a better quality of service for determining a node in which xAPP is to be deployed based on information related to a message which executed in a radio access network intelligent controller (RIC) , see Lee, paragraphs 0005-0007. Per claim 15, White discloses t he system of claim 10, but fails to disclose wherein the system is one of a real-time RAN intelligent controller (RIC), a near-real-time RIC, or a non-real-time RIC In an analogous field of endeavor, Lee discloses wherein the system is one of a real-time RAN intelligent controller (RIC), a near-real-time RIC, or a non-real-time RIC ( paragraph 0004, a non-real-time RIC , similar motivation as claim 9, see paragraphs 0005-0007) . Per claim 20, refer to the same rationale as explained in claim 15. Any inquiry concerning this communication or earlier communications from the examiner should be directed to FILLIN "Examiner name" \* MERGEFORMAT JOSEPH E DEAN, JR whose telephone number is FILLIN "Phone number" \* MERGEFORMAT (571)270-7116 . The examiner can normally be reached FILLIN "Work Schedule?" \* MERGEFORMAT Mon-Fri 7:30-3:30 . 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, Alison Slater can be reached at FILLIN "SPE Phone?" \* MERGEFORMAT 571-270-0375 . 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. /JOSEPH E DEAN, JR/ Primary Examiner, Art Unit 2647