特許 7356536 コンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2023-09-26

(45)【発行日】2023-10-04

(54)【発明の名称】コンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバ

(51)【国際特許分類】

   A63F 13/77 20140101AFI20230927BHJP

   A63F 13/35 20140101ALI20230927BHJP

   A63F 13/49 20140101ALI20230927BHJP

   H04L 67/131 20220101ALI20230927BHJP

   H04L 67/30 20220101ALI20230927BHJP

【ＦＩ】

A63F13/77

A63F13/35

A63F13/49

H04L67/131

H04L67/30

【請求項の数】 9

(21)【出願番号】P 2022077161

(22)【出願日】2022-05-09

【審査請求日】2022-05-31

(73)【特許権者】

【識別番号】000233778

【氏名又は名称】任天堂株式会社

(73)【特許権者】

【識別番号】504440133

【氏名又は名称】株式会社ポケモン

(74)【代理人】

【識別番号】100090181

【弁理士】

【氏名又は名称】山田 義人

(74)【代理人】

【識別番号】100130269

【弁理士】

【氏名又は名称】石原 盛規

(74)【代理人】

【識別番号】100168217

【弁理士】

【氏名又は名称】大村 和史

(72)【発明者】

【氏名】富樫 紘希

(72)【発明者】

【氏名】太田 信之

【審査官】池田 剛志

(56)【参考文献】

【文献】特開２０２０－１９２０１２（ＪＰ，Ａ）

【文献】特開２０１９－１４６９９８（ＪＰ，Ａ）

【文献】特開２０１４－０２３８８１（ＪＰ，Ａ）

【文献】特開２０１８－２０２１８８（ＪＰ，Ａ）

【文献】特開２０２０－１９２０１３（ＪＰ，Ａ）

【文献】特開２０００－１８５１７８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ａ６３Ｆ １３／００－１３／９８

Ａ６３Ｆ ９／２４

(57)【特許請求の範囲】

【請求項1】

サーバと、当該サーバに接続可能な少なくとも１つの情報処理端末を含み、
前記サーバは、
複数種類のゲームで利用可能な少なくとも１つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、
前記コンテンツデータを管理するサーバ管理プログラムを実行する第１のプロセッサを備え、
前記コンテンツ記憶媒体に記憶される前記コンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、前記複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、前記複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有し、
前記情報処理端末は、
前記複数種類のゲームのいずれかである第１のゲームのセーブデータである第１セーブデータを記憶する第１セーブデータ記憶媒体と、
前記サーバと送受信する前記コンテンツを管理するクライアントプログラムを実行する第２のプロセッサを備え、
前記クライアントプログラムは、前記第２のプロセッサに、
前記第１セーブデータ記憶媒体から前記第１セーブデータを読み出させ、
当該第１セーブデータに基づいて、前記第１のゲームで用いられた少なくとも１つの第１のコンテンツについて、前記共通領域と、前記第１のゲームに対応する前記固有領域である第１固有領域とを少なくとも含む預入用コンテンツデータを生成させ、
生成された前記預入用コンテンツデータを前記サーバに送信させ、
前記サーバ管理プログラムは、前記第１のプロセッサに、
前記情報処理端末から前記第１のコンテンツに関する前記預入用コンテンツデータを受信した場合に、受信された前記預入用コンテンツデータに含まれる前記共通領域および前記第１固有領域を少なくとも含むコンテンツデータであって、かつ前記第１のコンテンツに関して前記第１固有領域以外の前記固有領域を有する前記コンテンツデータが前記コンテンツ記憶媒体に保持されている場合には当該保持された前記第１固有領域以外の前記固有領域をさらに含むコンテンツデータを、前記第１のコンテンツに関する最新の前記コンテンツデータとして前記コンテンツ記憶媒体に記憶させる、
コンテンツ保持システム。

【請求項2】

前記情報処理端末はさらに、
前記複数種類のゲームのいずれかである第２のゲームのセーブデータである第２セーブデータを記憶する第２セーブデータ記憶媒体を備え、
前記サーバ管理プログラムはさらに、前記第１のプロセッサに、
前記情報処理端末から、前記第２のゲームで用いられる前記第１のコンテンツの送信要求があった場合に、
当該第１のコンテンツの前記コンテンツデータに基づいて、前記共通領域を少なくとも含み、前記第２のゲームに対応する第２固有領域が保持されている場合は当該第２固有領域をさらに少なくとも含む引出用コンテンツデータを生成させ、
当該コンテンツデータを前記コンテンツ記憶媒体に保持させたまま、前記引出用コンテンツデータを前記情報処理端末に送信させ、
前記クライアントプログラムはさらに、前記第２のプロセッサに、
受信された前記引出用コンテンツデータに含まれる前記共通領域および前記第２固有領域に基づいて、前記第１のコンテンツが含まれるように前記第２セーブデータを更新して前記第２セーブデータ記憶媒体に記憶させる、請求項１記載のコンテンツ保持システム。

【請求項3】

前記引出用コンテンツデータは、前記第１のコンテンツに関する前記コンテンツデータにおける、前記共通領域および保持されているすべての前記固有領域を含む、請求項２記載のコンテンツ保持システム。

【請求項4】

前記クライアントプログラムはさらに、前記第２のプロセッサに、
受信された前記引出用コンテンツデータに前記第２固有領域が含まれない場合、当該第２固有領域に対応する前記パラメータ群を生成させて、前記第２セーブデータを更新して前記第２セーブデータ記憶媒体に記憶させる、請求項２記載のコンテンツ保持システム。

【請求項5】

前記サーバ管理プログラムは、前記第１のプロセッサにさらに、
前記情報処理端末から前記第１のコンテンツに関する前記預入用コンテンツデータを受信した場合に、前記第１のコンテンツが引出可能な状態として前記コンテンツデータを前記コンテンツ記憶媒体に記憶させ、
前記第１のコンテンツが引出可能な状態において前記情報処理端末から前記第１のコンテンツの送信要求があった場合に、前記コンテンツデータを前記コンテンツ記憶媒体に保持させたまま前記引出用コンテンツデータを前記情報処理端末に送信させ、かつ、前記第１のコンテンツが第２セーブデータに含まれるよう前記第２セーブデータ記憶媒体に記憶されている場合に前記第１のコンテンツが引出不可能な状態となるように前記コンテンツデータを保持させる、請求項２記載のコンテンツ保持システム。

【請求項6】

前記コンテンツデータの前記共通領域は、前記コンテンツ固有のＩＤを少なくとも含み、
前記サーバ管理プログラムは、前記第１のプロセッサにさらに、
前記情報処理端末から前記預入用コンテンツデータを受信した場合に、前記第１のコンテンツに前記ＩＤが無い場合には新規に前記ＩＤを付与した上で、前記コンテンツデータを前記コンテンツ記憶媒体に記憶させる、請求項１から５のいずれか記載のコンテンツ保持システム。

【請求項7】

前記預入用コンテンツデータは、前記複数種類のゲームのいずれかである第３のゲームに対応する前記固有領域である第３固有領域をさらに含む、請求項１または２記載のコンテンツ保持システム。

【請求項8】

情報処理装置のコンピュータに実行されるコンテンツ管理プログラムであって、
前記情報処理装置は、複数種類のゲームのいずれかである第１のゲームのセーブデータである第１セーブデータを記憶する第１セーブデータ記憶媒体と、前記複数種類のゲームのいずれかである第２のゲームのセーブデータである第２セーブデータを記憶する第２セーブデータ記憶媒体とを備え、
前記コンピュータに、
第１の指示入力に基づいて、
前記第１セーブデータ記憶媒体から、当該第１セーブデータを読み出させ、
当該第１セーブデータに基づいて、前記第１のゲームで用いられた少なくとも１つの第１のコンテンツについて、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、前記複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、前記複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域のうち、前記第１のゲームに対応する第１固有領域とを少なくとも含む預入用コンテンツデータを生成させ、
生成された前記預入用コンテンツデータをサーバに送信させ、
第２の指示入力に基づいて、
前記サーバに対して、前記複数種類のゲームのいずれかである第２のゲームで用いられる前記第１のコンテンツの送信要求を行わせ、
当該送信要求に応じて、当該第１のコンテンツに関して、前記共通領域と前記第２のゲームに対応する前記固有領域である第２固有領域とを含む引出用コンテンツデータを前記サーバから受信させ、
少なくとも前記引出用コンテンツデータに含まれる前記共通領域および前記第２固有領域に基づいて、前記第１のコンテンツが含まれるよう前記第２セーブデータを更新して前記第２セーブデータ記憶媒体に記憶させる、
コンテンツ管理プログラム。

【請求項9】

複数種類のゲームで利用可能な少なくとも１つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、
前記コンテンツデータを管理する管理プログラムを実行するプロセッサを備え、
前記コンテンツ記憶媒体に記憶される前記コンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、前記複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、前記複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有し、
前記管理プログラムを実行する前記プロセッサは、
情報処理端末から、第１のコンテンツについて、前記共通領域と、前記複数種類のゲームのいずれかである第１のゲームに対応する前記固有領域である第１固有領域とを少なくとも含む預入用コンテンツデータを受信し、
受信された前記預入用コンテンツデータに含まれる前記共通領域および前記第１固有領域を少なくとも含むコンテンツデータであって、かつ前記第１のコンテンツに関して前記第１固有領域以外の前記固有領域を有する前記コンテンツデータが前記コンテンツ記憶媒体に保持されている場合には当該保持された前記第１固有領域以外の前記固有領域をさらに含むコンテンツデータを、前記第１のコンテンツに関する最新の前記コンテンツデータとして前記コンテンツ記憶媒体に記憶させ、
前記情報処理端末から、前記複数種類のゲームのいずれかである第２のゲームで用いられる前記第１のコンテンツの送信要求があった場合に、
当該第１のコンテンツの前記コンテンツデータに基づいて、前記共通領域を少なくとも含み、前記第２のゲームに対応する第２固有領域が保持されている場合は当該第２固有領域をさらに少なくとも含む引出用コンテンツデータを生成し、
当該コンテンツデータを前記コンテンツ記憶媒体に保持させたまま、前記引出用コンテンツデータを前記情報処理端末に送信させる、
コンテンツ保持サーバ。

【発明の詳細な説明】

【技術分野】

【0001】

この発明はコンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバに関し、特にたとえば、ユーザが所有する複数のキャラクタから選択した一部のキャラクタを所定の情報処理に利用する、コンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバに関する。

【背景技術】

【0002】

この種のコンテンツ保持システムの一例が特許文献１に開示されている。この特許文献１には、ゲームＧ１とは種類の異なるゲームＧ２では、ゲームＧ１で利用されるキャラクタデータＤ１を利用することができる。この場合、ゲーム装置２は、第２サーバ５から、選択したキャラクタデータＤ２を受信し、記憶部２２に記憶する。キャラクタデータＤ２は、第２サーバ５に預けられる場合に、キャラクタデータＤ１に管理ＩＤを付与したキャラクタデータである。ゲーム装置２では、キャラクタデータＤ２を受信した際、記憶部２２に記憶されるキャラクタデータＤ２に、ゲームＧ２で利用される１以上のパラメータが含まれていない場合には、そのパラメータが自動的に付与される。

【先行技術文献】

【特許文献】

【0003】

【文献】特許第６７５１１８１号

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかし、特許文献１では、ゲームＧ２でゲームＧ１から預けたキャラクタデータすなわちコンテンツを引き出して利用しようとした場合にパラメータが欠けているときは当該パラメータが追加されるが、パラメータが追加された後のキャラクタデータでは元のゲームＧ１に戻して利用することが難しくなることが考えられる。

【0005】

それゆえに、この発明の主たる目的は、新規な、コンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバを提供することである。

【0006】

また、この発明の他の目的は、複数種類のゲームでコンテンツを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でコンテンツを保持することができる、コンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバを提供することである。

【課題を解決するための手段】

【0007】

（構成１）
構成１は、サーバと、当該サーバに接続可能な少なくとも１つの情報処理端末を含む、コンテンツ保持システムである。サーバは、複数種類のゲームで利用可能な少なくとも１つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、コンテンツデータを管理するサーバ管理プログラムを実行する第１のプロセッサを備え、コンテンツ記憶媒体に記憶されるコンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有している。情報処理端末は、複数種類のゲームのいずれかである第１のゲームのセーブデータである第１セーブデータを記憶する第１セーブデータ記憶媒体と、サーバと送受信するコンテンツを管理するクライアントプログラムを実行する第２のプロセッサを備え、クライアントプログラムは、第２のプロセッサに、第１セーブデータ記憶媒体から第１セーブデータを読み出させ、第１セーブデータに基づいて、第１のゲームで用いられた少なくとも１つの第１のコンテンツについて、共通領域と、第１のゲームに対応する固有領域である第１固有領域とを少なくとも含む預入用コンテンツデータを生成させ、生成された預入用コンテンツデータをサーバに送信させ、サーバ管理プログラムは、第１のプロセッサに、情報処理端末から第１のコンテンツに関する預入用コンテンツデータを受信した場合に、受信された預入用コンテンツデータに含まれる共通領域および第１固有領域を少なくとも含むコンテンツデータであって、かつ第１のコンテンツに関して第１固有領域以外の固有領域を有するコンテンツデータがコンテンツ記憶媒体に保持されている場合には当該保持された第１固有領域以外の固有領域をさらに含むコンテンツデータを、第１のコンテンツに関する最新のコンテンツデータとしてコンテンツ記憶媒体に記憶させる。

【0008】

構成１によれば、第１のゲームで使った共通領域と第１固有領域のみ更新されてサーバに保持されるので、他の固有領域を他のゲームで使うことが出来る。したがって、１つのコンテンツを複数種類のゲームで相互に利用することができる。つまり、複数種類のゲームでコンテンツを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でコンテンツを保持することができる。

【0009】

（構成２）
構成２は、上記構成１において、情報処理端末はさらに、複数種類のゲームのいずれかである第２のゲームのセーブデータである第２セーブデータを記憶する第２セーブデータ記憶媒体を備える。サーバ管理プログラムはさらに、第１のプロセッサに、情報処理端末から、第２のゲームで用いられる第１のコンテンツの送信要求があった場合に、当該第１のコンテンツのコンテンツデータに基づいて、共通領域を少なくとも含み、第２のゲームに対応する第２固有領域が保持されている場合は当該第２固有領域をさらに少なくとも含む引出用コンテンツデータを生成させ、当該コンテンツデータをコンテンツ記憶媒体に保持させたまま、引出用コンテンツデータを情報処理端末に送信させる。クライアントプログラムはさらに、第２のプロセッサに、受信された引出用コンテンツデータに含まれる共通領域および第２固有領域に基づいて、第１のコンテンツが含まれるように第２セーブデータを更新して第２セーブデータ記憶媒体に記憶させる。

【0010】

構成２によれば、第２のゲームで使う共通領域と第２の固有領域のみ第２のセーブデータに反映できるので、第２のゲームで使えない他の固有領域が含まれるコンテンツデータがサーバに保持されていても、第２のゲーム側で他の固有領域に対応する必要なくコンテンツを利用することができる。

【0011】

（構成３）
構成３は、上記構成２において、引出用コンテンツデータは、第１のコンテンツに関するコンテンツデータにおける、共通領域および保持されているすべての固有領域を含む。

【0012】

（構成４）
構成４は、上記構成２または上記構成３において、クライアントプログラムはさらに、第２のプロセッサに、受信された引出用コンテンツデータに第２固有領域が含まれない場合、当該第２固有領域に対応するパラメータ群を生成させて、第２セーブデータを更新して第２セーブデータ記憶媒体に記憶させる。

【0013】

（構成５）
構成５は、上記構成２から上記構成４までのいずれかにおいて、サーバ管理プログラムは、第１のプロセッサにさらに、情報処理端末から第１のコンテンツに関する預入用コンテンツデータを受信した場合に、第１のコンテンツが引出可能な状態としてコンテンツデータをコンテンツ記憶媒体に記憶させ、第１のコンテンツが引出可能な状態において情報処理端末から第１のコンテンツの送信要求があった場合に、コンテンツデータをコンテンツ記憶媒体に保持させたまま引出用コンテンツデータを情報処理端末に送信させ、かつ、第１のコンテンツが第２セーブデータに含まれるよう第２セーブデータ記憶媒体に記憶されている場合に第１のコンテンツが引出不可能な状態となるようにコンテンツデータを保持させる。

【0014】

（構成６）
構成６は、上記構成１から上記構成５までのいずれかにおいて、コンテンツデータの共通領域は、コンテンツ固有のＩＤを少なくとも含み、サーバ管理プログラムは、第１のプロセッサにさらに、情報処理端末から預入用コンテンツデータを受信した場合に、第１のコンテンツにＩＤが無い場合には新規にＩＤを付与した上で、コンテンツデータをコンテンツ記憶媒体に記憶させる。

【0015】

（構成７）
構成７は、上記構成１から上記構成６までのいずれかにおいて、預入用コンテンツデータは、複数種類のゲームのいずれかである第３のゲームに対応する固有領域である第３固有領域をさらに含む。

【0016】

構成７によれば、何らかの目的で特定のゲーム固有領域が必ず含まれるようにすることができる。

【0017】

（構成８）
構成８は、情報処理装置のコンピュータに実行されるコンテンツ管理プログラムである。情報処理装置は、複数種類のゲームのいずれかである第１のゲームのセーブデータである第１セーブデータを記憶する第１セーブデータ記憶媒体と、複数種類のゲームのいずれかである第２のゲームのセーブデータである第２セーブデータを記憶する第２セーブデータ記憶媒体とを備える。コンテンツ管理プログラムは、コンピュータに、第１の指示入力に基づいて、第１セーブデータ記憶媒体から、当該第１セーブデータを読み出させ、当該第１セーブデータに基づいて、第１のゲームで用いられた少なくとも１つの第１のコンテンツについて、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域のうち、第１のゲームに対応する第１固有領域とを少なくとも含む預入用コンテンツデータを生成させ、生成された預入用コンテンツデータをサーバに送信させ、第２の指示入力に基づいて、サーバに対して、複数種類のゲームのいずれかである第２のゲームで用いられる第１のコンテンツの送信要求を行わせ、当該送信要求に応じて、当該第１のコンテンツに関して、共通領域と第２のゲームに対応する固有領域である第２固有領域とを含む引出用コンテンツデータをサーバから受信させ、少なくとも引出用コンテンツデータに含まれる共通領域および第２固有領域に基づいて、第１のコンテンツが含まれるよう第２セーブデータを更新して第２セーブデータ記憶媒体に記憶させる。

【0018】

（構成９）
構成９は、複数種類のゲームで利用可能な少なくとも１つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、コンテンツデータを管理する管理プログラムを実行するプロセッサを備える、コンテンツ保持サーバである。コンテンツ記憶媒体に記憶されるコンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有している。管理プログラムを実行するプロセッサは、情報処理端末から、第１のコンテンツについて、共通領域と、複数種類のゲームのいずれかである第１のゲームに対応する固有領域である第１固有領域とを少なくとも含む預入用コンテンツデータを受信し、受信された預入用コンテンツデータに含まれる共通領域および第１固有領域を少なくとも含むコンテンツデータであって、かつ第１のコンテンツに関して第１固有領域以外の固有領域を有するコンテンツデータがコンテンツ記憶媒体に保持されている場合には当該保持された第１固有領域以外の固有領域をさらに含むコンテンツデータを、第１のコンテンツに関する最新のコンテンツデータとしてコンテンツ記憶媒体に記憶させ、情報処理端末から、複数種類のゲームのいずれかである第２のゲームで用いられる第１のコンテンツの送信要求があった場合に、当該第１のコンテンツのコンテンツデータに基づいて、共通領域を少なくとも含み、第２のゲームに対応する第２固有領域が保持されている場合は当該第２固有領域をさらに少なくとも含む引出用コンテンツデータを生成し、当該コンテンツデータをコンテンツ記憶媒体に保持させたまま、引出用コンテンツデータを情報処理端末に送信させる。

【0019】

第８構成および第９構成においても、上記第１構成と同様に、複数種類のゲームでコンテンツを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でコンテンツを保持することができる。

【発明の効果】

【0020】

この発明によれば、複数種類のゲームでコンテンツを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でコンテンツを保持することができる。

【0021】

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

【図面の簡単な説明】

【0022】

【図1】図１はコンテンツ保持システムの限定しない一例を示す図である。

【図2】図２は図１に示すゲーム装置の電気的な構成の限定しない一例を示すブロック図である。

【図3】図３は図１に示すコンテンツ保持サーバの電気的な構成の限定しない一例を示すブロック図である。

【図4】図４は図２に示す表示装置に表示されるゲーム選択画面の限定しない一例を示す図である。

【図5】図５は図２に示す表示装置に表示される移動画面の限定しない一例を示す図である。

【図6】図６はゲーム装置からコンテンツ保持サーバにキャラクタを預ける場合の過程の一例を説明するための図である。

【図7】図７はゲーム装置からコンテンツ保持サーバにキャラクタを預ける前のコンテンツ保持サーバで管理されるデータベースの一例を示す図である。

【図8】図８はゲーム装置からコンテンツ保持サーバにキャラクタを預ける場合にコンテンツ保持サーバで補完されたキャラクタデータの一例を示す図である。

【図9】図９はゲーム装置からコンテンツ保持サーバにキャラクタを預けた場合にコンテンツ保持サーバで管理されるデータベースの一例を示す図である。

【図10】図１０はコンテンツ保持サーバで保持されるキャラクタデータの詳細な内容の一例の一部を示す図である。

【図11】図１１はコンテンツ保持サーバで保持されるキャラクタデータの詳細な内容の一例の他の一部を示す図である。

【図12】図１２はコンテンツ保持サーバからゲーム装置にキャラクタを引き出す場合の過程の一例の一部を説明するための図である。

【図13】図１３はコンテンツ保持サーバからゲーム装置にキャラクタを引き出す場合の過程の一例の他の一部を説明するための図である。

【図14】図１４は図２に示すゲーム装置に内蔵されるＲＡＭのメモリマップの一例を示す図である。

【図15】図１５は図２に示すコンテンツ保持サーバに内蔵されるＲＡＭのメモリマップの一例を示す図である。

【図16】図１６は図２に示すゲーム装置に内蔵されるＣＰＵのデータ管理処理の一例の一部を示すフロー図である。

【図17】図１７は図２に示すゲーム装置に内蔵されるＣＰＵのデータ管理処理の他の一部であって、図１６に後続するフロー図である。

【図18】図１８は図２に示すゲーム装置に内蔵されるＣＰＵのデータ管理処理のその他の一部であって、図１７に後続するフロー図である。

【図19】図１９は図３に示すコンテンツ保持サーバに内蔵されるＣＰＵのデータ管理処理の一例を示すフロー図である。

【発明を実施するための形態】

【0023】

図１を参照して、限定しない一例のコンテンツ保持システム１０はゲーム装置１２を含み、ゲーム装置１２は、インターネットのようなネットワーク１４を介してコンテンツ保持サーバ（以下、単に「サーバ」という）１６と通信可能に接続される。

【0024】

ゲーム装置１２は、情報処理装置の一例であり、ゲーム専用機のみならず、ゲーム機能を備える各種の電子機器である。電子機器は、たとえば、スマートフォン、携帯電話機（フィーチャーフォン）、タブレットＰＣ、ノートＰＣなどである。ただし、携帯型の電子機器に限定される必要は無く、据置型のゲーム装置、アーケードゲーム装置、デスクトップＰＣなどの据置型の電子機器を用いることもできる。

【0025】

サーバ１６は、汎用のサーバである。サーバ１６は、内部メモリまたは外部に接続されたデータベースに、この実施例のゲーム装置１２でプレイされる仮想のゲームのゲームデータに含まれるキャラクタデータを、ゲーム装置１２のユーザないしプレイヤ（以下、単に「ユーザ」という）の情報と関連付けて記憶または保持（つまり、管理）する。

【0026】

図２は図１に示すゲーム装置１２の電気的な構成の限定しない一例を示すブロック図である。図２に示すように、ゲーム装置１２はＣＰＵ２０を含み、ＣＰＵ２０には、ＲＡＭ２２、フラッシュメモリ２４、第１通信モジュール２６、第２通信モジュール２８、入力装置３０、表示ドライバ３２およびＤ／Ａ変換器３４が接続される。また、表示装置３６が表示ドライバ３２に接続され、スピーカ３８がＤ／Ａ変換器３４に接続される。

【0027】

ＣＰＵ２０は、ゲーム装置１２の全体制御を司る。ただし、ＣＰＵ２０に代えて、ＣＰＵ機能、ＧＰＵ機能等の複数の機能を含むＳｏＣ（Ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ）を設けてもよい。ＲＡＭ２２は、揮発性記憶媒体であり、ＣＰＵ２０のワークメモリやバッファメモリとして使用される。フラッシュメモリ２４は、不揮発性記憶媒体であり、ゲームのようなアプリケーションのプログラムを記憶したり、各種のデータを記憶（セーブ）したりするために使用される。

【0028】

この実施例では、ゲームのアプリケーションのみならず、ゲームで利用されるキャラクタを管理するためのプログラム（後述する、「クライアント側データ管理プログラム」）も記憶される。この実施例では、キャラクタは、一例として、動物を模したモンスターのキャラクタである。

【0029】

なお、ゲーム装置１２では、文書作成アプリケーション、電子メールアプリケーション、お絵描きアプリケーション、文字練習用アプリケーション、語学トレーニングアプリケーション、学習アプリケーションなどの様々なアプリケーションも実行可能であり、これらのアプリケーションがフラッシュメモリ２４に記憶される場合もある。

【0030】

第１通信モジュール２６は、たとえばＩＥＥＥ８０２．１１．ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。したがって、たとえば、ＣＰＵ２０は、第１通信モジュール２６を用いて、アクセスポイントおよびインターネット（すなわち、ネットワーク１４）を介して他の機器（サーバ１６および他のゲーム装置など）との間でデータを送受信する。ただし、第１通信モジュール２６を用いて、他の機器との間で直接データを送受信することもできる。

【0031】

第２通信モジュール２８は、近距離無線通信を行う機能を有する。具体的には、第２通信モジュール２８は、所定の通信方式（たとえば、赤外線方式）により、他の機器（他のゲーム装置など）との間で赤外線信号の送受信を行う機能、および所定の通信プロトコル（たとえば、マルチリンクプロトコル）に従って、同種のゲーム装置との間で無線通信を行う機能を有する。したがって、たとえば、ＣＰＵ２０は、第２通信モジュール２８を用いて、同種の他のゲーム装置との間でデータを直接送受信することもできる。ただし、赤外線方式の近距離無線通信に代えて、Bluetooth（登録商標）のような他の無線通信規格に従う近距離無線通信を行うようにしてもよい。

【0032】

入力装置３０は、たとえば、ゲーム装置１２に設けられる各種の押しボタンないしスイッチであり、ユーザによって、メニュー選択やゲーム操作などの各種の操作に用いられる。ただし、入力装置３０としては、タッチパネルなどのポインティングデバイス、マイクおよびカメラなどの入力手段が、押しボタンないしスイッチに代えて、または、押しボタンないしスイッチとともに設けられてもよい。また、タッチパネルは、後述する表示装置３６に組み込まれる場合もある。この場合の表示装置３６は、タッチパネル一体型表示装置である。

【0033】

表示ドライバ３２は、ＣＰＵ２０の指示の下、表示装置３６にゲーム画像などの各種の画像（画面）を表示するために使用される。図示は省略するが、表示ドライバ３２は、ビデオＲＡＭ（ＶＲＡＭ）を内蔵している。表示装置３６は、ＬＣＤまたは有機ＥＬディスプレイである。

【0034】

Ｄ／Ａ変換器３４は、ＣＰＵ２０から与えられる音声データをアナログのゲーム音声に変換し、スピーカ３８に出力する。ただし、ゲーム音声は、ゲームのキャラクタないしオブジェクトの音声、効果音、音楽（ＢＧＭ）のようなゲームに必要な音を意味する。

【0035】

なお、図１に示すゲーム装置１２の電気的な構成は単なる一例であり、これに限定される必要はない。たとえば、第２通信モジュール２８は無くてもよい。

【0036】

図３は図１に示したサーバ１６の電気的な構成を示すブロック図である。図３に示すように、サーバ１６はＣＰＵ５０を含み、ＣＰＵ５０には、ＲＡＭ５２、ＨＤＤ５４、通信モジュール５６、入力装置５８および表示ドライバ６０が接続される。また、表示装置６２が表示ドライバ６０に接続される。

【0037】

ＣＰＵ５０は、サーバ１６の全体的な制御を司る。ＲＡＭ５２は、揮発性記憶媒体であり、ＣＰＵ５０のワークメモリやバッファメモリとして使用される。ＨＤＤ５４は、不揮発性記憶媒体であり、オペレーティングシステム（ＯＳ）および必要な制御プログラムを記憶するとともに、所定のデータを記憶または保持するために使用される。この実施例では、必要な制御プログラムはキャラクタを管理するためのプログラム（後述する、「サーバ側データ管理プログラム」）を含む。また、所定のデータとして、１または複数のゲームで利用されるキャラクタのキャラクタデータを管理するためのデータベース（以下、「キャラクタ管理ＤＢ」）５４ａおよび１または複数のゲームで利用されるキャラクタのキャラクタデータを保持するためのデータベース（以下、「キャラクタ情報ＤＢ」）５４ｂを含む。ただし、キャラクタ管理ＤＢ５４ａおよびキャラクタ情報ＤＢ５４ｂは、サーバ１６の外部に設けられてもよい。この場合、キャラクタ管理ＤＢ５４ａおよびキャラクタ情報ＤＢ５４ｂは、サーバ１６に直接接続されてもよいし、ネットワーク１４を介してサーバ１６と通信可能に設けられてもよい。

【0038】

通信モジュール５６は、有線または無線で、ＬＡＮに接続する機能を有する。したがって、サーバ１６は、ゲーム装置１２および他のゲーム装置とネットワーク１４を介して通信することができる。ただし、サーバ１６は、ゲーム装置１２および他のゲーム装置とネットワーク１４を介さずに直接通信することもできる。

【0039】

入力装置５８は、たとえば、キーボードおよびコンピュータマウスなどである。表示ドライバ６０は、ＣＰＵ５０の指示の下、表示装置６２に各種画面を表示するために使用される。表示ドライバ６０は、ビデオＲＡＭ（ＶＲＡＭ）を内蔵している。表示装置６２は、ＬＣＤまたは有機ＥＬディスプレイである。

【0040】

なお、図３に示すサーバ１６の電気的な構成は単なる一例であり、これに限定される必要はない。

【0041】

上述したコンテンツ保持システム１０では、ゲーム装置１２は、複数種類のゲームをプレイすることができ、或る種類のゲームをプレイすることにより取得したキャラクタ（コンテンツに相当する）を、種類の異なる他のゲームで利用することができる。

【0042】

キャラクタを種類の異なる他のゲームで利用する場合には、或るゲームで取得したキャラクタはサーバ１６に一旦預けられ、当該キャラクタは他のゲームで利用するためにサーバ１６から引き出される。この場合、預けたり引き出したりするキャラクタのキャラクタデータがゲーム装置１２とサーバ１６の間で送受信される。

【0043】

ただし、或る種類のゲームで取得したキャラクタを他の種類のゲームで利用するためにサーバ１６から引き出すだけでなく、同じ方法で、同じ種類のゲームで利用するためにサーバ１６から引き出すことも可能である。

【0044】

また、後述するように、サーバ１６はキャラクタのキャラクタデータを保持するため、サーバ１６からゲーム装置１２にキャラクタを引き出した場合であっても、サーバ１６に保持されているキャラクタデータが消去されることはない。

【0045】

また、或るゲームと他のゲームは、種類の異なるゲームであるが、いずれも、ユーザが仮想のゲーム空間で様々なキャラクタ（この実施例では、モンスターのキャラクタ）を収集（この実施例では、捕獲または取得）し、収集したキャラクタを他のキャラクタと対戦させることで育成するゲームである。一例として、種類の異なるゲームは、一部の内容が異なる作品またはシリーズのゲームである。

【0046】

以下、この明細書においては、１のユーザがキャラクタをサーバ１６に預けたりサーバ１６から引き出したりする場合について説明するが、複数のユーザが、それぞれ、キャラクタをサーバ１６に預けたりサーバ１６から引き出したりすることができる。つまり、サーバ１６では、ユーザ毎に、キャラクタが管理される。

【0047】

また、この明細書においては、ユーザが一台のゲーム装置１２を用いてキャラクタをサーバ１６に預けたり、サーバ１６から引き出したりする場合について説明するが、同じユーザＩＤを複数台のゲーム装置１２に登録している場合には、キャラクタをサーバ１６に預けるゲーム装置１２とキャラクタをサーバ１６から引き出すゲーム装置１２は異なるゲーム装置１２であってもよい。したがって、たとえば、携帯型のゲーム装置１２で預けたキャラクタをゲーム装置１２としても使用できるスマートフォンで引き出してゲームに利用することができる。これは一例であり、上述しように、使用可能なゲーム装置１２は様々である。

【0048】

図４はゲーム装置１２の表示装置３６に表示されるゲーム選択画面１００の限定しない一例を示す図である。ユーザは、キャラクタを預けたり引き出したりする場合には、ゲーム装置１２に記憶されたクライアント側のデータ管理アプリケーション（後述する「クライアント側データ管理プログラム３０２ｆ」を実行する。すると、預けるキャラクタを利用するゲームまたは引き出したキャラクタを利用するゲームを選択するためのゲーム選択画面１００が表示装置３６に表示される。

【0049】

図示は省略するが、メインメニュー画面では、ゲームをプレイすることが選択されたり、クライアント側のデータ管理アプリケーションを実行することが選択されたり、各種の設定を行うことが選択されたりする。

【0050】

ゲーム選択画面１００には、１または複数のアイコン（図４では、アイコン１０２、１０４、１０６）が表示され、１または複数のアイコンの下方に、３つのボタン１１０、１１２および１１２が表示される。

【0051】

アイコン１０２は、ゲームＡを選択するためのアイコンである。アイコン１０４は、ゲームＢを選択するためのアイコンである。アイコン１０６は、ゲームＣを選択するためのアイコンである。図示は省略するが、一例として、ゲーム選択画面１００でアイコン（ここでは、アイコン１０２、アイコン１０４またはアイコン１０６）がオンされると、オンされたアイコンに割り当てられたゲームが選択された状態となる。また、オンされたアイコンが再度オンされると、再度オンされたアイコンに割り当てられたゲームが選択された状態が解除される。

【0052】

ゲームＡ、ゲームＢおよびゲームＣは、ゲーム装置１２でプレイ可能なゲームであり、各セーブデータがゲーム装置１２のフラッシュメモリ２４に記憶されている。ゲームＡ、ゲームＢおよびゲームＣのゲームプログラムは、ゲーム装置１２に常に記憶されている必要はなく、プレイするときに、ゲーム装置１２に記憶されていればよい。

【0053】

セーブデータは、ゲームをプレイした場合に生成および更新されるゲームデータ、当該ゲームの種類を示す情報（たとえば、タイトル）、ゲームをプレイしたユーザを示す情報（たとえば、ユーザＩＤ）を含む。また、ゲームデータに、上記のように、収集したキャラクタについてのデータ（以下、「キャラクタデータ」という）が含まれる。

【0054】

この実施例では、セーブデータはゲーム装置１２の内部に設けられたフラッシュメモリ２４に記憶されるが、限定される必要はない。セーブデータはゲーム装置１２に外付けされたメモリに記憶されてもよい。外付けされたメモリとしては、ゲーム装置１２に着脱可能なＳＤカード、ＵＳＢメモリ、外付けＨＤＤを用いることができる。また、セーブデータは、クラウド上の所定のサーバに記憶されてもよい。

【0055】

ボタン１１０は、ゲームの選択を止めて、メインメニュー画面に戻るためのボタンである。ボタン１１２は、選択したゲームを確定するためのボタンである。ボタン１１２がオンされると、ゲーム装置１２はサーバ１６と連携し、ユーザの操作に従ってキャラクタを移動することができる。

【0056】

図５はゲーム装置１２の表示装置３６に表示される移動画面２００の限定しない一例を示す図である。移動画面２００は、ゲーム選択画面１００でボタン１１２がオンされ、キャラクタを移動するゲームが選択されたことに応じて表示装置３６に表示される。

【0057】

なお、図５では、ゲーム選択画面１００においてゲームＡが選択された場合についての移動画面２００の例が示される。

【0058】

図５に示すように、移動画面２００は、表示領域２０２および表示領域２０４を含む。表示領域２０２は、ゲーム装置１２側において、ゲーム選択画面１００で選択された仮想のゲーム（ここでは、ゲームＡ）で利用される１または複数のキャラクタのキャラクタ画像２０６を表示するための領域である。つまり、仮想のゲームのセーブデータに含まれるキャラクタデータに対応する１または複数のキャラクタのキャラクタ画像２０６が表示される。また、表示領域２０２の右上方に、ゲームの種類を示す文字列（ここでは、ゲームＡ）２０２ａが表示される。表示領域２０４は、サーバ１６において、預かっているキャラクタのキャラクタ画像２０６を表示するための領域である。ただし、表示領域２０２および表示領域２０４に表示されるキャラクタ画像２０６は、同じユーザが所有するキャラクタのキャラクタ画像２０６である。

【0059】

図示は省略するが、表示領域２０２および表示領域２０４に表示されるのは、一部のキャラクタのキャラクタ画像２０６であり、それぞれ、スクロールすることでユーザが所有する他のキャラクタのキャラクタ画像２０６を表示することができる。

【0060】

詳細な説明は省略するが、ゲーム装置１２で利用されるキャラクタを格納する複数の仮想のボックスおよびサーバ１６で預かっているキャラクタを格納する複数の仮想のボックスが設けられており、上記のように、スクロールすると、仮想のボックスが変更され、変更された仮想のボックスに格納された１または複数のキャラクタのキャラクタ画像２０６が表示される。キャラクタが仮想のボックスに格納されていない場合には、キャラクタ画像２０６は表示されない。また、仮想のボックスは、それぞれ、識別可能な情報（一例として、シリアル番号）が付されており、現在表示されている１または複数のキャラクタが格納されている、または、キャラクタが格納されていない、仮想のボックスのシリアル番号が、表示領域２０２および表示領域２０４の近傍に、それぞれ、表示される。一例として、表示領域２０２の上方の「ゲーム装置側」の文字列および表示領域２０４の上方の「サーバ側」の文字列の横に、それぞれ、シリアル番号が表示される。ただし、表示領域２０２および表示領域２０４は、個別にスクロールできる。また、一例として、ゲーム装置１２で利用されるキャラクタを格納する仮想のボックスのシリアル番号はユーザによって指定され、サーバ１６で預かっているキャラクタを格納する仮想のボックスのシリアル番号はサーバ１６（つまり、ＣＰＵ５０）によって指定される。

【0061】

また、図５に示すように、移動画面２００は、ボタン２１０、ボタン２１２およびボタン２１４を含む。図５に示す例では、ボタン２１０およびボタン２１２は表示領域２０２の下方に設けられ、ボタン２１４は表示領域２０４の下方に設けられる。ボタン２１０は、キャラクタの移動を終了して、ゲーム選択画面１００に戻るためのボタンである。ボタン２１２は、キャラクタの移動を終了して、メインメニューに戻るためのボタンである。ボタン２１４は、キャラクタを移動させた状態を保存するためのボタンである。

【0062】

さらに、図５に示すように、移動画面２００上には、指示画像２２０が表示され、ユーザは、指示画像２２０を移動させたり、キャラクタ画像２０６を選択したり、ボタン２１０、２１２、２１４をオンしたりすることができる。

【0063】

ユーザは、キャラクタをサーバ１６に預ける場合には、表示領域２０２に表示された１または複数のキャラクタ画像２０６を選択し、表示領域２０４に移動させる。たとえば、ユーザは、選択された１または複数のキャラクタ画像２０６をドラッグ＆ドロップする。この操作は、キャラクタを引き出す場合も同じである。一方、ユーザは、キャラクタをサーバ１６から引き出す場合には、表示領域２０４に表示された１または複数のキャラクタ画像２０６を選択し、表示領域２０２に移動させる。キャラクタ画像２０６を移動させ、保存することで、キャラクタの移動が確定する。

【0064】

ただし、保存せずに、ゲーム選択画面１００またはメインメニュー画面に戻った場合には、キャラクタ画像２０６を移動していた場合であっても、キャラクタの移動は確定しない。つまり、キャラクタの移動がキャンセルされる。

【0065】

また、ユーザは、選択された１または複数のキャラクタ画像２０６を再度選択すると、当該１または複数のキャラクタ画像２０６の選択された状態が解除される。ただし、これは一例であり、キャラクタ画像２０６が選択された状態を解除する方法は他の方法でもよい。

【0066】

図６－図９はゲーム装置１２で利用するキャラクタをサーバ１６に預ける場合の処理について説明するための図である。図１０および図１１はサーバ１６で保持または管理されるキャラクタデータのフォーマットを説明するための図である。図１２－図１３はサーバ１６に預けたキャラクタをゲーム装置１２で利用するために引き出す場合の処理について説明するための図である。

【0067】

以下、図６－図１３を参照しながら、キャラクタを預けたり引き出したりする場合の処理について説明する。ただし、分かり易く説明するために、図６－図９では、ゲーム装置１２においてゲームＡで利用した第１キャラクタおよび第２キャラクタをサーバ１６に預ける場合の処理について説明する。また、同様に、図１２－図１３では、サーバ１６に預けた第１キャラクタおよび第２キャラクタをゲーム装置１２においてゲームＢで利用するために引き出す場合の処理について説明する。

【0068】

ただし、第１キャラクタについては、ゲーム装置１２において過去にゲームＡで利用したことが無い場合について説明する。

【0069】

図６に示すように、ゲームＡで利用した第１キャラクタおよび第２キャラクタをサーバ１６に預ける場合、ゲーム装置１２では、クライアント側データ管理プログラム（「クライアント側アプリ」ともいう）が、ゲームＡのセーブデータから第１キャラクタのキャラクタデータおよび第２キャラクタのキャラクタデータを取得する。

【0070】

次に、クライアント側アプリは、サーバ１６で保存するために、第１キャラクタのキャラクタデータおよび第２キャラクタのキャラクタデータのフォーマットを変換する。フォーマットが変換されたキャラクタデータ（以下、「預入用キャラクタデータ」と呼ぶことがある）は、共通領域および仮想のゲーム（ここでは、ゲームＡ）の固有領域を有している。共通領域は、キャラクタをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームに共通して用いられる、キャラクタについてのパラメータ群を含む。ゲームの固有領域は、キャラクタをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含む。共通領域に含まれるパラメータ群および個別領域に含まれるパラメータ群については、後述する。

【0071】

なお、図６では、フォーマット変換後のキャラクタデータに対応するキャラクタを示すために、第１キャラクタおよび第２キャラクタを表記してあるが、後述するように、キャラクタの固有の識別情報は、共通領域に含まれる。

【0072】

クライアント側アプリは、フォーマットを変換した第１キャラクタの預入用キャラクタデータおよびフォーマットを変換した第２キャラクタの預入用キャラクタデータをサーバ１６に送信する。

【0073】

キャラクタがサーバ１６に預けられる場合、サーバ側データ管理プログラム（「サーバ側アプリ」ともいう）は、このキャラクタを管理するための固有の識別情報（以下、「ユニークＩＤ」という）を付与する。このユニークＩＤは、サーバ側アプリによって発行され、キャラクタに付与される。ゲーム側アプリで発行すると、ユーザが複数台のゲーム装置１２を使用する場合に、ユニークＩＤが重複してしまう不都合があるからである。ユニークＩＤは、サーバ１６でキャラクタを管理するためのユニークな情報である。ただし、一度サーバ１６に預けたことのあるキャラクタについては、ユニークＩＤが既に付与されているため、再度発行および付与されることはない。

【0074】

ここでは、第１キャラクタはサーバ１６に預けたことがあり、第２キャラクタはサーバ１６に預けたことがないものと仮定する。また、一度預けたことがあるキャラクタについては、キャラクタ管理ＤＢ５４ａに管理情報が記憶され、キャラクタ情報ＤＢ５４ｂにサーバ１６に預けられたキャラクタについてのキャラクタデータ（以下、「引出用キャラクタデータ」と呼ぶことがある）が記憶される。引出用キャラクタデータは、キャラクタ毎に生成され、キャラクタ情報ＤＢ５４ｂに記憶される。

【0075】

管理情報は、キャラクタを預けたユーザのユーザＩＤを含み、このユーザＩＤに対応付けられた、当該キャラクタのユニークＩＤ、当該キャラクタが格納された仮想のボックスの番号、および、引き出し可能かどうかを示す情報（以下、「フラグ情報」という）をさらに含む。フラグ情報は、対応するキャラクタがサーバ１６に預けられている場合には、「true（つまり、引き出し可能）」に設定され、対応するキャラクタがサーバ１６に預けられていない場合には、「false（つまり、引き出し不可）」に設定される。引出用キャラクタデータについては、後で詳細に説明する。

【0076】

第１キャラクタおよび第２キャラクタをサーバ１６に預ける前では、図７に示すように、キャラクタ情報ＤＢ５４ｂにおいて、第１のキャラクタの引出用キャラクタデータは保持されているが、第２のキャラクタの引出用キャラクタデータは保持されていない。

【0077】

図７に示すように、第１キャラクタの引出用キャラクタデータは、共通領域と、ゲームＢの固有領域およびゲームＣの固有領域を有している。後述するように、引出用キャラクタデータは、共通領域と、１または複数の固有領域を含む作品別領域を有している（図１０参照）。図７に示す例では、第１キャラクタの引出用キャラクタデータは、作品別領域に、ゲームＢの固有領域およびゲームＣの固有領域を有している。したがって、第１キャラクタは、ゲーム装置１２において、ゲームＢおよびゲームＣのそれぞれで利用されたことがあることが分かる。また、第１キャラクタは、ゲームＡで利用されているが、ゲームＡで利用された後にサーバ１６に預けられたことはない。上述したように、第２キャラクタは、サーバ１６に預けられたことが無いため、引出用キャラクタデータはキャラクタ情報ＤＢ５４ｂに記憶（または、保持）されていない。また、第２キャラクタについては、管理情報もキャラクタ管理ＤＢ５４ａに記憶されていない。

【0078】

図８に示すように、サーバ側アプリは、ゲーム装置１２から受信した第１キャラクタの預入用キャラクタデータで、キャラクタ情報ＤＢ５４ｂに記憶された第１キャラクタの引出用キャラクタデータを補完する。このとき、第１キャラクタの引出用キャラクタデータに含まれる共通領域のパラメータ群は、受信した預入用キャラクタデータに含まれる共通領域のパラメータ群で上書き（つまり、更新）される。

【0079】

図示は省略するが、第１キャラクタが過去にゲームＡで利用されていた場合には、引出用キャラクタデータには、ゲームＡの固有領域も含まれるため、この場合には、ゲームＡの固有領域のパラメータ群が、受信した預入用キャラクタデータに含まれるゲームＡの固有領域のパラメータ群で上書きされる。

【0080】

また、サーバ側アプリは、ゲーム装置１２から第２キャラクタの預入用キャラクタデータを受信すると、第２キャラクタに対してユニークＩＤを発行および付与して、第２キャラクタの引出用キャラクタデータを生成する。

【0081】

サーバ側アプリは、第１キャラクタの引出用キャラクタデータを補完し、第２キャラクタの引出用キャラクタデータを生成すると、第１キャラクタの引出用キャラクタデータおよび第２キャラクタの引出用キャラクタデータをキャラクタ情報ＤＢ５４ｂに記憶する。つまり、図９に示すように、サーバ側アプリは、補完した第１キャラクタの引出用キャラクタデータをキャラクタ情報ＤＢ５４ｂに上書きし、生成した第２キャラクタの引出用キャラクタデータをキャラクタ情報ＤＢ５４ｂに新規に登録する。

【0082】

詳細な説明は省略するが、サーバ側アプリは、第１キャラクタの引出用キャラクタデータおよび第２キャラクタの引出用キャラクタデータをキャラクタ情報ＤＢ５４ｂに記憶するときに、キャラクタ管理ＤＢ５４ａに記憶される第１キャラクタの管理情報を更新し、第２キャラクタの管理情報を生成して、キャラクタ管理ＤＢ５４ａに記憶する。

【0083】

図１０は、図９に示したように、キャラクタ情報ＤＢ５４ｂに記憶された第１キャラクタの引出用キャラクタデータの一例を示す。図１０に示すように、第１キャラクタの引出用キャラクタデータは、共通領域および作品別領域を含む。

【0084】

共通領域には、第１キャラクタについての共通の情報として、ユニークＩＤ、モンスター種別番号、経験値、特性番号、性別、ＨＰ決定用パラメータＡ、攻撃決定用パラメータＡ、防御決定用パラメータＡ、速さ決定用パラメータＡ、ニックネーム、ＨＰ決定用パラメータＢ、攻撃決定用パラメータＢ、防御決定用パラメータＢ、速さ決定用パラメータＢ、捕まえたゲームのバージョン、プレイヤ名、獲得日および獲得場所が記載される。

【0085】

ユニークＩＤは、当該キャラクタ（ここでは、「第１キャラクタ」）に付与された固有のＩＤであり、サーバ側アプリによって付与される。モンスター種別番号は、当該キャラクタの種別を示す番号である。経験値は、戦闘の経験値であり、経験値が上がると、当該キャラクタのレベルが上昇される。特性番号は、当該キャラクタに設定された特性を識別するための番号である。性別は、当該キャラクタの性別であり、オス、メスまたは性別不明のいずれかである。

【0086】

ＨＰ決定用パラメータＡは、戦闘の結果において、当該キャラクタのＨＰを決定するためのパラメータである。ただし、ＨＰは、当該キャラクタの体力を示すヒットポイントである。攻撃決定用パラメータＡは、戦闘の結果において、当該キャラクタの攻撃力を決定するためのパラメータである。防御決定用パラメータＡは、戦闘の結果において、当該キャラクタの防御力を決定するためのパラメータである。速さ決定用パラメータＡは、戦闘の結果において、当該キャラクタの攻撃の素早さを決定するためのパラメータである。ＨＰ決定用パラメータＡ、攻撃決定用パラメータＡ、防御決定用パラメータＡ、速さ決定用パラメータＡは、少なくともいずれかのゲーム内において、戦闘回数に応じて所定の上限まで上昇するように設定されていてもよい。

【0087】

ニックネームは、ユーザが当該キャラクタに付けたニックネームである。ＨＰ決定用パラメータＢは、キャラクタ毎に予め設定された、当該キャラクタのＨＰを決定するためのパラメータである。攻撃決定用パラメータＢは、キャラクタ毎に予め設定された、当該キャラクタの攻撃力を決定するためのパラメータである。防御決定用パラメータＢは、キャラクタ毎に予め設定された、当該キャラクタの防御力を決定するためのパラメータである。速さ決定用パラメータＢは、キャラクタ毎に予め設定された、当該キャラクタの攻撃の素早さを決定するためのパラメータである。ＨＰ決定用パラメータＢ、攻撃決定用パラメータＢ、防御決定用パラメータＢ、速さ決定用パラメータＢは、少なくともいずれかのゲーム内において、初めて当該キャラクタを入手した際に所定の範囲内においてランダムな値が設定され、変動しないように設定されていてもよい。

【0088】

少なくともいずれかのゲーム内において、キャラクタの最大ＨＰは、少なくともモンスターの種別によってゲーム内で予め定められた固定値、ＨＰ決定用パラメータＡ、ＨＰ決定用パラメータＢを加算した値がゲーム内の当該キャラクタの最大ＨＰとされるようにしてもよい。攻撃、防御、速さについても同様である。

【0089】

捕まえたゲームのバージョンは、当該キャラクタを捕獲または取得したゲームのバージョン（または、種類）を識別するための情報である。プレイヤ名は、当該キャラクタを捕獲または取得したユーザの名称である。獲得日は、当該キャラクタを捕獲または取得した日付（実施例では、年月日）である。獲得場所は、当該キャラクタを捕獲または取得した仮想空間における場所である。

【0090】

図１１は図１０に示した作品別領域の具体的な内容の限定しない一例を示す。作品領域は、キャラクタが過去に利用された１または複数のゲームの固有領域をゲームの種類毎に含む。図１１に示す例では、ゲームＡの固有領域、ゲームＢの固有領域およびゲームＣの固有領域を含む。

【0091】

ゲームＡの固有領域には、ゲームＡにおける第１キャラクタの固有の情報として、所持技、所持技の残り回数、技回数アップ使用回数、固有イベント遊び度および捕獲アイテム種類が記載される。

【0092】

所持技は、当該キャラクタ（ここでは、「第１キャラクタ」）がゲームＡにおいて使用可能な技の種類である。所持技の残り回数は、当該キャラクタがゲームＡにおいて使用可能な技の種類毎の使用可能な回数である。技回数アップ使用回数は、当該キャラクタの技の使用可能な回数を増やすアイテムを使用可能な回数である。固有イベント遊び度は、当該キャラクタを用いて固有イベントをプレイした回数または度合である。捕獲アイテム種類は、当該キャラクタが獲得または取得したアイテムの種類である。

【0093】

ゲームＢの固有領域には、ゲームＢにおける第１キャラクタの固有の情報として、特殊個体フラグ、サイズ、所持技、所持技の残り回数、ＨＰ決定用パラメータＣ、攻撃決定用パラメータＣ、防御決定用パラメータＣ、速さ決定用パラメータＣおよび捕獲アイテム種類が記載される。

【0094】

特殊個体フラグは、当該キャラクタ（ここでは、「第１キャラクタ」）が特殊個体であることを示すフラグ情報である。この実施例では、特殊個体のキャラクタは、仮想空間において周辺に存在する他のキャラクタよりも大きく、レベルが高く、強いキャラクタを意味する。フラグ情報は、当該キャラクタが特殊個体であるため、「true」に設定される。サイズは、仮想空間における当該キャラクタの大きさ（この実施例では、高さおよび重さ）である。所持技は、当該キャラクタがゲームＢにおいて使用可能な技の種類である。所持技の残り回数は、当該キャラクタがゲームＢにおいて使用可能な技の種類毎の使用可能な回数である。

【0095】

ＨＰ決定用パラメータＣは、戦闘の結果において、当該キャラクタのＨＰを決定するためのパラメータである。攻撃決定用パラメータＣは、戦闘の結果において、当該キャラクタの攻撃力を決定するためのパラメータである。防御決定用パラメータＣは、戦闘の結果において、当該キャラクタの防御力を決定するためのパラメータである。速さ決定用パラメータＣは、戦闘の結果において、当該キャラクタの攻撃の素早さを決定するためのパラメータである。捕獲アイテム種類は、当該キャラクタを捕獲したときに使用したアイテムの種類である。

【0096】

ゲームＢにおいて、キャラクタの最大ＨＰは、共通領域内のＨＰ決定用パラメータＡ、ＨＰ決定用パラメータＢを用いずに、モンスターの種別によってゲームＢ内で予め定められた固定値と、ゲームＢ内で用いられるＨＰ決定用パラメータＣを加算した値が最大ＨＰとされるようにしてもよい。攻撃、防御、速さについても同様である。

【0097】

このとき、ＨＰ決定用パラメータＣ、攻撃決定用パラメータＣ、防御決定用パラメータＣおよび速さ決定用パラメータＣの初期値を、それぞれ、共通領域に記載された、ＨＰ決定用パラメータＢ、攻撃決定用パラメータＢ、防御決定用パラメータＢおよび速さ決定用パラメータＢに対応させることで、他のゲームでもゲームＢで入手したキャラクタを利用することができる。ゲームＢにおいて連動していてもよいし、他のゲームで初めて当該キャラクタを利用する場合に補完されるようにしてもよい。また、第１キャラクタをゲームＢで入手して他のゲームで使用していない場合、ＨＰ決定用パラメータＡ、攻撃決定用パラメータＡ、防御決定用パラメータＡおよび速さ決定用パラメータＡはすべて０のままである。

【0098】

ゲームＣの固有領域には、ゲームＣにおける第１キャラクタの固有の情報として、所持技、所持技の残り回数、技回数アップ使用回数、固有イベント遊び度および捕獲アイテム種類が記載される。各固有の情報は、ゲームＡの固有領域で説明した内容と同じであるため、重複した説明は省略する。

【0099】

なお、簡単に説明するために、図１０および図１１では、共通領域および各固有領域に含まれるパラメータ群の一部を示してある。

【0100】

図１２および図１３を用いて、第１キャラクタおよび第２キャラクタをゲームＢで利用するために引き出す場合の処理について説明する。ゲーム選択画面１００でゲームＢが選択され、移動画面２００が表示されるとき、ゲーム装置１２の要求に応じて、サーバ１６は預かっている１または複数のキャラクタについての引出用キャラクタデータを要求元のゲーム装置１２にすべて送信する。したがって、サーバ１６は預かっていない１または複数のキャラクタについての引出用キャラクタデータはゲーム装置１２に送信しない。

【0101】

移動画面２００では、表示領域２０４に、サーバ１６で預かっている１または複数のキャラクタを表示することができる。上述したように、第１キャラクタおよび第２キャラクタはサーバ１６に預けられているため、移動画面２００では、第１キャラクタのキャラクタ画像２０６および第２キャラクタのキャラクタ画像２０６が表示領域２０４に表示することができる。

【0102】

この場合、クライアント側アプリは、第１キャラクタについての引出用キャラクタデータから共通領域とゲームＢで利用するためのゲームＢの固有領域を抽出し、抽出した共通領域と固有領域すなわち第１キャラクタのキャラクタデータに基づいて移動画面２００の表示領域２０４に第１キャラクタのキャラクタ画像２０６を表示する。

【0103】

また、クライアント側アプリは、第２キャラクタについての引出用キャラクタデータから共通領域を抽出し、ゲームＢで利用するためのゲームＢの固有領域をデフォルトで生成し、抽出した共通領域と生成した固有領域すなわち第２キャラクタのキャラクタデータに基づいて移動画面２００の表示領域２０４に第２キャラクタのキャラクタ画像２０６を表示する。上述したように、第２キャラクタは、ゲームＡで利用されただけで、他のゲーム（ここでは、ゲームＢ）では利用されたことがないため、引出用キャラクタデータには、ゲームＢの固有領域は含まれていない。したがって、移動画面２００に第２キャラクタのキャラクタ画像２０６を表示し、さらには、ゲームＢで利用するために、ゲームＢの固有領域をデフォルトで生成するようにしてある。

【0104】

さらに、クライアント側アプリは、第１キャラクタのキャラクタ画像２０６および第２キャラクタのキャラクタ画像２０６が表示領域２０２に移動された状態で保存が実行されると、つまり、第１キャラクタおよび第２キャラクタをゲームＢで利用するために引き出すことが決定されると、第１キャラクタおよび第２キャラクタがゲームＢのセーブデータに含められる。具体的には、図１３に示すように、クライアント側アプリは、第１キャラクタのキャラクタデータおよび第２キャラクタのキャラクタデータをゲームＢで利用するためのフォーマットに変換する。そして、クライアント側アプリは、変換した第１キャラクタのキャラクタデータおよび第２キャラクタのキャラクタデータを、ゲームＢで利用している他のキャラクタのキャラクタデータとともに保存する。つまり、第１キャラクタのキャラクタデータおよび第２キャラクタのキャラクタデータを含むゲームＢのセーブデータがフラッシュメモリ２４に記憶（上書き）される。このようにして、第１キャラクタおよび第２キャラクタがサーバ１６からゲーム装置１２に引き出される。

【0105】

つまり、ゲーム装置１２では、クライアント側アプリは、キャラクタを引き出すときには、過去に利用したことのあるゲームで利用する場合には、引出用キャラクタデータから、共通領域とそのゲームの固有領域を抽出し、過去に利用したことのないゲームで利用する場合には、引出用キャラクタデータから、共通領域を抽出し、そのゲームの固有領域をデフォルトで生成する。

【0106】

このように、引き出したキャラクタを、過去に利用したことのあるゲームで利用する場合には、引出用キャラクタデータから、共通領域とそのゲームの固有領域を抽出するので、他のゲームの固有領域が引出用キャラクタデータに含まれていても、引き出したキャラクタを利用するゲーム側で他のゲームの固有領域に対応する必要はない。

【0107】

ゲームの固有領域をデフォルトで生成する場合には、固有領域に含まれるパラメータ群を０等の適切なデフォルト値に設定する。または、他の固有領域を参照して、互換性のあるパラメータが発見された場合には、そのパラメータを使用するようにしてもよい。たとえば、互換性のあるパラメータは、捕獲アイテム種類である。

【0108】

また、クライアント側アプリは、第１キャラクタおよび第２キャラクタを引き出すと、第１キャラクタおよび第２キャラクタを引き出し不可にすることを、サーバ１６（すなわち、サーバ側アプリ）に通知する。

【0109】

したがって、サーバ１６では、サーバ側アプリは、引き出し不可にすることを通知したゲーム装置１２のユーザのユーザＩＤが記載された第１キャラクタおよび第２キャラクタの管理情報に含まれるフラグ情報を「false（つまり、引き出し不可）」に設定する。

【0110】

図１４は図２に示したゲーム装置１２のＲＡＭ２２のメモリマップ３００の一例を示す図である。図１４に示すように、ＲＡＭ２２は、プログラム記憶領域３０２およびデータ記憶領域３０４を含む。プログラム記憶領域３０２には、通信プログラム３０２ａ、画像表示プログラム３０２ｂ、ゲームＡプログラム３０２ｃ、ゲームＢプログラム３０２ｄ、ゲームＣプログラム３０２ｅおよびクライアント側データ管理プログラム３０２ｆなどが記憶される。

【0111】

通信プログラム３０２ａは、第１通信モジュール２６を用いて他の機器（この実施例では、サーバ１６および他のゲーム装置など）と通信したり、第２通信モジュール２８を用いて無線ＬＡＮを介して他の機器（他のゲーム装置など）と通信したりするためのプログラムである。

【0112】

画像表示プログラム３０２ｂは、ゲーム画像（上記の各種の画面１００、２００など）のデータ（ゲーム画像データ）を生成し、生成したゲーム画像データを表示装置３６に出力するためのプログラムである。したがって、ゲーム画像データに対応するゲーム画像が表示装置３６に表示される。

【0113】

ゲームＡプログラム３０２ｃは、ゲームＡのアプリケーションプログラムである。ゲームＢプログラム３０２ｄは、ゲームＢのアプリケーションプログラムである。ゲームＣプログラム３０２ｅは、ゲームＣのアプリケーションプログラムである。

【0114】

クライアント側データ管理プログラム３０２ｆは、クライアントすなわちゲーム装置１２側でキャラクタデータを管理するためのアプリケーションプログラム（すなわち、クライアント側アプリ）であり、具体的には、後述するクライアント側のデータ管理処理（図１６－図１８参照）を実行するためのプログラムである。

【0115】

図示は省略するが、プログラム記憶領域３０２には、ゲームデータをフラッシュメモリ２４に保存するためのプログラム、ゲームに必要な音を生成および出力するための音出力プログラムなどの他のプログラムも記憶される。

【0116】

なお、ゲームＡプログラム３０２ｃ、ゲームＢプログラム３０２ｄおよびゲームＣプログラム３０３ｅは、常に、ＲＡＭ２２に記憶されている必要はなく、ゲームＡ、ゲームＢまたはゲームＣをプレイする場合に、フラッシュメモリ２４、ゲーム装置１２に装着可能な他の記憶媒体、または、ネットワーク１４から取得されればよい。

【0117】

データ記憶領域３０４には、操作入力データ３０４ａ、セーブデータ３０４ｂ、引出用キャラクタデータ３０４ｃ、表示用キャラクタデータ３０４ｄおよび移動候補キャラクタデータ３０４ｅなどが記憶される。

【0118】

操作入力データ３０４ａは、入力装置３０から入力された操作データである。操作データは、ＣＰＵ２０の処理に使用されると、消去される。

【0119】

セーブデータ３０４ｂは、ゲーム選択画面１００で選択されたゲーム（この実施例では、ゲームＡ、ゲームＢまたはゲームＣ）のセーブデータであって、フラッシュメモリ２４から読み出される。また、キャラクタを引き出した場合には、セーブデータ３０４ｂは更新された後に、フラッシュメモリ２４に記憶（または、上書き）される。

【0120】

引出用キャラクタデータ３０４ｃは、移動画面２００を表示装置３６に表示する場合に、サーバ１６から送信された１または複数のキャラクタの各々についての引出用キャラクタデータである。

【0121】

表示用キャラクタデータ３０４ｄは、移動画面２００の表示領域２０２に表示される１または複数のキャラクタ画像２０６の各々に対応するキャラクタデータと、移動画面２００の表示領域２０４に表示される１または複数のキャラクタのキャラクタ画像２０６の各々に対応するキャラクタデータである。ただし、キャラクタ画像２０６に対応するキャラクタデータは、表示領域２０２に表示する（すなわち、ゲーム装置１２に格納されている）こと、または、表示領域２０４に表示する（すなわち、サーバ１６に預けられている）ことが識別可能に分類されている。

【0122】

移動画面２００の表示領域２０２に表示される１または複数のキャラクタのキャラクタデータは、ゲーム選択画面１００で選択されたゲーム（この実施例では、ゲームＡ、ゲームＢまたはゲームＣ）のセーブデータ３０４ｂから取得した１または複数のキャラクタのキャラクタデータである。

【0123】

また、移動画面２００の表示領域２０４に表示される１または複数のキャラクタのキャラクタデータは、サーバ１６から送信された１または複数のキャラクタの各々についての引出用キャラクタデータであり、移動画面２００を最初に表示するとき、引出用キャラクタデータ３０４ｃがコピーされる。ただし、コピーされるのは、１または複数のキャラクタの各々についての引出用キャラクタデータのうち、共通領域と、ゲーム選択画面１００で選択されたゲームの固有領域である。ゲーム選択画面１００で選択されたゲームの固有領域が引出用キャラクタデータに含まれていないキャラクタについては、ゲーム選択画面１００で選択されたゲームの固有領域がデフォルトで生成される。

【0124】

移動画面２００においてキャラクタ画像２０６が表示領域２０２と表示領域２０４の間で移動されると、表示用キャラクタデータ３０４ｄにおいて、移動されたキャラクタについての表示領域２０２または表示領域２０４の分類が変更される。

【0125】

移動候補キャラクタデータ３０４ｅは、移動画面２００において表示領域２０２と表示領域２０４の間で移動されたキャラクタの識別情報および移動後の表示領域２０２または表示領域２０４の識別情報のデータである。ここで、キャラクタの識別情報は、ユニークＩＤであるが、ユニークＩＤが付与されていないキャラクタについては、当該キャラクタの預入用キャラクタデータ自体である。また、表示領域２０２の識別情報はゲーム装置１２側であることとゲーム装置１２側の仮想のボックスの番号であり、表示領域２０４の識別情報はサーバ１６側であることとサーバ１６側の仮想のボックスの番号である。ただし、キャラクタが元の表示領域２０２または表示領域２０４に移動される（つまり、戻される）と、当該キャラクタについての移動候補キャラクタデータ３０４ｅは消去される。

【0126】

移動画面２００において、保存が実行されると、表示領域２０４から表示領域２０２に移動されたキャラクタのキャラクタデータが、選択されているゲームのセーブデータに含めて保存される。また、移動画面２００において、保存が実行されると、表示領域２０２から表示領域２０４に移動されたキャラクタのキャラクタデータがサーバ１６に送信され、当該キャラクタデータは、選択されているゲームのセーブデータから削除される。

【0127】

図示は省略するが、データ記憶領域３０４には、データ管理処理に必要な他のデータが記憶されたり、データ管理処理に必要なフラグおよびカウンタ（タイマ）が設けられたりする。

【0128】

図１５は図３に示したサーバ１６のＲＡＭ５２のメモリマップ５００の限定しない一例を示す図である。図１５に示すように、ＲＡＭ５２は、プログラム記憶領域５０２およびデータ記憶領域５０４を含む。プログラム記憶領域５０２には、通信プログラム５０２ａおよびサーバ側データ管理プログラム５０２ｂなどが記憶される。

【0129】

通信プログラム５０２ａは、通信モジュール５６を用いて他の機器（この実施例では、ゲーム装置１２および他のゲーム装置など）と通信するためのプログラムである。

【0130】

サーバ側データ管理プログラム５０２ｂは、サーバ１６側でキャラクタデータを管理するためのアプリケーションプログラム（すなわち、サーバ側アプリ）であり、具体的には、後述するサーバ側のデータ管理処理（図１９参照）を実行するためのプログラムである。

【0131】

図示は省略するが、プログラム記憶領域５０２には、データ管理のために必要な他のプログラムも記憶される。

【0132】

データ記憶領域５０４には、受信キャラクタデータ５０４ａ、更新キャラクタデータ５０４ｂおよび送信キャラクタデータ５０４ｃなどが記憶される。

【0133】

受信キャラクタデータ５０４ａは、ゲーム装置１２から受信した１または複数の預入用キャラクタデータである。更新キャラクタデータ５０４ｂは、ゲーム装置１２がキャラクタを預ける場合に、補完されたり、生成されたりした１または複数の引出用キャラクタデータである。送信キャラクタデータ５０４ｃは、ゲーム装置１２に送信するための１または複数の引出用キャラクタデータであって、キャラクタ情報ＤＢ５４ｂから取得される。

【0134】

図示は省略するが、データ記憶領域５０４には、データ管理処理に必要な他のデータが記憶されたり、データ管理処理に必要なフラグおよびカウンタ（タイマ）が設けられたりする。

【0135】

図１６－図１８は図２に示したＣＰＵ２０のクライアント側のデータ管理処理のフロー図である。このデータ管理処理は、ユーザがデータ管理アプリの実行を指示したことに応じて開始される。詳細な説明は省略するが、ユーザがクライアント側アプリの実行を指示してから、サーバ１６に引出用キャラクタデータの送信が要求されるまでの間に、サーバ１６によって、ゲーム装置１２のユーザが認証される。

【0136】

図１６に示すように、ＣＰＵ２０は、データ管理処理を開始すると、ステップＳ１で、図４に示したようなゲーム選択画面１００を表示装置３６に表示する。次のステップＳ３では、キャラクタの移動処理を実行するかどうかを判断する。ここでは、アイコン１０２、１０４または１０６がオンされた状態で、ボタン１１２がオンされたかどうかを判断する。

【0137】

ステップＳ３で“ＮＯ”であれば、つまり、キャラクタの移動処理の実行でなければ、ステップＳ１に戻る。ただし、ユーザがアイコン１０２、１０４または１０６をオンした場合には、オンされたアイコン１０２、１０４または１０６に割り当てられたゲームが選択される、または、割り当てられたゲームの選択を解除される。ただし、ユーザがボタン１１０をオンした場合には、データ管理処理を終了して、メインメニューに戻る。一方、ステップＳ３で“ＹＥＳ”であれば、つまり、キャラクタの移動処理の実行であれば、ステップＳ５で、引出用キャラクタデータ３０４ｃの送信をサーバ１６に要求する。

【0138】

続いて、ステップＳ７では、サーバ１６から引出用キャラクタデータ３０４ｃを受信したかどうかを判断する。ステップＳ７で“ＮＯ”であれば、つまり、引出用キャラクタデータ３０４ｃを受信していなければ、ステップＳ７に戻る。

【0139】

一方、ステップＳ７で“ＹＥＳ”であれば、つまり、引出用キャラクタデータ３０４ｃを受信すれば、ステップＳ９で、表示用キャラクタデータ３０４ｄを記憶する。ここでは、ＣＰＵ２０は、ゲーム選択画面１００で選択したゲームのセーブデータをフラッシュメモリ２４から読み出し、さらに、このセーブデータからキャラクタデータを読み出し、読み出したキャラクタデータと、受信した引出用キャラクタデータをそれぞれ識別可能に分類した表示用キャラクタデータ３０４ｄを生成し、データ記憶領域３０４に記憶する。このとき、ＣＰＵ２０は、ゲーム選択画面１００で選択されたゲームで利用されたことのないキャラクタの引出用キャラクタデータについては、当該ゲームの固有領域をデフォルトで生成して付与する。

【0140】

続くステップＳ１１では、図５に示したような移動画面２００を表示装置３６に表示する。次のステップＳ１３では、移動操作が有るかどうかを判断する。ステップＳ１３で“ＮＯ”であれば、つまり、移動操作が無ければ、図１８に示すステップＳ３５に進む。ただし、移動操作が無い場合であっても、ユーザの操作に従って、指示画像２２０が移動されたり、１または複数のキャラクタ画像２０６が選択されたり、１または複数のキャラクタ画像２０６の選択が解除されたりする。また、ユーザがボタン２１０をオンした場合には、キャラクタの移動を終了して、ステップＳ１に戻る。

【0141】

一方、ステップＳ１３で“ＹＥＳ”であれば、つまり、移動操作があれば、ステップＳ１５で、移動操作に従って表示用キャラクタデータ３０４ｄを更新し、ステップＳ１７で、移動操作に従ってキャラクタ画像２０６を移動し、図１７に示すステップＳ１９で、移動候補キャラクタデータ３０４ｅを更新する。ここでは、移動操作に従って移動されたキャラクタ画像２０６に対応するキャラクタデータについての移動候補キャラクタデータ３０４ｅを生成して記憶したり、元の表示領域２０２または表示領域２０４に移動されたキャラクタ画像２０６対応するキャラクタデータについての移動候補キャラクタデータ３０４ｅを削除したりする。

【0142】

続くステップＳ２１では、保存するかどうかを判断する。ここでは、ＣＰＵ２０は、ボタン２１４がオンされたかどうかを判断する。ステップＳ２１で“ＮＯ”であれば、つまり、保存しない場合には、ステップＳ３５に進む。一方、ステップＳ２１で“ＹＥＳ”であれば、つまり、保存する場合には、ステップＳ２３で、預けるキャラクタが有るかどうかを判断する。ここでは、ＣＰＵ２０は、表示領域２０４の識別情報を含む移動候補キャラクタデータ３０４ｅが有るかどうかを判断する。

【0143】

ステップＳ２３で“ＮＯ”であれば、つまり、預けるキャラクタが無ければ、ステップＳ２９に進む。一方、ステップＳ２３で“ＹＥＳ”であれば、つまり、預けるキャラクタが有れば、ステップＳ２５で、預けるキャラクタに対応するキャラクタデータすなわち預入用キャラクタデータをサーバ１６に送信する。ただし、ステップＳ２５では、ＣＰＵ２０は、サーバ１６にキャラクタデータを送信する前に、フォーマットを変換して、預入用キャラクタデータを生成する。次のステップＳ２７では、送信したキャラクタデータすなわちサーバ１６に預けたキャラクタのキャラクタデータをセーブデータ３０４ｂから削除し、フラッシュメモリ２４に上書きして、ステップＳ２９に進む。

【0144】

なお、預けるキャラクタが２体以上である場合には、ステップＳ２５およびＳ２７の処理は、預ける２体以上のキャラクタのそれぞれについて実行される。

【0145】

ステップＳ２９では、引き出すキャラクタが有るかどうかを判断する。ここでは、ＣＰＵ２０は、に、表示領域２０２の識別情報を含む移動候補キャラクタデータ３０４ｅが有るかどうかを判断する。

【0146】

ステップＳ２９で“ＮＯ”であれば、つまり、引き出すキャラクタが無い場合には、ステップＳ３５に進む。一方、ステップＳ２９で“ＹＥＳ”であれば、つまり、引き出すキャラクタが有る場合には、ステップＳ３１で、引き出すキャラクタに対応するキャラクタデータを含むセーブデータをフラッシュメモリ２４に保存し、ステップＳ３３で、引き出したキャラクタを引き出し不可状態にすることをサーバ１６に通知して、ステップＳ３５に進む。

【0147】

なお、引き出すキャラクタが２体以上である場合には、ステップＳ３１およびＳ３３の処理は、引き出す２体以上のキャラクタのそれぞれについて実行される。

【0148】

また、引き出すキャラクタに対応するキャラクタデータはセーブデータに含めて保存されるときに、ゲームで利用するフォーマットに変換される。

【0149】

図１８に示すように、ステップＳ３５では、終了するかどうかを判断する。ここでは、ＣＰＵ２０は、ボタン２１２がオンされたかどうかを判断する。ステップＳ３５で“ＮＯ”であれば、つまり、終了しない場合には、図１６に示すステップＳ１１に戻る。一方、ステップＳ３５で“ＹＥＳ”であれば、つまり、終了する場合には、ステップＳ３７で、移動処理の終了をサーバに通知して、データ管理処理を終了する。

【0150】

図１９は図３に示したサーバ１６のＣＰＵ５０のサーバ側のデータ管理処理の限定しない一例を示すフロー図である。詳細な説明は省略するが、ユーザがクライアント側アプリの実行を指示してから、サーバ１６に引出用キャラクタデータの送信が要求されるまでの間に、サーバ１６は、ゲーム装置１２のユーザのユーザＩＤを用いて当該ユーザを認証している。

【0151】

図１９に示すように、ＣＰＵ５０は、サーバ側のデータ管理処理を開始すると、ステップＳ１０１で、引出用キャラクタデータの送信要求が有るかどうかを判断する。ステップＳ１０１で“ＮＯ”であれば、つまり、引出用キャラクタデータの送信要求が無ければ、ステップＳ１０５に進む。一方、ステップＳ１０１で“ＹＥＳ”であれば、つまり、引出用キャラクタデータの送信要求が有れば、ステップＳ１０３で、要求元のゲーム装置１２に引出用キャラクタデータを送信して、ステップＳ１０５に進む。ただし、引出用キャラクタデータは、要求元のゲーム装置１２のユーザが所有するキャラクタについての引出用キャラクタデータである。

【0152】

ステップＳ１０５では、預入用キャラクタデータを受信したかどうかを判断する。ステップＳ１０５で“ＹＥＳ”であれば、預入用キャラクタデータを受信すれば、ステップＳ１０７で、受信した預入用キャラクタデータにユニークＩＤが付与されているかどうかを判断する。

【0153】

ステップＳ１０７で“ＹＥＳ”であれば、つまり、受信した預入用キャラクタデータにユニークＩＤが付与されている場合には、ステップＳ１０９で、引出用キャラクタデータすなわち引出用キャラクタデータの共通領域および作品別領域を更新して、ステップＳ１１３に進む。一方、ステップＳ１０７で“ＮＯ”であれば、つまり、受信した預入用キャラクタデータにユニークＩＤが付与されていない場合には、ステップＳ１１１で、ユニークＩＤを発行し、受信した預入用キャラクタデータに付与して、ステップＳ１１３に進む。

【0154】

ステップＳ１１３では、引き出し可能状態で、受信した預入用キャラクタデータを保存して、ステップＳ１１９に進む。つまり、ステップＳ１１３では、受信した預入用キャラクタデータに対応するキャラクタがサーバ１６に預けられ、更新された引出用キャラクタデータをキャラクタ情報ＤＢ５４ｂに記憶するとともに、フラグ情報を「true」に設定した当該キャラクタの管理情報をキャラクタ管理ＤＢ５４ａに記憶（または、更新）する。ただし、今回ユニークＩＤを発行したキャラクタについては、ステップＳ１１３では、管理情報が生成され、このとき、フラグ情報が「true」に設定される。

【0155】

また、ステップＳ１０５で“ＮＯ”であれば、つまり、預入用キャラクタデータを受信していなければ、ステップＳ１１５で、キャラクタを引き出し不可状態にすることの通知を受信したかどうかを判断する。ステップＳ１１５で“ＮＯ”であれば、つまり、キャラクタを引き出し不可状態にすることの通知を受信していなければ、ステップＳ１１９に進む。一方、ステップＳ１１５で“ＹＥＳ”であれば、つまり、キャラクタを引き出し不可状態にすることの通知を受信すれば、ステップＳ１１７で、当該キャラクタを引き出し不可状態に更新して、ステップＳ１１９に進む。ステップＳ１１７では、ＣＰＵ５０は、当該キャラクタの管理情報に含まれるフラグ情報を「false」に設定する。

【0156】

ステップＳ１１９では、ゲーム装置１２から移動処理の終了の通知があるかどうかを判断する。ステップＳ１１９で“ＮＯ”であれば、つまり、ゲーム装置１２から移動処理の終了の通知が無ければ、ステップＳ１０１に戻る。一方、ステップＳ１１９で“ＹＥＳ”であれば、つまり、ゲーム装置１２から移動処理の終了の通知が有れば、データ管理処理を終了する。

【0157】

この実施例によれば、引出用キャラクタデータは、或るゲームで使用した共通領域と固有領域のみが更新または補完されてサーバで保持されるので、他の固有領域を他のゲームで使用することができる。したがって、１つのキャラクタを複数種類のゲームで使用することができる。つまり、複数種類のゲームでキャラクタを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でキャラクタを保持することができる。

【0158】

なお、この実施例では、ゲームに利用されたキャラクタをサーバに預け、当該ゲームの固有領域を含む引出用キャラクタデータを更新または生成するようにしたが、ゲーム装置で実行可能な特定の種類のゲームについては、当該特定の種類のゲームで利用されたかどうかに関係無く、引出用キャラクタデータを生成するときに、当該特定の種類のゲームの固有領域を引出用キャラクタデータに含めるようにしてもよい。この場合、何らかの目的で特定のゲームの固有領域が必ず含まれるようにすることができる。一例として、特定の種類のゲームの固有領域を含まない引出用キャラクタデータをクライアント側アプリが使用しないようにすることで、不正に生成された引出用キャラクタデータの使用を防止することができる。つまり、不正チェックの目的で特定のゲームの固有領域を引出用キャラクタデータに含めることができる。

【0159】

また、この実施例では、サーバを設けて、サーバにキャラクタを預けたり、サーバからキャラクタを引き出したりするようにしたが、これに限定される必要はない。ゲーム装置において、キャラクタを預けたり、キャラクタを引き出したりするようにしてもよい。この場合、たとえば、ゲーム装置のフラッシュメモリに、キャラクタ管理ＤＢおよびキャラクタ情報を設け、ゲーム装置が図１９に示したサーバ側のデータ管理処理も実行する。

【0160】

さらに、この実施例では、キャラクタを引き出す場合に、クライアント側アプリが利用したことの無いゲームについての固有領域をデフォルトで生成するようにしたが、これに限定される必要はない。サーバ側アプリが引出用キャラクタデータを生成するときに、実行可能な複数のゲームの固有領域であって、ゲーム装置から受信した預入用キャラクタデータに含まれていない固有領域を除く１または複数の固有領域をデフォルトで生成するようにしてもよい。

【0161】

さらにまた、この実施例では、コンテンツの一例であるキャラクタを、サーバに預けたり、サーバから引き出したりする場合について説明したが、限定される必要はない。複数種類のゲームで利用されるアイテムを、サーバに預けたり、サーバから引き出したりすることもできる。

【0162】

また、この実施例で示した各種のゲーム画像およびゲーム装置の構成は単なる例示であり、限定されるべきでなく、実際の製品に応じて適宜変更可能である。

【0163】

さらに、同じ効果（結果）が得られる場合には、フロー図に示した各ステップの順番は適宜変更されてもよい。

【符号の説明】

【0164】

１０ …コンテンツ保持システム
１２ …ゲーム装置
１６ …コンテンツ保持サーバ
２０、５０ …ＣＰＵ
２２、５２ …ＲＡＭ
２４ …フラッシュメモリ
２６ …第１通信モジュール
２８ …第２通信モジュール
３０、５８ …入力装置
３６、６２ …表示装置
３８ …スピーカ
５４ …ＨＤＤ
５６ …通信モジュール

【要約】      （修正有）

【課題】複数種類のゲームでコンテンツを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でコンテンツを保持する。
【解決手段】コンテンツ保持システムは、ゲーム装置およびサーバを含む。ゲーム装置は複数種類のゲームをプレイすることができ、キャラクタをサーバに預けることができる。キャラクタデータは共通領域およびゲームの固有領域を有するフォーマットに変換される。サーバは、キャラクタを預かる場合、当該キャラクタの引出用キャラクタデータにおいて、共通データとゲームで使用した固有領域のみを更新する。ゲーム装置は、預けたキャラクタを引き出す場合に、サーバ側で保持された引出用キャラクタデータから、共通領域と、引き出すキャラクタを利用するゲームの固有領域を有するキャラクタデータを取得し、取得したキャラクタデータをゲームで利用するためのフォーマットに変換して利用するゲームのセーブデータに含めて保存する。
【選択図】図９

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】