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 11/26/2025 complies with the requirements of 37 CFR 1.121(c) and has been entered. Claims 1, 14, and 20 are amended. Claim 11 is cancelled.
Response to Arguments
Applicant's Arguments/Remarks filed 11/26/2025 (hereinafter Resp.) have been fully considered as follows.
First, Applicant argues that rejections of Claims 2, 7, 9, and 15 under 35 U.S.C. §112(b) is improper because “[a] person of ordinary skill in the art of wireless communications would understand that ‘802.11’ refers to the IEEE 802.11 family of standards for wireless local area networks, and would be able to identify the specific frame structures, fields, and protocols referenced in the claims based on their knowledge of these widely-adopted technical standards” – See Resp.,8:¶2. Although the rejection was not issued because a person of ordinary skills in the art would not recognize the trademark or have an understanding of the general technology under the “802.11” label but for using the trademark to identify a product, a practice discouraged under MPEP § 2173.05(u), the rejection is withdrawn based on the argument.
Second, Applicant argues that the “amended independent claim 1 is allowable over Lu” – See Resp.,10:¶3 whereby the amendment consists of substantially the limitations recited in former Claim 11, now cancelled. While the amended independent claim may overcome the §102 rejection over Lu et al., U.S. Patent Application Publication No. 2025/0119965 (hereinafter Lu), the previous Office Action rejected Claim 11 under § 103 over Lu in view of 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). Specifically, the Office action, at page 23, states that “the TID-to-link mapping negotiation subfield could be set to 0 to indicate no additional negotiation, as further taught by IEEE P802.11be:392” and, at page 24, that “[s]ection 35.3.7.1.4 of IEEE P802.11be:394 further teaches that ‘the initial power management mode of the STA, immediately after the acknowledgement of the (Re)Association Response frame . . . is power save mode, and its power state is doze,’” hence providing that IEEE P802.11be discloses the limitations that now amend independent Claims 1, 14 and 20. Although Applicant further states that “Examiner's obviousness analysis fails to establish that the combination of Lu and IEEE P802.11be teaches or suggests the specific technical configuration recited in the amended independent claims (particularly the subject matter from cancelled claim 11), where traffic identifiers are automatically mapped by default without additional negotiation and non-AP stations corresponding to newly added links are placed in power save mode and doze state” – See Resp., 11:¶3, there is no argument to rebut examiner’s prima facie case of obviousness based on IEEE P802.11be as secondary reference combinable with Lu – See Lu:[¶0051] (stating that “the AP 110 may be a device supporting the 802.11be standard” and “the STA 120 may support the 802.11be standard”). Therefore, this argument is unpersuasive.
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-10, and 12-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 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).
Regarding Claim 1, Lu teaches an apparatus of a non-access point (AP) multi-link device (non-AP-MLD) for adding or removing communication APs affiliated with an associated AP MLD (“the AP 110 may be a device supporting the 802.11be standard” and “the STA 120 may support the 802.11be standard” – See [¶0051] and Fig. 1; “the first MLD is a non-AP MLD, and the second MLD is an AP MLD. After the non-AP MLD has successfully completed the multi-link setup and association with the AP MLD, when the non-AP MLD needs to establish an addition link or delete an established link with the AP MLD” – See [¶0286]),
the non-AP-MLD comprising processing circuitry coupled to storage, the processing circuitry configured to (“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):
identify a communication link between the non-AP-MLD and an AP-MLD, the communication link previously used by the non-AP-MLD (“The non-AP MLD may send the multi-link reconfiguration request frame to the AP MLD on the established link” – See [¶0286]);
encode a request frame comprising a multi-link reconfiguration element indicative of a request to add or remove the communication link (“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 id.);
cause the non-AP-MLD to transmit the request frame to the AP-MLD (“The 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”– See id.); and
identify a response frame received from the AP-MLD, the response frame comprising the multi-link reconfiguration element and 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 for one or more communication links, comprising the communication link, that were accepted to be added (“the AP MLD may accept all addition links requested to be established or a part of addition links requested to be established” – See [¶0287]), when “the first part of links is the link requested to be added by the first MLD” – See [¶0123]), the “MLD capabilities subfield includes at least one of following:” – See [¶0124], a “Traffic ID (TID)-to-link mapping negotiation support subfield for indicating a capability for supporting a TID-to-link mapping negotiation” – See [¶0126]. While Lu teaches support for TID-to-link mapping negotiation, Lu does not disclose or mandate such negotiation. Therefore, it would be obvious for a person of ordinary skills in the art that TID-to-link mapping may happen without negotiation. Furthermore, because Lu discloses that the described APs and STAs are “device[s] supporting the 802.11be standard” – See [¶0051], a person of ordinary skills in the art would look at a version of the standard before the effective filing date of Lu application to understand the default Traffic ID (TID)-to-link mapping. Indeed, IEEE P802.11be teaches that:
by default all traffic identifiers (TIDs) are mapped to the one or more communication links without additional negotiation – See § 35.3.7.1, at page 391(disclosing that “[b]y default, all TIDs shall be mapped to all setup links for both DL and UL (see 35.3.7.1.2 (Default mapping mode))” unless “both MLDs have explicitly negotiated a TID-to-link mapping by following the procedure defined in 35.3.7.1.3 (Negotiation of TID-to-link mapping)”)(emphasis added); see also id., at page 392 (stating that TID-to-link mapping negotiation requires special settings such as the “dot11TIDtoLinkMappingActivated equal to true” and “a nonzero value the TID-to-link Mapping Negotiation Supported subfield in the MLD Capabilities”; further stating that “[o]therwise it shall set the TID-to-link Mapping Negotiation Supported subfield to 0,” i.e., the default setting is without additional negotiation because a “0” value setting is required for the devices not to be confused by a different value indicating negotiation) and
wherein one or more non-AP stations (STAs) affiliated with the non-AP-MLD corresponding to the one or more communication links are in a power save (PS) mode and a doze state – See § 35.3.7.1.1, at page 391 (“By default, all setup links shall be enabled (see 35.3.7.1.2 (Default mapping mode)” ); see also § 35.3.7.1.4, at page 394 (disclosing power state after enablement that “[w]hen a link transitions to being enabled for a STA that is affiliated with a non-AP MLD . . . the initial power management mode of the STA . . . is power save mode, and its power state is doze”).
Thus, Lu and IEEE P802.11be each teaches multi-link setup between the non-AP-MLD and an AP-MLD using request/response frames. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood the link management requiring default setting of TID-to-link mapping without negotiation and power save mode of STAs with recently setup links, as specified in § 35.3.7 of IEEE P802.11be, could have been combined with the steps of adding links as taught in Lu, because both provide for request/response frames comprising multi-link reconfiguration element. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art. Finally, the combination achieves the predictable result of aligning Lu with the IEEE P802.11be technical specifications for handling multi-link reconfiguration.
Therefore, Amended Claim 1 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 2, dependent from Amended Claim 1, Lu further teaches the apparatus of claim 1, wherein the request frame and the response frame are protected 802.11 action frames (“the first multi-link element is carried in a first action field of a first request frame” wherein “the first action field further includes at least one of: a first category field for indicating a category of the first action field; a first protected action field for indicating a protected action;” – See [¶0173]; and “the second multi-link element is carried in a second action field of a first response frame, the second action field includes a second multi-link element field for indicating the second multi-link element” wherein “the second action field further includes at least one of: a second category field for indicating a category of the second action field; a second protected action field for indicating a protected action” – See [¶0260]; in addition, “a format of an action field of the multi-link reconfiguration request frame is illustrated in Table 4, including: a category field, a protected action field” – See [¶0283] and Table 4; and “a format of an action field of the multi-link reconfiguration response frame is illustrated in Table 5, including: a category field, a protected action field” – See [¶0284] and Table 5)
comprising one or more key data encapsulation (KDE) (“in the case the first part of links is the link requested to be added by the first MLD, after the first part of links is added, a first part of parameters used by the first part of links and the second part of links is unchanged; and/or 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], which are known in the art as KDEs – See, e.g., Table 12-10—KDE selectors, IEEE P802.11be:321).
Lu further teaches that “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] when the request frame and the response frame are protected action frames, supra. However, Lu does not teach the protected request frame and the response frame comprising a key data length field and a key data field, wherein the key data length field is indicative of a length of the key data field and the key data field includes the one or more KDE.
IEEE P802.11be:321 teaches that “[f]or MLO [multi-link operations], the AP MLD Authenticator and non-AP MLD Supplicant manage the PMK and pairwise key derivation,” “the 4-way handshake and group key handshake take place between the AP MLD Authenticator and the non-AP MLD Supplicant,” and that “an originating STA may create a new GTKSA by using 4-way handshake or group key handshake.” Furthermore, § 12.7.6 of IEEE P802.11be:327-34, describing a 4-way handshake for multi-link operations (MLO), teaches the protected request frame and the response frame comprising a key data length field and a key data field, wherein the key data length field is indicative of a length of the key data field and the key data field includes the one or more KDE (e.g., each of the messages 1 to 4 contains “Key Data Length=length of Key Data field in octets” and “Key Data” wherein the Key Data for MLO contains “a MAC Address KDE containing the MLD MAC address of the Supplicant/Authenticator” and: (1) in message 2, “an MLO Link KDE for each affiliated STA link containing the affiliated STA MAC address included by the non-AP MLD in the Multi-Link element in (Re)Association Request frame,” while (2) in message 3, “a MLO Link KDE containing the LinkID field, the affiliated AP MAC address” and “the MLO GTK KDE for each setup link . . . If management frame protection is negotiated, the MLO IGTK KDE for each setup link . . . the MDE with the same contents as in the (Re)Association Response frame.”
Therefore Claim 2 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 3, dependent from Amended Claim 1, Lu further teaches the apparatus of claim 1, wherein the multi-link reconfiguration element of the request frame comprises a MLD capabilities and operations present field set to one in a presence bitmap (“the first multi-link element and/or the second multi-link element are used for the link addition or the link deletion in the multi-link reconfiguration” – See [¶0077], whereby “the first multi-link element includes at least one of . . . a first multi-link control field for indicating the type of the multi-link reconfiguration” – See [¶¶0087-88]; and “the first multi-link control field further includes a first presence bitmap subfield . . . used for indicating a subfield present in the first common information field of the first multi-link element” – See [¶0101] and Fig. 6, whereby “the format of the presence bitmap subfield in the multi-link control field of the multi-link element is illustrated in FIG. 7” showing 1 bit for MLD capabilities present – See [¶0273], and comprises indication of “a first MLD capabilities subfield for indicating an MLD capability of the first MLD” – See [¶0113] which includes “a first part of MLD capabilities subfield for indicating a first part of MLD capabilities information affected by the multi-link reconfiguration” – See [¶0115] or “a second part of MLD capabilities subfield for indicating a second part of MLD capabilities information not affected by the multi-link reconfiguration” – See [¶0116], i.e., indicating MLD capabilities and operations; see also § 9.4.2.312 of IEEE P802.11be:188, infra, defining a basic multi-link element).
Therefore, Claim 3 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 4, dependent from Amended Claim 1, Lu further teaches the apparatus of claim 1, wherein the multi-link reconfiguration element of the request frame comprises an enhanced multi-link (EML) capabilities present field set to 1 or 0 (as shown in Fig. 7 of the presence bitmap, 1 bit is allocated to EML Capabilities Present which may be set to 1 or 0; see also §§ 9.4.2.312.2.1-1 of IEEE P802.11be:190-192, infra, defining Multi-Link Control field and Common Info field of the Basic Multi-Link element).
Therefore, Claim 4 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 5, dependent from Amended Claim 1, Lu further teaches the apparatus of claim 1, wherein the multi-link reconfiguration element of the request frame comprises a non-simultaneous transmission reception (NSTR) link pair present in a STA control field and is set to 1 (“The first link information field in the first multi-link element includes STA information of an affiliated STA” – See [¶0127] and “in a case that the first multi-link element [e.g., link addition request] is a first type of multi-link element, the first STA control subfield includes at least” – See [¶0135] “. . . a first NSTR link pair present subfield for indicating whether an NSTR link pair subfield is present in the first STA information subfield” – See [¶0142] and Fig. 10-1 showing “the format of the STA control subfield” of “the first type of the reconfiguration multi-link element (i.e., addition reconfiguration multi-link element)” having “a NSTR link pair present subfield” of length 1 bit, i.e., could be set to “1” – See [¶0276]).
Therefore, Claim 5 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 6, dependent from Amended Claim 1, Lu further teaches the apparatus of claim 1, wherein the multi-link reconfiguration element of the request frame comprises a NSTR bitmap size field in a STA control field, wherein a complete profile field is set to 1, and wherein a medium access control (MAC) address present field is set to 1 (the format of the STA control subfield illustrated in FIG. 10-1, further comprises “a NSTR bitmap size subfield” of length 1 bit, and “a complete profile subfield, an MAC address present subfield” each of 1 bit, hence can be “1” – See [¶0276], e.g., when “the addition reconfiguration multi-link element indicates the MLD MAC address of the non-AP MLD, indicates complete information of the non-AP STA3 in the carried per-STA profile subelement and requests for setup of an addition link between the non-AP STA3 and the AP3” – See [¶0288] and Fig. 11).
Therefore, Claim 6 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 7, dependent from Amended Claim 1, Lu further teaches the apparatus of claim 1, wherein the multi-link reconfiguration element of the request frame comprises a station (STA) profile field (a “first multi-link element is carried in a first action field of a first request frame” – See [¶0173], and “the first multi-link element includes at least one of the following: a first common information field for indicating the link common information; or a first link information field for indicating link information of the first part of links and/or link information of the link associated with the first part of links in the second part of links” – See [¶¶0087, 0089, 0090], and “[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], whereby “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 control subfield for indicating STA control information; a first STA information subfield for indicating STA information; or a first STA profile subfield for indicating STA profile information” – See [¶¶0128,0131-33]) as defined in an 802.11 association request frame and elements that will be present if sent in an 802.11 association request frame (“when a reporting STA of the multi-link element is a non-AP STA, a rule that the STA profile field corresponding to a reported non-AP STA in the multi-link element includes fields and elements is consistent with a rule that the STA profile field corresponding to a reported non-AP STA when the basic multi-link element is carried by the association request frame includes fields and elements” – See [¶0281]).
However, Lu does not teach a STA profile field comprising a capability information field and wherein an inheritance rule of the elements is based on the elements in the first STA profile field in the multi-link reconfiguration element.
Figure 35-5 of IEEE P802.11be:375 teaches a Basic Multi-Link element, carried in an Association Request frame format, like the one in Fig. 5 of Lu, wherein the Link Info of fig. 5 of Lu is developed into per-STA profile comprising the three elements described in Lu: STA control, STA info, and STA profile, as explained, supra, and the STA profile subfield contains capability information.
Thus, each of Lu and IEEE P802.11be teaches a multi-link reconfiguration element of a request frame. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the detailed description of the Basic Multi-Link element in an Association Request wherein the STA profile comprises capabilities information, as taught in IEEE P802.11be could have been substituted in for the first link information field in the first multi-link element as taught by Lu, because both contain the same subfields structure. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution through techniques known in the art. Finally, the substitution achieves the predictable result of aligning Lu with the IEEE P802.11be technical specification for Basic Multi-Link element.
Furthermore, while Lu teaches that “[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], § 35.3.2.3.1 of IEEE P802.11be:376 further teaches wherein an inheritance rule of the elements is based on the elements in the first STA profile field in the multi-link reconfiguration element (“It is possible for STAs affiliated with an MLD to have similar capabilities and operational parameters on different links” then “[t]o reduce the frame size, when a Per-STA Profile subelement carries complete profile for a reported STA, it inherits the elements from the reporting,” as shown in Fig. 35-4 for elements B, D, and Y of STA 1– See IEEE P802.11be:180.
Therefore, Claim 7 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 8, dependent from Amended Claim 1, Lu further teaches the apparatus of claim 1, wherein a complete profile field of the multi-link reconfiguration element of the response frame is set to 1 and wherein a MAC address present field of the multi-link reconfiguration element of the response frame is set to 1 (a “first multi-link element is carried in a first action field of a first request frame” – See [¶0173] and a “second multi-link element is carried in a second action field of a first response frame” – See [¶0260], whereby “the second multi-link element includes at least one of following: a second multi-link control field for indicating the type of the multi-link reconfiguration; a second common information field for indicating the link common information; or a second link information field for indicating link information of the first part of links and/or link information of the link associated with the first part of links in the second part of links” – See [¶¶0174-77]; and “the type of the second multilink element is a reconfiguration multi-link element” – See [¶0186], and “[t]he second link information field in the second 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 second MLD” – See [¶0214] wherein “the STA information is carried in a per-STA profile subelement, and the per-STA profile subelement includes at least . . . a second STA control subfield for indicating STA control information” – See [¶¶0215,0218], and “in a case that the second multi-link element is a first type of multi-link element, the second STA control subfield includes at least one of following … a second complete profile subfield for indicating whether the first STA profile subfield carries complete STA profile information; a second MAC address present subfield for indicating whether a STA MAC address subfield is present in the first STA information subfield” – See [¶¶0222,0225-26]; and ‘1’ represents complete STA profile and STA MAC address presence).
Therefore, Claim 8 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 9, dependent from Amended Claim 1, Lu further teaches the apparatus of claim 1, wherein the multi-link reconfiguration element of the response frame comprises a station (STA) profile field with a capability information field (“The link information field in the multi-link element [as shown in Fig. 5] carries link information of the reconfiguration link and/or the link affected by the reconfiguration operation in the established links. The link information herein is STA information of an affiliated STA operating on the link in the MLD, and the STA information is carried in the per-STA profile subelement” – See [¶0275] and Fig. 9).
Lu further teaches a Status code field in the association response frame to indicate whether the communication link is accepted or rejected to be added (“For each per-STA profile subelement of the link information field, the complete profile subfield of the STA control field is set to be 1, and 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’” or if “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]).
However, Lu does not teach “as defined in an 802.11 association response frame” including supported rates and basic service set (BSS) membership selectors field as defined in the 802.11 association response frame, and elements that will be present if sent in the 802.11 association response frame, and wherein an inheritance rule of the elements is based on the elements in the first STA profile field in the multi-link reconfiguration element.
Section 35.3.2.2 of IEEE P802.11be:376 teaches that “[t]he complete profile of a reported STA consists of all the elements and fields . . . that would be included in a Management frame, that is of the same subtype as that transmitted by the reporting STA carrying the Basic Multi-Link element, if the reported STA were to transmit the frame” and “[i]f the reporting STA is an AP, the STA Profile field corresponding to the reported AP” as when transmitting the association response frame, “fields and elements in the same order and subject to the conditions as in: . . . Table 9-63 (Association Response frame body) if the frame is an Association Response frame.” Furthermore, §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, wherein “a Management frame carries several elements with their corresponding element IDs shown in parenthesis” and “[t]he frame also carries a Basic Multi-Link element,” such as an association response frame wherein STA1 is shown with full profile and inherited and non-inherited elements, thus teaching wherein an inheritance rule of the elements is based on the elements in the first STA profile field in the multi-link reconfiguration element. Among the elements listed in a STA profile “[i]f an Association Response frame is received with a status code other than SUCCESS. . .[t]he status code returned in the Association Response frame indicates the cause of the failed association attempt” and “[a]ny misconfiguration or parameter mismatch, e.g., data rates required as basic rates that the STA or a non-AP STA affiliated with the non-AP MLD did not indicate as supported in the STA’s Supported Rates and BSS Membership Selectors element shall be corrected” – See IEEE P802.11be:289. Therefore, IEEE P802.11be teaches STA’s Supported Rates and BSS Membership Selectors elements.
PNG
media_image1.png
508
884
media_image1.png
Greyscale
Thus, each of Lu and IEEE P802.11be teaches a multi-link reconfiguration element of association response frame. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the detailed description of the STA profile in a Basic Multi-Link element of type Association Response wherein the STA profile comprises inherited and non-inherited elements, as taught in IEEE P802.11be could have been substituted in for the per-STA profile subelement in the second multi-link element as taught by Lu, because both contain the same subfields structure. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution through techniques known in the art. Finally, the substitution achieves the predictable result of aligning Lu with the IEEE P802.11be technical specification for Basic Multi-Link element.
Therefore, Claim 9 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 10, dependent from Amended Claim 1, Lu further teaches the apparatus of claim 1, wherein the multi-link reconfiguration element of the response frame comprises KDE-related information for the communication link including multi-link operations (MLO) group temporal key (GTK) KDE, MLO integrity GTK (IGTK) KDE, and MLO beacon IGTK (BIGTK) KDE when the communication link has been added based on the request (“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, a first part of parameters used by the first part of links and the second part of links is unchanged; and/or a second part of parameters used by the first part of links is re-established” – See [¶0262], whereby “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], wherein a person of ordinary skills in the art would know that each of the keys are a type of KDE – See, e.g., Table 12-10—KDE selectors, IEEE P802.11be:321).
Therefore, Claim 10 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 12, dependent from Amended Claim 1, Lu further teaches the apparatus of claim 1, further comprising a transceiver configured to transmit and receive signals comprising the request frame and the response frame (“as illustrated in FIG. 13, 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” – See [¶0494], whereby “the communication device 1300 may specifically be the first MLD in the embodiments of the present disclosure, and the communication device 1300 may implement the corresponding process implemented by the first MLD in each method of the embodiments of the present disclosure” – See [¶0496])
Therefore, Claim 12 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 13, dependent from Claim 12, Lu further teaches the apparatus of claim 12, further comprising an antenna coupled to the transceiver to cause to send the request frame (“The transceiver 1530 may further include an antenna(s), the number of which may be one or more” – See [¶0495] and Fig. 13, whereby the communication device is the first MLD, as explained in Regarding Claim 12, supra)
Therefore, Claim 13 is obvious over Lu in view of IEEE P802.11be.
Regarding Amended Claim 14, Lu teaches a non-transitory computer-readable medium storing computer-executable instructions which when executed by one or more processors of an access point (AP) multi-link device (AP-MLD) result in performing operations (“The processor 1410 may invoke and execute a computer program from the memory 1420 to implement the method in the embodiments of the present disclosure” whereby “[t]he memory 1420 may be a separate device independent of the processor 1410 or the memory 1420 may be integrated into the processor 1410” – See [¶¶0599-500] and Fig. 14) comprising:
identifying a request frame received from a non-AP-MLD, the request frame comprising a multi-link reconfiguration element indicative of a request to add or remove a communication link between the non-AP-MLD and an AP-MLD, the communication link previously used by the non-AP-MLD (“After the non-AP MLD has successfully completed the multi-link setup and association with the AP MLD, when the non-AP MLD needs to establish an addition link or delete an established link with the AP MLD” the “non-AP MLD may send the multi-link reconfiguration request frame to the AP MLD on the established link” and “[t]he multi-link reconfiguration request frame carries the first multi-link element” indicative of a request to add or remove a communication link – See [¶0286]);
encoding a response frame comprising the multi-link reconfiguration element (“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 “the second multi-link element includes at least one of following:” element recited in [¶¶0174-181] and shown in Fig. 5) and
indicating whether the communication link was accepted or rejected to be added or removed (“For the case that the non-AP MLD requests addition links, the AP MLD may accept all addition links requested to be established or a part of addition links requested to be established” – See [¶0287]; and “[t]he addition reconfiguration multi-link element carried in the addition multi-link reconfiguration response frame includes a common information field and a link information field” whereby “[t]he link information field includes a per-STA profile subelement corresponding to the addition link. For each per-STA profile subelement of the link information field, the complete profile subfield of the STA control field is set to be 1, and 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 the AP-MLD to transmit the response frame (“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 for one or more communication links that were accepted to be added the same limitations apply as recited in Amended Claim 1 using the same language.
Therefore, Amended Claim 14 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 15, dependent from Amended Claim 14, the claim language is a mere recitation of the limitation applied to the request frame and the response frame are protected action frames used to add or remove a communication link between the non-AP-MLD and an AP-MLD using the same language as in Claim 2. Because the limitation is obvious over Lu in view of IEEE P802.11be and the non-transitory computer-readable medium storing computer-executable instructions which when executed by one or more processors of an access point (AP) multi-link device (AP-MLD) interact with the aforementioned frames is also obvious over Lu in view of IEEE P802.11be, Claim 15 is obvious over Lu in view of IEEE P802.11be.
Therefore, Claim 15 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 16, dependent from Amended Claim 14, Lu further teaches the non-transitory computer-readable medium of claim 14, wherein the multi-link reconfiguration element of the request frame comprises a MLD capabilities and operations present field set to one in a presence bitmap (whereby “the first multi-link element includes at least one of . . . a first multi-link control field for indicating the type of the multi-link reconfiguration” – See [¶¶0087-88]; and “the first multi-link control field further includes a first presence bitmap subfield . . . used for indicating a subfield present in the first common information field of the first multi-link element” – See [¶0101] and Fig. 6, whereby “the format of the presence bitmap subfield in the multi-link control field of the multi-link element is illustrated in FIG. 7” showing 1 bit for MLD capabilities present which can be set to 1 – See [¶0273], and comprises indication of “a first MLD capabilities subfield for indicating an MLD capability of the first MLD” – See [¶0113] which includes “a first part of MLD capabilities subfield for indicating a first part of MLD capabilities information affected by the multi-link reconfiguration” – See [¶0115] or “a second part of MLD capabilities subfield for indicating a second part of MLD capabilities information not affected by the multi-link reconfiguration” – See [¶0116], i.e., indicating MLD capabilities and operations; see also § 9.4.2.312 of IEEE P802.11be:188, infra, defining a basic multi-link element).
Therefore, Claim 16 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 17, dependent from Amended Claim 14, Lu further teaches The non-transitory computer-readable medium of claim 14, wherein the multi-link reconfiguration element of the request frame comprises an enhanced multi-link (EML) capabilities present field set to 1 or 0 (as shown in Fig. 7 of the presence bitmap, 1 bit is allocated to EML Capabilities Present which may be set to 1 or 0; see also §§ 9.4.2.312.2.1-1 of IEEE P802.11be:190-192, infra, defining Multi-Link Control field and Common Info field of the Basic Multi-Link element).
Therefore Claim 17 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 18, dependent from Amended Claim 14, Lu further teaches the non-transitory computer-readable medium of claim 14, wherein the multi-link reconfiguration element of the request frame comprises a non-simultaneous transmission reception (NSTR) link pair present in a STA control field and is set to 1 (“The first link information field in the first multi-link element includes STA information of an affiliated STA” – See [¶0127] and “in a case that the first multi-link element [e.g., link addition] is a first type of multi-link element, the first STA control subfield includes at least” – See [¶0135] “. . . a first NSTR link pair present subfield for indicating whether an NSTR link pair subfield is present in the first STA information subfield” – See [¶0142] and Fig. 10-1 showing “the format of the STA control subfield” of “the first type of the reconfiguration multi-link element (i.e., addition reconfiguration multi-link element)” having “a NSTR link pair present subfield” of length 1 bit, i.e., could be set to “1” – See [¶0276]).
Therefore, Claim 18 is obvious over Lu in view of IEEE P802.11be.
Regarding Claim 19, dependent from Amended Claim 14, Lu further teaches the non-transitory computer-readable medium of claim 14, wherein the multi-link reconfiguration element of the request frame comprises a NSTR bitmap size field in a STA control field, wherein a complete profile field is set to 1, and wherein a medium access control (MAC) address present field is set to 1. (the format of the STA control subfield illustrated in FIG. 10-1, further comprises “a NSTR bitmap size subfield” of length 1 bit, and “a complete profile subfield, an MAC address present subfield” each of 1 bit, hence can be “1” – See [¶0276], e.g., when “the addition reconfiguration multi-link element indicates the MLD MAC address of the non-AP MLD, indicates complete information of the non-AP STA3 in the carried per-STA profile subelement and requests for setup of an addition link between the non-AP STA3 and the AP3” – See [¶0288] and Fig. 11).
Therefore, Claim 19 is obvious over Lu in view of IEEE P802.11be.
Regarding Amended Claim 20, Lu teaches a method for adding or removing affiliated access points (APs) (“a multi-link reconfiguration method” – See [¶0005] and “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]), the method comprising each of the steps executed by the processing circuitry of an apparatus of a non-access point (AP) multi-link device (non-AP-MLD) for adding or removing communication APs affiliated with an associated AP MLD, whereby the execution of each step is described with the language of the corresponding step in Amended Claim 1. Because the apparatus of a non-access point (AP) multi-link device (non-AP-MLD) for adding or removing communication APs affiliated with an associated AP MLD and the steps performed by the processing circuitry of the apparatus are obvious over Lu in view of IEEE P802.11be, Amended Claim 20 is obvious over Lu in view of IEEE P802.11be.
In sum, Claims 1-10, and 12-20, as amended are rejected under 35 U.S.C. 103 as obvious over Lu in view of IEEE P802.11be.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Patil et al., U.S. Patent No. US 11228963 disclosing systems, 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;
Viger et al., U.S. Patent Application Publication No. US 2023/0119901disclosing 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 802.11-21/1175r5, title: “CC36 Resolution for CIDs related to Multi-Link Advertisement – Part 1,” Source: Qualcomm, July 2021.
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