对比文件的名称：发明专利_JP2017139796A 縮小されたチャネル帯域幅を使用するデバイス通信
目标专利的名称：用于窄带操作的上行链路和下行链路授权
本次调用的模型名称：专利代理师创造性评估模型
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：一种用于由用户设备(UE)进行无线通信的方法<br>**公开性判断**：**直接公开** | [0004] 译：例如，一实施形态中，设备可以接收下行链路分配和/或上行链路授权等的带内分配。基于这样的带内分配，设备可以监视（monitor）和/或决定由网络提供的一个或多个传输（例如，在窄的或缩小的信道带宽中）。<br>[0130] 译：例如，一实施形态中，如图18所示，UE或MTC设备等设备可以监视一个或多个RB，该RB位于诸如LTE子帧的子帧的数据区域的指定部分上，以寻找用于识别由eNB进行的DL数据传输的目标接收机的带内信令的发生。 | 对比文件通篇描述了由UE或MTC设备等无线设备执行的无线通信方法，包括接收授权/分配、监视控制信道、发送和接收数据等操作。这直接对应于目标专利中由UE执行无线通信方法这一上位概念。因此，技术特征A被对比文件直接公开。 |
| **技术特征B**：针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道<br>**公开性判断**：**直接公开** | [0004] 译：例如，一实施形态中，设备可以接收下行链路分配和/或上行链路授权等的带内分配。基于这样的带内分配，设备可以监视（monitor）和/或决定由网络提供的一个或多个传输（例如，在窄的或缩小的信道带宽中）。<br>[0130] 译：例如，一实施形态中，如图18所示，UE或MTC设备等设备可以监视一个或多个RB，该RB位于诸如LTE子帧的子帧的数据区域的指定部分上，以寻找用于识别由eNB进行的DL数据传输的目标接收机的带内信令的发生。<br>[0170] 译：MTC设备可以在第二时隙内的PDSCH区域中接收PDCCH。 | 对比文件多次明确描述了设备（UE/MTC）在缩小的信道带宽（即系统带宽的窄带）中监视控制信息，以接收DL分配或UL授权。例如，通过监视PDSCH区域内的带内信令或M-PDCCH来获得授权。这直接公开了在窄带中为获得UL或DL授权而监视控制信道的行为。因此，技术特征B被对比文件直接公开。 |
| **技术特征C**：接收交织的在各自的子帧中的UL授权和DL授权<br>**公开性判断**：**未公开** | 对比文件中未发现任何关于接收“交织的”UL授权和DL授权的描述。对比文件提到了背对背的DL授权或UL授权（例如两个连续的DL授权或两个连续的UL授权），但未提及一个UL授权和一个DL授权以交织方式（即一个UL后跟一个DL，或一个DL后跟一个UL）在各自的子帧中接收。 | 根据目标专利说明书第[0106]段，交织的UL和DL授权是指支持在一个UL授权之后接收一个DL授权作为下一个授权，或者在一个DL授权之后接收一个UL授权作为下一个授权，这对于支持TDD模式下的交织DL/UL传输尤为重要。对比文件虽然广泛讨论了在窄带中接收DL分配和UL授权，但始终将DL和UL授权的接收作为独立事件描述，或在背对背的同类授权场景中描述，并未描述或暗示接收交织的不同类型（UL和DL）授权。因此，本领域技术人员无法从对比文件中直接或隐含地确定技术特征C的内容。 |
| **技术特征D**：以及响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息。<br>**公开性判断**：**直接公开**（但前提条件“交织的授权”未被公开） | [0004] 译：基于这样的带内分配，设备可以监视（monitor）和/或决定由网络提供的一个或多个传输（例如，在窄的或缩小的信道带宽中）。<br>[0132] 译：UE或MTC设备等设备如果能够解码作为DL信号传输的一部分分配的标识符（例如，图18中的点状阴影内），则可以着手解码该子帧中对应的一个或多个数据单元（例如，图18中的斜线阴影）。<br>[0142] 译：UE或MTC设备等设备如果能够解码作为DL信号传输的一部分分配的其UL标识符，则可以着手准备在相关的UL子帧中的相关UL发送资源内发送一个或多个数据单元。 | 对比文件明确描述了设备在接收到DL分配或UL授权（无论是通过带内信令还是控制信道）后，会相应地发送或接收信息（数据单元）。例如，解码DL分配标识符后接收DL数据，解码UL授权标识符后准备UL发送。这直接公开了“响应于所接收的授权来发送或接收信息”这一基本操作流程。然而，该操作在对比文件中是响应于单个授权或背对背的同类授权，并非响应于“交织的UL和DL授权”。由于“交织的授权”这一前提未被公开，因此技术特征D作为一个整体（包含“交织的”限定）未被公开。但仅就“响应于授权发送或接收信息”而言，被直接公开。 |
| **技术特征E**：根据权利要求1所述的方法，其中，接收所述交织的在各自的子帧中的UL授权和DL授权包括以下至少一者：在UL授权之后接收DL授权作为下一个授权，或者在DL授权之后接收UL授权作为下一个授权。<br>**公开性判断**：**未公开** | 对比文件中未发现任何关于UL授权和DL授权以所述顺序（UL后DL或DL后UL）作为“下一个授权”连续接收的描述。 | 技术特征E进一步限定了交织授权的具体接收顺序。如对技术特征C的分析，对比文件未涉及UL和DL授权交织接收的概念，因此更不可能公开这种特定的交织顺序。本领域技术人员无法从对比文件中推断出这种接收模式。 |
| **技术特征F**：根据权利要求1所述的方法，其中，所述UE监视控制信道搜索空间，并且在UL授权之后并在响应于所述UL授权的在UL数据信道上所述发送信息的开始之后，接收DL授权作为下一个授权。<br>**公开性判断**：**未公开** | 对比文件中未发现任何描述在UL数据传输开始之后，再接收DL授权作为下一个授权的时序关系。 | 技术特征F限定了在UL授权触发的UL数据传输开始“之后”，才接收DL授权。这体现了一种特定的、可能用于避免冲突或优化半双工操作的时序安排。对比文件虽然分别描述了接收UL授权和DL授权，但并未建立这种精细的、依赖于前一个授权触发的数据传输开始的时序依赖关系。因此，该技术特征未被公开。 |
| **技术特征G**：根据权利要求4所述的方法，其中，在所述UE在其中在所述UL数据信道上发送信息的子帧之后并在用于DL通信的子帧之前的子帧用作保护子帧。<br>**公开性判断**：**未公开** | 对比文件中未提及将子帧用作“保护子帧”（Guard Subframe）以处理UL到DL切换的概念。 | 技术特征G涉及使用保护子帧来处理UL和DL通信之间的切换，特别是在交织授权和交织数据传输的场景下，这对于TDD或半双工操作中的时序管理很重要。对比文件没有描述或暗示这种保护机制。因此，该技术特征未被公开。 |
| **技术特征H**：根据权利要求1所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持一个或多个混合自动重传请求(HARQ)过程。<br>**公开性判断**：**未公开** | 对比文件提到了HARQ过程，例如[0240]段提到了HARQ进程号。然而，该描述并未将其与“交织的UL和DL授权中的每一个授权”相关联。对比文件主要关注在窄带操作中支持HARQ，但未提及在交织授权场景下每个授权支持一个或多个HARQ过程。 | 技术特征H限定了交织的UL和DL授权各自支持一个或多个HARQ过程。对比文件公开了HARQ过程的存在，但未将其与“交织授权”这一特定上下文联系起来。由于“交织授权”本身未被公开，因此该进一步限定的特征也未被公开。 |
| **技术特征I**：根据权利要求8所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持两个HARQ过程。<br>**公开性判断**：**未公开** | 对比文件在[0240]段提及了HARQ进程号，但未明确说明每个授权支持“两个”HARQ过程，更未在交织授权的背景下提及。 | 技术特征I进一步将支持的HARQ过程数量限定为两个。对比文件没有公开每个授权支持两个HARQ过程，也未在交织授权的语境下讨论HARQ过程数量。因此，该技术特征未被公开。 |
| **技术特征J**：根据权利要求8所述的方法，其中，所述UE经由能力信令指示对以下至少一者的支持：针对每个UL授权或DL授权的两个HARQ进程，或UL授权和DL授权的交织。<br>**公开性判断**：**隐含公开** | [0337] 译：例如，设备可以经由能力消息通知eNB其是否支持灵活的UL发送。<br>[0338] 译：设备还可以在随机接入响应之后或在竞争解决之后，在随机接入消息之一（例如设备或UE响应）中，通知eNB其是否可以是如MTC设备或带宽较窄的设备这样的设备。 | 对比文件明确描述了UE/MTC设备可以通过信令（如能力消息、随机接入消息）向网络（eNB）指示其支持的能力或设备类型。虽然对比文件未明确提及“针对每个授权的两个HARQ进程”或“UL和DL授权交织”这两种具体能力，但公开了设备通过信令向网络指示其能力的一般原理。本领域技术人员基于此原理，可以合理推断出，如果设备支持诸如两个HARQ进程或交织授权等特定增强功能，也可以通过类似的信令机制（能力信令）向网络进行指示。因此，技术特征J被对比文件隐含公开。 |
| **技术特征K**：根据权利要求1所述的方法，还包括：响应于所述响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息，识别冲突，所述冲突包括以下至少一者：UL数据信道和DL数据信道之间的冲突，或 UL数据信道与混合ARQ确认(HARQ-ACK)信令之间的冲突。<br>**公开性判断**：**未公开** | 对比文件中未发现任何关于识别因交织UL和DL授权而导致的“UL数据信道和DL数据信道之间的冲突”或“UL数据信道与HARQ-ACK信令之间的冲突”的描述。 | 技术特征K涉及在交织授权场景下可能出现的特定冲突类型及其识别。对比文件虽然讨论了冲突解决（例如随机接入中的竞争解决），但并未涉及由交织的UL和DL数据传输引发的资源冲突问题。因此，该技术特征未被公开。 |
| **技术特征L**：根据权利要求11所述的方法，其中，所述HARQ-ACK信令包括确认或否定确认(NACK)，并且其中，所述HARQ-ACK信令是针对所述DL数据信道的。<br>**公开性判断**：**直接公开**（但冲突上下文未被公开） | [0066] 译：例如，PHICH可以用于发送与在上行链路子帧中发送的PUSCH相对应的ACK或NACK。<br>[0240] 译：此外，可以提供和/或使用HARQ进程号和/或信道状态信息反馈，如本文所述。 | 对比文件明确公开了HARQ-ACK信令（包括ACK/NACK）是针对上行链路传输（PUSCH）的反馈，这是LTE中的标准做法。然而，技术特征L是在“UL数据信道与HARQ-ACK信令之间的冲突”这一特定冲突上下文（技术特征K）中描述的，且明确指出该HARQ-ACK是针对DL数据信道的。这与对比文件中描述的针对UL的HARQ-ACK不同。虽然HARQ-ACK包含ACK/NACK被直接公开，但其在冲突场景下针对DL数据信道的应用未被公开。因此，技术特征L作为一个整体（在特定冲突上下文中针对DL的HARQ-ACK）未被公开。 |
| **技术特征M**：根据权利要求11所述的方法，其中，所述冲突包括所述UL数据信道和所述DL数据信道之间的所述冲突，所述方法还包括以下至少一个步骤：确定使用所述UL数据信道和所述DL数据信道中的一者，或对于在所述UL数据信道和所述DL数据信道之间冲突的子帧，确定使用所述UL数据信道和所述DL数据信道中的一者的所述子帧。<br>**公开性判断**：**未公开** | 对比文件中未发现任何关于在UL和DL数据信道发生冲突时，选择使用其中一者或选择冲突子帧的处理步骤描述。 | 技术特征M提供了处理UL和DL数据信道冲突的具体UE行为。对比文件没有描述这种冲突场景，因此也不可能公开解决该冲突的步骤。该技术特征未被公开。 |
| **技术特征N**：根据权利要求13所述的方法，其中，所述确定使用的步骤是至少部分地基于能量度量阈值的。<br>**公开性判断**：**未公开** | 对比文件中提到了基于能量度量来选择授权，例如在隐含公开判断J的上下文中可能涉及，但并非用于解决UL和DL数据信道之间的冲突。具体用于冲突解决的“基于能量度量阈值确定使用哪个信道”的步骤未被描述。 | 技术特征N限定了在冲突解决中基于能量度量阈值进行决策。对比文件虽然可能在其他场景（如授权选择）中提到能量度量，但并未将其应用于技术特征M所定义的UL/DL数据信道冲突解决场景中。因此，该技术特征未被公开。 |
| **技术特征O**：根据权利要求12所述的方法，其中，所述冲突包括所述UL数据信道与所述HARQ-ACK信令之间的冲突，所述方法还包括以下至少一个步骤：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，确定传送所述HARQ-ACK信令，或者将所述HARQ-ACK信令与所述UL数据信道复用。<br>**公开性判断**：**未公开** | 对比文件中未发现任何关于处理UL数据信道与HARQ-ACK信令之间冲突的步骤描述，无论是选择传送HARQ-ACK还是将其与UL数据信道复用。 | 技术特征O提供了处理UL数据信道与HARQ-ACK信令冲突的具体UE行为。对比文件没有描述这种冲突场景，因此也不可能公开解决该冲突的步骤。该技术特征未被公开。 |
| **技术特征P**：根据权利要求15所述的方法，其中，所述将所述HARQ-ACK信令与所述UL数据信道复用包括：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，用所述HARQ-ACK信令调制所述UL数据信道的解调参考信号(DMRS)。<br>**公开性判断**：**未公开** | 对比文件中未提及通过用HARQ-ACK调制UL数据信道的DMRS来实现信令复用的技术。 | 技术特征P限定了将HARQ-ACK与UL数据信道复用的一种具体实现方式。这是一种特定的技术手段。对比文件中完全没有提及这种复用机制。因此，该技术特征未被公开。 |
| **技术特征Q**：根据权利要求1所述的方法，其中，所述UE被配置用于窄带物联网(NB-IoT)。<br>**公开性判断**：**直接公开** | [0006] 译：无线设备可以包括物联网(IoT)设备（例如，窄带IoT(NB-IoT)设备）。<br>[0056] 译：MTC设备或诸如其他UE设备的设备可以是针对由GSM/GPRS网络处理的低端（例如，低成本、低数据速率）应用的目标。 | 对比文件明确将NB-IoT设备作为其描述的无线设备（如MTC设备、低复杂度UE）的一种类型。其整体技术方案就是针对在LTE等网络中支持此类窄带、低成本设备（包括NB-IoT）的通信。因此，技术特征Q被对比文件直接公开。 |
| **技术特征R**：根据权利要求1所述的方法，其中，所述UE被配置用于时分双工(TDD)操作。<br>**公开性判断**：**直接公开** | [0114] 译：当前物理随机接入信道(PRACH)也可能受到带宽缩小引起的问题或挑战的影响或招致问题或挑战。...对于TDD（即帧结构2），可以配置上行链路子帧中最多六个PRACH频率资源。<br>[0240] 译：可以根据多类型子帧配置中的子帧配置来改变用于HARQ进程号的比特数。 | 对比文件在多处提到了TDD（帧结构2），并讨论了在TDD配置下的操作（如PRACH资源配置、多类型子帧等），表明其技术方案适用于TDD模式。因此，技术特征R被对比文件直接公开。 |
| **技术特征S**：根据权利要求1所述的方法，其中，所述UE被配置用于频分双工(FDD)操作。<br>**公开性判断**：**直接公开** | [0066] 译：...在FDD的情况下...<br>[0114] 译：...对于FDD（例如，帧结构1）... | 对比文件同样在多处明确提到了FDD（帧结构1），表明其技术方案也适用于FDD模式。因此，技术特征S被对比文件直接公开。 |
| **技术特征T**：根据权利要求1所述的方法，其中，所述控制信道包括窄带物理下行链路控制信道(NPDCCH)。<br>**公开性判断**：**直接公开** | [0170] 译：MTC设备可以在第二时隙内的PDSCH区域中接收PDCCH。...用于M-PDCCH的下行链路控制信道的资源定义，包括PCFICH、PHICH和PDCCH，与使用给定带宽用于MTC设备的LTE相同。<br>[0222] 译：在描述用于不同子帧中的M-PDCCH和M-PDSCH的实施例等、本文描述的任何实施例中，可以设想M-PDCCH可由ePDCCH替换。 | 对比文件描述了用于MTC设备的窄带控制信道，如M-PDCCH，其功能与常规PDCCH类似，但适用于窄带操作。在NB-IoT语境下，窄带物理下行链路控制信道即为NPDCCH。对比文件提到的M-PDCCH或ePDCCH在窄带操作中扮演的角色，实质上等同于目标专利中的NPDCCH。因此，技术特征T被对比文件直接公开。 |
| **技术特征U**：根据权利要求1所述的方法，其中，所述发送信息包括：响应于所接收的UL授权，在UL数据信道中发送信息；并且其中，所述接收信息包括响应于所述DL授权在DL数据信道中接收信息。<br>**公开性判断**：**直接公开** | [0132] 译：UE或MTC设备等设备如果能够解码作为DL信号传输的一部分分配的标识符（例如，图18中的点状阴影内），则可以着手解码该子帧中对应的一个或多个数据单元（例如，图18中的斜线阴影）。<br>[0142] 译：UE或MTC设备等设备如果能够解码作为DL信号传输的一部分分配的其UL标识符，则可以着手准备在相关的UL子帧中的相关UL发送资源内发送一个或多个数据单元。 | 对比文件明确描述了设备在解码出DL分配（授权）后接收DL数据单元，以及在解码出UL授权后准备并发送UL数据单元。这直接对应于技术特征U中“响应于UL授权在UL数据信道中发送信息”和“响应于DL授权在DL数据信道中接收信息”。因此，技术特征U被对比文件直接公开。 |
| **技术特征V**：根据权利要求21所述的方法，其中，所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)，并且其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)。<br>**公开性判断**：**直接公开** | [0060] 译：例如，在DL或DL方向上，发送至手持设备的DL-SCH可以映射到HS-PDSCH...同样，在UL或UL方向上，PUSCH可以包括每个TTI一个传输块（例如，在R8中）或在使用空间复用时最多两个传输块每个TTI（例如，在R10中）。<br>[0292] 译：...下行链路数据信道区域（例如，M-PDSCH区域）... | 对比文件描述了用于上下行数据传输的共享信道，如PDSCH和PUSCH。在窄带操作（如MTC、NB-IoT）的上下文中，这些信道对应于窄带版本的共享信道，即NPDSCH和NPUSCH。对比文件中提到的M-PDSCH即为窄带PDSCH的一种表述。因此，技术特征V被对比文件直接公开。 |
| **技术特征W**：根据权利要求11所述的方法，其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)，所述HARQ-ACK包括混合自动重传请求(HARQ)确认或否定确认，并且所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)。<br>**公开性判断**：**直接公开**（但冲突上下文未被公开） | [0066] 译：例如，PHICH可以用于发送与在上行链路子帧中发送的PUSCH相对应的ACK或NACK。<br>[0060], [0292] 译：（同上技术特征V） | 技术特征W在从属权利要求11（涉及冲突识别）的语境下，进一步明确了所涉及信道的具体类型。对比文件直接公开了这些信道类型（NPDSCH/NPUSCH）和HARQ-ACK信令（ACK/NACK）本身，如之前对技术特征V和L部分内容的分析。然而，技术特征W是嵌在“根据权利要求11所述的方法”这一冲突识别语境中的。由于该冲突识别语境（技术特征K）本身未被对比文件公开，因此技术特征W作为一个整体（在冲突语境下明确这些信道类型）未被公开。但仅就明确这些信道和信令类型而言，其内容已被直接公开。 |
<<<A>>><<<B>>><<<D>>><<<Q>>><<<R>>><<<S>>><<<T>>><<<U>>><<<V>>><<<W>>>