DETAILED ACTION
Claim(s) 1-30 have been examined and are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 3 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 3 recites the following
“3. The apparatus of claim 1, wherein to receive the OCC configuration, the one or more processors are individually or collectively configured to cause the UE to receive the OCC configuration in one or more radio resource control messages for CG-SDT and PUR.”
Claim 3, contains a limitation involving receiving OCC configuration in one or more radio resource control messages for CG-SDT and PUR. However, its parent claim, claim 1, only requires one of CG-SDT and PUR.
“1. An apparatus for wireless communication at a user equipment (UE), comprising: one or more memories; and one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the UE to: transmit an indication of a capability for supporting an orthogonal cover code (OCC) for a configured grant (CG) small data transmission (SDT) or a preconfigured uplink resource (PUR); and receive an OCC configuration that indicates a multiplexing order and an OCC codeword for the multiplexing order, and an OCC indication that indicates how to monitor a downlink in association with supporting the OCC for the CG-SDT or the PUR.”
Due to inconsistency between the requirements of claim 3 and its parent claim 1, it is unclear as to what the Applicants intend to seek coverage for with respect to the CG-SDT and the PUR. Therefore claim 3 has been regarded as indefinite. For purposes of examination the limitation will be understood as CG-SDT or PUR.
Claim 17-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 17 recites the following
“17. The apparatus of claim 16, wherein the OCC configuration is based at least in part on the preamble, and wherein the transmission is based at least in part on the OCC configuration.”
Claim 17, contains recites the limitation, the transmission. Claim(s) 11 and 16, which are parent claim(s) to claim 17, recite the following respectively.
“11. An apparatus for wireless communication at a user equipment (UE), comprising: one or more memories; and one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the UE to: transmit a preamble associated with orthogonal cover code (OCC) support for transmission of a random access (RA) small data transmission (SDT) with a 4-step random access channel (RACH) procedure, an RA-SDT with a 2-step RACH procedure, or an early data transmission (EDT); and receive an OCC configuration that indicates a multiplexing order and an OCC codeword for the multiplexing order.”
“16. The apparatus of claim 11, wherein the OCC configuration enables the UE to transmit uplink data during transmission of an RA-SDT using an OCC.”
Claim 17 recites the transmission. However, it is not clear if it refers to the transmission of the preamble that takes place in claim 11 or the transmission of the RA-SDT referred to in claim 16. Therefore claim 17 is regarded as being indefinite. Claim(s) 18-19 are also regarded as being indefinite due to dependency on claim 17, and for also failing to resolve the indefiniteness issues with respect to claim 17. For the purposes of examination, the transmission will be understood as referring to either of RA-SDT or the preamble
Claim 21-23 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 21 recites the following
“21. The apparatus of claim 20, wherein the OCC configuration is based at least in part on the preamble, and wherein the transmission is based at least in part on the OCC configuration.”
Claim 21, contains recites the limitation, the transmission. Claim(s) 11 and 20, which are parent claim(s) to claim 21, recite the following respectively.
“11. An apparatus for wireless communication at a user equipment (UE), comprising: one or more memories; and one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the UE to: transmit a preamble associated with orthogonal cover code (OCC) support for transmission of a random access (RA) small data transmission (SDT) with a 4-step random access channel (RACH) procedure, an RA-SDT with a 2-step RACH procedure, or an early data transmission (EDT); and receive an OCC configuration that indicates a multiplexing order and an OCC codeword for the multiplexing order.”
“20. The apparatus of claim 11, wherein the OCC configuration enables the UE to transmit uplink data during transmission of an EDT using an OCC.”
Claim 17 recites the transmission. However, it is not clear if it refers to the transmission of the preamble that takes place in claim 11 or the transmission of the EDT referred to in claim 20. Therefore claim 21 is regarded as being indefinite. Claim(s) 22-23 are also regarded as being indefinite due to dependency on claim 21, and for also failing to resolve the indefiniteness issues with respect to claim 21. For purposes of examination the transmission will be understood as either of the transmitted preamble or the EDT.
Claim 25-30 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 25 recites the following
25. An apparatus for wireless communication at a network entity, comprising: one or more memories; and one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the network entity to: (1) receive a preamble or a capability indication associated with orthogonal cover code (OCC) support for a configured grant (CG) small data transmission (SDT), a preconfigured uplink resource (PUR), a random access (RA) small data transmission (SDT) with a 4-step random access channel (RACH) procedure, an RA-SDT with a 2-step RACH procedure, or an early data transmission (EDT); and (2) transmit, based at least in part on the capability indication, an OCC configuration that indicates a multiplexing order and an OCC codeword for the multiplexing order.
Claim 25, recites at least a first feature, (1) to receive a preamble or capability indication, and a second feature to (2) to transmit, based at least in part on the capability information, an OCC configuration. The second feature for transmitting the OCC configuration requires capability indication (i.e. to transmit based at least in part on the capability indication). However, the first feature makes the capability information optional (i.e. receive a preamble or capability indication). Thus, it is unclear as to the scope of which the Applicants seeks coverage with respect to claim 25. Therefore, claim 25 is regarded as indefinite. Claim(s) 26-30 are also regarded as being indefinite due to dependency on claim 25, and for also failing to resolve the indefiniteness issues with respect to claim 25. For the purposes of examination, the limitation will be understood as the following, “transmit, based at least in part on the preamble or the capability indication, an OCC configuration that indicates a multiplexing order and an OCC codeword for the multiplexing order”
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 .
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.
Claim(s) 11, 12, 13, 14, 15, 20, and 21, is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Rico Alvarino (US 20200252972 A1)
In regards to claim 11, Rico Alvarino (US 20200252972 A1) teaches an apparatus for wireless communication at a user equipment (UE), comprising: one or more memories; and one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the UE to (“[0145] FIG. 10 shows a diagram of a system 1000 including a device 1005 that supports increasing physical random access capacity using orthogonal cover codes in accordance with aspects of the present disclosure. Device 1005 may be an example of or include the components of wireless device 705, wireless device 805, or a UE 115 as described above, e.g., with reference to FIGS. 1, 2, 7, and 8. Device 1005 may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including UE PRACH OCC module 1015, processor 1020, memory 1025, software 1030, transceiver 1035, antenna 1040, and I/O controller 1045. These components may be in electronic communication via one or more buses (e.g., bus 1010). Device 1005 may communicate wirelessly with one or more base stations 105. [0146] Processor 1020 may include an intelligent hardware device, (e.g., a general-purpose processor, a DSP, a central processing unit (CPU), a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, processor 1020 may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into processor 1020. Processor 1020 may be configured to execute computer-readable instructions stored in a memory to perform various functions (e.g., functions or tasks supporting increasing physical random access capacity using orthogonal cover codes)…”):
transmit a preamble associated with orthogonal cover code (OCC) support for transmission of a random access (RA) small data transmission (SDT) with a 4-step random access channel (RACH) procedure, an RA-SDT with a 2-step RACH procedure, or an early data transmission (EDT) (“[0107] An “enhanced” UE 115 may support transmitting RACH preamble repetitions using one or more OCCs in PRACH resources 425 designated for OCCs. The enhanced UE 115 may receive signals (e.g., a SIB) from the base station 105, and may identify both the set of legacy PRACH resources 430 not supporting OCCs and the set of enhanced PRACH resources 425 supporting OCCs. The enhanced UE 115 may select to transmit a RACH preamble message or a repeated RACH preamble message in either the enhanced PRACH resources 425 or the legacy PRACH resources 430… [0109] If an enhanced UE 115 selects to transmit a RACH preamble message in the enhanced PRACH resources 425 using an OCC, the enhanced UE 115 may randomly or pseudo-randomly select a preamble and an OCC cover for transmission of the RACH preamble message. In some cases, the enhanced PRACH resources 425 may be associated with “enhanced services.” For example, these enhanced services may include connection-less data transmission from the UE 115 to the base station 105. Connection-less data transmission may involve an enhanced UE 115 performing early data transmission in the enhanced PRACH resources 425 using an OCC. In such cases, enhanced UEs 115 or legacy UEs 115 may use the legacy PRACH resources 430 without OCCs for standard connection setup (e.g., radio resource control (RRC) connection) with the base station 105. In other cases, an enhanced UE 115 may utilize the enhanced PRACH resources 425 or a subset of the enhanced PRACH resources 425 and an OCC to transmit additional information (e.g., a payload size).”); and
receive an OCC configuration that indicates a multiplexing order and an OCC codeword for the multiplexing order (“[0093] In some cases, base station 105-a may initiate the RACH procedure using a PDCCH order. Base station 105-a may transmit the PDCCH order, which may contain DCI, to UE 115-a to instruct UE 115-a to perform a system access procedure using PRACH. For example, if UE 115-a temporarily loses access to base station 105-a (e.g., due to lack of uplink synchronization), or if base station 105-a identifies that UE 115-a is about to move out of geographic coverage area 110-a and a coverage area for a different base station 105, base station 105-a may command UE 115-a to begin a PRACH system access procedure. [0094] Base station 105-a may include parameters in the PDCCH order indicating how UE 115-a may perform the system access. For example, the PDCCH order may include a preamble identifier or index, a PRACH mask index (e.g., identifying PRACH resources for UE 115-a to use), a starting coverage enhancement (CE) level, other static fields (e.g., set to zero), or some combination of these. Additionally, base station 105-a may include a field in the PDCCH order that indicates an OCC index for UE 115-a to use when applying an OCC. In some cases, the field may additionally indicate a preamble for the RACH preamble message 215… [0095] UE 115-a may determine a length (e.g., a bit length) for an OCC either explicitly or implicitly. In one example, base station 105-a may explicitly signal the OCC length, for example, in DCI or in a SIB. In a second example, UE 115-a may implicitly determine the OCC length based on a PRACH configuration or PRACH format. For example, UE 115-a may set the OCC length to the number of contiguous subframes with PRACH resources. In another example, UE 115-a may contain an indication of a maximum OCC length (e.g., 4 bits), and may determine the OCC length based on the maximum OCC length (e.g., the lesser of the maximum OCC length and the number of contiguous PRACH subframes)”).
In regards to claim 12, Rico Alvarino (US 20200252972 A1) teaches the apparatus of claim 11, wherein the one or more processors are individually or collectively configured to cause the UE to monitor for downlink communications based at least in part on the preamble that was transmitted (“[0091] In a second aspect, base station 105-a and UE 115-a may select a radio network temporary identifier (RNTI) or random access-RNTI (RA-RNTI) for encoding or decoding the RACH preamble response message based on a cover code used for the corresponding RACH preamble message 215. For example, base station 105-a and UE 115-a may use a first RNTI in cases where OCCs are not used (e.g., for legacy UEs 115 or UEs 115 that select to transmit in legacy PRACH resources without an OCC). However, if an OCC is applied, base station 105-a and UE 115-a may select an RNTI based on the applied cover code, or simply based on whether an OCC is implemented (e.g., where the applied cover code may be indicated some other way, for example, as part of a preamble identifier or in a field of the RACH response). Base station 105-a may determine the applied cover code when receiving the RACH preamble message 215, may identify the corresponding RNTI, and may encode the RACH preamble response message based on the identified RNTI. UEs 115 that transmit RACH preamble messages 215 may identify the RNTI corresponding to the transmitted RACH preamble message 215. If a UE 115 detects a RACH preamble response message, the UE 115 may attempt to decode the received signals using the identified RNTI. The UE 115, such as UE 115-a, that successfully decodes the RACH preamble response message using an RNTI corresponding to the RACH preamble message 215 may identify the preamble identifier for its RACH preamble message 215 indicated in the RACH response message. Based on the successful decoding with the RNTI and the preamble identifier, UE 115-a may determine that the RACH preamble response message is in response to the RACH preamble message 215 of UE 115-a. Other UEs 115 attempting to decode the RACH response may be unsuccessful based on using incorrect RNTIs or may not determine a preamble identifier corresponding to those UEs 115, as the RACH preamble response message was not encoded based on the parameters these UEs 115 used to transmit RACH preamble messages 215.”).
In regards to claim 13, Rico Alvarino (US 20200252972 A1) teaches the apparatus of claim 11, wherein the one or more processors are individually or collectively configured to cause the UE to receive a system information block (SIB) that enables SDT transmission with an OCC or EDT transmission with an OCC (“[0093] In some cases, base station 105-a may initiate the RACH procedure using a PDCCH order. Base station 105-a may transmit the PDCCH order, which may contain DCI, to UE 115-a to instruct UE 115-a to perform a system access procedure using PRACH. For example, if UE 115-a temporarily loses access to base station 105-a (e.g., due to lack of uplink synchronization), or if base station 105-a identifies that UE 115-a is about to move out of geographic coverage area 110-a and a coverage area for a different base station 105, base station 105-a may command UE 115-a to begin a PRACH system access procedure. [0094] Base station 105-a may include parameters in the PDCCH order indicating how UE 115-a may perform the system access. For example, the PDCCH order may include a preamble identifier or index, a PRACH mask index (e.g., identifying PRACH resources for UE 115-a to use), a starting coverage enhancement (CE) level, other static fields (e.g., set to zero), or some combination of these. Additionally, base station 105-a may include a field in the PDCCH order that indicates an OCC index for UE 115-a to use when applying an OCC. In some cases, the field may additionally indicate a preamble for the RACH preamble message 215… [0095] UE 115-a may determine a length (e.g., a bit length) for an OCC either explicitly or implicitly. In one example, base station 105-a may explicitly signal the OCC length, for example, in DCI or in a SIB. In a second example, UE 115-a may implicitly determine the OCC length based on a PRACH configuration or PRACH format. For example, UE 115-a may set the OCC length to the number of contiguous subframes with PRACH resources. In another example, UE 115-a may contain an indication of a maximum OCC length (e.g., 4 bits), and may determine the OCC length based on the maximum OCC length (e.g., the lesser of the maximum OCC length and the number of contiguous PRACH subframes)”).
In regards to claim 14, Rico Alvarino (US 20200252972 A1) teaches the apparatus of claim 11, wherein the preamble or a RACH occasion (RO) is from a resource pool associated with OCC support for UEs (“[0087] In a second aspect of increasing PRACH capacity using OCCs, a base station 105 and UE 115 may support separate format indications for OCC or non-OCC transmissions. For example, base station 105-a may signal at least two PRACH configurations, where at least one PRACH configuration indicates PRACH resources supporting OCCs and at least one other PRACH configuration indicates PRACH resources not configured to support OCCs. Legacy UEs 115 may transmit using the PRACH resources not configured to support OCCs, while enhanced UEs 115 may transmit in either set of PRACH resources. For examples, UE 115-a may transmit in PRACH resources supporting OCCs whenever UE 115-a identifies these enhanced resources, or may select which set of resources to use—and, correspondingly, whether or not to apply an OCC—using a random or pseudo-random selection process, which may or may not depend on a weight value. In some cases, base station 105-a may signal this weight value to one or more UEs 115 in a system information block (SIB), dedicated signaling, or a combination of the two.”).
In regards to claim 15, Rico Alvarino (US 20200252972 A1) teaches the apparatus of claim 11, wherein the one or more processors are individually or collectively configured to cause the UE to receive an OCC indication that indicates how to monitor a downlink in association with OCC support (
“[0091] In a second aspect, base station 105-a and UE 115-a may select a radio network temporary identifier (RNTI) or random access-RNTI (RA-RNTI) for encoding or decoding the RACH preamble response message based on a cover code used for the corresponding RACH preamble message 215. For example, base station 105-a and UE 115-a may use a first RNTI in cases where OCCs are not used (e.g., for legacy UEs 115 or UEs 115 that select to transmit in legacy PRACH resources without an OCC). However, if an OCC is applied, base station 105-a and UE 115-a may select an RNTI based on the applied cover code, or simply based on whether an OCC is implemented (e.g., where the applied cover code may be indicated some other way, for example, as part of a preamble identifier or in a field of the RACH response). Base station 105-a may determine the applied cover code when receiving the RACH preamble message 215, may identify the corresponding RNTI, and may encode the RACH preamble response message based on the identified RNTI. UEs 115 that transmit RACH preamble messages 215 may identify the RNTI corresponding to the transmitted RACH preamble message 215. If a UE 115 detects a RACH preamble response message, the UE 115 may attempt to decode the received signals using the identified RNTI. The UE 115, such as UE 115-a, that successfully decodes the RACH preamble response message using an RNTI corresponding to the RACH preamble message 215 may identify the preamble identifier for its RACH preamble message 215 indicated in the RACH response message. Based on the successful decoding with the RNTI and the preamble identifier, UE 115-a may determine that the RACH preamble response message is in response to the RACH preamble message 215 of UE 115-a. Other UEs 115 attempting to decode the RACH response may be unsuccessful based on using incorrect RNTIs or may not determine a preamble identifier corresponding to those UEs 115, as the RACH preamble response message was not encoded based on the parameters these UEs 115 used to transmit RACH preamble messages 215.”).
In regards to claim 20, Rico Alvarino (US 20200252972 A1) teaches the apparatus of claim 11, wherein the OCC configuration enables the UE to transmit uplink data during transmission of an EDT using an OCC (“[0107] An “enhanced” UE 115 may support transmitting RACH preamble repetitions using one or more OCCs in PRACH resources 425 designated for OCCs. The enhanced UE 115 may receive signals (e.g., a SIB) from the base station 105, and may identify both the set of legacy PRACH resources 430 not supporting OCCs and the set of enhanced PRACH resources 425 supporting OCCs. The enhanced UE 115 may select to transmit a RACH preamble message or a repeated RACH preamble message in either the enhanced PRACH resources 425 or the legacy PRACH resources 430… [0109] If an enhanced UE 115 selects to transmit a RACH preamble message in the enhanced PRACH resources 425 using an OCC, the enhanced UE 115 may randomly or pseudo-randomly select a preamble and an OCC cover for transmission of the RACH preamble message. In some cases, the enhanced PRACH resources 425 may be associated with “enhanced services.” For example, these enhanced services may include connection-less data transmission from the UE 115 to the base station 105. Connection-less data transmission may involve an enhanced UE 115 performing early data transmission in the enhanced PRACH resources 425 using an OCC. In such cases, enhanced UEs 115 or legacy UEs 115 may use the legacy PRACH resources 430 without OCCs for standard connection setup (e.g., radio resource control (RRC) connection) with the base station 105. In other cases, an enhanced UE 115 may utilize the enhanced PRACH resources 425 or a subset of the enhanced PRACH resources 425 and an OCC to transmit additional information (e.g., a payload size).”);
In regards to claim 21, Rico Alvarino (US 20200252972 A1) teaches the the apparatus of claim 20, wherein the OCC configuration is based at least in part on the preamble, and wherein the transmission is based at least in part on the OCC configuration (See in RICO ALVARINO where the OCC configuration is for configuring preambles, and where the preamble is transmitted based on the OCC configuration, “[0093] In some cases, base station 105-a may initiate the RACH procedure using a PDCCH order. Base station 105-a may transmit the PDCCH order, which may contain DCI, to UE 115-a to instruct UE 115-a to perform a system access procedure using PRACH. For example, if UE 115-a temporarily loses access to base station 105-a (e.g., due to lack of uplink synchronization), or if base station 105-a identifies that UE 115-a is about to move out of geographic coverage area 110-a and a coverage area for a different base station 105, base station 105-a may command UE 115-a to begin a PRACH system access procedure. [0094] Base station 105-a may include parameters in the PDCCH order indicating how UE 115-a may perform the system access. For example, the PDCCH order may include a preamble identifier or index, a PRACH mask index (e.g., identifying PRACH resources for UE 115-a to use), a starting coverage enhancement (CE) level, other static fields (e.g., set to zero), or some combination of these. Additionally, base station 105-a may include a field in the PDCCH order that indicates an OCC index for UE 115-a to use when applying an OCC. In some cases, the field may additionally indicate a preamble for the RACH preamble message 215… [0095] UE 115-a may determine a length (e.g., a bit length) for an OCC either explicitly or implicitly. In one example, base station 105-a may explicitly signal the OCC length, for example, in DCI or in a SIB. In a second example, UE 115-a may implicitly determine the OCC length based on a PRACH configuration or PRACH format. For example, UE 115-a may set the OCC length to the number of contiguous subframes with PRACH resources. In another example, UE 115-a may contain an indication of a maximum OCC length (e.g., 4 bits), and may determine the OCC length based on the maximum OCC length (e.g., the lesser of the maximum OCC length and the number of contiguous PRACH subframes)”. ).
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.
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.
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.
Claim(s) 16 and 17, is/are rejected under 35 U.S.C. 103 as being unpatentable over Rico Alvarino (US 20200252972 A1) in view of LIBERG (WO 2025126156 A1).
In regards to claim 16, Rico Alvarino (US 20200252972 A1) is silent on the apparatus of claim 11, wherein the OCC configuration enables the UE to transmit Rico Alvarino (US 20200252972 A1) differs from claim 1, in that while Rico Alvarino (US 20200252972 A1) teaches a feature for applying orthogonal cover codes (OCC) to uplink transmissions, specifically NPRACH preamble transmissions, SHAH is silent on applying OCC to uplink transmissions, such as a RA-SDT. Thus, SHAH is silent on a feature wherein the OCC configuration enables the UE to transmit uplink data during transmission of an RA-SDT using an OCC. Despite these differences similar features have been seen in other prior art involving use of OCC for uplink transmissions.
LIBERG (WO 2025126156 A1) suggests applying OCC for a RA-SDT ([0056] One example of the ‘EDT for loT NTN’ procedure is the following: • Step 400: The BS in SI configures periodic PUSCH resources with a fixed MCS and repetition-level per PUSCH resource (and number off OCC/cyclic DM-RS shifts, and other information). In other words, the BS configures multiple radio resource pools where, in this example, each radio resource pool includes a single periodic PUSCH resource with an associated fixed MCS and repetition-level. • Steps 402 and 404: The UE upon data transmission choses a PUSCH resource with the appropriate TBS, and MCS and repetition-level (e.g., based on RSRP-measurement) and randomly picks an orthogonal resource (OCC/cyclic DM-RS shifts, etc.). In other words, the UE selects a PUSCH resource (from among those configured) that has an appropriate TBS, MCS, and repetition level (e.g., based on RSRP measurement), randomly selects an orthogonal resource (e.g., OCC or cyclic DM-RS shift) from among those associated to the selected PUSCH resource, and transmits PUSCH on the selected PUSCH resource using the selected orthogonal code and the associated TBS, MCS, and repetition level…. [0057] This procedure is applicable in any network supporting the method, i.e. both terrestrial and non-terrestrial networks. I.e., even though the solution is discussed for EDT in use with loT NTN, it is equally applicable to EDT alone, common Preconfigured Uplink Resource (PUR) resources (if such a solution later introduced), or to for NR small data transmission (SDT) in combination with NR NTN, to RA-SDT alone, or to common Configured Grant (CG)-SDT resources (if such a solution is later introduced).).
Thus, based upon the teachings of LIBERG (WO 2025126156 A1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the OCC feature of Rico Alvarino (US 20200252972 A1), by also applying the OCC feature to an uplink RA-SDT transmission, as similarly seen in LIBERG to thus arrive at the apparatus of claim 11, wherein the OCC configuration enables the UE to transmit uplink data during transmission of an RA-SDT using an OCC, in order to provide the benefits of OCC to uplink transmissions such as RA-SDT in addition to or in-lieu of NR-PRACH(s) transmissions.
In regards to claim 17, Rico Alvarino (US 20200252972 A1) in view of LIBERG (WO 2025126156 A1) suggest the apparatus of claim 16, wherein the OCC configuration is based at least in part on the preamble, and wherein the transmission is based at least in part on the OCC configuration (See in RICO ALVARINO where the OCC configuration is for configuring preambles, and where the preamble is transmitted based on the OCC configuration, “[0093] In some cases, base station 105-a may initiate the RACH procedure using a PDCCH order. Base station 105-a may transmit the PDCCH order, which may contain DCI, to UE 115-a to instruct UE 115-a to perform a system access procedure using PRACH. For example, if UE 115-a temporarily loses access to base station 105-a (e.g., due to lack of uplink synchronization), or if base station 105-a identifies that UE 115-a is about to move out of geographic coverage area 110-a and a coverage area for a different base station 105, base station 105-a may command UE 115-a to begin a PRACH system access procedure. [0094] Base station 105-a may include parameters in the PDCCH order indicating how UE 115-a may perform the system access. For example, the PDCCH order may include a preamble identifier or index, a PRACH mask index (e.g., identifying PRACH resources for UE 115-a to use), a starting coverage enhancement (CE) level, other static fields (e.g., set to zero), or some combination of these. Additionally, base station 105-a may include a field in the PDCCH order that indicates an OCC index for UE 115-a to use when applying an OCC. In some cases, the field may additionally indicate a preamble for the RACH preamble message 215… [0095] UE 115-a may determine a length (e.g., a bit length) for an OCC either explicitly or implicitly. In one example, base station 105-a may explicitly signal the OCC length, for example, in DCI or in a SIB. In a second example, UE 115-a may implicitly determine the OCC length based on a PRACH configuration or PRACH format. For example, UE 115-a may set the OCC length to the number of contiguous subframes with PRACH resources. In another example, UE 115-a may contain an indication of a maximum OCC length (e.g., 4 bits), and may determine the OCC length based on the maximum OCC length (e.g., the lesser of the maximum OCC length and the number of contiguous PRACH subframes)”. ).
Claim(s) 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rico Alvarino (US 20200252972 A1) in view of YIN (US 20260032675 A1).
In regards to claim 24, Rico Alvarino (US 20200252972 A1) is silent on the apparatus of claim 11, wherein the one or more processors are individually or collectively configured to cause the UE to receive an updated OCC configuration that: changes one or more of the multiplexing order, the OCC codeword for the multiplexing order, and the OCC indication, disables use of an OCC for an RA-SDT or an EDT, or enables one or more of a new multiplexing order, a new OCC codeword for the new multiplexing order, or a new OCC indication for a next RA-SDT or a next EDT. Despite these differences similar features have been seen in other prior art involving use of orthogonal cover codes for data transmission. YIN for example suggests a feature for dynamically indicating an OCC codeword (i.e. OCC index), through use of downlink control information (DCI), enabling the update of the OCC codeword through use of the DCI (“[0162] In this method, an IoT NTN device is configured with either NPUSCH with OCC or NPUSCH without OCC. Dynamic switching between OCC and non-OCC is not supported. [0163] If OCC is configured by higher layer signaling, the OCC multiplexing factor or OCC length or OCC capacity should be further configured by higher layer signaling, i.e. RRC signaling. The OCC multiplexing factor may be configured as 2 or 4 at least. Higher multiplexing factor, e.g. 8, may be supported. In this method, the OCC length cannot be dynamically changed either. The higher layer signaling can be a RRC configuration. The higher layer signaling can be a combination of RRC configuration and MAC CE. For example, one or more configurations are included in a RRC signaling, and a MAC CE is used to indicate which parameter or set of parameters are applied. [0164] With configured OCC multiplexing factor or OCC length, the OCC index may be dynamically indicated by the eNB to the NTN-IoT device in the scheduling DCI. If OCC multiplexing factor of 2 is configured, 1 bit is needed to indicate the OCC index 0 or 1. If OCC multiplexing factor of 4 is configured, 2 bits are needed to indicate the OCC index. [0165] The indication can be performed by the NPUSCH scheduling DCI, i.e. DCI format N0. Due to limited IoT capability, the DCI total number of bits, i.e. 23 bits in DCI format N0 should not be changed. Therefore, some approaches may be defined to provide the required 1 or 2 bits for DCI format N0, as discussed in detail below.”).
YIN also suggests a feature for dynamically indicating an OCC feature (whether OCC is ON or OFF) and OCC codeword (i.e. OCC index), through use of downlink control information (DCI), enabling the updating of the OCC, or rather the turning on or off the OCC feature, and adjustment of the OCC codeword through use of the DCI (“[0192] Alternatively or additionally, the OCC method and OCC multiplexing factor can be semi-statically configured, but whether OCC is applied is dynamically indicated by the DCI. If OCC is applied, OCC index is also dynamically indicated by the DCI. This is similar to semi-persistent configurations, the OCC on/off is similar to an activation/deactivation process for a semi-persistent configuration.”).
YIN further suggests a feature for dynamically indicating an ON/OFF status of an OCC feature, an OCC codeword (i.e. OCC index), and OCC multiplexing factor through use of downlink control information (DCI). Thus, enabling the updating of the ON/OFF status of the OCC feature, a selected OCC codeword, and selected the OCC multiplexing factor through use of the DCI (“Method 3: Dynamic Indication of OCC Method, OCC Multiplexing Factor and OCC Index. [0210] To provide maximum scheduling flexibility, all parameters can be scheduled by the DCI. Thus, at least 1 bit for OCC on/off, 1 bit for OCC length or OCC multiplexing factor, and 1 or 2 bits for the OCC index.”).
Thus, based upon the teachings of YIN, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1), by dynamically indicating features such as a OCC ON/OFF feature, OCC codeword, and/or OCC multiplexing factor through the use of DCI, to thus arrive at the apparatus of claim 11, wherein the one or more processors are individually or collectively configured to cause the UE to receive an updated OCC configuration that: changes one or more of the multiplexing order, the OCC codeword for the multiplexing order, and the OCC indication, disables use of an OCC for an RA-SDT or an EDT, or enables one or more of a new multiplexing order, a new OCC codeword for the new multiplexing order, or a new OCC indication for a next RA-SDT or a next EDT, in order to provide support for different uplink transmission configurations depending on whether OCC is supported or not.
Claim(s) 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1).
In regards to claim 25, SHAH (US 20240407006 A1) teaches an apparatus for wireless communication at a network entity, comprising: one or more memories; and one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the network entity to (“[0022] An apparatus for wireless communications at a network entity is described. The apparatus may include at least one processor, at least one memory coupled with the at least one processor, and instructions stored in the at least one memory. The instructions may be executable by the at least one processor to cause the apparatus to perform an access procedure for establishing a connection with a UE and receive, as part of the access procedure, one or more repetitions of a NPRACH preamble from the UE, each repetition of the one or more repetitions including a set of symbol groups, and each symbol group of the set of symbol groups including a set of symbols for receiving the NPRACH preamble from the UE, the set of symbols including a subset of symbols to which an OCC is applied, where the set of symbols is multiplexed with one or more other sets of symbols associated with preambles of one or more other UEs.”):
receive a preamble or a capability indication associated with orthogonal cover code (OCC) support
transmit, based at least in part on the capability indication, an OCC configuration that indicates a multiplexing order and an OCC codeword for the multiplexing order (“[0144] At 1105, the UE 115-u may transmit a capability message indicating a capability of the UE 115-u to support NPRACH multiplexing. The capability of the UE 115-u for NPRACH multiplexing may be based on phase coherence capabilities associated with the UE 115-u, and the capability message may indicate a phase coherence capability of the UE 115-u. [0145] At 1110, the UE 115-u may receive a configuration message indicating a configuration of the NPRACH preamble. The network entity 105-c may receive the configuration message via RRC, MAC-CE, system information, or other signaling that may configure the UE 115-u with one or more preambles to transmit. The configuration message may include UE specific configuration information regarding an NPRACH orthogonal cover coding configuration to be used for transmitting the NPRACH preamble. For example, the configuration message may include a multiplexing order M (e.g., quantity of UEs or quantity of preambles to be multiplexed). The multiplexing order M may be based on a phase coherence capability reported from the UE 115-u. The configuration message may indicate a configuration of one or more candidate configurations (e.g., using an index). The configuration message may assign an OCC codeword to the UE 115-u for multiplexing, or the configuration message may indicate one or more OCCs including the OCC to be used by the UE 115-u for multiplexing. In some examples, the UE 115-u may receive the configuration message via a system information block.”)
SHAH differs from claim 25, in that while SHAH teaches a feature for applying orthogonal cover codes (OCC) to uplink transmissions, specifically NPRACH preamble transmissions, SHAH is silent on applying OCC to uplink transmissions, such as a configured grant (CG) small data transmission (SDT), a preconfigured uplink resource (PUR), a random access (RA) small data transmission (SDT) with a 4-step random access channel (RACH) procedure, an RA-SDT with a 2-step RACH procedure, or an early data transmission (EDT). Thus, SHAH is silent on a feature where the indication of the capability for supporting the orthogonal cover code (OCC) is for a configured grant (CG) small data transmission (SDT), a preconfigured uplink resource (PUR), a random access (RA) small data transmission (SDT) with a 4-step random access channel (RACH) procedure, an RA-SDT with a 2-step RACH procedure, or an early data transmission (EDT) or a preconfigured uplink resource (PUR), as arranged with the remaining elements of claim 25. Despite these differences similar features have been seen in other prior art involving use of OCC for uplink transmissions.
LIBERG (WO 2025126156 A1) suggests applying OCC for a CG-SDT, PUR, RA-SDT, or EDT, ([0056] One example of the ‘EDT for loT NTN’ procedure is the following: • Step 400: The BS in SI configures periodic PUSCH resources with a fixed MCS and repetition-level per PUSCH resource (and number off OCC/cyclic DM-RS shifts, and other information). In other words, the BS configures multiple radio resource pools where, in this example, each radio resource pool includes a single periodic PUSCH resource with an associated fixed MCS and repetition-level. • Steps 402 and 404: The UE upon data transmission choses a PUSCH resource with the appropriate TBS, and MCS and repetition-level (e.g., based on RSRP-measurement) and randomly picks an orthogonal resource (OCC/cyclic DM-RS shifts, etc.). In other words, the UE selects a PUSCH resource (from among those configured) that has an appropriate TBS, MCS, and repetition level (e.g., based on RSRP measurement), randomly selects an orthogonal resource (e.g., OCC or cyclic DM-RS shift) from among those associated to the selected PUSCH resource, and transmits PUSCH on the selected PUSCH resource using the selected orthogonal code and the associated TBS, MCS, and repetition level…. [0057] This procedure is applicable in any network supporting the method, i.e. both terrestrial and non-terrestrial networks. I.e., even though the solution is discussed for EDT in use with loT NTN, it is equally applicable to EDT alone, common Preconfigured Uplink Resource (PUR) resources (if such a solution later introduced), or to for NR small data transmission (SDT) in combination with NR NTN, to RA-SDT alone, or to common Configured Grant (CG)-SDT resources (if such a solution is later introduced).).
Thus, based upon the teachings of LIBERG (WO 2025126156 A1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the OCC feature of SHAH (US 20240407006 A1), by also applying the OCC feature to CG-SDT, PUR, RA-SDT, or an EDT, as similarly seen in LIBERG to thus arrive at a feature to receive a preamble or a capability indication associated with orthogonal cover code (OCC) support for a configured grant (CG) small data transmission (SDT), a preconfigured uplink resource (PUR), a random access (RA) small data transmission (SDT) with a 4-step random access channel (RACH) procedure, an RA-SDT with a 2-step RACH procedure, or an early data transmission (EDT), to thus arrive at claim 25, in order to provide the benefits of OCC to uplink transmissions such as CG-SDT, PUR, RA-SDT, and/or EDT transmissions, in addition to or in-lieu of NR-PRACH(s) transmissions.
Claim(s) 1, 2, 3, 4, 5, 6, 7, 9, 10, 26, 27, and 30, is/are rejected under 35 U.S.C. 103 as being unpatentable over SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN (US 20260032675 A1)
In regards to claim 1, SHAH (US 20240407006 A1) teaches an apparatus for wireless communication at a user equipment (UE), comprising: one or more memories; and one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the UE to (“[0005] An apparatus for wireless communications at a UE is described. The apparatus may include at least one processor, at least one memory coupled with the at least one processor, and instructions stored in the at least one memory. The instructions may be executable by the at least one processor to cause the apparatus to perform an access procedure for establishing a connection with a network entity and transmit, as part of the access procedure, one or more repetitions of a NPRACH preamble to the network entity, each repetition of the one or more repetitions including a set of symbol groups, and each symbol group of the set of symbol groups including a set of symbols used by the UE for transmitting the NPRACH preamble, the set of symbols including a subset of symbols to which an OCC is applied, where the set of symbols is multiplexed with one or more other sets of symbols associated with respective preambles of one or more other UEs.”):
transmit an indication of a capability for supporting an orthogonal cover code (OCC)
receive an OCC configuration that indicates a multiplexing order and an OCC codeword for the multiplexing order, and an (“[0144] At 1105, the UE 115-u may transmit a capability message indicating a capability of the UE 115-u to support NPRACH multiplexing. The capability of the UE 115-u for NPRACH multiplexing may be based on phase coherence capabilities associated with the UE 115-u, and the capability message may indicate a phase coherence capability of the UE 115-u. [0145] At 1110, the UE 115-u may receive a configuration message indicating a configuration of the NPRACH preamble. The network entity 105-c may receive the configuration message via RRC, MAC-CE, system information, or other signaling that may configure the UE 115-u with one or more preambles to transmit. The configuration message may include UE specific configuration information regarding an NPRACH orthogonal cover coding configuration to be used for transmitting the NPRACH preamble. For example, the configuration message may include a multiplexing order M (e.g., quantity of UEs or quantity of preambles to be multiplexed). The multiplexing order M may be based on a phase coherence capability reported from the UE 115-u. The configuration message may indicate a configuration of one or more candidate configurations (e.g., using an index). The configuration message may assign an OCC codeword to the UE 115-u for multiplexing, or the configuration message may indicate one or more OCCs including the OCC to be used by the UE 115-u for multiplexing. In some examples, the UE 115-u may receive the configuration message via a system information block.”).
SHAH differs from claim 1, in that while SHAH teaches a feature for applying orthogonal cover codes (OCC) to uplink transmissions, specifically NPRACH preamble transmissions, SHAH is silent on applying OCC to uplink transmissions, such as a configured grant (CG) small data transmission (SDT) or a preconfigured uplink resource (PUR). Thus, SHAH is silent on a feature where the indication of the capability for supporting the orthogonal cover code (OCC) is for a configured grant (CG) small data transmission (SDT) or a preconfigured uplink resource (PUR). SHAH further differs from claim 1 in that SHAH is silent on receiving an OCC indication that indicates how to monitor a downlink in association with supporting the OCC for the CG-SDT or the PUR. Despite these differences similar features have been seen in other prior art involving use of OCC for uplink transmissions.
LIBERG (WO 2025126156 A1) suggests applying OCC for a CG-SDT or a PUR ([0056] One example of the ‘EDT for loT NTN’ procedure is the following: • Step 400: The BS in SI configures periodic PUSCH resources with a fixed MCS and repetition-level per PUSCH resource (and number off OCC/cyclic DM-RS shifts, and other information). In other words, the BS configures multiple radio resource pools where, in this example, each radio resource pool includes a single periodic PUSCH resource with an associated fixed MCS and repetition-level. • Steps 402 and 404: The UE upon data transmission choses a PUSCH resource with the appropriate TBS, and MCS and repetition-level (e.g., based on RSRP-measurement) and randomly picks an orthogonal resource (OCC/cyclic DM-RS shifts, etc.). In other words, the UE selects a PUSCH resource (from among those configured) that has an appropriate TBS, MCS, and repetition level (e.g., based on RSRP measurement), randomly selects an orthogonal resource (e.g., OCC or cyclic DM-RS shift) from among those associated to the selected PUSCH resource, and transmits PUSCH on the selected PUSCH resource using the selected orthogonal code and the associated TBS, MCS, and repetition level…. [0057] This procedure is applicable in any network supporting the method, i.e. both terrestrial and non-terrestrial networks. I.e., even though the solution is discussed for EDT in use with loT NTN, it is equally applicable to EDT alone, common Preconfigured Uplink Resource (PUR) resources (if such a solution later introduced), or to for NR small data transmission (SDT) in combination with NR NTN, to RA-SDT alone, or to common Configured Grant (CG)-SDT resources (if such a solution is later introduced).).
Thus, based upon the teachings of LIBERG (WO 2025126156 A1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the OCC feature of SHAH (US 20240407006 A1), by also applying the OCC feature to CG-SDT or a PUR, as similarly seen in LIBERG to thus arrive at a feature to transmit the indication of the capability for supporting an orthogonal cover code (OCC) for a configured grant (CG) small data transmission (SDT) or a preconfigured uplink resource (PUR), as arranged in claim 1, in order to provide the benefits of OCC to uplink transmissions such as CG-SDT or PUR in addition to or in-lieu of NR-PRACH(s) transmissions.
The combined teachings of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) further differ from claim 1, in that the combined teachings are silent on a feature to receive an OCC indication that indicates how to monitor a downlink in association with supporting the OCC for the CG-SDT or the PUR. Despite these differences similar features have been seen in other prior art involving use of OCC for uplink transmissions.
YIN (US 20260032675 A1) teaches where for multiplexed OCC transmissions, an indication is received in downlink control information (DCI) that indicates how to monitor (i.e. interpret) a downlink in association with supporting OCC, where depending on whether or not OCC supported, bits monitored/interpreted differently (i.e. understood as either having information indicating an OCC level/multiplexing level and OCC code, or not having that information). See where, YIN (US 20260032675 A1) recites, the following, “Method 3: Dynamic Indication of OCC Method, OCC Multiplexing Factor and OCC Index. [0210] To provide maximum scheduling flexibility, all parameters can be scheduled by the DCI. Thus, at least 1 bit for OCC on/off, 1 bit for OCC length or OCC multiplexing factor, and 1 or 2 bits for the OCC index… Alternative 1: Define a Mapping Table for Different OCC Combination and Indicate the Index in the Table [0211] Including no OCC case, OCC with length 2 and 4, there are a total of 7 possible combinations, i.e.: [0212] no OCC. [0213] OCC 2x with OCC index 0 [0214] OCC 2x with OCC index 1 [0215] OCC 4x with OCC index 0 [0216] OCC 4x with OCC index 1 [0217] OCC 4x with OCC index 2 [0218] OCC 4x with OCC index 3… Alternative 2: Separate Bits for OCC on/Off, OCC Length and OCC Index
[0224] In another alternative, some bits may be used for OCC on/off and OCC length parameter. And separate bits are allocated for OCC index if OCC is indicated.”
Thus, based upon the teachings of YIN it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the OCC feature suggested by the combined teachings of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) by, adopting YIN’s feature for indicating how to monitor a downlink in association with supporting the OCC, through use of DCI, to arrive at feature to receive the OCC configuration that indicates the multiplexing order and the OCC codeword for the multiplexing order, and an OCC indication that indicates how to monitor a downlink in association with supporting the OCC for the CG-SDT or the PUR, to thus arrive at claim 1, in order to provide support for different uplink transmission configurations depending on whether OCC is supported or not.
In regards to claim 26, with respect to the apparatus of claim 25, wherein the one or more processors are individually or collectively configured to cause the network entity to transmit an OCC indication that indicates whether to monitor a downlink in association with OCC support. The combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) is believed to suggest the apparatus of claim 25, for the reasons provided in regards to claim 25 above. With respect to the remaining features of claim 26, The combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) is silent on the apparatus of claim 25, wherein the one or more processors are individually or collectively configured to cause the network entity to transmit an OCC indication that indicates whether to monitor a downlink in association with OCC support. Despite these differences similar features have been seen in other prior art involving use of OCC for uplink transmissions.
YIN (US 20260032675 A1) teaches where for multiplexed OCC transmissions, an indication is received in downlink control information (DCI) that indicates whether to monitor (i.e. interpret) a downlink in association with supporting OCC, where depending on whether or not OCC supported, bits monitored/interpreted differently (i.e. understood as either having information indicating an OCC level/multiplexing level and OCC code, or not having that information). See where, YIN (US 20260032675 A1) recites, the following, “Method 3: Dynamic Indication of OCC Method, OCC Multiplexing Factor and OCC Index. [0210] To provide maximum scheduling flexibility, all parameters can be scheduled by the DCI. Thus, at least 1 bit for OCC on/off, 1 bit for OCC length or OCC multiplexing factor, and 1 or 2 bits for the OCC index… Alternative 1: Define a Mapping Table for Different OCC Combination and Indicate the Index in the Table [0211] Including no OCC case, OCC with length 2 and 4, there are a total of 7 possible combinations, i.e.: [0212] no OCC. [0213] OCC 2x with OCC index 0 [0214] OCC 2x with OCC index 1 [0215] OCC 4x with OCC index 0 [0216] OCC 4x with OCC index 1 [0217] OCC 4x with OCC index 2 [0218] OCC 4x with OCC index 3… Alternative 2: Separate Bits for OCC on/Off, OCC Length and OCC Index
[0224] In another alternative, some bits may be used for OCC on/off and OCC length parameter. And separate bits are allocated for OCC index if OCC is indicated.”
Thus, based upon the teachings of YIN it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the OCC feature suggested by the combined teachings of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) by, adopting YIN’s feature for indicating whether to monitor a downlink in association with supporting the OCC, through use of DCI, to arrive at feature wherein the one or more processors are individually or collectively configured to cause the network entity to transmit an OCC indication that indicates whether to monitor a downlink in association with OCC support, to thus arrive at claim 26, in order to provide support for different uplink transmission configurations depending on whether OCC is supported or not.
In regards to claim 27, which claims the apparatus of claim 25, wherein resources for OCC support for a CG-SDT, a PUR, an RA-SDT, or an EDT are different than resources for non-OCC support for a CG-SDT, a PUR, an RA-SDT, or an EDT ,the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) is believed to suggest the apparatus of claim 25, for the reasons provided in regards to claim 25 above. With respect to the remaining features of claim 27, similar features have been seen in other prior art involving the use of OCC for uplink transmissions.
With respect to the feature of providing resources (i.e. OCC, the orthogonal cover code) for OCC support of a CG-SDT, a PUR, an RA-SDT, or an EDT, LIBERG (WO 2025126156 A1) suggests said feature ([0056] One example of the ‘EDT for loT NTN’ procedure is the following: • Step 400: The BS in SI configures periodic PUSCH resources with a fixed MCS and repetition-level per PUSCH resource (and number off OCC/cyclic DM-RS shifts, and other information). In other words, the BS configures multiple radio resource pools where, in this example, each radio resource pool includes a single periodic PUSCH resource with an associated fixed MCS and repetition-level. • Steps 402 and 404: The UE upon data transmission choses a PUSCH resource with the appropriate TBS, and MCS and repetition-level (e.g., based on RSRP-measurement) and randomly picks an orthogonal resource (OCC/cyclic DM-RS shifts, etc.). In other words, the UE selects a PUSCH resource (from among those configured) that has an appropriate TBS, MCS, and repetition level (e.g., based on RSRP measurement), randomly selects an orthogonal resource (e.g., OCC or cyclic DM-RS shift) from among those associated to the selected PUSCH resource, and transmits PUSCH on the selected PUSCH resource using the selected orthogonal code and the associated TBS, MCS, and repetition level…. [0057] This procedure is applicable in any network supporting the method, i.e. both terrestrial and non-terrestrial networks. I.e., even though the solution is discussed for EDT in use with loT NTN, it is equally applicable to EDT alone, common Preconfigured Uplink Resource (PUR) resources (if such a solution later introduced), or to for NR small data transmission (SDT) in combination with NR NTN, to RA-SDT alone, or to common Configured Grant (CG)-SDT resources (if such a solution is later introduced).).
Thus, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) is believed to suggest the apparatus of claim 25, further comprising resources for OCC support for a CG-SDT, a PUR, an RA-SDT, or an EDT. However, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) is silent on non-OCC support, and thus is silent on the apparatus of claim 25, wherein resources for OCC support for a CG-SDT, a PUR, an RA-SDT, or an EDT are different than resources for non-OCC support for a CG-SDT, a PUR, an RA-SDT, or an EDT. Despite these differences similar features have been seen in other prior art involving use of OCC for uplink transmissions.
YIN (US 20260032675 A1) teaches where for multiplexed OCC transmissions, an indication is received in downlink control information (DCI) that indicates whether to monitor (i.e. interpret) a downlink in association with supporting OCC, where depending on whether or not OCC supported, bits monitored/interpreted differently (i.e. understood as either having information indicating an OCC level/multiplexing level and OCC code, or not having that information). YIN further teaches providing different resources (i.e. OCC codes, different resource mapping) for transmissions supporting OCC as opposed to the resources providing to those transmissions that don’t support OCC (i.e. OCC code(s) aren’t provided, different resource mapping) , See where, YIN (US 20260032675 A1) recites, the following, “[0051] NPUSCH with OCC and NPUSCH without OCC may have different resource mapping and transport block segmentation methods. Thus, the UE should be indicated by the Next Generation Node B (gNB) on whether OCC is applied or not. Furthermore, the OCC multiplexing factor should be signaled if OCC is supported…Method 3: Dynamic Indication of OCC Method, OCC Multiplexing Factor and OCC Index. [0210] To provide maximum scheduling flexibility, all parameters can be scheduled by the DCI. Thus, at least 1 bit for OCC on/off, 1 bit for OCC length or OCC multiplexing factor, and 1 or 2 bits for the OCC index… Alternative 1: Define a Mapping Table for Different OCC Combination and Indicate the Index in the Table [0211] Including no OCC case, OCC with length 2 and 4, there are a total of 7 possible combinations, i.e.: [0212] no OCC. [0213] OCC 2x with OCC index 0 [0214] OCC 2x with OCC index 1 [0215] OCC 4x with OCC index 0 [0216] OCC 4x with OCC index 1 [0217] OCC 4x with OCC index 2 [0218] OCC 4x with OCC index 3… Alternative 2: Separate Bits for OCC on/Off, OCC Length and OCC Index
[0224] In another alternative, some bits may be used for OCC on/off and OCC length parameter. And separate bits are allocated for OCC index if OCC is indicated.[0225] In one implementation, two additional RNTIs for OCC, e.g. OCC-RNTI1 and OCC-RNTI2, can be configured to represent OCC length 2 and OCC length 4 respectively. The selection of RNTI determines whether OCC is applied, and the OCC length if applied. If the existing RNTI is used in the DCI, no OCC is applied. If OCC-RNTI1 is used in the DCI, OCC length 2 is applied. If OCC-RNTI2 is used in the DCI, OCC length 4 is applied. If OCC is indicated, additional 1 or 2 bits can be used to indicate the OCC index. ”
Thus, based upon the teachings of YIN it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the OCC feature suggested by the combined teachings of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) by, adopting YIN’s feature for indicating whether to monitor a downlink in association with supporting the OCC, through use of DCI and/or RNTI, to arrive the apparatus of claim 25, wherein resources for OCC support for a CG-SDT, a PUR, an RA-SDT, or an EDT are different than resources for non-OCC support for a CG-SDT, a PUR, an RA-SDT, or an EDT, in order to provide support for different uplink transmission configurations depending on whether OCC is supported or not.
In regards to claim 2, SHAH (US 20240407006 A1) is silent on the apparatus of claim 1, wherein the one or more processors are individually or collectively configured to cause the UE to monitor for downlink communications based at least in part on the OCC indication. However, with respect to the apparatus of claim 1, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN, are believed to suggest the apparatus for claim 1, for the same reasons provided with respect to claim 1 above. With regards to the remaining features of claim 2, the feature wherein the one or more processors are individually are collectively configured to cause the UE to monitor for downlink communication, SHAH and LIBERG are silent on said feature, however, similar features have been seen in other prior art involving communication using orthogonal cover codes (OCC). YIN teaches a feature where a UE is caused to monitor, interpret, downlink communication, downlink control information, based at least in part on the OCC indication, whether the OCC indication indicates support for OCC or not. See where, YIN (US 20260032675 A1) recites, the following, “Method 3: Dynamic Indication of OCC Method, OCC Multiplexing Factor and OCC Index. [0210] To provide maximum scheduling flexibility, all parameters can be scheduled by the DCI. Thus, at least 1 bit for OCC on/off, 1 bit for OCC length or OCC multiplexing factor, and 1 or 2 bits for the OCC index… Alternative 1: Define a Mapping Table for Different OCC Combination and Indicate the Index in the Table [0211] Including no OCC case, OCC with length 2 and 4, there are a total of 7 possible combinations, i.e.: [0212] no OCC. [0213] OCC 2x with OCC index 0 [0214] OCC 2x with OCC index 1 [0215] OCC 4x with OCC index 0 [0216] OCC 4x with OCC index 1 [0217] OCC 4x with OCC index 2 [0218] OCC 4x with OCC index 3… Alternative 2: Separate Bits for OCC on/Off, OCC Length and OCC Index [0224] In another alternative, some bits may be used for OCC on/off and OCC length parameter. And separate bits are allocated for OCC index if OCC is indicated.”
Thus, based upon the teachings of YIN it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the OCC feature suggested by the combined teachings of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) by, adopting YIN’s feature for indicating how to monitor a downlink in association with supporting the OCC, through use of DCI, to arrive at feature wherein the one or more processors are individually or collectively configured to cause the UE to monitor for downlink communications based at least in part on the OCC indication, to thus arrive at claim 2, in order to provide support for different uplink transmission configurations depending on whether OCC is supported or not.
In regards to claim 3, SHAH (US 20240407006 A1) is silent on the apparatus of claim 1, wherein to receive the OCC configuration, the one or more processors are individually or collectively configured to cause the UE to receive the OCC configuration in one or more radio resource control messages for CG-SDT and PUR. However, with respect to the apparatus of claim 1, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN, are believed to suggest the apparatus for claim 1, or the same reasons provided with respect to claim 1 above. With respect to the remaining features of claim 3, similar features have been seen in prior art involving using orthogonal cover codes for uplink transmission. SHAH for example teaches a feature to receive the OCC configuration, the one or more processors are individually or collectively configured to cause the UE to receive the OCC configuration in one or more radio resource control messages for NRPACH,
SHAH differs from the feature of claim 3, in that while SHAH teaches a feature for applying orthogonal cover codes (OCC) to uplink transmissions, specifically NPRACH preamble transmissions, SHAH is silent on applying OCC to uplink transmissions, such as a configured grant (CG) small data transmission (SDT) or a preconfigured uplink resource (PUR). Thus, SHAH is silent on a feature where to receive the OCC configuration, the one or more processors are individually or collectively configured to cause the UE to receive the OCC configuration in one or more radio resource control messages for CG-SDT and PUR. Despite these differences similar features have been seen in other prior art involving use of OCC for uplink transmissions.
LIBERG (WO 2025126156 A1) suggests applying OCC for a CG-SDT or a PUR ([0056] One example of the ‘EDT for loT NTN’ procedure is the following: • Step 400: The BS in SI configures periodic PUSCH resources with a fixed MCS and repetition-level per PUSCH resource (and number off OCC/cyclic DM-RS shifts, and other information). In other words, the BS configures multiple radio resource pools where, in this example, each radio resource pool includes a single periodic PUSCH resource with an associated fixed MCS and repetition-level. • Steps 402 and 404: The UE upon data transmission choses a PUSCH resource with the appropriate TBS, and MCS and repetition-level (e.g., based on RSRP-measurement) and randomly picks an orthogonal resource (OCC/cyclic DM-RS shifts, etc.). In other words, the UE selects a PUSCH resource (from among those configured) that has an appropriate TBS, MCS, and repetition level (e.g., based on RSRP measurement), randomly selects an orthogonal resource (e.g., OCC or cyclic DM-RS shift) from among those associated to the selected PUSCH resource, and transmits PUSCH on the selected PUSCH resource using the selected orthogonal code and the associated TBS, MCS, and repetition level…. [0057] This procedure is applicable in any network supporting the method, i.e. both terrestrial and non-terrestrial networks. I.e., even though the solution is discussed for EDT in use with loT NTN, it is equally applicable to EDT alone, common Preconfigured Uplink Resource (PUR) resources (if such a solution later introduced), or to for NR small data transmission (SDT) in combination with NR NTN, to RA-SDT alone, or to common Configured Grant (CG)-SDT resources (if such a solution is later introduced).).
Thus, based upon the teachings of LIBERG (WO 2025126156 A1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the OCC feature of SHAH (US 20240407006 A1), by also applying the OCC feature to CG-SDT or a PUR, as similarly seen in LIBERG to thus arrive the method of claim 1, wherein to receive the OCC configuration, the one or more processors are individually or collectively configured to cause the UE to receive the OCC configuration in one or more radio resource control messages for CG-SDT and PUR , in order to provide the benefits of OCC to uplink transmissions such as CG-SDT or PUR in addition to or in-lieu of NR-PRACH(s) transmissions.
In regards to claim 4, SHAH (US 20240407006 A1) is silent on the apparatus of claim 1, wherein the OCC configuration enables the UE to transmit uplink data during transmission of the CG-SDT using an OCC. However, with respect to the apparatus of claim 1, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN, are believed to suggest the apparatus for claim 1, or the same reasons provided with respect to claim 1 above. With respect to the remaining features of claim 4, similar features have been seen in prior art involving using orthogonal cover codes for uplink transmission. SHAH for example teaches a where the OCC configuration enables the UE to transmit the NRPRACH . (“[0144] At 1105, the UE 115-u may transmit a capability message indicating a capability of the UE 115-u to support NPRACH multiplexing. The capability of the UE 115-u for NPRACH multiplexing may be based on phase coherence capabilities associated with the UE 115-u, and the capability message may indicate a phase coherence capability of the UE 115-u. [0145] At 1110, the UE 115-u may receive a configuration message indicating a configuration of the NPRACH preamble. The network entity 105-c may receive the configuration message via RRC, MAC-CE, system information, or other signaling that may configure the UE 115-u with one or more preambles to transmit. The configuration message may include UE specific configuration information regarding an NPRACH orthogonal cover coding configuration to be used for transmitting the NPRACH preamble….”).
SHAH differs from the feature of claim 4, in that while SHAH teaches a feature for applying orthogonal cover codes (OCC) to uplink transmissions, specifically NPRACH preamble transmissions, SHAH is silent on applying OCC to uplink transmissions, such as a configured grant (CG) small data transmission (SDT) or a preconfigured uplink resource (PUR). Thus, SHAH is silent on wherein the OCC configuration enables the UE to transmit uplink data during transmission of the CG-SDT using the OCC. Despite these differences similar features have been seen in other prior art involving use of OCC for uplink transmissions.
LIBERG (WO 2025126156 A1) suggests applying OCC for a CG-SDT or a PUR ([0056] One example of the ‘EDT for loT NTN’ procedure is the following: • Step 400: The BS in SI configures periodic PUSCH resources with a fixed MCS and repetition-level per PUSCH resource (and number off OCC/cyclic DM-RS shifts, and other information). In other words, the BS configures multiple radio resource pools where, in this example, each radio resource pool includes a single periodic PUSCH resource with an associated fixed MCS and repetition-level. • Steps 402 and 404: The UE upon data transmission choses a PUSCH resource with the appropriate TBS, and MCS and repetition-level (e.g., based on RSRP-measurement) and randomly picks an orthogonal resource (OCC/cyclic DM-RS shifts, etc.). In other words, the UE selects a PUSCH resource (from among those configured) that has an appropriate TBS, MCS, and repetition level (e.g., based on RSRP measurement), randomly selects an orthogonal resource (e.g., OCC or cyclic DM-RS shift) from among those associated to the selected PUSCH resource, and transmits PUSCH on the selected PUSCH resource using the selected orthogonal code and the associated TBS, MCS, and repetition level…. [0057] This procedure is applicable in any network supporting the method, i.e. both terrestrial and non-terrestrial networks. I.e., even though the solution is discussed for EDT in use with loT NTN, it is equally applicable to EDT alone, common Preconfigured Uplink Resource (PUR) resources (if such a solution later introduced), or to for NR small data transmission (SDT) in combination with NR NTN, to RA-SDT alone, or to common Configured Grant (CG)-SDT resources (if such a solution is later introduced).).
Thus, based upon the teachings of LIBERG (WO 2025126156 A1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the OCC feature of SHAH (US 20240407006 A1), by also applying the OCC feature to CG-SDT or a PUR, as similarly seen in LIBERG to thus arrive the apparatus of claim 1, wherein the OCC configuration enables the UE to transmit uplink data during transmission of the CG-SDT using an OCC , in order to provide the benefits of OCC to uplink transmissions such as CG-SDT or PUR in addition to or in-lieu of NR-PRACH(s) transmissions.
In regards to claim 5, SHAH (US 20240407006 A1) is silent on the apparatus of claim 1, wherein the OCC configuration enables the UE to transmit uplink data during transmission of the PUR using an OCC. However, with respect to the apparatus of claim 1, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN, are believed to suggest the apparatus for claim 1, or the same reasons provided with respect to claim 1 above. With respect to the remaining features of claim 5, similar features have been seen in prior art involving using orthogonal cover codes for uplink transmission. SHAH for example teaches a where the OCC configuration enables the UE to transmit the NRPRACH . (“[0144] At 1105, the UE 115-u may transmit a capability message indicating a capability of the UE 115-u to support NPRACH multiplexing. The capability of the UE 115-u for NPRACH multiplexing may be based on phase coherence capabilities associated with the UE 115-u, and the capability message may indicate a phase coherence capability of the UE 115-u. [0145] At 1110, the UE 115-u may receive a configuration message indicating a configuration of the NPRACH preamble. The network entity 105-c may receive the configuration message via RRC, MAC-CE, system information, or other signaling that may configure the UE 115-u with one or more preambles to transmit. The configuration message may include UE specific configuration information regarding an NPRACH orthogonal cover coding configuration to be used for transmitting the NPRACH preamble….”).
SHAH differs from the feature of claim 5, in that while SHAH teaches a feature for applying orthogonal cover codes (OCC) to uplink transmissions, specifically NPRACH preamble transmissions, SHAH is silent on applying OCC to uplink transmissions, such as a configured grant (CG) small data transmission (SDT) or a preconfigured uplink resource (PUR). Thus, SHAH is silent on wherein the OCC configuration enables the UE to transmit uplink data during transmission of the PUR using the OCC. Despite these differences similar features have been seen in other prior art involving use of OCC for uplink transmissions.
LIBERG (WO 2025126156 A1) suggests applying OCC for a CG-SDT or a PUR ([0056] One example of the ‘EDT for loT NTN’ procedure is the following: • Step 400: The BS in SI configures periodic PUSCH resources with a fixed MCS and repetition-level per PUSCH resource (and number off OCC/cyclic DM-RS shifts, and other information). In other words, the BS configures multiple radio resource pools where, in this example, each radio resource pool includes a single periodic PUSCH resource with an associated fixed MCS and repetition-level. • Steps 402 and 404: The UE upon data transmission choses a PUSCH resource with the appropriate TBS, and MCS and repetition-level (e.g., based on RSRP-measurement) and randomly picks an orthogonal resource (OCC/cyclic DM-RS shifts, etc.). In other words, the UE selects a PUSCH resource (from among those configured) that has an appropriate TBS, MCS, and repetition level (e.g., based on RSRP measurement), randomly selects an orthogonal resource (e.g., OCC or cyclic DM-RS shift) from among those associated to the selected PUSCH resource, and transmits PUSCH on the selected PUSCH resource using the selected orthogonal code and the associated TBS, MCS, and repetition level…. [0057] This procedure is applicable in any network supporting the method, i.e. both terrestrial and non-terrestrial networks. I.e., even though the solution is discussed for EDT in use with loT NTN, it is equally applicable to EDT alone, common Preconfigured Uplink Resource (PUR) resources (if such a solution later introduced), or to for NR small data transmission (SDT) in combination with NR NTN, to RA-SDT alone, or to common Configured Grant (CG)-SDT resources (if such a solution is later introduced).).
Thus, based upon the teachings of LIBERG (WO 2025126156 A1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the OCC feature of SHAH (US 20240407006 A1), by also applying the OCC feature to CG-SDT or a PUR, as similarly seen in LIBERG to thus arrive the apparatus of claim 1, wherein the OCC configuration enables the UE to transmit uplink data during transmission of the PUR using an OCC , in order to provide the benefits of OCC to uplink transmissions such as CG-SDT or PUR in addition to or in-lieu of NR-PRACH(s) transmissions.
In regards to claim 6, SHAH (US 20240407006 A1) is silent on the apparatus of claim 1, wherein the one or more processors are individually or collectively configured to cause the UE to identify values in downlink control information (DCI) according to a first manner if OCC is supported and identify values in the DCI according to a second manner if OCC is not supported. However, with respect to the apparatus of claim 1, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN, are believed to suggest the apparatus for claim 1, or the same reasons provided with respect to claim 1 above. With respect to the remaining features of claim 6, similar features have been seen in prior art involving using orthogonal cover codes for uplink transmission.
YIN (US 20260032675 A1) teaches where for multiplexed OCC transmissions, an indication is received in downlink control information (DCI) that indicates how to monitor (i.e. interpret) a downlink in association with supporting OCC, where depending on whether or not OCC supported, bits monitored/interpreted differently (i.e. understood as either having information indicating an OCC level/multiplexing level and OCC code, or not having that information). See where, YIN (US 20260032675 A1) recites, the following, “Method 3: Dynamic Indication of OCC Method, OCC Multiplexing Factor and OCC Index. [0210] To provide maximum scheduling flexibility, all parameters can be scheduled by the DCI. Thus, at least 1 bit for OCC on/off, 1 bit for OCC length or OCC multiplexing factor, and 1 or 2 bits for the OCC index… Alternative 1: Define a Mapping Table for Different OCC Combination and Indicate the Index in the Table [0211] Including no OCC case, OCC with length 2 and 4, there are a total of 7 possible combinations, i.e.: [0212] no OCC. [0213] OCC 2x with OCC index 0 [0214] OCC 2x with OCC index 1 [0215] OCC 4x with OCC index 0 [0216] OCC 4x with OCC index 1 [0217] OCC 4x with OCC index 2 [0218] OCC 4x with OCC index 3… Alternative 2: Separate Bits for OCC on/Off, OCC Length and OCC Index
[0224] In another alternative, some bits may be used for OCC on/off and OCC length parameter. And separate bits are allocated for OCC index if OCC is indicated.”
Thus, based upon the teachings of YIN it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the OCC feature suggested by the combined teachings of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) by, adopting YIN’s feature for indicating how to monitor a downlink in association with supporting the OCC, through use of DCI, to arrive at the apparatus of claim 1, wherein the one or more processors are individually or collectively configured to cause the UE to identify values in downlink control information (DCI) according to a first manner if OCC is supported and identify values in the DCI according to a second manner if OCC is not supported, in order to provide support for different uplink transmission configurations depending on whether OCC is supported or not.
In regards to claim 7, SHAH (US 20240407006 A1) is silent on the apparatus of claim 1, wherein downlink control information (DCI) for an OCC-supported UE is different than DCI for a non-OCC-supported UE. However, with respect to the apparatus of claim 1, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN, are believed to suggest the apparatus for claim 1, or the same reasons provided with respect to claim 1 above. With respect to the remaining features of claim 7, similar features have been seen in prior art involving using orthogonal cover codes for uplink transmission.
YIN (US 20260032675 A1) teaches where for multiplexed OCC transmissions, an indication is received in downlink control information (DCI) that indicates how to monitor (i.e. interpret) a downlink in association with supporting OCC, where depending on whether or not a UE, supports OCC, bits are monitored/interpreted differently (i.e. understood as either having information indicating an OCC level/multiplexing level and OCC code, or not having that information). See where, YIN (US 20260032675 A1) recites, the following, “[0198] In this method, an IoT NTN device is configured with either NPUSCH with OCC or NPUSCH without OCC by higher layer signaling. Dynamic switching between OCC and non-OCC is not supported. The higher layer signaling can be a RRC configuration. The higher layer signaling can be a combination of RRC configuration and MAC CE. For example, one or more configurations are included in a RRC signaling, and a MAC CE is used to indicate which parameter or set of parameters are applied…Method 3: Dynamic Indication of OCC Method, OCC Multiplexing Factor and OCC Index. [0210] To provide maximum scheduling flexibility, all parameters can be scheduled by the DCI. Thus, at least 1 bit for OCC on/off, 1 bit for OCC length or OCC multiplexing factor, and 1 or 2 bits for the OCC index… Alternative 1: Define a Mapping Table for Different OCC Combination and Indicate the Index in the Table [0211] Including no OCC case, OCC with length 2 and 4, there are a total of 7 possible combinations, i.e.: [0212] no OCC. [0213] OCC 2x with OCC index 0 [0214] OCC 2x with OCC index 1 [0215] OCC 4x with OCC index 0 [0216] OCC 4x with OCC index 1 [0217] OCC 4x with OCC index 2 [0218] OCC 4x with OCC index 3… Alternative 2: Separate Bits for OCC on/Off, OCC Length and OCC Index
[0224] In another alternative, some bits may be used for OCC on/off and OCC length parameter. And separate bits are allocated for OCC index if OCC is indicated.”
Thus, based upon the teachings of YIN it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the OCC feature suggested by the combined teachings of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) by, adopting YIN’s feature for indicating how to monitor a downlink in association with supporting the OCC, through use of DCI, to arrive at the apparatus of claim 1, wherein downlink control information (DCI) for an OCC-supported UE is different than DCI for a non-OCC-supported UE, in order to provide support for different uplink transmission configurations depending on whether OCC is supported or not.
In regards to claim 9, SHAH (US 20240407006 A1) is silent on the apparatus of claim 1, wherein the one or more processors are individually or collectively configured to cause the UE to transmit uplink data based at least in part on the OCC configuration. However, with respect to the apparatus of claim 1, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN, are believed to suggest the apparatus for claim 1, or the same reasons provided with respect to claim 1 above. With respect to the remaining features of claim 9, similar features have been seen in prior art involving using orthogonal cover codes for uplink transmission. SHAH for example teaches where the UE is caused to transmit the NRPRACH (“[0144] At 1105, the UE 115-u may transmit a capability message indicating a capability of the UE 115-u to support NPRACH multiplexing. The capability of the UE 115-u for NPRACH multiplexing may be based on phase coherence capabilities associated with the UE 115-u, and the capability message may indicate a phase coherence capability of the UE 115-u. [0145] At 1110, the UE 115-u may receive a configuration message indicating a configuration of the NPRACH preamble. The network entity 105-c may receive the configuration message via RRC, MAC-CE, system information, or other signaling that may configure the UE 115-u with one or more preambles to transmit. The configuration message may include UE specific configuration information regarding an NPRACH orthogonal cover coding configuration to be used for transmitting the NPRACH preamble….”).
SHAH differs from the feature of claim 9, in that while SHAH teaches a feature for applying orthogonal cover codes (OCC) to uplink transmissions, specifically NPRACH preamble transmissions, SHAH is silent on applying OCC to uplink data transmissions, such as a configured grant (CG) small data transmission (SDT) or a preconfigured uplink resource (PUR). Thus, SHAH is silent wherein the one or more processors are individually or collectively configured to cause the UE to transmit uplink data based at least in part on the OCC configuration. Despite these differences similar features have been seen in other prior art involving use of OCC for uplink transmissions.
LIBERG (WO 2025126156 A1) suggests applying OCC for a CG-SDT or a PUR ([0056] One example of the ‘EDT for loT NTN’ procedure is the following: • Step 400: The BS in SI configures periodic PUSCH resources with a fixed MCS and repetition-level per PUSCH resource (and number off OCC/cyclic DM-RS shifts, and other information). In other words, the BS configures multiple radio resource pools where, in this example, each radio resource pool includes a single periodic PUSCH resource with an associated fixed MCS and repetition-level. • Steps 402 and 404: The UE upon data transmission choses a PUSCH resource with the appropriate TBS, and MCS and repetition-level (e.g., based on RSRP-measurement) and randomly picks an orthogonal resource (OCC/cyclic DM-RS shifts, etc.). In other words, the UE selects a PUSCH resource (from among those configured) that has an appropriate TBS, MCS, and repetition level (e.g., based on RSRP measurement), randomly selects an orthogonal resource (e.g., OCC or cyclic DM-RS shift) from among those associated to the selected PUSCH resource, and transmits PUSCH on the selected PUSCH resource using the selected orthogonal code and the associated TBS, MCS, and repetition level…. [0057] This procedure is applicable in any network supporting the method, i.e. both terrestrial and non-terrestrial networks. I.e., even though the solution is discussed for EDT in use with loT NTN, it is equally applicable to EDT alone, common Preconfigured Uplink Resource (PUR) resources (if such a solution later introduced), or to for NR small data transmission (SDT) in combination with NR NTN, to RA-SDT alone, or to common Configured Grant (CG)-SDT resources (if such a solution is later introduced).).
Thus, based upon the teachings of LIBERG (WO 2025126156 A1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the OCC feature of SHAH (US 20240407006 A1), by also applying the OCC feature to CG-SDT or a PUR, as similarly seen in LIBERG to thus arrive the apparatus of claim 1, wherein the one or more processors are individually or collectively configured to cause the UE to transmit uplink data (i.e. CG-SDT or PUR) based at least in part on the OCC configuration, in order to provide the benefits of OCC to uplink transmissions such as CG-SDT or PUR in addition to or in-lieu of NR-PRACH(s) transmissions.
In regards to claim 10, SHAH (US 20240407006 A1) is silent on the apparatus of claim 1, wherein the one or more processors are individually or collectively configured to cause the UE to receive an updated OCC configuration that: changes one or more of the multiplexing order, the OCC codeword for the multiplexing order, or the OCC indication, disables use of an OCC for a CG-SDT or a PUR, or enables one or more of a new multiplexing order, a new OCC codeword for the new multiplexing order, or a new OCC indication for a next CG-SDT or a next PUR. However, with respect to the apparatus of claim 1, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN, is believed to suggest the apparatus for claim 1, or the same reasons provided with respect to claim 1 above. Regarding the remaining features of claim 10, while SHAH and LIBERG are believed to suggest the applying OCC for a CG-SDT or a PUR, for the same reasons provided with respect to claim 1, SHAH in view of LIBERG are silent on silent on wherein the one or more processors are individually or collectively configured to cause the UE to receive an updated OCC configuration that: changes one or more of the multiplexing order, the OCC codeword for the multiplexing order, or the OCC indication, disables use of an OCC for the CG-SDT or the PUR, or enables one or more of a new multiplexing order, a new OCC codeword for the new multiplexing order, or a new OCC indication for a next CG-SDT or a next PUR. Despite these differences similar features have been seen in other prior art of record involving the use of orthogonal cover codes (OCC) for communication.
YIN for example suggests a feature for dynamically indicating an OCC codeword (i.e. OCC index), through use of downlink control information (DCI), enabling the update of the OCC codeword through use of the DCI (“[0162] In this method, an IoT NTN device is configured with either NPUSCH with OCC or NPUSCH without OCC. Dynamic switching between OCC and non-OCC is not supported. [0163] If OCC is configured by higher layer signaling, the OCC multiplexing factor or OCC length or OCC capacity should be further configured by higher layer signaling, i.e. RRC signaling. The OCC multiplexing factor may be configured as 2 or 4 at least. Higher multiplexing factor, e.g. 8, may be supported. In this method, the OCC length cannot be dynamically changed either. The higher layer signaling can be a RRC configuration. The higher layer signaling can be a combination of RRC configuration and MAC CE. For example, one or more configurations are included in a RRC signaling, and a MAC CE is used to indicate which parameter or set of parameters are applied. [0164] With configured OCC multiplexing factor or OCC length, the OCC index may be dynamically indicated by the eNB to the NTN-IoT device in the scheduling DCI. If OCC multiplexing factor of 2 is configured, 1 bit is needed to indicate the OCC index 0 or 1. If OCC multiplexing factor of 4 is configured, 2 bits are needed to indicate the OCC index. [0165] The indication can be performed by the NPUSCH scheduling DCI, i.e. DCI format N0. Due to limited IoT capability, the DCI total number of bits, i.e. 23 bits in DCI format N0 should not be changed. Therefore, some approaches may be defined to provide the required 1 or 2 bits for DCI format N0, as discussed in detail below.”).
YIN also suggests a feature for dynamically indicating an OCC feature (whether OCC is ON or OFF) and OCC codeword (i.e. OCC index), through use of downlink control information (DCI), enabling the updating of the OCC, or rather the turning on or off the OCC feature, and adjustment of the OCC codeword through use of the DCI (“[0192] Alternatively or additionally, the OCC method and OCC multiplexing factor can be semi-statically configured, but whether OCC is applied is dynamically indicated by the DCI. If OCC is applied, OCC index is also dynamically indicated by the DCI. This is similar to semi-persistent configurations, the OCC on/off is similar to an activation/deactivation process for a semi-persistent configuration.”).
YIN further suggests a feature for dynamically indicating an ON/OFF status of an OCC feature, an OCC codeword (i.e. OCC index), and OCC multiplexing factor through use of downlink control information (DCI). Thus, enabling the updating of the ON/OFF status of the OCC feature, a selected OCC codeword, and selected the OCC multiplexing factor through use of the DCI (“Method 3: Dynamic Indication of OCC Method, OCC Multiplexing Factor and OCC Index. [0210] To provide maximum scheduling flexibility, all parameters can be scheduled by the DCI. Thus, at least 1 bit for OCC on/off, 1 bit for OCC length or OCC multiplexing factor, and 1 or 2 bits for the OCC index.”).
Thus, based upon the teachings of YIN, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1), by dynamically indicating features such as a OCC ON/OFF feature, OCC codeword, and/or OCC multiplexing factor through the use of DCI, to thus arrive at the apparatus of claim 1, wherein the one or more processors are individually or collectively configured to cause the UE to receive an updated OCC configuration that: changes one or more of the multiplexing order, the OCC codeword for the multiplexing order, or the OCC indication, disables use of an OCC for a CG-SDT or a PUR, or enables one or more of a new multiplexing order, a new OCC codeword for the new multiplexing order, or a new OCC indication for a next CG-SDT or a next PUR, in order to provide support for different uplink transmission configurations depending on whether OCC is supported or not.
In regards to claim 30, SHAH (US 20240407006 A1) is silent on the apparatus of claim 25, wherein the one or more processors are individually or collectively configured to cause the network entity to transmit an updated OCC configuration that: changes one or more of the multiplexing order, the OCC codeword for the multiplexing order, and the OCC indication, disables use of an OCC for a CG-SDT, a PUR, an RA-SDT, or an EDT, or enables one or more of a new multiplexing order, a new OCC codeword for the new multiplexing order, or a new OCC indication for a next CG-SDT, a next PUR, a next RA-SDT, or a next EDT. However, with respect to the apparatus of claim 25, the combination of SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1), is believed to suggest the apparatus for claim 25, or the same reasons provided with respect to claim 25 above. Regarding the remaining features of claim 30, while SHAH and LIBERG are believed to suggest the applying OCC for a CG-SDT, PUR, RA-SDT, and/or EDT for the same reasons provided with respect to claim 25, However, SHAH in view of LIBERG are silent on silent on wherein the one or more processors are individually or collectively configured to cause the UE to receive an updated OCC configuration that: changes one or more of the multiplexing order, the OCC codeword for the multiplexing order, or the OCC indication, disables use of an OCC for the CG-SDT or the PUR, or enables one or more of a new multiplexing order, a new OCC codeword for the new multiplexing order, or a new OCC indication for a next CG-SDT or a next PUR. Despite these differences similar features have been seen in other prior art of record involving the use of orthogonal cover codes (OCC) for communication.
YIN for example suggests a feature for dynamically indicating an OCC codeword (i.e. OCC index), through use of downlink control information (DCI), enabling the update of the OCC codeword through use of the DCI (“[0162] In this method, an IoT NTN device is configured with either NPUSCH with OCC or NPUSCH without OCC. Dynamic switching between OCC and non-OCC is not supported. [0163] If OCC is configured by higher layer signaling, the OCC multiplexing factor or OCC length or OCC capacity should be further configured by higher layer signaling, i.e. RRC signaling. The OCC multiplexing factor may be configured as 2 or 4 at least. Higher multiplexing factor, e.g. 8, may be supported. In this method, the OCC length cannot be dynamically changed either. The higher layer signaling can be a RRC configuration. The higher layer signaling can be a combination of RRC configuration and MAC CE. For example, one or more configurations are included in a RRC signaling, and a MAC CE is used to indicate which parameter or set of parameters are applied. [0164] With configured OCC multiplexing factor or OCC length, the OCC index may be dynamically indicated by the eNB to the NTN-IoT device in the scheduling DCI. If OCC multiplexing factor of 2 is configured, 1 bit is needed to indicate the OCC index 0 or 1. If OCC multiplexing factor of 4 is configured, 2 bits are needed to indicate the OCC index. [0165] The indication can be performed by the NPUSCH scheduling DCI, i.e. DCI format N0. Due to limited IoT capability, the DCI total number of bits, i.e. 23 bits in DCI format N0 should not be changed. Therefore, some approaches may be defined to provide the required 1 or 2 bits for DCI format N0, as discussed in detail below.”).
YIN also suggests a feature for dynamically indicating an OCC feature (whether OCC is ON or OFF) and OCC codeword (i.e. OCC index), through use of downlink control information (DCI), enabling the updating of the OCC, or rather the turning on or off the OCC feature, and adjustment of the OCC codeword through use of the DCI (“[0192] Alternatively or additionally, the OCC method and OCC multiplexing factor can be semi-statically configured, but whether OCC is applied is dynamically indicated by the DCI. If OCC is applied, OCC index is also dynamically indicated by the DCI. This is similar to semi-persistent configurations, the OCC on/off is similar to an activation/deactivation process for a semi-persistent configuration.”).
YIN further suggests a feature for dynamically indicating an ON/OFF status of an OCC feature, an OCC codeword (i.e. OCC index), and OCC multiplexing factor through use of downlink control information (DCI). Thus, enabling the updating of the ON/OFF status of the OCC feature, a selected OCC codeword, and selected the OCC multiplexing factor through use of the DCI (“Method 3: Dynamic Indication of OCC Method, OCC Multiplexing Factor and OCC Index. [0210] To provide maximum scheduling flexibility, all parameters can be scheduled by the DCI. Thus, at least 1 bit for OCC on/off, 1 bit for OCC length or OCC multiplexing factor, and 1 or 2 bits for the OCC index.”).
Thus, based upon the teachings of YIN, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1), by dynamically indicating features such as a OCC ON/OFF feature, OCC codeword, and/or OCC multiplexing factor through the use of DCI, to thus arrive at the apparatus of claim 25, wherein the one or more processors are individually or collectively configured to cause the network entity to transmit an updated OCC configuration that: changes one or more of the multiplexing order, the OCC codeword for the multiplexing order, and the OCC indication, disables use of an OCC for a CG-SDT, a PUR, an RA-SDT, or an EDT, or enables one or more of a new multiplexing order, a new OCC codeword for the new multiplexing order, or a new OCC indication for a next CG-SDT, a next PUR, a next RA-SDT, or a next EDT, in order to provide support for different uplink transmission configurations depending on whether OCC is supported or not.
Allowable Subject Matter
Claim 8, is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim(s) 18 and 19 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Claim(s) 22 and 23 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Claim(s) 28 and 29 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TARELL A HAMPTON whose telephone number is (571)270-7162. The examiner can normally be reached 9:00 AM - 5:00 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, Ayaz Sheikh can be reached at 5712723795. 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.
/TARELL A HAMPTON/Examiner, Art Unit 2476 /AYAZ R SHEIKH/Supervisory Patent Examiner, Art Unit 2476
Prosecution Insights