返回项目页面
对比文件列表
3gpp文件_+++B_G_H_I_K_L_M_O_P_Q_R_S_T_U_V_W_a_b_c_d_e_f_j_n+++.docx
2026-02-01 01:03
发明公开_EP2761955A1 DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH_+++A_B_T_U_q_r_s_v+++.docx
2026-02-01 01:03
发明公开_EP3247160A1 DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH_+++A_B_D_L_Q_R_S_U_V_W_c_e_t+++.docx
2026-02-01 01:03
发明申请_US20130083753A1 DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH_+++A_B_L_Q_R_S_T_U_V_W+++.docx
2026-02-01 01:03
发明申请_US20170141901A1 SOUNDING REFERENCE SIGNAL TRANSMISSIONS IN ENHANCED MACHINE TYPE COMMUNICATION_+++A_Q_R_S+++.docx
2026-02-01 01:03
发明申请_WO2013049768A1 DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH_+++A_R_S_U_b_q_t_v_w+++.docx
2026-02-01 01:03
发明申请_WO2017014549A1 하향링크 제어 정보 수신 방법 및 사용자기기와, 하향링크 제어 정보 전송 방법 및 기지국_+++A_B_Q_R_S_T_U_V_W+++.docx
2026-02-01 01:03
发明授权_EP2761955B1 DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH_+++A_B_q_r_s_t_u_v+++.docx
2026-02-01 01:03
发明专利_CA2850569A1 DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH_+++A_B_U_q_r_s+++.docx
2026-02-01 01:03
发明专利_JP6122855B2 縮小されたチャネル帯域幅を使用するデバイス通信_+++A_B_D_R_S_c_e_f_h_l_q_t_u_v_w+++.docx
2026-02-01 01:03
发明专利_JP2014531856A 縮小されたチャネル帯域幅を使用するデバイス通信_+++A_B_C_D_E_H_L_Q_R_S_U+++.docx
2026-02-01 01:03
发明专利_JP2017139796A 縮小されたチャネル帯域幅を使用するデバイス通信_+++A_B_D_Q_R_S_T_U_V_W+++.docx
2026-02-01 01:03
发明专利_SG11201401068SA DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH_+++A_D_Q_R_S_T_U_V_b+++.docx
2026-02-01 01:03
发明专利_TW201330558A 使用減少頻道頻寬裝置通訊_+++A_B_D_U_q_s+++.docx
2026-02-01 01:03
发明申请_US20130083753A1 DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH_+++A_B_L_Q_R_S_T_U_V_W+++.docx

对比文件名称:发明申请_US20130083753A1 DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH

目标专利名称:用于窄带操作的上行链路和下行链路授权

本次调用的模型名称:专利创造性评估模型

技术特征描述以及公开性判断结果对比文件原文引用公开性论述
A: 一种用于由用户设备(UE)进行无线通信的方法 《隐含公开》[0003] 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).对比文件[0003]段明确公开了为支持UE和/或低成本MTC设备与全带宽网络之间使用减少的信道带宽进行无线通信的系统和方法。具体实施例描述了设备可以接收诸如下行链路分配和/或上行链路授权的带内分配。这公开了一种由设备(即UE)执行的无线通信方法。虽然该段未使用“用户设备(UE)进行无线通信的方法”的精确措辞,但其描述的“device”在上下文(如[0003]开头)中明确包括UE,且整体技术方案就是关于设备(UE/MTC)在窄带中的通信操作。因此,本领域技术人员可以直接且明确地确定对比文件公开了由UE执行无线通信的方法。
B: 针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道 《直接公开》[0003] ... 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).对比文件[0003]段直接描述了设备可以基于接收到的带内分配(下行链路分配和/或上行链路授权)来监视网络提供的一个或多个传输,并且明确指出监视发生在窄带或减少的信道带宽中。这直接对应于目标专利特征B中“针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道”。设备为了接收DL分配或UL授权,必然需要监视承载这些授权的控制信道(如PDCCH、ePDCCH等)。因此,该技术特征被对比文件直接公开。
C: 接收交织的在各自的子帧中的UL授权和DL授权 《未公开》未找到直接或隐含公开“交织的”UL和DL授权的内容。对比文件提到了设备可以接收DL分配和UL授权(例如[0003], [0155], [0156], [0170]),但未描述这些授权在时间上是“交织的”(即一个UL授权之后紧接着一个DL授权,或一个DL授权之后紧接着一个UL授权),也未明确提及授权位于“各自的子帧中”。图21展示了DL和UL授权的示例,但未体现“交织”特性。对比文件虽然公开了设备可以接收DL分配和UL授权,但未公开这些授权是“交织的”这一特定时序关系。目标专利说明书中(如[0112]段)明确“交织的UL和DL授权”旨在支持TDD模式下的交织DL/UL传输,或提高FDD的传输效率,这是一个特定的调度方案。对比文件未教导或暗示以交织方式连续发送UL和DL授权。本领域技术人员阅读对比文件后,无法直接确定或通过合理推理推断出接收“交织的”UL和DL授权这一技术特征。因此,该特征既未被直接公开,也未被隐含公开。
D: 以及响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息。 《未公开》由于特征C“接收交织的在各自的子帧中的UL授权和DL授权”未被公开,因此基于此接收动作的响应动作“发送或接收信息”也未被公开。对比文件虽然描述了设备基于接收到的分配/授权来发送或接收(例如[0155], [0156], [0177]),但该分配/授权并非“交织的”。该特征依赖于特征C。既然特征C中“交织的”授权未被公开,那么“响应于所接收的交织的...授权来发送或接收信息”这一整体动作在对比文件中也不存在。对比文件中设备响应于授权进行发送/接收的动作是针对非交织的授权。因此,该技术特征未被公开。
E: 在UL授权之后接收DL授权作为下一个授权,或者在DL授权之后接收UL授权作为下一个授权。 《未公开》未找到直接或隐含公开授权顺序为“在UL授权之后接收DL授权作为下一个授权”或“在DL授权之后接收UL授权作为下一个授权”的内容。该特征是特征C“交织的”授权的具体实现方式。对比文件未公开“交织的”授权,因此也不可能公开这种特定的交织顺序。本领域技术人员无法从对比文件中推导出这种特定的、连续的UL-DL或DL-UL授权顺序。
F: 所述UE监视控制信道搜索空间,并且在UL授权之后并在响应于所述UL授权的在UL数据信道上所述发送信息的开始之后,接收DL授权作为下一个授权。 《未公开》未找到直接或隐含公开在UL数据传输开始之后接收DL授权作为下一个授权的内容。对比文件提到了监视搜索空间(例如[0216])以及接收UL和DL授权,但未将这两者与UL数据传输的开始时刻关联起来,也未描述在UL数据传输开始后接收下一个(DL)授权。该特征是一个非常具体的时序和行为描述,涉及监视搜索空间、UL授权、UL数据传输开始、然后接收DL授权。对比文件未描述这种精确的、依赖于UL数据传输开始的授权接收时序。因此,该特征未被公开。
G: 在所述UE在其中在所述UL数据信道上发送信息的子帧之后并在用于DL通信的子帧之前的子帧用作保护子帧。 《未公开》未找到任何关于“保护子帧”用于UL到DL切换的公开内容。该特征涉及TDD操作中用于切换的保护子帧的具体使用。对比文件全文未提及“保护子帧”的概念。因此,该特征未被公开。
H: 所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持一个或多个混合自动重传请求(HARQ)过程。 《未公开》对比文件提到了HARQ(例如[0115], [0408], [0409]),但未将其与“交织的UL和DL授权中的每一个授权”相关联。由于“交织的授权”本身未被公开(特征C),因此关于此类授权支持HARQ过程的特征也无法被公开。该特征是对“交织的授权”的进一步限定。基础特征(交织授权)未被公开,因此其附加属性(支持一个或多个HARQ过程)在对比文件中也没有对应基础。即使对比文件提到了HARQ的一般概念,也并未将其应用于“交织的授权”这一特定场景。
I: 所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持两个HARQ过程。 《未公开》未找到关于授权支持“两个HARQ过程”的公开内容。对比文件提及HARQ,但未指定每个授权支持的具体HARQ过程数量为两个。该特征是对特征H的进一步具体化(支持两个HARQ过程)。由于特征H未被公开,且对比文件未提及“两个HARQ过程”的具体支持,因此该特征未被公开。
J: 所述UE经由能力信令指示对以下至少一者的支持:针对每个UL授权或DL授权的两个HARQ进程,或UL授权和DL授权的交织。 《未公开》对比文件提到了能力信令(例如[0175], [0329]),但未提及UE通过能力信令指示对“两个HARQ进程”或“UL授权和DL授权的交织”的支持。该特征涉及UE通过信令指示对特定功能(两个HARQ进程或交织授权)的支持。对比文件未公开“交织的授权”(特征C)和“两个HARQ进程”(特征I),因此也不可能公开UE指示支持这些功能。对比文件中能力信令可能用于其他目的(如指示减少的带宽支持),但非此特定组合。
K: 响应于所述响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息,识别冲突,所述冲突包括以下至少一者:UL数据信道和DL数据信道之间的冲突,或 UL数据信道与混合ARQ确认(HARQ‑ACK)信令之间的冲突。 《未公开》未找到任何关于识别UL数据信道与DL数据信道之间冲突,或UL数据信道与HARQ-ACK信令之间冲突的公开内容。该特征涉及在交织授权场景下处理特定冲突。由于“交织的授权”场景本身未被对比文件公开(特征C),因此在该场景下可能出现的冲突及其识别方法也未被公开。对比文件未讨论这些特定类型的冲突。
L: 所述HARQ‑ACK信令包括确认或否定确认(NACK),并且其中,所述HARQ‑ACK信令是针对所述DL数据信道的。 《隐含公开》[0115] ... the PHICH may be used to transmit ACK or NACK corresponding to the PUSCH transmitted in an uplink subframe. <br> [0408] ... a network such as LTE may transmit PHICH in the downlink to indicate the hybrid-ARQ acknowledgements in response to UL data packet transmission. <br> [0409] ... the HARQ ACK/NACK in response to UL data packet transmission may be retransmitted in the downlink. <br> [0415] ... the network such as LTE may transmit PUCCH in the uplink to indicate the hybrid-ARQ acknowledgements in response to DL data packet transmission.对比文件多处提及HARQ确认(ACK/NACK)信令。[0115]、[0408]、[0409]描述了针对上行链路数据传输(PUSCH)的下行链路HARQ确认(PHICH)。[0415]描述了针对下行链路数据传输的上行链路HARQ确认(PUCCH)。虽然目标专利特征L中“HARQ-ACK信令是针对所述DL数据信道的”更具体地指向针对DL数据的确认,但对比文件[0415]明确公开了响应于DL数据包传输的HARQ确认,这隐含了该确认是针对DL数据信道的。本领域技术人员可以合理推断,在无线通信系统中,HARQ确认信令自然包括ACK或NACK,并且可以针对DL数据信道。因此,该技术特征被对比文件隐含公开。
M: 所述冲突包括所述UL数据信道和所述DL数据信道之间的所述冲突,所述方法还包括以下至少一个步骤:确定使用所述UL数据信道和所述DL数据信道中的一者,或对于在所述UL数据信道和所述DL数据信道之间冲突的子帧,确定使用所述UL数据信道和所述DL数据信道中的一者的所述子帧。 《未公开》未找到关于在UL和DL数据信道冲突时确定使用其中一者的公开内容。该特征是针对特定冲突(UL与DL数据信道冲突)的解决步骤。对比文件未公开此类冲突,因此也未公开解决此类冲突的具体步骤(如确定使用其中一者)。
N: 所述确定使用的步骤是至少部分地基于能量度量阈值的。 《未公开》未找到在冲突解决中基于“能量度量阈值”进行确定的任何公开内容。该特征限定了冲突解决决策的一个具体依据(能量度量阈值)。对比文件未公开冲突解决,更未提及使用能量度量阈值作为决策依据。
O: 所述冲突包括所述UL数据信道与所述HARQ‑ACK信令之间的冲突,所述方法还包括以下至少一个步骤:对于在所述UL数据信道和所述HARQ‑ACK信令之间冲突的子帧,确定传送所述HARQ‑ACK信令,或者将所述HARQ‑ACK信令与所述UL数据信道复用。 《未公开》未找到关于UL数据信道与HARQ-ACK信令冲突,或在此冲突下确定传送HARQ-ACK信令或将其与UL数据信道复用的公开内容。该特征是针对另一种特定冲突(UL数据信道与HARQ-ACK冲突)的解决步骤。对比文件未公开此类冲突,因此也未公开相应的解决步骤。
P: 所述将所述HARQ‑ACK信令与所述UL数据信道复用包括:对于在所述UL数据信道和所述HARQ‑ACK信令之间冲突的子帧,用所述HARQ‑ACK信令调制所述UL数据信道的解调参考信号(DMRS)。 《未公开》未找到关于用HARQ-ACK信令调制UL数据信道的DMRS的公开内容。该特征是实现特征O中“复用”的一种非常具体的技术手段。由于特征O未被公开,且该具体复用手段也未在对比文件中提及,因此该特征未被公开。
Q: 所述UE被配置用于窄带物联网(NB‑IoT)。 《隐含公开》[0002] ... current wireless communication systems do not support providing information such as channel information including control channel information, uplink information, downlink information, and the like on a reduced channel bandwidth. <br> [0003] 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... <br> [0058] Systems and/or methods for supporting reduced channel bandwidth in wireless communications using devices such as UEs and/or low cost Machine-Type Communications (MTC) devices may be disclosed herein. <br> [0102] ... an example for the application of wireless communications technology may include Machine-Type Communications (MTC). <br> [0103] ... a low cost device such as a UE or MTC device ... <br> 全文多处提及MTC设备、低成本设备、减少带宽操作。对比文件的核心主题就是支持使用减少信道带宽的设备(如低成本MTC设备)进行通信。窄带物联网(NB-IoT)是MTC和IoT通信的一种重要实现方式,通常也在减少的带宽(如180kHz)上操作。虽然对比文件未明确使用“NB-IoT”这一术语,但其描述的“low cost MTC device”、“reduced channel bandwidth”操作与本领域公知的NB-IoT设备的特征和操作环境高度重合。本领域技术人员阅读对比文件后,可以合理推断其所描述的支持减少带宽的MTC/UE通信方案可以应用于或包括NB-IoT场景。因此,该技术特征被对比文件隐含公开。
R: 所述UE被配置用于时分双工(TDD)操作。 《隐含公开》[0064] ... The communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. <br> [0065] ... 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> [0129] ... the SIB 1 may provide ... certain operating parameters such as the TDD UL/DL configuration (e.g. for TDD only) ...对比文件[0064]提及系统可以采用多种多址方案,包括TDMA(时分多址),这暗示了系统支持基于时间划分的通信。[0065]提到系统可以实现E-UTRA(即LTE),而LTE标准支持TDD和FDD两种双工模式。[0129]更直接指出SIB1可以提供TDD UL/DL配置,这明确意味着网络和UE可以配置用于TDD操作。虽然对比文件没有明确说“所述UE被配置用于TDD操作”,但公开了系统支持TDD模式以及UE可以从系统信息获得TDD配置。本领域技术人员可以合理推断,在支持TDD的系统中,UE可以被配置用于TDD操作。因此,该特征被隐含公开。
S: 所述UE被配置用于频分双工(FDD)操作。 《隐含公开》[0064] ... The communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. <br> [0065] ... 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> 图3描述了用于FDD的示例帧结构300。对比文件[0064]提及系统可以采用FDMA(频分多址),这暗示了基于频率划分的通信。[0065]提到系统可以实现E-UTRA(LTE),而LTE标准支持FDD和TDD。图3明确示出了“用于频分双工(FDD)的示例性帧结构300”。虽然对比文件没有明确说“所述UE被配置用于FDD操作”,但公开了系统支持FDD模式(如图3)以及UE可以在这样的系统中操作。本领域技术人员可以合理推断,在支持FDD的系统中,UE可以被配置用于FDD操作。因此,该特征被隐含公开。
T: 所述控制信道包括窄带物理下行链路控制信道(NPDCCH)。 《隐含公开》[0058] ... To support such reduced channel bandwidth, inband assignment of downlink (DL) and/or uplink (UL) transmission resources, PCFICH and/or PDCCH over zero-power CSI-RS in a data region, PCFICH, PHICH, and/or PDCCH transmission in a control region, multiplexing control and/or data transmission, and/or network configuration for the UE or MTC device may be provided and/or used as described herein. <br> [0240] ... a 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.对比文件[0058]和[0240]提到了用于MTC设备的“M-PDCCH”(MTC物理下行链路控制信道)。M-PDCCH是适用于窄带或减少带宽MTC设备的控制信道。目标专利中的“窄带物理下行链路控制信道(NPDCCH)”是NB-IoT标准中对应的窄带控制信道。虽然术语不同(M-PDCCH vs NPDCCH),但两者在概念上都是为窄带操作设计的物理下行链路控制信道。本领域技术人员可以理解,对比文件中为减少带宽MTC设备描述的控制信道(M-PDCCH)与目标专利中NB-IoT的NPDCCH属于同一类技术手段,即用于窄带设备的控制信道。因此,该特征被对比文件隐含公开。
U: 所述发送信息包括:响应于所接收的UL授权,在UL数据信道中发送信息;并且其中,所述接收信息包括响应于所述DL授权在DL数据信道中接收信息。 《直接公开》[0155] ... a device (e.g. a low-cost device that may support a reduced bandwidth) such as a UE or MTC device may receive an inband UL grant for an upcoming PUSCH transmission as part of the signaling that may be carried in the Data Region of a subframe. ... Similarly, the inband UL grant may be accompanied by information describing the specifics of the upcoming UL transmission opportunity such as the modulation type, coding rate, RV, a number of transport blocks, antenna encoding formats or transmission schemes, and the like. <br> [0154] ... a low-complexity device such as a UE or MTC device may receive an inband DL assignment that may identify an intended receiver of a PDSCH transmission through inband signaling that may be carried in a Data Region of a subframe. The inband DL assignment ... may be accompanied by information describing the specifics of the transmission such as a modulation type, a coding rate, RV, a number of transport blocks, antenna encoding formats or transmission schemes, and the like.对比文件[0155]直接公开了设备(如UE或MTC设备)可以接收用于即将到来的PUSCH传输的带内UL授权,并基于该授权进行上行链路传输(即发送信息)。[0154]直接公开了设备可以接收标识PDSCH传输预期接收者的带内DL分配,并基于该分配接收下行链路传输(即接收信息)。这完全对应于目标专利特征U:响应于UL授权在UL数据信道(PUSCH)中发送信息,以及响应于DL授权在DL数据信道(PDSCH)中接收信息。因此,该技术特征被对比文件直接公开。
V: 所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH),并且其中,所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)。 《隐含公开》[0155] ... a device ... may receive an inband UL grant for an upcoming PUSCH transmission ... <br> [0154] ... a low-complexity device ... may receive an inband DL assignment that may identify an intended receiver of a PDSCH transmission ... <br> 结合特征Q的论述,对比文件公开了用于MTC/窄带操作的PUSCH和PDSCH。对比文件[0155]和[0154]明确提到了PUSCH和PDSCH作为UL和DL数据信道。同时,如特征Q所述,对比文件的整体技术方案针对的是减少带宽的MTC/低成本设备通信。在窄带操作(如NB-IoT或eMTC)的上下文中,用于窄带设备的物理上行链路共享信道和物理下行链路共享信道通常被称为NPUSCH和NPDSCH(在NB-IoT中)或M-PUSCH/M-PDSCH等。虽然对比文件使用了“PUSCH”和“PDSCH”的通用术语,但鉴于其应用场景是减少带宽的MTC设备,本领域技术人员可以合理推断,这些信道在窄带操作环境下就是窄带版本的共享信道(即NPUSCH和NPDSCH或其等效信道)。因此,该特征被对比文件隐含公开。
W: 所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH),所述HARQ‑ACK包括混合自动重传请求(HARQ)确认或否定确认,并且所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)。 《隐含公开》该特征实质上是特征L、V的组合。特征L(HARQ-ACK信令的性质)已被隐含公开,特征V(NPUSCH/NPDSCH)已被隐含公开。因此,该组合特征也被隐含公开。如特征L和V的论述,对比文件隐含公开了HARQ-ACK信令包括ACK/NACK,并且隐含公开了在窄带操作上下文中的UL和DL数据信道对应于NPUSCH和NPDSCH。因此,本领域技术人员可以从对比文件中合理推断出该组合特征。

<<<A>>><<<B>>><<<L>>><<<Q>>><<<R>>><<<S>>><<<T>>><<<U>>><<<V>>><<<W>>>

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

网站备案号:渝ICP备2023012882号


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