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 .
Response to Amendment
Applicant’s submission filed on 07/21/2026 has been entered. Claims 1-10 are pending in the application. Examiner is re-opening prosecution based on Applicant’s remarks.
Response to Arguments
Applicant’s arguments with respect to claims 1-10 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Rejection(s) of claims 1-10 under U.S.C. 102 have been withdrawn. However, upon further consideration, a new ground(s) of U.S.C. 103 rejection is made over RANGANATH in view of ZHU.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “first data processing module” and “second processing module” in claim 2.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claims 1-10 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganath et al. (US 2024/0259879 A1), hereinafter “RANGANATH” in view of Zhu et al. (2024/0276301 A1), hereinafter “ZHU”.
Regarding claim 1, RANGANATH teaches, ‘A multi-protocol open radio access network system, comprising:’ (Paragraph [0026]: FIG. 1 depicts an example O-RAN architecture 100 including various interfaces between a RAN Intelligent Controller (RIC) 114 and service management and orchestration framework (SMO) 102):
‘a service management and orchestration apparatus comprising a non-real time radio access network (RAN) intelligent controller,’ (Paragraph [0026]: The O-RAN architecture 100 describes a model for RAN resource control, managed at the upper level by orchestration and automation components of the SMO 102 (e.g., policy, configuration, inventory, design, and non-RT RIC 112)),
‘and a near-real time RAN intelligent controller connected to the service management and orchestration apparatus,’ (Paragraph [0026]: These components control and communicate with the near-RT RIC 114 via the Al interface. The near-RT RIC 114 provides management of and connectivity to RAN nodes),
RANGANATH does not explicitly teach but ZHU teaches, ‘wherein the non-real time RAN intelligent controller comprises a first multi-protocol interface, and the first multi-protocol interface is configured to receive a plurality of first packets corresponding to different communication protocols’ (ZHU –Paragraph [0497]: In another example implementation, the ECT (Edge Computing Technology) 1935 operates according to the O-RAN framework… O-RAN Working Group 2 (Non-RT RIC and AI interface WG) AI interface… O-RAN Working Group 2 Non-RT RIC Architecture… O-RAN Working Group 2 Non-RT RIC: Functional Architecture… Paragraph [0042]: The DPPS 102 and 142 includes the client-side MAMS (Multiple Access Management Services) DPPS (Data Plane Protocol Stack) 102 implemented by the client 101 and the server-side MAMS DPPS 142 implemented by the server 140. For devices equipped with multiple radio link technologies (or multiple RAT circuitries), such as 5G/NR, LTE, WiFi, etc., MAMS [RFC8743] provides a programmable framework to dynamically select and transmit data simultaneously over multiple radio links for high throughput, low latency, and improved reliability. The MAMS DPPS 102, 142 includes the following two (sub)layers: the convergence (sub)layer and the adaptation (sub)layer; Paragraph [0044]: The MX Adaptation Layer can be implemented using existing protocols (e.g. TCP, UDP, IPSec, QUIC, etc.); Paragraph [0274]: (b) Connection Type: Type of RAT connection associated with the connection ID. Examples of the type of connection include "Wi-Fi", "5G_NR", "MulteFire", "LTE", "DSL", etc.) (Note: ZHU teaches incorporating O-RAN Non-RT RIC architectures with a multi-access, multi-protocol interface architecture (MAMS DPPS convergence/ adaptation sublayers) capable of receiving packet streams corresponding to diverse access network protocols including 5G/NR, LTE, Wi-Fi, MulteFire, DSL, TCP, UDP, IPsec, and QUIC))
‘and format the plurality of first packets to generate first formatted data;’ (ZHU – Paragraph [0043]: The MX convergence layer is configurable or operable to perform MX-specific tasks in the UP… by adapting encapsulating header/trailer schemes such as GRE or Generic Multi-Access (GMA). In some implementations, the MX convergence supports GMA, MPTCP Proxy, GRE Aggregation Proxy, and MPQUIC. As discussed in more detail infra, the GMA protocol may be used to encode additional control information (e.g., Key, Sequence Number, Timestamp, etc.) at this (sub)layer; Paragraph [0344]: The GMA Tx also adds a GMA header or trailer to the packet(s) and performs tunneling by, for example, repackaging the packet according to a suitable GMA tunneling protocol (Note: ZHU teaches data processing modules/convergence sublayers that ingest multi-protocol packets and perform format conversion/ encapsulation (adding GMA headers/ trailers, GRE, MPTCP, or MPQUIC) to generate unified, re-packaged formatted data units));
‘wherein the near-real time RAN intelligent controller comprises a second multi-protocol interface, and the second multi-protocol interface is configured to receive a plurality of second packets corresponding to different communication protocols’ (ZHU – Paragraph [0497]: Near-Real-time Intelligent Controller Architecture & E2 General Aspects and Principles… O-RAN Working Group 3 Near-Realtime Intelligent Controller Near-RT RIC Architecture; Paragraph [0035]: In the example of FIG. 1, the (R)AN 110A is a 3GPP-based access network such as an LTE E-UTRAN where the one or more (R)AN nodes 111A are evolved NodeBs (eNBs)… Additionally, in the example of FIG. 1, the (R)AN 110A is a WiFi-based access network where the (R)AN nodes 111B are WiFi Access Points (APs)… The multi-radio UE 101 is capable of establishing a 3GPP access link 105A with the eNB/gNB 111A… and capable of establishing a WiFi access link 105B with the AP 111B (Note: ZHU teaches integrating O-RAN Near-RT RIC architecture with a multi-protocol interface (MAMS/ GMA sublayers) at the controller level capable of concurrently establishing connections and receiving packets across different radio access protocols (such as 3GPP LTE/5G links and non-3GPP WiFi access links))
‘and format the plurality of second packets to generate second formatted data.’ (ZHU – Paragraph [0345]: The GMA Rx receives the packet(s) and unpackages the packet(s) according to the tunneling protocol being used, and removes the GMA header/trailer. The GMA Rx also reassembles and reorders the packet(s) that are delivered over multiple access networks based on the sequence numbers provided by the GMA Tx… and then delivers, in-order, the reassembled and reordered packet(s) to higher layers (Note: ZHU teaches receiving multi-protocol encapsulated packets, stripping/ unpackaging headers and trailers, and reassembling/ reordering the data to output unified formatted data to higher application layers)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of ZHU with RANGANATH because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of ZHU into RANGANATH is that ZHU provides MAMS (Multiple Access Management Services) and GMA (Generic Multi-Access) multi-protocol convergence sublayer (Multi-Protocol Interfaces) that allow RIC controllers and customized applications (xApps/rApps) to ingest and process data packets from diverse protocols (e.g., LTE, 5G NR, Wi-Fi, Ethernet, UDP, TCP, QUIC) in a unified format, avoiding the need to route non-3GPP/heterogeneous traffic through underlying base station stacks. Incorporating MAMS data proxies (N-MADP/C-MADP) at the near-RT RIC / Edge level allows near-real-time traffic steering, dynamic splitting, and packet reordering across heterogeneous links directly within local control loop, thereby significantly reducing feedback latency and improving user Quality of Experience (QoE) (See paragraph [0035], [0042]-[0044], [0344]-[0345], ZHU).
Regarding claim 2, RANGANATH and ZHU teach, The multi-protocol open radio access network system according to claim 1, RANGANATH does not explicitly teach but ZHU teaches, ‘wherein the first multi-protocol interface comprises a plurality of first sub-interfaces and a first data processing module, the first data processing module is connected to the plurality of first sub- interfaces, the plurality of first sub-interfaces are configured to receive the plurality of first packets, respectively, and the first data processing module is configured to format the plurality of first packets to generate the first formatted data,’ (ZHU – Paragraph [0026]: An access network is the segment in a network that delivers user data packets to a client via an access link such as a WiFi airlink, an cellular airlink, or DSL… The MAMS framework can be used to flexibly select the combination of uplink (UL) and downlink (DL) access and core network paths; Paragraph [0343]: The GMA data plane entity 1400… performs various functions such as path quality measurements (QoS, packet loss, latency, etc.), multi-link traffic steering (e.g. traffic splitting/steering, reordering, retransmission, duplication, coding, fragmentation, concatenation, etc.) (Note: ZHU teaches a two-tier interface structure wherein individual sub-interfaces (adaptation layers/ sockets for WiFi, Cellular, DSL) receive respective protocol packets and feed them into a unified data processing module (GMA data plane entity 1400) that performs reordering, decoding, and formatting)),
‘the second multi-protocol interface comprises a plurality of second sub-interfaces and a second data processing module, the second data processing module is connected to the plurality of second sub-interfaces, the plurality of second sub-interfaces are configured to receive the plurality of second packets, respectively, and the second data processing module is configured to format the plurality of second packets to generate the second formatted data.’ (ZHU – Paragraph [0035]: The multi-radio UE 101 is capable of establishing a 3GPP access link 105A with the eNB/gNB 111A… and capable of establishing a WiFi access link 105B with the AP 111B. The eNB/gNB 111A communicates with the server 140 via a 3GPP backhaul link 106A and the AP 111B communicates with the server 140 via a WiFi backhaul link 106B; Paragraph [0345]: The GMA Rx receives the packet(s) and unpackages the packet(s) according to the tunneling protocol being used, and removes the GMA header/trailer. The GMA Rx also reassembles and reorders the packet(s) that are delivered over multiple access networks (Note: ZHU teaches a corresponding two-tier receiver interface structure at the controller level where separate access sub-interfaces (3GPP and WiFi backhaul paths) receive packets and pass them to a data processing module (GMA Rx) for unpackaging and formatting)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of ZHU with RANGANATH because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of ZHU into RANGANATH is that ZHU provides MAMS (Multiple Access Management Services) and GMA (Generic Multi-Access) multi-protocol convergence sublayer (Multi-Protocol Interfaces) that allow RIC controllers and customized applications (xApps/rApps) to ingest and process data packets from diverse protocols (e.g., LTE, 5G NR, Wi-Fi, Ethernet, UDP, TCP, QUIC) in a unified format, avoiding the need to route non-3GPP/heterogeneous traffic through underlying base station stacks. Incorporating MAMS data proxies (N-MADP/C-MADP) at the near-RT RIC / Edge level allows near-real-time traffic steering, dynamic splitting, and packet reordering across heterogeneous links directly within local control loop, thereby significantly reducing feedback latency and improving user Quality of Experience (QoE) (See paragraph [0035], [0042]-[0044], [0344]-[0345], ZHU).
Regarding claim 3, RANGANATH and ZHU teach, The multi-protocol open radio access network system according to claim 2, RANGANATH does not explicitly teach but ZHU teaches, ‘wherein the plurality of first sub-interfaces are at least partially the same as the plurality of second sub-interfaces.’ (ZHU – Paragraph [0147]: (c) Anchor connections; Paragraph [0149]: (e) Delivery connections; Paragraph [0283]: Examples of the possible convergence methods include: "GMA", "MPTCP Proxy", "GREAggregation_Proxy", and "MPQUIC" (Note: ZHU discloses that the sub-interface protocol methods (e.g., GMA, MPTCP, GRE, MPQUIC) used on the first multi-protocol interface (anchor side) and the second multi-protocol interface (delivery side) are identical or at least partially overlap))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of ZHU with RANGANATH because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of ZHU into RANGANATH is that ZHU provides MAMS (Multiple Access Management Services) and GMA (Generic Multi-Access) multi-protocol convergence sublayer (Multi-Protocol Interfaces) that allow RIC controllers and customized applications (xApps/rApps) to ingest and process data packets from diverse protocols (e.g., LTE, 5G NR, Wi-Fi, Ethernet, UDP, TCP, QUIC) in a unified format, avoiding the need to route non-3GPP/heterogeneous traffic through underlying base station stacks. Incorporating MAMS data proxies (N-MADP/C-MADP) at the near-RT RIC / Edge level allows near-real-time traffic steering, dynamic splitting, and packet reordering across heterogeneous links directly within local control loop, thereby significantly reducing feedback latency and improving user Quality of Experience (QoE) (See paragraph [0035], [0042]-[0044], [0344]-[0345], ZHU).
Regarding claim 4, RANGANATH and ZHU teach, The multi-protocol open radio access network system according to claim 2, RANGANATH further teaches, ‘wherein the non-real time RAN intelligent controller further comprises a first database, the first database is connected to the first data processing module, the first database is configured to store the first formatted data,’ (Paragraphs [0028]-[0029]: Most cloud platforms today use standard telemetry collectors for the telemetry to be fed into the non-RT RIC using the O1 and O2 interfaces, which runs analytics and acts on the infrastructure telemetry every 10 seconds(s) or more. While the O2 interfaces acquire appropriate telemetry from the near-RT RIC 114, central unit (CU) 121, 122, and DU 115… which deploys an app manager and alarm manager on the near real-time RIC that primarily targets application telemetry and events from key performance measurements (KPMs) from an E2 terminator… and Influxdb data base that manages policies for the xApps),
‘and the near-real time RAN intelligent controller further comprises a second database, the second database is connected to the second data processing module, the second database is configured to store the second formatted data.’ (Paragraph [0029]: One existing solution is the OpenShift Container Platform (OCP) provided by Red Hat, Inc.®, which deploys an app manager and alarm manager on the near real-time RIC that primarily targets application telemetry and events from key performance measurements (KPMs) from an E2 terminator… and Influxdb data base that manages policies for the xApps).
Regarding claim 5, RANGANATH and ZHU teach, The multi-protocol open radio access network system according to claim 1, RANGANATH further teaches, ‘wherein the non-real time RAN intelligent controller further comprises a customized application connected to the first multi-protocol interface to receive the first formatted data.’ (Abstract: In particular, the present disclosure provides RIC-based resource management for individual RIC applications, which is based on the collection and analysis of platform telemetry data as well as measurements collected by user equipment and access network infrastructure elements; Paragraph [0028]: Most cloud platforms today use standard telemetry collectors for the telemetry to be fed into the non-RT RIC using the O1 and O2 interfaces, which runs analytics and acts on the infrastructure telemetry every 10 seconds (s) or more; Paragraph [0026]: The RIC 114 is an NF that also includes intelligent applications (apps) such as network ML/ AI apps functioning with it to automate various NFs for predictive maintenance, enhanced operation, and the like; Paragraph [0161]: The non-RT RIC 912 can include and/or operate one or more non-RT RIC applications (rApps) 911. The rApps 911 are modular apps that leverage functionality exposed via the non-RT RIC framework's R1 interface (Note: RANGANATH teaches that the Non-RT RIC hosts customized applications (rAPP 911) connected via the framework interface to receive processed/ formatted network data)).
Regarding claim 6, RANGANATH and ZHU teach, The multi-protocol open radio access network system according to claim 1, RANGANATH further teaches, ‘wherein the near-real time RAN intelligent controller further comprises a customized application connected to the second multi-protocol interface to receive the second formatted data.’ (Abstract: In particular, the present disclosure provides RIC-based resource management for individual RIC applications, which is based on the collection and analysis of platform telemetry data as well as measurements collected by user equipment and access network infrastructure elements; Paragraph [0029]: One existing solution is the OpenShift Container Platform (OCP) provided by Red Hat, Inc.®, which deploys an app manager and alarm manager on the near real-time RIC that primarily targets application telemetry and events from key performance measurements (KPMs) from an E2 terminator… However, the OCP framework does not consider or guarantee an xApp's run time performance and/or resource management customized for xApps within the time limits necessary for real-time or near real-time operations; Paragraph [0026]: The RIC 114 is an NF that also includes intelligent applications (apps) such as network ML/ AI apps functioning with it to automate various NFs for predictive maintenance, enhanced operation, and the like… Additionally, a core set of services provided by the near-RT RIC 114 is extensible by custom third-party xApps, which are instantiated as cloud services and have low-latency connectivity to RAN nodes (Note: RANGANATH discloses customized applications (third-party xApps) hosted within the Near-RT RIC 114 connected to internal interfaces to consume formatted data)).
Regarding claim 7, RANGANATH and ZHU teach, The multi-protocol open radio access network system according to claim 1, RANGANATH further teaches, ‘…Representational State Transfer Application Programming Interface, Message Queuing Telemetry Transport,…’ (Paragraph [0052]: The RIC 3c14 communicates with the application (app) layer 3c30 via interface 3c13, which may include one or more APIs, server-side web APIs, web services (WS), and/or some other interface or reference point. As examples, the interface 3c13 may be one or more of Representational State Transfer (REST) APIs, RESTful web services,… MQTT (formerly "Message Queueing Telemetry Transport"),… and/or the like (Note: RANGANATH teaches REST API and MQTT for the first multi-protocol interface))…
‘…Representational State Transfer Application Programming interface,…’ (Paragraph [0030]: Here, a slice-aware scheduler and an O-RAN E2 agent is added to the srsRAN, and a custom xApp (e.g., "NexRAN xApp" in FIG. 2) is added to the RIC to control slicing… NexRAN exposes this functionality, via a RESTful API, to a RAN slicing manager (Note: RANGANATH teaches REST API for the second multi-protocol interface))…
RANGANATH does not explicitly teach but ZHU teaches, ‘wherein the first multi-protocol interface supports at least two of…, Simple Network Management Protocol, Websocket, TR069 protocol and Kafka,’ (ZHU – Paragraphs [0075]-[0076]: FIG. 3 depicts an example MAMS Control-Plane Protocol Stack (CPPS) 300. The CPPS 300 includes an Multi-Access (MX) Control Message layer 303, a WebSocket layer, and a Transport Control Protocol (TCP)/ Transport Layer Security (TLS) layer. Here, WebSocket… is used for transporting management and control messages… between the NCM 236 and the CCM 206… FIG. 3 shows a MAMS management protocol stack 300m. Here, a secure websocket is established over a third transport layer (e.g., TCP, UDP, IP Security Protocol (IPSec), etc.) tunnel… for sending MAMS management messages between the CCM 206 and the NCM 236; Paragraph [0058]: Additionally or alternatively, WebSocket is used for transporting management and control messages between the NCM 236 and CCM 206, wherein MX Control Message are carried over (or encapsulated in) a WebSocket, and the WebSocket is carried over (or encapsulated in) TCP/TLS; Paragraph [0106]: FIG. 6 shows an enhanced Multi-Access data-plane protocol stack, in which a first transport protocol (including Transport-1a and Transport-1b for RAT-1 and Transport-2a and Transport-2b for RAT-2) are used at the adaptation sublayer... Transport-1b and Transport-2b (e.g., UDP and/or the like) is used for keep-alive messages and transporting user data packets… TCP is used for sending out the new trigger message (Note: ZHU teaches for the first multi-protocol management/ control interfaces at the upper control level supporting WebSocket)),
‘and the second multi-protocol interface supports at least two of …, Message Queuing Telemetry Transport, Simple Network Management Protocol, Websocket, TR069 protocol and Kafka.’ (ZHU – Paragraph [0070]: In MEC-based implementations… the MAMS system 235 may be implemented in or by a MEC host/server that is located in, or co-located with, a RAN 110 or RAN node 111. The functions that are located in the network side (e.g., the NCM 236 and N-MADP 237) can be hosted either at a centralized location or at an edge cloud; Paragraph [0075]: a WebSocket layer, and a Transport Control Protocol (TCP)/ Transport Layer Security (TLS) layer. Here, WebSocket… is used for transporting management and control messages (Note: ZHU teaches WebSocket for the second multi-protocol interface)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of ZHU with RANGANATH because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of ZHU into RANGANATH is that ZHU provides MAMS (Multiple Access Management Services) and GMA (Generic Multi-Access) multi-protocol convergence sublayer (Multi-Protocol Interfaces) that allow RIC controllers and customized applications (xApps/rApps) to ingest and process data packets from diverse protocols (e.g., LTE, 5G NR, Wi-Fi, Ethernet, UDP, TCP, QUIC) in a unified format, avoiding the need to route non-3GPP/heterogeneous traffic through underlying base station stacks. Incorporating MAMS data proxies (N-MADP/C-MADP) at the near-RT RIC / Edge level allows near-real-time traffic steering, dynamic splitting, and packet reordering across heterogeneous links directly within local control loop, thereby significantly reducing feedback latency and improving user Quality of Experience (QoE) (See paragraph [0035], [0042]-[0044], [0344]-[0345], ZHU).
Regarding claim 8, RANGANATH and ZHU teach, The multi-protocol open radio access network system according to claim 1, RANGANATH does not explicitly teach but ZHU teaches, ‘wherein the first multi-protocol interface is further configured to connect an Internet-of- things device.’ (ZHU - Paragraph [0028]: The MX client 101 is an end-user device that supports connections with one or more access nodes, possibly over different access technologies (or RATs), and is also referred to as a user station, user device, user equipment (UE), or multi-radio UE 101; Paragraph [0469]: The endpoints 1910 include UEs 1911, which may be IoT devices (also referred to as "IoT devices 1911"), which are uniquely identifiable embedded computing devices (e.g., within the Internet infrastructure) that comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of ZHU with RANGANATH because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of ZHU into RANGANATH is that ZHU provides MAMS (Multiple Access Management Services) and GMA (Generic Multi-Access) multi-protocol convergence sublayer (Multi-Protocol Interfaces) that allow RIC controllers and customized applications (xApps/rApps) to ingest and process data packets from diverse protocols (e.g., LTE, 5G NR, Wi-Fi, Ethernet, UDP, TCP, QUIC) in a unified format, avoiding the need to route non-3GPP/heterogeneous traffic through underlying base station stacks. Incorporating MAMS data proxies (N-MADP/C-MADP) at the near-RT RIC / Edge level allows near-real-time traffic steering, dynamic splitting, and packet reordering across heterogeneous links directly within local control loop, thereby significantly reducing feedback latency and improving user Quality of Experience (QoE) (See paragraph [0035], [0042]-[0044], [0344]-[0345], ZHU).
Regarding claim 9, RANGANATH and ZHU teach, The multi-protocol open radio access network system according to claim 1, RANGANATH does not explicitly teach but ZHU teaches, ‘wherein the second multi-protocol interface is further configured to connect a heterogeneous device.’ (ZHU – Paragraph [0035]: In the example of FIG. 1, the (R)AN 110A is a 3GPP-based access network such as an LTE E-UTRAN where the one or more (R)AN nodes 111A are evolved NodeBs (eNBs)… Additionally, in the example of FIG. 1, the (R)AN 110A is a WiFi-based access network where the (R)AN nodes 111B are WiFi Access Points (APs )…. The multi-radio UE 101 is capable of establishing a 3GPP access link 105A with the eNB/gNB 111A… and capable of establishing a WiFi access link 105B with the AP 111B; Paragraph [0074]: The present disclosure also provides a Software-Defined, Access-Agnostic, and High-Performance solution to such issues, which is referred to herein as Generic Multi-Access (GMA) to enable integration of multiple (heterogeneous or homogeneous) radio access networks and RATs at the Edge).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of ZHU with RANGANATH because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of ZHU into RANGANATH is that ZHU provides MAMS (Multiple Access Management Services) and GMA (Generic Multi-Access) multi-protocol convergence sublayer (Multi-Protocol Interfaces) that allow RIC controllers and customized applications (xApps/rApps) to ingest and process data packets from diverse protocols (e.g., LTE, 5G NR, Wi-Fi, Ethernet, UDP, TCP, QUIC) in a unified format, avoiding the need to route non-3GPP/heterogeneous traffic through underlying base station stacks. Incorporating MAMS data proxies (N-MADP/C-MADP) at the near-RT RIC / Edge level allows near-real-time traffic steering, dynamic splitting, and packet reordering across heterogeneous links directly within local control loop, thereby significantly reducing feedback latency and improving user Quality of Experience (QoE) (See paragraph [0035], [0042]-[0044], [0344]-[0345], ZHU).
Regarding claim 10, RANGANATH and ZHU teach, The multi-protocol open radio access network system according to claim 1, RANGANATH does not explicitly teach but ZHU teaches, ‘wherein the first multi-protocol interface is further configured to connect an Internet-of-things device,’ (ZHU - Paragraph [0469]: The endpoints 1910 include UEs 1911, which may be IoT devices (also referred to as "IoT devices 1911"), which are uniquely identifiable embedded computing devices (e.g., within the Internet infrastructure) that comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections),
‘and reconnect the Internet-of-things device when communication with the Internet-of-things device is interrupted,’ (ZHU – Paragraphs [0091]-[0092]: MAMS CP peers execute the keep-alive procedures to ensure that the other peers are reachable and to recover from dead-peer scenarios. Each MAMS CP endpoint maintains a Keep-Alive timer that is set for a duration of MAMS_KEEP ALIVE_TIMEOUT… If the sender does not receive a MAMS control message in response to MAMS_RETRY retries of the MX Keep-Alive Request, the MAMS peer declares that the peer is dead or unreachable. The CCM 206 may initiate the MAMS discovery procedure for re-establishing the MAMS session; Paragraph [0113]: The MA client 101 (or Ge 1301) will send out a probe message (e.g., Probe-REQ/ACK messages; see e.g., [RFC8743] § 8.6.3) over transport-b (e.g., UDP) immediately after receiving the KAT message, and the NAT device will then update its NAT mapping accordingly… Afterwards, downlink packet can be successfully delivered to the MA client 101 (or Ge 1301)),
‘and the second multi-protocol interface is further configured to connect a heterogeneous device,’ (ZHU – Paragraph [0035]: In the example of FIG. 1, the (R)AN 110A is a 3GPP-based access network such as an LTE E-UTRAN where the one or more (R)AN nodes 111A are evolved NodeBs (eNBs)… Additionally, in the example of FIG. 1, the (R)AN 110A is a WiFi-based access network where the (R)AN nodes 111B are WiFi Access Points (APs )…. The multi-radio UE 101 is capable of establishing a 3GPP access link 105A with the eNB/gNB 111A… and capable of establishing a WiFi access link 105B with the AP 111B; Paragraph [0074]: The present disclosure also provides a Software-Defined, Access-Agnostic, and High-Performance solution to such issues, which is referred to herein as Generic Multi-Access (GMA) to enable integration of multiple (heterogeneous or homogeneous) radio access networks and RATs at the Edge),
‘and reconnect the heterogeneous device when communication with the heterogeneous device is interrupted.’ (ZHU – Paragraph [0121]: At the beginning of procedure 800, all data traffic are sent over the RAT-B (e.g., WiFi) link… When the RAT-B NAN 111 (e.g., WiFi router) fails, the MA client 101 (or Ge 1301) will not receive any downlink packet, and trigger probing accordingly. Then, the MA client 101 (or Ge 1301) will detect the link failure through probing, and switch its data traffic over to the RAT-A (e.g., cellular (e.g., 5G/NR, LTE, mWiMAX, etc.)) link; Paragraph [0360]: If a link is declared "Link Failure", it should not be used to send any data or control packets, except "Probe/ACK", and the "Link Failure" status can only be turned off after successfully transmitting a probe message over the link).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of ZHU with RANGANATH because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of ZHU into RANGANATH is that ZHU provides MAMS (Multiple Access Management Services) and GMA (Generic Multi-Access) multi-protocol convergence sublayer (Multi-Protocol Interfaces) that allow RIC controllers and customized applications (xApps/rApps) to ingest and process data packets from diverse protocols (e.g., LTE, 5G NR, Wi-Fi, Ethernet, UDP, TCP, QUIC) in a unified format, avoiding the need to route non-3GPP/heterogeneous traffic through underlying base station stacks. Incorporating MAMS data proxies (N-MADP/C-MADP) at the near-RT RIC / Edge level allows near-real-time traffic steering, dynamic splitting, and packet reordering across heterogeneous links directly within local control loop, thereby significantly reducing feedback latency and improving user Quality of Experience (QoE) (See paragraph [0035], [0042]-[0044], [0344]-[0345], ZHU).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAESHIL J CHOI whose telephone number is (703)756-5409. The examiner can normally be reached Monday through Friday ET.
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, Jae Y Lee can be reached on 571-270-3936. 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.
/HAESHIL JESSICA CHOI/Examiner, Art Unit 2479
/JAE Y LEE/Supervisory Patent Examiner, Art Unit 2479
Prosecution Insights