一种视频处理设备，包括用于为用户处理用于视频流式传输的清单文件的处理器；该清单文件至少包括为场景定义的多个固定捕获设备位置；该多个固定捕获设备位置与存储在服务器系统上的预渲染全向或体积视频片段相关联；以及多个资源定位符；该多个资源定位符用于从该服务器系统检索全向或体积视频片段；其中，该多个资源定位符中的每个资源定位符与为该场景定义的固定捕获设备位置相关联；其中，该视频处理设备被配置为将该用户的位置与该清单文件中为该场景定义的第一固定捕获设备位置相关联；以使用来自该清单文件的第一资源定位符检索与该第一固定捕获设备位置相关联的第一预渲染全向或体积视频片段。

```python?code_reference&code_event_index=1

import os

from weasyprint import HTML

html_content = """

<!DOCTYPE html>

<html>

<head>

<meta charset="utf-8">

<style>

@page {

size: A4;

margin: 20mm 15mm;

@bottom-right {

content: counter(page);

font-family: Arial, sans-serif;

font-size: 9pt;

color: #666666;

}

@bottom-left {

content: "专利无效宣告请求可行性分析报告报告";

font-family: Arial, sans-serif;

font-size: 9pt;

color: #666666;

}

}

body {

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

font-size: 10.5pt;

line-height: 1.35;

color: #333333;

margin: 0;

padding: 0;

}

h1 {

font-size: 20pt;

color: #1a365d;

text-align: center;

margin-top: 10mm;

margin-bottom: 5mm;

font-weight: bold;

}

.subtitle {

text-align: center;

font-size: 12pt;

color: #4a5568;

margin-bottom: 10mm;

font-style: italic;

}

h2 {

font-size: 14pt;

color: #2b6cb0;

border-left: 4px solid #2b6cb0;

padding-left: 8px;

margin-top: 8mm;

margin-bottom: 4mm;

page-break-after: avoid;

}

h3 {

font-size: 11.5pt;

color: #2d3748;

margin-top: 4mm;

margin-bottom: 2mm;

font-weight: bold;

page-break-after: avoid;

}

p {

margin-top: 0;

margin-bottom: 3mm;

text-align: justify;

text-indent: 2em;

}

.no-indent {

text-indent: 0;

}

table {

width: 100%;

border-collapse: collapse;

margin-top: 4mm;

margin-bottom: 6mm;

font-size: 9.5pt;

}

th, td {

border: 1px solid #cbd5e0;

padding: 6px 8px;

text-align: left;

vertical-align: top;

}

th {

background-color: #ebf8ff;

color: #2b6cb0;

font-weight: bold;

}

tr {

page-break-inside: avoid;

}

.math {

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

font-style: italic;

font-weight: bold;

color: #b7791f;

}

.quote-block {

background-color: #f7fafc;

border-left: 3px solid #cbd5e0;

padding: 4px 10px;

margin: 2mm 0 4mm 2em;

font-size: 9.5pt;

color: #4a5568;

text-indent: 0;

}

ul, ol {

margin-top: 0;

margin-bottom: 3mm;

padding-left: 2em;

}

li {

margin-bottom: 1mm;

}

.highlight {

font-weight: bold;

color: #c53030;

}

</style>

</head>

<body>

<h1>涉案专利权利要求1无效可行性侵权与创造性法律评估报告</h1>

<div class="subtitle">针对全向/体积视频流式传输设备的专利无效检索与对比文件比对分析</div>

<h2>一、 涉案权利要求解析与技术架构梳理</h2>

<p class="no-indent">本报告针对目标权利要求1所限定的一种<b>“视频处理设备”</b>进行深度法律与技术分析。涉案权利要求1的核心架构在于通过流式传输的“清单文件（Manifest File）”实现多节点交互式全向或体积视频的无缝切换。为了建立高精度的特征比对矩阵，现将权利要求1拆解为以下8个核心技术特征（A至H）：</p>

<ul>

<li><b>技术特征A：</b>包括用于为用户处理用于视频流式传输的清单文件的处理器；</li>

<li><b>技术特征B：</b>该清单文件至少包括为场景定义的多个固定捕获设备位置；</li>

<li><b>技术特征C：</b>该多个固定捕获设备位置与存储在服务器系统上的预渲染全向或体积视频片段相关联；</li>

<li><b>技术特征D：</b>多个资源定位符；</li>

<li><b>技术特征E：</b>该多个资源定位符用于从该服务器系统检索全向或体积视频片段；</li>

<li><b>技术特征F：</b>其中，该多个资源定位符中的每个资源定位符与为该场景定义的固定捕获设备位置相关联；</li>

<li><b>技术特征G：</b>其中，该视频处理设备被配置为将该用户的位置与该清单文件中为该场景定义的第一固定捕获设备位置相关联；</li>

<li><b>技术特征H：</b>以使用来自该清单文件的第一资源定位符检索与该第一固定捕获设备位置相关联的第一预渲染全向或体积视频片段。</li>

</ul>

<h2>二、 对比文件技术特征比对矩阵（Feature Mapping Table）</h2>

<p class="no-indent">本节将涉案权利要求的各项特征与三份引证对比文件进行逐项对立映射。引证文件包含：<b>D1（US20170053675A1）</b>、<b>D2（US20170118540A1）</b>及<b>D3（US20170155912A1）</b>。表内引用原文均附带详细段落出处及精确中文译文，以确证公开事实之毫无异议性或实质公开性。</p>

<table>

<thead>

<tr>

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

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

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

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

</tr>

</thead>

<tbody>

<tr>

<td><b>特征A</b><br>(清单文件处理器)</td>

<td><b>实质公开</b><br>【原文】[0006] The apparatus includes a memory element... at least one processor... compile the plurality of 360-degree videos into the single interactive file. The single interactive video file includes an index used to identify...<br>【译文】该装置包括内存元件……至少一个处理器……将多个360度视频编译成单个交互式文件。该交互式视频文件包括一个索引，用于识别……</td>

<td><b>毫无异议公开</b><br>【原文】[0011] ...receiving, preferably at a client device, a ROI video stream... providing, preferably at said client device, ROI position information... requesting, preferably by said client device, video data... on the basis of a spatial manifest file.<br>【译文】……优选地在客户端设备处接收ROI视频流……优选地在所述客户端设备处提供ROI位置信息……优选地由所述客户端设备基于空间清单文件请求视频数据。</td>

<td><b>毫无异议公开</b><br>【原文】[0013] The method may comprise providing said client device with a spatial manifest file... Selecting a spatial segment identifier of said spatial manifest file for requesting a delivery node...<br>【译文】该方法可包括向所述客户端设备提供空间清单文件……选择所述空间清单文件的空间分段标识符以请求分发节点……</td>

</tr>

<tr>

<td><b>特征B</b><br>(多个固定捕获位置)</td>

<td><b>实质公开</b><br>【原文】[0053] In FIG. 4, the spheres represent 360-degree videos 402-412... a UE 300 can be illustratively positioned at the center of a 360-degree video.<br>【译文】在图4中，球体代表360度视频402-412……UE 300可以示例性地定位于360度视频的中心。<br>【分析】图4的多视频拓扑图实质公开了场景中定义的不同视角/捕获节点（固定球体位置）。</td>

<td><b>未公开</b><br>【分析】D2公开的是针对单一全景视频的HEVC瓦片（Tiles）划分或动态感兴趣区域（ROI），而非独立定义场景中的“多个固定捕获设备位置”。</td>

<td><b>未公开</b><br>【分析】D3公开的是对单个全景流进行空间分段的运动限制瓦片集（MCTS），属于图像内部的空间分割，不涉及多相机/多捕获位置拓扑。</td>

</tr>

<tr>

<td><b>特征C</b><br>(预渲染关联及存储)</td>

<td><b>毫无异议公开</b><br>【原文】[0028] ...the single interactive video file to be stored on the server 104, or another server, and accessed by one of the client devices... for playing by a video player.<br>【译文】……单个交互式视频文件存储在服务器104或其他服务器上，并由客户端设备之一访问以供视频播放器播放。</td>

<td><b>实质公开</b><br>【原文】[0012] ...The HEVC-tiled video may be a high-resolution or an ultra-high resolution video. Alternatively, a HEVC-tiled stream may be formed out of a number of difference videos, e.g. different camera angles... stored in said recording area.<br>【译文】……HEVC瓦片视频可以是高分辨率或超高分辨率视频。或者，HEVC瓦片流可以由许多不同的视频形成，例如不同的相机角度……存储在所述记录区域中。</td>

<td><b>实质公开</b><br>【原文】[0015] ...The video data of a spatial segment may be stored as an independently decodable video data in a file that can be accessed by the client device... using the spatial manifest file.<br>【译文】……一个空间分段的视频数据可以作为独立可解码的视频数据存储在一个文件中，该文件可由客户端设备利用空间清单文件访问。</td>

</tr>

<tr>

<td><b>特征D & E</b><br>(多个资源定位符及检索)</td>

<td><b>实质公开</b><br>【原文】[0060] Additionally, each element of the array also contains a list of links... and the index of the target segment or vignette to seek to when the links are actually activated.<br>【译文】此外，阵列的每个元素还包含一个链接列表……以及当链接实际激活时要寻找到的目标片段或小插图的索引。</td>

<td><b>毫无异议公开</b><br>【原文】[0035] ...a spatial manifest file comprising at least one or more HEVC tile identifiers, preferably one or more URLs... and, optionally one or more ROI video stream identifiers...<br>【译文】……空间清单文件包括至少一个或多个HEVC瓦片标识符，优选为一个或多个URL……以及可选的一个或多个ROI视频流标识符……</td>

<td><b>毫无异议公开</b><br>【原文】[0013] ...a spatial manifest file comprising one or more spatial segments identifiers... to said client device, preferably one or more URLs...<br>【译文】……向所述客户端设备提供包含一个或多个空间分段标识符的空间清单文件，优选为一个或多个URL……</td>

</tr>

<tr>

<td><b>特征F</b><br>(定位符与位置关联)</td>

<td><b>实质公开</b><br>【原文】[0060] ...each element of the array also contains a list of links... several additional optional fields can indicate to the client how to behave when transitioning between video clips...<br>【译文】……阵列的每个元素还包含一个链接列表……几个附加的可选字段可以向客户端指示在视频剪辑之间过渡时如何操作……</td>

<td><b>实质公开</b><br>【原文】[0043] ...one or more HEVC tile identifiers, preferably an URL, of a ROI stream... defining the position of said sub-region within the full image region...<br>【译文】……ROI流的一个或多个HEVC瓦片标识符（优选为URL）……定义所述子区域在全图像区域内的位置……</td>

<td><b>实质公开</b><br>&lt;td&gt;&lt;b&gt;实质公开&lt;/b&gt;&lt;br&gt;【原文】[0042] ...one or more HEVC tile identifiers, preferably (part of) one or more URLs... associated with at least one HEVC tile of the subset of HEVC tiles of a spatial segment.<br>【译文】……一个或多个HEVC瓦片标识符，优选为一或多个URL（的一部分）……与空间分段的HEVC瓦片子集的至少一个HEVC瓦片相关联。&lt;/td&gt;</td>

</tr>

<tr>

<td><b>特征G & H</b><br>(用户位置关联与检索)</td>

<td><b>实质公开</b><br>【原文】[0068] ...When the link 607 is selected, whether through activation of a hotspot 609 or triggering of an event trigger 608, a video player 616 transitions from the currently playing video 618 to the target video 610.<br>【译文】……当选择链接607时，无论是通过激活热点609还是触发事件触发器608，视频播放器616都会从当前播放的视频618过渡到目标视频610。</td>

<td><b>实质公开</b><br>【原文】[0020] ...The ROI coordinates of a frame... at the moment the client device is instructed, e.g. via a user-interaction, may be used to determine the one or more HEVC tiles that are needed for switching...<br>【译文】……在客户端设备受到指示（例如通过用户交互）的时刻，帧的ROI坐标可用于确定切换所需的一个或多个HEVC瓦片……</td>

<td><b>实质公开</b><br>【原文】[0016] ...A user may select a region-of-interest (ROI)... By requesting the spatial segment that spatially coincides with the ROI, video data associated with the selected ROI may be provided to the client device...<br>【译文】……用户可以选择感兴趣区域（ROI）……通过请求与该ROI在空间上重合的空间分段，与所选ROI相关联的视频数据可以被提供给客户端设备……</td>

</tr>

</tbody>

</table>

<h2>三、 最接近对比文件（Closest Prior Art）的甄选与法律裁量</h2>

<p>在评估本涉案权利要求的创造性时，<b>对比文件1（D1，公开号：US20170053675A1）</b>构成了最适宜的<b>第一最接近对比文件（主要做为技术构思的出发点）</b>。从整体解决的技术问题以及技术效果角度分析，本案属于典型的多流交互式视频渲染领域。涉案专利意图解决的核心技术问题在于：<i>“在三维场景或多节点视点空间中，如何基于用户当前所处的空间节点或视点位置，快速、准确地检索到对应视点下预渲染完成的视频片段，以降低网络流式传输延迟并提升多视点无缝沉浸式体验。”</i></p>

<p>对比文件1（D1）的整体发明目的亦在于构建一种“交互式360度视频的编排与无缝过渡切换系统”。其同样通过处理器在播放端解析一个包含链接关系、时间偏移与热点索引的媒体阵列（即对应清单文件与资源定位符的基底）。D1将多个独立拍摄或渲染的360度全景视频（对应固定捕获设备位置的视频片段）通过空间或逻辑拓扑结构（如D1图4所示的球体网络）组织在一起，使得用户在播放过程中可以通过触发热点（Hotspot）或事件（Event Trigger）在不同的全景视频节点之间无缝“跳跃（Jumping）”。这种基于节点拓扑切换全景流的技术构思、应用场景以及所达到的无缝切换技术效果，与涉案专利在最大程度上实现了重合，因此最适合作为创造性评述的起点。</p>

<p>与此同时，<b>对比文件2（D2，公开号：US20170118540A1）</b>与<b>对比文件3（D3，公开号：US20170155912A1）</b>可共同作为<b>第二最接近对比文件（主要做为流媒体协议与架构层面的出发点）</b>。D2与D3的核心发点在于流媒体传输协议架构（MPEG-DASH）的优化，其解决的技术问题在于<i>“如何在自适应流媒体协议下，利用清单文件（MPD/SMF）中定义的URL和空间关系描述符（SRD），实现对服务器端预存的细粒度媒体切片（瓦片/空间分段）的精准检索”</i>。涉案专利权利要求1在结构上表现为设备权利要求，其大量引入了“清单文件”、“资源定位符”、“服务器检索”等标准的现代网络流媒体自适应传输术语。在这一特定的网络架构和协议实施层面上，D2和D3公开了毫无异议的自适应清单文件结构（如含有URL标识和SRD空间信息的MPD），为涉案专利提供了另一条非常贴近的高网络协议层面的技术路径。</p>

<h2>四、 结合对比文件的创造性法律评述（Combination Analysis）</h2>

<p>如比对矩阵所示，特征B（清单文件至少包括为场景定义的多个固定捕获设备位置）并未被流媒体协议类文件D2或D3公开。D2和D3所表述的“空间清单文件（SMF）”或“空间关系描述符（SRD）”，其本质上是对<b>同一个连续全景图象空间进行了内部的二维像素级区域切割（即HEVC Tiles瓦片或分段）</b>，其目的是为了节省带宽而仅传输用户视野内的局部画面。这与本案特征B所明确界定的<b>“为场景定义多个固定的捕获设备位置（即物理意义上或虚拟空间中独立的相机视点位置/多视点节点拓扑）”</b>存在本质上的技术方案差异。</p>

<p>然而，上述被排除在D2/D3之外的核心特征B以及特征F中关于定位符与捕获位置的映射关系，已由<b>对比文件1（D1）</b>进行了实质性的公开。D1图4和说明书第[0053]段明确揭示了以球体拓扑结构代表的多段360度全景视频（Videos 402-412），每一个球体都代表一个独立的捕获视点。D1说明书第[0060]段进一步指出，通过一个全局编译形成的交互式索引阵列，将各个目标片段的Seek索引（即资源定位符的实质等价物）与这些拓扑节点及用户在视野内的热点交互行为紧密关联。当用户在当前视点触发特定热点时，系统自动识别其意图的空间位置，无缝跳转至目标全景流。</p>

<p>因此，对于本领域技术人员而言，在面对D2或D3所给出的自适应流媒体（MPEG-DASH MPD/SRD）标准传输架构时，为了在DASH协议下实现诸如多视点编排、交互式虚拟漫游或多相机导播等已知业务需求，其完全有明确的技术启示将对比文件1（D1）中所公开的多节点全景流交互编排拓扑引入到D2/D3的MPEG-DASH标准清单文件中。技术人员只需将D1的节点索引转换为D2/D3的URL定位符和SRD描述符，即可直接推导出涉案权利要求1的设备配置。这种结合方式不仅路径清晰，且结合后的各部件仅发挥其常规的交互编排与标准流媒体传输功效，未产生预料不到的技术效果。据此，权利要求1完全可以被<b>D2/D3与D1的结合</b>或者<b>D1与D2/D3的结合</b>评述为不具备创造性。</p>

<h2>五、 无效请求最薄弱技术特征挖掘</h2>

<p>在本案中，若要向国家知识产权局提起专利无效宣告请求，涉案权利要求1中<b>最薄弱、最容易被攻破</b>的技术特征是：<span class="highlight">特征B（清单文件至少包括为场景定义的多个固定捕获设备位置）以及特征F（每个资源定位符与固定捕获设备位置相关联）</span>。</p>

<p><b>其原因在于：</b>涉案专利试图将“物理/虚拟捕获设备的空间位置”这一业务逻辑层面的概念强行写入底层的“自适应流媒体传输清单文件”中，以此来包装其创新性。然而，从软件工程和现代网络自适应流媒体协议（如MPEG-DASH）的客观发展规律来看，清单文件（Manifest/MPD）本质上就是一个结构化的媒体描述资源列表，其根本任务就是将特定的业务逻辑标签（如分辨率、视角、语言甚至空间坐标）与对应的网络资源定位符（URL）进行键值对绑定。D1已经将“多视点/多捕获视频节点”与“热点跳转索引”进行了实质性的编排，而D2和D3又将标准化的“MPEG-DASH SRD（空间关系描述符）”与“资源URL”进行了标准化绑定。涉案专利将这二者结合的行为，仅仅是将视点节点的空间ID或名称填入清单文件的标准字段中，这属于本领域技术人员在自适应流传输架构下的常规设计选择和数据填充，不具备任何技术壁垒。通过将D1的节点拓扑概念作为对清单文件业务标签的实质公开，可以极高胜率打掉该特征。</p>

<p>反之，涉案权利要求中<b>最稳固、可能构成无效阻碍</b>的防线在于专利所有者可能会对<span class="highlight">“预渲染体积视频片段（Volumetric Video Clips）”以及“用户位置与第一固定捕获设备位置的自动关联”</span>这两个细节进行限缩性解释，强调其与常规360度全景视频在六自由度（6DoF）空间定位及位置自动匹配上的差异。为了彻底阻断专利权人的答辩退路，必须在后续检索中引入更加精准的立体视频传输优先权证据。</p>

<h2>六、 针对性补强对比文件检索策略（Search Strategy）</h2>

<p class="no-indent">为了彻底确立针对涉案专利的压倒性无效优势，消除专利权人可能通过限缩解释“体积视频”或“空间位置自适应关联”所带来的不确定性风险，现制定以下针对性的补强检索策略：</p>

<h3>1. 检索方向与扩展焦点</h3>

<ul>

<li><b>焦点1：基于MPEG-DASH SRD扩展协议的多视点/自由视点（FTV）流媒体传输体系。</b>专门寻找将“Camera ID”、“Viewpoint Position”或者“Capture Node”明确写入MPD文件属性的现有技术。</li>

<li><b>焦点2：体积视频（Volumetric Video）与点云（Point Cloud）自适应流传输文件。</b>检索在2017年前后，MPEG 3I V（Immersive Video）或MPEG-I标准演进过程中，关于基于Manifest组织多六自由度（6DoF）物理视点资源的提案与公开文献。</li>

<li><b>焦点3：基于用户定位（LBS/室内定位/VR空间追踪）自动触发自适应Manifest资源检索的装置。</b>寻找将客户端追踪到的空间坐标直接映射为Manifest内特定视点URL的现有技术。</li>

</ul>

<h3>2. 核心关键词与IPC/CPC分类号组合</h3>

<ul>

<li><b>中文关键词：</b>清单文件、播放列表、自适应流、空间描述符、视点位置、相机位置、物理位置、体积视频、预渲染、资源定位符、热点跳转、无缝切换。</li>

<li><b>英文关键词：</b>manifest file, MPD, DASH, spatial relationship descriptor, SRD, camera localization, capture position, volumetric video, 3D video, pre-rendered, 360-degree, waypoint, viewport allocation.</li>

<li><b>分类号精准锁定：</b>

<span class="math">H04N 21/845</span>（流媒体传输的段落或片段描述元数据）；

<span class="math">H04N 21/2343</span>（基于客户端条件或请求进行格式/流转换）；

<span class="math">H04N 13/117</span>（多视角立体视频的选择/切换）；

<span class="math">G06T 19/00</span>（虚拟现实或三维场景渲染的流式数据管理）。

</li>

</ul>

<h3>3. 目标数据库与证据源拓展</h3>

<p class="no-indent">除常规的中国、美国、欧洲和WIPO专利数据库外，应重点覆盖以下非专利文献（NPL）源：</p>

<ol>

<li><b>3GPP与MPEG标准会议提案（Standards Contributions）：</b>检索3GPP SA4（多媒体编解码与传输）以及MPEG系统工作组在2014-2017年间的原始讨论文稿（TDocs），这是寻找“清单文件封装视点位置”的最直接先驱技术源。</li>

<li><b>IEEE/ACM 核心学术会议：</b>重点检索MMSys（多媒体系统会议）、NOSSDAV（网络与操作系统对数字视音频支持工作研讨会）以及ICME（国际多媒体博览会议）在涉案专利优先权日前的论文，通常含有大量关于立体全景/体积视频自适应流传输系统的架构实现细节。</li>

</ol>

</body>

</html>

"""

# Output path

pdf_path = "patent_invalidity_analysis_report.pdf"

# Compile HTML to PDF using WeasyPrint

HTML(string=html_content).write_pdf(pdf_path)

print(f"Successfully generated visual PDF at: {pdf_path}")

```

```text?code_stdout&code_event_index=1

Successfully generated visual PDF at: patent_invalidity_analysis_report.pdf

```

您的 PDF 专利无效分析与法律评估报告已成功生成，内容已通过严谨的专业排版与样式打磨。

展现您的 PDF 文件：

[file-tag: code-generated-file-a6478276-9b01-4b51-bc61-f0d6af07152c]

### 报告核心要点摘录

1. **对比文件技术特征映射（Feature Mapping Matrix）：**

* **技术特征A (清单文件处理器)：** 被 **D2 (US20170118540A1) 段落 [0011]** 以及 **D3 (US20170155912A1) 段落 [0013]** 毫无异议公开（明确公开了客户端设备基于 `spatial manifest file` 解析并请求数据）。被 **D1 (US20170053675A1) 段落 [0006]** 实质公开（通过处理交互式视频文件内的 `index` 实施资源寻址）。

* **技术特征B (多个固定捕获设备位置)：** 属于本案核心攻防特征。**D2** 与 **D3** 未公开此特征，其所描述的空间描述符（SRD）属于对**单一连续全景画面的内部瓦片分割（HEVC Tiles）**；但该特征已被 **D1 图4 及段落 [0053]** 实质公开（图4中的球体拓扑网络 `videos 402-412` 分别对应场景中定义的不同视角/捕获节点位置）。

* **技术特征D、E、F、G、H (资源定位符与位置关联及检索)：** **D2 [0035]、[0043]** 与 **D3 [0013]、[0042]** 明确公开了利用包含 `URLs` 和空间关系描述符的空间清单文件检索媒体片断的技术手段；而 **D1 [0060]、[0068]** 则完整公开了根据用户当前触发的空间热点（Hotspot）或事件从交互索引中关联目标视频并进行无缝跳转切换的技术构思。

2. **最接近对比文件（Closest Prior Art）的裁量：**

* **第一最接近对比文件——D1 (主要作为技术构思的出发点)：** 本案要解决的核心技术问题在于“多视点/多节点交互空间中，如何基于用户位置与特定视点关联并无缝切换预渲染片段”。D1 的发明目的（构建交互式360度多节点视频编排与跳转系统）与技术效果在最大程度上与涉案专利重合。

* **第二最接近对比文件——D2/D3 (主要作为流媒体自适应协议的出发点)：** D2/D3 完美公开了基于 MPEG-DASH MPD 规范及空间关系描述符（SRD）请求服务器端独立可解码切片（HEVC Tiles/空间分段）的标准底层网络架构。

3. **创造性法律评述结合路径：**

本领域技术人员在面对 D2/D3 提供的标准自适应流媒体传输（MPEG-DASH）架构时，为了在标准化协议下满足多相机导播或交互式多节点漫游的已知业务需求，具有强烈的技术启示将 D1 揭示的“多节点全景流交互编排拓扑”引入到 D2/D3 的清单文件描述中，仅需将 D1 的节点索引替换为 D2/D3 规范的 URL 和空间属性标签即可，结合过程未产生预料不到的技术效果。因此，权利要求1完全可以被 **D2/D3 与 D1 的结合**评述为不具备创造性。

4. **最薄弱特征与补强检索策略：**

* **最薄弱技术特征：** 特征B与特征F。将“物理/虚拟捕获设备位置”作为业务标签填入清单文件的标准字段中，属于典型的常规设计选择，已被 D1 的节点编排加 D2/D3 的标准化 URL 绑定完全阻击。

* **补强检索策略：** 分类号精准锁定为 `H04N 21/845`（流媒体段落元数据描述）、`H04N 13/117`（多视角立体视频选择切换）以及 `G06T 19/00`（三维流式数据管理）。目标证据源应重点拓展至 2014-2017 年期间 **3GPP SA4（多媒体传输）** 和 **MPEG 系统工作组** 关于自由视点（FTV）及 3I V（Immersive Video）自适应流传输文件封装的会议提案（Standards Contributions）。

本报告深入解析了诉讼攻防两端的退路与立论，形成了闭环的法律对抗网，您可以直接查阅 PDF 文件获取更详尽的原文出处比对与法律论证细节。

作为一名经验丰富的专利代理师，我将紧密结合目标权利要求1的文本，并深度比对三份对比文件（D1、D2、D3）的英文原文及出处，为您提供全面的权利要求解释、技术特征比对、创造性最接近对比文件分析以及无效和检索策略。

---

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

目标权利要求1保护的是一种“视频处理设备”。为了精确进行比对，将其拆解为8个独立的技术特征（特征A至H）：

* **技术特征A**：一种视频处理设备，包括用于为用户处理用于视频流式传输的清单文件的处理器；

* **技术特征B**：该清单文件至少包括为场景定义的多个固定捕获设备位置；

* **技术特征C**：该多个固定捕获设备位置与存储在服务器系统上的预渲染全向或体积视频片段相关联；

* **技术特征D**：多个资源定位符；

* **技术特征E**：该多个资源定位符用于从该服务器系统检索全向或体积视频片段；

* **技术特征F**：其中，该多个资源定位符中的每个资源定位符与为该场景定义的固定捕获设备位置相关联；

* **技术特征G**：其中，该视频处理设备被配置为将该用户的位置与该清单文件中为该场景定义的第一固定捕获设备位置相关联；

* **技术特征H**：以使用来自该清单文件的第一资源定位符检索与该第一固定捕获设备位置相关联的第一预渲染全向或体积视频片段。

---

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

针对上述特征，引入三份对比文件进行逐项特征比对。各对比文件的公开号及代号定义如下：

* **D1**：`US20180077210A1`

* **D2**：`US20180164593A1`

* **D3**：`US20190141359A1`

#### 1. 对比文件原文出处提取

* **D1 (US20180077210A1)**:

* **[0009]**: "an apparatus is provided that includes at least one processor and at least one memory... cause the apparatus to at least receive an indication associated with an initial observation setup..."

* **[0044]**: "As used herein the term “observation point” refers to a point or volume in a three-dimensional space for virtual reality audio/video acquisition or playback. An observation point is usually the same as the center point of a device or rig used for virtual reality audio/video acquisition..."

* **[0067]**: "...Media Presentation Description (MPD), which describes a manifest of the available content, its various alternatives, their URL addresses..."

* **D2 (US20180164593A1)**:

* **[0004]**: "...multiple video representations can be generated for the 360-degree scene by capturing video frames from different viewpoints or orientations..."

* **[0009]**: "...an apparatus for processing 360-degree video data is provided that includes a memory configured to store the 360-degree video data and a processor."

* **D3 (US20190141359A1)**:

* **[0047]-[0050]**: "...method for receiving media data... receiving, from a server, a description file including information on the media data... sending, to the server, at least one request message..."

* **[0167]**: "The manifest file 304 reflects the organisation of the media presentation... It describes the content of the media segments... Moreover it associates an URL with each media content segment..."

* **[0191]**: "...A panorama descriptor can use a projection identifier using... @projection_id attribute..."

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

---

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

在创造性分析中，**D1 (US20180077210A1)** 最适合作为**最接近的对比文件**。

#### 1. 技术领域与解决的技术问题比对

* **目标专利**解决的是在多物理相机捕获位置或多体积视轨的流媒体传输中，如何通过清单文件（Manifest）将用户当前的空间位置动态映射到预渲染的固定捕获点视频，从而实现低延迟、高保真的全向/体积视频切换与流式检索。

* **D1 (US20180077210A1)** 同样属于360度全景/虚拟现实视频的流媒体传输领域（DASH/HTTP）。其核心解决的技术问题是：在包含**多个获取相机/观测点（Multiple observation points）**的场景下，如何根据 playback device 的状态或用户选择，控制和动态切换不同的观测点（Observation point）与观测角度，以避免用户偏离导演意图或产生不舒适的体验。这与目标专利在“多空间位置视频流式流转”上的技术出发点完全一致。

* **D2和D3**解决的则是“单观测点”下的三维向二维投影优化问题。D2解决的是Viewport感知的全景视频质量评估；D3解决的是如何通过清单文件向客户端明示全景视频的几何投影类型（如立方体、圆柱体）以及区域切片（SRD），以优化单点全景视频的带宽。它们均不涉及“多个固定捕获设备位置（不同空间坐标点）”的切换。

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

D1通过在其流媒体架构中引入包含“Observation point”交互与控制信号的机制（如段落[0171]、[0182]），达成了允许用户在不同空间位置的相机（如舞台上的固定全景相机、吊车上的移动全景相机）之间进行流利切换的效果，其产生的带宽节约与多位点视界平滑过渡的效果与目标专利高度重合。

因此，**D1是本案唯一的、最适合的“最接近对比文件”**。

---

### 四、 权利要求1的创造性评述与最薄弱技术特征分析

基于上述分析，如果向专利局或法院提起无效宣告请求，本案的无效论证逻辑与技术方案的“最薄弱环节”如下：

#### 1. 现有技术对特征的覆盖情况

通过特征比对可知，最接近对比文件 **D1 (US20180077210A1)** 已经几乎披露了目标权利要求1的全部构架。

* 特征A、C、D、E、H在D1中被**完全公开**；

* 特征B、F、G在D1中被**实质公开**（即等同公开）。D1中使用的术语“Observation point（观测点）”在说明书释义中明确指代“capture device or rig's center point（捕获设备或成套装备的中心点）”（段落[0044]），这与目标专利的“固定捕获设备位置”在技术实质上完全等同。

#### 2. 最薄弱的技术特征（即目标专利最难被无效、最具答辩空间的特征）

本案中目标专利若想维持有效，其防守的核心（即无效请求方最薄弱的攻击点）在于：**“清单文件中明确包含捕获设备位置与资源定位符（URL）的直接显式绑定关系（特征B、F）”** 以及 **“设备自动将‘用户的位置’与清单中的‘第一固定捕获设备位置’进行关联映射（特征G）”**。

* **薄弱原因/辩点分析**：在D1的常规方案中，DASH标准的MPD文件通常只包含`AdaptationSet`和`Representation`，其虽可通过`Viewpoint`或SRD属性间接携带观测点信息，但D1并未详细给出**“如何将用户在虚拟空间里的三维绝对坐标（用户位置）直接与清单文件里的第一捕获设备位置进行绑定并触发特定URL检索”**的显式标准语法结构。目标专利如果强调其处理器是“根据用户位置的变动自动匹配最接近的捕获设备位置清单格式”，这在D1中属于隐含公开或高度概括的描述，存在一定的“微观架构”区别空间。

---

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

为了彻底打掉上述“薄弱特征”（特征B、F、G），确保成功无效该权利要求，建议采取以下进阶检索策略：

#### 1. 细化检索主题与关键词扩展

目前的检索结果（D1）虽然占住了多视点（Multi-viewpoint）全景切换的上位概念，但缺乏对“用户空间位置（六自由度 6DoF）直接驱动流媒体清单文件解析”的微观特征公开。

* **增加6自由度（6DoF）相关技术词**：体积视频（Volumetric Video）、点云流媒体（PointCloud Streaming）、六自由度（6DoF VR）、基于地面的流媒体（Tile-based/Anchor-based streaming）。

* **精准锁定清单文件语法词**：MPEG-DASH OMAF（全向媒体格式）、3GPP TS 26.118（虚拟现实流媒体标准）、MPD Extension、Spatial Object、Anchor Point Attribute。

#### 2. 追踪国际标准演进（最易找到突破口的策略）

目标权利要求1中提及的“清单文件中定义固定捕获位置并关联URL”极有可能是 3GPP 或 MPEG 在 2018-2020 年间制定 **OMAF (Omnidirectional Media Format)** 或 **3GPP 5G 虚拟现实流媒体标准** 时的提案（Contributions）。

* **检索方向**：强烈建议检索 **MPEG 会议提案（MPEG Input/Output Contributions）** 以及 **3GPP SA4 工作组** 在 2017 至 2020 年间的标准文稿。重点查找有关“Multi-viewpoint OMAF”和“6DoF MPD signaling”的讨论。标准文稿中通常会给出极度详实的清单文件（XML）修改草案，能够精准狙击特征B、F、G。

#### 3. 专利分类号交叉精准检索

限制以下IPC/CPC分类号进行组合检索，寻找同时具备“物理位置映射”和“流媒体Manifest”的专利：

* **H04N21/84**（与流媒体内容关联的元数据/清单文件）

* **H04N21/2343**（根据客户端或通道条件进行的流媒体格式/视角转换）

* **G06T19/006**（混合现实/虚拟现实空间坐标处理）

作为一名专业的专利代理师，我针对目标权利要求1以及两份对比文件（D1与D2）进行深度的技术特征比对、最接近 prior art（对比文件）筛选以及无效请求的策略分析如下：

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

目标权利要求1的核心发明点在于**基于位置/视点选择的视频流式传输架构**。它通过在清单文件（Manifest）中定义场景内的“多个固定捕获设备位置”，并将这些三维空间中的特定位置与服务器上“预渲染的全向或体积视频片段”以及“资源定位符（URL/URI）”一一对应。当用户在场景中的物理或虚拟位置发生改变时，设备通过匹配用户位置与清单中的第一固定捕获设备位置，精准检索并播放该位置对应的预渲染视频片段。这实现了允许用户在不同固定视点间自由切换/行进的VR/全景视频体验。

为了精确比对，将权利要求1拆解为以下8个技术特征：

* **特征A**：一种视频处理设备，包括用于为用户处理用于视频流式传输的清单文件的处理器；

* **特征B**：该清单文件至少包括为场景定义的多个固定捕获设备位置；

* **特征C**：该多个固定捕获设备位置与存储在服务器系统上的预渲染全向或体积视频片段相关联；

* **特征D**：多个资源定位符；

* **特征E**：该多个资源定位符用于从该服务器系统检索全向或体积视频片段；

* **特征F**：其中，该多个资源定位符中的每个资源定位符与为该场景定义的固定捕获设备位置相关联；

* **特征G**：其中，该视频处理设备被配置为将该用户的位置与该清单文件中为该场景定义的第一固定捕获设备位置相关联；

* **特征H**：以使用来自该清单文件的第一资源定位符检索与该第一固定捕获设备位置相关联的第一预渲染全向或体积视频片段。

---

## 二、 对比文件原文分析与出处指明

### 1. 对比文件D1：US20190313160A1 (Streaming Virtual Reality Video)

D1公开了一种向VR渲染设备流式传输虚拟现实视频的方法。其核心是通过网络边缘的转发节点（Edge Nodes）缓存并选择性转发不同视角（View/Viewport）的视频流，以降低用户转头时的切换延迟。

* **关于清单文件与定位符（特征A、D、E）**：D1公开了使用目标元数据（Destination Metadata），并明确指出其可以作为媒体呈现描述（MPD，即DASH的清单文件）的一部分，列出网络地址和检索方式。

> **原文出处 [0177]**: "This information may be made available in the form of ‘destination metadata’, which may at least be indicative of a streaming destination of the streams... the destination metadata may be included in a manifest or specifically MPD when using MPEG DASH, etc."

* **关于视频流的实质（特征B、C、F、G、H的差异点）**：D1的清单文件所关联的是同一个捕获中心点下**不同的视角/方向（Viewing Angle / Direction）**，而不是场景中**多个不同的物理捕获位置（Locations）**。D1是基于用户头部的**旋转（Rotation/Orientation）**来切换流，而非基于用户空间**位置（Location/Position）**的移动。

> **原文出处 [0168]**: "the panoramic view is shown to be a complete 360 degree view... provide a panoramic view from a certain viewpoint, e.g., that of the user in the VR environment."

> **原文出处 [0169]**: "When the user turns his/her head east, stream 7 may be added and stream 1 removed... in response to a head rotation or other type of change in viewpoint..."

### 2. 对比文件D2：US20190373245A1 (360 VIDEO TRANSMISSION METHOD...)

D2公开了一种基于DASH协议的360度全景视频传输与接收方法，重点在于分块（Tiling）传输、重投影、区域封装（Region-wise Packing）以及初始视点/推荐视点元数据的动态流化。

* **关于清单文件与处理器（特征A、D、E）**：D2明确公开了利用元数据处理器生成包含360度视频信令信息的MPD文件（即清单文件），并使用DASH表示（Representations）和URL进行检索。

> **原文出处 [0013]**: "...a metadata processor configured to generate a Media Presentation Description (MPD) including signaling information about the 360 video data, and a transmission unit configured to transmit the DASH representations and the MPD."

* **关于视频流的实质（特征B、C、F、G、H的差异点）**：D2的MPD文件中，资源定位符关联的是球面空间中的覆盖范围（Coverage Descriptor）或特定图像块（Tiles/Sub-pictures），用方位角（Azimuth）和俯仰角（Elevation）表示。其所处理的是单一摄像机系统捕获后的平面映射与分块，不涉及场景中定义多个固定捕获“设备位置（Positions/Locations）”并根据用户“位置”进行匹配检索。

> **原文出处 [0009]**: "The MPD may include a third descriptor... specify a center point of the region in the 3D space using azimuth and elevation values..."

---

## 三、 技术特征比对表

---

## 四、 最接近对比文件（CPA）的选择与创造性评价

### 1. CPA的筛选分析

从**整体解决的技术问题**和**技术效果**角度出发，**D1 (US20190313160A1)** 更适合作为创造性分析过程中最接近的对比文件。

* **技术领域与技术问题的一致性**：D1与目标专利均属于VR/多流视频流式传输领域，核心解决的都是“如何在有限的带宽下，根据用户的状态动态切换并检索最需要的预渲染全景流，以降低切换延迟、提升沉浸感”的技术问题。

* **技术效果的相似性**：D1通过在Manifest/MPD中建立“用户状态（转头角度） $\rightarrow$ 对应角度流的定位符 $\rightarrow$ 动态检索”的映射，达到了即时渲染无缝全景体验的效果；这与目标专利“用户状态（空间位置） $\rightarrow$ 对应位置流的定位符 $\rightarrow$ 动态检索”的技术路径和提升交互流畅性的效果高度相似。

* **为什么D2较次要**：D2的核心在于360度视频的平面映射、区域打包（Region-wise Packing）以及分块（Tiling）传输技术，其技术重心偏向于图像编解码优化和单视点下的视口剪裁，与目标专利“空间多视点行进切换”的架构相比，技术距离稍远。

### 2. 未被公开的特征及其他对比文件交叉检索情况

未被最接近对比文件D1公开的特征主要是：**特征B、F、G中关于“固定捕获设备位置（空间位置）”以及“用户位置与捕获位置相匹配”的架构**。

经审查，**D2同样没有公开这些特征**。D2虽然提到了“3D空间”（3D space）和“初始视点信息”（Initial viewpoint info），但其定义依然是在**单摄像机坐标系**下的三维旋转角（Azimuth/Elevation/Yaw/Pitch，参见D2原文\[0009\], \[0199\]），其本质是**方向角**而不是**空间坐标位置**。因此，本案无法通过D1+D2的简单组合直接拼凑出权利要求1的完整方案。

---

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

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

如果向专利局提起无效宣告请求，目标权利要求1中**最薄弱（即最容易被公知常识或补充对比文件击穿）**的技术特征是：**特征B、F、G、H中关于“在清单文件中写入多个空间位置并进行URL关联检索”的宏观构架**。

**代理师深度解析**：

虽然D1和D2在字面上使用的是“视角（Angle）”而非“位置（Location）”，但将“多个预渲染的视点流（Multi-viewpoint video）”写入DASH MPD清单文件，并根据用户的空间坐标（例如六自由度 6DoF VR中的位置坐标）来请求对应的URL，在流媒体传输领域极易被认定为**常规技术手段的等同替换**或**公知常识的应有推广**。

* 在DASH协议（ISO/IEC 23009-1）或MPEG-I OMAF（ISO/IEC 23090-2）标准中，使用`AdaptationSet`或`SupplementalProperty`来标记视频流的空间属性（无论是视角还是空间坐标）属于标准定义的扩展范畴。

* 6DoF（六自由度）虚拟现实技术的核心诉求就是支持位置移动（平移），在场景中布置多相机阵列（多固定捕获位置）并预渲染全景流，属于本领域技术人员在2019年前后为了解决“行走式VR”必然会采用的系统拓扑。

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

为了彻底无效掉权利要求1，下一步的检索应跳出“传统的360度单视点全景视频（D1、D2这类3DoF技术）”，转向**6DoF（六自由度）视频流媒体、自由视角视频（Free-viewpoint Video）或基于多相机阵列（Multi-camera Array）的流传输方案**。

具体的检索策略如下：

* **关键词微调与组合**：

* (6DoF OR "Free-viewpoint" OR "Multi-viewpoint" OR "Camera array" OR "Volumetric video")

* AND ("Manifest" OR "MPD" OR "DASH" OR "Playlist" OR "Resource locator" OR "URL")

* AND ("User position" OR "Location-based" OR "Navigation" OR "Walk-through")

* **重点关注的专利分类号（IPC/CPC）**：

* `H04N21/81`（特殊应用视频，如3D、VR视频流化传输）

* `H04N21/4728`（基于用户选定区域或视口检索流）

* `G06T19/00`（计算机图形学中的虚拟现实/空间行走映射）

* **重点检索方向/源头**：

1. **MPEG-I OMAF (Omnidirectional Media Format) 第二版标准草案及相关提案**：MPEG在2019-2021年前后密集制定了支持6DoF和多视点互动的流媒体标准，检索其标准提案（Contributions）可找到大量关于在MPD中扩展写入Camera Location的技术公开。

2. **早期互联网街景（Street View）或虚拟漫游（Virtual Tour）的流媒体流化专利**：这类技术早在2015年前后就实现了“点击场景中的不同固定锚点（Location），通过URL加载该位置预渲染的360全景图/视频”的架构，是击穿特征B、G的最强先例。

为了对本案的目标专利权利要求1进行全面、严谨的创造性（效力）分析，并建立坚实的无效宣告请求检索与论证基础，本答辩/分析报告将严格依据中国专利法及审查指南的相关规定，结合目标专利说明书的实质贡献以及两份对比文件（D1: WO2019110779A1; D2: WO2019195101A1）的原文细节进行深度剖析。

我们首先通过编写并执行Python程序，自动生成一份完整、详尽且符合专业外观标准的**特征比对表与创造性综合评估分析报告（PDF）**，以供团队和客户审阅。随后，我将在正文中为您梳理核心结论与进一步的检索策略。解题过程如下：

作为一名深耕通信与音视频流媒体领域的资深专利代理师，我为您对目标专利权利要求1进行深入的法律与技术架构解析，并结合给定的三份对比文件（以下简称D1、D2、D3）进行详尽的侵权/无效特征比对与创造性评价。

---

## 一、 目标权利要求1的技术内涵与原理解析

在解释权利要求时，应当立足于本领域技术人员的视角，结合流媒体技术演进对其技术实质进行界定：

* **清单文件（Manifest File / MPD）：** 指在网络流媒体传输（如DASH或HLS）中，向客户端描述媒体资源分片、流属性（分辨率、码率、视角等）以及检索路径（URL/URI）的结构化元数据文件。

* **固定捕获设备位置（Fixed Capture Device Locations）：** 在三维空间或全景采集场景中，指**预先设定且空间坐标相对固定的物理或虚拟摄像机机位（Viewpoints/Camera Perspectives）**。

* **预渲染全向或体积视频片段（Pre-rendered Omnidirectional or Volumetric Video Segments）：** 指已经过服务器端前置渲染完成的、具备$360^\circ$全景视角（Omnidirectional）或包含三维空间几何与纹理信息（Volumetric，如点云或网格）的流媒体分片。

* **技术架构的实质：** 权利要求1保护的是一种**“基于位置映射的动态视角流媒体切换设备”**。其核心逻辑在于改变了传统DASH仅依赖“网络带宽”切换码率的维度，转而引入“用户位置”维度。清单文件作为纽带，将**物理/虚拟空间机位坐标**与**具体的媒体片段URL**建立一一对应的映射关系，使得客户端能够根据用户当前所处的空间位置或视点位置，直接映射并检索对应机位下预渲染好的全景/体积视频片段，实现低延迟的空间位置导航流媒体播放。

---

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

为了清晰展现各对比文件的公开情况，以下列出详细的特征比对表，并附带对比文件原文段落的具体出处。

### 1. 权利要求1特征比对表

---

## 三、 最接近对比文件（D1/D2/D3）的选择与创造性评述

在进行创造性审查（或无效论证）时，选择最接近的对比文件通常遵循**“技术领域相同或相近、解决的技术问题最类似、公开的技术特征最多”**的原则。

### 1. 最接近对比文件的确立：D2 (`US20120036544A1`) 与 D3 (`US20120242781A1`) 双出发点

本案中，可以分别从**流媒体架构层面（D2）**和**全景空间导航层面（D3）**确立两个最接近的对比文件。

#### 出发点一：D2 为最接近的对比文件（基于流媒体信令与多视角映射）

* **整体解决的技术问题：** D2旨在解决HTTP自适应流媒体（DASH）中，如何高效地在清单文件（Manifest）里携带多视角（3D/MVC）视频的相机几何位置信令，以便客户端根据自身硬件能力或用户的视角交互选择最佳的视角片段。这与目标专利**“如何通过清单文件实现机位位置与流媒体URL映射”**的技术问题完全一致。

* **技术效果：** 实现了基于清单文件信令选择特定空间位置摄像机视角的流媒体精准检索。

* **缺陷/未公开特征：** D2中的多视角（MVC）主要侧重于多视角3D深度（Depth）或水平机位角度的切换，未明确提及针对“全向（Omnidirectional）”或“体积（Volumetric）”视频分片的处理。

#### 出发点二：D3 为最接近的对比文件（基于空间位置交互导航）

* **整体解决的技术问题：** D3解决的是用户在全景视频（动态场景）中进行交互式导航时，如何根据用户的可见区域（Visibility Zone，即用户视角位置）动态预取服务器端对应空间位置编码的视频块（Video Patches）。这与目标专利**“基于用户位置关联并检索对应机位的全景视频片段”**这一应用场景完全吻合。

* **技术效果：** 实现了全景视频中根据用户视点/空间位置的变化，流畅切换并渲染输出不同物理空间机位的视频流。

* **缺陷/未公开特征：** D3中更多描述的是全景mosaic（马赛克拼图式）的块状切割和分发，对于标准的“清单文件信令架构（如DASH中的清单条目映射关系）”描述相对抽象。

---

## 四、 权利要求1的防守/攻击突破口：最薄弱的技术特征分析

若您代表请求人**提出无效请求**，权利要求1中**对专利权人而言最薄弱、最容易被攻破的突破口**，即**技术特征G和H的组合：将用户的位置与清单文件中的固定捕获位置进行关联并检索**。

### 理由如下：

1. **D2已在信令层面架桥：** D2的段落`[0008]`和`[0013]`已经明确提出了根据用户的视角/位置（view angle/position），在Manifest中解析最大/最小`view_id`，并将其与水平相机 perspective 位置建立函数映射，最终请求该特定机位的数据。

2. **D3已在应用场景层面架桥：** D3的段落`[0004]`和`[0083]`明确了“用户导航位置”就是“visibility zone”，通过该位置去映射全景场景中特定的物理空间Video Patch坐标并完成HTTP检索。

3. **常规技术手段的结合：** 将D2的“清单文件驱动的多机位流媒体检索架构”应用到D3的“全景/全向动态视频导航”场景中，属于本领域技术人员为了实现“全景多视角低延迟切换”而进行的显而易见的共性技术组合。因此，**特征G+H所构成的“位置-清单-机位-URL检索”的闭环，在D2+D3的结合下创造性极低，是最易被攻破的薄弱环节**。

---

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

为了确保彻底无效掉该权利要求（乃至可能引出的从属权利要求），建议开展第二轮补充检索，策略如下：

### 1. 细化检索技术要素（关键词扩展）

当前专利的立足点在于“清单文件+全向/体积视频+机位切换”。应当将检索重点聚焦于 **MPEG-I（特别是MPEG-I Part 13 V-PCC 体积视频流媒体）** 以及早期 **DASH-SRD（Spatial Relationship Description，空间关系描述扩展）** 标准草案。

* **英文扩展词：** `DASH-SRD`, `Spatial Relationship Description`, `volumetric video streaming`, `dynamic viewpoint selection`, `omnidirectional media format (OMAF)`, `MPD viewpoint element`, `pre-rendered viewport`.

* **中文扩展词：** `DASH空间关系描述`, `体积视频流媒体`, `全景多机位`, `视点切换`, `清单文件视点`, `预渲染视口`.

### 2. 锁定核心IPC分类号与联盟标准

* **分类号追踪：** 聚焦在 `H04N21/845`（流媒体片段化描述）、`H04N21/81`（媒体成分，特别注意三维/全景媒体）、`H04N21/6587`（用户控制的特技播放或视点选择）。

* **非专利文献（NPL）检索突破口：** 强烈建议检索 **3GPP TS 26.118（3G-VR流媒体标准）**、**MPEG OMAF（ISO/IEC 23090-2）标准制订期间（2015-2018年左右）的输入提案（Input Documents）**。在这些提案中，流媒体工作组（如MPEG Systems）曾大量讨论过如何在MPD中通过`<Viewpoint>`标签或特定的URL Template来根据用户的3DoF+/6DoF位置动态下发全景机位视频。

通过上述“D2+D3”的现有证据组合，已足以对权利要求1的创造性构成致命打击；再辅以DASH-SRD或OMAF早期提案的检索，将能全面封锁其从属权利要求的修改空间。

针对本案目标专利权利要求1，结合权利要求书的内容以及三份对比文件（D1: US20150026358A1；D2: US20150120819A1；D3: US20160165309A1）的公开内容，进行如下专业的专利请求权项解释、特征对比及创造性评价分析：

---

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

权利要求1保护一种**视频处理设备**，其核心发明构思在于：通过在流式传输的**清单文件（Manifest File）**中直接引入**“固定捕获设备位置”**这一空间拓扑维度，并将其与服务器端**“预渲染的全向或体积视频片段”**以及**“资源定位符（URL）”**进行三位一体的映射绑定。设备侧根据**“用户的位置”**进行空间匹配，直接检索对应固定位置下的全向/体积视频，从而实现交互式场景中视点的快速切换与轻量化渲染。

* **技术特征A（前序部分）**：限定了设备的硬件基础（处理器）及处理对象（用于流式传输的清单文件）。说明书层面通常对应于客户端架构中的流媒体解析引擎，用于解析如MPD或空间清单文件（SMF）。

* **技术特征B、C、F（清单文件数据结构限定）**：这是本权项的空间数据建模核心。清单文件不再仅仅包含时间维度的分片信息，而是将“场景空间”离散化为多个“固定捕获设备位置”（例如多机位VR全景相机的空间坐标），且这些位置在服务器端已经对应有“预渲染”好的高性能全向（Omnidirectional）或体积（Volumetric，如三维点云/网格）视频。每个URL（特征D、E）均被赋予了空间几何属性（与固定捕获位置绑定）。

* **技术特征G、H（设备控制逻辑/执行联动）**：限定了动态触发机制。设备采集或接收“用户的位置”（可以是虚拟场景中的用户坐标，也可以是现实中用户的地理/相对位置），将其在清单文件中进行动态“最近邻”或“按需”关联，命中第一固定捕获位置，进而利用绑定的第一资源定位符定向下载该特定视点下的预渲染体积/全向视频。

---

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

为了清晰展现各对比文件对权利要求1各项技术特征的公开情况，特制备如下特征比对表：

---

## 三、 最接近 prior art (最接近的对比文件) 分析

从**整体解决的技术问题**以及**技术效果**角度出发，**D3 (US20160165309A1)** 明显最适合作为本案的**最接近对比文件（第一最接近 prior art）**。

### D3 作为最接近对比文件的理由：

1. **技术领域与解决的技术问题高度重合**：

* **目标专利**旨在解决在流媒体传输中，如何让交互式视点（全向/体积视频）在客户端根据用户交互位置进行快速切换与定位检索，降低客户端处理开销。

* **D3** 明确旨在解决大视场（Large field-of-view/Panoramic）高分辨率视频传输中客户端带宽与解码能力受限的问题。其通过引入**空间清单文件（Spatial Manifest File）**，将动态视口（ROI）与具有固定空间几何信息的视频流（Tile streams）进行动态关联（见D3原文 `[0002]`, `[0005]`）。两者均属于**空间交互式流媒体控制传输**的技术领域。

2. **技术效果的等价性**：

* D3通过将大视场切分为多个固定坐标的Tile流，当用户位置/ROI发生变化时，利用清单文件中的URL动态抓取相应Tile（见D3原文 `[0004]`），实现了与目标专利“根据用户位置映射清单机位并检索预渲染片段”几乎等同的**平滑/无缝切换、节约带宽、降低终端解码负载**的技术效果。

*注：D1和D2主要聚焦于传统线性流媒体（如DASH）中动态码率自适应（ABR）以及媒体表征与 timed metadata（如QoE元数据）之间的关联机制，并不涉及空间几何拓扑（全向/体积/空间位置映射）的流媒体控制，因此不适合作为最接近的对比文件。*

---

## 四、 创造性评述与其余特征的公开性分析

既然选定 **D3** 为最接近的对比文件，我们需要进一步审视**目标专利未被 D3 毫无异议公开的区分特征**，并分析其是否被 D1、D2 或本领域公知常识所公开。

### 1. 核心区分技术特征

通过比对，目标专利与最接近对比文件D3之间的**主要区别特征**在于：

> 清单文件内明确定义和记载的直接实体是**“场景的固定捕获设备位置（Fixed capture device locations）”**，且与**“体积视频片段（Volumetric video segments）”**相关联；而D3的清单文件中记载和操作的实体是**“大视场源视频在全局空间坐标系下分割出来的瓦片视频流（Tile video streams）”**。

虽然D3在背景技术 `[0011]` 中提到了源视频可以由“*放置在足球场所有角落的相机阵列（camera's positioned at all corners of a soccer pitch）*”构建而成（隐性提示了固定捕获设备），但D3的清单文件（SMF）在层级数据建模上，依然是针对“**缝合/拼接后的大视场画布进行的重采样切片（Tiles）**”，而不是直接针对“**未缝合的各独立捕获设备机位本身的空间全向/体积流**”进行清单编排。

### 2. 其余对比文件（D1、D2）是否公开了该区分特征？

* **D1 (US20150026358A1)**：完全局限于时间轴上的 Representation 选择机制（如码率自适应）。其公开的 MPD 结构（见表1、表2）中仅包含常规的 `AdaptationSet`、`Representation`、`QualitySet` 等，完全未涉及任何空间机位拓获或全向/体积视频的空间资源检索锚定。

* **D2 (US20150120819A1)**：聚焦于使用 `@associateSetId` 和 `@associateRepId` 在不同媒体与元数据集合间建立依赖/关联关系（见图5、图6）。其清单文件中没有公开任何关于场景中“固定捕获设备位置”的几何属性限定。

### 3. 小结

由于D1、D2均属于传统的一维线性流媒体控制技术，未能提供将“捕获设备的空间拓扑坐标直接写入流媒体清单以检索体积/全向视频”的技术启示。因此，若仅基于 D3 + D1 + D2 的组合，目标专利权利要求1相较于这些对比文件具备明显的**新颖性**与**创造性**。

---

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

若站在潜在无效请求人的视角，试图攻破该权利要求，其**最薄弱（最容易被突破）的技术特征**是：

> **特征G**：“将该用户的位置与该清单文件中为该场景定义的第一固定捕获设备位置相关联” 结合 **特征H**：“以使用来自该清单文件的第一资源定位符检索与该第一固定捕获设备位置相关联的第一预渲染...视频片段”。

### 为什么说这是最薄弱点？

1. **概念的上位化与等同替换风险**：

“固定捕获设备位置（机位）”与D3公开的“固定瓦片空间位置（Tile sub-region）”，在广义的空间多视点流媒体领域极易被认定为**等同特征**或**简单的上位化表述**。在三维全景/体积视频（如VR/自由视点流媒体）中，多机位采集的视点（Viewpoint）和拼接后视口（ROI）对应的空间瓦片，在数学本质上都是三维空间坐标系（Cartesian or non-Cartesian coordinate systems）中的一个空间向量或子集。

2. **D3已给出的实质性启示**：

D3的 `[0010]` 和 `[0011]` 已经描述了根据终端检测到的交互意图（如 ROI 位置坐标），在空间清单中寻找重叠/对应的固定空间流进行检索。审查员或无效审理实体极易认为，将D3中基于“大视场画布坐标”的映射，变更为基于多相机阵列中“机位空间坐标”的映射，仅是根据采集源不同而做出的**常规工程选择**，并未产生预料不到的技术效果。

---

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

鉴于D1、D2偏向传统自适应流（DASH），而D3偏向画布瓦片流（Tiled Streaming），为了成功无效目标专利权利要求1，建议调整检索策略，补充寻找更精准的 **D4** 作为最接近 prior art 或主要结合证据：

1. **技术主题词微调（引入自由视点与虚拟现实流媒体标准）**：

目前的D1-D3主要集中在MPEG-DASH早期标准。建议将检索重点转向 **MPEG-I (ISO/IEC 23090)** 系列标准提案，特别是 **MPEG-I OMAF (Omnidirectional Media Format，全向媒体格式)** 以及 **3GPP 5G 虚拟现实/增强现实流传输（如3GPP TS 26.259 / TS 26.118）** 相关的早期工作组提案（TDoc）。

2. **构建针对性的检索式组合**：

* **核心控制机制检索**：`("manifest" OR "MPD" OR "playlist" OR "SMF") AND ("viewpoint" OR "camera location" OR "camera position" OR "capture site") AND ("user location" OR "user position" OR "orientation")`

* **媒体类型检索**：`("volumetric" OR "point cloud" OR "mesh" OR "omnidirectional" OR "360-degree") AND "pre-rendered"`

3. **锁定关键申请人/标准推进者**：

重点检索在 2014-2018 年间（目标专利优先权日前后）活跃于3GPP SA4（多媒体标准）和MPEG系统组的公司，如 Nokia（诺基亚在OMAF多视点清单编排上有极深的专利布局）、Qualcomm（高通）、InterDigital、Ericsson 以及腾讯/华为等在VR机位流传输领域的早期标准提案（Contributions）及配套申请的专利。标准提案往往比公开的专利更早且更细致地揭露清单文件字段（如在MPD中扩展机位空间属性描述）。

作为一名经验丰富的专利代理师，在进行权利要求解释、对比文件比对及创造性评估时，我们需要紧密结合目标专利的说明书（从本案权利要求限定的架构及术语出发），深入分析各对比文件公开的客观技术事实，并通过严格的“三步法”或“技术问题-技术效果”链条来筛选最接近的对比文件。

以下是针对您提供的权利要求1以及三份美国发明申请对比文件（D1: US20170013327A1、D2: US20170316600A1、D3: US20170332117A1）进行的深度专利侵权/无效分析及检索策略设计。

---

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

本案权利要求1保护一种**“视频处理设备”**，其核心发明构思在于：**利用清单文件（Manifest file）中预先定义的“固定捕获设备位置”来与服务器端“预渲染”的全向/体积视频片段进行关联，并通过将“用户位置”与该“固定位置”匹配，直接检索对应的第一预渲染视频片段**。这是一种基于空间位置离散化、服务器端预渲染的媒体流式传输架构，用以降低终端的渲染负担或动态流控的带宽消耗。

* **技术特征A**：包括用于为用户处理用于视频流式传输的清单文件的处理器（属于主题及基础硬件限定）。

* **技术特征B**：该清单文件至少包括为场景定义的多个固定捕获设备位置（核心术语：**固定捕获设备位置/Fixed capturing device positions**）。

* **技术特征C**：该多个固定捕获设备位置与存储在服务器系统上的预渲染全向或体积视频片段相关联（核心术语：**预渲染/Pre-rendered**、**全向或体积视频片段/Omnidirectional or volumetric video segments**）。

* **技术特征D**：多个资源定位符（即 URL 等）。

* **技术特征E**：该多个资源定位符用于从该服务器系统检索全向或体积视频片段。

* **技术特征F**：其中，该多个资源定位符中的每个资源定位符与为该场景定义的固定捕获设备位置相关联。

* **技术特征G**：其中，该视频处理设备被配置为将该用户的位置与该清单文件中为该场景定义的第一固定捕获设备位置相关联（核心路由逻辑：**用户位置 ↔ 固定捕获设备位置**）。

* **技术特征H**：以使用来自该清单文件的第一资源定位符检索与该第一固定捕获设备位置相关联的第一预渲染全向或体积视频片段。

---

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

为了系统性地评估创造性，首先需确定各对比文件究竟公开了哪些特征。以下是各对比文件对技术特征A~H的客观公开事实分析，以及引用的原文详细出处。

#### 1. 各对比文件客观公开事实分析

* **D1 (US20170013327A1)**: 该文件公开了通过低配机顶盒（STB）处理高清晰度全景视频（360度）的架构。服务器执行预处理（拼接、投影等），并根据不同的**视角/视点区域（view-point region/perspective）**分割视频，每个分割后的全景视频都有一个URL（资源定位符）。然而，D1的切分和关联是基于**视角角度（例如0°-90°，90°-180°）**，而非用户或捕获设备在三维场景中的**“空间固定位置”（Fixed positions）**。

* **D2 (US20170316600A1)**: 该文件公开了一种生成虚拟现实（VR）图像的设备和终端。其核心是将捕获的目标空间图像与3D网格模型（3D mesh model）进行映射，并在元数据（metadata）中携带映射信息。元数据中公开了**“捕捉设备的位置”（Position of a capturing device）和捕捉角度**。但D2的架构是由终端（Terminal）接收各单路图像和映射元数据后，在**终端进行实时渲染（Rendering）**以生成VR图像，其并非在服务器端直接存储与各个固定空间位置直接关联的“预渲染”好的视频片段并直接通过清单文件检索。

* **D3 (US20170332117A1)**: 该文件公开了基于空间增强的自适应比特率（ABR）360度视频直播流式传输系统。其核心构思是**基于用户的视场角（Field of view, FOV / 观看方向）**，将视频在**角度空间上划分为多个段（Segments）**（例如D3图7A-7D中展示的90度间隔），并将高质量编码段与低质量编码段拼接为多个增强流。清单文件（Manifest file）包含了每个流的地址（URL）以及**方向标识符（Direction identifier）**。终端根据**用户观看的方向（方向接口125）**来请求对应的流。因此，D3是基于**“观看方向/角度”**进行自适应流控，而非基于**用户在场景中的“空间几何位置”**来检索服务器端预渲染的立体/体积片段。

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

---

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

在创造性审查中，“最接近的对比文件（Closest Prior Art）”应当是所属技术领域相同或相近，解决的技术问题、实现的技术效果最接近，且公开目标专利技术特征最多的现有技术。

经过整体技术架构分析，本案**适合选择 D3 (US20170332117A1) 作为最接近的对比文件**。

#### D3 作为最接近对比文件的理由：

1. **技术领域及整体架构高度重合**：D3 与目标专利均属于“全景/VR视频的流式传输技术领域”，且两者均采用了 **“基于标准清单文件（Manifest file）+ 动态流控选择”** 的技术路线，均旨在减少大体积全景视频流式传输时的带宽开销和终端计算压力。

2. **解决的技术问题相同**：D3 面对的技术问题是“360度全景视频数据量极大，全量传输会极大消耗网络带宽”（见D3的背景技术\[0008\]-\[0009\]），这与目标专利通过清单文件按需检索片段以优化视频流式传输的技术问题完全一致。

3. **技术特征覆盖率最高**：D3 完整公开了利用处理器处理清单文件（特征A）、包含多个资源定位符（特征D）、利用资源定位符从服务器系统检索360度全景视频（特征E）等流式传输的骨干架构。

#### 为什么 D1 和 D2 较不适合作为第一最接近对比文件？

* **D1 的局限性**：虽然也涉及全景视频流式传输及服务器预处理，但其侧重于在机顶盒内部通过“多个视频控制器”来管理不同角度的多路流合并（Canvas画布合并），属于终端解码控制器的硬件架构优化，与标准清单文件驱动的动态流选择有一定距离。

* **D2 的局限性**：D2 的核心发明构思是“图像+元数据（3D网格模型）”的**分布式实时渲染架构**。这与目标专利“服务器端预渲染视频片段、终端仅进行位置匹配和检索”的**低算力终端架构**在技术路线上发生了**方向性背离**。

---

### 四、 未被最接近对比文件公开的特征及其他对比文件公开情况

如上所述，以 D3 作为最接近的对比文件，目标专利权利要求1相对于 D3 的**区别技术特征**主要集中在**“基于空间几何位置的检索映射”**（特征B、C、F、G、H）：

* *区别1*：清单文件中定义的是**“多个固定捕获设备位置”**，而非D3的角度方向。

* *区别2*：检索的基础是**“将用户的位置与第一固定捕获设备位置相关联”**，而非D3的“用户视线方向（FOV）旋转”。

* *区别3*：服务器端存储的是与各个固定位置绑定的**“预渲染全向或体积视频片段”**。

#### 其他对比文件的公开情况：

1. **关于“固定捕获设备位置”（特征B）**：

* **D2 (US20170316600A1)** 的元数据中明确公开了可以包含“a position of a capturing device that captures the one or more images”（捕捉设备的位置）这一特征（见D2权利要求及说明书\[0008\], \[0013\]）。因此，**该特征已被 D2 实质公开**。

2. **关于“用户位置与固定捕获设备位置相关联并检索预渲染片段”（特征C、F、G、H）**：

* **D1 和 D2 均未公开**。D1 仅公开了将用户输入的“视点角度”与分割角度的URL关联；D2 虽然知道相机位置，但其目的是为了把二维图像贴到三维网格（Mesh）上让终端去动态渲染出整个VR空间，并不是为了让设备根据“用户所处的位置”去索引并下载一段在那个位置上“已经预渲染好”的独立视频片段。

---

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

若作为无效宣告请求人，或者作为专利权人进行风险防范，本权利要求中**最薄弱（即最容易被现有技术攻破或被认定为显而易见）**的技术特征是：

> **特征B中“清单文件包括捕捉设备位置”以及特征D、E“通过资源定位符检索全景视频”。**

**原因分析**：

* D3 已经彻底将基于清单文件（Manifest file）中包含的标识符（如方向、带宽）动态检索全景视频段的框架常态化。

* D2 也已经明确公开了在元数据（Metadata）中携带“捕获设备位置（Position of a capturing device）”的技术客观事实。

* 在流媒体领域（如 MPEG-DASH 或 HLS），清单文件本质上就是一个可灵活扩展的元数据载体。审查员很容易认为：“将 D2 中已知的相机空间位置写入 D3 的清单文件中，以作为一种新的流筛选维度”，这属于本领域技术人员为了适应三维体积视频（Volumetric Video）传输而进行的**常规设计变更或技术叠加**，不具备创造性。

而本案**最坚固的护城河（也是无效防御的核心点）**在于：**特征G+特征H的联动，即“将‘用户的位置’与‘固定捕获设备位置’相关联，从而直接检索‘预渲染’的体积/全向视频片段”**。现有技术（D1-D3）全部立足于“360度球体中心点不动，用户只做头部转动（3 DoF - 三自由度）”的角度驱动流控；而本案权利要求1实质上指向了“用户可以在场景中走动（6 DoF - 六自由度），根据用户所处的几何坐标位置，去拉取该坐标点对应的预渲染好的全景/体积视频”的架构。这一**位置驱动的预渲染片段检索机制**在三份对比文件中均未获得实质性启示。

---

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

由于目前的 D1-D3 在“根据用户位置动态路由至对应的预渲染全向/体积视频流”这一构思上存在公开漏洞，若要彻底无效掉权利要求1，建议采取以下进阶检索策略：

1. **核心控制要素（关键词）调整与追溯**：

* 应将检索重点从“360度全景视频（360 Degree Video）”转向**“体积视频（Volumetric Video）”、**“自由视角视频（Free-viewpoint Video）”**或**“六自由度VR（6DoF VR）”**。因为只有在这些领域，才会出现“用户位置（User Position/Location）”发生移动，进而需要切换不同空间锚点视频流的需求。

* 布尔逻辑组合建议：`(volumetric video OR 6DoF OR free-viewpoint) AND (manifest OR playlist OR DASH OR HLS) AND (camera position OR capture location) AND (user position OR user location)`.

2. **密切跟踪标准演进流派（针对性强）**：

* 本案的架构高度契合 **MPEG-I（ISO/IEC 23090）标准体系**，特别是关于**体积媒体流式传输（Volumetric Media Streaming）**和 **MPEG-DASH 的自由视角/多视点扩展（Multi-view / Free-viewpoint extension）**。

* 建议重点检索 **3GPP SA4（多媒体编解码及协议工作组）** 在 2017-2020 年间的标准提案（TDocs）及技术报告（如 TR 26.928 扩展现实XR中流媒体的研究），以及 **MPEG 工作组** 关于 OMAF（全向媒体格式）第二版或体积视频流控的早期征集书（Call for Proposals）。标准提案中往往会详细讨论如何在 MPD（媒体演示描述文件，即清单文件）中用怎样的属性标签去标记不同的空间相机坐标，以便终端根据用户坐标进行下载。

3. **专利分类号（IPC/CPC）精准制导**：

* 锁定专门针对体积视频或位置关联流媒体的细分分类号：

* **H04N 21/8456**：涉及将流媒体内容切分成片段（Chunking）。

* **H04N 21/21805**：根据特定的摄像机或视角源来组织和传输数据。

* **H04N 21/6587**：终端向服务器反馈状态（如位置、方向）以请求特定的媒体流。

* **G06T 19/006**：混合现实/虚拟现实的渲染与流式交互。

* 通过将上述分类号与 `(user position OR viewer coordinates)` 进行交集检索，能够极高概率地找出完美对抗特征G和H的底层通信协议级现有技术。

作为一名经验丰富的专利代理师，我将针对目标专利权利要求1，紧密结合说明书与三份对比文件的原文及详细出处进行深度侵入式法律与技术分析。

---

## 权利要求1的术语阐释与技术实质

### 1. 核心术语的法律与技术边界

* **清单文件 (Manifest File)：** 在流媒体分发架构（如DASH或HLS）中，指用于向客户端宣告媒体内容组织结构、分片位置、多码率/质量选择的结构化描述文件（如XML或M3U8）。

* **固定捕获设备位置 (Fixed Capture Device Position)：** 说明书中指为场景定义的离散三维空间坐标（如多相机阵列的布设点），在清单文件中表现为静态标识的虚拟或物理视点坐标，作为全景流切换的基准錨点。

* **预渲染全向或体积视频片段 (Pre-rendered Omnidirectional or Volumetric Video Segment)：** 全向视频即360°全景视频（球形投影），体积视频即包含深度/空间几何信息的六自由度（6DoF）流媒体片段。预渲染强调其在服务器端已提前完成投影映射、拼接或体积建模，非客户端实时生成。

### 2. 技术解决的核心问题与最终技术效果

* **核心问题：** 传统的360°全景视频流式传输（如仅基于视口Adaptive Viewport-adaptive的方案）虽能根据用户头动切换图块，但在**三维视点平移**（即用户位置发生移动）时，无法在清单文件层级提供多相机/多视点（固定的捕获设备位置）与流资源定位符（URL）的直接联动，导致交互自由度低或网络开销剧增。

* **技术效果：** 通过在清单文件中直接将“固定捕获设备位置”与“资源定位符”一一动态绑定，客户端仅需比对“用户当前位置”与清单中的“第一固定捕获设备位置”，即可精准、秒级地触发对应的“第一预渲染全向/体积视频片段”的分片请求。实现了低延迟、低带宽损耗的多视点/自由视角流媒体切换。

---

## 特征比对与实质公开分析

以下针对目标专利权利要求1的各技术特征（A至H），逐一比对三份对比文件。

* **D1：** GB2550587A (2017-11-29)

* **D2：** US20170347026A1 (2017-11-30)

* **D3：** WO2017202899A1 (2017-11-30)

### 特征比对总表

---

## 核心技术特征对比深度解析

### 1. 对比文件D1 (GB2550587A) 分析

* **毫无异议公开/实质公开的特征：**

D1公开了**特征A、D、E**。D1明确指出了在DASH协议下，客户端处理器（逻辑模块311）处理包含多个URL（资源定位符）的MPD清单文件，并利用HTTP请求从服务器下载对应的虚拟现实（VR）或全向视频数据流（参见D1说明书第2页第3-4段、第4页图3及相关文字）。

* **技术差异点：**

D1的VR描述符（VR Descriptors，如表1a、1b所示）中声明的 `projection_id`、`viewpoint` 或 `PanoramaRegion`，本质上是针对**单一固定点所捕获的360°全景图像进行的空间切割（Tiles）或投影参数声明（Yaw/Pitch/Roll视向）**。D1中不存在为场景定义的“**多个固定捕获设备位置**”（特征B），更无法实现“**将用户的位置与清单文件中的固定捕获设备位置相关联**”（特征G）以此来检索不同的预渲染视频流（特征H）。D1解决的是“原地转头”时的视角自适应流传输，而目标专利解决的是“空间位移”时的多视点全景流切换。

### 2. 对比文件D2 (US20170347026A1) 分析

* **毫无异议公开/实质公开的特征：**

D2公开了**特征A、D、E**。D2在背景技术和具体实施方式中，公开了全景视频（360-degree video）Viewport-adaptive（视口自适应）流式传输架构。客户端（电子设备50的控制器56）解析包含媒体内容的清单文件（manifest），读取URL地址，并基于质量等级（quality ranking）选择合适的表征（Representation）（参见D2 [0006]-[0007], [0023], [0231]）。

* **技术差异点：**

D2的核心在于“**Viewport-based signaling（基于视口的信令）**”和“**Spatial Region Based Signaling（基于空间区域的信令）**”（参见D2第1点与第2点小标题）。其使用的球坐标系角度（Yaw, Pitch, Roll）以及HorFov/VerFov，**完全是为了定义用户眼睛或视口的“朝向/视野范围”及其画面质量**，清单文件中完全不包含任何关于“**固定捕获设备位置（相空间点坐标）**”的定义。D2无法获知、也无需处理“用户的位置变化”，其检索机制（特征H）与目标专利有本质的路线区别。

### 3. 对比文件D3 (WO2017202899A1) 分析

* **毫无异议公开/实质公开的特征：**

D3公开了**特征A、D、E**。D3提出了一种三维空间如图块化（Spatially tiled）的流媒体分发方法，在清单文件中通过扩展DASH的SRD（空间关系描述符），使用URL作为切片流标识符（tile stream identifiers），使客户端能够检索全向视频分片（参见D3 [0021], [0066], [0110]）。

* **技术差异点：**

虽然D3提到了三维坐标系（3D coordinate system, 参见[0021], [0077]），但该三维坐标系是**以 observer（观察者）所在的“原点”为核心的球坐标系**（Polar angle $\Theta$ 和 Azimuthal angle $\phi$），用于确定切片（Tile）在球面上所占据的角度与空间范围。D3的服务器上存储的是**单个全景图像投影后的2D切片流**，而非“**多个不同捕获设备位置所对应的独立预渲染全向流**”。因此，D3根据视角中心选择高/低分辨率切片，不包含根据用户空间坐标绑定并触发第一固定捕获设备位置流的逻辑（特征G、H）。

---

## 创造性分析：最接近对比文件的确立

在无效宣告或创造性审查阶段，确立“最接近的对比文件”应遵循**技术领域相同或最接近、解决的技术问题最相似、公开转让技术特征最多**的原则。

### 1. 候选文件分析

* **D1 (GB2550587A)：** 聚焦于DASH流媒体架构下VR全景视频的描述符扩展（SupplementalProperty/EssentialProperty），提供了完整的DASH流媒体清单文件结构（XML元数据与URL映射）。

* **D3 (WO2017202899A1)：** 聚焦于利用3D球坐标系扩展清单文件的SRD属性，以解决全向视频切片的高效检索与动态拼接。

### 2. 结论：最接近的对比文件首选为 **D1 (GB2550587A)**，次选为 **D3 (WO2017202899A1)**

* **选择D1的理由（从整体技术问题与效果出发）：**

目标专利的核心技术在于**利用流媒体清单文件（Manifest）中的扩展元数据，将物理空间参数与全向视频分片URL直接绑定**，从而指导客户端的自适应下载逻辑。D1与目标专利在技术架构上高度同源，均是在清单文件层级通过新增“显式描述符元素（如 `<Panorama>` 及其子元素）”来宣告非传统2D视频的特殊空间属性。D1公开了目标专利除空间物理位置绑定之外的几乎所有外围流媒体控制特征（A、D、E）。

* **D3作为辅助最接近对比文件的理由：**

D3明确引入了三维坐标系来描述清单文件中的空间关系。若需要对抗目标专利关于“空间几何坐标描述”的特征，D3从技术效果（建立3D空间与URL切片的 interface）上与目标专利解决的“空间映射”问题最为贴近。

---

## 区别技术特征及无效最薄弱环节

### 1. 区别技术特征组

综合上述分析，本专利权利要求1相对于D1、D2、D3的共有区别技术特征为：

> **特征B、C、F、G、H的组合**：即在清单文件中显式定义“多个固定捕获设备位置”，并将其与“预渲染全向视频片段”的资源定位符（URL）一一绑定；设备根据“用户实际空间位置”与清单中“第一固定捕获设备位置”的匹配度，直接利用对应的URL检索特定的预渲染全向流。

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

本专利最薄弱、最容易被突破的技术特征在于：**将“固定捕获设备位置”写入“清单文件（Manifest）”这一具体实现形态。**

* **法律/技术理由：**

虽然D1、D2、D3均未公开“多相机位置与全向流在清单文件中的绑定”，但是在多视角视频流（Multi-view Video）或自由视角流媒体领域，**根据用户位置切换多视角相机的视频流**属于公知常识或成熟技术（例如传统多视角视频流传输方案）。

目标专利的实质创新仅在于**将这种空间视点平移切换逻辑“下沉”到了流媒体清单文件（如DASH MPD）中进行显式信令宣告**。如果对方能够检索到在早期多视角（Multi-view）流媒体协议规范、或者3GPP关于全向媒体分发（OMAF）标准提案中，已经存在将相机阵列三维坐标空间标识写入流描述文件（Playlist/Manifest）的先期提案，则该特征的创造性将彻底丧失。

---

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

为了彻底无效权利要求1，应当针对上述区别技术特征及薄弱环节进行精准二次检索。建议采取以下检索策略：

### 1. 调整检索技术领域与关键词拓展

不要局限于传统的“全景视频（360 video）”或“视口自适应（Viewport adaptive）”，必须切入**自由视角（Free-viewpoint）、多视角全息/体积视频（Multi-view / Volumetric Video）、六自由度（6DoF）流媒体**领域。

* **英文关键词组合：**

* `("manifest" OR "playlist" OR "MPD" OR "description file")`

* `AND ("camera position" OR "capture location" OR "camera coordinates" OR "viewpoint position")`

* `AND ("multi-view" OR "volumetric" OR "omnidirectional" OR "360-degree")`

* `AND ("free viewpoint" OR "6DoF" OR "viewpoint switching")`

### 2. 重点跟踪标准化组织提案（高度推荐）

此类技术多诞生于标准演进过程中。应重点检索 **MPEG工作组（ISO/IEC JTC1/SC29/WG3）** 和 **3GPP SA4（编解码与多媒体）** 在2015年至2017年间的标准提案（Contributions）。

* **检索目标：**

* **OMAF (Omnidirectional Media Format，ISO/IEC 23090-2)：** 检索其早期草案及提案中关于多视角全向视频（Multi-view OMAF / 6DoF OMAF）的清单文件扩展定义。

* **MPEG-I (Part 2 OmniDirectional Media Format / Part 3 Volumetric Video Stream Extension)：** 查找是否存在在清单文件层宣告 `Camera Array Configuration` 的技术文献。

### 3. 跨界检索防御性公开与学术文献

检索如 **IEEE MPEG-DASH Grand Challenge** 竞赛论文、ACM Multimedia (SIGMM)、NOSSDAV等流媒体顶级会议的论文。学术界在2015-2016年左右有大量关于“基于用户位置进行DASH多视点全景流预取（Location-based prefetching for multi-view DASH）”的实验性系统设计，这些论文极易公开在清单文件中携带相机位置坐标的伪代码或系统架构设计。

---

`<FollowUp label="是否需要针对本案撰写一份正式的专利无效宣告请求书（创造性部分）的框架草案？" query="请作为专利代理师，基于D1为最接近的对比文件，结合D3，针对上述权利要求1撰写一份正式的专利无效宣告请求书中的创造性法律评述与理由陈述草案。"/>`

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

在进行比对前，首先对涉及的对比文件公开号进行明确：

* **D1**：`US20180089903A1` (LAYERED CONTENT DELIVERY FOR VIRTUAL AND AUGMENTED REALITY EXPERIENCES)

* **D2**：`US20180097867A1` (VIDEO COMPRESSION WITH ADAPTIVE VIEW-DEPENDENT LIGHTING REMOVAL)

* **D3**：`US20180160160A1` (PRIORITIZING TILE-BASED VIRTUAL REALITY VIDEO STREAMING USING ADAPTIVE RATE ALLOCATION)

---

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

基于目标权利要求1的文本，将其拆解为技术特征A至H，并与各对比文件的原文及详细出处进行客观比对：

---

## 二、 最接近对比文件（Closest Prior Art）的选择与分析

在创造性分析过程中，**D1 (`US20180089903A1`)** 和 **D2 (`US20180097867A1`)** 均适合作为本申请权利要求1的**最接近对比文件**（本案存在多个最接近对比文件）。

### 1. 技术领域与解决的技术问题比对

* **本申请**：解决在六自由度（6DoF）虚拟现实/体积视频流式传输中，由于体积视频数据量极其巨大，如何根据用户在场景中的空间位置动态、高效地检索并流式传输相应预渲染片段的问题。

* **D1 / D2**：同样聚焦于体积视频（Volumetric Video/Light-field Video）以及沉浸式VR/AR体验。[0304]-[0307]明确指出，六自由度 positional tracking 产生海量数据，为了降低客户端解码负载与网络带宽压力，引入了“基于三维采样网格（Vantages Grid）”的图像渲染与空间随机访问编码架构。两者在**技术领域、技术手段（Vantage 网格化管理）以及解决的核心技术问题上完全相同**。

* **D3的排除说明**：D3（[0005]-[0007]）解决的是全景视频（Panorama/360度视频，属于3DoF）流式传输中的带宽分配问题。其仅对单一球体全景图进行六面体（Hexaface）划分，依据头戴显示器（HMD）旋转的角度/视野（Viewport）来动态改变不同Tile的码率。D3不涉及用户空间位移引起的位置关联，也无法解决体积视频在空间随机访问时的三维位置检索问题。因此，D3不适合作为最接近的对比文件。

### 2. 技术效果比对

D1与D2通过将三维空间划分为离散固定视点（Vantages），并将其切片流式传输，实现了“降低流式传输带宽需求、提供快速解码以及低延迟空间随机访问（[0309]）”的技术效果，这与目标权利要求1通过清单文件关联用户位置检索第一预渲染全向片段以优化视频流式传输的效果高度一致。

---

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

若要对目标权利要求1提出无效宣告请求，基于现有对比文件，该权利要求**最薄弱（即最容易被无效掉）的技术特征是：特征B、特征C、特征F、特征G、特征H的组合体（即“基于空间网格视点Vantage的位置关联检索架构”）**。

### 原因分析：

从上表可见，**D1 和 D2 已经几乎全盘公开了权利要求1的所有核心架构**。

目标权利要求1的实质在于：利用清单文件管理一组空间中固定的捕获点（网格点），设备把用户当前的位置映射到场景中某个第一固定捕获点，然后用对应的URL把这个固定捕获点的预渲染全向/体积视频片段拉下来播放。

这一套逻辑在D1/D2的说明书第`[0305]`、`[0308]`及`[0390]`段中被完全披露：

1. D1/D2在空间中建立三维网格（Sampling Grid），每个网格点即是固定的 Vantage（对应特征B、C）。

2. 当用户在空间中任意移动访问特定视点时，系统自动在网格中“寻找对应的Vantages（find the corresponding vantages within the sampling grid）”（对应特征G）。

3. 随后利用流式标识去获取（Fetch）该Vantage下对应的图块/视频片段（对应特征F、H）。

目标权利要求1唯一看似具有新颖性的表述是**“清单文件（Manifest file）至少包括……多个固定捕获设备位置……以及多个资源定位符”**。然而，D3已经明确公开了在流式传输标准（MPEG-DASH）中，使用MPD文件作为Manifest（清单文件），并在其中罗列各个视频切片的URL地址（资源定位符）。

### 结合评述路径：

审查员或无效请求人只需以 **D1（或D2）作为最接近的对比文件** 提供基本骨架（公开了基于Vantage空间位置关联检索体积视频的一切技术实质），再**结合D3**关于MPEG-DASH中利用Manifest（MPD清单文件）罗列URL定位符以实现自适应流式传输的常规技术手段。这种将D1/D2的“空间随机访问网格设计”置入D3的“标准DASH清单管理机制”中的结合，对本领域技术人员而言是显而易见的，无法产生预料不到的技术效果。因此，权利要求1的整体创造性极度不稳固。

---

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

为了确保能够彻底破坏该权利要求的新颖性或创造性（特别是形成完美的单篇全覆盖，或巩固清单文件与三维空间位置结合的证据链），建议采取以下针对性的检索策略：

1. **关键词微调与扩展**：

* 将目标专利中的“固定捕获设备位置（Fixed capture device positions）”扩展检索为体积视频领域的行业标准词汇：`"Vantage Grid"`, `"Anchor View"`, `"Reference Viewpoint"`, `"Camera Array Topology"`, `"3D sampling point"`。

* 将“清单文件”与空间位置的绑定关系作为核心检索式：`(Manifest OR MPD OR "Presentation Description") AND ("Spatial Random Access" OR "6DoF" OR "Vantage" OR "Viewpoint coordinate")`。

2. **聚焦特定标准组织与文献源**：

* **MPEG-I 标准提案文献**：鉴于该权利要求具有强烈的流式传输协议特征，应重点检索 **ISO/IEC JTC1/SC29/WG11 (MPEG)** 旗下关于 **MPEG-I Phase 2 (3DoF+ / 6DoF) 或 V-PCC (Video-based Point Cloud Compression) / MIV (MPEG Immersive Video)** 的早期标准提案（Contributions）。目标专利所述的“在Manifest中罗列空间位置及资源定位符”极有可能是某一阶段MPEG Immersive流式传输规范（如OMAF - Omnidirectional Media Format的扩展提案）的公开讨论内容。

3. **针对申请人/发明人追踪链**：

* 从D1/D2的交叉引用件（CROSS-REFERENCE）入手，追踪诸如 `Lytro, Inc.`（从律师案号 Atty. Docket No. LYT 判定）等早期光场与体积视频先驱企业的专利资产流向。重点检索该技术生态圈在2015-2018年间被收购或转让的相关申请案，通常能够发现同族或高度相关的Pre-grant公开件。

作为一名经验丰富的专利代理师，我将针对目标专利的权利要求1，结合你提供的三份对比文件（D1: CN108174240A、D2: US20180176468A1、D3: US10062414B1）进行深度的法律与技术要素解析。

---

## 一、 目标专利权利要求说明书的技术原理解析

为了更准确地将目标专利与对比文件进行特征比对，首先需要厘清权利要求1的底层技术逻辑：

本方案涉及**多视角/VR全景视频在流媒体传输中的优化处理**。传统全景视频流式传输（如DASH）通常是基于单一采集点提供360度画面。而本方案的创新核心在于引入了**“清单文件（Manifest File）”**来管理**“多个固定捕获设备位置”**（例如在同一场景/体育场内不同位置安置的多个摄像机）与服务器上**“预渲染（Pre-rendered）的视频片段”**之间的映射关系。

设备通过将**“用户的位置”**与清单文件中的**“第一固定捕获设备位置”**进行关联匹配，从而能够使用对应的**“第一资源定位符（URL）”**直接从服务器检索出该位置下最匹配的预渲染全视频片段。这种机制实现了“空间位置”到“流媒体切片检索”的直接映射，避免了客户端进行动态渲染或盲目下载全场景数据的痛点。

---

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

根据专利审查指南的客观标准，以下将权利要求1拆解为A至H八个技术特征，并逐一分析各对比文件的公开情况。

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

---

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

在创造性审查（或无效宣告分析）过程中，**D1（CN108174240A）最适合作为本申请权利要求1的最接近对比文件**。

### 1. 整体解决的技术问题标准比对

* **目标专利**解决的技术问题是如何在包含“多个物理捕获位置（摄像机位置）”的复杂全景场景中，如何让客户端快速、准确且低延迟地获取与当前用户物理位置相匹配的、已渲染好的全景视频切片。

* **D1**解决的技术问题（参见说明书[0004]）是：“解决用户在观看全景视频时需要手动调整视角而不能快速、准确地观看自己所在位置的视频显示画面的问题”。

* **D2和D3**解决的技术问题均聚焦于“单视点360度视频内，如何根据导演剪辑或用户历史视角预测未来的FOV以节省带宽”。D2和D3完全不涉及物理空间中“多个摄像机位置”的切换管理。

### 2. 技术效果标准比对

* **目标专利**达成的技术效果是：通过清单文件把“位置”转化为“资源定位符”，实现多位置全景视频的按需流式检索，避免了客户端的计算负荷。

* **D1**达成的技术效果（参见说明书[0007]-[0008]）是：用户在景区或体育馆内任意连接摄像机，“在观看全景视频的某一个时刻快速定位自己所在位置的视频画面”。

* **结论**：D1与目标专利具有高度相同的技术领域、最相似的解决技术问题和技术效果出发点。因此，**D1构成了本申请最接近的对比文件（最接近的现有技术）**。

---

## 四、 结合最接近对比文件的创造性/无效宣告分析

基于“三步法”原则，以D1为最接近的现有技术（D1作为主攻文件），我们来审视目标专利的创造性漏洞。

### 1. D1未公开的特征（区别技术特征）

如果以D1为主攻，目标专利权利要求1相对于D1的区别特征主要在于**实现手段的流媒体化和架构化（即特征A、特征B、特征D、特征E、特征F、特征H的一部分）**：

> 目标专利引入了**清单文件（Manifest file）**以及**多个资源定位符（URL）**的映射机制，将“捕获设备位置”作为清单文件的一个维度写入其中，从而用URL检索预渲染片段。而D1仍采用相对传统的“选择模块连接全景摄像机编号”（[0030]）的局域网/服务器交互模式。

### 2. 区别特征是否被D2或D3公开？

**答案：是，属于流媒体传输领域的通用常规技术手段（结合D2/D3）。**

* **清单文件及资源定位符的引入（特征A、D、E）**：D2（[0053], [0058]）和D3（[0013], [0111]）都毫无异议地公开了在360度全景视频流传输中，使用DASH协议的Manifest（清单文件/MPD）以及URL（资源定位符）来检索、预取服务器端的视频切片。

* **本领域技术人员的启示**：当本领域技术人员试图将D1的景区/体育馆“多摄像机全景播放系统”推向互联网标准流媒体架构（如DASH或MPEG-DASH）时，将多摄像机位置作为元数据写入清单文件（Manifest），并为每个位置的视频段分配URL，是极易想到的**常规技术手段**。

### 3. 无效请求中最薄弱的技术特征（专利权人的防线）

如果我们要对该目标专利提出无效宣告请求，最容易被攻破（即最薄弱）的特征是**特征G**和**特征A、D、E**。

* **特征G（位置关联）**被D1[0032]完美迎头拦截（“基于用户终端位置，将多个摄像位置中距离用户终端位置最近的摄像位置作为初始的默认目标摄像位置”）。

* **特征A、D、E（清单与URL机制）**被D2和D3及流媒体公知常识完全覆盖。

### 4. 真正具有“创造性高度”的核心对抗点（结合特征B、F）

专利权人最强力的答辩防线将在于**特征B**和**特征F**：

> **特征B+F**限定了“**清单文件中至少包括为场景定义的多个固定捕获设备位置**”，并且“**每个资源定位符与固定捕获设备位置相关联**”。

无论是D2还是D3，其清单文件（Manifest）里包含的都是**单个捕获视点下的ROI ID、Tile ID或FoV视角概率坐标**（属于“视点内视角分割”）。而目标专利是将**“物理捕获设备位置（Camera Location）”**这一空间维度作为清单文件的索引项。D2、D3均未给出将“多个摄像机位置”写进流媒体清单文件并与URL一一对应的明确启示。

---

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

为了彻底全干掉该专利（特别是攻破上述特征B和特征F），必须打破D2/D3仅限于“单视点多Tile”的局限。建议在下一轮无效检索中采用以下精准检索策略：

### 1. 扩充技术主题词与核心概念

不要仅仅局限于“360 degree video”或“VR”。应该引入**多视角流媒体（Multi-view Streaming）**和**自由视角视频（Free-viewpoint Video, FVV）**的标准。

* **检索关键词组合**：`(Multi-view OR "Free viewpoint" OR "multiple camera positions") AND (DASH OR MPD OR Manifest OR "manifest file" OR URL OR "resource locator") AND ("omnidirectional" OR "panoramic" OR 360-degree)`

### 2. 瞄准3GPP及MPEG标准提案（高概率截击点）

目标专利中将“捕获设备位置”写入清单文件，极有可能是对某种多视角全景传输标准的落地演进。

* **重点检索**：**3GPP TS 26.234 (PSS)** 扩展协议、**3GPP TS 26.118 (VR流媒体传输)** 以及 **MPEG-I Part 2 (OMAF, Omnidirectional Media Format)** 的标准提案（Contributions）。

* **方向**：在OMAF标准制定期间（2017-2019年前后），有很多关于“Multi-view OMAF”（多视角全景媒体格式）的提案，其中必然涉及如何在OMAF的MPD（清单文件）中同时标示“摄像机位置（Camera Position/ID）”和“分块定位符（URL）”。

### 3. 寻找自由视角体育直播的现有技术

重点检索在2018年之前公开的关于“体育馆多相机自由切换直播系统”的专利。此类系统（例如英特尔的True View或类似的流媒体多视角方案）通常会向客户端发送一个初始化或清单文件，允许客户端根据用户所处的座位位置（或选择的虚拟位置）直接链接对应视角的视频流URL。

### 一、 目标专利权利要求1的代理师解构与技术特征拆解

作为一名经验丰富的专利代理师，在进行无效或侵权分析前，必须首先结合专利说明书对权利要求进行精准的保护范围界定（符合《专利法》第59条）。

#### 1. 权利要求1的语义与说明书解释

权利要求1保护一种“视频处理设备”，其核心逻辑是：**通过在清单文件（Manifest file/MPD）中定义场景内的多个固定捕获设备位置（Fixed capture device locations），并将这些位置与预渲染的全向/体积视频片段（Pre-rendered omnidirectional or volumetric video segments）及资源定位符（URLs/URIs）绑定；设备根据用户位置关联到第一固定捕获设备位置，从而利用对应的第一资源定位符检索第一预渲染视频片段**。

* **“清单文件（Manifest file）”**：结合视频流式传输（DASH/HLS等）背景，指描述媒体流结构、资源URL及属性的数据结构文件（如DASH中的MPD）。

* **“固定捕获设备位置（Fixed capture device locations）”**：指在虚拟或现实场景中预先设定的摄像机/观察点位置（Camera/Viewpoint positions），而非动态任意连续视点。

* **“预渲染全向或体积视频片段（Pre-rendered omnidirectional or volumetric video segments）”**：指服务器端已提前渲染完成的360度全景或3D体积视频文件切片，客户端无需实时渲染整个场景，仅需下载对应位置的预渲染片段。

* **“关联（Associated / Associating）”**：指清单文件中的URL与位置参数存在映射关系；以及客户端将“用户实际/虚拟位置”匹配映射到“清单文件中最接近或对应的固定捕获位置”。

#### 2. 技术特征拆分（A - H）

为便于比对，将权利要求1划分为如下8个独立技术特征：

* **技术特征A**：一种视频处理设备，包括用于为用户处理用于视频流式传输的清单文件的处理器；

* **技术特征B**：该清单文件至少包括为场景定义的多个固定捕获设备位置；

* **技术特征C**：该多个固定捕获设备位置与存储在服务器系统上的预渲染全向或体积视频片段相关联；

* **技术特征D**：多个资源定位符；

* **技术特征E**：该多个资源定位符用于从该服务器系统检索全向或体积视频片段；

* **技术特征F**：其中，该多个资源定位符中的每个资源定位符与为该场景定义的固定捕获设备位置相关联；

* **技术特征G**：其中，该视频处理设备被配置为将该用户的位置与该清单文件中为该场景定义的第一固定捕获设备位置相关联；

* **技术特征H**：以使用来自该清单文件的第一资源定位符检索与该第一固定捕获设备位置相关联的第一预渲染全向或体积视频片段。

---

### 二、 对比文件原文深度拆解与特征比对表格

在专利无效宣告程序中，对比文件的认定必须严格基于原文公开的内容（包括明确记载的内容和本领域技术人员能直接、毫无疑义确定的内容）。

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

* **D1**：`US20190014350A1`（公开日：2019-01-10）—— *ENHANCED HIGH-LEVEL SIGNALING FOR FISHEYE VIRTUAL REALITY VIDEO IN DASH*

* **D2**：`JP2019022176A`（公开日：2019-02-07）—— *ユーザ状態及び複雑度によってビットレートを決定するコンテンツ配信装置、システム、プログラム及び方法*

* **D3**：`US20190104316A1`（公开日：2019-04-04）—— *Client-Based Adaptive Streaming of Nonlinear Media*

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

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

##### （1）D1 (US20190014350A1)

* **公开的技术特征**：A, D, E。

* **原文详细出处**：

* **特征A**：段落[0008]记载：“An apparatus configured to process a file including video data, the apparatus comprising... one or more processors... configured to process the manifest file...”。

* **特征D、E**：段落[0041]记载：“1) A DASH client obtains the MPD... as well as the URLs of the HTTP resources... 2) ... requests the desired representation(s), one segment... at a time.”；段落[0115]明确视频为360度全景视频（omnidirectional video）。

* **未公开的内容**：特征B、C、F、G、H。D1的核心发明点在于DASH中鱼眼全景视频（fisheye VR video）的高层信令扩展（如FVI descriptor、view_dimension_idc），其清单文件仅描述视频的编码参数、视角类型（单目/立体），完全没有在清单文件中定义“场景中的固定捕获设备位置”并与URL绑定，更无用户位置匹配逻辑。

##### （2）D2 (JP2019022176A)

* **公开的技术特征**：A, C（实质公开）, D, E, G（实质公开）, H（实质公开）。

* **原文详细出处**：

* **特征A、D、E**：段落[0007]、[0043]-[0053]记载了客户端（HMD2）通过通信控制部211利用HLS或MPEG-DASH协议接收清单文件，并根据URL请求切分好的全景视频段（セグメントファイル）。

* **特征C（实质公开）**：段落[0057]-[0064]记载：“視点映像生成部11は...当該メッシュの代表点(本実施形態では中心点)(ui, vi)毎に、当該中心点を視点位置としてパノラマ画像を切り出す...エンコード(符号化)処理を行い、パノラマ映像を生成する”。这公开了服务器预先在虚拟空间的固定网格中心点（即固定捕获/视点位置）生成全景视频片段。

* **特征G、H（实质公开）**：段落[0085]-[0089]及段落[0098]-[0101]记载：HMD2获取现实世界中的位置（如GPS位置RA、RB），发送给服务器/客户端，系统将该用户位置转换为虚拟空间中的位置A、位置B（匹配到对应的网格中心点），并根据该位置决定/检索对应的全景视频片段（パノラマ映像）。

* **未公开的内容**：特征B、F。D2虽然在后台算法中实现了“将用户位置映射到网格中心点并调取对应全景视频”，但D2**并未公开将“多个固定捕获设备位置”显式写入清单文件（Manifest/MPD）中**，也未公开“清单文件中的资源定位符（URL）直接与该清单文件中定义的固定捕获设备位置显式关联（特征F）”。D2的URL是传统的DASH/HLS Segment URL，其位置映射是在服务端/客户端业务逻辑层完成的，而非通过Manifest文件语法结构直接传递。

##### （3）D3 (US20190104316A1)

* **公开的技术特征**：A, D, E。

* **原文详细出处**：

* **特征A、D、E**：段落[0019]、[0036]、[0065]记载：客户端（HAS client）接收包含媒体结构的Manifest文件（MPD），通过segment identifiers（URLs）向网络节点请求传输全向/360度视频Segment。

* **未公开的内容**：特征B、C、F、G、H。D3解决的是非线性媒体（Nonlinear Media，如分支剧情/交互式视频）的自适应流传输。D3在MPD中引入了`SpatialPlaybackRegion`（空间播放区域，见段落[0075]-[0088]及表1-3），但该“区域”指的是**视频图像画面/球面上的视角兴趣区（ROI/Viewport）**（例如用户看向画面中的某扇门），当用户视线落在该区域时触发跳转到下一个Period，**这与目标专利中“场景中定义的固定捕获设备位置（摄像机机位位置）”以及“用户物理/虚拟空间位置的关联”具有本质区别**。

---

### 三、 整体解决的技术问题与技术效果分析及最接近对比文件选择

#### 1. 目标专利整体解决的技术问题与技术效果

* **技术问题**：在流式传输预渲染的全向或体积视频（如VR/AR 3D场景）时，如何在清单文件（Manifest）层面实现轻量化、标准化的机位位置描述与资源寻址，从而降低客户端渲染负担，并快速根据用户位置切换匹配的视频流。

* **技术效果**：通过将固定捕获位置及其对应的资源定位符（URL）直接封装在清单文件中，使得客户端仅凭解析清单文件即可完成“用户位置 -> 捕获机位 -> 视频URL”的快速映射与检索，极大地简化了客户端与服务端的交互逻辑，降低了时延。

#### 2. 最接近对比文件的选择与分析

**结论：D2 (JP2019022176A) 是最适合作为最接近的对比文件（D1/D3均不适合作为第一对比文件）。**

* **选择D2的理由**：

1. **技术领域与场景高度重合**：D2同样关注基于用户位置（GPS/虚拟位置）动态传输匹配视点/位置的全景视频（パノラマ映像），解决传输带宽与位置连动VR体验的问题（段落[0011],[0018]）。

2. **技术特征重合度最高**：D2已经公开了特征A、C、D、E、G、H的绝大部分实质内容（预渲染固定网格视点视频、用户位置映射、根据位置检索视频片段）。

3. **技术问题最为接近**：D2与目标专利均致力于解决“如何根据移动用户的空间位置，高效提供对应位置的预渲染全景/VR视频流”。

* **排除D1/D3作为最接近对比文件的理由**：

* **D1**仅涉及鱼眼视频在DASH中的参数信令（如视角维度、通道Flag），完全不涉及“位置映射”或“基于位置的视频检索”，技术方案偏离较大。

* **D3**虽然在MPD中扩展了空间语法（`SpatialPlaybackRegion`），但其控制逻辑是“视线方向（Gaze/Viewport）触发分支剧情”，属于交互视频领域，不涉及“用户空间位置与固定摄像机捕获位置的映射”。

---

### 四、 创造性分析（区别特征、结合关系与最薄弱特征指出）

基于以 **D2** 为最接近的对比文件（D1）：

#### 1. 目标专利权利要求1相对于D2的区别特征

通过上述拆解，权利要求1相对于D2的区别特征为：

* **区别特征1（对应特征B及部分F）**：清单文件至少包括为场景定义的多个固定捕获设备位置，且资源定位符中的每个资源定位符与该清单文件中定义的固定捕获设备位置相关联（即：**固定捕获位置作为清单文件的数据项被显式定义，并与URL直接绑定**）。

* **区别特征2（对应部分G）**：视频处理设备被配置为将用户位置与**该清单文件中**为该场景定义的第一固定捕获设备位置相关联（即：**位置匹配逻辑是直接基于清单文件内的数据项进行的**）。

#### 2. 区别特征是否被其他对比文件（D1、D3）公开？

* **D1是否公开？** 未公开。D1仅公开了相机物理参数（如圆心坐标、焦距、yaw/pitch/roll），未公开在清单文件中定义场景内的多个固定捕获位置并与URL关联。

* **D3是否公开？** 未公开。D3在MPD中定义了`SpatialPlaybackRegion`，但如前所述，D3定义的是“画面内的2D/球面像素区域（ROI）”，用于视线碰撞检测，**不是“场景中的固定捕获设备位置（Camera Location）”**，二者概念完全不同。

#### 3. 无效请求中最薄弱的技术特征（专利权的防线）

在提起无效宣告请求时，专利权人最容易防御、请求人**最薄弱的技术特征**是：

> **“在清单文件（Manifest file）中直接定义多个固定捕获设备位置，并使资源定位符（URL）与清单文件中的固定捕获设备位置显式关联（特征B + 特征F的部分）”**。

* **薄弱原因分析（对请求人而言）**：

* 现有技术（如D2）虽然在**后台算法/业务逻辑层**实现了“位置 -> 视点 -> 视频片段URL”的映射，但这种映射是硬编码在服务器/客户端的私有协议或APP逻辑中的。

* 目标专利将这一映射关系**“数据化、标准协议化”**，直接写进了DASH/HLS的清单文件（Manifest）数据结构中。

* 审查指南中，将私有后台逻辑改写为标准Manifest文件字段，如果缺乏明确的技术教导（Showing teaching），常被认定为“具有非显而易见的改进（产生了标准化、通用化的技术效果）”。现有的D1、D2、D3均未给出“将场景捕获机位坐标写入DASH Manifest/MPD结构”的明确教导。

---

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

为了成功无效权利要求1，必须突破上述“最薄弱特征”（即：**在MPD/Manifest中定义相机机位/捕获位置坐标**）。建议采取以下补充检索策略：

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

* **主题词组合1（标准扩展类）**：

* `(Manifest OR MPD OR "Media Presentation Description" OR "playlist")`

* AND `("camera position" OR "capture location" OR "camera location" OR "viewpoint location" OR "fixed location")`

* AND `(URL OR URI OR "resource locator" OR Segment)`

* **主题词组合2（VR/自由视角/6DOF传输类）**：

* `("Free Viewpoint Video" OR FVV OR "6DOF" OR "Volumetric Video" OR "Omnidirectional")`

* AND `(DASH OR HLS OR "streaming")`

* AND `("manifest" OR "MPD")` AND `("position" OR "coordinate")`

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

* **H04N 21/84**：与媒体内容相关的元数据（Metadata associated with the content）。

* **H04N 21/218**：源自多个摄像机的媒体流处理（Media stream processing derived from multiple cameras）。

* **H04N 21/845**：流媒体分段/Chunk描述（Structuring of the media stream, e.g. segmenting）。

* **H04N 13/00 / H04N 21/472**：立体/3D/VR视频的交互式传输。

#### 3. 极具有希望的“非专利文献（NPL）”检索方向（重点推荐）

由于该技术高度依赖于标准演进，**3GPP 和 MPEG（ISO/IEC JTC1/SC29/WG11）的标准提案文稿（Contributions）** 是寻找该区别特征的最佳突破口：

1. **MPEG OMAF (Omnidirectional Media Format - ISO/IEC 23090-2) 2nd Edition / Phase 2 提案**：

* 重点检索 2017–2019 年间关于 **6DOF（Six Degrees of Freedom）** 和 **Timed Metadata / MPD extensions for camera positions** 的提案。

* 例如：MPEG提案中关于“Camera position signaling in MPD”、“Multi-view / Multi-camera DASH streaming”的讨论文稿。

2. **IEEE / ACM 顶级会议论文**：

* 检索 *ACM MMSys (Multimedia Systems Conference)*, *IEEE VR*, *ACM TVX* 中关于 “6DOF VR Streaming”、“Viewport/Position-aware DASH streaming” 的论文（2016-2018年）。

作为一名经验丰富的专利代理师，我将紧密结合目标专利的技术背景与流媒体传输技术演进，对权利要求1进行深度的特征拆解与技术解释，并结合对比文件D1、D2、D3的原文及出处进行严谨的创造性与无效可行性分析。

### 一、 权利要求解释与技术方案拆解

在进行特征比对前，首先结合全景（全向）及体积视频（Volumetric Video）的流媒体传输技术背景，对权利要求1中的关键术语及整体技术方案进行法律与技术层面的精准解释：

1. **固定捕获设备位置（Fixed Capture Device Locations）**：这是本权利要求的核心概念。在全景视频或虚拟现实（VR）中，它指代的是**多视点/多节点（Multi-node/Multi-viewpoint）的相机采集物理坐标（如场馆中的不同机位或虚拟场景中的不同渲染视点）**。必须严格将其与用户转头带来的“视角方向（Orientation/Viewport/Gaze Direction）”相区分。本专利的核心在于将场景切分为多个空间离散的、预渲染的“机位节点”。

2. **清单文件（Manifest File）**：指在线流媒体（如DASH或HLS）中用于向客户端描述媒体分片URL、分辨率及空间关系的索引文件（如MPD文件）。

3. **将用户的位置与第一固定捕获设备位置相关联（特征G、H）**：指设备根据用户当前的**物理空间位置或虚拟位移（如6DoF下的位置移动）**，匹配最接近的相机机位（第一固定捕获设备位置），从而调用对应的资源定位符（URL）去拉取该特定角度或位置下“预渲染”好的视频分片，实现场景内的节点间导航或多视角切换。

我们将权利要求1拆解为以下8个独立的组织架构特征（特征A至特征H）：

* **技术特征A**：包括用于为用户处理用于视频流式传输的清单文件的处理器；

* **技术特征B**：该清单文件至少包括为场景定义的多个固定捕获设备位置；

* **技术特征C**：该多个固定捕获设备位置与存储在服务器系统上的预渲染全向或体积视频片段相关联；

* **技术特征D**：以及多个资源定位符；

* **技术特征E**：该多个资源定位符用于从该服务器系统检索全向或体积视频片段；

* **技术特征F**：其中，该多个资源定位符中的每个资源定位符与为该场景定义的固定捕获设备位置相关联；

* **技术特征G**：其中，该视频处理设备被配置为将该用户的位置与该清单文件中为该场景定义的第一固定捕获设备位置相关联；

* **技术特征H**：以使用来自该清单文件的第一资源定位符检索与该第一固定捕获设备位置相关联的第一预渲染全向或体积视频片段。

---

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

在本案中，我们引入三篇对比文件，并明确其公开号及核心公开内容：

* **D1：US20190141311A1** —— 《METHOD FOR TRANSMITTING 360-DEGREE VIDEO, METHOD FOR RECEIVING 360-DEGREE VIDEO...》

* **D2：US20190174150A1** —— 《Spatially Tiled Omnidirectional Video Streaming》

* **D3：US10356387B1** —— 《Bookmarking system and method in 360° immersive video based on gaze vector information》

#### 1. D1 (US20190141311A1) 毫无异议公开/实质公开的内容

D1公开了基于DASH（动态自适应流媒体）的全景（360度）视频传输与接收架构。

* **特征A、D、E**：D1明确公开了接收装置包含文件解析器、信令解码器、数据解码器和渲染器，基于DASH架构利用互联网接收并处理媒体分段。在段落 `[0040]` 提及“the overall operation of a DASH-based adaptive streaming model... ”，在 `[0107]` 明确提及“encapsulate the encoded 360-degree video data... process the data in the form of a DASH segment... A URL of each segment may be provided in order to access each segment”。这毫无异议地公开了处理器、清单文件（MPD）、资源定位符（URL）及检索全景视频片段的架构。

* **关于特征B、C、F、G、H（未公开）**：D1中提及的采集和 viewport 交互（如 `[0079]`-`[0080]`, `[0093]`-`[0096]`）完全是基于**单点全景相机视角转动（3DoF：Pitch, Yaw, Roll）**，其提及的“viewport”是用户眼球或头部转动的方向（通过方向向量计算），而非用户在场景中发生**物理位置（Location/Position）改变而切换多相机位**的机制。因此，D1未公开“多个固定捕获设备位置”及与之绑定的URL切换。

#### 2. D2 (US20190174150A1) 毫无异议公开/实质公开的内容

D2引入了扩展的空间关系描述符（SRD）来优化全向视频流式传输。

* **特征A、D、E**：D2在摘要及段落 `[0018]` 明确提到“receiving... a manifest file, the manifest file comprising a plurality of tile stream identifiers... select part of omnidirectional video that corresponds to a particular viewpoint”。在 `[0060]` 提及“The tile stream identifiers (e.g. URLs) and the spatial relation... are stored in a so-called spatial manifest file 106”。毫无异议地公开了通过清单文件中的URL拉取全景视频。

* **特征B、C、F、G、H的实质审查**：D2极易在审查中被审查员用来误导对抗这些特征，因为D2提到了“viewpoint”（视点）和“3D coordinate system”（3D坐标系）。但通过细读D2原文 `[0018]` 发现：“wherein the spatial relation information defines for each tile a tile position and wherein the viewpoint defines a viewing direction of the user, tile position and the viewpoint being defined on the basis of coordinates of the 3D coordinate system.”

**代理师辩驳分析**：D2中定义的“视点（viewpoint）”实质指的是**用户的视线方向（viewing direction）**，其3D坐标系是为了给球体/圆柱体表面的全景分块（Tiles）进行三维空间定位（如Yaw和Pitch角度），其依然属于单视点360度视频内的视角自适应流传输。D2完全没有公开场景中存在“多个离散的多捕获机位位置（多个固定捕获设备位置）”，更没有公开将“用户空间位置”与“机位物理位置”相关联并拉取不同机位下预渲染片段的方案。

#### 3. D3 (US10356387B1) 毫无异议公开/实质公开的内容

D3聚焦于全景沉浸式视频中的空间书签（Bookmarking）系统。

* **公开内容**：D3公开了利用视线向量（Gaze Vector）在3D沉浸式视频空间中建立书签。如段落 `[0006]` 提及“storing a first gaze vector from the first client device relative to the current frame... create the first bookmark... contains a user ID, a resume time, and a first resume location point”。

* **比对结论**：D3公开了利用用户视角/视线在三维显示环境中的方向来保存和恢复播放状态，属于播放控制层面的交互，与流媒体清单文件中关于多个采集设备位置节点和用户位置关联的流媒体调度机制（特征B、C、G、H）毫无关联。

---

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

---

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

在对本案进行创造性审查或提起无效请求时，**D2（US20190174150A1）最适合作为唯一的或最接近的对比文件（D1也可并列作为最接近对比文件）**。原因如下：

1. **整体解决的技术问题高度一致**：D2旨在解决在**有限的网络带宽下，如何高效、低延迟地为虚拟现实（VR）用户流式传输全景/全向超高清视频**的问题（参见D2 `[0003]`-`[0004]`）。这与目标专利构建视频处理设备、处理器处理清单文件以检索全向视频的技术领域及面临的带宽瓶颈完全相同。

2. **技术架构最为接近**：D2完整搭建了客户端、清单文件（Manifest）、三维坐标系描述、处理器选择自适应流、以及通过多个URL资源定位符检索视频分片并拼装渲染的完整技术底座（参见D2 Fig.1、段落 `[0018]`、`[0034]`）。

3. **技术效果具有对抗性（容易造成表面混淆）**：D2通过扩展清单文件中的SRD描述，将视频分块映射到了“三维坐标系空间（3D coordinate system）”，并且根据用户的“Viewport（视点）”进行动态资源检索。尽管其本质是单视点的视角自适应，但在文字表述上使用了3D、坐标系、Viewpoint等词汇，在创造性审查的“三步法”第一步中，最适合作为搭建基础流媒体平台的起步点。

---

### 五、 未公开特征与最薄弱的技术特征（Weakest Technical Feature）

通过前述两节的严谨比对可以发现，目标专利相比于现有技术（D1-D3）存在着一道明显的**技术鸿沟**：

现有的VR全景流媒体传输技术（以D1、D2为代表）均建立在 **“3DoF（自由度）”** 假设上，即相机在原点不动，用户只在原地转头，清单文件描述的是球体表面不同角度的**Tiles（分块区域）**；

而目标专利的权利要求1则建立在 **“多视点导航/类似6DoF（包含位移）”** 的技术方案上，其清单文件中包含的是**多个不同的空间物理相机位置（特征B、C、F）**，并根据**用户的位置位移来切换机位（特征G、H）**。

因此，**若提出无效请求，目标专利权利要求1中“最薄弱的技术特征”（即对无效请求方而言最难攻克、最难找到现有技术直接公开的特征）是：**

> **特征G和特征H的结合体**：*“将该用户的位置与该清单文件中为该场景定义的第一固定捕获设备位置相关联；以使用来自该清单文件的第一资源定位符检索与该第一固定捕获设备位置相关联的第一预渲染全向或体积视频片段。”*

**薄弱原因（站在无效请求方的攻击难点角度）**：

即使无效请求方论证了特征A、D、E属于流媒体常规架构，且试图用D2的3D坐标系去生搬硬套特征B、C中的位置概念，但**特征G、H明确引入了“用户位置（User's Location）”作为检索条件，以此去匹配“相机位置（Capture Device Location）”，并调用绑定的URL来拉取该特定位置的“预渲染片段”**。D1-D3的整套理论全部围绕“视线方向/转头方向（Viewport/Viewing direction/Gaze Vector）”展开，没有任何一处提及根据“用户位置”去清单文件匹配“相机机位位置”。这种从“视角外设控制”向“位置位移自适应拉流”的质变，在现有D1-D3的框架下极难通过“显而易见性”进行主观推导。

---

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

鉴于D1-D3未能有效攻克上述最薄弱特征（特征G、H），若想成功无效掉权利要求1，必须调整检索策略，从单纯的“全景视频Tile分块传输”领域跳出，靶向锁定**“多视角/多视点全景流媒体导航”**及**“体积视频/虚拟导览清单自适应”**领域。建议采取以下精准检索策略：

#### 1. 核心技术特征的检索关键词精准重组

必须放弃单纯的 360 video, tile, viewport 等词，转向专门公开“多相机位置切换”的系统：

* **输入组1（多机位/多节点）**：`"multi-viewpoint 360"` / `"multi-node"` / `"camera locations"` / `"virtual tour"` / `"viewpoint switching"` / `"multi-camera selective streaming"`

* **输入组2（清单文件与位置关联）**：`"manifest"` / `"MPD"` / `"DASH extension"` / `"user location-aware"` / `"position-based streaming"` / `"pre-rendered segments"`

* **构建布尔逻辑检索式示例**：

`(360 video OR omnidirectional OR volumetric) AND (manifest OR MPD OR DASH) AND (camera location OR camera position OR multi-node) AND (user position OR user location) AND (switch* OR select* OR retrieve*)`

#### 2. 精准国际专利分类号（IPC/CPC）锁定

审查员常规检索全景视频多使用 `H04N21/2343`（传输端的格式自适应），为了切中多机位位置清单，应扩大至以下位置与多视角交互分类号：

* **H04N21/816**：专门针对虚拟现实（VR）或多通道流媒体内容的系统。

* **H04N21/4728**：允许用户选择内容的不同部分或不同视角的终端侧自适应。

* **H04N21/6587**：包含用户交互反馈（如位置移动信息反馈给服务器）的流媒体。

* **G06T15/04 / G06T19/006**：涉及虚拟三维场景中基于位置预渲染全景图（Skybox/Panoramic nodes）切换的图形处理技术。

#### 3. 目标技术源头与追溯方向

* **虚拟导览（Virtual Tour）与街景流媒体标准**：重点检索Google Street View流媒体或Matterport等3D空间扫描服务商的早期流媒体底座专利。这些系统往往在清单文件中定义了多个Spot（固定捕获点），用户在网页或VR中“点击地面位移”时，客户端利用当前虚拟位置匹配最近的机位节点，拉取预渲染好的全景切片。

* **MPEG-I（MPEG Immersive Video）标准提案追溯**：检索2020年之前提交给ISO/IEC JTC1/SC29/WG11（MPEG组织）关于3DoF+（允许有限头部物理位移的全景视频）和6DoF流媒体传输的方案或技术提案（MPEG Output Documents）。这些标准提案中关于清单文件（Metadata/Manifest）如何定义多相机空间密集阵列（Dense Camera Array）及其与用户空间坐标匹配的公开技术设计，是无效本案核心特征G、H的绝佳突破口。

作为一名经验丰富的专利代理师，我将为您对该视频处理设备的权利要求1进行深入的法律与技术解析，并结合对比文件D1（US11076162B2）与D2（WO2019043025A1）进行详尽的特征比对、最接近对比文件筛选以及后续的无效宣告策略制定。

---

### 一、 权利要求1的技术内涵解析

本申请权利要求1保护一种**“视频处理设备”**，其核心发明构思在于：**利用清单文件（Manifest File）中预先定义的“多个固定捕获设备位置（Fixed Capture Device Locations）”与用户当前的“空间位置”进行关联匹配，从而精准检索对应位置下预渲染的全向或体积视频片段。**

这种技术方案通常应用于多视点（Multi-viewpoint）或六自由度（6DoF）的全息/全向视频流式传输中。系统并不是实时渲染整个虚拟空间，也不是单纯依赖用户的视景体（Viewport）方向，而是**将空间离散化为多个固定的拍摄/渲染锚点**，清单文件建立起“位置—资源定位符（URL）—预渲染视频片段”的映射关系。当用户在空间中移动时，设备通过位置关联切换到最近的固定捕获点，从而降低客户端计算负载流式传输体积或全向视频。

---

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

#### 1. 对比文件身份定义

* **对比文件1（D1）**：US11076162B2

* **对比文件2（D2）**：WO2019043025A1

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

---

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

在创造性（Invalidity/Obviousness）分析中，**D1（US11076162B2）** 适合被选为本权利要求1的**最接近对比文件**。

#### 1. 技术领域与解决的技术问题共性

* **目标专利**：旨在解决在全向/体积视频的流式传输中，如何高效传输高数据量视频，避免客户端实时渲染的高计算负载与高网络带宽消耗。

* **D1（US11076162B2）**：其整体技术方案直接聚焦于高分辨率全景/沉浸式视频（VR 360°）在有限网络带宽下的高效自适应传输（HAS/DASH协议）。它解决的是“如何避免传输用户看不到的90%以上的全景画面，在带宽受限的情况下提供高质量沉浸式体验”的技术问题（参见D1说明书\[0006\]-\[0009\]）。这与目标专利在流媒体分发架构、清单文件（MPD）应用以及降低传输开销的大背景上最为契合。

* **D2（WO2019043025A1）**：核心侧重于全景视频的“局部画面缩放（Zooming）”以防止晕动症（Cyber sickness）。其本质上是一种视口内图像的二次形变处理（如网格畸变或多层纹理贴图），其技术主题和要解决的问题（缓解视觉不一致导致的恶心）与目标专利的“多视点空间切换”相距稍远。

#### 2. 技术效果的演进倾向

D1通过将全景空间切割为Tiles并利用清单文件引导客户端按需检索（GET请求），其达成的“降低带宽压力、按需精准调取预存储内容”的技术效果与目标专利的“基于用户当前空间位置从清单文件中精准检索预渲染视频片段”的效果具有极高的高度相似性。因此，以D1作为创造性审查的起点（最接近现有技术）符合专利审查指南的评判标准。

---

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

如果在后续程序中向专利局提起针对该权利要求1的无效请求，**最薄弱（即专利权人最难辩驳、最容易被现有技术突破）的技术特征是：特征A、D、E**。这些特征属于流媒体传输（如MPEG-DASH/Omaf标准）的公知常识组合，已被D1完全毫无异议地实质公开。

然而，**目标专利最坚固（即对请求人而言最难攻克）的核心发明点在于特征B、F、G、H的组合**，即：

1. 清单文件中包含“**固定捕获设备位置**”这一数据维度。

2. 设备将“**用户的位置**”（三维空间坐标/物理位置）而非“用户的视线方向”与该捕获点相关联。

#### 对手防线分析（未被公开特征的穿透可能性）：

经审查，**最接近对比文件D1未公开的特征（B, F, G, H），同样没有被D2公开。**

* D1和D2的技术核心依然束缚在三自由度（3DoF）或局部图像处理的框架内——即用户站在固定原点，仅能做偏航、俯仰、翻滚（Yaw, Pitch, Roll）的旋转操作，系统响应的是视线方向。

* 权利要求1则跨越到了**六自由度（6DoF）或多视点自由选择**的场景，响应的是用户在空间中的位移（Translation/Location）。

因此，如果仅仅依靠目前的D1和D2组合，由于**缺乏关于“将空间绝对位置写入视频流清单文件（MPD），并基于用户空间位移映射对应的URL以切换预渲染视频”的技术启示**，直接宣告权利要求1无效的成功率较低。

---

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

鉴于目前的D1和D2尚未触及核心区别特征（基于空间位置的清单文件映射），为了成功切断该权利要求的创造性链条，建议调整并启动以下第二阶段检索策略：

#### 1. 调整检索关键词与分类号

当前案子的本质是**6DoF视频/点云体积视频/多视角流媒体（Multi-view streaming）**的传输优化。

* **增加关键词**：6DoF, Free-viewpoint video (自由视角视频), Multi-viewpoint, Volumetric video (体积视频), Point cloud streaming, Viewpoint adaptive streaming, Camera position grid (相机位置网格), MPEG-I V-PCC/MIV (MPEG-I多视角视频标准)。

* **聚焦IPC/CPC分类号**：

* `H04N21/81`（特殊的流媒体内容，如3D/VR）

* `H04N21/2343` 或 `H04N21/4402`（涉及流媒体格式转换/自适应流）

* `G06T15/00`（三维图像渲染与空间切片相关）

#### 2. 锁定特定标准提案与技术文献（关键突破口）

既然该权利要求中大量使用了“清单文件（Manifest file）”、“资源定位符（Resource Locators）”等HAS（基于HTTP的自适应流）术语，说明其极有可能是在国际标准化组织（如**3GPP**或**MPEG**）制定**6DoF/MPEG-I沉浸式媒体分发标准**期间衍生的技术专利。

* **检索方向**：重点检索2018年至2023年期间，MPEG工作组关于**MPEG-I Part 12 (Omnidirectional Media Format v2 / OMAF v2 多视角扩展)** 以及 **MPEG-I Part 4 (Video-based Point Cloud Compression / V-PCC)** 的标准提案（Contributions）。

* **预期斩获目标**：在OMAF v2的多视角（Multi-view）扩展提案中，标准专家们为了支持用户在多个相机阵列拍摄的画面间无缝走动，专门探讨过**在MPD清单文件中使用`EssentialProperty`或新的属性标签来声明各个“相机/渲染视点（Viewpoint/Capture Position）”的空间三维坐标**，从而允许客户端根据位置请求不同的流。一旦检索到这类型的标准草案或会议提案，即可作为强力证据（D3），与D1组合，彻底无效掉权利要求1。

根据权利要求1所述的视频处理设备，其中，该清单文件中的一个或多个固定捕获设备位置与观看范围相关联；在该观看范围内，该处理设备能够处理该检索到的全向或体积视频片段；以为该用户渲染视图。

根据权利要求1或2所述的视频处理设备，其中，该视频处理设备被配置为为该用户生成合成视图或接收生成的合成视图；其中，该合成视图是基于至少该检索到的第一预渲染全向或体积视频片段的一个或多个帧而生成的；并且其中，该合成视图是进一步基于以下各项中的至少一项生成的：当该用户的位置对应于为该场景定义的第一固定捕获设备位置时，该场景的与该第一固定捕获设备位置相关联的一部分的模型描述；以及当该用户的位置对应于为该场景定义的第一固定捕获设备位置时，针对为该场景定义的第二固定捕获设备位置使用与该第二固定捕获设备位置相关联的第二资源定位符检索的第二全向或体积视频片段的一个或多个帧；以及当该用户的位置不对应于为该场景定义的第一固定捕获设备位置时，该检索到的第一预渲染全向或体积视频片段的一个或多个帧。

根据权利要求3所述的视频处理设备，其中，该清单文件定义与该第一资源定位符相关联的第一固定捕获设备位置和与第二资源定位符相关联的第二固定捕获设备位置；并且其中，当该用户的位置不对应于为该场景定义的第一固定捕获设备位置时，该视频处理设备被配置为使用与该清单文件中的第二固定捕获设备位置相关联的第二资源定位符从该服务器系统检索至少一个第二全向或体积视频片段；并且基于该检索到的第一全向或体积视频片段和第二全向或体积视频片段的一个或多个帧为该用户生成合成视图。

根据权利要求3所述的视频处理设备，其中，该清单文件定义对组合使用第一视频片段 and 第二视频片段的帧来生成该合成视图的禁例；其中，可选地，该禁例是该清单文件中的边界类型元素；该边界类型元素指示该视频处理设备组合或不组合该第一视频片段和该第二视频片段或其帧来生成该合成视图。

根据权利要求3所述的视频处理设备，其中，该视频处理设备被配置为至少检索该场景的模型描述的与该清单文件中的至少一个固定捕获设备位置相关联的一部分；并且其中，该视频处理设备进一步被配置为基于该第一预渲染全向或体积视频片段的至少一个或多个帧和模型描述的至少该检索到的部分来为该用户生成该合成视图。

根据权利要求1-2中任一项所述的视频处理设备，其中，该清单文件定义允许该用户在其中移动的区域或体积；并且其中，该视频处理设备使用所述区域或体积作为导航空间指示。