返回项目页面
对比文件列表
2007-05-09_EP1784035A_发明公开_EP1784035A1 A method for connection re-establishment in a mobile communication system_+++c+++.docx
2026-06-17 01:26
2008-08-14_KR1020080075162A_发明公开_KR1020080075162A 이동 통신 시스템에서의 접속 재설정 방법 및 이동 통신시스템을 위한 네트워크 개체_+++c+++.docx
2026-06-17 01:26
2013-02-21_WO2013023975A_发明申请_WO2013023975A1 SUSPENDING A CONNECTION IN A WIRELESS COMMUNICATION SYSTEM_+++A_C_F_G+++.docx
2026-06-17 01:26
2013-05-16_TW201320679A_发明专利_TW201320679A 處置無線通信系統中之一連接_+++F_a_c+++.docx
2026-06-17 01:26
2014-04-17_KR1020140046071A_发明公开_KR1020140046071A 무선 통신 시스템에서 접속의 핸들링_+++C_F_G_a+++.docx
2026-06-17 01:26
2014-04-29_KR1020140050724A_发明公开_KR1020140050724A 무선 통신 시스템에서 접속의 핸들링_+++C_G_f+++.docx
2026-06-17 01:26
2015-03-19_US2015080006A_发明申请_US20150080006A1 WIRELESS COMMUNICATIONS SYSTEM, WIRELESS STATION, BASE STATION, AND COMMUNICATIONS METHOD_+++A_B_C_D_E_F_G_a_b_c_d_e_f_g+++.docx
2026-06-17 01:26
2015-12-11_KR101577153B_发明授权_KR101577153B1 무선 통신 시스템에서 접속의 핸들링_+++F_a_c_g+++.docx
2026-06-17 01:26
2016-01-27_CN105284081A_发明公开_CN105284081A 传输机制的转换方法、用户设备以及基站_+++A_C_E_F_b_d_g+++.docx
2026-06-17 01:26
2016-02-09_US9258839B_发明授权_US09258839B2 Other network component receiving RRC configuration information from eNB_+++A_C_F_G_b_e+++.docx
2026-06-17 01:26
2016-05-05_US2016128007A_发明申请_US20160128007A1 USER EQUIPMENT CONTEXT HANDLING WITH USER EQUIPMENT AUTONOMOUS MOBILITY_+++c+++.docx
2026-06-17 01:26
US2017070981A1_Description_20260426_1221_+++a_b_c_e_f_g+++.docx
2026-06-17 01:26
US2017070981A1_Description_20260426_1221_+++a_b_c_e_f_g+++.docx

好的,作为一名资深专利代理师,我将严格遵循您的指示,对对比文件US2017070981A1_Description_20260426_1221(下称D1)是否公开目标专利“728用于信令优化的寻呼增强CN109417772B”(下称目标专利)的权利要求技术特征进行严谨评估。

首先,明确本次评估的对比文件名称:**US2017070981A1_Description_20260426_1221**,目标专利名称:**728用于信令优化的寻呼增强CN109417772B**,以及本次调用的模型名称:本评估由资深专利代理师模型执行。

以下是根据您的要求创建的特征比对表格及详细分析。

### 特征比对表格

技术特征描述以及公开性判断结果对比文件原文引用(翻译成中文)公开性论述
**技术特征A:包括:通过网络元件标识无线电资源控制连接恢复请求过程要由用户设备使用以作为对寻呼消息的响应**<br><br>《隐含公开》**引用1(段落[0160])**: “在UE的RRC连接挂起时,UE执行小区选择和重选……UE可以监控寻呼信道……在接收到包含UE身份的寻呼消息时,UE将尝试恢复其挂起的RRC连接,如下所述。”<br><br>**引用2(段落[0161])**: “当DL数据到达网络……网络可以联系或寻呼UE……UE通过发送RRC连接恢复请求来响应寻呼”。<br><br>**引用3(段落[0166])**: “UE确定其挂起的RRC连接在其所在的小区是有效的。UE通过发送RRC连接恢复请求来启动RRC连接恢复过程。”D1没有明确记载网络元件“标识”RRC连接恢复请求过程作为对寻呼的响应。然而,D1详细描述了当UE处于RRC连接挂起状态时,网络为了传输下行数据(MT数据)会发起寻呼(引用1、2)。UE在收到该寻呼后,会尝试恢复(reactivate)挂起的连接,即通过发送“RRC连接恢复请求”(RRC Connection Reactivation Request)来响应(引用2、3)。<br><br>在D1的上下文中,网络(eNB/MME)发起寻呼的目的是为了触发UE恢复其挂起的连接,因此可以合理推断,网络必然知晓并“标识”了UE应当使用连接恢复过程来响应这个寻呼,否则寻呼将失去其预期的功能。尽管这种标识是隐式的(基于系统操作流程的约定),但本领域技术人员可以合理推断,对于处于挂起状态的UE,网络在发送寻呼时,其内在意图就是让UE使用RRC连接恢复请求过程。因此,该特征被D1隐含公开。
**技术特征B:在所述寻呼消息中,由所述网络元件向所述用户设备隐式地指示使用所述无线电资源控制连接恢复请求过程。**<br><br>《隐含公开》**引用1(段落[0160])**: “UE将尝试恢复其挂起的RRC连接……”<br><br>**引用2(段落[0161])**: “当DL数据到达网络……网络可以联系或寻呼UE……UE通过发送RRC连接恢复请求来响应寻呼”。D1没有明确记载在寻呼消息中包含一个显式的指示字段来告知UE使用恢复过程。然而,D1的整个系统框架是建立在“RRC连接挂起”和“RRC连接恢复”这一对概念上的。当一个UE处于挂起状态时,网络发起的寻呼(Paging)本身就是一个隐式的触发信号,指示UE执行与之关联的RRC连接恢复过程(引用1、2)。<br><br>在D1中,寻呼消息的作用不仅仅是通知UE有下行数据,更重要的是触发UE启动恢复流程。这种功能上的关联性构成了一种隐式指示。本领域技术人员可以理解,当网络对一个处于挂起状态的UE发送寻呼时,寻呼消息本身就隐含了“请使用RRC连接恢复请求过程进行响应”的指示。这完全符合目标专利中关于隐式指示的定义(即UE基于寻呼消息中的各种指示来确定响应过程)。因此,该特征被D1隐含公开。
**技术特征C:其中所述过程是基于所述用户设备的上下文的可用性来标识的。**<br><br>《隐含公开》**引用1(段落[0165])**: “RRC连接恢复可以由UE 101中生成的UL数据触发,或者由接收到指示网络有DL数据等待传递的寻呼或DL数据通知消息触发。当这种情况发生时,UE首先根据其当前所在的小区确定其挂起的RRC连接是否有效。”<br><br>**引用2(段落[0166]-[0167])**: 描述了当UE确定挂起的RRC连接有效([0166])和无效([0167])时的不同处理流程。当有效时,使用恢复过程;当无效时,释放连接并进入空闲模式,然后发起正常的RRC连接建立过程。D1明确记载了UE和网络(通过eNB)会基于UE上下文的可用性来决定后续的信令过程。引用1指出,UE会首先判断其挂起的RRC连接(即UE上下文)在当前服务小区是否有效。根据这个判断结果(即上下文的可用性),UE决定是使用RRC连接恢复过程(上下文有效,[0166])还是使用全新的RRC连接建立过程(上下文无效,[0167])。<br><br>虽然D1主要从UE角度描述,但网络侧(eNB)同样存储了UE上下文,并且网络在发起寻呼时也依赖该上下文的可用性来判断是否能够成功恢复连接(例如,D1的图20-22描述了因上下文无效而导致恢复失败的情况)。因此,网络标识使用何种过程(恢复或建立)必然是基于其对UE上下文可用性的判断。目标专利的特征C是“所述过程是基于用户设备的上下文的可用性来标识的”,这在D1中得到了充分的体现和隐含公开。
**技术特征D:其中所述隐式地指示包括使用经由控制平面的数据、经由用户平面的数据、正常数据、小数据、短连接、高优先级数据、低优先级数据或信令中的至少一种。**<br><br>《未公开》D1全文未提及在寻呼消息中通过区分数据类型(如控制平面数据、用户平面数据、小数据等)来隐式指示UE应使用的响应过程。D1中,网络对挂起UE的寻呼触发的是统一的RRC连接恢复请求过程。D1没有描述网络可以根据将要发送的数据类型(如CP数据、UP数据、小数据等)在寻呼消息中隐式地指示UE使用不同的响应过程(如RRC连接建立请求、RRC连接恢复请求等)。D1的寻呼触发机制与目标专利中的基于数据类型的隐式指示机制完全不同。因此,该技术特征未被D1直接或隐含公开。
**技术特征E:在寻呼消息中,由用户设备从网络元件接收使用无线电资源控制连接恢复请求过程作为对所述寻呼消息的响应的隐式的指示。**<br><br>《隐含公开》**引用1(段落[0160])**: “在接收到包含UE身份的寻呼消息时,UE将尝试恢复其挂起的RRC连接……”<br><br>**引用2(段落[0161])**: “UE通过发送RRC连接恢复请求来响应寻呼”。与特征B的分析逻辑一致。D1中,处于挂起状态的UE在接收到寻呼消息后,其预定义的行为就是尝试恢复挂起的RRC连接,并发送RRC连接恢复请求(引用1, 2)。UE能够理解这个寻呼消息意味着网络期望它启动恢复过程,而不是重新建立一个新的连接。因此,该寻呼消息对于UE来说,构成了一个隐式的指示,即“请使用RRC连接恢复请求过程进行响应”。所以,该特征被D1隐含公开。
**技术特征F:使用所述无线电资源控制连接恢复请求过程来对所述寻呼消息进行响应。**<br><br>《隐含公开》**引用1(段落[0160])**: “在接收到包含UE身份的寻呼消息时,UE将尝试恢复其挂起的RRC连接,如下所述。”<br><br>**引用2(段落[0161])**: “UE通过发送RRC连接恢复请求来响应寻呼”。<br><br>**引用3(段落[0166])**: “UE通过发送RRC连接恢复请求来启动RRC连接恢复过程。”D1明确记载了UE收到寻呼消息后,会尝试恢复挂起的RRC连接,并且通过发送“RRC连接恢复请求”(RRC Connection Reactivation Request)来响应这个寻呼(引用1, 2, 3)。这与目标专利中“使用所述无线电资源控制连接恢复请求过程来对所述寻呼消息进行响应”的描述完全一致。因此,该特征被D1隐含公开(在D1中,这是UE的自然行为,而非根据一个明确的指示执行,但行为本身是公开的)。
**技术特征G:其中对所述寻呼消息进行响应包括在所述寻呼消息中没有显式指示的情况下,基于服务小区中的所述用户设备的上下文的可用性对信令过程的选择。**<br><br>《隐含公开》**引用1(段落[0165])**: “UE首先根据其当前所在的小区确定其挂起的RRC连接是否有效。”<br><br>**引用2(段落[0166]-[0167])**: 基于有效性判断,UE选择不同的过程:<br> - 上下文有效([0166]):发送RRC连接恢复请求。<br> - 上下文无效([0167]):释放挂起的连接,进入空闲模式,并启动正常的RRC连接建立过程。<br><br>**引用3(段落[0052])**: 描述了正常的寻呼过程,其中没有涉及挂起连接的恢复。D1明确公开了UE在响应寻呼时,其行为的核心是基于服务小区中UE上下文的可用性(即挂起的RRC连接是否有效)来选择一个信令过程(引用1)。当上下文有效时,选择RRC连接恢复请求过程(引用2);当上下文无效时,选择正常的RRC连接建立过程(引用2)。<br><br>重要的是,D1中并没有一个单独的显式指示来告知UE在收到寻呼时该选择哪个过程,UE完全是基于其对自身上下文可用性的判断来自主选择(引用1, 2)。这与目标专利的特征G“在所述寻呼消息中没有显式指示的情况下,基于服务小区中的所述用户设备的上下文的可用性对信令过程的选择”完全吻合。因此,该特征被D1隐含公开。

### 结论

经过严谨比对,对比文件D1(US2017070981A1_Description_20260426_1221)**隐含公开**了目标专利CN109417772B权利要求中的技术特征A、B、C、E、F、G。

具体而言,D1虽然未明确记载“网络元件标识过程”和“在寻呼消息中显式/隐式指示”,但其公开的RRC连接挂起与恢复系统框架下,网络发起寻呼以触发UE恢复连接、UE基于上下文可用性选择响应过程(恢复或建立)的机制,使得本领域技术人员能够毫无疑义地推断出D1实质上已经隐含公开了上述技术特征。然而,D1并未公开技术特征D中关于通过区分数据类型进行隐式指示的方案。

根据您的输出格式要求,结论如下:

<<<a>>><<<b>>><<<c>>><<<e>>><<<f>>><<<g>>>

Powered by Django

网站备案号:渝ICP备2023012882号


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