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 .
Response to Amendment
The amendment to the claims filed on 05/19/2026 complies with the requirements of 37 CFR 1.121(c) and has been entered.
Response to Arguments
Applicant's Arguments/Remarks filed 05/19/2026 (Hereinafter Resp.) have been fully considered but they are moot because the new ground of rejection does not rely on the same paragraphs of the references applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 1-20, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Lu et al., U.S. Patent Application Publication No. 2025/0119965 (hereinafter Lu) and further in view of Seok et al., U.S. Patent Application Publication No. 2025/0212275 (hereinafter Seok).
Regarding Amended Claim 1, Lu teaches an access point (AP) multi-link device (AP MLD) comprising processing circuitry coupled to non-transitory storage (“The communication device 1300 illustrated in FIG. 13 . . . may be the first MLD or the second MLD” and “includes a processor 1310, and the processor 1310 may invoke and execute a computer program from a memory to implement the method in the embodiments of the present disclosure” – See [¶0491], whereby “the second MLD is an AP MLD” – See [¶0489] and “may be a device supporting the 802.11be standard1” – See [¶0051]), the processing circuitry configured to:
identify a request, received from a non-AP MLD, to add or remove a communication link between the non-AP MLD and an AP MLD, wherein the non-AP MLD was previously associated to the AP MLD (“for the multi-link reconfiguration, a link addition mechanism and/ or a link deletion mechanism on the basis that the non-AP MLD is already associated with the AP MLD [is] defined” – See [¶0072] whereby “[t]he non-AP MLD may send the multi-link reconfiguration request frame to the AP MLD on the established link to request for adding one or more links or deleting one or more established links . . . [a]fter the non-AP MLD has successfully completed the multi-link setup and association with the AP MLD”– See [¶0286] whereby “a link reconfiguration request/response [is an] action frame based on the reconfiguration variant multi-link element [] designed in the related technologies” – See [¶0067]);
generate a response to the request indicating whether the communication link was accepted or rejected to be added or removed (“In the multi-link reconfiguration response frame, the AP MLD indicates, through the second multi-link element, links that have been successfully added and/or the links that have been denied to be added, and link information of these links” – See id.); and
provide the response to the non-AP MLD (“the AP MLD may send the multi-link reconfiguration response frame to the non-AP MLD on the link on which the multi-link reconfiguration request frame is received to reply to the multi-link reconfiguration request frame” – See id. whereby, if the response is success, “the non-AP MLD and the AP MLD perform a multicast key handshake protocol for the successfully established addition link and establish GTK, IGTK, and BIGTK of the addition link” – See [¶0287] i.e., establish secure operation as described in IEEE 802.11 Standards2).
Although Lu teaches that the AP MLD needs to validate requested operating channels (“The AP MLD needs to ensure that different nonoverlapping channels are used between the addition links accepted to be established and between the addition links and the links that have been successfully established” whereby “the non-AP MLD needs to ensure that different non-overlapping channels are used between the addition links requested to be established” – See [¶0287]), Lu does not explicitly teach wherein the response is generated when no Operating Channel Information (OCI) element validation is required, or when the OCI element
validation is required and the validation is successful.
Seok teaches “methods and apparatuses pertaining to EHT ML operating channel validation in wireless communications” – See [¶0005] whereby, like in Fig. 11 of Lu, “a first MLD (MLD 110) and a second MLD (MLD 120) communicating wirelessly over multiple links (e.g., link 1 and link 2) with each other in a basic service set (BSS) in accordance with one or more IEEE 802.11 standards” and the first “MLD 110 is shown to be a non-AP MLD with a number of affiliated non-AP STAs (e.g., STA 11 and STA 12) and [the second] MLD 120 is shown to be an AP MLD with a number of affiliated AP STAs (e.g., AP 1 and AP 2)” – See [¶0020] and Fig. 1(A).
Seok teaches “an Operating Channel Validation Capable (OCVC) capability” present and advertised by a STA whereby “the STA may include operating channel information and validate Operating Channel Information (OCI) received from an OCVC-capable peer in certain protected messages (e.g., management frames) used for key establishment and confirmation” – See [¶0022] i.e., like the key handshake protocols for Security Association (SA) disclosed in Lu and in the IEEE 802.11-2020 standard in Footnote 2 – See [¶0026] (“For operating channel validation, the OCI may need to be included in certain types of messages,” e.g., “the OCI may be included in 4-way handshake M2 and M3 messages. Alternatively, or additionally, the OCI
may be included in group temporal key (GTK) handshake messages”).
Seok further teaches when the OCI element validation is required and the validation is successful (“most management frames may contain an OCI element that indicates the
operating channel number, and such management frames are encrypted (protected)” e.g., action frames used for the multi-link reconfiguration request to the AP MLD, and “the STA with OCVC capability may validate that the channel information in the received OCI matches its current operating channel parameters by performing certain operations,” i.e., if the MDL stations have “Operating Channel Validation Capable (OCVC) capability” and “advertise this
capability in a Robust Security Network Element (RSNE)” – See [¶0022], i.e., OCI validation is required; then, “in validating OCI, a STA may validate the global operating class (that also defines bandwidth and primary channel upper/lower behavior) and channel number” – See [¶0024] and, “[f]or operating channel validation, . . . the OCI may be included in group temporal key (GTK) handshake messages” because when “a channel is confirmed by another secure handshake, multi-channel MITM threat may be alleviated,” e.g., “Security Association (SA) query may be extended and used after a channel switch to validate OCI” – See [¶0026]; see also § 12.6, IEEE 802.11-2020 standard in Footnote 2).
Thus, Lu and Seok each teaches protected messages for handshake protocol for the successfully established addition link and establish GTK of the addition link between a MLD AP and non-AP MLD. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the MLD STAs could advertise Operating Channel Validation Capable (OCVC) capability and the non-AP MLD STA may include its operating channel information (OCI), as taught in Seok, in a group temporal key (GTK) handshake messages exchanged during the request for a link addition as taught by Lu, and then the MLD AP, based on a presence of the operating channel validation capability (OCVC) and the operating channel information (OCI) element in the request from the non-AP MLD must validate that the channel information in the received OCI matches its current operating channel parameters by performing certain operations, as further taught by Seok. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination of operating channel validation taught by Seok with the additional links establishment procedure between a non-AP MLD and an AP MLD taught by Lu through techniques known in the art. Finally, the combination achieves the predictable result of improved security in the handshake operation for establishing the GTK of the additional link between the non-AP MLD and the AP MLD in Lu by adding the step of validating that the OCI received in protected messages used in key establishment and confirmation with the OCVC non-AP MLD matches one or more parameters of a current operating channel of that non-AP MLD, so that a channel is confirmed by
another secure handshake and a multi-channel MITM threat may be alleviated, as taught in Seok.
Therefore, Amended Claim 1 is obvious over Lu in view of Seok.
Regarding Claim 2, dependent from Amended Claim 1, Lu further teaches the AP MLD of claim 1, wherein the request comprises a reconfiguration multi-link element comprising a profile of the non-AP MLD (“the multi-link reconfiguration method includes . . . a first MLD sends a first multi-link element to a second MLD,” – See [¶¶0075-76], i.e., a request comprising the reconfiguration MLE further comprising “a first link information field for indicating link information of the first part of links” – See [¶0090] and Fig. 4, whereby “[t]he first link information field in the first multi-link element includes STA information of an affiliated STA corresponding to each link of the first part of links and/or the links associated with the first part of links of the second part of links in the first MLD” – See [¶0127] , “the STA information is carried in a per-STA profile subelement, and the per-STA profile subelement includes at least one of following: . . . a first STA profile subfield for indicating STA profile information.” –See [¶0128], [¶0133] and Fig. 9). Furthermore, because Lu teaches that at least the MLD AP “may be a device supporting the 802.11be standard” – See [¶0051], §35.3.2.3 of IEEE P802.11be:378 details the elements of a complete per-STA profile in an example of inheritance, e.g., as shown in Figure 35-4, shown below:
PNG
media_image1.png
478
830
media_image1.png
Greyscale
Therefore, Claim 2 is obvious over Lu in view of Seok.
Regarding Claim 3, dependent from Claim 2, Lu further teaches the AP MLD of claim 2, wherein the profile comprises an identifier of the communication link and an indication that the reconfiguration multi-link element comprises a medium access control (MAC) address of the non-AP MLD (“the first STA control subfield in the per-STA profile subelement has following implementations:” – See [¶0134], “a first link ID subfield for indicating a target link” – See [¶0136], “a first link reconfiguration indication subfield for indicating a type of a reconfiguration operation performed on the target link” – See [¶0137], and “a first MAC address present subfield for indicating whether a STA MAC address subfield is present in the first STA information subfield;” – See [¶0139]).
Therefore, Claim 3 is obvious over Lu in view of Seok.
Regarding Claim 4, dependent from Claim 2, Lu further teaches the AP MLD of claim 2, wherein the profile comprises a complete profile subfield set to 1 (“the first STA control subfield in the per-STA profile subelement has . . .” – See [¶0134], “a first complete profile subfield for indicating whether the first STA profile subfield carries complete STA profile information;” – See [¶0137]).
Therefore, Claim 4 is obvious over Lu in view of Seok.
Regarding Claim 5, dependent from Claim 2, Lu further teaches the AP MLD of claim 2, wherein the profile comprises an indication of whether a removal timer is present (“in a case that the first multi-link element is a second type of multi-link element,” – See [¶0146] i.e., delete type of link reconfiguration, “a first delete timer present subfield for indicating whether a delete timer subfield is present in the first STA information subfield” – See [¶0150]).
Therefore, Claim 5 is obvious over Lu in view of Seok.
Regarding Claim 6, dependent from Amended Claim 1, although Lu teaches the AP MLD of claim 1 is a 802.11be AP using protected frames3 to communicate with the non-AP MLD (“the first multi-link element is carried in a first action field of a first request frame” that further includes “first protected action field for indicating a protected action;” – See [¶0173] and Table 4, whereby the protected action may be that “a successfully established addition link between the non-AP MLD and the AP MLD uses the PTK formed by the successfully established link before the addition link is successfully established, to encrypt and decrypt a unicast frame” or “the non-AP MLD and the AP MLD perform a multicast key handshake protocol for the successfully established addition link and establish GTK, IGTK, and BIGTK of the addition link” – See [¶0287]), Lu does not explicitly teach wherein the processing circuitry is further configured to validate, based on a presence of an operating channel validation capability (OCVC), an operating channel information (OCI) element of the request.
As explained in Regarding Amended Claim 1 supra, Seok teaches wherein the processing circuitry is further configured to validate, based on a presence of an operating channel validation capability (OCVC), an operating channel information (OCI) element of the request (“most management frames may contain an OCI element that indicates the operating channel number, and such management frames are encrypted (protected)” and “[w]hen an Operating Channel Validation Capable (OCVC) capability is present, a STA may advertise this capability in a Robust Security Network Element (RSNE), and the STA may include operating channel information and validate Operating Channel Information (OCI) received from an OCVC-capable peer in certain protected messages (e.g., management frames) used for key establishment and confirmation,” i.e., “the STA with OCVC capability may validate that the channel information in the received OCI matches its current operating channel parameters by performing certain operations” – See [¶0022] whereby “[f]or operating channel validation, the OCI may need to be included in certain types of messages. For instance, the OCI may be included in 4-way handshake M2 and M3 messages. Alternatively, or additionally, the OCI may be included in group temporal key (GTK) handshake messages” – See [¶0026] and Fig. 2 showing an EHT multi-link OCI element; see also §12.2.9 of IEEE 802.11be, teaching operating channel validation).
Therefore, Claim 6 is obvious over Lu in view of Seok.
Regarding Claim 7, dependent from Claim 1, Lu further teaches the AP MLD of claim 1, wherein the response comprises group key data (“in the case that the first part of links is the link requested to be added by the first MLD, after the first part of links is added” – See [¶0262], “[t]he first MLD receives the second multi-link element sent by the second MLD on a link on which the first MLD sends the first multi-link element” – See [¶0258] whereby “a second part of parameters used by the first part of links is re-established” – See [¶0262] and “the second part of parameters includes at least one of: a Group Temporal Key (GTK), an Integrity Group Temporal Key (IGTK), and a Beacon Integrity Group Temporal Key (BIGTK)” – See [¶0264] because “the first MLD performs interaction of handshake messages with the second MLD, and the interaction of the handshake messages is used for establishing the second part of parameters for the first part of links” – See [¶0265] and “the operation and management parameters (such as GTK, IGTK, BIGTK, etc.) specific to the addition link are newly established” – See [¶0287]).
Therefore, Claim 7 is obvious over Lu in view of Seok.
Regarding Claim 8, dependent from Amended Claim 1, Lu further teaches the AP MLD of claim 1, further comprising a transceiver configured to transmit and receive wireless signals comprising the request and the response (“the communication device 1300 may further include a transceiver 1330. The processor 1310 may control the transceiver 1330 to communicate with other devices, in particular, to send information or data to other devices, or receive information or data sent by other devices,” e.g., the request and the response containing MLEs – See [¶0494]).
Therefore, Claim 8 is obvious over Lu in view of Seok.
Regarding Claim 9, dependent from Claim 8, Lu further teaches the AP MLD of claim 8, further comprising an antenna coupled to the transceiver to send the request and the response (“The transceiver 1530 may further include an antenna(s), the number of which may be one or more” – See [¶0495]).
Therefore, Claim 9 is obvious over Lu in view of Seok.
Regarding Amended Claim 10, Lu teaches a non-transitory computer-readable medium storing computer-executable instructions which when executed by one or more processors of a non-access point multi-link device (non-AP MLD) (“The communication device may be the first MLD or the second MLD. The communication device 1300 illustrated in FIG. 13 includes a processor 1310, and the processor 1310 may invoke and execute a computer program from a memory to implement the method in the embodiments of the present disclosure” – See [¶0491] and Fig. 13, whereby “the first MLD is a nonAP MLD” – See [¶0489] and “[t]he memory 1420 may be a separate device independent of the processor 1410 or the memory 1420 may be integrated into the processor” – See [¶500] and Fig. 14) result in performing operations comprising:
generating a request to add or remove a communication link between the non-AP MLD and an AP MLD (“the non-AP MLD performs interaction of a multi-link reconfiguration request frame” and “[t]he multi-link reconfiguration request frame carries the first multi-link element,” whereby “[i]n the multilink reconfiguration request frame, the non-AP MLD indicates, through the first multi-link element, link information of the reconfiguration link and/or the link affected by the reconfiguration operation” – See [¶0286]),
wherein the non-AP MLD was previously associated to the AP MLD ([a]fter the non-AP MLD has successfully completed the multi-link setup and association with the AP MLD” – See id.);
provide the request to the AP MLD (“The non-AP MLD may send the multi-link reconfiguration request frame to the AP MLD on the established link” – See id.); and
identify a response from the AP MLD, the response indicating whether the communication link was accepted or rejected to be added or removed (“the AP MLD may send the multi-link reconfiguration response frame to the non-AP MLD on the link on which the multi-link reconfiguration request frame is received to reply to the multi-link reconfiguration request frame” and “[i]n the multi-link reconfiguration response frame, the AP MLD indicates, through the second multi-link element, links that have been successfully added and/or the links that have been denied to be added, and link information of these links” – See id., whereby “for the multi-link reconfiguration, a link addition mechanism and/or a link deletion mechanism on the basis that the non-AP MLD is already associated with the AP MLD” is defined – See [¶0072]) wherein the response has the same limitation as recited in Amended Claim 1 using the same language. Because Amended Claim 1 is obvious over Lu in view of Seok, Amended Claim 10 is obvious over Lu in view of Seok.
Regarding Claims 11-15, dependent from Amended Claim 10, each claim recites the same limitations to the non-AP MLD request as required by Claims 2-5, and 7, respectively, using the same language. Because each of the Claims 2-5, 7 and 10, is obvious over Lu in view of Seok, Claims 11-15 are obvious over Lu in view of Seok.
Regarding Amended Claim 16, Lu teaches a method comprising:
identifying, by processing circuitry of an access point (AP) multi-link device (AP MLD), a request, received from a non-AP MLD, to add or remove a communication link between the non-AP MLD and an AP MLD, wherein the non-AP MLD was previously associated to the AP MLD (“a multi-link reconfiguration method” – See [¶0005] and a “new multi-link element (i.e., the first multi-link element and/or the second multi-link element) . . by interacting the new multi-link element between the first MLD and the second MLD, on the basis that the second part of links has been established between the first MLD and the second MLD, addition of a new link or deletion of an established link can be implemented, thereby improving the multi-link reconfiguration mechanism” – See [¶0024]);
generating, by the processing circuitry, a response to the request indicating whether the communication link was accepted or rejected to be added or removed (“In the multi-link reconfiguration response frame, the AP MLD indicates, through the second multi-link element, links that have been successfully added and/or the links that have been denied to be added, and link information of these links” – See [¶0286] whereby “when the addition link is accepted to be established, the status code in the STA profile subfield of the corresponding per-STA profile subelement indicates ‘success’. When the addition link is denied to be established, the status code in the STA profile subfield of the corresponding per-STA profile subelement indicates ‘failure reason’” – See [¶0287]); and
causing transmission, by the processing circuitry, of the response to the non-AP MLD (“the AP MLD may send the multi-link reconfiguration response frame to the non-AP MLD on the link on which the multi-link reconfiguration request frame is received to reply to the multi-link reconfiguration request frame” – See [¶0286]) wherein the response has the same limitation as recited in Amended Claim 1 using the same language. Because Amended Claim 1 is obvious over Lu in view of Seok, Amended Claim 16 is obvious over Lu in view of Seok.
Regarding Claims 17-20, dependent from Amended Claim 16, each claim recites the same limitations to the non-AP MLD request as required by Claims 2-5, respectively, using the same language. Because each of the Claims 2-5, and 16, is obvious over Lu in view of Seok, Claims 17-20 are obvious over Lu in view of Seok.
In sum, Claims 1-20, as amended, are rejected under 35 U.S.C. §103 as obvious over Lu in view of Seok.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Patil et al., U.S. Patent Application Publication No. 2025/0317830 discloses methods, and apparatuses for associating a wireless communication device such as a wireless station (STA) of a STA multi-link device (MLD) with an access point (AP) MLD that includes a first AP associated with a first communication link of the AP MLD and includes one or more secondary APs associated with one or more respective secondary communication links of the first AP MLD;
Kwon et al., U.S. Patent Application Publication No. 2021/0368419 teaches multi-link device operation (MLO) information of least one neighboring wireless device to a reporting wireless device;
Viger et al., U.S. Patent Application Publication No. US 2023/0119901 disclosing a method for multi-link setup comprising an access point multi-link device, AP MLD, and the wireless network further comprising a first and a second station multi-link devices, STA MLDs;
Chitrakar et al., U.S. Patent Application Publication No. 2023/0232315 discloses communication devices and methods for EHT virtualization for MLD devices;
Chu et al., U.S. Patent Application Publication No. 2022/0330366 discloses device, a system, and a method for Multi-Link (ML) reconfiguration;
Liu et al., U.S. Patent Application Publication No. 2025/0081097 discloses apparatuses and methods for implementing a hibernation mode for multi-link wireless communication networks such as a wireless local area network with aspects related to a multi-link device (MLD);
Hu et al., U.S. Patent Application Publication No. 2022/0124855 discloses wireless multilink device (MLD) including a transceiver configured to send, to a second wireless MLD, a request for multi-link reconfiguration;
Ho et al., U.S. Patent Application Publication No. 2022/0022033 discloses methods, devices and systems that facilitate mobility of wireless communication devices configured for multi-link operation (MLO);
Lorgeoux et al., WIPO Patent Application Publication No. WO 2022/253791 discloses wireless networks implementing multilink transmissions, a non-AP MLD signals its Enhanced Multi-Link Multi-Radio, EMLMR, links and associated EMLMR links sets to the AP MLD;
Montemurro, WIPO Patent Application Publication No. WO 2022/157239 discloses multi-link transmission in wireless communications;
IEEE P802.11be™/D1.5, March 2022, (amendment to IEEE 802.11-2020 standards), “Draft Standard for Information technology— Telecommunications and information exchange between systems Local and metropolitan area networks— Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 8: Enhancements for extremely high throughput (EHT)”;
Section 12.2.9, ISO/IEC/IEEE 8802-11 Telecommunications and information exchange between systems — Specific requirements for local and metropolitan area networks — Part 11: Wireless LAN medium access control (MAC) and physical layer (PHY) specifications, Third edition, 2022-07, pages 2442-2443;
Section 12.6, "IEEE Standard for Information Technology--Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks--Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications," in IEEE Std 802.11-2020 (Revision of IEEE Std 802.11-2016) , vol., no., pp.1-4379, 26 Feb. 2021, doi: 10.1109/IEEESTD.2021.9363693, pages 2508-2509;
Á. López-Raventós and B. Bellalta, "Multi-Link Operation in IEEE 802.11be WLANs," published by arXiv, January 19, 2022, available at https://arxiv.org/pdf/2201.07499.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUCIA GHEORGHE GRADINARIU whose telephone number is (571)272-1377. The examiner can normally be reached Monday-Friday 9:00am - 5:00pm EST.
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, Joseph AVELLINO can be reached at (571)272-3905. 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.
/L.G.G./Examiner, Art Unit 2478
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478
1 At the effective filing date of the present application, IEEE had already published IEEE P802.11be™/D1.5, March 2022, (amendment to IEEE 802.11-2020 standards), “Draft Standard for Information technology—Telecommunications and information exchange between systems Local and metropolitan area networks— Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 8: Enhancements for extremely high throughput (EHT)” (hereinafter IEEE P802.11be).
2 Specifically, § 12.6, "IEEE Standard for Information Technology--Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks--Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications," in IEEE Std 802.11-2020 (Revision of IEEE Std 802.11-2016) , vol., no., pp.1-4379, 26 Feb. 2021, doi: 10.1109/IEEESTD.2021.9363693 (hereinafter IEEE 802.11-2020) specifies at page 2508-2509 that “Secure communications are possible only within the context of a security association, as this is the context providing the state (e.g., cryptographic keys, counters, sequence spaces) needed for correct operation of the IEEE 802.11 cipher suites” and “a STA that received a 4-way handshake but does not know the security policy of the peer should send a Probe Request frame to the peer STA to find its security
policy before setting up a security association to the peer STA” whereby multiple “types of security associations are supported by an RSNA STA” including GTK, IGTK, and BIGTK SA disclosed by Lu.
3 Section 9.2.4, IEEE 802.11be describes frames containing Reassociation request or action subfields as Management frames wherein the frame Control field indicates a protected frame – See Figure 9-3 and Table 9-1.
Prosecution Insights