DETAILED ACTION
Claims 1-14, and 16-21 are presented for examination.
Claims 1-4, 8, 12, 14, 17, 19, and 20 are amended.
Claim 15 is canceled.
Claim 21 is new.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
The objection to the claims has been withdrawn based on Applicant’s amendment.
Applicant’s arguments with respect to claim(s) 1 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.
Applicant's arguments filed 05/14/2026 have been fully considered but they are not persuasive. The reasons set forth below.
The Applicant argues:
(1) Sunkada does not teach the feature "wherein the in-order traffic comprises a first type of protocol data unit (PDU) sets and the out-of-order traffic comprises a second type of PDU sets," as recited in amended claim 3, [Remarks, page 9].
The Examiner respectfully disagrees with these arguments.
As per the first argument
As indicated in the previous rejection and below, Sunkada teaches wherein the in-order traffic comprises a first type of protocol data unit (PDU) sets, and the out-of-order traffic comprises a second type of PDU sets [fig. 1, 2B, 11, claim 1, paragraphs 0008, 0067, 0068, 0071, 0072, 0074, wherein the in-order traffic comprises a first type of protocol data unit (PDU) sets, and the out-of-order traffic comprises a second type of PDU sets (INORDER Packets of the IP Flow 1; the out of order in another IP flow 2)].
Regarding wherein the in-order traffic comprises a first type of protocol data unit (PDU) sets, and the out-of-order traffic comprises a second type of PDU sets, Sunkada discloses in Figure 11, claim 1, paragraphs 0008, 0067, 0088.
PNG
media_image1.png
264
546
media_image1.png
Greyscale
Figure 11 illustrates all the packets that are in order and the packets which are not in order.
[0008] …. It is evident from FIG. 4 that packets with sequence numbers (SN 5, SN 6) are not delivered to the application even though they are in order with respect to the IP Flow 1 of the first Application because of the missing packets with PDCP sequence number (SN 3 and SN 4 of IP flow 2) from the reordering window. Buffers are not freed at PDCP. It may trigger the transport layer timeout at the sender application and may lead to a slow start and retransmission of the packets due to which the first application suffers because of the loss in packets of the second application belonging to the IP flow 2. In particular, each flow may belong to different Applications/Transport layer sessions at the user space. Therefore, INORDER Packets of the IP Flow 1 wait in the reordering window due to the out of order in another IP flow 2 as both the flows belong to the same DRB.
[0067] FIG. 9 is a diagram illustrating a second exemplary scenario to transfer the received data packets to the upper layer where the reorder timer is running, in accordance with an embodiment. As shown in FIG. 9, there are four data packets (PDCP SN 0, PDCP SN 1, PDCP SN 4, and PDCP SN 3) are received at the PDCP layer at a respective time intervals t0, t1, t2, and t3. At time t3 of FIG. 9, it can be seen that the data packets which is received having PDCP SN 4 is out of order with respect to the sequence flow of FLOW_ID 1, and the data packet with the PDCP SN 2 and PDCP SN 3 is missing. Therefore, due to the detection of the missing data packets and the out-of-order data packets, the PDCP reorder timer starts running and waits for the missing packets to arrive at the PDCP layer. However, when the data packet with the PDCP SN 3 arrives at the PDCP layer, it is determined that the data packets with the PDCP SN 3 and the PDCP SN 4 are in order with respect to the sequence flow of FLOW_ID 1. Therefore, the data packets that are determined to be in sequence are delivered to the upper layer when the PDCP reorder timer is running. ….
[0088] At the step 1404, the method 1400 comprises generating unique Flow IDs of the received data packets based on the plurality of parameters related to each of the received data packets which correspond to but are not necessarily limited to including, a source IP, a destination IP, a source port, and a destination port of the corresponding data packet of the received data packets. For generating the unique Flow IDs, at first, the processor 602 analyzes a sequence flow of the received one or more data packets based on the packet sequence numbers (PDCP SN) included in the PDU header of each of the one or more data packets. …. Thereafter, as an outcome of assigning the Flow_ID to each of the one or more data packets, the unique flow IDs are generated. The Same FLOW_ID is generated for all the packets that are belonging to the same flow. It is to be noted that The Identification and the assigning operation to assign the unique FLOW_ID to each of the one or more data packets, can be done by any layer before the PDCP SN update.
[Claim 1] … a first set of data packets among the received plurality of data packets of which associated packet flow sequence numbers of the first flow are in order with respect to the flow IDs and are after the packet flow sequence numbers of the at least one data packet whose packet flow sequence number is out of order;…
In other words, Sunkada discloses a first set of data packets among the received plurality of data packets of which associated packet flow sequence numbers are in order, and the packet flow sequence numbers of the at least one data packet whose packet flow sequence number is out of order.
Therefore, given that Sunkada discloses wherein the in-order traffic comprises a first type of plurality of data packets (the packet sequence numbers (PDCP SN) included in the PDU header of each of the one or more data packets), and the out-of-order traffic comprises a second type of plurality of data packets, then Sunkada clearly discloses wherein the in-order traffic comprises a first type of protocol data unit (PDU) sets, and the out-of-order traffic comprises a second type of PDU sets.
In view of above, it is clear that the system/methods of the cited art disclose the claimed invention.
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 2, 5, 6, 8-14, 16, 20, and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hande et al., (hereinafter Hande), U.S. Publication No. 2022/0038955, in view of Parron et al., International Publication Number WO 2020/036928.
As per claim 1, Hande discloses a baseband processor [fig. 8, 9, paragraphs 0068, 0075, 0085, a baseband processor (a processing system/apparatus)], comprising:
one or more processors [fig. 8, 9, paragraphs 0068, 0075, 0078, 0085, 0088, 0093, 0099, one or more processors (the circuitry included in the processor)] configured to:
receive an OOD configuration [paragraphs 0032, 0093-0096, 0098, receive an OOD configuration (one or more configuration parameters from the wireless network; receives downlink control information)]; and
communicate information as in-order traffic and out-of-order traffic based on the OOD configuration [paragraphs 0056, 0073, 0098, communicate information as in-order traffic and out-of-order traffic based on the OOD configuration (in-order delivery of packets; activate and/or deactivate OOOD for the data; OOOD may be activated/deactivated for downlink traffic)].
Hande does not explicitly disclose provide User Equipment (UE) capability information including an indication of whether the UE is capable of communicating information using selective out-of- order delivery (OOD) and an indication of whether the UE is capable of communicating information using per-packet OOD.
However, Parron teaches provide User Equipment (UE) capability information including an indication of whether the UE is capable of communicating information using selective out-of- order delivery (OOD) and an indication of whether the UE is capable of communicating information using per-packet OOD [fig. 1, 2, page 4, lines 7-25, page 9, lines 33-34, page 10, lines 1-25, page 11, lines 19-34, page 12, lines 1-7, page 13, lines 17-29, page 14, lines 26-34, provide User Equipment (UE) capability information including an indication of whether the UE is capable of communicating information using selective out-of- order delivery (OOD) and an indication of whether the UE is capable of communicating information using per-packet OOD (UE 101 may generate an RRC UE Capability information message to include UE Capability information, which includes the out-of-order delivery UE capability indicator; determine whether to use SDF ID tagging or new QFI tagging based on signaling)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to improve upon the processor described in Hande by including using selective out-of- order delivery (OOD) and using per-packet OOD as taught by Parron because it would provide the Hande's processor with the enhanced capability of enabling faster packet delivery [Parron, page 2, lines 2-12, page 5, lines 27-33, page 13, lines 18-21].
As per claim 2, Hande discloses the baseband processor of claim 1, wherein the out-of-order traffic comprises at least one of:
one or more protocol data units (PDUs),one or more PDU set types, one or more packet data convergence protocol (PDCP) service data units (SDUs),one or more service data adaptation protocol (SDAP) service data units (SDUs),one or more traffic flows, one or more service data flows (SDFs), or one or more quality of service (QoS) flows [paragraphs 0056, 0059, 0066, 0067, one or more protocol data units (PDUs); one or more traffic flows, one or more service data flows (SDFs), or one or more quality of service (QoS) flows (PDU session 412 may include one or more data flows; service data unit (SDU) may be delivered to the PDCP layer; packets from a service data flow (SDF) to the first QoS flow, and packets from other SDFs to respective other QoS flows)].
As per claim 5, Hande discloses the baseband processor of claim 1,
wherein the in-order traffic and the out-of-order traffic correspond to a same quality flow identifier (QFI) [paragraphs 0062, 0064, 0070, 0088, wherein the in-order traffic and the out-of-order traffic correspond to a same quality flow identifier (QFI) (QoS flow to DRB mapping by NB 408 is based on the QFI and the associated QoS profiles (i.e., QoS parameters and QoS characteristics); the QFI flow and DRB shared with other traffic)].
As per claim 6, Hande discloses the baseband processor of claim 5,
wherein headers of packets of the out-of-order traffic comprise an out-of-order flag [paragraphs 0064, 0093, 0098, wherein headers of packets of the out-of-order traffic comprise an out-of-order flag (determine one or more configuration parameters for each set of PDCP-OOOD flow indicating if a network RRC-configured flag for PDCP-OOOD enablement; a QoS Flow ID (QFI) carried in an encapsulation header)].
As per claim 8, Hande discloses the baseband processor of claim 1,
wherein the in-order traffic corresponds to a first quality flow identifier (QFI) and the out-of-order traffic correspond to a second QFI being different than the first QFI [Abstract, paragraphs 0064, 0071, 0072, 0088, 0092, wherein the in-order traffic corresponds to a first quality flow identifier (QFI) and the out-of-order traffic correspond to a second QFI being different than the first QFI (one or more distinct QFI flows 614; the QFI flow and DRB is not shared with other traffic)].
As per claim 9, Hande discloses the baseband processor of claim 8,
wherein the in-order traffic is configured to be identified by a packet data convergence protocol (PDCP) receiver based on the first QFI and the out-of-order traffic is configured to be identified by the PDCP receiver based on the second QFI [fig. 11, paragraphs 0008, 0060, 0064, 0081, 0092, 0093, 0097, wherein the in-order traffic is configured to be identified by a packet data convergence protocol (PDCP) receiver based on the first QFI and the out-of-order traffic is configured to be identified by the PDCP receiver based on the second QFI (the UE may identify data from the wireless network that matches the one or more configuration parameters; mapping by NB 408 is based on the QFI and the associated QoS profiles (i.e., QoS parameters and QoS characteristics); processing circuitry 841 may include one or more transmit/receive chains; determine IP flows associated with application provided QFIs)].
As per claim 10, Hande discloses the baseband processor of claim 1, wherein the one or more processors are further configured to:
using one or more upper layers of the UE, provide one or more lower layers of the UE with an indication of which traffic is configured for OOD [fig. 3, paragraphs 0054, 0055, 0067, 0070, 0073, using one or more upper layers of the UE, provide one or more lower layers of the UE with an indication of which traffic is configured for OOD (PDCP layer 314 provides packet sequence numbering, in-order delivery of packets, retransmission of PDCP protocol data units (PDUs), and transfer of upper layer data packets to lower layers)].
As per claim 11, Hande discloses the baseband processor of claim 1, wherein the one or more processors are further configured to
identify information as in-order traffic or out-of-order traffic based on the OOD configuration [paragraphs 0005, 0064, 0097, identify information as in-order traffic or out-of-order traffic based on the OOD configuration (identifying data from the wireless network that matches the one or more configuration parameters and activating out-of-order delivery (OOOD) for the data)].
As per claim 12, Hande discloses the baseband processor of claim 1, wherein the out-of-order traffic is indicated based on at least one of:
a property of a corresponding quality of service (QoS) flow, a property of a corresponding protocol data unit (PDU) set or a PDU set type, a property of a corresponding traffic flow or a service data flow (SDF), a property of a packet header on a per-packet basis, or a property of a packet header field of an upper layer payload [paragraphs 0056, 0059, 0064, 0066, 0067, 0070, 0088, a property of a corresponding quality of service (QoS) flow, a property of a corresponding protocol data unit (PDU) set or a PDU set type, a property of a corresponding traffic flow or a service data flow (SDF), a property of a packet header on a per-packet basis, or a property of a packet header field of an upper layer payload (QoS flow 418a-418c is identified within the PDU session 412 by a QoS Flow ID (QFI) carried in an encapsulation header; PDU session 412 may include one or more data flows; service data unit (SDU) may be delivered to the PDCP layer; packets from a service data flow (SDF) to the first QoS flow, and packets from other SDFs to respective other QoS flows)].
As per claim 13, Hande discloses the baseband processor of claim 1, wherein the one or more processors are further configured to:
receive a radio resource control (RRC) message to configure a packet data convergence protocol (PDCP) and a data radio bearer (DRB) for the selective OOD or the per-packet OOD [paragraphs 0064, 0065, 0070, 0093, receive a radio resource control (RRC) message to configure a packet data convergence protocol (PDCP) and a data radio bearer (DRB) for the selective OOD or the per-packet OOD (determine one or more configuration parameters for each set of PDCP-OOOD flow indicating if a network RRC-configured flag for PDCP-OOOD enablement is used; NB 408 may configure by RRC an uplink QoS Flow to DRB mapping)].
As per claim 14, Hande discloses a method for a base station [paragraphs 0030, 0032, 0042, a method for a base station (a scheduling entity (e.g., a base station 108) allocates resources for communication)], comprising:
transmitting an OOD configuration to the UE based on the UE capability information [paragraphs 0032, 0093-0096, 0098, transmitting an OOD configuration to the UE based on the UE capability information (one or more configuration parameters from the wireless network; receives downlink control information)]; and
communicating information as in-order traffic and out-of-order traffic with the UE based on the OOD configuration [paragraphs 0056, 0073, 0098, communicating information as in-order traffic and out-of-order traffic with the UE based on the OOD configuration (in-order delivery of packets; activate and/or deactivate OOOD for the data; OOOD may be activated/deactivated for downlink traffic)].
Hande does not explicitly disclose receiving User Equipment (UE) capability information including an indication of whether the UE is capable of communicating information using selective out-of-order delivery (OOD) and an indication of whether the UE is capable of communicating information using per- packet OOD.
However, Parron teaches receiving User Equipment (UE) capability information including an indication of whether the UE is capable of communicating information using selective out-of-order delivery (OOD) and an indication of whether the UE is capable of communicating information using per- packet OOD [fig. 1, 2, page 4, lines 7-25, page 9, lines 33-34, page 10, lines 1-25, page 11, lines 19-34, page 12, lines 1-7, page 13, lines 17-29, page 14, lines 26-34, receiving User Equipment (UE) capability information including an indication of whether the UE is capable of communicating information using selective out-of-order delivery (OOD) and an indication of whether the UE is capable of communicating information using per- packet OOD (UE 101 may generate an RRC UE Capability information message to include UE Capability information, which includes the out-of-order delivery UE capability indicator; determine whether to use SDF ID tagging or new QFI tagging based on signaling)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to improve upon the method described in Hande by including using selective out-of- order delivery (OOD) and using per-packet OOD as taught by Parron because it would provide the Hande's method with the enhanced capability of enabling faster packet delivery [Parron, page 2, lines 2-12, page 5, lines 27-33, page 13, lines 18-21].
As per claim 16, Hande discloses the method of claim 14, further comprising:
transmitting a radio resource control (RRC) message to the UE to configure a packet data convergence protocol (PDCP) and a data radio bearer (DRB) for the selective OOD or the per-packet OOD [paragraphs 0064, 0065, 0070, 0093, transmitting a radio resource control (RRC) message to the UE to configure a packet data convergence protocol (PDCP) and a data radio bearer (DRB) for the selective OOD or the per-packet OOD (determine one or more configuration parameters for each set of PDCP-OOOD flow indicating if a network RRC-configured flag for PDCP-OOOD enablement is used; NB 408 may configure by RRC an uplink QoS Flow to DRB mapping)].
As per claim 20, Hande discloses a User Equipment (UE) [fig. 8, 9, paragraphs 0068, 0074, 0075, 0085, a User Equipment (the scheduled entity 800 may be a user equipment (UE))], comprising:
a memory; radio front end circuitry; and processor circuitry, coupled to the radio front end circuitry and the memory, the processor circuitry configured to execute instructions stored in the memory [fig. 8, 9, paragraphs 0068, 0075, 0076, 0078, 0085, 0088, 0093, 0099, a memory; radio front end circuitry; and processor circuitry, coupled to the radio front end circuitry and the memory, the processor circuitry configured to execute instructions stored in the memory (the circuitry included in the processor; processor 804 is responsible for managing the bus 802 and general processing, including the execution of software stored on the computer-readable medium 806; the transceiver 810 that receives the information)] to cause the UE to:
receive an OOD configuration [paragraphs 0032, 0093-0096, 0098, receive an OOD configuration (one or more configuration parameters from the wireless network; receives downlink control information)]; and
communicate information as in-order traffic and out-of-order traffic based on the OOD configuration [paragraphs 0056, 0073, 0098, communicate information as in-order traffic and out-of-order traffic based on the OOD configuration (in-order delivery of packets; activate and/or deactivate OOOD for the data; OOOD may be activated/deactivated for downlink traffic)].
Hande does not explicitly disclose transmit User Equipment (UE) capability information including an indication of whether the UE is capable of communicating information using selective out-of- order delivery (OOD) and an indication of whether the UE is capable of communicating information using per-packet OOD.
However, Parron teaches transmit User Equipment (UE) capability information including an indication of whether the UE is capable of communicating information using selective out-of- order delivery (OOD) and an indication of whether the UE is capable of communicating information using per-packet OOD [fig. 1, 2, page 4, lines 7-25, page 9, lines 33-34, page 10, lines 1-25, page 11, lines 19-34, page 12, lines 1-7, page 13, lines 17-29, page 14, lines 26-34, transmit User Equipment (UE) capability information including an indication of whether the UE is capable of communicating information using selective out-of- order delivery (OOD) and an indication of whether the UE is capable of communicating information using per-packet OOD (UE 101 may generate an RRC UE Capability information message to include UE Capability information, which includes the out-of-order delivery UE capability indicator; determine whether to use SDF ID tagging or new QFI tagging based on signaling)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to improve upon the processor described in Hande by including using selective out-of- order delivery (OOD) and using per-packet OOD as taught by Parron because it would provide the Hande's processor with the enhanced capability of enabling faster packet delivery [Parron, page 2, lines 2-12, page 5, lines 27-33, page 13, lines 18-21].
As per claim 21, Hande discloses the baseband processor of claim 1,
Hande does not explicitly disclose wherein the one or more processors are further configured to provide the UE capability information to a base station as part of a procedure to establish a data radio bearer (DRB) with the base station.
However, Parron teaches wherein the one or more processors are further configured to provide the UE capability information to a base station as part of a procedure to establish a data radio bearer (DRB) with the base station [page 3, lines 18-31, page 6, lines 28-32, page 7, lines 15-21, page 8, lines 1-10, page 10, lines 11-25, page 11, lines 19-31, page 13, lines 9-16, provide the UE capability information to a base station as part of a procedure to establish a data radio bearer (DRB) with the base station (DRBs 154 are associated with one or more QoS flows 151 different applications/services; establish a new DRB 154 for packet flows 145; delivery capability should be used for delivering the packets of the packet flow)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to improve upon the processor described in Hande by establishing a data radio bearer (DRB)as taught by Parron because it would provide the Hande's processor with the enhanced capability of enabling faster packet delivery [Parron, page 2, lines 2-12, page 5, lines 27-33, page 13, lines 18-21].
Claim(s) 3, 4, and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hande, in view of Parron, and in further view of Sunkada Gopinath et al., (hereinafter Sunkada), U.S. Publication No. 2023/0412514.
As per claim 3, Hande discloses the baseband processor of claim 1,
wherein the traffic comprises a first type of protocol data unit sets and the out-of-order traffic comprises a second type of PDU sets [fig. 4, 11, paragraphs 0059, 0073, 0094, 0097, 0098, wherein the traffic comprises a first type of PDU sets or QoS flows, and the out-of-order traffic comprises a second type of PDU sets or QoS flows (activate and/or deactivate OOOD for the data from the wireless network that matches the one or more configuration parameters; applying different handling to different traffic flows in the network)].
Hande does not explicitly disclose wherein the in-order traffic comprises a first type of PDU sets or QoS flows, and the out-of-order traffic comprises a second type of PDU sets or QoS flows.
However, Sunkada teaches wherein the in-order traffic comprises a first type of protocol data unit (PDU) sets, and the out-of-order traffic comprises a second type of PDU sets [fig. 1, 2B, 11, claim 1, paragraphs 0008, 0067, 0068, 0071, 0072, 0074, wherein the in-order traffic comprises a first type of protocol data unit (PDU) sets, and the out-of-order traffic comprises a second type of PDU sets (INORDER Packets of the IP Flow 1; the out of order in another IP flow 2)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to improve upon the processor described in Hande by including the in-order traffic comprises a first type of PDU sets or QoS flows, and the out-of-order traffic comprises a second type of PDU sets or QoS flows as taught by Sunkada because it would provide the Hande's processor with the enhanced capability of improving user experience with higher throughput [Sunkada, paragraph 0096].
As per claim 4, Hande discloses the baseband processor of claim 1,
wherein the traffic comprises a primary quality of service (QoS) flow and the out-of-order traffic comprises a secondary QoS flow [paragraphs 0066, 0098, wherein the traffic comprises a primary quality of service (QoS) flow and the out-of-order traffic comprises a secondary QoS flow (the UE may be configured to map a first QoS flow and a second QoS flow)].
Hande does not explicitly disclose wherein the in-order traffic and the out-of-order traffic.
However, Sunkada teaches wherein the in-order traffic and the out-of-order traffic [fig. 1, 2B, 11, paragraphs 0008, 0067, 0068, 0071, 0072, 0074, wherein the in-order traffic and the out-of-order traffic (INORDER Packets of the IP Flow 1; the out of order in another IP flow 2)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to improve upon the processor described in Hande by including wherein the in-order traffic and the out-of-order traffic as taught by Sunkada because it would provide the Hande's processor with the enhanced capability of improving user experience with higher throughput [Sunkada, paragraph 0096].
As per claim 7, Hande discloses the baseband processor of claim 5, wherein the one or more processors are further configured to
identify a packet of the out-of-order traffic [paragraphs 0008, 0069, 0088, 0097, 0101, identify a packet of the out-of-order traffic (identify data from the wireless network that matches the one or more configuration parameters and activate out-of-order delivery (OOOD) for the data; process traffic mapping an packet filtering)].
Hande does not explicitly disclose identify a packet by deep packet inspection (DPI).
However, Sunkada teaches identify a packet by deep packet inspection (DPI) [fig. 1, 2B, 11, paragraphs 0083, 0094, 0095, wherein the in-order traffic comprises a first type of PDU sets or QoS flows, and the out-of-order traffic comprises a second type of PDU sets or QoS flows (identify the Flow IDs based on a deep packet inspection)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to improve upon the processor described in Hande by including identify a packet by deep packet inspection as taught by Sunkada because it would provide the Hande's processor with the enhanced capability of improving user experience with higher throughput [Sunkada, paragraph 0096].
Claim(s) 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hande, in view of Parron, and in further view of Pan, U.S. Publication No. 2021/0352521.
As per claim 17, Hande discloses the method of claim 14, Hande does not explicitly disclose wherein an uplink (UL) protocol data unit (PDU) session information is configured to enable a user plane function (UPF) to receive control information elements (IEs) associated with a transfer of packets over an N3 interface, and downlink (DL) PDU session information is configured to enable the base station to receive control IEs associated with a transfer of packets over an N3 interface.
However, Pan teaches wherein an uplink (UL) protocol data unit (PDU) session information is configured to enable a user plane function (UPF) to receive control information elements (IEs) associated with a transfer of packets over an N3 interface, and downlink (DL) PDU session information is configured to enable the base station to receive control IEs associated with a transfer of packets over an N3 interface [paragraphs 0047, 0059, 0062-0064, 0068, 0103, 0113, 0115, 0132, 0202, wherein an uplink (UL) PDU session information is configured to enable a user plane function (UPF) to receive control information elements (IEs) associated with a transfer of packets over an N3 interface, and downlink (DL) PDU session information is configured to enable the base station to receive control IEs associated with a transfer of packets over an N3 interface (control element information; the UL PDU, and selects the N3 tunnel; DL packets corresponding to this SDF, the UPF may set the RQI bit in the encapsulation header on the N3 reference point)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to improve upon the processor described in Hande by including user plane function (UPF) to receive control information elements (IEs) as taught by Pan because it would provide the Hande's processor with the enhanced capability of improving scheduling in a wireless communication system [Pan, paragraph 0002].
As per claim 18, Hande discloses the method of claim 14, Hande does not explicitly disclose wherein the out-of-order traffic is indicated using a quality of service (QoS) flow information element (IE) via an N2 interface.
However, Pan teaches wherein the out-of-order traffic is indicated using a quality of service (QoS) flow information element (IE) via an N2 interface [paragraphs 0057, 0136, 0139, 0140, 0158, 0167, wherein the out-of-order traffic is indicated using a quality of service (QoS) flow information element (IE) via an N2 interface (N2 signalling is required at the time traffic for the corresponding QoS flows; possible out-of-order delivery when re-mapping a QoS-Flow to a different DRB)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to improve upon the processor described in Hande by including using a quality of service (QoS) flow information element (IE) via an N2 interface as taught by Pan because it would provide the Hande's processor with the enhanced capability of improving scheduling in a wireless communication system [Pan, paragraph 0002].
As per claim 19, Hande discloses the method of claim 14, Hande does not explicitly disclose wherein an OOD is configured to be indicated in uplink (UL) protocol data unit (PDU) session information on a per-packet basis using a 1-bit field.
However, Pan teaches wherein an OOD is configured to be indicated in uplink (UL) protocol data unit (PDU) session information on a per-packet basis using a 1-bit field [paragraphs 0113, 0114, 0120, 0164, wherein an OOD is configured to be indicated in UL PDU session information on a per-packet basis using a 1-bit field (one-bit indication in the DL header; the bit is set to 1; the SDAP header would need to indicate with one bit the presence of the “QoS Flow ID”; PDCP Data PDU with P bit set to 1 is received)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to improve upon the processor described in Hande by including using a 1-bit field as taught by Pan because it would provide the Hande's processor with the enhanced capability of improving scheduling in a wireless communication system [Pan, paragraph 0002].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kanamarlapudi et al., U.S. Publication No. 2024/0259860 discloses wherein PDCP OOOD may be enabled or disabled at the data flow level based on the respective QFI of each of the data flows.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACKIE ZUNIGA ABAD whose telephone number is (571)270-7194. The examiner can normally be reached Monday - Friday, 8:00am - 4:00pm.
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, IAN MOORE can be reached at 571-272-3085. 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.
/JACKIE ZUNIGA ABAD/Primary Examiner, Art Unit 2469
Prosecution Insights