(57)【要約】【課題】ＡＶコンテンツを再生する場合、通常ＡＶコンテンツを構成する再生ブロック（例えばＧＯＰ）の構成に関する情報が必要となる。ネットワーク再生の場合は、ＡＶコンテンツ再生装置がこの情報をＡＶサーバから取得しなくてはならなかった。本発明は、このような情報の送受信を不要にしたＡＶコンテンツの再生方法、ＡＶサーバ、ＡＶコンテンツ再生装置を提供する。【解決手段】ＡＶコンテンツ再生装置が開始要求位置を指定して再生開始要求を送信し、ＡＶサーバはその開始要求位置付近で、かつ再生ブロック（例えばＧＯＰ）の先頭となる位置から送信を開始する。【選択図】  図２
2005027010.tif 000002
【特許請求の範囲】
【請求項１】
画像または音声またはその両方を含み、かつ複数の再生ブロックから構成されるＡＶコンテンツを一つ以上保持している蓄積手段と、
ＡＶコンテンツを識別する情報であるＡＶコンテンツ識別子と当該ＡＶコンテンツ識別子で識別されるＡＶコンテンツのどの位置から再生を開始するべきかを指示する開始要求位置を示す情報である開始要求位置情報を有する再生開始要求を受信する再生要求受信手段と、
前記開始要求位置情報が示す前記開始要求位置付近の前記再生ブロックの先頭を送信開始位置として決定する送信データ決定手段と、
前記再生要求受信手段が受信した再生開始要求が有するＡＶコンテンツ識別子で識別されるＡＶコンテンツを前記送信開始位置から送信する送信手段を具備するＡＶサーバ。
【請求項２】
前記送信手段は、前記送信開始位置を示す情報である送信開始位置情報も送信することを特徴とする請求項１に記載のＡＶサーバ。
【請求項３】
前記再生開始要求に、要求サイズを示す情報である要求サイズ情報が含まれ、
前記送信データ決定手段は、送信するデータ量が前記要求サイズ以下で、かつ、送信するデータの終わりが前記再生ブロックのいずれかの終わりとなるように送信終了位置を決定し、
前記送信手段は、前記ＡＶコンテンツの前記送信開始位置から前記送信終了位置までを送信することを特徴とする請求項１または請求項２いずれかに記載のＡＶサーバ。
【請求項４】
前記再生開始要求に、ＡＶコンテンツのどの位置までの送信を行うべきかを指示する終了要求位置を示す情報である終了要求位置情報が含まれ、
前記送信データ決定手段は、送信するデータの終わりが前記再生ブロックのいずれかの終わりとなり、かつ前記終了要求位置を超えない位置を送信終了位置として決定し、
前記送信手段は、前記ＡＶコンテンツの前記送信開始位置から前記送信終了位置までを送信することを特徴とする請求項１または請求項２いずれかに記載のＡＶサーバ。
【請求項５】
前記送信手段は、前記送信終了位置を示す情報である送信終了位置情報も送信することを特徴とする請求項３または請求項４いずれかに記載のＡＶサーバ。
【請求項６】
ＡＶコンテンツを識別する情報であるＡＶコンテンツ識別子を有する入力を受け付けるユーザ入力手段と、
前記ユーザ入力手段が受け付けたＡＶコンテンツ識別子により識別されるＡＶコンテンツの再生をどの位置から始めるかを要求する開始要求位置を決定する受信データ決定手段と、
前記ＡＶコンテンツ識別子と前記開始要求位置を示す情報である開始要求位置情報を含む再生開始要求を送信する再生要求送信手段と、
前記再生開始要求の送信に対応して、ＡＶコンテンツ受信する受信手段と、
前記受信手段が受信したＡＶコンテンツを再生する再生手段を具備するＡＶコンテンツ再生装置。
【請求項７】
前記受信手段は、前記ＡＶコンテンツと、前記ＡＶコンテンツのどの位置までのデータを含んでいるかを示す送信終了位置を特定する情報である送信終了位置情報を受信し、
前記受信データ決定手段が、前記ユーザ入力手段が受け付けたＡＶコンテンツ識別子により識別されるＡＶコンテンツの再生をどの位置から始めるかを要求する開始要求位置を決定し、かつ、前記受信した送信終了位置情報から次の開始要求位置を決定することを特徴とする請求項６記載のＡＶコンテンツ再生装置。
【請求項８】
前記受信手段は、前記ＡＶコンテンツと、前記ＡＶコンテンツ内のどの位置からのデータを含んでいるかを示す送信開始位置を特定する情報である送信開始位置情報を受信し、
前記受信データ決定手段は、前記ユーザ入力手段が受け付けたＡＶコンテンツ識別子により識別されるＡＶコンテンツの再生をどの位置から始めるかを要求する開始要求位置を決定し、かつ、前記送信開始位置情報と前記受信したＡＶコンテンツのサイズに基づいて、次の開始要求位置を決定することを特徴とする請求項６に記載のＡＶコンテンツ再生装置。
【請求項９】
前記受信データ決定手段は、送信を要求するサイズである要求サイズも決定し、
前記再生要求送信手段が、前記要求サイズを示す情報である要求サイズ情報を前記再生開始要求に含ませて送信することを特徴とする請求項６から請求項８いずれかに記載のＡＶコンテンツ再生装置。
【請求項１０】
前記受信データ決定手段は、前記ＡＶコンテンツのどの位置まで再生を要求するか示す終了要求位置も決定し、
前記再生要求送信手段は、前記終了要求位置を示す情報である終了要求位置情報を前記再生開始要求に含ませて送信することを特徴とする請求項６から請求項８いずれかに記載のＡＶコンテンツ再生装置。
【請求項１１】
前記ＡＶコンテンツがＭＰＥＧ動画像であり、前記再生ブロックのそれぞれがＧＯＰであることを特徴とする請求項６から請求項１０いずれかに記載のＡＶコンテンツ再生装置。
【請求項１２】
前記ＡＶコンテンツがＤＶＤ−ＶＲフォーマットの動画像であり、前記再生ブロックのそれぞれがＶＯＢＵであることを特徴とする請求項６から請求項１０いずれかに記載のＡＶコンテンツ再生装置。
【請求項１３】
前記再生開始要求の送信、および前記ＡＶコンテンツの受信が、ＨＴＴＰによることを特徴とする請求項６から請求項１２いずれかに記載のＡＶコンテンツ再生装置。
【請求項１４】
前記再生開始要求の送信、および前記ＡＶコンテンツの受信が、ＨＴＴＰにより、前記開始要求位置情報はＨＴＴＰのＲａｎｇｅヘッダに記録されていることを特徴とする請求項６から請求項１３いずれかに記載のＡＶコンテンツ再生装置。
【請求項１５】
前記再生開始要求の送信、および前記ＡＶコンテンツの受信が、ＨＴＴＰにより、前記送信開始位置情報はＨＴＴＰのＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダに記録されていることを特徴とする請求項７から請求項１３いずれかに記載のＡＶコンテンツ再生装置。
【請求項１６】
前記再生開始要求の送信、および前記ＡＶコンテンツの受信が、ＨＴＴＰにより、前記終了要求位置情報はＨＴＴＰのＲａｎｇｅヘッダに記録されていることを特徴とする請求項１０から請求項１４いずれかに記載のＡＶコンテンツ再生装置。
【請求項１７】
前記再生開始要求の送信、および前記ＡＶコンテンツの受信が、ＨＴＴＰにより、前記送信開始位置情報及び前記送信終了位置情報はＨＴＴＰのＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダに記録されていることを特徴とする請求項１０記載のＡＶコンテンツ再生装置。
【請求項１８】
前記ユーザ入力手段は、ＡＶコンテンツ識別子と当該ＡＶコンテンツ識別子で識別されるＡＶコンテンツの位置を指定する時間情報を有する入力を受け付け、
受信データ決定手段は、前記時間情報に基づいて開始要求位置を決定することを特徴とする請求項６から請求項１７いずれかに記載ＡＶコンテンツ再生装置。
【請求項１９】
コンピュータに、
ＡＶコンテンツ識別子と開始要求位置情報を有する再生開始要求を受信するステップと、
前記開始要求位置情報が示す前記開始要求位置付近の再生ブロックの先頭を送信開始位置として決定するステップと、
前記受信した再生開始要求が有するＡＶコンテンツ識別子で識別されるＡＶコンテンツを前記送信開始位置から送信するステップを実行させるためのプログラム。
【請求項２０】
コンピュータに、
ＡＶコンテンツ識別子を有する入力を受け付ける入力ステップと、
ＡＶコンテンツの再生位置である開始要求位置を決定する決定ステップと、
前記ＡＶコンテンツ識別子と前記決定した開始要求位置を示す情報である開始要求位置情報を含む再生開始要求を送信する送信ステップと、
前記再生開始要求の送信に対応して、ＡＶコンテンツを受信する受信ステップと、
前記受信したＡＶコンテンツを再生する再生ステップを実行させるためのプログラム。
【請求項２１】
前記受信ステップにおいて、前記ＡＶコンテンツとともに、前記ＡＶコンテンツ内のどの位置からのデータを含んでいるかを示す送信開始位置を示す情報である送信開始位置情報を受信し、
前記決定ステップにおいて、受け付けた入力から、ＡＶコンテンツの再生位置である開始要求位置を決定し、かつ、前記送信開始位置情報と前記受信したＡＶコンテンツのサイズに基づいて、次の開始要求位置を決定する請求項２０記載のプログラム。
【請求項２２】
前記決定ステップにおいて、前記ＡＶサーバに送信を要求するサイズである要求サイズも決定し、
前記送信ステップにおいて、前記要求サイズを示す情報である要求サイズ情報を前記再生開始要求に含ませて送信する請求項２０または請求項２１いずれか記載のプログラム。
【請求項２３】
前記決定ステップにおいて、前記ＡＶコンテンツのどの位置まで再生を要求するか示す終了要求位置も決定し、
前記送信ステップにおいて、前記終了要求位置を示す情報である終了要求位置情報を前記再生開始要求に含ませて送信する請求項２０または請求項２１いずれか記載のプログラム。
【請求項２４】
前記受信ステップにおいて、記ＡＶサーバからＡＶコンテンツともに、前記ＡＶコンテンツのどの位置までのデータを含んでいるかを示す送信終了位置情報を受信し、
決定ステップにおいて、前記受信した送信終了位置情報から次の開始要求位置を決定する請求項２０から請求項２３いずれか記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、画像や音声等のＡＶコンテンツを蓄積しているＡＶサーバと、ＡＶサーバにネットワークで接続され、ＡＶコンテンツの再生をネットワーク経由で行うＡＶコンテンツ再生装置等に関する。
【０００２】
【従来の技術】
一般にＡＶコンテンツは、ＭＰＥＧのような圧縮方式によって圧縮されていることが多い。この場合、ＡＶコンテンツは所定の方法で再生ブロック（ＭＰＥＧでは例えばＧＯＰ）に分けられ、その再生ブロック内ではＡＶコンテンツの他の部分を参照せずにデコードできるようになっている。デコーダにはこのブロックの先頭から入力する必要がある。従って、ＡＶコンテンツをネットワーク経由で再生しようとする場合も、この再生ブロック単位での送受信が必要となる。
【０００３】
従来のＡＶコンテンツのＡＶサーバ、ＡＶコンテンツ再生装置については、例えば特許文献１に記載されているようなものがあった。特許文献１では、ＡＶサーバがあらかじめＡＶコンテンツを解析して、所定の時間単位でＡＶコンテンツを分割する。その際、上記の再生ブロック単位で分割される。ＡＶコンテンツの分割それぞれと、その再生時間情報やサイズとの対応情報を作成し、ＡＶサーバ内に保持しておく。ＡＶコンテンツをネットワーク再生する前に、ＡＶサーバからＡＶコンテンツ再生装置に上記の対応情報を送信しておく。ＡＶコンテンツ再生装置は、この対応情報を見て、ＡＶコンテンツの分割単位でＡＶサーバへ送信を要求する。
このことによって、ＡＶコンテンツ再生装置は、ＡＶコンテンツの各部分を再生ブロックの先頭から自身のデコーダへ入力することができるようになる。
【０００４】
【特許文献１】
特開２００３−４６９２８号公報（第１頁、第１図等）
【０００５】
【発明が解決しようとする課題】
しかし、上記の方法では、ＡＶコンテンツ再生装置側に対応情報を解釈する機構が必要となり、ＡＶコンテンツ再生装置の負荷が大きい。ＡＶコンテンツのサイズが大きくなるにつれ対応情報のサイズも大きくなるので、ＡＶコンテンツ再生装置側のメモリ容量が足りなくなる可能性がある。また、対応情報を解釈できないＡＶコンテンツ再生装置は、ネットワークでの再生ができない。さらに、ＡＶサーバ本体での編集作業等によりＡＶコンテンツの内容に変化があった場合、対応表の内容と実際のＡＶコンテンツの状態が一致せず、不整合を起こす場合がある。
【０００６】
【課題を解決するための手段】
上記課題を解決するための第一の発明におけるＡＶコンテンツのネットワーク再生方法は、ＡＶコンテンツ再生装置が、ＡＶコンテンツを識別するＡＶコンテンツ識別子と開始要求位置情報を有する再生開始要求をＡＶサーバに送信する、再生要求ステップを含む。また、ＡＶサーバがこの再生開始要求を受信し、指定された開始要求位置付近の再生ブロックの先頭を送信開始位置として決定する、送信データ決定ステップを含む。さらに、ＡＶサーバが指定されたＡＶコンテンツを、送信開始位置から送信する送信ステップを含む。さらに、ＡＶコンテンツ再生装置が、前記送信ステップで送信されたＡＶコンテンツを受信するステップを含む。このことにより、ＡＶコンテンツ再生装置は、再生ブロックの位置に関する正確な情報を持っていなくても、再生ブロックの先頭からネットワーク再生できる。
【０００７】
また、第二の発明におけるＡＶコンテンツのネットワーク再生方法は、第一の発明のネットワーク再生方法における送信ステップで、送信開始位置情報も送信する。このことにより、ＡＶコンテンツ再生装置では、受信した送信開始位置とデータのサイズから次に要求する再生ブロックの先頭を推定することができ、次の再生開始要求で正確な再生開始位置を指定可能になる。こうすると、ＡＶサーバが開始要求位置付近の再生ブロックの先頭を見つけだす必要がなくなり、ＡＶサーバの負荷が軽減される。
【０００８】
また、第三の発明における方法は、第一の発明または第二の発明のいずれかの方法において、再生開始要求が要求サイズを示す情報である要求サイズ情報も含む。また送信データ決定ステップにおいて、ＡＶサーバは、送信するデータ量が要求サイズ以下で、かつ、送信するデータの終わりが再生ブロックのいずれかの終わりとなるように送信終了位置を決定し、送信ステップにおいて、指定されたＡＶコンテンツを、送信開始位置から送信終了位置まで送信する。このことにより、ＡＶコンテンツ再生装置が受信用に割り当てられたバッファの空き具合に応じてＡＶコンテンツのデータを受信できる。
【０００９】
また、第四の発明における方法は、第一の発明または第二の発明のいずれかの方法において、ＡＶコンテンツ再生装置が送信する再生開始要求は、ＡＶコンテンツのどの位置まで送信を行うべきかを指示する終了要求位置を示す終了要求位置情報含む。また、送信データ決定ステップにおいて、ＡＶサーバは、送信するデータの終わりが再生ブロックのいずれかの終わりとなり、かつ終了要求位置を超えない位置を送信終了位置として決定し、送信ステップにおいて、指定されたＡＶコンテンツを、送信開始位置から送信終了位置まで送信する。このことにより、ＡＶコンテンツ再生装置が受信用に割り当てられたバッファの空き具合に応じてＡＶコンテンツのデータを受信できる。第三の発明における方法に比べて、ＡＶサーバのサイズ計算の負荷が軽減される。
【００１０】
第五の発明における方法は、第三の発明または第四の発明のいずれかの方法において、送信ステップで、ＡＶサーバは、送信終了位置情報も送信する。このことにより、ＡＶコンテンツ再生装置は、次に再生する再生ブロックの先頭が容易に分かるようになり、次の再生開始要求で正確な再生開始位置を指定可能になる。こうすると、ＡＶサーバが開始要求位置付近の再生ブロックの先頭を見つけだす必要がなくなり、ＡＶサーバの負荷が軽減される。
【００１１】
第六の発明における方法は、第五の発明における方法において、ＡＶコンテンツ再生装置が、送信終了位置情報を受信し、次に再生開始要求を送信する際、次の再生ブロックの先頭を、受信した送信終了位置情報に基づいて開始要求位置情報を決定する。このことにより、再生開始要求で正確な再生開始位置を指定可能になる。こうすると、ＡＶサーバが開始要求位置付近の再生ブロックの先頭を見つけだす必要がなくなり、ＡＶサーバの負荷が軽減される。
【００１２】
第七の発明における方法は、第一から第六の方法において、ＡＶコンテンツがＭＰＥＧ動画像であり、再生ブロックのそれぞれがＧＯＰである。このことにより、ＭＰＥＧ動画像の場合、ＡＶコンテンツ再生装置においてＧＯＰ単位で再生することができる。
【００１３】
第八の発明における方法は、第一から第六の方法において、ＡＶコンテンツがＤＶＤ−ＶＲフォーマット動画像であり、再生ブロックのそれぞれがＶＯＢＵである。このことにより、ＤＶＤ−ＶＲフォーマット動画像の場合、ＡＶコンテンツ再生装置においてＶＯＢＵ単位で再生することができる。
【００１４】
第九の発明における方法は、第一から第八の方法において、ＡＶサーバとＡＶコンテンツ再生装置間の送受信が、ＨＴＴＰによる。このことにより、標準的なプロトコルで、第一から第八の発明の効果が得られる。
【００１５】
第十の発明における方法は、第一から第九の方法において、ＡＶサーバとＡＶコンテンツ再生装置間の送受信が、ＨＴＴＰにより、開始要求位置情報をＨＴＴＰのＲａｎｇｅヘッダに記録する。このことにより、標準的なプロトコルで、かつ標準的なヘッダを使って第一から第九に記載の発明の効果が得られる。
【００１６】
第十一の発明における方法は、第二の方法において、ＡＶサーバとＡＶコンテンツ再生装置間の送受信が、ＨＴＴＰにより、送信開始位置情報をＨＴＴＰのＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダに記録する。このことにより、標準的なプロトコルで、かつ標準的なヘッダを使って第二の発明の効果が得られる。
【００１７】
第十二の発明における方法は、第四の方法において、ＡＶサーバとＡＶコンテンツ再生装置間の送受信が、ＨＴＴＰにより、終了要求位置情報をＨＴＴＰのＲａｎｇｅヘッダに記録する。このことにより、標準的なプロトコルで、かつ標準的なヘッダを使って第四の発明の効果が得られる。
【００１８】
第十三の発明における方法は、第五の方法に加えて、ＡＶサーバとＡＶコンテンツ再生装置間の送受信が、ＨＴＴＰにより、送信開始位置情報及び送信終了位置情報をＨＴＴＰのＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダに記録する。このことにより、標準的なプロトコルで、かつ標準的なヘッダを使って第五の発明の効果が得られる。
【００１９】
第十四の発明における方法は、第一から第十三の方法に加えて、ＡＶコンテンツ内の位置の指定が時間情報による。このことにより、ＡＶコンテンツの再生を時間で管理しているＡＶコンテンツ再生装置であっても、第一から第十三の発明の効果が得られる。ただし、現在、Ｒａｎｇｅヘッダ及びＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダでの指定はバイト値のみなので、時間情報で指定しようとする場合は、拡張ヘッダを用いざるを得ない。将来的にＲａｎｇｅヘッダ、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダが時間情報を扱えるようになった場合、より有効となる。
【発明の実施の形態】
以下、本発明の一実施の形態について、図面を参照しながら説明する。
【００２０】
図１は、本実施形態が適用されるネットワークの構成図である。ＡＶサーバ１は、蓄積手段１１に記録されているＡＶコンテンツを、ＡＶコンテンツ再生装置２からの要求に応じて、ネットワーク３上に送信する。ＡＶコンテンツ再生装置２は、ＡＶサーバ１からＡＶコンテンツを受信し、再生する。ＡＶコンテンツとは、ここでは、画像または音声またはその両方を含み、かつ複数の再生ブロックから構成されるデータである。画像とは、動画像、静止画を含む。なお、本実施例では、ＡＶコンテンツの例としてＤＶＤ−ＶＲフォーマットの動画像をあげ、ＡＶコンテンツ再生装置２が送信を要求するＤＶＤ−ＶＲフォーマット動画像の名前を「ｐｒｏｇ．ｖｏｂ」とする。
【００２１】
図２は、ＡＶサーバ１とＡＶコンテンツ再生装置２間の送受信を記述したシーケンス図である。本実施形態ではこの送受信にＨＴＴＰプロトコルを用いる。ただし、送受信のプロトコルは問わない。図２はＡＶサーバ１の蓄積手段１１に記録されているｐｒｏｇ．ｖｏｂを、ＡＶコンテンツ再生装置２が動画像の最初からネットワーク再生する場合の例である。図３にｐｒｏｇ．ｖｏｂの構成を例示する。ｐｒｏｇ．ｖｏｂは、トータルサイズが、２２５１２９６７６８バイトで、Ｎ個のＶＯＢＵ（Ｖｉｄｅｏ  ＯＢｊｅｃｔ  Ｕｎｉｔ）から構成されている。１番目のＶＯＢＵの長さは１２９０２４０バイト、２番目のＶＯＢＵの長さは１２８８１９２バイトである。なお、ＶＯＢＵは、再生ブロックの例である。つまり、再生ブロックは他の構造で良く、データサイズも問わない。また、蓄積手段１１は、ハードディスクなどの不揮発性の記録媒体が好適であるが、揮発性の記録媒体でも実現可能である。
【００２２】
図２でＡＶコンテンツ再生装置は、最初に、再生開始要求であるメッセージ１をＡＶサーバ１に向けて送信する。メッセージ１はＲａｎｇｅヘッダを含み、ｐｒｏｇ．ｖｏｂの０バイト目から１９２００００バイト目までの送信を要求している。開始要求位置が０バイト目、終了要求位置が１９２００００バイト目となる。ここで、開始要求位置を示す情報である開始要求位置情報は「０」であり、終了要求位置を示す情報である終了要求位置情報は「１９２００００」である。また、開始要求位置情報および終了要求位置情報はＨＴＴＰのＲａｎｇｅヘッダに記録されている。
【００２３】
ＡＶサーバ１はこのメッセージ１を受信すると、メッセージ２を送信する。メッセージ２は、Ｃｏｎｔｅｎｔ−Ｒａｎｇｅヘッダを含み、要求されたｐｒｏｇ．ｖｏｂのうち、０バイト目から１２９０２３９バイト目の送信を行うことを示している。送信開始位置が０バイト目、送信終了位置が１２９０２３９バイト目となる。そして、送信開始位置を示す情報である送信開始位置情報は「０」であり、送信終了位置を示す情報である送信終了位置情報は「１２９０２３９」である。また、送信開始位置情報および送信終了位置情報は、ＨＴＴＰのＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダに記録されている。
【００２４】
ここで０バイト目から１２９０２３９バイト目は、ｐｒｏｇ．ｖｏｂの最初のＶＯＢＵ（Ｖｉｄｅｏ  ＯＢｊｅｃｔ  Ｕｎｉｔ）を構成している。ＡＶサーバ１は１９２００００バイト目までの送信を要求されているが、１９２００００を超えないＶＯＢＵの区切りである１２９０２３９バイト目までを送信する。つまり、ＡＶサーバ１は、送信するデータの終わりが再生ブロックのいずれかの終わりとなり、かつ受信した終了要求位置情報が示す終了要求位置を超えない位置を送信終了位置として決定する。そして、ＡＶサーバ１は、送信終了位置として決定した１２９０２３９バイト目までを送信する。
【００２５】
また、ＡＶサーバ１が送信したメッセージ２が有するＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダの「／」以降で、ｐｒｏｇ．ｖｏｂのトータルサイズが２２５１２９６７６８バイトであることも示されている。メッセージ２のメッセージボディにｐｒｏｇ．ｖｏｂの最初のＶＯＢＵ（すなわち０バイト目から１２９０２３９バイト目）が格納され、ＡＶサーバ１からＡＶコンテンツ再生装置２へ、当該ｐｒｏｇ．ｖｏｂの最初のＶＯＢＵが転送される。
【００２６】
最初のＶＯＢＵの転送が終わると、ＡＶコンテンツ再生装置２は、メッセージ３を送信する。メッセージ３もメッセージ１と同様、Ｒａｎｇｅヘッダを含む。今度はｐｒｏｇ．ｖｏｂの１２９０２４０バイト目から３１９０２４０バイト目までの送信を要求する。この１２９０２４０バイト目は、メッセージ２のＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダで示された終点１２９０２３９の次のバイトを示す。つまり、ＡＶコンテンツ再生装置２は、送信終了位置情報に基づいて、次の開始要求位置を決定する。ＡＶコンテンツ再生装置２は、通常、「送信終了位置情報＋１」を次の開始要求位置を示す開始要求位置情報と決定するが、他の方法により、次の開始要求位置情報を決定しても良い。
【００２７】
メッセージ３の応答として、ＡＶサーバ１はＡＶコンテンツ再生装置２にメッセージ４を送る。メッセージ４にもＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダが含まれ、１２９０２４０バイト目から２５７８４３１バイト目までを送信することを示す。これは２番目のＶＯＢＵを構成する。以下、ｐｒｏｇ．ｖｏｂをすべて送信し終わるまで、上記を繰り返す。
【００２８】
図４は、本実施形態のＡＶサーバ１の構成を示すブロック図である。図４で、蓄積手段１１にはＤＶＤ−ＶＲフォーマットの動画像が一以上、蓄積されている。再生要求受信手段１２は、ネットワーク３を介してＡＶコンテンツ再生装置２からの再生開始要求を受信する。再生開始要求は、ＡＶコンテンツを識別する情報であるＡＶコンテンツ識別子と当該ＡＶコンテンツ識別子で識別されるＡＶコンテンツのどの位置から再生を開始するべきかを指示する開始要求位置を示す情報である開始要求位置情報を有する。
【００２９】
送信データ決定手段１３は、受信した再生開始要求から送信開始位置と送信終了位置を決定する。送信手段１４はＡＶコンテンツ再生装置２宛てに、再生開始要求で指定されたＤＶＤ−ＶＲフォーマット動画像を、送信開始位置から送信終了位置まで送信するとともに、送信開始位置を示す送信開始位置情報と送信終了位置を示す送信終了位置情報も送信する。再生要求受信手段１２、送信データ決定手段１３は、無線または有線の通信手段等で実現され得る。
【００３０】
図５は、本実施形態のＡＶサーバ１の動作を示すフローチャートである。以下、図５を使い、図２を用いて説明したシーケンスにおけるＡＶサーバ１の動作を説明する。
ＡＶサーバ１の再生要求受信手段１２が、再生開始要求であるＨＴＴＰメッセージ（ＧＥＴメソッドを含む；図２のメッセージ１、メッセージ３）を受信する（ステップ５０１）と、このＨＴＴＰメッセージが送信データ決定手段１３に送られる。
【００３１】
送信データ決定手段１３は、ＧＥＴメソッドが指定しているＵＲＩから送信を要求しているＡＶコンテンツの名前（図２ではｐｒｏｇ．ｖｏｂ）を抽出し（ステップ５０２）、またＲａｎｇｅヘッダから開始要求位置情報と終了要求位置情報とを抽出する（ステップ５０３）。次に送信データ決定手段１３は、蓄積手段１１を見て、要求されているＡＶコンテンツを構成するＶＯＢＵのうち、抽出した開始要求位置に最も近い位置から始まる（開始要求位置付近の）ＶＯＢＵを選び、その先頭を送信開始位置に設定する（送信開始位置情報に値を入力する）（ステップ５０４）。このとき、送信開始位置が開始要求位置と異なる値になった場合、終了要求位置の値（終了要求位置情報）を調整する。例えば、送信開始位置が開始要求位置よりＸバイトだけ大きい位置であれば、受信した終了要求位置情報にＸバイト足した値を以降の終了要求位置情報とする。図２のメッセージ１では０バイト目が、メッセージ３では１２９０２４０バイト目が選ばれている。（図２では、ｐｒｏｇ．ｖｏｂの先頭からの送信が要求されているため、１番目の再生開始要求から開始要求位置とＶＯＢＵの先頭が一致するが、例えば、メッセージ１のＲａｎｇｅヘッダで１２０００００バイト目から２５０００００バイト目までが指定されているような場合は、１２０００００バイト目に最も近い位置から始まるＶＯＢＵである２番目のＶＯＢＵが選ばれ、送信開始位置が１２９０２４０バイト目になる。）次に、送信データ決定手段１３は、このＶＯＢＵの終点を示す値と終了要求位置情報とを比較する（ステップ５０５、５０６）。ＶＯＢＵの終点を示す値が終了要求位置情報と一致するか小さければ、送信終了位置情報にその終点を示す値を設定する（ステップ５０７）。次いで送信データ決定手段１３は、ステップ５０６で終点の位置を確認したＶＯＢＵが要求されたＡＶコンテンツを構成する最終のＶＯＢＵかどうかを確認し（ステップ５０８）、そうでなければ次のＶＯＢＵの終点を示す値と終了要求位置情報を比較する（ステップ５０９、５１０）。ＶＯＢＵの終点を示す値が終了要求位置情報と一致するか小さければ、ステップ５０７に戻り、送信終了位置情報にその終点を示す値を設定する。ステップ５０７から５１０を、注目しているＶＯＢＵの終点を示す値が、終了要求位置情報が示す値以下で、かつそのＶＯＢＵがＡＶコンテンツを構成する最終のＶＯＢＵではない間繰り返す。
【００３２】
このようにして、送信開始位置と送信終了位置が決定されると、送信データ決定手段１３は、送信手段１４に送信開始位置情報と送信終了位置情報を通知する。送信手段１４は、Ｃｏｎｔｅｎｔ−Ｒａｎｇｅヘッダでこの送信開始位置情報と送信終了位置情報が記録され、メッセージボディに要求されたＡＶコンテンツの送信開始位置から送信終了位置までが含まれるようなＨＴＴＰメッセージを作成し、ネットワーク３に送信する（ステップ５１１、５１３）。このＨＴＴＰメッセージは図２の例では、メッセージ２またはメッセージ４である。送信するＡＶコンテンツのデータは蓄積手段１１に含まれているので、送信手段１４は、ＨＴＴＰメッセージの送信の際、蓄積手段１１から必要なデータを獲得する。
【００３３】
ステップ５０６の判定の結果、ＶＯＢＵの終点を示す値が終了要求位置情報より大きければ、送信データ決定手段１３は、ＡＶコンテンツ再生装置２に、そのＶＯＢＵを受信するだけの十分な容量のバッファがないと見なし、その旨を送信手段１４に通知する。送信手段１４は、Ｒａｎｇｅエラーを示すＨＴＴＰメッセージを作成し、ネットワーク３に送信する（ステップ５１２、５１３）。
【００３４】
図６は、本実施形態のＡＶコンテンツ再生装置２の構成を示すブロック図である。図６でユーザ入力手段２１は、ユーザから、ネットワーク再生を行うＡＶコンテンツを識別する情報であるＡＶコンテンツ識別子（名前など）や再生開始要求、停止要求を受け付ける。具体的には、ユーザ入力手段２１は、ＡＶコンテンツ識別子と時間情報（例えば、３０分（３０分後から開始、を意味する。）など）を受け付ける。なお、ユーザ入力手段２１は、ＡＶコンテンツ識別子だけの入力（情報）を受け付けても良い。ユーザ入力手段２１が受け付ける情報の入力手段は、テンキーやキーボードやマウスやリモコンを使ってメニュー画面を操作するもの等、何でも良い。ユーザ入力手段２１は、テンキーやキーボード等の入力手段のデバイスドライバーや、メニュー画面の制御ソフトウェア等で実現され得る。
【００３５】
受信データ決定手段２２は、ユーザ入力手段２１からの通知、バッファ２５の空き容量に関する問い合わせ結果、受信手段２４からの通知等を受けて、開始要求位置、終了要求位置を決定する。受信データ決定手段２２は、ユーザ入力手段２１からの通知のみに基づいて、ＡＶコンテンツの再生をどの位置から始めるかを要求する開始要求位置を決定しても良い。
また、受信データ決定手段２２は、送信開始位置情報と受信したＡＶコンテンツのサイズに基づいて、次の開始要求位置を決定する場合もある。
【００３６】
また、後述する受信手段２４が、ＡＶコンテンツと、ＡＶコンテンツのどの位置までのデータを含んでいるかを示す送信終了位置情報を受信する場合、受信データ決定手段２２は、受信した送信終了位置情報から次の開始要求位置を決定する場合もある。かかる処理の詳細は、後述する。受信データ決定手段２２は、通常、ＭＰＵやメモリ等から実現され得る。受信データ決定手段２２の処理手順は、通常、ソフトウェアで実現され、当該ソフトウェアはＲＯＭ等の記録媒体に記録されている。但し、ハードウェア（専用回路）で実現しても良い。
【００３７】
再生要求送信手段２３は、ネットワーク再生を要求するＡＶコンテンツ識別子と、開始要求位置情報と終了要求位置情報を含む、再生開始要求を生成し、ネットワーク３に送信する。開始要求位置情報と終了要求位置情報は、ユーザ入力手段２１が受け付けた情報や、バッファ２５の空き容量に関する問い合わせ結果、受信手段２４からの通知等に基づいて決定され得る。なお、再生開始要求は、ＡＶコンテンツ識別子と開始要求位置情報のみを含む場合もある。
【００３８】
受信手段２４は、ネットワーク３からＡＶコンテンツのデータを受信し、バッファ２５に送るとともに、一緒に送られてきた送信終了位置情報を受信データ決定手段２２に通知する。再生要求送信手段２３、受信手段２４は、無線または有線の通信手段等で実現され得る。
再生手段２６は、バッファ２５からＡＶコンテンツのデータを順次読み込んで再生する。再生手段２６は、ディスプレイやスピーカー等の出力デバイスを含むと考えても含まないと考えても良い。再生手段２６は、出力デバイスのドライバーソフトと再生処理ソフトウェアまたは、出力デバイスのドライバーソフトと出力デバイスと再生処理ソフトウェア等で実現され得る。
【００３９】
図７は、本実施形態のＡＶコンテンツ再生装置２の動作を示すフローチャートである。以下、図７を使い、図２を用いて説明したシーケンスにおけるＡＶコンテンツ再生装置２の動作を説明する。
ユーザ入力手段２１に、ＡＶサーバ１にあるＡＶコンテンツの再生開始要求があると（ステップ７０１）、ユーザ入力手段２１は、要求するＡＶコンテンツ識別子（図２の例ではｐｒｏｇ．ｖｏｂ）と、どの位置から再生を開始したいかを示すオフセット値を受信データ決定手段２２に通知する（ステップ７０２）。ここで通知されるオフセット値は、ＡＶコンテンツの先頭からの経過時間で表現され、ＶＯＢＵ等の再生ブロックの区切りを意識したものではない。ＡＶコンテンツの先頭から再生する場合はオフセット値として０が通知される。なお、入力される再生位置を示す情報（ここでの、オフセット値）は、先頭からの経過時間などの時間情報であるとも限らない。また、入力される再生位置を示す情報の構造等も問わない。
【００４０】
受信データ決定手段２２は、通知されたオフセット値から開始要求位置情報を算出する（ステップ７０３）。受信データ決定手段２２は、予め保持している算出式（時間情報をバイト値に変換する式）により、通知されたオフセット値から開始要求位置情報を算出する。例えば、受信データ決定手段２２は、平均ビットレートと時間情報から、開始要求位置情報の概算値を算出する。なお、ビットレートが固定である場合は、受信データ決定手段２２は、正確な開始要求位置情報を算出できる。開始要求位置情報は、ＡＶコンテンツの先頭からのバイト値で表現される。ただし、ＡＶコンテンツ再生装置２は、実際の経過時間とバイト数の関係が分からないので、正確な値にはならない。また一般的にＶＯＢＵ等の再生ブロックの先頭にならない。次に受信データ決定手段２２は、バッファ２５の空き容量を確認する（ステップ７０４）。空き容量があらかじめ定められているＶＯＢＵ長の最大値以上あれば、開始要求位置情報に空き容量を加えることで終了要求位置情報を決定する（ステップ７０５）。受信データ決定手段２２は、要求するＡＶコンテンツ名（ＡＶコンテンツ識別子）、開始要求位置情報、終了要求位置情報を有する再生開始要求を再生要求送信手段２３に通知する。なお、ステップ７０５において、開始要求位置情報に空き容量の一定割合の数値を加えることで終了要求位置情報を決定しても良い。バッファ２５の空き容量があらかじめ定められているＶＯＢＵ長の最大値未満であれば、ステップＳ７０４に戻る。
【００４１】
再生要求送信手段２３は、Ｒａｎｇｅヘッダに開始要求位置情報、終了要求位置情報を含み、通知されたＡＶコンテンツ名（ｐｒｏｇ．ｖｏｂ）の送信を要求するＨＴＴＰメッセージを作成し（ステップ７０６）、ネットワーク３に送信する（ステップ７０７）。このＨＴＴＰメッセージは、例えば図２のメッセージ１である。
【００４２】
受信手段２４が、ネットワーク３から送信したＨＴＴＰメッセージに対する応答であるＨＴＴＰメッセージを受信すると（ステップ７０８）、エラーメッセージでないことを確認する（ステップ７０９）。エラーメッセージならエラー処理を行って（ステップ７１５）、はじめに戻る。エラーでなければ、受信手段２４は、ＨＴＴＰメッセージのヘッダ部分を受信データ決定手段２２へ送る。
【００４３】
受信データ決定手段２２は、受信したＨＴＴＰメッセージのヘッダから、Ｃｏｎｔｅｎｔ−Ｒａｎｇｅヘッダを取り出し、送信開始位置情報と送信終了位置情報を抜き出す（ステップ７１０）。また受信手段２４は、バッファ２５へＨＴＴＰメッセージのメッセージボディ部分をバッファ２５へ送る（ステップ７１１）。実際は、このＨＴＴＰメッセージのサイズがネットワーク３の転送単位に比べて大きいために、複数のＴＣＰパケットに分かれて伝送され、最初のＴＣＰパケットにだけヘッダが含まれていることが多い。従って、受信手段２４は、最初のＴＣＰパケット受信時にヘッダを受信データ決定手段２２に送り、引き続くＴＣＰパケット受信時に、含まれているＡＶコンテンツのデータを順次バッファ２５に送る。
【００４４】
受信したＨＴＴＰメッセージで、要求したＡＶコンテンツの最後まで受信し終わった場合（ステップ７１２）、はじめに戻る。そうでなければ、ユーザ入力手段２１に停止要求がなかったかどうかを確認し（ステップ７１３）、あったらはじめに戻る。停止要求がなければ、受信データ決定手段２２は、受信した送信終了位置情報から次の再生開始要求の開始要求位置を決定する（開始要求位置情報に値を設定する）（ステップ７１４）。通常の場合、この開始要求位置は、ＡＶコンテンツを構成するいずれかのＶＯＢＵの先頭と一致するはずである。次いで、ステップ７０４に戻り、ＡＶコンテンツの最後まで達するか、ユーザからの停止要求があるまで上記の動作を繰り返す。
【００４５】
上記では説明しなかったが、再生手段２６は、ユーザ入力手段２１から再生開始の通知があり、かつバッファ２５にデータが格納され始めるとデータを読み出し、再生を開始する。バッファ２５の読み出された領域は、通常、順次解放される。ユーザ入力手段２１からの停止通知があるか、バッファ２５にデータがなくなった時点で再生を停止する。したがって、ステップ７０４で、場ファ２５の空き容量がＶＯＢＵ長の最大値未満であっても、再生によって、空き容量が増加するので、無限ループに陥ることはない。また、図７のフローチャートにおいて、電源オフや処理終了等の割り込みにより処理は終了する。
【００４６】
以上、本実施形態によれば、ＡＶサーバ１の蓄積手段１１に記録されているＤＶＤ−ＶＲフォーマットの動画像をネットワーク再生する場合、ＡＶコンテンツ再生装置２は、ＶＯＢＵに関する正確な情報を持っていなくても、ＶＯＢＵの先頭から再生できるようになる。
【００４７】
また、１番目の再生開始要求の応答として、ＡＶサーバ１が正確な送信終了位置を示す送信終了位置情報をＡＶコンテンツ再生装置２に送信するので、２番目の再生開始要求以降は、ＡＶコンテンツ再生装置２がＶＯＢＵの先頭を指定して再生を要求できる。本実施形態では、２番目以降の再生開始要求に対してもステップ５０４で、最も近いＶＯＢＵの先頭を検出しているが、２番目以降の再生開始要求の開始要求位置をそのまま送信開始位置としてもよく、そうすることによってＡＶサーバ１の負荷が軽減される。
【００４８】
また、開始要求位置の他に開始終了位置も指定することで、ＡＶコンテンツ再生装置２は、バッファの空き具合に応じてＡＶコンテンツのデータを受信できる。
また、ＡＶサーバ１とＡＶコンテンツ再生装置２間の送受信にＨＴＴＰを用い、またＨＴＴＰ規格で定められたＲａｎｇｅヘッダ及びＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダを使うことで、標準的なプロトコルに従って上記の効果が得られる。
【００４９】
なお、上記の実施形態では、ＡＶコンテンツとしてＤＶＤ−ＶＲフォーマットの動画像を例としたが、ＭＰＥＧ動画像をネットワーク再生する場合でも同様の構成、動作で同様の効果が得られる。この場合は、再生ブロックがＶＯＢＵ単位ではなくＧＯＰ（Ｇｒｏｕｐ  Ｏｆ  Ｐｉｃｔｕｒｅｓ）単位となる。なお、ＡＶコンテンツは、他のフォーマットのデータでも良いことは、言うまでもない。
【００５０】
また、上記の実施形態では、Ｒａｎｇｅヘッダの終点で終了要求位置を指定した。このかわりに、ＨＴＴＰの拡張ヘッダを用いて要求サイズを指定してもよい。この場合、ＡＶサーバ１の送信データ決定手段１３は、開始要求位置に要求サイズを加えた結果を終了要求位置として扱い、上記の実施形態と同様の動作を行う。
また、上記の実施形態では、ＡＶコンテンツ再生装置２はＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダの終点から次の要求開始位置を導出していた。このかわりに、Ｃｏｎｔｅｎｔ−Ｒａｎｇｅヘッダの始点とＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダで指定される長さから次の要求開始位置を導出してもよい。
【００５１】
また、上記の実施形態において、ＡＶサーバとＡＶコンテンツ再生装置の間に、例えば、中継装置が存在し、ＡＶコンテンツ再生装置から中継装置に再生開始要求が送信され、中継装置がＡＶサーバをアクセスし、ＡＶコンテンツを取得して、ＡＶコンテンツ再生装置に当該ＡＶコンテンツを送信しても良い。つまり、ＡＶサーバとＡＶコンテンツ再生装置は、直接にネットワークで、データの送受信を行う必要は、必ずしもない。
【００５２】
さらに、本実施の形態における処理は、ソフトウェアで実現しても良い。そして、このソフトウェアをソフトウェアダウンロード等により配布しても良い。また、このソフトウェアをＣＤ−ＲＯＭなどの記録媒体に記録して流布しても良い。なお、このことは、本明細書における他の実施の形態においても該当する。なお、本実施の形態におけるＡＶコンテンツ装置を実現するソフトウェアは、以下のようなプログラムである。つまり、このプログラムは、コンピュータに、ＡＶコンテンツ識別子を有する入力を受け付ける入力ステップと、ＡＶコンテンツの再生位置である開始要求位置を決定する決定ステップと、前記ＡＶコンテンツ識別子と決定した開始要求位置を示す情報である開始要求位置情報を含む再生開始要求を送信する送信ステップと、再生開始要求の送信に対応して、ＡＶコンテンツを受信する受信ステップと、受信したＡＶコンテンツを再生する再生ステップを実行させるためのプログラム、である。
【００５３】
また、本実施の形態におけるＡＶサーバを実現するソフトウェアは、以下のようなプログラムである。つまり、このプログラムは、コンピュータに、ＡＶコンテンツ識別子と開始要求位置情報を有する再生開始要求を受信するステップと、開始要求位置情報が示す開始要求位置付近の再生ブロックの先頭を送信開始位置として決定するステップと、受信した再生開始要求が有するＡＶコンテンツ識別子で識別されるＡＶコンテンツを送信開始位置から送信するステップを実行させるためのプログラム、である。
【００５４】
【発明の効果】
以上、本発明によれば、ＡＶサーバに記録されているＡＶコンテンツをネットワーク再生する場合、ＡＶコンテンツ再生装置がそのＡＶコンテンツを構成する再生ブロックに関する正確な情報をもっていなくても、その再生ブロックの先頭から再生できるようになる。従って、ＡＶコンテンツの再生ブロックに関する情報をＡＶコンテンツ再生装置がＡＶサーバに問い合わせたり、またＡＶコンテンツ再生装置がそのような情報を解釈したりする必要がなくなり、ＡＶコンテンツ再生装置の負荷を軽減させ、構成を簡単にできる。
【図面の簡単な説明】
【図１】本発明の一実施形態が適用されるネットワークの構成図
【図２】同、ＡＶサーバとＡＶコンテンツ再生装置間の送受信を記述したシーケンス図
【図３】同、図２でＡＶコンテンツの例としてあげたｐｒｏｇ．ｖｏｂの構成を示す図
【図４】同、ＡＶサーバの構成を示すブロック図
【図５】同、ＡＶサーバの動作を示すフローチャート
【図６】同、ＡＶコンテンツ再生装置の構成を示すブロック図
【図７】同、ＡＶコンテンツ再生装置の動作を示すフローチャート
【符号の説明】
１    ＡＶサーバ
１１  蓄積手段
１２  再生要求手段
１３  送信データ決定手段
１４  送信手段
２    ＡＶコンテンツ再生装置
２１  ユーザ入力手段
２２  受信データ決定手段
２３  再生要求送信手段
２４  受信手段
２５  バッファ
２６  再生手段
３    ネットワーク
【図１】
2005027010.tif 000003
【図２】
2005027010.tif 000004
【図３】
2005027010.tif 000005
【図４】
2005027010.tif 000006
【図５】
2005027010.tif 000007
【図６】
2005027010.tif 000008
【図７】
2005027010.tif 000009