DETAILED ACTION
Claim Objections
Claim 12 is objected to because of the following informalities: “…a request message to from a first….” ; typo mistake. Appropriate correction is required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1- 3, 5- 6, 8, 10- 11 and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Mohammed Mikaeil et al. (US Pub. No. 2024/0214875 A1), hereafter Ahmed.
Regarding claim 1, Ahmed teaches a method of wireless communications (see [0001]..wireless communication system…), comprising:
determining, by a first access node that supports multicast and broadcast service (MBS), to initiate a handover procedure for a handover of a user device to a second access node (see [0045] …. an example of MBS handover procedure to a target gNB (i.e. second access node) not supporting MBS target according to an embodiment of the present disclosure. FIG. 7 illustrates that, in some embodiments, a UE Reports a handover control information and/or measurement to a source gNB (i.e. first access node) while receiving an MBS data via MRBs during mobility to a target gNB. The source gNB sends a handover request containing an MBS service information at the source gNB such as TMGI, service ID, MBS bearer IDs, and/or QoS flow to MRB mapping to the target gNB….);
buffering, at the first access node, for the handover procedure, a first set of data packets of an MBS session of the user device received over a shared tunnel from a core network (see [0046].. MRB is not supported by target gNB, the target gNB will indicate a bit value e.g., 1″ to the source gNB at the same time, it will send an MBS switch delivery request to a CN (i.e. core network). Upon the reception of the switch delivery request, the CN generates an individual delivery tunnel for the MBS associated PDU session on the top of the existing shared delivery tunnel used for MBS session. The CN sends a copy of the MBS data to the source gNB over both the individual delivery tunnel as well as the existing shared delivery tunnel MBS data (i.e. existing data as a first set of data packets and data associated with individual delivery tunnel as a second set of data packets) to the source gNB (i.e. existing data (i.e. from shared tunnel) is being stored/buffered at source node; see Fig. 2 regarding #22 of #20);….; further see [0052]… Moreover, in order to guarantee UE service continuity when moving to a target RAN node not supporting MBS, it is proposed to provide a copy of MBS data from CN to both source and the target RAN nodes, to allow UE to continue receiving from the MBS data from both the source RAN node over both MBS radio bearers (MRBs) and unicast data radio bearer (DRB) until the handover process to the target node complete. In this way the service continuity can be guaranteed for the UE since the UE will be able to continue to receive MBS data before, during and after the handover process, this can also help reducing UE service interruption while moving because all configuration and a copy of MBS data is available at the target cell before moving.);
requesting, to the core network, to change the shared tunnel for receiving the MBS session to a unicast tunnel (see [0045] and Fig. 7 (HO request, switch delivery request)) regarding HO request from source gnB …now see [0046].. MRB is not supported by target gNB, the target gNB will indicate a bit value e.g., 1″ to the source gNB at the same time, it will send an MBS switch delivery request to a CN. Upon the reception of the switch delivery request, the CN generates an individual delivery tunnel for the MBS associated PDU session on the top of the existing shared delivery tunnel used for MBS session. The CN sends a copy of the MBS data to the source gNB over both the individual delivery tunnel as well as the existing shared delivery tunnel MBS data to the source gNB; at the same time, the CN may also provide a copy of MBS data to via individual delivery tunnel to the target gNB. The target gNB keeps receiving the copy of MBS data received over the individual delivery tunnel and buffering the data until it receives a switch delivery acknowledgment from the CN…);
buffering, by the first access node a second set of data packets of the MBS session received over the unicast tunnel (already discussed above see [0046].. MRB is not supported by target gNB, the target gNB will indicate a bit value e.g., 1″ to the source gNB at the same time, it will send an MBS switch delivery request to a CN (i.e. core network). Upon the reception of the switch delivery request, the CN generates an individual delivery tunnel for the MBS associated PDU session on the top of the existing shared delivery tunnel used for MBS session. The CN sends a copy of the MBS data to the source gNB over both the individual delivery tunnel as well as the existing shared delivery tunnel MBS data (i.e. existing data as a first set of data packets and data associated with individual delivery tunnel as a second set of data packets) to the source gNB (i.e. data (i.e. from individual delivery tunnel (unicast DRB)) is being stored/buffered at source node; see Fig. 2 regarding #22 of #20);….; further see [0052]… Moreover, in order to guarantee UE service continuity when moving to a target RAN node not supporting MBS, it is proposed to provide a copy of MBS data from CN to both source and the target RAN nodes, to allow UE to continue receiving from the MBS data from both the source RAN node over both MBS radio bearers (MRBs) and unicast data radio bearer (DRB) until the handover process to the target node complete. In this way the service continuity can be guaranteed for the UE since the UE will be able to continue to receive MBS data before, during and after the handover process, this can also help reducing UE service interruption while moving because all configuration and a copy of MBS data is available at the target cell before moving.); and
providing, upon initiating the handover, at least part of the first set of data packets or the second set of data packets to the second access node (see [0046] first six lines in a case wherein target gnb supports TMGI or service or MRB (MBS radio bearer)… the source will apply a handover similar to legacy unicast NR for the respective MRB to the MRB of the target (i.e. first set of data packets).).
Regarding claim 2, Ahmed teaches as per claim 1, wherein the requesting comprises:
initiating, by the first access node, the handover procedure by transmitting a handover request that includes information about the MBS session (see [0045].. The source gNB sends a handover request containing an MBS service information at the source gNB such as TMGI, service ID, MBS bearer IDs, and/or QoS flow to MRB mapping….),
transmitting, by the first access node, a request message to the core network indicating a switch to a unicast tunnel for receiving MBS data (already discussed above see [0045] and Fig. 7 (HO request, switch delivery request)) regarding HO request from source gnB …now see [0046].. MRB is not supported by target gNB, the target gNB will indicate a bit value e.g., 1″ to the source gNB at the same time, it will send an MBS switch delivery request to a CN. Upon the reception of the switch delivery request, the CN generates an individual delivery tunnel for the MBS associated PDU session (i.e. see [0052] unicast DRB) on the top of the existing shared delivery tunnel used for MBS session. The CN sends a copy of the MBS data to the source gNB over both the individual delivery tunnel as well as the existing shared delivery tunnel MBS data to the source gNB; at the same time, the CN may also provide a copy of MBS data to via individual delivery tunnel to the target gNB. The target gNB keeps receiving the copy of MBS data received over the individual delivery tunnel and buffering the data until it receives a switch delivery acknowledgment from the CN…),
receiving, by the first access node, a confirmation message from the core network acknowledging the switch to the unicast tunnel (see Fig. 7 and [0045] regarding source gNB sends HO request and as per target base station not supporting existing service, it requests to core network and core network configures DRB and finally source gNB receives Ho ACK.).
Regarding claim 3, Ahmed teaches as per claim 2, wherein the request message comprises information associated with the MBS session, wherein the information includes at least an identifier of the MBS session or information about the shared tunnel (already discussed refer to [0045]….source gNB sends a handover request containing an MBS service information at the source gNB such as TMGI, service ID, MBS bearer IDs, and/or QoS flow to MRB mapping to the target gNB..).
Regarding claim 5, Ahmed teaches as per claim 2, wherein the confirmation message comprises at least information of the MBS session, information of the unicast tunnel, or Quality of Service (QoS) information associated with the unicast tunnel; already discussed above in [0045- 0046] indication “0” or “1” regarding ….indication meaning at the target gNB 1 The respective [TMGI and Service id, MBS MRB] is supported by the target gNB 0 The respective [TMGI and Service id, MBS MRB] is not supported by the target gNB.
Regarding claim 6, Ahmed teaches as per claim 2, wherein the transmitting of the handover request comprises; transmitting, by the first access node, the handover request to the second access node; see Fig. 7 HO request [TMGI, MRB].
Regarding claim 8, Ahmed teaches as per claim 2, further comprising: receiving, by the first access node, information indicating that the second access node does not support the MBS; already described above see [0045- 0046].. . indication “0” or “1” regarding ….indication meaning at the target gNB 1 The respective [TMGI and Service id, MBS MRB] is supported by the target gNB 0 The respective [TMGI and Service id, MBS MRB] is not supported by the target gNB.
Regarding claim 10, Ahmed teaches as per claim 1, wherein a buffer is associated with the MBS session, the buffer being a user equipment specific buffer or a common buffer; already discussed above see [0046].. MRB is not supported by target gNB, the target gNB will indicate a bit value e.g., 1″ to the source gNB at the same time, it will send an MBS switch delivery request to a CN (i.e. core network). Upon the reception of the switch delivery request, the CN generates an individual delivery tunnel for the MBS associated PDU session on the top of the existing shared delivery tunnel used for MBS session. The CN sends a copy of the MBS data to the source gNB over both the individual delivery tunnel as well as the existing shared delivery tunnel MBS data (i.e. existing data as a first set of data packets and data associated with individual delivery tunnel as a second set of data packets) to the source gNB (i.e. data (i.e. from individual delivery tunnel (unicast DRB)) is being stored/buffered (i.e. shared channel data is stored in common buffer) at source node; see Fig. 2 regarding #22 of #20).
Regarding claim 11, Ahmed teaches as per claim 1, wherein the core network includes a user plane function or an access and mobility management function; see Fig. 6, UPF under CN.
Regarding claim 20, Ahmed teaches an apparatus for wireless communication comprising: one or more processor configured to (see [0001]..wireless communication system…; apparatus can be first access node here), comprising:
determine, by a first access node that supports multicast and broadcast service (MBS), to initiate a handover procedure for a handover of a user device to a second access node (see [0045] …. an example of MBS handover procedure to a target gNB (i.e. second access node) not supporting MBS target according to an embodiment of the present disclosure. FIG. 7 illustrates that, in some embodiments, a UE Reports a handover control information and/or measurement to a source gNB (i.e. first access node) while receiving an MBS data via MRBs during mobility to a target gNB. The source gNB sends a handover request containing an MBS service information at the source gNB such as TMGI, service ID, MBS bearer IDs, and/or QoS flow to MRB mapping to the target gNB….);
buffer, at the first access node, for the handover procedure, a first set of data packets of an MBS session of the user device received over a shared tunnel from a core network (see [0046].. MRB is not supported by target gNB, the target gNB will indicate a bit value e.g., 1″ to the source gNB at the same time, it will send an MBS switch delivery request to a CN (i.e. core network). Upon the reception of the switch delivery request, the CN generates an individual delivery tunnel for the MBS associated PDU session on the top of the existing shared delivery tunnel used for MBS session. The CN sends a copy of the MBS data to the source gNB over both the individual delivery tunnel as well as the existing shared delivery tunnel MBS data (i.e. existing data as a first set of data packets and data associated with individual delivery tunnel as a second set of data packets) to the source gNB (i.e. existing data (i.e. from shared tunnel) is being stored/buffered at source node; see Fig. 2 regarding #22 of #20);….; further see [0052]… Moreover, in order to guarantee UE service continuity when moving to a target RAN node not supporting MBS, it is proposed to provide a copy of MBS data from CN to both source and the target RAN nodes, to allow UE to continue receiving from the MBS data from both the source RAN node over both MBS radio bearers (MRBs) and unicast data radio bearer (DRB) until the handover process to the target node complete. In this way the service continuity can be guaranteed for the UE since the UE will be able to continue to receive MBS data before, during and after the handover process, this can also help reducing UE service interruption while moving because all configuration and a copy of MBS data is available at the target cell before moving.);
request, to the core network, to change the shared tunnel for receiving the MBS session to a unicast tunnel (see [0045] and Fig. 7 (HO request, switch delivery request)) regarding HO request from source gnB …now see [0046].. MRB is not supported by target gNB, the target gNB will indicate a bit value e.g., 1″ to the source gNB at the same time, it will send an MBS switch delivery request to a CN. Upon the reception of the switch delivery request, the CN generates an individual delivery tunnel for the MBS associated PDU session on the top of the existing shared delivery tunnel used for MBS session. The CN sends a copy of the MBS data to the source gNB over both the individual delivery tunnel as well as the existing shared delivery tunnel MBS data to the source gNB; at the same time, the CN may also provide a copy of MBS data to via individual delivery tunnel to the target gNB. The target gNB keeps receiving the copy of MBS data received over the individual delivery tunnel and buffering the data until it receives a switch delivery acknowledgment from the CN…);
buffer, by the first access node a second set of data packets of the MBS session received over the unicast tunnel (already discussed above see [0046].. MRB is not supported by target gNB, the target gNB will indicate a bit value e.g., 1″ to the source gNB at the same time, it will send an MBS switch delivery request to a CN (i.e. core network). Upon the reception of the switch delivery request, the CN generates an individual delivery tunnel for the MBS associated PDU session on the top of the existing shared delivery tunnel used for MBS session. The CN sends a copy of the MBS data to the source gNB over both the individual delivery tunnel as well as the existing shared delivery tunnel MBS data (i.e. existing data as a first set of data packets and data associated with individual delivery tunnel as a second set of data packets) to the source gNB (i.e. data (i.e. from individual delivery tunnel (unicast DRB)) is being stored/buffered at source node; see Fig. 2 regarding #22 of #20);….; further see [0052]… Moreover, in order to guarantee UE service continuity when moving to a target RAN node not supporting MBS, it is proposed to provide a copy of MBS data from CN to both source and the target RAN nodes, to allow UE to continue receiving from the MBS data from both the source RAN node over both MBS radio bearers (MRBs) and unicast data radio bearer (DRB) until the handover process to the target node complete. In this way the service continuity can be guaranteed for the UE since the UE will be able to continue to receive MBS data before, during and after the handover process, this can also help reducing UE service interruption while moving because all configuration and a copy of MBS data is available at the target cell before moving.); and
providing, upon initiating the handover, at least part of the first set of data packets or the second set of data packets to the second access node (see [0046] first six lines in a case wherein target gnb supports TMGI or service or MRB (MBS radio bearer)… the source will apply a handover similar to legacy unicast NR for the respective MRB to the MRB of the target (i.e. first set of data packets).).
Claim(s) 12, 14- 16, 21 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Source: Nokia, Nokia Shanghai Bell Title: Mobility from MBS Supporting to Non-Supporting MBS nodes, R3-210173; see IDS filed on 4/4/2025, page 1 cite #1; hereafter Nokia.
Regarding claim 12,Nokia teaches a method for wireless communications (see introduction), comprising:
receiving, by a core network, a request message to from a first access node indicating a switch from a shared tunnel to a unicast tunnel for multicast and broadcast service (MBS) data (see page 2 (i.e. context with page 1 wherein option 2 is selected… that the SMF indicates to the NG-RAN node that the unicast QoS flow which is being setup is associated to an MBS QoS flow, … )… the source NGRAN (i.e. first access node) node knows in advance whether the target NG-RAN node supports MBS or not. In this case, the source NG-RAN node can send a trigger to SMF to switch from shared delivery to individual delivery just before the handover takes place. This, in turn, triggers SMF to request the setup of an N9 interface between MB-UPF and UPF; option 2.1; further see option 2.2 … Alternatively, the source NG-RAN can trigger the handover directly from shared delivery. During the handover the Path Switch Request message serves as trigger for the SMF to trigger the switch from shared delivery into individual delivery: SMF can contact the UPF to get a DL GTP TEID, then send this DL GTP TEID to the MB-UPF via the MB-SMF. The MB-UPF is ready to deliver multicast data to UPF in individual delivery mode. The complete procedure can take place during the path switch procedure and can end with SMF sending the Path Switch Request Acknowledge message to target NG-RAN node ); and
transmitting, from the core network in response to the switch to the unicast tunnel, the MBS data for an MBS session via the unicast tunnel (see page 1….. provided that the SMF indicates to the NG-RAN node that the unicast QoS flow which is being setup is associated to an MBS QoS flow, the NG-RAN node can setup the unicast QoS flow while refraining from assigning radio resources to it, even though the unicast N3 tunnel could be setup…; further see page 2 option 2.2… Alternatively, the source NG-RAN can trigger the handover directly from shared delivery. During the handover the Path Switch Request message serves as trigger for the SMF to trigger the switch from shared delivery into individual delivery: SMF can contact the UPF to get a DL GTP TEID, then send this DL GTP TEID to the MB-UPF via the MB-SMF. The MB-UPF is ready to deliver multicast data to UPF in individual delivery mode. The complete procedure can take place during the path switch procedure and can end with SMF sending the Path Switch Request Acknowledge message to target NG-RAN node; further see page 2 proposal 3 regarding agree to standardize only option 2.2; also refer to page 3 first ten lines… select option 2 and agree that the unicast QoS flow associated to an MBS QoS flow can be setup at PDU session resource setup/modify, with a mapping between the MBS flow and the associated unicast QoS flow … agree to standardize only option 2.2 for Xn mobility from MBS-supporting to non-MBS-supporting NG-RAN nodes where the switch from shared delivery to individual delivery takes place during the path switch procedure by the SMF…..).
Regarding claim 14, Nokia teaches as per claim 12, further comprising: performing, by the core network, a handover procedure from the first access node to a second access node prior to transmitting the MBS data via the unicast tunnel to the second access node; see page 2 option 2.2... Alternatively, the source NG-RAN can trigger the handover directly from shared delivery. During the handover the Path Switch Request message serves as trigger for the SMF to trigger the switch from shared delivery into individual delivery: SMF can contact the UPF to get a DL GTP TEID, then send this DL GTP TEID to the MB-UPF via the MB-SMF. The MB-UPF is ready to deliver multicast data to UPF in individual delivery mode. The complete procedure can take place during the path switch procedure and can end with SMF sending the Path Switch Request Acknowledge message to target NG-RAN node.
Regarding claim 15, Nokia teaches as per claim 12, wherein the transmitting of the MBS data for the MBS session via the unicast tunnel comprises: transmitting, by the core network, the MBS data via the unicast tunnel to the first access node as part of a handover procedure from the first access node to a second access node; see page 1….. provided that the SMF indicates to the NG-RAN node that the unicast QoS flow which is being setup is associated to an MBS QoS flow, the NG-RAN node can setup the unicast QoS flow while refraining from assigning radio resources to it, even though the unicast N3 tunnel could be setup…; further see page 2 option 2.2… Alternatively, the source NG-RAN can trigger the handover directly from shared delivery. During the handover the Path Switch Request message serves as trigger for the SMF to trigger the switch from shared delivery into individual delivery: SMF can contact the UPF to get a DL GTP TEID, then send this DL GTP TEID to the MB-UPF via the MB-SMF. The MB-UPF is ready to deliver multicast data to UPF in individual delivery mode. The complete procedure can take place during the path switch procedure and can end with SMF sending the Path Switch Request Acknowledge message to target NG-RAN node; further see page 2 proposal 3 regarding agree to standardize only option 2.2; also refer to page 3 first ten lines… select option 2 and agree that the unicast QoS flow associated to an MBS QoS flow can be setup at PDU session resource setup/modify, with a mapping between the MBS flow and the associated unicast QoS flow … agree to standardize only option 2.2 for Xn mobility from MBS-supporting to non-MBS-supporting NG-RAN nodes where the switch from shared delivery to individual delivery takes place during the path switch procedure by the SMF…..
Regarding claim 16, Nokia teaches as per claim 12, wherein the core network includes a user plane function or an access and mobility management function; see page 2 option 2.2 UPF.
Regarding claim 21,Nokia teaches an apparatus for wireless communication comprising: one or more processor configured to (see introduction; apparatus as a core network here SMF):
receive, by a core network, a request message to from a first access node indicating a switch from a shared tunnel to a unicast tunnel for MBS data (see page 2 (i.e. context with page 1 wherein option 2 is selected… that the SMF indicates to the NG-RAN node that the unicast QoS flow which is being setup is associated to an MBS QoS flow, … )… the source NGRAN (i.e. first access node) node knows in advance whether the target NG-RAN node supports MBS or not. In this case, the source NG-RAN node can send a trigger to SMF to switch from shared delivery to individual delivery just before the handover takes place. This, in turn, triggers SMF to request the setup of an N9 interface between MB-UPF and UPF; option 2.1; further see option 2.2 … Alternatively, the source NG-RAN can trigger the handover directly from shared delivery. During the handover the Path Switch Request message serves as trigger for the SMF to trigger the switch from shared delivery into individual delivery: SMF can contact the UPF to get a DL GTP TEID, then send this DL GTP TEID to the MB-UPF via the MB-SMF. The MB-UPF is ready to deliver multicast data to UPF in individual delivery mode. The complete procedure can take place during the path switch procedure and can end with SMF sending the Path Switch Request Acknowledge message to target NG-RAN node ); and
transmit, from the core network in response to the switch to the unicast tunnel, the MBS data for an MBS session via the unicast tunnel (see page 1….. provided that the SMF indicates to the NG-RAN node that the unicast QoS flow which is being setup is associated to an MBS QoS flow, the NG-RAN node can setup the unicast QoS flow while refraining from assigning radio resources to it, even though the unicast N3 tunnel could be setup…; further see page 2 option 2.2… Alternatively, the source NG-RAN can trigger the handover directly from shared delivery. During the handover the Path Switch Request message serves as trigger for the SMF to trigger the switch from shared delivery into individual delivery: SMF can contact the UPF to get a DL GTP TEID, then send this DL GTP TEID to the MB-UPF via the MB-SMF. The MB-UPF is ready to deliver multicast data to UPF in individual delivery mode. The complete procedure can take place during the path switch procedure and can end with SMF sending the Path Switch Request Acknowledge message to target NG-RAN node; further see page 2 proposal 3 regarding agree to standardize only option 2.2; also refer to page 3 first ten lines… select option 2 and agree that the unicast QoS flow associated to an MBS QoS flow can be setup at PDU session resource setup/modify, with a mapping between the MBS flow and the associated unicast QoS flow … agree to standardize only option 2.2 for Xn mobility from MBS-supporting to non-MBS-supporting NG-RAN nodes where the switch from shared delivery to individual delivery takes place during the path switch procedure by the SMF…..).
Claim Rejections - 35 USC § 103
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.
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 nonobviousness.
Claim(s) 4, 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mohammed Mikaeil et al. (US Pub. No. 2024/0214875 A1), hereafter Ahmed in view of Jia et al. (US Pub. No. 2023/0164640 A1).
Regarding claim 4, Ahmed teaches as per claim 2, but fails to state about wherein the request message comprises information associated with the unicast tunnel, wherein the information includes at least an identifier of the unicast tunnel or Quality of Service (QoS) information associated with the unicast tunnel; however Jia states in [0478- 0479] regarding .. , the “handover required” includes PDU session information of the UE to be handed over and associated multicast service information (including an associated multicast service identifier), and the PDU session information includes a PDU session identifier and QoS information corresponding to a unicast service flow included in the PDU session. The QoS information of the unicast service flow includes a QFI and a QoS parameter. If the PDU session of the current UE to be handed over is associated with the multicast service, the S-gNB may map a multicast QoS flow to a unicast QoS flow based on a mapping relationship between a multicast QoS flow QFI and a unicast QoS flow QFI (QoS flow identifier); further see [0481]). It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Jia with the teachings of Ahmed to make system more effective. Having a mechanism wherein the request message comprises information associated with the unicast tunnel, wherein the information includes at least an identifier of the unicast tunnel or Quality of Service (QoS) information associated with the unicast tunnel; greater way resources can be managed/utilized in order to carry out more reliable communication in the communication system.
Regarding claim 7, Ahmed teaches as per claim 2, but fails to teach about wherein the transmitting of the handover request comprises transmitting, by the first access node, the handover request to the second access node via the core network; however Jia sattes in Fig. 10A regarding T-gnB (second access node) receives handover request (#1008) from S-gNb (first access node) via S-AMF (core). It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Jia with the teachings of Ahmed to make system more standardized. Having a mechanism wherein the transmitting of the handover request comprises transmitting, by the first access node, the handover request to the second access node via the core network; greater way more standardized approach can be carried out.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mohammed Mikaeil et al. (US Pub. No. 2024/0214875 A1), hereafter Ahmed in view of Wang et al. (US Pub. No. 2022/0124583 A1).
Regarding claim 9, Ahmed teaches as per claim 1, but fails to sate about wherein each of the first set and the second set of MBS data packets is associated with a unique sequence number, and wherein the method further comprises re-ordering the first set and the second set of MBS data packets based on a respective unique sequence number prior to forwarding the at least part of the first set and/or the second set of MBS data packets to the second access node; however Wang states in [0345] about .. When the source base station decides to initiate the handover procedure, the source base station starts to save/buffer the data that has not been sent to the UE at this time (i.e. first set), and also saves/buffers the data newly received (i.e. second set) from the core network. These data are all the data to be forwarded to the destination base station. The buffering starts from the time when the handover is initiated, and ends when the source base station receives the release request message sent by the destination base station, or ends at a certain time point after receipt of the release request message sent by the destination base station, which can be implementation-related; now refer to [0346- 0347] The message may also contain the PDCP SN corresponding to the MBS data transmission of the source base station and the SN of the corresponding GTP-U, and the specific contents are as described in Embodiments 1 to 6. The GTP-U SN is the sequence number contained in the data packet sent by the core network to the base station, and can be contained in the header of the GTP-U or the extended header of the GTP-U. This SN can be for a PDU session, a QoS flow, or multiple QoS flows, for example, multiple QoS flows mapped onto the same radio bearer. For the same data packet, the GTP-U SNs sent to different base stations are the same, so the destination base station can know the PDCP SN assigned by the source base station for a data packet of the same GTP-U SN, and thus can know the difference between the PDCP SN assigned by the destination base station and the PDCP SN assigned by the source base station, which is called PDCP SN difference. It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Wang with the teachings of Ahmed to make system more effective. Having a mechanism wherein each of the first set and the second set of MBS data packets is associated with a unique sequence number, and wherein the method further comprises re-ordering the first set and the second set of MBS data packets based on a respective unique sequence number prior to forwarding the at least part of the first set and/or the second set of MBS data packets to the second access node; greater way resources can be managed/utilized in the communication system.
Claim(s) 17- 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Source: Nokia, Nokia Shanghai Bell Title: Mobility from MBS Supporting to Non-Supporting MBS nodes, R3-210173; see IDS filed on 4/4/2025, page 1 cite #1 in view of Jia et al. (US Pub. No. 2023/0164640 A1).
Regarding claim 17 teaches as per claim 12, but fails to state about wherein the request message comprises information associated with the MBS session, wherein the information includes at least an identifier of the MBS session or information about the shared tunnel; however Jia teaches in [0478- 0479] regarding .. , the “handover required” includes PDU session information of the UE to be handed over and associated multicast service information (including an associated multicast service identifier), and the PDU session information includes a PDU session identifier and QoS information corresponding to a unicast service flow included in the PDU session. The QoS information of the unicast service flow includes a QFI and a QoS parameter. If the PDU session of the current UE to be handed over is associated with the multicast service, the S-gNB may map a multicast QoS flow to a unicast QoS flow based on a mapping relationship between a multicast QoS flow QFI and a unicast QoS flow QFI (QoS flow identifier); further see [0481]). It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Jia with the teachings of Ahmed to make system more effective. Having a mechanism wherein the request message comprises information associated with the MBS session, wherein the information includes at least an identifier of the MBS session or information about the shared tunnel; greater way resources can be managed/utilized in order to carry out more reliable communication in the communication system.
Regarding claim 18 teaches as per claim 12, but fails to state about wherein the request message comprises information associated with the unicast tunnel, wherein the information includes at least an identifier of the unicast tunnel or Quality of Service (QoS) information associated with the unicast tunnel; however Jia teaches in [0478- 0479] regarding .. , the “handover required” includes PDU session information of the UE to be handed over and associated multicast service information (including an associated multicast service identifier), and the PDU session information includes a PDU session identifier and QoS information corresponding to a unicast service flow included in the PDU session. The QoS information of the unicast service flow includes a QFI and a QoS parameter. If the PDU session of the current UE to be handed over is associated with the multicast service, the S-gNB may map a multicast QoS flow to a unicast QoS flow based on a mapping relationship between a multicast QoS flow QFI and a unicast QoS flow QFI (QoS flow identifier); further see [0481]). It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Jia with the teachings of Ahmed to make system more effective. Having a mechanism wherein the request message comprises information associated with the unicast tunnel, wherein the information includes at least an identifier of the unicast tunnel or Quality of Service (QoS) information associated with the unicast tunnel; greater way resources can be managed/utilized in order to carry out more reliable communication in the communication system.
Claim(s) 13, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Source: Nokia, Nokia Shanghai Bell Title: Mobility from MBS Supporting to Non-Supporting MBS nodes, R3-210173; see IDS filed on 4/4/2025, page 1 cite #1 in view of Liu et al. (US Pub. No. 2023/0300681 A1).
Regarding claim 13, Nokia teaches as per claim 12, but fails to teach about transmitting, by the core network in response to the request message, a confirmation message to the first access node acknowledging the switch to the unicast tunnel; see page 2 option 2.2 acknowledge message; Liu teaches in Fig. 5 regarding in response to handover request message from first network device (i.e. first access node), core network control panel network element transmitting response back as a “handover request acknowledgement” to first network device; further see [0020]... the information interaction (see [0019] performed by first network device) method further includes: determining whether the second network device supports a first MBS; and in the case that the second network device selected by the first network device does not support the first MBS, triggering a core network device to perform a switching process from multicast to unicast….; further see claim 13. It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Liu with the teachings of Nokia to make system more standardized. Having a mechanism wherein transmitting, by the core network in response to the request message, a confirmation message to the first access node acknowledging the switch to the unicast tunnel; greater way more standardized approach can be carried out in the communication system.
Regarding claim 19, Nokia in view of Liu teaches as claim 13, wherein the confirmation message comprises at least information of the MBS session, information of the unicast tunnel, an acknowledgement indicator indicating the switch has completed successfully, or Quality of Service (QoS) information associated with the unicast tunnel; Liu see claim 1 wherein the handover request acknowledgement message carrying access control-related information of the first MBS (i.e. relevant information of a first Multicast Broadcast Service (MBS); now refer to claim 4 wherein the relevant information of the first MBS comprises at least one of: Quality of Service (QoS) flow information of the first MBS; service identification information of the first MBS; identification information of a first MBS group; session information of the first MBS; a transmission mode adopted by the first network device for the first MBS; a transmission mode expected or selected by the terminal; further see claim 5 wherein the access control related information of the first MBS comprises at least one of: a QoS flow for an accepted first MBS; session information of the accepted first MBS; a QoS flow for an unaccepted first MBS; session information of the unaccepted first MBS; an established or to-be-established first MBS session; Transmission Network Layer (TNL) address information for data forwarding; a transmission mode of the first MBS; now refer to claim 6 method according to claim 4 or 5, wherein the transmission mode comprises at least one of: a unicast transmission mode; a multicast transmission mode; a point-to-point transmission mode; a point-to-multipoint transmission mode.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please see PTO-892 form for considered prior arts for record.
Li et al. (US Pub. No. 2023/0345310 A1) teaches in [0131] regarding Delivery mode switch mentioned throughout the paper means 5GC switch the delivery method between 5GC Individual MBS traffic delivery and 5GC shared MBS traffic delivery to send the multicast/broadcast data to UE. This section presents the procedure of switching from unicast data (i.e. individual) transfer to multicast (i.e. shared); further see Methods of Switch from Multicast to Unicast Delivery [0208] This section presents the procedures of switching data transmission from multicast to unicast Events to Trigger Switch Process from Multicast to Unicast [0209] A UE 201 may request to switch from multicast to unicast for an application due to one of the following five reasons, among other things; in same above context refer to [0277] When a UE 201 receiving the multicast data is moving from the source RAN node (i.e. first access node) to the target RAN node (second access node), the UE 201 or source RAN node may trigger the delivery mode switch procedure along with the handover procedure. This trigger may be because the target RAN node does not support MBS service or UE 201 is out of an MBS service area. In addition, an NF such as AMF 203, MBMF, or MB-SMF 208/SMF 204 (i.e. consider as a core network) may trigger the switch as well after being notified by the source RAN node about the handover…; further see [0277].. For example, the SMF 204 may find out that the target RAN node is out of MBS service area when initiating the PDU session establishment or modification procedure. In case that MBSF is managing the MB-SMF 208 or SMF 204 with respect to the MBS service, the MBSF may trigger the switch; now refer to [0278].. After a switch to individual traffic delivery method, the UE 201 may receive the data over a PDU session through the target RAN node. Significant issues may include the following. A first issue with regard to how to link the MBS PDU session for shared delivery method and the PDU session for individual delivery method to make sure the QoS requirement is met. Or a second issue with regard to how to prevent the potential data loss during the handover/switch process; now in context with [0279] refer to [0280]… The benefit is that the UE 201 could provide the mapping at the beginning of handover process to the target RAN node, so that the switch process could be done faster. MB-SMF 208/SMF 204 managing the MBS session or the source RAN node could provide the QoS mapping to the UE 201. The QoS mapping information may include QFI of MBS PDU session and QFI of PDU session for the individual traffic delivery with the same QoS requirement, 5QI of MBS PDU session and 5QI of PDU session for the individual traffic delivery; now refer to [0281].. Regardless whether the target RAN node supports MBS service or not, during the time period between completion of handover and completion of switch, the UE 201 may not be able to receive data because handover is done while the switch is not finished yet, e.g., the PDU session for individual traffic delivery is not established yet or not activated yet. One possible approach is to let source RAN node continue to receive and store the MBS data during the time period and forwards the data to the target RAN node. When the PDU session is ready for individual traffic delivery to UE 201..).
Reference Xiong (US Pub. No. 2023/0082364 A1) teaches in [0070] regarding …. implementing multicast broadcast service handover provided in the embodiments of the present disclosure, in one aspect, after UE is handed over from a source base station supporting an MBS service to a target base station not supporting an MBS service, when or in response to a determination that the source base station supports the MBS and the target base station does not support the MBS, the SMF may directly acquire policy rule information of an activated MBS session through a PCF, so that a quality of service (QoS, which may be all quality of service flows corresponding to the activated MBS session) flow corresponding to the activated MBS session may be established on a PDU session associated with the MBS session, thereby simplifying a procedure of acquiring the policy rule information of the activated MBS session. In another aspect, this mode has minimal modification to a 5G system and implements switching of UE from an MBS session to a unicast PDU session during handover of the UE between a source base station supporting an MBS service and a target base station not supporting an MBS service, thereby implementing the continuity of an MBS service.
Reference Baek (US Pub. No. 2022/0322160 A1) teaches method for Xn handover of a multicast/broadcast service (MBS) by a session management function (SMF) device in a mobile communication system is provided. The method includes receiving, from a target next generation radio access network (NG-RAN) node through an access and mobility management function (AMF), a first message including information on whether the target NG-RAN node supports the MBS, determining an individual delivery method for MBS data, in case that the target NG-RAN node does not support the MBS based on the first message, and setting up the MBS data to be individually delivered to a user equipment (UE) through the target NG-RAN node; see abstract.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PARTH PATEL whose telephone number is (571)270-1970. The examiner can normally be reached 7 a.m. -7 p.m. PST.
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, Jae Y. Lee can be reached at 5712703936. 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.
PARTH PATEL
Primary Examiner
Art Unit 2479
/PARTH PATEL/Primary Examiner, Art Unit 2479