**对比文件名称**：发明专利_JP2016506088A 無線通信システム、基地局、及びそれらの方法
**目标专利名称**：PUCCH资源映射和HARQ‑ACK反馈
**模型名称**：DeepSeek
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：一种用于由用户装备UE进行无线通信的方法**<br>**判断结果：隐含公开** | [0033] 段： “Rel.11以降のUEは、本明細書においてフレキシブルTDD UEとも呼ばれる。... この機能(405)は、PDSCH HARQのエンコードと、PDSCH HARQフィードバックをeNB(401)に送信するための適切な1つ以上のULサブフレームの選択とを行う。”<br>**译文**： “Rel.11及以后的UE，在本文中也称为灵活TDD UE。... 该功能(405)执行PDSCH HARQ的编码，以及选择用于向eNB(401)发送PDSCH HARQ反馈的一个或多个合适的UL子帧。” | 对比文件通篇描述了在支持灵活TDD配置的系统中，UE（特别是灵活TDD UE）所执行的操作，包括接收配置、确定HARQ反馈时序和资源等。虽然未明确使用“一种用于由用户装备UE进行无线通信的方法”这样的总括性语句，但其[0033]段及全文（如[0035]段关于UE的TDD配置处理功能）实质性地描述了UE执行无线通信方法的步骤。本领域技术人员可直接且毫无疑义地确定，对比文件公开了一种由UE执行的无线通信方法。该特征在对比文件中为解决灵活TDD系统中的PUCCH资源冲突和效率问题提供了基础框架，与目标专利中作为方法权利要求主题的作用相同。 |
| **技术特征B：接收指示动态上行链路‑下行链路UL‑DL子帧配置的信令**<br>**判断结果：直接公开** | [0034] 段： “また、eNB(401)は、高速シグナリング手法を使用して、Rel.11以降のUE(404)のみとショートタームTDD UL‑DLコンフィグレーションを通信する。eNB(401)は、共通検索領域(Common Search Space)内のPDCCH又はEPDCCH(Enhanced PDCCH)上で送信されるDCI(Downlink Control Information:ダウンリンク制御情報)の形式でショートタームTDD UL‑DLコンフィグレーションを送信する。”<br>**译文**： “此外，eNB(401)使用快速信令方法，仅与Rel.11及以后的UE(404)通信短期TDD UL-DL配置。eNB(401)以在公共搜索空间内的PDCCH或EPDCCH上发送的DCI（下行链路控制信息）的形式发送短期TDD UL-DL配置。” | 对比文件明确公开了基站向特定UE（Rel.11及以后的UE，即支持动态配置的UE）发送指示短期（即动态）TDD UL-DL配置的信令，该信令通过PDCCH/EPDCCH上的DCI形式发送。这直接对应于目标专利中“接收指示动态上行链路‑下行链路UL‑DL子帧配置的信令”。该特征在对比文件中用于使UE获知当前帧使用的动态子帧配置，以进行后续的HARQ反馈和资源确定，与目标专利中为解决动态配置下的资源分配问题而接收配置信令的作用完全相同。 |
| **技术特征C：基于所述动态UL‑DL子帧配置来确定混合自动重复请求HARQ确收/否定确收ACK/NACK定时**<br>**判断结果：未公开** | 无对应内容。 | 对比文件虽然提到了使用“参考配置”来确定HARQ定时（例如[0010]段），但明确区分了“参考配置”和“动态配置”。对比文件的核心方案之一是HARQ定时基于**参考UL-DL配置**（见[0010], [0020], [0021]段），而PUCCH资源分配则可能基于调整后的DL关联集（即部分考虑了动态配置的影响，但非直接基于动态配置确定定时）。目标专利特征C明确要求“基于所述动态UL‑DL子帧配置”来确定HARQ ACK/NACK定时，这与对比文件中基于“参考配置”确定定时的教导相悖。对比文件未公开，也未隐含教导本领域技术人员基于动态配置本身来确定HARQ ACK/NACK定时。 |
| **技术特征D：基于所述动态UL‑DL子帧配置来确定针对物理上行链路控制信道PUCCH的HARQ资源分配**<br>**判断结果：隐含公开** | [0020] 段： “第3のDLアソシエーションセットは、前記第2のDLアソシエーションセットにおけるサブフレームを有するが、前記第1のDLアソシエーションセットにおけるサブフレームのいくつかが除かれており、... 前記第3のDLアソシエーションセットにおけるサブフレームに対するPUCCHリソースの割り当てとを実行し”<br>[0043] 段： “より高いPUCCH効率を達成し、サブフレーム#1、#5及び#6(602)に対する冗長PUCCHリソースを予約するために、フレキシブルTDD UEのDLアソシエーションセット(セット3(603))は、サブフレーム#9(521)、#0(522)、#7(525)、#8(526)、#4(524)及び#3(523)のみを含む。”<br>**译文**： [0020]“第三DL关联集具有所述第二DL关联集中的子帧，但去除了所述第一DL关联集中的一些子帧，... 执行对所述第三DL关联集中的子帧的PUCCH资源分配”。 [0043]“为了达成更高的PUCCH效率，并避免为子帧#1、#5和#6(602)预留冗余的PUCCH资源，灵活TDD UE的DL关联集（集3(603)）仅包括子帧#9(521)、#0(522)、#7(525)、#8(526)、#4(524)和#3(523)。” | 对比文件公开了为灵活TDD UE定义“第三DL关联集（Set 3）”，该集合是基于参考配置的DL关联集（Set 2）**去除**了传统UE的DL关联集（Set 1）中的子帧后得到的。传统UE的DL关联集是基于SIB1配置（即长期/半静态配置），而灵活TDD UE的Set 1与之相同（[0036]段）。因此，从Set 2中去除Set 1的子帧，这一操作**实质上依赖于当前动态配置与传统配置的差异**（即哪些子帧在动态配置下是DL，而在传统配置下也是DL，这些子帧的资源会冲突，故被去除）。最终用于PUCCH资源分配的Set 3，其构成是由动态配置与传统配置共同决定的，可以理解为**基于动态配置进行了调整**。本领域技术人员能够合理推断，为了确定Set 3，UE必须知晓动态UL-DL配置（特征B），并基于此配置与传统配置的比较来生成用于资源分配的DL关联集。因此，对比文件隐含公开了“基于动态UL‑DL子帧配置来确定针对PUCCH的HARQ资源分配”这一概念。 |
| **技术特征E：以及基于所确定的HARQ资源分配和HARQ ACK/NACK定时来在所述PUCCH上传送HARQ ACK/NACK**<br>**判断结果：隐含公开** | [0033] 段： “この機能(405)は、PDSCH HARQのエンコードと、PDSCH HARQフィードバックをeNB(401)に送信するための適切な1つ以上のULサブフレームの選択とを行う。”<br>结合[0010]段关于参考配置确定HARQ定时的描述，以及[0020]、[0043]段关于基于Set 3进行PUCCH资源分配的描述。<br>**译文**： “该功能(405)执行PDSCH HARQ的编码，以及选择用于向eNB(401)发送PDSCH HARQ反馈的一个或多个合适的UL子帧。” | 对比文件[0033]段明确UE需要选择用于发送HARQ反馈的UL子帧（这涉及HARQ定时），并执行编码和发送。[0010]段教导了HARQ定时可以基于参考配置。[0020]、[0043]段教导了PUCCH资源分配基于调整后的DL关联集（Set 3）。虽然对比文件将定时（基于参考配置）和资源分配（基于调整后的集）分开描述，但作为一个完整的HARQ反馈流程，本领域技术人员能够直接且毫无疑义地确定，UE在确定的UL子帧（由定时决定）上，使用确定的PUCCH资源（由资源分配决定）来发送HARQ ACK/NACK。这是实现HARQ反馈的必然步骤。因此，该特征被对比文件整体技术方案所隐含公开。 |
| **技术特征F：基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定HARQ‑ACK码本大小。**<br>**判断结果：未公开** | 无对应内容。 | 对比文件主要关注PUCCH**资源映射**（即具体的物理资源块分配）以避免冲突和提高效率。虽然[0056]-[0075]段详细讨论了HARQ-ACK比特的捆绑和码本构成（“オプションA”和“オプションB”），但该讨论的背景是**HARQ定时遵循参考配置**的前提下，如何优化在PUSCH或PUCCH格式3上反馈的HARQ-ACK比特集的构成，以减少冗余的“哑元”比特。其中，码本大小或比特数的确定是基于**参考配置**的DL关联集大小（见[0060]段），而不是基于动态UL-DL子帧配置。目标专利特征F明确将“确定HARQ-ACK码本大小”作为“基于动态UL-DL子帧配置来确定HARQ资源分配”的一部分。对比文件未公开此特定关联，也未教导基于动态配置来确定码本大小。 |
| **技术特征G：所述码本大小或ACK/NACK位的数目中的至少一者基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。**<br>**判断结果：未公开** | 无对应内容。 | 如特征F所述，对比文件中讨论的HARQ-ACK比特数目是基于**参考配置**的DL关联集大小（[0060]段）。虽然对比文件定义了“第三DL关联集（Set 3）”用于资源映射，但并未将Set 3的大小与HARQ-ACK码本大小或比特数目相关联。Set 3是用于确定物理PUCCH资源位置的，而码本大小是用于确定需要反馈的ACK/NACK信息量的，两者目的不同。对比文件未公开或暗示基于动态配置的DL关联集（即Set 3或其等效概念）的大小来确定码本大小或比特数目。 |
| **技术特征H：基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定物理上行链路控制信道PUCCH资源分配。**<br>**判断结果：直接公开** | [0020] 段： “第3のDLアソシエーションセットは、前記第2のDLアソシエーションセットにおけるサブフレームを有するが、前記第1のDLアソシエーションセットにおけるサブフレームのいくつかが除かれており、... 前記第3のDLアソシエーションセットにおけるサブフレームに対するPUCCHリソースの割り当てとを実行し”<br>**译文**： “第三DL关联集具有所述第二DL关联集中的子帧，但去除了所述第一DL关联集中的一些子帧，... 执行对所述第三DL关联集中的子帧的PUCCH资源分配” | 对比文件[0020]段明确记载了基于“第三DL关联集（Set 3）”来执行PUCCH资源分配。如特征D所述，Set 3的生成依赖于动态配置（通过从参考配置的集中去除与传统配置重叠的子帧）。因此，对比文件直接公开了“基于动态UL-DL子帧配置来确定PUCCH资源分配”这一技术手段。该手段在对比文件中用于避免PUCCH资源冲突并提高资源效率，与目标专利中为解决动态配置下的资源分配问题所起的作用相同。 |
| **技术特征I：所述物理上行链路控制信道PUCCH资源分配基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。**<br>**判断结果：隐含公开** | [0043] 段： “フレキシブルTDD UEのDLアソシエーションセット(セット3(603))は、サブフレーム#9(521)、#0(522)、#7(525)、#8(526)、#4(524)及び#3(523)のみを含む。”<br>结合[0020]段关于对Set 3进行PUCCH资源分配的记载。<br>**译文**： “灵活TDD UE的DL关联集（集3(603)）仅包括子帧#9(521)、#0(522)、#7(525)、#8(526)、#4(524)和#3(523)。” | 对比文件公开了PUCCH资源分配是基于“第三DL关联集（Set 3）”执行的（特征H）。而Set 3本身是一个DL关联集，其大小（即包含的子帧数量）直接取决于动态配置与传统配置的对比结果（见特征D论述）。因此，PUCCH资源分配所基于的那个DL关联集（Set 3），其大小是由动态UL-DL子帧配置决定的。本领域技术人员通过阅读对比文件，能够合理推断出“PUCCH资源分配基于一个DL关联集的大小，而该DL关联集的大小又基于动态配置”这一逻辑链。因此，该特征被隐含公开。 |
| **技术特征J：当确定所述DL关联集的所述大小时，集束集合中未被配置为所述动态UL‑DL配置中的DL的灵活子帧不被计及。**<br>**判断结果：直接公开** | [0045] 段： “図5におけるフレキシブルサブフレーム(523、524)に対するPUCCH予約は、特別な処置を必要とする。なぜならULサブフレームとして使用されるフレキシブルサブフレームに対するPUCCHリソース予約は、HARQ‑ACK送信のために使用されることはないからである。”<br>**译文**： “图5中对于灵活子帧(523、524)的PUCCH预留需要特殊处理。因为对于被用作UL子帧的灵活子帧的PUCCH资源预留，将不会被用于HARQ-ACK发送。” | 对比文件[0045]段明确指出，对于在动态配置中被用作上行链路（UL）子帧的灵活子帧，为其预留的PUCCH资源不会被使用。这意味着，在考虑为灵活TDD UE分配PUCCH资源时，那些在动态配置下实际上是UL子帧的灵活子帧，不应被计入需要分配资源的DL子帧集合中。这直接对应于目标专利特征J描述的“集束集合中未被配置为所述动态UL‑DL配置中的DL的灵活子帧不被计及”。该特征在对比文件中用于提高PUCCH资源利用效率，避免为无效的UL子帧预留资源，与目标专利中的作用相同。 |
| **技术特征K：包括通过移除UL子帧来确定所述集束集合中的剩余DL子帧的打包次序。**<br>**判断结果：隐含公开** | [0043] 段： “フレキシブルTDD UEのDLアソシエーションセット(セット3(603))は、サブフレーム#9(521)、#0(522)、#7(525)、#8(526)、#4(524)及び#3(523)のみを含む。” <br>结合图5和图6，Set 3中的子帧次序（#9, #0, #7, #8, #4, #3）与原始参考配置Set 2中的次序（#9, #0, #1, #3, #4, #5, #6, #7, #8）不同，子帧#1, #5, #6被移除。<br>**译文**： “灵活TDD UE的DL关联集（集3(603)）仅包括子帧#9(521)、#0(522)、#7(525)、#8(526)、#4(524)和#3(523)。” | 对比文件公开了Set 3是通过从Set 2中移除与传统UE的Set 1重叠的子帧（#1, #5, #6）得到的（[0043]段）。Set 1中的子帧在传统配置下是DL，但在动态配置下，这些子帧对于灵活TDD UE可能是DL也可能是UL。移除操作本身就隐含了“将那些在动态配置下对于灵活TDD UE是UL的子帧（或与UL冲突的子帧）从集合中移除”的逻辑。移除后，剩余的DL子帧（Set 3）形成了一个新的序列，这个序列可以视为一种“打包次序”。虽然对比文件没有明确使用“打包次序”这一术语，但本领域技术人员能够理解，在定义了用于资源映射的DL子帧新集合（Set 3）后，必然需要确定这些子帧在资源映射时的顺序，而该顺序自然由移除UL子帧后剩余子帧的排列决定。因此，该特征被隐含公开。 |
| **技术特征L：其中，固定DL子帧在所述剩余DL子帧的打包次序中被映射为第一个。**<br>**判断结果：未公开** | 无对应内容。 | 对比文件确实将Set 3中的子帧进一步分为固定DL/特殊子帧和灵活子帧（[0045]段），并对它们的资源映射进行独立处理（[0046]段）。但是，对比文件并未明确教导在“打包次序”或资源映射顺序中，固定DL子帧必须被映射为第一个。在[0046]段描述的选项1中，固定DL子帧的资源是按照Rel.10规范交织预留的，而灵活子帧的资源是另外一块预留的，两者是分开的，没有统一的“第一个”的概念。在选项2中，使用了UE特定的偏移。因此，对比文件未公开特征L的特定排序规则。 |
| **技术特征M：为能够支持动态UL‑DL子帧配置的UE和不能够支持动态UL‑DL子帧配置的UE配置分开的PUCCH区域。**<br>**判断结果：直接公开** | [0020] 段： “PUCCH領域が、前記第1のDLアソシエーションセットのPUCCH領域に続くか、又は、規定のPUCCHオフセットを使用するように、PUCCHリソースの割り当てを実行する”<br>[0046] 段（结合图5选项1）： “フレキシブルTDDUEのDLアソシエーションセットにおける固定のDL/スペシャルサブフレーム...についてのPUCCHリソースは、Rel.10仕様に従って、(532)としてPUCCH領域にインタリーブ及び予約される。” (532)在图5中位于传统UE的PUCCH区域(531)之后。<br>**译文**： [0020]“执行PUCCH资源分配，使得PUCCH区域跟随在所述第一DL关联集的PUCCH区域之后，或者使用规定的PUCCH偏移。” [0046]“对于灵活TDD UE的DL关联集中的固定DL/特殊子帧...的PUCCH资源，根据Rel.10规范，作为(532)被交织并预留到PUCCH区域中。” | 对比文件[0020]段明确提出了PUCCH资源分配的两种方式之一：使灵活TDD UE的PUCCH区域跟随在传统UE（第一类型UE）的PUCCH区域之后。这明确公开了为两种UE配置分开的（即相邻但不重叠的）PUCCH区域。图5选项1(530)直观展示了这一点，传统UE的PUCCH资源(531)和灵活TDD UE的固定子帧PUCCH资源(532)是分开的区块。该特征在对比文件中用于避免PUCCH资源冲突，与目标专利中的作用相同。 |
| **技术特征N：包括确定针对能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域与针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域之间是否存在潜在冲突。**<br>**判断结果：直接公开** | [0013] 段： “スペシャルサブフレーム#6(321)におけるレガシーUEと、DLサブフレーム#4(331)におけるフレキシブルTDD UEに対するPDCCHの最初のCCEインデックスが両方とも0であると仮定すると、それらは両方とも、PUCCH衝突を引き起こす動的PUCCH領域(すなわち、レガシーUEに対する(341)とフレキシブルTDD UEに対する(342))における最初のPUCCHにマッピングされる。”<br>**译文**： “假设传统UE在特殊子帧#6(321)和灵活TDD UE在DL子帧#4(331)的PDCCH的第一个CCE索引都是0，那么它们都被映射到动态PUCCH区域（即，传统UE的(341)和灵活TDD UE的(342)）中的第一个PUCCH，导致PUCCH冲突。” | 对比文件在[0013]段明确分析了PUCCH冲突发生的情景，即当传统UE和灵活TDD UE的PDCCH的起始CCE索引映射到相同的PUCCH资源时，会产生冲突。这实质上就是确定两种UE的PUCCH区域是否存在潜在冲突的过程。对比文件全文正是以识别和解决这一冲突问题为出发点的。因此，该特征被对比文件直接公开。 |
| **技术特征O：若没有检测到潜在冲突，则使用针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域。**<br>**判断结果：未公开** | 无对应内容。 | 对比文件提出的解决方案（如特征M所述）是为两种UE配置分开的PUCCH区域（一个在前，一个在后），或者使用规定的PUCCH偏移。这是预设的资源配置规则，旨在主动避免冲突，而不是在检测到“没有冲突”时才回退到使用传统UE的区域。对比文件没有描述根据冲突检测结果动态选择使用传统PUCCH区域的机制。因此，该特征未被公开。 |
| **技术特征P：若没有检测到潜在冲突，则为第一偏移值；以及若检测到潜在冲突，则为第二偏移值。**<br>**判断结果：未公开** | 无对应内容。 | 对比文件提到了使用“规定的PUCCH偏移”（[0020]段），但并未将该偏移值的选择与“是否检测到潜在冲突”这一条件相关联。偏移值似乎是预先配置或通过信令指示的，而非根据实时冲突检测结果动态切换。因此，该特征未被公开。 |
| **技术特征Q：指示动态上行链路‑下行链路UL‑DL子帧配置的所述信令包括动态信令。**<br>**判断结果：直接公开** | [0034] 段： “eNB(401)は、高速シグナリング手法を使用して、Rel.11以降のUE(404)のみとショートタームTDD UL‑DLコンフィグレーションを通信する。eNB(401)は、... DCI(Downlink Control Information:ダウンリンク制御情報)の形式でショートタームTDD UL‑DLコンフィグレーションを送信する。”<br>**译文**： “eNB(401)使用快速信令方法，仅与Rel.11及以后的UE(404)通信短期TDD UL-DL配置。eNB(401)以... DCI（下行链路控制信息）的形式发送短期TDD UL-DL配置。” | 对比文件明确将指示短期TDD UL-DL配置的信令描述为通过PDCCH/EPDCCH上的DCI发送的“高速信令”或“快速信令”。这完全符合本领域对“动态信令”（相对于半静态的RRC或SIB信令）的理解。该特征被直接公开。 |
| **技术特征R：所述动态信令经由以下至少一者来传达：用于发射功率控制TPC命令的下行链路控制信息DCI格式中的一个或多个位，或者一个或多个确收资源偏移ARO位。**<br>**判断结果：未公开** | 无对应内容。 | 对比文件[0034]段明确说明动态TDD配置是通过一种新的DCI格式发送的，该DCI的CRC使用特定的“eIMTA-RNTI”加扰。这表明动态配置信息是承载在专为此目的设计的DCI中的有效载荷字段，而非复用于现有DCI格式中的TPC或ARO位。对比文件没有提及使用TPC命令位或ARO位来传达动态配置信令。因此，该特征未被公开。 |
| **技术特征S：检测丢失的动态UL‑DL子帧配置；以及响应于所述检测，基于系统信息块SIB中信令通知的UL‑DL子帧配置来确定HARQ资源分配。**<br>**判断结果：未公开** | 无对应内容。 | 对比文件描述了UE通过盲检测DCI来获取动态配置（[0035]段），也提到了传统UE使用SIB1配置（[0036]段）。但是，对比文件完全没有涉及“检测动态配置丢失”的场景，也没有教导在此场景下回退到基于SIB配置来确定HARQ资源分配。回退机制是对目标专利说明书中提及的增强鲁棒性的方案，对比文件未公开此内容。 |
<<<B>>><<<H>>><<<J>>><<<M>>><<<N>>><<<Q>>>
<<<a>>><<<b>>><<<d>>><<<e>>><<<i>>><<<k>>>