DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
2. 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.
3. 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)(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.
4. Claims 15 and 22 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by
Liu (US 2023/0413154 A1).
Regarding claim 15, Liu teaches a method performed by an integrated access and backhaul (IAB) node in a communication system, the method comprising:
obtaining, from a central unit (CU) of a target IAB donor, first information on a backhaul
adaptation protocol (BAP) header rewriting (figs. 1-7, ¶ [0056] The switching can be switching between different donor DUs in the same CU, that is, switching between donor DUs in the same CU; or the switching can be switching between different CU, that is, switching from one CU to another CU. ¶ [0061, ¶ [0071] receiving, by the IAB node, a third indication sent by the target CU or the target donor DU, where the third indication is configured to instruct to route the second BAP PDU to the target donor DU. ¶ [0076]. ¶ [0081], ¶ [0112]), wherein the first information including information on a mapping between an old routing identifier (ID) associated with a first topology of a source IAB donor and a new routing ID associated with a second topology of the target IAB donor (¶ [0082] As an optional implementation manner, the routing, to a target donor DU, a second BAP PDU whose target BAP address is an original donor distributed unit DU includes: ¶ [0083] performing a rewriting operation on the second BAP PDU, and routing the second BAP PDU after the rewriting operation to the target donor DU, where the rewriting operation includes at least one of the following: ¶ [0084] rewriting a first routing identifier of the second BAP PDU to a second routing identifier, where the first routing identifier is configured to route to the original donor DU, and the second routing identifier is configured to route to the target donor DU); in case that a BAP packet to be considered for the BAP header rewriting is identified, rewriting a first routing ID of the first topology included in a header of the BAP packet to a second routing ID of the second topology corresponding to the first routing ID based on the first information (¶ [0083] performing a rewriting operation on the second BAP PDU, and routing the second BAP PDU after the rewriting operation to the target donor DU, where the rewriting operation includes at least one of the following: ¶ [0084] rewriting a first routing identifier of the second BAP PDU to a second routing identifier, where the first routing identifier is configured to route to the original donor DU, and the second routing identifier is configured to route to the target donor DU. ¶ [0086], Rewriting the BAP routing ID includes rewriting the destination BAP address of the BAP PDU to the address of the target donor DU); and routing the BAP packet with the rewritten header, through a target path identified based on the second routing ID (¶ [0086] The routing identifier can be a BAP routing identifier (routing ID), and the rewriting of the first routing identifier of the second BAP PDU to the second routing identifier can be to rewrite the BAP routing ID in the BAP header of the BAP PDU to the BAP routing ID of the target donor DU, so as to send the rewritten BAP PDU to the target donor DU).
Regarding claim 22, Liu teaches an integrated access and backhaul (IAB) node in a communication system, the IAB node comprising: a transceiver; and a controller (fig. 7) configured to: obtain, from a central unit (CU) of a target IAB donor, first information on a backhaul adaptation protocol (BAP) header rewriting (figs. 1-7, ¶ [0056] The switching can be switching between different donor DUs in the same CU, that is, switching between donor DUs in the same CU; or the switching can be switching between different CU, that is, switching from one CU to another CU. ¶ [0061, ¶ [0071] receiving, by the IAB node, a third indication sent by the target CU or the target donor DU, where the third indication is configured to instruct to route the second BAP PDU to the target donor DU. ¶ [0076]. ¶ [0081], ¶ [0112]), wherein the first information including information on a mapping between an old routing identifier (ID) associated with a first topology of a source IAB donor and a new routing ID associated with a second topology of the target IAB donor (¶ [0082] As an optional implementation manner, the routing, to a target donor DU, a second BAP PDU whose target BAP address is an original donor distributed unit DU includes: ¶ [0083] performing a rewriting operation on the second BAP PDU, and routing the second BAP PDU after the rewriting operation to the target donor DU, where the rewriting operation includes at least one of the following: ¶ [0084] rewriting a first routing identifier of the second BAP PDU to a second routing identifier, where the first routing identifier is configured to route to the original donor DU, and the second routing identifier is configured to route to the target donor DU), in case that a BAP packet to be considered for the BAP header rewriting is identified, rewrite a first routing ID of the first topology included in a header of the BAP packet to a second routing ID of the second topology corresponding to the first routing ID based on the first information (¶ [0083] performing a rewriting operation on the second BAP PDU, and routing the second BAP PDU after the rewriting operation to the target donor DU, where the rewriting operation includes at least one of the following: ¶ [0084] rewriting a first routing identifier of the second BAP PDU to a second routing identifier, where the first routing identifier is configured to route to the original donor DU, and the second routing identifier is configured to route to the target donor DU. ¶ [0086], Rewriting the BAP routing ID includes rewriting the destination BAP address of the BAP PDU to the address of the target donor DU), and route the BAP packet with the rewritten header, through a target path identified based on the second routing ID (¶ [0086] The routing identifier can be a BAP routing identifier (routing ID), and the rewriting of the first routing identifier of the second BAP PDU to the second routing identifier can be to rewrite the BAP routing ID in the BAP header of the BAP PDU to the BAP routing ID of the target donor DU, so as to send the rewritten BAP PDU to the target donor DU.).
5. Claims 15 and 22 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by
Zhu et al. (US 2023/0247521 A1, hereinafter “Zhu”).
Regarding claim 15, Zhu teaches a method performed by an integrated access and backhaul (IAB) node in a communication system, the method comprising:
obtaining, from a central unit (CU) of a target IAB donor, first information on a backhaul
adaptation protocol (BAP) header rewriting (figs. 1A, 1F, 1G, 2A-5, ¶ [0192], the first network node receives configuration information provided by the target IAB donor CU (for example, a fourth network node shown in FIG. 1F). Specific content includes one or more new routing identifiers (for example, a default/default BAP routing ID, which may be used to forward all buffered data packets) to the target IAB donor DU, and optionally, further includes an original routing identifier (pointing to an original transmission path to the source IAB donor DU) mapping to each new routing identifier), wherein the first information including information on a mapping between an old routing identifier (ID) associated with a first topology of a source IAB donor and a new routing ID associated with a second topology of the target IAB donor (¶ [0192], The first network node replaces, based on the configuration information provided by the target IAB donor CU, the BAP routing IDs in the header information of the BAP layer carried in BAP PDUs being buffered by the first network node with the configured new routing identifiers, performs routing selection based on the new routing identifiers); in case that a BAP packet to be considered for the BAP header rewriting is identified, rewriting a first routing ID of the first topology included in a header of the BAP packet to a second routing ID of the second topology corresponding to the first routing ID based on the first information (¶ [0192], The first network node replaces, based on the configuration information provided by the target IAB donor CU, the BAP routing IDs in the header information of the BAP layer carried in BAP PDUs being buffered by the first network node with the configured new routing identifiers, performs routing selection based on the new routing identifiers); and routing the BAP packet with the rewritten header, through a target path identified based on the second routing ID (¶ [0192], The first network node replaces, based on the configuration information provided by the target IAB donor CU, the BAP routing IDs in the header information of the BAP layer carried in BAP PDUs being buffered by the first network node with the configured new routing identifiers, and sends the data packets to the next-hop node (that is, the target parent node)).
Regarding claim 22, Zhu teaches an integrated access and backhaul (IAB) node in a communication system, the IAB node comprising: a transceiver; and a controller (figs. 5, 6) configured to: obtain, from a central unit (CU) of a target IAB donor, first information on a backhaul adaptation protocol (BAP) header rewriting (figs. 1A, 1F, 1G, 2A-5, ¶ [0192], the first network node receives configuration information provided by the target IAB donor CU (for example, a fourth network node shown in FIG. 1F). Specific content includes one or more new routing identifiers (for example, a default/default BAP routing ID, which may be used to forward all buffered data packets) to the target IAB donor DU, and optionally, further includes an original routing identifier (pointing to an original transmission path to the source IAB donor DU) mapping to each new routing identifier), wherein the first information including information on a mapping between an old routing identifier (ID) associated with a first topology of a source IAB donor and a new routing ID associated with a second topology of the target IAB donor (¶ [0192], The first network node replaces, based on the configuration information provided by the target IAB donor CU, the BAP routing IDs in the header information of the BAP layer carried in BAP PDUs being buffered by the first network node with the configured new routing identifiers, performs routing selection based on the new routing identifiers), in case that a BAP packet to be considered for the BAP header rewriting is identified, rewrite a first routing ID of the first topology included in a header of the BAP packet to a second routing ID of the second topology corresponding to the first routing ID based on the first information (¶ [0192], The first network node replaces, based on the configuration information provided by the target IAB donor CU, the BAP routing IDs in the header information of the BAP layer carried in BAP PDUs being buffered by the first network node with the configured new routing identifiers, performs routing selection based on the new routing identifiers), and route the BAP packet with the rewritten header, through a target path identified based on the second routing ID (¶ [0192], The first network node replaces, based on the configuration information provided by the target IAB donor CU, the BAP routing IDs in the header information of the BAP layer carried in BAP PDUs being buffered by the first network node with the configured new routing identifiers, and sends the data packets to the next-hop node (that is, the target parent node)).
Claim Rejections - 35 USC § 103
6. 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.
7. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
8. Claims 16-19 and 23-26 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu in view of Akl et al. (US 2022/0132390 A1, hereinafter “Akl”).
Regarding claims 16 and 23, Zhu teaches the method of claim 15.
Zhu does not explicitly teach further comprising: obtaining, from the CU of the target IAB donor, second information on a backhaul (BH) routing between the target IAB donor and the IAB node.
Akl teaches obtaining, from the CU of the target/second IAB donor, second information on a backhaul (BH) routing between the target/second IAB donor and the IAB node (fig. 8, ¶ [0070], a routing configuration and/or a channel mapping configuration may be needed at IAB-node 831. Further, sharing transport IDs may be utilized between IAB-donor 821, e.g., CU1, and IAB-donor 822, e.g., CU2. The transport IDs may correspond to a BAP routing space, a backhaul (BH) radio link control (RLC) channel space, and/or a logical channel ID (LCID) space. ¶ [0071], it may be beneficial to include a routing configuration and/or a channel mapping configuration at an IAB node. Accordingly, it may be beneficial to share transport IDs between IAB donors, e.g., multiple CUs. ¶ [0073], ¶ [0074], the routing ID may be rewritten for packets that cross the two topology sections along the routing path between donor-DU2 and IAB-node 832. These routing IDs may be exchanged between CU1 and CU2. In one example, CU1 may establish a BH RLC CH (e.g., the CH with ID=‘a’) between IAB-node 831 and IAB-node 832. CU2 may establish a BH RLC CH between IAB-node 831 and IAB-node 833. Traffic that is received by IAB-node 831 along the backhaul routing path over one of the two example BH RLC CHs may be mapped to the other CH. A channel mapping configuration at IAB-node 831 may be configured by either of the two CUs, and this may utilize knowledge of the BH RLC CH established by the other CU. The two CUs may exchange a CH ID such as a BH RLC CH ID or LCD for the channel. ¶ [0081], ¶ [0091]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to obtain, from the CU of the target IAB donor, second information on a backhaul (BH) routing between the target IAB donor and the IAB node in the system of Zhu to further improve industrial applicability.
Regarding claims 17 and 24, Zhu in view of Akl teaches the method of claim 16, wherein the second information includes information on a next hop BAP address mapped with the second routing ID, and wherein the second routing ID includes a BAP's address and a path identity (ID) for the target path (Zhu: figs. 1E-6, ¶ [0192], Specific content includes one or more new routing identifiers (for example, a default/default BAP routing ID, which may be used to forward all buffered data packets) to the target IAB donor DU, and optionally, further includes a next-hop node corresponding to each routing identifier, and an original routing identifier (pointing to an original transmission path to the source IAB donor DU) mapping to each new routing identifier. ¶ [0189], the BAP routing ID includes a BAP address (BAP address) and a BAP path identifier (BAP path ID). Akl: ¶ [0081], The second configuration may include a routing configuration of a BAP routing ID of the first BAP configuration to an egress link. The second configuration may include a routing configuration to a next-hop BAP address of the first BAP configuration for a parent node of the IAB-node on the backhaul routing path. ¶ [0091]).
Regarding claims 18 and 25, Zhu in view of Akl teaches the method of claim 17. Zhu further teaches wherein the routing the BAP packet with rewritten header further comprises: identifying that a destination of the BAP packet is a distributed unit (DU) of the target IAB donor based on the BAP's address; identifying a target parent IAB node corresponding to the next hop address; and transmitting the BAP packet to the target parent IAB node (figs. 1F-4, ¶ [0192], Specific content includes one or more new routing identifiers (for example, a default/default BAP routing ID, which may be used to forward all buffered data packets) to the target IAB donor DU, and optionally, further includes a next-hop node corresponding to each routing identifier, and an original routing identifier (pointing to an original transmission path to the source IAB donor DU) mapping to each new routing identifier. The first network node replaces, based on the configuration information provided by the target IAB donor CU, the BAP routing IDs in the header information of the BAP layer carried in BAP PDUs being buffered by the first network node with the configured new routing identifiers, performs routing selection based on the new routing identifiers, and sends the data packets to the next-hop node (that is, the target parent node), ¶ [0189]).
Zhu does not explicitly teach transmitting, to the target parent IAB node, the BAP packet through a BH radio link control (RLC) channel allocated on the target path.
Akl teaches transmitting, to the target parent IAB node, the BAP packet through a BH radio link control (RLC) channel allocated on the target path (figs. 8, 9, ¶ [0091]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to transmit the BAP packet to the target parent IAB through a BH radio link control (RLC) channel allocated on the target path in the system of Zhu in view of Akl to utilize conventional techniques in the art.
Regarding claims 19 and 26, Zhu in view of Akl teaches the method of claim 16.
Zhu does not explicitly teach wherein the first information is obtained with the second information at a distributed unit (DU) of the IAB node, through a CU of the source/first IAB donor based on an F1 application protocol (F1AP).
Akl teaches wherein the first information is obtained with the second information at a distributed unit (DU) of the IAB node, through a CU of the source IAB donor based on an F1AP (¶ [0071], it may be beneficial to include a routing configuration and/or a channel mapping configuration at an IAB node. Accordingly, it may be beneficial to share transport IDs between IAB donors, e.g., multiple CUs. ¶ [0073], If CU1 selects the BAP routing ID, CU2 may configure routing and mapping configurations at the section managed by CU2, which may imply CU1 and CU2 may exchange the BAP routing ID. ¶ [0074], These routing IDs may be exchanged between CU1 and CU2. In one example, CU1 may establish a BH RLC CH (e.g., the CH with ID=‘a’) between IAB-node 831 and IAB-node 832. CU2 may establish a BH RLC CH between IAB-node 831 and IAB-node 833. The two CUs may exchange a CH ID such as a BH RLC CH ID or LCD for the channel. ¶ [0075], The first IAB-donor-CU may also communicate a first BAP configuration associated with the backhaul routing path with the second IAB-donor-CU. ¶ [0077], the signaling connection may be RRC or F1 control plane (F1-C). The IAB-node may have a second signaling connection with the second IAB-donor-CU. Additionally, the second signaling connection may be RRC or F1-C.).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to obtain the first information with the second information at a DU of the IAB node, through a CU of the source IAB donor based on an F1AP in the system of Zhu to further improve industrial applicability.
9. Claims 20, 21, 27 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Liu et al. (US 2023/0262827 A1, hereinafter “Liu’27”).
Regarding claims 20 and 27, Liu teaches the method of claim 15, further comprising: receiving, at a mobile terminal (MT) of the IAB node from the source IAB donor, a radio resource control (RRC) message including a handover command (figs. 5, 6, ¶ [0046], The CU can configure the MT of the IAB node through the radio resource control (RRC) protocol. ¶ [0168], the switching command can include a switching configuration of the MT and BAP routing reconfiguration information of the F1-AP. The IAB node completes IAB-MT and BAP routing configuration according to the switching command; then, the IAB node sends MT switching completion and BAP reconfiguration completion information to the CU. After switching, the IAB node saves the BAP address of the original donor-DU. ¶ [0169], the IAB node can be the switching IAB node, or the downstream node of the switching IAB node. ¶ [0186]) and uplink configuration for the target path (figs. 5, 6, ¶ [0168], the switching command can include a switching configuration of the MT and BAP routing reconfiguration information of the F1-AP. ¶ [0169], Rewriting the BAP routing ID includes rewriting the destination BAP address of the BAP PDU to the address of the target donor DU, and/or rewriting the BAP path of the BAP PDU to BAP path of the target donor DU. ),
Liu does not explicitly teach uplink default configuration for the target path wherein the uplink default configuration including a default backhaul (BH) routing ID and a default BH radio link control (RLC) channel.
However, Liu’27 teaches receiving uplink default configuration for the target path wherein the uplink default configuration including a default backhaul (BH) routing ID and a default BH radio link control (RLC) channel (figs. 8, 9, ¶ [0197], Further, the IAB-donor-CU may further provide a default UL configuration for the recovery IAB-MT based on an RRC reconfiguration message. The default UL configuration includes: a configured default BH RLC channel that is used for UL F1-C/non-F1 service transmission and that is on the target path, a default backhaul adaptation protocol routing ID (backhaul adaptation protocol routing ID, BAP routing ID), and the like).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to receive a handover command including uplink default configuration, including BH routing ID and a default BH RLC channel for the target path where the uplink default configuration including a default backhaul (BH) routing ID and a default BH radio link control (RLC) channel to utilize conventional techniques in the art.
Regarding claims 21 and 28, Liu in view of Liu’27 teaches the method of claim 20, wherein the first information is obtained from the RRC message (Liu: fig. 2, ¶ [0046], The CU can configure the MT of the IAB node through the radio resource control (RRC) protocol. Liu’27: ¶ [0197).
Double Patenting
10. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
11. Claims 15 and 22 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 2, 8 and 9 of copending Application No. 18/725,554. Although the claims at issue are not identical, they are not patentably distinct from each other.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Regarding claim 15, claims 1 and 2 of the copending application teach a method performed by an integrated access and backhaul (IAB) node in a communication system, the method comprising: obtaining, from a central unit (CU) of a target IAB donor, first information on a backhaul adaptation protocol (BAP) header rewriting, wherein the first information including information on a mapping between an old routing identifier (ID) associated with a first topology of a source IAB donor and a new routing ID associated with a second topology of the target IAB donor; in case that a BAP packet to be considered for the BAP header rewriting is identified, rewriting a first routing ID of the first topology included in a header of the BAP packet to a second routing ID of the second topology corresponding to the first routing ID based on the first information; and
routing the BAP packet with the rewritten header, through a target path identified based on the second routing ID.
Claim 15 broadens the scope of claims 1 and 2 of the copending application by removing limitations (e.g., identifying whether a first link belonging to a topology of the second donor CU is available for routing the packet based on the BAP header rewriting operation; in case that a radio link failure (RLF) is detected for the first link, identifying, a second link belonging to a topology of the first donor CU to be used for routing the packet based on the configuration information; and in case that the second link is available, routing the packet on the second link).
Regarding claim 22, claims 8 and 9 of the copending application teach an integrated access and backhaul (IAB) node in a communication system, the IAB node comprising: a transceiver; and a controller configured to: obtain, from a central unit (CU) of a target IAB donor, first information on a backhaul adaptation protocol (BAP) header rewriting, wherein the first information including information on a mapping between an old routing identifier (ID) associated with a first topology of a source IAB donor and a new routing ID associated with a second topology of the target IAB donor, in case that a BAP packet to be considered for the BAP header rewriting is identified, rewrite a first routing ID of the first topology included in a header of the BAP packet to a second routing ID of the second topology corresponding to the first routing ID based on the first
information, and route the BAP packet with the rewritten header, through a target path identified based on the second routing ID.
Claim 22 broadens the scope of claims 8 and 9 of the copending application by removing limitations (e.g., identifying whether a first link belonging to a topology of the second donor CU is available for routing the packet based on the BAP header rewriting operation; in case that a radio link failure (RLF) is detected for the first link, identifying, a second link belonging to a topology of the first donor CU to be used for routing the packet based on the configuration information; and in case that the second link is available, routing the packet on the second link.).
Conclusion
12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MANDISH RANDHAWA whose telephone number is (571)270-5650. The examiner can normally be reached Monday-Thursday (9 AM-7 PM).
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, Chirag Shah can be reached at 571-272-3144. 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.
/MANDISH K RANDHAWA/Primary Examiner, Art Unit 2477