用于增强视频流的视频帧中的至少一个感兴趣区域ROI的方法，所述方法包括客户端设备接收定义至少一个基础流的基础视频帧的媒体数据；所述基础流与一个或多个增强图块流相关联；其中增强图块流包括定义图块化视频帧的媒体数据；图块化视频帧包括与用于增强基础视频帧的图像区域的子区域中的视觉内容的媒体数据相关联的图块；其中增强图块流的媒体数据可独立于所述基础流的媒体数据进行解码；确定与所述基础流的视频帧中的至少一个感兴趣区域的位置相关联 of the ROI位置信息；基于ROI位置信息和图块位置信息来确定一个或多个增强图块流；其中所述一个或多个所确定的增强图块流定义与至少一个ROI至少部分地重叠的一个或多个图块；客户端设备请求所述一个或多个所确定的增强图块流的媒体数据；所请求的媒体数据的图块化视频帧的一个或多个图块与基础视频帧的图像区域中的至少一个预定的感兴趣区域相关联；所述媒体数据是由客户端设备基于清单文件而请求的；所述清单文件包括至少一个基础流标识符和与该至少一个基础流标识符相关联的一个或多个增强图块流标识符；流标识符包括URL的至少一部分或包括用于确定这样的URL的信息；清单文件还包括用于向所述客户端设备发信号通知关于所述基础流的视频帧中的视觉内容与所述一个或多个增强图块流的图块化视频帧的图块中的视觉内容之间的空间关系的图块位置信息；连接到所述客户端设备的第一解码器基于至少一个基础流的媒体数据生成基础视频帧；并且连接到客户端设备的第二解码器基于一个或多个增强图块流的媒体数据生成图块化视频帧；所生成的图块化视频帧包括在至少一个感兴趣区域中形成增强视觉内容的一个或多个图块；以及，渲染设备通过基于图块化视频帧的增强视觉内容的至少一部分修改所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分来形成包括增强感兴趣区域的视频帧；所述修改包括用图块化视频帧的增强视觉内容的至少一部分替换或混合所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分。

作为一名资深的专利代理师，我现针对目标专利权利要求1的19个技术特征（特征A至S），紧密结合三份对比文件（D1: GB2505912A；D2: WO2014057131A1；D3: GB2513139A）的英文原文及详细出处进行深度侵权/无效法律分析。

### 一、 权利要求技术特征比对表格

为了清晰展现各对比文件对权利要求1技术特征的公开情况，以下给出特征比对表。“毫无异议公开（完全公开）”标记为“✓”，“实质公开（等同或隐含公开）”标记为“◎”，“未公开”标记为“✗”。

---

### 二、 对比文件公开情况详细法律分析（结合原文出处）

#### 1. D1 (GB2505912A) 的公开情况分析

D1实质公开了多层（基础层+增强层）空间ROI切片流的架构，但未明确提及客户端双解码器架构。

* **特征A, B, C, L（实质公开/等同）**：D1公开了分层视频流结构，包含一个基础层和至少一个采用独立可解码图块（Tile）编码的增强层。原文出处：`"Still according to a particular embodiment, the video sequence may be a scalable video sequence, comprising one base layer and at least one enhancement layer which is encoded by independently decodable tiles."` 这一描述实质公开了基础流与增强图块流的关联及标识。

* **特征D, E, F, G, H, I, J, K, M, N, Q（毫无异议公开）**：D1明确指出通过描述文件（Manifest）中的空间和时间信息来检索包含ROI的视频段，且增强层由独立可解码的Tile组成。原文出处：`"According to a first aspect... generating a description file comprising spatial information describing the frame region... and temporal information..."` ；以及 `"the video sequence may be encoded by independently decodable tiles, and wherein the spatial information includes index of the tiles covered by the region of interest."`

* **特征R, S（实质公开）**：D1公开了客户端接收ROI对应的增强Tile数据后，在更高质量下将其呈现在基础层之上，并由客户端进行裁剪显示。原文出处：`"The client can then decode the tiles and provides a superset of the ROI in higher quality on top of the base layer. Or it is up to the client... to crop the received data before display."` 这构成了基于增强Tile对基础视频帧对应ROI的修改（混合/替换）。

* **特征O, P（未公开）**：D1仅概括提及“decode and display”（解码并显示），**未公开**通过“第一解码器”和“第二解码器”分别独立并行解码基础流和增强图块流的硬件/软件双解码器架构。

#### 2. D2 (WO2014057131A1) 与 D3 (GB2513139A) 的公开情况分析

*注：D2与D3的内容高度一致（同族或同日申请族），故合并分析，其原文依据同时适用于两份文件。*

* **特征A至N, Q（毫无异议公开）**：D2/D3完美公开了基于DASH标准下的Tiled视频流清单文件（MPD）信令机制。客户端基于ROI选择对应的Tile URL并同时请求基础层。

* **原文出处 (特征A, B, C, D, I, J)**：`"said video further comprising a base layer video track, said description file further comprising the URL of the base layer track, and if the client device selects at least one URL according to one Region Of Interest, it also selects the URL of the base layer... and the server further transmits... video data corresponding to the requested base layer track..."`

* **原文出处 (特征K, L, M, N)**：`"transmitting, by a server, a description file to a client device, said description file including data about the spatial organization of the n video sub-tracks and at least n URLs respectively designating each video sub-track,"` 以及 `"the set of parameters including a descriptor called a Role element which incorporates data about... the position of the spatial tile and the configuration of the n spatial tiles."`

* **原文出处 (特征E)**：`"According to a preferred embodiment, these video sub-tracks are considered as independent video and are compressed independently."`

* **特征O, P（实质公开）**：D2/D3公开了通用微处理器（CPU）以及用于执行其算法的架构。原文出处：`"a random access memory 1002... necessary for implementing the method for... encoding the video and/or for reading or generating the Data... Under the control of the software application running in the CPU 1001"和"These temporal segments can be decoded 108 by the client device 110 for display 109."` 虽然明确了基础层和各个Tile作为独立视频流被独立下载并送入解码，但并未在权利要求层面具象化为“第一解码器”和“第二解码器”的物理或逻辑双实体描述，属于实质公开/隐含公开。

* **特征R（实质公开）**：D2/D3提及利用初始化数据中的变换矩阵将各子轨道（Tile）在正确的位置进行拼接显示。原文出处：`"the initialization data further comprises a transformation matrix which enables the display of each video sub-track at the right position."` 这种在特定空间坐标位置将增强Tile与基础层叠加显示的行为，实质上属于对基础帧视觉内容的“修改”以形成包含增强ROI的帧。

* **特征S（未公开）**：D2/D3**未明确公开**“用图块化视频帧的增强视觉内容替换或混合基础流视频帧中感兴趣区域的视觉内容”这一具体的后端渲染消除或遮蔽原基础帧像素的操作细节。

---

### 三、 最接近对比文件的确定（创造性分析）

在创造性分析中，**D2（或D3）最适合作为本申请的“最接近的对比文件（第一源头）”**。

**原因分析：**

1. **技术领域与解决的技术问题高度一致**：本申请旨在解决如何在客户端高效请求、解码并渲染视频流中感兴趣区域（ROI）的画面增强问题。D2/D3同样聚焦于DASH/HTTP流媒体中，针对大视频（如4K2K）在移动端无法全高清流畅播放的场景，通过将增强层切片（Tiling）并结合清单文件（MPD Role元素）信令，允许客户端仅请求ROI对应的Tile和基础层轨道。

2. **技术效果的重合度最高**：D2/D3通过将Tile URL直接写入清单文件并与基础层关联，极大地“减少了流媒体传输中的无用请求和网络开销（limiting the number of requests）”，这与本申请通过独立解码的增强图块流来“增强视频流基础帧中的ROI”以节省带宽的技术效果完全匹配。

3. **技术特征覆盖率最高**：如特征比对表所示，D2/D3毫无异议地完全公开了权利要求1中除具体解码器硬件划分（特征O、P）及具体混合/替换渲染算法（特征S）以外的几乎所有前序流信令控制和媒体组织特征（特征A-N, Q）。相比之下，D1侧重于动态时间区间的动态段生成算法（依据ROI移动速度动态划分子流），其清单文件的空间信令结构没有D2/D3与本申请的DASH MPD映射关系紧密。

---

### 四、 未公开特征的交叉公开性与最薄弱技术特征指出

#### 1. 未被最接近对比文件（D2/D3）公开的特征是否被其他文件公开？

* **特征O、P（第一/第二解码器结构）**：D2/D3未明示，**D1同样未公开**。三份文件在解码层面均属于通用性描述（如D1的`"decode the tiles"`，D2/D3的`"decoded 108 by the client device"`）。

* **特征S（替换或混合的具体修改方式）**：D2/D3未公开，但**D1对此进行了其实质性公开**。D1明确指出：`"The client can then decode the tiles and provides a superset of the ROI in higher quality on top of the base layer."`（客户端在基础层之上提供更高质量的ROI超集层）。将高质量Tile覆盖在低质量基础层之上的操作，在计算机图形渲染领域即为典型的“混合（Alpha Blending）”或“像素替换（Opaque Overlay）”。

#### 2. 无效请求中最薄弱的技术特征（即创造性突破口）

本权利要求1若面临无效宣告请求，**最薄弱（即最容易被认为属于显而易见、不具备创造性）的技术特征是：特征O和特征P（双解码器架构）**。

**无效理由预测：**

尽管D1、D2、D3均未直接使用“第一解码器”和“第二解码器”的字眼，但D2/D3已经彻底公开了`“基础流媒体数据”`与`“增强图块流媒体数据”`是**可独立解码的独立轨道（independent tracks/bitstreams）**。在已知两个视频流相互独立且可独立解码的前提下，本领域技术人员为了实现并行处理或利用硬件加速，自然而然会想到在客户端配置两个解码器实体（或同一多路解码芯片的两个独立解码实例）分别对其进行解码。这属于本领域的公知常识或常规技术选择，不具有意料不到的技术效果。

相反，**最稳固（抗无效能力最强）的特征是特征O、P与特征R、S的架构组合**，即：“第一解码器生成基础帧，第二解码器独立生成图块帧，再由渲染设备在ROI区域进行像素级别的替换或混合。” 这种“分流双解码器并行解码 + 后端像素级替换混合渲染”的完整链路，在对比文件中缺乏一体化的技术启示。

---

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

为了在诉讼或无效程序中彻底攻破该权利要求的创造性，建议采取以下精准检索策略：

1. **关键词扩展与精准组合**：

* **流媒体信令类**：`"DASH"`, `"MPD"`, `"Manifest"`, `"Role descriptor"`, `"Spatial relationship"`, `"Supplemental Enhancement Information (SEI)"`.

* **图块与图层类**：`"SHVC" (Scalable HEVC)`, `"Base layer"`, `"Enhancement layer"`, `"Tiles"`, `"Sub-tracks"`, `"Region of Interest (ROI)"`.

* **解码与渲染类**：`"Dual decoders"`, `"Multi-decoder"`, `"Parallel decoding"`, `"Alpha blending"`, `"Overlay"`, `"Texture replacement"`.

2. **重点分类号检索（IPC/CPC）**：

* **H04N21/434**：客户端的多路解复用和解密/解码。

* **H04N21/4728**：针对特定ROI（感兴趣区域）的视频内容选择。

* **H04N19/30**：可伸缩/分层视频编码。

* **H04N19/167**：基于ROI的编码图块划分。

3. **目标突破点检索（专攻双解码器与像素替换）**：

* 鉴于D2/D3已完美解决传输和清单文件信令问题，下一步检索应**脱离流媒体传输协议**，转向**“客户端播放器架构”和“视频渲染引擎”**领域。

* 重点检索2014-2016年期间关于“SHVC（可伸缩视频编码）播放器实现”或“4K全景视频/VR局部视口（Viewport）播放器”的技术文献或专利。在这些文献中，为了渲染用户当前高清晰度的视口，通常会启示“用主解码器解低清全景背景，用副解码器解高清图块，并用高清图块像素覆盖/替换背景中对应区域”的方案。

作为一名经验丰富的专利代理师，我将为您对该目标专利（权利要求1）进行深度的说明书解读、对比文件原文比对及创造性证据链分析。

本案涉及的核心技术核心在于**基于互联网流媒体（如DASH标准）的视频感兴趣区域（ROI）空间图块（Tile）增强传输与渲染架构**。其通过独立的“基础流”与“增强图块流”分离传输，并在客户端采用双解码器架构实施替换或混合渲染，从而在不大幅增加带宽的前提下提升局部区域画质。

以下是针对权利要求1的全面无效可行性及创造性分析报告：

---

## 一、 权利要求1的技术特征拆解与技术内涵解析

紧密结合目标专利说明书的本意，对权利要求1的19个技术特征（A至S）的法律与技术内涵解析如下：

* **特征A~D（流关联与图块化定义）：** 确立了“基础流（定义基础帧）”与“增强图块流（定义图块化视频帧，对应子区域视觉内容，用于增强基础帧）”的关联架构。这属于典型的分层/可伸缩编码（Scalable Coding）与空间切片（Tiling）的结合。

* **特征E（独立解码特征）：** “增强图块流可独立于基础流进行解码”。**这是本专利非常核心且严苛的限定**。在传统可伸缩编码（如SVC/SHVC）中，增强层通常依赖于基础层的层间预测（Intra-layer prediction），无法独立解码。此特征限定了增强图块流在语法和预测上具备独立性（例如彻底关闭层间预测或采用特定的独立封装机制）。

* **特征F~H（ROI图块确定机制）：** 客户端基于ROI位置信息和媒体自身的“图块位置信息”进行重叠度匹配，从而动态筛选出需要下载的增强图块流。

* **特征I~N（基于清单文件的标识符与流请求）：** 限定了流媒体客户端（如DASH客户端）的行为。流请求基于一个“清单文件（Manifest，如MPD）”，清单文件内包含两类关键信号：① 基础流与增强图块流的标识符（包含URL或其一部分）；② 向客户端发信号通知两者空间关系的“图块位置信息”。

* **特征O~Q（双解码器生成架构）：** 明确限定客户端硬件/软件架构包含“第一解码器”（解码基础流生成基础帧）和“第二解码器”（解码增强图块流生成图块化帧，包含ROI增强内容）。

* **特征R~S（渲染设备的修改与混合机制）：** 限定了解码后的后处理渲染行为，即渲染设备通过“替换（Replace）”或“混合（Blend）”的方式，用图块化帧的增强内容去修改基础帧对应的ROI区域。

---

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

为了客观全面地评估公开情况，以下将三份对比文件与权利要求1的各个技术特征进行逐项比对：

* **D1：** WO2015011109A1（下称 D1_WO109A）

* **D2：** GB2519746A（下称 D2_GB746A）

* **D3：** WO2015144735A1（下称 D3_WO735A）

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

---

## 三、 对比文件实质公开/毫无异议公开特征的详细出处分析

### 1. 对比文件 D1 (WO2015011109A1)

* **研发背景与技术问题：** 解决如何在HTTP流媒体（DASH）中高效传输用户动态选择的感兴趣区域（ROI），避免请求大量不连续的字节范围或造成基础层数据重复传输（见`[p0003]`, `[p0018]`）。

* **技术效果：** 通过定义“图块轨（Tile Track）”将空间图块组织为连续字节范围，降低了传输开销，并保证客户端组合出的文件对通用视频解码器完全合法（见`[p0019]`, `[p0027]`）。

* **核心特征公开出处：**

* **特征B、C、D、L：** `[p0261]`和`[p0272]`明确指出：“分层媒体数据组织可以由多个相关轨表示……新轨称为图块轨（tile track）。图块轨的样本定义了完整视频帧的空域定义子部分。图块轨仅包含与给定图块相关的NAL单元”。

* **特征F、G、H、I：** `[p0342]-[p0343]`（图6b流程）：“在客户端选择ROI时，确定对应ROI的图块（步骤608）……客户端向服务器发送请求以请求下载与选择图块相对应的媒体 segment 文件（步骤612）”。

* **特征K、M：** `[p0007]`明确公开了在DASH框架下，基于包含资源标识符（HTTP-URLs）的媒体展示描述清单文件（MPD）由客户端决定下载哪些分片。

### 2. 对比文件 D2 (GB2519746A)

* **研发背景与技术问题：** 针对分层可伸缩视频编码（如SHVC/SVC），如何对包含空域图块的流媒体文件进行重组和封装，以支持动态ROI流式传输，提升解析和ROI图块提取效率（见说明书第2页第`[2]`段、第5页第`[2]`段）。

* **技术效果：** 将ROI的几何信息与层识别信息在统一结构（如`TileRegionGroupEntry`描述符）中集中处理，大幅优化了流媒体客户端在多层依赖下的解析响应速度（见第5页第`[2]`段）。

* **核心特征公开出处：**

* **特征B、D、G：** 说明书第13页第`[2]`段及图3b、3c：“图3b描述了包含基础层310和增强层315的可伸缩视频流……增强层是包含图块320的图块化增强层……存在图块到图片的依赖关系”。

* **特征F、I、J：** 说明书第17页第`[2]`段（图11b流程）：“在客户端确定对应所选ROI的图块（步骤1108）……客户端发送请求下载与所选图块对应的媒体 segment 文件（步骤1112）”。

* **特征L、N（部分公开）：** 详细公开了利用`NALUMapEntry`和`TileRegionGroupEntry`在文件内部映射NAL单元与图块几何信息（宽、高、横纵坐标偏移）的机制（见说明书第15页第`[2]`段、第16页第`[2]`段）。

### 3. 对比文件 D3 (WO2015144735A1)

* **研发背景与技术问题：** 解决DASH标准现有MPD清单文件无法准确表达“同一个视频源的各视频轨之间互为局部空间子集（图块）及复杂的Mandatory/Optional（强制/可选）层间依赖关系”的问题，避免客户端因盲目解析初始化分片而导致的高延迟和多余的HTTP往返（见`[0018]-[0019]`）。

* **技术效果：** 通过在清单文件（MPD）中引入空间关系描述（SRD）描述符及 qualified 依赖属性，使客户端仅凭清单文件就能立即获知各URL的空间几何对应关系及解码所需的最简分片组合，实现动态平滑的高清ROI局部放大与全景切换（见`[0029]-[0031]`）。

* **核心特征公开出处：**

* **特征G、H、N（全部毫无异议公开）：** `[0199]-[0206]`及图4b详细阐述了**在清单文件（MPD）层面**扩展空间关系描述（SRD）的语法：“SRD描述符使用`SupplementalProperty`或`EssentialProperty`，其`@value`包含`source_id, x, y, w, h, W, H, group_id`……表达关联的表征在源坐标系中的2D位置与2D尺寸”。

* **特征K、L、M：** `[0008]-[0010]`明确公开客户端通过接收XML格式的清单文件（MPD），获取媒体组件描述与HTTP URLs，并基于清单文件显式声明的`@dependencyId`属性发起图块分片请求。

---

## 四、 最接近对比文件（最接近现有技术）的选择与创造性证据链构建

### 1. 哪个对比文件最适合做“最接近的对比文件”？

在本案的创造性评述中，**对比文件 D3 (WO2015144735A1) 最适合作为审查指南中所定义的“最接近现有技术（最接近的对比文件）”**。

**选择理由分析：**

1. **技术领域与解决的技术问题最契合：** 目标专利核心保护的是一种流标识符与空间位置关系被写在“清单文件（Manifest）”中，且客户端“基于清单文件”确定并请求ROI增强图块的方法。D1和D2的技术核心在于**ISO BMFF文件容器层级（封装层）**的轨描述（如使用`tmhd`盒或文件内部的描述符），其清单文件仅映射了标准URL；而**D3则直接聚焦于DASH流媒体的“清单文件（MPD）”层面**，专门解决如何在清单文件中表达空间图块位置（SRD）与流请求依赖的问题。

2. **公开的技术特征数量最多且最为核心：** 权利要求1中关于清单文件的架构性限定（特征K、L、M，尤其是将图块空间位置写入清单文件的**特征N**），在D1和D2中均属于未公开的盲区，但在D3的`[0199]-[0206]`（SRD技术）中被**毫无异议地完全公开**。因此，以D3作为主选对比文件，能够最大程度减少证据链构建中的“技术断层”。

### 2. 创造性证据链与评述策略构建

虽然D3在清单文件层面公开了绝大部分特征，但权利要求1中仍包含D3未公开的独特性限定（如双解码器、后处理替换/混合渲染、图块流独立解码）。因此，必须采用**多份对比文件结合**的策略来构筑无效证据链：

#### 创造性评述路线：D3 + D1 + 本领域公知常识 / D2

* **第一步：确定区别特征**

将权利要求1与最接近现有技术D3比对，其区别特征在于：

1. **特征E**：增强图块流可以“独立于基础流进行解码”；

2. **特征P**：客户端硬件/软件架构采用了“双解码器”（第一解码器解基础流，第二解码器解增强图块流）；

3. **特征R、S**：解码后由渲染设备执行“后处理”，通过“替换”或“混合”增强视觉内容的方式修改基础帧的ROI。

* **第二步：分析区别特征实际解决的技术问题**

上述区别特征在实际结合中，解决的技术问题是：*如何在客户端解码并呈现这种基础帧与局部增强图块时，降低单个解码器的性能负载压力，并实现平滑的后处理局部图像拼接与融合。*

* **第三步：评估技术启示与结合可行性**

1. **关于独立解码（特征E）与双解码器（特征P）：**

* 对比文件D1的`[p0009]`、`[p0263]`等段落已经指出了SVC和HEVC等标准支持独立可解码空间区域（Tiling）的定义，且D1的`[p0016]-[p0017]`中在论述现有技术局限性时，已经明确提及并设想过“每个轨需要一个解码器（one decoder per track is required）”的多解码器架构。

* 此外，在视频处理领域，当遇到相互独立的视频流（特征E中限定了增强图块流可独立解码）需要同时播放时，设置多路解码器（双解码器）并行处理属于本领域的**常规技术选择（公知常识）**。

2. **关于渲染设备的替换或混合修改（特征R、S）：**

* 一旦客户端通过第一和第二解码器分别生成了完整的“基础视频帧”和局部的“图块化视频帧”，如何将这两张图呈现在屏幕的同一ROI区域？对于本领域技术人员而言，在视频后处理（Post-processing）或图层合成阶段，采用“用高分辨率图像直接**替换**低分辨率对应区域”，或者为了消除边缘缝隙采用Alpha**混合（混合）**，这属于图形图像渲染领域极其初级且普遍应用的**公知常识**。

* 目标专利将这一显而易见的后处理显示手段写入权利要求，并未产生任何超出预期的技术效果。

**结论：** 本领域技术人员在D3的基础上，结合D1关于多轨多解码器技术演进的提示，并融入图形渲染的公知常识，完全有能力且有动机组合出权利要求1的技术方案，因此权利要求1不具备创造性。

---

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

若您代表请求人向国家知识产权局提起专利无效宣告请求，整个创造性辩论中**最薄弱（即最难攻克、目标专利所有人防守最严密）的技术特征**是：

> **特征E：其中增强图块流的媒体数据可独立于所述基础流的媒体数据进行解码。**

### 为什么特征E是最薄弱/最难攻克的点？

1. **文献中的技术描述“相悖”或具有“负启示”：**

流媒体分层传输（可伸缩编码）的标准逻辑是“增强层依赖于基础层”。D1、D2和D3作为流媒体封装和传输的早期专利，其本质上都在大量讨论“如何处理层间预测依赖（Coding dependencies）”。例如，D1在`[p0273]`中强调复合轨要利用提取器指向依赖轨；D2在图3b/3c中重点描述“图块到图片”、“图块到图块”的**层间依赖**；D3在`[0154]`中亦明确指出“编码依赖性可能存在于增强层图块与基础层图块之间”。

2. **专利权人的强力抗辩点：**

在无效口头审理中，专利权人会极力抗辩：“现有技术（D1-D3）全部都在研究‘如何让增强图块依赖基础流进行层间预测以节省带宽’，它们给出的均是**负启示**。而本专利限定了增强图块流可以‘独立于基础流进行解码’（彻底切断层间预测语法流），这是一种反向思维，现有技术没有给出将其改为‘独立解码’的明确技术启示。”

### 应对策略建议：

在检索和陈述中，不要单从“可伸缩视频”的角度去解构特征E。应当主张：在HEVC标准中，由`loop_filter_across_tiles_enabled_flag=0`及运动向量限制在图块内部所定义的**独立图块（Independent Tiles）**本身就是可以完全脱离外界独立解码的（如D1的`[p0390]`及D2的说明书第15页均有涉及）。当把每个独立图块单独打包成一路独立的流（特征C）时，它自然就具备了独立于其他任何流（包括基础流）进行解码的能力，这属于对HEVC Tile特性的延伸应用。

---

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

鉴于目前的D1-D3在“双解码器（特征P）”及“渲染层替换/混合（特征R、S）”的字面公开曲率上略有不足，为了彻底锁死无效证据链，建议开展以下针对性补充检索：

### 1. 扩展检索主题词与技术分支

* **核心方向：** 改变纯粹从“DASH/流媒体封装”标准切入的视角，转向**“视频终端播放器架构”**和**“视频后处理合成”**领域。

* **检索词组合（中英文）：**

* (双解码器 OR 多解码器 OR 异步解码 OR 并行解码) AND (感兴趣区域 OR 局部增强 OR 图块 OR 切片 OR ROI OR Tile)

* (Dual decoder OR Multiple decoders OR Parallel decoding) AND (ROI OR Region of Interest OR Tile-based enhancement) AND (Post-processing OR Blend OR Replace OR Compose)

### 2. 重点紧盯的目标专利权人与标准组织文献

1. **标准提案（Standard Contributions）：** 检索 **3GPP SA4（流媒体小组）** 和 **MPEG/JCT-VC** 在2013年~2015年期间关于DASH SRD (Spatial Relationship Description) 以及 HEVC 基于图块流传输（Tile-stream-based delivery）的原始提案文件（如 `JCTVC-K0128` 或相近提案）。标准提案中往往会讨论终端如何利用双流和双解码器在渲染层进行Patch拼接。

2. **行业巨头的专利防御库：** 重点检索在流媒体技术及图符渲染领域积淀深厚的公司（如高通 Qualcomm、爱立信 Ericsson、InterDigital、三星 Samsung、华为）在2013-2015年间申请的、关于“多路视频局部叠加/超分辨率局部拼接”的终端实现专利。

### 3. 精准检索靶向：寻找特征R/S的字面公开

重点寻找这样一种现有技术文献：*“一种视频播放方法，终端同时接收一路低码率全景视频和一路高码率局部ROI视频，使用两个独立的解码器线程分别解码，显示驱动或渲染引擎将解码后的高清ROI视频帧覆盖（替换）在低清全景帧的对应坐标上。”*

此类文献一旦检出，结合D3的空间清单文件技术，将能形成无懈可击的创造性顶层攻击力。

作为一名经验丰富的专利代理师，我将为您对该目标专利（权利要求1）与三份对比文件（D1、D2、D3）进行深度法律与技术分析。

本案核心在于一种**基于清单文件（Manifest file）独立解码基础流与增强图块流，并在客户端进行区域替换或混合以实现感兴趣区域（ROI）空间视频增强**的方法。

以下为详细的分析报告、特征比对、最接近对比文件筛选及无效策略。

---

## 权利要求1的技术特征拆解与技术理解

为了进行精准的比对，首先将权利要求1拆解为以下**19个独立的技术特征（A至S）**：

* **A：** 所述方法包括客户端设备接收定义至少一个基础流的基础视频帧的媒体数据；

* **B：** 所述基础流与一个或多个增强图块流相关联；

* **C：** 其中增强图块流包括定义图块化视频帧的媒体数据；

* **D：** 图块化视频帧包括与用于增强基础视频帧的图像区域的子区域中的视觉内容的媒体数据相关联的图块；

* **E：** 其中增强图块流的媒体数据可独立于所述基础流的媒体数据进行解码；

* **F：** 确定与所述基础流的视频帧中的至少一个感兴趣区域的位置相关联的ROI位置信息；

* **G：** 基于ROI位置信息和图块位置信息来确定一个或多个增强图块流；

* **H：** 其中所述一个或多个所确定的增强图块流定义与至少一个ROI至少部分地重叠的一个或多个图块；

* **I：** 客户端设备请求所述一个或多个所确定的增强图块流的媒体数据；

* **J：** 所请求的媒体数据的图块化视频帧的一个或多个图块与基础视频帧的图像区域中的至少一个预定的感兴趣区域相关联；

* **K：** 所述媒体数据是由客户端设备基于清单文件而请求的；

* **L：** 所述清单文件包括至少一个基础流标识符和与该至少一个基础流标识符相关联的一个或多个增强图块流标识符；

* **M：** 流标识符包括URL的至少一部分或包括用于确定这样的URL的信息；

* **N：** 清单文件还包括用于向所述客户端设备发信号通知关于所述基础流的视频帧中的视觉内容与所述一个或多个增强图块流的图块化视频帧的图块中的视觉内容之间的空间关系的图块位置信息；

* **O：** 连接到所述客户端设备的第一解码器基于至少一个基础流的媒体数据生成基础视频帧；

* **P：** 连接到客户端设备的第二解码器基于一个或多个增强图块流的媒体数据生成图块化视频帧；

* **Q：** 所生成的图块化视频帧包括在至少一个感兴趣区域中形成增强视觉内容的一个或多个图块；

* **R：** 渲染设备通过基于图块化视频帧的增强视觉内容的至少一部分修改所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分来形成包括增强感兴趣区域的视频帧；

* **S：** 所述修改包括用图块化视频帧的增强视觉内容的至少一部分替换或混合所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分。

---

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

### D1: US20020080878A1 (Video apparatus and method for digital video enhancement)

* **实质公开的技术架构：** 基于MPEG-4的可伸缩性编码（Scalable Coding）架构，包括基础层（Base Layer）和增强层（Enhancement Layer）。通过控制基础层的量化步长和增强层的位移（Bit-shifting）来实现对ROI（感兴趣区域）的质量增强。

* **相关原文出处及内容：**

* **\[0004\] / \[0008\]：** 公开了输入视频产生压缩的“base layer bitstream”和“enhancement layer bitstream”。在基础层使用运动补偿DCT编码，增强层使用残差的位元面编码（bitplane coding）。—— *实质公开/毫无异议公开了特征A、B、C*。

* **\[0010\]：** “In the decoder of FIG. 2, the base layer bitstream is coupled to variable length decoder 205... In the enhancement decoder, the enhancement bitstream is coupled to variable length decoder 251...” —— *公开了双解码器（第一解码器解码基础流，第二解码器解码增强流），即特征O、P*。

* **\[0010\]末尾：** “The output of combiner is coupled to clipping circuit, whose output is the decoded enhancement video.” 组合器256将基础层视频和增强层残差结合。—— *公开了通过混合来修改基础帧（特征R、S的部分手段），但它是基于传统的层相加，而非空间图块图块化（Tile-based）的局部替换*。

* **未公开的关键特征：** 没有任何关于“图块（Tile）”或“空间图块化视频帧（Tile-based video frame）”的描述（特征D、H、J、N、Q不公开）；没有任何客户端基于带有URL的“清单文件（Manifest file）”进行独立请求的机制（特征K、L、M、N完全未公开）。

### D2: US20060120610A1 (Image transcoding)

* **实质公开的技术架构：** 基于JPEG 2000标准的图像转码。利用JPEG 2000的“Precinct（分区/图块区域）”概念，在频域/空间域将图像划分为不重叠的矩形块，并分为ROI Precinct和BG（背景）Precinct。转码器在不完全解码的情况下，通过抛弃背景Precinct或使用空数据包（Empty packet），在输出码流中只保留或强化增强ROI Precinct。

* **相关原文出处及内容：**

* **\[0026\]：** “code-blocks are grouped into ‘precincts’ within each resolution level. Precinct partitioning makes it easier to access the wavelet coefficients corresponding to a particular spatial region of the image. Each precinct generates one packet in the bitstream.” —— *毫无异议公开了“图块/分区”的概念以及它与空间区域的对应关系，即特征D*。

* **\[0032\] / \[0033\]：** “coordinates of the ROI... The ROI coordinates may not match the precinct locations. In this case, the transcoding 120 rounds the ROI coordinates outward to the nearest precinct boundaries... to indicate how many quality levels that need to be transcoded for the BG and ROI.” —— *实质公开了基于ROI位置和图块/分区位置来确定重叠的一个或多个图块/分区，即特征F、G、H、J*。

* **\[0044\] / \[0045\]：** “For ROI packets, the transcoder 120 extracts only the ROI packet from the lowest quality layer 1, to quality layer n... The BG packets on layers higher than m are all converted to the empty packets...”

* **未公开的关键特征：** D2是静态文件转码（Transcoding）或单码流包过滤技术，它**没有**区分独立并行的“基础流”与“增强图块流”（D2是在一个混合了ROI和BG的整体JPEG 2000流中操作），因此特征B、E、K、L、M、N、O、P、Q、R、S不公开。

### D3: EP1672925A1 (Mixed-media service collections for multimedia platforms)

* **实质公开的技术架构：** 一种用于多媒体平台的混合媒体服务集合（Service Collection）机制。为每个“频道（Channel）”定义一个服务集合映射表（Map），包含多个独立的“服务（Services）”（如1.5Mbps全屏主视频、150kbps的PIP画中画视频、静态画、音频流等）。客户端根据自身条件（授权、硬件能力）基于这些服务标识符和URL去请求并独立 actuated（执行/解码）对应的媒体流。

* **相关原文出处及内容：**

* **\[0023\]：** “by allowing the client to tune to a service collection instead of to a service, multiple forms of content can be displayed simultaneously... by actuating multiple services in the service collection for the tuned channel.” —— *公开了基础频道流与关联的多个其他媒体流的关联请求*。

* **\[0025\] / \[0026\]：** “A service collection map 200 bundles individual services 206 together for each channel... structured in extensible markup language (XML)... structured language map of relations between unique IDs.” —— *实质公开了清单文件（XML映射表）以及基础流标识符与相关联的多个服务（增强流）标识符的对应，即特征K、L*。

* **\[0030\] / \[0031\]：** “a service 206 is assigned a unique identifier to allow each service 206 to be interchanged or reused in a modular manner... more than one service ‘tagged’ for simultaneous use in a given display context.” —— *公开了流标识符的概念*。

* **Fig. 9 & Fig. 10 (\[0062\]-\[0064\])：** 服务标识符（GUIDs）关联到具体的子系统和数据源（包含Internet links/URL信息）。—— *实质公开了特征M*。

* **\[0039\]：** “a fullscreen high-resolution movie 316 may display at the same time as a lower resolution PIP window 318 for delivering sign-language dialogue for the movie and both services 206 may display without tuning two main streams with two tuners.” 并在图2中公开了Fullscreen和PIP的空间上下文（Context）。—— *公开了将两个独立的流在空间上结合渲染修改，即特征R、S的初级形态（画中画或图层叠加）*。

* **未公开的关键特征：** D3的流是“全屏/独立图像”级别的（如画中画、字幕流），**并没有**公开针对同一个视频帧内部的“子区域视觉内容增强”的“图块化视频帧（Tile-based video frame）”及“图块位置的空间映射信号通知”（即未公开特征D、G、H、I、J、N、Q）。

---

## 技术特征比对表

---

## 最接近的对比文件（D1 / D3 组合选择）

在创造性分析中，本案可以视不同的切入视角选择 **D3** 或 **D1** 作为最接近的对比文件（本案具有多个适合作为最接近对比文件的基础）：

### 选择基础 1：以 D3 (EP1672925A1) 作为最接近的对比文件

* **技术领域与解决的问题：** D3属于多媒体平台下的流媒体交互控制领域。它解决的技术问题是**“客户端如何根据具体上下文和业务清单，动态、独立地请求并组合多个媒体流，以实现统一的协同画面呈现”**。这与目标专利在客户端通过“清单文件”识别“基础流标识符/增强流标识符”并“发起请求”的系统架构完全一致。

* **技术效果相似度：** 都是通过多流解耦、独立请求、客户端复合渲染，降低了服务器端为了适配不同终端而进行二次转码的负担和带宽限制。

* **局限：** D3的流粒度是画面级别的（如主画面+字幕/画中画），没有细化到帧内区域的“图块化（Tile-based）”空间映射。

### 选择基础 2：以 D1 (US2002080878A1) 作为最接近的对比文件

* **技术领域与解决的问题：** D1属于传统的视频编解码与增强领域。它解决的技术问题是**“如何在有限带宽下，通过基础层+增强层的分层编码架构，对视频帧内的ROI区域进行特定增强”**。这与目标专利“增强视频帧中至少一个感兴趣区域ROI”的终极编解码愿景完全一致。

* **局限：** D1是传统的信源编码层面的可伸缩编码（MPEG-4 FGS/SVC），缺乏网络分发层面的客户端清单请求机制（Manifest/URL），且增强层是全帧残差而非Tile图块。

> **结论：** 审查员通常倾向于选择 **D3** 作为最接近的对比文件，因为目标专利的权利要求构建极度依赖网络传输实体（清单文件、URL标识符、客户端独立请求）。

---

## 创造性无效评述与最薄弱技术特征

如果发起无效宣告请求，权利要求1被攻破的概率极高。其本质是将 **D3的网络分发架构（Manifest + 独立流URL请求）** 与 **D2的空间图块映射（Precinct/Tile与ROI边界对齐）** 以及 **D1的分层增强解码理念（基础流+增强流双解码器合并）** 进行了拼凑。

### 1. 结合论证路径（以D3为最接近对比文件）

* **明晰区别特征：** 相比于D3，权利要求1的区别在于：D3关联的流是独立媒体（如画中画视频），而本案关联的是“增强图块流”，且清单文件中包含的是“发信号通知关于基础帧视觉内容与图块视觉内容之间空间关系的图块位置信息”（特征D、G、H、N、Q）。

* **对比文件D2的引入：** 对比文件D2已经明确公开了在图像/视频处理中，为了对ROI进行柔性处理，可以将图像空间划分为不重叠的“分区/图块（Precincts/Tiles）”，并公开了“获取ROI坐标后，将其向外圆整到最近的图块/分区边界，从而确定需要操作的图块数据包”（完全对应特征G、H、J）。

* **结合提示：** 本领域技术人员在面对D3提出的“如何将完全不同的服务类型组合成相干显示（\[0006\]）”的教导下，为了将这种多流交互架构应用到视频帧内局部的ROI空间精细增强上，自然有动机引入D2所公开的图块化/分区空间坐标映射技术。将D2的空间映射关系写入D3的XML清单文件中（转化为特征N的图块位置信号），属于本领域的常规技术手段。

* **解码与修改：** 独立解码并进行混合替换（特征O、P、Q、R、S）已被D1（双解码器分别解码基础层与增强层残差并Combiner混合）以及D3（独立子系统actuate并协同渲染）所公开或给出技术启示。

### 2. 本专利最薄弱的技术特征（极易被突破点）

* **特征M（流标识符包括URL的至少一部分）：** 这在D3中是极其标准配置（Internet links/GUIDs映射），属于成熟互联网技术的直接套用。

* **特征G、H（基于ROI和图块位置确定重叠图块）：** 被D2完美读入。D2的“rounds the ROI coordinates outward to the nearest precinct boundaries”就是基于ROI位置和图块位置确定重叠图块的法律等同/相同公开。

* **特征S（替换或混合）：** D1的Combiner 256和D3的混合显示已经将“混合/替换”的技术实质公开殆尽。

---

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

虽然目前的D1-D3组合已经对权利要求1构成了严重的创造性威胁，但为了达成**“毫无异议的绝对破坏（如直接组合出特征N）”**，建议开展针对性强化检索：

### 1. 锁定关键区别特征的专业术语（Keywords）

目前唯一需要加强说服力的是**“在清单文件（Manifest）中携带图块（Tile）的空间位置信息/空间关系信号，供客户端解析并请求”**。

* **中文检索词：** 清单文件、描述文件、MPD、M3U8、图块、切片、感兴趣区域、空间关系、条带、Tile、ROI、SRD（空间关系描述）。

* **英文检索词：** "Manifest", "MPD", "M3U8", "DASH", "Tile", "Sub-picture", "ROI", "Region of Interest", "Spatial Relationship Description", "SRD", "independent decoding".

### 2. 重点检索的标准组织与文献库

目标专利的特征K、L、M、N、O、P的组合，带有极强的 **MPEG-DASH (Dynamic Adaptive Streaming over HTTP)** 标准的技术烙印。

* **重点追踪标准：** **ISO/IEC 23009-1 (MPEG-DASH Part 1)**，特别是其关于 **SRD (Spatial Relationship Description)** 的扩展提案。MPEG在2014-2015年前后深度标准化了“如何在MPD清单文件中使用SRD属性向客户端发信号通知基础视频与各局部Tile流之间的空间相对位置和尺寸”。

* **检索方向：** 检索2014至2018年期间，涉及“DASH SRD VR/HEVC Tile streaming”相关的专利申请（如三星、高通、华为、爱立信、诺基亚等公司在3GPP或MPEG的提案及衍生专利）。这些文献会100%完美再现特征K、L、M、N、O、P的结合。

### 3. 分类号建议（IPC/CPC）

在检索时限制以下分类号，能够精准命中该跨界领域（视频编码+网络传输）：

* **H04N21/845**（媒体流的块化、分段或分层描述，如MPD文件结构）

* **H04N21/2343**（根据客户端能力或请求在网络侧/转码侧进行涉及ROI或Tile的处理）

* **H04N19/167**（视频编码中的感兴趣区域ROI技术）

* **H04N19/70**（视频编码中的语法细节、清单或文件格式信号）

作为一名经验丰富的专利代理师，我将严格依据目标专利说明书的逻辑架构，结合各对比文件（以下用公开号指代）的原始文本，对权利要求1进行深度解析、特征比对、最接近对比文件选择以及无效宣告请求的策略分析。

---

## 一、 权利要求1的技术特征拆解与技术本质分析

根据目标专利的文本结构，权利要求1所保护的“用于增强视频流的视频帧中的至少一个感兴趣区域ROI的方法”，其核心发明点在于：**客户端基于清单文件（Manifest File）发信号通知的基础流与增强图块流之间的空间关系（图块位置信息），自适应地请求并独立解码可重叠的、独立解码的增强图块（Tiles），并由双解码器架构分别解码后进行替换或混合渲染，从而在不增加整体基础流解码负担的前提下，实现局部ROI的画质选择性增强。**

为了进行精确的对比分析，我们将权利要求1拆解为以下 19 个技术特征（A 至 S）：

* **前序部分与输入端：**

* **特征A**：所述方法包括客户端设备接收定义至少一个基础流的基础视频帧的媒体数据；

* **特征B**：所述基础流与一个或多个增强图块流相关联；

* **特征C**：其中增强图块流包括定义图块化视频帧的媒体数据；

* **特征D**：图块化视频帧包括与用于增强基础视频帧的图像区域的子区域中的视觉内容的媒体数据相关联的图块；

* **特征E**：其中增强图块流的媒体数据可独立于所述基础流的媒体数据进行解码；

* **控制与流选择逻辑（清单文件驱动）：**

* **特征F**：确定与所述基础流的视频帧中的至少一个感兴趣区域的位置相关联的ROI位置信息；

* **特征G**：基于ROI位置信息和图块位置信息来确定一个或多个增强图块流；

* **特征H**：其中所述一个或多个所确定的增强图块流定义与至少一个ROI至少部分地重叠的一个或多个图块；

* **特征I**：客户端设备请求所述一个或多个所确定的增强图块流的媒体数据；

* **特征J**：所请求的媒体数据的图块化视频帧的一个或多个图块与基础视频帧的图像区域中的至少一个预定的感兴趣区域相关联；

* **特征K**：所述媒体数据是由客户端设备基于清单文件而请求的；

* **特征L**：所述清单文件包括至少一个基础流标识符和与该至少一个基础流标识符相关联的一个或多个增强图块流标识符；

* **特征M**：流标识符包括URL的至少一部分或包括用于确定这样的URL的信息；

* **特征N**：清单文件还包括用于向所述客户端设备发信号通知关于所述基础流的视频帧中的视觉内容与所述一个或多个增强图块流的图块化视频帧的图块中的视觉内容之间的空间关系的图块位置信息；

* **解码架构与输出端：**

* **特征O**：连接到所述客户端设备的第一解码器基于至少一个基础流的媒体数据生成基础视频帧；

* **特征P**：连接到客户端设备的第二解码器基于一个或多个增强图块流的媒体数据生成图块化视频帧；

* **特征Q**：所生成的图块化视频帧包括在至少一个感兴趣区域中形成增强视觉内容的一个或多个图块；

* **特征R**：渲染设备通过基于图块化视频帧的增强视觉内容的至少一部分修改所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分来形成包括增强感兴趣区域的视频帧；

* **特征S**：所述修改包括用图块化视频帧的增强视觉内容的至少一部分替换或混合所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分。

---

## 二、 对比文件特征比对表格

以下将目标权利要求的各个技术特征，与三份对比文件进行逐项比对。

* **D1**: US20060262345A1 (Method and device for transmitting and receiving image sequences between a server and client)

* **D2**: CN101262604A (一种感兴趣区优先传输的可伸缩视频编码方法)

* **D3**: WO2009003885A2 (VIDEO INDEXING METHOD, AND VIDEO INDEXING DEVICE)

---

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

在创造性评判中，**D1 (US20060262345A1)** 和 **D2 (CN101262604A)** 均有资格作为本申请创造性分析的**最接近对比文件（共同作为起点）**。

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

* **目标专利**解决的技术问题是如何在基于流媒体框架下，通过独立、弹性的图块传输，既节省带宽，又能让客户端对视频画面中的局部ROI区域进行画质增强渲染。

* **D1 (US20060262345A1)** 解决的技术问题是：在有限带宽和终端解码能力下，如何让客户端动态请求并自动追踪视频中的空间子部分（Spatial Sub-parts / Slice Groups），从而只传输和解码用户关心的运动区域，降低传输带宽。**这与目标专利在“如何空间定位、独立请求和独立解码局部区域”的技术手段和流媒体控制架构上最为接近。**

* **D2 (CN101262604A)** 解决的技术问题是：在无线或窄带流媒体传输中，如何结合可伸缩视频编码（SVC），通过发送基本层提供粗略图像，并在信道宽裕或用户指定时，优先提供ROI增强层数据，从而提升ROI区域的主观画质并节省总带宽。**这与目标专利在“基础流+局部区域画质增强层”这一分层级复合渲染的技术构思上最为接近。**

### 2. 从技术效果角度分析

* **D1** 实现了“客户端自适应空间相交请求、服务器切片（图块化）独立发送与解码”的效果，其网络交互行为与目标专利高度一致。

* **D2** 实现了“基础画质画面 + ROI高画质（残差）画面 = 增强型ROI全景画面”的视觉增强效果，其最终呈现形式与目标专利高度一致。

**结论**：在无效宣告程序中，最有力、最符合逻辑的创造性进攻策略是**以D1作为第一主体（最接近对比文件）**，用于构建整个网络流请求、空间图块匹配以及独立解码的骨架；**同时结合D2**，用于引入对基础流和局部图块进行多解码器复合渲染增强画质的概念。

---

## 四、 未被最接近对比文件公开的特征之评述

假设以 **D1 (US20060262345A1)** 为最接近的对比文件，其未公开的特征主要分布在控制层的**清单文件（特征K、L、N）**，以及后端的**双解码器及替换/混合渲染机制（特征P、Q、R、S）**。

### 1. 渲染与多解码器特征（特征P、Q、R、S）是否被其他对比文件公开？

**已被 D2 (CN101262604A) 实质公开。**

* **特征P（第二解码器）与特征Q、R、S（混合/替换渲染）**：D1中独立解码Slice Group是为了单独显示选定区域（类似于裁剪放大）。而D2则明确公开了双编解码架构——基本层编解码器由H.264标准实现，增强层（残差层）编解码器采用单独设计的CAVLC编解码器（即对应“第一解码器”和“第二解码器”）。同时，D2公开了在最后阶段“将增强层输出的图像残差信号与基本层输出的图像信号进行复合生成最终的输出视频序列”，这正是通过将图块化的增强内容（残差）与基础视频帧进行“混合”来增强ROI视觉效果的渲染手段。

### 2. 清单文件相关特征（特征K、L、N）是否被其他对比文件公开？

**未被任何一份对比文件（D1、D2、D3）公开。**

* **特征K、L、N** 构成了将这套图块化流传输机制引入现代标准流媒体框架（如MPEG-DASH等基于Manifest清单控制的架构）的关键。

* 虽然 **D3 (WO2009003885A2)** 公开了在SEI消息（`user_data_payload_byte`，参见其表1和表2）中携带ROI的坐标（`roi_x_16`, `roi_y_16`）以及宏块对齐信息（`macroblock_alignment`），以向解码器发信号通知空间关系，但这是将空间关系隐埋在**视频比特流的SEI网络抽象层（NAL）单元**内部，而非公开在客户端设备基于的**清单文件（Manifest file）**中。

* 清单文件（如`.mpd`或`.m3u8`）是在不解析视频比特流的前提下，在应用层高空提供基础流URL标识符、增强流URL标识符以及它们空间关系信号的独立控制文档。这一特征在三份对比文件中均处于**完全缺失**状态。

---

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

如果在无效程序中对该专利发起创造性或新颖性攻击，本权利要求**防守最稳固、最难被攻破的阻击点（即无效请求方最薄弱的攻击点）**是：

> **特征K + 特征L + 特征N 的组合（即：基于包含基础/增强流标识符、并包含发信号通知两者空间关系的图块位置信息的“清单文件”来由客户端请求媒体数据）。**

### 原因分析：

1. **现有技术的架构鸿沟**：D1基于的是JPIP（JPEG2000交互协议）的动态交互控制，空间 offset 都是直接拼装在 HTTP 请求的 URL 参数中（如 `roff=113,237`），由服务器实时计算返回；D2 和 D3 则是基于传统 H.264/AVC 架构，其空间关系（Slice Group / FMO 网格）是固化在图像参数集（PPS）或 SEI 消息这种**媒体流内部的元数据**里。

2. **技术方案的实质改变**：目标专利将空间关系和流的关联“上移”到了**清单文件**（Manifest File）中。这使得客户端在根本不需要下载、解复用或解析任何实际视频帧/SEI 消息之前，就能通盘获知“哪个URL对应的增强图块流对应基础画面的哪个象限”，从而实现极低延迟、极低开销的流媒体自适应切换。这种“清单文件驱动的空间关系发信”在2006-2009年的现有技术中缺乏技术启示，具有非常显著的创造性高度。

---

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

为了成功无效掉包含上述“清单文件”特征的权利要求1，必须打破清单文件与空间图块发信之间的技术壁垒。建议调整检索策略如下：

### 1. 检索关键词调整与扩展

必须引入现代流媒体协议及其空间扩展的专业术语。

* **核心控制词**：`"Manifest"`（清单文件）、`"MPD"`（媒体演示描述）、`"Playlist"`（播放列表）、`"Media Playlist"`。

* **空间/图块词**：`"Tile"`（图块）、`"SRD"`（Spatial Relationship Description，空间关系描述）、`"HEVC Tile"`、`"OMAF"`（全方位媒体格式）、`"ROI"`（感兴趣区域）。

* **构造检索式示例**：

* `(Manifest OR MPD OR "Playlist") AND ("Tile" OR SRD OR "Spatial Relationship") AND (ROI OR "Region of interest") AND (Enhance* OR "Base Layer" OR "Enhancement layer")`

### 2. 目标标准组织（SSO）文献检索——重中之重

由于“清单文件（Manifest）”通常是流媒体标准格式的核心组件，常规的早期专利文献可能较少将视频图块与清单文件融合。应全力检索以下标准组织的提案（Tdoc/Contributions）：

* **MPEG 工作组 (ISO/IEC JTC1/SC29/WG11)**：重点检索 2010年-2015年 间关于 **MPEG-DASH (Dynamic Adaptive Streaming over HTTP)** 标准制定的早期提案。特别是涉及到 **DASH SRD (Spatial Relationship Description)** 的技术提案。SRD 允许在 MPD（清单文件）中描述各个切片流（Tiles）在屏幕上的空间坐标和比例关系，这与特征N完全吻合。

* **3GPP SA4 (Codecs and Media Working Group)**：检索关于 3GPP 流媒体服务（PSS）以及基于 DASH 的立体视频/局部增强视频传输的会议输入文档。

### 3. 关键专利分类号（IPC/CPC）精准锁定

缩小检索范围至现代基于清单的网络流媒体分发小类：

* **H04N 21/8456**：与内容或元数据的结构化有关的元素，如片段化、分块（Chunking）（流媒体切片及清单文件核心分类）。

* **H04N 21/4402**：客户端的数据处理，如改变流的特性、分辨率或画质增强。

* **H04N 19/30**：可伸缩编码（Scalable coding）技术。

* **H04N 19/167**：相对于感兴趣区域（ROI）的编码或处理。

通过锁定 2010-2014 年间关于 MPEG-DASH SRD 技术演进的公开专利或标准提案，将有极高概率检索到“在清单文件中明文携带图块与基础流空间几何关系坐标，以供客户端按需请求ROI增强流”的冲突现有技术，从而彻底攻克这一防御堡垒。

作为一名经验丰富的专利代理师，我针对涉案专利权利要求1及提供的三份对比文件进行深度法律与技术分析。

本案的目标专利核心在于一种**基于清单文件（Manifest File）驱动的、客户端主导的视频流感兴趣区域（ROI）流式传输与动态渲染增强方案**。其技术手段是通过低分辨率的“基础流”提供全景框架，并解耦出可独立解码的“增强图块（Tile）流”来按需提升ROI区域的画质，在客户端通过双解码器架构并行处理，最终在渲染层进行替换或混合。

以下是针对权利要求1（特征A至S）的全面无效宣告分析及检索策略：

---

## 一、 涉案专利权利要求特征解构与解析

根据权利要求1的架构，其技术方案可解构为以下四个核心技术模块：

1. **架构定义（特征A-E）**：定义了“基础流”与“独立解码的增强图块流”的空间关联空间架构。

2. **策略决策（特征F-H）**：客户端基于ROI位置与图块位置的空间重叠度，动态计算并锁定目标增强图块流。

3. **信号与传输（特征I-N）**：基于包含URL、空间关系信号（图块位置信息）的清单文件（Manifest File），由客户端发起动态请求。

4. **解码与渲染（特征O-S）**：客户端采用双解码器并行生成基础帧与图块帧，由渲染设备在ROI区域执行替换（Replace）或混合（Blend）的图像重建。

---

## 二、 对比文件特征比对表格

以下为涉案专利权利要求1的技术特征与各对比文件（D1、D2、D3）原文的详细比对。

* **D1**: `US20090300692A1` (SYSTEMS AND METHODS FOR VIDEO STREAMING AND DISPLAY)

* **D2**: `US7894531B1` (Method of compression for wide angle digital video)

* **D3**: `WO2012168356A1` (LOCATING AND RETRIEVING SEGMENTED CONTENT)

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

---

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

在对本案进行创造性（Invalidity/Obviousness）论证时，**适合作为最接近对比文件的为：D3 (`WO2012168356A1`) 和 D1 (`US20090300692A1`)**。本案存在两个平行且均具有极高威胁度的无效主线逻辑：

### 主线一：以 D3 为最接近的对比文件（主攻“清单文件信号驱动流机制”）

* **技术问题与效果重合度**：D3 聚焦于解决在多CDN/分布式网络架构下，如何高效定位和检索**空间分割视频内容（Spatially Segmented Content / Tiled Video）**的技术问题。其达到了在客户端进行平移（Panning）、缩放（Zooming）交互时，以最小延迟交付空间切片（Tile/Segment）、消除画面卡顿（Glitch）的技术效果。这与涉案专利“增强视频流中的ROI”所面向的交互式空域增强、提升用户观看体验的整体技术问题与效果完全一致。

* **特征覆盖优势**：D3 **毫无异议地公开了涉案专利最核心的“清单文件控制机制”（特征K、L、M、N）**。D3明确提出了使用Manifest File Template生成Dynamic Manifest File，其中不仅包含了各空间切片的标识符（URL），还显式地向客户端发信号通知了各切片之间的**空间关系（Spatial Relation）**（对应特征N）。因此，D3奠定了极佳的上位架构基础。

### 主线二：以 D1 为最接近的对比文件（主攻“全景流+图块残差叠加渲染机制”）

* **技术问题与效果重合度**：D1 旨在解决高分辨率视频流传输中，受限于客户端显示分辨率或网络带宽，无法全局传输高清画面，进而通过传输全景低清Overview流加局部高清预推流（Pre-fetch）来满足终端虚拟PTZ（Pan-Tilt-Zoom）交互需求的技术问题。这与涉案专利通过基础视频帧叠加增强图块的实质物理图景几乎完全等同。

* **特征覆盖优势**：D1 **毫无异议地完全公开了涉案专利的后端渲染层特征（特征R、S）以及ROI重叠计算特征（特征G、H）**。D1详细推导了当用户的ROI矩形框与切片网格（Slice Grid）发生位置错位与部分重叠时，如何计算“多余像素开销（Pixel Overhead）”（D1图7及[0083]），并且极为精准地公开了“将Overview视频帧上采样后，在ROI区域与独立的P-slice高清残差流进行叠加混合重建”的图像处理细节（特征S）。

---

## 四、 未被最接近现有技术公开的特征比对与结合路径

由于D3和D1各长于涉案专利的不同阶段（D3偏重前端控制信令，D1偏重后端图像处理），因此通过**D3与D1的交叉结合**，可以完美实现对权利要求1全特征的无缝覆盖。

### 路径方案A：以D3为最接近现有技术 + 结合D1

1. **D3未显式公开的特征**：双解码器管线（特征O、P）的字面表述，以及用图块流数据与基础流在ROI区域进行“替换或混合（Replace or Blend）”的具体像素级渲染算法（特征S）。

2. **D1的补足情况**：D1在[0069]和图6中明确公开了Overview Video（基础流）与Independent P slices（增强图块流）的复合编码架构，并明确指出在客户端需要解码这两部分流，将重构的Overview视频上采样后与P-slices残差信号相加（此即为最典型的像素混合/叠加修改方式），完美公开了特征O、P、R、S。

3. **结合启示（Motivation）**：D3已经明确指出了其空间分割段可以采用**SVC（可伸缩视频编码）的增强层（Enhancement Layer）**或HAS的高码率分块（[p0005]）。本领域技术人员在实现D3所述的“空间分块动态无缝合成（Seamless Switching）”时，为了优化编解码效率，极易想到引入D1所公开的“基础流+残差Slice流”的叠加混叠技术方案。这种结合属于为了实现空域分块渲染而采用的常规技术手段的组合，不存在技术障碍。

---

## 五、 涉案专利最薄弱的技术特征与防御边界

如果在无效程序中作为请求人，应当集中火力猛攻涉案专利在法律层面上**保护范围最宽、防守最薄弱的特征——特征N（清单文件中包含基础流与增强流的空域空间关系信息）**。

* **薄弱原因分析**：特征N是涉案专利连接信令层（清单文件）与物理渲染层（图块位置）的关键纽带。涉案专利企图通过“在清单文件中写入空间关系信号”来构建对普通DASH或HLS流媒体协议的创造性壁垒。然而，**这一特征已被D3 [p0071] 处的原文以极高的显性度直接击穿**：

> D3 原文 [p0071]: *"The MF may comprise a header section 304 and a segment section 306... Global information may include... the **relation between the segments (e.g. the temporal or spatial relation between segments)**."*

* **对抗策略**：专利权人可能会抗辩称D3的“空间关系”是指不同CDN之间的路由映射关系，而非视频像素空域几何关系。但专利代理师可联合D3 [p0004] 处提及的“spatially segmented content (e.g. tiled video)”以及本领域公知常识（如MPEG-DASH SRD, Spatial Relationship Description标准规范）进行有力反驳，证明将Tile的空间几何坐标写入Manifest中以向客户端发信号通知空间关系，在标准流媒体领域早已成为现有技术的一部分。

---

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

为了在诉讼或无效请求中形成“双保险”，彻底锁死专利权人的修改与答辩空间，建议启动第二轮精准检索，检索策略配置如下：

### 1. 检索核心关键词扩展

* **空间划分/图块层**：`Tile` / `Tiled Video` / `Slice Grid` / `Spatial Segment` / `HEVC Tiles` / `空域分块` / `图块化`

* **信令/清单文件层**：`Manifest File` / `MPD` / `M3U8` / `SRD (Spatial Relationship Description)` / `清单文件` / `空间关系描述`

* **ROI/渲染层**：`Region of Interest` / `Base Layer` / `Enhancement Layer` / `Alpha Blending` / `残差叠加` / `双解码器`

### 2. 精准分类号（IPC/CPC）交叉锁定

* **H04N21/8456**：具有空间或时间分段的媒体流传输（针对Segmented/Tiled Content的最精准分类号）。

* **H04N21/4402**：客户端终端的视频数据流修改/改动（针对特征R、S的客户端渲染替换）。

* **H04N19/70**：涉及视频编码流中的语法元素、信令或清单文件（针对特征L、M、N的清单文件信号）。

* **H04N19/30**：可伸缩视频编码（SVC）技术（针对基础流与增强流的解耦解码）。

### 3. 目标源与时间窗截击

* **追溯标准提案（重要突破口）**：强烈建议检索 **MPEG工作组在2012-2015年间关于 ISO/IEC 23009-1 (MPEG-DASH) 第二版或扩展案的提案（Input/Output Documents, MPEG m-numbers）**，特别是有关 **DASH-SRD (Spatial Relationship Description)** 的技术提案。涉案专利将空间关系写入清单文件的构想，极大概率抄袭或借鉴了当时MPEG标准制定过程中的专家提案。一旦检索到公开日早于涉案专利优先权日的标准提案，将直接构成单篇“毫无异议公开”的绝对毁灭性证据。

作为一名资深的专利代理师，我将严格依据目标专利说明书以及三份对比文件的原文内容，对权利要求1的各个技术特征进行客观、严谨的侵权/无效分析（即拆解比对）。

在本次分析中，三份对比文件分别使用其公开号指代如下：

* **D1**：`US20140016703A1`

* **D2**：`US20140079126A1`

* **D3**：`US20140089990A1`

---

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

以下将权利要求1拆解为技术特征 A 至 S，并逐一结合对比文件原文出处进行实质比对。

### 1. 特征A: 所述方法包括客户端设备接收定义至少一个基础流的基础视频帧的媒体数据

* **D1 (US20140016703A1) 比对分析：** 实质公开。参见D1原文 `[0007]`：“encodes a first reduced version of a video stream of the HD resolution with a standard existing codec... to obtain a base layer.” 以及 `[0040]` / `[0114]`，解码器接收并解码 base layer bit-stream。基础层即对应基础流，包含基础视频帧。

* **D2 (US20140079126A1) 比对分析：** 未明确公开基础流与增强流的分层架构，D2主要基于HEVC单层架构下的图块（Tile）划分及图块组（Tile Group）约束。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3原文 `[0010]` 及 `[0089]`：“selecting one or more spatial segment streams associated with a first spatial representation...”。D3支持空间分层，其低分辨率的非分块流（Full Stream/Source Stream）即对应基础流。

### 2. 特征B: 所述基础流与一个或多个增强图块流相关联

* **D1 (US20140016703A1) 比对分析：** 实质公开。参见D1原文 `[0007]`：“Next, it encodes the pixel differences... to obtain an enhancement layer. According to this UHD codec, the enhancement layer is organized in a way that provides spatial access”。D1的增强层（Enhancement Layer）被划分为多个独立可解码的块组，实质公开了与基础流相关联的增强图块流。

* **D2 (US20140079126A1) 比对分析：** 未公开。D2不涉及基础流与增强分块流的关联，仅在同单一码流内划分图块。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3图4及 `[0088]`-`[0093]`。说明书公开了第一空间表示（非分块的基础源流）与第二、三空间表示（空间切分的图块流，如 `stream1_1.avi`）通过同一个清单文件（SMF）相互关联。

### 3. 特征C: 其中增强图块流包括定义图块化视频帧的媒体数据

* **D1 (US20140016703A1) 比对分析：** 实质公开。参见D1原文 `[0095]`：“blocks corresponding to potential regions of interest are coded without dependencies upon other blocks...”。这些独立编码的块组（groups of blocks）在空间上构成了图块化视频帧。

* **D2 (US20140079126A1) 比对分析：** 毫无异议公开。参见D2原文 `[0004]` 及 `[0026]`：“An encoded video sequence including a temporal series of pictures, a picture being partitioned into a plurality of tiles...”。公开了图块化视频帧的媒体数据。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3原文 `[0053]`：“Spatially segmented content may be generated by spatially dividing each image frame of a source stream, e.g. an MPEG-type stream, into a number spatial segment frames.” 这里的空间分段流即为增强图块流，定义了图块化帧。

### 4. 特征D: 图块化视频帧包括与用于增强基础视频帧的图像区域的子区域中的视觉内容的媒体数据相关联的图块

* **D1 (US20140016703A1) 比对分析：** 实质公开。参见D1原文 `[0007]`：“encodes the pixel differences between an up-scaled version of an encoded HD image and the corresponding original UHD image to obtain an enhancement layer.” 其增强层中的各个块（Blocks）正是用于增强基础层对应子区域的视觉内容（分辨率增强）。

* **D2 (US20140079126A1) 比对分析：** 未公开增强层图块与基础帧的对应增强关系。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3原文 `[0060]` 及 `[0110]`：“A second spatial representation... associated with a 4096x2160 resolution source stream, which is spatially segmented...”。高分辨率的图块流用于增强低分辨率基础流在对应子区域的视觉内容。

### 5. 特征E: 其中增强图块流的媒体数据可独立于所述基础流的媒体数据进行解码

* **D1 (US20140016703A1) 比对分析：** 未公开。D1的增强层解码强依赖于基础层。参见D1原文 `[0102]` 和 `[0201]`：“The information contained in this residual enhancement layer X is the error resulting from the base layer encoding and up-sampling.” 以及 `[0114]`，解码增强层前必须先解码并上采样基础层（Base Layer），无法独立于基础流解码。

* **D2 (US20140079126A1) 比对分析：** 未涉及分层，不适用。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3原文 `[0004]`、`[0053]` 和 `[0090]`。D3中的各个空间分段流（Spatial Segment Streams）本身就是独立的标准视频流（如 `.avi` 或 `.m2ts`），各个 Representation 之间或图块流之间可以完全独立由客户端的普通解码器解码，无需依赖基础流的残差叠加。

### 6. 特征F: 确定与所述基础流的视频帧中的至少一个感兴趣区域的位置相关联 of the ROI位置信息

* **D1 (US20140016703A1) 比对分析：** 实质公开。参见D1原文 `[0098]`：“a decoder infers ROIs as they are inferred by an encoder, from the base layer...”。D1通过分析基础流的运动矢量或块大小，由解码器自动确定ROI的位置信息。

* **D2 (US20140079126A1) 比对分析：** 毫无异议公开。参见D2原文 `[0005]`：“Signaling indicating a region of interest (ROI) may be received by the video decoder, or an ROI otherwise determined... allows the end user to identify a region of interest in the displayed video content”。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3原文 `[0023]` 及 `[0099]`：“receiving user input associated with a region of interest, said region of interest defining a selected area...”。

### 7. 特征G: 基于ROI位置信息和图块位置信息来确定一个或多个增强图块流

* **D1 (US20140016703A1) 比对分析：** 实质公开。参见D1原文 `[0098]` 及 `[0168]`-`[0171]`。根据从基础流推导出的ROI map（即图块位置映射），确定增强层中哪些宏块组（图块流）需要被提取和解码。

* **D2 (US20140079126A1) 比对分析：** 毫无异议公开。参见D2原文 `[0005]` 和 `[0021]`：“The tiles that the ROI overlaps may be said to cover the ROI... decoding the tiles that the ROI overlaps... may be sufficient”。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3原文 `[0024]`、`[0099]` 和 `[0100]`：“determining the spatial segment frames overlapping said selected region of interest”。

### 8. 特征H: 其中所述一个或多个所确定的增强图块流定义与至少一个ROI至少部分地重叠的一个或多个图块

* **D1、D2、D3 比对分析：** 三份对比文件均实质公开或毫无异议公开了此特征。

* **D1**：参见 `[0095]`，ROI内的块独立编码成组。

* **D2**：参见 `[0021]`：“An ROI 204 is contained within two of the tiles 202a, 202c. The tiles 202a, 202c that the ROI 204 overlaps may be said to cover the ROI.”

* **D3**：参见 `[0100]`：“determining the spatial segment frames overlapping said selected region of interest”。

### 9. 特征I: 客户端设备请求所述一个或多个所确定的增强图块流的媒体数据

* **D1 (US20140016703A1) 比对分析：** 实质公开。参见D1原文 `[0040]`：“allowing a user of the receiving device to obtain enhancement layer data from the enhancement layer corresponding the determined selectable area.”

* **D2 (US20140079126A1) 比对分析：** 实质公开。参见D2原文 `[0005]`，客户端选择ROI并仅解码该部分重叠的图块组。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3原文 `[0010]` 及 `[0101]`：“requesting at least one delivery node... to deliver said at least one selected spatial segment stream to said client”。

### 10. 特征J: 所请求的媒体数据由图块化视频帧的一个或多个图块与基础视频帧的图像区域中的至少一个预定的感兴趣区域相关联

* **D1、D2、D3 比对分析：** 均公开。选定的增强图块流在空间上完全覆盖或关联于基础帧上的ROI区域。出处同特征G、H。

### 11. 特征K: 所述媒体数据是由客户端设备基于清单文件而请求的

* **D1 (US20140016703A1) 比对分析：** 未公开。D1不依赖独立于媒体流的清单文件来请求切片，它是直接解析基础流的宏块/切片头部（Slice Header）信息（参见D1图8及 `[0175]`）。

* **D2 (US20140079126A1) 比对分析：** 实质公开。参见D2原文 `[0004]`：“Signaling indicating parameters of the at least one or more tile group may be received... parameter may be signaled in a picture parameter set (PPS), VUI, or a SEI message.” PPS/VUI/SEI在广义上起到了控制清单的作用，但非本专利所述的独立空间清单文件。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3原文 `[0010]` 及 `[0054]`：“a client receiving a spatial manifest data structure (SMF)...”。客户端完全基于该空间清单文件请求数据。

### 12. 特征L: 所述清单文件包括至少一个基础流标识符和与该至少一个基础流标识符相关联的一个或多个增强图块流标识符

* **D1、D2 比对分析：** 未公开。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3图4的XML结构及 `[0088]`-`[0093]`。清单文件（SMF）中同时包含了 `full_stream.avi`（基础流标识符）以及与其关联的 `stream1_1.avi` 等多个增强分段流的标识符。

### 13. 特征M: 流标识符包括URL的至少一部分或包括用于确定这样的URL的信息

* **D1、D2 比对分析：** 未公开。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3图4及图2E的 `Updated SMF 294`。明确公开了流标识符为标准 URL（如 `rtsp://[video.content.com/stream1_1.avi](https://video.content.com/stream1_1.avi)` 或 `cache-1.cdn_A/res/`）。

### 14. 特征N: 清单文件还包括用于向所述客户端设备发信号通知关于所述基础流的视频帧中的视觉内容与所述一个或多个增强图块流的图块化视频帧的图块中的视觉内容之间的空间关系的图块位置信息

* **D1、D2 比对分析：** 未公开。

* **D3 (US20140089990A1) 比对分析：** 毫无异议公开。参见D3图3、图4及图7A/7C。清单文件中明确包含 `DisplayPosition="1000,500"` 或矩阵坐标 `(NumberOfColumns, NumberOfRows)` 等空间位置信息，用于发信号通知基础帧与各增强图块流之间的空间几何/视觉对应关系。

### 15. 特征O: 连接到所述客户端设备的第一解码器基于至少一个基础流的媒体数据生成基础视频帧

* **D1 (US20140016703A1) 比对分析：** 实质公开。参见D1原文 `[0114]`：“The base layer bit-stream is received and decoded by the standard base video decoder to produce the decoded base layer.”

* **D2 (US20140079126A1) 比对分析：** 未公开双解码器架构。

* **D3 (US20140089990A1) 比对分析：** 实质公开。参见D3原文 `[0130]` 和 `[0137]`：“These devices generally allow only a single decoder instance running at the same time... In a further embodiment, the media engine may comprise two or more decoders for decoding data...”。D3公开了使用多个解码器实例分别解码不同的流。

### 16. 特征P: 连接到客户端设备的第二解码器基于一个或多个增强图块流的媒体数据生成图块化视频帧

* **D1 (US20140016703A1) 比对分析：** 实质公开。参见D1原文 `[0114]`：“At the same time, the enhancement layer bit-stream is decoded at step 225...”。D1采用了基础层解码器和增强层解码器的双解码器并行/协作架构。

* **D2 (US20140079126A1) 比对分析：** 未公开。

* **D3 (US20140089990A1) 比对分析：** 实质公开。参见D3原文 `[0137]`，采用第二/多个解码器并行解码各分段图块流。

### 17. 特征Q: 所生成的图块化视频帧包括在至少一个感兴趣区域中形成增强视觉内容的一个或多个图块

* **D1、D2、D3 比对分析：** 三份文件均公开了此通用特征，即解码出的增强图块在ROI区域提供更高分辨率/质量的视觉内容。

### 18. 特征R: 渲染设备通过基于图块化视频帧的增强视觉内容的至少一部分修改所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分来形成包括增强感兴趣区域的视频帧

* **D1 (US20140016703A1) 比对分析：** 毫无异议公开。参见D1原文 `[0114]`-`[0117]`：“is added to a residual enhancement layer X at step 215... to obtain the decoded enhancement layer.” D1通过将增强层解码出的残差视觉内容与基础层上采样的视频帧进行像素级相加（即修改基础帧的ROI），形成最终的增强视频帧。

* **D2 (US20140079126A1) 比对分析：** 未公开此种基于基础帧修改/融合的操作。

* **D3 (US20140089990A1) 比对分析：** 未明确公开“修改基础帧”的融合操作。D3采用的是“Stitching（缝合/拼接）”机制（参见 `[0138]`），即直接将多个解码后的增强图块拼接成完整的ROI画面进行分屏或全屏替换显示，而非在低分辨率基础帧上进行修改或混合残差。

### 19. 特征S: 所述修改包括用图块化视频帧的增强视觉内容的至少一部分替换或混合所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分

* **D1 (US20140016703A1) 比对分析：** 毫无异议公开（混合）。D1通过残差叠加（混合Blending/Addition）的方式修改基础帧视觉内容（参见 `[0114]`）。

* **D2、D3 比对分析：** 未明确公开这种针对基础流的“替换或混合”修改机制。

---

## 二、 特征比对表

根据上述客观分析，各对比文件对权利要求1各项技术特征的公开情况总结如下：

---

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

在创造性分析过程中，**D3 (US20140089990A1)** 和 **D1 (US20140016703A1)** 均有资格作为最接近的对比文件，但侧重点不同。通常，**D3是最适合的独立第一选择**。

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

* **D3的契合度最高**：D3整体聚焦于解决“如何在现有的常规内容分发网络（CDN）架构下，高效传输超高分辨率视频的空间分段内容，以响应客户端的ROI交互（如放大、平移），而不需要改变网络基础设施”的问题（参见D3 `[0006]`-`[0009]`）。这与目标专利“客户端基于清单文件从网络节点请求特定增强图块流以增强ROI”的场景完全一致。

* **D1偏向于编解码底层**：D1解决的是“如何在块分层视频编码中消除帧内/帧间预测依赖，从而以较低的码率开销实现高效的空间随机访问”的问题（参见D1 `[0018]`、`[0094]`）。

### 2. 从技术效果角度分析

* **D3的技术效果最为接近**：D3通过在客户端解析SMF（空间清单文件），直接向CDN不同的Delivery Nodes请求各自独立的 `.avi/.m2ts` 切片流，实现了极其灵活的客户端驱动型ROI动态分发，完美契合目标专利要求“增强图块流独立于基础流解码”以及“通过URL请求”的效果。

* **D1的技术效果侧重于质量叠加**：D1通过增强层解码出残差，并与基础层相加，达到了局部图像分辨率从HD提升到UHD的增强效果（参见D1 `[0007]`）。

### 3. 最接近对比文件的公开情况及未能公开特征的交叉检索

* **选定D3作为最接近对比文件时**：

* D3已经公开了特征 A、B、C、D、**E**（独立解码）、F、G、H、I、J、**K、L、M、N**（清单文件与URL架构）、O、P、Q。

* **D3未公开的特征**：特征 R 和 S（即渲染设备通过“**替换或混合修改基础视频帧**”来形成增强帧）。D3中各个流是完全独立的，其效果是通过 `Stitching`（拼接缝合）各个独立流的帧来生成最终画面，不涉及对低分辨率基础帧的视觉内容进行“混合或残差叠加”修改。

* **该未公开特征是否被其他对比文件公开**：**被D1明确公开**。D1在 `[0114]`-`[0117]` 中完整公开了将基础层解码数据上采样后，与增强层解码出的像素残差进行“**混合/相加（added）**”来修改基础帧，从而得到最终增强图像的技术方案。

---

## 四、 提起无效请求时最薄弱的技术特征

若作为无效宣告请求人攻击目标专利的创造性，本权利要求**最薄弱（即最容易被攻破）的技术特征**是：

> **特征E（增强图块流独立解码）** + **特征K, L, M, N（基于清单文件及URL请求增强图块）**

### 原因分析：

这两组特征通常被认为是该专利区别于传统SVC（可伸缩视频编码）的核心发明点。然而，**D3已经在完全相同的多媒体交互分发场景下，毫无异议地公开了这些特征**。D3中的 Spatial Manifest File (SMF) 架构、 normalized 空间几何坐标、以及各分段流独立作为常规视频流（如 `.avi` 等 URL 资源）接受客户端请求并独立解码的机制，使得目标专利在网络分发与独立解码层面几乎没有创造性空间。

### 相对而言，专利权人的防御核心（相对稳固点）：

特征 R、S 中关于“通过**替换或混合修改基础视频帧**来形成增强帧”的表述。因为D3走向了完全的“空间独立拼接（Stitching）”路线，放弃了基础帧与增强帧的层间融合；而D1虽然有层间融合修改（残差相加），但其增强层又**无法独立于基础流解码**（不满足特征E）。

因此，无效组合策略必须是 **D3 + D1**：以D3为基础架构，引入D1的层间残差混合修改技术，并论证这种结合属于本领域技术人员为了兼顾“流独立分发”与“层间残差编解码增益”的常规选择，从而剥夺特征R、S的创造性。

---

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

为了彻底无效掉权利要求1，特别是针对其“独立解码 + 清单URL请求 + 基础帧局部替换混合”的结合体，建议开展以下定向增补检索：

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

* **IPC/CPC分类号**：聚焦于 `H04N21/2343`（涉及专用于流传输的视频数据重定格式）、`H04N21/4728`（涉及感兴趣区域ROI的选择与移动）、`H04N19/30`（可伸缩编码）以及 `H04N19/167`（基于ROI的编码）。

* **扩展检索词**：`(MPEG-DASH OR "HTTP Adaptive Streaming" OR "Manifest") AND ("Tile-based" OR "Spatial segment") AND ("Enhancement layer" OR "Residual" OR "Layered") AND ("Blending" OR "Mixing" OR "Overlay")`。

2. **追踪标准组织提案（3GPP / MPEG / DVB）**：

* 鉴于目标专利表现出强烈的 HTTP 动态自适应流媒体（DASH）空间延伸特征，应重点检索 **ISO/IEC 23009 (MPEG-DASH)** 早期关于 **SRD (Spatial Relationship Description，空间关系描述)** 的标准提案（约在2013-2015年前后）。DASH SRD 允许在 MPD（清单文件）中通过坐标宣告基础层与各个高分辨率 Tile 增强流的空间几何映射，这与特征K、L、M、N、B高度吻合。

3. **针对“混合/替换”特征（R、S）的定向检索**：

* 检索基于DASH SRD框架下，客户端如何处理低分辨率背景与高分辨率交互区域的学术论文或专利。寻找明确记载“客户端为了节省解码性能，先解码全景低码率流作为底图，当用户点击某ROI时，通过清单请求该区域的独立高码率增强Tile，并直接**用增强Tile的解码帧覆盖/替换（Overwrite/Replace）或混合（Blend）掉底图对应区域**”的现有技术。这种基于交互式全景视频（Omnidirectional / Panoramic Video）或电子翻阅（Virtual Pan-Tilt-Zoom）的早期分发方案是极佳的突破口。

作为一名经验丰富的专利代理师，我现针对目标专利（以下简称为“本申请”）的权利要求1，结合说明书的整体技术方案、发明构思以及三份对比文件（D1、D2、D3）的原文进行深度的权利要求解释、技术特征比对以及创造性最接近对比文件的分析。

---

## 一、 目标专利权利要求1的架构与技术特征分解

本申请权利要求1请求保护一种**“用于增强视频流的视频帧中的至少一个感兴趣区域ROI的方法”**，其核心技术构思在于：客户端基于清单文件（Manifest）中的关联关系及空间关系（图块位置信息），独立地请求并解码与ROI至少部分重叠的增强图块流，最终将增强图块与基础视频帧进行替换或混合，实现ROI区域的局部质量或分辨率增强。

为了进行精准比对，我们将权利要求1拆解为以下20个具体技术特征：

* **前序部分**：用于增强视频流的视频帧中的至少一个感兴趣区域ROI的方法，所述方法包括：

* **技术特征A**：客户端设备接收定义至少一个基础流的基础视频帧的媒体数据；

* **技术特征B**：所述基础流与一个或多个增强图块流相关联；

* **技术特征C**：其中增强图块流包括定义图块化视频帧的媒体数据；

* **技术特征D**：图块化视频帧包括与用于增强基础视频帧的图像区域的子区域中的视觉内容的媒体数据相关联的图块；

* **技术特征E**：其中增强图块流的媒体数据可独立于所述基础流的媒体数据进行解码；

* **技术特征F**：确定与所述基础流的视频帧中的至少一个感兴趣区域的位置相关联 of the ROI位置信息；

* **技术特征G**：基于ROI位置信息和图块位置信息来确定一个或多个增强图块流；

* **技术特征H**：其中所述一个或多个所确定的增强图块流定义与至少一个ROI至少部分地重叠的一个或多个图块；

* **技术特征I**：客户端设备请求所述一个或多个所确定的增强图块流的媒体数据；

* **技术特征J**：所请求的媒体数据的图块化视频帧的一个或多个图块与基础视频帧 of the 图像区域中的至少一个预定的感兴趣区域相关联；

* **技术特征K**：所述媒体数据是由客户端设备基于清单文件而请求的；

* **技术特征L**：所述清单文件包括至少一个基础流标识符和与该至少一个基础流标识符相关联的一个或多个增强图块流标识符；

* **技术特征M**：流标识符包括URL的至少一部分或包括用于确定这样的URL的信息；

* **技术特征N**：清单文件还包括用于向所述客户端设备发信号通知关于所述基础流的视频帧中的视觉内容与所述一个或多个增强图块流的图块化视频帧的图块中的视觉内容之间的空间关系的图块位置信息；

* **技术特征O**：连接到所述客户端设备的第一解码器基于至少一个基础流的媒体数据生成基础视频帧；

* **技术特征P**：连接到客户端设备的第二解码器基于一个或多个增强图块流的媒体数据生成图块化视频帧；

* **技术特征Q**：所生成的图块化视频帧包括在至少一个感兴趣区域中形成增强视觉内容的一个或多个图块；

* **技术特征R**：渲染设备通过基于图块化视频帧的增强视觉内容的至少一部分修改所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分来形成包括增强感兴趣区域的视频帧；

* **技术特征S**：所述修改包括用图块化视频帧的增强视觉内容的至少一部分替换或混合所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分。

---

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

为了叙述清晰简练，本案分析中对各对比文件的指代定义如下：

* **D1**：`WO2014106651A1`，题为 *“EFFICIENT SCALABLE CODING CONCEPT”*，公开日：2014-07-10。

* **D2**：`WO2014111423A1`，题为 *“METHOD OF DISPLAYING A REGION OF INTEREST IN A VIDEO STREAM”*，公开日：2014-07-24。

* **D3**：`WO2014168972A1`，题为 *“REGION OF INTEREST SCALABILITY WITH SHVC”*，公开日：2014-10-16。

---

## 三、 对比文件技术特征详尽比对与出处分析

### 1. 各对比文件公开权利要求特征的深度剖析

#### (1) D1 (WO2014106651A1) 的公开情况

D1实质上关注的是**多层视频编码（如HEVC的可伸缩或多视角扩展）中的跨层并行处理与对齐概念**。

* **实质公开了特征A、B、C、D、O、P**：D1公开了多层视频数据流，包含基础层（Base Layer）和依赖的增强层（Dependent/Enhancement Layer），且每一层均可以划分成图块（Tiles）或WPP子流。原文 `[p0006]` 提到 *"inter-layer prediction limits the degree of parallelization in decoding layers dependent on each other via inter-layer prediction... pixels/pels within the co-located partition of the base layer picture"* 以及 `[p0028]` 提到 predictor 18 提供 *"an inter-layer prediction mode according to which block 41 is predicted on the basis of a corresponding portion of picture 2 of a lower layer."*

* **未能公开特征E（独立解码）**：D1的增强层解码由于采用了层间预测（Inter-layer prediction），其增强层技术特征的解码是**强依赖于**基础层对应协同位置（co-located）重建像素的。这从根本上排除了特征E中“增强图块流的媒体数据可独立于基础流的媒体数据进行解码”的架构。

* **未能公开特征F~N（清单文件、URL、ROI的动态请求逻辑）**：D1属于系统层/编解码层标准提案，不涉及网络传输层如DASH清单文件、URL标识符定位图块流以及客户端发起请求的逻辑。

* **未能公开特征R、S（渲染设备的替换或混合修改）**：D1通过重建合并残差信号来直接生成增强帧输出，而非在渲染设备处通过图块去“替换”或“混合”基础帧的某一部分。

#### (2) D2 (WO2014111423A1) 的公开情况

D2的构思与本申请最为契合，其核心即为解决**如何在网络流媒体（DASH）下，通过传输非全图高清、而是仅传输对应ROI区域的独立流，来达到降低超高清（UHD）传输带宽并实现用户动态选择ROI的目的**。

* **毫无异议公开了前序、特征A~D**：D2公开了将视频流细分为多个图块（Tiles），并编码为LQ（低质量）和多个HD（高清）流。`[p0031]-[p0035]`、`[p0093]-[p0096]` 提到：*"Each image (or 'frame' hereinafter) of the video stream 400 is subdivided into image portions (or 'tiles' hereinafter) 401... A plurality of encoded video streams is obtained wherein each tile T1-T8 is encoded with high quality in at least one encoded video stream."*

* **毫无异议公开了特征E（独立解码）**：D2在非可伸缩架构下（Non-scalable codec），五个基本流（503~507）相互完全独立。在其可伸缩架构下（Scalable codec），Track 1-4为增强层，Track 0为共享的基础层，D2通过使用**提取器（Extractors NALU）**来打破或接通依赖。`[p0117]`、`[p0165]` 明确指出：*"Track 1 and 3 both use Track 0 through extractors... extractors are replaced during de-encapsulation by the NAL units of the base layer... After elementary stream extraction (frame by frame), the elementary stream is decoded"*。在此机制下，Track 1或Track 3在解封装提取出完整序列后，其作为增强图块流媒体数据的轨迹，从客户端网络请求和传输调度流的层面而言，可脱离整幅图的传统束缚独立控制。更直接的是，其非伸缩方案中的高清流504-507本身即完全符合**独立于基础流进行独立解码**的含义。

* **毫无异议公开了特征F、G、H、I、J**：D2完全契合这一套ROI动态请求闭环。`[p0088]-[p0092]` 明确指出：*"the user... requests display with high quality. A request 315 is transmitted from the client device to the server device. The request comprises an identification of the region of interest... accesses the encapsulation file in order to determine... image portions of the grid that correspond to the region of interest."*

* **毫无异议公开了特征K、L、M、N（清单文件与空间关系信号发送）**：D2基于 ISO BMFF 和 DASH 协议扩展。`[p0106]-[p0109]` 指出：*"The ISO BMFF and the extension for DASH make it possible to put each track in different segment files. In such case, an initialization segment is generated. The initialization segment contains data defining and initializing the tracks... only the video tracks useful for the end user can be sent."* 此外，其通过扩展Track Header Box（`'tkhd'`，见其附录Annex B）或者Movie Header Box（`'mvhd'`，见其附录Annex C），在元数据中明确包含了基础视频帧与各图块视觉内容之间的**空间关系（即位置origin与尺寸size）**：`[p0125]-[p0126]` 毫无异议公开了特征N的图块位置信息：*"horizontal_origin, vertical_origin specifies the track's visual presentation origin of the current spatial sub-part... width and height specify the rectangular spatial sub-part visual presentation size"*。流标识符以DASH媒体段形式存在，天然包含URL的至少一部分信息（特征M）。

* **毫无异议公开了特征O、P、Q、R、S（双解码器及渲染层混合/替换）**：D2在客户端架构上，`[p0165]-[p0168]` 详细推演了多轨联合解码与图块层叠渲染过程：*“Once the three tracks are received, elementary streams contained in Tracks 1 and 3 are extracted... After elementary stream extraction, the elementary stream is decoded (step 804). Decoded frames 807 and 808, respectively belonging to Track 1 and Track 3 are shown... combined together based on the layering information ('Tile_Layer' attribute)... tile 'a' from frame 807 is shown in front... tile 'c' from frame 808 is shown in front. Therefore, Frame 811 has pixels in tiles 'a' and 'c' coming from a video stream encoded with high quality.”* 这种利用 `Tile_Layer` 优先级图层覆盖基础层图块像素的机制，完全构成了本申请特征R、S中所述的**“用图块化视频帧的增强视觉内容替换或混合所述基础流的视频帧中的感兴趣区域的视觉内容”**。

#### (3) D3 (WO2014168972A1) 的公开情况

D3侧重于**在SHVC（可伸缩HEVC）架构下实现局部ROI的可伸缩性**，以此节省非ROI区域（即非显著性CTU）的编解码带宽与计算负载。

* **实质公开了特征A~D，O~Q**：D3提出了在增强层中划分ROI与非ROI的概念。`[p0010]` 和 `[p0031]` 阐述：增强层中只对显著性CTU（Significant CTUs）进行编码，非显著性CTU（Non-significant CTUs）在SNR可伸缩时直接从协同位置的基础层复制像素，在空间可伸缩时从上采样基础层复制。

* **未能公开特征E（独立解码）**：D3是典型的强层间预测结构。非显著性CTU需要“copying the pixels from the co-located base layer”，意味着增强层的解码**完全不能**独立于基础层数据流，必须在两层完全同步且基础层解码完毕的基底上才能进行。

* **实质公开了部分特征F、G、H、J**：D3通过SEI消息来公开ROI地图（ROI Map）。`[p0041]` 原文写道：*"The enhancement layer is encoded with a Supplemental Enhancement Information (SEI) message to indicate the location of the region of interest... include the number of ROIs... address of the first CTU... column width... row height..."* 提供了通过SEI消息确定ROI空间关系并导向对应图像子区域的方案。

* **未能公开特征K、L、M（清单文件与基础/增强流标识符URL）**：D3是通过SEI消息（高层语法层）隐式或显式地向解码器发信号，未涉及外围流媒体层面的清单文件及URL分流请求控制。

* **未能公开特征R、S（渲染设备替换/混合修改）**：D3的非显著性区域复制发生在增强层**解码器内部**的重建环节，不是解码后由外围渲染设备去读取两个独立解码的视频帧通过覆盖或混合来处理。

---

### 2. 特征比对表格（特制专利代理审查视角）

下表详细罗列了本申请权利要求1中各项技术特征与对比文件D1、D2、D3的逐项比对结果及具体原文出处。

---

## 四、 创造性分析：最接近对比文件（D1/D2/D3）的选择与确立

在创造性审查（三步法）过程中，选择**最接近的对比文件**（最适宜的起步点）主要根据**技术领域是否相同、发明解决的技术问题以及达到的技术效果是否最接近**，或者**公开权利要求技术特征的数量**来确定。

### D2 (`WO2014111423A1`) 是本申请绝对唯一的“最接近对比文件”

1. **技术领域与构思完全一致**：本申请与D2均属于**网络流媒体传输及局部ROI增强**领域。两者针对的核心痛点完全一致——即在超高清视频传输中，如何避免为了增强局部ROI而被迫传输整幅高清图像所带来的巨大带宽浪费。

2. **技术手段完全重合**：本申请与D2均抛弃了在传统的编解码架构内部强行进行全图尺寸绑定的做法，而是创造性地在**网络系统层/封装文件层（DASH/ISO BMFF）**做文章，把视频画面格条块化（Tiles），将各高清图块作为关联的独立媒体流独立传输、独立解码，最后在**客户端渲染侧**利用空间位置坐标信息将高清图块“替换或混合覆盖”到低清底图上。

3. **技术特征公开度最高**：从特征比对表可以看出，D2毫无异议地公开了本申请权利要求1中除个别极其微弱的细节表述外的**几乎全部技术特征（包括核心的独立解码、清单文件空间信号、多解码器处理以及渲染层替换混合）**。

### 为什么D1和D3完全不适合做最接近的对比文件？

* **D1 (`WO2014106651A1`)** 解决的是传统SVC/多视角视频编码中，各层之间由于层间预测依赖而导致的**并行编解码线程对齐及调度难度**问题。它属于底层标准的纯编解码优化方案。

* **D3 (`WO2014168972A1`)** 解决的是SHVC在对局部ROI增强时，如何在编码端对非ROI区域的CTU进行大面积“跳过（Skip）”以节省编解码器内部算力的问题。

* **致命缺陷**：D1和D3都属于强可伸缩编解码框架（层间预测）。在这两份文件中，增强层的解码**完全离不开**基础层输入数据，更不存在客户端可以通过清单文件和URL去自主选择“只下一部分高清图块流，而且还能拿到没有基础层介入的独立解码器里去独立解码”的机制，两者在架构上与本申请存在天然的**技术方向性偏离**。因此，D1和D3绝不能作为最接近的对比文件。

---

## 五、 本申请最薄弱的技术特征分析（无效宣告视角）

如果我们站在请求人（试图无效掉本申请）的角度来看，权利要求1中**防御力最低、最薄弱、极容易被评述为不具备创造性的特征**，在于对**清单文件内部标识符与空间关系的具体定义组合**（即**特征L、M、N**）。

### 原因剖析：

1. **公知常识/惯常设计强规制**：本申请的特征K、L、M、N本质上是在描述：“清单文件包含基础流和增强流的ID，ID可以用URL的一部分表示，清单文件中还有发信号通知它们空间关系的图块位置信息”。

2. **D2的强公开性**：D2在 `[p0106]-[p0108]` 以及附录中，已经明确提出了利用DASH协议的媒体呈现描述（MPD，即清单文件）和初始化段来对各Track（基础轨与各高清图块轨）进行统一标识和独立切片网络请求。更致命的是，D2的附录Annex B和Annex C中给出的修改方案，直接在元数据字段中明确记录了各个图块的 `horizontal_origin`（水平原点）、`vertical_origin`（垂直原点）、`width`（宽度）和 `height`（高度）。

3. **创造性认定的薄弱点**：本申请特征N所述的“发信号通知关于基础流视频帧与增强图块帧视觉内容之间的**空间关系**的图块位置信息”，在D2公开了图块的具体坐标和图层覆灭关系（`Tile_Layer`）之后，已经失去了任何实质性的新颖性与高度。审查员或无效请求人只需证明“利用URL标识网络资源”以及“在DASH的清单文件中携带分流元数据”是本领域在2026年之前的公知常识或DASH标准协议的固有属性，即可轻松将特征L、M、N斩落马下。

因此，如果面临无效请求，权利要求1几乎可以被D2单篇通读结合公知常识全面击穿。本申请**唯一残存的细微辩驳空间**，仅在于“清单文件”这一名词与D2中“封装文件初始化段（Initialization segment）”在协议层面的严格术语映射界定，但这属于字面游戏，在实质性技术贡献审查中非常薄弱。

---

## 六、 针对最薄弱特征的进一步对比文件检索策略

鉴于特征L、M、N（清单文件、URL、空间关系信号）属于本申请在D2基础上的最后防线，若要彻底无效该权利要求，必须实施精准的**补充检索**。以下是为你量身定制的进一步检索策略：

### 1. 关键词精细化与扩展组合

应将检索视野从纯粹的视频编解码标准（HEVC/SHVC）向**流媒体网络传输层标准及文件封装格式**大幅度倾斜。

* **流媒体控制关键词**：`DASH` (Dynamic Adaptive Streaming over HTTP), `MPD` (Media Presentation Description), `Manifest file` (清单文件), `Playlist`, `Segment template`, `URL queries`.

* **空间联合控制关键词**：`Spatial relationship` (空间关系), `SRD` (Spatial Relationship Description，**核心检索词**), `ROI video streaming`, `Tile-based streaming`, `Interactive video panning`, `Omnidirectional video` (全景视频切片传输).

### 2. 精准追踪关键标准提案（重点突破口）

在MPEG和ISO标准制定历史中，针对DASH协议如何传输局部图块以支持ROI或虚拟现实（VR）视口（Viewport）切换，曾有过极其密集的提案发布：

* **MPEG DASH SRD (空间关系描述) 扩展案**：强烈建议定向检索 **ISO/IEC 23009-1:2014/Amd 2:2015**（或者其在2013-2014年间的标准草案阶段工作组提案，即MPEG OME / DASH SRD相关输入文档）。SRD机制正是为了允许DASH清单文件（MPD）向客户端发信号通知各个独立URL代表的Segment在空间网格中的绝对位置、相对比例以及与基础流的关系。如果能检索到2014年前后的 SRD 标准草案提案，特征L、M、N、K将被彻底斩断创造性基础。

* **HEVC OMAF (全方位媒体格式)** 早期的图块流化传输提案（如针对360度视频视口自适应传输的相关专利和标准草案）。

### 3. 分类号（IPC/CPC）交叉精确定位

限制检索范围至流媒体及系统封装层，避开到底层残差计算的噪音：

* **H04N 21/845**：关于流媒体数据块划分或分段的元数据描述（DASH/MPD切片极度密集区）。

* **H04N 21/2343**：网络服务端根据客户端请求动态进行视频流格式/空间调整。

* **H04N 19/70**：视频编码中的高层语法（High-level syntax）元数据封装。

### 总结建议

利用 **D2 (`WO2014111423A1`)** 作为创造性评述的**最接近对比文件**（主引用文献），公开权利要求1中90%以上的构思与架构特征。接着，补充一篇明确公开**“在DASH MPD清单文件中通过SRD或其他元数据字段标记各视频流图块空间坐标与URL映射”**的MPEG标准提案或流媒体专利作为**次引用文献**（如评述特征K、L、M、N）。两相结合，即可构筑起一条牢不可破的创造性无效证据链，实现对目标权利要求1的完全无效。

作为一名经验丰富的专利代理师，我将为您对该目标专利的权利要求1进行深度解析，并结合三份对比文件（D1、D2、D3）的原文进行细致的特征比对与创造性分析，最后为您指出无效请求的最薄弱突破口并制定下一步的检索策略。

首先，为清晰指代，明确三份对比文件的公开号：

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

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

* **对比文件3（D3）**：`EP2814243A1`

*(注：通过原文分析可见，D2与D3为同族专利，技术内容实质相同。)*

---

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

本申请权利要求1保护的是一种“在客户端基于清单文件，通过独立解码的基础流和增强图块流，实现对视频帧中感兴趣区域（ROI）进行增强替换或混合渲染的方法”。其核心在于**空间可缩放性与图块（Tile）技术的结合应用**：利用基础流保证全视频的常规解码，利用可独立解码的增强图块流（只包含子区域）对用户关注的ROI区域进行按需下载、解码，并在渲染时将增强图块“缝合/混合”到基础帧上，从而在不大幅增加带宽的前提下实现局部高清增强。

---

## 二、 技术特征比对表及详细出处分析

以下将权利要求1拆解为A至S共19个技术特征，并与对比文件D1、D2、D3的原文及详细出处进行比对。

---

## 三、 最接近对比文件（D1 vs D2/D3）的确定与创造性分析

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

在本案的创造性分析过程中，**对比文件2（D2）/ 对比文件3（D3）最适合作为最接近的对比文件（D1不适合）**。

* **技术领域与解决的技术问题角度**：

* **本申请**旨在解决如何在有限的带宽或终端能力下，利用分层流（基础+增强）和图块化（Tile）技术，实现对视频局部ROI区域的空间可缩放增强与按需动态解码。

* **D2/D3**明确提出：“为了向具有高能力的终端提供高分辨率图像并向具有相对低能力的终端提供低分辨率图像，实现所谓的部分解码是有利的……提供使得能够使用瓦片分割进行部分解码的结构”（见D2 [0008]-[0009] / D3 [0005]）。其从根本上提出了**基于瓦片（Tile）分割的区域可缩放视频编码（Regional Scalability）**，涉及多层流（基本层+增强层）和多解码器架构。

* **反观D1**，其本质是在**单层码流**中通过SEI或VUI写入预览瓦片的编号或坐标，其实质是为了在手机等终端做“缩略图/预览播放”时快速跳过非预览瓦片（见D1 [0007]-[0009]），并不涉及多层码流的缝合增强与流之间的空间映射。

* **技术特征覆盖角度**：

D2/D3几乎公开了本申请除“清单文件（Manifest file）及URL标识”以外的全部架构特征（包括多流关联、双解码器并行生成、瓦片空间拼接渲染等）。因此，D2/D3是本申请天然的最佳无效起点。

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

经上述比对，**特征K、L、M、N中关于“清单文件（Manifest file）”的部分**未被D2/D3公开。

* **D2/D3的方案**是将基础/增强瓦片的关联关系、空间坐标参数完全写入传统媒体传输流的**带内信令**中（如H.265/HEVC的SPS/PPS/SEI/切片头部）。

* **本申请的特征K-N**则引入了**带外信令文件——清单文件**（例如MPEG-DASH标准中的MPD文件或HLS中的m3u8文件），通过在清单文件中写入基础流URL、增强图块流URL，以及图块的空间几何位置关系，使客户端能够在不解析视音频媒体流头部的情况下，直接通过清单文件进行网络层面的按需流请求。

---

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

如果要对本权利要求1提出无效宣告请求，**最薄弱（即专利权人最容易据此答辩成功、最难被无效掉）的技术特征是：特征K、L、M、N组合构成的“在清单文件中包含基础/增强图块流的URL标识及各流下图块间的空间几何关系，并由客户端据此发起HTTP请求”这一特征组合**。

### 原因分析：

1. **技术架构的错位**：D2/D3等传统视频编码领域的对比文件，其思维定势是“如何在视音频编解码器（Codec）层面解决并行与分层”。因此，其所有空间信令（如`coord_roi_tile_hor_minus1`）都是编解码流语法元素的一部分。而本申请的清单文件（Manifest）属于**网络流媒体传输协议层（如DASH/HLS）**。

2. **新颖性与创造性的辩驳空间**：专利权人可以极力抗辩称：本申请通过将空间位置信息提升至“网络流传输协议层的清单文件”中，使得客户端设备在**网络下载前**即可通过URL直接精准过滤并请求特定图块流，而不需要像D2/D3那样必须先接收多路复用流或解析媒体流头部信令，极大地节省了网络带宽并降低了客户端解析开销。这属于跨层组合带来的显著技术效果。

---

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

针对上述最薄弱的“基于清单文件携带图块空间关系的HTTP流媒体传输”特征，目前的D1-D3尚无法形成完美的创造性组合。为了成功无效该权利要求，必须补充检索**流媒体协议及全景视频/全向视频传输（VR/360度视频）**领域的对比文件作为**D4/D5**。具体检索策略如下：

### 1. 拓展技术领域与关键词

不要局限于传统的视频编码标准（HEVC/AV1），应全面进军**MPEG-DASH、MPEG OMAF（全向媒体格式标准）、3GPP流媒体扩展**等传输层技术领域。

* **核心英文关键词**：`"Manifest file"`, `"MPD"`, `"MPEG-DASH"`, `"SRD" (Spatial Relationship Description)`, `"tile stream"`, `"base stream"`, `"enhancement"`, `"URL"`, `"ROI"`, `"dynamic streaming"`。

* **核心中文关键词**：`清单文件`、`媒体呈现描述`、`MPD`、`图块流`、`基础流`、`空间关系描述`、`感兴趣区域`、`URL`、`统一资源定位符`。

### 2. 瞄准关键的行业公知常识/标准提案（最核心策略）

在2014-2016年期间，MPEG-DASH标准中引入了一个极其关键的技术特性——**SRD（Spatial Relationship Description，空间关系描述）**。

* **寻找目标D4**：检索公开日在本案申请日之前的关于**“MPEG-DASH SRD”**的技术文章、专利或ISO/IEC标准文档（如 ISO/IEC 23009-1 AM4）。

* **预期技术契合度**：MPEG-DASH SRD允许在MPD清单文件中使用XML标签描述视频不同图块（Tile）在空间上的坐标、重叠关系及对应的URL链接，这与本申请特征K、L、M、N的结合度几乎是100%。

### 3. 无效组合构建路线图

通过补充检索获得D4（公开了在DASH MPD清单文件中通过URL和空间关系描述请求不同部分画面图块）后，采用如下证据组合方式：

* **主方案**：**D2（或D3） + D4**。用D2/D3证明“将视频划分为基础层和增强图块层进行局部增强和混合渲染”是行业已知架构；用D4证明“在网络流媒体传输中，利用清单文件（Manifest）携带图块流的URL及空间关系信令以供客户端发起HTTP按需请求”属于流媒体领域的通用传输技术。

* **结论**：将D4的技术手段应用到D2的多层瓦片架构中，以解决网络按需流传输的问题，对本领域技术人员而言是显而易见的，权利要求1不具备创造性。

作为一名经验丰富的专利代理师，我将为您对目标权利要求1进行深度解析，并紧密结合三份对比文件（D1、D2、D3）的英文原文及详细出处进行特征比对和创造性评价，最后给出无效宣告请求的最薄弱技术特征分析及下一步的检索策略。

---

### 一、 目标专利权利要求1的特征分解（Element-by-Element）

为了进行精确的比对，首先将权利要求1分解为20个独立的技术特征（A至S，其中包含特征H2，共20项拆解）：

* **特征A**：所述方法包括客户端设备接收定义至少一个基础流的基础视频帧的媒体数据；

* **特征B**：所述基础流与一个或多个增强图块流相关联；

* **特征C**：其中增强图块流包括定义图块化视频帧的媒体数据；

* **特征D**：图块化视频帧包括与用于增强基础视频帧的图像区域的子区域中的视觉内容的媒体数据相关联的图块；

* **特征E**：其中增强图块流的媒体数据可独立于所述基础流的媒体数据进行解码；

* **特征F**：确定与所述基础流的视频帧中的至少一个感兴趣区域的位置相关联的ROI位置信息；

* **特征G**：基于ROI位置信息和图块位置信息来确定一个或多个增强图块流；

* **特征H**：其中所述一个或多个所确定的增强图块流定义与至少一个ROI至少部分地重叠的一个或多个图块；

* **特征I**：客户端设备请求所述一个或多个所确定的增强图块流的媒体数据；

* **特征J**：所请求的媒体数据的图块化视频帧的一个或多个图块与基础视频帧 of 图像区域中的至少一个预定的感兴趣区域相关联；

* **特征K**：所述媒体数据是由客户端设备基于清单文件而请求的；

* **特征L**：所述清单文件包括至少一个基础流标识符和与该至少一个基础流标识符相关联的一个或多个增强图块流标识符；

* **特征M**：流标识符包括URL的至少一部分或包括用于确定这样的URL的信息；

* **特征N**：清单文件还包括用于向所述客户端设备发信号通知关于所述基础流的视频帧中的视觉内容与所述一个或多个增强图块流的图块化视频帧的图块中的视觉内容之间的空间关系的图块位置信息；

* **特征O**：连接到所述客户端设备的第一解码器基于至少一个基础流的媒体数据生成基础视频帧；

* **特征P**：连接到客户端设备的第二解码器基于一个或多个增强图块流的媒体数据生成图块化视频帧；

* **特征Q**：所生成的图块化视频帧包括在至少一个感兴趣区域中形成增强视觉内容的一个或多个图块；

* **特征R**：渲染设备通过基于图块化视频帧的增强视觉内容的至少一部分修改所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分来形成包括增强感兴趣区域的视频帧；

* **特征S**：所述修改包括用图块化视频帧的增强视觉内容的至少一部分替换或混合所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分。

---

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

在后续分析中，将使用以下简称指代各对比文件：

* **D1**：`US20150023407A1` (IMAGE DECODING DEVICE, IMAGE DECODING METHOD...)

* **D2**：`US20150032901A1` (SYSTEM AND METHOD FOR SPATIAL ADAPTATION IN ADAPTIVE STREAMING)

* **D3**：`WO2015014773A1` (PROVIDING TILE VIDEO STREAMS TO A CLIENT)

---

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

以下表格详细列出各对比文件是否公开了目标权利要求的技术特征，并给出了**毫无异议公开（实意公开）**或**实质公开（下位/等同概念公开）**的英文原文及段落出处。

---

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

在创造性分析中，**D3 (`WO2015014773A1`)** 和 **D2 (`US20150032901A1`)** 均适合作为最接近的对比文件（主审对比文件）。本案存在多个最接近的对比文件，理由如下：

#### 1. 为什么D3（`WO2015014773A1`）最适合作为第一主审对比文件？

* **技术领域与解决的技术问题完全一致**：D3聚焦于客户端从网络接收一个常规的ROI视频流（如导演剪辑版/基础流），当用户产生交互请求时，无缝切换并请求高分辨率的Tile（图块）流进行空间拼接渲染。这完全对应了目标专利“基础流+增强图块流+空间位置信号”的架构，旨在解决**如何在有限带宽/解码能力下，实现动态ROI的高清无缝增强与渲染切换**。

* **技术特征覆盖度极高**：如上表所示，D3毫无异议地公开了从特征A~N，以及特征Q的大部分网络流媒体传输层面的特征。

#### 2. 为什么D2（`US20150032901A1`）同样适合作为最接近的对比文件？

* **技术手段完全一致（基于DASH协议的空间动态图块选择）**：D2公开了基于DASH（清单文件MPD），客户端通过在新属性`@pos`中发信号通知Tile的空间位置，并根据用户ROI请求对应的Tile流，实现“Free-zooming”且保持“constant video quality”的效果。D2在**清单文件（Manifest）的信令交互（特征K、L、M、N）**的公开上比D3更具体、更贴切。

#### 3. 核心未公开特征的交叉覆盖分析

* **关于特征O、P（双解码器架构）**：D2和D3作为网络流媒体协议优先的申请，对客户端“第一解码器”和“第二解码器”的物理硬件切分未做强限定。然而，**D1 (`US20150023407A1`)** 恰恰是一篇聚焦于**HEVC图块并行解码架构**的专利。D1在图[19]-[21]及说明书[0149]~[0192]中极为详尽地公开了“第一解码部6a”解码基准层，“第二解码部6b”解码增强层或非ROI图块的并行双解码器结构。同时，D3在[p0008]中也明确指出“每一个Tile流都要启动一个单独的解码器实例（a separate instance of a decoder should be started）”。

* **关于特征R、S（替换或混合的渲染修改）**：目标专利提到了通过“替换或混合”将增强图块内容融合到基础流中。D3公开了将收到的Tile流进行“同步并拼接（stitch）”，并利用ROI坐标从拼接后的子区域中裁剪（crop）出最终的ROI，其本质也是通过空间像素的“替换/覆盖”来实现无缝图像生成。D1也公开了组合部（Combining section）将图块拼接回原图。

---

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

若要向专利局提起针对目标专利权利要求1的无效宣告请求，以下特征是目标专利对抗对比文件时**最薄弱（即最容易被宣告无效）**的防线：

1. **特征K、L、M、N（基于清单文件和URL包含空间位置信令）**：

* *薄弱原因*：目标专利可能认为在清单文件中加入基础流与增强Tile流的关联及空间URL是其发明点。然而，这一套机制已经被 **D2 (`@pos` 属性写入MPD)** 和 **D3 (SMF 包含 ROI stream URL 和 Tile位置)** 彻底“定点清除”。这属于流媒体DASH协议在图块化视频传输中的常规标准应用，不具备任何创造性高度。

2. **特征O、P（第一解码器和第二解码器分别解码基础流和图块流）**：

* *薄弱原因*：目标专利试图通过引入硬件/逻辑层面的“双解码器”来制造技术壁垒。但结合 **D1的区域/空间可伸缩性双解码部（6a/6b）**，或者 **D3提到的多解码器实例**，对于本领域技术人员来说，面对独立编码的基础流和增强Tile流，为了提升解码效率并防范宏块参考依赖，自然而然的技术选择就是启用两个独立的解码器管线进行并行解码。这属于“公知常识”或“常规设计选择的直接组合”。

3. **特征S（用增强图块替换或混合基础流ROI的视觉内容）**：

* *薄弱原因*：这只是图像后处理（渲染层）的常规描述。D3中将高分辨率图块序列对齐并“Stitch（拼接）”与“Crop（裁剪）”后覆盖在原视窗的技术手段，在逻辑上与“替换”完全等同。

---

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

为了确保彻底无效掉权利要求1（甚至包括后续可能出现的从属权利要求修改），建议采取以下针对性的检索策略：

1. **针对“替换或混合（Replace or Blend）”渲染细节的精确检索**：

* *方向*：检索MPEG-DASH空间自适应扩展标准或高级视频渲染（如VR/全景视频拼接）领域。

* *关键词组合*：`(base layer OR low resolution) 3D2D (tile OR sub-stream) 3D2D (replace OR blend OR overlay OR alpha-blend) 3D2D (ROI OR Region of Interest)`。

2. **针对“双解码器时间同步与抖动消除”的检索**：

* *方向*：目标专利如果想在从属权利要求中死守“第一解码器与第二解码器如何保证输出帧率同步、如何处理解码延迟差”，需要提前检索对抗文件。

* *关键词组合*：`(dual decoders OR multiple decoder instances) 3D2D (synchroniz* OR PTS OR timestamp) 3D2D (delay OR latency OR jitter)`。

3. **标准追踪检索（3GPP / MPEG-DASH / HEVC Tiling）**：

* *方向*：重点检索2013-2015年期间（目标专利优先权日之前），MPEG工作组关于“Tiled Adaptive Streaming”及“Interactive ROI Streaming with DASH”的提案文件（即D2和D3背景技术中提到的 `m28883`, `m29232`, `m28176` 等MPEG内部提案报告）。这些会议提案通常包含比公开专利更细致的语法元素和架构设计，极易构成销毁创造性的强力非专利文献（NPL）。

作为一个经验丰富的专利代理师，针对本案涉案权利要求1与对比文件D1、D2、D3的创造性/无效可行性深度分析报告如下：

---

## 一、 权利要求1的技术特征拆解与技术方案解读

涉案权利要求1保护一种**用于增强视频流的视频帧中的至少一个感兴趣区域（ROI）的方法**。其核心架构基于互联网自适应流媒体（如DASH）环境，利用“基础流”提供全画面低分辨率/基础视觉内容，利用“增强图块流（Tile Stream）”提供ROI区域的高分辨率/增强视觉内容。

其技术分工与协作逻辑如下：

1. **传输与解析（特征A~N）：** 客户端通过清单文件（Manifest，包含URL与空间位置信息）获知基础流与各增强图块流的关联及空间关系。客户端根据用户或系统确定的ROI位置信息，按需仅请求与该ROI至少部分重叠的增强图块流，实现带宽节约。

2. **解码架构（特征O~Q）：** 客户端采用双解码器独立解码架构，第一解码器解码基础流生成基础视频帧，第二解码器独立解码增强图块流生成图块化视频帧（含增强视觉内容）。

3. **渲染与合成（特征R~S）：** 渲染设备将解码后的增强图块视觉内容，通过“替换”或“混合（如Alpha融合）”的方式叠加到基础视频帧的对应ROI区域，从而在整体画面中实现局部ROI的视觉增强。

---

## 二、 对比文件特征比对表格（特征级比对）

为了客观评价权利要求1的无异议公开（全包含）或实质公开特征，现将技术特征 A~S 与对比文件进行精细化映射：

---

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

### 1. 最接近对比文件（Primary Reference）的选择

在创造性分析或无效宣告程序中，**D2 (`WO2015059194A1`)** 最适合作为审查本案权利要求1的最接近对比文件。

* **技术领域相同：** 二者均属于视频编解码、流媒体文件封装与传输技术领域，特别是基于HTTP的自适应ROI（感兴趣区域）如图块（Tile）流式传输范畴。

* **解决的技术问题相同：** 二者均旨在解决超高分辨率视频传输中，客户端带宽或解码能力有限，无法全分辨率接收，而需要“按需、空间空间定位、独立请求和动态提取局部ROI高分辨率数据”的技术问题。

* **技术效果相同：** 均实现了通过清单文件指引，仅传输与用户ROI重叠的空间图块，大幅降低了流媒体的网络吞吐量和资源开销。

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

从上表可见，D2 几乎毫无异议地公开了权利要求1中除解码/渲染细节（特征O、P、R、S部分细节）外的所有前序传输、标识、ROI空间映射特征。D2 未明确公开的特征主要在于后端：**“连接到客户端设备的第一解码器/第二解码器分别独立解码生成基础帧和图块帧（特征O、P）”** 以及 **“通过替换或混合的具体渲染修改方式形成最终增强ROI帧（特征R、S）”**。

这些未被 D2 公开的特征，已被 **D3 (`WO2015104451A1`)** 完全公开：

* **关于特征O、P（双解码器架构）：** D3 明确公开了多循环（Multi-loop）解码架构（说明书\[0160\]、\[0434\]），各个层（基础层与ROI增强层）具有独立的图像缓冲区和独立的解码输出路径，能够并行输出基层图像和高层的增强图像。

* **关于特征R、S（替换或混合的渲染机制）：** D3 在说明书\[0006\]及\[0558\]-\[0563\]中完美对应了这一合成操作。其指出：输出图像叠加合成过程（output picture overlaying process）中，通过参考层位置偏移量将两层对齐在共用坐标系上，随后“ROI增强层的样本值将覆盖或替换基层对应位置的样本值（replace that ROI of the base layer picture）”，或者“根据alpha通道进行alpha混合（alpha blending）”。

### 3. 本领域技术人员的结合启示

由于 D2 和 D3 均基于相同的 HEVC（H.265）及其可伸缩扩展（SHVC）标准框架，且 D2 在背景技术中已经指出“传统Tile传输由于多轨道独立解码导致基层重复解码、开销大，需要一种有效的层与Tile结合的组织形式（说明书\[0015\]-\[0016\]）”。因此，本领域技术人员在面对 D2 提出的可伸缩分区（Tiled Scalable）流媒体架构时，为了在客户端重构并显示最终的视频，具有极其强烈的技术启示去引入 D3 所公开的成熟的“多循环独立解码层架构”以及“依据空间偏移量进行多层图像空间覆盖/混合替换的渲染技术”。

二者的结合属于本领域的常规技术选择，未产生预料不到的技术效果。因此，**权利要求1相对于 D2 + D3 的结合不具备创造性。**

---

## 四、 提起无效请求时最薄弱的技术特征

如果要向专利局或法院提起无效宣告请求，该权利要求**最薄弱（即最容易被证据攻破）**的技术特征是：**特征F至特征N（关于基于清单文件进行ROI与图块空间关联及按需请求的特征）**。

> **薄弱原因分析：**

> 涉案专利将“清单文件（包含URL和发信号通知空间关系的图块位置信息）”和“基于ROI与图块重叠关系动态请求”作为其流媒体自适应的核心发明点。然而，这一套机制在 **D2 (`WO2015059194A1`)** 中被**大篇幅、高精度地全盘公开**。D2 甚至直接给出了包含水平偏移量、垂直偏移量、区域宽高的专用描述符 `TileRegionGroupEntry ('trif')`（说明书\[0305\]），且其步骤1108、1112完美对应了根据ROI重叠计算图块并用URL发送HTTP GET请求的全过程。可以说，涉案专利在网络传输和空间映射这一最大发明点上，对 D2 构成了**实质性重合**，防御力极低。

>

> 相反，涉案专利最强的特征（虽然也是相对的）可能是特征O、P中限定的**“连接到客户端设备的第一解码器……第二解码器……”**这一微观硬件/软件解码器物理区隔。涉案专利可能会辩称其属于特定的双硬件解码器协作流。但由于 D3 已经公开了多循环独立层解码路径，且在多媒体终端中部署多实例化解码组件属于公知常识，此特征亦极易被 D2+D3 或结合公知常识直接无效。

---

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

为了彻底巩固无效证据链，或在涉案专利缩减权利要求范围（例如将其限缩在特定清单语法或解码流水线同步控制）时进行精准打击，建议采取以下针对性的延伸检索策略：

1. **聚焦 3GPP / MPEG 标准提案（TS / TDDoc）检索：**

涉案专利和 D2、D3 的时间节点均集中在 2015 年左右，这正是 HEVC（H.265）的图块化扩展（Tile）以及可伸缩视频编码（SHVC）、多视角编码（MV-HEVC）在 MPEG/3GPP 组织中制定标准、讨论文件封装格式（ISO BMFF Amendment）的关键期。

* **关键检索源：** 检索 2013-2015 年间的 **JCT-VC** (Joint Collaborative Team on Video Coding) 和 **MPEG 委员会** 提案（如 JCTVC-Oxxxx, JCTVC-Pxxxx ）。

* **针对特征：** 重点寻找涉及“DASH streaming for ROI using SHVC tiles”或“Manifest signaling for spatial dependence”的提案（例如图块流中通用参数集 track 与局部 tile track 的标识关联 `dond`、`sbas` 机制）。

2. **细化“替换或混合（Replace or Blend）”渲染网关检索：**

若涉案专利通过强调渲染层面的“特定混合比例”或“动态切换替换/混合”来争取创造性，应进一步检索数字图像合成或多视点视频合成（View Synthesis Rendering）的早期技术。

* **关键词扩展：** `Alpha blending`, `Compositing`, `Region-of-interest overlay`, `PIP (Picture-in-Picture) rendering`, `Dynamic replacement`.

3. **多编解码器标准交叉检索（如 H.264/SVC 的既往实现）：**

虽然本案背景基于图块（Tile），但局部区域增强（ROI Enhancement）在 H.264 的可伸缩扩展（SVC）中已有类似演进（通过宏块级 ROI 映射）。建议检索 2010-2013 年关于 **H.264/SVC 空间可伸缩局部流传输** 的专利，作为外围“技术启示（Suggestion）”或公知常识的有力补充证据。

作为一名经验丰富的专利代理师，在针对涉案专利权利要求1进行无效可行性分析时，我们需要以客观、严谨的态度，紧密结合涉案专利说明书与对比文件（下称D1、D2、D3）的原文及其实质公开内容进行特征比对。

在本案中，涉案专利（目标权利要求1）的核心技术方案为：**一种基于清单文件指导客户端进行基础流与解耦的“增强图块流”双解码器独立解码，并在渲染侧进行感兴趣区域（ROI）空间位置替换/混合以实现视频流ROI局部增强的方法。**

以下为针对该权利要求的详细invalidity分析：

---

### 一、 权利要求技术特征分解（Feature Breakdown）

为了进行精确的创造性评述，首先将权利要求1拆解为19个独立的技术特征（特征A至特征S）：

* **特征A**：客户端设备接收定义至少一个基础流的基础视频帧的媒体数据；

* **特征B**：基础流与一个或多个增强图块流相关联；

* **特征C**：增强图块流包括定义图块化视频帧的媒体数据；

* **特征D**：图块化视频帧包括与用于增强基础视频帧的图像区域的子区域中的视觉内容的媒体数据相关联的图块；

* **特征E**：增强图块流的媒体数据可独立于基础流的媒体数据进行解码；

* **特征F**：确定与基础流的视频帧中的至少一个感兴趣区域的位置相关联的ROI位置信息；

* **特征G**：基于ROI位置信息和图块位置信息来确定一个或多个增强图块流；

* **特征H**：一个或多个所确定的增强图块流定义与至少一个ROI至少部分地重叠的一个或多个图块；

* **特征I**：客户端设备请求一个或多个所确定的增强图块流的媒体数据；

* **特征J**：所请求的媒体数据的图块化视频帧的一个或多个图块与基础视频帧的图像区域中的至少一个预定的感兴趣区域相关联；

* **特征K**：媒体数据是由客户端设备基于清单文件而请求的；

* **特征L**：清单文件包括至少一个基础流标识符和与该至少一个基础流标识符相关联的一个或多个增强图块流标识符；

* **特征M**：流标识符包括URL的至少一部分或包括用于确定这样的URL的信息；

* **特征N**：清单文件还包括用于向客户端设备发信号通知关于基础流的视频帧中的视觉内容与一个或多个增强图块流的图块化视频帧的图块中的视觉内容之间的空间关系的图块位置信息；

* **特征O**：连接到客户端设备的第一解码器基于至少一个基础流的媒体数据生成基础视频帧；

* **特征P**：连接到客户端设备的第二解码器基于一个或多个增强图块流的媒体数据生成图块化视频帧；

* **特征Q**：所生成的图块化视频帧包括在至少一个感兴趣区域中形成增强视觉内容的一个或多个图块；

* **特征R**：渲染设备通过基于图块化视频帧的增强视觉内容的至少一部分修改基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分来形成包括增强感兴趣区域的视频帧；

* **特征S**：修改包括用图块化视频帧的增强视觉内容的至少一部分替换或混合基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分。

---

### 二、 对比文件公开情况分析与出处指明

根据提供的对比文件内容，分析各篇对比文件的实质公开特征：

#### 1. D1: US20150208103A1 (System and Method for Enabling User Control of Live Video Stream(s))

D1公开了一种用户可控的近实时/实时视频流图块化（Tile）提取和虚拟缩放系统。

* **实质公开内容**：用户在客户端界面（[0006]）通过手势选择感兴趣区域（RoI）（[0021]、[0061]），系统通过索引文件（Index File）中记录的各个图块（Tiles）和切片（Slices）的字节偏移量（Byte Offsets）（[0019]-[0020]），在压缩域中实时裁剪出与RoI相交的那些高分辨率图块，并流式传输给用户，以此节约带宽。同时公开了在新的高分辨率图块到达前，先缩放显示同位置的低分辨率图块或 thumbnail（缩略流）（[0028]、[0091]）。

* **局限性**：D1是基于单一视频流的不同分辨率级别进行无损提取或平滑切换，并非将“基础流”与“独立的增强图块流”进行双解码器并行解码并作渲染重组。

#### 2. D2: US20150237166A1 (METHOD AND CORRESPONDING DEVICE FOR STREAMING VIDEO DATA)

D2公开了一种基于DASH（HTTP动态自适应流）标准的图块化视频传输方法。

* **实质公开内容**：D2公开了将视频划分为基础层（Base Layer）和至少一个空间增强层（Spatial Enhancement Layer）（[0023]），其中增强层被划分为 $n$ 个独立的视频子轨道（Video Sub-tracks/Tiles）（[0013]）。清单文件（DASH MPD）（[0003]、[0020]）直接包含了各子轨道的组织结构及各自的URL（[0014]、[0020]），允许客户端根据选定的感兴趣区域（ROI）（[0014]、[0092]）选择特定的URL发出请求（[0092]）。在说明书[0023]和[0024]中，明确提到了如果客户端选择ROI，它会同时选择对应增强层图块的URL以及**基础层（Base Layer）的URL**，服务器同时发送两者，并在客户端组合。

* **局限性**：D2侧重于DASH清单文件中针对Tiled video的语法标记（利用Role元素及tiling Scheme），虽然提及了Base Layer和Enhancement Layer的共存，但未显式详述客户端需采用“第一解码器”与“第二解码器”将解耦且独立的两个流分别解码后再在“渲染侧”做图块混合/替换的具体架构。

#### 3. D3: KR1020150103224A (EFFICIENT SCALABLE CODING CONCEPT)

D3公开了一种高效可扩展视频编码（SHVC/SVC）的并行化解码概念。

* **实质公开内容**：D3聚焦于可扩展视频编码中基本层（Base Layer）与增强层（Enhancement Layer）之间的并行解码技术（[0004]、[0007]）。为了解决层间预测（Inter-layer Prediction）导致增强层必须等待基本层对应区域解码完成的延迟问题，D3通过引入长期语法结构（Long-term syntax element structure）来保证两层之间空间段（图块Tile/WPP子流）的边界重叠与对齐（[0004]、[0030]）。D3明确公开了在进行可扩展视频解码时，**针对依赖层（增强层）的解码线程与针对基准层（基本层）的解码线程并行运行**，并利用层间偏移（Inter-layer offset）实现流水线（Pipeline）作业（[0030]、[0070]、[0137]）。

* **局限性**：D3属于编解码器（Codec）内部的并行化技术改造，其层间预测包含了复杂的层间上采样滤波器限制（[0006]、[0053]），其最终输出是由增强层解码器直接重构出的完整高分辨率帧，而非在解码后由渲染设备将两个独立解码的像素流在ROI区域进行图块替换或混合。

---

### 三、 技术特征比对表格（Feature Comparison Matrix）

根据上述原文出处分析，建立涉案专利权利要求1与对比文件的特征比对表：

---

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

#### 1. 最接近对比文件的选择：**D2（US20150237166A1）**

* **评述理由**：从整体解决的技术问题和技术效果来看，**D2最适合作为创造性分析中的最接近对比文件（主案/D1）**。

* **技术问题一致性**：涉案专利与D2解决的都是“如何在网络传输中，针对用户个性化的感兴趣区域（ROI）高自适应地、节省带宽地传输高清晰度视频流”的问题。

* **技术手段最为接近**：D2采用了在清单文件（Manifest/MPD）中同时提供基础流标识符（Base Layer URL）和与之空间关联的独立增强图块流标识符（Enhancement Sub-track URLs）的架构。这与涉案专利依赖清单文件引导客户端请求“基础流+增强图块流”的构思高度契合（覆盖了特征A-D、F-N）。

#### 2. 辅助对比文件的选择：**D3（KR1020150103224A）**

* **评述理由**：D3解决了多层视频流在面对空间段（Tile）划分时，客户端如何利用**多个解码线程/解码器并行处理基本层与增强层**以降低整体延迟的问题。因此，D3可以用于提供**特征O、特征P**（即第一解码器解码基础流，第二解码器解码增强图块流）的技术启示。

#### 3. 创造性评述逻辑构建（三步法评视图路）

* **区别特征**：将涉案专利权利要求1与D2相比，区别特征主要在于**特征O、P、Q、R、S**。即：涉案专利限定了客户端配置“第一解码器”和“第二解码器”分别独立生成基础视频帧和图块化视频帧，并由“渲染设备”在“渲染侧”通过“替换或混合”基础流ROI区域的视觉内容，形成局部增强的视频帧。

* **结合D3引入并行解码**：本领域技术人员在D2的基础上，为了提高解码效率、降低多层（Base+Enhancement）视频的总体解码延迟，有动机引入D3所公开的并行解码技术，即分配不同的解码线程/双解码器（第一解码器和第二解码器）分别对D2中的Base Layer和具有独立子轨道的Enhancement Layer进行并行解码（从而解决特征O、P、Q）。

* **无法被公开的实质性区别（特征R、S）**：

然而，即便将D2和D3结合，**依然无法导出特征R和特征S**。

* **D2+D3的传统逻辑**：在编解码领域（如SHVC/DASH），传统的做法是将基本层经由层间上采样后作为增强层解码的**预测参考帧**，在编解码器内部完成残差相加，最终由增强层解码器输出一幅整体的、完整的高分辨率大帧进行渲染。

* **涉案专利的创新构思**：涉案专利跳出了Codec底层重构的框架，转而在**渲染侧（Display/Render level）**做动作。第一解码器输出一幅完整的低清/基础帧，第二解码器单独输出一块高质量的ROI图块。渲染设备直接在画布上把基础帧的ROI区域抠掉，“替换”或“混合”成该高质量图块。这种“**独立解码+渲染层局部像素混合/替换**”的方案，在提供局部增强效果的同时，彻底解耦了基础解码器和增强解码器的底层依赖，技术效果上极大减轻了客户端编解码层面的同步开销。

---

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

通过上述深度比对可见，涉案专利权利要求1中**最薄弱（即最不容易被攻破、对创造性贡献最大）的技术特征**是：

> **特征R + 特征S**：即“渲染设备通过基于图块化视频帧的增强视觉内容的至少一部分**修改**所述基础流的视频帧中的至少一个感兴趣区域的视觉内容……所述修改包括用图块化视频帧的增强视觉内容的至少一部分**替换或混合**所述基础流的视频帧中的至少一个感兴趣区域的视觉内容的至少一部分。”

* **弱点原因**：目前检索到的主流流媒体标准（D2）与多层Codec并行化技术（D3），均将多层流的复用留在“解码器内部重构”阶段。涉案专利将图块流定位为“可独立于基础流进行解码（特征E）”，并在解码后交给“渲染设备”通过“替换/混合”来“修改”基础流对应区域。这一工程实现手段属于**编解码与显示渲染的跨界结合**，在现有三篇对比文件中完全没有实质性启示。如果无效请求人仅凭借D1-D3，该特征将成为维持专利权坚固的“护城河”。

---

### 六、 进一步的对比文件检索策略（Search Strategy）

为了成功无效掉包含特征R和S的权利要求1，必须打破“渲染侧局部替换/混合”这一技术壁垒。建议调整检索策略，从以下三个维度进行针对性补充检索：

#### 1. 跨领域检索：计算机图形学与视频后处理（Video Post-processing / OSD）

* **检索方向**：寻找在客户端进行视频后处理时，将“低清视频背景”与“局部高清贴图/画中画（PiP）”在**渲染画布（Canvas/Framebuffer）**层面进行像素级替换或 Alpha 混合（Alpha Blending）的专利或文献。

* **核心逻辑**：证明“将两个独立解码的图像流在显示渲染阶段进行指定区域的覆盖或融合”属于计算机视频播放器的公知常识或成熟的后处理技术。

#### 2. 特定标准跟踪：MPEG-scalable / MPEG-I / OMAF (Omnidirectional Media Format)

* **检索方向**：重点检索 2015-2018 年期间，国际标准组织针对全景视频（360-degree video）、VR视频流传输制定的 OMAF 标准提案或早期草案。

* **核心逻辑**：全景视频流传输中经常使用“低分辨率全景底图（Base）”+“用户当前视锥（FoV）高分辨率增强图块（Viewport Tile）”的方案。需检索是否存在提案直接公开了“客户端启动两个独立解码器分别解码全景底图和视锥图块，并在渲染时将高清视锥图块直接覆写（Overwrite/Replace）到低清底图对应坐标上”的公开技术。

#### 3. 检索要素（Keywords & IPC）增强组合

* **IPC分类号精选**：`H04N21/44`（终端流媒体后处理）、`H04N21/431`（视觉界面渲染）、`G06T15/00`（图像/视频渲染）。

* **英文扩展词**：`("dual decoder" OR "two decoders") AND ("rendering side" OR "renderer" OR "canvas" OR "framebuffer") AND ("replace" OR "blend" OR "overlay" OR "substitute") AND ("ROI" OR "tile")`

* **中文扩展词**：`（"双解码器" 或 "第二解码器"） 并与 （"渲染" 或 "画布" 或 "显示侧"） 并与 （"替换" 或 "混合" 或 "覆盖" 或 "抠象"） 并与 （"感兴趣区域" 或 "图块"）`

### 总结意见

目前由D2（作为最接近的现有技术）结合D3（提供双解码并行启示），已经能够成功覆盖涉案专利权利要求1约 80% 的技术内容。本案成败的关键完全取决于能否检索到一篇公开了“**在独立解码后，由渲染侧对基础视频帧的ROI区域实施像素级替换/混合**”的系统级后处理对比文件。依照上述补充检索策略进行拓展，将有很大几率彻底完成对该权利要求的创造性绞杀。

该权利要求 1 涉及一种用于增强视频流的视频帧中感兴趣区域（ROI）的方法。为了分析该方案的创造性，我们首先对权利要求 1 的技术特征进行拆解，并与提供的对比文件（D1-D3）进行比对。

### 1. 权利要求技术特征分析与比对

### 2. 创造性分析（最接近的对比文件）

* **最接近的对比文件：D1 (US2015264404A1)**。

* **理由**：D1 详细描述了可伸缩视频编码（SVC/SHVC）架构，特别是关于 ROI 可伸缩性（ROI scalability）以及如何使用基础层和增强层进行视频编码和解码。它涵盖了基础流和增强层的基本概念、分层结构以及层间预测，是权利要求 1 的最核心参考。

* **其他特征的公开情况**：

* D1 公开了分层结构（基础层+增强层）、ROI 的定义及增强、以及通过覆盖（overlay）在显示时形成最终画面的方法。

* **权利要求 1 未被 D1 公开的潜在薄弱点**：

1. **基于清单文件（Manifest file）的具体请求机制**：虽然 D1 提到了传输机制，但权利要求对于清单文件的特定结构（包含基础流 ID、增强流 ID、URL 生成信息、图块位置信息等）并未在 D1 中体现。

2. **特定的替换或混合修改策略**：权利要求明确了“用图块化视频帧的增强视觉内容替换或混合基础流视频帧”，尽管 D1 提到了层覆盖，但权利要求将这种操作定义为一种“修改”方法，并与清单文件中的空间关系信息联动。

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

**最薄弱的技术特征是：清单文件（Manifest file）及其包含的图块位置信息。**

* **理由**：在视频流传输标准中，基于清单（如 DASH 中的 MPD 文件）进行流请求和加载是行业惯例。尽管 D1 主要是编码/解码层面的公开，但将视频流分块（Tiles）并利用清单文件进行选择性加载的技术在当前的流媒体传输标准（如 MPEG-DASH，ISO/IEC 23009-1）中已属于公知常识。如果无效请求人能找到关于 DASH 或类似流媒体传输协议的现有技术，结合 D1 的编码架构，权利要求 1 的创造性将面临极大挑战。

### 4. 进一步检索策略

若要进一步挖掘现有技术以确信该方案不具备创造性，建议采用以下检索策略：

1. **关键词组合**：

* `MPEG-DASH` OR `HLS` OR `Manifest`

* `Tile` AND `ROI` AND `Video streaming`

* `HTTP Adaptive Streaming` AND `Tiles` AND `spatial relationship`

2. **检索库建议**：

* **MPEG 标准文稿 (JCT-VC / JCT-3V)**：查看 2013-2015 年间关于 Tile 和 ROI 流传输的提案，这些提案往往包含上述清单文件（Manifest）的详细定义。

* **Google Patents / Espacenet**：针对“Video streaming tile request manifest”进行检索，寻找在 SHVC 基础上叠加 DASH 传输逻辑的专利申请。

* **术语检索**：查找 `Spatial relationship` 在 `Manifest file` 中如何通过 `supplemental enhancement information` (SEI) 之外的方式进行信号通知。

**结论**：D1 在编码架构上提供了基础，权利要求的创造性高度依赖于“清单文件”实现 Tile 级 ROI 增强的技术细节。如果能证明上述清单文件处理逻辑在流媒体传输领域为公知手段，则权利要求 1 很可能被判定为不具备创造性。

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

本案涉及的技术核心是在基于HTTP的动态自适应流媒体（如DASH）或图块化（Tiled）视频流传输中，如何通过基础流与增强图块流的结合，实现客户端对感兴趣区域（ROI）的自适应动态增强与渲染修改。

以下针对您提供的对比文件进行深度比对与创造性分析。为了行文清晰，我们用以下公开号指代各对比文件：

* **D1**：`GB2524531A`（Methods, devices, and computer programs for improving streaming of partitioned timed media data.）

* **D2**：`JPWO2014002619A1 / WO2014002619A1`（画像復号装置、画像復号方法、画像符号化装置及び画像符号化方法）

---

### 一、 权利要求技术特征比对表格及详细出处

为了清晰展现特征的公开情况，以下表格列出了权利要求1拆解后的技术特征A~S，并紧密结合对比文件的原文及详细出处（段落号/页面说明）进行了毫无悬念公开（实质公开）或未公开的判定。

---

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

在创造性分析中，**D1（GB2524531A）最适合作为本申请的“最接近的对比文件”**。

#### 1. 技术领域与技术问题角度

* **目标专利的技术领域与问题**：目标专利致力于解决在**网络流媒体传输环境（基于清单文件/Manifest）**下，客户端如何智能、自适应地请求基础流及对应的增强图块流，并在客户端进行双解码器架构的独立解码与ROI区域的空间渲染替换，从而优化带宽并增强局部画质。

* **D1的技术领域与问题**：D1同样处于**基于HTTP的动态自适应流媒体（DASH）领域**，明确提出了如何解决在DASH MPD（清单文件）中无法有效描述图块（Tile）依赖性的缺陷。它解决的技术问题是：如何通过扩展清单文件（如DASH的SRD空间描述和`@dependencyId`、`@codec`），使客户端能识别mandatory（强制）和optional（可选）的图块流，从而允许用户动态缩放（Zoom-in）或请求特定高分辨率ROI区域。这与目标专利从系统架构到网络传输的出发点几乎完全一致。

* **D2的局限性**：D2虽然公开了双解码器（第1复号部和第2复号部）及ROI图块分割，但其本质上是**传统视频编解码（Video Coding）层面的区域可伸缩性（Scalability）设计**。D2解决的问题是如何在码流内部通过修改SPS/PPS/SEI等参数来限制帧内/帧间预测以支持局部解码，它**完全没有网络流媒体、清单文件（Manifest）、URL标识符以及基于清单文件的自适应网络请求**的概念。

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

* D1和目标专利都达到了“通过网络清单文件实现空域重叠计算，从而精确、按需下载局部图块以节省网络带宽并提升特定区域画质”的技术效果。

* 因此，无论是从所解决的技术问题、采用的系统框架（DASH/清单），还是最终的技术效果来看，D1都是最接近的现有技术。

---

### 三、 创造性评述：未被公开的特征与薄弱技术特征

基于将 **D1 作为最接近的对比文件（最接近现有技术）** 的前述判定，我们来排查权利要求1的实质性区别特征：

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

在比对中可以发现，虽然D1公开了绝大部分网络流传输、清单文件的特征（K、L、M、N），但在**客户端解码与渲染阶段的架构**上，目标专利具有更具体且特殊的表述：

* **特征O、P**：明确要求客户端连接**“第一解码器”**和**“第二解码器”**，分别独立解码基础视频帧与图块化视频帧。

* **特征R、S**：明确要求在渲染时，用第二解码器生成的图块化视频帧的增强视觉内容，去**“替换或混合”**第一解码器生成的基础视频帧中的ROI区域。

**其他对比文件（D2）的公开情况**：

上述双解码器及合成的架构，恰好被 **D2（WO2014002619A1）** 实质公开。D2在第[0098]、[0120]段明确公开了通过“第1复号部6a”解码ROI层，“第2复号部6b”解码非ROI（或增强）层，并通过“合成部8”将两者合成复原图像的技术方案。

#### 2. 针对无效请求“最薄弱的技术特征”

如果在无效宣告程序中代表请求人攻击该专利，本权利要求**最薄弱（即最容易被攻破、创造性最低）**的特征是：**通过双解码器并行解码并进行图像区域的合成渲染/替换（特征O、P、Q、R、S的组合）**。

* **理由**：目标专利的全部方案实质上是由“DASH自适应流媒体传输（D1）”和“双解码器多层多图块空间合成（D2）”两部分拼凑而成。

* 在D1中，已经公开了在清单文件中利用SRD发信号通知空间关系，并由客户端按需下载基础流和独立图块流。

* 在D2中，已经公开了使用第一解码器和第二解码器分别解码不同流，再通过合成部进行空间拼接与混合替换。

* 将D1的网络传输及清单解析机制，与D2的标准双解码器合成架构相结合，属于本领域技术人员为了在网络流媒体中实现区域可伸缩性（Regional Scalability）而进行的**常规技术结合**。其在技术上并未产生超出预期的协同效应，仅是两段现有技术的组合拳。

---

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

为了在后续的无效程序中彻底推翻该权利要求（或者针对其可能提交的修改进行防御），建议采取以下精准检索策略：

1. **关键词与分类号的交叉检索（流媒体 + 编解码合成）**

* **IPC/CPC分类号**：重点锁定 `H04N21/845`（流媒体文件的分块/分段处理）、`H04N21/2662`（基于客户端能力的自适应流传输）、`H04N19/30`（可伸缩视频编码）、`H04N19/167`（基于感兴趣区域ROI的视频编码）。

* **动态组合检索式**：`(DASH OR "Dynamic Adaptive Streaming" OR MPD OR "manifest file") AND (Tile OR "Tiled video" OR "independent tile") AND (ROI OR "Region of interest" OR "spatial relationship") AND ("dual decoder" OR "two decoders" OR "replace" OR "blending")`。

2. **追溯 3GPP 标准提案（SA4/MPEG 联合工作组文档）**

* 本专利的清单结构（基础流ID与增强图块流ID关联、空间关系信号通知）具有浓厚的 **3GPP MPEG-DASH SRD（Spatial Relationship Description）标准规范** 演进背景。

* **检索策略**：建议深入检索 2013年-2015年 期间，由大北欧（Ericsson、Nokia）、Qualcomm、Canon等公司在 **MPEG 工作组（ISO/IEC JTC1/SC29/WG11）** 提交的关于 “DASH SRD for HEVC Tiles” 或 “Virtual Representations for Tile Tracks” 的标准技术提案（Contributions）。标准提案中往往会极为详细地阐述客户端如何利用清单文件解析URL并调用双硬解芯片（Dual Decoders）进行Alpha混合（Blending）或覆盖替换（Overlay/Replace）的渲染流程。这类公开出版物对破坏其“双解码器清单关联请求”的创造性往往具有一击必杀的效果。

根据权利要求1所述的方法，其中，位置信息包括一个或多个空间关系描述符SRD；空间关系描述符与基础流和/或增强图块流相关联；空间关系描述符向客户端设备发信号通知关于视觉内容在基础流的视频帧中的位置和/或关于图块在图块化的增强图块流的图块化视频帧中的位置。

根据权利要求1或2所述的方法，其中，清单文件还包括与一个或多个增强图块流中的至少一个相关联的增强信息；增强信息被配置用于向客户端设备发信号通知关于由增强图块流提供的增强的类型；并且可选地用于向客户端设备提供与由所述增强图块流标识符定义的一个或多个增强图块流的分辨率、比特率、色彩深度、帧速率中的至少一个相关联的一个或多个增强参数。

根据权利要求1或2所述的方法，还包括确定像素替换信息，其用于向渲染设备发信号通知关于与基础流的视频帧中的至少一个感兴趣区域相关联的基础流的视频帧中的像素；渲染设备使用像素替换信息来用图块化视频帧的增强视觉内容的相关联的像素信息替换或混合基础流的视频帧中的至少一个感兴趣区域的至少一部分中的像素信息。

根据权利要求4所述的方法，其中，像素替换信息是至少部分地基于清单文件中的图块位置信息来确定的。

根据权利要求1或2所述的方法，其中，所述形成包括在所述修改之前，基于关于一个或多个增强图块流的图块化视频帧的视频和/或图片特性的信息来调整所述基础视频帧的视频 and/或图片特性；所述调整包括提升所述基础视频帧的所述视频和/或图片特性以匹配一个或多个增强图块流的图块化视频帧的视频和/或图片特性。

根据权利要求1或2所述的方法，其中，与第一图块化视频帧中的图块相关联的媒体数据被编码为使得所述媒体数据不具有对第一图块化视频帧中的一个或多个其它图块的媒体数据的任何空间解码依赖性；和/或其中，与所述图块相关联的媒体数据被编码为使得所述媒体数据不具有对在第一图块化视频帧之前或者第一图块化视频帧之后的一个或多个图块化视频帧中的其它图块的媒体数据的任何时间解码依赖性。

根据权利要求1或2所述的方法，其中，增强图块流包括具有增强的亮度信息的媒体数据。

根据权利要求1或2所述的方法，其中，修改所述至少一个感兴趣区域的视觉内容的至少一部分包括将包括基础流的视频帧的第一视频帧缓冲器的内容复制到媒体设备的输出帧缓冲器中；用包括与一个或多个增强图块流相关联的图块化视频帧的第二视频帧缓冲器中的对应像素位置处的像素值覆写或混合输出帧缓冲器中与至少一个感兴趣区域相关联的像素值；其中二进制掩码指示第二视频帧缓冲器中的哪些像素值需要被复制到输出帧缓冲器中。

根据权利要求1或2所述的方法，其中，所述一个或多个增强图块流是基于媒体流式传输协议或媒体传输协议、自适应流式传输协议或用于包化媒体数据的传输协议的数据容器来格式化的；和/或其中，基于支持图块化视频帧的编解码器对一个或多个增强图块流的媒体数据进行编码；和/或其中，由一个或多个增强图块流标识符定义的一个或多个增强图块流的媒体数据被存储 in 图块轨道中；并且其中，与一个或多个增强图块流的至少一部分相关联的元数据被存储在至少一个基础轨道中。

根据权利要求4所述的方法，其中所述像素替换信息包括位图。

根据权利要求10所述的方法，其中所述图块轨道和至少一个基础轨道具有基于ISO/IEC 14496‑12 ISO基础媒体文件格式ISOBMFF或ISO基础媒体文件格式中的NAL单元结构化视频的ISO/IEC 14496‑15托架的数据容器格式。