Office Action Predictor
Last updated: April 16, 2026
Application No. 17/903,245

COMMUNICATION METHOD AND APPARATUS

Final Rejection §103
Filed
Sep 06, 2022
Examiner
LOUIS, VINNCELAS
Art Unit
2474
Tech Center
2400 — Computer Networks
Assignee
Huawei Technologies Co., LTD.
OA Round
4 (Final)
80%
Grant Probability
Favorable
5-6
OA Rounds
2y 12m
To Grant
99%
With Interview

Examiner Intelligence

Grants 80% — above average
80%
Career Allow Rate
535 granted / 668 resolved
+22.1% vs TC avg
Strong +42% interview lift
Without
With
+42.1%
Interview Lift
resolved cases with interview
Typical timeline
2y 12m
Avg Prosecution
20 currently pending
Career history
688
Total Applications
across all art units

Statute-Specific Performance

§101
5.8%
-34.2% vs TC avg
§103
53.5%
+13.5% vs TC avg
§102
24.1%
-15.9% vs TC avg
§112
5.8%
-34.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 668 resolved cases

Office Action

§103
DETAILED ACTION Continued Examination Under 37 CFR 1.114 The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . The instant first office action is in response to communication filed on 12/17/2025. Claims 1-2, 4, 6-10, 12-17 and 19-20 are pending of which claims 1, 9 and 16 are the base independent claims. Response to Arguments Applicant’s arguments with respect to claim(s) 1-2, 4, 6-10, 12-17 and 19-20 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. Further, the amended limitations are in fact taught by the previously cited prior art. For a detailed explanation on how the prior art reads on the claims as amended, please see the rejection below. Allowable Subject Matter Claim 7 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 1, 6, 8-9, 15-16 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang (US 2020/0245405), in view of 3GPP (3GPP TR 23.793 V1.2.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspect; Technical Specification Group Services and System Aspect; Study on Access Traffic Steering, Switching and Splitting Support in the 5G System architecture (Release 16)) ) and in view of Rasmos-Escano et al (US 2005/0117529). Regarding claim 1, 9, 16, Tang’405 discloses a communication method, comprising: receiving, by a session management function (SMF) network element, a first message from a terminal device(see fig.15, which shows SMF receives establishment/modification request of a first PDU session, see fig.16, 11 & see para.0303), wherein the first message is used to request to establish or(due to or language, only one of them is being considered) update a protocol data unit (PDU) session(see fig.16 & para.0303, which discusses where the first request message is used to apply to perform session establishment of N data flows in a first protocol data unit PDU session); determining, by the SMF network element, that a plurality of traffic flows in the PDU session(see fig.15, S9002, see para.0073, which discusses triggering, by the SMF device according to the first request message, an access network device to perform session establishment of the N data flows in the first PDU session; and receiving, by the SMF device, a data flow list that corresponds to the first PDU session and that is sent by the access network device, where the data flow list includes the M data flows or (N-M) data flows of the N data flows received by the first PDU session, see para.0281, 0310) shares a same connection (see para.0073, which discusses triggering, by the SMF device according to the first request message, an access network device to perform session establishment of the N data flows in the first PDU session; and receiving, by the SMF device, a data flow list that corresponds to the first PDU session and that is sent by the access network device, where the data flow list includes the M data flows or (N-M) data flows of the N data flows received by the first PDU session, see para.0281, 0310, thus N data flows in the first PDU session indicative of N data flows sharing the PDU session connection); and sending, by the SMF network element, a second message to the terminal device(see fig.16, which shows SMF sends a response to the terminal device, see para.0287), wherein the second message is used to indicate that the PDU session is successfully established or(due to or language, only one of them is being considered) updated(see para.0287, which discusses the network device may further indicate, to the terminal device through the response message, data flows that are refused by the network side. For example, a data flow list accepted by the network device may be carried in the response message, and the terminal device may further determine, according to the accepted data flow list, data flows that are refused. Alternatively, the data flow list refused by the network device may be directly carried in the response message. The data flow list may include identifiers of a plurality of data flows, thus data flow list accepted by the network device may be carried in the response message is indicative of PDU session is successfully established). As discussed above, although Tang’405 discloses SMF receives a request from the UE and transmits a response (see at least fig.3-4, 14-16, 18-19), Tang’405 does not explicitly show the use of “a multi-path quick user datagram protocol (UDP) internet connection (MP-QUIC), and the second message comprises a multi-flow connection parameter, and the multi-flow connection parameter is used to indicate that the plurality of traffic flows in the PDU session are transmitted by using the same connection, the traffic flow description parameter comprises at least one of the following: one or more pieces of traffic flow description information, an application identifier, one or more quality of service (QoS) flow identifiers, QoS flow IDs, QFIs, one or more PDU session identifiers, and a terminal device identifier” as required by present claimed invention. However, including “a multi-path quick user datagram protocol (UDP) internet connection (MP-QUIC), and the second message comprises a multi-flow connection parameter, and the multi-flow connection parameter is used to indicate that the plurality of traffic flows in the PDU session are transmitted by using the same connection, the traffic flow description parameter comprises at least one of the following: one or more pieces of traffic flow description information, an application identifier, one or more quality of service (QoS) flow identifiers, QoS flow IDs, QFIs, one or more PDU session identifiers, and a terminal device identifier” would have been obvious to one having ordinary skill in the art as evidenced by 3GPP’793. In particular, in the same field of endeavor, 3GPP’793 teaches the use of wherein the connection shared by the plurality of traffic flows is a multi-path quick user datagram protocol (UDP) internet connection (MP-QUIC) (see page 26 & 6.1.7.4, which discusses the L4 multipath transport service may use either MPTCP, QUIC, MP-QUIC, SCTP or UDP generic. MP-TCP sets up multiple TCP subflows over the different access networks, MP-QUIC several UDP flows, QUIC several UDP flows, SCTP several SCTP flows and the UDP generic approach several UDP flows… one or more IP addresses may be allocated….to differentiate between flows over both access, see page 29-page 33, see fig.6.1.7.4.3.1.1-1: SCTP, see 6.3.1, NON MTCP flows vs MTCP flows, see page 41 & 6.2.3.3, figure 6.2.3.1-1, thus determine connection shared by flows is MP-QUIC) and the second message comprises a multi-flow connection parameter(see page 39 & 6-9, which discusses the SMF sends a PDU Session Establishment Accept message with a MA-PDU Capability flag as multi-flow connection parameter to inform the UE that the network can support MA-PDU procedures for this PDU session. Otherwise, the SMF may accept the PDU Session establishment but does not include the MA-PDU Capability flag in the PDU Session Establishment Accept message) is used to indicate that the plurality of traffic flows in the PDU session are transmitted(see page 38-39 & 6-9, which discusses if the MA-PDU Capability flag is received by the UE, the UE may later add another child PDU session to the existing PDU session with the steps below, see page 14 & 6.1.1, see figure 6.1.1-1 & 6.2.1, which discusses a Multi-Access PDU (MA-PDU) session is created by bundling together two separate PDU sessions, which are established over different accesses) by using the same connection(see page 26 & 6.1.7.4, which discusses the L4 multipath transport service may use either MPTCP, QUIC, MP-QUIC, SCTP or UDP generic. MP-TCP sets up multiple TCP subflows over the different access networks, MP-QUIC several UDP flows, QUIC several UDP flows, SCTP several SCTP flows and the UDP generic approach several UDP flows, see page 26-33, see page 41 & 6.2.3.3), the traffic flow description parameter(see page 110, which discusses A Traffic Descriptor, which identifies a service data flow (SDF)) comprises at least one(due to at least one, only one of them is being considered) of the following: one or more pieces of traffic flow description information, an application identifier, one or more quality of service (QoS) flow identifiers, QoS flow IDs, QFIs, one or more PDU session identifiers, and a terminal device identifier(see page 110, which discusses a Traffic Descriptor, which identifies a service data flow (SDF). It may include e.g. an Application ID, IP descriptors (Destination Address, Destination Port and Destination FQDN), non-IP descriptors, etc.). In view of the above, having the system of Tang’405 and then given the well-established teaching of 3GPP’793, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Tang’405 to include “a multi-path quick user datagram protocol (UDP) internet connection (MP-QUIC), and the second message comprises a multi-flow connection parameter, and the multi-flow connection parameter is used to indicate that the plurality of traffic flows in the PDU session are transmitted by using the same connection” as taught by 3GPP’793, since 3GPP’793 stated in page 9+ that such a modification would provide an efficient system with access traffic steering is applicable between 3GPP and non-3GPP accesses and access traffic splitting is applicable between 3GPP and non- 3GPP accesses. Although the combination of Tang’405 and 3GPP’793 discloses multi-flow connection parameter(3GPP’793, see page 39 & 6-9, which discusses the SMF sends a PDU Session Establishment Accept message with a MA-PDU Capability flag as multi-flow connection parameter to inform the UE that the network can support MA-PDU procedures for this PDU session. Otherwise, the SMF may accept the PDU Session establishment but does not include the MA-PDU Capability flag in the PDU Session Establishment Accept message), the combination of Tang’405 and 3GPP’793 does not explicitly show the use of “the multi-flow connection parameter comprises a traffic flow description parameter and a multi-flow multiplexing parameter, wherein the multi-flow multiplexing parameter comprises at least one of the following: protocol indication information, multi-flow multiplexing indication information, a connection identifier, QoS flow granularity indication information, PDU session granularity indication information, and terminal device granularity indication information” as required by present claimed invention. However, including “he multi-flow connection parameter comprises a traffic flow description parameter and a multi-flow multiplexing parameter, wherein the multi-flow multiplexing parameter comprises at least one of the following: protocol indication information, multi-flow multiplexing indication information, a connection identifier, QoS flow granularity indication information, PDU session granularity indication information, and terminal device granularity indication information” would have been obvious to one having ordinary skill in the art as evidenced by Rasmos-Escano’529. In particular, in the same field of endeavor, Rasmos-Escano’529 teaches the use of the multi-flow connection parameter comprises a traffic flow description parameter and a multi-flow multiplexing parameter(see para.0013, which discusses a data frame is sent to the second endpoint, the data frame comprising the selected transport connection identifier as multi-flow multiplexing parameter, destination application information as traffic flow description parameter and/or data type information), wherein the traffic flow description parameter (see para.0013, which discusses a data frame is sent to the second endpoint, the data frame comprising the selected transport connection identifier as multi-flow multiplexing parameter, destination application information as traffic flow description parameter and/or data type information) comprises at least one of the following: one or(due to at least one, only of them is being considered) more pieces of traffic flow description information, an application identifier, one or more quality of service (QoS) flow identifiers, QoS flow IDs, QFIs, one or more PDU session identifiers, and a terminal device identifier(see para.0013, which discusses a data frame is sent to the second endpoint, the data frame comprising the selected transport connection identifier as multi-flow multiplexing parameter, destination application information as application identifier and/or data type information, see para.0015-0016, which discusses the value of the Protocol Payload Identifier (PPI) parameter identifies the destination application and the type of the data (connection-oriented or connectionless), see para.0063); the multi-flow multiplexing parameter(see para.0013, which discusses a data frame is sent to the second endpoint, the data frame comprising the selected transport connection identifier as multi-flow multiplexing parameter, destination application information as traffic flow description parameter and/or data type information) comprises at least one(due to at least one, only of them is being considered) of the following: protocol indication information, multi-flow multiplexing indication information, a connection identifier, QoS flow granularity indication information, PDU session granularity indication information, and terminal device granularity indication information(see para.0013, see para.0014, which discusses the connection identifier refers to the SCTP as protocol indication information streamID). In view of the above, having the combined system of Tang’405 and 3GPP’793 and then given the well-established teaching of Rasmos-Escano’529, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the combined system of Tang’405 and 3GPP’793 to include “the multi-flow connection parameter comprises a traffic flow description parameter and a multi-flow multiplexing parameter, wherein the multi-flow multiplexing parameter comprises at least one of the following: protocol indication information, multi-flow multiplexing indication information, a connection identifier, QoS flow granularity indication information, PDU session granularity indication information, and terminal device granularity indication information” as taught by Rasmos-Escano’529, since Rasmos-Escano’529 stated in para.0021+ that such a modification would reduce the complexity (implementation and operational) and also the processing requirement of the signalling bearer and reduce the delay for the set up and release of the connections. Regarding clam 6 and 19, as discussed above, although Tang’405 discloses SMF receives a request from the UE and transmits a response (see at least fig.3-4, 14-16, 18-19), Tang’405 does not explicitly show the use of “sending, by the SMF network element, the multi-flow connection parameter to the user plane function (UPF) network element” as required by present claimed invention. However, including “sending, by the SMF network element, the multi-flow connection parameter to the user plane function (UPF) network element” would have been obvious to one having ordinary skill in the art as evidenced by 3GPP’793. In particular, in the same field of endeavor, 3GPP’793 teaches the use of sending, by the SMF network element, the multi-flow connection parameter to the user plane function (UPF) network element(see figure 6.2.3.1-1, which shows SMF sends MA-PDU flag to UPF network 5, see page 39, which discusses the SMF sends an MA-PDU Capability flag as multi-flow connection parameter to PCF when it performs Session Management Policy Establishment procedure). In view of the above, having the system of Tang’405 and then given the well-established teaching of 3GPP’793, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Tang’405 to include “sending, by the SMF network element, the multi-flow connection parameter to the user plane function (UPF )network element” as taught by 3GPP’793, since 3GPP’793 stated in page 9+ that such a modification would provide an efficient system with access traffic steering is applicable between 3GPP and non-3GPP accesses and access traffic splitting is applicable between 3GPP and non- 3GPP accesses. Regarding clam 8 and 15, as discussed above, although Tang’405 discloses SMF receives a request from the UE and transmits a response (see at least fig.3-4, 14-16, 18-19), Tang’405 does not explicitly show the use of “sending, by the SMF network element, encryption and/or integrity protection indication information to at least one of a user plane function (UPF) network element and the terminal device” as required by present claimed invention. However, including “sending, by the SMF network element, encryption and/or integrity protection indication information to at least one of a user plane function (UPF) network element and the terminal device” would have been obvious to one having ordinary skill in the art as evidenced by 3GPP’793. In particular, in the same field of endeavor, 3GPP’793 teaches the use of sending, by the SMF network element, encryption and/or integrity protection indication information to the UPF network element and/or(due to or language, only one of them is being considered) the terminal device(see page 37, which discusses SMF provides a "linked PDU session" identity to UPF so that the UPF links this PDU session with the one established in step 6. The UPF considers both PDU sessions as part of the same MA-PDU session. The SMF also provides ATSSS forwarding rules to UPF that indicate how downlink traffic should be routed across the two child PDU sessions. The ATSSS forwarding rules are derived based on the Multi- Access PCC rules provided by PCF, see page 43, which discusses the SMF derives (a) ATSSS rules, which will be sent to UE for controlling the traffic steering, switching and splitting in the uplink direction, and (b) N4 rules, which will be sent to UPF for controlling the traffic steering, switching and splitting in the downlink direction, see page 80, which discusses ATSSS policies may also contain information about the splitting/switching method for the data flow: An indication on the allowed Convergence Method (e.g. Null Aggregation, GRE Aggregation, MP-TCP Proxy, MP-QUIC Proxy, etc) and the associated Convergence Method Parameters,, the Transport Method (e.g. UDP tunnel, IPSec Tunnel with NULL encryption, etc.),, thus SMF Sends ATSSS rules/policies includes encryption and/or GRE/MPTCP/MP-QUIC indication as integrity protection indication information to UPF). In view of the above, having the system of Tang’405 and then given the well-established teaching of 3GPP’793, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Tang’405 to include “sending, by the SMF network element, encryption and/or integrity protection indication information to the UPF network element and/or the terminal device” as taught by 3GPP’793, since 3GPP’793 stated in page 9+ that such a modification would provide an efficient system with access traffic steering is applicable between 3GPP and non-3GPP accesses and access traffic splitting is applicable between 3GPP and non- 3GPP accesses. Regarding claim 20, Tang’405 discloses wherein determining, by the SMF network element, that the plurality of traffic flows in the PDU session share the same connection further comprises: when the plurality of traffic flows in the PDU session are non-guaranteed bit rate non-GBR traffic flows, determining, by the SMF network element, that the plurality of traffic flows share the same connection; or (see page 15, which discusses the PDU session and the linked PDU session of a MA PDU share the following attributes: DNN, SSC mode, S-NSSAI, PDU session type (IPV4, IPV6 or Ethenet), IP address (for IPV4 and IPV6 PDU session type, see page 53, which discusses QoS Rule 1 and Rule 2 are applicable for GBR or non GBR flow. QoS Rule 3 is only applicable for non GBR flow. For the QoS Rule 3, see page 56, which discusses the UE or the UPF may trigger the traffic splitting per packet for non-GBR service when the RTT on both accesses are on the same level, see page 109, which discusses Non-GBR QoS Flow and GBR QoS Flow are supported in MA-PDU session, thus when the plurality of traffic flows in the PDU session are non-guaranteed bit rate). Claim(s) 2, 4, 10, 12-13 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang (US 2020/0245405) and in view of 3GPP (3GPP TR 23.793 V1.2.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspect; Technical Specification Group Services and System Aspect; Study on Access Traffic Steering, Switching and Splitting Support in the 5G System architecture (Release 16)) ), in view of Rasmos-Escano et al (US 2005/0117529) and further in view of Zhou et al (US 2022/0353788). Regarding claims 2, 10, 17, as discussed above, the combination of Tang’405, 3GPP’793 and Rasmos-Escano’529 discloses the multi-flow multiplexing parameter(see para.0013, which discusses a data frame is sent to the second endpoint, the data frame comprising the selected transport connection identifier as multi-flow multiplexing parameter, destination application information as traffic flow description parameter and/or data type information, see para.0014, which discusses the connection identifier refers to the SCTP as protocol indication information streamID), the combination of Tang’405, 3GPP’793 and Rasmos-Escano’529 does not explicitly show the use of “the multi-flow multiplexing parameter is used to indicate MP-QUIC information or MP-QUIC aggregated stream connection information” as required by present claimed invention. However, including “the multi-flow multiplexing parameter is used to indicate MP-QUIC information or MP-QUIC aggregated stream connection information” would have been obvious to one having ordinary skill in the art as evidenced by Zhou’788. In particular, in the same field of endeavor, Zhou’788 teaches the use of the multi-flow multiplexing parameter(see para.0079, which discusses the request can include application traffic descriptor(s) as traffic flow description parameter and steering functionality information as multi-flow multiplexing parameter) is used to indicate MP-QUIC information or(due to or language, only one of them is being considered) MP-QUIC aggregated stream connection information(see para.0079-0082, which discusses steering functionality information as multi-flow multiplexing parameter includes MP-QUIC server information, see para.0089 & 0049, which discusses the one or more parameters comprise server information of Multipath Transmission Control Protocol or Multipath QUIC). In view of the above, having the combined system of Tang’405, 3GPP’793 and Rasmos-Escano’529 and then given the well-established teaching of 3GPP’793, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the combined system of Tang’405, 3GPP’793 and Rasmos-Escano’529 to include “the multi-flow multiplexing parameter is used to indicate MP-QUIC information or MP-QUIC aggregated stream connection information” as taught by Zhou’788, since Zhou’788 stated in para.0003+ that such a modification would provide techniques, including new ways to provide higher quality of service, longer battery life, and improved performance. Regarding claims 4 and 12, as discussed above, the combination of Tang’405, 3GPP’793 and Rasmos-Escano’529 discloses the multi-flow multiplexing parameter(see para.0013, which discusses a data frame is sent to the second endpoint, the data frame comprising the selected transport connection identifier as multi-flow multiplexing parameter, destination application information as traffic flow description parameter and/or data type information, see para.0014, which discusses the connection identifier refers to the SCTP as protocol indication information streamID), the combination of Tang’405, 3GPP’793 and Rasmos-Escano’529 does not explicitly show the use of “wherein the multi-flow multiplexing parameter further comprises MP-QUIC method indication information, wherein the MP-QUIC method indication is used to indicate that the traffic flow is transmitted by using the MP-QUIC” as required by present claimed invention. However, including “wherein the multi-flow multiplexing parameter further comprises MP-QUIC method indication information, wherein the MP-QUIC method indication is used to indicate that the traffic flow is transmitted by using the MP-QUIC” would have been obvious to one having ordinary skill in the art as evidenced by Zhou’788. In particular, in the same field of endeavor, Zhou’788 teaches the use of the multi-flow multiplexing parameter(see para.0079, which discusses the request can include application traffic descriptor(s) as traffic flow description parameter and steering functionality information as multi-flow multiplexing parameter) further comprises MP-QUIC method indication information(see para.0084, which discusses the steering functionality information can also include information about the steering mode as MP-QUIC method indication information), wherein the MP-QUIC method indication is used to indicate that the traffic flow is transmitted by using the MP-QUIC(see para.0058, when one or more user devices indicate the multi-access traffic steering related capability (e.g. ATSSS-LL, MPTCP, MP-QUIC, etc, see para.0084-0089, which discusses he steering functionality information can also include information about the steering mode as MP-QUIC method indication information, including but is not limited to: (a) active-standby: the UE steers the traffic by using the active access if the active access is available. If the active access is not available and the standby access is available, the UE steers the traffic by using the standby access; (b) smallest delay: the UE steers the traffic by using the access network with the smallest round-trip-time (RTT);(c) load balancing: the UE steers the traffic across both the 3GPP access and the non-3GPP access with a given percentage; or (d) priority based: the UE steers the traffic over the access with high priority unless the access with high priority is congested, when the UE steers the SDF over both the access with high priority and the access with low priority, thus steer traffic flow using MP-QUIC). In view of the above, having the combined system of Tang’405, 3GPP’793 and Rasmos-Escano’529 and then given the well-established teaching of 3GPP’793, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the combined system of Tang’405, 3GPP’793 and Rasmos-Escano’529 to include “wherein the multi-flow multiplexing parameter further comprises MP-QUIC method indication information, wherein the MP-QUIC method indication is used to indicate that the traffic flow is transmitted by using the MP-QUIC” as taught by Zhou’788, since Zhou’788 stated in para.0003+ that such a modification would provide techniques, including new ways to provide higher quality of service, longer battery life, and improved performance. Regarding clam 13, as discussed above, although Tang’405 discloses SMF receives a request from the UE and transmits a response (see at least fig.3-4, 14-16, 18-19), Tang’405 does not explicitly show the use of “establishing, by the terminal device, the connection shared by a plurality of traffic flows of a user plane function UPF network element; and transmitting, by the terminal device, a first traffic flow by using the connection shared by the plurality of traffic flows” as required by present claimed invention. However, including “establishing, by the terminal device, the connection shared by a plurality of traffic flows of a user plane function UPF network element; and transmitting, by the terminal device, a first traffic flow by using the connection shared by the plurality of traffic flows” would have been obvious to one having ordinary skill in the art as evidenced by 3GPP’793. In particular, in the same field of endeavor, 3GPP’793 teaches the use of establishing, by the terminal device, the connection shared by a plurality of traffic flows of a user plane function UPF network element(see figure 6.1.1-1, which shows establishment MAPDU session connection shared by traffic flow PDU over 3GGP access and NON-3GPP of UPF, see page 26-33); and transmitting, by the terminal device, a first traffic flow by using the connection shared by the plurality of traffic flows(see figure 6.1.1-1, fig.6.2.1-1, child session # and child PDU session #2, see page 39, which discusses UE may later add another child PDU session to the existing PDU session, see page 31, see page 51, MTCP FLOWS and NON-MTCP FLOWS). In view of the above, having the system of Tang’405 and then given the well-established teaching of 3GPP’793, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Tang’405 to include “establishing, by the terminal device, the connection shared by a plurality of traffic flows of a user plane function UPF network element; and transmitting, by the terminal device, a first traffic flow by using the connection shared by the plurality of traffic flows” as taught by 3GPP’793, since 3GPP’793 stated in page 9+ that such a modification would provide an efficient system with access traffic steering is applicable between 3GPP and non-3GPP accesses and access traffic splitting is applicable between 3GPP and non- 3GPP accesses. Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang (US 2020/0245405) and in view of 3GPP (3GPP TR 23.793 V1.2.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspect; Technical Specification Group Services and System Aspect; Study on Access Traffic Steering, Switching and Splitting Support in the 5G System architecture (Release 16)) ), in view of Rasmos-Escano et al (US 2005/0117529), in view of Zhou et al (US 2022/0353788) and further in view of Zhu et al (US 2024/0259857). Regarding claim 14, the combined system of Tang’405, 3GPP’793, Rasmos-Escano’529 and Zhou’788 discloses when the second traffic flow is allowed to share the connection for transmitting the first traffic flow(see page 27 & see figure 6.1.7.4-1b, which shows when the traffic flow as second flow over Non-3GPP is allowed to share MP-QUIC connection for transmitting traffic flow as first traffic flow over 5G-AN protocol, see page 26 & see page 30), transmitting, by the terminal device, the second traffic flow by using the connection for transmitting the first traffic flow(see page 26 & see page 30, which discuses In this mode of operation MP-QUIC is used as a tunnelling transport between the UE-AT3SF as terminal device and UPu-AT3SF. This solution enables different flows (e.g. IP flows) to use multiple paths between UE-AT3SF and UPu-AT3SF, see page 27 & see figure 6.1.7.4-1b, shows traffic flow as first traffic flow over 5G-AN and traffic flow as second traffic over NON-3GPP between UE as terminal device and UPu-AT3SF). Regarding claim 14, although the combination of Tang’405 and 3GPP’793 further discloses wherein the multi-flow connection parameter comprises a traffic flow description parameter (3GPP’793, see 6.1.3 & see figure 6.1.3-1, A Traffic descriptor to be priority Y of App 2 includes in MAC PDU), the combination of Tang’405 and 3GPP’793 does not explicitly show the use of “determining, by the terminal device based on the multi-flow multiplexing parameter, whether a second traffic flow is allowed to share the connection for transmitting the first traffic flow; and when the second traffic flow is allowed to share the connection for transmitting the first traffic flow, transmitting, by the terminal device, the second traffic flow by using the connection for transmitting the first traffic flow” as required by present claimed invention. However, including “determining, by the terminal device based on the multi-flow multiplexing parameter, whether a second traffic flow is allowed to share the connection for transmitting the first traffic flow; and when the second traffic flow is allowed to share the connection for transmitting the first traffic flow, transmitting, by the terminal device, the second traffic flow by using the connection for transmitting the first traffic flow” would have been obvious to one having ordinary skill in the art as evidenced by Zhu’857. In particular, in the same field of endeavor, Zhu’857 teaches the use of : determining, by the terminal device based on the multi-flow multiplexing parameter, whether a second traffic flow is allowed to share the connection for transmitting the first traffic flow(see para.0101, which discusses the new “Multi-Access Traffic Steering Capability” message may include a Multi-Access Traffic Steering Mode data element as multi-flow multiplexing parameter , data field, IE, etc., which includes a list of supported Multi-Access Traffic Steering Modes (e.g., MPTCP, MPQUIC, MAMS, etc.). For each listed Multi-Access Traffic Steering mode, the Multi-Access Traffic Steering Capability message may include a data element, data field, IE, etc., for each of the following: a list of access networks that can be used for this mode; a Traffic Direction indicator to indicate the list of supported traffic steering modes is for downlink, uplink, or both; a list of supported dynamic multi-access traffic steering modes including, for example, lowest cost, lowest latency, maximum throughput mode #1, maximum throughput mode #2, and QoS-based; and a list of supported static multi-access traffic steering modes (e.g., the static multi-access traffic steering modes may include steering, splitting, and duplication), thus Multi-Access Traffic Steering Mode data element as multi-flow multiplexing parameter indicate (e.g., MPTCP, MPQUIC, MAMS, etc.) , see fig.4, which shows determine MTCP to share flows 420 associated with subflow 1 and 2); and when the second traffic flow is allowed to share the connection for transmitting the first traffic flow, transmitting, by the terminal device, the second traffic flow by using the connection for transmitting the first traffic flow(see fig.4, which shows transmitting Subflow to ip@2 over MTCP connection using the connection for transmitting the subflow @1). In view of the above, having the combined system of Tang’405 and 3GPP’793 and then given the well-established teaching of Zhu’857, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the combined system of Tang’405 and 3GPP’793 to include “determining, by the terminal device based on the multi-flow multiplexing parameter, whether a second traffic flow is allowed to share the connection for transmitting the first traffic flow; and when the second traffic flow is allowed to share the connection for transmitting the first traffic flow, transmitting, by the terminal device, the second traffic flow by using the connection for transmitting the first traffic flow” as taught by Zhu’857, since Zhu’857 stated in para.0026+ that such a modification would provide techniques to enable coexistence between MEC-based MAMS systems and 5G MA traffic steering mechanisms. 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. Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http://www.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03. Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINNCELAS LOUIS whose telephone number is (571)270-5138. The examiner can normally be reached 8:30-5:00 PM. 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, Michael Thier can be reached on 571-272-2832. 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. /VINNCELAS LOUIS/Primary Examiner, Art Unit 2474
Read full office action

Prosecution Timeline

Sep 06, 2022
Application Filed
Sep 16, 2022
Response after Non-Final Action
Nov 30, 2024
Non-Final Rejection — §103
Feb 27, 2025
Response Filed
Apr 19, 2025
Final Rejection — §103
Jul 23, 2025
Response after Non-Final Action
Aug 21, 2025
Request for Continued Examination
Aug 28, 2025
Response after Non-Final Action
Sep 15, 2025
Examiner Interview (Telephonic)
Sep 19, 2025
Non-Final Rejection — §103
Dec 17, 2025
Response Filed
Feb 04, 2026
Examiner Interview (Telephonic)
Feb 06, 2026
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12604363
SIDELINK COMMUNICATION METHOD AND COMMUNICATION DEVICE
2y 5m to grant Granted Apr 14, 2026
Patent 12587346
COMMUNICATION APPARATUS, CONTROL METHOD, AND COMPUTER-READABLE STORAGE MEDIUM
2y 5m to grant Granted Mar 24, 2026
Patent 12568520
ELECTRONIC DEVICE COMPRISING PLURALITY OF SUBSCRIBER IDENTIFICATION MODULES AND OPERATION METHOD OF SAME
2y 5m to grant Granted Mar 03, 2026
Patent 12563586
DETERMINING COLLISIONS AND CONFLICTS FOR SIDELINK COMMUNICATIONS
2y 5m to grant Granted Feb 24, 2026
Patent 12561258
WEIGHTING ROUTING
2y 5m to grant Granted Feb 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

5-6
Expected OA Rounds
80%
Grant Probability
99%
With Interview (+42.1%)
2y 12m
Median Time to Grant
High
PTA Risk
Based on 668 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in for Full Analysis

Enter your email to receive a magic link. No password needed.

Free tier: 3 strategy analyses per month