DETAILED ACTION
Claims 1-15 and 47-49 are presented for examination.
Claims 16-46 are cancelled.
Claims 1, 11 and 15 are amended.
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 .
Response to Arguments
Applicant’s arguments, see Remarks pages 8-9, filed April 27, 2026, with respect to the rejection(s) of claim(s) 5 under 35 USC § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Hou (US 20230254868 A1) and Fei (US 20240049205 A1).
Applicant's arguments regarding claims 1 and 15 have been fully considered but they are not persuasive. Reasons set forth below.
Regarding claims 1 and 15, Applicant argues Liu (US 20240187037 A1) does not teach “wherein receiving the configuration information (including information indicating whether frequency hopping, associated with transmission of control information via PUCCH, is enabled or disabled) comprises receiving the configuration information via downlink control information (DCI) scheduling Msg4 or MsgB” (Remarks, pages 7-8). Examiner respectfully disagrees.
Liu teaches receiving the configuration information comprises receiving the configuration information via downlink control information (DCI) scheduling Msg4 or MsgB ([0242] In S904, if the base station 160 successfully decoded the transport block (this is referring to the PUSCH the UE sends as part of the random access procedure (i.e. Msg3), the base station 160 may generate and transmit a DCI format 1_0 with CRC scrambled by the TC-RNTI scheduling a PDSCH that includes a UE contention resolution identity (This is the DCI that schedules the PDSCH for contention resolution, i.e. Msg4). See Fig.9). Liu also teaches the DCI includes information indicating whether frequency hopping, associated with transmission of control information via PUCCH, is enabled or disabled ([0311] A DCI format which schedules the corresponding PDSCH may include a frequency hopping flag field. The frequency hopping flag field can be included in the frequency domain resource allocation field and can be used to indicate whether the determined frequency hopping is enabled or disabled for the PUCCH transmission.) Since Liu teaches a DCI that includes information on whether frequency hopping for a PUCCH is enabled/disabled and Liu teaches the DCI schedules a PDSCH for contention resolution of a random access procedure, then it follows that Liu teaches “the configuration information including information indicating whether frequency hopping, associated with transmission of control information via a physical uplink control channel (PUCCH), is enabled or disabled, wherein receiving the configuration information comprises receiving the configuration information via downlink control information (DCI) scheduling Msg4 or MsgB” as amended claims 1 and 15.
Regarding the dependent claims 2-4, 6-10, 12-14 and 47-49, Applicant has not made specific arguments pertaining to why the cited references do not teach the recited claims, other than their dependency to claim 1 or 11. Therefor for at least the reasons presented above for claim 1, the dependent claims are rejected.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 3, 4, 15, 48 and 49 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Liu (US 20240187037 A1).
Regarding claim 1, Liu teaches a method performed by a wireless device (Fig. 9, UE), the method comprising:
receiving configuration information to be utilized to communicate with a base station ([0217] Before initiating a random access procedure, the UE 102 may receive, from the base station 160, the information for the random access procedure. The information (i.e. the random access information) includes the cell-specific random access parameters and/or the dedicated random access parameters. The random access information may be indicated by the broadcasted system information (e.g., MIB, SIB1, and/or other SIBs) and/or RRC message and so on. Fig. 9, [0242] In S904, if the base station 160 successfully decoded the transport block, the base station 160 may generate and transmit a DCI format 1_0 with CRC scrambled by the TC-RNTI scheduling a PDSCH that includes a UE contention resolution identity (i.e. a UE contention resolution identity MAC CE)) the configuration information including information indicating whether frequency hopping, associated with transmission of control information via a physical uplink control channel (PUCCH), is enabled or disabled ([0311] A DCI format which schedules the corresponding PDSCH may include a frequency hopping flag field. The frequency hopping flag field can be included in the frequency domain resource allocation field and can be used to indicate whether the determined frequency hopping is enabled or disabled for the PUCCH transmission.),
wherein receiving the configuration information comprises receiving the configuration information via downlink control information (DCI) scheduling Msg4 or MsgB (Fig. 9, [0242] In S904, if the base station 160 successfully decoded the transport block, the base station 160 may generate and transmit a DCI format 1_0 with CRC scrambled by the TC-RNTI scheduling a PDSCH that includes a UE contention resolution identity (message 4). [0311] A DCI format which schedules the corresponding PDSCH may include a frequency hopping flag field. The frequency hopping flag field can be included in the frequency domain resource allocation field and can be used to indicate whether the determined frequency hopping is enabled or disabled for the PUCCH transmission. In a case that the value of the frequency hopping flag field is set to 0, the UE 102 may transmit the PUCCH without frequency hopping. In this case, the frequency hopping is disabled for the PUCCH transmission. In a case that the value of the frequency hopping flag field is set to 1, the UE 102 may transmit the PUCCH with frequency hopping. In this case, the frequency hopping is enabled for the PUCCH transmission.); and
transmitting control information via the PUCCH based on whether the frequency hopping is enabled or disabled ([0244] In response to the PDSCH reception with the UE contention resolution identity, the UE 102 may transmit HARQ-ACK information in a PUCCH using frequency hopping to the base station 160. [0311] In a case that the value of the frequency hopping flag field is set to 0, the UE 102 may transmit the PUCCH without frequency hopping. In this case, the frequency hopping is disabled for the PUCCH transmission. In a case that the value of the frequency hopping flag field is set to 1, the UE 102 may transmit the PUCCH with frequency hopping. In this case, the frequency hopping is enabled for the PUCCH transmission.).
Regarding claim 3, Liu teaches the method of claim 1, wherein receiving the configuration information, including the information indicating whether frequency hopping is enabled or disabled, includes receiving the configuration information dynamically ([0311] A DCI format which schedules the corresponding PDSCH may include a frequency hopping flag field. The frequency hopping flag field can be included in the frequency domain resource allocation field and can be used to indicate whether the determined frequency hopping is enabled or disabled for the PUCCH transmission.)
Regarding claim 4, Liu teaches the method of claim 1, further comprising: transmitting the control information via the PUCCH by utilizing the frequency hopping when the frequency hopping is enabled ([0311] In a case that the value of the frequency hopping flag field is set to 1, the UE 102 may transmit the PUCCH with frequency hopping. In this case, the frequency hopping is enabled for the PUCCH transmission.); and transmitting the control information via the PUCCH without utilizing the frequency hopping when the frequency hopping is disabled ([0311] In a case that the value of the frequency hopping flag field is set to 0, the UE 102 may transmit the PUCCH without frequency hopping. In this case, the frequency hopping is disabled for the PUCCH transmission.).
Regarding claim 15, Liu teaches a wireless device comprising: processing circuitry (Fig. 16, Processor 1679) configured to perform operations comprising:
receiving configuration information to be utilized to communicate with a base station ([0217] Before initiating a random access procedure, the UE 102 may receive, from the base station 160, the information for the random access procedure. The information (i.e. the random access information) includes the cell-specific random access parameters and/or the dedicated random access parameters. The random access information may be indicated by the broadcasted system information (e.g., MIB, SIB1, and/or other SIBs) and/or RRC message and so on.Fig. 9, [0242] In S904, if the base station 160 successfully decoded the transport block, the base station 160 may generate and transmit a DCI format 1_0 with CRC scrambled by the TC-RNTI scheduling a PDSCH that includes a UE contention resolution identity (i.e. a UE contention resolution identity MAC CE)), the configuration information including information indicating whether frequency hopping, associated with transmission of control information via a physical uplink control channel (PUCCH), is enabled or disabled ([0311] A DCI format which schedules the corresponding PDSCH may include a frequency hopping flag field. The frequency hopping flag field can be included in the frequency domain resource allocation field and can be used to indicate whether the determined frequency hopping is enabled or disabled for the PUCCH transmission.);
wherein receiving the configuration information comprises receiving the configuration information dynamically via downlink control information (DCI) scheduling Msg4 or MsgB (Fig. 9, [0242] In S904, if the base station 160 successfully decoded the transport block, the base station 160 may generate and transmit a DCI format 1_0 with CRC scrambled by the TC-RNTI scheduling a PDSCH that includes a UE contention resolution identity (message 4). [0311] A DCI format which schedules the corresponding PDSCH may include a frequency hopping flag field. The frequency hopping flag field can be included in the frequency domain resource allocation field and can be used to indicate whether the determined frequency hopping is enabled or disabled for the PUCCH transmission. In a case that the value of the frequency hopping flag field is set to 0, the UE 102 may transmit the PUCCH without frequency hopping. In this case, the frequency hopping is disabled for the PUCCH transmission. In a case that the value of the frequency hopping flag field is set to 1, the UE 102 may transmit the PUCCH with frequency hopping. In this case, the frequency hopping is enabled for the PUCCH transmission.); and
transmitting control information via the PUCCH based on whether the frequency hopping is enabled or disabled ([0244] In response to the PDSCH reception with the UE contention resolution identity, the UE 102 may transmit HARQ-ACK information in a PUCCH using frequency hopping to the base station 160. [0311] In a case that the value of the frequency hopping flag field is set to 0, the UE 102 may transmit the PUCCH without frequency hopping. In this case, the frequency hopping is disabled for the PUCCH transmission. In a case that the value of the frequency hopping flag field is set to 1, the UE 102 may transmit the PUCCH with frequency hopping. In this case, the frequency hopping is enabled for the PUCCH transmission.).
Regarding claim 48 Liu teaches the wireless device of claim 15, wherein receiving the configuration information, including the information indicating whether frequency hopping is enabled or disabled, includes receiving the configuration information dynamically ([0311] A DCI format which schedules the corresponding PDSCH may include a frequency hopping flag field. The frequency hopping flag field can be included in the frequency domain resource allocation field and can be used to indicate whether the determined frequency hopping is enabled or disabled for the PUCCH transmission.)
Regarding claim 49, Liu teaches the wireless device of claim 15, further comprising: transmitting the control information via the PUCCH by utilizing the frequency hopping when the frequency hopping is enabled ([0311] In a case that the value of the frequency hopping flag field is set to 1, the UE 102 may transmit the PUCCH with frequency hopping. In this case, the frequency hopping is enabled for the PUCCH transmission.); and transmitting the control information via the PUCCH without utilizing the frequency hopping when the frequency hopping is disabled ([0311] In a case that the value of the frequency hopping flag field is set to 0, the UE 102 may transmit the PUCCH without frequency hopping. In this case, the frequency hopping is disabled for the PUCCH transmission.).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 2, and 47 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of KHOSHNEVISAN (US 20220094389 A1).
Regarding claim 2, Liu teaches the method of claim 1 but does not explicitly teach wherein an information element included in a system information block of the configuration information indicates whether frequency hopping is enabled or disabled.
Khoshnevisan in the same field of endeavor of frequency hopping for PUCCH transmissions teaches wherein an information element included in a system information block of the configuration information indicates whether frequency hopping is enabled or disabled (Fig. 4, [0062] A UE 402 may receive from a base station 404, a PUCCH resource IE 406 for a PUCCH resource indicating a PUCCH resource intra-slot frequency hopping configuration. [0064] The PUCCH resource IE 406 (including the startingPRB, secondHopPRB, and intraSlotFrequencyHopping fields) is configured semi-statically through RRC signaling. [0050] The controller/processor 375 (of the base station in Fig. 3) provides RRC layer functionality associated with broadcasting of system information (e.g., MIB, SIBs). (Thus the information element is included in a system information block). [0064] the UE 402 may determine the mode to be mode 0 (no frequency hopping) if intraSlotFrequencyHopping is disabled and to be mode 1 (frequency hopping) if intraSlotFrequencyHopping is enabled.).
It would have been obvious for one of ordinary skill in the art to modify the random access procedure of Liu to include the PUCCH resource IE configured through SIB of Khoshnevisan. The motivation to do so would have been to determine a mode in association with frequency hopping for PUCCH transmissions (Khoshnevisan; [0006]).
Regarding claim 47, Liu teaches the wireless device of claim 15 but does not explicitly teach wherein an information element included in a system information block of the configuration information indicates whether frequency hopping is enabled or disabled.
Khoshnevisan in the same field of endeavor of frequency hopping for PUCCH transmissions teaches wherein an information element included in a system information block of the configuration information indicates whether frequency hopping is enabled or disabled (Fig. 4, [0062] A UE 402 may receive from a base station 404, a PUCCH resource IE 406 for a PUCCH resource indicating a PUCCH resource intra-slot frequency hopping configuration. [0064] The PUCCH resource IE 406 (including the startingPRB, secondHopPRB, and intraSlotFrequencyHopping fields) is configured semi-statically through RRC signaling. [0050] The controller/processor 375 (of the base station in Fig. 3) provides RRC layer functionality associated with broadcasting of system information (e.g., MIB, SIBs). (Thus the information element is included in a system information block). [0064] the UE 402 may determine the mode to be mode 0 (no frequency hopping) if intraSlotFrequencyHopping is disabled and to be mode 1 (frequency hopping) if intraSlotFrequencyHopping is enabled.).
It would have been obvious for one of ordinary skill in the art to modify the random access procedure of Liu to include the PUCCH resource IE configured through SIB of Khoshnevisan. The motivation to do so would have been to determine a mode in association with frequency hopping for PUCCH transmissions (Khoshnevisan; [0006]).
Claim Rejections - 35 USC § 103
Claim(s) 5 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Hou (US 20230254868 A1) in view of Fei (US 20240049205 A1).
Regarding claim 5, Hou teaches a method performed by a wireless device, the method comprising:
receiving configuration information to be utilized to communicate with a base station ([0202] S1302: The network device sends a configuration instruction to a terminal device, where the configuration instruction indicates the P uplink bandwidth parts.), the configuration information including information indicating a first size or a first location associated with a first initial bandwidth part (BWP) configured for the wireless device and a second size or a second location associated with a second initial BWP configured for another wireless device ([0158] In a first scenario, as shown in FIG. 7, the network device may configure a first initial uplink BWP (first size associated with a first initial BWP) for the first-type terminal device, and configure a second initial uplink BWP for the second-type terminal device (second size associated with a second initial BWP). The first initial uplink BWP may be located in a frequency domain range of the second initial uplink BWP or may not be located in the frequency domain range of the second initial uplink BWP.)
Hou does not teach transmitting, by selectively utilizing frequency hopping, control information via a physical uplink control channel (PUCCH) based on the first size of the first initial BWP and the second size of the second initial BWP or based on the first location of the first initial BWP and the second location of the second initial BWP.
Fei in the same field of endeavor of channel transmission in communication technologies teaches transmitting, by selectively utilizing frequency hopping, control information via a physical uplink control channel (PUCCH) based on the first size of the first initial BWP and the second size of the second initial BWP or based on the first location of the first initial BWP and the second location of the second initial BWP ([0391] 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 until obtaining user-specific RRC configuration; or that in case that the bandwidth of UL BWP (such as UL initial BWP) of the RedCap UE (second size associated with a second initial BWP) is larger than a threshold value (such as the maximum bandwidth supported by the RedCap UE) (first size associated with a first initial BWP), the PUCCH transmission with frequency hopping is not performed, otherwise, the PUCCH transmission with frequency hopping is performed. No any indication from the network side device is required in the predefined mode and the indication overhead can be saved.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the communication methods of Hou to include the predefined mode of Fei where the frequency hopping is not performed if the initial UP BWP is greater than the bandwidth supported by the RedCap device. The motivation to do so would have been so that the bandwidth in which the RedCap UE transmits the PUCCH is within the bandwidth range supported by the RedCap UE. This solves the problem where the UE fails to transmit the PUCCH correctly in the UL initial BWP if a frequency interval between two hops for the PUCCH transmission is larger than the maximum bandwidth supported by the RedCap UE. (Fei; [0200]).
Regarding claim 6, Hou in view of Fei teach the method of claim 5 and Fei teaches wherein the wireless device transmits the control information via the PUCCH by utilizing the frequency hopping when the first size and the second size are substantially the same ([0391] 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 until obtaining user-specific RRC configuration; or that in case that the bandwidth of UL BWP (such as UL initial BWP) of the RedCap UE (second size associated with a second initial BWP) is larger than a threshold value (such as the maximum bandwidth supported by the RedCap UE) (first size associated with a first initial BWP), the PUCCH transmission with frequency hopping is not performed, otherwise, the PUCCH transmission with frequency hopping is performed. In other words, frequency hopping is performed when the second size is less than or equal to the first size.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the communication methods of Hou to include the predefined mode of Fei where the frequency hopping is not performed if the initial UP BWP is greater than the bandwidth supported by the RedCap device. The motivation to do so would have been so that the bandwidth in which the RedCap UE transmits the PUCCH is within the bandwidth range supported by the RedCap UE. This solves the problem where the UE fails to transmit the PUCCH correctly in the UL initial BWP if a frequency interval between two hops for the PUCCH transmission is larger than the maximum bandwidth supported by the RedCap UE. (Fei; [0200]).
Claim Rejections - 35 USC § 103
Claim(s) 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Hou (US 20230254868 A1) in view of Fei (US 20240049205 A1); further in view of Kim (US 20230292322 A1).
Regarding claim 7, Hou in view of Fei teach the method of claim 5 but do not teach wherein the wireless device transmits the control information via the PUCCH without utilizing the frequency hopping when the first size and the second size are different.
Kim, in the same field of endeavor of transmitting and receiving PUCCH transmissions, teaches wherein the wireless device transmits the control information via the PUCCH without utilizing the frequency hopping when the first size and the second size are different ([0458] In the following methods, for the above reason, if a separate initial UL BWP for the RedCap UE is configured and managed, the RedCap UE bandwidth may include a meaning of a separate initial UL BWP or a bandwidth of a separate initial UL BWP for the RedCap UE. And/or, the bandwidth of the separate initial UL BWP for the RedCap UE may be limited to the RedCap UE bandwidth or less. For the above reason, in the present disclosure, the meaning of “the bandwidth of the initial UL BWP or the initial UL bandwidth is greater than the RedCap UE bandwidth” or “the base station shall set the initial UL bandwidth for the normal UE to be greater than the RedCap UE bandwidth” may include the meaning of “a separate initial UL BWP for RedCap is/has been set”. [0514] As specified in the predefined standard, PUCCH transmission before dedicated PUCCH resource configuration is configured to always perform FH based on an initial UL bandwidth. If the initial UL bandwidth (second size) is greater than a RedCap UE bandwidth (first size), a FH problem may be applied in the same manner as the contents described in the Msg3 PUSCH. That is, at least one of the methods 2-1 to 2-4 of the second embodiment may be applied to a PUCCH transmission. [0515] For example, a suggested method for the PUCCH in the above case may be applied for the above methods proposed in the Msg3 PUSCH by replacing Msg3 PUSCH with PUCCH and interpreting it. That is, unlike the related art normal UE, if a bandwidth of initial UL BWP (second size) is greater than the RedCap UE bandwidth (first size), PUCCH FH disable may be supported for the RedCap UE. [0460] (Method 2-1) [0461] This method is a method of performing FH off when an initial UL bandwidth is greater than a RedCap UE bandwidth. [0462] When a base station needs to set the initial UL bandwidth for the normal UE (second size) to be greater than the RedCap UE bandwidth (first size), the base station may perform Msg3 PUSCH FH off (without utilizing the frequency hopping). [0476] Referring to FIG. 15, when a bandwidth of an initial UL BWP is greater than the RedCap UE bandwidth in the Case 2, Msg3 PUSCH (or a 1st hop 1510 and a 2nd hop 1520) may be transmitted without FH in a frequency domain of the 2nd hop 1520 falling within the RedCap UE bandwidth.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hou and Fei to include the Method 2-1 of Kim. The motivation to do so would have been to provide a method of transmitting and receiving a PUCCH (or HARQ-ACK information) for Msg4 without a frequency hopping when an initial UL BWP is greater than a bandwidth of a RedCap UE, and a device therefor. (Kim; [0008]).
Regarding claim 8, Hou in view of Fei teach the method of claim 5, and Hou teaches ([0158] The first initial uplink BWP (first size) may be located in (within) a frequency domain range of the second initial uplink BWP (second size)).
Hou does not teach wherein the wireless device transmits the control information via the PUCCH without utilizing the frequency hopping when the first initial BWP is located within the second initial BWP.
Kim, in the same field of endeavor of transmitting and receiving PUCCH transmissions, teaches wherein the wireless device transmits the control information via the PUCCH without utilizing the frequency hopping when the first initial BWP is located within the second initial BWP ([0514] a FH problem may be applied in the same manner as the contents described in the Msg3 PUSCH. That is, at least one of the methods 2-1 to 2-4 of the second embodiment may be applied to a PUCCH transmission. [0515] For example, a suggested method for the PUCCH in the above case may be applied for the above methods proposed in the Msg3 PUSCH by replacing Msg3 PUSCH with PUCCH and interpreting it. [0462] When a base station needs to set the initial UL bandwidth for the normal UE (second size) to be greater than the RedCap UE bandwidth (first size), the base station may perform Msg3 PUSCH FH off (without utilizing the frequency hopping). [0476] Referring to FIG. 15, when a bandwidth of an initial UL BWP is greater than the RedCap UE bandwidth in the Case 2, Msg3 PUSCH (or a 1st hop 1510 and a 2nd hop 1520) may be transmitted without FH in a frequency domain of the 2nd hop 1520 falling within the RedCap UE bandwidth. Fig. 15 shows the RedCap UE bandwidth (fist size) is within the Initial UL BWP (second size)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hou and Fei to include the Method 2-1 of Kim. The motivation to do so would have been to provide a method of transmitting and receiving a PUCCH (or HARQ-ACK information) for Msg4 without a frequency hopping when an initial UL BWP is greater than a bandwidth of a RedCap UE, and a device therefor. (Kim; [0008]).
Claim Rejections - 35 USC § 103
Claim(s) 9 is rejected under 35 U.S.C. 102 as being unpatentable over Hou (US 20230254868 A1) in view of Fei (US 20240049205 A1); further in view of Liu (US 20200084768 A1); hereinafter Liu2.
Regarding claim 9 Hou in view of Fei teach the method of claim 5, but do not teach wherein whether the frequency hopping is enabled or disabled is based on a presence of another wireless device in a cell associated with the base station.
Liu2, in the same field of endeavor of techniques for flexible resource allocation teaches wherein whether the frequency hopping is enabled or disabled is based on a presence of another wireless device in a cell associated with the base station ([0207] In another example, applying the frequency hopping offset can include determining whether to consider compatibility with legacy UEs (a presence of another wireless device in a cell), which can be enabled by higher layer signaling (e.g., RRC signaling from a base station). In this example, where WB hopping component 52 determines to consider compatibility with legacy UEs, WB hopping component 52 can apply hopping according to one of the schemes above. Where WB hopping component 52 determines to not consider compatibility with legacy UEs, WB hopping component 52 can apply hopping as ƒ.sub.NB,hop.sup.PUSCH=6(ƒ.sub.NB,hop.sup.PUSCH mod N.sub.NB).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hou and Fei to include the teachings of Liu2 to consider the presence of legacy UEs when considering whether to enable/disable frequency hopping. The motivation to do so would have been to avoid or significantly reduce system performance degradations, for example, decreased downlink cell throughput or fragmentation of the spectrum for uplink transmissions. (Liu2; [0036] [0037]).
Claim Rejections - 35 USC § 103
Claim(s) 12 is rejected under 35 U.S.C. 103 as being unpatentable over Hou (US 20230254868 A1) in view of Fei (US 20240049205 A1); further in view of Liu (US 20200084768 A1); hereinafter Liu2; further in view of Khosnevisan (US 20220094389 A1).
Regarding claim 12, Hou in view of Fei and Liu2 teaches the method of claim 9 but does not teach wherein an information element included in a system information block of the configuration information indicates whether the frequency hopping is enabled or disabled.
KHOSHNEVISAN in the same field of endeavor of frequency hopping for PUCCH transmissions teaches wherein an information element included in a system information block of the configuration information indicates whether the frequency hopping is enabled or disabled (Fig. 4, [0062] A UE 402 may receive from a base station 404, a PUCCH resource IE 406 for a PUCCH resource indicating a PUCCH resource intra-slot frequency hopping configuration. [0064] The PUCCH resource IE 406 (including the startingPRB, secondHopPRB, and intraSlotFrequencyHopping fields) is configured semi-statically through RRC signaling. [0050] The controller/processor 375 (of the base station in Fig. 3) provides RRC layer functionality associated with broadcasting of system information (e.g., MIB, SIBs). (Thus, the information element is included in a system information block). [0064] the UE 402 may determine the mode to be mode 0 (no frequency hopping) if intraSlotFrequencyHopping is disabled and to be mode 1 (frequency hopping) if intraSlotFrequencyHopping is enabled.).
It would have been obvious for one of ordinary skill in the art to modify the teachings of Hou in view of Fei and Liu2 to include the PUCCH resource IE configured through SIB of Khoshnevisan. The motivation to do so would have been to determine a mode in association with frequency hopping for PUCCH transmissions (Khoshnevisan; [0006]).
Claim Rejections - 35 USC § 103
Claim(s) 13 is rejected under 35 U.S.C. 102 as being unpatentable over Hou (US 20230254868 A1) in view of Fei (US 20240049205 A1); further in view of Liu (US 20200084768 A1); hereinafter Liu2; further in view of Liu (US 20240187037 A1).
Regarding claim 13 Hou in view of Fei and Liu2 teaches the method of claim 9, but they do not teach wherein transmitting the configuration information, including the information indicating whether the frequency hopping is enabled or disabled, includes transmitting the configuration information dynamically.
Liu in the same field of endeavor of wireless communications teaches wherein transmitting the configuration information, including the information indicating whether the frequency hopping is enabled or disabled, includes transmitting the configuration information dynamically ([0311] A DCI format which schedules the corresponding PDSCH may include a frequency hopping flag field. The frequency hopping flag field can be included in the frequency domain resource allocation field and can be used to indicate whether the determined frequency hopping is enabled or disabled for the PUCCH transmission.)
It would have been obvious for one of ordinary skill in the art to modify the teachings of Hou in view of Fei and Liu2 to include the DCI that includes a frequency hopping flag of Liu. The motivation to do so would have been to indicate whether the determined frequency hopping is enabled or disabled for the PUCCH transmission (Liu; [0311]).
Claim Rejections - 35 USC § 103
Claim(s) 11 is rejected under 35 U.S.C. 103 as being unpatentable over Liu (US 20240187037 A1) in view of Rastegardoost (US 20240031056 A1); further in view of Hou (US 20230254868 A1)
Regarding claim 11, Liu teaches a method performed by a base station (Fig. 9, base station), the method comprising:
transmitting configuration information to be utilized by a wireless device to communicate with the base station ([0217] Before initiating a random access procedure, the UE 102 may receive, from the base station 160, the information for the random access procedure. The information (i.e. the random access information) includes the cell-specific random access parameters and/or the dedicated random access parameters. The random access information may be indicated by the broadcasted system information (e.g., MIB, SIB1, and/or other SIBs) and/or RRC message and so on. Fig. 9, [0242] In S904, if the base station 160 successfully decoded the transport block, the base station 160 may generate and transmit a DCI format 1_0 with CRC scrambled by the TC-RNTI scheduling a PDSCH that includes a UE contention resolution identity (i.e. a UE contention resolution identity MAC CE)), the configuration information including information indicating whether frequency hopping, associated with transmission of control information via a physical uplink control channel (PUCCH), is enabled or disabled ([0311] A DCI format which schedules the corresponding PDSCH may include a frequency hopping flag field. The frequency hopping flag field can be included in the frequency domain resource allocation field and can be used to indicate whether the determined frequency hopping is enabled or disabled for the PUCCH transmission.)
receiving control information via the PUCCH based on whether the frequency hopping is enabled or disabled ([0244] In response to the PDSCH reception with the UE contention resolution identity, the UE 102 may transmit HARQ-ACK information in a PUCCH using frequency hopping to the base station 160. [0311] In a case that the value of the frequency hopping flag field is set to 0, the UE 102 may transmit the PUCCH without frequency hopping. In this case, the frequency hopping is disabled for the PUCCH transmission. In a case that the value of the frequency hopping flag field is set to 1, the UE 102 may transmit the PUCCH with frequency hopping. In this case, the frequency hopping is enabled for the PUCCH transmission.).
Liu does not teach determining whether a RedCap wireless device is being served by the base station; and the frequency hopping accounting for a bandwidth associated with the RedCap wireless device.
Rastegardoost in the same field of endeavor of initial access for reduced capability devices teaches determining whether a RedCap wireless device is being served by the base station ([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. A second type wireless device (e.g., a non-RedCap UE) may use a second time/frequency/code resource for a second preamble. The second time/frequency/code resource may be determined based on a second PRACH configuration and/or a second UL BWP. [0263] Early identification of RedCap UE type(s) during transmission of Msg1 may be necessary for: coverage recovery (including link adaptation) for one or more of: Msg2 PDCCH/PDSCH, Msg3 PUSCH and PDCCH scheduling Msg3 reTx, Msg4 PDCCH/PDSCH or PUCCH in response to Msg4. identifying UE max bandwidth capability for Msg3 and Msg5 scheduling and PUCCH in response to Msg4.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu to include the separate initial access procedures for RedCap UEs of Rastegardoost. The motivation to do so would have been to allow for early identification of RedCap UEs to enable efficient handling of different UE minimum processing times between RedCap and non-RedCap UEs, and for coverage recovery (including link adaptation) for one or more initial access messages (Rastegardoost [0263] [0264]).
Rastegardoost does not teach the frequency hopping accounting for a bandwidth associated with the RedCap wireless device.
Hou in the same field of endeavor of PUCCH transmissions for reduced capability devices teaches the frequency hopping accounting for a bandwidth associated with the RedCap wireless device ([0158] In a first scenario, as shown in FIG. 7, the network device may configure a first initial uplink BWP for the first-type terminal device, and configure a second initial uplink BWP for the second-type terminal device. The first initial uplink BWP may be located in a frequency domain range of the second initial uplink BWP, or may not be located in the frequency domain range of the second initial uplink BWP. This is not limited in this application. [0159] The first PUCCH resource set is located in a frequency domain range of the first initial uplink BWP. Correspondingly, the second PUCCH resource set is located in the frequency domain range of the second initial uplink BWP. [0160] In this scenario, a bandwidth of the first initial uplink BWP may be less than or equal to the maximum bandwidth supported by the first-type terminal device. According to this method, when a terminal device transmits a PUCCH in the first PUCCH resource set, a frequency domain range of two adjacent frequency hopping transmissions can be less than or equal to a maximum bandwidth supported by the terminal device, to avoid a performance loss of PUCCH transmission.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Liu in view of Rastegardoost to include implementation 2 of Hou where the First PUCCH Resource Set is different from the Second PUCCH Resource Set. The motivation to do so would have been to avoid a performance loss of PUCCH transmission for Redcap devices. (Hou; [0160]).
Claim Rejections - 35 USC § 103
Claim(s) 10 is rejected under 35 U.S.C. 103 as being unpatentable over Hou (US 20230254868 A1) in view of Fei (US 20240049205 A1); further in view of Koorapaty (US 20190132861 A1).
Regarding claim 10, Hou in view of Fei teach the method of claim 5 but do not teach further comprising: providing user data; and forwarding the user data to a host computer via a transmission to the base station.
Koorapaty in the same field of endeavor of PUCCH resource allocation teaches providing user data; and forwarding the user data to a host computer via a transmission to the base station ([0204] The method of any of the previous embodiments, further comprising: providing user data; and forwarding the user data to a host computer via the transmission to the base station.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the host computer and OTT connection 550 of Koorapaty with the UE and base station of Hou and Fei. The motivation to do so would have been to include a measurement procedure for the purpose of monitoring data rate, latency and other factors that would include the performance of transmission between the UE and the base station of Hou in view of Fei. (Koorapaty; [0165]).
Claim Rejections - 35 USC § 103
Claim(s) 14 is rejected under 35 U.S.C. 103 as being unpatentable over Liu (US 20240187037 A1) in view of Rastegardoost (US 20240031056 A1) and Hou (US 20230254868 A1); further in view of Koorapaty (US 20190132861 A1).
Regarding claim 14, Liu, Rastegardoost and Hou teach the method of claim 11 but do not teach further comprising: obtaining user data; and forwarding the user data to a host computer or a wireless device.
Koorapaty in the same field of endeavor of PUCCH resource allocation teaches obtaining user data; and forwarding the user data to a host computer or a wireless device ([0218] The method of any of the previous embodiments, further comprising: obtaining user data; and forwarding the user data to a host computer or a wireless device).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the host computer and OTT connection 550 of Koorapaty with the UE and base station of Liu, Rastegardoost and Hou. The motivation to do so would have been to include a measurement procedure for the purpose of monitoring data rate, latency and other factors that would include the performance of transmission between the UE and the base station of Liu, Rastegardoost and Hou. (Koorapaty; [0165]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NANCY SIXTO whose telephone number is (571)272-3295. The examiner can normally be reached Mon - Friday 9AM-5PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Gary Mui can be reached at 571-270-1420. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NANCY SIXTO/Examiner, Art Unit 2465
/GARY MUI/Supervisory Patent Examiner, Art Unit 2465
Prosecution Insights