WO2013014880A1 - コンテンツ再生装置、コンテンツ再生方法、コンテンツ再生プログラム及びコンテンツ提供システム - Google Patents

Abstract

　本発明は、ネットワークを介してストリーミング配信される、複数の視聴形態が選択可能なコンテンツを再生する場合に、視聴形態が切り替えられることをユーザに提示することによりユーザの利便性を向上することができるコンテンツ再生装置を提供する。コンテンツ再生装置は、映像コンテンツについて選択可能な複数の視聴形態を示す制御情報をコンテンツ配信システムからネットワークを介して受信する受信手段と、複数の視聴形態を選択肢としてユーザに提示する提示手段と、選択肢から１つを選択するユーザ入力を受け付ける入力受付手段と、選択された視聴形態を示す情報をコンテンツ配信システムに送信することにより映像コンテンツのストリーム配信を要求する要求手段とを備える。

Description

コンテンツ再生装置、コンテンツ再生方法、コンテンツ再生プログラム及びコンテンツ提供システム

　本発明は、ネットワークを介してコンテンツをストリーミング受信し再生する技術に関し、特に、コンテンツ再生時の視聴形態の切り替えに関する。

　近年、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　Ｔｅｌｅ－Ｖｉｓｉｏｎ）による映像コンテンツのストリーミング配信が広く行われている。このストリーミング配信では、従来の２Ｄコンテンツに加えて、内容は同様であるが視聴形態の異なる３Ｄコンテンツが提供される場合も多くなっている。

　ここで、ＩＰＴＶでは、上述のような視聴形態の異なる複数のコンテンツを相互に対応付けせず、別個の独立したコンテンツとして扱うこととなっており、再生装置において、あるコンテンツについて複数の視聴形態（例えば２Ｄと３Ｄ）が存在するか否かの情報は得ていない（非特許文献１、非特許文献２参照）。

一般社団法人　ＩＰＴＶフォーラム、ＩＰＴＶ規定　ＶＯＤ仕様　ＩＰＴＶＦＪ　ＳＴＤ－０００２　１．２版、２０１２年４月１６日発行 デジタルテレビ情報化研究会、デジタルテレビ ネットワーク機能仕様　ストリーミング機能仕様書　コーデック編、１．２版、２０１０年１２月２１日発行

　ところで、再生装置を用いてコンテンツを視聴するユーザは、ある視聴形態でコンテンツの再生が行われている場合に、他の視聴形態への切り替えを望む場合があると考えられる。例えば、ユーザが、当初コンテンツを３Ｄメガネを用い３Ｄで視聴している場合において、３Ｄメガネを持たない他のユーザとともにそのコンテンツを２Ｄで視聴するため２Ｄへの切り替えを望む場合や、あるコンテンツを２Ｄで視聴している場合において、その迫力ある映像を３Ｄで視聴するのを望む場合などである。

　しかしながら、上述のように、再生装置においては、コンテンツについて複数の視聴形態が存在するか否かの情報は得ていないから、視聴形態が切り替えられることをユーザに提示し視聴形態の切り替えの機会を与えることはできないという問題がある。

　そこで、本発明は、係る問題に鑑みてなされたものであり、ネットワークを介してストリーミング配信される、複数の視聴形態が選択可能なコンテンツを再生する場合に、視聴形態が切り替えられることをユーザに提示し視聴形態の切り替えの機会を与えることによりユーザの利便性を向上することができるコンテンツ再生装置を提供することを目的とする。

　上記課題を解決するために本発明に係るコンテンツ再生装置は、ネットワークを介して接続するコンテンツ配信システムから、映像コンテンツをストリーム受信し再生するコンテンツ再生装置であって、映像コンテンツについて選択可能な複数の視聴形態を示す制御情報を前記コンテンツ配信システムから前記ネットワークを介して受信する受信手段と、前記複数の視聴形態を選択肢としてユーザに提示する提示手段と、前記選択肢から１つを選択するユーザ入力を受け付ける入力受付手段と、前記選択された視聴形態を示す情報を前記コンテンツ配信システムに送信することにより映像コンテンツのストリーム配信を要求する要求手段とを備える。

　上述の構成により、本発明に係るコンテンツ再生装置は、視聴形態が切り替えられることを予めユーザに提示して切り替えの機会を与えることができ、ユーザの利便性を向上することができる。

本発明の一実施形態に係るコンテンツ提供システムの構成を示す図 ポータルサーバの構成を示すブロック図 コンテンツ管理情報表の一例を示す図 ユーザ管理情報表の一例を示す図 再生制御情報サーバの構成を示すブロック図 再生制御情報の構成を示す図 再生制御情報の構成を示す図（図６の続き） 映像コンテンツサーバの構成を示すブロック図 再生装置の構成を示すブロック図 コンテンツが再生されるまでの全体動作の流れを示すフローチャート コンテンツ一覧文書作成処理の流れを示すフローチャート コンテンツ一覧からの再生コンテンツ選択処理の流れを示すフローチャート 視聴形態決定処理の流れを示すフローチャート コンテンツ視聴中断処理の流れを示すフローチャート 視聴形態選択画面の一例を示す図 本発明の変形例に係るａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素を示す図 本発明の変形例に係るａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素を示す図

＜１．概要＞
　図１は、本発明の一実施形態に係るコンテンツ提供システム１の構成を示す図である。

　コンテンツ提供システム１は、図１に示すように、コンテンツ、及びコンテンツの再生に必要な再生制御情報等を配信するコンテンツ配信システム２、コンテンツを受信し再生する再生装置３及び再生装置４がネットワーク５を介して接続して成る。

　コンテンツ配信システム２は、配信するコンテンツの一覧と、再生制御情報を取得するためのＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）とを提供するポータルサーバ１１、再生制御情報を配信する再生制御情報サーバ１２、コンテンツを配信する映像コンテンツサーバ１３を含んで構成される。なお、本実施形態では、ポータルサーバ、再生制御情報サーバ、及び映像コンテンツサーバを、説明の便宜上１つずつしか記載していないが、実際には１以上存在するものとする。

　コンテンツを受信するにあたり、再生装置３は、まず、ポータルサーバ１１に対し、コンテンツ提供システム１で配信対象となっているコンテンツの一覧表を送信するよう要求する。ポータルサーバ１１は、再生装置３に対し、コンテンツ一覧表を送信する。

　再生装置３は、コンテンツ一覧表を受信し、ディスプレイに表示することによりユーザに提示する。ユーザは、再生装置３に対し、再生を要望するコンテンツ（以下、「再生対象コンテンツ」という。）を選択する入力を行う。

　再生装置３は、再生対象コンテンツに対応する再生制御情報サーバ（本実施形態では、再生制御情報サーバ１２）にアクセスするためのＵＲＬをコンテンツ一覧表から読み出し、そのＵＲＬにアクセスして再生制御情報の送信を要求する。

　ここで、再生制御情報には、再生対象コンテンツについて選択可能な複数の視聴形態が記載されている。コンテンツの「視聴形態」とは、コンテンツの「視覚的な表現形態」をいう。また、「視聴」の語は、一般的には単なる「視」よりも限定的な語であるが、本明細書及び請求の範囲では、「視」のみの場合も含めており一般的な用法よりも広義に用いている。

　再生装置３は、再生制御情報を参照し、再生制御情報に記載されている視聴形態を選択肢として全てディスプレイに提示し、視聴形態の選択をユーザに促す。これにより、再生装置３のユーザは、再生対象コンテンツについて想定していた視聴形態に加え、これとは異なる他の視聴形態も選択できることを知ることができ、ユーザにとっての利便性が向上する。以下、本発明の一実施形態について、より詳細に説明する。
＜２．構成＞
＜２－１．ポータルサーバ１１＞
　ポータルサーバ１１は、コンテンツの配信を受ける際の入り口となるポータルサービスを提供するＷＥＢサーバであり、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）文書、ＢＭＬ（Ｂｒｏａｄｃａｓｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）文書等を供給する機能を有する。

　図２は、ポータルサーバ１１の構成を示すブロック図である。

　ポータルサーバ１１は、図２に示すように、通信処理部３１、データ処理部３２、及び記憶部３３を含んで構成される。また、ポータルサーバ１１は、プロセッサ及びメモリを含んで構成されており、データ処理部３２の機能は、メモリに記憶されているプログラムをプロセッサが実行することにより実現される。

　通信処理部３１は、通信用のＬＳＩで構成されており、ネットワーク５を介してデータを送受信する機能を有する。

　記憶部３３は、不揮発性メモリで構成され、コンテンツ配信システム２において配信するコンテンツに関する管理情報であるコンテンツ管理情報、及びユーザ管理情報を記憶する。

　データ処理部３２は、コンテンツ一覧文書送信機能、ユーザ管理情報記録機能を有する。

　ここで、コンテンツ一覧文書送信機能は、コンテンツ一覧送信要求を受け付けて、その応答としてコンテンツ一覧文書を配信する機能である。コンテンツ一覧送信要求は、コンテンツ管理情報及びユーザ管理情報を用いて生成される。

　また、ユーザ管理情報記録機能とは、再生装置３又は再生装置４のユーザ等に関する情報であるユーザ管理情報を記録、更新する機能である。
＜データ構造＞
　以下、コンテンツ管理情報、コンテンツ一覧文書及びユーザ管理情報のデータ構造について説明する。
＜コンテンツ管理情報＞
　コンテンツ管理情報は、コンテンツ配信システム２が配信するコンテンツについての管理情報であり、予め、記憶部３３に記憶されている。

　図３は、コンテンツ管理情報の一覧であるコンテンツ管理情報表の一例を示す図である。

　コンテンツ管理情報（コンテンツ管理情報表の行）のそれぞれが、１つのコンテンツに対応する。

　コンテンツ管理情報は、コンテンツ名、コンテンツＩＤ、視聴形態、再生制御情報ＵＲＬ、戻り先ＵＲＬから成る。

　コンテンツ名は、コンテンツの名称である。

　コンテンツＩＤは、コンテンツを識別する識別情報である。

　視聴形態は、コンテンツの受信側（再生装置３又は４）において、どのような視聴形態で視聴できるようにコンテンツを配信するかのデフォルト値を示す。受信側において２Ｄで視聴できるようコンテンツを配信する場合には「２Ｄ」と記載され、３Ｄで視聴できるようコンテンツを配信する場合には、「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」と記載される。

　再生制御情報ＵＲＬは、コンテンツを受信し再生するために必要な再生制御情報を提供しているリソースを指し示すＵＲＬである。

　戻り先ＵＲＬは、コンテンツの再生が終了した後に、再生装置３及び４が表示するＨＴＭＬ文書のＵＲＬを表すパラメータである。
＜ユーザ管理情報＞
　ユーザ管理情報は、コンテンツ配信システム２がコンテンツを配信するユーザに関する情報である。ユーザ管理情報は、コンテンツ配信業者とユーザとの間で、コンテンツの配信契約が締結された時など、コンテンツの配信に先立ち生成される。また、ユーザ管理情報は、データ処理部３２が、再生装置３及び４からコンテンツ再生終了通知を受信したときに、コンテンツ再生終了通知に含まれる情報を反映するために更新される。

　図４は、ユーザ管理情報の一覧であるユーザ管理情報表の一例を示す図である。

　ユーザ管理情報は、ユーザＩＤ、コンテンツＩＤ、デバイスＩＤ、最終視聴形態、及び視聴済秒数から成る。

　ユーザＩＤは、コンテンツの配信を希望するユーザを識別する情報である。ユーザＩＤは、コンテンツ配信業者により、コンテンツの配信契約締結時などに各ユーザに対して一意に割り当てられる。ユーザＩＤは、一例として契約者番号である。なお、１人のユーザが複数のデバイスを有している場合など、同一のユーザについて複数のユーザ管理情報が存在する場合もある。

　コンテンツＩＤは、コンテンツを識別する識別情報である。

　デバイスＩＤは、ユーザが用いる再生装置を一意に識別する識別情報である。デバイスＩＤは、コンテンツの配信契約が締結された時などにユーザの申請に応じてコンテンツ配信業者が各デバイスに一意に割り当てるものとする。

　最終視聴形態は、コンテンツがどの視聴形態で視聴されていたかを示す情報である。本実施形態では、最終視聴形態は、「２Ｄ」、「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」のいずれかである。但し、コンテンツが全く視聴されていない場合には、何も記載されない。

　視聴済秒数は、コンテンツが視聴中断前に先頭から何秒分視聴されたかを示す情報である。なお、コンテンツが全く視聴されていない場合には、視聴済秒数は０である。
＜コンテンツ一覧文書＞
　コンテンツ一覧文書は、ＨＴＭＬ文書であり、コンテンツ配信システム２において配信されるコンテンツ１つにつき、下記フォーマットのａタグ（以下、「コンテンツタグ」という。）が１つ記載されたものである。

　＜ａ　ｈｒｅｆ＝　ＭｅｔａＦｉｌｅＵＲＬ？Ｒｅｔｕｒｎ＝ＲｅｔｕｒｎＵＲＬ［＆ＰｌａｙＰｏｓ＝ＰｌａｙＰｏｓｉｔｉｏｎ］＆ＰｌａｙＭｏｄｅ＝２Ｄ３Ｄ［＆ＬＩＤ＝ＬｉｃｅｎｓｅＩＤ］＞ＮＡＭＥ＜／ａ＞
　ここで、ａタグのアンカーテキスト中のＮＡＭＥには、コンテンツ名が記載される。具体的には、ＮＡＭＥには、コンテンツ管理情報中のコンテンツ名が記載される。

　ここで、ＭｅｔａＦｉｌｅＵＲＬは、コンテンツを受信するために必要な再生制御情報を提供しているリソースを指し示すＵＲＬである。ＭｅｔａＦｉｌｅＵＲＬには、具体的には、コンテンツ管理情報中の再生制御情報ＵＲＬが記載される。

　Ｒｅｔｕｒｎは、コンテンツの再生が終了した後に表示するＨＴＭＬ文書のＵＲＬを表すパラメータを示し、ＲｅｔｕｒｎＵＲＬにそのパラメータ値が記載される。ＲｅｔｕｒｎＵＲＬには、具体的には、コンテンツ管理情報中の戻り先ＵＲＬが記載される。

　ＰｌａｙＰｏｓは、コンテンツにおける、再生を開始する位置を表すパラメータを示し、ＰｌａｙＰｏｓｉｔｉｏｎに、そのパラメータ値として、コンテンツの先頭からの秒数が記載される。例えば、コンテンツの視聴が中断された場合、ＰｌａｙＰｏｓｉｔｉｏｎには、ユーザ管理情報中の視聴済秒数が記載される。［］で囲んだパラメータは、省略可能であることを表す。上述のコンテンツタグにおいては、コンテンツを先頭から再生する場合に、ＰｌａｙＰｏｓは省略される。

　ＰｌａｙＭｏｄｅは、コンテンツの視聴形態を表すパラメータであり、２Ｄ３Ｄに、そのパラメータ値として、原則、コンテンツ管理情報中の視聴形態が記載される。但し、ユーザ管理情報中に、コンテンツ管理情報におけるコンテンツＩＤと同じコンテンツＩＤが記録され、かつ、そのコンテンツＩＤに対応する最終視聴形態が記録されている場合には、コンテンツ管理情報中の視聴形態に代え、ユーザ管理情報中の最終視聴形態をＰｌａｙＭｏｄｅに記載する。

　ＬＩＤは、映像コンテンツを再生するときに使用するライセンスのＩＤを表すパラメータである。ＬｉｃｅｎｓｅＩＤにそのＩＤが記載される。ＬＩＤは、課金等に用いられるＩＤである。本実施形態では、課金に関しては説明しない。
＜２－２．再生制御情報サーバ１２＞
　再生制御情報サーバ１２は、要求された再生制御メタファイルを送信するサーバである。

　図５は、再生制御情報サーバ１２の構成を示すブロック図である。

　再生制御情報サーバ１２は、図５に示すように、通信処理部５１、データ処理部５２、及び記憶部５３を含んで構成される。再生制御情報サーバ１２は、プロセッサ及びメモリを含んで構成されており、データ処理部５２の機能は、メモリに記憶されているプログラムをプロセッサが実行することにより実現される。

　通信処理部５１は、通信用のＬＳＩで構成されており、ネットワーク５を介してデータを送受信する機能を有する。

　記憶部５３は、不揮発性メモリで構成され、コンテンツ配信システム２における配信対象であるコンテンツそれぞれについての再生制御情報を記憶する。各再生制御情報を入手するためにアクセスすべきＵＲＬは、前述のポータルサーバ１１が送信するコンテンツ一覧文書中にＭｅｔａＦｉｌｅＵＲＬとして記載されている。

　データ処理部５２は、前述のコンテンツ一覧文書に記載されたＭｅｔａＦｉｌｅＵＲＬを用いて送信要求された再生制御情報を、送信要求を行った装置に送信する機能を有する。再生制御情報を送信する場合、データ処理部５２は、再生制御情報、ＬＬＩ（Ｌｉｃｅｎｓｅ　Ｌｉｎｋ　Ｉｎｆｏｒｍａｔｉｏｎ）、ＮＣＩ（Ｎｅｔｗｏｒｋ　ｃｏｎｔｅｎｔ　Ｃｏｎｔｒｏｌ　Ｉｎｆｏｒｍａｔｉｏｎ）を含めて再生制御メタファイルの形で送信するものとする。
＜データ構造＞
　図６及び図７は、再生制御情報の構成を示す図である。図７は、図６の続きである。

　再生制御情報は、「デジタルテレビ情報化研究会、デジタルテレビ ネットワーク機能仕様　ストリーミング機能仕様書　コーデック編、１．２版、２０１０年１２月２１日発行」（非特許文献２）で示される再生制御メタファイルのうちＥＲＩ（Ｅｎｔｒｙ　Ｒｅｓｏｕｒｃｅ　Ｉｎｆｏｒｍａｔｉｏｎ）を拡張したものである。よって、特段の説明をする場合を除いてＥＲＩの各項目の説明は省略する。

　本実施形態では、再生制御情報として、ＥＲＩに対しａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素、ｄｅｆａｕｌｔ＿ｐｌａｙ＿ｍｏｄｅ要素を追加する拡張を行っている。

　ａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素は、コンテンツについて選択可能な視聴形態を全て列挙したものである。ａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素には、「２Ｄ」、「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」の一方又は双方が記載されることになる。「２Ｄ」は、コンテンツが２Ｄ映像として視聴可能であることを示す。「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」は、ＭＶＣ方式の３Ｄ映像として視聴可能であることを示す。

　再生制御情報を受信した再生装置は、このａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素を参照することで、選択可能な視聴形態をユーザに予め提示することができる。

　なお、上述のＭＶＣ（Ｍｕｌｔｉ　Ｖｉｅｗ　Ｃｏｄｉｎｇ）方式は、マルチビュー映像を、1個のベースビューと、1個以上のディペンデントビューとして符号化する方式である。ＭＶＣ方式では、ディペンデントビューは、ベースビューに含まれるフレームを参照(ビュー間予測)して符号化されるので、それぞれのビューを独立して扱うよりも効率的な圧縮が可能となる。

　ｄｅｆａｕｌｔ＿ｐｌａｙ＿ｍｏｄｅ要素は、この再生制御情報を受信した装置が、２Ｄ映像と３Ｄ映像のいずれをデフォルトとして選択するかを指定する情報である。このｄｅｆａｕｌｔ＿ｐｌａｙ＿ｍｏｄｅをＥＲＩに含めるか否かはオプションであり、本実施形態では使用しない。変形例として後述する。

　なお、コンテンツ本体の参照先は、ＥＲＩのｓｔａｒｔ要素に、ＡＶリソースの要求先ＵＲＬをスキームも含め１０２４バイト以下の文字列で記載される。スキームとしては、ｒｔｓｐ：／／、ｈｔｔｐ：／／のいずれかとなる。具体的には、ｈｔｔｐ：／／ｖｉｄｅｏｓｅｒｖｅｒ．ｃｏｍ／ＡＶＤａｔａ／０００１．ｍ２ｔｓのように記載される。
＜２－３．映像コンテンツサーバ１３＞
　映像コンテンツサーバ１３は、映像コンテンツをストリーム配信するサーバである。

　図８は、映像コンテンツサーバ１３の構成を示すブロック図である。

　映像コンテンツサーバ１３は、図８に示すように、通信処理部７１、リクエスト処理部７２、記憶部７３及びＶＯＤ（Ｖｉｄｅｏ　Ｏｎ　Ｄｅｍａｎｄ）配信制御部７４を含んで構成される。映像コンテンツサーバ１３は、プロセッサ及びメモリを含んで構成されており、リクエスト処理部７２及びＶＯＤ配信制御部７４の機能は、メモリに記憶されているプログラムをプロセッサが実行することにより実現される。

　通信処理部７１は、通信用のＬＳＩで構成されており、ネットワーク５を介してデータを送受信する機能を有する。

　記憶部７３は、不揮発性メモリで構成され、配信するコンテンツ本体を記憶している。

　リクエスト処理部７２は、コンテンツ配信要求を受け付けて、要求されたコンテンツの配信をＶＯＤ配信制御部７４に指示する機能（以下、「配信指示機能」という。）を有する。

　コンテンツ配信要求は、ＨＴＴＰ－ＧＥＴリクエストにより成される。なお、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）については、ＲＦＣ２６１６に定義されている。ＨＴＴＰ－ＧＥＴリクエストは、一例として以下のような形式で行われる。
「
　ＧＥＴ　ｈｔｔｐ：／／ｖｉｄｅｏｓｅｒｖｅｒ．ｃｏｍ／ＡＶＤａｔａ／０００１．ｍ２ｔｓ　ＨＴＴＰ／１．１
　Ｈｏｓｔ：　ｖｉｄｅｏｓｅｒｖｅｒ．ｃｏｍ
　Ｄａｔｅ：　Ｗｅｄ　Ｊｕｌ　２０　１５：００：００　２０１１　ＧＭＴ
　Ｕｓｅｒ－Ａｇｅｎｔ：　ＩＰ　Ｂｒｏａｄｃａｓｔ　Ｒｅｃｅｉｖｅｒ
　Ｃｏｎｎｅｃｔｉｏｎ：　Ｋｅｅｐ－Ａｌｉｖｅ
　Ｘ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅ：　３Ｄ
　Ｘ－ＴｉｍｅＳｅｅｋＲａｎｇｅ：ｎｐｔ－ｔｉｍｅ＝００：６０：００－
」
　ＨＴＴＰ－ＧＥＴリクエストのＵＲＬには、コンテンツを取得するためのＵＲＬが記載される。上述の例では、ｈｔｔｐ：／／ｖｉｄｅｏｓｅｒｖｅｒ．ｃｏｍ／ＡＶＤａｔａ／０００１．ｍ２ｔｓがコンテンツを取得するためのＵＲＬに該当する。

　Ｈｏｓｔには、コンテンツを提供するサーバ（本実施形態では、映像コンテンツサーバ１３）のホスト名が記載される。

　Ｄａｔｅには、ＨＴＴＰ－ＧＥＴリクエストが生成された日時が記載される。

　Ｕｓｅｒ－Ａｇｅｎｔには、ブラウザの情報をサーバに伝えるための情報が記載される。フォーマットについて特に規定はなく、本実施形態では、「ＩＰ　Ｂｒｏａｄｃａｓｔ　Ｒｅｃｅｉｖｅｒ」を用いる。

　Ｃｏｎｎｅｃｔｉｏｎには、このＨＴＴＰリクエストに対するレスポンスが終了した後の、ＴＣＰレイヤの接続に関する情報が記載される。ＴＣＰレイヤの接続維持を要求する場合には、Ｋｅｅｐ－Ａｌｉｖｅ記載し、ＴＣＰレイヤの接続切断を要求する場合には、Ｃｌｏｓｅを記載する。

　Ｘ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅには、再生装置側が要求する、コンテンツについての視聴形態が記載される。

　Ｘ－ＴｉｍｅＳｅｅｋＲａｎｇｅには、該コンテンツにおける、送信を要求する先頭位置を指定する。これは、コンテンツの先頭からの時間によって指定される。Ｘ－ＴｉｍｅＳｅｅｋＲａｎｇｅで先頭からの視聴済時間を指定することにより、前回の視聴を中断した箇所の続きから視聴することが可能となる。映像コンテンツサーバ１３は、Ｘ－ＴｉｍｅＳｅｅｋＲａｎｇｅで指定された位置以降の部分を送信することになる。詳細は、「デジタルテレビ情報化研究会、デジタルテレビ ネットワーク機能仕様　ストリーミング機能仕様書　プロトコル編、１．２版、２０１０年１２月２１日発行」に規定されている。

　以上のようなＨＴＴＰ―ＧＥＴリクエストに対し、映像コンテンツサーバ１３は、一例として下記のようなレスポンスを返すことになる。
「
　ＨＴＴＰ／１．１　２００　ＯＫ
　Ｄａｔｅ：　Ｗｅｄ　Ｊｕｌ　２０　１５：００：０１　２０１１　ＧＭＴ
　Ｓｅｒｖｅｒ：　Ｖｉｄｅｏ　Ｓｔｒｅａｍｉｎｇ　Ｓｅｒｖｅｒ
　Ｃｏｎｔｅｎｔ－Ｔｙｐｅ：　ｖｉｄｅｏ／ｍｐｅｇ
　Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ：　５４５２００００００ｂｙｔｅ
　Ｘ－Ａｖａｉｌａｂｌｅ－Ｐｌａｙ－Ｍｏｄｅ：　２Ｄ３Ｄ
　Ｘ－ＴｉｍｅＳｅｅｋＲａｎｇｅ：　ｎｐｔ－ｔｉｍｅ＝００：６０：００－　ｂｙｔｅｓ＝５４５２００００００－１０９３９９９９９９／１０９４００００００
」
　ここで、上述のリクエスト処理部７２による配信指示機能は、下記手順により実現される。

　リクエスト処理部７２は、コンテンツ配信要求を受け付けた場合、コンテンツ配信要求から、コンテンツ名、視聴形態、視聴済時間を抽出する。そして、リクエスト処理部７２は、コンテンツ名、視聴形態、視聴済時間を通知することにより、要求されたコンテンツの配信をＶＯＤ配信制御部７４に指示する。

　次に、ＶＯＤ配信制御部７４について説明する。

　ＶＯＤ配信制御部７４は、リクエスト処理部７２から配信するよう指示されたコンテンツをストリーミング配信する機能を有する。

　ＶＯＤ配信制御部７４は、通知されたコンテンツ名のコンテンツにおける、通知された視聴済時間に相当する箇所に継続する部分を、コンテンツ配信要求を送信してきた装置に対し配信する。また、通知された視聴形態が「２Ｄ」の場合、２Ｄ映像のコンテンツを送信し、通知された視聴形態が「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」の場合、３Ｄ映像のコンテンツを配信する。ここで、コンテンツがＭＶＣ方式で符号化されている場合、通知された視聴形態が「２Ｄ」であれば、ディペンデントビューを含まず、ベースビューだけを含む２Ｄ映像として配信する。また、通知された視聴形態が「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」であれば、ベースビューとディペンデントビューの双方を含むＭＶＣ映像（３Ｄ映像）として送信する。
＜２－４．再生装置３＞
　再生装置３は、コンテンツをストリーム受信し、再生する装置である。

　図９は、再生装置３の構成を示すブロック図である。

　再生装置３は、図９に示すように、通信処理部８１、デマルチプレクサ８２、音声デコーダ８３、映像デコーダ８４、字幕デコーダ８５、表示処理部８６、ＶＯＤ再生制御部８７、ブラウザ処理部８８、記憶部８９、及びユーザ操作部９０を含んで構成される。再生装置３は、プロセッサ及びメモリを含んで構成されており、ＶＯＤ再生制御部８７及びブラウザ処理部８８の各機能は、メモリに記憶されているプログラムをプロセッサが実行することにより実現される。

　通信処理部８１は、通信用のＬＳＩで構成されており、ネットワーク５を介してデータを送受信する機能を有する。

　デマルチプレクサ８２は、デマルチプレクサＬＳＩで構成されており、多重化されているＭＰＥＧ－２　ＴＳを受信して、映像、音声、字幕、ＰＳＩ／ＳＩ等のパケットに分離する機能を有する。デマルチプレクサ８２は、分離した音声パケットを音声デコーダ８３に出力し、映像パケットを映像デコーダ８４に出力し、字幕パケットを字幕デコーダ８５に出力し、ＰＳＩ／ＳＩパケットをＶＯＤ再生制御部８７に出力する。

　音声デコーダ８３は、ＡＶ信号処理ＬＳＩで実現されており、音声パケットを復号することにより音声信号を得て、外部に出力する機能を有する。

　映像デコーダ８４は、上述のＡＶ信号処理ＬＳＩで実現されており、ＶＯＤ再生制御部８７からコンテンツの再生に用いる視聴形態の通知を受け、通知された視聴形態で映像を表示できるよう、映像パケットを復号することにより映像信号を得て、表示処理部８６に出力する機能を有する。映像パケットが、ＭＶＣ方式に基づき符号化されている場合において、通知された視聴形態が「２Ｄ」の場合、ディペンデントビューを無視して、ベースビューのみを復号し、２Ｄ映像を表す映像信号を生成し、表示処理部８６に出力する。また、通知された視聴形態が「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」の場合、映像パケットからベースビューのフレームを復号したあと、ディペンデントビューのフレームを復号し、それぞれを左右の映像として交互に表示させる映像信号を生成し表示処理部８６に出力する。

　字幕デコーダ８５は、上述のＡＶ信号処理ＬＳＩで実現されており、字幕パケットを復号することにより字幕信号を得て、表示処理部８６に出力する機能を有する。

　表示処理部８６は、上述のＡＶ信号処理ＬＳＩで実現されており、映像デコーダ８４から得た映像信号と、字幕デコーダ８５から得た字幕信号とを重ね合わせて表示画像を形成し、ディスプレイなど外部に出力する機能を有する。また、ブラウザ処理部８８により、ＨＴＭＬ文書、ＢＭＬ文書に基づき形成されるページ画像などを、単独で、又は、映像、字幕と重ね合わせて表示画像を形成し、ディスプレイなど外部に出力する機能を有する。

　ＶＯＤ再生制御部８７は、コンテンツの再生制御を行う機能を有する。再生制御は、主に、再生開始制御と再生中断中止制御とから成る。

　まず、再生開始制御について説明する。

　ＶＯＤ再生制御部８７は、ブラウザ処理部８８に対しユーザ指示によって再生が指示された再生対象コンテンツについて再生を開始する。具体的には、ＶＯＤ再生制御部８７は、映像コンテンツサーバ１３から送信される再生対象コンテンツを受信し再生するために、音声デコーダ８３に音声パケットの復号を指示し、映像デコーダ８４に、再生に用いる視聴形態を通知し、映像パケットの復号を指示し、字幕デコーダ８５に対し、字幕パケットの復号を指示する。

　次に、再生中断中止制御について説明する。

　ＶＯＤ再生制御部８７は、ユーザ操作部９０から、コンテンツ再生中断指示を受け取ると、音声デコーダ８３に音声パケットの復号停止を指示し、映像デコーダ８４に映像パケットの復号停止を指示し、字幕デコーダ８５に対し、字幕パケットの復号停止を指示する。このとき、ＶＯＤ再生制御部８７は、このコンテンツに関する視聴済秒数を記録しておき、ブラウザ処理部８８に通知する。そして、ＶＯＤ再生制御部８７は、通信処理部８１に対し、映像コンテンツサーバ１３とのＴＣＰコネクションの切断を指示する。

　ブラウザ処理部８８は、サーバから取得したＨＴＭＬ文書又はＢＭＬ文書を解釈し、記載されているスクリプトを実行し、提示を行う。ブラウザ処理部８８は、コンテンツ一覧表示機能（図１２のＳ２０２）、再生対象コンテンツ情報記憶制御機能（図１２のＳ２０４）、再生位置選択画面表示機能（図１２のＳ２０６）、再生制御情報送信要求機能（図１０のＳ１７）、視聴形態決定機能（図１３）、及びコンテンツ再生終了通知送信機能（図１４）を有する。

　コンテンツ一覧表示機能は、ポータルサーバ１１からＨＴＭＬ文書もしくはＢＭＬ文書であるコンテンツ一覧文書を取得し、ＨＴＭＬもしくはＢＭＬに従って表示するものである。この場合、コンテンツ一覧文書に含まれる各コンテンツタグのコンテンツ名がユーザに提示される。

　再生対象コンテンツ情報記憶制御機能は、再生対象コンテンツ情報の記憶、更新についての制御を行う機能である。具体的には、ブラウザ処理部８８は、コンテンツ一覧文書における、再生対象コンテンツについてのコンテンツタグから、ＭｅｔａＦｉｌｅＵＲＬ、ＲｅｔｕｒｎＵＲＬ、ＰｌａｙＭｏｄｅ、コンテンツ名を抽出し、これらを再生対象コンテンツ情報として記憶部８９に記憶させる。再生対象コンテンツ情報における、ＭｅｔａＦｉｌｅＵＲＬなど各要素の意味は、コンテンツ一覧文書のコンテンツタグにおけるものと同じである。

　再生位置選択画面表示機能は、再生コンテンツについて、先頭から再生するか、レジューム再生（視聴中断位置から再生）するかを選択するための画面である再生位置選択画面を表示するよう指示する機能である。

　再生制御情報送信要求機能は、再生対象コンテンツの再生制御情報を取得するため、再生対象コンテンツ情報中のＭｅｔａＦｉｌｅＵＲＬを読み出し、再生制御情報送信要求を行う機能である。

　視聴形態決定機能は、再生対象コンテンツについて実行可能な視聴形態をディスプレイに表示し、ユーザに選択させることにより、視聴形態を決定する機能である。

　コンテンツ再生終了通知送信機能は、映像コンテンツの再生を中断、或いは中止する際に、コンテンツ再生終了通知を、コンテンツ再生終了通知の内容をＲｅｔｕｒｎＵＲＬ（本実施形態では、ポータルサーバ１１上のリソースである。）へのリクエストに含めて送信する機能である。

　コンテンツ再生終了通知は、具体的には、以下のように記述したＵＲＬを記載したＨＴＴＰリクエストメッセージを送信することで行う。

　ＲｅｔｕｒｎＵＲＬ？Ｓｔａｔｕｓ＝ＳｔａｔｕｓＣｏｄｅ［＆ＳｔｏｐＰｏｓ＝ＳｔｏｐＰｏｓｉｔｉｏｎ］＆ＰｌａｙＭｏｄｅ＝２Ｄ３Ｄ
　ここで、ＲｅｔｕｒｎＵＲＬには、再生対象コンテンツ情報のＲｅｔｕｒｎＵＲＬを記載する。

　また、Ｓｔａｔｕｓは、再生したプレーヤの終了状態を表すものであり、０の場合は正常終了を表し、－２以下の場合はエラーを表す。詳細は、「デジタルテレビ情報化研究会、デジタルテレビ ネットワーク機能仕様　ストリーミング機能仕様書　ブラウザ編、１．２版、２０１０年１２月２１日発行」に規定されている。

　ＳｔｏｐＰｏｓは、再生を中断した場合に、その停止位置を表すパラメータであり、ＳｔｏｐＰｏｓｉｔｉｏｎに、そのパラメータ値として、ＶＯＤ再生制御部８７から通知される視聴済秒数を記載する。

　ＰｌａｙＭｏｄｅは、映像コンテンツを再生していた視聴形態を表すパラメータである。２Ｄ３Ｄに、そのパラメータ値として、２Ｄ映像として再生していた場合「２Ｄ」を、３Ｄ映像として再生していた場合「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」を記載する。

　コンテンツ再生終了通知には、上述のＨＴＴＰリクエストメッセージとともに、ユーザＩＤ、デバイスＩＤを含めるものとする。

　ブラウザ処理部８８は、このコンテンツ再生終了通知をポータルサーバ１１に送信する。

　記憶部８９は、不揮発性メモリで構成され、再生対象コンテンツ情報を記憶する。

　また、再生装置３のユーザのユーザＩＤ（本実施形態ではＵ０１）、再生装置３に割り振られているデバイスＩＤ（本実施形態では、Ｄ０１）を記憶している。

　ユーザ操作部９０は、キーパッド、リモコン等で構成され、ユーザがキーパッド、リモコン等を操作することにより入力した指示（以下、「ユーザ指示」という。）を、ＶＯＤ再生制御部８７、ブラウザ処理部８８に通知する。

　なお、再生装置４については、構成は再生装置３と同様であるので説明は省略する。但し、再生装置４の記憶部８９に記憶されているユーザＩＤはＵ０１とし、デバイスＩＤはＤ０２とする。
＜３．動作＞
＜３－１．全体動作＞
　以上のように構成されたコンテンツ提供システム１において、再生装置３によりコンテンツが再生されるまでの全体動作について説明する。

　図１０は、コンテンツが再生されるまでの全体動作の流れを示すフローチャートである。

　まず、再生装置３のユーザは、再生装置３のユーザ操作部９０を用いて、コンテンツ一覧表示要求を入力する（Ｓ１１）。ユーザ操作部９０は、コンテンツ一覧表示要求を受け付け、コンテンツ一覧表示要求をブラウザ処理部８８に通知する。

　ブラウザ処理部８８は、コンテンツ一覧送信要求をポータルサーバ１１に対し送信する（Ｓ１２）。なお、再生装置３における他の装置との通信は、全て通信処理部８１を介している。以下では、記載簡略化のため通信についての「通信処理部８１を介し」の記載は省略する場合がある。他の装置についても同様である。

　ポータルサーバ１１において、通信処理部３１は、コンテンツ一覧送信要求を受信し、データ処理部３２に出力する。データ処理部３２は、コンテンツ一覧文書作成処理を行う（Ｓ１３）。この処理の詳細は、後述の図１１に示している。

　データ処理部３２は、生成したコンテンツ一覧文書を再生装置３に送信する（Ｓ１４）。

　再生装置３は、コンテンツ一覧文書を受信し、コンテンツ一覧からの再生コンテンツの選択処理を行う（Ｓ１５）。この処理の詳細は、後述の図１２に示している。

　再生装置３において、ブラウザ処理部８８は、選択されたコンテンツの再生制御情報を取得するためのＵＲＬとして、再生対象コンテンツ情報中のＭｅｔａＦｉｌｅＵＲＬを読み出す（Ｓ１６）。ブラウザ処理部８８は、通信処理部８１を用い、読み出したＵＲＬ（本実施形態では、再生制御情報サーバ１２上のリソースを指す）に対する再生制御情報送信要求を行う（Ｓ１７）。

　再生制御情報サーバ１２は、再生制御情報を再生装置３に送信する（Ｓ１８）。

　再生制御情報を受信した再生装置３は、視聴形態決定処理を行う（Ｓ１９）。

　この処理の詳細は、図１３に示している。

　再生装置３におけるブラウザ処理部８８は、通信処理部８１を用いて、映像データ送信要求を行うため映像コンテンツサーバ１３に対し、ＨＴＴＰ－ＧＥＴリクエストを送信する（Ｓ２０）。

　映像コンテンツサーバ１３は、ＨＴＴＰ－ＧＥＴリクエストで要求されたコンテンツを、ＨＴＴＰ－ＧＥＴリクエストの送信元である再生装置３に送信する（Ｓ２１）。

　ここで、映像コンテンツサーバ１３は、コンテンツを、ＨＴＴＰ－ＧＥＴリクエストのＰｌａｙ＿ｍｏｄｅで視聴できる態様で送信する。また、ＨＴＴＰ－ＧＥＴリクエストにＸ－ＴｉｍｅＳｅｅｋＲａｎｇｅヘッダがあったときには、コンテンツにおけるＸ－ＴｉｍｅＳｅｅｋＲａｎｇｅヘッダで指定された視聴位置から再生装置３に送信する。

　再生装置３のＶＯＤ再生制御部８７は、映像コンテンツサーバ１３から送信されるコンテンツを受信し再生するため、再生開始制御として、音声デコーダ８３に音声パケットの復号を指示し、映像デコーダ８４に映像パケットの復号を指示し、字幕デコーダ８５に対し、字幕パケットの復号を指示する。再生装置３において、音声デコーダ８３が音声パケットを復号し、映像デコーダ８４が映像パケットを復号し、字幕デコーダ８５は、字幕パケットが復号することにより、映像コンテンツサーバ１３から送信されるコンテンツを受信しながら再生するストリーミング再生を行う（Ｓ２２）。
＜３－２．コンテンツ一覧文書作成処理＞
　図１０のＳ１３に相当する、コンテンツ一覧文書作成処理について説明する。

　図１１は、コンテンツ一覧文書作成処理の流れを示すフローチャートである。

　図１０のＳ１２において、ポータルサーバ１１のデータ処理部３２は、再生装置３から、コンテンツ一覧送信要求を取得している。コンテンツ一覧送信要求には、要求元のユーザＩＤと、デバイスＩＤとが含まれている。

　データ処理部３２は、記憶部３３から、コンテンツ一覧送信要求に含まれていたユーザＩＤと一致するユーザＩＤのユーザ管理情報を読み出す（Ｓ１０１）。

　また、データ処理部３２は、未だ読み出していないコンテンツ管理情報が有るか否か判断し（Ｓ１０２）、読み出していないコンテンツ管理情報が無い場合（Ｓ１０２でＮＯ）、処理を終了する。

　読み出していないコンテンツ管理情報あった場合（Ｓ１０２でＹＥＳ）、そのコンテンツ管理情報を読み出す（Ｓ１０３）。

　そして、読み出したコンテンツ管理情報中のコンテンツＩＤに一致するコンテンツＩＤが、ユーザ管理情報中に記録されているか否か判断する（Ｓ１０４）。

　一致するものがある場合（Ｓ１０４でＹＥＳ）、そのユーザ管理情報における視聴済秒数が０か否か判断する（Ｓ１０５）。視聴済秒数が０で無い場合（Ｓ１０５でＮＯ）、コンテンツタグにＰｌａｙＰｏｓｉｔｉｏｎを追加し、値として視聴済秒数を設定する（Ｓ１０６）。視聴済秒数が０の場合（Ｓ１０５でＹＥＳ）、コンテンツタグにＰｌａｙＰｏｓｉｔｉｏｎは使用しない。

　ここで、Ｓ１０４～Ｓ１０６について補足説明する。Ｓ１０４～Ｓ１０６では、デバイスＩＤについてチェックを行っていない。よって、仮に、ユーザ管理情報中のデバイスＩＤが、コンテンツ一覧送信要求に含まれるデバイスＩＤとは異なっていたとしても、（ａ）読み出したコンテンツ管理情報のコンテンツＩＤと、同じコンテンツＩＤを有し、かつ（ｂ）コンテンツ一覧送信要求に含まれるユーザＩＤと、同じユーザＩＤを有する場合には、そのユーザ管理情報中の視聴済秒数が、コンテンツタグのＰｌａｙＰｏｓｉｔｉｏｎに設定されることになる。

　具体例として、デバイスＩＤがＤ０１の再生装置３により、コンテンツＡが視聴され、その視聴が中断された場合を想定する。その視聴が中断された後に、同じユーザが所有するデバイスＩＤがＤ０２の再生装置４によりコンテンツ一覧文書が要求されるとする。この場合、再生装置４が取得するコンテンツ一覧文書において、コンテンツＡについてのコンテンツタグのＰｌａｙＰｏｓｉｔｉｏｎには、再生装置４とはデバイスＩＤが異なるものの同じユーザが所有する再生装置３によって視聴された視聴済秒数が設定されることになる。以上で補足説明を終え、フローチャートの説明に戻る。

　Ｓ１０７では、データ処理部３２は、コンテンツタグの２Ｄ３Ｄに、ユーザ管理情報における最終視聴形態を設定し（Ｓ１０７）、Ｓ１０９に進む。

　一方、コンテンツ管理情報中のコンテンツＩＤに一致するコンテンツＩＤが、ユーザ管理情報中に記録されていない場合（Ｓ１０４でＮＯ）、データ処理部３２は、コンテンツタグの２Ｄ３Ｄに、読み出したコンテンツ管理情報中の視聴形態を設定し（Ｓ１０８）、Ｓ１０９に進む。

　Ｓ１０９では、コンテンツタグのＮＡＭＥに、読み出したコンテンツ管理情報中のコンテンツ名を設定する（Ｓ１０９）。

　そして、コンテンツタグのＭｅｔａＦｉｌｅＵＲＬに、読み出したコンテンツ管理情報中の再生制御情報ＵＲＬを設定する（Ｓ１１１）。そして、コンテンツタグのＲｅｔｕｒｎＵＲＬに、読み出したコンテンツ管理情報中の戻り先ＵＲＬを設定する（Ｓ１１２）。

　そして、生成したコンテンツタグを、コンテンツ一覧文書に追加し（Ｓ１１３）、Ｓ１０２に進む。
＜３－３．コンテンツ一覧からの再生コンテンツ選択処理＞
　図１０のＳ１５に相当する、コンテンツ一覧からの再生コンテンツ選択処理について説明する。

　図１２は、コンテンツ一覧からの再生コンテンツ選択処理の流れを示すフローチャートである。

　再生装置３における通信処理部８１は、ポータルサーバ１１からコンテンツ一覧文書を取得し、ブラウザ処理部８８に転送する。

　ブラウザ処理部８８は、ポータルサーバ１１から受信したコンテンツ一覧文書を表示処理部８６に出力する。コンテンツ一覧文書はＨＴＭＬ文書であり、表示処理部８６は、受け取ったコンテンツ一覧文書をディスプレイ（図示せず）に表示する（Ｓ２０２）。

　ここで、コンテンツタグにＰｌａｙＰｏｓｉｔｉｏｎがある場合、そのコンテンツについては、視聴が中断していることをユーザが認識できるようアイコンを用いるなどして表示するものとする。

　次に、ユーザ操作部９０は、コンテンツの一覧表を見たユーザの入力により、ユーザが再生を要望するコンテンツ（再生対象コンテンツ）の選択を受け付けて、ブラウザ処理部８８に通知する（Ｓ２０３）。

　ここで、ユーザによるコンテンツの選択は、例えば、ディスプレイに表示されるカーソルを、リモコン操作により移動させるなどし、ディスプレイに一覧表示されたコンテンツ名から１つを選出し、決定ボタンを押下することなどにより行う。

　ブラウザ処理部８８は、コンテンツ一覧文書における、再生対象コンテンツについてのコンテンツタグから、ＭｅｔａＦｉｌｅＵＲＬ、ＲｅｔｕｒｎＵＲＬ、ＰｌａｙＭｏｄｅ、コンテンツ名を抽出し、これらを再生対象コンテンツ情報として記憶する（Ｓ２０４）。

　そして、ブラウザ処理部８８は、再生対象コンテンツについてのコンテンツタグにＰｌａｙＰｏｓｉｔｉｏｎが有るか否か判断する（Ｓ２０５）。ＰｌａｙＰｏｓｉｔｉｏｎが有る場合（Ｓ２０５でＹＥＳ）、ブラウザ処理部８８は、先頭からの再生、レジューム再生のいずれを行うかの選択画面である再生位置選択画面を表示処理部８６に表示するよう指示する（Ｓ２０６）。表示処理部２０６は、ディスプレイに再生位置選択画面を表示し、ユーザ入力を待つ。

　そして、ユーザ入力がレジューム再生を選択するものであった場合（Ｓ２０７でＹＥＳ）、ブラウザ処理部８８は、コンテンツタグ中のＰｌａｙＰｏｓｉｔｉｏｎを再生対象コンテンツ情報のＰｌａｙＰｏｓｉｔｉｏｎとして記憶し（Ｓ２０８）、処理を終える（ＲＥＴＵＲＮ）。

　ユーザ入力がレジューム再生を選択するものでなかった場合（Ｓ２０７でＮＯ）、ブラウザ処理部８８は、再生対象コンテンツ情報のＰｌａｙＰｏｓｉｔｉｏｎとして０を記憶し（Ｓ２０９）、処理を終える（ＲＥＴＵＲＮ）。
＜３－４．視聴形態決定処理＞
　図１０のＳ１９に相当する、視聴形態決定処理について説明する。

　図１３は、再生装置３による視聴形態決定処理の流れを示すフローチャートである。

　再生装置３における通信処理部８１は、再生制御情報サーバ１２から再生制御情報を受信し、ブラウザ処理部８８に出力する。

　ブラウザ処理部８８は、取得した再生制御情報からｓｔａｒｔ要素を抽出し、記憶部８９に記憶させる（Ｓ３０１）。

　そして、再生制御情報中に、ａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素が有るか否か判定する（Ｓ３０２）。

　ａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素があった場合（Ｓ３０２でＹＥＳ）、ａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素を記憶部８９に記憶させる（Ｓ３０３）。

　そして、ブラウザ処理部８８は、ａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素に記載されている実行可能な視聴形態を表示し、ユーザに視聴形態を選択させる画面（以下、「視聴形態選択画面」という。）を表示するよう表示処理部８６に指示する。表示処理部８６は、一例として、図１５に示すような視聴形態選択画面をディスプレイに表示する（Ｓ３０４）。なお、図１５では、デフォルトで「３Ｄで再生」にハイライトがされており、「２Ｄで再生」と区別されている。図１５において、実行可能な視聴形態のうち、いずれにハイライトがされるかは、ポータルサーバ１１から再生装置３が受信したコンテンツ一覧文書における、再生対象コンテンツのコンテンツタグのＰｌａｙＭｏｄｅに記載されている視聴形態で定まる。

　ブラウザ処理部８８は、ユーザが視聴形態を選択するユーザ入力を行うのを一定時間経過（タイムアウト）するまで待つ（Ｓ３０５）。タイムアウトした場合（Ｓ３０５でＹＥＳ）、ブラウザ処理部８８は、再生対象コンテンツのコンテンツタグのｐｌａｙ＿ｍｏｄｅを、映像コンテンツサーバ１３に要求する視聴形態として、ＨＴＴＰ－ＧＥＴリクエストのＸ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅヘッダに格納し（Ｓ３０８）、Ｓ３０９に進む。

　タイムアウト前にユーザ入力による視聴形態の選択があった場合（Ｓ３０６でＹＥＳ）、選択された視聴形態を、映像コンテンツサーバ１３に要求する視聴形態として、ＨＴＴＰ－ＧＥＴリクエストのＸ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅヘッダに格納し（Ｓ３０７）、Ｓ３０９に進む。

　Ｓ３０２において、再生制御情報中にａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素が無いと判断された場合（Ｓ３０２でＮＯ）、Ｓ３０８に進む。

　Ｓ３０９において、再生対象コンテンツ情報中のＰｌａｙＰｏｓｉｔｏｎが０であるか否か判定する（Ｓ３０９）。

　ＰｌａｙＰｏｓｉｔｏｎが０である場合（Ｓ３０９でＹＥＳ）、ＨＴＴＰ－ＧＥＴリクエストにＸ－ＴｉｍｅＳｅｅｋＲａｎｇｅヘッダを追加しないものと決定し（Ｓ３１１）、処理を終了する（ＲＥＴＵＲＮ）。

　ＰｌａｙＰｏｓｉｔｏｎが０でない場合（Ｓ３０９でＮＯ）、ＨＴＴＰ－ＧＥＴリクエストにＸ－ＴｉｍｅＳｅｅｋＲａｎｇｅヘッダを追加し、値としてＰｌａｙＰｏｓｉｔｉｏｎを設定し（Ｓ３１０）、処理を終了する（ＲＥＴＵＲＮ）。
＜３－５．コンテンツ視聴中断（ポーズ）処理＞
　次に、再生装置３が図１０で示した手順で、コンテンツをストリーミング再生している状態となった後、視聴を中断する場合の処理について説明する。この処理において、再生装置３は、視聴を中断した位置として、コンテンツについての視聴済秒数をポータルサーバ１１に記憶させる。

　図１４は、コンテンツ視聴中断処理の流れを示すフローチャートである。

　コンテンツのストリーミング再生中に、再生装置３のユーザは、ユーザ操作部９０を用いて、コンテンツの再生中断を指示する（Ｓ５０１）。

　ユーザ操作部９０は、ＶＯＤ再生制御部８７に対しコンテンツ再生中断指示を出力する。ＶＯＤ再生制御部８７は、コンテンツ再生中断指示を受け取ると、音声デコーダ８３に音声パケットの復号停止を指示し、映像デコーダ８４に映像パケットの復号停止を指示し、字幕デコーダ８５に対し、字幕パケットの復号停止を指示する（Ｓ５０２）。このとき、ＶＯＤ再生制御部８７は、このコンテンツに関する視聴済秒数を記憶しておく（Ｓ５０３）。

　復号停止の指示を受けた音声デコーダ８３は、音声パケットの復号を停止する。また、復号停止の指示を受けた映像デコーダ８４は、映像パケットの復号を停止する。また、復号停止の指示を受けた字幕デコーダ８５は、字幕パケットの復号を停止する。

　そして、ＶＯＤ再生制御部８７は、通信処理部８１に対し、映像コンテンツサーバ１３とのＴＣＰコネクションの切断を指示する。通信処理部８１は、切断の指示を受けて、映像コンテンツサーバ１３とのＴＣＰコネクションを切断する（Ｓ５０４）
　次に、ブラウザ処理部８８は、ポータルサーバ１１に対し、通信処理部８１を介して、ユーザＩＤ、デバイスＩＤを含めたコンテンツ再生終了通知を送信する（Ｓ５０５）。

　コンテンツ再生終了通知のＳｔｏｐＰｏｓｉｔｉｏｎには、Ｓ５０３で記憶していた視聴済秒数を記載する。また、コンテンツ再生終了通知の２Ｄ３Ｄには、コンテンツ再生に用いていた視聴形態を記載する。

　ポータルサーバ１１において、通信処理部３１は、コンテンツ再生終了通知を受信し（Ｓ５０６）、データ処理部３２に出力する。

　データ処理部３２は、受信したコンテンツ再生終了通知のうち、ＨＴＴＰリクエストメッセージからＳｔｏｐＰｏｓｉｔｉｏｎ、ＰｌａｙＭｏｄｅを抽出する。そして、コンテンツ再生終了通知に含まれるユーザＩＤ、デバイスＩＤと一致するユーザＩＤ、デバイスＩＤを有するユーザ管理情報の最終視聴形態に、抽出したＰｌａｙＭｏｄｅを記載し、視聴済秒数に、ＳｔｏｐＰｏｓｉｔｉｏｎを記載する。

　ここで、本発明の本質には無関係であるが、Ｓ５０５の通信はＲｅｔｕｒｎＵＲＬで示されるリソースへのＨＴＴＰ－ＧＥＴリクエストで行われる。また、ＲｅｔｕｒｎＵＲＬで示されるリソースとしては、一般的にコンテンツ一覧文書が用いられる。したがって、Ｓ５０６の処理の後、ポータルサーバ１１は、コンテンツ一覧文書を再生装置３に送信する。
＜３－６．コンテンツ視聴再開処理＞
　コンテンツ視聴再開処理は、図１４を用いて説明したような、コンテンツの視聴が中断された状態から、コンテンツの視聴を再開する処理である。コンテンツ視聴再開処理は、既に説明した図１０～図１３のフローチャートに従い行うことになる。

　以下、コンテンツ視聴の再開処理について図１０～図１３のフローチャートを参照しながら具体例で説明する。

　本処理の前提として、視聴が中断されたコンテンツは、コンテンツＩＤがＣ０１であるコンテンツＡとする。コンテンツＡについては、「２Ｄ」「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」のいずれの視聴形態でも視聴できるよう構成されているものとする。また、再生制御情報サーバ１２が送信する再生制御情報中のａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素には「２Ｄ」、「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」の双方が記載されているものとする。

　視聴の中断までは、デバイスＩＤがＤ０１である再生装置３によりコンテンツが再生されていたものとし、視聴形態はｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣであったとする。コンテンツＡの視聴が中断されたときの視聴済秒数は３６００秒であったとする。

　コンテンツＡの視聴の再開は、再生装置３ではなく、再生装置４により行われるものとする。再生装置４において、この再開前にはコンテンツＡの視聴はされていないものとする。再生装置３及び再生装置４のユーザは同じであり、ユーザＩＤはＵ０１とする。

　再開直前のポータルサーバ１１の記憶部３３に記録されているユーザ管理情報は、図４に示す状態であるとする。

　これらの前提のもと、以下、図１０～１３に沿って説明を進める。なお、ここで説明に用いる図１０～図１３については、既に詳細に説明している。よって、再度全てのステップについて詳細に説明することはせず、重要度に応じて適宜説明を簡略化する。

　まず、図１０のＳ１１において、再生装置４のユーザは、再生装置４のユーザ操作部９０を用いて、コンテンツ一覧表示要求を入力する（Ｓ１１）。ユーザ操作部９０は、コンテンツ一覧表示要求を受け付け、コンテンツ一覧表示要求をブラウザ処理部８８に通知する。

　ブラウザ処理部８８は、コンテンツ一覧送信要求をポータルサーバ１１に対し送信する（Ｓ１２）。ポータルサーバ１１において、通信処理部３１は、コンテンツ一覧送信要求を受信し、データ処理部３２に出力する。データ処理部３２は、コンテンツ一覧文書作成処理を行う（Ｓ１３）。

　ここで、再生装置４が取得するコンテンツ一覧文書において、視聴を中断したコンテンツＡのコンテンツタグのＰｌａｙＰｏｓｉｔｉｏｎには、再生装置３における視聴済秒数（３６００）が設定されている。

　再生装置４のブラウザ処理部８８は、コンテンツ一覧文書に基づき、ディスプレイにコンテンツ名を一覧表示させる（Ｓ１５、図１２のＳ２０２）。このとき、コンテンツＡについては、視聴が中断していることをアイコンを用いて表示する。

　ユーザは、再生対象コンテンツとして、コンテンツＡを選択する（Ｓ２０３）。ブラウザ処理部８８は、コンテンツＡについての再生対象コンテンツ情報を記憶する（Ｓ２０４）。

　このとき、再生対象コンテンツとして、ＰｌａｙＰｏｓｉｔｉｏｎが設定されたコンテンツＡが選ばれているので（Ｓ２０５でＹＥＳ）、ブラウザ処理部８８は、先頭からの再生、レジューム再生のいずれを行うかの選択画面である再生位置選択画面を表示処理部８６に表示させる（Ｓ２０６）。

　このときユーザは、レジューム再生を選択するユーザ入力を行う。

　ブラウザ処理部８８は、レジューム再生が選択されたので（Ｓ２０７でＹＥＳ）、再生対象コンテンツ情報のＰｌａｙＰｏｓｉｔｉｏｎとして、コンテンツタグ中のＰｌａｙＰｏｓｉｔｉｏｎである３６００を記憶する（Ｓ２０８）。

　そして、ブラウザ処理部８８は、再生対象コンテンツ情報中のＭｅｔａＦｉｌｅＵＲＬを読み出し（Ｓ１６）、このＵＲＬに対する再生制御情報送信要求を行う（Ｓ１７）。

　再生制御情報サーバ１２は、コンテンツＡについての再生制御情報を再生装置４に送信する（Ｓ１８）。

　ブラウザ処理部８８は、再生制御情報サーバ１２から再生制御情報を受信する。そして、start要素を抽出し（Ｓ３０１）、再生制御情報中のａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素を抽出する（Ｓ３０２～３０３）。

　そして、ブラウザ処理部８８は、再生制御情報中のａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素に記載されている実行可能な視聴形態（「２Ｄ」「３Ｄ（ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ）」）から１つをユーザに選択させる画面である図１５に示すような視聴形態選択画面をディスプレイに表示させる（Ｓ３０４）。

　なお、図１５では、ポータルサーバ１１から再生装置４が受信したコンテンツ一覧文書におけるコンテンツＡのコンテンツタグのＰｌａｙＭｏｄｅに記載されている視聴形態（例えば「３Ｄ（ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ）」）にデフォルトでハイライトがされる。

　ここで、ユーザは２Ｄを選択するものとする（Ｓ３０５～３０６）。

　ブラウザ処理部８８は、ＨＴＴＰ－ＧＥＴリクエストのＸ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅヘッダに「２Ｄ」を格納し（Ｓ３０７）、Ｘ－ＴｉｍｅＳｅｅｋＲａｎｇｅヘッダを追加し、値として３６００を設定する（Ｓ３０９、Ｓ３１０）。

　そして、ブラウザ処理部８８は、映像コンテンツサーバ１３に、ＨＴＴＰ－ＧＥＴリクエストによるコンテンツの配信要求を行う（図１０のＳ２０）。

　映像コンテンツサーバ１３は、コンテンツＡについて先頭から３６００秒の部分以降を、２Ｄで視聴できるように再生装置４に配信する。

　再生装置４は、映像コンテンツサーバ１３からコンテンツＡを受信し、先頭から３６００秒の部分以降の再生を行う（Ｓ２２）。

　以上により、再生装置４において、コンテンツＡを、再生装置３で用いられていた視聴形態（３Ｄ（ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ））から、別の視聴形態（２Ｄ）に変更して、再生装置３にて視聴済であった続きから視聴することができることとなる。

　なお、コンテンツＡの視聴の再開について、再生装置４で行われる例で説明したが、再生装置３により行われる場合についても上記の説明と同様となる。
＜４．変形例＞
　以上、本発明に係るコンテンツ提供システムの実施形態を説明したが、例示したコンテンツ提供システムを以下のように変形することも可能であり、本発明が上述の実施形態で示した通りのコンテンツ提供システムに限られないことは勿論である。
（１）上記実施形態では、ポータルサーバ１１から再生装置３に対して前回の視聴形態を通知するため、ＨＴＭＬ文書を使用していたが、前回の視聴形態を通知できれば足りる。　　　

　例えば、再生開始を行うための関数としてｌａｕｎｃｈＩＰＴＶＣｏｎｔｅｎｔＥｘ（）のような前回の視聴形態を通知する機能を持った新たな関数を定義して用いてもよい。

　この新たな関数は、コンテンツ一覧文書として生成されるＢＭＬ文書に埋め込み、コンテンツの購入ボタンや再生ボタンなど押下によりコンテンツの再生が開始されるボタンに割り当てる。通知される前回の視聴形態は、再生装置において、視聴再開時のデフォルトの視聴形態として利用し、又は視聴形態選択画面に表示させる視聴形態を選択するためのボタンのうちデフォルトでいずれにフォーカスするかを決定するのに利用する。

　ｌａｕｎｃｈＩＰＴＶＣｏｎｔｅｎｔＥｘ（ｉｎｐｕｔ　Ｓｔｒｉｎｇ　ｃｏｎｔｅｎｔ＿ｕｒｉ，ｉｎｐｕｔ　Ｓｔｒｉｎｇ　ｒｅｔ＿ｕｒｉ，ｉｎｐｕｔ　Ｎｕｍｂｅｒ　ｓｔａｒｔ＿ｎｐｔ，　［ｉｎｐｕｔ　Ｓｔｒｉｎｇ　ｌｉｃｅｎｓｅ＿ｉｄ，］　ｉｎｐｕｔ　Ｓｔｒｉｎｇ　ｐｌａｙ＿ｍｏｄｅ）
　ここで、ｃｏｎｔｅｎｔ＿ｕｒｉは、再生対象のコンテンツに対応する再生制御メタファイルのＵＲＩを示す。ｒｅｔ＿ｕｒｉは、コンテンツ再生終了後に表示するＢＭＬ文書のＵＲＩを示す。ｓｔａｒｔ＿ｎｐｔは、コンテンツの再生開始時間位置（コンテンツの先頭からの秒数）を示す。再生装置は、引数ｓｔａｒｔ＿ｎｐｔによって引き渡された時間位置を指定して、映像コンテンツサーバ１０１にコンテンツのデータ送信をリクエストすることになる。ｌｉｃｅｎｓｅ＿ｉｄは、再生時に利用するライセンスのライセンスＩＤを示す。ｐｌａｙ＿ｍｏｄｅは、コンテンツの視聴形態を示す。ｐｌａｙ＿ｍｏｄｅは、値として「２Ｄ」、「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」が記載される。ｐｌａｙ＿ｍｏｄｅが「２Ｄ」の場合、コンテンツを２Ｄ映像として再生することを表し、「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」の場合、コンテンツを３Ｄ映像として再生することを表す。

　また、図１５の視聴形態選択画面をＢＭＬ文書で表現し、ＢＭＬ文書に、２Ｄ映像として再生することを選択するボタン、３Ｄ映像として再生することを選択するボタンのそれぞれが押下された場合に、ｌａｕｎｃｈＩＰＴＶＣｏｎｔｅｎｔＥｘ（）関数が実行されるよう記載しておいてもよい。

　具体的には、ＢＭＬ文書に、２Ｄ映像として再生することを選択するボタンが選択された場合に引数ｐｌａｙ＿ｍｏｄｅの値が「２Ｄ」であるｌａｕｎｃｈＩＰＴＶＣｏｎｔｅｎｔＥｘ（）関数が実行されるよう記載する。また、３Ｄ映像として再生することを選択するボタンが選択された場合に引数ｐｌａｙ＿ｍｏｄｅの値が「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」であるｌａｕｎｃｈＩＰＴＶＣｏｎｔｅｎｔＥｘ（）関数が実行されるよう記載する。

　また、この場合、ポータルサーバ１１に記憶されたユーザ管理情報の最終視聴形態と同じ視聴形態で視聴するボタンにフォーカスがあたっているようにＢＭＬ文書を構成するようにしてもよい。すなわち、最終視聴形態が「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」の場合にはｐｌａｙ＿ｍｏｄｅの値が「３Ｄ」であるｌａｕｎｃｈＩＰＴＶＣｏｎｔｅｎｔＥｘ（）関数が実行されるボタンにフォーカスをあてるようにＢＭＬ文書を構成し、最終視聴形態が「２Ｄ」の場合にはｐｌａｙ＿ｍｏｄｅの値が「２Ｄ」であるｌａｕｎｃｈＩＰＴＶＣｏｎｔｅｎｔＥｘ（）関数が実行されるボタンにフォーカスをあてるようにＢＭＬ文書を構成する。
（２）変形例（１）では、前回の視聴形態を通知する関数ｌａｕｎｃｈＩＰＴＶＣｏｎｔｅｎｔＥｘ（）を定義して用いることとしたが、前回の視聴形態を通知できれば足りる。例えば、視聴形態を再生制御情報にて指定することとしてもよい。この場合、再生制御情報に一例として図７に示すｄｅｆａｕｌｔ＿ｐｌａｙ＿ｍｏｄｅ要素を追加する。

　ｄｅｆａｕｌｔ＿ｐｌａｙ＿ｍｏｄｅ要素は、パラメータ値として「２Ｄ」又は「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」が記載される。

　また、再生装置において、２Ｄ映像と３Ｄ映像のいずれをデフォルトで選択するかは、予め再生装置に記憶されていてもよい。

　また、ｄｅｆａｕｌｔ＿ｐｌａｙ＿ｍｏｄｅ要素は、前回の視聴形態を通知するのではなく、サービス提供者などが設定する該コンテンツのデフォルトの視聴形態を表すものであってもよい。

　また、ｄｅｆａｕｌｔ＿ｐｌａｙ＿ｍｏｄｅ要素は、再生装置が備える表示能力に応じて、コンテンツ配信システム２が設定するものであってもよい。すなわち、コンテンツ配信システム２は、再生装置が３Ｄの表示能力を有するものであれば、ｄｅｆａｕｌｔ＿ｐｌａｙ＿ｍｏｄｅ要素の値として３Ｄを設定し、再生装置が３Ｄの表示能力を有さないものであれば、ｄｅｆａｕｌｔ＿ｐｌａｙ＿ｍｏｄｅ要素の値として２Ｄを設定するものであってもよい。
（３）上述の実施形態では、視聴形態選択画面として、ａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅに記載されている実行可能な視聴形態をディスプレイに表示し、ユーザ入力により視聴形態の選択をさせることとしたが、視聴形態が選択できれば足りる。例えば、特定ボタンの押下など予め決まった動作により、ユーザに視聴形態を選択させることとしてもよい。
（４）上述の実施形態では、再生装置３から映像コンテンツサーバ１３に視聴形態を通知するために、ＨＴＴＰ－ＧＥＴリクエストにＸ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅヘッダを記載することとしたが、映像コンテンツサーバ１３において視聴形態を認識できれば足りる。

　例えば、再生装置３と、映像コンテンツサーバ１３との間で、ＨＴＴＰ－ＧＥＴリクエストにＸ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅヘッダが無い場合には、「２Ｄ」が指定されたものとみなすと予め規定してもよい。これにより、ＨＴＴＰ－ＧＥＴリクエストについて、コンテンツを２Ｄでのみ再生可能な、Ｘ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅを加える拡張に対応していないレガシー装置との互換性を確保することができる。
（５）上述の実施形態では、送信する映像がＭＶＣ映像である場合において、Ｘ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅが「２Ｄ」の場合、映像コンテンツサーバ１３が、配信時にディペンデントビューを含むＴＳパケットを取り除く処理を行って配信するとしたが、ディペンデントビューを含まない映像データが送信できさえすれば足りる。例えば、ディペンデントビューを含まない映像データを予め用意しておき、これを送信することとしてもよい。これにより、再生装置側で使用しないディペンデントビューを送信するのを避け、使用する通信帯域を節約することができる。
（６）上述の実施形態では、デバイスＩＤは、コンテンツの配信契約締結時などにユーザの申請に応じてコンテンツ配信業者が一意に割り当てるとしたが、デバイスを一意に識別できれば足りる。例えば、ＩＰアドレスや、ＭＡＣアドレスなどを用いてもよい。
（７）上述の実施形態では、再生装置３がコンテンツの視聴、中断を行った後、デバイスＩＤの異なる再生装置４が同コンテンツの視聴を再開する場合に、再生装置４において同コンテンツについて可能な全視聴形態から１つの視聴形態を選択することとしていたが、視聴再開時に、デバイスＩＤを用いて視聴形態の選択肢を制限する制御を行ってもよい。

　例えば、据置端末である再生装置３がコンテンツについて３Ｄ表示する能力を有し、タブレット端末である再生装置４が同コンテンツについて３Ｄ表示する能力を有しておらず２Ｄ表示する能力しか有さない場合、再生装置４において、視聴を再開するときに表示される視聴形態選択画面に３Ｄ視聴の選択肢を表示しない、或いは３Ｄ視聴を選択できないよう制御してもよい。
（８）上述の実施形態では、再生制御情報中のａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素に、コンテンツについて可能な視聴形態として「２Ｄ」、「３Ｄ（ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ）」を記載し、再生装置３及び４に通知していたが、視聴形態は「２Ｄ」「３Ｄ（ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ）」に限らず、コンテンツについての視覚的な表現形態を示すものであれば足りる。

　例えば、視聴形態は、マルチアングル表現されているコンテンツについての各アングルを示してもよい。また、視聴形態は、同時刻に配信する複数の番組それぞれを示してもよい。

　この場合、再生制御情報中のａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素には、図１６に示すように、一例として、コンテンツについて可能な視聴形態を表す「Ｖｉｅｗ１」「Ｖｉｅｗ２」などを列記する。Ｖｉｅｗ１、Ｖｉｅｗ２・・・がそれぞれ、各アングルや、各番組を示すことになる。

　また、視聴形態は、解像度であってもよい。この場合、再生制御情報中のａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素には、図１７に示すように、コンテンツについて可能な視聴形態として一例として「ＳＤ（Ｓｔａｎｄａｒｄ　Ｄｅｆｉｎｉｔｉｏｎ）」「ＨＤ（Ｈｉｇｈ　Ｄｅｆｉｎｉｔｉｏｎ）」「４Ｋ」「ＱＶＧＡ（Ｑｕａｒｔｅｒ　Ｖｉｄｅｏ　Ｇｒａｐｈｉｃｓ　Ａｒｒａｙ）」などを列記する。ここで、４Ｋとは、４０００×２０００ドット前後の解像度を示す。

　また、上述の実施形態では、ＥＲＩにａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素やｄｅｆａｕｌｔ＿ｐｌａｙ＿ｍｏｄｅ要素を追加する例を示したが、これらと同様の内容を通知できさえすれば足りる。例えば、他の名前の要素を追加して使用しても良い。また、各要素の値として「２Ｄ」と「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」を用いているが、同様の内容を表している他の値（「３Ｄ」など）を用いても良い。

　以上の説明は、再生制御情報中のａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素について行ったものであるが、上述の再生装置３と映像コンテンツサーバ１３の間の通信に用いるＸ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅについても同様である。
（９）上述の実施形態では、再生装置３及び４が、映像コンテンツサーバ１３に対し、「コンテンツの再生、再開（配信開始）」、「コンテンツの再生中断、中止」を要求する場合に、ＨＴＴＰを使用したが、「コンテンツの再生、再開」、「コンテンツの再生中断、中止」が要求できさえすれば足りる。

　例えば、データ通信としてＲＴＰ（Ｒｅａｌｔｉｍｅ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ）、その制御プロトコルとしてＲＴＳＰ（Ｒｅａｌ　Ｔｉｍｅ　Ｓｔｒｅａｍｉｎｇ　Ｐｒｏｔｏｃｏｌ）を使用しても良い。なお、ＲＴＰはＲＦＣ３５５０で、ＲＴＳＰはＲＦＣ２３２６で定義されている。

　ＲＴＳＰでは、ストリーミング再生に（ａ）ＳＥＴＵＰ、（ｂ）ＰＬＡＹ、（ｃ）ＰＡＵＳＥ、（ｄ）ＴＥＡＲＤＯＷＮの各メソッドが用いられる。

　ＳＥＴＵＰは、サーバへのストリーム送出用のリソース確保とセッション開始を指示するメソッドである。

　ＰＬＡＹは、ＳＥＴＵＰによって確保されたリソースによるメディアデータの送出開始を指示するメソッドである。コンテンツについて再生を行う場合に用いられる。

　ＰＡＵＳＥは、サーバリソースを開放せず、一時的にストリームの送出を停止するよう指示するメソッドである。コンテンツを一時停止、停止（再生終了）する場合の双方に用いられる。

　ＴＥＡＲＤＯＷＮは、リソースの開放とセッションの終了を指示するメソッドである。

　ここで、ＰＬＡＹは、上述の実施形態におけるＨＴＴＰ－ＧＥＴリクエストの代わりに使用されることとなる。

　ＰＡＵＳＥは、上述の実施形態におけるコンテンツ再生終了通知の代わりに使用されることとなる。

　ＳＥＴＵＰは、上述の実施形態において対応するメソッド等は特には無いが、ＰＬＡＹに先立って使用することとなる。

　ＴＥＡＲＤＯＷＮは、上述の実施形態において対応するメソッド等は特には無いが、コンテンツの再生を終了する場合に使用することとなる。

　以下に、（ａ）ＳＥＴＵＰ、（ｂ）ＰＬＡＹ、（ｃ）ＰＡＵＳＥの各メソッド（リクエスト、レスポンス）の例を記載する。ＴＥＡＲＤＯＷＮについては、ＲＦＣ２３２６の規定と特に変わるところが無いので記載を省略する。

　ここで、ＳＥＴＵＰ、ＰＬＡＹ、ＰＡＵＳＥの各メソッドのレスポンスには、コンテンツで利用可能な視聴形態を記述するため、拡張ヘッダＸ－Ａｖａｉｌａｂｌｅ－Ｐｌａｙ－Ｍｏｄｅを追加する拡張を行っている。Ｘ－Ａｖａｉｌａｂｌｅ－Ｐｌａｙ－Ｍｏｄｅには、２Ｄと３Ｄの双方を示す「２Ｄ３Ｄ」，２Ｄを示す「２Ｄ」，３Ｄを示す「３Ｄ」のいずれかが記載される。
（ａ）ＳＥＴＵＰ
　　（リクエスト）
　ＳＥＴＵＰ　ｒｔｓｐ：／／ｖｉｄｅｏｓｅｒｖｅｒ．ｃｏｍ／ＡＶＤａｔａ／０００１．ｍ２ｔｓ　ＲＴＳＰ／１．０
　ＣＳｅｑ：　　２
　Ｔｒａｓｎｐｏｒｔ：　ＲＴＰ／ＡＶＰ；ｕｎｉｃａｓｔ；ｃｌｉｅｎｔ＿ｐｏｒｔ＝５０００－５００１
　Ｘ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅ：　３Ｄ
　ここで、Ｘ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅは、追加する拡張ヘッダであり、コンテンツについて配信を要求する視聴形態を記載する。Ｘ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅについては、上記例の３Ｄの他、２Ｄを指定することもできる。また、互換性確保の観点からＸ－Ｒｅｑｕｅｓｔ－Ｐｌａｙ－Ｍｏｄｅを省略することをもって２Ｄを指定するものと取り決めておいてもよい。

　　（レスポンス）
　ＲＴＳＰ／１．０　２００　ＯＫ
　ＣＳｅｑ：　２
　Ｄａｔｅ：　Ｗｅｄ　Ｊｕｌ　２０　１５：００：００　２０１１　ＧＭＴ
　Ｓｅｓｓｉｏｎ：　５０５
　Ｔｒａｎｓｐｏｒｔ：　ＲＴＰ／ＡＶＰ；ｕｎｉｃａｓｔ；ｃｌｉｅｎｔ＿ｐｏｒｔ＝５０００－５００１；ｓｅｖｅｒ＿ｐｏｒｔ＝６０００－６００１
　Ｘ－Ａｖａｉｌａｂｌｅ－Ｐｌａｙ－Ｍｏｄｅ：　２Ｄ３Ｄ
（ｂ）ＰＬＡＹ
　　（リクエスト）
　ＰＬＡＹ　ｒｔｓｐ：／／ｖｉｄｅｏｓｅｒｖｅｒ．ｃｏｍ／ＡＶＤａｔａ／０００１．ｍ２ｔｓ　ＲＴＳＰ／１．０
　ＣＳｅｑ：　　３
　Ｓｅｓｓｉｏｎ：　５０５
　Ｒａｎｇｅ：　ｎｐｔ＝００：６０：００－
　ここで、Ｒａｎｇｅが、上述の実施形態における　ＸＴｉｍｅＳｅｅｋＲａｎｇｅに相当し、意味内容も同様である。

　　（レスポンス）
　ＲＴＳＰ／１．０　２００　ＯＫ
　ＣＳｅｑ：　３
　Ｄａｔｅ：　Ｗｅｄ　Ｊｕｌ　２０　１５：０２：００　２０１１　ＧＭＴ
　Ｒａｎｇｅ：　ｎｔｐ＝００：６０：００－
　Ｘ－Ａｖａｉｌａｂｌｅ－Ｐｌａｙ－Ｍｏｄｅ：　２Ｄ３Ｄ
（ｃ）ＰＡＵＳＥ
　　（リクエスト）
　ＰＡＵＳＥ　ｒｔｓｐ：／／ｖｉｄｅｏｓｅｒｖｅｒ．ｃｏｍ／ＡＶＤａｔａ／０００１．ｍ２ｔｓ　ＲＴＳＰ／１．０
　ＣＳｅｑ：　　４
　Ｓｅｓｓｉｏｎ：　５０５
　　（レスポンス）
　ＲＴＳＰ／１．０　２００　ＯＫ
　ＣＳｅｑ：　４
　Ｄａｔｅ：　Ｗｅｄ　Ｊｕｌ　２０　１５：２０：００　２０１１　ＧＭＴ
　Ｘ－Ａｖａｉｌａｂｌｅ－Ｐｌａｙ－Ｍｏｄｅ：　２Ｄ３Ｄ
（１０）上述の実施形態では、再生装置３が、コンテンツについての再生制御情報を受信し、解析し、図１５に示すような視聴形態選択画面を生成し表示することとしていたが、視聴形態選択画面を表示できれば足りる。

　例えば、コンテンツの映像がＭＶＣ映像である場合に、ポータルサーバ１１が、２Ｄ映像として再生するか、３Ｄ映像として再生するかを、再生装置３に問い合せることとしてもよい。この場合、一例として、再生装置３が再生する映像コンテンツを選択したとき、ポータルサーバ１１が、図１５に示すような視聴形態選択画面を表示するためのＢＭＬ文書もしくはＨＴＭＬ文書を再生装置３に送信する。

　また、送信する視聴形態選択画面としては、ポータルサーバ１１に対し、再生装置側からコンテンツについて通知された、前回の再生時に選択していた視聴形態を示すボタンに、デフォルトでフォーカスが当たっているものであってもよい。

　例えば、再生装置３では前回に３Ｄ映像として再生していたコンテンツに対して視聴形態選択画面が表示される場合、３Ｄ映像に係るボタンにフォーカスを当てた状態で表示されることとなる。
（１１）上述の実施形態では、映像コンテンツサーバ１３は、ＭＶＣ映像について、再生装置３から２Ｄ映像の送信をリクエストされた場合、ＭＶＣ映像のディペンデントビューを含まないストリームを送信し、再生装置３から３Ｄ映像の送信をリクエストされた場合、ＭＶＣ映像をそのまま送信することとしたが、再生装置３において、リクエストした視聴形態で２Ｄ映像、３Ｄ映像が再生できれば足りる。

　例えば、映像コンテンツサーバ１３が、ＭＶＣ映像の送信をリクエストされた場合には常にＭＶＣ映像をそのまま送信し、再生装置３側で、ＭＶＣ映像を２Ｄ映像として再生するか、３Ｄ映像として再生するか制御してもよい。この場合、再生装置３において、視聴形態の切り替えが必要となっても、映像コンテンツサーバ１３と通信を一旦終了する必要は無くなる。
（１２）上述の実施形態では、ａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素に、コンテンツについて可能な視聴形態を全て列挙していたが、コンテンツについて許可されている視聴形態を列挙することとしてもよい。これにより、コンテンツの制作者がそのコンテンツを３Ｄ映像としてのみ視聴させたい場合など、利用可能な視聴形態を意図的に制限できることとなる。

　例えば、コンテンツがＭＶＣ映像であっても、このコンテンツに関する再生制御情報のａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素に、「２Ｄ」を記載せず「ｓｔｅｒｅｏｓｃｏｐｉｃ＿ＭＶＣ」のみ記載する。これにより、コンテンツは３Ｄ映像として再生することは許可されているものの、２Ｄ映像として再生することは許可されていないことを再生装置に認識させることができる。
（１３）上述の実施形態では、本発明をコンテンツのインターネット配信によるＶＯＤサービスに適用する例で説明していたが、コンテンツの配信タイミングは、ＶＯＤのようなリアルタイム配信に限るものではなく、コンテンツの再生に間に合えば足りる。

　例えば、予めコンテンツをダウンロードして記憶しておき、その後、再生するダウンロードサービスにも、本発明は適用できる。

　この場合、再生装置３は、映像コンテンツサーバ１３に対するコンテンツの送信要求は行なわず、自装置内に記憶しているコンテンツを再生することになる。また、再生装置３は、再生制御情報におけるａｖａｉｌａｂｌｅ＿ｐｌａｙ＿ｍｏｄｅ要素を、再生対象コンテンツが選択されたときに参照し、視聴形態選択画面を表示することで、コンテンツについて可能な視聴形態をユーザに選択させることができる。
（１４）上述の実施形態で示したコンテンツ一覧表示処理、再生対象コンテンツ情報記憶制御処理、再生位置選択画面表示処理、再生制御情報送信要求処理、視聴形態決定処理などを再生装置３、及び４のプロセッサ、及びそのプロセッサに接続された各種回路に実行させるための機械語或いは高級言語のプログラムコードからなる制御プログラムを、記録媒体に記録すること、又は各種通信路等を介して流通させ頒布することもできる。このような記録媒体には、ＩＣカード、ハードディスク、光ディスク、フレキシブルディスク、ＲＯＭ、フラッシュメモリ等がある。流通、頒布された制御プログラムはプロセッサに読み出され得るメモリ等に格納されることにより利用に供され、そのプロセッサがその制御プログラムを実行することにより各実施形態で示したような各機能が実現されるようになる。なお、プロセッサは、制御プログラムを直接実行する他、コンパイルして実行或いはインタプリタにより実行してもよい。
（１５）上述の実施形態で示した各機能構成要素（通信処理部３１、データ処理部３２、記憶部３３、通信処理部５１、データ処理部５２、記憶部５３、通信処理部７１、リクエスト処理部７２、記憶部７３及びＶＯＤ配信制御部７４、通信処理部８１、デマルチプレクサ８２、音声デコーダ８３、映像デコーダ８４、字幕デコーダ８５、表示処理部８６、ＶＯＤ再生制御部８７、ブラウザ処理部８８、及びユーザ操作部９０など）は、その機能を実行する回路として実現されてもよいし、１又は複数のプロセッサによりプログラムを実行することで実現されてもよい。

　なお、上述の各機能構成要素は典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップされてもよいし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。更には、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。
（１６）上述の実施形態及び各変形例を、部分的に組み合せてもよい。
＜５．補足＞
　以下、更に本発明の一実施形態としてのコンテンツ再生装置の構成及びその変形例と効果について説明する。
（１）本発明の一実施形態に係るコンテンツ再生装置は、ネットワークを介して接続するコンテンツ配信システムから、映像コンテンツをストリーム受信し再生するコンテンツ再生装置であって、映像コンテンツについて選択可能な複数の視聴形態を示す制御情報を前記コンテンツ配信システムから前記ネットワークを介して受信する受信手段と、前記複数の視聴形態を選択肢としてユーザに提示する提示手段と、前記選択肢から１つを選択するユーザ入力を受け付ける入力受付手段と、前記選択された視聴形態を示す情報を前記コンテンツ配信システムに送信することにより映像コンテンツのストリーム配信を要求する要求手段とを備える。

　この構成により、視聴形態が切り替えられることを予めユーザに提示して切り替えの機会を与えることができ、ユーザの利便性を向上することができる。
（２）また、前記入力受付手段は、更に、前記映像コンテンツの再生中に、再生を中断するポーズ指示を受け付け、前記提示手段は、更に、前記ポーズ指示が受け付けられたときに、再生再開時の視聴形態を選択するための選択肢として前記複数の視聴形態をユーザに提示することとしてもよい。

　この構成により、再生中断を契機として、視聴形態が切り替えられることを予めユーザに提示して切り替えの機会を与えることができ、ユーザの利便性を向上することができる。
（３）また、前記提示手段は、前記再生再開時の視聴形態を選択するための選択肢を表示する場合に、前記ポーズ指示を受け付ける直前に用いられていた視聴形態を他の視聴形態と差別化して表示することとしてもよい。

　この構成により、ユーザが選択する可能性の高い、再生中断直前に用いられていた視聴形態を、他の視聴形態から識別し及び選択するのを容易にすることができ、ユーザの利便性を向上することができる。
（４）また、前記コンテンツ配信システムは、前記映像コンテンツが、前記コンテンツ再生装置によって再生される前に、前記コンテンツ再生装置のユーザによって他の装置を用いて途中まで視聴された場合に、その視聴形態を記憶しており、前記受信手段は、更に、前記コンテンツ配信システムから、前記他の装置での視聴形態を示す情報を受信し、前記提示手段は、前記選択肢を表示する場合に、前記他の装置での視聴形態を、他の視聴形態とは差別化して表示することとしてもよい。

　この構成により、ユーザが他の装置を用いて途中まで視聴していたコンテンツを、コンテンツ再生装置で引き継いで視聴する場合に、ユーザが選択する可能性の高い、再生中断直前に他の装置で用いられていた視聴形態を、他の視聴形態から識別し及び選択するのを容易にすることができ、ユーザの利便性を向上することができる。
（５）また、前記提示手段は、前記選択肢を提示する場合に、自装置が表示する能力を有さない視聴形態については提示を抑制することとしてもよい。

　この構成により、ユーザによる、実際に用いることができる視聴形態の把握を容易にすることができる。
（６）また、前記制御情報は、前記映像コンテンツについて選択可能な視聴形態を全て列記したものであり、前記提示手段は、前記制御情報中に列記された視聴形態を全て読み出して表示することとしてもよい。

　また、前記制御情報は、ＥＲＩに追記された情報であり、前記受信手段は、前記制御情報の受信として、前記コンテンツ配信システムから前記ＥＲＩを受信して当該ＥＲＩから前記制御情報を抽出することとしてもよい。

　この構成により、切り替え可能な視聴形態を全てユーザに予め提示することができ、ユーザの利便性を向上することができる。
（７）また、前記複数の視聴形態それぞれは、相互に異なる解像度であることとしてもよい。

　この構成により、切り替え可能な解像度を全てユーザに予め提示することができ、ユーザの利便性を向上することができる。
（８）また、前記複数の視聴形態は、２Ｄ及び３Ｄであることとしてもよい。

　この構成により、コンテンツの視聴形態として２Ｄと３Ｄとが切り替え可能であることをユーザに予め提示することができ、ユーザの利便性を向上することができる。
（９）本発明の一実施形態に係るコンテンツ再生方法は、受信手段と、提示手段と、入力受付手段と、要求手段とを備えたコンテンツ再生装置に用いられ、ネットワークを介して接続するコンテンツ配信システムから、映像コンテンツをストリーム受信し再生するコンテンツ再生方法であって、前記受信手段が、映像コンテンツについて選択可能な複数の視聴形態を示す制御情報を前記コンテンツ配信システムから前記ネットワークを介して受信する受信ステップと、前記提示手段が、前記複数の視聴形態を選択肢としてユーザに提示する提示ステップと、前記入力受付手段が、前記選択肢から１つを選択するユーザ入力を受け付ける入力受付ステップと、前記要求手段が、前記選択された視聴形態を示す情報を前記コンテンツ配信システムに送信することにより映像コンテンツのストリーム配信を要求する要求ステップとを含む。

　本発明の一実施形態に係るコンテンツ再生プログラムは、コンピュータを、ネットワークを介して接続するコンテンツ配信システムから、映像コンテンツをストリーム受信し再生するコンテンツ再生装置として機能させるためのコンテンツ再生プログラムであって、前記コンピュータを、映像コンテンツについて選択可能な複数の視聴形態を示す制御情報を前記コンテンツ配信システムから前記ネットワークを介して受信する受信手段と、前記複数の視聴形態を選択肢としてユーザに提示する提示手段と、前記選択肢から１つを選択するユーザ入力を受け付ける入力受付手段と、前記選択された視聴形態を示す情報を前記コンテンツ配信システムに送信することにより映像コンテンツのストリーム配信を要求する要求手段として機能させる。

　本発明の一実施形態に係るコンテンツ提供システムは、映像コンテンツをストリーム配信するコンテンツ配信システムと、前記映像コンテンツをストリーム受信し再生するコンテンツ再生装置とがネットワークを介して接続されたコンテンツ提供システムであって、前記コンテンツ配信システムは、前記映像コンテンツについて選択可能な複数の視聴形態を示す制御情報を前記コンテンツ再生装置に送信する送信手段と、前記コンテンツ再生装置から、前記複数の視聴形態から選択された１つの視聴形態を示す情報を受け付ける要求受付手段と、前記選択された視聴形態による前記映像コンテンツの配信を行う配信手段とを備え、前記コンテンツ再生装置は、前記コンテンツ配信システムから、前記制御情報を受信する受信手段と、前記制御情報に示される複数の視聴形態を選択肢としてユーザに提示する提示手段と、前記選択肢から１つを選択するユーザ入力を受け付ける入力受付手段と、前記コンテンツ配信システムに対し、前記選択された視聴形態を示す情報を送信する要求手段とを備える。

　この構成により、視聴形態が切り替えられることを予めユーザに提示して切り替えの機会を与えることができ、ユーザの利便性を向上することができる。

　本発明の一形態に係るコンテンツ再生装置は、コンテンツについて複数の視聴形態が切り替えられることを予めユーザに提示して切り替えの機会を与えるものであり、ネットワークを介してコンテンツをストリーミング受信し再生する装置等に有用である。

　１　コンテンツ提供システム
　２　コンテンツ配信システム
　３　再生装置
　４　再生装置
　５　ネットワーク
　１１　ポータルサーバ
　１２　再生制御情報サーバ
　１３　映像コンテンツサーバ
　８１　通信処理部
　８２　デマルチプレクサ
　８３　音声デコーダ
　８４　映像デコーダ
　８５　字幕デコーダ
　８６　表示処理部
　８７　ＶＯＤ再生制御部
　８８　ブラウザ処理部
　８９　記憶部
　９０　ユーザ操作部

Claims (12)

1. 　ネットワークを介して接続するコンテンツ配信システムから、映像コンテンツをストリーム受信し再生するコンテンツ再生装置であって、
   　映像コンテンツについて選択可能な複数の視聴形態を示す制御情報を前記コンテンツ配信システムから前記ネットワークを介して受信する受信手段と、
   　前記複数の視聴形態を選択肢としてユーザに提示する提示手段と、
   　前記選択肢から１つを選択するユーザ入力を受け付ける入力受付手段と、
   　前記選択された視聴形態を示す情報を前記コンテンツ配信システムに送信することにより映像コンテンツのストリーム配信を要求する要求手段とを備える
   　ことを特徴とするコンテンツ再生装置。
2. 　前記入力受付手段は、更に、前記映像コンテンツの再生中に、再生を中断するポーズ指示を受け付け、
   　前記提示手段は、更に、前記ポーズ指示が受け付けられたときに、再生再開時の視聴形態を選択するための選択肢として前記複数の視聴形態をユーザに提示する
   　ことを特徴とする請求項１記載のコンテンツ再生装置。
3. 　前記提示手段は、前記再生再開時の視聴形態を選択するための選択肢を表示する場合に、前記ポーズ指示を受け付ける直前に用いられていた視聴形態を他の視聴形態と差別化して表示する
   　ことを特徴とする請求項２記載のコンテンツ再生装置。
4. 　前記コンテンツ配信システムは、前記映像コンテンツが、前記コンテンツ再生装置によって再生される前に、前記コンテンツ再生装置のユーザによって他の装置を用いて途中まで視聴された場合に、その視聴形態を記憶しており、
   　前記受信手段は、更に、前記コンテンツ配信システムから、前記他の装置での視聴形態を示す情報を受信し、
   　前記提示手段は、前記選択肢を表示する場合に、前記他の装置での視聴形態を、他の視聴形態とは差別化して表示する
   　ことを特徴とする請求項１記載のコンテンツ再生装置。
5. 　前記提示手段は、前記選択肢を提示する場合に、自装置が表示する能力を有さない視聴形態については提示を抑制する
   　ことを特徴とする請求項１記載のコンテンツ再生装置。
6. 　前記制御情報は、前記映像コンテンツについて選択可能な視聴形態を全て列記したものであり、
   　前記提示手段は、前記制御情報中に列記された視聴形態を全て読み出して表示する
   　ことを特徴とする請求項１記載のコンテンツ再生装置。
7. 　前記制御情報は、ＥＲＩ（Ｅｎｔｒｙ　Ｒｅｓｏｕｒｃｅ　Ｉｎｆｏｒｍａｔｉｏｎ）に追記された情報であり、
   　前記受信手段は、前記制御情報の受信として、前記コンテンツ配信システムから前記ＥＲＩを受信して当該ＥＲＩから前記制御情報を抽出する
   　ことを特徴とする請求項６記載のコンテンツ再生装置。
8. 　前記複数の視聴形態それぞれは、相互に異なる解像度である
   　ことを特徴とする請求項１記載のコンテンツ再生装置。
9. 　前記複数の視聴形態は、２Ｄ及び３Ｄである
   　ことを特徴とする請求項１記載のコンテンツ再生装置。
10. 　受信手段と、提示手段と、入力受付手段と、要求手段とを備えたコンテンツ再生装置に用いられ、ネットワークを介して接続するコンテンツ配信システムから、映像コンテンツをストリーム受信し再生するコンテンツ再生方法であって、
    　前記受信手段が、映像コンテンツについて選択可能な複数の視聴形態を示す制御情報を前記コンテンツ配信システムから前記ネットワークを介して受信する受信ステップと、
    　前記提示手段が、前記複数の視聴形態を選択肢としてユーザに提示する提示ステップと、
    　前記入力受付手段が、前記選択肢から１つを選択するユーザ入力を受け付ける入力受付ステップと、
    　前記要求手段が、前記選択された視聴形態を示す情報を前記コンテンツ配信システムに送信することにより映像コンテンツのストリーム配信を要求する要求ステップとを含む
    　ことを特徴とするコンテンツ再生方法。
11. 　コンピュータを、ネットワークを介して接続するコンテンツ配信システムから、映像コンテンツをストリーム受信し再生するコンテンツ再生装置として機能させるためのコンテンツ再生プログラムであって、
    　前記コンピュータを、
    　映像コンテンツについて選択可能な複数の視聴形態を示す制御情報を前記コンテンツ配信システムから前記ネットワークを介して受信する受信手段と、
    　前記複数の視聴形態を選択肢としてユーザに提示する提示手段と、
    　前記選択肢から１つを選択するユーザ入力を受け付ける入力受付手段と、
    　前記選択された視聴形態を示す情報を前記コンテンツ配信システムに送信することにより映像コンテンツのストリーム配信を要求する要求手段として機能させる
    　ことを特徴とするコンテンツ再生プログラム。
12. 　映像コンテンツをストリーム配信するコンテンツ配信システムと、前記映像コンテンツをストリーム受信し再生するコンテンツ再生装置とがネットワークを介して接続されたコンテンツ提供システムであって、
    　前記コンテンツ配信システムは、
    　前記映像コンテンツについて選択可能な複数の視聴形態を示す制御情報を前記コンテンツ再生装置に送信する送信手段と、
    　前記コンテンツ再生装置から、前記複数の視聴形態から選択された１つの視聴形態を示す情報を受け付ける要求受付手段と、
    　前記選択された視聴形態による前記映像コンテンツの配信を行う配信手段とを備え、
    　前記コンテンツ再生装置は、
    　前記コンテンツ配信システムから、前記制御情報を受信する受信手段と、
    　前記制御情報に示される複数の視聴形態を選択肢としてユーザに提示する提示手段と、
    　前記選択肢から１つを選択するユーザ入力を受け付ける入力受付手段と、
    　前記コンテンツ配信システムに対し、前記選択された視聴形態を示す情報を送信する要求手段とを備える
    　ことを特徴とするコンテンツ提供システム。

Images