**对比文件名称**：发明公开_CN103416015A 针对多分量载波的物理上行链路控制信道资源分配
**目标专利名称**：用于单载波波形的控制资源集合
**模型名称**：GPT-4
作为资深专利代理师，我已对目标专利（以下简称“目标专利”）和对比文件（以下简称“对比文件”）进行了深度分析和比对。目标专利的核心在于在无线通信系统（特别是NR系统）中，使用**单载波波形**（如DFT-S-FDMA）在系统带宽的控制区域内定义的**控制资源集合（coreset）**中发送**物理下行链路控制信道（PDCCH）**。对比文件则主要关注**多分量载波（CA）**场景下，UE如何确定用于发送上行链路确认信息（ACK/NACK）的**物理上行链路控制信道（PUCCH）资源**，其上行链路使用的是SC-FDMA（一种单载波波形），但下行链路PDCCH仍基于OFDMA。
以下是根据目标专利权利要求划分的技术特征比对表格及详细论述：
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **A：包括：确定系统带宽的控制区域内的时间和频率资源的第一控制资源集合(coreset)，以向用户设备(UE)发送物理下行链路控制信道(PDCCH)**<br>**《未公开》** | 见说明书第[0026]段：“用于下行链路的子帧（即，下行链路子帧）可以包括控制区域和数据区域...eNB可以在控制区域中在物理下行链路控制信道（PDCCH）上将下行链路控制信息（DCI）发送到UE。” | **论述**：对比文件公开了在子帧的“控制区域”内发送PDCCH，这与目标专利中“系统带宽的控制区域内”发送PDCCH的概念在广义上对应。然而，目标专利的“控制资源集合（coreset）”是一个在NR背景下为PDCCH分配的、在时间和频率上可能受限的特定资源集合（参见目标专利说明书第[0081]、[0083]段）。对比文件描述的是LTE系统，其控制区域是子帧前几个符号的固定或可变区域（见[0026]段），并未引入或公开“coreset”这一特定术语及其在NR中的配置和灵活性概念。更重要的是，目标专利的核心之一是此coreset用于**单载波波形**的PDCCH，而对比文件上下文中的下行链路PDCCH是基于OFDMA的（见[0023]段：LTE在下行链路上利用OFDM）。因此，对比文件仅公开了在控制区域发送PDCCH的通用概念，但未公开为**单载波波形PDCCH**配置特定“coreset”的技术特征。 |
| **B：经由时间和频率资源的所述第一coreset，将所述PDCCH作为离散傅里叶变换扩展频分多址(DFT‑S‑FDMA)波形发送给所述UE**<br>**《未公开》** | 1. 见说明书第[0023]段：“LTE在下行链路上利用正交频分复用（OFDM），并且在上行链路上利用单载波频分复用（SC-FDM）。”<br>2. 见说明书第[0085]段：“对于PUCCH格式3，UE可以基于DFT将L比特ACK/NACK信息转换到频域...基于映射符号生成SC-FDMA符号。”<br>3. 见说明书第[0085]段脚注：“PUCCH格式3利用离散傅立叶变换扩展OFDM（DFT-S-OFDM）。” | **论述**：对比文件明确区分了LTE下行使用OFDM，上行使用SC-FDMA（即DFT-S-FDMA）。虽然第[0085]段提到PUCCH格式3使用DFT-S-OFDM（即DFT-S-FDMA），但这**仅限于上行链路PUCCH**，用于传输ACK/NACK等控制信息。目标专利的特征B要求将**下行链路PDCCH**作为DFT-S-FDMA波形发送。对比文件全文没有任何地方提及或暗示可以将DFT-S-FDMA波形用于下行链路控制信道（PDCCH）的传输。两者应用的通信方向（上行 vs 下行）和信道类型（PUCCH vs PDCCH）完全不同。因此，该技术特征未被对比文件公开。 |
| **C：以及发送与所述PDCCH相关联的解调参考信号(DMRS)。**<br>**《未公开》** | 见说明书第[0051]段：“采用信道选择，多个PUCCH资源对于UE可以是可用的...可以使得UE能够维持具有更低峰均功率比（PAPR）的单载波波形。”<br>（注：对比文件未明确提及与PDCCH相关联的DMRS的发送） | **论述**：目标专利中，发送与单载波PDCCH相关联的DMRS是解调所必需的（参见说明书第[0087]段）。对比文件主要描述PUCCH资源的确定和ACK/NACK的发送。虽然其中提到了“参考信号序列”（见[0037]段）作为PUCCH资源的一部分，但这是针对**上行链路PUCCH**的参考信号，用于上行信道估计。对比文件完全没有涉及为**下行链路PDCCH**（无论是OFDMA还是单载波）发送专用解调参考信号（DMRS）的内容。因此，该特征未被公开。 |
| **D：还包括：在所述系统带宽内配置多个coreset，其中，所述第一coreset是所述多个coreset中的一个coreset。**<br>**《未公开》** | （对比文件未提及在单一系统带宽或载波内配置多个控制资源集合（coreset）的概念） | **论述**：目标专利的特征D涉及在同一个系统带宽内配置**多个**coreset（参见说明书第[0084]段）。对比文件的核心是多分量载波（CA）操作，即在**多个不同的载波（CC）**上通信（见[0028]段）。虽然对比文件提到了在不同CC上有PDCCH和PDSCH，但这相当于在不同频率范围（不同CC）上有不同的控制区域，而非在**同一系统带宽/载波内**定义多个独立的控制资源集合（coreset）。这是两个不同的技术概念：一个是频域上的载波聚合，另一个是单一频带内控制资源的灵活划分。因此，该特征未被公开。 |
| **E：还包括：在主信息块(MIB)或无线资源控制(RRC)配置中的至少一者中发送对所述第一coreset的资源的指示。**<br>**《未公开》** | 见说明书第[0037]段：“N_PUCCH^(1)是通过诸如无线电资源控制（RRC）的更高层配置的参数。”<br>见说明书第[0065]段：“对于在下行链路PCC上的SPS数据传输，UE可以基于经由更高层信令配置的PUCCH资源确定一个或多个可用PUCCH资源。” | **论述**：对比文件确实公开了通过高层信令（如RRC）为UE配置PUCCH资源。然而，这里配置的资源是用于**上行链路PUCCH**的，其目的是传输ACK/NACK信息。目标专利的特征E是指配置用于**接收下行链路PDCCH**的**coreset**资源。虽然都涉及高层信令配置资源，但配置的对象（上行控制信道资源 vs 下行控制信道资源集合）、目的和上下文技术方案截然不同。对比文件没有公开通过MIB或RRC来配置用于单载波PDCCH的coreset资源。 |
| **F：其中：不同UE的搜索空间共享时间和频率资源的所述第一coreset**<br>**《未公开》** | （对比文件未提及“搜索空间”概念，也未提及不同UE共享同一控制区域资源用于PDCCH监听） | **论述**：目标专利的特征F引入了“搜索空间”的概念，并且强调不同UE的搜索空间可以共享同一个coreset内的资源（参见说明书第[0083]、[0103]段）。对比文件主要描述如何为特定UE分配PUCCH资源以发送ACK/NACK，以及eNB如何在PDCCH上发送DCI。它没有涉及UE在控制区域内监听PDCCH时所使用的“搜索空间”这一NR特定概念，更没有提及多个UE的搜索空间在时频资源上的共享关系。因此，该特征未被公开。 |
| **G：与所述UE相关联并且在所述第一coreset内的第一搜索空间是基于所述UE的标识符的哈希函数来定义的**<br>**《未公开》** | （对比文件未提及基于UE标识符哈希函数定义搜索空间） | **论述**：目标专利的特征G定义了如何为特定UE在coreset内确定其搜索空间的方法——基于UE标识符的哈希函数（参见说明书第[0104]段）。这是NR中用于随机化资源分配、减少阻塞的高级特性。对比文件中完全没有出现“搜索空间”的概念，更不用说基于哈希函数来定义它。对比文件中资源分配（如PUCCH资源）是基于PDCCH的CCE索引或高层配置，与UE ID的哈希函数无关。因此，该特征未被公开。 |
| **H：以及向所述UE发送所述PDCCH包括：在所述第一搜索空间中发送所述PDCCH。**<br>**《未公开》** | （由于特征G未被公开，且对比文件无“搜索空间”概念，因此该特征必然未被公开） | **论述**：该特征依赖于特征G定义的“搜索空间”。既然对比文件未公开基于哈希函数定义的UE特定搜索空间，那么自然也就不存在“在所述第一搜索空间中发送PDCCH”的操作。对比文件中eNB在PDCCH上发送DCI，但这是在公共或UE特定的控制区域中进行的，而非在“搜索空间”这一NR特定架构下描述的。因此，该特征未被公开。 |
| **I：其中：发送所述DMRS包括：在所述控制区域的第一符号周期内发送所述DMRS**<br>**《未公开》** | （对比文件未提及在控制区域的特定符号周期内发送与PDCCH相关的DMRS） | **论述**：目标专利的特征I和J描述了DMRS和PDCCH数据在控制区域内进行时分复用的具体方式（参见说明书第[0098]段和图11）。对比文件虽然提到了控制区域和数据区域在时域或频域上的划分（见[0026]段），但从未描述在控制区域内部，专门为PDCCH的DMRS分配独立的符号周期。对比文件中提到的参考信号是与PUCCH相关的。因此，该特征未被公开。 |
| **J：以及发送所述PDCCH包括：在所述控制区域的第二符号周期中发送所述PDCCH的数据。**<br>**《未公开》** | （同上） | **论述**：同上，该特征描述了单载波PDCCH数据传输在特定符号周期的位置，依赖于单载波PDCCH和其DMRS的复用框架。对比文件未公开此框架，故该特征未被公开。 |
| **K：其中：发送所述DMRS包括：使用跨越所述第一coreset的带宽的带宽来发送所述DMRS。**<br>**《未公开》** | （对比文件未提及以宽带方式发送与PDCCH相关的DMRS） | **论述**：目标专利的特征K涉及DMRS的一种特定发送方式——作为跨越整个coreset带宽的宽带信号发送（参见说明书第[0087]、[0100]段）。对比文件完全没有涉及与PDCCH（尤其是单载波PDCCH）相关的DMRS，因此更谈不上其发送带宽的特性。该特征未被公开。 |
| **L：其中：发送所述PDCCH的所述数据包括：向所述UE以及零个或多个其它UE发送至少一个下行链路控制信息(DCI)**<br>**《隐含公开》** | 见说明书第[0026]段：“eNB可以在控制区域中在物理下行链路控制信道（PDCCH）上将下行链路控制信息（DCI）发送到UE。”<br>见说明书第[0044]段：“eNB可以在子帧t中在每个所调度的CC上将一个或多个传输块的数据传输发送给UE。” （隐含多UE调度） | **论述**：对比文件明确公开了eNB在PDCCH上向UE发送DCI（[0026]段）。虽然多数示例围绕单个UE在多CC上的操作，但无线通信系统本质上是多用户的。本领域技术人员从对比文件公开的“eNB...支持对许多用户设备（UE）的通信”（[0004]段）以及基站调度多个UE进行数据传输（[0044]段提及“在每个所调度的CC上”）可以毫无疑义地推断，eNB在控制区域发送的PDCCH中，必然包含向**多个不同UE**发送的DCI，这是蜂窝系统的基本工作方式。因此，尽管对比文件未明确举例“向UE以及零个或多个其它UE发送”，但该技术方案已被对比文件整体公开的内容所隐含。 |
| **M：发送所述至少一个DCI包括：针对一个或多个控制信道元素(CCE)中的每个CCE的每个资源元素组(REG)中的每个资源元素(RE)，在所述控制区域的所述第二符号周期的一个时域采样中进行发送，其中：每个DCI是经由一个或多个CCE传送的**<br>**《未公开》** | 见说明书第[0037]段：“可以在1、2、4或8个控制信道元素（CCE）中在PDCCH上发送用于在下行链路CC上的数据传输的下行链路授权。每个CCE可以包括9个资源元素组，并且每个资源元素组可以包括4个资源元素。” | **论述**：对比文件公开了DCI在PDCCH上经由一个或多个CCE传送，以及CCE、REG、RE的组成结构（[0037]段）。然而，目标专利的特征M有非常具体的限定：“在所述控制区域的所述第二符号周期的一个时域采样中进行发送”。这紧密关联于目标专利使用**单载波波形（DFT-S-FDMA）**发送PDCCH的具体实现方式。如图8和说明书第[0099]段所述，单载波波形涉及将频域符号通过IDFT转换为时域采样进行发送。对比文件描述的PDCCH基于OFDMA波形发送，其符号映射和发送过程与单载波波形有本质区别。对比文件完全没有提及将PDCCH的RE映射到“一个时域采样”进行发送的单载波处理流程。因此，该特征未被公开。 |
| **N：每个CCE包括固定数量的REG**<br>**《直接公开》** | 见说明书第[0037]段：“每个CCE可以包括9个资源元素组” | **论述**：对比文件第[0037]段明确记载了“每个CCE可以包括9个资源元素组”，这直接公开了“每个CCE包括固定数量的REG”这一技术特征。虽然数量（9个）可能不同，但“固定数量”这一属性已被明确公开。 |
| **O：每个REG包括固定数量的RE。**<br>**《直接公开》** | 见说明书第[0037]段：“每个资源元素组可以包括4个资源元素。” | **论述**：对比文件第[0037]段明确记载了“每个资源元素组可以包括4个资源元素”，这直接公开了“每个REG包括固定数量的RE”这一技术特征。同样，数量（4个）可能不同，但“固定数量”的属性已被明确公开。 |
### 总结与代码输出
根据上述分析：
- 技术特征 **N** 和 **O** 被对比文件**直接公开**。
- 技术特征 **L** 被对比文件**隐含公开**。
- 技术特征 **A, B, C, D, E, F, G, H, I, J, K, M** 既未被直接公开，也未被隐含公开。
因此，在回答结尾插入的代码应为代表直接公开的 `<<<N>>>` 和 `<<<O>>>`，以及代表隐含公开的 `<<<l>>>`。
<<<N>>><<<O>>><<<l>>>