**本次调用的模型名称**：专利创造性评估模型
**目标专利名称**：用于窄带操作的上行链路和下行链路授权
**对比文件名称**：发明专利_JP2014531856A 縮小されたチャネル帯域幅を使用するデバイス通信
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：一种用于由用户设备(UE)进行无线通信的方法** <br>《直接公开》 | [0003] 译：（例如，低LTE UEカテゴリデバイスを含む）UEおよび／または低コストマシンタイプ通信（MTC：Machine-Type Communication）デバイスなどのデバイスと、全帯域幅をサポートできるネットワーク（例えば，全帯域幅ネットワーク）との間の無線通信において、縮小されたチャネル帯域幅をサポートするための、システムおよび／または方法を提供することができる。 | 对比文件[0003]段明确指出，其描述的系统/方法涉及“用户设备（UE）”和/或低成本机器类型通信（MTC）设备等设备与支持全带宽的网络之间的无线通信，以支持缩小的信道带宽。这直接公开了目标专利权利要求中“一种用于由用户设备(UE)进行无线通信的方法”这一主题。两者均涉及UE侧的无线通信方法。 |
| **技术特征B：针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道** <br>《直接公开》 | [0003] 译：例えば，一実施形態では、デバイスは、ダウンリンク割り当ておよび／またはアップリンクグラントなどのインバンド割り当てを受信することができる。そのようなインバンド割り当てに基づいて、デバイスは、（例えば、狭いまたは縮小されたチャネル帯域幅において）ネットワークによって提供できる１つまたは複数の送信を監視し、および／または決定することができる。<br>[0122] 译：例えば，一実施形態では、ＵＥまたはＭＴＣデバイスなどの複雑さが低いデバイスは、サブフレームのデータ領域内で搬送できるインバンドシグナリングを通してＰＤＳＣＨ送信の対象受信機を識別できる、インバンドＤＬ割り当てを受信することができる。 | 对比文件[0003]段公开了设备可以接收下行链路分配和/或上行链路授权等带内分配，并基于此监视网络提供的传输。结合[0122]段，其进一步明确描述了低复杂度的设备（如UE或MTC设备）可以接收在子帧数据域内携带的“带内DL分配”，该分配用于识别PDSCH传输的目标接收机。在对比文件的上下文中，“带内分配”即在数据信道（PDSCH）中携带的控制信息，这对应于目标专利中在窄带中“监视控制信道”以获取授权。虽然对比文件更侧重于在数据域（PDSCH）内携带控制信息（即“带内”），而目标专利的控制信道（如NPDCCH）可能位于控制域或数据域，但其核心功能——UE在受限带宽（窄带）内监视用于UL或DL授权的控制信息——已被对比文件直接公开。 |
| **技术特征C：接收交织的在各自的子帧中的UL授权和DL授权** <br>《隐含公开》 | [0123] 译：さらなる一実施形態では、ＵＥまたはＭＴＣデバイスなどのデバイス（例えば、縮小された帯域幅をサポートできる低コストデバイス）は、サブフレームのデータ領域内で搬送できるシグナリングの一部として、次回のＰＵＳＣＨ送信のためのインバンドＵＬグラントを受信することができる。<br>[0124] 译：本明細書で説明するように、サブフレームのデータ領域内で搬送されるインバンドシグナリングを監視することに、ＵＥまたはＭＴＣデバイスなどの複数のデバイス（例えば、縮小された帯域幅をサポートできる低コストデバイス）を割り当てることができる。また、ＤＬ ＰＤＳＣＨおよびＵＬ ＰＵＳＣＨ送信リソースを、全てのスケジュールインスタンスまたはＴＴＩにおいて、これらの複数のデバイスの間で互いから独立して割り当てることができる。例えば、第１のＭＴＣデバイスなどの第１のデバイスには、インバンドシグナリングを通してＤＬ ＰＤＳＣＨ送信を割り当てることができ、一方、第２のＭＴＣデバイスなどの第２のデバイスには、このインバンドシグナリングメッセージ内の付随または関連するＵＬ ＰＵＳＣＨ送信機会を割り当てることができる。<br>[0140] 译：ＤＬ信号送信は、インバンドＤＬ割り当てとＵＬグラントの両方を、または特定の発生（ＴＴＩ）内にこれらの一方を含むことができる。説明の目的で、ＤＬ割り当てとＵＬグラントの両方をＵＥまたはＭＴＣデバイスなどのデバイスへのＤＬ信号送信の一部とすることができる実施形態について、インバンドＵＬグラントを図２０に示すことができる。 | 对比文件未明确使用“交织”一词描述UL和DL授权的接收顺序。然而，[0124]段明确指出，在同一个调度实例或TTI（即子帧）中，可以独立地为多个设备分配DL PDSCH和UL PUSCH传输资源，并举例说明可以在一个带内信令消息中，为一个设备分配DL传输，同时为另一个设备分配UL传输机会。[0140]段进一步说明DL信号传输可以在一个特定发生（TTI）内同时包含带内DL分配和UL授权两者。结合[0123]段描述的接收带内UL授权，本领域技术人员可以合理推断：网络在一个子帧（或连续的几个子帧）内发送的控制信息（带内信令）有可能既包含针对某个UE的DL授权，也包含针对该UE或其他UE的UL授权。UE在监视这些带内信令时，完全有可能在时间上连续或接近连续的子帧中，接收到一个UL授权和一个DL授权，或者反之。这种接收顺序不是固定的，而是由网络调度决定的，这与“交织”的概念（即UL和DL授权交替出现）在效果上是兼容的。因此，对比文件隐含公开了接收交织的UL和DL授权。 |
| **技术特征D：以及响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息。** <br>《隐含公开》 | [0122] 译：...インバンドＤＬ割り当てを受信することができる。<br>[0123] 译：...インバンドＵＬグラントを受信することができる。<br>[0124] 译：...ＤＬ ＰＤＳＣＨおよびＵＬ ＰＵＳＣＨ送信リソースを...割り当てることができる。 | 对比文件[0122]和[0123]段分别描述了设备接收带内DL分配和带内UL授权。[0124]段紧接着说明可以根据这些分配/授权来分配DL PDSCH和UL PUSCH传输资源。这直接对应于接收到授权后，在PDSCH上接收信息或在PUSCH上发送信息的基本操作。结合对技术特征C“接收交织授权”的隐含公开分析，本领域技术人员可以合理推断，当UE按照对比文件描述的方式，在可能交织的顺序下接收到UL和DL授权后，自然需要并根据这些授权来执行相应的信息发送（在PUSCH上）或接收（在PDSCH上）。因此，该特征被对比文件隐含公开。 |
| **技术特征E：根据权利要求1所述的方法，其中，接收所述交织的在各自的子帧中的UL授权和DL授权包括以下至少一者：在UL授权之后接收DL授权作为下一个授权，或者在DL授权之后接收UL授权作为下一个授权。** <br>《隐含公开》 | [0124] 译：例えば、第１のＭＴＣデバイスなどの第１のデバイスには、インバンドシグナリングを通してＤＬ ＰＤＳＣＨ送信を割り当てることができ、一方、第２のＭＴＣデバイスなどの第２のデバイスには、このインバンドシグナリングメッセージ内の付随または関連するＵＬ ＰＵＳＣＨ送信機会を割り当てることができる。<br>[0140] 译：ＤＬ信号送信は、インバンドＤＬ割り当てとＵＬグラントの両方を、または特定の発生（ＴＴＩ）内にこれらの一方を含むことができる。 | 对比文件未明确规定UL和DL授权必须按照“UL后DL”或“DL后UL”的特定交织顺序接收。然而，[0124]段表明，在同一带内信令消息中，可以同时为不同设备分配DL和UL资源，这意味着UE可能在解析一个控制消息时同时发现涉及DL和UL的调度信息。[0140]段说明一个DL信号传输（可理解为控制信息承载）可以同时包含DL分配和UL授权。虽然这更倾向于“同时”而非严格时间序列上的“下一个”，但本领域技术人员可以理解，在实际调度中，网络完全可以在连续的TTI（子帧）中，先发送一个包含UL授权的控制消息，紧接着在下一个TTI发送一个包含DL授权的控制消息，或者反之。这种调度灵活性是无线通信系统的常规设计。因此，对比文件的内容为“在UL授权之后接收DL授权作为下一个授权，或者在DL授权之后接收UL授权作为下一个授权”这种具体的交织顺序提供了合理的基础和可能性，故该特征被隐含公开。 |
| **技术特征F：根据权利要求1所述的方法，其中，所述UE监视控制信道搜索空间，并且在UL授权之后并在响应于所述UL授权的在UL数据信道上所述发送信息的开始之后，接收DL授权作为下一个授权。** <br>《未公开》 | （对比文件未提及在UL数据传输开始之后接收DL授权的具体时序关系） | 对比文件描述了接收带内DL/UL授权以及根据授权进行发送/接收，但并未具体限定在接收到UL授权并已开始UL数据传输之后，才接收DL授权作为下一个授权。目标专利的该特征明确了UL数据传输开始与接收下一个DL授权之间的先后时序关系，这是为了解决特定场景（如TDD或半双工下的交织操作）下的冲突或时序安排问题。对比文件中没有公开或暗示这种特定的、精细化的时序约束条件。 |
| **技术特征G：根据权利要求4所述的方法，其中，在所述UE在其中在所述UL数据信道上发送信息的子帧之后并在用于DL通信的子帧之前的子帧用作保护子帧。** <br>《未公开》 | （对比文件未提及在UL和DL子帧之间使用保护子帧） | 对比文件通篇未涉及在UL数据传输子帧和后续DL通信子帧之间插入“保护子帧”（Guard Subframe）的概念。保护子帧通常用于TDD或半双工操作中，为UE提供从发送切换到接收（或反之）所需的切换时间。目标专利引入此特征是为了解决窄带操作中（特别是TDD模式下）交织UL/DL传输时的切换时序问题。对比文件没有公开或暗示这一特定技术手段。 |
| **技术特征H：根据权利要求1所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持一个或多个混合自动重传请求(HARQ)过程。** <br>《直接公开》 | [0238] 译：ＨＡＲＱプロセス番号および／またはチャネル状態情報フィードバックを、本明細書で説明するように、さらに提供すること、および／または使用することができる。例えば、一実施形態では、ＨＡＲＲＱプロセス番号のためのビットの数を、マルチタイプサブフレーム構成におけるサブフレーム構成に従って変更することができる。 | 对比文件[0238]段明确提到了HARQ过程，并指出可以根据子帧配置来改变用于HARQ过程编号的比特数，这表明其系统支持HARQ过程。虽然该段未明确将这些HARQ过程与“交织的UL和DL授权中的每一个授权”直接关联，但HARQ过程是LTE及类似系统中与数据传输（无论是UL还是DL）紧密相关的底层机制。当对比文件公开了接收DL分配和UL授权（技术特征B、C）并基于其进行数据传输（技术特征D）时，结合其明确支持HARQ过程的事实，本领域技术人员可以直接且明确地确定，这些授权所调度的数据传输自然会涉及一个或多个HARQ过程。因此，该技术特征被直接公开。 |
| **技术特征I：根据权利要求8所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持两个HARQ过程。** <br>《未公开》 | （对比文件未提及支持两个HARQ过程的具体数量） | 对比文件[0238]段提到支持HARQ过程并可改变其编号的比特数，但并未具体说明支持的HARQ过程数量，特别是没有明确指出每个授权支持“两个”HARQ过程。支持两个HARQ过程是目标专利针对窄带操作（如Rel-14 NB-IoT）引入的特定增强功能，以允许背对背授权。对比文件没有公开或暗示这一具体数量。 |
| **技术特征J：根据权利要求8所述的方法，其中，所述UE经由能力信令指示对以下至少一者的支持：针对每个UL授权或DL授权的两个HARQ进程，或UL授权和DL授权的交织。** <br>《未公开》 | （对比文件未提及UE通过能力信令指示对两个HARQ过程或交织授权的支持） | 对比文件虽然描述了低复杂度设备（如MTC设备）的操作和可能的带内信令，但并未涉及UE通过“能力信令”（capability signaling）向网络主动指示其是否支持“两个HARQ过程”或“UL和DL授权交织”这些特定功能。这种能力指示是终端与网络协商高级特性的常见方式，但对比文件文本中找不到相关描述。 |
| **技术特征K：根据权利要求1所述的方法，还包括：响应于所述响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息，识别冲突，所述冲突包括以下至少一者：UL数据信道和DL数据信道之间的冲突，或UL数据信道与混合ARQ确认(HARQ-ACK)信令之间的冲突。** <br>《未公开》 | （对比文件未提及识别UL数据信道与DL数据信道之间，或UL数据信道与HARQ-ACK之间的冲突） | 对比文件详细描述了资源分配、带内信令、HARQ过程等，但完全没有涉及在接收到交织授权并进行数据传输时，可能出现的“冲突”识别问题，特别是UL数据信道与DL数据信道之间的冲突，或者UL数据信道与HARQ-ACK信令之间的冲突。目标专利引入冲突识别是为了处理在支持交织UL/DL授权或两个HARQ过程时可能产生的资源重叠问题。这是一个特定场景下的问题解决方案，对比文件未予公开。 |
| **技术特征L：根据权利要求11所述的方法，其中，所述HARQ-ACK信令包括确认或否定确认(NACK)，并且其中，所述HARQ-ACK信令是针对所述DL数据信道的。** <br>《直接公开》 | [0067] 译：例えば、ＰＨＩＣＨは、アップリンクサブフレーム内で送信されるＰＵＳＣＨに対応するＡＣＫまたはＮＡＣＫを送信するために使用することができる。 | 对比文件[0067]段明确说明，PHICH用于发送对应于上行链路子帧中发送的PUSCH的ACK或NACK。这直接公开了HARQ-ACK信令包括确认(ACK)或否定确认(NACK)。虽然此例是针对UL的反馈，但根据LTE原理，对于DL数据信道（PDSCH）的反馈（ACK/NACK）通常通过PUCCH或PUSCH发送，这是本领域的公知常识。对比文件公开了ACK/NACK的概念及其用于数据传输反馈，结合本领域常识，可直接确定HARQ-ACK信令也针对DL数据信道。因此，该特征被直接公开。 |
| **技术特征M：根据权利要求11所述的方法，其中，所述冲突包括所述UL数据信道和所述DL数据信道之间的所述冲突，所述方法还包括以下至少一个步骤：确定使用所述UL数据信道和所述DL数据信道中的一者，或对于在所述UL数据信道和所述DL数据信道之间冲突的子帧，确定使用所述UL数据信道和所述DL数据信道中的一者的所述子帧。** <br>《未公开》 | （对比文件未提及在UL和DL数据信道冲突时确定使用其中一者的步骤） | 如对技术特征K的分析，对比文件未涉及冲突识别，因此更不可能公开在识别出UL和DL数据信道冲突后，所采取的“确定使用其中一者”或“在冲突子帧确定使用其中一者”的具体解决步骤。 |
| **技术特征N：根据权利要求13所述的方法，其中，所述确定使用的步骤是至少部分地基于能量度量阈值的。** <br>《未公开》 | （对比文件未提及基于能量度量阈值来解决授权或信道冲突） | 对比文件没有描述任何基于“能量度量阈值”来进行决策的机制，特别是在冲突解决的上下文中。这是一个特定的决策标准，对比文件未予公开。 |
| **技术特征O：根据权利要求12所述的方法，其中，所述冲突包括所述UL数据信道与所述HARQ-ACK信令之间的冲突，所述方法还包括以下至少一个步骤：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，确定传送所述HARQ-ACK信令，或者将所述HARQ-ACK信令与所述UL数据信道复用。** <br>《未公开》 | （对比文件未提及在UL数据信道与HARQ-ACK冲突时确定传送HARQ-ACK或将其复用的步骤） | 如对技术特征K的分析，对比文件未涉及此类冲突，因此也未公开相应的解决步骤，例如优先传送HARQ-ACK或将其与UL数据信道进行复用。 |
| **技术特征P：根据权利要求15所述的方法，其中，所述将所述HARQ-ACK信令与所述UL数据信道复用包括：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，用所述HARQ-ACK信令调制所述UL数据信道的解调参考信号(DMRS)。** <br>《未公开》 | （对比文件未提及用HARQ-ACK调制UL数据信道的DMRS） | 对比文件未提及任何关于将HARQ-ACK信令与UL数据信道复用的具体实现方式，特别是“用HARQ-ACK信令调制UL数据信道的解调参考信号(DMRS)”这种非常具体的物理层复用技术。 |
| **技术特征Q：根据权利要求1所述的方法，其中，所述UE被配置用于窄带物联网(NB-IoT)。** <br>《直接公开》 | [0006] 译：NB‑IoT可以指专门为IoT设计的窄带无线电技术...<br>[0054] 译：ＭＴＣデバイスまたはＵＥなどのデバイスは、ＧＳＭ／ＧＰＲＳネットワークによって扱うことができるローエンド（例えば、低コスト、低データレート）アプリケーションのターゲットとすることができる。...そのようなデバイスをＬＴＥネットワークなどのネットワークに移行するためのシステムおよび／または方法（例えば、低コストのシステムおよび／または方法）を提供すること、および／または使用することができる。 | 对比文件[0006]段明确提到了“窄带物联网(NB-IoT)”。[0054]段虽然主要提及MTC设备，但其描述的低成本、低数据速率设备正是NB-IoT设备的典型特征，并且全文的核心就是支持缩窄带宽的设备在LTE等网络中操作。因此，对比文件直接公开了UE被配置用于窄带物联网(NB-IoT)的应用场景。 |
| **技术特征R：根据权利要求1所述的方法，其中，所述UE被配置用于时分双工(TDD)操作。** <br>《直接公开》 | [0097] 译：例えば、ＳＩＢ１は、...ＴＤＤ ＵＬ／ＤＬ構成などの何らかの動作パラメータ（例えば、ＴＤＤの場合に限る）...を提供することができる。<br>[0112] 译：現在のところ（例えば、現在のＬＴＥ規格）、実施形態では、...ＴＤＤ（すなわち、フレーム構造２）の場合、アップリンクサブフレーム内の最大６個のＰＲＡＣＨ周波数リソースを構成することができる。 | 对比文件[0097]段提到系统信息块SIB1可以提供“TDD UL/DL配置”等操作参数。[0112]段明确区分了FDD和TDD（帧结构2）的情况。这表明对比文件所描述的系统和方法适用于TDD操作模式。虽然对比文件没有明确说“UE被配置用于TDD操作”，但其描述的系统支持TDD，那么参与其中的UE自然可以被配置用于TDD操作。这可以被本领域技术人员直接确定。 |
| **技术特征S：根据权利要求1所述的方法，其中，所述UE被配置用于频分双工(FDD)操作。** <br>《直接公开》 | [0112] 译：現在のところ（例えば、現在のＬＴＥ規格）、実施形態では、ＦＤＤ（例えば、フレーム構造１）の場合、サポートされるシステムＢＷ内のＰＲＡＣＨ周波数リソース（例えば、連続する６個のＲＢ）をアップリンクサブフレーム内に割り当てることができ... | 对比文件[0112]段明确提到了“FDD（例如，帧结构1）”，并描述了FDD下的资源分配。这表明对比文件所描述的系统和方法同样适用于FDD操作模式。因此，UE被配置用于FDD操作也被直接公开。 |
| **技术特征T：根据权利要求1所述的方法，其中，所述控制信道包括窄带物理下行链路控制信道(NPDCCH)。** <br>《未公开》 | （对比文件未提及“窄带物理下行链路控制信道(NPDCCH)”这一特定术语） | 对比文件详细描述了多种控制信道设计，包括在PDCCH区域、PDSCH区域（带内信令）、以及为低带宽设备设计的M-PDCCH等。然而，它始终没有使用目标专利中特定的标准化术语“窄带物理下行链路控制信道(NPDCCH)”。NPDCCH是3GPP NB-IoT标准中定义的特定信道。虽然对比文件描述的控制信道功能（在窄带中传递控制信息）与NPDCCH类似，但未公开这一具体命名。在专利创造性评估中，具体的技术术语（尤其是标准化名称）的差异可能具有重要性。因此，认为该特征未被直接或隐含公开。 |
| **技术特征U：根据权利要求1所述的方法，其中，所述发送信息包括：响应于所接收的UL授权，在UL数据信道中发送信息；并且其中，所述接收信息包括响应于所述DL授权在DL数据信道中接收信息。** <br>《直接公开》 | [0122] 译：...インバンドＤＬ割り当てを受信することができる。ＰＤＳＣＨ送信の対象受信機を識別できるインバンドＤＬ割り当てには、変調タイプ、コーディングレート、...などの、送信の細目を記述する情報が付随することができる。<br>[0123] 译：...インバンドＵＬグラントを受信することができる。インバンドＵＬグラントは、ＰＵＳＣＨ送信を割り当てることができた対象送信機を識別することができる。...インバンドＵＬグラントには、変調タイプ、コーディングレート、...などの、次回のＵＬ送信機会の細目を記述する情報が付随することができる。 | 对比文件[0122]段明确说明，接收到带内DL分配（授权）后，该分配附带调制类型、编码率等详细信息，用于标识PDSCH传输的目标接收机，这必然意味着UE需要根据该授权在PDSCH（DL数据信道）上接收信息。[0123]段同样明确说明，接收到带内UL授权后，该授权附带详细信息，用于标识PUSCH传输的目标发射机并描述下一次UL传输机会的细节，这必然意味着UE需要根据该授权在PUSCH（UL数据信道）上发送信息。因此，该特征被对比文件直接公开。 |
| **技术特征V：根据权利要求21所述的方法，其中，所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)，并且其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)。** <br>《未公开》 | （对比文件未提及“窄带物理上行链路共享信道(NPUSCH)”和“窄带物理下行链路共享信道(NPDSCH)”这些特定术语） | 与技术特征T类似，对比文件使用了PUSCH和PDSCH等通用术语来描述上行和下行数据信道，即使在低带宽操作背景下。但它没有使用NB-IoT标准中特定的“窄带物理上行链路共享信道(NPUSCH)”和“窄带物理下行链路共享信道(NPDSCH)”这两个术语。虽然功能对应，但具体名称未被公开。 |
| **技术特征W：根据权利要求11所述的方法，其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)，所述HARQ-ACK包括混合自动重传请求(HARQ)确认或否定确认，并且所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)。** <br>《未公开》 | （对比文件未提及NPDSCH和NPUSCH这两个特定术语） | 该特征组合了技术特征L、V的内容。对比文件公开了HARQ-ACK包括ACK/NACK（特征L），但未公开“窄带物理下行链路共享信道(NPDSCH)”和“窄带物理上行链路共享信道(NPUSCH)”这两个特定术语（特征V）。因此，作为一个整体，该技术特征未被对比文件公开。 |
<<<A>>><<<B>>><<<C>>><<<D>>><<<E>>><<<H>>><<<L>>><<<Q>>><<<R>>><<<S>>><<<U>>>