JP2012203733A - データ処理装置、データ処理方法、及びプログラム - Google Patents

Abstract

【課題】データの出力の停止を抑えるデータ処理装置、データ処理方法、及びプログラムを提供することである。
【解決手段】実施形態のデータ処理装置は、取得部と、ダウンロード制御部と、選択受付部と、出力部と、を備える。取得部は、データの構造を表した構造情報を取得する。ダウンロード制御部は、前記構造情報に基づいて前記データを区切った複数の部分データのうち、当該区切り位置をダウンロードの開始位置として、一つ以上の部分データをダウンロードする。選択受付部は、前記データの前記区切り位置の選択を受け付ける。出力部は、前記選択受付部により選択を受け付けた前記区切り位置から、前記データを出力する。
【選択図】図１

Description

本発明の実施形態は、データ処理装置、データ処理方法、及びプログラムに関する。

ネットワークを介してコンテンツをダウンロードして再生する技術が広く普及している。例えば、インターネットのような広域ネットワークを介して行うコンテンツ配信事業や、ホームネットワーク内で共有されるコンテンツが再生の対象となる。このようなコンテンツに限らず、ネットワーク上のコンテンツであれば、コンテンツを完全にダウンロードする前に、一定量を受信して（再生可能になった時点で）再生するという実装が一般的である。これは、ダウンロード処理と再生処理とを時間的にオーバーラップさせることで、利用者に対して真のダウンロード時間を隠蔽する効果を有する。

近年、コンテンツのダウンロード手法としては、様々な手法が提案されている。ダウンロードの手法としては、複数のコンテンツを並列してダウンロードする手法や、１つのコンテンツを機械的に等分割してダウンロードする手法なども提案されている。

特表２００３−５１０７３４号公報 特開２０１０−４１２４６号公報

しかしながら、従来技術においては、ユーザがあるコンテンツを視聴している時に、当該コンテンツ内で視聴箇所を変更した場合、すでに変更先のデータがバッファリングされている場所であれば良いが、変更先のデータがダウンロードされていない場合、再びバッファリングが必要となり再生が停止する可能性がある。

実施形態のデータ処理装置は、取得部と、ダウンロード制御部と、選択受付部と、出力部と、を備える。取得部は、データの構造を表した構造情報を取得する。ダウンロード制御部は、前記構造情報に基づいて前記データを区切った複数の部分データのうち、当該区切り位置をダウンロードの開始位置として、一つ以上の部分データをダウンロードする。選択受付部は、前記データの前記区切り位置の選択を受け付ける。出力部は、前記選択受付部により選択を受け付けた前記区切り位置から、前記データを出力する。

図１は、第１の実施形態に係る通信装置の構成を示した図である。 図２は、第１の実施形態にかかる通信装置が接続するネットワークを模式的に示した図である。 図３は、第１の実施形態にかかるメタ情報により特定される、コンテンツファイルの構造を示した図である。 図４は、第１の実施形態にかかる通信装置におけるコンテンツのダウンロードの過程を示した図である。 図５は、従来のコンテンツのダウンロードを示した図である。 図６は、第１の実施形態にかかる通信装置の動作を示したシーケンス図である。 図７は、第１の実施形態にかかる通信装置における、コンテンツの再生が開始されるまでのフローチャートである。 図８は、第１の実施形態にかかる通信装置における、コンテンツの再生中の処理を示したフローチャートである。 図９は、第１の実施形態にかかる通信装置において、図８の処理を実行する際の構成要素間の動作を示した第１のシーケンス図である。 図１０は、第１の実施形態にかかる通信装置において、図８の処理を実行する際の構成要素間の動作を示した第２のシーケンス図である。 図１１は、第１の実施形態にかかる通信装置の制御部が、「Ｄx1に移動するユーザ操作」のイベントの発生を検出した場合の処理を示した第１のシーケンス図である。 図１２は、第１の実施形態にかかる通信装置の制御部が、「Ｄx1に移動するユーザ操作」のイベントの発生を検出した場合の処理を示した第２のシーケンス図である。 図１３は、第１の実施形態にかかる通信装置の記憶部で管理する状態情報の第１の例を示した図である。 図１４は、第１の実施形態にかかる通信装置の記憶部で管理する状態情報の第２の例を示した図である。 図１５は、第１の実施形態にかかる通信装置の記憶部で管理する状態情報の第３の例を示した図である。 図１６は、第１の実施形態にかかる通信装置の記憶部で管理する状態情報の第４の例を示した図である。 図１７は、第１の実施形態にかかる通信装置の記憶部で管理する状態情報の第５の例を示した図である。 図１８は、第１の実施形態にかかる通信装置の記憶部で管理する状態情報の第６の例を示した図である。 図１９は、第２の実施形態にかかる通信装置のブロック構成を示した図である。 図２０は、第３の実施形態にかかる通信装置のブロック構成を示した図である。 図２１は、第３の実施形態にかかるネットワークを模式的に示した図である。 図２２は、第３の実施形態にかかる通信装置でのコンテンツのダウンロード状況に応じた、コンテンツ管理サーバの動作状態と休止状態との遷移タイミングを説明した図である。 図２３は、第３の実施形態にかかる通信装置とコンテンツ管理サーバとの間の動作を表したシーケンスを示した図である。 図２４は、第３の実施形態にかかる通信装置の再生開始までのフローチャートを示した図である。 図２５は、第３の実施形態にかかる通信装置の再生中のフローチャートを示した図である。 図２６は、第３の実施形態にかかる制御部によるサーバ情報の解析結果として記憶部に保存された情報の第１の例を示した図である。 図２７は、第３の実施形態にかかる制御部によるサーバ情報の解析結果として記憶部に保存された情報の第２の例を示した図である。 図２８は、図２７に示すサーバ情報に従った各状態の遷移を示した図である。

（第１の実施形態）
図１は、第１の実施形態に係る通信装置の構成を示した図である。図１に示すように、通信装置１００は、通信Ｉ／Ｆ部１０１と、通信部１０２と、制御部１０３と、記憶部１０４と、ユーザインターフェイス部１０６と、再生部１０７と、を備える。

通信Ｉ／Ｆ部１０１は、有線ＬＡＮや無線ＬＡＮなど種々の手法を用いて、ネットワークと接続する。通信Ｉ／Ｆ部１０１を備えたことで通信装置１００は、ネットワークと接続可能となる。

図２は、通信装置１００が接続するネットワークを模式的に示した図である。図２に示すように、通信装置１００は、ネットワーク２００を介して、コンテンツ管理サーバ２０１と、メタ情報管理サーバ２０２と、接続されている。

コンテンツ管理サーバ２０１は、コンテンツを管理するサーバとする。

メタ情報管理サーバ２０２は、コンテンツの内容やコンテンツの構造が示されたメタ情報を管理するサーバとする。本実施形態では、コンテンツを管理するコンテンツ管理サーバ２０１と、メタ情報管理サーバ２０２と、が別構成の例について説明するが、１つのサーバでコンテンツ及びメタ情報を提供しても良い。

また、本実施形態では、コンテンツの内容や構造を認識するための構造情報としてメタ情報を用いた例について説明した。しかしながら、メタ情報に制限するものではなく、例えば、コンテンツデータの先頭に、当該コンテンツの構造等が含まれていても良い。

メタ情報には、コンテンツの構造を示す情報が含まれている。例えば、メタ情報には、コンテンツ全体のデータサイズ又はコンテンツの再生時間が情報として含まれている。さらに、メタ情報には、当該コンテンツが複数のチャプタ(区間)に分かれており、各チャプタの開始位置（換言すれば、コンテンツを区切る位置）が含まれている。具体的には、メタ情報には、コンテンツを区切る位置として、例えば各チャプタの開始時刻又は開始バイトが、各チャプタと対応付けて記憶されている。このように、メタ情報は、コンテンツを視聴時、別の場面に移動する際、移動先として用いられる可能性が高い区切り位置の情報を含んでいる。

つまり、本実施形態にかかる通信装置１００は、ユーザから、当該区切り位置の選択を受け付け、当該区切り位置からコンテンツの再生を開始した場合、ユーザが所望する内容を視聴できる可能性が高くなる。なお、区切り位置は、チャプタの区切り位置に制限するものではなく、例えばＣＭの開始、終了する位置等でも良い。

さらには、通信装置１００以外のユーザにより設定された区切り位置を用いても良い。例えば、アップロードされているコンテンツに対して、ユーザがおすすめの場面の閲覧等のために区切り位置を設定する技術が提案されている。そこで、メタ情報管理サーバ２０２が、お薦め場面閲覧等のためにユーザにより設定された区切り位置を取得し、取得した区切り位置等をメタ情報内に記憶する。そして、メタ情報管理サーバ２０２が、通信装置１００に対して、当該メタ情報を送信する。これにより、ユーザは、他のユーザが設定した区切り位置を含むメタ情報を利用して、コンテンツを視聴することができる。

さらに、メタ情報には、コンテンツのビットレートが含まれている。ＣＢＲ（Constant Bit Rate）の場合には、コンテンツ１つについて１つのビットレートが含まれている。一方、ＶＢＲ（Variable Bit Rate）の場合には、コンテンツを区切る区間毎に平均ビットレートが含まれている。

図３は、メタ情報により特定される、コンテンツファイルの構造を示した図である。図３に示す例では、長さＬ・再生時間Ｔを持つコンテンツファイルが、８個の区間に分割される例を示している。各区間は、開始時刻ti(i=0,..,7)、又は開始バイトアドレスbi(i=0,..,7)により特定される。本実施形態にかかる通信装置１００は、分割された各区間をチャプタとして認識する。そして、通信装置１００は、ユーザインターフェイス部１０６を介して、ユーザから任意のチャプタに移動する操作を受け付けた場合に、当該チャプタに対応する、上述した開始時刻又は開始バイトアドレスからコンテンツの再生を行う。

コンテンツの各区間は、さらに区間を分割した小区間（細かい破線で区切られた領域）を含んでいる。通信装置１００は、この小区間のデータをコンテンツ管理サーバ２０１からダウンロードする。

小区間のデータサイズは、所定の基準に従って定められている。つまり、小区間のデータサイズは、ユーザが再生対象として各区間を選択した際、当該小区間のデータの再生が終了する前に、コンテンツ管理サーバ２０１から当該小区間の続きのデータを取得し、シームレスに再生可能とすることを基準として定められている。当該小区間のデータサイズは、コンテンツ管理サーバ２０１側で決定しても良いし、通信装置１００側で決定しても良い。コンテンツ管理サーバ２０１側が決定する場合に、上述した基準を満たすものとして予め定めた固定サイズでも良い。また、通信装置１００側で決定する場合、コンテンツ管理サーバ２０１と通信装置１００との間のネットワーク速度、及びコンテンツのビットレートを考慮して、上述した条件を満たすようデータサイズを決定する。

図１に戻り、通信部１０２は、通信Ｉ／Ｆ部１０１を介して、通信プロトコル、例えばＴＣＰ／ＩＰで定められた処理を行って、ネットワーク２００に接続されたコンテンツ管理サーバ２０１又はメタ情報管理サーバ２０２との間で、データの送受信を制御する。

記憶部１０４は、ＲＡＭまたはハードディスクなどにより構成され、コンテンツ管理サーバ２０１から取得したコンテンツや、メタ情報管理サーバ２０２から取得したメタ情報を記憶する。

制御部１０３は、取得部１１１と、ダウンロード制御部１１２と、を備え、通信装置１００全体を制御する。例えば、制御部１０３は、再生部１０７を制御して、取得したコンテンツを再生したり、ユーザインターフェイス部１０６を介して入力されたユーザから要求に対応する処理を行ったり、記憶部１０４を用いてコンテンツのバッファ状態を管理する。

取得部１１１は、通信部１０２を制御して、メタ情報を取得する。取得したメタ情報は、記憶部１０４に記憶される。そして、メタ情報を解析することで、コンテンツを分割する複数の区間を特定できる。

ダウンロード制御部１１２は、メタ情報に基づいて特定された、コンテンツを区切る複数のチャプタ（区間）のうち、チャプタ間の区切り位置をダウンロードの開始位置として、３個の区間のデータを並行してダウンロードする。

本実施形態は、並行してダウンロード可能な数を３個とするが、３個に制限するものではない。２個であっても良いし、４個以上であっても良い。このように、並列数は設計事項であり、必要に応じて増減させて良い。なお、本実施形態の目的を効果的に実現するためには、２以上の並列数が好ましい。さらに並列ダウンロードは、複数のＴＣＰコネクションを確立して行っても良いし、１つのコネクションの中で多重化してダウンロードするようにしても良い。なお、１つずつしかダウンロードできない場合であっても、ダウンロード速度と再生速度との間に十分な差が確保できれば適用可能である。次に、ダウンロード制御の手順について例を用いて説明する。

図４は、コンテンツのダウンロードの過程を示した図である。図４の（１）は、コンテンツのダウンロード前を示している。上述したように、当該コンテンツは、８チャプタ（区間）で構成されている。そして、ダウンロード制御部１１２は、当該コンテンツうち、最初から３個のチャプタについて、各チャプタの開始位置（開始位置４０１、４０２、４０３）から、並行してダウンロードを行う。

その後、図４の（２）に示すように、タウンロード制御部１１２は、最初から３個のチャプタ（区間）について、小区間分（小区間４０４、４０５、４０６）のダウンロードが済んだ段階で、当該３個のチャプタについてのダウンロードを停止する。これにより、再生部１０７により、ダウンロード済みのチャプタの再生が開始された場合、ダウンロード制御部１１２により、ダウンロード済みの小区間以降についてダウンロードが再開されれば、当該チャプタについてはシームレスに再生可能となる。

その後、図４の（３）に示すように、再生部１０７により最初のチャプタについて再生が開始されると共に、ダウンロード制御部１１２は、それ以降のチャプタについて、開始位置（開始位置４０７、４０８、４０９）からのダウンロードを並行して行う。これ以降も同様の手順でダウンロード制御部１１２がダウンロードを行い、図４の（４）に示すように、ダウンロード制御部１１２が、コンテンツのチャプタ毎に小区間分のダウンロードを完了させる。これにより、ユーザから各チャプタに移動する操作を受け付けた場合であっても、移動先のチャプタについて待機することなく、シームレスに再生を可能とする。

図５は、従来のコンテンツのダウンロードを示した図である。図５に示すように、従来、コンテンツをダウンロードする場合、開始位置から継続してダウンロードが行われる。このため、ユーザが、コンテンツの再生位置５０１から再生位置５０２に変更した場合、再生位置５０２からのデータがまだダウンロードされていないため、コンテンツの再生が停止する。これに対し、本実施形態にかかる通信装置１００は、複数のチャプタについて、開始位置から小区間分のコンテンツを並行してダウンロードすることとした。これにより、通信装置１００は、ユーザから各チャプタへの移動を受け付けた場合であってもシームレスにコンテンツを再生することができる。

ユーザインターフェイス部１０６は、通信装置１００を操作するユーザに対するインターフェイスとする。例えば、ユーザインターフェイス部１０６は、再生部１０７が再生しているコンテンツに対して、当該コンテンツを区切るチャプタの開始位置の選択を受け付ける。

再生部１０７は、記憶部１０４に保存されたコンテンツを再生する。再生部１０７は、ユーザインターフェイス部１０６により選択を受け付けた、チャプタの開始位置から、データを再生（出力）する。

図６は、通信装置１００の動作を示したシーケンス図である。まず、通信装置１００は、再生対象となるコンテンツのメタ情報を取得する。この取得手法としては、どのような手法を用いても良い。本実施形態では、上述したように、メタ情報管理サーバ２０２に予め用意されているものとする。

まず、通信装置１００の取得部１１１が、通信部１０２を介して、コンテンツのメタ情報を取得するため、メタ情報管理サーバ２０２に対して、メタ情報のダウンロードの要求を送信する（ステップＳ６０１）。当該要求に応じて、メタ情報管理サーバ２０２は、要求されたコンテンツに対応するメタ情報を送信する（ステップＳ６０２）。

そして、通信装置１００の取得部１１１が、通信部１０２を介して、メタ情報を取得して記憶部１０４に記憶した場合、制御部１０３が、メタ情報を解析して、再生対象のコンテンツの構造を把握する（ステップＳ６０３）。これにより、再生対象のコンテンツの各チャプタの開始位置を把握できる。

そして、本実施形態にかかる通信装置１００のダウンロード制御部１１２は、再生対象のコンテンツについて、ダウンロードを要求する。本実施形態では通信装置１００では上述したように最大３個まで並行してダウンロード可能とする。その上、ダウンロード制御部１１２のダウンロードは、同時に処理できる最大数（本実施形態では３個とする）まで並列して行う。そこで、ダウンロード制御部１１２は、チャプタ１（Ch.1）を構成する最初の小区間（Ch.1-1）のダウンロード要求（ステップＳ６０４）と、チャプタ２（Ch.2）を構成する最初の小区間（Ch.2-1）のダウンロード要求（ステップＳ６０５）と、チャプタ３（Ch.3）を構成する最初の小区間（Ch.3-1）のダウンロード要求（ステップＳ６０６）と、を並行して行う。

そして、本実施形態にかかる通信装置１００のダウンロード制御部１１２は、ファイルの先頭のチャプタ（区間）を構成する小区間から順次にダウンロードする。すなわちb0バイトで特定される区間の最初の小区間のデータからダウンロードする。その後も他の区間についてダウンロードを行い、ダウンロード制御部１１２は、チャプタ１（Ch.1）〜チャプタ３（Ch.3）の３つの区間それぞれの、最初の小区間(Ch.1-1, Ch.2-1, Ch.3-1,)のデータを並行してダウンロードすることとなる（ステップＳ６０７〜Ｓ６０９）。

そして、最初の区間（Ch.1）について再生できる量のダウンロードが完了すると、通信装置１００の再生部１０７が、当該コンテンツの先頭（最初のチャプタの開始位置）から順に再生を開始する（ステップＳ６１０）。

さらに時間が経過し、ダウンロード中のチャプタのうち、いずれかの小区間に対するダウンロードが完了したとする。この場合、通信装置１００の制御部１０３は、コンテンツに含まれる各チャプタ（区間）のうち、最初の小区間のダウンロードが完了していないチャプタ（区間）の有無を判定する。

図６に示す例では、ダウンロード制御部１１２が、通信部１０２を介して、チャプタ（区間）１（Ch.1）の最初の小区間の最後のデータのダウンロード制御まで行い、チャプタ（区間）１（Ch.1）の最初の小区間のダウンロードが完了したものとする（ステップＳ６１１）。

当該ダウンロードが完了した後、制御部１０３が、ダウンロードが完了していない区間の有無を判定する（ステップＳ６１２）。図６に示す例では、制御部１０３が、チャプタ（区間）４（Ch.4）の最初の小区間のダウンロードが完了していないことを検出する。なお、チャプタ（区間）１（Ch.1）の再生で、当該チャプタ１をシームレスに再生するだけのデータサイズがなくなりそうな場合には、チャプタ１の最初の小区間以降について、継続してダウンロードしても良い。

そこで、ダウンロード制御部１１２は、チャプタ４（Ch.4）を構成する最初の小区間のダウンロード要求を行う（ステップＳ６１３）。当該要求に対応して、ダウンロード制御部１１２は、チャプタ４（Ch.4）を構成する、最初の小区間について、ダウンロードが終了していない他のチャプタの小区間と並行してダウンロードする（ステップＳ６１４）。

また、制御部１０３が、ダウンロードが完了していない他の区間が無いと判定した場合、現在再生中の小区間に継続する小区間のうち、ダウンロードが完了していないものから順次にダウンロードしていく。

このように本実施形態にかかる通信装置１００では、再生するコンテンツの構造を考慮して、移動先の各チャプタの開始位置から小区間分のデータを優先的に取得することとした。これにより、再生部１０７によるコンテンツの再生中に、ユーザインターフェイス部１０６が、チャプタを移動するなどの操作を受け付けたとしても、再バッファリングが発生する可能性を抑止し、データの遅延を隠蔽し、コンテンツのシームレスな再生を提供できる。

次に、通信装置１００における再生するまでの処理について説明する。図７は、通信装置１００における、コンテンツの再生が開始されるまでのフローチャートである。本フローチャートでは、動画コンテンツをインデックスｉとｊで表現する。インデックスｉが、区間のインデックスであり、インデックスｊが小区間のインデックスとする。

まず、通信装置１００の取得部１１１が、通信部１０２を介して、コンテンツのメタ情報のダウンロード要求を、メタ情報管理サーバ２０２に対して送信する（ステップＳ７０１）。そして、取得部１１１が取得したメタ情報を、記憶部１０４に保存する（ステップＳ７０２）。その後、制御部１０３が、メタ情報を解析して、再生対象のコンテンツの構造を把握する（ステップＳ７０３）。その後、制御部１０３が、コンテンツのインデックスｉ、ｊを‘１’で初期化する（ステップＳ７０４）。さらに、制御部１０３が、ダウンロード数のカウンタ（以降、ダウンロードカウンタｎ）を‘０’で初期化する（ステップＳ７０５）。

その後、ダウンロード制御部１１２が、コンテンツの各チャプタの小区間Ｄijのダウンロードを開始する（ステップＳ７０６）。そして、正常にダウンロードが開始された場合、制御部１０３は、ダウンロードカウンタｎに‘１’追加する（ステップＳ７０７）。

その後、制御部１０３が、ダウンロードカウンタｎが、最大ダウンロード数Ｎ（上限値‘３’）より小さいか否かを判定する（ステップＳ７０８）。ダウンロードカウンタｎが、最大ダウンロード数Ｎより小さいと判定した場合（ステップＳ７０８：Ｙｅｓ）、インデックスｉに‘１’追加する（ステップＳ７０９）。そして、制御部１０３が、インデックスｉが、コンテンツ内の区間の数以上か否かを判定する（ステップＳ７１０）。区間の数以上ではないと判定した場合（ステップＳ７１０：Ｎｏ）、ダウンロード制御部１１２が、異なるチャプタの小区間Ｄijのダウンロードを開始する（ステップＳ７０６）。このようにステップＳ７０６〜Ｓ７１０まで処理を繰り返して行うことで、複数のチャプタの小区間についてダウンロードが並行して行われる。

そして、制御部１０３が、ダウンロードカウンタｎが、最大ダウンロード数Ｎ以上となった場合（ステップＳ７０８：Ｎｏ）、またはインデックスｉがコンテンツ内の区間数以上となった場合（ステップＳ７１０：Ｙｅｓ）、制御部１０３が、コンテンツの最初のチャプタ１の小区間Ｄ11が再生可能か否かを判定する（ステップＳ７１１）。制御部１０３が、再生できないと判定した場合（すなわち、ダウンロード済みのサイズが不足していると判定した場合）（ステップＳ７１１：Ｎｏ）、条件が満たされるまで待機する（ステップＳ７１２）。その後、制御部１０３が、再生可能か否かの判定を定期的に行う。

制御部１０３が、再生可能と判定した場合（ステップＳ７１１：Ｙｅｓ）、再生部１０７が、チャプタ１の小区間Ｄ11の再生を開始して（ステップＳ７１３）、次の処理に移る。

以上が、通信装置１００における再生を開始するまでの処理である。なお、図７に示すフローチャートでは、一連の処理の間に小区間のダウンロードは完了しないと仮定している。仮にダウンロードが完了することを考慮する場合には、後述する再生中の処理と同様の処理で対応する。

次に、通信装置１００における再生中の処理について説明する。図８は、通信装置１００における、コンテンツの再生中の処理を示したフローチャートである。

本実施形態にかかる通信装置１００では、再生中の処理フローは、イベントドリブンになっている。そこで、制御部１０３が、イベントが発生するまで待機する（ステップＳ８０１）。なお、この図８に示すフローチャートでは、不要なイベントは省略し、イベントとして「小区間ダウンロード完了」及び「Ｄx1に移動するユーザ操作」が発生する場合に限って示した。

その後、制御部１０３が、発生したイベントを判定する（ステップＳ８０２）。制御部１０３が「小区間ダウンロード完了」のイベントが発生したと判定した場合（ステップＳ８０２：下）、ダウンロードカウンタｎを‘１’減算する（ステップＳ８０３）。その後、制御部１０３が、他のチャプタの先頭に位置する小区間Ｄ*1のうち未ダウンロードのものがあるか否かを判定する（ステップＳ８０４）。未ダウンロードの小区間があると判定した場合（ステップＳ８０４：Ｙｅｓ）、ダウンロード制御部１１２は、未ダウンロードの小区間Ｄ*1の一つに対してダウンロードを開始する（ステップＳ８０５）。そして、制御部１０３は、ダウンロードカウンタｎに‘１’加算する（ステップＳ８０６）。なお、クライアントがダウンロードした最初の小区間だけでは十分な再生時間を確保できないと判断した場合、例えば先頭から２つの小区間を連続してダウンロードするように変更しても良い。

一方、制御部１０３が、他のチャプタの先頭に位置する小区間Ｄ*1のうち、未ダウンロードのものが無いと判定した場合（ステップＳ８０４：Ｎｏ）、他にダウンロードを行っていない小区間Ｄ*y(y!=1)があるか否かを判定する（ステップＳ８０７）。ないと判定した場合（ステップＳ８０７：Ｎｏ）、イベントの発生まで待機する（ステップＳ８０１）。一方、小区間Ｄ*y(y!=1)があると判定した場合（ステップＳ８０７：Ｙｅｓ）、ダウンロード制御部１１２が、これら小区間Ｄ*y(y!=1)のうち少なくとも一つに対してダウンロードを開始する（ステップＳ８０８）。さらに、制御部１０３が、ダウンロードカウンタｎに‘１’を加算する（ステップＳ８０９）。なお、ステップＳ８０８でダウンロードする小区間は、現在の再生が継続した場合に再生されるタイミングが早いものから順にダウンロードしていくものとする。

次に、ステップＳ８０２で、制御部１０３が、「Ｄx1に移動するユーザ操作」のイベントが発生したと判定した場合（ステップＳ８０２：右）の処理について述べる。この処理は、移動先である区間Ｄxの先頭にある小区間のデータＤx1がダウンロードされているか否かによって処理が異なる。つまり、制御部１０３が、小区間のデータＤx1が再生可能か否かを判定する（ステップＳ８１０）。

制御部１０３が小区間のデータＤx1を再生可能と判定した場合、換言すればＤx1が再生可能なバイト数以上ダウンロード済みの場合（ステップＳ８１０：Ｙｅｓ）、Ｄx1の再生を開始する（ステップＳ８１１）。その後、制御部１０３が、再生を開始した小区間のデータＤx1と同一区間に属する他の小区間Ｄx*で、未ダウンロードのものがあるか否かを判定する（ステップＳ８１２）。そして、制御部１０３が、全てがダウンロードされていると判定した場合（ステップＳ８１２：Ｎｏ）、イベントの発生まで待機する（ステップＳ８０１）。

一方、制御部１０３が小区間Ｄx*で未ダウンロードのものがあると判定した場合（ステップＳ８１２：Ｙｅｓ）、現在のダウンロードカウンタｎが、最大ダウンロード数Ｎ以上であるか否かを判定する（ステップＳ８１３）。最大ダウンロード数Ｎ以上ではないと判定した場合（ステップＳ８１３：Ｎｏ）、イベントの発生まで待機する（ステップＳ８０１）。また最大ダウンロード数Ｎより小さいと判定した場合（ステップＳ８１３：Ｎｏ）、ダウンロード制御部１１２が、小区間Ｄx*のダウンロードを開始する（ステップＳ８１４）。そして、制御部１０３が、ダウンロードカウンタｎに‘１’加算する（ステップＳ８１５）。

また、ステップＳ８１０で、制御部１０３が小区間のデータＤx1を再生できないと判定した場合、換言すれば、小区間のデータＤx1が全くダウンロードされていない又は再生可能なバイト数に満たないと判定した場合（ステップＳ８１０：Ｎｏ）、小区間のデータＤx1がダウンロード中であるか否かを判定する（ステップＳ８２３）。ダウンロード中ではないと判定した場合（ステップＳ８２３：Ｎｏ）、制御部１０３が、ダウンロードカウンタｎが、最大ダウンロード数Ｎより小さいか否かを判定する（ステップＳ８１６）。ダウンロードカウンタｎが、最大ダウンロード数Ｎ以上と判定された場合（ステップＳ８１６：Ｎｏ）、ダウンロード中の小区間の１つをキャンセルする（ステップＳ８１７）。キャンセルする対象を決める基準としては、最もダウンロードが進んでいない小区間、もっとも最近にダウンロードが開始された小区間、現在再生中の区間よりも時間的に前の区間に含まれる小区間、現在再生中の区間からの時間的距離が最も遠い小区間、など種々の基準を用いて良い。そして、制御部１０３が、当該キャンセルに伴いダウンロードカウンタｎから‘１’減算する（ステップＳ８１８）。

そして、ステップＳ８１８の処理の後、又はダウンロードカウンタｎが、最大ダウンロード数Ｎより小さいと判定された場合（ステップＳ８１６：Ｙｅｓ）、ダウンロード制御部１１２が、移動先の小区間のデータＤx1のダウンロードを開始する（ステップＳ８１９）。その際、制御部１０３が、ダウンロードカウンタｎに‘１’加算する（ステップＳ８２０）。その後、同小区間のデータＤx1が再生できるようになるまで待機する（ステップＳ８２１）。その後、同小区間のデータＤx1が再生できるようになった場合、再生部１０７が、再生を開始して（ステップＳ８２２）、元に戻る（ステップＳ８２１〜ステップＳ８２２）。

現在ダウンロード中だった場合（ステップＳ８２３：Ｙｅｓ）、再生可能になるまで待機し（ステップＳ８２１）、再生可能となった場合に再生を開始する（ステップＳ８２２）。その後、イベントの発生まで待機する（ステップＳ８０１）。

このように通信装置１００では、ユーザ操作によって移動する可能性がある、各チャプタの開始部分に対応する小区間を予めダウンロードしておくこととした。これにより、ユーザからチャプタ移動の操作を受け付けた場合に、移動操作の直後にダウンロードが実行される可能性を低減させることができる。結果的に、ダウンロードに要する遅延をユーザに対して隠蔽することができる。

引き続き、本実施形態にかかる通信装置１００を構成する各構成要素の役割と動作について詳細に述べる。図９と図１０は、通信装置１００において、図８の処理を実行する際の構成要素間の動作を示したシーケンス図である。

ユーザインターフェイス部１０６が、ユーザからのコンテンツの再生要求の選択を受け付ける（ステップＳ９０１）。そして、ユーザインターフェイス部１０６が、再生要求の選択を受け付けたことを、制御部１０３に通知する（ステップＳ９０２）。そして、制御部１０３の取得部１１１が、コンテンツの再生要求を解析し、ユーザに選択されたコンテンツと、当該コンテンツに対応するメタ情報を取得する要求を生成する（ステップＳ９０３）。その後、取得部１１１が、メタ情報の取得要求を、通信部１０２に出力する（ステップＳ９０４）。

これにより、通信部１０２が、通信Ｉ／Ｆ部１０１を介してコンテンツ管理サーバ２０１にメタ情報の取得要求を送信する（ステップＳ９０５〜ステップＳ９０６）。

メタ情報の取得要求を受信したメタ情報管理サーバ２０２は、メタ情報を通信装置１００に送り返す（ステップＳ９０７）。そして、通信部１０２が、通信Ｉ／Ｆ部１０１を介して、メタ情報を受信し（ステップＳ９０８）、取得部１１１の制御に従って、受信したメタ情報を記憶部１０４に記憶する（ステップＳ９０９）。その後、通信部１０２は、制御部１０３の取得部１１１に、メタ情報を受信したことを通知する（ステップＳ９１０）。

制御部１０３の取得部１１１が、受信通知を受け取った場合にメタ情報が適切に取得できたものと判定する。そして、制御部１０３が、記憶部１０４に記憶されたメタ情報を読み出す（ステップＳ９１１）。そして、制御部１０３が、メタ情報を解析し、コンテンツ内の各チャプタの開始バイト（区切り位置）を特定する（ステップＳ９１２）。その結果、制御部１０３は、コンテンツが例えば図３に示すような構造を有していることを認識する。なお、解析結果は記憶部１０４に保存する。さらに、制御部１０３は、各チャプタにおけるダウンロード単位である小区間を特定する（ステップＳ９１３）。なお、小区間の特定手法は、上述したように様々な手法が考えられる。そして、制御部１０３は、特定されたコンテンツ内の各チャプタ、及び各チャプタの小区間を、特定結果として、記憶部１０４に記憶する（ステップＳ９１４）。

ところで、本実施形態では、各チャプタの小区間３個を並行してダウンロード可能としている。そこで、制御部１０３のダウンロード制御部１１２は、通信部１０２に対して、異なるチャプタについての小区間取得要求を、３回出力する（ステップＳ９１５、Ｓ９１８、Ｓ９２１）。そして、通信部１０２が、これら３個の取得要求を、通信Ｉ／Ｆ部１０１を介して、コンテンツ管理サーバ２０１に送信する（ステップＳ９１６、Ｓ９１７、Ｓ９１９、Ｓ９２０、Ｓ９２２、Ｓ９２３）。なお、図８に示したダウンロードカウンタｎの増減は、制御部１０３で適切に実行されているものとして、説明を省略する。

これに伴い、コンテンツ管理サーバ２０１が、通信装置１００に対して、３個の小区間のデータを、並行して送信する（ステップＳ９２４、Ｓ９２７、Ｓ９３０）。そして、通信部１０２が、通信Ｉ／Ｆ部１０１を介して、３個の小区間のデータを、並行して受信する（ステップＳ９２４、Ｓ９２５、Ｓ９２７、Ｓ９２８、Ｓ９３０、Ｓ９３１）。そして、通信部１０２が、ダウンロード制御部１１２による制御に従って、３個の小区間のデータを並行して、記憶部１０４に記憶させる（ステップＳ９２６、Ｓ９２９、Ｓ９３２）。

さらに通信部１０２は、制御部１０３のダウンロード制御部１１２に、小区間のデータを受信したことを通知する（ステップＳ９３３）。通知を受けた制御部１０３は、コンテンツのダウンロード状態を更新し、確認する（ステップＳ９３４〜Ｓ９３５）。これ以降の処理については、図１０で説明する。

制御部１０３が、図９のステップＳ９３５でダウンロードの状態確認で、コンテンツの先頭チャプタの小区間が再生可能と判定した場合、制御部１０３は、再生部１０７にコンテンツの再生を指示する（ステップＳ１００１）。再生部１０７は、当該指示に従って、小区間のデータを、記憶部１０４から読出し（ステップＳ１００２）、再生する（ステップＳ１００３）。

次に、小区間のデータのダウンロード終了後に他のチャプタの小区間のデータをダウンロードする際の処理について述べる。まず図９で示した処理（ステップＳ９２４〜Ｓ９３２）と同様に、小区間のデータのダウンロードから保存するまでの処理を行う（ステップＳ１００４〜Ｓ１００６）。その後、通信部１０２による小区間のデータを受信したことを通知（ステップＳ１００７）、コンテンツのダウンロード状態の更新（ステップＳ１００８）、及びコンテンツのダウンロード状態の確認（ステップＳ１００９）が行われる。当該確認で、制御部１０３が、小区間全体がダウンロードできたことを確認できる。

そして、制御部１０３は、ダウンロードすべき小区間のデータが存在するか否かを判定する（ステップＳ１０１０）。当該判定は、図８のステップＳ８０４やステップＳ８０７に相当し、状況に応じて判定基準が異なる。

そして、制御部１０３が、ダウンロードすべき小区間のデータが存在すると判定した場合、ダウンロード制御部１１２が、小区間のデータの取得要求を、通信部１０２と通信Ｉ／Ｆ部１０１を介して、コンテンツ管理サーバ２０１に送信する（ステップＳ１０１１〜Ｓ１０１３）。これにより、コンテンツ管理サーバ２０１からの取得要求の対象となった小区間のデータのダウンロードが開始される。

次に、図８のステップＳ８０２で、「Ｄx1に移動するユーザ操作」のイベントが発生したと判定した場合（ステップＳ８０２：右）の処理について説明する。図１１は、制御部１０３が、「Ｄx1に移動するユーザ操作」のイベントの発生を検出した場合の処理を示したシーケンス図である。

まず、ユーザインターフェイス部１０６がユーザによるＤx1への移動させる選択を受け付ける（ステップＳ１１０１）。そして、ユーザインターフェイス部１０６が、制御部１０３に対して、選択された移動先を通知する（ステップＳ１１０２）。制御部１０３は、記憶部１０４に取得要求を出力することで（ステップＳ１１０３）、通知された移動先（本処理手順ではＤx1とする）のダウンロード状態を、記憶部１０４から取得する（ステップＳ１１０４）。そして、制御部１０３は、保存された状態情報に基づいて、再生のためにダウンロードが必要か否かを判定する（ステップＳ１１０５）。なお、本シーケンス図では、図８のステップＳ８１０で、制御部１０３が、ダウンロードが不要と判断した場合（ステップＳ８１０：Ｙｅｓ）について説明する。

そして、制御部１０３が、ダウンロードが不要と判断した場合、再生部１０７に再生指示を出力する（ステップＳ１１０６）。そして、再生部１０７が、記憶部１０４から小区間のデータＤx1を読み出して（ステップＳ１１０７）、当該小区間のデータＤx1の再生を開始する（ステップＳ１１０８）。その後、制御部１０３は、区間Ｄxに属する小区間Ｄxy(y!=1)についてダウンロード要否を判定する（ステップＳ１１０９）。なお、本シーケンス図では、制御部１０３が、ダウンロードが必要と判定した場合について説明する。

そして、制御部１０３が、ダウンロードが必要と判定した場合、制御部１０３のダウンロード制御部１１２による制御に従って、通信部１０２が、コンテンツ管理サーバ２０１に対して、小区間のデータのダウンロードの要求を送信する（ステップＳ１１１０〜Ｓ１１１２）。

さらに、図１２を用いて、制御部１０３が、「Ｄx1に移動するユーザ操作」のイベントの発生を検出した場合の処理を継続して説明する。

次に、図８のステップＳ８１０で、制御部１０３が、移動先のＤx1のダウンロードが必要と判断した場合（ステップＳ８１０：Ｎｏ）について説明する。なお、移動先のＤx1のダウンロードについては未だ実行されていなかったものとする（ステップＳ８２３：Ｎｏ）。この場合、制御部１０３が移動先のＤx1のダウンロードが必要と判定した場合、ダウンロードカウンタｎが最大ダウンロード数Ｎ以上であるか、換言すればダウンロードが即座に開始できるか否かを判定する（ステップＳ１２０１）。なお、当該処理は、図８のステップＳ８１６に相当する。当該処理手順では、ダウンロードが即座に開始できる例とする。

そして、制御部１０３が、即座にダウンロードできると判定した場合、制御部１０３のダウンロード制御部１１２の制御に従って、通信部１０２が、通信Ｉ／Ｆ部１０１を介して取得要求を、コンテンツ管理サーバ２０１に対して送信する（ステップＳ１２０２〜Ｓ１２０４）。これにより、コンテンツ管理サーバ２０１から、小区間のデータＤx1のダウンロードが開始される。

一方、制御部１０３が、ステップＳ１２０１で即座にダウンロードできないと判定した場合、キャンセルの対象となるダウンロード中の小区間のデータを特定する（ステップＳ１２０５）、そして、制御部１０３の制御に従って、通信部１０２が、通信Ｉ／Ｆ部１０１を介して、コンテンツ管理サーバ２０１に対して、特定された小区間のデータのキャンセルを通知する（ステップＳ１２０６〜Ｓ１２０８）。通信部１０２が、通信Ｉ／Ｆ部１０１を介して、コンテンツ管理サーバ２０１からキャンセル応答を受信し（ステップＳ１２０９〜Ｓ１２１０）、受信したキャンセル応答を、制御部１０３に通知する（ステップＳ１２１１）。

そして、制御部１０３が、当該キャンセル応答に従って、記憶部１０４に記憶された状態情報を更新する（ステップＳ１２１２）。その後、制御部１０３が状態情報を確認する（ステップＳ１２１３）。ダウンロードを１つキャンセルしたことで、小区間のデータＤx1のダウンロードが可能となった。これにより、制御部１０３のダウンロード制御部１１２による制御に従って、通信部１０２が、コンテンツ管理サーバ２０１に対して、小区間のデータＤx1のダウロード要求を送信する（ステップＳ１２１４〜Ｓ１２１６）。これにより、コンテンツ管理サーバ２０１から、小区間のデータＤx1のダウンロードが開始される。

一定時間が経過し、制御部１０３が小区間のデータＤx1が再生可能なだけダウンロードできたと判断した場合、再生部１０７に再生指示を出力する（ステップＳ１２１７）。そして、再生部１０７が、記憶部１０４から小区間のデータＤx1を読み出して（ステップＳ１２１８）、当該小区間のデータＤx1の再生を開始する（ステップＳ１２１９）。

一連の説明において、通信装置１００で、再生中の小区間に対する再生が終了した場合には、自動的に次の小区間の再生を開始する。同様に、通信装置１００で、再生中の区間を構成する最後の小区間に対する再生が終了した場合には、自動的に次の区間の再生を開始する。その際、各区間の最初の小区間は事前にダウンロードされている可能性が高いが、ダウンロードされていない場合もありうる。この場合、Ｄx1に移動するユーザ操作が発生した場合と同様に処理することで対応できる。

次に、通信装置１００の記憶部１０４に保存する各種情報について説明する。図１３〜図１８は、記憶部１０４で管理する状態情報の一例を示した図である。図１３〜図１８に示す状態情報は、図３に示す構造をもったコンテンツファイルを例として用いている。

図１３〜図１８では、各小区間を一つのエントリとする表形式で表現しているが、同等の情報を扱うことができれば他の形式であっても良い。当該状態情報は、制御部１０３がメタ情報の解析が終了した時点（図９のステップＳ９０３）で、当該状態情報を生成し、記憶部１０４に記憶させる。

そして、図９のステップＳ９１５〜Ｓ９２３に示すように、各小区間取得要求が、ダウンロード制御部１１２による制御で通信部１０２から送信された場合、図１４で示した状態となる（なお、図９では、煩雑になるのを抑止するため状態情報の更新は省略している）。このように、チャプタ１〜３の最初の小区間のデータについては、ダウンロードが開始される。

この後、制御部１０３が、小区間のデータを受信するごとに、状態情報において対応するエントリを受信済みバイト数で更新する（図９のステップＳ９３４）。さらに、制御部１０３が、再生するために十分なバイト数を受信したと判定した場合、再生部１０７に指示する（図１０のステップＳ１００１）。これにより再生部１０７が小区間Ｄ11の再生を開始する（図１０のステップＳ１００３）。これに伴い、制御部１０３が、状態情報において該当するエントリを「再生中」で更新する（図１０では当該処理を省略する）。

そして、小区間Ｄ11のダウンロードが終了すると、ダウンロード制御部１１２の制御により、通信部１０２が、次の区間の最初の小区間のデータの受信（ダウンロード）を開始する（ステップＳ１０１０〜Ｓ１０１３）。この結果、状態情報は図１５のように更新される。つまり、チャプタ４の最初の小区間のエントリが、「ダウンロード中」と更新される。

通信装置１００において、ユーザインターフェイス部１０６が、別のチャプタ（区間）に移動する操作を受け付けた際、当該区間の最初の小区間のデータのダウンロードが、再生可能な程度に完了している場合、制御部１０３が、状態情報で、移動先を示す小区間に対応するエントリを「再生中」に変更する。例えば、小区間のデータＤ51への移動が指示された場合、小区間のデータＤ51が再生開始に足るサイズをダウンロードされていた場合、制御部１０３は、図１６に示す状態情報から、図１７に示す状態情報のように、チャプタ２の最初の小区間及びチャプタ５の最初の小区間を更新する。

一方、移動先の区間の小区間のデータＤx1が再生可能な程度にダウンロードされておらず（図８のステップＳ８１０：Ｎｏ）、小区間のデータＤx1はダウンロード中ではなく、さらに、ダウンロードカウンタｎが最大ダウンロード数Ｎ以上の場合（ステップＳ８１６：Ｎｏ）、状態情報のエントリでダウンロード中の示されている小区間のうち、適当な小区間のデータのダウンロードをキャンセルし（ステップＳ８１７）、ダウンロードカウンタｎから‘１’を減算した後（ステップＳ８１８）、ダウンロード制御部１１２の制御により、通信部１０２が、小区間のデータＤx1のダウンロードを新たに開始する（ステップＳ８１９）。

図１６は、当該処理の例として、小区間Ｄ21を再生中で、チャプタ３〜５がダウンロード中の例とする。そして、移動先として小区間Ｄ51が選択された場合、図１７の状態情報に示されるように、制御部１０３が、小区間Ｄ21のエントリを「ダウンロード済」に更新し、小区間Ｄ51のエントリを「ダウンロード・再生中」に更新する。

一方、図１６に示す状況で、移動先として小区間Ｄ61が選択された場合、小区間Ｄ31に対するダウンロードがキャンセルされ、小区間Ｄ61に対するダウンロードが開始される。そこで、図１８の状態情報に示されるように、制御部１０３が、小区間Ｄ21のエントリを「ダウンロード済」に更新し、小区間Ｄ61のエントリを「ダウンロード中」に更新し、小区間Ｄ31のエントリを「ダウンロード停止中」に更新する。

上述した第１の実施形態では、通信装置１００が複数の小区間を並列にダウンロードする際、各ダウンロードの速度を制御できるように実装しても良い。例えば、再生中の区間に対するダウンロードを優先する、各区間の先頭の小区間を優先する、再生場所に近い順に帯域を割り当てる、などの制御方法が考えられる。

第１の実施形態にかかる通信装置１００では、各チャプタ（区間）の最初の小区間のデータを早くダウンロードすることが重要となる。そのため、最初は低品質のコンテンツをダウンロードするなどしてダウンロード容量と時間を減らすようにしても良い。その際、コンテンツ管理サーバ２０１側に品質が異なる複数のコンテンツファイルを準備しておく方式と、スケーラブル符号化方式を用いてエンコードしたコンテンツを用意する方法の２通りが考えられる。いずれの場合も、事前のダウンロードを低品質のコンテンツに対して行うことで、容量と時間を削減できる。そして、通信装置１００が再生を行う際、事前にダウンロードしておいたコンテンツに置き換えもしくは追加する形で高品質なコンテンツを再生する。

（第１の実施形態の変形例）
第１の実施形態では、メタ情報のコンテンツを区切るチャプタ毎に、開始時刻又は開始バイト数が含まれている例について説明した。しかしながら、メタ情報は、各チャプタ（区分）の開始時刻又は開始バイト数が含まれていることに制限するものではない。このようにメタ情報に、データの区切りの位置を含むのではなく、コンテンツの内部を示す情報のみが含まれていても良い。

この場合、本変形例にかかるダウンロード制御部１１２は、メタ情報の解析結果に基づいて、コンテンツを区切り、当該区切り位置を特定し、特定した区切り位置に従ってダウンロード制御を行っても良い。なお、ダウンロード手法は、第１の実施形態と同様として説明を省略する。

上述した手法以外にも様々な手法が考えられる。例えば、コンテンツの区切り位置を特定する手法として、一度再生した過去のコンテンツの構造に関する情報を、通信装置１００自ら蓄積しておき、当該コンテンツの再利用の際に利用しても良い。

（第２の実施形態）
第１の実施形態にかかる通信装置１００では、ダウンロードの対象となる各チャプタの小区間は、チャプタ１から順に選択されていた。しかしながら、このような選択手法に制限するものではない。そこで、第２の実施形態では、通信装置１００が、ダウンロード対象となるチャプタの順序を決定する例について説明する。

図１９は、第２の実施形態にかかる通信装置１９００のブロック構成を示した図である。図１９に示すように、通信装置１９００は、第１の実施形態の通信装置１００と比べて、制御部１０３が制御部１９１０に変更された例とする。なお、第１の実施形態と同一の構成については、同一の符号を付与し、説明を省略する。

制御部１９１０は、第１の実施形態の制御部１０３と比べて、決定部１９１１が追加された構成とする。

決定部１９１１は、コンテンツを構成する複数のチャプタ（区分）に対して、ダウンロード制御部１１２がダウンロードする順序を決定する。

本実施形態では、制御部１０３がメタ情報を解析して、抽出した各区分の優先順位に従って、決定部１９１１がダウンロードする順番を決定する。

ところで、現在、ユーザが、お気に入りのシーンを視聴するために、コンテンツに対して区分を設定し、ネットワークを介して他のユーザと共有する技術が提案されている。さらに、ユーザが設定した区分毎に、視聴数や人気を保持する技術も提案されている。そこで、本実施形態にかかるメタ情報管理サーバ２０２では、通信装置１９００に対して提供するメタ情報に、他のユーザが設定した区分や、視聴数や人気に基づく各区分の優先順位が設定されているものとする。この優先順位が高い区分は、他のユーザからも評判が高い区分である。そのため、通信装置１９００で当該コンテンツを視聴するユーザも当該区分について興味を有している可能性が高く、当該区分について優先的に視聴される可能性が高い。

そこで、本実施形態にかかる決定部１９１１は、メタ情報に含まれていた、このようにユーザが設定した区分と、当該区分の人気順等に基づく優先順位に従って、コンテンツに含まれている各区分のダウンロード順を決定する。

そして、ダウンロード制御部１１２は、決定部１９１１に決定されたダウンロード順に従った上で、第１の実施形態と同様に３個の小区間のデータを並行してダウンロードする。

このように、本実施形態にかかる通信装置１９００では、決定部１９１１で決定された順序に従って、小区間のデータをダウンロードすることとした。これにより、ユーザが視聴する可能性の高い小区間のデータを優先的にダウンロードすることが可能となり、コンテンツ移動をする際にシームレスな再生の可能性を向上させることができる。

（第３の実施形態）
次に、第３の実施形態について説明する。図２０は、第３の実施形態にかかる通信装置２０００のブロック構成を示した図である。図２０に示すように、通信装置２０００は、第１の実施形態の通信装置１００と比べて、制御部１９１０が制御部２０１０に変更された例とする。なお、第２の実施形態と同一の構成については、同一の符号を付与し、説明を省略する。

制御部２０１０は、第２の実施形態の制御部１９１０と比べて、コマンド送信制御部２０１１が追加された構成とする。

コマンド送信制御部２０１１は、図２１に示すコンテンツ管理サーバ２１０１に対する復帰指示や休止指示のコマンドを生成し、通信部１０２を制御して、当該復帰指示や休止指示を送信制御する。

図２１は、第３の実施形態にかかるネットワークを模式的に示した図である。図２１に示すように、通信装置２０００と、コンテンツ管理サーバ２１０１と、は、家庭又は事業所内のＬＡＮ等の小規模ネットワークで接続されている。このようなネットワーク構成において、コンテンツ管理サーバ２１０１を常時起動させておくのは、消費電力等の観点から望ましくない。

そこで、本実施形態にかかるコンテンツ管理サーバ２１０１は、休止状態と、動作中の状態とを切り替え可能とする。その上で、コンテンツ管理サーバ２１０１は、通信装置２０００からの制御指示により、少なくとも動作状態と、休止状態と、の２つの状態の間で状態遷移を可能とした。

このように、コマンド送信制御部２０１１は、通信装置２０００のコンテンツのダウンロード状況に応じてコンテンツ管理サーバ２１０１の動作状態を制御するように指示を出す機能を有する。その際、コマンド送信制御部２０１１は、動作状態又は休止状態に遷移させる制御コマンドを生成して、通信部１０２を介してコンテンツ管理サーバ２１０１に向けて送信させる機能を有する。

コマンド送信制御部２０１１は、コンテンツ管理サーバ２１０１に合わせた制御方法を使用する。また、コマンド送信制御部２０１１が行う制御内容もコンテンツ管理サーバ２１０１の能力に依存する。例えば、コンテンツ管理サーバ２１０１が外部からの指示を受信して「休止状態」（外部からの問い合わせに応答できない状態の総称とする）から「動作状態」（コンテンツを速やかに提供できる状態）に復帰可能とするために、コマンド送信制御部２０１１は、はコンテンツ管理サーバ２１０１に応じた復帰指示機能を有している。

例えば、コンテンツ管理サーバ２１０１がマジックパケット（登録商標）を用いたWake on ＬＡＮで復帰可能な場合、コマンド送信制御部２０１１はマジックパケットの生成機能と、通信部１０２を介したマジックパケットの送信機能と、を備えている。他にも赤外線や電波などの無線媒体、電力線を含む様々な有線媒体を介した復帰指示方法が考えられる。これらの方法で通常の通信とは異なる通信インターフェイスを必要とする場合には、通信装置２０００は、通信Ｉ／Ｆ部１０１に加えて、復帰指示機能に対応した別の通信インターフェイスも備える必要がある。

なお、通信装置２０００が、「休止状態→動作状態」、「動作状態→休止状態」のいずれか一方でも対応する手段を具備しない場合、本実施形態にかかるコマンド送信制御部２０１１が当該いずれか一方に対応する動作を行わないように実装しても良い。又は対応する手段を具備した別の通信装置に対して、コマンド送信制御部２０１１が処理の代行を依頼するよう実装しても良い。

そして、コマンド送信制御部２０１１は、コンテンツ管理サーバ２１０１に対して、必要に応じて、休止指示を行うためのコマンドを生成する。例えば、コンテンツ管理サーバ２１０１が、コンテンツをＨＴＴＰでダウンロード可能とするサーバとする。そして、コンテンツ管理サーバ２１０１が、休止状態への指示を、ＨＴＴＰのメッセージとして受信できる。その場合、コマンド送信制御部２０１１は、休止指示を行うためのＨＴＴＰメッセージを生成して、通信部１０２を介して送信する機能を有する。

さらにコンテンツ管理サーバ２１０１が「動作状態」と「休止状態」以外の様々な状態に遷移可能な場合、コマンド送信制御部２０１１がこれらの状態に遷移するための制御指示の手法を備えていても良い。

なお、コマンド送信制御部２０１１が、通信Ｉ／Ｆ部１０１を介して直接制御指示を送信するか、通信部１０２に送信を依頼して制御指示を送信するかは、使用する制御手法および実装に依存する事項である。

なお、コンテンツ管理サーバ２１０１がこのような状態制御機能を備えていることに伴い、通信装置２０００に送信するメタ情報を第１の実施形態と異ならせても良い。例えば、メタ情報の形式は第１の実施形態と同様であるが、小区間をサーバの状態遷移の都合に基づいて決定しても良い。すなわち、小区間に対して、各区間の最小のデータサイズとして、コンテンツ管理サーバ２１０１が「動作状態→休止状態→動作状態」という遷移を行い、エネルギー消費を節約できる最低の再生時間が確保できる長さのデータを定めても良い。また、小区間のデータサイズは、コンテンツ管理サーバ２１０１と通信装置２０００との間の通信路の帯域や帯域遅延積に依存して決定しても良い。

このように遷移に要する時間を通信装置２０００が認識するために、本実施形態においては、コンテンツ管理サーバ２１０１が、通信装置２０００に対して、「動作状態→休止状態」の遷移に要する時間と、「休止状態→動作状態」の遷移に要する時間と、が含まれたサーバ情報を、送信する。

サーバ情報は、コンテンツ管理サーバ２１０１がサポートしている状態（例えば動作状態、休止状態）間での遷移手段（休止指示の方法、復帰指示の方法など）や各状態間での遷移に要する時間などを含んでいる。通信装置２０００は、サーバ情報を解析することで、コマンド送信制御部２０１１が対応可能であるか否かを判断できる。その上、サーバ情報は、コマンド送信制御部２０１１が、コマンドを送信するタイミングを制御する際にも用いられる。

図２２は、コンテンツのダウンロード状況に応じた、コンテンツ管理サーバ２１０１の動作状態と休止状態との遷移タイミングを説明した図である。図２２に示す例では、既にデータ２２０１がダウンロード済みとする。これにより、再生されていないデータ２２０２が存在する。この再生されていないデータ２２０２のサイズに基づいて、コンテンツ管理サーバ２１０１の状態の切り替え制御を行う。なお、当該切り替え制御の前に、通信装置２０００は、コンテンツ管理サーバ２１０１からサーバ情報を受信し、状態遷移に要する時間を認識しているものとする。

さらに、通信装置２０００の制御部２０１０は、コンテンツ管理サーバ２１０１との間のネットワークの回線速度と、コンテンツのビットレートと、に基づいて、コンテンツ管理サーバ２１０１が状態遷移（例えば、動作状態→休止状態→動作状態）に要する時間の間、コンテンツをシームレスに再生するために必要なデータサイズを特定する。

そして、図２２に示すように、通信装置２０００は、当該コンテンツのチャプタ１について、データサイズ２２０１だけダウンロード済みであり、未再生のデータサイズ２２０２とする。

そして、制御部２０１０は、未再生のデータサイズ２２０２が、状態遷移（例えば、動作状態→休止状態→動作状態）に要する時間をシームレスに再生するために必要なデータサイズより大きいと判定した場合、コマンド送信制御部２０１１が、休止状態に遷移するためのコマンドを生成し、コンテンツ管理サーバ２１０１に対して通信部１０２を介して送信制御する。

そして、コンテンツの再生２２０３がなされた後、制御部２０１０は、未再生のデータサイズ２２０４が、状態遷移（例えば、休止状態→動作状態）に要する時間をシームレスに再生するために必要なデータサイズより小さくならない、所定のタイミングで、コマンド送信制御部２０１１が、動作状態に遷移するためのコマンドを生成し、コンテンツ管理サーバ２１０１に対して通信部１０２を介して送信制御する。

なお、制御部２０１０による判定では、データサイズを用いることに制限するものではなく、再生時間を用いて判定を行っても良い。後述する図２５では、データサイズの代わりに再生時間を用いた例について説明する。このようにコンテンツがシームレスに再生できるか否かの判定ができれば、データサイズを用いても、再生時間を用いても良い。

また、ユーザインターフェイス部１０６で、他のチャプタに移動する操作を受け付けた場合も、移動先のチャプタの未再生のデータサイズ２２０５に基づいて、コマンド送信制御部２０１１が、状態遷移するためのコマンドを生成し、コンテンツ管理サーバ２１０１に対して通信部１０２を介して送信制御する。コマンドを生成する条件については、上述した条件と同様として説明を省略する。コマンド送信制御部２０１１が、コマンドの生成及び送信を行う際に、５，１０秒ぐらいの余裕を持たせても良い。

図２３は、本実施形態の通信装置２０００とコンテンツ管理サーバ２１０１との間の動作を表したシーケンスを示した図である。図２３に示すシーケンスでは、まず通信装置２０００の通信部１０２が、制御部２０１０の制御に従って、コンテンツ管理サーバ２１０１に対して、サーバ情報の要求を送信する（ステップＳ２３０１）。これにより、コンテンツ管理サーバ２１０１が、通信装置２０００に対して、サーバ情報を送信する（ステップＳ２３０２）。このサーバ情報は、記憶部１０４に記憶される。

そして、通信装置２０００の制御部２０１０は、記憶部１０４に記憶されたサーバ情報を解析する（ステップＳ２３０３）。これにより、制御部２０１０は、コンテンツ管理サーバ２１０１を動作状態に遷移させるコマンド、休止状態に遷移させるコマンド、さらにコンテンツ管理サーバ２１０１の状態遷移に要する時間を認識できる。

その後、第１の実施形態の図６で示した処理（ステップＳ６０１〜Ｓ６１０）と同様の手順で再生の開始まで行われる（ステップＳ２３０４〜２３１３）。

そして、通信装置２０００の通信部１０２が、チャプタ８（Ｃｈ．８）の最初の小区間における最後のデータを受信する（ステップＳ２３１４）。その後、制御部２０１０が、コンテンツ管理サーバ２１０１を休止させるべきか否かを判定する（ステップＳ２３１５）。判定手法は上述した通りとして説明を省略する。

休止させるべきと判定した場合、コマンド送信制御部２０１１が、休止状態に遷移させるための休止指示コマンドを生成し、通信部１０２を介してコンテンツ管理サーバ２１０１に対して、休止指示コマンドを送信する（ステップＳ２３１６）。

その後、制御部２０１０が、コンテンツ管理サーバ２１０１の復帰が必要か否かを判定する（ステップＳ２３１７）。この判定基準は、上述した基準と同様として説明を省略する。以降、復帰が必要と判定された場合について説明する。

まず、コマンド送信制御部２０１１が、動作状態に復帰させるための復帰指示コマンドを生成し、コンテンツ管理サーバ２１０１に送信する（ステップＳ２３１８）。これにより、コンテンツ管理サーバ２１０１が動作状態に移動する。

その後、通信装置２０００は動作状態に遷移するまでの時間を待機する。なお、当該待機時間はサーバ情報に基づいて決定される。そして、ダウンロード制御部１１２が、通信部１０２を制御して、チャプタ１の２番目（Ｃｈ．１−２）の小区間についてのダウンロード要求を、コンテンツ管理サーバ２１０１に対して送信する（ステップＳ２３１９）。これにより、ダウンロード制御部１１２が通信部１０２を制御して、コンテンツ管理サーバ２１０１から、チャプタ１の２番目の小区間のデータをダウンロードする（ステップＳ２３２０）。

このように、本実施形態にかかる通信装置２０００は、コンテンツ管理サーバ２１０１からのダウンロードが不要と判断したタイミングにおいて休止指示のコマンドを送信し、必要と判断したタイミングにおいて復帰指示のコマンドを送信する。これにより、コンテンツ管理サーバ２１０１側の不要な待機状態を減らすことができる。

本実施形態にかかる通信装置２０００の再生開始までの処理手順について説明する。図２４は、通信装置２０００の再生開始までのフローチャートを示した図である。本実施形態では、制御部２０１０による制御で、通信部１０２がサーバ情報を予め要求しておく必要があるが、すでにサーバ情報を得ているサーバについては再取得する必要が無い。そこで、制御部２０１０が、すでにサーバ情報を得ている既知のサーバであるか否かを判定する（ステップＳ２４０１）。既存のサーバと判定した場合（ステップＳ２４０１：Ｙｅｓ）、ステップＳ２４０５以降の処理を行う。なお、当該判定は、必須ではなく毎回取得しても良い。

一方、制御部２０１０が、サーバ情報の取得が必要と判断した場合（ステップＳ２４０１：Ｎｏ）、制御部２０１０がサーバ情報の取得要求を生成し、コンテンツ管理サーバ２１０１に送信する（ステップＳ２４０２）。これにより、通信部１０２が、取得要求先のコンテンツ管理サーバ２１０１から、サーバ情報を受信し、記憶部１０４に保存する（ステップＳ２４０３）。その後、制御部２０１０が、取得したサーバ情報を解析し、保存する（Ｓ２４０４）。

この後の処理については、第１の実施形態と同様の手順（ステップＳ７０１〜Ｓ７１３）で、メタ情報のタウンロード及びコンテンツのダウンロードが行われ、コンテンツの再生が開始される（ステップＳ２４０５〜Ｓ２４０８）。

図２４のステップＳ２４０４で示した制御部２０１０によるサーバ情報の解析結果について説明する。図２６は、制御部２０１０によるサーバ情報の解析結果として記憶部１０４に保存された情報の第１の例を示した図である。図２６に示す例では、コンテンツ管理サーバ２１０１が２つの状態「動作」と「休止」とを備えている。そして、それぞれの状態毎に、各状態間での遷移手段と、遷移時間と、が対応付けて記憶されている。

図２７は、制御部２０１０によるサーバ情報の解析結果として記憶部１０４に保存された情報の第２の例を示した図である。図２７に示す例では、状態が「動作」、「休止１」及び「休止２」の３種類の状態を備えている。そして、図２６と同様に、それぞれの状態毎に、各状態間での遷移手段と、遷移時間と、が対応付けて記憶されている。なお、２つの状態間での遷移ができない場合は遷移手段として「遷移不可」を設定されているものとする。

図２８は、図２７に示すサーバ情報に従った各状態の遷移を示した図である。図２８に示すように、動作状態及び休止１では、ＨＴＴＰによるコマンドで、状態遷移を行うことができる。これに対し、休止２では、ＨＴＴＰによるコマンドを認識できないため、Ｗａｋｅ ｏｎ ＬＡＮにより起動させることとする。

なお、サーバ情報はいずれの形式でも良いが、例えば、ＸＭＬ形式を用いることができる。

本実施形態にかかる通信装置２０００の再生中の処理手順について説明する。図２５は、通信装置２０００の再生中のフローチャートを示した図である。まずは、図８のステップＳ８０１〜Ｓ８０６までの処理と同様に、未ダウンロードの小区間のデータＤ*1のダウンロードが開始される（ステップＳ２５０１〜Ｓ２５０６）。ただし、図８と異なる点として、トリガーとなるイベントとして、再生中の区間に含まれるダウンロード済みの小区間の再生可能な時間が、閾値よりも小さくなった場合を追加し、当該イベントの発生に対応する処理が、ステップＳ２５１３〜Ｓ２５１６に追加されたものとする。なお、このイベントは、休止中のコンテンツ管理サーバ２１０１を復帰させるためのイベントである。このイベントが発生した際の処理については後述する。

そして、ステップＳ２５０４で、制御部２０１０が、小区間のデータＤ*1で未ダウンロードのものが無いと判定した場合（ステップＳ２５０４：Ｎｏ）の場合、制御部２０１０は、再生中の区間でダウンロード済みの小区間で、未再生な部分による再生可能な時間と、コンテンツ管理サーバ２１０１が状態遷移を経て、復帰するまでに要する時間（休止遷移時間及び復帰遷移時間の合計）と、を比較する（ステップＳ２５０７）。さらに復帰するまでに要する時間として、消費電力の削減効果が得られる最低時間などの他のパラメータを加えても良い。

そして、制御部２０１０が、再生時間の方が長いと判定した場合（ステップＳ２５０７：Ｙｅｓ）、制御部２０１０が、現在のダウンロードカウンタｎが‘0'か否かを判定する（ステップＳ２５１２）。制御部２０１０が、‘0'ではないと判定した場合（ステップＳ２５１２：Ｎｏ）、イベントの発生まで待機する（ステップＳ２５０１）。一方、制御部２０１０が、‘0’であると判定した場合（ステップＳ２５１２：Ｙｅｓ）、コマンド送信制御部２０１１が、コンテンツ管理サーバ２１０１に対して、休止状態に遷移させる休止指示コマンドの生成、送信を行う（ステップＳ２５１１）。なお、ステップＳ２５１２におけるダウンロードカウンタｎによる判定処理は、制御部２０１０が記憶部１０４に保存されているカウンタ値を参照することで行う。また、休止指示コマンドの送信は、上述した通りとする。休止指示コマンドによる送信は、サーバ情報から読み出した設定に基づいて行う。

また、ステップＳ２５０７で、制御部２０１０が、再生時間の方が短いと判定した場合い（ステップＳ２５０７：Ｎｏ）、未ダウンロードの小区間のデータＤ*y(y!=1)があるか否かを判定する（ステップＳ２５０８）。

そして、制御部２０１０が、未ダウンロードの小区間のデータＤ*y(y!=1)が無いと判定した場合（ステップＳ２５０８：Ｎｏ）、全ての小区間のデータＤ*y(y!=1)がダウンロード完了していることになるため、コマンド送信制御部２０１１が、コンテンツ管理サーバ２１０１に対して、休止指示コマンドの生成、送信を行う（ステップＳ２５１１）。

また、ステップＳ２５０８で、未ダウンロードの小区間のデータＤ*y(y!=1)があると判定した場合（ステップＳ２５０８：Ｙｅｓ）、第１の実施形態と同様（図８のステップＳ８０８及びステップＳ８０９）に小区間のデータＤ*y(y!=1)のダウンロードの開始と、ダウンロードカウンタｎへの‘１’追加と、を行う（ステップＳ２５０９、ステップＳ２５１０）。

ステップＳ２５０１でイベント発生の基準となる再生時間の算出は、上述したようにメタ情報に基づいて行う。つまり、メタ情報に含まれている各区間の時間情報を用いて、ダウンロードしたコンテンツのデータサイズと、再生時間と、の関係を導出する。例えば、コンテンツがＣＢＲ方式でエンコードされていれば、区間の再生時間を区間のバイト数で割ればバイト当たりの再生時間を算出できる。ＶＢＲ方式でエンコードされている場合にも小区間毎の平均的なビットレートを用いれば、ＣＢＲと同様の手法でバイト当たりの再生時間を算出できる。また、コンテンツを再生したことで得られる情報を用いてバイト数あたりの再生時間を算出しても良い。いずれかの方法で算出した再生時間の情報を使って、状態遷移に要する時間との比較を行う。

そして、ステップＳ２５０２において、制御部２０１０が、「再生中の区間の再生時間が少ない場合」のイベントが発生したと判定した場合（ステップＳ２５０２）、通信装置２０００のコマンド送信制御部２０１１が、通信部１０２を制御して、コンテンツ管理サーバ２１０１に対して、動作状態に遷移する復帰指示コマンドを直ちに送信する（ステップＳ２５１３）。この復帰指示コマンドは、サーバ情報に基づいて生成する。

その後、制御部２０１０が、サーバ情報に基づき、コンテンツ管理サーバ２１０１が動作状態への復帰を待機する一方、再生部１０７が、コンテンツの再生を継続して行う（ステップＳ２５１４）。待機が完了すると、ダウンロード制御部１１２は、コンテンツ管理サーバ２１０１に対して、小区間のデータのダウンロードを要求する。これにより、ダウンロード制御部１１２は、コンテンツ管理サーバ２１０１から小区間のデータのダウンロードを開始する（ステップＳ２５１５）。ここで要求する小区間のデータは、現在の再生が継続した場合に必要になる、未ダウンロードの小区間のうち、最も早く再生が行われる小区間のデータとする。そして、制御部２０１０が、ダウンロードカウンタｎに‘１’追加する（ステップＳ２５１６）。

さらに、本実施形態では、コンテンツ管理サーバ２１０１と通信装置２０００との双方がダウンロードを任意の場所で停止・再開できる場合には、その機能を利用して任意のタイミングでコンテンツ管理サーバ２１０１を休止状態にしても良い。すなわち、図２５のダウンロードカウンタｎが‘0’であることを判定する処理の代わりに、通信中の全てのダウンロードを停止させて、コンテンツ管理サーバ２１０１に休止状態に遷移するように指示するように実現しても良い。

そして、ステップＳ２５０２において、制御部２０１０が、「Ｄx1に移動するユーザ操作」のイベントが発生したと判定した場合（ステップＳ２５０２）、第１の実施形態の図８のステップＳ８１０〜Ｓ８２３の処理と同様、小区間のデータＤx1の再生と各小区間のダウンロードを行う（ステップＳ２５１７）。

このように第３の実施形態では、第１の実施形態の効果の他に、コンテンツを提供するコンテンツ管理サーバ２１０１を休止状態に遷移させることで、システム全体としての消費電力を低減できる。第１の実施形態で述べた方法を使用して小区間ごとにダウンロードしているため、コンテンツ管理サーバ２１０１の状態遷移に要する時間を隠蔽することもできる。

上述した実施形態及び変形例においては、コンテンツをダウンロードする際に、当該コンテンツを分割する区間毎に最初の小区間をダウンロードすることとした。これにより、コンテンツの再生中に、区間の移動の選択を受け付けた場合でも、移動先の位置からのコンテンツの再生を停止することなく実行できる。これによりユーザの利便性を向上させることができる。

上述した実施形態の通信装置は、ＣＰＵなどの制御装置と、ＲＯＭ（Read Only Memory）やＲＡＭなどの記憶装置と、ＨＤＤ、ＣＤドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置を備えており、通常のコンピュータを利用したハードウェア構成となっている。

上述した実施形態の通信装置で実行される通信制御プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、上述した実施形態の通信装置で実行される通信制御プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態の実施形態の通信装置で実行される通信制御プログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。

また、本実施形態の通信制御プログラムを、ＲＯＭ等に予め組み込んで提供するように構成しても良い。

本実施形態の通信装置で実行される通信制御プログラムは、上述した各部（通信部、制御部、再生部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記記憶媒体から通信制御プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、通信部、制御部、再生部が主記憶装置上に生成されるようになっている。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１００、１９００、２０００ 通信装置
１０１ 通信Ｉ／Ｆ部
１０２ 通信部
１０３、１９１０、２０１０ 制御部
１０４ 記憶部
１０６ ユーザインターフェイス部
１０７ 再生部
１１１ 取得部
１１２ タウンロード制御部
２００ ネットワーク
２０１ コンテンツ管理サーバ
２０２ メタ情報管理サーバ
１９１１ 決定部
２０１１ コマンド送信制御部
２１０１ コンテンツ管理サーバ

Claims (10)

1. データの構造を表した構造情報を取得する取得部と、
   前記構造情報に基づいて前記データを区切った複数の部分データのうち、当該区切り位置をダウンロードの開始位置として、一つ以上の部分データをダウンロードするダウンロード制御部と、
   前記データの前記区切り位置の選択を受け付ける選択受付部と、
   前記選択受付部により選択を受け付けた前記区切り位置から、前記データを出力する出力部と、
   を備えることを特徴とするデータ処理装置。
2. 前記複数の部分データに対して、ダウンロードする順序を決定する決定部をさらに備え、
   前記ダウンロード制御部は、前記決定部に決定された順序に従った上で、前記一つ以上の部分データをダウンロードすること、
   を特徴とする請求項１に記載のデータ処理装置。
3. 前記ダウンロード制御部は、前記出力部により前記部分データの出力が開始された際に前記部分データのダウンロードが再開された場合において前記出力部がシームレスに出力可能とするデータサイズ分の前記部分データをダウンロードした後に、前記部分データのダウンロードを停止し、さらに他の区切り位置を開始位置として他の部分データをダウンロードすること、
   を特徴とする請求項１又は２に記載のデータ処理装置。
4. 前記ダウンロード制御部のダウンロード先のデータ記憶装置が、データを送信可能な起動状態と、データを送信不可能な待機状態と、を遷移可能である場合に、前記データ記憶装置に対して、前記待機状態に遷移する要求と、前記データ記憶装置に対して前記起動状態に遷移する要求と、を送信する送信制御部を、
   さらに備えたことを特徴とする請求項３に記載のデータ処理装置。
5. 前記送信制御部は、前記ダウンロード制御部によりダウンロードされた前記部分データのうち前記出力部において未出力の部分が、前記データ記憶装置が前記起動状態、休止状態及び前記起動状態の順に遷移するまでに要する時間をシームレスに出力可能とするデータサイズ以上の場合に、前記データ記憶装置に対して前記待機状態に遷移する要求を送信すること、
   を特徴とする請求項３に記載のデータ処理装置。
6. 前記送信制御部は、さらに、前記ダウンロード制御部によりダウンロードされた前記部分データのうち前記出力部において未出力の部分が、前記休止状態から前記起動状態に遷移するまでに要する時間をシームレスに出力可能とするデータサイズより小さくならない、所定のタイミングで、前記データ記憶装置に対して前記起動状態に遷移する要求を送信すること、
   を特徴とする請求項４又は５に記載のデータ処理装置。
7. 前記取得部が取得する前記構造情報は、前記データの構造として前記データの区切り位置が含まれていること、を特徴とする請求項１に記載のデータ処理装置。
8. 前記取得部が取得する前記構造情報は、前記データの構造として前記データの区切り位置を含まず、
   前記ダウンロード制御部は、さらに、前記構造情報のデータの構造を解析して前記区切り位置を特定してから、ダウンロードを行うこと、
   を特徴とする請求項１に記載のデータ処理装置。
9. データ処理装置で実行されるデータ処理方法であって、
   前記データ処理装置は、
   取得部が、データの構造を表した構造情報を取得する取得ステップと、
   ダウンロード制御部が、前記構造情報に基づいて前記データを区切った複数の部分データのうち、当該区切り位置をダウンロードの開始位置として、一つ以上の部分データをダウンロードするダウンロード制御ステップと、
   選択受付部が、前記データの前記区切り位置の選択を受け付ける選択受付ステップと、
   出力部が、前記選択受付ステップにより選択を受け付けた前記区切り位置から、前記データを出力する出力ステップと、
   を含むことを特徴とするデータ処理方法。
10. データの構造を表した構造情報を取得する取得ステップと、
    前記構造情報に基づいて前記データを区切った複数の部分データのうち、当該区切り位置をダウンロードの開始位置として、一つ以上の部分データをダウンロードするダウンロード制御ステップと、
    前記データの前記区切り位置の選択を受け付ける選択受付ステップと、
    前記選択受付ステップにより選択を受け付けた前記区切り位置から、前記データを出力する出力ステップと、
    をコンピュータに実行させるためのプログラム。

Images