IP Force 特許公報掲載プロジェクト 2022.1.31 β版

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

▶ 株式会社コナミデジタルエンタテインメントの特許一覧

特開2022-164838情報処理装置、情報処理システム、プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022164838
(43)【公開日】2022-10-27
(54)【発明の名称】情報処理装置、情報処理システム、プログラム
(51)【国際特許分類】
   A63F 13/825 20140101AFI20221020BHJP
   A63F 13/79 20140101ALI20221020BHJP
   A63F 13/53 20140101ALI20221020BHJP
   A63F 13/80 20140101ALN20221020BHJP
【FI】
A63F13/825
A63F13/79
A63F13/53
A63F13/80 B
【審査請求】有
【請求項の数】4
【出願形態】OL
(21)【出願番号】P 2022138246
(22)【出願日】2022-08-31
(62)【分割の表示】P 2020214768の分割
【原出願日】2014-02-13
(71)【出願人】
【識別番号】506113602
【氏名又は名称】株式会社コナミデジタルエンタテインメント
(74)【代理人】
【識別番号】110003177
【氏名又は名称】特許業務法人旺知国際特許事務所
(72)【発明者】
【氏名】大類 裕鎮
(72)【発明者】
【氏名】栄花 卓郎
(72)【発明者】
【氏名】近藤 昌隆
(72)【発明者】
【氏名】大谷 卓
(72)【発明者】
【氏名】木村 憲司
(57)【要約】
【課題】ユーザが所持しているオブジェクトを、ユーザが所望するオブジェクトの使用目的以外の処理に使用して消失してしまう可能性を低下させる。
【解決手段】オブジェクト識別情報と、複数のオブジェクト識別情報を含む変化条件とを対応付けて記憶する記憶装置にアクセス可能な情報処理装置であって、ユーザの操作に基づいてユーザの所持オブジェクトの中から選択オブジェクトの指定を受け付ける第1受付手段と、選択オブジェクトが変化処理を行う毎に順次異なるオブジェクトとなるよう段階的に変化可能なオブジェクトである場合、選択オブジェクトに対して複数段階の各変化処理を行うための各変化条件を記憶装置から取得する取得手段と、取得手段により取得された各変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための出力データを出力する出力手段とを備える。
【選択図】図11
【特許請求の範囲】
【請求項1】
オブジェクトを識別するオブジェクト識別情報と、前記オブジェクトを変化させる変化
処理を行うための条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付
けて記憶する記憶装置にアクセス可能な情報処理装置であって、
ユーザの操作に基づいて選択されたオブジェクトである選択オブジェクトの指定を受け
付ける第1受付手段と、
前記選択オブジェクトが、前記変化処理を行う毎に順次異なるオブジェクトとなるよう
段階的に変化可能なオブジェクトである場合、前記選択オブジェクトに対して複数段階の
各変化処理を行うための各変化条件を、前記記憶装置から取得する取得手段と、
前記取得手段により取得された各変化条件に含まれる複数のオブジェクト識別情報によ
って特定される複数のオブジェクトを、ユーザにそれぞれ識別可能な表示形式で表示させ
るための出力データを出力する出力手段と、
を備え、
前記出力データは、前記特定される複数のオブジェクトの各々について、前記ユーザが
所持する所持オブジェクトであるか否かを前記ユーザが識別可能な表示形式で表示させる
ためのデータである、情報処理装置。
【請求項2】
前記出力手段は、前記取得手段により取得された各変化条件に含まれる複数のオブジェ
クト識別情報によって特定される複数のオブジェクトを、対応する変化条件ごとに区別し
て表示させるようにして、前記出力データを出力する、
請求項1に記載された情報処理装置。
【請求項3】
前記取得手段により取得された各変化条件に含まれる複数のオブジェクト識別情報の中
に、前記ユーザの所持オブジェクトに対応するオブジェクト識別情報が含まれるときに、
当該所持オブジェクトのうちユーザの操作に基づいて選択された所持オブジェクトを登録
する登録手段、をさらに備えた、
請求項1または2に記載された情報処理装置。
【請求項4】
前記出力手段により前記出力データが出力されたことに応じて、前記ユーザによる操作
に基づく要求であって、前記複数のオブジェクトのうち少なくともいずれかのオブジェク
トに対して処理を制限させるための要求を受け付ける要求受付手段と、
前記要求受付手段により前記要求が受け付けられた場合、前記取得手段により取得され
た変化条件に含まれる複数のオブジェクト識別情報に基づいて、前記要求元のユーザが所
持する所持オブジェクトのうち、前記変化処理とは異なる処理に用いられることを制限す
べき制限オブジェクトとして特定されたオブジェクトに対して、前記変化処理とは異なる
処理に用いられることを制限する制限手段と、をさらに備えた、
請求項1~3のいずれかに記載された情報処理装置。
【請求項5】
ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと、を含む情報処理シス
テムであって、前記ユーザ端末および前記サーバの少なくともいずれかが、オブジェクト
を識別するオブジェクト識別情報と、前記オブジェクトを変化させる変化処理を行うため
の条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記
憶装置にアクセス可能である前記情報処理システムにおいて、
請求項1~4のいずれかに記載された情報処理装置の各手段を前記ユーザ端末または前
記サーバの少なくともいずれかが備えた、情報処理システム。
【請求項6】
オブジェクトを識別するオブジェクト識別情報と、前記オブジェクトを変化させる変化
処理を行うための条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付
けて記憶する記憶装置、にアクセス可能なコンピュータを、請求項1~4のいずれかに記
載された情報処理装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、オブジェクトについての情報を処理する情報処理技術に関する。
【背景技術】
【0002】
近年、ソーシャルネットワーキングサービス(SNS)において実行されるアプリケー
ションとして、いわゆるソーシャルゲーム(Social Game)が普及している。このような
ソーシャルゲームとして、カードを利用したデジタルカードゲームが知られている。
また、ユーザの所有カードの中からメインカードとサブカードがユーザに選択され、メ
インカードとサブカードを合成処理することによって、メインカードの能力パラメータを
変更するとともに、サブカードをユーザの所有カードから削除するようにしたゲームが知
られている(特許文献1、2)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特許5086491号公報
【特許文献2】特許5153960号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
合成処理では、ベースとなるオブジェクト(ベースオブジェクト;上記メインカードに
相当)の合成処理を実現するために、ベースオブジェクトに対応した組合せ条件を満たす
複数のオブジェクト(参照オブジェクト;上記サブカードに相当)をユーザが所持してい
ることが要件となる場合がある。その場合に、ベースオブジェクトとして選択されたオブ
ジェクトに対して合成処理を実行するために必要となる参照オブジェクトがユーザに提示
する仕組みを備えたゲームも知られている。しかし、その場合、選択されたカードに対し
て直近の合成処理を実行するために必要となる参照オブジェクトがユーザに提示されるに
過ぎず、その直近の合成処理の実行後にさらに合成処理を実行するために必要となる参照
オブジェクト(つまり、将来の合成処理に必要となる参照オブジェクト)をユーザは知る
ことができない。そのため、例えば、合成処理を行う毎に順次オブジェクトが異なるオブ
ジェクトに変化(進化)するようなゲームでは、進化の過程で将来必要となる参照オブジ
ェクトを現在所持しているにも関わらず、その参照オブジェクトを手放してしまう状況が
生じていた。このような場合、将来の合成処理において、ユーザは過去に手放してしまっ
たオブジェクトを再度入手しなければならず、手放してしまったことを後で後悔すること
になる。
【0005】
本発明は上述した観点に鑑みてなされたものであり、その目的は、ユーザが所持してい
るオブジェクトを、ユーザが所望する当該オブジェクトの使用目的以外の処理に使用して
消失してしまう可能性を低下させることができる情報処理装置、情報処理システム、プロ
グラムを提供することである。
【課題を解決するための手段】
【0006】
本発明の一態様は、オブジェクトを識別するオブジェクト識別情報と、前記オブジェク
トを変化させる変化処理を行うための条件であって複数のオブジェクト識別情報を含む変
化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置であって、
ユーザの操作に基づいて、当該ユーザが所持する所持オブジェクトの中から選択された
オブジェクトである選択オブジェクトの指定を受け付ける第1受付手段と、
前記選択オブジェクトが、前記変化処理を行う毎に順次異なるオブジェクトとなるよう
段階的に変化可能なオブジェクトである場合、前記選択オブジェクトに対して複数段階の
各変化処理を行うための各変化条件を、前記記憶装置から取得する取得手段と、
前記取得手段により取得された各変化条件に含まれる複数のオブジェクト識別情報によ
って特定される複数のオブジェクトを、ユーザにそれぞれ識別可能な表示形式で表示させ
るための出力データを出力する出力手段と、
を備えた、情報処理装置である。
【0007】
本発明の別の態様は、ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと
、を含む情報処理システムであって、前記ユーザ端末および前記サーバの少なくともいず
れかが、オブジェクトを識別するオブジェクト識別情報と、前記オブジェクトを変化させ
る変化処理を行うための条件であって複数のオブジェクト識別情報を含む変化条件と、を
対応付けて記憶する記憶装置にアクセス可能である前記情報処理システムにおいて、
ユーザの操作に基づいて、当該ユーザが所持する所持オブジェクトの中から選択された
オブジェクトである選択オブジェクトの指定を受け付ける第1受付手段、
前記選択オブジェクトが、前記変化処理を行う毎に順次異なるオブジェクトとなるよう
段階的に変化可能なオブジェクトである場合、前記選択オブジェクトに対して複数段階の
各変化処理を行うための各変化条件を、前記記憶装置から取得する取得手段、
前記取得手段により取得された各変化条件に含まれる複数のオブジェクト識別情報によ
って特定される複数のオブジェクトを、ユーザにそれぞれ識別可能な表示形式で表示させ
るための出力データを出力する出力手段、
を前記ユーザ端末または前記サーバの少なくともいずれかが備えた、情報処理システム
である。
【0008】
本発明の別の態様は、オブジェクトを識別するオブジェクト識別情報と、前記オブジェ
クトを変化させる変化処理を行うための条件であって複数のオブジェクト識別情報を含む
変化条件と、を対応付けて記憶する記憶装置、にアクセス可能なコンピュータに、
ユーザの操作に基づいて、当該ユーザが所持する所持オブジェクトの中から選択された
オブジェクトである選択オブジェクトの指定を受け付ける第1受付手段、
前記選択オブジェクトが、前記変化処理を行う毎に順次異なるオブジェクトとなるよう
段階的に変化可能なオブジェクトである場合、前記選択オブジェクトに対して複数段階の
各変化処理を行うための各変化条件を、前記記憶装置から取得する取得手段、
前記取得手段により取得された各変化条件に含まれる複数のオブジェクト識別情報によ
って特定される複数のオブジェクトを、ユーザにそれぞれ識別可能な表示形式で表示させ
るための出力データを出力する出力手段、
として機能させるためのプログラムである。
【図面の簡単な説明】
【0009】
図1】第1の実施形態のゲームシステムの基本構成を示す図。
図2】第1の実施形態のユーザ端末の構成を示すブロック図。
図3】第1の実施形態のゲームサーバの構成を示すブロック図。
図4】進化合成に必要となるカードのユーザへの通知を概念的に説明するための図。
図5】カードデータテーブルの構成例を示す図。
図6】進化合成データテーブルの構成例を示す図。
図7】所持カードデータテーブルの構成例を示す図。
図8】第1の実施形態においてユーザ端末に表示される画像の一例を示す図。
図9】第1の実施形態においてユーザ端末に表示される画像の一例を示す図。
図10】第1の実施形態においてユーザ端末に表示される画像の一例を示す図。
図11】第1の実施形態のゲームサーバの機能ブロック図。
図12A】進化合成の確認処理の一例を示すシーケンスチャート。
図12B】進化合成の確認処理の一例を示すシーケンスチャート。
図13】進化合成の実行処理の一例を示すシーケンスチャート。
図14】実施形態の変形例においてユーザ端末に表示される画像の一例を示す図。
図15】実施形態の変形例においてユーザ端末に表示される画像の一例を示す図。
図16】実施形態の変形例においてユーザ端末に表示される画像の一例を示す図。
図17】実施形態の変形例においてユーザ端末に表示される画像の一例を示す図。
図18】実施形態の変形例においてユーザ端末に表示される画像の一例を示す図。
図19】実施形態の変形例においてユーザ端末に表示される画像の一例を示す図。
図20】予約データテーブルの構成例を示す図。
図21】実施形態の変形例においてユーザ端末に表示される画像の一例を示す図。
【発明を実施するための形態】
【0010】
(1)第1の実施形態
(1-1)ゲームシステムの構成
以下、情報処理システムの一実施形態として、ゲームシステム1について説明する。
【0011】
図1は、実施形態のゲームシステム1のシステム構成例を示している。図1に示すよう
に、このゲームシステム1は、ユーザ端末10a,10b,10c,…、およびゲームサ
ーバ20を含む。各ユーザ端末10a,10b,10cからゲームサーバ20に対しては
、例えばインターネットなどの通信網NWを通してアクセス可能である。ゲームサーバ2
0は、情報処理装置の一例である。
各ユーザ端末10a,10b,10c,…はそれぞれ、個々のユーザによって操作され
る端末であり、例えば、フィーチャーフォン、スマートフォン、タブレット端末、パーソ
ナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機(いわゆる多機能型の
スマートテレビも含む。)、通信機能付き携帯ゲーム機などの通信端末である。以下の説
明において、各ユーザ端末10a,10b,10c,…に共通して言及するときには、ユ
ーザ端末10と表記する。
【0012】
ゲームサーバ20は、ゲームを実行するサーバである。ゲームサーバ20には、ウェブ
ブラウザによって解釈可能な画像データ(例えばHTML、XMLなどの形式で記述され
た画像データのことである。本発明の実施形態では、HTMLデータを例として説明する
。)を作成可能なプログラムが実装されている。なお、画像データは、出力データの一例
である。
ユーザ端末10は、ゲームサーバ20によって提供されるHTMLデータを解釈して表
示するウェブブラウザを備えており、ユーザ端末10によるウェブページ上のユーザの操
作に基づく要求を、ネットワークを介してゲームサーバ20へ送信し、ゲームサーバ20
による処理結果を受信することでゲームの処理を実行する。
通信網NWは、例えば、インターネット、WAN(Wide Area Network)、LAN(Loc
al Area Network)、専用回線、又はこれらの組み合わせによって構成される情報通信ネ
ットワークである。
【0013】
(1-2)ユーザ端末の構成
図2を参照してユーザ端末10について説明する。
図2に示すように、ユーザ端末10は、CPU(Central Processing Unit)11、R
OM(Read Only Memory)12、RAM(Random Access Memory)13、操作入力部15、表
示部16、通信インタフェース部17、および、ストレージ18を備えており、各部間の
制御信号あるいはデータ信号を伝送するためのバス19が設けられている。
【0014】
CPU11は、ROM12に格納されているプログラムやデータを読み出して、ユーザ
端末10内の各部との制御信号やデータ信号のタイミング処理等、ユーザ端末10内の全
体の動作を制御する。CPU11はまた、ストレージ18に記憶されているプログラムや
、プログラムの実行に必要な各種データを読み出してRAM13に展開し、プログラムの
実行に伴うデータの入出力処理、演算処理、判定処理等の各種処理を行う。RAM13は
、CPU11による演算処理、判定処理等のために一時的にデータを記憶する。
【0015】
例えば、CPU11は、ストレージ18内に格納されているウェブブラウザをRAM1
3にロードして実行する。そして、CPU11は、操作入力部15等によってユーザに入
力されるURL(Uniform Resource Locator)の指定に基づき、通信インタフェース部17
を介して、ゲームサーバ20からウェブページを表示するためのデータ、すなわち、HT
ML(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェ
クトのデータ(以下、総称して適宜「HTMLデータ」と表記する。)を、通信インタフ
ェース部17を介して取得し、ウェブブラウザを実行してHTMLデータを解釈する。な
お、ユーザ端末10には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグ
インが実装されていてもよい。そのようなプラグインの一例は、米国のアドビシステムズ
社によるフラッシュプレイヤである。あるいは、本実施形態でのHTMLデータを、動画
及び音声の再生機能を備えたHTML5形式としてもよい。
【0016】
ウェブブラウザは、ゲームサーバ20とHTTP(HyperText Transfer Protocol)に従
った通信を行う。ウェブブラウザは、ユーザによる操作入力部15の操作によってウェブ
ページ上のURL(Uniform Resource Locator)または操作対象(例えば、ソフトウェアボ
タン(以下、単に「ボタン」と表記する。)等)が選択されると、ウェブページの更新の
ために、その選択結果を含むHTTPリクエストをゲームサーバ20に送信する。ウェブ
ブラウザは、HTTPレスポンスとしてゲームサーバ20からHTMLデータを取得し、
解釈して、ウェブページの画像を表示部16に表示する。
本実施形態において、HTMLデータは画像データの一例である。
【0017】
表示部16は、たとえば、LCD(Liquid Cristal Display)や有機EL(Electro Lumin
escence)ディスプレイ等の表示デバイスである。マトリクス状に画素単位で配置された薄
膜トランジスタを含むLCD(Liquid Cristal Display)モニタを適用した場合、表示部1
6は、薄膜トランジスタを駆動することでウェブページの画像を表示画面に表示する。
【0018】
ユーザ端末10が釦入力方式のユーザ端末である場合、操作入力部15は、例えば、ユ
ーザの操作入力を受け入れるための方向指示釦、決定釦、テンキーなどの複数の指示入力
釦を備え、各釦の押下(操作)入力を認識してCPU11へ出力するためのインタフェー
ス回路を含む。
ユーザ端末10がタッチパネル入力方式のユーザ端末である場合、操作入力部15は、
主として表示画面に指先あるいはペンで触れることによるタッチパネル方式の入力を受け
付ける。
【0019】
ストレージ18は、例えばフラッシュメモリあるいはHDD(Hard Disk Drive)によっ
て構成される記憶装置である。
【0020】
(1-3)ゲームサーバの構成
図3を参照してゲームサーバ20の構成について説明する。
図3に示すように、ゲームサーバ20は、CPU21、ROM22、RAM23、通信
インタフェース部24、および、ストレージ25を備えており、各部間の制御信号あるい
はデータ信号を伝送するためのバス26が設けられている。なお、ゲームサーバ20は、
ハードウェアに関しては汎用のネットワークサーバと同一の構成をとることができる。
【0021】
CPU21は、ROM22に格納されているプログラムやデータを読み出して、ゲーム
サーバ20内の各部との制御信号やデータ信号のタイミング処理等、ゲームサーバ20内
の全体の動作を制御する。CPU21はまた、ストレージ25に記憶されているプログラ
ムや、プログラムの実行に必要な各種データを読み出してRAM23に展開し、プログラ
ムの実行に伴うデータの入出力処理、演算処理、判定処理等の各種処理を行う。RAM2
3は、CPU21による演算処理、判定処理等のために一時的にデータを記憶する。
【0022】
例えば、ストレージ25には、クライアントであるユーザ端末10のウェブブラウザと
の間でHTTPに従った通信を行ってウェブサービスを提供するプログラムが格納されて
いる。CPU21は、ストレージ25に格納されているプログラムをRAM23に展開し
て、プログラムを実行する。プログラムの実行に伴ってCPU21は、通信インタフェー
ス部24を介してユーザ端末10からHTTPリクエストを取得し、当該HTTPリクエ
ストに応じた処理を実行し、その実行結果を含むHTMLデータをHTTPレスポンスと
してユーザ端末10へ返す。
【0023】
ストレージ25は、例えばフラッシュメモリあるいはHDD(Hard Disk Drive)によっ
て構成される記憶装置であり、上述したプログラムに加え、データテーブル群70(後述
する)を格納する。データテーブル群70は、カードデータテーブル、進化合成データテ
ーブル、および、所持カードデータテーブルを含む。ストレージ25内の各データテーブ
ルは、適宜CPU21からデータの読み書きのためにアクセスされる。
【0024】
(1-4)カードの進化合成に必要なカード提示
本実施形態のゲームシステム1において実行されるゲームは、ユーザがオブジェクトと
してのカードを利用するゲームである。本実施形態のゲームのタイプは特に問わないが、
例えば、ユーザがゲーム上のエリアを探索してカードやアイテムを取得し、あるいはユー
ザが所持するカードを用いて他のユーザやNPC(Non-Player Character)と対戦するゲー
ムである。
なお、以下の説明において、カードの「所持」とは、ユーザが当該カードを、当該カー
ドを用いた処理に利用可能な状態にあることをいう。カードの「未所持」とは、ユーザが
当該カードを、当該カードを用いた処理に利用不可能な状態にあることをいう。カードの
「入手」とは、当該カードに対して未所持の状態から所持の状態に移行したことをいう。
本実施形態のゲームにおいて、カードの進化合成処理(以下、適宜単に「進化合成」ま
たは「進化」という。)とは、所定の条件を満足する場合に、ユーザが所持するカードを
進化させる処理である。カードの進化合成は、本実施形態の例では後述するようにカード
IDを変更する処理であるが、カードに対応するカードデータ(後述する)の少なくとも
一部を変更する処理であってもよい。その場合、カードデータの変更対象は特に問わない
が、例えば、カード名やカード画像、レアリティ等のカードパラメータである。カードの
進化合成は、オブジェクトの変化処理の一例である。
進化合成を実行するには、ユーザは自身が所持するカード(以下、適宜「所持カード」
という。)の中から、ベースカードとして進化させたいカードを選択する。ベースカード
として選択されたカードは、選択オブジェクトの一例である。
進化合成では、ベースカードのカードIDごとに、そのベースカードを進化させるのに
必要な複数のカード(「参照カード」という。)のカードIDの組合せ条件(変化条件の
一例)が決められている。進化合成が実行されると、その進化合成に使用された参照カー
ドはユーザの所持カードから消失する。
本実施形態において、所持カードおよび参照カードはそれぞれ、所持オブジェクトおよ
び参照オブジェクトの一例である。
本実施形態のゲームでは、ユーザによってベースカードとして選択されたカードに対応
する組合せ条件に含まれる複数の参照カードをユーザが所持していることが、選択された
カードを進化させるための条件である。
【0025】
カードの進化合成に必要なカード提示について、図4を参照して具体的に説明する。図
4は、カードの進化合成に必要なカード提示を概念的に説明するための図である。
図4において、ユーザがカードA,D,G,Q1,M2,…を所持し、カードQ1を進
化させたいと考える場合を想定する。この例では、カードQ1は、進化合成を行う毎に順
次異なるカード(Q1→Q2→Q3)に変化可能なオブジェクトである場合を想定する。
この例では、カードQ1をカードQ2に進化させるのに必要な参照カードはカードA,カ
ードBおよびカードCであり、カードQ2をカードQ3に進化させるのに必要な参照カー
ドはカードE,カードF,カードGおよびカードHである。
【0026】
本実施形態では、ベースカードとして選択されたカードQ1に必要な参照カード(カー
ドA,カードBおよびカードC)のみならず、カードQ1が順次段階的に異なるカードに
進化するときに必要なカード(カードA,B,C,E,F,G,H)がユーザに提示され
る。そのためユーザは、提示された複数のカード(カードA,B,C,E,F,G,H)
が、ベースカードとして選択されたカードであるカードQ1の将来の進化合成に必要なカ
ードであることを予め認識することができるため、提示された上記複数のカードを誤って
手放すことが防止される。例えば、図4において仮に、ベースカードとして選択されたカ
ードQ1の1回の進化合成に必要なカード(カードA,カードBおよびカードC)のみが
ユーザに提示されたならば、ユーザの所持カードGがカードQ1の将来の進化(この例で
は、カードQ2→Q3の進化)に必要なカードであるにも関わらず、カードGをユーザが
手放してしまう(例えば、処分してしまう)虞がある。それに対して、本実施形態では、
ベースカードとして選択されたカードQ1が順次段階的に異なるカードに進化するときに
必要なカード(カードA,B,C,E,F,G,H)がユーザに提示されるため、例えば
カードGを誤ってユーザが手放してしまう状況が回避される。
【0027】
(1-5)データテーブルの構成
次に、ゲームサーバ20のストレージ25に格納されるカードデータテーブル、進化合
成データテーブル、および、所持カードデータテーブルについて、図5~8を参照して順
に説明する。ゲームサーバ20のストレージ25は、記憶装置の一例である。
【0028】
(i)カードデータテーブル
カードデータテーブルには、本実施形態のゲームで使用されるカードのデータが記録さ
れている。図5にカードデータテーブルの構成例を示す。図5に示す例では、カードID
ごとにカード名、カード画像、および、カードパラメータのデータが含まれる。カードI
Dは、オブジェクト識別情報の一例である。
カード名は、カードに表示されるキャラクタの名称を示す文字列である。カード画像は
、カードに表示されるキャラクタの画像である。カードパラメータは、レアリティ、属性
、コスト、スキル、売却価格、攻撃力、防御力、および、限定フラグの各データから構成
されている。
レアリティは、カードの希少価値を示す指標であり、図5に示す例ではR1~R5の順
にレアリティが高く設定されている。
属性は、カードに表示されるキャラクタの属性であり、図5に示す例ではN1~N3の
いずれかである。
コストは、カードをユーザのカードチームに組み込むときに参照される値である。例え
ばカードチームによる対戦を行う場合には、カードチームに含まれるカードのコストの総
和が所定値以下に制限される。
スキルは、カードを用いてゲームを実行するときに有利となる効果を示す情報であり、
図4に示す例では、SK1~SK12の様々な効果を備えたスキルが各カードに設定され
ている。なお、すべてのカードがスキルを備えていなくてもよい。
売却価格は、ユーザが自身で所持しているカードを売却するときにユーザが得られるゲ
ーム上のポイントである。
攻撃力および防御力は、カードを対戦で用いるときに参照されるパラメータである。
限定フラグは、期間限定で発行されたカードであるか否かを示すフラグである。図4
示す例では、限定フラグが「1」であるカードは期間限定で発行されたカードであること
を意味し、限定フラグが「0」であるカードは期間限定でないカードであることを意味す
る。
【0029】
(ii)進化合成データテーブル
進化合成データテーブルには、本実施形態のゲームのカードの進化合成の条件が記録さ
れている。図6に進化合成データテーブルの構成例を示す。図6に示す例では、進化合成
の内容を識別するための進化IDごとに、進化前カードID(つまり、進化前のベースカ
ードとなるカードのカードID)、進化後カードID(ベースカードの進化後のカードI
D)、および進化合成を実行するために必要となる参照カードのカードIDの組合せ条件
(C1~C5の欄の5枚の参照カード)が記録されている。例えば、進化ID:0002
が示す条件では、ユーザが所持カードの中からカードID:0072のカードをベースカ
ードとして選択し、ユーザの所持カードの中にカードID:0025,0060,007
0の3枚のカードの組合せが存在する場合には、進化合成を実行することによって、カー
ドID:0072のカードをカードID:9072のカードに進化させることができる。
すなわち、進化合成データテーブルにおける参照カードIDの組合せ条件は、進化前カー
ドIDに対応するカードを変化させる変化条件の一例である。
なお、参照カードのカードIDの組合せ条件を示すC1~C5の欄には、少なくともい
ずれか2つの欄に同一のカードIDが記録されていることもある。例えば、ベースカード
を進化合成するときに使用する参照カードの組合せ条件に同一の参照カードが2枚以上含
まれていてもよい。ベースカードを進化させるための参照カードの組合せ条件が、同一の
カードIDである参照カードが所定数含まれることである場合には、図6に示したような
データ形式ではなく、参照カードのカードIDとその枚数とからなるデータ形式であって
もよい。
【0030】
(iii)所持カードデータテーブル
所持カードデータテーブルは、ユーザの所持カードの情報が記録されている。図7に所
持カードデータテーブルの構成例を示す。図7では1ユーザ分の所持カードデータテーブ
ルを例示するが、所持カードデータテーブルは、ゲームに登録しているユーザ毎に設けら
れる。
図7に示す所持カードデータテーブルには、カードIDごとに、シリアル番号、カード
レベル、および、スキルレベルの各データが対応付けられて記録されている。シリアル番
号は、ユーザにカードが付与された時点で決定される固有の番号である。同一のカードI
Dのカードに対しても異なるシリアル番号が付される。なお、カードが進化した場合には
、そのカードの進化前後でシリアル番号を変化させてもよいし、変化させなくてもよい。
カードレベルはカードの育成レベルを示すパラメータであり、例えば通常合成を実行す
ることによって増加する。ユーザがカードを取得した時点でのカードレベルの値(初期値
)は1であり、ユーザは通常合成を実行することでそのカードを成長(つまり、カードレ
ベルを増加)させることができる。
スキルレベルはカードの育成レベルを示すパラメータであり、特にカードが備えるスキ
ルのレベルを示すパラメータである。ユーザがスキルを備えたカードを取得した時点での
スキルレベルの値(初期値)は1であり、例えば所定の条件を満たすカードを参照カード
とした通常合成を行うことによってカードのスキルレベルを増加させることができる。カ
ードのスキルレベルが増加するにつれて、スキルによって発生する効果が増大する。
【0031】
以下の説明では、カードIDに関連付けられたカード名、カード画像、シリアル番号、
および、カードパラメータを総称して、適宜「カードデータ」という。カードデータを構
成するカードパラメータは、カードデータテーブルに記録される各カードパラメータや、
所持カードデータテーブルに記録されるカードレベル、スキルレベルが含まれる。すなわ
ち、カード名、カード画像、シリアル番号、および、各カードパラメータの中のいずれか
のデータが、カードデータに相当する。カードID、カード名、および、カード画像はそ
れぞれ、オブジェクト識別情報の一例である。
【0032】
(1-6)カードの進化合成に関する処理の具体例
以下、本実施形態のゲームのカードの進化合成に関する処理の具体例について、図8
10を参照しながら説明する。図8~10はそれぞれ、本実施形態のゲームの処理を実行
しているときのユーザ端末10に表示される画面の一例を示す図である。
【0033】
図8は、ユーザの所持カカードの進化合成に関する処理を実行するときの一連の表示画
面の変化を示している。図8において、画像P1は、本実施形態のゲームのメインメニュ
ーを含む画像である。画像P1には、ユーザの操作対象として、ボタンb1(「所持モン
スターを見る」)、ボタンb2(「チーム編成」)、ボタンb3(「通常合成」)、ボタ
ンb4(「進化合成」)、ボタンb5(「売却」)が設けられる。
ボタンb1は、ユーザの所持カードの閲覧処理の要求を行うときに指定されるボタンで
ある。ボタンb2は、ユーザが自身の所持カードの中から他のユーザやNPCとの対戦に
おいて使用するカードを選択するときに指定されるボタンである。ボタンb3は、ユーザ
が所持カードの中からベースカードとして選択したカードの通常合成の実行要求を行うと
きに指定されるボタンである。ボタンb4は、ユーザが所持カードの中からベースカード
として選択したカードの進化合成処理の要求を行うときに指定されるボタンである。ボタ
ンb5は、ユーザが所持カードの中から選択したカードに対して売却処理の要求を行うと
きに指定されるボタンである。
【0034】
画像P1においてボタンb4(「進化合成」)が指定されると、P2に示すように画像
が変化する。画像P2では、ユーザの所持カードの中からいずれかのカードをベースカー
ドとして選択するために、複数の所持カードが一覧表示される。なお、進化することがで
きないカードについては、ベースカードとして選択できないことをユーザが認識可能な表
示形式でカード画像が表示されていることが好ましい。
画像P2において、例えばカードQ01が選択されると、P3に示すように画像が変化
する。画像P3には、カードQ01がベースカードとして選択されたことを示すテキスト
とともに、選択されたカードQ01の進化の各段階で必要となる参照カードを確認するた
めのボタンb11(「確認する」)と、画像P2に戻ってベースカードとする所持カード
を再選択するためのボタンb12(「カードを再選択」)とが含まれる。ボタンb11(
「確認する」)が指定されると、P4(図9)に示すように画像が変化する。
【0035】
図9において画像P4では、ユーザによってベースカードとして選択されたカードQ0
1の第1段階の進化(カードQ01→R01)および当該進化に必要な参照カード(カー
ドA01,B03,C12)と、第2段階の進化(カードR01→S01)および当該進
化に必要な参照カード(カードA01,K14,M03,R05)と、最終段階の進化(
カードS01→T01)および当該進化に必要な参照カード(カードM03,C12)と
が表示される。すなわち、ベースカードとして選択されたカードQ01に対して複数段階
の各進化合成を行うための各組合せ条件に含まれる複数の参照カードが、ユーザにそれぞ
れ識別可能な表示形式で表示される。最終段階の進化は、「最終進化」ともいう。なお、
図9以降の各図では、参照カードのカード画像の表示を適宜省略する。
【0036】
カードQ01の第1段階の進化合成の組合せ条件に含まれるカードA01,B03,C
12(つまり、カードQ01を進化させるための参照カード)をユーザがすべて所持して
いる場合(カードが揃っている場合)には、図9の画像P4に代えて、図10の画像P4
aが表示される。
画像P4aでは、第1段階の進化合成を実行するためのカードがすべて揃っていること
をユーザに通知するテキスト(「すべて揃っています」)と、第1段階の進化合成を実行
することを要求するボタンb21(「進化する」)とを含む。画像P4aにおいてボタン
b21が指定されると、P5に示すように画像が変化する。すなわち、カードQ01から
カードR01への進化合成が実行されて、画像がP5に示すように、進化後カードのカー
ド画像やカード名、およびパラメータの少なくとも一部が表示される。第1段階の進化合
成が実行されると、進化合成の参照カードであるカードA01,B03,C12がユーザ
の所持カードから消失する。
【0037】
(1-7)情報処理装置が備える機能の概要
次に、上述した本実施形態のゲームを実現するためにゲームサーバ20が備える機能に
ついて説明する。図11は、本実施形態のゲームサーバ20で主要な役割を果たす機能を
説明するための機能ブロック図である。図11において、データテーブル群70は、前述
したように、カードデータテーブル、進化合成データテーブル、および、所持カードデー
タテーブルを含む。なお、図11に示す機能ブロック図に含まれる手段のすべてが本発明
に必須の要素とは限らない。例えば、本発明の一態様では、受付手段51、取得手段53
、および、出力手段54を備えていればよい。また、記録手段57、制限手段58、およ
び登録手段59は、変形例において言及される。
【0038】
受付手段51は、ユーザの操作入力に関する情報に基づいてユーザからの各種の要求を
受け付ける機能を備える。本実施形態のゲームにおいてユーザからの要求としては、例え
ば、カードの進化合成処理の要求、進化合成の実行要求、通常合成の実行要求、売却処理
の要求がある。
また、受付手段51は、第1受付手段として、ユーザの操作入力に関する情報に基づい
て、当該ユーザが所持する所持カードの中からベースカードとして選択されたカードの指
定を受け付ける機能を備える。
受付手段51の機能を実現するために、ゲームサーバ20は、通信インタフェース部2
4を介して、ユーザ端末10から画像であるウェブページ内のユーザによるボタンの操作
入力に対応する要求、またはベースカードとして選択されたカードの情報(例えば、シリ
アル番号)を受信する。ゲームサーバ20のCPU21は、受信した要求に含まれる情報
に基づいて、要求の内容を判別し、要求の受付処理を行う。受付処理では、要求がRAM
13に記録される。CPU21は、受け付けられた要求に応じた処理を順に実行する。ま
た、CPU21は、受信したカードのシリアル番号をRAM23に記録する。
【0039】
ゲーム実行手段52は、受付手段51にて受け付けたユーザ端末10からの要求に基づ
いて、進化合成以外の様々なゲームの処理を実行する機能を備える。本実施形態のゲーム
の処理は、適宜設けられてよいが、例えば、ユーザ間の対戦処理、ユーザ対NPCの対戦
処理、ユーザによるクエスト処理、ユーザの所持カードの通常合成の処理である。
対戦処理については詳しく述べないが、例えば、ユーザは、コストの総和が所定の上限
値以下となるように予め複数の所持カードからなるチームを編成し、チームによって他の
ユーザまたはNPCと対戦する。対戦結果は、チームを構成する各カードの攻撃力、防御
力、スキルなどのパラメータによって決定される。
クエスト処理は、ユーザがゲーム内のエリアを探索する処理を行うことで、カードやア
イテムを入手するための処理である。
【0040】
ユーザの所持カードの通常合成の処理を実行する場合のゲーム実行手段52の機能は、
以下のようにして実現される。ゲームサーバ20のCPU21は、ベースカードおよび参
照カードについてのユーザの選択結果を含む通常合成の実行要求を受け付けると、所持カ
ードデータテーブルからベースカードおよび参照カードのカードデータを読み出してRA
M23に展開する。次いでゲームサーバ20のCPU21は、ベースカードおよび参照カ
ードのパラメータに基づいてベースカードのパラメータ(例えば、カードレベルやスキル
レベル)を変更し、変更後のベースカードのパラメータを所持カードデータテーブルに書
き込むとともに、所持カードデータテーブルから参照カードとした所持カードのカードデ
ータを削除する。なお、ベースカードのカードレベルやスキルレベルは、通常合成を実行
する度に常に増加するとは限らない。例えば、通常合成を実行する度にカードに関連付け
られた育成パラメータの値を増加させ、その育成パラメータの値が所定値に達した場合に
カードレベルを1つ増加させるとともに育成パラメータの値をゼロにリセットするように
してもよい。
【0041】
ユーザの所持カードの売却処理を実行する場合のゲーム実行手段52の機能は、以下の
ようにして実現される。図5に記載していないが、カードデータテーブルにおいて、カー
ドIDごとに売却価格(ポイント)が対応付けられている。そしてゲームサーバ20のC
PU21は、売却処理の要求を受け付け、売却対象のカードの選択結果を取得すると、所
持カードデータテーブルから売却対象のカードのカードデータを削除する。さらにゲーム
サーバ20のCPU21は、カードデータテーブルから売却対象のカードの売却価格の値
(ポイント)を読み出し、読み出したポイントをユーザに付与する処理を行う。ポイント
をユーザに付与する処理は、例えば、ユーザデータベース(図示せず)に記録されている
ユーザの所持ポイントの値を更新する処理である。
【0042】
取得手段53は、ベースカードとして選択されたカード(選択オブジェクトの一例)が
、進化合成を行う毎に順次異なるカードとなるよう段階的に進化可能なカードである場合
、選択されたカードに対して複数段階の各進化合成を行うための各組合せ条件を、進化合
成データテーブルから取得する機能を備える。
取得手段53の機能は、ゲームサーバ20のCPU21が以下の手順を実行することに
よって実現できる。
(手順1)ベースカードとして選択されたカードのシリアル番号に対応するカードIDを
、所持カードデータテーブルを参照して特定する。
(手順2)進化合成データテーブルにおいて、手順1で特定したカードIDと同じ「進化
前カードID」が記録されている進化IDを特定する。そして、特定された進化IDに対
応する「進化後カードID」と、組合せ条件に含まれる参照カードIDとを読み出す。
(手順3)読み出された「進化後カードID」と同じ「進化前カードID」が記録されて
いる進化IDを特定する。そして、特定された進化IDに対応する「進化後カードID」
と、組合せ条件に含まれる参照カードIDとを読み出す。その後、手順3を進化IDが特
定できなくなるまで繰り返し行う。
【0043】
出力手段54は、取得手段53により取得された各組合せ条件に含まれる複数の参照カ
ードのカードIDによって特定される複数のカードを、ユーザにそれぞれ識別可能な表示
形式で表示させるための画像データ(出力データの一例)を出力する機能を備える。
出力手段54の機能を実現するために、ゲームサーバ20のCPU21は、ベースカー
ドとして選択されたユーザの所持カードが進化合成を行う毎に順次進化するときの、各進
化合成における進化IDに対応する、進化前カードID、進化後カードID、および、組
合せ条件に含まれる参照カードIDを取得すると、これらのカードIDに対応するカード
データ(例えば、カード名、カード画像等)をカードデータテーブルから読み出す。次い
でCPU21は、読み出したカードデータに基づいて、ユーザに提示するための画像デー
タを生成してユーザ端末10へ送信する。この画像データを基にユーザ端末10に表示さ
れる画像の一例が、図9の画像P4である。
【0044】
判定手段55は、ベースカードとして選択されたカードに対応する組合せ条件である複
数の参照カードがユーザの所持カードに含まれるという条件を満たすか否かを判定する機
能を備える。
判定手段55の機能を実現するために、例えば、ゲームサーバ20のCPU21は、ベ
ースカードとして選択されたカードのカードIDに対応する組合せ条件に含まれる複数の
参照カードIDによって特定されるカードをユーザが所持しているか否かについて、所持
カードデータテーブルを参照して判定する。
【0045】
変更手段56は、判定手段55によって条件を満たすと判定された場合に、ベースカー
ドのカードデータを変更する進化合成を実行する機能を備える。進化合成は、オブジェク
トとしてのカードの変化処理の一例である。
本実施形態の例では、変更手段56の機能を実現するために、ゲームサーバ20のCP
U21は、進化合成の実行要求を受け付けると、所持カードデータテーブルにおいて、進
化前カード(つまり、進化合成のベースカード)のカードデータを消去し、進化後カード
のカードデータを新たに書き込む。それによって、ユーザの所持カードのベースカードが
進化することになる。なお、進化合成データテーブルに示すように、進化前と進化後とで
カードIDは異なるため、カード名、カード画像、および、カードパラメータのうち少な
くともいずれかが進化合成によって変更される。
【0046】
(1-8)本実施形態のゲームにおける進化合成の処理フロー
次に、本実施形態のゲームにおける進化合成の処理フローの一例について、図12A
図12B、および図13のシーケンスチャートを参照して説明する。図12Aおよび図1
2Bは、進化合成の確認処理の一例を示すシーケンスチャートである。図13は、進化合
成の実行処理の一例を示すシーケンスチャートである。なお、各図において、図8~10
に示した各画像が表示される処理のタイミングに各画像の符号を付してある。
【0047】
(A)進化合成の確認処理(図12A図12B
本実施形態のゲームのメインメニュー(図8参照)においてボタンb4(「進化合成」
)が指定されると、ユーザ端末10のCPU11は、進化合成処理の要求を受け付け(S
10)、当該要求をゲームサーバ20へ送信する(S12)。ゲームサーバ20のCPU
21は、ユーザ端末10からの進化合成処理の要求を受け付けると、所持カードデータテ
ーブルから要求元のユーザの所持カードのカードIDを特定し、カードデータテーブルお
よび所持カードデータテーブルから所持カードのカードデータを読み出して、所持カード
の一覧を含む画像データを生成し(S14)、その画像データをユーザ端末10へ送信す
る(S16)。ユーザ端末10のCPU11は、S16で受信した画像データを取得する
と、当該画像データに基づいて画像(例えば、図8の画像P2)を表示部16に表示する
(S18)。なお、S14においてゲームサーバ20のCPU21は、ユーザの各所持カ
ードのカードIDが進化前カードIDとして進化合成データテーブルに記録されているか
否かを判定することによって、ユーザの各所持カードが進化可能なカードであるか否かを
判定し、進化することができない所持カードについてはベースカードとして選択できない
ことをユーザが認識可能な表示形式で、画像データを生成することが好ましい。
【0048】
S18で表示される画像には、図8の画像P2に例示したように、整列されたユーザの
所持カードの画像および名称が含まれ、各カードの画像を選択することで各カードのシリ
アル番号が選択可能となるようにして構成されている。S18で表示された複数の所持カ
ードの中でいずれかのカードをベースカードとして選択する操作が行われると、ユーザ端
末10のCPU11は、ベースカードの選択結果(シリアル番号)を受け付け(S20)
、その選択結果をゲームサーバ20へ送信する(S22)。ゲームサーバ20のCPU2
1は、受信したベースカードの選択結果に基づいて、ベースカードの選択結果を確定させ
るための確認用画像データを生成し(S24)、その画像データをユーザ端末10へ送信
する(S26)。ユーザ端末10のCPU11は、S26で受信した画像データを取得す
ると、当該画像データに基づいて画像(例えば、図8の画像P3)を表示部16に表示す
る(S28)。
S28で表示される画像は、図8の画像P3に例示したように、ベースカードの選択結
果を確認するためのボタン(b11,b12)が設けられている。ユーザ端末10のCP
U11は、このボタンのユーザによる操作に基づいて、S22で送信したベースカードの
選択結果を確定させるか否かについての応答を受け付け、その応答をゲームサーバ20へ
送信する。ここでは、CPU11が、S22で送信したベースカードの選択結果を確定さ
せる応答(ベースカードの確定応答)を受け付け、その確定応答をゲームサーバ20へ送
信する場合を想定する(S30)。
ゲームサーバ20のCPU21は、ベースカードの確定応答を取得すると、ベースカー
ドとして選択されたカードのシリアル番号を基に所持カードデータテーブルを参照して、
選択されたカードのカードIDを特定する(S32)。
【0049】
次いでCPU21は、進化合成データテーブルにおいて、S32で特定したカードID
と同じ「進化前カードID」が記録されている進化IDが特定されるか否か判定する(S
34)。進化IDが特定された場合(S34:YES)、CPU21は、特定された進化
IDに対応する進化後カードIDと、組合せ条件に含まれる参照カードIDとを読み出す
(S36)。なお、S18において表示される画像が、進化することができない所持カー
ドがベースカードとして選択できないような表示形式で表示される場合には、S20でベ
ースカードとして選択されるカードは進化可能なカードであるため、S34では進化ID
が必ず特定されることになる。
次いでCPU21は、S36で読み出した進化後カードIDと同じ進化前カードIDが
記録されている進化IDが特定されるか否か判定する(S38)。進化IDが特定される
場合には(S38:YES)、S36に戻り、S38で特定された進化IDに対応する進
化後カードIDと、組合せ条件に含まれる参照カードIDとを読み出す。CPU21は、
進化IDが特定されなくなるまでS36とS38の処理を繰り返し行い、それによって、
ベースカードとして選択された所持カードに対して複数回の各段階における進化合成を行
うための各組合せ条件(つまり、各進化に必要な参照カードID)が読み出される。 な
お、本実施形態における処理フローは、進化合成データテーブルにおける「進化前カード
ID」と「進化後カードID」とを用いる方法により説明を行っているが、この方法に限
られるものではない。例えば、進化合成データテーブルにおいてカードIDごとにすべて
の段階の進化とその進化に必要な参照カードIDとを定義し、ベースカードとして選択さ
れた所持カードに対して複数回の各段階における進化合成を行うための各組合せ条件を読
み出す方法であってもよい。また、その他の方法であってもよい。つまり、ベースカード
として選択された所持カードに対して複数回の各段階における進化合成を行うための各組
合せ条件を読み出す方法であればどのような方法であってもよい。
【0050】
進化IDが特定されなくなった場合には(S38:NO)、CPU21はS40へ進む
。S40では、S34で特定された進化IDに対応する組合せ条件に含まれる参照カード
IDによって特定されるカードをユーザがすべて所持しているかについて、所持カードデ
ータテーブルを参照して確認する(S40)。つまり、ユーザによってベースカードとし
て選択されたカードを進化させるのに必要な参照カードをすべてユーザが所持しているか
確認する。
【0051】
次いでCPU21は、S36において読み出された各進化における進化後カードIDお
よび参照カードIDと、S40の確認結果とに基づいて、ユーザに提示するための画像デ
ータを生成し(S42)、その画像データをユーザ端末10へ送信する(S44)。ユー
ザ端末10のCPU11は、S44で受信した画像データを取得すると、当該画像データ
に基づいて画像を表示部16に表示する(S46)。S40においてベースカードとして
選択されたカードを進化させるのに必要な参照カードをすべてユーザが所持していること
が確認された場合には例えば図10の画像P4aに例示したように、ベースカードとして
選択されたカードを進化させるためのボタンを含む画像が表示され、確認されない場合に
図9の画像P4に例示したように、ベースカードとして選択されたカードを進化させる
ためのボタンを含まない画像が表示される。なお、参照カードをすべてユーザが所持して
いることに加えて、他の条件を満たしていること(例えば、ベースカードが最大のレベル
に達している)が確認された場合にカードを進化させるためのボタンを含む画像を表示し
てもよい。つまり、ベースカードとして選択されたカードが最大のレベルに達しており、
かつ参照カードをユーザがすべて所持していることを、選択されたカードを進化させるた
めの条件としてもよい。いずれの場合も、生成される画像データは、各進化の組合せ条件
に含まれる複数の参照カードのカードIDによって特定される複数のカードを、ユーザに
それぞれ識別可能な表示形式で表示させるための画像データである。
なお、S34で進化IDが特定されない場合には(S34:NO)、ユーザによってベ
ースカードとして選択されたカードが進化できないカードであることを意味するため、S
42で生成される画像データは、例えば「選択したカードは進化できません」といったテ
キストを含む画像(図示せず)を表示するデータとなる。
【0052】
(B)進化合成の実行処理(図13
図13に示すシーケンスチャートは、図12BのS46において、例えば図10の画像
P4aに例示したように、ベースカードとして選択されたカードを進化させるためのボタ
ンを含む画像が表示された場合の処理の流れを示している。例えば図10の画像P4aに
は、進化合成の実行要求を行うか否かを確認するためのボタンb21(「進化する」)が
設けられている。図13では、このボタンを指定するユーザの操作に基づいて、ユーザ端
末10のCPU11が進化合成の実行要求を受け付けた場合(S50)、当該要求をゲー
ムサーバ20へ送信する(S52)。
【0053】
ゲームサーバ20のCPU21は、ユーザ端末10から受信した進化合成の実行要求を
受け付けると、所持カードデータテーブルにおいて、進化前カード(つまり、進化合成の
ベースカード)のカードデータを消去し(S54)、進化後カードのカードデータを新た
に書き込む(S56)。このとき、カードデータには、例えば、進化後カードIDに対応
して発行したシリアル番号が含まれる。次いでゲームサーバ20のCPU21は、進化合
成に使用する参照カードのカードデータを所持カードデータテーブルから消去する(S5
8)。
進化合成を実行した後、CPU21は、進化後カードのカードデータを含む画像データ
を生成し(S60)、その画像データをユーザ端末10へ送信する(S62)。ユーザ端
末10のCPU11は、S62で送信された画像データを取得すると、当該画像データに
基づいて画像(例えば、図10の画像P5)を表示部16に表示する(S64)。
【0054】
以上説明したように、本実施形態のゲームシステムでは、ユーザによってベースカード
として選択された所持カード(選択オブジェクトの一例)が進化合成を行う毎に順次異な
るカードとなるよう段階的に進化可能なカードである場合には、そのユーザに対して、選
択された所持カードの1段階の進化に必要な組合せ条件(変化条件の一例)だけではなく
、将来に亘る複数段階の進化合成のための組合せ条件に含まれる複数の参照カードIDに
よって特定される複数のカードが提示される。そのためユーザは、提示された複数のカー
ドが選択された所持カードの将来の進化に必要な参照カードであることを予め認識するこ
とができるため、提示された複数の所持カードのいずれかを誤って手放すことが防止され
る。
【0055】
上述した実施形態では、出力手段54が、取得手段53により取得された各組合せ条件
に含まれる複数の参照カードIDによって特定される複数のカードを、対応する組合せ条
件ごとに区別して表示させるようにして、画像データを出力する場合について説明した。
このような画像データを出力する場合には、以下の利点がある。すなわち、図9の画像P
4に示したように、第1段階の進化合成、第2段階の進化合成、…のための組合せ条件に
含まれる複数の参照カードが、組合せ条件ごとに表示されるため、ユーザは、比較的近い
将来に進化合成に必要となるカードと、比較的遠い将来に必要となるカードとを区別して
認識することができる。そのためユーザは、例えば他の目的のために、比較的遠い将来に
必要となるカードを進化合成以外の処理に用いるという選択をすることもできる。
【0056】
(2)第2の実施形態
第1の実施形態では、ユーザ端末10とゲームサーバ20との間でHTTPに従った通
信が行われ、ユーザ端末10がゲームサーバ20から取得するHTML文書を解釈するこ
とでゲーム画像を表示する、いわゆるブラウザ形式によって本発明が実現される場合につ
いて説明したが、この場合に限られない。ユーザ端末10がダウンロードしたゲームプロ
グラムを実行することでユーザ端末10が主体的にゲームの処理を実行し、ユーザ端末1
0とゲームサーバ20の間の送受信処理を抑制した、いわゆるネイティブアプリケーショ
ン形式によって実現してもよい。ネイティブアプリケーション形式では、ウェブブラウザ
を利用せずにユーザ端末10内で画像データを生成して表示する。
第2の実施形態では、第1の実施形態のゲームをネイティブアプリケーション形式によ
って実現する場合の一例について説明する。なお、本実施形態のハードウェア構成は、第
1の実施形態と同じ構成でよい。本実施形態のネイティブアプリケーションの形式では、
処理のほとんどをユーザ端末10側で行うことを想定しているが、以下で説明しないゲー
ムの処理の一部(例えば、ユーザに抽選によって付与する抽選処理や、ゲーム運営者がユ
ーザにカードを付与するプレゼント処理等)については、ゲームサーバ20側で処理を実
行し、ゲームサーバ20による処理結果をユーザ端末10へ送信するように構成してもよ
い。
本実施形態では、ユーザ端末10が情報処理装置の一例となる。
【0057】
本実施形態では、ユーザ端末10がユーザによる所定の操作に基づいて、ゲーム運営者
のサーバからゲームプログラムを受信し、受信したゲームプログラムがストレージ18に
格納される。ユーザ端末10によってゲームが起動されると、ユーザ端末10とゲームサ
ーバ20との間で通信が確立されてログイン処理が行われ、ゲームサーバ20からユーザ
端末10へデータテーブル群(カードデータテーブル、進化合成データテーブル、所持カ
ードデータテーブル)が送信される。ユーザ端末10に送信されるデータテーブル群は、
ユーザ端末10のストレージ18内に保持される。この場合、ストレージ18内のデータ
テーブル群は、ログインの度に更新される。
所持カードデータテーブルがユーザ端末10において改竄されることを防止するため、
ユーザ端末10による所定の処理が終了する度、あるいは、ゲームからログアウトする時
点で、ユーザ端末10内の所持カードデータテーブルがゲームサーバ20へ送信される。
ゲームサーバ20では、受信した所持カードデータテーブルと、ストレージ25内の所持
カードデータテーブルとを比較し、データの改竄が行われていないか確認した後に、スト
レージ25内の所持カードデータテーブルを受信したものに更新する。
【0058】
図示しないが、本実施形態ではユーザ端末10が、図12A図12B、および図13
に示した進化合成の処理フローを、ストレージ18内のデータテーブル群を参照して実行
する。
本実施形態では、カードデータテーブル、進化合成データテーブル、所持カードデータ
テーブルがゲームサーバ20において保持される場合について説明したが、この場合に限
られない。ネイティブアプリケーション形式のゲームでは、各データテーブルの保持分担
については適宜設定することが可能であって、ユーザ端末10、ゲームサーバ20、また
は、ユーザ端末10若しくはゲームサーバ20からアクセス可能な他の装置の少なくとも
いずれかに各データテーブルが保持されるようにすればよく、特定の保持態様に限定され
るものではない。
【0059】
(3)変形例
以下、上述した各実施形態に共通の変形例について説明する。
【0060】
(3-1)変形例1
本変形例では、出力手段54が、取得手段53により取得された各組合せ条件に含まれ
る複数の参照カードIDによって特定される複数の参照カードを、参照カードIDごとに
区別して表示させるようにして、画像データを出力する。
本変形例の出力手段54の機能を実現するために、ゲームサーバ20のCPU21は、
各進化合成における進化IDに対応する、進化前カードID、進化後カードID、および
、組合せ条件に含まれる参照カードIDを取得すると、これらのカードIDに対応するカ
ードデータをカードデータテーブルから読み出して、参照カードIDごとに区別して表示
するための画像データを生成する。生成される画像データを基に表示される画像の一例を
図14に示す。図14に示す画像P4bは、図9の画像P4を、本変形例に従って表示す
る画像の例である。
この構成では、各組合せ条件に含まれる複数のカードがカードIDごとに区別してユー
ザに提示されるため、ユーザは、いずれのカードが何枚必要になるのか定量的に認識する
ことができる。そのためユーザは、選択カードを順次異なるカードに進化させるために必
要となる全体のカードを概観することができ、また、入手すべきカードの種類数を容易に
認識することができる。
さらに、各カードIDのカードをユーザが所持しているのか未所持なのかが分かるよう
に表示させてもよい。また、所持している場合であっても、すべての数のカードを所持し
ているのか、すべての数のカードは所持していないのかが分かるように表示させてもよい
。また、すべての数のカードを所持していない場合、所持しているカードの数と所持が必
要となるカードの数とをそれぞれ分かるように表示させてもよい。このように表示させる
ことで、ユーザは入手すべきカードの現在の所持状態を確認することができる。例えば、
所持している参照カードの数をN,所持が必要となる参照カードの数をMとした場合、各
カードに対応付けてN/Mといった形式の情報を表示してもよい。
【0061】
(3-2)変形例2
本変形例では、出力手段54が、取得手段53により取得された各組合せ条件に含まれ
る複数の参照カードIDの中で、少なくとも2段階以上の組合せ条件において重複して含
まれる参照カードIDによって特定されるカードを、重複して含まれるカードID以外の
カードIDによって特定されるカードと異なる表示形式で表示させるようにして、画像デ
ータを出力してもよい。
本変形例の出力手段54の機能を実現するために、ゲームサーバ20のCPU21は、
各進化合成における進化IDに対応する、進化前カードID、進化後カードID、および
、組合せ条件に含まれる参照カードIDを取得すると、少なくとも2段階以上の組合せ条
件において重複して含まれる参照カードID(重複参照カードID)を特定する。そして
、進化前カードID、進化後カードID、および、組合せ条件に含まれる参照カードID
に対応するカードデータをカードデータテーブルから読み出して、上記重複参照カードI
Dと、重複参照カードIDではない参照カードIDとが異なる表示形式となるようにして
画像データを生成する。生成される画像データを基に表示される画像の一例を図15に示
す。図15に示す画像P4cは、図9の画像P4を、本変形例に従って表示する画像の例
であり、カードA01、C12、M03がそれぞれ重複参照カードIDに対応するカード
である。
この構成では、ベースカードとして選択されたカードに対する複数段階の進化合成の組
合せ条件に含まれる複数の参照カードIDの中で重複する参照カードIDのカードが異な
る表示形式でユーザに提示される。そのためユーザは、選択されたカードを順次異なるカ
ードに進化させるために必要となる全体のカードを概観することができ、特に多く入手す
べきカードを容易に認識することができる。
さらに、重複参照カードIDに対応するカードIDのカードをユーザが所持しているの
か未所持なのかが分かるように表示させてもよい。また、所持している場合であっても、
すべての数の重複参照カードを所持しているのか、すべての数の重複参照カードは所持し
ていないのかが分かるように表示させてもよい。また、すべての数の重複参照カードを所
持していない場合、所持している重複参照カードの数と所持が必要となる重複参照カード
の数とをそれぞれ分かるように表示させてもよい。このように表示させることで、ユーザ
は入手すべきカードの現在の所持状態を確認することができる。例えば、所持している重
複参照カードの数をN,所持が必要となる重複参照カードの数をMとした場合、各カード
に対応付けてN/Mといった形式の情報を表示してもよい。
【0062】
(3-3)変形例3
本変形例では、カードIDは、ユーザによるカードの入手条件を示す情報と関連付けら
れている。カードの入手条件を示す情報は、例えば図5に示すようにカードのレアリティ
あるいは限定フラグであってもよいし、カードの流通枚数に応じたレベルであってもよい
。カードの流通枚数に応じたレベルは、図5には図示していないが、カードデータテーブ
ルに記録される。ゲームサーバ20は、定期的に(例えば毎日)、ゲームに登録するすべ
てのユーザの所持カードをカードIDごとに集計し、その集計値に基づいてレベルを決定
し、カードデータテーブルの当該レベルの値を更新する。
本件例において、出力手段54は、取得手段53により取得された各組合せ条件に含ま
れる複数の参照カードIDの中で、入手条件が所定条件を満たす参照カードIDによって
特定されるカードを、入手条件が当該所定条件を満たさない参照カードIDによって特定
される参照カードと異なる表示形式で表示させるようにして、画像データを出力してもよ
い。
本変形例の出力手段54の機能を実現するために、ゲームサーバ20のCPU21は、
各進化合成における進化IDに対応する、進化前カードID、進化後カードID、および
、組合せ条件に含まれる参照カードIDを取得すると、これらのカードIDに対応するカ
ードデータをカードデータテーブルから読み出して、カードの入手条件を示す情報ごとに
区別して表示するための画像データを生成する。生成される画像データを基に表示される
画像の一例を図16に示す。図16に示す画像P4dは、図9の画像P4を、本変形例に
従って表示する画像の例である。画像P4dの例では、カードの入手条件を示す情報がレ
アリティであって、所定条件としてカードのレアリティがR5である場合を例示している
。レアリティがR5の参照カードが、レアリティがR4以下の参照カードとは異なる表示
形式で表示されている。
この構成おいて、例えば入手条件がカードの入手の難易度と関連する条件である場合、
ベースカードとして選択されたカードに対する複数段階の進化合成の組合せ条件に含まれ
る複数のカードIDのカードの入手の難易度がわかるため、ユーザは入手の難易度を考慮
して、選択されたカードに対する進化合成をどの段階まで実行するか判断することができ
る。
さらに、入手の難易度が高いとされたカードをユーザが所持しているのか未所持なのか
が分かるように表示させてもよい。また、所持している場合であっても、すべての数のカ
ードを所持しているのか、すべての数のカードは所持していないのかが分かるように表示
させてもよい。また、すべての数のカードを所持していない場合、所持しているカードの
数と所持が必要となるカードの数とをそれぞれ分かるように表示させてもよい。このよう
に表示させることで、ユーザは入手すべきカードの現在の所持状態を確認することができ
る。例えば、所持している参照カードの数をN,所持が必要となる参照カードの数をMと
した場合、各カードに対応付けてN/Mといった形式の情報を表示してもよい。
【0063】
(3-4)変形例4
本変形例では、第2受付手段としての受付手段51は、ベースカードとして選択された
カードが、進化合成を行う毎に順次異なるカードとなるよう段階的に進化可能なカードで
ある場合、選択されたカードを順次異なるカードとなるように段階的に進化させる進化合
成の回数に関する情報の指定を受け付ける。
また、本変形例では、取得手段53は、受付手段51により進化合成の回数に関する情
報の指定が受け付けられた場合、ベースカードとして選択されたカードに対して当該回数
の進化合成を行うための各組合せ条件を取得する。
本変形例においてユーザ端末10に表示される一連の画像の例を図17に示す。図17
の画像P3(図8の画像P3と同じ)においてボタンb11(「確認する」)が指定され
ると、P10に示すように画像が変化する。画像P10では、ベースカードとして選択さ
れたカードQ01の進化の回数の選択肢としてボタンb31~b33が設けられる。ボタ
ンb31~b33のいずれかの指定は、進化合成の回数に関する情報の指定に相当する。
画像P10において、例えばボタンb32(「第2段階までの進化」)が指定されると、
P11に示すように画像が変化する。画像P11は、ボタンb32によって指定されたよ
うに、カードQ01の第2段階までの進化に必要な参照カードが表示される。
【0064】
本変形例を実現するために、ユーザ端末10のCPU11は、進化合成の回数に関する
情報を指定する操作(例えば、図17のボタンb31~b33のいずれかの指定操作)を
受け付けると、当該進化合成の回数に関する情報をゲームサーバ20へ送信する。ゲーム
サーバ20のCPU21は、ユーザ端末10から進化合成の回数に関する情報を取得する
と、進化合成データテーブルから、ベースカードとして選択されたカードの各進化合成に
おける進化IDに対応する、進化前カードID、進化後カードID、および、組合せ条件
に含まれる参照カードIDを取得する。そして、取得した情報の中から、ユーザによって
指定された進化合成の回数に関する情報に対応するカードIDを抽出して、抽出したカー
ドIDに対応するカードデータをカードデータテーブルから読み出して、各段階の進化ご
とに区別して表示するための画像データを生成する。生成される画像データを基に表示さ
れる画像の一例が図17に例示した画像P11である。
なお、CPU21が進化合成データテーブルから取得する情報は、ベースカードとして
選択されたカードが最終進化するまでのすべての進化に対応する情報でなくてもよく、進
化合成の回数に関する情報によって特定される進化合成の回数分に対応する情報であれば
よい。
【0065】
この構成では、ユーザによって指定される進化合成の回数に応じて、選択されたカード
に対する当該回数の進化合成に必要となる参照カードがユーザに提示される。そのためユ
ーザは、選択されたカードに対するすべての進化合成に必要となる参照カードの種類およ
びその数が非常に多い場合にそのすべてがユーザに提示された場合等、ユーザにとって煩
雑になるような状況を回避できる。ユーザは、進化合成の回数を指定できるため、例えば
、進化合成について比較的少ない回数(例えば、2~3回)を指定することで、近い将来
、選択されたカードにとって必要となる参照カードのみを抽出して確認することができ、
あるいは選択されたカードについてのすべての進化合成に必要となる参照カードを一括し
て確認することもできる。つまり、ユーザの指定次第でユーザ所望の提示態様を実現する
ことができる。
さらに、各カードをユーザが所持しているのか未所持なのかが分かるように表示させて
もよい。また、所持している場合であっても、すべての数のカードを所持しているのか、
すべての数のカードは所持していないのかが分かるように表示させてもよい。また、すべ
ての数のカードを所持していない場合、所持しているカードの数と所持が必要となるカー
ドの数とをそれぞれ分かるように表示させてもよい。このように表示させることで、ユー
ザは指定した回数の進化合成を行うために入手すべきカードの現在の所持状態を確認する
ことができる。例えば、所持している参照カードの数をN,所持が必要となる参照カード
の数をMとした場合、各カードに対応付けてN/Mといった形式の情報を表示してもよい
【0066】
(3-5)変形例5
本変形例では、ベースカードとして選択されたカードが複数段階に亘って進化するカー
ドである場合、そのカードの各段階での進化に必要となるカードを、ユーザが誤って処分
してしまうことがないように予約できるようにする。予約されたカード(以下、「予約済
カード」ともいう。)については、目的とするカードの進化合成以外の処理に使用される
ことが制限される。
より具体的には、本変形例では、上述した受付手段51は、要求受付手段として、判定
手段54により画像データが出力されたことに応じて、ユーザによる操作に基づく要求で
あって、複数のカードのうち少なくともいずれかのカードに対して処理を制限させるため
の制限要求を受け付ける。
そして本変形例では、変更手段58は、受付手段51により制限要求が受け付けられた
場合、取得手段53により取得された組合せ条件に含まれる複数の参照カードIDに基づ
いて、制限要求の要求元のユーザの所持カードのうち、進化合成とは異なる処理に用いら
れることを制限すべき制限カードとして特定されたカードに対して、進化合成とは異なる
処理に用いられることを制限する機能を備える。
【0067】
本変形例のカードの予約方法の一例について、図18の画像P4eを参照して説明する
図18の画像P4eは、図9の画像P4の表示態様の変形例である。画像P4eでは、
各段階の進化に必要な参照カードを表示するとともに、表示される参照カードに対応して
カードの状態が表示される。カードの状態は、ユーザがカードを所持していないことを示
す「未所持」の状態、ユーザはカードを所持しており、かつカードを予約していることを
示す「予約済」の状態、またはユーザはカードを所持しているがカードを予約していない
ことを示す「未予約」の状態(この場合、カードを予約するためのボタンb41,b42
(「予約する」)等が表示される。)のいずれかの状態である。
画像P4eにおいて、ボタンb41,b42のいずれかを指定すると、ボタンに対応す
る参照カードの状態が「未予約」の状態から「予約済」の状態に変化する。
【0068】
予約済カードが目的とする進化合成以外の処理に用いられる場合の一例として、予約済
カードの売却処理について説明する。
図19は、ユーザが予約済カードを売却するときの処理を実行するときの一連の表示画
面の変化を示している。図19において、画像P1は図8に示したものと同じである。
画像P1においてボタンb5(「売却」)が指定されると、P20に示すように画像が
変化する。画像P20では、ユーザの所持カードの一覧が表示される。画像P20の所持
カードの一覧の中からユーザが売却することを希望するカードを選択する。このとき、所
持カードの中から予約済カードを売却対象として選択した場合、P21に示すように画像
が変化する。画像P21は、ユーザが選択したカードが予約済カードであることを通知す
るためのテキストと、売却処理を続行するか否かを選択させるためのボタンb50(「続
ける」)およびb51(「戻る」)を含む。画像P21においてボタンb50が指定され
た場合には、予約済カードであっても売却処理が行われ、それによってユーザは当該カー
ドに対応する売却価格のポイントを得るとともに予約済カードを失う。
【0069】
画像P21に示すように、予約済カードについて売却処理の実行手続きを煩雑にするこ
とは、予約済カードが進化合成以外の処理に用いられることを制限する一例である。
また、図19には図示していないが、画像P20において、ユーザの所持カードの一覧
を、予約済カードについては選択できないような態様で表示するようにしてもよい。すな
わち、予約済カードが進化合成以外の処理に用いられることをより確実に防止するために
、予約済カードの売却処理の実行が禁止されるようにしてもよい。
【0070】
なお、本実施形態のゲームでは、上述した売却処理以外にも、通常合成処理を実行する
ことで所持カードを失う場合がある。通常合成処理では、ユーザは自身の所持カードの中
から、成長させたいカードとしてベースカードを選択する。通常合成処理では、ベースカ
ードごとに参照カードの組合せ条件が決められていなくてもよく、ユーザは適宜参照カー
ドを所持カードの中から選択することができる。通常合成処理が実行されると、ベースカ
ードのカードパラメータが変化する(例えば、カードレベルやスキルレベルが増加する)
代わりに、参照カードはユーザの所持カードから消失する。通常合成処理の場合も、上述
した売却処理と同様に、通常合成を実行するときにその通常合成に使用する参照カードが
予約済カードである場合には、その通常合成の実行が制限される。
【0071】
本変形例の実現方法について説明する。
本変形例では、ゲームサーバ20のストレージ25に、予約データテーブルが設けられ
る。予約データテーブルは、進化合成ごとに、カードの予約を管理するためのデータテー
ブルであり、その一例を図20に示す。
予約データテーブルは、ユーザの進化合成のための予約済カードの情報が記録されてい
る。図20では1ユーザ分の予約データテーブルを例示するが、予約データテーブルは、
ゲームに登録しているユーザ毎に設けられる。図20において、予約IDは進化合成の予
約が行われた順に発行されるIDである。進化IDは、進化合成データテーブルに示した
進化IDに対応しており、進化合成の内容を特定するIDである。予約済カードのシリア
ル番号のうち、進化前カードのシリアル番号は、進化合成のベースカードとしてユーザに
よって選択された所持カードに対応するシリアル番号である。予約済みカードのシリアル
番号のうち参照カードのC1~C5の欄はそれぞれ、進化合成データテーブルの参照カー
ドIDの組合せ条件を構成するC1~C5の欄に対応しており、各欄に対応する参照カー
ドが予約済カードである場合には、そのカードのシリアル番号が記録されている。各欄に
対応する参照カードが予約済みでない場合には、「予約無し」を示すデータ(例えば、N
ULL)が記録される。
図20に示す予約データテーブルの例では、図18の画像P4eに示す場合の例が示さ
れる。すなわち、進化ID:0033はカードQ01→R01の進化に対応し、進化ID
:0044はカードR01→S01の進化に対応し、進化ID:0020はカードS01
→T01の進化に対応する。ここで、図18の画像P4eにおいてボタンb41(「予約
する」)が選択された場合、ゲームサーバ20のCPU21は、進化ID:0044のC
2の欄に、「予約無し」を示すデータに代えて、ユーザが所持するカードK14のシリア
ル番号を書き込む。このときCPU21は、カードK14のシリアル番号を取得するため
、ユーザの所持カードデータテーブルを参照する。
【0072】
ゲームサーバ20のCPU21は、図18の画像P4eの基礎となる画像データを生成
するに当たって、予約データテーブルおよび所持カードデータテーブルを参照して、ユー
ザの所持カードの状態を決定する。CPU21は予約データテーブルを参照して、シリア
ル番号が書き込まれている参照カードについては「予約済」の状態であると判断し、予約
データテーブルにシリアル番号が書き込まれていないがユーザが所持しているカードにつ
いては「未予約」の状態であると判断し、ユーザが所持していないカードについては「未
所持」の状態であると判断する。
また、ゲームサーバ20のCPU21は、予約済カードを制限する場合には以下のよう
に処理を行う。CPU21は、予約済カードが処理に使用するカードとして選択された場
合、その処理が予約済カードに対応する進化合成(つまり、目的とする進化合成)の処理
であるか否か、予約データテーブルを参照して判断する。つまり、予約済カードに対応す
る進化IDによって進化合成の内容が特定されるため、上記処理が目的とする進化合成で
あるか否か判断することができる。目的とする進化合成ではないと判断した場合、例えば
ユーザに対して警告を与えるための画像(例えば、図19の画像P21)のデータを生成
してユーザ端末10へ送信する。
【0073】
本変形例によれば、ユーザからの要求に応じて、ユーザの所持カードの中で、ベースカ
ードとして選択されたカードを進化させるために必要となる参照カードの少なくとも一部
またはすべてを、選択されたカードの各段階の進化合成以外の処理に用いられることを制
限する。そのため、組合せ条件を満たす前に、ユーザが誤って、選択されたカードを将来
に亘って進化させるために必要となる参照カードを、当該進化以外の処理に誤って使用し
てしまうことを確実に防止することができる。
【0074】
(3-6)変形例6
本変形例では、登録手段59が設けられる。登録手段59は、ベースカードとして選択
されたカードに対して取得手段53により取得された各組合せ条件に含まれる複数のカー
ドIDの中に、ユーザの所持カードに対応するカードIDが含まれるときに、当該所持カ
ードのうちユーザの操作に基づいて選択された指示カードを、お気に入り(ブックマーク
)として登録する機能を備える。すなわち、本変形例では、ユーザの所持カードの中に、
ベースカードとして選択されたカードの将来の進化に必要なカードが含まれている場合に
は、当該カードをお気に入りとして登録することができる。
【0075】
本変形例においてカードをお気に入りとして登録する方法の一例について、図21を参
照して説明する。図21の画像P4fは、図9の画像P4の表示態様の変形例である。画
像P4fでは、各段階の進化に必要な参照カードを表示するとともに、表示される参照カ
ードに対応してカードの状態が表示される。カードの状態は、ユーザがカードを所持して
いないことを示す「未所持」の状態、または、ユーザがカードを所持していることを示す
「所持」の状態のいずれかである。
画像P4fにおいて、所持状態のいずれかのカード(この例では、K14)を選択する
と、例えば、画像P15に示すように、選択されたカードがお気に入り登録の対象として
表示される。画像P15には、選択されたカードをお気に入り登録するためのボタンb5
0(「お気に入り登録」)が含まれる。ボタンb50(「お気に入り登録」)を指定する
と、選択されたカード(K14)がユーザのお気に入りとして登録される。
なお、「所持」「未所持」の状態を識別表示させる方法は、画像P4fに示すように文
字列による方法に限られず、画像を用いて識別できるように表示してもよい。例えば、所
持カードの場合は、その所持カードに対応するカード画像を表示させ、未所持カードの場
合は、その未所持カードに対応するカード画像とは異なる画像として表示する。異なる画
像としては、通常のカード画像と異なることが分かる画像であれば何でもよく、例えば、
通常のカード画像の明るさを暗くした画像、「?」マーク等の画像であってもよい。
また、お気に入りの登録は、画像P4fにおいて、所持カードが選択された場合に、画
像P15を表示させることなく、直ちにユーザのお気に入りとして登録してもよい。また
、画像P4fにおいて、複数の所持カードをユーザに選択させた後、ユーザに確定ボタン
を押させることで、選択された複数の所持カードを一括して登録してもよい。
なお、図示しないが、お気に入りとして登録された場合、ユーザの閲覧要求に応じて、
お気に入りとして登録されたユーザの所持カードの一覧が表示される。また、図8の画像
P1においてボタンb1(「所持モンスターを見る」)が指定された場合に表示される所
持カードの一覧の中でお気に入りのカードが識別できるように、お気に入り登録されてい
る所持カードと、お気に入り登録されていない所持カードとを識別可能に表示してもよい
。例えば、お気に入り登録されている所持カードには、お気に入り登録されていることを
示すマークを付して表示することで、お気に入り登録されていない所持カードと識別可能
に表示することができる。なお、お気に入り登録は、マークを付すだけでなく、お気に入
り登録されている所持カードに対して、所持カードでなくなる処理を制限してもよい。こ
れにより、お気に入り登録された所持カードをユーザが誤って売却等することをなくすこ
とができる。なお、変形例6で説明した方法と同様にして、お気に入り登録されている所
持カードの一覧の中から所望のカードに予約用ボタンを設け、当該予約用ボタンを指定す
ることで予約ができるようにしてもよい。
本変形例を実現するために、所持カードデータテーブル(図7参照)において、所持カ
ードのカードIDに対応して、フラグ(1:お気に入り登録済み、0:お気に入り未登録
)を設けてもよい。ゲームサーバ20のCPU21は、お気に入りとして登録されたカー
ドの閲覧要求を受け付けた場合、所持カードデータテーブルのフラグが「1」のカードデ
ータを読み出し、読み出したカードデータを基にカードの一覧を含む画像データを生成す
る。
本変形例によれば、ベースカードとして選択されたカードの将来の進化に必要なカード
を所持していることが確認できた場合、直ちにお気に入りとして登録することができるた
め、ユーザは自身の記憶に頼ることなく将来の進化に必要な所持カードに確実にしるしを
つけることができるようになる。また、ユーザは、例えば多数のカードを所持している場
合に、進化に必要となるユーザにとって重要なカードを素早く確認することができるよう
になる。
【0076】
(4)ゲーム以外のアプリケーションへの適用について
上述した実施形態および変形例では、本発明がゲームに適用される場合について説明し
たが、他のアプリケーションに適用してもよい。例えばインターネット上のショッピング
モールで商品を購入する度に複数種類の電子クーポン券を配布している場合、その電子ク
ーポン券を本発明のオブジェクトの一例としてもよい。この場合、例えばベースクーポン
券としてのクーポン券Qの特典内容をアップグレード(変更処理の一例)するために、ク
ーポン券Qに対応する参照クーポン券としてのクーポン券A~Cをユーザが所持し利用す
ることが考えられる。この例において、クーポン券Qが複数段階の変化処理を経て異なる
クーポン券に変化する場合が想定される。このとき、ショッピングサーバは、ベースクー
ポン券としてのクーポン券Qの各段階の進化に必要な参照クーポン券を特定し、当該参照
クーポン券をユーザが提示するための画像データを生成し、当該画像データをユーザ端末
へ送信する。
上述した例示以外の他のアプリケーションについても適宜適用可能である。
【0077】
以上、本発明の実施形態、変形例について詳細に説明したが、本発明は上記実施形態等
に限定されない。また、実施形態は、本発明の主旨を逸脱しない範囲において、種々の改
良や変更をしてもよいのは勿論である。上記実施形態および各変形例に記載された技術的
事項は適宜組合せて適用してもよい。
なお、要求の受付方法については上述した場合に限られない。例えば、要求の受付方法
は、加速度センサを備えたユーザ端末を振ることによる指示入力、あるいはジェスチャに
よる指示入力(ジェスチャ入力)によって受け付ける方法であってもよい。ジェスチャ入
力では、撮像機能を備えたユーザ端末に対する所定のジェスチャを行うことでユーザ端末
がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。
また、音声認識プログラムを実行可能なユーザ端末の場合には、要求の受付方法は、所定
の音声による指示入力によって受け付ける方法であってもよい。
【0078】
[発明のまとめ]
以上の記載から本発明は例えば以下のように把握される。
【0079】
本発明の一態様は、オブジェクトを識別するオブジェクト識別情報と、前記オブジェク
トを変化させる変化処理を行うための条件であって複数のオブジェクト識別情報を含む変
化条件と、を対応付けて記憶する記憶装置(25)にアクセス可能な情報処理装置(10
または20)であって、
ユーザの操作に基づいて、当該ユーザが所持する所持オブジェクトの中から選択された
オブジェクトである選択オブジェクトの指定を受け付ける第1受付手段(51)と、
前記選択オブジェクトが、前記変化処理を行う毎に順次異なるオブジェクトとなるよう
に段階的に変化可能なオブジェクトである場合、前記選択オブジェクトに対して複数段階
の各変化処理を行うための各変化条件を、前記記憶装置(25)から取得する取得手段(
53)と、
前記取得手段(53)により取得された各変化条件に含まれる複数のオブジェクト識別
情報によって特定される複数のオブジェクトを、ユーザにそれぞれ識別可能な表示形式で
表示させるための出力データ(例えば、画像データ)を出力する出力手段(54)と、
を備えた、情報処理装置である。
【0080】
「情報処理装置」は、スタンドアローンのゲーム機、あるいはユーザ端末(例えば、携
帯端末やパーソナルコンピュータ等)やネットワーク上のサーバなどであってもよい。ゲ
ームの実現形態によって適宜情報処理装置の実体を定義することができる。例えば、ユー
ザがゲーム機やユーザ端末を操作することで情報処理装置の各部の機能が実現される場合
には、ゲーム機やユーザ端末が本発明の情報処理装置に相当する。あるいは、クライアン
トであるユーザ端末がユーザからの操作入力の受付や画像の表示の機能を有し、情報処理
装置の各部の機能が実質的にユーザ端末と通信可能なサーバによって実現される場合には
、サーバが本発明の情報処理装置に相当する。
「オブジェクト」は、ユーザが視覚的に認識可能である限り如何なる表示対象であって
もよく、本発明の情報処理装置による処理内容に応じて適宜設定することができる。例え
ば、本発明の情報処理装置がゲームに関する情報を処理する場合、オブジェクトは、ゲー
ム上のキャラクタやアイテム等を含んでもよい。キャラクタは、例えばゲーム上の仮想的
な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも
含む。
「オブジェクト識別情報」は、オブジェクトをユーザが識別可能となる識別情報、およ
び、当該識別情報と関連付けられた情報である。オブジェクトをユーザが識別可能となる
識別情報は、例えば、オブジェクト名やオブジェクト画像等である。オブジェクト名やオ
ブジェクト画像と関連付けられた情報として、オブジェクトID(例えば、オブジェクト
がカードの場合には、カードID)等も「オブジェクト識別情報」の一例である。
「記憶装置」は、例えばフラッシュメモリやHDD(Hard Disk Drive)等、如何なる構
成のメモリデバイスであってもよい。また、記憶装置は、情報処理装置に内蔵されたもの
であってもよいし、情報処理装置から有線または無線でアクセス可能に構成された外部の
装置であってもよい。
オブジェクトの「所持」とは、ユーザが当該オブジェクトを、当該オブジェクトを用い
た処理に利用可能な状態にあることをいう。オブジェクトの「未所持」とは、ユーザが当
該オブジェクトを、当該オブジェクトを用いた処理に利用不可能な状態にあることをいう
。オブジェクトの「入手」とは、当該オブジェクトに対して未所持の状態から所持の状態
に移行したことをいう。
【0081】
上記情報処理装置では、ユーザによって選択された選択オブジェクトが変化処理を行う
毎に順次異なるオブジェクトとなるように段階的に変化可能なオブジェクトである場合に
は、そのユーザに対して、選択オブジェクトの1段階の変化処理に必要な変化条件だけで
はなく、将来に亘る複数段階の変化処理のための変化条件に含まれる複数のオブジェクト
識別情報によって特定される複数のオブジェクトが提示される。そのためユーザは、提示
された複数のオブジェクトが選択オブジェクトの将来の変化処理に必要なオブジェクトで
あることを予め認識することができるため、提示された複数のオブジェクトのいずれかを
誤って手放すことが防止される。
【0082】
前記出力手段(54)は、前記取得手段(53)により取得された各変化条件に含まれ
る複数のオブジェクト識別情報によって特定される複数のオブジェクトを、対応する変化
条件ごとに区別して表示させるようにして、前記出力データを出力してもよい。
この構成では、第1段階の変化処理、第2段階の変化処理、…のための変化条件に含ま
れる複数のオブジェクトが、変化条件ごとに表示されるため、ユーザは、比較的近い将来
に変化処理に必要となるオブジェクトと、比較的遠い将来に必要となるオブジェクトとを
区別して認識することができる。そのためユーザは、例えば他の目的のために、比較的遠
い将来に必要となるオブジェクトを変化処理以外の処理に用いるという選択をすることも
できる。
【0083】
上記情報処理装置は、前記取得手段により取得された各変化条件に含まれる複数のオブ
ジェクト識別情報の中に、前記ユーザの所持オブジェクトに対応するオブジェクト識別情
報が含まれるときに、当該所持オブジェクトのうちユーザの操作に基づいて選択された所
持オブジェクトを登録する登録手段(59)、をさらに備えてもよい。
この構成では、選択オブジェクトの将来の変化処理に必要な所持オブジェクトを登録す
ることができるため、ユーザは、例えば多数のオブジェクトを所持している場合に、変化
処理に必要となるユーザにとって重要なオブジェクトを素早く確認することができるよう
になる。
【0084】
前記出力手段(54)により前記出力データが出力されたことに応じて、前記ユーザに
よる操作に基づく要求であって、前記複数のオブジェクトのうち少なくともいずれかのオ
ブジェクトに対して処理を制限させるための要求を受け付ける要求受付手段(51)と、
前記要求受付手段(51)により前記要求が受け付けられた場合、前記取得手段(53
)により取得された変化条件に含まれる複数のオブジェクト識別情報に基づいて、前記要
求元のユーザが所持する所持オブジェクトのうち、前記変化処理とは異なる処理に用いら
れることを制限すべき制限オブジェクトとして特定されたオブジェクトに対して、前記変
化処理とは異なる処理に用いられることを制限する制限手段(58)と、をさらに備えて
もよい。
「変化処理とは異なる処理に用いられることを制限」とは、選択オブジェクトの変化処
理以外の処理自体が禁止されることに限られず、選択オブジェクトの変化処理は実行可能
であるが、変化処理の実行の手続きをし難くする、あるいは変化処理の実行手続きを煩雑
にすることであってもよい。なお、上述した実施形態の例では、オブジェクトの変化処理
とは異なる処理に用いられることの制限は、当該オブジェクトの予約によって実現される
。例えば上記実施形態では、「予約済カード」は、カードを目的とする進化予約とは異な
る処理に用いられることが制限される。
上記構成では、ユーザからの要求に応じて、ユーザの所持オブジェクトの中で、選択オ
ブジェクトを変化させるために必要となるオブジェクトの少なくとも一部またはすべてを
、当該選択オブジェクトの変化処理以外の処理に用いられることを制限する。そのため、
変化条件を満たす前に、ユーザが誤って、選択オブジェクトを変化させるために必要とな
るオブジェクトを、その選択オブジェクトを変化させる処理以外の処理に誤って使用して
しまうことを確実に防止することができる。
【0085】
前記出力手段(54)は、前記取得手段(53)により取得された各変化条件に含まれ
る複数のオブジェクト識別情報によって特定される複数のオブジェクトを、オブジェクト
識別情報ごとに区別して表示させるようにして、前記出力データを出力してもよい。
この構成では、各変化条件に含まれる複数のオブジェクトがオブジェクト識別情報ごと
に区別してユーザに提示されるため、ユーザは、いずれのオブジェクトが何個必要になる
のか定量的に認識することができる。そのためユーザは、選択オブジェクトを順次異なる
オブジェクトに変化させるために必要となる全体のオブジェクトを概観することができ、
また、多く入手すべきオブジェクトの種類数を容易に認識することができる。
【0086】
前記出力手段(54)は、前記取得手段(53)により取得された各変化条件に含まれ
る複数のオブジェクト識別情報の中で、少なくとも2段階以上の変化条件において重複し
て含まれるオブジェクト識別情報によって特定されるオブジェクトを、前記重複して含ま
れるオブジェクト識別情報以外のオブジェクト識別情報によって特定されるオブジェクト
と異なる表示形式で表示させるようにして、前記出力データを出力してもよい。
この構成では、選択オブジェクトに対する複数段階の変化処理の変化条件に含まれる複
数のオブジェクト識別情報の中で重複するオブジェクト識別情報のオブジェクトが異なる
表示形式でユーザに提示される。そのためユーザは、選択オブジェクトを順次異なるオブ
ジェクトに変化させるために必要となる全体のオブジェクトを概観することができ、特に
多く入手すべきオブジェクトを容易に認識することができる。
【0087】
オブジェクト識別情報は、ユーザによるオブジェクトの入手条件を示す情報と関連付け
られており、
前記出力手段(54)は、前記取得手段(53)により取得された各変化条件に含まれ
る複数のオブジェクト識別情報の中で、入手条件が所定条件を満たすオブジェクト識別情
報によって特定されるオブジェクトを、入手条件が前記所定条件を満たさないオブジェク
ト識別情報によって特定されるオブジェクトと異なる表示形式で表示させるようにして、
前記出力データを出力してもよい。
この構成おいて、例えば入手条件がオブジェクトの入手の難易度と関連する条件である
場合、選択オブジェクトに対する複数段階の変化処理の変化条件に含まれる複数のオブジ
ェクト識別情報のオブジェクトの入手の難易度がわかるため、ユーザは入手の難易度を考
慮して、選択オブジェクトに対する変化処理をどの段階まで実行するか判断することがで
きる。
【0088】
前記選択オブジェクトが、前記変化処理を行う毎に順次異なるオブジェクトとなるよう
に段階的に変化可能なオブジェクトである場合、前記選択オブジェクトを順次異なるオブ
ジェクトとなるように段階的に変化させる変化処理の回数に関する情報の指定を受け付け
る第2受付手段(51)、をさらに備え、
前記取得手段(53)は、前記第2受付手段(51)により前記変化処理の回数に関す
る情報の指定が受け付けられた場合、前記選択オブジェクトに対して当該回数の変化処理
を行うための各変化条件を取得してもよい。
この構成では、ユーザによって指定される複数段階の変化処理の回数に応じて、その回
数の選択オブジェクトの変化処理に必要となるオブジェクトがユーザに提示される。その
ためユーザは、選択オブジェクト対するすべての変化処理に必要となるオブジェクトの種
類およびその数が非常に多い場合にそのすべてがユーザに提示された場合等、ユーザにと
って煩雑になるような状況を回避できる。ユーザは、複数段階の変化処理の回数を指定で
きるため、例えば、変化処理について比較的少ない回数(例えば、2~3回)を指定する
ことで、近い将来選択オブジェクトにとって必要となるオブジェクトのみを抽出して確認
することができ、あるいは選択オブジェクトについてのすべての変化処理に必要となるオ
ブジェクトを一括して確認することもできる。つまり、ユーザの指定次第でユーザ所望の
提示態様を実現することができる。
【0089】
本発明の別の態様は、ユーザ端末(10)と、当該ユーザ端末(10)と通信可能に構
成されるサーバ(20)と、を含む情報処理システム(1)であって、前記ユーザ端末(
10)および前記サーバ(20)の少なくともいずれかが、オブジェクトを識別するオブ
ジェクト識別情報と、前記オブジェクトを変化させる変化処理を行うための条件であって
複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置(25)
にアクセス可能である前記情報処理システムにおいて、
ユーザの操作に基づいて、当該ユーザが所持する所持オブジェクトの中から選択された
オブジェクトである選択オブジェクトの指定を受け付ける第1受付手段(51)、
前記選択オブジェクトが、前記変化処理を行う毎に順次異なるオブジェクトとなるよう
に段階的に変化可能なオブジェクトである場合、前記選択オブジェクトに対して複数段階
の各変化処理を行うための各変化条件を、前記記憶装置(25)から取得する取得手段(
53)、
前記取得手段(53)により取得された各変化条件に含まれる複数のオブジェクト識別
情報によって特定される複数のオブジェクトを、ユーザにそれぞれ識別可能な表示形式で
表示させるための出力データを出力する出力手段(54)、
を前記ユーザ端末(10)または前記サーバ(20)の少なくともいずれかが備えた、
情報処理システムである。
【0090】
本発明の別の態様は、オブジェクトを識別するオブジェクト識別情報と、前記オブジェ
クトを変化させる変化処理を行うための条件であって複数のオブジェクト識別情報を含む
変化条件と、を対応付けて記憶する記憶装置(25)、にアクセス可能なコンピュータに

ユーザの操作に基づいて、当該ユーザが所持する所持オブジェクトの中から選択された
オブジェクトである選択オブジェクトの指定を受け付ける第1受付手段(51)、
前記選択オブジェクトが、前記変化処理を行う毎に順次異なるオブジェクトとなるよう
に段階的に変化可能なオブジェクトである場合、前記選択オブジェクトに対して複数段階
の各変化処理を行うための各変化条件を、前記記憶装置(25)から取得する取得手段(
53)、
前記取得手段(53)により取得された各変化条件に含まれる複数のオブジェクト識別
情報によって特定される複数のオブジェクトを、ユーザにそれぞれ識別可能な表示形式で
表示させるための出力データを出力する出力手段(54)、
として機能させるためのプログラムである。
【0091】
本発明の別の態様は、上記プログラムを格納する、光ディスク、磁気ディスク等の、コ
ンピュータが読み取り可能な記憶媒体であってもよい。
【0092】
なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書
きで記載しているが、これにより本発明に係る情報処理装置等が図示の態様に限定される
ものではない。
【符号の説明】
【0093】
1…ゲームシステム
10…ユーザ端末
11…CPU
12…ROM
13…RAM
15…操作入力部
16…表示部
17…通信インタフェース部
18…ストレージ
19…バス
20…ゲームサーバ
21…CPU
22…ROM
23…RAM
24…通信インタフェース部
25…ストレージ
26…バス
51…受付手段
52…ゲーム実行手段
53…取得手段
54…出力手段
55…判定手段
56…変更手段
57…記録手段
58…制限手段
59…登録手段
70…データテーブル群
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12A
図12B
図13
図14
図15
図16
図17
図18
図19
図20
図21
【手続補正書】
【提出日】2022-09-29
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
プロセッサを具備し、
オブジェクトを順次異なるオブジェクトとなるよう段階的に変化させる変化処理を行うための情報処理装置のプログラムであって、
前記プロセッサを、
ユーザの操作に基づいて、当該ユーザが所持するオブジェクトの中から選択されたオブジェクトである選択オブジェクトの指定を受け付ける第1受付手段として機能させ、
前記変化処理に関する情報の指定を受け付ける第2受付手段として機能させ、
前記第2受付手段により前記変化処理に関する情報の指定が受け付けられた場合、前記選択オブジェクトに対して前記変化処理に関する情報の指定に基づく変化処理に必要な回数の変化処理を行うための変化条件であって、オブジェクトを識別するオブジェクト識別情報と対応付けられ、かつ、複数のオブジェクト識別情報を含む変化条件を取得する取得手段として機能させ、
前記取得手段により取得された変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトを、ユーザにそれぞれ識別可能な表示形式で表示させるための出力データを出力する出力手段として機能させる、
情報処理装置のプログラム。
【請求項2】
前記出力手段は、前記取得手段により取得された変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトを、前記ユーザ所持に関する情報を表示させるようにして、前記出力データを出力する、
請求項1に記載の情報処理装置のプログラム。
【請求項3】
サーバにアクセス可能な情報処理装置を用いて、オブジェクトを順次異なるオブジェクトとなるよう段階的に変化させる変化処理を行うための情報処理システムであって、
前記情報処理装置は、
ユーザの操作に基づいて、当該ユーザが所持する前記オブジェクトの中から選択されたオブジェクトである選択オブジェクトの指定を受け付ける第1受付手段と、
前記変化処理に関する情報の指定を受け付ける第2受付手段と、
前記第2受付手段により前記変化処理に関する情報の指定が受け付けられた場合、前記選択オブジェクトに対して前記変化処理に関する情報の指定に基づく変化処理に必要な回数の変化処理を行うための変化条件であって、オブジェクトを識別するオブジェクト識別情報と対応付けられ、かつ、複数のオブジェクト識別情報を含む変化条件を取得する取得手段と、
前記取得手段により取得された変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトを、ユーザにそれぞれ識別可能な表示形式で表示させるための出力データを出力する出力手段と、
を備えた、情報処理システム。
【請求項4】
プロセッサを具備し、
オブジェクトを順次異なるオブジェクトとなるよう段階的に変化させる変化処理を行うための情報処理装置の出力データの出力方法であって、
ユーザの操作に基づいて、当該ユーザが所持する前記オブジェクトの中から選択されたオブジェクトである選択オブジェクトの指定を受け付け、
前記変化処理に関する情報の指定を受け付け、
前記変化処理に関する情報の指定が受け付けられた場合、前記選択オブジェクトに対して前記変化処理に関する情報の指定に基づく変化処理に必要な回数の変化処理を行うための変化条件であって、オブジェクトを識別するオブジェクト識別情報と対応付けられ、かつ、複数のオブジェクト識別情報を含む変化条件を取得し、
前記取得された変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトを、ユーザにそれぞれ識別可能な表示形式で表示させるための出力データを出力する、
情報処理装置の出力データの出力方法。