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 .
Response to Arguments
Applicant's arguments filed 04/27/2026 with respect to claim(s) 1, 8, and 15 have been considered but are moot in view of the new ground(s) of rejection under 103 based on new reference Zhu et al. (US 2023/0319649 A1) in view of previously cited references Rönneke et al. (US 2023/0309189 A1) and Ianev et al. (US 2022/0264504 A1).
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 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.
Claim(s) 1-3, 8, 11-13, 15-16, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US 2023/0319649 A1) in view of Rönneke et al. (US 2023/0309189 A1) and Ianev et al. (US 2022/0264504 A1).
Regarding claims 1 and 15, Zhu discloses A data transmission method executed by a first network node and A first network node, comprising a processor, a memory, and a program or instructions stored in the memory and capable of running on the processor, wherein the program or instructions are executed by the processor, to implement the following steps (Fig. 3: AF includes a processor and a storage unit comprising program code), comprising:
sending first data to a second network node according to whether the second network node supports a first capability ([0136]: based on the RAN node information within the notification, the AF acknowledges that the UE has joined the MBS session and that whether the serving RAN of the UE supports the MBS and/or whether the serving RAN of the UE has the MBS session context and/or whether the MBS session corresponding to the TMGI is activated in the serving RAN of the UE. Based on the RAN node information in the notification, the AF determines using a unicast PDU session or an MBS session to deliver the MBS to the UE. Fig. 6B, [0157]: In step 613, see Fig. 6B, the AF sends downlink traffic (e.g. MBS downlink data) towards the UPF+BMSC-U IP address and port number. In this embodiment, the UPF2 with the BMSC-U generates the MBS downlink traffic (e.g. by using the IP multicast address as a target IP address) and forwards the MBS downlink data towards the RAN via the shared N3 tunnel of the MBS session. Fig. 7A, [0163]: the UE receives the MBS (e.g. the MBS downlink data) via an MBS session through the RAN1 (step 701)); wherein
the first data comprises the following:
a broadcast indication ([0136], Fig. 6B, [0157], Fig. 7A, [0163]: MBS downlink data via an MBS session. [0103]: For the MBS session, a single N3 tunnel between the RAN2 and the UPF2 may be shared by the group of the UEs);
Zhu does not disclose, but Rönneke discloses when the second network node meets the following, it is determined that the second network node supports the first capability (Fig. 3, [0038], [0064]: RAN 10 supports multicast distribution which is the implementation of 5GC Shared MBS traffic delivery method):
the second network node supports transmitting Multimedia Broadcast and Multicast Service (MBMS) or Multicast/Broadcast Service (MBS) data through shared delivery in the core network portion (Fig. 3, [0038], [0064]: RAN 10 supports multicast distribution which is the implementation of 5GC Shared MBS traffic delivery method. [0008]: 5GC Shared MBS traffic delivery method: 5G CN receives a single copy of MBS data packets and delivers a single copy of those MBS packets packet to a radio access node (RAN) node, which then delivers them to one or multiple UEs);
when the second network node meets the following, it is determined that the second network node does not support the first capability (Fig. 3, [0038], [0064]: RAN 10 supports unicast distribution via PDU session which is the implementation of 5GC Individual MBS traffic delivery method):
the second network node does not support transmitting MBMS or MBS data through shared delivery in the core network portion, but supports transmitting MBMS or MBS data separately through a protocol data unit session (PDU session) or through individual delivery in the core network portion (Fig. 3, [0038], [0064]: RAN 10 supports unicast distribution via PDU session which is the implementation of 5GC Individual MBS traffic delivery method. [0009]: If 5GC Individual MBS traffic delivery method is supported, a same received single copy of MBS data packets by the 5G CN may be delivered via 5GC Individual MBS traffic delivery method for some UE(s). [0010]: the “5GC Individual MBS traffic delivery method” could be utilized for UEs 12 within NG-RAN 10 without 5MBS support).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhu with the teachings of Rönneke.
Doing so uses solution #3 in chapter 6.3 of TR 23.757 v0.4.0 which is a main solution for 5MBS Multicast support based on architecture option #1 where both 5GC Shared MBS traffic delivery method” and “5GC Individual MBS traffic delivery method” have been defined (Rönneke: [0038]).
Zhu in view of Rönneke does not disclose, but Ianev discloses the second network node is at least one of the following:
a second base station located within a radio access network-based notification area RNA;
a second base station located within a registration area RA (Fig. 8, [0141]: AMF 750 sends a Paging message to the RAN nodes 5 in the UE's registration area and includes as a parameters the UE Id and the paged user's id, i.e. temporary user Id for user 1. [0086]: When the UE 3 changes the registration area, the AMF 750 may change the temporary user Id for the user);
a base station of a recommended cell determined based on the terminal identifier;
a base station determined based on the terminal identifier;
a base station of a cell corresponding to radio access network paging area information determined based on the terminal identifier; or
a base station corresponding to a RAN area identifier in a radio access network paging area determined based on the terminal identifier.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhu in view of Rönneke as outlined above with the teachings of Ianev.
Doing so allows the AMF to perform separate paging procedures with the temporary user Id so that the RAN node pages the UE with the temporary user Id allowing the UE to establish RRC connection (Ianev: Fig. 8, [0140]-[0143]).
Regarding claim(s) 2 and 16, Zhu in view of Rönneke and Ianev discloses all features of claim(s) 1 and 15 as outlined above.
Zhu discloses wherein the sending the first data to the second network node according to whether the second network node supports a first capability comprises the following:
sending a broadcast indication to the second network node in a case that the second network node supports the first capability ([0136]: based on the RAN node information within the notification, the AF acknowledges that the UE has joined the MBS session and that whether the serving RAN of the UE supports the MBS and/or whether the serving RAN of the UE has the MBS session context and/or whether the MBS session corresponding to the TMGI is activated in the serving RAN of the UE. Based on the RAN node information in the notification, the AF determines using a unicast PDU session or an MBS session to deliver the MBS to the UE. Fig. 6B, [0157]: In step 613, see Fig. 6B, the AF sends downlink traffic (e.g. MBS downlink data) towards the UPF+BMSC-U IP address and port number. In this embodiment, the UPF2 with the BMSC-U generates the MBS downlink traffic (e.g. by using the IP multicast address as a target IP address) and forwards the MBS downlink data towards the RAN via the shared N3 tunnel of the MBS session. Fig. 7A, [0163]: the UE receives the MBS (e.g. the MBS downlink data) via an MBS session through the RAN1 (step 701)), wherein the broadcast indication is used to notify the second network node to send a broadcast message ([0136], Fig. 6B, [0157], Fig. 7A, [0163]: MBS downlink data sent from AF to UPF2 to RAN1 to UE via an MBS session. [0103]: For the MBS session, a single N3 tunnel between the RAN2 and the UPF2 may be shared by the group of the UEs).
Regarding claim(s) 3, Zhu in view of Rönneke and Ianev discloses all features of claim(s) 1 as outlined above.
Zhu discloses wherein the first data comprises at least one of the following ([0136], Fig. 6B, [0157], Fig. 7A, [0163]: MBS downlink data via an MBS session):
the terminal identifier;
a service identifier (Fig. 6B, [0157]: In step 613, see Fig. 6B, the AF sends downlink traffic (e.g. MBS downlink data). Fig. 7A, [0163]: the UE receives the MBS (e.g. the MBS downlink data) via an MBS session); or
a session identifier (Fig. 6B, [0157]: In step 613, see Fig. 6B, the AF sends downlink traffic (e.g. MBS downlink data). Fig. 7A, [0163]: the UE receives the MBS (e.g. the MBS downlink data) via an MBS session); and/or,
wherein the first network node is at least one of the following:
a first base station; or
a core network function (Fig. 3: AF).
Regarding claim 8, Zhu discloses A data transmission method executed by a second network node (Figs. 5, 6B, 7A: RAN), the method comprising:
receiving first data sent by a first network node ([0136]: based on the RAN node information within the notification, the AF acknowledges that the UE has joined the MBS session and that whether the serving RAN of the UE supports the MBS and/or whether the serving RAN of the UE has the MBS session context and/or whether the MBS session corresponding to the TMGI is activated in the serving RAN of the UE. Based on the RAN node information in the notification, the AF determines using a unicast PDU session or an MBS session to deliver the MBS to the UE. Fig. 6B, [0157]: In step 613, see Fig. 6B, the AF sends downlink traffic (e.g. MBS downlink data) towards the UPF+BMSC-U IP address and port number. In this embodiment, the UPF2 with the BMSC-U generates the MBS downlink traffic (e.g. by using the IP multicast address as a target IP address) and forwards the MBS downlink data towards the RAN via the shared N3 tunnel of the MBS session. Fig. 7A, [0163]: the UE receives the MBS (e.g. the MBS downlink data) via an MBS session through the RAN1 (step 701)); wherein
the first data comprises the following:
a broadcast indication ([0136], Fig. 6B, [0157], Fig. 7A, [0163]: MBS downlink data via an MBS session. [0103]: For the MBS session, a single N3 tunnel between the RAN2 and the UPF2 may be shared by the group of the UEs);
wherein after the receiving first data sent by a first network node, the method further comprises at least one of the following (Figs. 6B, 7A: RAN1 receives MBS downlink data):
skipping sending second data to a terminal in a case that the second network node does not support a first capability and the first data is a broadcast indication;
sending the second data to the terminal in a case that the second network node supports the first capability and the first data is a broadcast indication (Figs. 6B, 7A: RAN1 transmits MBS downlink data to the UE via an MBS session. [0136]: based on the RAN node information within the notification, the AF acknowledges that the UE has joined the MBS session and that whether the serving RAN of the UE supports the MBS and/or whether the serving RAN of the UE has the MBS session context and/or whether the MBS session corresponding to the TMGI is activated in the serving RAN of the UE. Based on the RAN node information in the notification, the AF determines using a unicast PDU session or an MBS session to deliver the MBS to the UE. [0103]: For the MBS session, a single N3 tunnel between the RAN2 and the UPF2 may be shared by the group of the UEs); or
Zhu does not disclose, but Rönneke discloses wherein when the second network node meets the following, it is determined that the second network node supports the first capability (Fig. 3, [0038], [0064]: RAN 10 supports multicast distribution which is the implementation of 5GC Shared MBS traffic delivery method):
the second network node supports transmitting Multimedia Broadcast and Multicast Service (MBMS) or Multicast/Broadcast Service (MBS) data through shared delivery in the core network portion (Fig. 3, [0038], [0064]: RAN 10 supports multicast distribution which is the implementation of 5GC Shared MBS traffic delivery method. [0008]: 5GC Shared MBS traffic delivery method: 5G CN receives a single copy of MBS data packets and delivers a single copy of those MBS packets packet to a radio access node (RAN) node, which then delivers them to one or multiple UEs);
wherein when the second network node meets the following, it is determined that the second network node does not support the first capability (Fig. 3, [0038], [0064]: RAN 10 supports unicast distribution via PDU session which is the implementation of 5GC Individual MBS traffic delivery method):
the second network node does not support transmitting MBMS or MBS data through shared delivery in the core network portion, but supports transmitting MBMS or MBS data separately through a protocol data unit session (PDU session) or through individual delivery in the core network portion (Fig. 3, [0038], [0064]: RAN 10 supports unicast distribution via PDU session which is the implementation of 5GC Individual MBS traffic delivery method. [0009]: If 5GC Individual MBS traffic delivery method is supported, a same received single copy of MBS data packets by the 5G CN may be delivered via 5GC Individual MBS traffic delivery method for some UE(s). [0010]: the “5GC Individual MBS traffic delivery method” could be utilized for UEs 12 within NG-RAN 10 without 5MBS support).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhu as outlined above with the teachings of Rönneke.
Doing so uses solution #3 in chapter 6.3 of TR 23.757 v0.4.0 which is a main solution for 5MBS Multicast support based on architecture option #1 where both 5GC Shared MBS traffic delivery method” and “5GC Individual MBS traffic delivery method” have been defined (Rönneke: [0038]).
Zhu in view of Rönneke does not disclose, but Ianev discloses the second network node is at least one of the following:
a second base station located within a radio access network-based notification area RNA;
a second base station located within a registration area RA (Fig. 8, [0141]: AMF 750 sends a Paging message to the RAN nodes 5 in the UE's registration area and includes as a parameters the UE Id and the paged user's id, i.e. temporary user Id for user 1. [0086]: When the UE 3 changes the registration area, the AMF 750 may change the temporary user Id for the user);
a base station of a recommended cell determined based on the terminal identifier;
a base station determined based on the terminal identifier;
a base station of a cell corresponding to radio access network paging area information determined based on the terminal identifier; or
a base station corresponding to a RAN area identifier in a radio access network paging area determined based on the terminal identifier.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhu in view of Rönneke as outlined above with the teachings of Ianev.
Doing so allows the AMF to perform separate paging procedures with the temporary user Id so that the RAN node pages the UE with the temporary user Id allowing the UE to establish RRC connection (Ianev: Fig. 8, [0140]-[0143]).
Regarding claim 18, Zhu in view of Rönneke and Ianev discloses A second network node, comprising a processor, a memory, and a program or instructions stored in the memory and capable of running on the processor, wherein when the program or instructions are executed by the processor, the steps of the data transmission method according to claim 8 are implemented (Zhu’s Fig. 3: RAN includes a processor and a storage unit comprising program code).
Regarding claim(s) 11, Zhu in view of Rönneke and Ianev discloses all features of claim(s) 8 as outlined above.
Zhu discloses wherein the first data comprises at least one of the following:
the terminal identifier;
a service identifier (Fig. 6B, [0157]: In step 613, see Fig. 6B, the AF sends downlink traffic (e.g. MBS downlink data). Fig. 7A, [0163]: the UE receives the MBS (e.g. the MBS downlink data) via an MBS session); or
a session identifier (Fig. 6B, [0157]: In step 613, see Fig. 6B, the AF sends downlink traffic (e.g. MBS downlink data). Fig. 7A, [0163]: the UE receives the MBS (e.g. the MBS downlink data) via an MBS session).
Regarding claim(s) 12, Zhu in view of Rönneke and Ianev discloses all features of claim(s) 8 as outlined above.
Zhu discloses wherein after the receiving first data sent by a first network node, the method further comprises (Figs. 6B, 7A: RAN1 receives MBS downlink data):
sending second data based on the first data through air interface (Figs. 6B, 7A: RAN1 transmits MBS downlink data to the UE via an MBS session. [0136]: based on the RAN node information within the notification, the AF acknowledges that the UE has joined the MBS session and that whether the serving RAN of the UE supports the MBS and/or whether the serving RAN of the UE has the MBS session context and/or whether the MBS session corresponding to the TMGI is activated in the serving RAN of the UE. Based on the RAN node information in the notification, the AF determines using a unicast PDU session or an MBS session to deliver the MBS to the UE. [0103]: For the MBS session, a single N3 tunnel between the RAN2 and the UPF2 may be shared by the group of the UEs);
wherein the sending second data to a terminal based on the first data through air interface comprises at least one of the following:
sending the second data to the terminal based on the broadcast indication in the first data (Figs. 6B, 7A: RAN1 transmits MBS downlink data to the UE via an MBS session. [0136]: based on the RAN node information within the notification, the AF acknowledges that the UE has joined the MBS session and that whether the serving RAN of the UE supports the MBS and/or whether the serving RAN of the UE has the MBS session context and/or whether the MBS session corresponding to the TMGI is activated in the serving RAN of the UE. Based on the RAN node information in the notification, the AF determines using a unicast PDU session or an MBS session to deliver the MBS to the UE. [0103]: For the MBS session, a single N3 tunnel between the RAN2 and the UPF2 may be shared by the group of the UEs); or
sending the second data to the terminal based on the first received first data (Figs. 6B, 7A: RAN1 transmits MBS downlink data to the UE via an MBS session. [0136]: based on the RAN node information within the notification, the AF acknowledges that the UE has joined the MBS session and that whether the serving RAN of the UE supports the MBS and/or whether the serving RAN of the UE has the MBS session context and/or whether the MBS session corresponding to the TMGI is activated in the serving RAN of the UE. Based on the RAN node information in the notification, the AF determines using a unicast PDU session or an MBS session to deliver the MBS to the UE. [0103]: For the MBS session, a single N3 tunnel between the RAN2 and the UPF2 may be shared by the group of the UEs).
Regarding claim(s) 13, Zhu in view of Rönneke and Ianev discloses all features of claim(s) 8 as outlined above.
Zhu discloses wherein the second data comprises at least one of the following:
a second paging indication; or
a broadcast message;
wherein the broadcast message comprises at least one of the following:
scheduling information;
service information; or
state information; and/or,
wherein the first network node is at least one of the following:
a first base station; or
a core network function (Fig. 3: AF).
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US 2023/0319649 A1) in view of Rönneke et al. (US 2023/0309189 A1), Ianev et al. (US 2022/0264504 A1) and Watanabe et al. (US 2004/0248574 A1).
Regarding claim(s) 5, Zhu in view of Rönneke and Ianev discloses all features of claim(s) 1 as outlined above.
Zhu does not disclose, but Watanabe discloses wherein the radio access network-based notification area and/or the registration area are determined based on the terminal identifier (Fig. 4, [0123]: determine to which location registration area LA#A, LA#B, or LA#C the paging is performed depending on the application Y. In table 40b, the mobile terminal identifier MT#1 is associated with the location registration area information LA_B#1 as a paging area for the application Y).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhu as outlined above with the teachings of Watanabe.
Doing so provides the method of determining a location registration area as a paging area and to select the corresponding radio system for paging (Watanabe: [0123]).
Claim(s) 6, 9-10, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US 2023/0319649 A1) in view of Rönneke et al. (US 2023/0309189 A1), Ianev et al. (US 2022/0264504 A1), and Jung et al. (US 2014/0029580 A1).
Regarding claim(s) 6, Zhu in view of Rönneke and Ianev discloses all features of claim(s) 1 as outlined above.
Zhu does not disclose, but Jung discloses wherein the broadcast indication comprises at least one of the following (Fig. 5, [0075]: source base station sends MBMS control request indication to target base station in S505):
a first broadcast indication, used to indicate that the second network node broadcasts service information or state information (Fig. 5, [0075]: the MBMS control request indication is information in which the source base station requests controlling the MBMS to the target base station in order to assure MBMS continuity of the user equipment and may include the same form or the same information as the MBMS service indication. For example, the MBMS control request indication may indicate whether the user equipment receives the MBMS. Alternatively, the MBMS control request indication may indicate the type of the MBMS received by the user equipment. Alternatively, the MBMS control request indication may include the MBMS interest information. The MBMS control request indication may be information defined in the X2 interface); or
a second broadcast indication, used to indicate that the second network node broadcasts scheduling information (Fig. 5, [0075]: the MBMS control request indication is information in which the source base station requests controlling the MBMS to the target base station in order to assure MBMS continuity of the user equipment and may include the same form or the same information as the MBMS service indication. The MBMS control request indication may include the MBMS interest information. [0079]: The target base station verifies the received MBMS and MBMS interest information and prefers a service in which the MBMS interest information is set to 1 among the MBMSs to set and schedule the MBMS).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhu as outlined above with the teachings of Jung.
Doing so provides a handover method for service continuity in an MBMS (Jung: Fig. 5, [0066]).
Regarding claim(s) 9 and 19, Zhu in view of Rönneke and Ianev discloses all features of claim(s) 8 and 18 as outlined above.
Zhu does not disclose, but Jung discloses wherein the broadcast indication comprises at least one of the following (Fig. 5, [0075]: source base station sends MBMS control request indication to target base station in S505):
a first broadcast indication, used to indicate that the second network node broadcasts service information or state information (Fig. 5, [0075]: the MBMS control request indication is information in which the source base station requests controlling the MBMS to the target base station in order to assure MBMS continuity of the user equipment and may include the same form or the same information as the MBMS service indication. For example, the MBMS control request indication may indicate whether the user equipment receives the MBMS. Alternatively, the MBMS control request indication may indicate the type of the MBMS received by the user equipment. Alternatively, the MBMS control request indication may include the MBMS interest information. The MBMS control request indication may be information defined in the X2 interface); or
a second broadcast indication, used to indicate that the second network node broadcasts scheduling information (Fig. 5, [0075]: the MBMS control request indication is information in which the source base station requests controlling the MBMS to the target base station in order to assure MBMS continuity of the user equipment and may include the same form or the same information as the MBMS service indication. The MBMS control request indication may include the MBMS interest information. [0079]: The target base station verifies the received MBMS and MBMS interest information and prefers a service in which the MBMS interest information is set to 1 among the MBMSs to set and schedule the MBMS).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhu as outlined above with the teachings of Jung.
Doing so provides a handover method for service continuity in an MBMS (Jung: Fig. 5, [0066]).
Regarding claim(s) 10, Zhu in view of Rönneke, Ianev, and Jung discloses all features of claim(s) 9 as outlined above.
Zhu does not disclose, but Jung discloses wherein in a case that the broadcast indication comprises the first broadcast indication and the second broadcast indication (Fig. 5, [0075]: the MBMS control request indication is information in which the source base station requests controlling the MBMS to the target base station in order to assure MBMS continuity of the user equipment and may include the same form or the same information as the MBMS service indication. For example, the MBMS control request indication may indicate whether the user equipment receives the MBMS. Alternatively, the MBMS control request indication may indicate the type of the MBMS received by the user equipment. Alternatively, the MBMS control request indication may include the MBMS interest information. The MBMS control request indication may be information defined in the X2 interface. [0079]: The target base station verifies the received MBMS and MBMS interest information and prefers a service in which the MBMS interest information is set to 1 among the MBMSs to set and schedule the MBMS), the method further comprises:
performing a first operation and a second operation; wherein
the first operation comprises broadcasting the service information and/or state information through air interface (Fig. 5, [0090]: target base station transmits the same MBMS which the user equipment receives from the source base station to the user equipment); and
the second operation comprises at least one of the following:
broadcasting the scheduling information through air interface in a case that an interest indication is received (Fig. 5, [0075]: the target base station may find whether the user equipment takes an interest in receiving the MBMS according to the indication of the MBMS interest information. [0079]: The target base station verifies the received MBMS and MBMS interest information and prefers a service in which the MBMS interest information is set to 1 among the MBMSs to set and schedule the MBMS. [0090]: target base station transmits the same MBMS which the user equipment receives from the source base station to the user equipment); or
sending a failure indication to the first network node in a case that no interest indication is received.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhu as outlined above with the teachings of Jung.
Doing so provides a handover method for service continuity in an MBMS (Jung: Fig. 5, [0066]).
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US 2023/0319649 A1) in view of Rönneke et al. (US 2023/0309189 A1), Ianev et al. (US 2022/0264504 A1), Jung et al. (US 2014/0029580 A1), and Hurtta et al. (US 2005/0091315 A1).
Regarding claim(s) 7, Zhu in view of Rönneke, Ianev and Jung discloses all features of claim(s) 6 as outlined above.
Zhu does not disclose, but Hurtta discloses wherein in a case that the broadcast indication comprises the second broadcast indication, the method further comprises:
sending the broadcast indication to a third network node in a case that a failure indication sent by the second network node is received ([0014]: establishing a bearer plane connection between a first network node and a second network node for a broadcast service session, detecting a failure an established bearer plane, reselecting a second network node providing the broadcast service session, and re-establishing the bearer plane connection with a selected second network node for continuing the broadcast service session. [0080]: The radio network controller 200 notices a failure situation e.g. when it receives an MBMS RAB Assignment Request (release RAB) from the default serving GPRS support node 202).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhu as outlined above with the teachings of Hurtta.
Doing so provides an effective solution for establishing and re-establishing user data connections, e.g. radio access bearers because if the radio access bearer fails, it is easy and quick to establish a new radio access bearer based on the stored SGSN address/MBMS service session identifier information (Hurrta: [0046]).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THE HY NGUYEN whose telephone number is (571)270-3813. The examiner can normally be reached on Mo-Fr: 8am-4pm.
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, Joseph Avellino, can be reached on (571) 272-3905. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/THE HY NGUYEN/Primary Examiner, Art Unit 2478
TheHy.Nguyen@USPTO.gov
Prosecution Insights