DETAILED ACTION
This Office action is a response to an application filed on August 2, 2024 wherein claims 1-18 remain pending and ready for examination.
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 .
Claim Objections
Claim 10 is objected to because “obtaining” and “maintaining” should respectively read “obtain” and “maintain”. Appropriate correction is required.
Claim 14 is objected to because the second instance of “the apparatus” (emphasis added) in “cause the apparatus to output, for transmission to the apparatus, an acknowledgment of the protected frame” should read “a wireless device.” Otherwise, the claim require the apparatus transmit an acknowledgement to itself and does not make sense. Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
Claims 1-4, 6-13, 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Trainin et al. (US 20180375969 A1, hereafter Trainin) in view of Chitrakar et al. (US 20230011167 A1, hereafter Chitrakar).
Regarding claim 1, Trainin discloses:
An apparatus for wireless communications (originator, Figs.8-10, 1000), comprising:
a memory comprising instructions (1010); and
one or more processors (1002, 1004, 1008) configured to execute the instructions and cause the apparatus (See [0114]-[0115]) to:
generate a protected frame (robust ADDBA Request frame, at least one frame) that indicates: 1) an updated starting sequence number (SSN) of a block acknowledgment (BA) window (MPDU_SSN, MPDU Starting Sequence Number subfield value, MSDU_SSN, MSDU Starting Sequence Number subfield value) and 2) an intended purpose of the protected frame as a request to update a BA window with the updated SSN (robust ADDBA Request frame is to shift the recipient's WinStartB value past the hole in the sequence number space; initializing a variable for a next expected sequence number based on the MSDU SSN and to initialize a variable for a starting MPDU sequence number based on the MPDU SSN) ([0069] In some cases, operations 500 may further include the recipient apparatus obtaining at least one frame with a set of parameters associated with at least an MPDU starting sequence number (SSN) and an MSDU SSN. The operations 500 may further include having the recipient apparatus initializing a variable for a next expected sequence number based on the MSDU SSN and to initialize a variable for a starting MPDU sequence number based on the MPDU SSN. In some cases, the set of parameters also indicates how many bits are used for the MPDU SSN and how many bits are used for the MSDU SSN. Further, the operations 500 may also include having the recipient apparatus determining the MPDU SSN and the MSDU SSN based on the indicated number of bits. [0083] WinStartB may be initialized to the MPDU Starting Sequence Number subfield value of the ADDBA Request frame that elicited the ADDBA Response frame that established the JMD block Ack agreement. WinEndB is initialized to WinStartB+WinSizeB−1, where WinSizeB is set to the smaller of 64 and the value of the MPDU Buffer Size field of the ADDBA Response frame that established the block Ack agreement. WinStartBJ is initialized to the MSDU Starting Sequence Number subfield value of the ADDBA Request frame that elicited the ADDBA Response frame that established the JMD block Ack agreement. [0106] The originator may send a BlockAckReq frame for block Ack agreement that is not a protected block Ack agreement or a robust ADDBA Request frame for protected block Ack agreement when a Data frame that was previously transmitted within an A-MPDU that had the Ack Policy field equal to Normal Ack is discarded due to exhausted MSDU lifetime. The purpose of this BlockAckReq or robust ADDBA Request frame is to shift the recipient's WinStartB value past the hole in the sequence number space that is created by the discarded Data frame and thereby to allow the earliest possible passing of buffered frames up to the next MAC process. [0107] Under JMD block Ack agreement the BlockAckReq or robust ADDBA Request frame shall comprise MPDU_SSN and MSDU_SSN fields of MPDU with the indication that the MPDU is the start of an MSDU (e.g., start_of_MSDU=true).; See also Figs.4-7, [0063], [0066], [0079]);
output, for transmission to a wireless device (recipient, Figs.8-9&11, 1100) that the apparatus has established a protected block acknowledgment (BA) agreement with ([0106] a robust ADDBA Request frame for protected block Ack agreement), the protected frame (robust ADDBA Request frame) ([0066] The operations 400 may further include the originator apparatus outputting the at least one frame for transmission to the recipient);
generate multiple medium access control (MAC) Protocol Data Units (MPDUs) (MPDUs) with SNs (MPDU sequence numbers) ([0065] Operations 400 begin, at 402, by splitting a first media access control (MAC) service data unit (MSDU) into a first plurality of MAC protocol data units (MPDUs), each having a unique MPDU sequence number and a separate MSDU sequence number associated with the first MSDU. At 404, the originator outputs the first plurality of MPDUs for transmission to a recipient. In some cases, the first plurality of MPDUs are output for transmission via an aggregated MPDU (A-MPDU).); and
output, for transmission to the wireless device, the multiple MPDUs ([0065]).
Trainin does not explicitly disclose the apparatus caused to: generate multiple medium access control (MAC) Protocol Data Units (MPDUs) with SNs within the updated BA window; and output, for transmission to the wireless device, the multiple MPDUs.
However, Chitrakar discloses:
An apparatus caused to: generate multiple medium access control (MAC) Protocol Data Units (MPDUs) (failed MPDUs with SN = 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, or 17) with SNs (Fig.19, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, or 17) within the updated BA window (BA window with the WinStart replaced); and
output, for transmission to a wireless device, the multiple MPDUs ([0100] FIG. 19 shows how eBAR resolves the issue of scoreboard context out of range as previously illustrated in FIG. 15A. Since the value of WinStartR for the scoreboard 1512 on Link 2=WS_R=16 after the initial transmission, if the originator MLD were to retransmit the failed MPDUs (that were originally transmitted on Link 1) on Link 2 … the originator MLD transmits an eBAR 1800 with SSN=3, which is the smallest SN to be re-transmitted. The “shift WinStartR” bit is set in the eBAR, hence recipient MLD shall replace the value of WinStartR for the scoreboard 1902 on Link 2 with the value of the Starting Sequence Number (SSN) sub-field of the BAR information field. Thereafter, the failed MPDUs on Link 1 may be re-transmitted on Link 2 as illustrated in 1900 without causing the scoreboard context control to become out of range. Advantageously, eBAR solves the issue of Scoreboard context control being out of range and facilitates cross-link re-transmissions.).
It would have been obvious before the effective filing date of the claimed invention to a person of ordinary skill in the art to modify the apparatus of Trainin to generate and output MPDUs as taught by Chitrakar, in order to allow the earliest possible passing of buffered frames up to the next MAC process by retransmit MPDUs in the updated BA window (Chitrakar, [0100]; Trainin, [0106] The purpose of this BlockAckReq or robust ADDBA Request frame is to shift the recipient's WinStartB value past the hole in the sequence number space that is created by the discarded Data frame and thereby to allow the earliest possible passing of buffered frames up to the next MAC process.)
Regarding claim 2,
Trainin does not explicitly disclose wherein the one or more processors are further configured to execute the instructions and cause the apparatus to: output, for transmission to the wireless device, an MPDU indicating a BA request; and obtain, from the wireless device in response to the request, a BA indicating which of the MPDUs within the updated BA window were successfully received by the wireless device.
However, Chitrakar discloses:
the apparatus (Fig.5, originator) to:
output, for transmission to the wireless device (Fig.5, recipient), an MPDU indicating a BA request (BlockAckReq, 532, 542); and
obtain, from the wireless device in response to the request, a BA (Block Ack) indicating which of the MPDUs within a BA window were successfully received by the wireless device ([0055] The MLD also includes Media Access Control (MAC) circuitry 212 coupled to the plurality of transceivers 216, 218, 220 which, in operation, generates a multi-link block acknowledgement request frame 532 and transmits the MAC multi-link block acknowledgement request frame 532 on the one of the plurality of frequency bands 206 to solicit the multi-link block acknowledgement frame 534. The Media Access Control (MAC) circuitry 212 subsequently receives a multi-link block acknowledgement frame 534 on one of the plurality of frequency bands 206 acknowledging the signal frames 536a, 536b, 536c transmitted on the plurality of frequency bands. [0100] FIG. 19 shows how eBAR resolves the issue of scoreboard context out of range as previously illustrated in FIG. 15A. Since the value of WinStartR for the scoreboard 1512 on Link 2=WS_R=16 after the initial transmission, if the originator MLD were to retransmit the failed MPDUs (that were originally transmitted on Link 1) on Link 2 … the originator MLD transmits an eBAR 1800 with SSN=3, which is the smallest SN to be re-transmitted. The “shift WinStartR” bit is set in the eBAR, hence recipient MLD shall replace the value of WinStartR for the scoreboard 1902 on Link 2 with the value of the Starting Sequence Number (SSN) sub-field of the BAR information field. Thereafter, the failed MPDUs on Link 1 may be re-transmitted on Link 2 as illustrated in 1900 without causing the scoreboard context control to become out of range. Advantageously, eBAR solves the issue of Scoreboard context control being out of range and facilitates cross-link re-transmissions.; See also Figs.13-15, 19-20).
It would have been obvious before the effective filing date of the claimed invention to a person of ordinary skill in the art to modify the one or more processors of Trainin to be further configured to execute the instructions and cause the apparatus to output a BA request and obtain a BA for the updated BA window as taught by Chitrakar, in order to allow the earliest possible passing of buffered frames up to the next MAC process by retransmit MPDUs in the updated BA window (Chitrakar, [0100]; Trainin, [0106] The purpose of this BlockAckReq or robust ADDBA Request frame is to shift the recipient's WinStartB value past the hole in the sequence number space that is created by the discarded Data frame and thereby to allow the earliest possible passing of buffered frames up to the next MAC process.)
Regarding claims 3 and 12, Trainin discloses:
wherein the protected frame (robust ADDBA Request frame) comprises a BA action frame designed for updating the BA window ([0106] … The purpose of this BlockAckReq or robust ADDBA Request frame is to shift the recipient's WinStartB value past the hole in the sequence number space that is created by the discarded Data frame and thereby to allow the earliest possible passing of buffered frames up to the next MAC process.; Note that ADDBA Request frame is a well-known action frame. See, e.g., Chitrakar [0135] “ADDBA action frames such as ADDBA request frames and/or ADDBA response frames”)
Regarding claims 4 and 13, Trainin discloses:
wherein the protected frame (robust ADDBA Request frame, at least one frame) indicates the intended purpose (robust ADDBA Request frame is to shift the recipient's WinStartB value past the hole in the sequence number space; initializing a variable for a next expected sequence number based on the MSDU SSN and to initialize a variable for a starting MPDU sequence number based on the MPDU SSN) via at least one of a category field or BA action field of the protected frame ([0069] In some cases, operations 500 may further include the recipient apparatus obtaining at least one frame with a set of parameters associated with at least an MPDU starting sequence number (SSN) and an MSDU SSN. The operations 500 may further include having the recipient apparatus initializing a variable for a next expected sequence number based on the MSDU SSN and to initialize a variable for a starting MPDU sequence number based on the MPDU SSN. In some cases, the set of parameters also indicates how many bits are used for the MPDU SSN and how many bits are used for the MSDU SSN. Further, the operations 500 may also include having the recipient apparatus determining the MPDU SSN and the MSDU SSN based on the indicated number of bits.; See also [0066], [0106]).
Regarding claims 6 and 15, Trainin discloses:
wherein the protected frame (robust ADDBA Request frame) comprises an add BA (ADDBA) request frame (robust ADDBA Request frame).
Regarding claim 7, Trainin discloses:
wherein the protected frame (robust ADDBA Request frame, at least one frame) includes a field (bits used for the MSDU SSN and the MPDU SSN) set to a certain value to indicate the intended purpose ([0069] In some cases, operations 500 may further include the recipient apparatus obtaining at least one frame with a set of parameters associated with at least an MPDU starting sequence number (SSN) and an MSDU SSN. The operations 500 may further include having the recipient apparatus initializing a variable for a next expected sequence number based on the MSDU SSN and to initialize a variable for a starting MPDU sequence number based on the MPDU SSN. In some cases, the set of parameters also indicates how many bits are used for the MPDU SSN and how many bits are used for the MSDU SSN. Further, the operations 500 may also include having the recipient apparatus determining the MPDU SSN and the MSDU SSN based on the indicated number of bits.; See also [0066], [0106]).
Regarding claims 8 and 17, Trainin discloses:
wherein the field is in a frame header of the ADDBA request frame (robust ADDBA Request frame, at least one frame).
Regarding claim 9, Trainin discloses:
further comprising at least one transceiver (1012) configured to transmit the protected frame and the multiple MPDUs, wherein the apparatus is configured as a wireless device ([0113] … The communications device 1000 includes a processing system 1014 coupled to a transceiver 1012. The transceiver 1012 is configured to transmit and receive signals for the communications device 1000 via an antenna 1020, such as the various signal described herein.).
Regarding claim 10, Trainin discloses:
An apparatus for wireless communications (recipient, Figs.8-9&11, 1100), comprising:
a memory comprising instructions (1110); and
one or more processors (1102, 1104, 1108) configured to execute the instructions and cause the apparatus (See [0117]-[0118]) to:
obtaining, from a wireless device (originator, Figs.8-10, 1000) that the apparatus has established a protected block acknowledgment (BA) agreement with ([0106] a robust ADDBA Request frame for protected block Ack agreement), a protected frame (robust ADDBA Request frame) that indicates: 1) an updated starting sequence number (SSN) of a block acknowledgment (BA) window (MPDU_SSN, MPDU Starting Sequence Number subfield value, MSDU_SSN, MSDU Starting Sequence Number subfield value) and 2) an intended purpose of the protected frame as a request to update a BA window with the updated SSN (robust ADDBA Request frame is to shift the recipient's WinStartB value past the hole in the sequence number space; initializing a variable for a next expected sequence number based on the MSDU SSN and to initialize a variable for a starting MPDU sequence number based on the MPDU SSN) ([0069] In some cases, operations 500 may further include the recipient apparatus obtaining at least one frame with a set of parameters associated with at least an MPDU starting sequence number (SSN) and an MSDU SSN. The operations 500 may further include having the recipient apparatus initializing a variable for a next expected sequence number based on the MSDU SSN and to initialize a variable for a starting MPDU sequence number based on the MPDU SSN. In some cases, the set of parameters also indicates how many bits are used for the MPDU SSN and how many bits are used for the MSDU SSN. Further, the operations 500 may also include having the recipient apparatus determining the MPDU SSN and the MSDU SSN based on the indicated number of bits. [0083] WinStartB may be initialized to the MPDU Starting Sequence Number subfield value of the ADDBA Request frame that elicited the ADDBA Response frame that established the JMD block Ack agreement. WinEndB is initialized to WinStartB+WinSizeB−1, where WinSizeB is set to the smaller of 64 and the value of the MPDU Buffer Size field of the ADDBA Response frame that established the block Ack agreement. WinStartBJ is initialized to the MSDU Starting Sequence Number subfield value of the ADDBA Request frame that elicited the ADDBA Response frame that established the JMD block Ack agreement. [0106] The originator may send a BlockAckReq frame for block Ack agreement that is not a protected block Ack agreement or a robust ADDBA Request frame for protected block Ack agreement when a Data frame that was previously transmitted within an A-MPDU that had the Ack Policy field equal to Normal Ack is discarded due to exhausted MSDU lifetime. The purpose of this BlockAckReq or robust ADDBA Request frame is to shift the recipient's WinStart.sub.B value past the hole in the sequence number space that is created by the discarded Data frame and thereby to allow the earliest possible passing of buffered frames up to the next MAC process. [0107] Under JMD block Ack agreement the BlockAckReq or robust ADDBA Request frame shall comprise MPDU_SSN and MSDU_SSN fields of MPDU with the indication that the MPDU is the start of an MSDU (e.g., start_of_MSDU=true).; See also Figs.4-7, [0063], [0066], [0079]); and
tracking medium access control (MAC) Protocol Data Units (MPDUs) that have been successfully obtained by the apparatus ([0068] Operations 500 begin, at 502, with by obtaining a first plurality of media access control (MAC) protocol data unit (MPDUs), each having a unique MPDU sequence number and a separate MAC service data unit (MSDU) sequence number. At 504, the recipient maintains a receive buffer based on the MPDU and MSDU sequence numbers of the first plurality of MPDUs. In some cases, the first plurality of MPDUs is obtained via an aggregated MPDU (A-MPDU).).
Trainin does not disclose: maintaining a bitmap to track medium access control (MAC) Protocol Data Units (MPDUs) with SNs within the updated BA window that have been successfully obtained by the apparatus.
However, Chitrakar discloses:
maintaining a bitmap (Fig.19, scoreboard, 1902, 1114) to track medium access control (MAC) Protocol Data Units (MPDUs) (MPDUs with SN = 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, or 17) with SNs (Fig.19, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, or 17) within the updated BA window (BA window with the WinStart replaced) that have been successfully obtained by the apparatus ([0100] FIG. 19 shows how eBAR resolves the issue of scoreboard context out of range as previously illustrated in FIG. 15A. Since the value of WinStartR for the scoreboard 1512 on Link 2=WS_R=16 after the initial transmission, if the originator MLD were to retransmit the failed MPDUs (that were originally transmitted on Link 1) on Link 2 … the originator MLD transmits an eBAR 1800 with SSN=3, which is the smallest SN to be re-transmitted. The “shift WinStartR” bit is set in the eBAR, hence recipient MLD shall replace the value of WinStartR for the scoreboard 1902 on Link 2 with the value of the Starting Sequence Number (SSN) sub-field of the BAR information field. Thereafter, the failed MPDUs on Link 1 may be re-transmitted on Link 2 as illustrated in 1900 without causing the scoreboard context control to become out of range. Advantageously, eBAR solves the issue of Scoreboard context control being out of range and facilitates cross-link re-transmissions.).
It would have been obvious before the effective filing date of the claimed invention to a person of ordinary skill in the art to modify the apparatus of Trainin to generate and output MPDUs as taught by Chitrakar, in order to allow the earliest possible passing of buffered frames up to the next MAC process by retransmit MPDUs in the updated BA window (Chitrakar, [0100]; Trainin, [0106] The purpose of this BlockAckReq or robust ADDBA Request frame is to shift the recipient's WinStartB value past the hole in the sequence number space that is created by the discarded Data frame and thereby to allow the earliest possible passing of buffered frames up to the next MAC process.)
It would have been obvious before the effective filing date of the claimed invention to a person of ordinary skill in the art to modify the apparatus of Trainin to maintain a bitmap as taught by Chitrakar, in order to allow the earliest possible passing of buffered frames up to the next MAC process using the bitmap tracking retransmitted MPDUs in the updated BA window (Chitrakar, [0100]; Trainin, [0106] The purpose of this BlockAckReq or robust ADDBA Request frame is to shift the recipient's WinStartB value past the hole in the sequence number space that is created by the discarded Data frame and thereby to allow the earliest possible passing of buffered frames up to the next MAC process.)
Regarding claim 11, Trainin discloses:
Trainin does not explicitly disclose wherein the one or more processors are further configured to execute the instructions and cause the apparatus to: obtain, from the wireless device, a BA request; and output, for transmission to the wireless device, an MPDU indicating a BA indicating which of the MPDUs within the updated BA window were successfully obtained by the apparatus in accordance with the bitmap.
However, Chitrakar discloses:
the apparatus (Fig.5, recipient) to:
obtain, from the wireless device (Fig.5, originator), a BA request (BlockAckReq, 532, 542); and
output, for transmission to the wireless device, an MPDU indicating a BA (Block Ack) indicating which of the MPDUs within a BA window were successfully obtained by the apparatus in accordance with the bitmap ([0055] The MLD also includes Media Access Control (MAC) circuitry 212 coupled to the plurality of transceivers 216, 218, 220 which, in operation, generates a multi-link block acknowledgement request frame 532 and transmits the MAC multi-link block acknowledgement request frame 532 on the one of the plurality of frequency bands 206 to solicit the multi-link block acknowledgement frame 534. The Media Access Control (MAC) circuitry 212 subsequently receives a multi-link block acknowledgement frame 534 on one of the plurality of frequency bands 206 acknowledging the signal frames 536a, 536b, 536c transmitted on the plurality of frequency bands. [0100] FIG. 19 shows how eBAR resolves the issue of scoreboard context out of range as previously illustrated in FIG. 15A. Since the value of WinStartR for the scoreboard 1512 on Link 2=WS_R=16 after the initial transmission, if the originator MLD were to retransmit the failed MPDUs (that were originally transmitted on Link 1) on Link 2 … the originator MLD transmits an eBAR 1800 with SSN=3, which is the smallest SN to be re-transmitted. The “shift WinStartR” bit is set in the eBAR, hence recipient MLD shall replace the value of WinStartR for the scoreboard 1902 on Link 2 with the value of the Starting Sequence Number (SSN) sub-field of the BAR information field. Thereafter, the failed MPDUs on Link 1 may be re-transmitted on Link 2 as illustrated in 1900 without causing the scoreboard context control to become out of range. Advantageously, eBAR solves the issue of Scoreboard context control being out of range and facilitates cross-link re-transmissions.; See also Figs.13-15, 19-20).
It would have been obvious before the effective filing date of the claimed invention to a person of ordinary skill in the art to modify the one or more processors of Trainin to be further configured to execute the instructions and cause the apparatus to obtain a BA request and output a BA for the updated BA window in accordance with the bitmap as taught by Chitrakar, in order to allow the earliest possible passing of buffered frames up to the next MAC process by retransmit MPDUs in the updated BA window (Chitrakar, [0100]; Trainin, [0106] The purpose of this BlockAckReq or robust ADDBA Request frame is to shift the recipient's WinStartB value past the hole in the sequence number space that is created by the discarded Data frame and thereby to allow the earliest possible passing of buffered frames up to the next MAC process.)
Regarding claim 16, Trainin discloses:
wherein the ADDBA request frame (robust ADDBA Request frame, at least one frame) includes a field (bits used for the MSDU SSN and the MPDU SSN) set to a certain value to indicate the intended purpose ([0069] In some cases, operations 500 may further include the recipient apparatus obtaining at least one frame with a set of parameters associated with at least an MPDU starting sequence number (SSN) and an MSDU SSN. The operations 500 may further include having the recipient apparatus initializing a variable for a next expected sequence number based on the MSDU SSN and to initialize a variable for a starting MPDU sequence number based on the MPDU SSN. In some cases, the set of parameters also indicates how many bits are used for the MPDU SSN and how many bits are used for the MSDU SSN. Further, the operations 500 may also include having the recipient apparatus determining the MPDU SSN and the MSDU SSN based on the indicated number of bits.; See also [0066], [0106]).
Regarding claim 18, Trainin discloses:
further comprising at least one transceiver (1112) configured to receive the protected frame, wherein the apparatus is configured as a wireless device ([0116] … The communications device 1100 includes a processing system 1114 coupled to a transceiver 1112. The transceiver 1112 is configured to transmit and receive signals for the communications device 1100 via an antenna 1120, such as the various signal described herein.).
Claims 5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Trainin in view of Chitrakar, further in view of Hsu et al. (US 20230188266 A1, hereafter Hsu).
Regarding claim 5,
Trainin and Chitrakar disclose wherein the protected frame comprises an add BA (ADDBA) request frame (see the rejection of claim 6).
Trainin and Chitrakar do not explicitly disclose wherein the one or more processors are further configured to execute the instructions and cause the apparatus to obtain, from the wireless device, an acknowledgment of the ADDBA request frame.
However, Hsu discloses:
The apparatus (originator) to obtain, from the wireless device (recipient), an acknowledgment (ACK) of the ADDBS frame (ADBA Request) (See Figs.2-6 and corresponding descriptions).
It would have been obvious before the effective filing date of the claimed invention to a person of ordinary skill in the art to modify the one or more processors of Trainin and Chitrakar to be further configured to execute the instructions and cause the apparatus to obtain an acknowledgement as taught by Hsu, in order to respond to a negotiation procedure initiated by a request action frame with an acknowledgement (ACK) control frame or a time-constrained response action frame (Hsu, [0002] The present invention relates to wireless communications, and more particularly, to a method and apparatus for dealing with a negotiation procedure initiated by a request action frame through responding with an acknowledgement (ACK) control frame or a time-constrained response action frame.)
Regarding claim 14,
Trainin and Chitrakar disclose wherein the protected frame comprises an add BA (ADDBA) request frame (see the rejection of claim 15).
Trainin and Chitrakar do not explicitly disclose wherein the one or more processors are further configured to execute the instructions and cause the apparatus to output, for transmission to the apparatus, an acknowledgment of the ADDBA request frame.
However, Hsu discloses:
The apparatus (recipient) to output, for transmission to the apparatus (originator), an acknowledgment (ACK) of the ADDBA request frame (ADBA Request) (See Figs.2-6 and corresponding descriptions).
wherein the one or more processors are further configured to execute the instructions and cause the apparatus to output
It would have been obvious before the effective filing date of the claimed invention to a person of ordinary skill in the art to modify the one or more processors of Trainin and Chitrakar to be further configured to execute the instructions and cause the apparatus to output an acknowledgement as taught by Hsu, in order to respond to a negotiation procedure initiated by a request action frame with an acknowledgement (ACK) control frame or a time-constrained response action frame (Hsu, [0002] The present invention relates to wireless communications, and more particularly, to a method and apparatus for dealing with a negotiation procedure initiated by a request action frame through responding with an acknowledgement (ACK) control frame or a time-constrained response action frame.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Moo Ryong Jeong whose telephone number is (571)272-9617. The examiner can normally be reached Monday-Friday 8AM-5PM 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.
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.
/Moo Jeong/Supervisory Patent Examiner, Art Unit 2418
Prosecution Insights