DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. Claims 1-20 are presented for examination.
3. This Office Action is in response to application 18/817876 (US 20250080469 A1) filed on August 28, 2024. Provisional 63/580241, filed September 1, 2023, mentions some of the features recited in application 18/817876 claims.
Paper Submitted
4. It is hereby acknowledged that the following papers has been received and placed of record in the file.
a. Information Disclosure Statements as received on November 6, 2024 and February 18, 2025.
Claim Rejection – 35 U.S.C. 102 CLAIM REJECTION
5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless—
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention
6. Claim(s) 1, 2, 4, 9-11, 16-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Henry et al. (US 20190082360 A1) hereinafter Henry.
7. Regarding claims 1, 17 and 20, Henry teach:
receiving, by a network device (controller 30 + AP together is considered as the ‘network device’ [0049] Figure 2), a Stream Classification Service (SCS) request (“RIC request” [0046] [0047], “TSPEC/TCLAS”, “TSPEC allows a wireless client to signal its traffic requirements to the AP” [0048]) from an associated station (STA) (“client” [0046]),
wherein the SCS request specifies one or more sets of traffic class (TCLAS) information (“TCLAS is”, “that contains a set of parameters to identify incoming frames with a particular traffic stream” [0048]) for a data flow (“continuation of a flow” [0047]) transmitted between the network device and the STA, each set of TCLAS information (“TCLAS”, “that contains a set of parameters to identify” [0049]) being accompanied by associated quality of service (QoS) profile information (“aggregated QoS policy”, “QoS information for each of the listed application identifiers” [0033], “traffic in the NBAR table” [0049]) for the data flow (“QoS rules for the flow matching the TSPEC/TCLAS value”, “or the QoS rules for the target traffic flow identified by deep packet inspection” [0051]);
comparing (“each flow that is uniquely matched”, “has an entry” [0035], “to identify” [0048], “comparing the TSPEC/TCLAS request against” [0079]), by the network device, the one or more sets of TCLAS information (“TCLAS is”, “that contains a set of parameters to identify incoming frames with a particular traffic steam” [0048]) and the associated QoS profile information (“QoS information” [0033]) with one or more cached application profiles (“5-tuple flow information” [0025], “listed application identifiers” [0033], “NBAR table” [0049], “recognition data”, “target flow” [0079] [0082]);
determining, by the network device, that the one or more sets of TCLAS information (“5-tuple flow information (Src IP, Dst IP, Src Port, Dst Port, Protocol Type)” [0025]) and the associated QoS profile information (“QoS policy can specify a number of other QoS metrics for each of the flows” [0016]) do not match (“not labeled” [0050]) any of the one or more cached application profiles (“NBAR engine in the wireless LAN controller”, “5-tuple flow information (Src IP, Dst IP” [0025], “an entry in the state table” [0035], “NBAR table” [0049]);
performing, in response to the determination, by the network device, packet analysis (“deep packet inspection” [0051]) to determine a type of service (“target traffic flow identified” [0051]) of the data flow (“or the QoS rules for the target traffic flow identified by deep packet inspection” [0051]);
confirming (“uniquely matched”, “an entry in the state table” [0035]), by the network device, that the one or more sets of TCLAS information and the associated QoS profile information align (“flow matching” [0051]) with the determined type of service based on one or more defined network policies (“QoS policy for network flows” [0033], “uniquely matched by an AVC policy” [0035]); and
applying, in response to the confirmation, by the network device, one or more treatments (“QoS treatment” [0018], “apply a policy” [0089]) to the data flow based on the one or more sets of TCLAS information (“obtaining flow information descriptive of one or more traffic flows” [0089]) and the associated QoS profile information (“state data” [0089]) received in the SCS request (“RIC request” [0046] [0047]),
wherein the one or more treatments (“QoS treatment” [0026] [0082]) are consistent with at least one of the determined type of service (“QoS metrics for each of the flows” [0016], “in the whitelist” [0026]) or the one or more defined network policies (“QoS policy for network flows” [0033], “uniquely matched by an AVC policy” [0035]).
8. Regarding claim(s) 2 and 18, Henry teach further comprising:
after determining that the one or more sets of TCLAS information (“observes the TSPEC/TCLAS” [0049]) and the associated QoS profile information (“QoS rules for that application” [0053]) do not match (“traffic flow is not labelled in the client NBAR” [0050]) any other the one or more cached application profiles (“5-tuple flow information (Src IP, Dst IP” [0025], “NBAR table” [0049]), sending, by the network device to the STA, a first SCS response indicating that SCS validation (“it may already be labelled”, “tries to match it against traffic in the NBAR table” [0049]) is in processing.
after confirming (“performing a lookup” [0082]) that the one or more sets of TCLAS information and the associated QoS profile information align (“labelled as a traffic flow” [0082]) with the determined type of service (“(QoS) treatment” [0082]);
based on the one or more defined network policies, sending (“sending operation” [0083]), by the network device (“wireless network controller” [0082]) to the STA (“for the wireless client device” [0083]), a second SCS response confirming (“sending data describing one or more rules matching the one or more applications” [0083]).
9. Regarding claim(s) 4 and 19, Henry further teach wherein the one or more sets of TCLAS information comprises at least one or a 5-tuple or differential services code point (DSCP) value for the data flow, the 5-tuple comprising a source IP address (“Src IP” [0025]), a destination IP address, a source port, a destination port, or a protocol type.
10. Regarding claim(s) 9, Henry teach:
receiving, by the network device (controller 30 + AP together is considered as the ‘network device’ [0049] Figure 2), a second SCS request (“RIC request” [0046] [0047], ““TSPEC/TCLAS”, “TSPEC allows a wireless client to signal its traffic requirements to the AP” [0048], see Examiner Note below) from the STA (“client” [0046]) (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),
wherein the second SCS request specifies one or more second sets of TCLAS information (“TCLAS is”, “that contains a set of parameters to identify incoming frames with a particular traffic stream” [0048], see Examiner Note below) for a second data flow (“continuation of a flow” [0047]) transmitted between the network device and the STA, each second set of TCLAS information (“TCLAS”, “that contains a set of parameters to identify incoming frames” [0049]) being accompanied by associated QoS profile information (“aggregated QoS policy”, “QoS information for each of the listed application identifiers” [0033]) (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);
comparing (“each flow that is uniquely matched”, “has an entry” [0035], “to identify” [0048], “comparing the TSPEC/TCLAS request against” [0079]), by the network device, the one or more second sets of TCLAS information (“TCLAS”, “that contains a set of parameters to identify incoming frames” [0049]) and the associated QoS profile information (“aggregated QoS policy”, “QoS information” [0033]) with one or more cached application profiles (“5-tuple flow information” [0025], “listed application identifiers” [0033], “NBAR table” [0049], “recognition data”, “target flow” [0079] [0082]);
determining that the one or more second sets of TCLAS information (“NBAR table” [0049]) and the associated QoS profile information match (“QoS rules for the flow matching” [0051]) one cached application profile (“traffic flow in an NBAR table” [0049]), within the one or more cached application profiles (“NBAR table” [0049]); and
applying, by the network device, one or more second treatments (“QoS category (or categories) identified” [0054], see note below) to the second data flow that are consistent with the matched profile (“one or more categories contained”, “QoS category descriptor” [0054]) (Examiner note: second treatment which is potentially a repeat of a first treatment which does not differentiate from the first treatment is merely a duplication of the first treatment. MPEP 2144.04 VI).
11. Regarding claim(s) 10, Henry teach further comprising sending, by the network device to the STA, an SCS response confirming (“sends the QoS rules for that application” [0054]) that the one or more second sets of TCLAS information (“QoS category descriptor” [0054]) and the associated QoS profile information (“QoS rules” [0054]) are received in the second SCS request (“QoS category in the RIC request” [0054]) for the second data flow (“key traffic” [0056]).
12. Regarding claim(s) 11, Henry teach further comprising:
receiving, by the network device (controller 30 + AP together is considered as the ‘network device’ [0049] Figure 2), a second SCS request (“RIC request” [0046] [0047], “TSPEC/TCLAS”, “TSPEC allows a wireless client to signal its traffic requirements to the AP” [0048], see note below) from the STA (“client” [0046]) (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),
wherein the second SCS request specifies one or more second sets of TCLAS information (“TCLAS is”, “that contains a set of parameters to identify incoming frames with a particular traffic stream” [0048]) for a second data flow (“TSPEC can include data rate, packet size, number of stream, etc.” [0048]) transmitted between the network device and the STA, each second set of TCLAS information (“TSPEC/TCLASS” [0048]) being accompanied by associated QoS profile information (“aggregated QoS policy”, “QoS information for each of the listed application identifiers” [0033]);
comparing, by the network device, the one or more second sets of TLCAS information and the associated QoS profile information (“QoS information” [0033]) with one or more cached application profiles (“5-tuple flow information (Src IP, Dst IP, ” [0025]);
determining that the one or more second sets of TCLAS information (“5-tuple flow information (Src IP, Dst IP, Src Port, Dst Port, Prototype)” [0025]) and the associated QoS profile information (“QoS policy can specify a number of other QoS metrics for each of the flows” [0016]) do not match (“not labeled” [0050]) any of the one or more cached application profiles (“NBAR engine in the wireless LAN controller”, “5-tuple flow information (Src IP, DST IP, “ [0025], “an entry in the state table” [0035], “NBAR table” [0049]);
performing, in response to the determination, by the network device, packet analysis (“deep packet inspection” [0049] [0051]) to determine a type of service (“to identify the target flow” [0049] [0051]) of the second data flow (“target flow” [0049]); and
confirming (“uniquely matched”, “an entry in the state table” [0035]), by the network device, that the one or more second sets of TCLAS information and the associated QoS profile information do not align (“flow matching” [0051]) with the determined type of service of the second data flow based on the one or more defined network policies (“QoS policy for network flows” [0033], uniquely matched by an AVC policy” [0035]).
13. Regarding claim(s) 16, Henry teach further comprising,
In response to the SCS request (“RIC request” [0046] [0047], “TSPEC/TCLAS”, “TSPEC allows a wireless client to signal its traffic requirements to the AP” [0048]), applying, by the network device, one or more second treatments (“QoS treatment” [0026]) to the data flow provisionally (“first upstream packets” [0026]) for a defined time frame (“until it receives new rules from the wireless LAN control” [0027]),
wherein the one or more second treatments (“examine the data portion within the packets of the particular flow” [0017], “reference the application by its the 5-tuple flow” [0025]) are consistent with the one or more sets of TCLAS information (“in order to determine information about the flow (e.g., a classification of the flow” [0017]) per the one or more defined network policies (“apply policies upstream on the AP” [0025]).
Claim Rejection – 35 U.S.C. 103 REJECTION
14. 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.
11. The factual inquiries for establishing a background for determining obviousness under pre-AIA 35 U.S.C. 103(a) are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
15. Claim(s) 3 is/are rejected under 35 USC 103 as being unpatentable over Henry, as applied to claim(s) 1 above, and further in view of Vutukuri et al. (US 20200322804 A1) hereinafter Vutukuri.
16. Regarding claim 3, Henry do not explicitly teach QoS characteristics comprise a desired data rate, however in a similar field of endeavor Vutukuri teach:
wherein the associated QoS profile information (“the QoS profile of the session” [0054]) comprises one or more QoS characteristics for the data flow, the one or more QoS characteristics (“characteristics” [0054]) comprising at least one of a desired data rate (“data rate characteristics” [0054]), a delay bound, traffic inter-arrival time, traffic service period, flow start time and a priority level indicated by a traffic identification (TID).
17. Thus, it would have been obvious before the effective filling date of the claimed invention to a person of ordinary skill in the art to readily recognize the advantage of modifying Henry’s system “network devices within the network can use a Quality of Service (QoS) policy to manage to relative priorities between the flows” (Henry [0016]) with the features of Vutukuri’s system 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]).
18. The motivation being to “assign priority levels and QoS requirements for each of the flows on a network device”, “may manually create a QoS policy that identify flows according to properties of flows”, “including prioritization” (Henry [0017]) which include “QoS policy details include the data rate to be supported and the security policy details include whether or not enable integrity protection” (Vutukuri [0015]) and “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” (Vutukuri [0054]).
19. Claim(s) 5 is/are rejected under 35 USC 103 as being unpatentable over Henry and Vutukuri, as applied to claim(s) 1 above, and further in view of Yachida (US 20110289540 A1).
20. Regarding claim 5, Henry do not explicitly teach a validation time for the packet analysis based on QoS characteristics of the data flow, however in a similar field of endeavor Yachida teach:
further comprising defining, by the network device, a validation time (“verifies the continuity of FEC packets” [0062] [0103], “the difference between the TTS time-stamp information in that TS packet and the TTS time-stamp information in preceding TS packet” [0101]) for the packet analysis (“FEC packet analysis” [0062]) based on the one or more QoS characteristics (“estimates the image quality of the image data based on the uncorrected data” [0024]) of the data flow (“packet data” [0043]).
21. Thus, it would have been obvious before the effective filling date of the claimed invention to a person of ordinary skill in the art to readily recognize the advantage of modifying Henry’s and Vutukuri’s system “network devices within the network can use a Quality of Service (QoS) policy to manage to relative priorities between the flows” (Henry [0016]) with the features of “an FEC packet analysis unit (3) verifies the continuity of FEC packets” (Yachida Abstract).
22. The motivation being to “assign priority levels and QoS requirements for each of the flows on a network device”, “may manually create a QoS policy that identify flows according to properties of flows”, “including prioritization” (Henry [0017]) which include a “estimates the image quality of the image data based on the uncorrected data” (Yachida [0024]).
23. Claim(s) 6 is/are rejected under 35 USC 103 as being unpatentable over Henry, as applied to claim(s) 1 above, and further in view of Kwan et al. (US 20090086634 A1) hereinafter Kwan.
24. Regarding claim 6, Henry do not explicitly teach applying a treatment to the data flow comprises allocating network resources for the data flow to satisfy a data rate requirement, however in a similar field of endeavor Kwan teach:
wherein applying the one or more treatments (“voice communications services” [0003]) to the data flow comprises allocating, by the network device, network resources (“allocation of resources” [0003]) for the data flow to satisfy one or more data rate requirements (“constant data rate transmission” [0003]), delay bound requirements, or traffic inter-arrival time and service period requirements of the data flow (“Class of Service (CoS)” [0004], “allocate resources to enable traffic to be transmitted at the minimum data transfer rate for a period of time” [0005]).
25. Thus, it would have been obvious before the effective filling date of the claimed invention to a person of ordinary skill in the art to readily recognize the advantage of modifying Henry’s system “network devices within the network can use a Quality of Service (QoS) policy to manage to relative priorities between the flows” (Henry [0016]) with the features of “as the range of services has expanded, the requirements for data networks have also expanded to accommodate the unique characteristics of the different service types” (Kwan [0003]) and “given that data networks do not have infinite bandwidth, multiservice data networks may be required to provide mechanisms for prioritizing the allocation of network resources among a diverse set of communication services” (Kwan [0004]).
26. The motivation being to “assign priority levels and QoS requirements for each of the flows on a network device”, “may manually create a QoS policy that identify flows according to properties of flows”, “including prioritization” (Henry [0017]) which include “voice communication services may require the allocation of resources within the network to enable constant data rate transmission” )Kwan [0003]).
27. Claim(s) 7 is/are rejected under 35 USC 103 as being unpatentable over Henry, as applied to claim(s) 1 above, and further in view of Balandin et al. (US 20060268699 A1) hereinafter Balandin.
28. Regarding claim(s) 7, Henry teach wherein applying the one or more treatments to the data flow (“increased QoS treatment” [0018]) comprises prioritizing (“including prioritization” [0017]), by the network device, the data flow in network queues to satisfy one or more priority level requirements (“priority level” [0017]) of the data flow (“assign priority levels and QoS requirements for each of the flows on a network device”, “may manually create a QoS policy that identify flows according to properties of flows”, “including prioritization” [0017]).
Henry do not explicitly teach treatment comprises prioritizing data flow in network queues to satisfy a priority level requirement, however in a similar field of endeavor Balandin teach:
one or more treatments (“treatment procedures for the QoS and BE traffic” [0021]) to the data flow (“traffic” [0023]) comprises prioritizing (“higher priority traffic is handled” [0023]), by the network device, the data flow in network queues (“a Priority buffer or Queue 24A, 24B” [0023]) to satisfy one or more priority level requirements (“collectively referred to as a Priority Queue 24” [0023]) of the data flow.
29. Thus, it would have been obvious before the effective filling date of the claimed invention to a person of ordinary skill in the art to readily recognize the advantage of modifying Henry’s system “network devices within the network can use a Quality of Service (QoS) policy to manage to relative priorities between the flows” (Henry [0016]) with the features of “a traffic treatment technique that employs two priority levels, where all or substantially all the corresponding buffering and management complexity” (Balandin [0015]) and “a Priority buffer or Que 24A, 24B, collectively referred to as a Priority Queue 24” (Balandin [0023]).
30. The motivation being to “assign priority levels and QoS requirements for each of the flows on a network device”, “may manually create a QoS policy that identify flows according to properties of flows”, “including prioritization” (Henry [0017]) which include “higher priority traffic is handled in”, “collectively referred to as Priority Queue 24” (Balandin [0023]).
31. Claim(s) 8 is/are rejected under 35 USC 103 as being unpatentable over Henry, as applied to claim(s) 1 and 2 above, and further in view of Fang et al. (EP 4135464) hereinafter Fang.
32. Regarding claim(s) 8, Henry do not explicitly teach time period for which the one treatment will be allocate to the STA, however in a similar field of endeavor Fang further teach wherein the first SCS response (“a target wake time (TWT) setup response” [0017], “schedules a TID-SP for performing time sensitive transmission” [0019]) further comprises an indication (“traffic identifier (TID)” [0008]) specifying a time period (“service period (SP)” [0008], “scheduling a TID-SP” [0009]) for which the one or more treatments (“service period (SP)” [0008], “a Quality of service (QoS) requirement” [0018]) will be allocated to the STA (“wireless station (STA)” [0009]).
33. Thus, it would have been obvious before the effective filling date of the claimed invention to a person of ordinary skill in the art to readily recognize the advantage of modifying Henry’s system “network devices within the network can use a Quality of Service (QoS) policy to manage to relative priorities between the flows” (Henry [0016]) with the features of “some networks operate using special timing requirements for time-sensitive transmission of data in deterministic networks” (Fang [0005]) and “provide a traffic identifier (TID) based restricted target wake time (RTWT) service period (SP)” (Fang [0008]).
34. The motivation being to “assign priority levels and QoS requirements for each of the flows on a network device”, “may manually create a QoS policy that identify flows according to properties of flows”, “including prioritization” (Henry [0017]) which include “provides a traffic identifier (TID) based restricted target wake time (RTWT) service period (SP)” (Fang [0008]) and “schedules a TID-SP for performing time sensitive transmission” (Fang [0019]).
35. Claim(s) 12 and 13 is/are rejected under 35 USC 103 as being unpatentable over Henry, as applied to claim(s) 1 and 11 above, and further in view of Hwang et al. (KR 20090033677) hereinafter Hwang and Soundararajan (US 20180035292 A1) hereinafter Soundararajan.
36. Regarding claim(s) 12, Henry teach further comprising:
after determining that the one or more second sets of TCLAS information (“TSPEC/TCLAS” [0049]) and the associated QoS profile information (traffic in the NBAR table” [0049]) do not match (“target traffic flow is not labeled in the client NBAR table” [0050]) any of the one or more cached application profiles (“an entry in the state table” [0035], “NBAR table” [0049]), sending, by the network device to the STA, a first SCS response indicating that SCS validation (“tries to match it against traffic” [0049]) is in processing;
after confirming (“uniquely matched”, “an entry in the state table”, “a label is added” [0035] [0037]), by the network device, that the one or more second sets of TCLAS information and the associated QoS profile information do not align (“not marking QoS” [0072], “QoS was not allowed” [0076]) with the determined type of service (“Quality of Service (QoS) treatment” [0076]) of the second data flow based on the one or more defined network polices, sending, by the network device to the STA, a second SCS response (“not in the whitelist” [0076]) indicating that the second SCS request has been denied (“mark traffic for which QoS was not allowed (not in the whitelist)”, “wipe the QoS marking out” [0076]).
Henry do not explicitly teach reclassifying to a second priority level lower than specified in the set of TCLAS and the associated QoS profile and assigning a treatment to data consistent with the priority level, however in a similar field of endeavor Hwang teach:
reclassifying (“reclassifies the flow” page 4 (8th para)), by the network device, the second data flow (“classification criteria having a lower priority” page 4 (8th para)) to a second priority level lower (“a lower priority” page 4 (8th para)) than specified in the one or more second sets of TCLAS (“for the classification criteria” page 4 (8th para)) and the associated QoS profile information (“measurement band” page 4 (8th para)); and
assigning (“allocates” page 4 (9th para)), by the network device, one or more second treatments (“allocates the packet section” page 4 (9th para)) to the second data flow that are consistent with the second priority level (“classification criteria having a lower priority” page 4 (8th para)).
37. Thus, it would have been obvious before the effective filling date of the claimed invention to a person of ordinary skill in the art to readily recognize the advantage of modifying Henry’s system “network devices within the network can use a Quality of Service (QoS) policy to manage to relative priorities between the flows” (Henry [0016]) with the features of “a circuit and packet traffic management apparatus and method for satisfying packet management efficiency by classifying and scheduling received data packets according to period information and band information for each flow” (Hwang page 2 (3rd para from bottom)).
38. The motivation being to “assign priority levels and QoS requirements for each of the flows on a network device”, “may manually create a QoS policy that identify flows according to properties of flows”, “including prioritization” (Henry [0017]) which include “packet traffic and a method thereof are provided to classify as received data packet into each flow per a period and differentially perform scheduling” (Hwang Abstract) and “reclassifying by the subdivided classification criteria” (Hwang page 4 (8th para)).
Henry and Hwang do not explicitly teach a set of TCLAS information and the associated QoS profile do not match any of the cached application profiles and sending a SCS response indicating that SCS validation is in processing, however in a similar field of endeavor Soundararajan teach:
after determining that the one or more second sets of TCLAS information (“TCLAS element, “TCLAS processing element” [0031]) and the associated QoS profile information (“QoS traffic capability element”, “QoS map set element” [0031]) do not match (“compares the plurality of capabilities with a preconfigured wireless network attribute policy” [0048], “denial based on received association validation decision” [0050]) any of the one or more cached application profiles (“compares the plurality of capabilities with a preconfigured” [0012], “a set of preconfigured WLAN attribute polices” [0030], “may cache a client identifier and the reason for denial for a predetermined period of time” [0050]), sending, by the network device to the STA, a first SCS response (“receives association response 245”, “transitions from an association phase to an association validation phase” [0029]) indicating that SCS validation is in processing (“association validation phase” [0050]).
39. Thus, it would have been obvious before the effective filling date of the claimed invention to a person of ordinary skill in the art to readily recognize the advantage of modifying Henry’s system “network devices within the network can use a Quality of Service (QoS) policy to manage to relative priorities between the flows” (Henry [0016]) with the features of “to perform association validation of a client device’s request” (Soundararajan Abstract) and “client device 200 receives association response 245, client device 200 transitions from an association phase to an association validation phase” (Soundararajan [0029]).
40. The motivation being to “assign priority levels and QoS requirements for each of the flows on a network device”, “may manually create a QoS policy that identify flows according to properties of flows”, “including prioritization” (Henry [0017]) which include “perform association validation of a client device’s request during an association validation phase based on a plurality of capabilities associated with the client device” (Soundararajan Abstract) and “once association validation server/authentication server 220 checks the client capabilities against a set of preconfigured WLAN attribute policies 250”, “server 220 will make an association validation decision” (Soundararajan [0033]).
41. Regarding claim(s) 13, Henry do not explicitly teach a SCS response indicating the priority level and the treatments have been assigned to the data flow by the network device, however in a similar field of endeavor Hwang teach:
further comprising sending, by the network device to the STA, a third SCS response (“detects the period of the data packet” page 4 (7th para), “again for the flow in which the measurement band exceeds” page 4 (8th para)) indicating the second priority level (“reclassifies the flow for the classification criteria having a lower priority level” page 4 (8th para)) and that the one or more second treatments (“if the measurement band of the reclassified flow does not exceed the reference band” page 4 (8th para)) have been assigned to the second data flow by the network device (“applies the flow to the scheduler 30” page 4 (8th para)).
42. Claim(s) 14 and 15 is/are rejected under 35 USC 103 as being unpatentable over Henry, as applied to claim(s) 1 and 11 above, and further in view of Soundararajan.
43. Regarding claim(s) 14, Henry further comprising:
after confirming (“uniquely matched”, “an entry in the state table”, “a label is added” [0035] [0037], “label to the state data” [0076]), by the network device, that the one or more second sets of TCLAS information and the associated QoS profile information do not align (“not marking QoS” [0072], “QoS was not allowed” [0076]) with the determined type of service (“Quality of Service (QoS) treatment” [0076]) of the second data flow based on the one or more defined network policies, sending, by the network device, a second SCS response (“not in the whitelist” [0076]) to the STA, indicating that the second SCS request has been denied (“mark traffic for which QoS was not allowed (not in the whitelist)”, “wipe the QoS marking out” [0076]); and
blocking (“wipe the QoS marking out” [0076]), by the network device, a transmission of the second data flow to the STA (“catch clients that may mark traffic for which QoS was not allowed” [0076]).
Henry do not explicitly teach a set of TCLAS information and the associated QoS profile do not match any cached application profiles and sending, by the network device to the STA, an SCS response indicating that SCS validation is in processing, however in a similar field of endeavor Soundararajan teach:
after determining that the one or more second sets of TCLAS information (“TCLAS element, “TCLAS processing element” [0031]) and the associated QoS profile information (“QoS traffic capability element”, “QoS map set element” [0031]) do not match (“compares the plurality of capabilities with a preconfigured wireless network attribute policy” [0048], “denial based on received association validation decision” [0050]) any of the one or more cached application profiles (“compares the plurality of capabilities with a preconfigured” [0012], “a set of preconfigured WLAN attribute polices” [0030], “may cache a client identifier and the reason for denial for a predetermined period of time” [0050]), sending, by the network device to the STA, a first SCS response (“receives association response 245”, “transitions from an association phase to an association validation phase” [0029]) indicating that SCS validation is in processing (“association validation phase” [0050]).
44. Regarding claim(s) 15, Henry teach:
wherein the network device comprises at least one of an access point (AP) (controller 310 + AP 20(1) in Figure 3), a wireless local areas network controller (WLC), a network security appliance, or a gateway, and
Henry do not explicitly teach network device comprises of being integrated with a network policy enforcement function (PEF), however in a similar field of endeavor Soundararajan teach:
wherein the network device is integrated (“Fig. 1 includes”, “server 110” [0014] [0026]) with a network policy enforcement function (PEF) (“policy may be a set of client capabilities based rules”, “association validation server/authentication server to enforce a client capability-based authentication rule” [0024]).
CONCLUSION
45. 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 O. Charlie Vostal whose telephone number is (571) 272-2536. The examiner can normally be reached on Monday-Friday from 8:00 am to 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Glenton Burgess can be reached at telephone number (571)-272-3949. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/ONDREJ C VOSTAL/ Examiner, Art Unit 2454
January 22, 2026
/JOHN A FOLLANSBEE/ Supervisory Patent Examiner, Art Unit 2444