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 .
This is in response to the Applicant’s arguments filed on June 04, 2026, in which claims 2 and 11 have been amended. Claims 1-20 are currently pending.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1- 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by TD TECH ET AL: "Multicast reception in RRC_INACTIVE state", 3GPP DRAFT; R2-2209458 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. Electronic meeting; 20221010 - 20221019, 27 September 2022 (2022-09-27), XP052262789, [retrieved on 2022-09-27].
Regarding claim 1, TD TECH ET AL teaches a method performed by a user equipment (UE) in a wireless communication system, the method comprising: receiving, from a base station, a radio resource control (RRC) release message (Proposal 1: RRC dedicated signalling is used to make UE switch to RRC_INACTIVE state from RRC_CONNECTED state; page 2) including multicast broadcast services (MBS) configuration information (Proposal 2: RRC dedicated signalling for UE to switch to RRC_INACTIVE state carries the following information to the UE. (1) RRC_INACTIVE state indicator: make UE switch to RRC_INACTIVE state from RRC_CONNECTED state. (2) PTM configuration information of the multicast session received by the UE (optional) (3) QoS information (optional) : target BLER of multicast reception by UE (4) PRACH configuration information (optional) (5) Multicast session configuration informations of neighbour cells (optional) ; pages 2, 3) and multicast control channel (MCCH) configuration information (The MCCH configuration information is sent to UE along with the other configuration information through RRC dedicated signalling after UE joins the multicast session and before UE is switched to RRC_INACTIVE state (for multicast session deactivation or multicast reception in RRC_INACTIVE state) ; page 3), wherein the MBS configuration information includes at least one of a list of neighboring cells ((5) Multicast session configuration informations of neighbour cells (optional) ; pages 2, 3)), a group-radio network temporary identifier (G-RNTI) (Option 2: use dedicated signalling + multicast session specific MCCH For a multicast session provided to RRC_INACTIVE UE, option 2 uses a multicast session specific MCCH to send common signalling of the multicast session with PTM mode. In detail, a MCCH is configured for G-RNTI/G-CS-RNTI where G- RNTI/G-CS-RNTI is used to identify the multicast session over Uu. The MCCH and the MTCHs associated with G-RNTI/G- CS-RNTI are sent on GC-PDSCH which is scrambled with G- RNTI/G-CS-RNTI; page 3), or an MBS session identity (ID) ((1) TMGI of the related multicast session (optional); proposals 4, 5, 7, 9, 11; pages 5-7), and the MCCH configuration information is associated with reception of a MBS multicast in an RRC inactive state (Proposal 15: In order to send the updated PTM configuration information, the following option is suggested: Option 3: Dedicated signalling + multicast session specific MCCH; page 8); and in case that a multicast session that the UE joined is not provided for the RRC inactive state in a current cell, performing an RRC connection resume (Question 6: If RRC_INACTIVE UE can decide by itself to initiate the random access procedure for continuing multicast reception in RRC_CONNECTED state? What conditions can be used by RRC_INACTIVE UE to make such decision? How can RRC_INACTIVE UE initiate the random accession procedure?; page 1; For Question 6, after UE switches to RRC_INACTIVE state, gNB doesn't know if multicast reception by UE satisfies the specific QoS requirement. If the specific Qos information is sent to UE, UE can find if multicast reception satisfies the specific Qos requirement. If UE finds multicast reception can't satisfy the specific QoS requirement, it can by itself initiate the random access procedure for continuing multicast reception in RRC_CONNECTED state; page 7).
Regarding claim 2, TD TECH ET AL teaches the RRC release message further comprises multicast control channel (MCCH) configuration information, wherein the MCCH configuration information includes a modification period and a repetition period, and wherein the method further comprises: receiving, from the base station, a first MCCH message including MBS configuration information, based on the modification period and the repetition period. (i.e., receiving from BS first MCCH message with modification and repetition periods (D1, Section 2, question 2, option 2, page 3)).
Regarding claim 3, TD TECH ET AL teaches in case that the multicast session is deactivated or the MBS configuration information of the first MCCH message is changed, a notification is received from the base station (i.e., notification reception whenever there is a changed or cell reselection (D1, Section 2, question 2, proposal 9; page 6 and question 7, option 3, page 8)).
Regarding claim 4, TD TECH ET AL teaches wherein, in case that the MBS configuration information of the first MCCH message is changed or a cell is reselected, a second MCCH message is received from the base station (i.e., receiving MBS multicast data while in RRC inactive state (D1, Section 2, proposal 2, page 3)).
Regarding claim 5, TD TECH ET AL teaches receiving, from the base station while the UE is in the RRC inactive state, an MBS multicast data based on the MBS configuration information (Section 2, question 2, option 2, page ).
Regarding claim 6, TD TECH ET AL teaches A user equipment (UE) comprising: at least one transceiver (typical feature of UE); at least one processor communicatively coupled to the at least one transceiver (typical feature of UE); and at least one memory, communicatively coupled to the at least one processor (typical feature of UE), storing instructions executable by the at least one processor (typical feature of UE) individually or in any combination to cause the UE to: receive, from a base station, a radio resource control (RRC) release message (Proposal 1: RRC dedicated signalling is used to make UE switch to RRC_INACTIVE state from RRC_CONNECTED state; page 2) including multicast broadcast services (MBS) configuration information (Proposal 2: RRC dedicated signalling for UE to switch to RRC_INACTIVE state carries the following information to the UE. (1) RRC_INACTIVE state indicator: make UE switch to RRC_INACTIVE state from RRC_CONNECTED state. (2) PTM configuration information of the multicast session received by the UE (optional) (3) QoS information (optional) : target BLER of multicast reception by UE (4) PRACH configuration information (optional) (5) Multicast session configuration informations of neighbour cells (optional) ; pages 2, 3) and multicast control channel (MCCH) configuration information (The MCCH configuration information is sent to UE along with the other configuration information through RRC dedicated signalling after UE joins the multicast session and before UE is switched to RRC_INACTIVE state (for multicast session deactivation or multicast reception in RRC_INACTIVE state) ; page 3), wherein the MBS configuration information includes at least one of a list of neighboring cells ((5) Multicast session configuration informations of neighbour cells (optional) ; pages 2, 3)), a group-radio network temporary identifier (G-RNTI) (Option 2: use dedicated signalling + multicast session specific MCCH For a multicast session provided to RRC_INACTIVE UE, option 2 uses a multicast session specific MCCH to send common signalling of the multicast session with PTM mode. In detail, a MCCH is configured for G-RNTI/G-CS-RNTI where G- RNTI/G-CS-RNTI is used to identify the multicast session over Uu. The MCCH and the MTCHs associated with G-RNTI/G- CS-RNTI are sent on GC-PDSCH which is scrambled with G- RNTI/G-CS-RNTI; page 3), or an MBS session identity (ID) ((1) TMGI of the related multicast session (optional); proposals 4, 5, 7, 9, 11; pages 5-7), and the MCCH configuration information is associated with reception of a MBS multicast in an RRC inactive state (Proposal 15: In order to send the updated PTM configuration information, the following option is suggested: Option 3: Dedicated signalling + multicast session specific MCCH; page 8); and in case that a multicast session that the UE joined is not provided for the RRC inactive state in a current cell, performing an RRC connection resume (Question 6: If RRC_INACTIVE UE can decide by itself to initiate the random access procedure for continuing multicast reception in RRC_CONNECTED state? What conditions can be used by RRC_INACTIVE UE to make such decision? How can RRC_INACTIVE UE initiate the random accession procedure?; page 1; For Question 6, after UE switches to RRC_INACTIVE state, gNB doesn't know if multicast reception by UE satisfies the specific QoS requirement. If the specific Qos information is sent to UE, UE can find if multicast reception satisfies the specific Qos requirement. If UE finds multicast reception can't satisfy the specific QoS requirement, it can by itself initiate the random access procedure for continuing multicast reception in RRC_CONNECTED state; page 7).
Regarding claim 7, TD TECH ET AL teaches the RRC release message further comprises multicast control channel (MCCH) configuration information, wherein the MCCH configuration information includes a modification period and a repetition period, and wherein the method further comprises: receiving, from the base station, a first MCCH message including MBS configuration information, based on the modification period and the repetition period. (i.e., receiving from BS first MCCH message with modification and repetition periods (D1, Section 2, question 2, option 2, page 3)).
Regarding claim 8, TD TECH ET AL teaches in case that the multicast session is deactivated or the MBS configuration information of the first MCCH message is changed, a notification is received from the base station (i.e., notification reception whenever there is a changed or cell reselection (D1, Section 2, question 2, proposal 9; page 6 and question 7, option 3, page 8)).
Regarding claim 9, TD TECH ET AL teaches wherein, in case that the MBS configuration information of the first MCCH message is changed or a cell is reselected, a second MCCH message is received from the base station (i.e., receiving MBS multicast data while in RRC inactive state (D1, Section 2, proposal 2, page 3)).
Regarding claim 10, TD TECH ET AL teaches receiving, from the base station while the UE is in the RRC inactive state, an MBS multicast data based on the MBS configuration information (Section 2, question 2, option 2, page 3).
Regarding claim 11, TD TECH ET AL teaches a method performed by a base station in a wireless communication system, the method comprising: transmitting, to a user equipment (UE), a radio resource control (RRC) release message (Proposal 1: RRC dedicated signalling is used to make UE switch to RRC_INACTIVE state from RRC_CONNECTED state; page 2) including multicast broadcast services (MBS) configuration information (Proposal 2: RRC dedicated signalling for UE to switch to RRC_INACTIVE state carries the following information to the UE. (1) RRC_INACTIVE state indicator: make UE switch to RRC_INACTIVE state from RRC_CONNECTED state. (2) PTM configuration information of the multicast session received by the UE (optional) (3) QoS information (optional) : target BLER of multicast reception by UE (4) PRACH configuration information (optional) (5) Multicast session configuration informations of neighbour cells (optional) ; pages 2, 3) and multicast control channel (MCCH) configuration information (The MCCH configuration information is sent to UE along with the other configuration information through RRC dedicated signalling after UE joins the multicast session and before UE is switched to RRC_INACTIVE state (for multicast session deactivation or multicast reception in RRC_INACTIVE state) ; page 3), wherein the MBS configuration information includes at least one of a list of neighboring cells ((5) Multicast session configuration informations of neighbour cells (optional) ; pages 2, 3)), a group-radio network temporary identifier (G-RNTI) (Option 2: use dedicated signalling + multicast session specific MCCH For a multicast session provided to RRC_INACTIVE UE, option 2 uses a multicast session specific MCCH to send common signalling of the multicast session with PTM mode. In detail, a MCCH is configured for G-RNTI/G-CS-RNTI where G- RNTI/G-CS-RNTI is used to identify the multicast session over Uu. The MCCH and the MTCHs associated with G-RNTI/G- CS-RNTI are sent on GC-PDSCH which is scrambled with G- RNTI/G-CS-RNTI; page 3), or an MBS session identity (ID) ((1) TMGI of the related multicast session (optional); proposals 4, 5, 7, 9, 11; pages 5-7), and the MCCH configuration information is associated with reception of a MBS multicast in an RRC inactive state (Proposal 15: In order to send the updated PTM configuration information, the following option is suggested: Option 3: Dedicated signalling + multicast session specific MCCH; page 8); and in case that a multicast session that the UE joined is not provided for the RRC inactive state in a current cell, performing an RRC connection resume (Question 6: If RRC_INACTIVE UE can decide by itself to initiate the random access procedure for continuing multicast reception in RRC_CONNECTED state? What conditions can be used by RRC_INACTIVE UE to make such decision? How can RRC_INACTIVE UE initiate the random accession procedure?; page 1; For Question 6, after UE switches to RRC_INACTIVE state, gNB doesn't know if multicast reception by UE satisfies the specific QoS requirement. If the specific Qos information is sent to UE, UE can find if multicast reception satisfies the specific Qos requirement. If UE finds multicast reception can't satisfy the specific QoS requirement, it can by itself initiate the random access procedure for continuing multicast reception in RRC_CONNECTED state; page 7).
Regarding claim 12, TD TECH ET AL teaches wherein the RRC release message further comprises multicast control channel (MCCH) configuration information, wherein the MCCH configuration information includes a modification period and a repetition period, and wherein the method further comprises: transmitting, to the UE, a first MCCH message including MBS configuration information, based on the modification period and the repetition period (i.e., receiving from BS first MCCH message with modification and repetition periods (Section 2, question 2, option 2, page 3)).
Regarding claim 13, TD TECH ET AL teaches wherein, in case that the multicast session is deactivated or the MBS configuration information of the first MCCH message is changed, a notification is transmitted to the UE (i.e., notification reception whenever there is a changed or cell reselection (Section 2, question 2 can be used to inform UE of multicast session deactivation, proposal 9; page 6 and question 7, option 3, page 8)).
Regarding claim 14, TD TECH ET AL teaches in case that the MBS configuration information of the first MCCH message is changed or a cell is reselected, a second MCCH message is transmitted to the UE (i.e., receiving MBS multicast data while in RRC inactive state (D1, Section 2, proposal 2, page 3)).
Regarding claim 15, TD TECH ET AL teaches transmitting, to the UE in the RRC inactive state, an MBS multicast data based on the MBS configuration information (Section 2, question 2, option 2, page 3).
Regarding claim 16, TD TECH ET AL teaches a base station comprising: at least one transceiver (typical feature of base station); at least one processor communicatively coupled to the at least one transceiver (typical feature of base station); and at least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination, cause the base station to: transmit, to a user equipment (UE), a radio resource control (RRC) release message (Proposal 1: RRC dedicated signalling is used to make UE switch to RRC_INACTIVE state from RRC_CONNECTED state; page 2) including multicast broadcast services (MBS) configuration information (Proposal 2: RRC dedicated signalling for UE to switch to RRC_INACTIVE state carries the following information to the UE. (1) RRC_INACTIVE state indicator: make UE switch to RRC_INACTIVE state from RRC_CONNECTED state. (2) PTM configuration information of the multicast session received by the UE (optional) (3) QoS information (optional) : target BLER of multicast reception by UE (4) PRACH configuration information (optional) (5) Multicast session configuration informations of neighbour cells (optional) ; pages 2, 3) and multicast control channel (MCCH) configuration information (The MCCH configuration information is sent to UE along with the other configuration information through RRC dedicated signalling after UE joins the multicast session and before UE is switched to RRC_INACTIVE state (for multicast session deactivation or multicast reception in RRC_INACTIVE state) ; page 3), wherein the MBS configuration information includes at least one of a list of neighboring cells ((5) Multicast session configuration informations of neighbour cells (optional) ; pages 2, 3)), a group-radio network temporary identifier (G-RNTI) (Option 2: use dedicated signalling + multicast session specific MCCH For a multicast session provided to RRC_INACTIVE UE, option 2 uses a multicast session specific MCCH to send common signalling of the multicast session with PTM mode. In detail, a MCCH is configured for G-RNTI/G-CS-RNTI where G- RNTI/G-CS-RNTI is used to identify the multicast session over Uu. The MCCH and the MTCHs associated with G-RNTI/G- CS-RNTI are sent on GC-PDSCH which is scrambled with G- RNTI/G-CS-RNTI; page 3), or an MBS session identity (ID) ((1) TMGI of the related multicast session (optional); proposals 4, 5, 7, 9, 11; pages 5-7), and the MCCH configuration information is associated with reception of a MBS multicast in an RRC inactive state (Proposal 15: In order to send the updated PTM configuration information, the following option is suggested: Option 3: Dedicated signalling + multicast session specific MCCH; page 8); and in case that a multicast session that the UE joined is not provided for the RRC inactive state in a current cell, performing an RRC connection resume (Question 6: If RRC_INACTIVE UE can decide by itself to initiate the random access procedure for continuing multicast reception in RRC_CONNECTED state? What conditions can be used by RRC_INACTIVE UE to make such decision? How can RRC_INACTIVE UE initiate the random accession procedure?; page 1; For Question 6, after UE switches to RRC_INACTIVE state, gNB doesn't know if multicast reception by UE satisfies the specific QoS requirement. If the specific Qos information is sent to UE, UE can find if multicast reception satisfies the specific Qos requirement. If UE finds multicast reception can't satisfy the specific QoS requirement, it can by itself initiate the random access procedure for continuing multicast reception in RRC_CONNECTED state; page 7).
Regarding claim 17, TD TECH ET AL teaches wherein the RRC release message further comprises multicast control channel (MCCH) configuration information, wherein the MCCH configuration information includes a modification period and a repetition period, and wherein the method further comprises: transmitting, to the UE, a first MCCH message including MBS configuration information, based on the modification period and the repetition period (i.e., receiving from BS first MCCH message with modification and repetition periods (Section 2, question 2, option 2, page 3)).
Regarding claim 18, TD TECH ET AL teaches wherein, in case that the multicast session is deactivated or the MBS configuration information of the first MCCH message is changed, a notification is transmitted to the UE (i.e., notification reception whenever there is a changed or cell reselection (Section 2, question 2 can be used to inform UE of multicast session deactivation, proposal 9; page 6 and question 7, option 3, page 8)).
Regarding claim 19, TD TECH ET AL teaches in case that the MBS configuration information of the first MCCH message is changed or a cell is reselected, a second MCCH message is transmitted to the UE (i.e., receiving MBS multicast data while in RRC inactive state (D1, Section 2, proposal 2, page 3)).
Regarding claim 20, TD TECH ET AL teaches transmitting, to the UE in the RRC inactive state, an MBS multicast data based on the MBS configuration information (Section 2, question 2, option 2, page 3).
Response to Arguments
Applicant’s arguments with respect to claims 1-20 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wang et al. (US 2024/0365177) teaches [0102] In some optional implementations, the network side configures the updated MBS configuration information through an RRC release message, and the terminal device obtains the target MBS configuration information through the RRC release message.
[0104] For any of the above solutions, the operation that the terminal device obtains the target MBS configuration information through the RRC recovery process or the RRC release message includes the following operations. The terminal device sends an RRC recovery request message to a first base station, and the first base station is a base station corresponding to the target cell. The terminal device receives the RRC release message from the first base station, and the RRC release message carries the updated MBS configuration information. The terminal device determines the updated MBS configuration information as the target MBS configuration information. [0124]-[0125] the RRC release message further carries a first list of neighbor cells in which an MBS exists. If the terminal device determines that the MBS does not exist in a neighbor cell of cell reselection based on the first list of neighbor cells.
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 JEAN ALLAND GELIN whose telephone number is (571)272-7842. The examiner can normally be reached MON-FR 9-6 PM.
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, JINSONG HU can be reached at 571-272-3965. 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.
/JEAN A GELIN/Primary Examiner, Art Unit 2643
Prosecution Insights