DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
The office action is in response to the claim amendments and remarks filed on September 25, 2025 for the application filed June 15, 2022. Claims 1-4, 7-8, 10, 12-24 are currently pending.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 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 nonobviousness.
Claims 1-3, 7-8, 10, 12, 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Duo et al. (US2017/0289837A1) in view of Naik et al. (US2023/0262585A1), and Patil et al. (US2018/0302923A1).
Regarding claim 1, Duo teaches a method comprising: monitoring, by an access point (AP), data traffic corresponding to a client device associated with a first virtual access point (VAP) hosted on the AP (Paragraph [0023]: A wireless local area network (WLAN) access point may receive a steering policy from a WLAN controller, the steering policy matching various data rate capabilities to various quality of service (QoS) levels. When a client device attempts to connect to the access point (AP), the access point responds via a default virtual access point (VAP) so that the client device transmits its client data rate capability to the AP via association request. The AP then checks the steering policy and either allows the connection to the default virtual access point if the quality of service of the default virtual access point matches the client data rate or identifies a second virtual access point (which the access point may generate if it doesn't already exist) whose quality of service does match the client data rate. The access point may then initiate WLAN communications between the client device and the matching virtual access point. Client devices with higher data rate capabilities may thus receive higher priority. Paragraph [0048]: Client device connections are steered (e.g., see steering process of FIG. 3) so that each virtual access point serves client devices that are to be granted the same quality of service. This allows easier and more efficient segregation of traffic from and/or to a number of client devices with a diverse range of data rate capabilities 170, and allows for the type of prioritization of requests illustrated in the efficient data prioritization 185 of FIG. 2B. Paragraph [0064]: The WLAN controller 305 may periodically or manually (e.g., via command from a network administrator) re-provision the steering policy to the access point 310 in order to update the steering policy (e.g., to enable/disable steering 290, to adjust assignments of quality of service levels to different data rate capabilities matching different standards). For example, different steering policies may be used at different times of day (or particular days of the week/month/year) to deal with surges in network traffic or surges in particular types (e.g., particular wireless protocols) of network traffic. Paragraph [0005]: An access point (AP) or virtual access point (VAP), with its client devices, may sometimes be referred to as a basic service set (BSS), and may be uniquely identified by a service set identification (SSID). Paragraph [0065]: At step 325, the client device 315 transmits a probe request to a service set identification (SSID) corresponding to the access point 310. The access point 310 directs this prove request to a “default” virtual access point, VAP_x 380.)
determining, by the AP, a communication demand of the client device based on the data traffic corresponding to the client device; steering, by the AP, the client device to the second VAP based on the communication demand and the QoS parameter; and communicating, by the AP, with the client device through the second VAP (Paragraph [0046]: The steering policy 295B of FIG. 2B identifies different quality of service (QoS) levels based on the data rate capabilities 170 of each client device. There are four quality of service (QoS) levels identified in FIG. 2B, which follow the four WiFi Multimedia (WMM) standard quality of service (QoS) levels—the best quality of service level being the “voice data” quality of service level (“AC-VO”), followed by the good “video data” quality of service level (“AC-VI”), followed by the fair “best-effort data” quality of service level (“AC-BE”), finally followed by the poor “background data” quality of service level (“AC-BK”). Paragraph [0063]: At step 320, the WLAN controller 305 provisions the steering policy to the access point 310. The steering policy provisioning of step 320 may occur automatically when the access point 310 is communicatively coupled to the WLAN controller 305, or may occur automatically, periodically, or manually (e.g., via command from a network administrator) at a later time. The steering policy may identify whether client steering is enabled or disabled, may identify whether clustering is enabled or disabled (e.g., and if it is enabled, then how), and may finally a table or database (e.g., as in FIG. 4) identifying what quality of service (QoS) level should be provided by each virtual access point of that access point 310. Paragraph [0064]: The WLAN controller 305 may periodically or manually (e.g., via command from a network administrator) re-provision the steering policy to the access point 310 in order to update the steering policy (e.g., to enable/disable steering 290, to adjust assignments of quality of service levels to different data rate capabilities matching different standards). For example, different steering policies may be used at different times of day (or particular days of the week/month/year) to deal with surges in network traffic or surges in particular types (e.g., particular wireless protocols) of network traffic. Paragraph [0065]: At step 325, the client device 315 transmits a probe request to a service set identification (SSID) corresponding to the access point 310. The access point 310 directs this prove request to a “default” virtual access point, VAP_x 380. Paragraph [0069]: At step 345, the client device 315 transmits an association request to the access point 310, and in particular to the “default” virtual access point, VAP_x 380. The association request of step 345 includes information about the client device 315, and may for example include a data rate capability 170 information element (IE), which may be referred to in some cases as a “basic supported rate” information element or a “basic service rate” information element. For example, a client using 802.11n typically transmits a “High Throughput” (HT) Capability information element, and a client using 802.11ac typically transmits a “Very High Throughput” (VHT) Capability information element. Paragraph [0070]: ….the WLAN access point 310 consults the steering policy it received from the WLAN controller in step 320 to determine whether the “default” virtual access point VAP_x 380 is appropriate for the client device 315 or whether the client device 315 should be steered to a different virtual access point. If VAP_x 380 is appropriate for the client device 315 (e.g., the quality of service of the virtual access point matches the data rate capability 170 of the client device 315), then the client device 315 can be connected to VAP_x 380 (not shown in FIG. 3). If not, then the process moves on to step 355. Paragraph [0071]: At step 355, the WLAN access point 310 generates a new virtual access point, VAP_y 385, to associate with the client device 315 so that the quality of service of VAP_y 385 matches the data rate capability 170 of the client device 315 as dictated by the steering policy 320. Paragraph [0074]: At step 370, the access point 310 sends a new probe response from the new virtual access point VAP_y 385 that was generated in step 355. Paragraph [0075]: At step 375, the access point 310 and the client device 315 continue with authentication, association, and handshakes (e.g., according to IEEE 802.11i standards) and any other necessary operations for the client device 315 to connect to the virtual access point VAP_y 385 of the physical access point 310.)
Duo does not explicitly teach wherein the first VAP is mapped to a first Multiple Basic Service Set Identifier (MBSSID) set and configured as a transmitted VAP or a non-transmitted VAP of the first MBSSID set, wherein the AP also hosts a second VAP mapped to a second MBSSID set and configured as a transmitted VAP or a non-transmitted VAP of the second MBSSID set.
However, Naik teaches wherein the first VAP is mapped to a first Multiple Basic Service Set Identifier (MBSSID) set and configured as a transmitted VAP or a non-transmitted VAP of the first MBSSID set, wherein the AP also hosts a second VAP mapped to a second MBSSID set and configured as a transmitted VAP or a non-transmitted VAP of the second MBSSID set (Paragraph [0057]: The wireless network 350 may include three links. A link 1 may have a first MBSSID set (or a first set of APs) AP11, AP21, . . . , APN1, a link 2 may have a second MBSSID set (or a second set of APs) AP12, AP22, . . . , APN2, and link 3 may have a third MBSSID set (or a third set of APs) AP13, AP23, . . . , APN3. Also, the wireless network 350 may include a first MLD 352 affiliated with AP11, AP12, and AP13, a second MLD 354 associated with AP21, AP22, and AP23, and an Nth MLD 356 associated with APN1, APN2, and APN3. Paragraph [0058]: The AP configured to transmit the beacon frames may be referred to as the TxBSSID and other BSSID may be referred to as the non-TxBSSIDs. In some aspects, each BSSID in the MBSSID set may be referred to as a Virtual Access Point (VAP). Paragraph [0059]: In some aspects, one AP, e.g., AP11 of an AP MLD may be in an MBSSID set and is the TxBSSID, and a network management frame, e.g., a beacon frame or a probe response frame, may include an ML element, which includes information of AP12 and AP13, an MBSSID element, which includes information of AP21, . . . , APN1, and an ML sub-element within the MBSSID element, which includes information of AP22, . . . , AP N3.)
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the first VAP is mapped to a first Multiple Basic Service Set Identifier (MBSSID) set and configured as a transmitted VAP or a non-transmitted VAP of the first MBSSID set, wherein the AP also hosts a second VAP mapped to a second MBSSID set and configured as a transmitted VAP or a non-transmitted VAP of the second MBSSID set, as taught by Naik in the system of Duo, so that a beacon frame can include information pertaining to the access points (VAPs) belonging to a specific MBSSID set, and reduce overload on the beacon (Naik: Paragraphs [0058], [0059], [0060]).
The combination of Duo and Naik does not explicitly teach wherein the first MBSSID set is configured with a first quality of service (QoS) parameter and the second MBSSID set is configured with a second QoS parameter.
However, Patil teaches wherein the first MBSSID set is configured with a first quality of service (QoS) parameter and the second MBSSID set is configured with a second QoS parameter (Abstract: This disclosure provides systems, methods, and apparatuses for operating a wireless station in a multiple basic service set identifier (BSSID) set including a transmitted BSSID (Tx BSSID) and a number of non-transmitted BSSIDs (non-Tx BSSIDs). Paragraph [0004]: An AP may create and operate multiple BSSs at the same time, and may assign (or associate) a number of wireless devices to each of the BSSs. Each of the multiple BSSs may operate independently of each other and yet use the same AP. Because different BSSs may include different numbers of wireless devices, may have different security parameters and access privileges, and may include different types of wireless devices (such as IoT devices, Wi-Fi devices, and so on), it may be desirable for the AP to prioritize the allocation of resources between multiple BSSs. Paragraph [0040]: A multiple basic service set identification (BSSID) set may include a plurality of basic service set (BSSs) each associated with or operated by a corresponding access point (AP) or virtual access point. All APs belonging to a multiple BSSID set all use a common operating class, a common channel, a common channel access mechanism. Paragraph [0128]: Referring again to FIG. 1B, the AP 140 may create and independently operate a plurality of basic service sets BSS0-BSSk (such as by using the virtual access points VAP1-VAPk), and each of the basic service sets BSS0-BSSk may include a different number of wireless devices or stations. In some implementations, the AP 140 may assign each of the example stations STA1-STA99 of FIG. 1B to a particular one of the basic service sets BSS0-BSSk based on a number of parameters of one or more of the basic service sets BSS0-BSSk. In some aspects, the number of parameters of a given one of the basic service sets BSS0-BSSk may include one or more of: security parameters of the given BSS, access privileges of the wireless devices associated with or belonging to the given BSS, the types of wireless devices (such as IoT devices, Wi-Fi devices, and so on) associated with or belonging to the given BSS, quality of service (QoS) parameters of the given BSS, delay requirements (such as relatively short delays for voice traffic and relatively long delays for background or best effort traffic) of the wireless devices associated with or belonging to the given BSS, bandwidth capabilities of the wireless devices associated with or belonging to the given BSS (such as narrowband capabilities and wideband capabilities), and any other suitable metric or characteristic that may be used to prioritize the allocation of random RUs to the plurality of basic service sets BSS0-BSSk.)
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the first MBSSID set is configured with a first quality of service (QoS) parameter and the second MBSSID set is configured with a second QoS parameter, as taught by Patil in the combined system of Duo and Naik, so that the basic service sets serving various devices with different requirements, can be allocated resources accordingly, and the wireless devices or STAs can be assigned to a basic service set based on parameters such as a quality of service parameter (Patil: Paragraphs [0004], [0128]).
Regarding claim 2, the combination of Duo, Naik, and Patil teaches the method of claim 1 (see rejection for claim 1);
Duo further teaches wherein monitoring the data traffic comprises: classifying the data traffic into a plurality of data traffic types corresponding to the client device; and determining the communication demand based on the plurality of data traffic types (Abstract: A wireless local area network (WLAN) access point may receive a steering policy from a WLAN controller, the steering policy matching various data rate capabilities to various quality of service (QoS) levels. When a client device attempts to connect to the access point (AP), the AP responds via a default virtual access point (VAP) so that the client device transmits its client data rate capability to the AP via association request. The AP then checks the steering policy and either allows the connection to the default VAP if the QoS of the default VAP matches the client data rate or identifies a second VAP (which the AP may generate if it doesn't already exist) whose QoS does match the client data rate. The AP may then initiate WLAN communications between the client device and the matching VAP. Client devices with higher data rate capabilities may thus receive higher priority. Paragraph [0048]: Client device connections are steered (e.g., see steering process of FIG. 3) so that each virtual access point serves client devices that are to be granted the same quality of service. This allows easier and more efficient segregation of traffic from and/or to a number of client devices with a diverse range of data rate capabilities 170, and allows for the type of prioritization of requests illustrated in the efficient data prioritization 185 of FIG. 2B. Paragraph [0069]: The association request of step 345 includes information about the client device 315, and may for example include a data rate capability 170 information element (IE), which may be referred to in some cases as a “basic supported rate” information element or a “basic service rate” information element. For example, a client using 802.11n typically transmits a “High Throughput” (HT) Capability information element, and a client using 802.11ac typically transmits a “Very High Throughput” (VHT) Capability information element. Paragraph [0078]: Priority can be granted to client devices according to data rate capabilities 170 of wirelessly connected client devices. For example, a client device with very-high-throughput (VHT) capability (e.g., a 802.11ac client device) may be given the best quality of service by getting Voice Data (“AC-VO”) quality of service (see row AC-3 435). A client device with high-throughput (HT) capability but without VHT capability (e.g., a 802.11n client device) may be given the good quality of service by getting Video Data (“AC-VI”) quality of service (see row AC-2 430). A client device with a data rate capability 170 greater than 48 Mbps but without HT or VHT capability (e.g., a 802.11g client device) may be given the fair quality of service by getting Best-Effort Data (“AC-BE”) quality of service (see row AC-1 425). A client device with a data rate capability 170 lower than 11 Mbps (e.g., a 802.11b or 802.11a client device) may be given the poor quality of service by getting Background Data (“AC-BK”) quality of service (see row AC-1420).)
Regarding claim 3, the combination of Duo, Naik, and Patil teaches the method of claim 1 (see rejection for claim 1);
Duo further teaches wherein monitoring the data traffic comprises: transmitting, by the AP, a capability request frame to the client device; and receiving, by the AP, a capability response frame from the client device, wherein the capability response frame comprises communication capabilities of the client devices, and wherein the communication demand of the client device is determined based on the response frame (Paragraph [0063]: At step 320, the WLAN controller 305 provisions the steering policy to the access point 310. The steering policy provisioning of step 320 may occur automatically when the access point 310 is communicatively coupled to the WLAN controller 305, or may occur automatically, periodically, or manually (e.g., via command from a network administrator) at a later time. The steering policy may identify whether client steering is enabled or disabled, may identify whether clustering is enabled or disabled (e.g., and if it is enabled, then how), and may finally a table or database (e.g., as in FIG. 4) identifying what quality of service (QoS) level should be provided by each virtual access point of that access point 310. Paragraph [0064]: The WLAN controller 305 may periodically or manually (e.g., via command from a network administrator) re-provision the steering policy to the access point 310 in order to update the steering policy (e.g., to enable/disable steering 290, to adjust assignments of quality of service levels to different data rate capabilities matching different standards). For example, different steering policies may be used at different times of day (or particular days of the week/month/year) to deal with surges in network traffic or surges in particular types (e.g., particular wireless protocols) of network traffic. Paragraph [0065]: At step 325, the client device 315 transmits a probe request to a service set identification (SSID) corresponding to the access point 310. The access point 310 directs this prove request to a “default” virtual access point, VAP_x 380. Paragraph [0066]: At step 330, the access point 310 replies to the client device 315 with a probe response from the “default” virtual access point, VAP_x 380. Paragraph [0067]: At step 335, the client device 315 transmits an authentication request to the access point 310 and in particular to the “default” virtual access point, VAP_x 380. Paragraph [0068]: At step 340, the access point 310 transmits an authentication response that is received by the client device 315. Paragraph [0069]: At step 345, the client device 315 transmits an association request to the access point 310, and in particular to the “default” virtual access point, VAP_x 380. The association request of step 345 includes information about the client device 315, and may for example include a data rate capability 170 information element (IE), which may be referred to in some cases as a “basic supported rate” information element or a “basic service rate” information element. For example, a client using 802.11n typically transmits a “High Throughput” (HT) Capability information element, and a client using 802.11ac typically transmits a “Very High Throughput” (VHT) Capability information element. Paragraph [0070]: At step 350, the WLAN access point 310 consults the steering policy it received from the WLAN controller in step 320 to determine whether the “default” virtual access point VAP_x 380 is appropriate for the client device 315 or whether the client device 315 should be steered to a different virtual access point. If VAP_x 380 is appropriate for the client device 315 (e.g., the quality of service of the virtual access point matches the data rate capability 170 of the client device 315), then the client device 315 can be connected to VAP_x 380 (not shown in FIG. 3). If not, then the process moves on to step 355. Paragraph [0071]: At step 355, the WLAN access point 310 generates a new virtual access point, VAP_y 385, to associate with the client device 315 so that the quality of service of VAP_y 385 matches the data rate capability 170 of the client device 315 as dictated by the steering policy 320.)
Regarding claim 7, the combination of Duo, Naik, and Patil teaches the method of claim 1 further comprising (see rejection for claim 1);
Duo further teaches maintaining, by the AP, association of the client device with the first VAP in response to determining that the first QoS parameter is relevant to the communication demand of the client device (Paragraph [0063]: At step 320, the WLAN controller 305 provisions the steering policy to the access point 310. The steering policy provisioning of step 320 may occur automatically when the access point 310 is communicatively coupled to the WLAN controller 305, or may occur automatically, periodically, or manually (e.g., via command from a network administrator) at a later time. The steering policy may identify whether client steering is enabled or disabled, may identify whether clustering is enabled or disabled (e.g., and if it is enabled, then how), and may finally a table or database (e.g., as in FIG. 4) identifying what quality of service (QoS) level should be provided by each virtual access point of that access point 310. Paragraph [0070]: At step 350, the WLAN access point 310 consults the steering policy it received from the WLAN controller in step 320 to determine whether the “default” virtual access point VAP_x 380 is appropriate for the client device 315 or whether the client device 315 should be steered to a different virtual access point. If VAP_x 380 is appropriate for the client device 315 (e.g., the quality of service of the virtual access point matches the data rate capability 170 of the client device 315), then the client device 315 can be connected to VAP_x 380 (not shown in FIG. 3). If not, then the process moves on to step 355.)
Regarding claim 8, the combination of Duo, Naik, and Patil teaches the method of claim 1 further comprising a plurality of MBSSID sets (see rejection for claim 1);
Duo further teaches searching, by the AP, to find a relevant set corresponding to the communication demand of the client device in response to determining that the first QoS parameter is irrelevant to the communication demand of the client device; and determining, by the AP, that the second set is the relevant set corresponding to the communication demand of the client device based on the searching (Paragraph [0046]: The steering policy 295B of FIG. 2B identifies different quality of service (QoS) levels based on the data rate capabilities 170 of each client device. There are four quality of service (QoS) levels identified in FIG. 2B, which follow the four WiFi Multimedia (WMM) standard quality of service (QoS) levels—the best quality of service level being the “voice data” quality of service level (“AC-VO”), followed by the good “video data” quality of service level (“AC-VI”), followed by the fair “best-effort data” quality of service level (“AC-BE”), finally followed by the poor “background data” quality of service level (“AC-BK”). Paragraph [0064]: The WLAN controller 305 may periodically or manually (e.g., via command from a network administrator) re-provision the steering policy to the access point 310 in order to update the steering policy (e.g., to enable/disable steering 290, to adjust assignments of quality of service levels to different data rate capabilities matching different standards). For example, different steering policies may be used at different times of day (or particular days of the week/month/year) to deal with surges in network traffic or surges in particular types (e.g., particular wireless protocols) of network traffic. Paragraph [0069]: At step 345, the client device 315 transmits an association request to the access point 310, and in particular to the “default” virtual access point, VAP_x 380. The association request of step 345 includes information about the client device 315, and may for example include a data rate capability 170 information element (IE), which may be referred to in some cases as a “basic supported rate” information element or a “basic service rate” information element. For example, a client using 802.11n typically transmits a “High Throughput” (HT) Capability information element, and a client using 802.11ac typically transmits a “Very High Throughput” (VHT) Capability information element. Paragraph [0070]: At step 350, the WLAN access point 310 consults the steering policy it received from the WLAN controller in step 320 to determine whether the “default” virtual access point VAP_x 380 is appropriate for the client device 315 or whether the client device 315 should be steered to a different virtual access point. If VAP_x 380 is appropriate for the client device 315 (e.g., the quality of service of the virtual access point matches the data rate capability 170 of the client device 315), then the client device 315 can be connected to VAP_x 380 (not shown in FIG. 3). If not, then the process moves on to step 355. Paragraph [00071]: At step 355, the WLAN access point 310 generates a new virtual access point, VAP_y 385, to associate with the client device 315 so that the quality of service of VAP_y 385 matches the data rate capability 170 of the client device 315 as dictated by the steering policy 320.)
The combination of Duo and Naik does not explicitly teach a relevant MBSSID set; that the second MBSSID set is the relevant MBSSID set.
However, Patil teaches a relevant MBSSID set; that the second MBSSID set is the relevant MBSSID set (Abstract: This disclosure provides systems, methods, and apparatuses for operating a wireless station in a multiple basic service set identifier (BSSID) set including a transmitted BSSID (Tx BSSID) and a number of non-transmitted BSSIDs (non-Tx BSSIDs). Paragraph [0004]: An AP may create and operate multiple BSSs at the same time, and may assign (or associate) a number of wireless devices to each of the BSSs. Each of the multiple BSSs may operate independently of each other and yet use the same AP. Because different BSSs may include different numbers of wireless devices, may have different security parameters and access privileges, and may include different types of wireless devices (such as IoT devices, Wi-Fi devices, and so on), it may be desirable for the AP to prioritize the allocation of resources between multiple BSSs. Paragraph [0128]: Referring again to FIG. 1B, the AP 140 may create and independently operate a plurality of basic service sets BSS0-BSSk (such as by using the virtual access points VAP1-VAPk), and each of the basic service sets BSS0-BSSk may include a different number of wireless devices or stations. In some implementations, the AP 140 may assign each of the example stations STA1-STA99 of FIG. 1B to a particular one of the basic service sets BSS0-BSSk based on a number of parameters of one or more of the basic service sets BSS0-BSSk. In some aspects, the number of parameters of a given one of the basic service sets BSS0-BSSk may include one or more of: security parameters of the given BSS, access privileges of the wireless devices associated with or belonging to the given BSS, the types of wireless devices (such as IoT devices, Wi-Fi devices, and so on) associated with or belonging to the given BSS, quality of service (QoS) parameters of the given BSS, delay requirements (such as relatively short delays for voice traffic and relatively long delays for background or best effort traffic) of the wireless devices associated with or belonging to the given BSS, bandwidth capabilities of the wireless devices associated with or belonging to the given BSS (such as narrowband capabilities and wideband capabilities), and any other suitable metric or characteristic that may be used to prioritize the allocation of random RUs to the plurality of basic service sets BSS0-BSSk.)
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide a relevant MBSSID set; that the second MBSSID set is the relevant MBSSID set, as taught by Patil in the combined system of Duo and Naik, so that the wireless devices or STAs can be assigned to a relevant basic service set based on parameters such as a quality of service parameter (Patil: Paragraphs [0004], [0128]).
Regarding claim 10, Duo teaches an access point (AP), comprising: a machine-readable storage medium storing executable instructions; and a processing resource coupled to the machine-readable storage medium, wherein the processing resource executes one or more of the executable instructions to: (Paragraph [0012]: The system also includes a memory. The system also includes a processor coupled to the memory and to the communication transceiver. Execution of instructions stored in the memory by the processor performs system operations. Paragraph [0013]: One exemplary non-transitory computer-readable storage medium may have embodied thereon a program executable by a processor to perform a method for wireless network optimization. The exemplary program method includes receiving a steering policy that identifies matches between a plurality of data rate capabilities and a plurality of quality of service levels. Paragraph [0023]: A wireless local area network (WLAN) access point may receive a steering policy from a WLAN controller, the steering policy matching various data rate capabilities to various quality of service (QoS) levels. Paragraph [0081]: For example, any of the computer systems or computerized devices described herein (e.g., WLAN controller 305/205, access point 310/210/230, client device 315/215/220/225/235/240/245) may, in at least some cases, be a computing system 500, or may include at least a subset of the elements of the computing system 500 illustrated in FIG. 5. The computing system 500 of FIG. 5 includes one or more processors 510 and memory 510. Main memory 510 stores, in part, instructions and data for execution by processor 510. Main memory 510 can store the executable code when in operation. The system 500 of FIG. 5 further includes a mass storage device 530, portable storage medium drive(s) 540, output devices 550, user input devices 560, a graphics display 570, and peripheral devices 580.)
monitor data traffic corresponding to a client device associated with a first virtual access point (VAP) hosted on the AP; determine a communication demand of the client device based on the data traffic corresponding to the client device; steer the client device to the second VAP based on the communication demand and the QoS parameter; and communicate with the client device through the second VAP (see rejection for claim 1).
Duo does not explicitly teach wherein the first VAP is mapped to a first Multiple Basic Service Set Identifier (MBSSID) set and configured as a transmitted VAP or anon-transmitted VAP of the first MBSSID set, wherein the AP also hosts a second VAP mapped to a second MBSSID set and configured as a transmitted VAP or anon-transmitted VAP of the second MBSSID set.
However, Naik teaches wherein the first VAP is mapped to a first Multiple Basic Service Set Identifier (MBSSID) set and configured as a transmitted VAP or anon-transmitted VAP of the first MBSSID set, wherein the AP also hosts a second VAP mapped to a second MBSSID set and configured as a transmitted VAP or anon-transmitted VAP of the second MBSSID set (see rejection for claim 1);
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the first VAP is mapped to a first Multiple Basic Service Set Identifier (MBSSID) set and configured as a transmitted VAP or anon-transmitted VAP of the first MBSSID set, wherein the AP also hosts a second VAP mapped to a second MBSSID set and configured as a transmitted VAP or anon-transmitted VAP of the second MBSSID set, as taught by Naik in the system of Duo, so that a beacon frame can include information pertaining to the access points (VAPs) belonging to a specific MBSSID set, and reduce overload on the beacon (Naik: Paragraphs [0058], [0059], [0060]).
The combination of Duo and Naik does not explicitly teach wherein the first MBSSID set is configured with a first quality of service (QoS) parameter and the second MBSSID set is configured with a second QoS parameter.
However, Patil teaches wherein the first MBSSID set is configured with a first quality of service (QoS) parameter and the second MBSSID set is configured with a second QoS parameter (see rejection for claim 1);
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the first MBSSID set is configured with a first quality of service (QoS) parameter and the second MBSSID set is configured with a second QoS parameter, as taught by Patil in the combined system of Duo and Naik, so that the basic service sets serving various devices with different requirements, can be allocated resources accordingly, and the wireless devices or STAs can be assigned to a basic service set based on parameters such as a quality of service parameter (Patil: Paragraphs [0004], [0128]).
Regarding claim 12, the combination of Duo, Naik, and Patil teaches the AP of claim 10 wherein the processing resource executes one or more of the instructions to (see rejection for claim 10);
Duo further teaches to transmit a capability request frame to the client device; receive a capability response frame from the client device, wherein the capability response frame comprises communication capabilities of the client devices; and determine the communication demand based on the response frame (see rejection for claim 3).
Regarding claim 16, the combination of Duo, Naik, and Patil teaches the AP of claim 10 wherein the processing resource executes one or more of the instructions to (see rejection for claim 10);
Duo further teaches to maintain an association of the client device with the first VAP in response to determining that the first QoS parameter is relevant to the communication demand of the client device (see rejection for claim 7).
Regarding claim 17, the combination of Duo, Naik, and Patil teaches the AP of claim 10, wherein the processing resource executes one or more of the instructions to; a plurality of MBSSID sets (see rejection for claim 10);
Duo further teaches to search to find a relevant set corresponding to the communication demand of the client device in response to determining that the first QoS parameter is irrelevant to the communication demand of the client device; and determine that the second set is the relevant set corresponding to the communication demand of the client device based on the search (see rejection for claim 8);
The combination of Duo and Naik does not explicitly teach a relevant MBSSID set; that the second MBSSID set is the relevant MBSSID set.
However, Patil teaches a relevant MBSSID set; that the second MBSSID set is the relevant MBSSID set (see rejection for claim 8);
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide a relevant MBSSID set; that the second MBSSID set is the relevant MBSSID set, as taught by Patil in the combined system of Duo and Naik, so that the wireless devices or STAs can be assigned to a relevant basic service set based on parameters such as a quality of service parameter (Patil: Paragraphs [0004], [0128]).
Regarding claim 18, Duo teaches a system, comprising: a client device; and an access point (AP) communicatively coupled to the client device (Paragraph [0040]: The WLAN access point 210 is wirelessly communicatively coupled to three client devices, namely: a client device 215 that uses 802.11ac, a client device 220 that also uses 802.11ac, and a client device 225 that uses 802.11g. The WLAN access point 230 is wirelessly communicatively coupled to three other client devices, namely: a client device 235 that uses 802.11 ac, a client device 240 that uses 802.11n, and a client device 245 that uses 802.11b. In an alternate embodiment, one or both of the WLAN access point 210 or WLAN access point 215 can be virtual access points generated by the WLAN controller 205)
wherein the AP hosts a first virtual access point (VAP) and a second VAP, and wherein the client device is associated with the first VAP, and wherein the AP is configured to: monitor data traffic corresponding to the client device (Paragraph [0023]: A wireless local area network (WLAN) access point may receive a steering policy from a WLAN controller, the steering policy matching various data rate capabilities to various quality of service (QoS) levels. When a client device attempts to connect to the access point (AP), the access point responds via a default virtual access point (VAP) so that the client device transmits its client data rate capability to the AP via association request. The AP then checks the steering policy and either allows the connection to the default virtual access point if the quality of service of the default virtual access point matches the client data rate or identifies a second virtual access point (which the access point may generate if it doesn't already exist) whose quality of service does match the client data rate. The access point may then initiate WLAN communications between the client device and the matching virtual access point. Client devices with higher data rate capabilities may thus receive higher priority. Paragraph [0048]: Client device connections are steered (e.g., see steering process of FIG. 3) so that each virtual access point serves client devices that are to be granted the same quality of service. This allows easier and more efficient segregation of traffic from and/or to a number of client devices with a diverse range of data rate capabilities 170, and allows for the type of prioritization of requests illustrated in the efficient data prioritization 185 of FIG. 2B. Paragraph [0064]: The WLAN controller 305 may periodically or manually (e.g., via command from a network administrator) re-provision the steering policy to the access point 310 in order to update the steering policy (e.g., to enable/disable steering 290, to adjust assignments of quality of service levels to different data rate capabilities matching different standards). For example, different steering policies may be used at different times of day (or particular days of the week/month/year) to deal with surges in network traffic or surges in particular types (e.g., particular wireless protocols) of network traffic. Paragraph [0005]: An access point (AP) or virtual access point (VAP), with its client devices, may sometimes be referred to as a basic service set (BSS), and may be uniquely identified by a service set identification (SSID). Paragraph [0065]: At step 325, the client device 315 transmits a probe request to a service set identification (SSID) corresponding to the access point 310. The access point 310 directs this prove request to a “default” virtual access point, VAP_x 380.)
determine a communication demand of the client device based on the data traffic corresponding to the client device; steer the client device to the second VAP based on the communication demand and the QoS parameter; and communicate with the client device through the second VAP (Paragraph [0046]: The steering policy 295B of FIG. 2B identifies different quality of service (QoS) levels based on the data rate capabilities 170 of each client device. There are four quality of service (QoS) levels identified in FIG. 2B, which follow the four WiFi Multimedia (WMM) standard quality of service (QoS) levels—the best quality of service level being the “voice data” quality of service level (“AC-VO”), followed by the good “video data” quality of service level (“AC-VI”), followed by the fair “best-effort data” quality of service level (“AC-BE”), finally followed by the poor “background data” quality of service level (“AC-BK”). Paragraph [0063]: At step 320, the WLAN controller 305 provisions the steering policy to the access point 310. The steering policy provisioning of step 320 may occur automatically when the access point 310 is communicatively coupled to the WLAN controller 305, or may occur automatically, periodically, or manually (e.g., via command from a network administrator) at a later time. The steering policy may identify whether client steering is enabled or disabled, may identify whether clustering is enabled or disabled (e.g., and if it is enabled, then how), and may finally a table or database (e.g., as in FIG. 4) identifying what quality of service (QoS) level should be provided by each virtual access point of that access point 310. Paragraph [0064]: The WLAN controller 305 may periodically or manually (e.g., via command from a network administrator) re-provision the steering policy to the access point 310 in order to update the steering policy (e.g., to enable/disable steering 290, to adjust assignments of quality of service levels to different data rate capabilities matching different standards). For example, different steering policies may be used at different times of day (or particular days of the week/month/year) to deal with surges in network traffic or surges in particular types (e.g., particular wireless protocols) of network traffic. Paragraph [0065]: At step 325, the client device 315 transmits a probe request to a service set identification (SSID) corresponding to the access point 310. The access point 310 directs this prove request to a “default” virtual access point, VAP_x 380. Paragraph [0066]: At step 330, the access point 310 replies to the client device 315 with a probe response from the “default” virtual access point, VAP_x 380. Paragraph [0067]: At step 335, the client device 315 transmits an authentication request to the access point 310 and in particular to the “default” virtual access point, VAP_x 380. Paragraph [0068]: At step 340, the access point 310 transmits an authentication response that is received by the client device 315. Paragraph [0069]: At step 345, the client device 315 transmits an association request to the access point 310, and in particular to the “default” virtual access point, VAP_x 380. The association request of step 345 includes information about the client device 315, and may for example include a data rate capability 170 information element (IE), which may be referred to in some cases as a “basic supported rate” information element or a “basic service rate” information element. For example, a client using 802.11n typically transmits a “High Throughput” (HT) Capability information element, and a client using 802.11ac typically transmits a “Very High Throughput” (VHT) Capability information element. Paragraph [0070]: ….the WLAN access point 310 consults the steering policy it received from the WLAN controller in step 320 to determine whether the “default” virtual access point VAP_x 380 is appropriate for the client device 315 or whether the client device 315 should be steered to a different virtual access point. If VAP_x 380 is appropriate for the client device 315 (e.g., the quality of service of the virtual access point matches the data rate capability 170 of the client device 315), then the client device 315 can be connected to VAP_x 380 (not shown in FIG. 3). If not, then the process moves on to step 355. Paragraph [0071]: At step 355, the WLAN access point 310 generates a new virtual access point, VAP_y 385, to associate with the client device 315 so that the quality of service of VAP_y 385 matches the data rate capability 170 of the client device 315 as dictated by the steering policy 320. Paragraph [0074]: At step 370, the access point 310 sends a new probe response from the new virtual access point VAP_y 385 that was generated in step 355. Paragraph [0075]: At step 375, the access point 310 and the client device 315 continue with authentication, association, and handshakes (e.g., according to IEEE 802.11i standards) and any other necessary operations for the client device 315 to connect to the virtual access point VAP_y 385 of the physical access point 310.)
Duo does not explicitly teach wherein the first VAP is mapped to a first Multiple Basic Service Set Identifier (MBSSID) set and configured as a transmitted VAP or a non-transmitted VAP of the first MBSSID set, wherein the second VAP is mapped to a second MBSSID set and configured as a transmitted VAP or a non-transmitted VAP of the second MBSSID set.
However, Naik teaches wherein the first VAP is mapped to a first Multiple Basic Service Set Identifier (MBSSID) set and configured as a transmitted VAP or a non-transmitted VAP of the first MBSSID set, wherein the second VAP is mapped to a second MBSSID set and configured as a transmitted VAP or a non-transmitted VAP of the second MBSSID set (see rejection for claim 1);
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the first VAP is mapped to a first Multiple Basic Service Set Identifier (MBSSID) set and configured as a transmitted VAP or a non-transmitted VAP of the first MBSSID set, wherein the second VAP is mapped to a second MBSSID set and configured as a transmitted VAP or a non-transmitted VAP of the second MBSSID set, as taught by Naik in the system of Duo, so that a beacon frame can include information pertaining to the access points (VAPs) belonging to a specific MBSSID set, and reduce overload on the beacon (Naik: Paragraphs [0058], [0059], [0060]).
The combination of Duo and Naik does not explicitly teach wherein the first MBSSID set is configured with a first quality of service (QoS) parameter and the second MBSSID set is configured with a second QoS parameter.
However, Patil teaches wherein the first MBSSID set is configured with a first quality of service (QoS) parameter and the second MBSSID set is configured with a second QoS parameter (see rejection for claim 1);
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the first MBSSID set is configured with a first quality of service (QoS) parameter and the second MBSSID set is configured with a second QoS parameter, as taught by Patil in the combined system of Duo and Naik, so that the basic service sets serving various devices with different requirements, can be allocated resources accordingly, and the wireless devices or STAs can be assigned to a basic service set based on parameters such as a quality of service parameter (Patil: Paragraphs [0004], [0128]).
Regarding claim 19, the combination of Duo, Naik, and Patil teaches t