非显而易见性评估仅供参考,不构成法律建议。
| 编号 | 名称 |
|---|---|
| 0 | 2015-07-23_US2015208095A_发明申请_US20150208095A1 VIDEO DATA STREAM CONCEPT_+++A_B_C_D_E_F_G_H+++.docx |
| 0 | US4315878A_Description_20260704_0100.docx |
| 0 | 2017-04-20_None_发明专利_JPWO2015190463A1 含フッ素塗膜の耐候性評価方法.docx |
| 0 | 2016-09-01_US2016255354A_发明申请_US20160255354A1 IMAGE DECODER, IMAGE ENCODER, AND ENCODED DATA CONVERTER_+++A_B_C_D_E_F_G_H_N_O_P_R_S_T+++.docx |
| 0 | 2016-05-12_US2016135321A_发明申请_US20160135321A1 ELECTRONIC DEVICE.docx |
| 0 | 2016-04-14_US2016105690A_发明申请_US20160105690A1 DESCRIPTION OF IMAGE COMPOSITION WITH HEVC STILL IMAGE FILE FORMAT_+++A_B_C_D_E_F_G_H+++.docx |
| 0 | 2016-01-07_WO2016002496A_发明申请_WO2016002496A1 情報処理装置および方法_+++A_B_C_H_d_e_f_g_s_t+++.docx |
| 0 | 2015-12-30_WO2015197818A_发明申请_WO2015197818A1 HEVC-TILED VIDEO STREAMING_+++A_B_C_M_O_P_S_T_d_e_f_g_n_q_r+++.docx |
| 0 | 2015-07-23_US2015208103A_发明申请_US20150208103A1 System and Method for Enabling User Control of Live Video Stream(s)_+++A_C_b_d_e_f_g+++.docx |
| 0 | 2001-05-25_JP2001145022A_发明专利_JP2001145022A Bit stream switching system_+++A+++.docx |
| 0 | 2015-07-16_US2015201202A_发明申请_US20150201202A1 METHOD OF GENERATING MEDIA FILE AND STORAGE MEDIUM STORING MEDIA FILE GENERATION PROGRAM_+++A_B_C_D_E_F_G_H_o_p+++.docx |
| 0 | 2015-04-16_US2015103926A_发明申请_US20150103926A1 VIDEO ENCODING AND DECODING_+++A_B_C_D_E_F_G_H+++.docx |
| 0 | 2015-01-29_WO2015011108A_发明申请_WO2015011108A1 METHOD, DEVICE, AND COMPUTER PROGRAM FOR ENCAPSULATING PARTITIONED TIMED MEDIA DATA USING SUB-TRACK FEATURE_+++A_B_C_D_E_F_G+++.docx |
| 0 | 2015-01-22_US2015023407A_发明申请_US20150023407A1 IMAGE DECODING DEVICE, IMAGE DECODING METHOD, IMAGE ENCODING DEVICE, AND IMAGE ENCODING METHOD_+++A_B_C_G_H_d_e_f+++.docx |
| 0 | 2014-10-16_US2014307775A_发明申请_US20140307775A1 METHOD AND DEVICE FOR PARTITIONING AN IMAGE_+++A_B_C_D_E_F_G_H+++.docx |
| 0 | 2013-04-25_US2013101035A_发明申请_US20130101035A1 GROUPING OF TILES FOR VIDEO CODING_+++A_B_C_D_E_H_f_g+++.docx |
| 0 | 2012-06-26_US8208790B_发明授权_US08208790B2 Recording medium, reproducing device, encoding device, integrated circuit, and reproduction output device_+++A_B_C_D_E_F_G_H_K_a_b_c_d_e_f_g_h_i_j_k_l_m_n_o_p_q_r_s_t_u_v_w_x_y_z+++.docx |
| 0 | 2010-06-24_WO2010069427A_发明申请_WO2010069427A1 METHOD AND ENCODER FOR PROVIDING A TUNE- IN STREAM FOR AN ENCODED VIDEO STREAM AND METHOD AND DECODER FOR TUNING INTO AN ENCODED VIDEO STREAM_+++A_D_H_b_c_e_f_g+++.docx |
一种解码来自第一视频流的编码视频数据的方法,所述第一视频流包括基于视频编解码器编码的视频图像;所述视频图像具有图像区域并被分成独立可解码切片的空间阵列;空间阵列与第一图片大小相关联;第一视频流包括网络抽象层单元;每个网络抽象层单元包含切片中的相应切片的视频内容数据;所述视频内容数据的前面是报头;所述报头包括与和第一视频流相关的切片中的相应切片相关的参数;所述方法由解码器装置执行;所述方法包括将针对切片的子阵列的网络抽象层单元部分地重写为重写的网络抽象层单元;网络抽象层单元在相应的网络抽象层单元中的每个中的位置处被重写;所述位置位于所述报头中;其中所述位置是基于元数据来选择的;所述位置包括一个或多个切片的空间位置的指示;重写的网络抽象层单元形成包括仅切片的子阵列的编码视频数据的第二视频流;所述编码视频数据表示包括所述图像区域的子区域的部分视频图像;其中所述重写的网络抽象层单元基于所述视频编解码器可解码成所述部分视频图像;和/或从针对不同子阵列大小的网络抽象层单元的多个不同版本选择针对切片的子阵列的网络抽象层单元的版本;解码重写的网络抽象层单元;所述解码基于与所述子阵列相关联的第二图片大小来执行;其中所述第二图片大小小于所述第一图片大小。
### 一、 目标专利权利要求与对比文件特征比对
对比文件为 **D1(US8208790B2)**,授权公告日为2012年6月26日。
以下为权利要求1的技术特征与D1原文的比对表及详细分析:
#### 1. 特征比对表
| 权利要求1技术特征 | D1(US8208790B2)比对分析与原文出处 | 比对结论 |
| 技术特征A:所述第一视频流包括基于视频编解码器编码的视频图像 | 公开。对应D1中的base-view video stream(如MPEG-4 AVC/MVC编码)。 | 完全公开 |
| 技术特征B:所述视频图像具有图像区域并被分成独立可解码切片的空间阵列 | 部分公开/实质区别。D1公开了图片分为多个Slice(切片),但D1中的切片是“通常水平排列的带状区域”,并未公开“独立可解码切片的空间阵列(Spatial Array)”(如Tile或Tile Grid架构)。 | 存在区别特征 |
| 技术特征C:空间阵列与第一图片大小相关联 | 未公开。因D1未公开切片的空间阵列,故未公开其与第一图片大小(First Picture Size)的关联。 | 未公开 |
| 技术特征D:第一视频流包括网络抽象层单元 | 公开。D1明确公开在MPEG-4 AVC/MVC中,VAU的各组件由NAL Unit(网络抽象层单元)组成。 | 完全公开 |
| 技术特征E:每个网络抽象层单元包含切片中的相应切片的视频内容数据 | 公开。D1公开切片数据存储于Slice NAL Unit(View Component)中。 | 完全公开 |
| 技术特征F:所述视频内容数据的前面是报头 | 公开。D1公开切片数据前面附有Slice Header(切片报头)。 | 完全公开 |
| 技术特征G:所述报头包括与和第一视频流相关的切片中的相应切片相关的参数 | 公开。D1公开Slice Header包含参考图像号、PPS ID等参数。 | 完全公开 |
| 技术特征H:所述方法由解码器装置执行 | 公开。D1公开该方法由Playback Device中的Decoder/System Target Decoder执行。 | 完全公开 |
| 技术特征I:将针对切片的子阵列的网络抽象层单元部分地重写为重写的网络抽象层单元 | 未公开/原理不同。D1采用的是3D/2D流的多路复用与提取(如从Extent SS中抽取Base/Dependent View),并非在解码器端对NAL单元的报头位置进行动态“部分重写(partially rewriting)”。 | 存在核心区别特征 |
| 技术特征J:网络抽象层单元在相应的网络抽象层单元中的每个中的位置处被重写 | 未公开。D1无重写NAL Unit内部位置的教导。 | 未公开 |
| 技术特征K:所述位置位于所述报头中 | 未公开。 | 未公开 |
| 技术特征L:其中所述位置是基于元数据来选择的 | 实质不同。D1中有SEI/Metadata(如Offset Metadata),但用于控制图形叠加(Offset Control),而非用于“选择报头中被重写的位置”。 | 未公开 |
| 技术特征M:所述位置包括一个或多个切片的空间位置的指示 | 未公开。 | 未公开 |
| 技术特征N:重写的网络抽象层单元形成包括仅切片的子阵列的编码视频数据的第二视频流 | 未公开。D1形成第二流(如Sub-TS或Dependent Stream)是通过解复用(Demultiplexing),而非通过重写切片子阵列的NALU来构建新视频流。 | 未公开 |
| 技术特征O:所述编码视频数据表示包括所述图像区域的子区域的部分视频图像 | 实质不同。D1的Sub-view/Dependent-view表示立体3D的另一视角或深度图,而非对单张大图进行空间裁剪/ROI提取所得的“图像区域的子区域(Partial Video Image)”。 | 存在区别特征 |
| 技术特征P:重写的网络抽象层单元基于视频编解码器可解码成部分视频图像 | 未公开。 | 未公开 |
| 技术特征Q:和/或从针对不同子阵列大小的网络抽象层单元的多个不同版本选择针对切片的子阵列的网络抽象层单元的版本 | 未公开。 | 未公开 |
| 技术特征R:解码重写的网络抽象层单元 | 实质不同。D1解码的是MVC依赖流/主流,而非解码“重写的NALU”。 | 存在区别特征 |
| 技术特征S:所述解码基于与所述子阵列相关联的第二图片大小来执行 | 未公开。D1中Base View与Dependent View的分辨率/图片大小必须完全一致(Match)。 | 存在区别特征 |
| 技术特征T:其中所述第二图片大小小于所述第一图片大小 | 未公开。D1不支持解码图像尺寸小于原始流图像尺寸的子区域解码机制。 | 未公开 |
---
### 二、 最接近对比文件分析与技术问题/效果评估
#### 1. 对比文件定位分析
* **D1(US8208790B2)** 解决的技术问题是:**如何在同一存储介质上高效存储与解复用3D立体视频 stream(Base View 与 Dependent View/Depth Map)以及图形叠加层,并保持与2D播放设备的兼容性。**
* **本目标专利** 解决的技术问题是:**如何从高分辨率/大尺寸视频流中,提取并解码特定空间区域(ROI,Region of Interest/子阵列),实现轻量化、低带宽的局部视频(ROI)解码,同时保持编解码器兼容性。**
#### 2. 结论
* **D1不适合作为最接近的对比文件**(或仅能作为证明通用AVC/NALU架构的背景技术)。
* **原因**:D1的技术领域属于**3D/MVC立体视频多路复用与字幕偏移控制**,而本专利属于**基于空间切片阵列(如 HEVC Tile / Motion-Constrained Tile Sets, MCTS)的局部视频抽取与报头重写(Header Rewriting)技术**。D1缺失了目标专利关于“空间切片阵列、报头位置重写、子图片尺寸缩小解码”等绝大多数核心发明点(特征B, C, I, J, K, L, M, N, O, P, Q, S, T)。
---
### 三、 无效请求中最薄弱的技术特征分析
若针对目标专利权利要求1提出无效宣告请求,目前基于D1**极难成立创造性结合**。本专利中最薄弱(即最容易被传统技术公知或攻破)与最坚固的技术特征如下:
1. **最薄弱的技术特征(极易被公知技术覆盖)**:
* **特征A, D, E, F, G, H**:这些属于标准MPEG-4 AVC / HEVC编解码器的基础NALU结构和切片报头规范。
2. **核心防线/最坚固的技术特征(本专利的专利性内核)**:
* **特征I + J + K + L + M(报头位置动态重写机制)**:解码器根据元数据,定位切片报头中的特定位置并进行重写,从而将大图的切片改变为符合小图规范的切片。
* **特征S + T(基于小于第一图片大小的第二图片大小进行重写后解码)**:将全景/大图流(第一尺寸)裁切为ROI子区域流(第二尺寸),并使标准解码器误以为这是一个独立的低分辨率视频流而直接解码。
---
### 四、 进一步的对比文件检索策略
为了有效无效目标专利权利要求1,必须调整检索方向,脱离3D/MVC领域,转向 **HEVC Tile / MCTS(运动约束切片组)/ VR全景视频(360-degree Video)ROI局部解码与流重写** 技术。
#### 1. 核心检索要素提取(Keywords & CPC/IPC)
* **核心概念1(空间切片阵列)**:Tile, Tile Grid, Spatial Array, Slice Group, MCTS (Motion-Constrained Tile Sets).
* **核心概念2(报头重写/流重写)**:Header rewriting, NAL unit rewrite, Bitstream rewriting, Slice header modification, Parameter set modification (SPS/PPS rewrite).
* **核心概念3(局部解码/ROI/小尺寸)**:ROI (Region of Interest), Sub-picture, Partial decoding, Viewport-dependent streaming, Cropping, Picture size reduction.
#### 2. 推荐检索分类号(CPC/IPC)
* **H04N19/167**:基于感兴趣区域(ROI)的视频编码/解码。
* **H04N19/597**:立体或多视图视频(若涉及 Tile 组合)。
* **H04N19/174**:基于 Slice(切片)的编码/解码。
* **H04N19/172 / H04N19/119**:基于图像分割/Tile 的编码。
* **H04N21/8456**:流媒体中的分段/Tile传输。
#### 3. 针对性的检索策略与标准文档源
1. **标准化组织(JCT-VC / MPEG / ITU-T)提案检索(最强对比文件来源)**:
* 检索 **JVET** 或 **JCT-VC** 关于 **MCTS (Motion-Constrained Tile Sets)** 和 **HEVC Tile Extraction / Rewriting** 的提案(约在 2013年–2017年 期间)。
* 重点关注 **"Tile Extractor"**, **"Bitstream extractor for MCTS"**, **"VR Viewport extraction by rewriting slice headers/PPS"** 的技术提案。
2. **专利数据库组合检索式示例**:
* `(HEVC OR H.265 OR NALU OR "slice header") AND (rewrite OR rewriting OR modify OR modified) AND (tile OR "spatial array") AND ("picture size" OR ROI OR "region of interest" OR viewport)`
3. **关键技术逻辑匹配**:寻找在一篇对比文件(如HEVC MCTS提取器专利)中公开了“接收全尺寸Tile流 -> 提取部分Tile -> 重写Slice Header/PPS中的Tile位置与Picture大小 -> 送入标准解码器解码为小尺寸视频”的完整流程。
这是一份立足于专利诉讼与无效宣告实务的专业法律与技术分析报告。
---
## 一、 权利要求1的技术特征拆解与说明书原意解释
权利要求1记载的是一种在解码器端通过重写NAL单元报头(Header),从而实现切片(Slice)子阵列(ROI区域)独立提取与解码的方法。结合目标专利的技术背景,其核心机制在于:**解码器不需要将整个大图解码,而是通过提取并重写元数据中的位置指示,生成仅包含目标子区域(ROI)的第二视频流,并按缩小后的“第二图片大小”进行解码。**
### 权1技术特征拆解及说明书原意解释:
* **技术特征A~C(输入流的基本特征):**
* **A:** 第一视频流包含基于视频编解码器编码的视频图像;
* **B:** 视频图像具有图像区域并被分成**独立可解码切片(independent decodable slices)的空间阵列**;
* **C:** 空间阵列与**第一图片大小(First picture size,即原始全图分辨率)**相关联。
* *说明书解释*:指原始高分辨率/全景视频流,图像被划分为网格状的独立切片阵列。
* **技术特征D~G(NAL单元结构特征):**
* **D:** 第一视频流包括网络抽象层单元(NAL Unit);
* **E:** 每个NAL单元包含切片中的相应切片的视频内容数据(Slice Payload);
* **F:** 视频内容数据的前面是报头(Header);
* **G:** 报头包括与和第一视频流相关的切片中的相应切片相关的参数(如坐标、切片地址、序列/图像参数集引用等)。
* *说明书解释*:遵循标准视频语法(如H.264/HEVC/VVC),NAL单元的头部携带用于定位该切片在全图位置的参数。
* **技术特征H(执行主体):**
* **H:** 方法由解码器装置执行。
* **技术特征I~M(NAL单元重写核心特征):**
* **I:** 将针对切片的**子阵列(Sub-array,即子图像/ROI)**的网络抽象层单元**部分地重写(partially rewrite)**为重写的网络抽象层单元;
* **J~K:** 并在相应的网络抽象层单元中的**报头(Header)位置**处进行重写;
* **L~M:** 重写位置是**基于元数据(Metadata)选择**的,该位置包括一个或多个切片的空间位置指示。
* *说明书解释*:解码器(或流提取器)在解码前,不改变Slice Payload,仅修改NAL报头中的地址/位置参数,使子阵列切片在新的子视频流中能够重新排列拼合。
* **技术特征N~P(重写后的第二视频流特征):**
* **N:** 重写的NAL单元形成包括**仅切片子阵列**的编码视频数据的**第二视频流**;
* **O:** 第二视频流表示包括图像区域的子区域的部分视频图像;
* **P:** 重写的NAL单元基于视频编解码器可解码成部分视频图像。
* **技术特征Q(版本选择分支):**
* **Q:** 和/或从针对不同子阵列大小的网络抽象层单元的多个不同版本选择针对切片的子阵列的网络抽象层单元的版本。
* **技术特征R~T(第二图片大小解码特征):**
* **R:** 解码重写的网络抽象层单元;
* **S:** 解码基于与子阵列相关联的**第二图片大小(Second picture size,即ROI子图的分辨率)**来执行;
* **T:** **第二图片大小小于第一图片大小**。
* *说明书解释*:解码器重新配置图像缓冲和显示参数,使解码器将子阵列直接作为一张独立的完整小图(第二图片大小)进行渲染解码,而非将其作为大图的一部分解码后裁切。
---
## 二、 对比文件特征比对与公开性分析
以下对比文件采用各自官方公开号指代:
* **D1:** JP2001145022A
* **D2:** WO2010069427A1
* **D3:** US20130101035A1
### 1. 详细特征比对表
| 权利要求1技术特征 | D1 (JP2001145022A) | D2 (WO2010069427A1) | D3 (US20130101035A1) |
| A:第一视频流包含编码视频图像 | 公开 [0002] MPEG2符号化 | 公开 [p0005] H.264/MPEG-2流 | 公开 [0003] HEVC/H.264视频流 |
| B:切片的空间阵列 | 未公开(仅提及GOP/Frame结构) | 未公开(仅提及1D/水平Slice [p0018]) | 公开 [0037]-[0038] 图像划分为Tile网格阵列 |
| C:第一图片大小 | 公开 [0003] HDTV/SDTV图像大小 | 公开 [0064] 1280x720 原始分辨率 | 公开 [0037] 包含全图的LCU阵列尺寸 |
| D~F:NAL单元及报头/内容 | 隐式公开(MPEG2 TS包头与Payload) | 公开 [p0042] H.264 NAL Unit结构 | 公开 [0041]-[0042] NAL Unit结构 |
| G:报头包含切片参数 | 部分公开 [0020] GOP Header | 公开 [p0020] Slice Header参数 | 公开 [0124] SPS/PPS/Slice Header参数 |
| H:解码器执行 | 公开 [0003] 接收机/解码器 | 公开 [p0040] 解码器装置400 | 公开 [0047] 解码器34 |
| I~K:报头部分重写 | 未公开 | 未公开(D2采用流拼接Splicing,非重写Header) | 实质公开 [0061],[0080],[0100] 封装单元/解码器改写Tile/Slice报头及语法 |
| L~M:基于元数据的重写位置指示 | 未公开 | 未公开 | 实质公开 [0124],[0138]-[0139] 基于SPS/PPS/TileGroupMap元数据定位Tile地址 |
| N~P:生成第二视频流(仅包含子阵列切片) | 未公开 | 未公开 | 公开 [0075]-[0076] 提取ROI Tile生成独立可解码子视频流 |
| Q:选择不同版本 | 未公开 | 公开 [p0012],[p0016] 针对不同分辨率选择SIDE Stream/TIP版本 | 未公开 |
| R~T:基于较小的第二图片大小解码 | 未公开 | 未公开 | 实质公开 [0075],[0143] 重新配置解码器按ROI子图尺寸/LCU范围解码 |
---
### 2. 各对比文件原文出处与详细比对分析
#### (1) 对比文件1:D1 (JP2001145022A)
* **比对分析**:D1公开了一种MPEG-2视频码流切换系统,主要解决SDTV与HDTV不同格式码流切换时因GOP结构破坏导致画面闪烁(画面肖克)的问题([0003]-[0005])。其技术手段是通过切换控制装置在切替时发送同步触发信号,使切替源和切替 destination 的编码器GOP相位一致,并在GOP头/I帧处进行切替([0009]-[0010], [0018])。
* **比对结论**:D1仅公开了基础的视频编码、解码器及码流切换(特征A, C, D, H),完全未公开将图像分割为**切片空间阵列**(特征B)、**部分重写NAL单元报头**(特征I-K)以及**提炼子区域生成第二流并按第二图片大小解码**(特征N-T)等特征。
#### (2) 对比文件2:D2 (WO2010069427A1)
* **比对分析**:D2公开了一种用于IPTV快速换台(Fast Channel Change, FCC)的渐进式 Tune-In 码流方法。D2将主码流采用渐进式解码刷新(GDR,将I帧宏块分散在多个帧中),并另外提供一个 Tune-In Stream(G-TIP),补充缺失的 Intra 宏块([p0028]-[p0032])。在换台时,解码器接收主码流和 Tune-In 码流并进行**拼接(Splicing)**([p0036]-[p0040])。
* **公开特征**:公开了特征A, C, D, E, F, G, H,以及特征Q(通过侧流/TIP提供不同版本的NAL/帧进行选择 [p0012])。
* **差异点**:D2的“拼接(Splicing)”是将不同流的NAL单元在时间轴上拼合,**并未对NAL单元的报头进行部分重写(I-K)**,且D2解决的是时间轴上的快速换台刷新问题,而非空间上的ROI切片提取与重写解码(B, I-T)。
#### (3) 对比文件3:D3 (US20130101035A1)
* **比对分析**:D3公开了HEVC标准下将图像分割为 Tile(网格状空间阵列,即独立可解码切片阵列)并进行 Tile Group 分组的技术([0037],[0063])。
* **特征B/C/D/E/F/G/H公开情况**:[0037]-[0042]段明确公开了图像被划分为矩阵形状的Tile(切片空间阵列),各Tile包含独立NAL单元及Header参数。
* **特征I/J/K/L/M(报头重写与元数据定位)公开情况**:[0061]与[0100]段公开了封装单元(Encapsulation Unit 22)或解封装单元(Decapsulation Unit 32)接收Tile数据后,依据SPS/PPS中的元数据(如 `tile_group_id`, `TileGroupMap` [0124],[0138]),重新排列并重写NAL单元语法和包头结构([0061]: "place syntax information into a bitstream... place the encoded video data from the tiles into the bitstream in an order in accordance with the grouping")。
* **特征N/O/P/R/S/T(第二视频流与第二图片大小解码)公开情况**:[0075]-[0076]段明确公开:“覆盖ROI的子区域(如Tile 92)可以独立于其他区域解码……封装单元将该ROI Tile的视频数据提取并独立成流/包,客户端可仅请求/解码该ROI子区域。”且[0143]指出“LCUs covered by a tile group... from picture-to-picture”,解码器按ROI子图尺寸配置缓冲区进行解码(第二图片大小小于第一图片大小)。
* **比对结论**:**D3实质公开了权利要求1绝大部分技术特征**(包括核心的空间阵列分割、基于元数据的Tile重写与提取、ROI第二视频流生成及小图尺寸解码)。
---
## 三、 最接近对比文件的选择与技术效果分析
### 1. 最接近对比文件(Primary Reference):**D3 (US20130101035A1)**
* **整体解决的技术问题**:D3与本专利均致力于解决**如何在不重新编码的前提下,从高分辨率视频流中灵活提取部分空间区域(ROI/子图像),实现并行处理或独立子图高效解码/传输的问题**。
* **技术效果的一致性**:两者均达成了“降低解码与传输带宽、仅对目标子区域切片进行重写拼合即可使标准解码器识别并按子图大小解码”的技术效果。
* **结论**:在创造性审查/无效分析中,**D3是唯一适合作为最接近对比文件(最强主对比文件)的文献**。D1和D2在整体技术领域(空间ROI提取 vs 时间轴换台/GOP切替)和技术手段(报头重写 vs 帧级同步/拼接)上存在本质差异,不适合作为主对比文件。
---
## 四、 未被最接近对比文件公开的特征及无效薄弱点分析
### 1. 未被D3完全直观公开的微观特征(潜在的“区别特征”)
虽然D3公开了提取ROI Tile并重组NAL包送入解码器,但对比权利要求1的极精细语言,审查员或专利权人可能会主张以下微细区别:
1. **特征I/J/K的极精细动作**:权利要求1限定为**“在解码器装置中”**对NAL单元**报头(Header)的位置**进行**“部分重写(partially rewrite)”**。D3虽然公开了在 Decapsulation Unit / Decoder 端重组和修改NAL/Slice语法([0061],[0100]),但是否属于对“Header原位特定参数的部分覆写”,存在字面拟合度辩论空间。
2. **特征Q的分支选择**:从针对不同子阵列大小的NAL单元的“多个不同版本”中选择版本(该特征为 `and/or` 选项,若主张 `or` 前半部分,则特征Q不构成实质限制;若作为限制,D3未明确强调多版本选择)。
### 2. 其他对比文件的补充情况(D1/D2)
* **特征Q(多版本选择)**:**D2 (WO2010069427A1)** [p0012] 明确公开了存在不同分辨率/质量版本的侧流(Side Stream / Tune-In Stream),解码器可根据需求从多个不同版本的流中选择对应的 NAL/Frame 进行解码。因此,特征Q已被D2公开。
### 3. 无效请求中最薄弱的技术特征分析(专利权人的防守据点)
在诉讼/无效攻击中,**最薄弱(即最容易被专利权人用来防守、最难被攻破)的技术特征是:**
> **特征I/J/K/L的结合:在解码器端,基于元数据(Metadata)精确定位切片空间位置指示,并“仅对 NAL 单元报头进行部分重写(partially rewrite in the header)”。**
* **薄弱原因(防守强度分析)**:
1. **概念混淆防御**:专利权人常辩称传统技术(如D3)是“重新封装(Re-encapsulation)”或“解包后重新生成包”,而本专利是“原位/直接部分重写(Partially rewrite)”,不破坏Payload,仅改动Header中的坐标/地址参数,极大地节省了解码器的CPU计算开销。
2. **执行主体限定(解码器端)**:特征H限定该重写由“解码器装置(Decoder Apparatus)”执行。D3的很多重写逻辑描述在 Encapsulation Unit(发射端/流媒体服务器端),虽然D3提到了 Decapsulation Unit,但专利权人会扣字眼强调D3是“解封装”而非“解码器内的NAL Header部分重写”。
---
## 五、 进一步对比文件检索策略(检索指引)
为了彻底攻破上述“解码器端对NAL包头部分重写(Header Partial Rewrite / Slice Header Modification)”这一薄弱特征,建议采取以下补充检索策略:
### 1. 核心技术要素组合(Search Concepts)
* **主题1(空间切片/Tile)**:HEVC Tiles, Sub-pictures, Motion-constrained tile sets (MCTS), ROI, Slice grid.
* **主题2(包头重写/修改)**:Slice Header rewrite / overwrite / modification, NAL header parsing, Parameter update, Bitstream rewriting.
* **主题3(解码端/提取端轻量化处理)**:Lightweight stream extractor, Decoder-side rewriting, Transcoder-less ROI extraction.
### 2. 推荐检索式与切入点
#### 策略一:聚焦 HEVC MCTS (Motion-Constrained Tile Sets) 与 360度全景视频(Tile Extraction)技术
* *背景说明*:2014-2016年间(HEVC标准完善期及全景VR视频兴起期),为了实现FOVs(视场角)提取,行业大量使用“修改Slice Header中的切片地址(`slice_segment_address`)和PPS ID,使裁剪后的Tile能直接被标准解码器当做独立小图解码”的技术。
* *关键检索表达*:
`("MCTS" OR "Tile") AND ("Slice Header" NEAR/5 "rewrite" OR "modify" OR "overwrite" OR "update") AND ("decoder" OR "extractor")`
#### 策略二:针对标准专利与提案(Standard Contributions)检索
* *重点机构与会议*:JCT-VC (Joint Collaborative Team on Video Coding) 以及 MPEG 360/VR 专题组提案。
* *关键提案主题*:
* HEVC Tile/Slice Header 语法重写(Header rewriting for ROI streaming)。
* 关注 `slice_segment_address` 的覆写(Rewriting `slice_segment_address` in slice header for sub-picture decoding)。
#### 策略三:专利分类号(CPC/IPC)精确精炼
* `H04N 19/167`(涉及感兴趣区域 ROI 的视频编码)
* `H04N 19/174`(涉及切片 Slice 的编码)
* `H04N 19/436`(并行处理/Tiles)
* `H04N 19/85`(涉及码流预处理或后处理/码流重写)
**结合组合**:`H04N19/167 AND H04N19/174 AND (rewrite* OR modify* OR header)`
作为一名经验丰富的专利代理师,我将紧密结合目标专利《权利要求1》的技术方案,对比D1(US20140307775A1)、D2(US20150023407A1)及D3(WO2015011108A1)三份对比文件的原文进行深入的法律与技术分析。
---
## 一、 基于目标专利说明书的权利要求1技术解释
为了准确界定权利要求1的保护范围,首先结合说明书对本领域技术人员理解关键特征的逻辑进行澄清:
1. **第一视频流与第二视频流(特征A、N、O、P)**:
* **解释**:第一视频流指**全画面(如高分辨率全景)**的编码流,具有第一图片大小(如8K/4K全画面)。第二视频流指**仅包含用户感兴趣区域(ROI)或部分切片子阵列**的编码流,具有第二图片大小(小于第一图片大小)。
2. **切片的空间阵列(特征B、C)与网格(Grid)**:
* **解释**:对应HEVC(H.265)中的Tile(瓦片)网格划分(如4x4 Tile阵列)。每个Tile包含独立可解码的CUs/CTUs,且在 Tile 边界处禁用了跨Tile的预测及环路滤波(如`loop_filter_across_tiles_enabled_flag=0`),使得Tile具备独立可解码性。
3. **网络抽象层单元(NALU)及报头(Header)(特征D、E、F、G)**:
* **解释**:指HEVC中的Slice NALU。NALU由NALU Header及包含切片视频数据的Payload组成。特征F和G所指的“报头”特指**切片报头(Slice Header)**,其包含切片解码所需的参数(如切片地址`slice_segment_address`、切片类型、参考帧列表等)。
4. **部分重写NALU与基于元数据选择(特征I、J、K、L、M)**:
* **解释**:
* **核心机制**:在服务端/流媒体传输节点或前端解码预处理器中,并不对视频内容数据(Slice Payload)进行重重编码或重组,而是**仅修改Slice Header中的特定位置**(例如改写切片地址参数`slice_segment_address`,或将独立Slice Header参数同步/修改),使其在第二视频流(小画面)的上下文下能够被标准解码器识别。
* **元数据**:指指示空间位置的元数据(如ROI的坐标、Tile的行列索引)。
5. **从不同版本选择(特征Q)与第二图片大小解码(特征R、S、T)**:
* **解释**:特征Q为“和/或”的可选特征,指系统可预先/动态生成对应不同子阵列大小的NALU版本并进行选择;特征S、T明确了解码器在解码第二视频流时,是**按照适应子阵列的第二图片大小(较小的分辨率/图像尺寸,如仅包含ROI的画面)**进行上下文配置和解码渲染,而非将子阵列填充回第一图片大小中解码。
---
## 二、 对比文件特征比对表及出处分析
### 1. 对比文件基本信息及公开号
* **D1**:US20140307775A1 (*METHOD AND DEVICE FOR PARTITIONING AN IMAGE*)
* **D2**:US20150023407A1 (*IMAGE DECODING DEVICE, IMAGE DECODING METHOD, IMAGE ENCODING DEVICE, AND IMAGE ENCODING METHOD*)
* **D3**:WO2015011108A1 (*METHOD, DEVICE, AND COMPUTER PROGRAM FOR ENCAPSULATING PARTITIONED TIMED MEDIA DATA USING SUB-TRACK FEATURE*)
### 2. 特征比对表格(对照权利要求1)
| 权利要求1技术特征 | D1 (US20140307775A1) | D2 (US20150023407A1) | D3 (WO2015011108A1) | 比对结论 |
| 特征A:第一视频流包含基于视频编解码器编码的视频图像 | 公开<br>Paragraph [0006], [0072] (HEVC编码图像序列) | 公开<br>Paragraph [0002], [0061] (HEVC编码图像) | 公开<br>Paragraph [0008], [0260] (HEVC/SVC编码视频) | D1, D2, D3均公开 |
| 特征B:视频图像有图像区域并被分成独立可解码切片的空间阵列 | 公开<br>Paragraph [0087], [0092]-[0093] (划分成独立的Tile阵列,如4x4 Grid) | 公开<br>Paragraph [0061], [0068]-[0070] (图像划分为Tile阵列且限制帧间/帧内参考) | 公开<br>Paragraph [0008], [0357]-[0387] (图像划分为独立Tile阵列) | D1, D2, D3均公开 |
| 特征C:空间阵列与第一图片大小相关联 | 公开<br>Paragraph [0003], [0080], [0122] (全画面高分辨率图像尺寸,如8K4K/1080p) | 公开<br>Paragraph [0006], [0061] (完整Picture PIC0的尺寸) | 公开<br>Paragraph [0007], [0258] (全图尺寸如4K2K/8K4K) | D1, D2, D3均公开 |
| 特征D:第一视频流包含网络抽象层单元(NALU) | 公开<br>Paragraph [0074], [0084] (NALU) | 公开<br>Paragraph [0105], [0107] (包含Slice Header等流数据) | 公开<br>Paragraph [0260], [0367]-[0374] (NALU格式) | D1, D2, D3均公开 |
| 特征E:每个NALU包含切片中相应切片的视频内容数据 | 公开<br>Paragraph [0084], [0097] (每个Tile/Slice嵌入在NALU中包含CUs数据) | 公开<br>Paragraph [0061], [0105] (包含Tile/Slice的编码数据) | 公开<br>Paragraph [0360]-[0367] (Slice segment包含CTUs数据嵌入NALU) | D1, D2, D3均公开 |
| 特征F:视频内容数据的前面是报头 | 公开<br>Paragraph [0084], [0122] (Slice Segment Header在内容前面) | 公开<br>Paragraph [0105] (Slice Header) | 公开<br>Paragraph [0374]-[0386] (Slice segment header) | D1, D2, D3均公开 |
| 特征G:报头包括与切片相关的参数 | 公开<br>Paragraph [0084], [0133] (Header包含解包/解码所需参数,如slice_segment_address) | 公开<br>Paragraph [0105] (Slice Header参数) | 公开<br>Paragraph [0374]-[0384] (包含slice_segment_address等参数) | D1, D2, D3均公开 |
| 特征H:方法由解码器装置执行 | 公开<br>Paragraph [0005], [0107]-[0112] (客户端/解码器装置) | 公开<br>Paragraph [0122], [0125] (图像解码装置) | 公开<br>Paragraph [0342], [0352] (客户端解码设备) | D1, D2, D3均公开 |
| 特征I:将切片子阵列的NALU部分地重写为重写的NALU | 未明确公开 / 隐式重写<br>D1段落[0112],[0133],[0140]-[0144]提及解码器重排/重用参数,但未明确提出“重写Slice Header” | 未公开<br>D2采用标记ROI Tile并直接丢弃非ROI Tile解码,不涉及修改/重写NAL Header | 未公开<br>D3通过Track/Extractor抽样组合重构流,不重写NAL Header本身 | 三者均未明确公开(薄弱特征) |
| 特征J:NALU在相应的NALU中的每个中的位置处被重写 | 未明确公开 | 未公开 | 未公开 | 三者均未明确公开 |
| 特征K:所述位置位于报头中 | 未明确公开(D1提及Slice Header参数一致性[0133],但未明确修改报头内部特定字段) | 未公开 | 未公开 | 三者均未明确公开 |
| 特征L:所述位置是基于元数据来选择的 | 实质公开/暗示<br>D1段落[0098]-[0103]根据ROI的位置/坐标元数据选择相应的Tile/Slice | 公开<br>D2段落[0105]根据coord_roi_tile_hor等ROI元数据 | 公开<br>D3段落[0279], [0491]-[0498]基于TileMediaHeader/TileRegion等位置元数据 | D1/D2/D3公开了基于元数据定位切片,但未公开“基于元数据选择报头中的重写位置” |
| 特征M:位置包括一个或多个切片的空间位置指示 | 公开<br>D1段落[0098], [0133] (包含slice_segment_address即切片空间地址) | 公开<br>D2段落[0105] (包含Tile坐标位置) | 公开<br>D3段落[0382] (Slice segment address) | D1, D2, D3均公开 |
| 特征N:重写的NALU形成仅包括切片子阵列的第二视频流 | 实质公开<br>D1段落[0099], [0100], [0138]-[0140] (服务器仅抽取ROI对应的Tile NALUs组成新流发给客户端) | 实质公开<br>D2段落[0180], [0269] (提取ROI Tile数据形成独立的Base Layer或过滤流) | 实质公开<br>D3段落[0268]-[0270], [0329]-[0331] (提取ROI Tile Track组合成第二独立流) | D1, D3实质公开;D2在第二实施例(Scalable)公开 |
| 特征O:编码数据表示包含图像区域子区域的部分视频图像 | 公开<br>D1段落[0007], [0098], [0113] (ROI部分图像) | 公开<br>D2段落[0066], [0113] (ROI局部图像) | 公开<br>D3段落[0007], [0258] (ROI空间子部分) | D1, D2, D3均公开 |
| 特征P:重写NALU基于视频编解码器可解码成部分视频图像 | 公开<br>D1段落[0107]-[0109] (HEVC解码器可直接解码提取出的ROI Tile流) | 公开<br>D2段落[0125], [0138] (解码器直接解码ROI Tile) | 公开<br>D3段落[0269], [0331] (符合标准编解码器的流,可直接解码) | D1, D2, D3均公开 |
| 特征Q:和/或从不同子阵列大小的NALU多个版本中选择 | 实质公开<br>D1段落[0026]-[0030], [0127]-[0128] (按不同ROI大小选择不同的独立Slice/Tile版本) | 未明确公开 | 实质公开<br>D3段落[0427], [0443] (子轨道/不同Tile分辨率版本选择) | D1, D3实质公开 |
| 特征R:解码重写的网络抽象层单元 | 公开<br>D1段落[0106]-[0109] | 公开<br>D2段落[0185] | 公开<br>D3段落[0348]-[0351] | D1, D2, D3均公开 |
| 特征S:解码基于与子阵列相关联的第二图片大小执行 | 实质公开<br>D1段落[0113] (仅显示Cropped area,且按照ROI子尺寸配置显示/解码) | 实质公开<br>D2段落[0138], [0281] (根据ROI尺寸调整分辨率和解码输出) | 实质公开<br>D3段落[0279] (TileMediaHeaderBox包含ROI几何尺寸,按此尺寸解码显示) | D1, D2, D3实质公开 |
| 特征T:第二图片大小小于第一图片大小 | 公开<br>D1段落[0007], [0095] (ROI尺寸小于全图尺寸) | 公开<br>D2段落[0066], [0247] (ROI Tile尺寸小于全图像PIC0) | 公开<br>D3段落[0007] (ROI子区域尺寸小于全视频) | D1, D2, D3均公开 |
---
## 三、 最接近的对比文件(近源对比文件)选择与分析
从整体解决的技术问题和达到的技术效果角度看:
* **目标专利解决的技术问题**:在传输和解码高分辨率视频的ROI(感兴趣区域)时,如何避免传输全图冗余数据,同时**无需对Tile视频内容重编码**,仅通过极小的信令开销(修改/重写部分报头)使标准视频解码器能够直接按照“小图片尺寸(第二图片大小)”独立解码ROI子阵列。
* **技术效果**:极大地节省传输带宽,降低解码器计算负载,且保持对标准视频编解码器的兼容性。
### 候选对比文件评估:
1. **对比文件1:D1(US20140307775A1)—— 【最佳最接近对比文件】**
* **技术问题与效果**:D1旨在解决在传输高分辨率视频ROI时降低传输开销和解码负担的问题([0008], [0010])。
* **技术方案重合度**:D1公开了将HEVC图像划分成Tile网格(特征B、C),在传输ROI时,服务器仅选择包含该ROI的Tiles对应的Slice segments NALUs发送给客户端(特征I、N、O),客户端解码器接收后直接解码(特征R、S、T)。更重要的是,D1在段落[0133]中明确指出了“为了使独立切片报头参数在不同Tile间可复用/解码,**强迫编码器/传输端对独立Slice Header的参数进行统一,除切片首个CU地址(`slice_segment_address`)外**”。这与目标专利中通过“重写报头中的空间位置指示”来实现Tile在第二视频流中独立解码的思想最为接近。
* **结论**:**D1最适合作为第一最接近对比文件(第一主引)**。
2. **对比文件3:D3(WO2015011108A1)—— 【并行最接近对比文件】**
* **技术问题与效果**:D3旨在解决在DASH/ISO-BMFF封装格式下,如何高效提取和组合视频Tile(ROI)并提供给客户端解码的问题([0007]-[0009])。
* **技术方案重合度**:D3提出了Tile Track与Composite Track架构,通过提取器(Extractors)或解封装组合(特征N、O、P),将代表ROI的Tile NALU提取并组合成符合标准解码器要求的流(第二视频流),并由客户端按照TileMediaHeader中定义的局部尺寸进行解码(特征S、T)。
* **结论**:如果考量“流重构/流封装”维度的技术逻辑,**D3同样适合作为最接近的对比文件(第二主引)**。
3. **对比文件2:D2(US2015023407A1)**:
* D2主要侧重于在HEVC编解码器内部限制ROI Tile与Non-ROI Tile之间的参考关系(跨Tile参考限制,段落[0068]-[0070]),其局部解码是通过在解码端“跳过/丢弃”非ROI Tile来实现的,并没有强调针对子阵列生成一个独立的“第二视频流”,因此相比D1和D3,D2作为最接近对比文件的契合度稍弱,更适合作为辅引。
---
## 四、 未被最接近对比文件公开的特征及在其他对比文件中的公开情况
以**D1**作为最接近对比文件为例:
### 1. D1未明确公开(或存在微小区别)的特征:
* **特征I、J、K**:*将针对切片子阵列的网络抽象层单元“部分地重写(partially rewrite)”为重写的网络抽象层单元,重写位置位于“报头(Header)”中*。
* *分析*:D1公开了在服务端抽取Tile NALUs,并利用统一的Header参数(段落[0133])或者重排NALUs(段落[0112])来保证解码,但D1原文未明确使用“部分重写(partially rewrite)Slice Header”这一动作术语。
* **特征L**:*所述报头中的重写位置是“基于元数据(Metadata)”来选择的*。
### 2. 其他对比文件(D2、D3)对上述区别特征的公开情况:
* **D2对区别特征的公开情况**:D2(段落[0105])公开了在SPS/PPS/Slice Header中插入ROI的元数据(如`coord_roi_tile_hor_minus1`等),解码器根据该元数据识别ROI Tile,但D2是直接解析并解码对应Tile,**未公开在报头内部进行“部分重写”的操作**。
* **D3对区别特征的公开情况**:D3通过ISO-BMFF文件格式中的抽取器(Extractors)在解封装阶段将 Tile NALU 组合成可解码流,其操作发生在流的封装/解封装层,**亦未公开对HEVC Slice NALU本身的Slice Header内部特定位置进行“部分重写(rewrite)”**。
> **代理师研判**:D1、D2、D3三份对比文件均未明确公开“**在NALU的报头(Slice Header)特定位置处,基于空间位置元数据进行‘部分重写’(Partially Rewrite)**”这一具体的技术手段。
---
## 五、 无效请求中最薄弱的技术特征分析
若针对本专利提出无效宣告请求,权利要求1中**最薄弱(即最容易被突破/最难以维持专利权)的技术特征**以及专利权的“防御护城河”分析如下:
### 1. 专利权的核心护城河(最强特征):
* **特征I + J + K + L**的组合:即“**在NALU的报头(Header)内部,基于空间位置元数据,对指示空间位置的参数进行‘部分重写’(Partially rewrite)**”。
* **为什么强**:现有技术(如D1-D3、甚至标准HEVC规范)处理Tile/ROI传输时,通常采用以下两种传统手段之一:
1. **完全重编码(Transcoding)**:重新编码切片,开销极大;
2. **容器层/解封装层处理(如D3的DASH Extractors或文件头修改)**:在MP4/TS容器层重组,不触动NALU内部的Slice Header;
3. **流抽取+丢弃(如D1/D2)**:传输全Slice Header或限制特性的Slice,解码器解码时丢弃无用Tile。
而本专利提出的“轻量级NALU报头部分重写”(如仅修改Slice Header中的切片地址`slice_segment_address`以使其适应新的第二图片尺寸),介于容器层处理与完全重编码之间,属于**字节级/语法元素级的流剪裁技术**。
### 2. 攻击该护城河的薄弱点(最易被攻破的突破口):
* **突破点(一):显而易见性(结合公知常识/标准规范)**
* 在HEVC(H.265)标准中,切片报头(Slice Header)中必然包含`slice_segment_address`(切片段地址)。当把一个大图(第一图片大小)中的子Tile阵列提取出来,构成一个独立的、分辨率较小的第二视频流(第二图片大小)时,如果不修改`slice_segment_address`,该切片在新的小图坐标系下其地址就会超界(Out of bound)或导致解码器图像定位错误。
* **无效攻击逻辑**:对于本领域技术人员而言,在已知D1(提取Tile NALUs形成独立流发给解码器)的基础上,为了让提取出的Tile子阵列在按小图尺寸解码时不报错,**修改Slice Header中的切片首地址(即部分重写报头)是本领域技术人员为了适应新坐标系必然会采用的常规技术手段/官能修正**,无需付出创造性劳动。
* **突破点(二):“重写”主体的宽泛性**
* 权利要求1中特征H限定“所述方法由解码器装置执行”,特征I限定“将针对切片的子阵列的网络抽象层单元部分地重写”。若专利权人解释该“解码器装置”包含前端预处理模块/Stream Parser,则该“重写”动作极易被认定为流传输过程中的常规语法适配。
---
## 六、 进一步的对比文件检索策略建议
为了彻底无效权利要求1(攻克上述“部分重写Slice Header”的区别特征),建议采取以下进一步的检索策略:
### 1. 检索要素表达(Keywords & Classification)
* **核心概念1(Tile/ROI裁剪/抽取)**:
* HEVC, H.265, Tile, Slice segment, Region of Interest, ROI, Partial decoding, Sub-stream, Sub-picture.
* **核心概念2(报头修改/重写/语法调整)**:
* Rewrite, Modify, Overwrite, Update, Patch, Header, Slice header, Syntax element, `slice_segment_address`, Bitstream manipulation, Lightweight transcoding.
* **分类号(IPC / CPC)**:
* **H04N19/167**(与感兴趣区域ROI相关的视频编码)
* **H04N19/174**(与切片Slice相关的编码)
* **H04N19/436**(并行处理/Tile)
* **H04N19/70**(语法元素、高层语法、NALU报头封装)
* **H04N21/2343**(服务端流转换/修改)
### 2. 重点检索源与文献类型策略
1. **标准提案(JCT-VC / MPEG 提案库)—— 【最强证据源】**
* **原因**:HEVC标准制定期间(2010–2014年),JCT-VC(Joint Collaborative Team on Video Coding)有大量关于 Tile 流抽取(Tile Bitstream Extraction)、ROI 拼接以及轻量级流重写(Bitstream Rewriting / Header Modification)的提案(Input Documents)。
* **检索目标**:寻找关于“*Tile Bitstream Extractor*”或“*Slice Header rewriting for ROI extraction*”的提案(如JCTVC-XXXX)。标准提案中的公开技术往往比专利申请更早且细节更深入。
2. **专利数据库组合检索**
* **结合逻辑**:检索同时包含 `(HEVC OR H.265 OR Tile)` AND `(Slice Header OR NAL header)` AND `(rewrite OR modify OR alter OR update) NEAR3 (address OR location OR header)` 的文献。
* **重点公司/机构专利族**:
* Canon(佳能——D1的申请人,其在Tile ROI流重构领域有深度专利布局);
* InterDigital / Thomson / Technicolor;
* Qualcomm(高通)、Samsung(三星)、Sony(索尼——D2申请人);
* Ericsson(爱立信)、Huawei(华为)。
### 3. 组合无效方案预设(结合新检索方向)
* **主引(D1或D3) + 辅引(针对Slice Header重写的新对比文件/公知常识)**:
* **方案A**:D1 + 结合HEVC标准规范(ISO/IEC 23008-2)中`slice_segment_address`的语法定义 + 本领域公知常识(切片地址在新坐标系下的必然修正)。
* **方案B**:D1/D3 + 揭示“在不重编码Payload的前提下,通过修改Slice Header参数实现Sub-bitstream(子位流)提取”的JCT-VC标准提案或相关技术文献。
尊敬的客户/专利代理师同行:
针对您提交的权利要求1及三份对比文件(D1: US20150103926A1、D2: US20150201202A1、D3: US20150208095A1),基于目标专利说明书的内在逻辑与视频编解码标准(如HEVC/H.265等)的技术背景,我为您做出了以下严谨、系统的专利无效/创造性比对与侵权风险分析。
---
### 一、 紧密结合说明书对权利要求1的技术特征拆解与解释
目标专利权利要求1的核心发明点在于:**在解码端/中间节点对高分辨率/全图视频流的报头(Header)进行“轻量级重写(Rewrite)”,提取切片子阵列(Sub-array of slices,例如ROI区域或子图像),直接组合生成符合标准编解码器规范的“第二视频流”(局部图像流),并基于小于原图的第二图片大小(Second picture size)直接解码该重写后的流。**
1. **第一视频流与独立可解码切片阵列(特征A-G)**:
- **第一视频流**:包含完整的大图像(如4K/8K视频)。
- **独立可解码切片的空间阵列**:图像被划分为多个Slice/Tile。每个NAL单元(NALU)包含Slice视频内容数据。
- **报头(Header)**:指NALU报头(NAL header)或Slice segment header。报头中包含与对应Slice相关的参数(如Slice地址、参数集索引等)。
2. **重写(Rewrite)机制与元数据选择(特征I-M)**:
- 指解码器/提取器无需重新对像素数据进行全编码/解码(避免重编码的高计算开销),仅通过修改(Rewrite)切片报头(Header)中的特定位置参数(如切片空间位置/地址的指示,如 `slice_segment_address` 或 Tile 偏移)。
- **重写位置的依据**:基于元数据(Metadata,如ROI信息、用户选择框、MCTS Tile指示等)来选择报头中的重写位置。
3. **第二视频流与第二图片大小(特征N-T)**:
- 重写后的NALU提取形成**第二视频流**,该流仅包含子阵列切片。
- 关键在于:解码器基于**第二图片大小(Second picture size,小于第一图片大小)**来解码该第二视频流。即解码器将重写后的子流视为一个独立的、较小分辨率的合规视频流直接解码输出,从而极大节省解码算力与内存。
---
### 二、 对比文件特征比对与特征比对表格
以下为三份对比文件针对权利要求1技术特征A-T的详细比对分析及原文出处:
#### 1. D1:US20150103926A1
* **技术领域**:可扩展视频编码(Scalable Video Coding, SVC/SHVC/MV-HEVC)。
* **公开内容分析**:主要涉及分层编码(Base Layer与Enhancement Layer)、输出层集(Output Layer Sets)以及替代输出层的信令控制(如 `min_alt_output_layer_idx`)。D1侧重于在某一层缺失时降级输出替代层,**完全未涉及针对切片空间阵列(Slice/Tile Array)的“报头重写(Header rewrite)”以抽取部分图像区域并按较小图片大小解码**。
#### 2. D2:US20150201202A1
* **技术领域**:基于HEVC的Tile/Slice划分及媒体文件(MP4/ISOBMFF)格式封装。
* **公开内容分析**:
* **公开了特征A-H**:公开了将图片划分为Tile和Slice的空间阵列,每个Slice/Tile封装在NALU中,包含报头及切片参数。
* **公开了基于元数据提取子图像**:公开了使用MCTS SEI或ROI Box等元数据,提取感兴趣区域(ROI / Particular tiles)对应的 Slice/Tile NALU。
* **未明确/未公开特征I-M及S-T**:D2侧重于在媒体文件格式(File format box,如 `sidx`, `tidx`, `tsob`)中记录Tile与Slice的索引偏移,以便提取端“跳过(Skip)”不需要的NALU。D2**未显式公开在NALU报头内部位置进行“重写(Rewrite)”**,也未显式明确提取后的子流是否通过**重写报头**并修改为**第二图片大小**直接输入标准解码器解码。
#### 3. D3:US20150208095A1
* **技术领域**:低延迟视频流传输、Sub-picture/Slice prefix NAL U及其报头数据信令。
* **公开内容分析**:
* **公开了特征A-H**:公开了 Slice/Tile/WPP 划分为 NALU 序列,带有 NAL/Slice Header。
* **实质公开了报头数据重写/替换(特征I-M, Q)**:D3引入了 **Slice Prefix NAL Unit**。在Slice Prefix中显式携带/替换后续Slice的报头数据(`slice_header_data()`),或者重写/继承报头参数。并且支持通过Tile ID、ROI SEI等元数据定位并改写/提供报头数据。
* **未公开特征S-T**:D3主要解决了网络提取与低延迟CPB/DPB缓冲管理,未强调将提取后的子区域流改写为**第二图片大小(小分辨率)**进行解码的特征。
---
#### 权利要求1特征比对表格
| 权利要求1技术特征 | D1 (US20150103926A1) | D2 (US20150201202A1) | D3 (US20150208095A1) |
| 特征A:第一视频流包含基于编解码器编码的视频图像 | 公开<br>[0006] encoding pictures into a bitstream | 公开<br>[0002] H.264/HEVC coding... | 公开<br>[0159] encode video content... |
| 特征B:图像有图像区域并分为独立可解码切片空间阵列 | 未公开<br>(D1为SNR/Spatial Layer,非Slice/Tile Array) | 公开<br>[0004] dividing a picture into rectangular areas called tiles | 公开<br>[0204] sub-portions... slices, tiles, WPP |
| 特征C:空间阵列与第一图片大小相关联 | 未公开 | 公开<br>[0010] 4096x2048 pixels | 公开<br>[0288] tile_width / tile_height / picture |
| 特征D:第一视频流包括网络抽象层(NAL)单元 | 公开<br>[0148] Network Abstraction Layer (NAL) unit | 公开<br>[0011] converted into NAL unit data | 公开<br>[0159] payload packets (VCL NAL units) |
| 特征E:每个NALU包含对应切片的视频内容数据 | 公开<br>[0152] | 公开<br>[0011] coded data of each slice... NAL unit | 公开<br>[0159] payload packets |
| 特征F:视频内容数据前面是报头 | 公开<br>[0149] | 公开<br>[0011] added with 1-byte NAL header / [0012] slice header | 公开<br>[0189] slice header |
| 特征G:报头包括与切片相关的参数 | 公开<br>[0149] | 公开<br>[0012] coding parameters necessary in decoding each tile are described in a slice header | 公开<br>[0189] slice header data |
| 特征H:方法由解码器装置执行 | 公开<br>[0024] decoding method | 公开<br>[0025] decoding time... | 公开<br>[0161] decoder for decoding |
| 特征I:将切片子阵列的NALU部分地重写为重写的NALU | 未公开 | 未显式公开<br>(仅公开提取/Skip NALU) | 实质公开<br>[0188]-[0190] slice prefix... slice_header_data(重写/替换Slice Header数据) |
| 特征J:NALU在相应NALU中的位置处被重写 | 未公开 | 未显式公开 | 实质公开<br>[0249]-[0250] prefix_slice_header_data_present_flag / [0260] slice_header_data |
| 特征K:所述位置位于报头中 | 未公开 | 未显式公开 | 实质公开<br>[0189] shifted to... slice_header_data / [0259] |
| 特征L:重写位置基于元数据选择 | 未公开 | 实质公开<br>[0005] MCTS SEI message / [0058] ROI box | 公开<br>[0182] ROI SEI message / [0278] sub-picture tile info SEI |
| 特征M:位置包括一个或多个切片的空间位置指示 | 未公开 | 公开<br>[0118] slice_segment_address / Tile Offset | 公开<br>[0076] slice_address / [0253] first_tile_id_in_prefixed_slices |
| 特征N:重写NALU形成仅含切片子阵列的第二视频流 | 未公开 | 实质公开<br>[0008] extract only a tile set... play back as a partial motion picture | 实质公开<br>[0163] perform the transmission of... decoding units |
| 特征O:编码数据表示包含图像区域子区域的部分视频图像 | 未公开 | 公开<br>[0008] partial motion picture / [0010] extract a particular area | 公开<br>[0182] region of interest (ROI) |
| 特征P:重写NALU基于编解码器可解码成部分视频图像 | 未公开 | 实质公开<br>[0008] quickly decode or play back... as a partial motion picture | 公开<br>[0161] |
| 特征Q:从不同子阵列大小的多个版本中选择NALU版本(和/或) | 未公开 | 未公开 | 实质公开<br>[0248] tile_idc / [0298] num_tiles_in_roi |
| 特征R:解码重写的NALU | 未公开 | 公开<br>[0008] decode the extracted MCTS tile set | 公开<br>[0161] |
| 特征S:解码基于与子阵列相关联的第二图片大小执行 | 未公开 | 未显式公开<br>(未明确写出将SPS/PPS中的Picture Size改写为小尺寸) | 未显式公开<br>(未强调修改SPS/PPS picture size进行解码) |
| 特征T:第二图片大小小于第一图片大小 | 未公开 | 未显式公开 | 未显式公开 |
---
### 三、 最接近对比文件的选择(从技术问题与效果角度分析)
在创造性分析(或无效宣告)中,**对比文件2(D2: US20150201202A1)** 最适合作为**最接近的现有技术(最接近的对比文件)**。
#### 1. 理由分析(技术问题与技术效果):
* **整体技术问题**:
目标专利要解决的核心问题是:在高分辨率视频(如4K/8K)中,如何高效提取并解码局部区域(ROI/Tile/子图像),**避免对整张大图进行完全解码所带来的巨大算力开销、内存占用以及高延迟**。
* **技术效果的一致性**:
* **D2 (US20150201202A1)** 的发明目的(BACKGROUND/SUMMARY)与目标专利高度重合。D2在段落 `[0010]` 中明确指出:“在低分辨率设备上播放高分辨率视频时,若先解码整张图片再裁剪提取,会导致**解码时间长(延迟高)、功耗大、内存需求高**;因此,将图片划分为Tile/Slice,并在播放时**仅提取并解码特定Tile**,可显著**降低延迟、降低功耗并减少内存**”。
* D2通过在MP4/ISOBMFF文件层建立Tile/Slice索引(如 `sidx`, `tidx`, MCTS SEI),实现了切片子阵列(Sub-array)的快速定位与抽取。
* **D3的定位**:
D3 (US20150208095A1) 侧重于**网络传输层/Slice Prefix NALU** 的低延迟CPB/DPB调度与报头数据预先/替换信令,其核心问题是网络流传输中的低延迟与Slice Header重用。虽然D3公开了报头重写/Prefix机制,但在“提取局部图像以降低解码器图片尺寸”这一整体构思上,D2与目标专利最为接近。
---
### 四、 未被最接近对比文件(D2)公开的特征及其在其他对比文件中的公开情况
#### 1. D2未公开(或未显式公开)的特征:
* **特征I-K(重写机制)**:将切片子阵列的网络抽象层单元(NALU)**在报头中的特定位置处进行部分重写(Rewrite)**。D2更多是“抽取/抽取切片NALU”,未明确写出修改/重写 Header 中的参数。
* **特征S-T(第二图片大小解码)**:解码重写后的NALU时,**基于小于第一图片大小(原图)的第二图片大小(子图像尺寸)来执行解码**。D2公开了提取子Tile解码,但未明确说明解码器是按照“缩小后的SPS/PPS Picture Size”进行初始化解码,还是在原图坐标系下解码。
#### 2. 其他对比文件(D3)对上述未公开特征的公开情况:
* **关于特征I-K(报头重写)**:
**D3 (US20150208095A1) 实质公开了该特征。** D3公开了 `slice_prefix` NALU 及 `slice_header_data()` 结构。D3明确教导了可以将 Slice Header 中的关键参数剥离到 Prefix 中,或者在 Prefix/Header 中**重写/替换(Overwrite/Override)**后续 Slice 的报头数据,使得解码器基于修改/重写后的报头参数进行解码。
* **关于特征S-T(第二图片大小)**:
在对比文件D1、D2、D3中,**均未显式、毫无疑义地公开“在重写切片报头后,将解码器配置为按‘第二图片大小(小尺寸)’直接解码重写后的流”这一具体动作。**
---
### 五、 若提出无效请求最薄弱的技术特征
如果在专利无效宣告程序中发起创造性挑战,本专利**最薄弱的技术特征**(即专利权人最容易用来防御、也是无效请求人最难攻破的特征)是:
> **特征S与T组合:【将针对切片的子阵列的网络抽象层单元部分地重写... 解码重写的网络抽象层单元;所述解码基于与所述子阵列相关联的第二图片大小来执行;其中所述第二图片大小小于所述第一图片大小】**
#### 薄弱点/突破点分析:
1. **专利权人的防御逻辑**:专利权人会主张,现有技术(如D2/D3)即使提取了局部Tile,解码器依然是以“原图大小(第一图片大小)”的缓冲区(DPB/CPB)和坐标系进行解码(仅跳过了非目标Tile的宏块)。而本专利通过**重写报头**(如重写SPS/PPS或Slice Header中的图像尺寸与地址偏移),**将提取出的局部流骗过解码器,使其误以为这是一个‘独立的小分辨率视频’(第二图片大小)**。这使得解码器可以**分配极小的内存缓冲区**,从而实现了意想不到的技术效果。
2. **无效请求人的攻破策略(公知常识/本领域技术人员的显而易见性)**:
* 在HEVC/MCTS(运动受限Tile集)标准中,MCTS的原本目的就是为了让子Tile集能够独立于其他Tile解码。
* 本领域技术人员(POSITA)为了让标准HEVC解码器能够直接播放提取出来的MCTS子流,必然需要将子流的SPS/PPS中的 `pic_width_in_luma_samples` 和 `pic_height_in_luma_samples` 改写为子区域的大小(即第二图片大小),并将Slice Header中的 `slice_segment_address` 重置为0。
* **结论**:这种“修改报头参数以符合小尺寸解码”的操作,是本领域技术人员在面对“如何用标准解码器解码提取出的MCTS/ROI流”这一技术问题时,**无需付出创造性劳动即可联想到的常规技术手段(或公知常识)**。
---
### 六、 进一步的对比文件检索策略(检索指引)
为了彻底击头(基于102新颖性或103创造性完全无效权利要求1),建议针对上述“最薄弱特征(S/T特征及报头重写)”展开补充检索。
#### 1. 重点检索方向与关键词组合:
* **核心概念**:切片/ Tile 提取 + 报头重写/修改 + 变更解码分辨率/图片大小。
* **英文关键词**:
* `(MCTS OR "motion constrained tile set" OR "sub-picture" OR "region of interest" OR ROI OR tile)`
* AND `(rewrite OR rewriting OR modify OR modification OR overwrite OR "header rewrite")`
* AND `(SPS OR PPS OR "slice header" OR NAL)`
* AND `("picture size" OR resolution OR "image size" OR width OR height) NEAR/5 (smaller OR reduce OR change OR second)`
* AND `(decode OR decoder OR bitstream)`
#### 2. 标准技术文档(Standard Contributions)专项检索(**最推荐**):
由于该技术紧密结合 HEVC (H.265) / VVC (H.266) 标准中的 **MCTS (Motion Constrained Tile Sets)** 和 **Sub-picture 提取**,建议直接检索 **JCT-VC** 和 **JVET** 的会议提案(Input Documents):
* **检索平台**:[JVET / JCT-VC Document Management System](https://phenix.int-evry.fr/jct/ 或 https://jvet-experts.org/)。
* **重点关注提案方向**:
1. **HEVC MCTS Extractor / Sub-bitstream Extraction**:寻找关于“如何编写一个 MCTS 提取器(Extractor),通过 Rewrite SPS/PPS/Slice Header 将 MCTS 转换为合规的单流(改写 picture_size)”的提案。
2. **Omnidirectional Media Format (OMAF) / 360-degree Video Streaming**:VR/360度全景视频中,基于Tile的视角(Viewport)提取与报头重写技术(这是2015-2018年间的极热方向)。
3. **JVET/JCT-VC 关于 Sub-picture / Tile Group 报头重写的草案**。
#### 3. 专利分类号(CPC/IPC)精准缩检:
* **H04N 19/167**:基于感兴趣区域(ROI)的视频编码。
* **H04N 19/174**:涉及 Slice/Tile 划分的视频编码。
* **H04N 19/40**:视频码流转码/重写(Transcoding/Bitstream rewriting)。
* **H04N 19/70**:视频码流语法/报头信令(High-level syntax / NAL unit header)。
通过将 **D2 (或D3)** 作为第一对比文件,结合上述补充检索到的“教导了将提取的Tile流通过重写SPS/PPS/Slice Header中的图片尺寸(pic_size)和切片地址(slice_address)以实现小尺寸解码”的标准提案或对比文件D4,将能够形成极其坚固的 103 创造性组合(D2 + D4 或 D3 + D4),成功无效目标专利权利要求1。
作为一名专业的专利代理师,在进行专利权无效宣告或创造性防辩/攻击分析时,必须**紧密围绕目标专利说明书的本意**对权利要求特征进行准确界定,并结合对比文件的原文细节、出处以及整体技术方案进行严密的法律与技术比对。
针对**权利要求1**,以下为您提供深度的专利有效性/创造性分析、对比文件技术特征比对表、最接近对比文件的筛选及后续无效检索策略。
---
### 一、 权利要求1技术特征拆解与说明书含义界定
根据专利说明书的技术本意,权利要求1的核心发明点在于:**在网络传输层/流媒体传输层,基于元数据(指示空间位置/子阵列),通过“重写网络抽象层单元(NAL Unit)报头(Header)”的方式,将包含全图/第一图片大小的第一视频流直接裁剪/改写为仅包含子阵列(第二图片大小)的独立可解码第二视频流,从而使得标准的视频解码器无需对全图进行解码,即可直接解码该部分视频图像。**
我们将权利要求1拆解为20个技术特征(A ~ T):
- **特征A**:第一视频流包含基于视频编解码器编码的视频图像;
- **特征B**:视频图像具有图像区域并被分成独立可解码切片(Slice/Tile)的空间阵列;
- **特征C**:空间阵列与第一图片大小(First Picture Size)相关联;
- **特征D**:第一视频流包括网络抽象层单元(NAL Unit);
- **特征E**:每个NAL Unit包含切片中的相应切片的视频内容数据;
- **特征F**:视频内容数据的前面是报头(Header);
- **特征G**:报头包括与和第一视频流相关的切片中的相应切片相关的参数;
- **特征H**:方法由解码器装置执行(注:实际语境中包含流传输处理端/解码端系统);
- **特征I**:包括将针对切片的子阵列的NAL Unit部分地重写为重写的NAL Unit;
- **特征J**:NAL Unit在相应的NAL Unit中的每个中的位置处被重写;
- **特征K**:重写位置位于报头(Header)中;
- **特征L**:重写位置是基于元数据来选择的;
- **特征M**:重写位置包括一个或多个切片的空间位置的指示;
- **特征N**:重写的NAL Unit形成包括仅切片的子阵列的编码视频数据的第二视频流;
- **特征O**:编码视频数据表示包括图像区域的子区域的部分视频图像;
- **特征P**:重写的NAL Unit基于视频编解码器可解码成部分视频图像;
- **特征Q**:和/或从针对不同子阵列大小的NAL Unit的多个不同版本选择针对切片的子阵列的NAL Unit的版本;
- **特征R**:解码重写的NAL Unit;
- **特征S**:解码基于与子阵列相关联的第二图片大小(Second Picture Size)来执行;
- **特征T**:第二图片大小小于第一图片大小。
---
### 二、 对比文件技术特征比对表
各对比文件公开号说明:
- **D1**:US20150208103A1
- **D2**:WO2015197818A1
- **D3**:WO2016002496A1
以下表格详细列出各技术特征在对比文件中的公开情况及原文出处:
| 权利要求1技术特征 | D1 (US20150208103A1) 公开情况及原文出处 | D2 (WO2015197818A1) 公开情况及原文出处 | D3 (WO2016002496A1) 公开情况及原文出处 |
| A: 第一视频流基于编解码器编码 | 实质公开:[0010]“encoded video segments” | 实质公开:[0007]“HEVC-tiled video stream” | 实质公开:[0008]“画像データが階層符号化された符号化データ” |
| B: 分成独立可解码切片空间阵列 | 实质公开:[0011]“divided into an array of tiles, and each tile comprising an array of slices” | 实质公开:[0009]“restricting spatial and temporal predictions... within boundaries of one or more HEVC tiles” | 实质公开:[0046]“タイル毎に独立して符号化を行うことができる” |
| C: 关联第一图片大小 | 实质公开:[0078]“<frame width> and <frame height> denote width and height of frames” | 实质公开:[0005]“full 360 degrees in even higher resolutions than 8Kx4K” / [0116] “4096x2160” | 实质公开:[0043]“1980x1080サイズの全体画像” |
| D: 第一视频流包含NALU | 实质公开(编解码器标准隐性公开):MPEG-4/H.264/HEVC视频流默认包含NAL Unit结构 | 实质公开:[0070]“MPEG stream... NAL units” / [0089]“bitstream” | 实质公开:[0045]“VPS, SPS, SEI, PPS... スライス(Slice)” |
| E: NALU包含切片视频内容数据 | 实质公开:[0018]“plurality of slices in each tile” | 实质公开:[0020]“video data of a spatial segment formatted as a HEVC-tiled video stream” | 实质公开:[0045]“画像データのビットストリームがスライス(Slice)毎に並べられている” |
| F: 视频数据前面有报头 | 实质公开(视频标准隐性公开):Slice前均有Slice Header及NALU Header | 实质公开:[0070]-[0089] SEI/Slice Header | 实质公开:[0045]“VPS, SPS, SEI, PPS等のヘッダ情報が付加され” |
| G: 报头包含相应切片相关参数 | 实质公开:[0078]“<tile offset>, <slice start>”等索引对应参数 | 实质公开:[0020]“decoder information for informing a decoder...” | 实质公开:[0054]“符号化パラメータ等の情報は...HEVC sample entryに格納” |
| H: 由解码器装置执行 | 实质公开:[0026]“display module for receiving and decoding tiles” | 实质公开:[0036]“HEVC decoder may be used for decoding” | 实质公开:[0204]“ベースレイヤ復号部203、エンハンスメントレイヤ復号部204” |
| I: 将切片子阵列NALU部分重写为重写NALU | 未公开:D1采用抽取切片字节(Byte Offset Crop)直接拼接发送,未在NALU内做Header改写 | 未公开:D2通过Track/Extractor和MPD层进行切片抽取,未公开“重写NALU报头” | 未公开:D3通过Track、Extractor以及MPD中的Association关联,未公开“重写NALU报头” |
| J: NALU在相应的每个的位置处被重写 | 未公开 | 未公开 | 未公开 |
| K: 位置位于报头(Header)中 | 未公开 | 未公开 | 未公开 |
| L: 位置基于元数据选择 | 未公开(D1的Offset文件仅用于查找字节起始位置) | 未公开(D2的SRD/SEI用于指示/定位,非重写报头位置) | 未公开 |
| M: 位置包括切片空间位置的指示 | 未公开 | 未公开 | 未公开 |
| N: 重写NALU形成第二视频流 | 未公开(仅公开抽取字节拼接传输) | 未公开(公开了生成Spatial Segment Stream,但非通过重写报头形成) | 未公开 |
| O: 编码数据表示子区域部分图像 | 实质公开:[0023]“extract the tiles... within the adjusted region-of-interest” | 实质公开:[0017]“spatial segment defines part of an image frame” | 实质公开:[0041]“部分画像(タイル画像)” |
| P: 基于编解码器可解码成部分图像 | 实质公开:[0027]“decode tiles for display... removing slices not in ROI” | 实质公开:[0020]“readily decoded by a single HEVC decoder” | 实质公开:[0006]“任意の階層の任意の部分画像を選択して” |
| Q: 多版本选择针对子阵列的版本 | 实质公开:[0024]“extract tiles at resolution closest to adjusted zoom level” | 实质公开:[0113]“different Spatial Representations (different qualities/resolutions)” | 实质公开:[0002]“同一コンテンツが異なるビットレート/解像度で表現された” |
| R: 解码重写的NALU | 未公开(仅公开解码提取的原样本切片数据) | 未公开(解码的是提取/拼接的流,非重写报头后的NALU) | 未公开(解码Track/Extractor拼接流) |
| S: 解码基于第二图片大小(小于第一) | 实质公开:[0027]“display module scale/crop decoded tiles” | 实质公开:[0028]“image area smaller than full panorama video” | 实质公开:[0058]“部分画像の画サイズを制御” |
| T: 第二图片大小小于第一图片大小 | 实质公开:[0027] | 实质公开:[0028] | 实质公开:[0058] |
---
### 三、 整体解决的技术问题、技术效果及“最接近对比文件”筛选
#### 1. 整体解决的技术问题与技术效果
本专利要解决的核心技术问题是:在基于Tile/Slice划分的大图像流媒体传输与解码中,**如何无需对整个大图进行重编码或复杂解码,就能使标准解码器以更低的计算资源和网络带宽,直接解码任意局部区域(ROI)并按缩小后的图像尺寸(第二图片大小)正确渲染**。
其技术效果在于:通过在NALU Header(报头)级别进行轻量级的**部分重写(Header Rewriting)**,用极小的计算开销修改了图像尺寸与空间位置参数,使后端的标准视频解码器“误以为”接收到的就是一个完整的、小尺寸的视频流,从而实现高效率的局部实时解码。
#### 2. 最接近对比文件的选择与分析
在创造性分析中,可以推选 **D1 (US20150208103A1)** 和 **D2 (WO2015197818A1)** 作为**最接近的对比文件(均可作为第一基本对比文件)**:
* **最接近对比文件 1:D1 (US20150208103A1)**
* **理由**:D1的技术方案最贴近本发明的应用场景与流处理架构。D1公开了基于Virtual Tiling技术,通过Index/Offset文件提取大图中对应ROI区域的Tile和Slice字节流,将其发送给终端进行局部解码与缩放展示([0011],[0019],[0023])。它与本发明的架构最为相似,均强调了在不重新编码全图的前提下对Slice/Tile级别的流数据进行裁剪与组合。
* **最接近对比文件 2:D2 (WO2015197818A1)**
* **理由**:D2深入探讨了HEVC架构下的Tile空间切片(Spatial Segment)。D2公开了将全图分割为独立可解码的Tile阵列,并利用MPD/SRD元数据以及Extractor Track技术,将子阵列切片组合成可直接被单一HEVC解码器解码的独立视频流([0019],[0020],[0039])。D2在标准编解码器兼容性、MPD元数据指示及单解码器处理逻辑上与本发明高度契合。
---
### 四、 未被最接近对比文件公开的技术特征分析与最薄弱特征
#### 1. 未被对比文件公开的特征(区别技术特征)
通过上述对比可知,对比文件D1、D2、D3均**未公开**以下核心技术特征组合:
* **特征 I、J、K、L、M、N、P、R** 的组合,即:**“基于元数据选择报头中的位置(指示切片空间位置),并将针对切片子阵列的网络抽象层单元(NAL Unit)的报头(Header)部分地重写为重写的NAL Unit,进而形成第二视频流并进行解码”**。
现有技术(如D1、D2、D3)在实现局部视频流解码时,普遍采用以下两种思路之一:
1. **D1的思路**:流媒体服务器根据Offset直接抽取原始切片的字节(Byte Cropping),直接发送给客户端,由客户端解码器或显示模块进行软件裁剪(Crop)与缩放(Scale)。
2. **D2/D3的思路**:在MP4容器层利用“Extractor Track(抽取器轨道)”或DASH MPD层利用“SRD (Spatial Relationship Description)”元数据,将多个Tile轨道动态拼装成一个符合规范的媒体流供解码器解码。
**没有任何一个对比文件公开了“在视频编解码层的NAL Unit Header(NALU报头)直接进行部分改写/重写(Rewriting)”这一具体技术手段。**
#### 2. 无效请求中最薄弱的技术特征(专利权人的“护城河”)
如果在无效宣告程序中对权利要求1发起攻击,**最薄弱(即最难被无效掉、专利权人防御最强)的技术特征是:特征I + K(将针对切片的子阵列的网络抽象层单元部分地重写,且重写位置位于报头中)。**
* **理由**:
1. **技术偏离**:现有技术(D1-D3)均在“容器层(MP4/DASH)”或“传输层(Byte offset)”解决局部流的提取问题,属于文件结构或协议层的重组;而本专利切入到了“视频编解码NALU报头层”,通过修改报头参数(如PPS/SPS/Slice Header中的图像尺寸和空间位置指示)来实现流的欺骗与重构。这种“报头重写”并非本领域的公知常识或显而易见的技术替代。
2. **显而易见性门槛高**:即使审查员/无效请求人试图将D1/D2与常知识组合,也难以证明将MP4轨道的组装手段替换为“重写NALU Header参数”存在明确的技术启示(Technical Teaching)。
---
### 五、 进一步的对比文件检索策略建议
为了成功攻破权利要求1的上述薄弱特征(即“重写NALU Header以实现切片/局部流解码”),建议采用以下进一步的检索策略:
#### 1. 扩展检索关键词组合(Focus在Header Rewriting & NALU)
在后续检索中,必须摆脱传统的“Tile/Slice Streaming”大概念,将检索重点精准锁定在**流转码、流重构中的“报头重写/报头修改”**。
* **核心关键词(英文)**:
* `NAL unit` OR `NALU` OR `Slice header` OR `SPS` OR `PPS`
* `rewrite` OR `rewriting` OR `modify` OR `header modification` OR `patching` OR `overwrite`
* `cropped` OR `sub-picture` OR `subpicture` OR `ROI` OR `tile array` OR `spatial sub-region`
* `transcoding-free` OR `lightweight stream adaptation` OR `bitstream rewriting`
* **核心关键词(中文/日文)**:
* NAL单元 / 报头重写 / 报头修改 / 切片头 / 图像尺寸修改 / 局部解码
* NALユニット / ヘッダ書き換え / ヘッダ修正 / 部分画像 / タイル抽出
#### 2. 分类号(IPC/CPC)精准聚焦
重点排查以下专门涉及“流语法修改”和“基于传输/解码控制的视频流拼接/裁剪”的分类号:
* **H04N 19/174**:包含切片(Slice)的编码/语法细节;
* **H04N 19/70**:比特流语法(Syntax)或报头结构(Header Structures);
* **H04N 19/46**:随编码视频数据传输附加信息(如元数据修改);
* **H04N 21/2343**:流媒体服务器端的视频流转换/重构(Stream transformation/rewriting)。
#### 3. 重点检索标准文献与学术库(标准提案往往公开极细微的报头操作)
由于“修改NALU Header”极易出现在视频编解码标准制定过程中的提案(Contributions)里,建议检索:
1. **JVET / JCT-VC / MPEG 提案库**:检索关于 `Motion-Constrained Tile Sets (MCTS)`、`Sub-picture NALU extraction` 以及 `MCTS SEI message rewriting` 的提案。在HEVC/VVC标准制定期间,有大量关于如何通过修改MCTS SEI或SPS/PPS Header将MCTS直接提取为独立比特流(Bitstream Extraction)的提案。
2. **IEEE Xplore / ACM Digital Library**:搜索主题如 *"Transcoding-free Tile Extraction"*, *"NAL unit header rewriting for virtual reality streaming"*, *"Direct bitstream manipulation for ROI video"*.
#### 4. 组合攻击路径推荐(103创造性组合路线)
* **主对比文件(D1或D2)**:提供“Tile/Slice划分 + 基于ROI提取切片子阵列 + 元数据定位”的整体流媒体传输架构。
* **辅对比文件(待检索的D4)**:提供“通过修改/重写NALU报头(如SPS/PPS/Slice Header中的图像尺寸或切片地址)将提取的视频切片重构成独立可解码流”的技术手段。
* **结合逻辑**:论证本领域技术人员在面对D1/D2中“客户端解码器需要额外对不完整Slice进行复杂拼接或软件Crop”的缺陷时,有明确动机引入D4所教导的“NALU报头重写技术”,使提取出的子阵列切片报头参数符合标准解码器对独立小图(第二图片大小)的解码要求,从而无需修改终端解码器即可直接播放,由此证明权利要求1不具备创造性。
这份专利无效分析报告以资深专利代理师的专业视角,紧密结合涉案专利(权利要求1)与对比文件D1(US2016105690A1)及D2(US2016255354A1)的原文进行对比,逐项拆解技术特征并评估有效性。
---
## 一、 权利要求1的技术特征拆解
权利要求1(下称“本专利权1”)保护一种**解码来自第一视频流的编码视频数据的方法**,拆解为技术特征A~T如下:
* **A**:第一视频流包括基于视频编解码器编码的视频图像
* **B**:视频图像具有图像区域并被分成独立可解码切片(slices)的空间阵列
* **C**:空间阵列与第一图片大小(first picture size)相关联
* **D**:第一视频流包括网络抽象层单元(NALUs)
* **E**:每个网络抽象层单元包含切片中的相应切片的视频内容数据
* **F**:视频内容数据的前面是报头(header)
* **G**:报头包括与和第一视频流相关的切片中的相应切片相关的参数
* **H**:方法由解码器装置执行
* **I**:将针对切片的子阵列的网络抽象层单元部分地重写为重写的网络抽象层单元
* **J**:网络抽象层单元在相应的网络抽象层单元中的每个中的位置处被重写
* **K**:位置位于报头(header)中
* **L**:位置是基于元数据(metadata)来选择的
* **M**:位置包括一个或多个切片的空间位置的指示
* **N**:重写的网络抽象层单元形成包括仅切片的子阵列的编码视频数据的第二视频流
* **O**:编码视频数据表示包括图像区域的子区域的部分视频图像
* **P**:重写的网络抽象层单元基于视频编解码器可解码成部分视频图像
* **Q**:和/或从针对不同子阵列大小的网络抽象层单元的多个不同版本选择针对切片的子阵列的网络抽象层单元的版本
* **R**:解码重写的网络抽象层单元
* **S**:解码基于与子阵列相关联的第二图片大小来执行
* **T**:第二图片大小小于第一图片大小
---
## 二、 特征比对与对比文件原文出处分析
### 1. 对比文件基本信息
* **对比文件D1**:US20160105690A1(公开日:2016-04-14)
* **对比文件D2**:US20160255354A1(公开日:2016-09-01)
### 2. 特征比对表格(Feature Mapping Table)
| 权利要求1特征 | 是否公开 (D1: US20160105690A1) | D1 详细原文出处及内容 | 是否公开 (D2: US2016255354A1) | D2 详细原文出处及内容 |
| A | 实质公开 | [0045], [0053](HEVC/AVC标准视频码流与NALU) | 毫无异议公开 | [0003], [0061], [0175](HEVC标准,VCL NAL单元) |
| B | 毫无异议公开 | [0044]-[0054], Fig 3(独立可解码Tile/Slice阵列) | 毫无异议公开 | [0043]-[0048], Fig 4(独立瓦片Tile及切片Slice阵列) |
| C | 毫无异议公开 | [0104], [0120](reference_width/height,全图尺寸) | 毫无异议公开 | [0192]-[0193], Fig 8(pic_width/height_in_luma_samples) |
| D | 毫无异议公开 | [0048], [0053](Network Abstract Layer (NAL) units) | 毫无异议公开 | [0174]-[0176](NAL units, VCL/non-VCL NAL) |
| E | 毫无异议公开 | [0048], [0053](coded slice segment, slice_segment_data) | 毫无异议公开 | [0160]-[0161], [0175](VCL NAL包含切片数据) |
| F | 毫无异议公开 | [0048]("header called slice_segment_header followed by data") | 毫无异议公开 | [0098], [0175](slice_segment_header位于slice数据前) |
| G | 毫无异议公开 | [0053](slice_segment_address, slice_segment_header参数) | 毫无异议公开 | [0198], [0258](slice_segment_address等切片报头参数) |
| H | 毫无异议公开 | [0166], [0170](multimedia player/client, parser, decoder) | 毫无异议公开 | [0025], [0169](image decoder, 图像解码器) |
| I | 未公开/差异 | 未提及“在报头中重写(rewrite)NALU”的过程 | 实质公开 | [0027], [0316], [0331](转换器重写/修正参数集与NALU) |
| J | 未公开/差异 | 未明确公开在报头特定位置重写NALU | 实质公开 | [0316]-[0330](修正PPS/SPS报头的指定参数位置) |
| K | 未公开/差异 | 未公开报头位置重写 | 实质公开 | [0027], [0320]-[0330](修改PPS/SPS parameter set报头) |
| L | 未公开/差异 | - | 实质公开 | [0027], [0318](基于ROI元数据/输入信息选择修改位置) |
| M | 未公开/差异 | - | 实质公开 | [0318]-[0320](ROI信息指示空间位置并定位对应Tile/Slice) |
| N | 实质公开 | [0055], [0197](抽取感兴趣区域Tile形成局部码流) | 毫无异议公开 | [0027], [0331], [0338](选取目标Tile的VCL NAL形成转换后码流) |
| O | 毫无异议公开 | [0018], [0055](spatial sub-parts, region of interest) | 毫无异议公开 | [0014]-[0015], [0318](表示ROI感兴趣区域的部分视频图像) |
| P | 毫无异议公开 | [0055], [0172](独立解码部分视频图像) | 毫无异议公开 | [0022], [0339](重写后的转换码流可被解码器解码) |
| Q | 未公开 | 属于择一性特征;无“预存多个不同版本供选择”的教导 | 未公开 | 无“预存多个不同版本供选择”的教导(均采用实时重写/转换) |
| R | 毫无异议公开 | [0171]-[0172](解码抽取后的Tile码流) | 毫无异议公开 | [0169], [0339](解码转换后的包含ROI的码流) |
| S | 毫无异议公开 | [0120]-[0121](基于Sub-image/Tile的display_width/height) | 毫无异议公开 | [0320](将SPS/PPS中的图片尺寸参数修改为第二图片大小后解码) |
| T | 毫无异议公开 | [0018], [0121](子区域尺寸小于原全图尺寸) | 毫无异议公开 | [0027], [0320](抽取后的局部图像尺寸小于原图尺寸) |
---
## 三、 最接近对比文件的选择与技术问题/效果分析
在本专利的创造性评估中,**D2(US20160255354A1)最适合作为“最接近的对比文件”**。
### 1. 技术问题与效果对照分析
* **本专利解决的技术问题与效果**:
* *技术问题*:如何在不重新完整编码/传输全图的前提下,高效提取并解码视频/图像的局部空间区域(ROI/Sub-array),同时确保解码器能够以正确的局部图片尺寸(第二图片大小)无缝解码该子集码流。
* *技术效果*:通过基于元数据直接“重写(rewrite)”NALU报头(如修改Slice Header或PPS/SPS中与图像尺寸/位置相关的参数),将大图码流裁剪为仅含子阵列的第二码流,避免了繁重的解码后二次编码计算,显著降低了传输带宽与解码开销。
* **对比文件D2(US20160255354A1)**:
* *整体技术方案*:D2公开了一种分层/高分辨率图像的编码数据转换器及解码器(Encoded Data Converter / Decoder)。其核心在于接收用户输入的感兴趣区域(ROI)元数据,根据ROI定位到对应的Tile/Slice,并在不重新解码图像像素的前提下,直接由转换器**“修正/重写(correct/rewrite)”参数集(Parameter Sets,如SPS/PPS,属于Non-VCL NALU报头)中的图像尺寸、Tile信息及位置偏移量**,生成仅包含目标Tile的第二码流并传输给解码器解码(D2段落 [0027], [0316]-[0339])。
* *技术问题与效果匹配度*:与本专利完全一致,均旨在解决“**基于ROI快速裁剪码流、修改报头参数以符合局部尺寸并直接解码**”的问题。
* **对比文件D1(US20160105690A1)**:
* D1侧重于在ISOBMFF(ISO基础媒体文件格式)的封装层(Meta Box / Item)中建立Tile与主图的描述性元数据关联,从而实现静止图像Tile的快速提取(D1段落 [0030], [0065])。其主要解决的是**文件封装格式(File Format)层面的元数据索引问题**,未深入探讨在视频/图像编解码协议层(NALU Header)进行报头重写(rewriting)的技术细节。
**结论**:**D2是唯一的最佳最接近对比文件**。D2公开了本专利权利要求1绝大部分的核心技术特征,特别是“网络抽象层单元(NALU)报头重写”的机理。
---
## 四、 未被最接近对比文件公开的特征及最薄弱特征分析
### 1. 未被D2完全公开的特征分析
比对可知,本专利权利要求1中**特征Q**(“从针对不同子阵列大小的网络抽象层单元的多个不同版本选择针对切片的子阵列的网络抽象层单元的版本”)未被D2公开,也未被D1公开。
但需要特别指出的是,特征Q在权利要求1中是以 **“和/或(and/or)”** 形式与**特征I-P**连接的:
> 特征:…… [特征I-P:重写NALU形成第二视频流] **和/或** [特征Q:从针对不同子阵列大小的网络抽象层单元的多个不同版本选择……]
根据专利审查指南,对于“A **和/或** B”形式的择一性方案,**只要侵权产品或对比文件落入“A”这一分支,即可认定特征覆盖**。本专利特征I-P代表了“实时重写NALU”分支,而特征Q代表了“预存多个版本供选择”分支。
### 2. 本专利权利要求1最薄弱的技术特征
若针对本专利提起无效宣告请求,**最薄弱的技术特征是:特征I、J、K、L、M的结合(即“基于元数据选择报头位置并重写NALU”这一重写机制)**。
#### 薄弱性原因分析:
1. **概念等效性极高**:本专利的“重写(rewrite)”在D2中对应为“修正/更新(correct / update / modify)”。D2的段落 [0316]-[0330] 极其详尽地描述了转换器(Converter)在解析到ROI元数据后,定位到SPS/PPS(即NALU的报头部分)中的 `pic_width_in_luma_samples`、`pic_height_in_luma_samples` 以及 Tile Offset 位置,并将其修改为目标Tile子阵列对应的尺寸和偏移参数。
2. **实施主体的争辩点**:本专利权1在前文声称“所述方法由解码器装置执行”,但在后文又包含“重写网络抽象层单元形成第二视频流”。在实际解码架构中,“重写码流”往往由**流媒体服务端/中间转换节点(如D2的Converter)** 完成,或者由解码器前端的“流解析/重写模块”完成。
* **无效突破口**:专利权人可能会辩称“D2的重写发生在Converter(转换器),而本专利发生在Decoder(解码器装置)”。但本领域技术人员(POSITA)显而易见能够想到将D2中的Converter前置模块集成到解码器装置(Decoder Device)的前端处理单元中,或者将“解码器装置”理解为包含码流预处理模块的广义解码系统,因此该区别特征极其容易被认定为**显而易见的技术手段置换**。
---
## 五、 进一步的对比文件检索策略(针对无效宣告)
为了彻底击毁本专利权利要求1(及可能存在的从属权利要求),建议采取以下进一步检索策略:
### 1. 核心检索要素(Technical Features & Keywords)表达
* **主题词组合 1(NALU重写/修改)**:
* `NAL unit` / `NALU` / `slice header` / `parameter set` / `SPS` / `PPS`
* `rewrite` / `modify` / `update` / `overwrite` / `patch` / `convert` (重写/修改/替换)
* **主题词组合 2(瓦片/切片/局部解码)**:
* `tile` / `slice` / `sub-picture` / `sub-array` / `region of interest` / `ROI`
* `extract` / `crop` / `partial decoding` (提取/裁剪/局部解码)
* **IPC / CPC 分类号限制**:
* `H04N 19/167`(涉及感兴趣区域 ROI 的视频编码)
* `H04N 19/174`(涉及切片 Slice 的视频编码)
* `H04N 19/172` / `H04N 19/30` / `H04N 19/46`(涉及参数集、NALU报头语法及可扩展编码)
### 2. 精准检索方向推荐
1. **针对“解码器端实时重写 Slice Header”的补充检索**:
* 重点检索 **HEVC / OMAF(Omnidirectional Media Format,360度全景视频传输)** 标准制定期间(2013年–2016年)的提案(MPEG / JCT-VC 工作文档)。
* *理由*:在VR/全景视频VR拼接领域,自由视角(Viewport)提取普遍采用“解析头文件 -> 修改Slice Header中的 `slice_segment_address` 和 PPS ID -> 送入硬件解码器”的流程。例如 **MPEG-OMAF 运动图像专家组关于 Tile-based Streaming 的提案** 中大量公开了“修改 Slice Header 位置参数以实现单Tile作为独立图像解码”的技术。
2. **针对特征 Q(预存多版本 NALU 选择)的补充检索**:
* 检索 **DASH(Dynamic Adaptive Streaming over HTTP)** 协议中针对多码率/多空间分辨率 Tile 的描述文件(MPD)。
* *理由*:DASH 标准允许服务器预先生成并存储针对不同Tile集合的 `Parameter Set NALU` 或 `Extractor NALU` 的不同版本(Different Versions),客户端根据带宽和显示区域直接选择(Select)对应的 NALU 版本下载解码。
### 3. 联合对比文结合方案预演
* **组合 1**:以 **D2(US20160255354A1)** 为主对比文件(公开了特征 A-P, R-T),结合 **OMAF/DASH 领域的公知常识/标准提案**(公开将转换重写模块置于解码终端,或预存多版本 NALU),证明权利要求1不具备创造性(三步法评述)。
* **组合 2**:以 **D1(US20160105690A1)** 为主对比文件(公开 Tile 封装与提取),结合 **D2**(公开 NALU/参数集报头重写修改),证明两者的结合属于本领域的常规技术选择,具备明确的技术结合启示。
根据权利要求1所述的方法,其中所述部分地重写包括针对具有变更的比特长度 of 切片的子阵列中的每个切片重写位于网络抽象层单元中的报头中的参数;以及改变所述参数之后的所述报头中的比特的一部分相对于网络抽象层单元的起始点的位置;以及在网络抽象层单元中添加或移除填充比特使得在网络抽象层单元中的所述报头之后的数据的开始在多比特字边界处对齐;其中报头的所述部分的长度和添加或移除的填充比特的数量基于元数据来确定。
根据权利要求1或2所述的方法,其中所述部分地重写包括使用切片的空间位置的变更的指示的预定集合来重写针对切片的子阵列的网络抽象层单元中的切片的空间位置的指示;由此变更的指示区分子阵列中的切片的空间位置。
根据权利要求3所述的方法,包括定义切片在空间阵列中的空间位置的指示的值到指示切片在切片的子阵列中的空间位置的目标值的映射;将所述子阵列改变成新的子阵列;所述新的子阵列包括不同于所述子阵列的切片的至少一个切片;对于属于新的子阵列和所述子阵列之间的重叠的切片保持所述映射中的切片的空间位置的指示的目标值;使用不属于重叠的至少一个切片的空间位置的指示的目标值来重新定义所述映射;对解码的部分视频图像进行后处理以在对应于它们在完整视频图像中的空间序列的空间序列中重新定位对应于新的子阵列的切片的图像块。
根据权利要求4所述的方法,其中所述解码包括仅使用包括独立于帧间关系编码的图像数据的第一网络抽象层单元来解码不属于连续帧的重叠的新的子阵列的切片;并且切换到使用第二网络抽象层单元来解码;第二网络抽象层单元包括使用帧间关系对其中第二网络抽象层单元包括独立于帧间关系编码的图像数据的帧之后的帧编码的图像数据。
根据权利要求1或2所述的方法,由通信地耦合到源设备的目的地设备执行;所述方法包括从源设备获得仅针对子阵列的网络抽象层单元;并且在目的地设备中接收网络抽象层单元和它们在目的地设备中用于所述解码之间执行网络抽象层单元的所述部分重写。
根据权利要求6所述的方法,所述方法包括从源设备选择性地获得针对子阵列的网络抽象层单元;使用来自第一视频流的第一和第二版本的网络抽象层单元从源设备选择性地获得针对新的子阵列的网络抽象层单元;第一版本包括基于帧间关系的图像数据并且第二版本仅包括独立于帧间关系编码的数据;来自第一和第二版本的网络抽象层单元分别被用于子阵列和新的子阵列之间的重叠内和重叠外的切片直到其中第一版本的网络抽象层单元包括独立于帧间关系编码的帧的帧;以及随后使用包括依赖于针对新的子阵列内的所有切片的帧间关系编码的图像数据的网络抽象层单元获得网络抽象层单元。