JP2022017556A - 情報処理装置、ゲームプログラム - Google Patents

Abstract

【課題】オブジェクトを変化させる処理を行う条件が定義された変化条件であって、少なくとも複数のオブジェクトを示す情報を含む変化条件と、ユーザが所持するオブジェクトを示す情報を含む所持情報とが記憶された記憶装置にアクセス可能な装置。
【解決手段】ユーザからの要求を受け付けたことに応じて、記憶装置から取得された変化条件と、当該ユーザが所持するオブジェクトを示す情報が含まれる所持情報とに基づいて、当該ユーザが所持するオブジェクトのうち、選択された選択オブジェクトを変化させる処理とは異なる処理に用いられることを制限すべき制限オブジェクトとして特定されたオブジェクトに対して、選択された選択オブジェクトを変化させる処理とは異なる処理に用いられることを制限する。
【選択図】図１３

Description

本発明は、オブジェクトについての情報を処理する情報処理技術に関する。

近年、ソーシャルネットワーキングサービス（ＳＮＳ）において実行されるアプリケー
ションとして、いわゆるソーシャルゲーム（Social Game）が普及している。このような
ソーシャルゲームとして、カードを利用したデジタルカードゲームが知られている。
また、ユーザの所有カードの中からメインカードとサブカードがユーザに選択され、メ
インカードとサブカードを合成処理することによって、メインカードの能力パラメータを
変更するとともに、サブカードをユーザの所有カードから削除するようにしたゲームが知
られている（特許文献１、２）。

特許５０８６４９１号公報 特許５１５３９６０号公報

合成処理では、ベースオブジェクト（上記メインカードに相当）の合成処理を実現する
ために、ベースオブジェクトに対応した組合せ条件を満たす複数の参照オブジェクト（上
記サブカードに相当）をユーザが所持していることが要件となる場合がある。その場合、
ユーザは合成処理を実行するために、組合せ条件を満たすすべての参照オブジェクトを入
手できるまで合成処理の実行を待機しなければならないが、その待機中に誤って、複数の
参照オブジェクトのうち既に所持しているオブジェクトを消失させてしまう虞がある。特
に、ベースオブジェクトごとに合成処理の組合せ条件を満たす複数の参照オブジェクトが
異なる場合には、ベースオブジェクトごとの組合せ条件をユーザが覚えておくのが大変で
あるため、オブジェクトを誤って消失させてしまう可能性が高くなる。

本発明は上述した観点に鑑みてなされたものであり、その目的は、ユーザが所持してい
るオブジェクトを、そのオブジェクトの使用目的以外の処理に使用して消失してしまう可
能性を低下させることができる情報処理装置、情報処理システム、プログラムを提供する
ことである。

本発明の一態様は、オブジェクトを変化させる処理を行う条件が定義された変化条件で
あって、少なくとも複数のオブジェクトを示す情報を含む変化条件と、ユーザが所持する
オブジェクトを示す情報を含む所持情報とが記憶された記憶装置にアクセス可能な情報処
理装置において、
選択された選択オブジェクトに対応する前記変化条件を、前記記憶装置から取得する取
得手段と、
前記取得手段により取得された前記変化条件に含まれる複数のオブジェクトを示す情報
を用いて、当該複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させる
ための出力データを出力する出力手段と、
前記出力手段により前記出力データが出力されたことに応じて、前記ユーザによる操作
を介してなされた要求であって、前記複数のオブジェクトのうち少なくともいずれかのオ
ブジェクトに対して処理を制限させるための要求を受け付ける受付手段と、
前記受付手段により前記要求を受け付けたことに応じて、前記取得手段により取得され
た前記変化条件と、前記要求元のユーザが所持するオブジェクトを示す情報が含まれる前
記所持情報とに基づいて、当該ユーザが所持するオブジェクトのうち、前記選択された選
択オブジェクトを変化させる処理とは異なる処理に用いられることを制限すべき制限オブ
ジェクトとして特定されたオブジェクトに対して、前記選択された選択オブジェクトを変
化させる処理とは異なる処理に用いられることを制限する制限手段と、
を有することを特徴とする情報処理装置である。

本発明の別の態様は、ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと
、を含むゲームシステムであって、
オブジェクトを変化させる処理を行う条件が定義された変化条件であって、少なくとも
複数のオブジェクトを示す情報を含む変化条件と、ユーザが所持するオブジェクトを示す
情報を含む所持情報とが記憶された記憶装置から、選択された選択オブジェクトに対応す
る前記変化条件を取得する取得手段と、
前記取得手段により取得された前記変化条件に含まれる複数のオブジェクトを示す情報
を用いて、当該複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させる
ための出力データを出力する出力手段と、
前記出力手段により前記出力データが出力されたことに応じて、前記ユーザによる操作
を介してなされた要求であって、前記複数のオブジェクトのうち少なくともいずれかのオ
ブジェクトに対して処理を制限させるための要求を受け付ける受付手段と、
前記受付手段により前記要求を受け付けたことに応じて、前記取得手段により取得され
た前記変化条件と、前記要求元のユーザが所持するオブジェクトを示す情報が含まれる前
記所持情報とに基づいて、当該ユーザが所持するオブジェクトのうち、前記選択された選
択オブジェクトを変化させる処理とは異なる処理に用いられることを制限すべき制限オブ
ジェクトとして特定されたオブジェクトに対して、前記選択された選択オブジェクトを変
化させる処理とは異なる処理に用いられることを制限する制限手段と、
を有することを特徴とする情報処理システムである。

本発明の別の態様は、オブジェクトを変化させる処理を行う条件が定義された変化条件
であって、少なくとも複数のオブジェクトを示す情報を含む変化条件と、ユーザが所持す
るオブジェクトを示す情報を含む所持情報とが記憶された記憶装置、にアクセス可能なコ
ンピュータに、
選択された選択オブジェクトに対応する前記変化条件を、前記記憶装置から取得する取
得手段、
前記取得手段により取得された前記変化条件に含まれる複数のオブジェクトを示す情報
を用いて、当該複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させる
ための出力データを出力する出力手段、
前記出力手段により前記出力データが出力されたことに応じて、前記ユーザによる操作
を介してなされた要求であって、前記複数のオブジェクトのうち少なくともいずれかのオ
ブジェクトに対して処理を制限させるための要求を受け付ける受付手段、および、
前記受付手段により前記要求を受け付けたことに応じて、前記取得手段により取得され
た前記変化条件と、前記要求元のユーザが所持するオブジェクトを示す情報が含まれる前
記所持情報とに基づいて、当該ユーザが所持するオブジェクトのうち、前記選択された選
択オブジェクトを変化させる処理とは異なる処理に用いられることを制限すべき制限オブ
ジェクトとして特定されたオブジェクトに対して、前記選択された選択オブジェクトを変
化させる処理とは異なる処理に用いられることを制限する制限手段、
として機能させるためのプログラムである。

本発明の別の態様は、ベースオブジェクトに対応する複数の参照オブジェクトがユーザ
の所持オブジェクトに含まれる場合に、前記ベースオブジェクトのオブジェクト情報を変
更する変更処理を含むゲーム、に用いられる情報処理装置であって、
前記ユーザの操作入力に基づいて、前記所持オブジェクトの中からいずれかのオブジェ
クトのオブジェクト情報を取得する取得手段と、
前記取得手段によって取得されたオブジェクト情報に対応するオブジェクトが前記ベー
スオブジェクトおよび前記複数の参照オブジェクトのいずれかである場合に、前記取得手
段によって取得されたオブジェクト情報を記憶装置に記録する記録手段と、
前記記憶装置に記録されているオブジェクト情報に対応するオブジェクトが前記変更処
理以外の処理に用いられることを制限する制限手段と、
を備えた、情報処理装置である。

本発明の別の態様は、ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと
、を含み、
ベースオブジェクトに対応する複数の参照オブジェクトがユーザの所持オブジェクトに
含まれる場合に、前記ベースオブジェクトのオブジェクト情報を変更する変更処理を含む
ゲーム、に用いられるゲームシステムであって、
前記ユーザの操作入力に基づいて、前記所持オブジェクトの中からいずれかのオブジェ
クトのオブジェクト情報を取得する取得手段と、
前記取得手段によって取得されたオブジェクト情報に対応するオブジェクトが前記ベー
スオブジェクトおよび前記複数の参照オブジェクトのいずれかである場合に、前記取得手
段によって取得されたオブジェクト情報を記憶装置に記録する記録手段と、
前記記憶装置に記録されているオブジェクト情報に対応するオブジェクトが前記変更処
理以外の処理に用いられることを制限する制限手段と、
を備えた、情報処理システムである。

本発明の別の態様は、ベースオブジェクトに対応する複数の参照オブジェクトがユーザ
の所持オブジェクトに含まれる場合に、前記ベースオブジェクトのオブジェクト情報を変
更する変更処理を含むゲーム、のためのプログラムであって、
コンピュータを、
前記ユーザの操作入力に基づいて、前記所持オブジェクトの中からいずれかのオブジェ
クトのオブジェクト情報を取得する取得手段、
前記取得手段によって取得されたオブジェクト情報に対応するオブジェクトが前記ベー
スオブジェクトおよび前記複数の参照オブジェクトのいずれかである場合に、前記取得手
段によって取得されたオブジェクト情報を記憶装置に記録する記録手段、および、
前記記憶装置に記録されているオブジェクト情報に対応するオブジェクトが前記変更処
理以外の処理に用いられることを制限する制限手段、
として機能させるためのプログラムである。

第１の実施形態のゲームシステムの基本構成を示す図。 第１の実施形態のユーザ端末の構成を示すブロック図。 第１の実施形態のゲームサーバの構成を示すブロック図。 進化合成におけるカードの予約を概念的に説明するための図。 カードデータテーブルの構成例を示す図。 進化合成データテーブルの構成例を示す図。 所持カードデータテーブルの構成例を示す図。 予約データテーブルの構成例を示す図。 第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第１の実施形態のゲームサーバの機能ブロック図。 進化合成の予約処理の一例を示すシーケンスチャート。 進化合成の予約処理の一例を示すシーケンスチャート。 所持カードの閲覧処理の一例を示すシーケンスチャート。 予約済カードの売却処理の一例を示すシーケンスチャート。 予約済カードの売却処理の一例を示すシーケンスチャート。 カード入手時の判定処理の一例を示すシーケンスチャート。 カード入手時の判定処理の一例を示すシーケンスチャート。 進化合成処理の一例を示すシーケンスチャート。 第２の実施形態の進化合成の予約処理の一例を示すシーケンスチャート。 第２の実施形態の進化合成の予約処理の一例を示すシーケンスチャート。 第２の実施形態の予約済カードの売却処理の一例を示すシーケンスチャート。 第２の実施形態の予約済カードの売却処理の一例を示すシーケンスチャート。 変形例においてゲームの実行時のユーザ端末に表示される画像の一例を示す図。 変形例においてゲームの実行時のユーザ端末に表示される画像の一例を示す図。

（１）第１の実施形態
（１－１）ゲームシステムの構成
以下、情報処理システムの一実施形態として、ゲームシステム１について説明する。

図１は、実施形態のゲームシステム１のシステム構成例を示している。図１に示すよう
に、このゲームシステム１は、ユーザ端末１０ａ，１０ｂ，１０ｃ，…、およびゲームサ
ーバ２０を含む。各ユーザ端末１０ａ，１０ｂ，１０ｃからゲームサーバ２０に対しては
、例えばインターネットなどの通信網ＮＷを通してアクセス可能である。ゲームサーバ２
０は、情報処理装置の一例である。
各ユーザ端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作され
る端末であり、例えば、フィーチャーフォン、スマートフォン、タブレット端末、パーソ
ナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型の
スマートテレビも含む。）、通信機能付き携帯ゲーム機などの通信端末である。以下の説
明において、各ユーザ端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、ユ
ーザ端末１０と表記する。

ゲームサーバ２０は、ゲームを実行するサーバである。ゲームサーバ２０には、ウェブ
ブラウザによって解釈可能な画像データ（例えばＨＴＭＬ、ＸＭＬなどの形式で記述され
た画像データのことである。本発明の実施形態では、ＨＴＭＬデータを例として説明する
。）を作成可能なプログラムが実装されている。なお、画像データは、出力データの一例
である。
ユーザ端末１０は、ゲームサーバ２０によって提供されるＨＴＭＬデータを解釈して表
示するウェブブラウザを備えており、ユーザ端末１０によるウェブページ上のユーザの操
作に基づく要求を、ネットワークを介してゲームサーバ２０へ送信し、ゲームサーバ２０
による処理結果を受信することでゲームの処理を実行する。
通信網ＮＷは、例えば、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Loc
al Area Network）、専用回線、又はこれらの組み合わせによって構成される情報通信ネ
ットワークである。

（１－２）ユーザ端末の構成
図２を参照してユーザ端末１０について説明する。
図２に示すように、ユーザ端末１０は、ＣＰＵ（Central Processing Unit）１１、Ｒ
ＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、操作入力部１５、表
示部１６、通信インタフェース部１７、および、ストレージ１８を備えており、各部間の
制御信号あるいはデータ信号を伝送するためのバス１９が設けられている。

ＣＰＵ１１は、ＲＯＭ１２に格納されているプログラムやデータを読み出して、ユーザ
端末１０内の各部との制御信号やデータ信号のタイミング処理等、ユーザ端末１０内の全
体の動作を制御する。ＣＰＵ１１はまた、ストレージ１８に記憶されているプログラムや
、プログラムの実行に必要な各種データを読み出してＲＡＭ１３に展開し、プログラムの
実行に伴うデータの入出力処理、演算処理、判定処理等の各種処理を行う。ＲＡＭ１３は
、ＣＰＵ１１による演算処理、判定処理等のために一時的にデータを記憶する。

例えば、ＣＰＵ１１は、ストレージ１８内に格納されているウェブブラウザをＲＡＭ１
３にロードして実行する。そして、ＣＰＵ１１は、操作入力部１５等によってユーザに入
力されるＵＲＬ(Uniform Resource Locator)の指定に基づき、通信インタフェース部１７
を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴ
ＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェ
クトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を、通信インタフ
ェース部１７を介して取得し、ウェブブラウザを実行してＨＴＭＬデータを解釈する。な
お、ユーザ端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグ
インが実装されていてもよい。そのようなプラグインの一例は、米国のアドビシステムズ
社によるフラッシュプレイヤである。あるいは、本実施形態でのＨＴＭＬデータを、動画
及び音声の再生機能を備えたＨＴＭＬ５形式としてもよい。

ウェブブラウザは、ゲームサーバ２０とＨＴＴＰ(HyperText Transfer Protocol)に従
った通信を行う。ウェブブラウザは、ユーザによる操作入力部１５の操作によってウェブ
ページ上のＵＲＬ(Uniform Resource Locator)または操作対象（例えば、ソフトウェアボ
タン（以下、単に「ボタン」と表記する。）等）が選択されると、ウェブページの更新の
ために、その選択結果を含むＨＴＴＰリクエストをゲームサーバ２０に送信する。ウェブ
ブラウザは、ＨＴＴＰレスポンスとしてゲームサーバ２０からＨＴＭＬデータを取得し、
解釈して、ウェブページの画像を表示部１６に表示する。
本実施形態において、ＨＴＭＬデータは画像データの一例である。

表示部１６は、たとえば、ＬＣＤ(Liquid Cristal Display)や有機ＥＬ(Electro Lumin
escence)ディスプレイ等の表示デバイスである。マトリクス状に画素単位で配置された薄
膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタを適用した場合、表示部１
６は、薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示す
る。

ユーザ端末１０が釦入力方式のユーザ端末である場合、操作入力部１５は、例えば、ユ
ーザの操作入力を受け入れるための方向指示釦、決定釦、テンキーなどの複数の指示入力
釦を備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェー
ス回路を含む。
ユーザ端末１０がタッチパネル入力方式のユーザ端末である場合、操作入力部１５は、
主として表示画面に指先あるいはペンで触れることによるタッチパネル方式の入力を受け
付ける。

ストレージ１８は、例えばフラッシュメモリあるいはＨＤＤ(Hard Disk Drive)によっ
て構成される記憶装置である。

（１－３）ゲームサーバの構成
図３を参照してゲームサーバ２０の構成について説明する。
図３に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、通信
インタフェース部２４、および、ストレージ２５を備えており、各部間の制御信号あるい
はデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、
ハードウェアに関しては汎用のネットワークサーバと同一の構成をとることができる。

ＣＰＵ２１は、ＲＯＭ２２に格納されているプログラムやデータを読み出して、ゲーム
サーバ２０内の各部との制御信号やデータ信号のタイミング処理等、ゲームサーバ２０内
の全体の動作を制御する。ＣＰＵ２１はまた、ストレージ２５に記憶されているプログラ
ムや、プログラムの実行に必要な各種データを読み出してＲＡＭ２３に展開し、プログラ
ムの実行に伴うデータの入出力処理、演算処理、判定処理等の各種処理を行う。ＲＡＭ２
３は、ＣＰＵ２１による演算処理、判定処理等のために一時的にデータを記憶する。

例えば、ストレージ２５には、クライアントであるユーザ端末１０のウェブブラウザと
の間でＨＴＴＰに従った通信を行ってウェブサービスを提供するプログラムが格納されて
いる。ＣＰＵ２１は、ストレージ２５に格納されているプログラムをＲＡＭ２３に展開し
て、プログラムを実行する。プログラムの実行に伴ってＣＰＵ２１は、通信インタフェー
ス部２４を介してユーザ端末１０からＨＴＴＰリクエストを取得し、当該ＨＴＴＰリクエ
ストに応じた処理を実行し、その実行結果を含むＨＴＭＬデータをＨＴＴＰレスポンスと
してユーザ端末１０へ返す。

ストレージ２５は、例えばフラッシュメモリあるいはＨＤＤ(Hard Disk Drive)によっ
て構成される情報記録装置であり、上述したプログラムに加え、データテーブル群７０（
後述する）を格納する。データテーブル群７０は、カードデータテーブル、進化合成デー
タテーブル、所持カードデータテーブル、および、予約データテーブルを含む。ストレー
ジ２５内の各データテーブルは、適宜ＣＰＵ２１からデータの読み書きのためにアクセス
される。

（１－４）本実施形態のゲームのカードの進化合成における予約
本実施形態のゲームシステム１において実行されるゲームは、ユーザがオブジェクトと
してのカードを利用して実行するゲームである。このゲームでは、例えば、ユーザがゲー
ム上のエリアを探索してカードやアイテムを取得し、あるいはユーザが所持するカードを
用いて他のユーザやＮＰＣ(Non-Player Character)と対戦するゲームである。
本実施形態のゲームにおいて、カードの進化合成処理（以下、適宜単に「進化合成」と
いう。）とは、所定の条件を満足する場合に、ユーザが所持するカードを進化させる処理
である。カードの進化合成は、本実施形態の例では後述するようにカードＩＤを変更する
処理であるが、カードに対応するカードデータ（後述する）の少なくとも一部を変更する
処理であってもよい。その場合、カードデータの変更対象は特に問わないが、例えば、カ
ード名やカード画像、レアリティ等のカードパラメータである。カードの進化合成は、オ
ブジェクトを変化させる処理、オブジェクト情報を変更する変更処理の一例である。
進化合成を実行するには、ユーザは自身が所持するカード（以下、適宜「所持カード」
という。）の中から、進化させたいカード（つまり、カードデータの変更処理の対象とす
るカード）としてベースカードを選択する。ベースカードとして選択されたカードは、選
択オブジェクトの一例である。
進化合成では、ベースカードごとに、そのベースカードを進化させるのに必要な複数のカ
ード（「参照カード」という。）の組合せ条件が決められている。進化合成が実行される
と、その進化合成に使用された参照カードはユーザの所持カードから消失する。
本実施形態において、ベースカード、参照カード、および、所持カードはそれぞれ、ベ
ースオブジェクト、参照オブジェクト、および、所持オブジェクトの一例である。
本実施形態のゲームでは、ユーザによってベースカードとして選択されたカードに対応
する組合せ条件となる複数の参照カードをユーザが所持していることが、選択されたカー
ドを進化させるための条件（変化条件の一例）である。

なお、本実施形態のゲームでは、ユーザが自身の所持カードを失う処理の一例として、
例えば、通常合成処理と売却処理がある。通常合成処理を実行するには、ユーザは自身の
所持カードの中から、成長させたいカードとしてベースカードを選択する。通常合成処理
では、ベースカードごとに参照カードの組合せ条件が決められていなくてもよく、ユーザ
は適宜参照カードを所持カードの中から選択することができる。通常合成処理が実行され
ると、ベースカードのカードパラメータが変化する（例えば、カードレベルやスキルレベ
ルが増加する）代わりに、参照カードはユーザの所持カードから消失する。
売却処理では、ユーザの所持カードの中から選択されたカード（例えば、ユーザが不要
とするカード）を、そのカードに対応する売却価格（例えば、ゲーム上のポイント）をユ
ーザが得る代わりに、売却したカードがユーザの所持カードから消失する。

本実施形態のゲームにおいて、ユーザが所望のカードを進化合成によって進化させたい
が当該カードを進化させるのに必要な参照カードの一部、あるいはすべてをユーザが所持
していない場合を考える。この場合、参照カードの組合せ条件を満たすための新しいカー
ド（つまり、残りの参照カード）をユーザが入手できるまで所望のカードの進化合成を実
行することを待機する必要がある。しかし、ユーザが、ベースカードや、ベースカードを
進化させるために所持している参照カードの一部を誤って消失してしまう場合（例えば、
上述した売却処理や通常合成等）がある。特に、進化合成のための組合せ条件を成立させ
るのに必要となる参照カードが多い場合や、ベースカードごとに組合せ条件が異なる場合
は、ユーザは進化合成のための組合せ条件を覚えておくのが大変であり、ベースカードや
参照カードを誤って消失させてしまう可能性が高くなる。
そこで、本実施形態では、ユーザの所持カードのうち、ベースカード、および、ベース
カードを進化させるのに必要となる複数の参照カードの中で少なくともいずれかを、ユー
ザが進化合成のために予約できるようにする。進化合成のために予約されたカードを、以
下の説明では「予約済カード」という。予約済カードは、制限オブジェクトの一例である
。予約済カードに対しては、予約の対象となる進化合成以外の処理（例えば、上述した通
常合成や売却処理）の実行が制限される。

進化合成におけるカードの予約について、図４を参照して具体的に説明する。図４は、
進化合成におけるカードの予約を概念的に説明するための図である。
図４において、ユーザがカードＱ，Ａ，Ｃを所持し、カードＱを進化させたい場合を考
える。ここでは、カードＱを進化させるための条件（変化条件）が、カードＱに対応する
組合せ条件である複数の参照カードＡ，Ｂ，Ｃをユーザがすべて所持している場合を想定
する。ユーザは現時点でカードＢを所持していないため、カードＱに対して進化合成を実
行することはできない。その場合に、ユーザは、自身が所持しているカードＱ，Ａ，Ｃを
誤ってカードＱの進化合成以外の処理に用いて消失してしまうことがないように、カード
Ｑの進化合成のためにカードＱ，Ａ，Ｃを予約しておく。そして、予約済カードＱ，Ａ，
Ｃは、カードＱの進化合成以外の処理（例えば、上述した通常合成や売却）に用いられる
ことが制限される。

なお、予約済カードについて「進化合成以外の処理に用いられることが制限される」と
は、予約済カードを用いた、目的とする進化合成以外の処理自体が禁止されることに限ら
れず、予約済カードを用いた、目的とする進化合成以外の処理は実行可能であるが、その
処理の実行の手続きをし難くする、あるいは処理の実行手続きを煩雑にすることであって
もよい。予約済カードについての「進化合成以外の処理」が、予約済カードをユーザの所
持カードから消失させる処理（つまり、予約済カードを非所持とする処理）である場合に
、当該処理が制限されることが特に好ましい。
また、図４に示す例では、ユーザが所持するベースカードＱおよび参照カードＡ，Ｃの
すべてを予約済カードとする場合について例示したが、この場合に限られない。いずれの
所持カードを予約済カードとするかについては、ユーザが適宜選択できるようにしても構
わない。

（１－５）データテーブルの構成
次に、ゲームサーバ２０のストレージ２５に格納されるカードデータテーブル、進化合
成データテーブル、所持カードデータテーブル、および、予約データテーブルについて、
図５～８を参照して順に説明する。ゲームサーバ２０のストレージ２５は、記憶装置の一
例である。

（i）カードデータテーブル
カードデータテーブルには、本実施形態のゲームで使用されるカードのデータが記録さ
れている。図５にカードデータテーブルの構成例を示す。図５に示す例では、カードＩＤ
ごとにカード名、カード画像、および、カードパラメータのデータが含まれる。カードＩ
Ｄは、オブジェクトを示す情報の一例である。
カード名は、カードに表示されるキャラクタの名称を示す文字列である。カード画像は
、カードに表示されるキャラクタの画像である。カードパラメータは、レアリティ、属性
、コスト、スキル、売却価格、攻撃力、防御力、および、限定フラグの各データから構成
されている。
レアリティは、カードの希少価値を示す指標であり、図５に示す例ではＲ１～Ｒ５の順
にレアリティが高く設定されている。
属性は、カードに表示されるキャラクタの属性であり、図５に示す例ではＮ１～Ｎ３の
いずれかである。
コストは、カードをユーザのカードチームに組み込むときに参照される値である。例え
ばカードチームによる対戦を行う場合には、カードチームに含まれるカードのコストの総
和が所定値以下に制限される。
スキルは、カードを用いてゲームを実行するときに有利となる効果を示す情報であり、
図４に示す例では、ＳＫ１～ＳＫ１２の様々な効果を備えたスキルが各カードに設定され
ている。なお、すべてのカードがスキルを備えていなくてもよい。
売却価格は、ユーザが自身で所持しているカードを売却するときにユーザが得られるゲ
ーム上のポイントである。
攻撃力および防御力は、カードを対戦で用いるときに参照されるパラメータである。
限定フラグは、期間限定で発行されたカードであるか否かを示すフラグである。図４に
示す例では、限定フラグが「１」であるカードは期間限定で発行されたカードであること
を意味し、限定フラグが「０」であるカードは期間限定でないカードであることを意味す
る。

（ii）進化合成データテーブル
進化合成データテーブルには、本実施形態のゲームのカードの進化合成の条件が記録さ
れている。図６に進化合成データテーブルの構成例を示す。図６に示す例では、進化合成
の内容を識別するための進化ＩＤごとに、進化前カードＩＤ（つまり、進化前のベースカ
ードとなるカードのカードＩＤ）、進化後カードＩＤ（ベースカードの進化後のカードＩ
Ｄ）、および進化合成を実行するために必要となる参照カードのカードＩＤの組合せ条件
（Ｃ１～Ｃ５の欄の５枚の参照カード）が記録されている。例えば、進化ＩＤ：０００２
が示す条件では、ユーザが所持カードの中からカードＩＤ：００７２のカードをベースカ
ードとして選択し、ユーザの所持カードの中にカードＩＤ：００２５，００６０，００７
０の３枚のカードの組合せが存在する場合には、進化合成を実行することによって、カー
ドＩＤ：００７２のカードをカードＩＤ：９０７２のカードに進化させることができる。
すなわち、進化合成データテーブルにおける参照カードＩＤの組合せ条件は、進化前カー
ドＩＤに対応するカードを変化させる変化条件の一例である。
なお、参照カードのカードＩＤの組合せ条件を示すＣ１～Ｃ５の欄には、少なくともい
ずれか２つの欄に同一のカードＩＤが記録されていることもある。例えば、ベースカード
を進化合成するときに使用する参照カードの組合せ条件に同一の参照カードが２枚以上含
まれていてもよい。ベースカードを進化させるための参照カードの組合せ条件が、同一の
カードＩＤである参照カードが所定数含まれることである場合には、図６に示したような
データ形式ではなく、参照カードのカードＩＤとその枚数とからなるデータ形式であって
もよい。

（iii）所持カードデータテーブル
所持カードデータテーブルは、ユーザの所持カードの情報（所持情報）が記録されてい
る。図７に所持カードデータテーブルの構成例を示す。図７では１ユーザ分の所持カード
データテーブルを例示するが、所持カードデータテーブルは、ゲームに登録しているユー
ザ毎に設けられる。
図７に示す所持カードデータテーブルには、カードＩＤごとに、シリアル番号、カード
レベル、スキルレベル、および、予約ＩＤの各データが対応付けられて記録されている。
シリアル番号は、ユーザにカードが付与された時点で決定される固有の番号である。同一
のカードＩＤのカードに対しても異なるシリアル番号が付される。なお、カードが進化し
た場合には、そのカードの進化前後でシリアル番号を変化させてもよいし、変化させなく
てもよい。
カードレベルはカードの育成レベルを示すパラメータであり、例えば上記通常合成を実
行することによって増加する。ユーザがカードを取得した時点でのカードレベルの値（初
期値）は１であり、ユーザは通常合成を実行することでそのカードを成長（つまり、カー
ドレベルを増加）させることができる。
スキルレベルはカードの育成レベルを示すパラメータであり、特にカードが備えるスキ
ルのレベルを示すパラメータである。ユーザがスキルを備えたカードを取得した時点での
スキルレベルの値（初期値）は１であり、例えば所定の条件を満たすカードを参照カード
とした通常合成を行うことによってカードのスキルレベルを増加させることができる。カ
ードのスキルレベルが増加するにつれて、スキルによって発生する効果が増大する。
予約ＩＤは、進化合成のための予約内容を識別するための識別情報である。予約済カー
ドとなっているユーザの所持カードには、予約ＩＤが対応付けられている。例えば、図７
に示す例では、カードＩＤ：０５９１，００１０（２枚）、００３３、２００５の５枚の
カードが予約済カードであることを示している。所持カードデータテーブルに記録されて
いる予約ＩＤは、後述する予約データテーブルに記録されている予約ＩＤに対応している
。

（iv）予約データテーブル
予約データテーブルは、ユーザの進化合成のための予約済カードの情報が記録されてい
る。図８に予約データテーブルの構成例を示す。図８では１ユーザ分の予約データテーブ
ルを例示するが、予約データテーブルは、ゲームに登録しているユーザ毎に設けられる。
図８において、予約ＩＤは進化合成の予約が行われた順に発行されるＩＤである。図８
に示す例では、０１，０２，…といった具合に昇順に番号が記録される。進化ＩＤは、進
化合成データテーブルに示した進化ＩＤに対応しており、進化合成の内容を特定するＩＤ
である。
予約済カードのシリアル番号のうち、進化前カードのシリアル番号は、進化合成のベー
スカードとしてユーザによって選択された所持カードに対応するシリアル番号である。予
約済みカードのシリアル番号のうち参照カードのＣ１～Ｃ５の欄はそれぞれ、進化合成デ
ータテーブルの参照カードＩＤの組合せ条件を構成するＣ１～Ｃ５の欄に対応しており、
各欄に対応する参照カードが予約済みである場合には、その参照カードのシリアル番号が
記録されている。
参照カードの各欄において、予約済みでない参照カードに対応する欄には「予約無し」
を示すデータ（例えば、ＮＵＬＬ）が記録される。
ユーザが所定の操作入力を行うことによって、所持カードを対象として予約処理が実行
された場合には、そのカードに対応する欄に、そのカードに対応するシリアル番号が書き
込まれる。
なお、以下では、予約データテーブルを設ける場合について説明するが、予約データテ
ーブルを独立して設けることは必須ではない。進化合成のための予約の管理方法として、
予約データテーブルに記録すべきデータを、所持カードデータテーブルに記録してもよい
。その場合には、所持カードデータテーブルにおいて、予約済カードのカードＩＤに対応
付けて、予約ＩＤ、進化ＩＤ、Ｃ１～Ｃ５のいずれかの文字列（進化合成データテーブル
のＣ１～Ｃ５の欄に対応する文字列であれば何でもよい。）が記録される。

以下の説明では、カードＩＤに関連付けられたカード名、カード画像、シリアル番号、
および、カードパラメータを総称して、適宜「カードデータ」という。カードデータを構
成するカードパラメータは、カードデータテーブルに記録される各カードパラメータや、
所持カードデータテーブルに記録されるカードレベル、スキルレベルが含まれる。すなわ
ち、カード名、カード画像、シリアル番号、および、各カードパラメータの中のいずれか
のデータが、カードデータに相当する。カードデータは、オブジェクト情報の一例である
。

（１－６）カードの予約および進化合成処理の具体例
以下、本実施形態のゲームのカードの予約および進化合成処理の具体例について、図９
～１２を参照しながら説明する。図９～１２はそれぞれ、本実施形態のゲームの処理を実
行しているときのユーザ端末１０に表示される画面の一例を示す図である。

（Ａ）進化合成の予約処理（図９）
図９は、ユーザの所持カードについて進化合成のための予約をするときの一連の表示画
面の変化を示している。図９において、画像Ｐ１は、本実施形態のゲームにおいてユーザ
がモンスターカード（以下、単に「カード」という。）について、処理要求を行うときの
画像である。画像Ｐ１には、ユーザの操作対象として、ボタンｂ１（「所持モンスターを
見る」）、ボタンｂ２（「チーム編成」）、ボタンｂ３（「通常合成」）、ボタンｂ４（
「進化合成」）、ボタンｂ５（「売却」）が設けられる。
ボタンｂ１は、ユーザの所持カードの閲覧処理の要求を行うときに操作されるボタンで
ある。ボタンｂ２は、ユーザが自身の所持カードの中から他のユーザやＮＰＣとの対戦に
おいて使用するカードを選択するときに操作されるボタンである。ボタンｂ３は、ユーザ
が所持カードの中からベースカードとして選択したカードの通常合成の実行要求を行うと
きに操作されるボタンである。ボタンｂ４は、ユーザが所持カードの中からベースカード
として選択したカードの進化合成の実行要求を行うときに操作されるボタンである。ボタ
ンｂ５は、ユーザが所持カードの中から選択したカードに対して売却処理の要求を行うと
きに操作されるボタンである。

画像Ｐ１においてボタンｂ４（「進化合成」）が操作されると、Ｐ２に示すように画像
が変化する。画像Ｐ２では、ユーザの所持カードの中からいずれかのカードをベースカー
ドとして選択するために、複数の所持カードが一覧表示される。なお、進化することがで
きないカード（図示する例では、カードＴＯＭ，ＴＥＤ，ＤＳＧ）についてはベースカー
ドとして選択できないように、画像が構成されている。すなわち、画像Ｐ２では、ユーザ
の所持カードのうち進化可能なカードと進化不可能なカードとをユーザが識別可能な表示
形式で示している。進化可能なカードと進化不可能なカードとをユーザが識別可能な表示
形式で示す方法は、図９の画像Ｐ２に示した例に限られない。所持カードの一覧は各カー
ドのカード名の文字列の一覧であってもよく、その場合には、進化可能なカードと進化不
可能なカードとを文字列の輝度、サイズ等によって識別できるようにしてもよい。 画像
Ｐ２において、進化可能ないずれかのカードとして例えばカードＫＬＭが選択されると、
Ｐ３に示すように画像が変化する。画像Ｐ３には、選択したカードを進化合成のベースカ
ードとして確定させるためのボタンｂ６（「選択する」）と、画像Ｐ２に戻って別のカー
ドをベースカードとして選択するためのボタンｂ７（「戻る」）とが含まれる。
画像Ｐ３においてユーザによってボタンｂ６が操作されると、ベースカードとして選択
されたカードＫＬＭが進化するために必要な参照カードの条件を満たしていない場合には
、Ｐ４に示すように画像が更新される。画像Ｐ４は、ベースカードとして選択されたカー
ドＫＬＭが進化するために必要な参照カードのうちユーザが所持しているカードを、進化
合成のために予約するための画像である。なお、画像Ｐ３においてユーザがボタンｂ６を
操作した時点で、ベースカードとして選択されたカードＫＬＭが進化するために必要な参
照カードの条件を満たしている場合には、画像Ｐ４に代えて、カードＫＬＭの進化合成を
実行するか否かについてのユーザが指示するための画像（図示せず）が表示される。

画像Ｐ４では、進化前カード（ここでは、ベースカードであるカードＫＬＭ）と進化後
カード（例えば、カードＱＲＳ）とを示す表示領域１０１、進化合成に必要な参照カード
とその状態（所持、未所持、予約済のいずれか）を示す表示領域１０２、および、ユーザ
が所持している参照カードを予約するためのボタンｂ８（「予約する」）を含む。画像Ｐ
４においてボタンｂ８が操作されると、ユーザが所持している参照カードについて予約が
実行され、予約が完了したことを示す画像Ｐ５が表示される。
なお、画像Ｐ４では、ユーザが所持している参照カードのすべてが予約される場合につ
いて示したが、予約するカードを個別に選択可能に構成されてもよい。例えば、所持して
いる参照カードの少なくともいずれかを指定して予約するように構成してもよい。

（Ｂ）所持カードの閲覧処理（図１０）
図１０は、ユーザの所持カードの閲覧処理を実行するときの一連の表示画面の変化を示
している。図１０において、画像Ｐ１は図９に示したものと同じである。
画像Ｐ１においてボタンｂ１（「所持モンスターを見る」）が操作されると、Ｐ６に示
すように画像が変化する。画像Ｐ６では、ユーザの所持カードの一覧が表示される。この
とき、進化合成の予約済カードについては、ユーザが他のカードと識別可能な表示形式で
表示することが好ましい。図１０に示す例では、予約済カード上に鍵の形を示すマークを
表示させることで、ユーザに予約済カードであることを示している。予約済カードである
ことを示すことで、ユーザが予約済カードを進化合成以外の処理に用いて消失させてしま
うことを防止することができる。
なお、予約済カードとそれ以外のカードとをユーザが識別可能な表示形式で示す方法は
、図１０の画像Ｐ６に示した例に限られない。所持カードの一覧は各カードのカード名の
文字列の一覧であってもよく、その場合には、予約済カードとそれ以外のカードとを文字
列の輝度、サイズ等によって識別できるようにしてもよい。

（Ｃ）予約済カードの売却処理（図１１）
図１１は、ユーザが予約済カードを売却するときの処理を実行するときの一連の表示画
面の変化を示している。図１１において、画像Ｐ１は図９に示したものと同じである。
画像Ｐ１においてボタンｂ５（「売却」）が操作されると、Ｐ７に示すように画像が変
化する。画像Ｐ７では、ユーザの所持カードの一覧が表示される。画像Ｐ７の所持カード
の一覧の中からユーザが売却することを希望するカードを選択する。このとき、所持カー
ドの中から予約済カードを売却対象として選択した場合、Ｐ８に示すように画像が変化す
る。画像Ｐ８は、ユーザが選択したカードが予約済カードであることを通知するためのテ
キストと、売却処理を続行するか否かを選択させるためのボタンｂ１０（「続ける」）お
よびｂ１１（「戻る」）を含む。画像Ｐ８においてボタンｂ１０が操作された場合には、
予約済カードであっても売却処理が行われ、それによってユーザは当該カードに対応する
売却価格のポイントを得るとともに予約済カードを失う。

画像Ｐ８に示すように、予約済カードを売却処理の実行手続きを煩雑にすることは、予
約済カードが進化合成以外の処理に用いられることを制限する一例である。
また、図１１には図示していないが、画像Ｐ７において、ユーザの所持カードの一覧を
、予約済カードについては選択できないような態様で表示するようにしてもよい。すなわ
ち、予約済カードが進化合成以外の処理に用いられることをより確実に防止するために、
予約済カードの売却処理の実行が禁止されるようにしてもよい。

（Ｄ）進化合成処理（図１２）
図１２は、ユーザの操作に基づいて進化合成処理を実行するときの一連の表示画面の変
化を示している。図１２において画像Ｐ１０は、ユーザがゲームを実行中に新たなカード
ＤＳＧを入手した場合に表示される画像の一例である。
この新たなカードＤＳＧを入手したことで、予約済みの進化合成の参照カードの組合せ
条件が満たされるようになった場合には、新たなカードの入手によって、予約された進化
合成のための参照カードの組合せ条件が満たされるようになったことをユーザに通知する
ことが好ましい。より好ましくは、Ｐ１１に示すように進化合成を実行するための画像を
表示することが好ましい。
画像Ｐ１１は、進化前カード（カードＫＬＭ）と進化後カード（カードＱＲＳ）とを示
す表示領域１０１、進化合成に必要な参照カードとその状態（ここでは、予約済または所
持）を示す表示領域１０２、および、進化合成を実行するか否かの要求を受け付けるため
のボタンｂ２０（「はい」）およびボタンｂ２１（「いいえ」）が表示される。
画像Ｐ１１においてボタンｂ２０が操作されると、Ｐ１２に示すように画像が変化する
。画像Ｐ１２の例では、進化後カードのカード画像やカード名、およびパラメータの少な
くとも一部が表示される。
なお、新たなカードを入手したことで、予約済みの進化合成の参照カードの組合せ条件
が満たされるようになった場合には、ユーザによる操作を待たずに進化合成を実行し、実
行後にユーザに対して、進化合成が行われたことを通知してもよい。すなわち、図１２に
おいて、画像Ｐ１０に続いて画像Ｐ１２が表示されてもよい。

（１－７）情報処理装置が備える機能の概要
次に、上述した本実施形態のゲームを実現するためにゲームサーバ２０が備える機能に
ついて説明する。図１３は、本実施形態のゲームサーバ２０で主要な役割を果たす機能を
説明するための機能ブロック図である。図１３において、データテーブル群７０は、前述
したように、カードデータテーブル、進化合成データテーブル、所持カードデータテーブ
ル、および、予約データテーブルを含む。なお、図１３に示す機能ブロック図に含まれる
手段のすべてが本発明に必須の要素とは限らない。例えば、本発明の一態様では、受付手
段５１、取得手段５５、出力手段５６、および、制限手段５８を備えていればよい。

受付手段５１は、ユーザの操作入力に関する情報に基づいてユーザからの各種の要求を
受け付ける機能を備える。本実施形態のゲームにおいてユーザからの要求としては、例え
ば、カードの進化合成処理の要求、進化合成の予約処理の要求、進化合成の実行要求、ユ
ーザの所持カードの閲覧処理の要求、ユーザの所持カードの売却処理の要求などがある。
進化合成の予約処理の要求は、出力手段５６により画像データが出力されたことに応じ
て、進化合成におけるベースカード、および、ベースカードに対応する複数の参照カード
うち少なくともいずれかのカードを進化合成のために予約し、当該進化合成以外の処理を
制限させる要求である。
受付手段５１の機能を実現するために、ゲームサーバ２０は、通信インタフェース部２
４を介して、ユーザ端末１０から画像であるウェブページ内のユーザによるボタンの操作
入力に対応する要求を受信する。ゲームサーバ２０のＣＰＵ２１は、受信した要求に含ま
れる情報に基づいて、要求の内容を判別し、要求の受付処理を行う。受付処理では、要求
がＲＡＭ１３に記録される。ＣＰＵ２１は、受け付けられた要求に応じた処理を順に実行
する。

ゲーム処理手段５２は、受付手段５１にて受け付けたユーザ端末１０からの要求に基づ
いて、進化合成以外の様々なゲームの処理を実行する機能を備える。本実施形態のゲーム
の処理は、適宜設けられてよいが、例えば、ユーザ間の対戦処理、ユーザ対ＮＰＣの対戦
処理、ユーザによるクエスト処理、ユーザの所持カードの通常合成の処理、ユーザの所持
カードの売却処理である。
対戦処理については詳しく述べないが、例えば、ユーザは、コストの総和が所定の上限
値以下となるように予め複数の所持カードからなるチームを編成し、チームによって他の
ユーザまたはＮＰＣと対戦する。対戦結果は、チームを構成する各カードの攻撃力、防御
力、スキルなどのパラメータによって決定される。
クエスト処理は、ユーザがゲーム内のエリアを探索する処理を行うことで、カードやア
イテムを入手するための処理である。

ユーザの所持カードの通常合成の処理を実行する場合のゲーム処理手段５２の機能は、
以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ベースカードおよび参
照カードについてのユーザの選択結果を含む通常合成の実行要求を受け付けると、所持カ
ードデータテーブルからベースカードおよび参照カードのカードデータを読み出してＲＡ
Ｍ２３に展開する。次いでゲームサーバ２０のＣＰＵ２１は、ベースカードおよび参照カ
ードのパラメータに基づいてベースカードのパラメータ（例えば、カードレベルやスキル
レベル）を変更し、変更後のベースカードのパラメータを所持カードデータテーブルに書
き込むとともに、所持カードデータテーブルから参照カードとした所持カードのカードデ
ータを削除する。なお、ベースカードのカードレベルやスキルレベルは、通常合成を実行
する度に常に増加するとは限らない。例えば、通常合成を実行する度にカードに関連付け
られた育成パラメータの値を増加させ、その育成パラメータの値が所定値に達した場合に
カードレベルを１つ増加させるとともに育成パラメータの値をゼロにリセットするように
してもよい。

ユーザの所持カードの売却処理を実行する場合のゲーム処理手段５２の機能は、以下の
ようにして実現される。ゲームサーバ２０のＣＰＵ２１は、売却処理の要求を受け付け、
売却対象のカードの選択結果を取得すると、所持カードデータテーブルから売却対象のカ
ードのカードデータを削除する。さらにゲームサーバ２０のＣＰＵ２１は、カードデータ
テーブルから売却対象のカードの売却価格の値（ポイント）を読み出し、読み出したポイ
ントをユーザに付与する処理を行う。ポイントをユーザに付与する処理は、例えば、ユー
ザデータベース（図示せず）に記録されているユーザの所持ポイントの値を更新する処理
である。

判定手段５３は、ベースカードに対応する組合せ条件である複数の参照カードがユーザ
の所持カードに含まれるという条件を満たすか否かを判定する機能を備える。
判定手段５３の機能を実現するために、例えば、ゲームサーバ２０のＣＰＵ２１は、予
約データテーブルにおいて判定対象とする予約ＩＤに対応する参照カードがすべて揃った
か否か判定する。具体的には、ゲームサーバ２０のＣＰＵ２１は、判定対象とする予約Ｉ
Ｄに対応する進化ＩＤに対応する各参照カードＩＤ（図６の進化合成データテーブルのＣ
１～Ｃ５の欄に記録されているカードＩＤ）を、進化合成データテーブルから読み出す。
さらにＣＰＵ２１は、読み出したＣ１～Ｃ５の欄のカードＩＤに対応した、予約データテ
ーブルにおける参照カードのＣ１～Ｃ５のすべての欄に、シリアル番号が記録されている
か否か判定する。すべての欄にシリアル番号が記録されている場合には、ベースカードに
対応する複数の参照カードの組合せがユーザの所持カードに含まれるという条件を満たし
たことになる。

カードデータ変更手段５４は、判定手段５３によって条件を満たすと判定された場合に
、ベースカードのカードデータを変更する進化合成を実行する機能を備える。進化合成は
、カードを変化させる処理、あるいは、変更処理の一例である。
本実施形態の例では、カードデータ変更手段５４の機能を実現するために、ゲームサー
バ２０のＣＰＵ２１は、進化合成の実行要求を受け付けると、所持カードデータテーブル
において、進化前カード（つまり、進化合成のベースカード）のカードデータを消去し、
進化後カードのカードデータを新たに書き込む。それによって、ユーザの所持カードのベ
ースカードが進化することになる。なお、進化合成データテーブルに示すように、進化前
と進化後とでカードＩＤは異なるため、カード名、カード画像、および、カードパラメー
タのうち少なくともいずれかが進化合成によって変更される。

取得手段５５は、ユーザによって選択されたベースカード（選択オブジェクトの一例）
に対応する参照カードの組合せ条件（変化条件の一例）である複数の参照カードＩＤを、
進化合成データテーブルから取得する機能を備える。また、取得手段５５は、進化合成の
ためにカードの予約をするに当たって、ユーザの操作入力に基づいて、ユーザの所持カー
ドの中のいずれかのカードのシリアル番号（オブジェクト情報の一例）を取得する機能を
備える。
取得手段５５が参照カードの組合せ条件である複数の参照カードＩＤを取得する場合、
ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からベースカードの選択結果を取得し
たことに応じて、進化合成データテーブルを参照して、ベースカードに対応する組合せ条
件を構成する複数の参照カードＩＤを読み出す。
一方、取得手段５５がカードのシリアル番号を取得する場合、ゲームサーバ２０のＣＰ
Ｕ２１は、ユーザ端末１０から進化合成の予約処理の要求を受け付けると、進化合成の対
象となるベースカード、および、当該ベースカードに対応する複数の参照カードの中から
、予約済みでない所持カードを、所持カードデータテーブルを参照して特定し、特定した
カードのシリアル番号を読み出す。

出力手段５６は、取得手段５５により取得された、参照カードの組合せ条件である複数
の参照カードＩＤ（複数のオブジェクトを示す情報）を用いて、当該複数の参照カードを
ユーザにそれぞれ識別可能な表示形式で表示させるための画像データ（出力データの一例
）を出力する機能を備える。出力手段５６によって表示される画像の一例は、図９の画像
Ｐ４である。
出力手段５６の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザ端末
１０からベースカードの選択結果（シリアル番号）を取得すると、進化合成データテーブ
ルを参照し、ユーザによって選択されたベースカードのシリアル番号に対応するカードＩ
Ｄと一致する進化前カードＩＤに対応する組合せ条件となる複数の参照カードＩＤ（Ｃ１
～Ｃ５の欄のカードＩＤ）を読み出す。ＣＰＵ２１は、各参照カードＩＤに対応するカー
ドデータを取得するために、カードデータテーブルおよび所持カードデータテーブルを参
照する。そしてＣＰＵ２１は、選択されたベースカードと、当該ベースカードに対応する
複数の参照カードとを、それぞれユーザに識別可能な表示形式で表示される画像を生成す
る。「ユーザに識別可能な表示形式」の一例は、図９の画像Ｐ４に例示したように、各カ
ードのカード画像を表示するようにした形式である。

記録手段５７は、進化合成の予約処理の要求を受け付けたことに応じて、取得手段５５
によって取得されたシリアル番号をストレージ２５内の予約データテーブルに予約済カー
ドとして記録する機能を備える。本実施形態の例では、予約対象カードは、選択されたベ
ースカードの進化合成とは異なる処理に用いられることを制限すべき制限オブジェクトと
して特定されたカードである。取得手段５５によって取得された予約済みでない所持カー
ドのシリアル番号が、予約対象カードのシリアル番号として予約データテーブルに記録さ
れる。

記録手段５７の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、進化合成の
予約処理の要求を受け付けると、予約データテーブルにアクセスし、予約対象カードのシ
リアル番号を書き込む。より具体的には、予約対象カードのうちベースカードとして選択
されたカードのシリアル番号が予約データテーブルに記録されていない場合には、新たな
予約ＩＤを発行する。ＣＰＵ２１は、発行した予約ＩＤに対応付けて、ベースカードとし
て選択されたカードのシリアル番号を「進化前カード」の欄に書き込む。さらに、予約対
象カードのうち参照カードのシリアル番号に対応するカードＩＤと同一の参照カードＩＤ
の欄（Ｃ１～Ｃ５の欄のいずれか）を特定し、特定した欄に予約対象カードのうち参照カ
ードのシリアル番号を書き込む。
一方、予約ＩＤが発行済みである場合には、「進化前カード」の欄にはシリアル番号が
既に記録されているため、ＣＰＵ２１は、予約対象カードのうち参照カードのシリアル番
号の書き込みのみを行う。

制限手段５８は、予約データテーブルに記録されている予約済カードが、目的とする進
化合成以外の処理に用いられることを制限する機能を備える。より具体的には、制限手段
５８は、受付手段５１により進化合成の予約処理の要求を受け付けたことに応じて、当該
ユーザの所持カードのうち、取得手段５５により取得された参照カードの組合せ条件と、
要求元のユーザの所持カードデータテーブル（所持情報の一例）とに基づいて予約データ
テーブルに記録されたカード（つまり、予約済カード）に対して、目的とする進化合成以
外の処理に用いられることを制限する機能を備える。
「目的とする進化合成以外の処理に用いられる」とは、目的とする進化合成に対応付け
られて予約済カードとして記録されているカードが、その目的とする進化合成以外の進化
合成や通常合成に用いられる場合も含まれる。
制限手段５８による制限方法は様々な方法が考えられる。例えば、制限対象となるカー
ドを、ユーザが目的とする進化合成以外の処理を禁止する方法や、制限対象となるカード
が目的とする進化合成以外の処理のために選択されたときに、ユーザに対して警告を行う
、あるいは当該処理の続行を確認する処理を行う方法などが挙げられる。

例えば、ゲームサーバ２０のＣＰＵ２１は、本実施形態のゲームの様々な処理のいずれ
かの処理の実行要求を受け付けた場合、ユーザの所持カードが処理対象のカードとして選
択されたときには、所持カードデータテーブルを参照して、当該選択されたカードのカー
ドＩＤに予約ＩＤが対応付けられているか否かについて判定する。ＣＰＵ２１は、選択さ
れたカードのカードＩＤに予約ＩＤが対応付けられ、かつ実行要求に係る処理が予約ＩＤ
に対応する進化合成の処理ではない場合には、当該処理を禁止してもよいし、選択された
カードが予約済カードであることをユーザに報知してもよい。あるいは、選択されたカー
ドが予約済カードであることをユーザに報知するとともに、処理を続行するか否かについ
てユーザに確認してもよい。予約データテーブルには進化ＩＤと予約済カードのシリアル
番号が対応付けられているため、ゲームサーバ２０のＣＰＵ２１は、予約済カードに対応
した、目的とする進化合成（つまり、特定の進化ＩＤに対応した進化合成）を特定するこ
とができる。そのため、ユーザが特定の所持カードを用いて実行しようとする処理が、目
的とする進化合成の処理であるか否かを判別することができる。

報知手段５９は、所定のタイミングで、ユーザの所持カードデータテーブル（所持情報
の一例）と、取得手段５５により取得された参照カードの組合せ条件とに基づき、当該組
合せ条件に含まれる複数の参照カードをユーザが所持していると判定された場合、当該組
合せ条件に含まれる複数の参照カードを所持していることを上記ユーザが識別可能な形式
で報知する機能を備える。本実施形態の例では、図１２の画像Ｐ１１に示したように、ユ
ーザがカードを入手したタイミングでユーザに報知するための画像データが生成され、ユ
ーザ端末１０に送信される。
報知手段５９の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、例えば、ユ
ーザがカードを入手した場合、そのカードを入手したことによって、予約データテーブル
のいずれかの予約ＩＤに対応する進化合成に必要な複数の参照カードがユーザの所持カー
ドに含まれることになったか否か、つまり、予約ＩＤに対応する参照カードがすべて揃っ
たか否か判定する。すべて揃ったと判定した場合には、進化合成に必要な参照カードが揃
ったことをユーザに報知する画像データを作成し、ユーザ端末１０へ送信する。

報知手段５９はさらに、所定のタイミングで、ユーザの所持カードデータテーブル（所
持情報の一例）と、取得手段５５により取得された参照カードの組合せ条件とに基づき、
当該組合せ条件に含まれる複数の参照カードを所持していると判定されたことにより、ユ
ーザによって選択されたカードの進化合成を実行する条件が成立したと判定された場合、
当該カードの進化合成を実行する条件が成立したことをユーザが識別可能な形式で報知し
てもよい。
本実施形態では、進化合成に必要な参照カードが揃ったことが進化合成を実行する条件
が成立するための必要十分条件である場合の例を示すが、この例に限られない。例えば、
進化合成に必要な参照カードが揃ったことに加え、他の条件（例えば、ユーザが所定量の
ポイントを消費すること）が成立した場合に、進化合成を実行する条件が成立する場合が
あってもよい。その場合には、進化合成に必要な参照カードが揃った時点で他の条件が成
立しないとき（例えば、ユーザが所持するポイントが所定量に足りないとき）には、参照
カードが揃ったことのみをユーザに報知し、他の条件が成立した時点でさらに、進化合成
を実行する条件が成立したことをユーザに報知してもよい。

報知手段５９を備えることは必須ではないが、報知手段５９を設けることで、例えば、
進化合成に必要となる複数の参照カードのうち一部の参照カードを進化合成の実行前に予
約し、残りの参照カードを入手するまで進化合成を待機しているユーザに、カードの入手
によって進化合成に必要な参照カードがすべて揃ったことが報知されるため、ユーザに対
する利便性を高めることができる。

表示手段６０は、ユーザの所持カードのうち、予約済カード（つまり、制限手段５８に
より制限すべき制限オブジェクトとして特定されたカード）と、他のカードとを、当該ユ
ーザが識別可能な表示形式で表示させるための制御を行う機能を備える。このような表示
を行うタイミングは特に限定されるものではないが、本実施形態の例では、(i)ユーザ端
末１０からカードの進化合成処理の要求、および、(ii)ユーザの所持カードの閲覧処理の
要求を取得したタイミングである。

(i) ユーザ端末１０からカードの進化合成処理の要求時の表示
この場合、所持カード毎の表示態様の差異点は、図９の画像Ｐ４に示すように、カード
に関連付けて表示するテキストである。つまり、予約データテーブルに記録されているシ
リアル番号に対応するカードには、「予約済」というテキストがカードに関連付けて表示
され、予約データテーブルに記録されていないシリアル番号に対応するカードには、「所
持」または「未所持」というテキストがカードに関連付けて表示される。表示態様の差異
はこの例に限られず、例えばカードの形態やサイズを変更して表示する場合等、ユーザが
識別可能な表示形式であれば適宜設定してもよい。
この場合の表示手段６０の機能は、以下のようにして実現できる。ゲームサーバ２０の
ＣＰＵ２１は、例えばユーザ端末１０からベースカードの選択結果を取得したときに、そ
のベースカードを進化させるために必要となる複数の参照カードＩＤの組合せを進化合成
データテーブルから読み出し、各参照カードについて、カードの状態（「予約済」、「所
持」または「未所持」のいずれかの状態）を特定する。ＣＰＵ２１は、各参照カードの状
態に基づいて、ユーザ端末１０へ送信（出力）する画像データを生成する。画像データを
生成するにあたっては、各参照カードの状態によって各カードの表示態様が区別される。
ゲームサーバ２０のＣＰＵ２１は、各参照カードの状態を特定するために、所持カードデ
ータテーブルおよび予約データテーブルを参照する。例えば、予約データテーブルにおい
て、ベースカードに対応する進化ＩＤに対応付けられたＣ１～Ｃ５の欄（図８参照）にシ
リアル番号が書き込まれている場合には、各欄に対応する参照カードが「予約済」として
特定される。

(ii)ユーザの所持カードの閲覧処理の要求時の表示
この場合、所持カード毎の表示態様の差異点は、図１０の画像Ｐ６に示すように、カー
ドに関連付けて表示する記号の有無である。つまり、予約データテーブルに記録されてい
るシリアル番号に対応するカード（つまり、予約済カード）には、所定の記号がカードに
関連付けて表示され、予約データテーブルに記録されていないシリアル番号に対応するカ
ード（予約済カードではないカード）には、その所定の記号がカードに関連付けて表示さ
れないようにする。表示態様の差異はこの例に限られず、例えばカードの形態やサイズを
変更して表示する場合等、適宜設定してもよい。
この場合の表示手段６０の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、
所持カードデータテーブルの所持カードの中から予約済カードを特定する。このとき、Ｃ
ＰＵ２１は、予約データテーブルに記録されている予約済カードのシリアル番号を読み出
して、ユーザの所持カードのうち予約済カードを特定する。そして、ユーザの所持カード
の一覧を、予約済カードとそれ以外のカードとをユーザが識別可能な表示形式で、ユーザ
端末１０へ送信（出力）する画像データを生成する。
なお、予約済カードの特定方法は、所持カードデータテーブルの「予約ＩＤ」の欄にデ
ータが記録されているか否かに基づいて行ってもよい。

表示手段６０を設けることは必須ではないが、表示手段６０を設けることで、表示画像
を見たユーザは、予約済カードを他のカードと識別可能に認識することができる。また、
ユーザの所持カードの中からいずれかのカードを指定して何らかの処理を実行する場合に
、予約済カードと他のカードを識別可能に認識できるため、予約済カードを目的とする進
化合成以外の処理に使用することがさらに効果的に防止できる。

（１－８）本実施形態のゲームの処理フロー
次に、本実施形態のゲームの処理フローの一例について、図１４Ａおよび図１４Ｂ、図
１５、図１６Ａ，１６Ｂ、図１７Ａおよび図１７Ｂ、図１８のシーケンスチャートを参照
して説明する。
図１４Ａおよび図１４Ｂは、進化合成の予約処理を示すシーケンスチャートである。図
１５は、所持カードの閲覧処理を示すシーケンスチャートである。図１６Ａおよび図１６
Ｂは、予約済カードの売却処理を示すシーケンスチャートである。図１７Ａおよび図１７
Ｂは、カード入手時の判定処理を示すシーケンスチャートである。図１８は、進化合成処
理を示すシーケンスチャートである。
なお、各図において、図９～１２に示した各画像Ｐ１～Ｐ８、Ｐ１０～Ｐ１２の表示さ
れるステップに各画像の符号を付してある。

（Ａ）進化合成の予約処理（図１４Ａ，図１４Ｂ）
以下で説明する予約処理では、一例として、ユーザが、ベースカードと、当該ベースカ
ードを進化合成させるための複数の参照カードの一部とを所持している場合に、ベースカ
ードと所持している参照カードとを予約する場合を想定する。

図１４Ａにおいて、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図９
の画像Ｐ１のボタンｂ４）をユーザが操作することによって、ユーザ端末１０のＣＰＵ１
１は進化合成処理の要求を受け付け（Ｓ１０）、当該要求をゲームサーバ２０へ送信する
（Ｓ１２）。
ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からの進化合成処理の要求を受け付
けると、進化合成データテーブルおよび所持カードデータテーブルを参照して、進化可能
なユーザの所持カードを読み出す（Ｓ１４）。すなわち、ゲームサーバ２０のＣＰＵ２１
は、所持カードデータテーブルからユーザの所持カードのカードデータを読み出し、進化
合成データテーブルの進化前カードＩＤ（つまり、進化可能なカードのカードＩＤ）をす
べて読み出す。次いでＣＰＵ２１は、ユーザの所持カードの中から進化可能なカード（つ
まり、ベースカード候補）のカードＩＤに対応するシリアル番号を特定し、ベースカード
候補の一覧を含む画像データを生成して（Ｓ１６）、ユーザ端末１０へ送信する（Ｓ１８
）。
なお、Ｓ１６で生成される画像データは、図９の画像Ｐ２に示したように、ユーザの所
持カードのうち進化可能なカードの画像と進化不可能なカードの画像とをユーザが識別可
能な表示形式で生成されることが好ましい。

ユーザ端末１０のＣＰＵ１１は、Ｓ１８で送信された画像データを取得すると、当該画
像データに基づいて画像を表示部１６に表示する（Ｓ２０）。Ｓ２０で表示される画像に
は、図９の画像Ｐ２に例示したように、ベースカード候補となる複数のカードの画像が含
まれ、各カードの画像を操作することで各カードのシリアル番号が選択可能となるように
して構成されている。Ｓ２０で表示された複数のベースカード候補の中でいずれかのカー
ドがベースカードとして選択する操作が行われると、ＣＰＵ１１は、ベースカードの選択
結果（シリアル番号）を受け付け（Ｓ２２）、その選択結果をゲームサーバ２０へ送信す
る（Ｓ２４）。

ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からベースカードの選択結果（シリ
アル番号）を取得すると、進化合成データテーブルを参照し、ユーザによって選択された
ベースカードのシリアル番号に対応するカードＩＤと一致する進化前カードＩＤに対応す
る組合せ条件となる複数の参照カードＩＤ（Ｃ１～Ｃ５の欄のカードＩＤ）を読み出す（
Ｓ２６）。次いでＣＰＵ２１は、所持カードデータテーブルおよび予約データテーブルを
参照して、Ｓ２６で読み出した各参照カードＩＤに対応するカードの状態（未所持、所持
、予約済）を特定し、その特定結果に基づいて画像データを生成する（Ｓ２８）。

各参照カードの状態の特定方法は、以下の通りである。
予約データテーブルの「予約済カードのシリアル番号」の欄に記録されているシリアル
番号を読み出し、所持カードデータテーブルを参照して、読み出したシリアル番号に対応
するカードＩＤを特定する。特定したカードＩＤの中に、Ｓ２６で読み出した参照カード
ＩＤと一致するカードＩＤがある場合には、その参照カードＩＤに対応するカードの状態
は「予約済」として特定する。
ユーザの所持カードデータテーブルに記録されているカードＩＤの中に、Ｓ２６で読み
出した参照カードＩＤと一致するカードＩＤが含まれていると判定し、かつその参照カー
ドＩＤに対応するカードの状態が「予約済」として特定されていない場合には、その参照
カードＩＤに対応するカードの状態は「所持」として特定する。Ｓ２６で読み出した参照
カードＩＤに対応するカードの状態が「予約済」および「所持」のいずれにも特定されて
いない場合には、その参照カードＩＤに対応するカードの状態は「未所持」として特定す
る。

Ｓ２８で生成される画像データは、カードの状態の特定結果によって異なってもよい。
すなわち、Ｓ２６で読み出したすべての参照カードの状態が「所持」または「予約済」
である場合には、ベースカードとして選択されたカードの進化合成に必要な参照カードが
すべて揃っていることを意味するため、ゲームサーバ２０のＣＰＵ２１は、進化合成を実
行するか否かについてのユーザが指示するための画像データを生成する。そして、進化合
成を実行することを選択する操作入力が行われた場合、図１８に示す進化合成処理に進む
。
一方、ＣＰＵ２１は、Ｓ２６で読み出した少なくともいずれかの参照カードの状態が「
未所持」である場合（つまり、ベースカードとして選択されたカードの進化合成に必要な
参照カードがすべて揃っていない場合）には、ベースカードとして選択されたカード、お
よび「所持」の状態の参照カードを進化合成のために予約するための画像データを生成す
る。
ここでは、後者の場合（いずれかの参照カードの状態が「未所持」である場合）を想定
する。後者の場合、ＣＰＵ２１は、図９の画像Ｐ４に例示したように、各参照カードをカ
ード画像と対応付けることで各参照カードがユーザにとって識別可能な表示形式とすると
ともに、各参照カードに対してカードの状態の特定結果を対応付けるようにして、画像デ
ータを生成する。また、画像データは、ベースカードと、複数の参照カードのうち予約済
みでない所持カードとを予約対象カードとした、進化合成の予約処理の要求の受付が可能
となる指示部（例えば、図９の画像Ｐ４のボタンｂ８）が表示されるようにして生成され
る。

ゲームサーバ２０のＣＰＵ２１は、Ｓ２８で生成した画像データをユーザ端末１０へ送
信する（Ｓ３０）。ユーザ端末１０のＣＰＵ１１は、Ｓ３０で送信された画像データを取
得すると、当該画像データに基づいて画像を表示部１６に表示する（Ｓ３２）。ここで、
進化合成の予約処理の要求を行うための指示（例えば、画像Ｐ４のボタンｂ８の操作）が
行われると、ユーザ端末１０のＣＰＵ１１は、進化合成の予約処理の要求を受け付け（Ｓ
３４）、当該要求をゲームサーバ２０へ送信する（Ｓ３６）。

進化合成の予約処理の要求を受け付けると、ゲームサーバ２０のＣＰＵ２１は、予約デ
ータテーブルにアクセスし、Ｓ２４で取得したベースカードのシリアル番号に対応する予
約ＩＤが発行済みであるか（つまり、「進化前カード」の欄に同一のシリアル番号が記録
されているか）否か判定する（Ｓ３８）。予約ＩＤが発行済みである場合には（Ｓ３８：
ＹＥＳ）、Ｓ４２へ進み、予約ＩＤが発行済みでない場合には（Ｓ３８：ＮＯ）、予約Ｉ
Ｄを発行した後に（Ｓ４０）、Ｓ４２へ進む。Ｓ４２では、ゲームサーバ２０のＣＰＵ２
１は、予約データテーブルに、予約ＩＤに対応付けて予約対象カードのシリアル番号を書
き込む。
このとき、ＣＰＵ２１は、予約ＩＤを新たに発行した場合には、予約対象カードのうち
ベースカードのシリアル番号を「進化前カード」の欄に書き込む。さらに、予約対象カー
ドのうち参照カードのシリアル番号に対応するカードＩＤと同一の「参照カード」の欄（
Ｃ１～Ｃ５の欄のいずれか）を特定し、特定した欄に予約対象カードのうち参照カードの
シリアル番号を書き込む。
一方、予約ＩＤが発行済みである場合には、「進化前カード」の欄にはシリアル番号が
既に記録されているため、ＣＰＵ２１は、予約対象カードのうち参照カードのシリアル番
号の書き込みのみを行う。
なお、ＣＰＵ２１は、予約データテーブルの予約ＩＤを新たに発行した場合、その予約
ＩＤに対応するＣ１～Ｃ５の欄のうちシリアル番号の書き込みを行わない欄には、「予約
無し」を示すデータ（例えば、ＮＵＬＬ）を書き込む。

次にゲームサーバ２０のＣＰＵ２１は、所持カードデータテーブルにおいて、予約対象
カードのカードＩＤに対応する「予約ＩＤ」の欄に、Ｓ４２の書き込み対象とした予約Ｉ
Ｄのデータを書き込む（Ｓ４４）。最後にＣＰＵ２１は、予約が完了したことを示す画像
データを生成し（Ｓ４６）、その画像データをユーザ端末１０へ送信する（Ｓ４８）。ユ
ーザ端末１０のＣＰＵ１１は、Ｓ４８で送信された画像データを取得すると、当該画像デ
ータに基づいて画像（例えば、図９の画像Ｐ５）を表示部１６に表示する（Ｓ５０）。

（Ｂ）所持カードの閲覧処理（図１５）
図１５において、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図１０
の画像Ｐ１のボタンｂ１）をユーザが操作することによって、ユーザ端末１０のＣＰＵ１
１は所持カードの閲覧処理の要求を受け付け（Ｓ６０）、当該要求をゲームサーバ２０へ
送信する（Ｓ６２）。
ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からの所持カードの閲覧処理の要求
を受け付けると、所持カードデータテーブルから所持カードのカードＩＤを特定し、カー
ドデータテーブルおよび所持カードデータテーブルから所持カードのカードデータを読み
出す（Ｓ６４）。
次にゲームサーバ２０は、ユーザの所持カードの中から予約済カードを特定するために
、以下の処理を行う。すなわち、ゲームサーバ２０のＣＰＵ２１は、予約データテーブル
に記録されている予約済カードのシリアル番号を読み出して（Ｓ６６）、ユーザの所持カ
ードのうち予約済カードを特定する。そして、ユーザの所持カードの一覧を、予約済カー
ドとそれ以外のカードとをユーザが識別可能な表示形式で画像データを生成し（Ｓ６８）
、その画像データをユーザ端末１０へ送信する（Ｓ７０）。ユーザ端末１０のＣＰＵ１１
は、Ｓ７０で送信された画像データを取得すると、当該画像データに基づいて画像（例え
ば、図１０の画像Ｐ６）を表示部１６に表示する（Ｓ７２）。

（Ｃ）予約済カードの売却処理（図１６Ａ，図１６Ｂ）
図１６Ａにおいて、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図１
１の画像Ｐ１のボタンｂ５）をユーザが操作することによって、ユーザ端末１０のＣＰＵ
１１は所持カードの売却処理の要求を受け付け（Ｓ８０）、当該要求をゲームサーバ２０
へ送信する（Ｓ８２）。
ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からの所持カードの売却処理の要求
を受け付けると、所持カードデータテーブルから所持カードのカードＩＤを特定し、カー
ドデータテーブルおよび所持カードデータテーブルから所持カードのカードデータを読み
出して、所持カードの一覧を含む画像データを生成し（Ｓ８４）、その画像データをユー
ザ端末１０へ送信する（Ｓ８６）。ユーザ端末１０のＣＰＵ１１は、Ｓ８６で送信された
画像データを取得すると、当該画像データに基づいて画像（例えば、図１１の画像Ｐ７）
を表示部１６に表示する（Ｓ８８）。
Ｓ８８で表示される画像には、図１１の画像Ｐ７に例示したように、整列されたユーザ
の所持カードの画像が含まれ、各カードの画像を操作することで各カードのシリアル番号
が選択可能となるようにして構成されている。Ｓ８８で表示された複数の所持カードの中
でいずれかのカードが売却対象カードとして選択する操作が行われると、ユーザ端末１０
のＣＰＵ１１は、売却対象カードの選択結果（シリアル番号）を受け付け（Ｓ９０）、そ
の選択結果をゲームサーバ２０へ送信する（Ｓ９２）。

ゲームサーバ２０は、ユーザ端末１０から売却対象カードの選択結果（シリアル番号）
を取得すると、その売却対象カードが進化合成のための予約済カードである場合には、ユ
ーザに対して警告を行うために以下の処理を行う。すなわち、ゲームサーバ２０のＣＰＵ
２１は、所持カードデータテーブルを参照して、売却対象カードのシリアル番号に予約Ｉ
Ｄが対応付けられているか否かについて判定する（Ｓ９４）。売却対象カードのシリアル
番号に予約ＩＤが対応付けられている場合には（Ｓ９４：ＹＥＳ）、警告用の画像データ
を生成し（Ｓ９６）、その画像データをユーザ端末１０へ送信する（Ｓ９８）。ユーザ端
末１０のＣＰＵ１１は、Ｓ９８で送信された画像データを取得すると、当該画像データに
基づいて画像（例えば、図１１の画像Ｐ８）を表示部１６に表示する（Ｓ１００）。
Ｓ１００で表示される画像には、図１１の画像Ｐ８に例示したように、売却処理を続行
するか否かを確認するためのボタンが設けられている。このボタンのユーザによる操作に
基づいて、ＣＰＵ１１が売却処理の続行要求を受け付けた場合には（Ｓ１０２：ＹＥＳ）
、当該要求をゲームサーバ２０へ送信する（Ｓ１０４）。売却処理の続行要求を受け付け
ない場合には（Ｓ１０２：ＮＯ）、売却対象カードを選択する画像（例えば、図１１の画
像Ｐ７）を再度表示してもよい。

ユーザ端末１０から受信した売却処理の続行要求を受け付けた場合、または、売却対象
カードのシリアル番号に予約ＩＤが対応付けられていない場合（予約済カードでない場合
）には（Ｓ９４：ＮＯ）、ゲームサーバ２０のＣＰＵ２１は、売却対象カードのシリアル
番号をＲＡＭ２３に記憶させ、所持カードデータテーブルにおいて当該シリアル番号の行
のデータを消去する（Ｓ１０６）。さらに、予約データテーブルの更新を行うため、以下
の処理を行う。すなわち、図１６Ｂに示すように、ゲームサーバ２０のＣＰＵ２１は、Ｓ
１０６で消去したカード（消去対象カード）についてＲＡＭ２３に記憶させたシリアル番
号に基づいて、消去対象カードが、予約済みの参照カードであるか、予約済みのベースカ
ードであるか、またはそれらのいずれでもないか判定する（Ｓ１０８）。
ゲームサーバ２０のＣＰＵ２１は、消去対象カードが予約済みの参照カードである場合
には、予約データテーブルに記録されている消去対象カードのシリアル番号をすべて消去
する（Ｓ１１０）。消去対象カードが予約済みのベースカード（進化前カード）である場
合には、予約データテーブルに記録されている消去対象カード（進化前カード）のシリア
ル番号に対応する行のデータをすべて消去する（Ｓ１１２）。消去対象カードが予約済カ
ードでない場合には、予約データテーブルに対する処理は行わない。

上述したように、本実施形態では、進化合成の予約済カードが、進化合成以外の処理で
ある売却処理に用いられる場合には、売却処理が実行されることが制限される。すなわち
、予約済カードに対して直ちに売却処理が実行されるのではなく、売却対象カードが予約
済カードであることをユーザに警告するための画像が提示され、売却処理の続行要求をユ
ーザ端末から取得するまで待ってから、売却処理が実行される。

（Ｄ）カード入手時の判定処理（図１７Ａ，図１７Ｂ）
本実施形態のゲームでは、好ましくは、ユーザが新たにカードを入手した場合に、その
カードを入手したことによって、予約ＩＤに対応した組合せ条件である複数の参照カード
をユーザがすべて所持することになった（つまり、参照カードがすべて揃った）場合には
、予約ＩＤに対応した参照カードがすべて揃ったことをユーザに通知する。そこで、ユー
ザが新たにカードを入手した時点で、予約ＩＤに対応したいずれかの進化合成の参照カー
ドの組合せ条件を満たすことになったか否か判定を行う。
この判定処理では先ず、図１７Ａにおいて、ゲームサーバ２０のＣＰＵ２１がゲームの
処理によってユーザに対してカードを付与する場合に、カードデータテーブルからユーザ
が入手するカード（「入手カード」という。）のカードＩＤを決定する（Ｓ１２０）。入
手カードのカードＩＤを決定するとゲームサーバ２０は、ユーザ端末１０に対して、入手
カードのカードデータを含む画像データを生成してユーザ端末１０へ送信する（Ｓ１２２
）。ユーザ端末１０のＣＰＵ１１は、Ｓ１２２で送信された画像データを取得すると、当
該画像データに基づいて画像（例えば、図１２の画像Ｐ１０）を表示部１６に表示する（
Ｓ１２４）。
次いでゲームサーバ２０のＣＰＵ２１は、入手カードに対応するシリアル番号を発行し
、所持カードデータテーブルに、発行したシリアル番号に対応するデータを書き込む（Ｓ
１２６）。このデータの書き込みでは、カードレベルおよびスキルレベルは初期値の「１
」が書き込まれる。書き込まれるカードＩＤは、Ｓ１２０で決定されたカードＩＤである
。

次に、ゲームサーバ２０のＣＰＵ２１は、予約データテーブルに記録されている進化Ｉ
Ｄをすべて特定し、特定した進化ＩＤに対応する組合せ条件を構成する複数の参照カード
ＩＤを、進化合成データテーブルから読み出す（Ｓ１２８）。図１７ＢにおいてＣＰＵ２
１は、進化合成データテーブルから読み出した各参照カードＩＤが、入手カードのカード
ＩＤ（入手カードＩＤ）と一致するか否か判定する（Ｓ１３０）。入手カードＩＤと一致
する参照カードＩＤが存在しなければ（Ｓ１３０：ＮＯ）、処理を終了する。ＣＰＵ２１
は、入手カードＩＤと一致する参照カードＩＤが存在した場合であっても（Ｓ１３０：Ｙ
ＥＳ）、予約データテーブルにおいて、その参照カードＩＤに対応するシリアル番号が既
に記録済みである場合（つまり、入手カードと予約済カードとが同じカードＩＤに対応付
けられている場合）には（Ｓ１３２：ＹＥＳ）、予約データテーブルにシリアル番号を新
たに記録する必要がないため、処理を終了する。

一方、ゲームサーバ２０のＣＰＵ２１は、入手カードＩＤと一致する参照カードＩＤが
存在した場合であって、予約データテーブルにおいて、その参照カードＩＤに対応するシ
リアル番号が記録されていない場合(Ｓ１３２：ＮＯ）、入手カードのシリアル番号を、
その参照カードＩＤに対応する欄（Ｃ１～Ｃ５のいずれか）に書き込むとともに（Ｓ１３
４）、書き込んだシリアル番号に対応する予約ＩＤを読み出す。さらにＣＰＵ２１は、読
み出した予約ＩＤを、所持カードデータテーブルにおいて入手カードのシリアル番号に対
応付けて書き込む（Ｓ１３６）。

次にゲームサーバ２０は、Ｓ１３４で書き込んだシリアル番号に対応する予約ＩＤに対
応する参照カードがすべて揃ったか否か判定する（Ｓ１３８）。具体的には、ゲームサー
バ２０のＣＰＵ２１は、入手カードに対応する予約ＩＤに対応する進化ＩＤについての参
照カードＩＤの組合せを構成するＣ１～Ｃ５の欄（進化合成データテーブル参照）の参照
カードＩＤに対応した、予約データテーブルにおける参照カードのＣ１～Ｃ５のすべての
欄に、シリアル番号が記録されているか判定することによって、参照カードがすべて揃っ
たか否か判定する。予約ＩＤに対応する参照カードがすべて揃っていない場合には（Ｓ１
３８：ＮＯ）、入手カードによって参照カードの組合せ条件が満たされていないため、処
理を終了する。一方、予約ＩＤに対応する参照カードがすべて揃った場合には（Ｓ１３８
：ＹＥＳ）、予約ＩＤに対応する参照カードがすべて揃ったことをユーザに通知するため
の画像データを生成し（Ｓ１４０）、その画像データをユーザ端末１０へ送信する（Ｓ１
４２）。ユーザ端末１０のＣＰＵ１１は、Ｓ１４２で送信された画像データを取得すると
、当該画像データに基づいて画像（例えば、図１２の画像Ｐ１１）を表示部１６に表示す
る（Ｓ１４４）。

（Ｅ）進化合成処理（図１８）
例えば、上述したカード入手時の判定処理を実行した結果、入手したカードによって進
化合成に必要な参照カードがすべて揃ったことで進化合成の条件を満たすことになった場
合には、進化合成処理が実行される。
図１８に示すシーケンスチャートは、図１７Ａおよび図１７Ｂに示した判定処理に引き
続いて実行される場合の処理の流れを示している。図１７ＢのＳ１４４で表示される画像
は、図１２の画像Ｐ１１に例示したように、進化合成の実行要求を行うか否かを確認する
ためのボタンが設けられている。図１８では、このボタンのユーザによる操作に基づいて
、ユーザ端末１０のＣＰＵ１１が進化合成の実行要求を受け付けた場合（Ｓ１５０）、当
該要求をゲームサーバ２０へ送信する（Ｓ１５２）。

ゲームサーバ２０のＣＰＵ２１がユーザ端末１０から受信した進化合成の実行要求を受
け付けると、ゲームサーバ２０のＣＰＵ２１は、所持カードデータテーブルにおいて、進
化前カード（つまり、進化合成のベースカード）のカードデータを消去し（Ｓ１５４）、
進化後カードのカードデータを新たに書き込む（Ｓ１５６）。Ｓ１５６では、図１７Ｂの
Ｓ１３８の判定対象となった予約ＩＤに対応して予約データテーブルに記録されている進
化ＩＤに基づいて、進化合成データテーブルから進化後カードＩＤを読み出し、この進化
後カードＩＤに対応するカードデータを所持カードデータテーブルに書き込む。このとき
、カードデータには、例えば、進化後カードＩＤに対応して発行したシリアル番号が含ま
れる。
次いでゲームサーバ２０のＣＰＵ２１は、進化合成に使用する参照カードのカードデー
タを所持カードデータテーブルから消去する（Ｓ１５８）。

進化合成を実行した後は予約ＩＤに対応付けられたデータを予約データテーブルに記録
している必要がないため、ゲームサーバ２０のＣＰＵ２１は、予約データテーブルから、
進化合成の対象となる予約ＩＤの行のデータを消去する（Ｓ１６０）。最後にＣＰＵ２１
は、進化後カードのカードデータを含む画像データを生成し（Ｓ１６２）、その画像デー
タをユーザ端末１０へ送信する（Ｓ１６４）。ユーザ端末１０のＣＰＵ１１は、Ｓ１６４
で送信された画像データを取得すると、当該画像データに基づいて画像（例えば、図１２
の画像Ｐ１２）を表示部１６に表示する（Ｓ１６６）。

以上説明したように、本実施形態のゲームシステムでは、オブジェクトを変化させる処
理の一例であるカードの進化合成を実行するためには、進化合成の対象となるベースカー
ドと、それに対応する複数の参照カードをユーザが所持していることが要件となる。従っ
て、例えば、その複数の参照カードのうち一部の参照カードを所持しているに過ぎない場
合には、ベースカードの進化合成を実行することができないため、進化合成を実行するた
めにはユーザは、残りの参照カードを入手して参照カードがすべて揃うまで待機する必要
がある。このとき、本実施形態のゲームサーバ２０は、ユーザによる要求に応じて、ユー
ザが所持し、かつ目的とする進化合成に必要となるベースカードおよび参照カードを進化
合成の実行前に予約しておくことで、予約済カードが目的とする進化合成以外の処理に用
いられることを制限する。そのため、ユーザが所持していない残りの参照カードを入手す
るまで待機期間において、ユーザが所持しているベースカードや参照カードを誤って目的
とする進化合成以外の別の処理に使用してしまうことを防止することができる。

なお、上述した実施形態では、ベースカードに対応する複数の参照カードの一部が予約
済カードである場合、その後にユーザが複数の参照カードのうち予約済みでないカードを
入手したときには、その入手したカードが自動的に予約対象カードとなる場合（言わば、
自動予約の場合）について説明した（図１７ＢのＳ１３６）。すなわち、記録手段５７が
、ベースカードおよび複数の参照カードのうち一部のカードがストレージ２５の予約デー
タテーブルに記録されており、ユーザがベースカードおよび複数の参照カードのいずれか
であって、かつ所持カードに含まれないカードを入手した場合には、当該入手したカード
のシリアル番号（カードデータ）を予約データテーブルに記録する場合について説明した
。具体的には、図１７Ａ，図１７Ｂに示したカード入手時の判定処理において、予約デー
タテーブルに、予約ＩＤに対応する参照カードＩＤのうち入手カードＩＤと同一の「参照
カード」の欄にシリアル番号が記録されていない場合には、ユーザの操作入力によらずに
入手カードのシリアル番号を書き込むようにしている（図１７ＢのＳ１３４）。
言い換えれば、上述した実施形態では、ユーザがカードを入手し、当該ユーザの所持カ
ードデータテーブルに新たなカードＩＤに対応する行のデータが追加される場合であって
、当該追加されたカードが予約データテーブルに予約されることで予約済カード（制限オ
ブジェクトの一例）であると判定された場合、制限手段５８が、当該追加されたカードに
対して、予約ＩＤに対応する進化合成とは異なる処理に用いられることを制限する場合に
ついて説明した。

このような自動予約を行うことは以下の利点がある。すなわち、複数の参照カードのう
ち一部のカードが予約（つまり、予約データテーブルに記録）されている場合には、ユー
ザが目的とするベースカードの進化合成を実行することを予定していると考えることがで
きるため、ユーザが入手したカードがその複数の参照カードのいずれかである場合には、
その入手したカードを自動的に予約することで、ユーザが予約のための操作入力を行わな
くて済むとともに、新たに入手したカードを目的とする進化合成以外の処理に用いられる
ことをより確実に抑制することができる。

しかし、入手カードについて自動予約を行わなくてもよい。その場合には、カード入手
時の処理は、図１７ＡのＳ１２０～Ｓ１２６の処理で終了する。Ｓ１２６の処理の後にＳ
１３８の判定処理に進んでもよいし、進まなくてもよい。Ｓ１３８の判定処理に進まない
場合には、ユーザの所望のタイミングで図１４Ａに示した処理を開始し、その処理の開始
時点ですべての参照カードが揃っていれば、Ｓ３０では、進化合成を実行するか否かにつ
いてのユーザが指示するための画像データが送信される。そして、進化合成を実行するこ
とを選択する操作入力が行われた場合、図１８に示す進化合成処理に進む。

本実施形態では、報知手段５９が、前記ユーザの所持カードデータテーブルに新たなカ
ードＩＤが追加されるタイミングでユーザのユーザ端末１０に対して報知を行う場合を一
例として説明したが、報知を行うタイミングはこの例に限られない。ユーザがゲームを開
始するタイミング（例えば、ログインするタイミング）で報知してもよいし、ゲーム上で
の区切りのよいタイミング（例えば、ゲームが複数のステージから構成されている場合に
各ステージのプレイが終了したタイミング等）で報知してもよい。
なお、ユーザがカードを入手するタイミングでユーザに対して報知が行われることで、
ユーザはカードを入手する度に、ベースカードとして選択されたカードの進化合成を実行
するための条件の一部またはすべてが満たされたか否かについて注目することになる。そ
のため、ユーザが新たなカードを入手するときの期待値を向上させることができる。

本実施形態では、制限手段５８が、予約済カードに対して、対応するベースカードの進
化合成とは異なる処理を実行する要求がなされた場合、図１１の画像Ｐ８に例示したよう
に、ユーザに対する警告を行う場合について説明した。なお、警告に限られず、実行を要
求された処理を中断してもよい。例えば、図１１の画像Ｐ７においていずれかの所持カー
ドが選択されたときに、選択されたカードについての処理を中断してもよい。また、画像
Ｐ７において、予約済カードについては暗転表示して選択できないような態様で表示して
もよい。
これによって、予約済カードが予約ＩＤに対応した進化合成以外の処理に用いられるこ
とを確実に防止し、あるいは、予約ＩＤに対応した進化合成以外の処理に用いられること
についてユーザに対して注意喚起を促すことができる。

（２）第２の実施形態
第１の実施形態では、ユーザ端末１０とゲームサーバ２０との間でＨＴＴＰに従った通
信が行われ、ユーザ端末１０がゲームサーバ２０から取得するＨＴＭＬ文書を解釈するこ
とでゲーム画像を表示する、いわゆるブラウザ形式によって本発明が実現される場合につ
いて説明したが、この場合に限られない。ユーザ端末１０がダウンロードしたゲームプロ
グラムを実行することでユーザ端末１０が主体的にゲームの処理を実行し、ユーザ端末１
０とゲームサーバ２０の間の送受信処理を抑制した、いわゆるネイティブアプリケーショ
ン形式によって実現してもよい。ネイティブアプリケーション形式では、ウェブブラウザ
を利用せずにユーザ端末１０内で画像データを生成して表示する。
第２の実施形態では、第１の実施形態のゲームをネイティブアプリケーション形式によ
って実現する場合の一例について説明する。なお、本実施形態のハードウェア構成は、第
１の実施形態と同じ構成でよい。本実施形態のネイティブアプリケーションの形式では、
処理のほとんどをユーザ端末１０側で行うことを想定しているが、以下で説明しないゲー
ムの処理の一部（例えば、ユーザに抽選によって付与する抽選処理や、ゲーム運営者がユ
ーザにカードを付与するプレゼント処理等）については、ゲームサーバ２０側で処理を実
行し、ゲームサーバ２０による処理結果をユーザ端末１０へ送信するように構成してもよ
い。

本実施形態では、ユーザ端末１０がユーザによる所定の操作に基づいて、ゲーム運営者
のサーバからゲームプログラムを受信し、受信したゲームプログラムがストレージ１８に
格納される。ユーザ端末１０によってゲームが起動されると、ユーザ端末１０とゲームサ
ーバ２０との間で通信が確立されてログイン処理が行われ、ゲームサーバ２０からユーザ
端末１０へデータテーブル群（カードデータテーブル、進化合成データテーブル、所持カ
ードデータテーブル）が送信される。ユーザ端末１０に送信されるデータテーブル群は、
ユーザ端末１０のストレージ１８内に保持される。この場合、ストレージ１８内のデータ
テーブル群は、ログインの度に更新される。予約データテーブルは、ユーザ端末１０で生
成されてストレージ１８に格納され、予約処理を実行する度に更新される。
所持カードデータテーブルがユーザ端末１０において改竄されることを防止するため、
ユーザ端末１０による所定の処理が終了する度、あるいは、ゲームからログアウトする時
点で、ユーザ端末１０内の所持カードデータテーブルがゲームサーバ２０へ送信される。
ゲームサーバ２０では、受信した所持カードデータテーブルと、ストレージ２５内の所持
カードデータテーブルとを比較し、データの改竄が行われていないか確認した後に、スト
レージ２５内の所持カードデータテーブルを受信したものに更新する。

図１９Ａおよび図１９Ｂは、本実施形態の進化合成の予約処理を示すシーケンスチャー
トである。図２０Ａおよび図２０Ｂは、予約済カードの売却処理を示すシーケンスチャー
トである。図１９Ａ、図１９Ｂ、図２０Ａ、図２０Ｂの各図において、図１４Ａ、図１４
Ｂ、図１６Ａ、図１６Ｂと同一の処理については、同一の符合を付してある。
本実施形態の進化合成の予約処理（図１９Ａおよび図１９Ｂ）では、例えばログイン時
に、ゲームサーバ２０はユーザ端末１０へ、ストレージ２５内のデータテーブル群（カー
ドデータテーブル、進化合成データテーブル、所持カードデータテーブル）を送信する（
Ｓ８）。ユーザ端末１０のＣＰＵ１１は、受信したデータテーブル群をストレージ１８に
記憶するとともに、操作入力部１５からの操作入力に基づいて、ＲＡＭ１３および表示部
１６等と協働してＳ１４～Ｓ５０の処理を実行する。ユーザ端末１０のＣＰＵ１１は、予
約データテーブルを逐次更新して予約処理が終了した後に、予約データテーブルをストレ
ージ１８へ格納する。Ｓ５０の処理が終了した後、あるいはログアウトの時点で、ユーザ
端末１０のＣＰＵ１１は、所持カードデータテーブルをゲームサーバ２０へ送信する（Ｓ
５２）。

本実施形態の予約済カードの売却処理（図２０Ａおよび図２０Ｂ）では、上記予約処理
と同様に、ゲームサーバ２０からユーザ端末１０へのデータテーブル群の送信（Ｓ７８）
、および、売却処理の終了後のユーザ端末１０からゲームサーバ２０への所持カードデー
タテーブルの送信（Ｓ１１４）が行われる。ユーザ端末１０のＣＰＵ１１は、操作入力部
１５からの操作入力に基づいて、ＲＡＭ１３および表示部１６等と協働してＳ８０～Ｓ１
１２の処理を実行する。
なお、図示しないが、本実施形態では、所持カードの閲覧処理、カード入手時の判定処
理、および、進化合成処理についても同様にして、ユーザ端末１０が主体的に実行する。
本実施形態では、カードデータテーブル、進化合成データテーブル、所持カードデータ
テーブルがゲームサーバ２０において保持され、予約データテーブルがユーザ端末１０に
おいて保持される場合について説明したが、この場合に限られない。ネイティブアプリケ
ーション形式のゲームでは、各データテーブルの保持分担については適宜設定することが
可能であって、ユーザ端末１０およびゲームサーバ２０の少なくともいずれかに保持され
るようにすればよく、特定の保持態様に限定されるものではない。ゲームサーバ２０にい
ずれかのデータテーブルが保持される場合には、ゲームの実行時にゲームサーバ２０に保
持されるデータテーブルがユーザ端末１０へ送信され、ユーザ端末１０内で行われるゲー
ムの処理に利用される。

（３）変形例
以下、上述した各実施形態に共通の変形例について説明する。
（３－１）変形例１
実施形態では、ベースカードが選択された後、当該ベースカードを進化合成させるため
の複数の参照カードの中から予約済みでない所持カードを、ユーザ端末１０からの進化合
成の予約処理の要求に基づいて一括で予約する場合について説明したが、この場合に限ら
れない。予約済みでない所持カードが複数存在する場合には、カード単位で予約対象のカ
ードをユーザが選択できるようにしてもよい。
例えば、図２１に、図９の画像Ｐ４の変形例に係る画像Ｐ４ａを示す。図２１に示す画
像Ｐ４ａでは、ベースカードとして選択されたカードＫＬＭに対して、進化合成に必要な
参照カードとその状態について、図９の画像Ｐ４とは異なる状態の場合を例として示して
いる。図２１に示す画像Ｐ４ａでは、複数の参照カードのうち予約済みでない２枚の所持
カードの各々に対して、「予約する」と表記されたボタンｂ３０，ｂ３１が表示される。
各ボタンを操作することで、カード単位で予約対象カードをユーザが選択できるように構
成されている。
本変形例では、例えば図１４Ｂにおいて、進化合成の予約処理の要求を行うための操作
としてボタンｂ３０，ｂ３１のいずれかのボタンに対する操作が行われると、進化合成の
予約処理の要求を受け付け（Ｓ３４）、当該要求をゲームサーバ２０へ送信する（Ｓ３６
）。各ボタンにはカードのシリアル番号が対応付けられており、進化合成の予約処理の要
求には、操作されたボタンに対応するシリアル番号が含まれる。Ｓ３８以降の処理は図１
４Ｂに示したものと同様にして実行することができる。

（３－２）変形例２
第１の実施形態の進化合成の予約処理では、図９および図１４Ａ，図１４Ｂに関連付け
て、ユーザが、ベースカードと複数の参照カードの一部とを所持している場合に、ベース
カードと所持している参照カードとを予約する場合について説明したが、ベースカードの
みを予約できるようにしてもよい。つまり、ユーザがベースカードのみを所持し、そのベ
ースカードを進化合成させるための参照カードを１枚も所持していない場合であっても、
ベースカードのみを進化合成のために予約できるようにしてもよい。
例えば、図２２に、図９の画像Ｐ４の変形例に係る画像Ｐ４ｂを示す。図２２に示す画
像Ｐ４ｂでは、ベースカードとして選択されたカードＫＬＭに対して、進化合成に必要な
参照カードとその状態について、図９の画像Ｐ４とは異なる状態の場合を例として示して
いる。図２２に示す画像Ｐ４ｂでは、複数の参照カードのいずれもユーザが所持していな
い。このような場合でも、ベースカードとして選択されたカードＫＬＭに対応付けてボタ
ンｂ３２（「予約する」）が設けられる。ボタンｂ３２を操作することでユーザは、ベー
スカードのみを予約対象カードとして選択できるように構成されている。
本変形例では、例えば図１４Ｂにおいて、進化合成の予約処理の要求を行うための操作
としてボタンｂ３２に対する操作が行われると、進化合成の予約処理の要求を受け付け（
Ｓ３４）、当該要求をゲームサーバ２０へ送信する（Ｓ３６）。ボタンｂ３２にはカード
のシリアル番号が対応付けられており、進化合成の予約処理の要求には、操作されたボタ
ンに対応するシリアル番号が含まれる。Ｓ３８以降の処理は図１４Ｂに示したものと同様
にして実行することができる。

（３－３）変形例３
上述した各実施形態において、予約データテーブルの予約ＩＤに対応する進化合成に対
応する参照カードがユーザの所持カードとしてすべて揃った場合には、ユーザの操作入力
を待たずに自動的に進化合成を実行してもよい。その場合、報知手段５９は、ユーザがカ
ードを入手したことによって複数の参照カードがユーザの所持カードに含まれることで進
化合成の条件を満たした場合には、進化合成が実行されたことをユーザに報知する。
例えば、図１７Ｂおよび図１８に示したフローにおいて、予約ＩＤに対応する参照カー
ドがすべて揃った場合には（Ｓ１３８：ＹＥＳ）、Ｓ１４０～Ｓ１５２の各処理を省略し
、Ｓ１５４の処理に移行してもよい。ユーザの操作入力を待たずに自動的に進化合成を実
行する場合、進化合成が実行されたことは、Ｓ１６６で画像表示が行われることによって
ユーザに報知される。この変形例では、ユーザは、進化合成を実行するための操作が必要
なくなるため操作性が向上するという利点がある。

（３－４）変形例４
上述した各実施形態では、出力手段５６が、複数の参照データを対象として進化合成の
予約処理の要求するための指示部としてのボタンｂ８（図９の画像Ｐ４参照）を表示させ
るための画像データを出力し、受付手段５１が、ユーザによる操作によりボタンｂ８を介
してなされた要求を受け付ける場合について説明した。ユーザ端末１０に表示される画像
内にユーザによる操作対象としての指示部を設けることで、ユーザは、複数の参照カード
がそれぞれ識別可能な表示形式で表示されている状態で、当該複数の参照カードを対象と
して進化合成の予約処理の要求を行うことができるため、予約対象カードである複数の参
照カードの確認および進化合成の予約処理の要求を、他の画像に遷移させることなく同時
に実行することができる。
なお、要求の受付方法については上述した場合に限られない。例えば、要求の受付方法
は、加速度センサを備えたユーザ端末を振ることによる指示入力、あるいはジェスチャに
よる指示入力（ジェスチャ入力）によって受け付ける方法であってもよい。ジェスチャ入
力では、撮像機能を備えたユーザ端末に対する所定のジェスチャを行うことでユーザ端末
がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。
また、音声認識プログラムを実行可能なユーザ端末の場合には、要求の受付方法は、所定
の音声による指示入力によって受け付ける方法であってもよい。

（３－５）変形例５
上述した実施形態では、例えば図１４ＡのＳ２２，Ｓ２４に示したように、ユーザ操作
によってベースカードが選択され、その選択結果がゲームサーバ２０へ送信される場合に
ついて説明したが、この場合に限られない。ベースカードが自動的に選択される場合であ
ってもよい。例えば、ユーザは、現在は所持していないが将来的に進化させたいカードを
登録しておく。そして、ユーザが登録しておいたカード（登録カード）を入手したタイミ
ングで、登録カードをベースカードとしたＳ２６以降の処理をゲームサーバ２０が実行す
る。このとき、登録カードを入手したタイミングで予約処理を実行するか否かについての
問い合わせをユーザ端末１０に対して行い、予約処理を実行することが選択された場合に
限り、Ｓ２６以降の処理を実行してもよい。
本変形例では、ユーザの操作に基づいてユーザ端末１０は、任意のタイミングでユーザ
が進化合成のベースカードとしたいカードをストレージ２５内の登録データテーブル（図
示せず）に記録することを要求する。当該要求に応じて、ゲームサーバ２０のＣＰＵ２１
は、登録データテーブルにユーザに対応付けて記録する。そして、ゲームサーバ２０のＣ
ＰＵ２１は、ユーザにカードを付与することを決定すると、ユーザに対して付与対象のカ
ードのカードデータを通知するとともに、付与対象のカードが登録データテーブルに記録
されているいずれかのカードと一致するか否か判定する。一致する場合には、図１４Ａの
Ｓ２６以降の処理を実行する。

（４）ゲーム以外のアプリケーションへの適用について
上述した実施形態および変形例では、本発明がゲームに適用される場合について説明し
たが、他のアプリケーションに適用してもよい。例えばインターネット上のショッピング
モールで商品を購入する度に複数種類の電子クーポン券を配布している場合、その電子ク
ーポン券を本発明のオブジェクトの一例としてもよい。この場合、例えばベースオブジェ
クトとしてのクーポン券Ｑの特典内容をアップグレード（変更処理の一例）するために、
クーポン券Ｑに対応する参照オブジェクトとしてのクーポン券Ａ～Ｃをユーザが所持し利
用することが考えられる。この例において、クーポン券Ｑをアップグレードすること目的
として、そのために必要なクーポン券Ａ～Ｃのいずれかのシリアル番号を予約データテー
ブルに書き込む。そして、予約データテーブルに記録されているクーポン券は、クーポン
券Ｑをアップグレードする処理以外の処理に用いられることが制限される。
上述した例示以外の他のアプリケーションについても適宜適用可能である。

［発明のまとめ］
以上の記載から本発明は例えば以下のように把握される。

本発明の一態様は、オブジェクトを変化させる処理を行う条件が定義された変化条件で
あって、少なくとも複数のオブジェクトを示す情報を含む変化条件と、ユーザが所持する
オブジェクトを示す情報を含む所持情報とが記憶された記憶装置（２５）にアクセス可能
な情報処理装置において、
選択された選択オブジェクトに対応する前記変化条件を、前記記憶装置（２５）から取
得する取得手段（５５）と、
前記取得手段（５５）により取得された前記変化条件に含まれる複数のオブジェクトを
示す情報を用いて、当該複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表
示させるための出力データを出力する出力手段（５６）と、
前記出力手段（５６）により前記出力データが出力されたことに応じて、前記ユーザに
よる操作を介してなされた要求であって、前記複数のオブジェクトのうち少なくともいず
れかのオブジェクトに対して処理を制限させるための要求を受け付ける受付手段（５１）
と、
前記受付手段（５１）により前記要求を受け付けたことに応じて、前記取得手段（５５
）により取得された前記変化条件と、前記要求元のユーザが所持するオブジェクトを示す
情報が含まれる前記所持情報とに基づいて、当該ユーザが所持するオブジェクトのうち、
前記選択された選択オブジェクトを変化させる処理とは異なる処理に用いられることを制
限すべき制限オブジェクトとして特定されたオブジェクトに対して、前記選択された選択
オブジェクトを変化させる処理とは異なる処理に用いられることを制限する制限手段（５
８）と、
を有することを特徴とする情報処理装置である。

「情報処理装置」は、スタンドアローンのゲーム機、あるいはユーザ端末（例えば、携
帯端末やパーソナルコンピュータ等）やネットワーク上のサーバなどであってもよい。ゲ
ームの実現形態によって適宜情報処理装置の実体を定義することができる。例えば、ユー
ザがゲーム機やユーザ端末を操作することで情報処理装置の各部の機能が実現される場合
には、ゲーム機やユーザ端末が本発明の情報処理装置に相当する。あるいは、クライアン
トであるユーザ端末がユーザからの操作入力の受付や画像の表示の機能を有し、情報処理
装置の各部の機能が実質的にユーザ端末と通信可能なサーバによって実現される場合には
、サーバが本発明の情報処理装置に相当する。
「オブジェクト」は、ユーザが視覚的に認識可能である限り如何なる表示対象であって
もよく、本発明の情報処理装置による処理内容に応じて適宜設定することができる。例え
ば、本発明の情報処理装置がゲームに関する情報を処理する場合、オブジェクトは、ゲー
ム上のキャラクタやアイテム等を含んでもよい。キャラクタは、例えばゲーム上の仮想的
な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも
含む。
「ユーザが所持するオブジェクト」とは、情報処理上でユーザが所持するオブジェクト
として管理されているオブジェクトであって、ユーザに対応付けて記憶あるいは管理され
ているオブジェクトを意味する。
「記憶装置」は、例えばフラッシュメモリやＨＤＤ(Hard Disk Drive)等、如何なる構
成のメモリデバイスであってもよい。また、記憶装置は、情報処理装置に内蔵された装置
であってもよいし、情報処理装置から有線または無線でアクセス可能に構成された外部の
装置であってもよい。
「選択オブジェクトを変化させる処理とは異なる処理に用いられることを制限する」と
は、選択オブジェクトを変化させる処理以外の処理自体が禁止されることに限られず、選
択オブジェクトを変化させる処理は実行可能であるが、その処理の実行の手続きをし難く
する、あるいは処理の実行手続きを煩雑にすることであってもよい。

上記情報処理装置において、選択オブジェクトを変化させる処理の実行は、少なくとも
複数のオブジェクトを示す情報を含む変化条件と、ユーザの所持情報とに基づいて行われ
る。そのため、例えば変化条件を満たさない場合には、選択オブジェクトを変化させる処
理の実行を実行することができない。このとき、上記情報処理装置では、ユーザからの要
求に応じて、選択オブジェクトや、変化条件の基礎となる複数のオブジェクトのいずれか
を、選択オブジェクトを変化させる処理以外の処理に用いられることを制限する。そのた
め、変化条件を満たす前に、ユーザが誤って、選択オブジェクトや、変化条件の基礎とな
る複数のオブジェクトのいずれかを、その選択オブジェクトを変化させる処理以外の処理
に使用してしまうことを防止することができる。

前記制限手段（５８）は、前記要求元のユーザが所持するオブジェクトを示す情報が含
まれる前記所持情報に、オブジェクトを示す情報が追加される場合であって、当該追加さ
れるオブジェクトが前記制限すべき制限オブジェクトであると判定された場合、当該追加
されたオブジェクトに対して、前記選択された選択オブジェクトを変化させる処理とは異
なる処理に用いられることを制限してもよい。
「所持情報にオブジェクトを示す情報が追加される場合」とは、例えばユーザがオブジ
ェクトを入手した場合である。このとき、ユーザが入手したオブジェクトが制限オブジェ
クトであると判定された場合には、そのオブジェクトは、当該ユーザによる指示を受け付
けることなく自動的に、選択オブジェクトを変化させる処理以外の処理に用いられること
が制限される。そのため、ユーザは指示のための操作入力を行わなくて済むとともに、新
たに入手したオブジェクトを、選択オブジェクトを変化させる処理以外の処理に用いられ
ることをより確実に抑制することができる。

前記出力手段（５６）は、前記複数のオブジェクトに対して処理を制限させることを要
求可能な指示部（ｂ８）を表示させるための出力データを出力し、前記受付手段（５１）
は、前記ユーザによる操作により前記指示部（ｂ８）を介してなされた要求を受け付けて
もよい。
出力データを基に表示される画像内に指示部（ｂ８）を設けることでユーザは、変化条
件に含まれる複数のオブジェクトがそれぞれ識別可能な表示形式で表示されている状態で
、当該複数のオブジェクトに対して処理を制限させるための要求を行うことができるため
、当該複数のオブジェクトの確認および上記要求を他の画像に遷移させることなく同時に
実行することができる。

上記情報処理装置は、所定のタイミングで、前記要求元のユーザが所持するオブジェク
トを示す情報が含まれる前記所持情報と、前記取得手段（５５）により取得された前記変
化条件とに基づき、当該ユーザが当該変化条件に含まれる複数のオブジェクトを所持して
いると判定された場合、当該変化条件に含まれる複数のオブジェクトを所持していること
を当該ユーザが識別可能な形式で報知する報知手段（５９）、を有してもよい。
報知手段（５９）を備えることでユーザは、変化条件に含まれる複数のオブジェクトを
所持していると判定された場合には、当該判定結果が認識可能な形式で認識することがで
きる。そのため、ユーザは、選択オブジェクトを変化させる処理を実行するための変化条
件のうち少なくとも一部が満たされたことを直ちに認識することが可能となる。

前記報知手段（５９）は、所定のタイミングで、前記要求元のユーザが所持するオブジ
ェクトを示す情報が含まれる前記所持情報と、前記取得手段（５５）により取得された前
記変化条件とに基づき、当該ユーザが当該変化条件に含まれる複数のオブジェクトを所持
していると判定されたことにより、前記選択された選択オブジェクトを変化させる処理を
行う条件が成立したと判定された場合、当該選択された選択オブジェクトを変化させる処
理を行う条件が成立したことを当該ユーザが識別可能な形式で報知してもよい。
それによって、ユーザは、選択オブジェクトを変化させる処理を実行するための変化条
件が満たされ、選択オブジェクトを変化させる処理が実行可能となったことを直ちに認識
することが可能となる。

前記報知手段（５９）は、前記要求元のユーザが所持するオブジェクトを示す情報が含
まれる前記所持情報に、オブジェクトを示す情報が追加されることに応じて報知してもよ
い。
ユーザがオブジェクトを入手するタイミングでユーザに対して報知が行われることで、
ユーザはオブジェクトを入手する度に、選択オブジェクトを変化させる処理を実行するた
めの変化条件の一部またはすべてが満たされたか否かについて注目することになる。その
ため、ユーザが新たなオブジェクトを入手するときの期待値を向上させることができる。

前記制限手段（５８）は、前記制限すべき制限オブジェクトに対して、前記選択された
選択オブジェクトを変化させる処理とは異なる処理を実行する要求がなされた場合、当該
処理の中断、またはユーザに対する警告の少なくともいずれかの処理を行ってもよい。
これによって、制限オブジェクトが選択オブジェクトを変化させる処理以外の処理に用
いられることを確実に防止し、あるいは、選択オブジェクトを変化させる処理以外の処理
に用いられることについてユーザに対して注意喚起を促すことができる。

上記情報処理装置は、前記ユーザが所持するオブジェクトのうち、前記制限手段（５８
）により前記制限すべき制限オブジェクトとして特定されたオブジェクトと、他のオブジ
ェクトとを、当該ユーザが識別可能な表示形式で表示させるための制御を行う表示手段（
６０）、を有してもよい。
このような表示手段（６０）を設けたことで、表示画像を見たユーザは、制限オブジェ
クトとして特定されたオブジェクトを他のオブジェクトと識別可能に認識することができ
る。また、ユーザが所持するオブジェクトの中からいずれかのオブジェクトを指定して何
らかの処理を実行する場合に、制限オブジェクトと他のオブジェクトを識別可能に認識で
きるため、選択オブジェクトを変化させる処理以外の処理に制限オブジェクトを使用する
ことがさらに効果的に防止できる。

本発明の別の態様は、ユーザ端末（１０）と、当該ユーザ端末（１０）と通信可能に構
成されるサーバ（２０）と、を含むゲームシステム（１）であって、
オブジェクトを変化させる処理を行う条件が定義された変化条件であって、少なくとも
複数のオブジェクトを示す情報を含む変化条件と、ユーザが所持するオブジェクトを示す
情報を含む所持情報とが記憶された記憶装置（２５）から、選択された選択オブジェクト
に対応する前記変化条件を取得する取得手段（５５）と、
前記取得手段（５５）により取得された前記変化条件に含まれる複数のオブジェクトを
示す情報を用いて、当該複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表
示させるための出力データを出力する出力手段（５６）と、
前記出力手段（５６）により前記出力データが出力されたことに応じて、前記ユーザに
よる操作を介してなされた要求であって、前記複数のオブジェクトのうち少なくともいず
れかのオブジェクトに対して処理を制限させるための要求を受け付ける受付手段（５１）
と、
前記受付手段（５１）により前記要求を受け付けたことに応じて、前記取得手段（５５
）により取得された前記変化条件と、前記要求元のユーザが所持するオブジェクトを示す
情報が含まれる前記所持情報とに基づいて、当該ユーザが所持するオブジェクトのうち、
前記選択された選択オブジェクトを変化させる処理とは異なる処理に用いられることを制
限すべき制限オブジェクトとして特定されたオブジェクトに対して、前記選択された選択
オブジェクトを変化させる処理とは異なる処理に用いられることを制限する制限手段（５
８）と、
を有することを特徴とする情報処理システムである。

本発明の別の態様は、オブジェクトを変化させる処理を行う条件が定義された変化条件
であって、少なくとも複数のオブジェクトを示す情報を含む変化条件と、ユーザが所持す
るオブジェクトを示す情報を含む所持情報とが記憶された記憶装置（２５）、にアクセス
可能なコンピュータに、
選択された選択オブジェクトに対応する前記変化条件を、前記記憶装置（２５）から取
得する取得手段（５５）、
前記取得手段（５５）により取得された前記変化条件に含まれる複数のオブジェクトを
示す情報を用いて、当該複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表
示させるための出力データを出力する出力手段（５６）、
前記出力手段（５６）により前記出力データが出力されたことに応じて、前記ユーザに
よる操作を介してなされた要求であって、前記複数のオブジェクトのうち少なくともいず
れかのオブジェクトに対して処理を制限させるための要求を受け付ける受付手段（５１）
、および、
前記受付手段（５１）により前記要求を受け付けたことに応じて、前記取得手段（５５
）により取得された前記変化条件と、前記要求元のユーザが所持するオブジェクトを示す
情報が含まれる前記所持情報とに基づいて、当該ユーザが所持するオブジェクトのうち、
前記選択された選択オブジェクトを変化させる処理とは異なる処理に用いられることを制
限すべき制限オブジェクトとして特定されたオブジェクトに対して、前記選択された選択
オブジェクトを変化させる処理とは異なる処理に用いられることを制限する制限手段（５
８）、
として機能させるためのプログラムである。

本発明の別の態様は、上記プログラムを格納する、光ディスク、磁気ディスク等の、コ
ンピュータが読み取り可能な記憶媒体であってもよい。

本発明の別の態様は、ベースオブジェクトに対応する複数の参照オブジェクトがユーザ
の所持オブジェクトに含まれる場合に、前記ベースオブジェクトのオブジェクト情報を変
更する変更処理を含むゲーム、に用いられる情報処理装置であって、
前記ユーザの操作入力に基づいて、前記所持オブジェクトの中からいずれかのオブジェ
クトのオブジェクト情報を取得する取得手段（５５）と、
前記取得手段（５５）によって取得されたオブジェクト情報に対応するオブジェクトが
前記ベースオブジェクトおよび前記複数の参照オブジェクトのいずれかである場合に、前
記取得手段（５５）によって取得されたオブジェクト情報を記憶装置（２５）に記録する
記録手段（５７）と、
前記記憶装置（２５）に記録されているオブジェクト情報に対応するオブジェクトが前
記変更処理以外の処理に用いられることを制限する制限手段（５８）と、
を備えた情報処理装置である。

この情報処理装置において「変更処理以外の処理に用いられることを制限する」とは、
変更処理以外の処理自体が禁止されることに限られず、変更処理以外の処理は実行可能で
あるが、その処理の実行の手続きをし難くする、あるいは処理の実行手続きを煩雑にする
ことであってもよい。

上記情報処理装置において、ベースオブジェクトのオブジェクト情報を変更する変更処
理を実行するためには、ベースオブジェクトと、当該ベースカードに対応した組合せ条件
を満たすための複数の参照オブジェクトとをユーザが所持していることが要件となる。従
って、上記複数の参照オブジェクトのうち一部の参照オブジェクトを所持しているに過ぎ
ない場合には、ベースオブジェクトの変更処理を実行することができないため、変更処理
を実行するためにはユーザは、残りの参照オブジェクトを入手するまで待機する必要があ
る。このとき、上記情報処理装置では、ユーザが所持し、かつ変更処理に必要となるベー
スオブジェクトおよび参照オブジェクトを目的とする変更処理の実行前に記録しておくこ
とで、ベースオブジェクトおよび参照オブジェクトが目的とする変更処理以外の処理に用
いられることを制限する。そのため、ユーザの所持していない残りの参照オブジェクトを
入手するまで待機期間において、ユーザが所持しているオブジェクトを誤って目的とする
変更処理以外の別の処理に使用してしまうことを防止することができる。

前記ベースオブジェクトおよび前記複数の参照オブジェクトのうち一部のオブジェクト
が前記記憶装置（２５）に記録されており、前記ユーザが前記ベースオブジェクトおよび
前記複数の参照オブジェクトのいずれかであって、かつ前記所持オブジェクトに含まれな
いオブジェクトを入手した場合には、前記記録手段（５７）は、当該入手したオブジェク
トのオブジェクト情報を前記記憶装置（２５）に記録してもよい。
複数の参照オブジェクトのうち一部のオブジェクトが記憶装置（２５）に記録されてい
る場合には、ユーザがベースオブジェクトの変更処理を実行することを予定していると考
えることができるため、ユーザが入手したオブジェクトがその複数の参照オブジェクトの
いずれかである場合には、その入手したオブジェクトを自動的に記憶装置（２５）に記録
することで、ユーザが記録のための操作入力を行わなくて済むとともに、新たに入手した
オブジェクトを目的とする変更処理以外の処理に用いられることをより確実に抑制するこ
とができる。

上記情報処理装置は、前記ユーザがオブジェクトを入手したことによって前記複数の参
照オブジェクトが前記ユーザの所持オブジェクトに含まれることになった場合には、前記
変更処理が実行可能になったこと、または、前記変更処理が実行されたこと前記ユーザに
報知する報知手段（５９）、を備えてもよい。
報知手段（５９）を備えることで、例えば、変更処理に必要となる複数の参照オブジェ
クトのうち一部の参照オブジェクトを変更処理の実行前に記録し、残りの参照オブジェク
トを取得するまで変更処理を待機しているユーザに、オブジェクトの取得によって変更処
理が実行可能になったことが報知されるため、ユーザは直ちに目的とする変更処理を実行
することが可能となる。
また、オブジェクトの取得によって変更処理が自動的に実行され、変更処理が実行され
たことがユーザに通知されてもよい。その場合には、ユーザは、変更処理を実行するため
の操作が必要なくなるため操作性が向上する。

本発明の別の態様は、ユーザ端末（１０）と、当該ユーザ端末と通信可能に構成される
サーバ（２０）と、を含み、
ベースオブジェクトに対応する複数の参照オブジェクトがユーザの所持オブジェクトに
含まれる場合に、前記ベースオブジェクトのオブジェクト情報を変更する変更処理を含む
ゲーム、に用いられるゲームシステム（１）であって、
前記ユーザの操作入力に基づいて、前記所持オブジェクトの中からいずれかのオブジェ
クトのオブジェクト情報を取得する取得手段（５５）と、
前記取得手段（５５）によって取得されたオブジェクト情報に対応するオブジェクトが
前記ベースオブジェクトおよび前記複数の参照オブジェクトのいずれかである場合に、前
記取得手段（５５）によって取得されたオブジェクト情報を記憶装置（２５）に記録する
記録手段（５７）と、
前記記憶装置（２５）に記録されているオブジェクト情報に対応するオブジェクトが前
記変更処理以外の処理に用いられることを制限する制限手段（５８）と、
を備えた、情報処理システムである。

本発明の別の態様は、ベースオブジェクトに対応する複数の参照オブジェクトがユーザ
の所持オブジェクトに含まれる場合に、前記ベースオブジェクトのオブジェクト情報を変
更する変更処理を含むゲーム、のためのプログラムであって、
コンピュータを、
前記ユーザの操作入力に基づいて、前記所持オブジェクトの中からいずれかのオブジェ
クトのオブジェクト情報を取得する取得手段（５５）、
前記取得手段（５５）によって取得されたオブジェクト情報に対応するオブジェクトが
前記ベースオブジェクトおよび前記複数の参照オブジェクトのいずれかである場合に、前
記取得手段（５５）によって取得されたオブジェクト情報を記憶装置（２５）に記録する
記録手段（５７）、および、
前記記憶装置（２５）に記録されているオブジェクト情報に対応するオブジェクトが前
記変更処理以外の処理に用いられることを制限する制限手段（５８）、
として機能させるためのプログラムである。

本発明の別の態様は、上記プログラムを格納する、光ディスク、磁気ディスク等の、コ
ンピュータが読み取り可能な記憶媒体であってもよい。

なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書
きで記載しているが、これにより本発明に係る情報処理装置等が図示の態様に限定される
ものではない。

１…ゲームシステム
１０…ユーザ端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１５…操作入力部
１６…表示部
１７…通信インタフェース部
１８…ストレージ
１９…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…通信インタフェース部
２５…ストレージ
２６…バス
５１…受付手段
５２…ゲーム処理手段
５３…判定手段
５４…カードデータ変更手段
５５…取得手段
５６…出力手段
５７…記録手段
５８…制限手段
５９…報知手段
６０…表示手段
７０…データテーブル群

Claims (8)

1. 合成元となるベースオブジェクトに関連付けて設定され、かつ当該ベースオブジェクト
   との合成に要する参照オブジェクトを、前記ベースオブジェクトと合成して、前記ベース
   オブジェクトを変化させるゲームを実行する情報処理装置であって、
   ベースオブジェクトに関連付けられた参照オブジェクトの情報を記憶し、かつ、ユーザ
   が所有する複数のオブジェクトが設定された所持情報を記憶する記憶部と、
   前記ユーザが所有する複数のオブジェクトの中からベースオブジェクトを指定する操作
   が、前記ユーザによって行われた際に、
   前記記憶部が記憶する情報に基づいて、前記ユーザが所有する前記複数オブジェクトの
   中から、指定されたベースオブジェクトに関連付けられた参照オブジェクトを抽出し、
   指定された前記ベースオブジェクトが、前記ユーザの所有しないオブジェクトにならな
   いように予約登録を行うと共に、前記ベースオブジェクトに関連付けられた参照オブジェ
   クトも予約登録を行なう登録処理部と、
   前記ユーザが所有する前記複数オブジェクトの中から予約登録された前記参照オブジェ
   クトを売却対象として指定する操作が、前記ユーザによって行われた際に、
   予約登録された前記参照オブジェクトを、売却によって前記ユーザの所有しないオブジ
   ェクトにすることなく、前記ユーザが所有するオブジェクトとしてそのまま維持する制限
   部と、
   を備えたことを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記制限部は、
   オブジェクトの売却を許可する操作が前記ユーザによって行われたことを条件として、
   予約登録された前記参照オブジェクトを前記ユーザの所有しないオブジェクトにし、かつ
   、
   オブジェクトの売却を許可しない操作が前記ユーザによって行われたことを条件として
   、予約登録された前記参照オブジェクトを前記ユーザの所有するオブジェクトとしてその
   まま維持する、
   ことを特徴とする情報処理装置。
3. 合成元となるベースオブジェクトに関連付けて設定され、かつ当該ベースオブジェクト
   との合成に要する参照オブジェクトを、前記ベースオブジェクトと合成して、前記ベース
   オブジェクトを変化させるゲームを実行する情報処理装置であって、
   ベースオブジェクトに関連付けられた参照オブジェクトの情報を記憶し、かつ、ユーザ
   が所有する複数のオブジェクトが設定された所持情報を記憶する記憶部と、
   前記ユーザが所有する複数のオブジェクトの中からベースオブジェクトを指定する操作
   が、前記ユーザによって行われた際に、
   前記記憶部が記憶する情報に基づいて、前記ユーザが所有する前記複数オブジェクトの
   中から、指定されたベースオブジェクトに関連付けられた参照オブジェクトを抽出し、
   指定された前記ベースオブジェクトが、前記ユーザの所有しないオブジェクトにならな
   いように予約登録を行うと共に、前記ベースオブジェクトに関連付けられた参照オブジェ
   クトも予約登録を行なう登録処理部と、
   前記ユーザが所有する前記複数オブジェクトの中から予約登録された前記参照オブジェ
   クトを合成対象として指定する操作が、前記ユーザによって行われた際に、
   予約登録された前記参照オブジェクトを、合成によって前記ユーザの所有しないオブジ
   ェクトにすることなく、前記ユーザが所有するオブジェクトとしてそのまま維持する制限
   部と、
   を備えたことを特徴とする情報処理装置。
4. 請求項３に記載の情報処理装置であって、
   前記制限部は、
   オブジェクトの合成を許可する操作が前記ユーザによって行われたことを条件として、
   予約登録された前記参照オブジェクトを前記ユーザの所有しないオブジェクトにし、かつ
   、
   オブジェクトの合成を許可しない操作が前記ユーザによって行われたことを条件として
   、予約登録された前記参照オブジェクトを前記ユーザの所有するオブジェクトとしてその
   まま維持する、
   ことを特徴とする情報処理装置。
5. 請求項１～４のいずれかに記載の情報処理装置であって、
   複数オブジェクトの中から選択されたオブジェクトをユーザに付与する付与処理部と、
   を備え、
   前記登録処理部は、
   付与された前記オブジェクトが、予約登録された前記ベースオブジェクトに関連付けら
   れた複数の参照オブジェクトのうち、予約登録されていない前記参照オブジェクトである
   か否かを判定し、
   かかる判定が肯定された場合に、付与された当該オブジェクトの予約登録を行なう、
   ことを特徴とする情報処理装置。
6. 合成元となるベースオブジェクトに関連付けて設定され、かつ当該ベースオブジェクト
   との合成に要する参照オブジェクトを、前記ベースオブジェクトと合成して、前記ベース
   オブジェクトを変化させるゲームを実行する情報処理装置であって、
   ベースオブジェクトに関連付けられた参照オブジェクトの情報を記憶し、かつ、ユーザ
   が所有する複数のオブジェクトが設定された所持情報を記憶する記憶部と、
   前記ユーザが所有する複数のオブジェクトの中からベースオブジェクトを指定する操作
   が、前記ユーザによって行われた際に、
   前記記憶部が記憶する情報に基づいて、前記ユーザが所有する前記複数オブジェクトの
   中から、指定されたベースオブジェクトに関連付けられた参照オブジェクトを抽出し、
   指定された前記ベースオブジェクト、または前記ベースオブジェクトに関連付けられた
   参照オブジェクトを、前記ユーザが所有しないオブジェクトにならないように予約登録を
   行なう登録処理部と、
   前記ユーザが所有する前記複数オブジェクトの中から予約登録された前記ベースオブジ
   ェクトまたは前記参照オブジェクトを売却対象として指定する操作が、前記ユーザによっ
   て行われた際に、
   予約登録された前記参照オブジェクトを、売却によって前記ユーザの所有しないオブジ
   ェクトにすることなく、前記ユーザが所有するオブジェクトとしてそのまま維持する制限
   部と、
   を備えたことを特徴とする情報処理装置。
7. 合成元となるベースオブジェクトに関連付けて設定され、かつ当該ベースオブジェクト
   との合成に要する参照オブジェクトを、前記ベースオブジェクトと合成して、前記ベース
   オブジェクトを変化させるゲームに関するプログラムであって、
   コンピュータに、
   ベースオブジェクトに関連付けられた参照オブジェクトの情報を記憶し、かつ、ユーザ
   が所有する複数のオブジェクトが設定された所持情報を記憶する処理と、
   前記ユーザが所有する複数のオブジェクトの中からベースオブジェクトを指定する操作
   が、前記ユーザによって行われた際に、
   前記記憶部が記憶する情報に基づいて、前記ユーザが所有する前記複数オブジェクトの
   中から、指定されたベースオブジェクトに関連付けられた参照オブジェクトを抽出し、
   指定された前記ベースオブジェクトが、前記ユーザの所有しないオブジェクトにならな
   いように予約登録を行うと共に、前記ベースオブジェクトに関連付けられた参照オブジェ
   クトも予約登録を行なう登録処理と、
   前記ユーザが所有する前記複数オブジェクトの中から予約登録された前記参照オブジェ
   クトを売却対象として指定する操作が、前記ユーザによって行われた際に、
   予約登録された前記参照オブジェクトを、売却によって前記ユーザの所有しないオブジ
   ェクトにすることなく、前記ユーザが所有するオブジェクトとしてそのまま維持する売却
   処理と、
   を実行させることを特徴とするゲームプログラム。
8. 合成元となるベースオブジェクトに関連付けて設定され、かつ当該ベースオブジェクト
   との合成に要する参照オブジェクトを、前記ベースオブジェクトと合成して、前記ベース
   オブジェクトを変化させるゲームに関するプログラムであって、
   コンピュータに、
   ベースオブジェクトに関連付けられた参照オブジェクトの情報を記憶し、かつ、ユーザ
   が所有する複数のオブジェクトが設定された所持情報を記憶する処理と、
   前記ユーザが所有する複数のオブジェクトの中からベースオブジェクトを指定する操作
   が、前記ユーザによって行われた際に、
   前記記憶部が記憶する情報に基づいて、前記ユーザが所有する前記複数オブジェクトの
   中から、指定されたベースオブジェクトに関連付けられた参照オブジェクトを抽出し、
   指定された前記ベースオブジェクトが、前記ユーザの所有しないオブジェクトにならな
   いように予約登録を行うと共に、前記ベースオブジェクトに関連付けられた参照オブジェ
   クトも予約登録を行なう登録処理と、
   前記ユーザが所有する前記複数オブジェクトの中から予約登録された前記参照オブジェ
   クトを合成対象として指定する操作が、前記ユーザによって行われた際に、
   予約登録された前記参照オブジェクトを、合成によって前記ユーザの所有しないオブジ
   ェクトにすることなく、前記ユーザが所有するオブジェクトとしてそのまま維持する売却
   処理と、
   を実行させることを特徴とするゲームプログラム。

Images