对比文件名称：2005-12-29_US2005286546A_发明申请_US20050286546A1 Synchronized media streaming between distributed peers
目标专利名称：用于提供协作数据再利用的方法和设备CN101946485B
模型名称：专利代理师
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：其包括：在第一客户端处发现紧密接近的其它客户端<br>**《直接公开》** | 第[0046]段：“A tunA player discovers like players that are within range, and establishes communications with those players, by periodically multicasting packets announcing their presence to all nearby devices via the UDP channel 124 as indicated at 133.” <br>第[0047]段：“The ad hoc service seen at 134 in FIG. 1 listens for incoming UDP packets on the channel 137 as indicated at 203 in FIG. 2. When a received packet is detected at 205, its contents are examined at 207 to determine if it is a peer announcement packet and, if it is, the peer list seen at 137 in FIG. 1 is checked to see if the received packet identifies a player already known to be nearby. If not, the identification of the newly arrived player is posted as seen at 209 to the peer list.” | 对比文件明确公开了第一客户端（tunA播放器）通过周期性多播信标包（peer announcement packet）来发现附近（within range）其他同类客户端（like players）的技术方案，并维护一个对等设备列表（peer list）。这属于本领域技术人员能够毫无疑义地得出的“发现紧密接近的其它客户端”的技术手段，且其在对比文件中的作用（建立邻近设备间的通信和社交网络）与在目标专利中的作用（为后续协作建立连接）实质相同。因此，该技术特征被**直接公开**。 |
| **技术特征B**：从一对多发射中的多个数据流中识别并选择用于再现的一个以上数据流<br>**《未公开》** | 第[0039]段：“During playback, a selected audio file is processed by an MP3 decoder 107 for playback.” <br>第[0049]段：“When a user selects a local audio track, the system begins to multicast packets consisting of some timing info, and frames of MP3 data to all interested peers (itself included) using the output multicasting streaming process seen at 124 in FIG. 1.” <br>第[0054]段：“The audio streaming multicasting service 124 reads frames of MP3 encoded data from a locally stored file, and transmits them via specially formatted UDP multicast packets...” | 对比文件公开了客户端可以播放本地存储的音频文件（selected audio file），并且可以将当前播放的音频内容以多播（multicast）形式发送出去。然而，对比文件描述的是对单一内容源（本地文件）的播放和流式传输，并未公开存在一个“一对多发射”提供“多个数据流”，并由客户端从中“识别并选择用于再现的一个以上数据流”的技术方案。目标专利强调从多个并发的数据流中选择子集，而对比文件是选择播放哪个文件或是否“调入”他人正在播放的单一流。两者技术方案不同，对比文件未公开该特征。 |
| **技术特征C**：与所述其它客户端中的至少一者协作以产生内容的聚合再现<br>**《隐含公开》** | 第[0025]段：“Shared music experience: A person can listen to their own music... but they can also tune in and listen to the same music and programming other people are listening to on their tunA devices, resulting in a shared music experience.” <br>第[0049]段：“When a user selects a local audio track, the system begins to multicast packets ... to all interested peers (itself included) ... The timing info is used to regulate the contents of the buffer and the requests from the decoder 107 to provide a synchronized audio experience among the peers.” | 对比文件的核心目的就是让多个邻近设备能够同步播放相同的音乐，以创造“共享的音乐体验”（shared music experience）。当一个设备“调入”（tune in）另一个设备时，它们通过同步算法确保播放内容在时间上一致，这实质上构成了多个客户端协作，以产生一个在时间上同步的、统一的音频再现体验。虽然目标专利的“聚合再现”可能包含更复杂的组合，但根据宽松的隐含公开判断标准，本领域技术人员完全有可能从对比文件所公开的“同步共享音频体验”中，合理推断出这是一种客户端间协作以产生内容（聚合）再现的技术方案。因此，该技术特征被**隐含公开**。 |
| **技术特征D**：其中，所述第一客户端再现的内容不同于其它客户端再现的内容。<br>**《未公开》** | 第[0025]段：“Audio synchronization: An audio stream timing/delay algorithm enables the audio playback to be perfectly synchronized on a source player and any nearby destination player, so that people tuned into a particular person's device can be listening to exactly what that other person is listening to.” <br>第[0049]段：“...to provide a synchronized audio experience among the peers.” | 对比文件明确强调并致力于实现所有参与设备“完美同步”（perfectly synchronized）地播放“完全相同”（exactly what that other person is listening to）的内容。其技术目的和效果是消除差异，实现一致性。这与技术特征D所要求的“第一客户端再现的内容不同于其它客户端再现的内容”正好相反。因此，对比文件不仅未公开该特征，而且教导了相反的技术方向。 |
| **技术特征E**：其中发现紧密接近的其它客户端包括：发送询问以确定所述其它客户端是否可参与协作体验<br>**《未公开》** | 第[0046]段：“A tunA player discovers like players that are within range, and establishes communications with those players, by periodically multicasting packets announcing their presence to all nearby devices...” <br>第[0048]段：“When a newly arriving player is detected, the IM communication module 132 requests profile information... from the newly arriving player.” | 对比文件中的发现机制是自动的、广播式的信标（beaconing）通知，而非目标专利中所述的“发送询问以确定是否可参与协作体验”。对比文件中在发现后请求的是个人资料信息（profile information），并非针对“是否参与协作”的询问。两者在交互方式和目的上均不相同。因此，该技术特征未被公开。 |
| **技术特征F**：接收对所述询问的响应，其中所述响应是接受或拒绝参与。<br>**《未公开》** | 无对应内容。 | 由于对比文件未公开技术特征E（发送询问），因此自然也不存在接收针对该询问的“接受或拒绝参与”的响应。对比文件中设备间的连接建立是基于自动发现和资料请求，未涉及对协作邀请的明确接受或拒绝流程。 |
| **技术特征G**：其进一步包括：基于类型而识别所述一个以上数据流，其中所述类型是视频流、数据流、音频流或其组合<br>**《未公开》** | 第[0039]段：“Audio files recorded in the MP3 format, which are referred to herein as “songs,” typically consist of recorded music performances...” <br>第[0077]段：“The preferred embodiment permits audio programming to be shared, but the principles of the invention are also applicable to the sharing of video and other forms of time-based media content as defined earlier.” | 对比文件具体实施方式中处理的是音频流（MP3文件）。虽然说明书中提及原理可应用于视频等其他媒体（第[0077]段），但这仅是泛泛而谈的可能性，并未在具体技术方案中公开如何“基于类型（视频、数据、音频）来识别数据流”。目标专利强调的是从多个流中基于类型进行识别和选择，而对比文件未公开该具体技术手段。 |
| **技术特征H**：部分基于所述类型而与至少一个其它客户端共享功能。<br>**《未公开》** | 第[0025]段：“Shared music experience: A person can listen to their own music... but they can also tune in and listen to the same music and programming other people are listening to on their tunA devices, resulting in a shared music experience.” | 对比文件共享的功能是“同步播放音频”，但这并非是基于数据流的“类型”（如视频、音频、数据）来决定共享何种功能。其共享的功能是固定的（音频播放），与流类型无关联。目标专利的特征H限定了共享功能是“部分基于类型”，对比文件未公开此限定关系。 |
| **技术特征I**：其中与所述其它客户端中的至少一者协作包括与至少一个其它客户端大体上同时使用所述流中的数据。<br>**《直接公开》** | 第[0025]段：“Audio synchronization: An audio stream timing/delay algorithm enables the audio playback to be perfectly synchronized on a source player and any nearby destination player...” <br>第[0059]-[0063]段：详细描述了同步算法，旨在确保所有收听设备在同一时间播放相同的声音。例如第[0060]段：“The human ear will assume two audio signals are ‘coherent’ (i.e. from the same source) if they arrive within 30 ms of each other.” | 对比文件的核心创新点之一就是通过精确的同步算法，确保多个设备能够“完美同步”地播放音频流。这明确公开了多个客户端“大体上同时使用所述流中的数据”（要求时间差在30毫秒内）的技术方案。该特征在对比文件中的作用（创造共享音乐体验）与在目标专利中（协作再现）的作用相同。因此，该技术特征被**直接公开**。 |
| **技术特征J**：其中所述一个以上数据流包含用于双重用途的信息。<br>**《未公开》** | 第[0039]段：“Audio files recorded in the MP3 format, which are referred to herein as “songs,” typically consist of recorded music performances...” <br>第[0049]段：“...multicast packets consisting of some timing info, and frames of MP3 data...” | 对比文件中的数据流（MP3音频包）用途单一，即用于音频播放以创造共享体验。流中附带的时间信息仅用于同步目的，并未公开该流中的数据（如音乐内容本身）还可用于其他独立的、并行的目的（例如，目标专利中所述的既提供信息又作为比赛基础）。对比文件未提及“双重用途”的概念。 |
| **技术特征K**：其中所述协作是共享的比赛体验。<br>**《未公开》** | 第[0025]段：“Shared music experience: A person can listen to their own music... but they can also tune in and listen to the same music and programming other people are listening to on their tunA devices, resulting in a shared music experience.” | 对比文件定义的协作是“共享的音乐体验”（shared music experience），这是一种社交化的共同聆听体验，可能促进交流。但其中并未包含任何“比赛”（contest, game）的要素，如竞争、打分、预测结果等。目标专利明确将协作限定为“共享的比赛体验”，两者在协作的具体内容和目的上存在本质区别。 |
| **技术特征L**：其中识别并选择用于再现的一个以上数据流是部分基于用户偏好、用户行为或其组合。<br>**《隐含公开》** | 第[0032]段：“tunA interface is “skinnable.” ... One screen shows a list of other users who are carrying other tunA players that are in range, along with information about each in-range device...” <br>第[0070]-[0072]段：描述了用户界面，用户可以通过触摸屏选择播放本地歌曲列表中的歌曲（图5），或者从附近设备列表中选择一个设备并“调入”（tune in）其正在播放的歌曲（图6，图7）。 | 对比文件公开了用户可以通过图形界面主动选择播放自己设备上的歌曲，或者选择“调入”附近某个其他用户设备正在播放的歌曲。这种“选择用于再现”的行为，是基于用户的主观意愿和操作（一种用户行为）。虽然对比文件没有明确使用“用户偏好”一词，但用户的选择操作本身就是其偏好的直接体现。根据宽松的隐含公开判断标准，本领域技术人员可以从“用户通过界面选择播放内容或播放源”这一公开内容中，合理推断出“识别并选择用于再现的数据流是基于用户行为（即用户的选择操作）”。因此，该技术特征被**隐含公开**。 |
<<<A>>><<<I>>><<<c>>><<<l>>>