**对比文件名称：** TW201729554A_专利详情
**特征比对表格**
| 技术特征描述 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：在侧行链路上接收至少一个侧行链路通信。<br>**公开性判断**：未公开 | 对比文件未提及“侧行链路(sidelink)”、“PC5接口”或设备间直接通信。其通信场景均围绕UE与基站之间的上下行链路（接入链路）。例如，说明书第[0070]段描述了“接收对用于与基站进行通信的指派的资源的指示”。 | **作用对比分析**：<br>在目标专利中，特征A是执行侧行链路反馈的前提，其作用是在设备间直接通信的链路上接收信息，以触发后续的反馈。对比文件的技术方案聚焦于UE与基站之间的蜂窝通信链路（Uu接口），用于确定数字方案并生成序列，其作用是优化在混合数字方案下的参考信号或扰码生成，以支持基站与UE之间的可靠通信。两者通信链路类型（侧行链路 vs. 接入链路）及在整个方案中的基础作用均不相同。因此，对比文件未公开技术特征A。 |
| **技术特征B**：所述至少一个侧行链路通信包括以下各项中的至少一项：授权、多阶段授权、多分组授权、或中继通信。<br>**公开性判断**：未公开 | 对比文件提到了“授权”，例如说明书第[0070]段：“所述指示包括下行链路指派”和第[0071]段：“所述指示包括上行链路授权”。但未提及“多阶段授权”、“多分组授权”或“中继通信”。 | **作用对比分析**：<br>在目标专利中，特征B限定了触发反馈的通信类型，特别是复杂授权模式（多阶段、多分组）或中继场景，其作用是为后续合并多个确认反馈提供具体的应用场景和需求。对比文件中提到的“下行链路指派”或“上行链路授权”是传统的、单次的基站调度授权，其作用是分配资源以供UE与基站进行上下行数据传输。两者虽都涉及“授权”，但授权模式、复杂程度以及在各自技术方案中解决的问题（复杂反馈合并 vs. 资源分配与序列生成）有本质区别。因此，对比文件未公开技术特征B。 |
| **技术特征C**：在所述侧行链路或上行链路上发送包括多个确认的反馈消息。<br>**公开性判断**：隐含公开 | 说明书第[0037]段（对应图2B描述）：“物理混合自动重传请求(ARQ)(HARQ)指示符信道(PHICH)也位于时隙0的符号0内，并携带用于指示基于物理上行链路共享信道(PUSCH)的HARQ确认(ACK)/否定ACK(NACK)反馈的HARQ指示符(HI)。” | **作用对比分析**：<br>在目标专利中，特征C是核心，其作用是将针对多个侧行链路通信（如多个授权或数据包）的确认合并到一个反馈消息中发送，以节省信令开销，解决侧行链路场景下多确认反馈导致的资源过度使用问题。<br>在对比文件中，PHICH信道用于在上行链路上向UE发送针对其PUSCH传输的HARQ ACK/NACK反馈。虽然对比文件未明确描述“多个确认”，但HARQ机制本身天然包含对多个传输块进行确认的可能性（例如，在载波聚合或多码字传输中）。PHICH信道的作用就是传送这种确认信息，以确保上行数据传输的可靠性。尽管应用场景（上行链路反馈给UE vs. 侧行链路/上行链路反馈给对等设备或基站）和针对的通信类型（PUSCH vs. 侧行链路通信）不同，但“发送包括确认的反馈消息”这一技术手段及其“提供传输可靠性反馈”的基础作用是相同的。对于本领域技术人员而言，在对比文件公开的上行链路HARQ反馈机制的基础上，能够理解“反馈消息可以包含确认”以及“该消息可在上行链路上发送”。因此，技术特征C在对比文件中被隐含公开。 |
| **技术特征D**：所述多个确认中的至少一个是针对在所述侧行链路上接收到的所述授权、所述多阶段授权、所述多分组授权或所述中继通信的。<br>**公开性判断**：未公开 | 对比文件未提及针对“侧行链路上接收到的授权、多阶段授权、多分组授权或中继通信”进行确认。其HARQ反馈（如PHICH）是针对UE在PUSCH上发送的数据，而非针对侧行链路通信。 | **作用对比分析**：<br>在目标专利中，特征D进一步限定了反馈消息中确认的具体对象，即侧行链路上接收到的特定类型的通信内容，其作用是明确反馈的源头和场景，与特征A、B共同定义了侧行链路反馈的完整闭环。对比文件中的确认反馈对象是UE上行传输的数据，与侧行链路通信无关。两者确认的对象和所服务的通信链路完全不同。因此，对比文件未公开技术特征D。 |
<<<c>>>