特許 6123048 ゲーム装置及びプログラム

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

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

(11)【特許番号】6123048

(24)【登録日】2017年4月14日

(45)【発行日】2017年5月10日

(54)【発明の名称】ゲーム装置及びプログラム

(51)【国際特許分類】

   A63F 13/69 20140101AFI20170424BHJP

   G06Q 50/10 20120101ALI20170424BHJP

【ＦＩ】

   A63F13/69 510

   G06Q50/10

【請求項の数】7

【全頁数】19

(21)【出願番号】特願2013-11715(P2013-11715)

(22)【出願日】2013年1月25日

(65)【公開番号】特開2013-172955(P2013-172955A)

(43)【公開日】2013年9月5日

【審査請求日】2013年12月18日

【審判番号】不服2016-8392(P2016-8392/J1)

【審判請求日】2016年6月7日

(31)【優先権主張番号】特願2012-14680(P2012-14680)

(32)【優先日】2012年1月26日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】506113602

【氏名又は名称】株式会社コナミデジタルエンタテインメント

(74)【代理人】

【識別番号】110000165

【氏名又は名称】グローバル・アイピー東京特許業務法人

(72)【発明者】

【氏名】梅川 知治

(72)【発明者】

【氏名】戸田 貴弘

(72)【発明者】

【氏名】兼吉 完聡

(72)【発明者】

【氏名】大和久 宏之

【合議体】

【審判長】 黒瀬 雅一

【審判官】 森次 顕

【審判官】 植田 高盛

(56)【参考文献】

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

【文献】 特開２０１０−５１４００（ＪＰ，Ａ）

【文献】 特開２００７−２２９２０５（ＪＰ，Ａ）

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

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

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

【文献】 特開２００４−２６６３０４（ＪＰ，Ａ）

【文献】 特開２００８−３０７４２５（ＪＰ，Ａ）

【文献】 特開２００４−２６７３６４（ＪＰ，Ａ）

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

A63F 13/00-13/98

A63F 9/24

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

【請求項1】

ユーザを識別するためのユーザ識別情報と、オブジェクトに関する情報であるオブジェクト情報と、が対応付けて記憶された記憶装置にアクセス可能なゲーム装置であって、
ユーザが操作する端末装置から抽選の実行指示を受け付ける受付手段と、
前記受付手段で受け付けられた実行指示に応じて、抽選対象となる複数のオブジェクト情報の中から２以上のオブジェクト情報を決定する抽選手段と、
前記抽選手段で決定された２以上のオブジェクト情報の中から少なくとも１つのオブジェクト情報を前記ユーザが選択できるように、前記端末装置に前記２以上のオブジェクト情報を表示させる提示手段と、
前記ユーザが選択したオブジェクト情報を、前記ユーザ識別情報に対応付けて記憶する対応付け手段と
を具備することを特徴とするゲーム装置。

【請求項2】

前記抽選手段で決定された２以上のオブジェクト情報の組合せが1又は複数の特典条件のいずれかを充足したとき、充足した前記特典条件に応じた特典を前記ユーザに提供する特典手段をさらに具備することを特徴とする請求項１に記載のゲーム装置。

【請求項3】

前記特典手段は、前記抽選手段で決定された２以上のオブジェクト情報の組合せが、複数の特典条件のうち２以上の特典条件を同時に充足したとき、同時に充足した特典条件の組合せに応じた特典を前記ユーザに提供することを特徴とする請求項２に記載のゲーム装置。

【請求項4】

前記特典手段は、前記オブジェクト情報に基づいて前記抽選手段で決定された２以上のオブジェクト情報の組合せが前記特典条件を充足するか否かを判断することを特徴とする請求項２又は３に記載のゲーム装置。

【請求項5】

前記抽選手段で決定する前記２以上のオブジェクト情報の数を設定する設定手段をさらに具備し、
前記特典手段は、前記設定手段で設定された数に応じて前記特典条件を変更することを特徴とする請求項２〜４のいずれかに記載のゲーム装置。

【請求項6】

前記２以上のオブジェクト情報を抽選で決定した順番を管理する管理手段をさらに具備し、
前記特典手段は、複数の前記組合せを構成する前記オブジェクト情報が１又は複数の特典条件のいずれかを充足したとき、充足した前記特典条件に応じた特典を前記ユーザに提供することを特徴とする請求項２〜５のいずれかに記載のゲーム装置。

【請求項7】

コンピュータを、請求項１〜６のいずれかに記載のゲーム装置の各手段として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、キャラクタを使用したゲームを利用者にプレイさせる技術に関する。

【背景技術】

【0002】

ソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ（Application Programming Interface）などの動作環境を基に作成されるゲーム用アプリケーションを用いて提供される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された端末装置を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。

【0003】

ソーシャルゲームとしては、例えば、ゲーム内でユーザに付与された複数のキャラクタ（例えば、モンスター）を使用してクエストや他のユーザとの戦闘等を実行していくＲＰＧ（Role-Playing Game）型のソーシャルゲームがあり、非特許文献１には、ユーザが所有する複数のキャラクタから所望の組合せのキャラクタを選択して他のユーザのキャラクタと戦闘させる技術が開示されている。

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】「ソーシャルゲーム総合情報誌 アプリＳＴＹＬＥ Ｖｏｌ．２」，株式会社イースト・プレス，平成２３年４月１日，ｐ.２６−ｐ.２９

【発明の概要】

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

【0005】

このようなソーシャルゲームにおいては、ゲーム内のポイントや通貨と引き換えに抽選で選ばれたキャラクタをユーザが獲得できる抽選イベントがある。

【0006】

しかし、この抽選イベントでは、ゲーム装置側で抽選されたキャラクタが付与されるだけで、ユーザ側でキャラクタを選ぶことができず、ユーザが欲しいキャラクタをなかなか獲得できない場合がある。特に多数のキャラクタを既に所持しているユーザにとっては、所持しているキャラクタが抽選によって選ばれることも多く、このような場合には抽選イベントに対するユーザの参加意欲を弱くする要因となっていた。

【0007】

そこで本発明では、抽選においてユーザが欲するキャラクタやアイテム等のオブジェクトを獲得できる可能性を高めることが可能なゲーム装置及びプログラムを提供することを目的とする。

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

【0008】

本発明に係るゲーム装置は、ユーザが操作する端末装置から抽選物の提供の要求を受け付ける受付手段と、抽選対象となる複数の抽選物の中から２以上の抽選物を抽選で決定する抽選手段と、前記抽選手段で決定された２以上の抽選物の中から前記ユーザが選択できるように前記端末装置に表示させる提示手段と、前記ユーザが選択した抽選物を前記ユーザに提供する提供手段とを具備する。

【0009】

この構成では、複数の抽選物をユーザに提示し、ユーザが選択することができるため、ユーザが欲する抽選物を獲得できる可能性を高めて、抽選イベントに対するユーザの参加意欲を向上させることができる。

【0010】

また、本発明に係るゲーム装置は、前記抽選手段で決定された２以上の抽選物の組合せが1又は複数の特典条件のいずれかを充足したとき、充足した前記特典条件に応じた特典を前記ユーザに提供する特典手段をさらに具備する。

【0011】

この構成は、特典条件が１つ設けられていて当該特典に充足する態様と、特典条件が複数設けられていて、いずれか一つの特典条件に充足する態様の両方を包含する。抽選の結果に応じて特典が付与されるため、抽選イベントに対するユーザの参加意欲を向上させることができる。

【0012】

また、本発明に係るゲーム装置の前記特典手段は、前記抽選手段で決定された２以上の抽選物の組合せが、複数の特典条件のうち２以上の特典条件を同時に充足したとき、同時に充足した特典条件の組合せに応じた特典を前記ユーザに提供する。例えば、ゲーム内で設定されている属性とレア度など、重複して特典条件を充足する可能性のある情報を用いて特典条件を設定することが可能であり、重複した場合の特典を変えるなど、ゲーム性を向上させることができる。

【0013】

また、本発明に係るゲーム装置の前記特典手段は、抽選物に設定された情報に基づいて前記選択肢が前記特典条件を充足するか否かを判断する。この構成では、キャラクタやアイテムの属性やパラメータなど、抽選物の任意の情報を用いて特典条件を設定することができるため、特典条件を付与するために特別な情報を設定することなく、特典条件を設定することができる。

【0014】

また、本発明に係るゲーム装置は、前記抽出手段で抽出する前記抽出物の数を設定する設定手段をさらに具備し、前記特典手段は、前記設定手段で設定された数に応じて前記特典条件を変更する。なお、設定手段は、ユーザの操作による切り替えや、時間などの所定条件に伴う切り替えなど、任意の方法を用いることができる。この構成では、例えば、三択と四択を選択可能とし、キャラクタ取得に関して言えば四択が有利、特典狙いであれば三択の方が有利とすることが可能であり、ゲーム性が向上する。

【0015】

また、本発明に係るゲーム装置は、前記抽選物を抽選で決定した順番を管理する管理手段をさらに具備し、前記特典手段は、複数の前記組合せを構成する前記抽出物が1又は複数の特典条件のいずれかを充足したとき、充足した前記特典条件に応じた特典を前記ユーザに提供する。２回目、３回目の抽選（再抽選）を行うか否かを判断でき、さらに、縦や斜めでの組も判断することができる。

【0016】

本発明に係るプログラムは、ユーザが操作する端末装置から抽選物の提供の要求を受け付けるステップと、抽選対象となる複数の抽選物の中から２以上の抽選物を抽選で決定するステップと、前記抽選手段で決定された２以上の抽選物の中から前記ユーザが選択できるように前記端末装置に表示させるステップと、前記ユーザが選択した抽選物を前記ユーザに提供するステップとをコンピュータに実行させる。コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。

【0017】

この構成では、複数の抽選物をユーザに提示し、ユーザが選択することができるため、ユーザが所望の抽選物を獲得できる可能性を向上し、抽選イベントに対するユーザの参加意欲を向上させることができる。

【発明の効果】

【0018】

本発明では、抽選イベントに対するユーザの参加意欲を向上させることができる。

【図面の簡単な説明】

【0019】

【図1】本発明の実施形態に係るゲームシステムのブロック図である。

【図2】クエスト処理の流れを示すフローチャートである。

【図3】イベント処理の流れを示すフローチャートである。

【図4】ボスバトル処理の流れを示すフローチャートである。

【図5】グループ編成処理の流れを示すフローチャートである。

【図6】バトル処理の流れを示すフローチャートである。

【図7】抽選イベント処理の流れを示すフローチャートである。

【図8】抽選イベント処理の流れを示すフローチャートである。

【図9】抽選イベント処理の流れを示すフローチャートである。

【図10】実施例３における特典条件を示す概念図である。

【図11】合成処理の流れを示すフローチャートである。

【図12】仲間申請の流れを示すフローチャートである。

【図13】トレード申請のフローチャートである。

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

【0020】

本発明に係るゲームシステムで提供されるゲームの一例は、ユーザがゲーム上の仲間である他のユーザとコミュニケーションをとりながらプレイするソーシャルゲームであって、ユーザは、収集したキャラクタを用いてエリア毎に設定された複数のクエストを順次進めながら様々な秘宝を集め、特別なキャラクタであるドラゴンを入手することを目指すゲームである。

【0021】

また、ユーザは、キャラクタを収集してグループを編成し、他のユーザやゲーム上の敵とバトルを行うことができる。キャラクタは、クエストや抽選を行うことで獲得でき、他のキャラクタと合成することで特定のキャラクタの能力を強化することもできる。また、ユーザは、他のユーザに対してトレード申請を行うことで、キャラクタやアイテム等の交換を申し出ることもできる。以下、図面を用いて詳細に説明する。

【0022】

＜ゲームシステムの構成＞
図１は、本発明に係るゲームシステム１００の構成の一例を示すブロック図である。同図に示すようにゲームシステム１００は、インターネット等の通信網１６を介して相互に通信する複数の端末装置１２とゲーム装置１４とを具備して構成される。

【0023】

端末装置１２は、例えば携帯電話機や携帯情報端末（ＰＤＡ：Personal Digital Assistant）、パーソナルコンピュータ等の通信端末であり、通信部２０と表示部２２と入力部２４と制御部２６とを含んで構成される。通信部２０は、通信網１６を介してゲーム装置１４と通信する通信インターフェイスである。表示部２２は、例えば液晶表示パネルなど、ゲーム画面等の各種画像を表示する。入力部２４は、端末装置１２に対する指示をユーザが入力するための機器であり、例えばユーザが操作する複数の操作子を含んで構成される。なお、表示部２２と一体に構成されてユーザからの操作を受付けるタッチパネルや、端末装置１２に対する指示をユーザが音声で入力するためのマイクロホンなどを入力部２４として採用することも可能である。制御部２６は、端末装置１２の制御中枢として機能するＣＰＵ（Central Processing Unit）などの情報処理装置で構成され、入力部２４に対するユーザからの指示に応じた処理を実行したり、ウェブページを端末装置１２の表示部２２に表示させたりする。

【0024】

ゲーム装置１４は、通信網１６を介して端末装置１２と相互に通信することによって、端末装置１２を所有するユーザにブラウザゲームを提供するウェブサーバであり、制御部３２と記憶部３４と通信部３６とを含んで構成される。制御部３２は、ＣＰＵなどの情報処理装置で構成され、入力部２４に対するユーザの指示に応じた処理を実行し、処理結果を通信部３６を介して端末装置１２に送信する。

【0025】

記憶部３４は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）、ＨＤＤ（Hard DiskDrive）等の記録媒体またはこれらの組合せを用いて構成され、制御部３２が実行するプログラム（ゲームプログラム）ＰGMを記憶している。また、記憶部３４は、制御部３２が使用する各種データをユーザ毎に記録したデータベースTBLを含む。

【0026】

記憶部３４に含まれるデータベースTBLには、ユーザＩＤ（ユーザ識別情報）が記憶されている。このユーザＩＤには、表示名、表示画像、レベル、経験値、体力値、攻魔値、防魔値、友情ポイント、キャラクタ数、通貨ポイント、所持コイン、保有アイテム、仲間のユーザＩＤ、保有キャラクタの画像データ、及び保有キャラクタのパラメータの各項目についての情報が関連付けられて記憶される。また、データベースTBLに含まれる情報は、制御部３２によって逐次更新されうる。

【0027】

図１に戻り、通信部３６は、通信網１６を介して端末装置１２と通信する通信インターフェイスである。

【0028】

そして、ゲーム装置１４は、入力部２４に対するユーザからの指示に応じて端末装置１２から送信される要求を契機として各種の処理を実行し、処理の結果を示すウェブページ（ゲーム画面）を端末装置１２の表示部２２に表示させる。

【0029】

上記構成を用いて本発明にかかるゲーム装置は、ユーザの端末装置１２に対する操作に応じて、ユーザがゲーム上で保有するキャラクタを用いてゲームをプレイするための処理を行う。

【0030】

＜クエスト＞
図２は、探索などのイベントであるクエストを実行する際の処理の流れを示すフローチャートである。

【0031】

ユーザは、クエストを実行すると、ユーザが保有する体力値と引き換えに経験値とゲーム内通貨である通貨ポイントが得られ、クエストの進行率が上昇する。そして、クエストの進行率が１００％となるとエリアクリアとなる。また、複数のエリアをクリアすると敵のキャラクタであるボスが現れ、ボスを倒すとステージクリアとなって次のステージに進むことができる。

【0032】

具体的には、洞窟を探索するイベントをクエストの例にとると、１つのフロアが複数のエリアに区分けされた１つのステージに相当し、ユーザが端末装置１２を介して“クエスト実行”（あるいは、対応するウェブページ上の釦）を選択する毎に、一定の体力値が減算され、進行率が上昇する。そして、進行率が１００％になると、ボスが登場し、このボスを倒すと次のフロアが探索可能になる。

【0033】

以下、図２を用いてクエストを実行する際の処理の流れを説明する。まず、端末装置１２の入力部２４を介してクエスト実行要求（探索）がユーザによって指示される（Ｓ１００）と、端末装置１２は、クエスト実行要求をゲーム装置１４に通知する。ゲーム装置１４の制御部３２は、通信部３６を介してクエスト実行要求を受信すると、一回のクエストを実行するのに必要な体力値を減算すると共に、一回のクエスト実行で得られる経験値や通貨ポイントを加算してデータベースに記録し（Ｓ１０１）、戦闘やアイテムの獲得といったイベント処理（Ｓ１０２）を行う。

【0034】

ここで図３は、イベント処理（Ｓ１０２）の流れを示すフローチャートである。まず、制御部３２は、発生するイベントを抽選によって決定する（Ｓ２０１）。本実施の形態では、「戦闘」、「アイテム獲得」という２つのイベントと「イベント無し」の計３つで抽選を行うこととする。

【0035】

ステップＳ２０１の抽選の結果で戦闘が発生する（Ｓ２１０）と、敵となるキャラクタのグループ（以下、「敵グループ」という）を設定（Ｓ２１１）し、ユーザの攻撃用グループを構成するキャラクタの攻撃力ＰAの合計値（以下「総攻撃力」という）ＴAと、敵グループを構成するキャラクタの防御力ＰDの合計値（以下「総防御力」という）ＴDとを比較して、ユーザが勝利した否かの判断を行う（Ｓ２１２）。ここで、総攻撃力ＴAが総防御力ＴDを下回る（ＴA＜ＴD）と、ユーザの敗北と判断し（Ｓ２１２でＮＯ）、イベント処理を終了する。一方、総攻撃力ＴAが総防御力ＴD以上である（ＴA≧ＴD）とユーザの勝利と判断し（Ｓ２１２でＹＥＳ）、経験値や通貨ポイントを加算してデータベースに記録して（Ｓ２１３）、イベント処理を終了する。

【0036】

ステップＳ２０１の抽選の結果でアイテムを獲得する（Ｓ２２０）と、ユーザに付与されるアイテムを抽選し（Ｓ２２１）、抽選されたアイテムをユーザＩＤに関連付けてデータベースに記録して（Ｓ２２２）処理を終了する。
ステップＳ２０１の抽選の結果でイベント無し（Ｓ２３０）となると、イベント処理を終了する。

【0037】

図２に戻ってイベント処理（Ｓ１０２）が終了すると、ボスが出現するか否かの判断を行い（Ｓ１０３）、ボスが出現しないと判断する（Ｓ１０３でＮＯ）と、クエスト後のゲーム画面を生成（Ｓ１０４）し、生成したゲーム画面をクエスト実行応答として端末装置１２に送信する。一方、ボスが出現すると判断する（Ｓ１０３でＹＥＳ）と、バトル処理（Ｓ１０５）を行う。

【0038】

ここで図４は、ボスと対戦する際のバトル処理（Ｓ１０５）の流れを示すフローチャートである。まず、ボス出現画面を生成（Ｓ３０１）し、端末装置１２に送信して（Ｓ３０２）表示部２２に表示させる。そして、端末装置１２の入力部２４を介してユーザからの戦闘指示がなされる（Ｓ３０３）と、ボスであるキャラクタの防御力ＰDと、ユーザの総攻撃力ＴAとを比較して、ユーザが勝利した否かの判断を行う（Ｓ３０４）。ここで、総攻撃力ＴAが防御力ＰDを下回る（ＴA＜ＰD）と、ユーザの敗北と判断して（Ｓ３０４でＮＯ）バトル処理を終了する。一方、総攻撃力ＴAが防御力ＰD以上である（ＴA≧ＰD）と、ユーザの勝利と判断して（Ｓ３０４でＹＥＳ）、経験値や通貨ポイントを加算してデータベースに記録し（Ｓ３０５）、バトル処理を終了する。

【0039】

図２に戻ってバトル処理（Ｓ１０５）が終了すると、戦闘の経過や結果を伝えるゲーム画面を生成（Ｓ１０４）し、生成したゲーム画面をクエスト実行応答として端末装置１２に送信する。クエスト実行応答を受信した端末装置１２は、表示部２２にクエスト実行応答として受信したゲーム画面を表示する（Ｓ１０６）。

【0040】

＜グループ＞
図５は、グループ編成処理の流れを示すフローチャートである。
ゲーム装置１４の制御部３２は、ユーザが所有する複数のキャラクタからグループを編成する対象となるキャラクタ（以下、「対象キャラクタ」という）を選択してグループ編成処理を実行する。攻撃用グループのグループ編成処理は、対象キャラクタの必要魔力Ｒの合計値Ｒsumが攻撃側のユーザの攻魔値ＬA以下となる範囲内で攻撃用グループを構成する。

【0041】

なお、本実施の形態では、攻撃用のグループを編成するグループ編成処理を説明するが、防御用グループのグループ編成処理も、対象キャラクタの必要魔力Ｒの合計値Ｒsumが防御側のユーザの防魔値ＬD以下となる範囲内で防御用グループを構成する点を除き、攻撃用グループを構成する場合と同様である。

【0042】

以下、図５を用いて、ユーザが保有するＮ個（Ｎは自然数）のキャラクタから攻撃用グループを編成するグループ編成処理の流れを説明する。まず、制御部３２は、ユーザが所有するＮ個の所有キャラクタのうち攻撃力ＰAの降順で上位に位置するＭ個のキャラクタを選択し（Ｓ４０１）、Ｍ個のキャラクタの必要魔力Ｒの合計値Ｒsumを算定する（Ｓ４０２）。

【0043】

そして、ステップＳ４０２で算定した合計値Ｒsumがユーザの攻魔値ＬA以下であるか否かを判定し（Ｓ４０３）、合計値Ｒsumがユーザの攻魔値ＬA以下であると判断する（Ｒsum≦ＬA）（Ｓ４０３でＹＥＳ）と、ステップＳ４０１で選択したＭ個のキャラクタを攻撃用グループの対象キャラクタとして確定し（Ｓ４０４）、グループ編成処理を終了する。

【0044】

一方、合計値Ｒsumがユーザの攻魔値ＬAを超えると判断する（Ｒsum＞ＬA）（Ｓ４０３でＮＯ）と、攻撃力ＰAの降順で上位からＭ個目のキャラクタを選択から外し（Ｓ４０５）、必要魔力Ｒの合計値Ｒsumを再計算し、ユーザの攻魔値ＬA以下であるか否かを判定する（Ｓ４０６）。再計算した合計値Ｒsumがユーザの攻魔値ＬAを超えると判断する（Ｓ４０６でＮＯ）（Ｒsum＞ＬA）と、次に攻撃力の低い（攻撃力ＰAの降順で上位から（Ｍ−１）個目の）キャラクタを選択から外し（Ｓ４０５）、必要魔力Ｒの合計値Ｒsumを再計算し、ユーザの攻魔値ＬA以下であるか否かを判定する（Ｓ４０６）。必要魔力Ｒの合計値Ｒsumがユーザの攻魔値ＬA以下となるまで、ステップＳ４０５からステップＳ４０６の処理を繰り返し行う。

【0045】

一方、必要魔力Ｒの合計値Ｒsumがユーザの攻魔値ＬA以下（Ｒsum≦ＬA）である（Ｓ４０６でＹＥＳ）と、必要魔力Ｒの合計値Ｒsumとユーザの攻魔値ＬAとの差を算出する（Ｓ４０７）。そして、当該差の範囲内に必要魔力が収まるキャラクタの有無を判断し（Ｓ４０８）、キャラクタがいない場合（Ｓ４０８でＮＯ）は、選択済みのキャラクタを攻撃用グループの対象キャラクタとして確定し（Ｓ４０４）、グループ編成処理を終了する。

【0046】

キャラクタがいる場合（Ｓ４０８でＹＥＳ）は、該当するキャラクタの中で最も攻撃力の高いキャラクタを選択する（Ｓ４０９）。選択済みキャラクタの数がキャラクタの最大数Ｍに達しているか否かの判断を行い（Ｓ４１０）、達している場合（Ｓ４１０でＮＯ）は、選択済みのキャラクタを攻撃用グループの対象キャラクタとして確定し（Ｓ４０４）、グループ編成処理を終了する。

【0047】

一方、キャラクタの数が最大数Ｍに達していない場合（Ｓ４１０でＹＥＳ）は、必要魔力Ｒの合計値Ｒsumとユーザの攻魔値ＬAとの差を算出し（Ｓ４０７）、当該差の範囲内に必要魔力が収まるキャラクタの有無を判断する（Ｓ４０６）。選択済みのキャラクタの数がＭに達するか、選択済みキャラクタの必要魔力Ｒの合計Ｒsumと攻魔値ＬAとの差以内のキャラクタが居なくなるまで、ステップＳ４０７からステップＳ４１０の処理を繰り返し行う。

【0048】

＜バトル＞
図６は、ユーザが他のユーザとバトルを行う際の処理の流れを示すフローチャートである。「秘宝」はクエストの他にも、他のユーザからバトルを通じて奪い取ることができる。以下、図６を用いて説明する。
端末装置１２の入力部２４を操作してユーザが他のユーザとのバトル（戦闘）を指示すると、まず、ゲーム装置１４の制御部３２は、記憶部３４に記憶されているデータベースを参照し、ユーザが揃えていないシリーズの秘宝（以下、「未完アイテム」という）が存在するか否かの判断を行う（Ｓ５０１）。

【0049】

未完アイテム群が存在しないと判断する（Ｓ５０１でＮＯ）と、ゲーム装置１４の制御部３２は、データベースを参照して所定の条件に合致する複数の対戦候補を抽出し、抽出した対戦候補を端末装置１２の表示部２２に表示する（Ｓ５０２）。対戦候補の抽出方法は任意であるが、例えばユーザとレベルが近い所定数のユーザを候補ユーザとして選択することが可能である。

【0050】

一方、ステップＳ５０１で未完アイテム群が存在すると判断する（Ｓ５０１でＹＥＳ）と、ゲーム装置１４の制御部３２は、未完アイテム群の中から取得していない任意の秘宝を選択し（Ｓ５０３）、データベースを参照して当該秘宝を所持していることを条件に複数の候補ユーザを抽出し、端末装置１２の表示部２２に表示する（Ｓ５０２）。

【0051】

そして、端末装置１２の入力部２４を介して対戦相手のユーザが選択され、戦闘が指示される（Ｓ５０４）と、攻撃側のユーザ（例えば戦闘イベントの発生を指示したユーザ）の攻撃用グループを編成する各対象キャラクタの攻撃力ＰAの合計値（以下「総攻撃力」という）ＴAと、防御側のユーザ（例えば攻撃側のユーザに戦闘相手として指定されたユーザ）の防御用グループを編成する各対象キャラクタの防御力ＰDの合計値（以下「総防御力」という）ＴDを比較して、攻撃側のユーザが勝利した否かの判断を行う（Ｓ５０５）。総攻撃力ＴAが総防御力ＴD以上である（ＴA≧ＴD）と、攻撃側のユーザの勝利と判断し、総攻撃力ＴAが総防御力ＴDを下回る（ＴA＜ＴD）と防御側のユーザの勝利と判断する。

【0052】

そして、秘宝の選択及び勝敗判断に基づいて、ユーザのパラメータ変化を判断し（Ｓ５０６）、データベースに記録する（Ｓ５０７）。具体的には、戦闘グループの必要魔力Ｒの合計値Ｒsumをユーザの攻魔値ＬAから減算して記録し、ユーザが戦闘に負けた場合は、ユーザの通貨ポイントを減算し、減算した通貨ポイントを対戦相手のユーザに加算して記録する。一方、ユーザが戦闘に勝利した場合は、対戦相手のユーザの通貨ポイントを減算し、減算した通貨ポイントをユーザに加算して記録すると共に、秘宝を選択していた場合は、記憶部３４に記憶されているデータベースにおいて、対戦相手であるユーザの所有アイテムを示す情報から当該秘宝を削除し、バトルを仕掛けたユーザの所有アイテムを示す情報に当該秘宝を追加する。

【0053】

また、勝敗の結果及び通貨ポイントの加算や減算、秘宝獲得の成功や失敗など、パラメータの変化をユーザの端末装置１２の表示部２２に表示させる（Ｓ５０８）。
なお、戦闘の結果に応じて加算又は減算する通貨ポイントは、例えば、所持金額の一割など、予めゲーム装置で設定しておく。

【0054】

＜抽選イベント＞
＜実施例１＞
ゲーム装置で抽選したキャラクタをユーザに付与する抽選イベントがある。以下、フローチャートを用いて詳細に説明する。
図７は、本発明に係る抽選イベント処理の一例を示すフローチャートである。なお、本実施例では、抽選処理で３体のキャラクタを抽出してユーザに提示する。抽選によって登場するキャラクタは、炎、森、水の３つの属性のいずれかに属するものとする。また、当該属性の組合せで特典条件が設定されており、抽選処理で抽出する３体のキャラクタの属性が全て一致する（（炎・炎・炎）、（森・森・森）、（水・水・水））場合、希少なキャラクタに限定して再抽選を行う権利が与えられる。一方、抽選処理で抽出する３体のキャラクタの属性が完全に異なる（（炎・森・水）、（炎・水・森）、（森・炎・水）、（森・水・炎）、（水・炎・森）、（水・森・炎））場合にはアイテムが付与ざれる。

【0055】

まず、端末装置１２の入力部を介してユーザから抽選の実行指示を受信する（Ｓ６０１）と、抽選処理を３回実施する（Ｓ６０２）。そして、ステップＳ６０２の抽選処理で得られたキャラクタの属性の組合せが、ユーザに特典を付与する条件である特典条件を充足するか否かの判断を行う（Ｓ６０３）。

【0056】

Ｓ６０３で特典条件を充足しないと判断する（Ｓ６０４）と、抽選結果をユーザの端末装置１２に送信する（Ｓ６０５）ことで、抽選処理で抽出した３体のキャラクタをユーザの端末装置１２に表示させる。
端末装置１２に３体のキャラクタが表示された後、ユーザは、表示された３体のキャラクタの中からいずれか１体のキャラクタを選択する。つまり、ユーザの欲するキャラクタを３体のキャラクタの中から選ばせるようにしている。

【0057】

そして、ユーザに選択された選択キャラクタが端末装置１２から通知される（Ｓ６０６）と、ユーザが選択したキャラクタがユーザがゲーム内で所有するキャラクタとしてデータベースに記録（更新）されて、ユーザに選択キャラクタを付与することになる（Ｓ６０７）。

【0058】

一方、ステップ６０３で、アイテムを付与する特典条件を充足した（３体のキャラクタの属性が異なる）と判断する（Ｓ６０８）と、抽選結果、及びアイテムの獲得を示す情報をユーザの端末装置１２に送信する（Ｓ６０９）ことで、抽選処理で抽出した３体のキャラクタをユーザの端末装置１２に表示させると共に、アイテムの獲得をユーザに通知する。また、獲得したアイテムをユーザがゲーム内で所有する所有物としてデータベースを更新することで、ユーザにアイテムを提供する（Ｓ６１０）。

【0059】

そして、ユーザに選択された選択キャラクタが端末装置１２から通知される（Ｓ６０６）と、ユーザがゲーム内で所有するキャラクタとしてデータベースを更新することによって、ユーザに選択キャラクタを付与する（Ｓ６０７）。

【0060】

ステップ６０３で、希少キャラクタに限定した再抽選を行う権利を獲得する特典条件を充足した（３体のキャラクタの属性が同一）と判断する（Ｓ６１１）と、抽選結果、及び再抽選を選択肢の一つとする旨をユーザの端末装置１２に送信する（Ｓ６１２）ことで、抽選処理で抽出した３体のキャラクタ、及び希少キャラクタに限定した再抽選を選択できることをユーザに通知する。

【0061】

ここで、再抽選指示を受信する（Ｓ６１３でＹＥＳ）と、希少キャラクタに限定した上で抽選を３回実施する抽選処理を行い（Ｓ６１４）当該抽選処理で得られたキャラクタの属性の組合せが、ユーザに特典を付与する条件である特典条件を充足するか否かの判断を行う（Ｓ６０３）。

【0062】

一方、再抽選指示を受信することなく（Ｓ６１３でＮＯ）ユーザに選択された選択キャラクタが端末装置１２から通知される（Ｓ６０６）と、ユーザがゲーム内で所有するキャラクタとしてデータベースを更新することによって、ユーザに選択キャラクタを付与する（Ｓ６０７）。

【0063】

このように本実施例では、ゲーム装置で複数のキャラクタを抽出してユーザに提示するため、ユーザの欲するキャラクタを獲得できる可能性が向上し、抽選イベントに対するユーザの参加意欲を向上させることができる。
なお、本実施例では、キャラクタを抽選物としているが、抽選物はキャラクタに限られるものではなく、アイテムなどであっても良い。

【0064】

また、本実施例では、属性を用いて特典条件を設定しているが、キャラクタの名称など、キャラクタ毎のユニークな識別子を用いて特典条件を定めても良い。さらに、キャラクタを複数のグループに分類できる情報で特典条件を設定することが望ましい。キャラクタの数に関係なく、処理を容易にすることが可能であり、特典条件設定後に導入された新しいキャラクタが抽選された場合でも、特典条件を充足する可能性があるからである。
加えて、属性とキャラクタのレア度など、重複して充足可能な特典条件を設定し、属性及びレア度が全て一致した場合など、重複して特典条件を充足した場合に提供する特典（例えば、特典条件を一つ充足した場合よりも希少なキャラクタ限定した再抽選など）を設定しても良い。

【0065】

＜実施例２＞
上記構成では、抽選処理で抽出するキャラクタの数が予め設定されていたが、ユーザが数を選択する構成としても良い。以下、図面を用いて詳細に説明する。

【0066】

図８は、本発明において、抽選の結果としてユーザに提示するキャラクタの数をユーザが指定可能とした場合の処理の一例を示すフローチャートである。なお、本実施例では、ユーザに提示するキャラクタの数として４体が指示されたとする。また、他の条件は、図７と同条件とする。

【0067】

まず、端末装置１２の入力部２４を介してユーザから抽選の実行指示を受信する（Ｓ１００１）と、ユーザに提示するキャラクタの数についての指示要求を送信し（Ｓ１００２）、キャラクタの数が指示されると、指示されたキャラクタ数に応じて特典条件を設定する（Ｓ１００３）。本実施例では、キャラクタ４体を提示することが指示されたとする。

【0068】

次に、抽選を４回実施する抽選処理を行い（Ｓ１００４）、抽選処理で得られたキャラクタの属性の組合せが、ユーザに特典を付与する条件である特典条件を充足するか否かの判断を行う（Ｓ１００５）。

【0069】

ここで、特典条件を充足しないと判断する（Ｓ１００５でＮＯ）と、抽選結果をユーザの端末装置１２に送信する（Ｓ１００６）ことで、抽選処理で抽出した４体のキャラクタをユーザの端末装置１２に表示させる。そして、ユーザに選択された選択キャラクタが端末装置１２から通知される（Ｓ１００７）と、ユーザがゲーム内で所有するキャラクタとしてデータベースを更新することによって、ユーザに選択キャラクタを付与する（Ｓ１００８）。

【0070】

一方、ステップＳ１００５で、希少キャラクタに限定した再抽選を行う権利を獲得する特典条件を充足した（４体のキャラクタの属性が同一）と判断する（Ｓ１００５でＹＥＳ）と、抽選結果、及び再抽選を選択肢の一つとする旨をユーザの端末装置１２に送信する（Ｓ１００９）ことで、抽選処理で抽出した４体のキャラクタ、及び希少キャラクタに限定した再抽選を選択できることを端末装置１２に表示させる。

【0071】

ここで、再抽選指示を受信する（Ｓ１０１０でＹＥＳ）と、希少キャラクタに限定した上で抽選を４回実施する抽選処理を行い（Ｓ１０１１）当該抽選処理で得られたキャラクタの属性の組合せが、ユーザに特典を付与する条件である特典条件を充足するか否かの判断を行う（Ｓ１００５）。

【0072】

一方、再抽選指示を受信することなく（Ｓ１０１０でＮＯ）ユーザに選択された選択キャラクタが端末装置１２から通知される（Ｓ１００７）と、ユーザがゲーム内で所有するキャラクタとしてデータベースを更新することによって、ユーザに選択キャラクタを付与する（Ｓ１００８）。

【0073】

このように本実施例では、キャラクタの数をユーザが指定して変えることができる。そのため、例えば、キャラクタ３体と４体を選択可能とし、キャラクタ取得に関して言えば４体（四択）が有利、特典狙いであれば３体（三択）の方が有利とすることが可能であり、ゲーム性が向上する。

【0074】

＜実施例３＞
上記構成では、その時に行われた抽選処理の結果で特典条件を充足するか否かを判断していたが、ユーザが再抽選を選択することで実施される複数の抽選処理の結果に基づいて特典条件を充足したか否かの判断を行っても良い。以下、図面を用いて詳細に説明する。

【0075】

図９は、本発明において、複数の抽選処理の結果を用いて特典条件の充足を判断する場合の処理の一例を示すフローチャートである。なお、本実施例では、再抽選が可能であり、少なくともユーザに提示するキャラクタの数と同じ数だけ抽選を行うことができる。すなわち、ユーザに３体のキャラクタを提示する場合、初回の抽選を含めて少なくとも３回抽選することが可能である。また、特典は、希少キャラクタに限定した抽選のみである。

【0076】

まず、端末装置１２の入力部２４を介してユーザから抽選の実行指示を受信する（Ｓ１１０１）と、抽選を３回実施する抽選処理を行う（Ｓ１１０２）。次に、抽選処理で抽出するキャラクタの数と、今回の抽選処理が何回目の抽選処理かを示す回数（以下、「抽選処理の回数」という）とを比較する（Ｓ１１０３）。

【0077】

そして、抽選処理の回数の方が多いと判断する（Ｓ１１０４）と、抽選結果、及び再抽選を選択肢としない旨をユーザの端末装置１２に送信する（Ｓ１１０５）ことで、抽選処理で抽出した３体のキャラクタを端末装置１２に表示させる。

【0078】

また、ステップＳ１１０３において抽選処理で抽出するキャラクタの数と、今回の抽選処理の回数の方が同じであると判断する（Ｓ１１０６）と、図１０を用いて後述するように、直前３回の抽選処理結果を用いて特典条件を充足したか否かの判断を行う（Ｓ１１０７）。

【0079】

ここで、特典条件を充足すると判断する（Ｓ１１０７でＹＥＳ）と、抽選結果、及び特典が発生した旨をユーザの端末装置１２に送信する（Ｓ１１０８）ことで、抽選処理で抽出した３体のキャラクタ、及び希少キャラクタに限定した再抽選を選択できることを端末装置１２に表示させる。

【0080】

ステップＳ１１０７で特典を充足しないと判断する（Ｓ１１０７でＮＯ）と、抽選結果、及び再抽選を選択肢としない旨をユーザの端末装置１２に送信し（Ｓ１１０５）、選択キャラクタを受信する（Ｓ１１０９）と、ユーザがゲーム内で所有するキャラクタとしてデータベースを更新することによって、ユーザに選択キャラクタを付与する（Ｓ１１１０）。

【0081】

ステップＳ１１０３における抽選処理で抽出するキャラクタの数よりも、今回の抽選処理の回数の方が少ないと判断する（Ｓ１１１１）と、抽選結果で得られたキャラクタ、及びキャラクタの抽選順をデータベースに記録し（Ｓ１１１２）、今回の抽選処理で得られたキャラクタの属性の組合せが、特典条件を充足するか否かの判断を行う（Ｓ１１１３）。

【0082】

ここで、特典条件を充足しないと判断する（Ｓ１１１３でＮＯ）と、抽選結果をユーザの端末装置１２に送信し（Ｓ１１１４）、端末装置１２からの指示を待つ（Ｓ１１１５）。一方、ステップＳ１１１３で特典条件を充足すると判断する（Ｓ１１１３でＹＥＳ）と、抽選結果、及び特典が発生した旨をユーザの端末装置１２に送信し（Ｓ１１０８）、端末装置１２からの指示を待つ（Ｓ１１１５）。

【0083】

ここで、再抽選指示を受信する（Ｓ１１１７）と、特典が発生したか否かの判断を行う（Ｓ１１１８）。そして、特典が発生したと判断する（Ｓ１１１８でＹＥＳ）と、希少キャラクタに限定した上で抽選を３回実施する抽選処理を行い（Ｓ１１１９）、抽選処理で抽出するキャラクタの数と、今回の抽選処理が何回目の抽選処理かを示す回数（以下、「抽選処理の回数」という）とを比較する（Ｓ１１０３）。

【0084】

一方、端末装置１２から選択キャラクタを受信する（Ｓ１１１６）と、ユーザがゲーム内で所有するキャラクタとしてデータベースを更新することによって、ユーザに選択キャラクタを付与する（Ｓ１１１０）。

【0085】

次に、直前３回の抽選処理結果を用いて特典条件を充足したか否かの判断を行うステップＳ１１０７の処理について、図１０を用いて説明する。同図に示すように、抽選処理毎の組（キャラクタＡ、Ｂ、Ｃ）（キャラクタＤ、Ｅ、Ｆ）（キャラクタＧ、Ｈ、Ｉ）を上方から順に配置し、抽選回数の組（キャラクタＡ、Ｄ、Ｇ）（キャラクタＢ、Ｅ、Ｈ）（キャラクタＣ、Ｆ、Ｉ）を左から抽選順に配置した場合に、抽選処理毎の組と抽選回数の組のそれぞれで特典条件を充足したか否かの判断を行う。さらに、図１０に示すように、抽選処理毎と抽選回数毎の組が直角に交わるように千鳥格子状に（つまり、マトリクス状に）配置した場合の対角線の組（図１０に破線で示す）で特典条件を充足したか否かの判断を行う。

【0086】

このように、本実施の形態では、既に抽選処理した結果も特典条件を充足する条件となるので、ユーザにとっては、再抽選を行うか否かの判断が難しくなりゲーム性が向上する。なお、上記各実施例では、特典の一つとして再抽選を行っているが、抽選イベントへの参加権をアイテムとして提供しても良い。

【0087】

＜合成＞
図１１は、キャラクタを合成して強化する際の処理の流れを示すフローチャートである。ベースとなるキャラクタに素材となるキャラクタを合成することによって、ベースとなるキャラクタの成長度合い（経験値）が増加し、素材となったキャラクタが失われる。成長度合いが１００％に達してレベルがアップすると、「攻撃力」、「防御力」などのパラメータが上昇する。「特技」は、同じ「特技」を有するキャラクタ同士を合成することで、上昇する場合がある。合成時には、通貨ポイントが必要であり、レベルアップさせるベースモンスターキャラクタのレベルが高いほど、通貨ポイントも多く必要である。以下、図１１を用いて説明する。

【0088】

端末装置１２の入力部を介してユーザから合成が指示される（Ｓ７０１）と、ゲーム装置１４の制御部３２は、端末装置１２の表示部２２にキャラクタの一覧を表示させる（Ｓ７０２）。

【0089】

ここで端末装置１２の入力部２４を介して一括合成が指示される（Ｓ７０３でＹＥＳ）と、制御部３２は、素材となるキャラクタ選択肢として特定のキャラクタのみを表示部２２に表示させる（Ｓ７０４）。例えば、レア度が低く、レベル１のキャラクタのみを表示するなど、ユーザが誤操作する恐れが少ないキャラクタのみを表示する。そして、ベースとなるキャラクタ及び素材となるキャラクタが選択され、合成が指示される（Ｓ７０５）と、制御部３２は、ベースとなるキャラクタに対して上昇させる経験値（成長度合い）を算出し、経験値（成長度合い）を上昇させ、レベルアップすればそれに応じてパラメータを上昇させる合成処理を行う（Ｓ７０６）。

【0090】

一方、一括合成が指示されず（Ｓ７０３でＮＯ）にベースとなるキャラクタ及び素材となるキャラクタが選択され、合成が指示される（Ｓ７０７）と、制御部３２は、誤操作を防止するための警告条件に該当するか否かの判断を行う（Ｓ７０８）。そして、警告条件に該当しない場合（Ｓ７０８でＮＯ）は、ベースとなるキャラクタに対して上昇させる経験値（成長度合い）を算出し、経験値（成長度合い）を上昇させる（合成処理）（Ｓ７０６）。警告条件に該当する場合（Ｓ７０８でＹＥＳ）は、ユーザに警告を行い（Ｓ７０９）、再度合成が指示される（Ｓ７１０でＹＥＳ）と合成処理を行い（Ｓ７０６）、合成がキャンセルされると（Ｓ７１０でＮＯ）キャラクタの一覧を表示させる（Ｓ７０２）。

【0091】

警告条件としては、例えば、希少なキャラクタが素材となっている場合や、ベースとなるキャラクタよりもレベルの高いキャラクタが素材になっている場合など、ご操作が想定される条件があげられ、合成を再度指示する際にチェック欄を表示し、チェック欄にチェックが入っていることを条件としても良い。

【0092】

＜仲間（申請）＞
図１２は、仲間申請の際の処理の流れを示すフローチャートである。まず、制御部３２は、端末装置１２から仲間申請を受け付ける（Ｓ８０１）と、ユーザが候補を直接選ぶか、ゲーム装置側で候補を抽出するかの選択を端末装置１２の表示部２２に表示する（Ｓ８０２）。そして、ユーザが直接選ぶことを選択する（Ｓ８０３）と、ＳＮＳ上の友達一覧を抽出し（Ｓ８０４）、表示部２２に仲間申請先の候補として表示する（Ｓ８０５）。

【0093】

一方、ゲーム装置側で候補を抽出することが選択される（Ｓ８０６）と、制御部３２は、候補となるユーザをデータベースから抽出し（Ｓ８０７）、端末装置１２の表示部２２に仲間申請先の候補として表示する（Ｓ８０５）。

【0094】

仲間申請先のユーザが選ばれる（Ｓ８０８）と、制御部３２は、仲間申請があった旨を申請先のユーザの端末装置の表示部（ゲーム画面）に表示する（Ｓ８０９）。そして、申請先で仲間申請が承認される（Ｓ８１０）と、申請元のユーザと申請先のユーザが仲間関係である旨が、記憶部３４のデータベースに記録される（Ｓ８１１）。

【0095】

＜トレード（申請）＞
図１３は、キャラクタのトレードを他のユーザに申請する際の処理の流れを示すフローチャートである。
まず、端末装置１２の入力部２４を操作して、トレードを申し込む申請先のユーザ（以下、「申請先」という）のページからトレード申請を指示する（Ｓ９０１）と、ゲーム装置１４の制御部３２は、記憶部３４のデータベースを参照して、トレードを申請したユーザ（以下、「申請元」という）のトレード対象と成り得る所持品を端末装置１２の表示部２２に表示する（Ｓ９０２）。

【0096】

そして、申請元がトレード対象物を選択する（Ｓ９０３）と、制御部３２は、電子メールや申請先のゲーム画面などを通じてトレード申請がある旨を申請先に通知する（Ｓ９０４）。

【0097】

申請先がトレード申請画面を開くと、申請元がトレード対象物に選択した物を表示する（Ｓ９０５）と共に、ゲーム装置１４の制御部３２は、記憶部３４のデータベースを参照して、申請先のトレード対象と成り得る所持品を申請先の端末装置１２の表示部２２に表示する（Ｓ９０６）。

【0098】

ここで、端末装置１２の入力部２４を操作してトレードが拒否される（Ｓ９０７でＮＯ）と、トレード申請処理を終了し、トレード申請先がトレード対象物を選択する（Ｓ９０７でＹＥＳ）と、ゲーム装置１４の制御部３２は、トレード申請への応答があった旨を申請元に通知する（Ｓ９０８）。

【0099】

申請元がトレード申請画面を開き、端末装置１２の入力部２４を操作してトレードが拒否される（Ｓ９０９でＮＯ）と、トレード申請処理を終了し、トレードが承認される（Ｓ９０９でＹＥＳ）と、トレードが成立し、ゲーム装置１４の制御部３２は、記憶部３４のデータベースを更新して、トレードの対象物を交換する（Ｓ９１０）と共に、トレード対象物が申請元と申請先のそれぞれにプレゼントとして届くための処理を行う（Ｓ９１１）。

【0100】

なお、トレードの対象となっているアイテムやキャラクタなどの対象物は、トレード申請が終了するまでロックされる。また、トレード申請の開始から終了までが所定時間（例えば４８時間）内に終了しない場合は、トレード申請が終了し、ロックも解除される。

【符号の説明】

【0101】

１２…端末装置、１４…ゲーム装置、１６……通信網、２０、３６……通信部、２２……表示部、２４……入力部、２６,３２……制御部、３４……記憶部、１００……ゲームシステム。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】