对比文件名称：2007-04-18_EP1774679A_发明公开_EP1774679A1 METHOD AND SYSTEM FOR MERGING MULTIPLE PUSH-TO-TALK OVER CELLULAR PHONE
目标专利名称：2095减少服务器-客户端会话的数目 CN105164989B
本次调用的模型名称：未指定
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用（翻译） | 公开性论述 |
| **技术特征A**：所述多个客户端通过网络可通信地连接到服务器，所述方法包括。**《直接公开》** | “[1] …PoC client 10 is a service requester that is mounted in a mobile phone, and usually connected to a network based on a SIP/IP core 30 through an access network 20…”（PoC客户端10安装在移动电话中，通常通过接入网络20连接到基于SIP/IP核心30的网络。）<br>“[6] Here, the PoC client 10 makes it possible to provide access to PoC service…”（PoC客户端10使得能够提供对PoC服务的接入。）<br>所述PoC客户端即为多个客户端，PoC服务器即为服务器，且客户端通过网络可通信地连接到服务器。 | 对比文件明确公开了多个PoC客户端（用户终端）通过接入网络和核心网络可通信地连接到PoC服务器，构成客户端-服务器架构。这与目标专利中“多个客户端通过网络可通信地连接到服务器”完全相同，且作用均是建立通信基础。因此该特征被直接公开。 |
| **技术特征B**：在中间节点处拦截来自第一客户端的以服务器为目的地的第一请求。**《未公开》** | “[60] First, a PoC client X 101 of a merging session sends a REFER request to CF 111 and PF 112 of a PoC server X… wherein the PoC client X 101 belongs to the CF 111 and PF 112…”（首先，合并会话的PoC客户端X 101向其所属的PoC服务器X的CF 111和PF 112发送REFER请求。）<br>该请求直接发送至其所属服务器，并未经过任何“中间节点”的拦截，也不存在以其他服务器为目的地的拦截行为。 | 目标专利的“拦截”是指中间节点截获本应直接发给服务器（如受约束节点）的请求，从而替代服务器处理。对比文件中，客户端直接向其归属的PoC服务器发送请求，该服务器即为服务目标，不存在另一“服务器”和独立的“中间节点”。本领域技术人员无法从对比文件推导出“在中间节点处拦截”这一概念。因此该特征未公开。 |
| **技术特征C**：利用第一请求在中间节点与服务器之间建立服务器-客户端会话。**《隐含公开》** | “[62] Next, the CF 111 of the PoC server X managing the merging session sends a PoC session merging indication, media parameters… using a sent group indication of the merged session (S 1200 and S 1201). A CF 211 of a PoC server Y receiving an INVITE request sends a temporal response…”（接下来，管理合并会话的PoC服务器X的CF 111使用已发送的合并会话的组指示发送PoC会话合并指示、媒体参数等。接收INVITE请求的PoC服务器Y的CF 211发送临时响应。）<br>通过INVITE/REFER等信令，在PoC服务器X和PoC服务器Y之间建立了用于合并会话的关联（即新会话或更新后的会话）。 | 目标专利中，中间节点利用第一请求与服务器建立单一会话以服务多个客户端。对比文件中，PoC服务器X（可视为中间节点角色）接收客户端X的请求（第一请求）后，通过INVITE与PoC服务器Y（最终服务器）建立会话关系（合并后的会话），从而替代客户端X直接与服务器Y交互。虽然目标专利中的“中间节点”与“服务器”有明确界限，但对比文件通过服务器间协作实现了类似效果，本领域技术人员可以合理推断出利用请求建立中间节点与服务器之间会话的步骤。因此该特征被隐含公开。 |
| **技术特征D**：在中间节点处拦截来自第二客户端的以服务器为目的地的第二请求，所述第二请求不同于第一请求。**《未公开》** | 对比文件全程由合并客户端（merging client）发起合并请求，另一组（merged session）的客户端并未主动发送合并请求。merged session的客户端在合并过程中仅被动接收UPDATE通知（S1400-1403），其原有会话并未产生新的独立请求。不存在与第一请求不同的第二请求被拦截的情况。 | 目标专利明确要求存在不同于第一请求的第二客户端请求，并被中间节点拦截。对比文件中，合并过程完全由单方发起，另一方客户端未发送任何请求。即便认为merged session的初始会话请求可作为“第二请求”，该请求也并未被“拦截”（早已建立）。因此本领域技术人员无法从对比文件得到该特征，未公开。 |
| **技术特征E**：确定第一请求是否部分地与第二请求重叠。**《未公开》** | 对比文件中，合并决策基于组策略和用户身份，而非基于请求内容的重叠。例如[55] “on the basis of policy of a PoC session Y, the PoC server Y may open the session merge negotiation…”（基于PoC会话Y的策略，PoC服务器Y可以开启会话合并协商。）<br>没有分析两个请求所请求的信息集合是否部分重叠。 | 目标专利的“重叠”特指请求所要求的信息集合存在公共部分（如资源状态、条件、频率等）。对比文件利用组标识和策略进行合并，不关注请求的语义内容。本领域技术人员无法从中推导出“确定请求是否部分重叠”的步骤。因此该特征未公开。 |
| **技术特征F**：如果第一请求部分地与第二请求重叠并且如果第二请求的一部分不与第一请求重叠，则更新中间节点与服务器之间的服务器-客户端会话以便包括第二请求的一部分。**《隐含公开》** | “[64] When the INVITE request is received, CF 211 and PF 212 of the PoC server Y perform the session merging procedure using the sent media parameters and session merging indication, sends an UPDATE request for negotiated media parameters to all the clients within the merged session…”（当接收到INVITE请求时，PoC服务器Y的CF 211和PF 212使用发送的媒体参数和会话合并指示执行会话合并过程，向合并会话内的所有客户端发送经协商的媒体参数的UPDATE请求。）<br>更新后的会话包括了原merged session的所有成员（相当于第二请求的全部），且原merging session的部分被保留（第一请求的部分重叠被扩展）。 | 目标专利中，当存在部分重叠且第二请求有新增部分时，更新现有会话以包含该新增部分。对比文件中，合并会话后，merged session的原有成员被保留（相当于第二请求的“已重叠部分”），同时新加入了merging session的成员（相当于第二请求的“不与第一请求重叠的部分”，因为第一请求代表merging session自身，而merging session的成员不是merged session原有部分）。会话参数被更新，从而容纳了新增部分。虽然出发点不同，但最终效果均为更新一个已有会话以包含另一请求的新部分，因此可合理推断该特征。故隐含公开。 |
| **技术特征G**：其还包括。**《隐含公开》** | 对比文件全文包含类似“还包括”、“进一步包括”的连接用语，例如“the method further includes steps of…”（见[29]“The method includes steps of…”） | 该特征仅为过渡性词语，对比文件在描述方法步骤时必然使用类似表述，本领域技术人员可以理解其存在。因此隐含公开。 |
| **技术特征H**：在中间节点处根据第一请求和第二请求通过服务器-客户端会话接收来自服务器的数据。**《隐含公开》** | “[12] …PF serves to relay the media between the CF and the PoC client…”（PF用于中继CF和PoC客户端之间的媒体。）<br>合并后，PF（可视为中间节点）通过已建立的会话（即合并后的会话）从CF（服务器）接收媒体数据，并根据第一客户端（merging client）和第二客户端（merged client）各自的请求（即参与会话的需求）进行中继。 | 目标专利的中间节点通过聚合会话接收数据并用于后续响应。对比文件中，PF作为中间角色，通过更新后的会话接收来自CF的媒体流，这些媒体流将服务于原两组客户端，相当于“根据第一请求和第二请求”。因此隐含公开。 |
| **技术特征I**：从所述数据导出第一响应以及可选地导出第二响应，所述第一响应根据第一请求，并且所述第二响应根据第二请求。**《隐含公开》** | “[12] …PF serves to relay the media between the CF and the PoC client… to filter any one of two simultaneous sessions according to selection of a PoC user…”（PF用于中继CF和PoC客户端之间的媒体……根据PoC用户的选择过滤两个同时会话中的任一个。）<br>PF在接收媒体后需要决定向哪个客户端转发何种媒体，这实际上是根据不同客户端的请求（参与会话的类型）导出对应的响应（媒体流）。 | 目标专利中，中间节点从聚合会话数据中提取并生成针对各请求的响应。对比文件中，PF从CF接收统一媒体流，但需根据客户端参与情况（第一请求或第二请求）进行过滤或直接转发，这相当于从同一数据源导出了服务于不同请求的响应。因此隐含公开。 |
| **技术特征J**：其还包括。**《隐含公开》** | 同特征G，对比文件包含“还包括”等过渡语句。 | 隐含公开。 |
| **技术特征K**：响应于第一请求从中间节点向第一客户端传送第一响应。**《隐含公开》** | “[12] …PF serves to relay the media between the CF and the PoC client…”（PF用于中继CF和PoC客户端之间的媒体。）<br>合并后，PF向第一客户端（merging client）传送媒体，该媒体即为对第一请求（即参与合并会话的请求）的响应。 | 目标专利中，中间节点向第一客户端传送根据第一请求导出的响应。对比文件中，PF向merging client传送媒体，该客户端原本请求并入会话，接收媒体即是对其请求的满足。故隐含公开。 |
| **技术特征L**：可选地响应于第二请求从中间节点向第二客户端传送第二响应。**《隐含公开》** | 同上，PF向merged client（第二客户端）传送媒体，该媒体是对第二客户端原有参与请求的响应。对比文件中，merged client在合并后继续接收媒体，且其原有会话并未终止。 | 与K类似，隐含公开。 |
| **技术特征M**：其中。**《隐含公开》** | 对比文件在描述步骤或条件时使用“wherein”、“其中”等连接词。 | 隐含公开。 |
| **技术特征N**：确定由第一请求所请求的第一信息集合。**《未公开》** | 对比文件未提及“信息集合”概念，合并请求仅涉及组标识、媒体参数（如编解码器），而非明确的“请求的信息集合”。 | 目标专利的“信息集合”特指客户端期望从资源服务器获取的状态信息（如温度值）。对比文件不涉及资源请求，本领域技术人员无法从中推导出确定信息集合的步骤。因此未公开。 |
| **技术特征O**：确定由第二请求所请求的第二信息集合。**《未公开》** | 同特征N。 | 未公开。 |
| **技术特征P**：确定第一请求是否至少部分地与第二请求重叠包括。**《隐含公开》** | 对比文件在描述重叠判断时使用了类似“whether the requests are combinable”的隐含条件，但并非直接。然而作为过渡句，本领域技术人员可以理解存在判断步骤。 | 隐含公开（仅为过渡，实质内容依赖后续特征）。 |
| **技术特征Q**：确定第一信息集合是否与第二信息集合重叠，和/或第二信息集合的至少一部分是否能够从第一信息集合的至少一部分导出。**《未公开》** | 对比文件没有基于信息集合的重叠或可导出来判断合并的条件。合并取决于组策略和授权，而非信息内容的重叠或衍生关系。 | 目标专利的核心是通过信息集合的重叠或可导出来减少冗余。对比文件的合并逻辑完全不同，因此该特征未公开。 |
| **技术特征R**：还包括。**《隐含公开》** | 同特征G。 | 隐含公开。 |
| **技术特征S**：根据第二请求对第一信息集合的至少一部分进行过滤从而生成经过过滤的信息集合。**《隐含公开》** | “[12] …May provide filtering of the media streams in the case of simultaneous sessions.”（可提供在同时会话情况下的媒体流过滤。）<br>当同时存在多个会话时，PF可以过滤媒体流，例如仅将特定信道的媒体转发给特定客户端，这相当于根据第二请求（第二客户端的会话需求）从第一信息集合（全局媒体）中过滤出子集。 | 目标专利中，中间节点根据第二请求对第一信息集合过滤。对比文件PF的过滤功能在同时会话场景中自然实现了类似效果：从完整媒体流中为特定客户端筛选所需部分。因此隐含公开。 |
| **技术特征T**：响应于第二请求向第二客户端传送所述经过过滤的信息集合。**《隐含公开》** | 结合S，过滤后的媒体流被传送到对应的客户端（即第二客户端）。对比文件[12]明确PF执行中继功能，经过滤的媒体必然传送至目标客户端。 | 隐含公开。 |
| **技术特征U**：其中，第一信息集合的至少一部分具有第一格式，并且第二信息集合具有不同于第一格式的第二格式，所述方法还包括。**《隐含公开》** | “[12] …May provide transcoding between different codecs.”（可提供不同编解码器之间的转码。）<br>当客户端使用不同编码格式时，PF需要将媒体从一种格式转换为另一种格式。 | 目标专利中第一格式与第二格式不同，中间节点需进行格式转换。对比文件PF的转码功能直接对应，因此隐含公开。 |
| **技术特征V**：对第一信息集合的所述至少一部分进行转化以生成具有第二格式的经过转化的信息集合。**《隐含公开》** | 同上，PF执行转码，将一种编解码格式转化为另一种格式。 | 隐含公开。 |
| **技术特征W**：响应于第二请求向第二客户端传送所述经过转化的信息集合。**《隐含公开》** | 转码后的媒体被传送给对应客户端，与特征U/V结合。 | 隐含公开。 |
| **技术特征X**：其中，确定第一请求是否部分地与第二请求重叠包括。**《隐含公开》** | 对比文件在合并过程中存在判断会话是否可合并的步骤，如策略检查。此为过渡性描述。 | 隐含公开（仅为过渡语句）。 |
| **技术特征Y**：把第一请求和第二请求与至少一种已知模式进行比较，每一种已知模式表明一种类型的服务器-客户端会话。**《未公开》** | 对比文件不存在“已知模式”比较过程。会话类型（如一对一、群组）虽存在，但不会用于比较请求以确定重叠。合并决策基于组标识等，而非模式匹配。 | 目标专利通过模式匹配识别请求类型以便组合。对比文件无此教导，本领域技术人员无法推导出该特征。因此未公开。 |
| **技术特征Z**：其中，所述至少一种已知模式当中的每一种被适配成与在不同协议中定义的请求相匹配。**《未公开》** | 对比文件所有信令均基于SIP协议，未涉及跨协议匹配。没有公开或暗示模式可以适应不同协议（如CoAP与HTTP）。 | 目标专利支持跨协议请求模式匹配。对比文件仅限于SIP单一协议，未公开此特征。因此未公开。 |
### 公开性代码汇总
根据以上分析，对比文件公开情况如下：
- 直接公开的技术特征：A
对应代码：<<<A>>>
- 隐含公开的技术特征：C, F, G, H, I, J, K, L, M, P, R, S, T, U, V, W, X
对应代码：<<<c>>><<<f>>><<<g>>><<<h>>><<<i>>><<<j>>><<<k>>><<<l>>><<<m>>><<<p>>><<<r>>><<<s>>><<<t>>><<<u>>><<<v>>><<<w>>><<<x>>>
未公开的特征（不输出代码）：B, D, E, N, O, Q, Y, Z
（注意：特征G、J、M、P、R、X为过渡性词语，对比文件必然存在类似表述，故判定为隐含公开；特征C、F、H、I、K、L、S、T、U、V、W基于PoC服务器功能可合理推断，符合隐含公开的宽松标准。）