(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023166242
(43)【公開日】2023-11-21
(54)【発明の名称】コンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバ
(51)【国際特許分類】
A63F 13/77 20140101AFI20231114BHJP
A63F 13/35 20140101ALI20231114BHJP
A63F 13/49 20140101ALI20231114BHJP
H04L 67/131 20220101ALI20231114BHJP
H04L 67/30 20220101ALI20231114BHJP
【FI】
A63F13/77
A63F13/35
A63F13/49
H04L67/131
H04L67/30
【審査請求】有
【請求項の数】9
【出願形態】OL
(21)【出願番号】P 2022077161
(22)【出願日】2022-05-09
(11)【特許番号】
(45)【特許公報発行日】2023-10-04
(71)【出願人】
【識別番号】000233778
【氏名又は名称】任天堂株式会社
(71)【出願人】
【識別番号】504440133
【氏名又は名称】株式会社ポケモン
(74)【代理人】
【識別番号】100090181
【弁理士】
【氏名又は名称】山田 義人
(74)【代理人】
【識別番号】100130269
【弁理士】
【氏名又は名称】石原 盛規
(74)【代理人】
【識別番号】100168217
【弁理士】
【氏名又は名称】大村 和史
(72)【発明者】
【氏名】富樫 紘希
(72)【発明者】
【氏名】太田 信之
(57)【要約】 (修正有)
【課題】複数種類のゲームでコンテンツを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でコンテンツを保持する。
【解決手段】コンテンツ保持システムは、ゲーム装置およびサーバを含む。ゲーム装置は複数種類のゲームをプレイすることができ、キャラクタをサーバに預けることができる。キャラクタデータは共通領域およびゲームの固有領域を有するフォーマットに変換される。サーバは、キャラクタを預かる場合、当該キャラクタの引出用キャラクタデータにおいて、共通データとゲームで使用した固有領域のみを更新する。ゲーム装置は、預けたキャラクタを引き出す場合に、サーバ側で保持された引出用キャラクタデータから、共通領域と、引き出すキャラクタを利用するゲームの固有領域を有するキャラクタデータを取得し、取得したキャラクタデータをゲームで利用するためのフォーマットに変換して利用するゲームのセーブデータに含めて保存する。
【選択図】
図9
【特許請求の範囲】
【請求項1】
サーバと、当該サーバに接続可能な少なくとも1つの情報処理端末を含み、
前記サーバは、
複数種類のゲームで利用可能な少なくとも1つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、
前記コンテンツデータを管理するサーバ管理プログラムを実行する第1のプロセッサを備え、
前記コンテンツ記憶媒体に記憶される前記コンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、前記複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、前記複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有し、
前記情報処理端末は、
前記複数種類のゲームのいずれかである第1のゲームのセーブデータである第1セーブデータを記憶する第1セーブデータ記憶媒体と、
前記サーバと送受信する前記コンテンツを管理するクライアントプログラムを実行する第2のプロセッサを備え、
前記クライアントプログラムは、前記第2のプロセッサに、
前記第1セーブデータ記憶媒体から前記第1セーブデータを読み出させ、
当該第1セーブデータに基づいて、前記第1のゲームで用いられた少なくとも1つの第1のコンテンツについて、前記共通領域と、前記第1のゲームに対応する前記固有領域である第1固有領域とを少なくとも含む預入用コンテンツデータを生成させ、
生成された前記預入用コンテンツデータを前記サーバに送信させ、
前記サーバ管理プログラムは、前記第1のプロセッサに、
前記情報処理端末から前記第1のコンテンツに関する前記預入用コンテンツデータを受信した場合に、受信された前記預入用コンテンツデータに含まれる前記共通領域および前記第1固有領域を少なくとも含むコンテンツデータであって、かつ前記第1のコンテンツに関して前記第1固有領域以外の前記固有領域を有する前記コンテンツデータが前記コンテンツ記憶媒体に保持されている場合には当該保持された前記第1固有領域以外の前記固有領域をさらに含むコンテンツデータを、前記第1のコンテンツに関する最新の前記コンテンツデータとして前記コンテンツ記憶媒体に記憶させる、
コンテンツデータ保持システム。
【請求項2】
前記情報処理端末はさらに、
前記複数種類のゲームのいずれかである第2のゲームのセーブデータである第2セーブデータを記憶する第2セーブデータ記憶媒体を備え、
前記サーバ管理プログラムはさらに、前記第1のプロセッサに、
前記情報処理端末から、前記第2のゲームで用いられる前記第1のコンテンツの送信要求があった場合に、
当該第1のコンテンツの前記コンテンツデータに基づいて、前記共通領域を少なくとも含み、前記第2のゲームに対応する第2固有領域が保持されている場合は当該第2固有領域をさらに少なくとも含む引出用コンテンツデータを生成させ、
当該コンテンツデータを前記コンテンツ記憶媒体に保持させたまま、前記引出用コンテンツデータを前記情報処理端末に送信させ、
前記クライアントプログラムはさらに、前記第2のプロセッサに、
受信された前記引出用コンテンツデータに含まれる前記共通領域および前記第2固有領域に基づいて、前記第1のコンテンツが含まれるように前記第2セーブデータを更新して前記第2セーブデータ記憶媒体に記憶させる、請求項1記載のコンテンツ保持システム。
【請求項3】
前記引出用コンテンツデータは、前記第1のコンテンツに関する前記コンテンツデータにおける、前記共通領域および保持されているすべての前記固有領域を含む、請求項2記載のコンテンツ保持システム。
【請求項4】
前記クライアントプログラムはさらに、前記第2のプロセッサに、
受信された前記引出用コンテンツデータに前記第2固有領域が含まれない場合、当該第2領域に対応する前記パラメータ群を生成させて、前記第2セーブデータを更新して前記第2セーブデータ記憶媒体に記憶させる、請求項2記載のコンテンツ保持システム。
【請求項5】
前記サーバ管理プログラムは、前記第1のプロセッサにさらに、
前記情報処理端末から前記第1のコンテンツに関する前記預入用コンテンツデータを受信した場合に、前記第1のコンテンツが引出可能な状態として前記コンテンツデータを前記コンテンツ記憶媒体に記憶させ、
前記第1のコンテンツが引出可能な状態において前記情報処理端末から前記第1のコンテンツの送信要求があった場合に、前記コンテンツデータを前記コンテンツ記憶媒体に保持させたまま前記引出用コンテンツデータを前記情報処理端末に送信させ、かつ、前記第1のコンテンツが第2セーブデータに含まれるよう前記第2セーブデータ記憶媒体に記憶されている場合に前記第1のコンテンツが引出不可能な状態となるように前記コンテンツデータを保持させる、請求項2記載のコンテンツ保持システム。
【請求項6】
前記コンテンツデータの前記共通領域は、前記コンテンツ固有のIDを少なくとも含み、
前記サーバ管理プログラムは、前記第1のプロセッサにさらに、
前記情報処理端末から前記預入用コンテンツデータを受信した場合に、前記第1のコンテンツに前記IDが無い場合には新規に前記IDを付与した上で、前記コンテンツデータを前記コンテンツ記憶媒体に記憶させる、請求項1から5のいずれか記載のコンテンツ保持システム。
【請求項7】
前記預入用コンテンツデータは、前記複数種類のゲームのいずれかである第3のゲームに対応する前記固有領域である第3固有領域をさらに含む、請求項1または2記載のコンテンツ保持システム。
【請求項8】
情報処理装置のコンピュータに実行されるコンテンツ管理プログラムであって、
前記情報処理装置は、複数種類のゲームのいずれかである第1のゲームのセーブデータである第1セーブデータを記憶する第1セーブデータ記憶媒体と、前記複数種類のゲームのいずれかである第2のゲームのセーブデータである第2セーブデータを記憶する第2セーブデータ記憶媒体とを備え、
前記コンピュータに、
第1の指示入力に基づいて、
前記第1セーブデータ記憶媒体から、当該第1セーブデータを読み出させ、
当該第1セーブデータに基づいて、前記第1のゲームで用いられた少なくとも1つの第1のコンテンツについて、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、前記複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、前記複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域のうち、前記第1のゲームに対応する第1固有領域とを少なくとも含む預入用コンテンツデータを生成させ、
生成された前記預入用コンテンツデータをサーバに送信させ、
第2の指示入力に基づいて、
前記サーバに対して、前記複数種類のゲームのいずれかである第2のゲームで用いられる前記第1のコンテンツの送信要求を行わせ、
当該送信要求に応じて、当該第1のコンテンツに関して、前記共通領域と前記固有領域とを含む引出用コンテンツデータを前記サーバから受信させ、
少なくとも前記引出用コンテンツデータに含まれる前記共通領域および前記第2固有領域に基づいて、前記第1のコンテンツが含まれるよう前記第2セーブデータを更新して前記第2セーブデータ記憶媒体に記憶させる、
コンテンツ管理プログラム。
【請求項9】
複数種類のゲームで利用可能な少なくとも1つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、
前記コンテンツデータを管理する管理プログラムを実行するプロセッサを備え、
前記コンテンツ記憶媒体に記憶される前記コンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、前記複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、前記複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有し、
前記管理プログラムを実行する前記プロセッサは、
情報処理端末から、第1のコンテンツについて、前記共通領域と、前記複数種類のゲームのいずれかである第1のゲームに対応する前記固有領域である第1固有領域とを少なくとも含む預入用コンテンツデータを受信し、
受信された前記預入用コンテンツデータに含まれる前記共通領域および前記第1固有領域を少なくとも含むコンテンツデータであって、かつ前記第1のコンテンツに関して前記第1固有領域以外の前記固有領域を有する前記コンテンツデータが前記コンテンツ記憶媒体に保持されている場合には当該保持された前記第1固有領域以外の前記固有領域をさらに含むコンテンツデータを、前記第1のコンテンツに関する最新の前記コンテンツデータとして前記コンテンツ記憶媒体に記憶させ、
前記情報処理端末から、前記複数種類のゲームのいずれかである第2のゲームで用いられる前記第1のコンテンツの送信要求があった場合に、
当該第1のコンテンツの前記コンテンツデータに基づいて、前記共通領域を少なくとも含み、前記第2のゲームに対応する第2固有領域が保持されている場合は当該第2固有領域をさらに少なくとも含む引出用コンテンツデータを生成し、
当該コンテンツデータを前記コンテンツ記憶媒体に保持させたまま、前記引出用コンテンツデータを前記情報処理端末に送信させる、
コンテンツ保持サーバ。
【発明の詳細な説明】
【技術分野】
【0001】
この発明はコンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバに関し、特にたとえば、ユーザが所有する複数のキャラクタから選択した一部のキャラクタを所定の情報処理に利用する、コンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバに関する。
【背景技術】
【0002】
この種のコンテンツ保持システムの一例が特許文献1に開示されている。この特許文献1には、ゲームG1とは種類の異なるゲームG2では、ゲームG1で利用されるキャラクタデータD1を利用することができる。この場合、ゲーム装置2は、第2サーバ5から、選択したキャラクタデータD2を受信し、記憶部22に記憶する。キャラクタデータD2は、第2サーバ5に預けられる場合に、キャラクタデータD1に管理IDを付与したキャラクタデータである。ゲーム装置2では、キャラクタデータD2を受信した際、記憶部22に記憶されるキャラクタデータD2に、ゲームG2で利用される1以上のパラメータが含まれていない場合には、そのパラメータが自動的に付与される。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、特許文献1では、ゲームG2でゲームG1から預けたキャラクタデータすなわちコンテンツを引き出して利用しようとした場合にパラメータが欠けているときは当該パラメータが追加されるが、パラメータが追加された後のキャラクタデータでは元のゲームG1に戻して利用することが難しくなることが考えられる。
【0005】
それゆえに、この発明の主たる目的は、新規な、コンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバを提供することである。
【0006】
また、この発明の他の目的は、複数種類のゲームでコンテンツを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でコンテンツを保持することができる、コンテンツ保持システム、コンテンツ管理プログラムおよびコンテンツ保持サーバを提供することである。
【課題を解決するための手段】
【0007】
(構成1)
構成1は、サーバと、当該サーバに接続可能な少なくとも1つの情報処理端末を含む、コンテンツデータ保持システムである。サーバは、複数種類のゲームで利用可能な少なくとも1つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、コンテンツデータを管理するサーバ管理プログラムを実行する第1のプロセッサを備え、コンテンツ記憶媒体に記憶されるコンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有している。情報処理端末は、複数種類のゲームのいずれかである第1のゲームのセーブデータである第1セーブデータを記憶する第1セーブデータ記憶媒体と、サーバと送受信するコンテンツを管理するクライアントプログラムを実行する第2のプロセッサを備え、クライアントプログラムは、第2のプロセッサに、第1セーブデータ記憶媒体から第1セーブデータを読み出させ、第1セーブデータに基づいて、第1のゲームで用いられた少なくとも1つの第1のコンテンツについて、共通領域と、第1のゲームに対応する固有領域である第1固有領域とを少なくとも含む預入用コンテンツデータを生成させ、生成された預入用コンテンツデータをサーバに送信させ、サーバ管理プログラムは、第1のプロセッサに、情報処理端末から第1のコンテンツに関する預入用コンテンツデータを受信した場合に、受信された預入用コンテンツデータに含まれる共通領域および第1固有領域を少なくとも含むコンテンツデータであって、かつ第1のコンテンツに関して第1固有領域以外の固有領域を有するコンテンツデータがコンテンツ記憶媒体に保持されている場合には当該保持された第1固有領域以外の固有領域をさらに含むコンテンツデータを、第1のコンテンツに関する最新のコンテンツデータとしてコンテンツ記憶媒体に記憶させる。
【0008】
構成1によれば、第1のゲームで使った共通領域と第1固有領域のみ更新されてサーバに保持されるので、他の固有領域を他のゲームで使うことが出来る。したがって、1つのコンテンツを複数種類のゲームで相互に利用することができる。つまり、複数種類のゲームでコンテンツを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でコンテンツを保持することができる。
【0009】
(構成2)
構成2は、上記構成1において、情報処理端末はさらに、複数種類のゲームのいずれかである第2のゲームのセーブデータである第2セーブデータを記憶する第2セーブデータ記憶媒体を備える。サーバ管理プログラムはさらに、第1のプロセッサに、情報処理端末から、第2のゲームで用いられる第1のコンテンツの送信要求があった場合に、当該第1のコンテンツのコンテンツデータに基づいて、共通領域を少なくとも含み、第2のゲームに対応する第2固有領域が保持されている場合は当該第2固有領域をさらに少なくとも含む引出用コンテンツデータを生成させ、当該コンテンツデータをコンテンツ記憶媒体に保持させたまま、引出用コンテンツデータを情報処理端末に送信させる。クライアントプログラムはさらに、第2のプロセッサに、受信された引出用コンテンツデータに含まれる共通領域および第2固有領域に基づいて、第1のコンテンツが含まれるように第2セーブデータを更新して第2セーブデータ記憶媒体に記憶させる。
【0010】
構成2によれば、第2のゲームで使う共通領域と第2の固有領域のみ第2のセーブデータに反映できるので、第2のゲームで使えない他の固有領域が含まれるコンテンツデータがサーバに保持されていても、第2のゲーム側で他の固有領域に対応する必要なくコンテンツを利用することができる。
【0011】
(構成3)
構成3は、上記構成2において、引出用コンテンツデータは、第1のコンテンツに関するコンテンツデータにおける、共通領域および保持されているすべての固有領域を含む。
【0012】
(構成4)
構成4は、上記構成2または上記構成3において、クライアントプログラムはさらに、第2のプロセッサに、受信された引出用コンテンツデータに第2固有領域が含まれない場合、当該第2領域に対応するパラメータ群を生成させて、第2セーブデータを更新して第2セーブデータ記憶媒体に記憶させる。
【0013】
(構成5)
構成5は、上記構成2から上記構成4までのいずれかにおいて、サーバ管理プログラムは、第1のプロセッサにさらに、情報処理端末から第1のコンテンツに関する預入用コンテンツデータを受信した場合に、第1のコンテンツが引出可能な状態としてコンテンツデータをコンテンツ記憶媒体に記憶させ、第1のコンテンツが引出可能な状態において情報処理端末から第1のコンテンツの送信要求があった場合に、コンテンツデータをコンテンツ記憶媒体に保持させたまま引出用コンテンツデータを情報処理端末に送信させ、かつ、第1のコンテンツが第2セーブデータに含まれるよう第2セーブデータ記憶媒体に記憶されている場合に第1のコンテンツが引出不可能な状態となるようにコンテンツデータを保持させる。
【0014】
(構成6)
構成6は、上記構成1から上記構成5までのいずれかにおいて、コンテンツデータの共通領域は、コンテンツ固有のIDを少なくとも含み、サーバ管理プログラムは、第1のプロセッサにさらに、情報処理端末から預入用コンテンツデータを受信した場合に、第1のコンテンツにIDが無い場合には新規にIDを付与した上で、コンテンツデータをコンテンツ記憶媒体に記憶させる。
【0015】
(構成7)
構成7は、上記構成1から上記構成6までのいずれかにおいて、預入用コンテンツデータは、複数種類のゲームのいずれかである第3のゲームに対応する固有領域である第3固有領域をさらに含む。
【0016】
構成7によれば、何らかの目的で特定のゲーム固有領域が必ず含まれるようにすることができる。
【0017】
(構成8)
構成8は、情報処理装置のコンピュータに実行されるコンテンツ管理プログラムである。情報処理装置は、複数種類のゲームのいずれかである第1のゲームのセーブデータである第1セーブデータを記憶する第1セーブデータ記憶媒体と、複数種類のゲームのいずれかである第2のゲームのセーブデータである第2セーブデータを記憶する第2セーブデータ記憶媒体とを備える。コンテンツ管理プログラムは、コンピュータに、第1の指示入力に基づいて、第1セーブデータ記憶媒体から、当該第1セーブデータを読み出させ、当該第1セーブデータに基づいて、第1のゲームで用いられた少なくとも1つの第1のコンテンツについて、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域のうち、第1のゲームに対応する第1固有領域とを少なくとも含む預入用コンテンツデータを生成させ、生成された預入用コンテンツデータをサーバに送信させ、第2の指示入力に基づいて、サーバに対して、複数種類のゲームのいずれかである第2のゲームで用いられる第1のコンテンツの送信要求を行わせ、当該送信要求に応じて、当該第1のコンテンツに関して、共通領域と固有領域とを含む引出用コンテンツデータをサーバから受信させ、少なくとも引出用コンテンツデータに含まれる共通領域および第2固有領域に基づいて、第1のコンテンツが含まれるよう第2セーブデータを更新して第2セーブデータ記憶媒体に記憶させる。
【0018】
(構成9)
構成9は、複数種類のゲームで利用可能な少なくとも1つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、コンテンツデータを管理する管理プログラムを実行するプロセッサを備える、コンテンツ保持サーバである。コンテンツ記憶媒体に記憶されるコンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有している。管理プログラムを実行するプロセッサは、情報処理端末から、第1のコンテンツについて、共通領域と、複数種類のゲームのいずれかである第1のゲームに対応する固有領域である第1固有領域とを少なくとも含む預入用コンテンツデータを受信し、受信された預入用コンテンツデータに含まれる共通領域および第1固有領域を少なくとも含むコンテンツデータであって、かつ第1のコンテンツに関して第1固有領域以外の固有領域を有するコンテンツデータがコンテンツ記憶媒体に保持されている場合には当該保持された第1固有領域以外の固有領域をさらに含むコンテンツデータを、第1のコンテンツに関する最新のコンテンツデータとしてコンテンツ記憶媒体に記憶させ、情報処理端末から、複数種類のゲームのいずれかである第2のゲームで用いられる第1のコンテンツの送信要求があった場合に、当該第1のコンテンツのコンテンツデータに基づいて、共通領域を少なくとも含み、第2のゲームに対応する第2固有領域が保持されている場合は当該第2固有領域をさらに少なくとも含む引出用コンテンツデータを生成し、当該コンテンツデータをコンテンツ記憶媒体に保持させたまま、引出用コンテンツデータを情報処理端末に送信させる。
【0019】
第8構成および第9構成においても、上記第1構成と同様に、複数種類のゲームでコンテンツを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でコンテンツを保持することができる。
【発明の効果】
【0020】
この発明によれば、複数種類のゲームでコンテンツを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でコンテンツを保持することができる。
【0021】
この発明の上述の目的,その他の目的,特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【図面の簡単な説明】
【0022】
【
図1】
図1はコンテンツ保持システムの限定しない一例を示す図である。
【
図2】
図2は
図1に示すゲーム装置の電気的な構成の限定しない一例を示すブロック図である。
【
図3】
図3は
図1に示すコンテンツ保持サーバの電気的な構成の限定しない一例を示すブロック図である。
【
図4】
図4は
図2に示す表示装置に表示されるゲーム選択画面の限定しない一例を示す図である。
【
図5】
図5は
図2に示す表示装置に表示される移動画面の限定しない一例を示す図である。
【
図6】
図6はゲーム装置からコンテンツ保持サーバにキャラクタを預ける場合の過程の一例を説明するための図である。
【
図7】
図7はゲーム装置からコンテンツ保持サーバにキャラクタを預ける前のコンテンツ保持サーバで管理されるデータベースの一例を示す図である。
【
図8】
図8はゲーム装置からコンテンツ保持サーバにキャラクタを預ける場合にコンテンツ保持サーバで補完されたキャラクタデータの一例を示す図である。
【
図9】
図9はゲーム装置からコンテンツ保持サーバにキャラクタを預けた場合にコンテンツ保持サーバで管理されるデータベースの一例を示す図である。
【
図10】
図10はコンテンツ保持サーバで保持されるキャラクタデータの詳細な内容の一例の一部を示す図である。
【
図11】
図11はコンテンツ保持サーバで保持されるキャラクタデータの詳細な内容の一例の他の一部を示す図である。
【
図12】
図12はコンテンツ保持サーバからゲーム装置にキャラクタを引き出す場合の過程の一例の一部を説明するための図である。
【
図13】
図13はコンテンツ保持サーバからゲーム装置にキャラクタを引き出す場合の過程の一例の他の一部を説明するための図である。
【
図14】
図14は
図2に示すゲーム装置に内蔵されるRAMのメモリマップの一例を示す図である。
【
図15】
図15は
図2に示すコンテンツ保持サーバに内蔵されるRAMのメモリマップの一例を示す図である。
【
図16】
図16は
図2に示すゲーム装置に内蔵されるCPUのデータ管理処理の一例の一部を示すフロー図である。
【
図17】
図17は
図2に示すゲーム装置に内蔵されるCPUのデータ管理処理の他の一部であって、
図16に後続するフロー図である。
【
図18】
図18は
図2に示すゲーム装置に内蔵されるCPUのデータ管理処理のその他の一部であって、
図17に後続するフロー図である。
【
図19】
図19は
図3に示すコンテンツ保持サーバに内蔵されるCPUのデータ管理処理の一例を示すフロー図である。
【発明を実施するための形態】
【0023】
図1を参照して、限定しない一例のコンテンツ保持システム10はゲーム装置12を含み、ゲーム装置12は、インターネットのようなネットワーク14を介してコンテンツ保持サーバ(以下、単に「サーバ」という)16と通信可能に接続される。
【0024】
ゲーム装置12は、情報処理装置の一例であり、ゲーム専用機のみならず、ゲーム機能を備える各種の電子機器である。電子機器は、たとえば、スマートフォン、携帯電話機(フィーチャーフォン)、タブレットPC、ノートPCなどである。ただし、携帯型の電子機器に限定される必要は無く、据置型のゲーム装置、アーケードゲーム装置、デスクトップPCなどの据置型の電子機器を用いることもできる。
【0025】
サーバ16は、汎用のサーバである。サーバ16は、内部メモリまたは外部に接続されたデータベースに、この実施例のゲーム装置12でプレイされる仮想のゲームのゲームデータに含まれるキャラクタデータを、ゲーム装置12のユーザないしプレイヤ(以下、単に「ユーザ」という)の情報と関連付けて記憶または保持(つまり、管理)する。
【0026】
図2は
図1に示すゲーム装置12の電気的な構成の限定しない一例を示すブロック図である。
図2に示すように、ゲーム装置12はCPU20を含み、CPU20には、RAM22、フラッシュメモリ24、第1通信モジュール26、第2通信モジュール28、入力装置30、表示ドライバ32およびD/A変換器34が接続される。また、表示装置36が表示ドライバ32に接続され、スピーカ38がD/A変換器34に接続される。
【0027】
CPU20は、ゲーム装置12の全体制御を司る。ただし、CPU20に代えて、CPU機能、GPU機能等の複数の機能を含むSoC(System-on-a-chip)を設けてもよい。RAM22は、揮発性記憶媒体であり、CPU20のワークメモリやバッファメモリとして使用される。フラッシュメモリ24は、不揮発性記憶媒体であり、ゲームのようなアプリケーションのプログラムを記憶したり、各種のデータを記憶(セーブ)したりするために使用される。
【0028】
この実施例では、ゲームのアプリケーションのみならず、ゲームで利用されるキャラクタを管理するためのプログラム(後述する、「クライアント側データ管理プログラム」)も記憶される。この実施例では、キャラクタは、一例として、動物を模したモンスターのキャラクタである。
【0029】
なお、ゲーム装置12では、文書作成アプリケーション、電子メールアプリケーション、お絵描きアプリケーション、文字練習用アプリケーション、語学トレーニングアプリケーション、学習アプリケーションなどの様々なアプリケーションも実行可能であり、これらのアプリケーションがフラッシュメモリ24に記憶される場合もある。
【0030】
第1通信モジュール26は、たとえばIEEE802.11.b/gの規格に準拠した方式により、無線LANに接続する機能を有する。したがって、たとえば、CPU20は、第1通信モジュール26を用いて、アクセスポイントおよびインターネット(すなわち、ネットワーク14)を介して他の機器(サーバ16および他のゲーム装置など)との間でデータを送受信する。ただし、第1通信モジュール26を用いて、他の機器との間で直接データを送受信することもできる。
【0031】
第2通信モジュール28は、近距離無線通信を行う機能を有する。具体的には、第2通信モジュール28は、所定の通信方式(たとえば、赤外線方式)により、他の機器(他のゲーム装置など)との間で赤外線信号の送受信を行う機能、および所定の通信プロトコル(たとえば、マルチリンクプロトコル)に従って、同種のゲーム装置との間で無線通信を行う機能を有する。したがって、たとえば、CPU20は、第2通信モジュール28を用いて、同種の他のゲーム装置との間でデータを直接送受信することもできる。ただし、赤外線方式の近距離無線通信に代えて、Bluetooth(登録商標)のような他の無線通信規格に従う近距離無線通信を行うようにしてもよい。
【0032】
入力装置30は、たとえば、ゲーム装置12に設けられる各種の押しボタンないしスイッチであり、ユーザによって、メニュー選択やゲーム操作などの各種の操作に用いられる。ただし、入力装置30としては、タッチパネルなどのポインティングデバイス、マイクおよびカメラなどの入力手段が、押しボタンないしスイッチに代えて、または、押しボタンないしスイッチとともに設けられてもよい。また、タッチパネルは、後述する表示装置36に組み込まれる場合もある。この場合の表示装置36は、タッチパネル一体型表示装置である。
【0033】
表示ドライバ32は、CPU20の指示の下、表示装置36にゲーム画像などの各種の画像(画面)を表示するために使用される。図示は省略するが、表示ドライバ32は、ビデオRAM(VRAM)を内蔵している。表示装置36は、LCDまたは有機ELディスプレイである。
【0034】
D/A変換器34は、CPU20から与えられる音声データをアナログのゲーム音声に変換し、スピーカ38に出力する。ただし、ゲーム音声は、ゲームのキャラクタないしオブジェクトの音声、効果音、音楽(BGM)のようなゲームに必要な音を意味する。
【0035】
なお、
図1に示すゲーム装置12の電気的な構成は単なる一例であり、これに限定される必要はない。たとえば、第2通信モジュール28は無くてもよい。
【0036】
図3は
図1に示したサーバ16の電気的な構成を示すブロック図である。
図3に示すように、サーバ16はCPU50を含み、CPU50には、RAM52、HDD54、通信モジュール56、入力装置58および表示ドライバ60が接続される。また、表示装置62が表示ドライバ60に接続される。
【0037】
CPU50は、サーバ16の全体的な制御を司る。RAM52は、揮発性記憶媒体であり、CPU50のワークメモリやバッファメモリとして使用される。HDD54は、不揮発性記憶媒体であり、オペレーティングシステム(OS)および必要な制御プログラムを記憶するとともに、所定のデータを記憶または保持するために使用される。この実施例では、必要な制御プログラムはキャラクタを管理するためのプログラム(後述する、「サーバ側データ管理プログラム」)を含む。また、所定のデータとして、1または複数のゲームで利用されるキャラクタのキャラクタデータを管理するためのデータベース(以下、「キャラクタ管理DB」)54aおよび1または複数のゲームで利用されるキャラクタのキャラクタデータを保持するためのデータベース(以下、「キャラクタ情報DB」)54bを含む。ただし、キャラクタ管理DB54aおよびキャラクタ情報DB54bは、サーバ16の外部に設けられてもよい。この場合、キャラクタ管理DB54aおよびキャラクタ情報DB54bは、サーバ16に直接接続されてもよいし、ネットワーク14を介してサーバ16と通信可能に設けられてもよい。
【0038】
通信モジュール56は、有線または無線で、LANに接続する機能を有する。したがって、サーバ16は、ゲーム装置12および他のゲーム装置とネットワーク14を介して通信することができる。ただし、サーバ16は、ゲーム装置12および他のゲーム装置とネットワーク14を介さずに直接通信することもできる。
【0039】
入力装置58は、たとえば、キーボードおよびコンピュータマウスなどである。表示ドライバ60は、CPU50の指示の下、表示装置62に各種画面を表示するために使用される。表示ドライバ60は、ビデオRAM(VRAM)を内蔵している。表示装置62は、LCDまたは有機ELディスプレイである。
【0040】
なお、
図3に示すサーバ16の電気的な構成は単なる一例であり、これに限定される必要はない。
【0041】
上述したコンテンツ保持システム10では、ゲーム装置12は、複数種類のゲームをプレイすることができ、或る種類のゲームをプレイすることにより取得したキャラクタ(コンテンツに相当する)を、種類の異なる他のゲームで利用することができる。
【0042】
キャラクタを種類の異なる他のゲームで利用する場合には、或るゲームで取得したキャラクタはサーバ16に一旦預けられ、当該キャラクタは他のゲームで利用するためにサーバ16から引き出される。この場合、預けたり引き出したりするキャラクタのキャラクタデータがゲーム装置12とサーバ16の間で送受信される。
【0043】
ただし、或る種類のゲームで取得したキャラクタを他の種類のゲームで利用するためにサーバ16から引き出すだけでなく、同じ方法で、同じ種類のゲームで利用するためにサーバ16から引き出すことも可能である。
【0044】
また、後述するように、サーバ16はキャラクタのキャラクタデータを保持するため、サーバ16からゲーム装置12にキャラクタを引き出した場合であっても、サーバ16に保持されているキャラクタデータが消去されることはない。
【0045】
また、或るゲームと他のゲームは、種類の異なるゲームであるが、いずれも、ユーザが仮想のゲーム空間で様々なキャラクタ(この実施例では、モンスターのキャラクタ)を収集(この実施例では、捕獲または取得)し、収集したキャラクタを他のキャラクタと対戦させることで育成するゲームである。一例として、種類の異なるゲームは、一部の内容が異なる作品またはシリーズのゲームである。
【0046】
以下、この明細書においては、1のユーザがキャラクタをサーバ16に預けたりサーバ16から引き出したりする場合について説明するが、複数のユーザが、それぞれ、キャラクタをサーバ16に預けたりサーバ16から引き出したりすることができる。つまり、サーバ16では、ユーザ毎に、キャラクタが管理される。
【0047】
また、この明細書においては、ユーザが一台のゲーム装置12を用いてキャラクタをサーバ16に預けたり、サーバ16から引き出したりする場合について説明するが、同じユーザIDを複数台のゲーム装置12に登録している場合には、キャラクタをサーバ16に預けるゲーム装置12とキャラクタをサーバ16から引き出すゲーム装置12は異なるゲーム装置12であってもよい。したがって、たとえば、携帯型のゲーム装置12で預けたキャラクタをゲーム装置12としても使用できるスマートフォンで引き出してゲームに利用することができる。これは一例であり、上述しように、使用可能なゲーム装置12は様々である。
【0048】
図4はゲーム装置12の表示装置36に表示されるゲーム選択画面100の限定しない一例を示す図である。ユーザは、キャラクタを預けたり引き出したりする場合には、ゲーム装置12に記憶されたクライアント側のデータ管理アプリケーション(後述する「クライアント側データ管理プログラム302f」を実行する。すると、預けるキャラクタを利用するゲームまたは引き出したキャラクタを利用するゲームを選択するためのゲーム選択画面100が表示装置36に表示される。
【0049】
図示は省略するが、メインメニュー画面では、ゲームをプレイすることが選択されたり、クライアント側のデータ管理アプリケーションを実行することが選択されたり、各種の設定を行うことが選択されたりする。
【0050】
ゲーム選択画面100には、1または複数のアイコン(
図4では、アイコン102、104、106)が表示され、1または複数のアイコンの下方に、3つのボタン110、112および112が表示される。
【0051】
アイコン102は、ゲームAを選択するためのアイコンである。アイコン104は、ゲームBを選択するためのアイコンである。アイコン106は、ゲームCを選択するためのアイコンである。図示は省略するが、一例として、ゲーム選択画面100でアイコン(ここでは、アイコン102、アイコン104またはアイコン106)がオンされると、オンされたアイコンに割り当てられたゲームが選択された状態となる。また、オンされたアイコンが再度オンされると、再度オンされたアイコンに割り当てられたゲームが選択された状態が解除される。
【0052】
ゲームA、ゲームBおよびゲームCは、ゲーム装置12でプレイ可能なゲームであり、各セーブデータがゲーム装置12のフラッシュメモリ24に記憶されている。ゲームA、ゲームBおよびゲームCのゲームプログラムは、ゲーム装置12に常に記憶されている必要はなく、プレイするときに、ゲーム装置12に記憶されていればよい。
【0053】
セーブデータは、ゲームをプレイした場合に生成および更新されるゲームデータ、当該ゲームの種類を示す情報(たとえば、タイトル)、ゲームをプレイしたユーザを示す情報(たとえば、ユーザID)を含む。また、ゲームデータに、上記のように、収集したキャラクタについてのデータ(以下、「キャラクタデータ」という)が含まれる。
【0054】
この実施例では、セーブデータはゲーム装置12の内部に設けられたフラッシュメモリ24に記憶されるが、限定される必要はない。セーブデータはゲーム装置12に外付けされたメモリに記憶されてもよい。外付けされたメモリとしては、ゲーム装置12に着脱可能なSDカード、USBメモリ、外付けHDDを用いることができる。また、セーブデータは、クラウド上の所定のサーバに記憶されてもよい。
【0055】
ボタン110は、ゲームの選択を止めて、メインメニュー画面に戻るためのボタンである。ボタン112は、選択したゲームを確定するためのボタンである。ボタン112がオンされると、ゲーム装置12はサーバ16と連携し、ユーザの操作に従ってキャラクタを移動することができる。
【0056】
図5はゲーム装置12の表示装置36に表示される移動画面200の限定しない一例を示す図である。移動画面200は、ゲーム選択画面100でボタン112がオンされ、キャラクタを移動するゲームが選択されたことに応じて表示装置36に表示される。
【0057】
なお、
図5では、ゲーム選択画面100においてゲームAが選択された場合についての移動画面200の例が示される。
【0058】
図5に示すように、移動画面200は、表示領域202および表示領域204を含む。表示領域202は、ゲーム装置12側において、ゲーム選択画面100で選択された仮想のゲーム(ここでは、ゲームA)で利用される1または複数のキャラクタのキャラクタ画像206を表示するための領域である。つまり、仮想のゲームのセーブデータに含まれるキャラクタデータに対応する1または複数のキャラクタのキャラクタ画像206が表示される。また、表示領域202の右上方に、ゲームの種類を示す文字列(ここでは、ゲームA)202aが表示される。表示領域204は、サーバ16において、預かっているキャラクタのキャラクタ画像206を表示するための領域である。ただし、表示領域202および表示領域204に表示されるキャラクタ画像206は、同じユーザが所有するキャラクタのキャラクタ画像206である。
【0059】
図示は省略するが、表示領域202および表示領域204に表示されるのは、一部のキャラクタのキャラクタ画像206であり、それぞれ、スクロールすることでユーザが所有する他のキャラクタのキャラクタ画像206を表示することができる。
【0060】
詳細な説明は省略するが、ゲーム装置12で利用されるキャラクタを格納する複数の仮想のボックスおよびサーバ16で預かっているキャラクタを格納する複数の仮想のボックスが設けられており、上記のように、スクロールすると、仮想のボックスが変更され、変更された仮想のボックスに格納された1または複数のキャラクタのキャラクタ画像206が表示される。キャラクタが仮想のボックスに格納されていない場合には、キャラクタ画像206は表示されない。また、仮想のボックスは、それぞれ、識別可能な情報(一例として、シリアル番号)が付されており、現在表示されている1または複数のキャラクタが格納されている、または、キャラクタが格納されていない、仮想のボックスのシリアル番号が、表示領域202および表示領域204の近傍に、それぞれ、表示される。一例として、表示領域202の上方の「ゲーム装置側」の文字列および表示領域204の上方の「サーバ側」の文字列の横に、それぞれ、シリアル番号が表示される。ただし、表示領域202および表示領域204は、個別にスクロールできる。また、一例として、ゲーム装置12で利用されるキャラクタを格納する仮想のボックスのシリアル番号はユーザによって指定され、サーバ16で預かっているキャラクタを格納する仮想のボックスのシリアル番号はサーバ16(つまり、CPU50)によって指定される。
【0061】
また、
図5に示すように、移動画面200は、ボタン210、ボタン212およびボタン214を含む。
図5に示す例では、ボタン210およびボタン212は表示領域202の下方に設けられ、ボタン214は表示領域204の下方に設けられる。ボタン210は、キャラクタの移動を終了して、ゲーム選択画面100に戻るためのボタンである。ボタン212は、キャラクタの移動を終了して、メインメニューに戻るためのボタンである。ボタン214は、キャラクタを移動させた状態を保存するためのボタンである。
【0062】
さらに、
図5に示すように、移動画面200上には、指示画像220が表示され、ユーザは、指示画像220を移動させたり、キャラクタ画像206を選択したり、ボタン210、212、214をオンしたりすることができる。
【0063】
ユーザは、キャラクタをサーバ16に預ける場合には、表示領域202に表示された1または複数のキャラクタ画像206を選択し、表示領域204に移動させる。たとえば、ユーザは、選択された1または複数のキャラクタ画像206をドラッグ&ドロップする。この操作は、キャラクタを引き出す場合も同じである。一方、ユーザは、キャラクタをサーバ16から引き出す場合には、表示領域204に表示された1または複数のキャラクタ画像206を選択し、表示領域202に移動させる。キャラクタ画像206を移動させ、保存することで、キャラクタの移動が確定する。
【0064】
ただし、保存せずに、ゲーム選択画面100またはメインメニュー画面に戻った場合には、キャラクタ画像206を移動していた場合であっても、キャラクタの移動は確定しない。つまり、キャラクタの移動がキャンセルされる。
【0065】
また、ユーザは、選択された1または複数のキャラクタ画像206を再度選択すると、当該1または複数のキャラクタ画像206の選択された状態が解除される。ただし、これは一例であり、キャラクタ画像206が選択された状態を解除する方法は他の方法でもよい。
【0066】
図6-
図9はゲーム装置12で利用するキャラクタをサーバ16に預ける場合の処理について説明するための図である。
図10および
図11はサーバ16で保持または管理されるキャラクタデータのフォーマットを説明するための図である。
図12-
図13はサーバ16に預けたキャラクタをゲーム装置12で利用するために引き出す場合の処理について説明するための図である。
【0067】
以下、
図6-
図13を参照しながら、キャラクタを預けたり引き出したりする場合の処理について説明する。ただし、分かり易く説明するために、
図6-
図9では、ゲーム装置12においてゲームAで利用した第1キャラクタおよび第2キャラクタをサーバ16に預ける場合の処理について説明する。また、同様に、
図12-
図13では、サーバ16に預けた第1キャラクタおよび第2キャラクタをゲーム装置12においてゲームBで利用するために引き出す場合の処理について説明する。
【0068】
ただし、第1キャラクタについては、ゲーム装置12において過去にゲームAで利用したことが無い場合について説明する。
【0069】
図6に示すように、ゲームAで利用した第1キャラクタおよび第2キャラクタをサーバ16に預ける場合、ゲーム装置12では、クライアント側データ管理プログラム(「クライアント側アプリ」ともいう)が、ゲームAのセーブデータから第1キャラクタのキャラクタデータおよび第2キャラクタのキャラクタデータを取得する。
【0070】
次に、クライアント側アプリは、サーバ16で保存するために、第1キャラクタのキャラクタデータおよび第2キャラクタのキャラクタデータのフォーマットを変換する。フォーマットが変換されたキャラクタデータ(以下、「預入用キャラクタデータ」と呼ぶことがある)は、共通領域および仮想のゲーム(ここでは、ゲームA)の固有領域を有している。共通領域は、キャラクタをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームに共通して用いられる、キャラクタについてのパラメータ群を含む。ゲームの固有領域は、キャラクタをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含む。共通領域に含まれるパラメータ群および個別領域に含まれるパラメータ群については、後述する。
【0071】
なお、
図6では、フォーマット変換後のキャラクタデータに対応するキャラクタを示すために、第1キャラクタおよび第2キャラクタを表記してあるが、後述するように、キャラクタの固有の識別情報は、共通領域に含まれる。
【0072】
クライアント側アプリは、フォーマットを変換した第1キャラクタの預入用キャラクタデータおよびフォーマットを変換した第2キャラクタの預入用キャラクタデータをサーバ16に送信する。
【0073】
キャラクタがサーバ16に預けられる場合、サーバ側データ管理プログラム(「サーバ側アプリ」ともいう)は、このキャラクタを管理するための固有の識別情報(以下、「ユニークID」という)を付与する。このユニークIDは、サーバ側アプリによって発行され、キャラクタに付与される。ゲーム側アプリで発行すると、ユーザが複数台のゲーム装置12を使用する場合に、ユニークIDが重複してしまう不都合があるからである。ユニークIDは、サーバ16でキャラクタを管理するためのユニークな情報である。ただし、一度サーバ16に預けたことのあるキャラクタについては、ユニークIDが既に付与されているため、再度発行および付与されることはない。
【0074】
ここでは、第1キャラクタはサーバ16に預けたことがあり、第2キャラクタはサーバ16に預けたことがないものと仮定する。また、一度預けたことがあるキャラクタについては、キャラクタ管理DB54aに管理情報が記憶され、キャラクタ情報DB54bにサーバ16に預けられたキャラクタについてのキャラクタデータ(以下、「引出用キャラクタデータ」と呼ぶことがある)が記憶される。引出用キャラクタデータは、キャラクタ毎に生成され、キャラクタ情報DB54bに記憶される。
【0075】
管理情報は、キャラクタを預けたユーザのユーザIDを含み、このユーザIDに対応付けられた、当該キャラクタのユニークID、当該キャラクタが格納された仮想のボックスの番号、および、引き出し可能かどうかを示す情報(以下、「フラグ情報」という)をさらに含む。フラグ情報は、対応するキャラクタがサーバ16に預けられている場合には、「true(つまり、引き出し可能)」に設定され、対応するキャラクタがサーバ16に預けられていない場合には、「false(つまり、引き出し不可)」に設定される。引出用キャラクタデータについては、後で詳細に説明する。
【0076】
第1キャラクタおよび第2キャラクタをサーバ16に預ける前では、
図7に示すように、キャラクタ情報DB54bにおいて、第1のキャラクタの引出用キャラクタデータは保持されているが、第2のキャラクタの引出用キャラクタデータは保持されていない。
【0077】
図7に示すように、第1キャラクタの引出用キャラクタデータは、共通領域と、ゲームBの固有領域およびゲームCの固有領域を有している。後述するように、引出用キャラクタデータは、共通領域と、1または複数の固有領域を含む作品別領域を有している(
図10参照)。
図7に示す例では、第1キャラクタの引出用キャラクタデータは、作品別領域に、ゲームBの固有領域およびゲームCの固有領域を有している。したがって、第1キャラクタは、ゲーム装置12において、ゲームBおよびゲームCのそれぞれで利用されたことがあることが分かる。また、第1キャラクタは、ゲームAで利用されているが、ゲームAで利用された後にサーバ16に預けられたことはない。上述したように、第2キャラクタは、サーバ16に預けられたことが無いため、引出用キャラクタデータはキャラクタ情報DB54bに記憶(または、保持)されていない。また、第2キャラクタについては、管理情報もキャラクタ管理DB54aに記憶されていない。
【0078】
図8に示すように、サーバ側アプリは、ゲーム装置12から受信した第1キャラクタの預入用キャラクタデータで、キャラクタ情報DB54bに記憶された第1キャラクタの引出用キャラクタデータを補完する。このとき、第1キャラクタの引出用キャラクタデータに含まれる共通領域のパラメータ群は、受信した預入用キャラクタデータに含まれる共通領域のパラメータ群で上書き(つまり、更新)される。
【0079】
図示は省略するが、第1キャラクタが過去にゲームAで利用されていた場合には、引出用キャラクタデータには、ゲームAの固有領域も含まれるため、この場合には、ゲームAの固有領域のパラメータ群が、受信した預入用キャラクタデータに含まれるゲームAの固有領域のパラメータ群で上書きされる。
【0080】
また、サーバ側アプリは、ゲーム装置12から第2キャラクタの預入用キャラクタデータを受信すると、第2キャラクタに対してユニークIDを発行および付与して、第2キャラクタの引出用キャラクタデータを生成する。
【0081】
サーバ側アプリは、第1キャラクタの引出用キャラクタデータを補完し、第2キャラクタの引出用キャラクタデータを生成すると、第1キャラクタの引出用キャラクタデータおよび第2キャラクタの引出用キャラクタデータをキャラクタ情報DB54bに記憶する。つまり、
図9に示すように、サーバ側アプリは、補完した第1キャラクタの引出用キャラクタデータをキャラクタ情報DB54bに上書きし、生成した第2キャラクタの引出用キャラクタデータをキャラクタ情報DB54bに新規に登録する。
【0082】
詳細な説明は省略するが、サーバ側アプリは、第1キャラクタの引出用キャラクタデータおよび第2キャラクタの引出用キャラクタデータをキャラクタ情報DB54bに記憶するときに、キャラクタ管理DB54aに記憶される第1キャラクタの管理情報を更新し、第2キャラクタの管理情報を生成して、キャラクタ管理DB54aに記憶する。
【0083】
図10は、
図9に示したように、キャラクタ情報DB54bに記憶された第1キャラクタの引出用キャラクタデータの一例を示す。
図10に示すように、第1キャラクタの引出用キャラクタデータは、共通領域および作品別領域を含む。
【0084】
共通領域には、第1キャラクタについての共通の情報として、ユニークID、モンスター種別番号、経験値、特性番号、性別、HP決定用パラメータA、攻撃決定用パラメータA、防御決定用パラメータA、速さ決定用パラメータA、ニックネーム、HP決定用パラメータB、攻撃決定用パラメータB、防御決定用パラメータB、速さ決定用パラメータB、捕まえたゲームのバージョン、プレイヤ名、獲得日および獲得場所が記載される。
【0085】
ユニークIDは、当該キャラクタ(ここでは、「第1キャラクタ」)に付与された固有のIDであり、サーバ側アプリによって付与される。モンスター種別番号は、当該キャラクタの種別を示す番号である。経験値は、戦闘の経験値であり、経験値が上がると、当該キャラクタのレベルが上昇される。特性番号は、当該キャラクタに設定された特性を識別するための番号である。性別は、当該キャラクタの性別であり、オス、メスまたは性別不明のいずれかである。
【0086】
HP決定用パラメータAは、戦闘の結果において、当該キャラクタのHPを決定するためのパラメータである。ただし、HPは、当該キャラクタの体力を示すヒットポイントである。攻撃決定用パラメータAは、戦闘の結果において、当該キャラクタの攻撃力を決定するためのパラメータである。防御決定用パラメータAは、戦闘の結果において、当該キャラクタの防御力を決定するためのパラメータである。速さ決定用パラメータAは、戦闘の結果において、当該キャラクタの攻撃の素早さを決定するためのパラメータである。HP決定用パラメータA、攻撃決定用パラメータA、防御決定用パラメータA、速さ決定用パラメータAは、少なくともいずれかのゲーム内において、戦闘回数に応じて所定の上限まで上昇するように設定されていてもよい。
【0087】
ニックネームは、ユーザが当該キャラクタに付けたニックネームである。HP決定用パラメータBは、キャラクタ毎に予め設定された、当該キャラクタのHPを決定するためのパラメータである。攻撃決定用パラメータBは、キャラクタ毎に予め設定された、当該キャラクタの攻撃力を決定するためのパラメータである。防御決定用パラメータBは、キャラクタ毎に予め設定された、当該キャラクタの防御力を決定するためのパラメータである。速さ決定用パラメータBは、キャラクタ毎に予め設定された、当該キャラクタの攻撃の素早さを決定するためのパラメータである。HP決定用パラメータB、攻撃決定用パラメータB、防御決定用パラメータB、速さ決定用パラメータBは、少なくともいずれかのゲーム内において、初めて当該キャラクタを入手した際に所定の範囲内においてランダムな値が設定され、変動しないように設定されていてもよい。
【0088】
少なくともいずれかのゲーム内において、キャラクタの最大HPは、少なくともモンスターの種別によってゲーム内で予め定められた固定値、HP決定用パラメータA、HP決定用パラメータBを加算した値がゲーム内の当該キャラクタの最大HPとされるようにしてもよい。攻撃、防御、速さについても同様である。
【0089】
捕まえたゲームのバージョンは、当該キャラクタを捕獲または取得したゲームのバージョン(または、種類)を識別するための情報である。プレイヤ名は、当該キャラクタを捕獲または取得したユーザの名称である。獲得日は、当該キャラクタを捕獲または取得した日付(実施例では、年月日)である。獲得場所は、当該キャラクタを捕獲または取得した仮想空間における場所である。
【0090】
図11は
図10に示した作品別領域の具体的な内容の限定しない一例を示す。作品領域は、キャラクタが過去に利用された1または複数のゲームの固有領域をゲームの種類毎に含む。
図11に示す例では、ゲームAの固有領域、ゲームBの固有領域およびゲームCの固有領域を含む。
【0091】
ゲームAの固有領域には、ゲームAにおける第1キャラクタの固有の情報として、所持技、所持技の残り回数、技回数アップ使用回数、固有イベント遊び度および捕獲アイテム種類が記載される。
【0092】
所持技は、当該キャラクタ(ここでは、「第1キャラクタ」)がゲームAにおいて使用可能な技の種類である。所持技の残り回数は、当該キャラクタがゲームAにおいて使用可能な技の種類毎の使用可能な回数である。技回数アップ使用回数は、当該キャラクタの技の使用可能な回数を増やすアイテムを使用可能な回数である。固有イベント遊び度は、当該キャラクタを用いて固有イベントをプレイした回数または度合である。捕獲アイテム種類は、当該キャラクタが獲得または取得したアイテムの種類である。
【0093】
ゲームBの固有領域には、ゲームBにおける第1キャラクタの固有の情報として、特殊個体フラグ、サイズ、所持技、所持技の残り回数、HP決定用パラメータC、攻撃決定用パラメータC、防御決定用パラメータC、速さ決定用パラメータCおよび捕獲アイテム種類が記載される。
【0094】
特殊個体フラグは、当該キャラクタ(ここでは、「第1キャラクタ」)が特殊個体であることを示すフラグ情報である。この実施例では、特殊個体のキャラクタは、仮想空間において周辺に存在する他のキャラクタよりも大きく、レベルが高く、強いキャラクタを意味する。フラグ情報は、当該キャラクタが特殊個体であるため、「true」に設定される。サイズは、仮想空間における当該キャラクタの大きさ(この実施例では、高さおよび重さ)である。所持技は、当該キャラクタがゲームBにおいて使用可能な技の種類である。所持技の残り回数は、当該キャラクタがゲームBにおいて使用可能な技の種類毎の使用可能な回数である。
【0095】
HP決定用パラメータCは、戦闘の結果において、当該キャラクタのHPを決定するためのパラメータである。攻撃決定用パラメータCは、戦闘の結果において、当該キャラクタの攻撃力を決定するためのパラメータである。防御決定用パラメータCは、戦闘の結果において、当該キャラクタの防御力を決定するためのパラメータである。速さ決定用パラメータCは、戦闘の結果において、当該キャラクタの攻撃の素早さを決定するためのパラメータである。捕獲アイテム種類は、当該キャラクタを捕獲したときに使用したアイテムの種類である。
【0096】
ゲームBにおいて、キャラクタの最大HPは、共通領域内のHP決定用パラメータA、HP決定用パラメータBを用いずに、モンスターの種別によってゲームB内で予め定められた固定値と、ゲームB内で用いられるHP決定用パラメータCを加算した値が最大HPとされるようにしてもよい。攻撃、防御、速さについても同様である。
【0097】
このとき、HP決定用パラメータC、攻撃決定用パラメータC、防御決定用パラメータCおよび速さ決定用パラメータCの初期値を、それぞれ、共通領域に記載された、HP決定用パラメータB、攻撃決定用パラメータB、防御決定用パラメータBおよび速さ決定用パラメータBに対応させることで、他のゲームでもゲームBで入手したキャラクタを利用することができる。ゲームBにおいて連動していてもよいし、他のゲームで初めて当該キャラクタを利用する場合に補完されるようにしてもよい。また、第1キャラクタをゲームBで入手して他のゲームで使用していない場合、HP決定用パラメータA、攻撃決定用パラメータA、防御決定用パラメータAおよび速さ決定用パラメータAはすべて0のままである。
【0098】
ゲームCの固有領域には、ゲームCにおける第1キャラクタの固有の情報として、所持技、所持技の残り回数、技回数アップ使用回数、固有イベント遊び度および捕獲アイテム種類が記載される。各固有の情報は、ゲームAの固有領域で説明した内容と同じであるため、重複した説明は省略する。
【0099】
なお、簡単に説明するために、
図10および
図11では、共通領域および各固有領域に含まれるパラメータ群の一部を示してある。
【0100】
図12および
図13を用いて、第1キャラクタおよび第2キャラクタをゲームBで利用するために引き出す場合の処理について説明する。ゲーム選択画面100でゲームBが選択され、移動画面200が表示されるとき、ゲーム装置12の要求に応じて、サーバ16は預かっている1または複数のキャラクタについての引出用キャラクタデータを要求元のゲーム装置12にすべて送信する。したがって、サーバ16は預かっていない1または複数のキャラクタについての引出用キャラクタデータはゲーム装置12に送信しない。
【0101】
移動画面200では、表示領域204に、サーバ16で預かっている1または複数のキャラクタを表示することができる。上述したように、第1キャラクタおよび第2キャラクタはサーバ16に預けられているため、移動画面200では、第1キャラクタのキャラクタ画像206および第2キャラクタのキャラクタ画像206が表示領域204に表示することができる。
【0102】
この場合、クライアント側アプリは、第1キャラクタについての引出用キャラクタデータから共通領域とゲームBで利用するためのゲームBの固有領域を抽出し、抽出した共通領域と固有領域すなわち第1キャラクタのキャラクタデータに基づいて移動画面200の表示領域204に第1キャラクタのキャラクタ画像206を表示する。
【0103】
また、クライアント側アプリは、第2キャラクタについての引出用キャラクタデータから共通領域を抽出し、ゲームBで利用するためのゲームBの固有領域をデフォルトで生成し、抽出した共通領域と生成した固有領域すなわち第2キャラクタのキャラクタデータに基づいて移動画面200の表示領域204に第2キャラクタのキャラクタ画像206を表示する。上述したように、第2キャラクタは、ゲームAで利用されただけで、他のゲーム(ここでは、ゲームB)では利用されたことがないため、引出用キャラクタデータには、ゲームBの固有領域は含まれていない。したがって、移動画面200に第2キャラクタのキャラクタ画像206を表示し、さらには、ゲームBで利用するために、ゲームBの固有領域をデフォルトで生成するようにしてある。
【0104】
さらに、クライアント側アプリは、第1キャラクタのキャラクタ画像206および第2キャラクタのキャラクタ画像206が表示領域202に移動された状態で保存が実行されると、つまり、第1キャラクタおよび第2キャラクタをゲームBで利用するために引き出すことが決定されると、第1キャラクタおよび第2キャラクタがゲームBのセーブデータに含められる。具体的には、
図13に示すように、クライアント側アプリは、第1キャラクタのキャラクタデータおよび第2キャラクタのキャラクタデータをゲームBで利用するためのフォーマットに変換する。そして、クライアント側アプリは、変換した第1キャラクタのキャラクタデータおよび第2キャラクタのキャラクタデータを、ゲームBで利用している他のキャラクタのキャラクタデータとともに保存する。つまり、第1キャラクタのキャラクタデータおよび第2キャラクタのキャラクタデータを含むゲームBのセーブデータがフラッシュメモリ24に記憶(上書き)される。このようにして、第1キャラクタおよび第2キャラクタがサーバ16からゲーム装置12に引き出される。
【0105】
つまり、ゲーム装置12では、クライアント側アプリは、キャラクタを引き出すときには、過去に利用したことのあるゲームで利用する場合には、引出用キャラクタデータから、共通領域とそのゲームの固有領域を抽出し、過去に利用したことのないゲームで利用する場合には、引出用キャラクタデータから、共通領域を抽出し、そのゲームの固有領域をデフォルトで生成する。
【0106】
このように、引き出したキャラクタを、過去に利用したことのあるゲームで利用する場合には、引出用キャラクタデータから、共通領域とそのゲームの固有領域を抽出するので、他のゲームの固有領域が引出用キャラクタデータに含まれていても、引き出したキャラクタを利用するゲーム側で他のゲームの固有領域に対応する必要はない。
【0107】
ゲームの固有領域をデフォルトで生成する場合には、固有領域に含まれるパラメータ群を0等の適切なデフォルト値に設定する。または、他の固有領域を参照して、互換性のあるパラメータが発見された場合には、そのパラメータを使用するようにしてもよい。たとえば、互換性のあるパラメータは、捕獲アイテム種類である。
【0108】
また、クライアント側アプリは、第1キャラクタおよび第2キャラクタを引き出すと、第1キャラクタおよび第2キャラクタを引き出し不可にすることを、サーバ16(すなわち、サーバ側アプリ)に通知する。
【0109】
したがって、サーバ16では、サーバ側アプリは、引き出し不可にすることを通知したゲーム装置12のユーザのユーザIDが記載された第1キャラクタおよび第2キャラクタの管理情報に含まれるフラグ情報を「false(つまり、引き出し不可)」に設定する。
【0110】
図14は
図2に示したゲーム装置12のRAM22のメモリマップ300の一例を示す図である。
図14に示すように、RAM22は、プログラム記憶領域302およびデータ記憶領域304を含む。プログラム記憶領域302には、通信プログラム302a、画像表示プログラム302b、ゲームAプログラム302c、ゲームBプログラム302d、ゲームCプログラム302eおよびクライアント側データ管理プログラム302fなどが記憶される。
【0111】
通信プログラム302aは、第1通信モジュール26を用いて他の機器(この実施例では、サーバ16および他のゲーム装置など)と通信したり、第2通信モジュール28を用いて無線LANを介して他の機器(他のゲーム装置など)と通信したりするためのプログラムである。
【0112】
画像表示プログラム302bは、ゲーム画像(上記の各種の画面100、200など)のデータ(ゲーム画像データ)を生成し、生成したゲーム画像データを表示装置36に出力するためのプログラムである。したがって、ゲーム画像データに対応するゲーム画像が表示装置36に表示される。
【0113】
ゲームAプログラム302cは、ゲームAのアプリケーションプログラムである。ゲームBプログラム302dは、ゲームBのアプリケーションプログラムである。ゲームCプログラム302eは、ゲームCのアプリケーションプログラムである。
【0114】
クライアント側データ管理プログラム302fは、クライアントすなわちゲーム装置12側でキャラクタデータを管理するためのアプリケーションプログラム(すなわち、クライアント側アプリ)であり、具体的には、後述するクライアント側のデータ管理処理(
図16-
図18参照)を実行するためのプログラムである。
【0115】
図示は省略するが、プログラム記憶領域302には、ゲームデータをフラッシュメモリ24に保存するためのプログラム、ゲームに必要な音を生成および出力するための音出力プログラムなどの他のプログラムも記憶される。
【0116】
なお、ゲームAプログラム302c、ゲームBプログラム302dおよびゲームCプログラム303eは、常に、RAM22に記憶されている必要はなく、ゲームA、ゲームBまたはゲームCをプレイする場合に、フラッシュメモリ24、ゲーム装置12に装着可能な他の記憶媒体、または、ネットワーク14から取得されればよい。
【0117】
データ記憶領域304には、操作入力データ304a、セーブデータ304b、引出用キャラクタデータ304c、表示用キャラクタデータ304dおよび移動候補キャラクタデータ304eなどが記憶される。
【0118】
操作入力データ304aは、入力装置30から入力された操作データである。操作データは、CPU20の処理に使用されると、消去される。
【0119】
セーブデータ304bは、ゲーム選択画面100で選択されたゲーム(この実施例では、ゲームA、ゲームBまたはゲームC)のセーブデータであって、フラッシュメモリ24から読み出される。また、キャラクタを引き出した場合には、セーブデータ304bは更新された後に、フラッシュメモリ24に記憶(または、上書き)される。
【0120】
引出用キャラクタデータ304cは、移動画面200を表示装置36に表示する場合に、サーバ16から送信された1または複数のキャラクタの各々についての引出用キャラクタデータである。
【0121】
表示用キャラクタデータ304dは、移動画面200の表示領域202に表示される1または複数のキャラクタ画像206の各々に対応するキャラクタデータと、移動画面200の表示領域204に表示される1または複数のキャラクタのキャラクタ画像206の各々に対応するキャラクタデータである。ただし、キャラクタ画像206に対応するキャラクタデータは、表示領域202に表示する(すなわち、ゲーム装置12に格納されている)こと、または、表示領域204に表示する(すなわち、サーバ16に預けられている)ことが識別可能に分類されている。
【0122】
移動画面200の表示領域202に表示される1または複数のキャラクタのキャラクタデータは、ゲーム選択画面100で選択されたゲーム(この実施例では、ゲームA、ゲームBまたはゲームC)のセーブデータ304bから取得した1または複数のキャラクタのキャラクタデータである。
【0123】
また、移動画面200の表示領域204に表示される1または複数のキャラクタのキャラクタデータは、サーバ16から送信された1または複数のキャラクタの各々についての引出用キャラクタデータであり、移動画面200を最初に表示するとき、引出用キャラクタデータ304cがコピーされる。ただし、コピーされるのは、1または複数のキャラクタの各々についての引出用キャラクタデータのうち、共通領域と、ゲーム選択画面100で選択されたゲームの固有領域である。ゲーム選択画面100で選択されたゲームの固有領域が引出用キャラクタデータに含まれていないキャラクタについては、ゲーム選択画面100で選択されたゲームの固有領域がデフォルトで生成される。
【0124】
移動画面200においてキャラクタ画像206が表示領域202と表示領域204の間で移動されると、表示用キャラクタデータ304dにおいて、移動されたキャラクタについての表示領域202または表示領域204の分類が変更される。
【0125】
移動候補キャラクタデータ304eは、移動画面200において表示領域202と表示領域204の間で移動されたキャラクタの識別情報および移動後の表示領域202または表示領域204の識別情報のデータである。ここで、キャラクタの識別情報は、ユニークIDであるが、ユニークIDが付与されていないキャラクタについては、当該キャラクタの預入用キャラクタデータ自体である。また、表示領域202の識別情報はゲーム装置12側であることとゲーム装置12側の仮想のボックスの番号であり、表示領域204の識別情報はサーバ16側であることとサーバ16側の仮想のボックスの番号である。ただし、キャラクタが元の表示領域202または表示領域204に移動される(つまり、戻される)と、当該キャラクタについての移動候補キャラクタデータ304eは消去される。
【0126】
移動画面200において、保存が実行されると、表示領域204から表示領域202に移動されたキャラクタのキャラクタデータが、選択されているゲームのセーブデータに含めて保存される。また、移動画面200において、保存が実行されると、表示領域202から表示領域204に移動されたキャラクタのキャラクタデータがサーバ16に送信され、当該キャラクタデータは、選択されているゲームのセーブデータから削除される。
【0127】
図示は省略するが、データ記憶領域304には、データ管理処理に必要な他のデータが記憶されたり、データ管理処理に必要なフラグおよびカウンタ(タイマ)が設けられたりする。
【0128】
図15は
図3に示したサーバ16のRAM52のメモリマップ500の限定しない一例を示す図である。
図15に示すように、RAM52は、プログラム記憶領域502およびデータ記憶領域504を含む。プログラム記憶領域502には、通信プログラム502aおよびサーバ側データ管理プログラム502bなどが記憶される。
【0129】
通信プログラム502aは、通信モジュール56を用いて他の機器(この実施例では、ゲーム装置12および他のゲーム装置など)と通信するためのプログラムである。
【0130】
サーバ側データ管理プログラム502bは、サーバ16側でキャラクタデータを管理するためのアプリケーションプログラム(すなわち、サーバ側アプリ)であり、具体的には、後述するサーバ側のデータ管理処理(
図19参照)を実行するためのプログラムである。
【0131】
図示は省略するが、プログラム記憶領域502には、データ管理のために必要な他のプログラムも記憶される。
【0132】
データ記憶領域504には、受信キャラクタデータ504a、更新キャラクタデータ504bおよび送信キャラクタデータ504cなどが記憶される。
【0133】
受信キャラクタデータ504aは、ゲーム装置12から受信した1または複数の預入用キャラクタデータである。更新キャラクタデータ504bは、ゲーム装置12がキャラクタを預ける場合に、補完されたり、生成されたりした1または複数の引出用キャラクタデータである。送信キャラクタデータ504cは、ゲーム装置12に送信するための1または複数の引出用キャラクタデータであって、キャラクタ情報DB54bから取得される。
【0134】
図示は省略するが、データ記憶領域504には、データ管理処理に必要な他のデータが記憶されたり、データ管理処理に必要なフラグおよびカウンタ(タイマ)が設けられたりする。
【0135】
図16-
図18は
図2に示したCPU20のクライアント側のデータ管理処理のフロー図である。このデータ管理処理は、ユーザがデータ管理アプリの実行を指示したことに応じて開始される。詳細な説明は省略するが、ユーザがクライアント側アプリの実行を指示してから、サーバ16に引出用キャラクタデータの送信が要求されるまでの間に、サーバ16によって、ゲーム装置12のユーザが認証される。
【0136】
図16に示すように、CPU20は、データ管理処理を開始すると、ステップS1で、
図4に示したようなゲーム選択画面100を表示装置36に表示する。次のステップS3では、キャラクタの移動処理を実行するかどうかを判断する。ここでは、アイコン102、104または106がオンされた状態で、ボタン112がオンされたかどうかを判断する。
【0137】
ステップS3で“NO”であれば、つまり、キャラクタの移動処理の実行でなければ、ステップS1に戻る。ただし、ユーザがアイコン102、104または106をオンした場合には、オンされたアイコン102、104または106に割り当てられたゲームが選択される、または、割り当てられたゲームの選択を解除される。ただし、ユーザがボタン110をオンした場合には、データ管理処理を終了して、メインメニューに戻る。一方、ステップS3で“YES”であれば、つまり、キャラクタの移動処理の実行であれば、ステップS5で、引出用キャラクタデータ304cの送信をサーバ16に要求する。
【0138】
続いて、ステップS7では、サーバ16から引出用キャラクタデータ304cを受信したかどうかを判断する。ステップS7で“NO”であれば、つまり、引出用キャラクタデータ304cを受信していなければ、ステップS7に戻る。
【0139】
一方、ステップS7で“YES”であれば、つまり、引出用キャラクタデータ304cを受信すれば、ステップS9で、表示用キャラクタデータ304dを記憶する。ここでは、CPU20は、ゲーム選択画面100で選択したゲームのセーブデータをフラッシュメモリ24から読み出し、さらに、このセーブデータからキャラクタデータを読み出し、読み出したキャラクタデータと、受信した引出用キャラクタデータをそれぞれ識別可能に分類した表示用キャラクタデータ304dを生成し、データ記憶領域304に記憶する。このとき、CPU20は、ゲーム選択画面100で選択されたゲームで利用されたことのないキャラクタの引出用キャラクタデータについては、当該ゲームの固有領域をデフォルトで生成して付与する。
【0140】
続くステップS11では、
図5に示したような移動画面200を表示装置36に表示する。次のステップS13では、移動操作が有るかどうかを判断する。ステップS13で“NO”であれば、つまり、移動操作が無ければ、
図18に示すステップS35に進む。ただし、移動操作が無い場合であっても、ユーザの操作に従って、指示画像220が移動されたり、1または複数のキャラクタ画像206が選択されたり、1または複数のキャラクタ画像206の選択が解除されたりする。また、ユーザがボタン210をオンした場合には、キャラクタの移動を終了して、ステップS1に戻る。
【0141】
一方、ステップS13で“YES”であれば、つまり、移動操作があれば、ステップS15で、移動操作に従って表示用キャラクタデータ304dを更新し、ステップS17で、移動操作に従ってキャラクタ画像206を移動し、
図17に示すステップS19で、移動候補キャラクタデータ304eを更新する。ここでは、移動操作に従って移動されたキャラクタ画像206に対応するキャラクタデータについての移動候補キャラクタデータ304eを生成して記憶したり、元の表示領域202または表示領域204に移動されたキャラクタ画像206対応するキャラクタデータについての移動候補キャラクタデータ304eを削除したりする。
【0142】
続くステップS21では、保存するかどうかを判断する。ここでは、CPU20は、ボタン214がオンされたかどうかを判断する。ステップS21で“NO”であれば、つまり、保存しない場合には、ステップS35に進む。一方、ステップS21で“YES”であれば、つまり、保存する場合には、ステップS23で、預けるキャラクタが有るかどうかを判断する。ここでは、CPU20は、表示領域204の識別情報を含む移動候補キャラクタデータ304eが有るかどうかを判断する。
【0143】
ステップS23で“NO”であれば、つまり、預けるキャラクタが無ければ、ステップS29に進む。一方、ステップS23で“YES”であれば、つまり、預けるキャラクタが有れば、ステップS25で、預けるキャラクタに対応するキャラクタデータすなわち預入用キャラクタデータをサーバ16に送信する。ただし、ステップS25では、CPU20は、サーバ16にキャラクタデータを送信する前に、フォーマットを変換して、預入用キャラクタデータを生成する。次のステップS27では、送信したキャラクタデータすなわちサーバ16に預けたキャラクタのキャラクタデータをセーブデータ304bから削除し、フラッシュメモリ24に上書きして、ステップS29に進む。
【0144】
なお、預けるキャラクタが2体以上である場合には、ステップS25およびS27の処理は、預ける2体以上のキャラクタのそれぞれについて実行される。
【0145】
ステップS29では、引き出すキャラクタが有るかどうかを判断する。ここでは、CPU20は、に、表示領域202の識別情報を含む移動候補キャラクタデータ304eが有るかどうかを判断する。
【0146】
ステップS29で“NO”であれば、つまり、引き出すキャラクタが無い場合には、ステップS35に進む。一方、ステップS29で“YES”であれば、つまり、引き出すキャラクタが有る場合には、ステップS31で、引き出すキャラクタに対応するキャラクタデータを含むセーブデータをフラッシュメモリ24に保存し、ステップS33で、引き出したキャラクタを引き出し不可状態にすることをサーバ16に通知して、ステップS35に進む。
【0147】
なお、引き出すキャラクタが2体以上である場合には、ステップS31およびS33の処理は、引き出す2体以上のキャラクタのそれぞれについて実行される。
【0148】
また、引き出すキャラクタに対応するキャラクタデータはセーブデータに含めて保存されるときに、ゲームで利用するフォーマットに変換される。
【0149】
図18に示すように、ステップS35では、終了するかどうかを判断する。ここでは、CPU20は、ボタン212がオンされたかどうかを判断する。ステップS35で“NO”であれば、つまり、終了しない場合には、
図16に示すステップS11に戻る。一方、ステップS35で“YES”であれば、つまり、終了する場合には、ステップS37で、移動処理の終了をサーバに通知して、データ管理処理を終了する。
【0150】
図19は
図3に示したサーバ16のCPU50のサーバ側のデータ管理処理の限定しない一例を示すフロー図である。詳細な説明は省略するが、ユーザがクライアント側アプリの実行を指示してから、サーバ16に引出用キャラクタデータの送信が要求されるまでの間に、サーバ16は、ゲーム装置12のユーザのユーザIDを用いて当該ユーザを認証している。
【0151】
図19に示すように、CPU50は、サーバ側のデータ管理処理を開始すると、ステップS101で、引出用キャラクタデータの送信要求が有るかどうかを判断する。ステップS101で“NO”であれば、つまり、引出用キャラクタデータの送信要求が無ければ、ステップS105に進む。一方、ステップS101で“YES”であれば、つまり、引出用キャラクタデータの送信要求が有れば、ステップS103で、要求元のゲーム装置12に引出用キャラクタデータを送信して、ステップS105に進む。ただし、引出用キャラクタデータは、要求元のゲーム装置12のユーザが所有するキャラクタについての引出用キャラクタデータである。
【0152】
ステップS105では、預入用キャラクタデータを受信したかどうかを判断する。ステップS105で“YES”であれば、預入用キャラクタデータを受信すれば、ステップS107で、受信した預入用キャラクタデータにユニークIDが付与されているかどうかを判断する。
【0153】
ステップS107で“YES”であれば、つまり、受信した預入用キャラクタデータにユニークIDが付与されている場合には、ステップS109で、引出用キャラクタデータすなわち引出用キャラクタデータの共通領域および作品別領域を更新して、ステップS113に進む。一方、ステップS107で“NO”であれば、つまり、受信した預入用キャラクタデータにユニークIDが付与されていない場合には、ステップS111で、ユニークIDを発行し、受信した預入用キャラクタデータに付与して、ステップS113に進む。
【0154】
ステップS113では、引き出し可能状態で、受信した預入用キャラクタデータを保存して、ステップS119に進む。つまり、ステップS113では、受信した預入用キャラクタデータに対応するキャラクタがサーバ16に預けられ、更新された引出用キャラクタデータをキャラクタ情報DB54bに記憶するとともに、フラグ情報を「true」に設定した当該キャラクタの管理情報をキャラクタ管理DB54aに記憶(または、更新)する。ただし、今回ユニークIDを発行したキャラクタについては、ステップS113では、管理情報が生成され、このとき、フラグ情報が「true」に設定される。
【0155】
また、ステップS105で“NO”であれば、つまり、預入用キャラクタデータを受信していなければ、ステップS115で、キャラクタを引き出し不可状態にすることの通知を受信したかどうかを判断する。ステップS115で“NO”であれば、つまり、キャラクタを引き出し不可状態にすることの通知を受信していなければ、ステップS119に進む。一方、ステップS115で“YES”であれば、つまり、キャラクタを引き出し不可状態にすることの通知を受信すれば、ステップS117で、当該キャラクタを引き出し不可状態に更新して、ステップS119に進む。ステップS117では、CPU50は、当該キャラクタの管理情報に含まれるフラグ情報を「false」に設定する。
【0156】
ステップS119では、ゲーム装置12から移動処理の終了の通知があるかどうかを判断する。ステップS119で“NO”であれば、つまり、ゲーム装置12から移動処理の終了の通知が無ければ、ステップS101に戻る。一方、ステップS119で“YES”であれば、つまり、ゲーム装置12から移動処理の終了の通知が有れば、データ管理処理を終了する。
【0157】
この実施例によれば、引出用キャラクタデータは、或るゲームで使用した共通領域と固有領域のみが更新または補完されてサーバで保持されるので、他の固有領域を他のゲームで使用することができる。したがって、1つのキャラクタを複数種類のゲームで使用することができる。つまり、複数種類のゲームでキャラクタを使う場合に、ゲームの種類ごとに異なるパラメータを使える状態でキャラクタを保持することができる。
【0158】
なお、この実施例では、ゲームに利用されたキャラクタをサーバに預け、当該ゲームの固有領域を含む引出用キャラクタデータを更新または生成するようにしたが、ゲーム装置で実行可能な特定の種類のゲームについては、当該特定の種類のゲームで利用されたかどうかに関係無く、引出用キャラクタデータを生成するときに、当該特定の種類のゲームの固有領域を引出用キャラクタデータに含めるようにしてもよい。この場合、何らかの目的で特定のゲームの固有領域が必ず含まれるようにすることができる。一例として、特定の種類のゲームの固有領域を含まない引出用キャラクタデータをクライアント側アプリが使用しないようにすることで、不正に生成された引出用キャラクタデータの使用を防止することができる。つまり、不正チェックの目的で特定のゲームの固有領域を引出用キャラクタデータに含めることができる。
【0159】
また、この実施例では、サーバを設けて、サーバにキャラクタを預けたり、サーバからキャラクタを引き出したりするようにしたが、これに限定される必要はない。ゲーム装置において、キャラクタを預けたり、キャラクタを引き出したりするようにしてもよい。この場合、たとえば、ゲーム装置のフラッシュメモリに、キャラクタ管理DBおよびキャラクタ情報を設け、ゲーム装置が
図19に示したサーバ側のデータ管理処理も実行する。
【0160】
さらに、この実施例では、キャラクタを引き出す場合に、クライアント側アプリが利用したことの無いゲームについての固有領域をデフォルトで生成するようにしたが、これに限定される必要はない。サーバ側アプリが引出用キャラクタデータを生成するときに、実行可能な複数のゲームの固有領域であって、ゲーム装置から受信した預入用キャラクタデータに含まれていない固有領域を除く1または複数の固有領域をデフォルトで生成するようにしてもよい。
【0161】
さらにまた、この実施例では、コンテンツの一例であるキャラクタを、サーバに預けたり、サーバから引き出したりする場合について説明したが、限定される必要はない。複数種類のゲームで利用されるアイテムを、サーバに預けたり、サーバから引き出したりすることもできる。
【0162】
また、この実施例で示した各種のゲーム画像およびゲーム装置の構成は単なる例示であり、限定されるべきでなく、実際の製品に応じて適宜変更可能である。
【0163】
さらに、同じ効果(結果)が得られる場合には、フロー図に示した各ステップの順番は適宜変更されてもよい。
【符号の説明】
【0164】
10 …コンテンツ保持システム
12 …ゲーム装置
16 …コンテンツ保持サーバ
20、50 …CPU
22、52 …RAM
24 …フラッシュメモリ
26 …第1通信モジュール
28 …第2通信モジュール
30、58 …入力装置
36、62 …表示装置
38 …スピーカ
54 …HDD
56 …通信モジュール
【手続補正書】
【提出日】2023-06-26
【手続補正1】
【補正対象書類名】明細書
【補正対象項目名】0007
【補正方法】変更
【補正の内容】
【0007】
(構成1)
構成1は、サーバと、当該サーバに接続可能な少なくとも1つの情報処理端末を含む、コンテンツ保持システムである。サーバは、複数種類のゲームで利用可能な少なくとも1つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、コンテンツデータを管理するサーバ管理プログラムを実行する第1のプロセッサを備え、コンテンツ記憶媒体に記憶されるコンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有している。情報処理端末は、複数種類のゲームのいずれかである第1のゲームのセーブデータである第1セーブデータを記憶する第1セーブデータ記憶媒体と、サーバと送受信するコンテンツを管理するクライアントプログラムを実行する第2のプロセッサを備え、クライアントプログラムは、第2のプロセッサに、第1セーブデータ記憶媒体から第1セーブデータを読み出させ、第1セーブデータに基づいて、第1のゲームで用いられた少なくとも1つの第1のコンテンツについて、共通領域と、第1のゲームに対応する固有領域である第1固有領域とを少なくとも含む預入用コンテンツデータを生成させ、生成された預入用コンテンツデータをサーバに送信させ、サーバ管理プログラムは、第1のプロセッサに、情報処理端末から第1のコンテンツに関する預入用コンテンツデータを受信した場合に、受信された預入用コンテンツデータに含まれる共通領域および第1固有領域を少なくとも含むコンテンツデータであって、かつ第1のコンテンツに関して第1固有領域以外の固有領域を有するコンテンツデータがコンテンツ記憶媒体に保持されている場合には当該保持された第1固有領域以外の固有領域をさらに含むコンテンツデータを、第1のコンテンツに関する最新のコンテンツデータとしてコンテンツ記憶媒体に記憶させる。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】0012
【補正方法】変更
【補正の内容】
【0012】
(構成4)
構成4は、上記構成2または上記構成3において、クライアントプログラムはさらに、第2のプロセッサに、受信された引出用コンテンツデータに第2固有領域が含まれない場合、当該第2固有領域に対応するパラメータ群を生成させて、第2セーブデータを更新して第2セーブデータ記憶媒体に記憶させる。
【手続補正3】
【補正対象書類名】明細書
【補正対象項目名】0017
【補正方法】変更
【補正の内容】
【0017】
(構成8)
構成8は、情報処理装置のコンピュータに実行されるコンテンツ管理プログラムである。情報処理装置は、複数種類のゲームのいずれかである第1のゲームのセーブデータである第1セーブデータを記憶する第1セーブデータ記憶媒体と、複数種類のゲームのいずれかである第2のゲームのセーブデータである第2セーブデータを記憶する第2セーブデータ記憶媒体とを備える。コンテンツ管理プログラムは、コンピュータに、第1の指示入力に基づいて、第1セーブデータ記憶媒体から、当該第1セーブデータを読み出させ、当該第1セーブデータに基づいて、第1のゲームで用いられた少なくとも1つの第1のコンテンツについて、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域のうち、第1のゲームに対応する第1固有領域とを少なくとも含む預入用コンテンツデータを生成させ、生成された預入用コンテンツデータをサーバに送信させ、第2の指示入力に基づいて、サーバに対して、複数種類のゲームのいずれかである第2のゲームで用いられる第1のコンテンツの送信要求を行わせ、当該送信要求に応じて、当該第1のコンテンツに関して、共通領域と第2のゲームに対応する固有領域である第2固有領域とを含む引出用コンテンツデータをサーバから受信させ、少なくとも引出用コンテンツデータに含まれる共通領域および第2固有領域に基づいて、第1のコンテンツが含まれるよう第2セーブデータを更新して第2セーブデータ記憶媒体に記憶させる。
【手続補正4】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
サーバと、当該サーバに接続可能な少なくとも1つの情報処理端末を含み、
前記サーバは、
複数種類のゲームで利用可能な少なくとも1つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、
前記コンテンツデータを管理するサーバ管理プログラムを実行する第1のプロセッサを備え、
前記コンテンツ記憶媒体に記憶される前記コンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、前記複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、前記複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有し、
前記情報処理端末は、
前記複数種類のゲームのいずれかである第1のゲームのセーブデータである第1セーブデータを記憶する第1セーブデータ記憶媒体と、
前記サーバと送受信する前記コンテンツを管理するクライアントプログラムを実行する第2のプロセッサを備え、
前記クライアントプログラムは、前記第2のプロセッサに、
前記第1セーブデータ記憶媒体から前記第1セーブデータを読み出させ、
当該第1セーブデータに基づいて、前記第1のゲームで用いられた少なくとも1つの第1のコンテンツについて、前記共通領域と、前記第1のゲームに対応する前記固有領域である第1固有領域とを少なくとも含む預入用コンテンツデータを生成させ、
生成された前記預入用コンテンツデータを前記サーバに送信させ、
前記サーバ管理プログラムは、前記第1のプロセッサに、
前記情報処理端末から前記第1のコンテンツに関する前記預入用コンテンツデータを受信した場合に、受信された前記預入用コンテンツデータに含まれる前記共通領域および前記第1固有領域を少なくとも含むコンテンツデータであって、かつ前記第1のコンテンツに関して前記第1固有領域以外の前記固有領域を有する前記コンテンツデータが前記コンテンツ記憶媒体に保持されている場合には当該保持された前記第1固有領域以外の前記固有領域をさらに含むコンテンツデータを、前記第1のコンテンツに関する最新の前記コンテンツデータとして前記コンテンツ記憶媒体に記憶させる、
コンテンツ保持システム。
【請求項2】
前記情報処理端末はさらに、
前記複数種類のゲームのいずれかである第2のゲームのセーブデータである第2セーブデータを記憶する第2セーブデータ記憶媒体を備え、
前記サーバ管理プログラムはさらに、前記第1のプロセッサに、
前記情報処理端末から、前記第2のゲームで用いられる前記第1のコンテンツの送信要求があった場合に、
当該第1のコンテンツの前記コンテンツデータに基づいて、前記共通領域を少なくとも含み、前記第2のゲームに対応する第2固有領域が保持されている場合は当該第2固有領域をさらに少なくとも含む引出用コンテンツデータを生成させ、
当該コンテンツデータを前記コンテンツ記憶媒体に保持させたまま、前記引出用コンテンツデータを前記情報処理端末に送信させ、
前記クライアントプログラムはさらに、前記第2のプロセッサに、
受信された前記引出用コンテンツデータに含まれる前記共通領域および前記第2固有領域に基づいて、前記第1のコンテンツが含まれるように前記第2セーブデータを更新して前記第2セーブデータ記憶媒体に記憶させる、請求項1記載のコンテンツ保持システム。
【請求項3】
前記引出用コンテンツデータは、前記第1のコンテンツに関する前記コンテンツデータにおける、前記共通領域および保持されているすべての前記固有領域を含む、請求項2記載のコンテンツ保持システム。
【請求項4】
前記クライアントプログラムはさらに、前記第2のプロセッサに、
受信された前記引出用コンテンツデータに前記第2固有領域が含まれない場合、当該第2固有領域に対応する前記パラメータ群を生成させて、前記第2セーブデータを更新して前記第2セーブデータ記憶媒体に記憶させる、請求項2記載のコンテンツ保持システム。
【請求項5】
前記サーバ管理プログラムは、前記第1のプロセッサにさらに、
前記情報処理端末から前記第1のコンテンツに関する前記預入用コンテンツデータを受信した場合に、前記第1のコンテンツが引出可能な状態として前記コンテンツデータを前記コンテンツ記憶媒体に記憶させ、
前記第1のコンテンツが引出可能な状態において前記情報処理端末から前記第1のコンテンツの送信要求があった場合に、前記コンテンツデータを前記コンテンツ記憶媒体に保持させたまま前記引出用コンテンツデータを前記情報処理端末に送信させ、かつ、前記第1のコンテンツが第2セーブデータに含まれるよう前記第2セーブデータ記憶媒体に記憶されている場合に前記第1のコンテンツが引出不可能な状態となるように前記コンテンツデータを保持させる、請求項2記載のコンテンツ保持システム。
【請求項6】
前記コンテンツデータの前記共通領域は、前記コンテンツ固有のIDを少なくとも含み、
前記サーバ管理プログラムは、前記第1のプロセッサにさらに、
前記情報処理端末から前記預入用コンテンツデータを受信した場合に、前記第1のコンテンツに前記IDが無い場合には新規に前記IDを付与した上で、前記コンテンツデータを前記コンテンツ記憶媒体に記憶させる、請求項1から5のいずれか記載のコンテンツ保持システム。
【請求項7】
前記預入用コンテンツデータは、前記複数種類のゲームのいずれかである第3のゲームに対応する前記固有領域である第3固有領域をさらに含む、請求項1または2記載のコンテンツ保持システム。
【請求項8】
情報処理装置のコンピュータに実行されるコンテンツ管理プログラムであって、
前記情報処理装置は、複数種類のゲームのいずれかである第1のゲームのセーブデータである第1セーブデータを記憶する第1セーブデータ記憶媒体と、前記複数種類のゲームのいずれかである第2のゲームのセーブデータである第2セーブデータを記憶する第2セーブデータ記憶媒体とを備え、
前記コンピュータに、
第1の指示入力に基づいて、
前記第1セーブデータ記憶媒体から、当該第1セーブデータを読み出させ、
当該第1セーブデータに基づいて、前記第1のゲームで用いられた少なくとも1つの第1のコンテンツについて、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、前記複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、前記複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域のうち、前記第1のゲームに対応する第1固有領域とを少なくとも含む預入用コンテンツデータを生成させ、
生成された前記預入用コンテンツデータをサーバに送信させ、
第2の指示入力に基づいて、
前記サーバに対して、前記複数種類のゲームのいずれかである第2のゲームで用いられる前記第1のコンテンツの送信要求を行わせ、
当該送信要求に応じて、当該第1のコンテンツに関して、前記共通領域と前記第2のゲームに対応する前記固有領域である第2固有領域とを含む引出用コンテンツデータを前記サーバから受信させ、
少なくとも前記引出用コンテンツデータに含まれる前記共通領域および前記第2固有領域に基づいて、前記第1のコンテンツが含まれるよう前記第2セーブデータを更新して前記第2セーブデータ記憶媒体に記憶させる、
コンテンツ管理プログラム。
【請求項9】
複数種類のゲームで利用可能な少なくとも1つのコンテンツのデータであるコンテンツデータを当該コンテンツ毎に記憶するコンテンツ記憶媒体と、
前記コンテンツデータを管理する管理プログラムを実行するプロセッサを備え、
前記コンテンツ記憶媒体に記憶される前記コンテンツデータは、コンテンツ毎にそれぞれ、当該コンテンツをゲームにおいて利用する際に用いられる複数のパラメータのうち、前記複数種類のゲームに共通して用いられるパラメータ群を含む共通領域と、前記複数種類のゲームのそれぞれにおいて個別に用いられるパラメータ群を含むゲーム毎の固有領域とを有し、
前記管理プログラムを実行する前記プロセッサは、
情報処理端末から、第1のコンテンツについて、前記共通領域と、前記複数種類のゲームのいずれかである第1のゲームに対応する前記固有領域である第1固有領域とを少なくとも含む預入用コンテンツデータを受信し、
受信された前記預入用コンテンツデータに含まれる前記共通領域および前記第1固有領域を少なくとも含むコンテンツデータであって、かつ前記第1のコンテンツに関して前記第1固有領域以外の前記固有領域を有する前記コンテンツデータが前記コンテンツ記憶媒体に保持されている場合には当該保持された前記第1固有領域以外の前記固有領域をさらに含むコンテンツデータを、前記第1のコンテンツに関する最新の前記コンテンツデータとして前記コンテンツ記憶媒体に記憶させ、
前記情報処理端末から、前記複数種類のゲームのいずれかである第2のゲームで用いられる前記第1のコンテンツの送信要求があった場合に、
当該第1のコンテンツの前記コンテンツデータに基づいて、前記共通領域を少なくとも含み、前記第2のゲームに対応する第2固有領域が保持されている場合は当該第2固有領域をさらに少なくとも含む引出用コンテンツデータを生成し、
当該コンテンツデータを前記コンテンツ記憶媒体に保持させたまま、前記引出用コンテンツデータを前記情報処理端末に送信させる、
コンテンツ保持サーバ。