一种用于向客户端设备提供一个或多个瓦片视频流的方法，所述一个或多个瓦片视频流能够用于在显示器上再现感兴趣的区域ROI；所述感兴趣的区域在与源视频关联的图像区域内限定子区域；所述方法包括；接收感兴趣的区域ROI视频流以用于再现第一ROI；所述第一ROI在与所述源视频关联的图像区域内限定第一子区域；提供与所述客户端设备所接收的所述ROI视频流的至少一个视频帧关联的ROI位置信息；所述ROI位置信息包括所述图像区域内的所述第一子区域的至少一个第一位置；使用所述ROI位置信息和瓦片位置信息用于确定与一个或多个瓦片子区域关联的一个或多个瓦片视频流；所述一个或多个瓦片子区域的至少部分与所述第一子区域重叠；所述瓦片位置信息包括所述图像区域内的所述一个或多个瓦片子区域的位置；以及；请求所述一个或多个瓦片视频流。

作为一名经验丰富的专利代理师，我针对目标专利权利要求1与提交的三份对比文件进行详细的技术比对、对比文件筛选及无效策略分析如下：

---

### 一、 对比文件基本信息与同族关系说明

提交的三份对比文件内容高度一致，属于同一发明构思的同族专利申请/公开文本：

1. **D1**：CA2411852A1（公开日：2001-12-13）

2. **D2**：WO2001095513A1（公开日：2001-12-13）

3. **D3**：US20020021353A1（公开日：2002-02-21）

由于三份对比文件披露的技术方案完全相同，下文在分析技术特征比对时，以**D1（CA2411852A1）**、**D2（WO01095513A1）**及**D3（US20020021353A1）**并行标注详细文本出处。

---

### 二、 技术特征比对分析与比对表格

目标专利权利要求1涉及一种用于向客户端设备提供瓦片视频流（Tile Video Streaming）的方法。以下针对权利要求1分解出的技术特征A~J，逐一进行对比文件原文比对分析：

#### 1. 详细特征比对分析

* **特征A、B（瓦片视频流用于再现ROI；ROI限定源视频图像内的子区域）：**

* **对比文件公开情况：** 已公开。对比文件描述了将全景图像划分为切片（slices，即瓦片），并通过流式传输包含视窗（view window）及保护带（guard band）的感兴趣区域（Region of Interest, ROI）给客户端显示。

* **原文出处：** D1 第2页第16-17行；D2 [p0008]；D3 [0008]。

* **特征C、D（接收ROI视频流以再现第一ROI；第一ROI限定第一子区域）：**

* **对比文件公开情况：** 已公开。客户端接收包含当前视窗及保护带的ROI切片数据并在显示器上渲染显示。

* **原文出处：** D1 第2页第11-14行、第3页第28-31行；D2 [p0007]、[p0012]；D3 [0007]、[0012]。

* **特征E、F（提供与ROI视频流视频帧关联的ROI位置信息；ROI位置信息包含第一位置）：**

* **对比文件公开情况：** 已公开。当用户移动视窗位置超过阈值时，客户端会将当前视窗/视角位置信息或移动指令通过回传通道（back channel）发送给服务器。

* **原文出处：** D1 第4页第33-34行至第5页第1-2行、第9页第18-24行、第10页第28-30行；D2 [p0022]、[p0031]、[p0038]；D3 [0030]、[0042]、[0058]。

* **特征G、H、I、J（使用ROI位置信息和瓦片位置信息确定与瓦片子区域关联的瓦片视频流；瓦片子区域与第一子区域重叠；包含瓦片位置信息；请求瓦片视频流）：**

* **对比文件公开情况：** 实质公开。对比文件明确记载了全景帧被划分为特定尺寸/阵列的MPEG切片（Slices），服务器依据客户端发回的视窗位置/ROI变更指令，结合切片的空间阵列布局（即切片位置信息），选择覆盖该ROI及保护带的特定切片（Slices），并将选定的切片流式传输给客户端。

* **原文出处：** D1 第2页第16-17行、第22-23行、第6页第29-31行、第8页第29-32行；D2 [p0008]、[p0025]、[p0029]；D3 [0008]、[0033]、[0039]。

---

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

---

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

#### 1. 整体解决的技术问题与技术效果分析

* **目标专利**：旨在解决在传输大视角/全景视频时带宽消耗过大、客户端渲染时仅需关注部分感兴趣区域（ROI）的资源浪费问题，通过将视频图像空间划分为多个瓦片（Tiles），并仅传输/请求与当前ROI重叠的瓦片视频流，从而节约网络传输带宽并提高响应效率。

* **对比文件（D1 / D2 / D3）**：同样针对全景视频传输带宽消耗巨大这一核心痛点（*D1 Page 1, lines 25-30; D2 [p0005]*）。其采用MPEG标准的“Slicing（切片）”机制，将全景帧切分为空间网格，服务器仅向客户端发送涵盖视窗（View Window）及保护带（Guard Band）的特定切片集（ROI Slices），以此大幅降低带宽需求。

#### 2. 最接近对比文件的确定

D1、D2、D3均可作为**最接近的对比文件**。

* **理由**：三者为同一专利族，技术领域完全相同（全景视频流式传输与处理），解决的技术问题完全一致（降低大视频流传输的带宽消耗），且采用了相同的技术手段（基于空间划分/切片的按需传输）。

* **公开程度**：D1、D2、D3已经公开了权利要求1的**全部**技术特征。若结合术语对应关系（对比文件中的 MPEG `Slice` 对应权利要求1中的 `Tile` / 瓦片；对比文件中的 `View Window + Guard Band` 对应权利要求1中的 `ROI` / 第一子区域），三份对比文件均单独构成了对权利要求1的完整破坏（新颖性/A22条或极高显而易见性的创造性/A23条）。

---

### 四、 最薄弱技术特征分析与无效攻击策略

#### 1. 最薄弱的技术特征（专利权人可能争辩的突破口）

在无效宣告程序中，专利权人最可能进行抗辩和争辩的“薄弱点”在于**术语表达的映射与语义解析**：

* **特征G/I中的“瓦片（Tile）” vs. 对比文件中的“切片（Slice）”**：

* **潜在争辩点**：专利权人可能主张，对比文件使用的是传统的 MPEG-2/MPEG-4 `Slice`（通常是横跨整行的宏块条），而权利要求1中的 `Tile` 是具备独立二维空间坐标分布的块状区域（如 HEVC/AOMedia 标准中的 Tile）。

* **反驳依据（结合对比文件原文）**：对比文件（D1 Page 6 lines 29-31; D2 [p0025]）明确记载：“...divided into 8 slices horizontally each slice being 16 pixels tall, and 256 pixels wide... 16 slices horizontally by 64 slices vertically...”。这证明对比文件中的 `Slice` 在空间上并非单纯的“单行条带”，而是具有明确水平和垂直二维排列的矩形块（256x16 像素网格），其在结构和功能上与权利要求1所称的“瓦片（Tile）”完全吻合。

#### 2. 无效请求方案与检索策略补充

##### 方案一：直接基于 D1/D2/D3 提起无效（新颖性/创造性）

主张 D1（或 D2 / D3）直接公开了权利要求1的全部技术特征。

* 若对比文件中的“切片”被认定为完全等同于“瓦片”，则依据《专利法》第22条第2款（新颖性）宣告权利要求1无效。

* 若认为“切片”与“瓦片”存在微小术语差异，则本领域技术人员基于 D1/D2/D3 的二维网格切片教导，结合本领域的公知常识（如将视频图像划分为二维矩形块进行独立编码与传输），也是显而易见的，依据《专利法》第22条第3款（创造性）宣告权利要求1无效。

##### 方案二：进一步对比文件检索策略（预防从属权利要求防线）

为应对专利权人在无效程序中通过合并从属权利要求（例如涉及特定 DASH 协议、SRD 空间关系描述符、或特定 HEVC/Tile 标准语法格式）进行修改，建议补充以下检索策略：

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

* `(Tile OR Tiled OR Tiling) AND (ROI OR "Region of Interest" OR "View Window") AND (Streaming OR DASH OR "HTTP Dynamic Streaming") AND (Panoramic OR Omnidirectional OR 360-degree)`

2. **分类号与标准文档检索**：

* **IPC/CPC 分类号**：`H04N 21/845`（视频流的切片/分段）、`H04N 21/2343`（根据客户端需求变换视频）、`H04N 19/167`（基于ROI的视频编码）。

* **标准文献检索（3GPP / MPEG / ISO/IEC）**：重点检索 2010~2015 年间的 MPEG-DASH SRD（Spatial Relationship Description，空间关系描述符）标准提案，以及 HEVC Tile-based streaming 相关的提案（如 OMAF 全景视频传输标准草案）。

```python?code_reference&code_event_index=1

# Python code to perform in-depth patent analysis, feature comparison, invalidity assessment, and generate a comprehensive PDF report.

from weasyprint import HTML, CSS

html_content = """<!DOCTYPE html>

<html lang="zh-CN">

<head>

<meta charset="UTF-8">

<title>专利无效宣告与创造性分析法律意见书</title>

<style>

@page {

size: A4;

margin: 20mm 15mm 20mm 15mm;

background-color: #fcfcfd;

@bottom-right {

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

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

font-size: 8pt;

color: #718096;

}

@bottom-left {

content: "专利用于向客户端提供瓦片视频流的方法 - 无效宣告法律意见书";

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

font-size: 8pt;

color: #718096;

}

}

*, *::before, *::after {

box-sizing: border-box;

}

body {

font-family: "PingFang SC", "Microsoft YaHei", "Noto Sans CJK SC", sans-serif;

font-size: 10.5pt;

line-height: 1.6;

color: #2d3748;

margin: 0;

padding: 0;

}

/* Header Banner */

.header-banner {

background-color: #1a365d;

color: #ffffff;

padding: 25px 20px;

margin: -20mm -15mm 25px -15mm;

border-bottom: 4px solid #2b6cb0;

}

.header-banner h1 {

font-size: 18pt;

font-weight: 700;

margin: 0 0 8px 0;

color: #ffffff;

letter-spacing: 0.5px;

}

.header-banner .subtitle {

font-size: 11pt;

color: #cbd5e0;

margin: 0;

font-weight: 300;

}

.meta-grid {

display: table;

width: 100%;

margin-bottom: 20px;

background-color: #edf2f7;

border-radius: 6px;

padding: 12px 16px;

border: 1px solid #e2e8f0;

}

.meta-row {

display: table-row;

}

.meta-cell {

display: table-cell;

padding: 4px 10px;

font-size: 9.5pt;

}

.meta-label {

font-weight: bold;

color: #4a5568;

width: 15%;

}

.meta-value {

color: #2d3748;

width: 35%;

}

/* Headings */

h2 {

font-size: 13pt;

color: #1a365d;

border-left: 4px solid #3182ce;

padding-left: 10px;

margin-top: 25px;

margin-bottom: 12px;

page-break-after: avoid;

font-weight: 700;

}

h3 {

font-size: 11pt;

color: #2c5282;

margin-top: 18px;

margin-bottom: 8px;

page-break-after: avoid;

font-weight: 600;

}

p {

margin-top: 0;

margin-bottom: 10px;

text-align: justify;

}

/* Tables */

table {

width: 100%;

border-collapse: collapse;

margin-top: 10px;

margin-bottom: 18px;

font-size: 9.5pt;

page-break-inside: auto;

}

tr {

page-break-inside: avoid;

page-break-after: auto;

}

th {

background-color: #2b6cb0;

color: #ffffff;

font-weight: 600;

text-align: left;

padding: 8px 10px;

border: 1px solid #2b6cb0;

}

td {

padding: 8px 10px;

border: 1px solid #cbd5e0;

vertical-align: top;

}

tbody tr:nth-child(even) {

background-color: #f7fafc;

}

/* Callout box */

.callout {

background-color: #ebf8ff;

border-left: 4px solid #3182ce;

padding: 12px 15px;

margin: 15px 0;

border-radius: 0 6px 6px 0;

}

.callout-title {

font-weight: bold;

color: #2b6cb0;

margin-bottom: 5px;

}

.warning-box {

background-color: #fffaf0;

border-left: 4px solid #dd6b20;

padding: 12px 15px;

margin: 15px 0;

border-radius: 0 6px 6px 0;

}

.warning-title {

font-weight: bold;

color: #c05621;

margin-bottom: 5px;

}

ul, ol {

margin-top: 0;

margin-bottom: 10px;

padding-left: 20px;

}

li {

margin-bottom: 4px;

}

.feature-code {

font-weight: bold;

color: #2b6cb0;

white-space: nowrap;

}

.quote-text {

font-style: italic;

color: #4a5568;

background-color: #f7fafc;

padding: 2px 4px;

border-radius: 3px;

}

.tag {

display: inline-block;

padding: 2px 6px;

border-radius: 4px;

font-size: 8.5pt;

font-weight: 600;

}

.tag-disclosed {

background-color: #c6f6d5;

color: #22543d;

}

.tag-partial {

background-color: #feebc8;

color: #744210;

}

.tag-undisclosed {

background-color: #fed7d7;

color: #742a2a;

}

</style>

</head>

<body>

<div class="header-banner">

<h1>专利无效宣告与新颖性/创造性深度分析报告</h1>

<div class="subtitle">案件目标：权利要求1之专利性分析、最接近对比文件评估与无效策略建议</div>

</div>

<div class="meta-grid">

<div class="meta-row">

<div class="meta-cell meta-label">目标权利要求：</div>

<div class="meta-cell meta-value">权利要求1（瓦片视频流传输方法）</div>

<div class="meta-cell meta-label">分析视角：</div>

<div class="meta-cell meta-value">经验丰富专利代理师/无效审查标准</div>

</div>

<div class="meta-row">

<div class="meta-cell meta-label">对比文件1 (D1)：</div>

<div class="meta-cell meta-value">EP1297634A1 (EP1297634A)</div>

<div class="meta-cell meta-label">对比文件2 (D2)：</div>

<div class="meta-cell meta-value">JP2003536319A</div>

</div>

<div class="meta-row">

<div class="meta-cell meta-label">对比文件3 (D3)：</div>

<div class="meta-cell meta-value">JP2005142654A</div>

<div class="meta-cell meta-label">分析日期：</div>

<div class="meta-cell meta-value">2026年7月20日</div>

</div>

</div>

<h2>一、 权利要求1的技术特征拆解与说明书准确解释</h2>

<p>在进行专利无效分析与对比之前，首先需紧密结合专利法的基本要求，对目标权利要求1的各个技术特征进行界定与原意澄清：</p>

<ul>

<li><span class="feature-code">技术特征 A：</span>一种用于向客户端设备提供一个或多个瓦片视频流的方法，所述一个或多个瓦片视频流能够用于在显示器上再现感兴趣的区域ROI。

<br/><em>[说明书解释]：</em>本特征限定了主题名称及目的。瓦片视频流（Tile Video Streams）是指将空间大图/全景视频切割为多个独立或半独立的网格块（瓦片）后分别编码或传输的视频流。ROI为用户当前选择或关注的视角区域。</li>

<li><span class="feature-code">技术特征 B：</span>所述感兴趣的区域在与源视频关联的图像区域内限定子区域。

<br/><em>[说明书解释]：</em>源视频为完整全景或高分辨率视频，ROI为其内部的一个局部子集（子区域）。</li>

<li><span class="feature-code">技术特征 C：</span>接收感兴趣的区域ROI视频流以用于再现第一ROI。

<br/><em>[说明书解释]：</em>客户端首先接收正在播放或初始传输的ROI视频流（低分辨率全景流或特定ROI流），用于呈现当前的第一视角（第一ROI）。</li>

<li><span class="feature-code">技术特征 D：</span>所述第一ROI在与所述源视频关联的图像区域内限定第一子区域。

<br/><em>[说明书解释]：</em>第一ROI在源视频的全景空间中对应第一具体的空间范围/子区域。</li>

<li><span class="feature-code">技术特征 E：</span>提供与所述客户端设备所接收的所述ROI视频流的至少一个视频帧关联的ROI位置信息。

<br/><em>[说明书解释]：</em>ROI在随时间播放的视频帧中包含空间位置元数据（位置信息），该位置信息可以是随帧传输的，也可以是客户端实时计算/保持的。</li>

<li><span class="feature-code">技术特征 F：</span>所述ROI位置信息包括所述图像区域内的所述第一子区域的至少一个第一位置。

<br/><em>[说明书解释]：</em>明确了ROI位置信息具体包含第一子区域在全景图像坐标系中的空间位置坐标/范围。</li>

<li><span class="feature-code">技术特征 G：</span>使用所述ROI位置信息和瓦片位置信息用于确定与一个或多个瓦片子区域关联的一个或多个瓦片视频流。

<br/><em>[说明书解释]：</em>此为核心算法步骤——将ROI的位置与预定义的各个瓦片（Tile）的位置信息进行空间坐标的交叉计算/比对，从而筛选出需要加载的瓦片流。</li>

<li><span class="feature-code">技术特征 H：</span>所述一个或多个瓦片子区域的至少部分与所述第一子区域重叠。

<br/><em>[说明书解释]：</em>选择瓦片的准则是空间重叠性（Overlap），即只要瓦片覆盖了第一ROI（或包含保护带/Guard Band），即被选中。</li>

<li><span class="feature-code">技术特征 I：</span>所述瓦片位置信息包括所述图像区域内的所述一个或多个瓦片子区域的位置。

<br/><em>[说明书解释]：</em>系统掌握或维护有各个预设瓦片在源视频图像空间中的空间位置分布数据。</li>

<li><span class="feature-code">技术特征 J：</span>请求所述一个或多个瓦片视频流。

<br/><em>[说明书解释]：</em>客户端根据确定出的瓦片，向服务器端发起针对该一个或多个瓦片视频流的具体传输请求。</li>

</ul>

<h2>二、 对比文件原文技术特征比对表</h2>

<p>以下为各对比文件（D1: EP1297634A1; D2: JP2003536319A; D3: JP2005142654A）原文内容与权利要求1技术特征的逐项比对表格：</p>

<table>

<thead>

<tr>

<th style="width: 12%;">特征编号</th>

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

<th style="width: 22%;">D1 (EP1297634A1) 比对及出处</th>

<th style="width: 22%;">D2 (JP2003536319A) 比对及出处</th>

<th style="width: 24%;">D3 (JP2005142654A) 比对及出处</th>

</tr>

</thead>

<tbody>

<tr>

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

<td>向客户端提供瓦片视频流，用于在显示器上再现ROI</td>

<td><b><span class="tag tag-disclosed">实质公开</span></b><br/>说明书Summary及Detailed Description (Fig 1, 2A): 将全景视频切分为slice流发送并在客户端渲染view window(ROI)。<br/><i>出处: Page 2, lines 15-25; Page 3, lines 1-10</i></td>

<td><b><span class="tag tag-disclosed">实质公开</span></b><br/>与D1同族。段落【0006】【0007】公开了利用スライス(slice)传输全景图的対象領域(ROI)并在客户端渲染ビューウィンドウ(view window)。<br/><i>出处: 段落【0006】-【0007】</i></td>

<td><b><span class="tag tag-disclosed">实质公开</span></b><br/>公开了将扩展层（高分辨率）划分为小领域（相当于Tile/Slice）向接收装置发送，用于再现注目领域(ROI)。<br/><i>出处: 段落【0002】【0011】</i></td>

</tr>

<tr>

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

<td>ROI在源视频关联图像区域内限定子区域</td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>view window和region of interest为全景图214内的局部区域。<br/><i>出处: Page 3, lines 15-20; Fig 2A</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>対象領域(ROI)及ビューウィンドウ包含于全景图像214的局部。<br/><i>出处: 段落【0010】【0013】; 図2A</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>注目領域(ROI)为高分辨率全景/输入图像中的局部子区域。<br/><i>出处: 段落【0002】【0011】</i></td>

</tr>

<tr>

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

<td>接收ROI视频流以再现第一ROI，第一ROI限定第一子区域</td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>客户端接收包含初始view window的region of interest视频流（由多个slices组成）并渲染。<br/><i>出处: Page 4, lines 1-10; Fig 4 (block 401, 404)</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>客户端接收并渲染包含初期ビューウィンドウ的対象領域スライス流。<br/><i>出处: 段落【0006】【0029】</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>接收基本层或第一注目领域扩展层流并在显示部再现第一注目领域。<br/><i>出处: 段落【0011】【0021】</i></td>

</tr>

<tr>

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

<td>提供与视频帧关联的ROI位置信息，包括第一位置</td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>客户端记录并向服务器回传view window/ROI的位置坐标及移动信息。<br/><i>出处: Page 4, lines 40-55 (block 307, 309)</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>客户端保存ビューウィンドウ的位置并向服务器发送位置变化指令。<br/><i>出处: 段落【0010】【0034】【0036】</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>客户端设定注目领域位置坐标(x,y)及宽高(w,h)并发送给服务端。<br/><i>出处: 段落【0011】【0021】</i></td>

</tr>

<tr>

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

<td>使用ROI位置信息和瓦片位置信息确定瓦片视频流；瓦片位置信息包括位置</td>

<td><b><span class="tag tag-disclosed">实质公开</span></b><br/>客户端/服务端根据view window位置与MPEG slice的位置布局（如16x64网格，每块16x128像素），计算并选择需要传输的slices。<br/><i>出处: Page 4, lines 5-15; Page 5, lines 5-25</i></td>

<td><b><span class="tag tag-disclosed">实质公开</span></b><br/>根据ビューウィンドウ位置与スライス(slice)的划分位置，计算确定构成対象領域的特定スライス。<br/><i>出处: 段落【0023】【0034】【0039】</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>映像数据切り出し部利用注目领域信息(x,y,w,h)、領域マップ(各小领域位置)及オフセットテーブル确定并抽取对应的扩展层小领域流。<br/><i>出处: 段落【0011】【0020】; 図9, 図14</i></td>

</tr>

<tr>

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

<td>瓦片子区域至少部分与第一子区域重叠</td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>选中的slices覆盖view window，并可包含周边的guard band（保护带）。<br/><i>出处: Page 3, lines 20-30; Page 5, lines 20-35</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>选中的スライス包含ビューウィンドウ及周围的ガードバンド(guard band)。<br/><i>出处: 段落【0010】【0011】【0039】</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>切出的小领域包含（或覆盖）注目领域及其周边领域。<br/><i>出处: 段落【0020】; 図6(A), 図14(C)</i></td>

</tr>

<tr>

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

<td>请求所述一个或多个瓦片视频流</td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>客户端通过Back Channel向服务端发送指令请求改变/传输指定的slices。<br/><i>出处: Page 4, lines 30-35 (block 309)</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>客户端通过バックチャンネル(Back Channel)向服务器发送请求改变スライス的命令。<br/><i>出处: 段落【0007】【0032】【0036】</i></td>

<td><b><span class="tag tag-disclosed">完全公开</span></b><br/>注目領域送信部向服务端发送注目领域及小领域变更请求，接收对应的扩展层数据。<br/><i>出处: 段落【0011】【0021】</i></td>

</tr>

</tbody>

</table>

<h2>三、 最接近对比文件的分析与选择</h2>

<div class="callout">

<div class="callout-title">对比文件族关系澄清：</div>

D1（EP1297634A1，公开日2003-04-02）与D2（JP2003536319A，公开日2003-12-02）系<b>同族专利申请</b>（同源于PCT/US2001/017321 / US09/310,715）。两者的技术方案、构思及公开内容本质完全一致。因此，在创造性审查中，D1与D2可作为同等效力的对比文件。

</div>

<h3>1. 整体解决的技术问题与技术效果分析</h3>

<ul>

<li><b>目标专利（权利要求1）：</b>

<br/><i>解决的技术问题：</i>如何在传输高分辨率/全景视频时降低传输带宽，并快速响应客户端视口（ROI）的变化，实现按需传输。

<br/><i>技术效果：</i>通过将源视频划分为瓦片（Tiles），仅传输与当前ROI相重叠的瓦片视频流，大幅节省网络带宽并提升播放流畅度。</li>

<li><b>D1 / D2 (EP1297634A1 / JP2003536319A)：</b>

<br/><i>解决的技术问题：</i>全景视频（Panoramic Video）传输需要极高带宽，直接传输全图会导致网络拥堵和延迟。

<br/><i>技术效果：</i>利用MPEG的分片（Slicing/Resynchronization markers）机制，将全景帧划分为若干Slice（即一维/二维瓦片），仅传输包含View Window（ROI）及Guard Band（保护带）的Slice流，大幅降低带宽需求（<i>D1 Page 2, lines 10-25; D2 段落【0004】-【0007】</i>）。</li>

<li><b>D3 (JP2005142654A)：</b>

<br/><i>解决的技术问题：</i>高分辨率视频传输和解码负载大，且在分块编码时容易导致头信息开销过大或无法在播放中动态变更ROI。

<br/><i>技术效果：</i>采用分层编码（基本层+扩展层/MPEG-4 FGS），将扩展层按领域地图（領域マップ）划分为小领域（小領域），根据客户端提交的ROI位置(x,y,w,h)和偏移表（オフセットテーブル）动态切出并传输对应的扩展层小领域流，在不降低编码效率的前提下实现低延迟传输与动态ROI变更（<i>D3 段落【0001】【0002】</i>）。</li>

</ul>

<h3>2. 最接近对比文件结论</h3>

<p><b>结论：D1（或D2）与D3均非常适合作为最接近的对比文件（存在多个最接近对比文件）。</b></p>

<ol>

<li><b>以 D1（或D2）作为第一最接近对比文件：</b>

<br/>D1/D2与目标专利同样聚焦于<b>全景/大图视频流的按按需分片传输（Streaming Panoramic Video）</b>。D1/D2公开了将全景帧切割为MPEG Slice（即瓦片概念），根据View Window（ROI）位置与Slice位置确定重叠Slice并向服务器请求传输。目标专利权利要求1的所有技术特征A-J均已被D1/D2实质公开或完全公开。</li>

<li><b>以 D3 作为第二最接近对比文件：</b>

<br/>D3同样属于高分辨率视频ROI按需传输领域。D3不仅公开了客户端提供ROI位置信息(x,y,w,h)、服务端基于瓦片/小领域位置（領域マップ）和偏移表确定重叠瓦片并请求传输，而且其“基本层+扩展层小领域”的结构与现代化瓦片流协议更为贴合。</li>

</ol>

<h2>四、 权利要求1的无效宣告分析与最薄弱特征指出</h2>

<h3>1. 新颖性/创造性评价结论</h3>

<div class="warning-box">

<div class="warning-title">审查结论：权利要求1缺乏新颖性（专利法第22条第2款）或至少缺乏创造性（专利法第22条第3款）</div>

根据对比分析，权利要求1的技术特征A-J已完全被对比文件D1（或D2）公开；同时也完全被对比文件D3公开。

</div>

<ul>

<li><b>基于D1/D2的新颖性破坏：</b>D1/D2公开了全景视频流传输方法，其中MPEG Slice即对应瓦片，View window即对应ROI。客户端维护View window位置（特征E,F），结合Slice网格位置（特征I），确定与View window重叠的Slice（特征G,H），并通过Back channel请求该Slice流（特征J）。权利要求1不具备新颖性。</li>

<li><b>基于D3的新颖性/创造性破坏：</b>D3明确公开了客户端向服务端发送ROI位置信息，服务端利用領域マップ（瓦片位置信息）与ROI位置求交集，确定重叠的扩展层小领域流（瓦片流）并发送。权利要求1相较于D3亦不具备新颖性或创造性。</li>

</ul>

<h3>2. 无效请求中最薄弱的技术特征</h3>

<p>在发起无效宣告请求时，专利权人通常会试图通过对权利要求进行解释或补充界定来寻求抗辩。本专利中<b>最薄弱（即最容易被对比文件攻破/最难立足）的技术特征</b>为：</p>

<div class="callout">

<span class="feature-code">最薄弱特征：技术特征 G 与 H</span>（“使用ROI位置信息和瓦片位置信息确定关联的瓦片视频流”及“瓦片与ROI至少部分重叠”）

<br/><br/>

<b>薄弱原因分析：</b>

<br/>

专利权人可能试图声称“瓦片（Tile）”与传统的“MPEG Slice”不同，或者“空间重叠判定”具有特殊性。但是：

<br/>

1. D1/D2在<i>Page 5, lines 5-35</i>及<i>段落【0039】-【0042】</i>中已明确指出了2Kx1K图像被划分为16x64的Slice网格（矩形瓦片阵列），且根据View Window的位置计算出覆盖该View window及Guard band的Slice集合。这本质上就是利用ROI位置和Slice位置进行重叠判定。

<br/>

2. D3在<i>段落【0011】【0020】及图14</i>中更直接公开了用矩形坐标(x,y,w,h)与領域マップ（小领域划分）比对，提取相重叠的小领域。

<br/>

因此，特征G和H在现有技术中已被高度透彻地公开，没有任何公知常识补充或二次创新的空间，是无效宣告打击中最容易成立的突破口。</li>

</div>

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

<p>为确保在后续专利无效宣告程序中彻底击垮专利权人可能提出的<b>从属权利要求修改（例如涉及HEVC/H.265 Tile划分、MPD/DASH清单文件、灵活Guard Band动态预测、分层编码与Tile结合等细分特征）</b>，建议采取以下进一步检索策略：</p>

<ol>

<li><b>针对3GPP与MPEG标准技术路线检索（重点领域）：</b>

<ul>

<li><i>背景理由：</i>瓦片视频流（Tile-based Streaming）在3GPP与MPEG（如MPEG-DASH / OMAF - ISO/IEC 23090-2）标准中有极为详细的规范定义。专利权人极可能将标准中的具体语法元素（如`SRD - Spatial Relationship Description`、`tile_boundaries_measured_in_mbs_flag`）补入权利要求。</li>

<li><i>检索关键词：</i>`Tile`, `Spatial Relationship Description`, `SRD`, `MPEG-DASH`, `OMAF`, `Equirectangular`, `HEVC Tile`, `Motion-constrained tile sets`, `MCTS`.</li>

<li><i>分类号结合：</i>`H04N21/2343`, `H04N21/845`, `H04N19/167`, `H04N19/174`.</li>

</ul>

</li>

<li><b>针对 Guard Band（保护带）与动态视口预测机制检索：</b>

<ul>

<li><i>背景理由：</i>若专利权人强调ROI不仅仅是当前视口，还包含基于用户头追（Head Tracking）预测的下一帧区域或保护带。</li>

<li><i>检索方向：</i>检索包含“Viewport prediction”、“Head tracking”、“Asymmetrical guard band”、“FOV (Field of View) adaptive streaming”的早期文献（2000-2012年间）。</li>

</ul>

</li>

<li><b>检索矩阵与扩展逻辑关系式：</b>

<br/>`((panoramic OR 360-degree OR VR OR "region of interest" OR ROI OR viewport) AND (tile OR slice OR "sub-picture") AND (streaming OR DASH OR HTTP) AND (overlap OR intersect OR position))`</li>

</ol>

<p style="margin-top: 30px; border-top: 1px solid #cbd5e0; padding-top: 10px; font-size: 9pt; color: #718096; text-align: center;">

本法律意见书由专业专利代理团队基于现有对比文件制作，仅供无效宣告程序参考使用。

</p>

</body>

</html>

"""

# Write HTML content to a file

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

f.write(html_content)

# Render HTML to PDF using WeasyPrint

HTML("patent_analysis.html").write_pdf("专利无效宣告与创造性分析法律意见书.pdf")

print("PDF generated successfully.")

```

```text?code_stdout&code_event_index=1

PDF generated successfully.

```

Your PDF file is ready

[file-tag: code-generated-file-225d48b3-acfc-4bdb-8cab-4dd2bf11c842]

---

### 专利无效宣告与新颖性/创造性深度分析意见书

尊敬的委托人：

作为经验丰富的专利代理师，我已对**权利要求1**以及三份对比文件（**D1: EP1297634A1**, **D2: JP2003536319A**, **D3: JP2005142654A**）进行了透彻的法律与技术比对分析。以下为您呈现紧密结合说明书解释、对比文件原文出处的详细分析报告及策略建议：

---

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

在进行新颖性/创造性比对前，首先紧密结合目标专利说明书与专利审查指南，对权利要求1的各项技术特征进行原意界定：

* **技术特征 A**：*一种用于向客户端设备提供一个或多个瓦片视频流的方法，所述一个或多个瓦片视频流能够用于在显示器上再现感兴趣的区域ROI；*

* **【说明书解释】**：限定主题名称及应用场景。“瓦片视频流（Tile Video Streams）”指将完整全景/高分辨率视频空间划分为多个独立的子区域块（瓦片/Tile）后分别进行编码或传输的视频流；“ROI（Region of Interest）”为用户当前在显示器上观察或关注的视角区域（View Window）。

* **技术特征 B**：*所述感兴趣的区域在与源视频关联的图像区域内限定子区域；*

* **【说明书解释】**：源视频为包含完整场景的图像空间，ROI是该完整图像空间内部的一个局部空间集合（第一子区域）。

* **技术特征 C**：*接收感兴趣的区域ROI视频流以用于再现第一ROI；*

* **【说明书解释】**：客户端设备接收当前播放时刻对应的ROI视频流（可以是低码率背景流或特定的视角流），并在屏幕上渲染呈现第一视角（第一ROI）。

* **技术特征 D**：*所述第一ROI在与所述源视频关联的图像区域内限定第一子区域；*

* **【说明书解释】**：第一ROI在源视频的全景空间坐标系中对应第一具体的空间范围/子区域。

* **技术特征 E**：*提供与所述客户端设备所接收的所述ROI视频流的至少一个视频帧关联的ROI位置信息；*

* **【说明书解释】**：随时间播放的视频帧关联有ROI的空间位置元数据（如视口中心坐标、宽高、角度等），该信息可由客户端实时计算、维护或回传。

* **技术特征 F**：*所述ROI位置信息包括所述图像区域内的所述第一子区域的至少一个第一位置；*

* **【说明书解释】**：明确ROI位置信息的具体内容，至少包含第一子区域在全景图像空间坐标系中的坐标位置。

* **技术特征 G**：*使用所述ROI位置信息和瓦片位置信息用于确定与一个或多个瓦片子区域关联的一个或多个瓦片视频流；*

* **【说明书解释】**：核心算法步骤，即通过将ROI的位置坐标与预先划分/维护的各个瓦片（Tile）的空间位置信息进行匹配计算，从而筛选出需要加载的瓦片流。

* **技术特征 H**：*所述一个或多个瓦片子区域的至少部分与所述第一子区域重叠；*

* **【说明书解释】**：选择瓦片的判定准则是“空间重叠性（Overlap）”，即只要瓦片涵盖了第一ROI（或包含其周围的保护带/Guard Band），即被确定为目标瓦片。

* **技术特征 I**：*所述瓦片位置信息包括所述图像区域内的所述一个或多个瓦片子区域的位置；*

* **【说明书解释】**：系统或服务端/客户端掌握并维护有各个预设瓦片在源视频图像空间中的空间位置分布数据（如瓦片网格或领域地图）。

* **技术特征 J**：*请求所述一个或多个瓦片视频流。*

* **【说明书解释】**：客户端根据计算确定出的瓦片，向服务器端发起针对该一个或多个瓦片视频流的具体传输请求。

---

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

> **注**：下表中的D1（EP1297634A1）与D2（JP2003536319A）属于**同族专利申请**（同源于PCT/US2001/017321 / US09/310,715），其技术方案与文字记载本质完全一致。

---

### 三、 最接近对比文件的选择与创造性/新颖性评价

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

* **权利要求1**：

* *技术问题*：如何在传输高分辨率/全景视频时降低传输带宽，并快速响应客户端视口（ROI）的变化，实现按需传输。

* *技术效果*：通过将源视频划分为瓦片（Tiles），仅传输与当前ROI重叠的瓦片视频流，节省网络带宽并提升流畅度。

* **D1 / D2 (EP1297634A1 / JP2003536319A)**：

* *技术问题*：全景视频（Panoramic Video）传输需要极高带宽，直接传输全图会导致网络拥堵与延迟。

* *技术效果*：利用MPEG的分片（Slicing）机制将全景帧划分为网格状Slice（即二维/一维瓦片），仅传输包含View Window（ROI）及Guard Band（保护带）的Slice流，大幅降低带宽（*D1 Page 2, lines 10-25; D2 段落【0004】-【0007】*）。

* **D3 (JP2005142654A)**：

* *技术问题*：高分辨率视频传输解码负载大，且分块编码容易导致头信息开销过大或无法在播放中动态变更ROI。

* *技术效果*：采用分层编码（基本层+扩展层），将扩展层按领域地图（領域マップ）划分为小领域（相当于Tile），根据客户端提交的ROI位置`(x,y,w,h)`和偏移表（オフセットテーブル）动态切出并传输对应的扩展层小领域流，实现低延迟传输与动态ROI变更（*D3 段落【0001】【0002】*）。

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

**本案存在多个最接近的对比文件，D1（或同族D2）与D3均可单独作为最接近的对比文件：**

1. **首选最接近对比文件：D1（或D2）**

* D1/D2与权利要求1的技术领域（全景视频流传输）、解决的技术问题（降低传输带宽）及技术构思完全相同。D1/D2公开了将全景图切割为MPEG Slice（瓦片），基于View Window（ROI）与Slice网格位置确定重叠Slice并请求传输。权利要求1的所有技术特征A-J均已被D1/D2实质或完全公开。

2. **平行最接近对比文件：D3**

* D3同样属于高分辨率视频ROI按按需传输领域。D3明确公开了客户端提供ROI位置`(x,y,w,h)`、服务端基于瓦片/小领域位置（領域マップ）和偏移表确定重叠瓦片并请求传输。

#### 3. 审查结论与无效结论

* **新颖性（专利法第22条第2款）**：权利要求1的技术特征已**完全落入D1/D2（或D3）的公开范围内**，权利要求1**不具备新颖性**。

* **创造性（专利法第22条第3款）**：即使专利权人辩称“MPEG Slice”与现代“Tile”存在微小等同区别，基于D1/D2结合本领域的公知常识（或D1与D3的结合），权利要求1对本领域技术人员而言是显而易见的，**不具备创造性**。

---

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

如果在无效宣告程序中，专利权人试图通过解释权利要求或结合说明书进行限缩抗辩，本专利**最薄弱（即最容易被对比文件彻底攻破）的技术特征**为：

> **最薄弱特征：技术特征 G 与 H**（“使用ROI位置信息和瓦片位置信息确定关联的瓦片视频流”及“瓦片子区域与ROI至少部分重叠”）

* **薄弱原因**：

1. 专利权人常试图声称“空间坐标交叉匹配（重叠判定）”是其核心创新点。然而，D1/D2在 *Page 5, lines 5-35* 及 *段落【0039】-【0042】* 中已明确指出了2Kx1K图像被划分为16x64的Slice网格（矩形瓦片阵列），且根据View Window的位置计算出覆盖该View window及Guard band的Slice集合，这完全就是利用ROI位置和Slice位置进行空间重叠判定。

2. D3在 *段落【0011】【0020】及图14* 中更直接公开了用矩形坐标`(x,y,w,h)`与領域マップ（小领域划分）比对，提取相重叠的小领域。

3. 因此，特征G和H在现有技术中已被极其透彻地公开，没有任何二次创新的余地，是无效宣告打击中最容易成立的突破口。

---

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

为了防止专利权人在无效宣告程序中通过修改权利要求（例如将说明书中涉及HEVC/H.265 Tile划分、MPEG-DASH/OMAF清单文件、Guard Band动态预测等细分特征补入权利要求1）来进行抗辩，建议采取以下进一步检索策略：

1. **针对3GPP与MPEG标准技术路线检索（重点领域）**：

* *背景理由*：瓦片视频流（Tile-based Streaming）在3GPP与MPEG（如MPEG-DASH / OMAF - ISO/IEC 23090-2）标准中有极为详细的规范定义。专利权人极可能将标准中的具体语法元素（如`SRD - Spatial Relationship Description`、`tile_boundaries_measured_in_mbs_flag`）补入权利要求。

* *检索关键词*：`Tile`, `Spatial Relationship Description`, `SRD`, `MPEG-DASH`, `OMAF`, `Equirectangular`, `HEVC Tile`, `Motion-constrained tile sets`, `MCTS`.

* *分类号结合*：`H04N21/2343`, `H04N21/845`, `H04N19/167`, `H04N19/174`.

2. **针对 Guard Band（保护带）与动态视口预测机制检索**：

* *背景理由*：若专利权人强调ROI不仅仅是当前视口，还包含基于用户头追（Head Tracking）预测的下一帧区域或非对称保护带。

* *检索方向*：检索包含“Viewport prediction”、“Head tracking”、“Asymmetrical guard band”、“FOV (Field of View) adaptive streaming”的早期文献（2000-2012年间）。

3. **检索逻辑关系式**：

`((panoramic OR 360-degree OR VR OR "region of interest" OR ROI OR viewport) AND (tile OR slice OR "sub-picture") AND (streaming OR DASH OR HTTP) AND (overlap OR intersect OR position))`

---

如需要进一步针对从属权利要求进行逐项拆解或撰写正式的《专利无效宣告请求书》，请随时告知！

作为一名专利代理师，在处理专利无效宣告或侵权比对业务时，对权利要求的解释及对比文件的比对必须做到**严格对应、言必有据、逻辑严密**。

下面我将紧密结合目标专利权利要求，对对比文件进行逐一分析、特征比对、接近对比文件判定、最薄弱特征定位及后续检索策略制定。

---

### 一、 权利要求特征分解与解释

目标专利权利要求1涉及一种用于向客户端设备提供瓦片视频流的方法（支持ROI交互显示与预取）。其技术特征分解及解释如下：

* **技术特征A**：`一种用于向客户端设备提供一个或多个瓦片视频流的方法，所述一个或多个瓦片视频流能够用于在显示器上再现感兴趣的区域ROI`

* *解释*：限定了应用场景为瓦片（Tile/Slice）化的视频流传输，且该视频流用于在客户端展示ROI。

* **技术特征B**：`所述感兴趣的区域在与源视频关联的图像区域内限定子区域`

* *解释*：ROI是整幅全高清/源视频图像中的一部分（局部空间区域）。

* **技术特征C**：`接收感兴趣的区域ROI视频流以用于再现第一ROI`

* *解释*：客户端/服务端接收/处理用于展示当前或特定时刻的第一个ROI流。

* **技术特征D**：`所述第一ROI在与所述源视频关联的图像区域内限定第一子区域`

* *解释*：第一ROI对应源视频图像中的第一个具体局部位置。

* **技术特征E**：`提供与所述客户端设备所接收的所述ROI视频流的至少一个视频帧关联的ROI位置信息`

* *解释*：传输/提供随视频帧关联的ROI坐标/位置元数据（Metadata）。

* **技术特征F**：`所述ROI位置信息包括所述图像区域内的所述第一子区域的至少一个第一位置`

* *解释*：位置元数据具体包含第一子区域（x, y等）坐标。

* **技术特征G**：`使用所述ROI位置信息和瓦片位置信息用于确定与一个或多个瓦片子区域关联的一个或多个瓦片视频流`

* *解释*：核心逻辑——根据ROI的位置与视频中预先/既定的瓦片（Tile/Precinct/Slice Group）位置进行比对/重叠计算，从而确定需要哪些瓦片流。

* **技术特征H**：`所述一个或多个瓦片子区域的至少部分与所述第一子区域重叠`

* *解释*：确定的瓦片与ROI在空间上存在重叠关系（包含、相交或覆盖）。

* **技术特征I**：`所述瓦片位置信息包括所述图像区域内的所述一个或多个瓦片子区域的位置`

* *解释*：系统掌握/维护着各个瓦片子区域在整幅图像中的空间坐标分布信息。

* **技术特征J**：`请求所述一个或多个瓦片视频流`

* *解释*：客户端向服务端（或网络节点）发起对确定出的重叠瓦片视频流的传输请求。

---

### 二、 对比文件原文比对与公开性分析

**对比文件清单：**

1. **D1**：`FR2884027A1` (法国专利申请，公开日2006-10-06)

2. **D2**：`US20060262345A1` (美国专利申请，公开日2006-11-23，系D1的同族专利)

3. **D3**：`US20090300692A1` (美国专利申请，公开日2009-12-03)

---

#### 1. D1与D2的公开性分析 (FR2884027A1 / US20060262345A1)

*注：D1与D2为同族，技术方案完全一致。下文以D2（US20060262345A1）为例进行出处标注（亦可对应D1相同章节）。*

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

* *出处*：D2 段落 `[0001]`, `[0004]`, `[0008]`, `[0027]`, `[0034]`, `[0100]`, `[0101]`。

* *分析*：D2公开了在Motion-JPEG2000或H.264/SVC标准下，用户选择显示窗口（Viewing window F）或跟踪区域（Tracked area Z/Zone to be followed）。Z限定了源视频中的子区域。服务端在元数据（metadata-bin）中向客户端返回新确定区域的位置信息（`x, y, w, h`）。上述特征被**毫无异议地完全公开**。

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

* *出处*：D2 段落 `[0063]`, `[0103]`, `[0139]`, `[0140]`。

* *分析*：

* **Motion-JPEG2000实施例**：D2段落 `[0063]` 提到图像被划分为矩形空间区域（Precincts/Codeblocks）；段落 `[0103]` 提到客户端可根据接收到的基本编码实体（Precincts）索引来推算/确定新区域的坐标。

* **H.264/SVC实施例**：D2段落 `[0140]` 明确记载：“...a fixed grid of slice groups may be predefined. Next, the 'Z' window may be projected on the predefined grid of slice groups and only slices corresponding to the slice groups intersecting the determined spatial area are transmitted.”（预定义固定 Slice Group 网格，将 Z 窗口投影到该固定网格上，仅传输与确定的空间区域相交的 Slice Group）。

* *结论*：D2段落 `[0140]` **实质公开（完全对等公开）**了利用ROI位置（Z窗口）与瓦片/Slice位置（Fixed grid）进行比对/重叠相交计算，从而确定重叠Slice/Tile流的过程（特征G、H、I）。

* **技术特征J**：

* *出处*：D2 段落 `[0082]`, `[0111]-[0117]`。

* *分析*：客户端通过JPIP协议发送HTTP GET请求（包含`tracking=n`等参数）来请求对应的图像数据流。**毫无异议地公开**。

---

#### 2. D3的公开性分析 (US20090300692A1)

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

* *出处*：D3 段落 `[0038]`, `[0039]`, `[0070]`, 图1（ROI 106、Overview 102）。

* *分析*：D3公开了在高清视频流传输中，客户端通过图形界面选择感兴趣区域（ROI），ROI限定了源视频的局部子区域，客户端接收并显示该高分辨率ROI视频流。**毫无异议地公开**。

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

* *出处*：D3 段落 `[0040]`, `[0051]`, `[0118]`。

* *分析*：客户端将ROI的位置/坐标/缩放因子实时提供给服务端或预取模块（`pt=(xt, yt)`）。**毫无异议地公开**。

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

* *出处*：D3 段落 `[0069]`, `[0070]`, `[0083]`, `[0084]`, 图6, 图7。

* *分析*：D3段落 `[0069]`, `[0070]` 及图6、图7明确记载：高分辨率视频被划分成独立的P slices网格（Grid），根据ROI在网格上的位置（Location of the ROI），确定包含/覆盖该ROI的具体Slices组合（“shaded pixels in FIG. 7 show the pixel overhead for the shown slice grid and location of the ROI”）。**毫无异议地完全公开**了特征G、H、I。

* **技术特征J**：

* *出处*：D3 段落 `[0070]`, `[0112]`, `[0120]`。

* *分析*：客户端根据确定的Slice，向服务端或P2P节点/DSP请求订阅并接收对应的Slice数据流。**毫无异议地公开**。

---

### 三、 特征比对表格 (Claim 1 Comparison Matrix)

---

### 四、 创造性分析：最接近对比文件的判定

在专利无效宣告程序中，选择最接近的对比文件（Closest Prior Art）应遵循“技术领域相同或最接近、所要解决的技术问题最相似、公开的技术特征最多”的原则。

本案中，**D2 (`US20060262345A1`) / D1 (`FR2884027A1`)** 与 **D3 (`US20090300692A1`)** **均可独立作为最接近的对比文件**（最接近对比文件可以有多个）。

#### 1. 以 D2 (或D1) 作为最接近对比文件

* **整体解决的技术问题**：解决客户端在高清/大图视频浏览时，仅传输与用户关注的移动/指定ROI区域相对应的局部编码数据，以节省网络传输带宽并降低传输延迟（参见D2 `[0005]`, `[0015]`）。

* **技术效果**：在不进行全图重编码的前提下，准确且低带宽地满足客户端对动态ROI流的交互式实时传输。

* **公开度评价**：D2在`[0140]`段落明确记载了预定义固定Slice Group网格，将ROI（Z窗口）投影到网格上，并仅传输与ROI相交的Slice Group。这一逻辑与权利要求1的特征A~J形成了**1对1的全面覆盖**（读入）。

#### 2. 以 D3 作为最接近对比文件

* **整体解决的技术问题**：解决有限显示分辨率或有限带宽条件下，高空间分辨率视频向客户端传输时带宽浪费及ROI动态变化时的显示延迟问题（参见D3 `[0002]-[0004]`）。

* **技术效果**：通过Slice划分与预取（Pre-fetching），实现流媒体传输中的虚拟Pan/Tilt/Zoom（云台/缩放）交互，并优化Slice尺寸以最小化传输码率。

* **公开度评价**：D3的图6、图7及段落`[0069]-[0070]`, `[0083]`非常直观地展现了利用ROI位置在Slice Grid中寻找重叠/覆盖Slices并进行请求传输的全过程，**亦实现了权利要求1全特征的完全覆盖**。

#### 3. 小结

权利要求1的技术方案已被 **D2 (或D1)** 独立完全公开（新颖性破坏），同时也已被 **D3** 独立完全公开（新颖性破坏）。即使目标专利在细微撰写上试图强调“利用位置元数据与瓦片位置比对来确定流”，D2和D3也均已明确记载了该比对逻辑。因此，权利要求1**缺乏新颖性（A22.2）**，退一步讲也显然**不具备创造性（A22.3）**。

---

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

针对权利要求1及潜在的从属权利要求，分析其在无效程序中最容易被专利权人拿来作为防线、或在比对中最易产生争议的**“最薄弱环节”**：

1. **“利用ROI位置信息与瓦片位置信息进行重叠确定”（特征G、H、I）**：

* *潜在争议点*：专利权人可能会辩称，传统技术是客户端直接框选像素坐标，服务端盲目裁剪；而本专利强调了存在独立的“瓦片位置信息（Tile location information）”与“ROI位置信息”在空间上的**坐标匹配/相交计算**过程。

* *攻破要害*：

* D2 `[0140]` 明确给出了“projection on the predefined grid of slice groups... intersecting the determined spatial area”（投影至预定义Slice组网格，判定相交）。

* D3 `[0070]`, `[0083]` 明确给出了根据ROI在Slice Grid上的投影关系计算Overhead及选取对应Slice的算法。

* 因此，此防线可被直接击破。

2. **从属权利要求可能存在的薄弱点（预判防线）**：

* 若目标专利的**从属权利要求**进一步限定了“ROI位置信息的具体信令格式（如特定JPIP Header/Metadata Box结构）”、“基于运动预测（Kalman/ARMA）预判下一帧ROI位置再进行瓦片确定”，或者“利用P2P/多播节点获取瓦片流”。

* *评价*：主权1本身非常宽泛，极易被直接无效；专利权人后续势必会通过合并从属权利要求（例如：具体的运动预测预取、特定Slice尺寸优化算法）来收缩保护范围。

---

### 六、 进一步的对比文件检索策略（针对从属权利要求及防线固化）

为了确保彻底无效掉目标专利（包含其可能修改或收缩的所有从属权利要求），建议采取以下进一步的对比文件检索策略：

#### 1. 扩充检索要素表达（Key Terms & IPC/CPC）

* **核心概念词**：

* *Tile/Slice/Precinct*: Tile, Slice, Precinct, Spatial sub-part, Slice group, FMO (Flexible Macroblock Ordering), Codeblock.

* *ROI/View*: Region of Interest, ROI, Viewing window, Viewport, Pan-Tilt-Zoom, PTZ, Cropped view.

* *Position Matching*: Overlap, Intersect, Grid, Map, Projection, Coordinates, Metadata.

* *Streaming/Protocol*: JPIP, DASH, SRD (Spatial Relationship Description), H.264/SVC, HEVC/Tile.

* **分类号 (IPC/CPC)**：

* `H04N 19/167`（涉及感兴趣区域ROI的视频编码）

* `H04N 19/174`（涉及Slice/Slice Group的视频编码）

* `H04N 19/177` / `H04N 19/30`（可伸缩视频编码/分层编码）

* `H04N 21/2343` / `H04N 21/4728`（基于客户端选择的局部区域流传输/交互式视频流）

#### 2. 针对性追踪与交叉检索

1. **MPEG-DASH SRD (Spatial Relationship Description) 标准追溯**：

* 检索2010~2014年前后关于 MPEG-DASH SRD（空间关系描述）的标准提案（3GPP / ISO/IEC JTC1/SC29/WG11）。DASH SRD 机制正是通过在 MPD 拟定瓦片的 `spatial_relationship_description` 元数据，客户端比对 ROI 坐标与 Tile 坐标来请求对应的 Segment/Tile 视频流。

2. **重点申请人/学术团队追踪**：

* 追踪 **Siemens**, **Canon** (D1/D2的原始申请人，在JPIP和Motion-JPEG2000领域有大量基础专利), **Stanford University / Bernd Girod 实验室**（D3的作者团队，在 Interactive Video Streaming / ROI Pre-fetching 领域发表了大量顶会论文及专利）。

* 检索 Bernd Girod 团队在 2005-2008 年间关于 "Interactive streaming of high-resolution video"、"ROI prediction"、"Slice size optimization" 的 IEEE 论文（论文公开日早于专利申请日时可作为非专利文献/NPL依据）。

3. **防范“运动预测预取”从属权利要求的对抗检索**：

* 针对“根据历史轨迹预测未来帧ROI位置并提前请求Tile”的技术点，重点检索组合关键词：`("ROI prediction" OR "trajectory prediction" OR "Kalman" OR "ARMA") AND ("tile" OR "slice") AND "streaming"`。

作为资深专利代理师，我针对目标专利《权利要求1.docx》与三篇对比文件进行系统的专利无效分析与特征比对。

---

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

根据说明书含义，对权利要求1的技术特征拆解及解释如下：

* **特征A**：*一种用于向客户端设备提供一个或多个瓦片视频流的方法，所述一个或多个瓦片视频流能够用于在显示器上再现感兴趣的区域ROI*

* **解释**：该特征限定了方法的目标与应用场景，即客户端通过请求并接收一个或多条以“瓦片（Tile）”为单位划分的视频流，在显示终端上重建/显示指定的感兴趣区域（ROI）。

* **特征B**：*所述感兴趣的区域在与源视频关联的图像区域内限定子区域*

* **解释**：ROI是整幅源视频图像画面中的一部分（局部子区域）。

* **特征C**：*接收感兴趣的区域ROI视频流以用于再现第一ROI*

* **解释**：客户端当前正在接收或已经接收到了用于再现当前第一ROI的视频流。

* **特征D**：*所述第一ROI在与所述源视频关联的图像区域内限定第一子区域*

* **解释**：第一ROI对应于源视频画面中的第一局部子区域。

* **特征E**：*提供与所述客户端设备所接收的所述ROI视频流的至少一个视频帧关联的ROI位置信息*

* **解释**：获得/提供与接收到的ROI视频流中至少一帧画面绑定的ROI位置数据（如坐标、宽高、SEI消息或MPD元数据中的位置字段）。

* **特征F**：*所述ROI位置信息包括所述图像区域内的所述第一子区域的至少一个第一位置*

* **解释**：位置信息中具体包含了第一子区域在整幅源视频坐标系中的空间位置（如左上角坐标 $x, y$ 等）。

* **特征G**：*使用所述ROI位置信息和瓦片位置信息用于确定与一个或多个瓦片子区域关联的一个或多个瓦片视频流*

* **解释**：核心逻辑步骤——结合已知的“第一ROI位置”与视频系统中预先/系统定义的“各瓦片（Tile）在源视频中的空间位置信息”，通过空间重叠或映射计算，挑选出需要获取的瓦片视频流。

* **特征H**：*所述一个或多个瓦片子区域的至少部分与所述第一子区域重叠*

* **解释**：被选中的瓦片在空间上必须与第一子区域有交集（重叠），从而保证瓦片能够覆盖第一ROI的内容。

* **特征I**：*所述瓦片位置信息包括所述图像区域内的所述一个或多个瓦片子区域的位置*

* **解释**：系统掌握或元数据中包含了各个瓦片子区域在整幅源视频中的坐标或位置界限。

* **特征J**：*以及；请求所述一个或多个瓦片视频流*

* **解释**：客户端向服务器发起对上述确定的一个或多个瓦片视频流的网络请求（如HTTP请求）。

---

### 二、 对比文件原文详细出处与特征比对表格

为了便于分析，对三篇对比文件进行编号并附上公开号：

* **D1**：CN101690228A（视频编索引方法和视频编索引设备）

* **D2**：US20100232504A1（Supporting region-of-interest cropping through constrained compression）

* **D3**：JPWO2015008774A1 / WO2015008774A1（情報処理装置および方法）

#### 特征比对表格

---

### 三、 对比文件公开内容的详细分析

#### 1. D1（CN101690228A）

* **出处**：说明书第[0010]-[0027]段、第[0074]-[0076]段（表1、表2）、第[0098]-[0100]段。

* **公开情况分析**：

* **毫无疑问公开了**：技术特征 B、C、D、E、F、I。D1公开了在H.264/AVC标准下，利用SEI（补充增强信息）消息传输视频帧中ROI的位置坐标（`roi_x_16`, `roi_y_16`）及宽高（[0076]表2），并在解码端根据SEI消息提取ROI区域进行放大切换或仅对包含ROI的片组（Slice group）进行解码（[0027]、[0098]）。

* **未公开/区别**：D1未公开DASH流式传输架构下的“瓦片视频流（Tile Stream）”概念，其主要是基于单条码流内部的FMO（灵活宏块排序）或片组选择解码，且未明确“客户端发起瓦片流请求（特征J）”。

#### 2. D2（US20100232504A1）

* **出处**：说明书第[0013]段、第[0021]段、第[0029]-[0033]段、图3B、图4。

* **公开情况分析**：

* **毫无疑问公开/实质公开了**：技术特征 A、B、C、D、E、F、G、H、I。D2明确提出了将高分辨率视频划分成虚拟瓦片（Virtual Tiles，段[0013]、[0021]），每个Tile包含 $N \times M$ 个宏块。在提取ROI时，“识别覆盖该ROI的最小瓦片组（smallest group of tiles covering the ROI is identified, extracted, and made into a video stream）”（段[0029]），且这些瓦片与ROI相交重叠（段[0030]）。

* **未公开/区别**：D2侧重于压缩域内的码流切片剪裁与提取（从主码流剥离非ROI Slice），未显式采用DASH客户端-服务器架构发起单独瓦片流的“网络请求（特征J）”。

#### 3. D3（JPWO2015008774A1 / WO2015008774A1）

* **出处**：说明书第[0042]-[0050]段、第[0068]-[0076]段、第[0100]-[0128]段、第[0221]-[0229]段、图10、图11-13。

* **公开情况分析**：

* **毫无疑问公开了**：技术特征 A、B、C、D、E、F、G、H、I、J（全特征全面覆盖）。

* **详细对开映射**：

* D3属于MPEG-DASH SRD（Spatial Relationship Description）背景的技术。它公开了将全体图像划分为Tile，针对每个Tile生成独立或关联的视频流（段[0050]-[0052]）。

* 在MPD（媒体呈现描述元数据）中，通过`Viewpoint`或`SupplementalProperty`/`EssentialProperty`扩展定义了部分图像/Tile的位置信息（包含 $x, y$ 坐标、$width, height$ 以及全体图像尺寸，段[0068]-[0070]、[0259]-[0261]）。

* 终端（客户端）获取MPD后（特征E、F、I），根据用户指定的显示区域/ROI，结合MPD中各Tile的位置坐标，计算并选择重叠的Tile视频流（特征G、H，段[0118]-[0120]、[0228]-[0229]），并通过HTTP协议向服务器请求对应的Tile视频流Segment（特征J、A，段[0044]、[0101]-[0103]）。

---

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

在专利无效宣告中，选择最接近的对比文件需考量**技术领域、解决的技术问题、技术效果及公开特征的数量**：

#### 核心推荐：D3（JPWO2015008774A1）作为第一最接近对比文件

1. **技术领域与架构完全重合**：目标专利与D3均属于**网络视频流式传输（基于DASH/HTTP）中基于Tile/ROI的切片传输与动态再现**领域。

2. **解决的技术问题完全一致**：两者均致力于解决“如何在客户端设备（尤其是显示能力或带宽有限的终端）上，根据用户指定的ROI，高效、动态地挑选并请求对应的Tile视频流，避免传输冗余全图数据”的问题。

3. **技术效果一致**：实现了客户端自适应选择局部Tile流，降低网络带宽消耗与终端解码负载。

4. **特征覆盖度**：**D3公开了权利要求1的全部技术特征（A-J）**。即使在细节理解上产生争议，D3也公开了权利要求1绝大部分的结构和步骤。因此，**D3是无可争议的最接近对比文件**。

#### 备选/辅助对比文件：D2（US20100232504A1）

* 如果将分析视角放在“视频编码内部Tile划分与ROI重叠映射算法”本身，D2也极其接近。D2解决了“利用约束运动估计的Virtual Tile实现高效ROI裁剪”的问题。但因其缺少DASH客户端网络请求（特征J）的上下文，在技术架构上略逊于D3，适合作为与D3结合的第二对比文件（D3+D2）。

---

### 五、 薄弱技术特征与专利无效策略

#### 1. 权利要求1中最薄弱的技术特征

权利要求1的整体方案属于典型的高级协议层/应用层逻辑整合。其最薄弱的技术特征在于：

* **特征G与特征H（动态映射逻辑）**：即“利用ROI位置信息和瓦片位置信息比较重叠，进而确定并请求重叠瓦片流”。

* **薄弱原因**：在Tile化视频传输体系（如MPEG-DASH SRD标准制定期间）中，只要元数据中给出了Tile的空间坐标（$x, y, w, h$），客户端将目标ROI的坐标与Tile坐标进行简单的空间交集（Overlapping）判断，属于**本领域技术人员的公知常识或显而易见的逻辑推理**。该特征缺乏深度的算法创新，极易被常规逻辑否定创造性。

#### 2. 无效请求策略与检索建议

如果针对目标专利提起无效宣告请求，建议采取以下组合策略：

##### 策略一：基于 D3 的单篇新颖性（A22.2）或创造性（A22.3）破坏

* **主攻方向**：主张D3已经完整公开了权利要求1的特征A-J。

* **论证要点**：D3中的DASH客户端在接收到用户对特定区域（ROI）的显示指令后，读取MPD中的Tile坐标（`urn:mpeg:dash:srd:2013` / `urn:mpeg:DASH:tile:2013`），计算坐标重叠，并向服务器发起该Tile Segment的HTTP Request。这与权利要求1完全逐字对应。

##### 策略二：基于 D3 + D2（或结合本领域公知常识）的创造性破坏（A22.3）

* 若专利权人辩称其“第一ROI”与“瓦片”存在动态连续切换（如先看ROI1，再根据ROI1位置拉取瓦片），可引入D2：

* D2公开了动态移动ROI时，实时计算与ROI相交的瓦片组（Intersecting Tiles）并提取码流（D2段[0030]、[0033]）。

* 将D2的重叠瓦片提取算法结合到D3的DASH流式传输系统属于本领域的常规技术结合。

##### 策略三：进一步对比文件检索策略（补充检索建议）

若需要进一步扩充对比文件证据链（例如针对其可能划入独立权利要求的从属权利要求），建议采取以下检索策略：

1. **标准草案与提案检索（极其有效）**：

* **目标标准**：MPEG-DASH SRD (Spatial Relationship Description, ISO/IEC 23009-1 AMD 2) 以及 3GPP TS 26.247。

* **检索关键词**：`DASH`, `SRD`, `Spatial Relationship Description`, `Tile`, `ROI`, `Region of Interest`, `MPD`, `SupplementalProperty`.

* **时间节点**：重点检索目标专利**优先权日之前**的MPEG会议提案（m31518, m31519 等关于Tile/ROI流式传输的Input Documents）。

2. **专利数据库检索要素表达**：

* **IPC/CPC分类号**：`H04N21/4728`（基于ROI的选择/显示）、`H04N21/845`（流分段/Chunking）、`H04N19/167`（基于ROI的视频编码）。

* **检索式组合**：`(DASH OR "dynamic adaptive streaming") AND (tile OR "slice group") AND (ROI OR "region of interest") AND (overlap* OR intersect* OR map*)`.

这一需求是典型的**专利无效宣告请求（Invalidation Request）**中的对比文件检索与技术特征对比分析。作为一名经验丰富的专利代理师，我将严格依据中国专利法（及国际通行专利审查标准），结合目标专利（权利要求1）与三份对比文件（D1、D2、D3）的原文文本，为您进行深度的技术特征比对、创造性分析、最接近对比文件选择、薄弱特征识别以及后续检索策略制定。

---

## 一、 对比文件基本信息及代号定义

为了分析的严谨性与规范性，在下文中对三份对比文件作如下代号映射及规范指代：

* **对比文件1（D1）**：`US 2006/0120610 A1`，公开日：2006年6月8日，名称：《Image transcoding》。

* **对比文件2（D2）**：`WO 2008/088772 A2`，公开日：2008年7月24日，名称：《MPEG OBJECTS AND SYSTEMS AND METHODS FOR USING MPEG OBJECTS》。

* **对比文件3（D3）**：`WO 2009/003885 A2`，公开日：2009年1月8日，名称：《VIDEO INDEXING METHOD, AND VIDEO INDEXING DEVICE》。

---

## 二、 目标专利权利要求1特征分解与对比文件逐项比对（表格式分析）

下表详细列出了权利要求1拆解出的技术特征A~J，并在D1、D2、D3中寻找原文依据，明确指出是**“毫无异议公开（即明确记载/实质公开）”**还是**“未公开”**。

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

---

## 三、 整体技术问题、技术效果分析与最接近对比文件（D1/D2/D3）的选择

### 1. 本专利解决的技术问题及技术效果

* **技术问题**：在向客户端设备传输及再现视频时，如何基于用户动态关注的感兴趣区域（ROI），高效定位、切分并请求与ROI重叠的局部瓦片视频流（Tile-based Video Streams），以节省传输带宽和计算资源。

* **技术效果**：通过ROI位置信息与预设瓦片（Tile）位置信息的匹配，精准请求重叠的瓦片视频流，减少不必要的背景或非ROI数据传输，降低客户端解码开销。

### 2. 三份对比文件的技术领域与核心构思分析

* **对比文件1（D1, US20060120610A1）**：

* **核心构思**：基于JPEG 2000标准的转码技术。利用小区域/专区（Precinct）结构，根据解码端动态提供的ROI坐标（坐标向外向上取整至最近 precinct 边界），直接抽取ROI对应的Precinct数据包，剔除或降低背景数据包质量。

* **技术问题/效果**：解决实时视频传输中动态ROI转码复杂度高的问题，避免重新编码包头，降低计算量与带宽需求。

* **对比文件2（D2, WO2008088772A2）**：

* **核心构思**：基于MPEG对象的交互式视频系统。利用Active Video Markup Language (AVML)定义帧布局（Layout），将包含ROI的MPEG Element/Slice（切片）在宏块/切片边界上进行缝合（Stitching）和组合，客户端向服务端发送请求，服务端组合对应的Slice流并传输。

* **技术问题/效果**：解决低算力终端（如机顶盒）无法实时解码组合复杂交互画面问题，避免全帧解码和重新编码。

* **对比文件3（D3, WO2009003885A2）**：

* **核心构思**：基于H.264/AVC标准的视频索引与ROI解码。利用灵活宏块顺序（FMO）将ROI编码为独立的切片组（Slice Groups），并在SEI（辅助增强信息）消息中携带ROI位置与Slice Group的映射关系，终端仅选择解码ROI对应的Slice Group。

* **技术问题/效果**：解决低显示能力移动终端传输和显示高密度视频图像的问题，节省解码资源。

### 3. 最接近对比文件的判定

在专利创造性审查中，“最接近的对比文件”通常应是**技术领域最相近、所要解决的技术问题最相似、公开技术特征最多**的现有技术。

经过综合评判，**本案存在两个均极其适合作为“最接近对比文件”的选项（主攻方向）**：

#### 最佳选择一：对比文件1 (D1 - US20060120610A1)

* **理由**：D1与本专利的技术构思最为契合。D1明确提出了**“解码端/动态提供ROI坐标” $\rightarrow$ “将ROI坐标向上对齐到Precinct（即图像切块/瓦片）边界” $\rightarrow$ “仅提取/请求与ROI重叠的Precinct包”**的完整技术路径。D1中的 Precinct 逻辑与本专利中的“瓦片（Tile）”在空间切分和流提取逻辑上几乎完全一致。

#### 最佳选择二：对比文件2 (D2 - WO2008088772A2)

* **理由**：D2在**网络架构与客户端-服务端交互（请求-响应机制）**上与本专利最为贴近。D2完整公开了客户端发起请求（Request）、服务端依据AVML布局文件中的位置信息（Pos x, y）和Slice/Macroblock切片边界，提取并 Stitch（缝合/组合）对应的独立Slice流提供给客户端。

*(注：D3亦可作为备选最接近对比文件，其公开了将ROI与H.264的Slice Group结合，并仅请求/解码特定Slice Group的思想。)*

---

## 四、 审查指南视角下的创造性攻击路线与最薄弱技术特征分析

### 1. 最薄弱的技术特征（弱点分析）

在无效宣告请求中，本专利权利要求1相对上述对比文件而言，**最薄弱的技术特征是：“瓦片视频流（Tiled Video Stream）”这一术语及“瓦片子区域（Tile sub-region）”的明确定义**。

* **薄弱原因**：

1. D1使用的是 JPEG 2000 的 **Precinct（专区/小块包）**；

2. D2使用的是 MPEG 的 **Slice / Macroblock（切片/宏块）**；

3. D3使用的是 H.264 的 **Slice Group / FMO（切片组）**。

* 专利权人极可能会在无效答辩中辩称：“对比文件公开的 Precinct 或 Slice 只是传统视频编码中的语法单元或空间切分，并不等同于独立的‘瓦片视频流（Tiled Video Stream）’”。

### 2. 无效宣告的创造性攻击路线（结合《专利审查指南》突围）

为了克服上述“术语差异”，应采用**“领域常识组合/等同替换”**策略进行攻击：

#### 攻击路线甲：以 D1 为最接近对比文件 + 本领域普通技术人员的公知常识（或 D2/D3）

* **论点**：

1. D1已经公开了权利要求1绝大部分技术特征，包括：接收ROI视频流、获取ROI位置信息、将ROI坐标与 Precinct（瓦片/小区块）边界对齐/重叠（特征H）、提取并请求对应的 Precinct 数据包流（特征G、J）。

2. D1中的 Precinct 实际上就是对图像空间区域进行网格化分割的子区域（即瓦片子区域）。

3. 将JPEG 2000中的 Precinct 或常规视频编码中的图像切块（Tiles，如HEVC Tile技术）作为“瓦片视频流”传输，属于本领域技术人员在面对“如何对图像进行空间切分并独立传输”这一技术问题时，结合本领域公知常识或D2/D3中的切片流（Slice Stream）技术手段显而易见能够得出的技术方案，不具备创造性。

#### 攻击路线乙：以 D2 为最接近对比文件 + D1/D3

* **论点**：

1. D2公开了客户端请求包含ROI的对象，服务端利用布局文件中的位置信息（特征E、F）和切片位置信息（特征I），确定与该ROI重叠的MPEG Slice/宏块流（特征G、H），并向客户端请求和传输该流（特征C、J）。

2. D2中的 Slice/Block 与本专利的 Tile 仅为对图像空间切分不同命名方式。结合 D1 中明确教导的“将ROI坐标向上对齐到最近的空间切分块边界（rounds ROI coordinates outward to nearest precinct boundaries）”，本领域技术人员无需付出创造性劳动即可导出权利要求1的技术方案。

---

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

为了在无效宣告程序中彻底“击穿”专利权人关于“瓦片（Tile / Tiled Video）”的技术壁垒，建议按照以下策略展开补充检索：

### 1. 核心检索要素（Key Concepts）拆解

* **要素一（瓦片/空间切分）**：Tile, Tiling, Tiled Video, Precinct, Sub-picture, Spatial Segment, Spatial Partition, Slice Group, FMO.

* **要素二（感兴趣区域）**：ROI, Region of Interest, Attention Area, Salience Map, Focus Area.

* **要素三（流请求/选择性传输）**：Stream, Bitstream, Transcoding, Request, Fetch, Overlap, Mapping, Alignment, Coordinates, Selective Transmission.

### 2. 检索式构造建议（以IPC分类号与关键词结合）

#### (1) 专利数据库（EPO / USPTO / CNIPA / Google Patents）检索

* **IPC/CPC分类号组合**：

* `H04N 19/167`（与ROI/感兴趣区域相关的视频编码）

* `H04N 19/174` / `H04N 19/176`（基于Slice或Block/Tile的视频编码）

* `H04N 21/2343` / `H04N 21/472`（服务端/客户端交互式视频流传输）

* **逻辑检索式示例**：

* `((H04N19/167 OR H04N19/174 OR H04N19/176) AND (tile OR tiled OR precinct OR "slice group") AND ("region of interest" OR ROI) AND (overlap OR align* OR mapping))`

* `((video OR image) NEAR3 (tile OR tiled OR segment)) AND ("region of interest" OR ROI) AND (request* OR fetch* OR select*) AND (stream* OR bitstream)`

#### (2) 标准文献与非专利文献（NPL）重点检索

由于“瓦片视频（Tiled Video / Tile-based streaming）”在全景视频（Omnidirectional/360 Video）及 DASH 动态自适应流媒体标准中极其常见，建议重点检索：

1. **3GPP / MPEG 标准提案（Standard Contributions）**：

* 检索 **ISO/IEC 23009 (DASH)** 标准中关于 *SRD (Spatial Relationship Description)* 的提案（约2014-2015年及更早技术）。

* 检索 **ISO/IEC 23008-2 (HEVC / H.265)** 中关于 *Tile* 划分为独立可解码视频流的提案。

2. **学术数据库（IEEE Xplore, ACM Digital Library）**：

* 关键词组合：`"Tiled video streaming" AND "Region of interest"` 或 `"Tile-based" AND ROI AND streaming`.

* 重点关注 2005年–2012 年间关于“交互式ROI视频流（Interactive ROI Video Streaming）”和“网络视频瓦片化切片（Video Tiling over HTTP/RTSP）”的经典论文。

### 3. 补充检索的目标与期望结果

直接寻找到**明确使用“Tile / Tiled Video Stream”术语**，且记载了**“客户端发送ROI坐标/位置 $\rightarrow$ 服务端将ROI映射至重叠的 Tile 瓦片 $\rightarrow$ 仅传输/请求重叠 Tile 视频流”**的优先权日之前（即2009-2012年或更早，视目标专利申请日而定）的现有技术文献，作为对比文件D4，直接对权利要求1实施新颖性（A22）或极强创造性（A23）毁灭性打击。

针对目标专利（权利要求1）与三份对比文件的技术比对、最接近对比文件选择、无效突破点以及检索策略，分析如下：

---

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

### 1. 说明书背景下的权利要求1解释

目标专利（权利要求1）保护一种在客户端设备上**基于ROI（感兴趣区域）位置与瓦片（Tile）位置重叠关系，向服务端/网络端请求并接收部分视频瓦片流**的方法。其核心逻辑在于：

* 客户端接收或确定第一ROI（对应图像内的第一子区域）。

* 结合ROI的位置信息与视频自身的瓦片分割位置信息（Tile Position），计算出哪些Tile与该第一ROI存在空间重叠。

* **仅针对重叠的Tile子区域发送瓦片视频流请求**，从而实现按需传输、节省带宽与解码资源。

---

### 2. 特征比对与出处分析

以 **D1** 指代 `EP2174500A2`；以 **D2** 指代 `US20100135575A1`；以 **D3** 指代 `JP2010532121A`（注：D1与D3本质上为同族专利，内容高度一致）。

#### 特征比对总表

---

### 3. 各对比文件对技术特征的详细公开性分析

#### 1) D1 (EP2174500A2)

* **公开的特征**：A, B, C, D, E, F, G, H, I。

* **详细原文出处与分析**：

* **特征 A, B, C, D**：D1说明书第3页第32-37行指出，接收终端（如PDA或手机）可以仅选择显示ROI区域（`choose to display the regions of interest only`），在图像内通过坐标（高度、宽度）确定其地理位置（`geographically located... identified by their coordinates according to height and width`）。

* **特征 E, F**：D1 Table 2公开了在SEI消息中携带ROI位置信息，包括 `roi_x_16`（X位置）、`roi_y_16`（Y位置）、`roi_w_16`（宽度）、`roi_h_16`（高度）。

* **特征 G, H, I**：D1在第5页第25-35行及Table 3-4公开了基于H.264/AVC的 **FMO（Flexible Macroblock Ordering，灵活宏块顺序）** 技术。图像被划分为多个 `slice groups`（切片组，对应本专利中的Tile/瓦片），PPS中包含 slice group 的映射图（即瓦片位置信息）；SEI消息指示哪些 slice group 对应ROI。解码端利用SEI中的ROI信息与 slice group 映射图，**仅解码包含ROI的slice group**（`decodes only the slice groups containing the region of interests`）。

* **未明确公开的特征**：**特征J**。D1主要描述的是“客户端接收到流后，仅选择解码和显示对应ROI的slice组”（本地过滤），或者由服务端推流，未明确提及“客户端主动向服务器/网络发送针对该特定Tile视频流的**请求（Request）**”。

#### 2) D2 (US20100135575A1)

* **公开的特征**：B, D（仅限图像处理中的ROI概念）。

* **详细原文出处与分析**：

* D2主要关注图像去伪影（Banding Artifact Removal）。在段落[0009]与[0032]-[0033]中提到了对图像分割出平滑区域/ROI（`region of interest based approach`），并建模为 `I(x,y)=ax+by+c` 进行滤镜处理。

* **未公开特征**：D2完全未涉及视频流传输、Tile瓦片切分、客户端/服务端交互以及基于位置信息的Tile流请求（缺少A, C, E, F, G, H, I, J）。

#### 3) D3 (JP2010532121A)

* **公开的特征**：A, B, C, D, E, F, G, H, I。

* **分析**：D3为D1的日本同族专利（同源于Thomson的PCT申请），技术方案与D1完全等同。段落[0021]及附表1-4公开了与D1一致的SEI消息传输ROI坐标以及利用FMO Slice Group进行选择性解码的技术方案。

---

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

### 1. 最接近对比文件的确定

**最接近对比文件为：D1 (EP2174500A2) [或其同族 D3 (JP2010532121A)]**。

* **理由分析**：

1. **技术领域一致**：D1/D3与目标专利均属于“带ROI信息的视频编码、传输与客户端再现”领域，特别针对带宽/显示能力有限的移动终端。

2. **解决的技术问题一致**：均致力于解决如何在显示大尺寸/高密度视频时，降低客户端解码负载与带宽消耗。

3. **技术方案重合度最高**：D1/D3已经公开了将图像区域划分为独立可解的子区域（FMO Slice Group，即Tile形态）、在SEI中传输ROI位置坐标、以及将ROI位置与Slice Group位置匹配后仅获取/解码重叠Slice Group的完整技术链路。

4. **排除D2**：D2仅为单帧图像滤镜去噪算法，与“瓦片视频流（Tile Streaming）与客户端请求”的技术问题及架构完全无关，不适合作为最接近对比文件。

### 2. 未被最接近对比文件（D1/D3）公开的特征及其他对比文件的补充

* **区别特征**：目标专利权利要求1相对于D1/D3的区别特征在于**特征J**（以及特征G中从“本地选择解码”延伸到“网络端请求”的拉取式架构）：**“请求所述一个或多个瓦片视频流”**（即客户端向服务端发起针对特定Tile流的下发请求）。

* **其他对比文件（D2）是否公开**：**否**。D2未公开任何关于视频流请求或Tile架构的内容。

---

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

若要针对目标专利权利要求1发起无效宣告请求，**最薄弱（最难以被直接攻破）的技术特征为：特征J（请求所述一个或多个瓦片视频流）结合特征G的客户端交互逻辑**。

### 难点分析：

1. **推模式（Push）与拉模式（Pull）的区别**：

* D1/D3采用的是标准的广播/推送流模式：服务端将完整视频流（包含所有Slice Group）或预定义的SEI流发给客户端，客户端在**本地解码器端**做选择性丢弃/解码（`decodes only the slice groups...`）。

* 目标专利权利要求1明确限定了**客户端驱动的“请求（Request）”机制**（即类似HTTP Dynamic Adaptive Streaming / DASH 中的 Tile-based streaming 机制，客户端计算出重叠Tile后，主动向服务器发起Get/Request请求）。

2. **术语映射风险**：虽然D1中的 FMO Slice Group 在技术实质上完全对应 Tile，但D1缺乏“客户端向服务端发送Tile级别请求”的明确动作描述。

---

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

为了成功无效权利要求1，必须补充检索能够体现 **“客户端确定ROI后，向服务端请求特定Tile/子区域视频流”**（Tile-based Dynamic Adaptive Streaming）的现有技术。建议采取以下检索策略：

### 1. 扩充检索的技术主题词与IPC分类号

* **核心概念组合**：`Tile Video Streaming` + `Region of Interest (ROI)` + `Client Request / Fetch` + `HTTP Adaptive Streaming / DASH`

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

* `H04N 21/2343`（服务端基于客户端需求或终端能力的流转换）

* `H04N 21/472`（客户端发起的内容请求/交互）

* `H04N 21/845`（视频流切片/瓦片化 Structuring of video streams, e.g., tiling, chunks）

* `H04N 19/167`（基于ROI的视频编码）

### 2. 关键检索逻辑表达式（以Patentics/Derwent/EPO格式为例）

```text

(Tile OR Tiled OR "Slice Group" OR "Sub-picture")

AND ("Region of Interest" OR ROI OR "interactive viewport")

AND (request* OR fetch* OR pull* OR demand*)

AND (stream* OR DASH OR HTTP)

```

### 3. 重点突破方向与标准文献检索

1. **追溯 DASH / MPEG-DASH 标准早期提案**：

* 关注 2010年—2014年 期间（目标专利申请日之前）关于 **MPEG-DASH SRD (Spatial Relationship Description)** 的标准提案（3GPP TS 26.247 或 ISO/IEC 23009-1 相关变体）。SRD 机制正是用于定义图像空间位置（Tile/ROI）并由客户端发起按需Tile请求的标准。

2. **重点申请人/公司检索**：

* 检索在全景视频（Omnidirectional / 360-degree video）、交互式超高清视频领域较早布局 Tile 传输的公司，例如：*InterDigital, Qualcomm, Nokia, Samsung, Technicolor, Fraunhofer*。

3. **结合D1进行“公知常识/显而易见性”结合结合（A+B结合）**：

* **D1 (EP2174500A2)** 提供“ROI与Tile/Slice Group位置重叠计算”的基础架构；

* 寻找一份**公开“客户端根据需要向服务器请求部分视频块/Tile”的通用DASH传输对比文件（D4）**。论证：将D1中的本地丢弃逻辑替换为D4中常见的客户端按需请求（以进一步节省下行传输带宽），属于本领域技术人员基于网络带宽优化动机作出的显而易见的技术改进（符合《专利审查指南》第二部分第四章关于创造性的规定）。

针对目标专利权利要求1，结合说明书进行解释，并对对比文件D1（US7894531B）、D2（US20110096990A1）和D3（JP2012049806A）进行比对分析。

---

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

权利要求1限定了一种在客户端（如播放器/终端）侧通过**位置匹配与重叠判断**，请求包含感兴趣区域（ROI）的“瓦片视频流（Tile Video Stream）”的方法：

1. **核心逻辑**：客户端先获取一个低分辨率/预览用的ROI视频流及第一ROI的位置（第一子区域）；同时掌握全图被切割成的各个瓦片（Tile）的位置；通过将第一子区域与各瓦片子区域进行空间重叠比对，精准筛选并请求包含第一ROI的瓦片视频流。

2. **关键技术特征划分**：

* **特征A~D**：接收第一ROI视频流，该ROI限定了源视频图像区域内的第一子区域。

* **特征E~F**：提供/获取与视频帧关联的ROI位置信息（第一位置）。

* **特征G~I**：基于ROI位置与瓦片位置，通过空间重叠计算确定需要请求的瓦片视频流。

* **特征J**：向服务端发送请求以获取所述瓦片视频流。

---

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

### 1. 对比文件基本信息

* **D1**：`US7894531B1` (*Method of compression for wide angle digital video*)

* **D2**：`US20110096990A1` (*Video Codec Method and System*)

* **D3**：`JP2012049806A` (*Information transmission and reception system and information transmission and reception method*)

### 2. 特征比对表格

---

### 3. 各对比文件原文详细出处与分析

#### 1) 对比文件 D1 (`US7894531B1`)

* **实质公开特征**：**特征B、D、E、F**

* **详细出处与分析**：

* **出处**：`[0015]` *"Automatic ROI estimation module passes the location of RoI, and the index of the DC only encoded block to the MPEG 1 video encoder for each image frame."* 及 `[0025]`。

* **分析**：D1公开了自动检测/手动设定ROI并在图像内限定子区域（特征B、D），同时将ROI的位置信息传递给编码器（特征E、F）。

* **未公开特征**：D1侧重于单流视频编码内部对ROI宏块与非ROI宏块的不同量化与矢量处理，**未公开基于瓦片（Tile）切割、空间重叠计算（特征G~I）以及请求瓦片流（特征A、J）**。

#### 2) 对比文件 D2 (`US20110096990A1`)

* **实质公开特征**：**特征A（部分）、B、C、D、E、F、J**

* **详细出处与分析**：

* **出处**：`[0011]` *"The encoder includes an ROI cropping module to crop the region of interest from the video image... An EL encoder module is employed to generate an enhancement layer bit stream by coding the cropped ROI image..."* 以及 `[0260]`。

* **分析**：D2公开了基于可伸缩视频编码（SVC），裁剪ROI区域并生成专门针对ROI的增强层（EL）视频流（公开了特征A、B、C、D）。同时公开了传输与接收ROI标识/位置信息（特征E、F）以及解码端接收/请求该码流（特征J）。

* **未公开特征**：D2采用的是**直接裁剪ROI（Cropping）**并编码为EL层，**未公开将图像预先切分为瓦片（Tiles），更未公开利用ROI位置与瓦片位置进行“空间重叠比对（Overlap）”来筛选瓦片视频流（特征G、H、I）**。

#### 3) 对比文件 D3 (`JP2012049806A`)

* **分析**：D3涉及一种利用电子水印传输分割图像的系统（出处：`[0007]`）。虽然D3将图像分割为多块（类似Tile），但其目的在于防止图像篡改与隐蔽传输，**不涉及视频ROI概念、瓦片视频流概念，也不存在基于ROI与瓦片重叠判断来选择性请求瓦片流的技术逻辑**。D3对本权利要求无实质影响。

---

## 三、 接近对比文件分析与创造性评估

### 1. 最接近的对比文件选择：D2 (`US20110096990A1`)

* **结论**：**D2 适合作为最接近的对比文件**。

* **原因**：

1. **技术领域**：D2 与目标专利均属于视频编解码与按需传输技术领域。

2. **解决的技术问题**：D2 与目标专利均致力于解决“在有限带宽下，如何高清晰度地向客户端传输并再现感兴趣区域（ROI）”的技术问题。

3. **技术特征覆盖度**：D2 公开了权利要求1中关于ROI视频流的接收、ROI子区域限定、位置信息传递以及选择性传输ROI码流的大部分特征（特征A、B、C、D、E、F、J）。

### 2. 区别技术特征与技术效果

与最接近的对比文件 D2 相比，权利要求1的区别技术特征在于：

> **区别特征（特征G、H、I）**：引入瓦片（Tile）架构，利用“ROI位置信息”与“瓦片位置信息”进行比对，确定与ROI至少部分重叠的一个或多个“瓦片子区域”，并据此确定和请求对应的瓦片视频流。

* **区别特征达到的技术效果**：

传统ROI裁剪传输（如D2）需要编码器针对每次变更的ROI动态裁剪并实时编码生成新的EL流，服务端计算负载极高且不利于标准缓存（CDN）。而目标专利通过预先将视频分割为固定的“瓦片流”，客户端仅需通过**空间重叠逻辑**判断并请求重叠的瓦片，**大幅降低了服务端的实时编码负担，提高了CDN缓存利用率及视频流调取的响应速度**。

### 3. 创造性结论与无效检索建议

* **创造性评估**：

D1、D2、D3 的结合**未能完全覆盖**“基于ROI位置与瓦片位置的空间重叠判断来决定瓦片视频流”这一核心机制（特征G、H、I）。因此，仅凭现有对比文件（D1~D3），权利要求1具备创造性，无效难度较大。

* **无效请求中最薄弱的技术特征**：

**特征G与特征H（ROI与瓦片重叠比对）**。这是目标专利区别于传统“直接裁剪ROI传输”或“静态多流切换”的核心逻辑。

---

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

若要成功发起无效宣告，需重点补充针对“**基于瓦片的动态ROI流请求（Tile-based ROI streaming）**”或“**瓦片重叠筛选算法**”的现有技术。建议策略如下：

1. **拓展技术标准文献（3GPP / MPEG / OMAF / DASH）**：

* **MPEG-DASH Part 1 (SRD - Spatial Relationship Description)**：重点检索 ISO/IEC 23009-1 及其扩展，SRD 架构中明确定义了基于空间位置（Spatial Coordinates）匹配 Tile 并请求动态 Tile 流的机制。

* **MPEG-OMAF (ISO/IEC 23090-2)**：全景/360度视频中的 Tile-based Viewport/ROI 传输规范。

2. **核心关键词组合检索**：

* `("Tile" OR "Tiled video") AND ("ROI" OR "Region of Interest" OR "Viewport") AND ("overlap" OR "intersect" OR "spatial position") AND ("request" OR "fetch" OR "DASH")`

* 重点检索申请日（或优先权日）之前的专利，如 interDigital、Qualcomm、Samsung、Technicolor 或 InterDigital 在 MPEG 提案中的技术文件。

作为一名经验丰富的专利代理师，我针对目标专利权利要求1与提供的两份对比文件（**D1：CN101690228B** 和 **D2：WO2012168356A1**）进行深入的权利要求解释、特征比对、最接近对比文件分析、薄弱特征识别及后续检索策略制定。

---

## 一、 目标专利权利要求1的代理人视角解释

权利要求1限定了一种“用于向客户端设备提供一个或多个瓦片视频流的方法”，其核心发明构思在于：

1. **两阶段/双重流交互机制**：首先接收/再现一个“感兴趣区域（ROI）视频流”（即第一ROI/第一子区域），然后通过该ROI的位置信息（ROI位置信息）结合预先定义的“瓦片位置信息”，计算出与之有交叠（重叠）的瓦片子区域，进而向服务端请求对应的瓦片视频流。

2. **空间映射与按需请求**：客户端通过将ROI在源视频图像区域内的动态位置与空间切片（瓦片 Tile）的位置进行重叠比对（Overlap Determination），实现仅请求和传输与用户视角/关注点重叠的瓦片流。

---

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

### 1. 对比文件公开号及指代说明

* **D1**：CN101690228B（授权公告日：2012-08-08，发明名称：视频编索引方法和视频编索引设备）

* **D2**：WO2012168356A1（国际公布日：2012-12-13，发明名称：LOCATING AND RETRIEVING SEGMENTED CONTENT）

---

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

---

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

从整体解决的技术问题与技术效果来看：

### 最接近对比文件选择：**D2 (WO2012168356A1)**

* **技术领域与问题对比**：

* **目标专利**：解决在客户端显示ROI时，如何高效定位并请求传输对应的瓦片（Tile）视频流，降低传输带宽与延迟。

* **D2**：专门针对**空间切片视频（Spatially Segmented Content / Tiled Video）**，解决在多CDN/客户端交互环境中，如何根据用户交互（Zooming, Panning, ROI切换）快速定位（Locating）并按需检索请求（Retrieving）空间瓦片片段，避免重定向延迟。

* **D1**：主要关注视频编码/解码端的SEI补充增强信息及H.264 FMO片组（Slice Group）的索引与选择性解码，侧重于传统视频编解码器内部处理，非网络流媒体传输中的瓦片（Tile）按需请求机制。

* **结论**：**D2适合作为最接近的对比文件**。D2公开了瓦片视频（Tiled Video）、空间切片（Spatial Segmentation）、清单文件（Manifest File）、基于位置/请求动态解析瓦片URL并由客户端发起瓦片请求（特征A、B、D、F、H、I、J）的完整架构。

---

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

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

结合D1与D2，目标专利权利要求1相对于D2的主要区别特征在于：

* **特征C + 特征E + 特征G的组合逻辑**：

* 客户端先**接收一个“ROI视频流”**（特征C）；

* 提取/提供与该ROI视频流关联的**ROI位置信息**（特征E）；

* **“融合计算”**：使用该“ROI位置信息”与“瓦片位置信息”进行比对/重叠判定，从而确定需要请求的瓦片视频流（特征G与H）。

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

在提出专利无效宣告请求时，**最薄弱的技术特征（即专利权人最难维持防线、最容易被认定为公知常识或显而易见的技术特征）**是：

> **特征G & H：使用ROI位置信息与瓦片位置信息确定重叠的瓦片子区域，并请求对应的瓦片流。**

#### 理由分析：

1. **公知常识与逻辑必然性**：在瓦片视频（Tiled Video/Tile-based Streaming）领域，图像已经被网格化切割为若干Tile（瓦片位置已知）。当用户指定或系统提供一个ROI（感兴趣区域）时，为了在显示器上呈现该ROI，**将ROI的几何坐标（x, y, w, h）与各个Tile的几何坐标进行重叠判断（Overlap Check），并仅请求重叠的Tile**，是本领域技术人员（POSITA）为了节省带宽必然采用的常规技术手段。

2. **D1与D2的结合**：

* **D2** 已经明确建立了“瓦片视频（Tiled Video）+ 空间位置清单 + 按需请求Tile”的框架；

* **D1** 明确公开了“在SEI消息中携带ROI位置坐标（x, y, w, h）”以及“根据ROI位置选择性解码/提取覆盖该ROI的片组（Slice Group）”。

* 本领域技术人员将D1中通过SEI传输ROI坐标的技术应用于D2的Tile请求场景中，导出“根据ROI坐标与Tile坐标交叠计算后请求Tile”是显而易见的。

---

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

为了在后续的无效宣告程序中彻底击靶（形成一击必杀的对比文件组合），建议采取以下补充检索策略：

### 1. 重点检索标准规范（3GPP / MPEG-DASH / OMAF）

目标专利的架构是典型的 **MPEG-DASH SRD (Spatial Relationship Description)** 或 **ISO/IEC 23090-2 (OMAF - Omnidirectional Media Format)** 全景/瓦片视频传输标准规范。

* **检索库**：IEEE Xplore, MPEG Input Documents (m43210等提案), 3GPP TSG-SA4 临时文档。

* **关键词组合**：

* `DASH` AND `Spatial Relationship Description` OR `SRD`

* `Tiled video` AND `ROI` AND `Overlap` AND `Manifest` / `MPD`

* `FOV` (Field of View) / `ROI` AND `Tile selection` AND `coordinate`

### 2. 专利检索式优化（Focus on Overlap & ROI-Tile Mapping）

在 PatentSight, Orbit 或 CNIPR 中使用如下逻辑组合：

* **IPC分类号结合**：`H04N 21/472` (客户端交互), `H04N 21/84` (结构化数据/Manifest), `H04N 19/167` (ROI编码), `H04N 19/174` (Tile/Slice编码)。

* **特征精准追踪检索式**：

* `(ROI OR "region of interest" OR "field of view" OR FOV) W/5 (location OR position OR coordinate)`

* `AND (tile OR "spatial segment" OR "tiled stream")`

* `AND (overlap OR intersect OR determine OR mapping)`

* `AND (request OR retrieve OR fetch)`

### 3. 追溯结合对比文件（D3/D4）

寻找直接公开“**客户端根据低码率/预览ROI流中的位置元数据，计算并向服务器请求高清 Tile 流**”的早期专利（优先关注2012年-2015年期间高通、诺基亚、爱立信、三星及Thomson在全景/交互式视频领域的专利布局）。

根据权利要求1所述的方法，其中所述感兴趣的区域ROI视频流是MPEG和/或DVB编码的感兴趣的区域ROI视频流；以及所述ROI位置信息还包括与所述ROI视频流的尚未被所述客户端设备接收的至少一个视频帧关联的至少一个超前位置。

根据权利要求1所述的方法，其中提供所述ROI位置信息包括；提供所述ROI视频流的至少第一图像帧的第一ROI坐标以用于基于所述一个或多个瓦片视频流来再现第二ROI；所述第一ROI坐标限定在由所述客户端设备接收到指令时所述第一子区域的所述第一位置。

根据权利要求3所述的方法，其中所述指令是用户发起的指令。

根据权利要求3所述的方法，其中所述指令包括ROI矢量以用于指示所述第一子区域的改变；并且其中所述ROI矢量用于确定所述一个或多个瓦片视频流。

根据权利要求3或5所述的方法，还包括；提供所述ROI视频流的至少第二图像帧的第二ROI坐标；所述第二ROI坐标限定在由所述客户端设备处理所述一个或多个瓦片流时所述第一子区域的第二位置；其中所述处理是接收、缓冲和/或解码之一。

根据权利要求3所述的方法，包括；基于所述一个或多个瓦片子区域和所述第一ROI坐标和/或第二ROI坐标来再现第二ROI。

根据权利要求3所述的方法，其中所述方法还包括；基于与所述一个或多个瓦片子区域关联的瓦片图像帧来形成第二子区域；从所述第二子区域中裁剪出所述第二ROI。

根据权利要求8所述的方法，其中如果所述第二子区域基于两个或更多瓦片子区域而形成；则形成所述第二子区域包括；同步所述两个或更多瓦片视频流的两个或更多瓦片图像帧；以及将所述同步的瓦片图像帧缝合成所述第二子区域。

根据权利要求2所述的方法，其中所述至少一个超前位置包括所述ROI视频流中尚未被所述客户端设备接收的一个或多个图像帧的一个或多个经时间移位的第一ROI坐标；所述经时间移位的第一ROI坐标在所述一个或多个图像帧之前被提供给所述客户端设备。

根据权利要求10所述的方法，其中所述经时间移位的ROI坐标还与时间移位信息相关联以用于确定所述时间移位。

根据权利要求11所述的方法，其中所述时间移位信息是时间戳。

根据权利要求1所述的方法，其中基于包括所述瓦片位置信息的空间清单文件来请求所述一个或多个瓦片视频流；所述瓦片位置信息包括所述图像区域内所述一个或多个瓦片子区域的坐标；所述空间清单文件还包括所述源视频的一个或多个瓦片表示；瓦片表示包括一个或多个瓦片标识符以用于标识一个或多个瓦片视频流。

根据权利要求13所述的方法，其中所述一個或多个瓦片视频流是基于HTTP的自适应流式传输类型的流。

根据权利要求1所述的方法，所述ROI位置信息包括ROI坐标；所述ROI坐标限定所述图像区域内所述第一子区域的至少一个位置；所述第一子区域由所述ROI视频流的至少一个图像帧来限定；其中；所述ROI位置信息的至少部分在所述ROI视频流的位流中传送到所述客户端设备；或者其中；所述ROI位置信息的至少部分在MPEG传送流中传送到客户端设备；或者作为所述MPEG传送流中的DVB定义的同步的辅助数据SAD分组；或者其中；所述ROI位置信息的至少部分在MPEG-4流中的预定义盒中被传送；或者其中；所述ROI位置信息的至少部分在MPEG-4流中的元数据轨道中被传送；或者其中；所述ROI位置信息的至少部分作为水印被传送到所述客户端设备。

根据权利要求15所述的方法，其中所述ROI位置信息是SEI消息或定义所述位流中所述ROI坐标的位置的ROI坐标标志；其中所述MPEG传送流是在所述MPEG传送流中的基本传送流；其中所述SAD分组包括经时间移位的ROI坐标；其中所述预定义的盒子是MPEG-4流的moov、trak和/或stbl盒；其中所述ROI位置信息的至少部分使用专用样本条目码在MPEG-4流中的元数据轨道中被传送；其中所述水印是在所述ROI视频流中的水印。