DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to remarks filed 02/09/2026.
Claims 1-7 and 9-11 are pending and presented for examination. Claims 1 and 5 are amended. No claims are cancelled or added.
Response to Amendment
Objections to Drawings, figures 12-16, are withdrawn.
The reply filed on 02/09/2026 is not fully responsive to the prior Office action because of the following omission(s) or matter(s): The IDS for the application does not include the list of references of the specification as required by 37 CFR 1.98(b), see Non-Final Office Action, filed 06/02/2025, pg. 2 item 5. See 37 CFR 1.111. Since the above-mentioned reply appears to be bona fide, applicant is given a shortened statutory period of TWO (2) MONTHS from the mailing date of this notice within which to supply the omission or correction in order to avoid abandonment. EXTENSIONS OF THIS TIME PERIOD MAY BE GRANTED UNDER 37 CFR 1.136(a), but in no case can any extension carry the date for reply to this letter beyond the maximum period of SIX MONTHS set by statute (35 U.S.C. 133).
Information Disclosure Statement
The listing of references in the specification is not a proper information disclosure statement. The specification discloses various research and findings by 3GPP in Rel-15, Rel-16, and Rel-17 including references to TR 38.874 and RAN2 workgroup. Various portions of TR 38.874 and TS 38.300 are also found in figures 13-16 of the drawings. 37 CFR 1.98(b) requires a list of all patents, publications, or other information submitted for consideration by the Office, and MPEP § 609.04(a) states, "the list may not be incorporated into the specification but must be submitted in a separate paper." Therefore, unless the references have been cited by the examiner on form PTO-892, they have not been considered.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-7 and 9-11 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Tao et al. (US 20210075547 A1, hereinafter “Tao”).
RE Claim 1, Tao discloses:
A communication control method comprising:
by a Radio Link Control (RLC) entity of a communication apparatus being either of a user equipment or a relay node (RLC layer has an AM RLC entity, Acknowledge Mode RLC. ¶0042, Fig. 3; User equipment, UE. ¶¶0091, 0126, Fig. 16, Fig. 19; One or more intermediate, relay, IAB nodes for multi-hop traffic in 5G NR as well as LTE relay. ¶0096;), transmitting a data packet a donor base station via a parent node of the communication apparatus and then receiving a first acknowledgment from the parent node (UE transmits data packets towards the end node, the donor base station, via the IAM wireless backhaul, the parent node. UE receives a reception feedback, first acknowledgement, regarding those transmitted data packets in the form of positive and/or negative acknowledgements. ¶0103, Fig. 18;),
the first acknowledgement indicating that the data packet has been received by the parent node (UE transmits data packets towards the end node, the donor base station, via the IAM wireless backhaul which is an intermediate IAB node, the parent node. UE receives a reception feedback, first acknowledgement, regarding those transmitted data packets in the form of positive and/or negative acknowledgements. ¶0103, Fig. 18;);
by the RLC entity, updating a transmission window managed at the RLC entity in response to receiving the first acknowledgment from the parent node (RLC entity. ¶¶0040-0042, Fig. 3; The transmitting side, UE, of an RLC entity maintains a transmitting window to control (and limit) the transmission of RLC PDUs. ¶0043, Fig. 4; );
receiving a second acknowledgement from the parent node subsequent to receiving the first acknowledgement, the second acknowledgement indicating that the data packet has been received by the donor base station (Examiner interpreted as a person of ordinary skill at the time of invention would understand that an E2E or HBH ARQ method still requires an initial MAC/RLC ACK at the initial IAB node, the first access or parent node, to the UE. Initial ACK is required here to manage wireless link variations and successful radio transmission to access node (acting as gNB for UE) for entry into an IAB network. In addition, Claim 1 recites limitations applied to “a communication apparatus being either of a user equipment or a relay node”, and thus may be interpreted as ‘a UE’. UE transmits data packets towards the end node, the donor base station, via the IAM wireless backhaul which is an intermediate IAB node, the parent node. UE receives a reception feedback, first acknowledgement, regarding those transmitted data packets in the form of positive and/or negative acknowledgements. ¶0103, Fig. 18; After the initial ACK, a first ACK, when the IAB network is configured for E2E method then the next ACK, a second ACK, comes from the end point, donor node, to the UE ¶¶0100-0102, 0104; The second acknowledgement received by the UE is from the donor node as shown in fig. 20 and paragraphs [0128-0132] with solution implemented by applying the method implemented in an E2E architecture per paragraphs [0100-0104].); and
by the communication apparatus, controlling, in response to receiving a second acknowledgment from the parent node subsequent to receiving the first acknowledgment, retransmission related to the data packet based on the second acknowledgment (UE transmits data packets towards the end node, the donor base station, via the IAM wireless backhaul which is an intermediate IAB node, the parent node. UE receives a reception feedback, first acknowledgement, regarding those transmitted data packets in the form of positive and/or negative acknowledgements. ¶0103, Fig. 18; UE data packets are transmitted to the intermediate IAB node. Intermediate IAB node, parent node, forwards data packets to the IAB donor node, donor base station. End-to-End ARQ, E2E ARQ, has the IAB donor node, donor base station, transmits the reception feedback, second acknowledgement, to the source node, UE, of the data traffic route. The data packets are forwarded by the intermediate node, the parent node, to the donor node which is the entity determined and transmitting the reception feedback of those data packets. ¶0104), Fig. 18;),
wherein the controlling the retransmission comprises
not notifying, by the RLC entity, a PDCP layer of the communication apparatus of successful delivery of the data packet, until receiving the second acknowledgement subsequent to receiving the first acknowledgement (Examiner interpreted as a person of ordinary skill at the time of invention would understand that an E2E or HBH ARQ method still requires an initial MAC/RLC ACK at the initial IAB node, the first access or parent node, to the UE. Initial ACK is required here to manage wireless link variations and successful radio transmission to access node (acting as gNB for UE) for entry into an IAB network. In addition, Claim 1 recites limitations applied to “a communication apparatus being either of a user equipment or a relay node”, and thus may be interpreted as ‘a UE’. UE transmits data packets towards the end node, the donor base station, via the IAM wireless backhaul which is an intermediate IAB node, the parent node. UE receives a reception feedback, first acknowledgement, regarding those transmitted data packets in the form of positive and/or negative acknowledgements. ¶0103, Fig. 18; After the initial ACK, a first ACK, when the IAB network is configured for E2E method then the next ACK, a second ACK, comes from the end point, donor node, to the UE ¶¶0100-0102, 0104; The second acknowledgement received by the UE is from the donor node as shown in fig. 20 and paragraphs [0128-0132] with solution implemented by applying the method implemented in an E2E architecture per paragraphs [0100-0104]; RLC entities at the UE and gNB configured for AM RLC. Transmitting side receives RLC SDUs from the upper layer, PDCP, and transmits. The receiving side of an AM RLC delivers RLC SDUs to upper layer, PDCP. ¶0041; Functions of PDCP and RLC layers listed in sections 6.4, 6.3 of 3GPP TS 38.300. ¶0035; Acknowledge Mode RLC, AM RLC, with functions defined by 3GPP TS 38.322. ¶0040; RLC status report includes acknowledgements of ACK/NACK information, a first acknowledgement, and sequence numbers, a second acknowledgement. ¶0048, Fig. 5;).
RE Claim 2, Tao discloses:
The communication control method, wherein
each of the first acknowledgment and the second acknowledgment is an acknowledgment of an RLC layer (AM data transfer at the RLC layer includes a transmitting window that limits the amount of PDUs that can be transmitted. The transmitting window can be a sliding window, which is moved forward upon receiving the positive acknowledgement of delivery, a first acknowledgement from the parent node, for the PDU, updating the transmission window. ¶0044, Fig. 4, ¶0090; Determination that a respective data packet was not correctly received, a NACK/ACK as second acknowledgement from the donor node, and optionally determines to retransmit the respective data packet by use of ARQ AM RLC mechanism. ¶0213) , and
the controlling the retransmission comprises notifying, by the RLC entity, a PDCP layer of the communication apparatus of successful delivery of the data packet, based on the second acknowledgment (RLC entities at the UE and gNB configured for AM RLC. Transmitting side receives RLC SDUs from the upper layer, PDCP, and transmits. The receiving side of an AM RLC delivers RLC SDUs to upper layer, PDCP. ¶0041; Functions of PDCP and RLC layers listed in sections 6.4, 6.3 of 3GPP TS 38.300. ¶0035; Acknowledge Mode RLC, AM RLC, with functions defined by 3GPP TS 38.322. ¶0040; RLC status report includes acknowledgements of ACK/NACK information, a first acknowledgement, and sequence numbers, a second acknowledgement. ¶0048, Fig. 5; Determination that a respective data packet was not correctly received, a NACK/ACK from the donor as second acknowledgement, as part of reception feedback, RLC status report, and optionally determines to retransmit the respective data packet by use of ARQ AM RLC mechanism. ¶0213; .
RE Claim 3, Tao discloses:
The communication control method, wherein
the first acknowledgment is an acknowledgment defined in an RLC layer (RLC status report includes acknowledgements of ACK/NACK information, a first acknowledgement, from the intermediate node, the parent node. ¶0048, Fig. 5;), and the second acknowledgment is an acknowledgment defined in an upper layer of the RLC layer (RLC entities at the UE and gNB configured for AM RLC. Transmitting side receives RLC SDUs from the upper layer, PDCP, and transmits. The receiving side of an AM RLC delivers RLC SDUs to upper layer, PDCP. ¶0041; End-to-End ARQ, E2E ARQ, has the IAB donor node, donor base station, transmits the reception feedback, second acknowledgement, to the source node, UE, of the data traffic route. The data packets are forwarded by the intermediate node, the parent node, to the donor node which is the entity determined and transmitting the reception feedback of those data packets. ¶0104), and
the controlling the retransmission comprises controlling, by the upper layer, the retransmission based on the second acknowledgment (RLC status report includes acknowledgements of ACK/NACK information from the parent node, a first acknowledgement, and the donor node, a second acknowledgement. ¶¶0103-0104; Determination that a respective data packet, was not correctly received, a NACK/ACK from the donor node, a second acknowledgement, as part of reception feedback, RLC status report, and optionally determines to retransmit the respective data packet by use of ARQ AM RLC mechanism. ¶0213;).
RE Claim 4, Tao discloses:
The communication control method, wherein
even if the upper layer receives, from the RLC layer, notification of successful delivery of the data packet, the upper layer ignores the notification (End-to-End ARQ, E2E ARQ, has the IAB donor node, donor base station, transmits the reception feedback, second acknowledgement, to the source node, UE, of the data traffic route. The data packets are forwarded by the intermediate node, the parent node, to the donor node which is the entity determined and transmitting the reception feedback of those data packets. ¶0104; Therefore, the intermediate nodes ignore the delivery notification and simply passes it onto the donor node of the traffic data route).
RE Claim 5, Tao discloses:
A communication control method comprising:
by a Radio Link Control (RLC) entity of a relay node (Integrated access backhaul network. ¶0059, Fig. 6; Improved RLC ARQ design for Backhaul for End-To-End, E2E, and Hop-by-Hop, HBH, a backhaul adaptation protocol. An above-RLC adaptation layer, Fig. 8, can only support HBH ARQ. An above-MAC adaptation layer, Fig. 9, can support both HBH and E2E ARQ. ¶¶0069-0071; A congested intermediate node, a parent or relay, may utilize the information given by the end node (the IAB Donor) to change its aggregation policy to minimize impact of the congestion. ¶¶0187,0194; The solutions according to FIG. 18 described above were mainly described as part of an E2E ARQ architecture but can also be applied to an HBH ARQ architecture, where ARQ is performed at every hop. Thus, the solution can be implemented between any two nodes of the data traffic route, such as between the UE and the next intermediate node, between two intermediate nodes, and between an intermediate node and an IAB donor. These can be implemented at the respectively applicable nodes, such as the UE, the intermediate nodes and the IAB donor. ¶0139, Fig. 18), transmitting data packets to a donor base station via a parent node of the relay node (Exemplary diagram of one IAB-donor and multiple IAB nodes, parent and relay, with two or more hops. ¶0059, Fig. 6; UE1 connected to I-Node 2, relay node, connected to I-Node 1, parent node, connected to IAB Donor Node. ¶0097, Fig. 17; UE transmits data packets towards the end node, the donor base station, via the IAM wireless backhaul which is an intermediate IAB node, the parent or relay node. UE receives a reception feedback, first acknowledgement, regarding those transmitted data packets in the form of positive and/or negative acknowledgements. ¶0103, Fig. 18;), and storing the data packets in a retransmission buffer and then receiving a first acknowledgment from the parent node, (; A congested intermediate node, a parent or relay, may utilize the information given by the end node (the IAB Donor) to change its aggregation policy to minimize impact of the congestion. ¶¶0187,0194; RLC entity STATUS report sent via a packet in response to a polling request. Status report contains reception status of the PDUs and associated sequence numbers, packet identifiers. RLC Status polling can include information about the PDUs including status of transmission buffer. ¶¶0049, 0055; Additional flow mechanisms to handle data congestion. ¶0077; Uplink transmission buffer at an intermediate node may experience congestion due to a weak link to the next intermediate node hop of data traffic route. ¶0079, Fig. 10, 11; A “transmitting window”, a buffer that stores packets, limits how many data packets may be transmitted based on transmitting window size. Transmitting window implemented as a sliding window that adjusts when a packet was successfully transmitted. ¶0090; Reception feedback, an indicator and status of congestion, may be used to base adaptation of transmitting window size dynamically, a buffer. ¶0107),
the first acknowledgment indicating that the data packets are received by the parent node (RLC status report includes acknowledgements of ACK/NACK information, a first acknowledgement, from the intermediate node, the parent node. ¶0048, Fig. 5;);
by the RLC entity, updating a transmission window managed at the RLC entity in response to receiving the first acknowledgment (RLC entity. ¶¶0040-0042, Fig. 3; The transmitting side, UE, of an RLC entity maintains a transmitting window to control (and limit) the transmission of RLC PDUs. ¶0043, Fig. 4);
by a Backhaul Adaptation Protocol (BAP) layer of the relay node (Improved RLC ARQ design defined for Integrated Access and Backhaul scenarios, RLC adaptation for Backhaul. End-to-End ARQ, E2E ARQ, and Hop-by-Hop ARQ, HBH ARQ solutions. ¶¶0069-0070, Fig. 9; ; A congested intermediate node, a parent or relay, may utilize the information given by the end node (the IAB Donor) to change its aggregation policy to minimize impact of the congestion. ¶¶0187,0194), receiving a status packet from the donor base station via the parent node (A congested intermediate node, a parent or relay, may utilize the information given by the end node (the IAB Donor) to change its aggregation policy to minimize impact of the congestion. ¶¶0187,0194; Data packet exchange of source node, UE, to an intermediate nodes, parent and/or relay nodes, to the donor node. Data packets are transmitted to intermediate nodes, parent or relay nodes, and to the donor node. RLC status polling request results in parent node transmitting reception feedback to the UE indicating data packets successfully and unsuccessfully received based on sequence numbers and ACK/NACK. ¶0128, Fig. 20; RLC entity STATUS report sent via a packet in response to a polling request. Status report contains reception status of the PDUs and associated sequence numbers, packet identifiers. ¶¶0049, 0055),
the BAP layer being an upper layer of the RLC entity the status packet indicating whether each of the data packets has been delivered to the donor base station (A congested intermediate node, a parent or relay, may utilize the information given by the end node (the IAB Donor) to change its aggregation policy to minimize impact of the congestion. ¶¶0187, 0194; Improved RLC ARQ design defined for Integrated Access and Backhaul scenarios, RLC adaptation for Backhaul. ¶¶0069-0070; RLC Entity receives RLC SDUs from upper layer. ¶¶0040-0041; Fig. 9; End-to-End ARQ, E2E ARQ, has the IAB donor node, donor base station, transmits the reception feedback status, second acknowledgement, to the source node, UE, of the data traffic route. ¶0104); and
by the relay node, controlling retransmission of the data packets stored in the retransmission buffer in response to receiving the status packet (A congested intermediate node, a parent or relay, may utilize the information given by the end node (the IAB Donor) to change its aggregation policy to minimize impact of the congestion. ¶¶0187, 0194; RLC layer provides ARQ functionality for AM RLC data transfer including retransmission to be performed and reception feedback to be implemented as a RLC Status Report. ¶0145, Fig. 5, 20; RLC entity STATUS report sent via a packet in response to a polling request. Status report contains reception status of the PDUs and associated sequence numbers, packet identifiers. RLC Status polling can include information about the PDUs including status of transmission buffer. ¶¶0049, 0055),
wherein the controlling the retransmission comprises not notifying, by the BAP layer, the RLC entity of successful delivery of the data packets, until receiving the status packet from the donor station (The following solutions can be used between the two nodes of a hop, respectively being the transmitting node and the receiving node of the hop, depending on whether the node is transmitting the data packets or receiving the data packets. For instance, in the downlink case, the UE can be the receiving node and the first intermediate node can be transmitting node; in the uplink case, the UE would be the transmitting node and the first intermediate node would be the receiving node. This logic would similarly apply in other hops, e.g., a hop involving two intermediate nodes, or a hop involving one intermediate node and the IAB node. A congested intermediate node, a parent or relay, may utilize the information given by the end node (the IAB Donor) to change its aggregation policy to minimize impact of the congestion. ¶¶0187,0194; Data packet exchange of source node, UE, to an intermediate nodes, parent and/or relay nodes, to the donor node. Data packets are transmitted to intermediate nodes, parent or relay nodes, and to the donor node. RLC status polling request results in parent node transmitting reception feedback to the UE indicating data packets successfully and unsuccessfully received based on sequence numbers and ACK/NACK. ¶0128, Fig. 20; RLC entity STATUS report sent via a packet in response to a polling request. Status report contains reception status of the PDUs and associated sequence numbers, packet identifiers. ¶¶0049, 0055).
RE Claim 6, Tao discloses:
The communication control method, further comprising:
starting a timer when the data packets are stored in the retransmission buffer (A step of determining transmitting window size by performing the step of operating a timer, e.g. starting, monitoring, stopping same, and determine its expiry. ¶¶0093, 0114, 0135; An acknowledgement timer may be configured for transmitted data packets or one timer per transmitted data packet. ¶0170.); and
discarding or retransmitting the data packets stored in the retransmission buffer when the timer expires (In case of no feedback for a data packet, the corresponding acknowledgement timer eventually expires. Transmitting side determines that the respective data packet was not correctly received by the receiving side. The UE determines a NACK for that data packet. ¶0172; The NACK obtained by the UE when the acknowledgement timer expires can be used to trigger a retransmission in the UE for said lost packet. ¶0178).
RE Claim 7, Tao discloses:
The communication control method, wherein
the controlling the retransmission comprises, among the data packets stored in the retransmission buffer (RLC Status polling can include information about the PDUs including status of transmission buffer. ¶¶0049, 0055; Transmitting window and transmitting window size is a buffer for status of data packets. ¶0090), discarding a data packet having a delivered packet identifier indicated by the status packet and retransmitting a data packet not having the delivered packet identifier (RLC entity STATUS report sent via a packet in response to a polling request. Status report contains reception status of the PDUs and associated sequence numbers, packet identifiers, packet identifiers. RLC Status polling can include information about the PDUs including status of transmission buffer. ¶¶0049, 0055; AM data transfer at the RLC layer includes a transmitting window that limits the amount of PDUs that can be transmitted. The transmitting window can be a sliding window, which is moved forward upon receiving the positive acknowledgement of delivery, a first acknowledgement, for the PDU, updating the transmission window. The lower edge of the transmit window corresponds to the PDU with the sequence number, SN, that follows the last in-sequence completely received RLC PDUs. ¶0044, Fig. 4, ¶0090).
RE Claim 9,
The communication control method, wherein the controlling of retransmission includes discarding or retransmitting the data packet stored in a retransmission buffer of the communication apparatus (In case of no feedback for a data packet, the corresponding acknowledgement timer eventually expires. Transmitting side, UE, determines that the respective data packet was not correctly received by the receiving side. The UE determines a NACK for that data packet. ¶0172; The NACK obtained by the UE when the acknowledgement timer expires can be used to trigger a retransmission in the UE for said lost packet. ¶0178).
RE Claim 10,
The communication control method, wherein the updating of the transmission window is started before the second acknowledgement being received by the communication apparatus (The transmitter transmits at least one data packet based on a transmitting window having a transmitting window size, setting of a window size to transmit packets initially. The processing circuitry determines, based on reception feedback after transmitting packets, whether to change the transmitting size window. ¶0012; A step of determining transmitting window size by performing the step of operating a timer, e.g. starting, monitoring, stopping same, and determine its expiry. ¶¶0093, 0114, 0135; An acknowledgement timer may be configured for transmitted data packets or one timer per transmitted data packet. ¶0170.).
RE Claim 11,
The communication control method, further comprising:
by the RLC entity of the relay node, receiving the data packets from a child node of the relay node (Exemplary diagram of one IAB-donor and multiple IAB nodes, parent, and child nodes, relay or UE, with two or more hops. ¶0059, Fig. 6; RLC layer has an AM RLC entity, Acknowledge Mode RLC. ¶0042, Fig. 3; One or more intermediate, relay, IAB nodes for multi-hop traffic in 5G NR as well as LTE relay. ¶0096; Data packet exchange of source node, UE, to an intermediate nodes, parent and/or relay nodes, to the donor node. Data packets are transmitted to intermediate nodes, parent or relay nodes, and to the donor node. RLC status polling request results in parent node transmitting reception feedback to the UE indicating data packets successfully and unsuccessfully received based on sequence numbers and ACK/NACK. ¶0128, Fig. 20; RLC entity STATUS report sent via a packet in response to a polling request. Status report contains reception status of the PDUs and associated sequence numbers, packet identifiers. ¶¶0049, 0055).
Response to Arguments
Applicant's arguments filed 02/09/2026 have been fully considered but they are not persuasive.
Applicant’s arguments are directed to claims 1 and 5 and arguing that “Tao does not disclose a coordination between RLC and PDCP based on two ACKs.” In addition, “Lack of Claimed Sequence: Applicant respectfully submits that even if one were to argue that Tao could combine these modes, Tao does not disclose or suggest the specific sequence of the present embodiment:
1. Updating the transmission window in response to a first ACK (from Parent);
2. Subsequent to the first ACK, receiving a second ACK (from Donor); and
3. Controlling retransmission based on that second ACK subsequent to receiving the first
ACK.
4. Not notifying, by the RLC entity, a PDCP layer of the communication apparatus of successful delivery of the data packet until receiving the second ACK, while updating a transmission window by the RLC entity in response to the first ACK.
Also, the Final Office Action cites Paragraphs 0103 (First ACK) and 0104 (Second ACK) of Tao. However, Applicant respectfully submits that paragraph 0104 of Tao, at best, describes E2E ARQ where the intermediate node simply forwards the packet, and does not teach that the UE first acts on a local ACK from the parent and subsequently acts on a remote ACK from the donor for the same packet flow in the manner claimed.”
Examiner respectfully disagrees. A two-step acknowledgement is disclosed by Tao with application of E2E ARQ. A person of ordinary skill at the time of invention would understand that an E2E or HBH ARQ method still requires an initial MAC/RLC ACK at the initial IAB node, the first access or parent node, to the UE. Initial ACK is required here to manage wireless link variations and successful radio transmission to access node (acting as gNB for UE) for entry into an IAB network. After the initial ACK, a first ACK, when the IAB network is configured for E2E method then the next ACK, a second ACK, comes from the end point, donor node, to the UE. Therefore, the first acknowledgement is the acknowledgement from the parent node. In addition, Claim 1 recites limitations applied to “a communication apparatus being either of a user equipment or a relay node”, and thus may be interpreted as ‘a UE’. The above response applies to a UE to a first IAB, access or parent node. See instant application, fig. 9, S101/102 for the initial exchange between a UE and a first node. Claim 1 recites in the first limitation this first step to obtain a first acknowledgement directly by a UE from a parent node. The second acknowledgement received by the UE is from the donor node as shown in fig. 20 and paragraphs [0128-0132] with solution implemented by applying the method implemented in an E2E architecture per paragraphs [0100-0104].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
US 20210127293 A1 Hong
“METHOD FOR PROCESSING DATA IN RELAY NODE, AND DEVICE THEREOF”
Provided are methods and apparatuses of processing data in an integrated access and backhaul (IAB) node using new radio (NR) wireless communication technology. The method of an integrated access and backhaul (IAB) node processes data, includes: configuring a mobile-termination (MT) function and a distribute unit function of the IAB node; monitoring an uplink buffer state or a downlink buffer state in the IAB node; and transmitting downlink buffer state information or uplink buffer state information to the donor base station or an associated parent IAB node on the basis of a monitoring result of the uplink buffer state or the downlink buffer state. See also ¶¶0126-0128
US-20210235519-A1 Yi et al.
“Method And Apparatus For Processing Signals By Node In Wireless Communication System”
The present invention relates to a method for processing signals by a node in a wireless communication system. In particular, the method includes receiving a radio bearer (RB) configuration message from a network; and configuring a radio bearer between a radio link control (RLC) entity of the node and a peer RLC entity using the RB configuration message, wherein the RB configuration message includes information about that the peer RLC entity operates with a different RLC mode from a RLC entity of the node.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL A. LANGER whose telephone number is (703)756-1780. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm, Eastern.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nishant B. Divecha can be reached at 1 (571) 270-3125. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/PAUL A. LANGER/Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights