DETAILED ACTION
Claims 1, 4-6, 9-12, 14, 17-19, and 21-28 are presented for examination.
Claims 2-3, 7-8, 13, 15-16 and 20 are cancelled.
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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on December 2, 2024, and August 27, 2025, are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0050]: Describes Multicast Session Deactivation. “…switched from inactive state to inactive state.” seems to be a typo. It is suggested to the applicant to change to “…switched from the active state to the inactive state.”
Appropriate correction is required.
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, 4, 6, 10-12, 14, 17-19, 21-22, 24, 26-28 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Babaei (US 20240260134 A1).
Regarding claim 1, Babaei teaches a method for determining a multicast service area for an inactive state, executed by a terminal (UE of Fig. 20), comprising:
receiving configuration information associated with a multicast service for the inactive state ([0129] In some examples, the RRCRelease message may be used to command the release of an RRC connection or the suspension of the RRC connection. In some examples, an IE suspendConfig may indicate configuration for the RRC_INACTIVE state.); and
determining a service area of the multicast service for the inactive state based on the configuration information associated with the multicast service for the inactive state (Fig. 20, [0217] In some examples, the UE may determine the MBS zone (multicast service area for an inactive state) based on one or more IEs/parameters indicated by an RRC release message (e.g., a suspend config of the RRC release message). [0129] In some examples, an IE suspendConfig may indicate configuration for the RRC_INACTIVE state (configuration information associated with the multicast service for the inactive state).).
Regarding claim 4, Babaei teaches the method of claim 1, wherein the configuration information associated with the multicast service for the inactive state comprises at least one of:
a service configuration of the multicast service for the inactive state ([0221] In some examples, the one or more multicast broadcast services (MBS)-related notifications may indicate one or more MBS configuration parameters for reception of the MBS data.); or
a list of cells of the multicast service for the inactive state ([0129] In some example, RAN-NotificationAreaInfo in the RRCRelease message may comprise a cellist field indicating a list of cells configured as RAN area.).
Regarding claim 6, Babaei teaches the method of claim 4, wherein the determining the service area of the multicast service for the inactive state comprises:
determining a service area indicated by the list of cells of the multicast service for the inactive state configured by a network as the service area of the multicast service for the inactive state ([0209] In some examples, the MBS configuration may be the same across a set of nearby cells or sectors. In this case RAN may configure such set of cells as a RAN Notification Area (RNA) for MBS such that inactive UE moving within such MBS-RNA may receive MBS data without returning to connected mode. UEs in inactive state may resume their connection in the same or different cells within the same RNA reusing the same MBS context and configuration. [0217] In some examples, the UE may determine the MBS zone based on one or more IEs/parameters indicated by an RRC release message (e.g., a suspend config of the RRC release message). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone. [0129] In some example, RAN-NotificationAreaInfo in the RRCRelease message may comprise a cellist field indicating a list of cells configured as RAN area. In some examples, ran-AreaConfigList may indicate a list of RAN area codes or RA code(s) as RAN area.).
Regarding claim 10, Babaei teaches the method of claim 1, wherein the service area of the multicast service for the inactive state comprises an area indicated by at least one of:
a cell identity list ([0217] For example, the MBS zone may be for/associated with one or more cells and/or RAN notification areas (RNAs) and/or tracking areas (TAs). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone.);
a Tracking Area Identity (TAI) list ([0217] For example, the MBS zone may be for/associated with one or more cells and/or RAN notification areas (RNAs) and/or tracking areas (TAs). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone.); or
geographical area information.
Regarding claim 11, Babaei teaches a method for configuring a multicast service area for an inactive state, executed by a network device (Base Station of Fig. 20), comprising:
sending configuration information associated with a multicast service for the inactive state to a terminal, wherein the configuration information associated with the multicast service for the inactive state is used to assist the terminal in determining a service area of the multicast service for the inactive state (Fig. 20, [0217] For example, the UE may receive an RRC release message comprising a suspend config IE indicating transitioning command from the RRC connected state to the RRC inactive state. The UE may determine an MBS zone associated with MBS data reception (e.g., MBS data reception in the RRC inactive state). For example, the MBS zone may be for/associated with one or more cells and/or RAN notification areas (RNAs) and/or tracking areas (TAs). [0217] In some examples, the UE may determine the MBS zone (multicast service area for an inactive state) based on one or more IEs/parameters indicated by an RRC release message (e.g., a suspend config of the RRC release message). [0129] In some examples, an IE suspendConfig may indicate configuration for the RRC_INACTIVE state (configuration information associated with the multicast service for the inactive state).).
Regarding claim 12, Babaei teaches the method of claim 11, wherein the configuration information associated with the multicast service for the inactive state comprises at least one of:
a service configuration of the multicast service for the inactive state ([0221] In some examples, the one or more multicast broadcast services (MBS)-related notifications may indicate one or more MBS configuration parameters for reception of the MBS data.); or
a list of cells of the multicast service for the inactive state ([0129] In some example, RAN-NotificationAreaInfo in the RRCRelease message may comprise a cellist field indicating a list of cells configured as RAN area.).
Regarding claim 14, Babaei teaches the method of claim 11, wherein the service area of the multicast service for the inactive state comprises at least one of:
a cell identity list ([0217] For example, the MBS zone may be for/associated with one or more cells and/or RAN notification areas (RNAs) and/or tracking areas (TAs). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone.);
a Tracking Area Identity (TAI) list ([0217] For example, the MBS zone may be for/associated with one or more cells and/or RAN notification areas (RNAs) and/or tracking areas (TAs). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone.); or
geographical area information.
Regarding claim 17, Babaei teaches a terminal, comprising: a processor (Fig. 15; processor 1540); and a transceiver coupled to the processor (Fig. 15; transceiver 1520), wherein the processor is configured to:
receive configuration information associated with a multicast service for the inactive state ([0129] In some examples, the RRCRelease message may be used to command the release of an RRC connection or the suspension of the RRC connection. In some examples, an IE suspendConfig may indicate configuration for the RRC_INACTIVE state.); and
determine a service area of the multicast service for the inactive state based on the configuration information associated with the multicast service for the inactive state (Fig. 20, [0217] In some examples, the UE may determine the MBS zone (multicast service area for an inactive state) based on one or more IEs/parameters indicated by an RRC release message (e.g., a suspend config of the RRC release message). [0129] In some examples, an IE suspendConfig may indicate configuration for the RRC_INACTIVE state (configuration information associated with the multicast service for the inactive state).).
Regarding claim 18, Babaei teaches a network device, comprising: a processor (Fig. 15; processor 1540); and a transceiver coupled to the processor (Fig. 15; transceiver 1520), wherein the processor is configured to implement the method of claim 11.
Regarding claim 19, Babaei teaches a non-transitory computer-readable storage medium storing therein at least one instruction, at least one program, a code set or an instruction set, wherein the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by a processor to implement the method of claim 1 ([0239] A non-transitory medium may be used to carry or store desired program code means (e.g., instructions and/or data structures) and may be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor.)
Regarding claim 21, Babaei teaches a non-transitory computer-readable storage medium storing therein at least one instruction, at least one program, a code set or an instruction set, wherein the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by a processor to implement the method of claim 11 ([0239] A non-transitory medium may be used to carry or store desired program code means (e.g., instructions and/or data structures) and may be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor.).
Regarding claim 22, Babaei teaches the terminal according to claim 17, wherein the configuration information associated with the multicast service for the inactive state comprises at least one of:
a service configuration of the multicast service for the inactive state ([0221] In some examples, the one or more multicast broadcast services (MBS)-related notifications may indicate one or more MBS configuration parameters for reception of the MBS data.); or
a list of cells of the multicast service for the inactive state ([0129] In some example, RAN-NotificationAreaInfo in the RRCRelease message may comprise a cellist field indicating a list of cells configured as RAN area.).
Regarding claim 24, Babaei teaches the terminal according to claim 22, wherein the processor is configured to:
determine a service area indicated by the list of cells of the multicast service for the inactive state configured by a network as the service area of the multicast service for the inactive state ([0209] In some examples, the MBS configuration may be the same across a set of nearby cells or sectors. In this case RAN may configure such set of cells as a RAN Notification Area (RNA) for MBS such that inactive UE moving within such MBS-RNA may receive MBS data without returning to connected mode. UEs in inactive state may resume their connection in the same or different cells within the same RNA reusing the same MBS context and configuration. [0217] In some examples, the UE may determine the MBS zone based on one or more IEs/parameters indicated by an RRC release message (e.g., a suspend config of the RRC release message). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone. [0129] In some example, RAN-NotificationAreaInfo in the RRCRelease message may comprise a cellist field indicating a list of cells configured as RAN area. In some examples, ran-AreaConfigList may indicate a list of RAN area codes or RA code(s) as RAN area.).
Regarding claim 26, Babaei teaches the terminal according to claim 17, wherein the service area of the multicast service for the inactive state comprises an area indicated by at least one of:
a cell identity list ([0217] For example, the MBS zone may be for/associated with one or more cells and/or RAN notification areas (RNAs) and/or tracking areas (TAs). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone.);
a Tracking Area Identity (TAI) list ([0217] For example, the MBS zone may be for/associated with one or more cells and/or RAN notification areas (RNAs) and/or tracking areas (TAs). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone.); or
geographical area information.
Regarding claim 27, Babaei teaches the network device according to claim 18, wherein the configuration information associated with the multicast service for the inactive state comprises at least one of:
a service configuration of the multicast service for the inactive state ([0221] In some examples, the one or more multicast broadcast services (MBS)-related notifications may indicate one or more MBS configuration parameters for reception of the MBS data.); or
a list of cells of the multicast service for the inactive state ([0129] In some example, RAN-NotificationAreaInfo in the RRCRelease message may comprise a cellist field indicating a list of cells configured as RAN area.).
Regarding claim 28, The network device according to claim 18, wherein the service area of the multicast service for the inactive state comprises an area indicated by at least one of:
a cell identity list ([0217] For example, the MBS zone may be for/associated with one or more cells and/or RAN notification areas (RNAs) and/or tracking areas (TAs). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone.);
a Tracking Area Identity (TAI) list ([0217] For example, the MBS zone may be for/associated with one or more cells and/or RAN notification areas (RNAs) and/or tracking areas (TAs). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone.); or
geographical area information.
Claim Rejections - 35 USC § 103
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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 5, 9, 23 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Babaei (US 20240260134 A1) in view of Deng (US 20250294322 A1).
Regarding claim 5, Babaei teaches the method of claim 4, wherein the determining the service area of the multicast service for the inactive state comprises:
determining a cell where the service configuration of the multicast service for the inactive state is received as the service area of the multicast service for the inactive state ([0217] In some examples, the UE may determine the MBS zone based on one or more IEs/parameters indicated by an RRC release message (e.g., a suspend config of the RRC release message). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone. The UE may receive MBS data, while within the MBS zone using first configuration parameters. In some examples (e.g., while the UE is in RRC inactive state), the MBS configuration parameters may be MBS zone-specific, and the first configuration parameters may be for the MBS zone in which the UE currently resides. The MBS zone in which the UE currently resides can be made up of just one cell.).
Deng in the same field of endeavor of multicast service in inactive state also teaches determining a cell where the service configuration of the multicast service for the inactive state is received as the service area of the multicast service for the inactive state (([0071] In some embodiments, the serving cell notifies the terminal device to receive the multicast service in the inactive state through the first indication information. The condition (i.e., the criterion) that the terminal device needs to meet to receive the multicast service in the inactive state is preset by a standard or protocol. If the terminal device in the inactive state continues to be interested in the multicast service, it needs to determine whether the condition is met. The condition that requires to be met to receive the multicast service in the inactive state includes one or more of followings. [0072] 1. UE continues to be within the serving cell (i.e., the serving cell sending the first indication information). (Since the condition requires the UE remain within the serving cell to receive MBS service in inactive state, the serving cell where the service configuration of the multicast service for the inactive state is received is the service area of the multicast service for the inactive state.)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of determining the service area of the multicast service for the inactive state of Babaei to include the condition the terminal needs to meet to receive the multicast service of Deng. The motivation to do so would have been to provide a method for sending and receiving a multicast service in an inactive state (Deng; [0005] [0006]).
Regarding claim 9, Babaei teaches the method of claim 1, and teaches a serving cell may be a Primary cell ([0081] A serving cell may be a Primary Cell (PCell).
Babaei does not explicitly teach wherein the determining the service area of the multicast service for the inactive state comprises:
determining that the service area of the multicast service for the inactive state only covers a Primary cell (Pcell).
Deng in the same field of endeavor of multicast service in inactive state teaches determining that the service area of the multicast service for the inactive state only covers a serving cell ([0071] In some embodiments, the serving cell notifies the terminal device to receive the multicast service in the inactive state through the first indication information. The condition (i.e., the criterion) that the terminal device needs to meet to receive the multicast service in the inactive state is preset by a standard or protocol. If the terminal device in the inactive state continues to be interested in the multicast service, it needs to determine whether the condition is met. The condition that requires to be met to receive the multicast service in the inactive state includes one or more of followings. [0072] 1. UE continues to be within the serving cell (i.e., the serving cell sending the first indication information). If the serving cell is a Pcell, as taught by Babaei, then Babaei in view of Deng teaches determining that the service area of the multicast service for the inactive state only covers a Primary cell (Pcell), since the condition requires the UE remain within the serving cell.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of determining the service area of the multicast service for the inactive state of Babaei to include the condition the terminal needs to meet to receive the multicast service of Deng. The motivation to do so would have been to provide a method for sending and receiving a multicast service in an inactive state (Deng; [0005] [0006]).
Regarding claim 23, Babaei teaches the terminal according to claim 22, wherein the processor is configured to:
determine a cell where the service configuration of the multicast service for the inactive state is received as the service area of the multicast service for the inactive state ([0217] In some examples, the UE may determine the MBS zone based on one or more IEs/parameters indicated by an RRC release message (e.g., a suspend config of the RRC release message). The one or more IEs/parameters indicating the MBS zone may indicate identifiers associated with the cell(s)/RNA(s)/TA(s) of the MBS zone. The UE may receive MBS data, while within the MBS zone using first configuration parameters. In some examples (e.g., while the UE is in RRC inactive state), the MBS configuration parameters may be MBS zone-specific, and the first configuration parameters may be for the MBS zone in which the UE currently resides.).
Deng in the same field of endeavor of multicast service in inactive state also teaches determining a cell where the service configuration of the multicast service for the inactive state is received as the service area of the multicast service for the inactive state (([0071] In some embodiments, the serving cell notifies the terminal device to receive the multicast service in the inactive state through the first indication information. The condition (i.e., the criterion) that the terminal device needs to meet to receive the multicast service in the inactive state is preset by a standard or protocol. If the terminal device in the inactive state continues to be interested in the multicast service, it needs to determine whether the condition is met. The condition that requires to be met to receive the multicast service in the inactive state includes one or more of followings. [0072] 1. UE continues to be within the serving cell (i.e., the serving cell sending the first indication information). (Since the condition requires the UE remain within the serving cell to receive MBS service in inactive state, the serving cell where the service configuration of the multicast service for the inactive state is received is the service area of the multicast service for the inactive state.)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of determining the service area of the multicast service for the inactive state of Babaei to include the condition the terminal needs to meet to receive the multicast service of Deng. The motivation to do so would have been to provide a method for sending and receiving a multicast service in an inactive state (Deng; [0005] [0006]).
Regarding claim 25, Babaei teaches the terminal according to claim 17, and teaches a serving cell may be a Primary cell ([0081] A serving cell may be a Primary Cell (PCell).
Babaei does not explicitly teach wherein the determining the service area of the multicast service for the inactive state comprises:
determining that the service area of the multicast service for the inactive state only covers a Primary cell (Pcell).
Deng in the same field of endeavor of multicast service in inactive state teaches determining that the service area of the multicast service for the inactive state only covers a serving cell ([0071] In some embodiments, the serving cell notifies the terminal device to receive the multicast service in the inactive state through the first indication information. The condition (i.e., the criterion) that the terminal device needs to meet to receive the multicast service in the inactive state is preset by a standard or protocol. If the terminal device in the inactive state continues to be interested in the multicast service, it needs to determine whether the condition is met. The condition that requires to be met to receive the multicast service in the inactive state includes one or more of followings. [0072] 1. UE continues to be within the serving cell (i.e., the serving cell sending the first indication information). If the serving cell is a Pcell, as taught by Babaei, then Babaei in view of Deng teaches determining that the service area of the multicast service for the inactive state only covers a Primary cell (Pcell), since the condition requires the UE remain within the serving cell.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of determining the service area of the multicast service for the inactive state of Babaei to include the condition the terminal needs to meet to receive the multicast service of Deng. The motivation to do so would have been to provide a method for sending and receiving a multicast service in an inactive state (Deng; [0005] [0006]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Belling (US 20230319853 A1) discloses a means for determining an area where handling of the multicast session for the at least one user equipment in inactive state is required; determining one or more nodes handling cells within at least a part of the determined area for handling the multicast session.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NANCY SIXTO whose telephone number is (571)272-3295. The examiner can normally be reached Mon - Friday 9AM-5PM EST.
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, Gary Mui can be reached at 571-270-1420. 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.
/NANCY SIXTO/Examiner, Art Unit 2465
/GARY MUI/Supervisory Patent Examiner, Art Unit 2465
Prosecution Insights