特許第6204775号(P6204775)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 任天堂株式会社の特許一覧
<>
  • 特許6204775-情報処理システムおよび情報処理装置 図000002
  • 特許6204775-情報処理システムおよび情報処理装置 図000003
  • 特許6204775-情報処理システムおよび情報処理装置 図000004
  • 特許6204775-情報処理システムおよび情報処理装置 図000005
  • 特許6204775-情報処理システムおよび情報処理装置 図000006
  • 特許6204775-情報処理システムおよび情報処理装置 図000007
  • 特許6204775-情報処理システムおよび情報処理装置 図000008
  • 特許6204775-情報処理システムおよび情報処理装置 図000009
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6204775
(24)【登録日】2017年9月8日
(45)【発行日】2017年9月27日
(54)【発明の名称】情報処理システムおよび情報処理装置
(51)【国際特許分類】
   G06F 9/445 20060101AFI20170914BHJP
   G06F 13/00 20060101ALI20170914BHJP
【FI】
   G06F9/06 640A
   G06F13/00 540A
【請求項の数】10
【全頁数】22
(21)【出願番号】特願2013-200851(P2013-200851)
(22)【出願日】2013年9月27日
(65)【公開番号】特開2015-69266(P2015-69266A)
(43)【公開日】2015年4月13日
【審査請求日】2016年9月6日
(73)【特許権者】
【識別番号】000233778
【氏名又は名称】任天堂株式会社
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1
(74)【代理人】
【識別番号】100090181
【弁理士】
【氏名又は名称】山田 義人
(74)【代理人】
【識別番号】100130269
【弁理士】
【氏名又は名称】石原 盛規
(72)【発明者】
【氏名】合田 照彦
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1 任天堂株式会社内
(72)【発明者】
【氏名】武田 直樹
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1 任天堂株式会社内
(72)【発明者】
【氏名】徳永 英治
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1 任天堂株式会社内
(72)【発明者】
【氏名】中尾 孔一
【住所又は居所】京都府京都市南区上鳥羽鉾立町11番地1 任天堂株式会社内
【審査官】 石川 亮
(56)【参考文献】
【文献】 特開2002−073498(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/445
G06F 13/00
(57)【特許請求の範囲】
【請求項1】
複数のユーザ端末の各々、または当該複数のユーザ端末のユーザの各々についての第1ダウンロード情報を記憶する第1情報記憶手段、
前記複数のユーザ端末、または当該複数のユーザ端末のユーザを分類した各グループについての第2ダウンロード情報を記憶する第2情報記憶手段、および
前記第1情報記憶手段に記憶された第1ダウンロード情報および前記第2情報記憶手段に記憶された第2ダウンロード情報の少なくとも一方を用いて前記ユーザ端末にコンテンツをダウンロードするダウンロード手段を備え、
前記ユーザ端末は、前記第1ダウンロード情報および前記第2ダウンロード情報の少なくとも一方を取得する情報取得手段、および前記情報取得手段によって取得された第1ダウンロード情報および第2ダウンロード情報の少なくとも一方に従ってコンテンツを取得するコンテンツ取得手段を備える、情報処理システム。
【請求項2】
前記ユーザ端末または当該ユーザ端末のユーザからの要求でダウンロードすることが決定されたコンテンツについてのダウンロード情報が前記第1ダウンロード情報として前記第1情報記憶手段に記憶され、
管理者によってダウンロードすることが決定されたコンテンツについてのダウンロード情報が前記第2ダウンロード情報として前記第2情報記憶手段に記憶される、請求項1記載の情報処理システム。
【請求項3】
前記第1情報記憶手段および前記第2情報記憶手段を含むダウンロード情報サーバをさらに備える、請求項1または2記載の情報処理システム。
【請求項4】
前記ユーザ端末は、前記コンテンツに付加された付加情報を取得する付加情報取得手段をさらに備える、請求項1ないし3のいずれかに記載の情報処理システム。
【請求項5】
前記情報取得手段は、前記第1ダウンロード情報および前記第2ダウンロード情報の少なくとも一方についての更新が有るとき、当該第1ダウンロード情報および当該第2ダウンロード情報のうち少なくとも更新された方を取得する、請求項1ないし4のいずれかに記載の情報処理システム。
【請求項6】
前記第1ダウンロード情報および前記第2ダウンロード情報の更新の有無を管理する更新管理サーバをさらに備え、
前記ユーザ端末は、前記第1ダウンロード情報および前記第2ダウンロード情報の更新の有無を前記更新管理サーバに問い合わせる問合せ手段をさらに備える、請求項記載の情報処理システム。
【請求項7】
前記第1ダウンロード情報および前記第2ダウンロード情報は、異なる種類のダウンロードタスクを含む、請求項1ないしのいずれかに記載の情報処理システム。
【請求項8】
前記ユーザ端末は、前記ダウンロードタスクの種類に応じて、前記コンテンツ取得手段によって前記コンテンツを取得したときの動作が異なる、請求項記載の情報処理システム。
【請求項9】
前記ダウンロードタスクの各々には異なる識別情報が付されており、当該ダウンロードタスクの各々は当該識別情報を用いて実行するか否かを管理される、請求項または記載の情報処理システム。
【請求項10】
複数のユーザ端末の各々、または当該複数のユーザ端末のユーザの各々についての第1ダウンロード情報を記憶する第1情報記憶手段、
前記複数のユーザ端末、または当該複数のユーザ端末のユーザを分類した各グループについての第2ダウンロード情報を記憶する第2情報記憶手段、および
前記第1情報記憶手段に記憶された第1ダウンロード情報および前記第2情報記憶手段に記憶された第2ダウンロード情報の少なくとも一方を用いて前記ユーザ端末にコンテンツをダウンロードするダウンロード手段を備え、
前記ユーザ端末は、前記第1ダウンロード情報および前記第2ダウンロード情報の少なくとも一方を取得する情報取得手段、および前記情報取得手段によって取得された第1ダウンロード情報および第2ダウンロード情報の少なくとも一方に従ってコンテンツを取得するコンテンツ取得手段を備える、情報処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は情報処理システムおよび情報処理装置に関し、特にたとえば、ユーザの端末にアプリケーションプログラムをダウンロードする、情報処理システムおよび情報処理装置に関する。
【背景技術】
【0002】
背景技術の一例が特許文献1に開示される。この特許文献1に開示のゲームソフトウェア配信システムでは、携帯端末は、ゲームソフトウェア配信サーバから提供されたゲームソフトウェア一覧から、希望するゲームソフトウェアを決定し、ゲームソフトウェア要求を行う。登録処理では、ゲームソフトウェア配信サーバは、端末ID管理テーブルに該当エントリを登録後、ゲームソフトウェアを生成し、ゲームソフトウェアデータ送信を行う。つまり、ゲームソフトウェアが携帯端末に配信される。携帯端末は、配信されたゲームソフトウェアをゲームデータ格納域に保存する。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2005−250622号[G06F 1/00, G06F 12/14, G06F 15/00]
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、特許文献1に開示されたゲームソフトウェア配信システムでは、携帯端末は、ゲームソフトウェア配信サーバにアクセスし、ゲームソフトウェアを一覧から決定して、そのゲームソフトウェアの配信を受けるため、たとえば、携帯端末以外の端末から購入したゲームソフトウェアを携帯端末に配信させることができなかった。このような配信を可能にするためには、ゲームソフトウェア配信サーバで管理される端末ID管理テーブルを変更して、ダウンロードに関する情報も管理する必要があると考えられる。ただし、この端末ID管理テーブルでは、携帯端末毎にソフトウェアの有効期限や使用可能回数などが管理されるため、これらの情報を更新する必要が有る度に、各携帯端末はゲームソフトウェア配信サーバにアクセスする。このため、ゲームソフトウェア配信サーバ側の処理負荷が大きいと考えられる。このような問題は、携帯端末の数が増大すると顕著に表れる。
【0005】
それゆえに、この発明の主たる目的は、新規な、情報処理システムおよび情報処理装置を提供することである。
【0006】
また、この発明の他の目的は、サーバ側の処理負荷を軽減することができる、情報処理システムおよび情報処理装置を提供することである。
【課題を解決するための手段】
【0007】
第1の発明は、第1情報記憶手段、第2情報記憶手段およびダウンロード手段を備える、情報処理システムである。第1情報記憶手段は、複数のユーザ端末の各々、または当該複数のユーザ端末のユーザの各々についての第1ダウンロード情報を記憶する。第2情報記憶手段は、複数のユーザ端末、または当該ユーザ端末のユーザを分類した各グループについての第2ダウンロード情報を記憶する。そして、ダウンロード手段は、第1情報記憶手段に記憶された第1ダウンロード情報および第2情報記憶手段に記憶された第2ダウンロード情報の少なくとも一方を用いてユーザ端末にコンテンツをダウンロードする。ユーザ端末は、情報取得手段およびコンテンツ取得手段をさらに備える。情報取得手段は、ユーザ端末は、第1ダウンロード情報および第2ダウンロード情報の少なくとも一方を取得する。コンテンツ取得手段は、情報取得手段によって取得された第1ダウンロード情報および第2ダウンロード情報の少なくとも一方に従ってコンテンツを取得する。
【0008】
第1の発明によれば、第1ダウンロード情報と、第2ダウンロード情報に分けるので、すべてのダウンロード情報をユーザ端末毎に管理する必要が無い。したがって、ダウンロード情報を管理する側の処理負荷を軽減することができる。
また、第1の発明によれば、ユーザ端末がダウンロード情報に従ってコンテンツを取得するので、ダウンロード情報を管理する側でコンテンツの取得について管理する必要が無い。
【0009】
第2の発明は、第1の発明に従属し、ユーザ端末または当該ユーザ端末のユーザからの要求でダウンロードすることが決定されたコンテンツについてのダウンロード情報が第1ダウンロード情報として第1情報記憶手段に記憶され、管理者によってダウンロードすることが決定されたコンテンツについてのダウンロード情報が第2ダウンロード情報として第2情報記憶手段に記憶される。
【0010】
第2の発明によれば、すべてのダウンロード情報をユーザ端末毎またはユーザ端末のユーザ毎に管理する必要が無く、第2ダウンロード情報はグループ単位で登録すれば良いため、サーバの処理負荷を低減するとともに、サーバの管理者の手間を省くことができる。
【0011】
第3の発明は、第1または第2の発明に従属し、第1情報記憶手段および第2情報記憶手段を含むダウンロード情報サーバをさらに備える。
【0012】
第3の発明によれば、第1情報記憶手段と第2情報記憶手段を同じサーバに設けるので、サーバを管理する手間を低減することができる。
【0015】
の発明は、第1ないし第3の発明のいずれかに従属し、ユーザ端末は、付加情報取得手段をさらに備える。付加情報取得手段は、コンテンツに付加された付加情報を取得する。
【0016】
の発明によれば、コンテンツのみならず、コンテンツに付加される付加情報を取得することができる。
【0017】
の発明は、第1ないし第4の発明のいずれかに従属し、情報取得手段は、第1ダウンロード情報および第2ダウンロード情報の少なくとも一方についての更新が有るとき、当該第1ダウンロード情報および当該第2ダウンロード情報のうち少なくとも更新された方を取得する。
【0018】
の発明によれば、第1ダウンロード情報および第2ダウンロード情報のうち更新された情報に従ってコンテンツを取得することができる。
【0019】
の発明は、第の発明に従属し、情報処理システムは、更新管理サーバをさらに備える。更新管理サーバは、第1ダウンロード情報および第2ダウンロード情報の更新の有無を管理する。ユーザ端末は、問合せ手段をさらに備える。問合せ手段は、第1ダウンロード情報および第2ダウンロード情報の更新の有無を更新管理サーバに問い合わせる。
【0020】
の発明によれば、ダウンロード情報の有無を更新管理サーバに問い合わせるので、ダウンロード情報を管理する側の処理負荷を軽減することができる。
【0021】
の発明は、第1ないし第の発明のいずれかに従属し、第1ダウンロード情報および第2ダウンロード情報は、異なる種類のダウンロードタスクを含む。
【0022】
の発明によれば、ダウンロードタスクの種類によって、たとえば、ユーザが購入したコンテンツと管理者が登録したコンテンツを区別することができる。
【0023】
の発明は、第の発明に従属し、ユーザ端末は、ダウンロードタスクの種類に応じて、コンテンツ取得手段によってコンテンツを取得したときの動作が異なる。たとえば、ユーザ自身が購入したコンテンツについては何ら通知しないが、他のユーザから贈られたコンテンツの場合には、その旨がユーザに通知される。さらに、他のユーザからメッセージが有る場合には、メッセージも通知される。また、管理者が登録したコンテンツであれば、管理者から配信されたことが通知される。さらに、管理者から配信されたコンテンツについては、レイティングの情報が有る場合には、その表示を行い、ユーザの承諾を得る。
【0024】
の発明によれば、コンテンツの登録した者に応じてダウンロードタスクの種類を変化させることにより、ユーザ端末における演出(挙動)を変えることができる。
【0025】
の発明は、第または第の発明に従属し、ダウンロードタスクの各々には異なる識別情報が付されており、ダウンロードタスクの各々は、識別情報を用いて実行するか否かを管理される。したがって、たとえば、既に取得したコンテンツと同じコンテンツであっても、ユーザによって再度購入されたり、管理者によって再度登録されたりした場合には、ダウンロードタスクには異なる識別情報が付される。
【0026】
の発明によれば、たとえば、既に取得したコンテンツと同じコンテンツのダウンロードタスクに異なる識別情報が付され、ダウンロードタスクの各々は識別情報を用いて管理されるので、削除したコンテンツを再度取得することができる。
【0027】
10の発明は、複数のユーザ端末の各々、または当該複数のユーザ端末のユーザの各々についての第1ダウンロード情報を記憶する第1情報記憶手段、複数のユーザ端末、または当該複数のユーザ端末のユーザを分類した各グループについての第2ダウンロード情報を記憶する第2情報記憶手段、および第1情報記憶手段に記憶された第1ダウンロード情報および第2情報記憶手段に記憶された第2ダウンロード情報の少なくとも一方を用いてユーザ端末にコンテンツをダウンロードするダウンロード手段を備え、ユーザ端末は、第1ダウンロード情報および第2ダウンロード情報の少なくとも一方を取得する情報取得手段、および情報取得手段によって取得された第1ダウンロード情報および第2ダウンロード情報の少なくとも一方に従ってコンテンツを取得するコンテンツ取得手段を備える、情報処理装置である。
【0028】
10の発明においても、第1の発明と同様に、ダウンロード情報を管理する側の処理負荷を軽減することができる。
【発明の効果】
【0029】
この発明によれば、ユーザ端末毎のダウンロード情報と、グループ毎のダウンロード情報に分けるので、すべてのダウンロード情報をユーザ端末毎に管理する必要が無い。したがって、ダウンロード情報を管理する側の処理負荷を軽減することができる。
【0030】
この発明の上述の目的,その他の目的,特徴および利点は、図面を参照して行う以下の実施形態の詳細な説明から一層明らかとなろう。
【図面の簡単な説明】
【0031】
図1図1は限定しない一例の情報処理システムのブロック図である。
図2図2はリストサーバに記憶される端末ダウンロードタスクリストとグループダウンロードタスクリストの限定しない一例を示す図である。
図3図3はユーザ端末で生成および更新されるタスク登録ステータスリストの限定しない一例を示す図である。
図4図4図1に示すユーザ端末に内蔵されるRAMのメモリマップの限定しない一例を示す図である。
図5図5図1に示すユーザ端末のCPUのリスト生成処理の限定しない一例の一部を示すフロー図である。
図6図6図1に示すユーザ端末のCPUのリスト生成処理の限定しない一例の他の一部であって、図5に後続するフロー図である。
図7図7図1に示すユーザ端末のCPUのコンテンツ取得処理の限定しない一例を示すフロー図である。
図8図8図1に示すユーザ端末のCPUの全体処理の限定しない一例を示すフロー図である。
【発明を実施するための形態】
【0032】
図1を参照して、この実施例の情報処理システム10は、複数のユーザ端末12を含み、各ユーザ端末12はインターネットのようなネットワーク14を介して、リストサーバ16、コンテンツサーバ18、リビジョンサーバ20およびショッピングサーバ22に有線または無線で接続される。したがって、各ユーザ端末12、リストサーバ16、コンテンツサーバ18、リビジョンサーバ20およびショッピングサーバ22は、互いに通信可能である。
【0033】
ユーザ端末12は、汎用のゲーム機であり、CPU12aおよびRAM12bなどのコンポーネントを備える。図示は省略するが、ユーザ端末12は、本体とは別に設けられたディスプレイおよびコントローラを有している。ただし、ユーザ端末12は、ディスプレイおよびコントローラが本体に一体的に設けられたものでもよい。
【0034】
ユーザ端末12は、ゲームプログラムのような所定のアプリケーションプログラムを実行可能である。所定のアプリケーションプログラムのようなコンテンツは、ユーザ端末12に装着されたCD、DVDまたはSDカードのような所定の記録媒体から取得することができ、また、ネットワーク14を介して所定のサーバ(この実施例では、コンテンツサーバ18)から取得することもできる。この実施例では、ユーザ端末12は、ユーザが所持ないし所有する端末のうち、コンテンツサーバ18から取得したコンテンツを使用する端末を意味する。そして、ユーザ端末12以外の他の端末は、ユーザが所持ないし所有する端末のうち、コンテンツサーバ18からのコンテンツを取得したり使用したりしない端末を意味する。他の端末の典型例は、スマートフォン、フィーチャーフォン、タブレットPCなどのPCである。
【0035】
リストサーバ16は、コンテンツサーバ18からユーザ端末12にコンテンツを配信するための情報(ダウンロード情報)を管理する汎用のサーバである。リストサーバ16は、CPU16aおよびHDDのようなメモリ16bなどのコンポーネントを備える。この実施例では、ダウンロード情報は、ダウンロードを実行するためのタスクを記述したリスト(ダウンロードタスクリスト)である。
【0036】
また、この実施例では、ダウンロードタスクリストは2種類存在する。一方は、ユーザ端末12毎に管理されるダウンロードタスクリストである。他方は、複数のユーザ端末12を所定の分類でグループ化した場合のグループ毎に管理されるダウンロードタスクリストである。この実施例では、グループは、国(または一定の領域)単位で分類されるが、これに限定される必要は無い。国に代えて、または、国に加えて、ユーザ端末12やそのオペレイティングシステムのバージョンで分類するようにしてもよい。分類する要素が2つ以上有る場合には、ユーザ端末12は2つ以上のグループに属する場合がある。
【0037】
以下、ユーザ端末12毎に管理されるダウンロードタスクリストを「端末DTL」と言い、グループ毎に管理されるダウンロードタスクリストを「グループDTL」と言う。ただし、端末DTLとグループDTLを区別する必要が無い場合には、「ダウンロードタスクリスト」ということがある。
【0038】
詳細な説明は省略するが、リストサーバ16は、端末DTLおよびグループDTLを内部のメモリ16bに記憶し、CPU16aの指示の下、ユーザ端末12からの要求に応じて、端末DTLおよびグループDTLを当該ユーザ端末12に送信(配信)する。また、リストサーバ16は、端末DTLおよびグループDTLを管理するため、その内部のメモリ16bに、ユーザ端末12の識別情報(端末ID)に対応して、ユーザの識別情報(ユーザID)およびグループの識別情報(グループID)を記述したテーブルを記憶する。ただし、ユーザ端末12には、複数のユーザを登録することができ、各ユーザに対してユーザIDが設定される。
【0039】
なお、この実施例では、ユーザ端末12に登録されたユーザIDを用いるようにしてあるが、ネットワーク14を通してコンテンツを購入等するためのサービスを提供するサーバ(この実施例では、ショッピングサーバ22)の管理者等によって割り当てられた識別情報(ネットワークID)を用いるようにしてもよい。このように、コンテンツの取得に関してネットワークIDを用いる場合には、ユーザ端末12、コンテンツサーバ18およびリビジョンサーバ20においても、ユーザIDに代えてネットワークIDが用いられる。または、ユーザIDに対応してネットワークIDが記憶されたテーブルが参照される。
【0040】
コンテンツサーバ18は、ユーザ端末12にコンテンツを配信するための汎用のサーバである。コンテンツサーバ18は、CPU18aおよびHDDのようなメモリ18bなどのコンポーネントを備え、コンテンツをメモリ18bに記憶(管理)し、CPU18aの指示の下、ユーザ端末12からのリクエストに応じて当該ユーザ端末12にコンテンツを配信する。詳細な説明は省略するが、コンテンツサーバ18では、アクセスしてきたユーザ端末12のユーザに対して、ユーザ認証を行うため、ユーザ端末12の端末IDや当該ユーザ端末12に登録されたユーザIDを記述したテーブルを内部のメモリ18bに記憶する。また、配信するコンテンツの識別情報(コンテンツID)に対応して配信するべきユーザのユーザIDを記憶したリスト(配信リスト)を内部のメモリ18bに記憶する。上述したように、この実施例では、コンテンツは、ゲームプログラムのような所定のアプリケーションプログラムである。ただし、プログラムに限定される必要は無く、画像データ、音(音楽)データ、文字(書籍)データのような他のコンテンツであってもよい。
【0041】
リビジョンサーバ20は、リストサーバ16で管理される端末DTLおよびグループDTLが更新されたかどうかを示す情報を管理する汎用のサーバである。リビジョンサーバ20は、CPU20aおよびHDDのようなメモリ20bなどのコンポーネントを備え、内部のメモリ20bに、端末IDに対応して、端末DTLが更新されたかどうかを示す情報(更新情報)およびグループDTLが更新されたかどうを示す情報(更新情報)を記憶する。詳細な説明は省略するが、リビジョンサーバ20は、端末IDが示すユーザ端末12が属するグループを知る必要がある。このため、リビジョンサーバ20は、グループIDに対応して、当該グループIDが示すグループに属するユーザ端末12の端末IDが記述されたテーブルを内部のメモリ20bに記憶する。また、リビジョンサーバ20は、CPU20aの指示の下、ユーザ端末12からの問い合わせに応じて、端末DTLおよびグループDTLの更新情報を当該ユーザ端末12に通知する。
【0042】
ショッピングサーバ22は、ユーザがユーザ端末12を用いて、取得(購入)するコンテンツを検索したり、所望のコンテンツを取得(購入)することを決定(登録)したりするための汎用のサーバである。ただし、ユーザは、他の端末を用いてコンテンツを検索したり、取得することを決定したりすることができる。この場合、ショッピングサーバ22は、当該ユーザが使用するユーザ端末12の端末IDやユーザIDを入力させることなどにより、コンテンツの購入者を特定する。詳細な説明は省略するが、ショッピングサーバ22では、コンテンツの購入者に関する情報およびコンテンツを配信するユーザ端末12の情報が必要であるため、各ユーザ端末12の端末IDに対応して各ユーザ端末12に登録されたユーザIDを記述したテーブルが内部のメモリ(HDDなど)に記憶される。また、コンテンツサーバ18から配信可能なコンテンツに対応するコンテンツIDおよび当該コンテンツの配信元の情報(後述する、「配信元のURL」)を記述したテーブルも内部のメモリに記憶される。
【0043】
なお、たとえば、スマートフォンやフィーチャーフォンのような他の端末を使用してコンテンツを検索したり取得(購入)することを決定したりする場合には、電話網およびネットワーク14を介してショッピングサーバ22にアクセスされる場合がある。
【0044】
また、上述したように、各ユーザ端末12、リストサーバ16、コンテンツサーバ18、リビジョンサーバ20およびショッピングサーバ22は、互いに通信可能であるため、それぞれ、通信機能を備えている。
【0045】
このような情報処理システム10では、上述したように、ユーザが自身のユーザ端末12を使用して、ショッピングサーバ22にアクセスすることにより、自身のためにコンテンツを取得(購入)することを決定したり、他人のためにコンテンツを取得することを決定したりすることができる。ただし、他人は他のユーザ端末12を使用する他のユーザに限らず、同じユーザ端末12を使用する他のユーザを含む。
【0046】
なお、ショッピングサーバ22にアクセスして、所望のコンテンツを検索したり、所望のコンテンツを取得(購入)することを決定したりすることについては既に周知であるため、詳細な説明は省略する。
【0047】
コンテンツを取得することが決定されると、ショッピングサーバ22は、リストサーバ16に、当該コンテンツのコンテンツID、配信元のURL、当該コンテンツを取得することを決定したユーザ(購入者)のユーザIDおよび当該コンテンツを取得するべきユーザ(取得者)のユーザIDを通知する。また、ショッピングサーバ22は、コンテンツサーバ18に、取得することが決定されたコンテンツのコンテンツIDおよび当該コンテンツの取得者のユーザIDを通知する。さらに、ショッピングサーバ22は、リビジョンサーバ20に、取得することが決定されたコンテンツの取得者のユーザIDを通知する。
【0048】
すると、リストサーバ16では、CPU16aによって、ダウンロードタスクが生成され、取得者のユーザIDが登録されたユーザ端末12についての端末DTL(図2(A)参照)が更新される。つまり、リストサーバ16は、ショッピングサーバ22から取得したコンテンツID、配信元のURL、購入者のユーザIDおよび取得者のユーザIDを用いてダウンロードタスクを生成する。そして、リストサーバ16は、内部のメモリ16bに記憶されたテーブルを参照して、取得者のユーザIDが登録されたユーザ端末12の端末IDを特定し、特定した端末IDが付された端末DTLに生成したダウンロードタスクを追加する。
【0049】
また、コンテンツサーバ18では、CPU18aによって、コンテンツの配信リストに、コンテンツIDに対応して取得者のユーザIDが登録される。さらに、リビジョンサーバ20では、取得者のユーザIDが登録されたユーザ端末12の端末DTLの情報が更新されたことが登録される。つまり、リビジョンサーバ20は、内部のメモリ20bに記憶されたテーブルを参照して、取得者のユーザIDが登録されたユーザ端末12の端末IDを特定し、特定した端末IDに対応して記憶された更新情報として端末DTLが更新されたことを記述する。
【0050】
なお、この実施例では、コンテンツを取得することが決定されると、ショッピングサーバ22は、リストサーバ16、コンテンツサーバ18およびリビジョンサーバ20のそれぞれに必要な情報を個別に通知するようにしてあるが、これに限定される必要はない。ショッピングサーバ22は、リストサーバ16、コンテンツサーバ18およびリビジョンサーバ20のすべてに、取得することが決定されたコンテンツのコンテンツID、配信元のURL、購入者のユーザIDおよび取得者のユーザIDを通知し、各サーバ(16、18、20)で選択的に情報を用いるようにしてもよい。
【0051】
図2(A)に示すように、各端末DTLには、端末IDが付され、当該端末IDが割り当てられたユーザ端末12に対応付けられている。端末DTLには、端末IDが示すユーザ端末12が取得するコンテンツについてのダウンロードタスクがコンテンツ毎に記述される。図2(A)に示す例では、複数のダウンロードタスクが記述される。各タスクには、識別情報(タスクID)が付されている。図2(A)に示す例では、タスクIDとして、ダウンロード1、ダウンロード2、…のような名称を記述してあるが、これに限定される必要は無く、タスク間で識別可能であれば、数字やアルファベット或いは人間が解読できない記号が用いられてよい。このことは、グループDTLに付されるタスクIDについても同様である。
【0052】
各ダウンロードタスクには、コンテンツID、配信元のURL、取得者IDおよびタスクタイプが記述される。コンテンツIDは、上述したように、コンテンツサーバ18から配信されるコンテンツの識別情報である。配信元のURLは、コンテンツIDが示すコンテンツの配信元(この実施例では、コンテンツサーバ18)のアドレスであり、当該コンテンツも特定する。取得者IDは、コンテンツサーバ18から配信されるコンテンツの取得者に割り当てられたユーザIDである。ただし、上述したように、ネットワークIDを用いる場合には、取得者IDとして、コンテンツの取得者に割り当てられたネットワークIDを記述するようにしてもよい。タスクタイプは、当該ダウンロードタスクの種類であり、この実施例では、3種類(タイプ1、タイプ2、タイプ3)に分類される。
【0053】
タイプ1は、購入者が自身のために取得することを決定したコンテンツについてのダウンロードタスクの種類である。つまり、ショッピングサーバ22から通知された購入者のユーザIDと取得者のユーザIDが一致する場合に、タスクタイプがタイプ1に決定される。
【0054】
タイプ2は、購入者が他人に取得させる(贈る)ことを決定したコンテンツについてのダウンロードタスクの種類である。つまり、ショッピングサーバ22から通知された購入者のユーザIDと取得者のユーザIDが一致しない場合に、タスクタイプがタイプ2に決定される。
【0055】
タイプ3は、管理者が登録したコンテンツについてのダウンロードタスクの種類である。後述するように、タイプ3のダウンロードタスクは、グループDTLに登録される。
【0056】
なお、タスクタイプはこれらに限定される必要は無く、2種類以上であれば、さらに多くの種類に分類してもよい。
【0057】
また、コンテンツサーバ18の管理者がコンテンツを登録する場合もある。たとえば、無料のコンテンツ、またはバージョンを変更したプログラムやパッチプログラムのようなコンテンツが該当する。管理者によって登録されるコンテンツは、複数のユーザの全部または一部のグループに対して配信される。したがって、管理者は、コンテンツを登録する場合に、当該コンテンツを配信するグループ(グループID)を指定する。すると、コンテンツサーバ18からリストサーバ16に、コンテンツID、配信元のURLおよびグループIDが通知される。また、コンテンツサーバ18からリビジョンサーバ20に、グループIDが通知される。したがって、リストサーバ16では、CPU16aによって、通知されたグループIDが付されたグループDTL(図2(B))が更新される。また、リビジョンサーバ20では、CPU20aによって、グループIDが示すグループに含まれる端末IDに対応する更新情報としてグループDTLが更新されたことが記述される。
【0058】
図2(B)に示すように、各グループDTLには、グループIDが付される。グループDTLには、グループIDが割り当てられたグループに含まれる複数のユーザ端末12が取得するコンテンツについてのダウンロードタスクがコンテンツ毎に記述される。各グループについて、複数のダウンロードタスクが記述される。上述したように、ダウンロードタスクにはタスクIDが付されている。図2(B)に示す例では、ダウンロードタスクIDとして、ダウンロードA、ダウンロードB、…のような名称が記述される。また、各ダウンロードタスクには、コンテンツID、配信元のURLおよびタスクタイプが記述される。これらについては、端末DTLの場合と同じであるため、重複した説明は省略する。
【0059】
なお、グループDTLに基づいて取得されるコンテンツは、ユーザ端末12単位で配信されるものであり、ユーザ単位で配信されるものではないため、グループDTLに含まれるダウンロードタスクにおいては、取得者IDとして取得者のユーザIDが記述されることはない。たとえば、nullデータが記述される。このようにして、端末DTLとグループDTLのデータ形式が同じにされる。
【0060】
たとえば、ユーザ端末12では、スリープの状態のような省電力モードにおいて、ダウンロードタスクリストを更新し、更新したダウンロードタスクリストに基づいて、コンテンツの配信を受ける。具体的には、ユーザ端末12では、ユーザの指示に従ってスリープの状態に移行されると、所定時間(たとえば、60分)毎に、リビジョンサーバ20にダウンロードタスクリストの更新の有無を問い合わせる。また、ユーザ端末12がアクティブな状態で、ユーザの指示に応じて、リビジョンサーバ20に問い合わせることも可能である。ただし、アクティブな状態とは、任意のアプリケーションプログラムを実行可能な状態を意味する。
【0061】
ユーザ端末12は、リビジョンサーバ20からダウンロードタスクリストの更新が無いことの通知を受けると、当該ユーザ端末12を起動することの指示が無い限り、スリープの状態を維持して、次回の問合せタイミングを待機する。
【0062】
一方、ユーザ端末12は、リビジョンサーバ20からダウンロードタスクリストの更新が有ることの通知を受けると、リストサーバ16にアクセスして、ダウンロードタスクリストを取得する。この実施例では、ユーザ端末12は、端末DTLおよびグループDTLの両方を取得するが、更新されたダウンロードタスクリストのみを取得するようにしてもよい。
【0063】
なお、リビジョンサーバ20は、ユーザ端末12にダウンロードタスクリストの更新の有無を通知すると、当該ユーザ端末12の更新情報をリセットする。この実施例では、更新情報として、ダウンロードタスクリストの更新が無いことが記述される。
【0064】
ユーザ端末12は、ダウンロードタスクリストをリストサーバ16から取得すると、各ダウンロードタスクにその状態を示す情報を付加したリスト(以下、この実施例では、「タスク登録ステータスリスト」という。)を生成(更新)する。初めてタスク登録ステータスリストを生成する場合には、端末DTLに記述されているダウンロードタスクおよびグループDTLに記述されているダウンロードタスクがすべて登録される。タスク登録ステータスリストは、端末DTLおよびグループDTLを取得する度に更新され、端末DTLやグループDTLに追加されたダウンロードタスクが追加され、端末DTLやグループDTLから削除されたダウンロードタスクが削除される。
【0065】
図3にはタスク登録ステータスリストの一例が示される。図3からも分かるように、ダウンロードタスクには、コンテンツID、配信元のURLおよび取得者IDの他に、状態情報が記述される。コンテンツID、配信元のURLおよび取得者IDは上述したとおりである。状態情報は、当該ダウンロードタスクの状態を示すデータであり、たとえば2ビットのレジスタで構成される。ダウンロードタスクが登録された当初において、当該ダウンロードタスクが実行されていない場合には、データ値“00”がレジスタに設定される。また、当該ダウンロードタスクが実行されたが、コンテンツの取得に失敗した場合には、データ値“01”がレジスタに設定される。さらに、当該ダウンロードタスクが実行され、コンテンツの取得に成功した場合には、データ値“10”がレジスタに設定される。
【0066】
このように、ダウンロードタスク毎にタスクIDを付してその状態を管理するので、ダウンロードに成功したダウンロードタスクが繰り返し実行されることは無い。したがって、たとえば、ダウンロードに成功したコンテンツがユーザの意思によってユーザ端末12から削除された場合であっても、状態情報を構成するレジスタのデータ値が“10”であるため、当該コンテンツが再度取得されることは無い。ただし、ユーザの指示または管理者によって、削除したコンテンツについてのダウンロードタスクが新しく登録されると、当該ダウンロードタスクには別のタスクIDが付されるため、このような場合には、削除したコンテンツと同じコンテンツが再度取得される。
【0067】
また、リストサーバ16に記憶されている端末DTLおよびダウンロードDTLは、ユーザが取得するコンテンツについての情報などが含まれるため、第三者に見られたり改竄されたりすることができないように、セキュリティのレベルが高くされている。このため、リビジョンサーバ20を設けない場合には、リストサーバ16にアクセスしてダウンロードタスクリストの更新の有無を問い合わせる必要があり、リストサーバ16において通信頻度が高くなってしまう。また、リストサーバ16との通信にも暗号化が施されているため、通信におけるデータ量が多い。つまり、リストサーバ16の処理負荷が非常に大きいと言える。
【0068】
したがって、この実施例では、リビジョンサーバ20を設けることにより、ダウンロードタスクリストが更新されている場合にのみ、ユーザ端末12がリストサーバ16にアクセスするので、ユーザ端末12がリストサーバ16にアクセスする回数を出来る限り少なくすることができる。したがって、リストサーバ16の処理負荷が軽減される。
【0069】
ただし、リビジョンサーバ16を設ける必要があるが、このリビジョンサーバ16に記憶されているのは更新情報だけであるため、第三者に見られたり改竄されたりしても何ら問題が無く、セキュリティのレベルを高くする必要がない。つまり、低コストでリビジョンサーバ16を設けることができる。
【0070】
また、ユーザ端末12は、タスク登録ステータスリストに従ってコンテンツを取得する。たとえば、ユーザ端末12は、所定時間(たとえば、60分)毎に、タスク登録ステータスリストを参照し、取得するべきコンテンツがあるかどうかを判断する。この実施例では、取得するべきコンテンツは、取得に成功していないコンテンツを意味する。したがって、状態情報のデータ値が“00”または“01”であるダウンロードタスクに記述されたコンテンツIDに対応するコンテンツが取得するべきコンテンツである。
【0071】
取得するべきコンテンツが有れば、当該コンテンツについてのダウンロードタスクが実行される。したがって、ユーザ端末12は、ダウンロードタスクに記述された配信元のURLに従ってコンテンツサーバ18にアクセスし、ユーザ認証等の所定の処理が実行された後に、コンテンツIDが示すコンテンツの送信要求を送信する。
【0072】
コンテンツサーバ18では、配信リストを参照して、アクセスしてきたユーザ端末12に対して配信するべきコンテンツがあるかどうかを判断し、送信要求されたコンテンツと配信するべきコンテンツが一致するかどうかを判断する。これらが一致すれば、コンテンツサーバ18は要求されたコンテンツを要求元のユーザ端末12に送信する。たとえば、コンテンツはパケット単位で送信されるが、これに限定される必要は無い。ただし、送信するコンテンツに付加情報が付加されている場合には、コンテンツを送信した後に、当該付加情報も送付する。この実施例では、付加情報は、他のユーザからのメッセージや管理者が提供するコンテンツについてのレイティングの情報である。
【0073】
なお、配信するべきコンテンツが無い場合や送信要求されたコンテンツと配信するべきコンテンツが一致しない場合には、コンテンツサーバ18はコンテンツを要求元のユーザ端末12に送信しない。
【0074】
また、ユーザがコンテンツを購入する場合には、通常、ショッピングサーバ22にてレイティングの承認(確認)が行われるため、この実施例では、ユーザが購入したコンテンツにレイティングの情報が付加されることは無い。ただし、ショッピングサーバ22にてレイティングの承認が行われない場合には、レイティングの情報がコンテンツに付加される。
【0075】
ユーザ端末12では、コンテンツの取得に成功すると、当該コンテンツのダウンロードタスクに記述された状態情報のデータ値を“10”に設定する。一方、ユーザ端末12では、コンテンツの取得に失敗すると、当該コンテンツのダウンロードタスクに記述された状態情報のデータ値を“01”に設定する。
【0076】
詳細な説明は省略するが、ユーザ端末12は、コンテンツの取得中(受信中)に、コンテンツサーバ18との接続が切断された場合に、コンテンツの取得に失敗する。たとえば、コンテンツサーバ18との通信時間が所定の制限時間(たとえば、10分)を超えた場合に、強制的に通信を切断される。ただし、何らかの要因で通信が切断される場合もある。
【0077】
また、ユーザ端末12では、新しくコンテンツを取得すると、取得したコンテンツのダウンロードタスクのタスクタイプに応じて異なる動作を実行する。つまり、ダウンロードタスクのタスクタイプによって、ユーザ端末12における挙動(演出)が異なる。たとえば、ダウンロードタスクのタスクタイプがタイプ1である場合には、新しく取得したコンテンツについての動作は何も実行しない。また、ダウンロードタスクのタスクタイプがタイプ2である場合には、誰から贈られたコンテンツであるかを示すメッセージがディスプレイに表示される。さらに、メッセージが付加されている場合には、当該メッセージも表示される。したがって、たとえば、友達や家族にコンテンツをプレゼントし、メッセージを添えることができる。ただし、メッセージは、テキストのみならず画像(写真)が含まれる場合もある。さらに、ダウンロードタスクのタスクタイプがタイプ3である場合には、管理者から配信された(贈られる場合もある)コンテンツであることを示すメッセージがディスプレイに表示される。さらに、レイティングの情報が付加されている場合には、レイティングの表示が実行され、ユーザの承諾が得られると、当該コンテンツが実行可能にされる。
【0078】
なお、これらは一例であり、限定されるべきでなく、タスクタイプに応じてユーザ端末12の動作が異なる点に着目されたい。
【0079】
図4には、図1に示したユーザ端末12に内蔵されるRAM12bのメモリマップ300の一例が示される。図4に示すように、RAM12bは、プログラム記憶領域302およびデータ記憶領域304を含む。プログラム記憶領域302は、情報処理プログラムを記憶し、情報処理プログラムは、全体処理プログラム302a、通信プログラム302b、コンテンツ購入プログラム302c、問合せプログラム302d、タスクリスト取得プログラム302e、ステータスリスト生成プログラム302f、コンテンツ取得プログラム302g、状態更新プログラム302hおよび通知プログラム302iなどによって構成される。
【0080】
なお、コンテンツ取得プログラム302gに従って取得されたコンテンツについてのデータ(コンテンツデータ304d)がプログラムデータである場合には、取得された後に、データ記憶領域304からプログラム記憶領域302に展開(実行形式に)される。
【0081】
全体処理プログラム302aは、ユーザ端末12の全体的な処理を実行するためのプログラムである。通信プログラム302bは、他のコンピュータ(サーバなど)にアクセスし、当該他のコンピュータと通信するためのプログラムである。コンテンツ購入プログラム302cは、通信プログラム302bに従ってショッピングサーバ22と通信することにより、ユーザの指示に従って、コンテンツを検索したり、所得(購入)するコンテンツを決定したりするためのプログラムである。
【0082】
問合せプログラム302dは、通信プログラム302bに従ってリビジョンサーバ20と通信することにより、ダウンロードタスクリストの更新の有無を問い合わせて、ダウンロードタスクリストの更新の有無の通知を受けるためのプログラムである。
【0083】
タスクリスト取得プログラム302eは、問合せプログラム302dに従ってダウンロードタスクリストが更新されていることの通知を受けると、通信プログラム302bに従ってリストサーバ16と通信することにより、端末DTLおよびグループDTLを取得するためのプログラムである。
【0084】
ステータスリスト生成プログラム302fは、タスクリスト取得プログラム302eに従って取得された端末DTLおよびグループDTLを用いて、タスク登録ステータスリストを生成(更新)するためのプログラムである。
【0085】
コンテンツ取得プログラム302gは、タスク登録ステータスリストを参照して、取得するべきコンテンツが有る場合に、通信プログラム302bに従ってコンテンツサーバ18と通信することにより、コンテンツを取得するためのプログラムである。
【0086】
状態更新プログラム302hは、コンテンツの取得の成功または失敗に応じて、タスク登録ステータスリストに記述された当該コンテンツのダウンロードタスクに含まれる状態情報を設定(更新)するためのプログラムである。
【0087】
通知プログラム302iは、コンテンツを取得した場合に、ダウンロードタスクのタスクタイプに応じてユーザに所定の通知を行うためのプログラムである。また、通知プログラム302iは、コンテンツに付加された付加情報を通知するためのプログラムでもある。
【0088】
図示は省略するが、プログラム記憶領域302には、ユーザ端末12で実行される様々な機能についてのプログラムも記憶される。
【0089】
また、データ記憶領域304には、端末DTLデータ304a、グループDTLデータ304b、ステータスリストデータ304c、コンテンツデータ304dおよび付加情報304eが記憶される。
【0090】
端末DTLデータ304aは、リストサーバ16から取得したユーザ端末12自身についてのダウンロードタスクリストのデータである。グループDTLデータ304bは、リストサーバ16から取得したユーザ端末12自身を含むグループについてのダウンロードタスクリストのデータである。
【0091】
ステータスリストデータ304cは、端末DTLデータ304aが示す端末DTLおよびグループDTLデータ304bが示すグループDTLに基づいて生成したタスク登録ステータスリストについてのデータである。コンテンツデータ304dは、コンテンツサーバ18から取得したコンテンツのデータである。付加情報304eは、コンテンツデータ304dに付加されたメッセージのデータまたはレイティングの情報である。
【0092】
また、データ記憶領域304には、タイマ304fが設けられる。このタイマ304fは、リビジョンサーバ20にダウンロードタスクリストが更新されたかどうかを問い合わせる時間間隔(この実施例では、60分)をカウントするためのタイマである。
【0093】
図示は省略するが、データ記憶領域304には、情報処理プログラムを実行するために必要な、他のデータが記憶されたり、他のタイマ(カウンタ)やフラグが設けられたりする。
【0094】
図5および図6図1に示したユーザ端末12のCPU12aのリスト生成処理を示すフロー図である。たとえば、CPU12aは、ユーザ端末12がスリープの状態になったときに、リスト生成処理を開始する。ただし、ユーザに指示された場合にも、CPU12aは、リスト生成処理を開始する。この場合には、後述するステップS1およびS3は省略される。
【0095】
図5に示すように、CPU12aは、リスト生成処理を開始すると、ステップS1で、タイマ304fをリセットおよびスタートする。次のステップS3では、所定時間(この実施例では、60分)を経過したかどうかを判断する。ここでは、CPU12aは、タイマ304fのカウント値が60分を経過したかどうかを判断する。ステップS3で“NO”であれば、つまり所定時間を経過していなければ、同じステップS3に戻る。
【0096】
一方、ステップS3で“YES”であれば、つまり所定時間を経過すれば、ステップS5で、リビジョンサーバ20にアクセスする。次のステップS7では、リビジョンサーバ20にダウンロードタスクリスト(この実施例では、端末DTLおよびグループDTL)の更新の有無を問い合わせる。そして、ステップS9で、リビジョンサーバ20からダウンロードタスクリストの更新の有無の通知を受信して、図6に示すステップS11に進む。
【0097】
図6に示すように、ステップS11では、ダウンロードタスクリストの更新が有るかどうかを判断する。ここでは、CPU12aは、リビジョンサーバ20から通知された更新情報が更新有りを示すかどうかを判断する。ステップS11で“NO”であれば、つまりダウンロードタスクリスト(端末DTLおよびグループDTLの両方)が更新されていなければ、そのまま図5に示したステップS1に戻る。ただし、この実施例では、リビジョンサーバ20から何ら応答が無い場合にも、ステップS11で“NO”と判断されるが、“YES”と判断されてもよい。
【0098】
一方、ステップS11で“YES”であれば、つまりダウンロードタスクリスト(端末DTLおよびグループDTLの少なくとも一方)が更新されていれば、ステップS13で、リストサーバ16にアクセスし、ステップS15で、リストサーバ16にダウンロードタスクリストの送信を要求する。そして、ステップS17で、リストサーバ16からのダウンロードタスクリストを取得する。つまり、CPU12aは、リストサーバ16から送信された端末DTLデータ304aおよびグループDTLデータ304bを受信してRAM12bに記憶する。この実施例では、ユーザ端末12は、端末DTLデータ304aおよびグループDTLデータ304bの両方を取得するようにしているが、更新されたデータのみを取得するようにしても良い。
【0099】
なお、ここでは、ユーザ端末12は、リストサーバ16にアクセスし、ダウンロードタスクリストを必ず取得できるように説明してあるが、リストサーバ16にアクセスできない場合やダウンロードタスクリストを取得できない場合には、ステップS13、S15およびS17の処理を繰り返し実行するようにしてよい。
【0100】
次のステップS19では、タスク登録ステータスリストを生成(更新)する。CPU12aは、リストサーバ16から取得した端末DTLデータ304aおよびグループDTLデータ304bを用いてタスク登録ステータスリストを生成し、RAM12bにステータスリストデータ304cを記憶する。そして、ステップS21で、リスト生成処理を終了するかどうかを判断する。ここでは、CPU12aは、ユーザ端末12を起動することが指示されたかどうかを判断する。ただし、ユーザ端末12がアクティブな状態でユーザの指示に応じてリスト生成処理を開始した場合には、ステップS21では、“YES”と判断される。
【0101】
ステップS21で“NO”であれば、つまりリスト生成処理を終了しない場合には、ステップS1に戻る。一方、ステップS21で“YES”であれば、つまりリスト生成処理を終了する場合には、そのままリスト生成処理を終了する。
【0102】
図7図1に示したユーザ端末12のCPU12aのコンテンツ取得処理を示すフロー図である。このコンテンツ取得処理は、所定時間(この実施例では、60分)毎に実行され、図5に示したリスト生成処理が実行されている場合には、並行して実行される。ただし、コンテンツ取得処理は、ユーザ端末12の起動時や終了時のような所定のタイミングで実行されてもよい。
【0103】
図7に示すように、CPU12aは、コンテンツ取得処理を開始すると、ステップS31で、取得するべきコンテンツがあるかどうかを判断する。ここでは、CPU12aは、ステータスリストデータ304cを参照して、状態情報のデータ値が“00”または“01”を示すダウンロードタスクがあるかどうかを判断する。
【0104】
ステップS31で“NO”であれば、つまり取得するべきコンテンツが無ければ、そのままコンテンツ取得処理を終了する。一方、ステップS31で“YES”であれば、つまり取得するべきコンテンツが有れば、ステップS33以降の処理を実行する。ただし、取得するべきコンテンツが複数有る場合には、各コンテンツについて、ステップS33以降の処理が実行される。
【0105】
ステップS33では、配信元のURLに従ってコンテンツサーバ18にアクセスする。ただし、コンテンツサーバ18にアクセスできない場合には、ステップS33の処理が繰り返し実行される。次のステップS35では、コンテンツサーバ18にコンテンツの送信を要求する。そして、ステップS37で、コンテンツサーバ18から送信されるコンテンツを取得(受信)する。つまり、CPU12aは、コンテンツデータ304dを受信し、RAM12bに記憶する。たとえば、コンテンツデータ304dは、パケット単位で送信される。
【0106】
続いて、ステップS39では、コンテンツの取得に成功したかどうかを判断する。つまり、CPU12aは、コンテンツデータ304dをすべて受信したかどうかを判断する。ステップS39で“YES”であれば、つまりコンテンツの取得を成功すれば、ステップS41で、当該コンテンツのダウンロードタスクに成功を記録する。つまり、ステップS41では、CPU12は、取得したコンテンツのダウンロードタスクに含まれる状態情報のデータ値を“10”に設定する。そして、ステップS43で、付加情報が有るかどうかを判断する。ステップS43で“NO”であれば、そのままコンテンツ取得処理を終了する。一方、ステップS43で“YES”であれば、つまり付加情報が有れば、ステップS45で、付加情報を取得して、コンテンツ取得処理を終了する。ステップS45では、CPU12aは、コンテンツサーバ18から付加情報304eを受信すると、この付加情報304eを先に取得したコンテンツに関連付けてRAM12bに記憶する。
【0107】
一方、ステップS39で“NO”であれば、つまりコンテンツの取得に成功していなければ、ステップS47で、コンテンツの取得に失敗したかどうかを判断する。ここでは、CPU12aは、コンテンツデータ304dをすべて受信する前に、通信の制限時間を超えてしまったり、コンテンツデータ304dの受信中に、何らかの要因で通信が切断されたりしたかどうかを判断する。
【0108】
ステップS47で“NO”であれば、つまりコンテンツの取得に失敗していなければ、コンテンツデータ304dの取得中(受信中)であると判断して、ステップS37に戻る。一方、ステップS47で“YES”であれば、つまりコンテンツの取得に失敗すれば、ステップS49で、当該コンテンツのダウンロードタスクに失敗を記録して、コンテンツ取得処理を終了する。つまり、ステップS49では、CPU12は、取得したコンテンツのダウンロードタスクに含まれる状態情報のデータ値を“01”に設定する。
【0109】
図8図1に示したユーザ端末12のCPU12aの全体処理の一例を示すフロー図である。ユーザがユーザ端末12の起動を指示すると、CPU12aは、全体処理を開始し、ステップS71で、ユーザ端末12を起動する。つまり、スリープの状態からアクティブな状態に移行される。次のステップS73では、ディスプレイにメニュー画面を表示する。そして、ステップS75で、新たに取得されたコンテンツが有るかどうかを判断する。
【0110】
ステップS75で“NO”であれば、つまり新たに取得されたコンテンツが無ければ、そのままステップS93に進む。一方、ステップS75で“YES”であれば、つまり新たに取得されたコンテンツが有れば、ステップS77以降の処理を実行する。ただし、新たに取得されたコンテンツが複数有る場合には、各コンテンツについてステップS77以降の処理が実行される。
【0111】
ステップS77では、新たに取得されたコンテンツのダウンロードタスクのタスクタイプがタイプ1であるかどうかを判断する。つまり、ユーザ端末12を所持しているユーザが自身のために取得することを決定したコンテンツであるかどうかが判断される。
【0112】
ステップS77で“YES”であれば、つまりタスクタイプがタイプ1であれば、そのままステップS93に進む。一方、ステップS77で“NO”であれば、つまりタスクタイプがタイプ1でなければ、ステップS79で、新たに取得されたコンテンツのダウンロードタスクのタスクタイプがタイプ2であるかどうかを判断する。つまり、ユーザ端末12を操作しているユーザ以外のユーザ(他人)から贈られたコンテンツであるかどうかが判断される。
【0113】
ステップS79で“YES”であれば、つまりタスクタイプがタイプ2であれば、ステップS81で、他人から贈られたコンテンツであることを通知する。つまり、ステップS81では、CPU12aは、他人から贈られたコンテンツであることのメッセージをディスプレイに表示する。
【0114】
続くステップS83では、メッセージがあるかどうかを判断する。つまり、CPU12aは、新たに取得されたコンテンツに関連付けられた付加情報304eが記憶されているかどうかを判断する。ステップS83で“NO”であれば、つまりメッセージが無ければ、そのままステップS93に進む。一方、ステップS83で“YES”であれば、つまりメッセージが有れば、ステップS85で、メッセージを通知して、ステップS93に進む。つまり、ステップS85では、CPU12aは、コンテンツの贈り主からのメッセージをディスプレイに表示する。
【0115】
また、ステップS79で“NO”であれば、つまりタスクタイプがタイプ3であれば、コンテンツサーバ18の管理者から配信されたコンテンツであると判断し、ステップS87で、当該管理者から配信されたコンテンツであることを通知する。つまり、ステップS87では、CPU12aは、管理者から配信されたコンテンツであることのメッセージをディスプレイに表示する。
【0116】
続くステップS89では、レイティングの情報が有るかどうかを判断する。つまり、CPU12aは、新たに取得されたコンテンツに関連付けられた付加情報304eが記憶されているかどうかを判断する。ステップS89で“NO”であれば、つまりレイティングの情報が無ければ、そのままステップS93に進む。一方、ステップS89で“YES”であれば、つまりレイティングの情報が有れば、ステップS91で、レイティングの情報をディスプレイに表示して、ステップS93に進む。詳細な説明は省略するが、その後、ユーザによって承認等の操作が行われる。
【0117】
ステップS93では、ユーザの操作に従って処理を実行する。たとえば、メニューで選択されたアプリケーションプログラムが開始されたり、アプリケーションにおける情報処理が実行されたりする。このアプリケーションには、ショッピングのアプリケーションも含まれる。したがって、このショッピングのアプリケーションが実行されることにより、ユーザ端末12は、ショッピングサーバ22にアクセスし、ユーザの指示に従って、コンテンツを検索したり、コンテンツを取得(購入)することを決定したり、メッセージを入力したりすることができる。
【0118】
続いて、ステップS95では、終了かどうかを判断する。ここでは、CPU12aは、ユーザによって終了の指示が入力されたかどうかを判断する。つまり、スリープの状態に移行するかどうかを判断するのである。ステップS91で“NO”であれば、つまり終了でなければ、ステップS89に戻る。一方、ステップS91で“YES”であれば、つまり終了であれば、全体処理を終了する。したがって、ユーザ端末12はスリープの状態に移行され、上述したように、リスト更新処理(図5および図6)が開始される。
【0119】
この実施例によれば、端末DTLとグループDTLを設けるので、グループを構成する複数のユーザ端末に共通に配信されるコンテンツについては、当該グループについてのグループDTLに登録すれば良く、各ユーザ端末の端末DTLに登録する必要がないため、すべてのダウンロードタスクリストをユーザ端末単位で管理する必要が無く、またダウンロードタスクの登録の手間を大幅に減らすことができる。
【0120】
また、この実施例によれば、ユーザ端末がダウンロードタスクリストを取得し、このダウンロードタスクリストから生成したタスク登録ステータスリストに従ってコンテンツをダウンロードするので、ユーザ端末におけるコンテンツの取得についてリストサーバは管理する必要が無く、このリストサーバ側の処理負荷を軽減することができる。
【0121】
さらに、この実施例では、グループDTLによってグループ毎に配信するコンテンツを管理することができるので、工場出荷前に、グループ単位でユーザ端末12にコンテンツをインストール(プリインストール)する必要が無い。たとえば、従前プリインストールしていたコンテンツを、ユーザ端末12の購入後にユーザによって取得させることができる。したがって、工場出荷前にグループ毎のユーザ端末12を用意する手間が無いため、ユーザ端末12の販売者(提供者)側の負担を大幅に減らすことができる。
【0122】
なお、この実施例では、ユーザ端末の一例としてゲーム機を挙げたが、これに限定される必要はない。ユーザ端末は、汎用のPC、フィーチャーフォンまたはスマートフォンでも良い。
【0123】
また、この実施例では、各種サーバを用途に分けて設けるようにしたが、リビジョンサーバを除いて、リストサーバ、コンテンツサーバおよびショッピングサーバを任意の2つまたは全部を1つのサーバにまとめるようにしてもよい。たとえば、リストサーバとコンテンツサーバとを1つにまとめて、ダウンロードタスクリストおよびコンテンツを配信するサーバとして機能させることができる。
【0124】
さらに、この実施例では、端末DTLおよびグループDTLをリストサーバで管理するようにしてあるが、これらを別のサーバで管理するようにしてもよい。このようにした場合であっても、すべてのダウンロードタスクリストをユーザ端末毎に管理する必要がないため、サーバ側の処理負荷を軽減することができる。
【0125】
さらにまた、この実施例では、ユーザ端末がダウンロードタスクリストを取得し、このダウンロードタスクリストに従ってコンテンツを取得するようにしたが、これに限定される必要はない。たとえば、リストサーバがダウンロードタスクリストに従ってコンテンツの配信指示をコンテンツサーバに与えて、ユーザ端末にコンテンツを配信するようにしてもよい。上述したように、リストサーバとコンテンツサーバを1つにまとめたサーバを設ける場合には、コンテンツの配信指示およびコンテンツの配信を1つのサーバで完結することができる。ただし、リストサーバの指示に従ってコンテンツを配信する場合には、リストサーバからユーザ端末にタスクタイプを通知する必要がある。これは、タスクタイプに応じてユーザ端末側での動作(挙動)が異なるからである。
【0126】
また、この実施例では、ユーザ端末毎に端末DTLやグループDTLを管理し、ユーザ端末に配信するようにしたが、これに限定される必要はない。たとえば、ユーザ毎のダウンロードタスクリストを管理するとともに、複数のユーザを分類したグループ単位のダウンロードリストを管理して、配信するようにしてもよい。この場合、ダウンロードタスクリストには、端末IDに代えて、ユーザIDまたはネットワークIDが付される。ただし、グループIDは、複数のユーザを分類したグループの識別情報である。この場合には、グループDTLに含まれる取得者IDとしてコンテンツを取得するべきユーザのユーザIDが記述される。このようにすれば、ユーザ端末を使用しているユーザを識別して、ユーザ毎に、ダウロードタスクリストの更新の有無を問い合わせたり、ダウロードタスクリストを取得したり、コンテンツを取得したりすることができる。たとえば、ユーザをグループに分類する場合には、ユーザが使用しているアプリケーション、ユーザの性別、年齢(年代)、趣味(趣向)などの種々の属性情報を用いて分類することができる。
【0127】
さらに、この実施例で示した具体的な数値は一例に過ぎず、実際の製品に応じて、適宜変更される。
【符号の説明】
【0128】
10 …情報処理システム
12 …ユーザ端末
16 …リストサーバ
18 …コンテンツサーバ
20 …リビジョンサーバ
22 …ショッピングサーバ
図1
図2
図3
図4
図5
図6
図7
図8