CTNF 18/729,545 CTNF 89706 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This action is in response to the application filed on 17 July 2024. Claims 1, 3-7, 13, 16, 18, 46-49, 68, and 72 are under examination. Information Disclosure Statement 06-52 The information disclosure statement (IDS) submitted on 19 August 2024, 17 July 2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Objections 07-29-01 AIA Claim s 48 is objected to because of the following informalities: claims 48 recites “N2”, which is abbreviation, “N2” should be spelled out . Appropriate correction is required. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-01 Claim 48 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. 07-34-05 AIA Claim 48 recites the limitation “ the N2 request " in line 1 . There is insufficient antecedent basis for this limitation in the claim. 07-34-05 AIA Claim 48 recites the limitation “ the N2 response " in line 2 . There is insufficient antecedent basis for this limitation in the claim. Claim Rejections - 35 USC § 102 07-07-aia AIA 07-07 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – 07-12-aia AIA (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. 07-15-03-aia AIA Claim s 1, 3-7, 13, 16, 18, 46-49, 68, and 72 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Becker et al. (US Publication 2010/0322128) . With respect to claims 1 and 68, Becker teaches A method performed by a radio access network node, comprising: receiving a first request from a core network node in a first network, (upon having received a trigger from the a centralized network node providing the multicast or broadcast service, such as the BM-SC, M-MME #10 and M-MME #11 send session start messages to all access nodes in Pool Area #1, i.e. eNodeBs#1 and eNodeB #3, eNodeB #4 and eNodeB #5 in the overlapping pool area region of Pool Area #1 and Pool Area #2, Paragraph 199) wherein the first request comprises a first multicast/broadcast service (MBS) session identifier (ID) for a first broadcast MBS session and an associated session ID, wherein the associated session ID is associated with two or more broadcast MBS sessions with different MBS session IDs delivering a same MBS content over two or more networks; (eNodeB #3, eNodeB #4 and eNodeB #5 will receive different session start messages for the same multicast or broadcast service (as can be for example identified based on the identical service identifiers in the session start messages) which yield different user plane entities in different pool areas, paragraph 201) and in accordance with a determination that a predefined user plane connection delivering the MBS content associated to a second broadcast MBS session has been established with a network for multicast transport, skipping joining a multicast group for receiving the MBS content from a Multicast/Broadcast User Plane Function (MB-UPF) in the first network which is originated from an application node; (the respective base stations eNodeB #3, eNodeB #4 and eNodeB #5 only need to receive the multicast or broadcast service data once (e.g. via private IP multicast within a pool area), they will individually select one of the two user plane entities and will establish a user plane for the multicast or broadcast service to this selected user plane entity. Accordingly, the respective base stations eNodeB #3, eNodeB #4 and eNodeB #5 will positively acknowledge the session start message yielding the selected user plane entity and will negatively acknowledge the other session start messages, paragraph 201. all base stations eNodeB #3, eNodeB #4 and eNodeB #5 in the overlapping region of Pool Area #1 and Pool Area #2 select M-UPE #1 of Pool Area #1 for providing the user plane for the service. The base stations may further positively acknowledge (ACK) the session start messages that have indicated the selected user plane entity M-UPE #1 (not shown in FIG. 25). All other session start messages are rejected (i.e. negatively acknowledged) by the base stations eNodeB #3, eNodeB #4 and eNodeB #5 by means of NACK messages, Paragraph 209) and/or for unicast transport, skipping allocation of downlink tunnel information for the first broadcast MBS session; wherein the first broadcast MBS session and the second broadcast MBS session are comprised in the two or more broadcast MBS sessions. With respect to claim 3, Becker teaches further comprising: when radio resource has been allocated for broadcasting the MBS content of the application node and shared by the two or more broadcast MBS sessions, skipping allocating the radio resource; and/or when the radio resource has not been allocated for broadcasting the MBS content of the application node and shared by the two or more broadcast MBS sessions, allocating the radio resource. (It is the trigger for resource allocation and establishment in the network, i.e. comprising core network and radio network resources, Paragraph 190) With respect to claim 4, Becker teaches further comprising: advertising the first MBS session ID; and linking the first MBS session ID to the radio resource. (In case the base station receives multiple multicast session start messages, it can determine whether these messages belong to the same service by analyzing the service identifier, e.g. TMGI/IP multicast address of the service, contained in each message, Paragraph 195) With respect to claim 5, Becker teaches further comprising: creating broadcast MBS session context including the associated session ID. (M-MME #10 and M-MME #11 are assumed to have received a service activation for a multicast or broadcast service (e.g. MBMS) from UE#1 and UE#2. Accordingly, the two mobility management entities have established a service context for the terminal (e.g. an MBMS UE context), Paragraph 199) With respect to claim 6, Becker teaches further comprising: receiving an MBS session release request from the core network node in the first network, wherein the MBS session release request comprises the first MBS session ID. (session stop in the point at which there will be no more data sent for the multicast service. It triggers release of previously allocated resources in the network. While the leaving is the process by which a subscriber leaves (stops being a member of) a multicast group, i.e. the user no longer wants to receive a specific multicast service, Paragraph 191) With respect to claim 7, Becker teaches further comprising: in accordance with a determination that the user plane of the first MBS session towards the first network is not established, continuing content delivery of the two or more broadcast MBS sessions, stopping advertisement of the MBS session ID; and for multicast transport, skipping sending a leaving message to an MB-UPF in the first network; and/or for unicast transport, sending an MBS session release response without downlink tunnel information to the core network node in the first network. (eNodeB #3, eNodeB #4 and eNodeB #5 will receive different session start messages for the same multicast or broadcast service (as can be for example identified based on the identical service identifiers in the session start messages) which yield different user plane entities in different pool areas. As the respective base stations eNodeB #3, eNodeB #4 and eNodeB #5 only need to receive the multicast or broadcast service data once (e.g. via private IP multicast within a pool area), they will individually select one of the two user plane entities and will establish a user plane for the multicast or broadcast service to this selected user plane entity), Paragraph 201) With respect to claim 13, Becker teaches further comprising: triggering Broadcast MBS Session Release Require procedure for each associated broadcast MBS session. (Session stop in the point at which there will be no more data sent for the multicast service. It triggers release of previously allocated resources in the network. While the leaving is the process by which a subscriber leaves (stops being a member of) a multicast group, i.e. the user no longer wants to receive a specific multicast service, Paragraph 191) With respect to claim 16, Becker teaches further comprising: determining that the radio access network node cannot receive MBS content from a user plane of a third MBS session towards a third network; and selecting a fourth MBS session of the two or more broadcast MBS sessions to establish a user plane of a fourth MBS session towards a fourth network. (During an ongoing multicast service a mobile terminal that receives the service may be removed from its attached mobility management entity. There are several reasons for this. For example, the mobile terminal stops receiving the multicast service. In this case it typically deactivates the multicast service at the mobility management entity. Another example, may be that the mobile terminal moves to another administrative area (pool area), which implies the transfer of mobile terminal control to another mobility management entity. A further reason might be that the mobile terminal moves out of coverage, runs out of battery or other failure situations occur, which makes the terminal disappear from the network. In any such case, the service context information or even the complete mobile terminal context information (comprising the multicast service context information) is typically removed from the mobility management entity, Paragraph 267) With respect to claim 18, Becker teaches wherein determining that the radio access network node cannot receive MBS content from a user plane of a third MBS session towards a third network comprises: detecting there is a failure in the third network which causes the radio access network node cannot receive MBS content from the user plane of the third MBS session towards the third network; and determining that the radio access network node cannot receive MBS content from the user plane of the third MBS session towards the third network. (Reactively trigger the coordination on specific notification by the base stations, e.g. requesting resolution of conflicting session start messages. For example, upon having received the session start messages from different mobility management entities that yield different user plane entities (as for example shown in FIG. 24) the base stations may respond to the session start messages by a notification that triggers the selection of the common user plane entity. This notification may for example comprise an identification of the (other) mobility management entities a respective base station has received a session start message from for a respective service and/or may (further) indicate the user plane entities that that have been indicated in the session start messages. Upon having selected the common user plane entity in response to the trigger the base stations may either receive updated session start messages from one or more mobility management entities or another signaling message that indicates the common user plane entity for the service), Paragraph 230) With respect to claims 46 and 72, Becker teaches A method performed by a multicast/broadcast session management function (MB-SMF) in a first network, comprising: receiving an MBS session create request from a Network Exposure Function (NEF) or a Multicast/Broadcast Service Function (MBSF) in the first network or an application function (AF), (upon having received a trigger from the a centralized network node providing the multicast or broadcast service, such as the BM-SC, M-MME #10 and M-MME #11 send session start messages to all access nodes in Pool Area #1, i.e. eNodeBs#1 and eNodeB #3, eNodeB #4 and eNodeB #5 in the overlapping pool area region of Pool Area #1 and Pool Area #2, Paragraph 199) wherein the MBS session create request comprises a multicast/broadcast service (MBS) session identifier (ID) and an associated session ID, wherein the associated session ID is associated with two or more broadcast MBS sessions of different MBS session IDs delivering a same content over two or more networks; (eNodeB #3, eNodeB #4 and eNodeB #5 will receive different session start messages for the same multicast or broadcast service (as can be for example identified based on the identical service identifiers in the session start messages) which yield different user plane entities in different pool areas, paragraph 201) and sending an MBS broadcast context create request to an access and mobility management function (AMF) in the first network, wherein the MBS broadcast context create request comprises the MBS session ID and the associated session ID, (upon having received the session start messages from different mobility management entities that yield different user plane entities (as for example shown in FIG. 24) the base stations may respond to the session start messages by a notification that triggers the selection of the common user plane entity. This notification may for example comprise an identification of the (other) mobility management entities a respective base station has received a session start message from for a respective service and/or may (further) indicate the user plane entities that that have been indicated in the session start messages. Upon having selected the common user plane entity in response to the trigger the base stations may either receive updated session start messages from one or more mobility management entities or another signaling message that indicates the common user plane entity for the service, paragraph 230) wherein at least one user plane is expected to be established for the two or more MBS sessions of the two or more networks. (detect at the mobility management entity that a conflicting situation might exist at the base stations, may be based on receiving ACK and NACK messages for the same session start from different base stations. Similar to the reactive option above, this may trigger the common user plane entity selection by mobility management entities and the result of the selection is communicated to the base stations in the overlapping region of the pool areas, so that they all establish the user plane to the same user plane entity, paragraph 231) With respect to claim 47, Becker teaches further comprising: receiving a notify request comprising an ID of a first MBS session and downlink tunnel information from the AMF in the first network; and sending a session modification request to a Multicast/Broadcast User plane Function (MB-UPF) to allocate point-to-point transport tunnel for a replicated MBS stream for the first MBS session; and sending a notify response to the AMF in the first network, wherein the notify response comprises the ID of the first MBS session. (upon having received the session start messages from different mobility management entities that yield different user plane entities (as for example shown in FIG. 24) the base stations may respond to the session start messages by a notification that triggers the selection of the common user plane entity. This notification may for example comprise an identification of the (other) mobility management entities a respective base station has received a session start message from for a respective service and/or may (further) indicate the user plane entities that that have been indicated in the session start messages. Upon having selected the common user plane entity in response to the trigger the base stations may either receive updated session start messages from one or more mobility management entities or another signaling message that indicates the common user plane entity for the service, paragraph 230) With respect to claim 48, Becker teaches wherein the N2 request is a broadcast session transport request and the N2 response is a broadcast session transport response. (upon having received the session start messages from different mobility management entities that yield different user plane entities (as for example shown in FIG. 24) the base stations may respond to the session start messages by a notification that triggers the selection of the common user plane entity. This notification may for example comprise an identification of the (other) mobility management entities a respective base station has received a session start message from for a respective service and/or may (further) indicate the user plane entities that that have been indicated in the session start messages. Upon having selected the common user plane entity in response to the trigger the base stations may either receive updated session start messages from one or more mobility management entities or another signaling message that indicates the common user plane entity for the service, paragraph 230) With respect to claim 49, Becker teaches wherein the notify request is an MBS broadcast context status notify request and the notify response is an MBS broadcast context status notify response. (upon having received the session start messages from different mobility management entities that yield different user plane entities (as for example shown in FIG. 24) the base stations may respond to the session start messages by a notification that triggers the selection of the common user plane entity. This notification may for example comprise an identification of the (other) mobility management entities a respective base station has received a session start message from for a respective service and/or may (further) indicate the user plane entities that that have been indicated in the session start messages. Upon having selected the common user plane entity in response to the trigger the base stations may either receive updated session start messages from one or more mobility management entities or another signaling message that indicates the common user plane entity for the service, paragraph 230) Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Wu et al. (US Publication 2025/0081290) discloses receiving, from an MBS network, an identifier for an MBS session; transmitting, to a RAN, a message including the identifier for the MBS session; transmitting, to the RAN, one or more parameters associated with the MBS session; and transmitting, to the RAN, one or more MBS data packets to be broadcast to a user equipment (UE) in accordance with the one or more parameters . Ling et al. (US Publication 2024/0422022) discloses SMF for detecting a failure and/or restart of a RAN node that serves one or more UEs for a multicast session comprises: receiving, from a network node, a message indicating a failure and/or restart of the RAN node. Any inquiry concerning this communication from the examiner should be directed to ABDULLAHI AHMED whose telephone number is (571) 270-3652. The examiner can normally be reached on M-F 8:00AM-4:30PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Khalid Kassim can be reached on 571-270-3370. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /ABDULLAHI AHMED/Examiner, Art Unit 2475 Application/Control Number: 18/729,545 Page 2 Art Unit: 2475 Application/Control Number: 18/729,545 Page 3 Art Unit: 2475 Application/Control Number: 18/729,545 Page 4 Art Unit: 2475 Application/Control Number: 18/729,545 Page 5 Art Unit: 2475 Application/Control Number: 18/729,545 Page 6 Art Unit: 2475 Application/Control Number: 18/729,545 Page 7 Art Unit: 2475 Application/Control Number: 18/729,545 Page 8 Art Unit: 2475 Application/Control Number: 18/729,545 Page 9 Art Unit: 2475 Application/Control Number: 18/729,545 Page 10 Art Unit: 2475 Application/Control Number: 18/729,545 Page 11 Art Unit: 2475 Application/Control Number: 18/729,545 Page 12 Art Unit: 2475
Prosecution Insights