【事件の表示】
　特願２０１３−５２３４９３「メディアストリーム伝送のためのセッション制御」拒絶査定不服審判事件〔平成２４年　２月１６日国際公開、ＷＯ２０１２／０１９６２１、平成２５年１１月　７日国内公表、特表２０１３−５４１２４５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２０１０年（平成２２年）８月１０日を国際出願日とする国際特許出願であって、手続の概要は以下のとおりである。
　
手続補正　　　　　　　：平成２５年　７月１０日
拒絶理由通知　　　　　：平成２６年　５月１５日（起案日）
手続補正　　　　　　　：平成２６年　８月２０日
拒絶査定　　　　　　　：平成２７年　２月２６日（起案日）
拒絶査定不服審判請求　：平成２７年　７月　１日
手続補正　　　　　　　：平成２７年　７月　１日
拒絶理由（当審）　　　：平成２８年　６月　２日（起案日）
手続補正　　　　　　　：平成２８年　９月　６日
　
第２　本願発明
　本願の請求項１３に係る発明（以下、「本願発明」という。）は、平成２８年９月６日付けの手続補正書により補正された特許請求の範囲の請求項１３に記載された事項により特定される、以下のとおりのものである。
（（Ａ）ないし（Ｅ）は当審において付与した。以下「構成要件（Ａ）」等として引用する。）
 　
　　【請求項１３】
（Ａ）連続した複数のストリーム要素（８４）に時間において分割されたメディアストリームの伝送を制御するためのメディアクライアントにおける方法であって、
（Ｂ）前記複数のストリーム要素のうちの最初の要素（９２）のメディアソースを示す、前記メディアストリームのメディア記述（１００）を取得するステップ（３２）と、
（Ｃ）前記最初の要素（９２）を求めるリクエストを送信するステップ（３４）と、
（Ｄ）前記メディアストリームの伝送のためのセッション制御手続きを開始するステップ（３６）とを有し、
（Ｅ）前記最初の要素（９２）を求めるリクエストを送信するステップ（３４）は、前記セッション制御手続きの結果を受信する前に実行されることを特徴とする方法。
　
第３　引用例の記載事項
（３−１）当審における拒絶の理由の通知において引用された引用例である国際公開第２０１０／０８８０３０号（以下「引用例１」という。）には、図面と共に次に掲げる事項が記載されている。（翻訳は、引用例１のパテントファミリーである特表２０１２−５１６６４４号公報の記載に基づいて合議体が作成した。）
　
[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).
（訳）
【００１３】
  [018]  本明細書において記載する種々の技法およびツールは、独立して用いることができる。これらの技法およびツールの中には、組み合わせて用いることができるものもある。以下では、処理動作(act)のフローチャートを参照しながら種々の技法について説明する。フローチャートにおいて示される種々の処理動作は、それらよりも少ない動作に統合すること、またはそれらよりも多い動作に分離することもできる。簡素化のために、個々のフローチャートに示される動作の、別のところで説明される動作に対する関係は、示されないことが多い。フローチャートにおける動作は、順序を変更できることが多い。
１．多ビット・レート・ビデオ・ストリーミング
  [019]  図１は、インデックス化ビデオ・ストリーム・ファイルに収容されているマルチメディア・コンテンツの区分ストリーミングのためのシステム１００を一般化したブロック図を示す。インデックス化ファイルは、一般に、マルチメディア・プログラムのビデオを多数のストリーミング・セグメントに分割し、種々のビット・レートのビデオ・セグメントを表す多数の圧縮ビット・ストリームを収容する。ＭＢＲビデオ・ストリームは、別個のコード化ストリームとして記載されているが、代替実施態様では、ＭＢＲビデオ・ストリームの一部または全部を、多数のコーディング・レイヤーを有する１つのコード化圧縮ビデオ・ストリームとしてエンコードすることもできる。システム１００において、サーバー１１０（例えば、標準的なＨＴＴＰサーバーのようなサーバー・コンピューター・システム）がマルチメディア・コンテンツをクライアント１２０（例えば、ラップトップまたはデスクトップ・コンピューターのようなクライアント・コンピューター・システム、あるいはＰＤＡまたは移動体電話機のような他のタイプのコンピューティング・デバイス）にネットワーク１３０（例えば、インターネット）を通じて供給する。システム１００では、サーバー１１０はプログラムをインデックス化ファイルに格納する。クライアント１２０は、クライアント側レート制御ソフトウェアおよび／またはハードウェアを備えている。
【００１４】
  [020]  具体的な一実施態様例では、サーバー１１０は標準的なＨＴＴＰサーバーであり、ファイルを配給することができる以外には、特別のストリーミング能力が全くない。サーバー１１０は特殊ビット・レート選択能力をサポートしないので、クライアント１２０が全てのビット・レート選択動作(activities)を実行しなければならない。この実施態様では、クライアント１２０は全てのビット・レート選択動作を実行する。例えば、クライアント１２０は、サーバー１１０から入手したインデックス情報を用いて（例えば、単独で、またはクライアント・バッファー情報、ネットワーク帯域幅等というような他の情報と組み合わせて）、レート制御を実行することができる。しかしながら、他の実施態様では、レート制御機能の一部または全部をサーバーにおいて行うことができる。
【００１５】
  [021]  一般に、多ビット・レート・ストリーミング用のインデックス化ファイルは、標準的なＨＴＴＰサーバーが、多数のビット・レートでマルチメディア・コンテンツを配給するために用いることができる。ビット・レートの選択（レート制御）は、クライアント側（例えば、クライアント側のみ）で行われる。クライアントは、最初にプログラムのストリーミング・セグメントに利用可能な種々のビット・レートを記載したインデックス情報をサーバーから入手することによって、レート制御を実行することができる。インデックス情報に基づいて、そしてその他にも可能な情報（例えば、ネットワーク帯域幅、バッファー情報等）に基づいて、クライアントは所望のユーザ体験（例えば、利用可能なビット・レートおよび現在のネットワーク状態に基づいて、可能な限り最良のユーザ体験）を提供するためには、どのビット・レートでストリーミング・セグメントをサーバーからダウンロードすればよいか判断することができる。
【００１６】
  [022]  他のタイプのコンピューティング・デバイス（例えば、従前からのＨＴＴＰサーバー以外）が、インデックス化ファイルを用いて、ファイルを提供することもできる。例えば、コンピューティング・デバイス（例えば、パーソナル・コンピューター、サーバー・コンピューター、または特殊目的ストリーミング・メディア・サーバー）がインデックス化ファイル・レイアウトを用いて、種々のファイル配給プロトコル（例えば、ファイル転送プロトコル（ＦＴＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）、ＭＭＳ（Microsoft Media Services)等）を用いてマルチメディア・コンテンツを配給することができる。
【００１７】
  [023]  ビット・レートの切り替えをサポートするために、ストリーミング・セグメント（自己完結ユニット）と呼ばれる時間チャンク(temporal chunk)に、プログラムを分割する。サーバーは、各ストリーミング・セグメントを１つ又は複数のビット・レートで格納する（例えば、各ストリーミング・セグメント−ビット・レートの組み合わせが、別のストリーミング・セグメント・エンコーディングとなる）。各ストリーミング・セグメントは、プログラムの特定のトラック（例えば、英語のオーディオ・トラックのような特定のオーディオ・トラック、または特定のビデオ・トラック）に利用可能な１つ又は複数のビット・レート・エンコーディングを有する。次いで、クライアントは、利用可能なビット・レートから（例えば、利用可能なストリーミング・セグメント・エンコーディングから）どのビット・レートにするか判断して、ストリーミング・セグメント毎にダウンロードする。例えば、クライアントは２５０Ｋｂ／秒（キロビット毎秒）でエンコードされたビデオ・トラック用第１ストリーミング・セグメント、５００Ｋｂ／秒でエンコードされたビデオ・トラック用第２ストリーミング・セグメント（第２ストリーミング・セグメントに利用可能な１つ又は複数のストリーミング・セグメント・エンコーディングから）、および１Ｍｂ／秒（メガビット毎秒）でエンコードされたビデオ・トラック用第３ストリーミング・セグメント（第３ストリーミング・セグメントに利用可能な１つ又は複数のストリーミング・セグメント・エンコーディングから）を入手することができる。図示したストリーミング・システム１００では、インデックス化ファイルに収容されている各ストリーミング・セグメントは、ビデオ・エンコーダーによって、可変ビット・レート（ＶＢＲ）および可変解像度で、以下で説明するようにエンコードされる。
ＩＩ．ビデオ・エンコーダーの全体像
  [024]  図２は、多ビット・レート・ビデオ・ストリーミングのためにビデオをエンコードする際に用いることができるビデオ・エンコーダー２００の一例を示す。ビデオ・エンコーダー２００は、ビデオ・コンテンツの「生の」（未圧縮）フレーム、およびこのビデオ・コンテンツについて予め計算されている動き情報を受信する入力２１０、２２０を有する。次いで、このビデオ・エンコーダーは、ビデオ・コンテンツの基準フレームのフレーム内ココーディングを実行し、動き情報を利用して、ビデオ・コンテンツの予測フレームのフレーム間コーディングを実行する。このエンコーディングは、Windows Media Videoフォーマット、SMPTE-421-Mフォーマット、ＭＰＥＧ−ｘフォーマット（例えば、ＭＰＥＧ−１、ＭＰＥＧ−２、またはＭＰＥＧ−４）、Ｈ．２６ｘフォーマット（例えば、Ｈ．２６１、Ｈ．２６２、Ｈ．２６３、またはＨ．２６４）、または他のフォーマットというような、既知のビデオ・エンコーディング規格にしたがって実行することができる。しかしながら、フレーム間コーディングの場合、ビデオ・エンコーダーは、それ自体の動き推定をフレームについて実行する代わりに、予測フレームのフレーム間コーディングについて予め計算されている動き情報を用いることを選択することができる。ビデオ・エンコーダーは、ビデオ・コンテンツをエンコードして圧縮ビットストリームとし、これを出力２３０として供給する。また、ビデオ・エンコーダーは、入力ビデオ・コンテンツのフレーム間圧縮に用いた動き情報も、動き情報出力２４０として（多ビット・レート・ビデオ・ストリーミング用に更に低いビット・レートのビデオ・ストリームをエンコードするというようなことのために）出力することができる。
　
（３−２）当審における拒絶の理由の通知において引用された引用例である特開２００２−１５２２７４号公報（以下「引用例３」という。）には、図面と共に次に掲げる事項が記載されている。
　
【０００１】
【発明の属する技術分野】本発明はコンピュータおよびコンピュータネットワークに関し、さらに具体的には、エンドユーザのためにメディアストリーミング体験を大幅に向上し、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ：サービス品質）フィーチャに対するサポートを提供する方法と構成に関する。
【０００２】
【従来の技術】コンピュータおよびデータコミュニケーションネットワークはますます高速化している。この種の高速デバイスと構成が広く使用されている目的の１つは、１種または２種以上のメディアに関連するデータストリームを提供することである。例えば、インターネット（ｔｈｅ  Ｉｎｔｅｒｎｅｔ）の多くのユーザは、ビデオデータおよび／またはオーディオデータを、他のコンピュータまたはサーバから選択的にダウンロードまたは「ストリーム化（ｓｔｒｅａｍｉｎｇ）」している。メディアデータを符号化（ｅｎｃｏｄｅ：エンコード）・ストリーム化し、そのあとでストリーム化メディアを受信し、ユーザのためにプレイ（再生）するためのアプリケーションが利用可能になっている。従って、ユーザは、コンピュータネットワークを利用して、符号化／ストリーム化ニュースプログラムを見たり、リアルタイムの投資情報を受信したり、符号化／ストリーム化ラジオショウを聴くことが可能になっている。
【０００３】残念ながら、ユーザは、種々の理由で、メディアデータのストリーミングに望ましくない中断が起こる事態を、しばしば体験することがある。例えば、ネットワークが瞬時に輻輳することがあるため、ストリーミングデータの一部が失われることが起こっている。この不確実性の多くは、ストリーム化データを、受信側コンピュータまたは類似デバイスに適切にバッファリングしておくことで解決することができる。この問題を解決する、もう１つの方法は、介在するネットワークリソースを通過するデータ経路（ｄａｔａ  ｐａｔｈ）を専用化するか、あるいは他の方法で保証することである。これらの種々リソースは、ストリーミングデータに対して一定レベルのサービス、つまり、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆＳｅｒｖｉｃｅ：サービス品質）を保証するように構成することができる。これは、マルチパーティカンファレンシング（ｍｕｌｔｉｐｌｅ  ｐａｒｔｙ  ｃｏｎｆｅｒｅｎｃｉｎｇ）アプリケーションなどのように、ツーウェイ（双方向）コミュニケーション（ｔｗｏ−ｗａｙ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）を必要とするアプリケーションをサポートするために行われているのが普通である。
【０００４】ストリーム化メディアデータの受信時に起こる中断のほかに、ユーザは、種々のサポートソフトウェアおよびハードウェアシステムが、メディアデータのストリーム化のためのセットアップを行い、メディアデータをストリーム化／バファッリングすることを開始するために必要な、該当情報をやりとりしている間に、初期セッションスタートアップレイテンシ（ｌａｔｅｎｃｙ）または遅延を体験することがよく起こっている。
【０００５】
【発明が解決しようとする課題】ストリーミングメディアに関連する上記および他の問題は、全体的エンドユーザ体験を低下させる傾向がある。その結果、スタートアップレイテンシを実効的に低減し、ＱｏＳ機能をサポートする、改良方法と構成が要望されている。
　
【００２４】最初のプロトコルはＲｅＳｅｒＶａｔｉｏｎプロトコル（ＲＳＶＰ）であり、これは、ネットワークリソースを直接に制御する下位層プロトコルを取り扱う、ネットワーク制御プロトコルである。そのために、ＲＳＶＰは、特定のＱｏＳに合致するために要求されるネットワーク１０６のリソースを予約する機能を備えている。しかし、ＲＳＶＰは、自身ではどのデータも配送しない。その代わりに、データ配送は、ＴＣＰ／ＩＰ、ユーザデータグラムプロトコル（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ    ＵＤＰ）、リアルタイムトランスポートプロトコル（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  ＰｒｏｔｏｃｏｌＲＴＰ）などの、別のプロトコルによって行われている。
【００２５】ＲＴＰは、リアルタイムデータをトランスポートすることを目的としたトランスポート層プロトコルである。従って、ＲＴＰは、エンドツーエンド配送サービス、タイムスタンピング、シーケンス番号付け（ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒｉｎｇ）、などの機能を備えている。特定のＱｏＳを提供するために、ＲＴＰはＲＶＳＰを利用してリソース予約を行うことが可能になっている。追加のデータ品質と参加者管理は、ＲＴＰの制御部分である、リアルタイム制御プロトコル（Ｒｅａｌ−Ｔｉｍｅ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ    ＲＴＣＰ）から得ることが可能になっている。
【００２６】構成１００に関連して関心のある、第３のプロトコルはリアルタイムストリーミングプロトコル（ＲＴＳＰ）であり、これは、サーバデバイス１０２からクライアントデバイス１０４へのストリーミングメディアの配送を開始し、指示するアプリケーション層制御プロトコルである。ＲＴＳＰが「ネットワークＶＣＲリモート制御プロトコル」にたとえられているのは、このプロトコルによると、クライアントデバイスのアプリケーション／ユーザは、プレイ、ポーズ（休止）、巻き戻し、高速前送り（ｆａｓｔ  ｆｏｒｗａｒｄ）、などの機能を得ることができるからである（ストリーム化されるタイプのメディアに適用されたとき）。実際のデータ配送は別に行われ、ＲＴＰによって行われることが多い。
【００２７】エンドユーザの体験を良好化するためには、例えば、エンコーダ、プレイヤなどのストリーミングメディアアプリケーションは、ストリーミングメディアセッション期間に、エンドツーエンドネットワーキングリソースを予約しておくことが要求される。ネットワーキングリソースは、ストリーム化されるメディアプロファイル（ｍｅｄｉａ  ｐｒｏｆｉｌｅ）をサポートするために利用できる、十分なバンド幅を確保しておくために必要になるものである。
【００２８】従って、上述したように、ＲＳＶＰや他の類似プロトコルは、トラフィックプロファイルに基づいて所要バンド幅を予約するために採用することができ、ＲＴＰや他の類似プロトコルは、予約されたネットワークリソースを利用してストリーミングメディアをトランスポートするために採用することができ、ＲＴＳＰや他の類似プロトコルは、ストリーミングメディアに対して制御を行うことによって、エンドユーザの体験を良好化するために採用することができる。
【００２９】ストリーミングメディアアプリケーションおよびそのアプリケーションの基礎となっているプロトコルスタックに直面している難題の１つは、ストリーミングメディアセッションを開始するコマンドに続く短時間の間に、エンドユーザに納得のいく高品質のメディアデータを提供する必要があることである。
【００３０】以上のことを念頭に置いて、図３は、ＲＴＳＰとＲＴＰを使用して（つまり、ＱｏＳが用意されていない）メディアストリーミングセッションを確立するときに起こる、ある種のコントロールベース遅延の例を示す例示時間系列（ｔｉｍｅ−ｌｉｎｅ）グラフである。同図において、時刻ｔ０に、エンドユーザ（クライアントデバイス１０４）はストリーミングメディアセッションを開始する。時刻ｔ０から時刻ｔ１までに、サーバデバイス１０２は、必要に応じてクライアントデバイス１０４およびルータ１０８と通信して、セッションを開始する。時刻ｔ１から時刻ｔ２までに、メディアデータはストリーム化され、サーバデバイス１０２から１つまたは２つ以上のルータ１０８を経由してクライアントデバイス１０４に送られ、そこでメディアデータはバッファに置かれることになる。時刻ｔ２に、十分なデータがバッファリングされると、エンドユーザに対するストリーム化メディアデータのプレイが開始される。
【００３１】この種のストリーミングメディアセッションの一例として、インターネット上を、ワールドワイドウェブ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ    ＷＷＷ）を通してビデオデータおよび／またはオーディオデータをストリーム化することがある。エンドユーザ、特に、低バンド幅のネットワークリソースを通して通信しているエンドユーザが、ストリーミングメディアセッションを開始してから、プレイされるメディアを見たり、聴いたりするまでに数秒間待たされることは、普通のことである。この待ち、つまり、セッションスタートセットアップレイテンシは、エンドユーザの体験を大幅に低減させる傾向がある。さらに、いったん確立されたストリーミングメディアセッションは、保証（ｇｕａｒａｎｔｅｅｄ）ＱｏＳが関連付けられていないのが通常である（例えば、ベストエフォート（ｂｅｓｔ−ｅｆｆｏｒｔ）で送信されている）。
【００３２】図４に示す時間系列グラフは、本発明のいくつかの実施形態による、例示ストリーミングメディアセッションに関連して起こる類似の遅延を示しているが、そこでは、ＲＳＶＰで設定されている保証ＱｏＳがさらに含まれている。同図において、時刻ｔ０に、エンドユーザ（クライアントデバイス１０４）はストリーミングメディアセッションを開始する。時刻ｔ０から時刻ｔ１までに、サーバデバイス１０２は、必要に応じて（例えば、ＲＴＳＰおよびＲＴＰを使用して）、クライアントデバイス１０４およびルータ１０８と通信してセッションを開始する。時刻ｔ１から時刻ｔ２までに、サーバデバイス１０２は、さらに、必要に応じて（例えば、ＲＳＶＰを使用して）、クライアントデバイス１０４およびルータ１０８と通信して適用可能なネットワークリソースを予約する。時刻ｔ２に、メディアデータは、必要とするＱｏＳと共にストリーム化され、サーバデバイス１０２から予約ネットワーク経路（例えば、選択されたルータ１０８）を経由してクライアントデバイス１０４に送られ、そこでメディアデータは、エンドユーザのために即時にプレイされることになる。
【００３３】従って、図４に示すように、エンドユーザが体験する総ＱｏＳは改善されているが、それでもなお、エンドユーザは、メディアとＱｏＳサービスがセットアップされるまで待たされることになっている。ある種の構成では、このような遅延（待ち）があると、ストリーミングメディアセッションおよび／または通信されるメディアの効果性が低下することになる。従って、セッションスタートアップレイテンシを低減することが、一層に望まれている。
【００３４】次に、図５を参照して説明すると、図は、図１のクライアント・サーバ構成が、本発明の別の実施形態に従って例示メディアストリーミング環境を確立するときの様子を時間系列グラフ３００で示したものである。
【００３５】図示のように、メディアセットアップ遅延期間３０２は、ＱｏＳセットアップ遅延期間３０４にオーバラップしている。その結果、エンドユーザが体験するセッションスタートアップレイテンシは最小限化され、さもなければ大幅に低減化されることが可能になっている。
【００３６】前例に戻って説明すると、ある種の例示実施形態では、メディアセットアップ期間３０２には、クライアントデバイス１０４とサーバデバイス１０２がＲＴＳＰコマンド／メッセージをやりとりすることが含まれており、これらは、ストリーミングメディアを開始し、さもなければ制御するために必要になるものである。ＱｏＳセットアップ期間３０４には、保証ＱｏＳコネクションを確立するために必要になる、ＲＳＶＰコマンド／メッセージをやりとりすることが含まれている。
【００３７】セットアップ期間３０２と３０４がいつ終了するか（つまり、完了するか）に関しては、変動する可能性があることから、ストリーミングメディアをプレイするために選択できるオプションがいくつか用意されている。
【００３８】従って、例えば、セットアップ期間３０２と３０４が共に同時に終了する場合、あるいはＱｏＳセット期間３０２がメディアセットアップ期間３０２の終了前に完了する場合には、メディアデータは、メディアセットアップ期間３０２の完了時にストリーム化して、ＲＳＶＰ交渉経路（ＲＳＶＰ  ｎｅｇｏｔｉａｔｅｄｐａｔｈ）を利用して保証ＱｏＳで送ることができる。
【００３９】これに反して、
メディアセットアップ期間３０２がＱｏＳセットアップ期間３０４の完了前に終了する場合には
【００４０】このようなオプションが与えられていれば、ある種のアプリケーションは、おそらくは、
優先（ｐｒｅｆｅｒｒｅｄ）ＱｏＳフォーマットになっていなくても、ストリーム化メディアを可能な限り早くプレイさせる
【００４１】例として、
エンドユーザは、可能な限り早くストリーム化ビデオデータを受信／プレイすることを選択したが、最終的には、保証ＱｏＳを望んでいる
メディアセットアップ期間３０２の終了からＱｏＳセットアップ期間３０４の終了までに、約５秒間の待ちが生じたものと想定する
ビデオデータは、従来の「ベストエフォート（ｂｅｓｔ  ｅｆｆｏｒｔ）」コミュニケーションを使用してネットワーク１０６上でストリーミングを開始し
ＱｏＳセットアップ遅延期間３０４が終了し、ＲＳＶＰ交渉経路が確立されると、ストリーミングビデオは望みの品質になる
【００４２】上記の例では、セットアップ遅延期間３０２と３０４は、基本的にオーバラップしている。しかし、実装されるプロトコルに応じて、セットアップ遅延期間３０２と３０４を結合すると、エンドユーザが体験する遅延をさらに低減することが可能になる。
　
第４　引用例に記載された発明
　以上の記載によれば、引用例１には次の発明（以下、引用例１発明という。）が記載されている。
　
（４−１）引用例１の[019]には「システム１００において、サーバー１１０（例えば、標準的なＨＴＴＰサーバーのようなサーバー・コンピューター・システム）がマルチメディア・コンテンツをクライアント１２０（例えば、ラップトップまたはデスクトップ・コンピューターのようなクライアント・コンピューター・システム、あるいはＰＤＡまたは移動体電話機のような他のタイプのコンピューティング・デバイス）にネットワーク１３０（例えば、インターネット）を通じて供給する。」との記載があるから、引用例１には、サーバーがクライアントにマルチメディア・コンテンツをネットワークを通じて供給することに関する発明が開示されているといえる。
　上記供給に関して、[0022]には「種々のファイル配給プロトコル（例えば、ファイル転送プロトコル（ＦＴＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）、ＭＭＳ（Microsoft Media Services)等）を用いてマルチメディア・コンテンツを配給することができる。」とあるから、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）を用いて供給することも開示されている。
　上記マルチメディア・コンテンツは、引用例１の「マルチメディア・コンテンツの区分ストリーミングのためのシステム１００を一般化したブロック図を示す。インデックス化ファイルは、一般に、マルチメディア・プログラムのビデオを多数のストリーミング・セグメントに分割し、種々のビット・レートのビデオ・セグメントを表す多数の圧縮ビット・ストリームを収容する。」（[019]）、「ストリーミング・セグメント（自己完結ユニット）と呼ばれる時間チャンク(temporal chunk)に、プログラムを分割する。」（[023]）の記載によれば、時間により分割されたストリーミング・セグメントからなることが開示されているといえる。
　以上まとめると、引用例１には、サーバーがクライアントに、時間により分割されたストリーミング・セグメントからなるマルチメディア・コンテンツを、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）を用いてネットワークを通じて供給することに関する発明が開示されている。
　
（４−２）引用例１の[021]には「クライアントは、最初にプログラムのストリーミング・セグメントに利用可能な種々のビット・レートを記載したインデックス情報をサーバーから入手することによって、レート制御を実行することができる。」と記載されており、上記「プログラム」は、「マルチメディア・プログラムのビデオ」（[019]）であることは明らかであって、「マルチメディア・コンテンツ」といいかえることができるから、「クライアントは、最初に、マルチメディア・コンテンツのストリーミング・セグメントに利用可能な種々のビット・レートを記載したインデックス情報をサーバーから入手する」ことが開示されている。
　上記入手したビットレートに基づいて、以下（４−３）にあるように、ダウンロードすべき所望のストリーミング・セグメントを判断しているから、上記ビットレートは、マルチメディア・コンテンツのストリーミング・セグメントから所望のストリーミング・セグメントを判断するためのインデックス情報といえる。
　したがって、引用例１には「クライアントは、最初に、マルチメディア・コンテンツのストリーミング・セグメントから所望のストリーミング・セグメントを判断するためのインデックス情報をサーバーから入手する」ことが開示されている。
　
（４−３）引用例１の[021]、[023]の記載によれば、クライアントは、インデックス情報に基づいてどのストリーミング・セグメントをサーバーからダウンロードすればよいか判断し、ストリーミング・セグメント毎にマルチメディア・コンテンツをダウンロードすることが開示されている。
　
（４−４）まとめ
　以上によれば、
「サーバーがクライアントに、時間により分割されたストリーミング・セグメントからなるマルチメディア・コンテンツを、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）を用いてネットワークを通じて供給することに関する発明において、
　クライアントは、
　最初に、マルチメディア・コンテンツのストリーミング・セグメントから所望のストリーミング・セグメントを判断するためのインデックス情報をサーバーから入手し、
　インデックス情報に基づいてどのストリーミング・セグメントをサーバーからダウンロードすればよいか判断し、ストリーミング・セグメント毎にマルチメディア・コンテンツをダウンロードする」
　ことが開示されているといえ、上記「入手」、「ダウンロード」は、クライアントにおける処理のステップであるから、当該ステップを有するクライアントにおける方法の発明が開示されているといえる。
　してみると、引用例１発明として、以下のとおりのものを認定することができる。（（ａ）ないし（ｄ）は当審において付与し、以下「構成要件（ａ）」等として引用する。）
（ａ）サーバーがクライアントに、時間により分割されたストリーミング・セグメントからなるマルチメディア・コンテンツを、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）を用いてネットワークを通じて供給する際のクライアントにおける方法であって、
（ｂ）最初に、マルチメディア・コンテンツのストリーミング・セグメントから所望のストリーミング・セグメントを判断するためのインデックス情報をサーバーから入手するステップと、
（ｃ）インデックス情報に基づいてどのストリーミング・セグメントをサーバーからダウンロードすればよいか判断し、ストリーミング・セグメント毎にマルチメディア・コンテンツをダウンロードするステップとを有する、
（ｄ）方法。
　
第５　対比
　本願発明と引用例１発明とを対比する。
　
（５−１）本願発明の構成要件（Ａ）と引用例１発明の構成要件（ａ）とを対比する。
　引用例１発明の「マルチメディア・コンテンツ」は、[019]の記載によれば、ビデオストリームであるから、本願発明の「メディアストリーム」に相当する。
　そして、上記「マルチメディア・コンテンツ」は、時間により分割された（ストリーミング・）セグメントからなるから、連続した複数のストリーム要素（８４）に時間において分割されたメディアストリームといえることは明らかである。
　さらに、引用例１発明は、「マルチメディア・コンテンツを、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）を用いてネットワークを通じて供給する際のクライアントにおける方法」であって、当該コンテンツをネットワークを通じて供給することは、伝送することともいえ、上記伝送する際のクライアントにおける方法は、伝送を制御するためのメディアクライアントにおける方法ともいえるから、引用例１発明の構成要件（ａ）は、本願発明の構成要件（Ａ）と相違がない。
　
（５−２）本願発明の構成要件（Ｂ）と引用例１発明の構成要件（ｂ）とを対比する。
　引用例１発明における「インデックス情報」は、引用例１の[019]の「図１は、インデックス化ビデオ・ストリーム・ファイルに収容されているマルチメディア・コンテンツの区分ストリーミングのためのシステム１００を一般化したブロック図を示す。インデックス化ファイルは、一般に、マルチメディア・プログラムのビデオを多数のストリーミング・セグメントに分割し、種々のビット・レートのビデオ・セグメントを表す多数の圧縮ビット・ストリームを収容する。・・・システム１００では、サーバー１１０はプログラムをインデックス化ファイルに格納する。」の記載によれば、「インデックス化ビデオ・ストリーム・ファイルに収容されているマルチメディア・コンテンツ」のインデックス情報であることは明らかであり、マルチメディア・コンテンツのインデックス情報とは、「マルチメディア・プログラムのビデオを多数のストリーミング・セグメントに分割し、種々のビット・レートのビデオ・セグメントを表す多数の圧縮ビット・ストリーム」として収容した、インデックス化ファイルのインデックス情報であるから、ストリーミング・セグメントに分割したビデオストリームの各セグメントのインデックス情報である。
　すなわち、インデックス情報は、各セグメントのインデックス情報であって、各セグメントが格納されているところを特定する情報であるから、セグメントのメディアソースを示す、前記メディアストリームのメディア記述といえる。
　そして、最初に入手する上記インデックス情報は、複数のストリーム要素のうちの最初の要素のメディアソースも含むことは当然のことである。
　以上のことから、引用例１発明の構成要件（ｂ）は、本願発明の構成要件（Ｂ）に相当する。
　
（５−３）本願発明の構成要件（Ｃ）と引用例１発明の構成要件（ｃ）とを対比する。
　引用例１発明では「ストリーミング・セグメント毎にマルチメディア・コンテンツをダウンロード」しているから、当然、最初のセグメント（要素）を求めるリクエストを送信していることは明らかである。
　したがって、引用例１発明は、本願発明の構成要件（Ｃ）を有している。
　
（５−４）本願発明の構成要件（Ｄ）と引用例１発明とを対比する。
　引用例１発明は、セッション制御に関する特定事項を備えていることが特定されていないから、本願発明の構成要件（Ｄ）を有していない。
　
（５−５）本願発明の構成要件（Ｅ）と引用例１発明の構成要件（ｃ）、（ｄ）とを対比する。
　引用例１発明が、「前記最初の要素（９２）を求めるリクエストを送信するステップ」を有していることは、上記（５−３）で検討したとおりであり、したがって、「前記最初の要素（９２）を求めるリクエストを送信するステップ（３４）が実行される方法」である点で、本願発明と相違がない。
　もっとも、本願発明では、上記「前記最初の要素（９２）を求めるリクエストを送信するステップ（３４）が実行される」のは、「前記セッション制御手続きの結果を受信する前に実行される」のに対し、引用例１発明は、セッション制御に関する特定事項を有していないから、「前記セッション制御手続きの結果を受信する前に実行される」との特定事項を有していない点で相違する。
　
（５−６）まとめ（一致点・相違点）
　以上まとめると、本願発明と引用例１発明とは以下の一致点で一致し相違点で相違する。
　
（一致点）
　連続した複数のストリーム要素（８４）に時間において分割されたメディアストリームの伝送を制御するためのメディアクライアントにおける方法であって、
　前記複数のストリーム要素のうちの最初の要素（９２）のメディアソースを示す、前記メディアストリームのメディア記述（１００）を取得するステップ（３２）と、
　前記最初の要素（９２）を求めるリクエストを送信するステップ（３４）と、
　前記最初の要素（９２）を求めるリクエストを送信するステップ（３４）は実行されることを特徴とする方法。
　
（相違点）
相違点１
　本願発明は、「前記メディアストリームの伝送のためのセッション制御手続きを開始するステップ」を有しているのに対し、引用例１発明は、当該構成を有していない点。
　
相違点２
　本願発明「前記最初の要素（９２）を求めるリクエストを送信するステップ（３４）は、前記セッション制御手続きの結果を受信する前に実行される」のに対し、引用例１発明では、「前記最初の要素（９２）を求めるリクエストを送信するステップ（３４）は実行されるものの「前記セッション制御手続きの結果を受信する前に実行される」ことが特定されていない点。
　
第６　判断
　上記相違点について検討する。
　
（６−１）相違点１について
　引用例１発明において、メディアデータ（メディアストリーム）は「リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）」を用いて送信されている。
　ここで、「リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）」でビデオストリーム等を送信するときには、セッション制御手続きを行うことは、下記の周知文献にあるとおり普通の構成であり、引用例１発明を「リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）」で実現したときに、相違点１の構成を採用することは当業者にとって当たり前のことである。
　
周知文献１：特開２００９−１８２４１７号公報（【００１７】等参照）
周知文献２：特開２００９−２２５３３９号公報（【０００３】−【０００７】等参照）　
　
（６−２）相違点２について
　上記（６−１）で検討したように、引用例１発明では、メディアデータの送信をリアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）で行っているのであるから、セッション制御手続を開始するステップを有することは普通のことである。
　このとき、上記周知のセッション制御手続は、上記周知文献１、周知文献２にあるように、クライアントとサーバとの間で、セッションを確立するための制御であって、メディアデータの送信に先立って行われるものであり、例えば、「ストリーム送出用のリソースの確保」（周知文献１【００１７】）等が行われることもよく知られたことである。
　ここで、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）を用い、リソースの確保を行いメディアデータを送信する具体的な構成が開示されている引用例３には、セッション制御手続が行われた後、ストリーミングが開始される構成であると、「ストリーミングメディアセッションおよび／または通信されるメディアの効果性が低下する」から、「セッションスタートアップレイテンシを低減する」（【００３３】）ための構成として、以下の構成（【００３４】−【００４２】）が開示されている。
　
　『メディアセットアップ遅延期間３０２とＱｏＳセットアップ遅延期間３０４とをオーバーラップさせてメディアストリーミング環境を確立（セッションを確立）するとき、メディアセットアップ期間３０２がＱｏＳセットアップ期間３０４の完了前に終了する場合、優先（ｐｒｅｆｅｒｒｅｄ）ＱｏＳフォーマットになっていなくても、ストリーム化メディアを可能な限り早くプレイさせるために、ＱｏＳセットアップ遅延期間３０４が終了し、ＲＳＶＰ交渉経路が確立される以前に、ネットワーク１０６上でストリーミングを開始すること』
　
　上記「ＱｏＳセットアップ遅延期間３０４が終了し、ＲＳＶＰ交渉経路が確立される以前」とは、ＲＳＶＰ交渉経路が確立したことを示す結果の受信の前であるから、「セッション制御手続きの結果を受信する前」に相当する。
　すなわち、引用例３には、「セッション制御手続きの結果を受信する前」に、ストリーミングが開始される構成（最初の要素を求めるリクエストを送信するステップが含まれていることは明らかである。）が開示されているといえ、引用例１発明においても、セッション制御手続きの結果を受信した後に最初の要素を求めるリクエストを送信した場合、遅延が生じることは当然予測可能であるから、当該遅延を防止するため、引用例３に記載された事項を適用し、相違点２の構成を採用することは、当業者が容易になしえたことである。
　
　したがって、上記各相違点は、当業者が容易に想到し得たものと認められ、本願発明全体としてみても格別のものはなく、その作用効果も、上記各相違点に係る構成の採用に伴って当然に予測される程度のものにすぎず、格別顕著なものがあるとは認められない。
　
第７　むすび
　以上のとおり、本願発明は、引用例１、引用例３に記載された事項および本願出願前周知の事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、残る請求項１ないし請求項１２、請求項１４ないし請求項２４に係る発明について検討するまでもなく、本願は拒絶すべきものである。
　よって、結論のとおり審決する。