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 .
Status of the Claims
The office action is in response to the claim amendments and remarks filed on December 19, 2025 for the application filed January 18, 2023. Claims 1, 5, 9, 10, and 14 have been amended. Claims 2-4, 8, 11-13, and 15-20 have been canceled. Claims 21-31 have been added. Claims 1, 5-7, 9-10, 14, and 21-31 are currently pending.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 6, 9, 10, 21, 24, 25, 26, 29 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Fei et al. (US2024/0049205A1).
Regarding claim 1, Fei teaches a method comprising: transmitting by a user equipment (UE) to a base station, a random access preamble; receiving, by the UE from the base station, a random access response; transmitting, by the UE to the base station, a physical uplink shared channel (PUSCH) based on the random access response; receiving, by the UE from the base station, a physical downlink shared channel (PDSCH) for a contention resolution (Paragraph [0263]: determining the first resource for the first type of terminal to transmit the PUCCH based on indication information carried in a contention resolution message transmitted by a network side device during a random access procedure of the first type of terminal; Paragraph [0264]: in the present embodiment, the first resource for the first type of terminal to transmit the PUCCH is determined based on indication information carried in a contention resolution message transmitted by a network side device during a random access procedure of the first type of terminal. For example, indication information for a frequency location of the PUCCH is transmitted by the gNB to the RedCap UE through Msg4 (also known as a contention resolution message) in the fourth step of the random access procedure and the RedCap UE can determine the frequency domain resource for the PUCCH based on the indication information carried in the Msg4. The indication information may directly indicate the frequency location where the first PRB for PUCCH is located.)
and transmitting, by the UE to the base station, a physical uplink control channel (PUCCH) including hybrid automatic repeat request-acknowledgement (HARQ-ACK) information, wherein a frequency hopping (FH) of the PUCCH is disabled, and the UE determines a frequency resource of the PUCCH based on a first resource block (RB) offset and an additional RB offset; (Paragraph [0234]: In the present embodiment, in case that the first resource is the resource for PUCCH transmission without frequency hopping, the determining the first resource for PUCCH transmission includes any one or more of: Paragraph [0235]: A, determining the first resource for the first type of terminal to transmit the PUCCH based on a frequency location corresponding to the first hop and/or the frequency location corresponding to the second hop when the second type of terminal transmits the PUCCH; where the maximum bandwidth supported by the second type of terminal is larger than the first preset value. Paragraph [0236]: In the present embodiment, the second type of terminal and the first type of terminal are different terminals. For example, the first type of terminal may be a reduced capability terminal (such as RedCap UE), and the second type of terminal may a non-reduced capability terminal (such as non-RedCap UE) or a general terminal or a normal terminal or a traditional terminal. Paragraph [0242]: On the basis of the above methods, the PUCCH resources used by the RedCap UE and the traditional UE may be not interlaced by any of the following methods. Paragraph [0243]: (1) An offset RBRedcap offset is introduced for determining the frequency location for the PUCCH transmitted by the RedCap UE. Paragraph [0246]: (2) A value of the RBBWP offset used by the RedCap UE is enabled to be different from a value of the RBBWP offset used by the traditional UE through a predefinition and/or indication method. (Also see paragraphs [0243] - [0245]). Paragraph [0265]: By the method according to the present embodiment, it can be ensured that the RedCap UE can always correctly transmit the PUCCH before obtaining the user-specific RRC configuration. In the present embodiment, the PUCCH is transmitted without frequency hopping, and the UE only needs to determine one resource location associated with the PUCCH to transmit the PUCCH, which is simple to implement.)
wherein the first RB offset is related to a PUCCH resource set among PUCCH resource sets (Paragraph [0052]: In an embodiment, in case that the first resource is the resource for PUCCH transmission without frequency hopping, determining the first resource for PUCCH transmission includes any one or more of: Paragraph [0053]: determining the first resource for the first type of terminal to transmit the PUCCH based on a frequency location corresponding to a first hop and/or a frequency location corresponding to a second hop when a second type of terminal transmits the PUCCH, where a maximum bandwidth supported by the second type of terminal is larger than the first preset value. Paragraph [0058]: In an embodiment, in case of determining the first resource for the first type of terminal to transmit the PUCCH based on the frequency location corresponding to the first hop and/or the frequency location corresponding to the second hop when the second type of terminal transmits the PUCCH, the determining the first resource for PUCCH transmission includes any one or more of: Paragraph [0059]: determining a first frequency offset RBBWP offset corresponding to the first type of terminal through a predefinition and/or indication method, where the first frequency offset RBBWP offset corresponding to the first type of terminal is different from the first frequency offset RBBWP offset corresponding to the second type of terminal. Paragraph [0237]: In the present embodiment, in case that the first type of terminal transmits the PUCCH resource without frequency hopping, the first resource for PUCCH transmission may reuse a frequency location corresponding to the first hop (hop1) or the second hop (hop2) when the traditional normal terminal (the second type of terminal) transmits the PUCCH with frequency hopping. That is, the first resource for the first type of terminal to transmit the PUCCH can be determined based on the frequency location corresponding to the first hop and/or the frequency location corresponding to the second hop when the second type of terminal transmits the PUCCH. Examiner’s note: Paragraphs [0238] - [0240] describe the RBBWP offset used to determine the first RB offset for common PUCCH resource sets used by the legacy UEs. Paragraph [0242]: In case that the RedCap UE and the traditional UE completely share the above formulas and the parameter RBBWP offset, the PUCCH resources used by the RedCap UE and the traditional UE are likely to interlace. On the basis of the above methods, the PUCCH resources used by the RedCap UE and the traditional UE may be not interlaced by any of the following methods.)
wherein the additional RB offset is a cell-specific offset parameter included in a reduced capability (RedCap)-specific initial uplink bandwidth part (BWP) configuration information (Paragraph [0196]: User-specific RRC configuration may configure suitable PUCCH transmission resources for the RedCap UE. Paragraph [0243]: (1) An offset RBRedcap offset is introduced for determining the frequency location for the PUCCH transmitted by the RedCap UE. See paragraphs [0243] - [0245]. Paragraph [0246]: (2) A value of the RBBWP offset used by the RedCap UE is enabled to be different from a value of the RBBWP offset used by the traditional UE through a predefinition and/or indication method. Paragraph [0247]: It should be noted that this method makes the PUCCH resources used by the RedCap UE and the PUCCH resources used by the traditional UE not interlaced. Examiner’s note: In addition to the RBBWP offset, an offset RBRedcap offset is introduced for determining the frequency location for the PUCCH transmitted by the RedCap UE. See paragraph [0244] for the equation indicating a first RB offset, and an additional RB offset. Paragraph [0260]: a frequency location of the L-th PRB for the PUCCH is a location determined based on a frequency location of the K-th PRB for Msg1 or Msg3 plus a frequency offset, where the frequency offset may be predefined or transmitted (such as in SIB1 or DCI) and indicated by the network side device; Paragraph [0291]: In the present embodiment, the frequency location of PUCCH is determined based on a frequency location of a given uplink channel transmitted by the UE. For example, the given uplink channel may be Msg1 or Msg3. The frequency location for the PUCCH transmission is determined based on a frequency location of Msg1 or Msg3. For example, a frequency location of the first PRB for the PUCCH is the same as a frequency location of the first PRB for Msg1 or Msg3; or a frequency location of the L-th PRB for the PUCCH is the same as a frequency location of the K-th PRB for Msg1 or Msg3; or a frequency location of the L-th PRB for the PUCCH is a location determined based on a frequency location of the K-th PRB for Msg1 or Msg3 plus a frequency offset, where the frequency offset may be predefined or transmitted (such as in SIB1 or DCI) and indicated by the network side device. Examiner’s note: Paragraph [0544] of the specification mentions that the offset is included in the SIB1 and transmitted.)
and wherein the RedCap-specific BWP configuration information is configured based on that a size of an initial uplink BWP is larger than a maximum size supported by the UE (Paragraph [0225]: For the predefined mode, for example, it may be predefined directly through a protocol that the RedCap UE does not perform the PUCCH transmission with frequency hopping before obtaining user-specific RRC configuration; or that in case that the bandwidth of UL BWP (such as UL initial BWP) of the RedCap UE is larger than a threshold value (such as the maximum bandwidth supported by the RedCap UE), the PUCCH transmission with frequency hopping is not performed. Paragraph [0227]: For the combination of both predefined mode and the mode indicated by the network side device, in case that the bandwidth of UL BWP (such as UL initial BWP) of the RedCap UE is larger than a threshold value (such as the maximum bandwidth supported by the RedCap UE), the PUCCH is not transmitted with frequency hopping; and in case that the bandwidth of UL BWP of the RedCap UE is less than or equal to the threshold value, it is determined whether to perform the PUCCH transmission with frequency hopping based on the frequency hopping indication information from the gNB. The combination of both predefined mode and the mode indicated by the network side device combines the advantages of indication overhead saving and flexibility, and is a relatively compromised solution.)
Regarding claim 6, Fei teaches the method of claim 1 (see rejection for claim 1);
wherein the random access response is received based on a frequency retuning based on a resource for the random access response being not included in the bandwidth of the UE (Paragraph [0308]: In the present embodiment, a possible value of
R
B
R
e
d
c
a
p
o
f
f
s
e
t
maybe
8
N
C
S
+
1
which may ensure that the PUCCH resources used by the RedCap UE and the general NR UE do not interlace. RBRedcap offset may also be other values, for example, may be the frequency location of the first PRB or the frequency location of the center PRB of the resources occupied by Msg1 or Msg3. This design is especially suitable for frequency division duplexing (FDD) systems, and no retuning is required when the PUCCH is transmitted over the uplink frequency band since a frequency at which the RedCap UE transmits the PUCCH is close to the frequency of Msg1 or Msg3. In the FDD systems, a possible value of RBRedcap offset may be the frequency location of the first PRB or the frequency location of the center PRB of the resources occupied by Msg1 or Msg3.)
Regarding claim 9, Fei teaches a device comprising; at least one processor; and at least one memory operably connectable to the at least one processor and storing instructions that, based on being executed by the at least one processor, perform operations comprising (Paragraph [0005]: Embodiments of the present application provide methods and apparatuses for channel transmission, a terminal, a network side device, and a storage medium, which solve the problem that a reduced capability (RedCap) user equipment (UE) fails to correctly transmit an uplink channel, such as a physical uplink control channel (PUCCH), in an uplink initial bandwidth part (UL initial BWP) since a frequency interval between two hops for the PUCCH is larger than the maximum bandwidth of the RedCap UE. Paragraph [0674]: FIG. 14 is a schematic structural diagram of a terminal according to an embodiment of the present application. The terminal includes a memory 1420, a transceiver 1400, and a processor 1410. Paragraph [0677]: The memory 1420 is used to store a computer program; the transceiver 1400 is used to transmit and receive data under a control of the processor 1410; and the computer program, when executed by the processor 1410, causes the processor 1410 to perform the following operations of:)
transmitting, to a base station, a random access preamble; receiving, from the base station, a random access response; transmitting, to the base station, a physical uplink shared channel (PUSCH) based on the random access response; receiving, from the base station, a physical downlink shared channel (PDSCH) for a contention resolution; and transmitting, to the base station, a physical uplink control channel (PUCCH) including hybrid automatic repeat request-acknowledgement (HARQ-ACK) information, wherein a frequency hopping (FH) of the PUCCH is disabled, and the device determines a frequency resource of the PUCCH based on a first resource block (RB) offset and an additional RB offset;
wherein the first RB offset is related to a PUCCH resource set among PUCCH resource sets, wherein the additional RB offset is a cell-specific offset parameter included in a reduced capability (RedCap)-specific initial uplink bandwidth part (BWP) configuration information, and wherein the RedCap-specific BWP configuration information is configured based on that a size of an initial uplink BWP is larger than a maximum size supported by the device (see rejection for claim 1).
Regarding claim 10, Fei teaches a method comprising: receiving, by a base station (BS) from a user equipment (UE), a random access preamble; transmitting, by the BS to the UE, a random access response; receiving, by the BS from the UE, a physical uplink shared channel (PUSCH) based on the random access response; transmitting, by the BS to the UE, a physical downlink shared channel (PDSCH) for a contention resolution, and receiving, by the BS from the UE, a physical uplink control channel (PUCCH) including hybrid automatic repeat request-acknowledgement (HARQ-ACK) information, wherein the frequency hopping (FH) of the PUCCH is disabled, and a frequency resource of the PUCCH is determined based on a first resource block (RB) offset and an additional RB offset; wherein the first RB offset is related to a PUCCH resource set among PUCCH resource sets, wherein the additional RB offset is a cell-specific offset parameter included in a reduced capability (RedCap)-specific initial uplink bandwidth part (BWP) configuration information, and wherein the RedCap-specific BWP configuration information is configured based on that a size of an initial uplink BWP is larger than a maximum size supported by the UE (see rejection for claim 1).
Regarding claim 21, Fei teaches the method of claim 1 (see rejection for claim 1);
wherein the UE is a RedCap UE and is not configured with dedicated PUCCH configuration information (Paragraph [0196]: User-specific RRC configuration may configure suitable PUCCH transmission resources for the RedCap UE. However, before obtaining the user-specific RRC configuration, the UE may only obtain a PUCCH resource set in a predefined mode. The predefined PUCCH resource set may be considered as a “common PUCCH” resource set since it is the same for all UEs. Paragraph [0265]: User-specific RRC configuration may configure suitable PUCCH transmission resources for the RedCap UE. However, before obtaining the user-specific RRC configuration, the UE may only obtain a PUCCH resource set in a predefined mode. The predefined PUCCH resource set may be considered as a “common PUCCH” resource set since it is the same for all UEs.)
Regarding claim 24, Fei teaches the device of claim 9 (see rejection for claim 9);
wherein the device is a RedCap UE or a processing device configured to control the RedCap UE (Paragraph [0005]: Embodiments of the present application provide methods and apparatuses for channel transmission, a terminal, a network side device, and a storage medium, which solve the problem that a reduced capability (RedCap) user equipment (UE) fails to correctly transmit an uplink channel, such as a physical uplink control channel (PUCCH), in an uplink initial bandwidth part (UL initial BWP) since a frequency interval between two hops for the PUCCH is larger than the maximum bandwidth of the RedCap UE. Paragraph [0200]: Embodiments of the present application provide methods and apparatuses for channel transmission, a terminal, a network side device, and a storage medium. In case that the RedCap UE transmits the PUCCH in the UL initial BWP, the bandwidth range of the first resource for PUCCH transmission is determined to be less than or equal to the maximum bandwidth supported by the RedCap UE.)
Regarding claim 25, Fei teaches the device of claim 9 (see rejection for claim 9);
further comprising: at least one transceiver (Paragraph [0674]: FIG. 14 is a schematic structural diagram of a terminal according to an embodiment of the present application. The terminal includes a memory 1420, a transceiver 1400, and a processor 1410. Paragraph [0677]: The memory 1420 is used to store a computer program; the transceiver 1400 is used to transmit and receive data under a control of the processor 1410; and the computer program, when executed by the processor 1410, causes the processor 1410 to perform the following operations of: Also see Paragraph [0678].)
Regarding claim 26, Fei teaches the device of claim 9 (see rejection for claim 9);
wherein the device is not configured with dedicated PUCCH configuration information (see rejection for claim 21).
Regarding claim 29, Fei teaches the method of claim 10 (see rejection for claim 10);
wherein the UE is a RedCap UE and is not configured with dedicated PUCCH configuration information (see rejection for claim 21).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 5, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Fei et al. (US2024/0049205A1) in view of MolavianJazi et al. (US2021/0076384A1).
Regarding claim 5, Fei teaches the method of claim 1 (see rejection for claim 1);
Fei does not explicitly teach wherein the random access response includes a frequency hopping flag for the PUSCH, and wherein the PUSCH is transmitted without frequency hopping based on that the frequency hopping flag is set to '0'.
However, MolavianJazi teaches wherein the random access response includes a frequency hopping flag for the PUSCH, and wherein the PUSCH is transmitted without frequency hopping based on that the frequency hopping flag is set to '0' (Paragraph [0115]: The (frequency) resource allocation for Msg3 (as identified in the RAR UL grant) in LTE includes: a 1-bit frequency hopping flag; and a 10-bit resource block assignment. Paragraph [0119]: N_{UL, hop}=0 if the frequency hopping flag is 0 (i.e., disabled). Paragraph [0164]: In the following and throughout the present disclosure, the terms “NR-Light UE,” “reduced capability UE” or “RedCap UE,” and “BL/CE UE” are used interchangeably to refer to a UE or a group of UEs with reduced cost and/or complexity and/or capability, such as reduced bandwidth. Paragraph [0130]: The resource allocation for Msg3 (as identified in the RAR UL grant) in NR specification includes: a 1-bit frequency hopping flag. Paragraph []0136]: N_{UL, hop}=0 if the frequency hopping flag is 0 (i.e., disabled). Paragraph [0221]: In one example, at least some of the methods described below for relaxed scheduling of Msg3 can apply to PUSCH/PDSCH transmissions after Msg3. Examiner’s note: Table 3 shows the RAR UL Grant Content Field Size for NR-Light UE, and PUSCH frequency and time resource allocations, and indicates that the Frequency hopping flag for NR-Light is set to ‘0. Paragraph [0223]: In one example of UL BWP for Msg3, a new field is introduced in the RAR UL grant that indicates the UL BWP index for Msg3 PUSCH transmission.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the random access response includes a frequency hopping flag for the PUSCH, and wherein the PUSCH is transmitted without frequency hopping based on that the frequency hopping flag is set to '0', as taught by MolavianJazi in the system of Fei, in order to include a frequency resource allocation for the Msg3, and to support the RAR UL Grant Content Field Size for NR-Light UE or RedCap UE (MolavianJazi: Paragraphs [0164], [0221], Table 3).
Regarding claim 14, Fei teaches the method of claim 10 (see rejection for claim 10);
Fei does not explicitly teach wherein the random access response includes a frequency hopping flag for the PUSCH, and wherein the PUSCH is received without frequency hopping based on that the frequency hopping flag is set to '0'.
However, MolavianJazi teaches wherein the random access response includes a frequency hopping flag for the PUSCH, and wherein the PUSCH is received without frequency hopping based on that the frequency hopping flag is set to '0' (see rejection for claim 5);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to wherein the random access response includes a frequency hopping flag for the PUSCH, and wherein the PUSCH is received without frequency hopping based on that the frequency hopping flag is set to '0', as taught by MolavianJazi in the system of Fei, in order to include a frequency resource allocation for the Msg3, and to support the RAR UL Grant Content Field Size for NR-Light UE or RedCap UE (MolavianJazi: Paragraphs [0164], [0221], Table 3).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Fei et al. (US2024/0049205A1) in view of Rastegardoost et al. (US2024/0031056A1).
Regarding claim 7, Fei teaches the method of claim 6 (see rejection for claim 6);
Fei does not explicitly teach wherein a starting location of a random access response window is configured by system information.
However, Rastegardoost teaches wherein a starting location of a random access response window is configured by system information (Paragraph [0286]: In an example, a network may identify RedCap UEs during Msg1/MsgA transmission, e.g., based on dedicated preamble and/or dedicated PRACH occasion and/or dedicated initial UL BWP. For example, a first type wireless device (e.g., a RedCap UE) may use a first time/frequency/code resource for a first preamble. The first time/frequency/code resource may be determined based on a first PRACH configuration and/or a first UL BWP. Paragraph [0287]: A base station may transmit a first PDSCH comprising one or more RARs for the first type wireless device. Paragraph [0307]: For example, the first parameters may indicate for a RACH configuration: one or more preambles, each associated with one or more SSBs, wherein one or more first preambles if the preambles may be dedicated/specific to first-type UEs. Paragraph [0310]: In an example, the one or more parameters may indicate a first processing time for the first-type UEs (e.g., a N1 minimum PDSCH processing time, and/or a N2 minimum PUSCH preparation time), that may be different from a second processing time of a second-type UEs (e.g., normal/legacy UEs). The first processing time may depend on a numerology of the initial UL/DL BWP. For example, a first PDSCH processing (decoding) time and/or a first PUSCH preparation time may be indicated for the first-type UEs of different capability(ies), e.g., different from a second PDSCH processing (decoding) time and/or a second PUSCH preparation time associated with second-type UEs (e.g., legacy UEs). In an example, the one or more parameters may indicate a first RAR/MsgB window size for the random access procedure of the first-type UEs that may be longer than/different from a second RAR/MsgB window size of second-type UEs (e.g., legacy UEs). Paragraph [0317]: For example, the DCI format may comprise one or more first information fields if the configuration parameters in the SIB indicate an enhancement/specific scheduling/parameter and/or a first value for a first parameter of the random access procedure; e.g., for Msg2/MsgB scheduling of first-type UEs. Paragraph [0318]: For example, the first condition may be that the RRC (e.g., SIB) message comprises a first parameter and/or indicates a first value for the first parameter. The first parameter may indicate a specific (e.g., specific to first-type UEs) Msg2/MsgB PDCCH repetition. The first parameter may indicate a specific entry (e.g., specific to first-type UEs) of a MCS/TB scaling table. The first parameter may indicate a specific (e.g., specific to first-type UEs) processing time (e.g., PDSCH processing time and/or PUSCH preparation time). The first parameter may indicate a specific (e.g., specific to first-type UEs) bandwidth and/or frequency domain scaling for a Msg2/MsgB PDSCH. Paragraph [0321]: As shown in FIG. 24 , the first-type UE may receive an RRC message comprising configuration parameters of RACH resources. The RACH resources may indicate one or more resources (e.g., preamble and/or RACH occasions) dedicated to first-type UEs. The configuration parameters may comprise a first parameter. The configuration parameters may comprise one or more first parameters. The first parameter(s) may indicate that one or more enhancement specific to the random access procedure of the first-type UEs is enabled/activated/configured. The first parameter(s) may indicate a special handling of one or more channels/signals/messages of the random access procedure for the first-type UEs. Paragraph [0334]: In response to the preamble transmission, the UE may monitor one or more PDCCH monitoring occasions of the search space (e.g., RA search space) for receiving one or more DCIs indicating a random access response (RAR) and/or MsgB. The UE may monitor the PDCCH monitoring occasions during a RAR/MsgB window. Paragraph [0347]: The configuration parameters may indicate a number of repetitions for the preamble transmission of the wireless devices of the first type. The configuration parameters may indicate a first duration, dedicated to the wireless devices of the first type, for the RAR window. The first duration for the RAR window of the wireless devices of the first type may be longer than a second duration of the RAR window of wireless devices of a second type other than the first type.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein a starting location of a random access response window is configured by system information, as taught by Rastegardoost in the system of Fei, so that the reduced capability UE can monitor for the random access response based on specific parameters configured via system information, which is different from the parameters configured for legacy UEs (Rastegardoost: Paragraphs [0286], [0287], [0307], [0310], [0318], [0321]).
Claims 22, 27, 30 are rejected under 35 U.S.C. 103 as being unpatentable over Fei et al. (US2024/0049205A1) in view of Hu et al. (US2024/0056797A1).
Regarding claim 22, Fei teaches the method of claim 1 further comprising: (see rejection for claim 1);
Fei does not explicitly teach receiving, by the UE, the RedCap-specific initial uplink BWP configuration information.
However, Hu teaches receiving, by the UE, the RedCap-specific initial uplink BWP configuration information (Abstract: In some embodiments, the reduced capability UE receives, from the network, a set of candidate uplink resources, and transmits a Message 3 message within a subset of the set of candidate uplink resources. Paragraph [0043]: The table of FIG. 3A shows the BWP configurations at different stages of the initial access process; both uplink and downlink BWPs are considered. The BWP configuration is split into uplink and downlink parameters as well as into common and dedicated parameters. Common parameters (in BWP-UplinkCommon and BWP-DownlinkCommon) may be “cell specific” and the network may ensure the necessary alignment with corresponding parameters of other UEs. The common parameters of the initial BWP of the PCell are also provided via system information. For all other serving cells, the network may provide the common parameters via dedicated signaling.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide receiving, by the UE, the RedCap-specific initial uplink BWP configuration information, as taught by Hu in the system of Fei, so that a reduced capability UE can be accommodated in a mobile communications network (Hu: Abstract, Paragraphs [0002], [0043]).
Regarding claim 27, Fei teaches the device of claim 9 further comprising: (see rejection for claim 9);
Fei does not explicitly teach receiving the RedCap-specific initial uplink BWP configuration information.
However, Hu teaches receiving the RedCap-specific initial uplink BWP configuration information (see rejection for claim 22);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide receiving the RedCap-specific initial uplink BWP configuration information, as taught by Hu in the system of Fei, so that a reduced capability UE can be accommodated in a mobile communications network (Hu: Abstract, Paragraphs [0002], [0043]).
Regarding claim 30, Fei teaches the method of claim 10, further comprising: (see rejection for claim 10);
Fei does not explicitly teach transmitting, by the BS, the RedCap-specific initial uplink BWP configuration information.
However, Hu teaches transmitting, by the BS, the RedCap-specific initial uplink BWP configuration information (see rejection for claim 22);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide transmitting, by the BS, the RedCap-specific initial uplink BWP configuration information, as taught by Hu in the system of Fei, so that a reduced capability UE can be accommodated in a mobile communications network (Hu: Abstract, Paragraphs [0002], [0043]).
Claims 23, 28, 31 are rejected under 35 U.S.C. 103 as being unpatentable over Fei et al. (US2024/0049205A1) in view of Choi et al. (US2023/0189308A1).
Regarding claim 23, Fei teaches the method of claim 1, the disabled FH (see rejection for claim 1);
Fei does not explicitly teach wherein the disabled FH is an intra-slot FH.
However, Choi teaches wherein the disabled FH is an intra-slot FH (Abstract: The present specification discloses reduced capability user equipment (UE) comprising: a communication module configured to receive configuration information for configuring a first downlink bandwidth part (DL BWP) and a first uplink bandwidth part (BWP) to be used for an initial access procedure. Paragraph [0381]: For PUSCH repetitive transmission type A, one of intra-slot frequency hopping of performing frequency hopping within a slot ….may be configured for the UE. Paragraph [0394]: If intra-slot frequency hopping is configured for the UE, the UE divides the PUCCH in half in the time domain in a slot for PUCCH transmission, so as to transmit a half of the PUCCH in a first PRB and transmit the other half in a second PRB. In this case, the first PRB and the second PRB may be configured for the UE via a higher layer for configuring of PUCCH resources.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the disabled FH is an intra-slot FH, so that diversity gain may be obtained in the frequency domain, and PUCCH resources may be configured for the UE via a higher layer (Choi: Abstract, Paragraphs [0381], [0394]).
Regarding claim 28, Fei teaches the device of claim 9, the disabled FH (see rejection for claim 9);
Fei does not explicitly teach wherein the disabled FH is an intra-slot FH.
However, Choi teaches wherein the disabled FH is an intra-slot FH (see rejection for claim 23);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the disabled FH is an intra-slot FH, so that diversity gain may be obtained in the frequency domain, and PUCCH resources may be configured for the UE via a higher layer (Choi: Abstract, Paragraphs [0381], [0394]).
Regarding claim 30, Fei teaches the method of claim 10, the disabled FH (see rejection for claim 10);
Fei does not explicitly teach wherein the disabled FH is an intra-slot FH.
However, Choi teaches wherein the disabled FH is an intra-slot FH (see rejection for claim 23);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the disabled FH is an intra-slot FH, so that diversity gain may be obtained in the frequency domain, and PUCCH resources may be configured for the UE via a higher layer (Choi: Abstract, Paragraphs [0381], [0394]).
Response to Arguments
Applicant's arguments filed December 19, 2025 with respect to claims 1,6, 8-10, 15,17 being rejected under 35 U.S.C. 102(a)(2) as being anticipated by Fei et al. (US2024/0049205A1); claims 5, 14 being rejected under 35 U.S.C. 103 as being unpatentable over Fei in view of MolavianJazi et al. (US2021/0076384A1); claims 7, 16 being rejected under 35 U.S.C. 103 as being unpatentable over Fei in view of Rastegardoost (US2024/0031056A1), have been fully considered.
Applicant submits that the cited references fail to disclose or suggest the features of amended independent claim 1 which recites in part “"wherein the additional RB offset is a cell-specific offset parameter included in a reduced capability (RedCap)- specific initial uplink bandwidth part (BWP) configuration information, and wherein the RedCap- specific BWP configuration information is configured based on that a size of an initial uplink BWP is larger than a maximum size supported by the UE.” However, Fei teaches that when frequency hopping is disabled the RedCap UE may determine its first resource for the PUCCH transmission based on an RB offset at a frequency location corresponding to the first/second hop when the non-RedCap or legacy UE transmits the PUCCH. The first resource for the RedCap UE to transmit the PUCCH can be determined based on the frequency location corresponding to the first hop and/or the frequency location corresponding to the second hop when the second type of terminal transmits the PUCCH. Paragraphs [0238] - [0240] describe the RBBWP offset used to determine the first RB offset for common PUCCH resource sets used by the legacy UEs. However, to avoid interlacing the resources used by the two types of UEs, an additional offset RBRedcap offset is introduced for determining the frequency location for the PUCCH transmitted by the RedCap UE. Thus, in addition to the RBBWP offset, an offset RBRedcap offset is introduced for determining the frequency location for the PUCCH transmitted by the RedCap UE. Fei teaches in paragraph [0244] the equation indicating a first RB offset RBBWP offset, and an additional RB offset RBRedcap offset that is introduced for determining the frequency location for the PUCCH transmitted by the RedCap UE. Fei teaches that user-specific RRC configuration may configure suitable PUCCH transmission resources for the RedCap UE. Fei also teaches that the frequency offset may be predefined or transmitted such as in SIB1. As per paragraph [0544] of the specification it is mentioned that the offset is included in the SIB1 and transmitted.
Fei also teaches that the RedCap-specific BWP configuration information is configured based on that a size of an initial uplink BWP is larger than a maximum size supported by the UE. Fei teaches that for the predefined mode, it may be predefined directly through a protocol that the RedCap UE does not perform the PUCCH transmission with frequency hopping before obtaining user-specific RRC configuration; or that in case that the bandwidth of UL BWP (such as UL initial BWP) of the RedCap UE is larger than a threshold value (such as the maximum bandwidth supported by the RedCap UE), the PUCCH transmission with frequency hopping is not performed. Fei teaches that the RedCap-specific BWP configuration information is configured based on that a size of an initial uplink BWP is larger than a maximum size supported by the UE. Thus, Fei teaches amended independent claim 1, and amended independent claims 9 and 10 which recite similar features.
Dependent claims 6, 21, 24- 26, 29 are also taught by Fei. Dependent claims 5, 14 are taught by the combination of Fei and MolavianJazi. Dependent claim 7 is taught by the combination of Fei and Rastegardoost. Dependent claims 22, 27, 30 are taught by the combination of Fei and Hu et al. (US2024/0056797A1). Dependent claims 23, 28, 31 are taught by the combination of Fei and Choi et al. (US2023/0189308A1).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LATHA CHAKRAVARTHY whose telephone number is (703)756-1172. The examiner can normally be reached M-Th 8:30 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, Huy Vu can be reached at 571-272-3155. 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.
/L.C./Examiner, Art Unit 2461
/HUY D VU/Supervisory Patent Examiner, Art Unit 2461