• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04N
管理番号 1325670
審判番号 不服2015-12485  
総通号数 208 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-04-28 
種別 拒絶査定不服の審決 
審判請求日 2015-07-01 
確定日 2017-03-07 
事件の表示 特願2013-523493「メディアストリーム伝送のためのセッション制御」拒絶査定不服審判事件〔平成24年 2月16日国際公開、WO2012/019621、平成25年11月 7日国内公表、特表2013-541245〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、2010年(平成22年)8月10日を国際出願日とする国際特許出願であって、手続の概要は以下のとおりである。

手続補正 :平成25年 7月10日
拒絶理由通知 :平成26年 5月15日(起案日)
手続補正 :平成26年 8月20日
拒絶査定 :平成27年 2月26日(起案日)
拒絶査定不服審判請求 :平成27年 7月 1日
手続補正 :平成27年 7月 1日
拒絶理由(当審) :平成28年 6月 2日(起案日)
手続補正 :平成28年 9月 6日

第2 本願発明
本願の請求項13に係る発明(以下、「本願発明」という。)は、平成28年9月6日付けの手続補正書により補正された特許請求の範囲の請求項13に記載された事項により特定される、以下のとおりのものである。
((A)ないし(E)は当審において付与した。以下「構成要件(A)」等として引用する。)

【請求項13】
(A)連続した複数のストリーム要素(84)に時間において分割されたメディアストリームの伝送を制御するためのメディアクライアントにおける方法であって、
(B)前記複数のストリーム要素のうちの最初の要素(92)のメディアソースを示す、前記メディアストリームのメディア記述(100)を取得するステップ(32)と、
(C)前記最初の要素(92)を求めるリクエストを送信するステップ(34)と、
(D)前記メディアストリームの伝送のためのセッション制御手続きを開始するステップ(36)とを有し、
(E)前記最初の要素(92)を求めるリクエストを送信するステップ(34)は、前記セッション制御手続きの結果を受信する前に実行されることを特徴とする方法。

第3 引用例の記載事項
(3-1)当審における拒絶の理由の通知において引用された引用例である国際公開第2010/088030号(以下「引用例1」という。)には、図面と共に次に掲げる事項が記載されている。(翻訳は、引用例1のパテントファミリーである特表2012-516644号公報の記載に基づいて合議体が作成した。)

[018] The various techniques and tools described herein may be used independently. Some of the techniques and tools may be used in combination. Various techniques are described below with reference to flowcharts of processing acts. The various processing acts shown in the flowcharts may be consolidated into fewer acts or separated into more acts. For the sake of simplicity, the relation of acts shown in a particular flowchart to acts described elsewhere is often not shown. In many cases, the acts in a flowchart can be reordered.
I. Multi Bit Rate Video Streaming
[019] Figure 1 depicts a generalized block diagram of a system 100 for segmented streaming of multimedia content contained in an indexed video stream file. The indexed file generally divides video of a multimedia program into multiple streaming segments, and contains a number of compressed bit streams representing the video segments at various bit rates. Although the MBR video streams are described as separate coded streams, alternative implementations can have some or all of the MBR video streams encoded as one coded compressed video stream with multiple coding layers. In the system 100, a server 110 (e.g., a server computer system such as a standard HTTP server) provides multimedia content to a client 120 (e.g., a client computer system, such as a laptop or desktop computer, or another type of computing device, such as a PDA or mobile phone) via a network 130 (e.g., the Internet). In the system 100, the server 110 stores programs in an indexed file. The client 120 comprises client-side rate control software and/or hardware.
[020] In one specific example implementation, the server 110 is a standard HTTP server without any specialized streaming capability other than the ability to serve files. Because the server 110 does not support any specialized bit rate selection capability, the client 120 must perform all bit rate selection activities. In this implementation, the client 120 performs all bit rate selection activities. For example, the client 120 can perform rate control using the index information obtained from the server 110 (e.g., alone or in combination with other information, such as client buffer information, network bandwidth, etc.). However, in other implementations, some or all of the rate-control functions can occur at the server.
[021] In general, the indexed file for multi bit rate streaming can be used by standard HTTP servers to serve multimedia content at multiple bit rates with bit rate selection (rate control) being performed client-side (e.g., exclusively client-side). Clients can perform rate control by first obtaining index information from the server describing the various bit rates available for streaming segments of a program. Based on the index information, and possibly other information (e.g., network bandwidth, buffer information, etc.), the client can decide which bit rate streaming segments to download from the server to provide a desired user experience (e.g., the best user experience possible based on the available bit rates and current network conditions).
[022] Other types of computing devices (e.g., other than traditional HTTP servers) can provide files using the indexed file. For example, a computing device (e.g., a personal computer, server computer, or special-purpose streaming media server) can use the indexed file layout to serve multimedia content using various file serving protocols (e.g., File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Real Time Streaming Protocol (RTSP), MMS (Microsoft Media Services), etc.).
[023] In order to support bit rate switching, programs are divided into temporal chunks called streaming segments (self-contained units). The server stores each streaming segment at one or more bit rates (e.g., each streaming segment - bit rate combination is a separate streaming segment encoding). Each streaming segment includes one or more available bit rate encodings for a specific track (e.g., a specific audio track, such as an English audio track, or a specific video track) of a program. Clients then determine which bit rate, from the available bit rates (e.g., from the available streaming segment encodings), to download for each streaming segment. For example, a client may obtain a first streaming segment, for a video track, encoded at 250Kb/sec (kilo-bits per second) (from one or more available streaming segment encodings for the first streaming segment), a second streaming segment, for the video track, encoded at 500Kb/sec (from one or more available streaming segment encodings for the second streaming segment), and a third streaming segment, for the video track, encoded at 1 Mb/sec (mega-bit per second) (from one or more available streaming segment encodings for the third streaming segment). In the illustrated streaming system 100, each streaming segment contained in the indexed file is encoded by a video encoder at a variable bit rate (VBR) and variable resolution, as described below. II. Video Encoder Overview
[024] Figure 2 depicts one example of a video encoder 200 that can be used for encoding video for multi bit rate video streaming. The video encoder 200 has inputs 210, 220 for receiving "raw" (uncompressed) frames of video content and also previously calculated motion information for the video content. The video encoder then performs intra-frame coding of reference frames of the video content, and utilizes the motion information to perform inter- frame coding of the predicted frames of the video content. The encoding can be performed according to a known video encoding standard, such as Windows Media Video format, SMPTE 421 -M format, MPEG-x format (e.g., MPEG-I, MPEG-2, or MPEG-4), H.26x format (e.g., H.261, H.262, H.263, or H.264), or other format. However, in the case of inter- frame coding, the video encoder can choose to use the pre-calculated motion information for the inter-frame coding of a predicted frame, rather than performing its own motion estimation for the frame. The video encoder encodes the video content into a compressed bitstream provided as output 230. The video encoder may also output the motion information that it used for inter- frame compression of the input video content as motion information output 240 (such as for encoding a lower bit rate video stream for the multiple bit rate video streaming).
(訳)
【0013】
[018] 本明細書において記載する種々の技法およびツールは、独立して用いることができる。これらの技法およびツールの中には、組み合わせて用いることができるものもある。以下では、処理動作(act)のフローチャートを参照しながら種々の技法について説明する。フローチャートにおいて示される種々の処理動作は、それらよりも少ない動作に統合すること、またはそれらよりも多い動作に分離することもできる。簡素化のために、個々のフローチャートに示される動作の、別のところで説明される動作に対する関係は、示されないことが多い。フローチャートにおける動作は、順序を変更できることが多い。
1.多ビット・レート・ビデオ・ストリーミング
[019] 図1は、インデックス化ビデオ・ストリーム・ファイルに収容されているマルチメディア・コンテンツの区分ストリーミングのためのシステム100を一般化したブロック図を示す。インデックス化ファイルは、一般に、マルチメディア・プログラムのビデオを多数のストリーミング・セグメントに分割し、種々のビット・レートのビデオ・セグメントを表す多数の圧縮ビット・ストリームを収容する。MBRビデオ・ストリームは、別個のコード化ストリームとして記載されているが、代替実施態様では、MBRビデオ・ストリームの一部または全部を、多数のコーディング・レイヤーを有する1つのコード化圧縮ビデオ・ストリームとしてエンコードすることもできる。システム100において、サーバー110(例えば、標準的なHTTPサーバーのようなサーバー・コンピューター・システム)がマルチメディア・コンテンツをクライアント120(例えば、ラップトップまたはデスクトップ・コンピューターのようなクライアント・コンピューター・システム、あるいはPDAまたは移動体電話機のような他のタイプのコンピューティング・デバイス)にネットワーク130(例えば、インターネット)を通じて供給する。システム100では、サーバー110はプログラムをインデックス化ファイルに格納する。クライアント120は、クライアント側レート制御ソフトウェアおよび/またはハードウェアを備えている。
【0014】
[020] 具体的な一実施態様例では、サーバー110は標準的なHTTPサーバーであり、ファイルを配給することができる以外には、特別のストリーミング能力が全くない。サーバー110は特殊ビット・レート選択能力をサポートしないので、クライアント120が全てのビット・レート選択動作(activities)を実行しなければならない。この実施態様では、クライアント120は全てのビット・レート選択動作を実行する。例えば、クライアント120は、サーバー110から入手したインデックス情報を用いて(例えば、単独で、またはクライアント・バッファー情報、ネットワーク帯域幅等というような他の情報と組み合わせて)、レート制御を実行することができる。しかしながら、他の実施態様では、レート制御機能の一部または全部をサーバーにおいて行うことができる。
【0015】
[021] 一般に、多ビット・レート・ストリーミング用のインデックス化ファイルは、標準的なHTTPサーバーが、多数のビット・レートでマルチメディア・コンテンツを配給するために用いることができる。ビット・レートの選択(レート制御)は、クライアント側(例えば、クライアント側のみ)で行われる。クライアントは、最初にプログラムのストリーミング・セグメントに利用可能な種々のビット・レートを記載したインデックス情報をサーバーから入手することによって、レート制御を実行することができる。インデックス情報に基づいて、そしてその他にも可能な情報(例えば、ネットワーク帯域幅、バッファー情報等)に基づいて、クライアントは所望のユーザ体験(例えば、利用可能なビット・レートおよび現在のネットワーク状態に基づいて、可能な限り最良のユーザ体験)を提供するためには、どのビット・レートでストリーミング・セグメントをサーバーからダウンロードすればよいか判断することができる。
【0016】
[022] 他のタイプのコンピューティング・デバイス(例えば、従前からのHTTPサーバー以外)が、インデックス化ファイルを用いて、ファイルを提供することもできる。例えば、コンピューティング・デバイス(例えば、パーソナル・コンピューター、サーバー・コンピューター、または特殊目的ストリーミング・メディア・サーバー)がインデックス化ファイル・レイアウトを用いて、種々のファイル配給プロトコル(例えば、ファイル転送プロトコル(FTP)、ハイパーテキスト転送プロトコル(HTTP)、リアル・タイム・ストリーミング・プロトコル(RTSP)、MMS(Microsoft Media Services)等)を用いてマルチメディア・コンテンツを配給することができる。
【0017】
[023] ビット・レートの切り替えをサポートするために、ストリーミング・セグメント(自己完結ユニット)と呼ばれる時間チャンク(temporal chunk)に、プログラムを分割する。サーバーは、各ストリーミング・セグメントを1つ又は複数のビット・レートで格納する(例えば、各ストリーミング・セグメント-ビット・レートの組み合わせが、別のストリーミング・セグメント・エンコーディングとなる)。各ストリーミング・セグメントは、プログラムの特定のトラック(例えば、英語のオーディオ・トラックのような特定のオーディオ・トラック、または特定のビデオ・トラック)に利用可能な1つ又は複数のビット・レート・エンコーディングを有する。次いで、クライアントは、利用可能なビット・レートから(例えば、利用可能なストリーミング・セグメント・エンコーディングから)どのビット・レートにするか判断して、ストリーミング・セグメント毎にダウンロードする。例えば、クライアントは250Kb/秒(キロビット毎秒)でエンコードされたビデオ・トラック用第1ストリーミング・セグメント、500Kb/秒でエンコードされたビデオ・トラック用第2ストリーミング・セグメント(第2ストリーミング・セグメントに利用可能な1つ又は複数のストリーミング・セグメント・エンコーディングから)、および1Mb/秒(メガビット毎秒)でエンコードされたビデオ・トラック用第3ストリーミング・セグメント(第3ストリーミング・セグメントに利用可能な1つ又は複数のストリーミング・セグメント・エンコーディングから)を入手することができる。図示したストリーミング・システム100では、インデックス化ファイルに収容されている各ストリーミング・セグメントは、ビデオ・エンコーダーによって、可変ビット・レート(VBR)および可変解像度で、以下で説明するようにエンコードされる。
II.ビデオ・エンコーダーの全体像
[024] 図2は、多ビット・レート・ビデオ・ストリーミングのためにビデオをエンコードする際に用いることができるビデオ・エンコーダー200の一例を示す。ビデオ・エンコーダー200は、ビデオ・コンテンツの「生の」(未圧縮)フレーム、およびこのビデオ・コンテンツについて予め計算されている動き情報を受信する入力210、220を有する。次いで、このビデオ・エンコーダーは、ビデオ・コンテンツの基準フレームのフレーム内ココーディングを実行し、動き情報を利用して、ビデオ・コンテンツの予測フレームのフレーム間コーディングを実行する。このエンコーディングは、Windows Media Videoフォーマット、SMPTE-421-Mフォーマット、MPEG-xフォーマット(例えば、MPEG-1、MPEG-2、またはMPEG-4)、H.26xフォーマット(例えば、H.261、H.262、H.263、またはH.264)、または他のフォーマットというような、既知のビデオ・エンコーディング規格にしたがって実行することができる。しかしながら、フレーム間コーディングの場合、ビデオ・エンコーダーは、それ自体の動き推定をフレームについて実行する代わりに、予測フレームのフレーム間コーディングについて予め計算されている動き情報を用いることを選択することができる。ビデオ・エンコーダーは、ビデオ・コンテンツをエンコードして圧縮ビットストリームとし、これを出力230として供給する。また、ビデオ・エンコーダーは、入力ビデオ・コンテンツのフレーム間圧縮に用いた動き情報も、動き情報出力240として(多ビット・レート・ビデオ・ストリーミング用に更に低いビット・レートのビデオ・ストリームをエンコードするというようなことのために)出力することができる。

(3-2)当審における拒絶の理由の通知において引用された引用例である特開2002-152274号公報(以下「引用例3」という。)には、図面と共に次に掲げる事項が記載されている。

【0001】
【発明の属する技術分野】本発明はコンピュータおよびコンピュータネットワークに関し、さらに具体的には、エンドユーザのためにメディアストリーミング体験を大幅に向上し、QoS(Quality of Service:サービス品質)フィーチャに対するサポートを提供する方法と構成に関する。
【0002】
【従来の技術】コンピュータおよびデータコミュニケーションネットワークはますます高速化している。この種の高速デバイスと構成が広く使用されている目的の1つは、1種または2種以上のメディアに関連するデータストリームを提供することである。例えば、インターネット(the Internet)の多くのユーザは、ビデオデータおよび/またはオーディオデータを、他のコンピュータまたはサーバから選択的にダウンロードまたは「ストリーム化(streaming)」している。メディアデータを符号化(encode:エンコード)・ストリーム化し、そのあとでストリーム化メディアを受信し、ユーザのためにプレイ(再生)するためのアプリケーションが利用可能になっている。従って、ユーザは、コンピュータネットワークを利用して、符号化/ストリーム化ニュースプログラムを見たり、リアルタイムの投資情報を受信したり、符号化/ストリーム化ラジオショウを聴くことが可能になっている。
【0003】残念ながら、ユーザは、種々の理由で、メディアデータのストリーミングに望ましくない中断が起こる事態を、しばしば体験することがある。例えば、ネットワークが瞬時に輻輳することがあるため、ストリーミングデータの一部が失われることが起こっている。この不確実性の多くは、ストリーム化データを、受信側コンピュータまたは類似デバイスに適切にバッファリングしておくことで解決することができる。この問題を解決する、もう1つの方法は、介在するネットワークリソースを通過するデータ経路(data path)を専用化するか、あるいは他の方法で保証することである。これらの種々リソースは、ストリーミングデータに対して一定レベルのサービス、つまり、QoS(Quality ofService:サービス品質)を保証するように構成することができる。これは、マルチパーティカンファレンシング(multiple party conferencing)アプリケーションなどのように、ツーウェイ(双方向)コミュニケーション(two-way communication)を必要とするアプリケーションをサポートするために行われているのが普通である。
【0004】ストリーム化メディアデータの受信時に起こる中断のほかに、ユーザは、種々のサポートソフトウェアおよびハードウェアシステムが、メディアデータのストリーム化のためのセットアップを行い、メディアデータをストリーム化/バファッリングすることを開始するために必要な、該当情報をやりとりしている間に、初期セッションスタートアップレイテンシ(latency)または遅延を体験することがよく起こっている。
【0005】
【発明が解決しようとする課題】ストリーミングメディアに関連する上記および他の問題は、全体的エンドユーザ体験を低下させる傾向がある。その結果、スタートアップレイテンシを実効的に低減し、QoS機能をサポートする、改良方法と構成が要望されている。

【0024】最初のプロトコルはReSerVationプロトコル(RSVP)であり、これは、ネットワークリソースを直接に制御する下位層プロトコルを取り扱う、ネットワーク制御プロトコルである。そのために、RSVPは、特定のQoSに合致するために要求されるネットワーク106のリソースを予約する機能を備えている。しかし、RSVPは、自身ではどのデータも配送しない。その代わりに、データ配送は、TCP/IP、ユーザデータグラムプロトコル(User Datagram Protocol UDP)、リアルタイムトランスポートプロトコル(Real-Time Transport ProtocolRTP)などの、別のプロトコルによって行われている。
【0025】RTPは、リアルタイムデータをトランスポートすることを目的としたトランスポート層プロトコルである。従って、RTPは、エンドツーエンド配送サービス、タイムスタンピング、シーケンス番号付け(sequence numbering)、などの機能を備えている。特定のQoSを提供するために、RTPはRVSPを利用してリソース予約を行うことが可能になっている。追加のデータ品質と参加者管理は、RTPの制御部分である、リアルタイム制御プロトコル(Real-Time Control Protocol RTCP)から得ることが可能になっている。
【0026】構成100に関連して関心のある、第3のプロトコルはリアルタイムストリーミングプロトコル(RTSP)であり、これは、サーバデバイス102からクライアントデバイス104へのストリーミングメディアの配送を開始し、指示するアプリケーション層制御プロトコルである。RTSPが「ネットワークVCRリモート制御プロトコル」にたとえられているのは、このプロトコルによると、クライアントデバイスのアプリケーション/ユーザは、プレイ、ポーズ(休止)、巻き戻し、高速前送り(fast forward)、などの機能を得ることができるからである(ストリーム化されるタイプのメディアに適用されたとき)。実際のデータ配送は別に行われ、RTPによって行われることが多い。
【0027】エンドユーザの体験を良好化するためには、例えば、エンコーダ、プレイヤなどのストリーミングメディアアプリケーションは、ストリーミングメディアセッション期間に、エンドツーエンドネットワーキングリソースを予約しておくことが要求される。ネットワーキングリソースは、ストリーム化されるメディアプロファイル(media profile)をサポートするために利用できる、十分なバンド幅を確保しておくために必要になるものである。
【0028】従って、上述したように、RSVPや他の類似プロトコルは、トラフィックプロファイルに基づいて所要バンド幅を予約するために採用することができ、RTPや他の類似プロトコルは、予約されたネットワークリソースを利用してストリーミングメディアをトランスポートするために採用することができ、RTSPや他の類似プロトコルは、ストリーミングメディアに対して制御を行うことによって、エンドユーザの体験を良好化するために採用することができる。
【0029】ストリーミングメディアアプリケーションおよびそのアプリケーションの基礎となっているプロトコルスタックに直面している難題の1つは、ストリーミングメディアセッションを開始するコマンドに続く短時間の間に、エンドユーザに納得のいく高品質のメディアデータを提供する必要があることである。
【0030】以上のことを念頭に置いて、図3は、RTSPとRTPを使用して(つまり、QoSが用意されていない)メディアストリーミングセッションを確立するときに起こる、ある種のコントロールベース遅延の例を示す例示時間系列(time-line)グラフである。同図において、時刻t0に、エンドユーザ(クライアントデバイス104)はストリーミングメディアセッションを開始する。時刻t0から時刻t1までに、サーバデバイス102は、必要に応じてクライアントデバイス104およびルータ108と通信して、セッションを開始する。時刻t1から時刻t2までに、メディアデータはストリーム化され、サーバデバイス102から1つまたは2つ以上のルータ108を経由してクライアントデバイス104に送られ、そこでメディアデータはバッファに置かれることになる。時刻t2に、十分なデータがバッファリングされると、エンドユーザに対するストリーム化メディアデータのプレイが開始される。
【0031】この種のストリーミングメディアセッションの一例として、インターネット上を、ワールドワイドウェブ(World Wide Web WWW)を通してビデオデータおよび/またはオーディオデータをストリーム化することがある。エンドユーザ、特に、低バンド幅のネットワークリソースを通して通信しているエンドユーザが、ストリーミングメディアセッションを開始してから、プレイされるメディアを見たり、聴いたりするまでに数秒間待たされることは、普通のことである。この待ち、つまり、セッションスタートセットアップレイテンシは、エンドユーザの体験を大幅に低減させる傾向がある。さらに、いったん確立されたストリーミングメディアセッションは、保証(guaranteed)QoSが関連付けられていないのが通常である(例えば、ベストエフォート(best-effort)で送信されている)。
【0032】図4に示す時間系列グラフは、本発明のいくつかの実施形態による、例示ストリーミングメディアセッションに関連して起こる類似の遅延を示しているが、そこでは、RSVPで設定されている保証QoSがさらに含まれている。同図において、時刻t0に、エンドユーザ(クライアントデバイス104)はストリーミングメディアセッションを開始する。時刻t0から時刻t1までに、サーバデバイス102は、必要に応じて(例えば、RTSPおよびRTPを使用して)、クライアントデバイス104およびルータ108と通信してセッションを開始する。時刻t1から時刻t2までに、サーバデバイス102は、さらに、必要に応じて(例えば、RSVPを使用して)、クライアントデバイス104およびルータ108と通信して適用可能なネットワークリソースを予約する。時刻t2に、メディアデータは、必要とするQoSと共にストリーム化され、サーバデバイス102から予約ネットワーク経路(例えば、選択されたルータ108)を経由してクライアントデバイス104に送られ、そこでメディアデータは、エンドユーザのために即時にプレイされることになる。
【0033】従って、図4に示すように、エンドユーザが体験する総QoSは改善されているが、それでもなお、エンドユーザは、メディアとQoSサービスがセットアップされるまで待たされることになっている。ある種の構成では、このような遅延(待ち)があると、ストリーミングメディアセッションおよび/または通信されるメディアの効果性が低下することになる。従って、セッションスタートアップレイテンシを低減することが、一層に望まれている。
【0034】次に、図5を参照して説明すると、図は、図1のクライアント・サーバ構成が、本発明の別の実施形態に従って例示メディアストリーミング環境を確立するときの様子を時間系列グラフ300で示したものである。
【0035】図示のように、メディアセットアップ遅延期間302は、QoSセットアップ遅延期間304にオーバラップしている。その結果、エンドユーザが体験するセッションスタートアップレイテンシは最小限化され、さもなければ大幅に低減化されることが可能になっている。
【0036】前例に戻って説明すると、ある種の例示実施形態では、メディアセットアップ期間302には、クライアントデバイス104とサーバデバイス102がRTSPコマンド/メッセージをやりとりすることが含まれており、これらは、ストリーミングメディアを開始し、さもなければ制御するために必要になるものである。QoSセットアップ期間304には、保証QoSコネクションを確立するために必要になる、RSVPコマンド/メッセージをやりとりすることが含まれている。
【0037】セットアップ期間302と304がいつ終了するか(つまり、完了するか)に関しては、変動する可能性があることから、ストリーミングメディアをプレイするために選択できるオプションがいくつか用意されている。
【0038】従って、例えば、セットアップ期間302と304が共に同時に終了する場合、あるいはQoSセット期間302がメディアセットアップ期間302の終了前に完了する場合には、メディアデータは、メディアセットアップ期間302の完了時にストリーム化して、RSVP交渉経路(RSVP negotiatedpath)を利用して保証QoSで送ることができる。
【0039】これに反して、メディアセットアップ期間302がQoSセットアップ期間304の完了前に終了する場合には、メディアデータは、(1)RSVP交渉経路が準備状態(ready)になるまで(つまり、QoSセットアップ期間304の終了時に)ストリーム化して非RSVP経路を利用して送ることができるが、そのためには、ストリーム化メディアデータの一部をクライアントデバイス104側のバッファに置いてから、エンドユーザのためにプレイする必要がある。または、(2)RSVP交渉経路が準備状態になるまで待たせておくこともできる。
【0040】このようなオプションが与えられていれば、ある種のアプリケーションは、おそらくは、優先(preferred)QoSフォーマットになっていなくても、ストリーム化メディアを可能な限り早くプレイさせるかどうか、あるいはストリーム化メディアのプレイを、それが優先QoSフォーマットになるまで(例えば、十分な高品質になるまで、RSVP交渉経路で受信されるまで、といったように)待たせるかを、エンドユーザおよび/またはサーバアドミニストレータ(管理者)に選択させるように構成することも可能である。その結果、エンドユーザは、ストリーム化メディアセッションの開始時に、異なる遅延および/またはプレイされるメディア品質を体験することになる。
【0041】例として、エンドユーザは、可能な限り早くストリーム化ビデオデータを受信/プレイすることを選択したが、最終的には、保証QoSを望んでいると想定する。さらに、ネットワーク輻輳または他の類似原因の結果として、メディアセットアップ期間302の終了からQoSセットアップ期間304の終了までに、約5秒間の待ちが生じたものと想定する。従って、この想定の下では、ビデオデータは、従来の「ベストエフォート(best effort)」コミュニケーションを使用してネットワーク106上でストリーミングを開始し、クライアントデバイス104側で瞬時に累積/バッファリングされたあとで(例えば、約2秒間を要したあとで)、エンドユーザのためにプレイされることになる。従って、若干待たされた後で、エンドユーザは、ストリーミングビデオの最初の3秒間を、そのとき望まれていた低品質で体験することになる。しかし、QoSセットアップ遅延期間304が終了し、RSVP交渉経路が確立されると、ストリーミングビデオは望みの品質になることになる。
【0042】上記の例では、セットアップ遅延期間302と304は、基本的にオーバラップしている。しかし、実装されるプロトコルに応じて、セットアップ遅延期間302と304を結合すると、エンドユーザが体験する遅延をさらに低減することが可能になる。

第4 引用例に記載された発明
以上の記載によれば、引用例1には次の発明(以下、引用例1発明という。)が記載されている。

(4-1)引用例1の[019]には「システム100において、サーバー110(例えば、標準的なHTTPサーバーのようなサーバー・コンピューター・システム)がマルチメディア・コンテンツをクライアント120(例えば、ラップトップまたはデスクトップ・コンピューターのようなクライアント・コンピューター・システム、あるいはPDAまたは移動体電話機のような他のタイプのコンピューティング・デバイス)にネットワーク130(例えば、インターネット)を通じて供給する。」との記載があるから、引用例1には、サーバーがクライアントにマルチメディア・コンテンツをネットワークを通じて供給することに関する発明が開示されているといえる。
上記供給に関して、[0022]には「種々のファイル配給プロトコル(例えば、ファイル転送プロトコル(FTP)、ハイパーテキスト転送プロトコル(HTTP)、リアル・タイム・ストリーミング・プロトコル(RTSP)、MMS(Microsoft Media Services)等)を用いてマルチメディア・コンテンツを配給することができる。」とあるから、リアル・タイム・ストリーミング・プロトコル(RTSP)を用いて供給することも開示されている。
上記マルチメディア・コンテンツは、引用例1の「マルチメディア・コンテンツの区分ストリーミングのためのシステム100を一般化したブロック図を示す。インデックス化ファイルは、一般に、マルチメディア・プログラムのビデオを多数のストリーミング・セグメントに分割し、種々のビット・レートのビデオ・セグメントを表す多数の圧縮ビット・ストリームを収容する。」([019])、「ストリーミング・セグメント(自己完結ユニット)と呼ばれる時間チャンク(temporal chunk)に、プログラムを分割する。」([023])の記載によれば、時間により分割されたストリーミング・セグメントからなることが開示されているといえる。
以上まとめると、引用例1には、サーバーがクライアントに、時間により分割されたストリーミング・セグメントからなるマルチメディア・コンテンツを、リアル・タイム・ストリーミング・プロトコル(RTSP)を用いてネットワークを通じて供給することに関する発明が開示されている。

(4-2)引用例1の[021]には「クライアントは、最初にプログラムのストリーミング・セグメントに利用可能な種々のビット・レートを記載したインデックス情報をサーバーから入手することによって、レート制御を実行することができる。」と記載されており、上記「プログラム」は、「マルチメディア・プログラムのビデオ」([019])であることは明らかであって、「マルチメディア・コンテンツ」といいかえることができるから、「クライアントは、最初に、マルチメディア・コンテンツのストリーミング・セグメントに利用可能な種々のビット・レートを記載したインデックス情報をサーバーから入手する」ことが開示されている。
上記入手したビットレートに基づいて、以下(4-3)にあるように、ダウンロードすべき所望のストリーミング・セグメントを判断しているから、上記ビットレートは、マルチメディア・コンテンツのストリーミング・セグメントから所望のストリーミング・セグメントを判断するためのインデックス情報といえる。
したがって、引用例1には「クライアントは、最初に、マルチメディア・コンテンツのストリーミング・セグメントから所望のストリーミング・セグメントを判断するためのインデックス情報をサーバーから入手する」ことが開示されている。

(4-3)引用例1の[021]、[023]の記載によれば、クライアントは、インデックス情報に基づいてどのストリーミング・セグメントをサーバーからダウンロードすればよいか判断し、ストリーミング・セグメント毎にマルチメディア・コンテンツをダウンロードすることが開示されている。

(4-4)まとめ
以上によれば、
「サーバーがクライアントに、時間により分割されたストリーミング・セグメントからなるマルチメディア・コンテンツを、リアル・タイム・ストリーミング・プロトコル(RTSP)を用いてネットワークを通じて供給することに関する発明において、
クライアントは、
最初に、マルチメディア・コンテンツのストリーミング・セグメントから所望のストリーミング・セグメントを判断するためのインデックス情報をサーバーから入手し、
インデックス情報に基づいてどのストリーミング・セグメントをサーバーからダウンロードすればよいか判断し、ストリーミング・セグメント毎にマルチメディア・コンテンツをダウンロードする」
ことが開示されているといえ、上記「入手」、「ダウンロード」は、クライアントにおける処理のステップであるから、当該ステップを有するクライアントにおける方法の発明が開示されているといえる。
してみると、引用例1発明として、以下のとおりのものを認定することができる。((a)ないし(d)は当審において付与し、以下「構成要件(a)」等として引用する。)

(a)サーバーがクライアントに、時間により分割されたストリーミング・セグメントからなるマルチメディア・コンテンツを、リアル・タイム・ストリーミング・プロトコル(RTSP)を用いてネットワークを通じて供給する際のクライアントにおける方法であって、
(b)最初に、マルチメディア・コンテンツのストリーミング・セグメントから所望のストリーミング・セグメントを判断するためのインデックス情報をサーバーから入手するステップと、
(c)インデックス情報に基づいてどのストリーミング・セグメントをサーバーからダウンロードすればよいか判断し、ストリーミング・セグメント毎にマルチメディア・コンテンツをダウンロードするステップとを有する、
(d)方法。

第5 対比
本願発明と引用例1発明とを対比する。

(5-1)本願発明の構成要件(A)と引用例1発明の構成要件(a)とを対比する。
引用例1発明の「マルチメディア・コンテンツ」は、[019]の記載によれば、ビデオストリームであるから、本願発明の「メディアストリーム」に相当する。
そして、上記「マルチメディア・コンテンツ」は、時間により分割された(ストリーミング・)セグメントからなるから、連続した複数のストリーム要素(84)に時間において分割されたメディアストリームといえることは明らかである。
さらに、引用例1発明は、「マルチメディア・コンテンツを、リアル・タイム・ストリーミング・プロトコル(RTSP)を用いてネットワークを通じて供給する際のクライアントにおける方法」であって、当該コンテンツをネットワークを通じて供給することは、伝送することともいえ、上記伝送する際のクライアントにおける方法は、伝送を制御するためのメディアクライアントにおける方法ともいえるから、引用例1発明の構成要件(a)は、本願発明の構成要件(A)と相違がない。

(5-2)本願発明の構成要件(B)と引用例1発明の構成要件(b)とを対比する。
引用例1発明における「インデックス情報」は、引用例1の[019]の「図1は、インデックス化ビデオ・ストリーム・ファイルに収容されているマルチメディア・コンテンツの区分ストリーミングのためのシステム100を一般化したブロック図を示す。インデックス化ファイルは、一般に、マルチメディア・プログラムのビデオを多数のストリーミング・セグメントに分割し、種々のビット・レートのビデオ・セグメントを表す多数の圧縮ビット・ストリームを収容する。・・・システム100では、サーバー110はプログラムをインデックス化ファイルに格納する。」の記載によれば、「インデックス化ビデオ・ストリーム・ファイルに収容されているマルチメディア・コンテンツ」のインデックス情報であることは明らかであり、マルチメディア・コンテンツのインデックス情報とは、「マルチメディア・プログラムのビデオを多数のストリーミング・セグメントに分割し、種々のビット・レートのビデオ・セグメントを表す多数の圧縮ビット・ストリーム」として収容した、インデックス化ファイルのインデックス情報であるから、ストリーミング・セグメントに分割したビデオストリームの各セグメントのインデックス情報である。
すなわち、インデックス情報は、各セグメントのインデックス情報であって、各セグメントが格納されているところを特定する情報であるから、セグメントのメディアソースを示す、前記メディアストリームのメディア記述といえる。
そして、最初に入手する上記インデックス情報は、複数のストリーム要素のうちの最初の要素のメディアソースも含むことは当然のことである。
以上のことから、引用例1発明の構成要件(b)は、本願発明の構成要件(B)に相当する。

(5-3)本願発明の構成要件(C)と引用例1発明の構成要件(c)とを対比する。
引用例1発明では「ストリーミング・セグメント毎にマルチメディア・コンテンツをダウンロード」しているから、当然、最初のセグメント(要素)を求めるリクエストを送信していることは明らかである。
したがって、引用例1発明は、本願発明の構成要件(C)を有している。

(5-4)本願発明の構成要件(D)と引用例1発明とを対比する。
引用例1発明は、セッション制御に関する特定事項を備えていることが特定されていないから、本願発明の構成要件(D)を有していない。

(5-5)本願発明の構成要件(E)と引用例1発明の構成要件(c)、(d)とを対比する。
引用例1発明が、「前記最初の要素(92)を求めるリクエストを送信するステップ」を有していることは、上記(5-3)で検討したとおりであり、したがって、「前記最初の要素(92)を求めるリクエストを送信するステップ(34)が実行される方法」である点で、本願発明と相違がない。
もっとも、本願発明では、上記「前記最初の要素(92)を求めるリクエストを送信するステップ(34)が実行される」のは、「前記セッション制御手続きの結果を受信する前に実行される」のに対し、引用例1発明は、セッション制御に関する特定事項を有していないから、「前記セッション制御手続きの結果を受信する前に実行される」との特定事項を有していない点で相違する。

(5-6)まとめ(一致点・相違点)
以上まとめると、本願発明と引用例1発明とは以下の一致点で一致し相違点で相違する。

(一致点)
連続した複数のストリーム要素(84)に時間において分割されたメディアストリームの伝送を制御するためのメディアクライアントにおける方法であって、
前記複数のストリーム要素のうちの最初の要素(92)のメディアソースを示す、前記メディアストリームのメディア記述(100)を取得するステップ(32)と、
前記最初の要素(92)を求めるリクエストを送信するステップ(34)と、
前記最初の要素(92)を求めるリクエストを送信するステップ(34)は実行されることを特徴とする方法。

(相違点)
相違点1
本願発明は、「前記メディアストリームの伝送のためのセッション制御手続きを開始するステップ」を有しているのに対し、引用例1発明は、当該構成を有していない点。

相違点2
本願発明「前記最初の要素(92)を求めるリクエストを送信するステップ(34)は、前記セッション制御手続きの結果を受信する前に実行される」のに対し、引用例1発明では、「前記最初の要素(92)を求めるリクエストを送信するステップ(34)は実行されるものの「前記セッション制御手続きの結果を受信する前に実行される」ことが特定されていない点。

第6 判断
上記相違点について検討する。

(6-1)相違点1について
引用例1発明において、メディアデータ(メディアストリーム)は「リアル・タイム・ストリーミング・プロトコル(RTSP)」を用いて送信されている。
ここで、「リアル・タイム・ストリーミング・プロトコル(RTSP)」でビデオストリーム等を送信するときには、セッション制御手続きを行うことは、下記の周知文献にあるとおり普通の構成であり、引用例1発明を「リアル・タイム・ストリーミング・プロトコル(RTSP)」で実現したときに、相違点1の構成を採用することは当業者にとって当たり前のことである。

周知文献1:特開2009-182417号公報(【0017】等参照)
周知文献2:特開2009-225339号公報(【0003】-【0007】等参照)

(6-2)相違点2について
上記(6-1)で検討したように、引用例1発明では、メディアデータの送信をリアル・タイム・ストリーミング・プロトコル(RTSP)で行っているのであるから、セッション制御手続を開始するステップを有することは普通のことである。
このとき、上記周知のセッション制御手続は、上記周知文献1、周知文献2にあるように、クライアントとサーバとの間で、セッションを確立するための制御であって、メディアデータの送信に先立って行われるものであり、例えば、「ストリーム送出用のリソースの確保」(周知文献1【0017】)等が行われることもよく知られたことである。
ここで、リアル・タイム・ストリーミング・プロトコル(RTSP)を用い、リソースの確保を行いメディアデータを送信する具体的な構成が開示されている引用例3には、セッション制御手続が行われた後、ストリーミングが開始される構成であると、「ストリーミングメディアセッションおよび/または通信されるメディアの効果性が低下する」から、「セッションスタートアップレイテンシを低減する」(【0033】)ための構成として、以下の構成(【0034】-【0042】)が開示されている。

『メディアセットアップ遅延期間302とQoSセットアップ遅延期間304とをオーバーラップさせてメディアストリーミング環境を確立(セッションを確立)するとき、メディアセットアップ期間302がQoSセットアップ期間304の完了前に終了する場合、優先(preferred)QoSフォーマットになっていなくても、ストリーム化メディアを可能な限り早くプレイさせるために、QoSセットアップ遅延期間304が終了し、RSVP交渉経路が確立される以前に、ネットワーク106上でストリーミングを開始すること』

上記「QoSセットアップ遅延期間304が終了し、RSVP交渉経路が確立される以前」とは、RSVP交渉経路が確立したことを示す結果の受信の前であるから、「セッション制御手続きの結果を受信する前」に相当する。
すなわち、引用例3には、「セッション制御手続きの結果を受信する前」に、ストリーミングが開始される構成(最初の要素を求めるリクエストを送信するステップが含まれていることは明らかである。)が開示されているといえ、引用例1発明においても、セッション制御手続きの結果を受信した後に最初の要素を求めるリクエストを送信した場合、遅延が生じることは当然予測可能であるから、当該遅延を防止するため、引用例3に記載された事項を適用し、相違点2の構成を採用することは、当業者が容易になしえたことである。

したがって、上記各相違点は、当業者が容易に想到し得たものと認められ、本願発明全体としてみても格別のものはなく、その作用効果も、上記各相違点に係る構成の採用に伴って当然に予測される程度のものにすぎず、格別顕著なものがあるとは認められない。

第7 むすび
以上のとおり、本願発明は、引用例1、引用例3に記載された事項および本願出願前周知の事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
したがって、残る請求項1ないし請求項12、請求項14ないし請求項24に係る発明について検討するまでもなく、本願は拒絶すべきものである。
よって、結論のとおり審決する。
 
審理終結日 2016-10-07 
結審通知日 2016-10-11 
審決日 2016-10-24 
出願番号 特願2013-523493(P2013-523493)
審決分類 P 1 8・ 121- WZ (H04N)
最終処分 不成立  
前審関与審査官 後藤 嘉宏福西 章人  
特許庁審判長 清水 正一
特許庁審判官 小池 正彦
渡邊 聡
発明の名称 メディアストリーム伝送のためのセッション制御  
代理人 大塚 康徳  
代理人 大塚 康弘  
代理人 高柳 司郎  
代理人 永川 行光  
代理人 木村 秀二  
代理人 下山 治  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ