返回项目页面
对比文件列表
2005-01-27_US2005021616A_发明申请_US20050021616A1 Method for managing sessions between network parties, methods, network element and terminal for managing calls_+++A_B_C_K_d_e_f_h_i_n_o_p_q_x+++.docx
2026-07-18 15:40
2006-02-16_US2006035656A_发明申请_US20060035656A1 Method and system for merging multiple push-to-talk over cellular sessions_+++A_S_T_U_V_W_c_f_h_i_k_l_n_o_q+++.docx
2026-07-18 15:40
2007-06-27_CN1989711A_发明公开_CN1989711A 合并多个无线一键通电话的方法和系统_+++A_b_c_d_e_f_h_i_k_l_n_o_q+++.docx
2026-07-18 15:40
2008-06-19_US2008147876A_发明申请_US20080147876A1 SYSTEM, METHOD AND PROGRAM FOR MANAGING FILE DOWNLOADS_+++E_N_O_P_Q_a+++.docx
2026-07-18 15:40
2008-08-07_US2008189421A_发明申请_US20080189421A1 SIP and HTTP Convergence in Network Computing Environments_+++A_B_D_g_j_k_l_m_n_o_r+++.docx
2026-07-18 15:40
2009-04-23_US2009106571A_发明申请_US20090106571A1 Systems and Methods to Adaptively Load Balance User Sessions to Reduce Energy Consumption_+++A_B_D_K_L_c_g_j_m_n_o_r+++.docx
2026-07-18 15:40
2010-04-22_US2010100621A_发明申请_US20100100621A1 SHARING STATUS INFORMATION ACROSS A PLURALITY OF COMMUNICATION NETWORKS_+++A_N_O_s_t+++.docx
2026-07-18 15:40
2010-08-04_CN101795439A_发明公开_CN101795439A 合并多个无线一键通电话的方法和系统_+++A_G_J_M_P_R_X_n_o_s_t_u_v_w+++.docx
2026-07-18 15:40
2010-09-22_JP4550899B_发明专利_JP4550899B2 Session binding method and system of multiple PoC session_+++A_E_F_K_L_b_c_d_h_i_n_o_p_q+++.docx
2026-07-18 15:40
2010-10-07_US2010257273A_发明申请_US20100257273A1 Method, Apparatus and Program Product for Merging Communication Sessions in an IMS_+++B_C_H_I_K_g_j_m_n_o+++.docx
2026-07-18 15:40
2010-12-16_US2010318570A_发明申请_US20100318570A1 PLUGGABLE SESSION CONTEXT_+++A_B_D_K_L_c_n_o+++.docx
2026-07-18 15:40
2012-11-15_US2012289239A_发明申请_US20120289239A1 DEVICE RESOURCES SHARING FOR NETWORK RESOURCE CONSERVATION_+++A_K_L_b_c_d_n_o+++.docx
2026-07-18 15:40
2007-06-27_CN1989711A_发明公开_CN1989711A 合并多个无线一键通电话的方法和系统_+++A_b_c_d_e_f_h_i_k_l_n_o_q+++.docx

好的,我们开始进行详细的比对分析。

**对比文件名称:** 2007-06-27_CN1989711A_发明公开_CN1989711A 合并多个无线一键通电话的方法和系统

**目标专利名称:** 2095减少服务器-客户端会话的数目CN105164989B

**本次调用的模型名称:** 深度思考模型 (DeepSeek-R1)

### 特征比对表格

第一栏:技术特征描述及公开性判断第二栏:对比文件原文引用第三栏:公开性论述
**技术特征A:** 所述多个客户端通过网络可通信地连接到服务器,所述方法包括<br><br>**《直接公开》**说明书[0001]:“本发明涉及一种用于合并多个无线一键通(PoC)会话的方法和系统,其中,在多个PoC群组会话的环境下当属于一个PoC群组会话的成员希望加入另一PoC会话时,通过合并PoC群组会话来建立新的会话而不释放当前参加的PoC会话。”<br><br>说明书[0014] (图1描述):“首先,PoC客户机10是安置在移动电话中的服务请求器,并且通常通过接入网络20连接到基于SIP/IP (会话启动协议/互联网协议)核心的网络...基于SIP/IP核心的网络连接到PoC服务器60、GLMS(群组列表管理系统)50以及现场服务器70以便于支持PoC服务”。对比文件公开了多个客户端(PoC客户机)通过网络(接入网络、基于SIP/IP核心的网络)可通信地连接到服务器(PoC服务器)。例如,图1所示的PoC客户机10通过接入网络20连接到核心网络,进而连接到PoC服务器60。这些客户端能够发送请求(如INVITE、REFER)到服务器以进行会话管理。因此,技术特征A被直接公开。
**技术特征B:** 在中间节点处拦截来自第一客户端的以服务器为目的地的第一请求<br><br>**《隐含公开》**说明书[0065] 起 [图8步骤S1100和S1101]:“首先,合并会话的PoC客户机X101使用它自己的PoC地址和被合并的群组会话的身份将REFER请求发送到PoC服务器X的CF111和PF112...”。<br><br>说明书[0063] (图7描述S100):“首先,作为合并会话的PoC客户机X请求PoC客户机X进行与被合并会话进行会话合并,其中,PoC服务器X管理PoC客户机X所属的会话(S100)。”对比文件中的“PoC服务器X”可被理解为位于客户端(PoC客户机X)与目标服务器(如PoC服务器Y的CF)之间的中间节点。PoC客户机X发送的“REFER请求”(第一请求)首先被发送到管理其所属合并会话的PoC服务器X(中间节点)。该请求的最终目的地是管理被合并会话的PoC服务器Y。对比文件描述该请求被PoC服务器X的CF和PF接收和处理,相当于由中间节点拦截了来自第一客户端的、以另一服务器为目的地的请求。该中间节点(PoC服务器X)的角色与目标专利中拦截请求的中间节点作用类似,即代表客户端处理会话建立。因此,虽然未明确使用“拦截”一词,但此处理过程实质上包含了拦截的含义,属于隐含公开。
**技术特征C:** 利用第一请求在中间节点与服务器之间建立服务器-客户端会话<br><br>**《隐含公开》**说明书[0065] 起 [图8步骤S1200和S1201]:“其后,管理合并会话的PoC服务器X的CF111使用被合并会话的发送的群组指示来发送PoC会话合并指示、在PoC服务器X确定的媒体参数等(S1200和S1201)”。<br><br>说明书[0064] (图7描述S110):“此时,PoC服务器X使用合并会话的群组URI以与上述的即时消息服务相同的方法将会话合并请求发送到PoC客户机Y,并公开用于管理被合并会话的CF协商(S110)。”在拦截来自PoC客户机X的REFER请求后,PoC服务器X(中间节点)根据该请求(利用其中包含的被合并会话的群组信息)向PoC服务器Y(服务器)发送INVITE请求,以建立或协商一个合并后的新会话。这个过程本质上是中间节点利用第一客户端(PoC客户机X)的请求,在自身(PoC服务器X)与另一服务器(PoC服务器Y)之间建立了一个会话(合并后的PoC会话)。这符合“利用第一请求在中间节点与服务器之间建立服务器-客户端会话”的实质,属于隐含公开。
**技术特征D:** 在中间节点处拦截来自第二客户端的以服务器为目的地的第二请求,所述第二请求不同于第一请求<br><br>**《隐含公开》**说明书[0025] (背景技术部分):“在现有技术中,为了与先前激活的会话合并,首先,PoC会话X将作为终止信号的PoC会话BYE发送到管理当前进行的会话的PoC服务器X...其后,在终止现有的会话之后,PoC会话做出新的INVITE请求。”上述现有技术隐含着,在合并前,存在另一个客户端(属于被合并会话Y的成员)的请求。虽然本发明的实施例侧重于从一个会话发起合并,但系统本身包含多个客户端。在PoC系统中,被合并会话的客户端已经有正在进行的会话请求。当PoC服务器X发起到PoC服务器Y的合并时,本领域技术人员可以合理推断,PoC服务器X作为中间节点,也需要处理来自被合并会话客户端(第二客户端)的、以PoC服务器Y为目的地的既有请求或新请求(例如,第二请求可以是确认合并的请求或是在合并过程中产生的其他信令)。虽然对比文件未明确描述“拦截第二不同请求”的完整流程,但系统上下文必然存在此类交互。为了支持合并功能,中间节点(PoC服务器X)需要处理来自不同会话的请求。因此,此特征属于隐含公开。
**技术特征E:** 确定第一请求是否部分地与第二请求重叠<br><br>**《隐含公开》**说明书[0064] (图7步骤S110-S120):“...并公开用于管理被合并会话的CF协商(S110)...当达成PoC服务之间的CF协商时...(S120)”。<br><br>说明书[0065]起 [图8步骤S1400-S1403]:“...PoC服务器Y的CF211和PF212使用发送的媒体参数和会话合并指示执行会话合并过程,将协商的媒体参数的UPDATE请求发送到被合并的会话之内的所有客户机...”。对比文件描述的“PoC会话合并”过程,实质上就是确定两个现有PoC会话(可以视为第一请求和第二请求所代表的会话)如何合并。合并的核心在于确定两个会话的“重叠”部分(例如,共享的媒体流、成员列表或其他会话资源)以及“不重叠”部分(例如,原始各自的特定参数)。PoC服务器之间的“CF协商”和“媒体参数协商”正是为了确定这些重叠和独有部分,以实现聚合。目标专利中的“请求”对应这里的“会话需求”,而重叠判断是会话合并的必经逻辑步骤。因此,尽管对比文件未使用“重叠”一词,但其核心逻辑包含了确定不同请求/会话间存在可合并的关联,这可以理解为一种对请求重叠的判断,属于隐含公开。
**技术特征F:** 如果第一请求部分地与第二请求重叠并且如果第二请求的一部分不与第一请求重叠,则更新中间节点与服务器之间的服务器-客户端会话以便包括第二请求的一部分。<br><br>**《隐含公开》**说明书[0064] (图7步骤S120-S130):“当将为通过PoC服务器之间的协商合并的会话选择整个CF时(S120),被修改的媒体参数的更新被发送到被合并会话的PoC客户机Y(S130)。”<br><br>说明书[0068] (图8步骤S1400-S1403及S1500):“...将协商的媒体参数的UPDATE请求发送到被合并的会话之内的所有客户机...当从被合并的会话接收到对所有媒体参数的响应时,PoC服务器Y将对会话合并的最终响应发送到PoC服务器X”。对比文件描述了详细的会话合并流程。当两个会话(请求)存在重叠(可合并)时,通过协商过程更新会话参数,以形成一个包含双方需求的聚合会话。具体地,“将协商的媒体参数的UPDATE请求发送到被合并的会话之内的所有客户机”这一操作,可被视为对中间节点(PoC服务器X)与服务器(PoC服务器Y)之间所建立的“聚合服务器-客户端会话”的更新,以容纳第二请求(被合并会话Y的请求)的部分。虽然对比文件未突出“不重叠部分”的精确判断,但其合并过程实质上是将两个不同会话的内容整合,这必然包含了将A会话的独有部分纳入到合并后的B会话中,符合特征F的逻辑。因此,本特征属于隐含公开。
**技术特征G:** 其还包括<br><br>**《未公开》**无直接或隐含对应的内容。此特征为程序性过渡词,用于引出后续步骤,不涉及具体技术方案。
**技术特征H:** 在中间节点处根据第一请求和第二请求通过服务器-客户端会话接收来自服务器的数据<br><br>**《隐含公开》**说明书图8步骤S1600:“...并进行管理通话发起的过程(S1600)。” <br><br>说明书图4B及相关描述([0081]):“...通过允许群组Y的PoC服务器的CF(控制PoC功能)负责在群组X的PoC服务器的CF执行的功能,群组X成员初始新的会话,而不需要释放当前参加的PoC会话。”在合并会话建立后,合并会话的中间节点(PoC服务器X)和参与合并的客户端之间、以及和另一服务器(PoC服务器Y)之间,势必会通过该建立的合并会话进行媒体流(数据)的接收和转发。例如,PoC服务器Y将媒体数据发送给PoC服务器X,由PoC服务器X分发给PoC客户机X。这个过程完全符合“根据第一请求和第二请求通过服务器-客户端会话接收来自服务器的数据”的描述。PoC服务器X接收来自PoC服务器Y的媒体数据,正是基于合并双方(第一和第二请求)的需求。因此,此特征属于隐含公开。
**技术特征I:** 从所述数据导出第一响应以及可选地导出第二响应,所述第一响应根据第一请求,并且所述第二响应根据第二请求。<br><br>**《隐含公开》**说明书图8步骤S1200-S1201/S1502-S1503 / S1600,描述了服务器间的信令交互和最终媒体流的建立与管理。<br><br>在PoC系统中,中间节点(PoC服务器X)需要将来自被合并服务器(PoC服务器Y)的媒体数据,根据原始请求的不同(发给A客户端的、发给B客户端的)进行区分和分发。当PoC服务器X(中间节点)从PoC服务器Y接收到合并后的媒体流(数据)时,它需要根据第一请求(PoC客户机X的需求)和/或第二请求(原属被合并会话的客户机需求)来生成对应的响应(媒体包)。例如,虽然媒体流可能是共享的,但根据请求的不同,中间节点可能在数据包中附加了不同的头信息(如会话ID),或者对流进行复制和分发。这种“导出”响应是PoC服务器作为CF/PF的核心功能,以实现对不同客户端的响应。尽管对比文件未明确写出“导出第一响应”的具体数据处理步骤,但这是实现多会话合并的必然隐含步骤。因此,属于隐含公开。
**技术特征J:** 其还包括<br><br>**《未公开》**无直接或间接对应的内容。此特征为程序性过渡词。
**技术特征K:** 响应于第一请求从中间节点向第一客户端传送第一响应<br><br>**《隐含公开》**说明书图8步骤S1600:“...并进行管理通话发起的过程(S1600)。”在合并会话建立后,PoC服务器X(中间节点)必然会将从PoC服务器Y接收到的媒体流(第一响应)发送给发起请求的第一客户端(PoC客户机X),这是PoC语音服务的根本目的。对比文件为了不释放当前会话就建立新会话,必然需要将合并后的通信内容(响应)传送回原请求的客户端。因此,此特征属于隐含公开。
**技术特征L:** 可选地响应于第二请求从中间节点向第二客户端传送第二响应。<br><br>**《隐含公开》**说明书图8步骤S1400-S1401:“PoC服务器Y的CF211和PF212使用发送的媒体参数和会话合并指示执行会话合并过程,将协商的媒体参数的UPDATE请求发送到被合并的会话之内的所有客户机...”<br><br>在更新被合并会话后,合并后的媒体流也应被传送给这些被合并会话的客户机。对于第二客户端(属于原被合并的PoC会话Y的客户机),对比文件明确描述了向他们发送UPDATE更新。在最终合并的会话中,这些客户端同样需要接收来自合并服务器的媒体流(第二响应)。中间节点(PoC服务器X)或其对应的服务器(PoC服务器Y)必然会响应于他们的原始请求(继续通话),将合并后的会话数据传送到他们。虽然对比文件未明确使用“第二响应”和“第二请求”的措辞,但其系统操作必然包含此步骤,属于隐含公开。
**技术特征M:** 其中<br><br>**《未公开》**无直接或间接对应的内容。此特征为程序性过渡词。
**技术特征N:** 确定由第一请求所请求的第一信息集合<br><br>**《隐含公开》**说明书[0065]起 [图8步骤S1100-S1101]:“合并会话的PoC客户机X101使用它自己的PoC地址和被合并的群组会话的身份将REFER请求发送到PoC服务器X”。<br><br>说明书[0078]:“如果请求会话合并的用户是会话管理者时,用户的PoC服务器的PF等同于PoC服务器的CF。”对比文件中的“REFER请求”包含了对合并的特定需求,即“被合并的群组会话的身份”和“它自己的PoC地址”等信息。当中间节点(PoC服务器X)收到此请求时,它需要解析并确定第一请求所请求的操作和资源集合,例如“将我的会话X合并到会话Y”。这个“请求操作和对象”即构成了所请求的“第一信息集合”。因此,中间节点确定第一信息集合是处理请求的隐含前提,属于隐含公开。
**技术特征O:** 确定由第二请求所请求的第二信息集合<br><br>**《隐含公开》**说明书[0067]起 [图8步骤S1400-S1401]:“...PoC服务器Y的CF211和PF212使用发送的媒体参数和会话合并指示执行会话合并过程,将协商的媒体参数的UPDATE请求发送到被合并的会话之内的所有客户机”。在合并过程中,除了第一请求外,被合并方(第二客户端)也有其既有的会话需求(例如,继续参与会话Y,接收来自合并后的媒体流)。中间节点(PoC服务器X)或其对应的服务器(PoC服务器Y)在处理合并时,必须考虑并确定被合并会话(第二请求)所请求的信息集合(即会话Y的当前配置、成员等)。这是进行合并协商(S1400-S1403)的基础,属于隐含公开。
**技术特征P:** 确定第一请求是否至少部分地与第二请求重叠包括<br><br>**《未公开》**无直接或间接对应的内容。此特征为程序性引导词。
**技术特征Q:** 确定第一信息集合是否与第二信息集合重叠,和/或第二信息集合的至少一部分是否能够从第一信息集合的至少一部分导出。<br><br>**《隐含公开》**说明书[0064] (图7步骤S120):“当达成PoC服务之间的CF协商时,现有PoC服务器中的一个作为对另一PoC会话执行CF的代理服务器,并且另一PoC服务器主要执行PF。”对比文件描述的“CF协商”过程,实际上是在判断两个会话的请求能否合并,如何划分职责(由谁担当新的CF)。这种协商的隐含前提是确定两个会话(信息集合)之间是否存在重叠(例如,共同的参与者、媒体编码等)以及哪些部分可以合并或由一方代理(导出)。例如,如果会话X的CF可以代替会话Y的CF执行控制功能,可以视为第二信息集合(会话Y的控制功能)能够从第一信息集合(会话X的CF功能)中导出或由其代理。虽然对比文件没有明确使用“重叠”和“导出”的表述,但其合并逻辑完全基于这种隐含的关联性判断。因此,本特征属于隐含公开。
**技术特征R:** 还包括<br><br>**《未公开》**无直接或间接对应的内容。此特征为程序性过渡词。
**技术特征S:** 根据第二请求对第一信息集合的至少一部分进行过滤从而生成经过过滤的信息集合<br><br>**《未公开》**对比文件描述了合并,但没有描述中间节点根据一个请求对另一个请求的请求信息进行过滤。对比文件的核心是“合并”两个完整的会话,而不是中间节点根据后续请求(第二请求)对先前请求(第一请求)所请求的信息进行过滤。PoC服务器在合并过程中更多是执行资源整合和协商,而非执行基于不同请求粒度的数据过滤。目标专利中的“过滤”是指根据第二请求的具体条件(如频率、条件)从第一请求的全量数据中提取子集。对比文件中没有公开或暗示此类中间节点进行的数据过滤处理。因此,本特征未被公开。
**技术特征T:** 响应于第二请求向第二客户端传送所述经过过滤的信息集合。<br><br>**《未公开》**无直接或间接对应的内容。由于技术特征S未被公开,作为其后续步骤的特征T也未被公开。
**技术特征U:** 其中,第一信息集合的至少一部分具有第一格式,并且第二信息集合具有不同于第一格式的第二格式,所述方法还包括<br><br>**《未公开》**无直接或间接对应的内容。对比文件涉及的是PoC会话的合并,其核心技术在于信令层面的会话控制(SIP信令的协商与转发)。对比文件完全没有提到对内容数据(如媒体流)进行不同数据格式(如JSON/XML)的转换。目标专利的格式转化是针对数据表示层,而对比文件处理的是会话管理和媒体分发,不涉及此类转化。因此,本特征未被公开。
**技术特征V:** 对第一信息集合的所述至少一部分进行转化以生成具有第二格式的经过转化的信息集合<br><br>**《未公开》**无直接或间接对应的内容。同上,对比文件未公开任何关于数据格式转化的内容。
**技术特征W:** 响应于第二请求向第二客户端传送所述经过转化的信息集合。<br><br>**《未公开》**无直接或间接对应的内容。由于技术特征V未被公开,作为其后续步骤的特征W也未被公开。
**技术特征X:** 其中,确定第一请求是否部分地与第二请求重叠包括<br><br>**《未公开》**无直接或间接对应的内容。此特征为程序性引导词。
**技术特征Y:** 把第一请求和第二请求与至少一种已知模式进行比较,每一种已知模式表明一种类型的服务器-客户端会话。<br><br>**《未公开》**无直接或间接对应的内容。对比文件没有描述任何“模式匹配”或与预定义的“已知模式”进行比较的过程。PoC会话合并的依据是基于SIP信令中的具体参数(如会议URI、群组ID)和策略规则,而不是将请求抽象为通用的“会话类型模式”进行比较。目标专利中的模式匹配是为了处理不同协议的请求,而对比文件明确基于SIP协议,没有跨协议的模式匹配概念。因此,本特征未被公开。
**技术特征Z:** 其中,所述至少一种已知模式当中的每一种被适配成与在不同协议中定义的请求相匹配。<br><br>**《未公开》**无直接或间接对应的内容。对比文件通篇使用SIP协议作为信令基础,没有提到支持或适配多种不同协议(如HTTP和CoAP)的请求匹配。其合并方法强依赖于SIP信令流程。因此,本特征未被公开。

---

**总结结论:**

经过逐项比对,对比文件《CN1989711A 合并多个无线一键通电话的方法和系统》公开或隐含公开了目标专利权利要求的以下特征:A, B, C, D, E, F, H, I, K, L, N, O, Q。

<<<A>>>

<<<b>>>

<<<c>>>

<<<d>>>

<<<e>>>

<<<f>>>

<<<h>>>

<<<i>>>

<<<k>>>

<<<l>>>

<<<n>>>

<<<o>>>

<<<q>>>

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

网站备案号:渝ICP备2023012882号


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