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 record are entered.
Response to Arguments
Applicant's arguments filed 12/18/2025 have been fully considered but they are not persuasive.
The arguments pertaining the previous rejection is/are moot as the claim as been rewritten to further elaborate conceptual limitations with actual steps, a new ground of rejection has been necessitated.
In another argument, Applicant appears to take issue with the examiner’s provision of direct quotations from reference, and Applicant suggests the rejection is in error because the examiner does not provide further explanation to applicant’s standard of clarity.
The examiner respectfully disagrees. The examiner submits each and every limitations are mapped to disclosure. So long as all limitations are met and can be found in the cited references, then the rejection suffices. There is no requirement in the MPEP that mandates over-explaining when the disclosure itself is self-evidence, for sake of conciseness. For examples, in ¶0010, Ramamurthi discloses “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”, the disclosure is direct, concise, and on point to map with corresponding limitations (as in the rejection below). Or in ¶0012, “the RAN may expose an application programming interface (API) to allow the MEC platform to access RAN information”, there couldn’t be a more direct and clearer way to re-explain this concept to one of ordinary skill in the art better than the verbatim quote itself. As such, for the general audience of ordinary skill in the art, as well as Applicant who is one skilled in the art and presumably has the best understanding of the technology sought to be patented, the examiner believes over-explaining of the clear and concise prior art disclosure is rather redundant. Applicant is always welcome to point out if anything is unclear from the otherwise very clear disclosures of the references of record if clarification is needed. The examiner asserts each and every limitations are shown either expressively or inherently described with full details as arranged in the claims.
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 Parekh et al. (US 2022/0210709).
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, 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, RAN information from various RAN nodes are gathered at the non-real time/near real time RIC)
and at least one of sending the information collected by the xApp to an Application Programming Interface (API) service or sending the information collected by the rApp to the API service in a MEC architecture, wherein the API service is an aggregation point for a MEC platform in the MEC architecture; (¶0011, data collected at the RIC are transmitted to a MEC platform via interaction between RIC and MEC platform. ¶0012, 0033, an API is used for RAN to send the collected RAN information)
wherein the API service exposes the collected information sent by at least one of the xApp or the rApp 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)
While xApp or rApp are not explicitly named in Rammamurthi’s disclosure, however Rammarmuthi specifically disclose the gathering of RAN information is performed by the non-real-time RIC and the near-real-time RIC which gather information from other RAN nodes as well as from outside entities, such as the MEC platform per ¶0010.
It is well established in the art that the RICs are network functions that host xApps/rApps which in turn drive the logics that perform data collection, specifically near-real time RIC hosts xApps, and non-real time RICs which hosts rApps, as the entities are responsible for gathering RAN information over respective interfaces. In a related, field of endeavor, Parekh, discloses in ¶0063-0065, specifically, for example, the near real-time RIC hosts xApp/rApps which implements the control logics for collect and analyze from the RAN.
It would have been obvious to one of ordinary skill in the art before the effective filing time of the invention that the RICS of Rammarmuthi gathering RAN data via xApp/rApp, because this is an industry standard defined by O-RAN Alliance, wherein the Apps are the entities implementing the logics for data gathering as they are hosted by the RICs (¶0295 of Parekh).
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, 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, RAN information from various RAN nodes are gathered at the non-real time/near real time RIC)
and at least one of sending the information collected by the xApp to an Application Programming Interface (API) service or sending the information collected by the rApp to the API service in a MEC architecture, wherein the API service is an aggregation point for a MEC platform in the MEC architecture; (¶0011, data collected at the RIC are transmitted to a MEC platform via interaction between RIC and MEC platform. ¶0012, 0033, an API is used for RAN to send the collected RAN information)
wherein the API service exposes the collected information sent by at least one of the xApp or the rApp to a MEC application of the MEC platform. (¶012, “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)
While xApp or rApp are not explicitly named in Rammamurthi’s disclosure, however Rammarmuthi specifically disclose the gathering of RAN information is performed by the non-real-time RIC and the near-real-time RIC which gather information from other RAN nodes as well as from outside entities, such as the MEC platform per ¶0010.
It is well established in the art that the RICs are network functions that host xApps/rApps which in turn drive the logics that perform data collection, specifically near-real time RIC hosts xApps, and non-real time RICs which hosts rApps, as the entities are responsible for gathering RAN information over respective interfaces. In a related, field of endeavor, Parekh, discloses in ¶0063-0065, specifically, for example, the near real-time RIC hosts xApp/rApps which implements the control logics for collect and analyze from the RAN.
It would have been obvious to one of ordinary skill in the art before the effective filing time of the invention that the RICS of Rammarmuthi gathering RAN data via xApp/rApp, because this is an industry standard defined by O-RAN Alliance, wherein the Apps are the entities implementing the logics for data gathering as they are hosted by the RICs (¶0295 of Parekh).
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 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, RAN information from various RAN nodes are gathered at the non-real time/near real time RIC)
and at least one of sending the information collected by the xApp to an Application Programming Interface (API) service or sending the information collected by the rApp to the API service in a MEC architecture, wherein the API service is an aggregation point for a MEC platform in the MEC architecture; (¶0011, data collected at the RIC are transmitted to a MEC platform via interaction between RIC and MEC platform. ¶0012, 0033, an API is used for RAN to send the collected RAN information)
wherein the API service exposes the collected information sent by at least one of the xApp or the rApp to a MEC application of the MEC platform. (¶012, “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)
While xApp or rApp are not explicitly named in Rammamurthi’s disclosure, however Rammarmuthi specifically disclose the gathering of RAN information is performed by the non-real-time RIC and the near-real-time RIC which gather information from other RAN nodes as well as from outside entities, such as the MEC platform per ¶0010.
It is well established in the art that the RICs are network functions that host xApps/rApps which in turn drive the logics that perform data collection, specifically near-real time RIC hosts xApps, and non-real time RICs which hosts rApps, as the entities are responsible for gathering RAN information over respective interfaces. In a related, field of endeavor, Parekh, discloses in ¶0063-0065, specifically, for example, the near real-time RIC hosts xApp/rApps which implements the control logics for collect and analyze from the RAN.
It would have been obvious to one of ordinary skill in the art before the effective filing time of the invention that the RICS of Rammarmuthi gathering RAN data via xApp/rApp, because this is an industry standard defined by O-RAN Alliance, wherein the Apps are the entities implementing the logics for data gathering as they are hosted by the RICs (¶0295 of Parekh).
As to claims 2, 9, and 16:
Rammarmuthi in view of Parekh 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 Parekh 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 Parekh 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 also ¶0295-0296 of Parekh)
As to claims 5, 12, and 19:
Rammarmuthi in view of Parekh 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 Parekh 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 at least Parekh, ¶0063-0065, xApps and rApps collect various information via E2/O1 interfaces directly)
As to claims 7 and 14:
Rammarmuthi in view of Parekh 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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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