DETAILED ACTION
Claim(s) 1-30 have been examined and are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Remarks
Status of Claims as of Non-Final Rejection mailed April 29, 2025:
Claim 3 was 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-19 were 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-23 were 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-30 were 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(s) 11, 12, 13, 14, 15, 20, and 21, were rejected under 35 U.S.C. 102(a)(1) as being anticipated by Rico Alvarino (US 20200252972 A1)
Claim(s) 16 and 17, were rejected under 35 U.S.C. 103 as being unpatentable over Rico Alvarino (US 20200252972 A1) in view of LIBERG (WO 2025126156 A1).
Claim(s) 24 was rejected under 35 U.S.C. 103 as being unpatentable over Rico Alvarino (US 20200252972 A1) in view of YIN (US 20260032675 A1).
Claim(s) 25 was rejected under 35 U.S.C. 103 as being unpatentable over SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1).
Claim(s) 1, 2, 3, 4, 5, 6, 7, 9, 10, 26, 27, and 30, were 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).
Claim 8, was 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 were objected to as being dependent upon a rejected base claim, but 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 were objected to as being dependent upon a rejected base claim, but 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 were objected to as being dependent upon a rejected base claim, but 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.
Applicants’ response to the Non-Final Rejection
Claim 3 has been amended in order to overcome the rejection of the claim 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. This amendment is effective. Accordingly, the rejection of claim 3 under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, is withdrawn.
Claim(s) 17 and 18 were amended in order to overcome the rejection(s) of claim 17-19 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. The amendments are effective. Accordingly, the rejections of claim 17-19 under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, are withdrawn.
Claim(s) 21 and 22 were amended in order to overcome the rejections of claim 21-23 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. The amendments are effective. Accordingly, the rejections of claim 21-23 under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, are withdrawn.
Claim(s) 25 was amended to overcome the rejections of claim 25-30 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. The amendments are effective. Accordingly, the rejections of claim 25-30 under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, are withdrawn.
• Claim 11 (See claims received July 8, 2026, where it at least recites, “…while the UE is in a radio resource control (RRC) inactive state…”) has been amended to address the rejection of claim(s) 11, 12, 13, 14, 15, 20, and 21, under 35 U.S.C. 102(a)(1) as being anticipated by Rico Alvarino (US 20200252972 A1). Arguments have also been presented in light of the amendments to claim 11. Accordingly, the rejections of 11, 12, 13, 14, 15, 20, and 21, under 35 U.S.C. 102(a)(1) as being anticipated by Rico Alvarino (US 20200252972 A1) are withdrawn. However, a new ground of rejection has been made in view of DAI (USPUB No. 2024/0365423).
The amendments to and arguments for claim 11, were also intended to address the rejection(s) of claim(s) 16 and 17, under 35 U.S.C. 103 as being unpatentable over Rico Alvarino (US 20200252972 A1) in view of LIBERG (WO 2025126156 A1). Accordingly, the rejections of Claim(s) 16 and 17, under 35 U.S.C. 103 as being unpatentable over Rico Alvarino (US 20200252972 A1) are withdrawn. However, a new ground of rejection has been made in view of DAI (USPUB No. 2024/0365423).
The amendments to and arguments for claim 11, were also intended to address the rejection(s) of claim(s) 24 under 35 U.S.C. 103 as being unpatentable over Rico Alvarino (US 20200252972 A1) in view of YIN (US 20260032675 A1). Accordingly, the rejection of claim(s) 24 under 35 U.S.C. 103 as being unpatentable over Rico Alvarino (US 20200252972 A1) in view of YIN (US 20260032675 A1) is withdrawn. However, a new ground of rejection has been made in view of DAI (USPUB No. 2024/0365423).
Applicants have argued that the prior art reference, SHAH (US 20240407006 A1), does not qualify as prior art according the 35 U.S.C. Section 102(b)(2)(C) exclusion, in order to overcome the rejection of claim(s) 25 under 35 U.S.C. 103 as being unpatentable over SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1). This argument is persuasive. Accordingly, the rejection of claim(s) 25 under 35 U.S.C. 103 as being unpatentable over SHAH (US 20240407006 A1) in view of LIBERG (WO 2025126156 A1) is withdrawn. However, a new ground of rejection has been made in view of AZARI (US 20250266945 A1).
Applicants have argued that the prior art reference, SHAH (US 20240407006 A1), does not qualify as prior art according the 35 U.S.C. Section 102(b)(2)(C) exclusion, in order to overcome the rejections of claim(s) 1, 2, 3, 4, 5, 6, 7, 9, 10, 26, 27, and 30, 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). This argument is persuasive. Accordingly, the rejections of claim(s) the rejection of claim(s) 1, 2, 3, 4, 5, 6, 7, 9, 10, 26, 27, and 30, 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) are withdrawn. However, a new ground of rejection has been made in view of AZARI (US 20250266945 A1).
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 11, 12, 13, 14, 15, 16, 17, 20, and 21, is/are rejected under 35 U.S.C. 103 as being unpatentable over Rico Alvarino (US 20200252972 A1) in view of DAI (USPUB No. 2024/0365423).
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, (“[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)”).
Note that while Rico Alvarino (US 20200252972 A1) teaches a feature to transmit a preamble associated with orthogonal cover code support for transmission of an early data transmission (EDT), RICO differs from that of claim 11, in that RICO ALVARINO is silent on a feature to transmit, while the UE is in radio resource control (RRC) inactive state, the 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, or an RA-SDT with a 2-step RACH procedure. Despite these differences similar features have been seen in other prior art concerning features similar to that of early data transmission (EDT).
DAI (USPUB No. 2024/0365423) suggests adapting use of early data transmission (EDT) feature into a RA-SDT procedure for 5G New Radio, the RA-SDT procedure being performed while a UE is in an RRC inactive state (“[0059] The EDT procedure evolves into an SDT procedure in NR. According to a NR Rel-17 work item, there are two SDT schemes (or SDT types) for UE in RRC_INACTIVE state, i.e., RA-SDT and CG-SDT. In RAN2 #113e, it was agreed that UE may fall back to RA-SDT from CG-SDT. For example, in response to the arrival of data only for DRB(s) and/or signaling radio bearer (SRB) (s) for which SDT is enabled, a high level procedure for selection between SDT and non-SDT is as follows: if the criteria for CG-SDT is met, then UE selects CG-SDT and initiates a CG-SDT procedure; else, if the criteria for RA-SDT is met, then UE selects RA-SDT and initiates a RA-SDT procedure; and else, UE initiates a non-SDT procedure.”). DAI further teaches where with respect to the RA-SDT procedures, there is a choice between at least a 2-step RA-SDT procedure and a 4-step RA-SDT procedure (“[0075] The UE may perform an SDT scheme selection procedure as follows: if a CG-SDT criteria is met, the UE will select the CG-SDT and will initiate a CG-SDT procedure; and else, if a RA-SDT criteria is met, the UE will select the RA-SDT and will initiate a RA-SDT procedure. If the RA-SDT criteria is not met either, the UE will initiate a non-SDT procedure. Wherein the CG-SDT criteria will be considered met, if all of the following conditions are met: 1) an available data volume is not larger than a data volume threshold; 2) reference signal received power (RSRP) is greater than or equal to a configured threshold; and 3) CG-SDT resources are configured on the selected UL carrier and are valid. In addition, the RA-SDT criteria will be considered met, if all of the following conditions are met: 1) an available data volume is not larger than a data volume threshold; 2) RSRP is greater than or equal to a configured threshold; and 3) 4 step RA-SDT resources are configured on the selected UL carrier and the criteria for selecting 4 step RA-SDT is met; or 2 step RA-SDT resources are configured on the selected UL carrier and the criteria for selecting 2 step RA-SDT is met.”).
Thus based upon the teachings of DAI 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 RICO ALVARINO’s feature to transmit a preamble with OCC support for an early data transmission (EDT), by transmitting, while the UE is in a RRC inactive state, the preamble with OCC support for a RA-SDT with a 4-step RACH procedure and/or RA-SDT with a step RACH procedure as similarly suggested by DAI, to thus arrive at claim 11, in order take advantage of the benefits of 5G NR, small data transmissions (SDT).
In regards to claim 12, Rico Alvarino (US 20200252972 A1) in view of DAI (USPUB No. 2024/0365423) suggest 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 (See RICO ALVARINO where, “[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) in view of DAI (USPUB No. 2024/0365423) suggest 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 (See RICO ALVARINO where “[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) in view of DAI (USPUB No. 2024/0365423) suggest the apparatus of claim 11, wherein the preamble or a RACH occasion (RO) is from a resource pool associated with OCC support for UEs (see RICO ALVARINO where “[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) in view of DAI (USPUB No. 2024/0365423) suggest 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 ( See RICO ALVARINO where “[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) in view of DAI (USPUB No. 2024/0365423) suggest the apparatus of claim 11, wherein the OCC configuration enables the UE to transmit uplink data during transmission of an EDT using an OCC (See RICO ALVARINO where “[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) in view of DAI (USPUB No. 2024/0365423) suggest 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)”. ).
In regards to claim 16, Rico Alvarino (US 20200252972 A1) in view of DAI (USPUB No. 2024/0365423) suggest 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.
Rico Alvarino (US 20200252972 A1) differs from claim 16, in that while Rico Alvarino (US 20200252972 A1) teaches a feature for applying orthogonal cover codes (OCC) to early data transmissions, wherein the OCC configuration enables the UE to transmit uplink data during 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).”), RICO ALVARINO is silent on applying OCC to uplink transmissions, such as a RA-SDT. Thus, RICO ALVARINO 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 concerning features similar to that of early data transmission (EDT).
DAI (USPUB No. 2024/0365423) suggests adapting use of early data transmission (EDT) feature into a RA-SDT procedure for 5G New Radio, the RA-SDT procedure being performed while a UE is in an RRC inactive state (“[0059] The EDT procedure evolves into an SDT procedure in NR. According to a NR Rel-17 work item, there are two SDT schemes (or SDT types) for UE in RRC_INACTIVE state, i.e., RA-SDT and CG-SDT. In RAN2 #113e, it was agreed that UE may fall back to RA-SDT from CG-SDT. For example, in response to the arrival of data only for DRB(s) and/or signaling radio bearer (SRB) (s) for which SDT is enabled, a high level procedure for selection between SDT and non-SDT is as follows: if the criteria for CG-SDT is met, then UE selects CG-SDT and initiates a CG-SDT procedure; else, if the criteria for RA-SDT is met, then UE selects RA-SDT and initiates a RA-SDT procedure; and else, UE initiates a non-SDT procedure.”). DAI further teaches where with respect to the RA-SDT procedures, there is a choice between at least a 2-step RA-SDT procedure and a 4-step RA-SDT procedure (“[0075] The UE may perform an SDT scheme selection procedure as follows: if a CG-SDT criteria is met, the UE will select the CG-SDT and will initiate a CG-SDT procedure; and else, if a RA-SDT criteria is met, the UE will select the RA-SDT and will initiate a RA-SDT procedure. If the RA-SDT criteria is not met either, the UE will initiate a non-SDT procedure. Wherein the CG-SDT criteria will be considered met, if all of the following conditions are met: 1) an available data volume is not larger than a data volume threshold; 2) reference signal received power (RSRP) is greater than or equal to a configured threshold; and 3) CG-SDT resources are configured on the selected UL carrier and are valid. In addition, the RA-SDT criteria will be considered met, if all of the following conditions are met: 1) an available data volume is not larger than a data volume threshold; 2) RSRP is greater than or equal to a configured threshold; and 3) 4 step RA-SDT resources are configured on the selected UL carrier and the criteria for selecting 4 step RA-SDT is met; or 2 step RA-SDT resources are configured on the selected UL carrier and the criteria for selecting 2 step RA-SDT is met.”).
Thus based upon the teachings of DAI 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 RICO ALVARINO’s feature to transmit a preamble with OCC support for an early data transmission (EDT), by transmitting, while the UE is in a RRC inactive state, the preamble with OCC support for a RA-SDT with a 4-step RACH procedure and/or RA-SDT with a step RACH procedure as similarly suggested by DAI, to thus arrive at claim 16, in order take advantage of the benefits of 5G NR, small data transmissions (SDT).
In regards to claim 17, Rico Alvarino (US 20200252972 A1) in view of DAI (USPUB No. 2024/0365423) 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 DAI (USPUB No. 2024/0365423) in view of YIN (US 20260032675 A1).
In regards to claim 24, Rico Alvarino (US 20200252972 A1) in view of DAI are 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 an OCC indication, disables use of an OCC for an RA-SDT, 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. 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 the RA-SDT OCC feature suggested by Rico Alvarino (US 20200252972 A1) in view of DAI, 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 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, 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 AZARI (US 20250266945 A1) in view of LIBERG (WO 2025126156 A1).
In regards to claim 25, AZARI (US 20250266945 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 (“[0063] FIG. 5 is an example apparatus 500, which may be implemented in hardware, configured to implement the examples described herein. The apparatus 500 comprises at least one processor 502 (e.g. an FPGA and/or CPU), one or more memories 504 including computer program code 505, the computer program code 505 having instructions to carry out the methods described herein, wherein the at least one memory 504 and the computer program code 405 are configured to, with the at least one processor 402, cause the apparatus 400 to implement circuitry, a process, component, module, or function (implemented with control module 406) to implement the examples described herein. The memory 405 may be a non-transitory memory, a transitory memory, a volatile memory (e.g. RAM), or a non-volatile memory (e.g. ROM).”):
receive a capability indication associated with orthogonal cover code (OCC) support (“[0038] Described herein are methods for signaling and indication of both UE capability of support of OCC operation and configuration of a UE with OCC operation, including indication of the length of and the actual OCC code the UE should apply to PUSCH repetitions, and the position of the OCC with respect to repetitions.[0039] Described herein are signaling methods to apply OCC to UEs data in uplink (i.e. PUSCH). This signaling indicates whether or not a UE is to use OCC for its uplink data transmission as well as which OCC code has to be used of which length and where the OCC code is located. [0040] For this described herein are the following signaling methods: UE indication of supporting capability of OCC application to PUSCH transmissions, and gNB indication and configuration of a UE with OCC operation for PUSCH transmissions…[0092] Example 16. The apparatus of any of examples 1 to 15, further including: means for transmitting, to a network, an indication of a capability of the apparatus to use an orthogonal cover code… [0112] Example 36. The apparatus of any of examples 21 to 35, further including: means for receiving, from the user equipment, an indication of a capability of the user equipment to use an orthogonal cover code.”); and
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(AZARI teaches transmitting an OCC configuration that indicates a multiplexing order, length, and an OCC codeword, OCC code, “[0039] Described herein are signaling methods to apply OCC to UEs data in uplink (i.e. PUSCH). This signaling indicates whether or not a UE is to use OCC for its uplink data transmission as well as which OCC code has to be used of which length and where the OCC code is located. [0040] For this described herein are the following signaling methods: UE indication of supporting capability of OCC application to PUSCH transmissions, and gNB indication and configuration of a UE with OCC operation for PUSCH transmissions. [0041] Regarding UE indication of supporting capability of OCC application to PUSCH transmissions, in one embodiment, the capability of applying OCC is limited to PUSCH repetitions. In another embodiment, the capability of applying OCC applies to DFT-s-OFDM PUSCH transmissions.[0042] Regarding gNB indication and configuration of a UE with OCC operation for PUSCH transmissions, in one embodiment, UE is configured to use OCC and the length of the OCC to use via RRC (semi-static) signalling. In one alternative of this embodiment, UE is further RRC configured which OCC code to use among the code set with the configured length. In another alternative, which OCC code to use (among the code set with the configured length) is indicated to the UE dynamically via DCI-either via a new DCI field or via repurposing an existing DCI field. The DCI field can further indicate an offset that specifies the OCC elements (or code) position with respect to first repetition, or specifies which part of the OCC code to be used within the OCC code sequence. The code set with the configured length might either be pre-configured at the UE (from specifications) or be further RRC configured by gNB. The code set might be a set of Walsh-Hadamard sequences or a set of DFT sequences or another set of codes (binary or non-binary, where binary is considered as having two discrete states) that are providing inter-code orthogonality given that UE transmissions are synchronized. [0043] In another embodiment, UE is configured to use OCC and a set of lengths of the OCC to use via RRC (semi-static) signaling. In this case, the OCC to use (length and code) is dynamically indicated to the UE via DCI either via a new DCI field or via repurposing an existing DCI field. The DCI field can further indicate an offset that specifies the OCC elements (or code) position with respect to first repetition, or specifies which part of the OCC code to be used within the OCC code sequence. In an alternative to this dynamic indication, a UE may be provided a table with different lengths and code entries, and the UE is dynamically indicated the specific row and/or column indexes to use. Upon knowing the row and/or column indexes the UE knows the specific OCC code and length to use for UL transmissions..”).
AZARI differs from claim 25, in that while AZARI teaches a feature for applying orthogonal cover codes (OCC) to uplink/PUSCH transmissions, AZARI is silent on applying OCC to uplink/PUSCH transmissions, such as a configured grant (CG) small data transmission (SDT) or a preconfigured uplink resource (PUR). Thus, AZARI 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). 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 AZARI, 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),to thus arrive at claim 25, in order to provide the benefits of OCC to uplink transmissions such as CG-SDT or PUR in addition to or in-lieu of PUSCH(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 AZARI (US 20250266945 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN (US 20260032675 A1)
In regards to claim 1, AZARI (US 20250266945 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 (“[0063] FIG. 5 is an example apparatus 500, which may be implemented in hardware, configured to implement the examples described herein. The apparatus 500 comprises at least one processor 502 (e.g. an FPGA and/or CPU), one or more memories 504 including computer program code 505, the computer program code 505 having instructions to carry out the methods described herein, wherein the at least one memory 504 and the computer program code 405 are configured to, with the at least one processor 402, cause the apparatus 400 to implement circuitry, a process, component, module, or function (implemented with control module 406) to implement the examples described herein. The memory 405 may be a non-transitory memory, a transitory memory, a volatile memory (e.g. RAM), or a non-volatile memory (e.g. ROM).”):
transmit an indication of a capability for supporting an orthogonal cover code (OCC) (“[0038] Described herein are methods for signaling and indication of both UE capability of support of OCC operation and configuration of a UE with OCC operation, including indication of the length of and the actual OCC code the UE should apply to PUSCH repetitions, and the position of the OCC with respect to repetitions.[0039] Described herein are signaling methods to apply OCC to UEs data in uplink (i.e. PUSCH). This signaling indicates whether or not a UE is to use OCC for its uplink data transmission as well as which OCC code has to be used of which length and where the OCC code is located. [0040] For this described herein are the following signaling methods: UE indication of supporting capability of OCC application to PUSCH transmissions, and gNB indication and configuration of a UE with OCC operation for PUSCH transmissions…[0092] Example 16. The apparatus of any of examples 1 to 15, further including: means for transmitting, to a network, an indication of a capability of the apparatus to use an orthogonal cover code… [0112] Example 36. The apparatus of any of examples 21 to 35, further including: means for receiving, from the user equipment, an indication of a capability of the user equipment to use an orthogonal cover code.”); and
receive an OCC configuration that indicates a multiplexing order and an OCC codeword for the multiplexing order, and an (AZARI teaches receiving an OCC configuration that indicates a multiplexing order, length, and an OCC codeword, OCC code, “[0039] Described herein are signaling methods to apply OCC to UEs data in uplink (i.e. PUSCH). This signaling indicates whether or not a UE is to use OCC for its uplink data transmission as well as which OCC code has to be used of which length and where the OCC code is located. [0040] For this described herein are the following signaling methods: UE indication of supporting capability of OCC application to PUSCH transmissions, and gNB indication and configuration of a UE with OCC operation for PUSCH transmissions. [0041] Regarding UE indication of supporting capability of OCC application to PUSCH transmissions, in one embodiment, the capability of applying OCC is limited to PUSCH repetitions. In another embodiment, the capability of applying OCC applies to DFT-s-OFDM PUSCH transmissions.[0042] Regarding gNB indication and configuration of a UE with OCC operation for PUSCH transmissions, in one embodiment, UE is configured to use OCC and the length of the OCC to use via RRC (semi-static) signalling. In one alternative of this embodiment, UE is further RRC configured which OCC code to use among the code set with the configured length. In another alternative, which OCC code to use (among the code set with the configured length) is indicated to the UE dynamically via DCI-either via a new DCI field or via repurposing an existing DCI field. The DCI field can further indicate an offset that specifies the OCC elements (or code) position with respect to first repetition, or specifies which part of the OCC code to be used within the OCC code sequence. The code set with the configured length might either be pre-configured at the UE (from specifications) or be further RRC configured by gNB. The code set might be a set of Walsh-Hadamard sequences or a set of DFT sequences or another set of codes (binary or non-binary, where binary is considered as having two discrete states) that are providing inter-code orthogonality given that UE transmissions are synchronized. [0043] In another embodiment, UE is configured to use OCC and a set of lengths of the OCC to use via RRC (semi-static) signaling. In this case, the OCC to use (length and code) is dynamically indicated to the UE via DCI either via a new DCI field or via repurposing an existing DCI field. The DCI field can further indicate an offset that specifies the OCC elements (or code) position with respect to first repetition, or specifies which part of the OCC code to be used within the OCC code sequence. In an alternative to this dynamic indication, a UE may be provided a table with different lengths and code entries, and the UE is dynamically indicated the specific row and/or column indexes to use. Upon knowing the row and/or column indexes the UE knows the specific OCC code and length to use for UL transmissions..”).
AZARI differs from claim 1, in that while AZARI teaches a feature for applying orthogonal cover codes (OCC) to uplink/PUSCH transmissions, AZARI is silent on applying OCC to uplink/PUSCH transmissions, such as a configured grant (CG) small data transmission (SDT) or a preconfigured uplink resource (PUR). Thus, AZARI 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). AZARI 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 AZARI, 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 PUSCH(s) transmissions.
The combined teachings of AZARI 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 AZARI 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 AZARI (US 20250266945 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 AZARI (US 20250266945 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 AZARI (US 20250266945 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 AZARI (US 20250266945 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 AZARI (US 20250266945 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 AZARI (US 20250266945 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 AZARI (US 20250266945 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, AZARI (US 20250266945 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 AZARI (US 20250266945 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, AZARI (US 20250266945 A1) 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 AZARI (US 20250266945 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, AZARI (US 20250266945 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 AZARI (US 20250266945 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. AZARI (US 20250266945 A1) 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 uplink and/or PUSCH transmissions, Regarding gNB indication and configuration of a UE with OCC operation for PUSCH transmissions, in one embodiment, UE is configured to use OCC and the length of the OCC to use via RRC (semi-static) signalling. In one alternative of this embodiment, UE is further RRC configured which OCC code to use among the code set with the configured length. In another alternative, which OCC code to use (among the code set with the configured length) is indicated to the UE dynamically via DCI-either via a new DCI field or via repurposing an existing DCI field. The DCI field can further indicate an offset that specifies the OCC elements (or code) position with respect to first repetition, or specifies which part of the OCC code to be used within the OCC code sequence. The code set with the configured length might either be pre-configured at the UE (from specifications) or be further RRC configured by gNB. The code set might be a set of Walsh-Hadamard sequences or a set of DFT sequences or another set of codes (binary or non-binary, where binary is considered as having two discrete states) that are providing inter-code orthogonality given that UE transmissions are synchronized.”).
AZARI differs from the feature of claim 3, in that while AZARI teaches a feature for applying orthogonal cover codes (OCC) to uplink transmissions, such as PUSCH 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, AZARI 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 AZARI (US 20250266945 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 PUSCH transmissions.
In regards to claim 4, AZARI (US 20250266945 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 AZARI (US 20250266945 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. AZARI (US 20250266945 A1) for example teaches where the OCC configuration enables the UE to transmit a PUSCH . (“[0041] Regarding UE indication of supporting capability of OCC application to PUSCH transmissions, in one embodiment, the capability of applying OCC is limited to PUSCH repetitions. In another embodiment, the capability of applying OCC applies to DFT-s-OFDM PUSCH transmissions. [0042] Regarding gNB indication and configuration of a UE with OCC operation for PUSCH transmissions, in one embodiment, UE is configured to use OCC and the length of the OCC to use via RRC (semi-static) signalling. In one alternative of this embodiment, UE is further RRC configured which OCC code to use among the code set with the configured length. In another alternative, which OCC code to use (among the code set with the configured length) is indicated to the UE dynamically via DCI-either via a new DCI field or via repurposing an existing DCI field. The DCI field can further indicate an offset that specifies the OCC elements (or code) position with respect to first repetition, or specifies which part of the OCC code to be used within the OCC code sequence. The code set with the configured length might either be pre-configured at the UE (from specifications) or be further RRC configured by gNB. The code set might be a set of Walsh-Hadamard sequences or a set of DFT sequences or another set of codes (binary or non-binary, where binary is considered as having two discrete states) that are providing inter-code orthogonality given that UE transmissions are synchronized.”).
AZARI differs from the feature of claim 4, in that while AZARI teaches a feature for applying orthogonal cover codes (OCC) to uplink/PUSCH 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, AZARI 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 AZARI, 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 the PUSCH transmissions.
In regards to claim 5, AZARI (US 20250266945 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 AZARI (US 20250266945 A1) is silent on 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. AZARI for example teaches a where the OCC configuration enables the UE to transmit the PUSCH . (“[0041] Regarding UE indication of supporting capability of OCC application to PUSCH transmissions, in one embodiment, the capability of applying OCC is limited to PUSCH repetitions. In another embodiment, the capability of applying OCC applies to DFT-s-OFDM PUSCH transmissions. [0042] Regarding gNB indication and configuration of a UE with OCC operation for PUSCH transmissions, in one embodiment, UE is configured to use OCC and the length of the OCC to use via RRC (semi-static) signalling. In one alternative of this embodiment, UE is further RRC configured which OCC code to use among the code set with the configured length. In another alternative, which OCC code to use (among the code set with the configured length) is indicated to the UE dynamically via DCI-either via a new DCI field or via repurposing an existing DCI field. The DCI field can further indicate an offset that specifies the OCC elements (or code) position with respect to first repetition, or specifies which part of the OCC code to be used within the OCC code sequence. The code set with the configured length might either be pre-configured at the UE (from specifications) or be further RRC configured by gNB. The code set might be a set of Walsh-Hadamard sequences or a set of DFT sequences or another set of codes (binary or non-binary, where binary is considered as having two discrete states) that are providing inter-code orthogonality given that UE transmissions are synchronized.”).
AZARI differs from the feature of claim 5, in that while AZARI teaches a feature for applying orthogonal cover codes (OCC) to uplink/PUSCH transmissions, AZARI 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, AZARI 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 AZARI (US 20250266945 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, AZARI (US 20250266945 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 AZARI (US 20250266945 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 AZARI (US 20250266945 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, AZARI (US 20250266945 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 AZARI (US 20250266945 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 AZARI (US 20250266945 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, AZARI (US 20250266945 A1) in view of LIBERG (WO 2025126156 A1) in view of YIN suggest 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 (See AZARI where, “[0039] Described herein are signaling methods to apply OCC to UEs data in uplink (i.e. PUSCH). This signaling indicates whether or not a UE is to use OCC for its uplink data transmission as well as which OCC code has to be used of which length and where the OCC code is located.”).
In regards to claim 10, AZARI (US 20250266945 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 AZARI (US 20250266945 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 AZARI (US 20250266945 A1) 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, AZARI (US 20250266945 A1) 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 modifyAZARI (US 20250266945 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, AZARI (US 20250266945 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 AZARI (US 20250266945 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 AZARI (US 20250266945 A1) 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, AZARI (US 20250266945 A1) 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 AZARI (US 20250266945 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, 18, 19, 22, 23, 28, and 29 are 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.
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