返回项目页面
对比文件列表
2005-11-17_JP2005323366A_发明专利_JP2005323366A Method and apparatus for changing tti based on harq process in enhanced uplink dedicated channel_+++B_E_F_H_I_J_K_M_N_Q_l_s+++.docx
2026-06-17 01:30
2009-03-12_US2009067364A_发明申请_US20090067364A1 APPARATUS AND METHOD FOR DETERMINING TIME TO RESPONSE OF RETRANSMISSION IN A MULTIHOP RELAY WIRELESS COMMUNICATION SYSTEM_+++H_I_a_b_c_d_e_f_j_k_l_p_t+++.docx
2026-06-17 01:30
2009-05-06_EP2056512A_发明公开_EP2056512A2 Apparatus and method for determining time to response of retransmission in a multihop relay wireless comunication system_+++A_B_C_D_G_H_I_J_K_L_e_f_p_t+++.docx
2026-06-17 01:30
2009-09-10_JP2009206846A_发明专利_JP2009206846A Data communication retransmission control method, and transmitting_receiving device_+++C_E_H_I_d_f+++.docx
2026-06-17 01:30
2012-10-24_CN102752090A_发明公开_CN102752090A 一种支持PUSCH的同步HARQ传输的方法_+++E_F_I_J_K_L_M_h+++.docx
2026-06-17 01:30
2012-10-25_US2012269180A_发明申请_US20120269180A1 METHOD AND APPARATUS FOR SUPPORTING SYNCHRONOUS HARQ TRANSMISSION_+++E_F_H_I_J_K_M_g_l_p+++.docx
2026-06-17 01:30
2014-02-26_EP2700185A_发明公开_EP2700185A2 METHOD AND APPARATUS FOR SUPPORTING SYNCHRONOYS HARQ TRANSMISSION_+++E_F_I_J_K_a_b_h_l+++.docx
2026-06-17 01:30
2014-04-03_US2014092788A_发明申请_US20140092788A1 METHOD AND APPARATUS FOR TRANSMITTING AND RECEIVING DATA IN MOBILE COMMUNICATION SYSTEM_+++C_D_E_F_I_J_K_M_b_h_q_s+++.docx
2026-06-17 01:30
2014-04-03_WO2014051407A_发明申请_WO2014051407A1 METHOD AND APPARATUS FOR TRANSMITTING AND RECEIVING DATA IN MOBILE COMMUNICATION SYSTEM_+++C_E_F_I_J_K_q+++.docx
2026-06-17 01:30
KR20140042416A_Description_20260426_1244_+++B_C_D_E_F_I_J_K_M_q_t+++.docx
2026-06-17 01:30
WO2012144772A2_Description_20260426_1245_+++E_F_I_J_K_a_b_h_l_o_p_s+++.docx
2026-06-17 01:30
WO2012144772A2_Description_20260426_1245_+++E_F_I_J_K_a_b_h_l_o_p_s+++.docx

好的,请稍等。作为一名资深专利代理师,我将基于您提供的详细要求和材料,对对比文件是否公开目标专利权利要求的各技术特征进行严谨的评估。

首先,明确本次评估的文档和模型信息如下:

* **对比文件名称:** WO2012144772A2_Description_20260426_1245

* **目标专利名称:** 750通信中的混合自动重传请求定时CN106165330B

* **本次调用的模型名称:** 您未指定模型名称,我假设为通用高级模型进行推理。

以下是根据您的要求进行的特征比对分析。

### 特征比对表格

技术特征描述以及公开性判断结果对比文件原文引用 (翻译成中文)公开性论述
**技术特征A:** 所述方法包括:在网络装置中并且基于用户终端的能力,在可用的多个混合自动重传请求简档之中定义针对所述用户终端的混合自动重传请求,<br><br>**《隐含公开》****对比文件段落引用:** <br>在描述图6及相关表格时,文中多处提及处理时间(processing time)的概念,例如:<br>“当Scell采用上下行配置1、3或4时,可能会出现上述情况。” (对应图6的描述)<br>“在这种情况中,不满足处理时间要求的情形不能用于上行传输,或者这些情形可以取决于BS的实现而被支持。例如,如果BS完全有能力在3ms内完成该过程,则可以调度这些Scell的上行子帧。如果BS无法在3ms内完成该过程,则不能调度这些Scell的上行子帧。” (对应图6的描述及对表9-13、14-16、17-18、19-22、23-29、30-34、35-40、41-42的类似描述) <br>“UE接收PDCCH和PHICH,解码上行数据的操作较简单,并且PDCCH和PHICH位于下行子帧的前3个OFDM符号中。UE无需等待整个下行子帧结束即可解码PDCCH和PHICH,从而UE有更多时间处理PDCCH和PHICH。” (在实施例2中的描述)**论述:** 目标专利的技术特征A强调“基于用户终端的能力”定义HARQ简档。对比文件虽未明确使用“HARQ简档”一词,但其核心在于为不同场景(特别是跨载波调度下不同小区配置组合)配置不同的定时关系。对比文件明确提出了“处理时间(processing time)”的概念,例如,对于BS接收PUSCH的处理时间(3ms vs 4ms),其指出能否使用取决于“BS的实现”或“BS完全有能力在3ms内完成该过程”。这直接隐含了定时关系的配置(即HARQ定时简档)与通信节点(此处为BS)的处理能力紧密相关。此外,对比文件提到“UE无需等待整个下行子帧结束...从而UE有更多时间处理...”,也暗示了UE的能力(处理速度)会影响其对定时关系的响应。因此,虽然对比文件没有明确将“UE能力”作为选择HARQ简档的唯一或首要依据,但其内容明确揭示了定时关系的配置需要考虑通信节点(BS/UE)的处理能力。本领域技术人员可以合理推断出,定义不同的定时关系(简档)是“基于用户终端的能力”的。因此,该特征被对比文件隐含公开。
**技术特征B:** 所述多个混合自动重传请求简档至少在所述用户终端和基站之间的通信链路的一端处提供不同的处理时间,<br><br>**《隐含公开》****对比文件段落引用:** <br>“当Scell采用上下行配置1、3或4时,可能会出现上述情况...不满足处理时间要求的情形...可以取决于BS的实现而被支持。例如,如果BS完全有能力在3ms内完成该过程,则可以调度这些Scell的上行子帧。” (对应图6描述及多个表格描述) <br>“在表14-16中,BS接收PUSCH的处理时间被缩短了。具体地,当Scell采用上下行配置1或2时,Scell可能会遇到上述情况。” (对表14-16的描述) <br>“UE接收PDCCH和PHICH...UE有更多时间处理PDCCH和PHICH。” (在实施例2中的描述)**论述:** 目标专利的特征B指出多个简档提供“不同的处理时间”。对比文件明确描述了多种定时关系配置,这些配置导致了“处理时间”的不同。例如,对比文件反复提及在特定配置组合下,BS接收PUSCH的处理时间从标准的4ms缩短为3ms(例如,图6及相关描述:“即BS发送PHICH的定时与UE发送PUSCH的定时之间的间隔是三个子帧(3ms),这小于LTE和LTE-A中提供的4ms的处理时间”)。这直接体现了在通信链路的一端(此处为BS)提供了不同的处理时间。虽然对比文件主要讨论的是BS端处理时间的差异,但其也提及了UE端接收PDCCH/PHICH的处理时间可以因“有更多时间”而不同。因此,对比文件公开了“提供不同的处理时间”这一概念,尽管其没有明确使用“多个简档”的术语,但不同的定时关系配置实质上构成了不同的处理时间简档。本领域技术人员可以合理推断,这些不同的配置即为目标专利所述的提供不同处理时间的HARQ简档。因此,该特征被对比文件隐含公开。
**技术特征C:** 其中所述混合自动重传请求简档指示:-下行链路传输在所述用户终端中被接收与对应的上行链路控制信息被预期从所述用户终端被发射之间的第一时间间隔,<br><br>**《未公开》****对比文件段落引用:** <br>全文主要关注上行链路PUSCH的HARQ定时,定义了从PDCCH/PHICH到PUSCH,以及从PUSCH到PHICH的定时关系。未找到描述下行数据接收与上行HARQ反馈(ACK/NACK)之间定时关系的明确内容。**论述:** 目标专利的特征C和D共同定义了一个针对“下行链路传输”的HARQ简档,描述了从“接收下行数据”到“发送上行ACK/NACK”再到“接收下行重传”的完整下行HARQ流程的定时。对比文件WO2012144772A2的全部内容均围绕着上行链路PUSCH的HARQ传输,其核心定时关系包括:1)PDCCH(调度授权)/PHICH(HARQ指示)到PUSCH(上行数据)的定时;2)PUSCH到PHICH的定时。这些均属于上行HARQ的范畴。对比文件中没有定义或提及任何关于“下行链路传输在用户终端中被接收”与“对应的上行链路控制信息被预期从用户终端被发射”之间的时间间隔。本领域技术人员无法从对比文件中毫无疑义地得出或合理推断出该下行HARQ的定时间隔。因此,技术特征C未被对比文件公开。
**技术特征D:** 以及-所述上行链路控制信息从所述用户终端被发射与对应的下行链路重传被预期最早在所述用户终端中被接收之间的第二时间间隔<br><br>**《未公开》****对比文件段落引用:** <br>同上,全文未涉及下行HARQ流程的定时。**论述:** 基于与特征C相同的理由,特征D是下行HARQ流程中的另一段定时。对比文件仅涉及上行HARQ流程,未公开任何关于“上行控制信息发射后,何时最早接收下行重传”的定时关系。因此,技术特征D未被对比文件公开。
**技术特征E:** 或者其中所述混合自动重传请求简档指示:-上行链路传输在基站中被接收与对应的下行链路信息被预期从所述基站被发射之间的第三时间间隔,<br><br>**《直接公开》****对比文件段落引用:** <br>“然后,将介绍LTE和LTE-A中从PUSCH到PHICH的定时关系。”<br>“对于上下行配置1-6,当UE在下行子帧i中接收到PHICH时,该PHICH指示上行子帧i-k中的PUSCH的ACK/NACK,k的值如下表4示例所示。”<br>“当Pcell采用上下行配置0时...接收到PUSCH后,根据从PUSCH到PHICH的定时关系在主小区中发送PHICH...”(步骤303描述) <br>“例如,对于在PUSCH的上行子帧n中发送的PUSCH,根据表4所示的LTE和LTE-A中从PUSCH到PHICH的定时关系,确定PHICH在下行子帧n+p中发送...” (步骤2描述)**论述:** 目标专利的特征E定义了上行HARQ简档中的一个时间间隔:“上行链路传输(PUSCH)在基站中被接收”与“对应的下行链路信息(即HARQ反馈,如PHICH上的ACK/NACK)被预期从基站被发射”之间的第三时间间隔。对比文件明确且详尽地定义了“从PUSCH到PHICH”的定时关系。例如,对比文件指出“当UE在下行子帧i中接收到PHICH时,该PHICH指示上行子帧i-k中的PUSCH的ACK/NACK”,这直接定义了PUSCH传输与PHICH反馈之间的固定关系。该关系在对比文件中以表格形式(如Table 4)呈现,定义了具体的子帧偏移量(k值)。这个偏移量所代表的时间间隔,正是目标专利所述的“第三时间间隔”。该特征在对比文件中起到的作用与在目标专利中相同,即定义上行数据接收与下行HARQ反馈之间的定时,以实现同步HARQ操作。因此,技术特征E被对比文件直接公开。
**技术特征F:** 以及-所述下行链路信息从所述基站被发射与对应的上行链路重传被预期最早在所述基站中被接收之间的第四时间间隔。<br><br>**《直接公开》****对比文件段落引用:** <br>“首先,将介绍从PDCCH和PHICH到PUSCH的定时关系。”<br>“对于从PDCCH到PUSCH的定时关系,假设UE在下行子帧n中接收到PDCCH,该PDCCH控制上行子帧n+k中的PUSCH。k的值定义在下面的表2中。”<br>“对于从PHICH到PUSCH的定时关系,在LTE和LTE-A中,每个上行子帧的PUSCH被分配一个单独的PHICH资源集。假设UE在下行子帧n中接收到PHICH,该PHICH控制上行子帧n+k中的PUSCH。k的值定义如下面的表3示例所示。”<br>“BS在主小区中根据从PUSCH到PHICH的定时关系发送PHICH,并根据从PHICH到PUSCH的定时关系接收辅小区中的重传PUSCH”(步骤303描述)**论述:** 目标专利的特征F定义了上行HARQ简档中的另一个时间间隔:“下行链路信息(PHICH/PDCCH)从基站被发射”与“对应的上行链路重传被预期最早在基站中被接收”之间的第四时间间隔。对比文件也详尽定义了“从PHICH/PDCCH到PUSCH”的定时关系。例如,对比文件指出“假设UE在下行子帧n中接收到PHICH,该PHICH控制上行子帧n+k中的PUSCH”,并给出了具体的k值。这个从接收PHICH到发送(重传)PUSCH的时间间隔,正是目标专利所述的“第四时间间隔”。对比文件明确用该定时关系来控制PUSCH的重传,其作用与目标专利完全相同。因此,技术特征F被对比文件直接公开。
**技术特征G:** 其中所述混合自动重传请求简档在对小区的初始接入期间被预定义或被定义。<br><br>**《未公开》****对比文件段落引用:** <br>全文未提及“初始接入”或“预定义”HARQ定时简档。对比文件中的定时关系是基于LTE/LTE-A标准中已定义的关系,或是针对跨载波调度中不同小区配置组合而“配置”或“重配置”的,但未提及这些配置发生在“对小区初始接入期间”。**论述:** 对比文件描述了在BS配置UE进入CA模式后,根据Pcell和Scell的不同配置来确定定时关系。这个过程发生在UE已连接并配置了CA之后,并非在“对小区初始接入期间”。对比文件没有公开或暗示HARQ定时简档是在初始接入时定义或预定义的。因此,技术特征G未被对比文件公开。
**技术特征H:** 其中所述方法还包括:通过调节为处理所述系统中的数据和相关控制信号而预留的时间来提供灵活的混合自动重传请求定时。<br><br>**《隐含公开》****对比文件段落引用:** <br>“当Scell采用上下行配置1、3或4时,可能会出现上述情况。在这种情况中,不满足处理时间要求的情形...可以取决于BS的实现而被支持。例如,如果BS完全有能力在3ms内完成该过程,则可以调度这些Scell的上行子帧。” (图6及相关描述) <br>“在表14-16中,BS接收PUSCH的处理时间被缩短了...为了满足BS接收PUSCH的处理时间,保证从接收PUSCH的上行子帧到发送对应PUSCH的PHICH的下行子帧之间的时间间隔大于4ms...” (对表23-25的描述) <br>“为了最小化收发器调制解调器部分的‘接通时间’,尽可能快速地传达数据通常是最功率高效的。” (对比文件无此句,此句来自目标专利,但对比文件有类似概念)**论述:** 目标专利的特征H核心是“通过调节为处理...而预留的时间”来实现“灵活的HARQ定时”。对比文件虽然没有使用相同的措辞,但其整个发明构思就是通过在不同场景下配置不同的定时关系,来实现灵活的上行HARQ传输。特别是,对比文件多次提到“处理时间(processing time)”可以被缩短(例如从4ms到3ms),并指出这种缩短是基于BS的实现能力。这本质上就是通过调节(缩短)为处理数据和控制信号(如解码PUSCH、生成PHICH)而预留的时间,从而提供了非固定的、灵活的HARQ定时。本领域技术人员可以合理推断,这种对处理时间的调节就是对预留处理时间的调节。因此,该特征被对比文件隐含公开。
**技术特征I:** 其中所述上行链路控制信息和所述下行链路信息中的至少一个包括确认消息或者否定确认消息。<br><br>**《直接公开》****对比文件段落引用:** <br>“LTE TDD系统支持混合自动重传请求(HARQ)机制...BS接收上行数据并向UE发送HARQ指示信息...”<br>“BS在物理HARQ指示信道(PHICH)中承载HARQ指示信息。”<br>“当UE在下行子帧i中接收到PHICH时,该PHICH指示上行子帧i-k中的PUSCH的ACK/NACK”。**论述:** 目标专利的特征I指出控制信息包括ACK/NACK。对比文件明确将PHICH定义为承载“HARQ指示信息”,并直接说明该信息是“ACK/NACK”。无论是上行控制信息(如PUCCH上的ACK/NACK,尽管对比文件未详述)还是下行信息(PHICH),其核心内容就是确认(ACK)或否定确认(NACK)消息。对比文件中PHICH的作用正是承载ACK/NACK,这与目标专利中对应特征的作用完全相同。因此,技术特征I被对比文件直接公开。
**技术特征J:** 其中所述上行链路传输包括上行链路被调度的消息。<br><br>**《直接公开》****对比文件段落引用:** <br>“UE在物理上行共享信道(PUSCH)中承载上行数据...”<br>“BS在物理下行控制信道(PDCCH)中承载PUSCH调度和控制信息...”<br>“该PDCCH控制上行子帧n+k中的PUSCH。”**论述:** 目标专利的特征J指出上行传输是“上行链路被调度的消息”。对比文件中的“PUSCH”即是UE在接收到BS的调度授权(PDCCH)后发送的上行数据信道,完全符合“上行链路被调度的消息”的定义。对比文件通篇都在讨论PUSCH的HARQ传输。因此,技术特征J被对比文件直接公开。
**技术特征K:** 其中所述下行链路信息包括上行链路调度授权消息。<br><br>**《直接公开》****对比文件段落引用:** <br>“BS在物理下行控制信道(PDCCH)中承载PUSCH调度和控制信息...”<br>“假设UE在下行子帧n中接收到PDCCH,该PDCCH控制上行子帧n+k中的PUSCH。”**论述:** 目标专利的特征K指出下行信息包括“上行链路调度授权消息”。对比文件中的“PDCCH”承载的“PUSCH调度和控制信息”正是用于授权UE进行上行传输的调度授权消息。该PDCCH的作用是调度PUSCH,与目标专利中“上行链路调度授权消息”的作用完全相同。因此,技术特征K被对比文件直接公开。
**技术特征L:** 其中所述混合自动重传请求简档是以下中的一个或多个:设备特定的、设备类型特定的、小区特定的和服务类型特定的。<br><br>**《隐含公开》****对比文件段落引用:** <br>“当Scell采用上下行配置1、3或4时,可能会出现上述情况。在这种情况中,不满足处理时间要求的情形...可以取决于BS的实现而被支持。” (暗示简档与BS设备能力相关)<br>“UE接收PDCCH和PHICH...UE有更多时间处理PDCCH和PHICH。” (暗示与UE类型或能力相关) <br>对比文件的核心在于,当Pcell和Scell采用不同的“上下行配置(uplink/downlink configurations)”时,需要配置不同的HARQ定时。不同的上下行配置是“小区特定(cell-specific)”的参数。**论述:** 目标专利的特征L指出HARQ简档可以是设备、设备类型、小区或服务类型特定的。对比文件虽然没有直接列出这些类别,但其教导的内容强烈暗示了这种特定性。首先,对比文件大量讨论不同小区配置(如Pcell配置0, Scell配置1)下的不同定时关系,这本身就是“小区特定”的。其次,对比文件提到配置可能取决于BS的实现能力(BS设备特定),也提到UE处理时间可以不同(隐含UE类型特定)。虽然对比文件没有明确说“为某类设备定义特定简档”,但其整个系统就是为不同配置(小区特定)和不同处理能力(隐含设备特定)提供不同定时。本领域技术人员可以合理推断出,这些不同的定时关系配置即为特定的HARQ简档。因此,该特征被对比文件隐含公开。
**技术特征M:** 其中定义所述混合自动重传请求简档中涉及的可变数目或固定数目的不同的混合自动重传请求进程。<br><br>**《未公开》****对比文件段落引用:** <br>“图2图示了传统的跨载波调度和非跨载波调度...上行子帧中的数字表示同步HARQ进程号...” <br>全文均基于LTE TDD中固定数目的同步HARQ进程进行操作,例如图2、图4、图5中均标注了HARQ进程号(0-7或类似),未提及进程数目可以改变。**论述:** 目标专利的特征M明确提到了“可变数目或固定数目的...HARQ进程”。对比文件中的HARQ操作完全是基于LTE TDD的同步HARQ,其进程数是固定的(例如,根据上下行配置,为7或4等)。对比文件虽然定义了多种不同的定时关系,但并未提及或暗示HARQ进程的数目可以随之变化,也没有提及可变数目的HARQ进程这个概念。其所有示例中的进程编号都是基于固定数目体系。因此,技术特征M未被对比文件公开。
**技术特征N:** 其中所述方法还包括:定义针对所述混合自动重传请求简档中涉及的不同的混合自动重传请求进程的可变传输时间间隔TTI长度。<br><br>**《未公开》****对比文件段落引用:** <br>全文未提及“传输时间间隔(TTI)长度”可变的概念。对比文件中的子帧长度是固定的(1ms),TTI长度等同于子帧长度,也是固定的。**论述:** 目标专利的特征N提出了“可变TTI长度”的概念。对比文件全文基于LTE TDD标准,其基本时间单位是固定的子帧(1ms),TTI长度也是固定的。对比文件的所有定时关系都是基于子帧索引(n, k等)进行定义,没有任何内容涉及或暗示TTI长度可以变化。因此,技术特征N未被对比文件公开。
**技术特征O:** 其中多个混合自动重传请求简档共存于包括频率和时间资源的共同资源空间中。<br><br>**《隐含公开》****对比文件段落引用:** <br>“本发明涉及多个CA小区采用不同上下行配置时的情况...BS配置UE在一个或多个小区(部分或全部)上操作。”<br>“当多个实现CA的小区间的频域距离足够长时,这些小区可以采用不同的上下行配置而不会相互干扰。”<br>全文描述的跨载波调度场景中,Pcell和Scell的物理资源(时频)是共存于同一系统带宽内的。**论述:** 目标专利的特征O要求“多个HARQ简档”共存于“共同资源空间”。对比文件描述的场景是载波聚合(CA),其中多个小区(Pcell和Scell)使用不同的上下行配置,并在同一系统内共存。这些小区使用不同的频率资源(分量载波),但共享同一时间轴。对比文件中,针对不同小区配置(这可以理解为不同的HARQ定时简档)的UE,其数据传输在时频资源上是共存并复用的。虽然对比文件没有明确说“HARQ简档共存”,但其描述的CA系统本质就是不同配置(简档)的小区在共同资源空间(系统频带、时间帧)内操作。本领域技术人员可以合理推断,这就是多个HARQ简档在共同资源空间中共存。因此,该特征被对比文件隐含公开。
**技术特征P:** 其中所述方法还包括:定义所述用户终端是具有快速响应能力的用户终端或者所述用户终端是具有较低的混合自动重传请求回路延迟能力的用户终端。<br><br>**《隐含公开》****对比文件段落引用:** <br>“UE接收PDCCH和PHICH...UE无需等待整个下行子帧结束即可解码PDCCH和PHICH,从而UE有更多时间处理PDCCH和PHICH。” (暗示了有快速处理能力的UE) <br>“在这种情况中,不满足处理时间要求的情形不能用于上行传输,或者这些情形可以取决于BS的实现而被支持...如果BS完全有能力在3ms内完成该过程,则可以调度这些Scell的上行子帧。如果BS无法在3ms内完成该过程,则不能调度这些Scell的上行子帧。” (隐含了BS的处理能力导致不同的回路延迟)**论述:** 目标专利的特征P是将UE定义为具有不同HARQ回路延迟能力(快速响应或较低能力)。对比文件虽然没有直接使用这样的分类术语,但其内容明确揭示了不同节点具有不同的处理能力,并因此影响HARQ定时。它指出UE可以“有更多时间处理”,暗示了处理速度快的UE与处理速度慢的UE存在差异。更重要的是,它多次提到定时配置取决于BS能否在“3ms内完成该过程”,这定义了BS的“回路延迟能力”。虽然对比文件主要讨论BS,但其对处理能力的区分原则同样适用于UE。本领域技术人员可以合理推断,存在具有不同HARQ回路延迟能力的UE,并且系统可以据此进行区分或定义。因此,该特征被对比文件隐含公开。
**技术特征Q:** 其中所述方法还包括:响应于所述系统中的预定事件,在活跃会话期间针对所述用户终端动态地重新配置混合自动重传请求回路延迟。<br><br>**《未公开》****对比文件段落引用:** <br>全文未提及“活跃会话期间动态重新配置”回路延迟。对比文件中的定时关系是基于BS对UE的初始CA配置而确定的,或者在规范中预先定义好的。虽然不同配置(简档)存在,但没有教导在同一个活跃会话中,响应于某个事件而动态切换。**论述:** 目标专利的特征Q的核心在于“动态重新配置”。对比文件中,HARQ定时关系是在UE被配置CA模式时确定的,或者是在标准中为特定配置组合而固定的。没有描述在UE已经处于活跃会话(例如,正在进行数据传输)时,由于某个事件(如信道条件变化、负载变化)触发,而动态地将UE从一个HARQ定时简档切换到另一个。对比文件的内容是静态的或半静态的配置,而非动态的、事件触发的重新配置。因此,技术特征Q未被对比文件公开。
**技术特征R:** 其中所述方法还包括:定义针对具有不同的混合自动重传请求简档的用户终端的共享控制信道中的分离的HARQ-ACK控制信道部分。<br><br>**《未公开》****对比文件段落引用:** <br>全文未提及“共享控制信道”或“分离的HARQ-ACK控制信道部分”。对比文件中的HARQ反馈是通过PHICH(一个专用信道)或PUCCH(对于下行HARQ,对比文件未详述)进行的,但没有涉及为不同HARQ简档的UE在同一共享控制信道中划分不同部分的概念。**论述:** 目标专利的特征R涉及控制信道资源划分的特定技术。对比文件没有公开或暗示任何关于为不同HARQ定时的UE在共享控制信道(如PUCCH区域)内划分“分离的HARQ-ACK控制信道部分”的内容。对比文件关注的是定时关系本身,而非反馈信道的资源复用方式。因此,技术特征R未被对比文件公开。
**技术特征S:** 其中所述方法还包括:根据所述混合自动重传请求简档,定义混合自动重传请求缓冲器每子帧的大小与混合自动重传请求进程的最大数目中的至少一个。<br><br>**《隐含公开》****对比文件段落引用:** <br>“图2图示了传统的跨载波调度和非跨载波调度...上行子帧中的数字表示同步HARQ进程号...” (显示了HARQ进程的存在) <br>“HARQ传输处理单元712被配置为包括至少一个HARQ传输进程...”(图7描述,暗示了需要缓冲器来支持这些进程)<br>虽然对比文件没有直接说明,但HARQ操作必然需要缓冲器来存储等待重传的数据块。进程数的不同自然会导致所需缓冲器大小的不同。**论述:** 目标专利的特征S将HARQ缓冲器大小或进程最大数目与“HARQ简档”关联。对比文件虽然没有直接表述这种关联,但这是HARQ操作的固有属性。不同的HARQ定时简档,特别是当涉及不同数目的HARQ进程(如特征M所述,虽然对比文件未公开可变进程数,但其有固定进程数)或不同的回路延迟时,为了支持连续的数据传输,所需的HARQ进程数目和相应的缓冲器大小必然是变化的。本领域技术人员可以理解,如果定义了不同的HARQ定时简档(如对比文件中的不同定时配置),那么为了支持这些简档下的连续传输,HARQ进程的最大数目和所需的缓冲器大小必然也需要相应地调整。因此,该特征虽然未被明示,但可以从对比文件公开的HARQ操作原理中合理推断出来。因此,该特征被对比文件隐含公开。
**技术特征T:** 其中所述方法还包括:定义针对所述用户终端的双向混合自动重传请求简档,所述双向混合自动重传请求简档包括针对所述用户终端的下行链路混合自动重传请求简档和上行链路混合自动重传请求简档。<br><br>**《未公开》****对比文件段落引用:** <br>全文仅涉及上行链路(PUSCH)的HARQ传输和定时。虽然其提到了下行控制信道(PDCCH)和下行反馈信道(PHICH),但这些都是为了控制和反馈上行数据的传输。对比文件没有定义任何关于下行数据(PDSCH)的HARQ流程的定时关系。**论述:** 目标专利的特征T提出了“双向HARQ简档”的概念,即同时包含下行和上行HARQ简档。对比文件WO2012144772A2的标题和内容均明确限定于“支持上行数据的同步HARQ传输”。其定义的所有定时关系(PDCCH/PHICH到PUSCH,PUSCH到PHICH)都是上行HARQ流程的一部分。它完全没有涉及下行HARQ流程(即接收PDSCH、发送PUCCH上的ACK/NACK、接收重传PDSCH)的任何定时关系。因此,对比文件既没有单独公开下行HARQ简档(特征C、D),更没有公开将下行和上行HARQ简档组合成一个“双向”简档的概念。因此,技术特征T未被对比文件公开。

### 总结与代码输出

根据上述严谨的逐项分析,判断结果如下:

* **直接公开的特征:** E, F, I, J, K

* **隐含公开的特征:** A, B, H, L, O, P, S

* **未公开的特征:** C, D, G, M, N, Q, R, T

因此,在回答结尾插入的代码为:

<<<E>>> <<<F>>> <<<I>>> <<<J>>> <<<K>>> <<<a>>> <<<b>>> <<<h>>> <<<l>>> <<<o>>> <<<p>>> <<<s>>>

权利要求与技术特征
Powered by Django

网站备案号:渝ICP备2023012882号


重庆市非显而易见网络科技有限责任公司 A Anti NPE NPE