对比文件名称：2005-12-15_US2005278411A_发明申请_US20050278411A1 Data delivery device
目标专利名称：用于提供协作数据再利用的方法和设备 CN101946485B
模型名称：DeepSeek最新版本模型
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：其包括：在第一客户端处发现紧密接近的其它客户端** | “所述检索手段基于包括所述周围移动装置的位置的管理信息，检索存在于从所述请求移动装置起预定区域内的周围移动装置的存在。” (说明书第[0009]段)<br>“所述位置信息检索部分13将请求信号发送到所述位置管理装置200，以进一步请求检索在接收到的位置信息周围预定区域中存在的移动装置。” (说明书第[0071]段)<br>“在此示例中，移动装置B至D的电话号码被提取并发送到数据分发装置100。” (说明书第[0071]段) | **《直接公开》**<br>对比文件公开了数据分发设备（服务器）在收到请求移动装置（即第一客户端）的下载请求后，基于管理信息检索存在于该请求移动装置周围预定区域内的其它移动装置（即其它客户端）。虽然“发现”过程由服务器执行，但其检索结果（其他移动装置的标识信息）会被通知给请求移动装置（见说明书第[0078]段），这使得请求移动装置能够知晓其周围存在的其它客户端。因此，本领域技术人员能够毫无疑义地得出，第一客户端（请求移动装置）通过服务器的辅助，实现了对紧密接近的其它客户端的发现。 |
| **技术特征B：从一对多发射中的多个数据流中识别并选择用于再现的一个以上数据流** | 未发现相关内容。 | **《未公开》**<br>目标专利的技术特征B强调从“一对多发射中的多个数据流”中识别和选择数据流进行再现。对比文件描述的是移动设备从其他单个移动设备或服务器“下载”一个“文件”（如应用文件，见说明书第[0004]、[0005]、[0090]段），整个过程涉及的是单个文件的点对点或点对多点传输，并未涉及“一对多发射”多个不同的“数据流”，也没有描述客户端从多个流中识别和选择用于“再现”的流。两者技术方案的本质不同。 |
| **技术特征C：与所述其它客户端中的至少一者协作以产生内容的聚合再现** | “用户所请求的移动设备（移动设备A）对任意移动设备（即，一个或多个周围移动设备（移动设备B至D））发送请求信号，以请求应用和识别该应用的信息。” (说明书第[0081]段)<br>“接收到请求信号的任意移动设备将所述应用的数据发送到已发送下载请求的请求移动设备（移动设备A）。” (说明书第[0081]段) | **《未公开》**<br>对比文件公开了请求移动设备从周围移动设备之一“下载”一个完整的应用文件。这是一个简单的文件传输过程：一个设备提供完整文件，另一个设备接收。目标专利的“协作以产生内容的聚合再现”是指多个客户端（设备）各自可能提供内容的一部分或从不同数据流获取内容，然后组合起来形成一个聚合的、统一的再现体验（如说明书第[0006]、[0026]、[0051]段所述）。对比文件完全没有描述这种多个设备协作组合内容以产生单一聚合输出的过程。 |
| **技术特征D：其中，所述第一客户端再现的内容不同于其它客户端再现的内容。** | “所述请求移动设备从另一移动设备（即，周围移动设备之一）接收所传输的应用数据。” (说明书第[0082]段)<br>“移动设备可以下载各种应用文件或数据文件” (说明书第[0004]段) | **《未公开》**<br>对比文件描述的是请求移动设备下载并（随后）执行或使用一个应用文件。对于提供文件的“周围移动设备”，说明书并未描述其自身正在“再现”该文件的内容。目标专利的特征D限定了多个客户端同时“再现”内容，且各自再现的内容不同。对比文件既未公开多个客户端同时进行内容再现的场景，更未限定它们再现的内容不同。 |
| **技术特征E：其中发现紧密接近的其它客户端包括：发送询问以确定所述其它客户端是否可参与协作体验** | “所述被设置为Master的请求移动设备向周围移动设备（即，周围区域中的移动设备）发送检索信号，并等待来自通信可用区域（大约10米）内周围移动设备的响应。” (说明书第[0040]段) | **《隐含公开》**<br>对比文件公开了在建立蓝牙连接的过程中，被设置为Master（主设备）的请求移动设备会向周围移动设备发送“检索信号”，并等待响应。这个过程本质上就是一种“询问”周围设备是否存在并能够通信的机制。虽然对比文件中询问的直接目的是建立用于文件传输的通信链路，而非目标专利中“确定是否可参与协作体验”，但“发送询问以确定其它客户端是否可参与”这一动作本身已被对比文件公开。本领域技术人员可以从“发送检索信号并等待响应”这一公开内容中，合理推断出这是客户端主动发现并确认周围设备可参与某种交互（在此为文件传输）的一种方式。因此，该技术特征被隐含公开。 |
| **技术特征F：接收对所述询问的响应，其中所述响应是接受或拒绝参与。** | “所述被设置为Master的请求移动设备向周围移动设备（即，周围区域中的移动设备）发送检索信号，并等待来自通信可用区域（大约10米）内周围移动设备的响应。” (说明书第[0040]段)<br>“接收到该检索信号的周围移动设备作出响应，向作为Master的请求移动设备提供其电话号码。” (说明书第[0040]段) | **《隐含公开》**<br>结合技术特征E的论述，对比文件公开了请求移动设备（Master）发送检索信号后，会“等待响应”。周围移动设备如果接收到信号并愿意通信，则会“作出响应”并提供其电话号码，这相当于“接受”参与（文件传输）。如果周围设备未响应（例如，超出范围、关机、拒绝连接），则相当于“拒绝”参与。因此，本领域技术人员可以从“等待响应”和“作出响应”的公开内容中，合理推断出询问的接收方会以响应（接受）或不响应（拒绝）的方式来表明其参与意愿。 |
| **技术特征G：其进一步包括：基于类型而识别所述一个以上数据流，其中所述类型是视频流、数据流、音频流或其组合** | 未发现相关内容。 | **《未公开》**<br>目标专利的技术特征G明确限定了基于“视频流、数据流、音频流或其组合”的类型来识别数据流。对比文件通篇描述的是下载“应用文件”或“数据文件”（见说明书第[0004]段），并未将这些文件或传输内容划分为视频、数据、音频等“流”类型，也未基于此类流类型进行识别或选择。两者涉及的技术概念不同。 |
| **技术特征H：部分基于所述类型而与至少一个其它客户端共享功能。** | 未发现相关内容。 | **《未公开》**<br>技术特征H依赖于技术特征G所定义的“类型”。由于对比文件未公开基于视频、数据、音频等流类型识别数据流的技术特征G，因此也就不存在“部分基于所述类型而与至少一个其它客户端共享功能”的基础。对比文件中的文件传输是为了让请求设备获得一个完整的应用，而非多个设备基于内容类型“共享功能”。 |
| **技术特征I：其中与所述其它客户端中的至少一者协作包括与至少一个其它客户端大体上同时使用所述流中的数据。** | “接收到请求信号的任意移动设备将所述应用的数据发送到已发送下载请求的请求移动设备（移动设备A）。” (说明书第[0081]段)<br>“在请求移动设备（移动设备A）中，完成从另一移动设备（即，周围移动设备之一）传输的应用数据的接收。” (说明书第[0082]段) | **《未公开》**<br>对比文件描述的是一个顺序过程：请求设备下载文件，接收完成后可能再使用该文件。目标专利的特征I强调“大体上同时使用所述流中的数据”，这暗示了多个客户端在时间上同步地、协作地利用数据（例如，共同参与一个实时比赛）。对比文件仅公开了单向的文件传输，没有公开多个客户端在接收或下载过程中“同时使用”数据以实现协作体验。 |
| **技术特征J：其中所述一个以上数据流包含用于双重用途的信息。** | 未发现相关内容。 | **《未公开》**<br>目标专利的“双重用途”指数据流中的信息既可以用于传统的内容呈现（如观看统计数据），又可以用于驱动另一种体验（如参与比赛）（见说明书第[0026]、[0029]、[0050]段）。对比文件中的“应用文件”被下载后用于安装和执行，是单一用途。没有任何内容表明对比文件中的文件或数据具有目标专利所定义的“双重用途”。 |
| **技术特征K：其中所述协作是共享的比赛体验。** | 未发现相关内容。 | **《未公开》**<br>目标专利明确将“协作”限定为“共享的比赛体验”（参见说明书第[0026]、[0051]、[0063]段）。对比文件中的“协作”仅限于文件从一个设备传输到另一个设备，目的是分担服务器负载（见说明书第[0008]、[0090]段），完全不具备“比赛”或“共享体验”的性质或目的。 |
| **技术特征L：其中识别并选择用于再现的一个以上数据流是部分基于用户偏好、用户行为或其组合。** | “所述通信部分11从请求移动设备接收与下载应用的请求一起的、用于识别要下载的应用的信息（文件名、应用ID等）。” (说明书第[0033]段) | **《未公开》**<br>对比文件中，请求移动设备请求下载的是特定的“应用文件”，这是用户明确请求某个具体应用的结果。说明书没有描述存在多个数据流供选择，更没有描述基于用户的历史偏好或行为模式来自动识别和选择数据流的过程。目标专利的特征L强调的是基于用户画像（偏好、行为）进行自动或半自动的流选择，这与对比文件中用户主动请求特定文件的模式有本质区别。 |
<<<A>>>
<<<e>>>
<<<f>>>