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 .
Terminal Disclaimer
The terminal disclaimer filed on April 21, 2026 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of co-pending application 18/615,748 has been reviewed and is accepted. The terminal disclaimer has been recorded.
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, 2, 3 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Applicant’s admitted prior art (Specification’s Technical problem citing IEEE 802.11be specification in paragraphs [0004]-[0008], and FIG. 1, hereinafter referred to as “IEEE 802.11be.” The same disclosure can be found in the application’s publication 2024/0237071 paragraphs [0004]-[0018] and FIG. 1) in view of Seok et al. (US 2020/0383156, “Seok”) and further in view of Ko et al. (US 2024/0129886,”Ko”).
Regarding claim 1, IEEE 802.11be teaches A wireless communication method for medium access recovery ([0005] “IEEE 802.11be draft 1.1 has specified a medium access recovery procedure to address the blindness issue at a non-AP multi-link device (MLD) with a non-simultaneous transmit and receive (NSTR) pair”), comprising:
setting, by a station (STA) affiliated with a non-simultaneous transmit and receive (NSTR) soft access point multi-link device (AP MLD) in a nonprimary link, a MediumSyncDelay timer to nonzero by starting the MediumSyncDelay timer at an end of a transmission by another STA affiliated with the same MLD when that transmission event is longer than a MediumSyncThreshold; wherein the STA has lost medium synchronization due to the transmission ([0006] “A STA that has lost medium synchronization due to transmission by another STA affiliated with the same MLD shall start a MediumSyncDelay timer at the end of that transmission event if that transmission event is longer than aMediumSyncThreshold…. 3) A non-AP STA is affiliated with non-AP MLD, has a nonzero MediumSyncDelay timer.” FIG. 1 shows STAs 121c, 122c, 123c, 124c are associated with AP MLD 110c);
transmitting, by the STA with a nonzero MediumSyncDelay timer, a request to send (RTS) frame as an initial frame of an obtained transmission opportunity (TXOP) ([0006] “3) A non-AP STA is affiliated with non-AP MLD, has a nonzero MediumSyncDelay timer, and supports to obtain a TXOP, and the non-AP STA shall: transmit an RTS frame as the first frame of any attempt to obtain a TXOP”) {to its associated non-AP STA in the nonprimary link only when another STA affiliated with the same soft AP MLD in a primary link is also initiating another physical protocol data unit (PPDU) as a TXOP holder or another STA affiliated with the same soft AP MLD in the primary link is also transmitting another PPDU at the same time, when capable of obtaining the TXOP}; and
{determining, by the STA with the nonzero MediumSyncDelay timer, whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving a PPDU with a valid media access control protocol data unit (MPDU); wherein determining, by the STA with the nonzero MediumSyncDelay timer, whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving the PPDU with the valid MPDU, comprises: resetting the MediumSyncDelay timer to zero when the STA receives the PPDU with the valid MPDU, and/or the STA receives a PPDU whose corresponding RXVECTOR parameter TXOPDURATION is not UNSPECIFIED}.
IEEE 802.11be does not teach transmitting… a request to send (RTS) to its associated non-AP STA in the nonprimary link only when another STA affiliated with the same soft AP MLD in a primary link is also initiating another physical protocol data unit (PPDU) as a TXOP holder or another STA affiliated with the same soft AP MLD in the primary link is also transmitting another PPDU at the same time, when capable of obtaining the TXOP.
However, the Examiner submits transmissions an RTS to an associated non AP STA for a TXOP is well known in the art. For example, Seok teaches transmitting… a request to send (RTS) to its associated non-AP STA in the nonprimary link only when another STA affiliated with the same soft AP MLD in a primary link is also initiating another physical protocol data unit (PPDU) as a TXOP holder or another STA affiliated with the same soft AP MLD in the primary link is also transmitting another PPDU at the same time, when capable of obtaining the TXOP ([0058] “When an STA within the constrained MLD that obtains the TXOP sends a frame to a peer STA within another MLD, the wireless STA initiates an RTS/MU-RTS and CTS frame exchange sequence with the peer STA MLD1 transmits RTS frame 605, and the constrained MLD C-MLD3 responds with CTS frame 615… Link 2 of the constrained MLD C-MLD2 is busy while C-MLD2 is transmitting A-MPDU 615. ” Also note: FIG. 6 shows STA in MLD1 transmits RTS frame 605 on link L2, while STA in C-MLD2 transmits A-MPDU on link L1).
It would have been obvious before the effective filing date of the claimed invention for a person having ordinary skill in the art to include the feature transmitting… a request to send (RTS) to its associated non-AP STA in the nonprimary link only when another STA affiliated with the same soft AP MLD in a primary link is also initiating another physical protocol data unit (PPDU) as a TXOP holder or another STA affiliated with the same soft AP MLD in the primary link is also transmitting another PPDU at the same time, when capable of obtaining the TXOP, as taught by Seok in IEEE 802.11be to perform constrained multi-link operations that increases throughput of the wireless network while advantageously preventing or mitigating the IDC interference.
Further the combination does not teach
determining, by the STA with the nonzero MediumSyncDelay timer, whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving a PPDU with a valid media access control protocol data unit (MPDU); wherein determining, by the STA with the nonzero MediumSyncDelay timer, whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving the PPDU with the valid MPDU, comprises: resetting the MediumSyncDelay timer to zero when the STA receives the PPDU with the valid MPDU, and/or the STA receives a PPDU whose corresponding RXVECTOR parameter TXOPDURATION is not UNSPECIFIED.
Ko teaches determining, by the STA with the nonzero MediumSyncDelay timer, whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving a PPDU with a valid media access control protocol data unit (MPDU); wherein determining, by the STA with the nonzero MediumSyncDelay timer, whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving the PPDU with the valid MPDU, comprises: resetting the MediumSyncDelay timer to zero when the STA receives the PPDU with the valid MPDU ([0326] “when the STA of a link to which MediumSyncDelay is applied receives a valid frame or a PPDU for a valid MPDU and the MediumSyncDelay timer is not “0”, the STA may reset the MediumSyncDelay timer to “0””), and/or the STA receives a PPDU whose corresponding RXVECTOR parameter TXOPDURATION is not UNSPECIFIED
It would have been obvious before the effective filing date of the claimed invention for a person having ordinary skill in the art to include the feature determining, by the STA with the nonzero MediumSyncDelay timer, whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving a PPDU with a valid media access control protocol data unit (MPDU); wherein determining, by the STA with the nonzero MediumSyncDelay timer, whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving the PPDU with the valid MPDU, comprises: resetting the MediumSyncDelay timer to zero when the STA receives the PPDU with the valid MPDU, and/or the STA receives a PPDU whose corresponding RXVECTOR parameter TXOPDURATION is not UNSPECIFIED, as taught by Ko in IEEE 802.11be for efficiently using multiple links.
Regarding claim 2, IEEE 802.11be teaches a wireless station (STA) (FIG. 1 STAs 121c, 122c, 123c, 124c), affiliated with a non-simultaneous transmit and receive (NSTR) soft access point multi-link device (AP MLD) in a nonprimary link ([0005] “IEEE 802.11be draft 1.1 has specified a medium access recovery procedure to address the blindness issue at a non-AP multi-link device (MLD) with a non-simultaneous transmit and receive (NSTR) pair”) and comprising:
a processor, configured to call and run a computer program stored in a memory (FIG. 1, STAs 121c, 122c, 123c, 124c inherently include a processor running programs stored in memory), to cause the STA to perform:
setting a MediumSyncDelay timer to nonzero by starting the MediumSyncDelay timer at an end of a transmission by another STA affiliated with the same MLD when that transmission event is longer than a MediumSyncThreshold; wherein the STA has lost medium synchronization due to the transmission ([0006] “A STA that has lost medium synchronization due to transmission by another STA affiliated with the same MLD shall start a MediumSyncDelay timer at the end of that transmission event if that transmission event is longer than aMediumSyncThreshold… 3) A non-AP STA is affiliated with non-AP MLD, has a nonzero MediumSyncDelay timer.” FIG. 1 shows STAs 121c, 122c, 123c, 124c are associated with AP MLD 110c);
wherein the processor is configured to call and run the computer program, to cause the STA with a nonzero MediumSyncDelay timer further to perform:
transmitting a request to send (RTS) frame as an initial frame of an obtained transmission opportunity (TXOP) ([0006] “3) A non-AP STA is affiliated with non-AP MLD, has a nonzero MediumSyncDelay timer, and supports to obtain a TXOP, and the non-AP STA shall: transmit an RTS frame as the first frame of any attempt to obtain a TXOP”) {to its associated non-AP STA in the nonprimary link only when another STA affiliated with the same soft AP MLD in a primary link is also initiating another physical protocol data unit (PPDU) as a TXOP holder or another STA affiliated with the same soft AP MLD in the primary link is also transmitting another PPDU at the same time, when capable of obtaining the TXOP};
{and determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving a PPDU with a valid media access control protocol data unit (MPDU);
wherein determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving the PPDU with the valid MPDU, comprises: resetting the MediumSyncDelay timer to zero when the STA receives the PPDU with the valid MAC MPDU, and/or the STA receives a PPDU whose corresponding RXVECTOR parameter TXOPDURATION is not UNSPECIFIED}.
IEEE 802.11be does not teach transmitting… a request to send (RTS) to its associated non-AP STA in the nonprimary link only when another STA affiliated with the same soft AP MLD in a primary link is also initiating another physical protocol data unit (PPDU) as a TXOP holder or another STA affiliated with the same soft AP MLD in the primary link is also transmitting another PPDU at the same time, when capable of obtaining the TXOP.
However, the Examiner submits transmissions an RTS to an associated non AP STA for a TXOP is well known in the art. For example, Seok teaches transmitting… a request to send (RTS) to its associated non-AP STA in the nonprimary link only when another STA affiliated with the same soft AP MLD in a primary link is also initiating another physical protocol data unit (PPDU) as a TXOP holder or another STA affiliated with the same soft AP MLD in the primary link is also transmitting another PPDU at the same time, when capable of obtaining the TXOP ([0058] “When an STA within the constrained MLD that obtains the TXOP sends a frame to a peer STA within another MLD, the wireless STA initiates an RTS/MU-RTS and CTS frame exchange sequence with the peer STA MLD1 transmits RTS frame 605, and the constrained MLD C-MLD3 responds with CTS frame 615… Link 2 of the constrained MLD C-MLD2 is busy while C-MLD2 is transmitting A-MPDU 615. ” Also note: FIG. 6 shows STA in MLD1 transmits RTS frame 605 on link L2, while STA in C-MLD2 transmits A-MPDU on link L1)
It would have been obvious before the effective filing date of the claimed invention for a person having ordinary skill in the art to include the feature transmitting… a request to send (RTS) to its associated non AP STA in the nonprimary link only when another STA affiliated with the same soft AP MLD in a primary link is also initiating another physical protocol data unit (PPDU) as a TXOP holder or another STA affiliated with the same soft AP MLD in the primary link is also transmitting another PPDU at the same time, when capable of obtaining the TXOP, as taught by Seok in IEEE 802.11be to perform constrained multi-link operations that increases throughput of the wireless network while advantageously preventing or mitigating the IDC interference.
Further the combination does not teach
determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving a PPDU with a valid media access control protocol data unit (MPDU); wherein determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving the PPDU with the valid MPDU, comprises: resetting the MediumSyncDelay timer to zero when the STA receives the PPDU with the valid MAC MPDU, and/or the STA receives a PPDU whose corresponding RXVECTOR parameter TXOPDURATION is not UNSPECIFIED.
Ko teaches determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving a PPDU with a valid media access control protocol data unit (MPDU); wherein determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving the PPDU with the valid MPDU, comprises: resetting the MediumSyncDelay timer to zero when the STA receives the PPDU with the valid MAC MPDU ([0326] “when the STA of a link to which MediumSyncDelay is applied receives a valid frame or a PPDU for a valid MPDU and the MediumSyncDelay timer is not “0”, the STA may reset the MediumSyncDelay timer to “0””), and/or the STA receives a PPDU whose corresponding RXVECTOR parameter TXOPDURATION is not UNSPECIFIED.
It would have been obvious before the effective filing date of the claimed invention for a person having ordinary skill in the art to include the feature determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving a PPDU with a valid media access control protocol data unit (MPDU); wherein determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU, when receiving the PPDU with the valid MPDU, comprises: resetting the MediumSyncDelay timer to zero when the STA receives the PPDU with the valid MAC MPDU, and/or the STA receives a PPDU whose corresponding RXVECTOR parameter TXOPDURATION is not UNSPECIFIED, as taught by Ko in IEEE 802.11be for efficiently using multiple links.
Regarding claim 3, IEEE 802.11be in view of Seok and Ko teaches claim 2 but does not teach determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU during a given time interval.
Ko teaches determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU during a given time interval ([0326] “when the STA of a link to which MediumSyncDelay is applied receives a valid frame or a PPDU for a valid MPDU and the MediumSyncDelay timer is not “0”, the STA may reset the MediumSyncDelay timer to “0””).
It would have been obvious before the effective filing date of the claimed invention for a person having ordinary skill in the art to include the feature determining, by the STA with the nonzero MediumSyncDelay timer, whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU during a given time interval, as taught by Ko in IEEE 802.11be for efficiently using multiple links.
Regarding claim 21, IEEE 802.11be in view of Seok and Ko teaches claim 1 but does not teach determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU during a given time interval.
Ko teaches determining whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU during a given time interval ([0326] “when the STA of a link to which MediumSyncDelay is applied receives a valid frame or a PPDU for a valid MPDU and the MediumSyncDelay timer is not “0”, the STA may reset the MediumSyncDelay timer to “0””).
It would have been obvious before the effective filing date of the claimed invention for a person having ordinary skill in the art to include the feature determining, by the STA with the nonzero MediumSyncDelay timer, whether to reset the MediumSyncDelay timer to zero according to detecting of the PPDU during a given time interval, as taught by Ko in IEEE 802.11be for efficiently using multiple links.
Claims 4 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over IEEE 802.11be in view of Seok, further in view of Ko and further in view of Lu et al. (US 2022/0338253, “Lu”).
Regarding claim 4, IEEE 802.11be in view of Seok teaches claim 2 but fails to teach
not resetting the MediumSyncDelay timer to zero when no PHY-RXSTART.indication primitive is received from a physical layer (PHY) of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a media access control (MAC) layer of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame; and/or
resetting the MediumSyncDelay timer to zero when a PHY-RXSTART.indication primitive is received from a PHY of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a MAC of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame;
wherein in non-directional multi-gigabit basic service set (non-DMG BSS), the NAVTimeout period is equal to (2 x aSIFSTime) + (CTS_Time) + aRxPHYStartDelay +(2x aSlotTime).
However, Ko discloses “when the STA of a link to which MediumSyncDelay is applied receives a valid frame or a PPDU for a valid MPDU and the MediumSyncDelay timer is not “0”, the STA may reset the MediumSyncDelay timer to “0”” (Ko, [0326]). The Examiner submits it is well known in the art that receiving “a valid frame or a PPDU for a valid MPDU” involves the claimed steps. For example, Lu discloses “A transmission failure of an MPDU transmitted during a multi-link operation may occur after transmitting an MPDU that requires an immediate response. In this case, the STA waits for a timeout interval of duration aSIFSTime+aSlotTime+aRxPHYStartDelay, the timeout interval starting when the MAC receives a primitive from the PHY layer (e.g., a “PHY-TXEND.confirm” primitive). If a “PHY-RXSTART.indication” primitive is not received during the timeout interval, the transmission of the 1VIPDU is considered a failure. If a “PHY-RXSTART.indication” primitive is received during the timeout interval, the STA waits for the corresponding “PHY-RXEND.indication” primitive to recognize a valid PPDU. If another frame is received (e.g., any other valid frame), the transmission of the 1VIPDU is considered a failure.”(Lu, [0056]). Therefore, the Examiner submits Ko’s [0326] teaches and Lu’s [0056] teach not resetting the MediumSyncDelay timer to zero when no PHY-RXSTART.indication primitive is received from a physical layer (PHY) of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a media access control (MAC) layer of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame; and/or
resetting the MediumSyncDelay timer to zero when a PHY-RXSTART.indication primitive is received from a PHY of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a MAC of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame;
wherein in non-directional multi-gigabit basic service set (non-DMGBSS), theNAVTimeoutperiod is equal to (2 x aSIFSTime) + (CTS_Time) + aRxPHlYStartDelay + (2 x aSlotTime).
(Note: the limitation wherein in non-directional multi-gigabit basic service set (non-DMGBSS), theNAVTimeoutperiod is equal to (2xaSFlSTime)+(CTSTime)+aRxPHYStartDelay+(2xaSlotTime), does not positively require the system to be a non-DMGBSS, therefore, the limitation theNAVTimeoutperiod is equal to (2xaSFlSTime)+(CTSTime)+aRxPHYStartDelay+(2xaSlotTime) is considered optional. MPEP 2103, section C states “Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation.”)
It would have been obvious before the filing date of the claimed invention for a person having ordinary skill in the art to include the feature not resetting the MediumSyncDelay timer to zero when no PHY-RXSTART.indication primitive is received from a physical layer (PHY) of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a media access control (MAC) layer of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame; and/or
resetting the MediumSyncDelay timer to zero when a PHY-RXSTART.indication primitive is received from a PHY of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a MAC of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame;
wherein in non-directional multi-gigabit basic service set (non-DMG BSS), the NAVTimeout period is equal to (2 x aSIFSTime) + (CTS_Time) + aRxPHYStartDelay +(2x aSlotTime).
as taught by Ko and Lu in IEEE 802.11be to avoid interference and improve performance of the wireless network.
Regarding claim 22, IEEE 802.11be in view of Seok teaches claim 1 but fails to teach
not resetting the MediumSyncDelay timer to zero when no PHY-RXSTART.indication primitive is received from a physical layer (PHY) of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a media access control (MAC) layer of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame; and/or
resetting the MediumSyncDelay timer to zero when a PHY-RXSTART.indication primitive is received from a PHY of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a MAC of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame;
wherein in non-directional multi-gigabit basic service set (non-DMG BSS), the NAVTimeout period is equal to (2 x aSIFSTime) + (CTS_Time) + aRxPHYStartDelay +(2x aSlotTime).
However, Ko discloses “when the STA of a link to which MediumSyncDelay is applied receives a valid frame or a PPDU for a valid MPDU and the MediumSyncDelay timer is not “0”, the STA may reset the MediumSyncDelay timer to “0”” (Ko, [0326]). The Examiner submits it is well known in the art that receiving “a valid frame or a PPDU for a valid MPDU” involves the claimed steps. For example, Lu discloses “A transmission failure of an MPDU transmitted during a multi-link operation may occur after transmitting an MPDU that requires an immediate response. In this case, the STA waits for a timeout interval of duration aSIFSTime+aSlotTime+aRxPHYStartDelay, the timeout interval starting when the MAC receives a primitive from the PHY layer (e.g., a “PHY-TXEND.confirm” primitive). If a “PHY-RXSTART.indication” primitive is not received during the timeout interval, the transmission of the 1VIPDU is considered a failure. If a “PHY-RXSTART.indication” primitive is received during the timeout interval, the STA waits for the corresponding “PHY-RXEND.indication” primitive to recognize a valid PPDU. If another frame is received (e.g., any other valid frame), the transmission of the 1VIPDU is considered a failure.”(Lu, [0056]). Therefore, the Examiner submits Ko’s [0326] teaches and Lu’s [0056] teach not resetting the MediumSyncDelay timer to zero when no PHY-RXSTART.indication primitive is received from a physical layer (PHY) of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a media access control (MAC) layer of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame; and/or
resetting the MediumSyncDelay timer to zero when a PHY-RXSTART.indication primitive is received from a PHY of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a MAC of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame;
wherein in non-directional multi-gigabit basic service set (non-DMGBSS), theNAVTimeoutperiod is equal to (2 x aSIFSTime) + (CTS_Time) + aRxPHlYStartDelay + (2 x aSlotTime).
(Note: the limitation wherein in non-directional multi-gigabit basic service set (non-DMGBSS), theNAVTimeoutperiod is equal to (2xaSFlSTime)+(CTSTime)+aRxPHYStartDelay+(2xaSlotTime), does not positively require the system to be a non-DMGBSS, therefore, the limitation theNAVTimeoutperiod is equal to (2xaSFlSTime)+(CTSTime)+aRxPHYStartDelay+(2xaSlotTime) is considered optional. MPEP 2103, section C states “Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation.”)
It would have been obvious before the filing date of the claimed invention for a person having ordinary skill in the art to include the feature not resetting the MediumSyncDelay timer to zero when no PHY-RXSTART.indication primitive is received from a physical layer (PHY) of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a media access control (MAC) layer of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame; and/or
resetting the MediumSyncDelay timer to zero when a PHY-RXSTART.indication primitive is received from a PHY of the STA during a NAVTimeout period, wherein the NAVTimeout period starts when a MAC of the STA receives a PHY-RXEND.indication primitive corresponding to detection of the RTS frame;
wherein in non-directional multi-gigabit basic service set (non-DMG BSS), the NAVTimeout period is equal to (2 x aSIFSTime) + (CTS_Time) + aRxPHYStartDelay +(2x aSlotTime).
as taught by Ko and Lu in IEEE 802.11be to avoid interference and improve performance of the wireless network.
Allowable Subject Matter
Claims 6 and 23 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 24 is allowed.
Response to Amendment
Applicant's request for reconsideration of the finality of the rejection of the last Office action is persuasive and, therefore, the finality of that action is withdrawn.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUOC THAI NGOC VU whose telephone number is (571)270-5901. The examiner can normally be reached M-F, 9:30AM-6:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rafael Perez-Gutierrez can be reached at 571-272-7915. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/QUOC THAI N VU/ Primary Examiner, Art Unit 2642
Prosecution Insights