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 .
Claims 1-20 is/are pending.
Amendments of 8/18/2026 - RCE are entered.
Response to Arguments
Applicant's arguments filed 08/18/2026 have been fully considered but they are moot in view of a new ground of rejection established to address the amendments.
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 (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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ramamurthi et al. (US 2022/0167182) in view of Yang et al. (US 2022/0286916), and in further view of de la Oliva et al. (US 2021/00211914).
As to claim 1:
Rammamurthi discloses:
A method of Open Radio Access Network (RAN) - Multi-Access Edge Computing (MEC) information exchange (Abstract, ¶0068, CRM implementing a method), the method comprising:
at least one of collecting, (by an xApp) for a RAN-MEC information exchange, information shared by at least one RAN function over at least one of an O1 interface or an E2 interface in a RAN architecture
or
collecting, (by an rApp) for the RAN-MEC information exchange, information shared by the at least one RAN function over at least one of the 01 interface or the E2 interface in the RAN architecture;
(See ¶0010, the RICs collecting RAN info from other RAN nodes as well as from outside entities, such as the MEC platform, for example, “The non-real-time RIC and the near-real-time RIC may gather information from other RAN nodes as well as from outside entities, such as the MEC platform”, “a non-real time RAN Intelligent Controller (RIC), a near-real-time RIC, various open interfaces (e.g., O1, A1, E2, open fronthaul interface, etc.), and interoperability with standard interfaces (e.g., Third Generation Partnership Project (3GPP) interfaces, such as F1, W1, E1, X2, Xn, etc”. See also ¶0033, 0037, 0039, 0056, RAN information from various RAN nodes are gathered at the non-real time/near real time RIC)
Sending the collected information to a MEC platform using an two-way API architecture
(See at least ¶0011, data collected at the RIC are transmitted to a MEC platform via interaction between the RIC and the MEC platform, see at least ¶0012, the RAN expose an API to allow MEC platform to access RAN information, ¶0033, 0037, 0059 API is used for RAN to send the collected RAN, 2-way bus)
wherein the API is used to the collected information to a MEC application of the MEC platform.
(¶012, API is used to expose the collected info to MEC, i.e. “the RAN may expose an application programming interface (API) to allow the MEC platform to access RAN information”, ¶0033, “APIs associated with the control and RAN nodes may be exposed to allow the MEC to access specific RAN information. Similarly, in order to allow information to be accessed by control and RAN nodes, the MEC API may be exposed to allow particular information to be exchanged”, ¶0059)
Rammarmuthi does not explicitly disclose (i) that collecting is performed by an xApp hosted on a near -RT RIC or by an rApp hosted on a non-RT RIC, or (ii) that the API is an API service in the MEC platform that is an aggregation point for that MEC platform and that exposes the collected information sent by at least one of the xApp/rApp to a MEC application of the MEC platform.
Yang, regarding (i), in a related field of O-RAN architecture, discloses collecting RAN information by applications, i.e. an xApp for near RT RIC or an rApp for non-RT RIC over the O1/E2 interfaces. Each RIC serves as a platform on which RAN-controlled applications execute. The near-RT RIC/non-RT RICs use data collection and communications per ¶0046-0047. See ¶0053, 0007-0008, 0047, these applications gather data sent from other nodes via data collection operation.
It would have been obvious to one of ordinary skill in the art before the effective filing time of the invention that the RIC-based collection of Ramamurthi is done as a data collection procedure by an xApp on the near-RT RIC and/or the rApp on the non-RT RIC, as taught by Yang in the discussion above. Both references concern the same O-RAN RIC gathering split. Yang identifies the applications that run on those RICs and perform the data collection Ramamurthi already assigned to the RICs. Doing so would have been a predictable use of known O-RAN applications types on a known RIC platforms with their intended purposes.
In addition:
De la Oliva, regarding (ii), discloses an API service in a MEC platform that gathers radio-network information and exposes to a MEC application, wherein MEC offers RT network information to applications via RNIS per Abstract, ¶0081. RNIS is a hosted as a mobile-edge service on the MEC platform (¶0077-0078). See also ¶0090, RNIS defined by ETSI MEC gathers and reports underlying radio network conditions to an ME app. ¶0081, RNIS provides a representational state transfer (REST) application program interface (API) that includes or responds to a query or direct access service and notification subscription service. See also ¶0099, 0149-0150, a single RNIS service may be presented to ME apps that encapsulates radio network information for all RATs in a single interface and service end-point, and a MEC APP uses RNIS to obtain information of the collected information.
It would have been obvious to one of ordinary skill in the art before the effective filing time of the invention to implement the MEC-based API of Ramamurthi, in view of xApp/rApp data collection of Yang, as an RNIS-type API service in the MEC platform that aggregates collected RAN information and exposes it to a MEC application, as taught by de la Oliva. Given that Ramamurti already communicates RAN/RIC information across the two-way API with the MEC platform (per ¶0012, 0033, 0037), de la Oliva provides the known MEC-platform service that gathers and delivers such data to MEC applications. This combination would have been a predictable arrangement of known MEC architecture with the benefit of ready access/delivery for MEC applications the same RAN data which Ramamurthi already exchanges over the two-way API.
As to claim 8:
Rammamurthi discloses:
A non-transitory computer-readable medium containing instructions for Open Radio Access Network (RAN) - Multi-Access Edge Computing (MEC) information exchange (Abstract, ¶0068, CRM implementing a method), which when executed, cause a system to perform steps comprising:
at least one of collecting, (by an xApp) for a RAN-MEC information exchange, information shared by at least one RAN function over at least one of an O1 interface or an E2 interface in a RAN architecture
or
collecting, (by an rApp) for the RAN-MEC information exchange, information shared by the at least one RAN function over at least one of the 01 interface or the E2 interface in the RAN architecture;
(See ¶0010, the RICs collecting RAN info from other RAN nodes as well as from outside entities, such as the MEC platform, for example, “The non-real-time RIC and the near-real-time RIC may gather information from other RAN nodes as well as from outside entities, such as the MEC platform”, “a non-real time RAN Intelligent Controller (RIC), a near-real-time RIC, various open interfaces (e.g., O1, A1, E2, open fronthaul interface, etc.), and interoperability with standard interfaces (e.g., Third Generation Partnership Project (3GPP) interfaces, such as F1, W1, E1, X2, Xn, etc”. See also ¶0033, 0037, 0039, 0056, RAN information from various RAN nodes are gathered at the non-real time/near real time RIC)
Sending the collected information to a MEC platform using an two-way API architecture
(See at least ¶0011, data collected at the RIC are transmitted to a MEC platform via interaction between the RIC and the MEC platform, see at least ¶0012, the RAN expose an API to allow MEC platform to access RAN information, ¶0033, 0037, 0059 API is used for RAN to send the collected RAN, 2-way bus)
wherein the API is used to the collected information to a MEC application of the MEC platform.
(¶012, API is used to expose the collected info to MEC, i.e. “the RAN may expose an application programming interface (API) to allow the MEC platform to access RAN information”, ¶0033, “APIs associated with the control and RAN nodes may be exposed to allow the MEC to access specific RAN information. Similarly, in order to allow information to be accessed by control and RAN nodes, the MEC API may be exposed to allow particular information to be exchanged”, ¶0059)
Rammarmuthi does not explicitly disclose (i) that collecting is performed by an xApp hosted on a near -RT RIC or by an rApp hosted on a non-RT RIC, or (ii) that the API is an API service in the MEC platform that is an aggregation point for that MEC platform and that exposes the collected information sent by at least one of the xApp/rApp to a MEC application of the MEC platform.
Yang, regarding (i), in a related field of O-RAN architecture, discloses collecting RAN information by applications, i.e. an xApp for near RT RIC or an rApp for non-RT RIC over the O1/E2 interfaces. Each RIC serves as a platform on which RAN-controlled applications execute. The near-RT RIC/non-RT RICs use data collection and communications per ¶0046-0047. See ¶0053, 0007-0008, 0047, these applications gather data sent from other nodes via data collection operation.
It would have been obvious to one of ordinary skill in the art before the effective filing time of the invention that the RIC-based collection of Ramamurthi is done as a data collection procedure by an xApp on the near-RT RIC and/or the rApp on the non-RT RIC, as taught by Yang in the discussion above. Both references concern the same O-RAN RIC gathering split. Yang identifies the applications that run on those RICs and perform the data collection Ramamurthi already assigned to the RICs. Doing so would have been a predictable use of known O-RAN applications types on a known RIC platforms with their intended purposes.
In addition:
De la Oliva, regarding (ii), discloses an API service in a MEC platform that gathers radio-network information and exposes to a MEC application, wherein MEC offers RT network information to applications via RNIS per Abstract, ¶0081. RNIS is a hosted as a mobile-edge service on the MEC platform (¶0077-0078). See also ¶0090, RNIS defined by ETSI MEC gathers and reports underlying radio network conditions to an ME app. ¶0081, RNIS provides a representational state transfer (REST) application program interface (API) that includes or responds to a query or direct access service and notification subscription service. See also ¶0099, 0149-0150, a single RNIS service may be presented to ME apps that encapsulates radio network information for all RATs in a single interface and service end-point, and a MEC APP uses RNIS to obtain information of the collected information.
It would have been obvious to one of ordinary skill in the art before the effective filing time of the invention to implement the MEC-based API of Ramamurthi, in view of xApp/rApp data collection of Yang, as an RNIS-type API service in the MEC platform that aggregates collected RAN information and exposes it to a MEC application, as taught by de la Oliva. Given that Ramamurti already communicates RAN/RIC information across the two-way API with the MEC platform (per ¶0012, 0033, 0037), de la Oliva provides the known MEC-platform service that gathers and delivers such data to MEC applications. This combination would have been a predictable arrangement of known MEC architecture with the benefit of ready access/delivery for MEC applications the same RAN data which Ramamurthi already exchanges over the two-way API.
As to claim 15:
Rammamurthi discloses:
A system for Open Radio Access Network (RAN) - Multi-Access Edge Computing (MEC) information exchange (Abstract, ¶0068, CRM implementing a method), comprising:
Radio Access Network (RAN) infrastructure, including a memory coupled to a processor, wherein the RAN infrastructure is configured to:
at least one of collect, (by an xApp) for a RAN-MEC information exchange, information shared by at least one RAN function over at least one of an O1 interface or an E2 interface in a RAN architecture
or
collect, (by an rApp) for the RAN-MEC information exchange, information shared by the at least one RAN function over at least one of the 01 interface or the E2 interface in the RAN architecture;
(See ¶0010, the RICs collecting RAN info from other RAN nodes as well as from outside entities, such as the MEC platform, for example, “The non-real-time RIC and the near-real-time RIC may gather information from other RAN nodes as well as from outside entities, such as the MEC platform”, “a non-real time RAN Intelligent Controller (RIC), a near-real-time RIC, various open interfaces (e.g., O1, A1, E2, open fronthaul interface, etc.), and interoperability with standard interfaces (e.g., Third Generation Partnership Project (3GPP) interfaces, such as F1, W1, E1, X2, Xn, etc”. See also ¶0033, 0037, 0039, 0056, RAN information from various RAN nodes are gathered at the non-real time/near real time RIC)
Send the collected information to a MEC platform using a two-way API architecture
(See at least ¶0011, data collected at the RIC are transmitted to a MEC platform via interaction between the RIC and the MEC platform, see at least ¶0012, the RAN expose an API to allow MEC platform to access RAN information, ¶0033, 0037, 0059 API is used for RAN to send the collected RAN, 2-way bus)
wherein the API is used to expose the collected information to a MEC application of the MEC platform.
(¶012, API is used to expose the collected info to MEC, i.e. “the RAN may expose an application programming interface (API) to allow the MEC platform to access RAN information”, ¶0033, “APIs associated with the control and RAN nodes may be exposed to allow the MEC to access specific RAN information. Similarly, in order to allow information to be accessed by control and RAN nodes, the MEC API may be exposed to allow particular information to be exchanged”, ¶0059)
Rammarmuthi does not explicitly disclose (i) that collecting is performed by an xApp hosted on a near -RT RIC or by an rApp hosted on a non-RT RIC, and (ii) that the API is an API service in the MEC platform that is an aggregation point for that MEC platform and that exposes the collected information sent by at least one of the xApp/rApp to a MEC application of the MEC platform.
Yang, regarding (i), in a related field of O-RAN architecture, discloses collecting RAN information by applications, i.e. an xApp for near RT RIC or an rApp for non-RT RIC over the O1/E2 interfaces. Each RIC serves as a platform on which RAN-controlled applications execute. The near-RT RIC/non-RT RICs use data collection and communications per ¶0046-0047. See ¶0053, 0007-0008, 0047, these applications gather data sent from other nodes via data collection operation.
It would have been obvious to one of ordinary skill in the art before the effective filing time of the invention that the RIC-based collection of Ramamurthi is done as a data collection procedure by an xApp on the near-RT RIC and/or the rApp on the non-RT RIC, as taught by Yang in the discussion above. Both references concern the same O-RAN RIC gathering split. Yang identifies the applications that run on those RICs and perform the data collection Ramamurthi already assigned to the RICs. Doing so would have been a predictable use of known O-RAN applications types on a known RIC platforms with their intended purposes.
In addition:
De la Oliva, regarding (ii), discloses an API service in a MEC platform that gathers radio-network information and exposes to a MEC application, wherein MEC offers RT network information to applications via RNIS per Abstract, ¶0081. RNIS is a hosted as a mobile-edge service on the MEC platform (¶0077-0078). See also ¶0090, RNIS defined by ETSI MEC gathers and reports underlying radio network conditions to an ME app. ¶0081, RNIS provides a representational state transfer (REST) application program interface (API) that includes or responds to a query or direct access service and notification subscription service. See also ¶0099, 0149-0150, a single RNIS service may be presented to ME apps that encapsulates radio network information for all RATs in a single interface and service end-point, and a MEC APP uses RNIS to obtain information of the collected information.
It would have been obvious to one of ordinary skill in the art before the effective filing time of the invention to implement the MEC-based API of Ramamurthi, in view of xApp/rApp data collection of Yang, as an RNIS-type API service in the MEC platform that aggregates collected RAN information and exposes it to a MEC application, as taught by de la Oliva. Given that Ramamurti already communicates RAN/RIC information across the two-way API with the MEC platform (per ¶0012, 0033, 0037), de la Oliva provides the known MEC-platform service that gathers and delivers such data to MEC applications. This combination would have been a predictable arrangement of known MEC architecture with the benefit of ready access/delivery for MEC applications the same RAN data which Ramamurthi already exchanges over the two-way API.
As to claims 2, 9, and 16:
Rammarmuthi in view of Yang and de la Oliva disclose all limitations of claim 1/8/15, wherein the RAN architecture includes an ORAN architecture. (See Rammarmuthi, ¶0010, Open RAN structure)
As to claims 3, 10, and 17:
Rammarmuthi in view of Yang and de la Oliva disclose all limitations of claim 2, 9, and 17, wherein the at least one function includes at least one of a radio unit (RU) function, a distributed unit (DU) function, a centralized unit control plane (CU-CP) function, or a centralized unit user plane (CU-UP) function of the ORAN architecture. (See at least Rammarmuthi, ¶0026-0028, at least DU, CU-UP, CU-CP, etc.)
As to claims 4, 11, and 18:
Rammarmuthi in view of Yang and de la Oliva disclose all limitations of claim 2, 9, and 17, wherein:
the xApp for the RAN-MEC information exchange is in a near-Real Time (RT) Radio Area Network (RAN) Intelligent controller (RIC) of the ORAN architecture; and the rApp for the RAN-MEC information exchange is in a non-RT RIC of the ORAN architecture. (This limitation recites the intrinsic fact of Open RAN structure, with rApp in non-RT RIC, xApp in near-RT RIC. See Yang, ¶0046, Each MC 105 or 115 serves as a platform on which RAN control applications execute. These applications can be developed by third-party suppliers that are different from the RIC vendors. These applications are referred to as “xApps” (for the near-RT RIC 115) and “rApps” (for the non-RT RIC 105))
As to claims 5, 12, and 19:
Rammarmuthi in view of Yang and de la Oliva disclose all limitations of claim 1/8/15, wherein the MEC platform is outside of a core network. (See Rammarmuthi, Fig. 1, MEC platforms are outside of core network 150)
As to claims 13, 6, and 20:
Rammarmuthi in view of Yang and de la Oliva disclose all limitations of claim 1/8/15, further comprising instructions, which when executed, cause the system to perform steps comprising:
collecting, by the xApp for the RAN-MEC information exchange, information shared by at least one RAN function over at least one of an O1 interface or an E2 interface in the RAN architecture without using a proprietary interface; and collecting, by the rApp for the RAN-MEC information exchange, information shared by the at least one RAN function over at least one of the O1 interface or the E2 interface in the RAN architecture without using a proprietary interface.
(See Yang, ¶0003, 007-0008, 0053, 0055, data collection over E2, also ¶0066-0067, near-RT RIC uses O1, SDK uses O1 to control-plan xApps. ¶0046, rApp for non-RT RIC. See also Ramamurthi, ¶0010, O1, A1, E2 as open interfaces)
As to claims 7 and 14:
Rammarmuthi in view of Yang and de la Oliva disclose all limitations of claim 8, wherein the MEC application is a 3rd party application. (See Ramamurthy, ¶0020, 0021, the MEC network hosting MEC applications is a separate network, including network function virtualization (NFV), software defined networking (SDN), cloud computing, webscale, or another type of network technology. Depending on the implementation, MEC network 130 may include, for example, virtualized network functions (VNFs), containerized network functions (CNFs), multi-access (MA) applications/services, and/or servers. These are separate from the core 150, thus they are 3rd party entities)
Conclusion
References considered pertinent to the invention include:
US 2022/0167236 - A radio access network (RAN) intelligent controller (RIC) and corresponding method may be implemented within RAN and in next-generation cellular networks to improve performance. The RIC comprises an interface to a RAN and further comprises a data-driven logic unit. The data-driven logic unit (i) produces, based on data received from the RAN via the interface, a representation describing a state of the RAN and (ii) based on the representation describing the state, instructs an action associated with at least one network element. The interface transmits a message based on the action instructed. The message is to be routed to the at least one network element. The representation is based on a context of the RAN. The message transmitted enabling re-configuration of the at least one network element. The re-configuration improves performance of the at least one network element within the context.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUAN M HUA whose telephone number is (571)270-7232. The examiner can normally be reached 10:30-6: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, Anthony Addy can be reached at 571-272-7795. 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.
/QUAN M HUA/Primary Examiner, Art Unit 2645
Prosecution Insights