**对比文件名称**：2008-03-19_EP1901525A_发明公开_EP1901525A1 File repair method for a content distribution system
**目标专利名称**：使用EMBMS中的调度描述段的完整文件修复的方法、装置和介质 CN105247840B
**本次调用的模型名称**：DeepSeek-R1
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：接收针对服务的服务通告，所述服务通告包括广播调度描述，所述广播调度描述包括以下至少一项：针对在所述服务内发送的文件的文件调度元素，所述文件调度元素包括指示所述文件的传输的结束时间的属性，以及针对包含在所述服务内发送的文件的会话的会话调度元素，所述会话调度元素包括指示所述会话的结束时间的属性。<br>**判断结果**：未公开 | 对比文件描述了使用FLUTE协议进行多播内容分发，并提到了FDT（文件递送表）。例如，在说明书第[0039]段提到：“FLUTE protocol transmits the FDT from the content server in a multicast mode to all the kiosks.”。该FDT包含了关于在当前会话中必须传输的文件的信息（第[0058]段：“Indeed the FLUTE protocol defines a File Delivery Table noted FDT, which contains the information of the files which have to be transmitted in the current session.”）。 | **论述**：技术特征A限定了接收“服务通告”，该通告包含“广播调度描述”，该描述进一步包含具有“结束时间”属性的“文件调度元素”或“会话调度元素”。对比文件公开了通过多播传输的“FDT”（文件递送表），它列出了要传输的文件。然而，FDT的功能是提供文件列表及其相关属性（如大小、哈希），以便接收方确定应接收哪些文件。这与目标专利中的“调度描述”不同，目标专利的调度描述（特别是其中的文件调度元素和会话调度元素）专门用于指示文件或会话传输的“结束时间”，以便在特定时刻触发文件修复。对比文件的FDT并未被描述为包含指示文件或会话传输“结束时间”的属性。虽然FDT的传输可以看作是服务通告的一部分，但其内容和作用（列出文件属性以进行完整性检查）与目标专利中用于基于“结束时间”触发修复的“调度描述”在功能上存在本质区别。因此，本领域技术人员无法从对比文件中毫无疑义地得出技术特征A的方案，该特征未被直接公开。同时，对比文件也完全没有涉及基于文件或会话的“结束时间”属性来规划或触发任何操作，因此也无法通过合理推断得出该特征，故亦未隐含公开。 |
| **技术特征B**：以及响应于确定没有接收到感兴趣的文件并且在没有接收到与所述感兴趣的文件相关联的文件递送表(FDT)实例的情况下，在一时刻触发对所述感兴趣的文件的修复过程。<br>**判断结果**：未公开 | 对比文件描述了在文件接收失败时进行文件修复。例如，第[0058]段提到：“Each kiosk may then indicate to the index server the files that are missing. The server then indicates to the kiosk the address(es) of another kiosk(s) that owns the missing file(s).”。第[0042]段描述了在“multicast delivery status step”中，每个接收器向索引服务器报告接收到的文件。 | **论述**：技术特征B的核心在于“在没有接收到与所述感兴趣的文件相关联的文件递送表(FDT)实例的情况下”触发修复过程。对比文件明确描述了其文件修复机制依赖于FDT。在第[0058]段中，接收器（kiosk）使用FDT来确定哪些文件应该被传输，并进而确定哪些文件缺失。因此，对比文件公开的文件修复过程，其前提是接收器已经获得了FDT实例（或至少知道其内容），并基于此来确定缺失文件。这与技术特征B限定的“在没有接收到FDT实例的情况下”触发修复的条件完全相反。目标专利要解决的核心问题之一正是在UE错过文件广播且未获得FDT的情况下如何进行完整文件修复。对比文件完全没有教导或暗示在未接收到FDT实例时如何触发或执行文件修复。因此，该特征既未被直接公开，也未被隐含公开。 |
| **技术特征C**：其中，所述时刻对应于从针对所述服务的所述服务通告的所述广播调度描述的所述文件调度元素的所述属性得到的所述感兴趣的文件的传输的所述结束时间或者从针对所述服务的所述服务通告的所述广播调度描述的所述会话调度元素的所述属性得到的所述会话的所述结束时间。<br>**判断结果**：未公开 | 对比文件未提及基于文件或会话的“结束时间”属性来触发文件修复。其文件修复的触发是基于检测到文件缺失（例如，通过FDT比较或向服务器报告），如第[0058]段和第[0042]段所述。 | **论述**：技术特征C进一步限定了触发修复的“时刻”具体对应于从调度描述中获得的文件传输结束时间或会话结束时间。这体现了目标专利的核心构思：利用调度信息中预知的时间点来精确控制修复过程的启动时机。对比文件描述的文件修复机制中，修复的触发是基于事件（如检测到文件缺失、接收到服务器指示或收到其他接收器的请求），而非基于一个从调度信息中预先推导出的特定时间点。对比文件中没有任何内容提及“文件调度元素”、“会话调度元素”或其“结束时间”属性，更未提及利用这些时间信息来触发修复。因此，本领域技术人员无法从对比文件中得出该技术方案，该特征既未被直接公开，也未被隐含公开。 |
| **技术特征D**：还包括：至少部分地基于通过FDT定位符获得的FDT中包括的信息来确定在所述服务中发送了所述感兴趣的文件，所述FDT定位符包括在所述会话调度元素中。<br>**判断结果**：未公开 | 对比文件第[0058]段提到，FLUTE协议以多播模式从内容服务器向所有接收器传输FDT，接收器使用FDT来确定哪些文件应该被传输以及哪些文件已被接收。 | **论述**：技术特征D限定了通过包含在“会话调度元素”中的“FDT定位符”来获取FDT，并基于FDT信息确定感兴趣的文件。对比文件公开了FDT被多播传输，接收器使用FDT来确定文件信息。然而，对比文件完全没有提及“会话调度元素”这一概念，更没有提及FDT定位符（或URI）被包含在会话调度元素中。在对比文件中，FDT是作为独立的信息实体（一个文件）被传输的，其获取方式是多播接收，而非通过从一个调度描述元素中解析出的定位符去获取。因此，该特征的具体实现方式未被对比文件公开。 |
| **技术特征E**：还包括：至少部分地基于通过FDT定位符获得的FDT中包括的信息来确定在所述服务中发送了所述感兴趣的文件，所述FDT定位符是从所述感兴趣的文件的定位符中隐式确定的。<br>**判断结果**：未公开 | 对比文件未提及“隐式确定”FDT定位符的方法。其FDT是通过明确的多播传输（第[0058]段）或可能通过服务器指示获得的。 | **论述**：技术特征E涉及一种特定的FDT获取方式：从文件的定位符（如URI）中“隐式”推导出FDT的定位符。对比文件只描述了FDT被显式地传输或提供，没有任何段落、暗示或逻辑推理表明存在一种从文件URI隐式推导FDT URI的机制。因此，本领域技术人员无法从对比文件中推理出该技术方案，该特征未被隐含公开。 |
| **技术特征F**：还包括：至少部分地基于在更新的调度描述中包括的信息来确定在所述服务中发送了所述感兴趣的文件。<br>**判断结果**：未公开 | 对比文件未提及“更新的调度描述”这一概念。其文件列表信息主要来自初始传输的FDT。 | **论述**：技术特征F限定了使用“更新的调度描述”中的信息来确定感兴趣的文件。对比文件描述了使用FDT，但并未提及该FDT或任何调度描述存在“更新”的版本，并且通过该更新版本来确定文件信息。对比文件的修复过程依赖于当前会话的FDT，没有引入“更新”的调度描述作为信息来源。因此，该特征未被对比文件公开。 |
| **技术特征G**：其中，所述更新的调度描述是通过单播传输获得的。<br>**判断结果**：未公开 | 对比文件第[0058]段提到FDT是通过“multicast mode”传输的。对比文件未描述通过单播传输获得更新调度描述或FDT。 | **论述**：技术特征G进一步限定了“更新的调度描述”的获取方式为“通过单播传输获得”。对比文件明确记载FDT是通过多播（multicast）传输的（第[0058]段）。虽然对比文件在其他部分（如修复阶段）使用了单播连接进行文件传输，但并未将单播用于获取调度描述或FDT。因此，该特定的获取方式未被对比文件公开。 |
| **技术特征H**：还包括：至少部分地基于在所述会话调度元素中包括的信息来确定在所述服务中发送了所述感兴趣的文件。<br>**判断结果**：未公开 | 对比文件未提及“会话调度元素”这一概念。其会话信息可能隐含在FLUTE协议上下文中，但未明确描述包含可用来确定感兴趣文件的信息元素。 | **论述**：技术特征H限定了基于“会话调度元素中包括的信息”来确定感兴趣的文件。对比文件没有公开“会话调度元素”这一结构。虽然FLUTE协议涉及会话，但对比文件说明书并未提取或描述一个独立的、包含特定信息元素的“会话调度元素”实体用于确定文件兴趣。因此，该特征未被公开。 |
| **技术特征I**：还包括：至少部分地基于通过针对最新的MD5文件进行查询而接收的信息来确定在所述服务中发送了所述感兴趣的文件。<br>**判断结果**：未公开 | 对比文件未提及通过查询“最新的MD5文件”来确定文件信息或兴趣。FDT中可能包含文件的哈希信息（如MD5），但对比文件未描述主动查询最新MD5的过程。 | **论述**：技术特征I涉及一种主动查询机制：通过查询“最新的MD5文件”来获取信息以确定是否发送了感兴趣的文件。对比文件中，文件版本或完整性信息（如哈希）是包含在FDT中被动接收的。没有描述接收器主动向服务器或其他实体发起针对“最新MD5”的查询过程。因此，该特征未被对比文件公开。 |
| **技术特征J**：还包括：基于将所述文件的最新版本的标识符与先前下载的所述文件的版本的比较来确定在所述服务中发送了所述感兴趣的文件。<br>**判断结果**：未公开 | 对比文件第[0058]段提到，接收器可以知道哪些文件应该被传输（通过FDT）以及哪些文件已被接收，从而可以检测缺失文件。这隐含了版本或文件标识的比较。 | **论述**：技术特征J限定了通过比较文件“最新版本的标识符”与“先前下载的版本”来确定感兴趣的文件（即是否存在新版本）。对比文件第[0058]段描述接收器使用FDT来知道应接收的文件，并与实际接收的文件进行比较以检测“缺失”文件。这里的“缺失”可能由于传输错误导致文件完全未收到，也可能暗示版本不一致？然而，对比文件的重点在于修复当前会话中“丢失”的文件，以确保接收到会话计划传输的完整文件集。虽然其中包含了比较的思想，但并未明确指向用于识别“文件新版本”的“版本标识符”比较，其目的更侧重于传输完整性而非版本更新检测。尽管如此，考虑到隐含公开判断标准宽松，可以认为对比文件部分公开了“通过比较文件标识信息来确定是否需要文件”这一广义概念。但技术特征J明确限定了“最新版本的标识符”与“先前下载的版本的比较”，这更具体地指向版本控制场景。由于对比文件没有明确区分版本标识符（如MD5）用于版本新旧判断，而是用于文件完整性/同一性判断，因此不能认为直接公开了技术特征J。从宽松的隐含公开角度看，本领域技术人员有可能从“比较应接收文件列表与实际接收文件列表以确定缺失”这一操作，推理出“比较文件标识符（如FDT中的哈希）以确定是否需要获取该文件（可能是新版本）”。但这种推理得到的方案与目标专利中基于版本标识符比较来确定“感兴趣的文件”（新版本文件）的方案在作用上具有相似性。因此，**判断技术特征J被对比文件隐含公开**。 |
| **技术特征K**：其中，所述标识符包括MD5签名。<br>**判断结果**：隐含公开 | 对比文件未明确提及“MD5签名”。然而，FLUTE协议中FDT可以包含文件的哈希值（如MD5）用于校验。本领域技术人员公知，在FLUTE等文件分发协议中，FDT常用MD5作为文件完整性校验的标识符。 | **论述**：技术特征K限定了标识符具体为MD5签名。虽然对比文件说明书文本未明确写出“MD5”，但其引用的FLUTE协议（IETF RFC 3926）标准中，FDT通常包含MD5哈希值作为文件内容的标识符。本领域技术人员在阅读对比文件提及的FLUTE协议和FDT时，能够毫无疑义地理解FDT中用于标识/校验文件的标识符可以是MD5签名。因此，该特征可以被认为是对比文件所公开的FDT机制中固有或公知常识的一部分，从而被隐含公开。 |
| **技术特征L**：还包括：基于在与先前的会话期间广播的文件相关联的索引和与在当前会话期间广播的文件相关联的索引之间的比较来确定在所述服务中发送了所述感兴趣的文件。<br>**判断结果**：未公开 | 对比文件未提及使用“会话索引”来比较不同会话的内容以确定感兴趣的文件。其修复机制主要关注当前会话内的文件缺失。 | **论述**：技术特征L限定了通过比较不同会话的“索引”来确定是否发送了感兴趣的文件（例如，判断当前会话内容是否与之前相同）。对比文件的文件修复机制聚焦于修复“当前文件递送会话”中丢失的文件（第[0037]段）。它没有描述或暗示存在一种“会话索引”机制，用于唯一标识会话内容，并通过比较会话来判断内容是否更新。因此，本领域技术人员无法从对比文件中推理出该方案，该特征既未被直接公开，也未被隐含公开。 |
**结论**：根据以上分析，技术特征J被判断为**隐含公开**，技术特征K被判断为**隐含公开**。技术特征A、B、C、D、E、F、G、H、I、L均未被对比文件直接公开或隐含公开。
<<<j>>>
<<<k>>>