对比文件名称：2009-09-24_US2009240701A_发明申请_US20090240701A1 File repair method for a content distribution system
目标专利名称：使用EMBMS中的调度描述段的完整文件修复的方法、装置和介质CN105247840B
本次调用的模型名称：专利创造性评估模型
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：接收针对服务的服务通告，所述服务通告包括广播调度描述，所述广播调度描述包括以下至少一项：针对在所述服务内发送的文件的文件调度元素，所述文件调度元素包括指示所述文件的传输的结束时间的属性，以及针对包含在所述服务内发送的文件的会话的会话调度元素，所述会话调度元素包括指示所述会话的结束时间的属性。 <br> **判断结果：未公开** | [0046]段：“To trigger the download phase, an out of band signaling mechanism managed by the operator is used to announce the update of the content subset to the kiosks.” （为了触发下载阶段，使用由运营商管理的带外信令机制向信息亭宣布内容子集的更新。）<br>[0069]段：“FLUTE protocol transmits the FDT from the content server in a multicast mode to all the kiosks.” （FLUTE协议以多播模式从内容服务器向所有信息亭传输FDT。） | 对比文件公开了使用“带外信令机制”（out of band signaling mechanism）来宣布内容更新，这可以对应于目标专利中的“服务通告”。然而，对比文件描述的信令机制是基于DVB-IP标准中的服务发现机制（参见[0046]段），其具体内容未被详细说明。更重要的是，对比文件完全没有提及目标专利权利要求所定义的“广播调度描述”，也未提及其中包含的“文件调度元素”及其“指示文件的传输的结束时间的属性”（如`end`属性），或“会话调度元素”及其“指示会话的结束时间的属性”（如`stop`属性）。对比文件提到了FLUTE协议及其文件递送表（FDT），但FDT用于列出会话中要传输的文件及其属性（如MD5），并不等同于包含文件/会话结束时间属性的“调度元素”（参见目标专利说明书[0080]段图10、[0081]段图11）。因此，本领域技术人员不能从对比文件毫无疑义地得出或合理推断出技术特征A所限定的具体数据结构（广播调度描述及其包含特定属性的元素）。 |
| **技术特征B**：以及响应于确定没有接收到感兴趣的文件并且在没有接收到与所述感兴趣的文件相关联的文件递送表(FDT)实例的情况下，在一时刻触发对所述感兴趣的文件的修复过程。 <br> **判断结果：未公开** | [0069]段：“each kiosk knows exactly, the files which have to be transmitted in the session and the files which have been received. Each kiosk may then indicate to the index server the files that are missing.” （每个信息亭确切地知道会话中必须传输的文件以及已接收的文件。然后，每个信息亭可以向索引服务器指示缺失的文件。）<br>[0053]段：“During the ‘multicast delivery status step’ each kiosk reports to a centralized index server the received files.” （在‘多播递送状态步骤’期间，每个信息亭向集中式索引服务器报告已接收的文件。） | 对比文件确实公开了在确定未接收到文件（缺失文件）时触发文件修复过程（例如，向索引服务器报告或发起P2P请求，参见[0069]、[0053]段）。然而，目标专利的技术特征B明确限定了触发修复的**两个并列条件**：1) 确定没有接收到感兴趣的文件；**且** 2) **在没有接收到与所述感兴趣的文件相关联的FDT实例的情况下**。这是目标专利要解决的核心问题之一，即在未收到FDT时如何进行完整文件修复（参见目标专利说明书[0061]段）。对比文件中的文件修复机制，无论是集中式还是分布式，均依赖于FDT或类似列表来确定哪些文件缺失（参见[0069]段：“rely on the FLUTE protocol to determine the files that are missing”）。换言之，对比文件中的修复触发以**可获得FDT（或等效文件列表）为前提**，而目标专利的技术特征B恰恰是针对**无法获得FDT**这一特定场景。因此，对比文件未公开，也未隐含公开“在没有接收到FDT实例的情况下”触发修复这一限定条件。 |
| **技术特征C**：其中，所述时刻对应于从针对所述服务的所述服务通告的所述广播调度描述的所述文件调度元素的所述属性得到的所述感兴趣的文件的传输的所述结束时间或者从针对所述服务的所述服务通告的所述广播调度描述的所述会话调度元素的所述属性得到的所述会话的所述结束时间。 <br> **判断结果：未公开** | 未发现相关内容。 | 技术特征C限定了触发修复的“时刻”的具体来源，即从服务通告的广播调度描述中的文件调度元素的属性（如`end`）或会话调度元素的属性（如`stop`）得到文件或会话的结束时间（参见目标专利说明书[0080]段）。对比文件完全没有提及任何从“广播调度描述”中提取文件或会话“结束时间”属性作为修复触发时刻的概念。对比文件中修复的触发是基于“检测到缺失文件”这一事件（参见[0069]段），或者是在报告/请求步骤之后，而非基于一个从信令中解析出的、预定义的、与文件/会话传输结束相关联的特定时刻。因此，该技术特征未被对比文件公开或隐含公开。 |
| **技术特征D**：还包括：至少部分地基于通过FDT定位符获得的FDT中包括的信息来确定在所述服务中发送了所述感兴趣的文件，所述FDT定位符包括在所述会话调度元素中。 <br> **判断结果：隐含公开 (d)** | [0069]段：“FLUTE protocol transmits the FDT from the content server in a multicast mode to all the kiosks. ... each kiosk knows exactly, the files which have to be transmitted in the session and the files which have been received.” （FLUTE协议以多播模式从内容服务器向所有信息亭传输FDT。...每个信息亭确切地知道会话中必须传输的文件以及已接收的文件。） | 技术特征D描述了通过一个包含在“会话调度元素”中的“FDT定位符”来获取FDT，进而基于FDT信息确定文件是否在服务中发送。对比文件明确公开了在FLUTE协议中，FDT通过多播传输给所有接收端（信息亭），接收端通过检查接收到的FDT可以知道会话中应该传输哪些文件（即“在服务中发送”了哪些文件）（参见[0069]段）。虽然对比文件没有明确提及“FDT定位符”这一术语，也没有提及“会话调度元素”这一特定结构，但FLUTE协议中FDT的传输和获取是其标准操作的一部分。本领域技术人员可以理解，要获取FDT，必然需要某种方式定位或访问它。因此，可以合理推断出，存在一种机制（可广义理解为“定位符”）使得接收端能够获得FDT信息，并基于此判断文件是否被发送。尽管具体实现方式（定位符置于“会话调度元素”中）未被公开，但“基于FDT信息确定文件在服务中发送”这一核心思想已被对比文件公开。因此，该技术特征被判断为**隐含公开**。 |
| **技术特征E**：还包括：至少部分地基于通过FDT定位符获得的FDT中包括的信息来确定在所述服务中发送了所述感兴趣的文件，所述FDT定位符是从所述感兴趣的文件的定位符中隐式确定的。 <br> **判断结果：未公开** | 未发现相关内容。 | 技术特征E涉及一种特定的、隐式的FDT定位符确定方式，即从感兴趣文件本身的定位符（如URI）推导出FDT的位置（例如，相同目录下的“FDT”文件，参见目标专利说明书[0102]段）。对比文件仅提及FDT通过多播传输（[0069]段），或作为修复过程的一部分被使用，但完全没有描述或暗示任何从文件URI隐式推导FDT位置的方法或概念。本领域技术人员无法从对比文件的内容中进行此类推理。 |
| **技术特征F**：还包括：至少部分地基于在更新的调度描述中包括的信息来确定在所述服务中发送了所述感兴趣的文件。 <br> **判断结果：未公开** | 未发现相关内容。 | 技术特征F涉及通过“更新的调度描述”来确定文件发送。目标专利中，“更新的调度描述”特指通过单播等方式获取的、包含最新文件调度信息的调度描述段（参见说明书[0086]-[0087]段）。对比文件未提及任何“调度描述”的概念，更不用说“更新的调度描述”以及通过它来确定文件发送信息。对比文件中用于确定文件是否发送的信息主要来自多播传输的FDT（[0069]段）。 |
| **技术特征G**：其中，所述更新的调度描述是通过单播传输获得的。 <br> **判断结果：未公开** | 未发现相关内容。 | 技术特征G限定了技术特征F中“更新的调度描述”的获取方式为“单播传输”。由于对比文件未公开“更新的调度描述”这一概念，自然也未曾公开其通过单播传输获得。对比文件中FDT的传输方式明确为多播（[0069]段）。 |
| **技术特征H**：还包括：至少部分地基于在所述会话调度元素中包括的信息来确定在所述服务中发送了所述感兴趣的文件。 <br> **判断结果：未公开** | 未发现相关内容。 | 技术特征H限定基于“会话调度元素中包括的信息”来确定文件发送。对比文件未定义或描述“会话调度元素”这一数据结构。虽然对比文件提到了“会话”（session），但用于确定会话中发送了哪些文件的信息明确来自FDT（[0069]段），而非来自一个独立的“会话调度元素”。 |
| **技术特征I**：还包括：至少部分地基于通过针对最新的MD5文件进行查询而接收的信息来确定在所述服务中发送了所述感兴趣的文件。 <br> **判断结果：未公开** | 未发现相关内容。 | 技术特征I涉及通过向文件修复服务器查询最新的MD5信息来确定文件是否被发送及其版本（参见目标专利说明书[0106]-[0107]段）。对比文件虽然提到了MD5哈希可能作为FDT中文件的签名（参见背景技术和FLUTE协议常规），但完全没有描述任何主动向服务器“查询最新的MD5文件”以确定文件发送情况的机制。对比文件中版本或文件完整性的判断是基于本地已有的FDT。 |
| **技术特征J**：还包括：基于将所述文件的最新版本的标识符与先前下载的所述文件的版本的比较来确定在所述服务中发送了所述感兴趣的文件。 <br> **判断结果：隐含公开 (j)** | [0069]段：“each kiosk knows exactly, the files which have to be transmitted in the session and the files which have been received.” （每个信息亭确切地知道会话中必须传输的文件以及已接收的文件。） | 技术特征J的核心在于通过比较版本来确定是否有新文件（或文件新版本）在服务中发送。对比文件[0069]段指出，信息亭通过FDT知道“会话中必须传输的文件”和“已接收的文件”。要完成这一“知道”，隐含地需要将FDT中列出的文件标识（可包含版本信息，如MD5）与本地已存储的文件进行比较。如果FDT中列出了本地没有的或版本更新的文件，即可确定该文件在本次服务中被发送。尽管对比文件没有明确写出“比较版本标识符”这一步骤，但这是实现“知道必须传输的文件”这一功能的必然且合理的逻辑推理。因此，该技术特征被判断为**隐含公开**。 |
| **技术特征K**：其中，所述标识符包括MD5签名。 <br> **判断结果：隐含公开 (k)** | [0002]段（背景技术）提及FLUTE协议，而FLUTE协议中FDT通常使用MD5哈希作为文件内容完整性校验的标识符，这是本领域公知常识。在对比文件[0069]段依赖FLUTE协议FDT的上下文中，可以合理推断所述文件标识符包括MD5签名。 | 技术特征K限定技术特征J中的“标识符”包括MD5签名。对比文件的背景技术部分（[0002]段）提到了IETF RFC 3926定义的FLUTE协议。在本领域，FLUTE协议的FDT中常用MD5哈希作为文件的标识符和完整性校验手段。虽然对比文件说明书正文未明确提及MD5在FDT中的使用，但在其描述的、依赖FLUTE协议和FDT来确定缺失文件的场景下（[0069]段），本领域技术人员能够毫无困难地理解并推断出，用于比较的文件标识符很可能包含MD5签名。因此，该限定被判断为**隐含公开**。 |
| **技术特征L**：还包括：基于在与先前的会话期间广播的文件相关联的索引和与在当前会话期间广播的文件相关联的索引之间的比较来确定在所述服务中发送了所述感兴趣的文件。 <br> **判断结果：未公开** | 未发现相关内容。 | 技术特征L涉及使用“会话索引”进行比较来确定文件发送。目标专利中，会话索引用于唯一标识会话，若当前会话索引与先前成功接收文件的会话索引不同，则推断有新内容（参见说明书[0096]-[0097]段）。对比文件完全没有提及任何“会话索引”的概念，也未描述通过比较会话索引来判断文件发送情况的方法。对比文件中判断是否有新文件发送依赖于FDT内容。 |
<<<d>>><<<j>>><<<k>>>