DETAILED ACTION
Notice of 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 Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7 are rejected under 35 U.S.C. 103 as being unpatentable over Apostolis Salkintzis (US 20250202801 A1), hereinafter referenced as Salkintzis, in view of Gundavelli et al. (US 20220124850 A1), hereinafter referenced as Gundavelli, and further in view of ZHU et al. (US 20240259857 A1), hereinafter referenced as Zhu.
Claims 8-9, 11 and 13-19 are rejected under 35 U.S.C. 103 as being unpatentable over Apostolis Salkintzis (US 20250202801 A1), hereinafter referenced as Salkintzis, in view of in view of ZHU et al. (US 20240259857 A1), hereinafter referenced as Zhu.
Regarding claim 1, Salkintzis teaches an apparatus for wireless communication at a user equipment (UE), comprising: one or more memories; and one or more processors, coupled to the one or more memories (Para. [0004]-Salkintzis discloses method of a User Equipment (“UE”) producer for multipath QUIC for ATSSS using stream-aware steering mode includes establishing a multiaccess data connection with a mobile communication network, the multiaccess data connection configured to apply a set of steering rules. Fig. 7, Para. [0137-0140]-Salkintzis discloses user equipment apparatus 700 that may be used for multipath QUIC for ATSSS using stream-aware steering mode, according to embodiments of the disclosure. The user equipment apparatus 700 may be one embodiment of the remote unit 105 and/or the UE 201. Furthermore, the user equipment apparatus 700 may include a processor 705, a memory 710, an input device 715, an output device 720, a transceiver 725 ... controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor 705 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor 705 executes instructions stored in the memory 710 to perform the methods and routines), individually or collectively configured to cause the UE to:
receive a configuration that indicates an internet protocol (IP) address that applies to an access traffic steering, switching, and splitting lower layer (ATSSS-LL) entity (Fig. 2, Para. [0077-0081]-Salkintzis discloses UE 201 is configured with ATSSS rules for steering/routing uplink traffic to the UPF 203, ... UE 201 receives MPQUIC proxy information, i.e., one IP address of the UPF 203, one UDP port number, and the proxy type (e.g., “masque” or “connect-udp”). This MPQUIC proxy information is used by the UE 201 for establishing QUIC connections with the UPF 203, which operates as an MPQUIC proxy. Para. [0038]-Salkintzis two steering functionalities have been defined in 3GPP Technical Specification (“TS”) 23.501: (a) the Multi-Path TCP (“MPTCP”) steering functionality and (b) the ATSSS-Low Layer (“ATSSS-LL”) steering functionality) and
at least one of an ATSSS multipath transmission control protocol (MPTCP) entity (Para. [0038]-Salkintzis discloses two steering functionalities have been defined in 3GPP Technical Specification (“TS”) 23.501: (a) the Multi-Path TCP (“MPTCP”) steering functionality and (b) the ATSSS-Low Layer (“ATSSS-LL”) steering functionality) or
an ATSSS multipath-enabled quick user datagram protocol internet connections (MPQUIC) entity (Fig. 2, Para. [0077-0081]-Salkintzis discloses UE 201 is configured with ATSSS rules for steering/routing uplink traffic to the UPF 203, ... UE 201 receives MPQUIC proxy information, i.e., one IP address of the UPF 203, one UDP port number, and the proxy type (e.g., “masque” or “connect-udp”). This MPQUIC proxy information is used by the UE 201 for establishing QUIC connections with the UPF 203, which operates as an MPQUIC proxy);
transmit the first packet on a first link (Para. [0065]-Salkintzis discloses the UPF(s) 141 is/are responsible for packet routing and forwarding. Fig. 1, Para. [0144]-Salkintzis discloses the remote unit communicates with the 3GPP access 20) network 120 using 3GPP communication links 123 and communicates with the non-3GPP access network 130 using non-3GPP communication links 133) and
the second packet on a second link (Para. [0065]-Salkintzis discloses the UPF(s) 141 is/are responsible for packet routing and forwarding. Fig. 1, Para. [0144]-Salkintzis discloses the remote unit communicates with the 3GPP access 20) network 120 using 3GPP communication links 123 and communicates with the non-3GPP access network 130 using non-3GPP communication links 133).
Salkintzis fails to explicitly teach generate a first packet with the IP address as a source IP address in a first header of the first packet and an associated second packet with the IP address as the source IP address in a second header of the second packet.
However, Gundavelli teaches generate a first packet with the IP address as a source IP address in a first header of the first packet and an associated second packet with the IP address as the source IP address in a second header of the second packet (Para. [0056]-Gundavelli discloses UE 102 may apply the ATSSS-LL rules on UL traffic for sending packets to the enterprise network 104 utilizing an appropriate access network(s). Para. [0064]-Gundavelli discloses an ATSSS-LL rule could be configured to indicate that duplicate UL/DL packets are to be transmitted over two different access network connections, which may include two different RAT types or two different APs for a same RAT type (e.g., for dual connectivity capable UEs). Para. [0013]-Gundavelli discloses for ATSSS-LL one common IP address (e.g., IP-3) is used and packets to IP-3 can be routed on both WLA and WWA access paths, such as for non-MPTCP flows, which may include TCP, User Datagram Protocol (UDP) and Ethernet flows. Para. [0057]-Gundavelli discloses in various embodiments, SDFs for different traffic may be identified based on Traffic Flow Templates (TFTs), which may utilize any combination of IP address information (e.g., source, destination address), UDP port numbers, application identifiers (e.g., in Layer 7 (L7) traffic, application instance identifiers, traffic analysis heuristics, machine learning, and/or the like).
Salkintzis and Gundavelli are both considered to be analogous to the claimed invention because they are in the same field of communication network equipment and services, dealing with Access Traffic Steering, Switching, and Splitting Low-Layer (ATSSS-LL) policies to an enterprise network.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis to incorporate the teachings of Gundavelli on ATSSS, with a motivation to generate first and second packets with a specified source and destination ip address, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Salkintzis fails to explicitly teach neither the first packet nor the second packet is encapsulated in another packet with a different IP address.
However, Zhu teaches neither the first packet nor the second packet is encapsulated in another packet with a different IP address (Para. [0078]-Zhu discloses if the ATSSS-LL functionality 415 is used (e.g., the “Layer 3 approach”), the MA PDU session contains IP traffic of two interfaces over 3GPP access 310A and Non-3GPP access 310B with one common IP addresses (e.g., IP@3). Para. [0103]-Zhu discloses “Multi-Access Traffic Steering Request” message may include a data element, data field, IE, etc., for each of the following elements: a Traffic Steering REQ ID to uniquely identify this traffic steering request; IP Packet Filter Set to identify the IP flows that the requested traffic steering rule applies, and may include IP source (src)/destination (dst) addresses (addr), src/dst port, and protocol type (number). Para. [0303]-Zhu discloses steering the traffic over multiple access network connections of the one or more access network connections when the traffic includes duplicated packets for an application having high-reliability and low-latency requirements. Table 3, Para. [0114]-Zhu discloses sending duplicated (redundancy) packets over multiple access network connections for high-reliability and low-latency applications 4 = QoS, e.g., performing MTS based on the specific QoS requirements from the app.).
Zhu is considered to be analogous because it is in the same field of edge computing, network communication, and communication system implementation, dealing with techniques for implementing Multi-access Edge Computing (MEC) systems, Multiple Access Management Services (MAMS), and Fifth Generation (5G) Access Traffic Switching, Steering, and Splitting (ATSSS).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis in view of Gundavelli to incorporate the teachings of Zhu on packet transmission, with a motivation for non-encapsulated packets, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Regarding claims 8 and 11, Salkintzis teaches an apparatus for wireless communication at a user equipment (UE), comprising: one or more memories; and one or more processors, coupled to the one or more memories (Para. [0004]-Salkintzis discloses method of a User Equipment (“UE”) producer for multipath QUIC for ATSSS using stream-aware steering mode includes establishing a multiaccess data connection with a mobile communication network, the multiaccess data connection configured to apply a set of steering rules. Fig. 7, Para. [0137-0140]-Salkintzis discloses user equipment apparatus 700 that may be used for multipath QUIC for ATSSS using stream-aware steering mode, according to embodiments of the disclosure. The user equipment apparatus 700 may be one embodiment of the remote unit 105 and/or the UE 201. Furthermore, the user equipment apparatus 700 may include a processor 705, a memory 710, an input device 715, an output device 720, a transceiver 725 ... controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor 705 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor 705 executes instructions stored in the memory 710 to perform the methods and routines), individually or collectively configured to cause the UE to:
receive a configuration that indicates an internet protocol (IP) address that applies to an access traffic steering, switching, and splitting lower layer (ATSSS-LL) entity (Fig. 2, Para. [0077-0081]-Salkintzis discloses UE 201 is configured with ATSSS rules for steering/routing uplink traffic to the UPF 203, ... UE 201 receives MPQUIC proxy information, i.e., one IP address of the UPF 203, one UDP port number, and the proxy type (e.g., “masque” or “connect-udp”). This MPQUIC proxy information is used by the UE 201 for establishing QUIC connections with the UPF 203, which operates as an MPQUIC proxy. Para. [0038]-Salkintzis two steering functionalities have been defined in 3GPP Technical Specification (“TS”) 23.501: (a) the Multi-Path TCP (“MPTCP”) steering functionality and (b) the ATSSS-Low Layer (“ATSSS-LL”) steering functionality) and
at least one of an ATSSS multipath transmission control protocol (MPTCP) entity (Para. [0038]-Salkintzis discloses two steering functionalities have been defined in 3GPP Technical Specification (“TS”) 23.501: (a) the Multi-Path TCP (“MPTCP”) steering functionality and (b) the ATSSS-Low Layer (“ATSSS-LL”) steering functionality) or
an ATSSS multipath-enabled quick user datagram protocol internet connections (MPQUIC) entity (Fig. 2, Para. [0077-0081]-Salkintzis discloses UE 201 is configured with ATSSS rules for steering/routing uplink traffic to the UPF 203, ... UE 201 receives MPQUIC proxy information, i.e., one IP address of the UPF 203, one UDP port number, and the proxy type (e.g., “masque” or “connect-udp”). This MPQUIC proxy information is used by the UE 201 for establishing QUIC connections with the UPF 203, which operates as an MPQUIC proxy);
receive a first packet on a first link with the IP address as a destination IP address in a first header of the first packet (Para. [0065]-Salkintzis discloses the UPF(s) 141 is/are responsible for packet routing and forwarding. Fig. 1, Para. [0144]-Salkintzis discloses the remote unit communicates with the 3GPP access 20) network 120 using 3GPP communication links 123 and communicates with the non-3GPP access network 130 using non-3GPP communication links 133. Para. [0116]-Salkintzis discloses each UDP packet 417 contains an IP header, a UDP header and a corresponding UDP payload. The source IP address is set to the UE's MA PDU Session address, the destination IP address is set to the remote host's address, and the destination UDP port is set to the remote host's port) and
an associated second packet on a second link with the IP address as a destination IP address in a second header of the second packet (Para. [0065]-Salkintzis discloses the UPF(s) 141 is/are responsible for packet routing and forwarding. Fig. 1, Para. [0144]-Salkintzis discloses the remote unit communicates with the 3GPP access 20) network 120 using 3GPP communication links 123 and communicates with the non-3GPP access network 130 using non-3GPP communication links 133. Para. [0116]-Salkintzis discloses each UDP packet 417 contains an IP header, a UDP header and a corresponding UDP payload. The source IP address is set to the UE's MA PDU Session address, the destination IP address is set to the remote host's address, and the destination UDP port is set to the remote host's port).
Salkintzis fails to explicitly teach neither the first packet nor the second packet is encapsulated in another packet with a different IP address.
However, Zhu teaches neither the first packet nor the second packet is encapsulated in another packet with a different IP address (Para. [0078]-Zhu discloses if the ATSSS-LL functionality 415 is used (e.g., the “Layer 3 approach”), the MA PDU session contains IP traffic of two interfaces over 3GPP access 310A and Non-3GPP access 310B with one common IP addresses (e.g., IP@3). Para. [0103]-Zhu discloses “Multi-Access Traffic Steering Request” message may include a data element, data field, IE, etc., for each of the following elements: a Traffic Steering REQ ID to uniquely identify this traffic steering request; IP Packet Filter Set to identify the IP flows that the requested traffic steering rule applies, and may include IP source (src)/destination (dst) addresses (addr), src/dst port, and protocol type (number). Para. [0303]-Zhu discloses steering the traffic over multiple access network connections of the one or more access network connections when the traffic includes duplicated packets for an application having high-reliability and low-latency requirements. Table 3, Para. [0114]-Zhu discloses sending duplicated (redundancy) packets over multiple access network connections for high-reliability and low-latency applications 4 = QoS, e.g., performing MTS based on the specific QoS requirements from the app.).
Salkintvis and Zhu are considered to be analogous to the claimed invention because they are in the same field of edge computing, network communication, and communication system implementation, dealing with techniques for implementing Multi-access Edge Computing (MEC) systems, Multiple Access Management Services (MAMS), and Fifth Generation (5G) Access Traffic Switching, Steering, and Splitting (ATSSS).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis to incorporate the teachings of Zhu on packet transmission, with a motivation for non-encapsulated packets, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Regarding claims 2, 9 and 13, Salkintzis in view of Gundavelli and Zhu teaches the apparatus of claim 1 and Salkintzis in view of Zhu teaches the apparatus of claims 8 and 11 respectively,
Salkintvis further teaches the IP address is assigned as a cellular IP address (Fig. 1, Para. [0044]-Salkintzis discloses the 5G-RAN 115 may be composed of a 3GPP access network 120 containing at least one cellular base unit 121 and/or a non-3GPP access network 130 containing at least one access point 131. Para. [0050]-Salkintzis discloses the remote units 105 may communicate directly with one or more of the cellular base units 121 in the 3GPP access network 120 via uplink (“UL”) and downlink (“DL”) communication signals).
Regarding claim 3, Salkintzis in view of Gundavelli and Zhu teaches the apparatus of claim 2,
Salkintvis fails to teach the IP address is an IP3 address.
However, Gundavelli teaches the IP address is an IP3 address (Para. [0013]-Gundavelli discloses 3GPP Release 16 (R16) of Technical Specification (TS) 23.501 Section 5.32.6.3.1, have defined integration architectures that provide for utilizing Access Traffic Steering, Switching, and Splitting Low-Layer (ATSSS-LL) policies between a user equipment (UE) and a networks for 3GPP access networks and non-3GPP access networks … the IP addresses that are obtained for a client for a given access (e.g., WLA access and WWA access) are both used for multipath, such as with Multipath Transmission Control Protocol (MPTCP) flows ... for ATSSS-LL one common IP address (e.g., IP-3) is used and packets to IP-3 can be routed on both WLA and WWA access paths, such as for non-MPTCP flows, which may include TCP, User Datagram Protocol (UDP) and Ethernet flows).
Gundavelli is considered to be analogous because it is in the same field of communication network equipment and services, dealing with Access Traffic Steering, Switching, and Splitting Low-Layer (ATSSS-LL) policies to an enterprise network.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis in view of Zhu to incorporate the teachings of Gundavelli on ATSSS, with a motivation for IP3 address, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Regarding claim 4, Salkintzis in view of Gundavelli and Zhu teaches the apparatus of claim 1,
Salkintvis fails to teach the first packet indicates a first source port in the first header, wherein the second packet indicates a second source port in the second header, and wherein the first source port is different from the second source port.
However, Gundavelli teaches the first packet indicates a first source port in the first header (Para. [0126]-Gundavelli discloses packet is a formatted unit of data that can contain control or routing information (e.g., source and destination address, source and destination port, etc.) and data, which is also sometimes referred to as a ‘payload’, ‘data payload’, and variations thereof),
the second packet indicates a second source port in the second header (Para. [0126]-Gundavelli discloses packet is a formatted unit of data that can contain control or routing information (e.g., source and destination address, source and destination port, etc.) and data, which is also sometimes referred to as a ‘payload’, ‘data payload’, and variations thereof), and
the first source port is different from the second source port (Para. [0057]-Gundavelli discloses SDFs for different traffic may be identified based on Traffic Flow Templates (TFTs), which may utilize any combination of IP address information (e.g., source, destination address), UDP port numbers. Para. [0126]-Gundavelli discloses packet is a formatted unit of data that can contain control or routing information (e.g., source and destination address, source and destination port, etc.) and data, which is also sometimes referred to as a ‘payload’, ‘data payload’, and variations thereof).
Gundavelli is considered to be analogous because it is in the same field of communication network equipment and services, dealing with Access Traffic Steering, Switching, and Splitting Low-Layer (ATSSS-LL) policies to an enterprise network.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis in view of Zhu to incorporate the teachings of Gundavelli on ATSSS, with a motivation for different source ports, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Regarding claims 5 and 14, Salkintzis in view of Gundavelli and Zhu teaches the apparatus of claim 1 and Salkintzis in view of Zhu teaches the apparatus of claim 11 respectively,
Salkintvis further teaches the first link is a cellular link and the second link is a non-cellular link or a secondary cellular link (Fig. 1, Para. [0044]-Salkintzis discloses the 5G-RAN 115 may be composed of a 3GPP access network 120 containing at least one cellular base unit 121 and/or a non-3GPP access network 130 containing at least one access point 131. Para. [0050]-Salkintzis discloses the remote units 105 may communicate directly with one or more of the cellular base units 121 in the 3GPP access network 120 via uplink (“UL”) and downlink (“DL”) communication signals).
Regarding claims 6 and 15, Salkintzis in view of Gundavelli and Zhu teaches the apparatus of claim 1 and Salkintzis in view of Zhu teaches the apparatus of claim 11 respectively,
Salkintvis further teaches to receive the configuration, the one or more processors are individually or collectively configured to cause the UE to receive the configuration in a non-access stratum (NAS) policy message with steering functionality (Para. [0134]-Salkintzis discloses below the MPQUIC steering functionality is the UDP/IP layer 607 and lower layers, e.g., Layer-3, Layer-2, and Layer-1. Note that at the UE 201 there may be separate protocol stacks for the 3GPP access network (e.g., containing Non-Access Stratum).
Regarding claims 7 and 18, Salkintzis in view of Gundavelli and Zhu teaches the apparatus of claim 1 and Salkintzis in view of Zhu teaches the apparatus of claim 11,
Salkintvis fails to explicitly teach a first source port, and a second source port.
However, Gundavelli teaches the one or more processors are individually or collectively configured to cause the UE to receive information that indicates the IP address, a first source port, and a second source port in association with setting up the first link and the second link (Para. [0013]-Gundavelli discloses for ATSSS-LL one common IP address (e.g., IP-3) is used and packets to IP-3 can be routed on both WLA and WWA access paths, such as for non-MPTCP flows, which may include TCP, User Datagram Protocol (UDP) and Ethernet flows. Para. [0064]-Gundavelli discloses an ATSSS-LL rule could be configured to indicate that duplicate UL/DL packets are to be transmitted over two different access network connections, which may include two different RAT types or two different APs for a same RAT type (e.g., for dual connectivity capable UEs). Para. [0056]-Gundavelli discloses UE 102 may apply the ATSSS-LL rules on UL traffic for sending packets to the enterprise network 104 utilizing an appropriate access network(s). Para. [0126]-Gundavelli discloses packet is a formatted unit of data that can contain control or routing information (e.g., source and destination address, source and destination port, etc.) and data, which is also sometimes referred to as a ‘payload’, ‘data payload’, and variations thereof).
Gundavelli is considered to be analogous because it is in the same field of communication network equipment and services, dealing with Access Traffic Steering, Switching, and Splitting Low-Layer (ATSSS-LL) policies to an enterprise network.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis in view of Zhu to incorporate the teachings of Gundavelli on ATSSS, with a motivation for first and second source/destination ports, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Regarding claim 16, Salkintzis in view of Zhu teaches the apparatus of claim 11,
Salkintvis further teaches the one or more processors are individually or collectively configured to cause the network entity to: receive a third packet with the first IP address as a destination IP address in a third header of the third packet (Para. [0065]-Salkintzis discloses the UPF(s) 141 is/are responsible for packet routing and forwarding. Fig. 1, Para. [0144]-Salkintzis discloses the remote unit communicates with the 3GPP access 20) network 120 using 3GPP communication links 123 and communicates with the non-3GPP access network 130 using non-3GPP communication links 133. Para. [0116]-Salkintzis discloses each UDP packet 417 contains an IP header, a UDP header and a corresponding UDP payload. The source IP address is set to the UE's MA PDU Session address, the destination IP address is set to the remote host's address, and the destination UDP port is set to the remote host's port) and
an associated fourth packet with the first IP address as the destination IP address in a fourth header of the fourth packet (Para. [0065]-Salkintzis discloses the UPF(s) 141 is/are responsible for packet routing and forwarding. Fig. 1, Para. [0144]-Salkintzis discloses the remote unit communicates with the 3GPP access 20) network 120 using 3GPP communication links 123 and communicates with the non-3GPP access network 130 using non-3GPP communication links 133. Para. [0116]-Salkintzis discloses each UDP packet 417 contains an IP header, a UDP header and a corresponding UDP payload. The source IP address is set to the UE's MA PDU Session address, the destination IP address is set to the remote host's address, and the destination UDP port is set to the remote host's port),
the third packet indicates a first destination port in the third header (Para. [0116]-Salkintvis discloses each UDP packet 417 contains an IP header, a UDP header and a corresponding UDP payload. The source IP address is set to the UE's MA PDU Session address, the destination IP address is set to the remote host's address, and the destination UDP port is set to the remote host's port) and
the fourth packet indicates the first destination port in the fourth header (Para. [0116]-Salkintvis discloses each UDP packet 417 contains an IP header, a UDP header and a corresponding UDP payload. The source IP address is set to the UE's MA PDU Session address, the destination IP address is set to the remote host's address, and the destination UDP port is set to the remote host's port);
forward the third packet on the first link (Para. [0065]-Salkintzis discloses the UPF(s) 141 is/are responsible for packet routing and forwarding. Fig. 1, Para. [0144]-Salkintzis discloses the remote unit communicates with the 3GPP access 20) network 120 using 3GPP communication links 123 and communicates with the non-3GPP access network 130 using non-3GPP communication links 133. Para. [0116]-Salkintzis discloses each UDP packet 417 contains an IP header, a UDP header and a corresponding UDP payload. The source IP address is set to the UE's MA PDU Session address, the destination IP address is set to the remote host's address, and the destination UDP port is set to the remote host's port) and
the fourth packet on the second link (Para. [0065]-Salkintzis discloses the UPF(s) 141 is/are responsible for packet routing and forwarding. Fig. 1, Para. [0144]-Salkintzis discloses the remote unit communicates with the 3GPP access 20) network 120 using 3GPP communication links 123 and communicates with the non-3GPP access network 130 using non-3GPP communication links 133. Para. [0116]-Salkintzis discloses each UDP packet 417 contains an IP header, a UDP header and a corresponding UDP payload. The source IP address is set to the UE's MA PDU Session address, the destination IP address is set to the remote host's address, and the destination UDP port is set to the remote host's port).
Salkintvis fails to explicitly teaches change a port value of the fourth packet from the first destination port to a second destination port.
However, Yang teaches change a port value of the fourth packet from the first destination port to a second destination port (Para. [0053]-Yang discloses remapping one Internet Protocol (IP) address space into another IP address space by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. Network Address and Port Translation (NAPT) also includes modifying the source port in the transport header. Para. [0227]-Yang discloses NAT information indicates replacement information, e.g. comprised by an “IP Header Modification IE”, that contains an IPv4/IPv6 address and/or a Port number that can be used to replace the Source/Destination IPv4/IPv6 address respectively and the Source/Destination Port respectively in the IP data packets).
Yang is considered to be analogous because it is in the same field of communication network, dealing with Network Address translation (NAT) in communications networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis in view of Zhu to incorporate the teachings of Yang on port values, with a motivation to translate port values, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Salkintzis fails to explicitly teach neither the third packet nor the fourth packet is encapsulated in another packet with a different IP address.
However, Zhu teaches neither the third packet nor the fourth packet is encapsulated in another packet with a different IP address (Para. [0078]-Zhu discloses if the ATSSS-LL functionality 415 is used (e.g., the “Layer 3 approach”), the MA PDU session contains IP traffic of two interfaces over 3GPP access 310A and Non-3GPP access 310B with one common IP addresses (e.g., IP@3). Para. [0103]-Zhu discloses “Multi-Access Traffic Steering Request” message may include a data element, data field, IE, etc., for each of the following elements: a Traffic Steering REQ ID to uniquely identify this traffic steering request; IP Packet Filter Set to identify the IP flows that the requested traffic steering rule applies, and may include IP source (src)/destination (dst) addresses (addr), src/dst port, and protocol type (number). Para. [0303]-Zhu discloses steering the traffic over multiple access network connections of the one or more access network connections when the traffic includes duplicated packets for an application having high-reliability and low-latency requirements. Table 3, Para. [0114]-Zhu discloses sending duplicated (redundancy) packets over multiple access network connections for high-reliability and low-latency applications 4 = QoS, e.g., performing MTS based on the specific QoS requirements from the app.).
Salkintvis and Zhu are considered to be analogous to the claimed invention because they are in the same field of edge computing, network communication, and communication system implementation, dealing with techniques for implementing Multi-access Edge Computing (MEC) systems, Multiple Access Management Services (MAMS), and Fifth Generation (5G) Access Traffic Switching, Steering, and Splitting (ATSSS).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis to incorporate the teachings of Zhu on packet transmission, with a motivation for non-encapsulated packets, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Regarding claim 17, Salkintzis in view of Zhu teaches the apparatus of claim 11,
Salkintvis further teaches the network entity includes a user plane function entity (Fig. 1, Para. [0051]-Salkintzis discloses the mobile core network 140 then relays traffic between the remote unit 105 and the remote host 155 using the PDU session. The PDU session represents a logical connection between the remote unit 105 and the User Plane Function (“UPF”) 141).
Regarding claim 19, Salkintzis in view of Zhu teaches the apparatus of claim 11,
Salkintvis further teaches the first link is an ATSSS-MPTCP link and the second link is an ATSSS-MPTCP link (Para. [0038]-Salkintzis discloses two steering functionalities have been defined in 3GPP Technical Specification (“TS”) 23.501: (a) the Multi-Path TCP (“MPTCP”) steering functionality and (b) the ATSSS-Low Layer (“ATSSS-LL”) steering functionality), or
the first link is an ATSSS-MPQUIC link and the second link is an ATSSS-MPQUIC link (Fig. 2, Para. [0077-0081]-Salkintzis discloses UE 201 is configured with ATSSS rules for steering/routing uplink traffic to the UPF 203, ... UE 201 receives MPQUIC proxy information, i.e., one IP address of the UPF 203, one UDP port number, and the proxy type (e.g., “masque” or “connect-udp”). This MPQUIC proxy information is used by the UE 201 for establishing QUIC connections with the UPF 203, which operates as an MPQUIC proxy).
Claims 10 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Apostolis Salkintzis (US 20250202801 A1), hereinafter referenced as Salkintzis, in view of ZHU et al. (US 20240259857 A1), hereinafter referenced as Zhu, and further in view of Yang et al. (US 20220377043 A1), hereinafter referenced as Yang.
Regarding claim 10, Salkintzis in view of Zhu teaches the apparatus of claim 8,
Salkintvis further teaches the first packet indicates a first destination port in the first header (Para. [0116]-Salkintvis discloses each UDP packet 417 contains an IP header, a UDP header and a corresponding UDP payload. The source IP address is set to the UE's MA PDU Session address, the destination IP address is set to the remote host's address, and the destination UDP port is set to the remote host's port),
the second packet indicates a second destination port in the second header (Para. [0116]-Salkintvis discloses each UDP packet 417 contains an IP header, a UDP header and a corresponding UDP payload. The source IP address is set to the UE's MA PDU Session address, the destination IP address is set to the remote host's address, and the destination UDP port is set to the remote host's port).
Salkintvis fails to explicitly teaches the one or more processors are individually or collectively configured to cause the UE to change a port value in the second packet from the second destination port to the first destination port.
However, Yang teaches the one or more processors are individually or collectively configured to cause the UE to change a port value in the second packet from the second destination port to the first destination port (Para. [0053]-Yang discloses remapping one Internet Protocol (IP) address space into another IP address space by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. Network Address and Port Translation (NAPT) also includes modifying the source port in the transport header. Para. [0227]-Yang discloses NAT information indicates replacement information, e.g. comprised by an “IP Header Modification IE”, that contains an IPv4/IPv6 address and/or a Port number that can be used to replace the Source/Destination IPv4/IPv6 address respectively and the Source/Destination Port respectively in the IP data packets).
Yang is considered to be analogous because it is in the same field of communication network, dealing with Network Address translation (NAT) in communications networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis in view of Zhu to incorporate the teachings of Yang on port values, with a motivation to translate port values, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Regarding claim 12, Salkintzis in view of Zhu teaches the apparatus of claim 11,
Salkintvis further teaches forward the first packet and the second packet (Para. [0065]-Salkintzis discloses the UPF(s) 141 is/are responsible for packet routing and forwarding. Fig. 1, Para. [0144]-Salkintzis discloses the remote unit communicates with the 3GPP access 20) network 120 using 3GPP communication links 123 and communicates with the non-3GPP access network 130 using non-3GPP communication links 133).
Salkintvis fails to explicitly teach the first packet indicates a first source port in the first header and the second packet indicates a second source port in the second header.
However, Zhu teaches the first packet indicates a first source port in the first header (Table 11, Para. [0164]-Zhu discloses the IP Packet Filter Set may be based on at least any combination of: Source/destination IP address or IPv6 prefix; source/destination port number) and
the second packet indicates a second source port in the second header (Table 11, Para. [0164]-Zhu discloses the IP Packet Filter Set may be based on at least any combination of: Source/destination IP address or IPv6 prefix; source/destination port number).
Zhu is considered to be analogous because it is in the same field of edge computing, network communication, and communication system implementation, dealing with techniques for implementing Multi-access Edge Computing (MEC) systems, Multiple Access Management Services (MAMS), and Fifth Generation (5G) Access Traffic Switching, Steering, and Splitting (ATSSS).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis to incorporate the teachings of Zhu on network ports, with a motivation for source ports indication, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Salkintvis fails to explicitly teaches the one or more processors are individually or collectively configured to cause the network entity to: change a port value of the second packet from the second source port to the first source port.
However, Yang teaches the one or more processors are individually or collectively configured to cause the network entity to: change a port value of the second packet from the second source port to the first source port (Para. [0053]-Yang discloses remapping one Internet Protocol (IP) address space into another IP address space by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. Network Address and Port Translation (NAPT) also includes modifying the source port in the transport header. Para. [0227]-Yang discloses NAT information indicates replacement information, e.g. comprised by an “IP Header Modification IE”, that contains an IPv4/IPv6 address and/or a Port number that can be used to replace the Source/Destination IPv4/IPv6 address respectively and the Source/Destination Port respectively in the IP data packets).
Yang is considered to be analogous because it is in the same field of communication network, dealing with Network Address translation (NAT) in communications networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Salkintzis in view of Zhu to incorporate the teachings of Yang on port values, with a motivation to translate port values, and guarantee establishment of a multiaccess protocol data unit (“MA PDU)” session between a UE and a UPF, and policy-controlled routing of data traffic over different access networks, (Salkintzis, Para. [0002]).
Conclusion
Listed below are the prior arts made of record and not relied upon but are considered pertinent to applicant`s disclosure.
ZHOU et al. (US 20220353788 A1)-discloses Fig. 9, Para. [0078-0083]-Zhou discloses an AF (e.g., MEC AF) creates an AF request about multi-access traffic steering requirements for one or more user devices. The one or more user devices can be one or more UEs or one or more groups of UEs. The request can include application traffic descriptor(s) and steering functionality information. The steering functionality information can include the following: [0080] (1) MPTCP server information, such as Fully Qualified Domain Name (FQDN), IP address, and/or port number; [0081] (2) MPTCP proxy information, such as MPTCP proxy IP address; [0082] (3) MP-QUIC server information, such as FQDN, IP address, and/or port number; [0083] (4) ATSSS-LL functionality. Para. [0093]-Zhou discloses the PCF then sends the response message to AF via the NEF…. …Fig. 1-9
Alasti et al. (US 20240056938 A1)-discloses [0064] Referring now to FIG. 5, an embodiment of 5G ATSSS Architecture is shown. As displayed in FIG. 5, User Equipment (UE) 502 includes Multipath Transmission Control Protocol (MP-TCP) functionality 504 and ATSSS-LL functionality 506. [0069] In one such example, the Traffic Descriptor is UDP, DestAddr A.B.C.D., and the Steering Mode is Active-Standby, Active=3GPP CBRS 5G, Standby=non-3GPP Wi-Fi. In such an embodiment, UDP traffic with destination IP address A.B.C.D. is steered to the active access (e.g., 3GPP CBRS 5G), if available.…. …Fig. 1-2
SU et al. (US 20250097131 A1)-discloses system and method for quality of experience (QoE)-aware transmission over multi-transport is disclosed. The system receives requests for transmitting data packets from source node to destination node in wireless communication network. Further, the system determines payload data of the data packet and n-tuple information associated with the data packet. Furthermore, the system analyzes packet level metrics associated with determined payload data of data packet. Additionally, system classifies data packets into a latency class (LC) and a Quality of Service (QoS) class based on the analyzed packet level metrics. Further, the system determines connection identifier (ID) associated with data packet. Further, the system determines appropriate multi-transport access network (MTAN) among plurality of MTANs for transmitting data packet to destination node. Furthermore, the system establishes multi-path (MP) backbone connection with destination node using determined appropriate MTAN. Additionally, the system transmits data packet to destination node through established MP backbone connection.… …Fig. 1-5
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLADIRAN GIDEON OLALEYE whose telephone number is (571)272-5377. The examiner can normally be reached Monday - Friday: 07:30am - 05:30pm.
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 SPE, NICHOLAS A. JENSEN can be reached on (571) 270-5443. 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.
/OO/
Examiner, Art Unit 2472
/NICHOLAS A JENSEN/Supervisory Patent Examiner, Art Unit 2472