JP2011216115A - ダウンロード制御装置 - Google Patents

Abstract

【課題】RSSのメタファイルの配信日時情報に従って一斉にダウンロードを開始すると、
サーバに一時的にトラフィックが集中して、システムダウン等のおそれがある。また、周期的にWebサーバ上のRSSファイルが更新されていないかをチェックするので、更新が不要なRSSファイルを監視対象からユーザが削除したりしなければならない。
【解決手段】そこで、ダウンロード制御情報の定期的な更新チェック時期を分散させることにより、サーバへのダウンロード要求を分散させる。また、ダウンロード制御情報に、そのダウンロード制御情報が、更新管理をするかどうかを示す情報、及び／又は、更新管理する場合の更新期限の日時情報を設け、情報処理装置がこれらの情報に基づいてダウンロード処理が完了した際のダウンロード制御情報の消去処理を行う。
【選択図】図２

Description

技術分野は、データやプログラム等のコンテンツのダウンロードを制御するダウンロード制御装置に関する。

上記技術分野について、例えば特許文献１には「情報配信者が登録ユーザに対して情報配信を継続的に行えるようにする」ことを課題とし、その解決手段として「情報配信システムは、所定の書式で記載された日付情報を含む配信情報を発信する発信サイト３０と、各発信サイト３０から配信情報を取得可能な情報配信サーバ２０と、情報配信サーバ２０から配信情報を取得する情報端末１０とを備える。情報端末１０は、配信情報をカレンダー状に表示したカレンダーブラウザ４０を表示可能な表示手段１４と、情報配信サーバ２０から取得した配信情報から日付情報を抽出し、日付情報に該当するカレンダーブラウザ４０の該当日欄に、配信情報が届いたことを示す情報マーク４７を表示するマーク生成手段１６と、情報マーク４７が表示された日欄を選択すると、選択された日欄に含まれる配信情報の内容を表示する内容表示画面に切り替える表示切替手段１７とを備える。コンテンツ毎の利用者の必要性の度合いを考慮して、必要性の高いコンテンツのみを即時に配信することができるコンテンツ配信システムを提供する」ことが記載されている。

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

ブロードバンドインターネットサービスの普及に伴い、映像、写真、音楽、マルチメディアデータ、アプリケーションプログラムといったコンテンツをインターネットで配信するサービスが注目を集めている。

これらの様々なコンテンツを購入してダウンロードするとき、ＰＣ等の情報処理装置でインターネットプラウザを利用し、HTMLコンテンツからリンクされたコンテンツを、ユーザが操作デバイスを使用して指示することで、購入やダウンロードの操作を行う。

このとき、コンテンツのダウンロードの利便性を向上するため、多数のコンテンツを一括してダウンロードしたり、定期的に配信されるコンテンツを逐次ダウンロードできたり、新しいバージョンのコンテンツが配信されたら、ダウンロード済みのコンテンツを更新できる機能を提供することが望ましい。

このようなダウンロード機能を提供するために、規格化されたダウンロード制御情報として、上記特許文献１にも記載のあるRSS（RDF Site Summary）と呼ばれるXML形式のタグ言語が利用されることがある。一つのRSSファイルの中には、RSSファイル自体の名称やインターネット上の所在（URL）が記載され、複数のitemと呼ばれるコンテンツのダウンロードに必要な情報が記載される。具体的には、ダウンロードするコンテンツの名称、データ種別、サイズ、ダウンロード先（URL）、配信日時などの情報が記載される。

RSSファイルは、例えばWebサーバ上に置かれる。情報処理装置は、HTMLコンテンツからリンクされたRSSファイルを、ユーザ操作により指示して読み込むことにより、RSSファイルに記載されたコンテンツのダウンロードを、メタファイルの記述に従って行う。

しかし、特許文献１やこのようなダウンローダアプリケーションにおいて、従来のRSSによるダウンロード制御では次のような問題がある。

まず、RSSのメタファイルの配信日時情報に従うと、そのメタファイルに従った情報処
理装置が一斉にダウンロードを開始することになってしまい、サーバに一時的にトラフィックが集中して、システムダウン等の障害を発生するおそれがある。特に家庭の映像をダウンロードする民生機器（テレビやレコーダ等）が情報処理装置である場合には、コンテンツが映像であるため大容量であり、民生用であるため数も多数のためおそれが特に懸念される。

また、RSSファイルでは、情報処理装置は、周期的にWebサーバ上のRSSファイルが更新されていないかをチェックすることとなってしまう。コンテンツによっては更新が不要なものや、ある時期まで更新されるがある時期以降は更新されないものもある。こういったコンテンツに対して、情報処理装置では今後の更新の有無を知ることができない。このため、情報処理装置を使用するユーザは、サービス提供者からの情報等から自分で判断して、不要になったRSSファイルの監視対象から削除することになり、ユーザの手間及び／又はネットワークのトラフィックの無駄となってしまう。

そこで例えば、ダウンロード制御情報の定期的な更新チェック時期を分散させることにより、サーバへのダウンロード要求を分散させる。

また、ダウンロード制御情報に、そのダウンロード制御情報が、更新管理をするかどうかを示す情報、及び／又は、更新管理する場合の更新期限の日時情報を設け、情報処理装置がこれらの情報に基づいてダウンロード処理が完了した際のダウンロード制御情報の消去処理を行う。

上記手段によれば例えば、トラフィックの集中を避けることができる。また、単発で（１回きりに）配信されるコンテンツや、不定期または定期的に配信される一連のコンテンツのそれぞれに対し、適切な更新処理を行うことができる。

情報処理装置及びシステムの構成例を示すブロック図 ダウンロード制御メタファイルの構成例を示すデータ図 Webサーバと情報処理装置との処理シーケンスの例を示すフロー図 ダウンローダ管理情報の構成例を示すデータ図 システム初期設定処理とタイマー割込処理の例を示すフロー図 ダウンローダ更新処理の例を示すフロー図 ダウンロード実行順序決定処理の例を示すフロー図 ダウンローダ実行処理の例を示すフロー図

本発明に好適な実施形態の例（実施例）を、図面を引用しつつ説明する。ただし本発明は本実施例に限定されるものではない。

図１は、情報処理装置400と、関係するシステムとの関係を示す。

情報処理装置400においては、CPU420が、メモリ430やHDD450に格納されたプログラムを実行することで、各種の処理を行う。情報処理装置400は、例えばネットワークに接続して記録機能を有するテレビ、レコーダ、パーソナルコンピュータ等である。

情報処理装置400は、リアルタイムクロック（RTC）460を持ち、常に実時間を保持し、上記プログラムから参照することができ、設定された日時にCPU420にプログラムを実行させるタイマー機能を持っている。

また、ハードディスクインタフェース（HDD I/F）440を介して、ハードディスクドライブ（HDD）が接続されており、上記プログラムは、大容量のデータの読み書き処理を行うことができる。

また、ネットワークインタフェース（LAN I/F）410を介し、ルータ（ゲートウェイ等であってもよい。総称して中継装置ともいう）310に接続され、インターネット300に接続される。インターネットを介してアクセスするサーバには、Webサーバ100とファイルサーバ200がある。

Webサーバ100は、情報処理装置400が持つWebブラウザ機能で表示を行うために参照するWebページ110と、情報処理装置400が様々なコンテンツをダウンロードするのに必要な制御情報を記述したダウンロード制御メタファイル120を保持する。情報処理装置400のようなハードウェア構成も備えており、例えばCPUが、メモリやHDDに格納されたプログラムを実行することで、各種の処理を行う。

ファイルサーバ200には、ダウンロードするコンテンツ210のデータ本体が置かれる。情報処理装置400のようなハードウェア構成も備えており、例えばCPUが、メモリやHDDに格納されたプログラムを実行することで、各種の処理を行う。

情報処理装置400からファイルサーバ200に、コンテンツの取得要求されると、インターネットを介してコンテンツのデータが配信され、それをHDD I/F440を介して、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の場合にはenclosure urlで各コンテンツを識別する。

ダウンロード制御情報130には、対応するダウンロード制御メタファイル１２０の名称（例えばダウンロード予約の名称、ファイル名、ID等）を示すダウンロード制御メタファイルの名称131、対応するダウンロード制御メタファイル１２０の所在（例えば、ダウンロード予約を提供するウェブサイトのインターネット上のURL。URLに限らないアドレスであってもよい、以下所在について同様。）を示すダウンロード制御メタファイルの所在132、対応するダウンロード制御メタファイル１２０の説明（例えばダウンロード予約についての説明や言語タイプ等）を示すダウンロード制御メタファイルの説明文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ページa 111（例えばパック、映画、番組、楽曲等のコンテンツのタイトルを表示する画面データや、HTMLを含む）を表示し、このコンテンツをユーザがリモコン等の操作デバイスで操作し、「購入する」のボタンを選択すると、Webページa 111において、「購入する」ボタンにリンク記述されたWebページb 112を取得し、表示する。図３の例では、Webページa 111として、パックのタイトル「柏ＦＣ’０６パック」と、金額「3000円」と、メッセージ「柏FCの06年度全試合をご覧いただけます」と、視聴やコピーの条件「期限なし」「コピー３回」と、ボタン「購入する」「戻る」とを表示する画面を示している。また、Webページb 112として、番組のタイトル「柏ＦＣ’０６パック」と、このパックのうちダウンロードするコンテンツを選択するボタン（例えば「全部」を選択するとパックに含まれる全てのコンテンツがダウンロードされ、「６月」を選択すると６月分のコンテンツがダウンロードされる）を標示する画面を示している。このWebページにおいて、一つ一つのダウンロードボタンに対して、それぞれダウンロードするコンテンツについて記述したダウンロード制御メタファイル120が用意され、リンクされている。「柏ＦＣ’０６パック」を選ぶと例えば、「柏ＦＣ’０６パック」を名称131として含むダウンロード制御情報130と、06年の柏FCの全試合のそれぞれに対応するダウンロード実行情報140（試合数が50試合なら、ダウンロード実行情報140も50個）とが含まれたダウンロード制御メタファイル120を取得する。また、「3月」を選択すると例えば、「柏ＦＣ’０６パック 3月」を名称131として含むダウンロード制御情報130と、06年3月の柏FCの全試合のそれぞれに対応するダウンロード実行情報140（試合数が5試合なら、ダウンロード実行情報140も5個）とが含まれたダウンロード制御メタファイル120を取得する（Webサーバ100は送信し、情報処理装置400は受信する）。

このWebページb 112において、ユーザが「ダウンロード」ボタンを選択すると、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ページb 112で指示したダウンロード制御メタファイル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のダウンロード実行管理テーブルポインタ（１ 856からN 857）には、ダウンロード実行管理テーブル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の相違をチェックする(1160)。

チェックした結果、ダウンロード実行管理テーブルポインタ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）。

図７は、図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） 複数のコンテンツのダウンロードが並行して実行できる情報処理装置の場合、数個のコンテンツを同時並行でダウンロードする。
（e） （d）の数個のコンテンツを同時並行でダウンロードする場合、それぞれ別々のドメインのサーバに置かれたダウンロードを優先する。
（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から、該当するポインタフィールドを削除して、前に詰める(1070)。

次に、ダウンロードが完了したコンテンツのダウンロード実行管理テーブル870が属するダウンロード予約管理テーブル850を参照し、これに属する全てのダウンロード実行管理テーブル870についてダウンロード実行状態878をチェックし（1080)、全てのダウンロード実行状態878が「ダウンロード済」で、更新チェックフラグ854＝「単発」、または、チェックフラグ854＝「更新」かつ更新期限日時855が現在日時より過去であれば（1080）、それ以上ダウンロード制御メタファイルを更新する必要はないと判断し、該当ダウンロード予約管理テーブル850と、それに属するダウンロード実行管理テーブル870をダウンローダ550のデータベースから削除する（1100）。

その後、新たなデータベースに基づき、改めてダウンロード順序決定処理1300を実行し、改めてダウンロード実行順序テーブル900を作り直し（1110）、ブロック1010からの処理を繰り返し実行する。

もし、ブロック1020で、それ以上実行すべきダウンロード実行管理テーブル870がなければ、ダウンロード予約管理テーブル８５０またはダウンロード実行管理テーブル８７０が更新されるまで待ち（1120）、更新されたら最初から処理をやり直す。

以上のダウンローダ実行処理1000は、システム起動処理で開始された後は、情報処理装置が動作している間は、他の処理の邪魔にならないよう低い優先度により、バックグラウンドで常に動作を繰り返し続けることが望ましい。

本実施例によれば、同じ情報処理装置が多数あった場合でも、ダウンローダ更新処理1100は、機器毎に違った日時を起点として、所定の周期でダウンロード制御メタファイルの更新をチェックする。

また、所定の周期に基づきダウンロードを実行するため、Webサーバ100やファイルサーバ200に対するトラフィックを分散することができ、サーバやサーバを接続する回線のコストを抑えることができる。

また、監視が不要になったダウンロード制御情報を、自動的にダウンローダ550のデータベース情報から削除でき、不要ファイルが際限なくHDD450に蓄積されることがない。

１２０：ダウンロード制御メタファイル
１３４：更新チェックフラグ
１３５：更新期限日時
２１０：コンテンツ
４００：情報処理装置
４５０：ハードディスクドライブ
４６０：リアルタイムクロック
５００：Webブラウザ
５５０：ダウンローダ
６００：システム初期設定処理
７００：タイマー割込処理
８００：ダウンローダ管理情報
８５０：ダウンロード予約管理テーブル
８７０：ダウンロード実行管理テーブル
９００：ダウンロード実行順序テーブル
１０００：ダウンローダ実行処理
１１００：ダウンローダ更新処理
１３００：ダウンロード実行順序決定処理

Claims (1)

1. コンテンツのダウンロードを制御するダウンロード制御装置であって、
   ダウンロードされるコンテンツの識別情報を含むダウンロード制御データを記録する制御データ記録部と、
   前記制御データ記録部に記録されているダウンロード制御データの更新を確認する更新確認部と、
   前記更新確認部による確認のタイミングを設定する確認タイミング設定部とを有するダウンロード制御装置。

Images