DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
Claims 1-2, 4-5, 10, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jason Yuchen Guo, Huawei technologies, “CR for RTWT TID Selection Rules”, IEEE 802.11-22/0514r0 referred to herein as “Huawei” in view of Millnert et al. US (2025/0016099).
Regarding Claim 1, Huawei discloses a device comprising: a processor; (see Pg. 2 i.e., Discussion: the AP (access point) (i.e., AP includes a processor) to map different types of traffic to different TIDs), configured to: determine a mapping policy for one or more Low Latency data flows, (see Pg. 2 i.e., Comment section in the table i.e., low latency traffic & Resolution section in the table i.e., AP can announce a set of TIDs as low latency TIDs (i.e., “mapping policy”) & Pg. 2 i.e., Discussion: 802.11 defines a tool (QoS Map element) for the AP to map different types of traffic (i.e., different QoS requirement) to different TIDs. From AP’s perspective, different TIDs mean different latency requirement. Hence, the AP can indicate some of the TIDs to be latency sensitive TID (i.e., “mapping policy” for low latency traffic) for each rTWT agreement)
configure the mapping policy on a wireless device, (see Pg. 2 i.e., Resolution section in the table i.e., AP can announce a set of TIDs as low latency TIDs (i.e., mapping policy configured on the station STA) & Pg. 2 i.e., Discussion: 802.11 defines a tool (QoS Map element) for the AP to map different types of traffic (i.e., different QoS requirement) to different TIDs. From AP’s perspective, different TIDs mean different latency requirement. Hence, the AP can indicate some of the TIDs to be latency sensitive TID (i.e., “mapping policy”) for each rTWT agreement. STAs can only select from the announced set of TIDs when requesting to join an rTWT agreement)
receive a restricted Target Wake Time (rTWT) schedule from the wireless device, (see Pg. 2 i.e., AP can indicate some of the TIDs to be latency sensitive TID for each rTWT agreement (i.e., “schedule”) suggesting the corresponding rTWT agreement (i.e., “schedule”) is indicated to the AP…STAs can only select from the announced set of TIDs when requesting to join an rTWT agreement…the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure & Pg. 3 i.e., 35.8.2.2 The setup procedure i.e., An r-TWT agreement is established using TWT setup frames containing a broadcast TWT element that includes a restricted TWT Parameter Set field…TWT setup frame transmitted by rTWT scheduled STA)
receive a downlink low latency data flow associated with the wireless device, (see Pg. 2, Discussion i.e., latency sensitive traffic is communicated in the rTWT SP (service period), Pg. 3, the setup procedure i.e., (#5954) The r-TWT scheduled STA should indicate in the restricted TWT DL TID bitmap and restricted TWT UL TID bitmap subfields only the TIDs that are mapped to the link on which the r-TWT membership is being set up & Pg. 3 i.e., (#4767) i.e., The TIDs that are specified in the restricted TWT DL TID Bitmap subfield…are referred to as r-TWT DL TID(s) (i.e., r-TWT DL TID suggests a downlink low latency traffic flow with corresponding DL TID will be received by the station (i.e., wireless device) during rTWT)
and schedule the downlink low latency data flow based on the rTWT schedule, (see Pg. 2, Discussion i.e., latency sensitive traffic is scheduled for communication in the rTWT SP (service period)…the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure, Pg. 3, the setup procedure i.e., (#5954) The r-TWT scheduled STA should indicate in the restricted TWT DL TID bitmap and restricted TWT UL TID bitmap subfields only the TIDs that are mapped to the link on which the r-TWT membership is being set up & Pg. 3 i.e., (#4767) i.e., The TIDs that are specified in the restricted TWT DL TID Bitmap subfield…are referred to as r-TWT DL TID(s) (i.e., r-TWT DL TID suggests a downlink low latency traffic flow with corresponding DL TID will be scheduled for the station (i.e., wireless device) during rTWT)
While Huawei discloses the mapping policy is determined for communication of low latency data flows, Huawei does not disclose the low latency data flows are low latency, low loss, scalable throughput (L4s) data flows and the device comprising a processor; a memory communicatively coupled to the processor; and a traffic mapping logic. However the claim features would be rendered obvious in view of Millnert et al. US (2025/0016099).
Millnert discloses a device (see Fig. 2 i.e., network node 200a) comprising a processor (see Fig. 5 i.e., processing circuitry 210 & Para’s [0082-0084]); a memory communicatively coupled to the processor (see Fig. 5 i.e., storage medium 230 & Para’s [0082-0084]); and a traffic mapping logic (see Fig. 2 i.e., L4s controller & Para [0033-0034]) configured to: determine a mapping policy for one or more low latency, low loss, scalable throughput (L4s) data flows (see Para’s [0005], [0007] i.e., bearers dedicated for L4S traffic flows should have a higher scheduling priority compared to bearers serving MBB traffic flows, [0030], & [0032-0033] i.e., the bearer for user equipment 150a is for an L4S traffic flow…the L4s traffic flow has a higher priority in the scheduler 240 (i.e., “mapping policy” for L4s data flow))
Receive a downlink L4S data flow associated with a wireless device (see Fig. 2 i.e., incoming traffic flow 180a (i.e., L4S) received by device 200a from application server 170 & Para [0033] i.e., incoming traffic flow 180a from the application server 170 where traffic flow 180a represents an L4S traffic flow)
and schedule a downlink L4S data flow for reception by a wireless device (see Fig. 2 & Para [0033] i.e., the bearer for user equipment 150a is for an L4S traffic flow…the L4s traffic flow has a higher priority in the scheduler 240…the bearers can be used either for an uplink traffic flow or for a downlink traffic flow. In the context of Fig. 2, it is without loss of generality assumed that the bearers are used for a downlink traffic flow…scheduler provides two corresponding outgoing traffic flows 190a and 190b towards the user equipment 150a and 150b in the access network 110).
(Millnert suggests the L4S data flow has a higher priority in the scheduler 240 to achieve a consistent and low latency for the L4S traffic flow (see Para’s [0007] & [0033]) and the L4S data flow is communicated for reducing congestion in the network, (see Para’s [0003-0007] & [0033-0035])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the determined mapping policy for the one or more low latency data flows communicated between the wireless device and the access point during the rTWT schedule as disclosed in Huawei to be for a low latency data flow such as the low latency, low loss, scalable throughput (L4S) data flow scheduled for communication between the wireless device and the device comprising a processor; a memory communicatively coupled to the processor; and a traffic mapping logic configured to determine a mapping policy for scheduling the L4S data flow as disclosed in the teachings of Millnert, because the motivation lies in Millnert that the L4S data flow has a higher priority in the scheduler to achieve a consistent and low latency for the L4S traffic flow and the L4S data flow is communicated for reducing congestion in the network.
Regarding Claim 2, the combination of Huawei in view of Millnert discloses the device of claim 1, wherein the mapping policy is indicative of one or more User Priority (UP) values or one or more Traffic Identifier (TID) values associated with the one or more L4S data flows (Huawei, see Pg. 2, Discussion i.e., 802.11 defines a tool (QoS Map element) for the AP to map different types of traffic (i.e., different QoS requirement) to different TIDs. From AP’s perspective, different TIDs mean different latency requirement. Hence, the AP can indicate some of the TIDs to be latency sensitive TID (i.e., “mapping policy” for low latency traffic) for each rTWT agreement)
Regarding Claim 4, the combination of Huawei in view of Millnert discloses the device of claim 3, wherein the rTWT schedule is further indicative of one or more rTWT TID values of the one or more TID values associated with the one or more L4S data flows, (Huawei, see Pg. 2 i.e., the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure & Pg. 3 i.e., (#5954) i.e., TIDs that are mapped to the link on which the r-TWT membership is being set up)
Regarding Claim 5, the combination of Huawei in view of Millnert discloses the device of claim 4, wherein the rTWT schedule further includes a Quality of Service (QoS) Information Element (IE) indicative of one or more Quality of Service (QoS) parameters associated with the one or more L4S data flows, (Huawei, Discussion: 802.11 defines a tool (QoS Map element) for the AP to map different types of traffic (i.e., different QoS requirement) to different TIDs. From AP’s perspective, different TIDs mean different latency requirement. Hence, the AP can indicate some of the TIDs to be latency sensitive TID (i.e., “mapping policy”) for each rTWT agreement. STAs can only select from the announced set of TIDs when requesting to join an rTWT agreement).
Regarding Claim 10, the combination of Huawei in view of Millnert discloses the device of claim 4, wherein the wireless device maps an uplink L4S data flow to an rTWT TID value associated with the uplink L4S data flow based on the rTWT schedule, (Huawei, see Pg. 2, discussion i.e., the STA transmits traffic (i.e., uplink) in the rTWT SP…the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure & Pg. 3, (#5954) i.e., TWT UL TID bitmap subfield indicates TIDs that are mapped to the link on which the r-TWT membership is being set up)
Regarding Claim 18, Huawei discloses a method comprising: determining a mapping policy for one or more Low Latency data flows, (see Pg. 2 i.e., Comment section in the table i.e., low latency traffic & Resolution section in the table i.e., AP can announce a set of TIDs as low latency TIDs (i.e., “mapping policy”) & Pg. 2 i.e., Discussion: 802.11 defines a tool (QoS Map element) for the AP to map different types of traffic (i.e., different QoS requirement) to different TIDs. From AP’s perspective, different TIDs mean different latency requirement. Hence, the AP can indicate some of the TIDs to be latency sensitive TID (i.e., “mapping policy” for low latency traffic) for each rTWT agreement)
configuring the mapping policy on a wireless device, (see Pg. 2 i.e., Resolution section in the table i.e., AP can announce a set of TIDs as low latency TIDs (i.e., mapping policy configured on the station STA) & Pg. 2 i.e., Discussion: 802.11 defines a tool (QoS Map element) for the AP to map different types of traffic (i.e., different QoS requirement) to different TIDs. From AP’s perspective, different TIDs mean different latency requirement. Hence, the AP can indicate some of the TIDs to be latency sensitive TID (i.e., “mapping policy”) for each rTWT agreement. STAs can only select from the announced set of TIDs when requesting to join an rTWT agreement)
receiving a restricted Target Wake Time (rTWT) schedule from the wireless device, (see Pg. 2 i.e., AP can indicate some of the TIDs to be latency sensitive TID for each rTWT agreement (i.e., “schedule”) suggesting the corresponding rTWT agreement (i.e., “schedule”) is indicated to the AP…STAs can only select from the announced set of TIDs when requesting to join an rTWT agreement…the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure & Pg. 3 i.e., 35.8.2.2 The setup procedure i.e., An r-TWT agreement is established using TWT setup frames containing a broadcast TWT element that includes a restricted TWT Parameter Set field…TWT setup frame transmitted by rTWT scheduled STA)
receiving a downlink low latency data flow associated with the wireless device, (see Pg. 2, Discussion i.e., latency sensitive traffic is communicated in the rTWT SP (service period), Pg. 3, the setup procedure i.e., (#5954) The r-TWT scheduled STA should indicate in the restricted TWT DL TID bitmap and restricted TWT UL TID bitmap subfields only the TIDs that are mapped to the link on which the r-TWT membership is being set up & Pg. 3 i.e., (#4767) i.e., The TIDs that are specified in the restricted TWT DL TID Bitmap subfield…are referred to as r-TWT DL TID(s) (i.e., r-TWT DL TID suggests a downlink low latency traffic flow with corresponding DL TID will be received by the station (i.e., wireless device) during rTWT)
and scheduling the downlink low latency data flow based on the rTWT schedule, (see Pg. 2, Discussion i.e., latency sensitive traffic is scheduled for communication in the rTWT SP (service period)…the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure, Pg. 3, the setup procedure i.e., (#5954) The r-TWT scheduled STA should indicate in the restricted TWT DL TID bitmap and restricted TWT UL TID bitmap subfields only the TIDs that are mapped to the link on which the r-TWT membership is being set up & Pg. 3 i.e., (#4767) i.e., The TIDs that are specified in the restricted TWT DL TID Bitmap subfield…are referred to as r-TWT DL TID(s) (i.e., r-TWT DL TID suggests a downlink low latency traffic flow with corresponding DL TID will be scheduled for the station (i.e., wireless device) during rTWT)
While Huawei discloses the mapping policy is determined for communication of low latency data flows, Huawei does not disclose the low latency data flows are low latency, low loss, scalable throughput (L4s) data flows and the device comprising a processor; a memory communicatively coupled to the processor; and a traffic mapping logic. However the claim features would be rendered obvious in view of Millnert et al. US (2025/0016099).
Millnert discloses a device (see Fig. 2 i.e., network node 200a) comprising a processor (see Fig. 5 i.e., processing circuitry 210 & Para’s [0082-0084]); a memory communicatively coupled to the processor (see Fig. 5 i.e., storage medium 230 & Para’s [0082-0084]); and a traffic mapping logic (see Fig. 2 i.e., L4s controller & Para [0033-0034]) configured to: determine a mapping policy for one or more low latency, low loss, scalable throughput (L4s) data flows (see Para’s [0005], [0007] i.e., bearers dedicated for L4S traffic flows should have a higher scheduling priority compared to bearers serving MBB traffic flows, [0030], & [0032-0033] i.e., the bearer for user equipment 150a is for an L4S traffic flow…the L4s traffic flow has a higher priority in the scheduler 240 (i.e., “mapping policy” for L4s data flow))
Receive a downlink L4S data flow associated with a wireless device (see Fig. 2 i.e., incoming traffic flow 180a (i.e., L4S) received by device 200a from application server 170 & Para [0033] i.e., incoming traffic flow 180a from the application server 170 where traffic flow 180a represents an L4S traffic flow)
and schedule a downlink L4S data flow for reception by a wireless device (see Fig. 2 & Para [0033] i.e., the bearer for user equipment 150a is for an L4S traffic flow…the L4s traffic flow has a higher priority in the scheduler 240…the bearers can be used either for an uplink traffic flow or for a downlink traffic flow. In the context of Fig. 2, it is without loss of generality assumed that the bearers are used for a downlink traffic flow…scheduler provides two corresponding outgoing traffic flows 190a and 190b towards the user equipment 150a and 150b in the access network 110).
(Millnert suggests the L4S data flow has a higher priority in the scheduler 240 to achieve a consistent and low latency for the L4S traffic flow (see Para’s [0007] & [0033]) and the L4S data flow is communicated for reducing congestion in the network, (see Para’s [0003-0007] & [0033-0035])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the determined mapping policy for the one or more low latency data flows communicated between the wireless device and the access point during the rTWT schedule as disclosed in Huawei to be for a low latency data flow such as the low latency, low loss, scalable throughput (L4S) data flow scheduled for communication between the wireless device and the device comprising a processor; a memory communicatively coupled to the processor; and a traffic mapping logic configured to determine a mapping policy for scheduling the L4S data flow as disclosed in the teachings of Millnert, because the motivation lies in Millnert that the L4S data flow has a higher priority in the scheduler to achieve a consistent and low latency for the L4S traffic flow and the L4S data flow is communicated for reducing congestion in the network.
Regarding Claim 19, the combination of Huawei in view of Millnert discloses the method of claim 18, further comprising: determining an rTWT Traffic Identifier (rTWT TID) value associated with the downlink L4S data flow based on the rTWT schedule; (Huawei, see Pg. 2 i.e., the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure & Pg. 3 i.e., (#5954) i.e., restricted TWT DL TID bitmap (i.e., TWT DL TID suggests downlink data flow)…TIDs that are mapped to the link on which the r-TWT membership is being set up)
mapping the downlink L4S data flow to the rTWT TID value; (Huawei, see Pg. 2 discussion i.e., different types of traffic are mapped to different TIDs, Pg. 3 i.e., (#5954) i.e., TIDs that are mapped to the link on which the r-TWT membership is being set up, & Pg. 3 i.e., (#4767) i.e., r-TWT DL TIDs suggests the downlink flows are mapped to the rTWT TID)
determining a service period based on the rTWT schedule; (see Huawei Pg. 2, Discussion i.e., rTWT SP (i.e., “service period”) used to transmit the traffic & Pg. 3 i.e., setup procedure for rTWT),
and transmitting the downlink L4S data flow to the wireless device during the service period, (see Pg. 2 i.e., traffic is communicated during the SP (service period) & Pg. 3 i.e., (#5954) i.e., TIDs that are mapped to the link on which the r-TWT membership is being set up, & Pg. 3 i.e., (#4767) i.e., r-TWT DL TIDs suggests the downlink traffic flows mapped to the rTWT TID are communicated according to the QoS requirements of the mapping policy)
Regarding Claim 20, Huawei discloses the device of claim 8, wherein the traffic mapping logic is further configured to: receive a non-L4S data flow corresponding to the rTWT TID value, (Huawei, see Pg. 2, discussion i.e., AP to map different types of traffic (i.e., different QoS requirements) to different TIDs. From AP’s perspective different TIDs mean different latency requirements…the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure (i.e., a type of traffic mapped to a rTWT TID may be for a non-L4S data traffic flow) & Pg. 3 i.e., (#5954) the r-TWT scheduled STA should indicate in the restricted TWT DL TID bitmap…only the TIDs (i.e., may include TID mapped to a non-L4S data flow) that are mapped to the link on which the r-TWT membership is being set up), but does not disclose the claim features of and assign a higher UP value to the downlink L4S data flow and a lower UP value to the non-L4S data flow based on the mapping policy. However the claim features would be rendered obvious in view of Millnert et al. US (2025/0016099).
Millnert discloses assign a higher user priority value to the downlink L4S data flow and a lower user priority value to the non-L4S data flow based on a mapping policy (see Fig. 2 i.e., downlink L4S data flow 180a and non-L4S data flow 180b & Para’s [0030] i.e., the bearer for the L4S traffic has a higher priority compared to the bearer of the MBB traffic (i.e., “mapping policy”) & [0033] i.e., the bearer for user equipment 150 is for an L4S traffic flow and the bearer for user equipment 150b is for a non-L4S traffic flow, such as an MBB traffic flow…to achieve a consistent and low latency for the L4S traffic flow, the L4S traffic flow has a higher priority in the scheduler 240 than the non-L4S traffic flow (i.e., “mapping policy”))
(Millnert suggests to achieve a consistent and low latency for the L4S traffic flow, the L4S traffic flow has a higher priority in the scheduler 240 than the non-L4S traffic flow (see Para [0033])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date the scheduling of the low latency data flows as disclosed in Huawei in view of LI to include assigning a higher user priority value to the downlink L4S data flow and a lower user priority value to the non-L4S data flow based on the mapping policy as disclosed in Millnert, because the motivation lies in Millnert that the L4S traffic flow has a higher priority than the non-L4S traffic flow in order to achieve a consistent and low latency for the L4S traffic flow.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Yuchen Guo, Huawei technologies, “CR for RTWT TID Selection Rules”, IEEE 802.11-22/0514r0 referred to herein as “Huawei” in view of Millnert et al. US (2025/0016099) as applied to claim 2 above, and further in view of Kishida et al. US (2025/0374322).
Regarding Claim 3, the combination of Huawei in view of Millnert discloses the device of claim 2, including wherein the rTWT schedule is indicative of at least one service period in which the wireless device transmits or receives the one or more L4S data flows (see Huawei Pg. 2, Discussion i.e., rTWT SP (i.e., “service period”) used to transmit the traffic), but does not disclose the at least one service period occurring at one or more service intervals. However the claim feature would be rendered obvious in view of Kishida et al. US (2025/0374322).
Kishida discloses the service period of an rTWT schedule occurring at one or more service intervals (see Fig. 12 & Para’s [0067-0068] i.e., rTWT function, for example, rTWT start time, rTWT cycle, and rTWT duration are set as the parameters related to the rTWT function…The rTWT cycle corresponds to the cycle of the rTWT-SP and is also referred to as “rTWT interval”).
(Kishida suggests the parameters related to rTWT function for configuring the service period are used for supporting traffic of low latency (see Fig. 12 & Para’s [0067-0068])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the at least one service period of the rTWT schedule in which the wireless device transmits or receives the one or more L4S data flows as disclosed in Huawei in view of Millnert to occur at the one or more service intervals such as the rTWT interval as disclosed in the teachings of Kishida, because the motivation lies in Kishida that the parameters related to rTWT function for configuring the service period are used for supporting traffic of low latency.
Claims 6-9 are rejected under 35 U.S.C. 103 as being unpatentable over Yuchen Guo, Huawei technologies, “CR for RTWT TID Selection Rules”, IEEE 802.11-22/0514r0 referred to herein as “Huawei” in view of Millnert et al. US (2025/0016099) as applied to claim 5 above, and further in view of LI US (2025/0071656).
Regarding Claim 6, the combination of Huawei in view of Millnert discloses the device of claim 5, but does not disclose the claim feature of wherein the traffic mapping logic is further configured to receive, from the wireless device, a Stream Classification Service (SCS) request indicative of the one or more QoS parameters associated with the one or more L4S data flows. However the claim feature would be rendered obvious in view of LI US (2025/0071656).
LI discloses wherein an access point (AP) is further configured to receive, from a wireless device, a Stream Classification Service (SCS) request indicative of the one or more QoS parameters associated with one or more low latency data flows (see Fig. 4 i.e., SCS request including i.e., SCSID, CLAS, QoS feature, latency range received by AP from STA & Para’s [0048-0052] i.e., the STA sends a Stream Classification Service request (SCS request) including SCSID used as an identifier of low delay (i.e., “low latency data flow”), a CLAS, in a subsequent downlink stream will be transmitted according to requirements of a QoS feature: the QoS feature contains requirements for a stream (i.e., “QoS parameters”), a delay bound limits a transmission delay of a stream (i.e., suggests a “low latency data flow”)).
(LI suggests a suggests an AP transmits a subsequent downlink stream according to the requirements of the QoS feature included in the SCS request for satisfying the QoS requirements and transmission delay of the low latency downlink stream, (see Fig. 4 & Para’s [0048-0052])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the traffic mapping logic of the AP which schedules the downlink L4S data flow as disclosed in Huawei in view of Millnert to be scheduled by receiving, from a wireless device, a Stream Classification Service (SCS) request indicative of the one or more QoS parameters associated with the one or more low latency data flows as disclosed in the teachings of LI who discloses wherein an access point (AP) is further configured to receive, from a wireless device, a Stream Classification Service (SCS) request indicative of one or more QoS parameters associated with one or more low latency data flows, because the motivation lies in LI that the AP transmits a subsequent downlink stream according to the requirements of the QoS feature included in the SCS request for satisfying the QoS requirements and transmission delay of the low latency downlink stream.
Regarding Claim 7, the combination of Huawei in view of Millnert, and further in view of LI discloses the device of claim 6, wherein scheduling the downlink L4S data flow comprises: determining an rTWT TID value associated with the downlink L4S data flow based on the rTWT schedule, (Huawei, see Pg. 2 Discussion i.e., the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure & Pg. 3 i.e., (#5954) i.e., the r-TWT scheduled STA should indicate in the restricted TWT DL TID bitmap only the TIDs that are mapped to the link on which the r-TWT membership is being set up & Pg. 3 i.e., (#4767) i.e., r-TWT DL TIDs)
and mapping the downlink L4S data flow to the rTWT TID value, (Huawei, see Pg. 2 discussion i.e., different types of traffic are mapped to different TIDs, Pg. 3 i.e., (#5954) i.e., TIDs that are mapped to the link on which the r-TWT membership is being set up, & Pg. 3 i.e., (#4767) i.e., r-TWT DL TIDs suggests the downlink flows are mapped to the rTWT TID)
Regarding Claim 8, the combination of Huawei in view of Millnert, and further in view of LI discloses the device of claim 7, wherein scheduling the downlink L4S data flow further comprises: determining the one or more QoS parameters associated with the downlink L4S data flow based on the SCS request or the QoS IE in the rTWT schedule (Huawei, see Pg. 2, discussion i.e., QoS Map element for the AP to map different types of traffic (i.e., different QoS requirements) to different TIDs…different TIDs mean different latency requirement…latency sensitive TIDs are used for a rTWT agreement & Pg. 3, (#4767) i.e., r-TWT DL TID(s) suggests the downlink traffic flows are communicated according to the QoS requirements mapped to the TID based on the mapping policy); and transmitting the downlink L4S data flow mapped to the rTWT TID value to the wireless device during the at least one service period based on the one or more QoS parameters, (see Pg. 2 i.e., traffic is communicated during the SP (service period) & Pg. 3 i.e., (#5954) i.e., TIDs that are mapped to the link on which the r-TWT membership is being set up, & Pg. 3 i.e., (#4767) i.e., r-TWT DL TIDs suggests the downlink traffic flows mapped to the rTWT TID are communicated according to the QoS requirements of the mapping policy)
Regarding Claim 9, the combination of Huawei in view of LI discloses the device of claim 8, wherein the traffic mapping logic is further configured to: receive a non-L4S data flow mapped to the rTWT TID value, (Huawei, see Pg. 2, discussion i.e., AP to map different types of traffic (i.e., different QoS requirements) to different TIDs. From AP’s perspective different TIDs mean different latency requirements…the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure (i.e., a type of traffic mapped to a rTWT TID may be for a non-L4S data traffic flow) & Pg. 3 i.e., (#5954) the r-TWT scheduled STA should indicate in the restricted TWT DL TID bitmap…only the TIDs (i.e., may include TID mapped to a non-L4S data flow) that are mapped to the link on which the r-TWT membership is being set up), but does not disclose the claim features of and assign a higher priority for scheduling the downlink L4S data flow and a lower priority for scheduling the non-L4S data flow based on the mapping policy. However the claim features would be rendered obvious in view of Millnert et al. US (2025/0016099).
Millnert discloses assign a higher priority for scheduling the downlink L4S data flow and a lower priority for scheduling the non-L4S data flow based on a mapping policy (see Fig. 2 i.e., downlink L4S data flow 180a and non-L4S data flow 180b & Para’s [0030] i.e., the bearer for the L4S traffic has a higher priority compared to the bearer of the MBB traffic (i.e., “mapping policy”) & [0033] i.e., the bearer for user equipment 150 is for an L4S traffic flow and the bearer for user equipment 150b is for a non-L4S traffic flow, such as an MBB traffic flow…to achieve a consistent and low latency for the L4S traffic flow, the L4S traffic flow has a higher priority in the scheduler 240 than the non-L4S traffic flow (i.e., “mapping policy”))
(Millnert suggests to achieve a consistent and low latency for the L4S traffic flow, the L4S traffic flow has a higher priority in the scheduler 240 than the non-L4S traffic flow (see Para [0033])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date the scheduling of the low latency data flows as disclosed in Huawei in view of LI to include assigning a higher priority for scheduling the downlink L4S data flow and a lower priority for scheduling the non-L4S data flow based on the mapping policy as disclosed in Millnert, because the motivation lies in Millnert that the L4S traffic flow has a higher priority in the scheduler than the non-L4S traffic flow in order to achieve a consistent and low latency for the L4S traffic flow.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Yuchen Guo, Huawei technologies, “CR for RTWT TID Selection Rules”, IEEE 802.11-22/0514r0 referred to herein as “Huawei” in view of Millnert et al. US (2025/0016099) as applied to claim 4 above, and further in view of Nadas et al. US (2024/0056401).
Regarding Claim 11, the combination of Huawei in view of Millnert discloses the device of claim 4, but does not disclose wherein the mapping policy is an enhanced Differentiated Services Code Point (DSCP) policy. However the claim feature would be rendered obvious in view of Nadas et al. US (2024/0056401).
Nadas discloses wherein a mapping policy is an enhanced Differentiated Services Code Point (DSCP) policy (see Para’s [0009] i.e., assigning each of the packets to either a L4S queue or a non-L4S queue & [0069] i.e., The traffic class (L4S or classic) was encoded into the Differentiated Services Code Point (DSCP) field (i.e., mapping policy such as a DSCP policy mapping L4S traffic flow to DSCP value))
(Nadas suggests the L4S traffic flows are scheduled for ensuring QoS of the L4S traffic according to the L4S and its associated DSCP (see Para’s [0009], [0038], & [0069])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the mapping policy for the L4S data flow as disclosed in Huawei in view of Millnert to be an enhanced Differentiated Services Code Point (DSCP) policy based on the teachings of Nadas who discloses wherein a mapping policy is an enhanced Differentiated Services Code Point (DSCP) policy based on mapping L4S traffic to a corresponding DSCP, because the motivation lies in Nadas that the L4S traffic flows are scheduled for ensuring QoS of the L4S traffic according to the L4S and its associated DSCP.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Yuchen Guo, Huawei technologies, “CR for RTWT TID Selection Rules”, IEEE 802.11-22/0514r0 referred to herein as “Huawei” in view of Millnert et al. US (2025/0016099), and further in view of Nadas et al. US (2024/0056401) as applied to claim 11 above, and further in view of Venkatesan et al. US (2022/0330099).
Regarding Claim 12, the combination of Huawei in view of Millnert, and further in view of Nadas discloses the device of claim 11, but does not disclose the claim features of wherein the traffic mapping logic is further configured to: transmit, to the wireless device, an enhanced DSCP policy request indicative of the mapping policy for the L4S data flow; and receive, from the wireless device, an enhanced DSCP policy response indicative of acceptance of the mapping policy for the L4S data flow. However the claim features would be rendered obvious in view of Venkatesan et al. US (2022/0330099).
Venkatesan wherein the traffic mapping logic is further configured to: transmit, to the wireless device (see Fig. 9 i.e., STA 904), an enhanced DSCP policy request indicative of the mapping policy for a QoS data flow; (see Fig. 9 i.e., QoS Mgmt Policy Request 918 sent from AP 902 to STA 904 & Para [0123] i.e., The QoS Mgmt AP 902 responds with a QoS Mgmt Policy Request frame…The QoS Mgmt STA 904 responds with a QoS Mgmt Policy Response 920 which may have…a status indicating whether the QoS Mgmt STA 904 has accepted the QoS policy or will conform to the policy)
and receive, from the wireless device (see Fig. 9 i.e., STA 904), an enhanced DSCP policy response indicative of acceptance of the mapping policy for a QoS data flow (see Fig. 9 i.e., QoS Mgmt Policy Response 920 sent from STA 904 to AP 902 & Para’s [0093-0094], [0098], [0123] i.e., The QoS Mgmt AP 902 responds with a QoS Mgmt Policy Request frame…The QoS Mgmt STA 904 responds with a QoS Mgmt Policy Response 920 which may have…a status indicating whether the QoS Mgmt STA 904 has accepted the QoS policy or will conform to the policy & [0134])
(Venkatesan suggests policy request and policy response is communicated between the STA and the AP for negotiating the QoS policy between stations and APs for satisfying the QoS of the traffic flow based on prioritizing the packets according to the determined QoS policy (see Para’s [0001], [0123], & [0134])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the QoS mapping policy such as the DSCP policy as disclosed in Huawei in view of Millnert, and further in view of Nadas to be indicated to the station based on the DSCP policy request and DSCP policy response communicated between the STA and AP as disclosed in Venkatesan, because the motivation lies in Venkatesan, that the DSCP policy request and DSCP policy response is communicated between the STA and the AP for negotiating the QoS policy between stations and APs for satisfying the QoS of the traffic flow based on prioritizing the packets according to the determined QoS policy.
Claims 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over Jason Yuchen Guo, Huawei technologies, “CR for RTWT TID Selection Rules”, IEEE 802.11-22/0514r0 referred to herein as “Huawei” in view of Millnert et al. US (2025/0016099), and further in view of Kishida et al. US (2025/0374322).
Regarding Claim 13, Huawei discloses a device (see Pg. 2, Discussion i.e., station STA), comprising: a processor (see Pg. 2 i.e., STA includes a processor); a memory communicatively coupled to the processor; and a traffic mapping logic, configured to: receive a mapping policy for one or more Low Latency data flows; (see Pg. 2 i.e., Comment section in the table i.e., low latency traffic & Resolution section in the table i.e., AP can announce a set of TIDs as low latency TIDs (i.e., “mapping policy”) & Pg. 2 i.e., Discussion: 802.11 defines a tool (QoS Map element) for the AP to map different types of traffic (i.e., different QoS requirement) to different TIDs. From AP’s perspective, different TIDs mean different latency requirement. Hence, the AP can indicate some of the TIDs to be latency sensitive TID (i.e., “mapping policy” for low latency traffic) for each rTWT agreement)
determine a service period for transmission or reception of the one or more low latency data flows; (see Pg. 2, Discussion i.e., latency sensitive traffic is transmitted in a determined rTWT SP (service period)…STAs can only select from the announced set of TIDs when requesting to join an rTWT agreement (i.e., includes rTWT SP)…the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure, Pg. 3, the setup procedure i.e., (#5954) The r-TWT scheduled STA should indicate in the restricted TWT DL TID bitmap and restricted TWT UL TID bitmap subfields only the TIDs that are mapped to the link on which the r-TWT membership is being set up & Pg. 3 i.e., (#4767) i.e., r-TWT DL TIDs or r-TWT UL TIDs for transmission or reception of the one or more low latency data flows)
generate a restricted Target Wake Time (rTWT) schedule indicative of the service period based on the mapping policy; (see Pg. 2 i.e., Discussion: 802.11 defines a tool (QoS Map element) for the AP to map different types of traffic (i.e., different QoS requirement) to different TIDs. From AP’s perspective, different TIDs mean different latency requirement. Hence, the AP can indicate some of the TIDs to be latency sensitive TID (i.e., “mapping policy”) for each rTWT agreement. STAs can only select from the announced set of TIDs when requesting to join an rTWT agreement (i.e., “rTWT schedule”)…rTWT SP is used to transmit traffic…the STA can indicate all TIDs to be rTWT TIDs during rTWT setup procedure (i.e., a rTWT schedule including the service period is generated based on the rTWT setup procedure for performing communication of the data traffic flow according to the received mapping policy) & Pg. 3 i.e., the setup procedure)
and transmit an uplink low latency data flow during the service period based on the rTWT schedule, (see Pg. 2 Discussion i.e., rTWT SP is used by the STA to transmit the low latency traffic based on latency sensitive TID selection & Pg. 3 i.e., (#4767) i.e., The TIDs that are specified in the restricted TWT UL TID Bitmap subfield…are referred to as r-TWT UL TID(s) (i.e., r-TWT UL TID suggests an uplink low latency traffic flow transmitted by the station (i.e., device) during rTWT SP).
While Huawei discloses the mapping policy is determined for communication of low latency data flows (see Pg. 2), Huawei does not disclose the low latency data flows are low latency, low loss, scalable throughput (L4s) data flows and the device comprising a processor; a memory communicatively coupled to the processor; and a traffic mapping logic. However the claim features would be rendered obvious in view of Millnert et al. US (2025/0016099).
Millnert discloses a device (see Fig. 2 i.e., UE 150) comprising a processor (see Fig. 5 i.e., processing circuitry 210 & Para’s [0082-0084]); a memory communicatively coupled to the processor (see Fig. 5 i.e., storage medium 230 & Para’s [0082-0084]); and a traffic mapping logic (see Fig. 1 i.e., 200b & Fig. 5 i.e., 200b & Para [0042] & [0082-0084]) configured to: transmit one or more uplink low latency, low loss, scalable throughput (L4s) data flows based on a mapping policy (see Para’s [0005], [0007] i.e., bearers dedicated for L4S traffic flows should have a higher scheduling priority compared to bearers serving MBB traffic flows, [0030], & [0032-0033] i.e., the bearer for user equipment 150a is for an L4S traffic flow…the L4s traffic flow has a higher priority in the scheduler 240 (i.e., “mapping policy” for L4s data flow)…the bearers can be used for an uplink traffic flow or for a downlink traffic flow)
(Millnert suggests the L4S data flow has a higher priority in the scheduler 240 to achieve a consistent and low latency for the L4S traffic flow (see Para’s [0007] & [0033]) and the L4S data flow is communicated for reducing congestion in the network, (see Para’s [0003-0007] & [0033-0035])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the determined mapping policy for the one or more low latency data flows communicated between the wireless device and the access point during the rTWT schedule as disclosed in Huawei to be for a low latency data flow such as the low latency, low loss, scalable throughput (L4S) data flow scheduled for uplink communication between the wireless device comprising a processor; a memory communicatively coupled to the processor; and a traffic mapping logic and a device as disclosed in the teachings of Millnert, because the motivation lies in Millnert that the L4S data flow has a higher priority in the scheduler to achieve a consistent and low latency for the L4S traffic flow and the L4S data flow is communicated for reducing congestion in the network.
While Huawei discloses a rTWT schedule including a service period (SP) for communication of the L4S data flow (Huawei, see Pg. 2, Discussion i.e., rTWT SP & Pg. 3 i.e., setup procedure), the combination of Huawei in view of Millner does not disclose the claim features of determining a service interval for the transmission or reception of the one or more L4S data flows and the generated rTWT schedule indicative of the service interval. However the claim features would be rendered obvious in view of Kishida et al. US (2025/0374322).
Kishida determining a service interval and a service period for the transmission or reception of one or more low latency data flows (see Fig. 12 & Para’s [0038] i.e., rTWT service period (SP), [0066] i.e., Data exchange between the AP 10 and the terminal 20 in the rTWT-SP is performed, [0067] i.e., In the setup of the rTWT function, for example, rTWT start time, rTWT cycle, and rTWT duration are set as the parameters related to the rTWT function. The rTWT start time corresponds to the time at the start of the rTWT-SP. The rTWT cycle corresponds to the cycle of the rTWT-SP and is also referred to as “rTWT interval” (i.e., “service interval”))
and the generated rTWT schedule indicative of the service interval and the service period (see Fig. 12 & Para’s [0038] i.e., rTWT service period (SP), [0066] i.e., Data exchange between the AP 10 and the terminal 20 in the rTWT-SP is performed, [0067] i.e., In the setup of the rTWT function (i.e., “rTWT schedule”), for example, rTWT start time, rTWT cycle, and rTWT duration are set as the parameters related to the rTWT function (i.e., “rTWT schedule”). The rTWT start time corresponds to the time at the start of the rTWT-SP. The rTWT cycle corresponds to the cycle of the rTWT-SP and is also referred to as “rTWT interval” (i.e., “service interval”))
transmitting the uplink low latency data flow during the service period based on the rTWT schedule (see Para’s [0038] & [0066-0068])
(Kishida suggests the parameters related to rTWT function are used for configuring the service period and the service interval in order to efficiently perform communication of uplink low latency traffic of the terminal, (see Fig. 12 & Para’s [0038] & [0066-0068])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the rTWT schedule used for transmitting the uplink L4S data flow as disclosed in Huawei in view of Millner to include a service interval and a service period for the transmission or reception of the one or more L4s data flows based on the teachings of Kishida who discloses a rTWT schedule includes a determined service interval and a service period for the transmission or reception of one or more low latency data flows, because the motivation lies in Kishida that the parameters related to rTWT function are used for configuring the service period and the service interval in order to efficiently perform communication of uplink low latency traffic of the terminal.
Regarding Claim 14, the combination of Huawei in view of Millner, and further in view of Kishida discloses the device of claim 13, wherein the mapping policy is indicative of one or more User Priority (UP) values or one or more Traffic Identifier (TID) values associated with the one or more L4S data flows. (Huawei, see Pg. 2, Discussion i.e., 802.11 defines a tool (QoS Map element) for the AP to map different types of traffic (i.e., different QoS requirement) to different TIDs. From AP’s perspective, different TIDs mean different latency requirement. Hence, the AP can indicate some of the TIDs to be latency sensitive TID (i.e., “mapping policy” for low latency traffic) for each rTWT agreement)
Regarding Claim 15, the combination of Huawei in view of Millner, and further in view of Kishida discloses the device of claim 14, wherein the rTWT schedule is further indicative of one or more rTWT TID values of the one or more TID values associated with the one or more L4S data flows, (Huawei, see Pg. 2 i.e., the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure & Pg. 3 i.e., (#5954) i.e., TIDs that are mapped to the link on which the r-TWT membership is being set up)
Regarding Claim 16, the combination of Huawei in view of Millner, and further in view of Kishida discloses the device of claim 15, wherein transmitting the uplink L4S data flow comprises: determining an rTWT TID value associated with the uplink L4S data flow based on the rTWT schedule, (Huawei, see Pg. 2 Discussion i.e., the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure & Pg. 3 i.e., (#5954) i.e., the r-TWT scheduled STA should indicate in the restricted TWT UL TID bitmap only the TIDs that are mapped to the link on which the r-TWT membership is being set up & Pg. 3 i.e., (#4767) i.e., r-TWT UL TIDs)
and mapping the uplink L4S data flow to the rTWT TID value, (Huawei, see Pg. 2 discussion i.e., different types of traffic are mapped to different TIDs, Pg. 3 i.e., (#5954) i.e., TIDs that are mapped to the link on which the r-TWT membership is being set up, & Pg. 3 i.e., (#4767) i.e., r-TWT UL TIDs suggests the uplink flows are mapped to the rTWT TID)
Regarding Claim 17, the combination of Huawei in view of Millner, and further in view of Kishida discloses the device of claim 16, wherein transmitting the uplink L4S data flow comprises mapping the uplink L4S data flow to a predetermined rTWT TID value. (Huawei, see Pg. 2, discussion i.e., different types of traffic (e.g., different QoS requirement) are mapped to different TIDs (i.e., a traffic flow is associated with a predetermined rTWT TID value)…the STA transmits traffic (i.e., uplink) in the rTWT SP…the STA can indicate all TIDs to be rTWT TIDs during the rTWT setup procedure & Pg. 3, (#5954) i.e., TWT UL TID bitmap subfield indicates TIDs that are mapped to the link on which the r-TWT membership is being set up)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADNAN A BAIG whose telephone number is (571)270-7511. The examiner can normally be reached M-F 9:00am-5: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, Huy Vu can be reached at 571-272-3155. 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.
/ADNAN BAIG/Primary Examiner, Art Unit 2461
Prosecution Insights