Prosecution Insights
Last updated: July 17, 2026
Application No. 18/320,939

REDUCED CAPABILITY FOR BROADCAST AND MULTICAST IN RRC INACTIVE STATE

Final Rejection §103
Filed
May 19, 2023
Examiner
KWAK, JAEYOUNG
Art Unit
2472
Tech Center
2400 — Computer Networks
Assignee
Qualcomm Incorporated
OA Round
2 (Final)
89%
Grant Probability
Favorable
3-4
OA Rounds
1m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 89% — above average
89%
Career Allowance Rate
16 granted / 18 resolved
+30.9% vs TC avg
Strong +18% interview lift
Without
With
+18.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 3m
Avg Prosecution
22 currently pending
Career history
51
Total Applications
across all art units

Statute-Specific Performance

§101
0.6%
-39.4% vs TC avg
§103
88.2%
+48.2% vs TC avg
§102
11.2%
-28.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 18 resolved cases

Office Action

§103
CTFR 18/320,939 CTFR 99873 DETAILED ACTION The office action is in response to the amendments received on Feb. 20, 2026 after a non-final office action. Claims 1-30 are pending in this application, based on the amended claims on Feb. 20, 2026. Information Disclosure Statement The information disclosure statements (IDSs) submitted on Sept. 16, 2024 has been considered by the examiner. Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Response to Arguments Applicant’s Amendments and Arguments filed 02/20/2026 have been considered for examination. Claims 1-30 are pending in the instant application. With regard to the 102/103 rejections, Applicant’s arguments filed 02/20/2026 (see pages 12-15 of Remarks) in view of the amendments have been fully considered but are not persuasive at least in view of the reasons set forth below. Further, Examiner notes that Applicant’s amendments necessitated the new ground(s) of rejection presented in the instant Office Action. Regarding claim 1, 15, 26, and 29, Applicant argued: Regarding the part of the amended claim 1, recited as "the first type of RedCap UE [that] supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of RedCap UE, wherein the second maximum bandwidth is less than a third maximum bandwidth that is supported by a third type of non-RedCap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth," Zhang fails to disclose, at least the following reasons. Further, Zhang only distinguishes between two categories: "first terminal" (RedCap/eRedCap grouped together) and "second terminal" (eMBB), not three distinct types with hierarchical bandwidth relationships as claimed. Rather, Zhang configures one CFR for all RedCap/eRedCap terminals collectively ("cfr- ConfigMCCH-MTCH-RedCap#") without differentiating CFRs based on the different bandwidth capabilities of different types of Red Cap UEs. In contrast, the amended claims recite that the first CFR is specifically "based on the support for the first maximum bandwidth" of the first type of RedCap UE, and a different second CFR that is "based on the support for the second maximum bandwidth" of the second type of RedCap UE. In response to Applicant’s argument, Examiner respectfully disagrees. In the argument, Applicant argue that the part of the amended claim 1, “ the first type of RedCap UE supports a first maximum bandwidth … the second CFR is based on the support for the second maximum bandwidth, ” is not disclosed by the combination of Zhang, but Examiner respectfully disagree. Zhang, in the previous action, clearly discloses the previous claim 1. In addition, Zhang theaches that wherein the second maximum bandwidth is less than a third maximum bandwidth that is supported by a third type of non-RedCap UE . Zhang, in Page 12, Lines 31 - Page 13, Lines 3, teaches that the first type of terminal (it is corresponding to the second type of RedCap UE) may include a reduced capability (RedCap) terminal (or UE) and/or an enhanced RedCap (eRedCap) terminal and the second type of terminal may be an enhanced mobile broadband (eMBB) terminal (it is corresponding to a third type of non-RedCap UE: a non-RedCap terminal or a normal terminal). The first terminal belongs to the first type of terminal, and the second terminal belongs to the second type of terminal. The features of the first terminal are considered as the features of the first type of terminal and the features of the second terminal are considered as the features of the second type of terminal. The maximum operating bandwidth of the first terminal (the second type RedCap UE) is less than the maximum operating bandwidth of the second terminal (third type of non-RedCap UE), or the maximum operating bandwidth of the second terminal is greater than the maximum operating bandwidth of the first terminal, or the second terminal device is a normal terminal or a non-capability-reduced terminal or a normal terminal. Thus, it is clear that the maximum bandwidth of RedCap UE (the first type or the second type) is less than the maximum bandwidth of non-RedCap UE (the third type of non-RedCap UE). Further, Sha Tong et. al. (Int. Pub. No.: WO 2024208022 A1 translated version, hereinafter “Sha”) teaches that wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth. Sha, in Page 30, Lines 20-34 and in Page 32, Lines 3-17, teaches that for a terminal device in an RRC non-connected state, when a multicast session is in a deactivated state, the network device needs to notify the terminal device so that the terminal device stops receiving the multicast session. To indicate this, an MCCH message is sent to the terminal device, and the deactivated state of the multicast session is indicated through the MCCH message, which will cause energy consumption overhead of the terminal device and increase the burden on the network side. Thus, as described in Page 33, Lines 10-25, the RedCap terminal (UE) is supported by the cell to provide MBS (multicast broadcast services). For this, two different CFRs are configured for two different RedCap UE. For the first RedCap terminal, the bandwidth value of the first common frequency resource CFR configured by SIB20 of the first cell does not exceed the first bandwidth value. Among them, the first bandwidth value can be the maximum bandwidth supported by the terminal equipment. If the first CFR configured by SIB20 is default, the bandwidth value of the first CFR is equal to the bandwidth of control resource set 0 (CORESET#0), and CORESET#0 is configured by SIB1. Alternatively, the first cell configures a second CFR, and the second CFR is the CFR used by the first type of terminal equipment (another RedCap UE: corresponding to the second type of RedCap UE), and the second CFR is independent of the first CFR. Here, the first type of terminal in the art indicates the RedCap UE, but as described in Paragraphs [0088] and [0089], the RedCap UEs having different configuration (bandwidth capability) are considered as different type of RedCap UE. Among them, the bandwidth value of the second CFR does not exceed the maximum bandwidth supported by the first type of terminal equipment (the second RedCap UE), and the second CFR can be configured by an additional field in SIB20, or configured through other SIBs. The second CFR can be a CFR dedicated to REDCAP terminal equipment configured by the network device, and the bandwidth of the above-mentioned second CFR is less than or equal to the maximum channel bandwidth supported by the REDCAP terminal equipment. Thus, since the first maximum bandwidth of the first RedCap UE is the bandwidth of CORESET#0 and the second maximum bandwidth of the second RedCap UE is the maximum channel bandwidth, the first maximum bandwidth of the first RedCap UE is less than one of the second RedCap UE and two CFRs are independent. Therefore, combination of Zhang and Sha clearly discloses the part of the amended claim 1 mentioned in the above and in the argument. Although the explanation is made for the arguments, here, the new rejection is made in the below, since the scope of the clams has been changed by amending. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. Claims 1-7, 9-20, 22-30 are rejected are rejected under U.S.C. 103 as being unpatentable over Zhang, Haisen et. al. (Int. Pub. No.: WO 2024208230 A1 translated version, hereinafter “Zhang”) in a view of Sha Tong et. al. (Int. Pub. No.: WO 2024208022 A1 translated version, hereinafter “Sha”) Regarding claim 1, Zhang teaches that an apparatus for wireless communication at a wireless device, comprising: at least one memory; and at least one processor coupled to the at least one memory and, based at least in part on information stored in the at least one memory, the at least one processor, individually or in any combination, is configured to: (Zhang, in Fig. 2 and in Page 15, Lines 14-22, teaches that as shown in FIG. 2, the communication device 200 includes at least one processor 201 and at least one communication interface (FIG. 2 is merely an example of a communication interface 204 and a processor 201). Optionally, the communication device 200 may further include a communication bus 202 and a memory 203. The processor 201 may be a general-purpose central processing unit (CPU), a general-purpose processor, a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof. The processor 201 may also be other devices with processing functions, such as circuits, devices, or software modules, without limitation. Therefore, it is clear that an apparatus at a wireless device comprises a processor coupled to a memory in which the information is stored.) receive a first indication of a first common frequency resource (CFR) associated with at least one of a multicast control channel (MCCH) or a multicast traffic channel (MTCH) for a first type of reduced capability (RedCap) UE in one of an inactive or idle state (Zhang, in Page 13, Lines 1-3, in Page 17, Lines 12-41, and in Page 18, Lines 1-21, teaches that the first type of terminal may include a reduced capability (RedCap) terminal and/or an enhanced RedCap (eRedCap) terminal. When the network provides broadcast services, the terminals receive them autonomously according to the configuration information. Broadcast services can be provided to terminals in any radio resource control (RRC) state that include RRC idle or inactive state. For broadcast services, two logical channels are introduced in the NR system: MBS control channel (MCCH) and MBS traffic channel (MTCH). At the physical layer, MCCH messages and broadcast services are carried in PDSCH. MCCH messages are transmitted periodically, and their configuration information is carried in the system information block (SIB), such as SIB20. For example, SIB20 may include MCCH configuration information (located in the cell mcch-Config) and common frequency resources (CFR) (located in the cell cfr-ConfigMCCH-MTCH). The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. From this, it can be considered as the first indication of CFR. CFR is a continuous frequency domain resource, which can be defined by a starting position and a bandwidth size. CFR is used to transmit MBS services. CFR can be: control resource set (CORESET) 0 (i.e., CORESET0), SIB1 configured bandwidth (such as initial part bandwidth (bandwidth part, BWP)), or a separately configured bandwidth larger than the SIB1 configured bandwidth. It is alternative first indication of CFR. MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. Based on this observation, it is clear that a first indication of a common frequency resource (CFR) associated with at least one of a multicast control channel (MCCH) or a multicast traffic channel (MTCH) for a plurality of reduced capability (RedCap) UEs in one of an inactive or idle state is received.) wherein the second maximum bandwidth is less than a third maximum bandwidth that is supported by a third type of non-RedCap UE (Zhang, in Page 12, Lines 31 - Page 13, Lines 3, teaches that the first type of terminal (it is corresponding to the second type of RedCap UE) may include a reduced capability (RedCap) terminal (or UE) and/or an enhanced RedCap (eRedCap) terminal and the second type of terminal may be an enhanced mobile broadband (eMBB) terminal (it is corresponding to a third type of non-RedCap UE: a non-RedCap terminal or a normal terminal). The first terminal belongs to the first type of terminal, and the second terminal belongs to the second type of terminal. The features of the first terminal are considered as the features of the first type of terminal and the features of the second terminal are considered as the features of the second type of terminal. The maximum operating bandwidth of the first terminal (the second type RedCap UE) is less than the maximum operating bandwidth of the second terminal (third type of non-RedCap UE), or the maximum operating bandwidth of the second terminal is greater than the maximum operating bandwidth of the first terminal, or the second terminal device is a normal terminal or a non-capability-reduced terminal or a normal terminal. Thus, it is clear that the maximum bandwidth of RedCap UE (the first type or the second type) is less than the maximum bandwidth of non-RedCap UE (the third type of non-RedCap UE).) and monitor the CFR indicated in the first indication for at least one of broadcast traffic or multicast traffic (Zhang, in Page 17, Lines 29-36, teaches that MCCH messages are transmitted periodically, and their configuration information is carried in the system information block (SIB), such as SIB20. For example, SIB20 may include MCCH configuration information (located in the cell mcch-Config) and common frequency resources (CFR) (located in the cell cfr-ConfigMCCH-MTCH). The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. Based on this observation, the MCCH message are transmitted periodically for broadcast service with configuration information including CFR configuration information, to monitor MCCH and the associated CFR. Therefore, it is clear that based on the MCCH message, the CFR indicated in the first indication for at least one of broadcast traffic or multicast traffic is monitored periodically.) However, Zhang does not explicitly teach that wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth. Sha teaches that wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth (Sha, in Page 30, Lines 20-34 and in Page 32, Lines 3-17, teaches that for a terminal device in an RRC non-connected state, when a multicast session is in a deactivated state, the network device needs to notify the terminal device so that the terminal device stops receiving the multicast session. To indicate this, an MCCH message is sent to the terminal device, and the deactivated state of the multicast session is indicated through the MCCH message, which will cause energy consumption overhead of the terminal device and increase the burden on the network side. Thus, as described in Page 33, Lines 10-25, the RedCap terminal (UE) is supported by the cell to provide MBS (multicast broadcast services). For this, two different CFRs are configured for two different RedCap UE. For the first RedCap terminal, the bandwidth value of the first common frequency resource CFR configured by SIB20 of the first cell does not exceed the first bandwidth value. Among them, the first bandwidth value can be the maximum bandwidth supported by the terminal equipment. If the first CFR configured by SIB20 is default, the bandwidth value of the first CFR is equal to the bandwidth of control resource set 0 (CORESET#0), and CORESET#0 is configured by SIB1. Alternatively, the first cell configures a second CFR, and the second CFR is the CFR used by the first type of terminal equipment (another RedCap UE: corresponding to the second type of RedCap UE), and the second CFR is independent of the first CFR. Here, the first type of terminal in the art indicates the RedCap UE, but as described in Paragraphs [0088] and [0089], the RedCap UEs having different configuration (bandwidth capability) are considered as different type of RedCap UE. Among them, the bandwidth value of the second CFR does not exceed the maximum bandwidth supported by the first type of terminal equipment (the second RedCap UE), and the second CFR can be configured by an additional field in SIB20, or configured through other SIBs. The second CFR can be a CFR dedicated to REDCAP terminal equipment configured by the network device, and the bandwidth of the above-mentioned second CFR is less than or equal to the maximum channel bandwidth supported by the REDCAP terminal equipment. Thus, since the first maximum bandwidth of the first RedCap UE is the bandwidth of CORESET#0 and the second maximum bandwidth of the second RedCap UE is the maximum channel bandwidth, the first maximum bandwidth of the first RedCap UE is less than one of the second RedCap UE and two CFRs are independent. It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine Zhang and Sha to include the technique of wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth of Sha in the system of Zhang provide a communication method and device, which can ensure the continuity of MBS services and improve communication quality (Sha, see Page 2, Lines, 15-16 ).). Regarding claim 2, combination of Zhang and Sha teaches the features defined in the claims 1, -refer to the indicated claim for reference(s). Zhang further teaches that wherein the a second CFR is associated with at least one of the MCCH or the MTCH for the second type RedCap UE (Zhang, in Page 13, Lines 1-11, in Page 17, Lines 12-41, and in Page 18, Lines 1-21, teaches that the first type of terminal may include a reduced capability (RedCap) terminal and/or an enhanced RedCap (eRedCap) terminal. The baseband bandwidth for the physical downlink shared channel (PDSCH) and physical uplink shared channel (PUSCH) is only supported at 5 megahertz (MHz). The radio frequency (RF) bandwidth for uplink (UL) and downlink (DL) is 20MHz. For RedCap terminal or eRedCap terminal, the maximum bandwidth of the RedCap terminal in frequency range 1 (frequency range 1, FR1) is 20 MHz, and the maximum bandwidth in frequency range 2 (frequency range 2, FR2) is 100 MHz. Based on this observation, RedCap or eRedCap terminal can have three different capabilities to support the three different maximum bandwidths (5 MHz, 20MHz, or 100MHz), respectively. Further, when for RedCap or eRedCap terminal, the first capability may support to the first maximum bandwidth 5 MHz, the second capability may support the second maximum bandwidth 100 MHz, and the third capability may support to the third maximum bandwidth 20 MHz, the third capability having a third maximum bandwidth 20 MHz that is greater than the first maximum bandwidth (5 MHz) and less than the second maximum bandwidth (100 MHz). Since CFR can be understood as the frequency range as described in the above, the first CFR supporting the third capability is different from the second CFR (100 MHz). MCCH messages and broadcast services are transmitted in CFR, where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Therefore, it is clear that the CFR is a first CFR that is different from a second CFR associated with at least one of the MCCH or the MTCH for one or more RedCap UEs supporting a third capability having a third maximum bandwidth that is greater than the first maximum bandwidth and less than the second maximum bandwidth.) Regarding claim 3, combination of Zhang and Sha teaches the features defined in the claims 1, -refer to the indicated claim for reference(s). Zhang further teaches wherein different CFRs are associated with different types of RedCap UEs supporting the first maximum bandwidth (Zhang, in Page 13, Lines 1-11, teaches that the first type of terminal may include a reduced capability (RedCap) terminal and/or an enhanced RedCap (eRedCap) terminal. The baseband bandwidth for the physical downlink shared channel (PDSCH) and physical uplink shared channel (PUSCH) is only supported at 5 megahertz (MHz). The radio frequency (RF) bandwidth for uplink (UL) and downlink (DL) is 20MHz. For RedCap terminal or eRedCap terminal, the maximum bandwidth of the RedCap terminal in frequency range 1 (frequency range 1, FR1) is 20 MHz, and the maximum bandwidth in frequency range 2 (frequency range 2, FR2) is 100 MHz. Based on this observation, RedCap or eRedCap terminal can have three different capabilities to support the three different maximum bandwidths (5 MHz, 20MHz, or 100MHz), respectively. Further, when for RedCap or eRedCap terminal, the capability may support to the first maximum bandwidth 5 MHz, the second capability may support the second maximum bandwidth 100 MHz, and the third capability may support to the third maximum bandwidth 20 MHz. Since CFR can be understood as the frequency range as described in the above, different CFRs are associated with different type of RedCap UEs (RedCap UE or eRedCap UE) and the first capability of each type of RedCap UE may be different, according to its affordable maximum bandwidth.) Regarding claim 4, combination of Zhang and Sha teaches the features defined in the claims 1, -refer to the indicated claim for reference(s). Zhang further teaches wherein the CFR is further associated with at least one of the MCCH or the MTCH for multiple types of RedCap UEs (Zhang, in Page 18, Lines 3-12, teaches that MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. Based on this observation, the CFR is associated with one of the MCCH or the MTCH for multiple types of RedCap UE, according to the capability of each type of RedCap UE.) Regarding claim 5, combination of Zhang and Sha teaches the features defined in the claims 4, -refer to the indicated claim for reference(s). Zhang further teaches wherein the at least one processor, individually or in any combination, is further configured to: skip decoding of a physical downlink shared channel (PDSCH) communication based on the PDSCH communication having frequency resources spanning more than the first maximum bandwidth (Zhang, in Page 18, Lines 3-7 and in Page 27, Lines 16-23, teaches that MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The first information may implicitly indicate whether the first cell supports providing broadcast services to the first terminal. For example, the first information may be the size of the CFR configured by the network device. When the CFR is greater than the maximum operating bandwidth of the first terminal, the first information indicates that the first cell does not support providing broadcast services to the first terminal; when the CFR is less than or equal to the maximum operating bandwidth of the first terminal, the first information indicates that the first cell supports providing broadcast services to the first terminal. Based on this observation, since when the CFR is greater than the maximum bandwidth of the terminal, the terminal receives the indication that the first cell does not support providing broadcasting service (including PDSCH) and skip the decoding of the corresponding PDSCH at the terminal.) Regarding claim 6, combination of Zhang and Sha teaches the features defined in the claims 1, -refer to the indicated claim for reference(s). Zhang further teaches wherein the at least one processor, individually or in any combination, is further configured to receive the first indication in a system information block (SIB) (Zhang, in Page 17, Lines 29-41, teaches that MCCH messages are transmitted periodically, and their configuration information is carried in the system information block (SIB), such as SIB20. For example, SIB20 may include MCCH configuration information (located in the cell mcch-Config) and common frequency resources (CFR) (located in the cell cfr-ConfigMCCH-MTCH). The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. Further, CFR is a continuous frequency domain resource, which can be defined by a starting position and a bandwidth size. CFR is used to transmit MBS services. Exemplarily, CFR can be: control resource set (CORESET) 0 (i.e., CORESET0), SIB1 configured bandwidth (such as initial part bandwidth (bandwidth part, BWP)), or a separately configured bandwidth larger than the SIB1 configured bandwidth. Based on this observation, it is clear that the first indication is received through a system information block (SIB).) Regarding claim 7, combination of Zhang and Sha teaches the features defined in the claims 1, -refer to the indicated claim for reference(s). Zhang further teaches receive a first MCCH configuration for the first type of RedCap UE that is different from a second MCCH configuration for the second type of RedCap UE wherein the first MCCH configuration specifies at least one of a first periodicity of MCCH resources or a first offset associated with the MCCH that is different from a second periodicity of MCCH resources or a second offset associated specified by the second MCCH configuration (Zhang, in Page 17, Lines 33-36, in Page 18, Lines 16-21, and in Page 25, Lines 13-29, teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. The terminal first receives the SIB and obtains the configuration information of the MCCH from the SIB. After that, the MCCH message is received according to the configuration information of the MCCH, and the content of the MCCH message is read to obtain the configuration information of the MTCH carried by the MCCH. Finally, the data of the broadcast service is received according to the configuration information of the MTCH. Further, the network device may perform MCCH configuration and/or CFR configuration for the first terminal and the second terminal respectively. Exemplarily, the system message of the first cell may include the following information: {mcch-Config# is used to configure MCCH for the second terminal; cfr-ConfigMCCH-MTCH# is used to configure CFR for the second terminal; … mcch-ConfigRedCap# is used to configure MCCH for the first terminal; cfr-ConfigMCCH-MTCH-RedCap# is used to configure CFR for the first terminal;} Based on this observation, each terminal may be performed by the network device MCCH configuration and/or CFR configuration, where each MCCH configuration for each terminal may have different parameter based on its own mcch-Config such as the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc.) Regarding claim 9, combination of Zhang and Sha teaches the features defined in the claims 1, -refer to the indicated claim for reference(s). Zhang further teaches receive a configuration of the first list of neighbor cells with a first set of one or more ongoing multicast or broadcast communication sessions associated with a first type of RedCap UE that is different from a second list of neighbor cells with a second set of one or more ongoing multicast or broadcast communication sessions associated with the second type of RedCap UE (Zhang, in Page 19, Lines 11-27, teaches that as shown in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. For the terminal, if the configuration information of MTCH indicates that a certain neighboring cell provides a broadcast service that the terminal is receiving or interested in, then the terminal can receive the broadcast service after moving or reselecting to the cell. If the configuration information of MTCH indicates that a certain neighboring cell does not provide a broadcast service that the terminal is receiving or interested in, then the terminal can trigger the establishment of a unicast session before/after moving or reselecting to the cell to receive the broadcast service. In addition to the neighbor service indication, the network device can also configure the MBS broadcast neighbor cell list (MBS Broadcast Neighbour Cell List) at the cell granularity. The MBS broadcast neighbor cell list indicates the neighbor cells that provide one or more broadcast services provided by the cell through broadcast MRB. Among them, the first cell in the MBS broadcast neighbor cell list is the neighbor cell corresponding to the first bit in mtch-NeighbourCell, the second cell is the neighbor cell corresponding to the second cell in mtch-NeighbourCell, and so on. Further, in Page 39, Lines 8-38 and in Page 40, Lines, the examples of MBS Broadcast Neighbor Cell List, including mtch-NeighboutCell (neighbour cell list), for the first type of terminal (RedCap UE or eRedCap UE terminal) and the second type of terminal (the enhanced mobile broadband (eMBB) terminal) are shown. Based on this, according to different mtch-neighbor cell configuration or MBS Broadcast Neighbor Cell list, the network node may configure the temporary multicast group identifier (TMGI) for the neighbor cells for each different type of RedCap terminal to provide broadcast services based on TMGI. Therefore, it is clear that each RedCap UE receives the different configuration of a neighbor cell list with a set of one or more ongoing multicast or broadcast communication sessions associated with its type, respectively.) Regarding claim 10, combination of Zhang and Sha teaches the features defined in the claims 1, -refer to the indicated claim for reference(s). Zhang further teaches receive a second indication of a first list of ongoing multicast or broadcast communication sessions associated with a first group radio network temporary identifier (G-RNTI) associated with the MTCH for the first type of RedCap UE that is different from a second list of ongoing multicast or broadcast communication sessions associated with a second G-RNTI associated with the MTCH for the second type of RedCap UE (Zhang, in Page 18, Lines 3-31,teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. Exemplarily, the configuration information of MTCH may include G-RNTI, discontinuous reception (DRX) parameters, TMGI, physical downlink shared channel (PDSCH) configuration corresponding to MTCH, etc. For example, as shown in FIG6 , the transmission process of the broadcast service from the MBS server to the terminal is shown. Before transmitting the service, the MBS server can send information to the core network device to indicate the start of the broadcast session. Correspondingly, the core network device indicates the start of the broadcast session to the base station. After receiving the indication, the base station sends a response to the core network device and sends the configuration information of the MTCH through the MCCH. Subsequently, the broadcast service 1 and the data of broadcast service 2 is sent from the MBS server to the core network device, and then from the core network device to the base station. The base station sends the data of broadcast service 1 and broadcast service 2 to the terminal through MTCH 1 and MTCH 2 respectively. Further, in Page 26, Lines 4-16, for the first cell supporting a broadcast service provided to the first terminal, the network device may schedule the broadcast service on the same PDSCH resource for the first terminal and the second terminal, or may schedule the broadcast service on different PDSCH resources for the first terminal and the second terminal respectively. Exemplarily, taking the case where the first cell supports providing broadcast service 1 and broadcast service 2 to the first terminal, but does not support providing broadcast service 3 to the first terminal as an example, as shown in FIG8 , the network device can schedule broadcast service 1 on different PDSCH resources for the first terminal and the second terminal respectively (represented by MTCH1 and MTCH2 in FIG8 , respectively), and schedule broadcast service 2 for the first terminal and the second terminal on the same PDSCH resource (represented by MTCH1 in FIG8 ). In addition, the network device schedules broadcast service 3 for the second terminal in a wider frequency domain resource/CORESET#2. Based on this observation, the network node may configure for each different type of terminal (RedCap, eRedCap or non-RedCap) the different broadcast service lists with different G-RNTI associated different MTCH.) Regarding claim 11, combination of Zhang and Sha teaches the features defined in the claims 10, -refer to the indicated claim for reference(s). Zhang further teaches wherein a physical downlink shared channel (PDSCH) communication scheduled by a physical downlink control channel (PDCCH) associated with at least one of the G-RNTI or a MCCH-RNTI associated with the MTCH for the first type of RedCap UE is associated with a set of physical resource blocks spanning fewer than 5 MHz (Zhang, in Page 29, Lines 13-19, teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. The physical resource block (PRB) where the PDSCH corresponding to the MCCH message or broadcast service sent by the network device is located can be described relative to the position of the CFR, and the first terminal or the second terminal needs to determine the position of the PDSCH according to the position of the CFR, such as determining the starting PRB and the number of PRBs of the PDSCH. The number of PRBs indicates the length of the allocated continuous PRBs, or the number of PRBs indicates the length or size of the frequency domain resources occupied by the PDSCH. PRB can also be replaced by RB. If the RedCap UE is eRedCap UE, a set of PRB spanning fewer than 5 MHz can be supported. Further, in Page 18, Lines 3-15, MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. Exemplarily, the configuration information of MTCH may include G-RNTI, discontinuous reception (DRX) parameters, TMGI, physical downlink shared channel (PDSCH) configuration corresponding to MTCH, etc. Based on this observation, it is clear that a physical downlink shared channel (PDSCH) communication scheduled by a physical downlink control channel (PDCCH) associated with at least one of the G-RNTI or a MCCH-RNTI associated with the MTCH for the plurality of RedCap UEs is associated with a set of physical resource blocks spanning fewer than 5 MHz.) Regarding claim 12, combination of Zhang and Sha teaches the features defined in the claims 10, -refer to the indicated claim for reference(s). Zhang further teaches receive a third indication of a first MTCH neighbor cell configuration for the first G-RNTI that is different from a second MTCH neighbor cell configuration for the second G-RNTI (Zhang, in Page 18, Lines 3-15, teaches that MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. The configuration information of MTCH may include G-RNTI, discontinuous reception (DRX) parameters, TMGI, physical downlink shared channel (PDSCH) configuration corresponding to MTCH, etc. Further, in Page 39 and in Page 40, Lines 1-20, Zhang teaches that each MBS Broadcast Neighbor Cell list can have its own mtch-neighborCell (neighbor cell list: can be considered as third indication) configuration that is represented by its own TMGI configuration based on its MTCH with G- RNTI corresponding to the broadcast service, respectively. Therefore, it is clear that a third indication of a first MTCH neighbor cell configuration is received for the first G-RNTI that is different from a second MTCH neighbor cell configuration for the second G-RNTI.) Regarding claim 13, combination of Zhang and Sha teaches the features defined in the claims 1, -refer to the indicated claim for reference(s). Zhang further teaches receive a first discontinuous reception (DRX) configuration associated with the first type of RedCap UE that is different from a second DRX configuration for the second type of RedCap UE (Zhang, in Page 18, Lines 3-15, teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. The configuration information of MTCH may include G-RNTI, discontinuous reception (DRX) parameters, TMGI, physical downlink shared channel (PDSCH) configuration corresponding to MTCH, etc. Based on this observation, it is clear that, since based on the CFR, the configuration information of MTCH corresponding to the broadcast service determines the DRX configuration, the DRX configuration for each type of RedCap UE can be different, if the different broadcast service is provided to each type of RedCap UE.) Regarding claim 14, combination of Zhang and Sha teaches the features defined in the claims 13, -refer to the indicated claim for reference(s). Zhang further teaches monitor, based on the first DRX configuration, physical downlink shared channel (PDSCH) occasions limited to a span of 5 MHz (Zhang, in Page 18, Lines 3-15, teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR and if the type of RedCap UE is the eRedCap UE with 5 MHz maximum bandwidth, the PDSCH occasions may be limited to a span of 5 MHz, due to its PRB. Further, MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. The configuration information of MTCH may include G-RNTI, discontinuous reception (DRX) parameters, TMGI, physical downlink shared channel (PDSCH) configuration corresponding to MTCH, etc. According that in Page 17, Lines 33-36, the configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH, MCCH is monitored periodically. Since the PDSCH occasions based on DRX is configured, according to the MTCH that is included MCCH message, the PDSCH occasions based on DRX is monitored periodically, according to scheduling of the MCCH message.) Regarding claim 15, Zhang teaches that an apparatus for wireless communication at network device, comprising: at least one memory; and at least one processor coupled to the at least one memory and, based at least in part on information stored in the at least one memory, the at least one processor, individually or in any combination, is configured to: (Zhang, in Fig. 2 and in Page 15, Lines 14-22, teaches that as shown in FIG. 2, the communication device 200 includes at least one processor 201 and at least one communication interface (FIG. 2 is merely an example of a communication interface 204 and a processor 201). Optionally, the communication device 200 may further include a communication bus 202 and a memory 203. The processor 201 may be a general-purpose central processing unit (CPU), a general-purpose processor, a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof. The processor 201 may also be other devices with processing functions, such as circuits, devices, or software modules, without limitation. Therefore, it is clear that an apparatus at a network device comprises a processor coupled to a memory in which the information is stored) output, for transmission to a first type of reduced capability (RedCap) user equipment (UE) in one of an inactive or idle state, a first indication of a first common frequency resource (CFR) associated with at least one of a multicast control channel (MCCH) or a multicast traffic channel (MTCH) for the first type of RedCap UE; (Zhang, in Page 13, Lines 1-3, in Page 17, Lines 12-41, and in Page 18, Lines 1-21, teaches that the first type of terminal may include a reduced capability (RedCap) terminal and/or an enhanced RedCap (eRedCap) terminal. When the network provides broadcast services, the terminals receive them autonomously according to the configuration information. Broadcast services can be provided to terminals in any radio resource control (RRC) state that include RRC idle or inactive state. For broadcast services, two logical channels are introduced in the NR system: MBS control channel (MCCH) and MBS traffic channel (MTCH). At the physical layer, MCCH messages and broadcast services are carried in PDSCH. MCCH messages are transmitted periodically, and their configuration information is carried in the system information block (SIB), such as SIB20. For example, SIB20 may include MCCH configuration information (located in the cell mcch-Config) and common frequency resources (CFR) (located in the cell cfr-ConfigMCCH-MTCH). The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. From this, it can be considered as the first indication of CFR. CFR is a continuous frequency domain resource, which can be defined by a starting position and a bandwidth size. CFR is used to transmit MBS services. CFR can be: control resource set (CORESET) 0 (i.e., CORESET0), SIB1 configured bandwidth (such as initial part bandwidth (bandwidth part, BWP)), or a separately configured bandwidth larger than the SIB1 configured bandwidth. It is alternative first indication of CFR. MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. Based on this observation, it is clear that a first indication of a common frequency resource (CFR) associated with at least one of a multicast control channel (MCCH) or a multicast traffic channel (MTCH) for a plurality of reduced capability (RedCap) UEs in one of an inactive or idle state is transmitted.) wherein the second maximum bandwidth is less than a third maximum bandwidth that is supported by a third type of non-RedCap UE (Zhang, in Page 12, Lines 31 - Page 13, Lines 3, teaches that the first type of terminal (it is corresponding to the second type of RedCap UE) may include a reduced capability (RedCap) terminal (or UE) and/or an enhanced RedCap (eRedCap) terminal and the second type of terminal may be an enhanced mobile broadband (eMBB) terminal (it is corresponding to a third type of non-RedCap UE: a non-RedCap terminal or a normal terminal). The first terminal belongs to the first type of terminal, and the second terminal belongs to the second type of terminal. The features of the first terminal are considered as the features of the first type of terminal and the features of the second terminal are considered as the features of the second type of terminal. The maximum operating bandwidth of the first terminal (the second type RedCap UE) is less than the maximum operating bandwidth of the second terminal (third type of non-RedCap UE), or the maximum operating bandwidth of the second terminal is greater than the maximum operating bandwidth of the first terminal, or the second terminal device is a normal terminal or a non-capability-reduced terminal or a normal terminal. Thus, it is clear that the maximum bandwidth of RedCap UE (the first type or the second type) is less than the maximum bandwidth of non-RedCap UE (the third type of non-RedCap UE).) and output, for transmission to the first type of RedCap UE, at least one of an MCCH communication or an MTCH communication via the first CFR indicated in the first indication for at least one of broadcast traffic or multicast traffic (Zhang, in Page 17, Lines 29-36, teaches that MCCH messages are transmitted periodically, and their configuration information is carried in the system information block (SIB), such as SIB20. For example, SIB20 may include MCCH configuration information (located in the cell mcch-Config) and common frequency resources (CFR) (located in the cell cfr-ConfigMCCH-MTCH). The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. Based on this observation, the MCCH message are transmitted periodically for broadcast service with configuration information including CFR configuration information, to monitor MCCH and the associated CFR. Therefore, it is clear that based on the MCCH message, the CFR indicated in the first indication for at least one of broadcast traffic or multicast traffic is transmitted, periodically.) However, Zhang does not explicitly teach that wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth. Sha teaches that wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth (Sha, in Page 30, Lines 20-34 and in Page 32, Lines 3-17, teaches that for a terminal device in an RRC non-connected state, when a multicast session is in a deactivated state, the network device needs to notify the terminal device so that the terminal device stops receiving the multicast session. To indicate this, an MCCH message is sent to the terminal device, and the deactivated state of the multicast session is indicated through the MCCH message, which will cause energy consumption overhead of the terminal device and increase the burden on the network side. Thus, as described in Page 33, Lines 10-25, the RedCap terminal (UE) is supported by the cell to provide MBS (multicast broadcast services). For this, two different CFRs are configured for two different RedCap UE. For the first RedCap terminal, the bandwidth value of the first common frequency resource CFR configured by SIB20 of the first cell does not exceed the first bandwidth value. Among them, the first bandwidth value can be the maximum bandwidth supported by the terminal equipment. If the first CFR configured by SIB20 is default, the bandwidth value of the first CFR is equal to the bandwidth of control resource set 0 (CORESET#0), and CORESET#0 is configured by SIB1. Alternatively, the first cell configures a second CFR, and the second CFR is the CFR used by the first type of terminal equipment (another RedCap UE: corresponding to the second type of RedCap UE), and the second CFR is independent of the first CFR. Here, the first type of terminal in the art indicates the RedCap UE, but as described in Paragraphs [0088] and [0089], the RedCap UEs having different configuration (bandwidth capability) are considered as different type of RedCap UE. Among them, the bandwidth value of the second CFR does not exceed the maximum bandwidth supported by the first type of terminal equipment (the second RedCap UE), and the second CFR can be configured by an additional field in SIB20, or configured through other SIBs. The second CFR can be a CFR dedicated to REDCAP terminal equipment configured by the network device, and the bandwidth of the above-mentioned second CFR is less than or equal to the maximum channel bandwidth supported by the REDCAP terminal equipment. Thus, since the first maximum bandwidth of the first RedCap UE is the bandwidth of CORESET#0 and the second maximum bandwidth of the second RedCap UE is the maximum channel bandwidth, the first maximum bandwidth of the first RedCap UE is less than one of the second RedCap UE and two CFRs are independent. It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine Zhang and Sha to include the technique of wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth of Sha in the system of Zhang provide a communication method and device, which can ensure the continuity of MBS services and improve communication quality (Sha, see Page 2, Lines, 15-16 ).). Regarding claim 16, combination of Zhang and Sha teaches the features defined in the claims 15, -refer to the indicated claim for reference(s). Zhang further teaches that wherein the second CFR is associated with at least one of the MCCH or the MTCH for the second type of RedCap UE (Zhang, in Page 13, Lines 1-11, in Page 17, Lines 12-41, and in Page 18, Lines 1-21, teaches that the first type of terminal may include a reduced capability (RedCap) terminal and/or an enhanced RedCap (eRedCap) terminal. The baseband bandwidth for the physical downlink shared channel (PDSCH) and physical uplink shared channel (PUSCH) is only supported at 5 megahertz (MHz). The radio frequency (RF) bandwidth for uplink (UL) and downlink (DL) is 20MHz. For RedCap terminal or eRedCap terminal, the maximum bandwidth of the RedCap terminal in frequency range 1 (frequency range 1, FR1) is 20 MHz, and the maximum bandwidth in frequency range 2 (frequency range 2, FR2) is 100 MHz. Based on this observation, RedCap or eRedCap terminal can have three different capabilities to support the three different maximum bandwidths (5 MHz, 20MHz, or 100MHz), respectively. Further, when for RedCap or eRedCap terminal, the first capability may support to the first maximum bandwidth 5 MHz, the second capability may support the second maximum bandwidth 100 MHz, and the third capability may support to the third maximum bandwidth 20 MHz, the third capability having a third maximum bandwidth 20 MHz that is greater than the first maximum bandwidth (5 MHz) and less than the second maximum bandwidth (100 MHz). Since CFR can be understood as the frequency range as described in the above, the first CFR supporting the third capability is different from the second CFR (100 MHz). MCCH messages and broadcast services are transmitted in CFR, where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Therefore, it is clear that the CFR is a first CFR that is different from a second CFR associated with at least one of the MCCH or the MTCH for one or more RedCap UEs supporting a third capability having a third maximum bandwidth that is greater than the first maximum bandwidth and less than the second maximum bandwidth.) Regarding claim 17, combination of Zhang and Sha teaches the features defined in the claims 15, -refer to the indicated claim for reference(s). Zhang further teaches wherein different CFRs are associated with different types of RedCap UEs supporting the first maximum bandwidth (Zhang, in Page 13, Lines 1-11, , teaches that the first type of terminal may include a reduced capability (RedCap) terminal and/or an enhanced RedCap (eRedCap) terminal. The baseband bandwidth for the physical downlink shared channel (PDSCH) and physical uplink shared channel (PUSCH) is only supported at 5 megahertz (MHz). The radio frequency (RF) bandwidth for uplink (UL) and downlink (DL) is 20MHz. For RedCap terminal or eRedCap terminal, the maximum bandwidth of the RedCap terminal in frequency range 1 (frequency range 1, FR1) is 20 MHz, and the maximum bandwidth in frequency range 2 (frequency range 2, FR2) is 100 MHz. Based on this observation, RedCap or eRedCap terminal can have three different capabilities to support the three different maximum bandwidths (5 MHz, 20MHz, or 100MHz), respectively. Further, when for RedCap or eRedCap terminal, the capability may support to the first maximum bandwidth 5 MHz, the second capability may support the second maximum bandwidth 100 MHz, and the third capability may support to the third maximum bandwidth 20 MHz. Since CFR can be understood as the frequency range as described in the above, different CFRs are associated with different type of RedCap UEs (RedCap UE or eRedCap UE) and the first capability of each type of RedCap UE may be different, according to its affordable maximum bandwidth.) Regarding claim 18, combination of Zhang and Sha teaches the features defined in the claims 15, -refer to the indicated claim for reference(s). Zhang further teaches wherein the first CFR is further associated with at least one of the MCCH or the MTCH for multiple types of RedCap UEs (Zhang, in Page 18, Lines 3-12, teaches that MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. Based on this observation, the CFR is associated with one of the MCCH or the MTCH for multiple types of RedCap UE, according to the capability of each type of RedCap UE.) Regarding claim 19, combination of Zhang and Sha teaches the features defined in the claims 15, -refer to the indicated claim for reference(s). Zhang further teaches wherein the first indication is comprised in a system information block (SIB) (Zhang, in Page 17, Lines 29-41, teaches that MCCH messages are transmitted periodically, and their configuration information is carried in the system information block (SIB), such as SIB20. For example, SIB20 may include MCCH configuration information (located in the cell mcch-Config) and common frequency resources (CFR) (located in the cell cfr-ConfigMCCH-MTCH). The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. Further, CFR is a continuous frequency domain resource, which can be defined by a starting position and a bandwidth size. CFR is used to transmit MBS services. Exemplarily, CFR can be: control resource set (CORESET) 0 (i.e., CORESET0), SIB1 configured bandwidth (such as initial part bandwidth (bandwidth part, BWP)), or a separately configured bandwidth larger than the SIB1 configured bandwidth. Based on this observation, it is clear that the first indication is received through a system information block (SIB).) Regarding claim 20, combination of Zhang and Sha teaches the features defined in the claims 15, -refer to the indicated claim for reference(s). Zhang further teaches output, for transmission to the first type of RedCap UE, a first MCCH configuration for the first type of RedCap UE that is different from a second MCCH configuration for the second type of RedCap UE wherein the first MCCH configuration specifies at least one of a first periodicity of MCCH resources or a first offset associated with the MCCH that is different from a second periodicity of MCCH resources or a second offset associated specified by the second MCCH configuration (Zhang, in Page 17, Lines 33-36, in Page 18, Lines 16-21, and in Page 25, Lines 13-29, teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. The network node first transmits the SIB and obtains the configuration information of the MCCH from the SIB. After that, the MCCH message is transmitted according to the configuration information of the MCCH, and the content of the MCCH message is read to obtain the configuration information of the MTCH carried by the MCCH. Finally, the data of the broadcast service is transmitted according to the configuration information of the MTCH. Further, the network device may perform MCCH configuration and/or CFR configuration for the first terminal and the second terminal respectively. Exemplarily, the system message of the first cell may include the following information: {mcch-Config# is used to configure MCCH for the second terminal; cfr-ConfigMCCH-MTCH# is used to configure CFR for the second terminal; … mcch-ConfigRedCap# is used to configure MCCH for the first terminal; cfr-ConfigMCCH-MTCH-RedCap# is used to configure CFR for the first terminal;} Based on this observation, it is clear that each terminal may be performed by the network device MCCH configuration and/or CFR configuration, where each MCCH configuration for each terminal may have different parameter based on its own mcch-Config such as the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc.) Regarding claim 22, combination of Zhang and Sha teaches the features defined in the claims 15, -refer to the indicated claim for reference(s). Zhang further teaches output, for transmission to the first type of RedCap UE, a configuration of a first list of neighbor cells with a first set of one or more ongoing multicast or broadcast communication sessions associated with the first type of RedCap UE that is different from a second list of neighbor cells with a second set of one or more ongoing multicast or broadcast communication sessions associated with the second type of RedCap UE (Zhang, in Page 19, Lines 11-27, teaches that as shown in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. For the terminal, if the configuration information of MTCH indicates that a certain neighboring cell provides a broadcast service that the terminal is receiving or interested in, then the terminal can receive the broadcast service after moving or reselecting to the cell. If the configuration information of MTCH indicates that a certain neighboring cell does not provide a broadcast service that the terminal is receiving or interested in, then the terminal can trigger the establishment of a unicast session before/after moving or reselecting to the cell to receive the broadcast service. In addition to the neighbor service indication, the network device can also configure the MBS broadcast neighbor cell list (MBS Broadcast Neighbour Cell List) at the cell granularity. The MBS broadcast neighbor cell list indicates the neighbor cells that provide one or more broadcast services provided by the cell through broadcast MRB. Among them, the first cell in the MBS broadcast neighbor cell list is the neighbor cell corresponding to the first bit in mtch-NeighbourCell, the second cell is the neighbor cell corresponding to the second cell in mtch-NeighbourCell, and so on. Further, in Page 39, Lines 8-38 and in Page 40, Lines, the examples of MBS Broadcast Neighbor Cell List, including mtch-NeighboutCell (neighbour cell list), for the first type of terminal (RedCap UE or eRedCap UE terminal) and the second type of terminal (the enhanced mobile broadband (eMBB) terminal) are shown. Based on this, according to different mtch-neighbor cell configuration or MBS Broadcast Neighbor Cell list, the network node may configure the temporary multicast group identifier (TMGI) for the neighbor cells for each different type of RedCap terminal to provide broadcast services based on TMGI. Therefore, it is clear that the network node transmits to each RedCap UE, the different configuration of a neighbor cell list with a set of one or more ongoing multicast or broadcast communication sessions associated with its type, respectively.) Regarding claim 23, combination of Zhang and Sha teaches the features defined in the claims 15, -refer to the indicated claim for reference(s). Zhang further teaches output, for transmission to the first type of RedCap UE, a second indication of a first list of ongoing multicast or broadcast communication sessions associated with a first group radio network temporary identifier (G-RNTI) associated with the MTCH for the first type of RedCap UE that is different from a second list of ongoing multicast or broadcast communication sessions associated with a second G-RNTI associated with the MTCH for the second type of RedCap UE (Zhang, in Page 18, Lines 3-31,teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. Exemplarily, the configuration information of MTCH may include G-RNTI, discontinuous reception (DRX) parameters, TMGI, physical downlink shared channel (PDSCH) configuration corresponding to MTCH, etc. For example, as shown in FIG6 , the transmission process of the broadcast service from the MBS server to the terminal is shown. Before transmitting the service, the MBS server can send information to the core network device to indicate the start of the broadcast session. Correspondingly, the core network device indicates the start of the broadcast session to the base station. After receiving the indication, the base station sends a response to the core network device and sends the configuration information of the MTCH through the MCCH. Subsequently, the broadcast service 1 and the data of broadcast service 2 is sent from the MBS server to the core network device, and then from the core network device to the base station. The base station sends the data of broadcast service 1 and broadcast service 2 to the terminal through MTCH 1 and MTCH 2 respectively. Further, in Page 26, Lines 4-16, for the first cell supporting a broadcast service provided to the first terminal, the network device may schedule the broadcast service on the same PDSCH resource for the first terminal and the second terminal, or may schedule the broadcast service on different PDSCH resources for the first terminal and the second terminal respectively. Exemplarily, taking the case where the first cell supports providing broadcast service 1 and broadcast service 2 to the first terminal, but does not support providing broadcast service 3 to the first terminal as an example, as shown in FIG8 , the network device can schedule broadcast service 1 on different PDSCH resources for the first terminal and the second terminal respectively (represented by MTCH1 and MTCH2 in FIG8 , respectively), and schedule broadcast service 2 for the first terminal and the second terminal on the same PDSCH resource (represented by MTCH1 in FIG8 ). In addition, the network device schedules broadcast service 3 for the second terminal in a wider frequency domain resource/CORESET#2. Based on this observation, the network node may configure for each different type of terminal (RedCap, eRedCap or non-RedCap) the different broadcast service lists with different G-RNTI associated different MTCH.) Regarding claim 24, combination of Zhang and Sha teaches the features defined in the claims 23, -refer to the indicated claim for reference(s). Zhang further teaches output, for transmission to the first type of RedCap UE, a third indication of a first MTCH neighbor cell configuration for the first G-RNTI that is different from a second MTCH neighbor cell configuration for the second G-RNTI (Zhang, in Page 18, Lines 3-15, teaches that MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. The configuration information of MTCH may include G-RNTI, discontinuous reception (DRX) parameters, TMGI, physical downlink shared channel (PDSCH) configuration corresponding to MTCH, etc. Further, in Page 39 and in Page 40, Lines 1-20, Zhang teaches that each MBS Broadcast Neighbor Cell list can have its own mtch-neighborCell (neighbor cell list: can be considered as third indication) configuration that is represented by its own TMGI configuration based on its MTCH with G-RNTI corresponding to the broadcast service, respectively. Therefore, it is clear that a third indication of a first MTCH neighbor cell configuration is transmitted for the first G-RNTI that is different from a second MTCH neighbor cell configuration for the second G-RNTI.) Regarding claim 25, combination of Zhang and Sha teaches the features defined in the claims 15, -refer to the indicated claim for reference(s). Zhang further teaches output, for transmission to the first type of RedCap UE, a first discontinuous reception (DRX) configuration associated with the first type of RedCap UE that is different from a second DRX configuration for the second type of RedCap UE (Zhang, in Page 18, Lines 3-15, teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. The configuration information of MTCH may include G-RNTI, discontinuous reception (DRX) parameters, TMGI, physical downlink shared channel (PDSCH) configuration corresponding to MTCH, etc. Based on this observation, it is clear that, since based on the CFR, the configuration information of MTCH corresponding to the broadcast service determines the DRX configuration, the DRX configuration for each type of RedCap UE can be different, if the different broadcast service is provided to each type of RedCap UE.) Regarding claim 26, Zhang teaches that a method for wireless communication at a wireless device (UE), comprising: receiving a first indication of a first common frequency resource (CFR) associated with at least one of a multicast control channel (MCCH) or a multicast traffic channel (MTCH) for a first type of reduced capability (RedCap) UE in one of an inactive or idle state (Zhang, in Page 13, Lines 1-3, in Page 17, Lines 12-41, and in Page 18, Lines 1-21, teaches that the first type of terminal may include a reduced capability (RedCap) terminal and/or an enhanced RedCap (eRedCap) terminal. When the network provides broadcast services, the terminals receive them autonomously according to the configuration information. Broadcast services can be provided to terminals in any radio resource control (RRC) state that include RRC idle or inactive state. For broadcast services, two logical channels are introduced in the NR system: MBS control channel (MCCH) and MBS traffic channel (MTCH). At the physical layer, MCCH messages and broadcast services are carried in PDSCH. MCCH messages are transmitted periodically, and their configuration information is carried in the system information block (SIB), such as SIB20. For example, SIB20 may include MCCH configuration information (located in the cell mcch-Config) and common frequency resources (CFR) (located in the cell cfr-ConfigMCCH-MTCH). The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. From this, it can be considered as the first indication of CFR. CFR is a continuous frequency domain resource, which can be defined by a starting position and a bandwidth size. CFR is used to transmit MBS services. CFR can be: control resource set (CORESET) 0 (i.e., CORESET0), SIB1 configured bandwidth (such as initial part bandwidth (bandwidth part, BWP)), or a separately configured bandwidth larger than the SIB1 configured bandwidth. It is alternative first indication of CFR. MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. Based on this observation, it is clear that a first indication of a common frequency resource (CFR) associated with at least one of a multicast control channel (MCCH) or a multicast traffic channel (MTCH) for a plurality of reduced capability (RedCap) UEs in one of an inactive or idle state is received.) wherein the second maximum bandwidth is less than a third maximum bandwidth that is supported by a third type of non-RedCap UE (Zhang, in Page 12, Lines 31 - Page 13, Lines 3, teaches that the first type of terminal (it is corresponding to the second type of RedCap UE) may include a reduced capability (RedCap) terminal (or UE) and/or an enhanced RedCap (eRedCap) terminal and the second type of terminal may be an enhanced mobile broadband (eMBB) terminal (it is corresponding to a third type of non-RedCap UE: a non-RedCap terminal or a normal terminal). The first terminal belongs to the first type of terminal, and the second terminal belongs to the second type of terminal. The features of the first terminal are considered as the features of the first type of terminal and the features of the second terminal are considered as the features of the second type of terminal. The maximum operating bandwidth of the first terminal (the second type RedCap UE) is less than the maximum operating bandwidth of the second terminal (third type of non-RedCap UE), or the maximum operating bandwidth of the second terminal is greater than the maximum operating bandwidth of the first terminal, or the second terminal device is a normal terminal or a non-capability-reduced terminal or a normal terminal. Thus, it is clear that the maximum bandwidth of RedCap UE (the first type or the second type) is less than the maximum bandwidth of non-RedCap UE (the third type of non-RedCap UE) and monitoring the first CFR indicated in the first indication for at least one of broadcast traffic or multicast traffic (Zhang, in Page 17, Lines 29-36, teaches that MCCH messages are transmitted periodically, and their configuration information is carried in the system information block (SIB), such as SIB20. For example, SIB20 may include MCCH configuration information (located in the cell mcch-Config) and common frequency resources (CFR) (located in the cell cfr-ConfigMCCH-MTCH). The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. Based on this observation, the MCCH message are transmitted periodically for broadcast service with configuration information including CFR configuration information, to monitor MCCH and the associated CFR. Therefore, it is clear that based on the MCCH message, the CFR indicated in the first indication for at least one of broadcast traffic or multicast traffic is monitored periodically.) However, Zhang does not explicitly teach that wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth. Sha teaches that wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth (Sha, in Page 30, Lines 20-34 and in Page 32, Lines 3-17, teaches that for a terminal device in an RRC non-connected state, when a multicast session is in a deactivated state, the network device needs to notify the terminal device so that the terminal device stops receiving the multicast session. To indicate this, an MCCH message is sent to the terminal device, and the deactivated state of the multicast session is indicated through the MCCH message, which will cause energy consumption overhead of the terminal device and increase the burden on the network side. Thus, as described in Page 33, Lines 10-25, the RedCap terminal (UE) is supported by the cell to provide MBS (multicast broadcast services). For this, two different CFRs are configured for two different RedCap UE. For the first RedCap terminal, the bandwidth value of the first common frequency resource CFR configured by SIB20 of the first cell does not exceed the first bandwidth value. Among them, the first bandwidth value can be the maximum bandwidth supported by the terminal equipment. If the first CFR configured by SIB20 is default, the bandwidth value of the first CFR is equal to the bandwidth of control resource set 0 (CORESET#0), and CORESET#0 is configured by SIB1. Alternatively, the first cell configures a second CFR, and the second CFR is the CFR used by the first type of terminal equipment (another RedCap UE: corresponding to the second type of RedCap UE), and the second CFR is independent of the first CFR. Here, the first type of terminal in the art indicates the RedCap UE, but as described in Paragraphs [0088] and [0089], the RedCap UEs having different configuration (bandwidth capability) are considered as different type of RedCap UE. Among them, the bandwidth value of the second CFR does not exceed the maximum bandwidth supported by the first type of terminal equipment (the second RedCap UE), and the second CFR can be configured by an additional field in SIB20, or configured through other SIBs. The second CFR can be a CFR dedicated to REDCAP terminal equipment configured by the network device, and the bandwidth of the above-mentioned second CFR is less than or equal to the maximum channel bandwidth supported by the REDCAP terminal equipment. Thus, since the first maximum bandwidth of the first RedCap UE is the bandwidth of CORESET#0 and the second maximum bandwidth of the second RedCap UE is the maximum channel bandwidth, the first maximum bandwidth of the first RedCap UE is less than one of the second RedCap UE and two CFRs are independent. It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine Zhang and Sha to include the technique of wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth of Sha in the system of Zhang provide a communication method and device, which can ensure the continuity of MBS services and improve communication quality (Sha, see Page 2, Lines, 15-16 ).). Regarding claim 27, combination of Zhang and Sha teaches the features defined in the claims 26, -refer to the indicated claim for reference(s). Zhang further teaches that wherein the second CFR is associated with at least one of the MCCH or the MTCH for the second type of RedCap UE (Zhang, in Page 13, Lines 1-11, in Page 17, Lines 12-41, and in Page 18, Lines 1-21, teaches that the first type of terminal may include a reduced capability (RedCap) terminal and/or an enhanced RedCap (eRedCap) terminal. The baseband bandwidth for the physical downlink shared channel (PDSCH) and physical uplink shared channel (PUSCH) is only supported at 5 megahertz (MHz). The radio frequency (RF) bandwidth for uplink (UL) and downlink (DL) is 20MHz. For RedCap terminal or eRedCap terminal, the maximum bandwidth of the RedCap terminal in frequency range 1 (frequency range 1, FR1) is 20 MHz, and the maximum bandwidth in frequency range 2 (frequency range 2, FR2) is 100 MHz. Based on this observation, RedCap or eRedCap terminal can have three different capabilities to support the three different maximum bandwidths (5 MHz, 20MHz, or 100MHz), respectively. Further, when for RedCap or eRedCap terminal, the first capability may support to the first maximum bandwidth 5 MHz, the second capability may support the second maximum bandwidth 100 MHz, and the third capability may support to the third maximum bandwidth 20 MHz, the third capability having a third maximum bandwidth 20 MHz that is greater than the first maximum bandwidth (5 MHz) and less than the second maximum bandwidth (100 MHz). Since CFR can be understood as the frequency range as described in the above, the first CFR supporting the third capability is different from the second CFR (100 MHz). MCCH messages and broadcast services are transmitted in CFR, where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Therefore, it is clear that the CFR is a first CFR that is different from a second CFR associated with at least one of the MCCH or the MTCH for one or more RedCap UEs supporting a third capability having a third maximum bandwidth that is greater than the first maximum bandwidth and less than the second maximum bandwidth.) Regarding claim 28, combination of Zhang and Sha teaches the features defined in the claims 26, -refer to the indicated claim for reference(s). Zhang further teaches receiving a first discontinuous reception (DRX) configuration associated with the first type of RedCap UE that is different from a second DRX configuration for the second type of RedCap UE (Zhang, in Page 18, Lines 3-15, teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. The configuration information of MTCH may include G-RNTI, discontinuous reception (DRX) parameters, TMGI, physical downlink shared channel (PDSCH) configuration corresponding to MTCH, etc. Based on this observation, it is clear that, since based on the CFR, the configuration information of MTCH corresponding to the broadcast service determines the DRX configuration, the DRX configuration for each type of RedCap UE can be different, if the different broadcast service is provided to each type of RedCap UE.) Regarding claim 29, Zhang teaches that a method for wireless communication at a network device, comprising: outputting, for transmission to a first type of reduced capability (RedCap) user equipment (UE) in one of an inactive or idle state, a first indication of a first common frequency resource (CFR) associated with at least one of a multicast control channel (MCCH) or a multicast traffic channel (MTCH) for the first type of RedCap UE; (Zhang, in Page 13, Lines 1-3, in Page 17, Lines 12-41, and in Page 18, Lines 1-21, teaches that the first type of terminal may include a reduced capability (RedCap) terminal and/or an enhanced RedCap (eRedCap) terminal. When the network provides broadcast services, the terminals receive them autonomously according to the configuration information. Broadcast services can be provided to terminals in any radio resource control (RRC) state that include RRC idle or inactive state. For broadcast services, two logical channels are introduced in the NR system: MBS control channel (MCCH) and MBS traffic channel (MTCH). At the physical layer, MCCH messages and broadcast services are carried in PDSCH. MCCH messages are transmitted periodically, and their configuration information is carried in the system information block (SIB), such as SIB20. For example, SIB20 may include MCCH configuration information (located in the cell mcch-Config) and common frequency resources (CFR) (located in the cell cfr-ConfigMCCH-MTCH). The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. From this, it can be considered as the first indication of CFR. CFR is a continuous frequency domain resource, which can be defined by a starting position and a bandwidth size. CFR is used to transmit MBS services. CFR can be: control resource set (CORESET) 0 (i.e., CORESET0), SIB1 configured bandwidth (such as initial part bandwidth (bandwidth part, BWP)), or a separately configured bandwidth larger than the SIB1 configured bandwidth. It is alternative first indication of CFR. MCCH messages and broadcast services are transmitted in CFR. CFR can be understood as the frequency range where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Broadcast services can be identified by temporary multicast group identifier (TMGI), that is, TMGI can be understood as the identifier of broadcast services. Based on this observation, it is clear that a first indication of a common frequency resource (CFR) associated with at least one of a multicast control channel (MCCH) or a multicast traffic channel (MTCH) for a plurality of reduced capability (RedCap) UEs in one of an inactive or idle state is transmitted.) wherein the second maximum bandwidth is less than a third maximum bandwidth that is supported by a third type of non-RedCap UE (Zhang, in Page 12, Lines 31 - Page 13, Lines 3, teaches that the first type of terminal (it is corresponding to the second type of RedCap UE) may include a reduced capability (RedCap) terminal (or UE) and/or an enhanced RedCap (eRedCap) terminal and the second type of terminal may be an enhanced mobile broadband (eMBB) terminal (it is corresponding to a third type of non-RedCap UE: a non-RedCap terminal or a normal terminal). The first terminal belongs to the first type of terminal, and the second terminal belongs to the second type of terminal. The features of the first terminal are considered as the features of the first type of terminal and the features of the second terminal are considered as the features of the second type of terminal. The maximum operating bandwidth of the first terminal (the second type RedCap UE) is less than the maximum operating bandwidth of the second terminal (third type of non-RedCap UE), or the maximum operating bandwidth of the second terminal is greater than the maximum operating bandwidth of the first terminal, or the second terminal device is a normal terminal or a non-capability-reduced terminal or a normal terminal. Thus, it is clear that the maximum bandwidth of RedCap UE (the first type or the second type) is less than the maximum bandwidth of non-RedCap UE (the third type of non-RedCap UE) and outputting, for transmission to the first type of RedCap UE, at least one of an MCCH communication or an MTCH communication via the first CFR indicated in the first indication for at least one of broadcast traffic or multicast traffic (Zhang, in Page 17, Lines 29-36, teaches that MCCH messages are transmitted periodically, and their configuration information is carried in the system information block (SIB), such as SIB20. For example, SIB20 may include MCCH configuration information (located in the cell mcch-Config) and common frequency resources (CFR) (located in the cell cfr-ConfigMCCH-MTCH). The configuration information of MCCH may include the repetition period (RP), offset (mcch-Offset), transmission time (mcch-duration), modification period (MP), etc. of MCCH. The cfr-ConfigMCCH-MTCH information element may include the LocationAndBandwidthBroadcast information element, which is used to configure CFR. Based on this observation, the MCCH message are transmitted periodically for broadcast service with configuration information including CFR configuration information, to monitor MCCH and the associated CFR. Therefore, it is clear that based on the MCCH message, the CFR indicated in the first indication for at least one of broadcast traffic or multicast traffic is transmitted, periodically.) However, Zhang does not explicitly teach that wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth. Sha teaches that wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth (Sha, in Page 30, Lines 20-34 and in Page 32, Lines 3-17, teaches that for a terminal device in an RRC non-connected state, when a multicast session is in a deactivated state, the network device needs to notify the terminal device so that the terminal device stops receiving the multicast session. To indicate this, an MCCH message is sent to the terminal device, and the deactivated state of the multicast session is indicated through the MCCH message, which will cause energy consumption overhead of the terminal device and increase the burden on the network side. Thus, as described in Page 33, Lines 10-25, the RedCap terminal (UE) is supported by the cell to provide MBS (multicast broadcast services). For this, two different CFRs are configured for two different RedCap UE. For the first RedCap terminal, the bandwidth value of the first common frequency resource CFR configured by SIB20 of the first cell does not exceed the first bandwidth value. Among them, the first bandwidth value can be the maximum bandwidth supported by the terminal equipment. If the first CFR configured by SIB20 is default, the bandwidth value of the first CFR is equal to the bandwidth of control resource set 0 (CORESET#0), and CORESET#0 is configured by SIB1. Alternatively, the first cell configures a second CFR, and the second CFR is the CFR used by the first type of terminal equipment (another RedCap UE: corresponding to the second type of RedCap UE), and the second CFR is independent of the first CFR. Here, the first type of terminal in the art indicates the RedCap UE, but as described in Paragraphs [0088] and [0089], the RedCap UEs having different configuration (bandwidth capability) are considered as different type of RedCap UE. Among them, the bandwidth value of the second CFR does not exceed the maximum bandwidth supported by the first type of terminal equipment (the second RedCap UE), and the second CFR can be configured by an additional field in SIB20, or configured through other SIBs. The second CFR can be a CFR dedicated to REDCAP terminal equipment configured by the network device, and the bandwidth of the above-mentioned second CFR is less than or equal to the maximum channel bandwidth supported by the REDCAP terminal equipment. Thus, since the first maximum bandwidth of the first RedCap UE is the bandwidth of CORESET#0 and the second maximum bandwidth of the second RedCap UE is the maximum channel bandwidth, the first maximum bandwidth of the first RedCap UE is less than one of the second RedCap UE and two CFRs are independent. It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine Zhang and Sha to include the technique of wherein the first type of RedCap UE supports a first maximum bandwidth that is less than a second maximum bandwidth that is supported by a second type of Red Cap UE, wherein the first CFR is based on the support for the first maximum bandwidth and is different from a second CFR for the second type of RedCap UE, and wherein the second CFR is based on the support for the second maximum bandwidth of Sha in the system of Zhang provide a communication method and device, which can ensure the continuity of MBS services and improve communication quality (Sha, see Page 2, Lines, 15-16 ).). Regarding claim 30, combination of Zhang and Sha teaches the features defined in the claims 29, -refer to the indicated claim for reference(s). Zhang further teaches that wherein the second CFR is associated with at least one of the MCCH or the MTCH for the second type of RedCap UEs (Zhang, in Page 13, Lines 1-11, in Page 17, Lines 12-41, and in Page 18, Lines 1-21, teaches that the first type of terminal may include a reduced capability (RedCap) terminal and/or an enhanced RedCap (eRedCap) terminal. The baseband bandwidth for the physical downlink shared channel (PDSCH) and physical uplink shared channel (PUSCH) is only supported at 5 megahertz (MHz). The radio frequency (RF) bandwidth for uplink (UL) and downlink (DL) is 20MHz. For RedCap terminal or eRedCap terminal, the maximum bandwidth of the RedCap terminal in frequency range 1 (frequency range 1, FR1) is 20 MHz, and the maximum bandwidth in frequency range 2 (frequency range 2, FR2) is 100 MHz. Based on this observation, RedCap or eRedCap terminal can have three different capabilities to support the three different maximum bandwidths (5 MHz, 20MHz, or 100MHz), respectively. Further, when for RedCap or eRedCap terminal, the first capability may support to the first maximum bandwidth 5 MHz, the second capability may support the second maximum bandwidth 100 MHz, and the third capability may support to the third maximum bandwidth 20 MHz, the third capability having a third maximum bandwidth 20 MHz that is greater than the first maximum bandwidth (5 MHz) and less than the second maximum bandwidth (100 MHz). Since CFR can be understood as the frequency range as described in the above, the first CFR supporting the third capability is different from the second CFR (100 MHz). MCCH messages and broadcast services are transmitted in CFR, where the PDSCH corresponding to the MCCH message and the PDSCH corresponding to the broadcast service are located. The specific frequency domain position of the PDSCH is scheduled by the downlink control information (DCI) in the physical downlink control channel (PDCCH). The configuration information of MTCH in the MCCH message can be based on the granularity of broadcast services, that is, the configuration of MTCH is per service level. Each broadcast service can be associated with a G-RNTI. Therefore, it is clear that the CFR is a first CFR that is different from a second CFR associated with at least one of the MCCH or the MTCH for one or more RedCap UEs supporting a third capability having a third maximum bandwidth that is greater than the first maximum bandwidth and less than the second maximum bandwidth.) Claims 8 and 21 are rejected under U.S.C. 103 as being unpatentable over Zhang, Haisen et. al. (Int. Pub. No.: WO 2024208230 A1 translated version, hereinafter “Zhang”) in a view of Lee, Youngdae et. al. (Int. Pub No.: WO 2023085842 A1 translated version, hereinafter “Lee”). Regarding claim 8, Zhang teaches the features defined in the claims 1, -refer to the indicated claim for reference(s). Zhang further teaches that receive a first MTCH configuration for a first type of RedCap UE that is different from a second MTCH configuration for a second type of RedCap UE (Zhang, in Page 17, Lines 33-36, in Page 18, Lines 16-21, and in Page 25, Lines 13-29, teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. The network node first transmits the SIB and obtains the configuration information of the MCCH from the SIB. After that, the MCCH message is transmitted according to the configuration information of the MCCH, and the content of the MCCH message is read to obtain the configuration information of the MTCH carried by the MCCH. Finally, the data of the broadcast service is transmitted according to the configuration information of the MTCH. Further, the network device may perform MCCH configuration and/or CFR configuration for the first terminal and the second terminal respectively. Exemplarily, the system message of the first cell may include the following information: {mcch-Config# is used to configure MCCH for the second terminal; cfr-ConfigMCCH-MTCH# is used to configure CFR for the second terminal; … mcch-ConfigRedCap# is used to configure MCCH for the first terminal; cfr-ConfigMCCH-MTCH-RedCap# is used to configure CFR for the first terminal;} Based on this observation, it is clear that for each type of RedCap UE, the different MTCH may be configured.) However, Zhang does not explicitly teach that wherein the first MTCH configuration includes at least one of a first rate matching (RM), a first limited buffer RM (LBRM), or a first set of reference signal (RS) configurations associated with the MTCH that is different from a second RM, a second LBRM, or a second set of RS configurations associated with the second MTCH configuration. Lee teaches that wherein the first MTCH configuration includes at least one of a first rate matching (RM), a first limited buffer RM (LBRM), or a first set of reference signal (RS) configurations associated with the MTCH that is different from a second RM, a second LBRM, or a second set of RS configurations associated with the second MTCH configuration (Lee, in Page 16, Lines 34-40 and in Page 36, Lines 19-34, in Page 37, Lines 1-17, and in Page 35, Lines 20-21 and Table of PDSCH (Table 6), teaches that when a data unit is available on the MTCH of the MBS radio bearer (MRB) for the MBS service, the network side is associated with the MTCH of the MRB for the MBS service, or associated with the TMGI of the MBS service, or a short A data unit for the SPS PDSCH case associated with the ID may be included, or a TB associated with the G-RNTI mapped to the MBS service may be configured and transmitted to the UE according to service-to-resource mapping. For group common dynamic scheduling of TB, the network side may transmit DCI to the UE through the PDCCH. The corresponding DCI may be CRC scrambled by G-RNTI, G-CS-RNTI, or CS-RNTI. The PDCCH may be implemented as a group common PDCCH or a UE-specific PDCCH. For example, the DCI is an identifier for a DCI format, a carrier indicator, a bandwidth part indicator, a frequency domain resource assignment, a time domain resource assignment, a VRB-to-PRB mapping, and a PRB bundling size. indicator, rate matching indicator, ZP CSI-RS trigger, MCS, NDI, RV, HARQ process number, downlink allocation index, scheduled TPC command for PUCCH, PUCCH resource indicator, PDSCH-to-HARQ_feedback timing indicator, it may include at least one of an antenna port, transmission configuration instruction, SRS request, DMRS sequence initialization, and priority indicator. In the case of group common dynamic scheduling, either by group common or UE specific RRC message or by group common or UE specific MAC CE, the network side can send one or more information to the MBS service identified by TMGI or G-RNTI or GC-CS-RNTI. Service-resource mapping may be provided to the terminal. The data of the MBS service can be carried over the multicast traffic logical channel, that is, the MBS radio bearer (MRB) of the MTCH associated with the MBS service. The RRC message may be a group common message transmitted through a PTM Multicast Control Channel (MCCH) or a UE-specific message transmitted through a UE-specific Dedicated Control Channel (DCCH). The DCI scheduling PDSCH carrying MBS service data may also indicate one or more of a short ID, MTCH ID, MRB ID, G-RNTI value and TMGI value for MBS service. When the UE receives the DCI scrambled by the G-RNTI to be received, the UE bases the mapping between the MBS service indicated in the DCI and the HPN and/or the mapping between the MBS service indicated in the DCI and the short ID(s). Thus, it is possible to determine the MBS service(s) associated with one or more of the short ID, MTCH ID, MRB ID, G-RNTI value, and TMGI value for each PDSCH opportunity. Then, if the UE is interested in the determined MBS service(s), the UE can receive PDSCH transmission scheduled by DCI. Further, configuration information (eg, 'PDSCH-config') of each PDSCH may be configured as shown in Table 6 with minimum information elements for multicast and/or broadcast. In the table, the configuration for RS (DMRS) configuration and RM configuration are provided with MTCH. In addition, the UE-specific BWP may also include multicast CFR. At this time, the terminal may receive broadcast and multicast transmission through one CFR, or receive both broadcast and multicast transmission through two CFRs (ie, broadcast CFR and multicast CFR). For a limited buffer rate matching (LBRM) operation when receiving a terminal common PDSCH, the base station provides resource block configuration information, max MIMO layer configuration information, and maximum modulation order configuration information for BWP or CFR can be provided to the terminal. Based on this observation, it is clear that for the type of each RedCap UE, its own MTCH configuration is received, where the MTCH includes its own RM, LBRM or RS configuration. It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine Zhang and Lee to include the technique of wherein the first MTCH configuration includes at least one of a first rate matching (RM), a first limited buffer RM (LBRM), or a first set of reference signal (RS) configurations associated with the MTCH that is different from a second RM, a second LBRM, or a second set of RS configurations associated with the second MTCH configuration of Lee in the system of Zhang to provide a method and apparatus for starting or restarting a timer related to deactivation of a secondary cell according to transmission and reception of multicast data or unicast data, for a terminal to be able to prevent from unnecessarily maintaining a secondary cell in an active state by controlling reception of a specific type of data not to affect restarting of a timer related to deactivation of a secondary cell (Lee, see Page 2, Lines, 20-26 ).). Regarding claim 21, Zhang teaches the features defined in the claims 15, -refer to the indicated claim for reference(s). Zhang further teaches that output, for transmission to the plurality of RedCap UEs, a first MTCH configuration for a first type of RedCap UE that is different from a second MTCH configuration for a second type of RedCap UE (Zhang, in Page 17, Lines 33-36, in Page 18, Lines 16-21, and in Page 25, Lines 13-29, teaches that in the above, the type of RedCap UE can be determined based on the capability supporting its maximum bandwidth, according to CFR. The network node first transmits the SIB and obtains the configuration information of the MCCH from the SIB. After that, the MCCH message is transmitted according to the configuration information of the MCCH, and the content of the MCCH message is read to obtain the configuration information of the MTCH carried by the MCCH. Finally, the data of the broadcast service is transmitted according to the configuration information of the MTCH. Further, the network device may perform MCCH configuration and/or CFR configuration for the first terminal and the second terminal respectively. Exemplarily, the system message of the first cell may include the following information: {mcch-Config# is used to configure MCCH for the second terminal; cfr-ConfigMCCH-MTCH# is used to configure CFR for the second terminal; … mcch-ConfigRedCap# is used to configure MCCH for the first terminal; cfr-ConfigMCCH-MTCH-RedCap# is used to configure CFR for the first terminal;} Based on this observation, it is clear that for each type of RedCap UE, the different MTCH may be configured.) However, Zhang does not explicitly teach that wherein the first MTCH configuration includes at least one of a first rate matching (RM), a first limited buffer RM (LBRM), or a first set of reference signal (RS) configurations associated with the MTCH that is different from a second RM, a second LBRM, or a second set of RS configurations associated with the second MTCH configuration. Lee teaches that wherein the first MTCH configuration includes at least one of a first rate matching (RM), a first limited buffer RM (LBRM), or a first set of reference signal (RS) configurations associated with the MTCH that is different from a second RM, a second LBRM, or a second set of RS configurations associated with the second MTCH configuration (Lee, in Page 16, Lines 34-40 and in Page 36, Lines 19-34, in Page 37, Lines 1-17, and in Page 35, Lines 20-21 and Table of PDSCH (Table 6), teaches that when a data unit is available on the MTCH of the MBS radio bearer (MRB) for the MBS service, the network side is associated with the MTCH of the MRB for the MBS service, or associated with the TMGI of the MBS service, or a short A data unit for the SPS PDSCH case associated with the ID may be included, or a TB associated with the G-RNTI mapped to the MBS service may be configured and transmitted to the UE according to service-to-resource mapping. For group common dynamic scheduling of TB, the network side may transmit DCI to the UE through the PDCCH. The corresponding DCI may be CRC scrambled by G-RNTI, G-CS-RNTI, or CS-RNTI. The PDCCH may be implemented as a group common PDCCH or a UE-specific PDCCH. For example, the DCI is an identifier for a DCI format, a carrier indicator, a bandwidth part indicator, a frequency domain resource assignment, a time domain resource assignment, a VRB-to-PRB mapping, and a PRB bundling size. indicator, rate matching indicator, ZP CSI-RS trigger, MCS, NDI, RV, HARQ process number, downlink allocation index, scheduled TPC command for PUCCH, PUCCH resource indicator, PDSCH-to-HARQ_feedback timing indicator, it may include at least one of an antenna port, transmission configuration instruction, SRS request, DMRS sequence initialization, and priority indicator. In the case of group common dynamic scheduling, either by group common or UE specific RRC message or by group common or UE specific MAC CE, the network side can send one or more information to the MBS service identified by TMGI or G-RNTI or GC-CS-RNTI. Service-resource mapping may be provided to the terminal. The data of the MBS service can be carried over the multicast traffic logical channel, that is, the MBS radio bearer (MRB) of the MTCH associated with the MBS service. The RRC message may be a group common message transmitted through a PTM Multicast Control Channel (MCCH) or a UE-specific message transmitted through a UE-specific Dedicated Control Channel (DCCH). The DCI scheduling PDSCH carrying MBS service data may also indicate one or more of a short ID, MTCH ID, MRB ID, G-RNTI value and TMGI value for MBS service. When the UE receives the DCI scrambled by the G-RNTI to be received, the UE bases the mapping between the MBS service indicated in the DCI and the HPN and/or the mapping between the MBS service indicated in the DCI and the short ID(s). Thus, it is possible to determine the MBS service(s) associated with one or more of the short ID, MTCH ID, MRB ID, G-RNTI value, and TMGI value for each PDSCH opportunity. Then, if the UE is interested in the determined MBS service(s), the UE can receive PDSCH transmission scheduled by DCI. Further, configuration information (eg, 'PDSCH-config') of each PDSCH may be configured as shown in Table 6 with minimum information elements for multicast and/or broadcast. In the table, the configuration for RS (DMRS) configuration and RM configuration are provided with MTCH. In addition, the UE-specific BWP may also include multicast CFR. At this time, the terminal may receive broadcast and multicast transmission through one CFR, or receive both broadcast and multicast transmission through two CFRs (ie, broadcast CFR and multicast CFR). For a limited buffer rate matching (LBRM) operation when receiving a terminal common PDSCH, the base station provides resource block configuration information, max MIMO layer configuration information, and maximum modulation order configuration information for BWP or CFR can be provided to the terminal. Based on this observation, it is clear that for the type of each RedCap UE, its own MTCH configuration is received, where the MTCH includes its own RM, LBRM or RS configuration. It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine Zhang and Lee to include the technique of wherein the first MTCH configuration includes at least one of a first rate matching (RM), a first limited buffer RM (LBRM), or a first set of reference signal (RS) configurations associated with the MTCH that is different from a second RM, a second LBRM, or a second set of RS configurations associated with the second MTCH configuration of Lee in the system of Zhang to provide a method and apparatus for starting or restarting a timer related to deactivation of a secondary cell according to transmission and reception of multicast data or unicast data, for a terminal to be able to prevent from unnecessarily maintaining a secondary cell in an active state by controlling reception of a specific type of data not to affect restarting of a timer related to deactivation of a secondary cell (Lee, see Page 2, Lines, 20-26 ).). Conclusion 07-40 AIA Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL . See MPEP § 706.07(a). 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 JAEYOUNG KWAK whose telephone number is (703)756-1768. The examiner can normally be reached Monday-Friday 9 AM -5 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, Kevin Bates can be reached at 571-272-3980. 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. /JAEYOUNG KWAK/Examiner, Art Unit 2472 /KEVIN T BATES/Supervisory Patent Examiner, Art Unit 2472 Application/Control Number: 18/320,939 Page 2 Art Unit: 2472 Application/Control Number: 18/320,939 Page 3 Art Unit: 2472 Application/Control Number: 18/320,939 Page 4 Art Unit: 2472 Application/Control Number: 18/320,939 Page 5 Art Unit: 2472 Application/Control Number: 18/320,939 Page 6 Art Unit: 2472 Application/Control Number: 18/320,939 Page 7 Art Unit: 2472 Application/Control Number: 18/320,939 Page 8 Art Unit: 2472 Application/Control Number: 18/320,939 Page 9 Art Unit: 2472 Application/Control Number: 18/320,939 Page 10 Art Unit: 2472 Application/Control Number: 18/320,939 Page 11 Art Unit: 2472 Application/Control Number: 18/320,939 Page 12 Art Unit: 2472 Application/Control Number: 18/320,939 Page 13 Art Unit: 2472 Application/Control Number: 18/320,939 Page 14 Art Unit: 2472 Application/Control Number: 18/320,939 Page 15 Art Unit: 2472 Application/Control Number: 18/320,939 Page 16 Art Unit: 2472 Application/Control Number: 18/320,939 Page 17 Art Unit: 2472 Application/Control Number: 18/320,939 Page 18 Art Unit: 2472 Application/Control Number: 18/320,939 Page 19 Art Unit: 2472 Application/Control Number: 18/320,939 Page 21 Art Unit: 2472 Application/Control Number: 18/320,939 Page 22 Art Unit: 2472 Application/Control Number: 18/320,939 Page 23 Art Unit: 2472 Application/Control Number: 18/320,939 Page 24 Art Unit: 2472 Application/Control Number: 18/320,939 Page 25 Art Unit: 2472 Application/Control Number: 18/320,939 Page 26 Art Unit: 2472 Application/Control Number: 18/320,939 Page 28 Art Unit: 2472 Application/Control Number: 18/320,939 Page 29 Art Unit: 2472 Application/Control Number: 18/320,939 Page 30 Art Unit: 2472 Application/Control Number: 18/320,939 Page 31 Art Unit: 2472 Application/Control Number: 18/320,939 Page 32 Art Unit: 2472 Application/Control Number: 18/320,939 Page 33 Art Unit: 2472 Application/Control Number: 18/320,939 Page 34 Art Unit: 2472 Application/Control Number: 18/320,939 Page 35 Art Unit: 2472 Application/Control Number: 18/320,939 Page 36 Art Unit: 2472 Application/Control Number: 18/320,939 Page 37 Art Unit: 2472 Application/Control Number: 18/320,939 Page 38 Art Unit: 2472 Application/Control Number: 18/320,939 Page 39 Art Unit: 2472 Application/Control Number: 18/320,939 Page 40 Art Unit: 2472 Application/Control Number: 18/320,939 Page 41 Art Unit: 2472 Application/Control Number: 18/320,939 Page 43 Art Unit: 2472 Application/Control Number: 18/320,939 Page 44 Art Unit: 2472 Application/Control Number: 18/320,939 Page 45 Art Unit: 2472 Application/Control Number: 18/320,939 Page 46 Art Unit: 2472 Application/Control Number: 18/320,939 Page 47 Art Unit: 2472 Application/Control Number: 18/320,939 Page 48 Art Unit: 2472 Application/Control Number: 18/320,939 Page 49 Art Unit: 2472 Application/Control Number: 18/320,939 Page 50 Art Unit: 2472 Application/Control Number: 18/320,939 Page 51 Art Unit: 2472 Application/Control Number: 18/320,939 Page 52 Art Unit: 2472 Application/Control Number: 18/320,939 Page 53 Art Unit: 2472 Application/Control Number: 18/320,939 Page 54 Art Unit: 2472
Read full office action

Prosecution Timeline

May 19, 2023
Application Filed
Dec 04, 2025
Non-Final Rejection mailed — §103
Feb 20, 2026
Response Filed
Jun 02, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12684459
SYSTEMS AND METHODS FOR SUPPORTING NETWORK SLICE ADMISSION CONTROL BASED ON SUBSCRIPTION AND POLICY CONTROL
3y 1m to grant Granted Jul 14, 2026
Patent 12677192
DATA TRANSMISSION METHOD, DEVICE, AND MEDIUM
3y 10m to grant Granted Jul 07, 2026
Patent 12666376
METHOD AND SYSTEM FOR NETWORK SLICE-SPECIFIC PROPAGATION DELAY COMPENSATION
4y 0m to grant Granted Jun 23, 2026
Patent 12634750
ERROR PROTECTION OF DATA UNIT SERVICE FIELD IN WIRELESS LOCAL AREA NETWORK TRANSMISSIONS
3y 10m to grant Granted May 19, 2026
Patent 12634056
CODE BLOCK OPERATION FOR PHYSICAL UPLINK SHARED CHANNEL REPETITIONS WITH TRANSPORT BLOCK SCALING AND FREQUENCY HOPPING
3y 3m to grant Granted May 19, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
89%
Grant Probability
99%
With Interview (+18.2%)
3y 3m (~1m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 18 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month