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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on December 18th, 2024 and May 1st, 2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 non-obviousness.
Claims 1, 4, 7, 10, 11, 13, 15, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Cariou (U.S. Publication No. US 20230380001 A1, as cited by applicant), and further in view of Hu (U.S. Publication No. US 20220124855 A1, as cited by applicant).
Regarding claim 11,
Cariou ‘0teaches at least one memory configured to store machine executable instructions
("memory 710" [Paragraph 94])
and at least one processor communicatively coupled with the at least one memory and configured to execute the machine executable instructions
("The processing circuitry 708 may include a processor such as a general purpose processor or special purpose processor." [Paragraph 94])
to: generate a frame including at least one multi-link reconfiguration element
(" In some embodiments, the wireless device 700 is configured to decode and/or encode signals, packets, and/or frames as described herein, e.g., PPDUs," and
Figure 11 illustrates an AP MLD management frame containing a "reconfiguration multilink element 1104",
i.e. Here, "encode" can be seen as analogous to "generate," meaning that the device ultimately will result in a frame containing a multi-link reconfiguration element.)
Cariou does not directly teach wherein the at least one multi-link reconfiguration element includes at least one add link operation based on which a non-access point multi-link device (non-AP MLD) performs a link level roaming between the AP MLD and a second AP MLD, wherein both of the AP MLD and the second AP MLD belong to a seamless mobility domain; and send the frame to the non-AP MLD to perform the link level roaming.
In an analogous art, Hu teaches the at least one multi-link reconfiguration element includes at least one add link operation
("In some embodiments, ML reconfiguration procedures may add links to, or remove links from, a link set in use by two associated MLDs. The procedure of adding or removing a link may be in the form of a request/response exchange initiated by a non-AP MLD; however, an AP MLD may trigger a non-AP MLD to make a reconfiguration request." [Paragraph 129],
i.e. The "AP-MLD reconfiguration request" may be considered analogous the multi-link reconfiguration element. Therefore, the multi-link reconfiguration element may be considered to have both add link and delete link operations associated with it.)
based on which a non-access point multi-link device (non-AP MLD) performs a link level roaming between the AP MLD and a second AP MLD,
("In some embodiments, a ML reconfiguration can be a standard part of architecture such that a MLO framework can provide mechanisms to make adjustments post association without having to disassociate. It is noted that the case of non-AP switching to different AP within the MLDs is remotely similar to BSS Transition Management (BTM), which allows AP to instruct client to start roaming, but there is really no network-wide transition in a ML reconfiguration." [Paragraph 90],
i.e. The "client" here may be the non-AP MLD.)
wherein both of the AP MLD and the second AP MLD belong to a seamless mobility domain
("FIG. 4 is a diagram of an example multi-link (ML) reconfiguration according to an example implementation of the present disclosure. In some embodiments, a ML configuration may include changing/updating/adjusting/reconfiguring in the number of links. For example, referring to FIG. 4, a ML configuration 410 in which an AP MLD 401 and a non-AP MLD 402 are paired or associated via two links, can be changed or reconfigured (ML reconfiguration 405) to a new ML configuration 420 in which the AP MLD 401 and the non-AP MLD 402 are paired or associated via three links." [Paragraph 73],
i.e. The configuration of non-AP MLD linked to multiple AP MLD, and these links being possible to change, is demonstrative of the seamless mobility domain described in the disclosure.)
and send the frame to the non-AP MLD to perform the link level roaming.
("In some embodiments, a ML reconfiguration can be a standard part of architecture such that a MLO framework can provide mechanisms to make adjustments post association without having to disassociate. It is noted that the case of non-AP switching to different AP within the MLDs is remotely similar to BSS Transition Management (BTM), which allows AP to instruct client to start roaming, but there is really no network-wide transition in a ML reconfiguration." [Paragraph 90],
i.e. The "client" here may be the non-AP MLD.)
Therefore, as Cariou teaches a frame including including a multi-link reconfiguration element, and as Hu teaches link level roaming with the non-AP MLD and AP MLDs in a seamless mobility domain based on add link operations in the multi-link reconfiguration element, to one of ordinary skill in the art prior to the effective filing date of the claimed invention, it would be obvious to Cariou’s frame with Hu’s method of roaming in a seamless mobility domain. The motivation to combine is to have a frame with particular operations and elements that facilitate roaming in a seamless mobility environment, thereby allowing "efficient use of the resources of a wireless local-area network (WLAN)" (Cariou '001, Paragraph 2) and "reachability and/or range changes (environment or mobility change related scenario)" (Hu, Paragraph 70).
Regarding claim 13, Cariou-Hu teaches all the limitations and motivations of claim 11.
Hu also teaches update the frame to further include a seamless mobility domain identifier that identifies the seamless mobility domain
("In some embodiments, a ML reconfiguration may be performed in a manner similar to that of BSS Transition Management (BTM) in that (1) AP recommends non-AP to transition to a new AP, (2) Query, Request and Response frames are used, and/or (3) a Neighbor Report element is used." [Paragraph 95],
i.e. The Neighbor Report elements can be seen as analogous to the seamless mobility domain, as it is a structure in the frame that identifies the domain through neighboring AP MLDs."
Regarding claim 15, Cariou-Hu teaches all the limitations and motivations of claim 11.
Hu teaches update the frame to further include at least one delete link operation in the at least one multi-link reconfiguration element
("In some embodiments, ML reconfiguration procedures may add links to, or remove links from, a link set in use by two associated MLDs. The procedure of adding or removing a link may be in the form of a request/response exchange initiated by a non-AP MLD; however, an AP MLD may trigger a non-AP MLD to make a reconfiguration request." [Paragraph 129],
i.e. The "AP-MLD reconfiguration request" may be considered analogous the multi-link reconfiguration element. Therefore, the multi-link reconfiguration element may be considered to have both add link and delete link operations associated with it.)
wherein the at least one delete link operation identifies one or more links of the AP MLD to be deleted when performing the link level roaming
("In some embodiments, the Link ID subfield may designate/identify/specify the AP that the AP MLD is recommending the non-AP STA to connect to, or may be set to <To Be Defined> if the AP MLD is recommending the non-AP STA to disconnect." [Paragraph 137])
wherein the at least one add link operation identifies one or more links of the second AP MLD to be added when performing the link level roaming
("In some embodiments, the Link ID subfield may designate/identify/specify the AP that the AP MLD is recommending the non-AP STA to connect to, or may be set to <To Be Defined> if the AP MLD is recommending the non-AP STA to disconnect." [Paragraph 137])
Regarding claim 16, Cariou-Hu teaches all the limitations and motivations of claim 11.
Cariou teaches the AP MLD and the second AP MLD is identified in the frame by a respective AP MLD media access control (MAC) address
("AP1 830, AP2 832, and AP3 834 includes different media access control (MAC) address (addr), which are MAC adder 848, MAC addr 850, and MAC addr 852, respectively." [Paragraph 101])
Regarding claim 20, Cariou-Hu teaches all the limitations and motivations of claim 11.
Cariou also teaches update the frame to further include a disassociation imminent field specifying a disassociation time for disassociating the non-AP MLD from the AP MLD if the non-AP MLD does not perform the link level roaming based on the at least one multi-link reconfiguration element
("In some examples, the management frame 1102, reconfiguration multilink element 1104, and/or per-STA profile subelement 1106 include a field, disassociated imminent 1110, that indicates to the non-AP MLD 809 that the non-collocated AP MLD3 912 will enforce the ML configuration if the non-AP MLD 809 does not initiate adding and/or deleting the links indicated by the reconfiguration multilink element 1104… In some examples, the same examples, the disassociated imminent 1110 field indicates when (a time) the non-AP MLD 809 will get disassociated (from, for example, APs indicated in the reconfiguration multilink element 1104 to “delete”). " [Paragraph 122])
Regarding claim 1, Cariou-Hu also teaches all the limitations of claim 1 in claim 11, in device mode rather than method mode. Therefore, claim 1 is rejected for the same reasons as claim 11.
Regarding claim 4, Cariou-Hu teaches all the limitations and motivations of claim 1. Cariou ‘001-Hu also teaches all the limitations of claim 4 in claim 13, in device mode rather than method mode. Therefore, claim 4 is rejected for the same reasons as claims 1 and 13.
Regarding claim 7, Cariou-Hu teaches all the limitations and motivations of claim 1. Cariou-Hu also teaches all the limitations of claim 7 in claim 15, in device mode rather than method mode. Therefore, claim 7 is rejected for the same reasons as claims 1 and 15.
Regarding claim 10, Cariou-Hu teaches all the limitations and motivations of claim 1. Cariou-Hu also teaches all the limitations of claim 10 in claim 20, in device mode rather than method mode. Therefore, claim 10 is rejected for the same reasons as claims 1 and 20.
Claims 2, 3, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Cariou-Hu further in view of Lundsgaard (U.S. Publication No. US 20110216692 A1) and Gan (U.S. Publication No. US 20200336969 A1).
Regarding claim 12, Cariou-Hu teaches all the limitations and motivations of claim 11.
Cariou-Hu do not directly teach determine a roaming time based on a predicted connectivity loss for the non-AP MLD with the AP MLD, wherein the AP MLD is a current AP MLD; and update the frame to further include the roaming time indicating a recommended time of performing the link level roaming, wherein the roaming time is a timing synchronization function (TSF) time of the AP MLD by which, or at which, the non-AP MLD is expected to perform the link level roaming.
In an analogous art, Lundsgaard teaches determine a roaming time based on a predicted connectivity loss for the non-AP MLD with the AP MLD, wherein the AP MLD is a current AP MLD
("The wireless communication device 160 can perform scanning when a roaming trigger event occurs. The roaming trigger event varies depending on the particular implementation. Examples of roaming trigger events include (1) expiration of a timer, (2) observing changes in link quality (e.g., decrease in RSSI or Received Channel Power Indicator (RCPI), a number of missed beacon frames, an increased percentage of unacknowledged packets and/or retransmission of packets)." [Paragraph 51])
Therefore, as Cariou-Hu teaches a frame of an AP MLD roaming in a seamless mobility domain, and as Lundsgaard teaches a basis for determining roaming time, to one of ordinary skill in the art prior to the effective filing date of the claimed invention, it would be obvious to combine Cariou-Hu’s device with Lundsgaard’s method. The motivation to combine is to have a frame of an AP MLD roaming in a seamless mobility domain where roaming time is updated based on predicted connectivity loss, thereby "provid[ing] improved AP selection techniques for use by a wireless communication device as the wireless communication device encounters different APs when moving from one physical location to another in a network" (Lundsgaard, Paragraph 10).
Neither Cariou-Hu nor Lundsgaard teach update the frame to further include the roaming time indicating a recommended time of performing the link level roaming, wherein the roaming time is a timing synchronization function (TSF) time of the AP MLD by which, or at which, the non-AP MLD is expected to perform the link level roaming.
In an analogous art, Gan teaches update the frame to further include the roaming time indicating a recommended time of performing the link level roaming, wherein the roaming time is a timing synchronization function (TSF) time of the AP MLD by which, or at which, the non-AP MLD is expected to perform the link level roaming
("…an unassociated STA or a STA in a roaming state can infer a time at which the AP operating on the 6 GHz band sends a beacon frame, and effectively listen to a corresponding channel on the 6 GHz band for the beacon frame sent by the AP operating on the 6 GHz band to further learn of information about an associated BSS and clock synchronization information of the AP operating on the 6 GHz band, after learning of the TSF information and the beacon frame information of the AP operating on the 6 GHz band." [Paragraph 71])
Therefore, as Cariou-Hu-Lundsgaard teaches a frame of an AP MLD roaming in a seamless mobility domain where roaming time is updated based on predicted connectivity loss, and as Gan teaches updating roaming time based on TSF, to one of ordinary skill in the art prior to the effective filing date of the claimed invention, it would be obvious to combine Cariou-Hu-Lundsgaard’s device with Gan’s method. The motivation to combine is to have a frame of an AP MLD roaming in a seamless mobility domain where roaming time is updated based on predicted connectivity loss and TSF, thereby reducing "long duration, high energy consumption, and unnecessary congestion" present in alternate methods during roaming operations (Gan, Paragraph 3).
Regarding claim 2, Cariou-Hu teaches all the limitations and motivations of claim 1. Cariou-Hu-Lundsgaard-Gan also teaches all the limitations of claim 1 in claim 12, in device mode rather than method mode. Therefore, claim 2 is rejected for the same reasons as claims 1 and 12.
Regarding claim 3, Cariou -Hu teaches all the limitations and motivations of claim 1. Cariou-Hu-Lundsgaard-Gan also teaches all the limitations of claim 1 in claim 12, in device mode rather than method mode. Therefore, claim 3 is rejected for the same reasons as claims 1 and 12.
Claims 5, 6, 8, 9, 14, 17, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Cariou-Hu further in view of Amini (U.S. Publication No. US 20170135018 A1).
Regarding claim 14, Cariou-Hu teaches all the limitations and motivations of claim 11.
Cariou also teaches the frame includes a first multi-link reconfiguration element and a second multi-link reconfiguration element, the first multi-link reconfiguration element corresponding to a first target AP MLD that is the second AP MLD and the second multi-link reconfiguration element corresponding to a second target AP MLD
("The management frame 1102 includes the Reconfiguration Multi-Link element 1104 that includes a Per-station (STA) Profile subelement 1106 for each affiliated AP, e.g., AP1 through AP6, that the non-collocated AP MLD3 912 advises the non-AP MLD 809 to add or delete to its ML setup" [Paragraph 114],
i.e. Multiple reconfiguration elements associated with each AP, as needed for an embodiment.)
Cariou-Hu does not directly teach receive, from the non-AP MLD, an acceptance of the link level roaming corresponding to the first multi-link reconfiguration element; and receive, from the non-AP MLD, a rejection of the link level roaming corresponding to the second multi-link reconfiguration element.
In an analogous art, Amini teaches receive, from the non-AP MLD, an acceptance of the link level roaming corresponding to the first multi-link reconfiguration element
("In a number of implementations, the mesh network's roaming commands support the BSS Transition Management (BTM) for network assisted roaming, described in IEEE 802.11v standards for wireless network management. In general, BTM allows steering the client seamlessly even when there is ongoing traffic…Specifically, the BSS Transition Management Request can be used when the AP (e.g., a mesh point) offers advice to the client. This can include a list of the APs (e.g., other mesh points) to which the client can consider associate (e.g., “Neighbor Report” information). The BSS Transition Management Response can be used for the client to accept or reject, and the client can also include a reason code for the acceptance or rejection." [Paragraph 109])
receive, from the non-AP MLD, a rejection of the link level roaming corresponding to the second multi-link reconfiguration element
("In a number of implementations, the mesh network's roaming commands support the BSS Transition Management (BTM) for network assisted roaming, described in IEEE 802.11v standards for wireless network management. In general, BTM allows steering the client seamlessly even when there is ongoing traffic…Specifically, the BSS Transition Management Request can be used when the AP (e.g., a mesh point) offers advice to the client. This can include a list of the APs (e.g., other mesh points) to which the client can consider associate (e.g., “Neighbor Report” information). The BSS Transition Management Response can be used for the client to accept or reject, and the client can also include a reason code for the acceptance or rejection." [Paragraph 109])
Therefore, as Cariou-Hu teaches a frame of an AP MLD roaming in a seamless mobility domain, and as Amini teaches actions and information regarding roaming preferences, to one of ordinary skill in the art prior to the effective filing date of the claimed invention, it would be obvious to combine Cariou-Hu’s device with Amini’s method. The motivation to combine is to have a frame of an AP MLD roaming in a seamless mobility domain which further includes information and actions to be performed in regard to roaming preference, thereby providing an "integral solution where multiple wireless local area network (WLAN) mesh point devices are deployed in a relatively large environment with potential dead spots, such as a home or an office" (Amini, Paragraph 37).
Regarding claim 17, Cariou-Hu teaches all the limitations and motivations of claim 11.
Cariou-Hu does not directly teach update the frame to further include a roaming command specifying a preference of the AP MLD for the at least one multi-link reconfiguration element, wherein the preference includes one of the link level roaming being mandatory, the link level roaming being preferred, the link level roaming being suggestive, and the link level roaming being neutral.
In an analogous art, Amini suggests update the frame to further include a roaming command specifying a preference of the AP MLD for the at least one multi-link reconfiguration element
("In a number of implementations, the mesh network's roaming commands support the BSS Transition Management (BTM) for network assisted roaming, described in IEEE 802.11v standards for wireless network management. In general, BTM allows steering the client seamlessly even when there is ongoing traffic…Specifically, the BSS Transition Management Request can be used when the AP (e.g., a mesh point) offers advice to the client. This can include a list of the APs (e.g., other mesh points) to which the client can consider associate (e.g., “Neighbor Report” information). The BSS Transition Management Response can be used for the client to accept or reject, and the client can also include a reason code for the acceptance or rejection." [Paragraph 109])
wherein the preference includes one of the link level roaming being mandatory, the link level roaming being preferred, the link level roaming being suggestive, and the link level roaming being neutral
("At the first dead spot (or as an alternative, continuously during the walk), the application employs one or more of the link rate estimation techniques introduced hereafter to monitor the wireless coverage, and automatically generate feedbacks to the user with regard to the location where the additional mesh points should be installed. Examples of such feedbacks or advices are: “Too close” (e.g., FIG. 7A), “Close” (e.g., FIG. 7B), “Good” (e.g., FIG. 7C), “A bit far” (e.g., FIG. 7D), and “Too far” (e.g., FIG. 7E). In some embodiments, to maximize the coverage, the user is instructed to install the additional mesh point(s) in the farthest possible place that is still considered “Good,” e.g., the closet possible places between “Good” and “A bit far.”" [Paragraph 71],
i.e. Here, feedback/advice is denoted with keywords suggestive of some preference hierarchy present in the communications between non-AP devices and AP devices to choose for the current AP to connect to nearby APs. The mandatory/preferred/suggestive/neutral labels are also suggestive of software processes that make determinations regarding connections, and the result of those determinations may be represented in any manner to a non-AP intermediary that is receiving information from the AP (“link level roaming being” a preference regarding connection).)
Therefore, as Cariou-Hu teaches a frame of an AP MLD roaming in a seamless mobility domain, and as Amini suggests actions and information regarding roaming preferences, to one of ordinary skill in the art prior to the effective filing date of the claimed invention, it would be obvious to combine Cariou ‘206-Cariou ‘001-Hu’s device with Amini’s method. The motivation to combine is to have a frame of an AP MLD roaming in a seamless mobility domain which further includes information and actions to be performed in regard to roaming preference, thereby providing an "integral solution where multiple wireless local area network (WLAN) mesh point devices are deployed in a relatively large environment with potential dead spots, such as a home or an office" (Amini, Paragraph 37).
Regarding claim 18, Cariou-Hu-Amini teaches all the limitations and motivations of claim 17.
Amini also teaches update the frame to further include a roaming reason field specifying a reason for the preference
("In a number of implementations, the mesh network's roaming commands support the BSS Transition Management (BTM) for network assisted roaming, described in IEEE 802.11v standards for wireless network management. In general, BTM allows steering the client seamlessly even when there is ongoing traffic…Specifically, the BSS Transition Management Request can be used when the AP (e.g., a mesh point) offers advice to the client. This can include a list of the APs (e.g., other mesh points) to which the client can consider associate (e.g., “Neighbor Report” information). The BSS Transition Management Response can be used for the client to accept or reject, and the client can also include a reason code for the acceptance or rejection." [Paragraph 109])
Regarding claim 19, Cariou-Hu-Amini teaches all the limitations and motivations of claim 17.
Amini also teaches the reason for the preference corresponds with one of a high load on the AP MLD, and a degraded quality of service (QoS) at the AP MLD
(“
"In a number of implementations, the mesh network's roaming commands support the BSS Transition Management (BTM) for network assisted roaming, described in IEEE 802.11v standards for wireless network management. In general, BTM allows steering the client seamlessly even when there is ongoing traffic…Specifically, the BSS Transition Management Request can be used when the AP (e.g., a mesh point) offers advice to the client. This can include a list of the APs (e.g., other mesh points) to which the client can consider associate (e.g., “Neighbor Report” information). The BSS Transition Management Response can be used for the client to accept or reject, and the client can also include a reason code for the acceptance or rejection." [Paragraph 109], and
i.e. Traffic influence load on AP and QoS, therefore influencing reason for preference for acceptance or rejection to a particular links.
Additionally, Amini also suggests the AP statistics (APSs) can include any one of a number of statistics or communication performance metrics which characterize or reflect, for example, the link capacity and/or link quality of the communication link between the wireless communication device 160 and the APs [Paragraph 27]. The APSs can generally include any known Link Quality Metrics (LQMs) and/or Link Capacity Metrics (LCMs). LQMs can include any metrics which reflect channel or link quality between the wireless communication device 160 and an AP.)
Regarding claim 5, Cariou-Hu teaches all the limitations and motivations of claim 1. Cariou-Hu-Amini also teaches all the limitations of claim 5 in claim 14, in device mode rather than method mode. Therefore, claim 5 is rejected for the same reasons as claims 1 and 14.
Regarding claim 6, Cariou-Hu teaches all the limitations and motivations of claim 1. Cariou-Hu-Amini also teaches all the limitations of claim 6 in claim 14, in device mode rather than method mode. Therefore, claim 6 is rejected for the same reasons as claims 1 and 14.
Regarding claim 8, Cariou-Hu teaches all the limitations and motivations of claim 1. Cariou-Hu-Amini also teaches all the limitations of claim 8 in claim 17, in device mode rather than method mode. Therefore, claim 8 is rejected for the same reasons as claims 1 and 17.
Regarding claim 9, Cariou-Hu-Amini teaches all the limitations and motivations of claim 8. Cariou-Hu-Amini also teaches all the limitations of claim 9 in claim 18, in device mode rather than method mode. Therefore, claim 9 is rejected for the same reasons as claims 8 and 18.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FATIHA KAMAL whose telephone number is (571)270-0726. The examiner can normally be reached M-Th 6:30am - 3:30pm, Alternating Fridays 6:30am-2:30pm.
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, Alison Slater can be reached at (571)270-0375. 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.
/FATIHA KAMAL/Examiner, Art Unit 2647
/Alison Slater/Supervisory Patent Examiner, Art Unit 2647
Prosecution Insights