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 .
Priority
Applicant’s claim for domestic priority under 35 U.S.C. 119(e) is acknowledged.
Information Disclosure Statement
The information disclosure statements submitted on 07/30/2024 and 06/23/2025 have been considered by the Examiner and made of record in the application file.
Specification
The disclosure is objected to because of the following informalities:
In p. 0025, “AKM Announcement Logic 150 may be configured identify” should presumably be “AKM Announcement Logic 150 may be configured to identify”
In p. 0038, the abbreviation “w/” should be replaced with the full word “with”.
In p. 0040, “At 402, an operation in configured to” should presumably be “At 402, an operation is configured to”
In p. 0071, “with at last one of” should presumably be “with at least one of”
Appropriate correction is required.
Claim Objections
Claims 1, 11, and 18 are objected to because of the following informalities: “via a distribution
network that interconnects respective access points” should presumably be “via a distribution network that interconnects the respective access points” as antecedent basis for “respective access points” was previously established.
Claim 9 is objected to because of the following informality: "with at is presumably a misspelling of “with at least one of”. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 8 recites the limitation "the one of the AKM suites" in line 1. There is insufficient antecedent basis for this limitation in the claim. It appears that claim 8 should dependent on claim 7 and for purposes of applying prior art, claim 8 will be interpreted as dependent on claim 7.
The term “less secure AKM suite” in claim 8 is a relative term which renders the claim indefinite. The term “less secure AKM suite” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. It is not clear how it can be determined that one AKM suite is strictly "less secure" compared to another AKM suite.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1, 3, 7, 11, 13, 17, 18, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11, hereinafter RFC 5416.
Regarding claim 1, RFC 5416 discloses a method, comprising:
receiving data representative of security capabilities of respective basic service sets affiliated with an extended service set of a wireless local area network (Abstract, page 2 “Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs)”, section 1.3, page 6 “These services include the transport of MSDUs between the access points (APs) of basic service sets (BSSs) within an extended service set (ESS) … In this document, WLAN refers to a logical component instantiated on a WTP device. A single physical WTP may operate a number of WLANs. Each Basic Service Set Identifier (BSSID) and its constituent wireless terminal radios is denoted as a distinct WLAN on a physical WTP”, section 6.1, pages 29-30 “The IEEE 802.11 Add WLAN message element is used by the AC to define a WLAN on the WTP. The inclusion of this message element MUST also include IEEE 802.11 Information Element message elements, containing the following IEEE 802.11 IEs: … RSN information element”; a WTP is known in the art to encompass the functionality of a wireless access point);
supplying the data representative of security capabilities to respective access points in the respective basic service sets via a distribution network that interconnects respective access points of the respective basic service sets (section 2.2.1, page 10, “If the WTP is providing encryption/decryption services, once the client has completed the IEEE 802.11 key exchange, the AC transmits another Station Configuration Request message [to the WTP — see Figure 2], which includes … An IEEE 802.11 Information Element message element, which includes the Robust Security Network Information Element (RSNIE) to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP)”); and
sending, from the respective access points, a beacon frame that includes an information element comprising the data representative of the security capabilities of the respective basic service sets affiliated with the extended service set (section 2.2.1, page 9, “The WTP generates the IEEE 802.11 Beacon frames, using information provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) message element, including the Robust Security Network Information Element (RSNIE), which indicates support of 802.1X and AES-CCMP”).
Regarding claim 3, RFC 5416 discloses the method of claim 1, wherein the data representative of security capabilities comprises authentication and key management (AKM) suites supported by the respective basic service sets (section 6.15, page 48 “When the Key field is non-zero in length, the RSN Information Element MUST be sent along with the IEEE 802.11 Station Session Key in order to instruct the WTP on the usage of the Key field. The WTP MUST observe the Authentication and Key Management (AKM) field of the RSN Information Element in order to identify the authentication protocol to be enforced with the station”; identifying and sending the authentication protocol to be enforced with the station by observing the AKM field of the RSN Information Element inherently includes accessing an AKM suite list field and transmitting an AKM suite; see IEEE 802.11-2007 section 7.3.2.25, which RFC 5416 is based on).
Regarding claim 7, RFC 5416 discloses the method of claim 3, further comprising receiving an authentication request from a client device roaming within the extended service set, based on one of the AKM suites (section 2.2.1, page 10, “The WTP forwards the IEEEE [sic] 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client”, section 2.3, page 15 “Once a client has successfully associated with the network in a secure fashion, it is likely to attempt to roam to another WTP. Figure 6 shows an example of a currently associated station moving from its "Old WTP" to a "New WTP". The figure is valid for multiple different security policies, including IEEE 802.1X and Wireless Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA]”; roaming between WTPs with different security policies is inherently based on AKM suites).
Regarding claim 11, RFC 5416 discloses a device comprising:
an interface configured to enable network communications (Introduction, page 4, “That said, the protocol does allow a WTP to advertise support for an IEEE 802.11n radio”);
a memory (section 7, page 67, “This section contains the IEEE 802.11 binding specific variables that SHOULD be saved in non-volatile memory on the WTP”);
and one or more processors coupled to the interface and the memory (section 1.1, page 5, “To
enable shifting of the higher-level protocol processing from the WTP. This leaves the time-critical applications of wireless control and access in the WTP, making efficient use of the computing power available in WTPs that are subject to severe cost pressure”; a device that computes inherently has a processor), and configured to:
receive data representative of security capabilities of respective basic service sets affiliated with an extended service set of a wireless local area network (Abstract, page 2 “Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs)”, section 1.3, page 6 “These services include the transport of MSDUs between the access points (APs) of basic service sets (BSSs) within an extended service set (ESS) … In this document, WLAN refers to a logical component instantiated on a WTP device. A single physical WTP may operate a number of WLANs. Each Basic Service Set Identifier (BSSID) and its constituent wireless terminal radios is denoted as a distinct WLAN on a physical WTP”, section 6.1, pages 29-30 “The IEEE 802.11 Add WLAN message element is used by the AC to define a WLAN on the WTP. The inclusion of this message element MUST also include IEEE 802.11 Information Element message elements, containing the following IEEE 802.11 IEs: … RSN information element”; a WTP is known in the art to encompass the functionality of a wireless access point);
supply the data representative of security capabilities to respective access points in the respective basic service sets via a distribution network that interconnects respective access points of the respective basic service sets (section 2.2.1, page 10, “If the WTP is providing encryption/decryption services, once the client has completed the IEEE 802.11 key exchange, the AC transmits another Station Configuration Request message [to the WTP — see Figure 2], which includes … An IEEE 802.11 Information Element message element, which includes the Robust Security Network Information Element (RSNIE) to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP)”); and
send, from the respective access points, a beacon frame that includes an information element comprising the data representative of the security capabilities of the respective basic service sets affiliated with the extended service set (section 2.2.1, page 9, “The WTP generates the IEEE 802.11 Beacon frames, using information provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) message element, including the Robust Security Network Information Element (RSNIE), which indicates support of 802.1X and AES-CCMP”).
Regarding claim 13, RFC 5416 discloses the device of claim 11, wherein the data representative of security capabilities comprises authentication and key management (AKM) suites supported by the respective basic service sets (section 6.15, page 48 “When the Key field is non-zero in length, the RSN Information Element MUST be sent along with the IEEE 802.11 Station Session Key in order to instruct the WTP on the usage of the Key field. The WTP MUST observe the Authentication and Key Management (AKM) field of the RSN Information Element in order to identify the authentication protocol to be enforced with the station”; identifying and sending the authentication protocol to be enforced with the station by observing the AKM field of the RSN Information Element inherently includes accessing an AKM suite list field and transmitting an AKM suite; see IEEE 802.11-2007 section 7.3.2.25, which RFC 5416 is based on).
Regarding claim 17, RFC 5416 discloses the device of claim 13, wherein the one or more processors are further configured to receive an authentication request from a client device roaming within the extended service set, based on one of the AKM suites (section 2.2.1, page 10, “The WTP forwards the IEEEE [sic] 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client”, section 2.3 “Once a client has successfully associated with the network in a secure fashion, it is likely to attempt to roam to another WTP. Figure 6 shows an example of a currently associated station moving from its "Old WTP" to a "New WTP". The figure is valid for multiple different security policies, including IEEE 802.1X and Wireless Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA]”; roaming between WTPs with different security policies is inherently based on AKM suites).
Regarding claim 18, RFC 5416 discloses one or more non-transitory computer readable storage media encoded with instructions that, when executed by a processor (section 1.1, page 5, “To enable shifting of the higher-level protocol processing from the WTP. This leaves the time-critical applications of wireless control and access in the WTP, making efficient use of the computing power available in WTPs that are subject to severe cost pressure”; a device that computes inherently has a processor that executes instructions stored is some kind of storage medium), cause the processor to:
receive data representative of security capabilities of respective basic service sets affiliated with an extended service set of a wireless local area network (Abstract, page 2 “Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs)”, section 1.3, page 6 “These services include the transport of MSDUs between the access points (APs) of basic service sets (BSSs) within an extended service set (ESS) … In this document, WLAN refers to a logical component instantiated on a WTP device. A single physical WTP may operate a number of WLANs. Each Basic Service Set Identifier (BSSID) and its constituent wireless terminal radios is denoted as a distinct WLAN on a physical WTP”, section 6.1, pages 29-30 “The IEEE 802.11 Add WLAN message element is used by the AC to define a WLAN on the WTP. The inclusion of this message element MUST also include IEEE 802.11 Information Element message elements, containing the following IEEE 802.11 IEs: … RSN information element”; a WTP is known in the art to encompass the functionality of a wireless access point);
supply the data representative of security capabilities to respective access points in the
respective basic service sets via a distribution network that interconnects respective access points of the respective basic service sets (section 2.2.1, page 10, “If the WTP is providing encryption/decryption services, once the client has completed the IEEE 802.11 key exchange, the AC transmits another Station Configuration Request message [to the WTP — see Figure 2], which includes … An IEEE 802.11 Information Element message element, which includes the Robust Security Network Information Element (RSNIE) to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP)”); and
send, from the respective access points, a beacon frame that includes an information element comprising the data representative of the security capabilities of the respective basic service sets affiliated with the extended service set (section 2.2.1, page 9, “The WTP generates the IEEE 802.11 Beacon frames, using information provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) message element, including the Robust Security Network Information Element (RSNIE), which indicates support of 802.1X and AES-CCMP”).
Regarding claim 20, RFC 5416 discloses the one or more non-transitory computer readable storage media of claim 18, wherein the data representative of security capabilities comprises authentication and key management (AKM) suites supported by the respective basic service sets (section 6.15, page 48 “When the Key field is non-zero in length, the RSN Information Element MUST be sent along with the IEEE 802.11 Station Session Key in order to instruct the WTP on the usage of the Key field. The WTP MUST observe the Authentication and Key Management (AKM) field of the RSN Information Element in order to identify the authentication protocol to be enforced with the station”; identifying and sending the authentication protocol to be enforced with the station by observing the AKM field of the RSN Information Element inherently includes accessing an AKM suite list field and transmitting an AKM suite; see IEEE 802.11-2007 section 7.3.2.25, which RFC 5416 is based on).
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 2, 8, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over RFC 5416 in view of Kneckt et al. (US Patent Publication 2025/0088949 A1, hereinafter Kneckt).
Regarding claim 2, RFC 5416 discloses the method of claim 1, but does not disclose the information element comprising data representing security capabilities within the extended service set across all affiliated basic service sets.
In the same field of endeavor, Kneckt discloses the information element comprising data representing security capabilities within the extended service set across all affiliated basic service sets (p. 0031 “The AP may broadcast the reduced neighbor report to the STA. This can be done by sending the report in a beacon frame or a probe response frame.”, p. 0050 “As shown, the first field 504 [of the reduced neighbor report] may indicate the security mode of an AP … In some embodiments, WPA modes may be defined as a set of supported Authentication and Key Managements (AKMs). In the illustrated embodiment, the WPA modes are listed.” p. 0051 “The second field 506 may indicate whether a same security mode is used on the ESS. In the illustrated embodiment, the second field 506 may be set to one to indicate that all APs in the ESS have the same security mode. The second field 506 may be set to zero to indicate that all the APs do not have the same security mode or that it is unknown”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the signaling of the security mode of APs in the ESS of Kneckt to the beacon frame of RFC 5416 in order to communicate the security requirements of all BSSs through the connection to just one BSS, minimizing latency caused by attempts to connect to incompatible BSSs.
Regarding claim 8, RFC 5416 discloses the method of claim 3, but does not disclose one of the AKM suites being a less secure AKM suite than was previously being employed by a client device in a prior authentication with one of the respective access points.
In the same field of endeavor, Kneckt discloses one of the AKM suites being a less secure AKM suite than was previously being employed by a client device in a prior authentication with one of the respective access points (p. 0044, “As shown, an STA 308 may first associate with the second AP 306. In the illustrated embodiment, the STA 308 is a WPA 3 device. Accordingly, the STA 308 is capable of roaming to the first AP 304 with the higher security. Some WPA 3 STAs may be configured to be able roam toward a higher security level AP but not be able to roam towards a lower security level AP. For example, a STA may not be allowed to roam from a WPA 3 network to a WPA 3 TM network”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the comparison of AKM suite security levels as disclosed on Kneckt to the protocols described in RFC 5416 in order to prevent client devices from roaming to APs using an inferior security protocol compared to a previous connection.
Regarding claim 12, RFC 5416 discloses the method of claim 11, but does not disclose the information element comprising data representing security capabilities within the extended service set across all affiliated basic service sets.
In the same field of endeavor, Kneckt discloses the information element comprising data representing security capabilities within the extended service set across all affiliated basic service sets (p. 0031 “The AP may broadcast the reduced neighbor report to the STA. This can be done by sending the report in a beacon frame or a probe response frame.”, p. 0050 “As shown, the first field 504 [of the reduced neighbor report] may indicate the security mode of an AP … In some embodiments, WPA modes may be defined as a set of supported Authentication and Key Managements (AKMs). In the illustrated embodiment, the WPA modes are listed.” p. 0051 “The second field 506 may indicate whether a same security mode is used on the ESS. In the illustrated embodiment, the second field 506 may be set to one to indicate that all APs in the ESS have the same security mode. The second field 506 may be set to zero to indicate that all the APs do not have the same security mode or that it is unknown”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the signaling of the security mode of APs in the ESS of Kneckt to the beacon frame of RFC 5416 in order to communicate the security requirements of all BSSs through the connection to just one BSS, minimizing latency caused by attempts to connect to incompatible BSSs.
Regarding claim 19, RFC 5416 discloses the one or more non-transitory computer readable storage media of claim 18, but does not disclose the information element comprising data representing security capabilities within the extended service set across all affiliated basic service sets.
In the same field of endeavor, Kneckt discloses the information element comprising data representing security capabilities within the extended service set across all affiliated basic service sets (p. 0031 “The AP may broadcast the reduced neighbor report to the STA. This can be done by sending the report in a beacon frame or a probe response frame.”, p. 0050 “As shown, the first field 504 [of the reduced neighbor report] may indicate the security mode of an AP … In some embodiments, WPA modes may be defined as a set of supported Authentication and Key Managements (AKMs). In the illustrated embodiment, the WPA modes are listed.” p. 0051 “The second field 506 may indicate whether a same security mode is used on the ESS. In the illustrated embodiment, the second field 506 may be set to one to indicate that all APs in the ESS have the same security mode. The second field 506 may be set to zero to indicate that all the APs do not have the same security mode or that it is unknown”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the signaling of the security mode of APs in the ESS of Kneckt to the beacon frame of RFC 5416 in order to communicate the security requirements of all BSSs through the connection to just one BSS, minimizing latency caused by attempts to connect to incompatible BSSs.
Claims 4, 5, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over RFC 5416 in view of Masataka et al. (Japan Patent Publication 2006-332788 A, hereinafter Masataka).
Regarding claim 4, RFC 5416 discloses the method of claim 3, but does not necessarily specify the information element comprising an affiliated AKM suite list field that lists the AKM suites supported by the respective basic service sets.
In the same field of endeavor, Masataka discloses the information element comprising an affiliated AKM suite list field that lists the AKM suites supported by the respective basic service sets (Fig. 5 shows the AKM Suite List field contained in frame body 21; p. 0031 (page 5 of the translated document) “According to the specification of the IEEE802.11 series given as an example in the present embodiment, the access point 2 must set the set security parameter in the beacon frame. FIG. 5 is a diagram showing a beacon frame structure in the IEEE802.11 series standard. As shown in the figure, the beacon frame has a hierarchical structure. Capability information 22 and RSN-IE 23 in the frame body 21 are affected by having a plurality of security parameter sets … Further, the number of authentication methods is described in the AKM Suite Count field 27 in the RSN-IE 23, and the identifier and value of the authentication method are described in the AKM Suite List field 28”, p. 0064 (page 6 of the translated document) “FIG. 7 is a diagram showing a description example of the AKM Suite List field 28 in the RSN-IE 23 in the first connection process.”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the AKM suite list field of Masataka to the beacon frame of RFC 5416 in order to add a standard representation of security capabilities, improving compatibility with existing systems.
Regarding claim 5, RFC 5416 discloses the method of claim 3, but does not disclose the
information element further comprising data representative of at least one of a Group Data Cipher Suite (GDCS), a Pairwise Cipher Suite (PCS), a Pairwise Master Key Identifier (PMKID), and a Group Management Cipher Suite (GMCS).
In the same field of endeavor, Masataka discloses the information element further comprising data representative of at least one of a Group Data Cipher Suite (GDCS), a Pairwise Cipher Suite (PCS), a Pairwise Master Key Identifier (PMKID), and a Group Management Cipher Suite (GMCS) (p. 0031 (page 5 of the translated document) “According to the specification of the IEEE802.11 series given as an example in the present embodiment, the access point 2 must set the set security parameter in the beacon frame. FIG. 5 is a diagram showing a beacon frame structure in the IEEE802.11 series standard. As shown in the figure, the beacon frame has a hierarchical structure. … In addition, the number of encryption schemes is described in the Pairwise Cipher Suite Count field 25 in the RSN-IE 23, and the identifier and value of each encryption scheme are described in the Pairwise Cipher Suite List field 26”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the Pairwise Cipher Suite of Masataka to the beacon frame of RFC 5416 in order to improve the security capabilities of the service set by enabling additional algorithms to secure the connections to a device.
Regarding claim 14, RFC 5416 discloses the method of claim 13, but does not necessarily specify the information element comprising an affiliated AKM suite list field that lists the AKM suites supported by the respective basic service sets.
In the same field of endeavor, Masataka discloses the information element comprising an affiliated AKM suite list field that lists the AKM suites supported by the respective basic service sets (Fig. 5 shows the AKM Suite List field contained in frame body 21; p. 0031 (page 5 of the translated document) “According to the specification of the IEEE802.11 series given as an example in the present embodiment, the access point 2 must set the set security parameter in the beacon frame. FIG. 5 is a diagram showing a beacon frame structure in the IEEE802.11 series standard. As shown in the figure, the beacon frame has a hierarchical structure. Capability information 22 and RSN-IE 23 in the frame body 21 are affected by having a plurality of security parameter sets … Further, the number of authentication methods is described in the AKM Suite Count field 27 in the RSN-IE 23, and the identifier and value of the authentication method are described in the AKM Suite List field 28”, p. 0064 (page 6 of the translated document) “FIG. 7 is a diagram showing a description example of the AKM Suite List field 28 in the RSN-IE 23 in the first connection process.”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the AKM suite list field of Masataka to the beacon frame of RFC 5416 in order to add a standard representation of security capabilities, improving compatibility with existing systems.
Regarding claim 15, RFC 5416 discloses the method of claim 13, but does not disclose the information element further comprising data representative of at least one of a Group Data Cipher Suite (GDCS), a Pairwise Cipher Suite (PCS), a Pairwise Master Key Identifier (PMKID), and a Group Management Cipher Suite (GMCS).
In the same field of endeavor, Masataka discloses the information element further comprising data representative of at least one of a Group Data Cipher Suite (GDCS), a Pairwise Cipher Suite (PCS), a Pairwise Master Key Identifier (PMKID), and a Group Management Cipher Suite (GMCS) (p. 0031 (page 5 of the translated document) “According to the specification of the IEEE802.11 series given as an example in the present embodiment, the access point 2 must set the set security parameter in the beacon frame. FIG. 5 is a diagram showing a beacon frame structure in the IEEE802.11 series standard. As shown in the figure, the beacon frame has a hierarchical structure. … In addition, the number of encryption schemes is described in the Pairwise Cipher Suite Count field 25 in the RSN-IE 23, and the identifier and value of each encryption scheme are described in the Pairwise Cipher Suite List field 26”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the Pairwise Cipher Suite of Masataka to the beacon frame of RFC 5416 in order to improve the security capabilities of the service set by enabling additional algorithms to secure the connections to a device.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over RFC 5416 in view of IEEE 802.11-2020.
Regarding claim 6, RFC 5416 discloses the method of claim 3, but does not disclose that a number of AKM suites that are listed in the information element may be derived from the information element.
In the same field of endeavor, IEEE 802.11-2020 discloses that a number of AKM suites that are listed in the information element may be derived from the information element (the number of AKM suites can be derived from the information element in both ways suggested by the applicant’s disclosure: by reading the AKM Suite Count field [section 9.4.2.24.3, page 1053, “The AKM Suite Count field indicates the number of AKM suite selectors that are contained in the AKM Suite List field.”], or by deriving it from the element length field [section 9.4.2.1, page 939, “The Length field indicates the number of octets in the element excluding the Element ID and Length fields”, section 9.4.2.24.1, page 1050, Figure 9-287 shows an AKM suite is made of 4 octets; therefore, the number of AKM suites can be found as the length of the element minus overhead, divided by 4]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the count of AKM suites as disclosed by IEEE 802.11-2020 to the beacon frame of RFC 5416 in order to improve compatibility with existing wireless systems and enable client devices to have greater awareness of security options.
Regarding claim 16, RFC 5416 discloses the method of claim 13, but does not disclose that a number of AKM suites that are listed in the information element may be derived from the information element.
In the same field of endeavor, IEEE 802.11-2020 discloses that a number of AKM suites that are listed in the information element may be derived from the information element (the number of AKM suites can be derived from the information element in both ways suggested by the applicant’s disclosure: by reading the AKM Suite Count field [section 9.4.2.24.3, page 1053, “The AKM Suite Count field indicates the number of AKM suite selectors that are contained in the AKM Suite List field.”], or by deriving it from the element length field [section 9.4.2.1, page 939, “The Length field indicates the number of octets in the element excluding the Element ID and Length fields”, section 9.4.2.24.1, page 1050, Figure 9-287 shows an AKM suite is made of 4 octets; therefore, the number of AKM suites can be found as the length of the element minus overhead, divided by 4]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the count of AKM suites as disclosed by IEEE 802.11-2020 to the beacon frame of RFC 5416 in order to improve compatibility with existing wireless systems and enable client devices to have greater awareness of security options.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over RFC 5416 in view of Tachibana (US Patent Publication 2025/0318000A1).
Regarding claim 9, RFC 5416 discloses the method of claim 3, but does not disclose at least one of the AKM suites being compliant with at last one of Wi-Fi Protected Access 2 (WPA2) security, Wi-Fi Protected Access 3 – Transition Mode (WPA3-TM) security, Wi-Fi Protected Access 3 (WPA3) security.
In the same field of endeavor, Tachibana discloses at least one of the AKM suites being compliant with at last one of Wi-Fi Protected Access 2 (WPA2) security, Wi-Fi Protected Access 3 – Transition Mode (WPA3-TM) security, Wi-Fi Protected Access 3 (WPA3) security (p. 0050 “For example, SAE (Simultaneous Authentication of Equals) is specified in “Authentication and Key Management Type” included in DPP Configuration Object Parameters defined in WEC, which makes it possible to indicate that the authentication method is WPA3”, p. 0052 “More specifically, PSK (Pre-Shared Key) is specified in “Authentication and Key Management Type” included in DPP Configuration Object Parameters, which makes it possible to indicate that the authentication method is WPA2”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to add the support for existing wireless connectivity security protocols as in Tachibana to the beacon frame of RFC 5416 in order to improve compatibility with existing wireless systems.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over RFC 5416 in view of Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP), hereinafter RFC 3416.
Regarding claim 10, RFC 5416 discloses the method of claim 3, but does not disclose polling the respective access points for the data representative of the security capabilities of the respective basic service sets.
In the same field of endeavor, RFC 3416 discloses polling the respective access points for the
data representative of the security capabilities of the respective basic service sets (Introduction, page 3, “Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI”, section 4.2.3, page 14, “A GetBulkRequest-PDU is generated and transmitted at the request of an application. The purpose of the GetBulkRequest-PDU is to request the transfer of a potentially large amount of data, including, but not limited to, the efficient and rapid retrieval of large tables“; this function can be used on the MIB of the WTBs of RFC 5416, a well-known component of 802.11 access points, in order to retrieve the dot11RSNAConfigAuthenticationSuites table, which lists the AKM suites supported by the entity).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective date of the claimed invention to use the table-reading function of RFC 3416 to allow a system, like one described in RFC 5416, to retrieve AKM suite information in order to keep the system managing an ESS aware of the current security capabilities of its APs.
Conclusion
IEEE 802.11-2007 may be used as reference for the state of wireless communication at the time of RFC 5416’s publication.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN WINN whose telephone number is (571)270-5541. The examiner can normally be reached M-F, 9am to 5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rafael Perez-Gutierrez can be reached at (571) 272-7915. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JUSTIN HUYNH WINN/Examiner, Art Unit 2642
/Rafael Pérez-Gutiérrez/Supervisory Patent Examiner, Art Unit 2642
Prosecution Insights