特許 5941386 ゲーム制御装置、プログラム、ゲームシステム

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

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

(11)【特許番号】5941386

(24)【登録日】2016年5月27日

(45)【発行日】2016年6月29日

(54)【発明の名称】ゲーム制御装置、プログラム、ゲームシステム

(51)【国際特許分類】

   A63F 13/69 20140101AFI20160616BHJP

【ＦＩ】

   A63F13/69 510

   A63F13/69 500

【請求項の数】8

【全頁数】40

(21)【出願番号】特願2012-215837(P2012-215837)

(22)【出願日】2012年9月28日

(65)【公開番号】特開2014-68731(P2014-68731A)

(43)【公開日】2014年4月21日

【審査請求日】2014年9月18日

(73)【特許権者】

【識別番号】506113602

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

(74)【代理人】

【識別番号】110000165

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

(72)【発明者】

【氏名】鈴木 英之

(72)【発明者】

【氏名】北村 暢也

【審査官】 彦田 克文

(56)【参考文献】

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

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

【文献】 特表２０１２−５１６７４９（ＪＰ，Ａ）

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

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

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

【請求項1】

ユーザと複数のオブジェクトとを対応付ける対応付け手段と、
前記ユーザの入力に関する情報に基づいて、前記ユーザに対応付けられた複数のオブジェクトの中から前記ユーザに付与される付与オブジェクトを選択する選択手段と、
前記付与オブジェクトを選択した場合に、前記ユーザと前記付与オブジェクトとの対応付けを解除する解除手段と、
所定の入力に関する情報に基づいて、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新する更新手段と、
所定の対価を設定する設定手段と、
前記第１ユーザに対応付けられた複数のオブジェクトのうちいずれかの付与オブジェクトを除くオブジェクトに関する情報を前記第２ユーザに提示する提示手段と、を備え、
前記更新手段は、前記提示手段によって前記オブジェクトに関する情報が提示された後に前記対価が前記第２ユーザによって支払われたことを条件として、前記第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新することを特徴とする、
ゲーム制御装置。

【請求項2】

前記設定手段は、前記第１ユーザに対する付与オブジェクトに関する情報に基づいて、
前記所定の対価を設定することを特徴とする、
請求項１に記載されたゲーム制御装置。

【請求項3】

ユーザと複数のオブジェクトとを対応付ける対応付け手段と、
前記ユーザの入力に関する情報に基づいて、前記ユーザに対応付けられた複数のオブジェクトの中から前記ユーザに付与される付与オブジェクトを選択する選択手段と、
前記付与オブジェクトを選択した場合に、前記ユーザと前記付与オブジェクトとの対応付けを解除する解除手段と、
所定の入力に関する情報に基づいて、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新する更新手段と、
ユーザ同士を関係付ける関係付け手段と、
前記第１ユーザに対応付けられた複数のオブジェクトのうちいずれかの付与オブジェクトを除くオブジェクトに関する情報を前記第２ユーザに提示する提示手段と、を備え、
前記更新手段は、前記第２ユーザが前記第１ユーザに関係付けられている場合に、前記提示手段によって前記オブジェクトに関する情報が提示された後の前記第２ユーザの入力に関する情報に基づいて、前記第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新することを特徴とする、
ゲーム制御装置。

【請求項4】

ユーザと複数のオブジェクトとを対応付ける対応付け手段と、
前記ユーザの入力に関する情報に基づいて、前記ユーザに対応付けられた複数のオブジェクトの中から前記ユーザに付与される付与オブジェクトを選択する選択手段と、
前記付与オブジェクトを選択した場合に、前記ユーザと前記付与オブジェクトとの対応付けを解除する解除手段と、
所定の入力に関する情報に基づいて、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新する更新手段と、
前記第１ユーザに対応付けられた複数のオブジェクトのうちいずれかの付与オブジェクトを除くオブジェクトに関する情報を前記第２ユーザに提示する提示手段と、を備え、
前記更新手段は、前記第２ユーザによるオブジェクトの選択回数が所定の条件を満たす場合に、前記提示手段によって前記オブジェクトに関する情報が提示された後の前記第２ユーザの入力に関する情報に基づいて、前記第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新することを特徴とする、
ゲーム制御装置。

【請求項5】

複数の属性のいずれかに属するオブジェクトに関するゲームを制御するゲーム制御装置であって、
ユーザと、前記オブジェクトの属性ごとの付与可能数との対応付けを行う対応付け手段と、
前記ユーザの入力に関する情報に基づいて、複数のオブジェクトの中から、前記付与可能数が１以上の属性に対応するオブジェクトを、前記ユーザに付与する付与オブジェクトとして選択する選択手段と、
前記ユーザに対応付けられた属性ごとの付与可能数のうち、前記付与オブジェクトとして選択されたオブジェクトの属性に対応する付与可能数を減らすことによって、前記ユーザと前記付与可能数との対応付けを変更する変更手段と、
第２ユーザの入力に関する情報に基づいて、前記変更手段によって前記対応付けが変更された後の第１ユーザに対応付けられた属性ごとの付与可能数を、第２ユーザに対応付ける更新手段と、
を備えた、ゲーム制御装置。

【請求項6】

複数の属性のいずれかに属するオブジェクトに関するゲームを制御するゲーム制御装置であって、
ユーザと、前記オブジェクトの属性ごとの付与可能数との対応付けを行う対応付け手段と、
前記ユーザの入力に関する情報に基づいて、複数のオブジェクトの中から、前記付与可能数が１以上の属性に対応するオブジェクトを、前記ユーザに付与する付与オブジェクトとして選択する選択手段と、
前記ユーザに対応付けられた属性ごとの付与可能数のうち、前記付与オブジェクトとして選択されたオブジェクトの属性に対応する付与可能数を減らすことによって、前記ユーザと前記付与可能数との対応付けを変更する変更手段と、
第２ユーザの入力に関する情報に基づいて、前記第２ユーザに対応付けられた属性ごとの付与可能数から、第１ユーザに対応付けられた属性ごとの付与可能数の初期値と前記変更手段によって変更された後の属性ごとの付与可能数との差を減算することによって、前記第２ユーザと前記属性ごとの付与可能数との対応付けを更新する更新手段と、
を備えた、ゲーム制御装置。

【請求項7】

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

【請求項8】

通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
請求項１〜６のいずれかに記載されたゲーム制御装置の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
ゲームシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、オブジェクトなどの対象を選択あるいは抽選するときの技術に関する。

【背景技術】

【0002】

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

【0003】

上述したソーシャルゲームでは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、関係付けられたユーザ（仲間）間で協力したゲームの実行のほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。このようなソーシャルゲームの一例として、下記の非特許文献１に記載されたデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】アプリＳＴＹＬＥ Vol.5（株式会社イースト・プレス、2011年11月15日発行）、94頁

【発明の概要】

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

【0005】

従来のゲームでは、例えば、所定数のオブジェクトを抽選対象として用意し、抽選対象の中から抽選によって選択されたオブジェクトをユーザに付与するものが知られている。このゲームでは、抽選によってユーザに付与されるオブジェクトの数が多くなるほど、抽選対象のオブジェクトの母数が小さくなるため、例えばユーザの所望するオブジェクトが抽選対象に含まれている場合には、ユーザは、抽選を繰り返し行うことによって、所望のオブジェクトを入手する可能性を高めることが可能となっている。しかしながら、従来のゲームでは、ユーザが単独でオブジェクトの抽選を行うようになっていたため、複数のユーザが協力してオブジェクトの抽選を楽しむことができなかった。

【0006】

本発明は上述した観点に鑑みてなされたもので、複数のユーザが協力してオブジェクトの抽選を楽しむことができるゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、抽選装置を提供することを目的とする。

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

【0007】

本発明の第１の観点は、ゲーム制御装置である。
当該ゲーム制御装置は、
ユーザと複数のオブジェクトとを対応付ける対応付け手段（５３）と、
前記ユーザの入力に関する情報に基づいて、前記ユーザに対応付けられた複数のオブジェクトの中から前記ユーザに付与される付与オブジェクトを選択する選択手段（５４）と、
前記付与オブジェクトを選択した場合に、前記ユーザと前記付与オブジェクトとの対応付けを解除する解除手段（５５）と、
所定の入力に関する情報に基づいて、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新する更新手段（５８）と、
を備える。

【0008】

ここで、「オブジェクト」は、選択対象となり得るものであれば如何なるものでもよく、例えばゲーム上のアイテムやキャラクタを含んでもよい。キャラクタとは、例えば現実世界に存在するもの（例えばスポーツ選手や歌手、アイドル、動物等）を模したものや、ゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。

【0009】

このゲーム制御装置によれば、ユーザは、自らの入力によって、自らに対応付けられた複数のオブジェクトの中から選択（抽選）された付与オブジェクトを入手することができる。また、付与オブジェクトが選択された場合には、ユーザと付与オブジェクトとの対応付けが解除されることから、ユーザは、付与オブジェクトを抽選対象から除いた状態でオブジェクトの抽選を繰り返し行うことが可能となる。さらに、第２ユーザは、所定の入力によって、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で自身に対応付ける（保有する）ことができる。この場合、第２ユーザは、第１ユーザに付与されていないオブジェクトを第１ユーザから引き継いだ状態でオブジェクトの抽選を行うことが可能となる。ここで、例えば、第１ユーザに付与されていないオブジェクトの中に第２ユーザの所望するオブジェクトが含まれている場合には、第２ユーザは、所望のオブジェクトを得るために、オブジェクトの抽選を行うことが動機付けられる。これにより、複数のユーザが協力してオブジェクトの抽選を楽しむことができる。

【0010】

上記ゲーム制御装置において、所定の対価を設定する設定手段（５６）を備え、前記更新手段（５８）は、設定された対価が前記第２ユーザによって支払われたことを条件として、前記第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新してもよい。
このゲーム制御装置によれば、第２ユーザは、設定された対価を支払わなければ、第１ユーザに対応付けられた複数のオブジェクトを、いずれかの付与オブジェクトを除いた状態で自身に対応付ける（保有する）ことができない。つまり、第２ユーザは、第１ユーザに付与されていないオブジェクトを抽選対象としてオブジェクトの抽選を行うためには、設定された対価を支払う必要がある。このため、例えば、第１ユーザに付与されていないオブジェクトの中に第２ユーザの所望するオブジェクトが含まれている場合には、所望のオブジェクトを抽選によって得るために対価を支払うべきか否かなどについて第２ユーザに慎重に検討させることができるので、第２ユーザの判断力や戦略などが求められる仕組みとすることができる。これにより、興趣性の高いゲームを実現することができる。

【0011】

上記ゲーム制御装置において、前記設定手段（５６）は、前記第１ユーザに対する付与オブジェクトに関する情報に基づいて、前記所定の対価を設定してもよい。
例えば、第１ユーザが所定の対価を手動で設定する場合において、第１ユーザが当該対価をどの程度に設定すべきか判断することが困難な場合には、第１ユーザにとっては、所定の対価を設定することが煩雑となるおそれがある。
このゲーム制御装置によれば、所定の対価を、第１ユーザに対する付与オブジェクトに関する情報に基づいて設定することができる。この場合、例えば第１ユーザによる所定の対価の入力などを契機とせずに自動的に所定の対価を設定することが可能となる。これにより、例えば、所定の対価をどの程度に設定すべきかなどについて第１ユーザに判断させる必要がないことから、第１ユーザにとっては所定の対価を容易に設定することが可能となるため、ゲームの利便性を向上させることができる。

【0012】

上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段（５９）を備え、前記更新手段（５８）は、前記第２ユーザが前記第１ユーザに関係付けられている場合に、前記第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新してもよい。
このゲーム制御装置によれば、第２ユーザは、第１ユーザと関係付けられていなければ、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で自身に対応付ける（保有する）ことができない。このため、例えば、第１ユーザに付与されていないオブジェクトの中に第２ユーザの所望するオブジェクトが含まれている場合には、第２ユーザは、所望のオブジェクトを抽選によって得るために、第１ユーザと関係付ける（例えば、仲間になる）ことが動機付けられる。これにより、ユーザ間の交流を促進することができるので、ゲームのソーシャル性を向上させることができる。

【0013】

上記ゲーム制御装置において、前記更新手段（５８）は、前記第２ユーザによるオブジェクトの選択回数が所定の条件を満たす場合に、前記第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新してもよい。
ここで、「所定の条件」とは、例えば、第２ユーザによるオブジェクトの選択回数が所定値以上であることとしてもよいし、第２ユーザによるオブジェクトの選択回数が第１ユーザによるオブジェクトの選択回数以上であることとしてもよい。
このゲーム制御装置によれば、第２ユーザは、自らのオブジェクトの選択回数（抽選回数）が所定の条件を満たしていなければ、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で自身に対応付ける（保有する）ことができない。このため、例えば、第１ユーザに付与されていないオブジェクトの中に第２ユーザの所望するオブジェクトが含まれている場合には、第２ユーザは、所望のオブジェクトを抽選によって得るために、自らのオブジェクトの選択回数が所定の条件を満たすように動機付けられる。これにより、ゲームに対する第２ユーザの遊戯意欲を向上させることができる。

【0014】

上記ゲーム制御装置において、前記第１ユーザに対応付けられた複数のオブジェクトのうちいずれかの付与オブジェクトを除くオブジェクトに関する情報を前記第２ユーザに提示する提示手段（５７）を備えてもよい。
このゲーム制御装置によれば、第２ユーザは、第１ユーザに対応付けられた複数のオブジェクトのうち、少なくとも第１ユーザに付与されていないオブジェクトを認識することができる。ここで、例えば、第１ユーザに付与されていないオブジェクトの中に第２ユーザの所望するオブジェクトが含まれている場合には、第２ユーザは、所望のオブジェクトを抽選によって得るために、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で自身に対応付ける（保有する）ように動機付けられる。

【0015】

本発明の第２の観点は、複数の属性のいずれかに属するオブジェクトに関するゲームを制御するゲーム制御装置である。
当該ゲーム制御装置は、
ユーザと、前記オブジェクトの属性ごとの付与可能数との対応付けを行う対応付け手段（５３）と、
前記ユーザの入力に関する情報に基づいて、前記ユーザに付与される付与オブジェクトを、前記複数の属性のうちいずれかの属性に属する複数のオブジェクトの中から当該属性に対応する付与可能数の範囲内で選択する選択手段（５４）と、
前記付与オブジェクトを選択するごとに、前記付与オブジェクトの属性に対応する付与可能数を減らすことによって、前記対応付けを変更する変更手段（６０）と、
所定の入力に関する情報に基づいて、第１ユーザに対応付けられたときの付与可能数から前記付与オブジェクトの数を減らした付与可能数を前記複数の属性ごとに第２ユーザに対応付けるように、前記第２ユーザについての前記対応付けを更新する更新手段（５８）と、
を備える。

【0016】

ここで、「オブジェクトの属性」とは、例えば、オブジェクトの特徴や性質などを示す情報であってもよいし、オブジェクトの特徴や性質などを分類するための情報であってもよい。
このゲーム制御装置では、ユーザは、自らの入力によって、複数の属性のうちいずれかの属性に属する複数のオブジェクトの中から選択（抽選）された付与オブジェクトを入手することができる。また、付与オブジェクトが選択された場合には、ユーザは、付与オブジェクトの属性に対応する付与可能数を減らした状態でオブジェクトの抽選を繰り返し行うことが可能となる。さらに、第２ユーザは、所定の入力によって、第１ユーザに対応付けられたときの付与可能回数からいずれかの付与オブジェクトの数を減らした付与可能数を複数の属性ごとに自身に対応付ける（保有する）ことができる。この場合、第２ユーザは、複数の属性ごとの付与可能数を第１ユーザから引き継いだ状態でオブジェクトの抽選を行うことが可能となる。ここで、第２ユーザは、例えば、所望の属性に対応する付与可能数が充分な状態で複数の属性ごとの付与可能数を第１ユーザから引き継いだ場合、所望の属性に属するオブジェクトを得るために、オブジェクトの抽選を行うことが動機付けられる。これにより、複数のユーザが協力してオブジェクトの抽選を楽しむことができる。

【0017】

本発明の第３の観点は、複数の属性のいずれかに属するオブジェクトに関するゲームを制御するゲーム制御装置である。
当該ゲーム制御装置は、
ユーザと、前記オブジェクトの属性ごとの付与可能数との対応付けを行う対応付け手段（５３）と、
前記ユーザの入力に関する情報に基づいて、前記ユーザに付与される付与オブジェクトを、前記複数の属性のうちいずれかの属性に属する複数のオブジェクトの中から当該属性に対応する付与可能数の範囲内で選択する選択手段（５４）と、
前記付与オブジェクトを選択するごとに、前記付与オブジェクトの属性に対応する付与可能数を減らすことによって、前記対応付けを変更する変更手段（６０）と、
所定の入力に関する情報に基づいて、第１ユーザに対するいずれかの前記付与オブジェクトの数だけ当該付与オブジェクトの属性に対応する付与可能数を減らした状態で前記複数の属性ごとの付与可能数を第２ユーザに対応付けるように、前記第２ユーザについての前記対応付けを更新する更新手段（５８）と、
を備える。

【0018】

このゲーム制御装置では、ユーザは、自らの入力によって、複数の属性のうちいずれかの属性に属する複数のオブジェクトの中から選択（抽選）された付与オブジェクトを入手することができる。また、付与オブジェクトが選択された場合には、ユーザは、付与オブジェクトの属性に対応する付与可能数を減らした状態でオブジェクトの抽選を繰り返し行うことが可能となる。さらに、第２ユーザは、所定の入力によって、第１ユーザに対するいずれかの前記付与オブジェクトの数だけ当該付与オブジェクトの属性に対応する付与可能数を減らした状態で複数の属性ごとの付与可能数を自身に対応付ける（保有する）ことができる。この場合、第２ユーザは、例えば、所望しない属性に対応する付与可能数が多い場合には、第１ユーザが当該所望しない属性に属する付与オブジェクトを入手した数だけ当該付与可能数を減らした状態で、オブジェクトの抽選を行うことができる。このとき、第２ユーザは、所望しない属性に属するオブジェクトを抽選で入手する確率を低減することができるので、オブジェクトの抽選を楽しむことが可能となる。これにより、複数のユーザが協力してオブジェクトの抽選を楽しむことができる。

【0019】

本発明の第４の観点は、ゲーム制御方法である。
当該ゲーム制御方法は、
ユーザと複数のオブジェクトとを対応付けるステップと、
前記ユーザの入力に関する情報に基づいて、前記ユーザに対応付けられた複数のオブジェクトの中から前記ユーザに付与される付与オブジェクトを選択するステップと、
前記付与オブジェクトを選択した場合に、前記ユーザと前記付与オブジェクトとの対応付けを解除するステップと、
所定の入力に関する情報に基づいて、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新するステップと、
を備える。

【0020】

本発明の第５の観点は、コンピュータに、
ユーザと複数のオブジェクトとを対応付ける機能、
前記ユーザの入力に関する情報に基づいて、前記ユーザに対応付けられた複数のオブジェクトの中から前記ユーザに付与される付与オブジェクトを選択する機能、
前記付与オブジェクトを選択した場合に、前記ユーザと前記付与オブジェクトとの対応付けを解除する機能、及び
所定の入力に関する情報に基づいて、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新する機能、
を実現させるためのプログラムである。

【0021】

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。

【0022】

本発明の第６の観点は、通信端末（１０）と、当該通信端末（１０）からアクセスされるサーバ（２０）とを含むゲームシステムであって、
ユーザと複数のオブジェクトとを対応付ける対応付け手段（５３）、
前記ユーザの入力に関する情報に基づいて、前記ユーザに対応付けられた複数のオブジェクトの中から前記ユーザに付与される付与オブジェクトを選択する選択手段（５４）、
前記付与オブジェクトを選択した場合に、前記ユーザと前記付与オブジェクトとの対応付けを解除する解除手段（５５）、
所定の入力に関する情報に基づいて、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新する更新手段（５８）、
の各手段を、前記通信端末（１０）又は前記サーバ（２０）のいずれか一方が備える。

【0023】

通信端末は、例えば携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機、通信機能付きゲーム装置等であってよい。

【0024】

本発明の第７の観点は、抽選装置である。
当該抽選装置は、
ユーザと複数のオブジェクトとを対応付ける対応付け手段（５３）と、
前記ユーザの入力に関する情報に基づいて、前記ユーザに対応付けられた複数のオブジェクトの中から前記ユーザに付与される付与オブジェクトを選択する選択手段（５４）と、
前記付与オブジェクトを選択した場合に、前記ユーザと前記付与オブジェクトとの対応付けを解除する解除手段（５５）と、
所定の入力に関する情報に基づいて、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新する更新手段（５８）と、
を備える。

【0025】

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

【発明の効果】

【0026】

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、抽選装置によれば、複数のユーザが協力してオブジェクトの抽選を楽しむことができる。

【図面の簡単な説明】

【0027】

【図1】第１実施形態のゲームシステムの基本構成を示す図。

【図2】通信端末の外観の例を示す図。

【図3】通信端末の構成を示すブロック図。

【図4】ゲームサーバの構成を示すブロック図。

【図5】データベースサーバの構成を示すブロック図。

【図6】ユーザデータベースの構成例を示す図。

【図7】モンスターカードデータベースの構成例を示す図。

【図8】抽選ボックスデータの構成例を示す図。

【図9】第１実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。

【図10】ユーザの通信端末に表示される一連のウェブページを例示する図。

【図11】ユーザの通信端末に表示される一連のウェブページを例示する図。

【図12】第１実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。

【図13】第１実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。

【図14】変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。

【図15】親密度データの構成例を示す図。

【図16】第２実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。

【図17】第２実施形態のゲーム制御装置における抽選ボックスデータの構成例を示す図。

【図18】第３実施形態においてユーザの通信端末に表示されるウェブページを例示する図。

【図19】ゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。

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

【0028】

（１）第１実施形態
以下、本発明の第１実施形態について説明する。なお、本実施形態の説明において、モンスターカードはオブジェクトの一例である。

【0029】

（１−１）ゲームシステムの構成
図１は、第１実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。
このゲームシステムにおいて、ゲームサーバ２０は、クライアントである通信端末１０と通信可能に構成されており、通信端末１０に対してゲーミングサービスを提供する。ゲームサーバ２０には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と有線又は無線で接続される。なお、ゲームサーバ２０とデータベースサーバ３０は、通信網ＮＷを介して接続しても良い。
通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末１０上でウェブページに対する操作を行うことにより、ゲームを実行する。

【0030】

また、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。

【0031】

（１−２）通信端末の構成
図２及び図３を参照して通信端末１０について説明する。
図２は、通信端末１０の外観の例を示す図であって、（ａ）は、例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものであり、（ｂ）は、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は、通信端末１０の内部構成を示すブロック図である。
図３に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、指示入力部１５、表示部１６、及び、信号送受信部としての通信インタフェース部１７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１８が設けられている。

【0032】

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

【0033】

ウェブブラウザは、ゲームサーバ２０とＨＴＴＰ(HyperText Transfer Protocol)に従った通信を行う。ウェブブラウザは、ゲームサーバ２０から取得したＨＴＭＬデータを解釈して、画像処理部１４を介してウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、ウェブページの更新のために、その選択結果に応じたＨＴＴＰリクエストをゲームサーバ２０に送信する。

【0034】

画像処理部１４は、ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて、表示部１６にウェブページを表示する。表示部１６は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。

【0035】

通信端末１０が釦入力方式の通信端末（図２（ａ）に示す）である場合、指示入力部１５は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群１５ａ、及び、テンキーなどの複数の指示入力釦を含む釦群１５ｂを備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部１６に表示されているウェブページをスクロールして表示することをＣＰＵ１１へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示（例えば強調表示）されている１つのハイパーリンクまたはメニューをユーザが選択することをＣＰＵ１１へ指示するために設けられる。なお、通信端末１０を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末１０を片手で保持したままその親指で操作（クリック）しやすいように、通信端末１０の前面に配置されていることが好ましい。図２（ａ）に示す例では、釦群１５ｂは、釦群１５ａの下方に配置され、「０」〜「９」、「＊」、「＃」（テンキー）が表記された複数の指示入力釦を含む。

【0036】

通信端末１０がタッチパネル入力方式の通信端末（図２（ｂ）に示す）である場合、指示入力部１５は、主として表示画面１６ａに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図２（ｂ）に示すように、通信端末１０がタッチパネル入力方式の場合であっても釦群１５ａが設けられる場合もある。

【0037】

通信端末１０に表示されるウェブページ上のメニューの選択操作は、例えば通信端末１０が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末１０がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面１６ａ上のメニューの位置を指あるいはペンで指示（タッチ操作）することによって行われる。

【0038】

（１−３）ゲームサーバの構成
図４を参照してゲームサーバ２０の構成について説明する。
ゲームサーバ２０は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末１０に対してゲームのウェブサービスを提供する。図４に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、及び、通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

【0039】

ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するアプリケーションプログラムが格納されている。ＲＯＭ２２には、アプリケーションプログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
ＣＰＵ２１は、ＲＯＭ２２内のゲームプログラムをＲＡＭ２３にロードして実行し、通信インタフェース部２５を介して、各種の処理を行う。

【0040】

例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、ゲームサーバ２０のウェブブラウザとの間でＨＴＴＰに従った通信を行う。例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、通信端末１０から受信したＨＴＴＰリクエスト（例えば、ウェブページ上でのユーザのハイパーリンクまたはメニューの選択結果を含む。）に基づいて所定のデータ処理や、演算処理を行い、その処理結果を含むＨＴＴＰレスポンスをゲームサーバ２０のウェブブラウザに返す。ＨＴＴＰレスポンスには、ウェブページを更新するためのＨＴＭＬデータが含まれる。また、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

【0041】

（１−４）データベースサーバの構成
データベースサーバ３０（記憶装置）は、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

【0042】

本実施形態のゲームのタイプは特に限定されるものではないが、以下では、実施形態のゲームの一例として、モンスターカードを用いたデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）を採り上げる。このゲームは、ユーザが、モンスターが描かれたデジタルカード（モンスターカード）を入手することによって自らのチーム（カードデッキ）を作り上げ、他のユーザのチームとバトルを行うように構成されている。
このゲームは、例えば、以下の処理を含む。
・バトル処理：
他のユーザのチームとバトルを行う処理である。なお、バトル処理については、ここでは詳しく述べないが、例えばチームに含まれるモンスターカードの能力を示すパラメータ（例えば、攻撃力、防御力を示す値）の大小に応じて、バトルの結果が決定されるように構成される。例えば、バトルを行う２人のユーザのうちチームに含まれるモンスターカードのパラメータの合計値の大きいユーザが、バトルに勝利する可能性が高くなるように設定されてもよい。また、ユーザがバトルに勝利すればポイント（後述する）が増加する。
なお、本実施形態では、ユーザ間でバトルを行う場合を一例として説明しているが、ユーザの対戦相手は、例えばＣＰＵ２１によって任意に抽出された複数のモンスターカードからなるチームであってもよい。
・抽選処理：
ユーザが、抽選によってモンスターカードを入手する処理である。本実施形態のゲームにおいて、ユーザは、ゲームで用意される全てのモンスターカードのうち所定数のモンスターカードを含む抽選ボックスを保有することができる。ユーザは、抽選処理において、抽選ボックスに含まれるモンスターカードの中から抽選されたモンスターカードを入手することができる。
なお、抽選処理では、ユーザがモンスターカードの抽選を行うごとに、所定量のポイント（後述する）を消費するようにしてもよい。また、ユーザは、複数の抽選ボックスを保有できるようにしてもよい。
・抽選ボックス購入処理：
ユーザが、他のユーザの保有する抽選ボックスを購入するための処理である。抽選ボックスの販売価格（対価）は、例えば、抽選ボックスを販売するユーザによって任意に設定され得る。

【0043】

図６に、本実施形態のゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名／表示画像、進行レベル、ポイント、仲間のユーザＩＤ、保有カードの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

【0044】

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・進行レベル
ゲーム上のユーザの進行レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・ポイント
本実施形態のゲームにおいて、抽選ボックス購入処理を実行する上で必要となるポイントである。ポイントは、例えば、ユーザが、ゲーム提供者等に所定の方法で実際の金銭を支払うことでその支払額に応じて増加してもよいし、他のユーザとのバトルに勝利した場合に所定量増加してもよい。
・仲間のユーザＩＤ
例えば仲間になるための申請などを契機として、ユーザと関連付けられた他のユーザ（仲間）のユーザＩＤのリストである。
・保有カード
ユーザがゲーム上保有するモンスターカードの識別コード（図の例では、「ＭＣ００１」や「ＭＣ０１０」等）のリストである。

【0045】

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、例えば他のユーザとのバトルの結果についての情報（例えば勝敗等）などを含む。
また、ゲームデータベース３２は、上述した各種処理に関連して、モンスターカードデータベース及び抽選ボックスデータを記憶する。

【0046】

モンスターカードデータベースは、本実施形態のゲームで用意される複数のモンスターカード（オブジェクト）の情報が記述されているデータベースである。ここで、「オブジェクト」は、選択対象となり得るものであれば如何なるものでもよく、例えばゲーム上のアイテムやキャラクタを含んでもよい。キャラクタとは、例えば現実世界に存在するもの（例えばスポーツ選手や歌手、アイドル、動物等）を模したものや、ゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
図７は、モンスターカードデータベースのデータ構成の一例を示す図である。図７に例示するモンスターカードデータベースは、モンスターカードの識別コード（図の例では、ＭＣ００１，ＭＣ００２，…）ごとに、対象となるモンスターカードの画像データ（画像）、対象となるモンスターの名前（モンスター名）及び対象となるモンスターカードの属性（図の例では、攻撃力や防御力などのモンスターの能力を示すパラメータ及びレア度）の各項目のデータを含む。例えば、攻撃力や防御力などのパラメータが大きいほど、モンスターカードに対応するモンスターの能力が高いことを示すように設定されてもよい。
また、レア度は、モンスターカードの希少価値の度合を示す値であり、例えば、その値が高い（つまり、希少価値が高い）ほど、ゲーム内で出現する確率が低く設定されてもよい。例えば、レア度を１〜５の５段階で表した場合、能力の際立ったモンスターや人気のあるモンスターに対応するモンスターカードのレア度が高く（例えば、４あるいは５など）設定されてもよい。
なお、属性は、例えば、オブジェクトの特徴や性質などを示す情報であってもよいし、オブジェクトの特徴や性質などを分類するための情報であってもよい。例えば、野球ゲームの場合、属性には、ゲーム上の選手（オブジェクト）のチームや、ポジション（例えば投手、捕手、一塁手、左翼手など）などが含まれてもよい。

【0047】

抽選ボックスデータは、ユーザが保有する抽選ボックスに関する情報が記述されているデータである。抽選ボックスデータのデータ構成例を図８に示す。図８に示す抽選ボックスデータは、ユーザＩＤごとに、複数の抽選ボックスのデータが含まれている。複数の抽選ボックスのデータの各々には、抽選ボックスの識別情報（抽選ボックスＩＤ）ごとに、複数のモンスターカード（図の例では識別コード）と、各モンスターカードに対応する複数の付与フラグと、抽選ボックスの販売価格とが含まれる。付与フラグは、対応するモンスターカードがユーザに付与されたか否かを示す情報である。例えば、モンスターカードがユーザに付与された場合、当該モンスターカードに対応する付与フラグには「１」が設定され、モンスターカードがユーザに付与されていない場合、当該モンスターカードに対応する付与フラグには「０」が設定される。また、販売価格の内容は、抽選処理において例えばユーザにより設定又は更新され得る。
なお、ユーザが抽選ボックスを保有していない場合、当該ユーザのユーザＩＤに対応する抽選ボックスのデータには、例えばＮＵＬＬデータが記録されてもよい。
また、ここでは、複数のユーザの各々に対して複数の抽選ボックスのデータが対応付けられている場合を一例として説明したが、この場合に限られない。例えば、複数のユーザからなるグループ（チーム）に対して一又は複数の抽選ボックスのデータが対応付けられてもよい。

【0048】

（１−５）ゲーム制御装置における各機能の概要
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述したゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図９を参照して説明する。図９は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、図９の機能ブロック図において、対応付け手段５３、選択手段５４、解除手段５５及び更新手段５８が本発明の主要な構成に対応している。その他の手段（つまり、登録手段５１、実行手段５２、設定手段５６、提示手段５７）は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成要素である。
また、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネルの操作によるウェブページのスクロール操作によって変化しうる。

【0049】

登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの要求を認識し、登録処理（ユーザ登録）を行う機能を備える。
登録手段５１の機能は、例えば以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して通信端末１０から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作やユーザが指定するユーザＩＤやパスワード等のテキスト入力等）によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末１０を特定するための情報（例えば、ＵＩＤ（Unique Identifier）などの端末の個体識別情報、ＩＰアドレス、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。
ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
登録が完了すると、ＣＰＵ２１は、ユーザＩＤに対応するユーザデータを生成し、ユーザデータベース３１に格納する。登録が完了すると、ユーザは、本実施形態のゲームを実行することが可能となる。

【0050】

実行手段５２は、本実施形態のゲームを実行する機能を備える。例えば、実行手段５２は、通信端末１０に対するユーザのウェブページ上の選択操作に応じてＨＴＴＰリクエストを受信し、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータ（つまり、ＨＴＴＰレスポンス）を送信することで、ウェブサービスにより本実施形態のゲームを実行する。

【0051】

また、実行手段５２は、ユーザが本実施形態のゲームを実行するに当たって、ユーザのログイン時の認証処理を実行する機能を備えてもよい。
この機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、各ユーザの通信端末１０からのＨＴＴＰリクエストを受信すると、当該ＨＴＴＰリクエストから個体識別情報、あるいはユーザＩＤ及びパスワードを取得し、その個体識別情報、あるいはユーザＩＤ及びパスワードを、例えばユーザデータベース３１に記録済みのデータと照合して認証処理を行う。

【0052】

実行手段５２は、ゲームで実行される複数の処理が各々割り当てられた複数のメニューを通信端末１０に表示させる。具体的には、ＣＰＵ２１は、複数のメニューを含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。そして、ＣＰＵ２１は、通信端末１０においてウェブページ上のメニューが選択されたときに、選択されたメニューについての情報を通信端末１０から受信し、受信した情報に基づいて、選択されたメニューに割り当てられた処理を実行する。

【0053】

実行手段５２によって通信端末１０に表示されるゲームのトップページの例を図１０のＰ１に示す。トップページＰ１は、個々のユーザＩＤに応じたウェブページで構成される。トップページＰ１は、モンスター画像表示領域１０１、ユーザデータ表示領域１０２及びメニュー表示領域１０３を含む。
モンスター画像表示領域１０１は、対象となるユーザＩＤのユーザデータに含まれる複数のモンスターカードのうちユーザによって予め指定されたモンスターカードに対応する画像が表示される領域である。
ユーザデータ表示領域１０２は、対象となるユーザＩＤのユーザデータに含まれる、進行レベル（図の例では、レベル）、ポイントの各項目のデータ（図６参照）が表示される領域である。
メニュー表示領域１０３は、本実施形態のゲームに設けられる複数の処理（バトル処理、抽選処理、抽選ボックス購入処理）に対応したメニューとして、「バトル」、「抽選」、「抽選ボックス購入」の各メニューｍ１〜ｍ３が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末１０に表示されるウェブページの所定の位置にそれぞれ配置される。

【0054】

例えば、トップページＰ１をユーザの通信端末１０に表示する場合について、実行手段５２の機能は以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、データベースアクセス部２４を介してユーザデータベース３１にアクセスし、対応するユーザのユーザデータのうちユーザデータ表示領域１０２に含まれる各項目のデータを読み出す。また、ＣＰＵ２１は、モンスターカードデータベースにアクセスし、モンスター画像表示領域１０１に表示すべきモンスターカードの画像データを読み出す。次にＣＰＵ２１は、図１０のＰ１に示すトップページが構成されるようにＨＴＭＬデータを生成し、ユーザの通信端末１０宛に送信する。この場合、生成されるＨＴＭＬデータは、ユーザごと（つまり、ユーザＩＤごと）に異なるものとなる。ユーザの通信端末１０は、受信したＨＴＭＬデータを解釈してトップページの画像を表示部１６（表示画面１６ａ）に表示する。

【0055】

また、実行手段５２は、後述する選択手段５４、解除手段５５及び設定手段５６と協働して、本実施形態のゲームにおける抽選処理を実行する機能を備える。
［抽選処理］
抽選処理は、ユーザが、抽選によってモンスターカードを入手する処理である。

【0056】

実行手段５２が抽選処理を実行する機能は、例えば以下のとおり実現される。なお、ここでは、「ＫＮＭ」というユーザ（以下、ユーザ：ＫＮＭと表記する。）がゲームを実行する場合を一例として説明する。
ゲームサーバ２０のＣＰＵ２１は、ユーザ：ＫＮＭの通信端末１０のトップページＰ１上でメニューｍ２が選択操作されたことを認識すると、図１０のＰ２に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＫＮＭの通信端末１０に送信する。ウェブページＰ２には、ユーザ：ＫＮＭの保有する抽選ボックスに含まれるモンスターカードについてのユーザ：ＫＮＭの取得状況に関する情報と、抽選ボックスの中から抽選によってモンスターカードを入手するための「カードを取得」と表記されたメニューｍ４と、抽選ボックスの内容を確認するための「内容を確認」と表記されたメニューｍ５と、などが含まれる。取得状況に関する情報は、例えば、モンスターカードのレア度ごとに、ユーザ：ＫＮＭによるモンスターカードの取得数が対応付けられて表示されるように構成されてもよい。ここで、ウェブページＰ２に例示するように、取得状況に関する情報が「０／２」と表記されている場合、対象となるレア度に属するモンスターカードのユーザによる取得数が０であり、対象となるレア度に属するモンスターカードのユーザに対する付与可能数が２であることを示している。

【0057】

ウェブページＰ２の表示に当たって、ＣＰＵ２１は、ユーザ：ＫＮＭによってメニューｍ２が選択操作されたことを認識すると、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する抽選ボックスのデータを抽出する。また、ＣＰＵ２１は、モンスターカードデータベースにアクセスして、抽出したデータに含まれる複数のモンスターカード（識別コード）の各々に対応するレア度を取得する。さらに、ＣＰＵ２１は、抽選ボックスに含まれるモンスターカードの数をレア度ごとにもとめる。次いで、ＣＰＵ２１は、ユーザ：ＫＮＭによるモンスターカードの取得数（つまり、抽出した付与フラグが「１」に設定されたモンスターカードの数）をレア度ごとにもとめる。そして、ＣＰＵ２１は、もとめた数をウェブページに含むようにＨＴＭＬデータを生成する。
なお、ユーザ：ＫＮＭが複数の抽選ボックスを保有している場合、ＣＰＵ２１は、例えば、メニューｍ２が選択操作されると、ユーザ：ＫＮＭの保有する複数の抽選ボックスのうちいずれかの抽選ボックスをユーザ：ＫＮＭが選択するためのウェブページ用のＨＴＭＬデータを生成して、ユーザ：ＫＮＭの通信端末１０に送信してもよい。そして、ＣＰＵ２１は、ウェブページ上でユーザ：ＫＮＭによって抽選ボックスが選択されたことを認識すると、選択された抽選ボックスに含まれるモンスターカードについてのユーザ：ＫＮＭの取得状況に関する情報を通知するウェブページ（例えば、Ｐ２に例示するウェブページ）を表示するためのＨＴＭＬデータを生成して、ユーザ：ＫＮＭの通信端末１０に送信する。

【0058】

ＣＰＵ２１は、ウェブページＰ２上でメニューｍ４が選択されると、後述する選択手段５４の機能に基づいて、抽選ボックスに含まれるモンスターカードの中からユーザ：ＫＮＭに付与される付与モンスターカード（付与オブジェクト）を選択する。そして、ＣＰＵ２１は、付与モンスターカードを選択すると、実行手段５２の機能に基づいて、付与モンスターカードをユーザ：ＫＮＭに付与する処理を行う。この処理について具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する保有カードの項目に対して、付与モンスターカードの識別コードを記録する。
次に、ＣＰＵ２１は、図１０のＰ３に例示するウェブページを表示するためのＨＴＭＬデータを生成してユーザ：ＫＮＭの通信端末１０に送信する。ウェブページＰ３には、付与モンスターカードに関する情報（図の例では、付与モンスターカードの画像データ、モンスター名及びレア度）が表示される。ウェブページＰ３の表示に当たって、ＣＰＵ２１は、選択手段５４の機能に基づいて付与モンスターカードを選択すると、モンスターカードデータベースにアクセスして、付与モンスターカードの識別コードに対応する画像データ、モンスター名及びレア度などを抽出する。そして、ＣＰＵ２１は、抽出した画像データ、モンスター名（図の例では、モンスターＣ）及びレア度（図の例では、４）などをウェブページに含むようにＨＴＭＬデータを生成する。
なお、ＣＰＵ２１は、ウェブページＰ３を表示するためのＨＴＭＬデータをユーザ：ＫＮＭの通信端末１０に送信すると、後述する解除手段５５の機能に基づいて、付与モンスターカードとユーザ：ＫＮＭとの対応付けを解除する処理を行う。これにより、ユーザ：ＫＮＭの抽選ボックスから付与モンスターカードが除かれることになる。

【0059】

次に、ユーザ：ＫＮＭが抽選を複数回行う（メニューｍ４の選択操作を複数回行う）ことにより、複数の付与モンスターカードがユーザ：ＫＮＭに付与された場合を想定する。この場合、ＣＰＵ２１は、トップページＰ１上でメニューｍ２が選択操作されたことを認識すると、図１０のＰ４に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＫＮＭの通信端末１０に送信する。ウェブページＰ４の構成は、ユーザ：ＫＮＭによるモンスターカードの取得状況が異なる点を除いて、ウェブページＰ２の構成と同様である。
ウェブページＰ４上でメニューｍ５が選択操作されると、ＣＰＵ２１は、図１０のＰ５に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＫＮＭの通信端末１０に送信する。ウェブページＰ５には、抽選ボックスに含まれるモンスターカードのデータ（図の例では、モンスター名）がレア度ごとに含まれる。また、ウェブページＰ５には、抽選ボックスを販売することを指示するための「抽選ボックスを販売」と表記されたメニューｍ６が含まれる。なお、ウェブページＰ５では、ユーザ：ＫＮＭに付与された付与モンスターカードのデータと、ユーザ：ＫＮＭに付与されていないモンスターカードのデータの各々が、ユーザ：ＫＮＭによって認識し得る態様で表示されてもよい。例えば、ウェブページＰ５に例示するように、付与モンスターカードのデータ（図の例では、モンスター名）には取り消し線が付されてもよい。また、例えば、抽選ボックスに含まれるモンスターカードのうちユーザ：ＫＮＭに付与されていないモンスターカード（つまり、付与フラグが「０」に設定されたモンスターカード）のデータのみが表示されてもよい。

【0060】

ウェブページＰ５の表示に当たって、ＣＰＵ２１は、メニューｍ５が選択操作されると、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する抽選ボックスのデータを抽出する。また、ＣＰＵ２１は、モンスターカードデータベースにアクセスして、抽出したデータに含まれるモンスターカード（識別コード）ごとに、対応するモンスター名及びレア度を取得する。そして、ＣＰＵ２１は、取得したモンスター名をレア度に応じて配置するようにＨＴＭＬデータを生成する。なお、ＣＰＵ２１は、抽出したモンスターカードのうち、ユーザ：ＫＮＭに対する付与モンスターカード（つまり、付与フラグが「１」に設定されたモンスターカード）のモンスター名に取り消し線を付してもよい。

【0061】

ウェブページＰ５上でメニューｍ６の選択操作が行われると、ＣＰＵ２１は、図１０のＰ６に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＫＮＭの通信端末１０に送信する。ウェブページＰ６には、抽選ボックスの販売価格を入力するためのテキストボックス１０４と、販売価格を設定するための「設定」と表記されたメニューｍ７が含まれる。
ＣＰＵ２１は、メニューｍ７が選択操作されると、後述する設定手段５６の機能に基づいて、抽選ボックスの販売価格を設定する処理を行う。

【0062】

対応付け手段５３は、ユーザと複数のモンスターカード（オブジェクト）とを対応付ける機能を備える。
ここで、「対応付ける」とは、例えば、ユーザのユーザＩＤ（識別情報）とモンスターカード（オブジェクト）に関する情報（例えば識別情報など）とを連結する（リンクする）ことであってもよいし、ユーザＩＤに対応付けられたモンスターカード用のデータファイルに対してモンスターカードに関する情報を記憶することであってもよいし、ユーザＩＤに対応付けられたモンスターカードの数を増加させることであってもよい。また、ユーザＩＤ及び／又はカード情報は、外部の記憶装置に記憶されてもよい。さらに、ユーザＩＤとカード情報とを連結する情報（リンク情報）は、外部の記憶装置に記憶されてもよい。

【0063】

対応付け手段５３の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、例えばユーザ：ＫＮＭの通信端末１０のトップページＰ１上でメニューｍ２が選択操作されたことを認識すると、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭが抽選ボックスを保有しているか否かを判別する。例えば、ユーザ：ＫＮＭのユーザＩＤに対応する抽選ボックスのデータにＮＵＬＬデータが記録されている場合には、ＣＰＵ２１は、ユーザ：ＫＮＭが抽選ボックスを保有していないと判別してもよい。一方、ユーザ：ＫＮＭのユーザＩＤに対応する抽選ボックスのデータにＮＵＬＬデータ以外のデータが記録されている場合には、ＣＰＵ２１は、ユーザ：ＫＮＭが抽選ボックスを保有していると判別して、上述した実行手段５２の機能に基づき抽選処理を実行してもよい。
ＣＰＵ２１は、ユーザ：ＫＮＭが抽選ボックスを保有していないと判別した場合、抽選ボックスに含まれる複数のモンスターカードをユーザ：ＫＮＭに対応付ける処理を行う。この処理の内容について具体的に説明すると、ＣＰＵ２１は、先ず、モンスターカードデータベースにアクセスして、抽選ボックスに含まれる複数のモンスターカードの各々の識別コードを任意に抽出する。ここで、例えば、複数の属性（例えばレア度）ごとに付与可能数が予め設定されている場合には、ＣＰＵ２１は、当該設定に応じて、複数のモンスターカードの識別コードを抽出してもよい。次に、ＣＰＵ２１は、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する抽選ボックスＩＤの項目に対して、例えば任意に決定した抽選ボックスＩＤを記録する。さらに、ＣＰＵ２１は、記録した抽選ボックスＩＤに対応するカード情報の項目に対して、モンスターカードデータベースから抽出した複数の識別コードを記録する。また、ＣＰＵ２１は、記録した識別コードの各々に対応する付与フラグの項目に「０」を設定する。このようにして、ユーザ：ＫＮＭと複数のモンスターカードとが対応付けられる。

【0064】

なお、ここでは、ユーザ：ＫＮＭが抽選ボックスを保有していないと判別したときに、所定数のモンスターカードをユーザ：ＫＮＭに対応付ける場合を一例として説明したが、複数のモンスターカードをユーザ：ＫＮＭに対応付けるタイミングは、この場合に限られず、任意のタイミング、あるいは所定の条件を満たしたタイミングであってもよい。例えば、トップページＰ１上に抽選ボックスの取得を指示するためのメニューが設けられている場合には、ＣＰＵ２１は、当該メニューが選択操作されたことを認識すると、抽選ボックスに含まれる複数のモンスターカードをユーザ：ＫＮＭに対応付ける処理を行ってもよい。
また、ＣＰＵ２１は、抽選ボックスを取得するための対価が支払われたこをと条件として、複数のモンスターカードをユーザ：ＫＮＭに対応付けてもよい。例えば、抽選ボックスを取得するための対価が所定量のポイントである場合を一例として説明すると、ＣＰＵ２１は、抽選ボックスをユーザ：ＫＮＭに対応付ける処理に先立って、ユーザデータベース３１にアクセスする。そして、ＣＰＵ２１は、ユーザ：ＫＮＭのユーザＩＤに対応するポイントの値が所定量以上である場合には、当該ユーザＩＤに対応するポイントの値を所定量減算した後に、抽選ボックスに含まれる複数のモンスターカードをユーザ：ＫＮＭに対応付ける処理を行えばよい。

【0065】

選択手段５４は、ユーザの入力に関する情報に基づいて、前記ユーザに対応付けられた複数のモンスターカード（オブジェクト）の中から前記ユーザに付与される付与モンスターカード（付与オブジェクト）を選択する機能を備える。
選択手段５４の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、図１０のウェブページＰ２上でメニューｍ４が選択操作されると、抽選ボックスデータにアクセスし、ユーザ：ＫＮＭのユーザＩＤに対応する複数のモンスターカード（識別コード）のうち付与フラグが「０」に設定されたモンスターカードの中から少なくとも１つのモンスターカードをランダムに、あるいは所定の規則に基づいて抽出する。なお、ユーザ：ＫＮＭが複数の抽選ボックスを保有している場合には、例えば、ユーザ：ＫＮＭによって選択された抽選ボックスに対応する複数のモンスターカードの中から少なくとも１つのモンスターカードが抽出されてもよい。そして、ＣＰＵ２１は、抽出したモンスターカードを付与モンスターカードとして特定（選択）する。

【0066】

解除手段５５は、付与モンスターカード（付与オブジェクト）を選択した場合に、ユーザと付与モンスターカード（付与オブジェクト）との対応付けを解除する機能を備える。
ここで、「対応付けを解除する」とは、例えば、ユーザのユーザＩＤ（識別情報）に対応付けられたモンスターカード（オブジェクト）に関する情報（例えば識別情報など）に対して、対応付けを解除するためのデータを連結（リンク）あるいは追加などすることであってもよいし、ユーザＩＤとモンスターカードに関する情報との連結を断つことであってもよい。また、「対応付けを解除する」とは、例えば、ユーザＩＤに対応付けられたモンスターカード用のデータファイルからモンスターカードに関する情報を消去することであってもよいし、ユーザＩＤに対応付けられたモンスターカードの数を減少させることであってもよい。また、ユーザＩＤ及び／又はモンスターカードに関する情報が外部の記憶装置に記憶されている場合には、ユーザＩＤ及び／又はモンスターカードに関する情報を当該記憶装置から消去することであってもよい。さらに、ユーザＩＤとモンスターカードに関する情報とを連結する情報（リンク情報）が外部の記憶装置に記憶されている場合には、当該情報を当該記憶装置から消去することであってもよい。また、「対応付けを解除する」とは、付与モンスターカードが選択手段５４によって再度選択されることを制限することであってもよい。
解除手段５５の機能は、例えば以下のようにして実現される。なお、ここでは、ユーザＩＤに対応付けられたモンスターカードに関する情報に対して、対応付けを解除するためのデータを連結あるいは追加などすることによって、対応付けを解除する場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、上述した実行手段５２の機能に基づいて、ウェブページＰ３を表示するためのＨＴＭＬデータをユーザ：ＫＮＭの通信端末１０に送信すると、付与モンスターカードとユーザ：ＫＮＭとの対応付けを解除する処理を行う。この処理の内容について具体的に説明すると、ＣＰＵ２１は、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する複数のモンスターカードのうち、付与モンスターカードとして選択されたモンスターカードの識別コードに対応する付与フラグを「１」に設定する。

【0067】

設定手段５６は、抽選ボックスの販売価格（所定の対価）を設定する機能を備える。
ここで、「対価」とは、例えば、ユーザが保有するゲーム上のポイントなどであってもよいし、所定のアイテムやキャラクタなどであってもよい。
設定手段５６の機能は、例えば以下のようにして実現される。なお、ここでは、ポイントを対価として用いる場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、図１０のウェブページＰ６上でメニューｍ７が選択操作されると、抽選ボックスの販売価格を設定する処理を行う。この処理の内容について具体的に説明すると、ＣＰＵ２１は、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する販売価格の項目に対して、ウェブページＰ６上のテキストボックス１０４に入力された情報を記録する。これにより、テキストボックス１０４に入力された情報が販売価格として設定される。
なお、設定手段５６は、ユーザに対応付けられた複数のモンスターカードのうち付与モンスターカードを除くモンスターカードの数が同じ場合には、販売価格を複数回設定してもよい。つまり、ユーザが抽選によってモンスターカードを取得するまでの間、販売価格を変更できるようにしてもよい。この場合、ＣＰＵ２１は、ウェブページＰ６上でメニューｍ７が選択操作されるごとに、抽選ボックスデータにアクセスして、ユーザのユーザＩＤに対応する販売価格の項目に記録されたデータを更新してもよい。

【0068】

また、設定手段５６は、ユーザに対応付けられた複数のモンスターカードのうち付与モンスターカードを除くモンスターカードの数が異なる場合に、販売価格を設定してもよい。例えば、ユーザが抽選によってモンスターカードを取得するごとに（つまり、ユーザと付与モンスターカードとの対応付けが解除されるごとに）、販売価格を設定できるようにしてもよい。これにより、ユーザは、抽選ボックス内のモンスターカードの取得状況に応じて、異なる販売価格を設定することが可能となる。この場合、ＣＰＵ２１は、例えば、解除手段５５の機能に基づいて付与モンスターカードとユーザとの対応付けを解除する処理を行う場合に、当該処理の実行に先立って、抽選ボックスデータにアクセスして、当該処理の対象となる抽選ボックスのデータ（抽選ボックスＩＤ、複数のモンスターカード、複数の付与フラグ、販売価格）と同じデータを当該ユーザのユーザＩＤに対応付けて追記する。また、ＣＰＵ２１は、当該処理の実行後に、当該処理の対象となる抽選ボックスの販売価格の項目に対してＮＵＬＬデータを記録する。これにより、ユーザが抽選によってモンスターカードを取得した後には、抽選ボックスの販売価格が設定されていない状態となる。ユーザは、ウェブページＰ６上でメニューｍ７を選択操作することにより、モンスターカードを取得した後の抽選ボックスの販売価格を設定することができる。

【0069】

なお、ここでは、ユーザ：ＫＮＭがテキストボックス１０４に入力した情報が販売価格として設定される場合を一例として説明したが、この場合に限られない。例えば、設定手段５６は、所定の入力を契機とせずに（つまり、自動的に）、販売価格を設定してもよい。具体的には、設定手段５６は、ユーザに対応付けられた複数のモンスターカードのうち、付与モンスターカード以外のモンスターカード（つまり、ユーザに付与されていないモンスターカード）に関する情報（例えば、属性に関する情報）に基づいて、販売価格を設定してもよい。この場合、ＣＰＵ２１は、例えば、実行手段５２の機能に基づいて付与モンスターカードをユーザに付与する処理を行った場合に、販売価格を設定する処理を行ってもよい。例えば、ユーザに付与されていないモンスターカード（つまり、付与フラグに「０」が設定されたモンスターカード）のうちレア度の高いモンスターカードの数あるいは割合が多いほど、販売価格が高くなるように設定してもよい。この場合、所定の対価は、所定の演算式を用いて、例えばユーザに付与されていないモンスターカードのレア度ごとの数あるいは割合を当該演算式に当てはめることによって算出されてもよい。

【0070】

提示手段５７は、移転元ユーザ（第１ユーザ）に対応付けられた複数のモンスターカード（オブジェクト）のうちいずれかの付与モンスターカード（付与オブジェクト）を除くモンスターカードに関する情報を移転先ユーザ（第２ユーザ）に提示する機能を備える。
提示手段５７をゲーム制御装置に設けることにより、移転先ユーザは、移転元ユーザに対応付けられた複数のモンスターカードのうち、少なくとも移転元ユーザに付与されていないモンスターカードを認識することができる。ここで、例えば、移転元ユーザに付与されていないモンスターカードの中に移転先ユーザの所望するモンスターカードが含まれている場合には、移転先ユーザは、所望のモンスターカードを抽選によって得るために、移転元ユーザに対応付けられた複数のモンスターカードをいずれかの付与モンスターカードを除いた状態で自身に対応付ける（保有する）ように動機付けられる。
また、提示手段５７は、後述する更新手段５８と協働して、本実施形態のゲームにおける抽選ボックス購入処理を実行する機能を備える。
［抽選ボックス購入処理］
抽選ボックス購入処理は、ユーザが、他のユーザの保有する抽選ボックスを購入するための処理である。

【0071】

提示手段５７が抽選ボックス購入処理を実行する機能は、例えば以下のとおり実現される。なお、ここでは、「ＡＢＣ」というユーザ（以下、ユーザ：ＡＢＣと表記する。）がユーザ：ＫＮＭの抽選ボックスを購入する場合を一例として説明する。つまり、この場合には、ユーザ：ＫＮＭが移転元ユーザとなり、ユーザ：ＡＢＣが移転先ユーザとなる。
ゲームサーバ２０のＣＰＵ２１は、図１１のＰ１１に例示するトップページ上でユーザ：ＡＢＣがメニューｍ３を選択操作したことを認識すると、抽選ボックスデータにアクセスして、ＮＵＬＬデータ以外の販売価格が設定された抽選ボックスのデータを、ユーザＩＤごとに抽出する。
次に、ＣＰＵ２１は、図１１のＰ１２に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。ウェブページＰ１２には、抽選ボックスの販売価格を設定したユーザごとに、当該抽選ボックスの販売価格と、当該抽選ボックスに含まれるモンスターカードのレア度ごとの数と、抽選ボックスの購入を指示するための「購入」と表記されたメニューｍ１０と、抽選ボックスの内容を確認するための「内容を確認」と表記されたメニューｍ１１とが含まれる。ここで、抽選ボックスに含まれるモンスターカードのレア度ごとの数は、販売価格を設定したユーザに付与されていないモンスターカードのレア度ごとの数を示している。
ウェブページＰ１２の表示に当たって、ＣＰＵ２１は、抽選ボックスデータにアクセスして、ＮＵＬＬデータ以外の販売価格が設定された抽選ボックスＩＤごとに、付与フラグが「０」に設定されたモンスターカード（つまり、販売価格を設定したユーザに付与されていないモンスターカード）を抽出する。また、ＣＰＵ２１は、モンスターカードデータベースを参照して、抽出したモンスターカードごとにレア度を取得する。さらに、ＣＰＵ２１は、抽出したモンスターカードのレア度ごとの数（付与可能数）をもとめる。そして、ＣＰＵ２１は、もとめた数と販売価格などをウェブページに含むようにＨＴＭＬデータを生成する。

【0072】

次に、ＣＰＵ２１は、ウェブページＰ１２上でユーザ：ＡＢＣがメニューｍ１０を選択操作したことを認識すると、後述する更新手段５８の機能に基づいて、選択操作されたメニューｍ１０に対応するユーザの抽選ボックスを購入する処理を行う。
また、ＣＰＵ２１は、ウェブページＰ１２上でユーザ：ＫＮＭに対応するメニューｍ１１が選択操作されたことを認識すると、図１１のＰ１３に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。ウェブページＰ１３には、ユーザ：ＫＮＭの抽選ボックスに含まれるモンスターカードのデータ（図の例では、モンスター名）がレア度ごとに含まれる。ここで、ウェブページＰ１３には、ユーザ：ＫＮＭの抽選ボックスに含まれるモンスターカードのうち、少なくともユーザ：ＫＮＭに付与されていないモンスターカードのデータ（モンスター名）が表示される。
ウェブページＰ１３の表示に当たって、ＣＰＵ２１は、メニューｍ１１が選択操作されると、抽選ボックスデータにアクセスして、選択操作されたメニューｍ１１に対応するユーザ（ここでは、ユーザ：ＫＮＭ）のユーザＩＤに対応する抽選ボックスのデータを抽出する。また、ＣＰＵ２１は、モンスターカードデータベースにアクセスして、抽出したデータに含まれる複数のモンスターカード（識別コード）のうち、付与フラグが「０」に設定されたモンスターカード（つまり、選択操作されたメニューｍ１１に対応するユーザに付与されていないモンスターカード）ごとに、対応するモンスター名及びレア度を取得する。そして、ＣＰＵ２１は、取得したモンスター名をレア度に応じて配置するようにＨＴＭＬデータを生成する。
また、ＣＰＵ２１は、ウェブページＰ１３上でユーザ：ＡＢＣがメニューｍ１２を選択操作したことを認識すると、後述する更新手段５８の機能に基づいて、ウェブページＰ１２上で選択操作されたメニューｍ１１に対応するユーザの抽選ボックスを購入する処理を行う。

【0073】

なお、ここでは、ユーザ：ＡＢＣに対して、販売価格を設定した全ての他のユーザの抽選ボックスのデータが提示される場合を一例として説明したが、この場合に限られない。例えば、移転先ユーザと移転元ユーザとの関係が所定の条件を満たす場合に、移転元ユーザの抽選ボックスのデータが移転先ユーザに提示されるようにしてもよい。ここで、所定の条件は、任意に設定することができる。例えば、移転先ユーザによるモンスターカードの選択回数（抽選回数）が所定値以上の場合に、移転元ユーザの抽選ボックスのデータが移転先ユーザに提示されるようにしてもよい。また、例えば、移転先ユーザと移転元ユーザの親密度（後述する変形例２において説明する）が所定の閾値以上の場合に、移転元ユーザの抽選ボックスのデータが移転先ユーザに提示されるようにしてもよい。

【0074】

更新手段５８は、所定の入力に関する情報に基づいて、移転元ユーザ（第１ユーザ）に対応付けられた複数のモンスターカード（オブジェクト）をいずれかの付与モンスターカード（付与オブジェクト）を除いた状態で移転先ユーザ（第２ユーザ）に対応付けるように、移転先ユーザと複数のモンスターカードとの対応付けを更新する機能を備える。
また、更新手段５８は、設定された対価が移転先ユーザ（第２ユーザ）によって支払われたことを条件として、移転元ユーザ（第１ユーザ）に対応付けられた複数のモンスターカード（オブジェクト）をいずれかの付与モンスターカード（付与オブジェクト）を除いた状態で移転先ユーザに対応付けるように、移転先ユーザと複数のモンスターカードとの対応付けを更新してもよい。
この場合、移転先ユーザは、設定された対価を支払わなければ、移転元ユーザに対応付けられた複数のモンスターカードを、いずれかの付与モンスターカードを除いた状態で自身に対応付ける（保有する）ことができない。つまり、移転先ユーザは、移転元ユーザに付与されていないモンスターカードを抽選対象としてモンスターカードの抽選を行うためには、設定された対価を支払う必要がある。このため、例えば、移転元ユーザに付与されていないモンスターカードの中に移転先ユーザの所望するモンスターカードが含まれている場合には、所望のモンスターカードを抽選によって得るために対価を支払うべきか否かなどについて移転先ユーザに慎重に検討させることができるので、移転先ユーザの判断力や戦略などが求められる仕組みとすることができる。これにより、興趣性の高いゲームを実現することができる。

【0075】

更新手段５８の機能は、例えば以下のようにして実現できる。なお、ここでは、設定された対価がユーザ：ＡＢＣ（移転先ユーザ）によって支払われたことを条件として、ユーザ：ＡＢＣと複数のモンスターカードとの対応付けを更新する場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、図１１のウェブページＰ１２上でユーザ：ＫＮＭに対応するメニューｍ１０が選択操作（所定の入力）されたこと、あるいは図１１のウェブページＰ１３上でメニューｍ１２が選択操作（所定の入力）されたことを認識すると、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するポイントの値がユーザ：ＫＮＭ（移転元ユーザ）の販売価格以上であるか否かを判別する。そして、ＣＰＵ２１は、ユーザ：ＡＢＣのポイントの値がユーザ：ＫＮＭの販売価格以上であると判別した場合には、ユーザ：ＡＢＣのポイントの値から販売価格を減算した（対価が支払われた）後に、ユーザ：ＡＢＣと複数のモンスターカードとの対応付けを更新する処理を行う。この処理の内容について具体的に説明すると、ＣＰＵ２１は、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する複数の抽選ボックスのうち、ユーザ：ＡＢＣが購入する抽選ボックスのデータ（抽選ボックスＩＤ、複数のカード情報、複数の付与フラグ）を抽出する。次に、ＣＰＵ２１は、抽出したデータを、ユーザ：ＡＢＣのユーザＩＤに対応付けて抽選ボックスデータ内に追記する。この場合、ユーザ：ＡＢＣに対応付けられる複数のモンスターカードのうち、ユーザ：ＫＮＭに付与されたモンスターカード（付与モンスターカード）に対応する付与フラグは「１」のままである。つまり、この場合には、ユーザ：ＡＢＣがユーザ：ＫＮＭから購入した抽選ボックスを用いて抽選処理を行う場合、ユーザ：ＫＮＭに付与されたモンスターカードが抽選対象から除かれた状態になる。
なお、ＣＰＵ２１は、ユーザ：ＫＮＭの抽選ボックスのデータに含まれるモンスターカードを抽出する際に、付与フラグが「１」に設定されたモンスターカードを除いて抽出してもよい。この場合、ユーザ：ＡＢＣには、ユーザ：ＫＮＭに付与されていないモンスターカード（つまり、付与フラグに「０」が設定されたモンスターカード）のみが対応付けられることになる。
また、ＣＰＵ２１は、ユーザ：ＡＢＣと複数のモンスターカードとの対応付けを更新する処理を行った後に、ユーザ：ＫＮＭのユーザＩＤに対応する複数の抽選ボックスのうち、ユーザ：ＡＢＣによって購入された抽選ボックスのデータを消去する。

【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】

本実施形態における対応付け手段５３の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、例えばユーザ：ＫＮＭの通信端末１０のトップページＰ１上でメニューｍ２が選択操作されたことを認識すると、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭが抽選ボックスを保有しているか否かを判別する。ＣＰＵ２１は、ユーザ：ＫＮＭが抽選ボックスを保有していないと判別した場合、複数のレア度（属性）ごとの付与可能数をユーザ：ＫＮＭに対応付ける処理を行う。この処理の内容について具体的に説明すると、ＣＰＵ２１は、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する抽選ボックスＩＤの項目に対して、例えば任意に決定した抽選ボックスＩＤを記録する。次に、ＣＰＵ２１は、記録した抽選ボックスＩＤに対応するレア度（属性）及び付与可能数の項目に対して、例えば予め設定された複数のレア度（属性）ごとの付与可能数を記録する。
なお、ここでは、ユーザ：ＫＮＭが抽選ボックスを保有していないと判別したときに、複数のレア度ごとの付与可能数をユーザ：ＫＮＭに対応付ける場合を一例として説明したが、複数のレア度ごとの付与可能数をユーザ：ＫＮＭに対応付けるタイミングは、この場合に限られない。例えば、トップページＰ１上に抽選ボックスの取得を指示するためのメニューが設けられている場合には、ＣＰＵ２１は、当該メニューが選択操作されたことを認識すると、複数のレア度ごとの付与可能数をユーザ：ＫＮＭに対応付ける処理を行ってもよい。

【0102】

本実施形態における選択手段５４の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、図１０のウェブページＰ２上でメニューｍ４が選択操作（所定の入力）されると、抽選ボックスデータにアクセスし、ユーザ：ＫＮＭのユーザＩＤに対応する複数のレア度（属性）の中から、対応する付与可能数が１以上の１つの属性をランダムに、あるいは所定の規則に基づいて決定する。次に、ＣＰＵ２１は、モンスターカードデータベースにアクセスして、決定した属性に属するモンスターカードの中から例えば１枚のモンスターカード（識別コード）を抽出する。そして、ＣＰＵ２１は、抽出したモンスターカードを付与モンスターカードとして特定（選択）する。

【0103】

本実施形態における変更手段６０の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、実行手段５２の機能に基づいて、ウェブページＰ３を表示するためのＨＴＭＬデータをユーザ：ＫＮＭの通信端末１０に送信すると、ユーザ：ＫＮＭについて対応付けを変更する処理を行う。この処理の内容について具体的に説明すると、ＣＰＵ２１は、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する複数の付与可能数のうち、付与モンスターカードのレア度に対応する付与可能数の値を１だけ減らす。例えば、付与モンスターカードのレア度が５であって、レア度５に対応する付与可能数が「２／２」である場合には、当該処理後の付与可能数は「１／２」となる。

【0104】

本実施形態における更新手段５８の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、例えば図１１のウェブページＰ１２上でユーザ：ＫＮＭ（移転元ユーザ）に対応するメニューｍ１０が選択操作（所定の入力）されたことを認識すると、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣ（移転先ユーザ）のユーザＩＤに対応するポイントの値がユーザ：ＫＮＭの販売価格以上であるか否かを判別する。そして、ＣＰＵ２１は、ユーザ：ＡＢＣのポイントの値がユーザ：ＫＮＭの販売価格以上であると判別した場合には、ユーザ：ＡＢＣのポイントの値から販売価格を減算した（対価が支払われた）後に、ユーザ：ＡＢＣについて対応付けを更新する処理を行う。この処理の内容について具体的に説明すると、ＣＰＵ２１は、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する複数の抽選ボックスのうち、ユーザ：ＡＢＣが購入する抽選ボックスのデータ（抽選ボックスＩＤ、複数のレア度ごとの付与可能数）を抽出する。次に、ＣＰＵ２１は、抽出したデータを、ユーザ：ＡＢＣのユーザＩＤに対応付けて抽選ボックスデータ内に追記する。

【0105】

本実施形態のゲーム制御装置によれば、ユーザは、自らの入力によって、複数のレア度のうちいずれかのレア度に属する複数のモンスターカードの中から選択（抽選）された付与モンスターカードを入手することができる。また、付与モンスターカードが選択された場合には、ユーザは、付与モンスターカードのレア度に対応する付与可能数を減らした状態でモンスターカードの抽選を繰り返し行うことが可能となる。さらに、移転先ユーザは、所定の入力によって、移転元ユーザに対応付けられたときの付与可能回数からいずれかの付与モンスターカードの数を減らした付与可能数を複数のレア度ごとに自身に対応付ける（保有する）ことができる。この場合、移転先ユーザは、複数のレア度ごとの付与可能数を移転元ユーザから引き継いだ状態でモンスターカードの抽選を行うことが可能となる。ここで、移転先ユーザは、例えば、所望のレア度に対応する付与可能数が充分な状態で複数のレア度ごとの付与可能数を移転元ユーザから引き継いだ場合、所望のレア度に属するモンスターカードを得るために、モンスターカードの抽選を行うことが動機付けられる。これにより、複数のユーザが協力してモンスターカードの抽選を楽しむことができる。

【0106】

（３）第３実施形態
以下、本発明の第３実施形態について説明する。
第３実施形態のゲーム制御装置の機能ブロック図は図１６に示したものと同様である。
本実施形態のゲームでは、例えば、ユーザが、他のユーザによるモンスターカードの取得状況に関する情報を購入する処理（以下、購入処理という）を含む。ユーザは、購入処理において他のユーザによるモンスターカードの取得状況に関する情報を購入すると、当該取得状況を自らの抽選ボックスに反映させることができる。例えば、他のユーザが抽選においてレア度４のモンスターカードを１枚、レア度３のモンスターカードを３枚入手した場合、ユーザは、自らの抽選ボックスから、レア度４の付与可能数を１つ、レア度３の付与可能数を３つ減らすことができるようになっている。
以下、第２実施形態と異なる構成について説明する。

【0107】

（３−１）ゲーム制御装置における機能の概要
本実施形態において、実行手段５２は、更新手段５８と協働して、本実施形態のゲームにおける購入処理を実行する機能を備える。実行手段５２の機能は、例えば以下のように実現される。なお、ここでは、ユーザ：ＡＢＣが、ユーザ：ＫＮＭによるモンスターカードの取得状況に関する情報を購入する場合を一例として説明する。つまり、この場合には、ユーザ：ＫＮＭが移転元ユーザとなり、ユーザ：ＡＢＣが移転先ユーザとなる。
ゲームサーバ２０のＣＰＵ２１は、ユーザ：ＡＢＣの通信端末１０のトップページ上で例えば購入処理用のメニュー（図示省略）が選択操作されたことを認識すると、抽選ボックスデータにアクセスして、ＮＵＬＬデータ以外の販売価格が設定された抽選ボックスのデータを、ユーザＩＤごとに抽出する。
次に、ＣＰＵ２１は、図１８に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。図１８のウェブページには、販売価格を設定したユーザごとに、当該抽選ボックスの販売価格と、当該ユーザによるモンスターカードの取得状況に関する情報と、当該情報の購入を指示するための「購入」と表記されたメニューｍ１０とが含まれる。ここで、レア度ごとのモンスターカードの取得数は、例えば図１７に例示する抽選ボックスデータを参照してもとめることが可能である。具体的に説明すると、例えば付与可能数が「１／２」と表記されている場合、対象となるレア度に属するモンスターカードの付与可能数がユーザに対応付けられたときの初期値（ここでは、２）から、対象となるレア度に属するモンスターカードの現在の付与可能数（ここでは、１）を引くことによって、モンスターカードの取得数（ここでは、１）がもとめられる。

【0108】

本実施形態において、更新手段５８は、所定の入力に関する情報に基づいて、移転元ユーザ（第１ユーザ）に対するいずれかの付与モンスターカード（付与オブジェクト）の数だけ当該付与モンスターカードのレア度（属性）に対応する付与可能数を減らした状態で複数のレア度ごとの付与可能数を移転先ユーザ（第２ユーザ）に対応付けるように、前記移転先ユーザについての対応付けを更新する機能を備える。
本実施形態における更新手段５８の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、例えば図１８のウェブページ上でユーザ：ＫＮＭ（移転元ユーザ）に対応するメニューｍ１０が選択操作（所定の入力）されたことを認識すると、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣ（移転先ユーザ）のユーザＩＤに対応するポイントの値がユーザ：ＫＮＭの販売価格以上であるか否かを判別する。そして、ＣＰＵ２１は、ユーザ：ＡＢＣのポイントの値がユーザ：ＫＮＭの販売価格以上であると判別した場合には、ユーザ：ＡＢＣのポイントの値から販売価格を減算した（対価が支払われた）後に、ユーザ：ＡＢＣについて対応付けを更新する処理を行う。この処理の内容について具体的に説明すると、ＣＰＵ２１は、抽選ボックスデータにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する複数の抽選ボックスのうち、ユーザ：ＡＢＣが購入する抽選ボックスのデータ（抽選ボックスＩＤ、複数のレア度ごとの付与可能数）を抽出する。次に、ＣＰＵ２１は、抽出したデータに含まれる複数のレア度ごとの付与可能数に基づいて、ユーザ：ＫＮＭによるモンスターカードの取得数を複数のレア度ごとにもとめる。そして、ＣＰＵ２１は、ユーザ：ＡＢＣのユーザＩＤに対応する抽選ボックスのデータに対して、複数のレア度ごとに、対応するレア度の付与可能数からユーザ：ＫＮＭによるモンスターカードの取得数を減算する処理を行う。例えば、ユーザ：ＡＢＣに対するレア度３のモンスターカードの現在の付与可能数が６０であって、ユーザ：ＫＮＭによるレア度３のモンスターカードの取得数が３３であった場合、当該処理後のユーザ：ＡＢＣに対するレア度３のモンスターカードの現在の付与可能数は２７となる。

【0109】

本実施形態のゲーム制御装置によれば、ユーザは、自らの入力によって、複数のレア度のうちいずれかのレア度に属する複数のモンスターカードの中から選択（抽選）された付与モンスターカードを入手することができる。また、付与モンスターカードが選択された場合には、ユーザは、付与モンスターカードのレア度に対応する付与可能数を減らした状態でモンスターカードの抽選を繰り返し行うことが可能となる。さらに、移転先ユーザは、所定の入力によって、移転元ユーザに対するいずれかの付与モンスターカードの数だけ当該付与モンスターカードのレア度に対応する付与可能数を減らした状態で複数のレア度ごとの付与可能数を自身に対応付ける（保有する）ことができる。この場合、移転先ユーザは、例えば、所望しないレア度に対応する付与可能数が多い場合には、移転元ユーザが当該所望しないレア度に属する付与モンスターカードを入手した数だけ当該付与可能数を減らした状態で、モンスターカードの抽選を行うことができる。このとき、移転先ユーザは、所望しないレア度に属するモンスターカードを抽選で入手する確率を低減することができるので、モンスターカードの抽選を楽しむことが可能となる。これにより、複数のユーザが協力してモンスターカードの抽選を楽しむことができる。

【0110】

以上、本発明の実施形態について詳細に説明したが、本発明は上記各実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上記各実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。

【0111】

上述した各実施形態では、複数のカード（モンスターカード）を用いてバトルを行う場合を例として説明したが、これに限られない。カードでなく、例えば、ユーザのアバタ画像等の各種オブジェクトを用いてバトルを行ってもよい。また、バトルにおけるカードやオブジェクトは複数でなくてもよく、単一のカードやオブジェクトで構わない。あるいは、カード等のオブジェクトを使用せずにバトルを行ってもよい。

【0112】

上述した各実施形態では、実行対象のゲームが、モンスターカードを用いたカードバトルゲームである場合の例について説明したが、本発明のゲームはこれに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲーム、テーブルゲーム、パズルゲーム、スポーツゲーム、レースゲーム、シューティングゲーム、アクションゲーム、アドベンチャーゲーム、シミュレーションゲームなどの各種ジャンルのゲームにおいて、ユーザの入力に関する情報に基づいて、当該ユーザに対応付けられた複数のオブジェクト情報に基づき当該ユーザに付与される付与オブジェクトが選択される場合には、本発明を好適に適用することができる。

【0113】

上述した各実施形態では、ユーザによる通信端末１０に対する所定の操作入力は、ユーザの通信端末１０に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末１０に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えた通信端末１０を振ることによる操作入力、あるいはジェスチャによる操作入力（ジェスチャ入力）であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末１０に対する所定のジェスチャを行うことで通信端末１０がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能な通信端末１０の場合には、操作入力は、音声を入力することにより行われてもよい。

【0114】

上述した各実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した各実施形態と同様に、ユーザによるゲームの進行を制御できることは言うまでもない。
また、例えば、家庭用ゲーム機がオフライン状態の場合であっても、上述した各実施形態と同様に、ユーザによるゲームの進行を制御することができる。
さらに、例えば、アドホックネットワーク等のように、複数の通信端末（例えば携帯電話やゲーム機など）が自律的にネットワークを構成して、データの送受信を各通信端末間で直接行う場合においても、上述した各実施形態と同様に、ユーザによるゲームの進行を制御することができる。

【0115】

上述した各実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、対応付け手段５３、選択手段５４、解除手段５５（あるいは変更手段６０）、及び更新手段５８の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記各実施形態に記載したようにして通信端末１０によっても各機能を実現できる。例えば、図１９（ａ），（ｂ）に、図９に示した機能ブロック図の各機能について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との機能分担の例を示す。なお、図１９（ａ），（ｂ）において、解除手段５５の代わりに変更手段６０が設けられてもよい。また、上述した各実施形態では、各種データ（例えば、モンスターカードデータベース、抽選ボックスデータなど）をデータベースサーバ３０（ゲームデータベース３２）が記憶している構成としたが、通信端末１０内の記憶装置に記憶させてもよい。その場合には、記憶装置は、通信端末１０内のＲＡＭ１３や図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置であってよい。

【0116】

上述した実施形態その他の記載では、ゲーム上のオブジェクトを選択（抽選）する場合について説明したが、本発明は、選択対象となるオブジェクトがゲーム上のオブジェクトに限られない。
つまり、選択対象をデータ一般とした抽選装置であってもよい。この場合、対応付け手段５３は、ユーザと複数のオブジェクトとを対応付ける機能を備えてもよい。選択手段５４は、前記ユーザの入力に関する情報に基づいて、前記ユーザに対応付けられた複数のオブジェクトの中から前記ユーザに付与される付与オブジェクトを選択する機能を備えてもよい。解除手段５５は、付与オブジェクトを選択した場合に、前記ユーザと前記付与オブジェクトとの対応付けを解除する機能を備えてもよい。更新手段５８は、所定の入力に関する情報に基づいて、第１ユーザに対応付けられた複数のオブジェクトをいずれかの付与オブジェクトを除いた状態で第２ユーザに対応付けるように、前記第２ユーザと複数のオブジェクトとの対応付けを更新する機能を備えてもよい。

【0117】

また、複数の属性のいずれかに属するオブジェクトを選択対象とした抽選装置であってもよい。
この場合、対応付け手段５３は、ユーザと、前記オブジェクトの属性ごとの付与可能数との対応付けを行う機能を備えてもよい。選択手段５４は、前記ユーザの入力に関する情報に基づいて、前記ユーザに付与される付与オブジェクトを、前記複数の属性のうちいずれかの属性に属する複数のオブジェクトの中から当該属性に対応する付与可能数の範囲内で選択する機能を備えてもよい。変更手段６０は、前記付与オブジェクトを選択するごとに、前記付与オブジェクトの属性に対応する付与可能数を減らすことによって、前記対応付けを変更する機能を備えてもよい。更新手段５８は、所定の入力に関する情報に基づいて、第１ユーザに対応付けられたときの付与可能数から前記付与オブジェクトの数を減らした付与可能数を前記複数の属性ごとに第２ユーザに対応付けるように、前記第２ユーザについての前記対応付けを更新する機能を備えてもよい。
また、更新手段５８は、上述した機能の代わりに、所定の入力に関する情報に基づいて、第１ユーザに対するいずれかの前記付与オブジェクトの数だけ当該付与オブジェクトの属性に対応する付与可能数を減らした状態で前記複数の属性ごとの付与可能数を第２ユーザに対応付けるように、前記第２ユーザについての前記対応付けを更新する機能を備えてもよい。

【符号の説明】

【0118】

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…実行手段
５３…対応付け手段
５４…選択手段
５５…解除手段
５６…設定手段
５７…提示手段
５８…更新手段
５９…関係付け手段
６０…変更手段

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】