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 .
Introduction
The claims 1-20 are pending in this application. This is a non-final office action in response to Application Number 18/922,112 filed on 21 October 2024. The applicant of record is TP-Link Systems Inc. in Irvine, CA, USA and the inventors of record are Shuyu Shi, Xuefeng Niu, and Da Sun.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 18 January 2025 and 22 June 2025 were filed after the initial filing date of the instant application on 21 October 2024. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Specification
The abstract of the disclosure is objected to because it uses legal phraseology. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Interpretation
The claims have been considered according to the latest Patent Eligibility Guidelines and are considered eligible.
Allowable Subject Matter
Claims 6 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 8-11, 13-16, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Lee (WO 2024/144101 A1).
Regarding claim 1, Lee disclosed a wireless communication device (see Lee Fig. 1: wireless communication network including wireless communication devices), comprising:
one or more processors (see Lee [0053], Fig. 2 #51 processor);
a memory coupled to at least one of the processors (see Lee [0054], Fig. 2 #52 memory, #51 processor); and
a set of computer program instructions stored in the memory, which, when executed by at least one of the processors (see Lee Fig. 2 #52 memory, #51 processor; [0054]: memory stores instructions executable by processor), perform actions of:
receiving, from a peer wireless communication device, a Low Latency (LL) frame indication for one or more LL frames of a plurality of data frames to be communicated between the wireless communication device and the peer wireless communication device in a Block Acknowledgment (BA) session (see Lee [0088]: “A low latency (LL) packet may be a data unit to be transmit with minimal delay by an LL STA. The LL STA is the STA with LL packet to be transmitted. A LL packet may be a data unit arrived to the LL STA in the middle of TXOP. The LL STA may be TXOP holder or TXOP responder…” | Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.”; examiner notes that the LL frame indication corresponds to the LL data subfield included in the BAR control field of the BlockACKReq frame, i.e. MU BAR frame, sent from AP MLD to STA MLD1 of Fig. 8, wherein the LL data subfield uses a bitmap to indicate the SNs of the MPDUs corresponding to LL MPDUs or non-LL MPDUs within the data sent from AP MLD to STA MLD1 of Fig. 8 | Fig. 9: control frame format; [0094]: “The initial control frame may be a MU-BAR trigger frame. When an AP affiliated with an AP MLD sends a MU-BAR Trigger frame within a TXOP, the MU-BAR Trigger frame may include a STA affiliated with STA MLDs operating on the EMLSR links in the User Info fields of the MU-BAR Trigger frame. For example, User Info #1 indicates STA MLD1 and User Info #2 indicates STA MLD2.”; [0099]: “The MU-BAR Trigger frame can be used as an initial control frame within the TXOP in order to initiate an LL packet delivery to the STA MLD operating on the EMLSR mode.”; [0100]: “An ELMSR Initial Control subfield can be used to indicate whether the MU-BAR Trigger frame is the initial control frame for the STA operating in the EMLSR link. The ELMSR Initial Control subfield can be used to indicate that the indicated STA which is not the TXOP responder is a temporary recipient for the LL packet within the TXOP. The ELMSR Initial Control subfield may be included in the BAR Control field. The ELMSR Initial Control subfield may have one bit…” | Fig. 23, [0175]: MAC frame format to classify LL MPDU); and
transmitting, in response to determining a missing LL frame of the one or more LL frames based on the LL frame indication, a retransmission request frame to the peer wireless communication device including an indication of the missing LL frame (see Lee [0068]: “In order to optimize the system spectrum utilization and achieve better throughput performance, the IEEE 802.11be has defined multi-link operation (MLO) to support sending data frames concurrently on multiple links…MLO enables frame transmission and retransmission on any link regardless of the link of the initial transmission of the frame.” | Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 9: control frame format | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”; [0109]: “When an AP MLD receives a BA frame in which the LL Indication subfield is set to one, the AP MLD can send a Trigger frame to the STA MLD. Otherwise, the AP MLD cannot schedule additional frame transmission to the STA MLD…”; examiner notes that the retransmission request frame corresponds to Fig. 11’s BA frame and is communicated from STA MLD1 to AP MLD of Fig. 8, wherein the BA frame is known to indicate the missing status of each LL MPDU and non-LL MPDU included in the data communicated from AP MLD to the STA MLD1 of Fig. 8).
Regarding claim 2, Lee disclosed the wireless communication device of claim 1, wherein the set of computer program instructions stored in the memory, which, when executed by at least one of the processors, further perform actions of:
transmitting, to the peer wireless communication device, a BA frame indicating whether each of the plurality of data frames is successfully received for the BA session (see Lee Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 9: control frame format | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”; [0109]: “When an AP MLD receives a BA frame in which the LL Indication subfield is set to one, the AP MLD can send a Trigger frame to the STA MLD. Otherwise, the AP MLD cannot schedule additional frame transmission to the STA MLD…”).
Regarding claim 3, Lee disclosed the wireless communication device of claim 1, wherein:
the LL frame indication is a LL bitmap included in a LL status notification frame (see Lee Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 9: control frame format; [0183]: “As still another embodiment to classify LL MPDU, BlockAckReq frame and/or MU-BAR Trigger frame can contain an LL Data Indication subfield. As shown in FIG. 9, BlockAckReq frame and/or MU-BAR Trigger frame can include BAR control field and BAR information field. BlockAckReq frame and/or MU-BAR Trigger frame may include an LL Data Indication Present subfield in the BAR Control field and the LL Data Indication subfield in the BAR information field. For example, If the LL Data Indication Present subfield in the BAR Control field is set to 1, the BAR Information field contains the LL Data Indication subfield. The LL Data Indication subfield is the bitmap that specifies the sequence numbers of the MPDUs containing LL packets.” | Fig. 23, [0175]: MAC frame format to classify LL MPDU), and
wherein each of a plurality of bits of the LL bitmap associated with the plurality of data frames has a first value for identifying a corresponding data frame as a LL data frame (see Lee Fig. 9: control frame format; [0183]: “As still another embodiment to classify LL MPDU, BlockAckReq frame and/or MU-BAR Trigger frame can contain an LL Data Indication subfield. As shown in FIG. 9, BlockAckReq frame and/or MU-BAR Trigger frame can include BAR control field and BAR information field. BlockAckReq frame and/or MU-BAR Trigger frame may include an LL Data Indication Present subfield in the BAR Control field and the LL Data Indication subfield in the BAR information field. For example, If the LL Data Indication Present subfield in the BAR Control field is set to 1, the BAR Information field contains the LL Data Indication subfield. The LL Data Indication subfield is the bitmap that specifies the sequence numbers of the MPDUs containing LL packets.” | Fig. 23, [0175]: MAC frame format to classify LL MPDU; [0181]: “As another embodiment to classify LL MPDU, an LL subfield to indicate that the LL packet is contained can be defined in the CCMP Header. For example, first bit (B0) of Key ID octet can be used as the LL subfield. The LL subfield can be set to a first value (e.g. 1) if the Data contains the LL packet. Otherwise, the LL subfield is set to a second value (e.g. 0).”), or a second value for identifying the corresponding data frame as a non-LL data frame.
Regarding claim 8, Lee disclosed the wireless communication device of claim 1, wherein the plurality of data frames correspond to a plurality of MAC Protocol Data Units (MPDUs) (see Lee Fig. 24: multiple Aggregate MPDUs; Fig. 25: multiple Aggregate MPDUs | [0185]: “An Aggregate-MPDU (A-MPDU) includes one or more MPDUs. A STA that transmits a PPDU that contains one or more PSDUs, each of which contains an A-MPDU, constructs the A-MPDU(s).”).
Regarding claim 9, Lee disclosed the wireless communication device of claim 8, wherein the plurality of MPDUs are aggregated into an Aggregate MPDU (A-MPDU) (see Lee Fig. 24: multiple Aggregate MPDUs; Fig. 25: multiple Aggregate MPDUs | [0185]: “An Aggregate-MPDU (A-MPDU) includes one or more MPDUs. A STA that transmits a PPDU that contains one or more PSDUs, each of which contains an A-MPDU, constructs the A-MPDU(s).”).
Regarding claim 10, Lee disclosed the wireless communication device of claim 1, wherein:
the BA frame is transmitted by the wireless communication device in response to a BA request frame from the peer wireless communication device (see Lee Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 9: control frame format | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”; [0109]: “When an AP MLD receives a BA frame in which the LL Indication subfield is set to one, the AP MLD can send a Trigger frame to the STA MLD. Otherwise, the AP MLD cannot schedule additional frame transmission to the STA MLD…”; examiner notes that the BA request frame corresponds to the MU BAR frame sent from AP MLD to STA MLD1 of Fig. 8, which triggers the communication of Fig. 11’s BA frame that is sent from STA MLD1 to AP MLD of Fig. 8); or
the BA frame is transmitted by the wireless communication device after receiving the data packets without the BA request frame from the peer wireless communication device.
Regarding claim 11, Lee disclosed the wireless communication device of claim 2, wherein
the wireless communication device and the peer wireless communication device are established with multiple links (see Lee [0068]: “In order to optimize the system spectrum utilization and achieve better throughput performance, the IEEE 802.11be has defined multi-link operation (MLO) to support sending data frames concurrently on multiple links…MLO enables frame transmission and retransmission on any link regardless of the link of the initial transmission of the frame.” | Fig. 8: multiple links; [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.”), and
the plurality of data frames of the BA session corresponding to a Traffic Identifier (TID) are transmitted over a selected one of the established multiple links (see Lee [0069]: “An enabled link is a setup link of a non-AP MLD to which at least one traffic identifier (TID) is mapped either in downlink or in uplink. A disabled link is a setup link of a non-AP MLD to which no TID is mapped neither in downlink nor in uplink. A TID is any of the identifiers usable by higher layer entities to distinguish MAC service data units (MSDUs) to MAC entities that support quality of service (QoS) within the MAC data service.” | Fig. 8, [0092]: transmitting LL packet(s) between AP MLD and STA MLD1, MLD2 | Fig. 9: control frame format | Fig. 23, [0175]: MAC frame format to classify LL MPDU; [0180]: “A Low Latency TID subfield may indicate the TID and/or SCSID of the low latency traffic Flow. The stream classification service (SCS) identifier (SCSID) is a nonzero value chosen by the non-AP STA identifying the SCS stream. An Expedited Processing subfield may indicate whether the receiver can immediately process the LL packet and deliver to the upper layer even though at least one of the preceding MPDUs is not been successfully received yet. A LL Queue Size field may indicate the Queue Size of the LL.” | [0184]: “Hereinafter, how to construct A-MPDU for LL application is proposed.”; [0185]: “An Aggregate-MPDU (A-MPDU) includes one or more MPDUs…”; [0186]: “First, An A-MPDU pre-EOF padding is constructed for each user from any of the following: (i) A-MPDU subframes constructed from the MPDUs available for transmission that have a TID value that maps to the primary AC, and (ii) A-MPDU subframes with 0 in the MPDU Length field and 0 in the EOF field.” ), and
wherein the BA frame indicates whether each of the plurality of data frames for the BA session is successfully received over the selected one of the established multiple links (see Lee Fig. 9: control frame format; [0183]: “As still another embodiment to classify LL MPDU, BlockAckReq frame and/or MU-BAR Trigger frame can contain an LL Data Indication subfield. As shown in FIG. 9, BlockAckReq frame and/or MU-BAR Trigger frame can include BAR control field and BAR information field. BlockAckReq frame and/or MU-BAR Trigger frame may include an LL Data Indication Present subfield in the BAR Control field and the LL Data Indication subfield in the BAR information field. For example, If the LL Data Indication Present subfield in the BAR Control field is set to 1, the BAR Information field contains the LL Data Indication subfield. The LL Data Indication subfield is the bitmap that specifies the sequence numbers of the MPDUs containing LL packets.” | Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”; [0109]: “When an AP MLD receives a BA frame in which the LL Indication subfield is set to one, the AP MLD can send a Trigger frame to the STA MLD. Otherwise, the AP MLD cannot schedule additional frame transmission to the STA MLD…” | examiner notes that the TXOP of Fig. 8 corresponds to a single BA session associated with a TID shared by MPDUs of low latency traffic and MPDUs of non-LL traffic, whose communication over a Link1 of Fig. 8 triggers the communication of a BA frame over Link1, wherein the Link1 is a link selected within the set of established links of Fig. 8 and wherein the BA frame is known to indicate the missing status of each LL MPDU and non-LL MPDU included in the data sent from AP MLD to STA MLD1 of Fig. 8).
Regarding claim 13, Lee disclosed the wireless communication device of claim 1, wherein:
the wireless communication device is an Access Point (AP) and the peer wireless communication device is a non-AP station; or the wireless communication device is a non-AP station and the peer wireless communication device is an AP (see Lee Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.”).
Regarding claim 14, the claim contains the limitations, substantially as claimed, as described in claim 1 above. Examiner notes that claim 1 describes a wireless communication device performing a method whereas claim 14 describes a method implemented in a wireless communication device. Lee disclosed, as recited in claim 14: A method for wireless communication, the method implemented in a wireless communication device (see Lee Fig. 1: wireless communication network including wireless communication devices | Fig. 2 #52 memory, #51 processor; [0054]: memory stores instructions executable by processor) and comprising:
receiving, from a peer wireless communication device, a Low Latency (LL) frame indication for one or more LL frames of a plurality of data frames to be communicated between the wireless communication device and the peer wireless communication device in a Block Acknowledgment (BA) session (see Lee [0088]: “A low latency (LL) packet may be a data unit to be transmit with minimal delay by an LL STA. The LL STA is the STA with LL packet to be transmitted. A LL packet may be a data unit arrived to the LL STA in the middle of TXOP. The LL STA may be TXOP holder or TXOP responder…” | Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.”; examiner notes that the LL frame indication corresponds to the LL data subfield included in the BAR control field of the BlockACKReq frame, i.e. MU BAR frame, sent from AP MLD to STA MLD1 of Fig. 8, wherein the LL data subfield uses a bitmap to indicate the SNs of the MPDUs corresponding to LL MPDUs or non-LL MPDUs within the data sent from AP MLD to STA MLD1 of Fig. 8 | Fig. 9: control frame format; [0094]: “The initial control frame may be a MU-BAR trigger frame. When an AP affiliated with an AP MLD sends a MU-BAR Trigger frame within a TXOP, the MU-BAR Trigger frame may include a STA affiliated with STA MLDs operating on the EMLSR links in the User Info fields of the MU-BAR Trigger frame. For example, User Info #1 indicates STA MLD1 and User Info #2 indicates STA MLD2.”; [0099]: “The MU-BAR Trigger frame can be used as an initial control frame within the TXOP in order to initiate an LL packet delivery to the STA MLD operating on the EMLSR mode.”; [0100]: “An ELMSR Initial Control subfield can be used to indicate whether the MU-BAR Trigger frame is the initial control frame for the STA operating in the EMLSR link. The ELMSR Initial Control subfield can be used to indicate that the indicated STA which is not the TXOP responder is a temporary recipient for the LL packet within the TXOP. The ELMSR Initial Control subfield may be included in the BAR Control field. The ELMSR Initial Control subfield may have one bit…” | Fig. 23, [0175]: MAC frame format to classify LL MPDU); and
transmitting, in response to determining a missing LL frame of the one or more LL frames based on the LL frame indication, a retransmission request frame to the peer wireless communication device including an indication of the missing LL frame (see Lee [0068]: “In order to optimize the system spectrum utilization and achieve better throughput performance, the IEEE 802.11be has defined multi-link operation (MLO) to support sending data frames concurrently on multiple links…MLO enables frame transmission and retransmission on any link regardless of the link of the initial transmission of the frame.” | Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 9: control frame format | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”; [0109]: “When an AP MLD receives a BA frame in which the LL Indication subfield is set to one, the AP MLD can send a Trigger frame to the STA MLD. Otherwise, the AP MLD cannot schedule additional frame transmission to the STA MLD…”; examiner notes that the retransmission request frame corresponds to Fig. 11’s BA frame and is communicated from STA MLD1 to AP MLD of Fig. 8, wherein the BA frame is known to indicate the missing status of each LL MPDU and non-LL MPDU included in the data communicated from AP MLD to the STA MLD1 of Fig. 8).
Regarding claim 15, the claim contains the limitations, substantially as claimed, as described in claim 2 above. Lee disclosed, as recited in claim 15: The method of claim 14, further comprising: transmitting, to the peer wireless communication device, a BA frame indicating whether each of the plurality of data frames is successfully received for the BA session (see Lee Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 9: control frame format | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”; [0109]: “When an AP MLD receives a BA frame in which the LL Indication subfield is set to one, the AP MLD can send a Trigger frame to the STA MLD. Otherwise, the AP MLD cannot schedule additional frame transmission to the STA MLD…”).
Regarding claim 16, the claim contains the limitations, substantially as claimed, as described in claim 3 above. Lee disclosed, as recited in claim 16: The method of claim 14, wherein:
the LL frame indication is a LL bitmap included in a LL status notification frame (see Lee Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 9: control frame format; [0183]: “As still another embodiment to classify LL MPDU, BlockAckReq frame and/or MU-BAR Trigger frame can contain an LL Data Indication subfield. As shown in FIG. 9, BlockAckReq frame and/or MU-BAR Trigger frame can include BAR control field and BAR information field. BlockAckReq frame and/or MU-BAR Trigger frame may include an LL Data Indication Present subfield in the BAR Control field and the LL Data Indication subfield in the BAR information field. For example, If the LL Data Indication Present subfield in the BAR Control field is set to 1, the BAR Information field contains the LL Data Indication subfield. The LL Data Indication subfield is the bitmap that specifies the sequence numbers of the MPDUs containing LL packets.” | Fig. 23, [0175]: MAC frame format to classify LL MPDU), and
wherein each of a plurality of bits of the LL bitmap associated with the plurality of data frames has a first value for identifying a corresponding data frame as a LL data frame (see Lee Fig. 9: control frame format; [0183]: “As still another embodiment to classify LL MPDU, BlockAckReq frame and/or MU-BAR Trigger frame can contain an LL Data Indication subfield. As shown in FIG. 9, BlockAckReq frame and/or MU-BAR Trigger frame can include BAR control field and BAR information field. BlockAckReq frame and/or MU-BAR Trigger frame may include an LL Data Indication Present subfield in the BAR Control field and the LL Data Indication subfield in the BAR information field. For example, If the LL Data Indication Present subfield in the BAR Control field is set to 1, the BAR Information field contains the LL Data Indication subfield. The LL Data Indication subfield is the bitmap that specifies the sequence numbers of the MPDUs containing LL packets.” | Fig. 23, [0175]: MAC frame format to classify LL MPDU; [0181]: “As another embodiment to classify LL MPDU, an LL subfield to indicate that the LL packet is contained can be defined in the CCMP Header. For example, first bit (B0) of Key ID octet can be used as the LL subfield. The LL subfield can be set to a first value (e.g. 1) if the Data contains the LL packet. Otherwise, the LL subfield is set to a second value (e.g. 0).”), or a second value for identifying the corresponding data frame as a non-LL data frame.
Regarding claim 20, the claim contains the limitations, substantially as claimed, as described in claim 1 above. Examiner notes that claim 1 describes a wireless communication device performing a method whereas claim 20 describes a computer program product executable by a wireless communication device. Lee disclosed, as recited in claim 20: A computer program product for wireless communication, the computer program product comprising a non-transitory computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor of a wireless communication device (see Lee Fig. 1: wireless communication network including wireless communication devices | Fig. 2 #52 memory, #51 processor; [0054]: memory stores instructions executable by processor) to cause the processor to:
receive, from a peer wireless communication device, a Low Latency (LL) frame indication for one or more LL frames of a plurality of data frames to be communicated between the wireless communication device and the peer wireless communication device in a Block Acknowledgment (BA) session (see Lee [0088]: “A low latency (LL) packet may be a data unit to be transmit with minimal delay by an LL STA. The LL STA is the STA with LL packet to be transmitted. A LL packet may be a data unit arrived to the LL STA in the middle of TXOP. The LL STA may be TXOP holder or TXOP responder…” | Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.”; examiner notes that the LL frame indication corresponds to the LL data subfield included in the BAR control field of the BlockACKReq frame, i.e. MU BAR frame, sent from AP MLD to STA MLD1 of Fig. 8, wherein the LL data subfield uses a bitmap to indicate the SNs of the MPDUs corresponding to LL MPDUs or non-LL MPDUs within the data sent from AP MLD to STA MLD1 of Fig. 8 | Fig. 9: control frame format; [0094]: “The initial control frame may be a MU-BAR trigger frame. When an AP affiliated with an AP MLD sends a MU-BAR Trigger frame within a TXOP, the MU-BAR Trigger frame may include a STA affiliated with STA MLDs operating on the EMLSR links in the User Info fields of the MU-BAR Trigger frame. For example, User Info #1 indicates STA MLD1 and User Info #2 indicates STA MLD2.”; [0099]: “The MU-BAR Trigger frame can be used as an initial control frame within the TXOP in order to initiate an LL packet delivery to the STA MLD operating on the EMLSR mode.”; [0100]: “An ELMSR Initial Control subfield can be used to indicate whether the MU-BAR Trigger frame is the initial control frame for the STA operating in the EMLSR link. The ELMSR Initial Control subfield can be used to indicate that the indicated STA which is not the TXOP responder is a temporary recipient for the LL packet within the TXOP. The ELMSR Initial Control subfield may be included in the BAR Control field. The ELMSR Initial Control subfield may have one bit…” | Fig. 23, [0175]: MAC frame format to classify LL MPDU); and
transmit, in response to determining a missing LL frame of the one or more LL frames based on the LL frame indication, a retransmission request frame to the peer wireless communication device including an indication of the missing LL frame (see Lee [0068]: “In order to optimize the system spectrum utilization and achieve better throughput performance, the IEEE 802.11be has defined multi-link operation (MLO) to support sending data frames concurrently on multiple links…MLO enables frame transmission and retransmission on any link regardless of the link of the initial transmission of the frame.” | Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 9: control frame format | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”; [0109]: “When an AP MLD receives a BA frame in which the LL Indication subfield is set to one, the AP MLD can send a Trigger frame to the STA MLD. Otherwise, the AP MLD cannot schedule additional frame transmission to the STA MLD…”; examiner notes that the retransmission request frame corresponds to Fig. 11’s BA frame and is communicated from STA MLD1 to AP MLD of Fig. 8, wherein the BA frame is known to indicate the missing status of each LL MPDU and non-LL MPDU included in the data communicated from AP MLD to the STA MLD1 of Fig. 8).
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 4-5 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Lee as applied to claims 3 and 16 above, and further in view of Lu et al. (WO 2025/111999).
Regarding claim 4, Lee disclosed the invention, substantially as claimed, as described in the wireless communication device of claim 3, wherein the set of computer program instructions stored in the memory, which, when executed by at least one of the processors, further perform actions of:
performing out-of-order delivery for one or more received data frames of the plurality of data frames from a current layer to an upper layer of the wireless communication device (see Lee Fig. 22, [0169]: “FIG. 22 shows an example of Head-of-line (HOL) blocking issue.”; [0171]: “For example, because the MPDU1 and MPDU2 failed, the MPDU3 to MPDU6 can't be processed by the upper layer even though the traffic flow is different with MPDU1 and MPDU2 (i.e., reordering is acceptable).”; [0173]: “In order to address a HOL blocking issue, the MPDUs containing LL packet are encrypted with the separate PN sequence for LL application. The MAC header and/or CCMP header may include information (i.e. a field) to indicate the MPDU contains the LL packet and the MPDU is encrypted with the separate PN sequence for LL application.”; [0174]: “The receiver also maintains the separate Replay Counter for LL application. If the receiver determines that the received MPDU contains LL packet, the receiver can process and deliver it to the upper layer before receiving all preceding MPDUs if the expedited processing is permitted by the source or destination.”); and
for the received data frames, maintaining a packet number (PN) window bitmap (see Lu combination below),
wherein each of a plurality of bits of the PN window bitmap (see Lu combination below) associated with the plurality of data frames has a first value for indicating that a corresponding data frame has been received and delivered to the upper layer, or a second value for indicating that the corresponding data frame has not been received and delivered to the upper layer (see Lee Fig. 9: control frame format; [0183]: “As still another embodiment to classify LL MPDU, BlockAckReq frame and/or MU-BAR Trigger frame can contain an LL Data Indication subfield. As shown in FIG. 9, BlockAckReq frame and/or MU-BAR Trigger frame can include BAR control field and BAR information field. BlockAckReq frame and/or MU-BAR Trigger frame may include an LL Data Indication Present subfield in the BAR Control field and the LL Data Indication subfield in the BAR information field. For example, If the LL Data Indication Present subfield in the BAR Control field is set to 1, the BAR Information field contains the LL Data Indication subfield. The LL Data Indication subfield is the bitmap that specifies the sequence numbers of the MPDUs containing LL packets.” | Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”; [0109]: “When an AP MLD receives a BA frame in which the LL Indication subfield is set to one, the AP MLD can send a Trigger frame to the STA MLD. Otherwise, the AP MLD cannot schedule additional frame transmission to the STA MLD…” | examiner notes the type of each missed data frame in the data sent from AP MLD to STA MLD1 of Fig. 8 is determined to an LL data frame or a non-LL data frame based on the bitmap of the LL data subfield included in the BAR control field of BlockACKReq frame, i.e. MU BAR frame sent from AP MLD to STA MLD1 of Fig. 8 during the BA session corresponding to the TXOP of Fig. 8).
Lee did not explicitly disclose “for the received data frames, maintaining a packet number (PN) window bitmap” and that the bitmap used to indicate if a corresponding data frame has or has not been received is a “PN window bitmap”.
Examiner notes that PN window bitmaps are part of a standard measure in the IEEE block acknowledgement (BA) and are known to be able to be used to solve a head-of-line blocking problem during the reception of a set of data frames. However in a related art, Lu disclosed solving a HOL blocking problem using out-of-order transmission of data packets for a specific flow identifier and that the PN space is used to distinguish between out-of-order frames and in-order frames (see Lu [0077]). Fig. 4 illustrates out-of-order delivery in which a BA frame indicating is sent every time the receiver receives multiple MPDUs to indicate whether or not each MPDU has been correctly received (see Lu [0079], Fig. 4). A PN window bitmap is used to identify which ones have and have not been received (see Lu [0080]). A solution to the head-of-line congestion problem makes use of an independent PN sequence and replay counter for LL packets (see Lu [0081]). Fig. 6 also illustrates out-of-order transmission (see Lu Fig. 6, [0095]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lee and Lu to further clarify how to solve HOL blocking problems using PN window bitmap. Expanding on Lee’s solution to the HOL blocking problem to make use of Lu’s PN window bitmap when solving the HOL blocking problem would facilitate earlier processing of LL packets while continuing to support replay detection of other packets in the same TID (see Lu [0081]).
Regarding claim 5, Lee-Lu disclosed the wireless communication device of claim 4, wherein the missing LL frame of the one or more LL frames is determined based on the LL bitmap (see Lee Fig. 9: control frame format; [0183]: “As still another embodiment to classify LL MPDU, BlockAckReq frame and/or MU-BAR Trigger frame can contain an LL Data Indication subfield. As shown in FIG. 9, BlockAckReq frame and/or MU-BAR Trigger frame can include BAR control field and BAR information field. BlockAckReq frame and/or MU-BAR Trigger frame may include an LL Data Indication Present subfield in the BAR Control field and the LL Data Indication subfield in the BAR information field. For example, If the LL Data Indication Present subfield in the BAR Control field is set to 1, the BAR Information field contains the LL Data Indication subfield. The LL Data Indication subfield is the bitmap that specifies the sequence numbers of the MPDUs containing LL packets.” | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”) and the PN window bitmap (see Lu Fig. 4, [0079]: illustrates out-of-order delivery in which a BA frame indicating is sent every time the receiver receives multiple MPDUs to indicate whether or not each MPDU has been correctly received; [0080]: using PN window bitmap to identify which ones have and have not been received | Fig. 5, [0082]: another example of out-of-order delivery including a bitmap that indicates if one of the MPDUs was not received | Fig. 6, [0093]: another example of out-of-order transmission making use of PNs, SNs, TIDs, and other parameters; [0087]: the solution in Figure 6 resolves a head-of-line blocking problem by making use of [0088] a data unit differentiation transmission indication method, [0089] SN allocation and processing mechanism to differentiate QoS transmission requirements, and also [0090] PN allocation and processing mechanism to distinguish QoS transmission requirements).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lee and Lu to further clarify how to solve HOL blocking problems using PN window bitmap. Expanding on Lee’s solution to the HOL blocking problem to make use of Lu’s PN window bitmap when solving the HOL blocking problem would facilitate earlier processing of LL packets while continuing to support replay detection of other packets in the same TID (see Lu [0081]).
Regarding claim 17, the claim contains the limitations, substantially as claimed, as described in claim 4 above. Lee disclosed, as recited in claim 17: The method of claim 16, further comprising:
performing out-of-order delivery for one or more received data frames of the plurality of data frames from a current layer to an upper layer of the wireless communication device (see Lee Fig. 22, [0169]: “FIG. 22 shows an example of Head-of-line (HOL) blocking issue.”; [0171]: “For example, because the MPDU1 and MPDU2 failed, the MPDU3 to MPDU6 can't be processed by the upper layer even though the traffic flow is different with MPDU1 and MPDU2 (i.e., reordering is acceptable).”; [0173]: “In order to address a HOL blocking issue, the MPDUs containing LL packet are encrypted with the separate PN sequence for LL application. The MAC header and/or CCMP header may include information (i.e. a field) to indicate the MPDU contains the LL packet and the MPDU is encrypted with the separate PN sequence for LL application.”; [0174]: “The receiver also maintains the separate Replay Counter for LL application. If the receiver determines that the received MPDU contains LL packet, the receiver can process and deliver it to the upper layer before receiving all preceding MPDUs if the expedited processing is permitted by the source or destination.”); and
for the received data frames, maintaining a packet number (PN) window bitmap (see Lu combination below),
wherein each of a plurality of bits of the PN window bitmap (see Lu combination below) associated with the plurality of data frames has a first value for indicating that a corresponding data frame has been received and delivered to the upper layer, or a second value for indicating that the corresponding data frame has not been received and delivered to the upper layer (see Lee Fig. 9: control frame format; [0183]: “As still another embodiment to classify LL MPDU, BlockAckReq frame and/or MU-BAR Trigger frame can contain an LL Data Indication subfield. As shown in FIG. 9, BlockAckReq frame and/or MU-BAR Trigger frame can include BAR control field and BAR information field. BlockAckReq frame and/or MU-BAR Trigger frame may include an LL Data Indication Present subfield in the BAR Control field and the LL Data Indication subfield in the BAR information field. For example, If the LL Data Indication Present subfield in the BAR Control field is set to 1, the BAR Information field contains the LL Data Indication subfield. The LL Data Indication subfield is the bitmap that specifies the sequence numbers of the MPDUs containing LL packets.” | Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.” | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”; [0109]: “When an AP MLD receives a BA frame in which the LL Indication subfield is set to one, the AP MLD can send a Trigger frame to the STA MLD. Otherwise, the AP MLD cannot schedule additional frame transmission to the STA MLD…” | examiner notes the type of each missed data frame in the data sent from AP MLD to STA MLD1 of Fig. 8 is determined to an LL data frame or a non-LL data frame based on the bitmap of the LL data subfield included in the BAR control field of BlockACKReq frame, i.e. MU BAR frame sent from AP MLD to STA MLD1 of Fig. 8 during the BA session corresponding to the TXOP of Fig. 8).
Lee did not explicitly disclose “for the received data frames, maintaining a packet number (PN) window bitmap” and that the bitmap used to indicate if a corresponding data frame has or has not been received is a “PN window bitmap”.
Examiner notes that PN window bitmaps are part of a standard measure in the IEEE block acknowledgement (BA) and are known to be able to be used to solve a head-of-line blocking problem during the reception of a set of data frames. However in a related art, Lu disclosed solving a HOL blocking problem using out-of-order transmission of data packets for a specific flow identifier and that the PN space is used to distinguish between out-of-order frames and in-order frames (see Lu [0077]). Fig. 4 illustrates out-of-order delivery in which a BA frame indicating is sent every time the receiver receives multiple MPDUs to indicate whether or not each MPDU has been correctly received (see Lu [0079], Fig. 4). A PN window bitmap is used to identify which ones have and have not been received (see Lu [0080]). A solution to the head-of-line congestion problem makes use of an independent PN sequence and replay counter for LL packets (see Lu [0081]). Fig. 6 also illustrates out-of-order transmission (see Lu Fig. 6, [0095]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lee and Lu to further clarify how to solve HOL blocking problems using PN window bitmap. Expanding on Lee’s solution to the HOL blocking problem to make use of Lu’s PN window bitmap when solving the HOL blocking problem would facilitate earlier processing of LL packets while continuing to support replay detection of other packets in the same TID (see Lu [0081]).
Regarding claim 18, the claim contains the limitations, substantially as claimed, as described in claim 5 above. Lee-Lu disclosed, as recited in claim 18: The method of claim 17, wherein the missing LL frame of the one or more LL frames is determined based on the LL bitmap (see Lee Fig. 9: control frame format; [0183]: “As still another embodiment to classify LL MPDU, BlockAckReq frame and/or MU-BAR Trigger frame can contain an LL Data Indication subfield. As shown in FIG. 9, BlockAckReq frame and/or MU-BAR Trigger frame can include BAR control field and BAR information field. BlockAckReq frame and/or MU-BAR Trigger frame may include an LL Data Indication Present subfield in the BAR Control field and the LL Data Indication subfield in the BAR information field. For example, If the LL Data Indication Present subfield in the BAR Control field is set to 1, the BAR Information field contains the LL Data Indication subfield. The LL Data Indication subfield is the bitmap that specifies the sequence numbers of the MPDUs containing LL packets.” | Fig. 11: BlockAck frame format; [0107]: “The BA frame can include an LL indication subfield to indicate the presence of the LL packet. During a TXOP, if an LL packet is arrived at a STA MLD, the STA MLD can indicate the presence of the LL packet in the BA Control field in the BA frame which is a control response frame.”; [0108]: “The BA Control field may include the LL Indication subfield which can indicate whether the LL packet is arrived at a STA MLD. The LL indication subfield can have one bit. For example, the LL indication subfield may be set to one (or zero) when the LL packet is present.”) and the PN window bitmap (see Lu Fig. 4, [0079]: illustrates out-of-order delivery in which a BA frame indicating is sent every time the receiver receives multiple MPDUs to indicate whether or not each MPDU has been correctly received; [0080]: using PN window bitmap to identify which ones have and have not been received | Fig. 5, [0082]: another example of out-of-order delivery including a bitmap that indicates if one of the MPDUs was not received | Fig. 6, [0093]: another example of out-of-order transmission making use of PNs, SNs, TIDs, and other parameters; [0087]: the solution in Figure 6 resolves a head-of-line blocking problem by making use of [0088] a data unit differentiation transmission indication method, [0089] SN allocation and processing mechanism to differentiate QoS transmission requirements, and also [0090] PN allocation and processing mechanism to distinguish QoS transmission requirements).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lee and Lu to further clarify how to solve HOL blocking problems using PN window bitmap. Expanding on Lee’s solution to the HOL blocking problem to make use of Lu’s PN window bitmap when solving the HOL blocking problem would facilitate earlier processing of LL packets while continuing to support replay detection of other packets in the same TID (see Lu [0081]).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Lee as applied to claim 1 above, and further in view of Cordeiro et al. (U.S. Patent Publication 2014/0126478).
Regarding claim 7, Lee disclosed the invention, substantially as claimed, as described in the wireless communication device of claim 1, but did not explicitly disclose the entirety of the following limitations:
the plurality of data frames are transmitted by the peer wireless communication device to the wireless communication device at an interval of a Short Interframe Space (SIFS) (see Cordeiro combination below); and
the retransmission request frame is transmitted by the wireless communication device to the peer wireless communication device at an interval shorter than the SIFS after determining the missing LL frame (see Cordeiro combination below).
Examiner notes that the specific retransmission interval to be used is a matter of implementation choice, however in a related art, Cordeiro disclosed retransmission of PSDUs based on SIFS and RIFS intervals (see Cordeiro Fig. 7). As illustrated in Figure 7, multiple PSDUs are transmitted and a BA includes fields for acknowledging whether or not each of the multiple PSDUs was received (see Cordeiro Fig. 7, [0036]). The BAs are transmitted according to a short interframe space (SIFS) or a reduced interframe space (RIFS) to reduce interference between multiple BAs (see Cordeiro [0037]). Examiner notes that the RIFS is smaller than the SIFS.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lee and Cordeiro to further clarify when to retransmit frames. Modifying Lee’s retransmission based on Cordeiro’s retransmission would clarify that retransmission is based on SIFS intervals. Incorporating Cordeiro’s teachings would improve overall efficiency when using aggregated protocols (see Cordeiro [0035]).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Lee as applied to claim 2 above, and further in view of Kakani (U.S. Patent Publication 2010/0153807).
Regarding claim 12, Lee disclosed the invention, substantially as claimed, as described in the wireless communication device of claim 2 above, wherein:
a Power-Save Multi-Poll (PSMP) scheduling mode is used for communications between the wireless communication device and the peer wireless communication device, and wherein multiple BA sessions corresponding to multiple Traffic Identifiers (TIDs) are established (see Kakani combination below),
wherein for each BA session of the multiple BA sessions, the LL frame indication for one or more LL frames for the BA session is transmitted from the peer wireless communication device to the wireless communication device (see Lee [0088]: “A low latency (LL) packet may be a data unit to be transmit with minimal delay by an LL STA. The LL STA is the STA with LL packet to be transmitted. A LL packet may be a data unit arrived to the LL STA in the middle of TXOP. The LL STA may be TXOP holder or TXOP responder…” | Fig. 8, [0092]: “AP MLD is a TXOP holder and STA MLD1 is a TXOP responder. When LL packet for STA MLD2 which is not TXOP responder is arrived at AP MLD, the AP MLD can send an initial control frame to STA MLD1 and STA MLD2 in the middle of TXOP. When a TXOP holder has LL packet intended to a non-TXOP responder, the TXOP holder can send a initial control frame to a TXOP responder and the non-TXOP responder in the middle of TXOP.”; examiner notes that the LL frame indication corresponds to the LL data subfield included in the BAR control field of the BlockACKReq frame, i.e. MU BAR frame, sent from AP MLD to STA MLD1 of Fig. 8, wherein the LL data subfield uses a bitmap to indicate the SNs of the MPDUs corresponding to LL MPDUs or non-LL MPDUs within the data sent from AP MLD to STA MLD1 of Fig. 8 | Fig. 9: control frame format; [0094]: “The initial control frame may be a MU-BAR trigger frame. When an AP affiliated with an AP MLD sends a MU-BAR Trigger frame within a TXOP, the MU-BAR Trigger frame may include a STA affiliated with STA MLDs operating on the EMLSR links in the User Info fields of the MU-BAR Trigger frame. For example, User Info #1 indicates STA MLD1 and User Info #2 indicates STA MLD2.”; [0099]: “The MU-BAR Trigger frame can be used as an initial control frame within the TXOP in order to initiate an LL packet delivery to the STA MLD operating on the EMLSR mode.”; [0100]: “An ELMSR Initial Control subfield can be used to indicate whether the MU-BAR Trigger frame is the initial control frame for the STA operating in the EMLSR link. The ELMSR Initial Control subfield can be used to indicate that the indicated STA which is not the TXOP responder is a temporary recipient for the LL packet within the TXOP. The ELMSR Initial Control subfield may be included in the BAR Control field. The ELMSR Initial Control subfield may have one bit…” | Fig. 23, [0175]: MAC frame format to classify LL MPDU).
Lee did not explicitly disclose “a Power-Save Multi-Poll (PSMP) scheduling mode is used for communications between the wireless communication device and the peer wireless communication device, and wherein multiple BA sessions corresponding to multiple Traffic Identifiers (TIDs) are established”. However in a related art, Kakani disclosed a Power-Save Multi-Poll (PSMP) scheduling mode (see Kakani [0077], Fig. 6) is used to trigger a receiving STA of a multicast group for sending a BA (see Kakani [0079], Fig. 6) in response to the reception of multiple data frames (see Kakani [0075], Fig. 6) associated with multiple BA sessions corresponding to different TIDs (see Kakani [0078], Fig. 6) and different receiving STAs of the multicast group (see Kakani Fig. 6, [0081]). Retransmissions occur based on the BAs (see Kakani [0082]) in a variety of scenarios (see Kakani [0085]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lee and Kakani to further clarify how to establish BA sessions. Modifying Lee’s BA session with Kakani’s BA sessions would clarify how to send BAs in a multicast session. Incorporating Kakani’s teachings would facilitate a reliable multicast transmission (see Kakani [0073]
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Angela Widhalm de Rodriguez whose telephone number is (571)272-1035. The examiner can normally be reached M-F: 6am-2:30pm 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, Nicholas Taylor can be reached at (571)272-3889. 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.
/ANGELA WIDHALM DE RODRIGUEZ/ Examiner, Art Unit 2443
Prosecution Insights