**对比文件名称**：2009-12-03_US2009298521A_发明申请_US20090298521A1 SYSTEM AND METHOD OF DELIVERY OF MEDIA DATA
**目标专利名称**：用于群通信中基于动态讲话者ID的媒体处理的框架和方法 CN104885487B
**模型名称**：DeepSeek最新版本模型
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：包括：在所述群通信会话期间在所述计算设备中接收媒体数据，所述媒体数据至少包括所述媒体数据的发送者的标识符(发送者ID) <br> **判断结果**：《隐含公开》 | 对比文件[0109]段：“A media alert message may include a source device identifier such as a calling line identifier (CLI) associated with a source device.” （媒体警报消息可以包括与源设备相关联的源设备标识符，例如主叫线路标识符（CLI）。）<br> [0091]段：“A media data delivery alert message may include a SIP INVITE message containing a SIP Alert-Info header with appropriate data content to instruct the target device.” （媒体数据传递警报消息可以包括包含有SIP Alert-Info报头的SIP INVITE消息，该报头带有适当的数据内容以指示目标设备。） | 对比文件公开了在媒体数据传递过程中，目标设备可以接收到包含源设备标识符（如CLI）的“媒体数据传递警报消息”（media data delivery alert message）。该消息的作用是警告目标设备即将有媒体数据到来，并可能据此配置其输出模式（例如，自动播放）。虽然对比文件中的“警报消息”与目标专利中“媒体数据”本身可能不完全相同，但“警报消息”是媒体数据传递流程的一部分，且明确包含了发送者的标识符。本领域技术人员能够理解，在基于SIP的通信系统中，媒体流（如RTP数据）的传递通常伴随或由信令消息（如SIP INVITE）发起和控制，这些信令消息中携带发送者标识。因此，可以合理推断，在群通信会话中，接收设备会接收到包含发送者ID的媒体数据或与之直接关联的控制信令。该技术特征在对比文件中被隐含公开。 |
| **技术特征B**：在所述计算设备中标识与所接收到的媒体数据相关联的所述发送者ID以及多个不同媒体类型中与所接收到的媒体数据相关联的媒体类型 <br> **判断结果**：《未公开》 | 对比文件[0088]段：“Target devices may be configured to associate a predetermined media data output mode with media data which is addressed to a network address being used in association with the group media data delivery mechanism.” （目标设备可以被配置为将预定的媒体数据输出模式与寻址到与群媒体数据传递机制相关联的网络地址的媒体数据相关联。）<br> [0109]段：“A media data output mode on a target device may involve a target device being configured to respond differently to media data identified from a source device identifier as being transmitted from different source devices...” （目标设备上的媒体数据输出模式可以涉及目标设备被配置为对根据源设备标识符识别出的、来自不同源设备的媒体数据做出不同的响应...） | 对比文件公开了目标设备可以根据接收到的源设备标识符（即发送者ID）来配置不同的输出模式。然而，目标专利的技术特征B明确要求标识**发送者ID**和**媒体类型**。对比文件虽然提及了“媒体数据”，但并未描述目标设备会主动“标识”所接收数据的“媒体类型”（例如，图片、视频、音频等）。其输出模式的配置主要基于发送者标识和/或数据所发往的网络地址（如组播地址），而非基于对媒体数据本身类型的识别。因此，对比文件没有公开“标识媒体类型”这一部分技术特征。 |
| **技术特征C**：在所述计算设备中标识呈现规则，所述呈现规则将所述发送者ID和关联于所接收到的媒体数据的媒体类型与所述计算设备的多个接口中有能力呈现关联于所接收到的媒体数据的媒体类型的一个或多个接口相关， <br> **判断结果**：《未公开》 | 对比文件[0088]段：“Target devices may be configured to associate a predetermined media data output mode with media data which is addressed to a network address being used in association with the group media data delivery mechanism.” （目标设备可以被配置为将预定的媒体数据输出模式与寻址到与群媒体数据传递机制相关联的网络地址的媒体数据相关联。）<br> [0109]段：“...for example auto-playing media data identified as being sourced from one source device, but not auto-playing media data from other source devices.” （例如，自动播放被识别为来自一个源设备的媒体数据，但不自动播放来自其他源设备的媒体数据。） | 对比文件描述了目标设备可以具有“预定的媒体数据输出模式”，例如“自动播放”模式。这种模式可以与特定的源设备（发送者）相关联。然而，目标专利的“呈现规则”是一个将**发送者ID**和**媒体类型**映射到**一个或多个具体接口**（如显示器、耳机）的规则。对比文件中的“输出模式”更接近于一种简单的行为开关（如是否自动播放），并未涉及根据媒体类型选择不同物理或逻辑接口（例如，将来自A的视频发往显示器，将来自A的音频发往耳机）。此外，对比文件的输出模式是基于数据发往的“网络地址”（如组播地址M1）或发送者ID，而非发送者ID与媒体类型的组合。因此，对比文件没有公开目标专利中这种结构化的、接口选择性的“呈现规则”。 |
| **技术特征D**：其中所述呈现规则在所述群通信会话期间能由所述计算设备动态地配置以响应于所述一个或多个接口的操作状态在所述群通信会话期间已改变的指示而改变与所述发送者ID和所述媒体类型相关的所述一个或多个接口 <br> **判断结果**：《未公开》 | 对比文件[0089]段：“Such an auto-play output mode may be disabled by a user if for some reason they do not wish to be disturbed by any such audio output...” （这种自动播放输出模式可以由用户禁用，如果他们由于某种原因不希望被任何此类音频输出打扰...） | 对比文件提到了用户**可以禁用**自动播放模式，这暗示了输出模式（类似于简单的呈现规则）可能被改变。然而，目标专利的技术特征D强调的是：1) **动态配置**；2) **响应于接口操作状态改变的指示**（例如，耳机被拔出、显示器断开）；3) **改变与发送者ID和媒体类型相关的接口**。对比文件仅提及用户手动禁用，并未提及基于接口状态（如外设连接状态）的动态、自动的规则重配置。其改变是基于用户意愿，而非设备接口状态变化的触发。因此，对比文件没有公开该技术特征。 |
| **技术特征E**：经由所述计算设备的与所述发送者ID和关联于所接收到的媒体数据的媒体类型相关的所述一个或多个接口来呈现所接收到的媒体数据。 <br> **判断结果**：《未公开》 | 对比文件[0088]段：“In this way, when a target device receives media data via the group data delivery mechanism, it may process the media data according to an associated output mode.” （以此方式，当目标设备通过群数据传递机制接收到媒体数据时，其可以根据相关联的输出模式来处理媒体数据。）<br> [0100]段：“If target device 404 is configured in a media output mode which allows ‘auto-play’, the RTP media data can be played as audio by target device 404 approximately in real-time as the RTP media is received.” （如果目标设备404被配置为允许“自动播放”的媒体输出模式，RTP媒体数据可以在被接收时由目标设备404近乎实时地作为音频播放。） | 对比文件公开了目标设备根据其配置的输出模式（如“自动播放”）来呈现（播放）接收到的媒体数据。然而，目标专利的技术特征E要求呈现行为是基于“与发送者ID和媒体类型相关的接口”进行的。对比文件中设备的输出是依据一个简单的、可能基于发送者的“模式”（如播放或不播放），并未指向一个由发送者ID和媒体类型共同决定的、特定的“接口”（例如，选择扬声器电话还是蓝牙耳机）。呈现的“接口”在对比文件中是隐含的、默认的（如设备扬声器），而非通过规则选择的结果。因此，该技术特征未被公开。 |
| **技术特征F**：所标识的呈现规则将所述发送者ID和关联于所接收到的媒体数据的所述媒体类型与所述多个接口中若存在的有能力呈现所接收到的媒体数据的第一接口相关以及在所述第一接口不存在的情况下与所述多个接口中有能力呈现所接收到的媒体数据的第二接口相关，以及所述用于呈现所接收到的媒体数据的一个或多个接口包括在所述第一接口存在的情况下的所述第一接口或者在所述第一接口不存在的情况下的所述第二接口。 <br> **判断结果**：《未公开》 | 无对应内容。 | 对比文件完全没有涉及任何根据接口是否存在（例如，“若存在耳机则使用耳机，否则使用扬声器”）来分层或后备选择不同接口的规则。其输出模式不涉及对多个可选接口的存在性进行判断和选择。因此，该技术特征未被公开。 |
| **技术特征G**：其特征在于，所述呈现规则是用户可配置的，所述方法进一步包括：接收用户输入 <br> **判断结果**：《未公开》 | 对比文件[0089]段：“Such an auto-play output mode may be disabled by a user if for some reason they do not wish to be disturbed by any such audio output...” （这种自动播放输出模式可以由用户禁用，如果他们由于某种原因不希望被任何此类音频输出打扰...） | 对比文件提到用户可以禁用自动播放模式，这可以视为一种非常简单的用户配置行为（开启/关闭）。但目标专利中的“用户可配置的呈现规则”范围更广，意味着用户可以建立或修改将发送者ID、媒体类型映射到具体接口的复杂规则。对比文件仅描述了用户对某个单一功能（自动播放）的开关控制，并未涉及用户创建或修改规则本身。因此，该技术特征未被充分公开。 |
| **技术特征H**：响应于所述用户输入而配置所述呈现规则。 <br> **判断结果**：《未公开》 | 同技术特征G引用。 | 基于与技术特征G相同的理由，对比文件仅暗示用户可以改变设备行为（禁用自动播放），但并未描述一个明确的“配置呈现规则”的过程或动作。因此，该技术特征未被公开。 |
| **技术特征I**：其特征在于，接收用户输入和响应于所述用户输入而配置所述呈现规则是在所述群通信会话期间完成的。 <br> **判断结果**：《未公开》 | 无对应内容。 | 对比文件没有提及用户配置行为发生的具体时机，更没有明确说明是在群通信会话期间动态完成的。因此，该技术特征未被公开。 |
| **技术特征J**：其特征在于，所述一个或多个接口包括以下一者或多者：显示器、头戴式耳机、扬声器电话、端口、应用或辅助设备。 <br> **判断结果**：《隐含公开》 | 对比文件[0006]段：“Typically, the target devices include telephone devices and the audio output loudspeakers are built into the telephone devices.” （通常，目标设备包括电话设备，音频输出扬声器内置于电话设备中。）<br> [0089]段提及“audio output”（音频输出），[0100]段提及“played as audio”（作为音频播放）。 | 对比文件中的目标设备（如SIP电话、扬声器）必然包含用于呈现媒体（特别是音频）的硬件接口，例如内置扬声器（属于“扬声器电话”范畴）、听筒（可视为一种“头戴式耳机”）。虽然对比文件没有像目标专利那样明确列举一个接口列表，但本领域技术人员可以毫无疑义地理解，任何能够播放音频的设备都必然包含至少一个音频输出接口。因此，对比文件隐含公开了“扬声器电话”等音频输出接口的存在。虽然“显示器”、“应用”等其他接口未被提及，但技术特征J是一个开放式的列举，包含“以下一者或多者”，对比文件公开了其中的部分（音频相关接口），因此该技术特征被隐含公开。 |
| **技术特征K**：其特征在于，进一步包括：存储对所述计算设备的被用来呈现所接收到的媒体数据的所述一个或多个接口的指示 <br> **判断结果**：《未公开》 | 无对应内容。 | 对比文件没有描述目标设备会存储关于“哪个接口被用于呈现媒体”的指示或历史记录。其焦点在于实时传递和播放媒体，而非记录呈现方式。因此，该技术特征未被公开。 |
| **技术特征L**：至少部分地基于所存储的对用于呈现所接收到的媒体数据的所述一个或多个接口的指示来更新所标识的呈现规则以生成经更新呈现规则 <br> **判断结果**：《未公开》 | 无对应内容。 | 对比文件既未公开“存储接口指示”（特征K），更未公开基于此类存储记录来“更新呈现规则”。这涉及机器学习或自适应行为，在对比文件中完全没有体现。因此，该技术特征未被公开。 |
| **技术特征M**：在所述群通信会话期间在所述计算设备中接收新媒体数据，所述新媒体数据包括另一发送者标识符(另一发送者ID) <br> **判断结果**：《未公开》 | 同技术特征A引用。 | 虽然对比文件隐含了接收包含发送者标识符的媒体数据（或警报），但技术特征M-N-O-P-Q-R作为一系列连续步骤，其前提是存在一个通过历史使用数据“更新”过的“经更新呈现规则”（特征L）。由于特征L未被公开，这一系列基于“经更新呈现规则”处理“新媒体数据”的后续步骤在对比文件中没有对应基础。对比文件描述的是每次媒体传递都遵循可能预配置但静态的输出模式，而非基于学习更新的规则。因此，该组技术特征未被公开。 |
| **技术特征N**：在所述计算设备中标识与所接收到的新媒体数据相关联的所述另一发送者ID <br> **判断结果**：《未公开》 | 同技术特征B引用。 | 理由同技术特征M。 |
| **技术特征O**：在所述计算设备中标识所接收到的新媒体数据的新媒体类型 <br> **判断结果**：《未公开》 | 同技术特征B引用。 | 理由同技术特征M。 |
| **技术特征P**：在所述计算设备中标识与所述另一发送者ID和所述新媒体类型相关联的经更新呈现规则 <br> **判断结果**：《未公开》 | 无对应内容。 | 理由同技术特征M。 |
| **技术特征Q**：基于所标识的经更新呈现规则来选择所述计算设备的另一接口以用于呈现所述新媒体数据 <br> **判断结果**：《未公开》 | 无对应内容。 | 理由同技术特征M。 |
| **技术特征R**：经由所述计算设备的所选另一接口来呈现所述新媒体数据。 <br> **判断结果**：《未公开》 | 无对应内容。 | 理由同技术特征M。 |
| **技术特征S**：其特征在于，所述媒体类型是以下一者或多者：图片、文本消息、视频、声音、多用途因特网邮件扩展(MIME)、分辨率、格式或文件扩展。 <br> **判断结果**：《隐含公开》 | 对比文件通篇描述的是“媒体数据”的传递，并多次以“音频”（audio）、“RTP媒体数据”、“语音”（speech）作为示例（例如[0100]段）。 | 对比文件明确将“音频”（sound/audio）作为其传递的媒体数据类型。虽然它没有提及图片、文本、视频等其他具体类型，但技术特征S是一个开放式的列举。本领域技术人员知晓，群通信中传递的媒体数据可以是多种类型的。对比文件公开了“声音”这一媒体类型，因此该技术特征被部分隐含公开。在宽松的隐含公开判断标准下，可以认为对比文件隐含公开了技术特征S中“声音”这一具体类型。 |
| **技术特征T**：其特征在于，进一步包括：将对所述计算设备的用于呈现所接收到的媒体数据的所述一个或多个接口的指示从所述计算设备发送给与所标识的发送者ID相关联的计算设备。 <br> **判断结果**：《未公开》 | 无对应内容。 | 对比文件描述的媒体数据传递是单向的（如群呼），重点是将媒体从源设备传递到多个目标设备。没有提及目标设备在呈现媒体后，会将其所使用的接口信息反馈给源设备或其他设备。因此，该技术特征未被公开。 |
| **技术特征U**：其特征在于，进一步包括：将对所述计算设备的用于呈现所接收到的媒体数据的所述一个或多个接口的指示从所述计算设备发送给参与所述群通信会话的所有其他计算设备。 <br> **判断结果**：《未公开》 | 无对应内容。 | 理由同技术特征T。对比文件没有描述这种呈现信息的反馈机制。因此，该技术特征未被公开。 |
<<<a>>><<<j>>><<<s>>>