对比文件名称：发明专利_JP6122855B2 縮小されたチャネル帯域幅を使用するデバイス通信
目标专利名称：用于窄带操作的上行链路和下行链路授权
模型名称：本次调用的模型
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：一种用于由用户设备(UE)进行无线通信的方法**<br>**判断结果：直接公开** | [0060] “例えば、与えられたサブフレーム（ＴＴＩ）において、ハンドセットは、ＤＣＩメッセージを探してＰＤＣＣＨを監視することができる。 ＤＬ割り当てを示すＤＣＩを受信することができた場合、ハンドセットは、その同じサブフレームのデータ領域内のＰＤＳＣＨを復調および復号しようと試みることができる。 同様に、ハンドセットは、サブフレームｎ内のＰＤＣＣＨ上のＵＬグラントを復号した場合、サブフレームｎ＋４でのＰＵＳＣＨのＵＬ送信を準備することができる。”<br>（译文：例如，在给定子帧（TTI）中，手机可以监视PDCCH以寻找DCI消息。 如果能够接收到指示DL分配的DCI，则手机可以尝试解调和解码同一子帧数据区域内的PDSCH。 同样，如果手机解码了子帧n中PDCCH上的UL授权，则可以准备在子帧n+4进行PUSCH的UL发送。） | 对比文件明确描述了由用户设备（UE，文中称为“ハンドセット”）执行的一系列无线通信动作，包括监视控制信道、接收下行链路（DL）分配或上行链路（UL）授权、以及根据授权发送或接收数据。这直接对应了由UE执行无线通信方法这一主题。 |
| **技术特征B：针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道**<br>**判断结果：直接公开** | [0102] “例えば、図１５に示されるように、ＭＴＣデバイスなどのデバイスは、システム帯域幅の一部しか読むことができない。”<br>（译文：例如，如图15所示，诸如MTC设备的设备只能读取系统带宽的一部分。）<br>[0108] “そのような縮小されたチャネル帯域幅をサポートするために、ダウンリンク（ＤＬ）および／若しくはアップリンク（ＵＬ）送信リソースのインバンド割り当て...を、本明細書で説明するように、提供すること、および／または使用することができる。”<br>（译文：为了支持这种缩小的信道带宽，可以如本文所述提供和/或使用下行链路（DL）和/或上行链路（UL）传输资源的带内分配...）<br>[0122] “例えば、一実施形態では、ＵＥまたはＭＴＣデバイスなどの複雑さが低いデバイスは、サブフレームのデータ領域内で搬送できるインバンドシグナリングを通してＰＤＳＣＨ送信の対象受信機を識別できる、インバンドＤＬ割り当てを受信することができる。”<br>（译文：例如，在一个实施例中，诸如UE或MTC设备的低复杂度设备可以接收带内DL分配，该分配能够通过可在子帧数据区域内传送的带内信令来识别PDSCH传输的目标接收机。）<br>[0123] “さらなる一実施形態では、ＵＥまたはＭＴＣデバイスなどのデバイス（例えば、縮小された帯域幅をサポートできる低コストデバイス）は、サブフレームのデータ領域内で搬送できるシグナリングの一部として、次回のＰＵＳＣＨ送信のためのインバンドＵＬグラントを受信することができる。”<br>（译文：在进一步的实施例中，诸如UE或MTC设备的设备（例如，支持缩小带宽的低成本设备）可以作为可在子帧数据区域内传送的信令的一部分，接收用于下一次PUSCH传输的带内UL授权。） | 对比文件多次明确提及设备（如MTC UE）在缩小的带宽（即系统带宽的一部分，可理解为窄带）内操作，并接收DL分配和UL授权。虽然授权是通过“インバンドシグナリング”（带内信令）在数据区域内传送，而非传统控制区域，但这仍然是在窄带内传送控制信息（授权）的一种形式。因此，对比文件直接公开了在系统带宽的窄带中针对UL或DL授权监视控制信道（此处控制信道体现为数据区域内的带内信令）的技术特征。 |
| **技术特征C：接收交织的在各自的子帧中的UL授权和DL授权**<br>**判断结果：隐含公开** | [0124] “本明細書で説明するように、サブフレームのデータ領域内で搬送されるインバンドシグナリングを監視することに、ＵＥまたはＭＴＣデバイスなどの複数のデバイス（例えば、縮小された帯域幅をサポートできる低コストデバイス）を割り当てることができる。 また、ＤＬ ＰＤＳＣＨおよびＵＬ ＰＵＳＣＨ送信リソースを、全てのスケジューリングインスタンスまたはＴＴＩにおいて、これらの複数のデバイスの間で互いから独立して割り当てることができる。 例えば、第１のＭＴＣデバイスなどの第１のデバイスには、インバンドシグナリングを通してＤＬ ＰＤＳＣＨ送信を割り当てることができ、一方、第２のＭＴＣデバイスなどの第２のデバイスには、このインバンドシグナリングメッセージ内の付随または関連するＵＬ ＰＵＳＣＨ送信機会を割り当てることができる。”<br>（译文：如本文所述，可以将多个设备（例如，支持缩小带宽的低成本设备），诸如UE或MTC设备，分配为监视在子帧数据区域内传送的带内信令。 此外，可以在所有调度实例或TTI中，在这些多个设备之间彼此独立地分配DL PDSCH和UL PUSCH传输资源。 例如，可以向第一设备（诸如第一MTC设备）分配通过带内信令进行的DL PDSCH传输，同时，可以向第二设备（诸如第二MTC设备）分配此带内信令消息内伴随或关联的UL PUSCH传输机会。） | 对比文件描述了在同一“インバンドシグナリングメッセージ”（带内信令消息）或同一调度实例/TTI中，可以独立地向不同设备分配DL资源和UL资源。这意味着网络有能力在同一个控制信令时机（可对应一个子帧内的资源）中调度一个DL传输和一个UL传输。本领域技术人员可以合理推断，对于单个UE而言，网络同样可以在连续的或交织的子帧中，通过类似的带内信令机制向该UE发送一个UL授权和一个DL授权，即接收交织的UL和DL授权。虽然未明确使用“交织”一词，但支持独立且可能交替分配DL和UL资源的能力隐含了接收交织授权的可能性。 |
| **技术特征D：以及响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息。**<br>**判断结果：直接公开** | [0060] （同特征A引用）<br>[0122] （同特征B引用）<br>[0123] （同特征B引用） | 对比文件明确描述了UE在接收到DL分配后，接收/解码PDSCH（即接收信息）；在接收到UL授权后，准备并发送PUSCH（即发送信息）。这是对授权做出响应的直接教导。结合对特征C“接收交织授权”的隐含公开论述，响应于此类授权发送或接收信息也是直接公开的。 |
| **技术特征E：根据权利要求1所述的方法，其中，接收所述交织的在各自的子帧中的UL授权和DL授权包括以下至少一者：在UL授权之后接收DL授权作为下一个授权，或者在DL授权之后接收UL授权作为下一个授权。**<br>**判断结果：隐含公开** | [0124] （同特征C引用） | 对比文件指出DL和UL资源可以在调度实例中独立分配。这种独立性意味着网络调度器可以自由决定在某个子帧分配UL授权，在紧接着的下一个子帧分配DL授权，或者反之。本领域技术人员基于资源独立分配的原理，可以合理推断出UL和DL授权可以以任意顺序（包括UL后DL或DL后UL）在连续的子帧中发送给UE，即授权顺序是交织的。 |
| **技术特征F：根据权利要求1所述的方法，其中，所述UE监视控制信道搜索空间，并且在UL授权之后并在响应于所述UL授权的在UL数据信道上所述发送信息的开始之后，接收DL授权作为下一个授权。**<br>**判断结果：隐含公开** | [0124] （同特征C引用）<br>[0126] “また、一実施形態では、例えば、ＬＴＥセルなどのセルを獲得した、若しくはＬＴＥセルなどのセルと同期した後、システム情報を獲得した後、および／またはネットワークに登録した後、続いて、ＤＬ割り当ておよび／またはＵＬグラントの発生を探してシステム帯域幅全体の特定の帯域幅部分を監視することに、ＵＥまたはＭＴＣデバイスなどのデバイスを割り当てることができる。”<br>（译文：此外，在一个实施例中，例如，在获取或与诸如LTE小区的小区同步之后、获取系统信息之后、和/或注册到网络之后，随后可以将诸如UE或MTC设备的设备分配为监视整个系统带宽的特定带宽部分，以寻找DL分配和/或UL授权的发生。） | 对比文件描述了UE监视特定带宽部分以寻找DL分配和UL授权。结合资源独立分配的能力（特征C、E），UE完全有可能在接收到一个UL授权并开始相应的UL数据传输后，在继续监视的过程中接收到下一个授权（可能是DL授权）。虽然没有明确描述“在UL数据传输开始之后接收DL授权”这一具体时序，但这是独立调度和连续监视场景下的合理且可能发生的情况，因此可以被隐含公开。 |
| **技术特征G：根据权利要求4所述的方法，其中，在所述UE在其中在所述UL数据信道上发送信息的子帧之后并在用于DL通信的子帧之前的子帧用作保护子帧。**<br>**判断结果：未公开** | 无 | 对比文件全文未提及在UL数据传输子帧和DL通信子帧之间使用“保护子帧”（Guard Subframe）的概念。此特征涉及特定的时序安排和硬件切换保护机制，在对比文件中既无直接记载，也无法从已公开内容中合理推断。 |
| **技术特征H：根据权利要求1所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持一个或多个混合自动重传请求(HARQ)过程。**<br>**判断结果：隐含公开** | [0066] “また、無線ネットワークは、ダウンリンクおよびアップリンク上のデータ伝送のためのハイブリッド自動再送要求（ＨＡＲＱ）をサポートすることができる。”（译文：此外，无线网络可以支持用于下行链路和上行链路上数据传输的混合自动重传请求（HARQ）。）<br>[0067] “実施形態では、ＰＨＩＣＨ（物理ハイブリッドＡＲＱインジケータチャネル）も提供すること、および／または使用することができる。 例えば、ＰＨＩＣＨは、アップリンクサブフレーム内で送信されるＰＵＳＣＨに対応するＡＣＫまたはＮＡＣＫを送信するために使用することができる。”（译文：在实施例中，也可以提供和/或使用PHICH（物理混合ARQ指示符信道）。 例如，PHICH可用于发送对应于在上行链路子帧中发送的PUSCH的ACK或NACK。） | 对比文件明确提到了HARQ是无线网络支持的标准功能，并描述了用于HARQ反馈的PHICH信道。在LTE及类似系统中，DL分配和UL授权通常与HARQ过程相关联以支持重传。因此，本领域技术人员可以合理推断，对比文件中描述的、通过带内信令传送的DL分配和UL授权，每一个都旨在支持一个或多个HARQ过程，这是此类系统数据传输的常规组成部分。 |
| **技术特征I：根据权利要求8所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持两个HARQ过程。**<br>**判断结果：未公开** | 无 | 对比文件虽然提到了HARQ，但从未具体说明每个授权支持特定数量的HARQ过程，尤其是“两个”HARQ过程。支持单个还是多个HARQ过程是特定的系统设计选择，对比文件未提供相关信息，无法直接确定或合理推断。 |
| **技术特征J：根据权利要求8所述的方法，其中，所述UE经由能力信令指示对以下至少一者的支持：针对每个UL授权或DL授权的两个HARQ进程，或UL授权和DL授权的交织。**<br>**判断结果：未公开** | 无 | 对比文件未提及UE通过能力信令（capability signaling）向网络指示其对于特定数量HARQ过程或交织授权支持的能力。此特征涉及特定的UE能力上报机制，在对比文件中没有记载。 |
| **技术特征K：根据权利要求1所述的方法，还包括：响应于所述响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息，识别冲突，所述冲突包括以下至少一者：UL数据信道和DL数据信道之间的冲突，或UL数据信道与混合ARQ确认(HARQ-ACK)信令之间的冲突。**<br>**判断结果：未公开** | 无 | 对比文件未涉及当UE响应于交织的UL和DL授权进行发送或接收时，可能出现的资源冲突（如UL数据信道与DL数据信道冲突，或UL数据信道与HARQ-ACK冲突）的识别或处理。此特征是关于冲突检测的特定UE行为，在对比文件中没有教导。 |
| **技术特征L：根据权利要求11所述的方法，其中，所述HARQ-ACK信令包括确认或否定确认(NACK)，并且其中，所述HARQ-ACK信令是针对所述DL数据信道的。**<br>**判断结果：隐含公开** | [0067] “例えば、ＰＨＩＣＨは、アップリンクサブフレーム内で送信されるＰＵＳＣＨに対応するＡＣＫまたはＮＡＣＫを送信するために使用することができる。”（译文：例如，PHICH可用于发送对应于在上行链路子帧中发送的PUSCH的ACK或NACK。） | 对比文件明确说明HARQ-ACK信令（通过PHICH）包括ACK或NACK。虽然该句例子是针对UL数据信道（PUSCH）的反馈，但HARQ机制本身是双向的。在LTE及类似系统中，同样存在针对DL数据信道（PDSCH）的HARQ-ACK反馈，通常通过PUCCH或PUSCH发送。本领域技术人员知晓HARQ-ACK信令可用于DL，因此“HARQ-ACK信令是针对所述DL数据信道的”这一限定可以被认为是系统中已知且隐含的技术常识。 |
| **技术特征M：根据权利要求11所述的方法，其中，所述冲突包括所述UL数据信道和所述DL数据信道之间的所述冲突，所述方法还包括以下至少一个步骤：确定使用所述UL数据信道和所述DL数据信道中的一者，或对于在所述UL数据信道和所述DL数据信道之间冲突的子帧，确定使用所述UL数据信道和所述DL数据信道中的一者的所述子帧。**<br>**判断结果：未公开** | 无 | 对比文件未提及在发生UL数据信道和DL数据信道冲突时，UE需要执行选择使用其中一者或选择冲突子帧使用的步骤。此冲突解决方法是特定的UE行为，在对比文件中没有公开。 |
| **技术特征N：根据权利要求13所述的方法，其中，所述确定使用的步骤是至少部分地基于能量度量阈值的。**<br>**判断结果：未公开** | 无 | 对比文件未提及基于“能量度量阈值”来进行任何选择或决策。此特征涉及特定的决策标准，在对比文件中没有依据。 |
| **技术特征O：根据权利要求12所述的方法，其中，所述冲突包括所述UL数据信道与所述HARQ-ACK信令之间的冲突，所述方法还包括以下至少一个步骤：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，确定传送所述HARQ-ACK信令，或者将所述HARQ-ACK信令与所述UL数据信道复用。**<br>**判断结果：未公开** | 无 | 对比文件未提及在发生UL数据信道与HARQ-ACK信令冲突时，UE需要执行确定传送HARQ-ACK或将其与UL数据信道复用的步骤。此冲突解决方法是特定的UE行为，在对比文件中没有公开。 |
| **技术特征P：根据权利要求15所述的方法，其中，所述将所述HARQ-ACK信令与所述UL数据信道复用包括：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，用所述HARQ-ACK信令调制所述UL数据信道的解调参考信号(DMRS)。**<br>**判断结果：未公开** | 无 | 对比文件未提及通过用HARQ-ACK信令调制UL数据信道的DMRS来实现复用的具体技术。此特征涉及非常具体的物理层复用方案，在对比文件中没有记载。 |
| **技术特征Q：根据权利要求1所述的方法，其中，所述UE被配置用于窄带物联网(NB-IoT)。**<br>**判断结果：隐含公开** | [0003] “（例えば、低ＬＴＥ ＵＥカテゴリデバイスを含む）ＵＥおよび／または低コストマシンタイプ通信（ＭＴＣ：Machine-Type Communication）デバイスなどのデバイスと、全帯域幅をサポートできるネットワーク（例えば、全帯域幅ネットワーク）との間の無線通信において、縮小されたチャネル帯域幅をサポートするための、システムおよび／または方法を提供することができる。”（译文：可以提供用于在设备（例如，包括低LTE UE类别设备的UE和/或低成本机器类型通信（MTC）设备）与能够支持全带宽的网络（例如，全带宽网络）之间的无线通信中支持缩小信道带宽的系统和方法。）<br>[0055] “本明細書で説明するように、ＵＥまたはＭＴＣデバイスなどの低コストデバイスは、限定することなく、より低いデータレート、より低い電力消費、およびより単純な実施など、一般的なＷＴＲＵ能力および機能のいくらかの低減を一般に含むことができ...”（译文：如本文所述，低成本设备（例如UE或MTC设备）通常包括一些通用WTRU能力和功能的降低，包括但不限于更低的数据速率、更低的功耗和更简单的实现...） | 对比文件通篇描述的是支持缩小信道带宽的低成本MTC设备。NB-IoT是3GPP标准中为物联网定义的一种特定类型的窄带、低成本MTC技术。虽然对比文件没有明确使用“NB-IoT”这个术语，但其描述的设备特征（低成本、窄带操作、适用于物联网场景）与NB-IoT设备的配置本质上是相同或高度重叠的。本领域技术人员能够合理推断，对比文件中描述的配置用于缩小带宽操作的MTC UE，包含了被配置用于NB-IoT的UE这一情形。 |
| **技术特征R：根据权利要求1所述的方法，其中，所述UE被配置用于时分双工(TDD)操作。**<br>**判断结果：直接公开** | [0066] “ＦＤＤ（周波数分割複信）とＴＤＤ（時分割複信）の両方について、ＬＴＥを構成することができる。”（译文：LTE可以配置为频分双工（FDD）和时分双工（TDD）两者。） | 对比文件明确提到系统支持TDD操作模式。因此，UE可以被配置用于TDD操作是直接公开的。 |
| **技术特征S：根据权利要求1所述的方法，其中，所述UE被配置用于频分双工(FDD)操作。**<br>**判断结果：直接公开** | [0066] “ＦＤＤ（周波数分割複信）とＴＤＤ（時分割複信）の両方について、ＬＴＥを構成することができる。”（译文：LTE可以配置为频分双工（FDD）和时分双工（TDD）两者。） | 对比文件明确提到系统支持FDD操作模式。因此，UE可以被配置用于FDD操作是直接公开的。 |
| **技术特征T：根据权利要求1所述的方法，其中，所述控制信道包括窄带物理下行链路控制信道(NPDCCH)。**<br>**判断结果：隐含公开** | [0102] “現在のところ、通常のＬＴＥチャネルなどの通常のチャネル上で、より小さな帯域幅または縮小された帯域幅をサポートできる、ＬＴＥデバイスまたはＵＥおよび／若しくはＭＴＣデバイスなどの、デバイスを動作させるときの問題は、デバイスがネットワークおよび／またはセルからＤＬ制御チャネルまたは信号を受信することができないこととすることができる。”（译文：当前，在能够在常规信道（例如常规LTE信道）上支持更小带宽或缩小带宽的设备（例如LTE设备或UE和/或MTC设备）操作时，问题可能是设备无法从网络和/或小区接收DL控制信道或信号。）<br>[0122] （同特征B引用，提及通过“インバンドシグナリング”接收DL分配） | 对比文件指出了在窄带操作中接收传统宽带控制信道（如PDCCH）的问题，并提出了在数据区域使用“インバンドシグナリング”（带内信令）作为替代方案来传送控制信息（DL分配、UL授权）。NPDCCH是NB-IoT中定义的窄带物理下行控制信道，其设计初衷正是为了在窄带内有效传送控制信息。虽然对比文件未明确命名“NPDCCH”，但其描述的、在窄带数据区域内用于传送控制信令的机制，其功能和作用与NPDCCH是相同的。本领域技术人员可以合理推断，在窄带物联网（NB-IoT）上下文中，这种控制信道就是NPDCCH或与之等效的实体。 |
| **技术特征U：根据权利要求1所述的方法，其中，所述发送信息包括：响应于所接收的UL授权，在UL数据信道中发送信息；并且其中，所述接收信息包括响应于所述DL授权在DL数据信道中接收信息。**<br>**判断结果：直接公开** | [0060] “ハンドセットは、サブフレームｎ内のＰＤＣＣＨ上のＵＬグラントを復号した場合、サブフレームｎ＋４でのＰＵＳＣＨのＵＬ送信を準備することができる。” （译文：如果手机解码了子帧n中PDCCH上的UL授权，则可以准备在子帧n+4进行PUSCH的UL发送。）<br>[0060] “ＤＬ割り当てを示すＤＣＩを受信することができた場合、ハンドセットは、その同じサブフレームのデータ領域内のＰＤＳＣＨを復調および復号しようと試みることができる。” （译文：如果能够接收到指示DL分配的DCI，则手机可以尝试解调和解码同一子帧数据区域内的PDSCH。） | 对比文件直接且明确地描述了UE在接收到UL授权后，在UL数据信道（PUSCH）上发送信息；在接收到DL分配（授权）后，在DL数据信道（PDSCH）上接收信息。这完全公开了特征U的内容。 |
| **技术特征V：根据权利要求21所述的方法，其中，所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)，并且其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)。**<br>**判断结果：隐含公开** | [0055] “...サポートされる最大受信（Ｒｘ）または送信（Ｔｘ）チャネル帯域幅を縮小することができ...” （译文：...可以缩小支持的最大接收（Rx）或发送（Tx）信道带宽...）<br>[0102] “例えば、図１５に示されるように、ＭＴＣデバイスなどのデバイスは、システム帯域幅の一部しか読むことができない。” （译文：例如，如图15所示，诸如MTC设备的设备只能读取系统带宽的一部分。） | 对比文件反复强调设备在缩小的带宽（窄带）内操作。在窄带物联网（如NB-IoT）的语境下，用于上行链路数据传输的共享信道被称为NPUSCH，用于下行链路数据传输的共享信道被称为NPDSCH。虽然对比文件在举例时使用了传统LTE的术语“PUSCH”和“PDSCH”，但结合其核心教导——为窄带操作设计，本领域技术人员可以合理推断，当应用于像NB-IoT这样的标准窄带系统时，这些数据信道对应的就是NPUSCH和NPDSCH。 |
| **技术特征W：根据权利要求11所述的方法，其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)，所述HARQ-ACK包括混合自动重传请求(HARQ)确认或否定确认，并且所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)。**<br>**判断结果：隐含公开** | 综合引用：[0067]（关于HARQ-ACK）、[0102]（关于窄带操作）、[0055]（关于窄带操作） | 此特征是对特征K中冲突所涉及信道的具体化。基于对特征L（HARQ-ACK针对DL）、特征V（NPUSCH/NPDSCH）的隐含公开分析，本领域技术人员可以合理推断，在窄带操作（如NB-IoT）场景下，如果存在特征K所描述的冲突，那么其中涉及的DL数据信道就是NPDSCH，UL数据信道就是NPUSCH，而HARQ-ACK就是针对NPDSCH的确认或否定确认。虽然冲突场景本身未被公开，但一旦考虑该场景，其中信道和信令的具体类型可以基于对比文件的其他教导进行合理推断。 |
<<<A>>><<<B>>><<<D>>><<<R>>><<<S>>>
<<<c>>><<<e>>><<<f>>><<<h>>><<<l>>><<<q>>><<<t>>><<<u>>><<<v>>><<<w>>>