JP6204775B2 - 情報処理システムおよび情報処理装置 - Google Patents

Description

この発明は情報処理システムおよび情報処理装置に関し、特にたとえば、ユーザの端末にアプリケーションプログラムをダウンロードする、情報処理システムおよび情報処理装置に関する。

背景技術の一例が特許文献１に開示される。この特許文献１に開示のゲームソフトウェア配信システムでは、携帯端末は、ゲームソフトウェア配信サーバから提供されたゲームソフトウェア一覧から、希望するゲームソフトウェアを決定し、ゲームソフトウェア要求を行う。登録処理では、ゲームソフトウェア配信サーバは、端末ＩＤ管理テーブルに該当エントリを登録後、ゲームソフトウェアを生成し、ゲームソフトウェアデータ送信を行う。つまり、ゲームソフトウェアが携帯端末に配信される。携帯端末は、配信されたゲームソフトウェアをゲームデータ格納域に保存する。

特開２００５−２５０６２２号[G06F 1/00, G06F 12/14, G06F 15/00]

しかし、特許文献１に開示されたゲームソフトウェア配信システムでは、携帯端末は、ゲームソフトウェア配信サーバにアクセスし、ゲームソフトウェアを一覧から決定して、そのゲームソフトウェアの配信を受けるため、たとえば、携帯端末以外の端末から購入したゲームソフトウェアを携帯端末に配信させることができなかった。このような配信を可能にするためには、ゲームソフトウェア配信サーバで管理される端末ＩＤ管理テーブルを変更して、ダウンロードに関する情報も管理する必要があると考えられる。ただし、この端末ＩＤ管理テーブルでは、携帯端末毎にソフトウェアの有効期限や使用可能回数などが管理されるため、これらの情報を更新する必要が有る度に、各携帯端末はゲームソフトウェア配信サーバにアクセスする。このため、ゲームソフトウェア配信サーバ側の処理負荷が大きいと考えられる。このような問題は、携帯端末の数が増大すると顕著に表れる。

それゆえに、この発明の主たる目的は、新規な、情報処理システムおよび情報処理装置を提供することである。

また、この発明の他の目的は、サーバ側の処理負荷を軽減することができる、情報処理システムおよび情報処理装置を提供することである。

第１の発明は、第１情報記憶手段、第２情報記憶手段およびダウンロード手段を備える、情報処理システムである。第１情報記憶手段は、複数のユーザ端末の各々、または当該複数のユーザ端末のユーザの各々についての第１ダウンロード情報を記憶する。第２情報記憶手段は、複数のユーザ端末、または当該ユーザ端末のユーザを分類した各グループについての第２ダウンロード情報を記憶する。そして、ダウンロード手段は、第１情報記憶手段に記憶された第１ダウンロード情報および第２情報記憶手段に記憶された第２ダウンロード情報の少なくとも一方を用いてユーザ端末にコンテンツをダウンロードする。ユーザ端末は、情報取得手段およびコンテンツ取得手段をさらに備える。情報取得手段は、ユーザ端末は、第１ダウンロード情報および第２ダウンロード情報の少なくとも一方を取得する。コンテンツ取得手段は、情報取得手段によって取得された第１ダウンロード情報および第２ダウンロード情報の少なくとも一方に従ってコンテンツを取得する。

第１の発明によれば、第１ダウンロード情報と、第２ダウンロード情報に分けるので、すべてのダウンロード情報をユーザ端末毎に管理する必要が無い。したがって、ダウンロード情報を管理する側の処理負荷を軽減することができる。
また、第１の発明によれば、ユーザ端末がダウンロード情報に従ってコンテンツを取得するので、ダウンロード情報を管理する側でコンテンツの取得について管理する必要が無い。

第２の発明は、第１の発明に従属し、ユーザ端末または当該ユーザ端末のユーザからの要求でダウンロードすることが決定されたコンテンツについてのダウンロード情報が第１ダウンロード情報として第１情報記憶手段に記憶され、管理者によってダウンロードすることが決定されたコンテンツについてのダウンロード情報が第２ダウンロード情報として第２情報記憶手段に記憶される。

第２の発明によれば、すべてのダウンロード情報をユーザ端末毎またはユーザ端末のユーザ毎に管理する必要が無く、第２ダウンロード情報はグループ単位で登録すれば良いため、サーバの処理負荷を低減するとともに、サーバの管理者の手間を省くことができる。

第３の発明は、第１または第２の発明に従属し、第１情報記憶手段および第２情報記憶手段を含むダウンロード情報サーバをさらに備える。

第３の発明によれば、第１情報記憶手段と第２情報記憶手段を同じサーバに設けるので、サーバを管理する手間を低減することができる。

第４の発明は、第１ないし第３の発明のいずれかに従属し、ユーザ端末は、付加情報取得手段をさらに備える。付加情報取得手段は、コンテンツに付加された付加情報を取得する。

第４の発明によれば、コンテンツのみならず、コンテンツに付加される付加情報を取得することができる。

第５の発明は、第１ないし第４の発明のいずれかに従属し、情報取得手段は、第１ダウンロード情報および第２ダウンロード情報の少なくとも一方についての更新が有るとき、当該第１ダウンロード情報および当該第２ダウンロード情報のうち少なくとも更新された方を取得する。

第５の発明によれば、第１ダウンロード情報および第２ダウンロード情報のうち更新された情報に従ってコンテンツを取得することができる。

第６の発明は、第５の発明に従属し、情報処理システムは、更新管理サーバをさらに備える。更新管理サーバは、第１ダウンロード情報および第２ダウンロード情報の更新の有無を管理する。ユーザ端末は、問合せ手段をさらに備える。問合せ手段は、第１ダウンロード情報および第２ダウンロード情報の更新の有無を更新管理サーバに問い合わせる。

第６の発明によれば、ダウンロード情報の有無を更新管理サーバに問い合わせるので、ダウンロード情報を管理する側の処理負荷を軽減することができる。

第７の発明は、第１ないし第６の発明のいずれかに従属し、第１ダウンロード情報および第２ダウンロード情報は、異なる種類のダウンロードタスクを含む。

第７の発明によれば、ダウンロードタスクの種類によって、たとえば、ユーザが購入したコンテンツと管理者が登録したコンテンツを区別することができる。

第８の発明は、第７の発明に従属し、ユーザ端末は、ダウンロードタスクの種類に応じて、コンテンツ取得手段によってコンテンツを取得したときの動作が異なる。たとえば、ユーザ自身が購入したコンテンツについては何ら通知しないが、他のユーザから贈られたコンテンツの場合には、その旨がユーザに通知される。さらに、他のユーザからメッセージが有る場合には、メッセージも通知される。また、管理者が登録したコンテンツであれば、管理者から配信されたことが通知される。さらに、管理者から配信されたコンテンツについては、レイティングの情報が有る場合には、その表示を行い、ユーザの承諾を得る。

第８の発明によれば、コンテンツの登録した者に応じてダウンロードタスクの種類を変化させることにより、ユーザ端末における演出（挙動）を変えることができる。

第９の発明は、第７または第８の発明に従属し、ダウンロードタスクの各々には異なる識別情報が付されており、ダウンロードタスクの各々は、識別情報を用いて実行するか否かを管理される。したがって、たとえば、既に取得したコンテンツと同じコンテンツであっても、ユーザによって再度購入されたり、管理者によって再度登録されたりした場合には、ダウンロードタスクには異なる識別情報が付される。

第９の発明によれば、たとえば、既に取得したコンテンツと同じコンテンツのダウンロードタスクに異なる識別情報が付され、ダウンロードタスクの各々は識別情報を用いて管理されるので、削除したコンテンツを再度取得することができる。

第１０の発明は、複数のユーザ端末の各々、または当該複数のユーザ端末のユーザの各々についての第１ダウンロード情報を記憶する第１情報記憶手段、複数のユーザ端末、または当該複数のユーザ端末のユーザを分類した各グループについての第２ダウンロード情報を記憶する第２情報記憶手段、および第１情報記憶手段に記憶された第１ダウンロード情報および第２情報記憶手段に記憶された第２ダウンロード情報の少なくとも一方を用いてユーザ端末にコンテンツをダウンロードするダウンロード手段を備え、ユーザ端末は、第１ダウンロード情報および第２ダウンロード情報の少なくとも一方を取得する情報取得手段、および情報取得手段によって取得された第１ダウンロード情報および第２ダウンロード情報の少なくとも一方に従ってコンテンツを取得するコンテンツ取得手段を備える、情報処理装置である。

第１０の発明においても、第１の発明と同様に、ダウンロード情報を管理する側の処理負荷を軽減することができる。

この発明によれば、ユーザ端末毎のダウンロード情報と、グループ毎のダウンロード情報に分けるので、すべてのダウンロード情報をユーザ端末毎に管理する必要が無い。したがって、ダウンロード情報を管理する側の処理負荷を軽減することができる。

この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施形態の詳細な説明から一層明らかとなろう。

図１は限定しない一例の情報処理システムのブロック図である。 図２はリストサーバに記憶される端末ダウンロードタスクリストとグループダウンロードタスクリストの限定しない一例を示す図である。 図３はユーザ端末で生成および更新されるタスク登録ステータスリストの限定しない一例を示す図である。 図４は図１に示すユーザ端末に内蔵されるＲＡＭのメモリマップの限定しない一例を示す図である。 図５は図１に示すユーザ端末のＣＰＵのリスト生成処理の限定しない一例の一部を示すフロー図である。 図６は図１に示すユーザ端末のＣＰＵのリスト生成処理の限定しない一例の他の一部であって、図５に後続するフロー図である。 図７は図１に示すユーザ端末のＣＰＵのコンテンツ取得処理の限定しない一例を示すフロー図である。 図８は図１に示すユーザ端末のＣＰＵの全体処理の限定しない一例を示すフロー図である。

図１を参照して、この実施例の情報処理システム１０は、複数のユーザ端末１２を含み、各ユーザ端末１２はインターネットのようなネットワーク１４を介して、リストサーバ１６、コンテンツサーバ１８、リビジョンサーバ２０およびショッピングサーバ２２に有線または無線で接続される。したがって、各ユーザ端末１２、リストサーバ１６、コンテンツサーバ１８、リビジョンサーバ２０およびショッピングサーバ２２は、互いに通信可能である。

ユーザ端末１２は、汎用のゲーム機であり、ＣＰＵ１２ａおよびＲＡＭ１２ｂなどのコンポーネントを備える。図示は省略するが、ユーザ端末１２は、本体とは別に設けられたディスプレイおよびコントローラを有している。ただし、ユーザ端末１２は、ディスプレイおよびコントローラが本体に一体的に設けられたものでもよい。

ユーザ端末１２は、ゲームプログラムのような所定のアプリケーションプログラムを実行可能である。所定のアプリケーションプログラムのようなコンテンツは、ユーザ端末１２に装着されたＣＤ、ＤＶＤまたはＳＤカードのような所定の記録媒体から取得することができ、また、ネットワーク１４を介して所定のサーバ（この実施例では、コンテンツサーバ１８）から取得することもできる。この実施例では、ユーザ端末１２は、ユーザが所持ないし所有する端末のうち、コンテンツサーバ１８から取得したコンテンツを使用する端末を意味する。そして、ユーザ端末１２以外の他の端末は、ユーザが所持ないし所有する端末のうち、コンテンツサーバ１８からのコンテンツを取得したり使用したりしない端末を意味する。他の端末の典型例は、スマートフォン、フィーチャーフォン、タブレットＰＣなどのＰＣである。

リストサーバ１６は、コンテンツサーバ１８からユーザ端末１２にコンテンツを配信するための情報（ダウンロード情報）を管理する汎用のサーバである。リストサーバ１６は、ＣＰＵ１６ａおよびＨＤＤのようなメモリ１６ｂなどのコンポーネントを備える。この実施例では、ダウンロード情報は、ダウンロードを実行するためのタスクを記述したリスト（ダウンロードタスクリスト）である。

また、この実施例では、ダウンロードタスクリストは２種類存在する。一方は、ユーザ端末１２毎に管理されるダウンロードタスクリストである。他方は、複数のユーザ端末１２を所定の分類でグループ化した場合のグループ毎に管理されるダウンロードタスクリストである。この実施例では、グループは、国（または一定の領域）単位で分類されるが、これに限定される必要は無い。国に代えて、または、国に加えて、ユーザ端末１２やそのオペレイティングシステムのバージョンで分類するようにしてもよい。分類する要素が２つ以上有る場合には、ユーザ端末１２は２つ以上のグループに属する場合がある。

以下、ユーザ端末１２毎に管理されるダウンロードタスクリストを「端末ＤＴＬ」と言い、グループ毎に管理されるダウンロードタスクリストを「グループＤＴＬ」と言う。ただし、端末ＤＴＬとグループＤＴＬを区別する必要が無い場合には、「ダウンロードタスクリスト」ということがある。

詳細な説明は省略するが、リストサーバ１６は、端末ＤＴＬおよびグループＤＴＬを内部のメモリ１６ｂに記憶し、ＣＰＵ１６ａの指示の下、ユーザ端末１２からの要求に応じて、端末ＤＴＬおよびグループＤＴＬを当該ユーザ端末１２に送信（配信）する。また、リストサーバ１６は、端末ＤＴＬおよびグループＤＴＬを管理するため、その内部のメモリ１６ｂに、ユーザ端末１２の識別情報（端末ＩＤ）に対応して、ユーザの識別情報（ユーザＩＤ）およびグループの識別情報（グループＩＤ）を記述したテーブルを記憶する。ただし、ユーザ端末１２には、複数のユーザを登録することができ、各ユーザに対してユーザＩＤが設定される。

なお、この実施例では、ユーザ端末１２に登録されたユーザＩＤを用いるようにしてあるが、ネットワーク１４を通してコンテンツを購入等するためのサービスを提供するサーバ（この実施例では、ショッピングサーバ２２）の管理者等によって割り当てられた識別情報（ネットワークＩＤ）を用いるようにしてもよい。このように、コンテンツの取得に関してネットワークＩＤを用いる場合には、ユーザ端末１２、コンテンツサーバ１８およびリビジョンサーバ２０においても、ユーザＩＤに代えてネットワークＩＤが用いられる。または、ユーザＩＤに対応してネットワークＩＤが記憶されたテーブルが参照される。

コンテンツサーバ１８は、ユーザ端末１２にコンテンツを配信するための汎用のサーバである。コンテンツサーバ１８は、ＣＰＵ１８ａおよびＨＤＤのようなメモリ１８ｂなどのコンポーネントを備え、コンテンツをメモリ１８ｂに記憶（管理）し、ＣＰＵ１８ａの指示の下、ユーザ端末１２からのリクエストに応じて当該ユーザ端末１２にコンテンツを配信する。詳細な説明は省略するが、コンテンツサーバ１８では、アクセスしてきたユーザ端末１２のユーザに対して、ユーザ認証を行うため、ユーザ端末１２の端末ＩＤや当該ユーザ端末１２に登録されたユーザＩＤを記述したテーブルを内部のメモリ１８ｂに記憶する。また、配信するコンテンツの識別情報（コンテンツＩＤ）に対応して配信するべきユーザのユーザＩＤを記憶したリスト（配信リスト）を内部のメモリ１８ｂに記憶する。上述したように、この実施例では、コンテンツは、ゲームプログラムのような所定のアプリケーションプログラムである。ただし、プログラムに限定される必要は無く、画像データ、音（音楽）データ、文字（書籍）データのような他のコンテンツであってもよい。

リビジョンサーバ２０は、リストサーバ１６で管理される端末ＤＴＬおよびグループＤＴＬが更新されたかどうかを示す情報を管理する汎用のサーバである。リビジョンサーバ２０は、ＣＰＵ２０ａおよびＨＤＤのようなメモリ２０ｂなどのコンポーネントを備え、内部のメモリ２０ｂに、端末ＩＤに対応して、端末ＤＴＬが更新されたかどうかを示す情報（更新情報）およびグループＤＴＬが更新されたかどうを示す情報（更新情報）を記憶する。詳細な説明は省略するが、リビジョンサーバ２０は、端末ＩＤが示すユーザ端末１２が属するグループを知る必要がある。このため、リビジョンサーバ２０は、グループＩＤに対応して、当該グループＩＤが示すグループに属するユーザ端末１２の端末ＩＤが記述されたテーブルを内部のメモリ２０ｂに記憶する。また、リビジョンサーバ２０は、ＣＰＵ２０ａの指示の下、ユーザ端末１２からの問い合わせに応じて、端末ＤＴＬおよびグループＤＴＬの更新情報を当該ユーザ端末１２に通知する。

ショッピングサーバ２２は、ユーザがユーザ端末１２を用いて、取得（購入）するコンテンツを検索したり、所望のコンテンツを取得（購入）することを決定（登録）したりするための汎用のサーバである。ただし、ユーザは、他の端末を用いてコンテンツを検索したり、取得することを決定したりすることができる。この場合、ショッピングサーバ２２は、当該ユーザが使用するユーザ端末１２の端末ＩＤやユーザＩＤを入力させることなどにより、コンテンツの購入者を特定する。詳細な説明は省略するが、ショッピングサーバ２２では、コンテンツの購入者に関する情報およびコンテンツを配信するユーザ端末１２の情報が必要であるため、各ユーザ端末１２の端末ＩＤに対応して各ユーザ端末１２に登録されたユーザＩＤを記述したテーブルが内部のメモリ（ＨＤＤなど）に記憶される。また、コンテンツサーバ１８から配信可能なコンテンツに対応するコンテンツＩＤおよび当該コンテンツの配信元の情報（後述する、「配信元のＵＲＬ」）を記述したテーブルも内部のメモリに記憶される。

なお、たとえば、スマートフォンやフィーチャーフォンのような他の端末を使用してコンテンツを検索したり取得（購入）することを決定したりする場合には、電話網およびネットワーク１４を介してショッピングサーバ２２にアクセスされる場合がある。

また、上述したように、各ユーザ端末１２、リストサーバ１６、コンテンツサーバ１８、リビジョンサーバ２０およびショッピングサーバ２２は、互いに通信可能であるため、それぞれ、通信機能を備えている。

このような情報処理システム１０では、上述したように、ユーザが自身のユーザ端末１２を使用して、ショッピングサーバ２２にアクセスすることにより、自身のためにコンテンツを取得（購入）することを決定したり、他人のためにコンテンツを取得することを決定したりすることができる。ただし、他人は他のユーザ端末１２を使用する他のユーザに限らず、同じユーザ端末１２を使用する他のユーザを含む。

なお、ショッピングサーバ２２にアクセスして、所望のコンテンツを検索したり、所望のコンテンツを取得（購入）することを決定したりすることについては既に周知であるため、詳細な説明は省略する。

コンテンツを取得することが決定されると、ショッピングサーバ２２は、リストサーバ１６に、当該コンテンツのコンテンツＩＤ、配信元のＵＲＬ、当該コンテンツを取得することを決定したユーザ（購入者）のユーザＩＤおよび当該コンテンツを取得するべきユーザ（取得者）のユーザＩＤを通知する。また、ショッピングサーバ２２は、コンテンツサーバ１８に、取得することが決定されたコンテンツのコンテンツＩＤおよび当該コンテンツの取得者のユーザＩＤを通知する。さらに、ショッピングサーバ２２は、リビジョンサーバ２０に、取得することが決定されたコンテンツの取得者のユーザＩＤを通知する。

すると、リストサーバ１６では、ＣＰＵ１６ａによって、ダウンロードタスクが生成され、取得者のユーザＩＤが登録されたユーザ端末１２についての端末ＤＴＬ（図２（Ａ）参照）が更新される。つまり、リストサーバ１６は、ショッピングサーバ２２から取得したコンテンツＩＤ、配信元のＵＲＬ、購入者のユーザＩＤおよび取得者のユーザＩＤを用いてダウンロードタスクを生成する。そして、リストサーバ１６は、内部のメモリ１６ｂに記憶されたテーブルを参照して、取得者のユーザＩＤが登録されたユーザ端末１２の端末ＩＤを特定し、特定した端末ＩＤが付された端末ＤＴＬに生成したダウンロードタスクを追加する。

また、コンテンツサーバ１８では、ＣＰＵ１８ａによって、コンテンツの配信リストに、コンテンツＩＤに対応して取得者のユーザＩＤが登録される。さらに、リビジョンサーバ２０では、取得者のユーザＩＤが登録されたユーザ端末１２の端末ＤＴＬの情報が更新されたことが登録される。つまり、リビジョンサーバ２０は、内部のメモリ２０ｂに記憶されたテーブルを参照して、取得者のユーザＩＤが登録されたユーザ端末１２の端末ＩＤを特定し、特定した端末ＩＤに対応して記憶された更新情報として端末ＤＴＬが更新されたことを記述する。

なお、この実施例では、コンテンツを取得することが決定されると、ショッピングサーバ２２は、リストサーバ１６、コンテンツサーバ１８およびリビジョンサーバ２０のそれぞれに必要な情報を個別に通知するようにしてあるが、これに限定される必要はない。ショッピングサーバ２２は、リストサーバ１６、コンテンツサーバ１８およびリビジョンサーバ２０のすべてに、取得することが決定されたコンテンツのコンテンツＩＤ、配信元のＵＲＬ、購入者のユーザＩＤおよび取得者のユーザＩＤを通知し、各サーバ（１６、１８、２０）で選択的に情報を用いるようにしてもよい。

図２（Ａ）に示すように、各端末ＤＴＬには、端末ＩＤが付され、当該端末ＩＤが割り当てられたユーザ端末１２に対応付けられている。端末ＤＴＬには、端末ＩＤが示すユーザ端末１２が取得するコンテンツについてのダウンロードタスクがコンテンツ毎に記述される。図２（Ａ）に示す例では、複数のダウンロードタスクが記述される。各タスクには、識別情報（タスクＩＤ）が付されている。図２（Ａ）に示す例では、タスクＩＤとして、ダウンロード１、ダウンロード２、…のような名称を記述してあるが、これに限定される必要は無く、タスク間で識別可能であれば、数字やアルファベット或いは人間が解読できない記号が用いられてよい。このことは、グループＤＴＬに付されるタスクＩＤについても同様である。

各ダウンロードタスクには、コンテンツＩＤ、配信元のＵＲＬ、取得者ＩＤおよびタスクタイプが記述される。コンテンツＩＤは、上述したように、コンテンツサーバ１８から配信されるコンテンツの識別情報である。配信元のＵＲＬは、コンテンツＩＤが示すコンテンツの配信元（この実施例では、コンテンツサーバ１８）のアドレスであり、当該コンテンツも特定する。取得者ＩＤは、コンテンツサーバ１８から配信されるコンテンツの取得者に割り当てられたユーザＩＤである。ただし、上述したように、ネットワークＩＤを用いる場合には、取得者ＩＤとして、コンテンツの取得者に割り当てられたネットワークＩＤを記述するようにしてもよい。タスクタイプは、当該ダウンロードタスクの種類であり、この実施例では、３種類（タイプ１、タイプ２、タイプ３）に分類される。

タイプ１は、購入者が自身のために取得することを決定したコンテンツについてのダウンロードタスクの種類である。つまり、ショッピングサーバ２２から通知された購入者のユーザＩＤと取得者のユーザＩＤが一致する場合に、タスクタイプがタイプ１に決定される。

タイプ２は、購入者が他人に取得させる（贈る）ことを決定したコンテンツについてのダウンロードタスクの種類である。つまり、ショッピングサーバ２２から通知された購入者のユーザＩＤと取得者のユーザＩＤが一致しない場合に、タスクタイプがタイプ２に決定される。

タイプ３は、管理者が登録したコンテンツについてのダウンロードタスクの種類である。後述するように、タイプ３のダウンロードタスクは、グループＤＴＬに登録される。

なお、タスクタイプはこれらに限定される必要は無く、２種類以上であれば、さらに多くの種類に分類してもよい。

また、コンテンツサーバ１８の管理者がコンテンツを登録する場合もある。たとえば、無料のコンテンツ、またはバージョンを変更したプログラムやパッチプログラムのようなコンテンツが該当する。管理者によって登録されるコンテンツは、複数のユーザの全部または一部のグループに対して配信される。したがって、管理者は、コンテンツを登録する場合に、当該コンテンツを配信するグループ（グループＩＤ）を指定する。すると、コンテンツサーバ１８からリストサーバ１６に、コンテンツＩＤ、配信元のＵＲＬおよびグループＩＤが通知される。また、コンテンツサーバ１８からリビジョンサーバ２０に、グループＩＤが通知される。したがって、リストサーバ１６では、ＣＰＵ１６ａによって、通知されたグループＩＤが付されたグループＤＴＬ（図２（Ｂ））が更新される。また、リビジョンサーバ２０では、ＣＰＵ２０ａによって、グループＩＤが示すグループに含まれる端末ＩＤに対応する更新情報としてグループＤＴＬが更新されたことが記述される。

図２（Ｂ）に示すように、各グループＤＴＬには、グループＩＤが付される。グループＤＴＬには、グループＩＤが割り当てられたグループに含まれる複数のユーザ端末１２が取得するコンテンツについてのダウンロードタスクがコンテンツ毎に記述される。各グループについて、複数のダウンロードタスクが記述される。上述したように、ダウンロードタスクにはタスクＩＤが付されている。図２（Ｂ）に示す例では、ダウンロードタスクＩＤとして、ダウンロードＡ、ダウンロードＢ、…のような名称が記述される。また、各ダウンロードタスクには、コンテンツＩＤ、配信元のＵＲＬおよびタスクタイプが記述される。これらについては、端末ＤＴＬの場合と同じであるため、重複した説明は省略する。

なお、グループＤＴＬに基づいて取得されるコンテンツは、ユーザ端末１２単位で配信されるものであり、ユーザ単位で配信されるものではないため、グループＤＴＬに含まれるダウンロードタスクにおいては、取得者ＩＤとして取得者のユーザＩＤが記述されることはない。たとえば、ｎｕｌｌデータが記述される。このようにして、端末ＤＴＬとグループＤＴＬのデータ形式が同じにされる。

たとえば、ユーザ端末１２では、スリープの状態のような省電力モードにおいて、ダウンロードタスクリストを更新し、更新したダウンロードタスクリストに基づいて、コンテンツの配信を受ける。具体的には、ユーザ端末１２では、ユーザの指示に従ってスリープの状態に移行されると、所定時間（たとえば、６０分）毎に、リビジョンサーバ２０にダウンロードタスクリストの更新の有無を問い合わせる。また、ユーザ端末１２がアクティブな状態で、ユーザの指示に応じて、リビジョンサーバ２０に問い合わせることも可能である。ただし、アクティブな状態とは、任意のアプリケーションプログラムを実行可能な状態を意味する。

ユーザ端末１２は、リビジョンサーバ２０からダウンロードタスクリストの更新が無いことの通知を受けると、当該ユーザ端末１２を起動することの指示が無い限り、スリープの状態を維持して、次回の問合せタイミングを待機する。

一方、ユーザ端末１２は、リビジョンサーバ２０からダウンロードタスクリストの更新が有ることの通知を受けると、リストサーバ１６にアクセスして、ダウンロードタスクリストを取得する。この実施例では、ユーザ端末１２は、端末ＤＴＬおよびグループＤＴＬの両方を取得するが、更新されたダウンロードタスクリストのみを取得するようにしてもよい。

なお、リビジョンサーバ２０は、ユーザ端末１２にダウンロードタスクリストの更新の有無を通知すると、当該ユーザ端末１２の更新情報をリセットする。この実施例では、更新情報として、ダウンロードタスクリストの更新が無いことが記述される。

ユーザ端末１２は、ダウンロードタスクリストをリストサーバ１６から取得すると、各ダウンロードタスクにその状態を示す情報を付加したリスト（以下、この実施例では、「タスク登録ステータスリスト」という。）を生成（更新）する。初めてタスク登録ステータスリストを生成する場合には、端末ＤＴＬに記述されているダウンロードタスクおよびグループＤＴＬに記述されているダウンロードタスクがすべて登録される。タスク登録ステータスリストは、端末ＤＴＬおよびグループＤＴＬを取得する度に更新され、端末ＤＴＬやグループＤＴＬに追加されたダウンロードタスクが追加され、端末ＤＴＬやグループＤＴＬから削除されたダウンロードタスクが削除される。

図３にはタスク登録ステータスリストの一例が示される。図３からも分かるように、ダウンロードタスクには、コンテンツＩＤ、配信元のＵＲＬおよび取得者ＩＤの他に、状態情報が記述される。コンテンツＩＤ、配信元のＵＲＬおよび取得者ＩＤは上述したとおりである。状態情報は、当該ダウンロードタスクの状態を示すデータであり、たとえば２ビットのレジスタで構成される。ダウンロードタスクが登録された当初において、当該ダウンロードタスクが実行されていない場合には、データ値“００”がレジスタに設定される。また、当該ダウンロードタスクが実行されたが、コンテンツの取得に失敗した場合には、データ値“０１”がレジスタに設定される。さらに、当該ダウンロードタスクが実行され、コンテンツの取得に成功した場合には、データ値“１０”がレジスタに設定される。

このように、ダウンロードタスク毎にタスクＩＤを付してその状態を管理するので、ダウンロードに成功したダウンロードタスクが繰り返し実行されることは無い。したがって、たとえば、ダウンロードに成功したコンテンツがユーザの意思によってユーザ端末１２から削除された場合であっても、状態情報を構成するレジスタのデータ値が“１０”であるため、当該コンテンツが再度取得されることは無い。ただし、ユーザの指示または管理者によって、削除したコンテンツについてのダウンロードタスクが新しく登録されると、当該ダウンロードタスクには別のタスクＩＤが付されるため、このような場合には、削除したコンテンツと同じコンテンツが再度取得される。

また、リストサーバ１６に記憶されている端末ＤＴＬおよびダウンロードＤＴＬは、ユーザが取得するコンテンツについての情報などが含まれるため、第三者に見られたり改竄されたりすることができないように、セキュリティのレベルが高くされている。このため、リビジョンサーバ２０を設けない場合には、リストサーバ１６にアクセスしてダウンロードタスクリストの更新の有無を問い合わせる必要があり、リストサーバ１６において通信頻度が高くなってしまう。また、リストサーバ１６との通信にも暗号化が施されているため、通信におけるデータ量が多い。つまり、リストサーバ１６の処理負荷が非常に大きいと言える。

したがって、この実施例では、リビジョンサーバ２０を設けることにより、ダウンロードタスクリストが更新されている場合にのみ、ユーザ端末１２がリストサーバ１６にアクセスするので、ユーザ端末１２がリストサーバ１６にアクセスする回数を出来る限り少なくすることができる。したがって、リストサーバ１６の処理負荷が軽減される。

ただし、リビジョンサーバ１６を設ける必要があるが、このリビジョンサーバ１６に記憶されているのは更新情報だけであるため、第三者に見られたり改竄されたりしても何ら問題が無く、セキュリティのレベルを高くする必要がない。つまり、低コストでリビジョンサーバ１６を設けることができる。

また、ユーザ端末１２は、タスク登録ステータスリストに従ってコンテンツを取得する。たとえば、ユーザ端末１２は、所定時間（たとえば、６０分）毎に、タスク登録ステータスリストを参照し、取得するべきコンテンツがあるかどうかを判断する。この実施例では、取得するべきコンテンツは、取得に成功していないコンテンツを意味する。したがって、状態情報のデータ値が“００”または“０１”であるダウンロードタスクに記述されたコンテンツＩＤに対応するコンテンツが取得するべきコンテンツである。

取得するべきコンテンツが有れば、当該コンテンツについてのダウンロードタスクが実行される。したがって、ユーザ端末１２は、ダウンロードタスクに記述された配信元のＵＲＬに従ってコンテンツサーバ１８にアクセスし、ユーザ認証等の所定の処理が実行された後に、コンテンツＩＤが示すコンテンツの送信要求を送信する。

コンテンツサーバ１８では、配信リストを参照して、アクセスしてきたユーザ端末１２に対して配信するべきコンテンツがあるかどうかを判断し、送信要求されたコンテンツと配信するべきコンテンツが一致するかどうかを判断する。これらが一致すれば、コンテンツサーバ１８は要求されたコンテンツを要求元のユーザ端末１２に送信する。たとえば、コンテンツはパケット単位で送信されるが、これに限定される必要は無い。ただし、送信するコンテンツに付加情報が付加されている場合には、コンテンツを送信した後に、当該付加情報も送付する。この実施例では、付加情報は、他のユーザからのメッセージや管理者が提供するコンテンツについてのレイティングの情報である。

なお、配信するべきコンテンツが無い場合や送信要求されたコンテンツと配信するべきコンテンツが一致しない場合には、コンテンツサーバ１８はコンテンツを要求元のユーザ端末１２に送信しない。

また、ユーザがコンテンツを購入する場合には、通常、ショッピングサーバ２２にてレイティングの承認（確認）が行われるため、この実施例では、ユーザが購入したコンテンツにレイティングの情報が付加されることは無い。ただし、ショッピングサーバ２２にてレイティングの承認が行われない場合には、レイティングの情報がコンテンツに付加される。

ユーザ端末１２では、コンテンツの取得に成功すると、当該コンテンツのダウンロードタスクに記述された状態情報のデータ値を“１０”に設定する。一方、ユーザ端末１２では、コンテンツの取得に失敗すると、当該コンテンツのダウンロードタスクに記述された状態情報のデータ値を“０１”に設定する。

詳細な説明は省略するが、ユーザ端末１２は、コンテンツの取得中（受信中）に、コンテンツサーバ１８との接続が切断された場合に、コンテンツの取得に失敗する。たとえば、コンテンツサーバ１８との通信時間が所定の制限時間（たとえば、１０分）を超えた場合に、強制的に通信を切断される。ただし、何らかの要因で通信が切断される場合もある。

また、ユーザ端末１２では、新しくコンテンツを取得すると、取得したコンテンツのダウンロードタスクのタスクタイプに応じて異なる動作を実行する。つまり、ダウンロードタスクのタスクタイプによって、ユーザ端末１２における挙動（演出）が異なる。たとえば、ダウンロードタスクのタスクタイプがタイプ１である場合には、新しく取得したコンテンツについての動作は何も実行しない。また、ダウンロードタスクのタスクタイプがタイプ２である場合には、誰から贈られたコンテンツであるかを示すメッセージがディスプレイに表示される。さらに、メッセージが付加されている場合には、当該メッセージも表示される。したがって、たとえば、友達や家族にコンテンツをプレゼントし、メッセージを添えることができる。ただし、メッセージは、テキストのみならず画像（写真）が含まれる場合もある。さらに、ダウンロードタスクのタスクタイプがタイプ３である場合には、管理者から配信された（贈られる場合もある）コンテンツであることを示すメッセージがディスプレイに表示される。さらに、レイティングの情報が付加されている場合には、レイティングの表示が実行され、ユーザの承諾が得られると、当該コンテンツが実行可能にされる。

なお、これらは一例であり、限定されるべきでなく、タスクタイプに応じてユーザ端末１２の動作が異なる点に着目されたい。

図４には、図１に示したユーザ端末１２に内蔵されるＲＡＭ１２ｂのメモリマップ３００の一例が示される。図４に示すように、ＲＡＭ１２ｂは、プログラム記憶領域３０２およびデータ記憶領域３０４を含む。プログラム記憶領域３０２は、情報処理プログラムを記憶し、情報処理プログラムは、全体処理プログラム３０２ａ、通信プログラム３０２ｂ、コンテンツ購入プログラム３０２ｃ、問合せプログラム３０２ｄ、タスクリスト取得プログラム３０２ｅ、ステータスリスト生成プログラム３０２ｆ、コンテンツ取得プログラム３０２ｇ、状態更新プログラム３０２ｈおよび通知プログラム３０２ｉなどによって構成される。

なお、コンテンツ取得プログラム３０２ｇに従って取得されたコンテンツについてのデータ（コンテンツデータ３０４ｄ）がプログラムデータである場合には、取得された後に、データ記憶領域３０４からプログラム記憶領域３０２に展開（実行形式に）される。

全体処理プログラム３０２ａは、ユーザ端末１２の全体的な処理を実行するためのプログラムである。通信プログラム３０２ｂは、他のコンピュータ（サーバなど）にアクセスし、当該他のコンピュータと通信するためのプログラムである。コンテンツ購入プログラム３０２ｃは、通信プログラム３０２ｂに従ってショッピングサーバ２２と通信することにより、ユーザの指示に従って、コンテンツを検索したり、所得（購入）するコンテンツを決定したりするためのプログラムである。

問合せプログラム３０２ｄは、通信プログラム３０２ｂに従ってリビジョンサーバ２０と通信することにより、ダウンロードタスクリストの更新の有無を問い合わせて、ダウンロードタスクリストの更新の有無の通知を受けるためのプログラムである。

タスクリスト取得プログラム３０２ｅは、問合せプログラム３０２ｄに従ってダウンロードタスクリストが更新されていることの通知を受けると、通信プログラム３０２ｂに従ってリストサーバ１６と通信することにより、端末ＤＴＬおよびグループＤＴＬを取得するためのプログラムである。

ステータスリスト生成プログラム３０２ｆは、タスクリスト取得プログラム３０２ｅに従って取得された端末ＤＴＬおよびグループＤＴＬを用いて、タスク登録ステータスリストを生成（更新）するためのプログラムである。

コンテンツ取得プログラム３０２ｇは、タスク登録ステータスリストを参照して、取得するべきコンテンツが有る場合に、通信プログラム３０２ｂに従ってコンテンツサーバ１８と通信することにより、コンテンツを取得するためのプログラムである。

状態更新プログラム３０２ｈは、コンテンツの取得の成功または失敗に応じて、タスク登録ステータスリストに記述された当該コンテンツのダウンロードタスクに含まれる状態情報を設定（更新）するためのプログラムである。

通知プログラム３０２ｉは、コンテンツを取得した場合に、ダウンロードタスクのタスクタイプに応じてユーザに所定の通知を行うためのプログラムである。また、通知プログラム３０２ｉは、コンテンツに付加された付加情報を通知するためのプログラムでもある。

図示は省略するが、プログラム記憶領域３０２には、ユーザ端末１２で実行される様々な機能についてのプログラムも記憶される。

また、データ記憶領域３０４には、端末ＤＴＬデータ３０４ａ、グループＤＴＬデータ３０４ｂ、ステータスリストデータ３０４ｃ、コンテンツデータ３０４ｄおよび付加情報３０４ｅが記憶される。

端末ＤＴＬデータ３０４ａは、リストサーバ１６から取得したユーザ端末１２自身についてのダウンロードタスクリストのデータである。グループＤＴＬデータ３０４ｂは、リストサーバ１６から取得したユーザ端末１２自身を含むグループについてのダウンロードタスクリストのデータである。

ステータスリストデータ３０４ｃは、端末ＤＴＬデータ３０４ａが示す端末ＤＴＬおよびグループＤＴＬデータ３０４ｂが示すグループＤＴＬに基づいて生成したタスク登録ステータスリストについてのデータである。コンテンツデータ３０４ｄは、コンテンツサーバ１８から取得したコンテンツのデータである。付加情報３０４ｅは、コンテンツデータ３０４ｄに付加されたメッセージのデータまたはレイティングの情報である。

また、データ記憶領域３０４には、タイマ３０４ｆが設けられる。このタイマ３０４ｆは、リビジョンサーバ２０にダウンロードタスクリストが更新されたかどうかを問い合わせる時間間隔（この実施例では、６０分）をカウントするためのタイマである。

図示は省略するが、データ記憶領域３０４には、情報処理プログラムを実行するために必要な、他のデータが記憶されたり、他のタイマ（カウンタ）やフラグが設けられたりする。

図５および図６は図１に示したユーザ端末１２のＣＰＵ１２ａのリスト生成処理を示すフロー図である。たとえば、ＣＰＵ１２ａは、ユーザ端末１２がスリープの状態になったときに、リスト生成処理を開始する。ただし、ユーザに指示された場合にも、ＣＰＵ１２ａは、リスト生成処理を開始する。この場合には、後述するステップＳ１およびＳ３は省略される。

図５に示すように、ＣＰＵ１２ａは、リスト生成処理を開始すると、ステップＳ１で、タイマ３０４ｆをリセットおよびスタートする。次のステップＳ３では、所定時間（この実施例では、６０分）を経過したかどうかを判断する。ここでは、ＣＰＵ１２ａは、タイマ３０４ｆのカウント値が６０分を経過したかどうかを判断する。ステップＳ３で“ＮＯ”であれば、つまり所定時間を経過していなければ、同じステップＳ３に戻る。

一方、ステップＳ３で“ＹＥＳ”であれば、つまり所定時間を経過すれば、ステップＳ５で、リビジョンサーバ２０にアクセスする。次のステップＳ７では、リビジョンサーバ２０にダウンロードタスクリスト（この実施例では、端末ＤＴＬおよびグループＤＴＬ）の更新の有無を問い合わせる。そして、ステップＳ９で、リビジョンサーバ２０からダウンロードタスクリストの更新の有無の通知を受信して、図６に示すステップＳ１１に進む。

図６に示すように、ステップＳ１１では、ダウンロードタスクリストの更新が有るかどうかを判断する。ここでは、ＣＰＵ１２ａは、リビジョンサーバ２０から通知された更新情報が更新有りを示すかどうかを判断する。ステップＳ１１で“ＮＯ”であれば、つまりダウンロードタスクリスト（端末ＤＴＬおよびグループＤＴＬの両方）が更新されていなければ、そのまま図５に示したステップＳ１に戻る。ただし、この実施例では、リビジョンサーバ２０から何ら応答が無い場合にも、ステップＳ１１で“ＮＯ”と判断されるが、“ＹＥＳ”と判断されてもよい。

一方、ステップＳ１１で“ＹＥＳ”であれば、つまりダウンロードタスクリスト（端末ＤＴＬおよびグループＤＴＬの少なくとも一方）が更新されていれば、ステップＳ１３で、リストサーバ１６にアクセスし、ステップＳ１５で、リストサーバ１６にダウンロードタスクリストの送信を要求する。そして、ステップＳ１７で、リストサーバ１６からのダウンロードタスクリストを取得する。つまり、ＣＰＵ１２ａは、リストサーバ１６から送信された端末ＤＴＬデータ３０４ａおよびグループＤＴＬデータ３０４ｂを受信してＲＡＭ１２ｂに記憶する。この実施例では、ユーザ端末１２は、端末ＤＴＬデータ３０４ａおよびグループＤＴＬデータ３０４ｂの両方を取得するようにしているが、更新されたデータのみを取得するようにしても良い。

なお、ここでは、ユーザ端末１２は、リストサーバ１６にアクセスし、ダウンロードタスクリストを必ず取得できるように説明してあるが、リストサーバ１６にアクセスできない場合やダウンロードタスクリストを取得できない場合には、ステップＳ１３、Ｓ１５およびＳ１７の処理を繰り返し実行するようにしてよい。

次のステップＳ１９では、タスク登録ステータスリストを生成（更新）する。ＣＰＵ１２ａは、リストサーバ１６から取得した端末ＤＴＬデータ３０４ａおよびグループＤＴＬデータ３０４ｂを用いてタスク登録ステータスリストを生成し、ＲＡＭ１２ｂにステータスリストデータ３０４ｃを記憶する。そして、ステップＳ２１で、リスト生成処理を終了するかどうかを判断する。ここでは、ＣＰＵ１２ａは、ユーザ端末１２を起動することが指示されたかどうかを判断する。ただし、ユーザ端末１２がアクティブな状態でユーザの指示に応じてリスト生成処理を開始した場合には、ステップＳ２１では、“ＹＥＳ”と判断される。

ステップＳ２１で“ＮＯ”であれば、つまりリスト生成処理を終了しない場合には、ステップＳ１に戻る。一方、ステップＳ２１で“ＹＥＳ”であれば、つまりリスト生成処理を終了する場合には、そのままリスト生成処理を終了する。

図７は図１に示したユーザ端末１２のＣＰＵ１２ａのコンテンツ取得処理を示すフロー図である。このコンテンツ取得処理は、所定時間（この実施例では、６０分）毎に実行され、図５に示したリスト生成処理が実行されている場合には、並行して実行される。ただし、コンテンツ取得処理は、ユーザ端末１２の起動時や終了時のような所定のタイミングで実行されてもよい。

図７に示すように、ＣＰＵ１２ａは、コンテンツ取得処理を開始すると、ステップＳ３１で、取得するべきコンテンツがあるかどうかを判断する。ここでは、ＣＰＵ１２ａは、ステータスリストデータ３０４ｃを参照して、状態情報のデータ値が“００”または“０１”を示すダウンロードタスクがあるかどうかを判断する。

ステップＳ３１で“ＮＯ”であれば、つまり取得するべきコンテンツが無ければ、そのままコンテンツ取得処理を終了する。一方、ステップＳ３１で“ＹＥＳ”であれば、つまり取得するべきコンテンツが有れば、ステップＳ３３以降の処理を実行する。ただし、取得するべきコンテンツが複数有る場合には、各コンテンツについて、ステップＳ３３以降の処理が実行される。

ステップＳ３３では、配信元のＵＲＬに従ってコンテンツサーバ１８にアクセスする。ただし、コンテンツサーバ１８にアクセスできない場合には、ステップＳ３３の処理が繰り返し実行される。次のステップＳ３５では、コンテンツサーバ１８にコンテンツの送信を要求する。そして、ステップＳ３７で、コンテンツサーバ１８から送信されるコンテンツを取得（受信）する。つまり、ＣＰＵ１２ａは、コンテンツデータ３０４ｄを受信し、ＲＡＭ１２ｂに記憶する。たとえば、コンテンツデータ３０４ｄは、パケット単位で送信される。

続いて、ステップＳ３９では、コンテンツの取得に成功したかどうかを判断する。つまり、ＣＰＵ１２ａは、コンテンツデータ３０４ｄをすべて受信したかどうかを判断する。ステップＳ３９で“ＹＥＳ”であれば、つまりコンテンツの取得を成功すれば、ステップＳ４１で、当該コンテンツのダウンロードタスクに成功を記録する。つまり、ステップＳ４１では、ＣＰＵ１２は、取得したコンテンツのダウンロードタスクに含まれる状態情報のデータ値を“１０”に設定する。そして、ステップＳ４３で、付加情報が有るかどうかを判断する。ステップＳ４３で“ＮＯ”であれば、そのままコンテンツ取得処理を終了する。一方、ステップＳ４３で“ＹＥＳ”であれば、つまり付加情報が有れば、ステップＳ４５で、付加情報を取得して、コンテンツ取得処理を終了する。ステップＳ４５では、ＣＰＵ１２ａは、コンテンツサーバ１８から付加情報３０４ｅを受信すると、この付加情報３０４ｅを先に取得したコンテンツに関連付けてＲＡＭ１２ｂに記憶する。

一方、ステップＳ３９で“ＮＯ”であれば、つまりコンテンツの取得に成功していなければ、ステップＳ４７で、コンテンツの取得に失敗したかどうかを判断する。ここでは、ＣＰＵ１２ａは、コンテンツデータ３０４ｄをすべて受信する前に、通信の制限時間を超えてしまったり、コンテンツデータ３０４ｄの受信中に、何らかの要因で通信が切断されたりしたかどうかを判断する。

ステップＳ４７で“ＮＯ”であれば、つまりコンテンツの取得に失敗していなければ、コンテンツデータ３０４ｄの取得中（受信中）であると判断して、ステップＳ３７に戻る。一方、ステップＳ４７で“ＹＥＳ”であれば、つまりコンテンツの取得に失敗すれば、ステップＳ４９で、当該コンテンツのダウンロードタスクに失敗を記録して、コンテンツ取得処理を終了する。つまり、ステップＳ４９では、ＣＰＵ１２は、取得したコンテンツのダウンロードタスクに含まれる状態情報のデータ値を“０１”に設定する。

図８は図１に示したユーザ端末１２のＣＰＵ１２ａの全体処理の一例を示すフロー図である。ユーザがユーザ端末１２の起動を指示すると、ＣＰＵ１２ａは、全体処理を開始し、ステップＳ７１で、ユーザ端末１２を起動する。つまり、スリープの状態からアクティブな状態に移行される。次のステップＳ７３では、ディスプレイにメニュー画面を表示する。そして、ステップＳ７５で、新たに取得されたコンテンツが有るかどうかを判断する。

ステップＳ７５で“ＮＯ”であれば、つまり新たに取得されたコンテンツが無ければ、そのままステップＳ９３に進む。一方、ステップＳ７５で“ＹＥＳ”であれば、つまり新たに取得されたコンテンツが有れば、ステップＳ７７以降の処理を実行する。ただし、新たに取得されたコンテンツが複数有る場合には、各コンテンツについてステップＳ７７以降の処理が実行される。

ステップＳ７７では、新たに取得されたコンテンツのダウンロードタスクのタスクタイプがタイプ１であるかどうかを判断する。つまり、ユーザ端末１２を所持しているユーザが自身のために取得することを決定したコンテンツであるかどうかが判断される。

ステップＳ７７で“ＹＥＳ”であれば、つまりタスクタイプがタイプ１であれば、そのままステップＳ９３に進む。一方、ステップＳ７７で“ＮＯ”であれば、つまりタスクタイプがタイプ１でなければ、ステップＳ７９で、新たに取得されたコンテンツのダウンロードタスクのタスクタイプがタイプ２であるかどうかを判断する。つまり、ユーザ端末１２を操作しているユーザ以外のユーザ（他人）から贈られたコンテンツであるかどうかが判断される。

ステップＳ７９で“ＹＥＳ”であれば、つまりタスクタイプがタイプ２であれば、ステップＳ８１で、他人から贈られたコンテンツであることを通知する。つまり、ステップＳ８１では、ＣＰＵ１２ａは、他人から贈られたコンテンツであることのメッセージをディスプレイに表示する。

続くステップＳ８３では、メッセージがあるかどうかを判断する。つまり、ＣＰＵ１２ａは、新たに取得されたコンテンツに関連付けられた付加情報３０４ｅが記憶されているかどうかを判断する。ステップＳ８３で“ＮＯ”であれば、つまりメッセージが無ければ、そのままステップＳ９３に進む。一方、ステップＳ８３で“ＹＥＳ”であれば、つまりメッセージが有れば、ステップＳ８５で、メッセージを通知して、ステップＳ９３に進む。つまり、ステップＳ８５では、ＣＰＵ１２ａは、コンテンツの贈り主からのメッセージをディスプレイに表示する。

また、ステップＳ７９で“ＮＯ”であれば、つまりタスクタイプがタイプ３であれば、コンテンツサーバ１８の管理者から配信されたコンテンツであると判断し、ステップＳ８７で、当該管理者から配信されたコンテンツであることを通知する。つまり、ステップＳ８７では、ＣＰＵ１２ａは、管理者から配信されたコンテンツであることのメッセージをディスプレイに表示する。

続くステップＳ８９では、レイティングの情報が有るかどうかを判断する。つまり、ＣＰＵ１２ａは、新たに取得されたコンテンツに関連付けられた付加情報３０４ｅが記憶されているかどうかを判断する。ステップＳ８９で“ＮＯ”であれば、つまりレイティングの情報が無ければ、そのままステップＳ９３に進む。一方、ステップＳ８９で“ＹＥＳ”であれば、つまりレイティングの情報が有れば、ステップＳ９１で、レイティングの情報をディスプレイに表示して、ステップＳ９３に進む。詳細な説明は省略するが、その後、ユーザによって承認等の操作が行われる。

ステップＳ９３では、ユーザの操作に従って処理を実行する。たとえば、メニューで選択されたアプリケーションプログラムが開始されたり、アプリケーションにおける情報処理が実行されたりする。このアプリケーションには、ショッピングのアプリケーションも含まれる。したがって、このショッピングのアプリケーションが実行されることにより、ユーザ端末１２は、ショッピングサーバ２２にアクセスし、ユーザの指示に従って、コンテンツを検索したり、コンテンツを取得（購入）することを決定したり、メッセージを入力したりすることができる。

続いて、ステップＳ９５では、終了かどうかを判断する。ここでは、ＣＰＵ１２ａは、ユーザによって終了の指示が入力されたかどうかを判断する。つまり、スリープの状態に移行するかどうかを判断するのである。ステップＳ９１で“ＮＯ”であれば、つまり終了でなければ、ステップＳ８９に戻る。一方、ステップＳ９１で“ＹＥＳ”であれば、つまり終了であれば、全体処理を終了する。したがって、ユーザ端末１２はスリープの状態に移行され、上述したように、リスト更新処理（図５および図６）が開始される。

この実施例によれば、端末ＤＴＬとグループＤＴＬを設けるので、グループを構成する複数のユーザ端末に共通に配信されるコンテンツについては、当該グループについてのグループＤＴＬに登録すれば良く、各ユーザ端末の端末ＤＴＬに登録する必要がないため、すべてのダウンロードタスクリストをユーザ端末単位で管理する必要が無く、またダウンロードタスクの登録の手間を大幅に減らすことができる。

また、この実施例によれば、ユーザ端末がダウンロードタスクリストを取得し、このダウンロードタスクリストから生成したタスク登録ステータスリストに従ってコンテンツをダウンロードするので、ユーザ端末におけるコンテンツの取得についてリストサーバは管理する必要が無く、このリストサーバ側の処理負荷を軽減することができる。

さらに、この実施例では、グループＤＴＬによってグループ毎に配信するコンテンツを管理することができるので、工場出荷前に、グループ単位でユーザ端末１２にコンテンツをインストール（プリインストール）する必要が無い。たとえば、従前プリインストールしていたコンテンツを、ユーザ端末１２の購入後にユーザによって取得させることができる。したがって、工場出荷前にグループ毎のユーザ端末１２を用意する手間が無いため、ユーザ端末１２の販売者（提供者）側の負担を大幅に減らすことができる。

なお、この実施例では、ユーザ端末の一例としてゲーム機を挙げたが、これに限定される必要はない。ユーザ端末は、汎用のＰＣ、フィーチャーフォンまたはスマートフォンでも良い。

また、この実施例では、各種サーバを用途に分けて設けるようにしたが、リビジョンサーバを除いて、リストサーバ、コンテンツサーバおよびショッピングサーバを任意の２つまたは全部を１つのサーバにまとめるようにしてもよい。たとえば、リストサーバとコンテンツサーバとを１つにまとめて、ダウンロードタスクリストおよびコンテンツを配信するサーバとして機能させることができる。

さらに、この実施例では、端末ＤＴＬおよびグループＤＴＬをリストサーバで管理するようにしてあるが、これらを別のサーバで管理するようにしてもよい。このようにした場合であっても、すべてのダウンロードタスクリストをユーザ端末毎に管理する必要がないため、サーバ側の処理負荷を軽減することができる。

さらにまた、この実施例では、ユーザ端末がダウンロードタスクリストを取得し、このダウンロードタスクリストに従ってコンテンツを取得するようにしたが、これに限定される必要はない。たとえば、リストサーバがダウンロードタスクリストに従ってコンテンツの配信指示をコンテンツサーバに与えて、ユーザ端末にコンテンツを配信するようにしてもよい。上述したように、リストサーバとコンテンツサーバを１つにまとめたサーバを設ける場合には、コンテンツの配信指示およびコンテンツの配信を１つのサーバで完結することができる。ただし、リストサーバの指示に従ってコンテンツを配信する場合には、リストサーバからユーザ端末にタスクタイプを通知する必要がある。これは、タスクタイプに応じてユーザ端末側での動作（挙動）が異なるからである。

また、この実施例では、ユーザ端末毎に端末ＤＴＬやグループＤＴＬを管理し、ユーザ端末に配信するようにしたが、これに限定される必要はない。たとえば、ユーザ毎のダウンロードタスクリストを管理するとともに、複数のユーザを分類したグループ単位のダウンロードリストを管理して、配信するようにしてもよい。この場合、ダウンロードタスクリストには、端末ＩＤに代えて、ユーザＩＤまたはネットワークＩＤが付される。ただし、グループＩＤは、複数のユーザを分類したグループの識別情報である。この場合には、グループＤＴＬに含まれる取得者ＩＤとしてコンテンツを取得するべきユーザのユーザＩＤが記述される。このようにすれば、ユーザ端末を使用しているユーザを識別して、ユーザ毎に、ダウロードタスクリストの更新の有無を問い合わせたり、ダウロードタスクリストを取得したり、コンテンツを取得したりすることができる。たとえば、ユーザをグループに分類する場合には、ユーザが使用しているアプリケーション、ユーザの性別、年齢（年代）、趣味（趣向）などの種々の属性情報を用いて分類することができる。

さらに、この実施例で示した具体的な数値は一例に過ぎず、実際の製品に応じて、適宜変更される。

１０ …情報処理システム
１２ …ユーザ端末
１６ …リストサーバ
１８ …コンテンツサーバ
２０ …リビジョンサーバ
２２ …ショッピングサーバ

Claims (10)

1. 複数のユーザ端末の各々、または当該複数のユーザ端末のユーザの各々についての第１ダウンロード情報を記憶する第１情報記憶手段、
   前記複数のユーザ端末、または当該複数のユーザ端末のユーザを分類した各グループについての第２ダウンロード情報を記憶する第２情報記憶手段、および
   前記第１情報記憶手段に記憶された第１ダウンロード情報および前記第２情報記憶手段に記憶された第２ダウンロード情報の少なくとも一方を用いて前記ユーザ端末にコンテンツをダウンロードするダウンロード手段を備え、
   前記ユーザ端末は、前記第１ダウンロード情報および前記第２ダウンロード情報の少なくとも一方を取得する情報取得手段、および前記情報取得手段によって取得された第１ダウンロード情報および第２ダウンロード情報の少なくとも一方に従ってコンテンツを取得するコンテンツ取得手段を備える、情報処理システム。
2. 前記ユーザ端末または当該ユーザ端末のユーザからの要求でダウンロードすることが決定されたコンテンツについてのダウンロード情報が前記第１ダウンロード情報として前記第１情報記憶手段に記憶され、
   管理者によってダウンロードすることが決定されたコンテンツについてのダウンロード情報が前記第２ダウンロード情報として前記第２情報記憶手段に記憶される、請求項１記載の情報処理システム。
3. 前記第１情報記憶手段および前記第２情報記憶手段を含むダウンロード情報サーバをさらに備える、請求項１または２記載の情報処理システム。
4. 前記ユーザ端末は、前記コンテンツに付加された付加情報を取得する付加情報取得手段をさらに備える、請求項１ないし３のいずれかに記載の情報処理システム。
5. 前記情報取得手段は、前記第１ダウンロード情報および前記第２ダウンロード情報の少なくとも一方についての更新が有るとき、当該第１ダウンロード情報および当該第２ダウンロード情報のうち少なくとも更新された方を取得する、請求項１ないし４のいずれかに記載の情報処理システム。
6. 前記第１ダウンロード情報および前記第２ダウンロード情報の更新の有無を管理する更新管理サーバをさらに備え、
   前記ユーザ端末は、前記第１ダウンロード情報および前記第２ダウンロード情報の更新の有無を前記更新管理サーバに問い合わせる問合せ手段をさらに備える、請求項５記載の情報処理システム。
7. 前記第１ダウンロード情報および前記第２ダウンロード情報は、異なる種類のダウンロードタスクを含む、請求項１ないし６のいずれかに記載の情報処理システム。
8. 前記ユーザ端末は、前記ダウンロードタスクの種類に応じて、前記コンテンツ取得手段によって前記コンテンツを取得したときの動作が異なる、請求項７記載の情報処理システム。
9. 前記ダウンロードタスクの各々には異なる識別情報が付されており、当該ダウンロードタスクの各々は当該識別情報を用いて実行するか否かを管理される、請求項７または８記載の情報処理システム。
10. 複数のユーザ端末の各々、または当該複数のユーザ端末のユーザの各々についての第１ダウンロード情報を記憶する第１情報記憶手段、
    前記複数のユーザ端末、または当該複数のユーザ端末のユーザを分類した各グループについての第２ダウンロード情報を記憶する第２情報記憶手段、および
    前記第１情報記憶手段に記憶された第１ダウンロード情報および前記第２情報記憶手段に記憶された第２ダウンロード情報の少なくとも一方を用いて前記ユーザ端末にコンテンツをダウンロードするダウンロード手段を備え、
    前記ユーザ端末は、前記第１ダウンロード情報および前記第２ダウンロード情報の少なくとも一方を取得する情報取得手段、および前記情報取得手段によって取得された第１ダウンロード情報および第２ダウンロード情報の少なくとも一方に従ってコンテンツを取得するコンテンツ取得手段を備える、情報処理装置。

Images