DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The following is a non-final office action in response to applicant’s amendment filed on 04/24/2026 for response of the office action mailed on 01/27/2026. Claims 1, 5, 7-9, 11, 13, 17, 19 and 23 have been amended. Claims 6, 18, 20-22 and 24-53 are cancelled. Claims 1-5, 7-17, 19 and 23 are pending in this application.
Response to Arguments
Applicant’s arguments with respect to Claims 1-5, 7-17, 19 and 23 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
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 1, 4-5, 7-13, 16-17, 19 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Talebi Fard, and further in view of Godin et al. (US 2022/0322048), Godin hereinafter.
Re. Claim 1, Talebi Fard teaches a method performed by a session management function, SMF, comprising: sending, to a user plane function, UPF, a first request for modifying a packet forwarding control protocol, PFCP, session for a protocol data unit, PDU, session associated with a multicast broadcast service, MBS, session, (Fig. 10, 19-21, 24-33 & ¶0212 - In an example, the new UPF 110 (intermediate) may send to SMF 160 an N4 session establishment response message 1030. ¶0294 - The SMF may sends the N4 session establishment/modification request to the UPF and may provide packet detection (e.g., PDR), forwarding (e.g., FAR), enforcement and reporting rules to be installed on the UPF for the PDU session. ¶0337 - At 3310, a user plane function (UPF) may receive, from a session management function (SMF), a session configuration message. The session configuration message may comprise a packet detection rule (PDR) for a group communication session. The PDR may comprise a multicast address mapped to a plurality of wireless devices associated with the group communication session. The PDR may comprise a forwarding rule for packets associated with the multicast address. Data packets comprising the multicast address may be received. Based on the PDR, the data packets may be sent to the plurality of wireless devices);
wherein the first request comprises an identification of the MBS session; (¶0288 - The group communication may comprise broadcast … The multicast information may comprise an identifier/identifiers/addresses of one or more wireless devices. Please also see ¶0252 and ¶0289);
and receiving, from the UPF, a first response to the first request, (Fig. 10, 25, 31 & ¶0212 - In an example, the new UPF 110 (intermediate) may send to SMF 160 an N4 session establishment response message 1030. ¶0287 - An example FIG. 25 depicts a UPF that is configured based on the multicast information, and receives data for the group associated with the multicast information. The UPF may send a data notification that may comprise multicast information, multicast address, a PDR ID associated with the group, and/or the like to the SMF. ¶0290 - In an example embodiment, data notification may part of an N4 related procedure, PFCP session related procedure, N4 reporting to detection of arrival of packets, N4 reporting for detection of inactivity for PDU sessions of a group, and/or the like. Please also see ¶0330);
Yet, Talebi Fard does not explicitly teach wherein the first response comprises tunnel information about a UPF endpoint of a tunnel between the UPF and a multicast broadcast (MB) UPF; and a first indicator indicating whether the tunnel information is newly allocated.
However, in the analogous art, Godin explicitly teaches wherein the first response comprises tunnel information about a UPF endpoint of a tunnel between the UPF and a multicast broadcast (MB) UPF; and a first indicator indicating whether the tunnel information is newly allocated (Fig. 2 & ¶0042 - In this example, the PFCP session creation/modification request is extended so that SMF1 indicates that PSA UPF 1 will be receiving data for MBS session 1. As further illustrated in the example of FIG. 2, at 204, PSA UPF1 may detect that no MBS context exists yet for the received MBS session 1. In this case, the PSA UPF 1 may create a context for MBS session 1 and, at 206, send back a “context created indicator” and an F-TEID to SMF 1. This may trigger, at 208, SMF1 to set up a tunnel between MB-UPF and PSA UPF 1 using the received F-TEID and the internet protocol address serving as PSA UPF 1 ingress point for receiving the multicast data).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Godin to the teaching of Talebi Fard. The motivation would be because the invention relates to systems and/or methods for distributing multicast packets in individual protocol data unit (PDU) sessions (¶0002, Godin).
Re. Claims 4 and 16, Talebi Fard and Godin teach Claims 1 and 13.
Talebi Fard further teaches the first request further comprises: a packet detection rule, PDR, for identifying the data of the MBS session; and a forwarding action rule, FAR, associated with the PDR (Fig. 10, 19-21, 24-33 & ¶0282 - The SMF allocates or retrieves the multicast information associated with the group and provide the multicast information to the UE members of the group. The SMF may provide the PDR, packet handling rules, and FAR to the UPF based on the multicast information. ¶0294 - The SMF may sends the N4 session establishment/modification request to the UPF and may provide packet detection (e.g., PDR), forwarding (e.g., FAR), enforcement and reporting rules to be installed on the UPF for the PDU session. Please also see ¶0333).
Re. Claims 5 and 17, Talebi Fard and Godin teach Claims 1 and 13.
Talebi Fard further teaches the PDU session is the first PDU session joining the MBS session in the SMF; (Fig. 12-13, 18, 20 & ¶0237 - In an example, the UE 100, in order to establish a new PDU session, may generate a new PDU session ID … In an example, the PDU session establishment request message may contain SM PDU DN request container containing information for the PDU session authorization by the external DN. ¶0270 - In an example FIG. 18, a UE may establish a PDU session to join a group. Please also see ¶0291);
and wherein the first request indicates the UPF to allocate, for the MBS session, tunnel information about the UPF endpoint of the tunnel between the UPF and the MB-UPF (Fig. 19 & ¶0212 - In case the UPF 110 may allocate CN tunnel info, the UPF 110 may provide DL CN tunnel info for the UPF 110 acting as PDU session anchor and UL CN tunnel info (e.g., CN N3 tunnel info) to the SMF 160. If the data forwarding indication may be received, the new (intermediate) UPF 110 acting as N3 terminating point may send DL CN tunnel info for the old (intermediate) UPF 110-2 to the SMF 160. ¶0269 - The SMF may send session establishment request to UPF2, including the allocated CN tunnel information and the allocated addresses for one to many data communication. The CN tunnel information may comprise the UPF2 address of the tunnel between UPF1 and UPF2 and the UPF2 address of N3 tunnel. UPF2 may acknowledge by sending Session establishment response message. The SMF may establish a group forwarding tunnel between UPF1 and UPF2, and may provide the UPF2 address of the tunnel between UPF1 and UPF2, as well as addresses for one to many data communication to UPF1).
Re. Claims 7 and 19, Talebi Fard and Godin teach Claims 1 and 13.
Yet, Talebi Fard does not explicitly teach the first response comprises: a second indicator indicating whether the UPF has joined a multicast group for the MBS session without allocating tunnel information about the UPF endpoint of the tunnel between the UPF and the MB-UPF.
However, in the analogous art, Godin explicitly teaches the first response comprises: a second indicator indicating whether the UPF has joined a multicast group for the MBS session without allocating tunnel information about the UPF endpoint of the tunnel between the UPF and the MB-UPF (Fig. 5 & ¶0045 - As illustrated in the example of FIG. 5, at 502, SMF1 may inform PSA UPF 1 that it will start receiving data for a multicast session and that it will forward the data in a PDU session. In this example, the PFCP session creation/modification request is extended so that SMF1 indicates that PSA UPF 1 will be receiving data for MBS session 1 and that it will forward data from the MBS session within a PDU session. As further illustrated in the example of FIG. 5, at 504, PSA UPF1 may detect that a context already exists for the received MBS session 1. In this case, at 506, the PSA UPF 1 may send back a “context exists indicator,” and optionally including an F-TEID and an internet protocol address, to SMF 1. This may trigger, at 508, SMF1 to detect that no tunnel set up is required and therefore not setup a tunnel. In this example, the PSA UPF also configures PDU session context to associate it with MBS session and forward related data).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Godin to the teaching of Talebi Fard. The motivation would be because the invention relates to systems and/or methods for distributing multicast packets in individual protocol data unit (PDU) sessions (¶0002, Godin).
Re. Claim 8, Talebi Fard and Godin teach Claim 1.
Yet, Talebi Fard does not explicitly teach when the first indicator indicates that the tunnel information is newly allocated, sending the tunnel information to an MB-SMF for establishing a multicast session distribution between the UPF and the MB-UPF.
However, in the analogous art, Godin explicitly teaches when the first indicator indicates that the tunnel information is newly allocated, sending the tunnel information to an MB-SMF for establishing a multicast session distribution between the UPF and the MB-UPF (Fig. 2 & ¶0042 - In this example, the PFCP session creation/modification request is extended so that SMF1 indicates that PSA UPF 1 will be receiving data for MBS session 1. As further illustrated in the example of FIG. 2, at 204, PSA UPF1 may detect that no MBS context exists yet for the received MBS session 1. In this case, the PSA UPF 1 may create a context for MBS session 1 and, at 206, send back a “context created indicator” and an F-TEID to SMF 1. This may trigger, at 208, SMF1 to set up a tunnel between MB-UPF and PSA UPF 1 using the received F-TEID and the internet protocol address serving as PSA UPF 1 ingress point for receiving the multicast data).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Godin to the teaching of Talebi Fard. The motivation would be because the invention relates to systems and/or methods for distributing multicast packets in individual protocol data unit (PDU) sessions (¶0002, Godin).
Re. Claim 9, Talebi Fard and Godin teach Claim 1.
Yet, Talebi Fard does not explicitly teach tunnel information about the UPF endpoint of tunnel between the UPF and the MB-UPF has been received and stored previously by the SMF for the MBS session in the UPF; and wherein the first request comprises the tunnel information.
However, in the analogous art, Godin explicitly teaches tunnel information about the UPF endpoint of tunnel between the UPF and the MB-UPF has been received and stored previously by the SMF for the MBS session in the UPF; (Fig. 3 ¶0043 - As further illustrated in the example of FIG. 3, at 304, PSA UPF1 may detect that a context already exists for the received MBS session 1. In this case, at 306, the PSA UPF 1 may send back a “context exists indicator,” and optionally including an F-TEID and an internet protocol address, to SMF 1);
and wherein the first request comprises the tunnel information (¶0032 - … the serving session management function (SMF) 1 (serving the PDU session associated with the MBS session) ensures that this PDU session, and more precisely the PSA UPF involved in this PDU session, receives multicast packets of the MBS session coming from the MB-UPF over a GTP tunnel. For this, the SMF 1 can receive DL tunnel endpoint identifier (TEID) and an internet protocol address from PSA UPF 1 and send it to MB-UPF via MB-SMF. ¶0043 - As illustrated in the example of FIG. 3, at 302, SMF1 may inform PSA UPF 1 that it will start receiving data for a multicast session, e.g., via a PFCP session creation/modification request that is extended so that SMF1 indicates that PSA UPF 1 will be receiving data for MBS session 1);
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Godin to the teaching of Talebi Fard. The motivation would be because the invention relates to systems and/or methods for distributing multicast packets in individual protocol data unit (PDU) sessions (¶0002, Godin).
Re. Claim 10, Talebi Fard and Godin teach Claim 1.
Yet, Talebi Fard does not explicitly teach sending, to the UPF, a second request for modifying the PFCP session for the PDU session, wherein the second request indicates the UPF to remove a PDR for identifying the data of the MBS session; and receiving, from the UPF, a second response to the second request.
However, in the analogous art, Godin explicitly teaches sending, to the UPF, a second request for modifying the PFCP session for the PDU session, wherein the second request indicates the UPF to remove a PDR for identifying the data of the MBS session; (Fig. 10 & ¶0050 - As illustrated in the example of FIG. 10, at 1002, SMF1 may inform PSA UPF 1 that it will stop multicast traffic forwarding of MBS session 1 over a PDU session 1. In this example, the SMF1 may indicate to remove a PDR associated to a multicast session);
and receiving, from the UPF, a second response to the second request (¶0050 - As further illustrated in the example of FIG. 10, at 1004, PSA UPF1 may de-associate the PDU session 1 from MBS session 1 context and stop delivering multicast data over PDU session 1. If the PSA UPF1 detects that there is no remaining PDU session associated to the MBS session 1 context, then several options are provided for removal of the MBS session 1 context in the PSA UPF1 and for removal of the tunnel between PSA UPF1 and MB-UPF. In the example of FIG. 10, the PSA UPF1 may keep the MBS session 1 context and, at 1006, may send back a “last association removed indicator” to SMF1. Please also see Fig. 11 & ¶0051).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Godin to the teaching of Talebi Fard. The motivation would be because the invention relates to systems and/or methods for distributing multicast packets in individual protocol data unit (PDU) sessions (¶0002, Godin).
Re. Claim 11, Talebi Fard and Godin teach Claim 10.
Yet, Talebi Fard does not explicitly teach the second response comprises: a third indicator indicating whether a tunnel between the UPF and the MB-UPF is to be released.
However, in the analogous art, Godin explicitly teaches the second response comprises: a third indicator indicating whether a tunnel between the UPF and the MB-UPF is to be released (Fig. 10-13 & ¶0050 - This may trigger the SMF1, at 1008, to decide whether to keep the context/tunnel. If SMF1 decides to release the context/tunnel, then SMF1 may request PSA UPF1 to release the MBS session context and request MB-UPF (e.g., via MB-SMF) to release the tunnel. ¶0051 - For instance, if the PSA UPF1 detects that there is no remaining PDU session associated to the MBS session 1 context, the PSA UPF1 may release the MBS session 1 context and, at 1106, may send back a “MBS session removed indicator” to SMF1. This may trigger the SMF1, at 1108, to request MB-UPF (e.g., via MB-SMF) to release the tunnel. ¶0052 - For instance, if MBS session 1 context is released the PSA UPF1 may send back, at 1206, a “MBS session 1 context removed indicator.” This may trigger in turn the SMF1, at 1208, to request MB-UPF (via MB-SMF) to release the tunnel. ¶0053 - In the example of FIG. 13, if the PSA UPF1 detects that there is no remaining PDU session associated to the MBS session 1 context, then PSA UPF1 may decide to keep the MBS session context and, at 1306, may send back an indication to SMF1 of the decision to keep the MBS session context. This may trigger the SMF1, at 1308, to not release the tunnel).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Godin to the teaching of Talebi Fard. The motivation would be because the invention relates to systems and/or methods for distributing multicast packets in individual protocol data unit (PDU) sessions (¶0002, Godin).
Re. Claim 12, Talebi Fard and Godin teach Claim 11.
Yet, Talebi Fard does not explicitly teach when the third indicator indicates that the tunnel is to be released, sending, to an MB- SMF, information about the release of the tunnel.
However, in the analogous art, Godin explicitly teaches when the third indicator indicates that the tunnel is to be released, sending, to an MB- SMF, information about the release of the tunnel (Fig. 10-12 & ¶0050 - In the example of FIG. 10, the PSA UPF1 may keep the MBS session 1 context and, at 1006, may send back a “last association removed indicator” to SMF1. This may trigger the SMF1, at 1008, to decide whether to keep the context/tunnel. If SMF1 decides to release the context/tunnel, then SMF1 may request PSA UPF1 to release the MBS session context and request MB-UPF (e.g., via MB-SMF) to release the tunnel. ¶0051 - For instance, if the PSA UPF1 detects that there is no remaining PDU session associated to the MBS session 1 context, the PSA UPF1 may release the MBS session 1 context and, at 1106, may send back a “MBS session removed indicator” to SMF1. This may trigger the SMF1, at 1108, to request MB-UPF (e.g., via MB-SMF) to release the tunnel. ¶0052 - As further illustrated in the example of FIG. 12, at 1204, PSA UPF1 may de-associate the PDU session 1 from MBS session 1 context and, since no PDU session is remaining, may release the context. For instance, if MBS session 1 context is released the PSA UPF1 may send back, at 1206, a “MBS session 1 context removed indicator. This may trigger in turn the SMF1, at 1208, to request MB-UPF (via MB-SMF) to release the tunnel).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Godin to the teaching of Talebi Fard. The motivation would be because the invention relates to systems and/or methods for distributing multicast packets in individual protocol data unit (PDU) sessions (¶0002, Godin).
Re. Claim 13, Talebi Fard teaches a method performed by a user plane function, UPF, comprising: receiving, from a session management function, SMF, a first request for modifying a packet forwarding control protocol, PFCP, session for a protocol data unit, PDU, session associated with a multicast broadcast service, MBS, session, (Fig. 10, 19-21, 24-33 & ¶0210 - In an example, the SMF 160 may send to the UPF 110 (e.g., new intermediate UPF 110) an N4 session establishment request 1030. ¶0294 - The SMF may sends the N4 session establishment/modification request to the UPF and may provide packet detection (e.g., PDR), forwarding (e.g., FAR), enforcement and reporting rules to be installed on the UPF for the PDU session. ¶0337 - At 3310, a user plane function (UPF) may receive, from a session management function (SMF), a session configuration message. The session configuration message may comprise a packet detection rule (PDR) for a group communication session. The PDR may comprise a multicast address mapped to a plurality of wireless devices associated with the group communication session. The PDR may comprise a forwarding rule for packets associated with the multicast address. Data packets comprising the multicast address may be received. Based on the PDR, the data packets may be sent to the plurality of wireless devices);
wherein the first request comprises an identification of the MBS session; (¶0288 - The group communication may comprise broadcast … The multicast information may comprise an identifier/identifiers/addresses of one or more wireless devices. Please also see ¶0252 and ¶0289);
and sending, to the SMF, a first response to the first request, (Fig. 10, 25, 31 & ¶0212 - In an example, the new UPF 110 (intermediate) may send to SMF 160 an N4 session establishment response message 1030. ¶0287 - An example FIG. 25 depicts a UPF that is configured based on the multicast information, and receives data for the group associated with the multicast information. The UPF may send a data notification that may comprise multicast information, multicast address, a PDR ID associated with the group, and/or the like to the SMF. ¶0290 - In an example embodiment, data notification may part of an N4 related procedure, PFCP session related procedure, N4 reporting to detection of arrival of packets, N4 reporting for detection of inactivity for PDU sessions of a group, and/or the like. Please also see ¶0330).
Yet, Talebi Fard does not explicitly teach wherein the first response comprises tunnel information about a UPF endpoint of a tunnel between the UPF and a multicast broadcast (MB) UPF; and a first indicator indicating whether the tunnel information is newly allocated.
However, in the analogous art, Godin explicitly teaches wherein the first response comprises tunnel information about a UPF endpoint of a tunnel between the UPF and a multicast broadcast (MB) UPF; and a first indicator indicating whether the tunnel information is newly allocated (Fig. 2 & ¶0042 - In this example, the PFCP session creation/modification request is extended so that SMF1 indicates that PSA UPF 1 will be receiving data for MBS session 1. As further illustrated in the example of FIG. 2, at 204, PSA UPF1 may detect that no MBS context exists yet for the received MBS session 1. In this case, the PSA UPF 1 may create a context for MBS session 1 and, at 206, send back a “context created indicator” and an F-TEID to SMF 1. This may trigger, at 208, SMF1 to set up a tunnel between MB-UPF and PSA UPF 1 using the received F-TEID and the internet protocol address serving as PSA UPF 1 ingress point for receiving the multicast data).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Godin to the teaching of Talebi Fard. The motivation would be because the invention relates to systems and/or methods for distributing multicast packets in individual protocol data unit (PDU) sessions (¶0002, Godin).
Re. Claim 23, Talebi Fard teaches a method performed by a session management function, SMF, comprising: sending, to a user plane function, UPF, a first request for establishing a first packet forwarding control protocol, PFCP, session for a multicast broadcast service, MBS, session, (Fig. 10, 19-21, 24-33 & ¶0210 - In an example, the SMF 160 may send to the UPF 110 (e.g., new intermediate UPF 110) an N4 session establishment request 1030. ¶0294 - The SMF may sends the N4 session establishment/modification request to the UPF and may provide packet detection (e.g., PDR), forwarding (e.g., FAR), enforcement and reporting rules to be installed on the UPF for the PDU session. ¶0337 - At 3310, a user plane function (UPF) may receive, from a session management function (SMF), a session configuration message. The session configuration message may comprise a packet detection rule (PDR) for a group communication session. The PDR may comprise a multicast address mapped to a plurality of wireless devices associated with the group communication session. The PDR may comprise a forwarding rule for packets associated with the multicast address. Data packets comprising the multicast address may be received. Based on the PDR, the data packets may be sent to the plurality of wireless devices);
wherein the first request comprises an identification of the MBS session; (¶0288 - The group communication may comprise broadcast … The multicast information may comprise an identifier/identifiers/addresses of one or more wireless devices. Please also see ¶0252 and ¶0289);
and receiving, from the UPF, a first response to the first request (Fig. 10, 25, 31 & ¶0212 - In an example, the new UPF 110 (intermediate) may send to SMF 160 an N4 session establishment response message 1030. ¶0287 - An example FIG. 25 depicts a UPF that is configured based on the multicast information, and receives data for the group associated with the multicast information. The UPF may send a data notification that may comprise multicast information, multicast address, a PDR ID associated with the group, and/or the like to the SMF. ¶0290 - In an example embodiment, data notification may part of an N4 related procedure, PFCP session related procedure, N4 reporting to detection of arrival of packets, N4 reporting for detection of inactivity for PDU sessions of a group, and/or the like. Please also see ¶0330).
Yet, Talebi Fard does not explicitly teach wherein the first response comprises tunnel information about a UPF endpoint of a tunnel between the UPF and a multicast broadcast (MB) UPF; and a first indicator indicating whether the tunnel information is newly allocated.
However, in the analogous art, Godin explicitly teaches wherein the first response comprises tunnel information about a UPF endpoint of a tunnel between the UPF and a multicast broadcast (MB) UPF; and a first indicator indicating whether the tunnel information is newly allocated (Fig. 2 & ¶0042 - In this example, the PFCP session creation/modification request is extended so that SMF1 indicates that PSA UPF 1 will be receiving data for MBS session 1. As further illustrated in the example of FIG. 2, at 204, PSA UPF1 may detect that no MBS context exists yet for the received MBS session 1. In this case, the PSA UPF 1 may create a context for MBS session 1 and, at 206, send back a “context created indicator” and an F-TEID to SMF 1. This may trigger, at 208, SMF1 to set up a tunnel between MB-UPF and PSA UPF 1 using the received F-TEID and the internet protocol address serving as PSA UPF 1 ingress point for receiving the multicast data).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Godin to the teaching of Talebi Fard. The motivation would be because the invention relates to systems and/or methods for distributing multicast packets in individual protocol data unit (PDU) sessions (¶0002, Godin).
Claims 2 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Talebi Fard and Godin, and further in view of Li et al. (US 20240179802), Li hereinafter.
Re. Claims 2 and 14, Talebi Fard and Godin teach Claims 1 and 13.
Yet, Talebi Fard and Godin do not explicitly teach the first request further comprises information required for receiving data of the MBS session via multicast transport.
However, in the analogous art, Li explicitly teaches the first request further comprises information required for receiving data of the MBS session via multicast transport (Fig. 2 (Please see SMF/UPF & MB-SMF/MB-UPF), 3, 5, 7 & ¶0134 - In an embodiment, if multicast transport is used, the MB-SMF may send a multicast address for each area session ID to the SMF. ¶0135 - If multicast transport is used, the SMF may also send a multicast address of the corresponding area session ID to the NG-RAN. ¶0139 - In an embodiment, if the multicast transport is used, the MB-SMF may send the multicast address to the NG-RAN via the AMF according to the received area session ID).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Li to the teachings of Talebi Fard and Godin. The motivation would be because the invention relates to methods, systems, and devices for establishing the MBS session, and in particular to methods, systems, and devices for establishing the MBS session in separate MBS areas (¶0006, Li).
Claims 3 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Talebi Fard, Godin and Li, and further in view of Li et al. (US 20240172175), Li (2) hereinafter.
Re. Claims 3 and 15, Talebi Fard, Godin and Li teach Claims 2 and 14.
Talebi Fard further teaches the information required for receiving data of the MBS session via multicast transport comprises: a common downlink tunnel identifier, ID; (Fig. 10, 19-21, 24-33 & ¶0217 - In an example, the SMF 160 may send to the old UPF 110-2 an N4 session modification request 1045 (e.g., may comprise … new UPF 110 DL tunnel ID, and/or the like. Please also see ¶0289);
Yet, Talebi Fard, Godin and Li do not explicitly teach and a source specific multicast address, SSM.
However, in the analogous art, Li (2) explicitly teaches and a source specific multicast address, SSM (Fig. 6-8 & ¶0110 - The MBS Session ID may be formatted in one of the following: … 2) source specific IP multicast address (e.g., for MBS multicast session only). ¶0111 - UE 102 may obtain MBS Session ID via MBS service announcement. For MBS multicast Session, a source specific IP multicast address may be a globally unique identifier and may be assigned by 5GC or an external network).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Li (2) to the teachings of Talebi Fard, Godin and Li. The motivation would be because the invention describes methods, systems, and devices which may include a method of group paging performed during an MBS session activation procedure (¶0006, Li (2)).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALYSSA WILLIAMS whose telephone number is (571)270-7673. The examiner can normally be reached Mon-Fri 8-5pm. 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, Ayman Abaza can be reached on (571) 270-0422. 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.
/ALYSSA WILLIAMS/Examiner, Art Unit 2465B
/CHRISTOPHER T WYLLIE/Examiner, Art Unit 2465
Prosecution Insights