(57)【要約】【課題】動画サーバと受信装置との間に介在するプロキシサーバが、Ｒａｎｇｅヘッダを削除する等により、ファイルの一部を要求するリクエストをファイル全体を要求するリクエストに変換してしまうような場合においても、ユーザに対して煩わしさを感じさせない動画配信サービスにおける動画受信装置およびＧＵＩ表示方法を提供する。【解決手段】動画受信装置は、通常の動画要求と同じ動作がプロキシサーバにおいてなされるリクエストをプロキシサーバに対して事前に送信し、動画ファイルの一部を取得するリクエストがプロキシサーバ経由で要求通り動画サーバに届くか、すなわち、特殊再生が可能な状況にあるか否かを事前に判断し、特殊再生が可能な状況になっていないと判断した場合には、ユーザ所望の動画ファイルを再生する際、特殊再生操作が可能なＧＵＩ画面の表示をしないようにする。【選択図】図２
2010124269.tif 000002
【特許請求の範囲】
【請求項１】
動画ファイルを保持する動画サーバからネットワークおよびプロキシサーバを介して動画を受信する動画受信装置であって、
前記動画サーバから配信された画像およびＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）画面を表示する表示手段と、
前記ネットワークおよび前記プロキシサーバを介して前記動画サーバとの間でコマンドや画像データの送受信を行う通信手段と、
ユーザから所望する前記動画ファイルの再生要求を受け入れた際に、前記通信手段を介して前記動画サーバに対し、前記ユーザが所望する前記動画ファイルの一部を要求した際の前記動画サーバによる応答のヘッダを少なくとも要求する第１の動画要求コマンドを送信する第１のコマンド送信手段と、
前記第１のコマンド送信手段が送信した前記第１の動画要求コマンドに対応する前記動画サーバからの応答コマンドを分析し、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっているか否かを判断する判断手段と、
前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっているか否かを前記判断手段が判断した後に、前記通信手段を介して前記動画サーバに対し、前記ユーザが所望する前記動画ファイルを要求する第２の動画要求コマンドを送信する第２のコマンド送信手段と、を備え、
前記判断手段において、合致した応答コマンドになっていないと判断した場合には、前記ユーザが所望する前記動画ファイルの再生に際し、前記表示手段において、特殊再生操作が可能なＧＵＩ情報の画面表示をしないようにすることを特徴とする動画受信装置。
【請求項２】
前記判断手段において、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には特殊再生操作が不可能なＧＵＩ情報の送信を、合致した応答コマンドになっていると判断した場合には特殊再生操作が可能なＧＵＩ情報の送信を要求するＧＵＩ情報送信要求を、前記通信手段を介して前記動画サーバに対して送信するＧＵＩ要求手段を、さらに備えたことを特徴とする請求項１記載の動画受信装置。
【請求項３】
前記動画受信装置は、前記動画サーバから受信する動画に関連するＧＵＩ情報を保持するＧＵＩ情報保持手段をさらに備え、前記判断手段において、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には特殊再生操作が不可能なＧＵＩ情報を、合致した応答コマンドになっていると判断した場合には特殊再生操作が可能なＧＵＩ情報を、それぞれＧＵＩ情報保持手段から取り出し、前記表示手段において表示することを特徴とする請求項１記載の動画受信装置。
【請求項４】
前記通信手段における通信に用いられるプロトコルがＨＴＴＰ（Ｈｙｐｅｒ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）であって、前記第１の動画要求コマンドがＨＴＴＰ  ＨＥＡＤコマンドであることを特徴とする請求項１乃至３のいずれかに記載の動画受信装置。
【請求項５】
動画ファイルを保持する動画サーバからネットワークおよびプロキシサーバを介して動画を受信する動画受信装置における画面表示方法であって、
前記動画サーバから配信された画像およびＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）画面を表示する表示ステップと、
前記ネットワークおよび前記プロキシサーバを介して前記動画サーバとの間でコマンドや画像データの送受信を行う通信ステップと、
前記通信ステップにおいて、ユーザから所望する前記動画ファイルの再生要求を受け入れた際に、前記動画サーバに対し、前記ユーザが所望する前記動画ファイルの一部を要求した際の前記動画サーバによる応答のヘッダを少なくとも要求する第１の動画要求コマンドを送信する第１のコマンド送信ステップと、
前記第１のコマンド送信ステップにおいて送信した前記第１の動画要求コマンドに対応する前記動画サーバからの応答コマンドを分析し、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっているか否かを判断する判断ステップと、
前記判断ステップにおいて、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっているか否かを判断した後に、前記通信ステップにおいて、前記動画サーバに対し、前記ユーザが所望する前記動画ファイルを要求する第２の動画要求コマンドを送信する第２のコマンド送信ステップと、を備え、
前記判断ステップにおいて、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には、前記ユーザが所望する前記動画ファイルの再生に際し、前記表示ステップにおいて特殊再生操作が可能なＧＵＩ情報の画面表示をしないようにすることを特徴とする動画受信装置におけるＧＵＩ表示方法。
【請求項６】
前記判断ステップにおいて前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には、特殊再生操作が不可能なＧＵＩ情報の送信を、合致した応答コマンドになっていると判断した場合には、特殊再生操作が可能なＧＵＩ情報の送信を要求するＧＵＩ情報送信要求を前記動画サーバに対して送信するＧＵＩ要求ステップを、前記通信ステップにおいてさらに備えたことを特徴とする請求項５記載の動画受信装置におけるＧＵＩ表示方法。
【請求項７】
前記動画サーバから受信する動画に関連するＧＵＩ情報を保持するＧＵＩ情報保持ステップをさらに備え、前記判断ステップにおいて、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には、前記ＧＵＩ情報保持ステップにおいて保持した特殊再生操作が不可能なＧＵＩ情報を、合致した応答コマンドになっていると判断した場合には、前記ＧＵＩ情報保持ステップにおいて保持した特殊再生操作が可能なＧＵＩ情報を、それぞれ前記表示ステップにおいて表示することを特徴とする請求項５記載の動画受信装置におけるＧＵＩ表示方法。
【請求項８】
前記通信ステップにおける通信に用いられるプロトコルがＨＴＴＰ（Ｈｙｐｅｒ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）であって、前記第１の動画要求コマンドがＨＴＴＰ  ＨＥＡＤコマンドであることを特徴とする請求項５乃至７のいずれかに記載の動画受信装置におけるＧＵＩ表示方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを利用した動画配信サービスにおける動画受信装置（以下、受信装置と称す）、および受信装置におけるグラフィカルユーザインタフェース（ＧＵＩ：Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）の表示方法に関する。特に、動画サーバと受信装置の間にプロキシサーバが介在する場合の受信装置および特殊再生に関するＧＵＩ表示方法に関する。
【背景技術】
【０００２】
現在、インターネット等のネットワークを利用した動画配信サービスが普及し始めている。ネットワーク利用の動画配信において、特殊再生（早送り、巻き戻しおよびスキップ等）を行う場合、主に３種類の方法がとられている。第一の方法は、受信装置での動画再生に並行してその動画を受信装置に蓄積し、蓄積した範囲のみ特殊再生を実現する。第二の方法は、動画サーバにおいて通常再生用動画ファイルの他に特殊再生用の動画ファイルをいくつか用意し、受信装置が、必要に応じてそれら異なる動画ファイルのうちの一つにアクセスする。第三の方法は、受信装置が、動画サーバに対して、動画の中で特殊再生に必要な部分のみを送信するよう要求して、受信した特殊再生に必要な部分を再生するようにしており、早送りや巻き戻しなどの特殊再生においては、このような動作を繰り返す。また、第一から三の方法を組み合わせた方法もとられている。
【０００３】
上記第一から第三の方法における長所・欠点を考察すると、第一の方法は、受信装置が蓄積している範囲の特殊再生しか対応できないという欠点があるほか、受信装置に大きな記憶領域が必要となり、テレビ等の家電機器には不向きである。また、第二の方法は、受信装置において大きな記憶領域を確保する必要がなくなるが、動画サーバ側で記憶すべきファイルの数が増えてしまい、配信すべき動画の数が多い場合、大規模な記憶媒体が必要となるという欠点を有している。これに対して第三の方法は、受信装置が、動画サーバに対して、特殊再生に必要な部分のみを送信するように要求して再生するようにしているので、動画サーバおよび受信装置ともに、特殊再生に必要な記録媒体や記憶領域を確保する負担が非常に軽くなるという長所を有している。
【０００４】
一方、動画配信サービスにおいて活用されているプロトコルに目を向けると、動画サーバと受信装置との間で用いられるプロトコルにはいくつかあるが、近年では、非特許文献１に開示されているハイパーテキストトランスファープロトコル（ＨＴＴＰ：ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）が用いられることが多くなってきた。
【０００５】
ＨＴＴＰで上記第三の方法を用いて特殊再生を行う場合は、非特許文献１において定義されているＲａｎｇｅヘッダを用いる。例えば、今視聴している時点から３分先に動画をスキップさせる場合、受信装置は、動画サーバに対して、Ｒａｎｇｅヘッダに動画ファイルの３分後に相当するバイトから最後までと指定したＨＴＴＰリクエストを送信し、動画サーバは、動画ファイルのうち受信装置から指定されたバイト以降の部分を送信する。
【０００６】
ところが、動画サーバと受信装置との間にプロキシサーバが介在する場合、一部のプロキシサーバは、受信装置から送られたＨＴＴＰリクエストに含まれるＲａｎｇｅヘッダを削除して、動画サーバに送ってしまうことがある。その理由は、ウィルス対策等によるものである。プロキシサーバは、中継するファイルの先頭部分がウィルスを含んだ不正ファイルのパターンと一致するかどうかを調べることで、ウィルス検出を実現しているが、Ｒａｎｇｅヘッダを使って動画ファイルの一部分を取得するとウィルス検出の処理ができなくなってしまうため、受信装置から受信したＨＴＴＰリクエストのＲａｎｇｅヘッダを削除し、ファイル全体を要求するＨＴＴＰリクエストに変換して動画サーバに対して送信する。
【０００７】
プロキシサーバがこのような処理を行うと、受信装置において上記第三の方法、すなわち、動画ファイルの一部を次々と取得することで特殊再生を行おうとしても、常に動画の先頭からの通常再生しかできなくなってしまう。ところが一方では、ユーザには、早送り・巻き戻しボタンやスキップボタンといった特殊再生に関するＧＵＩが提示されることになる。このような場合、ユーザはこれらのＧＵＩを操作しても実際には特殊再生ができず、いらいら感や煩わしさを感じてしまうという課題があった。
【０００８】
このような課題を解決するために、特許文献１には、リモート操作端末装置（本発明の受信装置に相当）がデバイス（本発明の動画サーバに相当）の能力（特殊再生できるか等の能力）を含むデバイス情報を取得し、そのデバイス情報に基づいて当該デバイスを操作するためのＧＵＩを構築する方法が開示されている。
【特許文献１】特開２００７−１１４８８８号公報
【非特許文献１】Ｒ．Ｆｉｅｌｄｉｎｇ他著、"Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ−ＨＴＴＰ／１．１"、ＲＦＣ２６１６
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１に開示されている従来の方法では、受信装置にも動画サーバにも関係なくプロキシサーバがＲａｎｇｅヘッダを削除してしまう場合には対応できないという課題があった。すなわち、動画サーバと受信装置との間で事前にやりとりをしたとしても、受信装置は特殊再生が可能という判断をしてしまい、結果として、プロキシサーバがＲａｎｇｅヘッダを削除してしまうと、ユーザには再生不能の特殊再生用ＧＵＩが提供されることになるという課題を有していた。
【００１０】
本発明は、上記の課題に鑑みてなされたものであり、動画サーバと受信装置との間に介在するプロキシサーバが、Ｒａｎｇｅヘッダを削除する等により、画像ファイルの一部を要求するリクエストを画像ファイル全体を要求するリクエストに変換してしまうような場合においても、ユーザに対していらいら感や煩わしさを感じさせない、動画配信サービスにおける受信装置、および受信装置におけるＧＵＩ表示方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するために、本願の第１の発明の動画受信装置は、動画ファイルを保持する動画サーバからネットワークおよびプロキシサーバを介して動画を受信する動画受信装置であって、前記動画サーバから配信された画像およびＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）画面を表示する表示手段と、前記ネットワークおよび前記プロキシサーバを介して前記動画サーバとの間でコマンドや画像データの送受信を行う通信手段と、ユーザから所望する前記動画ファイルの再生要求を受け入れた際に、前記通信手段を介して前記動画サーバに対し、前記ユーザが所望する前記動画ファイルの一部を要求した際の前記動画サーバによる応答のヘッダを少なくとも要求する第１の動画要求コマンドを送信する第１のコマンド送信手段と、前記第１のコマンド送信手段が送信した前記第１の動画要求コマンドに対応する前記動画サーバからの応答コマンドを分析し、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっているか否かを判断する判断手段と、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっているか否かを前記判断手段が判断した後に、前記通信手段を介して前記動画サーバに対し、前記ユーザが所望する前記動画ファイルを要求する第２の動画要求コマンドを送信する第２のコマンド送信手段と、を備え、前記判断手段において、合致した応答コマンドになっていないと判断した場合には、前記ユーザが所望する前記動画ファイルの再生に際し、前記表示手段において、特殊再生操作が可能なＧＵＩ情報の画面表示をしないようにすることを特徴とするものである。
【００１２】
また、本願の第２の発明の動画受信装置は、本願の第１の発明の動画受信装置において、前記判断手段において、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には特殊再生操作が不可能なＧＵＩ情報の送信を、合致した応答コマンドになっていると判断した場合には特殊再生操作が可能なＧＵＩ情報の送信を要求するＧＵＩ情報送信要求を、前記通信手段を介して前記動画サーバに対して送信するＧＵＩ要求手段を、さらに備えたことを特徴とするものである。
【００１３】
また、本願の第３の発明の動画受信装置は、本願の第１の発明の動画受信装置において、前記動画受信装置は、前記動画サーバから受信する動画に関連するＧＵＩ情報を保持するＧＵＩ情報保持手段をさらに備え、前記判断手段において、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には特殊再生操作が不可能なＧＵＩ情報を、合致した応答コマンドになっていると判断した場合には特殊再生操作が可能なＧＵＩ情報を、それぞれＧＵＩ情報保持手段から取り出し、前記表示手段において表示することを特徴とするものである。
【００１４】
また、本願の第４の発明の動画受信装置は、本願の第１乃至第３の発明の動画受信装置のいずれかにおいて、前記通信手段における通信に用いられるプロトコルがＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）であって、前記第１の動画要求コマンドがＨＴＴＰ  ＨＥＡＤコマンドであることを特徴とするものである。
【００１５】
また、本願の第５の発明の動画受信装置におけるＧＵＩ表示方法は、動画ファイルを保持する動画サーバからネットワークおよびプロキシサーバを介して動画を受信する動画受信装置における画面表示方法であって、前記動画サーバから配信された画像およびＧＵＩ画面を表示する表示ステップと、前記ネットワークおよび前記プロキシサーバを介して前記動画サーバとの間でコマンドや画像データの送受信を行う通信ステップと、前記通信ステップにおいて、ユーザから所望する前記動画ファイルの再生要求を受け入れた際に、前記動画サーバに対し、前記ユーザが所望する前記動画ファイルの一部を要求した際の前記動画サーバによる応答のヘッダを少なくとも要求する第１の動画要求コマンドを送信する第１のコマンド送信ステップと、前記第１のコマンド送信ステップにおいて送信した前記第１の動画要求コマンドに対応する前記動画サーバからの応答コマンドを分析し、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっているか否かを判断する判断ステップと、前記判断ステップにおいて、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっているか否かを判断した後に、前記通信ステップにおいて、前記動画サーバに対し、前記ユーザが所望する前記動画ファイルの全部を要求する第２の動画要求コマンドを送信する第２のコマンド送信ステップと、を備え、前記判断ステップにおいて、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には、前記ユーザが所望する前記動画ファイルの再生に際し、前記表示ステップにおいて特殊再生操作が可能なＧＵＩ情報の画面表示をしないようにすることを特徴とするものである。
【００１６】
また、本願の第６の発明の動画受信装置におけるＧＵＩ表示方法は、本願の第５の発明の動画受信装置におけるＧＵＩ表示方法において、前記判断ステップにおいて前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には、特殊再生操作が不可能なＧＵＩ情報の送信を、合致した応答コマンドになっていると判断した場合には、特殊再生操作が可能なＧＵＩ情報の送信を要求するＧＵＩ情報送信要求を前記動画サーバに対して送信するＧＵＩ要求ステップを、前記通信ステップにおいてさらに備えたことを特徴とするものである。
【００１７】
また、本願の第７の発明の動画受信装置におけるＧＵＩ表示方法は、本願の第５の発明の動画受信装置におけるＧＵＩ表示方法において、前記動画サーバから受信する動画に関連するＧＵＩ情報を保持するＧＵＩ情報保持ステップをさらに備え、前記判断ステップにおいて、前記応答コマンドが前記第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には、前記ＧＵＩ情報保持ステップにおいて保持した特殊再生操作が不可能なＧＵＩ情報を、合致した応答コマンドになっていると判断した場合には、前記ＧＵＩ情報保持ステップにおいて保持した特殊再生操作が可能なＧＵＩ情報を、それぞれ前記表示ステップにおいて表示することを特徴とするものである。
【００１８】
また、本願の第８の発明の動画受信装置におけるＧＵＩ表示方法は、本願の第５から第７の発明の動画受信装置におけるＧＵＩ表示方法において、前記通信ステップにおける通信に用いられるプロトコルがＨＴＴＰ（Ｈｙｐｅｒ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）であって、前記第１の動画要求コマンドがＨＴＴＰ  ＨＥＡＤコマンドであることを特徴とするものである。
【発明の効果】
【００１９】
本発明によれば、動画受信装置は、通常の動画要求と同じ動作がプロキシサーバにおいてなされるリクエスト、例えば、ＨＴＴＰにおけるＨＥＡＤリクエストのようなリクエストを、プロキシサーバに対して事前に送信するので、動画ファイルの一部を取得するリクエストがプロキシサーバ経由で要求通り動画サーバに届くか、すなわち、特殊再生が可能か否かを事前に知ることができる。このことにより、動画受信装置がプロキシサーバを介して動画サーバにアクセスする際に、プロキシサーバが動画ファイルの一部を要求するリクエストを動画ファイル全体を要求するリクエストに変換してしまう、すなわち、特殊再生が不可能な状況になっている場合には、特殊再生操作が可能なＧＵＩ画面の表示をしないようにすることが可能となり、ユーザのいらいら感や煩わしさをなくすことができる。
【発明を実施するための最良の形態】
【００２０】
以下に、本発明を実施するための最良の形態について、図面を参照しながら説明する。
【００２１】
（実施の形態１）
本発明に係る動画受信装置（以下、受信装置と称す）は、例えば、ネットワークインタフェースを持ち、インターネット上の動画サーバから、ＨＴＴＰを用いた動画配信サービスを受けることが可能なテレビジョン受像機（以下、テレビと略す）として実現することができる。また、本発明に係るＧＵＩ画面表示方法は、上記テレビの画面上に表示される動画配信サービスのＧＵＩ画面として実現できる。なお、このＧＵＩ画面を実現するプログラムは、上記テレビ内にあらかじめインストールされていてもよいし、上記動画サーバから上記テレビへ都度送信されてもよい。
【００２２】
図１は、本発明の実施の形態１に係る受信装置が、プロキシサーバおよびインターネットなどを介して動画サーバと接続される構成の一例を示す図である。
【００２３】
図１において、動画サーバ１は、動画蓄積手段１０１に記録されている動画ファイルを、受信装置３からの要求に応じてインターネット４上に送信する。また、動画サーバ１は、ＧＵＩ蓄積手段１０２に記録されているＧＵＩプログラムを、受信装置３からの要求に応じてインターネット４上へ送信する。ＧＵＩ蓄積手段１０２には、少なくとも、特殊再生用のＧＵＩを含むＧＵＩプログラムと、特殊再生用のＧＵＩを含まないＧＵＩプログラムの両方が記録されている。
【００２４】
受信装置３は、動画ファイルまたはＧＵＩプログラムの送信を要求するリクエストをネットワーク５へ送信し、その応答として、動画サーバから送信された動画ファイルまたはＧＵＩプログラム（ＧＵＩ情報）を受信する。
【００２５】
動画サーバ１と受信装置３の間でやりとりされるすべての情報（リクエスト、動画ファイルおよびＧＵＩプログラムなど）は、プロキシサーバ２を経由する。プロキシサーバ２は、動画サーバ１を含むインターネット４上の各サーバ（動画サーバ１、およびサーバ６１〜サーバ６ｎ）との間で、受信装置３の代理として送受信を行う。
【００２６】
ネットワーク５の例としては、インターネット４の一部を構成するネットワークである場合の他に、企業内のイントラネットワークである場合や、インターネットサービスプロバイダ（ＩＳＰ：Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  ｐｒｏｖｉｄｅｒ）が提供する各家庭とＩＳＰの局舎を結ぶネットワークの場合などがある。
【００２７】
次に、図２を用いて、受信装置の構成とその動作について説明する。なお、図２は、本発明の実施の形態１に係る受信装置の構成を示すブロック図である。
【００２８】
図２において、受信装置３は、通信手段２１、画像復号手段２２、表示手段２３、判断手段２４、ＧＵＩ要求手段２５、第１のコマンド送信手段２６と第２のコマンド送信手段２７で構成されるコマンド送信手段２８、操作入力手段２９、および受信装置３の全体を制御する制御手段３０で構成されている。
【００２９】
通信手段２１は、ネットワーク５、プロキシサーバ２およびネットワーク４を介して動画サーバ１との間でコマンドや画像データなどの送受信を行う。通信手段２１において受信された画像データやＧＵＩ情報などは画像復号手段２２において復号され、その復号された画像やＧＵＩ情報などは表示手段２３に送信され表示される。
【００３０】
ユーザからの動画ファイルの再生要求などを受け入れる操作入力手段２９において、ユーザから所望する動画ファイルの再生要求を受け入れた際に、第１のコマンド送信手段２６は、ユーザが所望する動画ファイルの一部を要求した際の動画サーバ１による応答のヘッダを少なくとも要求する第１の動画要求コマンドを、通信手段２１を介し動画サーバ１に対して送信する。
【００３１】
判断手段２４は、第１のコマンド送信手段２６が送信した第１の動画要求コマンドに対応して動画サーバ１から送信された応答コマンドを、通信手段２１を介して受信して分析し、その受信した応答コマンドが第１の動画要求コマンドに合致した応答コマンドになっているか否かを判断する。
【００３２】
第２のコマンド送信手段２７は、動画サーバ１からの応答コマンドが第１の動画要求コマンドに合致した応答コマンドになっているか否かを判断手段２４が判断した後に、通信手段２１を介して動画サーバ１に対し、ユーザが所望する動画ファイルを要求する第２の動画要求コマンドを送信する。
【００３３】
ＧＵＩ要求手段２５は、判断手段２４が、動画サーバ１からの応答コマンドが第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には特殊再生操作が不可能なＧＵＩ情報の送信を、合致した応答コマンドになっていると判断した場合には特殊再生操作が可能なＧＵＩ情報の送信を要求するＧＵＩ情報送信要求を、通信手段２１を介して動画サーバ１に対して送信する。ＧＵＩ要求手段２５からのＧＵＩ情報送信要求に対応して動画サーバ１から送信されたＧＵＩ情報は、通信手段２１で受信されて画像復号手段２２で処理された後、表示手段２３において表示される。
【００３４】
以上のように構成することにより、判断手段２４において、動画サーバ１からの応答コマンドが第１の動画要求コマンドに合致した応答コマンドになっていないと判断した場合には、すなわち、特殊再生が不可能な状況においては、ユーザが所望する動画ファイルの再生に際し、表示手段２３において特殊再生操作が可能なＧＵＩ情報の画面表示をしないようにすることが可能となる。
【００３５】
なお、以上の説明においては、ＧＵＩ情報（ＧＵＩプログラム）は動画サーバ１に記録されているものとしたが、これに限るものではなく、例えば、受信装置３がＧＵＩ情報保持手段（図示せず）を備え、このＧＵＩ情報保持手段にＧＵＩ情報をあらかじめ保持するようにしてもよい。この場合は、ネットワーク４、５における伝送遅延がなくなるので、受信装置３の表示手段２３にＧＵＩが表示されるまでの時間が短縮される。
【００３６】
また、以上の説明においては、第１のコマンド送信手段２６と第２のコマンド送信手段２７は独立した別々の手段としたが、これに限るものではなく、例えば、第１のコマンド送信手段２６および第２のコマンド送信手段２７の機能を備えた１つのコマンド送信手段２８としてもよい。
【００３７】
次に、図３、図４および図５を用いて、動画サーバ１、プロキシサーバ２および受信装置３の間でのデータや情報のやり取りの具体例について説明する。なお、図３は、本発明の実施の形態１における動画サーバ、プロキシサーバおよび受信装置の間のやりとりのシーケンスの一例を示す図であり、図３においては、プロキシサーバ２は、受信装置３から動画サーバ１に対する動画ファイルの一部を要求するリクエストを、動画ファイル全体を要求するリクエストに変換する例を示す。また、図４は、本発明の実施の形態１における動画サーバ、プロキシサーバおよび受信装置の間でやりとりされるＨＴＴＰメッセージの一例を示す図であり、図５は、本発明の実施の形態１におけるＧＵＩ画面の一例を示す図である。
【００３８】
図５において、ここでは、受信装置３の表示手段２３における表示画面には、図５の（イ）に示されるＧＵＩが表示されていることを前提として説明する。なお、図５の（イ）は、動画の紹介画面である。図５の（イ）において、動画紹介記述４１は、動画サーバ１が提供するそれぞれの動画の紹介を行う記述（例えば、タイトルやおすすめ度等）である。
【００３９】
ユーザが、例えば、操作入力手段２９の１つであるリモコンの上下左右キーを使って、複数ある動画紹介記述４１の一つに画面上のカーソルを置くと、受信装置３の表示手段２３における表示画面に表示されているＧＵＩ画面には、カーソルが置かれた動画紹介記述４１に対応する動画の代表静止画４２と動画に関する詳細データ４３（例えば、出演者名、あらすじおよび上映時間等）が表示される。ユーザが、代表静止画４２と動画に関する詳細なデータ４３を基にして所望の動画を選択し、リモコンの決定キーを押すと、受信装置３の表示画面に表示されているＧＵＩが図５の（イ）から図５の（ロ）または図４の（ハ）に変わり、その時に代表画像が表示されている動画、すなわち、ユーザが所望／選択した動画の再生が開始される。なお、図５の（ロ）と図５の（ハ）の表示画面の違いは、特殊再生（スキップ４４、早送り４７および巻き戻し４５）ボタンがあるかないかの違いだけである。
【００４０】
図３において、受信装置３の操作入力手段２９がユーザから動画の再生要求を受けた（図３の（ａ））とき（表示手段２３の表示画面の表示が、図５の（イ）から図５の（ロ）または（ハ）へ遷移するとき）、受信装置３の第１のコマンド送信手段２６は、その動画のアドレスを指定し、動画ファイルの一部だけを指定したＨＴＴＰ  ＨＥＡＤリクエスト（第１の動画要求コマンド）を、プロキシサーバ２に対して通信手段２１を介して送信する（図３の（１））。図４の（１）がそのリクエストの内容であり、例として、動画サーバ１のアドレスは、videoserver.sample、動画のアドレスは、/data/video001.mp4とし、Ｒａｎｇｅヘッダを使って、その動画ファイルの最初の１００バイトを指定している。
【００４１】
受信装置３から図４の（１）に示すリクエストを受信したプロキシサーバ２は、図４の（１）に示されるリクエストからＲａｎｇｅヘッダを取り除いた図４の（２）に示されるＨＴＴＰ  ＨＥＡＤリクエストを、動画サーバ１に対して送信する（図３の（２））。プロキシサーバ２から図４の（２）に示されるリクエストを受信した動画サーバ１は、指定された動画ファイル全体を返すためのＨＴＴＰレスポンスのうち、図４の（３）に示されるヘッダ部分のみをプロキシサーバ２に返信し、プロキシサーバ２はこれを受信装置３に中継する（図３の（３））。
【００４２】
受信装置３の判断手段２４は、第１のコマンド送信手段２６から送信／要求したＨＴＴＰ  ＨＥＡＤリクエストと、要求したリクエストに対応した動画サーバ１からのレスポンスとしてプロキシサーバ２から受信したＨＴＴＰレスポンスをみて、特殊再生に対応できないと判断する。受信装置３は、特殊再生に対応できないと判断すると、プロキシサーバ２に対して、図５の（ハ）に示される特殊再生用ボタン（スキップ、早送り、巻き戻し）のないＧＵＩ画面を表示するためのＧＵＩプログラム（/data/notrickplay.js）を要求するために、図４の（４）に示されるＨＴＴＰ  ＧＥＴリクエストを送信し、プロキシサーバ２はそれを動画サーバ１に中継する（図３の（４））。
【００４３】
動画サーバ１は、プロキシサーバ２経由で受信装置３から指定されたＧＵＩプログラムを運ぶＨＴＴＰレスポンス（図４の（５）参照）を生成し、プロキシサーバ２経由で受信装置３に送信する（図３の（５））。受信装置３は、受信手段２１において、プロキシサーバ２経由で動画サーバ１から受信したＧＵＩプログラムを使って、図５の（ハ）に示される特殊再生用ボタンのないＧＵＩ画面を表示手段２３に表示する（図３の（ｂ））とともに、動画ファイルの全部の取得を要求するＨＴＴＰ  ＧＥＴリクエスト（第２の動画要求コマンド、図４の（６）参照）をプロキシサーバ２経由で動画サーバ１に送信する（図３の（６））。動画サーバ１は、受信装置３の第２のコマンド送信手段２７から送信／指定された動画ファイルを運ぶＨＴＴＰレスポンス（図４の（７）参照）を生成し、プロキシサーバ２経由で受信装置３に送信する（図３の（７））。受信装置３は、プロキシサーバ２経由で動画サーバ１から受信した動画の再生を開始する（図３の（ｃ））。
【００４４】
次に、図６および図７を用いて、動画サーバ１、プロキシサーバ２および受信装置３の間でのデータや情報のやり取りに関する他の具体例について説明する。なお、図６は、本発明の実施の形態１における動画サーバ、プロキシサーバおよび受信装置の間のやりとりのシーケンスの他の例を示す図であり、図６においては、プロキシサーバ２は、受信装置３から動画サーバ１に対する動画ファイルの一部を要求するリクエストを、動画ファイル全体を要求するリクエストに変換しない例を示す。また、図７は、本発明の実施の形態１における動画サーバ、プロキシサーバおよび受信装置の間でやりとりされるＨＴＴＰメッセージの他の例を示す図である。
【００４５】
図５において、図２の場合と同様、受信装置３の表示手段２３における表示画面には、あらかじめ、図５の（イ）に示されるＧＵＩが表示されているものとして説明する。受信装置３の操作入力手段２９がユーザからの動画の再生要求を受けた（図６の（ａ））とき（表示手段２３の表示画面の表示が図５の（イ）から図５の（ロ）または（ハ）へ遷移するとき）、受信装置３の第１のコマンド送信手段２６は、ユーザから再生要求を受けた動画のアドレスを指定し、動画ファイルの一部だけを指定したＨＴＴＰ  ＨＥＡＤリクエスト（第１の動画要求コマンド、図７の（１）参照）をプロキシサーバ２に対して送信するが、図３に示す場合と異なり、プロキシサーバ２は、この受信装置３からのリクエストからＲａｎｇｅヘッダを取り除かずに、動画サーバ１に送信する（図６の（１））。
【００４６】
動画サーバ１は、プロキシサーバ２経由で受信装置３から指定された動画の一部を返すためのＨＴＴＰレスポンスのうち、ヘッダ部分のみ（図７の（２）参照）をプロキシサーバ２に返信し、プロキシサーバ２はこれを受信装置３に中継する（図６の（２））。この時のＨＴＴＰレスポンスのステータスコードは、図３に示す場合と異なり、図７の（２）に示すように２０６となる。
【００４７】
受信装置３の判断手段２４は、第１のコマンド送信手段２６から送信／要求したＨＴＴＰ  ＨＥＡＤリクエストと、要求したリクエストに対応した動画サーバ１からのレスポンスとしてプロキシサーバ２から受信したＨＴＴＰレスポンスをみて、特殊再生に対応できると判断する。受信装置３のＧＵＩ要求手段２５は、判断手段２４が特殊再生に対応できる判断すると、特殊再生用ボタン（スキップ、早送り、巻き戻し）があるＧＵＩ画面（図５の（ロ）参照）を表示するためのＧＵＩプログラム（/data/trickplay.js）を要求するためのＨＴＴＰ  ＧＥＴリクエスト（図６の（３）参照）を送信し、プロキシサーバ２はそれを動画サーバ１に中継する（図６の（３））。
【００４８】
動画サーバ１は、プロキシサーバ２経由で受信装置３から指定されたＧＵＩプログラムを運ぶＨＴＴＰレスポンス（図７の（４）参照）を生成し、プロキシサーバ２経由で受信装置３に送信する（図６の（４））。受信装置３は、受信したＧＵＩプログラムを使って、特殊再生用ボタンのあるＧＵＩ画面（図５の（ロ）参照）を表示手段２３に表示する（図６の（ｂ））とともに、第２のコマンド送信手段は、動画ファイルの全部の取得を要求するＨＴＴＰ  ＧＥＴリクエスト（第２の動画要求コマンド、図６の（５）参照）をプロキシサーバ２経由で動画サーバ１に送信する（図６の（５））。動画サーバ１は、受信装置３から指定された動画ファイルを運ぶＨＴＴＰレスポンス（図７の（６）参照）を生成し、プロキシサーバ２経由で受信装置３に送信する（図６の（６））。受信装置３は、プロキシサーバ２経由で動画サーバ１から受信した動画の再生を開始する（図６のｃ）。
【００４９】
ここで、動画サーバ１、プロキシサーバ２および受信装置３の間での動画の特殊再生に関するデータや情報のやり取りについて説明する。
【００５０】
図５の（ロ）に示す画面では、動画の特殊再生が可能である。例えば、スキップなら、スキップボタン４４が押下されたら３０秒先から再生を行うといったことが可能になる。また、巻き戻し、早送り、あるいは一時停止を行う場合は、ユーザがそれぞれ巻き戻しボタン４５、早送りボタン４７、あるいは一時停止ボタン４６を押下することにより可能となる。また、現在の再生位置やトータルの時間などを表示するために、現在の再生位置をアナログ的に表示するためのバーである再生位置表示バー４８と、再生経過時間とトータル再生時間をデジタル的に表示するためのテキストである再生経過時間とトータル再生時間を表すテキスト４９が設けられている。
【００５１】
動画再生中にユーザからの特殊再生入力を取得した（図６の（ｄ））場合、例えば、ユーザからスキップボタンの押下を受けた場合、受信装置３は、スキップ先が動画ファイルの何バイト目に相当するかを計算する。この計算は、現在の再生位置、動画のビットレートおよびスキップする秒数（本発明の実施の形態１では、例えば３０秒）を使って計算することが可能であるし、また、受信装置３が、あらかじめその動画に関するスキップする秒数とスキップ先のバイト数の表を持っておくことで可能になる。
【００５２】
スキップ先のバイト数（例えば、１００００バイト）が確定する（図６の（ｅ））と、受信装置３は、Ｒａｎｇｅヘッダに１００００バイト目以降を指定したＨＴＴＰ  ＧＥＴリクエスト（図７の（７）参照）を、プロキシサーバ２経由で動画サーバ１に送信する（図６の（７））。動画サーバ１は、受信装置３から指定された動画ファイルの１００００バイト以降を運ぶＨＴＴＰレスポンス（図７の（８）参照）を生成し、プロキシサーバ２経由で受信装置３に送信する（図６の（８））。受信装置３は、プロキシサーバ２経由で動画サーバ１から受信した動画の再生を開始する（図５の（ｆ））。
【００５３】
以上のように、本発明の実施の形態１によれば、受信装置３が、ＧＵＩプログラムを取得する前に、動画サーバ１に対してＨＴＴＰ  ＨＥＡＤリクエストを送信するので、受信装置３は、動画ファイルの一部を取得するリクエストが要求通り動画サーバに届くか否か、すなわち、特殊再生が可能か否かを事前に知ることができる。このことにより、受信装置３がプロキシサーバ２を介して動画サーバ１にアクセスする場合、プロキシサーバ２が、動画ファイルの一部を要求するリクエストを、動画ファイル全体を要求するリクエストに変換してしまったとしても、受信装置３は、特殊再生に関するＧＵＩを除いたＧＵＩを表示することが可能となり、ユーザがいらいら感や煩わしさを感じることをなくすことができる。
【００５４】
なお、本発明の実施の形態１では、特殊再生用ボタンがあるかないかで、ＧＵＩプログラムを分ける場合を例に挙げたが、これに限るものではなく、例えば、同一プログラムの中の条件分岐等で、特殊再生用ボタンの表示、非表示を変えるようにしてもよい。
【００５５】
また、本発明は、本発明の実施の形態１における各手段を備える動画受信装置として提供できるばかりでなく、動画受信装置が具備する各手段を各ステップとする動画受信装置におけるＧＵＩ表示方法、および、その動画受信装置におけるＧＵＩ表示方法をコンピュータに実行させるＧＵＩ表示プログラムを提供することも可能である。
【産業上の利用可能性】
【００５６】
本発明に係る動画受信装置および動画受信装置におけるＧＵＩ表示方法は、プロキシサーバを介してインターネット上の動画配信サーバから動画を受信する動画受信装置に適用することができ、特に、ＨＴＴＰを用いて動画配信サービスが行われる際に、ＨＴＴＰのＲａｎｇｅヘッダを用いて特殊再生を実現する場合の動画受信装置および動画受信装置におけるＧＵＩ表示に適用することができる。
【図面の簡単な説明】
【００５７】
【図１】本発明の実施の形態１に係る受信装置が、プロキシサーバおよびインターネットなどを介して動画サーバと接続される構成の一例を示す図
【図２】本発明の実施の形態１に係る受信装置の構成を示すブロック図
【図３】本発明の実施の形態１における動画サーバ、プロキシサーバおよび受信装置の間のやりとりのシーケンスの一例を示す図
【図４】本発明の実施の形態１における動画サーバ、プロキシサーバおよび受信装置の間でやりとりされるＨＴＴＰメッセージの一例を示す図
【図５】本発明の実施の形態１におけるＧＵＩ画面の一例を示す図
【図６】本発明の実施の形態１における動画サーバ、プロキシサーバおよび受信装置の間のやりとりのシーケンスの他の例を示す図
【図７】本発明の実施の形態１における動画サーバ、プロキシサーバおよび受信装置の間でやりとりされるＨＴＴＰメッセージの他の例を示す図
【符号の説明】
【００５８】
１  動画サーバ
２  プロキシサーバ
３  動画受信装置
４  インターネット
５  ネットワーク
２１  通信手段
２２  画像復号手段
２３  表示手段
２４  判断手段
２５  ＧＵＩ要求手段
２６  第１のコマンド送信手段
２７  第２のコマンド送信手段
２８  コマンド送信手段
２９  操作入力手段
３０  制御手段
４１  動画紹介記述
４２  代表静止画
４３  動画に関する詳細データ
４４  スキップボタン
４５  巻き戻しボタン
４６  一時停止ボタン
４７  早送りボタン
４８  再生位置表示バー
４９  再生経過時間とトータル再生時間を表すテキスト
６１〜６ｎ  インターネット上のサーバ
１０１  動画蓄積手段
１０２  ＧＵＩ蓄積手段
【図２】
2010124269.tif 000003
【図３】
2010124269.tif 000004
【図４】
2010124269.tif 000005
【図５】
2010124269.tif 000006
【図６】
2010124269.tif 000007
【図７】
2010124269.tif 000008
【図１】
2010124269.tif 000009