(57)【要約】【課題】  コンテンツの自動配信を受ける利用者の端末内の記憶装置の記憶領域をあらかじめ確保しておくことが可能なコンテンツ配信システム，利用者端末，コンテンツ配信サーバおよびコンピュータプログラムを提供する。【解決手段】  本発明に係るコンテンツ配信システム１００は，利用者が所有する利用者端末１１０と，利用者端末１１０の要求に応じてあるいは所定の条件により自動的にコンテンツを配信するコンテンツ配信サーバ１２０と，がネットワークを介して接続されており，利用者端末１１０は，利用者端末１１０内の記憶装置に配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する容量判断手段と，記憶装置に配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に少なくとも記憶装置の空き容量が不足している旨のアラートを通知するアラート通知手段と，を備える。【選択図】    図１
2006053633.tif 000002
【特許請求の範囲】
【請求項１】
利用者が所有する利用者端末と，前記利用者端末の要求に応じてあるいは所定の条件により自動的にコンテンツを配信するコンテンツ配信サーバと，がネットワークを介して接続された，コンテンツ配信システムであって：
前記コンテンツ配信サーバは，前記利用者端末に対して，配信予定のコンテンツの容量に関するデータを送信する，データ送信手段を備え，
前記利用者端末は，
前記送信された配信予定のコンテンツの容量に基づいて，前記利用者端末内の記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する，容量判断手段と；
前記記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に，少なくとも前記記憶装置の空き容量が不足している旨のアラートを通知する，アラート通知手段と；
を備えることを特徴とする，コンテンツ配信システム。
【請求項２】
前記コンテンツ配信サーバは，
少なくとも前記配信予定のコンテンツの容量に関するデータを含むメタデータを格納する，メタデータデータベースと；
少なくとも前記配信予定のコンテンツの容量に変更があった場合に，前記格納されたメタデータの更新を行う，メタデータ更新手段と；
をさらに備え，
前記利用者端末は，前記コンテンツ配信サーバに対し，前記メタデータの更新があったか否かを定期的にポーリングする，ポーリング手段をさらに備え，
前記データ受信手段は，前記ポーリングの結果，前記メタデータの更新があった場合に，更新後の前記メタデータを受信し，
前記容量判断手段は，受信された前記更新後の前記メタデータを読み込み，少なくとも前記配信予定のコンテンツの容量が変更されていると判断した場合には，前記変更された前記配信予定のコンテンツの容量に基づいて，前記配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する，
ことを特徴とする，請求項１に記載のコンテンツ配信システム。
【請求項３】
利用者が所有する利用者端末と，前記利用者端末の要求に応じてあるいは所定の条件により自動的にコンテンツを配信するコンテンツ配信サーバと，がネットワークを介して接続された，コンテンツ配信システムであって：
前記利用者端末は，前記コンテンツ配信サーバに対して，前記利用者端末内の記憶装置の容量に関するデータを送信する，データ送信手段を備え，
前記コンテンツ配信サーバは，
配信予定のコンテンツの容量と前記送信された前記記憶装置の容量とに基づいて，前記記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する，容量判断手段と；
前記記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に，前記利用者端末に，少なくとも前記記憶装置の空き容量が不足している旨のアラートを送信する，アラート送信手段と；
を備えることを特徴とする，コンテンツ配信システム。
【請求項４】
前記コンテンツ配信サーバは，
少なくとも前記配信予定のコンテンツの容量に関するデータを含むメタデータを格納する，メタデータデータベースと；
少なくとも前記配信予定のコンテンツの容量に変更があった場合に，前記格納されたメタデータの更新を行う，メタデータ更新手段と；
をさらに備え，
前記容量判断手段は，前記メタデータの更新があった場合に，前記更新された前記メタデータを読み込み，前記配信予定のコンテンツの容量が変更されていると判断した場合には，前記変更された前記配信予定のコンテンツの容量に基づいて，前記配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する，
ことを特徴とする，請求項３に記載のコンテンツ配信システム。
【請求項５】
要求に応じてあるいは所定の条件により自動的にコンテンツを配信するコンテンツ配信サーバから，前記コンテンツの配信を受ける利用者端末であって：
配信予定のコンテンツの容量に関するデータを受信する，データ受信手段と；
前記受信された配信予定のコンテンツの容量に基づいて，前記利用者端末内の記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する，容量判断手段と；
前記記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に，少なくとも前記記憶装置の空き容量が不足している旨のアラートを通知する，アラート通知手段と；
を備えることを特徴とする，利用者端末。
【請求項６】
少なくとも前記配信予定のコンテンツの容量に変更があった場合に，少なくとも前記配信予定のコンテンツの容量に関するデータを含むメタデータの更新を行う前記コンテンツ配信サーバに対し，前記メタデータの更新があったか否かを定期的にポーリングする，ポーリング手段と；
前記ポーリングの結果，前記メタデータの更新があった場合に，更新後の前記メタデータを受信する，メタデータ受信手段と；
をさらに備え，
前記容量判断手段は，受信された前記更新後の前記メタデータを読み込み，少なくとも前記配信予定のコンテンツの容量が変更されていると判断した場合には，前記変更された前記配信予定のコンテンツの容量に基づいて，前記配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する，
ことを特徴とする，請求項５に記載の利用者端末。
【請求項７】
前記配信予定のコンテンツの容量は，一定であることを特徴とする，請求項６に記載の利用者端末。
【請求項８】
利用者端末の要求に応じて，あるいは所定の条件により自動的にコンテンツを配信するコンテンツ配信サーバであって：
前記利用者端末内の記憶装置の容量に関するデータを受信する，データ受信手段と；
配信予定のコンテンツの容量と前記受信された前記記憶装置の容量とに基づいて，前記記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する，容量判断手段と；
前記記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に，前記利用者端末に，少なくとも前記記憶装置の空き容量が不足している旨のアラートを送信する，アラート送信手段と；
を備えることを特徴とする，コンテンツ配信サーバ。
【請求項９】
少なくとも前記配信予定のコンテンツの容量に関するデータを含むメタデータを格納する，メタデータデータベースと；
少なくとも前記配信予定のコンテンツの容量に変更があった場合に，前記格納されたメタデータの更新を行う，メタデータ更新手段と；
をさらに備え，
前記容量判断手段は，前記メタデータの更新があった場合に，前記更新された前記メタデータを読み込み，前記配信予定のコンテンツの容量が変更されていると判断した場合には，前記変更された前記配信予定のコンテンツの容量に基づいて，前記配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する，
ことを特徴とする，請求項８に記載のコンテンツ配信サーバ。
【請求項１０】
要求に応じて，あるいは所定の条件により自動的に，コンテンツの配信を受けるためのコンピュータプログラムであって：
コンピュータを，
配信予定のコンテンツの容量に関するデータを受信する，データ受信手段と；
前記受信された配信予定のコンテンツの容量に基づいて，前記利用者端末内の記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する，容量判断手段と；
前記記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に，少なくとも前記記憶装置の空き容量が不足している旨のアラートを通知する，アラート通知手段と；
して機能させるための，コンピュータプログラム。
【請求項１１】
利用者端末の要求に応じて，あるいは所定の条件により自動的にコンテンツを配信するためのコンピュータプログラムであって：
コンピュータを，
前記利用者端末内の記憶装置の容量に関するデータを受信する，データ受信手段と；
配信予定のコンテンツの容量と前記受信された前記記憶装置の容量とに基づいて，前記記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する，容量判断手段と；
前記記憶装置に前記配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に，前記利用者端末に対し，少なくとも前記記憶装置の空き容量が不足している旨のアラートを送信する，アラート送信手段と；
して機能させるための，コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，コンテンツ配信システム，利用者端末，コンテンツ配信サーバおよびコンピュータプログラムに関する。
【背景技術】
【０００２】
近年，通信技術などの発達により，例えばインターネットなどのネットワークを介した情報提供サービスが可能となっており，文字情報，画像情報，音声情報などの様々な情報が提供されている。このような情報提供サービスを提供するシステム（情報提供システム）においては，文字情報や映像情報などの情報コンテンツが，例えば購入手続などのユーザによる情報提供の要求ごとに個々に提供される場合のほかに，定期購読などの形態で定期的に自動配信される場合もある。
【０００３】
このように自動配信される場合には，例えば就寝中などの間に，利用者端末にコンテンツが自動的に配信（ダウンロード）され，利用者端末の例えばハードディスク装置（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ：以下，ＨＤＤという）などの記憶装置に記憶されることになる。このため，利用者は，コンテンツをダウンロードしている間，端末の前で待っている必要もなく，また，ダウンロードのための操作の必要もない。したがって，コンテンツを視聴等しようとする利用者にとっては，便利である。
【０００４】
ところが，コンテンツが自動配信される前に，例えば，利用者が，他の目的で作成した文書ファイルや画像ファイルを利用者端末の記憶装置（例えば，ＨＤＤなど）に保存したことなどにより，利用者端末の記憶装置の記憶容量がたまたま不足していたような場合には，配信が予定されていたコンテンツの全部または一部がダウンロードできないという問題があった。
【０００５】
一方，コンテンツをダウンロードあるいはアップロードする際には，そのコンテンツの容量に基づいて，あらかじめそのコンテンツを記憶装置に記憶することが可能か否かを判定してから，記憶可能な場合にダウンロード等することも行われている。これにより，ダウンロード等を開始した後に空き容量不足のためにダウンロード等できなかったというような事態を防止することができる（例えば，特許文献１参照）。
【０００６】
【特許文献１】特開２００３−１０８４７７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら，例えば，コンテンツに対する課金処理がすでに行われてしまった後で，コンテンツの自動配信が行われるような場合には，利用者はすでにそのコンテンツに対する代金を支払っているため，問題となる。
【０００８】
すなわち，特許文献１に記載されたように，ダウンロード前に記憶可能か否かの判定を行ったとしても，実際にダウンロードできなかった場合には，利用者は，すでに代金を支払ったコンテンツの配信を受けることができないことになるため，問題となる。
【０００９】
そこで，本発明は，このような問題に鑑みてなされたもので，その目的は，自動的に配信されるコンテンツの配信を確実に行うために，該コンテンツの配信を受ける利用者の端末内のＨＤＤなどの記憶装置の記憶領域をあらかじめ確保しておくことが可能な新規かつ改良されたコンテンツ配信システム，利用者端末，コンテンツ配信サーバおよびコンピュータプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
上記課題を解決するために，本発明の第１の観点によれば，利用者が所有する利用者端末と，利用者端末の要求に応じてあるいは所定の条件により自動的にコンテンツを配信するコンテンツ配信サーバとがインターネット等のネットワークを介して接続されたコンテンツ配信システムが提供される。
【００１１】
本発明の第１の観点によるコンテンツ配信システムにおいては，コンテンツ配信サーバは，利用者端末に対して，配信予定のコンテンツの容量に関するデータを送信するデータ送信手段を備えている。また，利用者端末は，送信された配信予定のコンテンツの容量に基づいて利用者端末内の記憶装置に配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する容量判断手段と，記憶装置に配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に少なくとも記憶装置の空き容量が不足している旨のアラートを通知するアラート通知手段と，を備えている。
【００１２】
このように，上記コンテンツ配信システムにおいては，容量判断手段が配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合には，アラート通知手段によりアラートが通知される。一方，容量判断手段が配信予定のコンテンツを記憶するための容量が確保されていると判断した場合には，利用者端末は，容量が確保されている旨を任意の通知手段によりコンテンツ配信サーバに通知する。そして，容量が確保されている旨の通知を受けたコンテンツ配信サーバは，利用者端末に配信予定のコンテンツを配信し，利用者端末は，該コンテンツを受信することができる。
【００１３】
また，上記コンテンツ配信システムにおいては，コンテンツ配信サーバは，少なくとも配信予定のコンテンツの容量に関するデータを含むメタデータを格納するメタデータデータベースと，少なくとも配信予定のコンテンツの容量に変更があった場合に格納されたメタデータの更新を行うメタデータ更新手段と，をさらに備えていてもよい。
【００１４】
さらに，上記コンテンツ配信システムにおいては，利用者端末は，コンテンツ配信サーバに対し，メタデータの更新があったか否かを定期的にポーリングするポーリング手段をさらに備えていてもよい。この場合に，データ受信手段は，上記ポーリングの結果，メタデータの更新があった場合に，更新後のメタデータを受信し，容量判断手段は，受信された更新後のメタデータを読み込み，少なくとも配信予定のコンテンツの容量が変更されていると判断した場合には，変更された配信予定のコンテンツの容量に基づいて，配信予定のコンテンツを記憶するための容量が確保されているか否かを判断することもできる。
【００１５】
上記課題を解決するために，本発明の第２の観点によれば，利用者が所有する利用者端末と，利用者端末の要求に応じてあるいは所定の条件により自動的にコンテンツを配信するコンテンツ配信サーバとがインターネット等のネットワークを介して接続されたコンテンツ配信システムが提供される。
【００１６】
本発明の第２の観点によるコンテンツ配信システムにおいては，利用者端末は，コンテンツ配信サーバに対して利用者端末内の記憶装置の容量に関するデータを送信するデータ送信手段を備えている。また，コンテンツ配信サーバは，配信予定のコンテンツの容量と送信された利用者端末内の記憶装置の容量とに基づいて上記記憶装置に配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する容量判断手段と，上記記憶装置に配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に利用者端末に少なくとも上記記憶装置の空き容量が不足している旨のアラートを送信するアラート送信手段と，を備えている。
【００１７】
このように，上記コンテンツ配信システムにおいては，容量判断手段が配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合には，アラート送信手段によりアラートが送信される。一方，容量判断手段が配信予定のコンテンツを記憶するための容量が確保されていると判断した場合には，その配信予定のコンテンツの配信が行われ，利用者端末は，該コンテンツを受信することができる。
【００１８】
また，上記コンテンツ配信システムにおいては，コンテンツ配信サーバは，少なくとも配信予定のコンテンツの容量に関するデータを含むメタデータを格納するメタデータデータベースと，少なくとも配信予定のコンテンツの容量に変更があった場合に格納されたメタデータの更新を行うメタデータ更新手段と，をさらに備えていてもよい。
【００１９】
さらに，容量判断手段は，メタデータ更新手段によりメタデータの更新が行われた場合に，更新されたメタデータを読み込み，配信予定のコンテンツの容量が変更されていると判断した場合には，変更された配信予定のコンテンツの容量に基づいて，配信予定のコンテンツを記憶するための容量が確保されているか否かを判断することもできる。
【００２０】
このように，本発明に係るコンテンツ配信システム（本発明の第１の観点および第２の観点）によれば，利用者端末の記憶装置に，配信予定のコンテンツを記憶するための空き容量があるか否かの判断を行い，さらに，空き容量がない場合には，アラートを通知または送信することにより，購入等した後に配信されるコンテンツを記憶するための容量を確保しておくことができる。したがって，他のアプリケーションなどで使用したことにより，コンテンツを記憶するための容量がたまたま不足していたため，ダウンロードをすることができなかったという事態を回避することが可能となり，コンテンツの自動配信を円滑に行うことができる。
【００２１】
上記課題を解決するために，本発明の第３の観点によれば，要求に応じてあるいは所定の条件により自動的にコンテンツを配信するコンテンツ配信サーバからコンテンツの配信を受ける利用者端末であって，配信予定のコンテンツの容量に関するデータを受信するデータ受信手段と，受信された配信予定のコンテンツの容量に基づいて利用者端末内の記憶装置に配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する容量判断手段と，上記記憶装置に配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に少なくとも記憶装置の空き容量が不足している旨のアラートを通知するアラート通知手段と，を備える利用者端末が提供される。
【００２２】
ここで，利用者端末内の記憶装置としては，ハードディスク装置（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ：ＨＤＤ）等の記憶装置を想定しているが，配信されるコンテンツを記憶することが可能な記憶媒体であれば，例えば，ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭのような外部記憶媒体などであってもよい。
【００２３】
また，容量判断手段による判断は，例えば，配信予定のコンテンツの容量と，記憶装置の記憶領域の空き容量とを比較することにより行う。また，例えば，記憶装置の記憶領域のうち現在使用している領域の容量と配信予定のコンテンツの容量との合計を，記憶装置の記憶領域の全容量と比較するなど，他の任意の方法により判断してもよい。
【００２４】
また，アラート通知手段によりアラートを通知する方法としては，例えば，利用者端末の表示装置に空き容量が不足している旨の文字を表示することにより行う方法があるが，画像により空き容量が不足している旨を表す方法，音声により通知する方法，あるいはこれらを組み合わせた方法等，任意の方法により通知してもよい。また，アラートを通知する場合には，空き容量が不足している旨に加えて，不要なファイルを削除すべき旨，一部のファイルを他の記憶装置（例えば，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭなど）に移動すべき旨，他の記憶領域に転送（例えば，ＨＤＤのＣ：ドライブからＤ：ドライブに転送）すべき旨等を共に表示してもよい。
【００２５】
また，上記利用者端末は，少なくとも配信予定のコンテンツの容量に変更があった場合に，少なくとも配信予定のコンテンツの容量に関するデータを含むメタデータの更新を行うコンテンツ配信サーバに対し，メタデータの更新があったか否かを定期的にポーリングするポーリング手段と，ポーリングの結果，メタデータの更新があった場合に，更新後のメタデータを受信するメタデータ受信手段と，をさらに備えていてもよい。
【００２６】
ここで，本発明におけるメタデータとは，コンテンツの属性を示すデータのことであって，例えば，コンテンツＩＤ，コンテンツ名，コンテンツの属するジャンル，コンテンツの置かれている場所を示すＵＲＬおよびコンテンツの容量などから構成されている。このうち，少なくとも配信予定のコンテンツの容量に関するデータが含まれることが好ましい。容量判断手段が利用者端末の記憶装置に容量が確保されているか否かを判断するために必要だからである。
【００２７】
また，メタデータの更新は，例えば，配信予定のコンテンツのうち一部のコンテンツが既に配信されたために配信予定のコンテンツが削除されたこと，利用者が新たなコンテンツを購入した等のために配信予定のコンテンツが新たに追加されたこと，コンテンツの置かれている場所が変更になったこと，あるいは配信予定のコンテンツの容量が変更になったことなどにより，コンテンツＩＤ，コンテンツ名，ジャンル，ＵＲＬ，容量等のメタデータが追加，削除，変更等された場合に行われる。
【００２８】
なお，メタデータの更新がされるためには，上記５つのメタデータのすべてが追加，変更等される必要はなく，このうちの１つ（例えば，コンテンツＩＤ）が追加，変更等されることにより，メタデータの更新が行われてもよい。特に，本発明においては，少なくともコンテンツの容量が変更になった場合にメタデータの更新が行われることが好ましい。配信予定のコンテンツの容量が変更になった場合には，記憶装置に確保しておくべき空き容量の大きさも変わってくるからである。
【００２９】
また，本発明におけるポーリングとは，コンテンツ配信サーバに対して，メタデータの更新があったか否かを問い合わせ，更新があった場合には，更新されたメタデータを利用者端末に送信するよう要求することをいう。
【００３０】
また，容量判断手段は，データ受信手段により受信された更新後のメタデータを読み込み，少なくとも配信予定のコンテンツの容量が変更されていると判断した場合には，変更された配信予定のコンテンツの容量に基づいて，配信予定のコンテンツを記憶するための容量が確保されているか否かを判断することもできる。
【００３１】
ここで，配信予定のコンテンツの容量は，一定であることもある。「容量が一定」とは，例えば，毎月一定の容量のコンテンツが配信される場合，毎月配信されるコンテンツの容量があらかじめ設定されており，設定されたコンテンツの容量が変動しない場合，配信予定のコンテンツの追加や変更等が行われない場合（配信予定のコンテンツに関するメタデータの更新が行われない場合）などをいう。
【００３２】
このような場合には，例えばコンテンツの購入等のときに，１度配信予定のコンテンツの容量のデータを受信しておけば，その後その容量の値が変動することはないので，上述したようなポーリングをする必要がなくなる。したがって，配信予定のコンテンツの容量が一定の場合には，利用者端末は，必ずしもポーリング手段を備えている必要はない。
【００３３】
なお，本発明に係る利用者端末としては，デスクトップ型のパーソナルコンピュータ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ：以下，「ＰＣ」とする）やノート型のＰＣ，ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）などが考えられるが，これらには限られず，上述した構成を備えていれば，例えば，携帯電話機などであってもよい。
【００３４】
このように，本発明に係る利用者端末によれば，利用者端末の記憶装置に，配信予定のコンテンツを記憶するための空き容量があるか否かの判断を行い，さらに，空き容量がない場合には，アラート通知をすることにより，購入等した後に配信されるコンテンツを記憶するための容量を確保しておくことができる。したがって，他のアプリケーションなどで使用したことにより，コンテンツを記憶するための容量がたまたま不足していたため，ダウンロードをすることができなかったという事態を回避することが可能となり，コンテンツの自動配信を円滑に行うことができる。
【００３５】
上記課題を解決するために，本発明の第４の観点によれば，利用者端末の要求に応じてあるいは所定の条件により自動的にコンテンツを配信するコンテンツ配信サーバであって，利用者端末内の記憶装置の容量に関するデータを受信するデータ受信手段と，配信予定のコンテンツの容量と受信された上記記憶装置の容量とに基づいて上記記憶装置に配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する容量判断手段と，上記記憶装置に配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に少なくとも上記記憶装置の空き容量が不足している旨のアラートを利用者端末に送信するアラート送信手段と，を備えるコンテンツ配信サーバが提供される。
【００３６】
ここで，データ受信手段が受信する記憶装置の容量に関するデータとしては，例えば，利用者端末の記憶装置の空き容量に関するデータや，上記記憶装置の全容量のデータと上記記憶装置の使用領域の容量のデータとの組み合わせ等がある。
【００３７】
また，容量判断手段による判断は，例えば，配信予定のコンテンツの容量と，利用者端末の記憶装置の記憶領域の空き容量とを比較することにより行う。また，例えば，上記記憶装置の記憶領域のうち現在使用している領域の容量と配信予定のコンテンツの容量との合計を，上記記憶装置の記憶領域の全容量と比較するなど，他の任意の方法により判断してもよい。
【００３８】
また，アラート送信手段により送信されたアラートは，利用者端末において利用者に通知される。アラートを通知する方法としては，例えば，利用者端末の表示装置に空き容量が不足している旨の文字を表示することにより行う方法があるが，画像により空き容量が不足している旨を表す方法，音声により通知する方法，あるいはこれらを組み合わせた方法等，任意の方法により通知してもよい。また，アラートを通知する場合には，空き容量が不足している旨に加えて，不要なファイルを削除すべき旨，一部のファイルを他の記憶装置（例えば，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭなど）に移動すべき旨，他の記憶領域に転送（例えば，ＨＤＤのＣ：ドライブからＤ：ドライブに転送）すべき旨等を共に表示してもよい。
【００３９】
また，上記コンテンツ配信サーバは，少なくとも配信予定のコンテンツの容量に関するデータを含むメタデータを格納するメタデータデータベースと，少なくとも配信予定のコンテンツの容量に変更があった場合に格納されたメタデータの更新を行うメタデータ更新手段と，をさらに備えていてもよい。
【００４０】
ここで，メタデータデータベースには，コンテンツＩＤ，コンテンツ名，コンテンツの属するジャンル，コンテンツが置かれている場所を示すＵＲＬ，コンテンツの容量等のメタデータが格納されている。なお，メタデータデータベースは，本発明においては，コンテンツ配信サーバに備えられているが，メタデータデータベースを備える独立のサーバが存在してもよい。
【００４１】
また，メタデータの更新は，上述したように，例えば，配信予定のコンテンツのうち一部のコンテンツが既に配信されたために配信予定のコンテンツが削除されたこと，配信予定のコンテンツの容量が変更になったこと等により，コンテンツＩＤ，コンテンツ名，ジャンル，ＵＲＬ，容量等のメタデータが追加，削除，変更等された場合に行われる。
【００４２】
なお，メタデータの更新がされるためには，上記５つのメタデータのすべてが追加，変更等される必要はなく，少なくともコンテンツの容量が変更になった場合にメタデータの更新が行われることが好ましい点も上述したのと同様である。
【００４３】
さらに，容量判断手段は，メタデータ更新手段によりメタデータの更新が行われた場合に，更新されたメタデータを読み込み，配信予定のコンテンツの容量が変更されていると判断した場合には，変更された配信予定のコンテンツの容量に基づいて，配信予定のコンテンツを記憶するための容量が確保されているか否かを判断することもできる。
【００４４】
このように，本発明に係るコンテンツ配信サーバによれば，利用者端末の記憶装置に，配信予定のコンテンツを記憶するための空き容量があるか否かの判断を行い，さらに，空き容量がない場合には，アラートを送信することにより，購入等した後に配信されるコンテンツを記憶するための容量を確保しておくことができる。したがって，他のアプリケーションなどで使用したことにより，コンテンツを記憶するための容量がたまたま不足していたため，配信をすることができなかったという事態を回避することが可能となり，コンテンツの自動配信を円滑に行うことができる。
【００４５】
上記課題を解決するために，本発明の第５の観点によれば，要求に応じてあるいは所定の条件により自動的にコンテンツの配信を受けるためのコンピュータプログラムであって，コンピュータを，配信予定のコンテンツの容量に関するデータを受信するデータ受信手段と，受信された配信予定のコンテンツの容量に基づいて利用者端末内の記憶装置に配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する容量判断手段と，記憶装置に配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に少なくとも記憶装置の空き容量が不足している旨のアラートを通知するアラート通知手段として機能させるためのコンピュータプログラムが提供される。
【００４６】
ここで，上記プログラムにおいて，記憶装置に容量が確保されているか否かの判断は，例えば，配信予定のコンテンツの容量と，記憶装置の記憶領域の空き容量とを比較することにより行う。すなわち，空き容量が配信予定のコンテンツの容量以上（空き容量≧配信予定のコンテンツの容量）の場合には，確保されている（記憶可能）と判断し，空き容量が配信予定のコンテンツの容量より小さい（空き容量＜配信予定のコンテンツの容量）の場合には，確保されていない（記憶不可能）と判断される。また，例えば，記憶装置の記憶領域のうち現在使用している領域の容量と配信予定のコンテンツの容量との合計を，記憶装置の記憶領域の全容量と比較するなど，他の任意の方法により判断してもよい。
【００４７】
また，上記プログラムにおいて，アラートを通知する方法としては，例えば，利用者端末の表示装置に空き容量が不足している旨の文字を表示することにより行う方法があるが，画像により空き容量が不足している旨を表す方法，音声により通知する方法，あるいはこれらを組み合わせた方法等，任意の方法により通知するよう制御してもよい。また，アラートを通知する場合には，空き容量が不足している旨に加えて，不要なファイルを削除すべき旨，一部のファイルを他の記憶装置（例えば，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭなど）に移動すべき旨，他の記憶領域に転送（例えば，ＨＤＤのＣ：ドライブからＤ：ドライブに転送）すべき旨等を共に表示するよう制御してもよい。
【００４８】
また，上記プログラムは，さらに，少なくとも配信予定のコンテンツの容量に変更があった場合に少なくとも配信予定のコンテンツの容量に関するデータを含むメタデータの更新を行うコンテンツ配信サーバに対し，メタデータの更新があったか否かを定期的にポーリングするポーリング手段と，ポーリングの結果，メタデータの更新があった場合に，更新後のメタデータを受信するメタデータ受信手段と，して機能させるためのプログラムであってもよい。
【００４９】
ここで，本発明におけるメタデータとは，コンテンツの属性を示すデータのことであって，例えば，コンテンツＩＤ，コンテンツ名，コンテンツの属するジャンル，コンテンツの置かれている場所を示すＵＲＬおよびコンテンツの容量などから構成されている。このうち，少なくとも配信予定のコンテンツの容量に関するデータが含まれることが好ましい。容量判断手段が利用者端末の記憶装置に容量が確保されているか否かを判断するために必要だからである。
【００５０】
また，メタデータの更新は，例えば，配信予定のコンテンツのうち一部のコンテンツが既に配信されたために配信予定のコンテンツが削除されたこと，利用者が新たなコンテンツを購入した等のために配信予定のコンテンツが新たに追加されたこと，コンテンツの置かれている場所が変更になったこと，あるいは配信予定のコンテンツの容量が変更になったことなどにより，コンテンツＩＤ，コンテンツ名，ジャンル，ＵＲＬ，容量等のメタデータが追加，削除，変更等された場合に行われる。
【００５１】
なお，メタデータの更新がされるためには，上記５つのメタデータのすべてが追加，変更等される必要はなく，このうちの１つ（例えば，コンテンツＩＤ）が追加，変更等されることにより，メタデータの更新が行われてもよい。特に，本発明においては，少なくともコンテンツの容量が変更になった場合にメタデータの更新が行われることが好ましい。配信予定のコンテンツの容量が変更になった場合には，記憶装置に確保しておくべき空き容量の大きさも変わってくるからである。
【００５２】
また，本発明におけるポーリングとは，コンテンツ配信サーバに対して，メタデータの更新があったか否かを問い合わせ，更新があった場合には，更新されたメタデータを利用者端末に送信するよう要求することをいう。
【００５３】
また，上記プログラムにおいて，コンテンツ配信サーバから受信した更新後のメタデータを読み込み，少なくとも配信予定のコンテンツの容量が変更されていると判断した場合には，変更された配信予定のコンテンツの容量に基づいて，配信予定のコンテンツを記憶するための容量が確保されているか否かを判断することもできる。
【００５４】
上記課題を解決するために，本発明の第６の観点によれば，利用者端末の要求に応じてあるいは所定の条件により自動的にコンテンツを配信するためのコンピュータプログラムであって，コンピュータを，利用者端末内の記憶装置の容量に関するデータを受信するデータ受信手段と，配信予定のコンテンツの容量と受信された上記記憶装置の容量とに基づいて上記記憶装置に配信予定のコンテンツを記憶するための容量が確保されているか否かを判断する容量判断手段と，上記記憶装置に配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に少なくとも記憶装置の空き容量が不足している旨のアラートを利用者端末に送信するアラート送信手段として機能させるためのコンピュータプログラムが提供される。
【００５５】
ここで，上記記憶装置の容量に関するデータとしては，例えば，利用者端末の記憶装置の空き容量に関するデータや，上記記憶装置の全容量のデータと上記記憶装置の使用領域の容量のデータとの組み合わせ等がある。
【００５６】
また，上記プログラムにおいて，記憶装置に容量が確保されているか否かの判断は，例えば，配信予定のコンテンツの容量と，利用者端末の記憶装置の記憶領域の空き容量とを比較することにより行う。すなわち，空き容量が配信予定のコンテンツの容量以上（空き容量≧配信予定のコンテンツの容量）の場合には，確保されている（記憶可能）と判断し，空き容量が配信予定のコンテンツの容量より小さい（空き容量＜配信予定のコンテンツの容量）の場合には，確保されていない（記憶不可能）と判断する。また，例えば，上記記憶装置の記憶領域のうち現在使用している領域の容量と配信予定のコンテンツの容量との合計を，上記記憶装置の記憶領域の全容量と比較するなど，他の任意の方法により判断してもよい。
【００５７】
また，アラート送信手段により送信されたアラートは，利用者端末において利用者に通知される。アラートを通知する方法としては，例えば，利用者端末の表示装置に空き容量が不足している旨の文字を表示することにより行う方法があるが，画像により空き容量が不足している旨を表す方法，音声により通知する方法，あるいはこれらを組み合わせた方法等，任意の方法により通知してもよい。また，アラートを通知する場合には，空き容量が不足している旨に加えて，不要なファイルを削除すべき旨，一部のファイルを他の記憶装置（例えば，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭなど）に移動すべき旨，他の記憶領域に転送（例えば，ＨＤＤのＣ：ドライブからＤ：ドライブに転送）すべき旨等を共に表示してもよい。
【００５８】
また，上記プログラムは，さらに，少なくとも配信予定のコンテンツの容量に関するデータを含むメタデータを格納する格納手段と，少なくとも配信予定のコンテンツの容量に変更があった場合に格納されたメタデータの更新を行うメタデータ更新手段と，して機能させるためのプログラムであってもよい。
【００５９】
また，メタデータの更新は，上述したように，例えば，配信予定のコンテンツのうち一部のコンテンツが既に配信されたために配信予定のコンテンツが削除されたこと，配信予定のコンテンツの容量が変更になったこと等により，コンテンツＩＤ，コンテンツ名，ジャンル，ＵＲＬ，容量等のメタデータが追加，削除，変更等された場合に行われる。
【００６０】
なお，メタデータの更新がされるためには，上記５つのメタデータのすべてが追加，変更等される必要はなく，少なくともコンテンツの容量が変更になった場合にメタデータの更新が行われることが好ましい点も上述したのと同様である。
【００６１】
さらに，上記プログラムにおいて，メタデータ更新手段によりメタデータの更新が行われた場合に，更新されたメタデータを読み込み，配信予定のコンテンツの容量が変更されていると判断した場合には，変更された配信予定のコンテンツの容量に基づいて，配信予定のコンテンツを記憶するための容量が確保されているか否かを判断することもできる。
【００６２】
このように，本発明に係るコンピュータプログラムによれば，利用者端末の記憶装置に，配信予定のコンテンツを記憶するための空き容量があるか否かの判断を行い，さらに，空き容量がない場合には，アラートを通知または送信することにより，購入等した後に配信されるコンテンツを記憶するための容量を確保しておくことができる。したがって，他のアプリケーションなどで使用したことにより，コンテンツを記憶するための容量がたまたま不足していたため，配信をすることができなかったという事態を回避することが可能となり，コンテンツの自動配信を円滑に行うことができる。
【発明の効果】
【００６３】
本発明によれば，自動的に配信されるコンテンツの配信を確実に行うために，該コンテンツの配信を受ける利用者の端末内のＨＤＤなどの記憶装置の記憶領域をあらかじめ確保しておくことが可能なコンテンツ配信システム，利用者端末，コンテンツ配信サーバおよびコンピュータプログラムを提供することができる。
【発明を実施するための最良の形態】
【００６４】
以下に添付図面を参照しながら，本発明の好適な実施の形態について詳細に説明する。なお，本明細書及び図面において，実質的に同一の機能構成を有する構成要素については，同一の符号を付することにより重複説明を省略する。
【００６５】
＜第１の実施形態＞
（コンテンツ配信システム１００の構成）
まず，図１を参照しながら，本発明の第１の実施形態に係るコンテンツ配信システム１００の構成について説明する。なお，図１は，本発明の第１の実施形態に係るコンテンツ配信システム１００の概略的な構成を示すブロック図である。
【００６６】
図１に示したように，本実施形態に係るコンテンツ配信システム１００においては，主として，利用者端末１１０とコンテンツ配信サーバ１２０とライセンス認証サーバ１３０と課金サーバ１４０とが，例えばインターネットなどのネットワーク１５０を介して接続されている。
【００６７】
利用者端末１１０は，コンテンツ配信システム１００の提供するコンテンツ配信サービスを利用する利用者の所有する端末であり，コンテンツ配信サーバ１２０から，利用者端末１１０の要求に応じてあるいは自動的に配信される１または複数のコンテンツを受信して，それを出力（表示など）する端末装置である。
【００６８】
なお，利用者端末１１０としては，デスクトップ型のパーソナルコンピュータ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ：以下，「ＰＣ」とする）やノート型のＰＣ，ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）などが考えられるが，これらには限られず，後述する本実施形態に係る利用者端末１１０の構成を備えていれば，例えば，携帯電話機などであってもよい。
【００６９】
本実施形態に係る利用者端末１１０は，図２に示したように，ＣＰＵ１１０２と，ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）などの記憶装置１１０４と，入力装置１１０６と，表示装置１１０８と，データ受信手段１１１０と，容量判断手段１１１２と，アラート通知手段１１１４と，コンテンツ受信手段１１１６とを備えている。なお，図２は，本実施形態に係る利用者端末１１０の概略的な構成を示したブロック図である。
【００７０】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１０２は，利用者端末１１０が行う処理の全般を制御する装置である。記憶装置１１０４は，主に，ＨＤＤなどの記憶装置を想定しているが，配信されるコンテンツを記憶することが可能な記憶媒体であれば，例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭのような外部記憶媒体などでもよい。入力装置１１０６は，コンテンツ配信システム１００の利用者が利用者端末１１０を操作するための装置で，例えば，マウスやキーボードなどのユーザインターフェース（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ：ＵＩ）のことである。表示装置１１０８は，配信されたコンテンツを視聴したり，後述するアラートを表示したりするために用いられる装置（ディスプレイ）である。
【００７１】
データ受信手段１１１０は，主に，コンテンツ配信サーバ１２０から送信された配信予定のコンテンツの容量に関するデータを受信するための手段である。
【００７２】
容量判断手段１１１２は，データ受信手段１１１０により受信された配信予定のコンテンツの容量に基づいて，記憶装置１１０４の記憶領域に，配信予定のコンテンツを記憶することが可能か否か，すなわち，配信予定のコンテンツを記憶するための容量が確保されているか否かを判断するための手段である。この判断は，例えば，配信予定のコンテンツの容量と，記憶装置１１０４の記憶領域の空き容量とを比較することにより行う。すなわち，空き容量が配信予定のコンテンツの容量以上（空き容量≧配信予定のコンテンツの容量）の場合には，確保されている（記憶可能）と判断し，空き容量が配信予定のコンテンツの容量より小さい（空き容量＜配信予定のコンテンツの容量）の場合には，確保されていない（記憶不可能）と判断する。また，例えば，記憶装置１１０４の記憶領域のうち現在使用している領域の容量と配信予定のコンテンツの容量との合計を，記憶装置１１０４の記憶領域の全容量と比較するなど，他の任意の方法により判断してもよい。
【００７３】
アラート通知手段１１１４は，容量判断手段１１１２が記憶装置１１０４に配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に，少なくとも記憶装置１１０４の空き容量が不足している旨のアラートを利用者に通知するための手段である。アラートを通知する方法としては，例えば，表示装置１１０８に空き容量が不足している旨の文字を表示することにより行う方法があるが，画像により空き容量が不足している旨を表す方法，音声により通知する方法，あるいはこれらを組み合わせた方法等，任意の方法により通知してもよい。なお，利用者端末１１０が携帯電話機などである場合には，バイブレーション機能を使用してもよい。また，アラートを通知する場合には，空き容量が不足している旨に加えて，不要なファイルを削除すべき旨，一部のファイルを他の記憶装置（例えば，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭなど）に移動すべき旨，他の記憶領域に転送（例えば，ＨＤＤのＣ：ドライブからＤ：ドライブに転送）すべき旨等を共に表示してもよい。
【００７４】
コンテンツ受信手段１１１６は，容量判断手段１１１２が記憶装置１１０４に配信予定のコンテンツを記憶するための容量が確保されていると判断した場合に，配信予定のコンテンツを受信するための手段である。
【００７５】
ここで，容量判断手段１１１２が配信予定のコンテンツを記憶するための容量が確保されていると判断した場合には，利用者端末１１０は，容量が確保されている旨を任意の通知手段（図示せず）により，コンテンツ配信サーバ１２０に通知する。そして，容量が確保されている旨の通知を受けたコンテンツ配信サーバ１２０は，利用者端末１１０に，配信予定のコンテンツを実際に配信し，利用者端末１１０は，コンテンツ受信手段１１１６により，該コンテンツを受信する。
【００７６】
また，利用者端末１１０は，図２に示したように，ポーリング手段１１１８をさらに備えていてもよい。
【００７７】
ポーリング手段１１１８は，コンテンツ配信サーバ１２０に対し，配信予定のコンテンツの属性を示すデータ（メタデータ）について追加，変更等があったか否か，すなわち，更新があったか否かを定期的にポーリングするための手段である。本実施形態におけるメタデータには，少なくとも配信予定のコンテンツの容量に関するデータが含まれる。
【００７８】
ここで，図９を参照しながら，本実施形態に係るメタデータの構成について説明する。なお，図９は，本実施形態に係る配信予定のコンテンツのメタデータのデータ構造の例を示す説明図である。
【００７９】
本実施形態に係るメタデータは，図９に示したように，例えば，コンテンツＩＤ，コンテンツ名，ジャンル，ＵＲＬおよびコンテンツの容量から構成されている。
【００８０】
各コンテンツには，固有のコンテンツＩＤが割り振られている。本実施形態においては，コンテンツＩＤは，００１，１２３等の３桁の数字としているが，桁数は３桁に限られず，また，数字だけでなく，アルファベット，数字とアルファベットの組み合わせ等任意の方法で定めることができる。また，ジャンルは，例えば，洋画，スポーツ，車，グルメ，旅行等のそのコンテンツが属する情報のジャンルを示しており，ＵＲＬは，そのコンテンツが置かれている場所を示している。
【００８１】
なお，本実施形態においては，コンテンツのメタデータとして，コンテンツＩＤ，コンテンツ名，ジャンル，ＵＲＬ，容量の５つを挙げたが，これらには限られず，再生時間，製作者，お勧め度，視聴のためのライセンスを取得済みか否か等が含まれていてもよい。
【００８２】
一方，本実施形態を実施するためには，必ずしも上記５つのメタデータを備えている必要はなく，少なくともコンテンツ名またはコンテンツＩＤのいずれか一方，およびコンテンツの容量が含まれていれば十分である。コンテンツ名またはコンテンツＩＤのいずれか一方がわかっていればコンテンツを特定することができ，コンテンツの容量がわかっていれば記憶装置１１０４に容量が確保されているか否か（記憶可能か否か）を判断することができるからである。
【００８３】
次に，再び図２を参照しながら，ポーリング手段１１１８の説明を続ける。上述したように，ポーリング手段１１１８は，コンテンツ配信サーバ１２０に対し，メタデータの更新があったか否かを定期的にポーリングするが，ここでいうポーリングの意味について以下に説明する。すなわち，本実施形態におけるポーリングとは，コンテンツ配信サーバ１２０に対して，メタデータの更新があったか否かを問い合わせ，更新があった場合には，更新されたメタデータを利用者端末１１０に送信するよう要求することをいう。
【００８４】
送信された更新後のメタデータは，データ受信手段１１１０により受信される。さらに，容量判断手段１１１２は，受信された更新後のメタデータを読み込み，少なくとも配信予定のコンテンツの容量が変更されていると判断した場合には，変更されたコンテンツの容量に基づいて，記憶装置１１０４に容量が確保されているか否かの判断を行う。
【００８５】
ここで，配信予定のコンテンツの容量は一定であってもよい。「容量が一定」とは，例えば，毎月一定の容量のコンテンツが配信される場合，毎月配信されるコンテンツの容量があらかじめ設定されており，設定されたコンテンツの容量が変動しない場合，配信予定のコンテンツの追加や変更等が行われない場合（配信予定のコンテンツに関するメタデータの更新が行われない場合）などをいう。
【００８６】
このような場合には，例えばコンテンツの購入等のときに，１度配信予定のコンテンツの容量のデータを受信しておけば，その後その容量の値が変動することはないので，上述したようなポーリングをする必要がなくなる。したがって，配信予定のコンテンツの容量が一定の場合には，利用者端末１１０は，必ずしもポーリング手段１１１８を備えている必要はない。
【００８７】
次に，コンテンツ配信サーバ１２０の構成について説明する。コンテンツ配信サーバ１２０は，利用者端末１１０に対し，利用者端末１１０の要求に応じてあるいは所定の条件により自動的にコンテンツを配信するサーバ装置である。
【００８８】
本実施形態に係るコンテンツ配信サーバ１２０は，図２に示したように，ＣＰＵ１２０２と，コンテンツデータベース（ＤＢ）１２０４と，メタデータデータベース（ＤＢ）１２０６と，データ送信手段１２０８と，コンテンツ配信手段１２１０と，を備えている。
【００８９】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１２０２は，コンテンツ配信サーバ１２０が行う処理の全般を制御する装置である。
【００９０】
コンテンツデータベース１２０４には，利用者端末１１０からの要求に応じて利用者端末１１０に例えば有償で提供される複数の映像コンテンツデータが格納されている。コンテンツ配信システム１００の利用者は，コンテンツデータベース１２０４の格納されたコンテンツデータの中から所望のコンテンツ，例えば，視聴したい映像コンテンツを選択することができる。コンテンツ配信サーバ１２０は，利用者により選択されたコンテンツをコンテンツデータベース１２０４から抽出し，利用者端末１１０に配信することができる。
【００９１】
なお，コンテンツデータベース１２０４は，本実施形態においては，コンテンツ配信サーバ１２０に備えられているが，コンテンツデータベース１２０４を備える独立のサーバ（図示せず）がコンテンツ配信システム１００に存在していてもよい。
【００９２】
メタデータデータベース１２０６には，図９に示すように，コンテンツＩＤ，コンテンツ名，コンテンツの属するジャンル，コンテンツが保存されている場所を示すＵＲＬ，容量等のメタデータが格納されている。なお，メタデータについては，上述したので，詳しい説明はここでは省略する。
【００９３】
ここで，メタデータデータベース１２０６は，本実施形態においては，コンテンツ配信サーバ１２０に備えられているが，メタデータデータベース１２０６を備える独立のサーバ（図示せず）がコンテンツ配信システム１００に存在していてもよい。
【００９４】
データ送信手段１２０８は，主に，配信予定のコンテンツの容量に関するデータをメタデータデータベース１２０６から抽出して，利用者端末１１０に送信するための手段である。データ送信手段１２０８が配信予定のコンテンツの容量を利用者端末１１０に送信することにより，利用者端末１１０は，配信予定のコンテンツを記憶するための容量が記憶装置１１０４に確保されているか否かを判断することができる。
【００９５】
コンテンツ配信手段１２１０は，利用者端末１１０から記憶装置１１０４に配信予定のコンテンツを記憶するための容量が確保されている旨の通知を受けた場合に，利用者端末１１０にそのコンテンツを配信するための手段である。
【００９６】
また，本実施形態に係るコンテンツ配信サーバ１２０は，メタデータ更新手段１２１２をさらに備えていてもよい。メタデータ更新手段１２１２は，メタデータデータベース１２０６に格納されたメタデータの更新を行うための手段である。
【００９７】
ここで，メタデータの更新について詳細に説明する。本実施形態においては，メタデータの更新は，コンテンツ配信サーバ１２０において行われ，具体的には以下のような場合に行われる。すなわち，例えば，図９に示したコンテンツのうち一部のコンテンツ（例えば，「ワールドカップスキー（第１戦）〜（第３戦）」）が既に配信されたために配信予定のコンテンツが削除されたこと，利用者が新たなコンテンツを購入した等のために配信予定のコンテンツが新たに追加されたこと，コンテンツの置かれている場所が変更になったこと，あるいは配信予定のコンテンツの容量が変更になったことなどにより，コンテンツＩＤ，コンテンツ名，ジャンル，ＵＲＬ，容量等のメタデータが追加，削除，変更等された場合に，メタデータの更新が行われる。
【００９８】
ここで，メタデータの更新がされるためには，上記５つのメタデータのすべてが追加，変更等される必要はなく，このうちの１つ（例えば，コンテンツＩＤ）が追加，変更等されることにより，メタデータの更新が行われるようにしてもよい。特に，本実施形態においては，少なくともコンテンツの容量が変更になった場合にメタデータの更新が行われることが好ましい。配信予定のコンテンツの容量が変更になった場合には，記憶装置１１０４に確保しておくべき空き容量の大きさも変わってくるからである。
【００９９】
本実施形態に係るライセンス認証サーバ１３０は，利用者が利用者端末１１０を介して例えば動画コンテンツ等のコンテンツを視聴等するために必要なライセンス登録情報（図示せず）が格納されているサーバ装置である。このライセンス登録情報は，例えば，動画を視聴することが可能な利用者端末が，視聴可能な期間とともに登録されている。そして，ライセンス認証サーバ１３０によるライセンス認証により，利用者は動画像を視聴することができる。
【０１００】
課金サーバ１４０は，コンテンツの配信料などの課金データに基づいて請求書金額情報を検索した後，これを印刷または電子的に出力するサーバ装置である。また，課金サーバ１４０は，利用者ごとに請求すべき当期間の請求情報を計算してその結果を利用者端末１１０に送信する。
【０１０１】
なお，本実施形態では，コンテンツ配信システム１００を構成する装置として，利用者端末１１０，コンテンツ配信サーバ１２０，ライセンス認証サーバ１３０および課金サーバ１４０を挙げたが，本実施形態の適用のためには，少なくとも利用者端末１１０およびコンテンツ配信サーバ１２０が備わっていれば十分である。
【０１０２】
（コンテンツ配信システム１００における処理のフロー）
次に，本実施形態に係るコンテンツ配信システム１００において，どのようにコンテンツの配信が行われるかについて説明する。
【０１０３】
（１：コンテンツ配信システム１００用のアプリケーションのダウンロード）
まず，コンテンツ配信システム１００を利用しようとする利用者は，ネットワークを介して，コンテンツ配信システム１００を利用するためのアプリケーションのダウンロードを行う。利用者は，上記アプリケーションをダウンロードした後，コンテンツ配信システム１００用に使用するための記憶装置１１０４（ここでは，理解を容易にするため，ハードディスク装置とする）の容量をあらかじめ設定しておくことができる。
【０１０４】
このように，コンテンツ配信システム１００に使用する分の容量をあらかじめ設定しておくことで，購入等した後に配信されるコンテンツを記憶するための容量を確保しておくことができる。したがって，他のアプリケーションなどで使用したことにより，コンテンツを記憶するための容量がたまたま不足していたため，ダウンロードをすることができなかったという事態を回避することが可能となる。
【０１０５】
ここで，図１０を参照しながら，記憶装置１１０４（例えば，ハードディスク装置）の容量の設定について説明する。この容量設定の説明においては，理解を容易にするために，記憶装置１１０４はハードディスク装置であるものとして説明する。なお，図１０は，本発明の実施形態に係るコンテンツ配信システムにおけるハードディスク装置の容量設定変更画面の表示例を示す説明図である。
【０１０６】
ハードディスク装置の容量設定変更画面は，例えば，図１０に示したように表示される。ラベル５０２は，本画面のタイトルを示したもので，本画面が設定を変更する画面であることを示している。タブ５０４は，ハードディスクに関する設定を変更する画面であることを示している。アイコン５０６，５０８，５１０，５１２，５１４，５１６，５１８および５２０は，コンテンツ配信システム１００に使用する分のハードディスク容量を，それぞれ，６ＧＢ，８ＧＢ，１０ＧＢ，１２ＧＢ，１４ＧＢ，１６ＧＢ，１８ＧＢおよび２０ＧＢに設定するボタンを表示したものである。アイコン５２２は，コンテンツ配信システム１００に使用する分のハードディスク容量を利用者が指定した容量に設定するボタンを表示したものである。容量の指定は，例えば，キーボードの上下キーや数字キー等により入力することができる。また，ラベル５２４は，コンテンツ配信システム１００に使用するために容量（領域）を確保した場所を表示したものであり，図１０においては，Ｃ：ドライブに領域が確保されているということが表示されている。アイコン５２６は，「決定」ボタンであり，利用者がこれを選択することにより，設定変更完了画面（図示せず）に移行する。アイコン５２８は，「戻る」ボタンであり，利用者がこれを選択すると，設定処理を行わずに，直前の画面に戻る。
【０１０７】
利用者は，コンテンツ配信システム１００に使用するためのハードディスク容量の設定を変更したい場合には，タブ２を選択すると，図１０に示した画面に移行する。現在の設定容量はデフォルト表示でチェックされている。例えば，図１０においては，アイコン５０６がチェックされており，この場合は，６ＧＢの容量に設定してあるということになる。
【０１０８】
利用者は，設定容量を変更したい場合には，アイコン５０６〜５２２のうちのいずれか一つを選択すればよい。この際，容量を増加させる場合には，ドライブ全体の残りのハードディスク容量を考慮して，容量不足等で設定できない値のボタンは，グレー表示し，押下できないようになっている。また，容量を減少させる場合には，現在コンテンツ配信システム１００に使用している容量よりも少ない値のボタンは，押下できないようになっている。
【０１０９】
利用者は，設定容量を変更した後に「決定」ボタン（アイコン５２６）を押下すると，設定変更完了画面（図示せず）に移行する。一方，利用者が「戻る」ボタン（アイコン５２８）を押下すると，設定変更の処理は行わずに，直前の画面に戻る。
【０１１０】
（２：コンテンツの購入時等における利用者端末１１０の処理）
次に，図３を参照しながら，利用者端末１１０が上記アプリケーションをダウンロードした後に行う，コンテンツの購入等の申し込み時における処理について詳細に説明する。なお，図３は，利用者端末１１０におけるコンテンツの購入時の処理の概略を示したフローチャートである。
【０１１１】
なお，コンテンツの配信の形式としては，定期購読などの形態で，定期的にコンテンツが自動で配信される形式と，利用者の要求に応じて個別にコンテンツが配信される形式とが考えられるが，ここでは，前者の形式でコンテンツが配信される場合について説明することとする。
【０１１２】
利用者端末１１０は，上記アプリケーションをダウンロードした後，コンテンツ配信サーバ１２０に対し，例えば，コンテンツの購入の申し込みにより，所望のコンテンツの配信を要求することができる。
【０１１３】
利用者端末１１０から購入の申し込みを受けたコンテンツ配信サーバ１２０は，その購入の申し込みに係るコンテンツの容量に関するデータ（容量データ）をメタデータデータベース１２０６から抽出し，抽出した容量データをデータ送信手段１２０８により利用者端末１１０に送信する。利用者端末１１０は，送信された容量データをデータ受信手段１１１０により受信する（Ｓ１０２）。
【０１１４】
次に，利用者端末１１０は，容量判断手段１１１２により，受信した容量データに基づいて，記憶装置１１０４に，少なくとも上記購入に係るコンテンツの総容量に相当する分の空き容量があるか否かを判断する（Ｓ１０４）。この判断は，例えば，購入に係るコンテンツの容量と，記憶装置１１０４の記憶領域の空き容量とを比較することにより行う。すなわち，空き容量が購入に係るコンテンツの容量以上（空き容量≧購入に係るコンテンツの容量）の場合には，空き容量がある（記憶可能）と判断し，空き容量が購入に係るコンテンツの容量より小さい（空き容量＜購入に係るコンテンツの容量）の場合には，空き容量がない（記憶不可能）と判断する。また，例えば，記憶装置１１０４の記憶領域のうち現在使用している領域の容量と購入に係るコンテンツの容量との合計を，記憶装置１１０４の記憶領域の全容量と比較するなど，他の任意の方法により判断してもよい。
【０１１５】
ステップＳ１０４における判断の結果，空き容量があると判断された場合には，利用者端末１１０は，記憶装置１１０４に上記購入に係るコンテンツを記憶するための容量を確保する（Ｓ１０６）。具体的には，本実施形態においては，利用者端末１１０は，上記確保した容量の値を所定の記憶手段により記憶させておく。なお，購入に係るコンテンツを記憶するための容量を確保しておく方法としては，確保した容量の値を記憶しておく方法の他にも，記憶装置１１０４に確保した容量分のデータ量を有するダミデータを記憶させておく方法など様々な方法が考えられる。
【０１１６】
ステップＳ１０６において記憶装置１１０４に容量が確保された場合には，コンテンツ配信サーバ１２０に購入の申し込みが受け付けられた状態で終了し（終了（１）），後述するように，この購入の申し込みに係るコンテンツの自動配信が行われる。
【０１１７】
一方，ステップＳ１０４における判断の結果，空き容量がないと判断された場合には，利用者端末１１０は，アラート通知手段１１１４により，例えば，購入ができない旨のアラート通知を表示装置１１０８にさせる（Ｓ１０８）。この場合に，購入ができない旨の通知と共に，不要なファイルを削除すべき旨，一部のファイルを他の記憶装置（例えば，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭなど）に移動すべき旨，他の記憶領域に転送（例えば，ＨＤＤのＣ：ドライブからＤ：ドライブに転送）すべき旨等を共に表示してもよい。
【０１１８】
次に，このアラート通知を受けて，記憶装置１１０４に空き容量が確保されたか否かの判断が行われる（Ｓ１１０）。この判断は，ステップＳ１０４における場合と同様の方法で行うことができる。
【０１１９】
ステップＳ１１０における判断の結果，例えば，利用者がアラート通知に応じて不要なファイルを削除したこと等により，記憶装置１１０４に空き容量が確保されたと判断された場合には，ステップＳ１０６における場合と同様に，利用者端末１１０は，記憶装置１１０４に上記購入に係るコンテンツを記憶するための容量を確保する（Ｓ１１２）。
【０１２０】
一方，ステップＳ１１０における判断の結果，例えば，利用者がアラート通知に対して何らの処理も行わなかったこと等により，記憶装置１１０４に空き容量が確保されなかったと判断された場合には，コンテンツ配信サーバ１２０に購入の申し込みが受け付けられない状態で終了する（終了（２））。この場合には，終了（１）の場合と異なり，購入の申し込みが受け付けられていないので，この購入の申し込みに係るコンテンツの自動配信は行われない。
【０１２１】
このように，コンテンツの購入の申し込み等の時点で，利用者端末１１０の記憶装置１１０４に，そのコンテンツを記憶するための十分な空き容量があるか否かの判断を行い，さらに，十分な空き容量がない場合には，アラート通知をすることにより，購入等した後に配信されるコンテンツを記憶するための容量を確保しておくことができる。したがって，他のアプリケーションなどで使用したことにより，コンテンツを記憶するための容量がたまたま不足していたため，ダウンロードをすることができなかったという事態を回避することが可能となり，後述するコンテンツの自動配信を円滑に行うことができる。
【０１２２】
（３：コンテンツの自動配信時における利用者端末１１０の処理）
次に，図４を参照しながら，コンテンツの自動配信時において利用者端末１１０で行われる処理について詳細に説明する。なお，図４は，利用者端末１１０におけるコンテンツの自動配信時の処理の概略を示したフローチャートである。
【０１２３】
上述したコンテンツの購入申し込みにおいて，該申し込みが受け付けられた状態で終了した（図３の終了（１））場合には，以下に説明するコンテンツの自動配信が行われる。
【０１２４】
まず，利用者端末１１０のポーリング手段１１１８は，コンテンツ配信サーバ１２０に対し，ポーリングを行う（Ｓ１５２）。利用者端末１１０のＣＰＵ１１０２は，ポーリングの結果，購入に係るコンテンツ，すなわち，これから配信される予定のコンテンツ（以下，単に「配信予定のコンテンツ」という）についてのメタデータ（例えば，コンテンツＩＤ，コンテンツ容量など）が更新されているか否かの判断を行う（Ｓ１５４）。
【０１２５】
ステップＳ１５４における判断の結果，メタデータの更新がされていないと判断された場合には，コンテンツの自動配信処理はいったん終了する（終了（３））。
【０１２６】
一方，ステップＳ１５４における判断の結果，メタデータの更新がされていると判断された場合には，ポーリング手段１１１８は，コンテンツ配信サーバ１２０に更新後のメタデータを送信するように要求し，データ受信手段１１１０は，コンテンツ配信サーバ１２０から更新後のメタデータを受信する（Ｓ１５６）。
【０１２７】
次に，利用者端末１１０の容量判断手段１１１２は，受信された更新後のメタデータに基づいて，少なくとも配信予定のコンテンツの総容量に相当する分の空き容量が記憶装置１１０４に確保されているか否かの判断を行う（Ｓ１５８）。具体的には，受信された更新後のメタデータを読み込み，その更新後のメタデータに含まれるデータ（例えば，コンテンツＩＤ，コンテンツ名，コンテンツの置かれている位置を示すＵＲＬ，コンテンツ容量等）のうち，どのデータが更新（変更）されているか否かを判断する。その判断の結果，少なくとも配信予定のコンテンツの容量が変更されていると判断した場合には，例えば，変更された配信予定のコンテンツの総容量と，記憶装置１１０４の記憶領域の空き容量とを比較することにより行う。すなわち，空き容量が変更された配信予定のコンテンツの総容量以上（空き容量≧配信予定のコンテンツの総容量）の場合には，確保されている（記憶可能）と判断し，空き容量が変更された配信予定のコンテンツの容量より小さい（空き容量＜配信予定のコンテンツの容量）の場合には，確保されていない（記憶不可能）と判断する。また，例えば，記憶装置１１０４の記憶領域のうち現在使用している領域の容量と配信予定のコンテンツの総容量との合計を，記憶装置１１０４の記憶領域の総容量と比較するなど，他の任意の方法により判断してもよい。
【０１２８】
ステップＳ１５８における判断の結果，記憶装置１１０４に配信予定のコンテンツを記憶するための容量が確保されていると判断された場合には，その配信予定のコンテンツのダウンロードが行われる（Ｓ１６０）。そして，コンテンツ受信手段１１１６がダウンロードされたコンテンツを受信することにより，コンテンツの自動配信処理はいったん終了する（終了（４））。
【０１２９】
一方，ステップＳ１５８における判断の結果，記憶装置１１０４に配信予定のコンテンツを記憶するための容量が確保されていないと判断された場合には，アラート通知手段１１１４は，少なくとも記憶装置１１０４の空き容量が不足している旨のアラートを利用者に通知する（Ｓ１６２）。アラートを通知する方法としては，例えば，表示装置１１０８に空き容量が不足している旨の文字を表示することにより行う方法があるが，画像により空き容量が不足している旨を表す方法，音声により通知する方法，あるいはこれらを組み合わせた方法等，任意の方法により通知してもよい。なお，利用者端末１１０が携帯電話機などである場合には，バイブレーション機能を使用してもよい。また，アラートを通知する場合には，空き容量が不足している旨に加えて，不要なファイルを削除すべき旨，一部のファイルを他の記憶装置（例えば，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭなど）に移動すべき旨，他の記憶領域に転送（例えば，ＨＤＤのＣ：ドライブからＤ：ドライブに転送）すべき旨等を共に表示してもよい。さらに，配信予定のコンテンツを記憶するために必要な容量や現在の記憶装置１１０４の空き容量などを共に表示してもよい。
【０１３０】
ここで，アラート通知手段１１１４により，利用者端末１１０の表示装置１１０８にアラートが表示される場合の表示例を図１１に示した。なお，図１１は，本実施形態に係るコンテンツ配信システムにおけるアラート通知の表示例を示す説明図である。
【０１３１】
図１１には，アラート通知の表示例として，記憶装置１１０４の空き容量が不足している旨，不要なファイルを削除すべき旨，配信予定のコンテンツを記憶するために必要な容量，および現在の記憶装置１１０４の空き容量を表示した例を示した。
【０１３２】
また，本実施形態において，上述したようなアラート通知が行われるタイミングとしては，コンテンツ配信システム１００を利用するためのアプリケーション（例えば，配信されたコンテンツを視聴等するためのアプリケーション）が起動していない場合には，アプリケーションの起動時にアラートが通知される。また，上記アプリケーションが起動している場合であって，各種設定（例えば，ハードディスク容量の設定）が行われている場合または配信されたコンテンツが再生等されている場合には，その処理，すなわち，各種設定またはコンテンツの再生等が終了した後に通知される。また，上記アプリケーションが起動している場合であって，各種設定もコンテンツの再生等も行われていない場合には，随時アラートが通知される。ただし，アラートの通知が行われるタイミングは上述したタイミングに限られず，例えば，ＰＣの起動時などにアラートの通知が行われるようにしてもよい。
【０１３３】
再び図４に戻って，コンテンツの自動配信時の利用者端末１１０の処理についての説明を続ける。ステップＳ１６２において上述したようなアラート通知が行われた後に，このアラート通知を受けて，記憶装置１１０４に空き容量が確保されたか否かの判断が行われる（Ｓ１６４）。この判断は，ステップＳ１５８における場合と同様の方法で行うことができる。
【０１３４】
ステップＳ１６４における判断の結果，例えば，利用者がアラート通知に応じて不要なファイルを削除したこと等により，記憶装置１１０４に空き容量が確保されたと判断された場合には，ステップＳ１６０における場合と同様に，配信予定のコンテンツのダウンロードが行われる（Ｓ１６６）。そして，コンテンツ受信手段１１１６がダウンロードされたコンテンツを受信することにより，コンテンツの自動配信処理はいったん終了する（終了（４））。
【０１３５】
一方，ステップＳ１６４における判断の結果，例えば，利用者がアラート通知に対して何らの処理も行わなかったこと等により，記憶装置１１０４に空き容量が確保されなかったと判断された場合には，配信予定のコンテンツのダウンロードは行われない（Ｓ１６８）。そして，配信予定のコンテンツのダウンロードが行われないまま，コンテンツの自動配信処理はいったん終了する（終了（５））。
【０１３６】
このように，コンテンツの自動配信処理は，メタデータの更新がない場合にいったん終了するか（終了（３）），配信予定のコンテンツをダウンロードした場合にいったん終了するか（終了（４）），あるいは記憶装置１１０４の容量が確保されないために配信予定のコンテンツをダウンロードできない場合にいったん終了する（終了（５））。しかし，ステップＳ１５２のポーリングは，定期的に，例えば１時間ごとに行われている。したがって，ステップＳ１５２〜Ｓ１６８の処理は，配信予定のコンテンツが存在しなくなるまで，例えば，配信予定のコンテンツをすべてダウンロードするまで，あるいは配信予定のコンテンツのダウンロードを中止等するまで繰り返される。
【０１３７】
なお，上記ポーリングは，定期的に行う場合に限られず，例えば，コンテンツを新たに購入したとき，コンテンツ配信システム１００を利用するためのアプリケーションを起動したとき，またはＰＣを起動したとき等に行ってもよい。
【０１３８】
また，ステップＳ１５８の判断も，上記ポーリングに応じて，例えば，コンテンツを新たに購入したとき，コンテンツ配信システム１００を利用するためのアプリケーションを起動したとき，またはＰＣを起動したとき等に行ってもよい。
【０１３９】
さらに，ステップＳ１５８の判断は，必ずしもポーリングに応じて行われる必要はなく，ポーリングとは関係なく，独立してステップＳ１５８の判断が行われてもよい。
【０１４０】
ここで，配信予定のコンテンツの容量は一定である場合もある。「容量が一定」とは，例えば，毎月一定の容量のコンテンツが配信される場合，毎月配信されるコンテンツの容量があらかじめ設定されており，設定されたコンテンツの容量が変動しない場合，配信予定のコンテンツの追加や変更等が行われない場合（配信予定のコンテンツに関するメタデータの更新が行われない場合）などをいう。
【０１４１】
このような場合には，例えばコンテンツの購入等のときに，１度配信予定のコンテンツの容量のデータを受信しておけば，その後その容量の値が変動することはないので，ステップＳ１５２においてポーリングをする必要がなくなる。よって，その後のメタデータの更新がされているか否かの判断（Ｓ１５４）や更新後のメタデータの受信（Ｓ１５６）を行う必要もなくなる。
【０１４２】
このように，配信予定のコンテンツの容量が一定である場合には，ステップＳ１５２〜Ｓ１５６は行われず，容量が確保されているか否かの判断（Ｓ１５８）が定期的および／またはアプリケーションやＰＣの起動等のときに行われる。したがって，ステップＳ１５８〜Ｓ１６８の処理が，配信予定のコンテンツが存在しなくなるまで，例えば，配信予定のコンテンツをすべてダウンロードするまで，あるいは配信予定のコンテンツのダウンロードを中止等するまで繰り返される。
【０１４３】
以上説明したように，利用者端末１１０の記憶装置１１０４に，そのコンテンツを記憶するための空き容量があるか否かの判断を行い，さらに，空き容量がない場合には，アラート通知をすることにより，購入等した後に配信されるコンテンツを記憶するための容量を確保しておくことができる。したがって，他のアプリケーションなどで使用したことにより，コンテンツを記憶するための容量がたまたま不足していたため，ダウンロードをすることができなかったという事態を回避することが可能となり，後述するコンテンツの自動配信を円滑に行うことができる。
【０１４４】
特に，利用者が定期的（例えば，毎月）に配信されるコンテンツを購入したような場合については，容量をあらかじめ確保しておく意味は大きい。すなわち，通常は，例えば，６月に配信予定のコンテンツは６月中に，７月に配信予定のコンテンツは７月中に配信されるが，コンテンツ配信サーバ１２０の負担を軽減するために，７月に配信予定のコンテンツの一部を６月中に配信するような場合もある。したがって，利用者端末１１０は，６月に配信予定のコンテンツ（例えば，３ＧＢ）と７月に配信予定のコンテンツの一部（例えば，１．５ＧＢ）の両方を記憶するための領域（例えば，４．５ＧＢ）を確保しておく必要がある。ところが，利用者端末１１０側では，７月に配信予定のコンテンツの分は６月の時点では確保されておらず，６月に配信予定の３ＧＢ分だけ確保してあるのが通常である。そこで，このような場合に，本実施形態に係るコンテンツ配信システム１００によれば，６月分と７月の分の一部を合わせた４．５ＧＢ分を確保するようアラートを通知することができる。これにより，利用者端末１１０は，４，５ＧＢ分を確保しておくことができるため，配信予定のコンテンツのダウンロードを確実に行うことが可能となり，コンテンツの自動配信を円滑に行うことができる。
【０１４５】
なお，本実施形態においては，Ｓ１５８における判断の結果，配信予定のコンテンツを記憶するための空き容量が確保されていないと判断された場合には，配信予定のコンテンツのダウンロードを行う前にアラートが通知されることとしたが，アラートを通知する前に，記憶装置１１０４に記憶できる分だけダウンロードを行い，ダウンロードした容量が記憶装置１１０４の空き容量を超えた時点でアラート通知がされるようにすることも可能である。この場合には，アラート通知により空き容量が確保された後は，アラート通知前のダウンロードの続きを継続できるようにすることが望ましい。そうすることにより，アラート通知前にダウンロードした分が無駄にならないからである。
【０１４６】
ただし，途中までダウンロードした後にアラート通知を行うこととすると，アラート通知によっても空き容量が確保することができなかった場合には，アラート通知前のダウンロードが無駄になる可能性もある。したがって，本実施形態におけるように，ダウンロードが開始される前に空き容量が確保されているか否かの判断を行い（Ｓ１５８），確保されていない場合にはあらかじめアラート通知をすることとすれば，途中までダウンロードした分が無駄になるという事態を回避することができ，より確実に配信予定のコンテンツのダウンロードを行うことができる。
【０１４７】
＜第２の実施形態＞
（コンテンツ配信システム２００の構成）
次に，図５を参照しながら，本発明の第２の実施形態に係るコンテンツ配信システム２００の構成について説明する。なお，図５は，本発明の第２の実施形態に係るコンテンツ配信システム２００の概略的な構成を示すブロック図である。
【０１４８】
図５に示したように，本実施形態に係るコンテンツ配信システム２００においては，主として，利用者端末２１０とコンテンツ配信サーバ２２０とライセンス認証サーバ２３０と課金サーバ２４０とが，例えばインターネットなどのネットワーク２５０を介して接続されている。
【０１４９】
利用者端末２１０は，コンテンツ配信システム２００の提供するコンテンツ配信サービスを利用する利用者の所有する端末であり，コンテンツ配信サーバ２２０から，利用者端末２１０の要求に応じてあるいは自動的に配信される１または複数のコンテンツを受信して，それを出力（表示など）する端末装置である。
【０１５０】
なお，利用者端末２１０としては，デスクトップ型のパーソナルコンピュータ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ：以下，「ＰＣ」とする）やノート型のＰＣ，ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）などが考えられるが，これらには限られず，後述する本実施形態に係る利用者端末２１０の構成を備えていれば，例えば，携帯電話機などであってもよい。
【０１５１】
本実施形態に係る利用者端末２１０は，図６に示したように，ＣＰＵ２１０２と，ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）などの記憶装置２１０４と，入力装置２１０６と，表示装置２１０８と，データ送信手段２１１０と，コンテンツ受信手段２１１２とを備えている。なお，図６は，本実施形態に係る利用者端末２１０の概略的な構成を示したブロック図である。
【０１５２】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２１０２は，利用者端末２１０が行う処理の全般を制御する装置である。記憶装置２１０４は，主に，ＨＤＤなどの記憶装置を想定しているが，配信されるコンテンツを記憶することが可能な記憶媒体であれば，例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭのような外部記憶媒体などでもよい。入力装置２１０６は，コンテンツ配信システム２００の利用者が利用者端末２１０を操作するための装置で，例えば，マウスやキーボードなどのユーザインターフェース（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ：ＵＩ）のことである。表示装置２１０８は，配信されたコンテンツを視聴したり，後述するアラートを表示したりするために用いられる装置（ディスプレイ）である。
【０１５３】
データ送信手段２１１０は，主に，コンテンツ配信サーバ２２０に，利用者端末２１０内の記憶装置２１０４の容量に関するデータを送信するための手段である。ここで，記憶装置２１０４の容量に関するデータとしては，例えば，記憶装置２１０４の空き容量に関するデータや，記憶装置２１０４の全容量のデータと記憶装置２１０４の使用領域の容量のデータとの組み合わせ等が挙げられる。データ送信手段２１１０が記憶装置２１０４の容量に関するデータをコンテンツ配信サーバ２２０に送信することにより，コンテンツ配信サーバ２２０は，配信予定のコンテンツを記憶するための容量が記憶装置２１０４に確保されているか否かを判断することができる。
【０１５４】
コンテンツ受信手段２１１２は，後述するコンテンツ配信サーバ２２０の容量判断手段２２１０が記憶装置２１０４に配信予定のコンテンツを記憶するための容量が確保されていると判断した場合に，配信予定のコンテンツを受信するための手段である。
【０１５５】
次に，コンテンツ配信サーバ２２０の構成について説明する。コンテンツ配信サーバ２２０は，利用者端末２１０に対し，利用者端末２１０の要求に応じてあるいは所定の条件により自動的にコンテンツを配信するサーバ装置である。
【０１５６】
本実施形態に係るコンテンツ配信サーバ２２０は，図６に示したように，ＣＰＵ２２０２と，コンテンツデータベース（ＤＢ）２２０４と，メタデータデータベース（ＤＢ）２２０６と，データ受信手段２２０８と，容量判断手段２２１０と，アラート送信手段２２１２と，コンテンツ配信手段２２１４と，を備えている。
【０１５７】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２２０２は，コンテンツ配信サーバ２２０が行う処理の全般を制御する装置である。
【０１５８】
コンテンツデータベース２２０４には，利用者端末２１０からの要求に応じて利用者端末２１０に例えば有償で提供される複数のコンテンツデータ（例えば，映像コンテンツ）が格納されている。コンテンツ配信システム２００の利用者は，コンテンツデータベース２２０４の格納されたコンテンツデータの中から所望のコンテンツ，例えば，視聴したい映像コンテンツを選択することができる。コンテンツ配信サーバ２２０は，利用者により選択されたコンテンツをコンテンツデータベース２２０４から抽出し，利用者端末２１０に配信することができる。
【０１５９】
なお，コンテンツデータベース２２０４は，本実施形態においては，コンテンツ配信サーバ２２０に備えられているが，コンテンツデータベース２２０４を備える独立のサーバ（図示せず）がコンテンツ配信システム２００に存在していてもよい。
【０１６０】
メタデータデータベース２２０６には，図９に示すように，コンテンツＩＤ，コンテンツ名，コンテンツの属するジャンル，コンテンツが保存されている場所を示すＵＲＬ，容量等のメタデータが格納されている。なお，メタデータについては，上述した第１の実施形態の場合と同様なので，詳しい説明はここでは省略する。
【０１６１】
ここで，メタデータデータベース２２０６は，本実施形態においては，コンテンツ配信サーバ２２０に備えられているが，メタデータデータベース２２０６を備える独立のサーバ（図示せず）がコンテンツ配信システム２００に存在していてもよい。
【０１６２】
データ受信手段２２０８は，主に，利用者端末２１０から送信された利用者端末２１０内の記憶装置２１０４の容量に関するデータを送信するための手段である。ここで，記憶装置２１０４の容量に関するデータとしては，上述したように，例えば，記憶装置２１０４の空き容量に関するデータや，記憶装置２１０４の全容量のデータと記憶装置２１０４の使用領域の容量のデータとの組み合わせ等が挙げられる。
【０１６３】
容量判断手段２２１０は，データ受信手段２２０８により受信された記憶装置２１０４の容量に関するデータに基づいて，記憶装置２１０４の記憶領域に，配信予定のコンテンツを記憶することが可能か否か，すなわち，配信予定のコンテンツを記憶するための容量が確保されているか否かを判断するための手段である。この判断は，例えば，配信予定のコンテンツの容量と，記憶装置２１０４の記憶領域の空き容量とを比較することにより行う。すなわち，空き容量が配信予定のコンテンツの容量以上（空き容量≧配信予定のコンテンツの容量）の場合には，確保されている（記憶可能）と判断し，空き容量が配信予定のコンテンツの容量より小さい（空き容量＜配信予定のコンテンツの容量）の場合には，確保されていない（記憶不可能）と判断する。また，例えば，記憶装置２１０４の記憶領域のうち現在使用している領域の容量と配信予定のコンテンツの容量との合計を，記憶装置２１０４の記憶領域の全容量と比較するなど，他の任意の方法により判断してもよい。
【０１６４】
アラート送信手段２２１２は，容量判断手段２２１０が記憶装置２１０４に配信予定のコンテンツを記憶するための容量が確保されていないと判断した場合に，少なくとも記憶装置２１０４の空き容量が不足している旨のアラートを利用者端末２１０に送信するための手段である。送信されたアラートは，利用者端末２１０において利用者に通知される。アラートを通知する方法としては，例えば，表示装置２１０８に空き容量が不足している旨の文字を表示することにより行う方法があるが，画像により空き容量が不足している旨を表す方法，音声により通知する方法，あるいはこれらを組み合わせた方法等，任意の方法により通知してもよい。なお，利用者端末２１０が携帯電話機などである場合には，バイブレーション機能を使用してもよい。また，アラートを通知する場合には，空き容量が不足している旨に加えて，不要なファイルを削除すべき旨，一部のファイルを他の記憶装置（例えば，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭなど）に移動すべき旨，他の記憶領域に転送（例えば，ＨＤＤのＣ：ドライブからＤ：ドライブに転送）すべき旨等を共に表示してもよい。
【０１６５】
コンテンツ配信手段２２１４は，容量判断手段２２１０が記憶装置２１０４に配信予定のコンテンツを記憶するための容量が確保されていると判断した場合に，利用者端末２１０にそのコンテンツを配信するための手段である。
【０１６６】
また，本実施形態に係るコンテンツ配信サーバ２２０は，メタデータ更新手段２２１６をさらに備えていてもよい。メタデータ更新手段２２１６は，メタデータデータベース２２０６に格納されたメタデータの更新を行うための手段である。なお，メタデータの更新については，上述した第１の実施形態の場合と同様であるので，詳しい説明は省略する。
【０１６７】
メタデータ更新手段２２１６によりメタデータの更新が行われた場合には，容量判断手段２２１０は，更新後のメタデータを読み込み，少なくとも配信予定のコンテンツの容量が変更されていると判断した場合には，変更されたコンテンツの容量に基づいて，記憶装置２１０４に容量が確保されているか否かの判断を行う。
【０１６８】
本実施形態に係るライセンス認証サーバ２３０は，利用者が利用者端末２１０を介して例えば動画コンテンツ等のコンテンツを視聴等するために必要なライセンス登録情報（図示せず）が格納されているサーバ装置である。このライセンス登録情報は，例えば，動画を視聴することが可能な利用者端末が，視聴可能な期間とともに登録されている。そして，ライセンス認証サーバ２３０によるライセンス認証により，利用者は動画像を視聴することができる。
【０１６９】
課金サーバ２４０は，コンテンツの配信料などの課金データに基づいて請求書金額情報を検索した後，これを印刷または電子的に出力するサーバ装置である。また，課金サーバ２４０は，利用者ごとに請求すべき当期間の請求情報を計算してその結果を利用者端末２１０に送信する。
【０１７０】
なお，本実施形態では，コンテンツ配信システム２００を構成する装置として，利用者端末２１０，コンテンツ配信サーバ２２０，ライセンス認証サーバ２３０および課金サーバ２４０を挙げたが，本実施形態の適用のためには，少なくとも利用者端末２１０およびコンテンツ配信サーバ２２０が備わっていれば十分である。
【０１７１】
（コンテンツ配信システム２００における処理のフロー）
次に，本実施形態に係るコンテンツ配信システム２００において，どのようにコンテンツの配信が行われるかについて説明する。
【０１７２】
（１：コンテンツ配信システム２００用のアプリケーションのダウンロード）
まず，コンテンツ配信システム２００を利用しようとする利用者は，ネットワークを介して，コンテンツ配信システム２００を利用するためのアプリケーションのダウンロードを行う。利用者は，上記アプリケーションをダウンロードした後，コンテンツ配信システム２００用に使用するための記憶装置２１０４（ここでは，理解を容易にするため，ハードディスク装置とする）の容量をあらかじめ設定しておくことができる。
【０１７３】
このように，コンテンツ配信システム２００に使用する分の容量をあらかじめ設定しておくことで，購入等した後に配信されるコンテンツを記憶するための容量を確保しておくことができる。したがって，他のアプリケーションなどで使用したことにより，コンテンツを記憶するための容量がたまたま不足していたため，ダウンロードをすることができなかったという事態を回避することが可能となる。
【０１７４】
なお，記憶装置２１０４（例えば，ハードディスク装置）の容量の設定については，第１の実施形態に係る記憶装置１１０４の容量の設定と同様であるので，詳しい説明は省略する（図１０参照）。
【０１７５】
（２：コンテンツの購入時等におけるコンテンツ配信サーバ２２０の処理）
次に，図７を参照しながら，利用者端末２１０が上記アプリケーションをダウンロードした後に行う，コンテンツの購入等の申し込み時におけるコンテンツ配信サーバ２２０の処理について詳細に説明する。なお，図７は，コンテンツ配信サーバ２２０におけるコンテンツの購入時の処理の概略を示したフローチャートである。
【０１７６】
なお，コンテンツの配信の形式としては，定期購読などの形態で，定期的にコンテンツが自動で配信される形式と，利用者の要求に応じて個別にコンテンツが配信される形式とが考えられるが，ここでは，前者の形式でコンテンツが配信される場合について説明することとする。
【０１７７】
利用者端末２１０は，上記アプリケーションをダウンロードした後，コンテンツ配信サーバ２２０に対し，例えば，コンテンツの購入の申し込みにより，所望のコンテンツの配信を要求することができる。
【０１７８】
コンテンツ配信サーバ２２０に対し購入の申し込みをした利用者端末２１０は，記憶装置２１０４の容量に関するデータ，例えば，記憶装置２１０４の空き容量に関するデータ（空き容量データ）をデータ送信手段２１１０によりコンテンツ配信サーバ２２０に送信する。コンテンツ配信サーバ２２０は，送信された空き容量データをデータ受信手段２２０８により受信する（Ｓ２０２）。
【０１７９】
次に，コンテンツ配信サーバ２２０は，容量判断手段２２１０により，受信した空き容量データと，上記購入に係るコンテンツの容量データとに基づいて，利用者端末２１０の記憶装置２１０４に，少なくとも購入に係るコンテンツの総容量に相当する分の空き容量があるか否かを判断する（Ｓ２０４）。この判断は，例えば，購入に係るコンテンツの容量と，記憶装置２１０４の記憶領域の空き容量とを比較することにより行う。すなわち，空き容量が購入に係るコンテンツの容量以上（空き容量≧購入に係るコンテンツの容量）の場合には，空き容量がある（記憶可能）と判断し，空き容量が購入に係るコンテンツの容量より小さい（空き容量＜購入に係るコンテンツの容量）の場合には，空き容量がない（記憶不可能）と判断する。また，コンテンツ配信サーバ２２０は，ステップＳ２０２において，利用者端末２１０から，例えば，記憶装置２１０４の記憶領域のうち現在使用している領域の容量と記憶装置２１０４の記憶領域の全容量に関するデータを受信し，記憶装置２１０４の使用領域の容量と購入に係るコンテンツの容量との合計を，記憶装置２１０４の記憶領域の全容量と比較するなど，他の任意の方法により判断することもできる。
【０１８０】
ステップＳ２０４における判断の結果，空き容量があると判断された場合には，コンテンツ配信サーバ２２０は，記憶装置２１０４に上記購入に係るコンテンツを記憶するための容量を確保する旨の要求を利用者端末２１０に送信する（Ｓ２０６）。具体的には，本実施形態においては，コンテンツ配信サーバ２２０は，利用者端末２１０に，上記確保した容量の値を所定の記憶手段により記憶させておく旨の要求を送信する。なお，購入に係るコンテンツを記憶するための容量を確保しておく方法としては，確保した容量の値を記憶させておく方法の他にも，記憶装置２１０４に確保した容量分のデータ量を有するダミデータを記憶させておく方法など様々な方法が考えられる。
【０１８１】
ステップＳ２０６において記憶装置２１０４に容量が確保された場合には，コンテンツ配信サーバ２２０に購入の申し込みが受け付けられた状態で終了し（終了（１）），後述するように，この購入の申し込みに係るコンテンツの自動配信が行われる。
【０１８２】
一方，ステップＳ２０４における判断の結果，空き容量がないと判断された場合には，コンテンツ配信サーバ２２０は，アラート送信手段２２１２により，例えば，購入ができない旨のアラートを利用者端末２１０に送信する（Ｓ２０８）。送信されたアラートは，例えば，利用者端末２１０の表示装置２１０８に表示されることなどにより，利用者に通知される。この場合に，アラート送信手段２２１２は，購入ができない旨のアラートと共に，不要なファイルを削除すべき旨，一部のファイルを他の記憶装置（例えば，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭなど）に移動すべき旨，他の記憶領域に転送（例えば，ＨＤＤのＣ：ドライブからＤ：ドライブに転送）すべき旨等を共に送信してもよい。
【０１８３】
次に，このアラートの通知を受けて，記憶装置２１０４に空き容量が確保されたか否かの判断が行われる（Ｓ２１０）。この判断は，ステップＳ２０４における場合と同様の方法で行うことができる。
【０１８４】
ステップＳ２１０における判断の結果，例えば，利用者がアラート通知に応じて不要なファイルを削除したこと等により，記憶装置２１０４に空き容量が確保されたと判断された場合には，ステップＳ２０６における場合と同様に，コンテンツ配信サーバ２２０は，記憶装置２１０４に上記購入に係るコンテンツを記憶するための容量を確保する旨の要求を利用者端末２１０に送信する（Ｓ２１２）。
【０１８５】
一方，ステップＳ２１０における判断の結果，例えば，利用者がアラート通知に対して何らの処理も行わなかったこと等により，記憶装置２１０４に空き容量が確保されなかったと判断された場合には，コンテンツ配信サーバ２２０に購入の申し込みが受け付けられない状態で終了する（終了（２））。この場合には，終了（１）の場合と異なり，購入の申し込みが受け付けられていないので，この購入の申し込みに係るコンテンツの自動配信は行われない。
【０１８６】
このように，コンテンツの購入の申し込み等の時点で，利用者端末２１０の記憶装置２１０４に，そのコンテンツを記憶するための十分な空き容量があるか否かの判断を行い，さらに，十分な空き容量がない場合には，アラート通知をすることにより，購入等した後に配信されるコンテンツを記憶するための容量を確保しておくことができる。したがって，他のアプリケーションなどで使用したことにより，コンテンツを記憶するための容量がたまたま不足していたため，ダウンロードをすることができなかったという事態を回避することが可能となり，後述するコンテンツの自動配信を円滑に行うことができる。
【０１８７】
（３：コンテンツの自動配信時におけるコンテンツ配信サーバ２２０の処理）
次に，図８を参照しながら，コンテンツの自動配信時においてコンテンツ配信サーバ２２０で行われる処理について詳細に説明する。なお，図８は，コンテンツ配信サーバ２２０におけるコンテンツの自動配信時の処理の概略を示したフローチャートである。
【０１８８】
上述したコンテンツの購入申し込みにおいて，該申し込みが受け付けられた状態で終了した（図７の終了（１））場合には，以下に説明するコンテンツの自動配信が行われる。
【０１８９】
まず，コンテンツ配信サーバ２２０のＣＰＵ２２０２は，購入に係るコンテンツ，すなわち，これから配信される予定のコンテンツ（以下，単に「配信予定のコンテンツ」という）についてのメタデータ（例えば，コンテンツＩＤ，コンテンツ容量など）がメタデータ更新手段２２１６により更新されているか否かの判断を行う（Ｓ２５２）。
【０１９０】
ステップＳ２５２における判断の結果，メタデータの更新がされていないと判断された場合には，コンテンツの自動配信処理はいったん終了する（終了（３））。
【０１９１】
一方，ステップＳ２５２における判断の結果，メタデータの更新がされていると判断された場合には，コンテンツ配信サーバ２２０は，利用者端末２１０に利用者端末２１０の記憶装置２１０４の容量に関するデータ，例えば，記憶装置２１０４の空き容量に関するデータ（空き容量データ）を送信するように要求し，データ受信手段２２０８は，利用者端末２１０から空き容量データを受信する（Ｓ２５４）。
【０１９２】
次に，コンテンツ配信サーバ２２０の容量判断手段２２１０は，受信された空き容量データと，配信予定のコンテンツの容量データとに基づいて，少なくとも配信予定のコンテンツの総容量に相当する分の空き容量が利用者端末２１０の記憶装置２１０４に確保されているか否かの判断を行う（Ｓ２５６）。具体的には，更新されたメタデータを読み込み，その更新後のメタデータに含まれるデータ（例えば，コンテンツＩＤ，コンテンツ名，コンテンツの置かれている位置を示すＵＲＬ，コンテンツ容量等）のうち，どのデータが更新（変更）されているか否かを判断する。その判断の結果，少なくとも配信予定のコンテンツの容量が変更されていると判断した場合には，例えば，変更された配信予定のコンテンツの総容量と，受信された記憶装置２１０４の記憶領域の空き容量とを比較することにより行う。すなわち，空き容量が変更された配信予定のコンテンツの総容量以上（空き容量≧配信予定のコンテンツの総容量）の場合には，確保されている（記憶可能）と判断し，空き容量が変更された配信予定のコンテンツの容量より小さい（空き容量＜配信予定のコンテンツの容量）の場合には，確保されていない（記憶不可能）と判断する。また，例えば，記憶装置２１０４の記憶領域のうち現在使用している領域の容量と配信予定のコンテンツの総容量との合計を，記憶装置２１０４の記憶領域の総容量と比較するなど，他の任意の方法により判断してもよい。
【０１９３】
ステップＳ２５６における判断の結果，記憶装置２１０４に配信予定のコンテンツを記憶するための容量が確保されていると判断された場合には，その配信予定のコンテンツの配信が行われる（Ｓ２５８）。そして，利用者端末２１０のコンテンツ受信手段２１１２が配信されたコンテンツを受信することにより，コンテンツの自動配信処理はいったん終了する（終了（４））。
【０１９４】
一方，ステップＳ２５６における判断の結果，記憶装置２１０４に配信予定のコンテンツを記憶するための容量が確保されていないと判断された場合には，アラート送信手段２２１２は，少なくとも記憶装置２１０４の空き容量が不足している旨のアラートを利用者端末２１０に送信する（Ｓ２６０）。送信されたアラートは，所定の通知手段により，利用者に通知される。アラートを通知する方法としては，例えば，表示装置２１０８に空き容量が不足している旨の文字を表示することにより行う方法があるが，画像により空き容量が不足している旨を表す方法，音声により通知する方法，あるいはこれらを組み合わせた方法等，任意の方法により通知してもよい。なお，利用者端末２１０が携帯電話機などである場合には，バイブレーション機能を使用してもよい。また，アラートを通知する場合には，空き容量が不足している旨に加えて，不要なファイルを削除すべき旨，一部のファイルを他の記憶装置（例えば，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭなど）に移動すべき旨，他の記憶領域に転送（例えば，ＨＤＤのＣ：ドライブからＤ：ドライブに転送）すべき旨等を共に表示してもよい。さらに，配信予定のコンテンツを記憶するために必要な容量や現在の記憶装置２１０４の空き容量などを共に表示してもよい。
【０１９５】
なお，アラート通知手段２１１２により利用者端末２１０の表示装置２１０８にアラートが表示される場合の表示例については，第１の実施形態の場合と同様であるので，説明を省略する（図１１参照）。
【０１９６】
また，本実施形態において，上述したようなアラート通知が行われるタイミングとしては，コンテンツ配信システム２００を利用するためのアプリケーション（例えば，配信されたコンテンツを視聴等するためのアプリケーション）が起動していない場合には，アプリケーションの起動時にアラートが通知される。また，上記アプリケーションが起動している場合であって，各種設定（例えば，ハードディスク容量の設定）が行われている場合または配信されたコンテンツが再生等されている場合には，その処理，すなわち，各種設定またはコンテンツの再生等が終了した後に通知される。また，上記アプリケーションが起動している場合であって，各種設定もコンテンツの再生等も行われていない場合には，随時アラートが通知される。ただし，アラートの通知が行われるタイミングは上述したタイミングに限られず，例えば，ＰＣの起動時などにアラートの通知が行われるようにしてもよい。
【０１９７】
次に，ステップＳ２６０において上述したようなアラートが送信され，利用者端末２１０において通知が行われた後に，このアラート通知を受けて，記憶装置２１０４に空き容量が確保されたか否かの判断が行われる（Ｓ２６２）。この判断は，ステップＳ２５６における場合と同様の方法で行うことができる。
【０１９８】
ステップＳ２６２における判断の結果，例えば，利用者がアラート通知に応じて不要なファイルを削除したこと等により，記憶装置２１０４に空き容量が確保されたと判断された場合には，ステップＳ２５８における場合と同様に，配信予定のコンテンツの配信が行われる（Ｓ２６４）。そして，利用者端末２１０のコンテンツ受信手段２１１２が配信されたコンテンツを受信することにより，コンテンツの自動配信処理はいったん終了する（終了（４））。
【０１９９】
一方，ステップＳ２６２における判断の結果，例えば，利用者がアラート通知に対して何らの処理も行わなかったこと等により，記憶装置２１０４に空き容量が確保されなかったと判断された場合には，配信予定のコンテンツの配信は行われない（Ｓ２６６）。そして，配信予定のコンテンツの配信が行われないまま，コンテンツの自動配信処理はいったん終了する（終了（５））。
【０２００】
このように，コンテンツの自動配信処理は，メタデータの更新がない場合にいったん終了するか（終了（３）），配信予定のコンテンツを配信した場合にいったん終了するか（終了（４）），あるいは記憶装置２１０４の容量が確保されないために配信予定のコンテンツを配信しない場合にいったん終了する（終了（５））。しかし，ステップＳ２５２におけるメタデータの更新があるか否かの判断は，定期的に，例えば１時間ごとに行われている。したがって，ステップＳ２５２〜Ｓ２６６の処理は，配信予定のコンテンツが存在しなくなるまで，例えば，配信予定のコンテンツをすべて配信するまで，あるいは配信予定のコンテンツの配信を利用者端末２１０の要求により中止等するまで繰り返される。
【０２０１】
なお，上記ステップＳ２５２の判断は，定期的に行う場合に限られず，例えば，利用者がコンテンツを新たに購入したとき，利用者端末２１０がコンテンツ配信システム２００を利用するためのアプリケーションを起動したとき，または利用者端末２１０がＰＣを起動したとき等に行ってもよい。
【０２０２】
また，ステップＳ２５６の判断も，上記ステップＳ２５２の判断に応じて，例えば，利用者がコンテンツを新たに購入したとき，利用者端末２１０がコンテンツ配信システム２００を利用するためのアプリケーションを起動したとき，または利用者端末２１０がＰＣを起動したとき等に行ってもよい。
【０２０３】
以上説明したように，利用者端末２１０の記憶装置２１０４に，そのコンテンツを記憶するための空き容量があるか否かの判断を行い，さらに，空き容量がない場合には，アラート通知をすることにより，購入等した後に配信されるコンテンツを記憶するための容量を確保しておくことができる。したがって，他のアプリケーションなどで使用したことにより，コンテンツを記憶するための容量がたまたま不足していたため，ダウンロードをすることができなかったという事態を回避することが可能となり，後述するコンテンツの自動配信を円滑に行うことができる。
【０２０４】
特に，利用者が定期的（例えば，毎月）に配信されるコンテンツを購入したような場合については，容量をあらかじめ確保しておく意味は大きい。すなわち，通常は，例えば，６月に配信予定のコンテンツは６月中に，７月に配信予定のコンテンツは７月中に配信されるが，コンテンツ配信サーバ２２０の負担を軽減するために，７月に配信予定のコンテンツの一部を６月中に配信するような場合もある。したがって，利用者端末２１０は，６月に配信予定のコンテンツ（例えば，３ＧＢ）と７月に配信予定のコンテンツの一部（例えば，１．５ＧＢ）の両方を記憶するための領域（例えば，４．５ＧＢ）を確保しておく必要がある。ところが，利用者端末２１０側では，７月に配信予定のコンテンツの分は６月の時点では確保されておらず，６月に配信予定の３ＧＢ分だけ確保してあるのが通常である。そこで，このような場合に，本実施形態に係るコンテンツ配信システム２００によれば，６月分と７月の分の一部を合わせた４．５ＧＢ分を確保するようアラートを通知することができる。これにより，利用者端末２１０は，４，５ＧＢ分を確保しておくことができるため，配信予定のコンテンツのダウンロードを確実に行うことが可能となり，コンテンツの自動配信を円滑に行うことができる。
【０２０５】
なお，本実施形態においては，Ｓ２５６における判断の結果，配信予定のコンテンツを記憶するための空き容量が確保されていないと判断された場合には，配信予定のコンテンツの配信を行う前にアラートが送信されることとしたが，アラートを送信する前に，記憶装置２１０４に記憶できる分だけ配信を行い，配信した容量が記憶装置２１０４の空き容量を超えた時点でアラートが送信されるようにすることも可能である。この場合には，アラートの送信（および利用者端末２１０による送信されたアラートの通知）により空き容量が確保された後は，アラート送信前の配信の続きを継続できるようにすることが望ましい。そうすることにより，アラート送信前に配信した分が無駄にならないからである。
【０２０６】
ただし，途中まで配信した後にアラートの送信を行うこととすると，アラート送信（および送信されたアラートの通知）によっても空き容量が確保することができなかった場合には，アラート送信前の配信が無駄になる可能性もある。したがって，本実施形態におけるように，配信が開始される前に空き容量が確保されているか否かの判断を行い（Ｓ２５６），確保されていない場合にはあらかじめアラートを送信することとすれば，途中まで配信した分が無駄になるという事態を回避することができ，より確実に配信予定のコンテンツの配信を行うことができる。
【０２０７】
以上，添付図面を参照しながら本発明の好適な実施形態について説明したが，本発明は係る例に限定されないことは言うまでもない。当業者であれば，特許請求の範囲に記載された範疇内において，各種の変更例または修正例に想到し得ることは明らかであり，それらについても当然に本発明の技術的範囲に属するものと了解される。
【０２０８】
例えば，上述した実施形態においては，記憶装置の空き容量の確保されているか否かの判断やアラートの通知は，コンテンツが自動配信（自動ダウンロード）される場合について主に説明したが，自動の場合だけでなく，利用者がコンテンツを手動でダウンロードするような場合にも，本発明を適用することができる。
【産業上の利用可能性】
【０２０９】
本発明は，コンテンツ配信システム，利用者端末，コンテンツ配信サーバおよびコンピュータプログラムに利用可能であり，特に，コンテンツの配信が自動的に行われるコンテンツ配信システム，利用者端末，コンテンツ配信サーバおよびコンピュータプログラムに利用可能である。
【図面の簡単な説明】
【０２１０】
【図１】本発明の第１の実施形態に係るコンテンツ配信システム１００の概略的な構成を示すブロック図である。
【図２】本発明の第１の実施形態に係る利用者端末１１０の概略的な構成を示すブロック図である。
【図３】本発明の第１の実施形態に係る利用者端末１１０におけるコンテンツの購入時の処理の概略を示すフローチャートである。
【図４】本発明の第１の実施形態に係る利用者端末１１０における自動ダウンロード時の処理の概略を示すフローチャートである。
【図５】本発明の第２の実施形態に係るコンテンツ配信システム２００の概略的な構成を示すブロック図である。
【図６】本発明の第２の実施形態に係るコンテンツ配信サーバ２２０の概略的な構成を示すブロック図である。
【図７】本発明の第２の実施形態に係るコンテンツ配信サーバ２２０におけるコンテンツの購入時の処理の概略を示すフローチャートである。
【図８】本発明の第２の実施形態に係るコンテンツ配信サーバ２２０における自動ダウンロード時の処理の概略を示すフローチャートである。
【図９】本発明の実施形態に係るコンテンツのメタデータのデータ構造の例を示す説明図である。
【図１０】本発明の実施形態に係るコンテンツ配信システムにおける設定変更画面の表示例を示す説明図である。
【図１１】本発明の実施形態に係るコンテンツ配信システムにおけるアラート通知の表示例を示す説明図である。
【符号の説明】
【０２１１】
１００，２００      コンテンツ配信システム
１１０，２１０      利用者端末
１２０，２２０      コンテンツ配信サーバ
１３０，２３０      ライセンス認証サーバ
１４０，２４０      課金サーバ
１１０４      記憶装置（ＨＤＤ）
１１１２，２２１０      容量判断手段
１１１４      アラート通知手段
２２１２      アラート送信手段
１２１０，２２１４      コンテンツ配信手段
１１１６，２１１２      コンテンツ受信手段
【図１】
2006053633.tif 000003
【図２】
2006053633.tif 000004
【図３】
2006053633.tif 000005
【図４】
2006053633.tif 000006
【図５】
2006053633.tif 000007
【図６】
2006053633.tif 000008
【図７】
2006053633.tif 000009
【図８】
2006053633.tif 000010
【図９】
2006053633.tif 000011
【図１０】
2006053633.tif 000012
【図１１】
2006053633.tif 000013