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 .
DETAILED ACTION
The office action is a response to application filed on 5.22.2026. Wherein claims 1-13 are pending and ready for examination.
Claims 14-26 have been withdrawn.
Election/Restrictions
Applicant's election without traverse of claims 1-13 in the reply filed on 5/22/2026 is acknowledged.
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 of this title, 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.
1. Claim(s) 1-3, 6-9 and 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Henry (US 20190082360 A1) in view of Xin (US 20230058871 A1).
With respect to independent claims:
Regarding claim(s) 1, a method, comprising:
Henry teaches receiving, by a network device (Henry, [0049, FIG.2; controller 30 + AP together is considered as the network device.) from an associated station (STA) (Henry, [0046], client), a Stream Classification Service (SCS) request (Henry, [0046]- [0048], RIC request” “TSPEC/TCLAS”, “TSPEC allows a wireless client to signal its traffic requirements to the AP”. [examiner notes: the RIC request interprets to be the SCS request.]) comprising one or more sets of traffic class (TCLAS) information and a preferred traffic identifier (TID) value for a data flow transmitted between the STA and the network device; (Henry, [0048], [0049] “TCLAS is”, “that contains a set of parameters to identify incoming frames with a particular traffic stream”. “TCLAS”, “that contains a set of parameters to identify. [examiner notes: TCLAS (Traffic Classification Element) comprises a traffic classifier used in Wi-Fi networks to identify and categorize specific types of data flows for Quality of Service (QoS).])
determining, by the network devices, a type of service of the data flow by analyzing the one or more sets of TCLAS information; (Henry, [0049], FIG.2; at 210, the wireless LAN controller 30 observes the TSPEC/TCLAS sent by the client via AP 20(1) and tries to match it against traffic in the NBAR table. If the target traffic flow was the subject of a previous TSPEC/TCLAS request on the current (previous before the roam) AP 20(1), it may already be labelled as such and its identification is easy. Thus, as shown in FIG. 2, at 210, the wireless LAN controller 30 detects “456” in the TSPEC/TCLAS element 200 and at 220 finds a match to a traffic flow in an NBAR table 230 maintained by the controller 30, as shown at 232. [0050] If the target traffic flow is not labelled in the client NBAR table maintained by the wireless LAN controller 30, at 250, the wireless LAN controller 30 invokes NBAR deep packet inspection using the packet size and expected rates to identify the target traffic flow as shown at 255. [0051] At 260, the controller either sends the QoS rules for the flow matching the TSPEC/TCLAS value (e.g., “456” in the example of FIG. 2.) at 220, or the QoS rules for the target traffic flow identified by deep packet inspection at 250. [examiner notes: FIGs.2 and 3; NBAR table 230/320 storing categories of QoS (types of services of data).]) confirming, by the network device, that the type of service does not align with the preferred TID value under one or more defined network policies; and (Henry, [0049], FIG.2; at 210, the wireless LAN controller 30 observes the TSPEC/TCLAS sent by the client via AP 20(1) and tries to match it against traffic in the NBAR table. If the target traffic flow was the subject of a previous TSPEC/TCLAS request on the current (previous before the roam) AP 20(1), it may already be labelled as such and its identification is easy. Thus, as shown in FIG. 2, at 210, the wireless LAN controller 30 detects “456” in the TSPEC/TCLAS element 200 and at 220 finds a match to a traffic flow in an NBAR table 230 maintained by the controller 30, as shown at 232. [0050] If the target traffic flow is not labelled in the client NBAR table maintained by the wireless LAN controller 30, at 250, the wireless LAN controller 30 invokes NBAR deep packet inspection using the packet size and expected rates to identify the target traffic flow as shown at 255. [0051] At 260, the controller either sends the QoS rules for the flow matching the TSPEC/TCLAS value (e.g., “456” in the example of FIG. 2.) at 220, or the QoS rules for the target traffic flow identified by deep packet inspection at 250. [examiner notes: FIG.3 shows NBAR table 332 storing categories of QoS (types of services of data).])
Henry does not teach in response to the confirmation, sending, by the network device to the STA, an SCS response comprising adjustments of at least one of the one or more sets of TCLAS information or the preferred TID value to a new TID value.
Xin however in the same field of computer networking teaches in response to the confirmation, sending, by the network device to the STA, an SCS response comprising adjustments of at least one of the one or more sets of TCLAS information or the preferred TID value to a new TID value. (Xin, [0079] In FIG. 12 each descriptor element is depicted having fields of Element ID, Length, SCSID, Request Type, Intra-Access Category Priority, TCLAS, TCLAS Processing (optional), TSPEC, and Optional Subelements. [0135] The non-AP can set the R-TWT request field to “not required” and the SCS request frame is only for SCS setup as it is defined in IEEE 802.11. No TWT element is carried by the SCS descriptor element in the SCS request frame. [0136] This provides backward compatibility with the existing protocol. Then, the non-AP STA receives the SCS response frame to indicate the setup results of SCSx. [0137] If at block 114, it is determined that the AP rejected the SCS setup request, then SCS setup has failed 124 in FIG. 21 as well as the associated R-TWT setup request. [0138] Execution moves to block 126, wherein the AP may include the suggested parameter setting. The non-AP can re-send another SCS request frame using the suggested parameter settings to again request SCS setup. [0147] If the SCS and R-TWT are accepted, then at block 138 the non-AP STA becomes a member of the R-TWT and traffic belonging to the SCS is scheduled to transmit during R-TWT SPs. Otherwise, if the request is not accepted at block 136, then at block 140 the traffic belonging to the SCS is not allowed, or is given a lower priority than that transmitted during R-TWT SPs.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Henry by incorporating the teachings of Xin. The motivation/suggestion would have been because there is a need to for enhanced CSMA/CA WLAN protocols which can provide low-latency for RTA packets, and high throughput for non-RTA packet traffic (Xin, [0008]).
With respect to dependent claims:
Regarding claim(s) 2, the method of claim 1,
Henry-Xin teach wherein the data flow comprises an uplink data flow transmitted from the STA to the network device. (Henry, FIG.2 shows uplink and downlink. [0021] In a centralized mode, the wireless LAN controller first needs upstream traffic from the client to identify the application, then downstream traffic with QoS marking, in order to generate new QoS policies (QoS remarking, rate limiting, dropping traffic). Once this is done, the wireless LAN controller is able to extend the reflective Application Visibility and Control policy to the new AP (to which the client roamed) and the policy is applied to the client in the upstream direction.)
Regarding claim(s) 3, the method of claim 1,
Henry-Xin teach wherein the data flow comprises a downlink data flow transmitted from the network device to the STA. (Henry, FIG.2 shows uplink and downlink. [0021] In a centralized mode, the wireless LAN controller first needs upstream traffic from the client to identify the application, then downstream traffic with QoS marking, in order to generate new QoS policies (QoS remarking, rate limiting, dropping traffic). Once this is done, the wireless LAN controller is able to extend the reflective Application Visibility and Control policy to the new AP (to which the client roamed) and the policy is applied to the client in the upstream direction.)
Regarding claim(s) 6, the method of claim 1,
Henry-Xin teach wherein the SCS request further comprises one or more sets of quality of service (QoS) characteristics information for the data flow, and wherein determining the type of service of the data flow comprises analyzing both the one or more sets of TCLAS information and the one or more sets of quality of service (QoS) characteristics information. (Henry, [0047] In both cases, the RIC request contains traffic descriptor that describes the traffic for which the QoS service is requested. In a roaming case, the request is unlikely to be new traffic (a new request exactly at the time of the roam is statistically unlikely) and likely to be the continuation of a flow going through the current AP. [0048] The traffic descriptor can take on different possible formats, and several examples are described below with reference to FIGS. 2-5. FIG. 2 shows an example in which the traffic descriptor uses the standard Traffic Specification/Traffic Classification (TSPEC/TCLAS) format of IEEE 802.11. This is shown at 200 in FIG. 2 [0054] Reference is now made to FIG. 4 that shows another example traffic descriptor scenario. In this example, the traffic descriptor takes the form of a QoS category. This category can be a Differentiated Services Code Point (DSCP) value, a group of DSCP values, or a QoS category (e.g. voice, video, or other). The RIC request sent by wireless client device 40 contains the QoS category as shown at 400. At 410, the controller observes the QoS category in the RIC request. The wireless LAN controller 30 uses its own application classification system to identify all applications in the client NBAR table 420 that match the one or more categories contained in the RIC request. As shown at 430, if the QoS category (or categories) identified in the RIC request 400 match a QoS category descriptor stored in the NBAR table 420, then a match is determined and the controller 30, at 440, sends the QoS rules for that application to the AP 20(2).)
Regarding claim(s) 7, the method of claim 1,
Henry-Xin teach further comprising sending, by the network device to the STA, adjustments of the one or more sets of QoS characteristics information for the data flow in the SCS response. (Xin, [0137] If at block 114, it is determined that the AP rejected the SCS setup request, then SCS setup has failed 124 in FIG. 21 as well as the associated R-TWT setup request. [0138] Execution moves to block 126, wherein the AP may include the suggested parameter setting. The non-AP can re-send another SCS request frame using the suggested parameter settings to again request SCS setup.)
The same motivation to combine as the independent claim 1 applies here.
Regarding claim(s) 8, the method of claim 1,
Henry-Xin teach further comprising sending, by the network device to the STA, a failure status code in the SCS response if the one or more sets of TCLAS information are not included for the data flow. (Henry, [0076], mark traffic for which QoS was not allowed (not in the whitelist)”, “wipe the QoS marking out.)
Regarding claim(s) 9, the method of claim 1,
Henry-Xin teach wherein each set of the one or more sets of TCLAS information comprises at least one of 5-tuple data, an application ID, or a web address or a fully qualified domain name (FQDN). (Henry, [0025] 5-tuple flow information. [0028] To do this, two elements are used: (1) a state table is kept of all the flows along with the associated AVC application identifier (App ID), and (2) utilization of the IEEE 802.11r Fast Transition (FT) protocol for certain clients.)
Regarding claim(s) 11, the method of claim 1,
Henry-Xin teach wherein the adjustments of the one or more sets of TCLAS information comprise at least one of: narrowing a scope of the one or more sets of TCLAS information, comprising limiting, by the network device, a range of IP addresses, port numbers, or port types to the preferred TID; or broadening the scope of the one or more sets of TCLAS information, comprising expanding, by the network device, the range of IP addresses, port numbers, or protocol types to the preferred TID.( (Henry, [0025], “5-tuple flow information (Src IP, Dst IP, Src Port, Dst Port, Protocol Type)” )
Regarding claim(s) 12, the method of claim 1,
Henry-Xin teach wherein the network device comprises at least one of an access point (AP), a wireless local area network controller (WLC), a network security appliance, or a gateway. (Henry, FIG.3; controller 310 + AP 20(1))
Regarding claim(s) 13, the method of claim 1,
Henry-Xin teach wherein the STA or the network device indicates a support for at least one of TCLAS inclusion for uplink data flows, TCLAS negotiation, or preferred TID negotiation via a capability field in a management frame. (Xin, [0343] wherein said SCS request frame comprises a traffic specification (TSPEC) element or QoS characteristics element; (d)(ii) receiving said SCS request frame from the non-AP STA, upon which the AP determines whether or not to accept the request; (d)(iii) sending a SCS response frame by the AP to the non-AP STA indicating a decision on the request; and (d)(iv) scheduling SCS traffic to be transmitted with an increased priority, by the AP and non-AP STA, during R-TWT service periods (SPs) if the request is accepted; wherein said SCS traffic is selected from the group of communication traffic consisting of downlink (DL), uplink (UL), and peer-to-peer (P2P). [0079] In FIG. 12 each descriptor element is depicted having fields of Element ID, Length, SCSID, Request Type, Intra-Access Category Priority, TCLAS, TCLAS Processing (optional), TSPEC, and Optional Subelements.)
The same motivation to combine as the independent claim 1 applies here.
2. Claim(s) 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Henry in view of Xin further in view of Kwan (US 20090086634 A1).
Regarding claim(s) 4, the method of claim 1,
Henry-Xin teach further comprising: receiving, by the network device, (Henry, [0049] FIG. 2; controller 30 + AP together is considered as the ‘network device’), a second SCS request from the STA incorporating the adjustments; (Henry, “RIC request” [0046]- [0048], ““TSPEC/TCLAS”, “TSPEC allows a wireless client to signal its traffic requirements to the AP. [Examiner Note: requesting a potentially repeated request (second SCS request) which does not differentiate from the first request is merely a duplication of a request. MPEP 2144.04 VI])
confirming, by the network device, that the adjusted one or more sets of TCLAS information align with the preferred TID value under the one or more defined network policies; (Henry, (“QoS policy for network flows” [0033], uniquely matched by an AVC policy” [0035]).
and sending, by the network device, a second SCS response confirming the preferred TID value. (Henry, [0083] Sending data describing one or more rules matching the one or more applications” [Examiner note: second sets of TCLAS information which are potentially repeat of a set of TCLAS information which does not differentiate from the set of TCLAS information is merely a duplication of the set of TCLAS information. MPEP 2144.04 VI.])
Henry-Xin do not teach allocating, by the network device, network resources to the data flow per the preferred TID value;
Kwan however in the same field of computer networking teaches allocating, by the network device, network resources to the data flow per the preferred TID value; (Kwan, Class of Service (CoS)” [0004], allocate resources to enable traffic to be transmitted at the minimum data transfer rate for a period of time.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Henry by incorporating the teachings of Kwan. The motivation/suggestion would have been because there is a need to or packet rate shaping may comprise an MMU that enables classification of one or more packets based on a CoS and/or an egress port, and transmission of the packets in accordance with a specified packet rate based on the classification (Kwan [0039]).
Regarding claim(s) 5, the method of claim 1,
Henry-Xin teach further comprising: receiving, by the network device, a second SCS request from the STA incorporating the adjustments; (Henry, “RIC request” [0046]- [0048], ““TSPEC/TCLAS”, “TSPEC allows a wireless client to signal its traffic requirements to the AP. [Examiner Note: requesting a potentially repeated request (second SCS request) which does not differentiate from the first request is merely a duplication of a request. MPEP 2144.04 VI])
confirming, by the network device, that the one or more sets of TCLAS information align with the new TID value under the one or more defined network policies; (Henry, (“QoS policy for network flows” [0033], uniquely matched by an AVC policy” [0035]).
allocating, by the network device, network resources to the data flow per the new TID value; and (Kwan, Class of Service (CoS)” [0004], allocate resources to enable traffic to be transmitted at the minimum data transfer rate for a period of time.)
sending, by the network device, a second SCS response confirming the new TID value. Henry, [0083] Sending data describing one or more rules matching the one or more applications” [Examiner note: second sets of TCLAS information which are potentially repeat of a set of TCLAS information which does not differentiate from the set of TCLAS information is merely a duplication of the set of TCLAS information. MPEP 2144.04 VI.])
The same motivation to combine as the dependent claim 4 applies here.
3. Claim(s) 10 is/are rejected under 35 USC 103 as being unpatentable over Henry in view of Xin further in view of Vutukuri et al. (US 20200322804 A1).
Regarding claim(s) 10, the method of claim 6,
Henry-Xin do not teach wherein each set of the one or more sets of QoS characteristics information comprises at least one of a service interval, delay bound, burst size, or minimum data rate.
Vutukuri however in the same field of computer networking teaches wherein each set of the one or more sets of QoS characteristics information comprises at least one of a service interval, delay bound, burst size, or minimum data rate. (Vutukuri, [0014] A network node (e.g., a node of the core network, such as a Session Management Function (SMF)) receives this information and determines whether or not to enable integrity protection for user plane data based on the information (possibly in conjunction with other information such as the minimum data rate to be supported, etc.). [0054] At 612, the SMF obtains the QoS profile of the session (e.g., by communicating with the PCF) and determines the required data rate characteristics to support the required QoS.[examiner notes: the required data rate is minimum data rate.])
. Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Henry by incorporating the teachings of Vutukuri. The motivation/suggestion would have been because there is a need to provide “in many modern wireless systems, integrity protection and integrity verification is carried out by a Packet Data Convergence Protocol (PDCP) entity” (Vutukuri [0004]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WUJI CHEN whose telephone number is (571)270-0365. The examiner can normally be reached on 9am-6pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, VIVEK SRIVASTAVA can be reached on (571) 272-7304. 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.
/WUJI CHEN/
Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449
Prosecution Insights