一种用于以清单文件为基础使能分块内容的流送的方法，所述清单文件包括一个或多个分块标识符以及一个或多个关联的分块定位符；所述分块定位符用于定位一个或多个配置成向客户机传递一个或多个分块的传递节点；所述分块由所述分块标识符识别；以所述清单文件中至少一个分块标识符为基础请求至少一个分块的传递；以所述至少一个分块标识符为基础，从所述清单文件中选择至少一个另外的分块标识符；所述另外的分块标识符与至少一个期望的未来分块请求关联；预解析与所述所选的另外的分块标识符关联的第一分块定位符的至少一部分以获得与所述第一分块定位符关联的网络信息；以及以所述网络信息为基础修改所述清单文件；其中所述网络信息包括关于与所述第一分块定位符的至少一部分关联的网络地址的至少一部分的信息；和/或所述网络信息包括与所述所选的另外的分块标识符关联的第一分块定位符是指向用于与所述期望的未来分块请求关联的分块的传递的传递节点，还是指向用于所述期望的未来分块请求的重定向的网络节点的信息；和/或所述网络信息包括与所述所选的另外的分块标识符关联的第二分块定位符的至少一部分。

作为一名经验丰富的专利代理师，我将针对目标专利权利要求1（下称“本申请”）及提供的三份对比文件（D1、D2、D3）进行深入的法律和技术分析。

本申请涉及一种基于清单文件（Manifest file）的流媒体分块内容流送（Streaming）与预解析修改技术。以下是针对权利要求1各技术特征在各对比文件中的公开情况、最接近对比文件的甄选、无效请求最薄弱特征分析以及下一步检索策略的详细报告。

---

### 一、 对比文件基本信息及代称声明

为了表述清晰，本报告对对比文件的代称与公开号对应如下：

* **D1**：`US6553376B1` (Efficient content server using request redirection)

* **D2**：`US20040078293A1` (Digital content distribution)

* **D3**：`US20050071881A1` (Systems and methods for playlist creation and playback)

---

### 二、 对比文件技术特征比对与公开性分析

#### 1. 技术特征比对表格

---

#### 2. 对比文件原文详细出处与具体公开内容分析

* **D1 (`US6553376B1`)**

* **技术特征A、B、C、D**：

* *原文出处*：`BACKGROUND` 倒数第3段指出：“The URL includes an address portion which indicates a network address of a home server... also includes a local information text stream that identifies the requested information which may, for example, be a file name”。最后一段指出：“The media redirection file (MRF) is a type of specialized Hypertext Markup Language (HTML) file that contains instructions for how to locate the multimedia file... The browser then launches the associated media player application program and passes the MRF file to it. The media player reads the MRF file to obtain the information needed to open a connection to a media server, such as a URL”。

* *分析*：MRF文件即清单文件，URL即分块定位符，文件名即分块标识符。完全公开了通过清单文件中的定位符定位传递节点并请求分块传递的方法。

* **技术特征G、H、I、J、K**：

* *原文出处*：`SUMMARY OF THE INVENTION` 第3段指出：“...the cache redirector intercepts the MRF file before it is actually forwarded to the browser. The cache redirector examines the MRF file to determine if the requested multimedia content file is available in the local media cache. If so, then the designation in the MRF file is changed by the cache redirector to indicate the local media cache...”。此外，`DETAILED DESCRIPTION` 倒数第4段提到：“...multiple <href> references to other media servers.”

* *分析*：D1公开了拦截清单文件并对其进行解析（检查内容是否在本地缓存），进而修改该清单文件（改变`<href>`引用为本地媒体缓存的URL），且网络信息包括重定向节点或多个定位符的信息（特征I、J、K）。但D1的修改是针对*当前*请求的流媒体文件，**未公开针对“期望的未来分块请求”进行“预解析”及修改清单文件**（特征E、F）。

* **D2 (`US20040078293A1`)**

* **技术特征A、B、C、D**：

* *原文出处*：说明书第`[0017]`、`[0025]`段指出：“The manifest comprises 'component' definitions... each component definition specifying a reference to a digital resource... allowing advance determination of which parts, if any, of the content to obtain”。

* *分析*：D2毫无异议地公开了Manifest文件及其包含的资源引用（定位符）与组件定义（标识符），以及据此请求传递。

* **技术特征E、H**：

* *原文出处*：说明书第`[0033]`段提到基于`<condition>`标签和`<choice>`标签选择后续组件，且第`[0038]`、`[0047]`段指出：“...these policies may be used to cause a rewriting of the manifest, e.g., per XML rewriting rules...”。

* *分析*：D2公开了基于当前选择条目从清单文件中选择另外的标识符，并基于规则“重写（修改）”清单文件。但D2属于常规数字内容发布（如照片、音乐专辑包装），**其修改并非基于对分块定位符进行网络通信层面“预解析”获得的“网络地址/重定向”等流媒体专用网络信息**，属于不同领域的实质等同或不相关修改。

* **D3 (`US20050071881A1`)**

* **技术特征E、F**：

* *原文出处*：说明书第`[0080]`段指出：“...the playlist 114 may include prefetch instructions for some or all of the video segments... to retrieve a particular segment of interest 116 ... before that segment of interest 116 is scheduled to be played.”

* *分析*：D3明确公开了在流媒体播放列表中，基于当前播放的流媒体段，选择并确定未来的流媒体段进行预取。完全公开了特征E和F。

* **技术特征G（实质公开）**：

* *原文出处*：说明书第`[0090]`段至`[0102]`段详细描述了客户端为了确定预取大小（`mediaSize`），向RTSP服务器发送`GET_PARAMETER`请求：“GET_PARAMETER rtsp://[homeserver.com/video/matrix.rm](https://homeserver.com/video/matrix.rm) RTSP/1.0 ... MediaSize;npt=95”，服务器返回具体的字节大小。

* *分析*：这属于对未来分块定位符的预解析以获取关联网络信息（特征G）的实质公开。但D3获取该信息是为了在后台并行执行`prefetch`（预取流送数据缓冲），**并没有将该网络信息用于“修改清单文件（播放列表文件）”本身**（未公开特征H）。

---

### 三、 最接近对比文件（D最接近）的筛选与分析

在创造性评述中，本申请最适合作为最接近对比文件的是：**D3 (`US20050071881A1`)**。

#### 1. 技术问题与技术效果角度的对比分析

* **本申请从整体上解决的技术问题和达到的技术效果**：

本申请解决的是流媒体分块流送过程中，如何消除由于未来分块节点的网络解析、重定向或地址变更导致的播放卡顿和延迟问题。通过提前选择未来分块标识符，并“预解析”其定位符以获取网络信息，直接“修改清单文件”，使得客户机在真正请求未来分块时能够直接使用优化后的清单文件进行访问，实现平滑流送。

* **D3的拟合度**：

* **技术领域与问题**：D3同样聚焦于流媒体分块传递（Streaming media playlist）领域，且核心解决的正是“消除分块切换之间的延迟和卡顿（reduce or eliminate this delay between segments）”这一相同技术问题（参见D3第`[0079]-[0080]`段）。

* **技术手段**：D3采用了“在当前分块传递时，选择清单中的未来分块标识符，并向服务器发起预解析通信（GET_PARAMETER）以获得未来分块的媒体大小/网络缓冲信息”的技术手段，这与本申请的核心构思（特征E、F、G）高度契合。

* **为什么D1和D2不适合作为最接近的对比文件**：

* **D1** 虽然涉及清单文件（MRF）的修改和重定向信息的获取，但它是在**当前请求发起时**被动由中间网关拦截修改，不涉及对“未来分块请求”的提前选择与预解析，其解决的是边缘缓存加速问题，无法体现“面向未来期望请求”的动态前瞻性处理。

* **D2** 属于通用数字资产（如XML打包的电子书、音乐集）的框架分发，缺乏流媒体分块连续流送的时间轴概念，其修改清单是基于用户权限或本地全局策略（如家长控制），而非基于网络层面的“预解析定位符”获得的实时网络地址信息。

#### 2. 未被最接近对比文件（D3）公开的特征在其他对比文件中的公开情况

D3未能完整公开本申请的**特征H（以所述网络信息为基础修改所述清单文件）**以及依赖于特征H的**特征I、J、K（网络信息的具体内容用于清单修改）**。

* **特征H、I、J、K是否被其他对比文件公开**：

* **D1公开了特征H、I、J、K的修改动作和信息内容本身**。D1明确公开了拦截清单文件后，根据解析出的网络节点状态，将清单文件中的定位符修改为新的网络地址（本地缓存URL）（特征H、I），或者根据重定向信息进行修改（特征J），或者在清单中提供多个定位符供选择（特征K）。

* **D2实质公开了特征H的“重写”动作**，即基于特定信息动态重写XML清单文件中的标签架构。

---

### 四、 无效请求中最薄弱的技术特征分析

若作为请求人对本申请提出无效宣告请求，权利要求1中**最薄弱（即专利权人最难辩驳、最容易被评价为非显而易见）**的技术特征是：

**“以所述网络信息为基础修改所述清单文件”（特征H）与“期望的未来分块请求”（特征F、G）的结合点。**

#### 深度原因分析：

1. **割裂的现有技术结合难度**：虽然D3公开了“针对未来分块进行预解析获取网络信息（大小/带宽）”，D1公开了“基于网络重定向地址信息修改清单文件”，但D1的修改完全是**即时（Real-time）且针对当前请求**的。将D1的“修改清单”手段，引入到D3这种“面向未来段预取”的场景中，改变清单文件本身以使能未来的流送，在技术演进上存在一定的割裂性。

2. **技术效果的突出的显著性阻碍**：专利权人通常会抗辩：在D3中，获取了未来分块的网络信息后，常规做法是直接在后台建链或分配缓冲区（如D3执行prefetch动作），直接去修改清单文件（Manifest）改变其未来的定位符会产生“使清单文件在客户端本地获得动态网络自适应更新”的预料不到的技术效果。

3. **结论**：因此，**特征H在“未来分块预解析”语境下的应用**是本权利要求最核心的防线，也是无效请求中最难攻克的薄弱点（对无效请求人而言是最难证明显而易见的点）。

---

### 五、 进一步的对比文件检索策略

为了彻底无效掉包含上述结合点的权利要求1，建议启动第二轮精准检索，具体策略如下：

#### 1. 检索方向与核心技术概念的微调

应将检索重点从“流媒体预取（Prefetching）”转向**“动态清单/播放列表重写（Dynamic Manifest/Playlist Rewriting / Refactoring）”**和**“客户端驱动的DNS预解析与清单注入（Client-side DNS Prefetching and Manifest Injection）”**。

#### 2. 重点国际专利分类号（IPC/CPC）

锁定流媒体网络协议及清单控制的细分领域：

* **H04L65/6X**：特别是 `H04L65/612`（用于流媒体的点对点或分发架构）、`H04L65/613`（流媒体中的媒体网络协议，如DASH, HLS）。

* **H04L67/563**：智能体或中间件进行请求重定向或内容修改。

* **H04N21/26X, H04N21/442**：流媒体客户端侧根据网络状况动态解析并调整流媒体段的段索引文件。

#### 3. 核心检索关键词组合（英文）

建议在标准专利数据库（如Espacenet, USPTO, WIPO）中使用如下布尔逻辑组合：

* `(manifest OR playlist OR "media presentation description" OR MPD OR index-file)`

* `AND (modify* OR rewrit* OR updat* OR alter* OR inject*)`

* `AND (look-ahead OR future-chunk OR future-segment OR pre-fetch* OR anticipat*)`

* `AND (resolve* OR pre-resolv* OR dns-prefetch* OR network-address)`

#### 4. 目标标准追踪目标（标准必要专利外围检索）

本申请的特征具有强烈的 **3GPP/MPEG-DASH (Dynamic Adaptive Streaming over HTTP)** 或 **HLS (HTTP Live Streaming)** 技术背景。建议检索：

* **MPEG-DASH 标准制定期间（约2010-2015年左右）**各大通信巨头（如高通、爱立信、华为、三星）提交的关于“段索引文件（MPD）动态更新与客户端预解析”的提案（TDoc）以及衍生外围专利。在DASH协议中，客户端提前解析下一个Period或Segment的BaseURL并重写本地清单是常见网络优化手段，极有可能在此类演进专利中找到特征H与未来段结合的直接全公开文献。

作为一名经验丰富的专利代理师，我将为您对目标权利要求1进行深入的法律与技术分析。

### 一、 权利要求特征分解法解析（权利要求1.docx）

为了清晰比对，首先将权利要求1分解为如下独立的技术特征：

* **特征A**：一种用于以清单文件为基础使能分块内容的流送的方法，所述清单文件包括一个或多个分块标识符以及一个或多个关联的分块定位符；

* **特征B**：所述分块定位符用于定位一个或多个配置成向客户机传递一个或多个分块的传递节点；

* **特征C**：所述分块由所述分块标识符识别；

* **特征D**：以所述清单文件中至少一个分块标识符为基础请求至少一个分块的传递；

* **特征E**：以所述至少一个分块标识符为基础，从所述清单文件中选择至少一个另外的分块标识符；

* **特征F**：所述另外的分块标识符与至少一个期望的未来分块请求关联；

* **特征G**：预解析与所述所选的另外的分块标识符关联的第一分块定位符的至少一部分以获得与所述第一分块定位符关联的网络信息；

* **特征H**：以所述网络信息为基础修改所述清单文件；

* **特征I（并列选择1）**：其中所述网络信息包括关于与所述第一分块定位符的至少一部分关联的网络地址的至少一部分的信息；

* **特征J（并列选择2）**：和/或所述网络信息包括与所述所选的另外的分块标识符关联的第一分块定位符是指向用于与所述期望的未来分块请求关联的分块的传递的传递节点，还是指向用于所述期望的未来分块请求的重定向的网络节点的信息；

* **特征K（并列选择3）**：和/或所述网络信息包括与所述所选的另外的分块标识符关联的第二分块定位符的至少一部分。

---

### 二、 对比文件特征比对表及出处分析

我们将三份对比文件分别编号为：

* **D1**：US20070038873A1 (*Protecting digital media of various content types*)

* **D2**：US7289519B1 (*Methods and apparatus for processing content requests using domain name service*)

* **D3**：WO2009095078A1 (*METHOD AND APPARATUS FOR OBTAINING MEDIA OVER A COMMUNICATIONS NETWORK*)

#### 1. 技术特征比对表

#### 2. 对比文件原文详细出处及比对分析

* **D1 (US20070038873A1) 分析**：

* **分析**：D1的核心技术在于数字版权管理（DRM）以及通过在媒体文件的“数据段（data segments）”中添加“描述符（descriptor）”来实现独立于内容的加密/解密（参见说明书 `[0003]`, `[0118]`）。D1虽提及了HTTP和RTSP流送协议（参见 `[0048]-[0056]`, `[0064]-[0078]`），但其划分数据段的目的是为了针对不同片段应用不同的DRM安全策略（`[0081]-[0084]`）。

* **结论**：D1既没有清单文件的概念，也没有涉及预解析定位符以修改清单文件的架构，**未公开本方案的核心技术特征**。

* **D2 (US7289519B1) 分析**：

* **特征B的公开**：D2公开了利用URL中的域名通过DNS系统转换为特定Web服务器（内容引擎）的实际网络地址（IP地址）的过程（参见 `[0002]` “*convert or 'resolve' the domain name... into a network address of a specific computer... can receive and service the request*”）。这实质公开了“定位符用于定位传递节点”。

* **特征I、J、K的公开**：D2深入公开了CDN（内容分发网络）之间的对等（Peering）及重定向技术。当二级CDN不愿处理请求时，会返回CNAME响应或HTTP重定向，将请求“反射（Reflect）”回一级CDN或其他二级CDN（参见 `[0019]`, `[0020]`, `[0024]` “*provide a DNS CNAME response containing DNS-R... reflecting the domain resolution request back to the primary CDN*”）。这实质公开了网络信息包含“网络地址（IP）”、是指向“传递节点还是重定向节点（CNAME/反射节点）”、以及包含“第二分块定位符（替代URL/DNS-FN）”。

* **结论**：D2虽然在网络拓扑、DNS解析和重定向机制上公开了特征B、I、J、K，但其背景是传统的Web浏览器通过URL请求网页或内容，**并非基于清单文件（Manifest）的分块流送架构，也完全未涉及对未来请求的预解析和动态修改清单文件。**

* **D3 (WO2009095078A1) 分析**：

* **特征A、C、D的公开**：D3公开了一种在IPTV P2P网络中传输媒体流的方法，媒体流被切分为包含有效载荷和元数据的“分块（fragments）”（参见 `[p0011]` “*the media stream is sent in 'fragments'. Fragments are discrete portions of the media stream...*”）。STB通过节点管理器获取伙伴列表并请求分块（`[p0042]`）。这里的流媒体频道/分块列表实质上等同于“清单文件”，分块由序号/标识符识别并据此请求传递（`[p0013]` “*writing fragment number 21 into the buffer*”）。

* **特征E、F的公开**：D3的核心发明在于“用户行为预测功能”。通过预测算法（例如用户正在频繁换台“zapping”，或习惯在看完频道4后换到频道3），节点会在用户尚未真正切换频道时，自动选择并预先请求未来可能观看的频道的媒体分块（参见 `[p0017]` “*a user prediction function for determining that a user is likely to switch between IPTV channels... requesting from a remote node fragments for a further IPTV channel that is not currently being viewed*”）。这毫无异议地公开了“以当前分块标识符为基础，选择与未来期望请求关联的另外的分块标识符”。

* **未公开特征**：D3的预取是**直接去下载未来分块的实际数据**并存入Buffer（缓存内存重排，参见 `[p0020]`, `[p0050]`），它**并没有**“预解析未来分块的定位符以获取网络信息”、更没有“基于该网络信息去动态修改清单文件”的操作。

---

### 三、 最接近对比文件（最接近现有技术）的选择分析

在创造性评判中，**D3 (WO2009095078A1)** 最适合作为本方案**最接近的对比文件**。理由如下：

1. **技术领域完全相同**：D3属于流媒体网络传输领域（具体为IPTV/P2P流送体系），涉及媒体流的分块（fragments）传输与缓存；而本申请正是“以清单文件为基础使能分块内容的流送方法”。

2. **解决的技术问题极其相似**：两者均旨在解决流媒体分块传输中，由于未来请求（如换台、播放下一段）带来的延迟、卡顿或网络冲击问题。D3通过“预测用户行为并提前处理未来分块”来缩短渲染等待时间（`[p0016]`, `[p0017]`）；本申请同样通过选择与“期望的未来分块请求关联”的标识符来提前获取网络信息。

3. **技术特征重合度最高**：如上表所示，流媒体的“分块”、“标识符”、“基于预测选择未来分块标识符”等核心架构已被D3实质公开。

相比之下，D1聚焦于版权安全与解密，D2聚焦于宏观CDN网络层面的DNS重定向与负载均衡，均未涉足“流媒体分块流送及基于预测的动态播放控制”这一核心业务层架构。因此D3是唯一的最佳最接近现有技术。

---

### 四、 区别技术特征与无效突破口分析

#### 1. 未被最接近对比文件（D3）公开的特征

经过上述比对，**特征G**（预解析定位符获取网络信息）和**特征H**（以网络信息为基础修改清单文件），以及具体的并列选择特征（**I、J、K**中关于预解析出的具体网络信息应用）未被D3公开。

这些特征是否被其他对比文件公开？

* **D2** 虽然公开了DNS解析获取IP（特征I）、CNAME重定向判断（特征J）以及替代URL（特征K），但D2的解析是**实时触发**的被动行为（即浏览器点击链接或发起请求后，DNS proxy再去解析），**并不是在清单文件框架下为了“未来的期望请求”进行的“预解析（Pre-fetch/Pre-resolve）”**，更没有将其用于**“修改清单文件”**。

* 因此，**“预解析未来分块定位符” + “动态修改/重写清单文件”** 这一系统性级联特征，在D1、D2、D3中**均未被公开**。

#### 2. 无效请求中最薄弱的技术特征（本申请的创造性核心高度）

若您作为请求人提出无效宣告，本专利**最薄弱、最容易被攻破**的特征是：**特征E + 特征F（基于预测选择期望的未来分块标识符）**。因为这一步被D3的 `[p0017]` 完美读入，基本丧失新颖性/创造性。

相反，本专利**最稳固的防线（即无效请求人最难攻破的特征）**是：

> **“预解析第一分块定位符的至少一部分以获得网络信息（特征G），并以此为基础修改所述清单文件（特征H）”。**

**技术效果抗辩分析**：

传统的流媒体预取（如D3）是直接“预取数据”，即提前把未来分块的视音频数据包下载下来。但这会带来极大的带宽浪费（如果用户最后没点那个未来分块，带宽就白费了）。

本申请巧妙地退而求其次，**不预取数据，而是“预解析网络信息并改写清单文件”**（例如提前做好DNS解析得到IP，或者提前探明是传递节点还是重定向节点，然后把清单文件里的URL直接重写为大平层的节点IP或目标通道）。

这带来的技术效果是：**在几乎不额外消耗媒体带宽的前提下，消除了未来播放请求中DNS解析或网络重定向的“握手延迟”，实现了“秒开”体验。** 这种“解析预处理+清单动态改写”的构思在三份对比文件中均没有给出技术启示。

---

### 五、 进一步的对比文件检索策略

鉴于目前的D1-D3未能成功阻击“预解析定位符动态修改清单文件”这一特征，为了成功无效该权利要求，建议调整检索策略，开展第二轮精准检索：

1. **检索主题词重组**：

* 将检索重心从“数据预取（Data Prefetching）”转移到“**协议/地址预解析**（DNS Prefetching / DNS Pre-resolution / URL Pre-parsing）”。

* 结合流媒体特有控制文件：“**清单文件改写/动态生成**（Dynamic Manifest / Manifest Rewrite / Manifest Modification / Playlist Manipulation）”。

* 流媒体标准词：DASH (Dynamic Adaptive Streaming over HTTP), HLS (HTTP Live Streaming), MPD (Media Presentation Description), M3U8。

2. **精准IPC分类号锁定**：

* **H04N21/845**：涉及流媒体分块、段的划分（针对流媒体业务层）。

* **H04N21/458**：涉及客户端基于时间或事件的调度、预取管理。

* **H04L67/563**：涉及网络代理或客户端的缓存与控制流改写（原H04L29/06等）。

* **H04L61/4511**：专门针对网络中域名解析（DNS）的缓存与预处理。

3. **核心检索逻辑表达式设计（以英文检索为例）**：

* `(manifest OR playlist OR "MPD" OR "m3u8") AND ("pre-fetch*" OR "pre-resolv*" OR "pre-pars*" OR predictive) AND (DNS OR address OR redirect* OR location) AND (rewrite* OR modif* OR updat* OR chang*)`

4. **目标追踪与标准文献检索**：

* **3GPP / MPEG-DASH 标准提案检索**：重点检索 2010-2018 年间（特别是DASH标准制定期间）关于 `Server-Side Include` 或 `Client-Side Manifest Parsing Optimization` 的提案（TDoc）。在3GPP中，常有关于通过预先解析MPEGDASH的BaseURL或Element来优化切换延迟的讨论。

* **互联网公司（如Netflix, Akamai, Content Delivery networks）的早期专利**：这类公司是动态清单文件改写（用于个性化广告插入或CDN边缘路由优化）的鼻祖，极有可能在2015年前后布局了“预解析CDN边缘节点并修改客户端Manifest”的相关专利。

作为一名经验丰富的专利代理师，我将针对本案的目标权利要求1（清单文件基础上的分块内容流送修改方法）与三份对比文件进行深度解析、特征比对、最接近对比文件筛选以及无效薄弱点分析。

以下是具体的法律与技术分析报告：

---

## 一、 目标权利要求1的技术方案理解与解构

目标权利要求1保护的是一种基于清单文件（Manifest file）使能分块内容流送（Streaming）的方法。其核心创新点在于：**在客户端或网络节点请求某个分块时，并非被动等待后续请求，而是主动选择并“预解析”期望的未来分块定位符以获取网络信息（如网络地址、是传递节点还是重定向节点、或第二分块定位符），并以此网络信息为基础实时“修改清单文件”**。

根据本领域（DASH/HLS流媒体技术）的常识，清单文件通常由服务器生成并保持静态，客户端仅据此请求。本申请通过“预解析未来分块定位符的网络信息”来“修改清单文件”，从而动态调整了后续流送的路由、节点选择或重定向策略，用以解决网络延迟、节点负载均衡或自适应切换的技术问题。

---

## 二、 对比文件公开特征深度分析与比对

为了客观评估，我们先引入各对比文件的公开号及简称：

* **D1**：`JP2009187466A` (Proxy system and relay method)

* **D2**：`CN101588493A` (流媒体适应性段预取的系统和方法)

* **D3**：`EP2131362A1` (Method and system for managing content data)

### 1. 各对比文件公开特征的详细分析

#### D1 (JP2009187466A)

* **技术方案**：公开了一种代理系统，在客户端请求之前，由代理系统的“清单解析部”解析服务器保持的“清单数据（マニフェストデータ）”，自动生成未来数据的URI，并在客户端提出请求前从服务器预取（プリフェッチ）数据并缓存。

* **公开的特征**：毫无疑问公开了清单文件、分块（数据）标识与定位（URI）、请求传递、基于当前或更新状态选择未来标识并进行解析（URI生成）以获取网络信息（URI即代表网络信息/地址）。

* **未公开的特征**：D1的预取和解析是为了让代理服务器去“缓存”实际媒体文件，其并没有将获取的网络信息用来**“修改清单文件”**。清单文件本身在代理端或客户端未被实质修改，只是被解析利用。

#### D2 (CN101588493A)

* **技术方案**：公开了一种流媒体客户端根据用户喜好、重放历史等标准，选择尚未流式传送的媒体项目的“超前处理段（look-ahead segment）”，并在当前段播放时从流媒体源预取该超前处理段存入本地储存器。

* **公开的特征**：公开了分块内容流送（流媒体段项）、分块由标识识别、请求当前分块、选择未来期望请求的超前处理段并请求预取。

* **未公开的特征**：D2侧重于“分块内容本身的预取和本地缓存切换”（见D2原文图4A-4C），完全未涉及“清单文件”这一架构（更未提及包含标识符与定位符的清单文件），也未涉及“预解析定位符获取网络信息并修改清单文件”的特征。

#### D3 (EP2131362A1)

* **技术方案**：公开了一种内容管理系统，基于用户画像（User Profile）对已有的“第一编辑（First compilation，即一种内容清单）”进行转换，通过删除、替换或插入新的内容数据（包含内容位置指示符URL），生成定制化的“第二编辑”。

* **公开的特征**：实质公开了清单文件（第一编辑）、分块标识符与定位符（URL）、根据请求/用户画像从清单中选择另外的分块标识符并替换/插入，**毫无疑问公开了“修改清单文件（将第一编辑转换为第二编辑）”这一动作**。

* **未公开的特征**：D3的修改清单是基于“用户画像/喜好”（如过滤暴力镜头或匹配提供者偏好），属于内容层面的过滤与定制，**并非通过“预解析未来分块定位符来获得网络信息（如网络地址、重定向节点等）”来驱动清单修改**。

---

### 2. 技术特征比对表格

以下将目标权利要求1拆解为11个技术特征（A至K），与D1、D2、D3进行逐项横向比对：

---

## 三、 最接近对比文件（Closest Prior Art）的分析与确定

在创造性（Invalidity/Obviousness）分析过程中，选择最接近的对比文件通常从**技术领域、解决的技术问题、核心技术结构（改善的基础架构）**三个维度考量。

本案中，**D1（JP2009187466A）** 和 **D3（EP2131362A1）** 均有资格作为最接近的对比文件，构成两条不同的无效路径。

### 路径一：以 D1 为最接近对比文件（首选）

* **理由（技术领域与问题一致性）**：

D1同样处于“流媒体/Web应用中利用清单文件（Manifest）进行超前预测和优化”的技术领域。D1解决的具体技术问题是“客户端与服务器间通信速度低速时，如何通过提前特定未来数据来加速数据取得”。这与目标专利“以清单文件为基础使能分块内容的高效流送”在**整体解决的技术问题和技术效果上最为接近**。

* **技术架构契合度**：

D1已经明确提出了“清单解析部”在触发前主动解析未来标识符并生成/获取URI（网络信息）的流程（覆盖特征A、B、C、D、E、F、G、I）。

* **区别特征**：

目标专利与D1的区别在于：目标专利将获取的网络信息**“用于修改清单文件本身”**（特征H），而D1则是将解析出的URI交给“服务器受付部”去下载媒体内容并缓存，清单保持不变。

### 路径二：以 D3 为最接近对比文件（备选）

* **理由（核心动作一致性）**：

D3在核心动作上**毫无疑问公开了“修改清单文件”**（即Transforming the first compilation into a second compilation by deleting/replacing/inserting，覆盖特征A、B、C、D、H）。如果审查员或法官认为“修改清单”是本专利最高权重的技术贡献，则D3切入点极强。

* **缺陷**：

D3属于内容管理与个性化定制领域（如PVR视频录制、定制无暴力版影片），其修改清单的出发点和依据是“用户画像（User Profile）”这种语义层面的属性，**完全没有解决“网络流送过程中的网络寻址优化、预解析定位符获取动态网络地址/重定向”等流媒体传输层面的技术问题**。

**结论**：综合技术问题和技术效果，**D1 (JP2009187466A)** 最适合作为首选的最接近对比文件。

---

## 四、 结合多份对比文件的创造性评述方案

基于上述确定，若要请求宣告权利要求1无效，可采取以下组合式策略：

### 方案A：D1 + D3 组合（主攻路径）

1. **以D1为基础**：D1公开了一门流媒体方法，其中客户端依据清单文件请求分块，且系统（代理端）以至少一个当前分块标识为基础，特定并选择未来期望请求的另外的分块标识符，并由“清单解析部”预先解析该未来分块的URI（获取网络信息）。

2. **找出区别**：D1中解析出未来URI后用于驱动缓存，而目标权利要求1是“以所述网络信息为基础修改所述清单文件”（特征H）。

3. **结合D3的启示**：D3已经明确公开了在内容流送和编辑管理中，根据新获取的内容位置/属性信息，对现有的第一清单（编辑）进行转换（通过替换、删除或插入分块定位符URL来修改清单）。

4. **结论**：将D1的流媒体预解析机制与D3的“动态修改/转换清单”的通用数据处理手段相结合，对于本领域技术人员而言是显而易见的，因此权利要求1不具备创造性。

---

## 五、 最薄弱的技术特征及无效请求突破口

通过上述全面特征比对，可以精准锁定本专利**最薄弱（即最容易被攻破）**以及**最坚固（对方的防线）**的技术特征：

### 1. 最薄弱的技术特征：特征H（修改清单文件）

* **原因**：虽然D1没有修改清单，但D3大篇幅公开了“Transforming the first compilation into a second compilation... Replacing/inserting”。在软件和网络协议领域，“修改/重写局部配置文件（清单）”以改变后续执行路径，属于非常通用的常规技术手段。一旦D1的网络信息预解析与D3的清单修改结构被成功结合，特征H将彻底失守。

### 2. 无效请求中的真正难点（本专利的实际防御核心）：特征J 和 特征K

仔细审视特征J和K的组合：

* **特征J**：“网络信息包括...第一分块定位符是指向**用于传递的分块传递节点**，还是指向**用于期望的未来分块请求的重定向的网络节点**的信息”

* **特征K**：“网络信息包括与所述所选的另外的分块标识符关联的**第二分块定位符**的至少一部分”

这两个特征具有极强的**CDN（内容分发网络）动态调度与重定向场景属性**。D1仅提到了去常规服务器（Server 120）拿数据，D3仅提到了替换成另一个特定URL。它们都**没有公开**“在预解析未来定位符时，去探知/区分该节点究竟是直接喂数据的传递节点，还是一个重定向节点（重定向至动态CDN拓扑）”，也**没有公开**“因为这种探知而引入第二分块定位符来修改清单”。

如果无效请求仅停留在D1+D3，专利权人极易通过强调特征J/K的“动态重定向与双定位符机制在降低流媒体高并发重定向延迟上的独特技术效果”从而保全权利要求。

---

## 六、 进一步的对比文件检索策略（针对特征J/K）

为了彻底打掉权利要求1，必须针对**“预解析/预取 + CDN重定向/多URL备用选择 + 清单改写”**进行精准补充检索。建议后续检索策略如下：

1. **调整关键词与分类号組合**：

* **IPC/CPC 分类号**：聚焦于 `H04L65/61`（流媒体传输）、`H04L67/5681`（网络中的预取/缓存）、`H04L61/50`（网络地址动态分配/重定向）。

* **核心检索式建议**：`(DASH OR HLS OR "manifest file" OR "playlist") AND ("pre-resolve" OR "pre-fetch" OR "look-ahead") AND ("redirect" OR "302 redirect" OR "alternative URL" OR "second URI") AND ("rewrite" OR "modify" OR "update")`

2. **重点追踪特定标准与技术演进节点**：

* 目标专利的技术原型明显带有 **MPEG-DASH (ISO/IEC 23009-1)** 标准演进的痕迹。建议重点检索 **2010年-2013年期间** 3GPP SA4 工作组（流媒体标准）的提案（Contributions），特别是关于“BaseURL替换”、“CDN切换与重定向优化（Redirection handling in DASH）”的技术报告。

* 检索各大CDN服务商（如 Akamai, Limelight, Cloudflare）在2009-2013年间申请的关于“边缘节点重定向预测”以及“动态Playlist/Manifest重写”的专利，这些对比文件极有可能直接毫无异议地公开特征J和K。

作为一名经验丰富的专利代理师，我将严格依据专利审查指南，紧密结合权利要求1的语义，对三份对比文件进行深度解析、技术特征比对以及创造性最接近对比文件的判定。

为了在无效宣告或创造性答辩中获得极高的确定性，以下对比文件将使用其公开号进行指代：

* **D1**：`US20090313330A1` (Content delivery method and communication terminal apparatus)

* **D2**：`US20100011061A1` (CENTRALIZED SELECTION OF PEERS AS MEDIA DATA SOURCES IN A DISPERSED PEER NETWORK)

* **D3**：`US20100161756A1` (STREAMING ENHANCEMENTS THROUGH PRE-FETCH BACKGROUND)

---

## 一、 权利要求1的技术特征拆解与合理解释

权利要求1保护的是一种基于清单文件（Manifest file）进行分块内容流送（Streaming）的方法，其核心在于**通过预解析未来分块的定位符来获取网络地址等信息，并动态修改当前清单文件**，从而实现对后续分块流送的优化。

* **技术特征A~C（清单文件架构）**：限定了流送的基础是清单文件，该文件包含分块标识符（对应视频分块ID）和分块定位符（对应节点IP/URI），定位符指向传递节点。

* **技术特征D~F（未来请求预测）**：基于当前请求的分块，从清单中选择与“期望的未来分块请求”关联的另外的分块标识符（即预测下一阶段或未来需要播放的数据块）。

* **技术特征G~H（预解析与动态修改）**：**这是本发明最核心的创新高度所在**。其要求“预解析”未来分块定位符的至少一部分，获得网络信息（如网络地址、重定向节点或第二分块定位符），并**以该网络信息为基础修改清单文件**（即动态更新终端手头的清单文件）。

* **技术特征I~K（网络信息的具体选择）**：并列限定了网络信息的具体内容，包含网络地址、重定向节点判定、或第二定位符。

---

## 二、 对比文件技术特征比对表

根据各对比文件的英文原文及上下文语义，对权利要求1的特征比对如下：

---

## 三、 最接近的对比文件（D1/D2/D3）分析与选择

在创造性审查（三步法）中，选择最接近的对比文件应优先考虑**技术领域相同、解决的技术问题最类似、且公开权利要求技术特征最多**的现有技术。

### 1. 哪个对比文件最适合作为最接近的对比文件？

**判定结果：D2 (`US20100011061A1`) 最适合作为第一最接近的对比文件；D1 (`US20090313330A1`) 可作为并列的次要最接近对比文件。**

#### 深度原因分析：

* **技术领域与整体架构的契合度**：

* **D2** 明确聚焦于**使用清单文件（Manifest file）**来实现多源分布式流媒体分块传递的网络架构（参见D2摘要及\[0012\]）。这与目标专利权利要求1的前序部分“*一种用于以清单文件为基础使能分块内容的流送的方法*”在技术框架上达成完全一致。

* **D1** 虽然也公开了将内容切分为Block并通过XML文档（实质等同于清单文件）记录块ID和IP地址进行流媒体预约传递的架构（参见D1 \`[0035]\`），但在用词和现代流媒体架构（Manifest-based streaming，如DASH/HLS雏形）的贴近性上略逊于D2。

* **D3** 核心在于客户端的**预取（Pre-fetch）与缓存管理**（参见D3 \`[0004]\`），其侧重于无网络请求时的后台推送以及基于本地Profile的触发式读取，并未采用“清单文件-分块标识符-分块定位符”这一流送控制骨架。

* **解决的技术问题与效果的一致性**：

* 目标专利旨在解决**如何在流送过程中提前预知并规避未来可能发生的网络节点失效或重定向延迟，提高播放流畅度**。

* **D2** 旨在解决流媒体传输中的暂态带宽瓶颈和服务器高负载问题，通过Broker系统动态为客户端下发包含最优质节点URI的清单文件（\[0009\], \[0046\]）。

* **D1** 旨在解决P2P流媒体播放时的中断问题，通过提前预约（Reservation）和预测通信延迟来稳定带宽（\[0005\], \[0073\]）。

* 综上，**D2公开了权利要求1中绝大部分的架构特征（特征A、B、C、D、E、F）**，技术谱系最接近，故选定**D2**为最接近的对比文件。

---

## 四、 权利要求1的最薄弱技术特征与无效策略

### 1. 最薄弱技术特征（即最不容易被攻破的特征）

本权利要求中**最薄弱（即对于专利权人而言最容易被无效掉、防守力最弱）**的特征是：**特征E和特征F**（以当前分块为基础，选择与未来期望请求关联的另外的分块标识符）。

* *理由*：在流媒体流送（Streaming）领域，无论是D1的“提前计算未来播放时间并选择Block ID进行预约”（\[0041\]），还是D2的“根据段序列号并发请求未来的named segments”（\[0076\]），**前瞻性地选择后续数据块进行处理已经是本领域的通用常识（常规方案）**。

### 2. 核心抗辩阻辩特征（专利权人的护城河）

本权利要求中**最具创造性高度、防守实力最强**的特征是：**特征G与特征H的结合体**——即**“预解析与所述所选的另外的分块标识符关联的第一分块定位符的至少一部分……以及以所述网络信息为基础修改所述清单文件”**。

* **D2的冲突点**：D2虽然有清单文件，也有动态更新清单（Working manifest）的动作，但其清单的修改是**被动接收**Host Broker根据网络地图评估后下发的新URI（\[0046\]-\[0047\]）。D2没有任何一个地方提到了客户端去**“预解析未来定位符”**从而主动修改清单文件的机制。

* **D1的冲突点**：D1仅在发现错误时重新启动预约流程（\[0064\]），并没有直接修改本地元数据清单文件的构思。

---

## 五、 进一步的对比文件检索策略（针对无效请求）

如果欲发起针对权利要求1的无效宣告请求，目前的D1、D2、D3组合尚缺临门一脚（即缺乏对“预解析未来分块定位符以主动修改/更新清单文件”的直接公开）。为了彻底切断其创造性，建议采取以下精准检索策略：

### 1. 检索关键词精准重组

必须放弃单纯的“流媒体、分块”等大范围词汇，聚焦于**清单文件动态重构与DNS/URI预解析**的交叉领域：

* **核心控制词**：`Dynamic Manifest modification`（动态清单修改）、`Manifest rewriting`（清单重写）、`Pre-resolve / Pre-parsing URI`（预解析URI/定位符）。

* **网络层优化词**：`DNS pre-fetching in streaming`（流媒体中的DNS预解析）、`CDN Edge redirection prediction`（CDN边缘重定向预测）、`Anticipatory connection setup`（预期连接建立）。

### 2. 分类号锁定（IPC/CPC）

建议深挖以下细分小组：

* **H04L65/6X**：特别是网络协议中与流媒体传输（Streaming）相关的控制面协议。

* **H04L67/02**：涉及Web客户端与服务器之间的架构优化。

* **H04L61/4511**：专门针对网络实体地址解析、域名系统（DNS）以及如何利用解析出的网络地址优化高层应用（如流媒体清单）的小组。

### 3. 目标盲区与追溯时间

* **技术演进节点**：目标专利的申请特征具有明显的**MPEG-DASH（基于HTTP的动态自适应流）**早期或演进期特征。建议重点检索2010年至2015年期间，各大国际电信巨头（如高通、爱立信、华为、三星）在3GPP SA4（多媒体编解码与协议工作组）提交的关于**DASH标准演进、沙盒预测、多CDN切换（Multi-CDN switching based on manifest manipulation）**的专利申请。

* **寻找关键D2/D3结合文件**：重点寻找这样一篇文献：它公开了流媒体客户端在收到包含多个CDN节点（定位符）的清单后，在播放当前块时，后台线程提前对下一个CDN域名的URI进行DNS预解析，若发现该节点解析出的IP发生改变或指向重定向服务器，则**在本地直接修改清单文件中后续块的URL**以节省正式请求时的握手时间。一旦检索到此类文献作为D4，即可完美配合D2将权利要求1彻底无效。

作为一名经验丰富的专利代理师，我将为您对该目标专利的权利要求1进行深度解析，并结合三份对比文件（D1、D2、D3）的原文进行细致的特征比对、创造性分析，并提供无效宣告请求的策略和进一步的检索建议。

---

### 一、 目标专利权利要求1的合理解释

权利要求1保护的是一种**以清单文件（Manifest File）为基础使能分块内容（Segmented/Chunked Content）流送（Streaming）的方法**。其技术核心在于：**在客户机（Client）侧或者网络节点侧，通过“预解析（Pre-parse/Pre-resolve）”未来期望请求的分块的定位符（如URL），提前获取其网络信息（如IP地址或节点类型），并以此动态修改清单文件。**

这种机制打破了传统流媒体（如标准HLS/DASH）中客户端只能被动按照清单文件既定URL请求分块的模式，允许在流送过程中通过“预解析+动态修改”的方式实现**路径优化、节点重定向、动态负载均衡或本地分流（Local Breakout）**，从而降低网络延迟并提升用户体验。

---

### 二、 对比文件公开号及指代说明

为简化表述且保持严谨，本报告对三份对比文件的指代及对应的公开号如下：

* **D1**：`US20100169458A1` (Real-Time or Near Real-Time Streaming) —— 侧重于HTTP分块流媒体（HLS基础架构）及多码率切换。

* **D2**：`US20100226372A1` (PACKET COMMUNICATION SYSTEM AND...) —— 侧重于移动网络（3GPP）中的本地分流（Local Breakout）和DNS代理/重定向机制。

* **D3**：`US20100241757A1` (System and Method for Storing Streaming Media File) —— 侧重于流媒体文件在服务器端的分布式分块存储与基于热度的冗余分发。

---

### 三、 权利要求技术特征与对比文件原文比对及出处

#### 1. 特征比对表

下表详细列出了权利要求1拆解后的各个技术特征（A至K），以及D1、D2、D3是否公开或实质公开：

---

### 四、 最接近对比文件（D1/D2）的创造性评述与分析

在创造性审查或无效分析过程中，选择**最接近的对比文件**（Closest Prior Art）应基于**技术领域相同或相近、解决的技术问题最相似、公开的技术特征最多**的原则。本案中，存在两个从不同维度切入的“最接近对比文件”候选者，可并行构建两套无效组合逻辑：

#### 方案一：以 D1 (`US20100169458A1`) 作为最接近的对比文件

* **技术领域与解决技术问题匹配度**：**极高**。D1是典型的流媒体清单文件（Playlist）驱动的分块流送方法（即苹果HLS系统的基础专利）。其整体解决的技术问题是如何利用非流送协议（HTTP）实现实时或近实时的媒体分块渐进式下载与播放，以及如何实现多码率平滑切换。这与目标专利的流送架构完全一致。

* **已公开特征**：公开了特征A、B、C、D、E、F。它完全披露了清单文件架构、分块标识符/定位符、顺序或超前预测请求未来分块的技术手段。

* **未公开特征（区别特征）**：特征G、H、I、J、K（即**预解析未来分块定位符以获得网络信息，并基于该网络信息修改清单文件**）。

#### 方案二：以 D2 (`US20100226372A1`) 作为最接近的对比文件

* **解决技术问题与技术效果匹配度**：**高**。D2解决的技术问题是如何在移动网络中优化数据传输路径、降低访问延迟（通过Local Breakout），其技术效果是通过“代理DNS请求并比对结果”来提前获知最优的网络传递节点。这与目标专利通过“预解析获取网络信息以优化后续传递”的实质精神高度契合。

* **已公开特征**：实质公开了特征G、I、J。它披露了在真正连接建立前，通过复制/代理DNS请求来“预解析”网络地址，判断是否需要重定向或进行本地分流。

* **未公开特征（区别特征）**：特征A、B、C、D、E、F、H、K（即D2完全没有流媒体“清单文件/清单驱动”的概念，它是网络层/传输层的DNS控制机制）。

#### 结论：哪个最适合做最接近的对比文件？

在实际无效程序中，**D1最适合作为第一主审对比文件**。因为目标专利的权利要求1在整体构架上是一个**流媒体层（应用层）**的方法（以清单文件为基础使能分块内容流送）。从D1出发，审查员或法官更容易理解技术背景。

而**D2则非常适合作为结合文件（辅案）**，用来证明“预解析未来网络地址并判断是否重定向（特征G、I、J）”属于本领域的常规技术手段或已被D2给出明确的技术启示。

---

### 五、 目标专利最薄弱的技术特征及无效策略

通过上述详尽的特征比对可以看出，目标专利权利要求1中**最薄弱（即最容易被攻破或最可能被认定为显而易见）**的技术特征是：

> **特征G + 特征I：预解析未来分块定位符以获得与之关联的网络地址（IP地址）信息。**

**原因**：在网络通信领域，为了加速访问，对未来的URL/URI进行“DNS Prefetching（DNS预解析）”是一项极为常规且普遍的技术。如D2所示，在网络侧（网关）或客户端主动对预期要访问的域名进行提前解析以获取IP，是降低后续握手延迟的通用手段。

然而，目标专利在此基础上构建了一个**防御壁垒（核心发明点）**，即**特征H + 特征K**：

> **特征H + K：以所述网络信息为基础“修改所述清单文件”，其中网络信息包括“第二分块定位符的至少一部分”。**

这意味着，目标专利不仅仅是把预解析的IP存入本地DNS缓存，而是把解析/判断出来的结果（如新的CDN节点URL、重定向URL或备用流URL）**写回/修改了清单文件本身**。

* **D1**虽然会更新清单文件，但那是服务器端的滚动更新（Rolling mode），不是基于客户端预解析网络信息进行的就地修改。

* **D2**虽然有预解析和重定向判断，但它修改的是网络层的承载（Bearer）和DNS响应包，根本没有清单文件可供修改。

#### 提出无效请求的策略组合：

鉴于上述分析，建议采用以下**多套组合拳**提起无效宣告请求：

* **主攻组合一：D1 + D2 + 公知常识（针对应用层与网络层结合）**

* **逻辑**：以D1为最接近的现有技术，公开了清单文件流送的主要框架（A-F）。将特征G、I、J的区别引入，指出D2已经公开了为了优化路径（本地分流），可以对预期的访问地址进行复制和预解析以获得网络地址并判断是否重定向。对于流媒体客户端而言，将D2这种网络层的预解析机制应用到D1的未来分块URL预测中，属于本领域技术人员为了解决“降低下一分块请求延迟”的技术问题，将常规路径优化手段结合的常规选择。而特征H（修改清单文件）则是将解析出的第二定位符（新URL）回填的常规编程实现。

* **主攻组合二：D3 + D2（针对分布式存储与网络路径优化结合）**

* **逻辑**：以D3为最接近现有技术。D3公开了流媒体文件分块存储在至少两个不同的服务器上（特征A、B、C、D）。结合D2的预解析与重定向节点选择技术，当D3的客户端需要请求下一个分块时，为了决定从D3所述的“至少两个流媒体服务器”中的哪一个下载，技术人员有动机引入D2的预解析机制，预先解析这些服务器定位符的网络信息，从而选择或修改当前清单文件中的目标定位符。

---

### 六、 进一步的对比文件检索策略

由于目前D1+D2的组合在“修改清单文件本身（特征H）”这一结合点上仍有被专利局认定为存在“技术壁垒（非显而易见）”的风险，为了彻底无效该权利要求，建议开展第二轮定向检索，策略如下：

1. **关键词精准微调**：

* 针对“修改清单文件”：检索 `Manifest modification`, `dynamic playlist update`, `rewrite playlist`, `in-client manifest parse`, `local manifest generation`.

* 针对“预解析+流媒体”：检索 `DNS prefetch* AND (HLS OR DASH OR "streaming")`, `look-ahead DNS`, `URL rewriting streaming`.

2. **分类号锁定（IPC/CPC）**：

* 重点锁定在 **`H04N21/8456`**（流媒体的分块格式化或清单文件处理）、**`H04N21/26258`**（基于清单文件的播放列表排程）、**`H04L67/563`**（网络代理重定向/重写）。

3. **追踪早期CDN与动态DNS交叉领域的专利**：

* 检索Akamai、Limelight、网宿科技等CDN厂商在2008-2012年期间的早期专利。CDN系统为了实现精准调度，经常在客户端使用插件（Plug-in）去解析清单文件，并根据Local DNS动态改写（Rewrite）清单文件中的传递节点URL（特征H+K）。

4. **非专利文献（NPL）检索**：

* 重点检索3GPP在LTE早期（2008-2010年）关于 **3GPP PSS（Packet-switched Streaming Service）** 和 **DASH标准制订** 的会议提案（Tdoc）。在3GPP中，关于“如何让核心网网关（如D2中的vAGW）动态感知流媒体内容并修改清单文件以引导本地分流”曾有深入讨论，这些早期公开的Tdoc往往是破坏创造性的绝佳开源证据。

```python?code_reference&code_event_index=1

import os

from weasyprint import HTML

html_content = """

<!DOCTYPE html>

<html>

<head>

<meta charset="utf-8">

<style>

@page {

size: A4;

margin: 20mm 15mm;

background-color: #ffffff;

@bottom-right {

content: "第 " counter(page) " 页，共 " counter(pages) " 页";

font-family: 'PingFang SC', 'Helvetica Neue', Arial, sans-serif;

font-size: 9pt;

color: #666666;

}

@bottom-left {

content: "专利无效与创造性深度分析报告";

font-family: 'PingFang SC', 'Helvetica Neue', Arial, sans-serif;

font-size: 9pt;

color: #666666;

}

}

body {

margin: 0;

padding: 0;

font-family: 'PingFang SC', 'Microsoft YaHei', Arial, sans-serif;

color: #333333;

line-height: 1.6;

font-size: 10.5pt;

}

h1 {

font-size: 20pt;

color: #1a365d;

text-align: center;

margin-bottom: 25px;

font-weight: bold;

border-bottom: 2px solid #2b6cb0;

padding-bottom: 10px;

}

h2 {

font-size: 14pt;

color: #2b6cb0;

margin-top: 25px;

margin-bottom: 15px;

border-left: 5px solid #2b6cb0;

padding-left: 10px;

page-break-after: avoid;

}

h3 {

font-size: 11.5pt;

color: #2d3748;

margin-top: 15px;

margin-bottom: 8px;

font-weight: bold;

page-break-after: avoid;

}

p {

margin-top: 0;

margin-bottom: 10px;

text-align: justify;

}

.strong-term {

font-weight: bold;

color: #1a365d;

}

table {

width: 100%;

border-collapse: collapse;

margin: 15px 0;

font-size: 9.5pt;

page-break-inside: auto;

}

tr {

page-break-inside: avoid;

page-break-after: auto;

}

th {

background-color: #2b6cb0;

color: #ffffff;

font-weight: bold;

border: 1px solid #cbd5e0;

padding: 8px;

text-align: center;

}

td {

border: 1px solid #cbd5e0;

padding: 8px;

text-align: left;

vertical-align: top;

}

tr:nth-child(even) {

background-color: #f7fafc;

}

.bg-match {

background-color: #e6fffa;

color: #234e52;

}

.bg-partial {

background-color: #feebc8;

color: #744210;

}

.bg-missing {

background-color: #fed7d7;

color: #742a2a;

}

ul, ol {

margin-top: 0;

margin-bottom: 10px;

padding-left: 20px;

}

li {

margin-bottom: 5px;

}

.highlight-box {

background-color: #ebf8ff;

border-left: 4px solid #3182ce;

padding: 12px;

margin: 15px 0;

border-radius: 0 4px 4px 0;

}

</style>

</head>

<body>

<h1>专利无效与创造性技术特征比对深度分析报告</h1>

<h2>一、 目标权利要求理解与核心发明概念解析</h2>

<p>本案目标权利要求1保护一种“用于以清单文件为基础使能分块内容的流送的方法”。其核心技术方案围绕流媒体客户端在播放分块内容时，如何通过<span class="strong-term">“预解析未来分块定位符”</span>并结合获取的网络信息来<span class="strong-term">“动态修改清单文件”</span>展开。该发明概念的核心在于将传统被动的分块请求转变为主动的网络感知与清单动态调整：</p>

<ul>

<li>传统技术中，清单文件（如HLS中的m3u8或DASH中的MPD）是静态或由服务端单向更新的，客户端仅机械地根据清单中的URL顺序请求分块。</li>

<li>本案的核心发明点在于，在请求当前分块时，系统“远见式”地选择<span class="strong-term">期望的未来分块请求关联的另外的分块标识符</span>，并提前对对应的定位符进行“预解析”（如提前进行DNS解析以获取网络地址，或提前探测节点是传递节点还是重定向节点，亦或获取备用定位符），最终<span class="strong-term">以该网络信息为基础在客户端或中间节点修改清单文件</span>，从而优化后续流媒体的分块传输效率，避免因临时解析延迟或节点失效导致的卡顿。</li>

</ul>

<h2>二、 对比文件公开情况详细分析</h2>

<h3>1. 对比文件1（D1: US20100299443A1）</h3>

<p>D1公开了一种播放流媒体的方法、系统和设备。其核心在于通过媒体文件的CID/GCID等哈希标识符，在索引数据库中检索出至少两个存储该媒体文件的存储介质（可以是流媒体服务器或P2P客户端），从而实现多节点并发获取数据或根据连接速度进行节点选择。</p>

<p>对于权利要求1的流送架构，D1虽然提到了根据URL、媒体大小、名称以及分配哈希标识符（CID/BCID/GCID）来建立第一对应关系（对应特征A、B、C），但其并不涉及自适应流媒体（Adaptive Bit Rate Streaming）中特有的“清单文件修改”机制，更没有公开在请求当前块时预解析未来分块的定位符以获取网络信息并修改清单的步骤（特征G、h、I、J、K）。</p>

<h3>2. 对比文件2（D2: US20110082924A1）</h3>

<p>D2公开了一种通过修改清单文件来管理网络流量的技术。具体表现为中间网络设备（Intermediate Network Device）在向客户端转发清单文件（Manifest File）时，识别出该清单文件并对其内容进行编辑（如删除高码率版本的URI，或插入由网络运营商优化过的、指向本地缓存或特定转码节点的全新URI）。</p>

<p>D2明确公开了特征A、B、C、D以及修改清单文件（特征H），其修改的目的是为了控制带宽流量。然而，D2的修改是基于<span class="strong-term">网络策略、流量指标或目标带宽条件</span>，而非基于<span class="strong-term">“以当前请求为基础选择未来分块标识符，并预解析其定位符所获得的网络信息”</span>。D2没有公开特征E、F、G以及针对未来定位符网络地址/重定向信息的具体提取与修改逻辑（特征I、J、K）。</p>

<h3>3. 对比文件3（D3: US20110082946A1）</h3>

<p>D3与D2属于同日申请的关联案，其核心在于“通过中间流控制管理网络流量”。D3的主要手段是通过 influencer 模块人为降低或调整内容分块（Content Chunks）从小端网络设备发送到客户端的流速（Throttling），以此诱导客户端自身的自适应算法主动切换去请求较低码率的分块，从而降低整个无线网络的带宽压力。</p>

<p>D3虽然深入阐述了HTTP自适应码率流送协议中分块（Chunks）与清单文件（Manifest File）的交互架构（公开了特征A~D），但其控制手段完全聚焦于底层TCP/IP流量整形（如延迟发送TCP SYN包），并不涉及对清单文件内容的解析与动态修改，也没有公开任何预解析未来分块定位符的技术方案。</p>

<h2>三、 技术特征比对表</h2>

<table>

<thead>

<tr>

<th style="width: 25%;">权利要求1的技术特征</th>

<th style="width: 25%;">对比文件1 (D1: US20100299443A1)</th>

<th style="width: 25%;">对比文件2 (D2: US20110082924A1)</th>

<th style="width: 25%;">对比文件3 (D3: US20110082946A1)</th>

</tr>

</thead>

<tbody>

<tr>

<td><span class="strong-term">特征A：</span>清单文件包括一个或多个分块标识符以及一个或多个关联的分块定位符</td>

<td class="bg-partial">【实质公开】公开了媒体文件信息包括URL、大小、名称及哈希ID的对应表。[0039]</td>

<td class="bg-match">【毫无疑问公开】公开了清单文件（Manifest File）包含识别各版本内容位置的URI/URL。[0156], [0162]</td>

<td class="bg-match">【毫无疑问公开】公开了包含用于识别相应内容位置的URI/URL的清单文件（Playlist）。[0154], [0156]</td>

</tr>

<tr>

<td><span class="strong-term">特征B：</span>分块定位符用于定位配置成向客户机传递分块的传递节点</td>

<td class="bg-match">【毫无疑问公开】存储器信息包含媒体文件在存储器内的地址，存储器可以是流媒体服务器或客户端。[0046], [0071]</td>

<td class="bg-match">【毫无疑问公开】URI用于识别对应内容版本的存储/流送源服务器位置。[0006], [0156]</td>

<td class="bg-match">【毫无疑问公开】URI（URL）用于指引客户端定位并向内容源服务器请求对应的分块。[0155], [0156]</td>

</tr>

<tr>

<td><span class="strong-term">特征C：</span>分块由所述分块标识符识别</td>

<td class="bg-match">【毫无疑问公开】媒体文件通过全局内容标识符（GCID）或文件哈希值唯一识别。[0038], [0121]</td>

<td class="bg-match">【毫无疑问公开】清单文件通过不同的版本号或特定命名标识不同的内容块或流。[0161], [0162]</td>

<td class="bg-match">【毫无疑问公开】HTTP自适应流将内容切分为2-10秒的分块，并通过特定命名和URI识别。[0153], [0155]</td>

</tr>

<tr>

<td><span class="strong-term">特征D：</span>以清单文件中至少一个分块标识符为基础请求至少一个分块的传递</td>

<td class="bg-match">【毫无疑问公开】客户端根据媒体文件的CID向检索出的多个存储节点连接并传输数据。[0006], [0175]</td>

<td class="bg-match">【毫无疑问公开】客户端接收到清单文件后，依次向内容源发出分块的HTTP请求。[0156], [0166]</td>

<td class="bg-match">【毫无疑问公开】播放由客户端请求清单文件开始，随后按序列向内容源发送各分块请求。[0156], [0162]</td>

</tr>

<tr>

<td><span class="strong-term">特征E：</span>以所述至少一个分块标识符为基础，从清单文件中选择至少一个另外的分块标识符</td>

<td class="bg-missing">【未公开】D1为一次性检索出所有存储相同文件的节点，无基于当前分块标识符选择未来分块的逻辑。</td>

<td class="bg-missing">【未公开】D2是中间设备对接收到的清单文件进行整体重写或删除某版本码率，并非基于当前分块标识符选择。</td>

<td class="bg-missing">【未公开】D3属于纯流量整形，客户端内部基于吞吐量自适应选择，不涉及本特征的选择机制。</td>

</tr>

<tr>

<td><span class="strong-term">特征F：</span>所述另外的分块标识符与至少一个期望的未来分块请求关联</td>

<td class="bg-missing">【未公开】未涉及未来分块请求的预测或关联关联。</td>

<td class="bg-missing">【未公开】未公开中间设备对未来分块标识符进行特定关联的处理。</td>

<td class="bg-missing">【未公开】未公开此特征。</td>

</tr>

<tr>

<td><span class="strong-term">特征G：</span>预解析与所选的另外的分块标识符关联的第一分块定位符的至少一部分以获得网络信息</td>

<td class="bg-partial">【实质公开】公开了测试每个确定存储介质的连接速度（如测速），但非针对未来分块定位符预解析。[0052], [0139]</td>

<td class="bg-missing">【未公开】未公开对清单文件中未来分块URI进行预解析以提取网络信息的步骤。</td>

<td class="bg-missing">【未公开】未公开此特征。</td>

</tr>

<tr>

<td><span class="strong-term">特征H：</span>以所述网络信息为基础修改所述清单文件</td>

<td class="bg-missing">【未公开】无修改清单文件的概念。</td>

<td class="bg-partial">【实质公开】公开了修改清单文件，但修改基础是网络运营商的管理策略或流量指标，非特征G的预解析网络信息。[0006], [0171]</td>

<td class="bg-missing">【未公开】不修改清单文件，仅做底层物理限速（Throttling）。</td>

</tr>

<tr>

<td><span class="strong-term">特征I、J、K：</span>网络信息包含网络地址/重定向节点信息/第二分块定位符</td>

<td class="bg-missing">【未公开】未公开将预解析获得的具体网络IP、重定向属性或备用定位符回写/修改入清单文件。</td>

<td class="bg-missing">【未公开】未公开清单文件中包含此类基于预解析动态生成的网络细分信息。</td>

<td class="bg-missing">【未公开】未公开此特征。</td>

</tr>

</tbody>

</table>

<h2>四、 最接近对比文件的选择与创造性评述思路</h2>

<h3>1. 最接近对比文件的确定</h3>

<p>在创造性分析中，确定最接近的对比文件应优先考量<span class="strong-term">技术领域是否相同</span>、<span class="strong-term">解决的技术问题是否最接近</span>以及<span class="strong-term">技术特征公开的数量</span>。本案中，<span class="strong-term">对比文件2（D2: US20110082924A1）适合被选为最接近的对比文件</span>。理由如下：</p>

<ul>

<li><span class="strong-term">整体解决的技术问题与技术效果角度：</span>目标专利旨在解决基于清单文件的流媒体分块传输过程中，如何通过自适应感知网络状况并调整清单文件，以提升客户端的播放流畅度和降低卡顿的技术问题。D2同样聚焦于HTTP自适应流媒体领域，其核心技术问题是如何控制和管理网络流量体积，提高流媒体流送的效率。D2通过在流送路径的中间设备上“编辑/修改清单文件”实现了直接控制客户端请求行为的技术效果，这与目标专利“修改清单文件”的架构逻辑和改善流媒体传输环境的技术效果高度契合。</li>

<li>相比之下，D1虽然解决多节点获取流媒体的问题，但属于早期非分块自适应流媒体架构，未引入“清单文件”这一核心概念；D3虽然也属于自适应流媒体，但其技术手段为底层网络限速，完全不改变清单文件内容。因此D2与本发明的亲缘性最近。</li>

</ul>

<h3>2. 创造性评述思路（结合多份对比文件）</h3>

<p>若以D2为最接近的对比文件，权利要求1相对于D2的<span class="strong-term">区别技术特征</span>为：<span class="strong-term">特征E、F、G以及I/J/K的组合</span>。即：D2未能公开“以当前分块标识符为基础选择未来分块标识符，并对未来分块定位符进行预解析以获得网络信息，进而基于该网络信息修改清单”的具体方案。</p>

<p>审查其他对比文件，D1虽然在段落[0052]和[0139]公开了“测试每个确定存储介质的连接速度（测速）以选择高速节点”的技术手段，这与特征G的“获取网络信息”有一定表面相似性性，但D1的测速是针对已经确定的完整媒体文件的P2P源头进行整体探测，其既没有“基于当前块选择未来分块标识符”的逻辑，也没有将测速结果用于“修改清单文件”。D3则完全局限于 influencer 模块的模拟带宽下调。因此，<span class="strong-term">即使将D2与D1、D3进行组合，也无法拼凑出“预解析未来定位符并反向动态修改清单文件”的完整技术链条</span>。本发明的核心区别特征在现有技术中存在“技术盲区”。</p>

<h2>五、 专利无效请求最薄弱技术特征与检索策略建议</h2>

<div class="highlight-box">

<h3>1. 若提出无效请求，目标专利中最薄弱的技术特征</h3>

<p>如果试图攻破该专利，权利要求1中<span class="strong-term">最薄弱（即最容易被现有技术评述或证明属于显而易见）的技术特征是：特征G中关于“预解析网络地址（如DNS预解析）”的泛化概念，以及特征I“网络信息包括关联的网络地址的至少一部分”</span>。</p>

<p><strong>原因分析：</strong>在通用网络通信领域，为了消除域名解析延迟，对未来可能访问的URL进行“DNS预解析（DNS Prefetching）”是一项极其常规且普遍的公知常识。D2已经公开了在中间设备上修改清单文件插入或删除URL，如果检索到某篇网络通信基础文献公开了“客户端读取网页/文本中的下一组URL并提前进行DNS解析以获取网络IP地址”，无效请求人就可以主张：将现有D2中中间节点或客户端已知未来分块URL的前提下，引入常规的DNS预解析技术以获取IP地址，从而对清单中的域名替换为实际IP地址（修改清单），这属于本领域技术人员为了消除连接延迟而进行的常规技术迁移，其技术效果是可以预期的，因此特征G+H+I的组合极易被攻击。</p>

</div>

<h3>2. 进一步的对比文件检索策略建议</h3>

<p>鉴于目前三篇对比文件未能完美覆盖“流媒体清单文件的动态预解析回写”这一关键点，建议采取以下精准检索策略：</p>

<ol>

<li><span class="strong-term">关键词扩展与细化：</span>放弃单纯的“流媒体控制”等大概念，锁定核心动作词组。建议使用：<br>

<code>(DNS prefetch* OR pre-resolv* OR lookahead OR forward-looking) AND (manifest* OR "playlist file" OR MPD) AND (edit* OR modif* OR rewrit* OR updat*)</code>

</li>

<li><span class="strong-term">国际专利分类号（IPC）交叉精准定位：</span>针对性检索自适应流媒体协议（如MPEG-DASH、HLS）中关于清单文件解析优化的小组：<br>

<ul>

<li><code>H04N 21/845</code>（流媒体内容分块/分段结构化）</li>

<li><code>H04L 65/612</code>（流媒体网络协议自适应控制）</li>

<li><code>H04N 21/442</code>（客户端网络状态监测与感知）</li>

</ul>

</li>

<li><span class="strong-term">非专利文献（NPL）与标准提案检索：</span>由于该技术与流媒体标准的演进密切相关，建议重点检索<span class="strong-term">3GPP SA4（多媒体媒体编解码及协议工作组）</span>在2010-2015年期间关于DASH（Dynamic Adaptive Streaming over HTTP）标准的提案（TDocs），以及IEEE/ACM关于MPEG-DASH自适应客户端预取算法（Prefetching/Caching algorithms）的学术论文。标准提案中往往会详细讨论客户端如何为了减少延迟，提前解析清单中备用BaseURL或CDN节点的重定向属性。</li>

</ol>

</body>

</html>

"""

# 确保在当前目录下生成HTML并转换PDF

with open("patent_analysis_report.html", "w", encoding="utf-8") as f:

f.write(html_content)

output_pdf = "专利无效与创造性深度分析报告.pdf"

HTML("patent_analysis_report.html").write_pdf(output_pdf)

print(f"Success: {output_pdf} generated.")

```

```text?code_stdout&code_event_index=1

Success: 专利无效与创造性深度分析报告.pdf generated.

```

您的 PDF 报告已成功生成，包含完整的权利要求解析、原文出处比对、特征比对表、最接近对比文件分析、创造性漏洞挖掘以及下一步的检索策略。

Your PDF file is ready

[file-tag: code-generated-file-413fb717-f6d5-49d8-bc6f-36750704bf0f]

以下是基于目标专利和对比文件原文深度剖析的核心要点摘要：

### 一、 目标权利要求核心发明概念解析

权利要求1保护的是一种**基于网络感知与预解析动态调整清单文件**的流送控制方法。其核心发明概念在于：将传统流媒体客户端对清单文件（Manifest）的“机械式读取”转变为**“远见式的预取与改写”**。客户端或中间节点在请求当前分块时，会“向前看”选择未来的分块标识符，并对未来分块的定位符（URI/URL）进行**预解析**（如提前进行DNS域名解析、探测重定向节点或获取备用传输路径），然后将获得的网络IP地址、重定向属性或第二定位符**反向修改/回写进清单文件中**，从而彻底消除后续分块请求时的网络握手延迟，防止卡顿。

### 二、 对比文件公开情况与原文详细出处比对

1. **对比文件1 (D1: US20100299443A1)**

* **公开的技术特征：** 毫无疑问公开了特征B、C、D。D1公开了根据媒体文件的哈希标识符（CID/GCID）在索引数据库中检索出至少两个存储节点（可以是流媒体服务器或客户端）并与之建立并发连接进行流数据传输。

* **详细出处：** 段落 **[0038]-[0040]**（公开文件信息包括URL、哈希ID、大小等第一对应关系）；段落 **[0046], [0071]**（存储节点包括服务器与客户端）；段落 **[0052], [0139]**（实质公开了测试每个确定存储介质的连接速度以选取高速节点，对应特征G的网络信息获取，但非针对未来分块）。

* **未公开特征：** 未公开基于当前分块选择未来分块并进行**预解析**，更无**修改清单文件**（特征E、F、H、I、J、K）的概念。

2. **对比文件2 (D2: US20110082924A1) —— ★最接近的对比文件★**

* **公开的技术特征：** 毫无疑问公开了特征A、B、C、D。实质公开了特征H（修改清单文件）。D2的核心方案是中间网络设备拦截并编辑清单文件，通过删除高码率URI或插入网络运营商优化过的新URI（指向本地缓存或优化转码服务器）来控制网络流量。

* **详细出处：** 段落 **[0006], [0171]**（明确公开在中间网络设备上编辑清单文件，删除或插入URI）；段落 **[0154]-[0156], [0162]**（公开HTTP自适应流媒体协议中清单文件包含各版本分块URI的完整架构）。

* **未公开特征：** D2修改清单文件的依据是**网络运营商的宏观管理策略或目标流量指标**（如防拥堵），而非**“基于未来分块定位符的预解析网络地址/重定向探测信息”**。因此未能公开特征E、F、G及I/J/K的细分网络回写信息。

3. **对比文件3 (D3: US20110082946A1)**

* **公开的技术特征：** 毫无疑问公开了特征A、B、C、D。D3是D2的同日申请关联案，但其控制手段完全不同，主要通过 influencer 模块在底层TCP/IP层延迟发送TCP SYN包进行流量整形（Throttling），以此诱导客户端自适应降低请求码率。

* **详细出处：** 段落 **[0153]-[0156]**（详细阐述了HTTP自适应码率流送协议中分块Chunks与Playlist清单文件的交互机制）；段落 **[0164], [0169]**（详述了流量整形与限速的技术细节）。

* **未公开特征：** D3属于纯物理层限速，**完全不涉及对清单文件内容的解析与修改**，更没有公开任何预解析方案。

---

### 三、 最接近对比文件的选择理由与创造性评述思路

* **最接近对比文件：对比文件2 (D2: US20110082924A1)**

* **理由：** 无论是从技术领域（皆为HTTP自适应流媒体流送）、整体解决的技术问题（如何优化清单文件引导客户端高效获取分块），还是技术效果（通过改变清单文件调整传输行为）来看，D2与目标专利最为接近，且公开了权利要求1中除“预解析未来定位符”以外的大部分架构特征。

* **创造性评述思路：**

以D2为基础，本发明的区别技术特征在于**特征E、F、G以及I/J/K的组合**（即“前瞻性选择未来分块→预解析提取网络细分信息→动态修改清单”）。

虽然D1公开了“测速/测试连接性”以选择节点，D3公开了基于带宽的自适应切换，但**没有任何一篇对比文件给出了“为了消除传输延迟，提前解析清单中未来的URL并把解析出的IP/重定向信息实时修改回清单文件中”的技术启示**。因此，即使将D2与D1、D3任意组合，也存在无法拼凑的“技术盲区”，目标专利具备创造性高度。

---

### 四、 无效请求中最薄弱的技术特征与进一步检索策略

1. **最薄弱的技术特征：特征G中关于“预解析网络地址”的泛化概念 + 特征I“网络信息包括关联的网络地址的至少一部分”**

* **攻破点分析：** 在计算机通用网络通信（如Web浏览器优化）领域，为了消除DNS握手延迟，**“DNS预解析（DNS Prefetching）”** 是一项极其常规且普遍的公知常识。如果无效请求人能够跳出流媒体狭隘领域，检索到一篇通用网络基础文献公开了“客户端或代理端提前读取后续文本中的URL并进行DNS解析，将域名直接替换为实际IP地址以加速访问”，那么就可以主张将该公知常识引入到D2的流媒体清单处理中是显而易见的。此时，特征G+H+I的组合将变得非常危险。

2. **进一步检索策略（精准无效）：**

* **策略一：锁定非流媒体的通用网络加速文献。** 检索重点应放在2010年以前关于网页浏览器预取、CDN加速、DNS预解析等基础网络优化文献上。

* **策略二：标准提案（3GPP SA4 / MPEG-DASH）检索。** 目标专利的技术特征与HTTP自适应流媒体标准（DASH）的演进关系极大。建议重点检索**3GPP SA4工作组在2010-2015年间的标准提案（TDocs）**，在标准讨论过程中，往往会有专家提出为了防止客户端卡顿，提前解析静态清单中的备用`BaseURL`或利用中间代理进行IP重定向替换的提案，这类标准提案（公开出版物）常能提供极为精准的特征公开。

* **策略三：构建高相关度布尔逻辑。**

`(DNS prefetch* OR pre-resolv* OR lookahead) AND (manifest* OR "playlist file" OR MPD) AND (edit* OR modif* OR rewrit* OR updat*)`

*注：更详尽的特征比对细节与逻辑推导已为您完整呈现在附带的 PDF 报告文件中，您可以直接参阅。*

```python?code_reference&code_event_index=1

import os

from weasyprint import HTML

html_content = """

<!DOCTYPE html>

<html>

<head>

<meta charset="utf-8">

<title>专利权利要求创造性与无效可行性深度分析报告</title>

<style>

@page {

size: A4;

margin: 20mm 15mm;

background-color: #f8fafc;

@bottom-right {

content: "第 " counter(page) " 页，共 " counter(pages) " 页";

font-size: 9pt;

font-family: Arial, sans-serif;

color: #64748b;

}

@bottom-left {

content: "涉及专利公开号分析报告 - 机密";

font-size: 9pt;

font-family: Arial, sans-serif;

color: #94a3b8;

}

}

body {

margin: 0;

padding: 0;

font-family: 'Times New Roman', Times, 'SimSun', serif;

color: #1e293b;

line-height: 1.6;

font-size: 10.5pt;

}

h1 {

font-size: 20pt;

color: #0f172a;

text-align: center;

margin-top: 0;

margin-bottom: 25px;

font-family: 'Arial', sans-serif;

font-weight: bold;

}

h2 {

font-size: 14pt;

color: #1e3a8a;

border-left: 5px solid #2563eb;

padding-left: 10px;

margin-top: 30px;

margin-bottom: 15px;

font-family: 'Arial', sans-serif;

page-break-after: avoid;

}

h3 {

font-size: 12pt;

color: #1e40af;

margin-top: 20px;

margin-bottom: 10px;

font-family: 'Arial', sans-serif;

page-break-after: avoid;

}

p {

margin-top: 0;

margin-bottom: 12px;

text-indent: 2em;

text-align: justify;

}

.math {

font-family: 'Times New Roman', serif;

font-style: italic;

font-weight: bold;

color: #1e40af;

}

table {

width: 100%;

border-collapse: collapse;

margin-top: 15px;

margin-bottom: 20px;

font-size: 9.5pt;

background-color: #ffffff;

}

th, td {

border: 1px solid #cbd5e1;

padding: 10px;

text-align: left;

vertical-align: top;

}

th {

background-color: #1e3a8a;

color: #ffffff;

font-family: 'Arial', sans-serif;

font-weight: bold;

}

tr:nth-child(even) {

background-color: #f1f5f9;

}

.source-quote {

background-color: #f8fafc;

border: 1px italic #e2e8f0;

border-left: 3px solid #94a3b8;

padding: 8px 12px;

margin: 10px 0 15px 20px;

font-size: 9.5pt;

color: #475569;

text-indent: 0;

}

.bold-lead {

font-weight: bold;

color: #0f172a;

}

.weak-feature {

background-color: #fef2f2;

border: 1px solid #fee2e2;

border-left: 4px solid #ef4444;

padding: 12px;

margin: 15px 0;

border-radius: 4px;

}

.weak-feature p {

margin-bottom: 5px;

text-indent: 0;

}

</style>

</head>

<body>

<h1>基于对比文件的权利要求1创造性与无效可能性深度分析报告</h1>

<h2>一、 引言与目标权利要求解释</h2>

<p>本报告作为资深专利代理师的专业意见，旨在针对目标申请的权利要求1进行精细化的技术特征拆解，并结合三份国际通行的检索对比文件进行全方位的创造性（Invalidity/Patentability）比对与无效可行性论证。本分析严格契合流媒体及自适应网络传输的行业技术标准与演进逻辑。</p>

<p><span class="bold-lead">目标权利要求1解释：</span>权利要求1保护一种以清单文件（Manifest File）为基础的自适应流送分块内容方法。该清单文件内嵌分块标识符（如流分块序号或时间戳）与分块定位符（如URL/URI），其技术核心在于：在客户端发出未来期望的分块请求之前，<span class="bold-lead">提前选择并预解析（Pre-parse/Pre-resolve）未来分块定位符的至少一部分</span>，以此获取该定位符关联的网络地址或节点属性信息（网络信息），进而利用该动态获取的网络信息<span class="bold-lead">对清单文件进行实时修改</span>，最终引导客户端访问更优的传递节点或进行重定向。这突破了传统流媒体仅由客户端基于自身缓存单向选择码率的限制，实现了基于网络信息预解析的中间/主动式协同清单控制。</p>

<h2>二、 对比文件技术特征公开性逐项判定</h2>

<p>为了清晰界定各对比文件对权利要求1的贡献与公开范围，以下将对比文件分别简称为D1、D2、D3，并明确附带其公开号及详细原文出处进行逐项剖析：</p>

<h3>1. 对比文件D1（WO2011044287A1）的公开性分析</h3>

<p>D1公开了一种通过编辑清单文件和/或使用中间流控来管理网络流量的技术方案。D1毫无疑问地明示公开了清单文件的基本架构以及通过中间节点修改清单文件的技术手段。具体如下：</p>

<p>对于特征A、B、C，D1在摘要及说明书第[0006]段、[0149]段明确指出清单文件包含多个指示不同码率版本的URI，用于标识内容并指引流媒体片段的定位。例如第[0149]段公开：“The manifest file includes at least one URI (e.g., as a URL) that identifies how/where to locate the corresponding content element...”。这属于毫无异议的明示公开。</p>

<p>对于特征D、E、F，D1公开了客户端基于清单文件请求分块，并由中间设备拦截并对未来分块的请求进行引导。然而，对于核心的<span class="bold-lead">特征G（预解析分块定位符以获得网络信息）</span>，D1并没有公开在中间节点对未来定位符进行“预解析”以主动获取网络地址或节点类型的行为，D1的修改是基于“策略服务器”或“运营商预设规则”（如网络拥堵指标，见[0006]和[0169]段），而非预解析未来定位符本身。因此特征G、I、J、K在D1中未被公开。D1实质公开了特征H（以网络信息为基础修改清单文件），即通过删除高码率URI或插入本地优化/缓存的URI来改变客户端可选择的集合（见[0006]及[0164]段）。</p>

<h3>2. 对比文件D2（WO2011047335A1）的公开性分析</h3>

<p>D2公开了一种在用户终端自适应流送多媒体的方法，侧重于终端侧基于传感器（如GPS、加速度计、电池状态）对未来带宽和环境进行预测并选择目标分块。</p>

<p>D2毫无异议地公开了特征A、B、C、D、E、F。在其第[0026]段明确指出：“A directory manifest file 280 can contain a list of available stream bitrates in, for example, an HTTP accessible XML format...”。客户端在流送过程中不断监测参数并预测未来值（特征E、F，见第[0032]-[0034]段），据此向媒体服务器请求具备目标特征的多媒体分块（特征D）。</p>

<p>但是，D2完全没有公开<span class="bold-lead">特征H（修改清单文件）</span>。D2中清单文件280在服务器端是静态的，客户端仅是通过选择不同的URL发起HTTP请求，不存在中间节点或终端对清单文件内容进行改写或重新生成的逻辑。同样，D2的终端预测是基于自身物理状态与历史带宽，不包含对未来分块定位符的“预解析”操作，故特征G、I、J、K未被公开。</p>

<h3>3. 对比文件D3（WO2011066691A1）的公开性分析</h3>

<p>D3公开了一种服务器端驱动的HTTP动态平滑流送系统（SSHTTPSS），主要利用内核流引擎（KSE）在发送端实时测量TCP往返时延（TCP-RTD），动态切换流送码率。</p>

<p>D3毫无异议地公开了特征A、B、C、D。在其第[0018]段指出，流送格式包含索引文件（Index Files）和分块内容文件（Cluster Content Files），每个分块含有标识符。在第[0030]段公开了客户端向服务器发起带有特定时间戳或偏移量的HTTP请求。然而，D3的自适应完全由服务器端的率适应模块（Rate Adaptation module）在发送粒子时直接抓取不同码率的关键帧（GOP）完成（见第[0032]段），根本不涉及对清单文件的修改（特征H未公开），也不包含对未来定位符的预解析（特征G未公开）。</p>

<h2>三、 技术特征比对表</h2>

<p>为了能够直观体现各对比文件的公开程度，现将权利要求1的所有技术特征与三份对比文件的具体原文公开内容进行映射比对：</p>

<table>

<thead>

<tr>

<th style="width: 15%;">技术特征编号</th>

<th style="width: 45%;">权利要求1的技术特征内容</th>

<th style="width: 13%;">D1<br>(WO2011044287A1)</th>

<th style="width: 13%;">D2<br>(WO2011047335A1)</th>

<th style="width: 14%;">D3<br>(WO2011066691A1)</th>

</tr>

</thead>

<tbody>

<tr>

<td><b>特征A</b></td>

<td>所述清单文件包括一个或多个分块标识符以及一个或多个关联的分块定位符</td>

<td>明示公开<br>(见[0149]段)</td>

<td>明示公开<br>(见[0026]段)</td>

<td>明示公开<br>(见[0018]段)</td>

</tr>

<tr>

<td><b>特征B</b></td>

<td>所述分块定位符用于定位向客户机传递分块的传递节点</td>

<td>明示公开<br>(见[0149]段)</td>

<td>明示公开<br>(见[0026]段)</td>

<td>明示公开<br>(见[0018]段)</td>

</tr>

<tr>

<td><b>特征C</b></td>

<td>所述分块由所述分块标识符识别</td>

<td>明示公开<br>(见[0149],[0175]段)</td>

<td>明示公开<br>(见[0021],[0026]段)</td>

<td>明示公开<br>(见[0018]段)</td>

</tr>

<tr>

<td><b>特征D</b></td>

<td>以清单文件中至少一个分块标识符为基础请求传递</td>

<td>明示公开<br>(见[0157],[0176]段)</td>

<td>明示公开<br>(见[0012],[0031]段)</td>

<td>明示公开<br>(见[0030]段)</td>

</tr>

<tr>

<td><b>特征E</b></td>

<td>从清单文件中选择至少一个另外的分块标识符</td>

<td>明示公开<br>(见[0158]段)</td>

<td>明示公开<br>(见[0032],[0034]段)</td>

<td>实质公开<br>(根据带宽选GOP)</td>

</tr>

<tr>

<td><b>特征F</b></td>

<td>所述另外的分块标识符与至少一个期望的未来分块请求关联</td>

<td>明示公开<br>(见[0158]段)</td>

<td>明示公开<br>(见[0029],[0036]段)</td>

<td>实质公开<br>(见[0032]段)</td>

</tr>

<tr>

<td><b>特征G</b></td>

<td><b>预解析与所选的另外的分块标识符关联的第一分块定位符的至少一部分以获得网络信息</b></td>

<td><b>未公开</b><br>(仅基于运营商策略)</td>

<td><b>未公开</b><br>(基于终端传感器)</td>

<td><b>未公开</b><br>(基于历史发送时延)</td>

</tr>

<tr>

<td><b>特征H</b></td>

<td>以所述网络信息为基础修改所述清单文件</td>

<td>明示公开<br>(见[0006],[0163]段)</td>

<td><b>未公开</b></td>

<td><b>未公开</b></td>

</tr>

<tr>

<td><b>特征I</b></td>

<td>网络信息包括与第一分块定位符关联的网络地址的至少一部分信息</td>

<td><b>未公开</b></td>

<td><b>未公开</b></td>

<td><b>未公开</b></td>

</tr>

<tr>

<td><b>特征J</b></td>

<td>网络信息包括定位符指向传递节点还是重定向网络节点的信息</td>

<td><b>未公开</b></td>

<td><b>未公开</b></td>

<td><b>未公开</b></td>

</tr>

<tr>

<td><b>特征K</b></td>

<td>网络信息包括与所选另外的分块标识符关联的第二分块定位符的至少一部分</td>

<td><b>未公开</b></td>

<td><b>未公开</b></td>

<td><b>未公开</b></td>

</tr>

</tbody>

</table>

<h2>四、 最接近对比文件（D1）的裁定与创造性深度评述</h2>

<p><span class="bold-lead">1. 最接近对比文件的确立：</span>从流媒体传输架构、技术领域以及整体解决的技术问题和达到的技术效果出发，本案最适合作为创造性分析过程中<span class="bold-lead">第一最接近对比文件（主引对比文件）的是 D1（WO2011044287A1）</span>。</p>

<p><span class="bold-lead">理由：</span>本申请的核心发明点在于通过在中间路径上“干预并修改清单文件”来实现对网络整体流量及流媒体自适应路由的调控。D1的构思完全与之吻合，其整体解决的技术问题是如何在无线网络运营商侧控制网络流量体积、缓解带宽压力，达到的技术效果是使得流媒体片段的码率选择对客户端和内容源保持完全透明，而控制权收归网络侧。相比之下，D2纯粹属于客户端传感数据驱动的自适应请求，不改变清单文件；D3属于纯服务端发送级别的调度，不改写清单协议文件。因此，D1在技术构思、系统拓扑和技术效果上均表现出最高程度的关联性。</p>

<p><span class="bold-lead">2. 区别技术特征与创造性缺陷评述：</span>以D1作为最接近的对比文件，权利要求1与D1相比，存在的实质性区别技术特征为：<span class="bold-lead">特征G，以及作为并列选择的特征I、J、K</span>。即“预解析未来分块定位符以动态获得网络信息（如具体网络地址、是否为重定向节点等），并以此作为修改清单文件的依据”。</p>

<p>纵观其余对比文件，D2侧重终端传感器状态（[0030]段），D3侧重当前连接的TCP往返时延（[0041]段），均没有给出任何关于“在中间或控制侧对清单文件中未来的定位符（URL/URI）进行预解析，从而提前获得底层网络地址或重定向属性信息”的启示。这意味着，单纯依靠现有文件D1、D2、D3的组合，并不足以直接否定特征G、I、J、K的创造性。本权利要求通过该特征解决了传统清单修改仅能依赖静态策略或宏观拥堵指标、无法针对未来具体传递节点的网络拓扑变化进行微观预判的技术问题，达到了提升未来请求命中率、降低由于重定向或跨网段带来的流送首包延迟的技术效果。</p>

<h2>五、 无效请求中最薄弱的技术特征判定</h2>

<p>若我方代表无效请求人向专利局针对该专利提出无效宣告请求，该权利要求书中最薄弱（即最容易被击破、创造性高度不足）的技术特征是：<span class="bold-lead">特征H（以所述网络信息为基础修改所述清单文件）</span>。</p>

<p><span class="bold-lead">无效理据分析：</span>虽然特征H在与特征G（预解析）结合时形成了目前的技术壁垒，但特征H本身——“根据网络状态信息在中间节点动态编辑、改写清单文件（如删除、插入或替换清单中的URI/URL）”这一动作，已经被对比文件D1在其说明书第[0006]段、[0163]段及[0194]段给出了极其详尽且毁灭性的公开。D1不仅公开了中间网络设备（Intermediate network device）识别清单文件，还公开了在其前往客户端的路径上直接删除高 bit rate 的 URI 或插入优化后的本地缓存 URI。因此，特征H属于流媒体动态中间控制领域的常规架构设计。在后续诉讼中，一旦审查员将特征G仅理解为常规的“DNS预解析（DNS Prefetching）”或常规的“链接网络探测”，那么特征H将无法提供任何具有高度的创造性技术贡献，该专利将极易被宣告无效。</p>

<h2>六、 进一步的对比文件检索策略建议</h2>

<p>鉴于目前D1+D2+D3的组合对核心特征G（预解析流送定位符以修改清单文件）的公开程度不够直接，为彻底破坏该专利的创造性，建议在后续的无效案源检索中实施以下精准检索策略：</p>

<p><span class="bold-lead">1. 核心技术要素词组的扩展检索：</span>聚焦于“清单文件动态改写”与“网络拓扑探测/预解析”的交集。建议采用扩展检索式：<span class="math">(Manifest OR "Playlist file" OR MPD) AND (Modify OR Edit OR Rewrite OR Inject) AND ("DNS prefetch" OR "Pre-parse" OR "Pre-resolve" OR "Network topology" OR Redirect)</span>。</p>

<p><span class="bold-lead">2. 寻找精准的D2/X类对比文件：</span>重点追踪在2010年左右由主流CDN服务商（如 Akamai, Limelight）或网络设备巨头（如 Cisco, Ericsson）申请的关于“边缘计算（Edge Computing）”、“智能DNS引导与流媒体协议协同”的专利。此类专利往往包含了“边缘节点在下发清单给用户前，先对清单里的源站或下行CDN节点进行Ping探测或DNS解析，若发现属于跨运营商地址则直接在清单中改写为本地联通/电信内网IP”的技术公开，一旦检索到此类文件，即可与D1完美结合，彻底摧毁特征G与I的创造性壁垒。</p>

<p><span class="bold-lead">3. 追踪流媒体标准组织（3GPP/MPEG-DASH）的早期提案：</span>本专利的申请背景高度依赖HTTP自适应流送协议的标准化进程。建议深入检索2009-2011年间3GPP SA4工作组关于3GP-Adaptive HTTP Streaming (AHS)或MPEG-DASH (ISO/IEC 23009-1) 标准制定期间的讨论文稿（TDocs）。标准提案中常有关于“中间网关或代理（Proxy）如何通过解析清单文件中的BaseURL或SegmentURL来预取网络路径信息并重写清单”的技术设想，属于极佳的破坏创造性的现有技术证据来源。</p>

</body>

</html>

"""

output_pdf_path = "patent_invalidity_analysis_report.pdf"

with open("temp_report.html", "w", encoding="utf-8") as f:

f.write(html_content)

HTML(filename="temp_report.html").write_pdf(output_pdf_path)

if os.path.exists(output_pdf_path):

print(f"SUCCESS: {output_pdf_path} generated.")

else:

print("FAILED")

```

```text?code_stdout&code_event_index=1

SUCCESS: patent_invalidity_analysis_report.pdf generated.

```

您的专利权利要求创造性与无效可行性深度分析报告 PDF 文件已为您生成完毕。

[file-tag: code-generated-file-3cb6dca4-bf45-4e05-8445-deba61c4be24]

以下是基于您提供的权利要求文件以及三份对比文件的核心深度分析摘要与结论：

### 一、 目标权利要求核心发明点解释

权利要求1的核心在于打破了传统自适应流送（如由客户端单向根据自身缓存或带宽盲目请求）的局限，提出了在中间或控制侧进行**“主动式预先协同清单控制”**的机制。其技术路径是：以当前请求为基础，预测并选择**未来的分块标识符**，并在客户端真正发起该未来请求之前，**“预解析”该未来分块定位符（URL/URI）的至少一部分以动态获取网络信息**（如底层具体网络地址、是否为重定向节点等），进而以此网络信息为依据**实时修改清单文件**下发给客户端，引导其建立最佳的传输路径。

### 二、 最接近对比文件（主引对比文件）的裁定

在创造性分析与无效宣告程序中，最适合作为**第一最接近对比文件的是 D1 (WO2011044287A1)**。

* **理由：** D1与目标专利在流媒体传输架构、系统拓扑及解决的技术问题上表现出最高程度的关联性。D1明确公开了“中间网络设备（Intermediate network device）拦截并识别清单文件，对其进行编辑（删除高码率URI或插入由运营商优化/本地缓存的URI），并将编辑后的清单文件发送给客户端”的完整框架。其解决的正是网络运营商如何主动干预自适应流送以调控整体流量体积的技术问题。

* **相比之下：** D2 (WO2011047335A1) 属于纯客户端基于物理传感器（GPS、加速度）和历史带宽的单向自适应请求，不涉及清单修改；D3 (WO2011066691A1) 属于纯服务端发送级别的调度（基于TCP-RTD直接在内核抓取不同码率的GOP发送），不涉及清单协议文件的改写。

### 三、 技术特征比对与无效可行性判定

1. **全面公开的区别特征：** D1、D2、D3三份文件均完整、毫无异议地公开了特征A、B、C、D、E、F（清单文件包含分块标识与定位符、基于标识请求、选择另外的未来分块标识等）。

2. **核心区别特征（技术壁垒）：** **特征G**以及并列的**特征I、J、K**（即“预解析未来定位符以获得具体网络地址/重定向节点属性等网络信息”）在D1、D2、D3中**均未被公开**。D1中修改清单的依据是“运营商宏观预设的流量控制策略或拥堵指标”，D2是终端传感器，D3是历史发送时延，均缺乏“对清单中未来的具体URL发起微观预解析”的技术启示。

3. **最薄弱的技术特征：** 权利要求中的**特征H（以所述网络信息为基础修改所述清单文件）**是最薄弱的。因为“在中间设备处识别清单文件，通过直接删除、插入或替换URI来改写清单内容”这一技术行为，已被D1在说明书第`[0006]`、`[0163]`、`[0194]`段给出了毁灭性的明示公开。特征H的动作本身属于流媒体领域的常规架构设计。

### 四、 进一步的无效检索策略建议

若要彻底推翻该专利权利要求1的创造性，目前的D1+D2+D3组合仍缺少对特征G（预解析未来定位符）的直接证明，建议进行以下精准补充检索：

1. **核心要素词组扩展检索：** 聚焦于“DNS预解析”或“智能网络拓扑探测”与“流媒体清单修改”的交集。检索式推荐：`(Manifest OR "Playlist file" OR MPD) AND (Modify OR Edit OR Rewrite OR Inject) AND ("DNS prefetch" OR "Pre-parse" OR "Pre-resolve" OR Redirect)`。

2. **追踪CDN服务商与网络巨头的早期专利（2009-2011年）：** 重点检索 Akamai、Cisco、Ericsson 等在2010年左右申请的边缘计算或智能DNS引导专利。此类现有技术经常包含“边缘网关在将清单下发给用户前，先对其中的源站URL进行Ping探测或DNS解析，若发现跨网段则直接改写IP”的逻辑，一旦检索到此类文件，即可与D1完美结合。

3. **深入检索标准组织提案（3GPP SA4 / MPEG-DASH）：** 检索2009-2011年间MPEG-DASH标准制定期间的早期讨论文稿（TDocs）。标准提案中常有关于中间代理（Proxy）如何通过解析清单文件中的BaseURL来提前预取网络路径信息并重写清单的技术设想，是极佳的破坏创造性的现有技术证据。

*注：更详细的逐项原文映射表、深度创造性评述以及具体段落引证已完整呈现在生成的 PDF 报告文件中，供您在无效宣告或侵权诉讼抗辩中直接参考使用。*

作为一名资深的专利代理师，我将针对本案的目标权利要求1以及两份对比文件（D1与D2），从说明书的深层物理含义、特征比对、最接近对比文件选择以及无效宣告的策略上进行全方位的专业拆解与分析。

---

## 权利要求1技术特征的物理含义解析

在流媒体传输领域（如3GPP Adaptive HTTP Streaming或DASH），权利要求1的核心物理含义是：**客户机在请求当前流媒体分块的同时，预测未来的分块请求，并提前（预解析）对未来分块定位符（如URL）的至少一部分进行解析（如DNS解析或获取重定向节点性质），然后根据解析得到的网络信息在本地动态修改清单文件（Manifest file，如MPD/m3u8）。**

其核心目的在于**降低后续请求的连接建立延迟（消除TCP握手/DNS查询等时间 penalty）**，或**提前感知网络节点的重定向行为，动态优化路由**。

---

## 对比文件公开情况比对表

根据权利要求1拆解的特征A至K，与对比文件 **D1 (US2011231519A1)** 和 **D2 (WO2011139305A1)** 进行详尽的原文特征比对：

---

## 最接近的对比文件（D1 vs D2）深度分析

在创造性评判中，选择最接近的对比文件（通常作为发明的基础，即“D1”）需要从**技术领域、解决的技术问题以及核心技术架构（效果）**三个维度进行综合考量。

### 1. 对比文件技术架构与解决问题分析

* **D1 (US2011231519A1)**：

* **架构领域**：纯粹的**客户端驱动的自适应流媒体传输（HTTP Streaming / 3GPP File Format）**。

* **解决的技术问题**：如何在客户端无感知、无频繁轮询的情况下更新媒体描述信息（MPD），如何规避TCP连接建立的延迟惩罚（Connection startup penalty），以及如何优化分块划分以提升压缩效率。

* **技术效果**：通过灵活的流水线请求（Pipelining）和时间/字节映射，使客户端能够自主高效地向标准Web服务器/CDN获取最佳画质分块。

* **D2 (WO2011139305A1)**：

* **架构领域**：**网络侧代理驱动的流量管理与流媒体优化（Proxy-based Control）**。

* **解决的技术问题**：无线蜂窝网络中，因移动用户基站切换、网络拥堵带来的带宽剧烈波动，尤其是解决“贪婪的客户端自适应算法”对网络整体吞吐量的破坏。

* **技术效果**：由移动运营商的Proxy主导，通过深度流检测（DSI）、伪造清单文件（Spoofed Playlist）以及强迫客户端进行播放速率削减（Playout rate reduction）或重定向，来实现全局的网络流量控制。

### 2. 结论：谁更适合作为最接近的对比文件？

**D1 (US2011231519A1) 更适合作为唯一最接近的对比文件。**

* **技术路径的一致性**：目标权利要求1明确定义的是一种“以清单文件为基础使能分块内容流送的方法”，且其技术动作（选择未来标识符、预解析定位符、**修改清单文件**）均发生于**流媒体传输的客户端动作链**中。D1构建的完全是标准的客户端DASH/3GPP流媒体基础架构，与目标专利的技术路线完美契合。

* **技术架构的背离（D2的局限性）**：D2的核心是一个**中心化的网络代理（Proxy）**。在D2的架构中，修改清单文件（生成Spoofed Playlist）和决定重定向的动作完全是由网络侧的Proxy电脑来强行实施的，客户端处于被动接受和被管控的地位。这与目标权利要求1所隐含的“客户端自主通过预解析网络信息来动态修改清单”的分布式自适应架构存在本质的拓扑架构冲突。因此，若以D2为出发点，审查员或无效请求人将面临极大的“技术架构改造阻力”。

---

## 缺陷与最薄弱的技术特征分析

通过上述比对可以清晰地发现，本权利要求1在无效宣告程序中，其防御的**核心堡垒**以及请求人眼中的**最薄弱特征**（即最容易被攻破或最不容易被公开的特征）呈现如下态势：

### 1. 最牢固的特征堡垒（结合特征G、H）

本权利要求最不容易被攻破的核心发明点在于：

> **“预解析与所述所选的另外的分块标识符关联的第一分块定位符的至少一部分……以及以所述网络信息为基础修改所述清单文件”**

无论是D1的客户端流水线请求，还是D2的Proxy预取和重定向，都**没有任何一个文件公开了“客户端提前对未来URL进行预解析（例如在网络层或应用层进行前期DNS或节点解析），并反过来在本地动态修改更新清单文件（MPD）”这一闭环动作**。D1和D2对清单文件的修改或更新均依赖于服务器侧的下发或代理侧的伪造。

### 2. 无效请求中最薄弱的技术特征

若要对本专利发起无效宣告，该权利要求最薄弱、最容易被对比文件外围蚕食的特征是：**特征E、F、I、J。**

* **特征E、F（未来分块的预测与选择）**：这属于流媒体预取（Prefetching）领域的通用技术。D1的候选请求列表（Candidate list）和D2的预测性预取（Predictively prefetching future segments）已经将“基于当前分块识别并选择期望的未来分块”这一逻辑实质公开。

* **特征I、J（包含网络地址或重定向节点信息）**：虽然对比文件没有公开这些信息是通过“客户端预解析未来分块”获得的，但**“分块定位符指向用于传递的传递节点还是重定向的网络节点”**这一网络拓扑架构，在D2的`[p0006]`和`[p0023]`中已经被完全公开（Proxy通过重定向将客户端引向特定的远程网络位置或本地缓存节点）。

**结论**：在无效宣告中，请求人很容易通过**D1（自适应流媒体框架） + D2（重定向与未来分块预取架构） + 公知常识（DNS预解析）** 构造创造性组合。

---

## 进一步的对比文件检索策略

鉴于目前D1和D2在“**客户端自主预解析未来URL并动态修改本地清单文件**”这一关键动作上存在组合盲区，为了成功无效该权利要求，建议采取以下精准检索策略：

### 1. 调整检索关键词与语义组合

重点攻关“**客户端DNS预解析/预连接**”与“**流媒体清单动态重构**”的交集。

* **语义轴A（流媒体控制）**：`DASH`, `MPD`, `Manifest`, `Playlist`, `m3u8`, `Smooth Streaming`, `Streaming segment`

* **语义轴B（预备动作）**：`DNS pre-fetching` (DNS预解析), `Pre-resolution`, `Pre-connect` (预连接), `Predictive lookup`, `Look-ahead`

* **语义轴C（本地改写）**：`Dynamic modification`, `Local rewrite`, `Client-side update`, `In-place edit`

### 2. 变换检索切入点：跨领域借鉴（公知常识/网页浏览器技术）

目标专利将“DNS预解析”这一在Web浏览器领域非常成熟的技术，移植到了流媒体分块请求领域。

* **策略**：检索2011年前后（目标专利优先权日前）**网页浏览器优化（Web Browser Optimization）**领域的对比文件。证明浏览器在解析HTML（一种清单文件）时，识别出未来的超链接（Future URLs），提前进行DNS预解析（DNS Prefetching），并动态调整DOM树或本地资源解析清单，是网页前端优化领域的常规技术手段。从而利用标准流媒体框架（如D1）结合网页预解析技术，以“**技术领域转用，且未带来意想不到的技术效果**”为由控诉其不具备创造性。

### 3. 目标标准组织（3GPP / MPEG / W3C）会议提案检索

鉴于目标专利深度涉及清单文件（MPD/MP4/3GP），该技术极有可能源自标准制定过程中的“技术提案（Contribution）”。

* **策略**：专门检索 **3GPP TSG-SA4 (Codec Working Group)** 以及 **ISO/IEC JTC1/SC29/WG11 (MPEG DASH)** 在2009年至2011年期间的会议输入文档（TDoc）。重点查找关于“`Minimizing HTTP turnaround time`”、“`DNS latency in DASH`”、“`Client-side MPD parsing optimization`”相关公司的提案（如Qualcomm, Ericsson, InterDigital, Nokia等），这些标准提案往往包含比公开专利更早、更详尽的系统架构演进描述，是绝佳的现有技术（Prior Art）来源。

作为一名经验丰富的专利代理师，我将为您对该涉案权利要求与对比文件进行深度的技术特征比对与创造性、无效可行性分析。

在本案中，目标权利要求涉及一种**“基于清单文件（Manifest File）使能分块内容流送”**的方法，其核心发明点在于通过“预解析未来分块请求的定位符”获取网络信息，并**以该网络信息为基础修改清单文件**，从而实现对流媒体客户端请求的超前引导与网络资源的优化配置。

以下是针对该权利要求的详细无效与创造性分析报告：

---

## 一、 对比文件基本信息及技术方案概述

在进行特征比对前，首先对两份对比文件（以下简称 D1、D2）的公开号、公开实质及解决的技术问题进行梳理：

* **对比文件1（D1）：`US20110314130A1`**

* **技术方案概述：** 涉及一种在带宽受限的“最后一公里（Last Mile）”信道上控制流媒体流的方法。其通过接收原始清单文件，根据网络信道状态（如带宽分配变化），**动态生成修改后的清单文件（Modified Manifest File）**发送给客户端。在修改时，通过删除非选择版本的检索信息（如 URL），迫使客户端只能请求符合当前网络带宽的视频分块，从而避免网络拥塞和带宽浪费。

* **对比文件2（D2）：`WO2009075033A1`**

* **技术方案概述：** 涉及一种移动通信系统中的本地分流（Local Breakout）及 CDN 重定向方法。当用户终端（UE）发送 DNS 请求（第一数据包）访问某个内容服务器时，在访问网关（vAGW）处拦截该请求，并以 vAGW 自身为发送元向本地 CDN 侧的 DNS 发送第二 DNS 请求。通过**比对两个 DNS 产生的大地解析结果（网络地址）**，若不同，则说明本地有更优的 CDN 节点（远程复制内容服务器），从而为 UE 分配新的本地 IP 并建立替代通信路（重定向），实现高效的内容访问。

---

## 二、 权利要求1的技术特征拆解与比对

根据权利要求1的文本，其可以拆解为 A 至 K 共 11 个技术特征。以下结合对比文件的原文及详细出处（段落/页码）进行毫无异议公开（实质公开）的逐项比对：

### 权利要求1技术特征比对表

---

## 三、 最接近的对比文件（D1）分析

在创造性分析中，**D1（US20110314130A1）最适合作为本案的核心最接近对比文件**。

### 1. 技术领域与解决的技术问题分析

* **本案：** 解决在基于清单文件的流媒体分块内容传输过程中，客户端可能盲目请求高码率或不合适节点的流媒体分块，从而导致网络拥塞或流媒体卡顿的问题。

* **D1：** 同样聚焦于基于清单文件（Manifest File）的流媒体分块传输（HTTP Streaming / ABR）。其明确指出：“客户端和服务器对它们之间的媒介没有任何信息……网络运营商无法有效管理最后一公里信道”（D1说明书\[0009\]-\[0010\]），其解决的技术问题正是**如何在网络侧介入流媒体分块的传输控制，防止由于客户端盲目请求导致的带宽浪费和丢包（Bandwidth Waste）**。

* **技术领域重合度：** 本案与 D1 均属于 **流媒体自适应流送（Adaptive Bit Rate Streaming）控制技术领域**，且核心控制对象均为“清单文件（Manifest File）”。相比之下，D2 属于移动通信网络层/传输层的路由重定向与 DNS 解析领域，不涉及流媒体的内容层控制。

### 2. 主要技术效果比对

D1 通过在网络侧（中间节点）拦截并修改清单文件，将非选定版本的 URL 检索信息剥离，使得客户端“被迫”只去请求符合当前信道状态的特定分块。这达到了与本案“根据预解析的网络信息修改清单文件，从而引导客户端高效流送分块内容”**完全相同的技术效果**（实现网络侧对客户端流媒体行为的隐性控制，优化带宽使用，提升播放流畅度）。

因此，**D1 构成了本案最接近的现有技术，应作为创造性评价的起点（主案）。**

---

## 四、 区别技术特征与结合创造性评述

将 D1 作为最接近的对比文件时，本案权利要求1与 D1 的**主要区别特征**在于特征 J 的后半部分以及特征 G 中的特定解析对象逻辑：

> **区别特征：** 清单文件修改所依据的“网络信息”，明确包含了“预解析出的未来分块定位符是指向用于传递分块的传递节点，还是指向用于期望的未来分块请求的重定向的网络节点的信息（即节点属性的甄别：直接传递 vs. 重定向）”。

### 结合创造性分析

虽然 D1 已经公开了“根据信道带宽分配动态修改清单文件”的架构，但 D1 修改清单文件的核心出发点是“自适应码率（ABR）的动态匹配”，并没有在流媒体清单文件层级上明确去**解析并判断该定位符到底是指向“直接传递节点”还是“重定向网络节点”**。

然而，**这一区别特征的实质技术手段已被 D2（WO2009075033A1）公开**。

* **D2 的技术启示：** D2 明确公开了一种由网络节点（vAGW）代理发送第二求包，并通过比对两个地址解决结果，从而**“简易识别并提供能够实现高效内容访问的连接（通信路/重定向）”**的技术手段（见 D2 的目的描述）。在 D2 中，区分原始服务器地址与可重定向的本地 CDN 复制服务器地址，正是其核心技术实质。

* **结合的显而易见性：** 当本领域技术人员试图在 D1 的流媒体清单文件控制系统中，进一步优化传递节点的选择（例如不仅考虑码率，还希望考虑节点是在线圈网的本地 CDN 节点还是远程主服务器节点）时，在 D2 的启发下，非常容易想到利用中间节点去预解析/拦截检索请求，获取地址信息，并判断该定位符指向的是直接传递节点还是重定向的 CDN 节点，并以此为依据去修改清单文件中的定位符（URL）。

因此，**权利要求1整体上可以通过 D1 和 D2 的结合来实施创造性否定。**

---

## 五、 无效请求中最薄弱的技术特征

如果要向专利局提出无效宣告请求，本权利要求中**最薄弱（即最容易被现有技术攻破、防守力度最差）**的技术特征是：

### 特征H：以所述网络信息为基础修改所述清单文件

#### 理由如下：

1. **现有技术完全直开：** 该特征构成本案权利要求1的核心动作，但它已经被 **D1 完全且毫无异议地公开**。D1 的权利要求和说明书摘要中反复强调了“generating a modified manifest file... by removing retrieval information”（通过移除检索信息生成修改后的清单文件）并发送给客户端（参见 D1 说明书 \[0013\], \[0024\], \[0035\]）。

2. **技术方案的核心驱动力丧失：** 申请人通常会辩称“修改清单文件”是其区别于传统网络层重定向的技术贡献，但在 D1 的强力阻击下，这一“在网络中间节点动态篡改/修改流媒体清单文件以控制客户端行为”的架构已经彻底失去了新颖性。一旦这一支撑性骨架被 D1 彻底砸实，本案将只剩下外围的“网络信息具体包含哪些参数（特征 I, J, K）”这一偏向数据结构定义的微弱区别，极易被认定为属于“公知常识的常规选择”或“被其他通信网络控制文件（如 D2 的 DNS/通信路控制）所给出技术启示”。

---

## 六、 进一步的对比文件检索策略

由于本案的区别特征落在了“流送清单文件层面的**重定向（Redirect）信息/CDN节点属性信息**的预解析与修改”上，为了能彻底地通过单篇对比文件否定其创造性，或形成更完美的“流媒体全领域”结合，建议采取以下进阶检索策略：

### 1. 关键词扩展与精准联配

* **核心控制对象层：** `Manifest File`（清单文件）、`MPD`（Media Presentation Description，MPEG-DASH标准中的清单文件）、`M3U8` / `Playlist`（HLS标准中的播放列表）。

* **动作与属性层：** `Pre-parse` / `Pre-resolve`（预解析/提前解析）、`Intercept`（拦截）、`Rewrite` / `Modify`（重写/修改）、`Redirect`（重定向）、`CDN Edge node`（边缘节点/传递节点识别）。

* **组合检索式推荐（以英文为例）：**

* `(MPD OR "manifest file" OR playlist) AND (modify OR rewrite OR alter OR adapt) AND (redirect OR "edge node" OR "redirection node") AND (pre-parse OR intercept)`

### 2. 标准文献检索（极为关键）

本案的技术形态与移动通信和互联网流媒体标准高度相关。建议打破常规专利数据库限制，深入检索 **3GPP** 和 **MPEG/DASH** 的标准提案（TDoc）：

* **3GPP 方面：** 重点检索 **SA4（Codec和多媒体流媒体工作组）** 在 2012-2015 年期间关于 **DASH (Dynamic Adaptive Streaming over HTTP) over 3GPP** 以及 **SAND (Server and Network Assisted DASH, ISO/IEC 23009-5)** 标准制定期间的提案。SAND 标准的核心正是讨论“网络节点（DNE）如何介入并协助/修改 DASH 客户端的流送清单和请求”。

* **IETF 方面：** 检索关于 `CDNI`（CDN Interconnection，CDN互联）和 `HTTP Redirection` 相关的 RFC 草案，特别是涉及边缘节点自动改写 HTTP 资源列表（Playlist）以实现负载均衡的早期提案。

### 3. 分类号锁定

精准限定检索范围至以下 IPC/CPC 分类号，并在其中批量过滤 2012 年之前的申请：

* **H04N 21/845：** 专门针对流媒体分块、分段（Chunking/Segmenting）的内容结构。

* **H04N 21/262：** 发送端/网络侧的流媒体调度与播放列表修改。

* **H04L 65/60：** 网络协议层面的流媒体网络传输控制。

根据权利要求1所述的方法，如果所述第一分块定位符指向用于重定向的网络节点；将所述第一分块定位符的至少一部分预解析为与所述所选的另外的分块标识符关联的第二分块定位符的至少一部分。

根据权利要求1或2所述的方法，以所述第二分块定位符的所述至少一部分为基础修改所述清单文件；优选地所述修改包括以所述第二分块定位符的所述至少一部分替换所述第一分块定位符的至少一部分的步骤。

根据权利要求1或2所述的方法，其中所述预解析包括发送针对所述网络信息的请求至与所述第一分块定位符关联的网络节点；接收响应消息；以所述响应消息为基础确定与所述所选的另外的分块标识符关联的所述第一分块定位符是指向用于与所述期望的未来分块请求关联的分块的传递的传递节点还是指向用于所述期望的未来分块请求的重定向的网络节点。

根据权利要求4所述的方法，其中所述针对网络信息的请求包括下列项的至少一个：优选为HTTP HEAD消息或RTSP DESCRIBE消息的HTTP、RTSP和/或DNS协议消息；和/或其中所述响应消息为HTTP或RTSP响应消息。

根据权利要求1或2所述的方法，其中所述预解析在所述至少一个分块的传递的至少一部分期间作为后台过程执行。

根据权利要求1或2所述的方法，以如下项的至少一部分为基础选择所述至少一个另外的分块标识符：用户资料、用户浏览历史、用户与分块内容的交互和/或客户机和/或用户的地理位置。

根据权利要求1或2所述的方法，其中所述清单文件包括用于将一个或多个另外的分块标识符标记用于未来分块请求的一个或多个标记；优选地所述标记包括评分值。

根据权利要求1或2所述的方法，其中所述预解析包括传输针对所述网络信息的请求至第一内容传递网络(CDN1)；所述请求优选为HTTP HEAD消息或RTSP DESCRIBE消息；所述请求包括至少所述所选的另外的分块标识符；所述第一内容传递网络(CDN1)传输交互CDN请求消息至第二内容传递网络(CDN2)以供协商由所述所选的另外的分块标识符识别的所述分块的未来传递；所述交互CDN请求消息包括所述所选的另外的分块标识符；所述交互CDN请求消息优选为DELIVERY REQUEST消息；所述第一内容传递网络CDN1接收交互CDN响应消息；所述交互CDN响应消息包括位置信息；所述交互CDN响应消息优选为DELIVERY RESPONSE消息；所述位置信息优选为与所述第二内容传递网络CDN2中一个或多个传递节点关联的网络地址或分块定位符；所述一个或多个传递节点配置成向客户机传递由所述所选的另外的分块标识符识别的分块；其中，可选地，所述交互CDN请求消息包括优选为标志的指示符；所述指示符允许所述第二内容传递网络CDN2确定所述交互CDN请求消息与分块定位符的所述预解析关联；或其中所述交互CDN请求消息以HTTP HEAD消息或RTSP DESCRIBE消息为基础来实现，从而允许所述第二内容传递网络CDN2确定所述交互CDN消息与分块定位符的所述预解析关联。

根据权利要求3所述的方法，其中对所述网络信息的所述请求包括HTTP HEAD消息。

根据权利要求3所述的方法，其中所述预解析在所述至少一分块的传递的至少一部分期间作为后台过程执行。

根据权利要求3所述的方法，以如下项的至少一部分为基础选择所述至少一个另外的分块标识符：用户资料、用户浏览历史、用户与分块内容的交互和/或客户机和/或用户的地理位置。