**对比文件名称**：发明申请_US20170141901A1 SOUNDING REFERENCE SIGNAL TRANSMISSIONS IN ENHANCED MACHINE TYPE COMMUNICATION
**目标专利名称**：用于窄带操作的上行链路和下行链路授权
**模型名称**：深度求索
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**: 一种用于由用户设备(UE)进行无线通信的方法 <br> **公开性判断**: 《直接公开》 | 对比文件第[0067]段：“FIG. 6 illustrates example operations 600 for wireless communications, according to certain aspects of the present disclosure. According to certain aspects, example operations 600 may be performed by a user equipment (UE) (e.g., an MTC UE, such as one or more of the UEs 120) and may enable support of sounding reference signals (SRSs) for machine type communications.” | 对比文件明确公开了一种由用户设备（UE）（例如MTC UE）执行的用于无线通信的方法。这直接对应于目标专利权利要求中限定的方法执行主体“用户设备(UE)”和“无线通信的方法”。 |
| **技术特征B**: 针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道 <br> **公开性判断**: 《隐含公开》 | 对比文件第[0053]段：“Additionally or alternatively, as illustrated in the example frame structure of FIG. 5B, one or more narrowband regions 560, 562 used by LC UEs in MTC may be frequency division multiplexed within the wider bandwidth 550 supported by LTE. Multiple narrowband regions, with each narrowband region spanning a bandwidth that is no greater than a total of 6 RBs, may be supported for MTC and/or eMTC operation. In some cases, each LC UE in MTC operation may operate within one narrowband region (e.g., at 1.4 MHz or 6 RBs) at a time.” <br> 第[0054]段：“The LC UEs may operate (e.g., monitor/receive/transmit) within the narrowband regions for various different operations. For example, as shown in FIG. 5B, a first narrowband region 560 (e.g., spanning no more than 6 RBs of the wideband data) of a subframe 552 may be monitored by one or more LC UEs for either a PSS, SSS, PBCH, MTC signaling, or paging transmission from a BS in the wireless communication network.” | 对比文件公开了低成本（LC）UE（例如eMTC UE）在从更宽系统带宽划分出的一个或多个窄带区域内操作，包括在该区域内进行监视（monitor）。在无线通信系统中，为了接收上行链路或下行链路授权，UE需要监视携带这些授权的控制信道（如PDCCH）。对比文件虽未明确提及“授权”，但其描述的“MTC signaling”可以包含控制信令，且UE在窄带内“监视”各类传输（包括信令）是本领域的常规操作。因此，本领域技术人员可以合理推断，为了接收UL或DL授权，UE需要监视系统带宽的窄带中的控制信道。 |
| **技术特征C**: 接收交织的在各自的子帧中的UL授权和DL授权 <br> **公开性判断**: 未公开 | 对比文件未提及“交织的UL授权和DL授权”或类似概念。 | 对比文件的核心内容是解决eMTC设备在窄带操作中传输SRS（探测参考信号）时遇到的问题，例如SRS与PUSCH/PDSCH的资源冲突、重调谐等。全文未涉及“交织的UL授权和DL授权”这一技术特征。交织授权是指交替接收UL和DL授权，以支持交替的UL和DL数据传输，这是目标专利为解决TDD模式或提高FDD效率而引入的特定方案。对比文件未公开此内容。 |
| **技术特征D**: 以及响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息。 <br> **公开性判断**: 未公开 | 对比文件未提及基于“交织的UL和DL授权”来发送或接收信息。 | 由于对比文件未公开“接收交织的UL和DL授权”（特征C），因此自然不可能公开“响应于所接收的交织授权来发送或接收信息”。对比文件中UE发送或接收信息（如SRS、PUSCH、PDSCH）是基于其他调度或触发机制，而非基于交织的UL/DL授权。 |
| **技术特征E**: 根据权利要求1所述的方法，其中，接收所述交织的在各自的子帧中的UL授权和DL授权包括以下至少一者：在UL授权之后接收DL授权作为下一个授权，或者在DL授权之后接收UL授权作为下一个授权。 <br> **公开性判断**: 未公开 | 对比文件未提及授权接收的特定顺序，如“在UL授权之后接收DL授权作为下一个授权”或反之。 | 这是对“交织授权”顺序的具体化。对比文件完全未涉及此类授权接收的时序关系。 |
| **技术特征F**: 根据权利要求1所述的方法，其中，所述UE监视控制信道搜索空间，并且在UL授权之后并在响应于所述UL授权的在UL数据信道上所述发送信息的开始之后，接收DL授权作为下一个授权。 <br> **公开性判断**: 未公开 | 对比文件未提及在UL数据传输开始之后接收DL授权作为下一个授权这种特定的操作时序。 | 此特征描述了非常具体的UE行为时序：在UL授权触发的UL数据传输开始“之后”，才接收作为下一个授权的DL授权。对比文件未描述任何与此类似的、基于数据信道传输开始时刻来界定后续授权接收时刻的机制。 |
| **技术特征G**: 根据权利要求4所述的方法，其中，在所述UE在其中在所述UL数据信道上发送信息的子帧之后并在用于DL通信的子帧之前的子帧用作保护子帧。 <br> **公开性判断**: 未公开 | 对比文件第[0071]段：“For example, for FDD, a UE may need a large amount of time to be able to retune from UL to DL since the UL narrowband and the DL narrowband are far apart from each other. In this case (e.g., for an FDD UE retuning from UL to DL), the UE may transmit an SRS during the last symbol of its UL subframe and may use the next whole subframe to retune to DL. However, for TDD, since the UE only has two symbols to retune, the UE may drop transmission of the SRS. Additionally, for TDD, if the UE is scheduled to transmit SRS in a partial downlink subframe, the decision of whether to transmit the SRS or not may be dependent on the duration of the partial downlink subframe, partial uplink subframe, and/or a guard period.” | 对比文件提到了TDD操作中的“保护周期（guard period）”，但其上下文是用于UE在部分下行链路子帧中决定是否传输SRS，或者用于半双工操作中的重调谐。这里描述的保护周期是TDD帧结构固有的或用于射频切换的，**并非**专门用于在UL数据子帧和DL通信子帧之间作为保护，以支持交织授权场景下的时序安排。目标专利中的“保护子帧”是为了确保交织UL/DL数据传输时序而引入的特定概念，与对比文件提及的保护周期作用不同。 |
| **技术特征H**: 根据权利要求1所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持一个或多个混合自动重传请求(HARQ)过程。 <br> **公开性判断**: 未公开 | 对比文件第[0043]段：“The wireless network may support hybrid automatic retransmission request (HARQ) for data transmission on the downlink and uplink.” | 对比文件仅将HARQ作为无线网络支持的背景技术提及，并未将其与“交织的UL授权和DL授权”相关联，也未公开每个此类授权支持一个或多个HARQ过程。目标专利将此作为交织授权的一个支持特性，对比文件未涉及。 |
| **技术特征I**: 根据权利要求8所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持两个HARQ过程。 <br> **公开性判断**: 未公开 | 对比文件未提及每个授权支持特定数量（如两个）HARQ过程。 | 这是对特征H的进一步限定（支持两个HARQ过程）。对比文件未公开特征H，因此自然未公开此更具体的限定。 |
| **技术特征J**: 根据权利要求8所述的方法，其中，所述UE经由能力信令指示对以下至少一者的支持：针对每个UL授权或DL授权的两个HARQ进程，或UL授权和DL授权的交织。 <br> **公开性判断**: 未公开 | 对比文件未提及UE通过能力信令指示对交织授权或特定数量HARQ过程的支持。 | 对比文件未涉及UE能力信令指示此类特定功能支持的内容。 |
| **技术特征K**: 根据权利要求1所述的方法，还包括：响应于所述响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息，识别冲突，所述冲突包括以下至少一者：UL数据信道和DL数据信道之间的冲突，或 UL数据信道与混合ARQ确认(HARQ‑ACK)信令之间的冲突。 <br> **公开性判断**: 未公开 | 对比文件第[0082]段：“In some cases, a UE may determine that a downlink transmission (e.g., a PDSCH transmission) will collide with an SRS transmission. For example, a UE may receive a grant from a base station comprising a trigger to perform SRS during a specific subframe. The UE may determine that the SRS transmission may collide with a PDSCH transmission during that subframe. In order to prevent collision, the UE may decide to drop at least one of the SRS transmission, the PDSCH transmission, or the resource grant (e.g., the UE may treat the resource grant as invalid).” <br> 第[0061]-[0065]段讨论了SRS与PUSCH/PDSCH可能冲突的各种场景。 | 对比文件确实公开了识别传输冲突（如SRS与PDSCH冲突）并采取相应处理。**然而**，目标专利中识别的冲突类型是特定的，源于“交织的UL和DL授权”场景：1) **UL数据信道和DL数据信道之间的冲突**；2) **UL数据信道与HARQ-ACK信令之间的冲突**。对比文件公开的冲突是SRS（一种上行参考信号）与下行数据信道（PDSCH）或上行数据信道（PUSCH）的冲突，这与目标专利定义的两种数据信道间冲突或数据信道与确认信令间冲突**在冲突对象和产生场景上均不相同**。因此，对比文件未公开目标专利中限定的这些特定冲突类型。 |
| **技术特征L**: 根据权利要求11所述的方法，其中，所述HARQ‑ACK信令包括确认或否定确认(NACK)，并且其中，所述HARQ‑ACK信令是针对所述DL数据信道的。 <br> **公开性判断**: 未公开 | 对比文件未提及针对DL数据信道的HARQ-ACK信令。 | 对比文件未涉及HARQ-ACK信令的具体内容及其与DL数据信道的关联。 |
| **技术特征M**: 根据权利要求11所述的方法，其中，所述冲突包括所述UL数据信道和所述DL数据信道之间的所述冲突，所述方法还包括以下至少一个步骤：确定使用所述UL数据信道和所述DL数据信道中的一者，或对于在所述UL数据信道和所述DL数据信道之间冲突的子帧，确定使用所述UL数据信道和所述DL数据信道中的一者的所述子帧。 <br> **公开性判断**: 未公开 | 对比文件第[0082]段提到冲突时UE可以决定丢弃（drop）SRS传输、PDSCH传输或将资源授权视为无效。 | 对比文件公开了在冲突时选择丢弃其中一个传输。**但是**，该冲突处理是针对SRS与PDSCH/PUSCH的冲突，而非目标专利中UL数据信道与DL数据信道的冲突。由于冲突类型本身未被公开（特征K），因此处理这种特定冲突的具体步骤（在UL和DL数据信道中择一使用）也未被公开。 |
| **技术特征N**: 根据权利要求13所述的方法，其中，所述确定使用的步骤是至少部分地基于能量度量阈值的。 <br> **公开性判断**: 未公开 | 对比文件未提及基于“能量度量阈值”来决定使用哪个信道。 | 对比文件未公开此具体的选择标准。 |
| **技术特征O**: 根据权利要求12所述的方法，其中，所述冲突包括所述UL数据信道与所述HARQ‑ACK信令之间的冲突，所述方法还包括以下至少一个步骤：对于在所述UL数据信道和所述HARQ‑ACK信令之间冲突的子帧，确定传送所述HARQ‑ACK信令，或者将所述HARQ‑ACK信令与所述UL数据信道复用。 <br> **公开性判断**: 未公开 | 对比文件未提及UL数据信道与HARQ-ACK信令冲突的场景及处理方式。 | 对比文件未公开此类冲突及相应的处理步骤（传送HARQ-ACK或复用）。 |
| **技术特征P**: 根据权利要求15所述的方法，其中，所述将所述HARQ‑ACK信令与所述UL数据信道复用包括：对于在所述UL数据信道和所述HARQ‑ACK信令之间冲突的子帧，用所述HARQ‑ACK信令调制所述UL数据信道的解调参考信号(DMRS)。 <br> **公开性判断**: 未公开 | 对比文件未提及用HARQ-ACK信令调制UL数据信道的DMRS。 | 对比文件未公开此具体的复用实现方式。 |
| **技术特征Q**: 根据权利要求1所述的方法，其中，所述UE被配置用于窄带物联网(NB‑IoT)。 <br> **公开性判断**: 《直接公开》 | 对比文件第[0030]段：“Some UEs may be considered machine-type communication (MTC) UEs, which may include remote devices, such as sensors, meters, monitors, location tags, drones, trackers, robots, etc., that may communicate with a base station, another remote device, or some other entity. ... MTC devices, as well as other types of devices, may include internet of everything (IoE) or internet-of-things (IoT) devices, such as NB-IoT (narrowband internet-of-things) devices, and techniques disclosed herein may be applied to MTC devices, NB-IoT devices, as well as other devices.” | 对比文件明确提及本公开内容的技术可应用于NB-IoT（窄带物联网）设备。这直接公开了UE可被配置用于NB-IoT。 |
| **技术特征R**: 根据权利要求1所述的方法，其中，所述UE被配置用于时分双工(TDD)操作。 <br> **公开性判断**: 《隐含公开》 | 对比文件第[0071]段：“However, for TDD, since the UE only has two symbols to retune, the UE may drop transmission of the SRS. Additionally, for TDD, if the UE is scheduled to transmit SRS in a partial downlink subframe, the decision of whether to transmit the SRS or not may be dependent on the duration of the partial downlink subframe, partial uplink subframe, and/or a guard period.” <br> 第[0021]段提到了“time division duplex (TDD)”。 | 对比文件多次提及TDD，并讨论了在TDD模式下UE关于SRS传输和重调谐的行为。虽然未明确说“UE被配置用于TDD操作”，但本领域技术人员可以合理推断，当对比文件讨论TDD模式下的UE行为时，其所指的UE自然是能够或已经被配置用于TDD操作的UE。因此，此特征被隐含公开。 |
| **技术特征S**: 根据权利要求1所述的方法，其中，所述UE被配置用于频分双工(FDD)操作。 <br> **公开性判断**: 《直接公开》 | 对比文件第[0021]段：“3GPP Long Term Evolution (LTE) and LTE-Advanced (LTE-A), in both frequency division duplex (FDD) and time division duplex (TDD), are new releases of UMTS that use E-UTRA...” <br> 第[0071]段：“For example, for FDD, a UE may need a large amount of time to be able to retune from UL to DL since the UL narrowband and the DL narrowband are far apart from each other.” | 对比文件明确将FDD作为通信模式进行描述，并具体讨论了FDD模式下UE的重调谐行为。这直接表明了UE可以被配置用于FDD操作。 |
| **技术特征T**: 根据权利要求1所述的方法，其中，所述控制信道包括窄带物理下行链路控制信道(NPDCCH)。 <br> **公开性判断**: 未公开 | 对比文件未提及“窄带物理下行链路控制信道（NPDCCH）”。对比文件提到的控制信道主要是PDCCH（例如第[0038]段）。 | 对比文件未公开此特定的窄带控制信道类型。NPDCCH是NB-IoT中特定的控制信道，而对比文件主要聚焦于eMTC及更通用的LTE上下文。 |
| **技术特征U**: 根据权利要求1所述的方法，其中，所述发送信息包括：响应于所接收的UL授权，在UL数据信道中发送信息；并且其中，所述接收信息包括响应于所述DL授权在DL数据信道中接收信息。 <br> **公开性判断**: 未公开 | 对比文件第[0058]段：“For example, during an uplink subframe, a UE may transmit a physical uplink shared channel (PUSCH) for the majority of the uplink subframe...” <br> 第[0038]段：“The eNB may transmit traffic data and/or other data on the PDSCH...” | 对比文件提到了UE在PUSCH上发送信息以及在PDSCH上接收信息。**但是**，目标专利中“发送信息”和“接收信息”是明确“响应于所接收的UL授权”和“响应于所述DL授权”的。对比文件虽然描述了PUSCH/PDSCH传输，但并未将其与“响应于UL/DL授权”这一因果关系紧密绑定在该方法步骤中。更重要的是，此处的“UL授权”和“DL授权”是前述“交织的授权”的一部分，而该前提特征（C）未被公开。因此，此特征作为一个整体（基于交织授权的数据收发）未被公开。 |
| **技术特征V**: 根据权利要求21所述的方法，其中，所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)，并且其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)。 <br> **公开性判断**: 未公开 | 对比文件未提及“窄带物理上行链路共享信道(NPUSCH)”和“窄带物理下行链路共享信道(NPDSCH)”。对比文件使用的是通用术语PUSCH和PDSCH（例如第[0058], [0038]段）。 | NPUSCH和NPDSCH是NB-IoT中特定的窄带数据信道名称。对比文件未使用这些特定术语，因此未公开此特征。 |
| **技术特征W**: 根据权利要求11所述的方法，其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)，所述HARQ‑ACK包括混合自动重传请求(HARQ)确认或否定确认，并且所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)。 <br> **公开性判断**: 未公开 | 对比文件未提及NPDSCH、NPUSCH，也未详细定义HARQ-ACK的具体内容。 | 此特征是对冲突中涉及的信道和信令类型的进一步定义。由于冲突本身（特征K）及相关信道类型（特征V）均未被公开，此特征也未被公开。 |
<<<A>>><<<Q>>><<<R>>><<<S>>>