一种用于使能段经由网络到内容处理设备（106）中的基于HTTP的自适应流式传输客户端（104）的低等待时间流式传输的方法，所述客户端被配置成基于清单文件从服务器系统请求和接收段，所述方法包括；所述网络中的监视系统（128）收集与所述客户端与所述服务器系统中的一个或多个流式传输服务器之间的一个或多个流式传输路径相关联的质量度量；并将所述质量度量存储在所述网络中的质量数据库（132）中；为内容处理设备提供所述存储的质量度量的至少一部分或提供基于所述存储的质量度量的至少一部分而确定的服务质量信息；基于所述质量度量的至少一部分或所述服务质量信息，所述内容处理设备中的配置模块配置所述内容处理设备中的缓冲器和/或所述内容处理设备中的段请求功能。

针对您提供的权利要求1以及两份对比文件，我作为一名经验丰富的专利代理师，为您进行深度的专利侵权与创造性（无效风险）分析。

首先需要说明的是，经过对两份对比文件的文本核对，**对比文件1（US20110093605A1）与对比文件2（TW201141156A）为同一专利家族**（均要求了相同的美国临时申请 61/252,721 的优先权，且图表、技术方案和文字表述高度一致，分别为主申请和台湾对应案）。因此，下文将二者合并或并行进行特征比对。

---

## 一、 权利要求特征比对分析

权利要求1可以拆解为A、B、C、D、E五个技术特征。以下是针对对比文件1（D1: US20110093605A1）和对比文件2（D2: TW201141156A）的详细特征比对。

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

---

## 二、 最接近对比文件（D1/D2）的选定与分析

在创造性无效宣告程序中，**D1（US20110093605A1）** 或 **D2（TW201141156A）** 均非常适合作为**第一最接近的对比文件（共同构成本案的最接近现有技术）**。

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

* **本案**：解决基于HTTP的自适应流媒体传输（如DASH/HLS）中，如何在低延迟（Low Latency）流传输下，合理配置终端的缓存和片段请求，避免播放卡顿或延迟增大。

* **D1/D2**：同样聚焦于无线网络下HTTP自适应媒体流传输。其核心解决的是当移动终端位置、速度发生变化或网络拥塞时，流媒体可能会中断、延迟增大（*“increase latency of data packets”*）或质量下降的问题。

* **结论**：两者处于完全相同的技术细分领域，面对的都是“如何在变动的网络环境下通过自适应调节优化基于段的HTTP流媒体播放体验”这一技术问题。

### 2. 技术效果与手段的相似性

本案通过获取流传输路径的质量度量来配置终端的“缓冲器”和“段请求功能”；D1/D2同样是通过监测网络带宽、延迟、SNR等参数，利用自适应流管理器（Adaptive Stream Manager）来动态调整请求段的比特率（*“dynamically adjust the bitrate”*）并调节媒体缓冲器（*“media buffers 334”*）。手段与效果高度重合。

---

## 三、 区别技术特征与“最薄弱”特征分析

经过上述比对，本案权利要求1相对于最接近对比文件（D1/D2）的**区别技术特征**主要集中在**特征B**和**特征C**，即**“网络侧监测架构”**：

1. 本案是由**“网络中的监视系统”**收集路径质量，而D1/D2是由**“终端侧/客户端”**收集；

2. 本案将质量度量存储在**“网络中的质量数据库”**中供内容处理设备获取，而D1/D2主要存储在**“终端本地的闪存”**中。

### 提出无效请求时，本案“最薄弱”的技术特征：特征D & 特征E

如果我们要向专利局提起无效宣告，**绝对不要**把主攻方向放在特征A、D、E上，因为它们已经在现有技术中被完全“剿灭”了。

* **特征A与E（极度薄弱）**：D1/D2已经全盘公开了基于清单文件的HTTP分段自适应流操作，以及利用该信息去配置请求功能和缓冲器的全套闭环。这部分没有任何创造性可言。

* **特征D（高度危险）**：虽然本案是从网络侧数据库提供给设备，但D1在[0039]中公开的“将数据传上网络服务器，服务器分析后将摘要（Summary）发回给终端”这一交互流向，已经与特征D的“网络向内容设备提供基于存储的质量度量确定的服务质量信息”在逻辑上形成了高度的实质性等同。

---

## 四、 针对区别特征的进一步对比文件检索策略

由于D1/D2在端侧自适应上做到了极致，但缺少**“网络侧主动监测流媒体传输质量并建立中心数据库供终端查询”**的架构特征。为了成功无效权利要求1，我们需要检索**第二对比文件（D3）**来与D1/D2进行组合（即采用 D1/D2 + D3 的标准创造性组合攻击）。

以下是为您量身定制的进一步检索策略：

### 1. 检索核心方向（针对特征B和C）

需要寻找公开了以下架构的现有技术：

* 运营商网络或CDN网络侧的网管系统（NMS）、性能监测服务器（Performance Monitoring Server），主动收集网络链路的QoS/QoE度量。

* 在网络侧建立集中的质量数据库（例如网络地理位置质量图谱、基站/流媒体服务器路径质量数据库）。

* 允许终端流媒体客户端在发起播放或切换流媒体时，向该网络侧数据库发起查询，以获取当前路径的QoS信息，从而指导终端初始化或调整自身的Buffer大小和首包请求策略。

### 2. 关键词与分类号组合逻辑

* **技术核心词**：

* 网络侧/服务器侧监测：*Network-side monitoring, Network monitor, CDN analytics, Base station probe, QoS server*

* 质量数据库/地图：*Quality database, Channel quality map, Radio environmental map (REM), QoS/QoE repository*

* 自适应流媒体配合：*DASH, HTTP adaptive streaming, Client buffer configuration, Low latency*

* **建议IPC/CPC分类号**：

* **H04L67/63**（针对网络服务请求的路由或目的选择——非常契合根据路径质量选择流媒体服务器或段）

* **H04L43/08**（网络状况的评估监控，如丢包、延迟、带宽监测）

* **H04N21/24**（流媒体服务器侧的监测）及 **H04N21/442**（流媒体客户端侧的监测与配合）

### 3. 目标寻检方向

建议重点检索 **2009年~2013年期间**（与D1同时代或稍晚，正是4G/LTE早期自适应流媒体技术爆发期）关于 **CDN自适应调度** 或 **3GPP规范中有关网络辅助自适应流媒体（如3GPP SAND - Server and Network Assisted DASH 技术的早期雏形提案）** 的专利。这类技术通常是由网络侧（如DASH Aware Network Element, DANE）收集网络QoS并存储，然后下发给终端配置缓冲器，只要捞到一篇这样的D3，配合现有的D1/D2，即可给本案的权利要求1致命一击。

作为一名经验丰富的专利代理师，我将针对目标专利“权利要求1”结合三份对比文件进行深度解释、特征比对、最接近对比文件分析以及无效请求策略与检索策略的制定。

### 目标权利要求理解与技术解释

目标专利权利要求1涉及**基于HTTP的自适应流式传输（DASH等标准常用技术）中，如何在保证低等待时间（Low-latency）的同时优化缓冲与流切换控制**。

* **技术特征A** 明确了应用场景为客户端通过“清单文件”（如DASH中的MPD或HLS中的M3U8）向服务器请求段（Segments）。

* **技术特征B、C、D** 构建了一个网络侧的闭环监控架构：由**网络中的监视系统**收集各流式传输路径的质量度量，存入**网络中的质量数据库**，并**反馈给内容处理设备（客户端侧）**。

* **技术特征E** 是控制的落脚点：客户端的配置模块基于上述网络反馈的质量度量或QoS信息，**配置缓冲器和/或段请求功能**（例如调整缓冲区大小或改变请求下一个分段的码率选择逻辑）。

---

## 一、 对比文件特征比对分析

三份对比文件的基本公开信息如下：

* **D1 (US20060109856A1)**：《Method and apparatus for adaptive buffering》，公开日：2006-05-25。

* **D2 (JP2008527765A)**：D1的同族日本专利，技术内容与D1高度一致。

* **D3 (US20110066673A1)**：《DYNAMIC STREAM SWITCH CONTROL》，公开日：2011-03-17。

### 1. 技术特征毫无异议公开（明示公开）或实质公开分析

#### 对比文件1 (D1: US20060109856A1) 与 对比文件2 (D2: JP2008527765A)

D1与D2为同族专利，以下统一以D1/D2表述。

* **技术特征A（自适应流请求）**：D1/D2公开了根据不同传输速率R或网络媒体特征自适应调整缓冲，主要基于**RTSP/RTP/RTCP/SDP协议**（参见D1 `[0005]`，D2 `[2]`第4段）。然而，其并未**明示公开“基于清单文件”**这一特定于基于HTTP自适应流（HAS）的特征。属于**实质公开了自适应流传输请求**，但未毫无异议公开“基于清单文件”这一具体手段。

* **技术特征B（监视系统收集质量度量）**：D1/D2公开了“服务器端12包含网络监视器60……监视连接21的 packet jitter 和 packet delay，和/或接收来自渲染端24的反馈”（参见D1 `[0037]`，D2 `[2]`第15段）。这毫无异议地公开了**监视系统收集流式传输路径的质量度量**。

* **技术特征C（质量数据库存储）**：D1/D2虽然提到了服务器端有内存17或处理器14，但其网络监视器60仅用于动态调整或交互，**未公开“将所述质量度量存储在网络中的质量数据库中”**这一特征。

* **技术特征D（为设备提供质量信息）**：D1/D2公开了服务器与客户端之间通过交换缓冲参数消息（例如SDP响应52、RTSP播放响应56或RTSP控制信令）来通知渲染端当前网络适配的参数（参见D1 `[0024]-[0027]`）。实质公开了为内容处理设备提供基于质量度量确定的服务质量/缓冲信息。

* **技术特征E（配置缓冲器/段请求）**：D1/D2明确公开了“渲染端24中的处理器32根据从服务器接收到的适配缓冲参数变更为与缓冲器26相关的缓冲参数”（参见D1 `[0018]`，D2 `[2]`第7段），且通过改变传输速率R来影响媒体段请求（参见D1 `[0040]`）。**毫无异议公开了配置缓冲器和段请求功能**。

#### 对比文件3 (D3: US20110066673A1)

* **技术特征A（自适应流请求）**：D3公开了一种通过控制动态流版本切换来连续显示多媒体的技术。它提到“客户端应用160通过向流媒体服务器110发起一次或多次调用125来排队内容流以供客户端播放”（参见`[0045]`），同时提到了采用**HTTP协议**（参见`[0040]`）。虽然D3提到了播放列表（Playlist）的概念（参见`[0006]`, `[0039]`, `[0065]`），但其更侧重于传统的流媒体调用，对于严格意义上HAS（基于HTTP自适应流）由客户端通过解析清单文件主动发起段请求的架构，属于**实质公开**。

* **技术特征B（监视系统收集质量度量）**：D3公开了“在事件监控170期间，播放器150可以监视和/或访问各种客户端条件……例如网络带宽、客户端缓冲区容量、丢帧率……”（参见`[0049]`）。注意，D3是在**客户端播放器**进行这种收集，属于**客户端自收集**，而目标专利要求的是**网络中的监视系统收集**。因此，D3未完全公开在“网络中的监视系统”进行收集的架构特征。

* **技术特征C（质量数据库存储）**：D3未公开在网络中设置独立的质量数据库来存储这些质量度量。

* **技术特征D（为设备提供质量信息）**：由于D3的监控本就发生在客户端内部（播放器150向应用160提供事件监控结果，参见`[0051]`），它不涉及“网络侧向内容处理设备提供”这一方向性特征。

* **技术特征E（配置缓冲器/段请求）**：D3的核心就在于切换锁（Switching Lock）控制，防止升档或降档循环。其公开了“访问与流内容关联的客户端缓冲区，并根据缓冲区输出决定是否激活切换锁”（参见`[0011]`）以及“向服务器发送动态变更流版本的请求”（参见`[0055]`）。这**毫无异议公开了基于质量度量/信息配置缓冲器和段请求功能（流版本切换控制）**。

---

### 2. 特征比对表格

---

## 二、 最接近的对比文件（D1/D2）判定及理由

在创造性分析过程中，**对比文件1 (US20060109856A1) / 对比文件2 (JP2008527765A)** 适合作为**最接近的对比文件**。

### 理由分析：

1. **技术领域与解决的技术问题最契合**：

目标专利旨在解决流媒体在网络传输中，如何根据网络传输路径的质量动态调整客户端的缓冲和段请求，以实现低等待时间、高平滑度的自适应流式传输。

* **D1/D2** 同样聚焦于解决由于网络干涉、交叉流量导致 packet jitter（数据包抖动）和延迟大幅度波动时，如何使服务器端与渲染端**协同进行自适应缓冲（Adaptive Buffering）调整**，防止解码缓冲区发生 Underflow（欠幅）或 Overflow（过幅）（参见D1 `[0004]-[0005]`）。这与目标专利从网络宏观到客户端微观的控制闭环完全一致。

* 相比之下，**D3** 解决的具体技术问题更加偏向客户端单侧的控制逻辑——防止因客户端CPU/处理资源不足与网络带宽不匹配时，所导致的“流版本频繁升降档切换的死循环”（参见D3 `[0020]-[0023]`）。

2. **技术特征覆盖率最高（整体架构最接近）**：

目标专利采用的是**“网络侧监视 $\rightarrow$ 反馈给客户端 $\rightarrow$ 客户端配置缓冲和请求”**的宏观协同架构。D1/D2 刚好公开了由网络侧（服务器端/网络监视器60）进行路径参数（抖动、延迟）收集，再发送给客户端配置缓冲器（处理器32配置缓冲器26）的全套闭环特征（包含特征B、D、E）。而 D3 的信息流完全是客户端本地自闭环，缺乏“网络侧监视系统收集并反馈”的架构基础。

因此，选择 **D1（或其同族D2）** 作为创造性评述的起点（主申引）最为合适。

---

## 三、 无效请求策略与最薄弱特征分析

### 1. 被留白的特征（非最接近对比文件公开特征）的补盲分析

最接近对比文件 D1/D2 未能公开的特征主要为：

* **特征A中的“基于清单文件请求段”**

* **特征C中的“存储在网络中的质量数据库中”**

对于**“基于清单文件请求段”**，**D3** 在一定程度上给予了补盲（公开了基于 HTTP 且利用播放列表 Playlist 进行流分段控制的架构）。而在 2011-2016 年间，基于 HTTP 的自适应流媒体（如规范化的 3GPP DASH、MPEG-DASH）普遍采用 XML 格式的清单文件（MPD）来描述段 URL，这是本领域流媒体工程技术的公知常识/常规技术手段。

对于**特征C“存储在网络中的质量数据库中”**，三份对比文件均未**直接明示**公开。

### 2. 提出无效请求时“最薄弱的技术特征”

本权利要求中，**最薄弱（即最容易被攻破、创造性最低）的技术特征是：特征E（基于QoS信息配置缓冲器/段请求功能）**。

* **原因**：无论是老一代的 RTSP 流媒体（D1/D2）还是新一代的 HTTP 切换流媒体（D3），只要网络条件或服务质量（QoS）发生变化，客户端**必然**需要调整缓冲深度（防止卡顿）或调整段请求（换用低码率或高码率段）。这属于流媒体自适应传输技术的核心本能。D1 明确给出了调整缓冲参数 $B$ 和 $F$ 的方案，D3 明确给出了调整段请求（码率升降档限制）的方案。在创造性答辩中，这一特征几乎无法为目标专利提供任何实质性的“显著的进步”。

### 3. 最强防线（权1中最具创造性的抗辩点）

相反，目标专利据以稳定权的骨架在于**“特征C：将所述质量度量存储在所述网络中的质量数据库中”**配合**特征B的“网络中的监视系统收集”**。对比文件均偏向点对点（单个Server到单个Client）的会话级监控，而目标专利明确提出了在网络中设置**独立的监视系统**与**质量数据库**，这意味着它可以收集跨用户、跨路径的宏观质量度量，并以此为依据反哺给具体的设备进行微观配置。

---

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

为了彻底无效掉权利要求1，必须针对上述“最强防线”（特征B+特征C的网络侧集中式质量监测与反哺架构）进行精准补盲检索。

### 1. 检索核心要素组合（Focus）

基于 HTTP 自适应流（DASH/HLS）+ 网络侧公共监视（Network-based/Server-assisted Monitoring）+ 质量数据库/中心化服务器（QoS/QoE Database/Repository）+ 客户端缓冲/码率控制。

### 2. 分步检索策略

* **第一步：追踪标准演进（3GPP / MPEG-DASH 专题）**

目标专利提及“基于清单文件请求段”和“低等待时间流式传输”，这带有强烈的 **3GPP 5G 媒体流（5GMS）** 或 **MPEG-DASH Server-Directed / Server-Assisted Streaming (SAND)** 标准背景。

* **重点检索**：3GPP TS 26.247 (DASH)、3GPP TS 26.512 (5G Media Streaming architecture) 以及 **MPEG-DASH ISO/IEC 23009-5 (SAND - Server Assistance and Network Assisted DASH)**。

* **理由**：MPEG-DASH SAND 标准专门定义了网络侧元素（DANE - DASH Aware Network Element）收集流路径质量，利用通过网络交互或中心缓存，向客户端（DASH WIC）提供网络QoS指导信息，以供客户端配置缓冲和请求。如果能检索到 SAND 标准的早期提案（2014-2016年前后），可直接以公知常识或单篇全文公开直接摧毁特征B+C+D+E的组合创造性。

* **第二步：关键词与分类号交叉检索（专攻特征C）**

* **IPC/CPC分类号**：`H04L65/61`（流媒体网络传输）、`H04L43/08`（网络监视/质量度量）、`H04L67/10`（中心化存储/网络数据库）。

* **关键词组合**：`(DASH OR "adaptive streaming" OR "http streaming") AND (monitor* OR quality OR QoS OR QoE) AND (database OR repository OR store*) AND (buffer* OR "request function" OR rate-adaptation)`。

* **第三步：目标转到早期 CDN (内容分发网络) 调度专利**

很多 CDN 厂商（如 Akamai、Limelight）或网络设备商（如思科、华为）在 2015 年前申请了大量关于“从全网探测节点收集链路质量（Quality Metrics），存入云端数据库，再由视频播放器下载该质量图谱用于优化首次缓冲和切片选择”的专利。此类专利是攻破特征C的最佳靶向文件。

作为一名经验丰富的专利代理师，我将紧密结合目标专利（“本专利”）的说明书及对比文件原文，对权利要求1进行精细化的法律与技术特征比对，并为您制定后续的创造性分析与检索策略。

### 对比文件公开号及代称对照表

为确保表述清晰严谨，本分析所使用的对比文件代称与公开号对应如下：

* **D1**：`US20120117225A1` (METHODS AND APPARATUS FOR PROVIDING A MEDIA STREAM QUALITY SIGNAL)

* **D2**：`CN102577312A` (自适应串流多媒体)

* **D3**：`KR1020120083463A` (적응형 스트리밍 멀티미디어)

---

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

根据说明书的逻辑架构，权利要求1被拆解为5个独立的技术特征（A至E）。以下紧密结合对比文件原文及详细出处进行实质比对：

### 1. 对比文件对技术特征的公开情况分析

* **技术特征A**：`一种用于使能段经由网络到内容处理设备（106）中的基于HTTP的自适应流式传输客户端（104）的低等待时间流式传输的方法，所述客户端被配置成基于清单文件从服务器系统请求和接收段，所述方法包括`

* **D1的公开情况**：**实质公开**。D1摘要及段落`[0059]-[0062]`、`[0067]`公开了基于TCP/HTTP的动态自适应流媒体（ABR），将视频切分为独立的段（segments），客户端通过请求不同的段来调整码率。D1图1中的`media client 104`即对应内容处理设备中的客户端。虽然D1文本中直接出现“清单文件（manifest file）”的频次极低，但其明确指出基于`Apple HLS`、`Microsoft Smooth Streaming`等协议架构，这些行业标准自适应流媒体协议在底层必然包含清单文件。

* **D2/D3的公开情况**：**毫无异议公开**。D2/D3（同族申请，以D2中文本为准）段落`[0022]`、`[0027]`极其明确地公开了：“编码器230将多媒体串流…分成可个别地经由HTTP服务器270存取的多个串流片段”、“目录信息清单文件（directory manifest file）280可含有…可用串流位速率的列表。因而，接入媒体服务器110的终端可随网络条件变化而通过请求适宜的串流片段来动态地调整”。这与特征A完全吻合。

* **技术特征B**：`所述网络中的监视系统（128）收集与所述客户端与所述服务器系统中的一个或多个流式传输服务器之间的一个或多个流式传输路径相关联的质量度量`

* **D1的公开情况**：**毫无异议公开**。D1段落`[0017]`、`[0074]`、`[0075]`以及图1明确公开：网络监测设备（`network monitoring device 106`，置于网络110中或inline部署）“检查网络接口上的所有数据包……监测网络和媒体服务器与媒体客户端之间的媒体会话”。收集的质量度量包括重缓冲事件的频率、持续时间（`re-buffering events`）以及码率切换事件（`stream switch events`）。

* **D2/D3的公开情况**：**未公开/实质未公开**。D2/D3段落`[0020]`、`[0025]`、`[0030]`虽然公开了“自适应串流管理器336监视移动终端120和网络状态”，但其明确限定监视的主体是**用户终端自身**（“所述装置监视其自身的参数”，见D2`[0016]`），而不是本专利所限定的“**网络中的监视系统**”。因此，D2/D3未公开由独立的网络侧监视系统收集路径质量度量的架构。

* **技术特征C**：`并将所述质量度量存储在所述网络中的质量数据库（132）中`

* **D1的公开情况**：**实质公开**。D1段落`[0079]`、`[0098]`公开了“DQS/NQS的值在整个会话中被计算和更新，并将该值存储到外部系统（`stored to an external system`，如内存或其他存储设备）”。其在网络侧监测设备中包含存储模块以记录历史KPI和质量度量。

* **D2/D3的公开情况**：**实质未公开**。D2段落`[0035]`、`[0041]`公开了存储模块750，但其明确限定该存储模块是作为移动终端/用户终端的自适应串流管理器336的内部组件（“所述自适应串流管理器336包括……存储模块750”），属于终端本地存储，而非特征C限定的“**网络中的质量数据库**”。

* **技术特征D**：`为内容处理设备提供所述存储的质量度量的至少一部分或提供基于所述存储的质量度量的至少一部分而确定的服务质量信息`

* **D1的公开情况**：**实质未公开**。D1的系统架构（图1、图9、图11）是一个闭环的**网络侧分析/网络侧流媒体优化系统**。D1段落`[0074]-[0076]`、`[0135]`指出的数据去向是：网络监测设备计算出DQS/NQS或KPI报告后，直接输出给外部存储，或者输出给“流媒体优化器（`streaming media optimizer 274`）”以“改变网络上生成的媒体流量特征276”。D1的核心逻辑是由网络侧直接干预流量或者为运营商生成报告，**并没有公开将网络侧收集和计算的质量信息再“提供给内容处理设备（客户端终端）”**，让终端去实施控制。

* **D2/D3的公开情况**：**实质未公开**。因为D2/D3的质量信息本身就是由终端自己收集的（D2段落`[0028]`），不存在“由网络侧提供给终端”的动作流。

* **技术特征E**：`基于所述质量度量的至少一部分或所述服务质量信息，所述内容处理设备中的配置模块配置所述内容处理设备中的缓冲器和/或所述内容处理设备中的段请求功能`

* **D1的公开情况**：**实质未公开**。如特征D所述，D1修改流媒体特征（配置缓冲器或调整请求）的主体是网络侧的优化器（`optimizer 274`），而不是“内容处理设备中的配置模块”。D1的客户端仅被动接受网络流量的改变或基于自身传统算法调整。

* **D2/D3的公开情况**：**实质公开（控制机制）但输入源不同**。D2段落`[0025]`、`[0029]`、`[0030]`公开了“自适应串流管理器336（相当于配置模块）……基于预测的未来参数值，选择目标多媒体特性，向媒体服务器请求具有目标特性的多媒体片段（相当于配置段请求功能）”，并且D2`[0024]`公开了其可以控制媒体缓冲器334。但是，D2这一连串的配置动作，其基础是**终端自身传感器和自身调制解调器监视的信息**（D2`[0028]`），而不是基于“由网络侧存储并提供的服务质量信息”。

---

### 2. 特征比对表格（Feature Matrix）

---

## 二、 最接近对比文件的选择与创造性分析

### 1. 哪个文件适合作为最接近的对比文件（D1 vs D2/D3）？

在创造性分析中，**D1 (`US20120117225A1`) 最适合作为最接近的对比文件（第一最接近对比文件）**。理由如下：

* **从整体解决的技术问题角度分析**：

本专利旨在解决在低等待时间（Low-Latency）流式传输中，如何精准掌握**客户端与服务器之间的整个网络路径（传输路径）的实际质量**，从而避免单靠客户端自身盲目探测带来的滞后性和片面性。

* **D1** 同样聚焦于解决自适应流媒体（ABR）由于客户端“只看得到自己的带宽，无法获知其他共享网络资源的设备情况”而导致“流切换决策次优、引起不必要质量调整”的技术问题（参见D1 `[0068]`）。这与本专利的出发点高度一致。

* **D2/D3** 解决的技术问题是如何利用终端侧的各种传感器（GPS、加速度计等）预测移动状态以主动调整流媒体特性，其本质是**终端侧的自主预测**，并未触及多客户端网络路径统筹拓扑的解决。

* **从技术效果角度分析**：

D1通过在网络侧设置独立的监测系统（inline设备），能够跨设备、客观地评估网络路径的服务质量（NQS/DQS），其实现的技术效果（获得网络路径的全局/宏观服务质量评价）与本专利特征B、C完全同构。

> **结论**：选择 **D1** 作为主要起点最符合审查指南中关于“技术领域相同或相近、解决的技术问题最接近”的原则。

---

### 2. 创造性三步法评述与特征组合

以 **D1** 为最接近的对比文件，本专利权利要求1与之相比，存在的**区别特征**为：

* **区别特征1（对应特征D）**：网络侧将存储的质量度量或确定的服务质量信息**提供给内容处理设备（客户端）**。

* *注：D1中这些数据是截留在网络侧，交给网络侧优化器274处理或生成KPI报告给运营商。*

* **区别特征2（对应特征E）**：内容处理设备的配置模块**基于该收到的来自网络侧的信息**来配置本地缓冲器或段请求功能。

#### 结合D2/D3的组合状态分析：

我们尝试审查是否能将 D2 引入作为结合手段。D2 确实公开了“客户端自适应串流管理器基于某些参数来调适所接收的内容并配置段请求”。

然而，**这种结合存在本质的“技术架构冲突”（技术偏见/阻碍）**：

D2的整套控制理论完全建立在“终端自给自足”的基础上（利用本地GPS、本地加速度计监测，见D2 `[0016]`），其根本没有架设任何“从外部网络侧数据库接收服务质量参数来指导本地流请求”的接口或通信机制。

如果强行将D2的配置模块塞入D1，D1本身并不具备向终端下发质量数据的通路（特征D缺失），D2也不具备接收网络侧宏观路径指标的输入端。因此，**D1 + D2 的简单组合无法直接推导出本专利的完整方案，两者的结合存在架构壁垒**。

---

## 三、 无效宣告请求中最薄弱的技术特征

若您代表专利权人进行稳定性评估，或者作为无效请求人寻找突破口，本专利权利要求1中**最薄弱（最容易被攻破或被规避）的技术特征是：技术特征D与特征E的交汇点（即：从网络数据库到内容处理设备的“下发”与“基于下发数据控制”的闭环链路）。**

### 为什么这里最薄弱？

1. **特征B和C已彻底被D1阻击**：在网络侧部署独立监测节点收集流媒体路径指标并存入数据库，在2012年左右（D1的申请日）已经是极其成熟的网络流量深度包检测（DPI）技术。

2. **特征A已被D2/D3等标准文献完全公开**：DASH、HLS自适应流媒体客户端基于Manifest请求Segment是行业公知常识。

3. **最终的防御阵地仅剩“信息架构的流向切换”**：本专利真正的发明点（Contribution）在于打破了D1的“网络侧收集 $\rightarrow$ 网络侧优化器拦截干预”架构，改为了“网络侧收集 $\rightarrow$ **下发给终端** $\rightarrow$ **终端主动配置请求**”的分布式协同架构。

### 潜在的致命威胁：

如果在后续检索中，一旦检索到某篇对比文件（例如某篇早期的3GPP标准业务层规范，或思科/爱立信早期的网络辅助流媒体自适应协议，如 **DASH-SAND (Server and Network Assisted DASH)** 技术的早期雏形提案），公开了“网络元素（NE）或质量服务器向DASH客户端发送QoS拓扑信息或接入网拥塞状态，以供客户端调整其MPD段请求策略”，那么权利要求1将由于所有特征被完全覆盖而彻底丧失创造性。

---

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

鉴于目前的D1与D2在“网络侧下发数据至终端协助自适应请求”这一电路上仍留有空白，为了能够彻底切断其创造性链条，建议采取以下精准检索策略：

### 1. 核心扩展检索方向（精准打击特征D+E）

必须寻找公开了“**网络侧辅助（Network-Assisted）/ 服务器辅助**”的自适应流媒体方案流派。

* **目标技术名词捕捉**：`Network Assisted DASH`、`Server and Network Assisted DASH (SAND)`、`DASH-SAND`、`QoE-driven network feedback`、`Bandwidth guidance from network`、`基站辅助码率自适应`。

* **关键架构寻找**：重点寻找存在从网络侧（如路由器、基站、无线网络控制器RNC、或独立QoE服务器）向终端自适应播放器下发“推荐带宽（Bandwidth Guidance）”、“路径质量度量（Path Quality Metrics）”或“拥塞对流媒体的预警信号”，且终端基于此信号更改Buffer或更改Manifest片段选择的文献。

### 2. 检索分类号与关键词组合建议

* **IPC/CPC分类号定位**：

* `H04L65/61` (Network streaming protocols)

* `H04L65/80` (Responsive to market or environmental conditions, e.g. QoS, QoE)

* `H04L67/10` (Protocols for Client-server architectures)

* **构建布尔检索式（示例）**：

* `(自适应流 OR ABR OR DASH OR HLS) AND (网络侧 OR 监测 OR 路径 OR 服务器辅助 OR 辅助 OR SAND) AND (下发 OR 发送 OR 通知 OR 指导 OR 告知 OR 提供) AND (客户端 OR 终端 OR 内容处理) AND (缓冲 OR 请求 OR 码率)`

* 英文对标：`(adaptive streaming OR ABR OR DASH) AND (network-assisted OR network monitoring OR SAND OR network feedback) AND (provid* OR send* OR downl* OR feedback OR inform*) AND (client OR "processing device" OR player) AND (buffer OR "segment request")`

### 3. 重点机构与文献库推荐

* **重点公司追踪**：思科 (`Cisco`)、爱立信 (`Ericsson`)、高通 (`Qualcomm`)、诺基亚 (`Nokia`)、华为 (`Huawei`)。这些公司在2011-2015年期间针对3GPP LTE流媒体QoE保障及MPEG-DASH标准的制定中有大量关于“网络侧如何向终端反馈QoS以优化流媒体段请求”的专利资产流出。

* **标准文献检索**：前往 **3GPP** 官网检索 `TS 26.247` (Transparent end-to-end Packet-switched Streaming Service; Progressive Download and Dynamic Adaptive Streaming over HTTP) 的演进历史提案（TDocs），特别是寻找关于网络辅助（Network Assistance）的引入讨论页，这类技术报告（TR）或提案往往比正式专利更早实质公开上述最薄弱的通信机制。

作为经验丰富的专利代理师，我将紧密结合目标权利要求1的文本内容，通过与对比文件D1（EP2489167A1）及D2（US20120265856A1）的原文进行逐字逐句的深度解构与特征比对，为您梳理出本案的无效/创造性分析全景图。

---

### 一、 目标权利要求1的全面技术解构与特征拆解

目标权利要求1公开了一种**“低等待时间流式传输的方法”**，其属于典型的基于HTTP的自适应流式传输（如DASH或HLS）的系统架构优化。该权利要求被拆解为以下5个技术特征：

* **特征A（前序部分+基础架构）：** 一种用于使能段经由网络到内容处理设备（106）中的基于HTTP的自适应流式传输客户端（104）的低等待时间流式传输的方法，所述客户端被配置成基于清单文件从服务器系统请求和接收段。

* **特征B（网络侧收集）：** 所述网络中的监视系统（128）收集与所述客户端与所述服务器系统中的一个或多个流式传输服务器之间的一个或多个流式传输路径相关联的质量度量。

* **特征C（存储）：** 并将所述质量度量存储在所述网络中的质量数据库（132）中。

* **特征D（分发/交互）：** 为内容处理设备提供所述存储的质量度量的至少一部分或提供基于所述存储的质量度量的至少一部分而确定的服务质量信息。

* **特征E（客户端配置）：** 基于所述质量度量的至少一部分或所述服务质量信息，所述内容处理设备中的配置模块配置所述内容处理设备中的缓冲器和/或所述内容处理设备中的段请求功能。

---

### 二、 对比文件原文公开情况深度分析

#### 1. 对比文件D1：EP2489167A1 (ADAPTIVELY STREAMING MULTIMEDIA)

* **技术领域与架构：** D1公开了一种在**用户终端（User Terminal）**侧实施自适应流媒体传输的方法。

* **特征A：** 实质公开。D1图2及说明书`[0026]`公开了服务器将源数据切分为多个“流段（stream segments）”，并使用“目录清单文件（directory manifest file 280）”，客户端通过“HTTP服务器270”动态请求段。

* **特征B、C、D（网络侧收集与存储）：** **未公开。**

* *详细出处分析：* 查阅D1说明书`[0008]`、`[0019]`以及`[0029]`，D1明确指出其核心机制是“the device monitors it's own parameters... to adapt the received media content（设备监视其**自身的参数**以自适应接收的媒体内容）”。其监测的参数（如`[0032]`所述的播放器缓冲状态、GPS位置、速度、加速度等）均由用户终端内部的“传感器套件（sensor suite 340）”或本地调制解调器产生并收集（D1图3/图4）。

* *结论：* D1的信息流是**完全本地化（终端内）**的，并不存在一个位于**“网络中的监视系统”**去收集“流式传输路径”的质量度量，更不存在将数据存入**“网络中的质量数据库”**并提供给终端的架构。

* **特征E：** 部分实质公开。D1说明书`[0029]`公开了用户终端内的“自适应流管理器336（adaptive stream manager）”基于监测或预测的参数来请求适当的段（配置段请求功能）。但由于D1缺乏外部网络输入的质量度量，其配置的依据完全不同。

#### 2. 对比文件D2：US20120265856A1 (SYSTEM AND METHOD FOR DATA STREAMING IN A COMPUTER NETWORK)

* **技术领域与架构：** D2公开了一种基于**网络侧节点（缓存服务器Cache Server 14）**评估网络指标，并将比特率提示数据（Bit rate hint data）发送给终端以优化自适应流媒体传输的架构。这与本申请的“网络侧监视+反馈”架构高度契合。

* **特征A：** 毫无疑问公开。

* *出处与原文：* 说明书`[0014]`："Most of the current adaptive streaming technologies use hypertext transfer protocol (HTTP)... Information describing the stream... is generally transferred in a separate file (e.g., in a manifest)." 完全对应基于HTTP、清单文件（Manifest）和段（Chunks/Fragments，见`[0017]`）的流媒体传输。

* **特征B：** 毫无疑问公开。

* *出处与原文：* 摘要、说明书`[0007]`及`[0035]`阐述了由“缓存服务器14（位于网络中）”评估一系列网络指标（Network criteria）："evaluating network criteria associated with characteristics that can affect a bit rate... The network criteria... include a number of requests for particular content upstream... a utilization characteristic associated with the server; a bandwidth characteristic associated with network infrastructure upstream... and load conditions associated with an origin server." 缓存服务器作为网络中的节点，实质上充当了“监视系统”，其收集的正是流式传输路径相关的上游带宽、服务器负载等质量度量。

* **特征C：** 实质公开。

* *出处与原文：* 说明书`[0038]`："For example, cache server 14 may store information about the specific rates at which future fragments are currently cached." 并且`[0048]`明确提及："The network element may include appropriate processors, memory elements [as shown in FIG. 3]... to store data used for the operations described herein." 缓存服务器包含存储器（Memory element 50）用于存储这些用于生成提示的评估数据，在网络侧节点中形成了“质量数据库”的物理实体。

* **特征D：** 毫无疑问公开。

* *出处与原文：* 说明书`[0007]`、`[0012]`及`[0027]`："communicating bit rate hint data, which is based on the network criteria, to the endpoint for consideration in a bit rate request." 以及 "This feedback mechanism can offer rate hints to clients..."。此处向终端提供“比特率提示数据（Rate hint data）”，正是本申请特征D中“提供基于所述存储的质量度量而确定的服务质量信息”的上位概括与下位等同。

* **特征E：** 毫无疑问公开。

* *出处与原文：* 说明书`[0045]`、`[0046]`及图3：终端包含“自适应流客户端模块（adaptive streaming client module 68b）”和“缓冲管理元件（buffer management element 43，见图2）”；"Adaptive streaming client modules can be configured to determine when new rate selections should occur, where bit rate selections can be properly sent to cache server." 终端的客户端模块基于收到的提示数据配置并调整了其比特率请求（段请求功能）。

---

### 三、 技术特征比对表

---

### 四、 最接近的对比文件（D1 vs D2）选择与论证

在创造性分析中，**对比文件D2（US20120265856A1）**明显更适合作为**唯一或最接近的对比文件（主导对比文件）**。

#### 1. 整体解决的技术问题角度

* **目标专利**旨在解决在流媒体传输过程中，如何通过网络侧监视并向客户端提供全局路径的质量度量，从而克服客户端仅凭本地感知无法得知上游网络瓶颈的缺陷，实现更精准的配置调优。

* **D2的技术问题：** 明确指出在传统自适应流中，客户端仅凭本地“看前方缓冲器余量（look-ahead buffer margin）”去盲目降低比特率，有时反而会加重网络或缓存服务器的负担（`[0025]`、`[0026]`）。D2要解决的正是**“如何让网络侧参与评估，向客户端传递其无法感知的上游/全局网络状况（network criteria），从而指导客户端做出智能的流请求决定”**（`[0027]`）。这与目标专利解决的技术问题完全一致。

* **D1的技术问题：** 侧重于用户终端在移动（如上高速公路、进山）时，如何利用**终端自带的传感器**（如加速度计、GPS）预测终端自身的性能变化来调整流媒体质量（`[0020]`），属于纯粹的客户端闭环本地调优，与目标专利的系统架构相去甚远。

#### 2. 技术效果角度

* **目标专利与D2**均达到了相同的技术效果：通过“网络侧监视节点评估数据 $\rightarrow$ 发送提示/质量信息 $\rightarrow$ 客户端改变段请求策略”，实现了降低网络盲目震荡、提高视频质量并降低等待延迟的效果。

**结论：** D2公开了权利要求1绝大部分（甚至全部）的技术特征，且技术领域、解决的技术问题和技术效果均高度相同。因此，**D2是本案最无可争议的“最接近的对比文件”**。

---

### 五、 针对最薄弱技术特征的无效突破点分析

如果选择D2做最接近的对比文件，目标权利要求1在形式上可能仅残存极微弱的微调特征。以下是若要提出无效请求时，目标专利**“最薄弱的技术特征”**以及如何利用D2进行攻破的策略：

#### 1. 最薄弱特征一：特征C中的“质量数据库（132）” vs D2的“存储器（50）”

* **专利可能抗辩点：** 专利权人可能会辩称，D2的缓存服务器14中的 `memory element 50` 只是普通的内存或常规存储组件，并不等同于专职且独立架构的“网络中的质量数据库（132）”。

* **无效攻破策略（实质公开/惯用手段）：** D2在`[0048]`、`[0054]`中明确指出该网络元件包括任何合适的“memory element (database, table, key, etc.)”。将收集到的网络指标序列化存入数据库或数据表中是本领域的惯用技术手段。利用D2的 `memory element 50` 结合常规数据库技术，足以认定该特征已被实质公开或属于显而易见的技术置换。

#### 2. 最薄弱特征二：特征E中的“配置内容处理设备中的缓冲器”

* **专利可能抗辩点：** D2的公开内容中，客户端收到 `rate hint data` 后，主要执行的是“rate selections（比特率选择请求）”，这对应了“配置段请求功能”，但D2是否明确提及了去直接“配置缓冲器（Buffer）”？

* **无效攻破策略（选择性特征阻击）：**

1. **注意权利要求的撰写方式：** 权利要求1在特征E中写的是“配置所述内容处理设备中的缓冲器**和/或**所述内容处理设备中的段请求功能”。在法律层面上，“和/或”意味着只要D2公开了其中**任意一项**（即配置“段请求功能”），就直接覆盖了该技术方案。而D2通过更改比特率选择请求（`[0046]`）已经完全公开了配置“段请求功能”。

2. **结合D2图2进一步阻击：** D2的图2中明确画出了 `buffer management element 43`（缓冲管理元件），且`[0025]`提到缓冲器状态是动态调整和考虑的因素。即使退一步讲，基于接收到的网络状况 hint 动态改变本地接收 buffer 的大小，也是为了配合段请求改变而进行的常规联锁配置，属于本领域技术人员的公知常识。

---

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

为了确保将该权利要求彻底、稳妥地斩于马下（实现单篇对比文件直接彻底否定创造性/新颖性，或形成双保险的结合），建议启动第二轮精准检索：

1. **锁定精准的IPC/CPC分类号检索：**

* 流媒体自适应传输及网络侧优化是现代通信（特别是3GPP DASH/流媒体）的热点。建议密切跟踪：`H04N21/24`（网络侧监视与质量检测）、`H04N21/2662`（基于网络条件自适应控制）、`H04N21/442`（客户端监视/接收网络反馈）、`H04L65/60`（网络流媒体传输协议优化）。

2. **关键词组合演进策略：**

* 为了更精准抓取“网络侧监视并把质量数据库信息发给客户端调控缓冲”的架构，应采用如下检索式：

* `(HTTP adaptive streaming OR DASH OR HLS) AND (network monitoring OR QoE probe OR Edge node) AND (quality database OR metric server) AND (buffer size configuration OR request scheduler) AND (low latency OR chunk transfer)`

3. **针对“标准提案（3GPP/MPEG）”进行非专利文献（NPL）检索：**

* 目标专利提及了“基于HTTP自适应流式传输的**低等待时间（Low-latency）**”，这在时间线上高度契合 **3GPP的3GP-DASH标准演进** 以及 **MPEG-DASH 的 SAND（Server and Network Assisted DASH，ISO/IEC 23009-5）标准**。

* *检索重点：* 特别去检索 2011年-2014年 期间（目标专利优先权日之前），3GPP SA4工作组或MPEG工作组关于 **“SAND” 架构** 的提案文献。SAND架构的核心思想正是定义了网络侧节点（DANE）收集路径质量信息（QoS/QoE），通过DASH协助通道把网络度量数据库的信息反馈给DASH客户端以配置其缓冲和段请求。一旦检索到当时的流媒体标准提案文献，该权利要求1将由于完全落入SAND标准架构而彻底丧失创造性。

作为一名经验丰富的专利代理师，我将针对目标专利权利要求1，紧密结合两份对比文件 **D1（WO2012145108A1）** 和 **D2（EP2530885A1）** 的具体原文及出处进行深度法律与技术分析。

---

### 一、 权利要求1的技术实质解析

权利要求1的实质是解决**基于HTTP的自适应流（如DASH/HLS等）在低延迟传输时，如何通过网络侧的协助来优化客户端的请求策略和缓存配置**。

传统自适应流（ABR）完全由客户端驱动，客户端仅能根据自身测量到的带宽或下载时间（即“滞后”的信息）来盲目调整。本权利要求通过在**网络中引入监视系统和质量数据库**，主动收集流式传输路径的质量度量，并**提供给内容处理设备（客户端侧）**，由客户端内部的**配置模块**动态调整**缓冲器和/或段请求功能**，从而实现低延迟下的精准自适应控制。

---

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

#### 1. D1（WO2012145108A1）公开情况分析

* **技术特征A（自适应流客户端/清单文件）**：**毫无疑问公开**。D1明确提到了通过HTTP进行自适应比特率流式传输，且描述流的信息（如视频质量和可用码率）传输在独立的清单文件（manifest）中，由客户端主动获取并请求段（chunks）。

* *原文出处*：`[0014] "Most of the current adaptive streaming technologies use hypertext transfer protocol (HTTP)... Information describing the stream... is generally transferred in a separate file (e.g., in a manifest)."`

* **技术特征B（网络中监视系统收集质量度量）**：**实质公开**。D1中由网络侧的缓存服务器（Cache Server）系统地评估（evaluate/monitor）能够影响比特率的各种网络指标（如上游点击量、服务器利用率、上游带宽特征、负载情况、时延等），这在实质上等同于网络中的监视系统收集质量度量。

* *原文出处*：`[0007] "...evaluating network criteria associated with characteristics that can affect a bit rate for the video session..."`；以及 `[0036] "For example, other criteria may include general latency characteristics, queuing delay characteristics, quality of service (QoS) characteristics..."`

* **技术特征C（存储在网络中质量数据库中）**：**实质公开**。D1公开了缓存服务器包含内存元件（memory element）、处理器和缓存存储器，用于存储评估后的未来片段码率信息和网络状况特征，这在实质上充当了网络中存储质量度量的“质量数据库”。

* *原文出处*：`[0037] "...cache server 14 may store information about the specific rates at which future fragments are currently cached."` 以及 `[0045] "Cache server 14 includes a memory element 50, a processor 52, a cache storage 56..."`

* **技术特征D（为内容处理设备提供质量度量或QoS信息）**：**毫无疑问公开**。D1的核心发明点就是将基于网络指标生成的“比特率提示数据（bit rate hint data）”通过HTTP头或清单文件发送（communicate/provide）给终端（endpoint）。

* *原文出处*：`[0007] "...and communicating bit rate hint data, which is based on the network criteria, to the endpoint for consideration in a bit rate request."` ；`[0008] "In particular embodiments, the bit rate hint data can be provided in headers of hypertext transfer protocol (HTTP) packets. Alternatively, the bit rate hint data is provided in a manifest..."`

* **技术特征E（内容处理设备基于该信息配置缓冲器和/或段请求功能）**：**部分公开（实质公开了配置“段请求功能”）**。D1公开了终端的“自适应流客户端模块（adaptive streaming client module）”接收该提示数据，并用于决定何时进行新的码率选择（即配置/调整段请求功能）。然而，D1**未明确公开**客户端根据该网络侧发送的提示数据去**配置客户端内部的“缓冲器（buffer）”**。

* *原文出处*：`[0046] "The rate hint data can be received by a respective hint receiver module 70a-c... Adaptive streaming client modules 68a-c can be configured to determine when new rate selections should occur, where bit rate selections can be properly sent to cache server 14."`

#### 2. D2（EP2530885A1）公开情况分析

* **技术特征A（自适应流客户端/清单文件）**：**毫无疑问公开**。公开了基于HTTP自适应流传输视频，客户端通过清单文件（manifest file）了解可用版本并发出请求。

* *原文出处*：`[0002] "The client fully controls the streaming session, managing the on-time request and play-out of the sequence of segments of the stream."` 以及 `[0017] "The information about the available versions or qualities of the segments is typically located in a so called manifest file 4..."`

* **技术特征B、C（监视系统与数据库）**：**实质公开**。D2在网络侧引入了整形部件（shaping component），其控制信息管理器（control information manager）负责接收并管理网络带宽、拓扑、中间缓存大小等控制信息，信息来源可包括网络监测系统（network monitoring system）。

* *原文出处*：`[0024] "It is assumed that the shaping component receives an input from an adaptive streaming server... and/or through a network monitoring system..."` ；`[0029] "The control information manager 13 is adapted to manage information that the shaper logic 15 and quality configuration components 17 can use."`

* **技术特征D、E（向客户端提供信息并由客户端配置）**：**未公开（存在实质性架构差异）**。D2的控制架构与本申请**完全不同**。D2的控制闭环在**网络侧的整形部件（shaping component）**内部完成。是由网络侧的整形器（shaper）直接限制分配给会话的虚拟通道带宽或队列大小，从而**被动迫使**客户端去适应。D2**并没有**将这些网络质量度量“发送给内容处理设备”，更**没有**由客户端内部的配置模块去“配置自身的缓冲器或段请求功能”。

* *原文出处*：`[0019] "Embodiments of the present invention artificially limit the effective bandwidth that an adaptive streaming session will get... creating a 'virtual channel' between the shaping component and the client..."` ；`[0004] "The shaping component comprises a shaper adapted to determine one or more transport parameters... based on control information; and to receive and transmit packets... to the client..."`

---

### 三、 技术特征比对表格

---

### 四、 最接近对比文件（Closest Prior Art）的筛选分析

在创造性分析中，**D1（WO2012145108A1）更适合作为最接近的对比文件**。分析如下：

1. **整体解决的技术问题角度**：

* **本申请**解决的是在低等待时间流式传输中，客户端如何打破信息不对称，获取网络侧的底层质量度量，从而精准做出流控调整的问题。

* **D1**完全聚焦于相同的技术问题。传统ABR单纯依赖客户端评估机制存在盲目性，导致网络资源利用不佳，D1旨在通过**网络侧向客户端提供反馈提示机制（rate hints）**，使客户端能够“做出更智能的码率选择决策（execute intelligent decisions about its bit rate requests）”。

* **D2**解决的是多客户端竞争带宽导致流量震荡（burstiness）的问题，其核心思想是**网络侧强行管控**（由Shaping Component创建虚拟通道拦截并重塑流量），并不鼓励客户端主动参与决策。

2. **技术效果角度**：

* **本申请**的效果是提高低延迟传输下的流控稳定性，避免客户端盲目切换码率或耗尽缓冲。

* **D1**达到了高度协同的效果，通过向终端提供前瞻性的网络压力和缓存状态提示，消除了不必要的反悔式请求，实现了低网络负载下的高画质流传输。

* **D2**的效果是强行让各会话在网络瓶颈处“排队”平滑化，客户端本身是“被动接受调速”的。

**结论**：D1与本申请的技术领域完全相同，技术方案的控制架构（**网络侧收集 $\rightarrow$ 发送给客户端 $\rightarrow$ 客户端调整请求**）高度一致，公开的技术特征显著多于D2。因此，**D1是唯一的、最适合的最接近对比文件**。

---

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

如果对权利要求1提出无效宣告请求，**最薄弱（即最不容易被无效掉、区别技术特征属性最强）的特征是特征E中的：“配置所述内容处理设备中的缓冲器”**。

* **原因分析**：

1. D1虽然毫无疑问公开了将信息发送给终端（特征D），也公开了客户端模块以此来配置“码率切换/段请求功能”（特征E的一部分），但在D1的全部实施例中，**客户端的反应仅限于改变其请求的Bit Rate，未涉及对客户端内部Video Buffer（缓冲器的大小、水位线阈值、预取策略）的重新配置**。

2. 无论是D1还是D2，常规的自适应流客户端的缓冲器管理都是相对固定的（如D1中提到方案依赖客户端侧的大量缓存调控 buffer fullness）。本申请将网络侧提供的质量信息（如时延、路径波动）用于**直接改变客户端缓冲器的配置（例如在低延迟模式下收紧缓冲器水位，或在不稳定网络下扩大缓冲器深度）**，这在现有技术中具有一定的技术贡献。

3. 审查指南中，只要权利要求中存在一个未被公开的区别特征，且该特征带来了有益的技术效果（动态缓冲平衡），创造性就可能成立。因此该特征是无效过程中的防守据点。

---

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

鉴于目前的防守据点在于“**客户端根据网络侧通知的QoS/网络质量指标来动态配置其本地缓冲器（Buffer）**”，为了彻底无效掉权利要求1，建议采取以下针对性的检索策略：

1. **关键词精细化扩展（聚焦客户端缓冲器控制）**：

* 中文：`(自适应流 或 DASH 或 HLS 或 ABR) 并 (网络侧提示 或 网络辅助 或 SAND 或 3GPP ATSSS 或 缓存服务器反馈) 并 (动态调整缓存 或 配置缓冲器 或 调整缓冲区水位 或 缓冲阈值 或 延迟优化)`

* 英文：`(Adaptive streaming OR DASH OR ABR OR HLS) AND (Network-assisted OR "bitrate hint" OR "network feedback" OR SAND OR "QoS flow") AND (configure buffer OR "buffer size" OR "buffer threshold" OR "playout buffer")`

2. **锁定标准规范标准演进（关键突破口）**：

* 本申请的系统架构（网络侧监视并向客户端提供QoS度量，客户端据此调节）高度契合 **MPEG-DASH SAND（Server and Network Assisted DASH，ISO/IEC 23009-5）** 标准协议。在SAND协议中，网络节点（DASH Assisting Network Element, DANE）会向客户端发送QoS信息或传输引导。

* **检索重点**：检索2012-2015年间 MPEG 工作组关于 **SAND (ISO/IEC 23009-5)** 的标准草案、提案输入文档（Contributions），以及 **3GPP TS 26.247**（关于3GP-DASH）的演进提案。标准文献中通常会极其详尽地描述客户端收到DANE的Metrics后，如何配置本地的Request Function和Buffer Level。

3. **目标公司与发明人检索**：

* 追踪在网络辅助自适应流（SAND）领域有深厚积累的厂家，如 **Cisco（D1的申请人通常为思科等网络巨头）、Ericsson、InterDigital、Qualcomm、Huawei**。

* 检索这些公司在2010–2015年期间关于“低延迟流媒体（Low Latency Streaming）”与“边缘计算/CDN辅助客户端缓存控制”的专利族。

根据权利要求1所述的方法，包括；基于所述质量度量的所述至少一部分来确定用于所述配置模块的所述一个或多个配置参数；所述一个或多个配置参数包括至少一个缓冲器大小参数，用于在开始所述缓冲器中的数据的播出之前确定缓冲器的大小和/或至少一个段请求参数，用于确定段请求功能将从所述流式传输服务器请求的选自所述清单文件中标识的段的第一段。

根据权利要求1或2所述的方法，包括；基于所述质量度量来确定所述服务质量信息；所述服务质量信息定义一个或多个QoS水平；其中，所述一个或多个QoS水平至少包括与用于在低等待时间模式中配置客户端的一个或多个配置参数相关联的低等待时间水平和与用于在高等待时间模式中配置客户端的一个或多个配置参数相关联的高等待时间水平。

根据权利要求1或2所述的方法，其中；所述服务质量信息的至少一部分由所述监视系统确定；并存储在所述质量数据库中。

根据权利要求1或2所述的方法，其中；所述提供包括将所述质量度量的所述至少一部分数和/或所述服务质量信息发送到所述内容处理设备。

根据权利要求5所述的方法，其中；所述提供包括客户端从所述服务器系统请求清单文件或清单文件更新的至少一部分；所述服务器系统从所述质量数据库检索所述质量度量的所述至少一部分、和/或所述服务质量信息；并将包括所述质量度量的所述至少一部分、和/或所述服务质量信息的清单文件发送到所述客户端。

根据权利要求5所述的方法，其中；通过基于Websocket的流式传输控制信道将所述质量度量的至少一部分、和/或所述服务质量信息发送到所述客户端。

根据权利要求7所述的方法，包括；为所述客户端提供用于在所述服务器系统与所述客户端之间建立流式传输控制信道的信道建立信息；所述流式传输控制信道是基于Websocket流式传输控制信道；基于所述信道建立信息来建立所述流式传输控制信道。

根据权利要求1或2所述的方法，包括；所述内容处理设备中的至少第一监视代理收集与所述内容处理设备相关联的第一度量和/或所述网络中的至少第二监视代理收集与所述网络的至少一部分相关联的第二度量；基于所述第一和/或第二度量，所述监视系统确定与所述服务器系统中的所述一个或多个流式传输服务器与所述客户端之间的一个或多个流式传输路径相关联的质量度量；并将所述质量度量存储在所述质量数据库中。