DETAILED ACTION
In response to communications filed 06/12/2026.
Claims 1-5, 7-14 and 16-21 are pending for examination.
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 .
Claim Rejections - 35 USC § 102
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5, 7-14 and 16-21 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Babaei (US 2024/0260134 A1) hereinafter “Babaei.”
Regarding Claim 1, Babaei teaches A method in a core network (CN) (Babaei: paragraph 0037 & Fig. 1, core network (5GC)) for managing multicast and/or broadcast services (MBS) (Babaei: paragraphs 0004-0005 & 0187, multicast broadcast services; see also paragraph 0193, MBS radio bearer for signaling of MBS configuration information) with a radio access network (RAN) (Babaei: paragraph 0037 & Fig. 1, NG-RAN), the method comprising:
receiving, from an MBS network (Babaei: paragraph 0209 & Fig. 18, MBS server; see also paragraph 0193), an interface message associated with an MBS session identifier (Babaei: paragraphs 0198, 0212-0213, MBS notification signaling indicates a start time, an activation time, or changes in MBS configuration); and
in response to the receiving, performing one of:
in a first instance, when the interface message requests activation for a multicast session (Babaei: paragraphs 0187 & 0190, a first MBS configuration used for multicast session), transmitting to the RAN, a first CN-to-BS message (Babaei: paragraph 0198, MBS notification sent by the core to the RAN) to request activation notification for a multicast session corresponding to the MBS session identifier (Babaei: paragraph 0187, MBS delivery mode 1 used for multicast sessions (based on MBS configuration)), and
in a second instance, when the interface message requests resources for a broadcast session (Babaei: paragraphs 0187 & 0190, a second MBS configuration used for broadcast session), transmitting, to the RAN, a second CN-to-BS message (Babaei: paragraph 0198, MBS notification sent by the core to the RAN) to request resources for a broadcast session corresponding to the MBS session identifier (Babaei: paragraph 0187, MBS delivery mode 2 used for broadcast sessions (based on MBS configuration)).
Regarding Claim 2, Babaei teaches the respective claim(s) as presented above and further teaches wherein the first CN-to-BS message a new next generation application protocol (NGAP) message defined specifically for a purpose of notifying the UEs of the MBS session activation (Babaei: paragraph 0041, implementing NGAP for transmitting or signaling messages).
Regarding Claim 3, Babaei teaches the respective claim(s) as presented above and further teaches wherein the second CN-to-BS message is an NGAP message (Babaei: paragraph 0041, implementing NGAP for transmitting or signaling messages).
Regarding Claim 4, Babaei teaches the respective claim(s) as presented above and further teaches wherein the second CN-to-BS message includes a QoS profile (Babaei: paragraph 0187, information of the MBS services including QoS requirements of an MBS service provided to RAN).
Regarding Claim 5, Babaei teaches the respective claim(s) as presented above and further teaches wherein the MBS session identifier includes a Temporary Mobile Group Identity (TMGI) (Babaei: paragraph 0187, information of the MBS services including TMGI provided to RAN).
Regarding Claim 7, Babaei teaches A method in a radio access network (RAN) node (Babaei: paragraph 0037 & Fig. 1, NG-RAN) for managing MBS (Babaei: paragraphs 0004-0005 & 0187, multicast broadcast services), the method comprising:
receiving, from a CN (Babaei: paragraph 0037 & Fig. 1, core network (5GC)), a CN-to-BS message (Babaei: paragraph 0198, MBS notification sent by the core to the RAN) including an MBS session identifier (Babaei: paragraphs 0198, 0212-0213, MBS notification signaling indicates a start time, an activation time, or changes in MBS configuration);
determining whether the CN-to-BS message requests resources for a multicast session corresponding to the MBS session identifier (Babaei: paragraphs 0187 & 0190, a first MBS configuration used for multicast session) or a broadcast session corresponding to the MBS session identifier (Babaei: paragraph 0187, MBS delivery mode 2 used for broadcast sessions (based on MBS configuration);
in a first instance, when the CN-to-BS message requests resources for a multicast session corresponding to the MBS session identifier (Babaei: paragraph 0187, MBS delivery mode 1 used for multicast sessions), performing one or more procedures to transition a plurality of user equipment units (UEs) (Babaei: paragraphs 0197-0198, number of UEs in the MBS group) to a connected state (Babaei: paragraphs 0205 & 216, transitioning from a radio resource control (RRC) inactive state or RRC idle state to an RRC connected state in response to reception of the MBS related notification); and
in a second instance, when the CN-to-BS message requests resources for a broadcast session corresponding to the MBS session identifier, broadcasting MBS resource configuration to the plurality of UEs (Babaei: paragraph 0187, MBS delivery mode 2 used for broadcast sessions), including refraining from transitioning the plurality of UEs to the connected state (Babaei: paragraph 0187, delivery mode 2 where the UE may also receive data in INACTIVE/IDLE state, therefore teaching no transition to a connected state).
Regarding Claim 8, Babaei teaches the respective claim(s) as presented above and further teaches wherein the broadcasting the MBS resource configuration includes using a multicast control channel (MCCH) (Babaei: paragraph 0190, MCCH may be used for the MBS delivery).
Regarding Claim 9, Babaei teaches the respective claim(s) as presented above and further teaches when the CN-to-BS message requests transmission of an MBS activation notification message for the broadcast session (Babaei: paragraph 0187, said delivery for MBS session):
transmitting MBS data associated with the MBS session to the plurality of UEs, using the MCCH (Babaei: paragraph 0190, MCCH change notification mechanism may be used to notify the changes of MCCH configuration due to session start for delivery mode 2 of NR MBS).
Regarding Claim 10, Babaei teaches the respective claim(s) as presented above and further teaches wherein the MBS session identifier includes a Temporary Mobile Group Identity (TMGI) (Babaei: paragraph 0187, information of the MBS services including TMGI provided to RAN).
Regarding Claim 11, Babaei teaches the respective claim(s) as presented above and further teaches wherein CN-to-BS message includes a QoS profile (Babaei: paragraph 0187, information of the MBS services including QoS requirements of an MBS service provided to RAN).
Regarding Claim 12, Babaei teaches the respective claim(s) as presented above and further teaches wherein:
the CN-to-BS message requesting activation notification for the multicast session is a first NGAP CN-to-BS message (Babaei: paragraph 0041, implementing NGAP for transmitting or signaling messages), and
the CN-to-BS message requesting activation notification for the broadcast session is a second NGAP CN-to-BS message (Babaei: paragraph 0041, implementing NGAP for transmitting or signaling messages).
Regarding Claim 13, Babaei teaches the respective claim(s) as presented above and further teaches wherein:
the CN-to-BS message requesting activation notification for the broadcast session is a resource setup request message (Babaei: paragraph 0198, MBS notification or paging message to start or activate session).
Regarding Claim 14, Babaei teaches A radio access network (RAN) node (Babaei: paragraph 0037 & Fig. 1, NG-RAN) comprising one or more processors (Babaei: paragraph 0106 & Fig. 15, processor) and configured to:
receive, from a CN (Babaei: paragraph 0037 & Fig. 1, core network (5GC)), a CN-to-BS message (Babaei: paragraph 0198, MBS notification sent by the core to the RAN) including a multicast and/or broadcast services (MBS) session identifier (Babaei: paragraph 0198, session start/end or MBS configuration change);
determine whether the CN-to-BS message requests resources for a multicast session corresponding to the MBS session identifier (Babaei: paragraphs 0187 & 0190, a first MBS configuration used for multicast session) or a broadcast session corresponding to the MBS session identifier (Babaei: paragraph 0187, MBS delivery mode 2 used for broadcast sessions (based on MBS configuration);
in a first instance, when the CN-to-BS message requests resources for a multicast session corresponding to the MBS session identifier (Babaei: paragraph 0187, MBS delivery mode 1 used for multicast sessions), performing one or more procedures to transition a plurality of user equipment units (UEs) to a connected state (Babaei: paragraphs 0205 & 216, transitioning from a radio resource control (RRC) inactive state or RRC idle state to an RRC connected state in response to reception of the MBS related notification); and
in a second instance, when the CN-to-BS message requests resources for a broadcast session corresponding to the MBS session identifier, broadcasting MBS resource configuration to the plurality of UEs (Babaei: paragraph 0187, MBS delivery mode 2 used for broadcast sessions), including refraining from transitioning the plurality of UEs to the connected state (Babaei: paragraph 0187, delivery mode 2 where the UE may also receive data in INACTIVE/IDLE state, therefore teaching no transitioning to a connected state).
Regarding Claim 16, Babaei teaches the respective claim(s) as presented above and further teaches wherein the broadcasting the MBS resource configuration includes using a multicast control channel (MCCH) (Babaei: paragraph 0190, MCCH may be used for the MBS delivery).
Regarding Claim 17, Babaei teaches the respective claim(s) as presented above and further teaches when the CN-to-BS message requests transmission of an MBS activation notification message for the broadcast session (Babaei: paragraph 0187, said delivery for MBS session):
transmit MBS data associated with the MBS session to the plurality of UEs, using the MCCH (Babaei: paragraph 0190, MCCH change notification mechanism may be used to notify the changes of MCCH configuration due to session start for delivery mode 2 of NR MBS).
Regarding Claim 18, Babaei teaches the respective claim(s) as presented above and further teaches the MBS session identifier includes a Temporary Mobile Group Identity (TMGI) (Babaei: paragraph 0187, information of the MBS services including TMGI provided to RAN).
Regarding Claim 19, Babaei teaches the respective claim(s) as presented above and further teaches wherein CN-to-BS message includes a QoS profile (Babaei: paragraph 0187, information of the MBS services including QoS requirements of an MBS service provided to RAN).
Regarding Claim 20, Babaei teaches the respective claim(s) as presented above and further teaches wherein:
the CN-to-BS message requesting transmission of an MBS activation notification message for the multicast session is a first NGAP CN-to-BS message, (Babaei: paragraph 0041, implementing NGAP for transmitting or signaling messages), and
the CN-to-BS message requesting activation notification for the broadcast session is a second NGAP CN-to-BS message (Babaei: paragraph 0041, implementing NGAP for transmitting or signaling messages).
Regarding Claim 21, Babaei teaches the respective claim(s) as presented above and further teaches wherein:
the CN-to-BS message requesting transmission of an MBS activation notification message for the broadcast session is a resource setup request message (Babaei: paragraph 0198, MBS notification or paging message to start or activate session).
Response to Arguments
Applicant arguments:
Babaei fails to teach or suggest the core network receiving an interface message associated with an MBS session identifier (remarks, page 6 paragraph 4).
Babaei fails to or suggest activation of a multicast session and/or resources for a broadcast session and instead merely teaches a UE using different delivery modes (i.e. delivery mode for 1 for a multicast session and delivery mode 2 for a broadcast session).
Examiner's response:
Applicant's arguments filed 06/12/2026 have been fully considered but they are not persuasive.
Regarding argument a), as previously presented, Babaei teaches MBS notification signaling indicates a start time, an activation time, or changes in MBS configuration for an MBS session (Babaei: paragraphs 0212-0213). Babaei further teaches an MBS radio bearer is used to handle the transport of the MBS notification signaling and/or configuration information (Babaei: paragraph 0193). Examiner notes since the signaling to provide configurations for an MBS session is initiated at the MBS radio bearer, Babaei inherently teaches a logical channel or connection to an MBS network or the MBS server of the MBS network for initiating the signaling to provide said configurations for an MBS session for a user equipment. Therefore, Babaei similarly teaches the core network transmitting either a first or second CN-to-BS message to the RAN based on MBS configurations obtained from the MBS server and/or network.
Regarding argument b), after review of the prior art, Babaei teaches the core network or the radio access network may initiate a paging message for a UE to session start/end or change the MBS configuration (Babaei: paragraphs 0198, 0214 & Fig. 16). Babaei additionally teaches a first MBS configuration (MBS configuration 1 or delivery mode 1) used only for multicast session and second MBS configuration (MBS configuration 2 or delivery mode 2) used for broadcast (Babaei: paragraphs 0187 & 0190). Examiner notes since the messages are used to indicate which MBS configurations are used for the MBS session between the user equipment and network, Babaei similarly teaches activation of a multicast session or and/or resources for a broadcast session based on which MBS delivery mode is indicated and transmitted by the RAN.
Therefore, the rejection of claims 1, 7 and 14 and respective dependent claims is maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lu et al. (US 2025/0338090 A1) teaches an MBS session activation procedure (paragraph 0020).
Babaei (US 2025/0203623 A1) teaches group notification and confirmation for multicast broadcast services (paragraph 0004).
Kim et al. (US 2023/0379942 A1) teaches NG-RAN node performs communication related to a multicast (paragraph 0010).
Zhu et al. (US 2023/0188948 A1) teaches methods for managing multicast and broadcast services (paragraph 0004).
THIS ACTION IS MADE FINAL. 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 NAJEEB ANSARI whose telephone number is (571)270-5446. The examiner can normally be reached Monday-Friday 10am to 2pm.
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, ASAD NAWAZ can be reached at (571) 272-3988. 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.
/NAJEEB ANSARI/Examiner, Art Unit 2463
/ASAD M NAWAZ/Supervisory Patent Examiner, Art Unit 2463
Prosecution Insights