DETAILED ACTION
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 § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claim invention.
Claim(s) 1-20 is/are rejected under 3 5 U.S.C. 102(a)(2) as being disclosed by Fu et al (hereinafter Fu), US Patent Publication US 20250097761 A1 (continuation priority date June 2022)
As per claim{s} 1, 2, 3, 7, 10, 11, 13, 14, 20, Fu discloses substantial features of the claimed invention, such as a method, wherein the method comprises:
obtaining, by a communication device (Fu: e.g., ‘UE Terminal’ / ‘Base Station’ performing data processing on different pieces of first data corresponding to the same QoS flow) [0059-0061; Fig. 2], a data flow of a service used on a terminal (Fu: e.g., performing data processing on different pieces of first data corresponding to the same ‘QoS flow’) [Abstract, 0003, 0059-0061; Fig. 2], wherein the data flow comprises a first group of protocol data unit sets and a second group of protocol data unit sets (Fu: e.g., in some embodiments, different data processing operations is performed based on a ‘first set of PDUs’ and a ‘second set of PDUs’ corresponding to a first / same QoS flow) [0063-0064, 0625, 0769 & 0771-0772, also Claim 3 ; Figs. 5, 6 & 19];
determining, by the communication device, a steering mode that is based on each group of protocol data unit sets (Fu: e.g., in some embodiments, the method for ‘processing data’ includes at least one of: [0071] configuring different first identifiers for different paths; [0072] configuring a first identifier for each of at least one path; [0073] configuring an identifier for the first QoS flow, a PDU session, or a SDAP; [0074] configuring or being configured with ‘mapping relationships’ between the first QoS flow and different paths; [0075] configuring or being configured with ‘mapping relationships between the different pieces of first data {of the QoS flow} and different paths’; [0076] identifying the different pieces of first data; [0077] adding or removing packet headers of data packets of the different pieces of first data; [0078] adding or removing control PDUs of the different pieces of first data; [0079] adding or removing control PDUs corresponding to the different pieces of first data; [0080] ‘routing {steering} the different pieces of first data to different paths’) [0070-0080] (e.g., Referring to FIG. 2, one or more ‘QoS flows’ are required to be established for transmitting user plane data in a mobile communication network, and ‘different data flows correspond to different QoS parameters’. As an important metric for communication quality, characteristics of the QoS flow are generally indicated by the ‘QoS parameters’. The QoS parameters include, but are not limited to: a ‘5QI’, an allocation and retention priority (ARP), a guaranteed flow bit rate (GFBR), maximum flow bit rate (MFBR), a maximum packet loss rate (uplink (UL), downlink (DL)) {steering mode}, a end-to-end packet delay budget (PDB), an access network-packet ‘delay’ budget (AN-PDB) {steering mode}, a ‘packet error rate’, a ‘priority’ level {steering mode}, an averaging window, a resource type, a maximum data burst volume, a UE aggregate maximum bit rate (UE-AMBR), a session aggregate maximum bit rate (Session-AMBR), and the like ) [0044; Fig. 2];
sending the first group of protocol data unit sets on a first path (Fu: e.g., ‘First PDU Set’ of QoS Flow is routed / transmitted along ‘Path 1’) [0109; Fig. 5] according to the steering mode; and sending the second group of protocol data unit sets on a second path according to the steering mode (Fu: e.g., ‘Second PDU Set’ of QoS Flow is routed / transmitted along ‘Path 2’) [0109; Fig. 5] (e.g., in some embodiments, different data processing operations is performed based on ‘types’ of the first set of PDUs and the second set of PDUs. In some embodiments, different data processing operations is performed based on ‘attributes’, ‘attribute levels’, or ‘indicators’ of the first set of PDUs and the second set of PDUs, wherein the ‘attribute’, ‘attribute level’, or ‘indicator’ includes at least one of: association, ‘dependency’, ‘importance’, ‘priority’, decoding reliability, or reliability. In some embodiments, different data processing operations is performed based on a first relationship between the first set of PDUs and the second set of PDUs, wherein the first relationship includes at least one of an association relationship, a dependency relationship, an importance relationship, a priority relationship, a decoding reliability relationship, or a reliability relationship ) [0067] (e.g., In some embodiments, the ‘bitmap indicator’ indicates the information of at least one set of PDUs. In some embodiments, the bitmap indicator includes at least one of: the SN of the control PDU; the type of the control PDU; the SN of the set of PDUs corresponding to the control PDU; the number of corresponding sets of PDUs; a ‘routing path’ of the corresponding set of PDUs; or the identifier of the corresponding set of PDUs) [0182-0183] (e.g., the transmitter routes the first set of PDUs and the second set of PDUs to different paths based on ‘first information’ {i.e., ‘mapping relationships’ between at least one of the first set of PDUs or the second set of PDUs and different paths, different types of the first set of PDUs and the second set of PDUs, different ‘attributes’, ‘attribute levels’, or ‘indicators’ of the first set of PDUs and the second set of PDUs, the first relationship between the first set of PDUs and the second set of PDUs, different ‘identifiers of different paths’, a first identifier of a path, or an identifier configured for the first QoS flow, a PDU session, or an SDAP} ) [0238-0241] [0243-0245] [0291].
Claim(s) 13 recite(s) substantially the same limitations / features as claim 1, except for the additional recited features of receiving, by a network device, a session establishment request message from a terminal device and establishing, by the network device, a session comprising an extended reality (XR) quality of service (QoS) flow (Fu: e.g., a ‘set of PDUs’ is composed of one or more PDUs, wherein the one or more PDUs carry a payload of one information unit generated in an application layer. For example, the ‘information unit’ is a frame or a video slice of ‘Extended reality and media services (XRMs)’ ) [0032] (e.g., the Terminal supports an ‘XR service’) [0529] (e.g., In case 4: the UE reports an indicator of a capability for supporting the enhanced SDAP, or the UE ‘indicates’ that it is a UE supporting the extended reality (XR) service or a UE of version R18. Both the network and the UE use the new SDAP data format by default, otherwise the original SDAP format is used. The application scope may be the ‘QoS flow corresponding to the XR service’ or all QoS flows of the UE …In case 8: based on at least one of cases 1-7, more than one PDCP/DRB is ‘activated’ or a non-default PDCP/DRB is activated {session establishment} ) [0734] (e.g., in some embodiments, the processing module 1901 is further configured to indicate the QoS rule to at least one of the terminal or the access network element upon ‘establishing a PDU session’ ) [0925] -- which is nonetheless also disclosed by Fu (above), and the claim is accordingly rejected on the same basis.
Claim(s) 20 recite(s) substantially the same limitations / features as claim 1, is/are distinguishable only by its/their statutory category (device), and accordingly rejected on the same basis.
As per claim{s} 2, 14, Fu discloses the method wherein the first group of protocol data unit sets is a first protocol data unit set, or is a first plurality of protocol data unit sets; and
wherein the second group of protocol data unit sets is a second protocol data unit set, or is a second plurality of protocol data unit sets (Fu: e.g., in some embodiments, different data processing operations is performed based on a ‘first set of PDUs’ and a ‘second set of PDUs’ corresponding to a first / same QoS flow) [0063-0064, 0625, 0769 & 0771-0772, also Claim 3 ; Figs. 5, 6 & 19].
As per claim{s} 3, Fu discloses the method wherein there is a dependency relationship between the first plurality of protocol data unit sets or the second plurality of protocol data unit sets (Fu: e.g., For example, an ‘association’ or ‘dependency relationship’ may be present between PDUs….In addition, an ‘association’ or ‘dependency relationship’ may be present between different sets of PDUs. For example, a dependency relationship is present between a ‘set of PDUs representing an I-frame’ and a ‘set of PDUs representing a P-frame’, wherein compression decoding of the P-frame ‘depends’ on the I-frame.) [0037, 0067].
As per claim{s} 7, Fu discloses the method wherein the method further comprises receiving, by the communication device from a network device, indication information that is based on each group of protocol data unit sets (Fu: e.g., in some embodiments, different data processing operations is performed based on types of the first set of PDUs and the second set of PDUs. In some embodiments, different data processing operations is performed based on ‘attributes’, ‘attribute levels’, or ‘indicators’ of the first set of PDUs and the second set of PDUs, wherein the ‘attribute’, ‘attribute level’, or ‘indicator’ includes at least one of: association, ‘dependency’, ‘importance’, ‘priority’, decoding reliability, or reliability. In some embodiments, different data processing operations is performed based on a first relationship between the first set of PDUs and the second set of PDUs, wherein the first relationship includes at least one of an association relationship, a dependency relationship, an importance relationship, a priority relationship, a decoding reliability relationship, or a reliability relationship ) [0067]; and the determining, by the communication device, the steering mode that is based on each group of protocol data unit sets comprises determining, based on the indication information, the steering mode that is based on each group of protocol data unit sets (Fu: e.g., Referring to FIG. 2, one or more ‘QoS flows’ are required to be established for transmitting user plane data in a mobile communication network, and ‘different data flows correspond to different QoS parameters’. As an important metric for communication quality, characteristics of the QoS flow are generally indicated by the ‘QoS parameters’. The QoS parameters include, but are not limited to: a ‘5QI’, an allocation and retention priority (ARP), a guaranteed flow bit rate (GFBR), maximum flow bit rate (MFBR), a maximum ‘packet loss rate’ (uplink (UL), downlink (DL)), a end-to-end packet delay budget (PDB), an access network-packet delay budget (AN-PDB), a ‘packet error rate’, a ‘priority’ level {steering mode[s]}, an averaging window, a resource type, a maximum data burst volume, a UE aggregate maximum bit rate (UE-AMBR), a session aggregate maximum bit rate (Session-AMBR), and the like ) [0044; Fig. 2] (e.g., In some embodiments, the ‘bitmap indicator’ indicates the information of at least one set of PDUs. In some embodiments, the ‘bitmap indicator’ includes at least one of: the SN of the control PDU; the SN of the set of PDUs corresponding to the control PDU; the type of the control PDU; the number of corresponding sets of PDUs; a ‘routing path’ of the corresponding set of PDUs; or the identifier of the corresponding set of PDUs) [0210].
As per claim{s} 10, Fu discloses the method wherein the method further comprises:
determining, by the communication device, that the data flow is transmitted by using an extended reality (XR) quality of service (QoS) flow (Fu: e.g., In case 4: the UE reports an indicator of a capability for supporting the enhanced SDAP, or the UE indicates that it is a UE supporting the extended reality (XR) service or a UE of version R18. Both the network and the UE use the new SDAP data format by default, otherwise the original SDAP format is used. The application scope may be the ‘QoS flow corresponding to the XR service’ or all Qos flows of the UE) [0730]; and the determining, by the communication device, the steering mode that is based on each group of protocol data unit sets comprises: determining, based on the XR QoS flow, the steering mode that is based on each group of protocol data unit sets (Fu: e.g., In case 5: the UE reports an indicator of a capability for supporting the enhanced SDAP, or the UE indicates that it is a UE supporting the XR service or a UE of version R18, and the network configures one QoS flow corresponding to a plurality of PDCPs or DRBs…In case 6: the UE reports an indicator of a capability for supporting the enhanced SDAP, or the UE indicates that it is a UE supporting the XR service or a UE of version R18, and the PDCP or the DRB configured by the network includes a ‘special tag’ (i.e., ‘important’ or ‘unimportant’, ‘XR’, or a ‘set of PDUs distinguishing identifier’)…In case 7: the PDCP or the DRB configured by the network includes a ‘special tag’ (i.e., ‘important’ or ‘unimportant’, ‘XR’, or a ‘set of PDUs distinguishing identifier’)… In case 8: based on at least one of cases 1-7, more than one PDCP/DRB is ‘activated’ or a non-default PDCP/DRB is ‘activated’) [0731-0734].
As per claim{s} 11, Fu discloses the method wherein the determining that the data flow is transmitted by using the XR QoS flow comprises: determining, by the communication device based on identification information of a QoS flow hit by the data flow, that the data flow is transmitted by using the XR QoS flow (Fu: e.g., In case 4: the UE reports an indicator of a capability for supporting the enhanced SDAP, or the UE indicates that it is a UE supporting the extended reality (XR) service or a UE of version R18. Both the network and the UE use the new SDAP data format by default, otherwise the original SDAP format is used. The application scope may be the ‘QoS flow corresponding to the XR service’ or all Qos flows of the UE) [0730]; or determining, based on QoS flow description information associated with the QoS flow hit by the data flow, that the data flow is transmitted by using the XR QoS flow, wherein the QoS flow description information comprises at least one of a QoS identifier (Fu: e.g., in some embodiments, the terminal further performs different data processing operations by mapping or filtering the first set of PDUs and the second set of PDUs based on their respective ‘QoS flows’, and at least one of a filter or a ‘QoS flow ID (QFI)’) [0506], a transmission delay (Fu: e.g., ‘delay budget’ of the first / second set of PDUs) [0919-0920], or a packet loss rate (Fu: e.g., ‘packet loss rate’ of the first / second set of PDUs) [0472]; or determining, based on a context, that the data flow is transmitted by using the XR QoS flow (Fu: e.g., In case 4: the UE reports an ‘indicator’ of a capability for supporting the enhanced SDAP, or the UE indicates that it is a UE supporting the ‘extended reality (XR) service’ or a UE of version R18. Both the network and the UE use the new SDAP data format by default, otherwise the original SDAP format is used. The application scope may be the ‘QoS flow corresponding to the XR service’ or all Qos flows of the UE) [0730].
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) 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) 4, 5, 6, 8, 9, 12, 15, 16, 17, 18, 19 is/are rejected under 35 U.S.C. 103 as being disclosed by Fu in view of Youn et al (hereinafter Youn), US Patent 12335430 B2 (filing date February 2021).
As per claim{s} 4, 15, Fu discloses substantial features of the invention as above, but does not explicitly disclose the additional feature(s) of the method wherein the steering mode comprises a load sharing mode, wherein the load sharing mode indicates that different groups of protocol data unit sets are transmitted on a plurality of paths based on preset load ratios and according to a load balancing rule.
However, in a related endeavor, Youn particularly discloses the additional feature(s) of the method wherein the steering mode comprises a load sharing mode, wherein the load sharing mode indicates that different groups of protocol data unit sets are transmitted on a plurality of paths based on preset load ratios and according to a load balancing rule (Youn: e.g., Each ‘ATSSS rule’ may include a ‘traffic descriptor’ {i.e., including one or more components described in the example in Table 3} that may determine when the rule is applicable…Each ATSSS rule may include an ‘access selection descriptor’ that includes components such as the following examples: ATSSS rules may include a ‘Steering Mode’. Steering Mode may determine how the matched SDF should be distributed over 3GPP access and non-3GPP access. ‘Steering Modes’ such as the following examples may be supported: 1) ‘Active-Standby’: Active-Standby can be used to steer the SDF in one access (Active access) (if this access is available). And, when active access is unavailable, Active-Standby can be used to switch the SDF to another available access (Standby access). When active access becomes available again, the SDF can be switched back to active access. If standby access is not defined, SDF is allowed only for active access and cannot be transmitted to other accesses. 2) ‘Smallest Delay’: Smallest Delay can be used to steer the SDF to the access determined to have the smallest Round-Trip Time (RTT). Measurements may be performed by the UE and UPF to determine RTT over 3GPP access and non-3GPP access. Also, if one access becomes unavailable, SDF traffic can be switched to another available access, if allowed by PCC rules. 3) ‘Load-Balancing’ [Wingdings font/0xE0] Load-Balancing can be used to ‘split’ the SDF through both accesses {paths} when both accesses are available. Load-Balancing may include a percentage of SDF traffic transmitted through 3GPP access and non-3GPP access. Load-balancing can only be applied to non-GBR (Guaranteed Bit Rate) ‘QoS flows’. Also, if one access becomes unavailable, all SDF traffic may be switched to another available access, as if the percentage of SDF traffic over the other available access is 100%. 4) Priority-based: Priority-based can be used to steer the traffic of SDF with high priority access. Priority-based can be used to steer the traffic of the SDF to high priority access until it is determined that the high priority access is congested. When it is determined that the high-priority access is congested, the traffic of the SDF may be transmitted even with the low-priority access. That is, SDF traffic may be split through two accesses. Also, if high priority access becomes unavailable, all SDF traffic may be switched through low priority access. How the UE and the UPF determine when congestion occurs in access may vary by implementation. ATSSS rules may include ‘Steering Functionality’. Steering Functionality can be used to identify whether the MPTCP function or the ATSSS-LL function can be used to steer the traffic of the matching SDF. Steering Functionality can be used when the UE supports multiple functions for ATSSS) [col 27, L38 – col 29, L12; Table 3].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify Fu’s invention with the above said additional feature(s), as expressly disclosed by Youn, for the motivation of providing a method and system for performing, by a network node, efficient communication associated with an MA PDU session [Youn: Abstract, col 1, L24 – col 2, L50; Figs.1-2 & 9-10].
As per claim{s} 5, 16, Fu in view of Youn, and Youn in particular, discloses the additional feature(s) of the method wherein the steering mode comprises: a minimum delay mode, wherein the minimum delay mode indicates that a group of protocol data unit sets is transmitted on the first path with a low transmission delay; and when it is detected that a second transmission delay of the second path is lower than a first transmission delay of the first path, transmission is performed on the second path based on each group of protocol data unit sets (Youn: e.g., Each ‘ATSSS rule’ may include a ‘traffic descriptor’ {i.e., including one or more components described in the example in Table 3} that may determine when the rule is applicable…Each ATSSS rule may include an ‘access selection descriptor’ that includes components such as the following examples: ATSSS rules may include a ‘Steering Mode’. Steering Mode may determine how the matched SDF should be distributed over 3GPP access and non-3GPP access. ‘Steering Modes’ such as the following examples may be supported: 1) ‘Active-Standby’: Active-Standby can be used to steer the SDF in one access (Active access) (if this access is available). And, when active access is unavailable, Active-Standby can be used to switch the SDF to another available access (Standby access). When active access becomes available again, the SDF can be switched back to active access. If standby access is not defined, SDF is allowed only for active access and cannot be transmitted to other accesses. 2) ‘Smallest Delay’ [Wingdings font/0xE0] Smallest Delay can be used to steer the SDF to the access determined to have the smallest Round-Trip Time (RTT). Measurements may be performed by the UE and UPF to determine RTT over 3GPP access and non-3GPP access. Also, if one access becomes unavailable, SDF traffic can be switched to another available access, if allowed by PCC rules. 3) ‘Load-Balancing’ : Load-Balancing can be used to ‘split’ the SDF through both accesses {paths} when both accesses are available. Load-Balancing may include a percentage of SDF traffic transmitted through 3GPP access and non-3GPP access. Load-balancing can only be applied to non-GBR (Guaranteed Bit Rate) ‘QoS flows’. Also, if one access becomes unavailable, all SDF traffic may be switched to another available access, as if the percentage of SDF traffic over the other available access is 100%. 4) Priority-based: Priority-based can be used to steer the traffic of SDF with high priority access. Priority-based can be used to steer the traffic of the SDF to high priority access until it is determined that the high priority access is congested. When it is determined that the high-priority access is congested, the traffic of the SDF may be transmitted even with the low-priority access. That is, SDF traffic may be split through two accesses. Also, if high priority access becomes unavailable, all SDF traffic may be switched through low priority access. How the UE and the UPF determine when congestion occurs in access may vary by implementation. ATSSS rules may include ‘Steering Functionality’. Steering Functionality can be used to identify whether the MPTCP function or the ATSSS-LL function can be used to steer the traffic of the matching SDF. Steering Functionality can be used when the UE supports multiple functions for ATSSS) [col 27, L38 – col 29, L12; Table 3].
The motivation for combining the prior art is the same as that given to claim 4 above.
As per claim{s} 6, 17, Fu in view of Youn, and Youn in particular, discloses the additional feature(s) of the method wherein the steering mode comprises: a priority mode, wherein the priority mode indicates that a group of protocol data unit sets is transmitted on the first path; and when the first path is congested, transmission is performed on the second path based on each group of protocol data unit sets (Youn: e.g., Each ‘ATSSS rule’ may include a ‘traffic descriptor’ {i.e., including one or more components described in the example in Table 3} that may determine when the rule is applicable…Each ATSSS rule may include an ‘access selection descriptor’ that includes components such as the following examples: ATSSS rules may include a ‘Steering Mode’. Steering Mode may determine how the matched SDF should be distributed over 3GPP access and non-3GPP access. ‘Steering Modes’ such as the following examples may be supported: 1) ‘Active-Standby’: Active-Standby can be used to steer the SDF in one access (Active access) (if this access is available). And, when active access is unavailable, Active-Standby can be used to switch the SDF to another available access (Standby access). When active access becomes available again, the SDF can be switched back to active access. If standby access is not defined, SDF is allowed only for active access and cannot be transmitted to other accesses. 2) ‘Smallest Delay’ : Smallest Delay can be used to steer the SDF to the access determined to have the smallest Round-Trip Time (RTT). Measurements may be performed by the UE and UPF to determine RTT over 3GPP access and non-3GPP access. Also, if one access becomes unavailable, SDF traffic can be switched to another available access, if allowed by PCC rules. 3) ‘Load-Balancing’ : Load-Balancing can be used to ‘split’ the SDF through both accesses {paths} when both accesses are available. Load-Balancing may include a percentage of SDF traffic transmitted through 3GPP access and non-3GPP access. Load-balancing can only be applied to non-GBR (Guaranteed Bit Rate) ‘QoS flows’. Also, if one access becomes unavailable, all SDF traffic may be switched to another available access, as if the percentage of SDF traffic over the other available access is 100%. 4) ‘Priority-based’ [Wingdings font/0xE0] Priority-based can be used to steer the traffic of SDF with ‘high priority’ access. Priority-based can be used to steer the traffic of the SDF to high priority access until it is determined that the high priority access is congested. When it is determined that the high-priority access is congested, the traffic of the SDF may be transmitted even with the low-priority access. That is, SDF traffic may be ‘split’ through two accesses. Also, if high priority access becomes unavailable, all SDF traffic may be switched through low priority access. How the UE and the UPF determine when congestion occurs in access may vary by implementation. ATSSS rules may include Steering Functionality. Steering Functionality can be used to identify whether the MPTCP function or the ATSSS-LL function can be used to steer the traffic of the matching SDF. Steering Functionality can be used when the UE supports multiple functions for ATSSS) [col 27, L38 – col 29, L12; Table 3].
The motivation for combining the prior art is the same as that given to claim 4 above.
As per claim{s} 8, 18, Fu in view of Youn, and Youn in particular, discloses the additional feature(s) of the method wherein the determining, by the communication device, the steering mode comprises: determining, by the communication device based on the indication information, a load sharing mode that is based on each group of protocol data unit sets, wherein the determining the load sharing mode comprises: receiving, by the communication device, first information and second information from the network device, wherein the first information identifies a path, and the second information identifies a load ratio of the path corresponding to the first information; and
determining, by the communication device based on the first information and the second information, the load ratio of the path determined based on the first information (Youn: e.g., c) ATSSS rules may include “Traffic Descriptor: Application-1” Steering Mode: Load-Balancing, 3GPP=20%, non-3GPP=80%”, and “Steering Functionality: MPTCP”: This ATSSS rule may mean “Using the MPTCP function, transmit 20% of application-1's traffic over 3GPP access, and transmit 80% of application-1's traffic over non-3GPP access”) [col 29, L32-39].
The motivation for combining the prior art is the same as that given to claim 4 above.
As per claim{s} 9, 19, Fu in view of Youn, and Fu in particular, discloses the method wherein the determining, by the communication device, the steering mode comprises: determining, based on indication information, a priority mode that is based on each group of protocol data unit sets (Fu: e.g., ‘priority indicators’ of the first / second set of PDUs ) [0275, 0315], and the method further comprises: receiving, by the communication device, third information from the network device, wherein the third information identifies a path for preferential transmission; and determining, by the communication device based on the third information, that the first path is the path for preferential transmission (Fu: e.g., In some other embodiments, the ‘bitmap indicator’ indicates the corresponding relationship between “one set of PDUs and the ‘path’ by explicit representation”. For example, the SN number of the set of PDUs or the SN number of the control PDU is indicated, and the path corresponding to the set of PDUs is indicated. The path indicator may be a ‘path identifier’, or a bitmap indicator of the path (for example, the mode as described in one of the above design mode 1, 2 or 3)) [0460].
As per claim{s} 12, Fu in view of Youn, and Youn in particular, discloses the additional feature(s) of the method wherein the first path and the second path are different transmission paths corresponding to a 3rd generation partnership project (3GPP) access type or a non-3GPP access type (Youn: e.g., The UE may receive the ATSSS rule from the SMF. The ATSSS rule may indicate how to ‘route’ uplink traffic through 3GPP access and non-3GPP access) [col 23, L34-39; Table 3] (e.g., ‘access type’ for the MA PDU session) [ col 23, L61].
The motivation for combining the prior art is the same as that given to claim 4 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GLENFORD J MADAMBA whose telephone number is (571)272-7989. The examiner can normally be reached on Mondays to Fridays, from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-7989. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/GLENFORD J MADAMBA/Primary Examiner, Art Unit 2451
Prosecution Insights