DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/24/2026 has been entered.
Response to Arguments
Applicant's arguments filed 3/24/202 have been fully considered but they are not persuasive.
Regarding claim 1, Applicant Argues that 601 discloses many different cases, but the cases together do not disclose the now cited procedure (Applicant’s Arguments and Remarks page 13-14). Examiner disagrees and notes that case 1 discloses these elements, as disclosed in the office action, infra.
Regarding claim 1, Applicant Argues that 601 does not disclose the claimed monitoring as monitoring reception of the MSG 2 is “insufficient” (page 14). However, the broadest reasonable interpretation of monitoring includes monitoring a channel to receive MSG 2, so Applicant’s Argument’s have been considered and are not persuasive.
Regarding claim 1, Applicant Argues that 601 discloses does not disclose that the monitoring is in response to initiating the RACH procedure, as it merely disclose performing random access for receiving messages (Id). This is incorrect. That is, 601 discloses that the channel for performing RACH is located in the RedCap-Specific initial BWP. Therefore, the changing of the BWP is directly in response to the need to perform RACH as this necessitats a switch to he RedCap-Specific initial BWP. Therefore, Applicant’s Arguments have been considered and are not persuasive.
Regarding claim 1, Applicant Argues related to Moo, however, this reference is no longer utilized and these arguments are therefore moot
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 4, 18, 19, 20, 26, 27, 29 and 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over R1-2106601 (“601”) (Author Unknown, Discussion on reduced maximum UE bandwidth, Doc. No. R1-2106601, pages 1-9, 27 August 2021) in view of Tran, et al. (US Pre Grant Publication No. 2023/0362796).
Regarding claims 1 and 27, 601 discloses a method of wireless communication performed by a user equipment (UE), comprising and a user equipment (UE) for wireless communication:
a. receiving a system information block 1 (SIB1) corresponding to a reduced capacity (RedCap) specific initial downlink bandwidth part (BWP) and a non-RedCap-specific initial downlink BWP (601 discloses that both RedCap and non-RedCap UEs share a single SIB1 that may indicate the configurations for the initial BWP for non-RedCap UEs and the separate initial DL BWP for RedCap UEs [see page 3, “Configuration details for the separate initial DL BWP” – the SIB1 contains generic parameters such as locationAndBandwidth, subcarrierSpacing and cyclicPrefix for the initial DL BWP for non-RedCap UEs and can also contain the locationAndBandwidth for the separate initial DL BWP for RedCap UEs and optionally may contain the subcarrierSpacing, cyclicPrefix and pdsch-AllocationList for the RedCap UEs, although these values may be inherited from the configuration for the initial DL BWP for non-RedCap UEs in the SIB1.] As discussed in further detail in Table 1, in cases 1-3 the SIB1/SI is common to both the BWP0/initial DL BWP/BWP for non-RedCap UEs and the BWP0’/separate initial DL BWP/BWP for RedCap UEs and in case 4, the SIB1 is common for RedCap and non-RedCap UEs but is separately broadcast in the separate initial DL BWP for RedCap UEs/BWP0’, causing overhead for the common SIB1 [see page 4, table 1].)
b. initiating a random access control channel (RACH) procedure and switching, based at least in part on initiating the RACH procedure, from the non-RedCap-specific initial downlink BWP to the RedCap-specific initial downlink BWP (In case 1, 601 discloses that an RRC idle UE will use the legacy/non-Redcap initial DL BWP to monitor the PDCCH for paging indicating a change in the received system information/SI and will initiate a RACH procedure on the RedCAP specific initial BWP/separate initial BWnon0P but does not enter into connected mode until completion of the MSG2 and MSG4 transmission on the PDCCH of the RedCAP specific initial BWP/separate initial BWP [page 2, proposal 4, discussion of case 1 – “For Case 1, generally, a RRC-IDLE/ INACTIVE RedCap UE uses the legacy initial DL BWP to monitor paging PDCCH in Type2 CSS and receives the updated SIs if paging PDCCH indicates the SI change. Only when random access is triggered, the RedCap UE needs to go to the separate DL initial BWP to receive MSG2 and MSG4. Once RRC connection is established, based on TS 38.331 [2], the RedCap UE in RRC-CONNECTED state…; table 4, case 1, - “offloaded messages – Msg 2, Msg 4 and associated PDCCH]. Therefore an idle mode UE may initiate the RACH procedure using by switching to the RedCap-specific initial downlink BWP and receiving MSG1 and MSG3 on the PDCCH of the RedCap-specific initial downlink BWP before transitioning to connected mode.
c. monitoring, in response to initiating the RACH procedure, a control channel within the RedCap-specific initial downlink BWP, wherein the UE is a redcap UE operating in idle mode or inactive mode and receiving at least one communication via the control channel. (As discussed in (b), supra the idle mode RedCap switches to the RedCAP specific initial BWP/separate initial BWP and initiates the RACH procedure where it monitors for MS2 and MSG4 on the PDCCH of the RedCAP specific initial BWP/separate initial BWP, note that before the completion of the RACH procedure, the UE is still in idle mode as the switch to connected mode is not yet complete [page 2, proposal 4, discussion of case 1, table 1, case 1].)
601 fails to disclose receiving, via a broadcast control channel (BCCH) a SIB1. In the same field of endeavor, Tran discloses receiving, via a broadcast control channel (BCCH) a SIB1 (paragraph 0115).
Therefore, since Tran discloses BCCH carrying SIB1, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to combine the BCCH carrying SIB1 of Tran with the system of 601 by having the UE receive and the network device/base station transmit the SIB1 using a BCCH. The motive to combine is to improve backwards compatibility with release 15 systems.
Regarding claim 27, 601 as modified by Tran fails to disclose one or more memories and one or more processors coupled to the one or more memories to carry out the recited functions. However, it is officially noted that the use of a memory and processor to carry out UE functions was well known in the art before the effective filing date of the invention. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to carry out the recited functions of 601 as modified by Moo using a memory and processor. The motive to combine is to allow use of the low cost microprocessor.
Regarding claim 4, 601 discloses receiving a synchronization signal block corresponding to the RedCap-specific initial downlink BWP. (601 discloses that an additional SSB dedicated/corresponding to the separate initial DL BWP/RedCap-specific initial downlink BWP is configured [pages 5-6, last dot of page 5 to proposal 9 on page 6 – note in particular fig. 1(b) – the RedCAP BWP has a dedicated/corresponding 2nd SSB].)
Regarding claim 18, 601 discloses switching from a non-RedCap-Specific initial downlink BWP to the RedCap-specific initial downlink BWP and performing a random access channel (RACH) procedure corresponding to the RedCap-specific initial downlink BWP. (Looking to case 1 and mapping the control information to MSG2 in the independent claim, 601 discloses that the UE searches for MSG2 in the RedCap-specific initial downlink BWP/ separate initial DL BWP only when a random access procedure is triggered and in that case, switches from the legacy initial DL BWP in which all other relevant information is received, to the RedCap-specific initial downlink BWP/ separate initial DL BWP to perform the random access reception/procedure and receive MSG2/4/control informaiton [see pages 2-3 case 1, UE looks for paging search space on legacy initial BWP and also receives SIs, including other SI there; UE only switches to RedCap-specific initial downlink BWP/separate DL initial BWP when random access is triggered to receive MSG2/4.])
Regarding claim 19, 601 discloses the RedCap-specific initial downlink BWP shares a synchronization signal block with a non-RedCap-Specific initial downlink BWP. (601 discloses that the RedCap-specific initial downlink BWP/separate initial BWP shares a synchronization signal block/SSB with a non-RedCap-Specific initial downlink BWP/legacy initial BWP [pages 3-4, portion after last bold dot of page 3 and pages 5-6, portion after last bold dot of page 6; in particular look to fig. 1(a) on page 6, which shows the same CD-SSB shared by both BWPs].)
Regarding claims 20 and 29, 601 discloses a method of wireless communication performed by a network node, comprising and a network node for wireless communication comprising:
Transmitting a SIB1 corresponding to a RedCap-specific initial downlink BWP and a non-RedCap specific initial downlink BWP (601 discloses that both RedCap and non-RedCap UEs share a single SIB1 trasmitted by a network node/base station that may indicate the configurations for the initial BWP for non-RedCap UEs and the separate initial DL BWP for RedCap UEs [see page 3, “Configuration details for the separate initial DL BWP” – the SIB1 contains generic parameters such as locationAndBandwidth, subcarrierSpacing and cyclicPrefix for the initial DL BWP for non-RedCap UEs and can also contain the locationAndBandwidth for the separate initial DL BWP for RedCap UEs and optionally may contain the subcarrierSpacing, cyclicPrefix and pdsch-AllocationList for the RedCap UEs, although these values may be inherited from the configuration for the initial DL BWP for non-RedCap UEs in the SIB1.] As discussed in further detail in Table 1, in cases 1-3 the SIB1/SI is common to both the BWP0/initial DL BWP/BWP for non-RedCap UEs and the BWP0’/separate initial DL BWP/BWP for RedCap UEs and in case 4, the SIB1 is common for RedCap and non-RedCap UEs but is separately broadcast in the separate initial DL BWP for RedCap UEs/BWP0’, causing overhead for the common SIB1 [see page 4, table 1].)
transmitting a first communication on a first control channel configured within a non-reduced capability (RedCap) specific initial downlink bandwidth part (BWP) (as discussed in (a), supra, the base station/network node transmits the SIB1 in the legacy/non-Redcap initial DL BWP
transmitting in response to a random access channel (RACH) procedure, a second communication on a second contrl channel configured within the RedCap-specific downlink BWP. (In case 1, 601 discloses that an RRC idle UE will use the legacy/non-Redcap initial DL BWP to monitor the PDCCH for paging indicating a change in the received system information/SI and will initiate a RACH procedure on the RedCAP specific initial BWP/separate initial BWP but does not enter into connected mode until completion of the MSG2 and MSG4 transmission in response to the RACH procedure are sent by the network device/base station on the PDCCH of the RedCAP specific initial BWP/separate initial BWP [page 2, proposal 4, discussion of case 1 – “For Case 1, generally, a RRC-IDLE/ INACTIVE RedCap UE uses the legacy initial DL BWP to monitor paging PDCCH in Type2 CSS and receives the updated SIs if paging PDCCH indicates the SI change. Only when random access is triggered, the RedCap UE needs to go to the separate DL initial BWP to receive MSG2 and MSG4. Once RRC connection is established, based on TS 38.331 [2], the RedCap UE in RRC-CONNECTED state…; table 4, case 1, - “offloaded messages – Msg 2, Msg 4 and associated PDCCH]. Therefore an idle mode UE may initiate the RACH procedure using by switching to the RedCap-specific initial downlink BWP and receiving MSG1 and MSG3 on the PDCCH of the RedCap-specific initial downlink BWP before transitioning to connected mode.
601 fails to disclose transmitting, via a broadcast control channel (BCCH) a SIB1. In the same field of endeavor, Tran discloses transmitting, via a broadcast control channel (BCCH) a SIB1 (paragraph 0115). Therefore, since Tran discloses BCCH carrying SIB1, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to combine the BCCH carrying SIB1 of Tran with the system of 601 by having the UE receive and the network device/base station transmit the SIB1 using a BCCH. The motive to combine is to improve backwards compatibility with release 15 systems.
Regarding claim 26, 601 discloses the RedCap-specific initial downlink BWP shares a synchronization signal block with a non-RedCap-Specific initial downlink BWP. (601 discloses that the RedCap-specific initial downlink BWP/separate initial BWP shares a synchronization signal block/SSB with a non-RedCap-Specific initial downlink BWP/legacy initial BWP [pages 3-4, portion after last bold dot of page 3 and pages 5-6, portion after last bold dot of page 6; in particular look to fig. 1(a) on page 6, which shows the same CD-SSB shared by both BWPs].)
Regarding claim 29, 601 as modified by XXX fails to disclose a memory and one or more processors coupled to the memory to carry out the recited functions. However, it is officially noted that the use of a memory and processor to carry out network node functions was well known in the art before the effective filing date of the invention. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to carry out the recited functions or 601 as modified by Moo using a memory and processor. The motive to combine is to allow use of the low cost microprocessor.
Regarding claim 32, 601 discloses the at least one communication is received after completing the RACH procedure (the at least one communication can be re-mapped any transmission in connected mode, sech as RRC signaling for updates [page 3, proposal 4)].)
Claims 3, 21, 28 and 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over R1-2106601 (“601”) (Author Unknown, Discussion on reduced maximum UE bandwidth, Doc. No. R1-2106601, pages 1-9, 27 August 2021) and Tran, et al. (US Pre Grant Publication No. 2023/0362796) as applied to claim 1 and further in view Liang, et al. (US Pre Grant Publication No. 2023/0319830 A1)
Regarding claims 3 and 30, 601 fails to disclose monitoring the channel comprises monitoring a common search space. (i.e. 601 discloses monitoring RACH, but does not disclose RACH is in a common search space). In the same field of endeavor, Liang discloses the channel comprises monitoring a common search space. (Liang discloses a common search space for signaling RACH transmission such that monitoring a control channel for the RACH can more accurately be stated as monitoring the common search space for RACH indication [paragraph 0015].)
Therefore, since Liang disclose RACH search spaces, it would have been obvious to a person of ordinary skill in the art to implement the RACH in the separate initial DL BWP/BWP for RedCap UEs using a common search space which is transmitted by the base station/network device and monitored by the UE. The motive to combine is to allow the UE to quickly ascertain if a RACH transmission occurs by channel monitoring.
Regarding claims 21 and 28, 601 fails to disclose the second control channel comprises a
a common search space. (i.e. 601 discloses monitoring RACH, but does not disclose RACH is in a common search space). In the same field of endeavor, Liang discloses the second control channel comprises a common search space. (Liang discloses a common search space for signaling RACH transmission such that monitoring a control channel for the RACH can more accurately be stated as monitoring the common search space for RACH indication [paragraph 0015].)
Therefore, since Liang disclose RACH search spaces, it would have been obvious to a person of ordinary skill in the art to implement the RACH in the separate initial DL BWP/BWP for RedCap UEs using a common search space which is transmitted by the base station/network device and monitored by the UE. The motive to combine is to allow the UE to quickly ascertain if a RACH transmission occurs by channel monitoring.
Claim 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over R1-2106601 (“601”) (Author Unknown, Discussion on reduced maximum UE bandwidth, Doc. No. R1-2106601, pages 1-9, 27 August 2021) and Tran, et al. (US Pre Grant Publication No. 2023/0362796) in view of Kim II, et al. (US Pre Grant Publication No. 2023/0142130 A1)
Regarding claim 12, 601 discloses receiving a SIB corresponding to a non-RedCap-Specific initial downlink BWP. (601 discloses that the UE may receive some SIB information in the non-Redcap-Specific initial BWP (page 3, paragraph after last bold dot, case 2 – the UE receives SIB1 and other SIBs via the legacy initial DL BWP/ non-RedCap-Specific initial downlink BWP].)
601 fails to explicitly disclose the SIB indicates a mode that the UE is to use to obtain system information. In the same field of endeavor, Kim, in view of 601, discloses the SIB indicates a mode that the UE is to use to obtain system information.
That is, 601 discloses the SIB1 is received in a system information block (SIB) corresponding to a non-RedCap-Specific initial downlink BWP, but does not disclose information on the SIB1 (see discussion, supra), such as that is contains Scheduling information that indicates the reception mode for the additional SIBs/system information.
The system of Kim II discloses the SIB indicates a mode that the UE is to use to obtain system information, as it discloses schedulingInfoList is received, which indicates which subsequest SIBs are to be obtained via a broadcast mode or an on demand requesting mode (paragraphs 0173-199).
Therefore, since Kim II discloses the use of scheduling info to determine if a SIB is received via broadcast or on-demand mode, it would have been obvious to a person of ordinary skill in the art at the time of the invention to combine the scheduling info of Kim II with the system of 601 by receiving the SIB1 via the non-Redcap-Specific initial BWP, as taught by 601, and reading the SIB1 to determine the scheduling information determining the scheduling mode of reception of the other SIBs as broadcast or on-demand. The motive to combine is to allow the UE to receive SIBs in the most efficient mode, with infrequently updated or required SIBs being provided by on-demand requests to lower broadcast overhead.
Claims 13 and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over R1-2106601 (“601”) (Author Unknown, Discussion on reduced maximum UE bandwidth, Doc. No. R1-2106601, pages 1-9, 27 August 2021) and Tran, et al. (US Pre Grant Publication No. 2023/0362796) as applied to claim 1 and further in view of R1-2107931 (Author Unknown, Discussion on the transmission of system information for RedCap, Doc. No. R1-2107931, pages 1-2, 27 August 2021)
Regarding claims 13, 601 fails to disclose the SIB is associated with one or more RedCap-specific transmission parameters. In the same field of endeavor, 931 discloses the SIB is associated with one or more RedCap-specific transmission parameters. (pages 1-2, discussion; section 1 – RedCap Specific information included in legacy SIB1; note also in particular first paragraph of section 2 – redcap specific IEs can relate to uplink BWP configuration/transmission parameters; in particular page 1, last full paragraph – redcap specific SIB1 with redcap specific IEs)
Therefore, since 931 discloses SIBs containing one or more RedCap-specific transmission parameters, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to combine the RedCap-specific transmission parameters of 931 with the system of 601 by transmitting some of the SIBs of 931 that are transmitted in the RedCap-specific initial downlink BWP as RedCap specific SIBs, as taught by both 601 and 931, that contain RedCap-specific transmission parameters, as taught by 931. The motive to combine is to allow the configuration of transmission parameters specific to RedCAp in the RedCap-specific initial downlink BWP to offload/reduce the load of the required transmission of these parameters from the non RedCap-specific initial downlink BWP.
Regarding claim 24, 601 discloses the SIB is associated with one or more RedCap-specific SIB. (601 discloses that the base station transmits to the UE on the second communication/seperate initial downlink BWP one or more SIBs in RedCap-specific SIBs [pages 3-4, starting with last bold dot of page 3, discussion of case 4 – in particular table 1 on page 4, case 4 offloads system informaiton/SIBs to the RedCap-specific initial downlink BWP and the SI may include RedCap Speecific SI (“FFS SI specifically for RedCap”))
601 fails to disclose one or more RedCap-specific transmission parameters. In the same field of endeavor, 931 discloses one or more RedCap-specific transmission parameters.
That is, 601 suggests the existence of redcap specific SIBs, but does not give any details.
931 discloses one or more RedCap-specific transmission parameters, as it discloses that redcap dedicated IEs related to transmission parameters for RedCap contained in, for example SIB1 (pages 1-2, discussion; in particular first paragraph of section 2 – redcap specific IEs can relate to uplink BWP configuration/transmission parameters; in particular page 1, last full paragraph – redcap specific SIB1 with redcap specific IEs)
Therefore, since 931 discloses SIBs containing one or more RedCap-specific transmission parameters, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to combine the RedCap-specific transmission parameters of 931 with the system of 601 by transmitting some of the SIBs of 931 that are transmitted in the RedCap-specific initial downlink BWP as RedCap specific SIBs, as taught by both 601 and 931, that contain RedCap-specific transmission parameters, as taught by 931. The motive to combine is to allow the configuration of transmission parameters specific to RedCAp in the RedCap-specific initial downlink BWP to offload/reduce the load of the required transmission of these parameters from the non RedCap-specific initial downlink BWP.
Claim 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over R1-2106601 (“601”) (Author Unknown, Discussion on reduced maximum UE bandwidth, Doc. No. R1-2106601, pages 1-9, 27 August 2021) and Tran, et al. (US Pre Grant Publication No. 2023/0362796) as applied to claim 1 and further in view of Maki, et al. (US Pre Grant Publication No. 2023/0276347)
Regarding claim 14, 601 discloses receiving at least one synchronization signal block (SSB) corresponding to the RedCap-specific initial downlink BWP (601 discloses that an additional SSB dedicated/corresponding to the separate initial DL BWP/RedCap-specific initial downlink BWP is configured [pages 5-6, last dot of page 5 to proposal 9 on page 6 – note in particular fig. 1(b) – the RedCAP BWP has a dedicated/corresponding 2nd SSB].)
601 fails to discloses and obtaining one or more radio resource management measurements based at least in part on the at least one SSB. In the same field of endeavor, Maki discloses one or more radio resource management measurements based at least in part on the at least one SSB (Maki discloses that a RedCap UE may use the additional SSB to perform RRM measurements [paragraphs 0298, 315].)
Therefore, since Maki discloses performing SSB based RRM measurements, it would have been obvious to a person of ordinary skill in the art at the time of the invention to combine the SSB based RRM measurements of Maki with the system of 601 by performing SSB based RRM measurements in the SSB that corresponds to the RedCap-specific initial downlink BWP after entering into the RRC connected mode. The motive to combine is provided by Maki and is to improve RRM measurement accuracy (paragraph 0315).
Claim 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over R1-2106601 (“601”) (Author Unknown, Discussion on reduced maximum UE bandwidth, Doc. No. R1-2106601, pages 1-9, 27 August 2021) and Tran, et al. (US Pre Grant Publication No. 2023/0362796) as applied to claim 1 and further in view of Li, et al. (US Pre Grant Publication No. 2024/0040477 A1)
Regarding claim 15, 601 discloses switching, after switching to the RedCap-specific initial downlink BWP, to the non-RedCap-specific initial downlink BWP. (After connected mode is complete the UE may re-enter into the idle mode where the UE connects to the non-Redcap-specific initial downlink BWP after re-entry into the area of the base station in idle mode [page 2, proposal 3, case 1 – disclosing RRC inactive UE uses legacy/non-RedCap-specific intitial downlink BWP].)
601 fails to disclose switching to a non-RedCap-Specific initial downlink BWP and receiving at least one of a cell barring indication or a unified access control indication via the non-RedCap-Specific initial downlink BWP. In the same field of endeavor, Li, in view of 601, discloses switching to a non-RedCap-Specific initial downlink BWP; and receiving at least one of a cell barring indication or a unified access control indication via the non-RedCap-Specific initial downlink BWP.
That is, as discussed, supra, 601 discloses switching to a non-RedCap-Specific initial downlink BWP and receiving SIB 1, but does not disclose the contents of SIB1 would include cell barring information.
The system of Li discloses receiving at least one of a cell barring indication or a unified access control indication via the SIB1 (UE receives SI indicating if access is barred via SIB1 [paragraphs 0047-0052; 0041 – UE can be a RedCap UE]).
Therefore, since Li discloses the SIB1 contains cell barring information, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to combine the cell barring SIB1 of Li with the system of 601 by receiving the SIB1 on the non-RedCap-Specific initial downlink BWP, as taught by 601, with the SIB1 containing access barring indications, as taught by Li. The motive to combine is to allow the UE to receive common information in the SIB1 on the non-RedCap-Specific initial downlink BWP so it does not need to be re-broadcast on the RedCap-Specific initial downlink BWP, wasting resources by duplicitous transmission.
Claims 16, 17 and 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over R1-2106601 (“601”) (Author Unknown, Discussion on reduced maximum UE bandwidth, Doc. No. R1-2106601, pages 1-9, 27 August 2021) and Tran, et al. (US Pre Grant Publication No. 2023/0362796) as applied to claim 1 and further in view of R1-2108498 (“498”) (Author Unknown, FL summary #6 on reduced maximum UE bandwidth for RedCap, Doc. No. R1-2108498 pages 1-143, 27 August 2021)
Regarding claim 16, 601 discloses monitoring the control channel comprises monitoring for a random access MSG2 configured within the RedCap-specific initial downlink BWP. (Looking to case 1 and mapping the control information to MSG2 in the independent claim, 601 discloses that the UE searches only for MSG2 in the RedCap-specific initial downlink BWP and not other search spaces, such as the paging search space and other system information search space, which are both placed on the non RedCap-specific initial downlink BWP/legacy initial BWP [see pages 2-3 case 1, UE looks for paging search space on legacy initial BWP and also receives SIs, including other SI there; UE only looks to RedCap-specific initial downlink BWP/separate DL initial BWP].)
601 fails to disclose monitoring a random access search space configured within the RedCap-specific initial downlink BWP. In the same field of endeavor, 498, in view of 601, discloses monitoring a random access search space configured within the RedCap-specific initial downlink BWP.
That is, as discussed, supra 601 discloses monitoring for a random access MSG2 configured within the RedCap-specific initial downlink BWP and not monitoring the SIs or paging on the the RedCap-specific initial downlink BWP, instead monitoring these on the non RedCap-specific initial downlink BWP. However, 601 is lacking in technical details, such as the details of the MSG2 being in a configured random access search space and the other SIs and paging messages being associated with their own search spaces.
In the same field of endeavor, 498 discloses monitoring a random access search space configured within the RedCap-specific initial downlink BWP. That is, 498 discloses that the UE, in accordance with the Vivo update [i.e. the precursor to 601, submitted by vivo] includes single random access search space/ra-SearchSpace that is configured in the RedCap-specific initial downlink BWP/separate initial DL BWP [page 81, Nordic disclosure – UE configured with a single ra-SearchSpace; page 98 – “UE expect to be configured with ra-SearchSpace in separate initial DL BWP”. 498 further dislcoses the use of a paging and other-SI search space [page 81, Nordic disclosure].)
Therefore, since 498 discloses the use of a random access search space on the RedCap-specific initial downlink BWP/separate initial DL BWP, it would have been obvious to a person of ordinary skill in the art at the time of the invention to receive the MSG2 of random access of 601 in the downlink random access search space of the RedCap-specific initial downlink BWP/separate initial DL BWP and to receive the SI and paging on the non RedCap-specific initial downlink BWP, as taught by 601 with the SI including an other SI search space and a paging search space in accordance with 498 such that only the random access search space is on the RedCap-specific initial downlink BWP/separate initial DL BWP. The motive to combine is to switching times of the UE by only requiring it to switch to the RedCap-specific initial downlink BWP/separate initial DL BWP during random access instead of requiring frequent switching between the RedCap-specific initial downlink BWP/separate initial DL BWP and non RedCap-specific initial downlink BWP.
Regarding claim 17, 601 as modified by 498 discloses the RedCap-specific initial downlink BWP contains only one search space, the one search space comprising the random access search space (see claim 16, supra)
Regarding claim 25, 601 discloses the RedCap-specific initial downlink BWP contains a random access MSG2. (Looking to case 1, 601 discloses that the base station send MSG2 in the RedCap-specific initial downlink BWP and not other search spaces, such as the paging search space and other system information search space, which are both placed on the non RedCap-specific initial downlink BWP/legacy initial BWP [see pages 2-3 case 1, UE looks for paging search space on legacy initial BWP and also receives SIs, including other SI there; UE only looks to RedCap-specific initial downlink BWP/separate DL initial BWP].)
601 fails to disclose monitoring a random access search space configured within the RedCap-specific initial downlink BWP. In the same field of endeavor, 498, in view of 601, discloses monitoring a random access search space configured within the RedCap-specific initial downlink BWP.
That is, as discussed, supra 601 discloses monitoring for a random access MSG2 configured within the RedCap-specific initial downlink BWP and not monitoring the SIs or paging on the RedCap-specific initial downlink BWP, instead monitoring these on the non RedCap-specific initial downlink BWP. However, 601 is lacking in technical details, such as the details of the MSG2 being in a configured random access search space and the other SIs and paging messages being associated with their own search spaces.
In the same field of endeavor, 498 discloses monitoring a random access search space configured within the RedCap-specific initial downlink BWP. That is, 498 discloses that the UE, in accordance with the Vivo update [i.e. the precursor to 601, submitted by vivo] includes single random access search space/ra-SearchSpace that is configured in the RedCap-specific initial downlink/second communication BWP/separate initial DL BWP [page 81, Nordic disclosure – UE configured with a single ra-SearchSpace; page 98 – “UE expect to be configured with ra-SearchSpace in separate initial DL BWP”. 498 further discloses the use of a paging and other-SI search space [page 81, Nordic disclosure].)
Therefore, since 498 discloses the use of a random access search space on the RedCap-specific initial downlink BWP/separate initial DL BWP/second communication, it would have been obvious to a person of ordinary skill in the art at the time of the invention to receive the MSG2 of random access of 601 in the downlink random access search space of the RedCap-specific initial downlink BWP/separate initial DL BWP/second communication and to transmit the SI and paging on the non RedCap-specific initial downlink BWP/first communication, as taught by 601 with the SI including an other SI search space and a paging search space in accordance with 498 such that only the random access search space is on the RedCap-specific initial downlink BWP/separate initial DL BWP/second communication. The motive to combine is to switching times of the UE by only requiring it to switch to the RedCap-specific initial downlink BWP/separate initial DL BWP during random access instead of requiring frequent switching between the RedCap-specific initial downlink BWP/separate initial DL BWP and non RedCap-specific initial downlink BWP.
Claim(s) 31 is/are rejected under 35 U.S.C. 103 as being unpatentable over R1-2106601 (“601”) (Author Unknown, Discussion on reduced maximum UE bandwidth, Doc. No. R1-2106601, pages 1-9, 27 August 2021) and Tran, et al. (US Pre Grant Publication No. 2023/0362796) as applied to claim 29 and further in view of R1-2106841 (Author Unknown, Bandwidth reduction for reduced capability NR devices, pages 1-7, 27 August 2021)
Regarding claim 31, 601 fails to disclose a bandwidth of the control channel is less than the RedCap Specific Initial Downlink BWP. In the same field of endeavor, 841 discloses a bandwidth of the control channel is less than the RedCap Specific Initial Downlink BWP (pages 5-6, Issue #9, especially Fig. 4 – the bandwidth of the RedCap Coreset in idle mode is less than the bandwidth of the control channel for the RedCap UE).
Therefore, since 841 suggests a control channel/coreset/PO that is less than the overall bandwidth of the RedCap Specific Initial Downlink BWP, it would have been obvious to a person of ordinary skill in the art at the time of the of the invention to combine the idle paging of 841 with the system of 601 by implementing a CORESET with a bandwidth less than the RedCap Specific Initial Downlink BWP. The motive to combine is to reduce UE usage by using a dedicated paging opportunity and to further improve efficiency by not using the entire BWP so that other devices may use the remainder for other functions.
Allowable Subject Matter
Claims 2, 5, 6, 7, 9-11, 22 and 23 allowed.
Regarding claim 2, the prior art fails to teach suggest or disclose the control channel comprises a paging control channel (PCCH). That is, the closest prior art of 601 teaches only one embodiment that meets the requirements of claim 1, case 1. However, in case 1, paging functions are not offloaded from the legacy/non-Redcap initial DL BWP and remain at the Legacy/non-Redcap initial DL BWP. Therefore, the prior art fails to teach, suggest or disclose all elements of the claimed invention. Furthermore, no other art teaching this feature could be located. Therefore, the prior art fails to teach suggest or disclose all elements of the invention.
Regarding claim 5 and 22, the prior art fails to teach, suggest or disclose switching, after performing the RACH procedure, from the RedCap-specific initial downlink BWP to the non-RedCap-specific initial downlink BWP and monitoring a broadcast control channel (BCCH) corresponding the BCCH, wherein the
BCCH corresponds to the non-RedCap-specific initial downlink BWP, wherein the BCCH corresponds to and has a bandwidth that is less than or equal to a maximum bandwidth capability of the UE. That is, no art in which the BCCH corresponds to and has a bandwidth that is less than or equal to a maximum bandwidth capability of the UE could be located, let alone art in which this is done after re-connected to the initial downlink BWP after the RACH procedure. Therefore, the prior art fails to teach, suggest or disclose all elements of the claimed invention.
Regarding claim 6, the claim depends from claim 5 and is allowable for at least the reasons stated with respect to claim 5, supra.
Regarding claim 7, the prior art fails to teach, suggest or disclose the control channel comprises- a broadcast control channel (BCCH) configured within the RedCap specific initial downlink BWP the BCCH. That is, 601 discloses that the UE uses the BCCH at the legacy/non-Redcap initial DL BWP and does not use the redcap DL BWP for this function in case 1. Furthermore, no other art that teaches this element in a way it is combinable with the elements of 601 could be located. Therefore, the prior art fails to teach, suggest or disclose all elements of the claimed invention.
Regarding claim 9, the prior art fails to teach, suggest or disclose receiving, via the control channel, a RedCap-specific short message that indicates a RedCap-specific system information update. That is, 601, in case 1, does not disclose the use of system information update short messages sent in the redcap-specific channel. Furthermore, no other art that teaches this element in a way it is combinable with the elements of 601 could be located.
Regarding claim 10, the prior art fails to teach, suggest or disclose transmitting, via a random access channel procedure corresponding to the RedCap specific initial downlink BWP the RACH procedure, a request for on-demand system information. That is, 601, in case 1, does not disclose the use of an on demand messages sent in the redcap-specific channel. Furthermore, no other art that teaches this element in a way it is combinable with the elements of 601 could be located.
Regarding claim 11 the prior art fails to teach, suggest or disclose receiving, during the RACH procedure, a UE-specific signal corresponding to a physical downlink shared channel associated with the UE, wherein the UE-specific signal includes an updated system information block. That is, 601, in case 1, does not disclose updates sent in the redcap-specific channel. Furthermore, no other art that teaches this element in a way it is combinable with the elements of 601 could be located.
Regarding claim 23 the prior art fails to teach, suggest or disclose wherein the first control channel comprises a first instance of- a broadcast control channel (BCCH) the BCCH, and wherein the second control channel comprises a second instance of the BCCH, wherein the first communication comprises a first instance of at least one of a master information block (MIB) or the SIB1, and wherein the second communication comprises a second instance of the at least one of the MIB or the SIB. That is, 601, in case 1, does not disclose re-sending SIB1 or MIB in the second communication. Furthermore, no other art that teaches this element in a way it is combinable with the elements of 601 could be located.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER M CRUTCHFIELD whose telephone number is (571)270-3989. The examiner can normally be reached 9am-5pm M-F.
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, Faruk Hamza can be reached on (571) 272-7969. 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.
/CHRISTOPHER M CRUTCHFIELD/Primary Examiner, Art Unit 2466
Prosecution Insights