DETAILED ACTION
Notice of 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 .
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.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. In particular, this Application is the national stage application of an international application that was filed on 18 Mar 2020.
Information Disclosure Statements
The information disclosure statements, submitted on 16 Sept 2022 and 3 Oct 2024, are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Objections
Claim 82 is objected to because it lacks a period. Appropriate correction is required.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 11, 12, 14, 22, 31-33, 72, and 74-84 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites, in part, “wherein the duration field in the MAC frame header . . . configured to be used by the third communication device belonging to a same Basic Service Set (BSS) as the first communication device . . . and the length field in the physical frame header is configured to be used by the third communication device belonging to a different BSS as the first communication device to set the NAV.”
It is unclear in the claimed invention if the third communication device is required to belong to the same BSS as the first communication device or a different BSS as the first communication device. Claims 12 and 22 recite the same limitation as claim 1 and are indefinite for the same reason. All other claims are rejected due to their dependence upon an indefinite claim.
Response to Arguments
Applicant’s arguments with respect to the independent claims 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. In particular, Huang is now cited for teaching defining a NAV using either a MAC field or PHY field for STAs in both the same and different basic service sets.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 11, 12, 14, 22, 31-33, 74-77, 79, 80, and 84 are rejected under 35 U.S.C. 103 as being unpatentable over McNamara (US 20050249244) in view of Huang (US 20170201981).
Regarding claims 1 and 74, McNamara teaches a data transmission method, applied to a communication device, and a data transmission apparatus comprising a processor, a memory, and an executable program configured to implement the method (McNamara, figure 9 – destination device), comprising:
determining duration indication information according to reception of a data frame in a multi-transport connection transmission (McNamara, ¶69 – a duration value is determined when a received data packet requires a NACK in response; McNamara, ¶4 – WLAN transmission is over a multi-path channel, which a preamble is used to correct),
wherein the duration indication information is configured to indicate duration of a transport connection continuing to be occupied (McNamara, ¶69 – duration value updates the NAV value); and
sending a first acknowledgement message frame (McNamara, ¶69 – NACK packet is sent), wherein the first acknowledgement message frame comprises feedback information about the reception and the duration indication information (McNamara, ¶69 - NACK packet indicates an unsuccessful reception of the packet and includes a DURATION field that contains the determined duration value);
wherein the duration indication information comprises a duration field in a Media Access Control (MAC) frame header of the first acknowledgement message frame (McNamara, ¶¶49, 69 and figure 2), and a length field in a physical frame header of the acknowledgement message frame (McNamara, ¶¶47, 61 and figure 1 – PLCP is a PHY and its header includes a length field).
McNamara does not explicitly teach “wherein the duration field in the MAC frame header is configured to be used by the second communication device to determine the duration of the transport connection continuing to be occupied, and configured to be used by a third communication device belonging to a same Basic Service Set (BSS) as the first communication device to set a Network Allocation Vector (NAV), and the length field in the physical frame header is configured to be used by the third communication device belonging to a different BSS as the first communication device to set the NAV.” However, Huang teaches the following:
wherein the duration field in the MAC frame header (Huang, figure 6 – MAC duration 620) is
configured to be used by the second communication device to determine the duration of the transport connection continuing to be occupied (Huang, ¶45 – HEW station 104.2 uses MAC duration 620 if it is successfully decoded and updates its NAV accordingly), and
configured to be used by a third communication device belonging to a same Basic Service Set (BSS) as the first communication device to set a Network Allocation Vector (NAV) (Huang, ¶41- HEW stations 104.2 and 104.1 are attached to master station 102.1 [i.e. share the same BSS]; id., figure 8 and ¶40 – BSS 804 and BSS 802; id. at figure 7 – all STAs in a BSS of the same AP applying either the PHY or MAC duration as a NAV [i.e. HEW station 104.1 will use the NAV indicated by master station 102.1]), and
the length field in the physical frame header (Huang, figure 6 – HE-SIG-A duration 618) is configured to be used by the third communication device belonging to a different BSS as the first communication device to set the NAV. Huang, ¶¶52-54 – HEW station uses HE-SIG-B duration 618 if it is unable to decode the MAC portion of an inter-BSS packet [i.e. a packet belonging to a different BSS associated with master station 102.2] and updates its NAV accordingly).
At the time of the effective filing date of the invention, it would have been obvious for one of ordinary skill in the art to use either a PHY or MAC duration field, as taught by Huang, to define the NAV, taught by McNamara, in order to ensure channel access to station that is in an overlapping Basic Service Sets (OBSS) situation. Id. at ¶40.
Regarding claims 14 and 79, the combination of McNamara and Huang also teaches wherein in response to failed reception of the data frame (McNamara, figure 9 – NACK transmitted), the duration indicated by the duration indication information comprises transmission duration of a retransmitted data frame (McNamara, figure 9 – duration of NAV(NACK) includes the time need for a DATA transmission by the source) and wherein the duration indicated by the duration indication information further comprises at least one of: transmission duration of the first acknowledgement message frame; or transmission duration of a second acknowledgement message frame corresponding to the retransmitted data frame. McNamara, figure 9 (“NAV(NACK)” duration includes the time to transmit a second NACK).
Regarding claim 10, the combination of McNamara and Huang also teaches wherein the duration indication information comprises a duration field in a Media Access Control (MAC) frame header of the first acknowledgement message frame (McNamara, figure 2 – MAC header includes “Duration/ID field; McNamara, ¶69 – duration field in NACK packet, which has a MAC header), and a length field in a physical frame header of the first acknowledgment message frame. McNamara, figure 1 and ¶65 (PLCP header includes length field).
Regarding claim 11, the combination of McNamara and Huang also teaches determining the duration indicated by the duration indication information as 0 in response to successful reception of the data frame. McNamara, ¶68 and figure 9 (as shown in the second “NAV(NACK)” of figure 9, when an ACK is received an additional NAV(NACK) is not initiated).
Regarding claims 12 and 75, McNamara teaches a data transmission method, performed by a communication device, and a data transmission apparatus comprising a processor, a memory, and an executable program configured to implement the method (McNamara, figure 9 – source device), comprising:
receiving, from a first communication device, a first acknowledgement message frame (McNamara, ¶69 and figure 9 – source device receives NACK from destination during NAV(RTS));
determining reception of a data frame in multi-transport connection transmission according to feedback information in the first acknowledgment message frame (McNamara, ¶69 – ACK or NACK from destination indicates to source whether transmission of a data packet was successful); and
determining duration of a transport connection continuing to be occupied according to duration indication information in the first acknowledgment message frame (McNamara, ¶69 – duration value updates the NAV value),
wherein the duration indication information is based on the reception of the data frame (McNamara, ¶69 - a duration value is determined when a received data packet requires a NACK in response);
wherein the duration indication information comprises a duration field in a Media Access Control (MAC) frame header of the first acknowledgement message frame (McNamara, ¶¶49, 69 and figure 2), and a length field in a physical frame header of the acknowledgement message frame (McNamara, ¶¶47, 61 and figure 1 – PLCP is a PHY and its header includes a length field).
McNamara does not explicitly teach “wherein the duration field in the MAC frame header is configured to be used by the second communication device to determine the duration of the transport connection continuing to be occupied, and configured to be used by a third communication device belonging to a same Basic Service Set (BSS) as the first communication device to set a Network Allocation Vector (NAV), and the length field in the physical frame header is configured to be used by the third communication device belonging to a different BSS as the first communication device to set the NAV.” However, Huang teaches the following:
wherein the duration field in the MAC frame header (Huang, figure 6 – MAC duration 620) is
configured to be used by the second communication device to determine the duration of the transport connection continuing to be occupied (Huang, ¶45 – HEW station 104.2 uses MAC duration 620 if it is successfully decoded and updates its NAV accordingly), and
configured to be used by a third communication device belonging to a same Basic Service Set (BSS) as the first communication device to set a Network Allocation Vector (NAV) (Huang, ¶41- HEW stations 104.2 and 104.1 are attached to master station 102.1 [i.e. share the same BSS]; id., figure 8 and ¶40 – BSS 804 and BSS 802; id. at figure 7 – all STAs in a BSS of the same AP applying either the PHY or MAC duration as a NAV [i.e. HEW station 104.1 will use the NAV indicated by master station 102.1]), and
the length field in the physical frame header (Huang, figure 6 – HE-SIG-A duration 618) is configured to be used by the third communication device belonging to a different BSS as the first communication device to set the NAV. Huang, ¶¶52-54 – HEW station uses HE-SIG-B duration 618 if it is unable to decode the MAC portion of an inter-BSS packet [i.e. a packet belonging to a different BSS associated with master station 102.2] and updates its NAV accordingly).
At the time of the effective filing date of the invention, it would have been obvious for one of ordinary skill in the art to use either a PHY or MAC duration field, as taught by Huang, to define the NAV, taught by McNamara, in order to ensure channel access to station that is in an overlapping Basic Service Sets (OBSS) situation. Id. at ¶40.
Regarding claims 22 and 76, McNamara teaches a data transmission method, performed by a third communication device, and a data transmission apparatus comprising a processor, a memory, and an executable program configured to implement the method (McNamara, figure 9 – “other” terminal), comprising:
receiving, from a first communication device, a first acknowledgement message frame (McNamara, figure 9 and ¶69 – all terminal listening to the channel will receive the ACK or NACK sent by the destination device); and
setting a Network Allocation Vector (NAV) according to duration of a transport connection continuing to be occupied indicated by duration indication information in the first acknowledgment message frame (McNamara, ¶¶8, 55-56 – all terminals [i.e. not just the source and destination] can update their NAV according to the duration value provided in signaling between the source and destination; McNamara, ¶69 – update NAV value according to duration field in NACK),
wherein the duration indication information is based on reception of a data frame in multi-transport connection transmission. McNamara, ¶69 (a duration value is determined when a received data packet requires a NACK in response; McNamara, ¶4 – WLAN transmission over multipath channel is a multi-transport connection transmission);
wherein the duration indication information comprises a duration field in a Media Access Control (MAC) frame header of the first acknowledgement message frame (McNamara, ¶¶49, 69 and figure 2), and a length field in a physical frame header of the acknowledgement message frame (McNamara, ¶¶47, 61 and figure 1 – PLCP is a PHY and its header includes a length field).
McNamara does not explicitly teach “wherein the duration field in the MAC frame header is configured to be used by the second communication device to determine the duration of the transport connection continuing to be occupied, and configured to be used by a third communication device belonging to a same Basic Service Set (BSS) as the first communication device to set a Network Allocation Vector (NAV), and the length field in the physical frame header is configured to be used by the third communication device belonging to a different BSS as the first communication device to set the NAV.” However, Huang teaches the following:
wherein the duration field in the MAC frame header (Huang, figure 6 – MAC duration 620) is
configured to be used by the second communication device to determine the duration of the transport connection continuing to be occupied (Huang, ¶45 – HEW station 104.2 uses MAC duration 620 if it is successfully decoded and updates its NAV accordingly), and
configured to be used by a third communication device belonging to a same Basic Service Set (BSS) as the first communication device to set a Network Allocation Vector (NAV) (Huang, ¶41- HEW stations 104.2 and 104.1 are attached to master station 102.1 [i.e. share the same BSS]; id., figure 8 and ¶40 – BSS 804 and BSS 802; id. at figure 7 – all STAs in a BSS of the same AP applying either the PHY or MAC duration as a NAV [i.e. HEW station 104.1 will use the NAV indicated by master station 102.1]), and
the length field in the physical frame header (Huang, figure 6 – HE-SIG-A duration 618) is configured to be used by the third communication device belonging to a different BSS as the first communication device to set the NAV. Huang, ¶¶52-54 – HEW station uses HE-SIG-B duration 618 if it is unable to decode the MAC portion of an inter-BSS packet [i.e. a packet belonging to a different BSS associated with master station 102.2] and updates its NAV accordingly).
At the time of the effective filing date of the invention, it would have been obvious for one of ordinary skill in the art to use either a PHY or MAC duration field, as taught by Huang, to define the NAV, taught by McNamara, in order to ensure channel access to station that is in an overlapping Basic Service Sets (OBSS) situation. Id. at ¶40.
Regarding claims 31 and 84, the combination of McNamara and Huang also teaches determining that the third communication device belongs to the same BSS as the first communication device (Huang, ¶43 – HEW stations 104.1 and 104.2 are associated with master station 102.1 by setting the master station’s address as its master and storing its BSS color);
determining the duration of the transport connection continuing to be occupied by parsing the duration field in the MAC header (Huang, ¶45 – if MAC duration is successfully decoded, duration 620 is used as a new intra-BSS NAV 812, assuming it is greater than the initial intra-BSS NAV 812); and
setting the NAV according to the duration of the transport connection continuing to be occupied (McNamara, figure 2 – MAC header includes “Duration/ID field”; McNamara, ¶69 – duration field in NACK packet, which has a MAC header).
Regarding claim 32, the combination of McNamara and Huang also teaches updating, in response to the duration of the transport connection continuing to be occupied indicated by the duration indication information being greater than backoff duration indicated by the NAV, the backoff duration using the duration of the transport connection continuing to be occupied indicated by the duration indication information (McNamara, figure 9 – “NAV(NACK)” increases the time that the other terminal consider the channel to be busy by extending the “NAV(RTS)” that is already in effect), wherein the backoff duration is a duration to keep silent on the transport connection. McNamara, ¶¶8, 55 (terminals “hear” all other terminals in the network so they can update their NAV to prevent packet collisions by not transmitting on the channel when its busy).
Regarding claim 33, the combination of McNamara and Huang also teaches maintaining the NAV in response to the duration of the transport connection continuing to be occupied indicated by the duration indication information being less than or equal to backoff duration indicated by the NAV (McNamara, ¶69 and figure 9 – duration of each “NAV(NACK)” is the same because the retransmitted data packet size has to be the same as the original. As a result, the second “NAV(NACK)” maintains an NAV duration equal to the first “NAV(NACK)”; see also Huang, ¶45 – NAV is only updated if the new NAV is greater than the current NAV [otherwise the current NAV is “maintained”), wherein the backoff duration is a duration to keep silent on the transport connection. McNamara, ¶¶8, 55 (terminals “hear” all other terminals in the network so they can update their NAV to prevent packet collisions by not transmitting on the channel when its busy).
Regarding claim 77, the combination of McNamara and Huang teaches wherein determining the duration indication information according to the reception of the data frame in multi-transport connection transmission further comprises: determining the duration indication information in response to failed reception of the data frame (McNamara, ¶69 – duration value is determined when a NACK is needed in response to receiving a data packet), wherein the duration indicated by the duration indication information comprises transmission duration of a retransmitted data frame (McNamara, figure 9 - “NAV(NACK)” includes retransmission of “data”).
Regarding claim 80, the combination of McNamara and Huang also teaches wherein the duration indicated by the duration indication information further comprises at least one of: a short interframe space between the first acknowledgement message frame and the retransmitted data frame; or a short interframe space between the retransmitted data frame and a second acknowledgement message frame corresponding to the retransmitted data frame. McNamara, figure 9 (“NAV(NACK)” includes a SIFS between the first NAC and the retransmitted data and between the retransmitted data and a second NACK).
Claims 72, 81, and 82 are rejected under 35 U.S.C. 103 as being unpatentable over McNamara in view of Huang (both of record) as applied to claim 14 above, and further in view of Lauer (of record and cited on PTO-892, dated 23 Jan 2025).
Regarding claims 72 and 81, the combination of McNamara and Huang teaches the methods according to claims 14 and 77, but does not explicitly teach “wherein in a case that the data frame comprises a plurality of data blocks, the first acknowledgement message frame is a block acknowledgement message frame, and the transmission duration of the retransmitted data frame comprises transmission duration for retransmitting n data blocks failing to be received among the plurality of data blocks, where n is a positive integer greater than or equal to 1, and less than or equal to a number of data blocks contained in the data frame.”
However, Lauer teaches “wherein in a case that the data frame comprises a plurality of data blocks (Lauer, ¶122 and figure 14A – MIMO frame includes a plurality of MAC frames), the first acknowledgement message frame is a block acknowledgement message frame (Lauer, ¶116), and the transmission duration of the retransmitted data frame comprises transmission duration for retransmitting n data blocks failing to be received among the plurality of data blocks, where n is a positive integer greater than or equal to 1, and less than or equal to a number of data blocks contained in the data frame.” Lauer, figure 14A and ¶¶122-123 (time-slotted ACK is contained in the header of each MAC frame and a SACK field can occur within a MAC frame either zero, once or multiple times [i.e. less than or equal to the number of frames]). At the time of the invention (pre-AIA ) or at the effective filing date of the invention (AIA ), it would have been obvious for one of ordinary skill in the art to implement MIMO technology, as taught by Lauer, within the WLAN access mechanism, taught by the combination of McNamara and Huang, in order to provide a flexible, multi-user system that can be employed for a host of communications. Id. at ¶60.
Regarding claim 82, the combination of McNamara, Huang, and Lauer also teaches wherein the duration indicated by the duration indication information further comprises a short interframe space between two adjacent data blocks among the data blocks. McNamara, figure 9 (each DATA has at least one SIFS between it and its adjunct DATA).
Claims 78 and 83 are rejected under 35 U.S.C. 103 as being unpatentable over McNamara in view of Huang (both of record) as applied to claim 14 above, and further in view of Habetha (US 2007/0297353).
Regarding claims 78 and 83, the combination of McNamara and Huang teaches the method of claim 77, the method of claim 81, and wherein in a case that the data frame is a unicast data frame (McNamara, figure 9 – “DATA” is sent from source to destination device [i.e. unicast]), determining the duration indication information in response to failed reception of the data frame. McNamara, figure 9 (duration of NAV(NACK) includes the retransmission of “DATA”).
The combination of McNamara and Huang does not explicitly teaches “wherein an expression of the duration indicated by the duration indication information comprises: 2*ACK+data frame length+2*SIFS, where 2*ACK represents transmission duration of the first acknowledgement message frame and transmission duration of a second acknowledgement message frame corresponding to the retransmitted data frame; the data frame length represents transmission duration for retransmitting the unicast data frame; 2*SIFS represents two short interframe spaces.” However, Habetha also teaches a multi-channel device that operates over multiple frequency bands. Habetha, ¶¶1-2 (device operates over at least two channels, where each channel is on a sub-band of a cell). Habetha teaches wherein in a case that the data frame is a unicast data frame (Habetha, figure 1 – “DATA” is sent from station 1 to station 2 [i.e. unicast]), . . . an expression of the duration indicated by the duration indication information comprises: 2*ACK+data frame length+2*SIFS, where 2*ACK represents transmission duration of the first acknowledgement message frame and transmission duration of a second acknowledgement message frame corresponding to the retransmitted data frame; the data frame length represents transmission duration for retransmitting the unicast data frame; 2*SIFS represents two short interframe spaces. Habetha, figure 1 (NAV set by station 6 includes two ACKs, at least one DATA, and at least two SIFS).
At the time of the invention (pre-AIA ) or at the effective filing date of the invention (AIA ), it would have been obvious for one of ordinary skill in the art to implement the channel access mechanism, taught by the combination of McNamara and Huang, for the multi-channel device that utilizes multiple frequency bands, as taught by Habetha, in order to increase bandwidth used by the device for transmission. Id. at ¶3.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN S LAMONT whose telephone number is (571)270-7514 and email address is benjamin.lamont@uspto.gov (see MPEP 502.03 for authorizing unsecure communication). The examiner can normally be reached M-F 7am to 3pm 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, Huy Vu can be reached on 571-272-3155. 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.
/Benjamin Lamont/Primary Examiner, Art Unit 2461