非显而易见杯

专利无效挑战赛

目标专利:1149用于多媒体数据的处理的方法和装置

专利公开号:CN104704793B

专利权人:瑞典爱立信有限公司

无效请求书提交日期:2026年


上一项目 下一项目

非显而易见性评估仅供参考,不构成法律建议。



权利要求列表点击可跳转

序号 权利要求内容

1

一种用于向自适应HTTP流播播放器提供媒体内容的方法,所述方法包括如下步骤,;-从自适应HTTP流播播放器接收请求所述媒体内容的HTTP请求(S21);-将所述媒体内容标识为在固定质量接口上可用的媒体内容(S22);-确定在所述固定质量接口上提供的所述媒体内容的表示偏好指示,其中所述表示偏好指示指示所述媒体内容的优选表示(S23);-向所述自适应HTTP流播播放器发信号通知所述表示偏好指示(S24),以便指令所述自适应HTTP流播播放器使用所述媒体内容的所述优选表示请求在所述固定质量接口上提供的所述媒体内容。

2

如权利要求1所述的方法,其中所述标识步骤(S22)包括,;检查可用SDP会话描述协议文件;以找到对应于用所述HTTP请求接收的媒体分段的SDP文件。

3

如权利要求1所述的方法,其中所述标识步骤(S22)包括,;评估在所述HTTP请求中接收的内容标识符。

4

如权利要求1所述的方法,其中所述方法包括,;进一步检查;通过固定质量接口提供所述内容数据是否有可能。

5

如权利要求1所述的方法,其中所述标识步骤(S22)包括,;确定;具有固定质量的媒体内容在高速缓存中是否可用。

6

如权利要求1至5中任一项所述的方法,其中所述确定步骤(S23)包括,;从SDP会话描述协议文件中导出所述表示偏好指示。

7

如权利要求1至5中任一项所述的方法,其中所述确定步骤(S23)包括,;从MPD媒体表示描述文件中导出所述表示偏好指示。

8

如权利要求1至5中任一项所述的方法,;其中所述表示偏好指示是位数数字或字符串表示。

9

如权利要求1至5中任一项所述的方法,;其中所述表示偏好指示是若干表示的子集。

10

如权利要求1至5中任一项所述的方法,其中所述发信号通知步骤(S24)包括,;向针对所述HTTP流播播放器的响应添加所述表示偏好指示。

11

如权利要求1所述的方法,;其中所述固定质量接口是提供正在广播的数据的接口。

12

如权利要求1所述的方法,;其中所述固定质量接口是提供存储在高速缓存中的数据的接口。


对比文件列表

编号 名称
0 2011-05-12_WO2011054377A_发明申请_WO2011054377A1 STREAMING WITH OPTIONAL BROADCAST DELIVERY OF DATA SEGMENTS_+++A_X_b_c_d_e_f_g_j_k_l_m_n_o_r_s_v_w_y+++.docx
0 2012-06-07_US2012144445A_发明申请_US20120144445A1 METHOD AND APPARATUS FOR DISTRIBUTING VIDEO_+++A_b_l_o_x_y+++.docx
0 2012-06-07_WO2012074874A_发明申请_WO2012074874A1 METHOD AND APPARATUS FOR RECEIVING MULTICAST VIDEO USING A PLAYLIST_+++A_B_O_X_Y+++.docx
0 2012-07-19_WO2012096372A_发明申请_WO2012096372A1 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造_+++A_X+++.docx

权利要求1

一种用于向自适应HTTP流播播放器提供媒体内容的方法,所述方法包括如下步骤,;-从自适应HTTP流播播放器接收请求所述媒体内容的HTTP请求(S21);-将所述媒体内容标识为在固定质量接口上可用的媒体内容(S22);-确定在所述固定质量接口上提供的所述媒体内容的表示偏好指示,其中所述表示偏好指示指示所述媒体内容的优选表示(S23);-向所述自适应HTTP流播播放器发信号通知所述表示偏好指示(S24),以便指令所述自适应HTTP流播播放器使用所述媒体内容的所述优选表示请求在所述固定质量接口上提供的所述媒体内容。


未提交复审委

无效理由:专利法第二十二条

蒋 晓勇
@jxy

作为一名经验丰富的专利代理师,我将为您对目标专利(CN104704793B)的权利要求1结合说明书进行合理解释,并与对比文件D1(WO2011054377A1)的原文进行客观、严谨的特征比对与创造性分析。

---

### 一、 结合目标专利说明书解释权利要求1

在进行特征比对前,首先结合目标专利说明书的公开内容,对权利要求1中的核心实质性术语进行界定:

1. **自适应HTTP流播播放器**:对应说明书\[0001\]、\[0003\]-\[0005\],明确指代**DASH播放器**(如MPEG-DASH播放器)或苹果的HLS播放器。这是一种客户端控制的、根据链路比特率动态取分段并调整媒体质量的播放器。

2. **固定质量接口**:对应说明书\[0042\],是指**给数据提供固定数据质量的任何接口**。其实施例包括**eMBMS广播传送接口**或**高速缓存(Cache)接口**。其特征在于,在接收媒体内容期间,其质量或表示不随单播链路状态而改变,客户端不需要定期执行链路速率测量和切换表示的决定。

3. **表示偏好指示**:对应说明书\[0064\]、\[0068\]-\[0070\],是指指示多媒体内容优选表示的信号,其可以格式化为**位数数字、字符串或自适应集合偏好指示符**,在技术实现上可作为 **HTTP 响应中的 HTTP 标题(HTTP Header)** 携带。其作用在于**指令/让自适应播放器停止其单播测量**,并直接请求在固定质量接口(如广播或缓存)上已有的优选表示。

---

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

以下将权利要求1的各个技术特征,与对比文件 **D1: WO2011054377A1** (STREAMING WITH OPTIONAL BROADCAST DELIVERY OF DATA SEGMENTS) 逐一进行比对。

#### 1. 逐字/实质公开情况分析及详细出处

* **技术特征A**:`-从自适应HTTP流播播放器接收请求所述媒体内容的HTTP请求(S21)`

* **D1公开情况**:**实质公开**。

* **详细出处**:D1说明书第\[p0019\]段明确公开:"For example, a streaming client may send a HTTP request with the delivery source identifier and, in response to the request, receive the data segment 210..."。

* **比对分析**:D1公开了流媒体客户端发送HTTP请求以获取媒体数据段,虽然其主要以HTTP Live Streaming (HLS) 为例(见\[p0019\]),但其流播客户端本质上也是一种自适应HTTP流播播放器,代理/服务器接收该请求。因此特征A被D1实质公开。

* **技术特征B**:`-将所述媒体内容标识为在固定质量接口上可用的媒体内容(S22)`

* **D1公开情况**:**实质公开**。

* **详细出处**:D1说明书第\[p0010\]、\[p0020\]、\[p0032\]段。例如\[p0020\]公开:"the broadcast indicator 120 can be selectively added to the descriptive file 100 so as to indicate whether broadcast delivery of the stream 200 is available." 且\[p0032\]公开,代理服务器(hybrid proxy server 350)基于流行度确定是否启动广播并向描述文件中添加广播指示符。

* **比对分析**:目标专利的“固定质量接口”包含广播(eMBMS)接口。D1中代理服务器识别该媒体流是否可以通过广播信道(broadcast delivery,基于MBMS或FLUTE,见\[p0021\])提供,这在实质上等同于“将媒体内容标识为在广播(固定质量)接口上可用”。因此特征B被D1实质公开。

* **技术特征C**:`-确定在所述固定质量接口上提供的所述媒体内容的表示偏好指示,其中所述表示偏好指示指示所述媒体内容的优选表示(S23)`

* **D1公开情况**:**未公开(或存在实质差异)**。

* **详细出处**:D1说明书第\[p0010\]、\[p0020\]段。

* **比对分析**:D1中虽然公开了在描述文件(descriptive file)中添加“广播指示符(broadcast indicator 120)”,用于指示广播是否可用,并且该指示符可以包含访问广播频道的参数(如端口号、多播地址,见\[p0020\])。**但是,D1的广播指示符仅仅是告诉客户端“广播可用”并提供通道接入信息,并未涉及在多种质量的媒体表示中“确定并指示一个特定的优选表示(表示偏好指示)”**。目标专利的特征C是在网络侧确定客户端应使用的具体优选质量等级(表示),从而在接口层级进行约束。D1并未公开确定“表示偏好指示”这一特征。

* **技术特征D**:`-向所述自适应HTTP流播播放器发信号通知所述表示偏好指示(S24),以便指令所述自适应HTTP流播播放器使用所述媒体内容的所述优选表示请求在所述固定质量接口上提供的所述媒体内容。`

* **D1公开情况**:**未公开**。

* **详细出处**:D1说明书第\[p0010\]、\[p0036\]、\[p0053\]段。

* **比对分析**:D1公开的是通过在**描述文件(清单文件/M3U8/Manifest)**中加入广播指示符发给客户端,客户端接收到描述文件后,自主决定是否切换到广播接收(见\[p0036\]、\[p0053\])。而目标专利的特征D是**在HTTP响应层面(例如在针对分段请求的HTTP Header中,见目标专利说明书\[0068\]、\[0084\])**发送表示偏好指示,从而**指令**播放器停止单播测量并强制或引导其使用该优选表示请求固定质量接口。两者的控制维度、信令位置(清单文件 vs HTTP响应头)以及对客户端自适应算法的控制机制完全不同。D1未公开特征D。

---

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

权利要求1的技术特征目标专利说明书对应出处对比文件D1(WO2011054377A1)对应原文/出处比对结论
前序部分:一种用于向自适应HTTP流播播放器提供媒体内容的方法,所述方法包括如下步骤:\[0001\]-\[0005\]\[p0002\]-\[p0003\], \[p0017\]: "...method of streaming data in a mobile communication network..."被实质公开
技术特征A:-从自适应HTTP流播播放器接收请求所述媒体内容的HTTP请求(S21)\[0050\]\[p0019\]: "...a streaming client may send a HTTP request with the delivery source identifier and, in response to the request, receive the data segment 210..."被实质公开
技术特征B:-将所述媒体内容标识为在固定质量接口上可用的媒体内容(S22)\[0042\], \[0051\]\[p0020\], \[p0032\]: "...adds the broadcast indicator to the descriptive file so as to indicate that broadcast delivery of the stream is now available."被实质公开
技术特征C:-确定在所述固定质量接口上提供的所述媒体内容的表示偏好指示,其中所述表示偏好指示指示所述媒体内容的优选表示(S23)\[0061\]-\[0065\]\[p0020\] (仅提及指示广播可用性及频道参数,未公开确定特定的质量表示偏好指示)未公开
技术特征D:-向所述自适应HTTP流播播放器发信号通知所述表示偏好指示(S24),以便指令所述自适应HTTP流播播放器使用所述媒体内容的所述优选表示请求在所述固定质量接口上提供的所述媒体内容。\[0066\]-\[0070\], \[0084\]\[p0010\], \[p0036\] (D1通过修改/下发主描述文件由客户端自行决定切换,未在响应中下发指令特定表示的偏好指示)未公开

---

### 三、 最接近对比文件(D1)分析

根据无效宣告程序及创造性审查指南的要求,判断哪个对比文件适合作为最接近的对比文件(最接近的现有技术),需从技术领域、解决的技术问题以及技术效果和技术特征重合度三个维度进行综合考量:

1. **技术领域及技术特征重合度**:D1(WO2011054377A1)同样属于移动通信网络中的流媒体传输技术领域,具体涉及将自适应HTTP流媒体(如HLS)与广播传送(如MBMS/FLUTE)技术相结合。从上述比对可以看出,权利要求1的前序部分、特征A、特征B均已被D1公开,其技术框架与目标专利高度重合。

2. **解决的技术问题**:

* **目标专利**试图解决:当自适应流播播放器无法感知网络底层是否处于广播覆盖、或由于缓存可用而导致播放器频繁在单播下错误地测量链路比特率并盲目切换质量,导致QoE降低和单播网络资源浪费的问题(说明书\[0011\]-\[0014\])。

* **D1**试图解决:在流媒体点播/直播中,大量客户端通过单播重复请求相同数据导致网络带宽资源严重消耗的问题(说明书\[p0007\]-\[p0008\])。

* **分析**:两者均聚焦于“如何引导自适应流媒体客户端从单播切换到广播以优化网络资源”这一核心问题。

3. **技术效果**:两者均达到了降低单播网络资源占用、优化多媒体递送效率的技术效果。

**结论**:**对比文件D1(WO2011054377A1)在创造性分析中非常适合作为最接近的对比文件。** (由于本案目前仅提供D1一份对比文件,若后续引入其他对比文件,D1仍可作为主要的第一出发点)。

---

### 四、 区别技术特征及无效请求方的薄弱环节

基于D1作为最接近的现有技术,目标专利权利要求1相对于D1的**区别技术特征**为:

> **特征C与特征D的结合**:即“网络侧(HTTP实体)确定具体的媒体内容表示偏好指示(优选表示),并通过发信号(如在分段请求的HTTP响应信令中)通知给播放器,从而主动指令播放器使用该优选表示请求固定质量接口上的内容”。

#### 针对无效宣告请求方(发起无效的一方)最薄弱的技术特征:

如果我是无效宣告的请求方(或者是为请求方评估风险的代理师),我认为**最薄弱(即最难被攻破、最难证明显而易见性)的技术特征是:特征D中“网络侧通过发信号通知表示偏好指示,以指令自适应播放器请求该优选表示(停止单播带宽测量及自主切换算法)”这一控制机制。**

**理由如下:**

1. **技术偏见与常规架构冲突**:在标准的自适应流媒体标准(如MPEG-DASH、Apple HLS)中,“客户端绝对控制(Client-controlled)”是该技术的根本立足之本(目标专利说明书\[0005\]也承认这一点)。传统的切换逻辑(如D1)全部是“网络侧更新清单文件/描述文件 $\rightarrow$ 客户端下载清单 $\rightarrow$ 客户端自适应算法根据自身测量的带宽决定请求哪种质量”。

2. **目标专利的实质创新点(非显而易见性所在)**:目标专利打破了客户端绝对控制的常规,允许HTTP实体在**处理分段请求的HTTP响应层面**(即会话进行中的动态交互信令),直接向播放器喂入一个“偏好指示”,**指令**播放器“不要再测速了,直接用我给你的这个质量去广播/缓存接口拿数据”(说明书\[0076\])。

3. **D1的阻碍(Teach-away)**:D1(\[p0036\]、\[p0040\])的思路依然是传统的,它通过强制客户端去更新描述文件(descriptive file),或通过故意停止某个分段的广播来“逼迫”客户端发送单播请求以测算流行度。D1的架构极度依赖客户端周期性的单播行为和描述文件的解析。

**无效应对策略建议**:

请求方如果仅凭D1,是无法破坏权利要求1的创造性的。要想成功无效权利要求1,请求方必须在补充检索中寻找满足以下条件的证据(D2或公知常识):

* 是否存在某篇文献公开了“在HTTP代理或Cache响应中,通过扩展HTTP Header(响应头)来干预或覆盖(Override)自适应流媒体播放器(DASH/HLS)底层自适应速率选择算法”的技术手段。

* 如果找不到这种在“响应信令层面对自适应算法实施顶层指令”的证据,权利要求1的创造性将非常稳固,该特征即为请求方最难攻克的薄弱点。


未提交复审委

无效理由:专利法第二十二条

蒋 晓勇
@jxy

作为一名经验丰富的专利代理师,我将为您对目标专利的权利要求1进行深度解析,并结合三份对比文件(D1: US2012144445A、D2: WO2012074874A、D3: WO2012096372A)进行详尽的侵权/无效技术特征比对,最后为您制定无效宣告请求的创造性策略。

首先需要指出的是,**对比文件D1(US2012144445A)与对比文件D2(WO2012074874A)在说明书文本、附图编号、甚至实质技术方案上几乎完全相同**(D2同日申请且互为相关申请,其附图1-22及技术细节完全对应D1的图1-22)。因此,在创造性分析中,D1和D2可以共同或任选其一作为最接近的现有技术进行评价。

---

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

目标专利(CN104704793B)核心解决的是在DASH(自适应HTTP流播)架构下,客户端播放器在进入广播/组播覆盖区域、或者有高速缓存可用时,由于“盲目”进行单播带宽测量而导致不必要切换、延迟及网络单播资源浪费的技术问题。

权利要求1被拆解为以下4个独立的技术特征:

* **技术特征A**:-从自适应HTTP流播播放器接收请求所述媒体内容的HTTP请求(S21)

* **技术特征B**:-将所述媒体内容标识为在固定质量接口上可用的媒体内容(S22)

* **技术特征C**:-确定在所述固定质量接口上提供的所述媒体内容的表示偏好指示,其中所述表示偏好指示指示所述媒体内容的优选表示(S23)

* **技术特征D**:-向所述自适应HTTP流播播放器发信号通知所述表示偏好指示(S24),以便指令所述自适应HTTP流播播放器使用所述媒体内容的所述优选表示请求在所述固定质量接口上提供的所述媒体内容。

> **代理师关键概念澄清(固定质量接口)**:根据目标专利说明书[0042]段解释,“固定质量接口”是指给数据提供固定数据质量的接口,其实施例包括**eMBMS广播接口**、**IP多播/组播接口**或**高速缓存接口**。其本质在于网络侧/代理侧提供了给定固定质量的分段,客户端无需进行单播的自适应改变测量。

---

## 二、 目标专利与对比文件的技术特征比对表格

以下紧密结合对比文件原文及详细出处,对权利要求1的各技术特征进行毫无异议公开(实质公开)的比对:

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

目标专利权利要求1的技术特征对比文件1:D1 (US2012144445A) <br> [同等对应D2 (WO2012074874A)]对比文件3:D3 (WO2012096372A)比对结论与分析
技术特征A:从自适应HTTP流播播放器接收请求所述媒体内容的HTTP请求(S21)实质公开。<br>【原文出处】:[0045]、[0082]段、图4、图8。<br>【原文对应】: AMGR Client利用HTTP Get请求从Adaptation Server请求分段。AMGR路由代理实体代为接收或拦截请求。毫无异议公开。<br>【原文出处】: [2]通信制御部110、[2]利点1段、图5步骤S8。<br>【原文对应】: 再生装置100の通信制御部110(DASH/DASH客户端)通过发送HTTP要求(HTTP请求)至配信サーバ300(媒体服务器)。D1、D2、D3均完全公开了自适应HTTP流播播放器(如DASH、HLS播放器)发送HTTP请求这一标准协议架构。
技术特征B:将所述媒体内容标识为在固定质量接口上可用的媒体内容(S22)毫无异议公开。<br>【原文出处】: [0045]、[0048]、[0103]段、图4。<br>【原文对应】: AMGR路由器解析Playlist(清单文件)判断内容是否为"Live"(直播)。[0045]段明确AMGR“acts on behalf of multiple client devices... requests and receives video chunks... over a TCP transport. It then redistributes... using an RTP multicast transmission”(代客户端通过组播转发)。即AMGR(网关/实体)标识出该媒体内容是在组播(固定质量接口)上可用的。毫无异议公开。<br>【原文出处】: [2]通信制御部110、[2]配信サーバ300段、图5步骤S3-S5。<br>【原文对应】: 通信制御部110根据MPD数据,判定该Representation(表示)的属性值是否为"Live"(组播/多播配信),从而将媒体内容标识为在多播配信(固定质量接口)上可用。完全公开。<br>D1/D2的AMGR网关,以及D3的通信控制部均执行了将当前播放内容与组播/多播(固定质量接口)进行关联标识的步骤。
技术特征C:确定在所述固定质量接口上提供的所述媒体内容的表示偏好指示,其中所述表示偏好指示指示所述媒体内容的优选表示(S23)实质公开。<br>【原文出处】: [0047]-[0050]、[0102]段、图5。<br>【原文对应】: [0047]段提出“Each video multicast group is referred to as a multicast gear.”(每个组播组称为一个multicast gear,对应不同的调制编码率/质量表示)。[0050]段指出,AMGR负责在LAN内以指定的调制和编码率(对应特定gear/表示)多播视频块。AMGR或Client通过测量的带宽来“确定”应该加入哪一个优选的gear(表示偏好)。实质公开。<br>【原文出处】: [2]通信制御部110、图5步骤S7。<br>【原文对应】: 算出当前正在多播(Live配信)的媒体分段的索引N(インデックスN)。这个正在多播的特定表示(质量级别)即为网络侧提供的优选表示。完全公开。<br>D1/D2的“Gears(档位/组播组)”以及D3算出的“当前正在多播的Index N”在实质上都对应于网络侧当前在固定质量接口上提供的“优选表示(优选质量)”。
技术特征D:向所述自适应HTTP流播播放器发信号通知所述表示偏好指示(S24),以便指令所述自适应HTTP流播播放器使用所述媒体内容的所述优选表示请求在所述固定质量接口上提供的所述媒体内容。实质公开(核心结合点)。<br>【原文出处】: [0120]段。<br>【原文对应】: 明确公开了“AVMS Mode”消息:“This message would typically originate from the AMGR, and would instruct an AMGR Client to switch the streaming mode in real-time... to multicast or unicast... an AVMS Mode message would be sent to the AMGR Clients with an instruction to switch to multicast mode.”(指令客户端切换至组播模式)。部分公开/异向实施。<br>【原文出处】: [2]通信制御部110、图5步骤S8-S9。<br>【原文对应】: 客户端自身通过计算自主加入マルチキャストグループ(多播组)来请求残余分段。D1/D2在非显而易见性上占绝对优势。<br>D1/D2显式公开了由网络侧路由实体(AMGR)向播放器发送特定指令消息(AVMS Mode)来“指令客户端切换至优选的组播”。而D3是由客户端自主切换。

---

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

在本案的无效请求审查中,**适合作为最接近的对比文件(D1或D2任选其一,本节以D1为例)**。

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

* **目标专利**:解决自适应HTTP流播播放器在进入广播/单播混合覆盖区域时,播放器无法感知广播状态,导致盲目测量、在单播/组播间错误切换,从而降低用户体验(QoE)和浪费网络带宽的问题。

* **对比文件D1**:其背景技术[0011]-[0015]同样聚焦于多个HTTP Live Streaming(HLS)客户端在同一区域接收相同内容时占用大量TCP单播带宽造成的瓶颈问题。其核心目的在于通过引入智能网关路由器(AMGR)将单播流转换为组播流转发,降低核心网带宽需求,同时允许客户端在不同质量档位(Gears)间自适应切换。

* **技术问题一致性**:二者完全聚焦于“**如何在高密度播放环境下,利用组播/广播(固定质量)手段优化自适应流媒体播放器的带宽消耗与自适应体验**”。

### 2. 技术效果角度

* **目标专利**:实现由网络实体/代理发信号通知表示偏好,从而控制/停止客户端播放器的自适应单播测量,强制其稳定在固定质量(广播)接口。

* **对比文件D1**:通过AMGR实体发送“AVMS Mode”等控制消息,实时指令(instruct)客户端在单播和组播之间切换([0120]段),同样达到了由网络侧智能控制播放器选择组播优选表示、降低单播带宽开销的技术效果。

因此,**D1/D2与目标专利的主题最紧密、技术领域完全相同、解决的技术问题和达到的技术效果最接近,是本案当之无愧的最接近的对比文件。**

---

## 四、 结合对比文件的创造性评述(无效宣告论证)

### 1. 权利要求1的技术方案已被D1/D2与现有技术实质公开

基于前述特征拆解,当以D1(公开号:US20120144445A1)或D2(公开号:WO2012074874A1)作为最接近的对比文件时:

* **技术特征A、B、C**已完全被D1的智能网关(AMGR)系统公开:AMGR负责拦截/接收客户端的HLS请求,并将其映射到当前可用的、具有固定质量的组播Gear(固定质量接口)上。

* **技术特征D的关键点**在于由网络实体“向播放器发信号通知偏好指示以进行指令请求”。D1在[0120]段明确公开了“AVMS Mode”下发机制,该机制由网络侧AMGR主动下发,用于**指令(instruct)自适应客户端切换至对应的组播模式(即请求固定质量接口上的媒体内容)**。

因此,权利要求1所请求保护的“向播放器通知偏好以指令其请求固定质量内容”的实质,已经被D1的“由AMGR向客户端下发AVMS Mode指令其切换至组播档位”完全实质公开。本领域技术人员在D1的基础上,结合常规的DASH清单/代理拦截常识,无需付出创造性劳动即可获得权利要求1的技术方案。**权利要求1不具备创造性。**

---

## 五、 请求方最薄弱的技术特征(抗辩难点预警)

在后续的无效宣告口头审理中,专利权人最可能据理力争、同时也是**对请求方(无效宣告提起方)而言最薄弱、需要重点攻坚的技术特征是:**

> **技术特征D**:“向所述自适应HTTP流播播放器发信号通知所述表示偏好指示……以便指令所述自适应HTTP流播播放器**使用所述媒体内容的所述优选表示请求……**”

### 弱点原因分析:

1. **概念表述的外延差异**:目标专利中,发信号通知的偏好指示是指**“具体的媒体质量表示(如特定的比特率、或清单文件中的Representation ID)”**,例如其说明书[0084]段所述“向HTTP响应添加优选MQ表示的指示……偏好指示符:中等质量”。

2. **D1/D2的公开偏向于“模式指令”而非“具体质量表示”**:D1的[0120]段公开的AVMS Mode,其文字表述是指令客户端“切换流播模式(**switch the streaming mode**... to multicast)”。

3. **专利权人的潜在抗辩**:专利权人一定会辩称:“D1仅仅是通知客户端‘去听组播’,客户端依然要自己去选Gear(自适应调速);而本发明是直接通知了‘哪一个表示是优选表示’,从而使播放器可以直接使用该优选表示去请求,免去了测量过程。D1没有公开‘发信号通知表示偏好指示’这一特征。”

### 请求方的破解与补强策略:

为了防止在此特征上被专利权人抗辩成功,请求方必须在无效请求书中建立如下**逻辑链条**:

* **多特征耦合论证**:紧密结合D1的[0047]、[0050]和[0105]段。D1中每个Multicast Gear(组播组)在定义上就唯一对应一个具体的视频分辨率和编码率(即表示质量)。当AMGR通过AVMS Mode指令客户端切入Multicast时,其必然伴随着下发“Chunk Information message”(块信息消息),该消息内直接包含了该Multicast Gear对应的特定组播组IP和URL。

* **等同替换/实质公开**:下发特定组播Gear的URL或下发AVMS Mode切换指令,其技术实质就是向客户端指示了网络侧期望其请求的“优选表示”。两者在手段、功能和效果上完全相同,属于本领域技术人员的惯用技术手段替换,不具备创造性。


权利要求2

如权利要求1所述的方法,其中所述标识步骤(S22)包括,;检查可用SDP会话描述协议文件;以找到对应于用所述HTTP请求接收的媒体分段的SDP文件。


权利要求3

如权利要求1所述的方法,其中所述标识步骤(S22)包括,;评估在所述HTTP请求中接收的内容标识符。


权利要求4

如权利要求1所述的方法,其中所述方法包括,;进一步检查;通过固定质量接口提供所述内容数据是否有可能。


权利要求5

如权利要求1所述的方法,其中所述标识步骤(S22)包括,;确定;具有固定质量的媒体内容在高速缓存中是否可用。


权利要求6

如权利要求1至5中任一项所述的方法,其中所述确定步骤(S23)包括,;从SDP会话描述协议文件中导出所述表示偏好指示。


权利要求7

如权利要求1至5中任一项所述的方法,其中所述确定步骤(S23)包括,;从MPD媒体表示描述文件中导出所述表示偏好指示。


权利要求8

如权利要求1至5中任一项所述的方法,;其中所述表示偏好指示是位数数字或字符串表示。


权利要求9

如权利要求1至5中任一项所述的方法,;其中所述表示偏好指示是若干表示的子集。


权利要求10

如权利要求1至5中任一项所述的方法,其中所述发信号通知步骤(S24)包括,;向针对所述HTTP流播播放器的响应添加所述表示偏好指示。


权利要求11

如权利要求1所述的方法,;其中所述固定质量接口是提供正在广播的数据的接口。


权利要求12

如权利要求1所述的方法,;其中所述固定质量接口是提供存储在高速缓存中的数据的接口。


Powered by Django

网站备案号:渝ICP备2023012882号


重庆市非显而易见网络科技有限责任公司 A Anti NPE NPE