**对比文件名称**：2010-02-11_WO2010016041A_发明申请_WO2010016041A2 A METHOD TO MANAGE COMMUNITY CALLS IN A TELECOMMUNICATION SYSTEM
**目标专利名称**：312用于群通信中基于动态讲话者ID的媒体处理的框架和方法CN104885487B
**本次调用模型名称**：gpt-4o
### **特征比对表格**
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：包括：在所述群通信会话期间在所述计算设备中接收媒体数据，所述媒体数据至少包括所述媒体数据的发送者的标识符(发送者ID) <br>**《直接公开》** | [p0028] “Each side of the call in the telecommunication network will be referred to a branch or a leg of the call... the actual call..., i.e. the media level of the call, will be handled by call control module 112.” <br> [p0059] “Each recipient end point from the selected community will receive the second call with the selected profile as the Caller ID.” | 对比文件明确公开了在群通信（社区呼叫）会话中，被叫端点（即计算设备）会接收呼叫。实际呼叫涉及媒体层面（media level），即媒体数据。同时，接收到的呼叫带有呼叫方ID（Caller ID），这即是媒体数据的发送者标识符（发送者ID）。因此，本领域技术人员能够毫无疑义地得出在群通信会话期间，计算设备接收包含发送者ID的媒体数据的技术方案。 |
| **技术特征B**：在所述计算设备中标识与所接收到的媒体数据相关联的所述发送者ID以及多个不同媒体类型中与所接收到的媒体数据相关联的媒体类型 <br>**《隐含公开》** | [p0028] “a media level for handling data, voice, etc.” <br> [p0059] “Each recipient end point... will receive the second call with the selected profile as the Caller ID.” <br> [p0036] “Call control offers different features such as decoding addressing information and routing telephone calls... a Media function to handle the entire media part of a communication between two end points.” | 对比文件公开了在媒体层面处理数据、语音等媒体，并且呼叫控制模块（call control module 112）具有媒体功能来处理端点之间通信的整个媒体部分。这隐含了计算设备（端点）需要处理不同类型的媒体（如语音、数据）。同时，接收到的呼叫带有“Caller ID”，这即是标识发送者ID。为了正确处理和路由不同的媒体（如区分语音通话和数据传输），计算设备必然需要识别其媒体类型（例如是音频流还是数据文件）。因此，本领域技术人员能够合理推断出计算设备会标识所接收媒体数据的发送者ID及其媒体类型。 |
| **技术特征C**：在所述计算设备中标识呈现规则，所述呈现规则将所述发送者ID和关联于所接收到的媒体数据的媒体类型与所述计算设备的多个接口中有能力呈现关联于所接收到的媒体数据的媒体类型的一个或多个接口相关，<br>**《未公开》** | 无对应内容。 | 对比文件的核心在于建立和管理群组呼叫的连接（如分配临时端点、建立呼叫桥接），其呼叫控制模块的功能是解码寻址信息、路由呼叫、处理媒体混合（[p0036]），但并未公开任何“呈现规则”（presentation rule）的概念，更没有公开将特定发送者ID和特定媒体类型映射到计算设备特定接口（如显示器、耳机）的规则。目标专利的“呈现规则”是用户定义的、用于控制媒体在哪个物理或逻辑接口上输出的策略，而对比文件关注的是网络层面的信令和媒体流连接，不涉及接收设备本地的、基于发送者身份的媒体输出接口选择策略。 |
| **技术特征D**：其中所述呈现规则在所述群通信会话期间能由所述计算设备动态地配置以响应于所述一个或多个接口的操作状态在所述群通信会话期间已改变的指示而改变与所述发送者ID和所述媒体类型相关的所述一个或多个接口 <br>**《未公开》** | 无对应内容。 | 如特征C所述，对比文件未公开“呈现规则”，因此更不可能公开该规则能够在群通信会话期间由计算设备动态配置，尤其是响应于接口操作状态改变的指示而动态改变规则内容。对比文件未涉及计算设备接口（如耳机插拔、显示器连接）状态监控及据此调整媒体输出目的地的功能。 |
| **技术特征E**：经由所述计算设备的与所述发送者ID和关联于所接收到的媒体数据的媒体类型相关的所述一个或多个接口来呈现所接收到的媒体数据。<br>**《直接公开》** | [p0028] “the actual call..., i.e. the media level of the call, will be handled by call control module 112.” <br> [p0036] “a Media function to handle the entire media part of a communication between two end points.” <br> [p0059] “Once the second user picks up the call, the call control module 112 will, in a subsequent act 260, joint the first and second calls through the bridge established using T_NUMBER to generate a call between the calling end point and all recipient end points...” | 对比文件公开了呼叫控制模块处理媒体层面，并建立通信桥接，使得主叫端点和所有被叫端点之间的呼叫得以生成。这意味着媒体数据最终会被路由并呈现在各个参与者端点（计算设备）上。虽然对比文件未指定具体的呈现接口（如扬声器或屏幕），但作为通信设备，其必然通过某种接口（如听筒、扬声器、屏幕）来呈现接收到的媒体（语音或数据）。因此，“经由计算设备的接口呈现媒体数据”这一基本动作已被直接公开。 |
| **技术特征F**：其特征在于：所标识的呈现规则将所述发送者ID和关联于所接收到的媒体数据的所述媒体类型与所述多个接口中若存在的有能力呈现所接收到的媒体数据的第一接口相关以及在所述第一接口不存在的情况下与所述多个接口中有能力呈现所接收到的媒体数据的第二接口相关，以及所述用于呈现所接收到的媒体数据的一个或多个接口包括在所述第一接口存在的情况下的所述第一接口或者在所述第一接口不存在的情况下的所述第二接口。<br>**《未公开》** | 无对应内容。 | 该特征是特征C中“呈现规则”的具体化，是一种条件备用规则（例如“如果耳机存在则用耳机，否则用扬声器”）。对比文件完全没有涉及此类基于接口可用性的、与发送者ID和媒体类型绑定的本地呈现策略。 |
| **技术特征G**：其特征在于，所述呈现规则是用户可配置的，所述方法进一步包括：接收用户输入 <br>**《未公开》** | 无对应内容。 | 对比文件允许用户配置“社区”（community）的联系人列表（[p0031], [p0044]），但这属于呼叫建立前的联系人分组管理，并非目标专利所述的、用于控制媒体如何呈现的“呈现规则”。对比文件未提及用户可以为特定联系人或媒体类型配置输出接口。 |
| **技术特征H**：响应于所述用户输入而配置所述呈现规则。<br>**《未公开》** | 无对应内容。 | 由于特征G未被公开，特征H自然也未被公开。 |
| **技术特征I**：其特征在于，接收用户输入和响应于所述用户输入而配置所述呈现规则是在所述群通信会话期间完成的。<br>**《未公开》** | 无对应内容。 | 对比文件未公开在群通信会话期间动态配置媒体呈现规则。 |
| **技术特征J**：其特征在于，所述一个或多个接口包括以下一者或多者：显示器、头戴式耳机、扬声器电话、端口、应用或辅助设备。<br>**《未公开》** | 无对应内容。 | 对比文件在描述通信系统和设备时，未具体列举或界定计算设备用于呈现媒体的具体接口类型，如显示器、头戴式耳机等。其关注点在于网络侧的呼叫控制和媒体桥接，而非终端设备的多媒体输出接口管理。 |
| **技术特征K**：其特征在于，进一步包括：存储对所述计算设备的被用来呈现所接收到的媒体数据的所述一个或多个接口的指示 <br>**《未公开》** | 无对应内容。 | 对比文件未提及存储关于使用哪个接口呈现媒体的信息。 |
| **技术特征L**：至少部分地基于所存储的对用于呈现所接收到的媒体数据的所述一个或多个接口的指示来更新所标识的呈现规则以生成经更新呈现规则 <br>**《未公开》** | 无对应内容。 | 对比文件未提及基于历史呈现记录来更新任何规则。 |
| **技术特征M**：在所述群通信会话期间在所述计算设备中接收新媒体数据，所述新媒体数据包括另一发送者标识符(另一发送者ID) <br>**《直接公开》** | [p0028], [p0059] (同特征A、E引用) | 与特征A同理，在持续的群通信会话中，计算设备会持续接收来自不同参与者的媒体数据，这些数据必然包含各自的发送者标识符（如Caller ID）。因此该特征被直接公开。 |
| **技术特征N**：在所述计算设备中标识与所接收到的新媒体数据相关联的所述另一发送者ID <br>**《直接公开》** | [p0059] (同特征B引用) | 与特征B中标识发送者ID的部分同理，对于接收到的任何新媒体数据，计算设备都需要识别其发送者ID（如Caller ID）以进行呼叫处理或显示。因此该特征被直接公开。 |
| **技术特征O**：在所述计算设备中标识所接收到的新媒体数据的新媒体类型 <br>**《隐含公开》** | [p0028], [p0036] (同特征B引用) | 与特征B中标识媒体类型同理，对于接收到的任何新媒体数据，计算设备为了正确处理（如解码、播放），需要识别其媒体类型（如语音、视频数据）。因此该特征被隐含公开。 |
| **技术特征P**：在所述计算设备中标识与所述另一发送者ID和所述新媒体类型相关联的经更新呈现规则 <br>**《未公开》** | 无对应内容。 | 由于对比文件未公开“呈现规则”及对其的“更新”（特征C、L未公开），因此不可能公开标识与新的发送者ID和媒体类型相关联的“经更新呈现规则”。 |
| **技术特征Q**：基于所标识的经更新呈现规则来选择所述计算设备的另一接口以用于呈现所述新媒体数据 <br>**《未公开》** | 无对应内容。 | 由于特征P未公开，且对比文件未公开基于规则选择接口的机制，因此该特征未被公开。 |
| **技术特征R**：经由所述计算设备的所选另一接口来呈现所述新媒体数据。<br>**《直接公开》** | [p0028], [p0059] (同特征E引用) | 与特征E同理，任何在群通信中接收到的媒体数据最终都会经由计算设备的某个接口呈现给用户。虽然“所选另一接口”中的“所选”依赖于未公开的规则，但“经由接口呈现”这一动作本身已被直接公开。 |
| **技术特征S**：其特征在于，所述媒体类型是以下一者或多者：图片、文本消息、视频、声音、多用途因特网邮件扩展(MIME)、分辨率、格式或文件扩展。<br>**《未公开》** | 无对应内容。 | 对比文件在描述媒体时，仅泛泛提及“data, voice, etc.”（[p0028]），并未具体公开目标专利所列举的如此细化的媒体类型分类，如图片、文本消息、MIME类型、分辨率、文件扩展等。 |
| **技术特征T**：其特征在于，进一步包括：将对所述计算设备的用于呈现所接收到的媒体数据的所述一个或多个接口的指示从所述计算设备发送给与所标识的发送者ID相关联的计算设备。<br>**《未公开》** | 无对应内容。 | 对比文件未提及接收方设备需要或会将自身用于呈现媒体的接口信息反馈给发送方设备。 |
| **技术特征U**：其特征在于，进一步包括：将对所述计算设备的用于呈现所接收到的媒体数据的所述一个或多个接口的指示从所述计算设备发送给参与所述群通信会话的所有其他计算设备。<br>**《未公开》** | 无对应内容。 | 对比文件未提及接收方设备需要或会将自身用于呈现媒体的接口信息广播给群组内所有其他设备。 |
<<<A>>><<<E>>><<<M>>><<<N>>><<<R>>>
<<<b>>><<<o>>>