Prosecution Insights
Last updated: April 19, 2026
Application No. 18/595,457

USER EQUIPMENT, SOURCE BASE STATION, TARGET BASE STATION, AND HANDOVER METHODS FOR UE MBS MOBILITY WITH SERVICE CONTINUITY

Non-Final OA §103
Filed
Mar 05, 2024
Examiner
LITTLE, DALE LI
Art Unit
2419
Tech Center
2400 — Computer Networks
Assignee
Huizhou TCL Cloud Internet Corporation Technology Co., Ltd.
OA Round
3 (Non-Final)
0%
Grant Probability
At Risk
3-4
OA Rounds
3y 1m
To Grant
0%
With Interview

Examiner Intelligence

Grants only 0% of cases
0%
Career Allow Rate
0 granted / 1 resolved
-58.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
42 currently pending
Career history
43
Total Applications
across all art units

Statute-Specific Performance

§101
1.7%
-38.3% vs TC avg
§103
68.3%
+28.3% vs TC avg
§102
22.2%
-17.8% vs TC avg
§112
7.2%
-32.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 1 resolved cases

Office Action

§103
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 . 2. This office action is in response to remarks filed on 12/03/2025. Claims 1-2 and 4-21 are pending and presented for examination. Claims 1-2 and 4-20 are amended. Claim 21 is added. Response to Amendments Claims 1-2 and 4-20 have been considered based on amendments. Claim 21 has been added and considered. Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/03/2025 has been entered. 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 non-obviousness. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claims 1-2, 4-8, 10-16, 18, and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Na et al (EP2200367A1) (hereinafter "Na") in view of Huawei et al (R3-213988) (hereinafter "Huawei") and Jung et al (US20140029580A1) (hereinafter "Jung"). Regarding claim 1, Na discloses a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a source base station, comprising ([0014] method of performing a handover of a mobile terminal which receives multimedia services in a broadcast mode in an E-MBMS mobile communication network.): transmitting, by the source base station, a handover request comprising an MBS information to a target base station, wherein the MBS information comprises at least an MBS bearer identity; and ([0023] Then, the source base station 102-1 transmits a handover request message to a target base station 102-2 (operation 206). The handover request message includes a MBMS service ID, a MBMS1 address and a MBMS2 address.) wherein the switching is completed prior to the UE transmitting a handover complete message to the target base station ([0029] The source base station 102-1 transmits a Handover Command message including PTP RB information corresponding to the MBMS service ID to the mobile terminal 101 (operation 306). The mobile terminal 101 performs synchronization and UL allocation with the target base station 102-2 according to a general handover procedure, and transmits a handover confirmation message to the target base station 102-2, thus informing the target base station 102-2 of the fact that the handover has been completed (operations 307 and 308).). Na fails to disclose a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a source base station, comprising: transmitting, by the source base station, a handover request comprising an MBS information to a target base station, wherein the MBS information comprises at least a quality of service (QoS) flow-to-MBS radio bearer (MRB) mapping; and switching, by the source base station, an MBS data transmission for the UE from MRBs to one or more unicast data radio bearers (DRBs) configured by the source base station. However, Huawei discloses a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a source base station, comprising: transmitting, by the source base station, a handover request comprising an MBS information to a target base station, wherein the MBS information comprises at least a quality of service (QoS) flow-to-MBS radio bearer (MRB) mapping; and (Sect. 2: The source NG-RAN node requests the mapped QoS Flow(s) in the associated unicast PDU session to be handed over to the target NG-RAN node.). switching, by the source base station, an MBS data transmission for the UE from MRBs to one or more unicast data radio bearers (DRBs) configured by the source base station (Fig. 2: MBS flow to unicast flow mapping (change QFI in GTP-U container to unicast QFI)); Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a source base station, comprising: transmitting, by the source base station, a handover request comprising an MBS information to a target base station, wherein the MBS information comprises at least a quality of service (QoS) flow-to-MBS radio bearer (MRB) mapping; and switching, by the source base station, an MBS data transmission for the UE from MRBs to one or more unicast data radio bearers (DRBs) configured by the source base station. The motivation to combine both references would come from the need to minimize data loss during mobility. Na fails to disclose a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a source base station, comprising: receiving, from the target base station, a handover acknowledgement comprising an explicit indication that the MBS information is not supported by the target base station; and wherein the switching is performed in direct response to, and only if, the explicit indication indicates that the MBS information is not supported. However, Jung discloses a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a source base station, comprising: receiving, from the target base station, a handover acknowledgement comprising an explicit indication that the MBS information is not supported by the target base station; and ([0085] For example, the target base station judges whether to support the continuity of the MBMS and when it is judged that the user equipment uses the MBMS, the target base station sets the MBMS service start indication to 1. This indicates that the target base station may continuously support the MBMS for the user equipment. That is, this means that the user equipment may receive the MBMS in the serving cell similarly to the MRB. On the contrary, the target base station judges whether to support the continuity of the MBMS and when it is judged that the user equipment does not use the MBMS, the target base station sets the MBMS service start indication to 0. This means that the target base station may not continuously support the MBMS for the user equipment.) wherein the switching is performed in direct response to, and only if, the explicit indication indicates that the MBS information is not supported ([0081] Alternatively, judging whether to support the continuity of the MBMS includes judging whether providing the MBMS itself is possible or impossible. [0083] Alternatively, judging whether to support the continuity of the MBMS includes judging the type of the MBMS received by the user equipment. The reason is that there may be present an MBMS which the target cell or the target base station is capable of supporting or there may be present an MBMS which the target cell or the target base station is incapable of supporting. [0101] Additionally, judging whether to support the continuity of the MBMS may further include judging whether the MBMS is provided through the dedicated bearer (point-to-point bearer) or the MRB.). Na and Jung are considered to be analogous to the claimed invention because both are in the same endeavor of device mobility during a multimedia broadcast/multicast service. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Jung to create a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a source base station, comprising: receiving, from the target base station, a handover acknowledgement comprising an explicit indication that the MBS information is not supported by the target base station; and wherein the switching is performed in direct response to, and only if, the explicit indication indicates that the MBS information is not supported. The motivation to combine both references would come from the need to provide MBMS service continuity during handover. Regarding claim 2, Na fails to disclose the handover method, wherein the explicit indication comprises a bit field indicating non-support of a temporary mobile group identity (TMGI), a MRB configuration, or the MBS bearer identity. However, Jung discloses the handover method, wherein the explicit indication comprises a bit field indicating non-support of a temporary mobile group identity (TMGI), a MRB configuration, or the MBS bearer identity ([0085] For example, the target base station judges whether to support the continuity of the MBMS and when it is judged that the user equipment uses the MBMS, the target base station sets the MBMS service start indication to 1. This indicates that the target base station may continuously support the MBMS for the user equipment. That is, this means that the user equipment may receive the MBMS in the serving cell similarly to the MRB. On the contrary, the target base station judges whether to support the continuity of the MBMS and when it is judged that the user equipment does not use the MBMS, the target base station sets the MBMS service start indication to 0. This means that the target base station may not continuously support the MBMS for the user equipment.). Na and Jung are considered to be analogous to the claimed invention because both are in the same endeavor of device mobility during a multimedia broadcast/multicast service. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Jung to create the handover method, wherein the explicit indication comprises a bit field indicating non-support of a temporary mobile group identity (TMGI), a MRB configuration, or the MBS bearer identity. The motivation to combine both references would come from the need to provide MBMS service continuity during handover. Regarding claim 4, Na fails to disclose the handover method, further comprising releasing, by the source base station, the MRBs for the UE in response to the switching. However, Huawei discloses the handover method, further comprising releasing, by the source base station, the MRBs for the UE in response to the switching (Fig. 2: if multicast distribution from CN to source gNB needs to be released; MULTICAST DISTRIBUTION RELEASE). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create the handover method, further comprising releasing, by the source base station, the MRBs for the UE in response to the switching. The motivation to combine both references would come from the need to minimize data loss during mobility. Regarding claim 5, Na fails to disclose the handover method, further comprising instructing a core network entity to cease multicast delivery for the MBS session following the switching. However, Huawei discloses the handover method, further comprising instructing a core network entity to cease multicast delivery for the MBS session following the switching (Fig. 2: PATH SWITCH REQUEST without MBS information Sect. 2: Standards shall provide means whereby the SMF knows when receiving a Path Switch Request when a target NG-RAN node does not support MBS and means for SMF to then switch from shared delivery to individual delivery.). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create the handover method, further comprising instructing a core network entity to cease multicast delivery for the MBS session following the switching. The motivation to combine both references would come from the need to minimize data loss during mobility. Regarding claim 6, Na discloses the handover method, wherein switching comprises providing, by the source base station, the MBS data to the UE via the one or more DRBs during the UE's access to the source cell ([0029] The source base station 102-1 transmits a Handover Command message including PTP RB information corresponding to the MBMS service ID to the mobile terminal 101 (operation 306).). Regarding claim 7, Na fails to disclose the handover method, wherein switching comprises mapping an MBS packet data unit (PDU) session identifier to a DRB tunnel identifier. However, Huawei discloses the handover method, wherein switching comprises mapping an MBS packet data unit (PDU) session identifier to a DRB tunnel identifier (Fig. 2: MBS flow to unicast flow mapping (change QFI in GTP-U container to unicast QFI)) Sect. 3: In the handover between MBS supporting nodes, the Source gNB will send MBS related information to the Target gNB, e.g. by include MBS QoS Flow id and Session ID in the PDU Session Resource To be Setup Item, and these information could be included regardless of whether the target gNB supports MBS or not.). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create the handover method, wherein switching comprises mapping an MBS packet data unit (PDU) session identifier to a DRB tunnel identifier. The motivation to combine both references would come from the need to minimize data loss during mobility. Regarding claim 8, Na fails to disclose the handover method, wherein the explicit indication is included in an XnAP handover request acknowledgment message. However, Huawei discloses the handover method, wherein the explicit indication is included in an XnAP handover request acknowledgment message (Sect. 6: During an active multicast MBS session, at mobility from an MBS-supporting NG-RAN node to a non-MBS supporting NG-RAN node, the target NG-RAN node sets up PDU Session resources associated to the multicast MBS Session. The SMF infers from the absence of an ‘MBS-support“ indication in the Path Switch Request message (Xn handover) or Handover Request Acknowledge message (NG handover) that the 5GC has to switch to 5GC individual MBS traffic delivery for that UE as specified in TS 23.247 [x].). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create the handover method, wherein the explicit indication is included in an XnAP handover request acknowledgment message. The motivation to combine both references would come from the need to minimize data loss during mobility. Regarding claim 10, Na discloses the handover method, wherein the switching enables uninterrupted MBS data reception by the UE until transmission of the handover complete message ([0029] The source base station 102-1 transmits a Handover Command message including PTP RB information corresponding to the MBMS service ID to the mobile terminal 101 (operation 306). The mobile terminal 101 performs synchronization and UL allocation with the target base station 102-2 according to a general handover procedure, and transmits a handover confirmation message to the target base station 102-2, thus informing the target base station 102-2 of the fact that the handover has been completed (operations 307 and 308).). Regarding claim 11, Na discloses a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a target base station, comprising ([0014] method of performing a handover of a mobile terminal which receives multimedia services in a broadcast mode in an E-MBMS mobile communication network.): receiving, form a source base station, a handover request comprising an MBS information, wherein the MBS information comprises an MBS bearer identity ([0023] Then, the source base station 102-1 transmits a handover request message to a target base station 102-2 (operation 206). The handover request message includes a MBMS service ID, a MBMS1 address and a MBMS2 address.); to complete said switching prior to the UE transmitting a handover complete message to the target base station ([0029] The source base station 102-1 transmits a Handover Command message including PTP RB information corresponding to the MBMS service ID to the mobile terminal 101 (operation 306). The mobile terminal 101 performs synchronization and UL allocation with the target base station 102-2 according to a general handover procedure, and transmits a handover confirmation message to the target base station 102-2, thus informing the target base station 102-2 of the fact that the handover has been completed (operations 307 and 308).). Na fails to discloses a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a target base station, comprising: receiving, form a source base station, a handover request comprising an MBS information, wherein the MBS information comprises a quality-of-service (QoS) flow-to-MBS radio bearer (MRB) mapping; thereby causing the source base station to switch an MBS data transmission for the UE from the MRBs to one or more DRBs in response to the explicit indication. However, Huawei discloses a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a target base station, comprising: receiving, form a source base station, a handover request comprising an MBS information, wherein the MBS information comprises a quality-of-service (QoS) flow-to-MBS radio bearer (MRB) mapping (Sect. 2: The source NG-RAN node requests the mapped QoS Flow(s) in the associated unicast PDU session to be handed over to the target NG-RAN node.); thereby causing the source base station to switch an MBS data transmission for the UE from the MRBs to one or more DRBs in response to the explicit indication (Fig. 2: MBS flow to unicast flow mapping (change QFI in GTP-U container to unicast QFI)). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a target base station, comprising: receiving, form a source base station, a handover request comprising an MBS information, wherein the MBS information comprises a quality-of-service (QoS) flow-to-MBS radio bearer (MRB) mapping; thereby causing the source base station to switch an MBS data transmission for the UE from the MRBs to one or more DRBs in response to the explicit indication. The motivation to combine both references would come from the need to minimize data loss during mobility. Na fails to discloses a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a target base station, comprising: determining, by the target base station, that the MBS information is not supported; and transmitting, to the source base station, a handover acknowledgement comprising an explicit indication that the MBS information is not supported. However, Jung discloses a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a target base station, comprising: determining, by the target base station, that the MBS information is not supported; and ([0085] For example, the target base station judges whether to support the continuity of the MBMS and when it is judged that the user equipment uses the MBMS, the target base station sets the MBMS service start indication to 1. This indicates that the target base station may continuously support the MBMS for the user equipment. That is, this means that the user equipment may receive the MBMS in the serving cell similarly to the MRB. On the contrary, the target base station judges whether to support the continuity of the MBMS and when it is judged that the user equipment does not use the MBMS, the target base station sets the MBMS service start indication to 0. This means that the target base station may not continuously support the MBMS for the user equipment.) transmitting, to the source base station, a handover acknowledgement comprising an explicit indication that the MBS information is not supported ([0085] For example, the target base station judges whether to support the continuity of the MBMS and when it is judged that the user equipment uses the MBMS, the target base station sets the MBMS service start indication to 1. This indicates that the target base station may continuously support the MBMS for the user equipment. That is, this means that the user equipment may receive the MBMS in the serving cell similarly to the MRB. On the contrary, the target base station judges whether to support the continuity of the MBMS and when it is judged that the user equipment does not use the MBMS, the target base station sets the MBMS service start indication to 0. This means that the target base station may not continuously support the MBMS for the user equipment.). Na and Jung are considered to be analogous to the claimed invention because both are in the same endeavor of device mobility during a multimedia broadcast/multicast service. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Jung to create a handover method for user equipment (UE) multicast-broadcast service (MBS) mobility with service continuity performed by a target base station, comprising: determining, by the target base station, that the MBS information is not supported; and transmitting, to the source base station, a handover acknowledgement comprising an explicit indication that the MBS information is not supported. The motivation to combine both references would come from the need to provide MBMS service continuity during handover. Regarding claim 12, Na fails to disclose the handover method, wherein the determining comprises comparing the MBS information to an MBS capability list of the target base station. However, Jung discloses the handover method, wherein the determining comprises comparing the MBS information to an MBS capability list of the target base station ([0133] For example, the MBMS service indication may be configured in a list form like TMGI A, B, and C when the plurality of MBMS user equipments receives MBMSs A, B, and C. [0135] As another example, the MBMS indicator may include MBMS interest information indicating whether the user equipment prefers receiving the MBMS. If the MBMS interest information indicates the interest in receiving the MBMS, the target base station may find that the user equipment takes an interest in receiving the MBMS.). Na and Jung are considered to be analogous to the claimed invention because both are in the same endeavor of device mobility during a multimedia broadcast/multicast service. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Jung to create the handover method, wherein the determining comprises comparing the MBS information to an MBS capability list of the target base station. The motivation to combine both references would come from the need to provide MBMS service continuity during handover. Regarding claim 13, Na fails to disclose the handover method, wherein the explicit indication identifies a non-supported MRB or temporary mobile group identity (TMGI). However, Jung discloses the handover method, wherein the explicit indication identifies a non-supported MRB or temporary mobile group identity (TMGI) ([0075] The source base station transmits an MBMS control request indication to the target base station (S505). 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. [0078] Alternatively, the MBMS control request indication may be configured as below. { MBMS TMGI= A, MBMS interest information: 1 or 0 MBMS TMGI= B, MBMS interest information: 1 or 0 MBMS TMGI= C, MBMS interest information: 1 or 0 }). Na and Jung are considered to be analogous to the claimed invention because both are in the same endeavor of device mobility during a multimedia broadcast/multicast service. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Jung to create the handover method, wherein the explicit indication identifies a non-supported MRB or temporary mobile group identity (TMGI). The motivation to combine both references would come from the need to provide MBMS service continuity during handover. Regarding claim 14, Na fails to disclose the handover method, wherein the explicit indication is included in an XnAP or NGAP handover acknowledgement information element. However, Huawei discloses the handover method, wherein the explicit indication is included in an XnAP or NGAP handover acknowledgement information element (Sect. 6: During an active multicast MBS session, at mobility from an MBS-supporting NG-RAN node to a non-MBS supporting NG-RAN node, the target NG-RAN node sets up PDU Session resources associated to the multicast MBS Session. The SMF infers from the absence of an ‘MBS-support“ indication in the Path Switch Request message (Xn handover) or Handover Request Acknowledge message (NG handover) that the 5GC has to switch to 5GC individual MBS traffic delivery for that UE as specified in TS 23.247 [x].). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create the handover method, wherein the explicit indication is included in an XnAP or NGAP handover acknowledgement information element. The motivation to combine both references would come from the need to minimize data loss during mobility. Regarding claim 15, Na fails to disclose the handover method, further comprising transmitting, by the target base station, a message indicating the MBS non-support to a core network entity. However, Huawei discloses the handover method, further comprising transmitting, by the target base station, a message indicating the MBS non-support to a core network entity (Fig. 2: PATH SWITCH REQUEST without MBS information Sect. 2: Standards shall provide means whereby the SMF knows when receiving a Path Switch Request when a target NG-RAN node does not support MBS and means for SMF to then switch from shared delivery to individual delivery.). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create the handover method, further comprising transmitting, by the target base station, a message indicating the MBS non-support to a core network entity. The motivation to combine both references would come from the need to minimize data loss during mobility. Regarding claim 16, Na fails to disclose the handover method, wherein the target base station omits MBS session configuration information from the handover acknowledgement in response to determining non-support. However, Huawei discloses the handover method, wherein the target base station omits MBS session configuration information from the handover acknowledgement in response to determining non-support (Sect. 3: In the handover between MBS supporting nodes, the Source gNB will send MBS related information to the Target gNB, e.g. by include MBS QoS Flow id and Session ID in the PDU Session Resource To be Setup Item, and these information could be included regardless of whether the target gNB supports MBS or not. And if the Target gNB does not support MBS, the Handover Request ACK will not include MBS related information.). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create the handover method, wherein the target base station omits MBS session configuration information from the handover acknowledgement in response to determining non-support. The motivation to combine both references would come from the need to minimize data loss during mobility. Regarding claim 18, Na fails to disclose the handover method, wherein the handover acknowledgement further comprises UE context information excluding MRB-related parameters. However, Huawei discloses the handover method, wherein the handover acknowledgement further comprises UE context information excluding MRB-related parameters (Sect. 3: In the handover between MBS supporting nodes, the Source gNB will send MBS related information to the Target gNB, e.g. by include MBS QoS Flow id and Session ID in the PDU Session Resource To be Setup Item, and these information could be included regardless of whether the target gNB supports MBS or not. And if the Target gNB does not support MBS, the Handover Request ACK will not include MBS related information.). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create the handover method, wherein the handover acknowledgement further comprises UE context information excluding MRB-related parameters. The motivation to combine both references would come from the need to minimize data loss during mobility. Regarding claim 20, Na fails to disclose the handover method, wherein the explicit indication triggers the source base station to release UE-specific MRBs prior to UE transmission of the handover complete message. However, Huawei discloses the handover method, wherein the explicit indication triggers the source base station to release UE-specific MRBs prior to UE transmission of the handover complete message (Fig. 2: if multicast distribution from CN to source gNB needs to be released; MULTICAST DISTRIBUTION RELEASE). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create the handover method, wherein the explicit indication triggers the source base station to release UE-specific MRBs prior to UE transmission of the handover complete message. The motivation to combine both references would come from the need to minimize data loss during mobility. Regarding claim 21, Na fails to disclose the handover method, wherein the one or more DRBs are configured with QoS parameters corresponding to the QoS flow-to-MRB mapping contained in the MBS information. However, Huawei discloses the handover method, wherein the one or more DRBs are configured with QoS parameters corresponding to the QoS flow-to-MRB mapping contained in the MBS information (Sect. 2: The source NG-RAN node requests the mapped QoS Flow(s) in the associated unicast PDU session to be handed over to the target NG-RAN node.). Na and Huawei are considered to be analogous to the claimed invention because both are in the same endeavor of mobility between MBS supporting and non-supporting nodes. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Huawei to create the handover method, wherein the one or more DRBs are configured with QoS parameters corresponding to the QoS flow-to-MRB mapping contained in the MBS information. The motivation to combine both references would come from the need to minimize data loss during mobility. Claims 9 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Na in view of Huawei and Jung as applied to claims 1 or 11 above, and further in view of Cao et al (WO2021233279A1) (hereinafter "Cao"). Regarding claim 9, Na fails to disclose the handover method, wherein the explicit indication indicates non-support of a QoS flow included within the MBS information. However, Cao discloses the handover method, wherein the explicit indication indicates non-support of a QoS flow included within the MBS information (S4: The source base station sends a handover request message to the target base station through the Xn interface, the purpose of which is to request resources for handover (Handover) and inform the target base station of the UE context on the source base station side; the handover request message may specifically include at least one of the following information One: Interest indication information reported by the UE, the current MBS service information received by the UE (for example, the MBS session identification information corresponding to the received MBS service), and the MBS session bearer configuration information (for example, PTM bearer configuration information and/or PTP bearer configuration information), the QoS configuration information of the QoS flow in the MBS session (for example, the QoS flow identification list in the session, corresponding to the QoS parameters of the QoS flow class of each QoS flow identification), the UE receives the current MBS service The indication information that identifies whether the corresponding MBS data uses the PTP radio bearer or the PTM radio bearer, and the MBS receiving capability information of the UE.). Na and Cao are considered to be analogous to the claimed invention because both are in the same endeavor of implementing broadcast/multicast services during the handover process. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Cao to create the handover method, wherein the explicit indication indicates non-support of a QoS flow included within the MBS information. The motivation to combine both references would come from the need to guarantee broadcast/multicast transmission during the handover process between base stations. Regarding claim 17, Na fails to disclose the handover method, wherein the explicit indication comprises a binary field indicating non-support of the QoS flow-to-MRB mapping. However, Cao discloses the handover method, wherein the explicit indication comprises a binary field indicating non-support of the QoS flow-to-MRB mapping (S4: The source base station sends a handover request message to the target base station through the Xn interface, the purpose of which is to request resources for handover (Handover) and inform the target base station of the UE context on the source base station side; the handover request message may specifically include at least one of the following information One: Interest indication information reported by the UE, the current MBS service information received by the UE (for example, the MBS session identification information corresponding to the received MBS service), and the MBS session bearer configuration information (for example, PTM bearer configuration information and/or PTP bearer configuration information), the QoS configuration information of the QoS flow in the MBS session (for example, the QoS flow identification list in the session, corresponding to the QoS parameters of the QoS flow class of each QoS flow identification), the UE receives the current MBS service The indication information that identifies whether the corresponding MBS data uses the PTP radio bearer or the PTM radio bearer, and the MBS receiving capability information of the UE.). Na and Cao are considered to be analogous to the claimed invention because both are in the same endeavor of implementing broadcast/multicast services during the handover process. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Cao to create the handover method, wherein the explicit indication comprises a binary field indicating non-support of the QoS flow-to-MRB mapping. The motivation to combine both references would come from the need to guarantee broadcast/multicast transmission during the handover process between base stations. Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Na in view of Huawei and Jung as applied to claims 1 or 11 above, and further in view of Baek et al (US20080132240A1) (hereinafter "Baek"). Regarding claim 19, Na fails to disclose the handover method, further comprising updating, by the target base station, a record of MBS service group membership for the UE based on the non-support determination. However, Baek discloses the handover method, further comprising updating, by the target base station, a record of MBS service group membership for the UE based on the non-support determination ([0064] The target base station 220 that has received the handover request message transmits IGMP membership report information to the gateway 300 in the case of the IPv4, and transmits the IGMP report message to the gateway 300 in the case of the IPv6 (Step S140). At this time, the message transmission process is performed in order for the gateway 300 to join the target base station 220, to which a handover of the mobile terminal is performed, to the existing multicast group. In this case, the IGMP report message includes multicast group information that is created by updating corresponding information with information on the mobile terminal 100, information on the serving base station 210, and information on the target base station 220 in the target base station 220.). Na and Baek are considered to be analogous to the claimed invention because both are in the same endeavor transmitting data in a handover between base stations. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Na with Baek to create the handover method, further comprising updating, by the target base station, a record of MBS service group membership for the UE based on the non-support determination. The motivation to combine both references would come from the need to minimize the loss of data traffic transmitted in a downlink. Response to Arguments Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to D. Little whose telephone number is (571)272-5748. The examiner can normally be reached M-Th 8-6 ET. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nishant Divecha can be reached at 571-270-3125. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /D LITTLE/ Examiner, Art Unit 2419 /Nishant Divecha/ Supervisory Patent Examiner, Art Unit 2419
Read full office action

Prosecution Timeline

Mar 05, 2024
Application Filed
Apr 07, 2025
Non-Final Rejection — §103
Jul 06, 2025
Response Filed
Sep 15, 2025
Final Rejection — §103
Dec 03, 2025
Request for Continued Examination
Dec 15, 2025
Response after Non-Final Action
Dec 30, 2025
Non-Final Rejection — §103 (current)

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
0%
Grant Probability
0%
With Interview (+0.0%)
3y 1m
Median Time to Grant
High
PTA Risk
Based on 1 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month