DETAILED ACTION
The action is responsive to claims filed on 04/27/2026. Claims 1-20 are pending for evaluation.
Note: The claims are presented with independent claims listed first in numerical order, followed by dependent claims also in numerical order; any dual or mirror claims are grouped with the lowest-numbered claim in their respective pairing.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/27/2026 has been entered.
Response to Amendment
The Amendment filed on 04/27/2026 has been entered. Claims 1, 8, 9, 12, 18, and 20 have been amended; Claims 1-20 remain pending for evaluation.
Allowable Subject Matter
Claims 8-17 and 20 are allowed.
The following is a statement of reasons for the indication of allowable subject matter:
Independent Claim 8 is allowable because the prior art of record does not teach or suggest the complete limitation that the “multicast service status comprises the number, types and names of multicast services in which the user terminal participates.”
Kadiri (US 20210068003, previously presented) Fig. 5 and Para. [0147-0150] teaches the limitations preceding the wherein clause by disclosing a core-network function transmitting, based on multicast-service-related status corresponding to a UE, assistance information to an access-network device for controlling the UE’s connection state. Thus, the transmission of the first assistance information based on a multicast service status corresponding to the user terminal is not the basis for allowance.
The remaining issue is whether the prior art teaches the complete multicast service status recited in the wherein clause. Kadiri Fig. 5 and Para. [0147] teaches the types of multicast services through its disclosure of QoS flow type. Mikaeil (US 20260089467) Fig. 6 and Para. [0202] teaches the names of multicast services through its disclosure of TMGIs, MBS context identifiers, and service identifiers.
However, the prior art does not teach the multicast service status comprising the number of multicast services in which the particular user terminal participates. Chou (US 20230403537) Figs. 6A-6D and Para. [0129] discusses a number of MBS services concurrently received by a UE, but that number is determined and used by the base station in DCI signaling to the UE, rather than being included in multicast service status transmitted by a core-network function to the access-network device. Dao (US 20180192289) Fig. 7 and Para. [0064] teaches that a core-network MBMS membership function manages UE subscription data identifying the services to which the UE subscribes; however, Dao does not teach communicating that membership information to the RAN or otherwise including it in assistance information transmitted to the access network device.
Accordingly, the cited references, individually or in combination, do not teach or suggest the complete limitation of “wherein the multicast service status comprises: the number, types, and names of multicast services in which the user terminal participates” in independent Claim 8.
Thus, at least independent Claim 8 is allowed over the prior art of record. Dependent Claims 9-17 and 20 are likewise allowed for at least the same reasons because they depend on Claim 8. Therefore, Claims 8-17 and 20 are allowed.
Response to Arguments
Applicant's arguments filed 04/27/2026 with respect to Claims 1, 2, 18, and 19 have been fully considered but they are not persuasive.
In response to Applicant’s argument on pg. 8-9 of Applicant Remarks that, in substance, Babaei fails to teach or suggest at least "when no data is received or transmitted through a connection specific to a user terminal, determining a Radio Resource Control (RRC) state of the user terminal and causing the user terminal to remain in the RRC state based on at least one of the following: that the user terminal participates in a multicast service or the multicast service in which the user terminal participates; whether data is received or transmitted for a multicast service in which the user terminal participates; or first assistance information transmitted by a first core network function, wherein the first assistance information is used to control the RRC state of the user terminal," as recited in independent Claim 1, Examiner respectfully disagrees.
During patent examination, the pending claims must be "given their broadest reasonable interpretation consistent with the specification." The Federal Circuit’s en banc decision in Phillips v. AWH Corp., 415 F.3d 1303, 1316, 75 USPQ2d 1321, 1329 (Fed. Cir. 2005) expressly recognized that the USPTO employs the "broadest reasonable interpretation" standard:
The Patent and Trademark Office ("PTO") determines the scope of claims in patent applications not solely on the basis of the claim language, but upon giving claims their broadest reasonable construction "in light of the specification as it would be interpreted by one of ordinary skill in the art." In re Am. Acad. of Sci. Tech. Ctr., 367 F.3d 1359, 1364[, 70 USPQ2d 1827, 1830] (Fed. Cir. 2004). Indeed, the rules of the PTO require that application claims must "conform to the invention as set forth in the remainder of the specification and the terms and phrases used in the claims must find clear support or antecedent basis in the description so that the meaning of the terms in the claims may be ascertainable by reference to the description." 37 CFR 1.75(d)(1). See MPEP §2111.
See also In re Suitco Surface, Inc., 603 F.3d 1255, 1259, 94 USPQ2d 1640, 1643 (Fed. Cir. 2010); In re Hyatt, 211 F.3d 1367, 1372, 54 USPQ2d 1664, 1667 (Fed. Cir. 2000).
Babaei Fig. 19, Para. [0150-0157] teach a service continuity procedure performed while the UE operates in an RRC Idle or RRC Inactive state. Para. [0150] establishes the UE’s RRC Idle/Inactive state, while Para. [0152-0154] teach that the UE initiates a request for MBS configuration parameters associated with one or more MBS services to maintain service continuity. The gNB processes the request in view of the UE’s RRC Idle/Inactive state and the applicable multicast service continuity requirements. Thus, Babaei teaches determining the RRC state of the user terminal while the UE is not utilizing an active connection specific to the user terminal.
Babaei Fig. 19 and Para. [0156] further teaches that the gNB responds with an RRC Reject message indicating that the UE is to remain in the RRC Inactive/Idle state while providing the MBS configuration parameters and information necessary for the continued MBS reception. The gNB’s determination of the UE’s RRC state is evidenced by its transmission of an RRC Reject expressly indicating that the UE is to remain in the RRC Inactive/Idle state while continuing the requested MBS service. Accordingly, Babaei teaches causing the user terminal to remain in the RRC state. Further, Fig. 19, Para. [0152-0156] teach that the service continuity procedure is performed for one or more MBS services and that the UE remains in the RRC Idle/Inactive state while continuing the requested MBS service. Thus, Babaei teaches causing the user terminal to remain in the RRC state based on at least one of the recited multicast-related conditions, including that the user terminal participates in a multicast service, the multicast service in which the user terminal participates, and whether data is received for the multicast service in which the user terminal participates.
In conclusion, Babaei teaches "when no data is received or transmitted through a connection specific to a user terminal, determining a Radio Resource Control (RRC) state of the user terminal and causing the user terminal to remain in the RRC state based on at least one of the following: that the user terminal participates in a multicast service or the multicast service in which the user terminal participates; whether data is received or transmitted for a multicast service in which the user terminal participates; or first assistance information transmitted by a first core network function, wherein the first assistance information is used to control the RRC state of the user terminal," as recited in independent Claim 1. Accordingly, Babaei anticipates the claimed subject matter, and the rejection under 35 U.S.C. §102(a)(2) is upheld.
Applicant’s arguments, see pg. 10-11 presented with respect to Claim(s) 3-7 are substantively the same as those set forth for Claims 1, 2, 18, and 19. Accordingly, the same reasoning and supporting explanation provided for Claims 1, 2, 18, and 19 are equally applicable to Claims 3-7.
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 (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 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.
Claim(s) 1, 2, 18, and 19 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Babaei (US 2023/0370905, previously presented).
Regarding Claim 1, Babaei teaches a communication indication method, performed by an access network device, comprising (Fig. 19, Para. [0150-0157]; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]):
when no data is received or transmitted through a connection specific to a user terminal, determining a Radio Resource Control (RRC) state of the user terminal (FIG. 19, Para. [0150-0157] - [0154] A group of pre-configured/configured random access preambles may be associated with the MBS services/sessions. The UE may transmit a first message, based on the random access process, indicating a request for MBS configuration parameters associated with the one or more MBS service via the target cell. For example, the UE may transmit the first message based on a Msg3 in a 4-step random access process or a MsgA in a 2-step random access process. The first message may comprise one or more service identifier (e.g., temporary mobile group identifier (TMGIs)) indicating MBS services that the UE is receiving from a currently camped on cell or the MBS services that the UE is interested in receiving from the target cell (e.g., MBS services for which service continuity is requested). In some examples, a Quality of Service (QoS) associated with an MBS service/session (e.g., an MBS bearer) may indicate whether the MBS service/session requires service continuity (for example, service continuity in idle and/or inactive state) and the UE and/or the gNB may consider the QoS requirements of the MBS bearer in transmission of the first message or admission control by the target cell. The first message may comprise one or more fields, one or more values of the one or more fields associated with the determined service continuity trigger and/or the need for service continuity for the one or more MBS services. For example, the one or more fields may comprise a cause field indicating a cause for transmission of the first message. For example, the first message may be transmitted in other procedures and/or for other reasons and the value of the cause field may indicate the cause for transmission of the first message. For example, in case of the UE being in an RRC inactive state, the first message may be an RRC resume request message with the value of the cause field (e.g., a resume cause field) indicating the cause for transmission of the first message is for service continuity associated with the one or more MBS services. The value of the cause field may indicate that the cause for transmission of the first message is for service continuity associated with the one or more MBS services while remaining in the RRC inactive state; Fig. 18; Para. [0148] - Example options for MBS service continuity in RRC Inactive state or RRC Idle state is shown in FIG. 18. In some example, once the UE determines that its MBS service continuity needs attention by the RAN it may initiate a procedure which may or may not require UE to return to connected state. In some examples (e.g., option a in FIG. 18), for a UE in RRC Inactive/Idle state, based on observing the MBS SC triggers, the UE may return to RRC Connected State and may use connected state mobility procedures for MBS HO to target cell. In some examples (e.g., option b in FIG. 18), a UE in RRC inactive state, based on observing the MBS SC triggers, may send an update to RAN, e.g. based on RAN Notification Area (RNA) update RNA Update in RRCResumeRequest or other procedures to indicate their transition to a target cell without leaving the RRC inactive state. In some examples, this process may allow such UE's MBS context as part of UE's RAN context to be shared with target cell without UE returning to connected state. If the MBS configuration, e.g. BWP, Subframes, slot duration/format, etc., are different in the target cell, such information may be included in the RRC signaling back to UE, e.g. as part of Suspend Indication message. In some examples (e.g., option c in FIG. 18), a UE in RRC Inactive or RRC Idle state, based on observing the MBS SC triggers, may send an update using a RACH based signaling and may indicate network about UE's leaving a source cell toward a target and the MBS services the UE is receiving. Such signaling may reuse Message A of 2-step RACH or message 3 of 4 step RACH procedure. Similar to option b, based on receiving this RACH signal, the RAN may send an RRC message to the UE, e.g. message B in 2-step RACH process or message 4 in a 4-step RACH process, including information needed by UE to determine the MBS services in target cell. The 2-step RACH procedure may be more efficient to reduce signaling, where message A from UE may include some identifier for the UE and target MBS services and message B from RAN may include MBS configuration for UE's selected services in the target cell; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]):
and causing the user terminal to remain in the RRC state based on at least one of the following (FIG. 19, Para. [0150-0157] - [0156] The UE may receive the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell as part of an RRC reject message indicating remaining in the RRC inactive/idle state. For example, the RRC reject message may comprise a suspend config information element indicating remaining/transitioning in the RRC inactive state and comprising MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may indicate and/or may comprise service identifiers (e.g., TMGIs, etc.) of one or more MBS services provided by the target cell and/or may indicate one or more MBS services that are admitted by the target cell. The admitted MBS services may be a subset of the MBS services indicated/requested by the first message. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may comprise first configuration parameters for receiving control information (e.g., via an MCCH) for receiving the MBS data from the target cell. The first configuration parameters may comprise scheduling information (e.g., periodicity of control information transmission by the target cell, etc.) for receiving the control information. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may comprise a BWP identifier of the target cell for receiving the control information and/or data for the MBS services, a numerology associated with the MBS services (e.g., a numerology for MBS data/control reception), a control resource set (CORESET) for receiving scheduling information for MBS data/control, etc.; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]):
that the user terminal participates in a multicast service (Fig. 19; Para. [0150-0157] – [0152] The UE may determine a service continuity trigger (e.g., a need for a new need cell (re)selection) for one or more MBS services/sessions based on the measurement configuration parameters. For example, the service continuity trigger may indicate a need for handover to a target cell at least for the one or more MBS services/sessions… In some example, the service continuity triggers may be independent of UE's ongoing services/sessions and may be UE-specific and not service/session-specific…[0156] The UE may receive the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell as part of an RRC reject message indicating remaining in the RRC inactive/idle state. For example, the RRC reject message may comprise a suspend config information element indicating remaining/transitioning in the RRC inactive state and comprising MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may indicate and/or may comprise service identifiers (e.g., TMGIs, etc.) of one or more MBS services provided by the target cell and/or may indicate one or more MBS services that are admitted by the target cell. The admitted MBS services may be a subset of the MBS services indicated/requested by the first message. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may comprise first configuration parameters for receiving control information (e.g., via an MCCH) for receiving the MBS data from the target cell. The first configuration parameters may comprise scheduling information (e.g., periodicity of control information transmission by the target cell, etc.) for receiving the control information. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may comprise a BWP identifier of the target cell for receiving the control information and/or data for the MBS services, a numerology associated with the MBS services (e.g., a numerology for MBS data/control reception), a control resource set (CORESET) for receiving scheduling information for MBS data/control, etc.; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272])
or the multicast service in which the user terminal participates (Fig. 19; Para. [0150-0157] – [0152] The UE may determine a service continuity trigger (e.g., a need for a new need cell (re)selection) for one or more MBS services/sessions based on the measurement configuration parameters. For example, the service continuity trigger may indicate a need for handover to a target cell at least for the one or more MBS services/sessions… In some example, the service continuity triggers may be independent of UE's ongoing services/sessions and may be UE-specific and not service/session-specific…[0156] The UE may receive the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell as part of an RRC reject message indicating remaining in the RRC inactive/idle state. For example, the RRC reject message may comprise a suspend config information element indicating remaining/transitioning in the RRC inactive state and comprising MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may indicate and/or may comprise service identifiers (e.g., TMGIs, etc.) of one or more MBS services provided by the target cell and/or may indicate one or more MBS services that are admitted by the target cell. The admitted MBS services may be a subset of the MBS services indicated/requested by the first message. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may comprise first configuration parameters for receiving control information (e.g., via an MCCH) for receiving the MBS data from the target cell. The first configuration parameters may comprise scheduling information (e.g., periodicity of control information transmission by the target cell, etc.) for receiving the control information. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may comprise a BWP identifier of the target cell for receiving the control information and/or data for the MBS services, a numerology associated with the MBS services (e.g., a numerology for MBS data/control reception), a control resource set (CORESET) for receiving scheduling information for MBS data/control, etc.; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272])
whether data is received or transmitted for a multicast service in which the user terminal participates (Fig. 19; Para. [0150-0157] – [0152] The UE may determine a service continuity trigger (e.g., a need for a new need cell (re)selection) for one or more MBS services/sessions based on the measurement configuration parameters. For example, the service continuity trigger may indicate a need for handover to a target cell at least for the one or more MBS services/sessions… In some example, the service continuity triggers may be independent of UE's ongoing services/sessions and may be UE-specific and not service/session-specific…[0156] The UE may receive the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell as part of an RRC reject message indicating remaining in the RRC inactive/idle state. For example, the RRC reject message may comprise a suspend config information element indicating remaining/transitioning in the RRC inactive state and comprising MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may indicate and/or may comprise service identifiers (e.g., TMGIs, etc.) of one or more MBS services provided by the target cell and/or may indicate one or more MBS services that are admitted by the target cell. The admitted MBS services may be a subset of the MBS services indicated/requested by the first message. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may comprise first configuration parameters for receiving control information (e.g., via an MCCH) for receiving the MBS data from the target cell. The first configuration parameters may comprise scheduling information (e.g., periodicity of control information transmission by the target cell, etc.) for receiving the control information. In some examples, the MBS configuration parameters and/or information required to receive data associated with the MBS services using the target cell may comprise a BWP identifier of the target cell for receiving the control information and/or data for the MBS services, a numerology associated with the MBS services (e.g., a numerology for MBS data/control reception), a control resource set (CORESET) for receiving scheduling information for MBS data/control, etc.; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]);
or first assistance information transmitted by a first core network function, wherein the first assistance information is used to control the RRC state of the user terminal.
Examiner’s Note:
The portions of Babaei (US 2023/0370905) relied upon for the identified subject matter are disclosed in Provisional Application No. 63/076,704, filed on 09/10/2020.
Fig. 18 of Babaei (US 2023/0370905) corresponds to Fig. 18 of Provisional Application No. 63/076,704.
Fig. 19 of Babaei (US 2023/0370905) corresponds to Fig. 19 of Provisional Application No. 63/076,704.
Para. [0148] of Babaei (US 2023/0370905) corresponds to Para. [0137] of Provisional Application No. 63/076,704.
Para. [0150-0157] of Babaei (US 2023/0370905) corresponds to Para. [0139-0144] of Provisional Application No. 63/076,704.
Babaei teaches maintaining a UE in an RRC Idle or RRC Inactive state in the context of multicast/broadcast service (MBS) continuity. Fig. 18 and 19 illustrate example options in which the UE evaluates MBS service continuity while remaining in RRC Idle or RRC inactive rather than returning to RRC Connected. Para. [0148] explains that the UE may remain in RRC Idle or RRC Inactive based on observing MBS service continuity triggers sent from the source/target gNB (i.e., network access device). Further, Para. [0152] explains that such triggers are determined for one or more MBS services or sessions based on service-specific measurement configuration parameters and thresholds, and further clarifies that, in some examples, the service continuity triggers may be dependent on the UE’s ongoing services or sessions. The claimed determination of the RRC state is satisfied because Babaei teaches at least one of the recited multicast-related conditions, consistent with the claim’s “at least one of” language.
[AltContent: textbox (Figure 1: Fig. 19 from Babaei (US 20230370905) illustrating the UE’s request for MBS configuration parameters to maintain service continuity and the gNB’s response causing the UE to remain in the RRC Inactive/Idle state while continuing to receive the MBS service. Annotations indicate how Fig. 19 is mapped to independent Claims 1 and 18.)]
PNG
media_image1.png
1471
1377
media_image1.png
Greyscale
Regarding Claim 18, Babaei teaches a network side device comprising (Fig. 15, Para. [0097-0102]):
a processor (Fig. 15, element 1540, Para. [0097-0102]);
and a memory having a computer program or instructions stored thereon, wherein the computer program or instructions, when executed by the processor, cause the processor to perform operations, comprising (Fig. 15, element 1530, Para. [0097-0102]):
when no data is received or transmitted through a connection specific to a user terminal, determining a Radio Resource Control (RRC) state of the user terminal (FIG. 19, Para. [0150-0157]; Fig. 18; Para. [0148]; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]):
and causing the user terminal to remain in the RRC state based on at least one of the following (FIG. 19, Para. [0150-0157]; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]):
that the user terminal participates in a multicast service (Fig. 19; Para. [0150-0157]; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272])
or the multicast service in which the user terminal participates (Fig. 19; Para. [0150-0157]; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272])
whether data is received or transmitted for a multicast service in which the user terminal participates (Fig. 19; Para. [0150-0157; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]);
or first assistance information transmitted by a first core network function, wherein the first assistance information is used to control the RRC state of the user terminal.
Regarding Claims 2 and 19, Babaei teaches Claims 1 and 18.
Babaei also teaches
wherein the multicast service is provided through a shared channel not specific to the user terminal (Para. [0106] - In some examples, one or more logical channels may be related to MBS transmissions. The one or more logical channels may comprise a Multicast/Broadcast control channel. The Multicast/Broadcast control channel may be a point-to-multipoint downlink channel used for transmitting MBS control information from the network to the UE, for one or several Multicast/Broadcast data channel. This channel may be used by UEs that receive or are interested to receive MBS. The one or more logical channels may comprise a Multicast/Broadcast data channel. This channel may be a point-to-multipoint downlink channel for transmitting MBS traffic data from the network; See also Para. [0103, 0107, 0109, 0114]; Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]).
The examiner interprets the PTM configuration for the MBS session to be sharing the multicast service through a shared channel not specific to the user terminal because the PTM configuration enables the UE to receive multicast data on a shared channel serving multiple UEs simultaneously and not dedicated to a specific UE.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 3, 4, and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Babaei in view of Kadiri et al. (US 2021/0068003, previously presented), Kadiri hereinafter.
Regarding Claim 3, Babaei teaches Claim 1.
Yet, Babaei does not expressly teach wherein that the first assistance information is used to control an RRC state of the user terminal comprises any one of the following: the first assistance information is used for indicating the RRC state of the user terminal controlled by the access network device; or the first assistance information is used for assisting determination of the RRC state of the user terminal.
However, Kadiri teaches
wherein that the first assistance information is used to control an RRC state of the user terminal comprises any one of the following (Fig. 5, step 505; Para. [0147]; See also Fig. 4, para. [0138-0145]; Fig. 14, Para. [0234-0237]; Fig. 15, Para. [0238-0242]; Fig. 16, Para. [0243-0249]; Fig. 17, Para. [0250-0253]; Para. [0255-0302]):
the first assistance information is used for indicating the RRC state of the user terminal controlled by the access network device (Fig. 5, step 505; Para. [0147]; See also Fig. 14, Para. [0234-0237]; Fig. 15, Para. [0238-0242]; Fig. 16, Para. [0243-0249]; Fig. 17, Para. [0250-0253]; Para. [0255-0302]);
or the first assistance information is used for assisting determination of the RRC state of the user terminal (Fig. 5, step 520; Para. [0147-0148] – [0148] At 520, the base station 105-b determines a UE connection state for receiving the multicast/broadcast traffic. In some cases, the UE connection state is determined based at least in part on the quality of service flow type associated with the multicast/broadcast traffic. For example, for relatively high QoS traffic, the connection state may be a CONNECTED mode state (e.g., RRC_CONNECTED). In another example, for relatively low QoS traffic, the connection state may be any of IDLE, INACTIVE, or CONNECTED mode states; See also Fig. 4, para. [0138-0145]; Fig. 14, Para. [0234-0237]; Fig. 15, Para. [0238-0242]; Fig. 16, Para. [0243-0249]; Fig. 17, Para. [0250-0253]; Para. [0255-0302]).
The examiner interprets Para. [0147-0148] as the base station at step 505 receives assistance information including a QoS flow type or UE connection state. At 520, the base station determines the UE’s RRC state at least in part on this information.
Therefore, it would have been obvious to one having ordinary skill of the art before the effective filing date of the claimed invention to combine Babaei’s invention of “a method of maintaining service continuity” (Babaei Para. [0004]) with Kadiri’s invention of “delivery of broadcast services using different broadcast/multicast radio bearer modes” (Kadiri Para. [002]) because Kadiri’s invention provides techniques for “selection of a radio bearer mode by a base station for service of multicast/broadcast traffic dependent on a quality of service for an indicated flow and/or a connected state of a user equipment (UE)” (Kadiri Para. [0005]).
Regarding Claim 4, Babaei Claim 1.
Babaei further teaches wherein the determination of the RRC state of the user terminal comprises any one of the following:
determining that the user terminal does not remain in an RRC-CONNECTED state (Fig. 18; Para. [0148]; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]);
determining that the user terminal enters an RRC-IDLE state (Fig. 18; Para. [0148]; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]);
or determining that the user terminal enters an RRC-INACTIVE state (Fig. 18; Para. [0148]; See also Fig. 16A-E, Para. [0131-0145]; Fig. 17, Para. [0146-0147]; Fig. 18, Para. [0148-0149]; Fig. 19, Para. [0150-0157]; Para. [0158-0171]; Para. [0178-0272]).
The examiner interprets that the UE is initially in an RRC Inactive or RRC Idle state in Fig. 18, Para. [0148], and may transition to RRC Connected, Inactive, or Idle state.
Yet, Babaei does not expressly teach determining that the user terminal remains in an RRC-CONNECTED state and determining that the user terminal does not remain in an RRC-CONNECTED state.
However, Kadiri teaches wherein the determination of the RRC state of the user terminal comprises any one of the following:
determining that the user terminal remains in an RRC-CONNECTED state (Fig. 4, flow 420-b; Para. [0142] - At MB flow 420-b, MB-UPF 405-b receives data and communicates the data to edge network devices according to MB-QoS flow 415-b. MB-QoS flow 415-b illustrates the RAN node 410-b operating in a mixed multicast/broadcast bearer mode and unicast mode. The RAN node 410-b may receive an indication to serve multicast/broadcast traffic to one or more UEs 115 from the MB-UPF 405-b. In accordance with the received indication, the RAN node 410-b may establish a multicast/broadcast N3 tunnel with the MB-UPF 405-b. In some cases, the MB-UPF 405-b may indicate that the multicast/broadcast tunnel is to be used for mixed multicast/broadcast and unicast mode based at least in part on a QoS associated with the traffic. The RAN node 410-b may receive the traffic via the multicast/broadcast N3 tunnel and transmit the multicast/broadcast traffic using a multicast/broadcast transmission (e.g., using a MRB) or a unicast transmission (e.g., using a DRB). In some cases, the RAN node 410-b may determine that the UEs 115-h and 115-i are to be in a CONNECTED mode only state in order to receive the multicast/broadcast traffic. In some cases, the RAN node 410-b may receive an indication from the core network that the UE 115-h and/or the 115-i are to be in a CONNECTED mode only state in order to receive the multicast/broadcast traffic. The RAN node 410-b may utilize a group radio network temporary identifier (G-RNTI) to perform the multicast/broadcast transmission; Fig. 5, step 520; Para. [0147-0148] – [0148] At 520, the base station 105-b determines a UE connection state for receiving the multicast/broadcast traffic. In some cases, the UE connection state is determined based at least in part on the quality of service flow type associated with the multicast/broadcast traffic. For example, for relatively high QoS traffic, the connection state may be a CONNECTED mode state (e.g., RRC_CONNECTED). In another example, for relatively low QoS traffic, the connection state may be any of IDLE, INACTIVE, or CONNECTED mode states; See also See also Fig. 4, para. [0138-0145]; Fig. 14, Para. [0234-0237]; Fig. 15, Para. [0238-0242]; Fig. 16, Para. [0243-0249]; Fig. 17, Para. [0250-0253]; Para. [0255-0302]);
determining that the user terminal does not remain in an RRC-CONNECTED state (Fig. 5, step 520; Para. [0147-0148] – [0148] At 520, the base station 105-b determines a UE connection state for receiving the multicast/broadcast traffic. In some cases, the UE connection state is determined based at least in part on the quality of service flow type associated with the multicast/broadcast traffic. For example, for relatively high QoS traffic, the connection state may be a CONNECTED mode state (e.g., RRC_CONNECTED). In another example, for relatively low QoS traffic, the connection state may be any of IDLE, INACTIVE, or CONNECTED mode states; See also See also Fig. 4, para. [0138-0145]; Fig. 14, Para. [0234-0237]; Fig. 15, Para. [0238-0242]; Fig. 16, Para. [0243-0249]; Fig. 17, Para. [0250-0253]; Para. [0255-0302]);
The examiner interprets that the user terminal is in an RRC state of RRC-CONNECETED, RRC-IDLE, or RRC-INACTIVE upon the beginning of the methods described in Figs. 4-5 and accompanying paragraphs.
Therefore, it would have been obvious to one having ordinary skill of the art before the effective filing date of the claimed invention to combine Babaei’s invention of “a method of maintaining service continuity” (Babaei Para. [0004]) with Kadiri’s invention of “delivery of broadcast services using different broadcast/multicast radio bearer modes” (Kadiri Para. [002]) because Kadiri’s invention provides techniques for “selection of a radio bearer mode by a base station for service of multicast/broadcast traffic dependent on a quality of service for an indicated flow and/or a connected state of a user equipment (UE)” (Kadiri Para. [0005]).
Regarding Claim 7, Babaei teaches Claim 1.
Yet, Babaei does not expressly teach wherein the first assistance information comprises any one of the following: an RRC-CONNECTED state; an RRC-IDLE state; an RRC-INACTIVE state; remaining in an RRC-CONNECTED state; prohibiting entering an RRC-IDLE state; prohibiting entering an RRC-INACTIVE state; no remaining in an RRC-CONNECTED state; entering an RRC-IDLE state; entering an RRC-INACTIVE state; or selecting a state corresponding to an RRC-CONNECTED state.
Kadiri further teaches wherein the first assistance information comprises any one of the following:
an RRC-CONNECTED state (Fig. 5, elements 505, 510, and 520; Para. [0145-0148] – [0148] At 510, the base station 510 identifies that the multicast/broadcast traffic is associated with a QoS flow type. At 514, the base station 105-b selects a radio bearer mode from a plurality of radio bearer modes for delivery of the multicast/broadcast traffic to at least one UE. The selecting may be based at least in part on the indication. For example, the indication may specify a radio bearer mode for the multicast/broadcast traffic. At 520, the base station 105-b determines a UE connection state for receiving the multicast/broadcast traffic. In some cases, the UE connection state is determined based at least in part on the quality of service flow type associated with the multicast/broadcast traffic. For example, for relatively high QoS traffic, the connection state may be a CONNECTED mode state (e.g., RRC_CONNECTED). In another example, for relatively low QoS traffic, the connection state may be any of IDLE, INACTIVE, or CONNECTED mode states; See also Para. [0075, 0121, 0123, 0125, 0127, 0128, 0130, 0131, 0136-0137, 0139-0145, 0149, 0153, 0165-0170, 0175-0179, 0200, 0210-0216, 0223-0224, 0252-0253, 0258-0267, 0277-0289, 0298]; Fig. 17);
an RRC-IDLE state (Para. [0128] - For multicast/broadcast only delivery modes, from the core network perspective, UEs 115 may receive service in both CM-IDLE and CM-CONNECTED mode. From a radio perspective, UEs 115 may receive service in a RRC IDLE, RRC_INACTIVE or RRC_CONNECTED state. If a particular UE 115 into RRC_CONNECTED (for any other purpose), UE should be able to receive broadcast service. When a particular UE 115 transitions between RRC_CONNCTED and RRC IDLE/RRC_INACTIVE states, UE shall be able to receive same broadcast service. Multicast/broadcast only delivery modes may support unicast assistance for UEs 115 in a connected state such that UEs may provide feedback (e.g., CSI, ACK/NACK) and the base stations 105 may provide retransmissions (e.g., ARQ, HARQ); See also Para. [0127, 0129, 0131, 0136, 0139, 0140, 0153, 0166-0170, 0179, 0211-0213, 0224, 0253, 0277, 0278, 0282, 0286] );
an RRC-INACTIVE state (Fig. 5, elements 505, 510, and 520; Para. [0145-0148]; See also Para. [0127, 0136, 0139, 0153, 0167, 0179, 0211-0213, 0253, 0277, 0278, 0282, 0286]);
remaining in an RRC-CONNECTED state (Fig. 5, elements 505, 510, and 520; Para. [0145-0148]; See also Para. [0075, 0121, 0123, 0125, 0127, 0128, 0130, 0131, 0136-0137, 0139-0145, 0149, 0153, 0165-0170, 0175-0179, 0200, 0210-0216, 0223-0224, 0252-0253, 0258-0267, 0277-0289, 0298]; Fig. 17);
prohibiting entering an RRC-IDLE state (Fig. 5, elements 505, 510, and 520; Para. [0145-0148]; See also Para. [0127, 0136, 0139, 0153, 0167, 0179, 0211-0213, 0253, 0277, 0278, 0282, 0286]);
prohibiting entering an RRC-INACTIVE state (Fig. 5, elements 505, 510, and 520; Para. [0145-0148]; See also Para. [0127, 0136, 0139, 0153, 0167, 0179, 0211-0213, 0253, 0277, 0278, 0282, 0286]););
no remaining in an RRC-CONNECTED state (Fig. 5, elements 505, 510, and 520; Para. [0145-0148]; See also Para. [0075, 0121, 0123, 0125, 0127, 0128, 0130, 0131, 0136-0137, 0139-0145, 0149, 0153, 0165-0170, 0175-0179, 0200, 0210-0216, 0223-0224, 0252-0253, 0258-0267, 0277-0289, 0298]; Fig. 17);
entering an RRC-IDLE state (Fig. 5, elements 505, 510, and 520; Para. [0145-0148]; See also Para. [0127, 0136, 0139, 0153, 0167, 0179, 0211-0213, 0253, 0277, 0278, 0282, 0286]);
entering an RRC-INACTIVE state (Fig. 5, elements 505, 510, and 520; Para. [0145-0148]; See also Para. [0127, 0136, 0139, 0153, 0167, 0179, 0211-0213, 0253, 0277, 0278, 0282, 0286]););
or selecting a state corresponding to an RRC-CONNECTED state (Fig. 5, elements 505, 510, and 520; Para. [0145-0148]; See also Para. [0075, 0121, 0123, 0125, 0127, 0128, 0130, 0131, 0136-0137, 0139-0145, 0149, 0153, 0165-0170, 0175-0179, 0200, 0210-0216, 0223-0224, 0252-0253, 0258-0267, 0277-0289, 0298]; Fig. 17).
Therefore, it would have been obvious to one having ordinary skill of the art before the effective filing date of the claimed invention to combine Babaei’s invention of “a method of maintaining service continuity” (Babaei Para. [0004]) with Kadiri’s invention of “delivery of broadcast services using different broadcast/multicast radio bearer modes” (Kadiri Para. [002]) because Kadiri’s invention provides techniques for “selection of a radio bearer mode by a base station for service of multicast/broadcast traffic dependent on a quality of service for an indicated flow and/or a connected state of a user equipment (UE)” (Kadiri Para. [0005]).
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Babaei in view of Kadiri as applied to Claim 4 above, and further in view of Kim et al. (US 2019/0357295, previously presented), Kim hereinafter.
Regarding Claim 5, Babaei in view of Kadiri teaches Claim 4.
Yet, Babaei does not expressly teach in the case of determining that the user terminal remains in the RRC-CONNECTED state.
However, Kadiri teaches
in the case of determining that the user terminal remains in the RRC-CONNECTED state (Fig. 4, flow 420-b; Para. [0142]; Fig. 5, step 520; Para. [0147-0148]; See also See also Fig. 4, para. [0138-0145]; Fig. 14, Para. [0234-0237]; Fig. 15, Para. [0238-0242]; Fig. 16, Para. [0243-0249]; Fig. 17, Para. [0250-0253]; Para. [0255-0302]),
Therefore, it would have been obvious to one having ordinary skill of the art before the effective filing date of the claimed invention to combine Babaei’s invention of “a method of maintaining service continuity” (Babaei Para. [0004]) with Kadiri’s invention of “delivery of broadcast services using different broadcast/multicast radio bearer modes” (Kadiri Para. [002]) because Kadiri’s invention provides techniques for “selection of a radio bearer mode by a base station for service of multicast/broadcast traffic dependent on a quality of service for an indicated flow and/or a connected state of a user equipment (UE)” (Kadiri Para. [0005]).
Yet, Babaei nor Kadiri expressly teach transmitting indication information to the first core network function, wherein the indication information is used for indicating that the state of the user terminal remains in the RRC- CONNECTED state or exits the RRC-CONNECTED state.
However, Kim teaches
transmitting indication information to the first core network function (Fig. 15, step 1505; Para. [0480] - In addition, after the RRC connection is established with the UE, when the RAN receives the UL NAS message (i.e., receives RRC message including the UL NAS message), the RAN may transmit the UL NAS message (i.e., response to the DL NAS message) to the CN node (step, S1505). Alternatively, the RAN may transmit the indication for RRC Connection establishment with the UE to the CN node when the RRC connection is established with the UE (step, S1505); See also Fig. 10, Para. [328-385]; Fig. 11, Para. [0386-0388]; Fig. 12, [0392-0498]; Fig. 13, [0429-0432]; Fig. 14, [0433-0464])
The examiner interprets a core network node (CN) as a core network function.
wherein the indication information is used for indicating that the state of the user terminal remains in the RRC- CONNECTED state or exits the RRC-CONNECTED state (Fig. 15, step 1505; Para. [0480-0482] - [0481] When the CN node receives the UL NAS message from the RAN or receives the indication for RRC Connection establishment, the CN node stops the second timer (step, S1506); See also Fig. 10, Para. [328-385]; Fig. 11, Para. [0386-0388]; Fig. 12, [0392-0498]; Fig. 13, [0429-0432]; Fig. 14, [0433-0464] ).
The examiner interprets Para. [0480-0482] as once the RRC connection is established with the UE, the CN node (i.e., core network function) receives the UL NAS message or the indication for the RRC Connection establishment (either are considered indication information); the UL NAS message or the indication for the RRC Connection establishment reflect that the UE is in, and remains in, the RRC-CONNECTED state. Thus, the information is used to signal that the UE’s state continues in RRC-CONNECTED mode.
Therefore, it would have been obvious to one having ordinary skill of the art before the effective filing date of the claimed invention to provide transmitting indication information to the first core network function, wherein the indication information is used for indicating that the state of the user terminal remains in the RRC- CONNECTED state or exits the RRC-CONNECTED state as taught by Kim, in the combined system of Babaei/Kadiri, so that it would provide “a method for transmitting and receiving a Non-Access Stratum (NAS) message to/from a User Equipment (UE) which is in a light connection state or a Radio Resource Control (RRC)-Inactive state” (Kim Para. [0005]).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Babaei in view of Kadiri as applied to Claim 4 above, and further in view of Banister et al. (US 2014/0269637, previously presented), Banister hereinafter.
Regarding Claim 6, Babaei in view of Kadiri teaches Claim 4.
Yet, Babaei does not expressly teach in the case of determining that the user terminal remains in the RRC-CONNECTED state.
However, Kadiri teaches
in the case of determining that the user terminal remains in the RRC-CONNECTED state (Fig. 4, flow 420-b; Para. [0142]; Fig. 5, step 520; Para. [0147-0148]; See also See also Fig. 4, para. [0138-0145]; Fig. 14, Para. [0234-0237]; Fig. 15, Para. [0238-0242]; Fig. 16, Para. [0243-0249]; Fig. 17, Para. [0250-0253]; Para. [0255-0302]),
Therefore, it would have been obvious to one having ordinary skill of the art before the effective filing date of the claimed invention to combine Babaei’s invention of “a method of maintaining service continuity” (Babaei Para. [0004]) with Kadiri’s invention of “delivery of broadcast services using different broadcast/multicast radio bearer modes” (Kadiri Para. [002]) because Kadiri’s invention provides techniques for “selection of a radio bearer mode by a base station for service of multicast/broadcast traffic dependent on a quality of service for an indicated flow and/or a connected state of a user equipment (UE)” (Kadiri Para. [0005]).
Yet, Babaei nor Kadiri expressly teach stopping transmitting a connection release message to the user terminal.
However, Banister teaches
stopping transmitting a connection release message to the user terminal (Fig. 17; Para. [0054] - The RRC connection release message 706 may be sent from the eNB 704 at time B during the time period T.sub.p 710 in which the UE 702 is unable to receive/decode the RRC connection release message 706. Subsequent RRC connection release messages 706 may be sent at times B' and B''. The duration of time in which the UE 702 is unable to receive the RRC connection release message 706 from the eNB 704 begins at time A 708 and extends for a duration T.sub.p 710. At time C, the UE 702 may regain the ability to receive the RRC connection release message 706. For example, at time C, the UE 702 may switch back from the second RAT to the first RAT. For another example, at time C 712, the UE 702 may re-enter the radio range of the eNB 704 sending the RRC connection release message 706. Prior to time C 712, the eNB 704 stops sending the RRC connection release message 706)
Therefore, it would have been obvious to one having ordinary skill of the art before the effective filing date of the claimed invention to provide stopping transmitting a connection release message to the user terminal as taught by Banister, in the combined system of Babaei/Kadiri, so that it would provide methods for determining “a possibility of failing to receive an RRC connection release message from a network” (Banister Para. [0007]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Mikaeil (US 20260089467) Fig. 6 and Para. [0202] teaches the names of multicast services through its disclosure of TMGIs, MBS context identifiers, and service identifiers.
Chou (US 20230403537) Figs. 6A-6D and Para. [0129] discusses a number of MBS services concurrently received by a UE, but that number is determined and used by the base station in DCI signaling to the UE, rather than being included in multicast service status transmitted by a core-network function to the access-network device.
Dao (US 20180192289) Fig. 7 and Para. [0064] teaches that a core-network MBMS membership function manages UE subscription data identifying the services to which the UE subscribes; however, Dao does not teach communicating that membership information to the RAN or otherwise including it in assistance information transmitted to the access network device.
Kong et al. (KR 20100045900 A) Para. [0079-0091] teaches maintaining MBMS service context and related multicast information while a UE remains in an idle state.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAENITA ANN FENNER whose telephone number is (571)270-0880. The examiner can normally be reached 8:00 - 5:30 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, Marcus Smith can be reached at (571) 270-1096. 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.
/R.A.F./Examiner, Art Unit 2468
/Thomas R Cairns/Primary Examiner, Art Unit 2468
Prosecution Insights