配信方法、配信装置、再生装置、配信システム、配信プログラム
【課題】コンテンツの送受信以外のネットワーク通信を不要としながらも、コンテンツを連続再生する技術を提供する。
【解決手段】ＨＴＴＰリクエスト受信部２８は、ネットワークを介して接続された再生装置１２から、当該再生装置において再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を受けつける。配信用生成部２４は、受けつけたＨＴＴＰコンテンツ要求に含まれたアドレスをもとに、第１記憶部２０に記憶された第１のデータを取得する。追加部２６は、再生装置１２が取得可能な第２のデータのアドレスも取得する。ＨＴＴＰレスポンス送信部３０は、取得した第１のデータと、第２のデータのアドレスとが含まれたＨＴＴＰコンテンツ応答を再生装置１２へ出力する。
【解決手段】ＨＴＴＰリクエスト受信部２８は、ネットワークを介して接続された再生装置１２から、当該再生装置において再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を受けつける。配信用生成部２４は、受けつけたＨＴＴＰコンテンツ要求に含まれたアドレスをもとに、第１記憶部２０に記憶された第１のデータを取得する。追加部２６は、再生装置１２が取得可能な第２のデータのアドレスも取得する。ＨＴＴＰレスポンス送信部３０は、取得した第１のデータと、第２のデータのアドレスとが含まれたＨＴＴＰコンテンツ応答を再生装置１２へ出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信技術に関し、特にデータを配信する配信方法、配信装置、再生装置、配信システム、配信プログラムに関する。
【背景技術】
【０００２】
ＡＶ（Ａｕｄｉｏ Ｖｉｓｕａｌ）家電のホームネットワーク化に伴って、ホームネットワークサーバに併設されたテレビジョン受像装置（以下、「ＴＶ」という）だけでなく、別部屋のＴＶでも、ホームネットワークサーバに記憶されたコンテンツが視聴可能になる。例えば、ホームネットワークサーバは、動画データ、写真データ、音楽データなどのデジタルコンテンツを記憶する。また、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｒａｎｓｆｅｒ Ｔｅｘｔ Ｐｒｏｔｏｃｏｌ）やＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ＆ Ｐｌａｙ）をベースにしたＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）ガイドラインの策定により、ホームネットワークシステムの普及が進んでいる。それとともに、コンテンツのネットワーク再生として、単一のコンテンツ再生だけでなく、商品価値の高いデジタル写真のスライドショー、音楽のアルバム再生などのコンテンツ連続再生機能が必要とされる。また、テープメディアからハードディスクなどに記録媒体が変わりつつある家庭用ビデオレコーダやビデオカメラでは、１回の録画ごとに動画ファイルが作成されるので、ユーザの利便性を向上するために、複数の動画ファイルの連続再生が必要になる。
【０００３】
一方、上記のガイドラインでは、ホームネットワークサーバに記憶されたコンテンツに対する再生に必要な情報や属性情報が、コンテンツ単位にクライアントに予め提供されている。クライアントは、その情報をもとにＨＴＴＰによるネットワーク再生を実施する。このように、ホームネットワークサーバが、複数のコンテンツの再生順序、時間、再生のために必要な情報などを予めプレイリストとして作成し、クライアントに提供することによって、複数のコンテンツの連続再生が可能にされている（例えば、特許文献１参照）。この場合、次に再生するコンテンツのメタ情報を現在再生中のコンテンツ再生終了前に取得するための特殊なネットワーク送受信処理とその機能がクライアントに必要とされる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−１５２６７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
プレイリストを使用する場合、コンテンツの連続再生の前に、プレイリスト自身のネットワーク送受信処理、プレイリストの解析機能およびその内容を保持するためのメモリが必要になる。また、プレイリストに含まれるコンテンツの数や各種情報の増加によって、クライアントにおけるプレイリスト使用の負担が増加する。そのため、特開２００８−１６５６５６号公報では、すべての連続再生コンテンツ情報をクライアントに予め提供する代わりに、クライアントが、次に再生すべきコンテンツのメタ情報を現在再生中のコンテンツ再生終了前に取得する。その結果、クライアントは、逐次処理により連続再生コンテンツの情報を保持することなく、連続再生を実現する。この場合においても、次に再生するコンテンツのメタ情報を現在再生中のコンテンツ再生終了前に取得するための特殊なネットワーク送受信処理とその機能がクライアントに必要とされる。
【０００６】
本発明はこうした状況に鑑みてなされたものであり、その目的は、コンテンツの送受信以外のネットワーク通信を不要としながらも、コンテンツを連続再生する技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様の配信方法は、ネットワークを介して接続された再生装置から、当該再生装置において再生が要求されている第１のデータのアドレスを受けつけるステップと、受けつけたアドレスをもとに、記憶媒体に記憶された第１のデータを取得するとともに、再生装置が取得可能な第１のデータとは別のデータである第２のデータのアドレスも取得するステップと、取得した第１のデータと、第２のデータのアドレスとを一体的に組み合わせて出力するステップと、を備える。
【０００８】
この態様によると、要求に応じて第１のデータを送信する際に、第２のデータのアドレスも一体的に送信するので、データの送受信以外のネットワーク通信を不要としながらも、第２のデータのアドレスを通知できる。
【０００９】
出力するステップは、ヘッダと、取得した第１のデータとを組み合わせたフレームを出力しており、第２のデータのアドレスをヘッダに含めてもよい。この場合、第２のデータのアドレスをヘッダに含めるので、ヘッダのみを出力することによっても、第２のデータのアドレスを通知できる。
【００１０】
取得するステップは、再生装置が取得可能な第２のデータの属性情報も取得し、出力するステップは、第２のデータのアドレスとともに、第２のデータの属性情報も出力してもよい。この場合、第２のデータのアドレスとともに、第２のデータの属性情報も出力するので、第２のデータの属性情報を通知できる。
【００１１】
本発明の別の態様は、配信装置である。この装置は、ネットワークを介して接続された再生装置から、当該再生装置において再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を受けつける受付部と、受付部において受けつけたＨＴＴＰコンテンツ要求に含まれたアドレスをもとに、記憶媒体に記憶された第１のデータを取得するとともに、再生装置が取得可能な第１のデータとは別のデータである第２のデータのアドレスも取得する取得部と、取得部において取得した第１のデータを、ＨＴＴＰコンテンツ要求に対するＨＴＴＰコンテンツ応答として再生装置へ出力する際に、ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに、取得した第２のデータのアドレスを含めて出力する出力部と、を備える。
【００１２】
この態様によると、要求に応じて第１のデータを送信する際に、第２のデータのアドレスも一体的に送信するので、データの送受信以外のネットワーク通信を不要としながらも、第２のデータのアドレスを通知できる。
【００１３】
本発明のさらに別の態様は、再生装置である。この装置は、ネットワークを介して接続された配信装置へ、再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を出力する出力部と、出力部がＨＴＴＰコンテンツ要求を出力した配信装置から、アドレスに対応した第１のデータが含まれたＨＴＴＰコンテンツ応答を受けつける受付部と、受付部において受けつけたＨＴＴＰコンテンツ応答に含まれた第１のデータを再生するとともに、ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに含まれている、取得可能な第１のデータとは別のデータである第２のデータのアドレスを取得する再生部とを備える。出力部は、新たなＨＴＴＰコンテンツ要求に、第２のデータのアドレスを含める。
【００１４】
この態様によると、要求に応じた第１のデータを受信する際に、第２のデータのアドレスも一体的に受信するので、データの送受信以外のネットワーク通信を不要としながらも、第２のデータのアドレスを取得できる。
【００１５】
本発明のさらに別の態様は、配信システムである。この配信システムは、ネットワークを介して、再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を出力する再生装置と、受けつけたＨＴＴＰコンテンツ要求に含まれたアドレスをもとに、記憶媒体に記憶された第１のデータを取得した後、第１のデータをＨＴＴＰコンテンツ要求に対するＨＴＴＰコンテンツ応答として再生装置へ出力する際に、ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに、取得した第１のデータとは別のデータである第２のデータのアドレスを含めて出力する配信装置とを備える。再生装置は、受けつけたＨＴＴＰコンテンツ応答に含まれた第１のデータを再生するとともに、新たなＨＴＴＰコンテンツ要求に、取得可能な第２のデータのアドレスを含める。
【００１６】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１７】
本発明によれば、コンテンツの送受信以外のネットワーク通信を不要としながらも、コンテンツを連続再生できる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施例に係る再生システムの構成を示す図である。
【図２】図２（ａ）−（ｂ）は、図１の再生システムにおいて使用されるＨＴＴＰリクエストとＨＴＴＰレスポンスの一例を示す図である。
【図３】図１の第２記憶部に記憶された連続再生コンテンツグループの情報が示されたテーブルのデータ構造を示す図である。
【図４】図１の表示部に表示されたコンテンツ選択画面を示す図である。
【図５】図１の配信装置におけるコンテンツの送信手順を示すフローチャートである。
【図６】図１の再生装置におけるコンテンツの再生手順を示すフローチャートである。
【図７】本発明の変形例に係る再生システムにおいて使用されるＨＴＴＰレスポンスの一例を示す図である。
【図８】本発明の変形例に係る表示部に表示されたコンテンツ選択画面を示す図である。
【発明を実施するための形態】
【００１９】
本発明を具体的に説明する前に、まず概要を述べる。本発明の実施例は、ネットワークを介して互いに接続された配信装置と再生装置によって形成され、配信装置がコンテンツを送信するとともに、再生装置がコンテンツを再生する再生システムに関する。ここでは、コンテンツとして、複数の静止画像によって形成されたグループを説明の対象にする。なお、以下では、静止画像そのもの、静止画像のデジタルデータを区別せずに「静止画像」という。前述のごとく、配信装置がプレイリストを予め提供していない状況下において、再生装置が、配信装置との間でコンテンツの送受信とは別のネットワークを設定することなく、新たなコンテンツのアドレスを取得するために、本実施例は、次の処理を実行する。
【００２０】
配信装置と再生装置とは、ネットワークを介して接続されている。再生装置は、再生が要求されているコンテンツのアドレスが含まれたＨＴＴＰリクエストを配信装置へ送信する。配信装置は、受けつけたＨＴＴＰリクエストに含まれたアドレスをもとに、内蔵の記憶媒体に記憶されたコンテンツを取得する。また、配信装置は、再生装置が当該コンテンツの次に取得可能な別のコンテンツのアドレスも取得し、取得したアドレスをＨＴＴＰヘッダに格納する。配信装置は、取得したコンテンツをボディに格納し、ＨＴＴＰヘッダを付加することによって、一体的なＨＴＴＰレスポンスを生成し、これを再生装置へ送信する。再生装置は、ＨＴＴＰレスポンスに含まれたコンテンツを再生するとともに、新たなＨＴＴＰリクエストに、ＨＴＴＰヘッダに含まれたアドレスを含ませる。
【００２１】
図１は、本発明の実施例に係る再生システム１００の構成を示す。再生システム１００は、配信装置１０、再生装置１２を含む。配信装置１０は、第１記憶部２０、第２記憶部２２、配信用生成部２４、追加部２６、ＨＴＴＰリクエスト受信部２８、ＨＴＴＰレスポンス送信部３０、配信用制御部３２を含む。再生装置１２は、ＨＴＴＰリクエスト送信部４０、ＨＴＴＰレスポンス受信部４２、再生用生成部４４、ＨＴＴＰヘッダ解析部４６、再生部４８、操作部５０、表示部５２、再生用制御部５４を含む。
【００２２】
ＨＴＴＰリクエスト受信部２８は、ネットワークを介して接続された再生装置１２から、ＨＴＴＰリクエストを受信する。ＨＴＴＰリクエストには、再生装置１２において再生が要求されているコンテンツのアドレスが含まれている。ここで、再生の要求は、再生装置１２において実行されているアプリケーションプログラムや、再生装置１２を使用しているユーザによってなされている。また、コンテンツのアドレスは、後述の第１記憶部２０に記憶されているコンテンツのアドレスに相当する。再生装置１２がアドレスを取得するための処理については後述する。
【００２３】
図２（ａ）−（ｂ）は、再生システム１００において使用されるＨＴＴＰリクエストとＨＴＴＰレスポンスの一例を示す。図２（ａ）がＨＴＴＰリクエストに相当し、図２（ｂ）がＨＴＴＰレスポンスに相当する。ここでは、図２（ａ）のみを説明する。「ＧＥＴ」がそれにつづくコンテンツを取得するための命令に相当し、「／Ｃｏｎｔｅｎｔｓ／Ｆｉｌｅ１０６．ｊｐｇ」が前述のコンテンツのアドレスに相当する。また、「Ｆｉｌｅ１０６．ｊｐｇ」が再生装置１２において再生が要求されているコンテンツである。図１に戻る。
【００２４】
第１記憶部２０は、再生装置１２に配信すべき複数のコンテンツを記憶する。前述のごとく、コンテンツは静止画像データであるので、第１記憶部２０は、デジタルデータを記憶するためのハードディスク等の記憶媒体によって構成されている。また、第１記憶部２０は、論理的なディレクトリ構造を形成し、ディレクトリ中にコンテンツを記憶する。例えば、「Ｆｉｌｅ１０６．ｊｐｇ」は、「／Ｃｏｎｔｅｎｔｓ」の配下に相当するアドレスに記憶されている。なお、第１記憶部２０は、配信装置１０に内蔵されているが、これに限らず、第１記憶部２０は、配信装置１０の外部に配置されていてもよい。
【００２５】
配信用生成部２４は、ＨＴＴＰリクエスト受信部２８において受信したＨＴＴＰリクエストから、コンテンツのアドレスを抽出する。配信用生成部２４は、抽出したアドレスをもとに、第１記憶部２０に記憶されたコンテンツを取得する。具体的には、アドレスにて示されたＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に記憶されたコンテンツが取得される。配信用生成部２４は、コンテンツをＨＴＴＰボディに格納する。また、ＨＴＴＰボディの前段にＨＴＴＰヘッダを付加することによって、配信用生成部２４はＨＴＴＰレスポンスを生成する。
【００２６】
第２記憶部２２は、第１記憶部２０に記憶された複数のコンテンツに関する情報を記憶する。ここで、コンテンツに関する情報の一例がアドレスである。また、２以上のコンテンツが、連続再生されるためにグループ化されている場合、第２記憶部２２は、グループ化の情報も記憶する。図３は、第２記憶部２２に記憶された連続再生コンテンツグループの情報が示されたテーブルのデータ構造を示す。図示のごとく、コンテンツ名欄２００、アドレス欄２０２が含まれている。コンテンツ名欄２００には、コンテンツの名称が示されており、アドレス欄２０２には、第１記憶部２０に記憶されたコンテンツのアドレスが示されている。また、図３のテーブルは、ひとつの連続再生コンテンツグループに相当する。そのため、当該テーブルは、例えば、「Ｆｉｌｅ１０６」の前段および後段には、「Ｆｉｌｅ１０５」および「Ｆｉｌｅ１０７」が配置されていることを示している。つまり、テーブルの縦方向に示されたコンテンツは連続している。なお、第２記憶部２２は、別の連続再生コンテンツグループに対して別のテーブルを記憶する。図１に戻る。
【００２７】
追加部２６は、配信用生成部２４において抽出されたアドレスを入力する。追加部２６は、入力したアドレスをもとに、第２記憶部２２から、再生装置１２が取得可能な別のコンテンツのアドレスも取得する。ここで、取得可能な別のコンテンツとは、配信用生成部２４において取得されたコンテンツに隣接したコンテンツであるとする。これは、配信用生成部２４において取得されたコンテンツの前段に配置されたコンテンツと、後段に配置されたコンテンツである。図３をもとに説明すると、これは、配信用生成部２４において取得されたコンテンツが「Ｆｉｌｅ１０６」である場合、「Ｆｉｌｅ１０５」および「Ｆｉｌｅ１０７」に相当する。追加部２６は、図３のアドレス欄２０２から、「Ｆｉｌｅ１０５」および「Ｆｉｌｅ１０７」に対するアドレスを取得する。
【００２８】
追加部２６は、アドレスを取得した場合、ＨＴＴＰヘッダに独自のコンテンツのＵＲＬ情報を追加させる。なお、ＨＴＴＰ規格では、このような独自定義のヘッダを「Ｘ−」で始まるヘッダとして送信、受信することが可能である。ここでは、図２（ｂ）に示されたＨＴＴＰレスポンスのＨＴＴＰヘッダを説明する。図示されたＨＴＴＰヘッダ群において、「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」の独自フィールド名を持つヘッダが、後段のコンテンツ「Ｆｉｌｅ１０７」に該当するＵＲＬ情報を示す。また、「Ｘ−ＰｒｅｖｉｏｕｓＰｌａｙＵＲＬ」の独自フィールド名を持つヘッダが、前段のコンテンツ「Ｆｉｌｅ１０５」に該当するＵＲＬ情報を示す。図１に戻る。
【００２９】
その結果、配信用生成部２４は、ＨＴＴＰヘッダに別のコンテンツのアドレスを含ませ、ＨＴＴＰボディにコンテンツを含ませることによって、取得したコンテンツに別のコンテンツのアドレスを一体的に組み合わせたＨＴＴＰレスポンスを生成する。ＨＴＴＰレスポンス送信部３０は、配信用生成部２４において生成したＨＴＴＰレスポンスを再生装置１２へネットワークを介して送信する。配信用制御部３２は、配信装置１０の動作タイミングを制御する。
【００３０】
ＨＴＴＰリクエスト送信部４０は、ネットワークを介して接続された配信装置１０へ、再生が要求されているコンテンツのアドレスが含まれたＨＴＴＰリクエストを出力する。なお、ＨＴＴＰリクエストは、後述の再生用生成部４４において生成されている。また、ＨＴＴＰリクエストの構成は、図２（ａ）に示したとおりである。ＨＴＴＰレスポンス受信部４２は、ＨＴＴＰリクエスト送信部４０がＨＴＴＰリクエストを出力した配信装置１０から、アドレスに対応したコンテンツがＨＴＴＰボディに含まれたＨＴＴＰレスポンスを受信する。当該ＨＴＴＰレスポンスは、前述のＨＴＴＰレスポンス送信部３０によって送信されたＨＴＴＰレスポンスに相当する。
【００３１】
再生部４８は、ＨＴＴＰレスポンス受信部４２において受信したＨＴＴＰレスポンスに含まれたＨＴＴＰボディ、つまりコンテンツを抽出する。再生部４８は、抽出したコンテンツを再生する。コンテンツが静止画像である場合、再生部４８は、静止画像を生成する。再生部４８は、再生したコンテンツを表示部５２へ出力する。表示部５２は、ディスプレイ等によって構成されており、再生部４８おいて再生されたコンテンツを表示する。例えば、表示部５２は、静止画像を表示する。操作部５０は、キーボードやマウス等によって構成されており、ユーザからの指示を受けつける。操作部５０は、受けつけた指示を再生部４８へ出力する。
【００３２】
ＨＴＴＰヘッダ解析部４６は、ＨＴＴＰレスポンス受信部４２において受信したＨＴＴＰレスポンスに含まれたＨＴＴＰヘッダを抽出する。ＨＴＴＰヘッダの構成は、図２（ｂ）に示したとおりである。ＨＴＴＰヘッダ解析部４６は、ＨＴＴＰヘッダの内容を解析する。特に、ＨＴＴＰヘッダ解析部４６は、ＨＴＴＰヘッダ中の独自フィールド名を持つヘッダ部分を解析する。その結果、ＨＴＴＰヘッダ解析部４６は、取得可能な別のコンテンツのアドレスを取得する。ＨＴＴＰヘッダ解析部４６は、取得した別のコンテンツのアドレスのいずれかを再生用生成部４４へ出力する。なお、再生用生成部４４へ出力すべきアドレスは、アプリケーションプログラムやユーザによって選択される。
【００３３】
このような選択に先立って、ここでは、図４をもとに、コンテンツが選択される際の動作を説明する。図４は、表示部５２に表示されたコンテンツ選択画面を示す。図示のごとく、第１記憶部２０に記憶された複数の静止画像、例えば、５００枚のデジタル写真画像のうち、途中の１０枚が「Ｆｉｌｅ１０１」から「Ｆｉｌｅ１１０」としてサムネイル表示されている。再生部４８は、現時点においてこの１０枚のコンテンツのアドレスであるＵＲＬを保持している。また、再生部４８は、当該１０枚のコンテンツに対して、コンテンツ選択画面に表示するための各タイトル名に関する情報も保持している。なお、残りのコンテンツに対するアドレス等は、再生部４８に保持されていない。
【００３４】
配信装置１０の第１記憶部２０において、５００枚のデジタル写真画像は、撮影時間をもとに時系列に連続再生可能なように、連続再生コンテンツグループを形成している。また、第２記憶部２２には、当該連続再生コンテンツグループの情報が記憶されている。図１の表示部５２がコンテンツ選択画面を表示しているときに、ユーザが操作部５０を操作することによって、「Ｆｉｌｅ１０６」のコンテンツが選択される。これにつづいて、前述のＨＴＴＰリクエストおよびＨＴＴＰレスポンスの送信がなされ、表示部５２は、「Ｆｉｌｅ１０６」のコンテンツを表示する。図１に戻る。
【００３５】
「Ｆｉｌｅ１０６」のコンテンツが表示された後、再生部４８において実行されているアプリケーションプログラムが、時間軸に沿ったスライドショーであるならば、再生部４８は、コンテンツ選択画面に戻らない。その代わりに、再生部４８は、直ちに「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」にて示された「Ｆｉｌｅ１０７」のＵＲＬを選択する。また、アプリケーションプログラムが、時間軸と逆方向のスライドショーであるならば、再生部４８は、直ちに「Ｘ−ＰｒｅｖｉｏｕｓＰｌａｙＵＲＬ」にて示された「Ｆｉｌｅ１０５」のＵＲＬを選択する。なお、前述のごとく、再生部４８は、予め１０枚分のコンテンツに対するＵＲＬ情報を保持しているので、ＨＴＴＰヘッダの「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」や「Ｘ−ＰｒｅｃｉｏｕｓＰｌａｙＵＲＬ」に含まれたアドレスを使用しなくてもよい。
【００３６】
しかしながら、スライドショーによって、表示すべきコンテンツが変更され、「Ｆｉｌｅ１１０」より後段のコンテンツや、「Ｆｉｌｅ１０１」より前段のコンテンツを連続して再生するためには、それらのアドレスが必要になる。一方、ＨＴＴＰヘッダ解析部４６は、「Ｆｉｌｅ１１０」のコンテンツが格納されたＨＴＴＰレスポンスにおいて、「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」にて示された「Ｆｉｌｅ１１１」のコンテンツのＵＲＬを抽出している。また、ＨＴＴＰヘッダ解析部４６は、「Ｆｉｌｅ１０１」のコンテンツが格納されたＨＴＴＰレスポンスにおいて、「Ｘ−ＰｒｅｖｉｏｕｓＰｌａｙＵＲＬ」にて示された「Ｆｉｌｅ１００」のコンテンツのＵＲＬを抽出している。
【００３７】
その結果、前述の１０枚のコンテンツ以外のコンテンツを連続再生する場合であっても、ＨＴＴＰヘッダ解析部４６や再生部４８は、それらのコンテンツのＵＲＬを別途取得しなくてもよい。また、ＨＴＴＰヘッダ解析部４６や再生部４８は、すべてのコンテンツのＵＲＬが示されたプレイリストを保持せずにすむ。さらに、配信装置１０と再生装置１２間の通信は、ＨＴＴＰ規格の範囲内だけなので、特殊な通信機能の追加が必要とされない。図２（ｂ）に示した独自フィールド名を持つヘッダに非対応の再生装置は、当該ヘッダを無視すればよいので、そのような再生装置に与える影響が低減される。なお、「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」、「Ｘ−ＰｒｅｖｉｏｕｓＰｌａｙＵＲＬ」は、ＨＴＴＰレスポンスとしてＨＴＴＰヘッダだけを要求するための「ＨＴＴＰ ＨＥＡＤメソッド」にも含まれる。そのため、ＨＴＴＰレスポンスにコンテンツを含めなくても、当該コンテンツの前後のコンテンツのＵＲＬが取得されるので、前方向、後方向へのコンテンツのスキップが迅速に実現される。
【００３８】
再生用生成部４４は、ＨＴＴＰヘッダ解析部４６から、別のコンテンツのアドレスを入力し、アドレスをもとにＨＴＴＰリクエストを生成する。前述のごとく、ＨＴＴＰリクエストのフォーマットの一例は、図２（ａ）である。ＨＴＴＰリクエスト送信部４０は、ＨＴＴＰヘッダ解析部４６において生成したＨＴＴＰリクエストであって、かつ新たなコンテンツのアドレスが含まれたＨＴＴＰリクエストを送信する。再生用制御部５４は、再生装置１２の動作タイミングを制御する。
【００３９】
この構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００４０】
以上の構成による再生システム１００の動作を説明する。図５は、配信装置１０におけるコンテンツの送信手順を示すフローチャートである。ＨＴＴＰリクエスト受信部２８が、ＨＴＴＰリクエストを受信すれば（Ｓ１０のＹ）、配信用生成部２４は、要求されたコンテンツが連続再生コンテンツグループに属するかを第２記憶部２２に問い合わせる（Ｓ１２）。要求されたコンテンツが連続再生可能である場合（Ｓ１４のＹ）、追加部２６は、要求されたコンテンツに隣接したコンテンツの情報を取得して、ＨＴＴＰヘッダを生成する（Ｓ１６）。要求されたコンテンツが連続再生可能でない場合（Ｓ１４のＮ）、ステップ１６はスキップされる。配信用生成部２４は、第１記憶部２０から、要求されたコンテンツを取得する（Ｓ１８）。配信用生成部２４は、ＨＴＴＰレスポンスを生成する（Ｓ２０）。ＨＴＴＰレスポンス送信部３０は、ＨＴＴＰレスポンスを送信する（Ｓ２２）。一方、ＨＴＴＰリクエスト受信部２８が、ＨＴＴＰリクエストを受信しなければ（Ｓ１０のＮ）、処理は終了される。
【００４１】
図６は、再生装置１２におけるコンテンツの再生手順を示すフローチャートである。ＨＴＴＰリクエスト送信部４０は、ＨＴＴＰリクエストを送信する（Ｓ５０）。ＨＴＴＰレスポンス受信部４２は、ＨＴＴＰレスポンスを受信する（Ｓ５２）。ＨＴＴＰヘッダ解析部４６は、ＨＴＴＰヘッダを解析する（Ｓ５４）。再生部４８は、コンテンツを再生する（Ｓ５６）。再生終了でなければ（Ｓ５８のＮ）、ステップ５６に戻る。再生終了であり（Ｓ５８のＹ）、連続再生可能であれば（Ｓ６０のＹ）、再生用生成部４４は、ＨＴＴＰヘッダを生成し（Ｓ６２）、ステップ５０に戻る。連続再生可能でなければ（Ｓ６０のＮ）、処理は終了される。
【００４２】
次に、変形例を説明する。変形例も、実施例と同様の再生システムであって、配信装置がコンテンツを送信し、再生装置がコンテンツを再生する。実施例では、コンテンツとして静止画像を説明の対象にした。しかしながら変形例では、コンテンツとして、静止画像だけではなく、動画像も説明の対象にする。そのため、ＨＴＴＰヘッダには、コンテンツのアドレスに加えて、当該コンテンツの属性情報も格納される。ここで、コンテンツの属性情報では、例えば、コンテンツの種類が示される。変形例にかかる再生システム１００は、図１に示された再生システム１００と同様のタイプである。そのため、ここでは、差異の部分を中心に説明する。
【００４３】
第２記憶部２２は、実施例と同様に、第１記憶部２０に記憶された複数のコンテンツに関する情報として、アドレスを記憶する。また、第２記憶部２２は、複数のコンテンツのそれぞれに対する属性の情報（以下、「属性情報」という）も記憶する。属性情報とは、例えば、コンテンツの種別であり、コンテンツが静止画像、動画像等のいずれかに相当するかに関する情報である。また、属性情報は、動画像の場合に、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）２などの圧縮方式を示していてもよい。追加部２６は、実施例での処理に加えて、第２記憶部２２から、再生装置１２が取得可能な別のコンテンツの属性情報も取得する。配信用生成部２４は、ＨＴＴＰレスポンスを生成する際、ＨＴＴＰヘッダに、別のコンテンツのアドレスとともに、当該別のコンテンツの属性情報も含める。
【００４４】
図７は、本発明の変形例に係る再生システム１００において使用されるＨＴＴＰレスポンスの一例を示す。図示されたＨＴＴＰヘッダ群において、前述のごとく、「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」の独自フィールド名を持つヘッダが、後段のコンテンツ「Ｆｉｌｅ１０７」に該当するＵＲＬ情報を示す。さらに、「Ｘ−ＮｅｘｔＰｌａｙＣｏｎｔｅｎｔｓＦｏｒｍａｔ」の独自フィールド名を持つヘッダが、後段のコンテンツ「Ｆｉｌｅ１０７」に該当する属性情報を示す。ここでは、「ＭＰＥＧ＿ＴＳ」と示されているので、コンテンツ「Ｆｉｌｅ１０７」は、ＭＰＥＧ２にて圧縮された動画像である。
【００４５】
次に、図８をもとに、再生装置１２においてコンテンツが選択される際の動作を説明する。図８は、表示部５２に表示されたコンテンツ選択画面を示す。第１記憶部２０に記憶された複数の静止画像や動画像、例えば、５００のコンテンツのうち、途中の１０のコンテンツが「Ｆｉｌｅ１０１」から「Ｆｉｌｅ１１０」としてサムネイル表示されている。ここで、「Ｆｉｌｅ１０１」は静止画像であり、「Ｆｉｌｅ１０２」は動画像であるように、コンテンツとして、静止画像と動画像とが混在している。また、５００のコンテンツは、連続再生コンテンツグループを形成している。再生部４８は、現時点においてこの１０のコンテンツのアドレスであるＵＲＬ、コンテンツの種類、サイズを保持している。なお、残りのコンテンツに対するアドレス等は、再生部４８に保持されていない。
【００４６】
図１の表示部５２がコンテンツ選択画面を表示しているときに、ユーザが操作部５０を操作することによって、「Ｆｉｌｅ１０６」のコンテンツが選択される。これにつづいて、前述のＨＴＴＰリクエストおよびＨＴＴＰレスポンスの送信がなされ、表示部５２は、「Ｆｉｌｅ１０６」のコンテンツを表示する。「Ｆｉｌｅ１０６」のコンテンツが表示された後、再生部４８において実行されているアプリケーションプログラムが、時間軸に沿ったスライドショーであるならば、再生部４８は、コンテンツ選択画面に戻らない。その代わりに、再生部４８は、直ちに「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」にて示された「Ｆｉｌｅ１０７」のＵＲＬを選択する。また、再生部４８は、「Ｘ−ＮｅｘｔＰｌａｙＣｏｎｔｅｎｔｓＦｏｒｍａｔ」にしたがって、動画像を再生するための準備を実行する。なお、次のコンテンツを再生するのに必要な独自ヘッダとして、各種コンテンツフォーマット別に必要な再生属性情報、以前途中まで再生した動画や音楽におけるレジューム再生位置情報が含まれていてもよい。
【００４７】
本発明の実施例によれば、ＨＴＴＰリクエストに応じてコンテンツを送信する際に、別のコンテンツのアドレスもＨＴＴＰレスポンスにて送信するので、コンテンツの送受信以外のネットワーク通信を不要としながらも、別のコンテンツのアドレスを通知できる。また、ＨＴＴＰレスポンスにて別のコンテンツのアドレスとコンテンツとを通知するので、コンテンツの送受信以外のネットワーク通信を不要としながらも、コンテンツを連続再生できる。また、別のコンテンツのアドレスをＨＴＴＰヘッダに含めるので、ＨＴＴＰヘッダのみを出力することによっても、別のコンテンツのアドレスを通知できる。また、別のコンテンツのアドレスをＨＴＴＰヘッダに含めるので、ＨＴＴＰボディを送信しなくても、別のコンテンツのアドレスを通知できる。
【００４８】
また、別のコンテンツのアドレスとともに、別のコンテンツの属性情報も出力するので、別のコンテンツの属性情報を通知できる。また、別のコンテンツのアドレスとともに、別のコンテンツの属性情報も出力するので、さまざまな種類のコンテンツが混在している場合でも対応できる。また、ＨＴＴＰレスポンスに応じたコンテンツを受信する際に、別のコンテンツのアドレスも一体的に受信するので、コンテンツの送受信以外のネットワーク通信を不要としながらも、別のコンテンツのアドレスを取得できる。また、別のコンテンツのアドレスを取得するので、直ちに当該アドレスへのＨＴＴＰリクエストを送信できる。
【００４９】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５０】
本発明の実施例において、追加部２６は、ＨＴＴＰヘッダに独自フィールドとして、別のコンテンツのアドレスや属性情報を追加している。しかしながらこれに限らず例えば、追加部２６は、独自ヘッダに他の内容を追加してもよい。例えば、連続再生中に前回再生したコンテンツにスキップして戻り再生を行うために、前回のコンテンツのＵＲＬが示されたヘッダ、連続再生コンテンツのフォーマットの違いやサイズなどの違いによって、再生部４８が初期設定を変更できるように、これらの情報が示されたヘッダが追加されてもよい。本変形によれば、再生部４８において再生されるコンテンツの多様化を実現できる。
【符号の説明】
【００５１】
１０ 配信装置、 １２ 再生装置、 ２０ 第１記憶部、 ２２ 第２記憶部、 ２４ 配信用生成部、 ２６ 追加部、 ２８ ＨＴＴＰリクエスト受信部、 ３０ ＨＴＴＰレスポンス送信部、 ３２ 配信用制御部、 ４０ ＨＴＴＰリクエスト送信部、 ４２ ＨＴＴＰレスポンス受信部、 ４４ 再生用生成部、 ４６ ＨＴＴＰヘッダ解析部、 ４８ 再生部、 ５０ 操作部、 ５２ 表示部、 ５４ 再生用制御部、 １００ 再生システム。
【技術分野】
【０００１】
本発明は、配信技術に関し、特にデータを配信する配信方法、配信装置、再生装置、配信システム、配信プログラムに関する。
【背景技術】
【０００２】
ＡＶ（Ａｕｄｉｏ Ｖｉｓｕａｌ）家電のホームネットワーク化に伴って、ホームネットワークサーバに併設されたテレビジョン受像装置（以下、「ＴＶ」という）だけでなく、別部屋のＴＶでも、ホームネットワークサーバに記憶されたコンテンツが視聴可能になる。例えば、ホームネットワークサーバは、動画データ、写真データ、音楽データなどのデジタルコンテンツを記憶する。また、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｒａｎｓｆｅｒ Ｔｅｘｔ Ｐｒｏｔｏｃｏｌ）やＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ＆ Ｐｌａｙ）をベースにしたＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）ガイドラインの策定により、ホームネットワークシステムの普及が進んでいる。それとともに、コンテンツのネットワーク再生として、単一のコンテンツ再生だけでなく、商品価値の高いデジタル写真のスライドショー、音楽のアルバム再生などのコンテンツ連続再生機能が必要とされる。また、テープメディアからハードディスクなどに記録媒体が変わりつつある家庭用ビデオレコーダやビデオカメラでは、１回の録画ごとに動画ファイルが作成されるので、ユーザの利便性を向上するために、複数の動画ファイルの連続再生が必要になる。
【０００３】
一方、上記のガイドラインでは、ホームネットワークサーバに記憶されたコンテンツに対する再生に必要な情報や属性情報が、コンテンツ単位にクライアントに予め提供されている。クライアントは、その情報をもとにＨＴＴＰによるネットワーク再生を実施する。このように、ホームネットワークサーバが、複数のコンテンツの再生順序、時間、再生のために必要な情報などを予めプレイリストとして作成し、クライアントに提供することによって、複数のコンテンツの連続再生が可能にされている（例えば、特許文献１参照）。この場合、次に再生するコンテンツのメタ情報を現在再生中のコンテンツ再生終了前に取得するための特殊なネットワーク送受信処理とその機能がクライアントに必要とされる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−１５２６７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
プレイリストを使用する場合、コンテンツの連続再生の前に、プレイリスト自身のネットワーク送受信処理、プレイリストの解析機能およびその内容を保持するためのメモリが必要になる。また、プレイリストに含まれるコンテンツの数や各種情報の増加によって、クライアントにおけるプレイリスト使用の負担が増加する。そのため、特開２００８−１６５６５６号公報では、すべての連続再生コンテンツ情報をクライアントに予め提供する代わりに、クライアントが、次に再生すべきコンテンツのメタ情報を現在再生中のコンテンツ再生終了前に取得する。その結果、クライアントは、逐次処理により連続再生コンテンツの情報を保持することなく、連続再生を実現する。この場合においても、次に再生するコンテンツのメタ情報を現在再生中のコンテンツ再生終了前に取得するための特殊なネットワーク送受信処理とその機能がクライアントに必要とされる。
【０００６】
本発明はこうした状況に鑑みてなされたものであり、その目的は、コンテンツの送受信以外のネットワーク通信を不要としながらも、コンテンツを連続再生する技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様の配信方法は、ネットワークを介して接続された再生装置から、当該再生装置において再生が要求されている第１のデータのアドレスを受けつけるステップと、受けつけたアドレスをもとに、記憶媒体に記憶された第１のデータを取得するとともに、再生装置が取得可能な第１のデータとは別のデータである第２のデータのアドレスも取得するステップと、取得した第１のデータと、第２のデータのアドレスとを一体的に組み合わせて出力するステップと、を備える。
【０００８】
この態様によると、要求に応じて第１のデータを送信する際に、第２のデータのアドレスも一体的に送信するので、データの送受信以外のネットワーク通信を不要としながらも、第２のデータのアドレスを通知できる。
【０００９】
出力するステップは、ヘッダと、取得した第１のデータとを組み合わせたフレームを出力しており、第２のデータのアドレスをヘッダに含めてもよい。この場合、第２のデータのアドレスをヘッダに含めるので、ヘッダのみを出力することによっても、第２のデータのアドレスを通知できる。
【００１０】
取得するステップは、再生装置が取得可能な第２のデータの属性情報も取得し、出力するステップは、第２のデータのアドレスとともに、第２のデータの属性情報も出力してもよい。この場合、第２のデータのアドレスとともに、第２のデータの属性情報も出力するので、第２のデータの属性情報を通知できる。
【００１１】
本発明の別の態様は、配信装置である。この装置は、ネットワークを介して接続された再生装置から、当該再生装置において再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を受けつける受付部と、受付部において受けつけたＨＴＴＰコンテンツ要求に含まれたアドレスをもとに、記憶媒体に記憶された第１のデータを取得するとともに、再生装置が取得可能な第１のデータとは別のデータである第２のデータのアドレスも取得する取得部と、取得部において取得した第１のデータを、ＨＴＴＰコンテンツ要求に対するＨＴＴＰコンテンツ応答として再生装置へ出力する際に、ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに、取得した第２のデータのアドレスを含めて出力する出力部と、を備える。
【００１２】
この態様によると、要求に応じて第１のデータを送信する際に、第２のデータのアドレスも一体的に送信するので、データの送受信以外のネットワーク通信を不要としながらも、第２のデータのアドレスを通知できる。
【００１３】
本発明のさらに別の態様は、再生装置である。この装置は、ネットワークを介して接続された配信装置へ、再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を出力する出力部と、出力部がＨＴＴＰコンテンツ要求を出力した配信装置から、アドレスに対応した第１のデータが含まれたＨＴＴＰコンテンツ応答を受けつける受付部と、受付部において受けつけたＨＴＴＰコンテンツ応答に含まれた第１のデータを再生するとともに、ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに含まれている、取得可能な第１のデータとは別のデータである第２のデータのアドレスを取得する再生部とを備える。出力部は、新たなＨＴＴＰコンテンツ要求に、第２のデータのアドレスを含める。
【００１４】
この態様によると、要求に応じた第１のデータを受信する際に、第２のデータのアドレスも一体的に受信するので、データの送受信以外のネットワーク通信を不要としながらも、第２のデータのアドレスを取得できる。
【００１５】
本発明のさらに別の態様は、配信システムである。この配信システムは、ネットワークを介して、再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を出力する再生装置と、受けつけたＨＴＴＰコンテンツ要求に含まれたアドレスをもとに、記憶媒体に記憶された第１のデータを取得した後、第１のデータをＨＴＴＰコンテンツ要求に対するＨＴＴＰコンテンツ応答として再生装置へ出力する際に、ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに、取得した第１のデータとは別のデータである第２のデータのアドレスを含めて出力する配信装置とを備える。再生装置は、受けつけたＨＴＴＰコンテンツ応答に含まれた第１のデータを再生するとともに、新たなＨＴＴＰコンテンツ要求に、取得可能な第２のデータのアドレスを含める。
【００１６】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１７】
本発明によれば、コンテンツの送受信以外のネットワーク通信を不要としながらも、コンテンツを連続再生できる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施例に係る再生システムの構成を示す図である。
【図２】図２（ａ）−（ｂ）は、図１の再生システムにおいて使用されるＨＴＴＰリクエストとＨＴＴＰレスポンスの一例を示す図である。
【図３】図１の第２記憶部に記憶された連続再生コンテンツグループの情報が示されたテーブルのデータ構造を示す図である。
【図４】図１の表示部に表示されたコンテンツ選択画面を示す図である。
【図５】図１の配信装置におけるコンテンツの送信手順を示すフローチャートである。
【図６】図１の再生装置におけるコンテンツの再生手順を示すフローチャートである。
【図７】本発明の変形例に係る再生システムにおいて使用されるＨＴＴＰレスポンスの一例を示す図である。
【図８】本発明の変形例に係る表示部に表示されたコンテンツ選択画面を示す図である。
【発明を実施するための形態】
【００１９】
本発明を具体的に説明する前に、まず概要を述べる。本発明の実施例は、ネットワークを介して互いに接続された配信装置と再生装置によって形成され、配信装置がコンテンツを送信するとともに、再生装置がコンテンツを再生する再生システムに関する。ここでは、コンテンツとして、複数の静止画像によって形成されたグループを説明の対象にする。なお、以下では、静止画像そのもの、静止画像のデジタルデータを区別せずに「静止画像」という。前述のごとく、配信装置がプレイリストを予め提供していない状況下において、再生装置が、配信装置との間でコンテンツの送受信とは別のネットワークを設定することなく、新たなコンテンツのアドレスを取得するために、本実施例は、次の処理を実行する。
【００２０】
配信装置と再生装置とは、ネットワークを介して接続されている。再生装置は、再生が要求されているコンテンツのアドレスが含まれたＨＴＴＰリクエストを配信装置へ送信する。配信装置は、受けつけたＨＴＴＰリクエストに含まれたアドレスをもとに、内蔵の記憶媒体に記憶されたコンテンツを取得する。また、配信装置は、再生装置が当該コンテンツの次に取得可能な別のコンテンツのアドレスも取得し、取得したアドレスをＨＴＴＰヘッダに格納する。配信装置は、取得したコンテンツをボディに格納し、ＨＴＴＰヘッダを付加することによって、一体的なＨＴＴＰレスポンスを生成し、これを再生装置へ送信する。再生装置は、ＨＴＴＰレスポンスに含まれたコンテンツを再生するとともに、新たなＨＴＴＰリクエストに、ＨＴＴＰヘッダに含まれたアドレスを含ませる。
【００２１】
図１は、本発明の実施例に係る再生システム１００の構成を示す。再生システム１００は、配信装置１０、再生装置１２を含む。配信装置１０は、第１記憶部２０、第２記憶部２２、配信用生成部２４、追加部２６、ＨＴＴＰリクエスト受信部２８、ＨＴＴＰレスポンス送信部３０、配信用制御部３２を含む。再生装置１２は、ＨＴＴＰリクエスト送信部４０、ＨＴＴＰレスポンス受信部４２、再生用生成部４４、ＨＴＴＰヘッダ解析部４６、再生部４８、操作部５０、表示部５２、再生用制御部５４を含む。
【００２２】
ＨＴＴＰリクエスト受信部２８は、ネットワークを介して接続された再生装置１２から、ＨＴＴＰリクエストを受信する。ＨＴＴＰリクエストには、再生装置１２において再生が要求されているコンテンツのアドレスが含まれている。ここで、再生の要求は、再生装置１２において実行されているアプリケーションプログラムや、再生装置１２を使用しているユーザによってなされている。また、コンテンツのアドレスは、後述の第１記憶部２０に記憶されているコンテンツのアドレスに相当する。再生装置１２がアドレスを取得するための処理については後述する。
【００２３】
図２（ａ）−（ｂ）は、再生システム１００において使用されるＨＴＴＰリクエストとＨＴＴＰレスポンスの一例を示す。図２（ａ）がＨＴＴＰリクエストに相当し、図２（ｂ）がＨＴＴＰレスポンスに相当する。ここでは、図２（ａ）のみを説明する。「ＧＥＴ」がそれにつづくコンテンツを取得するための命令に相当し、「／Ｃｏｎｔｅｎｔｓ／Ｆｉｌｅ１０６．ｊｐｇ」が前述のコンテンツのアドレスに相当する。また、「Ｆｉｌｅ１０６．ｊｐｇ」が再生装置１２において再生が要求されているコンテンツである。図１に戻る。
【００２４】
第１記憶部２０は、再生装置１２に配信すべき複数のコンテンツを記憶する。前述のごとく、コンテンツは静止画像データであるので、第１記憶部２０は、デジタルデータを記憶するためのハードディスク等の記憶媒体によって構成されている。また、第１記憶部２０は、論理的なディレクトリ構造を形成し、ディレクトリ中にコンテンツを記憶する。例えば、「Ｆｉｌｅ１０６．ｊｐｇ」は、「／Ｃｏｎｔｅｎｔｓ」の配下に相当するアドレスに記憶されている。なお、第１記憶部２０は、配信装置１０に内蔵されているが、これに限らず、第１記憶部２０は、配信装置１０の外部に配置されていてもよい。
【００２５】
配信用生成部２４は、ＨＴＴＰリクエスト受信部２８において受信したＨＴＴＰリクエストから、コンテンツのアドレスを抽出する。配信用生成部２４は、抽出したアドレスをもとに、第１記憶部２０に記憶されたコンテンツを取得する。具体的には、アドレスにて示されたＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に記憶されたコンテンツが取得される。配信用生成部２４は、コンテンツをＨＴＴＰボディに格納する。また、ＨＴＴＰボディの前段にＨＴＴＰヘッダを付加することによって、配信用生成部２４はＨＴＴＰレスポンスを生成する。
【００２６】
第２記憶部２２は、第１記憶部２０に記憶された複数のコンテンツに関する情報を記憶する。ここで、コンテンツに関する情報の一例がアドレスである。また、２以上のコンテンツが、連続再生されるためにグループ化されている場合、第２記憶部２２は、グループ化の情報も記憶する。図３は、第２記憶部２２に記憶された連続再生コンテンツグループの情報が示されたテーブルのデータ構造を示す。図示のごとく、コンテンツ名欄２００、アドレス欄２０２が含まれている。コンテンツ名欄２００には、コンテンツの名称が示されており、アドレス欄２０２には、第１記憶部２０に記憶されたコンテンツのアドレスが示されている。また、図３のテーブルは、ひとつの連続再生コンテンツグループに相当する。そのため、当該テーブルは、例えば、「Ｆｉｌｅ１０６」の前段および後段には、「Ｆｉｌｅ１０５」および「Ｆｉｌｅ１０７」が配置されていることを示している。つまり、テーブルの縦方向に示されたコンテンツは連続している。なお、第２記憶部２２は、別の連続再生コンテンツグループに対して別のテーブルを記憶する。図１に戻る。
【００２７】
追加部２６は、配信用生成部２４において抽出されたアドレスを入力する。追加部２６は、入力したアドレスをもとに、第２記憶部２２から、再生装置１２が取得可能な別のコンテンツのアドレスも取得する。ここで、取得可能な別のコンテンツとは、配信用生成部２４において取得されたコンテンツに隣接したコンテンツであるとする。これは、配信用生成部２４において取得されたコンテンツの前段に配置されたコンテンツと、後段に配置されたコンテンツである。図３をもとに説明すると、これは、配信用生成部２４において取得されたコンテンツが「Ｆｉｌｅ１０６」である場合、「Ｆｉｌｅ１０５」および「Ｆｉｌｅ１０７」に相当する。追加部２６は、図３のアドレス欄２０２から、「Ｆｉｌｅ１０５」および「Ｆｉｌｅ１０７」に対するアドレスを取得する。
【００２８】
追加部２６は、アドレスを取得した場合、ＨＴＴＰヘッダに独自のコンテンツのＵＲＬ情報を追加させる。なお、ＨＴＴＰ規格では、このような独自定義のヘッダを「Ｘ−」で始まるヘッダとして送信、受信することが可能である。ここでは、図２（ｂ）に示されたＨＴＴＰレスポンスのＨＴＴＰヘッダを説明する。図示されたＨＴＴＰヘッダ群において、「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」の独自フィールド名を持つヘッダが、後段のコンテンツ「Ｆｉｌｅ１０７」に該当するＵＲＬ情報を示す。また、「Ｘ−ＰｒｅｖｉｏｕｓＰｌａｙＵＲＬ」の独自フィールド名を持つヘッダが、前段のコンテンツ「Ｆｉｌｅ１０５」に該当するＵＲＬ情報を示す。図１に戻る。
【００２９】
その結果、配信用生成部２４は、ＨＴＴＰヘッダに別のコンテンツのアドレスを含ませ、ＨＴＴＰボディにコンテンツを含ませることによって、取得したコンテンツに別のコンテンツのアドレスを一体的に組み合わせたＨＴＴＰレスポンスを生成する。ＨＴＴＰレスポンス送信部３０は、配信用生成部２４において生成したＨＴＴＰレスポンスを再生装置１２へネットワークを介して送信する。配信用制御部３２は、配信装置１０の動作タイミングを制御する。
【００３０】
ＨＴＴＰリクエスト送信部４０は、ネットワークを介して接続された配信装置１０へ、再生が要求されているコンテンツのアドレスが含まれたＨＴＴＰリクエストを出力する。なお、ＨＴＴＰリクエストは、後述の再生用生成部４４において生成されている。また、ＨＴＴＰリクエストの構成は、図２（ａ）に示したとおりである。ＨＴＴＰレスポンス受信部４２は、ＨＴＴＰリクエスト送信部４０がＨＴＴＰリクエストを出力した配信装置１０から、アドレスに対応したコンテンツがＨＴＴＰボディに含まれたＨＴＴＰレスポンスを受信する。当該ＨＴＴＰレスポンスは、前述のＨＴＴＰレスポンス送信部３０によって送信されたＨＴＴＰレスポンスに相当する。
【００３１】
再生部４８は、ＨＴＴＰレスポンス受信部４２において受信したＨＴＴＰレスポンスに含まれたＨＴＴＰボディ、つまりコンテンツを抽出する。再生部４８は、抽出したコンテンツを再生する。コンテンツが静止画像である場合、再生部４８は、静止画像を生成する。再生部４８は、再生したコンテンツを表示部５２へ出力する。表示部５２は、ディスプレイ等によって構成されており、再生部４８おいて再生されたコンテンツを表示する。例えば、表示部５２は、静止画像を表示する。操作部５０は、キーボードやマウス等によって構成されており、ユーザからの指示を受けつける。操作部５０は、受けつけた指示を再生部４８へ出力する。
【００３２】
ＨＴＴＰヘッダ解析部４６は、ＨＴＴＰレスポンス受信部４２において受信したＨＴＴＰレスポンスに含まれたＨＴＴＰヘッダを抽出する。ＨＴＴＰヘッダの構成は、図２（ｂ）に示したとおりである。ＨＴＴＰヘッダ解析部４６は、ＨＴＴＰヘッダの内容を解析する。特に、ＨＴＴＰヘッダ解析部４６は、ＨＴＴＰヘッダ中の独自フィールド名を持つヘッダ部分を解析する。その結果、ＨＴＴＰヘッダ解析部４６は、取得可能な別のコンテンツのアドレスを取得する。ＨＴＴＰヘッダ解析部４６は、取得した別のコンテンツのアドレスのいずれかを再生用生成部４４へ出力する。なお、再生用生成部４４へ出力すべきアドレスは、アプリケーションプログラムやユーザによって選択される。
【００３３】
このような選択に先立って、ここでは、図４をもとに、コンテンツが選択される際の動作を説明する。図４は、表示部５２に表示されたコンテンツ選択画面を示す。図示のごとく、第１記憶部２０に記憶された複数の静止画像、例えば、５００枚のデジタル写真画像のうち、途中の１０枚が「Ｆｉｌｅ１０１」から「Ｆｉｌｅ１１０」としてサムネイル表示されている。再生部４８は、現時点においてこの１０枚のコンテンツのアドレスであるＵＲＬを保持している。また、再生部４８は、当該１０枚のコンテンツに対して、コンテンツ選択画面に表示するための各タイトル名に関する情報も保持している。なお、残りのコンテンツに対するアドレス等は、再生部４８に保持されていない。
【００３４】
配信装置１０の第１記憶部２０において、５００枚のデジタル写真画像は、撮影時間をもとに時系列に連続再生可能なように、連続再生コンテンツグループを形成している。また、第２記憶部２２には、当該連続再生コンテンツグループの情報が記憶されている。図１の表示部５２がコンテンツ選択画面を表示しているときに、ユーザが操作部５０を操作することによって、「Ｆｉｌｅ１０６」のコンテンツが選択される。これにつづいて、前述のＨＴＴＰリクエストおよびＨＴＴＰレスポンスの送信がなされ、表示部５２は、「Ｆｉｌｅ１０６」のコンテンツを表示する。図１に戻る。
【００３５】
「Ｆｉｌｅ１０６」のコンテンツが表示された後、再生部４８において実行されているアプリケーションプログラムが、時間軸に沿ったスライドショーであるならば、再生部４８は、コンテンツ選択画面に戻らない。その代わりに、再生部４８は、直ちに「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」にて示された「Ｆｉｌｅ１０７」のＵＲＬを選択する。また、アプリケーションプログラムが、時間軸と逆方向のスライドショーであるならば、再生部４８は、直ちに「Ｘ−ＰｒｅｖｉｏｕｓＰｌａｙＵＲＬ」にて示された「Ｆｉｌｅ１０５」のＵＲＬを選択する。なお、前述のごとく、再生部４８は、予め１０枚分のコンテンツに対するＵＲＬ情報を保持しているので、ＨＴＴＰヘッダの「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」や「Ｘ−ＰｒｅｃｉｏｕｓＰｌａｙＵＲＬ」に含まれたアドレスを使用しなくてもよい。
【００３６】
しかしながら、スライドショーによって、表示すべきコンテンツが変更され、「Ｆｉｌｅ１１０」より後段のコンテンツや、「Ｆｉｌｅ１０１」より前段のコンテンツを連続して再生するためには、それらのアドレスが必要になる。一方、ＨＴＴＰヘッダ解析部４６は、「Ｆｉｌｅ１１０」のコンテンツが格納されたＨＴＴＰレスポンスにおいて、「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」にて示された「Ｆｉｌｅ１１１」のコンテンツのＵＲＬを抽出している。また、ＨＴＴＰヘッダ解析部４６は、「Ｆｉｌｅ１０１」のコンテンツが格納されたＨＴＴＰレスポンスにおいて、「Ｘ−ＰｒｅｖｉｏｕｓＰｌａｙＵＲＬ」にて示された「Ｆｉｌｅ１００」のコンテンツのＵＲＬを抽出している。
【００３７】
その結果、前述の１０枚のコンテンツ以外のコンテンツを連続再生する場合であっても、ＨＴＴＰヘッダ解析部４６や再生部４８は、それらのコンテンツのＵＲＬを別途取得しなくてもよい。また、ＨＴＴＰヘッダ解析部４６や再生部４８は、すべてのコンテンツのＵＲＬが示されたプレイリストを保持せずにすむ。さらに、配信装置１０と再生装置１２間の通信は、ＨＴＴＰ規格の範囲内だけなので、特殊な通信機能の追加が必要とされない。図２（ｂ）に示した独自フィールド名を持つヘッダに非対応の再生装置は、当該ヘッダを無視すればよいので、そのような再生装置に与える影響が低減される。なお、「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」、「Ｘ−ＰｒｅｖｉｏｕｓＰｌａｙＵＲＬ」は、ＨＴＴＰレスポンスとしてＨＴＴＰヘッダだけを要求するための「ＨＴＴＰ ＨＥＡＤメソッド」にも含まれる。そのため、ＨＴＴＰレスポンスにコンテンツを含めなくても、当該コンテンツの前後のコンテンツのＵＲＬが取得されるので、前方向、後方向へのコンテンツのスキップが迅速に実現される。
【００３８】
再生用生成部４４は、ＨＴＴＰヘッダ解析部４６から、別のコンテンツのアドレスを入力し、アドレスをもとにＨＴＴＰリクエストを生成する。前述のごとく、ＨＴＴＰリクエストのフォーマットの一例は、図２（ａ）である。ＨＴＴＰリクエスト送信部４０は、ＨＴＴＰヘッダ解析部４６において生成したＨＴＴＰリクエストであって、かつ新たなコンテンツのアドレスが含まれたＨＴＴＰリクエストを送信する。再生用制御部５４は、再生装置１２の動作タイミングを制御する。
【００３９】
この構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００４０】
以上の構成による再生システム１００の動作を説明する。図５は、配信装置１０におけるコンテンツの送信手順を示すフローチャートである。ＨＴＴＰリクエスト受信部２８が、ＨＴＴＰリクエストを受信すれば（Ｓ１０のＹ）、配信用生成部２４は、要求されたコンテンツが連続再生コンテンツグループに属するかを第２記憶部２２に問い合わせる（Ｓ１２）。要求されたコンテンツが連続再生可能である場合（Ｓ１４のＹ）、追加部２６は、要求されたコンテンツに隣接したコンテンツの情報を取得して、ＨＴＴＰヘッダを生成する（Ｓ１６）。要求されたコンテンツが連続再生可能でない場合（Ｓ１４のＮ）、ステップ１６はスキップされる。配信用生成部２４は、第１記憶部２０から、要求されたコンテンツを取得する（Ｓ１８）。配信用生成部２４は、ＨＴＴＰレスポンスを生成する（Ｓ２０）。ＨＴＴＰレスポンス送信部３０は、ＨＴＴＰレスポンスを送信する（Ｓ２２）。一方、ＨＴＴＰリクエスト受信部２８が、ＨＴＴＰリクエストを受信しなければ（Ｓ１０のＮ）、処理は終了される。
【００４１】
図６は、再生装置１２におけるコンテンツの再生手順を示すフローチャートである。ＨＴＴＰリクエスト送信部４０は、ＨＴＴＰリクエストを送信する（Ｓ５０）。ＨＴＴＰレスポンス受信部４２は、ＨＴＴＰレスポンスを受信する（Ｓ５２）。ＨＴＴＰヘッダ解析部４６は、ＨＴＴＰヘッダを解析する（Ｓ５４）。再生部４８は、コンテンツを再生する（Ｓ５６）。再生終了でなければ（Ｓ５８のＮ）、ステップ５６に戻る。再生終了であり（Ｓ５８のＹ）、連続再生可能であれば（Ｓ６０のＹ）、再生用生成部４４は、ＨＴＴＰヘッダを生成し（Ｓ６２）、ステップ５０に戻る。連続再生可能でなければ（Ｓ６０のＮ）、処理は終了される。
【００４２】
次に、変形例を説明する。変形例も、実施例と同様の再生システムであって、配信装置がコンテンツを送信し、再生装置がコンテンツを再生する。実施例では、コンテンツとして静止画像を説明の対象にした。しかしながら変形例では、コンテンツとして、静止画像だけではなく、動画像も説明の対象にする。そのため、ＨＴＴＰヘッダには、コンテンツのアドレスに加えて、当該コンテンツの属性情報も格納される。ここで、コンテンツの属性情報では、例えば、コンテンツの種類が示される。変形例にかかる再生システム１００は、図１に示された再生システム１００と同様のタイプである。そのため、ここでは、差異の部分を中心に説明する。
【００４３】
第２記憶部２２は、実施例と同様に、第１記憶部２０に記憶された複数のコンテンツに関する情報として、アドレスを記憶する。また、第２記憶部２２は、複数のコンテンツのそれぞれに対する属性の情報（以下、「属性情報」という）も記憶する。属性情報とは、例えば、コンテンツの種別であり、コンテンツが静止画像、動画像等のいずれかに相当するかに関する情報である。また、属性情報は、動画像の場合に、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）２などの圧縮方式を示していてもよい。追加部２６は、実施例での処理に加えて、第２記憶部２２から、再生装置１２が取得可能な別のコンテンツの属性情報も取得する。配信用生成部２４は、ＨＴＴＰレスポンスを生成する際、ＨＴＴＰヘッダに、別のコンテンツのアドレスとともに、当該別のコンテンツの属性情報も含める。
【００４４】
図７は、本発明の変形例に係る再生システム１００において使用されるＨＴＴＰレスポンスの一例を示す。図示されたＨＴＴＰヘッダ群において、前述のごとく、「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」の独自フィールド名を持つヘッダが、後段のコンテンツ「Ｆｉｌｅ１０７」に該当するＵＲＬ情報を示す。さらに、「Ｘ−ＮｅｘｔＰｌａｙＣｏｎｔｅｎｔｓＦｏｒｍａｔ」の独自フィールド名を持つヘッダが、後段のコンテンツ「Ｆｉｌｅ１０７」に該当する属性情報を示す。ここでは、「ＭＰＥＧ＿ＴＳ」と示されているので、コンテンツ「Ｆｉｌｅ１０７」は、ＭＰＥＧ２にて圧縮された動画像である。
【００４５】
次に、図８をもとに、再生装置１２においてコンテンツが選択される際の動作を説明する。図８は、表示部５２に表示されたコンテンツ選択画面を示す。第１記憶部２０に記憶された複数の静止画像や動画像、例えば、５００のコンテンツのうち、途中の１０のコンテンツが「Ｆｉｌｅ１０１」から「Ｆｉｌｅ１１０」としてサムネイル表示されている。ここで、「Ｆｉｌｅ１０１」は静止画像であり、「Ｆｉｌｅ１０２」は動画像であるように、コンテンツとして、静止画像と動画像とが混在している。また、５００のコンテンツは、連続再生コンテンツグループを形成している。再生部４８は、現時点においてこの１０のコンテンツのアドレスであるＵＲＬ、コンテンツの種類、サイズを保持している。なお、残りのコンテンツに対するアドレス等は、再生部４８に保持されていない。
【００４６】
図１の表示部５２がコンテンツ選択画面を表示しているときに、ユーザが操作部５０を操作することによって、「Ｆｉｌｅ１０６」のコンテンツが選択される。これにつづいて、前述のＨＴＴＰリクエストおよびＨＴＴＰレスポンスの送信がなされ、表示部５２は、「Ｆｉｌｅ１０６」のコンテンツを表示する。「Ｆｉｌｅ１０６」のコンテンツが表示された後、再生部４８において実行されているアプリケーションプログラムが、時間軸に沿ったスライドショーであるならば、再生部４８は、コンテンツ選択画面に戻らない。その代わりに、再生部４８は、直ちに「Ｘ−ＮｅｘｔＰｌａｙＵＲＬ」にて示された「Ｆｉｌｅ１０７」のＵＲＬを選択する。また、再生部４８は、「Ｘ−ＮｅｘｔＰｌａｙＣｏｎｔｅｎｔｓＦｏｒｍａｔ」にしたがって、動画像を再生するための準備を実行する。なお、次のコンテンツを再生するのに必要な独自ヘッダとして、各種コンテンツフォーマット別に必要な再生属性情報、以前途中まで再生した動画や音楽におけるレジューム再生位置情報が含まれていてもよい。
【００４７】
本発明の実施例によれば、ＨＴＴＰリクエストに応じてコンテンツを送信する際に、別のコンテンツのアドレスもＨＴＴＰレスポンスにて送信するので、コンテンツの送受信以外のネットワーク通信を不要としながらも、別のコンテンツのアドレスを通知できる。また、ＨＴＴＰレスポンスにて別のコンテンツのアドレスとコンテンツとを通知するので、コンテンツの送受信以外のネットワーク通信を不要としながらも、コンテンツを連続再生できる。また、別のコンテンツのアドレスをＨＴＴＰヘッダに含めるので、ＨＴＴＰヘッダのみを出力することによっても、別のコンテンツのアドレスを通知できる。また、別のコンテンツのアドレスをＨＴＴＰヘッダに含めるので、ＨＴＴＰボディを送信しなくても、別のコンテンツのアドレスを通知できる。
【００４８】
また、別のコンテンツのアドレスとともに、別のコンテンツの属性情報も出力するので、別のコンテンツの属性情報を通知できる。また、別のコンテンツのアドレスとともに、別のコンテンツの属性情報も出力するので、さまざまな種類のコンテンツが混在している場合でも対応できる。また、ＨＴＴＰレスポンスに応じたコンテンツを受信する際に、別のコンテンツのアドレスも一体的に受信するので、コンテンツの送受信以外のネットワーク通信を不要としながらも、別のコンテンツのアドレスを取得できる。また、別のコンテンツのアドレスを取得するので、直ちに当該アドレスへのＨＴＴＰリクエストを送信できる。
【００４９】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５０】
本発明の実施例において、追加部２６は、ＨＴＴＰヘッダに独自フィールドとして、別のコンテンツのアドレスや属性情報を追加している。しかしながらこれに限らず例えば、追加部２６は、独自ヘッダに他の内容を追加してもよい。例えば、連続再生中に前回再生したコンテンツにスキップして戻り再生を行うために、前回のコンテンツのＵＲＬが示されたヘッダ、連続再生コンテンツのフォーマットの違いやサイズなどの違いによって、再生部４８が初期設定を変更できるように、これらの情報が示されたヘッダが追加されてもよい。本変形によれば、再生部４８において再生されるコンテンツの多様化を実現できる。
【符号の説明】
【００５１】
１０ 配信装置、 １２ 再生装置、 ２０ 第１記憶部、 ２２ 第２記憶部、 ２４ 配信用生成部、 ２６ 追加部、 ２８ ＨＴＴＰリクエスト受信部、 ３０ ＨＴＴＰレスポンス送信部、 ３２ 配信用制御部、 ４０ ＨＴＴＰリクエスト送信部、 ４２ ＨＴＴＰレスポンス受信部、 ４４ 再生用生成部、 ４６ ＨＴＴＰヘッダ解析部、 ４８ 再生部、 ５０ 操作部、 ５２ 表示部、 ５４ 再生用制御部、 １００ 再生システム。
【特許請求の範囲】
【請求項１】
ネットワークを介して接続された再生装置から、当該再生装置において再生が要求されている第１のデータのアドレスを受けつけるステップと、
受けつけた前記アドレスをもとに、記憶媒体に記憶された前記第１のデータを取得するとともに、前記再生装置が取得可能な前記第１のデータとは別のデータである第２のデータのアドレスも取得するステップと、
取得した前記第１のデータと、前記第２のデータのアドレスとを一体的に組み合わせて出力するステップと、
を備えることを特徴とする配信方法。
【請求項２】
前記出力するステップは、ヘッダと、前記取得した第１のデータとを組み合わせたフレームを出力しており、前記第２のデータのアドレスを前記ヘッダに含めることを特徴とする請求項１に記載の配信方法。
【請求項３】
前記取得するステップは、前記再生装置が取得可能な前記第２のデータの属性情報も取得し、
前記出力するステップは、前記第２のデータのアドレスとともに、前記第２のデータの属性情報も出力することを特徴とする請求項１または２に記載の配信方法。
【請求項４】
ネットワークを介して接続された再生装置から、当該再生装置において再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を受けつける受付部と、
前記受付部において受けつけた前記ＨＴＴＰコンテンツ要求に含まれた前記アドレスをもとに、記憶媒体に記憶された前記第１のデータを取得するとともに、前記再生装置が取得可能な前記第１のデータとは別のデータである第２のデータのアドレスも取得する取得部と、
前記取得部において取得した前記第１のデータを、前記ＨＴＴＰコンテンツ要求に対するＨＴＴＰコンテンツ応答として前記再生装置へ出力する際に、前記ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに、取得した前記第２のデータのアドレスを含めて出力する出力部と、
を備えることを特徴とする配信装置。
【請求項５】
ネットワークを介して接続された配信装置へ、再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を出力する出力部と、
前記出力部が前記ＨＴＴＰコンテンツ要求を出力した配信装置から、前記アドレスに対応した前記第１のデータが含まれたＨＴＴＰコンテンツ応答を受けつける受付部と、
前記受付部において受けつけたＨＴＴＰコンテンツ応答に含まれた前記第１のデータを再生するとともに、ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに含まれている、取得可能な前記第１のデータとは別のデータである第２のデータのアドレスを取得する再生部とを備え、
前記出力部は、新たなＨＴＴＰコンテンツ要求に、前記第２のデータのアドレスを含めることを特徴とする再生装置。
【請求項６】
ネットワークを介して、再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を出力する再生装置と、
受けつけた前記ＨＴＴＰコンテンツ要求に含まれた前記アドレスをもとに、記憶媒体に記憶された前記第１のデータを取得した後、前記第１のデータを前記ＨＴＴＰコンテンツ要求に対するＨＴＴＰコンテンツ応答として前記再生装置へ出力する際に、前記ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに、取得した前記第１のデータとは別のデータである第２のデータのアドレスを含めて出力する配信装置とを備え、
前記再生装置は、受けつけた前記ＨＴＴＰコンテンツ応答に含まれた前記第１のデータを再生するとともに、新たなＨＴＴＰコンテンツ要求に、取得可能な前記第２のデータのアドレスを含めることを特徴とする配信システム。
【請求項７】
ネットワークを介して接続された再生装置から、当該再生装置において再生が要求されている第１のデータのアドレスを受けつけるステップと、
受けつけた前記アドレスをもとに、記憶媒体に記憶された前記第１のデータを取得するとともに、前記再生装置が取得可能な前記第１のデータとは別のデータである第２のデータのアドレスも取得するステップと、
取得した前記第１のデータと前記第２のデータのアドレスとを一体的に組み合わせて出力するステップと、
をコンピュータに実行させるための配信プログラム。
【請求項１】
ネットワークを介して接続された再生装置から、当該再生装置において再生が要求されている第１のデータのアドレスを受けつけるステップと、
受けつけた前記アドレスをもとに、記憶媒体に記憶された前記第１のデータを取得するとともに、前記再生装置が取得可能な前記第１のデータとは別のデータである第２のデータのアドレスも取得するステップと、
取得した前記第１のデータと、前記第２のデータのアドレスとを一体的に組み合わせて出力するステップと、
を備えることを特徴とする配信方法。
【請求項２】
前記出力するステップは、ヘッダと、前記取得した第１のデータとを組み合わせたフレームを出力しており、前記第２のデータのアドレスを前記ヘッダに含めることを特徴とする請求項１に記載の配信方法。
【請求項３】
前記取得するステップは、前記再生装置が取得可能な前記第２のデータの属性情報も取得し、
前記出力するステップは、前記第２のデータのアドレスとともに、前記第２のデータの属性情報も出力することを特徴とする請求項１または２に記載の配信方法。
【請求項４】
ネットワークを介して接続された再生装置から、当該再生装置において再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を受けつける受付部と、
前記受付部において受けつけた前記ＨＴＴＰコンテンツ要求に含まれた前記アドレスをもとに、記憶媒体に記憶された前記第１のデータを取得するとともに、前記再生装置が取得可能な前記第１のデータとは別のデータである第２のデータのアドレスも取得する取得部と、
前記取得部において取得した前記第１のデータを、前記ＨＴＴＰコンテンツ要求に対するＨＴＴＰコンテンツ応答として前記再生装置へ出力する際に、前記ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに、取得した前記第２のデータのアドレスを含めて出力する出力部と、
を備えることを特徴とする配信装置。
【請求項５】
ネットワークを介して接続された配信装置へ、再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を出力する出力部と、
前記出力部が前記ＨＴＴＰコンテンツ要求を出力した配信装置から、前記アドレスに対応した前記第１のデータが含まれたＨＴＴＰコンテンツ応答を受けつける受付部と、
前記受付部において受けつけたＨＴＴＰコンテンツ応答に含まれた前記第１のデータを再生するとともに、ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに含まれている、取得可能な前記第１のデータとは別のデータである第２のデータのアドレスを取得する再生部とを備え、
前記出力部は、新たなＨＴＴＰコンテンツ要求に、前記第２のデータのアドレスを含めることを特徴とする再生装置。
【請求項６】
ネットワークを介して、再生が要求されている第１のデータのアドレスが含まれたＨＴＴＰコンテンツ要求を出力する再生装置と、
受けつけた前記ＨＴＴＰコンテンツ要求に含まれた前記アドレスをもとに、記憶媒体に記憶された前記第１のデータを取得した後、前記第１のデータを前記ＨＴＴＰコンテンツ要求に対するＨＴＴＰコンテンツ応答として前記再生装置へ出力する際に、前記ＨＴＴＰコンテンツ応答のＨＴＴＰヘッダに、取得した前記第１のデータとは別のデータである第２のデータのアドレスを含めて出力する配信装置とを備え、
前記再生装置は、受けつけた前記ＨＴＴＰコンテンツ応答に含まれた前記第１のデータを再生するとともに、新たなＨＴＴＰコンテンツ要求に、取得可能な前記第２のデータのアドレスを含めることを特徴とする配信システム。
【請求項７】
ネットワークを介して接続された再生装置から、当該再生装置において再生が要求されている第１のデータのアドレスを受けつけるステップと、
受けつけた前記アドレスをもとに、記憶媒体に記憶された前記第１のデータを取得するとともに、前記再生装置が取得可能な前記第１のデータとは別のデータである第２のデータのアドレスも取得するステップと、
取得した前記第１のデータと前記第２のデータのアドレスとを一体的に組み合わせて出力するステップと、
をコンピュータに実行させるための配信プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１０−２０４９１１（Ｐ２０１０−２０４９１１Ａ）
【公開日】平成２２年９月１６日（２０１０．９．１６）
【国際特許分類】
【出願番号】特願２００９−４９２１７（Ｐ２００９−４９２１７）
【出願日】平成２１年３月３日（２００９．３．３）
【出願人】（０００００４３２９）日本ビクター株式会社 (3,896)
【Ｆターム（参考）】
【公開日】平成２２年９月１６日（２０１０．９．１６）
【国際特許分類】
【出願日】平成２１年３月３日（２００９．３．３）
【出願人】（０００００４３２９）日本ビクター株式会社 (3,896)
【Ｆターム（参考）】
[ Back to top ]