非显而易见性评估仅供参考,不构成法律建议。
| 编号 | 名称 |
|---|---|
| 0 | 2009-04-30_US2009111790A_发明申请_US20090111790A1 HETEROARYL BENZAMIDE DERIVATIVES FOR USE AS GLK ACTIVATORS IN THE TREATMENT OF DIABETES.docx |
| 0 | WO2006073008A1_Description_20260428_0850.docx |
| 0 | JP2006201021A_Description_20260428_0849.docx |
| 0 | JP2005101799A_Description_20260428_0849.docx |
| 0 | JP2005012655A_Description_20260428_0851_+++A_B_C_E_F_G_J_K_L_M_N_O+++.docx |
| 0 | JP2003331047A_Description_20260428_0848.docx |
| 0 | EP1783219A1_Description_20260428_0851.docx |
| 0 | 2014-07-31_None_发明专利_JPWO2012153684A1 ルテニウム−ジアミン錯体および光学活性化合物の製造方法.docx |
| 0 | 2011-01-13_WO2010078281A_发明申请_WO2010078281A2 REAL-TIME OR NEAR REAL-TIME STREAMING_+++A_B_C+++.docx |
| 0 | 2010-08-05_WO2010088030A_发明申请_WO2010088030A2 MULTIPLE BIT RATE VIDEO ENCODING USING VARIABLE BIT RATE AND DYNAMIC RESOLUTION FOR ADAPTIVE VIDEO STREAMING_+++A_B_C_S_T_p+++.docx |
| 0 | 2010-06-03_US2010138545A_发明申请_US20100138545A1 STREAMING MEDIA_+++A_F_G_H_K_M_b_c_d_i_j_l_p_r_s_t_u_v+++.docx |
| 0 | 2010-01-26_US7653685B_发明授权_US07653685B2 Methods and apparatuses for transferring streaming multimedia data and various types of data associated therewith in a network environment_+++a_b_c+++.docx |
| 0 | 2009-10-01_JP2009225339A_发明专利_JP2009225339A Information processor, information processing method, and computer program_+++C_K_L+++.docx |
| 0 | 2009-10-01_JP2009225217A_发明专利_JP2009225217A Apparatus, system, and method for distributing content_+++C_G_K_N_a_b_f_h_i_l_o+++.docx |
| 0 | 2009-09-10_RU2367003C_发明专利_RU2367003C2 СПОСОБ СООБЩЕНИЯ О СКОРОСТИ ПЕРЕДАЧИ ДАННЫХ ОТ КЛИЕНТА В ПЕРЕДАЧЕ МУЛЬТИМЕДИЙНОГО ПОТОКА_+++K_f_g+++.docx |
| 0 | 2009-08-13_JP2009182417A_发明专利_JP2009182417A Communication system and video stream transmission rate control method_+++c_n_o+++.docx |
| 0 | 2001-12-27_WO2001099374A_发明申请_WO0199374A2 METHODS AND APPARATUSES FOR TRANSFERRING DATA.docx |
| 0 | 2009-03-05_WO2009029202A_发明申请_WO2009029202A2 PROXY-DRIVEN CONTENT RATE SELECTION FOR STREAMING MEDIA SERVERS_+++N_O_e_k+++.docx |
| 0 | 2009-02-12_JP2009028232A_发明专利_JP2009028232A Seat cushion frame of automobile seat.docx |
| 0 | 2008-10-23_None_发明专利_JPWO2006073008A1 ネットワークカメラへのログイン認証システム_+++G_K_L_M_Q_R_T+++.docx |
| 0 | 2007-08-02_JP2007194680A_发明专利_JP2007194680A Moving picture viewing method, and communication terminal and program_+++A_C+++.docx |
| 0 | 2006-12-28_US2006291452A_发明申请_US20060291452A1 Method and apparatus for providing reliable communications over an unreliable communications channel.docx |
| 0 | 2006-08-03_JP2006201021A_发明专利_JP2006201021A Duty measurement circuit and duty measurement method.docx |
| 0 | 2006-03-27_RU2273103C_发明专利_RU2273103C2 СПОСОБ И УСТРОЙСТВО ДЛЯ ОБМЕНА ИНФОРМАЦИЕЙ В СЕТИ СВЯЗИ_+++V+++.docx |
| 0 | 2006-03-21_US7014818B_发明授权_US07014818B2 Electrical device for evaporating volatile liquid.docx |
| 0 | 2005-04-14_JP2005101799A_发明专利_JP2005101799A Apparatus and system for radio communication.docx |
| 0 | 2005-03-10_US2005053528A_发明申请_US20050053528A1 Electrical device for evaporating volatile liquid.docx |
| 0 | 2004-04-01_US2004064573A_发明申请_US20040064573A1 Transmission and reception of audio and_or video material_+++A_C_P_S_T+++.docx |
| 0 | 2003-12-03_JP2003341891A_发明专利_JP2003341891A Film image reader.docx |
| 0 | 2003-03-13_US2003050052A_发明申请_US20030050052A1 Method and apparatus for retrieving calling party information in a mobile communications system.docx |
| 0 | 2002-05-24_JP2002152274A_发明专利_JP2002152274A Streaming media transfer method and device_+++C_D_G_K_N_O_V_a_b_e_f_i_j_l_s_t_u+++.docx |
一种在媒体客户端中用于控制包括多个连续流元素(84)的媒体流的传输的方法,所述方法包括以下步骤;获得(32)所述媒体流的媒体描述(100);所述媒体描述指示所述流元素的初始元素(92);发送(34)对所述初始元素(92)的请求;启动(36)会话控制过程以将所述媒体流与用于控制所述媒体流的传输的会话相关联,其中,能够在完成所述会话控制过程之前启动媒体流传递
作为一名经验丰富的专利代理师,我将为您深入解析本案目标专利权利要求1的法律效力与技术边界,并紧密结合对比文件D1(JP2002152274A)与D2(US20100138545A1)的原文及详细出处进行比对分析,最终为您提供无效宣告请求诉讼策略的专业建议。
---
## 一、 目标专利权利要求1的合理解释
在结合目标专利说明书(CN108270799B)对权利要求1进行整体实质性理解时,关键在于准确界定其技术边界与核心发明点。
### 1. 术语与技术边界解释
* **媒体描述 (100) / 初始元素 (92) / 媒体流传输**:
结合说明书【0005】及【0043】-【0044】可知,“媒体流”是由多个连续的流元素(如自适应HTTP流传递AHS中的流段/Segment)组成的媒体流。而“媒体描述”在实际应用中对应于媒体表示描述(MPD),其为包含描述媒体信息和属性的XML编码文件,指示了流元素的“初始元素”(例如初始流段的URI或生成URI的模板)。
* **会话控制过程 (36)**:
结合说明书【0007】-【0008】及【0046】可知,会话是指网络和客户端之间的传输上下文(如无线电接入承载),会话控制过程特指为了在传输中实施指定传输特性(如QoS预留、认证、计费规则)而进行的控制过程,在IMS控制架构下具体表现为使用包括SDP信息的SIP消息(如SIP INVITE)建立或修改会话的过程。
### 2. 核心发明点(技术方案的实质)
权利要求1的核心发明点聚焦于特征D中的限定:**“能够在完成所述会话控制过程之前启动媒体流传递”**。
结合说明书【0059】及图8的公开内容,传统IMS控制的流媒体下载(如背景技术图2)必须**先完成**繁琐的SIP会话控制信令交互(步骤1-8),在UE接收到SIP 200 OK并确保QoS预留后,**才开始**发送HTTP GET请求启动媒体传递(步骤9)。
本方案打破了这一时序限制:在发送初始元素请求(步骤34 / 图8中步骤10c的HTTP请求)的同时或稍后,**并行**启动SIP会话控制(图8中步骤11的SIP INVITE)。由于初始流段的传输(尽力而为传输)不需要等待漫长的会话建立完成(SIP 200 OK应答),从而消除了会话启动的延迟,显著提高了流媒体的“快速启动(Fast startup)”能力并增强了用户体验。
---
## 二、 对比文件技术特征比对分析
以下将对比文件D1、D2的原文与目标专利权利要求1的各技术特征进行逐项比对。
### 1. 技术特征比对表格
| 目标专利权利要求1的技术特征 | 对比文件 D1 (JP2002152274A) 的公开情况与原文出处 | 对比文件 D2 (US20100138545A1) 的公开情况与原文出处 |
| 前序部分:一种在媒体客户端中用于控制包括多个连续流元素(84)的媒体流的传输的方法,所述方法包括以下步骤; | 毫无疑问公开。<br>【0001】本発明は…メディアストリーミング体験を大幅に向上し、QoS…に対するサポートを提供する方法と構成に関する。<br>【0002】…ビデオデータおよび/またはオーディオデータを、他のコンピュータまたはサーバから選択的にダウンロードまたは「ストリーム化(streaming)」している。 | 毫无疑问公开。<br>[0001]...The present invention relates generally to streaming media.<br>[0025] A streaming client A20 is using a user application A21 to receive streaming media from a user Application A11 of a streaming server A10. |
| 特征A:获得(32)所述媒体流的媒体描述(100); | 实质公开。<br>【0044】…送信されるデータに必要なバンド幅と関係参数を記述しており、経路上を伝播されて行く。…PATHメッセージとRESVメッセージのやりとりである。PATHメッセージは、トラフィックのQoSパラメータ、送信側のアドレス、およびトラフィックのデスティネーションを記述している。<br>*(注:公开了传输数据所需的流参数及描述文件。)* | 毫无疑问公开。<br>[0004]...The RTSP DESCRIBE method can be used to retrieve stream parameters from the RTSP streaming server.<br>[0028]...The communication is started by sending a SUBSCRIBE D1 message from the client to the server...to query the current description of streaming resource... |
| 特征B:所述媒体描述指示所述流元素的初始元素(92); | 实质公开。<br>【0047】PATHメッセージは、トラフィックのQoSパラメータ、送信側のアドレス、およびトラフィックのデスティネーションを記述している。…RESVメッセージを受信すると、QoSデータフローが開始する。<br>*(注:隐含公开了流参数中必然包含数据源的寻址信息以指示待接收的流元素。)* | 毫无疑问公开。<br>[0036]...Use of URI (uniform resource identifier) user part “movies/matrix” defining the source of requested streaming media... defines that streaming is to be used... |
| 特征C:发送(34)对所述初始元素(92)的请求; | 毫无疑问公开。<br>【0048】…送信側アプリケーションは、ベストエフォートで送信を即時に開始するように構成することも可能であり…<br>【0051】クライアントデバイス104は、セットアップされるメディアストリームごとに1つのRTSP SETUPコマンドをサーバデバイス102に送信することによって、セッションセットアップを開始する。 | 毫无疑问公开。<br>[0028]...The client requests streaming media, and decides that the movie or any other multimedia stream should be played.<br>[0109]...The client starts streaming the movie.... Range and Scale Headers are sent in the INVITE message D5. |
| 特征D:启动(36)会话控制过程以将所述媒体流与用于控制所述媒体流的传输的会话相关联,其中,能够在完成所述会话控制过程之前启动媒体流传递 | 毫无疑问公开。<br>【0007】…可能な限り速やかにメディアのストリーミングを開始し、その間に、より望ましいまたは該当するQoS機能を同時にセットアップすることを基本としている。<br>【0035】図5に示すように、メディアセットアップ遅延期間302は、QoSセットアップ遅延期間304にオーバラップしている。<br>【0052】サーバデバイス102から出力されたメディアデータは、RESVメッセージが接收されるまでベストエフォートで送信される。RESVメッセージが接收されると、ストリーミングメディアデータフローは、保証QoSに変更される。 | 未公开(属于区别技术特征)。<br>D2中虽然使用了SIP信令来提供流媒体扩展(SIP-MEX),但根据其[0108]-[0135]的交互时序(图4),客户端是先发送INVITE控制信令(D5),等待服务器回应200 OK(D6)并确立传输参数后,才开始启动媒体流的传输(图4中INVITE流程之后才正式传输RTP)。其无法在控制会话完成前启动流传递。 |
---
## 三、 最接近对比文件的确定与创造性分析
在创造性评估中,选择**对比文件D1(JP2002152274A)**作为最接近的对比文件最为合适。原因如下:
### D1 适合做最接近对比文件的理由
1. **整体解决的技术问题完全一致**:
D1明确指出了流媒体在启动时面临的难题。其说明书【0004】指出用户在等待各种支持软件/硬件系统进行设置和缓冲时,会遇到“初期セッションスタートアップレイテンシ(初期会话启动延迟)”。这与目标专利背景技术【0019】、发明内容【0059】所欲解决的“减小会话建立延迟,增强用户快速启动的体验”的技术问题完全相同。
2. **核心技术构思与手段高度契合**:
目标专利的核心在于“控制会话与媒体传递并行,在会话完成前先以尽力而为传输媒体”。
反观**D1的说明书【0007】和【0035】(对应图5)**,其明确提出了核心构思:**“可能な限り速やかにメディアのストリーミングを開始し、その間に、より望ましいまたは該当するQoS機能を同時にセットアップすることを基本としている(基本构思是尽可能快地开始媒体流传输,同时在此期间设置更理想或适用的QoS功能)”**。图5清楚地展示了媒体设置延迟302与QoS设置延迟304在时间轴上高度重叠。
进一步地,**D1【0052】**指出:在RTSP/RSVP联合组网中,**“メディアデータは、RESVメッセージが接收されるまでベストエフォートで送信される(媒体数据在接收到RESV消息之前以尽力而为方式发送)”**。而RESV消息的成功接收和确认才代表RSVP“会话控制过程的完成”。因此,D1完全公开了“在完成会话控制(RSVP成功)之前,即启动媒体流传递(RTSP已发送PLAY命令并以尽力而为方式传输)”这一技术手段。
### 为什么不选择D2?
D2虽然使用了与目标专利相同的**SIP/IMS控制域(SIP-MEX)**,且公开了媒体表示描述(SUBSCRIBE/NOTIFY获取SDP文件),但其信令流程本质上仍然是**传统的“串行”架构**(必须等INVITE会话确立后才传输媒体)。D2并没有提出解决“会话建立延迟”的并行处理构思。因此,从技术实质及解决问题的角度来看,D1比D2更接近目标专利。
---
## 四、 权利要求1的创造性评述意见(组合防线)
基于上述分析,目标专利权利要求1不具备创造性。无效宣告请求方可以采用以下**对比文件组合策略**:
### 1. 独立权利要求1的无效理由:D1 + D2
* **最接近对比文件(D1)公开的特征**:
D1公开了前序部分、特征C,以及核心特征D(在会话控制RSVP完成前,基于并行重叠构思,先以尽力而为方式启动媒体流传递)。
* **D1未明确公开、但被D2公开的特征(区别特征)**:
D1中用于获取流描述以及控制媒体的协议是下层网络控制协议RSVP和应用层RTSP的结合;而目标专利的特征A、B限定了“获得媒体流的媒体描述(如XML/MPD文件)”。
这一区别特征已被**D2(US20100138545A1)**明确公开:D2在[0028]-[0107](图4)中公开了客户端通过发送SUBSCRIBE消息,从服务器接收携带流参数格式(SDP)的NOTIFY消息来获取媒体流描述,且其URL/URI中携带有“user=stream”等指示流媒体初始元素的标示。
* **结合驱动与创造性结论**:
由于D1与D2均属于流媒体传输技术领域,且D1已经明确指出其方法可以灵活“公知的或未来的类似协议(公知または将来のプロトコル)”来实现(参见D1【0022】)。当技术人员面对IMS/SIP通信网络风靡的背景时,为了使D1控制流媒体的手段能够适配IMS网络,自然有动机引入D2中利用SIP(SUBSCRIBE/NOTIFY)获取流媒体描述(SDP/XML)的标准手段。这种结合属于本领域的常规方案替换,没有产生意料不到的技术效果。因此,权利要求1在D1和D2的组合面前不具备《专利法》第22条第3款的创造性。
---
## 五、 对请求方来说最薄弱的技术特征及应对策略
如果在国家知识产权局提起无效宣告请求,对于请求方(无效方)来说,攻克该专利**最薄弱(即最容易受到专利权人顽强抵抗、最难被完全等同否定)**的技术特征是:
> **“获得所述媒体流的媒体描述” 结合 “启动会话控制过程以将所述媒体流与用于控制传输的会话相关联”(特征A与特征D的特定架构耦合)**
### 薄弱原因分析(专利权人的潜在抗辩点)
尽管D1公开了“在QoS会话控制完成前先传输流媒体”的并行构思,但D1的整体网络架构是基于 **RTSP(流媒体控制)+ RSVP(资源预约协议)** 的结合。
在D1的架构中,所谓的“媒体描述”是通过RSVP的PATH消息或RTSP的DESCRIBE方法来实现的。而目标专利说明书反复强调,其背景是自适应HTTP流传递(AHS/DASH),其媒体描述是**XML编码的MPD文件**,其会话控制是**IMS控制域下的SIP信令**。
专利权人一定会极力抗辩:*“D1的RSVP属于底层网络逐跳(Hop-by-hop)的资源预留,其并行机制是为了解决网络层带宽锁定的延迟;而本发明是在应用层/IMS核心网控制层(SIP信令)实现媒体描述(MPD)引导下的并行快速启动。D1的底层预留协议与本发明的上层会话协议(SIP)存在本质拓扑差异,技术人员没有将RSVP底层控制替换为IMS/SIP应用层控制的动机。”*
### 无效请求方的应对与突破策略
为了攻克这一薄弱点,请求方在口头审理和意见陈述书中应咬定以下辩论逻辑:
1. **坚持“上位概念”的功能等同**:
权利要求1的特征A和特征D均采用了极为上位的法律措辞(“媒体描述”、“会话控制过程”),并未在限制性条款中写入“必须为IMS网络”或“必须为XML格式的MPD”。根据**以权利要求书为准**的法律原则,D1的RTSP DESCRIBE/SDP就是“媒体描述”,D1的RSVP预留上下文就是“用于控制传输的会话”。两者在功能、手段、效果上完全等同。
2. **利用目标专利说明书的自我承认**:
目标专利说明书在【0003】中明确承认:*“RTP及相关联的控制协议RTSP……优点是……。近期的发展,自适应HTTP流传递(AHS),旨在结合这两个方案的优点。”* 这表明将传统的RTSP控制架构向新兴的AHS/IMS网络架构进行迁移,是本领域公开的演进趋势。
3. **强化D2的桥梁过渡作用**:
D2(STREAMING MEDIA)恰恰是一篇**专门解决如何将RTSP流媒体域与SIP会话域进行相互映射(Mapping)和融合**的专利(参见D2摘要、图2及图8)。D2的存在证明了,在现代IMS网络中,流媒体控制(RTSP)与会话控制(SIP)的融合与协议替换是本领域技术人员的普通常识。将D1的并行构思应用到D2的SIP控制架构中,完全是显而易见的。
作为一个经验丰富的专利代理师,我将紧密结合目标专利说明书《用于媒体流传输的会话控制》(CN108270799B)来解释权利要求1。
以下是针对您提出的各项要求的详细分析。
### 第一部分:权利要求1的技术特征解释(结合目标专利说明书)
权利要求1保护的是一种在媒体客户端中用于控制包括多个连续流元素的媒体流传输的方法。结合说明书,其各个技术特征的含义如下:
* **技术特征A:获得(32)所述媒体流的媒体描述(100)**
* **说明书解释:** 此步骤是指客户端通过下载一个文件(如XML编码文件)来获取媒体流的描述信息。在自适应HTTP流传递(AHS)的语境下,这被称为“媒体表示描述(MPD)”[0005]。该MPD是客户端为了启动媒体传送而传输的第一资源。
* **代理师注:** 这里的“获得”可以是主动请求,也可以是通过其他消息(例如会话控制响应)被动接收[0052, 0088]。
* **技术特征B:所述媒体描述指示所述流元素的初始元素(92)**
* **说明书解释:** 初始元素可以是媒体描述中指示的第一个可获得的流段(segment),例如视频轨道的第一个10秒长的段。媒体描述通过指定媒体源(如URI)或者用于生成URI的模板来指示如何获得该初始元素[0004, 0044]。
* **技术特征C:发送(34)对所述初始元素(92)的请求**
* **说明书解释:** 客户端在获得媒体描述后,根据其中指示的媒体源(URI),使用标准HTTP请求(例如HTTP GET命令)向媒体平台或服务器发送对初始流段的下载请求[0005, 0045]。
* **技术特征D:启动(36)会话控制过程以将所述媒体流与用于控制所述媒体流的传输的会话相关联,其中,能够在完成所述会话控制过程之前启动媒体流传递**
* **说明书解释:** 这里的核心在于“会话关联”和“并行/提前启动传递”。
* “会话”是在网络和客户端之间的传输上下文(例如承载),具有指定的传输特性(如QoS、计费策略)。
* “会话控制过程”可以是任何将媒体流与会话相关联的过程,例如在IP多媒体子系统(IMS)中,通过SIP信令(如SIP INVITE)来建立新会话或修改现有会话,使媒体流(通过IP地址、端口号等识别)适用该会话的控制规则(策略)[0007, 0046, 0048]。
* “能够在完成所述会话控制过程之前启动媒体流传递”意味着客户端不等待SIP会话完全确立(例如不等待接收到SIP 200 OK确认),就已经发送了对初始元素的HTTP请求(特征C)。例如,可以使用现有的尽力而为(best-effort)连接迅速开始初始传输,以增强用户启动播放的体验。
* **代理师注:** 权利要求描述的是一种操作的可能性(“能够”),即方法步骤并不严格受限于特征D必须在特征C之前或之后完成,关键在于时间上允许特征C的请求在特征D的控制过程最终结束前发送,从而实现并行操作,缩短启动延迟。
---
### 第二部分:对比文件分析及特征比对
您提供了三份对比文件,我将分别使用其公开号进行分析。
**对比文件1 (D1):US 2004/0064573 A1**
*公开日期:2004-04-01*
*技术领域:数字编码材料(如音频/视频)通过电信链路的交付。*
**对比文件2 (D2):JP 2007-194680 A**
*公开日期:2007-08-02*
*技术领域:移动终端通过通信路选择功能接收视频的方法,涉及Mobile IP和网管部。*
**对比文件3 (D3):JP 2009-182417 A**
*公开日期:2009-08-13*
*技术领域:根据电池残量控制视频流发送速率的方法,涉及RTSP/RTP信令过程。*
以下是特征比对表格,指出各对比文件原文的详细出处及对技术特征的公开情况(“+”表示公开,“-”表示未公开,“+/-”表示隐含公开或实质公开)。
#### 特征比对表格
| 权利要求1的技术特征 | 目标专利出处 | 对比文件1 (US2004064573A1) | 对比文件2 (JP2007194680A) | 对比文件3 (JP2009182417A) |
| 权利要求1前序部分:一种在媒体客户端中用于控制包括多个连续流元素的媒体流的传输的方法 | 说明书[0043]、[0022] | + (终端从远程服务器接收代表连续临时部分的文件的集合) - 参见段落 [0003]。 | + (通信终端希望接收希望的动态图像) - 参见段落 [0001]。 | + (移动通信终端使用バッテリ驱动視聴ビデオストリーム) - 参见段落 [0001]。 |
| 技术特征A:获得(32)所述媒体流的媒体描述(100) | 说明书[0005]、[0044] | +/- (请求index文件以存储可用数据速率列表) - D1公开了请求一个索引(index)文件(图3,段落 [0054]),该文件提供了可用数据速率的列表。虽然没有使用“媒体描述”一词,但实质上是一个指示流属性的描述性文件。出处:段落 [0054]。 | - | + (RTSP信令在ストリーミング准备中确定ストリーム描述(SDP)) - D3提及在SETUP前通过DESCRIBE(隐含)或SETUP(图4)确定SDP(Session Description Protocol)信息。SDP是一种媒体描述。出处:段落 [0012]、[0013]、图4。 |
| 技术特征B:所述媒体描述指示所述流元素的初始元素(92) | 说明书[0004]、[0044] | + (通过index文件确定第一个子文件的文件名(000000.bin)) - D1明确公开客户端通过索引文件确定起始子文件的文件名(例如通过在index文件所在的Stem目录下添加特定文件名)。出处:段落 [0036]、[0054]、图3(显示LFI和序列号)。 | - | +/- (SDP中包含媒体格式等信息,PLAY消息隐含指示从头开始) - D3的SDP中包含媒体有关的信息(段落[0013]),虽然SDP主要描述会话参数,但其为PLAY请求(步骤406,指示媒体数据的送出开始)打下了基础。可以认为SDP实质公开了对媒体流的指示。出处:段落 [0012]、图4。 |
| 技术特征C:发送(34)对所述初始元素(92)的请求 | 说明书[0005]、[0045] | + (构造请求消息并发送到服务器以获取初始子文件) - D1公开客户端在获得Stem URL和起始文件名后,构造URL请求消息并将其发送到服务器(例如请求bin000000.bin)。出处:段落 [0036]。 | - | + (发送RTSP的PLAY消息以指示媒体数据送出开始) - D3公开客户端发送RTSP PLAY消息,指示开始通过确立的资源发送媒体数据。出处:段落 [0014]、图4。 |
| 技术特征D:启动(36)会话控制过程以将所述媒体流与用于控制所述媒体流的传输的会话相关联,其中,能够在完成所述会话控制过程之前启动媒体流传递 | 说明书[0007]、[0046]、[0048] | - (D1不涉及用于将媒体流与网络策略(QoS等)相关联的SIP会话控制过程) - 虽然D1有速率自适应(段落 [0054]),但这是客户端基于下载速度的测量进行的本地决定,并不涉及为了QoS预留、计费等目的在网络侧启动并完全或部分独立于媒体数据请求本身的“会话控制过程”。D1不具备“并行启动传递”的特征。 | +/- (视频視聴アプリから通信管理部にフロー情報を通知し、割当帯域を決定) - D2提及视频客户端通过呼叫控制协议(SIP/RTSP)向服务器发送コンテンツ(呼叫控制信令,包含会话描述信息,步骤0011-0012)。同时,D2还强调了将流动(flow)信息从应用程序通知给通信管理部以在多个NIC间进行路由或带宽分配(图1,段落 [0010]、[0011]、[0017]、[0018])。D2提出了会话关联和带宽管理。但是,D2并未明确描述“在完成会话过程前提前启动媒体数据传递”的并行机制以解决缩短启动延迟的技术问题。 | + (SETUP和PLAY的常规RTSP序列) - D3公开了常规的RTSP会话过程。首先,通过SETUP(步骤402)确立资源和セッション(会话)开始。在收到SETUP响应(步骤404)后,客户端发送PLAY消息(步骤406)启动媒体传递。因此,D3虽然公开了会话启动过程(特征D的前部),但媒体传递是在接收到会话过程(SETUP)结束响应后由PLAY启动的,这属于“先会话完成,后传递媒体”的常规序列。并未公开并行处理或提前启动。出处:段落 [0014]-[0016]、图4。 |
---
### 第三部分:最接近对比文件的确定及最薄弱特征分析
#### 1. 最接近对比文件的确定 (Creativity Analysis - Closest Prior Art)
在从整体解决的技术问题以及技术效果角度进行创造性分析时,确定“最接近的对比文件(Closest Prior Art, CPA)”是至关重要的一步。
* **目标专利的核心:** 目标专利(CN108270799B)针对的核心技术问题是解决将复杂的会话控制(例如IMS控制,用于QoS、计费等)引入到自适应流(AHS,如HTTP AHS)中时,由于会话建立信令的延迟而导致的“流启动时间延迟”[0106]。其技术效果是即便在IMS会话控制过程(如SIP INVITE过程)完成之前,也能并行启动尽力而为(best-effort)的初始流传递,从而实现快速流启动时间[0106, 0090, 0108]。
* **对比文件的分析:**
* **D1 (US 2004/0064573 A1)**解决的问题是利用普通的HTTP Web服务器在不同带宽条件下进行流传递(通过客户端本地测量和文件名切换),避免复杂的流服务器和协议(段落 **[0001]**、**[0023]**、**[0025]**)。虽然其具备获得描述文件(索引文件)、指示和请求初始段(特征A、B、C)的特征,但其**完全不涉及**通过额外的网络会话信令过程将网络策略(如QoS承载、网络计费)应用到流的技术,也没有解决如何缩短这类复杂信令带来的启动延迟。
* **D2 (JP 2007-194680 A)**主要涉及多宿主(multi-homing)或Mobile IP环境下的带宽分配和NIC选择(段落 **[0001]**、**[0010]**)。它确实涉及将流动信息与应用程序相关的控制规则相关联。但其核心关注点在于路由和带宽选择(段落 **[0018]**、**[0023]**),并不关注由复杂呼叫控制信令(如SIP)本身引起的初始启动延迟问题,更没有提出在此之前并行传递媒体的技术方案。
* **D3 (JP 2009-182417 A)**基于バッテリ残量和視聴予定时间通过RTSP进行流发送速率控制(段落 **[0001]**、**[0010]**、**[0022]**)。它在步骤上是常规的RTSP SETUP(特征D的过程启动)、SETUP 响应(完成)、然后 PLAY(特征C)。并未提出并行或提前传递的方案。它解决的是电池效率问题。
* **CPA的选择结论:**
* **D3 适合做CPA。** 虽然所有对比文件都公开了特征A、C,但 D3 不仅具备与目标专利相似的自适应流技术背景(自适应速率控制),而且公开了常规的“呼叫/会话控制过程”(RTSP SETUP),并使用了会话标识和参数(段落 **[0013]**、图4)。它在技术领域、所涉及的呼叫控制协议架构(虽然不完全是IMS,但同属于需要SETUP信令的协议簇)上最接近目标专利。虽然 D1 和 D2 在某些具体特征(如D1的“指示起始元素文件名”)上有更详细的描述,但其与目标专利在整体解决“复杂信令延迟导致的启动慢”这一技术问题上的相关性不及 D3。
* **D2 也是可选的CPA。** D2 提及了呼叫控制协议(SIP/RTSP),并具有将会话(由流动信息描述)与控制实体(通信管理部)相关联并适用控制规则(带宽、路由选择)的步骤,具有特征D的前序部分实质性内容。
* **代理师建议:** 如果提出无效请求,通常首选 **D3** 或 **D2** 作为 CPA,因为它们都触及了网络侧呼叫/会话控制信令。可以主要以 **D3** 为 CPA 进行独立或组合无效分析。
#### 2. 最薄弱技术特征分析 (请求方最薄弱环节)
如果作为无效请求方,针对权利要求1进行无效宣告请求,那么哪个特征是最薄弱的技术特征(即,是最难找到完全公开或实质公开证据的特征)?
**结论:技术特征D的后半部分**。
具体地:**“(启动会话控制过程,以便……),其中,能够在完成所述会话控制过程之前启动媒体流传递”**。
**分析理由:**
1. **现有技术常识:** 如我们在对 D3 的分析中所述,常规的呼叫控制和媒体控制协议序列(例如基于RTSP或早期的 IMS 控制流,参见目标专利背景 **[0008]**-**[0018]** 中的描述)通常严格执行“先信令,后媒体”或“信令确立,再发送媒体”的逻辑链条(例如 D3 中的先步骤 402/404 确立资源,然后步骤 406 启动传递)。现有技术中的“关联”和“启动过程”是已公开的。
2. **目标专利的独特技术效果:** 目标专利明确提出了这种并行操作的可行性(“能够”)作为其关键创新点,旨在利用尽力而为传输在复杂网络会话控制确立(如QoS、认证、计费预留)结束之前就开始媒体数据的提前传递,从而优化用户启动体验。
3. **对比文件公开情况:**
* **D1-D3 均未实质性公开此特征。**
* D1 不存在网络侧策略(策略执行点、QoS)控制的“会话过程”,更谈不上在其结束前启动媒体。
* D2 关联了流动信息,但并未提出在呼叫控制过程完成前并行传递的技术方案。
* D3 采用的是严格的先后顺序序列。
4. **代理师总结:** 此特征引入了一个明确的并行或提前操作的时间窗口或操作策略,打破了常规信令协议中严格按照步骤完成的逻辑。要在现有技术中找到一个公开了使用网络侧呼叫控制信令(特征D前半部分),同时又允许或描述客户端在其未完成(例如未收到响应消息)时就提前发送媒体请求(特征C和D后半部分),并明确解决由复杂信令引起延迟这一技术问题的对比文件,是非常困难的。
因此,**特征D关于并行启动传递的技术特征(“能够在完成所述会话控制过程之前启动媒体流传递”)是对于无效请求方来说最薄弱的技术特征,是权利要求1区别于所有现有技术并具有创造性的主要技术支点。** 如果现有对比文件没有公开此特征,请求方则需要寻求通过其他方式证明该区别特征相对于现有技术是显而易见的,这通常需要更复杂的逻辑论证和更强的技术显而易见性依据。
作为一名经验丰富的专利代理师,我将紧密结合目标专利说明书和对比文件的原文,对权利要求1进行深入的解释和比对分析。
### 第一部分:权利要求1的技术特征拆解与解释
目标专利为 CN108270799B(以下简称“目标专利”),其旨在解决现有自适应 HTTP 流传递(AHS)中,媒体描述和下载机制缺乏与资源或 QoS(服务质量)预留机制结合的问题,导致在受管理系统中也只能尽力而为(best-effort)地工作(参见说明书【0019】)。
目标专利的核心发明构思在于:在媒体客户端开始请求媒体流的初始元素的同时或之后,启动会话控制过程,以便在媒体流传递的早期阶段(甚至在会话控制完成之前)就能够开始播放,同时后续能通过会话控制实现 QoS 预留、计费等受管理网络的功能。
基于此,权利要求1的方法被拆解为以下四个技术特征:
* **技术特征A:获得媒体流的媒体描述**
* **解释:** 客户端通过例如下载文件的方式获得描述媒体流的信息。结合说明书【0044】,这对应于“从由客户端下载的文件获得媒体流的媒体描述”。
* **技术特征B:所述媒体描述指示所述流元素的初始元素**
* **解释:** 媒体描述中包含了如何获取媒体流中第一个元素(初始元素)的信息,通常是初始元素的URI(统一资源标识符)。结合说明书【0044】,这对应于“媒体描述指示流元素的初始元素,例如作为从其可获得初始元素的媒体源,像 URI”。
* **技术特征C:发送对所述初始元素的请求**
* **解释:** 客户端根据媒体描述中的指示,向服务器(平台)发送获取该初始元素的请求(例如 HTTP GET)。结合说明书【0045】,这对应于“例如由客户端将对初始流元素的请求发送到平台以获得来自媒体源的初始元素”。
* **技术特征D:启动会话控制过程以将所述媒体流与用于控制所述媒体流的传输的会话相关联,其中,能够在完成所述会话控制过程之前启动媒体流传递**
* **解释:** 这是目标专利的核心创新点。客户端不仅请求媒体元素,还启动一个会话控制过程(例如 SIP 信令过程)。这个过程的目的是建立或修改一个具有特定传输特性(如 QoS)传输上下文(即会话),并将该会话与当前的媒体流关联起来。关键在于,媒体流元素的传递(即步骤C对初始元素的请求和接收)可以在会话控制过程完全结束(例如收到 SIP 200 OK 最终响应)之前就开始。这允许媒体流在尽力而为的承载上快速启动,增强用户体验,同时后续能切换到 QoS 承载(参见说明书【0047】-【0048】、【0059】)。
---
### 第二部分:对比文件特征比对与分析
我们将分析以下三份对比文件:
1. **D1: JP2009225217A**
2. **D2: JP2009225339A**
3. **D3: US7653685B2**
#### 1. 对比文件特征比对表格
| 权利要求1的技术特征 | 目标专利说明书出处 | D1 (JP2009225217A) 特征比对及出处 | D2 (JP2009225339A) 特征比对及出处 | D3 (US7653685B2) 特征比对及出处 |
| 技术特征A: 获得媒体流的媒体描述 | 【0044】 | 毫无异议公开。<br>D1公开了通信装置(客户端)通过网络获取用户所希望的コンテンツ情報(PLAYLIST)。PLAYLIST即是一种媒体描述。<br>【原文出处】:【0042】「通信装置10に対してコンテンツ情報を配信する。…プレイリスト、及びコンテンツに関するメタ情報などのことを指す。」,【0043】「 WWWサーバである第二通信サーバ80にアクセスし、ユーザが所望するコンテンツのセッション情報、プレイリスト及びコンテンツに関するメタ情報などを取得する」 | 毫无线议公开。<br>D2公开了客户端发送 SETUP 方法,从内容服务器获取关于传输方法的トランスポートパラメータ。这是一种关于媒体传输方式的媒体描述。<br>【原文出处】:【0003】「クライアントからSETUPメソッドを送信し、伝送方法に関するトランスポートパラメータをコンテンツサーバから取得する。」 | 毫无线议公开。<br>D3公开了缓存代理服务器(一种客户端)向源服务器发送对 RTP 数据(媒体流)的 SETUP 请求,并接收响应(包括会话描述 SDP 文件)。<br>【原文出处】:【0047】「“setup” in RTSP for audio or video streaming media data.」,【0066】「a session description protocol document for a uniform resource locator (URL) may include a range」,图5。 |
| 技术特征B: 所述媒体描述指示所述流元素的初始元素 | 【0044】 | 毫无线议公开。<br>D1公开了 PLAYLIST 具有本编映像或广告的ファイル名,按照播放顺序描述。PLAYLIST 中的第一个文件名即指示了初始元素。<br>【原文出处】:【0042】「部分コンテンツが本編か広告かを示す識別子又はコンテンツあるいは部分コンテンツの帯域情報等を有するプレイリスト」,【0046】「プレイリストの順で第一通信サーバ40に対して、映像の配信を要求する。…プレイリストとは、例えば、図17に示されるような映像の配信順序を記述したものである。」 | 毫无线议公开。<br>D2公开了客户端在 SETUP 之后发送 PLAY 方法,请求内容服务器开始流式传输内容。PLAY 方法隐含了请求特定流元素的意图。<br>【原文出处】:【0004】「クライアントからPLAYメソッドを送信して、コンテンツサーバからコンテンツのストリーミング配信を要求する」。 | 毫无线议公开。<br>D3公開了CP服务器发送 PLAY 命令来请求特定的视频和音频轨道,其中媒体描述(SDP 文件)包括 URL 范围。<br>【原文出处】:【0052】「caching proxy server 401 sends a “PLAY” command in the RTSP protocol.」,【0066】。 |
| 技术特征C: 发送对所述初始元素的请求 | 【0045】 | 毫无线议公开。<br>D1公开了通信装置向第一通信服务器(媒体服务器)发送コンテンツ配信の開始要求,并且按照 PLAYLIST 的顺序进行要求。<br>【原文出处】:【0046】「第一通信サーバ40に対して映像配信制御プロトコルを用いてコンテンツ配信の開始を要求し、第一通信サーバ40はコンテンツ配信を開始する(S405)。この際、通信装置90は図17に示されるようなプレイリストの順で第一通信サーバ40に対して、映像の配信を要求する。」 | 毫无线议公开。<br>D2公开了客户端发送 PLAY メソッド,请求开始流式传输。<br>【原文出处】:【0004】「クライアントからPLAYメソッドを送信して、コンテンツサーバからコンテンツのストリーミング配信を要求すると…」。 | 毫无线议公开。<br>D3公开了CP服务器向源服务器发送 PLAY 命令。<br>【原文出处】:【0052】「caching proxy server 401 sends a “PLAY” command in the RTSP protocol.」。 |
| 技术特征D: 启动会话控制过程以将所述媒体流与用于控制所述媒体流的传输的会话相关联,其中,能够在完成所述会话控制过程之前启动媒体流传递 | 【0047】-【0048】、<br>【0059】 | 实质公开了会话控制的启动和关联,但公开了在会话完成之前启动传递的技术特征。<br>D1中,通信装置先通过 SIP 请求建立会话(S401-S402),并由会话控制装置在会话中确保带宽(S403)。只有在会话建立成功后,通信装置才发送媒体流传输请求(S405)。<br>【原文出处】:【0044】-【0046】「SIPを介してセッション制御装置70に第一通信サーバ40とのセッションの確立を要求する(S401)。…SIPを介したセッションの確立を行う(S402)。また、…帯域制御装置20に対して、…帯域の確保を要求する(S403)。…帯域を確保し(S404)、確保できたらその旨を第一通信サーバ40に伝える。…通信装置90は第一通信サーバ40との間のセッションの確立に成功すると、第一通信サーバ40に対して映像配信制御プロトコルを用いてコンテンツ配信の開始を要求し、…」 | 毫无异议公开了会话控制的启动和关联,但未实质公开能够在完成前启动传递。<br>D2使用的是标准的 RTSP 协议。它先建立 RTSP 会话(S11-S12),获得トランスポートパラメータ。只有在会话建立和参数确定之后,才发送 PLAY 方法请求媒体流传输(S13-S15)。整个 RTSP SETUP/PLAY 过程在技术上通常被视为完整的会话建立和控制过程。<br>【原文出处】:【0003】-【0004】以及【0038】-【0040】(图3流程)。 | 毫无异议公开了会话控制的启动和关联,但公开了能够在完成前启动传递。<br>D3中CP服务器首先通过 SETUP 建立会话,然后发送 PLAY 命令请求媒体流。源服务器响应 PLAY 命令并开始流传输。类似于 D2,这是标准的 RTSP 会话建立和控制过程。<br>【原文出处】:【0047】、「505」以及【0066】-【0067】。 |
#### 2. 对比文件详细分析与创造性最接近文件选择
通过上述特征比对,我们可以得出以下分析结论:
**(1)关于各对比文件对技术特征的公开情况:**
* **D1 (JP2009225217A):**
* 毫无异议公开了特征 A、B、C。
* **关于特征D:** D1 公开了启动一个会话控制过程(SIP 信令,通过会话控制装置确保带宽,S401-S403),旨在控制媒体流的带宽。然而,D1 明确指出了先后顺序:通信装置在会话建立**成功后**(「成功すると」,【0046】)才启动媒体流传递(S405)。这与特征 D 的核心教导“**能够在完成所述会话控制过程之前启动媒体流传递**”相悖。因此,D1 未公开这一核心技术特征。
* **D2 (JP2009225339A):**
* 毫无异议公开了特征 A、B、C。
* **关于特征D:** D2 使用标准的 RTSP 协议。SETUP メソッド(S11)建立会话并确定参数(トランスポートパラメータ),之后的 PLAY メソッド(S13)启动媒体传输。虽然トランスポートパラメータ决定了传输方式(这是一种控制传输的规则),但在 SETUP 和获得响应(S12)完成之前,媒体传输(PLAY 命令发送)不会启动。D2 的重点在于内容播放**结束后**维持会话以供再收听,而不在于会话建立过程中媒体流的尽早启动。因此,D2 也未实质公开这一核心技术特征。
* **D3 (US7653685B2):**
* 毫无线议公开了特征 A、B、C。
* **关于特征D:** D3 的过程与 D2 类似,也是标准的 RTSP SETUP 和 PLAY 过程。SETUP 过程建立会话(【0047】),源服务器在 PLAY 命令后启动流式传输(【0052】)。这同样是一个会话先建立/修改,媒体流传输后启动的过程,没有公开在会话完成前启动传递。D3 关注的是在缓存代理和源服务器之间协商 RTP 扩展特征(如 TT),而不是媒体流在会话建立时的快速启动。
**(2)关于最接近对比文件的分析与选择:**
要确定哪一个对比文件最适合作为最接近的对比文件,我们需要考虑它们所解决的技术问题、技术效果以及公开的技术特征数量。
* **技术特征公开数量:** 所有三份对比文件 D1、D2、D3 都公开了特征 A、B、C,即媒体描述的获得、指示以及初始元素的请求。
* **核心技术问题与效果:** 目标专利要解决的核心问题是自适应流传递缺乏与 QoS 等会话控制的结合,导致流传递只能是尽力而为。其技术效果是通过将会话控制启动与媒体流传递并行或几乎并行地启动(尤其是能够在会话控制完成之前启动传递),从而在保证媒体流能快速启动(尽力而为)的同时,后续能够通过会话控制获得 QoS 和计费等增强服务(参见【0019】、【0047】)。
* **对比文件的分析:**
* **D1:** 致力于解决在发送高画质、特定部分内容时(参见【0008】),如何能够自动变动带宽的问题。其技术效果是防止网络拥塞导致重要信息画质劣化(参见【0012】)。D1 虽然未公开并行处理,但它公开了通过**IMS(IP多媒体子系统)**这一具体的会话控制装置来进行带宽确保(参见【0023】),这与目标专利说明书所讨论的基于 IMS 控制的概念是非常接近的(参见目标专利背景技术【0007】)。
* **D2:** 致力于解决 RTSP 会话结束后需要重新建立才能再次播放或早退早进的问题(参见【0007】)。其技术效果是通过在播放结束后维持会话,允许用户立即再次或从任意位置收听内容,无需再次建立会话。它完全不关注会话启动时的效率问题。
* **D3:** 致力于解决缓存代理服务器需要源服务器提供 TT 等信息,以便向客户端平滑交付 RTP 包,并能够检索丢失包的问题(参见【0006】-【0007】)。其技术效果是提高缓存代理服务器的缓存和传输效率。它关注的是缓存代理与源服务器之间的扩展特征协商,而不是媒体流在客户端的快速启动。
**结论:**
从整体解决的技术问题和技术效果来看,**D1 (JP2009225217A)** 公开了最接近的技术概念和结构。虽然 D1 仍然是“先会话建立完成,后媒体传输”的传统模式,但它明确涉及了将会话控制(通过 IMS 装置确保带宽)与媒体流元素传输进行结合这一总体概念。D2 和 D3 关注的场景(播放结束后的会话维持、缓存代理扩展特征协商)与目标专利在媒体传输启动阶段所关注的“并行”或“加速启动”场景距离较远。
因此,在创造性分析过程中,**D1 适合做最接近的对比文件**。
**(3) 創造性分析中的最薄弱技术特征 Point out:**
基于上面的分析,如果我是无效请求方(或者专利代理师在撰写阶段进行防范),我认为目标专利权利要求1最薄弱的技术特征是:
**技术特征D中的下半部分:“……其中,能够在完成所述会话控制过程之前启动媒体流传递”。**
理由如下:
1. **现有技术已公开上半部分:** 对比文件 D1-D3 以及普遍的流媒体技术(如 RTSP)都已经公开了启动会话控制过程以将媒体流与用于控制传输的会话关联的概念。D1 更是公开了将这一会话控制过程用于 QoS 控制(带宽确保)。
2. **核心创新在于并行处理的时序:** 目标专利的核心教导在于打乱传统的时序:不再等待会话控制完全完成(即确定所有 QoS 参数和计费授权),而是允许媒体传递(尽力而为模式)与会话控制过程启动阶段并行产生,以获得快速启动的效果。
3. **创造性分析要点:** 因此,目标专利具备创造性的核心支点在于,本领域技术人员在面对“如何提高流媒体服务启动速度”这一常见技术问题时,是否存在技术教导或动机从 D1 这种“先建立会话,确认所有资源,后传输内容”的严格传统模式,改变为目标专利这种“先启动内容传输(尽力而为),同时启动会话控制(确保后续 QoS),允许传递在控制完成前发生”的新模式。这一改动涉及到协议流程和策略控制逻辑的变化,并非显而易见地通过简单增加部件或改变参数来实现。
对于请求方来说,要无效权利要求1,必须找到现有技术教导了将会话建立过程(特别是涉及 QoS 控制的过程)与媒体流初始阶段(例如尽力而为承载)并行处理,且明确教导可以在会话建立完成之前就启动媒体内容传递的技术教导。这一步往往是无效过程中的难点,也是最薄弱的环节。相反,如果专利局能够证明这种打乱时序、并行处理在当时(目标专利申请日之前)已经是通用的优化策略,那么权利要求1的创造性将面临很大挑战。
作为一名经验丰富的专利代理师,我将为您深度解析目标专利的权利要求1,并与您提供的三份对比文件(以下使用其公开号和简称指代:**D1 (WO2010088030A2)**、**D2 (WO2010078281A2)**、**D3 (JP2005012655A)**)进行紧密结合原文的特征比对与创造性分析。
---
## 一、 目标专利权利要求1的合理解释
目标专利的权利要求1请求保护一种**“在媒体客户端中用于控制媒体流传输的方法”**。其核心发明点在于解决自适应媒体流(如自适应HTTP流AHS)缺乏与网络侧会话控制/QoS预留机制有效结合的问题。
为了避免播放延迟,本发明提出在**会话控制过程(如SIP会话建立/修改)完成之前,允许先启动媒体流的传递(如使用尽力而为的承载进行初始元素的请求和传输)**。当后续会话控制过程完成(如收到SIP 200 OK)后,再根据确立的会话控制规则(如QoS、计费等)来控制后续流元素的传输。这使得客户端能够快速启动流媒体播放,随后平滑升级到具有QoS保证的高质量流。
---
## 二、 目标专利与对比文件的技术特征比对
为了清晰展现各对比文件是否公开了权利要求1的技术特征,以下将权利要求1分解为4个技术特征(A、B、C、D),并与对比文件的原文出处进行逐一比对。
### 1. 技术特征特征比对表
| 权利要求1的技术特征 | 对比文件1 (D1: WO2010088030A2) | 对比文件2 (D2: WO2010078281A2) | 对比文件3 (D3: JP2005012655A) |
| 特征A:获得媒体流的媒体描述 | 实质公开<br>出处:\[p0017] [021]<br>原文:“Clients can perform rate control by first obtaining index information from the server describing the various bit rates available...” | 毫无异议公开<br>出处:\[p0037] [0034], [0047]<br>原文:“In order to play the stream of media data, the client device obtains the playlist file from the server...” | 毫无异议公开<br>出处:\[0007], \[0013]<br>原文:“コンテンツの視聴者の端末装置が、コンテンツアドレス管理サーバサブシステムから該コンテンツのアドレスを取得する手順”(获取包含内容的第1地址形式/电子节目表) |
| 特征B:所述媒体描述指示所述流元素的初始元素 | 实质公开<br>出处:\[p0017] [021], [023]<br>原文:“Based on the index information... the client can decide which bit rate streaming segments to download...” | 毫无异议公开<br>出处:\[p0037] [0034], [0047]<br>原文:“Each URI in the playlist file refers to a media file that is a segment of a stream...” | 实质公开<br>出处:\[0007], \[0013]<br>原文:“希望するコンテンツに対しコンテンツアドレス管理サーバサブシステム61で関連づけられている該コンテンツを指定する第1のアドレス形式によるアドレス等の情報を取得し” |
| 特征C:发送对所述初始元素的请求 | 实质公开<br>出处:\[p0017] [021], [023]<br>原文:“the client can decide which bit rate streaming segments to download from the server...” | 毫无异议公开<br>出处:\[p0020] [0008], \[p0037] [0034]<br>原文:“The client then can request the segmented media files identified in the playlist file(s) and download the linked media files.” | 毫无异议公开<br>出处:\[0013], \[0031]<br>原文:“第一のアドレス形式のアドレスが指定するところのコンテンツを保持しているコンテンツ配信サブシステムに対して、...リアルタイムデータ配信の制御ができるようにし” |
| 特征D:启动会话控制过程以将所述媒体流与用于控制所述媒体流的传输的会话相关联,其中,能够在完成所述会话控制过程之前启动媒体流传递 | 未公开<br>D1属于传统客户端自适应流,由客户端根据网络带宽自发选择下载分段,不涉及网络侧的“会话控制过程”(如SIP/IMS信令及QoS预留),更未提及在会话完成前传递流。 | 未公开<br>D2公开了根据网络带宽切换分段和Variant Playlist,以及failover机制,但未涉及与网络侧QoS/策略控制相关的“会话控制过程”(D2完全基于标准的非会话HTTP协议)。 | 实质公开(前半部分)/ 未公开(核心限定)<br>出处:\[0007], \[0012], \[0024]-[0028]<br>原文:“SIPセッション制御サブシステムを経由してコンテンツ配信サブシステムに該コンテンツの視聴に先立ちセッションの確立を要求する手順...帯域予約の要求を行う”<br>【未公开核心限定】:D3明确要求在“コンテンツの視聴に先立ち”(在观看内容之前)先通过SIP确立セッション(会话)并确保(予約)带域,未能公开“能够在完成会话控制过程之前启动媒体流传递”这一特征。 |
---
## 三、 最接近的对比文件(最接近现有技术)分析
在创造性分析中,确定“最接近的对比文件”通常应优先选择与发明**技术领域相同、解决的技术问题最相似、且公开技术特征最多**的文件。
基于上述原则,本案中**适合作为最接近对比文件的是:D3 (JP2005012655A)**。
### 1. 为什么D3最适合作为最接近的对比文件?
* **技术领域与架构高度重合**:目标专利解决的是“如何将自适应流传递(如HTTP流)与网络侧的会话控制(如IMS/SIP、QoS策略预留)相结合”的问题。D3正是公开了一种“利用SIP会话控制在CDN中保证QoS”的方法和系统,同样引入了SIPセッション制御サブシステム(SIP会话控制子系统)和帯域制御サブシステム(带宽控制子系统)。这与目标专利在网络架构、会话控制手段上完全相同。
* **技术特征公开最多**:D3完全公开了特征A、C,并实质公开了特征B和特征D的前半部分(启动会话控制以将媒体流与会话相关联并进行带宽预约)。
### 2. 为什么D1和D2不适合作为最接近的对比文件?
* D1和D2属于**尽力而为(Best-Effort)的网络传输技术**。D1侧重于多比特率编码(动态分辨率和VBR),D2侧重于HTTP自适应流传递(M3U8切片和变体播放列表切换)。
* D1和D2**完全不涉及网络侧的“会话控制过程”或“QoS带宽预约/策略控制”**。如果以D1或D2为起点,审查员需要证明技术人员有动机引入复杂的网络侧SIP会话控制机制,这存在明显的“事后诸葛亮”偏见。
---
## 四、 区别技术特征及其他对比文件是否公开
### 1. 目标专利权利要求1与最接近对比文件(D3)的区别技术特征
经过特征比对,权利要求1与D3的区别特征在于特征D的后半部分限定:
> **“其中,能够在完成所述会话控制过程之前启动媒体流传递”**
### 2. 其他对比文件(D1、D2)是否公开了该区别特征?
* **D1 (WO2010088030A2)**:**未公开**。D1根本没有会话控制过程的概念,因此谈不上“在完成会话控制过程前启动媒体流传递”。
* **D2 (WO2010078281A2)**:**未公开**。D2虽然提到了“快速启动”(\[p0003] [003] start-up latency),但其是通过客户端首选低码率分段或通过缓存重叠来实现的,并不是在“会话控制过程完成前”并行启动流传递。
### 结论
**该区别技术特征在所有引证的对比文件(D1、D2、D3)中均未被公开。**
---
## 五、 无效宣告请求方最薄弱的技术特征(即目标专利的最强防线)
如果请求方试图针对目标专利权利要求1提出无效宣告请求,其**最薄弱的技术特征(即最难攻克的防线)**显然是:
> **“能够在完成所述会话控制过程之前启动媒体流传递”**
### 为什么该特征是请求方的致命软肋?
1. **现有技术存在相反的技术启示(反向教导)**:
在最接近的现有技术D3中,其核心逻辑是**串行**的。D3明确规定:客户端在“**視聴に先立ち**”(观看内容之前)必须先向SIP系统发起会话确立(序列S13-S14),由网络侧先向带宽控制系统成功预约带宽(序列S18-S19),在完成带宽确保并向终端返回200 OK(序列S20)之后,终端才被允许通过RTSP启动媒体流的下载和視聴(序列S23-S25)。
D3的整个设计初衷是“无QoS保障就不提供流服务”(以避免播放中途卡顿或用于鉴权控制),这给技术人员带来了**反向教导**——技术人员在面对D3时,不会想到在会话控制和带宽预约完成之前就“偷跑”媒体流。
2. **该特征带来了显著的技术效果(解决突出的技术问题)**:
目标专利敏锐地发现了D3这类IMS/SIP控制流技术的致命缺陷:**会话确立和QoS预留存在明显的信令延迟**(IMS信令层层转发需要时间),如果必须等会话完成才放行媒体流,会导致用户遭遇严重的“首帧播放延迟(Start-up latency)”,极大地损害用户体验。
目标专利通过“在完成会话控制过程之前允许启动媒体流传递”,使客户端可以先用默认承载/尽力而为承载瞬间拉取初始切片播放,在播放的同时异步完成网络侧的SIP会话控制和QoS升级。这种**并行双轨**机制既实现了快速开播,又兼顾了后续的QoS管理,取得了意料不到的技术效果。
### 给请求方的无效策略建议:
由于D1、D2、D3均未公开也未启示该“并行/偷跑”机制,请求方若仅依赖本案的D1-D3,在创造性(具体为“显而易见性”)的论证上会极其被动。请求方必须去寻找**另外的D4或篇章级公知常识**(例如证明在通信领域中,“异步信令处理”或“在安全通道确立前允许受限预览数据”属于本领域的通用公知常识),否则直接宣告权利要求1无效的成功概率极低。
根据权利要求1所述的方法,其中,启动会话控制过程的步骤包括;获得指示与所述媒体流相关联的会话控制的源的资源定位符;以及发送请求以便启动与会话控制的所述源的所述会话控制过程
根据权利要求2所述的方法,其中,所述资源定位符被包括在所述媒体描述(100)中或者与所述媒体描述(100)相关联
根据权利要求1至3中任一项所述的方法,其中,所述媒体描述(100)包括或者关联到用于指定所述会话控制过程中的会话参数的至少一个信息元素
根据权利要求1至3中任一项所述的方法,还包括以下步骤;接收对所述会话控制过程的会话控制响应;以及在接收到所述会话控制响应时,发送对于所述流元素的初始元素或后继元素(94)的请求
根据权利要求5所述的方法,其中,所述会话控制响应指示媒体描述、媒体源的指示和指定所述会话的参数中的至少一个
根据权利要求6所述的方法,其中,所述会话控制过程包括资源预留;并且指定所述会话的参数指示准许的服务质量
根据权利要求6所述的方法,其中,从多个媒体源选择所述后继元素的媒体源;并且来自所述多个媒体源的每个媒体源与指定所述会话的不同参数相关联
根据权利要求6所述的方法,其中,指定所述会话的参数被包括在对所述后继元素(94)的请求之中
根据权利要求6所述的方法,其中,所述媒体描述包括多个表示描述,每个表示描述指示所述媒体流的不同表示和所关联的媒体源;并且其中,基于所述媒体描述选择所述相关联的媒体源中的至少一个媒体源;并且将选择的媒体源包括在对所述初始元素(92)的请求中或对所述后继元素(94)的请求中
根据权利要求6所述的方法,其中,用于会话控制的所述源和媒体源中的至少一个特定于所述会话
根据权利要求1至3中任一项所述的方法,其中,在启动所述会话控制过程之前或同时,发送对所述初始元素(92)的请求