コンテンツのダウンロードを制御するダウンロード制御装置であって、ダウンロードされるコンテンツの識別情報を含むダウンロード制御データを記録する制御データ記録部と、前記制御データ記録部に記録されているダウンロード制御データの更新を確認する更新確認部と、前記更新確認部による確認のタイミングを設定する確認タイミング設定部とを有するダウンロード制御装置。ブロードバンドインターネットサービスの普及に伴い、映像、写真、音楽、マルチメディアデータ、アプリケーションプログラムといったコンテンツをインターネットで配信するサービスが注目を集めている。これらの様々なコンテンツを購入してダウンロードするとき、PC等の情報処理装置でインターネットプラウザを利用し、HTMLコンテンツからリンクされたコンテンツを、ユーザが操作デバイスを使用して指示することで、購入やダウンロードの操作を行う。このとき、コンテンツのダウンロードの利便性を向上するため、多数のコンテンツを一括してダウンロードしたり、定期的に配信されるコンテンツを逐次ダウンロードできたり、新しいバージョンのコンテンツが配信されたら、ダウンロード済みのコンテンツを更新できる機能を提供することが望ましい。このようなダウンロード機能を提供するために、規格化されたダウンロード制御情報として、上記特許文献1にも記載のあるRSSRDFSiteSummaryと呼ばれるXML形式のタグ言語が利用されることがある。一つのRSSファイルの中には、RSSファイル自体の名称やインターネット上の所在URLが記載され、複数のitemと呼ばれるコンテンツのダウンロードに必要な情報が記載される。具体的には、ダウンロードするコンテンツの名称、データ種別、サイズ、ダウンロード先URL、配信日時などの情報が記載される。RSSファイルは、例えばWebサーバ上に置かれる。情報処理装置は、HTMLコンテンツからリンクされたRSSファイルを、ユーザ操作により指示して読み込むことにより、RSSファイルに記載されたコンテンツのダウンロードを、メタファイルの記述に従って行う。しかし、特許文献1やこのようなダウンローダアプリケーションにおいて、従来のRSSによるダウンロード制御では次のような問題がある。まず、RSSのメタファイルの配信日時情報に従うと、そのメタファイルに従った情報処理装置が一斉にダウンロードを開始することになってしまい、サーバに一時的にトラフィックが集中して、システムダウン等の障害を発生するおそれがある。特に家庭の映像をダウンロードする民生機器テレビやレコーダ等が情報処理装置である場合には、コンテンツが映像であるため大容量であり、民生用であるため数も多数のためおそれが特に懸念される。また、RSSファイルでは、情報処理装置は、周期的にWebサーバ上のRSSファイルが更新されていないかをチェックすることとなってしまう。コンテンツによっては更新が不要なものや、ある時期まで更新されるがある時期以降は更新されないものもある。こういったコンテンツに対して、情報処理装置では今後の更新の有無を知ることができない。このため、情報処理装置を使用するユーザは、サービス提供者からの情報等から自分で判断して、不要になったRSSファイルの監視対象から削除することになり、ユーザの手間及び/又はネットワークのトラフィックの無駄となってしまう。そこで例えば、ダウンロード制御情報の定期的な更新チェック時期を分散させることにより、サーバへのダウンロード要求を分散させる。また、ダウンロード制御情報に、そのダウンロード制御情報が、更新管理をするかどうかを示す情報、及び/又は、更新管理する場合の更新期限の日時情報を設け、情報処理装置がこれらの情報に基づいてダウンロード処理が完了した際のダウンロード制御情報の消去処理を行う。上記手段によれば例えば、トラフィックの集中を避けることができる。また、単発で1回きりに配信されるコンテンツや、不定期または定期的に配信される一連のコンテンツのそれぞれに対し、適切な更新処理を行うことができる。本発明に好適な実施形態の例実施例を、図面を引用しつつ説明する。ただし本発明は本実施例に限定されるものではない。図1は、情報処理装置400と、関係するシステムとの関係を示す。情報処理装置400においては、CPU420が、メモリ430やHDD450に格納されたプログラムを実行することで、各種の処理を行う。情報処理装置400は、例えばネットワークに接続して記録機能を有するテレビ、レコーダ、パーソナルコンピュータ等である。情報処理装置400は、リアルタイムクロックRTC460を持ち、常に実時間を保持し、上記プログラムから参照することができ、設定された日時にCPU420にプログラムを実行させるタイマー機能を持っている。また、ハードディスクインタフェースHDDIF440を介して、ハードディスクドライブHDDが接続されており、上記プログラムは、大容量のデータの読み書き処理を行うことができる。また、ネットワークインタフェースLANIF410を介し、ルータゲートウェイ等であってもよい。総称して中継装置ともいう310に接続され、インターネット300に接続される。インターネットを介してアクセスするサーバには、Webサーバ100とファイルサーバ200がある。Webサーバ100は、情報処理装置400が持つWebブラウザ機能で表示を行うために参照するWebページ110と、情報処理装置400が様々なコンテンツをダウンロードするのに必要な制御情報を記述したダウンロード制御メタファイル120を保持する。情報処理装置400のようなハードウェア構成も備えており、例えばCPUが、メモリやHDDに格納されたプログラムを実行することで、各種の処理を行う。ファイルサーバ200には、ダウンロードするコンテンツ210のデータ本体が置かれる。情報処理装置400のようなハードウェア構成も備えており、例えばCPUが、メモリやHDDに格納されたプログラムを実行することで、各種の処理を行う。情報処理装置400からファイルサーバ200に、コンテンツの取得要求されると、インターネットを介してコンテンツのデータが配信され、それをHDDIF440を介して、HDDに記録することでダウンロードが完了する。より詳細な運用例としては例えば、まずサービスプロバイダで情報処理装置400又はユーザのIDの認証が実行された後にWebサーバ100でHTMLのWebページを取得する。そのWebページを用いてパッケージコンテンツの購入処理を実行するとパッケージコンテンツのIDと情報処理装置又はユーザのIDを顧客管理の課金サーバに送って課金する。課金が完了すると、ダウンロード制御メタファイルをWebサーバ100から情報処理装置400にダウンロードする。このダウンロード制御メタファイルに従って、ファイルサーバ200からパッケージコンテンツをダウンロードする。ダウンロードしたパッケージコンテンツを再生するときには、再生制御メタファイルやDRMの鍵データやコンテンツメタデータを必要に応じて取得する。なお、情報処理装置400とサーバ100及び200のようにダウンロードを制御する装置を総称して、ダウンロード制御装置とも呼ぶ。図2は、ダウンロード制御メタファイル120の構成例を示す。ダウンロード制御メタファイル120は、メタファイル自身の内容を記述したダウンロード制御情報130と、一つまたは複数のコンテンツをダウンロードするのに用いるダウンロード実行情報140を含む。このダウンロード制御メタファイル120は、例えばWebサーバ100でダウンロード制御情報130やダウンロード実行情報140、さらにそれらの詳細に図2に示す各種データを含めて生成される。この生成する部位例えばWebサーバ100のCPUでプログラムを実行する部位をダウンロード制御メタファイル生成部ともいう。このダウンロード制御メタファイル120は、例えばRSSで記述される。ダウンロード制御またファイルは、或るパッケージ内の任意の複数コンテンツに対し作成用意可能であるが、複数のパッケージは跨がない。また、或るパッケージに対して複数用意することも可能である。ただし、必ずパッケージ内の全コンテンツがダウンロードできるように用意する。ダウンロード制御メタファイル120は更新されることがあり、受信機は一定周期でチェックし、差分を更新する。なお、RSSの場合にはenclosureurlで各コンテンツを識別する。ダウンロード制御情報130には、対応するダウンロード制御メタファイル120の名称例えばダウンロード予約の名称、ファイル名、ID等を示すダウンロード制御メタファイルの名称131、対応するダウンロード制御メタファイル120の所在例えば、ダウンロード予約を提供するウェブサイトのインターネット上のURL。URLに限らないアドレスであってもよい、以下所在について同様。を示すダウンロード制御メタファイルの所在132、対応するダウンロード制御メタファイル120の説明例えばダウンロード予約についての説明や言語タイプ等を示すダウンロード制御メタファイルの説明文133、更新チェックフラグ134、更新期限日時135などの情報を持つ。更新チェックフラグ134は、Webサーバ100上のダウンロード制御メタファイル120の内容が変更されていないか、周期的にチェックを行うかどうかを判別するフラグであり、チェックを行う更新と、最初に取得した後は、周期的にチェックを行わない単発の値をとる。更新期限日時135は、更新チェックフラグ134が更新の場合に有効で、ダウンロード制御メタファイル120の更新をチェックし続ける期限の日時を記載する。更新期限日時135は、コンテンツの更新を監視する期限を示す。期限の単位日単位、時単位、分単位等は任意である。期限なしすなわち半永久的にチェックをし続けることを示す値をとることも可能である。また、別の実施例として、更新期限日時135の特殊な値例えば全て0を更新チェックフラグ134の単発を示す値として扱うことにより、更新チェックフラグ134を省略する構成も実現可能である。ダウンロード実行情報140は、ダウンロード制御メタファイル120に複数記述可能である。ダウンロードする各々のコンテンツについて、そのコンテンツのタイトル番組名等であってもよいし、ファイル名やIDであってもよいを示す配信コンテンツのタイトル141、そのコンテンツの説明特徴や備考等を示す配信コンテンツの説明文142、そのコンテンツを配信する日時日単位、分単位であっても良いを示す配信日時143、そのコンテンツの所在を示す配信コンテンツの所在144、配信コンテンツの種別145、そのコンテンツに対応するメタファイルの所在を示す配信コンテンツ用メタファイルの所在146、配信コンテンツのサイズ147などの情報を格納する。配信日時143は、通常、コンテンツがファイルサーバ200に格納され、公開された日時を記載するが、ダウンロード制御メタファイル120が配信されたときには、コンテンツがまだ公開されず、配信日時143には配信予定の未来の日時が記載される場合もある。また、一度、配信されたコンテンツの内容が更新された場合、配信日時143には、更新された日時を記載する。配信コンテンツのファイル種別145は、例えばサーバから配信される映像、写真、音楽、プログラム、マルチメディアデータなどの種別を記載する。映像の中で更に細分化して、映画、ニュース、スポーツ等、音楽の中で更に細分化してクラシック、ロック、ジャズ等の種別を記載してもよい。配信コンテンツ用メタファイルとは、コンテンツの再生や実行に必要な付属情報のことで、一例としてはコンテンツ検索用のジャンルやキーワード情報、コンテンツが映像情報であれば、そのサムネイルやチャプタ情報などがある。なお、ダウンロード制御メタファイル120、ダウンロード制御情報130、ダウンロード実行情報140の全部又は一部をダウンロード制御データとも呼ぶ。図3は、ダウンロード制御メタファイル120を、情報処理装置400が取得する手順の例を示す。情報処理装置400で実行されるWebブラウザ500のプログラム以下、単にWebブラウザ500ともいうは、Webサーバ100に対し、Webページの取得要求を行い、取得したWebページを表示する。図3では、まずWebページa111例えばパック、映画、番組、楽曲等のコンテンツのタイトルを表示する画面データや、HTMLを含むを表示し、このコンテンツをユーザがリモコン等の操作デバイスで操作し、購入するのボタンを選択すると、Webページa111において、購入するボタンにリンク記述されたWebページb112を取得し、表示する。図3の例では、Webページa111として、パックのタイトル柏FC’06パックと、金額3000円と、メッセージ柏FCの06年度全試合をご覧いただけますと、視聴やコピーの条件期限なしコピー3回と、ボタン購入する戻るとを表示する画面を示している。また、Webページb112として、番組のタイトル柏FC’06パックと、このパックのうちダウンロードするコンテンツを選択するボタン例えば全部を選択するとパックに含まれる全てのコンテンツがダウンロードされ、6月を選択すると6月分のコンテンツがダウンロードされるを標示する画面を示している。このWebページにおいて、一つ一つのダウンロードボタンに対して、それぞれダウンロードするコンテンツについて記述したダウンロード制御メタファイル120が用意され、リンクされている。柏FC’06パックを選ぶと例えば、柏FC’06パックを名称131として含むダウンロード制御情報130と、06年の柏FCの全試合のそれぞれに対応するダウンロード実行情報140試合数が50試合なら、ダウンロード実行情報140も50個とが含まれたダウンロード制御メタファイル120を取得する。また、3月を選択すると例えば、柏FC’06パック3月を名称131として含むダウンロード制御情報130と、06年3月の柏FCの全試合のそれぞれに対応するダウンロード実行情報140試合数が5試合なら、ダウンロード実行情報140も5個とが含まれたダウンロード制御メタファイル120を取得するWebサーバ100は送信し、情報処理装置400は受信する。このWebページb112において、ユーザがダウンロードボタンを選択すると、Webブラウザ500は、ダウンロードボタンにリンク記述されたダウンロード制御メタファイル120を、Webサーバ100に取得要求する。Webブラウザ500は、ダウンロード制御メタファイル120を取得すると、そのデータをダウンローダ550情報処理装置400で実行されるダウンローダ550のプログラムに渡す。ダウンローダ550は、渡されたダウンロード制御メタファイル120の内容を解析し560、その中に記載されたダウンロード予約情報130を図4で説明するダウンロード予約管理テーブル850に登録し570、対応するダウンロード実行情報140を図4で説明するダウンロード実行管理テーブル870に登録する580。その後、図7で後述するダウンロード実行順序決定処理1300を実行する590。図4は、ダウンローダ550が管理するデータベースの構成例を示す。ダウンローダ管理情報800は、ダウンローダ550が、ダウンロード制御メタファイル120の更新をチェックするタイミングを管理する情報である。チェック周期情報810は例えばユーザが設定する所定のチェック周期時間である。前回チェック日時820は、周期的にチェックする際、前回チェックを行った日時情報である。次回チェック予定日時830は、前回チェック日時820に、チェック周期情報810を加算して求めた日時であり、この値をRTC460のタイマーに設定することで、次回チェック予定日時830にダウンロード制御メタファイル120の更新をチェックすることができる。ダウンロード予約管理テーブル850は、図3のWebページb112で指示したダウンロード制御メタファイル120に対応するダウンロード予約を管理するテーブルである。ダウンロード予約の名称851、ダウンロード予約の所在852、ダウンロード予約の説明文853、更新チェックフラグ854、更新期限日時855にはそれぞれ、インポートされた図2のダウンロード制御情報130のダウンロード制御メタファイルの名称131、ダウンロード制御メタファイルの所在132、ダウンロード制御メタファイルの説明文133、更新チェックフラグ134、更新期限日時135を格納する。ダウンロード実行管理テーブル870は、各々のコンテンツについて、ダウンロードの実行状況を管理するテーブルである。配信コンテンツのタイトル871、配信コンテンツの説明文872、配信日時873、配信コンテンツの所在874、配信コンテンツの種別875、配信コンテンツ用メタファイルの所在876、配信コンテンツのサイズ877にはそれぞれ、インポートされた図2のダウンロード制御メタファイル120のダウンロード実行情報140の配信コンテンツのタイトル141、配信コンテンツの説明文142、配信日時143、配信コンテンツの所在144、配信コンテンツの種別145、配信コンテンツ用メタファイルの所在146、配信コンテンツのサイズ147を格納する。ダウンロード実行状態878は、未実行ダウンロード中ダウンロード済中断状態などの値を持ち、ダウンローダ550が、ダウンロードの実行状態を管理するために利用する。ダウンロード進捗情報879は、ダウンロードの進捗度合いを管理するために利用するための情報で、例としてダウンロードが済んだコンテンツのサイズを逐次格納する。この場合、配信コンテンツのサイズ877との比を求めることで、ダウンロードの進捗度合いをユーザに例えばで表示することができる。このとき、ダウンロード実行状態878が未実行の場合、ダウンロード進捗情報879の値は0であり、ダウンロード済の場合は、ダウンロード進捗情報879の値=配信コンテンツのサイズ877に設定するものとする。このダウンロード実行管理テーブル870は、ダウンロードの管理が可能なコンテンツ数M個用意される。ダウンロード予約管理テーブル850のダウンロード実行管理テーブルポインタ1856からN857には、ダウンロード実行管理テーブル870の所在HDD450内でのアドレスまたはメモリ430のアドレス等を格納する。Nは、インポート可能なダウンロード実行情報140の数であり、システム設計により異なる。ダウンロード実行順序テーブル900は、ダウンローダ550が、ダウンロードを実行する優先度を管理するテーブルである。ダウンロード実行管理テーブル870へのM個のポインタ910の配列を含む。配列は、例えば実行順とする。実行順は、ダウンロード実行順序決定処理1300で決定される。このように、ダウンロード制御メタファイルを記録する部位例えばHDDやメモリをダウンロード制御メタファイル記録部ともいう。図5は、ダウンローダ550による処理例を示す。情報処理装置400で行われるのが、図5のシステム初期設定処理600である。ここで、まず、ユーザからリモコン等でダウンロード制御メタファイルのチェック周期の入力を受ける610。例えば、1日おき、1時間おき、といった情報を入力させる。入力されたチェック周期時間を、チェック周期時間810のフィールドに設定する620。次に、情報処理装置400一台一台が異なる値を発生させるような乱数を発生させ630、その値を元に、初回のダウンロード制御メタファイルをチェックする基準日時を生成する640。ユーザの設定を受けずともチェック周期が固定又はユーザにより可変に初期設定されていてもよい。生成した日時情報は、次回チェック予定日時830に格納し650、RTC460に次回チェック予定日時830の時刻のタイマー割込み発生要求を設定する660。660でタイマー割込み発生要求が設定された後に実行されるのが、タイマー割込処理700である。660でタイマーが設定された時刻になると、図5のタイマー割込処理700を実行する。タイマー割込み処理700は、次回チェック予定日時830の値を前回チェック日時820にコピーし720、ダウンロード更新処理1100を実行する730。その後、次回チェック予定日時830に、前回チェック日時820にチェック周期時間810を加算した値を格納し740、RTC460に、次回チェック予定日時830の時刻のタイマー割込み発生要求を設定する750。これにより、チェック周期時間810に従い、タイマー割込処理700が行われるため、例えばユーザが指定した一定周期でダウンロード制御メタファイル120の更新をチェックすることができる。このように更新の確認のタイミングを設定する部位例えばCPUのうちプログラムで実行される部位を確認タイミング設定部ともいう。図6は、図5の730で実行されるダウンロード更新処理1100の詳細例を示す。ダウンロード更新処理1100は、ダウンロード予約管理テーブル850の先頭レコードから順に1110、更新チェックフラグ854の値が更新かどうかをチェックし1120、更新なら次に更新期限日時855が、現在より過去の値、すなわち期限切れになっていないかどうかをチェックする1130。期限切れでなければ、ダウンロード予約の所在852が示すURLにアクセスし、ダウンロード制御メタファイル120が更新されているかどうかをチェックし1140、サーバ上のダウンロード制御メタファイル120が更新されていれば1150、新しいダウンロード制御メタファイル120をダウンロードし、対応するダウンロード予約管理テーブル850およびダウンロード実行管理テーブル870の相違をチェックする。チェックした結果、ダウンロード実行管理テーブルポインタ1~Nの参照先のダウンロード実行管理テーブル870について、ダウンロード実行情報140から削除されたがないかチェックし1170、もしあれば、該当するダウンロード実行管理テーブル870のレコードを削除する1180。次に、ダウンロード実行管理テーブルポインタ1~Nの参照先のダウンロード実行管理テーブル870について、既存のダウンロード実行管理テーブル870にない、ダウンロード実行情報140が追加されていないかチェックし1190、もしあれば、該当するダウンロード実行管理テーブル870のレコードを追加する1200。さらに、ダウンロード実行管理テーブルポインタ1~Nの参照先のダウンロード実行管理テーブル870について、新しいダウンロード実行情報140で情報が更新されているかどうかをチェックし1210、もし更新されている部分があれば、該当するダウンロード実行管理テーブル870のフィールドの値を修正する1220。こうして、すべてのダウンロード実行管理テーブル870をチェックし終えるまでボックス1120からの処理を繰り返す1230。以上の処理により、一定周期で、サーバに対してダウンロード制御メタファイルの更新をチェックし、変更された部分を、ダウンローダのデータベースに反映させることができる。このように、ダウンロード制御メタファイルの更新を確認する部位例えばCPUのうちプログラムで実行される部位を更新確認部ともいう。最後に、ダウンロード実行順序決定処理1300を実行し、ダウンロードの実行順序を決定し直す1240。図7は、図3の590で実行されるダウンロード実行順序決定処理1300の詳細例を示す。まず、ダウンロード管理テーブル870のうち、配信日時873が未来のもの、すなわち、まだ配信されておらず、ダウンロードを予約している状態のものや、ダウンロード実行状態878がダウンロード済のものなどを、実行対象外として実行順序決定の対象外とする1310。残った実行対象のダウンロード実行管理テーブル870について、所定のアルゴリズムに従い、ダウンロード実行順序を決定し1320、決定した実行順序に従い、ダウンロード実行順序テーブル900のダウンロード実行管理テーブルポインタ910に、ダウンロード実行管理テーブル870へのポインタ値を優先度順に格納する1330。1320の所定のアルゴリズムについては、ダウンロードサービスの形態やユーザの望む性能、機能によって、実装する方式が変わってくるが、一例としては、次のa~fのようなアルゴリズムが考えられる。aダウンロード制御メタファイル120がインポートされた順に、同じダウンロード制御メタファイル120内では、ダウンロード実行情報140が記述された順に、コンテンツをダウンロードする。b配信コンテンツのサイズ877が小さいものを優先する。c更新周期が短いのダウンロード制御メタファイル120に属するコンテンツを優先する。d複数のコンテンツのダウンロードが並行して実行できる情報処理装置の場合、数個のコンテンツを同時並行でダウンロードする。edの数個のコンテンツを同時並行でダウンロードする場合、それぞれ別々のドメインのサーバに置かれたダウンロードを優先する。fユーザが、情報処理装置のユーザインタフェースを介して、明示的にダウンロードの実行順を指定し、それに従いダウンロードを行う。図8は、図7のダウンロード実行順序決定処理1300によって設定されたダウンロード実行順序テーブル900に従い、実際のダウンロード処理を行うダウンローダ実行処理1000の処理例を示す。まず、ダウンロード実行順序テーブル900のダウンロード実行管理テーブルポイタ910が示すダウンロード実行管理テーブル870のレコードを優先度順に参照する1010。ダウンロード実行管理テーブル870を見つけたら1020、ダウンロード実行管理テーブル870の内容に従い、サーバからコンテンツのダウンロードを開始し1040、ダウンロード実行状態878の値を、初期値の未ダウンロードからダウンロード中に変更する1040。コンテンツのダウンロードが完了し、HDDに記録されたら1050、配信コンテンツ用メタファイルの所在876のURLから、コンテンツの再生や実行に必要な関連メタファイルをダウンロードし、コンテンツと併せてHDDに登録し1055、ダウンロードの実行状態878の値をダウンロード済に変更し1060、最後に、ダウンロード実行順序テーブル900から、該当するポインタフィールドを削除して、前に詰める。次に、ダウンロードが完了したコンテンツのダウンロード実行管理テーブル870が属するダウンロード予約管理テーブル850を参照し、これに属する全てのダウンロード実行管理テーブル870についてダウンロード実行状態878をチェックし1080、全てのダウンロード実行状態878がダウンロード済で、更新チェックフラグ854=単発、または、チェックフラグ854=更新かつ更新期限日時855が現在日時より過去であれば1080、それ以上ダウンロード制御メタファイルを更新する必要はないと判断し、該当ダウンロード予約管理テーブル850と、それに属するダウンロード実行管理テーブル870をダウンローダ550のデータベースから削除する1100。その後、新たなデータベースに基づき、改めてダウンロード順序決定処理1300を実行し、改めてダウンロード実行順序テーブル900を作り直し1110、ブロック1010からの処理を繰り返し実行する。もし、ブロック1020で、それ以上実行すべきダウンロード実行管理テーブル870がなければ、ダウンロード予約管理テーブル850またはダウンロード実行管理テーブル870が更新されるまで待ち1120、更新されたら最初から処理をやり直す。以上のダウンローダ実行処理1000は、システム起動処理で開始された後は、情報処理装置が動作している間は、他の処理の邪魔にならないよう低い優先度により、バックグラウンドで常に動作を繰り返し続けることが望ましい。本実施例によれば、同じ情報処理装置が多数あった場合でも、ダウンローダ更新処理1100は、機器毎に違った日時を起点として、所定の周期でダウンロード制御メタファイルの更新をチェックする。また、所定の周期に基づきダウンロードを実行するため、Webサーバ100やファイルサーバ200に対するトラフィックを分散することができ、サーバやサーバを接続する回線のコストを抑えることができる。また、監視が不要になったダウンロード制御情報を、自動的にダウンローダ550のデータベース情報から削除でき、不要ファイルが際限なくHDD450に蓄積されることがない。