DETAILED ACTION
Response to Amendment
In response to amendment filed on 5/27/2026, claims 1-3, 5, 12, 14-15, 17 and 19-21 are amended. Claim 9 is canceled. Claims 1- 8, 10- 21 are pending for examinations. Further previously given objection for claim 12 is withdrawn.
Response to Arguments
Applicant’s arguments with respect to claim(s) filed in the remarks on 5/27/2026 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.
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) 1- 3, 5- 6, 8, 10- 11 and 20 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) and in further view of Wittberg et al. (US Pat. No. 11477845 B2).
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 that does not support the MBS (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).).
But Ahmed is silent about each of the first set of data packets is associated with a unique sequence number; wherein each of the second set of data packets is associated with a unique sequence number and also fails to state about reordering the first set of data packets and the second set of data packets based on a respective unique sequence number; and providing subsequent to the re-ordering first or second set of data packets to the second access node.
However Wang teaches 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 in context with [0060, 0067- 0082] (i.e. regarding SN information) 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; further see [0373]…. For example, if the first synchronization mode is adopted, i.e., GTP-U SN=PDCP SN, the base station receives a data packet with GTP-U SN=9, and assigns PDCP SN=9 to the data packet. If the data packet with GTP-U SN=10 is lost in the procedure of transmission from the core network to the base station, the base station receives the data packet with GTP-U SN=11 instead of the data packet with GTP-U SN=10, and the corresponding PDCP SN directly goes from 9 to 11, so the PDCP SN contained in the data packet sent by the base station is discontinuous. The UE side needs to sort the data according to the PDCP SN. If the UE does not receive PDCP SN=10, the UE may think that the data packet with PDCP SN=10 has not been sent successfully, and may require the base station to retransmit…; further see [0350]… According to the difference, data packets can be sorted. If the data packets are not continuous, the UE can know which data packets are lost, so the UE can request the destination base station to retransmit the lost data packets.
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 of data packets is associated with a unique sequence number; wherein each of the second set of data packets is associated with a unique sequence number and about reordering the first set of data packets and the second set of data packets based on a respective unique sequence number; and providing subsequent to the re-ordering first or second set of data packets to the second access node; greater way resources can be managed/utilized in the communication system.
But here Ahmed as well as Wang is silent about source node reorders these two set of data packets based on respective identifier before forwarding.
However Wittberg states in lines 10- 34 of col. 13 states regarding a method performed by a network node 606, 608, such as the RNN 606 or the communications device 608, for PDCP reordering will now be described. As previously mentioned, the network node 606,608 is operating in the wireless communications network 600. The method comprises one or more of the actions below and it should be understood that actions may be combined and that actions may be performed in any suitable order. Action 701A…………. The network node 606,608 buffers one or more first data units received out of order from a lower layer and during a first time period. Especially, the network node 606,608 buffers in order one or more first data units received out of order by a PDCP layer. In other words, the network node 606,608 buffers in sequence number order the one or more first data units received out of sequence number order by the PDCP layer. As mentioned above, the one or more first data units are received from a lower layer during a first time period. Further, the lower layer is a layer below the PDCP layer; also see lines 49- 54 of col. 14 about .. to perform the method for PDCP reordering, the network node 606,608 may be configured according to an arrangement depicted in FIG. 8. As previously described, the network node 206,208 is configured to operate in the wireless communications network 200. 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 Wittberg with the teachings of Ahmed in view of Wang to make system more effective. Having a mechanism wherein source node reorders two set of data packets based on respective identifier before forwarding; greater way resources can be managed in the communication system.
Regarding claim 2, Ahmed in view of Wang and Wittberg teaches as per claim 1, wherein Ahmed teaches the requesting comprises:
initiating, by the first access node, the handover procedure by transmitting a handover request that includes information associated 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 theunicast 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…), and
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 in view of Wang and Wittberg 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 associated the shared tunnel (Ahmed; 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 in view of Wang and Wittberg teaches as per claim 2, wherein the confirmation message comprises at least the information associated with the MBS session, information associated with the unicast tunnel, or Quality of Service (QoS) information associated with the unicast tunnel; Ahmed 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 in view of Wang and Wittberg 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; Ahmed see Fig. 7 HO request [TMGI, MRB].
Regarding claim 8, Ahmed in view of Wang and Wittberg 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; Ahmed 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 in view of Wang and Wittberg 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; Ahmed 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 in view of Wang and Wittberg teaches as per claim 1, wherein the core network includes a user plane function or an access and mobility management function; Ahmed 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 that does not support the MBS (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).).
But Ahmed is silent about each of the first set of data packets is associated with a unique sequence number; wherein each of the second set of data packets is associated with a unique sequence number and also fails to state about reordering the first set of data packets and the second set of data packets based on a respective unique sequence number; and providing subsequent to the re-ordering first or second set of data packets to the second access node.
However Wang teaches 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 in context with [0060, 0067- 0082] (i.e. regarding SN information) 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; further see [0373]…. For example, if the first synchronization mode is adopted, i.e., GTP-U SN=PDCP SN, the base station receives a data packet with GTP-U SN=9, and assigns PDCP SN=9 to the data packet. If the data packet with GTP-U SN=10 is lost in the procedure of transmission from the core network to the base station, the base station receives the data packet with GTP-U SN=11 instead of the data packet with GTP-U SN=10, and the corresponding PDCP SN directly goes from 9 to 11, so the PDCP SN contained in the data packet sent by the base station is discontinuous. The UE side needs to sort the data according to the PDCP SN. If the UE does not receive PDCP SN=10, the UE may think that the data packet with PDCP SN=10 has not been sent successfully, and may require the base station to retransmit…; further see [0350]… According to the difference, data packets can be sorted. If the data packets are not continuous, the UE can know which data packets are lost, so the UE can request the destination base station to retransmit the lost data packets.
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 of data packets is associated with a unique sequence number; wherein each of the second set of data packets is associated with a unique sequence number and about reordering the first set of data packets and the second set of data packets based on a respective unique sequence number; and providing subsequent to the re-ordering first or second set of data packets to the second access node; greater way resources can be managed/utilized in the communication system.
But here Ahmed as well as Wang is silent about source node reorders these two set of data packets based on respective identifier before forwarding.
However Wittberg states in lines 10- 34 of col. 13 states regarding a method performed by a network node 606, 608, such as the RNN 606 or the communications device 608, for PDCP reordering will now be described. As previously mentioned, the network node 606,608 is operating in the wireless communications network 600. The method comprises one or more of the actions below and it should be understood that actions may be combined and that actions may be performed in any suitable order. Action 701A…………. The network node 606,608 buffers one or more first data units received out of order from a lower layer and during a first time period. Especially, the network node 606,608 buffers in order one or more first data units received out of order by a PDCP layer. In other words, the network node 606,608 buffers in sequence number order the one or more first data units received out of sequence number order by the PDCP layer. As mentioned above, the one or more first data units are received from a lower layer during a first time period. Further, the lower layer is a layer below the PDCP layer; also see lines 49- 54 of col. 14 about .. to perform the method for PDCP reordering, the network node 606,608 may be configured according to an arrangement depicted in FIG. 8. As previously described, the network node 206,208 is configured to operate in the wireless communications network 200. 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 Wittberg with the teachings of Ahmed in view of Wang to make system more effective. Having a mechanism wherein source node reorders two set of data packets based on respective identifier before forwarding; greater way resources can be managed in the communication system.
Claim(s) 4, 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mohammed Mohammed Mikaeil et al. (US Pub. No. 2024/0214875 A1), hereafter Ahmed in view of Wang et al. (US Pub. No. 2022/0124583 A1) and in further view of Wittberg et al. (US Pat. No. 11477845 B2) in view of Jia et al. (US Pub. No. 2023/0164640 A1).
Regarding claim 4, Ahmed in view of Wang and Wittberg teaches as per claim 2, but Ahmed 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 in view of Wang and Wittberg 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 in view of Wang and Wittberg teaches as per claim 2, but Ahmed 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 in view of Wang and Wittberg 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) 12, 14- 16, 21 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; hereafter Nokia in view of Wang et al. (US Pub. No. 2022/0124583 A1) and in further view of Wittberg et al. (US Pat. No. 11477845 B2).
Regarding claim 12,Nokia teaches a method for wireless communications (see introduction), comprising:
receiving, by a core network, a request message from a first access node that supports multicast and broadcast service (MBS), wherein the request message indicates a switch from a shared tunnel to a unicast tunnel for MBS data for an MBS session, wherein the core network is configured to transmit to the first access node prior to receiving the request message, the MBS data via a shred tunnel (see page 2 (i.e. context with page 1 wherein option 2 is selected… that the SMF (i.e. core network) indicates to the NG-RAN node (i.e. first access 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 (i.e. core network) 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 to the first access node, 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…..).
But Nokia is silent about wherein the MBS data comprises a first set of data packets and a second set of data packets,each data packet being associated with a unique sequence number, wherein the first access node is configured, subsequent to receiving the MBS data, to: re-order the first set of data packets and the second set of data packets based on a respective unique sequence number, and provide, subsequent to the re-ordering, at least part of the first set of data packets or the second set of data packets to a second access node as part of a handover procedure from the first access node to the second access node that does not support the MBS.
However Wang teaches 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 in context with [0060, 0067- 0082] (i.e. regarding SN information) 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; further see [0373]…. For example, if the first synchronization mode is adopted, i.e., GTP-U SN=PDCP SN, the base station receives a data packet with GTP-U SN=9, and assigns PDCP SN=9 to the data packet. If the data packet with GTP-U SN=10 is lost in the procedure of transmission from the core network to the base station, the base station receives the data packet with GTP-U SN=11 instead of the data packet with GTP-U SN=10, and the corresponding PDCP SN directly goes from 9 to 11, so the PDCP SN contained in the data packet sent by the base station is discontinuous. The UE side needs to sort the data according to the PDCP SN. If the UE does not receive PDCP SN=10, the UE may think that the data packet with PDCP SN=10 has not been sent successfully, and may require the base station to retransmit…; further see [0350]… According to the difference, data packets can be sorted. If the data packets are not continuous, the UE can know which data packets are lost, so the UE can request the destination base station to retransmit the lost data packets.
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 the MBS data comprises a first set of data packets and a second set of data packets, each data packet being associated with a unique sequence number, wherein the first access node is configured, subsequent to receiving the MBS data, to: re-order the first set of data packets and the second set of data packets based on a respective unique sequence number, and provide, subsequent to the re-ordering, at least part of the first set of data packets or the second set of data packets to a second access node as part of a handover procedure from the first access node to the second access node that does not support the MBS; greater way resources can be managed/utilized in the communication system.
But here Nokia as well as Wang is silent about core network reorders these two sets of data packets based on respective identifier before forwarding.
However Wittberg states in lines 10- 34 of col. 13 states regarding a method performed by a network node 606, 608, such as the RNN 606 or the communications device 608, for PDCP reordering will now be described. As previously mentioned, the network node 606,608 is operating in the wireless communications network 600. The method comprises one or more of the actions below and it should be understood that actions may be combined and that actions may be performed in any suitable order. Action 701A…………. The network node 606,608 buffers one or more first data units received out of order from a lower layer and during a first time period. Especially, the network node 606,608 buffers in order one or more first data units received out of order by a PDCP layer. In other words, the network node 606,608 buffers in sequence number order the one or more first data units received out of sequence number order by the PDCP layer. As mentioned above, the one or more first data units are received from a lower layer during a first time period. Further, the lower layer is a layer below the PDCP layer; also see lines 49- 54 of col. 14 about .. to perform the method for PDCP reordering, the network node 606,608 may be configured according to an arrangement depicted in FIG. 8. As previously described, the network node 206,208 is configured to operate in the wireless communications network 200. 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 Wittberg with the teachings of Nokia in view of Wang to make system more effective. Having a mechanism wherein source node reorders two set of data packets based on respective identifier before forwarding; greater way resources can be managed in the communication system.
Regarding claim 14, Nokia in view of Wang and Wittberg teaches as per claim 12, further Nokia teaches comprising: performing, by the core network, the handover procedure from the first access node to the 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 in view of Wang and Wittberg teaches as per claim 12, wherein Nokia teaches 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 the handover procedure; 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 in view of Wang and Wittberg teaches as per claim 12, wherein the core network includes a user plane function or an access and mobility management function; Nokia 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 from a first access node that supports multicast and broadcast service (MBS), wherein the request message indicates a switch from a shared tunnel to a unicast tunnel for MBS data for an MBS session, wherein the core network is configured to transmit to the first access node prior to receiving the request message, the MBS data via a shred tunnel (see page 2 (i.e. context with page 1 wherein option 2 is selected… that the SMF (i.e. core network) indicates to the NG-RAN node (i.e. first access 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 (i.e. core network) 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 to the first access node, 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…..).
But Nokia is silent about wherein the MBS data comprises a first set of data packets and a second set of data packets,each data packet being associated with a unique sequence number, wherein the first access node is configured, subsequent to receiving the MBS data, to: re-order the first set of data packets and the second set of data packets based on a respective unique sequence number, and provide, subsequent to the re-ordering, at least part of the first set of data packets or the second set of data packets to a second access node as part of a handover procedure from the first access node to the second access node that does not support the MBS.
However Wang teaches 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 in context with [0060, 0067- 0082] (i.e. regarding SN information) 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; further see [0373]…. For example, if the first synchronization mode is adopted, i.e., GTP-U SN=PDCP SN, the base station receives a data packet with GTP-U SN=9, and assigns PDCP SN=9 to the data packet. If the data packet with GTP-U SN=10 is lost in the procedure of transmission from the core network to the base station, the base station receives the data packet with GTP-U SN=11 instead of the data packet with GTP-U SN=10, and the corresponding PDCP SN directly goes from 9 to 11, so the PDCP SN contained in the data packet sent by the base station is discontinuous. The UE side needs to sort the data according to the PDCP SN. If the UE does not receive PDCP SN=10, the UE may think that the data packet with PDCP SN=10 has not been sent successfully, and may require the base station to retransmit…; further see [0350]… According to the difference, data packets can be sorted. If the data packets are not continuous, the UE can know which data packets are lost, so the UE can request the destination base station to retransmit the lost data packets.
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 the MBS data comprises a first set of data packets and a second set of data packets, each data packet being associated with a unique sequence number, wherein the first access node is configured, subsequent to receiving the MBS data, to: re-order the first set of data packets and the second set of data packets based on a respective unique sequence number, and provide, subsequent to the re-ordering, at least part of the first set of data packets or the second set of data packets to a second access node as part of a handover procedure from the first access node to the second access node that does not support the MBS; greater way resources can be managed/utilized in the communication system.
But here Nokia as well as Wang is silent about core network reorders these two sets of data packets based on respective identifier before forwarding.
However Wittberg states in lines 10- 34 of col. 13 states regarding a method performed by a network node 606, 608, such as the RNN 606 or the communications device 608, for PDCP reordering will now be described. As previously mentioned, the network node 606,608 is operating in the wireless communications network 600. The method comprises one or more of the actions below and it should be understood that actions may be combined and that actions may be performed in any suitable order. Action 701A…………. The network node 606,608 buffers one or more first data units received out of order from a lower layer and during a first time period. Especially, the network node 606,608 buffers in order one or more first data units received out of order by a PDCP layer. In other words, the network node 606,608 buffers in sequence number order the one or more first data units received out of sequence number order by the PDCP layer. As mentioned above, the one or more first data units are received from a lower layer during a first time period. Further, the lower layer is a layer below the PDCP layer; also see lines 49- 54 of col. 14 about .. to perform the method for PDCP reordering, the network node 606,608 may be configured according to an arrangement depicted in FIG. 8. As previously described, the network node 206,208 is configured to operate in the wireless communications network 200. 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 Wittberg with the teachings of Nokia in view of Wang to make system more effective. Having a mechanism wherein source node reorders two set of data packets based on respective identifier before forwarding; greater way resources can be managed 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 Wang et al. (US Pub. No. 2022/0124583 A1) and in further view of Wittberg et al. (US Pat. No. 11477845 B2) and in view of Liu et al. (US Pub. No. 2023/0300681 A1).
Regarding claim 13, Nokia in view of Wang and Wittberg teaches as per claim 12, but Nokia 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 in view of Wang and Wittberg 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 Wang and Wittberg and Liu teaches as claim 13, wherein the confirmation message comprises at least information associated with the MBS session, information associated with 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.
Claim(s) 17- 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Source: 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 in view of Wang et al. (US Pub. No. 2022/0124583 A1) and in further view of Wittberg et al. (US Pat. No. 11477845 B2) and in view of Jia et al. (US Pub. No. 2023/0164640 A1).
Regarding claim 17 Nokia in view of Wang and Wittberg teaches as per claim 12, but Nokia 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 Nokia in view of Wang and Wittberg 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 Nokia in view of Wang and Wittberg teaches as per claim 12, but Nokia 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 Nokia in view of Wang and Wittberg 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.
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.
Reference Meylan (US Pat. No. 11647435 B2) teaches A user equipment (UE) may be handed over from a source base station to a target base station. The source base station may forward packets for the UE to the target base station, which may receive the packets out of order. In one design, the target base station may determine whether each packet can be sent in order to the UE, send the packet if it can be sent in order, and discard the packet otherwise. In another design, the target base station may re-order packets received within a re-ordering window and may send the re-ordered packets to the UE. In yet another design, the target base station may process each packet received out of order as if the packet is in order, e.g., by incrementing a hyper-frame number (HFN) or re-assigning the packet with a later sequence number.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights