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 09/02/2025.
Claims 1-7 and 9-11 are pending and presented for examination. Claims 1 and 3-5 are amended. Claim 8 is cancelled. Claims 9-11 are added.
Response to Amendment
Drawing objection to Figures 11 and 12 are withdrawn.
Specification objection is withdrawn.
Claim objections are withdrawn.
The reply filed on 09/02/2025 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.
Drawings
Figures 12- 16 should be designated by a legend such as --Prior Art-- because only that which is old is illustrated. See MPEP § 608.02(g). Fig. 12 – The figure is the same as found in 3GPP 38.240 version 16.1.0, 07/24/2020, page 18, Fig. 6.2.2-1, https://www.etsi.org/deliver/etsi_ts/138300_138399/138340/16.01.00_60/ts_138340v160100p.pdf Fig. 13 – Per the specification, “In email discussion of Rel-16, four types of BH RLF notifications as illustrated in FIG. 13 were discussed.”, ¶0155. This is found in 3GPP document “draft R2-200xxxx [AT112-e][031][eIAB] Topology Adaptation (QC) - v13_Ericsson”, Qualcomm, Nov. 2-13 2020. Fig. 14 – Per the specification, “As illustrated in FIG. 14, possible five solutions were discussed and summarized together with the rapporteur’s view.”, ¶0169. This is found in 3GPP document “R2-20xxxxx 109e_36 IAB RLF handling_PH2_Lenovo_Nokia_CATT_FTW_vivo_HW_ER”, Qualcomm, 04/08/2020. Fig. 15 – Per the specification, “In the stage of research of Rel-15, the problem of multi-hop RLC ARQ was discussed and captured in Section 8.2.3 of TR. In Rel-16, the protocol stack was defined for the IAB including unsplit RLC layers. In other words, in Rel-16, end-to-end ARQ was excluded, and hop-by-hop ARQ was adopted. [0166] Regarding the hop-by-hop ARQ, the problem in end-to-end reliability, that is, lossless delivery with UL packets, was identified. As illustrated in FIG. 15, three solutions were identified and evaluated.”, ¶¶0184-0185. This is found in 3GPP document “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Study on Integrated Access and Backhaul; (Release 16)3GPP TR 38.874 V16.0.0 (2018-12)”, Pg. 32 Table 8.2.3-2. Fig. 16 – Per the specification “[0171] Proposal 11: RAN2 should agree on introduction of the solution identified in TR 38.874, that is, the mechanism to guarantee lossless delivery under a condition that the topology change may frequently occur based on "UL status delivery" of some form. [0172] The details of the third solution, that is, "Introducing UL status delivery", were discussed in two options, namely C-1 and C-2, in email discussion as illustrated in FIG. 16.”, ¶¶0189-0191. This “email” has not been found through search nor was the document included in the IDS.
Corrected drawings in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. The replacement sheet(s) should be labeled “Replacement Sheet” in the page header (as per 37 CFR 1.84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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; ); and
by the communication apparatus, controlling, in response to receiving a second acknowledgment from the parent node after receiving the first acknowledgment, retransmission related to the data packet based on the second acknowledgment (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; ),
the second acknowledgement indicating that the data packet has been received by the 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).
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 BAP layer, 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).
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 traverses the objection to the identified drawings to be labelled as “Prior Art”. Applicant argues that “Figures 11-16 are presented to illustrate examples of the present embodiments and do not represent prior art.” Examiner respectfully disagrees. Figures 12-16 are referenced in the specification, 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. The drawings do not illustrate what is new in the application over Prior Art. Refer to prior section under Drawings.
Applicant’s second argument is regarding claim 1, as amended. Applicant argues that Tao does not disclose the claimed embodiments. Specifically, RLC entity updates transmission window in response to a first acknowledgement from a parent node and retransmission in response to a second acknowledgement after receiving the first. Applicant submits that this “two-step process with two distinct acknowledgements is neither disclosed nor suggested by Tao”. Examiner respectfully disagrees. In a cursory review of Tao, the subject matter is disclosed. Regarding the first 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. Regarding the second acknowledgement: 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, Tao discloses the subject matter.
Applicant’s third argument is regarding claim 5, as amended. Applicant argues that claim 5, as amended, recites the two-step acknowledgement process and control of retransmissions by the RLC entity of a relay node. Applicant submits that Tao does not disclose this “specific, multi-layered acknowledgement and control process.” Examiner respectfully disagrees. In a cursory review of Tao, the subject matter is disclosed. First, regarding the two-step process of acknowledgements, Tao discloses the first and second acknowledgements as discussed in prior argument response. Second, the control process of a relay node is disclosed. 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. Per Tao, the methods are applied between any two nodes of the data traffic route. “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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
US 20210127293 A1 Hong
US-20230164617-A1 Barac et al.
WO-2009031866 Chang et al.
3GPP TSG-RAN WG2 Meeting [#109bis-e], R2-20xxxxx, Electronic meeting, [April 24 - May 1], https://www.3gpp.org/ftp/Email_Discussions/RAN2/%5BRAN2%23109-e%5D/%5BPost109e%2336%5D%5BIAB%5D%20RLF%20open%20issues/R2-20xxxxx%20109e_36%20IAB%20RLF%20handling_PH2_Lenovo_Nokia_CATT_FTW_vivo_HW_SAM.docx (Year: 2020)
The above references disclose various aspects of methods and improvements for data packet communication in a multi-hop network consisting of user device, intermediate nodes, and parent node.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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