DETAILED ACTION
Status of the Claims
Claims 1–30 are pending. Claims 1–5, 11–17, 19, 23, and 29 are amended. No claims are added or canceled. This Office action is in response to Applicant’s request for reconsideration after non-final rejection filed on 4/3/2026. Claims 1–30 are rejected as set forth below.
Other Prior Art
RFC 3168, RFC 9330, and RFC 9331 disclose Explicit Congestion Notification (ECN) signaling and the use of ECN signaling in the context of Low Latency, Low Loss, and Scalable Throughput (L4S) (RFC 9330, section 1).
Response to Arguments
The arguments of Applicant’s representative filed 4/3/2026 have been fully considered.
Rejection of Claims 1, 11, 16, and 23 under 35 U.S.C. § 103 over Henry and Wang.
Claims 1, 11, 16, and 23 were amended to recite that the L4S request frame is a Mirrored Stream Classification Service (MSCS) w/L4S request frame, that the L4S descriptor is included in the request as an L4S descriptor element that includes an element ID, and that the L4S congestion buffer threshold is an Explicit Congestion Notification (ECN) threshold indicated in the request frame. Applicant’s representative argues that the combination of Henry and Wang does not teach claims 1, 11, 16, and 23, as amended. Examiner agrees. Nonetheless, the combination of Henry, IEEE, Zuniga, and Patil teaches amended claim 1, as discussed in the rejection below.
Claim Rejections — 35 U.S.C. § 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–15 are rejected under 35 U.S.C. § 103 as being unpatentable over Henry (US 2025/0202827; “Henry”) in view of the non-patent literature entitled “IEEE Std 802.11 — 2020” (“IEEE”), Zuniga (US 2025/0158926; “Zuniga”), and Patil (US 2025/0106680; “Patil”).
Regarding claims 1 and 11, Henry teaches a method of operating an access point (AP), the method comprising: receiving at the access point a Low Latency, Low Loss, and Scalable Throughput (L4S) request frame from a first station (STA), the L4S request frame including an L4S descriptor. Henry teaches that an L4S enabled wireless device (STA) transmits an augmented Stream Classification Service (SCS) request frame to the access point, which the access point receives, the augmented SCS request frame being indicative of a request that an upstream data flow be classified as L4S; the augmented SCS request frame includes an L4S descriptor comprising an L4S indicator, in the form of a field such as a one-bit field set by the wireless device to request that the upstream data flow be classified as L4S, and a QoS Characteristics Element indicative of one or more flow characteristics, such as bandwidth requirements and latency constraints, of the requested L4S flow ([0041], [0065], [0090]; figs. 2, 8).
Henry teaches operating the access point to create an L4S classifier filter corresponding to the first STA, said L4S classifier filter distinguishing between Media Access Control (MAC) Service Data Units (MSDUs) which communicate L4S data and MSDUs which communicate non L4S data. Henry teaches that an access point 120 includes a classifier 122 that classifies incoming data flows as L4S or non-L4S and directs them to an L4S queue 126 or a classic queue 128, the classifier corresponding to the flow associated with the requesting wireless device ([0058]; figs. 1, 8), and that the access point creates the classifier for downstream traffic directed to the wireless device by detecting the ECN indicator in a downstream data packet of the downstream data flow and matching the downstream data flow to a corresponding upstream data flow, so that the downstream MSDUs directed to the wireless device are distinguished as L4S or non-L4S ([0086]–[0087]).
Henry teaches operating the access point to use the L4S classifier filter to determine if an MSDU directed to the first station communicates data to be treated as L4S data or communicates non-L4S data. Henry teaches that the access point parses the data packets and treats the data flow as L4S or classifies it as non-L4S based on the classifier ([0062]; fig. 8, blocks 830, 840, 860), and, with respect to traffic directed to the wireless device, classifies the downstream data flow as L4S or non-L4S based on the downstream-to-upstream flow matching ([0086]–[0087]).
Henry teaches storing the MSDU in a transmission queue corresponding to the type of data being communicated by the MSDU, said step of storing the MSDU in a transmission queue corresponding to the type of data being communicated by the MSDU including storing MSDUs which communicate L4S data in an L4S transmission queue, said L4S transmission queue being an L4S data buffer. Henry teaches that the access point implements a dual queue and enqueues the upstream L4S data flow in an L4S queue 126, which can be an Active Queue Management (AQM) queue, and stores non-L4S traffic in a classic queue 128 ([0061], [0078]; fig. 8, block 850).
However, Henry does not teach that the L4S request frame is a Mirrored Stream Classification Service (MSCS) w/L4S request frame, that the L4S descriptor is included in the request as an L4S descriptor element, or that the L4S descriptor element includes an element ID. Nonetheless, IEEE teaches the Mirrored Stream Classification Service (MSCS), wherein a non-AP STA requests mirrored stream classification by sending an MSCS Request frame to the AP with which the STA is associated (pg. 706, lines 35–36). IEEE further teaches that the MSCS Request frame includes an MSCS Descriptor element (pg. 1567, line 31), and that the MSCS Descriptor element includes an Element ID, a Length, an Element ID Extension, a Request Type, a User Priority Control, a Stream Timeout, optional TCLAS Mask Elements, and an Optional Subelements field (pg. 1399, lines 49–65; fig. 9-782). IEEE further teaches that the Optional Subelements field of the MSCS Descriptor element contains zero or more subelements, each identified by a subelement ID, the subelements allowed in the MSCS Descriptor element being defined in Table 9-322, including a Vendor subelement having subelement ID 221 (pg. 1400, lines 50–53, 55–67; table 9-322). A subelement nested within the MSCS Descriptor element thus constitutes an L4S descriptor element that includes an element ID, namely the subelement ID identifying that subelement.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Henry so that the access point receives the L4S classification request as an MSCS Request frame including an MSCS Descriptor element carrying Henry’s L4S descriptor within a subelement nested in the Optional Subelements field, the nested subelement constituting an L4S descriptor element that includes an element ID (e.g., the Vendor subelement having subelement ID 221), as taught by IEEE, because doing so would have allowed the station to request Henry’s L4S classification treatment using the existing standardized 802.11 MSCS request mechanism and its established subelement-nesting conventions, Henry expressly providing that its L4S signaling may utilize any 802.11 frame structure and that its elements are interchangeable with other 802.11 elements ([0067], [0070]).
Furthermore, Henry as modified by IEEE does not teach checking if the amount of data in the L4S data buffer exceeds the congestion buffer threshold. Nonetheless, Zuniga teaches an access point that configures an L4S queue 210 with a first threshold 214 and a second threshold 216, checks whether the latency sensitive traffic 212 in the L4S queue 210 has crossed above the threshold ([0029]–[0030]; fig. 3).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Henry and IEEE so that the access point checks whether the amount of data in the L4S data buffer exceeds an L4S congestion buffer threshold, as taught by Zuniga, because doing so would have provided a concrete, well-defined queue-occupancy criterion for determining when the L4S buffer is congested, in place of an unspecified network-condition determination.
Lastly, Henry, IEEE, and Zuniga do not teach that the L4S congestion buffer threshold checked by the access point is indicated in said MSCS w/L4S request frame, the threshold being an Explicit Congestion Notification (ECN) threshold, said ECN threshold being a L4S congestion buffer threshold. Nonetheless, the combination of Zuniga and Patil teaches this limitation. Patil teaches an L4S-enablement scheme in which a request to set up an L4S-enabled QoS flow carries L4S QoS parameters that define queue limits indicating congestion at network nodes, and marking requirements ([0041]), the L4S QoS parameters included in the flow setup request comprising a queue size and marking criteria provided to the node that will provide the L4S service ([0050]; fig. 5, block 540). The combination teaches the recited coupling in that the congestion buffer threshold against which the access point checks the L4S data buffer—the threshold supplied by Zuniga—is the queue-limit value carried in the station’s request as taught by Patil, so that the threshold the access point checks is the same threshold indicated in the request frame.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Henry, IEEE, and Zuniga so that the L4S congestion buffer threshold checked by the access point is the ECN threshold indicated in the MSCS w/L4S request frame, as taught by the combination of Zuniga and Patil, because doing so would have allowed the station to specify, in its request, the queue-occupancy threshold the access point applies to that station’s L4S flow, giving the station control over the congestion-marking point appropriate to its application rather than leaving the threshold to a fixed access-point default. Carrying the threshold in the 802.11 request would have been a predictable use of Henry’s existing request mechanism, which already carries station-supplied L4S flow-characteristic parameters such as bandwidth requirements and latency constraints in the request frame ([0041]) and which Henry provides may utilize any 802.11 frame structure with interchangeable elements ([0067], [0070]); Henry’s use of access-point-side congestion management therefore does not teach away from a station-supplied threshold, because Henry already contemplates the station supplying L4S parameters in the request.
Regarding claims 2 and 12, Henry, IEEE, Zuniga, and Patil teach the method of claim 2, and further teach wherein the L4S descriptor element included in said MSCS w/L4S request frame further includes a loss tolerance indicator. IEEE teaches a loss tolerance indicator in the form of a Drop Eligibility subfield, carried in an element present in SCS Request frames, that indicates the degree to which a stream tolerates packet loss; specifically, IEEE teaches that the Intra-Access Category Priority element, which is present in SCS Request frames (pg. 1228, lines 30–34), includes a Drop Eligibility subfield that “is used to indicate the suitability of this TS to be discarded if there are insufficient resources” (pg. 1228, lines 68–69), and that the access point preferentially discards MSDUs of a stream whose Drop Eligibility subfield is equal to 1 in preference to MSDUs of a stream whose Drop Eligibility subfield is equal to 0 (pg. 1229, lines 5–6).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, Zuniga, and Patil so that the L4S descriptor element further includes a loss tolerance indicator, as taught by IEEE’s Drop Eligibility subfield, because doing so would have allowed the station to convey, with its request for L4S treatment, the acceptable loss tolerance for the L4S flow, which the access point would use in managing the L4S flow under congestion.
Henry, IEEE, Zuniga, and Patil further teach wherein the method further comprises communicating, from the AP to the first STA, an MSCS w/L4S response frame, said MSCS w/L4S response frame indicating creation of an L4S classifier filter. Henry teaches that, upon accepting the requested L4S flow, the access point communicates a response to the wireless device indicating the disposition (accept/creation) of the request ([0010], [0025]); IEEE teaches the standardized MSCS Response frame as the mechanism by which the AP communicates the disposition of an MSCS request to the STA (pg. 1564, line 65; pg. 1567, lines 33–37).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, Zuniga, and Patil so that the filter-creation decision is communicated using IEEE’s MSCS Response frame, because doing so would have allowed the access point to communicate the disposition of the L4S request to the station using an established 802.11 signaling exchange, Henry already communicating the accept/creation decision and providing that its L4S signaling may use standard 802.11 frame structures ([0068], [0070]).
Regarding claims 3 and 13, Henry, IEEE, Zuniga, and Patil teach the method of claim 2, and further teach operating the access point to decide to terminate the L4S classifier filter corresponding to the first STA, and operating the access point to communicate an MSCS w/L4S response frame to the first STA indicating that the grant of the L4S classifier filter request has been terminated. Henry teaches that the access point may decline or reclassify a flow that no longer complies with network policies, classify the flow as non-L4S, and communicate that determination to the wireless device ([0045], [0095]; fig. 8, block 860); IEEE teaches the MSCS Response frame as the standardized mechanism by which the AP communicates to the STA the disposition of an MSCS stream-classification request (pg. 1564, line 65; pg. 1567, lines 33–37).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, Zuniga, and Patil so that Henry’s termination/reclassification determination is communicated to the station using IEEE’s standardized MSCS Response frame, because doing so would have allowed the station to be informed that the grant had been terminated using an established 802.11 signaling exchange, Henry inviting the use of standard 802.11 frame structures ([0068], [0070]).
Regarding claims 4 and 14, Henry, IEEE, Zuniga, and Patil teach the method of claim 1, and further teach wherein the L4S descriptor element in the MSCS w/L4S request frame further includes an intra Access Category (intra-AC) queue designation which designates which intra-AC transmission queue is to be used for L4S data, and wherein operating the access point to use the classifier filter to determine if an MSDU directed to the first station communicates L4S data or communicates non-L4S data determines that the MSDU is L4S data. Henry teaches that the L4S request descriptor carries flow-characteristic and queue-treatment parameters for the requested L4S flow, that the access point assigns the L4S flow to a higher-priority queue, and that the access point determines an MSDU to be L4S using the classifier and enqueues it accordingly ([0041], [0046], [0062], [0078]; fig. 8, blocks 840, 850); IEEE teaches that intra-AC queue selection between primary and alternate EDCA queues is performed by an Intra-Access Category Priority element present in SCS Request frames (pg. 1228, lines 30–34), wherein the Alternate Queue subfield “indicates the intended primary or alternate EDCA queue that is used for this stream” (pg. 1228, lines 62–63; pg. 1633, lines 22–23).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, Zuniga, and Patil so that Henry’s L4S descriptor element includes an intra-AC queue designation that designates which intra-AC transmission queue is to be used for L4S data, as taught by IEEE’s Alternate Queue designation, because doing so would have allowed the station to designate the intra-AC transmission queue for its L4S data.
Regarding claims 5 and 15, Henry, IEEE, Zuniga, and Patil teach the method of claim 4, and further teach wherein said designated intra-AC transmission queue for future L4S traffic is a queue that was previously designated at the access point as one of: i) a primary voice queue, ii) an alternate voice queue, iii) a primary video queue, or iv) an alternate video queue. IEEE teaches that, when dot11AlternateEDCAActivated is true, six transmit queues are defined (pg. 1633, lines 22–23), including a primary and an alternate queue for each of the video (AC_VI) and voice (AC_VO) access categories, designated “Video (alternate),” “Video (primary),” “Voice (primary),” and “Voice (alternate)” (pg. 1633, lines 42–48; table 10-1), and that the Alternate Queue subfield selects the primary EDCA queue when set to 0 and the alternate EDCA queue for that AC when set to 1 (pg. 1228, lines 62–65).
This limitation is recited in the alternative (“or”); because IEEE teaches a previously-designated primary or alternate voice or video queue as set forth above, the requirement is satisfied. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, Zuniga, and Patil so that the intra-AC queue of claim 4 is designated as a previously-designated primary or alternate voice or video queue, as taught by IEEE, because doing so would have allowed the access point to assign the L4S flow to one of the prioritized voice or video EDCA transmit queues already defined at the access point for intra-AC stream treatment.
Regarding claim 6, Henry, IEEE, Zuniga, and Patil teach the method of claim 5, and further teach further comprising, in response to determining that the amount of data in the L4S data buffer exceeds the congestion buffer threshold, setting a congestion experienced (CE) codepoint (ECN=11) in the MSDU prior to communicating the MSDU to the first station. Zuniga teaches that when the L4S queue 210 crosses the second threshold 216, the access point sends a congestion notification comprising an ECN mark, and the ECN bits are set to 11 to indicate congestion ([0031], [0033]; fig. 3, block 350).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, Zuniga, and Patil so that the CE codepoint (ECN=11) is set in the MSDU upon determining that the L4S data buffer exceeds the congestion buffer threshold, as taught by Zuniga, because doing so would have signaled the congestion-experienced state to the first station as the intended result of the L4S congestion-detection mechanism.
Regarding claim 7, Henry, IEEE, Zuniga, and Patil teach the method of claim 6, and further teach further comprising transmitting the MSDU in accordance with a higher priority than is accorded with non-L4S data, said transmitted MSDU including the ECN bits set to a pattern (11) indicating that congestion was experienced. Zuniga teaches assigning a higher priority to the L4S queue 210 over other traffic, including by using Arbitration Interframe Spacing (AIFS) and/or altering the Contention Window minimum (CW_Min), and setting the ECN bits to 11 to indicate congestion ([0030], [0031], [0035]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, Zuniga, and Patil so that the L4S MSDU is transmitted at a higher priority than non-L4S data with the ECN bits set to 11, as taught by Zuniga, because doing so would have expedited delivery of the congestion-signaling L4S traffic as the intended result of the combined L4S prioritization and congestion-marking mechanism.
Regarding claim 8, Henry, IEEE, Zuniga, and Patil teach the method of claim 7, and further teach further comprising determining a required QoS for the MSDU conveying L4S data, said determined required QoS being a computed QoS metric. Henry teaches that the access point determines and applies QoS and flow characteristics for the L4S flow — including required bandwidth and latency constraints described in the flow-characteristics signaling — and schedules the flow based on the computed QoS and flow characteristics ([0041], [0046], [0081]–[0083]; fig. 6, blocks 620, 640). Under the broadest reasonable interpretation, the required QoS metric is computed by the access point’s flow scheduler from the received flow characteristics, the access point describing the QoS and flow characteristics and scheduling the flow based on the resulting computed QoS metric ([0081]–[0083]; fig. 6, block 640).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, Zuniga, and Patil so that the required QoS metric is computed and applied, as taught by Henry, because doing so would have allowed the access point to schedule the L4S flow in accordance with the QoS requirements computed for that flow.
Regarding claim 9, Henry, IEEE, Zuniga, and Patil teach the method of claim 8, and further teach wherein transmitting the MSDU in accordance with a higher priority than is accorded with the non-L4S data includes transmitting the MSDU as L4S data in accordance with the computed QoS metric. Henry teaches scheduling and transmitting the L4S flow based on the computed QoS and flow characteristics ([0081]–[0083]; fig. 6, block 640), and Zuniga teaches transmitting the prioritized L4S traffic at the higher priority ([0030], [0035]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, Zuniga, and Patil to transmit the L4S MSDU at the higher priority in accordance with the computed QoS metric, as taught by Henry and Zuniga, because doing so would have caused the L4S flow to be served in accordance with its determined QoS requirements as the intended result of Henry’s QoS-based scheduling combined with Zuniga’s prioritized transmission.
Regarding claim 10, Henry, IEEE, Zuniga, and Patil teach the method of claim 1, and further teach wherein creating an L4S filter includes monitoring uplink traffic streams; detecting uplink traffic streams having parameters relating to L4S traffic; designating downlink traffic streams corresponding to the detected uplink traffic streams as downlink L4S traffic streams; obtaining stream ID information corresponding to the downlink L4S traffic streams; and using the obtained stream ID information in the L4S classifier filter to identify L4S MSDUs. Henry teaches that the access point detects a downstream data flow, matches the corresponding upstream data flow using a device identifier or flow identifier, identifies the matched upstream and downstream flows as L4S, and uses the matched flow information to classify L4S traffic ([0045], [0085]–[0089]; figs. 7, 9); IEEE teaches the mirrored stream classification service (MSCS), in which the access point monitors the reverse-direction (uplink) stream from the non-AP STA and derives the downlink stream classification from it, the AP setting the UP of the MSDUs in the classified streams based on the UP of individually addressed MSDUs in the corresponding mirror (reverse direction) stream (pg. 2343, lines 56–57), the mirror classifier parameters for the downlink stream being determined from the monitored uplink stream by mapping source addresses/ports to destination addresses/ports and vice versa (pg. 2345, lines 19–38), and the AP identifying the stream by the value tuple (m_tuple) of the masked mirror classifier parameters carried in the MSCS Descriptor element (pg. 2345, lines 49–59).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, Zuniga, and Patil to create the L4S classifier filter by monitoring uplink traffic streams, detecting L4S-related uplink streams, designating the corresponding downlink streams as L4S, obtaining the stream ID information, and using it in the L4S classifier filter, as taught by the combination of Henry and IEEE, because doing so would have allowed the access point to identify the L4S MSDUs of the downlink stream by mirroring the monitored L4S uplink stream, using an existing 802.11 stream-classification mechanism.
Claims 16–20 and 23–28 are rejected under 35 U.S.C. § 103 as being unpatentable over Henry in view of IEEE and Patil.
Regarding claims 16 and 23, Henry teaches a method of operating a station (STA), the method comprising: determining that a Low Latency, Low Loss, and Scalable Throughput (L4S) filter should be set up at an access point (AP). Henry teaches that an L4S enabled wireless device (STA) determines to request that an upstream data flow be classified and treated as L4S at the access point, and on that basis initiates an L4S classification request to the access point ([0041], [0065], [0090]; figs. 2, 8).
Henry teaches generating a L4S request frame, the L4S request frame including an L4S descriptor. Henry teaches that the wireless device generates an augmented Stream Classification Service (SCS) request frame, the augmented SCS request frame including an L4S descriptor comprising an L4S indicator, in the form of a field such as a one-bit field set by the wireless device to request that the upstream data flow be classified as L4S, and a QoS Characteristics Element indicative of one or more flow characteristics, such as bandwidth requirements and latency constraints, of the requested L4S flow ([0041], [0065], [0090]; figs. 2, 8).
Henry teaches transmitting the MSCS w/L4S request frame to an access point. Henry teaches that the wireless device transmits the augmented SCS request frame to the access point ([0041], [0065]; fig. 2, step 1).
However, Henry does not teach that the L4S request frame is a Mirrored Stream Classification Service (MSCS) w/L4S request frame, that the L4S descriptor is included in the request as an L4S descriptor element, or that the L4S descriptor element includes an element ID. Nonetheless, IEEE teaches the Mirrored Stream Classification Service (MSCS), wherein a non-AP STA requests mirrored stream classification by generating and transmitting an MSCS Request frame to the AP with which the STA is associated (pg. 706, lines 35–36, 41–42). IEEE further teaches that the MSCS Request frame includes an MSCS Descriptor element (pg. 1567, line 31), and that the MSCS Descriptor element includes an Element ID, a Length, an Element ID Extension, a Request Type, a User Priority Control, a Stream Timeout, optional TCLAS Mask Elements, and an Optional Subelements field (pg. 1399, lines 49–65; fig. 9-782). IEEE further teaches that the Optional Subelements field of the MSCS Descriptor element contains zero or more subelements, each identified by a subelement ID, the subelements allowed in the MSCS Descriptor element being defined in Table 9-322, including a Vendor subelement having subelement ID 221 (pg. 1400, lines 50–53, 55–67; table 9-322). A subelement nested within the MSCS Descriptor element thus constitutes an L4S descriptor element that includes an element ID, namely the subelement ID identifying that subelement.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Henry so that the wireless device generates and transmits the L4S classification request as an MSCS Request frame including an MSCS Descriptor element carrying Henry’s L4S descriptor within a subelement nested in the Optional Subelements field, the nested subelement constituting an L4S descriptor element that includes an element ID (e.g., the Vendor subelement having subelement ID 221), as taught by IEEE, because doing so would have allowed the station to request Henry’s L4S classification treatment using the existing standardized 802.11 MSCS request mechanism and its established subelement-nesting conventions, Henry expressly providing that its L4S signaling may utilize any 802.11 frame structure and that its elements are interchangeable with other 802.11 elements ([0067], [0070]).
In addition, Henry and IEEE do not teach that the MSCS w/L4S request frame includes an ECN threshold, said ECN threshold being a L4S congestion buffer threshold. Nonetheless, Patil teaches an L4S-enablement scheme in which a request to set up an L4S-enabled flow carries L4S QoS parameters that define queue limits indicating congestion at network nodes, and marking requirements ([0041]), comprising a queue size and marking criteria provided to the node that will provide the L4S service ([0050]; fig. 5, block 540).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Henry and IEEE so that the MSCS w/L4S request frame generated and transmitted by the station includes an ECN threshold that is an L4S congestion buffer threshold, as taught by Patil, because doing so would have allowed the station to convey, with its request for L4S treatment, the L4S congestion buffer threshold for use by the access point in performing L4S queue management.
Regarding claim 17, Henry, IEEE, and Patil teach the method of claim 16, and further teach wherein the L4S descriptor element included in said MSCS w/L4S request frame further includes a loss tolerance indicator, and wherein the method further comprises receiving, from the AP, an MSCS w/L4S response frame indicating creation of an L4S classifier filter. As to the loss tolerance indicator, IEEE teaches that the Intra-Access Category Priority element, present in SCS Request frames, includes a Drop Eligibility subfield that indicates the suitability of a stream to be discarded if there are insufficient resources (pg. 1228, lines 30–34, 68–69), wherein the access point preferentially discards the MSDUs of a stream whose Drop Eligibility subfield equals 1 over those of a stream whose Drop Eligibility subfield equals 0 (pg. 1229, lines 5–6). As to the response frame, Henry teaches that the access point communicates a response to the station indicating the disposition of the request ([0010], [0025]), and IEEE teaches the standardized MSCS Response frame, received by the STA, as the mechanism for communicating the disposition of an MSCS request (pg. 1564, line 65; pg. 1567, lines 33–37).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, and Patil to include a loss tolerance indicator in the station’s L4S descriptor element and to receive an MSCS w/L4S response frame indicating creation of the L4S classifier filter, as taught by IEEE, because doing so would have allowed the station to signal its acceptable loss tolerance and to learn that its requested L4S filter had been created, using established 802.11 stream-classification signaling.
Regarding claims 18 and 26, Henry, IEEE, and Patil teach the method of claim 16, and further teach wherein the L4S descriptor element includes an element ID identifying the L4S descriptor element as an L4S descriptor and said ECN threshold. As set forth for claim 16, the L4S descriptor element is a subelement nested within IEEE’s MSCS Descriptor element, identified by its subelement ID (IEEE, pg. 1400, lines 50–53, 55–67; table 9-322); the subelement ID identifies the nested subelement as the L4S descriptor element, and the ECN threshold (the L4S congestion buffer threshold) is carried therein as set forth for claim 16 (Patil, [0041], [0050]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, and Patil to provide the L4S descriptor element with an element ID identifying it as an L4S descriptor, as taught by IEEE, because doing so would have allowed the access point to recognize the L4S descriptor among the subelements of the MSCS Descriptor element.
Regarding claim 19, Henry, IEEE, and Patil teach the method of claim 18, and further teach wherein generating the MSCS w/L4S request frame includes including in said L4S descriptor element at least one of i) a L4S classifier mask, ii) a latency target, ii) a desired level of bandwidth, or iii) a loss tolerance indicator. This limitation is recited in the alternative (“at least one of”); because the combination teaches at least a latency target, the requirement is satisfied: Henry teaches that the L4S descriptor carries flow-characteristic parameters including latency constraints for the requested L4S flow ([0041]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, and Patil to include a latency target in the station’s L4S descriptor element, as taught by Henry and Patil, because doing so would have allowed the station to convey the flow’s latency requirement for use in L4S treatment.
Regarding claims 20 and 28, Henry, IEEE, and Patil teach the method of claim 17, and further teach further comprising operating the station to receive an MSCS w/L4S response frame indicating that the grant of the L4S classifier filter request has been terminated. Henry teaches that the access point may decline or reclassify a previously granted L4S flow that no longer complies with network policies and communicates that determination to the wireless device ([0045], [0095]; fig. 8, block 860); IEEE teaches the standardized MSCS Response frame, received by the non-AP STA, as the mechanism by which the access point communicates the disposition of an MSCS request to the station (pg. 1564, line 65; pg. 1567, lines 33–37).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, and Patil so that the station receives an MSCS w/L4S response frame indicating that the grant of the L4S classifier filter has been terminated, as taught by IEEE, because doing so would have informed the station of the termination using an established 802.11 signaling exchange.
Regarding claim 24, Henry, IEEE, and Patil teach the station of claim 23, and further teach wherein said processor is configured to operate the station to include in said L4S descriptor element a L4S Classifier Mask, as part of being configured to operate the station to generate the MSCS w/L4S request frame. IEEE teaches that the MSCS Descriptor element carries one or more TCLAS Mask elements that specify a classifier mask used to classify incoming MSDUs into streams (pg. 1399, lines 23–35; pg. 1400, lines 40–48; fig. 9-782, clause 9.4.2.242).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, and Patil to configure the station to include a L4S classifier mask in the L4S descriptor element, as taught by IEEE, because doing so would have allowed the station to specify the classification criteria for its L4S traffic.
Regarding claim 25, Henry, IEEE, and Patil teach the station of claim 23, and further teach further comprising a wireless receiver, and wherein said processor is further configured to operate the station to receive, from the AP, an MSCS w/L4S response frame, said MSCS w/L4S response frame indicating creation of an L4S classifier filter. Henry teaches that the access point communicates a response to the wireless device indicating the disposition (accept/creation) of the request ([0010], [0025]); IEEE teaches the standardized MSCS Response frame, received by the non-AP STA, as the mechanism for communicating the disposition of an MSCS request (pg. 1564, line 65; pg. 1567, lines 33–37).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, and Patil to configure the station, having a wireless receiver, to receive an MSCS w/L4S response frame indicating creation of the L4S classifier filter, as taught by IEEE, because doing so would have allowed the station to be informed that its requested L4S filter had been created using an established 802.11 signaling exchange.
Regarding claim 27, Henry, IEEE, and Patil teach the station of claim 26, and further teach wherein said processor is configured to operate the station to include in said L4S descriptor element at least one of i) a L4S classifier mask, ii) a latency target, ii) a desired level of bandwidth, or iii) a loss tolerance indicator, as part of being configured to operate the station to generate the MSCS w/L4S request frame. This limitation is recited in the alternative (“at least one of”); because the combination teaches at least a latency target and a desired level of bandwidth, the requirement is satisfied: Henry teaches that the L4S descriptor carries a QoS Characteristics Element indicative of flow characteristics including latency constraints and bandwidth requirements of the requested L4S flow ([0041]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Henry, IEEE, and Patil to configure the station to include a latency target and/or a desired level of bandwidth in the L4S descriptor element, as taught by Henry and Patil, because doing so would have allowed the station to convey the flow’s QoS requirements for use in L4S treatment.
Claims 21, 22, 29, and 30 are rejected under 35 U.S.C. § 103 as being unpatentable over Henry, IEEE, and Patil, as applied to claims 20 and 28 above, in further view of Zuniga.
Regarding claims 21 and 29, Henry, IEEE, and Patil teach the method of claim 20, but do not teach further comprising receiving from the access point an MSDU with a congestion experienced (CE) codepoint that was set by the AP in response to the AP determining that the amount of data in the L4S data buffer exceeds the congestion buffer threshold. Nonetheless, Zuniga teaches that, when the amount of traffic in the L4S queue crosses above the threshold, the access point sets the ECN bits to 11 (the CE codepoint) to indicate congestion before the traffic is communicated, such that the recipient receives the MSDU carrying the CE marking ([0031], [0033]; fig. 3, block 350); in the combination, the threshold against which the L4S data buffer is checked is the L4S congestion buffer threshold indicated in the MSCS w/L4S request frame (Patil, [0041], [0050]), as set forth for claim 16.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Henry, IEEE, and Patil so that the station receives an MSDU bearing a CE codepoint that the access point set upon determining that the L4S data buffer exceeded the congestion buffer threshold, as taught by Zuniga, because doing so would have caused the station to receive the congestion-experienced indication as the intended result of the L4S congestion-detection and marking mechanism.
Regarding claims 22 and 30, Henry, IEEE, and Patil teach the method of claim 20, but do not teach further comprising receiving from the access point an MSDU with a congestion experienced (CE) codepoint that was left unchanged by the access point following the access point determining that the amount of data in the L4S data buffer did not exceed the congestion buffer threshold, with whatever pattern they were set to when received by the access point. Nonetheless, Zuniga teaches that the access point sets the ECN bits to the CE pattern (11) only when the L4S queue crosses the threshold ([0031], [0033]), and that when the L4S queue has not crossed the threshold the access point operates normally and does not apply ECN (CE) marking ([0030], [0032]; fig. 3, blocks 320, 330), such that the MSDU is forwarded to the station with the ECN bits unchanged from the pattern they carried when received by the access point.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Henry, IEEE, and Patil so that the station receives an MSDU whose CE codepoint was left unchanged when the L4S data buffer did not exceed the congestion buffer threshold, as taught by Zuniga, because doing so would have been the operation of the combined L4S congestion-detection and marking mechanism, which marks CE only upon a threshold crossing and otherwise forwards the MSDU with its ECN bits unchanged.
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andrew Georgandellis whose telephone number is 571-270-3991. The examiner can normally be reached on Monday through Friday, 7:30-5:00 PM EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tonia Dollinger, can be reached on 571-272-4170. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANDREW C GEORGANDELLIS/Primary Examiner, Art Unit 2459
Prosecution Insights