DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 7-14 and 18-20 are rejected under 35 U.S.C. 102(a)(1) as being clearly anticipated by NTT Docomo, Summary EOM on 9.9.1 Coverage enhancement for NR NTN, April 17-26, 2023, R1-2304244, hereinafter NTT Docomo.
Regarding claim 1 NTT Docomo discloses: One or more processors configured for wireless communication by performing operations (2 UE implies processors within context of 3GPP standards) comprising: receiving configuration information specifying a repetition factor for a physical uplink control channel (PUCCH) for a hybrid automatic repeat request (HARQ-ACK) transmission associated with a random-access message;( 8.5 Working Assumption: One or more repetition factors may be configured via SIB. If only one repetition factor is configured via SIB and if the value is one of {[1], 2, 4, 8}… - Repetition factor(s) for PUCCH are configured by the network via SIB (System Information Block). 4.1.6 Agreement: candidate values of only one repetition factor configuration via SIB are {2, 4, 8}. - Specific allowed values when single factor configured; 4.1 Section title: PUCCH enhancements for Msg4 HARQ-ACK - The entire section addresses PUCCH carrying HARQ-ACK. 8.3 Agreement (RAN1#110bis-e): For PUCCH for Msg4 HARQ-ACK, Support PUCCH repetition. Further discuss the specification impact… - Confirms repetition is for PUCCH carrying HARQ-ACK feedback; 8.3 Agreement: For PUCCH for Msg4 HARQ-ACK, Support PUCCH repetition - Msg4 is the contention resolution message in 4-step random access. 8.4 Conclusion: RAN1 concluded that PUCCH for Msg4 HARQ-ACK should be enhanced to meet the coverage requirements - Confirms random-access context. 4.1.1 Proposal 1-1_v5: PUCCH transmission when dedicated PUCCH resource configuration is not provided - This is the state during/after initial random access before dedicated resources configured)
receiving information representing a reference signal receive power (RSRP) threshold for a PUCCH repetition for the HARQ-ACK transmission; (8.5 Working Assumption: A RSRP threshold can be configured via SIB at least when the number of repetitions is configured by SIB - RSRP threshold is configured by network via system information. 4.1.4 Proposal 1-4_v0: Support Alt B for RSRP threshold… Alt B: New RSRP threshold is introduced - A new NTN-specific RSRP threshold (separate from Msg3 threshold) is introduced for determining when UE should request/report PUCCH repetition capability)
encoding, based on the RSRP threshold and the configuration information specifying the repetition factor, a capability report indicating a PUCCH repetition number for the HARQ-ACK transmission (8.5 Working Assumption: If the RSRP threshold is not configured, or if the configured RSRP threshold is X, UE capable of PUCCH repetition for Msg4 HARQ-ACK reports the capability of PUCCH repetition for Msg4 HARQ-ACK - UE encodes and transmits capability report when RSRP threshold is disabled or set to maximum value. The capability report is conditioned on both the RSRP threshold configuration and the UE having the repetition capability; the framework distinguishes between (1) capability report (indicating UE supports the feature) and (2) repetition request (requesting repetition when RSRP below threshold). 4.1.2 Section title: Signaling for repetition request or capability report - These are treated as related but distinct concepts. The capability report appears to indicate capability (binary: capable/not capable) rather than a specific repetition number preference)
or a request for the PUCCH repetition number for the HARQ-ACK transmission; (8.5 Working Assumption: If the RSRP threshold is configured and the configured RSRP threshold is smaller than X, UE capable of PUCCH repetition for Msg4 HARQ-ACK transmits repetition request if measured RSRP is lower than a RSRP threshold - When UE measures RSRP below the configured threshold, it transmits a repetition request to the network, signaling that coverage enhancement repetition is needed)
receiving, based on the capability report or the request, an indicated PUCCH repetition number for the HARQ-ACK transmission; (8.5 Agreement (RAN1#112): Alt 1: Field in DCI scheduling the Msg4 PDSCH. Alt 1-1: One or two bits of the existing field… Alt 1-1d: DAI field - gNB dynamically indicates repetition factor using a field in the DCI that schedules the Msg4 PDSCH. 4.1.3 Agreement (after 2nd GTW): support Alt 1-1 for dynamic indication of repetition factor from gNB. Further discuss which field(s) to be used. - The network receives the UE’s capability/request and responds by indicating the actual repetition number to use via DCI signaling)
and preparing the HARQ-ACK transmission for repetition based on the indicated PUCCH repetition number. (8.3 Agreement: Support PUCCH repetition - UE implements repetition of PUCCH transmission. 4.1.5 Agreement (after 2nd GTW): apply frequency hopping mechanism in R15/16/17 defined for PUCCH transmission for Msg4 HARQ-ACK, in every slot - Specifies that UE prepares repeated PUCCH transmissions using intra-slot frequency hopping in each slot of the repetition, following legacy frequency hopping rules)
Regarding claim 2 NTT Docomo discloses: The one or more processors of claim 1, wherein the repetition factor for PUCCH for the HARQ-ACK transmission is one of 1, 2, 4, or 8. (8.4 Agreement (RAN1#110bis): Supported number of transmissions are 1, 2, 4, 8. - Explicit list of allowed repetition factor values. 4.1.6 Agreement: candidate values of only one repetition factor configuration via SIB are {2, 4, 8}. - When configuring a single factor, only {2,4,8} allowed; but when multiple factors configured, the set {1,2,4,8} is the full range. Value 1 means single transmission (no repetition))
Regarding claim 3 NTT Docomo discloses: The one or more processors of claim 1, the operations further comprising encoding for transmission a PUCCH repetition based on a different PUCCH repetition factor than the PUCCH repetition factor for the HARQ-ACK transmission. (4.1.1 Proposal 1-1_v3 and v5 FFS: how to indicate repetition factor for PUCCH transmission scheduled by DCI format 1_0 and with CRC scrambled by C-RNTI - Leaves open whether different repetition factors can be indicated for other PUCCH transmissions. 4.1.1 Note in Proposal 1-1_v2: The same configuration of PUCCH repetition provided via SIB is applied to any PUCCH transmission by using common PUCCH - Suggests same factor applies to all common PUCCH. 5.1 [21/QC] Proposal 4: The same repetition factor of the PUCCH for Msg4 HARQ-ACK applies to other PUCCH without additional signaling when dedicated PUCCH resource configuration is not provided)
Regarding claim 4 NTT Docomo discloses: The one or more processors of claim 1, wherein the RSRP threshold for PUCCH repetition for the HARQ-ACK transmission is different than a PUCCH repetition for a Msg4 HARQ-ACK transmission. (4.1.4 Proposal 1-4_v0: Support Alt B for RSRP threshold… Alt B: New RSRP threshold is introduced. Note: the same value between the new RSRP threshold and the RSRP threshold for R17 Msg3 repetition can be configured by gNB implementation. - A new RSRP threshold separate from the Msg3 PUSCH repetition threshold is introduced. 5.1 Contribution Summary (Alt B supporters): [21/QC]: Since the exact SNR level below which Msg4 HARQ-ACK repetition is required differs from that for Msg3 repetition, network should be allowed the flexibility to configure the RSRP threshold for Msg4 HARQ-ACK repetition independent of that for Msg3 repetition. [12/Ericsson]: The SNR limit for when repetitions are needed is different for Msg4 HARQ-ACK PUCCH and Msg3 PUSCH. [1/HW, HiSi]: PUCCH of Msg4 HARQ-ACK can have better link budget than Msg3. Analysis: The claim language different than a PUCCH repetition for a Msg4 HARQ-ACK transmission is ambiguous (comparing Msg4 to Msg4), but interpreted as different than [the RSRP threshold for] a Msg3 PUSCH repetition)
Regarding claim 7, NTT Docomo discloses: The one or more processors of claim 1, the operations further comprising: determining that a RSRP measurement is below the RSRP threshold and that a UE has a capability of PUCCH repetition; (8.5 Working Assumption: UE measures RSRP (e.g., on SSB) and compares to configured threshold; if RSRP < threshold, condition is satisfied; UEs with the capability can transmit the request. The condition UE capable of PUCCH repetition for Msg4 HARQ-ACK in the WA explicitly requires UE to have the capability before transmitting repetition request)
and encoding for transmission the request for the PUCCH repetition for the HARQ-ACK transmission. (8.5 Working Assumption: UE encodes and transmits the repetition request; 4.1.2 Working Assumption (after 1st GTW): The request is encoded in higher layer signaling (MAC layer) carried on Msg3 PUSCH)
Regarding claim 8, NTT Docomo discloses: The one or more processors of claim 1, wherein the RSRP threshold is not configured or is configured with a specific value, the operations further comprising:
transmitting the capability report on PUCCH repetition for the HARQ-ACK transmission. (8.5 Working Assumption: two scenarios: (1) RSRP threshold absent from SIB configuration, or (2) RSRP threshold present but set to a specific maximum value X (where X is the maximum configurable value, FFS but likely 127 or similar); UE transmits capability report (not a request) unconditionally (i.e., without RSRP measurement trigger). This allows network to know UE capability before deciding whether to enable repetition)
Regarding claim 9, NTT Docomo discloses: The one or more processors of claim 1, wherein the capability report or the request is transmitted using a physical uplink shared channel (PUSCH). (4.1.2 Working Assumption: For PUCCH repetition for Msg4 HARQ-ACK, support Option B as container of the repetition request or capability report indicated by UE. Option B: Higher layer signaling in Msg3 PUSCH - Msg3 is transmitted on PUSCH. 5.1 Contribution Summary: Option B The capability report or request is carried in higher layer signaling (MAC layer: LCID or reserved bits) within the Msg3 PUSCH transmission)
Regarding claim 10, NTT Docomo discloses: The one or more processors of claim 9, wherein a reserved bit in a medium access control (MAC) sub-header indicates the PUCCH repetition number or the request for the PUCCH repetition number. (4.1.2 Details under Option B: E.g., LCID codepoints, R bits in the MAC subheader listed as mechanisms. 5.1 [12/Ericsson]: R bit in the MAC subheader explicitly proposed for indicating repetition request/capability in Msg3 PUSCH. The MAC sub-header contains reserved ® bits that can be repurposed to carry 1-bit or 2-bit indication of PUCCH repetition number or the request for repetition)
Regarding claim 11, NTT Docomo discloses: The one or more processors of claim 9, wherein a logical cell identifier (LCID) code indicates the PUCCH repetition number or the request for the PUCCH repetition number. (4.1.2 Details under Option B: LCID codepoints listed as a mechanism. 5.1 Details: support LCID-based indication. [12/Ericsson]: If LCID codepoints are used to request Msg4 HARQ-ACK PUCCH repetitions, four of the seven reserved LCID codepoints would be needed… - Using LCID values to encode both CCCH size, RedCap capability, and PUCCH repetition capability/request)
Regarding claim 12, NTT Docomo discloses: The one or more processors of claim 1, wherein the capability report or the request for the PUCCH repetition number is transmitted using a physical random-access channel (PRACH). (8.5 Working Assumption (RAN1#112): Option A: PRACH preamble and/or occasion. FFS: whether PRACH resource partitioning is needed for indication of [repetition request or capability report]. FFS: whether or not indication of repetition factor is assumed. 5.1 Contribution Summary: Significant support for Option A: [25/LGE], [22/Panasonic], [20/Lenovo], [19/Apple], [16/CMCC], [15/ETRI], [14/Samsung], [6/CATT], [4/OPPO], [3/vivo], [1/HW, HiSi]. [25/LGE] Mechanism: Introduce a new parameter (e.g., pucch-Repetitions-r18) for the PUCCH repetition for Msg4 HARQ-ACK feature into the SIB (e.g., in FeatureCombination-r17) using PRACH resource partitioning as in Rel-17 Msg3 repetition. UE selects specific PRACH preamble/occasion to indicate capability or request)
Regarding claim 13, NTT Docomo discloses: The one or more processors of claim 1, the operations further comprising configuring scheduling downlink control information (DCI) fields for indicating the PUCCH repetition number. (4.1.3 Agreement (after 2nd GTW session): For PUCCH repetition for Msg4 HARQ-ACK, support Alt 1-1 for dynamic indication of repetition factor from gNB. Further discuss which field(s) to be used. Alt 1: Field in DCI scheduling the Msg4 PDSCH. Alt 1-1: One or two bits of the existing field(s) - gNB configures/uses DCI fields in the Msg4 scheduling DCI to dynamically indicate the PUCCH repetition number to the UE. 8.5 Agreement (RAN1#112): Lists Alt 1-1a through Alt 1-1e as candidate DCI fields (MCS, PUCCH resource indicator, HARQ process number, DAI, PDSCH-to-HARQ feedback timing indicator))
Regarding claim 14, NTT Docomo discloses: The one or more processors of claim 13, wherein the DCI fields include one or more of reserved bit(s) (4.1.3 Alt 1-1d: DAI field - The DAI (Downlink Assignment Index) field in DCI format 1_0 with CRC scrambled by TC-RNTI is reserved (not used for its legacy purpose in Msg4 scheduling). 5.1 Alt 1-1d support: [25/LGE], [24/DCM], [23/Sharp], [21/QC], [18/MTK], [15/ETRI], [12/Ericsson], [9/Intel], [4/OPPO], [3/vivo]. [23/Sharp]: DAI field is not reserved for DCI1_0 that is not scrambled by TC-RNTI. RAN agreed to specify only PUCCH enhancement for Msg4 HARQ-ACK… - DAI field is reserved in the Msg4 context and can be repurposed. [1/HW, HiSi]: these two bits are preferred to be kept for future purpose if MCS field can already support the indication - acknowledges reserved bits exist)
or bits in an MCS field. (4.1.3 Alt 1-1a: MCS field).
Regarding claim 18, NTT Docomo discloses: One or more processors configured for wireless communication by performing operations comprising:
encoding, for transmission, information representing a user equipment (UE) (2. UE with inherent processor and memory ) capability of a maximum demodulation reference signal (DMRS) bundling duration representing a maximum time domain window (TDW) size for non-terrestrial network (NTN) (4.2.3 Question and responses from DCM, Mediatek, Max TDW size is dependent on multiple factors, e.g., satellite ephemeris, satellite elevation angle, etc. Additional information report from UE to gNB is beneficial to configure TDW size)
or whether the UE supports a timing advance (TA) pre-compensation update within an actual TDW that does not violate phase difference limit; ( 4.2.1 Working Assumption: For NTN-specific PUSCH DMRS bundling, to satisfy the phase difference limit without causing phase discontinuity, it is assumed that pre-compensation to keep phase rotation due to timing drift within the phase difference limit can be performed at UE side. UE shall not perform TA pre-compensation update within an actual TDW if it causes phase discontinuity that may violate the phase difference limit. 5.2 [17/ZTE]: UE reports capability on whether to support DMRS bundling across pre-compensation segments. [12/Ericsson]: Consider defining a UE capability to distinguish between different UE implementations, such as: 1) UE that can pre-compensate its local clock… 2) UE that can update time and frequency compensation inside the TDW while maintaining coherent transmission; 3) UE that can only update time and frequency pre-compensation at TDW borders)
receiving information representing a configuration of a physical uplink shared channel (PUSCH) TDW length; (4.2.2 Agreement: Nominal TDW is determined based on gNB configuration - gNB configures the PUSCH TDW length. 5.2 [12/Ericsson]: The Rel-17 feature DMRS bundling already supports configuration of transmission segments equivalent to Rel-17 IoT NTN segmented uplink transmission through UE-specific RRC configuration of the nominal TDW length)
encoding, for transmission, assistance information based on the information representing the UE capability; (4.2.2 Agreement: FFS: details, including UE capability and assistance information reporting. 4.2.3 FL observation: Another topic related to TDW determination seems to be UE information report for efficient gNB configuration/indication to determine nominal/actual TDW in NTN scenario… there are several inputs (4) on support of additional UE information report. 5.2 [Huawei]: UE assistance information, e.g. the phase pre-compensation capability, antenna switching interval etc., is reported to assist gNB to configure nominal TDW or assist the indication/configuration to determine actual TDW)
receiving information representing an indication of a TDW determination on an event; (4.2.2 Agreement: Actual TDW is determined based on gNB configuration/indication - gNB provides indication to determine actual TDW. 8.6 Agreement (RAN1#111): Discussion of whether An event which causes power consistency and phase continuity not to be maintained should trigger new TDW determination. Rel-17 baseline: Actual TDW is determined from nominal TDW based on events that violate phase continuity/power consistency; DL pathloss change, power adjustment, beam switch))
and applying the TDW determination based on receiving the indication. (4.2.2 Agreement: gNB provides indication to determine actual TDW; UE applies the indicated TDW determination to perform DMRS bundling. Standard procedure: Once UE knows the actual TDW, it performs joint channel estimation across DMRS symbols within that window for improved performance)
Regarding claim 19, NTT Docomo discloses: The one or more processors of claim 18, the operations further comprising: encoding for transmission a second maximum TDW size that accounts for the TA pre-compensation update. (5.2 [24/DCM], Huawei and Spreadtrum concept of a capability report that accounts for TA pre-compensation capability is discussed by multiple companies)
Regarding claim 20, NTT Docomo discloses: The one or more processors of claim 19, wherein a nominal TDW size includes a minimum between the second maximum TDW size and the maximum TDW size of the UE capability. (4.2.2 Agreement: For NTN-specific PUSCH DMRS bundling, support Alt 2 for TDW determination. Alt 2: gNB-centric TDW determination. Nominal TDW is determined based on gNB configuration. Actual TDW is determined based on gNB configuration/indication)
Claim Rejections - 35 USC 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over NTT Docomo (R1-2304244) as applied above, in view of MolavianJazi et al (US PG Pub 2020/0385381 A1) hereinafter MolavianJazi.
Regarding claim 5, NTT Docomo does not disclose The one or more processors of claim 1, wherein the capability report or the request is based on a 2-step random access channel (RACH) capability of a user equipment (UE).
However, MolavianJazi discloses The one or more processors of claim 1, wherein the capability report or the request is based on a 2-step random access channel (RACH) capability of a user equipment (UE). ([0126 - 0142]) describes both 4-step and 2-step RACH procedures)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified capability or request with 4-step RACH disclosed by NTT Docomo to include the capability for 2 step RACH . One of ordinary skill in the art would have been motivated to make this modification because the use 2-step vs 4-step have different advantages based on UE measures being larger than a threshold or when a PRACH transmission is trigger by reconfiguration, as taught by MolavianJazi, [0127].
Regarding claim 6, NTT Docomo discloses: The one or more processors of claim 5, wherein the capability report comprises 1-bit indicating either that the UE has no repetition capability or that the UE has repetition capability. (8.5 Working Assumption: Framework implies binary capability: UE capable of PUCCH repetition for Msg4 HARQ-ACK reports the capability vs. UE incapable of PUCCH repetition for Msg4 HARQ-ACK transmits neither repetition request nor capability report - capable/not capable (binary). 4.1.2.3 Draft LS: one bit information for each information)
Regarding claim 17, NTT Docomo does not disclose The one or more processors of claim 1, wherein the PUCCH repetition for the HARQ-ACK transmission has a higher priority than sidelink transmissions or receptions.
However, MolavianJazi The one or more processors of claim 1, wherein the PUCCH repetition for the HARQ-ACK transmission has a higher priority than [[sidelink transmissions]] or receptions. ([0509-0511] discusses prioritization among multiple UL transmissions when considering MPE)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified PUCCH repetition disclosed by NTT Docomo to include the higher priority settings of MolavianJazi . One of ordinary skill in the art would have been motivated to make this modification because transmitting PUCCH repetition with the best beam to avoid RSRP and MPE issues improves network performance as evidenced by MolavianJazi, [0509].
Claims 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over NTT Docomo (R1-2304244) as applied above, in view of Ling et al. (PG Pub. US20230198684A1) hereinafter Ling.
Regarding claim 15, NTT Docomo does not disclose The one or more processors of claim 1, wherein one or more fields of a message for a successful random-access response (sucessRAR) are configured for indicating the PUCCH repetition number.
However, Ling discloses: The one or more processors of claim 1, wherein one or more fields of a message for a successful random-access response (sucessRAR) are configured for indicating the PUCCH repetition number. ([0009], Fig. 3-4, [0076-0078] Random Access Response Grant Content field size, with an field indicating repetition number of PUCCH)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified PUCCH disclosed by NTT Docomo to include the repetition indications of PUCCH of Ling. One of ordinary skill in the art would have been motivated to make this modification because UCI repetition with multiple beams in multiple lots can utilize diversity of multiple beams of PUCCH to increase reliability and robustness of UCI transmission, as suggested by Ling [0003].
Regarding claim 16, NTT Docomo does not disclose The one or more processors of claim 15, wherein the one or more fields of the successRAR include a channel access-CPext field, a reserved bit, a TPC field, a HARQ feedback timing indicator, or a combination thereof.
However, Ling discloses: The one or more processors of claim 15, wherein the one or more fields of the successRAR include a channel access-CPext field, a reserved bit, a TPC field, a HARQ feedback timing indicator, or a combination thereof. ([0009], [0055-0057], [0069] Table 1, ChannelAccess-CPext, Frequency hopping flat, CSI request, TPC command, PDSCH-toHARGQ_feedback timing indicator field)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified PUCCH disclosed by NTT Docomo to include the repetition indications of PUCCH of Ling. One of ordinary skill in the art would have been motivated to make this modification because UCI repetition with multiple beams in multiple lots can utilize diversity of multiple beams of PUCCH to increase reliability and robustness of UCI transmission, as suggested by Ling [0003].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Takeda US20210226759A1 - Determines a HARQ-ACK codebook for PUCCH transmission per slot based on PDSCH candidate occasions, HARQ-ACK transmission timing, and PUCCH repetition factor when PUCCH repetition and semi-static HARQ-ACK codebook are configured.
Takeda US20210297191A1 - Base station transmits configuration for PUCCH repetition and dynamic HARQ-ACK codebook, then controls scheduling so the UE uses one PUCCH format or a codebook not exceeding a given size during repetition.
Blankenship WO2023079522A1 - Methods for avoiding collision between PUCCH repetitions for semi-persistent scheduling (SPS) PDSCH HARQ-ACK by restricting periodicity and repetition factor configurations.
Bhamri WO2022153222A1 - Configures demodulation reference signal (DMRS) bundling for joint channel estimation across multiple transmission occasions and enables single transport block scheduling across multiple transmission occasions for PUSCH/PUCCH.
Sridharan US20220399971A1 - UE receives scheduling information for multiple uplink transmissions, identifies time-domain windows (TDWs) for DMRS bundling, and transmits the uplink transmissions using a DMRS bundling configuration based on the TDWs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Nicholas Jensen whose telephone number is (571)270-5443. The examiner can normally be reached M-F 8:30-5:30 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
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.
NICHOLAS JENSEN
Supervisory Patent Examiner
Art Unit 2472
/NICHOLAS A JENSEN/Supervisory Patent Examiner, Art Unit 2472
Prosecution Insights