对比文件名称：发明授权_EP2761955B1 DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH
目标专利名称：用于窄带操作的上行链路和下行链路授权
模型名称：本次评估由具备专利创造性评估经验的资深专利代理师执行。
以下是根据目标专利权利要求的技术特征划分，与对比文件EP2761955B1进行比对的特征比对表格：
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：一种用于由用户设备(UE)进行无线通信的方法<br>**公开性判断**：《直接公开》 | [0005] Systems and/or methods may be provided for supporting reduced channel bandwidth in wireless communications between devices such as UEs (e.g. including a low LTE UE category device) and/or low cost Machine-Type Communications (MTC) devices and networks that may support a full bandwidth (e.g. a full bandwidth network). For example, in one embodiment, a device may receive inband assignments such as downlink assignments and/or uplink grants. Based on such inband assignments, the device may monitor and/or decide one or more transmissions that may be provided by the network (e.g. in the narrow or reduced channel bandwidth).<br>译文：[0005] 可以提供系统和/或方法以支持设备（例如UE（包括低LTE UE类别设备）和/或低成本机器类型通信（MTC）设备）与可以支持全带宽（例如全带宽网络）的网络之间的无线通信中的减少的信道带宽。例如，在一个实施例中，设备可以接收带内分配，例如下行链路分配和/或上行链路授权。基于这种带内分配，该设备可以监视和/或决定网络可以提供一个或多个传输（例如在窄的或减少的信道带宽中）。 | 该技术特征限定了方法的执行主体为UE。对比文件[0005]段明确记载了其系统和方法涉及UE（用户设备）和/或低成本MTC设备与网络之间的无线通信，并且描述了由设备（即UE）执行接收下行链路分配/上行链路授权并基于此进行监视/决定的动作。因此，对比文件直接公开了由UE执行无线通信方法的技术特征。 |
| **技术特征B**：针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道<br>**公开性判断**：《直接公开》 | [0005] ... a device may receive inband assignments such as downlink assignments and/or uplink grants. Based on such inband assignments, the device may monitor and/or decide one or more transmissions that may be provided by the network (e.g. in the narrow or reduced channel bandwidth).<br>译文：[0005] ... 设备可以接收带内分配，例如下行链路分配和/或上行链路授权。基于这种带内分配，该设备可以监视和/或决定网络可以提供一个或多个传输（例如在窄的或减少的信道带宽中）。<br>[0006] Additionally, in an example embodiment, a device may receive information (e.g. a definition or configuration) associated with a modified PDCCH that may be used by the device. The device may then monitor and/or decode the modified PDCCH resources based on such information (e.g. in the narrow or reduced channel bandwidth).<br>译文：[0006] 此外，在示例性实施例中，设备可以接收与设备可能使用的修改后的PDCCH相关联的信息（例如定义或配置）。然后，该设备可以基于此类信息（例如在窄的或减少的信道带宽中）监视和/或解码修改后的PDCCH资源。<br>[0155] An MTC device may receive the PDCCH in the PDSCH region in the second slot and the resource definition of the downlink control channels for M-PDCCH including PCFICH, PHICH, and PDCCH are the same as the LTE with the given bandwidth for MTC device.<br>译文：[0155] MTC设备可以在第二时隙中的PDSCH区域中接收PDCCH，并且用于M-PDCCH（包括PCFICH、PHICH和PDCCH）的下行链路控制信道的资源定义与针对MTC设备给定带宽的LTE相同。 | 该技术特征的核心是UE在系统带宽的“窄带”中监视控制信道以获取UL或DL授权。对比文件[0005]段明确提及设备基于接收的分配（如下行链路分配或上行链路授权）在“窄的或减少的信道带宽”中监视传输。[0006]段进一步说明设备监视和解码“修改后的PDCCH资源”，且同样是在窄带中。[0155]段提到了MTC设备接收“M-PDCCH”，这正是一种在窄带中定义的控制信道。因此，对比文件直接公开了在系统带宽的窄带中监视控制信道以获取UL或DL授权的技术特征。 |
| **技术特征C**：接收交织的在各自的子帧中的UL授权和DL授权<br>**公开性判断**：《未公开》（既非直接公开也非隐含公开） | 对比文件中未发现直接描述“接收交织的在各自的子帧中的UL授权和DL授权”的内容。文件涉及DL和UL授权，但未明确其“交织”特性及“在各自的子帧中”的具体时序关系。相关可能内容：<br>[0127] A DL signal transmission may include both inband DL assignments and UL grants, or in a specific occurrence (TTI), one of these.<br>译文：[0127] DL信号传输可以包括带内DL分配和UL授权两者，或者在特定出现（TTI）中，其中之一。<br>图20-21示出了DL和UL授权可以共存于同一调度实例（如子帧）中，分配给不同设备。 | 目标专利中“交织的UL授权和DL授权”具有特定含义，根据说明书[0106]-[0108]段及图12-13，其指UE可以连续接收一个UL授权后跟一个DL授权，或一个DL授权后跟一个UL授权，以支持TDD模式下的交织DL/UL传输或提高FDD效率。对比文件虽然提到DL信号传输中可以同时包含DL分配和UL授权（[0127]），并且图20-21显示了在同一子帧的带内信号中可以为不同设备分配DL PDSCH和UL PUSCH，但这描述的是在同一调度实例（TTI/子帧）内同时存在DL和UL授权信息，且通常分配给不同的UE。这与目标专利中UE“连续接收”时间上交错排列的、分别针对该UE自身的UL和DL授权（即“交织授权”）的技术方案有本质区别。本领域技术人员从对比文件的内容中无法直接确定也无法通过合理推断得出目标专利所定义的“接收交织的在各自的子帧中的UL授权和DL授权”这一特定技术特征。因此，该特征未被公开。 |
| **技术特征D**：以及响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息。<br>**公开性判断**：《未公开》（依赖特征C） | 对比文件中描述了设备在接收到DL分配或UL授权后，进行相应的PDSCH接收或PUSCH发送（例如[0062]、[0108]-[0109]）。 | 该技术特征是执行动作，其前提是接收到如特征C所定义的“交织的UL和DL授权”。由于特征C未被对比文件公开，因此响应于此特定类型授权而进行的发送或接收动作，在对比文件的整体技术方案中也不存在。对比文件中描述的发送/接收动作是针对其公开的普通DL/UL授权，而非“交织授权”。因此，该特征未被公开。 |
| **技术特征E**：根据权利要求1所述的方法，其中，接收所述交织的在各自的子帧中的UL授权和DL授权包括以下至少一者：在UL授权之后接收DL授权作为下一个授权，或者在DL授权之后接收UL授权作为下一个授权。<br>**公开性判断**：《未公开》（依赖特征C） | 对比文件中未发现描述授权接收顺序为“在UL授权之后接收DL授权作为下一个授权”或“在DL授权之后接收UL授权作为下一个授权”的内容。 | 该技术特征是对“交织授权”顺序的具体化。如对特征C的论述，对比文件未公开“交织授权”的概念，更未公开这种特定的、连续的授权接收顺序。因此，该特征未被公开。 |
| **技术特征F**：根据权利要求1所述的方法，其中，所述UE监视控制信道搜索空间，并且在UL授权之后并在响应于所述UL授权的在UL数据信道上所述发送信息的开始之后，接收DL授权作为下一个授权。<br>**公开性判断**：《未公开》 | 对比文件中未发现描述在UL数据传输开始“之后”接收DL授权作为“下一个授权”的特定时序关系。 | 该技术特征规定了非常具体的操作时序：UE在已经开始基于前一个UL授权进行上行数据传输之后，才接收下一个DL授权。对比文件未描述这种在UL数据发送开始后接收DL授权的特定场景。因此，该特征既未直接公开，也无法从对比文件内容中隐含得出。 |
| **技术特征G**：根据权利要求4所述的方法，其中，在所述UE在其中在所述UL数据信道上发送信息的子帧之后并在用于DL通信的子帧之前的子帧用作保护子帧。<br>**公开性判断**：《未公开》 | 对比文件中未提及“保护子帧”（guard subframe）的概念，也未描述在UL数据子帧和DL通信子帧之间插入子帧用于保护间隔。 | 该技术特征涉及TDD操作中为避免冲突而引入的保护子帧机制。对比文件整体未涉及此概念。因此，该特征未被公开。 |
| **技术特征H**：根据权利要求1所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持一个或多个混合自动重传请求(HARQ)过程。<br>**公开性判断**：《未公开》 | 对比文件提到了HARQ过程（例如[0061]、[0346]），但未明确将“每个UL或DL授权支持一个或多个HARQ过程”这一特性与“交织授权”相关联。 | 该技术特征限定了交织授权所支持的HARQ过程数量特性。由于“交织授权”本身（特征C）未被公开，因此与之绑定的HARQ支持特性也无从谈起。对比文件中关于HARQ的一般性描述不能直接等同于该特定限定。因此，该特征未被公开。 |
| **技术特征I**：根据权利要求8所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持两个HARQ过程。<br>**公开性判断**：《未公开》 | 对比文件中未明确提及每个授权支持“两个HARQ过程”，尤其是在窄带操作上下文下。 | 该技术特征是对HARQ过程数量的进一步具体限定（支持两个）。对比文件未公开此具体数量限定。因此，该特征未被公开。 |
| **技术特征J**：根据权利要求8所述的方法，其中，所述UE经由能力信令指示对以下至少一者的支持：针对每个UL授权或DL授权的两个HARQ进程，或UL授权和DL授权的交织。<br>**公开性判断**：《未公开》 | 对比文件中未提及UE通过能力信令（capability signaling）来指示对“两个HARQ过程”或“UL和DL授权交织”的支持。 | 该技术特征涉及UE通过信令向网络报告其特定能力。对比文件未公开这种具体的能力信令内容。因此，该特征未被公开。 |
| **技术特征K**：根据权利要求1所述的方法，还包括：响应于所述响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息，识别冲突，所述冲突包括以下至少一者：UL数据信道和DL数据信道之间的冲突，或UL数据信道与混合ARQ确认(HARQ-ACK)信令之间的冲突。<br>**公开性判断**：《未公开》 | 对比文件中未描述在接收“交织的UL和DL授权”并进行相应数据传输时，可能发生的“UL数据信道和DL数据信道之间的冲突”或“UL数据信道与HARQ-ACK信令之间的冲突”这些特定类型的冲突。 | 该技术特征涉及交织授权场景下特有的冲突识别问题。由于“交织授权”场景本身未被对比文件公开，因此在该场景下可能发生的这些特定类型冲突及其识别方法，在对比文件中也无对应记载。因此，该特征未被公开。 |
| **技术特征L**：根据权利要求11所述的方法，其中，所述HARQ-ACK信令包括确认或否定确认(NACK)，并且其中，所述HARQ-ACK信令是针对所述DL数据信道的。<br>**公开性判断**：《未公开》（依赖特征K） | 对比文件提及了ACK/NACK（例如[0069]段关于PHICH）。 | 该技术特征是对冲突中涉及的HARQ-ACK信令的进一步定义。由于其所依附的冲突识别特征（K）未被公开，且该定义与交织授权冲突场景紧密相关，因此该特征在对比文件的整体技术方案中无对应作用，未被公开。 |
| **技术特征M**：根据权利要求11所述的方法，其中，所述冲突包括所述UL数据信道和所述DL数据信道之间的所述冲突，所述方法还包括以下至少一个步骤：确定使用所述UL数据信道和所述DL数据信道中的一者，或对于在所述UL数据信道和所述DL数据信道之间冲突的子帧，确定使用所述UL数据信道和所述DL数据信道中的一者的所述子帧。<br>**公开性判断**：《未公开》（依赖特征K） | 对比文件中未描述在UL数据信道和DL数据信道冲突时，选择使用其中一者或选择冲突子帧的冲突解决步骤。 | 该技术特征是针对UL-DL数据信道冲突的具体解决步骤。由于冲突场景（特征K）未被公开，这些解决步骤在对比文件中也无对应记载。因此，该特征未被公开。 |
| **技术特征N**：根据权利要求13所述的方法，其中，所述确定使用的步骤是至少部分地基于能量度量阈值的。<br>**公开性判断**：《未公开》（依赖特征M） | 对比文件中未提及基于“能量度量阈值”来确定在冲突信道中选择哪个信道。 | 该技术特征是对冲突解决决策依据的进一步限定。由于其依附的冲突解决步骤（M）未被公开，且该特定决策依据在对比文件中无记载，因此该特征未被公开。 |
| **技术特征O**：根据权利要求12所述的方法，其中，所述冲突包括所述UL数据信道与所述HARQ-ACK信令之间的冲突，所述方法还包括以下至少一个步骤：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，确定传送所述HARQ-ACK信令，或者将所述HARQ-ACK信令与所述UL数据信道复用。<br>**公开性判断**：《未公开》（依赖特征K） | 对比文件中未描述在UL数据信道与HARQ-ACK信令冲突时，确定传送HARQ-ACK或将其与UL数据信道复用的解决步骤。 | 该技术特征是针对UL数据信道与HARQ-ACK冲突的具体解决步骤。由于冲突场景（特征K）未被公开，这些解决步骤在对比文件中也无对应记载。因此，该特征未被公开。 |
| **技术特征P**：根据权利要求15所述的方法，其中，所述将所述HARQ-ACK信令与所述UL数据信道复用包括：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，用所述HARQ-ACK信令调制所述UL数据信道的解调参考信号(DMRS)。<br>**公开性判断**：《未公开》（依赖特征O） | 对比文件中未提及用HARQ-ACK信令调制UL数据信道的DMRS这种复用方式。 | 该技术特征是对冲突解决中复用方式的具体实现。由于其依附的复用解决步骤（O）未被公开，且该具体实现方式在对比文件中无记载，因此该特征未被公开。 |
| **技术特征Q**：根据权利要求1所述的方法，其中，所述UE被配置用于窄带物联网(NB-IoT)。<br>**公开性判断**：《隐含公开》 | [0005] Systems and/or methods may be provided for supporting reduced channel bandwidth in wireless communications between devices such as UEs (e.g. including a low LTE UE category device) and/or low cost Machine-Type Communications (MTC) devices...<br>译文：[0005] 可以提供系统和/或方法以支持设备（例如UE（包括低LTE UE类别设备）和/或低成本机器类型通信（MTC）设备）...之间的无线通信中的减少的信道带宽。<br>全文多处提及支持“reduced channel bandwidth”、“narrow bandwidth”、“MTC device”。 | 目标专利中“配置用于窄带物联网(NB-IoT)”的UE，其核心特征之一是支持窄带操作。对比文件通篇主题即为支持减少信道带宽（窄带）的通信，特别是针对低成本MTC设备。在无线通信领域，NB-IoT是MTC和物联网（IoT）的一种重要实现方式，专为窄带、低功耗、广覆盖场景设计。本领域技术人员阅读对比文件后，能够直接理解其教导适用于包括NB-IoT在内的各类需要窄带操作的MTC/IoT设备。因此，对比文件隐含公开了UE被配置用于窄带物联网(NB-IoT)这一特征。 |
| **技术特征R**：根据权利要求1所述的方法，其中，所述UE被配置用于时分双工(TDD)操作。<br>**公开性判断**：《隐含公开》 | [0019] In another embodiment, the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).<br>译文：[0019] 在另一实施例中，基站114a和WTRU 102a、102b和/或102c可以实现诸如演进UMTS陆地无线电接入（E-UTRA）的无线电技术，其可以使用长期演进（LTE）和/或高级LTE（LTE-A）来建立空中接口115/116/117。 | LTE/LTE-A系统支持TDD和FDD两种双工模式，这是本领域的公知常识。对比文件[0019]明确其技术可应用于LTE/LTE-A系统。因此，本领域技术人员可以合理推断，对比文件中描述的用于支持减少带宽的无线通信方法，可以应用于LTE/LTE-A系统，进而自然包括该系统的TDD操作模式。虽然对比文件未明确点出“TDD”，但基于其应用的系统基础，隐含公开了UE可被配置用于TDD操作。 |
| **技术特征S**：根据权利要求1所述的方法，其中，所述UE被配置用于频分双工(FDD)操作。<br>**公开性判断**：《隐含公开》 | [0019] In another embodiment, the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).<br>译文：[0019] 在另一实施例中，基站114a和WTRU 102a、102b和/或102c可以实现诸如演进UMTS陆地无线电接入（E-UTRA）的无线电技术，其可以使用长期演进（LTE）和/或高级LTE（LTE-A）来建立空中接口115/116/117。 | 与特征R同理，LTE/LTE-A系统支持FDD模式。对比文件[0019]明确其技术可应用于LTE/LTE-A系统。因此，本领域技术人员可以合理推断，对比文件中的方法可以应用于LTE/LTE-A系统的FDD操作模式。隐含公开了UE可被配置用于FDD操作。 |
| **技术特征T**：根据权利要求1所述的方法，其中，所述控制信道包括窄带物理下行链路控制信道(NPDCCH)。<br>**公开性判断**：《隐含公开》 | [0155] An MTC device may receive the PDCCH in the PDSCH region in the second slot and the resource definition of the downlink control channels for M-PDCCH including PCFICH, PHICH, and PDCCH are the same as the LTE with the given bandwidth for MTC device.<br>译文：[0155] MTC设备可以在第二时隙中的PDSCH区域中接收PDCCH，并且用于M-PDCCH（包括PCFICH、PHICH和PDCCH）的下行链路控制信道的资源定义与针对MTC设备给定带宽的LTE相同。 | 目标专利中NPDCCH是NB-IoT中定义的窄带物理下行控制信道。对比文件[0155]提到了“M-PDCCH”（MTC PDCCH），这是为MTC/窄带设备定义的控制信道。在窄带操作的上下文中，为MTC设备设计的控制信道（如M-PDCCH）与为NB-IoT设计的控制信道（NPDCCH）在概念和功能上具有高度相似性，都是适配窄带带宽的控制信道解决方案。本领域技术人员基于对比文件对M-PDCCH的教导，能够合理推及类似的窄带控制信道设计也适用于NB-IoT场景，即控制信道包括NPDCCH。因此，该特征被隐含公开。 |
| **技术特征U**：根据权利要求1所述的方法，其中，所述发送信息包括：响应于所接收的UL授权，在UL数据信道中发送信息；并且其中，所述接收信息包括响应于所述DL授权在DL数据信道中接收信息。<br>**公开性判断**：《隐含公开》 | [0060] ... LTE data transmission in the DL and UL may be or may include DL-SCH and UL-SCH transport channels. Each transport channel may be mapped to a corresponding physical channel. In the DL or DL direction, the DL-SCH transmitted to a handset may be mapped to the HS-PDSCH... Similarly, in the UL or UL direction, the PUSCH may include a transport block per TTI...<br>译文：[0060] ... LTE中的DL和UL数据传输可以是或可以包括DL-SCH和UL-SCH传输信道。每个传输信道可以映射到相应的物理信道。在DL或DL方向上，发送到手机的DL-SCH可以映射到HS-PDSCH...类似地，在UL或UL方向上，PUSCH可以包括每个TTI的传输块...<br>[0108] ... a device such as a UE or MTC device may receive an inband UL grant for an upcoming PUSCH transmission...<br>译文：[0108] ... 诸如UE或MTC设备的设备可以接收用于即将到来的PUSCH传输的带内UL授权...<br>[0109] ... the inband UL grant may identify the intended transmitter to which the PUSCH transmission may have been assigned.<br>译文：[0109] ... 带内UL授权可以标识PUSCH传输可能被分配给的预期发射机。 | 该技术特征定义了发送和接收信息的具体动作与信道的映射关系。对比文件[0060]明确说明了在LTE中，DL-SCH映射到PDSCH，UL-SCH映射到PUSCH。[0108]-[0109]描述了设备接收UL授权以进行PUSCH传输。因此，对比文件直接公开了响应于UL授权在UL数据信道（PUSCH）发送信息，以及响应于DL授权在DL数据信道（PDSCH）接收信息的基本原理。在窄带操作语境下（如NB-IoT），这些信道对应为NPUSCH和NPDSCH，但功能等价。因此，该特征被隐含公开。 |
| **技术特征V**：根据权利要求21所述的方法，其中，所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)，并且其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)。<br>**公开性判断**：《隐含公开》 | [0060] ... LTE data transmission in the DL and UL may be or may include DL-SCH and UL-SCH transport channels... the DL-SCH... may be mapped to the HS-PDSCH... the PUSCH may include a transport block per TTI...<br>译文：[0060] ... LTE中的DL和UL数据传输可以是或可以包括DL-SCH和UL-SCH传输信道... DL-SCH...可以映射到HS-PDSCH... PUSCH可以包括每个TTI的传输块... | 目标专利中NPUSCH和NPDSCH是NB-IoT中的窄带数据信道。对比文件[0060]公开了在LTE中，上行数据信道是PUSCH，下行数据信道是PDSCH。对于窄带操作（如MTC或NB-IoT），本领域技术人员知晓需要定义适用于窄带宽的相应物理信道。基于对比文件对PUSCH/PDSCH作为数据信道的基本教导，结合窄带操作的需求，本领域技术人员能够合理推断在窄带系统中会存在功能相对应的窄带数据信道，即NPUSCH和NPDSCH。因此，该特征被隐含公开。 |
| **技术特征W**：根据权利要求11所述的方法，其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)，所述HARQ-ACK包括混合自动重传请求(HARQ)确认或否定确认，并且所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)。<br>**公开性判断**：《未公开》（依赖特征K） | 对比文件提及了PDSCH/PUSCH（[0060]）和ACK/NACK（[0069]）。 | 该技术特征是对冲突描述中涉及的信道和信号的进一步定义。由于其依附的冲突识别特征（K）未被对比文件公开，因此这些在特定冲突上下文中的进一步定义在对比文件的整体方案中无对应作用。虽然NPDSCH/NPUSCH可如特征V所述被隐含公开，HARQ-ACK是公知概念，但在此处作为冲突构成要素的特定组合未被公开。 |
<<<A>>><<<B>>><<<q>>><<<r>>><<<s>>><<<t>>><<<u>>><<<v>>>