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 .
This Office Action is in response to the RCE Applicant Arguments/REMARKS correspondence filed on 10/28/2025.
Claims 1, 17-23 are pending and rejected.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/28/2025 has been entered.
Response to Arguments
Applicant’s arguments with respect to claims 1, & 17-23 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 1, & 17-23 are rejected under 35 U.S.C. 103 as being unpatentable over Chu et al (WO2015081179) in view of Seok, IEEE 802.11-19/2125r2 EHT RTS and CTS Procedure (2020) (hereinafter "Seok"), in further view of Chun et al (US20170272138A1).
Regarding claim 1, Chu teaches a method performed in a wireless local area network (WLAN) system (Fig 1 10, [0024], WLAN), comprising:
receiving a control frame including a request to send (RTS) frame (Fig 5, 510, claim 23, [0049] method for receiving an enhanced RTS message, wherein the E-RTS message includes i.) the length of a transmission opportunity (TXOP) of a first communication device; and ii.) an indication of a data unit size for an uplink MU-MIMO data unit to be transmitted by the first communication device—RTS/CTS frames are transmitted within the TXOP before data transmission; RTS/CTS exchange occurs within the TXOP before actual data transmission—TXOP contains length of RTS/CTS frames),
and in response to the RTS frame, transmitting a the CTS frame, wherein the CTS frame includes information related to the length of the CTS frame ([0130] & claim 41; configured to transmit a clear to send (CTS) frame that indicates a length of a transmission opportunity (TXOP) of the access point—RTS /CTS frames are transmitted within the TXOP before data transmission; RTS/CTS exchange occurs within the TXOP before actual data transmission—TXOP contains length of RTS/CTS frames).
But Chu fails to teach wherein the RTS frame includes a first frame control field which contains control information related to the RTS frame and has a length of 2 octets (, a first duration field which is contiguous to the first frame control field and has a length of 2 octets, a first receiver address (RA) field which is contiguous to the first duration field and has a length of 6 octets, a first transmitter address (TA) field which is contiguous to the first RA field and has a length of 6 octets, a version field which is contiguous to the first TA field, and a frame check sequence (FCS) having a length of 4 octets, wherein the version field is information related to a length of the RTS frame, wherein based on the version field having a first value, the RTS frame further includes first control information which is contiguous to the version field, the first control information is configured based on a single control field which is related to a punctured channel, and the FCS is contiguous to the first control information, wherein based on the version field having a second value, the RTS frame further includes second control information which is contiguous to the version field, the second control information is configured based on two control fields, a first control field of the two control fields is related to the punctured channel, and the FCS is contiguous to the second control information;
However, Seok teaches wherein the RTS frame includes a first frame control field which contains control information related to the RTS frame and has a length of 2 octets (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/punctrue-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS), a first duration field which is contiguous to the first frame control field and has a length of 2 octets, a first receiver address (RA) field which is contiguous to the first duration field and has a length of 6 octets, a first transmitter address (TA) field which is contiguous to the first RA field and has a length of 6 octets, a version field which is contiguous to the first TA field, and a frame check sequence (FCS) having a length of 4 octets (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/punctrue-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS), wherein the version field is information related to a length of the RTS frame (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/puncture-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS), wherein based on the version field having a first value, the RTS frame further includes first control information which is contiguous to the version field, the first control information is configured based on a single control field which is related to a punctured channel, and the FCS is contiguous to the first control information, wherein based on the version field having a second value, the RTS frame further includes second control information which is contiguous to the version field, the second control information is configured based on two control fields, a first control field of the two control fields is related to the punctured channel, and the FCS is contiguous to the second control information (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/puncture-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS).
A POSITA would have found it obvious to incorporate the version field and conditional inclusion of additional control information from Seok into the E-RTS message of Chu because both references aim to enhance coordination of uplink and downlink access in high-efficiency wireless networks (through MU-MIMO scheduling and TXOP sharing). Seok provides a known mechanism—via the version field—for indicating frame format extensions and controlling the inclusion of new fields based on capability negotiation. Adding the version field and associated control information (puncturing info, group scheduling details, or modulation/coding info) would have allowed Chu’s E-RTS frame to efficiently signal enhanced capabilities, improving interoperability with both legacy and advanced designs. This modification to combine would’ve been driven by the need to enhance flexibility, compatibility, and signaling efficiency of RTS frames in evolving WLAN systems, particularly those supporting high-efficiency and backward compatible features.
But Seok fails to teach wherein the control information includes type information, a first value of the type information indicates the RTS, a second value of the type information indicates a clear to send (CTS) frame, and a third value of the type information indicates a trigger frame related to a multi-user (MU) communication.
However, Chun teaches wherein the control information includes type information ([0014]-[0015], [0017], state that the trigger frame is a MAC frame, an MAC header of the trigger frame includes a type field and a subtype field, and the type of the trigger frame includes a type field and a subtype field, and the type of the trigger frame is indicated by the type field and the subtype field—which defines the “type information” within control information), a first value of the type information indicates the RTS ([0012], [0014], [0065]-[0066], describes that the invention relates to a type of trigger frame for UL multi-user transmission, and later, Fig 36-40 illustrate different trigger types, Fig 36 also describes identify an UL data trigger frame type that includes an MU-RTS function, thereby mapping the “first value = RTS”), a second value of the type information indicates a clear to send (CTS) frame ([0028]-[0029], explain that when the trigger frame is a type for triggering control frame transmission, it includes control type information for distinguishing the control frame, and examples include ACK, CTS, BSR, and PS-Poll frames; thus the “second value” corresponds to “CTS”), and a third value of the type information indicates a trigger frame related to a multi-user (MU) communication ([0011]-[0018], Figs 31, 36-40, show trigger frames for MU transmission (“trigger frame including information for UL MU transmission,”, “uplink multi-user (MU) transmission”)—which define the MU trigger frame (third type).
A POSITA would have found it obvious to incorporate the version field and conditional inclusion of additional control information from Seok into the E-RTS message of Chu because both references aim to enhance coordination of uplink and downlink access in high-efficiency wireless networks (through MU-MIMO scheduling and TXOP sharing). Seok provides a known mechanism—via the version field—for indicating frame format extensions and controlling the inclusion of new fields based on capability negotiation. Furthermore, Chun discloses control information (MAC header) including type information fields, whose values indicates frame types such as RTS, CTS and MU trigger frames. Adding the version field, associated control information (puncturing info, group scheduling details, or modulation/coding info), and type information fields, whose values indicates frame types such as RTS, CTS, and MU trigger frames would have allowed Chu’s E-RTS frame to efficiently signal enhanced capabilities, improving interoperability with both legacy and advanced designs. This modification to combine would’ve been driven by the need to enhance flexibility, compatibility, and signaling efficiency of RTS frames in evolving WLAN systems, particularly those supporting high-efficiency and backward compatible features.
Regarding claim 17, Chu fails to teach the method wherein based on the version field having a third value, the RTS frame does not include additional information between the version field and the FCS.
However, Seok teaches the method wherein based on the version field having a third value, the RTS frame does not include additional information between the version field and the FCS (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/punctrue-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS).
A POSITA would have found it obvious to incorporate the version field and conditional inclusion of additional control information from Seok into the E-RTS message of Chu because both references aim to enhance coordination of uplink and downlink access in high-efficiency wireless networks (through MU-MIMO scheduling and TXOP sharing). Seok provides a known mechanism—via the version field—for indicating frame format extensions and controlling the inclusion of new fields based on capability negotiation. Furthermore, Chun discloses control information (MAC header) including type information fields, whose values indicates frame types such as RTS, CTS and MU trigger frames. Adding the version field, associated control information (puncturing info, group scheduling details, or modulation/coding info), and type information fields, whose values indicates frame types such as RTS, CTS, and MU trigger frames would have allowed Chu’s E-RTS frame to efficiently signal enhanced capabilities, improving interoperability with both legacy and advanced designs. This modification to combine would’ve been driven by the need to enhance flexibility, compatibility, and signaling efficiency of RTS frames in evolving WLAN systems, particularly those supporting high-efficiency and backward compatible features.
Regarding claim 18, Chu fails to teach the method wherein the third value is set to zero (0), the first value is set to one (1), and the second value is set to two (2).
However, Seok teaches the method wherein the third value is set to zero (0), the first value is set to one (1), and the second value is set to two (2) (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/punctrue-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS).
A POSITA would have found it obvious to incorporate the version field and conditional inclusion of additional control information from Seok into the E-RTS message of Chu because both references aim to enhance coordination of uplink and downlink access in high-efficiency wireless networks (through MU-MIMO scheduling and TXOP sharing). Seok provides a known mechanism—via the version field—for indicating frame format extensions and controlling the inclusion of new fields based on capability negotiation. Furthermore, Chun discloses control information (MAC header) including type information fields, whose values indicates frame types such as RTS, CTS and MU trigger frames. Adding the version field, associated control information (puncturing info, group scheduling details, or modulation/coding info), and type information fields, whose values indicates frame types such as RTS, CTS, and MU trigger frames would have allowed Chu’s E-RTS frame to efficiently signal enhanced capabilities, improving interoperability with both legacy and advanced designs. This modification to combine would’ve been driven by the need to enhance flexibility, compatibility, and signaling efficiency of RTS frames in evolving WLAN systems, particularly those supporting high-efficiency and backward compatible features.
Regarding claim 19, Chu fails to teach the method wherein the CTS frame includes a second frame control field which contains control information related to the CTS frame and has a length of 2 octets, a second duration field which is contiguous to the second frame control field and has a length of 2 octets, a second receiver address (RA) field which is contiguous to the second duration field and has a length of 6 octets, a second transmitter address (TA) field which is contiguous to the second RA field and has a length of 6 octets, a CTS version field which is contiguous to the second TA field.
However, Seok teaches the method wherein the CTS frame includes a second frame control field which contains control information related to the CTS frame and has a length of 2 octets, a second duration field which is contiguous to the second frame control field and has a length of 2 octets, a second receiver address (RA) field which is contiguous to the second duration field and has a length of 6 octets, a second transmitter address (TA) field which is contiguous to the second RA field and has a length of 6 octets, a CTS version field which is contiguous to the second TA field (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/punctrue-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS).
A POSITA would have found it obvious to incorporate the version field and conditional inclusion of additional control information from Seok into the E-RTS message of Chu because both references aim to enhance coordination of uplink and downlink access in high-efficiency wireless networks (through MU-MIMO scheduling and TXOP sharing). Seok provides a known mechanism—via the version field—for indicating frame format extensions and controlling the inclusion of new fields based on capability negotiation. Furthermore, Chun discloses control information (MAC header) including type information fields, whose values indicates frame types such as RTS, CTS and MU trigger frames. Adding the version field, associated control information (puncturing info, group scheduling details, or modulation/coding info), and type information fields, whose values indicates frame types such as RTS, CTS, and MU trigger frames would have allowed Chu’s E-RTS frame to efficiently signal enhanced capabilities, improving interoperability with both legacy and advanced designs. This modification to combine would’ve been driven by the need to enhance flexibility, compatibility, and signaling efficiency of RTS frames in evolving WLAN systems, particularly those supporting high-efficiency and backward compatible features.
Regarding claim 20, A station (STA) in a wireless local area network (WLAN) system (Fig 1, 10, 25, [0024], WLAN), comprising:
at least one processor (Fig 1 10 25 27 30, [0024] processor, WLAN);
and at least one computer memory operatively connected to the at least one processor and storing instructions that (Fig 1 10 25 27 30, [0024] processor, WLAN), based on being executed by the at least one processor, perform operations comprising:
receiving a control frame including a request to send (RTS) frame (Fig 5, 510, claim 23, [0049] method for receiving an enhanced RTS message, wherein the E-RTS message includes i.) the length of a transmission opportunity (TXOP) of a first communication device; and ii.) an indication of a data unit size for an uplink MU-MIMO data unit to be transmitted by the first communication device—RTS/CTS frames are transmitted within the TXOP before data transmission; RTS/CTS exchange occurs within the TXOP before actual data transmission—TXOP contains length of RTS/CTS frames),
and in response to the RTS frame, transmitting the CTS frame ([0130] & claim 41; configured to transmit a clear to send (CTS) frame that indicates a length of a transmission opportunity (TXOP) of the access point—RTS /CTS frames are transmitted within the TXOP before data transmission; RTS/CTS exchange occurs within the TXOP before actual data transmission—TXOP contains length of RTS/CTS frames), wherein the CTS frame includes information related to the length of the CTS frame.
But Chu fails to teach wherein the RTS frame includes a first frame control field which contains control information related to the RTS frame and has a length of 2 octets, a first duration field which is contiguous to the first frame control field and has a length of 2 octets, a first receiver address (RA) field which is contiguous to the first duration field and has a length of 6 octets, a first transmitter address (TA) field which is contiguous to the first RA field and has a length of 6 octets, a version field which is contiguous to the first TA field, and a frame check sequence (FCS) having a length of 4 octets, wherein the version field is information related to a length of the RTS frame, wherein based on the version field having a first value, the RTS frame further includes first control information which is contiguous to the version field, the first control information is configured based on a single control field which is related to a punctured channel, and the FCS is contiguous to the first control information, wherein based on the version field having a second value, the RTS frame further includes second control information which is contiguous to the version field, the second control information is configured based on two control fields, a first control field of the two control fields is related to the punctured channel, and the FCS is contiguous to the second control information;
However, Seok teaches wherein the RTS frame includes a first frame control field which contains control information related to the RTS frame and has a length of 2 octets (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/punctrue-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS), a first duration field which is contiguous to the first frame control field and has a length of 2 octets, a first receiver address (RA) field which is contiguous to the first duration field and has a length of 6 octets, a first transmitter address (TA) field which is contiguous to the first RA field and has a length of 6 octets, a version field which is contiguous to the first TA field, and a frame check sequence (FCS) having a length of 4 octets (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/punctrue-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS), wherein the version field is information related to a length of the RTS frame (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/puncture-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS), wherein based on the version field having a first value, the RTS frame further includes first control information which is contiguous to the version field, the first control information is configured based on a single control field which is related to a punctured channel, and the FCS is contiguous to the first control information, wherein based on the version field having a second value, the RTS frame further includes second control information which is contiguous to the version field, the second control information is configured based on two control fields, a first control field of the two control fields is related to the punctured channel, and the FCS is contiguous to the second control information (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/punctrue-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS).
A POSITA would have found it obvious to incorporate the version field and conditional inclusion of additional control information from Seok into the E-RTS message of Chu because both references aim to enhance coordination of uplink and downlink access in high-efficiency wireless networks (through MU-MIMO scheduling and TXOP sharing). Seok provides a known mechanism—via the version field—for indicating frame format extensions and controlling the inclusion of new fields based on capability negotiation. Adding the version field and associated control information (puncturing info, group scheduling details, or modulation/coding info) would have allowed Chu’s E-RTS frame to efficiently signal enhanced capabilities, improving interoperability with both legacy and advanced designs. This modification to combine would’ve been driven by the need to enhance flexibility, compatibility, and signaling efficiency of RTS frames in evolving WLAN systems, particularly those supporting high-efficiency and backward compatible features.
But Seok fails to teach wherein the control information includes type information, a first value of the type information indicates the RTS, a second value of the type information indicates a clear to send (CTS) frame, and a third value of the type information indicates a trigger frame related to a multi-user (MU) communication.
However, Chun teaches wherein the control information includes type information ([0014]-[0015], [0017], state that the trigger frame is a MAC frame, an MAC header of the trigger frame includes a type field and a subtype field, and the type of the trigger frame includes a type field and a subtype field, and the type of the trigger frame is indicated by the type field and the subtype field—which defines the “type information” within control information), a first value of the type information indicates the RTS ([0012], [0014], [0065]-[0066], describes that the invention relates to a type of trigger frame for UL multi-user transmission, and later, Fig 36-40 illustrate different trigger types, Fig 36 also describes identify an UL data trigger frame type that includes an MU-RTS function, thereby mapping the “first value = RTS”), a second value of the type information indicates a clear to send (CTS) frame ([0028]-[0029], explain that when the trigger frame is a type for triggering control frame transmission, it includes control type information for distinguishing the control frame, and examples include ACK, CTS, BSR, and PS-Poll frames; thus the “second value” corresponds to “CTS”), and a third value of the type information indicates a trigger frame related to a multi-user (MU) communication ([0011]-[0018], Figs 31, 36-40, show trigger frames for MU transmission (“trigger frame including information for UL MU transmission,”, “uplink multi-user (MU) transmission”)—which define the MU trigger frame (third type).
A POSITA would have found it obvious to incorporate the version field and conditional inclusion of additional control information from Seok into the E-RTS message of Chu because both references aim to enhance coordination of uplink and downlink access in high-efficiency wireless networks (through MU-MIMO scheduling and TXOP sharing). Seok provides a known mechanism—via the version field—for indicating frame format extensions and controlling the inclusion of new fields based on capability negotiation. Furthermore, Chun discloses control information (MAC header) including type information fields, whose values indicates frame types such as RTS, CTS and MU trigger frames. Adding the version field, associated control information (puncturing info, group scheduling details, or modulation/coding info), and type information fields, whose values indicates frame types such as RTS, CTS, and MU trigger frames would have allowed Chu’s E-RTS frame to efficiently signal enhanced capabilities, improving interoperability with both legacy and advanced designs. This modification to combine would’ve been driven by the need to enhance flexibility, compatibility, and signaling efficiency of RTS frames in evolving WLAN systems, particularly those supporting high-efficiency and backward compatible features.
Regarding claim 21, Chu fails to teach the STA wherein based on the version field having a third value, the RTS frame does not include additional information between the version field and the FCS.
However, Seok teaches the STA wherein based on the version field having a third value, the RTS frame does not include additional information between the version field and the FCS (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/puncture-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS).
A POSITA would have found it obvious to incorporate the version field and conditional inclusion of additional control information from Seok into the E-RTS message of Chu because both references aim to enhance coordination of uplink and downlink access in high-efficiency wireless networks (through MU-MIMO scheduling and TXOP sharing). Seok provides a known mechanism—via the version field—for indicating frame format extensions and controlling the inclusion of new fields based on capability negotiation. Furthermore, Chun discloses control information (MAC header) including type information fields, whose values indicates frame types such as RTS, CTS and MU trigger frames. Adding the version field, associated control information (puncturing info, group scheduling details, or modulation/coding info), and type information fields, whose values indicates frame types such as RTS, CTS, and MU trigger frames would have allowed Chu’s E-RTS frame to efficiently signal enhanced capabilities, improving interoperability with both legacy and advanced designs. This modification to combine would’ve been driven by the need to enhance flexibility, compatibility, and signaling efficiency of RTS frames in evolving WLAN systems, particularly those supporting high-efficiency and backward compatible features.
Regarding claim 22, Chu fails to teach the STA wherein the third value is set to zero (0), the first value is set to one (1), and the second value is set to two (2).
However, Seok teaches the STA wherein the third value is set to zero (0), the first value is set to one (1), and the second value is set to two (2) (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/punctrue-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS).
A POSITA would have found it obvious to incorporate the version field and conditional inclusion of additional control information from Seok into the E-RTS message of Chu because both references aim to enhance coordination of uplink and downlink access in high-efficiency wireless networks (through MU-MIMO scheduling and TXOP sharing). Seok provides a known mechanism—via the version field—for indicating frame format extensions and controlling the inclusion of new fields based on capability negotiation. Furthermore, Chun discloses control information (MAC header) including type information fields, whose values indicates frame types such as RTS, CTS and MU trigger frames. Adding the version field, associated control information (puncturing info, group scheduling details, or modulation/coding info), and type information fields, whose values indicates frame types such as RTS, CTS, and MU trigger frames would have allowed Chu’s E-RTS frame to efficiently signal enhanced capabilities, improving interoperability with both legacy and advanced designs. This modification to combine would’ve been driven by the need to enhance flexibility, compatibility, and signaling efficiency of RTS frames in evolving WLAN systems, particularly those supporting high-efficiency and backward compatible features.
Regarding claim 23, Chu fails to teach the STA wherein the CTS frame includes a second frame control field which contains control information related to the CTS frame and has a length of 2 octets, a second duration field which is contiguous to the second frame control field and has a length of 2 octets, a second receiver address (RA) field which is contiguous to the second duration field and has a length of 6 octets, a second transmitter address (TA) field which is contiguous to the second RA field and has a length of 6 octets, a CTS version field which is contiguous to the second TA field.
However, Seok teaches the STA wherein the CTS frame includes a second frame control field which contains control information related to the CTS frame and has a length of 2 octets, a second duration field which is contiguous to the second frame control field and has a length of 2 octets, a second receiver address (RA) field which is contiguous to the second duration field and has a length of 6 octets, a second transmitter address (TA) field which is contiguous to the second RA field and has a length of 6 octets, a CTS version field which is contiguous to the second TA field (slides 5-9, detailing new EHT RTS and CTS framework structures for punctured EHT channel states; describes the frame header layout such as frame control field 2 octets, duration field 2 octets, receiver address (RA) 6 octets, transmitter address (TA) 6 octets, followed by other control information before the FCS; this enhanced RTS includes a version or type subfield (frame control header or header extension), when set to a specific value (indicating EHT-RTS), it inserts additional control information contiguous to that field; specifically, a bitmap/puncture-channel control field located before the FCS coding which subchannels (punctured carriers) are disallowed; the disallowed subchannel bitmap field explicitly carries puncturing data, contiguous to the version/type fields and preceding the FCS; all control information including the new puncturing bitmap is within the MAC header and followed directly by the FCS).
A POSITA would have found it obvious to incorporate the version field and conditional inclusion of additional control information from Seok into the E-RTS message of Chu because both references aim to enhance coordination of uplink and downlink access in high-efficiency wireless networks (through MU-MIMO scheduling and TXOP sharing). Seok provides a known mechanism—via the version field—for indicating frame format extensions and controlling the inclusion of new fields based on capability negotiation. Furthermore, Chun discloses control information (MAC header) including type information fields, whose values indicates frame types such as RTS, CTS and MU trigger frames. Adding the version field, associated control information (puncturing info, group scheduling details, or modulation/coding info), and type information fields, whose values indicates frame types such as RTS, CTS, and MU trigger frames would have allowed Chu’s E-RTS frame to efficiently signal enhanced capabilities, improving interoperability with both legacy and advanced designs. This modification to combine would’ve been driven by the need to enhance flexibility, compatibility, and signaling efficiency of RTS frames in evolving WLAN systems, particularly those supporting high-efficiency and backward compatible features.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kim et al (US20180020475A1) discloses wireless communication method for saving power and wireless communication terminal using same
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL WILLIAM ABBATINE whose telephone number is (571)272-0192. The examiner can normally be reached Monday-Friday 0830-1700 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nishant Divecha can be reached at (571) 270-3125. 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.
/MICHAEL WILLIAM ABBATINE JR./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419