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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/23/2024 and 12/26/2024 was filed in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 25 and 32 are objected to because of the following informality:
Claims 25 and 32 recite “wherein the predesignated value is a which is not used for a value of FORMAT of TXVECTOR”. What follows article “a” and precedes “which” is missing. “wherein the predesignated value is a which is not used for a value of FORMAT of TXVECTOR” should read “wherein the predesignated value is a value which is not used for a value of FORMAT of TXVECTOR”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claims 19-23, 25-30 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US20210367886A1, hereinafter Chen) in view of IEEE P802.11be D2.0 (IEEE P802.11be D2.0 Amendment 8: Enhancements for extremely high throughput (EHT), hereinafter P802.11) and Chu et al. (US20190222680A1, hereinafter Chu).
For claim 19, Chen teaches a station for performing wireless communication ([Para. 0056] and [FIG. 4] the wireless communication device 400 can be an example of a device for use in a STA such as one of the STAs 104 described with reference to FIG. 1), the station comprising: a transceiver ([Para. 0057], the wireless communication device 400 includes radios 404. [Para. 0060], The radio 404 generally includes radio frequency (RF) transmitter and RF receiver); and a processor ([Para. 0057], the wireless communication device [400] includes processors), wherein the processor is configured to ([Para. 0010], the subject matter can be implemented in a wireless communication device. Execution of the processor-readable code by the processor causes the wireless communication device to perform operations): receive, using the transceiver, a physical layer protocol data unit (PPDU) ([Para. 0050], STAs receive wireless communications from APs in the form of physical layer convergence protocol (PLCP) protocol data units (PPDUs)); when the PPDU satisfies a predesignated condition, acquire a value of a PHY version identifier field indicating a format of the PPDU from a signaling field of the PPDU ([Para. 0090], FIG. 9A shows an example PHY preamble 900 for a non-legacy PPDU. [Para. 0091], The receiving device may further detect the presence of U-SIG 905 in the PHY preamble 900 based on a combination of L-SIG 903 and RL-SIG 904. The receiving device may determine, based on the presence of RL-SIG 904, that the PPDU conforms with the IEEE 802.11ax amendment, or later generation, of the IEEE 802.11 standard. The receiving device may further determine, based on a length field (L_LEN) of L-SIG 903, that the PPDU also conforms with the IEEE 802.11be amendment to the IEEE 802.11 standard (where L_LEN %3==0) [Examiner’s Note: Presence of RL-SIG and L_LEN %3==0 constitute satisfying a predesignated condition that indicates the presence of U-SIG in PPDU]. [Para. 0009], the determining of the format of the packet may include determining that the packet conforms with a non-legacy extended range (ER) packet format based on a value of a version identifier subfield of U-SIG [Examiner’s Note: U-SIG is the signaling field of the PPDU. The PHY version identifier in U-SIG indicates the format of the PPDU]. [Para. 0107], a PHY version identifier in U-SIG 1105 may further differentiate the ER PPDU 1100 from other non-legacy PPDU formats. The PHY version identifier may indicate a version of the wireless communication protocols associated with the PPDU 1100. The version identifier may be provided as a subfield of the version-independent fields 632 of U-SIG 616. [Para. 0066], a non-legacy or Extremely High Throughput (EHT) WLAN preamble in accordance with the IEEE 802.11be amendment to the IEEE 802.11 [Examiner’s Note: The version of non-legacy is EHT. Determining the PPDU format based on the value of the PHY version identifier indicates acquiring the value indicating the PPDU format from U-SIG based on the presence of U-SIG]).
Although teaching acquiring the version indicating PPDU format based on satisfying the condition for presence of U-SIG, Chen does not explicitly disclose and when the acquired value of the PHY version identifier field indicates a format of the PPDU, which is not supported by the station, and is valid, configure a predesignated value to be a value of FORMAT of RXVECTOR transferred to a medium access control (MAC) layer of the station.
P802.11teaches and when the acquired value of the PHY version identifier field indicates a format of the PPDU, which is not supported by the station, and is valid, configure a predesignated value to be a value of FORMAT of RXVECTOR transferred to a medium access control (MAC) layer of the station ([Page 166, 9.3 Format of individual frame types, lines 18-19], The PHY Version Identifier subfield is set to 0 for EHT. Other values from 1 to 7 are reserved. [Page 547, 36.1.4 PPDU formats, lines 3-29], The structure of the PPDU transmitted by an EHT STA. The FORMAT parameter determines the overall structure of the PPDU and can take on one of the following : EHT MU PPDU format and EHT TB PPDU format [Examiner’s Note: That the list of the supported formats at an EHT device does not include a format after EHT and version 0 is for EHT indicates that a version between 1 and 7 corresponds to a PPDU format that is unsupported at an EHT device and is valid as its version number is a reserved value. Chen also teaches “a PHY version identifier in U-SIG may further differentiate the ER PPDU from other non-legacy PPDU formats” ([Para. 0107])]. [Page 642, 36.3.12.7 U-SIG, lines 24-25], The value of PHY Version Identifier field is used to identify the exact PHY version starting with EHT. [Page 642, 36.3.12.7 U-SIG, lines 27-37], For forward compatibility. An EHT STA shall be able to decode and interpret the version independent content in the U-SIG field of the preamble introduced (Extremely high throughput (EHT) PHY) onwards. Regardless of the value of the PHY Version Identifier field in U-SIG field, an EHT STA shall defer for the duration of the PPDU as defined in 36.3.22 (EHT receive procedure). [Page 778, 36.3.22 EHT receive procedure lines 42-58], If U-SIG field is present, PHY entity shall begin receiving the U-SIG field and identify the PPDU version based on the PHY Version Identifier field. If the U-SIG field indicates a valid CRC, and the PHY version identifier does not contain an intended value, the PHY entity shall issue a PHY-RXSTART.indication(RXVECTOR) [Examiner’s Note: The unintended value in the PHY version identifier indicates that the EHT device acquires a version after EHT and therefore indicating a PPDU format valid but unsupported at the EHT device]. [Page 547, 36.2 EHT PHY service interface, lines 42-43], The PHY uses the RXVECTOR to inform the MAC of the received PPDU parameters. [Page 547-548, 36.2.2 RXVECTOR parameters, lines 52-53 and lines 1-2], The parameters in Table 36-1 (RXVECTOR parameters) are defined as part of the RXVECTOR parameter list in the PHY-RXSTART.indication and PHY-RXEND.indication primitives for PPDU receiving. [Page 548, Table 36-1 RXVECTOR parameters] : FORMAT - Determines the format of the PPDU, EHT_MU indicates EHT_MU PPDU format, EHT_TB indicates EHT TB PPDU format [Examiner’s Note: Based on the teaching of P802.11, acquiring the unintended version after EHT and regardless the acquired version, the PHY issues PHY-RXSTART.indication(RXVECTOR) to the MAC. RXVECTOR includes FORMAT. The value of the FORMAT of RXVECTOR is one of the FORMAT values listed in Table 36-1 and is the predesignated value. It is reasonable that, receiving PPDU of a version than EHT, the EHT device uses the legacy format such as EHT_MU/TB as the predesignated value for FORMAT of RXVECTOR issued to the MAC]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen, so that when the PHY version identifier indicates a version after EHT, the predesignated value of EHT_MU/TB is transferred in the FORMAT of RXVECTOR to MAC, as taught by P802.11. The modification would have modified IEEE Std 802.11 physical layers (PHY) and the Medium Access Control Layer (MAC) to enable at least one mode of operation capable of supporting a maximum throughput of at least 30 Gbps (P802.11 [Page 1, Abstract]).
Although teaching setting a listed value to FORMAT of RXVECTOR when a version after EHT is received, P802.11 does not explicitly disclose and when the acquired value of the PHY version identifier field indicates a format of the PPDU, which is not supported by the station, and is valid, configure a predesignated value to be a value of FORMAT of RXVECTOR transferred to a medium access control (MAC) layer of the station.
Chu is directed to providing methods and apparatus for generation of physical layer protocol data units. More specifically, Chu teaches and when the acquired value of the PHY version identifier field indicates a format of the PPDU, which is not supported by the station, and is valid, configure a predesignated value to be a value of FORMAT of RXVECTOR transferred to a medium access control (MAC) layer of the station ([Para. 0054], The responding communication device determines the PPDU format for the PPDU, when transmitted to a non-legacy communication device. The PPDU format for the PPDU is a default format (a legacy format) unless a different format (e.g., non-legacy) PPDU has been received [Examiner’s Note: Chu teaches that a device uses the legacy format for PPDU when the device has no knowledge of what format to use. It is obvious that in combination, P802.11 and Chu teach using the legacy format EHT_MU/TB as the predesignated value for FORMAT of RXVECTOR at an EHT device in the case that the received PPDU is in a version after EHT]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen, so that without knowledge of PPDU format, a device uses the legacy format for PPDU format, as taught by Chu. The modification would have allowed a device to determine a PPDU format without knowing the format of the PPDU for another device (Chu [Para. 0054]).
For claim 20, Chen, P802.11 and Chu teach the station of claim 19. The references further teach wherein the processor is configured to, when the acquired value of the PHY version identifier field indicates a format of the PPDU, which is supported by the station, configure the value of FORMAT of RXVECTOR to be a value corresponding to the format of the PPDU (P802.11 [Page 166, first para.], The PHY Version Identifier subfield is set to 0 for EHT. P802.11 [Page 547, 36.1.4 PPDU formats, lines 3-29], The structure of the PPDU transmitted by an EHT STA. The FORMAT parameter determines the overall structure of the PPDU and can take on one of the following : EHT MU PPDU format and EHT TB PPDU format [Examiner’s Note: EHT_MU/TB is the predesignated value for the format of EHT PPDU. It is listed as the supported format at an EHT device]. P802.11 [Page 547, 36.2 EHT PHY service interface, lines 42-43], The PHY uses the RXVECTOR to inform the MAC of the received PPDU parameters. [Page 547-548, 36.2.2 RXVECTOR parameters, lines 52-53 and lines 1-2], The parameters in Table 36-1 (RXVECTOR parameters) are defined as part of the RXVECTOR parameter list in the PHY-RXSTART.indication and PHY-RXEND.indication primitives for PPDU receiving. P802.11 [Page 548, Table 36-1 RXVECTOR parameters] : FORMAT - Determines the format of the PPDU, EHT_MU indicates EHT_MU PPDU format, EHT_TB indicates EHT TB PPDU format. P802.11 [Page 778, 36.3.22 EHT receive procedure lines 42-58], If U-SIG field is present, PHY entity shall begin receiving the U-SIG field and identify the PPDU version based on the PHY Version Identifier field. [Examiner’s Note: The PHY Version Identifier 0 indicates EHT. The PPDU format for EHT is supported at the EHT device as the format is defined as EHT_MU/TB]. P802.11 [Page 779, 36.3.22 EHT receive procedure, line 34], If the received PPDU is EHT MU PPDU, P802.11 [Page 780, 36.3.22 EHT receive procedure, line 7], If the received PPDU is EHT TB PPDU [Examiner’s Note: EHT Preamble parsing block in Figure 36-80-PHY receive state machine shows that determination of EHT MU/TB PPDU is based on the version in the PHY Version Identifier], P802.11 [Page 780, 36.3.22 EHT receive procedure, lines 33-40], If packet extension and/or signal extension is applied, the PHY entity shall wait until the packet extension and/or signal extension expires before issuing a PHY-RXEND indication (NoError, RXVECTOR) [Examiner’s Note: Figure 36-80-PHY receive state machine indicates in Data processing block that PHY-RXSTASRT indication (RXVECTOR) is issued to MAC before PHY-DATA.indication(DATA)]. P802.11 [Page 547-548, 36.2 EHT PHY service interface, lines 52-53 and 1-2], RXVECTOR parameters in Table 36-1 are defined as part of the RXVECTOR parameter list in the PHY-RXSTART.indication and PHY-RXEND.indication primitives for PPDU receiving [Examiner’s Note: Issuing PHY-RXSTART.indication(RXVECTOR) including EHT_MU/TB indicates configure the value of FORMAT of RXVECTOR for EHT. EHT_MU/TB is the predesignated value]), which is indicated by the acquired value of the PHY version identifier field (P802.11 [Page 166, 9.3 Format of individual frame types, lines 18-19], The PHY Version Identifier subfield is set to 0 for EHT. P802.11 [Page 547, 36.2 EHT PHY service interface, lines 42-43], The PHY uses the RXVECTOR to inform the MAC of the received PPDU parameters. P802.11 [Page 547-548, 36.2.2 RXVECTOR parameters, lines 52-53 and lines 1-2], The parameters in Table 36-1 (RXVECTOR parameters) are defined as part of the RXVECTOR parameter list in the PHY-RXSTART.indication and PHY-RXEND.indication primitives for PPDU receiving. P802.11 [Page 548, Table 36-1 RXVECTOR parameters] : FORMAT - Determines the format of the PPDU, EHT_MU indicates EHT_MU PPDU format, EHT_TB indicates EHT TB PPDU format. P802.11 [Page 778, 36.3.22 EHT receive procedure lines 42-58], If U-SIG field is present, PHY entity shall begin receiving the U-SIG field and identify the PPDU version based on the PHY Version Identifier field. P802.11 [Page 779, 36.3.22 EHT receive procedure, line 34], If the received PPDU is EHT MU PPDU, P802.11 [Page 780, 36.3.22 EHT receive procedure, line 7], If the received PPDU is EHT TB PPDU. P802.11 [Page 780, 36.3.22 EHT receive procedure, lines 33-40], If packet extension and/or signal extension is applied, the PHY entity shall wait until the packet extension and/or signal extension expires before issuing a PHY-RXEND indication (NoError, RXVECTOR)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen and Chu, so that when the PHY version identifier indicates a version for EHT, the predesignated value of EHT_MU/TB is transferred in the FORMAT of RXVECTOR to MAC, as taught by P802.11. The modification would have modified IEEE Std 802.11 physical layers (PHY) and the Medium Access Control Layer (MAC) to enable at least one mode of operation capable of supporting a maximum throughput of at least 30 Gbps (P802.11 [Page 1, Abstract]).
For claim 21, Chen, P802.11 and Chu teach the station of claim 19. The references further teach wherein the PPDU comprises a version independent field regardless of the value of the PHY version identifier field (P802.11 [Page 642, 36.3.12.7 U-SIG, lines 13-25], The U-SIG field is designed to bring forward compatibility to the EHT preamble via the introduction of version independent fields. The intent of the version independent content is to achieve better coexistence (Extremely high throughput (EHT) PHY specification) onwards. PHY Version Identifier field is one of the version independent fields in the U-SIG field. The value of this field is used to identify the exact PHY version starting with EHT. P802.11 [Page 642, 36.3.12.7 U-SIG, lines 27-37], For forward compatibility. An EHT STA shall be able to decode and interpret the version independent content in the U-SIG field of the preamble introduced EHT onwards. Regardless of the value of the PHY Version Identifier field in U-SIG field, an EHT STA shall defer for the duration of the PPDU), and wherein the processor is configured to, when the acquired value of the PHY version identifier field indicates the format of the PPDU, which is not supported by the station, and is valid, transfer information acquired from the version independent field to the MAC layer of the station (P802.11 [Page 166, 9.3 Format of individual frame types, lines 18-19], The PHY Version Identifier subfield is set to 0 for EHT. Other values from 1 to 7 are reserved. P802.11 [Page 547, 36.1.4 PPDU formats, lines 3-29], The structure of the PPDU transmitted by an EHT STA. The FORMAT parameter determines the overall structure of the PPDU and can take on one of the following : EHT MU PPDU format and EHT TB PPDU format [Examiner’s Note: That the list of the supported formats at an EHT device does not include a format after EHT and version 0 is for EHT indicates that a version between 1 and 7 corresponds to a PPDU format that is unsupported at an EHT device and is valid as its version number is a reserved value]. P802.11 [Page 642, 36.3.12.7 U-SIG, lines 24-25], The value of PHY Version Identifier field is used to identify the exact PHY version starting with EHT. P802.11 [Page 642, 36.3.12.7 U-SIG, lines 27-37], For forward compatibility. An EHT STA shall be able to decode and interpret the version independent content in the U-SIG field of the preamble introduced EHT onwards. Regardless of the value of the PHY Version Identifier field in U-SIG field, an EHT STA shall defer for the duration of the PPDU as defined in 36.3.22 (EHT receive procedure) and report the information from the version independent fields within the RXVECTOR. P802.11 [Page 778, 36.3.22 EHT receive procedure lines 42-58], If U-SIG field is present, PHY entity shall begin receiving the U-SIG field and identify the PPDU version based on the PHY Version Identifier field. If the U-SIG field indicates a valid CRC, the PHY entity shall report the version independent fields in the U-SIG field (e.g., TXOP, BSS color, and Bandwidth) to the MAC entity. If the U-SIG field indicates a valid CRC, and the PHY version identifier does not contain an intended value, the PHY entity shall issue a PHY-RXSTART.indication(RXVECTOR)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen and Chu, so that when the PHY version identifier indicates a version after EHT, information from the version independent field is transferred to the MAC, as taught by P802.11. The modification would have modified IEEE Std 802.11 physical layers (PHY) and the Medium Access Control Layer (MAC) to enable at least one mode of operation capable of supporting a maximum throughput of at least 30 Gbps (P802.11 [Page 1, Abstract]).
For claim 22, Chen, P802.11 and Chu teach the station of claim 21. The references further teach wherein: the processor is configured to, based on the information acquired from the version independent field, configure CH_BANDWIDTH, UPLINK_FLAG, BSS_COLOR, and TXOP_DURATION of RXVECTOR (P802.11 [Page, 642, 36.3.12.7 U-SIG, lines 30-37], An EHT STA shall be able to decode and interpret the version independent content in the U-SIG field of an ER preamble introduced from EHT onwards. Regardless of the value of the PHY Version Identifier field, an EHT STA shall report the information from the version independent fields within the RXVECTOR. P802.11 [Page 778, 36.3.22 EHT receive procedure lines 42-58], If U-SIG field is present. PHY entity shall begin receiving the U-SIG field and identify the PPDU version based on the PHY Version Identifier field in the U-SIG field. If the U-SIG field indicates a valid CRC, the PHY entity shall report the version independent fields in the U-SIG field (e.g., TXOP, BSS color, and Bandwidth) to the MAC entity. If the PHY version identifier does not contain an intended value, the PHY entity shall issue a PHY-RXSTART.indication(RXVECTOR) [Examiner’s Note: Reporting the version independent field is based on the value of the PHY version identifier. Reporting TXOP, BSS color, and Bandwidth to the MAC indicates configuring the parameters]. P802.11 [Page 643, 36.3.12.7 U-SIG, lines 13-15 and Table 36-28 U-SIG field of an EHT MU PPDU], The U-SIG field for an EHT MU PPDU contains the fields listed in Table 36-28 (U-SIG field of an EHT MU PPDU). The version independent bits are B0-B19 of U-SIG-1 field. The version independent bits are B0-B19 of U-SIG-1 field. [Examiner’s Note: Table 36-28 shows that the version independent field include Bandwidth, UL/DL, BSS Color and TXOP. That an EHT STA shall report the information from the version independent fields within the RXVECTOR indicates that CH_BANDWIDTH, UPLINK_FLAG, BSS_COLOR, and TXOP_DURATION as listed in the table are reported in RXVECTOR and thus configured]), the CH_BANDWIDTH indicates a bandwidth of the PPDU (Chen [Para. 0113], the version independent fields may include a PHY version identifier subfield, an uplink or downlink subfield, a transmit opportunity (TXOP) duration subfield, a BSS color subfield, and a PPDU bandwidth subfield. P802.11 [Page 643, Table 36-28 U-SIG field of an EHT MU PPDU, lines 28-36], Bandwidth of PPDU); the UPLINK_FLAG indicates whether the PPDU is an uplink PPDU (P802.11 [Page 643, Table 36-28 U-SIG field of an EHT MU PPDU, lines 39-46], PPDU set in uplink or downlink); the BSS_COLOR indicates a BSS color to which the PPDU corresponds (P802.11 [Page 643, Table 36-28 U-SIG field of an EHT MU PPDU, lines 48-50], BSS for PPDU); and the TXOP_DURATION indicates a duration of TXOP in which the PPDU has been exchanged ([Page 644, Table 36-28 U-SIG field of an EHT MU PPDU, lines 7-22], TXOP duration for PPDU).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen and Chu, so that when the PHY version identifier contains unsupported future version after EHT, information in the version independent field is reported to the MAC, as taught by P802.11. The modification would have modified IEEE Std 802.11 physical layers (PHY) and the Medium Access Control Layer (MAC) to enable at least one mode of operation capable of supporting a maximum throughput of at least 30 Gbps (P802.11 [Page 1, Abstract]).
For claim 23, Chen, P802.11 and Chu teach the station of claim 22. The references further teach wherein the processor is configured to, when the acquired value of the PHY version identifier field indicates the format of the PPDU, which is not supported by the station, and is valid, defer a channel access based on the PPDU (P802.11 [Page 166, 9.3 Format of individual frame types, lines 18-19], The PHY Version Identifier subfield is set to 0 for EHT. Other values from 1 to 7 are reserved. P802.11 [Page 547, 36.1.4 PPDU formats, lines 3-29], The structure of the PPDU transmitted by an EHT STA. The FORMAT parameter determines the overall structure of the PPDU and can take on one of the following : EHT MU PPDU format and EHT TB PPDU format [Examiner’s Note: That the list of the supported formats at an EHT device does not include a format after EHT and version 0 is for EHT indicates that a version between 1 and 7 corresponds to a PPDU format that is unsupported at an EHT device and is valid as its version number is a reserved value]. P802.11 [Page 642 , 36.3.12.7 U-SIG, lines 24-25], The value of PHY Version Identifier field is used to identify the exact PHY version starting with EHT. P802.11 [Page 642, 36.3.12.7 U-SIG, lines 27-37], For forward compatibility. An EHT STA shall be able to decode and interpret the version independent content in the U-SIG field of the preamble introduced (Extremely high throughput (EHT) PHY) onwards. Regardless of the value of the PHY Version Identifier field in U-SIG field, an EHT STA shall defer for the duration of the PPDU as defined in 36.3.22 (EHT receive procedure) [Examiner’s Note: STA defers channel access based on PPDU even if PPDU version is not supported], report the information from the version independent fields within the RXVECTOR. P802.11 [Page 778, 36.3.22 EHT receive procedure, lines 42-58], If U-SIG field is present, PHY entity shall begin receiving the U-SIG field and identify the PPDU version based on the PHY Version Identifier field. If the U-SIG field indicates a valid CRC, and the PHY version identifier does not contain an intended value, the PHY entity shall issue a PHY-RXSTART.indication(RXVECTOR)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen and Chu, so that when the STA defers channel access even if the PPDU version indicates unsupported format, as taught by P802.11. The modification would have modified IEEE Std 802.11 physical layers (PHY) and the Medium Access Control Layer (MAC) to enable at least one mode of operation capable of supporting a maximum throughput of at least 30 Gbps (P802.11 [Page 1, Abstract]).
For claim 25, Chen, P802.11 and Chu teach the station of claim 19. The references further teach wherein the predesignated value is a which is not used for a value of FORMAT of TXVECTOR (P802.11 [Page 550, Table 36-1, lines 19-25], SNR, not present in TXVECTOR, present in RXVECTOR. P802.11 [Page 551, Table 36-1, lines 31-37], RSSI not present in TXVECTOR, present in RXVECTOR. [Examiner’s Note: SNR and RSSI teach that a parameter is present in RXVECTOR so that the PHY provides the parameter value to the MAC but not present in TXVECTOR since the PHY can not use the parameter value for transmission. Based on teaching of P802.11, it is obvious that at an EHT device, a predesignated value added to the format list of RXVECTOR that corresponds to only a format after EHT should not be added to the format list of TXVECTOR since the PHY of the EHT device can not use a format after EHT for transmission]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen and Chu, so that a parameter value that can not be used by the PHY for transmission is not added to TXVECTOR, as taught by P802.11. The modification would have modified IEEE Std 802.11 physical layers (PHY) and the Medium Access Control Layer (MAC) to enable at least one mode of operation capable of supporting a maximum throughput of at least 30 Gbps (P802.11 [Page 1, Abstract]).
For claim 26, Chen teaches a method of operating a station for performing wireless communication ([Para. 0006], The subject matter can be implemented as a method of wireless communication. The method may be performed by a wireless communication device), the method comprising: receiving a physical layer protocol data unit (PPDU) ([Para. 0050], STAs receive wireless communications from APs in the form of physical layer convergence protocol (PLCP) protocol data units (PPDUs)); when the PPDU satisfies a predesignated condition, acquiring a value of a PHY version identifier field indicating a format of the PPDU from a signaling field of the PPDU ([Para. 0090], FIG. 9A shows an example PHY preamble 900 for a non-legacy PPDU. [Para. 0091], The receiving device may further detect the presence of U-SIG 905 in the PHY preamble 900 based on a combination of L-SIG 903 and RL-SIG 904. The receiving device may determine, based on the presence of RL-SIG 904, that the PPDU conforms with the IEEE 802.11ax amendment, or later generation, of the IEEE 802.11 standard. The receiving device may further determine, based on a length field (L_LEN) of L-SIG 903, that the PPDU also conforms with the IEEE 802.11be amendment to the IEEE 802.11 standard (where L_LEN %3==0) [Examiner’s Note: Presence of RL-SIG and L_LEN %3==0 constitute satisfying a predesignated condition that indicates the presence of U-SIG in PPDU]. [Para. 0009], the determining of the format of the packet may include determining that the packet conforms with a non-legacy extended range (ER) packet format based on a value of a version identifier subfield of U-SIG [Examiner’s Note: U-SIG is the signaling field of the PPDU. The PHY version identifier in U-SIG indicates the format of the PPDU]. [Para. 0107], a PHY version identifier in U-SIG 1105 may further differentiate the ER PPDU 1100 from other non-legacy PPDU formats. The PHY version identifier may indicate a version of the wireless communication protocols associated with the PPDU 1100. The version identifier may be provided as a subfield of the version-independent fields 632 of U-SIG 616. [Para. 0066], a non-legacy or Extremely High Throughput (EHT) WLAN preamble in accordance with the IEEE 802.11be amendment to the IEEE 802.11 [Examiner’s Note: The version of non-legacy is EHT. Determining the PPDU format based on the value of the PHY version identifier indicates acquiring the value indicating the PPDU format from U-SIG based on the presence of U-SIG]).
Although teaching acquiring the version indicating PPDU format based on satisfying the condition for presence of U-SIG, Chen does not explicitly disclose and when the acquired value of the PHY version identifier field indicates a format of the PPDU, which is not supported by the station, and is valid, configuring a predesignated value to be a value of FORMAT of RXVECTOR transferred to a medium access control (MAC) layer of the station.
P802.11teaches and when the acquired value of the PHY version identifier field indicates a format of the PPDU, which is not supported by the station, and is valid, configuring a predesignated value to be a value of FORMAT of RXVECTOR transferred to a medium access control (MAC) layer of the station ([Page 166, 9.3 Format of individual frame types, lines 18-19], The PHY Version Identifier subfield is set to 0 for EHT. Other values from 1 to 7 are reserved. [Page 547, 36.1.4 PPDU formats, lines 3-29], The structure of the PPDU transmitted by an EHT STA. The FORMAT parameter determines the overall structure of the PPDU and can take on one of the following : EHT MU PPDU format and EHT TB PPDU format [Examiner’s Note: That the list of the supported formats at an EHT device does not include a format after EHT and version 0 is for EHT indicates that a version between 1 and 7 corresponds to a PPDU format that is unsupported at an EHT device and is valid as its version number is a reserved value. Chen also teaches “a PHY version identifier in U-SIG may further differentiate the ER PPDU from other non-legacy PPDU formats” ([Para. 0107])]. [Page 642, 36.3.12.7 U-SIG, lines 24-25], The value of PHY Version Identifier field is used to identify the exact PHY version starting with EHT. [Page 642, 36.3.12.7 U-SIG, lines 27-37], For forward compatibility. An EHT STA shall be able to decode and interpret the version independent content in the U-SIG field of the preamble introduced (Extremely high throughput (EHT) PHY) onwards. Regardless of the value of the PHY Version Identifier field in U-SIG field, an EHT STA shall defer for the duration of the PPDU as defined in 36.3.22 (EHT receive procedure). [Page 778, 36.3.22 EHT receive procedure lines 42-58], If U-SIG field is present, PHY entity shall begin receiving the U-SIG field and identify the PPDU version based on the PHY Version Identifier field. If the U-SIG field indicates a valid CRC, and the PHY version identifier does not contain an intended value, the PHY entity shall issue a PHY-RXSTART.indication(RXVECTOR) [Examiner’s Note: The unintended value in the PHY version identifier indicates that the EHT device acquires a version after EHT and therefore indicating a PPDU format valid but unsupported at the EHT device]. [Page 547, 36.2 EHT PHY service interface, lines 42-43], The PHY uses the RXVECTOR to inform the MAC of the received PPDU parameters. [Page 547-548, 36.2.2 RXVECTOR parameters, lines 52-53 and lines 1-2], The parameters in Table 36-1 (RXVECTOR parameters) are defined as part of the RXVECTOR parameter list in the PHY-RXSTART.indication and PHY-RXEND.indication primitives for PPDU receiving. [Page 548, Table 36-1 RXVECTOR parameters] : FORMAT - Determines the format of the PPDU, EHT_MU indicates EHT_MU PPDU format, EHT_TB indicates EHT TB PPDU format [Examiner’s Note: Based on the teaching of P802.11, acquiring the unintended version after EHT and regardless the acquired version, the PHY issues PHY-RXSTART.indication(RXVECTOR) to the MAC. RXVECTOR includes FORMAT. The value of the FORMAT of RXVECTOR is one of the FORMAT values listed in Table 36-1 and is the predesignated value. It is reasonable that, receiving PPDU of a version than EHT, the EHT device uses the legacy format such as EHT_MU/TB as the predesignated value for FORMAT of RXVECTOR issued to the MAC]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen, so that when the PHY version identifier indicates a version after EHT, the predesignated value of EHT_MU/TB is transferred in the FORMAT of RXVECTOR to MAC, as taught by P802.11. The modification would have modified IEEE Std 802.11 physical layers (PHY) and the Medium Access Control Layer (MAC) to enable at least one mode of operation capable of supporting a maximum throughput of at least 30 Gbps (P802.11 [Page 1, Abstract]).
Although teaching setting a listed value to FORMAT of RXVECTOR when a version after EHT is received, P802.11 does not explicitly disclose and when the acquired value of the PHY version identifier field indicates a format of the PPDU, which is not supported by the station, and is valid, configuring a predesignated value to be a value of FORMAT of RXVECTOR transferred to a medium access control (MAC) layer of the station.
Chu is directed to providing methods and apparatus for generation of physical layer protocol data units. More specifically, Chu teaches and when the acquired value of the PHY version identifier field indicates a format of the PPDU, which is not supported by the station, and is valid, configuring a predesignated value to be a value of FORMAT of RXVECTOR transferred to a medium access control (MAC) layer of the station ([Para. 0054], The responding communication device determines the PPDU format for the PPDU, when transmitted to a non-legacy communication device. The PPDU format for the PPDU is a default format (a legacy format) unless a different format (e.g., non-legacy) PPDU has been received [Examiner’s Note: Chu teaches that a device uses the legacy format for PPDU when the device has no knowledge of what format to use. It is obvious that in combination, P802.11 and Chu teach using the legacy format EHT_MU/TB as the predesignated value for FORMAT of RXVECTOR at an EHT device in the case that the received PPDU is in a version after EHT]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen and P802.11, so that without knowledge of PPDU format, a device uses the legacy format for PPDU format, as taught by Chu. The modification would have allowed a device to determine a PPDU format without knowing the format of the PPDU for another device (Chu [Para. 0054]).
Claims 27-30 and 32 are method claims and they do not teach or further define over the limitations recited in claims 20-23 and 25. Therefore, claims 27-30 and 32 are also rejected for similar reasons set forth in claims 20-23 and 25.
Claims 24 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US20210367886A1, hereinafter Chen) in view of IEEE P802.11be D2.0 (IEEE P802.11be D2.0 Amendment 8: Enhancements for extremely high throughput (EHT), hereinafter P802.11), Chu et al. (US20190222680A1, hereinafter Chu) and Kwon et al. (US20210143884A1, hereinafter Kwon).
For claim 24, Chen, P802.11 and Chu teach the station of claim 23. The references further teach wherein the processor is configured to, when the acquired value of the PHY version identifier field indicates the format of the PPDU, which is not supported by the station, and is valid, set a network allocation vector (NAV) based on the PPDU (P802.11 [Page 166, 9.3 Format of individual frame types, lines 18-19], The PHY Version Identifier subfield is set to 0 for EHT. Other values from 1 to 7 are reserved. P802.11 [547, 36.1.4 PPDU formats, lines 3-29], The structure of the PPDU transmitted by an EHT STA. The FORMAT parameter determines the overall structure of the PPDU and can take on one of the following: EHT MU PPDU format and EHT TB PPDU format. [Examiner’s Note: The list of the supported formats at an EHT device does not include a format after EHT]. P802.11 [Page 642, 36.3.12.7 U-SIG, lines 24-25], The value of PHY Version Identifier field is used to identify the exact PHY version starting with EHT. P802.11 [Page 642, 36.3.12.7 U-SIG, lines 27-37], For forward compatibility. An EHT STA shall be able to decode and interpret the version independent content in the U-SIG field of the preamble introduced EHT onwards. Regardless of the value of the PHY Version Identifier field, an EHT STA shall report the information from the version independent fields within the RXVECTOR. P802.11 [Page 778, 36.3.22 EHT receive procedure lines 42-58], If U-SIG field is present, PHY entity shall begin receiving the U-SIG field and identify the PPDU version based on the PHY Version Identifier field. If the U-SIG field indicates a valid CRC, the PHY entity shall report the version independent fields in the U-SIG field (e.g., TXOP) to the MAC entity. If the PHY version identifier does not contain an intended value, the PHY entity shall issue a PHY-RXSTART.indication(RXVECTOR). P802.11 [Page 547, 36.2 EHT PHY service interface, lines 42-43], The PHY uses the RXVECTOR to inform the MAC of the received PPDU parameters. The MAC uses the TXVECTOR to supply the PHY with per-PPDU transmit parameters. P802.11 [Page 644, Table 36-28-U-SIG field of an EHT MU PPDU, lines 11-22], For TXOP. If the TXVECTOR parameter TXOP_DURATION is an integer value, set to a value less than 127 to indicate duration information for NAV setting and protection of the TXOP).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen and Chu, so that when the NAV is set based on the TXOP and TXOP is issued to the MAC regardless the acquired version after EHT, as taught by P802.11. The modification would have modified IEEE Std 802.11 physical layers (PHY) and the Medium Access Control Layer (MAC) to enable at least one mode of operation capable of supporting a maximum throughput of at least 30 Gbps (P802.11 [Page 1, Abstract]).
Although teaching NAV setting, P802.11 does not explicitly disclose wherein the processor is configured to, when the acquired value of the PHY version identifier field indicates the format of the PPDU, which is not supported by the station, and is valid, set a network allocation vector (NAV) based on the PPDU.
Kwon is directed to providing apparatus and methods for multi-ap joint transmission and reception. More specifically, Kwon teaches wherein the processor is configured to, when the acquired value of the PHY version identifier field indicates the format of the PPDU, which is not supported by the station, and is valid, set a network allocation vector (NAV) based on the PPDU ([Para. 0061], a STA shall update the basic NAV with the duration information indicated by the RXVECTOR parameter TXOP_DURATION for an HE PPDU if [Para. 0065], the duration information indicated by the RXVECTOR parameter TXOP_DURATION is greater than the current basic NAV of the STA).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen, P802.11 and Chu, so that when the NAV is set based on the TXOP of the received PPDU, as taught by Kwon. The modification would have overcome blocking CSI report by the NAV rules (Kwon [Para. 0066]).
For claim 31, Chen, P802.11 and Chu teach the method of claim 29. The references further teach further comprising, when the acquired value of the PHY version identifier field indicates the format of the PPDU, which is not supported by the station, and is valid, setting a network allocation vector (NAV) based on the PPDU (P802.11 [Page 166, 9.3 Format of individual frame types, lines 18-19], The PHY Version Identifier subfield is set to 0 for EHT. Other values from 1 to 7 are reserved. P802.11 [547, 36.1.4 PPDU formats, lines 3-29], The structure of the PPDU transmitted by an EHT STA. The FORMAT parameter determines the overall structure of the PPDU and can take on one of the following : EHT MU PPDU format and EHT TB PPDU format. [Examiner’s Note: The list of the supported formats at an EHT device does not include a format after EHT]. P802.11 [Page 642, 36.3.12.7 U-SIG, lines 24-25], The value of PHY Version Identifier field is used to identify the exact PHY version starting with EHT. P802.11 [Page 642, 36.3.12.7 U-SIG, lines 27-37], For forward compatibility. An EHT STA shall be able to decode and interpret the version independent content in the U-SIG field of the preamble introduced EHT onwards. Regardless of the value of the PHY Version Identifier field, an EHT STA shall report the information from the version independent fields within the RXVECTOR. P802.11 [Page 778, 36.3.22 EHT receive procedure lines 42-58], If U-SIG field is present, PHY entity shall begin receiving the U-SIG field and identify the PPDU version based on the PHY Version Identifier field. If the U-SIG field indicates a valid CRC, the PHY entity shall report the version independent fields in the U-SIG field (e.g., TXOP) to the MAC entity. If the PHY version identifier does not contain an intended value, the PHY entity shall issue a PHY-RXSTART.indication(RXVECTOR). P802.11 [Page 547, 36.2 EHT PHY service interface, lines 42-43], The PHY uses the RXVECTOR to inform the MAC of the received PPDU parameters. The MAC uses the TXVECTOR to supply the PHY with per-PPDU transmit parameters. P802.11 [Page 644, Table 36-28-U-SIG field of an EHT MU PPDU, lines 11-22], For TXOP. If the TXVECTOR parameter TXOP_DURATION is an integer value, set to a value less than 127 to indicate duration information for NAV setting and protection of the TXOP).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen and Chu, so that when the NAV is set based on the TXOP and TXOP is issued to the MAC regardless the acquired version after EHT, as taught by P802.11. The modification would have modified IEEE Std 802.11 physical layers (PHY) and the Medium Access Control Layer (MAC) to enable at least one mode of operation capable of supporting a maximum throughput of at least 30 Gbps (P802.11 [Page 1, Abstract]).
Although teaching NAV setting, P802.11 does not explicitly disclose wherein the processor is configured to, when the acquired value of the PHY version identifier field indicates the format of the PPDU, which is not supported by the station, and is valid, setting a network allocation vector (NAV) based on the PPDU.
Kwon is directed to providing apparatus and methods for multi-ap joint transmission and reception. More specifically, Kwon teaches wherein the processor is configured to, when the acquired value of the PHY version identifier field indicates the format of the PPDU, which is not supported by the station, and is valid, setting a network allocation vector (NAV) based on the PPDU ([Para. 0061], a STA shall update the basic NAV with the duration information indicated by the RXVECTOR parameter TXOP_DURATION for an HE PPDU if [Para. 0065], the duration information indicated by the RXVECTOR parameter TXOP_DURATION is greater than the current basic NAV of the STA).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Chen, P802.11 and Chu, so that when the NAV is set based on the TXOP of the received PPDU, as taught by Kwon. The modification would have overcome blocking CSI report by the NAV rules (Kwon [Para. 0066]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHU LIU whose telephone number is (571)272-5186. The examiner can normally be reached Monday - Friday 9:00 am - 5:00 pm.
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, REBECCA E SONG can be reached at (571)270-3667. 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.
/S.L./Examiner, Art Unit 2417
/REBECCA E SONG/Supervisory Patent Examiner, Art Unit 2417
