用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法，接收第一清单文件；其包括一个或多个段标识符和用于定位一个或多个递送节点的位置信息；所述一个或多个递送节点被配置成向所述至少一个客户端发送与所述一个或多个段标识符相关联的一个或多个段；向客户端提供信道建立信息；以及基于所述提供的信道建立信息，在所述至少一个客户端和与所述递送节点相关联的控制信道服务器功能之间建立至少一个流式传输控制信道；所述至少一个客户端被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息。

作为一名经验丰富的专利代理师，我将针对目标专利“权利要求1”的技术特征，紧密结合各对比文件（D1: US20050246752A1、D2: US20060212595A1、D3: JP2010519822A）的原文进行法律与技术层面的深度比对与剖析。

---

### 一、 目标专利权利要求1的技术特征拆解与说明书解释

为了客观准确地比对，首先对权利要求1的技术特征进行梳理与界定：

* **技术特征A**：接收第一清单文件（First manifest file）；

* **技术特征B**：其（清单文件）包括一个或多个段标识符（Segment identifiers）和用于定位一个或多个递送节点的位置信息（Location information for locating delivery nodes）；

* **技术特征C**：所述一个或多个递送节点被配置成向所述至少一个客户端发送与所述一个或多个段标识符相关联的一个或多个段；

* **技术特征D**：向客户端提供信道建立信息（Channel establishment information）；

* **技术特征E**：基于所述提供的信道建立信息，在所述至少一个客户端和与所述递送节点相关联的控制信道服务器功能（Control channel server function）之间建立至少一个流式传输控制信道（Streaming control channel）；

* **技术特征F**：所述至少一个客户端被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息（Manifest file update messages）。

**说明书解释要点**：

本专利核心在于**网络发起的控制**（Network-initiated control）下的流媒体传输架构。清单文件用于提供分段媒体信息的定位（节点+段标识符），而**独立的控制信道**用于实现清单文件的实时动态更新（Manifest Update），确保客户端能够动态获取最新的分段信息或节点切换控制。

---

### 二、 对比文件特征比对与原文出处分析

现将各对比文件的公开号与简称对照如下：

* **D1**: US20050246752A1 (`Method and system for sharing video over a network`)

* **D2**: US20060212595A1 (`Method and computer-readable medium for associating sequence numbers with data blocks for distribution of data in a peer-to-peer network`)

* **D3**: JP2010519822A (`Time shift tv service establishment method and time-shift tv media functional entity`)

#### 1. 详细特征比对表

---

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

##### **D1: US20050246752A1**

* **公开情况**：D1主要涉及视频文件的上传、转码及基于URL/缩略图的视频共享。

* **特征C（实质公开）**：原文第`[0038]`段指出：“*In one embodiment the viewer activates a link by clicking a button, and the server computer 62, 62' responds by sending a streaming video segment that the viewer observe.*”（服务器根据请求向客户端发送流式视频段）。

* **缺失特征**：D1未公开“清单文件（Manifest file）”的概念（特征A/B），也未涉及“流式传输控制信道及其更新消息”（特征D/E/F）。

##### **D2: US20060212595A1**

* **公开情况**：D2涉及P2P网络中基于全局序列号（Sequence Number）对数据块（Data Blocks）进行分发。

* **特征A/B（实质/毫无异议公开）**：

* 第`[0023]`及`[0025]`段指出：“*Control server 231 may maintain or generate a peer list 270 that includes connectivity information, such as a network address and port number...*” 以及 “*...peer client that has cached multimedia content maintains or generates a sequence number scope list that specifies the sequence numbers of data blocks maintained by the client.*”

* **分析**：结合`Peer list`（节点位置信息）与`Sequence number scope list`（段标识符列表），两者组合实质上起到了“清单文件”的作用，公开了特征A和特征B。

* **特征C（毫无异议公开）**：第`[0046]`段指出：“*Peer clients may obtain data blocks from the source server by specifying sequence numbers of desired data blocks... upload data blocks to other peer clients...*”

* **特征F（实质公开）**：第`[0025]`段及第`[0031]`段指出，当Peer节点缓存更新时，会生成/更新序列号范围列表并发送给其他客户端：“*...generates or updates its sequence number scope list... transmit the sequence number scope list to other peer clients...*”，这属于清单更新消息的范畴。

* **缺失特征**：D2属于纯粹的P2P网络传输架构，未显式公开专门的“流式传输控制信道服务器功能（Control channel server function）”（特征E）。

##### **D3: JP2010519822A**

* **公开情况**：D3公开了一种在IMS网络中实现时移电视（TsTV）服务的方法及媒体功能实体（TsTV MF）。

* **特征C/D/E（毫无异议公开）**：

* 第`[0011]`段、第`[0016]`段及实施例第`[2]`节（Step 204-213）明确记载：“*TsTV MFエンティティが、端末によって開始された、コンテンツ送達チャネル情報およびコンテンツ制御チャネル情報を保有するメディアネゴシエーションを受信し、メディアネゴシエーション結果に従って、端末との伝送接続を確立し...*”（TsTV MF接收包含内容送达通道信息和内容控制通道信息的媒体协商，并建立传输连接/TCP连接）。

* 第`[2]`节（Step 213-214）明确指出建立专门用于RTSP控制信令的TCP传输连接：“*端末は、メディアネゴシエーション結果に従ってTsTV MFエンティティと共にRTSPを担う伝送接続(例えば、TCP接続)を確立する。*”这完全对应特征D和特征E中的“控制信道服务器功能及流式传输控制信道的建立”。

* **特征A/B/F（实质公开）**：

* D3通过SIP/SDP协商协议传输媒体描述（SDP Offer/Answer，包含媒体位置、通道描述、RTSP URI），并结合RTSP PLAY指令中的“绝对时间/媒体位置信息”（Step 214），实质公开了清单文件及段标识符的概念（特征A/B）。

* 在Step 204/314（ Session Update 要求/Re-INVITE）中，通过控制信道/IMS网络动态更新会话与通道信息，实质公开了“清单文件/会话更新消息”（特征F）。

---

### 三、 最接近对比文件的选择与创造性/无效分析

#### 1. 最接近对比文件的挑选与理由

在专利无效审查实践中，选择最接近的对比文件需考虑：**技术领域是否相同、解决的技术问题是否相似、公开的技术特征数量多少**。

**结论**：**D3 (JP2010519822A)** 最适合作为**第一最接近的对比文件**；**D2 (US20060212595A1)** 可作为**备选的最接近对比文件**。

* **选择 D3 的理由**：

1. **技术领域与架构高度一致**：D3与本专利均处于“网络发起的/基于网络架构的流媒体控制与传送（如IPTV/时移电视）”领域。

2. **核心控制机制相同**：D3完整公开了“**内容控制信道（Control Channel）**与**内容送达信道（Delivery Channel）**分离”的架构，并详细描述了在客户端与服务器（TsTV MF）之间建立基于RTSP/TCP的专门流式传输控制信道的完整过程（覆盖了特征C、D、E）。

3. **解决的技术问题一致**：两者均致力于解决如何在网络侧控制下，动态建立控制与传输连接，实现流媒体的灵活控制与更新。

* **选择 D2 的理由（备选）**：

1. 如果侧重于“**媒体分段（Segmentation）、段标识符（Segment Identifiers）及清单（Scope List）的动态分发**”，D2在数据分段与清单结构上的映射更为直观（公开了特征A、B、C、F）。

---

#### 2. 结合对比文件的组合无效方案分析

##### **方案一：以 D3 为最接近对比文件 + D2 / 本领域公知常识**

* **主攻方向**：

* D3已经完全公开了技术特征 C、D、E，并实质公开了特征 A、B、F（通过 SDP 描述文件及 Session Update 机制）。

* **区别特征分析**：若专利权人抗辩称“SDP 或 RTSP URI 不等同于 HTTP 流媒体中的 Manifest（清单文件）”，则区别特征仅在于**将媒体控制信息具体表现为“清单文件（Manifest file）及其更新消息”**。

* **结合路径**：D2（或HTTP Live Streaming/DASH公知常识）明确公开了将媒体切片并使用清单文件（Sequence Number Scope List/Manifest）进行段定位与动态更新的技术手段。将D2的清单文件管理机制结合到D3的IMS/TsTV控制信道架构中，对本领域技术人员而言是显而易见的。

##### **方案二：以 D2 为最接近对比文件 + D3**

* **主攻方向**：

* D2公开了基于段标识符（Sequence Number）和节点列表（Peer List）的清单机制（特征A、B、C、F）。

* **区别特征分析**：D2未显式公开“建立专门的流式传输控制信道及控制信道服务器功能”（特征D、E）。

* **结合路径**：D3明确教导了在网络流媒体传输中，利用控制信道服务器（TsTV MF）建立独立的控制信道（TCP/RTSP）来实现网络发起的控制与动态更新。将D3的控制信道建立机制引入D2的流媒体传输体系中，属于常规的技术组合。

---

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

在针对权利要求1发起无效宣告请求时，**最薄弱（即最容易被无效掉/突破）的技术特征是：技术特征D 与 技术特征E**。

* **薄弱原因**：

1. **特征D与E（控制信道的建立）已经被D3完全击穿**：D3的第`[0011]`-`[0016]`段及Step 213详细记载了客户端与TsTV MF（控制信道服务器）之间基于SIP/SDP协商建立RTSP传输/控制信道（TCP连接）的全过程。这使得本专利关于“建立流式传输控制信道”的限定完全丧失新颖性或创造性。

2. **特征A与B（清单文件与段标识符）属于现有技术的常规替换**：在切片流媒体传输（如HLS、DASH、P2P分片传输）中，使用包含段标识符和URL/节点位置的Manifest文件是本领域的公知常识（D2亦有充分体现）。

* **抗辩风险点（专利权人可能的反驳）**：

* 专利权人可能会强调“**经由流式传输控制信道接收清单文件更新消息（特征F）**”中“控制信令与清单更新”的结合关系，主张D3的 Session Update 是通过IMS Core发起的，而D2的Scope List更新是P2P节点间发送的，均非“在专门建立的流式传输控制信道上接收清单更新”。

---

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

为了彻底封闭专利权人的防守空间（尤其是针对特征F“经由控制信道推送/接收Manifest Update”），建议采取以下进一步检索策略：

1. **技术标准文献检索（极高优先级）**：

* **重点关注标准组织**：3GPP（如3GPP TS 26.234 - PSS、3GPP TS 26.247 - DASH）、DVB-DASH、MPEG-DASH (ISO/IEC 23009-1)、OMA (Open Mobile Alliance)。

* **关键词组合**：`Dynamic Manifest Update` / `Manifest Refresh` / `Inband Signaling` / `Control Channel` / `MPD Update` / `RTSP` / `DASH`。

* **检索逻辑**：标准文献中对于移动网络下通过单独的TCP/HTTP控制信道或Websocket信道向客户端推送清单更新（Dynamic MPD/Manifest Update）有极其详尽的规范定义，极易找到直击特征F的对比文件。

2. **专利文献扩充检索**：

* **IPC/CPC分类号**：`H04L65/60`（流媒体传输）、`H04L65/10`（会话控制）、`H04L67/02`（基于Web协议）。

* **检索式逻辑**：`(manifest or MPD or playlist) AND (update or refresh) AND (control channel or control server or control socket)`。

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

* 检索2008–2012年间关于“HTTP Adaptive Streaming (HAS)”、“Network-assisted DASH”、“Live Streaming Manifest Update”的 IEEE / ACM 学术论文。聚焦于在直播或时移电视中，服务器如何通过长连接/控制信道动态向客户端更新Manifest文件。

作为一名经验丰富的专利代理师，我将紧密结合**目标专利的说明书（权利要求1及相关技术方案）**与**对比文件原文**，对技术特征进行精准比对、最接近对比文件的选择分析以及无效检索策略的制定。

---

### 一、 权利要求1技术特征拆解与技术内涵解析（结合目标专利说明书）

权利要求1保护的是一种“**用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法**”。结合HTTP流式传输（如DASH或HLS等）的通用技术背景与本专利方案，对各技术特征拆解如下：

* **前置主题/步骤：** 用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法；

* **技术特征A：** 接收第一清单文件（Manifest file/MPD）；

* **技术特征B：** 其包括一个或多个段标识符（Segment Identifier/URI）和用于定位一个或多个递送节点的位置信息（Node Location Info/Base URL/Server Address）；

* **技术特征C：** 所述一个或多个递送节点被配置成向所述至少一个客户端发送与所述一个或多个段标识符相关联的一个或多个段（Media Segments）；

* **技术特征D：** 向客户端提供信道建立信息（Channel Establishment Info）；

* **技术特征E：** 基于所述提供的信道建立信息，在所述至少一个客户端和与所述递送节点相关联的控制信道服务器功能之间建立至少一个流式传输控制信道（Streaming Control Channel）；

* **技术特征F：** 所述至少一个客户端被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息（Manifest Update Message / Out-of-band / Push update）。

> **关键创新点与发明构思（用于评估最接近对比文件与无效突破口）：**

> 传统HTTP流式传输（如客户端轮询Polling）由客户端主导，频繁请求清单更新会造成带宽浪费与延迟。本权利要求1的核心在于**“网络发起的控制（Network-initiated control）”**，即通过向客户端提供信道建立信息，建立**带外/独立控制信道（Control Channel）**，网络端（控制信道服务器）可通过该信道主动向客户端**推送（Push）清单文件更新消息**（特征D、E、F）。

---

### 二、 对比文件原文比对与对比分析

以下将各对比文件原文与权利要求1的技术特征进行逐一比对。

#### 1. D1：WO2011087449A1

* **技术领域：** 用于HTTP媒体流分发的清单文件（MPD）结构与更新。

* **公开特征比对：**

* **特征A/B/C：** 公开了客户端获取包含媒体段URI（段标识符及位置信息）的MPD文件，并从网络节点（递送节点）下载媒体段（[p0003]、[p0018]、[p0019]）。——**实质/毫无异议公开**。

* **特征D/E/F（更新机制）：**

* D1在[p0034]、[p0035]中提到了两种更新机制：“polling”（轮询）以及“**updated MPDs may instead be pushed to the client**”（更新的MPD可以被推送给客户端），以及在[p0384]中提到了“**push notification approach, where the client is notified about an MPD update by a server, typically by receiving a notification sent in-band together with associated media segments. The new MPD may be provided by a server in a Multipart MIME container...**”。

* **差异点：** D1中提及的“push”主要是带内（in-band，随媒体段一起发送 Multipart MIME），**未明确公开**“向客户端提供信道建立信息”、“在客户端与控制信道服务器之间建立**流式传输控制信道**”，以及“经由该**控制信道**接收更新消息”等带外控制信道架构（特征D、E、F）。

#### 2. D2：WO2011090715A2

* **技术领域：** 用于不限格式流架构的边缘服务器（Edge Server for CDN）。

* **公开特征比对：**

* **特征A/B/C：** 公开了客户端向CDN边缘服务器请求流媒体，边缘服务器获取Stream Manifest、Fragment Index，并将IF片段转换为目标格式提供给客户端（[p0014]、[p0048]、[p0061]）。——**实质公开**。

* **特征D/E/F（控制信道机制）：**

* D2在[p0064]、[p0065]、[p0156]中公开了“...the HTTP proxy process supports a **control channel** by which the client can make any combination of various requests against an active stream including... seek, and switch.”以及在[p0156]提到：“The control channel is used send seek requests to the edge server process when a new stream playback position is desired... via a POST request on a new connection.”。

* **差异点：** D2中的控制信道（Control Channel）是**客户端向服务器发起请求/控制命令**（如seek、switch、发送session token的POST请求），属于**客户端发起的控制（Client-initiated control）**，用于控制播放进度或切换码率，**并未公开**“网络发起的控制”、“基于网络提供的建立信息建立信道”，以及“经由该控制信道**接收清单文件更新消息（Manifest Update）**”。

#### 3. D3：US20110191684A1

* **技术领域：** 互联网视频访问与管理（聚合不同网站视频生成播放列表、Vlog及GUI）。

* **公开特征比对：**

* D3侧重于上层播放列表（Playlist）的生成、HTML GUI界面、Vlog评论及多URL播放顺序控制（[0010]-[0014]）。其公开的“Playlist/View script”是更高层级的网页URL播放脚本，不属于HTTP媒体流底层分段传输（Segment/MPD）架构。

* **未公开：** 底层流媒体的段标识符/递送节点位置（特征B/C）、网络发起控制信道建立（特征D/E）及清单更新推送（特征F）。

---

### 三、 特征比对表格（特征矩阵）

---

### 四、 最接近的对比文件选择分析（整体技术问题与技术效果维度）

在评估哪个对比文件最适合作为**最接近的对比文件（Primary Prior Art）**时，需从技术领域、解决的技术问题及技术效果切入：

1. **D1 (WO2011087449A1) 适合作为首选的最接近对比文件**：

* **技术问题与效果：** D1旨在解决HTTP流传输中MPD清单文件结构僵硬、无法灵活更新（特别是在Live动态场景）的问题（[p0015]-[0017]）。D1提出了更新MPD的概念，并明确提出了通过**Push机制（推送模式）**将更新后的MPD发送至客户端（[p0035]），与本专利“解决轮询带来越纳延迟与开销、实现网络发起更新”的技术问题和技术效果最为契合。

* **区别特征：** 仅在于**推送的具体实现方式**（D1为带内/概念性Push vs. 本专利通过独立控制信道及信道建立信息建立控制信道来进行网络发起的清单更新）。

2. **D2 (WO2011090715A2) 适合作为备选的最接近对比文件**：

* **技术问题与效果：** D2主要解决CDN架构下跨格式流媒体高效传输与控制（[p0010]-[p0013]）。D2公开了流媒体架构中明确的“**Control Channel（控制信道）**”（[p0064]）。

* **区别特征：** D2中的控制信道是客户端发起的（用于POST命令、Seek、Switch），而不是“网络发起的控制”，且信道传输的是控制指令而非“清单文件更新消息”。

> **结论：** 在创造性审查/无效宣告中，**建议以 D1 (WO2011087449A1) 作为第一最接近对比文件**；以 **D2 (WO2011090715A2)** 作为结合对比文件（或备选最接近对比文件）。D3技术领域差异较大，不适合作为最接近对比文件。

---

### 五、 未被最接近对比文件公开的技术特征及最薄弱特征分析

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

以 **D1** 为最接近对比文件，未被公开的区别技术特征为：

* **特征D+E+F的组合：** “向客户端提供信道建立信息，在客户端与控制信道服务器之间建立流式传输控制信道，并**经由该控制信道接收清单文件更新消息**（即网络发起控制的带外推送更新架构）”。

如果试图引入 **D2** 结合：

* D2虽公开了“Control Channel（控制信道）”，但D2的控制信道作用方向是**客户端 -> 服务器**（发送Seek/Switch请求），而本专利特征F是**服务器 -> 客户端**（推送清单更新消息，网络发起）。

#### 2. 若提出无效请求，目标专利最薄弱的技术特征分析

本专利权利要求1最薄弱（最容易被突破）的技术特征在于：**“控制信道的定义与建立过程（特征D、E）”**。

* **薄弱点原因：**

1. **信道建立信息的泛化：** 在HTTP/WebSockets/推送通知（Push Notification/Long-Polling/SSE）领域，“信道建立信息”可以非常简单（如一个WebSocket URL、Push Token服务器地址或Server-Sent Events的Endpoint）。

2. **公知常识/技术结合的风险：** D1已经提出了“将更新后的MPD Push给客户端（Updated MPDs pushed to client）”的技术构想（D1 [p0035]）。当本领域技术人员为了在D1中实现这个“Push”功能时，从网络通信公知常识（如WebSocket协议RFC 6455、SIP订阅/通知机制、或推送服务器机制）出发，采用“向客户端下发Push Server地址（信道建立信息）以建立独立控制/推送信道”，属于**本领域技术人员解决‘如何实现D1中Push功能’的常规技术选择**。

---

### 六、 进一步的对比文件检索策略（无效检索指南）

为了成功发起无效宣告，针对上述“最薄弱特征（带外控制信道/网络推送清单更新）”，建议采取以下补充检索策略：

1. **精准检索要素组合（Keywords & IPC/CPC）：**

* **核心分类号：** `H04L65/60`（流媒体传输）、`H04L65/65`（流媒体传输控制协议）、`H04L67/55`（推送服务 Push Services）、`H04L67/02`（基于Web协议的通信）。

* **关键词逻辑组合：**

* (`HTTP streaming` OR `DASH` OR `HLS` OR `Manifest` OR `MPD` OR `Playlist`)

* **AND** (`Push` OR `Server-initiated` OR `Control channel` OR `WebSocket` OR `Out-of-band` OR `Notification`)

* **AND** (`Update` OR `Refresh` OR `Dynamic`)

2. **追溯标准协议与早期草案（Standard Documents & Drafts）：**

* 目标专利申请日集中在2011年左右，此时正是 **3GPP PSS / Dynamic Adaptive Streaming over HTTP (DASH)** 标准化的关键时期。

* **重点检索对象：**

* **3GPP TS 26.234 / TS 26.247** 早期研讨文稿（Tdoc）：重点寻找关于“Server Push for MPD Update”、“MPD Update via control channel / Long polling”的提案。

* **ISO/IEC 23009-1 (MPEG-DASH)** 早期草案及Working Drafts (2010-2011年)。

3. **寻找“控制信道/推送清单”的强对比文件（D4/D5）：**

* 寻求一篇公开了**“在流媒体传输中，通过独立的控制信道/WebSocket/推送通道向客户端发送/推送更新后的清单文件/播放列表”**的对比文件。

* **结合路径：** 将 **D1 (WO2011087449A1)** 作为第一对比文件（提供MPD更新与Push构想），结合新检索出的 **D4/公知常识**（提供通过控制信道推送清单更新的具体技术手段），从而评述权利要求1的创造性（意图证明特征D+E+F属于显而易见的重新组合或常规技术套用）。

尊敬的委托人/代理人：

作为一名经验丰富的专利代理师，我已对目标专利权利要求1（以下简称“本专利权1”）以及两份对比文件**D1（WO2011122909A2）**与**D2（WO2011136496A2）**进行了全面、严谨的法律与技术对比分析。

以下是紧密结合目标专利说明书内涵与对比文件原文出处做出的详细法律意见书：

---

## 一、 权利要求特征拆解与技术特征比对

为了实现准确的对比，将本专利权利要求1拆解为技术特征A~F，并分别与D1、D2的原文进行核对分析。

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

---

### 2. 各对比文件公开性之详细分析及原文出处

#### (1) 对比文件 D1（WO2011122909A2）

* **特征A**：段落 [8]、[44] 明确记载了客户端接收MPD（Multimedia Presentation Description，即本领域通用的流式传输清单文件）：“`a client device for receiving the updated MPD...`”；段落 [310] 记载“`transmits (delivers) the created MPD file to the client 306`”。因此，D1**实质公开了特征A**。

* **特征B**：段落 [8] 记载 MPD 中包含“`Uniform Resource Location (URL) information indicating a location where the segment is stored`”；段落 [39] 记载“`Uniform Resource Location (URL) information representing each representation or segment is also changed.`”。URL与段信息即对应“段标识符及定位递送节点的位置信息”。因此，D1**实质公开了特征B**。

* **特征C**：段落 [43] 定义了“`live broadcast content server 300`”、“`nPVR or on-network content storage device 302`”作为提供内容的服务器；段落 [312b] 记载“`the live broadcast content server 300 transmits a segment... to the client`”，段落 [328b] 记载“`nPVR... transmits the segment requested... to the client`”。这些服务器即对应“递送节点”。因此，D1**实质公开了特征C**。

* **特征D、E、F**：D1中客户端获取清单更新（Updated MPD）的方式是**轮询/主动请求模式**（参见段落 [48]、[362]-[366]：“`If the checktime has come... the client 306 requests the content delivery server 304 to update the changed MPD...`”）。D1中不存在“向客户端提供信道建立信息”、“建立流式传输控制信道”以及“经由流式传输控制信道接收清单文件更新消息”的构思。D1建立的仅为传输媒体段数据的普通HTTP Session。

#### (2) 对比文件 D2（WO2011136496A2）

* **特征A**：段落 [p13]、[p18]、[p517] 明确公开了客户端接收 MPD 文件：“`The content delivery server 505 then sends the client 503 the MPD#1 file...`”。因此，D2**实质公开了特征A**。

* **特征B**：段落 [p03] 记载“`information on the content related to a playback time and bandwidth for the segments of the content`”，段落 [p519] 记载“`the client 503 connects the individual segments of the content to Uniform Resource Locators (URLs)`”。因此，D2**实质公开了特征B**。

* **特征C**：段落 [p507]、[p521] 记载“`live content provision server 507`”（即递送节点）根据URL向客户端发送请求的 segment。因此，D2**实质公开了特征C**。

* **特征D、E、F**：D2的核心发明在于客户端或服务器合并新旧MPD中的可播放段列表（Combined Segments），避免客户端请求不可用的段。当需要更新清单时，依然是客户端在 CheckTime 到达时主动向服务器发送 `MPD update request message`（段落 [p529]-[p531]）。D2未公开任何关于“控制信道建立信息”、“控制信道服务器功能”以及“通过建立的控制信道接收清单文件更新消息”的技术特征。

---

## 二、 最接近对比文件的选择分析

在创造性评估中，选择“最接近的对比文件”需综合考量**技术领域、解决的技术问题、技术方案的重合度以及技术效果的贴合度**。

### 1. 整体技术问题与技术效果对比

* **本专利权利要求1**：

* *技术问题*：在基于HTTP的流式传输（如DASH/HLS）中，传统客户端需要通过轮询（Polling）或定时刷新来获取清单文件（Manifest/MPD）更新，这会导致信令开销大、更新不及时或带宽浪费。本专利旨在实现**网络发起的控制（Network-initiated control）**，通过专门建立的流式传输控制信道，由网络侧主动向客户端推送清单文件更新消息。

* *技术效果*：降低客户端轮询的开销，提高清单文件更新的即时性与精准度，实现网络侧对流媒体传输的高效控制。

* **对比文件 D1**：

* *技术问题*：解决数字广播系统中时移（Timeshift/nPVR）服务受限于本地存储容量的问题，使得客户端能够顺畅访问已播放过的历史直播段。

* *技术效果*：使用户能够随时回看历史节目，并在存储位置变更时正确获取更新后的MPD。

* **对比文件 D2**：

* *技术问题*：解决直播流式传输中，客户端在MPD更新时因不知道哪些段可播放而盲目请求导致资源浪费和播放延迟的问题。

* *技术效果*：通过组合新旧MPD中的可用段列表（Playlist），防止客户端请求不可用的段，从而提高资源利用率并减少播放延迟。

### 2. 分析结论与最接近对比文件的确定

**结论：D1 和 D2 均可作为最接近的对比文件（首选 D1 或 D2）。**

* **理由**：

1. **技术领域完全重合**：D1、D2与本专利均属于“数字广播/IPTV中基于HTTP的自适应流式传输（HTTP Adaptive Streaming / DASH）”技术领域，且均涉及“清单文件（MPD）的更新与分发”以及“客户端与服务器之间的段传输”。

2. **基本架构一致**：D1和D2均完整揭示了本专利的前半部分架构（特征A、B、C），即客户端接收包含段URL信息的MPD清单，并据此从递送节点（Server）获取媒体段。

3. **区别特征相同**：无论选择D1还是D2作为最接近的对比文件，本专利权利要求1相对于D1/D2的区别特征完全相同，即：**技术特征D、E、F**（向客户端提供信道建立信息，建立专门的流式传输控制信道，并**经由该控制信道接收清单文件更新消息**，即从“客户端主动Pull”转变为“网络发起的Push”）。

---

## 三、 无效攻击中的最薄弱技术特征分析

如果基于现有的 D1 和 D2 提起专利无效宣告请求，**本专利权利要求1目前具备较强的稳固性**。

### 1. 最薄弱的技术特征（即专有发明点）

本专利权利要求1中最薄弱、也是最核心的防御特征是：

> **特征 D+E+F 的组合**：即“**向客户端提供信道建立信息 $\rightarrow$ 在客户端与控制信道服务器功能之间建立流式传输控制信道 $\rightarrow$ 经由该控制信道接收清单文件更新消息（网络发起的控制）**”。

### 2. 为什么这是最薄弱（但也是目前最难攻破）的特征？

* **从D1/D2的局限性看**：D1和D2代表了标准DASH（Dynamic Adaptive Streaming over HTTP）协议的**典型客户端拉取（Client-Driven / Pull-based）模式**。在D1和D2中，清单更新完全依赖客户端根据 CheckTime 定时向服务器发起 HTTP GET 请求。

* **从本专利的创新看**：本专利引入了**双通道/双平面机制**——数据通道（用于流式传输段）与控制通道（专门的控制信道服务器，用于推送清单更新）。这种“网络发起/推送（Server-Push / Network-Initiated）”的架构改变了传统的DASH交互模式。

* **在现有的 D1 和 D2 中**：**完全没有被公开**。如果仅凭 D1 或 D2 单独或结合，审查员/审理员极易认定特征D、E、F提供了区别于传统 Pull 模式的技术效果（减少轮询开销、实现实时网络控制），从而认可权利要求1具备创造性（突出的实质性特点和显著的进步）。

---

## 四、 进一步的对比文件检索策略建议

为了成功无效本专利权利要求1，必须打破D1/D2所代表的传统“Pull模式”，寻找**公开了“服务器主动推送清单/控制信息”或“建立独立控制信道进行带内/带外信令传输”**的早期对比文件。

建议采取以下针对性的检索策略：

### 1. 扩充检索关键词组合 (Key Terms Strategy)

针对特征D、E、F（控制信道与网络发起推送），建议采用以下关键词进行逻辑组配：

* **主题词（流媒体/清单文件）**：

`DASH`, `HTTP Adaptive Streaming`, `HAS`, `HLS`, `MPD`, `Manifest`, `Playlist`, `Media Presentation Description`

* **控制信道/网络发起（核心攻破点）**：

* `Control Channel`, `Control Plane`, `Out-of-band`, `Dedicated Channel`, `Control Server`

* `Server Push`, `Network-initiated`, `Network-driven`, `Push Notification`, `WebSocket`, `SSE` (Server-Sent Events), `HTTP/2 Push`

* `Manifest Update`, `MPD Update`, `Dynamic Update`, `Asynchronous Event`

### 2. 重点技术标准与组织文件检索 (Standard Documents Strategy)

专利申请人往往直接将国际标准提案（Contributions）转化为专利。流媒体推送控制信道极有可能出现在标准演进过程中：

1. **3GPP 规范与提案**：

* 重点检索 **3GPP TS 26.247** (Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH))。

* 重点检索 **3GPP MBMS (Multimedia Broadcast/Multicast Service)** 相关的 DASH 传输标准（如 **TS 26.346**），MBMS天然具备网络发起（Push）和控制信道（Control Channel/FLUTE Session）的属性。

2. **MPEG-DASH 标准演进（ISO/IEC 23009）**：

* 检索 MPEG-DASH Part 1 (ISO/IEC 23009-1) 中关于 **MPD Events**、**Inband Events**（带内事件）、**Server Push** 以及 **MPD Update Mechanisms** 的早期提案（2010年—2013年期间）。

3. **DVB (Digital Video Broadcasting) 规范**：

* 检索 **DVB-DASH** (TS 103 285) 或 DVB-IPTV 规范中关于服务器端控制与通知信道的章节。

### 3. 分立特征组合逻辑（结合对比文件攻击）

* **主对比文件（D1 或 D2）**：提供流式传输、清单文件（MPD）、段标识符及递送节点的基本架构（已覆盖特征A、B、C）。

* **辅对比文件（D3）**：寻找一份公开了“在流媒体/DASH系统中使用独立的控制信道/WebSocket/Server-Push机制向客户端推送清单更新或控制信令”的技术文献。

* **结合逻辑（结合公知常识/技术动机）**：

* 引证 D3 说明：在流媒体传输中，为了解决客户端频繁轮询（Polling）清单文件造成的网络负担，本领域技术人员有动机引入控制信道或服务器推送机制（如 WebSocket 或 Dedicated Control Channel）。

* 将 D3 的控制信道技术应用于 D1/D2 的 DASH 架构中，得到权利要求1的技术方案对本领域技术人员而言是显而易见的。

---

**代理师总结建议**：

目前仅凭 D1 和 D2 尚不足以完全拉垮权利要求1的创造性。建议立即启动**第二轮精准检索**，重点锁定 **3GPP MBMS/DASH 结合标准** 以及 **基于 WebSocket/HTTP-Push 的 DASH 清单更新** 相关的早期文献（D3），以此补齐特征 D、E、F 的证据链。

作为一名经验丰富的专利代理师，我针对目标专利权利要求1以及提供的两篇对比文件（D1: EP2391086A2, D2: WO2011159558A1）进行深入的技术特征比对、最接近对比文件分析以及无效策略评估。

---

### 一、 目标专利权利要求1的技术特征拆解与技术内涵解释

**权利要求1**的主题为“用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法”。其核心在于**“网络发起控制（Network-initiated control）”**以及**“通过建立控制信道（Control Channel）来接收清单文件更新消息（Manifest update messages）”**。

1. **特征A（接收第一清单文件）**：客户端/网络侧接收初始的清单文件（如DASH中的MPD文件）。

2. **特征B（其包括一个或多个段标识符和用于定位一个或多个递送节点的位置信息）**：清单文件中包含媒体段的标识（Segment ID/URL）和递送节点（如CDN/HTTP Server）的位置/寻址信息。

3. **特征C（所述一个或多个递送节点被配置成向所述至少一个客户端发送与所述一个或多个段标识符相关联的一个或多个段）**：递送节点负责向客户端传输具体的媒体段数据。

4. **特征D（向客户端提供信道建立信息）**：网络侧向客户端下发建立专门控制信道所需的信道建立参数/信息。

5. **特征E（基于所述提供的信道建立信息，在所述至少一个客户端和与所述递送节点相关联的控制信道服务器功能之间建立至少一个流式传输控制信道）**：客户端根据接收到的信道建立信息，与控制信道服务器功能（Control Channel Server Function）建立起**专门的流式传输控制信道**。

6. **特征F（所述至少一个客户端被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息）**：清单文件的更新（Manifest Update）不是由客户端主动轮询（Polling）拉取，而是通过该**专门建立的控制信道**由网络侧/服务器主动推拉或传输更新消息（网络发起控制）。

---

### 二、 对比文件原文详细比对与公开情况分析

针对两篇对比文件：

* **D1**：EP2391086A2（*Method and apparatus for playing live content*）

* **D2**：WO2011159558A1（*MEDIA PRESENTATION DESCRIPTION DELTA FILE FOR HTTP STREAMING*）

#### 1. 特征比对表格（对照对比文件原文及出处）

---

### 三、 最接近对比文件的确定与技术问题/效果分析

#### 1. 整体解决的技术问题与技术效果对比

* **目标专利**：旨在解决传统HTTP流式传输中客户端频繁轮询（Polling）更新清单文件导致的开销大、响应延迟高以及缺乏网络侧主动控制的问题；通过建立专门的**控制信道（Control Channel）**，实现**网络发起的控制（Network-initiated control）**及清单更新消息的主动下发。

* **D1 (EP2391086A2)**：主要解决直播流媒体中，客户端请求过期/不可用片段导致资源浪费和播放卡顿的问题。其技术方案是服务端合并新旧MPD片段列表，客户端基于CheckTime定时主动拉取（GET）新MPD。属于典型的**客户端拉取（Client-driven/Polling）模式**。

* **D2 (WO2011159558A1)**：主要解决HTTP Streaming中MPD文件频繁更新（如每10秒）占用大量网络带宽的问题。为了解决带宽和效率问题，D2不仅提出了Delta File增量更新方案，还进一步提出了**网络推送（Push）与订阅/通知（SIP SUBSCRIBE/NOTIFY, XDCP, XCAP）机制**。

#### 2. 最接近对比文件的选择结论

**最接近的对比文件首选：D2 (WO2011159558A1)**

* **理由**：

1. **技术领域与应用场景相同**：均涉及HTTP流式传输中的清单文件（MPD）更新控制。

2. **技术特征覆盖度最高**：D2在段落[0038]–[0041]中明确提出了从“客户端控制（Client controlled）”转向“服务器/网络推送控制（Server push / Subscription-notification）”的演进方案，公开了基于SIP/XDCP等协议建立控制/订阅信道，并向客户端推送清单更新（Delta文件或更新消息）的全套架构。这与目标专利的“网络发起控制”和“流式传输控制信道”构成了完全相同的技术思路。

3. **技术问题与效果重合**：二者均试图减少客户端盲目轮询的开销，提高清单文件更新的即时性与传输效率。

*(注：D1仅能作为背景技术对比文件或组合对比文件，用以补充媒体段传输与传统MPD处理的基础特征。)*

---

### 四、 无效分析：区别特征与最薄弱技术特征

#### 1. 区别特征分析（以D2为最接近对比文件）

以D2（WO2011159558A1）为主对比文件进行比对：

D2已经公开了特征A、B、C、E、F。

* D2段落[0041]公开了MPD中可以包含指示符（Indicator），指示服务器支持推送到客户端、使用XCAP或订阅/通知模型。

* 特征D（“向客户端提供信道建立信息”）在D2中体现为：MPD中包含的订阅/通知指示符或服务器相关控制节点Endpoint信息。

若目标专利在说明书中将“信道建立信息”进一步限定为**非常具体的信道参数（如特定Websocket URL、专用TCP端口绑定、或者具体的控制信道Token/密钥）**，或者目标专利的控制信道是绑定在特定的递送节点（Delivery Node）架构之上的，则特征D和E可能构成微小的字面区别。

#### 2. 最薄弱技术特征评估

目标专利权利要求1中**最薄弱的技术特征为：特征D（向客户端提供信道建立信息）与特征E（建立流式传输控制信道）**。

* **薄弱原因**：

在流媒体标准（如3GPP PSS, MPEG-DASH, OIPF）演进过程中，引入Push机制（如基于WebSocket, Server-Sent Events (SSE), 或 SIP/OMA Push）来替代Pull机制是本领域的公知常识或显而易见的演化趋势。D2段落[0038]–[0041]已经明确指出了利用SIP:SUBSCRIBE/NOTIFY、XDCP、XCAP等通用控制协议由服务器向客户端推送MPD更新。

因此，只要本领域技术人员为了实现网络侧主动控制，在D2的基础上引入公知的信道建立握手过程（即下发信道建立信息），该特征极易被认定为**不具备创造性（公知常识叠加或显而易见的协议选型）**。

---

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

为了彻底击垮目标专利权利要求1（以及可能存在的从属权利要求），建议采取以下进一步检索策略：

1. **聚焦DASH Push / Websockets 标准提案（3GPP / MPEG-DASH）**：

* **背景**：目标专利的技术方案高度契合MPEG-DASH标准中关于“Server Push”以及“MPD Update via Event Stream / Control Channel”的讨论。

* **检索方向**：重点检索 2011年~2013年期间（注意要在目标专利申请日之前）3GPP TSG SA WG4 (SA4) 和 ISO/IEC JTC1/SC29/WG11 (MPEG) 的会议文稿（Tdocs / Standard Contributions）。

* **关键词组合**：

* `("HTTP Streaming" OR "DASH" OR "MPD") AND ("Push" OR "Control Channel" OR "WebSocket" OR "SSE" OR "Server-sent events")`

* `("Manifest update") AND ("Channel establishment" OR "Subscription")`

2. **追溯网络协同流式传输（Network-Assisted Streaming / SAND）文献**：

* 重点检索DASH-SAND (Server and Network Assisted DASH, ISO/IEC 23009-5) 早期Draft和专利族。该标准专门定义了DASH Client与Network/Server之间的DANE (DASH Aware Network Entity) 控制信道。

3. **扩展检索Websocket / SIP 实时控制信道结合流媒体的相关专利**：

* **分类号（IPC/CPC）推荐**：

* `H04L 65/60` (Media streaming)

* `H04L 65/1066` (Session establishment)

* `H04L 67/55` (Push-based services)

* `H04L 67/02` (Protocols based on HTTP)

* **组合检索**：检索在2012年前后公开的，关于利用长连接控制信道（Push Channel）实时下发Playlist/Manifest更新的各类CDN及视频流控专利。

在对涉案专利权利要求1进行深入的无效宣告请求（Invalidation）技术分析时，需要严格以权利要求为准绳，将各技术特征与对比文件（D1-D3）进行逐一比对。以下是针对权利要求1的特征比对、最接近的现有技术分析、最薄弱特征评估以及后续的检索策略规划。

### 一、 权利要求1技术特征拆解与对比文件公开情况分析

以下分析基于提供的对比文件：

* **D1**: WO2011038034A1

* **D2**: WO2011054377A1

* **D3**: US20110173345A1

#### 1. 技术特征映射与原文出处

**技术特征A：接收第一清单文件**

* **D1 公开**：D1中公开了Media Presentation Description (MPD)，即清单文件。原文出处：`[0066]` "A media presentation description may be provided to an HTTP streaming client..."

* **D2 毫无异议公开**：D2公开了描述性文件（descriptive file）。原文出处：`[0050]` "In step 610, a descriptive file of a stream is received... For example, the descriptive file may be a playlist file in accordance with the HTTP live streaming protocol."

* **D3 公开**：D3公开了流清单（Stream Manifest）。原文出处：`[0035]` "...the HTTP proxy 312 starts the streaming process by retrieving a 'Stream Manifest'..."

**技术特征B：其包括一个或多个段标识符和用于定位一个或多个递送节点的位置信息**

* **D1 公开**：MPD包含段的URI。原文出处：`[0227]`及`[0247]` "FileURIPattern: A pattern used by the Client to generate Request messages for files... The base URI may be an HTTP URI."

* **D2 毫无异议公开**：描述性文件包含用于单播交付的数据段的交付源标识符（如URI）。原文出处：`[0019]` "The descriptive file 100 comprises a list 110 of delivery source identifiers for unicast delivery of the data segments 210... the delivery source identifiers have the form of URIs or of URLs."

**技术特征C：所述一个或多个递送节点被配置成向所述至少一个客户端发送与所述一个或多个段标识符相关联的一个或多个段**

* **D1, D2, D3 均毫无异议公开**。例如 **D2** 原文出处：`[0019]` "...a streaming client may send a HTTP request with the delivery source identifier and, in response to the request, receive the data segment 210 corresponding to this delivery source identifier."

**技术特征D：向客户端提供信道建立信息**

* **D2 实质公开**：D2公开了在描述性文件中提供广播指示符，该指示符包含建立/接收广播频道的访问信息（如端口号、组播地址），这等同于信道建立信息。原文出处：`[0020]` "...the broadcast indicator 120 also includes access information for the broadcast delivery, e.g. an identifier of a broadcast channel and/or parameters needed to receive the broadcast channel such as a port number or a multicast address."

**技术特征E：基于所述提供的信道建立信息，在所述至少一个客户端和与所述递送节点相关联的控制信道服务器功能之间建立至少一个流式传输控制信道**

* **D2 实质公开**：客户端基于上述端口或多播地址建立并接收广播频道，该频道独立于单播数据通道，起到了控制与元数据更新的作用。原文出处：`[0021]` "The broadcast delivery may be established using a broadcast channel which can be received by a plurality of mobile terminals..."

* **D3 实质公开（结合参考）**：D3明确提出了在HTTP代理和客户端之间建立单独的“控制信道”（control channel）的概念。原文出处：`[0045]` "In addition, preferably the HTTP proxy process supports a control channel by which the client can make any combination of various requests against an active stream..."

**技术特征F：所述至少一个客户端被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息**

* **D2 毫无异议公开**：客户端通过上述建立的广播频道（相当于流式传输控制信道）接收更新后的描述性文件（即清单文件更新消息）。原文出处：`[0036]` "As mentioned above, the descriptive file of the stream may be included in the broadcast delivery as well. Accordingly, the streaming client of the mobile terminal 380 may receive an updated version of the descriptive file using the broadcast delivery."

---

### 二、 特征比对表格

---

### 三、 最接近的现有技术分析与创造性评述

**最接近的现有技术：D2 (WO2011054377A1)**

* **选择理由（从整体解决的技术问题与技术效果角度）**：

本专利权利要求1的核心发明点在于：为了解决流媒体传输中清单文件（Manifest）的动态更新问题，避免客户端频繁通过HTTP拉取（Polling）导致服务器过载，引入了独立的“流式传输控制信道”来推送/接收清单更新。

D2 试图解决完全相同的技术问题（避免大量客户端频繁请求清单文件更新导致网络资源浪费）。D2 的解决方案是在初始清单文件（Descriptive file）中提供建立新通道的参数（多播地址/端口），客户端借此建立额外的广播通道（Broadcast channel），并通过该通道接收清单文件的更新版本（`[0036]`段）。两者在解决的技术问题、技术手段及技术效果上高度一致。D2 作为最接近的现有技术，在无效宣告请求中具有极高的杀伤力。

* **没有被最接近的现有技术公开的特征及其他对比文件补强**：

权利要求1中唯一可能被认为未被D2完全字面公开的特征是术语“**流式传输控制信道 (streaming control channel)**”。D2称之为“广播信道 (broadcast channel)”。然而，D3 (`[0045]`) 中明确教导了在基于HTTP的流媒体架构中，在客户端和代理服务器之间建立带外的“控制信道（control channel）”的常规技术手段。

**创造性攻击逻辑**：D2已经实质公开了所有物理步骤和逻辑流程。若专利权人争辩D2的“广播信道”与本专利的“控制信道”不同，无效请求人可结合 D2 与 D3 提出组合攻击：本领域技术人员在D2公开了通过额外信道下发清单更新的基础上，结合D3中在流媒体系统中建立专用“控制信道”的教导，将该额外信道命名或具体化为控制信道，是显而易见的常规技术选择，不具有突出的实质性特点和显著的进步。

---

### 四、 最薄弱的技术特征评估

若提出无效宣告请求，**特征A、B、C** 是最薄弱的技术特征。

这三个特征描述的是标准的自适应HTTP流媒体（Adaptive HTTP Streaming / DASH）的基础架构，即“获取Manifest -> 解析URL -> 请求段”。D1、D2、D3对这三个特征均构成了毫无异议的完全公开，专利权人在答复时绝对无法在这三个特征上进行限缩或辩护。

真正的争议焦点将完全集中在 **特征D、E、F** 的联动机制上。D2的存在使得专利权人极难在此处构筑有效的防线，因为D2完全公开了“下发参数 -> 建立额外通道 -> 通过额外通道接收清单更新”的完整闭环。

---

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

为确保无效请求的万无一失，除了利用D2作为主证，还应通过以下策略检索更外围或更直击字面的现有技术：

1. **标准化组织提案检索（重点）**：

* 目标：3GPP SA4 (PSS / DASH) 和 IETF (HTTP Streaming / RTSP) 在2010-2011年间的草案和会议记录。

* 关键词：`MPD update` AND `out-of-band` AND (`control channel` OR `WebSocket` OR `SIP` OR `dedicated connection`)。

* 目的：寻找在DASH标准制定早期，提议使用带外控制信道（而不是目前标准的带内EventStream或定期轮询）来推送MPD更新的提案。

2. **美国专利及专利申请检索（扩展分类号）**：

* IPC / CPC 组合：H04L 65/60 (Streaming), H04L 65/4084 (Adaptive Streaming), H04N 21/84 (Metadata/Manifest).

* 关键词组合：(`manifest` OR `playlist` OR `MPD` OR `descriptive file`) AND `update` AND (`control channel` OR `signaling channel` OR `out of band`) AND `setup` AND `streaming`.

3. **针对“信道建立信息（Channel Establishment Information）”的精细检索**：

* 寻找那些使用RTSP (Real Time Streaming Protocol) 思维来改造HTTP Streaming的早期文献。在RTSP中，SETUP阶段会协商控制信道和数据信道的端口。检索试图在HTTP体系中复用类似RTSP SETUP信令机制以接收元数据更新的专利（优先日为2010-2012年间）。

根据权利要求1的方法，其中；响应于在客户端处接收所述第一清单文件而建立至少一个流式传输控制信道。

根据权利要求1的方法，包括；针对至少一个清单文件更新消息而监视所述流式传输控制信道。

根据权利要求1或2的方法，包括；检测清单文件更新消息；响应于检测到所述清单文件更新消息而获取第二清单文件的至少部分。

根据权利要求4的方法，进一步包括；基于所述第二清单文件而请求段流或文件。

根据权利要求1的方法，其中所述第一清单文件包含至少部分所述信道建立信息。

根据权利要求6的方法，所述信道建立信息包括用于定位网络中的所述控制信道服务器功能的服务器位置信息。

根据权利要求7的方法，所述服务器位置信息为至少一个URL。

根据权利要求1的方法，其中所述清单文件更新消息包括第二清单文件的至少部分或者其中所述清单文件更新消息包括用于定位和请求所述第二清单文件的至少部分的清单文件位置信息。

根据权利要求9的方法，所述清单文件位置信息为至少一个URL。

根据权利要求1的方法，其中所述分段内容基于流式传输协议而被递送到所述至少一个客户端；和/或，其中所述流式传输控制信道基于WebSocket协议、SIP协议、XMPP协议和/或其组合而被建立。

根据权利要求11的方法，所述流式传输协议为基于HTTP的流式传输协议或其派生物。