DETAILED ACTION
Applicant’s response filed on 12/04/2025 has been entered and made of record.
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 .
Claim Status
Claims 1, 5 and 8 are amended.
Claims 2 and 9 are cancelled.
No new claim is/are added.
Claims 1, 3-8 and 10-12 are pending for examination.
Response to Argument
Applicant’s arguments (remark pages 8-11), filed on 12/04/2025, with respect to claims 1, 3-8 and 10-12 have been considered but are moot in view of the new ground of rejection below which better address the claimed invention as amended.
This Office Action is made Final.
Claim Rejections - 35 USC § 103
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 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.
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 no obviousness.
Claims 1, 3-8 and 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Fujishiro et al. (US 20220386404 A1), hereinafter “Fujishiro”, in view of Teyeb et al.(US 20230127850 A1), hereinafter “Teyeb, in view of combination of Wu et al. (US 20230036769 A1), hereinafter “Wu” and Michail Litvak (“ip-route(8) — Linux manual page”), hereinafter “Litvak”.
Per claim 1, 5 and 8:
Regarding claim 8, Fujishiro teaches ‘An integrated access and backhaul (IAB) node’ (Fujishiro: [FIG.7]: “IAB-NODE 300-3”, “IAB NODE 300-2”, “IAB NODE 300-1” in a wireless communication system); ‘operating with a first cell group and a second cell group in a wireless communication system’ (Fujishiro: [0061]: “the IAB node 300 may include dual connectivity to two upper nodes. One of the two upper nodes is a master node (MN), and the other is a secondary node (SN). The BH link between the IAB node 300 and the MN may be referred to as a Master Cell Group (MCG) link, and the BH link between the IAB node 300 and the SN may be referred to as a Secondary Cell Group (SCG) link”); ‘the IAB node comprising: a transceiver and a controller” (Fujishiro: [FIG.3]: “IAB NODE”, “RECEIVER” “TRANSMITTER”, “CONTROLLER”);
‘configured to:
receive, from a first parent node related to the first cell group via the transceiver, a backhaul radio link failure (RLF) indication, consider an RLF is detected for the first cell group’ (Fujishiro: [0061]: “a Master Cell Group (MCG) link”; [FIG.7]: “300-1 IAB NODE” (parent node) -> “300-2 IAB NODE”: “BH RLF NOTIFICATION”; [FIG.13]: step S606: “BH RLF”, step S608: “RECOVERY FAILURE”, step S609: “TYPE 4 BH RLF NOTIFICATION”, “IAB NODE 300-2” receives a BH RLF indicator related to a BH RLF recovery failure of “IAB NODE 300-1” which could be related to a MCG link);
‘based on the backhaul RLF indication, suspend transmission for all data radio bearers (DRBs)’ (Fujishiro: [FIG.10]: S304: “STOP COMMUNICATION”; [0052]: “radio bearer”). However, Fujishiro fails to expressly teach suspend transmission for all DRBs;
‘a backhaul radio link control (RLC) channel related to the first cell group’ (Fujishiro: [FIG.10]: S304: “STOP COMMUNICATION”; [0229]: “suspend a scheduling request and other uplink transmissions”; [FIG.6]: “BH RLC channel”; [0061]: “a Master Cell Group (MCG) link”; suspend transmission through a BH RLC channel related to “IAB NODE 300-1” which could be related to MCG link);
‘update, based on the backhaul RLF indication, at least one routing entry in the IAB node, by removing a first routing entry having an egress link associated with the first parent node and replacing the first routing entry with a second routing entry having an egress link associated with a second parent node related to the second cell group’ (Fujishiro: [FIG.10]: S301: “BH RLF”; [0205]: “an alternative backhaul link and an alternative route”; [0061]: “the IAB node 300 may include dual connectivity to two upper nodes … Master Cell Group (MCG) link … Secondary Cell Group (SCG) link”, two parents in dual connection; [0110]: “the target node other than the IAB node 300-1 whether any radio link with the IAB node 300-2 can be established. The target node … may be the IAB node 300”, the other parent node in dual connection is among the IAB Node 300 as alternative route; could include the other parent node as alternate route to replace the failure parent node). However, Fujishiro fails to expressly teach update at least one routing entry in the IAB node by removing the routing entry associated with the failure parent node and replacing with the routing entry associated with the other parent node;
‘transmit, to the second parent node via the transceiver, a cell group failure information message, the cell group failure information message including information indicating that the cell group failure information message is associated with the reception of the backhaul RLF indication from the first parent node’ (Fujishiro: [0075]: “Type 4 (Recovery failure): Indicates that the IAB node 300 has failed to recover the BH link”; [FIG.12]: step: S407: “RRC Pre-connection Request”; [0126]: “RRC Pre-connection Request may include Cause information indicating the cause of transmission … the BH RLF of the IAB node 300-1 is the cause”; [0061]: “the IAB node 300 may include dual connectivity to two upper nodes … Master Cell Group (MCG) link … Secondary Cell Group (SCG) link”, two parents in dual connection; [0110]: “the target node other than the IAB node 300-1 whether any radio link with the IAB node 300-2 can be established. The target node … may be the IAB node 300”, the other parent node in dual connection is among the IAB Node 300; [FIG.3]: “TRANSMITTER”; indicate BH RLF toward an IAB donor gNB via target IAB node which can be the second parent node in dual connection of “IAB NODE 300-2”).
However, Teyeb in the same field of endeavor teaches suspend transmission for all DRBs by following the procedures of TS38.331 (Teyeb: [0153]-[0200]: “Begin text for 3GPP TS 38.331 … upon detecting radio link failure of the MCG … suspend MCG transmission for all SRBs and DRBs , except SRB0 … End text for 3GPP TS 38.331”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Teyeb’s teaching with that of Fujishiro in order to conform to 3GPP specification TS38.331 for promotion of corroboration and inter-operation (see reference quotes in element above).
Combination of Fujishiro and Teyeb does not expressly teach update at least one routing entry in the IAB node by removing the routing entry associated with the failure parent node and replacing with the routing entry associated with the other parent node and ‘routing information used by a backhaul adaptation protocol (BAP) layer in the IAB node when the RLF is detected, wherein the routing information includes an egress link identifier (ID) and a next hop ID mapped to each routing ID, and includes backhaul RLC channel mapping information used when the RLF is detected’.
However, Wu in the same field of endeavor teaches an IAB node would, upon detecting backhaul RLF, reselect a second egress link and a second next hop to re-route data (Wu: [FIG.1B]: “IAB node”; [FIG.2]: block 217: “routing”; [0057]: “At operation 217, the BAP entity may perform routing to select an egress link for transmitting the BAP data PDU. In some embodiments of the present disclosure, in case of a backhaul RLF on the selected egress link, the BAP entity may reselect another egress link to re-route the BAP data PDU”; [0062]: “a RLF may occur on the egress link associated with the selected routing ID. In these scenarios, the communication device may select or reselect a candidate routing identity from the at least one candidate routing identity, wherein an egress link associated with the selected candidate routing identity does not include the above-mentioned failed link”; [0072]: “an egress link corresponding to the next hop BAP address of an entry in the routing configuration”; [0005]: “detecting a failure on a first egress link between the communication device and a first next hop communication device of the communication device; re-routing first data intended to be transmitted on the first egress link, wherein the first data may have not been acknowledged by a layer lower than a Backhaul Adaptation Protocol (BAP) layer of the communication device; reselecting a second egress link between the communication device and a second next hop communication device based on the routing configuration; reselecting an egress Radio Link Control (RLC) channel of the second egress link based on bearer mapping configuration; and submitting the first data to the reselected egress RLC channel of the second egress link”; [0006]: “the first next hop communication device may be a parent node of the communication device. The method may further include in response to the failure on the first egress link and re-routing the first data to the second next hop communication device”; [0007]: “each candidate routing identity may indicate a BAP address, a BAP path identity, and a next hop BAP address … reselecting a candidate routing identity from the at least one candidate routing identity, wherein an egress link associated with the selected candidate routing identity may not include the failed first egress link”);
‘routing information used by a backhaul adaptation protocol (BAP) layer in the IAB node when the RLF is detected’ (Wu: [0062]: “a RLF may occur on the egress link associated with the selected routing ID. In these scenarios, the communication device may select or reselect a candidate routing identity from the at least one candidate routing identity”);
‘wherein the routing information includes an egress link identifier (ID) and a next hop ID mapped to each routing ID’ (Wu: [0007]: “each candidate routing identity may indicate a BAP address, a BAP path identity, and a next hop BAP address”; [0008]: “the routing configuration may include at least one entry, each entry may include a BAP address and a next hop BAP address. Each entry of the routing configuration may further include a path identity”; [0062]: “a RLF may occur on the egress link associated with the selected routing ID”; [0072]: “an egress link corresponding to the next hop BAP address of an entry in the routing configuration, which has the same BAP address as the BAP address in the BAP ADDRESS field of the BAP data PDU and a BAP path identity the same as the BAP path identity in the PATH field of the BAP data PDU”; [0073]: “each entry is associated with an egress link corresponding to the next hop BAP address of the entry”; [0078]: “an entry associated with the route “IAB node 120E->IAB node 120F->IAB node 120D” in the routing configuration, and may select the egress link from IAB node 120C to IAB node 120E for data transmission”; would include egress link ID (BAP address and path identity identifying an egress link) and next hop ID (next hop BAP address));
‘includes backhaul RLC channel mapping information used when the RLF is detected’ (Wu: [0005]: “detecting a failure on a first egress link … reselecting an egress Radio Link Control (RLC) channel of the second egress link based on bearer mapping configuration; and submitting the first data to the reselected egress RLC channel of the second egress link”).
And, Litvak in the same field of endeavor teaches ip route command to update route table by add, del or replace route with parameters such as next-hop ID and egress link ID (Litvak: [Page 1]: “ip route {add | del | change | append | replace} ROUTE”; [Page 19]: “ip route add default via 192.168.1.1 dev eth0”, where next-hop ID is “192.168.1.1”), egress link ID is “eth0”; [Page 7]: “via [ FAMILY ] ADDRESS - is the nexthop router. dev NAME - is the output device”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of combination of Wu and Litvak with that of combination of Fujishiro and Teyeb to update, based on the backhaul RLF indication, at least one routing entry in the IAB node, by removing a first routing entry having an egress link associated with the first parent node and replacing the first routing entry with a second routing entry having an egress link associated with a second parent node related to the second cell group in order to re-route data over other egress link upon detecting backhaul RLF (see reference quotes in element above).
Regarding claim 1, claim 1 recites the method implemented by the IAB node of claim 8 (see rejection of claim 8 above).
Regarding claim 5, Fujishiro teaches ‘A method performed by a first parent node related to a first cell group of an integrated access and backhaul (IAB) node’ (Fujishiro: [0005]: “A communication control method”; [FIG.7]: “IAB NODE 300-1”, parent of “IAB NODE 300-2”); ‘the IAB node operating with the first cell group and a second cell group, in a wireless communication system’ (Fujishiro: [0061]: “the IAB node 300 may include dual connectivity to two upper nodes. One of the two upper nodes is a master node (MN), and the other is a secondary node (SN). The BH link between the IAB node 300 and the MN may be referred to as a Master Cell Group (MCG) link, and the BH link between the IAB node 300 and the SN may be referred to as a Secondary Cell Group (SCG) link”; “IAB NODE 300-1” could be MCG in dual connection);
‘the method comprising:
detecting a backhaul radio link failure (RLF) recovery failure (Fujishiro: [FIG.13]: step S606: “BH RLF”, step 608: “RECOVERY FAILURE”, “IAB NODE 300-1” detects a recovery failure);
‘transmitting, to the IAB node, a backhaul RLF indication based on the detection of the backhaul RLF recovery failure’ (Fujishiro: [FIG.7]: “300-1 IAB NODE” -> “300-2 IAB NODE”: “BH RLF NOTIFICATION”; [FIG.3]: “TRANSMITTER”; [FIG.13]: step 609: “TYPE 4 BH RLF NOTIFICATION”, “IAB NODE 300-1”; transmit a BH RLF indicator related to a BH RLF recovery failure to “IAB NODE 300-2”);
‘suspending reception for all data radio bearers (DRBs)’ (Fujishiro: [FIG.10]: S304: “STOP COMMUNICATION”; [0052]: “radio bearer”). However, Fujishiro fails to expressly teach suspending reception for all DRBs;
‘a backhaul radio link control (RLC) channel related to the first cell group’ (Fujishiro: [FIG.10]: S304: “STOP COMMUNICATION”; [0229]: “suspend a scheduling request and other uplink transmissions”; [FIG.6]: “BH RLC channel”; [0061]: “the IAB node 300 may include dual connectivity to two upper nodes … Master Cell Group (MCG) link … Secondary Cell Group (SCG) link”; suspend a reception for a BH RLC channel over MCG link in dual connection);
‘wherein an RLF for the first cell group is considered to be detected according to the backhaul RLF indication’ (Fujishiro: [FIG.13]: step: S606: “BH RLF” indicator, [0166]: “the MT of the IAB node 300-1 detects a BH RLF with the donor gNB”; [0075]: “Indicates that the IAB node 300 has failed to recover the BH link”),
‘wherein the backhaul RLF indication triggers the IAB node to transmit a cell group failure information message to a second parent node related to the second cell group’ (Fujishiro: [FIG.12]: step: S407: “RRC Pre-connection Request”; [0061]: “the IAB node 300 may include dual connectivity to two upper nodes … Master Cell Group (MCG) link … Secondary Cell Group (SCG) link”, two parents in dual connection; [0110]: “the target node other than the IAB node 300-1 whether any radio link with the IAB node 300-2 can be established. The target node … may be the IAB node 300”, the other parent node in dual connection is among the IAB Node 300; transmit BH RLF toward an IAB donor gNB via target IAB node which can be the second parent node in dual connection of “IAB NODE 300-2” in response to BH RLF);
‘the cell group failure information message including information indicating that the cell group failure information message is associated with a reception, by the IAB node, of the backhaul RLF indication from the first parent node’ (Fuji Shiro: [0075]: “Type 4 (Recovery failure): Indicates that the IAB node 300 has failed to recover the BH link”; [0126]: “RRC Pre-connection Request may include Cause information indicating the cause of transmission … the BH RLF of the IAB node 300-1 is the cause”; BH RLF related to “IAB node 300-1” (the parent MCG link of “IAB node 300-2” in dual connection));
‘wherein, based on the backhaul RLF indication, at least one routing entry in the IAB node is updated by removing a routing entry having an egress link associated with the first parent node and replacing the first routing entry with a second routing entry having an egress link associated with the second parent node’ (Fujishiro: [FIG.10]: S301: “BH RLF”; [0205]: “an alternative backhaul link and an alternative route”; [0061]: “the IAB node 300 may include dual connectivity to two upper nodes … Master Cell Group (MCG) link … Secondary Cell Group (SCG) link”, two parents in dual connection; [0110]: “the target node other than the IAB node 300-1 whether any radio link with the IAB node 300-2 can be established. The target node … may be the IAB node 300”, the other parent node in dual connection is among the IAB Node 300 as alternative route; could include the other parent node as alternate route to replace the failure parent node). However, Fujishiro fails to expressly teach update at least one routing entry in the IAB node by removing the routing entry associated with the failure parent node and replacing with the routing entry associated with the other parent node.
However, Teyeb teaches suspending reception for all DRBs by following the procedures of TS38.331 (Teyeb: [0153]-[0200]: “Begin text for 3GPP TS 38.331 … upon detecting radio link failure of the MCG … suspend MCG transmission for all SRBs and DRBs , except SRB0 … End text for 3GPP TS 38.331”; suspend reception of all DRBs over the failure link).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Teyeb’s teaching with that of Fujishiro in order to conform to 3GPP specification TS38.331 for promotion of corroboration and inter-operation (see reference quotes in element above).
Combination of Fujishiro and Teyeb does not expressly teach update at least one routing entry in the IAB node by removing the routing entry associated with the failure parent node and replacing with the routing entry associated with the other parent node and ‘routing information used by a backhaul adaptation protocol (BAP) layer in the IAB node when the RLF is detected, wherein the routing information includes an egress link identifier (ID) and a next hop ID mapped to each routing ID, and includes backhaul RLC channel mapping information used when the RLF is detected’.
However, Wu teaches an IAB node would, upon detecting backhaul RLF, reselect a second egress link and a second next hop to re-route data (Wu: [FIG.1B]: “IAB node”; [FIG.2]: block 217: “routing”; [0057]: “At operation 217, the BAP entity may perform routing to select an egress link for transmitting the BAP data PDU. In some embodiments of the present disclosure, in case of a backhaul RLF on the selected egress link, the BAP entity may reselect another egress link to re-route the BAP data PDU”; [0062]: “a RLF may occur on the egress link associated with the selected routing ID. In these scenarios, the communication device may select or reselect a candidate routing identity from the at least one candidate routing identity, wherein an egress link associated with the selected candidate routing identity does not include the above-mentioned failed link”; [0072]: “an egress link corresponding to the next hop BAP address of an entry in the routing configuration”; [0005]: “detecting a failure on a first egress link between the communication device and a first next hop communication device of the communication device; re-routing first data intended to be transmitted on the first egress link, wherein the first data may have not been acknowledged by a layer lower than a Backhaul Adaptation Protocol (BAP) layer of the communication device; reselecting a second egress link between the communication device and a second next hop communication device based on the routing configuration; reselecting an egress Radio Link Control (RLC) channel of the second egress link based on bearer mapping configuration; and submitting the first data to the reselected egress RLC channel of the second egress link”; [0006]: “the first next hop communication device may be a parent node of the communication device. The method may further include in response to the failure on the first egress link and re-routing the first data to the second next hop communication device”; [0007]: “each candidate routing identity may indicate a BAP address, a BAP path identity, and a next hop BAP address … reselecting a candidate routing identity from the at least one candidate routing identity, wherein an egress link associated with the selected candidate routing identity may not include the failed first egress link”);
‘routing information used by a backhaul adaptation protocol (BAP) layer in the IAB node when the RLF is detected’ (Wu: [0062]: “a RLF may occur on the egress link associated with the selected routing ID. In these scenarios, the communication device may select or reselect a candidate routing identity from the at least one candidate routing identity”);
‘wherein the routing information includes an egress link identifier (ID) and a next hop ID mapped to each routing ID’ (Wu: [0007]: “each candidate routing identity may indicate a BAP address, a BAP path identity, and a next hop BAP address”; [0008]: “the routing configuration may include at least one entry, each entry may include a BAP address and a next hop BAP address. Each entry of the routing configuration may further include a path identity”; [0062]: “a RLF may occur on the egress link associated with the selected routing ID”; [0072]: “an egress link corresponding to the next hop BAP address of an entry in the routing configuration, which has the same BAP address as the BAP address in the BAP ADDRESS field of the BAP data PDU and a BAP path identity the same as the BAP path identity in the PATH field of the BAP data PDU”; [0073]: “each entry is associated with an egress link corresponding to the next hop BAP address of the entry”; [0078]: “an entry associated with the route “IAB node 120E->IAB node 120F->IAB node 120D” in the routing configuration, and may select the egress link from IAB node 120C to IAB node 120E for data transmission”; would include egress link ID (BAP address and path identity identifying an egress link) and next hop ID (next hop BAP address));
‘includes backhaul RLC channel mapping information used when the RLF is detected’ (Wu: [0005]: “detecting a failure on a first egress link … reselecting an egress Radio Link Control (RLC) channel of the second egress link based on bearer mapping configuration; and submitting the first data to the reselected egress RLC channel of the second egress link”).
And, Litvak teaches ip route command to update route table by add, del or replace route with parameters such as next-hop ID and egress link ID (Litvak: [Page 1]: “ip route {add | del | change | append | replace} ROUTE”; [Page 19]: “ip route add default via 192.168.1.1 dev eth0”, where next-hop ID is “192.168.1.1”), egress link ID is “eth0”; [Page 7]: “via [ FAMILY ] ADDRESS - is the nexthop router. dev NAME - is the output device”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of combination of Wu and Litvak with that of combination of Fujishiro and Teyeb to update, based on the backhaul RLF indication, at least one routing entry in the IAB node by removing a routing entry having an egress link associated with the first parent node and replacing the first routing entry with a second routing entry having an egress link associated with the second parent node in order to re-route data over other egress link upon detecting backhaul RLF (see reference quotes in element above).
Regarding claim 3, combination of Fujishiro, Teyeb, Wu and Litvak teaches the method of claim 1 (discussed above).
Fujishiro teaches ‘wherein the first cell group comprises a master cell group (MCG)’ (Fujishiro: [0061]: “a Master Cell Group (MCG) link”, first cell group may be a MCG);
‘wherein the second cell group comprises a secondary cell group (SCG)’ (Fujishiro: [0061]: “a Secondary Cell Group (SCG) link”, second cell group may be a SCG).
Fujishiro does not expressly teach, but Teyeb teaches ‘wherein the cell group failure information message is transmitted through a split signaling radio bearer (SRB) 1 or an SRB 3’ (Teyeb: [0145]: “reports the failure with an MCG Failure Information message to the MN via the SCG, using the SCG leg of split SRB1 or SRB3”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Teyeb’s teaching with that of Fujishiro in order to report MCG failure via SCG (see reference quotes in element above).
Per claim 4, 7 and 12:
Regarding claim 12, combination of Fujishiro, Teyeb, Wu and Litvak teaches the IAB node of claim 8 (discussed above).
Fujishiro teaches ‘wherein the first cell group comprises a secondary cell group (SCG)’ (Fujishiro: [0061]: “a Secondary Cell Group (SCG) link”, first cell group may be SCG);
‘wherein the second cell group comprises a master cell group (MCG)’ (Fujishiro: [0061]: “a Master Cell Group (MCG) link”, second cell group may be MCG).
Regarding claim 4, claim 4 recites the method implemented by the IAB node of claim 12 (see rejection of claim 12 above).
Regarding claim 7, combination of Fujishiro, Teyeb, Wu and Litvak teaches the method of claim 5 (discussed above).
Fujishiro teaches ‘wherein the first cell group comprises a secondary cell group (SCG)’ (Fujishiro: [0061]: “a Secondary Cell Group (SCG) link”, first cell group may be SCG);
‘wherein the second cell group comprises a master cell group (MCG)’ (Fujishiro: [0061]: “a Master Cell Group (MCG) link”, second cell group may be MCG).
Regarding claim 6, combination of Fujishiro, Teyeb, Wu and Litvak teaches the method of claim 5 (discussed above).
Fujishiro teaches ‘wherein the first cell group comprises a master cell group (MCG)’ (Fujishiro: [0061]: “a Master Cell Group (MCG) link”, first cell group may be MCG);
‘wherein the second cell group comprises a secondary cell group (SCG)’ (Fujishiro: [0061]: “a Secondary Cell Group (SCG) link”, second cell group may be SCG).
Fujishiro does not expressly teach, but Teyeb teaches ‘wherein the cell group failure information message is transmitted through a split signaling radio bearer (SRB) 1 or an SRB 3’ (Teyeb: [0145]: “reports the failure with an MCG Failure Information message to the MN via the SCG, using the SCG leg of split SRB1 or SRB3”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Teyeb’s teaching with that of Fujishiro in order to report MCG failure via SCG leg (see reference quotes in element above).
Regarding claim 10, combination of Fujishiro, Teyeb, Wu and Litvak teaches the IAB node of claim 8 (discussed above).
Fujishiro teaches ‘wherein the first cell group comprises a master cell group (MCG)” (Fujishiro: [0061]: “a Master Cell Group (MCG) link”, first cell group may be MCG);
‘wherein the second cell group comprises a secondary cell group (SCG)’ (Fujishiro: [0061]: “a Secondary Cell Group (SCG) link”, second cell group may be SCG).
Regarding claim 11, combination of Fujishiro, Teyeb, Wu and Litvak teaches the IAB node of claim 10 (discussed above).
Fujishiro does not expressly teach, but Teyeb teaches ‘wherein the cell group failure information message is transmitted through a split signaling radio bearer (SRB) 1 or an SRB 3’ (Teyeb: [0145]: “reports the failure with an MCG Failure Information message to the MN via the SCG, using the SCG leg of split SRB1 or SRB3”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Teyeb’s teaching with that of Fujishiro in order to report MCG failure via SCG leg (see reference quotes in element above).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GUOXING FAN whose telephone number is (703)756-1310. The examiner can normally be reached Monday - Friday 8:30am - 5:30pm.
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, Yemane Mesfin can be reached at (571)272-3927. 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.
/G.F./Examiner, Art Unit 2462
/YEMANE MESFIN/Supervisory Patent Examiner, Art Unit 2462