对比文件名称：2008-06-26_US2008155062A_发明申请_US20080155062A1 System for providing media data
目标专利名称：用于群通信中基于动态讲话者ID的媒体处理的框架和方法 CN104885487B
模型名称：DeepSeek
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **技术特征A** 《未公开》 | 未直接引用。 | 对比文件描述了一种家庭媒体网络系统，其中中央服务器（如PC、网络存储设备）向客户端设备（如电视、手机、PDA、立体声音响）提供媒体流（参见[0030]-[0032]，[0041]-[0044]）。媒体数据是从服务器流向客户端的。虽然客户端设备可以被识别和选择（例如“Television (Living Room)”），但这种识别是用于指定媒体流的目标接收设备（参见[0042]），而非如目标专利所要求的，在**群通信会话**中，媒体数据本身“包括所述媒体数据的发送者的标识符(发送者ID)”。目标专利的“发送者ID”特指群通信中对等参与者（即其他用户）的唯一标识（参见[0019]），用于区分媒体来源。对比文件未描述在媒体数据中携带或由接收方标识对等参与者的“发送者ID”。 |
| **技术特征B** 《未公开》 | 未直接引用。 | 对比文件涉及标识媒体类型，例如音频、视频、图片等（参见[0055]），以便进行适配处理。然而，如特征A所述，对比文件未公开标识与媒体数据相关联的“发送者ID”。因此，对比文件仅部分公开了“标识媒体类型”，但未公开“标识发送者ID”以及将两者结合进行标识的技术方案。 |
| **技术特征C** 《未公开》 | 未直接引用。 | 对比文件允许用户通过“Send To”功能选择目标播放设备（参见[0042]，[0048]），这可以视为一种简单的“呈现规则”，即将媒体流定向到特定设备。然而，目标专利的“呈现规则”是预配置的、将“发送者ID”和“媒体类型”与设备“接口”相关联的规则（参见[0020]-[0021]，[0029]，图4）。对比文件的选择是基于用户实时操作（点击菜单选择目标设备），而非基于预存的、与特定发送者ID和媒体类型绑定的规则。更重要的是，对比文件未建立“发送者ID”与接口之间的任何关联。因此，该技术特征未被公开。 |
| **技术特征D** 《未公开》 | 未直接引用。 | 对比文件支持将媒体流从一个设备重定向到另一个设备（参见[0031]，[0048]），这体现了动态改变媒体流向的能力。然而，这种改变是响应用户的“Send To”指令（一种用户输入），而不是目标专利所限定的“响应于所述一个或多个接口的操作状态在所述群通信会话期间已改变的指示”。目标专利说明书[0036]及图6描述了因接口状态改变（如耳机被移除）而自动触发规则重新配置。对比文件未描述这种由接口操作状态变化自动触发规则重新配置的机制。 |
| **技术特征E** 《隐含公开》 | [0042]：“从选择屏幕，用户可以选择实际将媒体文件发送到哪里。...用户选择‘电视(客厅)’...” <br> [0048]：“播放媒体文件在按下此按钮后立即暂停...选择屏幕显示出来，用户可以选择实际将媒体文件发送到哪里。” <br> [0052]：“一旦用户指示他希望继续播放，网络附加存储设备610继续将媒体数据流式传输到立体声音响630...” | 对比文件明确描述了媒体数据经由用户选择的设备（即接口）进行呈现的过程。例如，用户选择“电视(客厅)”后，媒体文件在电视上播放（图5b, HTTP流）。在另一个例子中，媒体流从手持设备重定向到立体声音响后，在立体声音响上播放（图7b）。虽然选择设备的逻辑（基于用户实时选择）与目标专利（基于预配置的发送者ID和媒体类型规则）不同，但“经由所述计算设备的...一个或多个接口来呈现所接收到的媒体数据”这一最终动作在对比文件中已被实质公开。本领域技术人员可以从对比文件的媒体播放过程毫无疑义地得出“通过设备接口呈现媒体”的技术方案。因此，该特征被直接公开。 |
| **技术特征F** 《未公开》 | 未直接引用。 | 对比文件的重定向功能允许用户在设备之间切换媒体流。例如，从手持设备切换到立体声音响（图6a-7b）。然而，这种切换是用户手动、显式选择的结果。目标专利特征F限定的是一种**预定义的备用规则**：规则关联了第一接口（首选）和第二接口（备用），并在第一接口不存在时**自动**选择第二接口（参见[0021]，[0035]及图4示例“耳机，否则无输出”）。对比文件没有公开这种基于接口存在性自动判断和切换的、预配置的备用呈现规则逻辑。 |
| **技术特征G** 《隐含公开》 | [0042]：“用户可能按下专用的遥控按钮‘发送到’或播放应用程序中的菜单操作...” <br> [0048]：“因此，他选择播放应用程序中的‘发送到’菜单操作...用户选择‘Hi-Fi(客厅)’。” <br> [0057]：“...可以提供‘发送到’功能...或设备用户界面中的图形或文本菜单项...” | 对比文件多次描述了用户通过界面操作（如按下“Send To”按钮、选择菜单项）来选择将媒体发送到哪个设备。这种用户操作实质上就是一种“用户输入”，用于配置或指定媒体呈现的目标设备/接口。虽然对比文件未使用“呈现规则”一词，但其描述的“用户选择目标设备”这一行为，在广义上可以理解为一种即时、动态的“配置媒体呈现方式”的过程。本领域技术人员可以合理推断，用户通过输入来指定媒体播放位置，即构成了对媒体呈现方式的“配置”。因此，该特征被隐含公开。 |
| **技术特征H** 《隐含公开》 | [0048]：“播放媒体文件在按下此按钮后立即暂停...选择屏幕显示出来，用户可以选择实际将媒体文件发送到哪里。” <br> [0052]：“一旦用户指示他希望继续播放，网络附加存储设备610继续将媒体数据流式传输到立体声音响630...” | 如特征G所述，用户输入（选择目标设备）导致了媒体流向的改变。在对比文件的流程中，响应用户在“Send To”菜单中的选择，系统会建立到新设备的连接并开始向该设备流式传输媒体（参见[0044]-[0045]，[0052]）。这实质上是“响应于所述用户输入而配置所述呈现规则”（即配置了“媒体应流向哪个接口”）并执行的结果。本领域技术人员可以从该过程推断出用户输入与媒体呈现配置之间的响应关系。因此，该特征被隐含公开。 |
| **技术特征I** 《隐含公开》 | [0041]-[0044] 描述了用户在桌面PC上预览电影时，决定继续在电视上观看，并在播放过程中按下“Send To”按钮。 <br> [0048]-[0052] 描述了用户在PDA上听歌时，决定继续在立体声音响上播放，并在播放过程中选择“Send To”菜单。 | 对比文件描述的所有用例（如Use case #1和#2）均是在一个正在进行的媒体播放会话（例如观看电影、收听歌曲）期间，用户发起“Send To”操作来重定向媒体流。这种媒体播放会话可以类比为目标专利中的“群通信会话”，都是持续的媒体交换或呈现过程。用户在这些会话“期间”进行配置操作（选择新设备）的行为，在对比文件中是明确记载的。因此，本领域技术人员可以合理推断出在媒体会话期间完成用户配置的可能性。该特征被隐含公开。 |
| **技术特征J** 《直接公开》 | [0030]：“...客户端设备可以是电视、笔记本电脑、PDA、手机等...” <br> [0037]：“接收器装置可以集成在电视机、PDA、手机、PC、笔记本电脑中。” <br> [0041]：“图3显示了电视和机顶盒310、智能手机320、台式PC 330、笔记本电脑340、手机350以及手持设备或PDA 360...” | 对比文件明确列举了多种可作为媒体播放终端（即接口）的设备，包括：电视（包含显示器）、立体声音响（扬声器电话/扬声器的示例）、手机（可包含头戴式耳机、扬声器）、PDA、PC、笔记本电脑（包含显示器、扬声器、端口）等（参见[0030], [0037], [0041]）。这些设备具体实现了目标专利所列举的接口类型，如显示器（电视、PC屏幕）、扬声器电话/扬声器（立体声音响、手机扬声器）、头戴式耳机（连接至手机或PDA）、端口（用于连接这些设备）等。因此，这些接口类型已被对比文件直接公开。 |
| **技术特征K** 《未公开》 | 未直接引用。 | 对比文件没有描述存储设备使用历史或记录哪个接口曾被用于呈现特定媒体。其核心是基于用户的即时指令进行媒体流控制，而非基于历史数据的学习或更新。 |
| **技术特征L** 《未公开》 | 未直接引用。 | 如特征K所述，由于没有存储接口使用指示，因此也不存在基于此来“更新所标识的呈现规则”的机制。目标专利此特征涉及机器学习动态更新规则（参见[0038]，图7），对比文件未公开此概念。 |
| **技术特征M** 《未公开》 | 未直接引用。 | 特征M-P、Q、R是一组基于已更新的规则（特征L）处理新媒体数据的连续步骤。由于对比文件未公开规则更新机制（特征K、L），因此这一系列依赖于更新规则的特征也未被公开。此外，对比文件中的“新媒体数据”接收是服务器流式传输的一部分，不涉及“另一发送者ID”的概念。 |
| **技术特征N** 《未公开》 | 未直接引用。 | 同特征M所述。对比文件未涉及标识对等参与者的“发送者ID”。 |
| **技术特征O** 《直接公开》 | [0055]：“...例如，视频包括电视、音频、图片，还包括文档、电子表格等...” | 对比文件明确提到了其系统可以处理多种类型的媒体数据，包括但不限于：视频、音频、图片、文档等（参见[0055]）。这涵盖了目标专利中列举的“视频、声音、图片”等媒体类型。虽然“文本消息”作为通信消息未被明确提及，但“文档”可视为广义的文本数据。因此，媒体类型被直接公开。 |
| **技术特征P** 《未公开》 | 未直接引用。 | 同特征M所述，由于缺乏规则更新机制，且没有发送者ID与规则关联的概念，此特征未被公开。 |
| **技术特征Q** 《未公开》 | 未直接引用。 | 对比文件中接口的选择是基于用户的实时指令（“Send To”选择），而不是基于“经更新呈现规则”的选择。因此，该特征未被公开。 |
| **技术特征R** 《隐含公开》 | [0052]：“一旦用户指示他希望继续播放，网络附加存储设备610继续将媒体数据流式传输到立体声音响630...” | 如特征E所述，对比文件明确描述了在用户选择或指示后，通过所选设备（接口）呈现媒体数据。此特征与特征E本质相同，只是应用于“新媒体数据”和“所选另一接口”的场景。在对比文件的用例中，重定向后的媒体流就是在新的接口（如立体声音响）上呈现的。本领域技术人员可以毫无疑义地得出该技术方案。因此，该特征被直接公开。 |
| **技术特征S** 《直接公开》 | [0055]：“SendMedia@Home功能...使得能够重定向任何类型的媒体，例如，视频包括电视、音频、图片，还包括文档、电子表格等...” | 对比文件明确列举了其系统可处理的媒体类型，包括：视频、音频（声音）、图片。虽然“文本消息、MIME、分辨率、格式、文件扩展”等未被逐一列出，但“文档、电子表格”属于文本类数据，且本领域技术人员知晓视频、音频、图片等媒体都具有分辨率、格式、文件扩展等属性。对比文件公开了核心的媒体种类，因此该特征被直接公开。 <<<S>>> |
| **技术特征T** 《未公开》 | 未直接引用。 | 对比文件描述了服务器向客户端发送媒体流，以及客户端向服务器发送控制指令（如暂停、播放）。但没有描述接收媒体数据的设备（客户端）将其呈现接口的指示“发送给与所标识的发送者ID相关联的计算设备”（即媒体发送方）。其通信模型不包含这种对等间的呈现反馈。 |
| **技术特征U** 《未公开》 | 未直接引用。 | 同特征T，对比文件未描述客户端设备将其接口指示发送给“所有其他计算设备”。其交互主要发生在服务器与单个或部分客户端之间，而非所有参与者之间的广播通信。 |
<<<E>>><<<J>>><<<O>>><<<R>>><<<S>>><<<g>>><<<h>>><<<i>>>