(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0027】
以下、本発明の実施形態について説明する。
【0028】
(1)ゲームシステムの構成
図1は、実施形態のゲームシステムのシステム構成例を示している。
図1に示すように、このゲームシステムは、例えばインターネットなどの通信網NW(ネットワーク)に接続可能な通信端末10a,10b,10c,…と、通信網NWに接続されているゲームサーバ20と、データベースサーバ30とによって構成されている。各通信端末10a,10b,10c,…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、PDA(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機(いわゆる多機能型のスマートテレビも含む。)などの通信端末である。なお、以下の説明において、各通信端末10a,10b,10c,…に共通して言及するときには、通信端末10と表記する。
このゲームシステムにおいて、ゲームサーバ20は、クライアントである通信端末10と通信可能に構成されており、通信端末10に対してゲーミングサービスを提供する。ゲームサーバ20には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ30は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ20と例えば有線で接続される。
通信端末10は、ゲームサーバ20によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末10を用いてウェブページに対する操作を行うことにより、ゲームを実行する。
【0029】
また、
図1には図示していないが、ゲームサーバ20とは別に各通信端末10のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末10からのアクセスを受け入れるために複数のゲームサーバ20を設ける場合は、その複数のゲームサーバ20間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ20は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。
【0030】
(2)通信端末の構成
図2及び
図3を参照して通信端末10について説明する。
図2は、通信端末10の外観の例を示す図であって、(a)は、例えば折り畳み式の携帯端末(携帯電話機)などの釦入力方式の通信端末を例示したものであり、(b)は、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。
図3は、通信端末10の内部構成を示すブロック図である。
図3に示すように、通信端末10は、CPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、画像処理部14、指示入力部15、表示部16、通信インタフェース部17及びGPS(Global Positioning System)測位部18を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス19が設けられている。
【0031】
CPU11は、ROM12内のウェブブラウザをRAM13にロードして実行する。そして、CPU11は、指示入力部15等によってユーザに入力されるURL(Uniform Resource Locator)の適切な指定に基づき、通信インタフェース部17を介して、ゲームサーバ20からウェブページを表示するためのデータ、すなわち、HTML(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ(以下、総称して適宜「HTMLデータ」と表記する。)を、通信インタフェース部17を介して取得し、そのHTMLデータを解釈する。なお、通信端末10には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。
なお、HTMLデータの取得に当たって、CPU11は、予め登録されたユーザID(ユーザ識別情報)、あるいは指示入力部15を介して入力されるユーザIDを含むアクセス要求メッセージを、通信インタフェース部17を介してゲームサーバ20へ通知する。
【0032】
ウェブブラウザは、画像処理部14を介して、取得したHTMLデータに基づき、ゲームサーバ20から提供されるウェブページを表示部16に表示する。また、ウェブブラウザは、ユーザが指示入力部15の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新
たなHTMLデータの送信(つまり、ウェブページの更新)をゲームサーバ20へ要求する。
【0033】
画像処理部14は、HTMLデータの解析結果としてCPU11から与えられる表示用画像データに基づいて、表示部16にウェブページを表示する。表示部16は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むLCD(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面16aに表示する。
【0034】
通信端末10が釦入力方式の通信端末(
図2(a)に示す)である場合、指示入力部15は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群15a、及び、テンキーなどの複数の指示入力釦を含む釦群15bを備え、各釦の押下(操作)入力を認識してCPU11へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部16に表示されているウェブページをスクロールして表示することをCPU11へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示(例えば強調表示)されている1つのハイパーリンクまたはメニューをユーザが選択することをCPU11へ指示するために設けられる。なお、通信端末10を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末10を片手で保持したままその親指で操作(クリック)しやすいように、通信端末10の前面に配置されていることが好ましい。
図2(a)に示す例では、釦群15bは、釦群15aの下方に配置され、「0」〜「9」、「*」、「#」(テンキー)が表記された複数の指示入力釦を含む。
【0035】
通信端末10がタッチパネル入力方式の通信端末(
図2(b)に示す)である場合、指示入力部15は、主として表示画面16aに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、
図2(b)に示すように、通信端末10がタッチパネル入力方式の場合であっても釦群15aが設けられる場合もある。
【0036】
通信端末10に表示されるウェブページ上のメニューの選択操作は、例えば通信端末10が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末10がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面16a上のメニューの位置を指あるいはペンで指示(タッチ操作)することによって行われる。
【0037】
GPS測位部18は、GPS衛星からの測位用電波信号を受信することにより、通信端末10の現在位置を測位する。CPU11は、例えば、位置情報の送信要求メッセージをゲームサーバ20から受信した場合に、通信端末10の現在位置をGPS測位部18に測位させ、GPS測位部18の測位によって得られた位置情報(緯度、経度、測位時刻などを含む)をRAM13などの記憶装置に記憶する。なお、CPU11は、例えば、ユーザによる所定の操作入力が行われたとき、あるいは所定の周期で、通信端末10の現在位置をGPS測位部18に測位させてもよい。
CPU11は、例えば、位置情報の送信要求メッセージを、通信インタフェース部17を介してゲームサーバ20から受信すると、記憶装置に記憶された位置情報をユーザID(あるいは通信端末10固有の端末識別情報)と対応付けて、通信インタフェース部17を介してゲームサーバ20に送信する。また、CPU11は、例えば、ユーザによる所定の操作入力が行われたとき、あるいは所定の周期で、記憶装置に記憶された位置情報をユーザID(あるいは通信端末10固有の端末識別情報)と対応付けて、通信インタフェース部17を介してゲームサーバ20に送信してもよい。
【0038】
(3)ゲームサーバの構成
図4を参照してゲームサーバ20の構成について説明する。
ゲームサーバ20は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末10に対してゲームのウェブサービスを提供する。
図4に示すように、ゲームサーバ20は、CPU21、ROM22、RAM23、データベース(DB)アクセス部24、及び、通信インタフェース部25を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス26が設けられている。なお、ゲームサーバ20は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。
【0039】
ROM22には、クライアントである通信端末10のウェブブラウザに対してHTML文書や画像などのオブジェクトの表示(ウェブページの表示)のサービスを提供するアプリケーションプログラムが格納されている。ROM22には、アプリケーションプログラム以外にもCPU21によって参照される各種データが格納されている。
CPU21は、ROM22内のゲームプログラムをRAM23にロードして実行し、通信インタフェース部25を介して、各種の処理を行う。
【0040】
例えば、CPU21は、通信インタフェース部25を介して、HTMLデータを通信端末10宛に送信する。なお、ゲームサーバ20が通信端末10のユーザの認証処理を行う場合には、CPU21はその認証処理を行う。
CPU21は、通信端末10で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなHTMLデータの送信、または、ゲームサーバ20内の演算処理あるいはデータ処理などを含む。
データベースアクセス部24は、CPU21がデータベースサーバ30に対してデータの読み書きを行うときのインタフェースである。
【0041】
(4)データベースサーバの構成
データベースサーバ30は、大容量のハードディスク装置やRAID(Redundant Arrays of Inexpensive Disks)等の形態の記憶装置等、汎用ストレージで実現できる。データベースサーバ30内の各データベースは、ゲームサーバ20のデータベースアクセス部24を介してCPU21からのデータの読み書きが可能となるように構成されている。
図5に、データベースサーバ30の構成の一例を示す。
図5に示すように、データベースサーバ30は、ユーザデータベース31と、ゲームデータベース32とを備える。
【0042】
本実施形態のゲームサーバ20によって実行制御されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、本実施形態のゲームの一例として、野球形式のデジタルカードゲーム(以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。)を採り上げる。
本実施形態のゲームは、ユーザが野球選手に対応する選手カードを収集することによって自らのチームを作り上げ、他のユーザのチームと野球の対戦を行うように構成されているゲームである。このゲームは、ユーザの実行対象となる以下の処理を含む。
・スカウト処理:
自らのチームを作り上げていくために選手カードを探索する処理である。スカウトを実行することで行動ポイント(後述する)は消費するが、強化ポイント(後述する)は増加する。
・強化処理:
強化ポイントを消費することで、2枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる処理である。この場合、特定の選手カードの能力は上昇するが、一体化に用いられた選手カードは消失する。つまり、一体化に用いられた選手カードの数だけ選手数が減少する。
・試合処理:
他のユーザのチームと野球の試合を行う処理である。試合を行うことで運営ポイント(後述する)は消費するが、試合に勝利すれば強化ポイントが増加する。
・オーダー処理:
ユーザが選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行するための処理である。
・アイテム抽選処理:
エールポイント(後述する)を消費して、抽選によってゲーム上のアイテム(例えば選手カード)を入手する処理である。
・抽選登録処理:
ゲーム上で行われる抽選(上記アイテム抽選処理で行われるアイテムの抽選とは異なる抽選)にユーザが登録(エントリー)するための処理である。抽選は、抽選登録処理を行ったユーザを対象に行われ、抽選に当選したユーザには、ゲーム上の特典が付与されるようになっている。なお、抽選は、定期的に行われてもよいし、任意に設定されたタイミングで行われてもよい。
【0043】
図6に、上述した野球形式のデジタルカードゲームにおいて適用されるユーザデータベース31の一例を示す。この例では、ユーザデータベース31は、ユーザID(ユーザ識別情報)ごとに、ユーザ名/表示画像、技能レベル、行動ポイント、運営ポイント、強化ポイント、選手数、仲間ユーザID、保有カードのデータの各項目についての情報を含む。ユーザデータベース31に含まれる情報は、ゲームサーバ20によって逐次更新されうる。
【0044】
以下の説明では、ユーザデータベース31に含まれるユーザIDごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名/表示画像
ユーザ名は、ユーザを特定するために、ゲームの実行時に通信端末10に表示される名称である。ユーザ名はユーザによって予め指定される所定長以下のテキストである。また、ユーザ名は、ゲームサーバ20によって提供されるネットワーク環境(あるいはゲームコミュニティ)上でユーザを特定する名称である。表示画像は、ユーザを特定するために、ゲームの実行時に通信端末10に表示される画像である。表示画像は、例えばユーザによって予め選択されるアバタ画像である。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばLv1(レベル1)からLv100(レベル100)までの範囲のレベル値であり、例えば、上述したスカウト処理が継続的に実行されることで、順次技能レベルが上がるように構成されてもよい。
・行動ポイント
本実施形態のゲームにおいて、スカウト処理を実行する上で必要となるポイントである。行動ポイントは、スカウト処理において探索を行うことで例えば一定量減少し、所定の時間が経過する毎に回復(増加)する値である。
・運営ポイント
本実施形態のゲームにおいて、試合処理を行う上で必要となるポイントである。運営ポイントは、他のユーザと試合を行うことによって低減し、所定の時間が経過する毎に回復(増加)する値である。
・強化ポイント
本実施形態のゲームにおいて、強化処理を行う上で必要となるポイントである。強化ポイントは、選手カードの強化を行うことで低減し、他のユーザとの試合で勝利するか、あるいはスカウト処理において探索を行うことで増加する値である。
・エールポイント
本実施形態のゲームにおいて、他のユーザ(例えば、ユーザと関係付けられた仲間ユーザ)へ応援メッセージを送信することでユーザが取得するポイントである。
・選手数
ユーザが保有する選手カードの数である。選手数は、スカウト処理や強化処理の実行によって増減する。選手数の最大値(例えば、60)は予め規定されている。
・仲間のユーザID
ユーザと関係付けられた仲間ユーザのユーザIDのデータである。
・保有カードのデータ
ユーザが保有する選手カードごとに、例えば、選手の画像データや、選手の能力を示すパラメータ(例えば、野手であれば打力、走力、守備力を示す値、投手であれば球速、制球力、スタミナを示す値)等のデータが含まれる。例えば、パラメータに含まれる能力の値が大きいほど能力が高いことを示すように設定されてもよい。なお、選手カードのデータには、「レア度」が含まれてもよい。ここで、「レア度」とは、選手カードの希少価値の度合を示す値であり、その値が高いほどゲーム内で出現する確率が非常に低く設定されてもよい。例えば、レア度を1〜5の5段階で表した場合、技術能力の際立った選手や人気のある選手に対応する選手カードのレア度は高く(例えば、4あるいは5など)設定されてもよい。
また、選手カードのデータには、選手の所属チーム、ポジション(投手、捕手、一塁手、左翼手など)、選手カードがゲームに及ぼす影響度(典型的にはポジティブな影響度)等が含まれてもよい。
【0045】
図5に戻り、ゲームデータベース32は、ゲームサーバ20からのアクセスに基づき、ゲームサーバ20によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、ユーザ毎のスカウト処理の進行状況を示す情報や、ユーザ間の試合の結果(スコア等)などを含む。
【0046】
(5)ゲーム制御装置における各機能の概要
本実施形態では、ゲームサーバ20及びデータベースサーバ30によってゲーム制御装置が構成されている。以下では、上述した野球形式のデジタルカードゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、
図7を参照して説明する。
図7は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、
図7の機能ブロック図において、関係付け手段53、抽選手段54、取得手段55、判別手段56、抽選制御手段57及び付与手段58が本発明の主要な構成に対応している。その他の手段は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成である。
また、以下の説明において、通信端末10に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末10で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネルの操作によるウェブページのスクロール操作によって変化しうる。
【0047】
登録手段51は、例えば通信端末10に提供するウェブページ上での通信端末10への適切な操作入力に基づいてユーザの要求を認識し、登録処理(ユーザ登録)を行う機能を備える。
なお、登録手段51は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。
【0048】
登録手段51の機能は、例えば以下のとおり実現される。ゲームサーバ20のCPU21は、通信インタフェース部25を介して通信端末10から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ20から提供されるウェブページ上での通信端末10に対する所定の操作(例えば、所定のメニューの選択操作やユーザが指定するユーザIDやパスワード等のテキスト入力等)によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末10を特定するための情報(例えば、UID(Unique Identifier)などの端末の個体識別情報、IPアドレス、メールアドレス等)が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザIDが含まれていてもよい。
CPU21は、登録要求メッセージを受信し、登録要求メッセージにユーザIDが含まれていない場合には、ユーザIDを新規に発行してそのユーザIDの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末10へ送信する。CPU21は、登録要求メッセージを受信し、登録要求メッセージにユーザIDが含まれている場合には、そのユーザIDの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末10へ送信する。
登録が完了すると、CPU21は、ユーザIDに対応するユーザデータを生成し、ユーザデータベース31に格納する。登録が完了すると、ユーザは、本実施形態のゲームを実行することが可能となる。
【0049】
ゲーム実行手段52は、ゲームを実行する機能を備える。例えば、ゲーム実行手段52は、通信端末10に対するユーザのウェブページ上の選択操作に応じてHTTPリクエストを受信し、通信端末10に表示されるウェブページを逐次更新するためのHTMLデータ(つまり、HTTPレスポンス)を送信することで、ウェブサービスにより本実施形態のゲームを実行する。
なお、ゲーム実行手段52は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。
【0050】
また、ゲーム実行手段52は、ユーザが本実施形態のゲームを実行するに当たって、ユーザのログイン時の認証処理を実行する機能を備えてもよい。
この機能は、以下のようにして実現される。ゲームサーバ20のCPU21は、各ユーザの通信端末10からのHTTPリクエストを受信すると、当該HTTPリクエストから個体識別情報、あるいはユーザID及びパスワードを取得し、その個体識別情報、あるいはユーザID及びパスワードを、例えばユーザデータベース31に記録済みのデータと照合して認証処理を行う。
【0051】
ゲーム実行手段52は、ゲームで実行される複数の処理が各々割り当てられた複数のメニューを通信端末10に表示させる。具体的には、CPU21は、複数のメニューを含むウェブページを表示するためのHTMLデータを生成して通信端末10宛に送信する。そして、CPU21は、通信端末10においてウェブページ上のメニューが選択されたときに、選択されたメニューについての情報を通信端末10から受信し、受信した情報に基づいて、選択されたメニューに割り当てられた処理を実行する。
【0052】
ゲーム実行手段52によって通信端末10に表示されるゲームのトップページの例を
図8に示す。このトップページは、個々のユーザIDに応じたウェブページで構成される。
図8に例示されるトップページは、ユーザデータ表示領域、選手画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザIDのユーザデータに含まれる、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間の各項目のデータ(
図6参照)が表示される領域である。なお、ユーザデータ表示領域に表示される項目で、X/Yの形式で表記されているポイントまたは数は、Xがユーザの保有するポイントまたは数であり、Yがそのポイントまたは数の最大値であることを示す。例えば、選手数が「40/60」と表記されていれば、ユーザが保有する選手数が40人であり、最大で保有可能な選手数が60人であることを示す。
選手画像表示領域は、ユーザによって予め選択された選手カードの画像データが表示される領域である。
メニュー表示領域は、本実施形態のゲームに設けられる複数の処理(スカウト処理、強化処理、試合処理、オーダー処理、アイテム抽選処理、抽選処理)に対応した基本メニューとして、「スカウト」、「強化」、「試合」、「オーダー」、「アイテム抽選」、「抽選登録」の各メニューm1〜m6が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末10に表示されるウェブページの所定の位置にそれぞれ配置される。なお、オーダー処理は、ユーザの指示の下、選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行する処理である。
ゲーム実行手段52は、通信端末10に表示されたメニューに対するユーザの選択操作に応じた処理を実行する。好ましくは、各処理が実行された場合、処理ごとに細分化された複数のメニューを含む新たなウェブページが表示されるようにして、階層的に各処理が実行される。
【0053】
例えば、
図8に示すトップページをユーザの通信端末10に表示する場合について、ゲーム実行手段52の機能は以下のようにして実現される。ゲームサーバ20のCPU21は、データベースアクセス部24を介してユーザデータベース31にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、選手画像表示領域に表示すべき選手カードの画像データを読み出す。次にCPU21は、
図8に示したトップページが構成されるようにHTMLデータを生成し、通信端末10宛に送信する。生成されるHTMLデータは、ユーザごと(つまり、ユーザIDごと)に異なるものとなる。通信端末10は、受信したHTMLデータを解釈してトップページの画像を表示部16(表示画面16a)に表示する。
【0054】
[スカウト処理]
ゲーム実行手段52は、ユーザが自らのチームを作り上げていくために選手カードを探索できるようにするスカウト処理を実行する。
図9は、スカウト処理が実行された場合に通信端末10に表示されるウェブページの例を示す。
図9は、トップページにおいてスカウトメニュー(
図8のメニューm1)が選択操作されたときのウェブページの表示例である。
【0055】
図9に例示するウェブページでは、表示領域100において、複数の地域(エリア)に分けられた日本地図が、探索の対象となるエリアが強調表示された状態で表示される。
このスカウト処理では、ユーザは、探索の対象となるエリア(
図9の例では、エリア9(サブエリア9−1,9−2,…))ごとに設けられる「探索する」と表記されたメニューm10を選択操作する。この操作を契機として、探索の対象となるエリアについての探索が行われ、選手が発掘された場合に表示領域102にその選手の選手カードが表示される仕組みになっている。このとき、メニューm10が選択操作されて探索が行われる度に、表示領域101に表示されている「探索率」(%)の値が増加する。また、表示領域101には、1回の探索に要する行動力の値(
図9の例では「5」)、1回の探索で得られる強化ポイントの値(
図9の例では「10」)が表示される。1回の探索につき、表示されている行動力の値だけ行動ポイントが減少し、表示されている量の強化ポイントが増加するように構成されている。ゲーム実行手段52では、探索を行う度(メニューm10が選択される度)に、CPU21がユーザデータベース31にアクセスし、対象となるユーザIDの行動ポイント及び強化ポイントの値を更新する。
【0056】
スカウト処理において、ゲームサーバ20のCPU21は、メニューm10に対する選択操作を認識すると、スカウト用に予め設けられた複数の選手の中から所定の、あるいはランダムな確率で抽選を行う。CPU21は、抽選により選手を得た(発掘した)場合には、ユーザデータベース31にアクセスし、対象となるユーザIDのデータに対して、発掘された新たな選手のデータを追加して、選手数の値を1だけ増加させる。さらにCPU21は、発掘された選手の選手カードを表示領域102に表示するためのHTMLデータを生成して通信端末10宛に送信する。なお、このHTMLデータは、表示領域101の探索率のデータが更新されるようにして構成されている。ユーザによるメニューm10に対する選択操作が繰返し行われ、
図9においてサブエリア9−1,9−2,…のすべてのエリアの探索率が100%に達すると、エリア9についての探索は終了し、探索対象は次のエリア(この場合、エリア10)に移る。なお、後述するように、探索率が100%に達したとしても、表示領域102に表示可能な最大の枚数(
図9のサブエリア9−1では、4枚)に相当する数の選手が発掘できたとは限らない。
【0057】
スカウト処理では、探索対象となるエリアごとに、1回の探索に要する行動ポイントが異なってもよい。つまり、探索対象となるエリアごとに、1回の探索で減少する(消費される)行動ポイントの量が異なってもよい。例えば、ユーザの技能レベルが上がるごとに、消費される行動ポイントの量を多くしてもよい。
スカウト処理では、メニューm10に対する選択操作を行う度に行動ポイントが減少していくため、スカウト処理が実行された直後にトップページが表示される場合には、そのトップページに表示される行動ポイントがスカウト処理の実行前よりも減少されて表示されることになる。ユーザが保有する行動ポイントが0になれば、それ以上、探索を実行することはできない。但し、行動ポイントは、例えば所定時間(例えば3分)が経過する度に1ポイントずつ回復(増加)するので、所定時間経過すれば、再び、探索を行うことが可能になる。
【0058】
[強化処理]
ゲーム実行手段52は、2枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる強化処理を実行する。このゲームでは、ユーザが強化処理を実行するには一定量の強化ポイントが必要となる。
この一体化の処理は、例えば以下のように行われてよい。強化対象となる選手カード(ユーザによって指定された、残留する選手カード)を選手Aの選手カードとし、選手Aの選手カードに一体化させられて消失する選手カードを選手Bの選手カードとする。この場合、一体化の処理では、CPU21が選手Aの選手カードの「打力」,「走力」,「守備力」の能力値を示すパラメータに対して、選手Bの選手カードの「打力」,「走力」,「守備力」の能力値を示すパラメータの一定比率をそれぞれ加算することで、新たな選手Aの選手カードのパラメータを算出するようにしてもよい。この強化処理によって、選手Bの選手カードの能力上の特徴が選手Aの選手カードに反映されることになる。
強化処理後には、CPU21は、強化処理の後にユーザデータベース31にアクセスし、対象となるユーザIDのユーザデータから選手Bの選手カードのデータを削除し、選手数の値を1だけ減少させ、選手Aの選手カードのパラメータを書き換え、対象となるユーザIDの強化ポイントを所定量減少させる。なお、強化ポイントは、上記スカウト処理を実行したり、以下に説明する試合処理を実行したりすることによって増加する。
【0059】
[試合処理]
ゲーム実行手段52は、ユーザによる通信端末10の操作入力を契機として、他のユーザのチームと野球の試合を行う試合処理を実行する機能を有する。
このゲームでは、試合処理を実行するには運営ポイントを必要とし、試合に勝利することで強化ポイントを得ることができる。つまり、試合処理の実行によって、ユーザIDに対応する運営ポイント、強化ポイントの値が変化し得る。1回の試合で必要となる(消費する)運営ポイントは、ユーザのチームで組まれるオーダーによって定まる値である。ユーザは、ユーザが保有する選手カードの中から試合に出場させたい選手カードをオーダー処理によって組み替えることができるが、試合に出場させたい所定数の選手カードによって、運営ポイントの消費量が決定される。例えば、選手カードごとに1回の試合で必要となるコスト(必要ポイント)が予め割り当てられており、試合に出場させたい所定数の選手の必要ポイントの合計が運営ポイントとなる。運営ポイントは、例えば所定時間(例えば1分)が経過する度に1ポイントずつ回復(増加)する。
【0060】
ゲーム実行手段52が試合処理を実行する機能は、例えば以下のとおり実現される。
ユーザの通信端末10のトップページ上でメニューm3(
図8参照)の選択操作がなされ、その選択結果を受信すると、ゲームサーバ20のCPU21は、そのユーザIDの試合相手の複数の候補を、ユーザデータベース31に含まれる他のユーザIDの中からランダムに決定する。このとき、試合相手の候補の技能レベルは、メニューm3を選択操作したユーザと同一の技能レベルであることが好ましい。CPU21は、複数の試合相手の候補のリストからいずれかの候補を選択可能とするウェブページを表示するためのHTMLデータをユーザの通信端末10宛に送信する。
複数の試合相手の候補のリストからいずれかの候補を選択する操作がユーザによってなされると、試合相手(対戦相手)ととともに試合開始の指示を促すメニューを含むウェブページが表示される。このウェブページには、例えば、試合開始を指示するための「試合開始」と表記されたメニューが含まれてもよい。ユーザが「試合開始」のメニューを選択すると、CPU21は試合結果を決定する処理を行う。試合結果を決定するに当たって、CPU21は、データベースアクセス部24を介してデータベースサーバ30のユーザデータベース31にアクセスし、対象となるユーザIDの運営ポイントが試合の実行に必要とする所定量以上である場合に、運営ポイントからその所定量を減少させるとともに、試合相手となる2つのユーザIDに対応付けられた複数の選手カードの能力を示すパラメータを読み出す。そして、CPU21は、読み出したパラメータに基づいてユーザ間の試合結果を決定する。
【0061】
試合結果の決定方法は、選手カードの能力値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、試合相手となる2人のユーザが保有する複数の選手カードのパラメータの合計値を比較し、合計値が大きな方のユーザが高い確率(例えば、60〜90%の範囲内の所定の確率)をもって勝利するように設定してもよい。この勝率は、能力値の差が大きいほど高い確率としてもよい。このとき、能力値を示すパラメータの項目が複数存在する場合には、各選手カードのパラメータを代表する値として、各項目のパラメータの値に対して所定の重み付け(例えば、「打力」を0.4、「走力」を0.2、「守備力」を0.4の重み付けにする等)をもって総合的な能力値を設定してもよい。
【0062】
CPU21は、試合結果を決定すると、試合結果をユーザに通知するために、その試合結果を含むウェブページを表示させるHTMLデータを、「試合開始」のメニューの選択操作を行ったユーザの携帯端末10宛に送信する。「試合開始」のメニューを選択する操作が行われてから、試合結果を含むウェブページが表示されるまでの時間は極めて短時間(例えば数秒)であるため、ユーザは、簡易な操作のみで極めて短期間で試合結果を知ることができる。
【0063】
[アイテム抽選処理]
ゲーム実行手段52は、抽選によってアイテム(例えば、選手カード)を入手することを可能とするアイテム抽選処理を実行する。アイテム抽選処理は、好ましくは、選手カードを抽選箱の中から1枚を取り出す(引く)ような演出を経て実行される。アイテム抽選処理によって出現する選手カードは基本的にランダムであるが、レア度の高い(例えば、レア度が4あるいは5の)選手カード(いわゆるレアカード)が抽選で出現する確率は非常に低く設定されている。アイテム抽選処理は、所定量のエールポイントと引き換えに行われてもよい。
【0064】
[抽選登録処理]
ゲーム実行手段52は、ゲーム上で行われる抽選にユーザが登録(エントリー)するための抽選登録処理を実行する。なお、この抽選は、上述したアイテム抽選処理と異なるものである。
ゲーム実行手段52が抽選登録処理を実行する機能は、例えば以下のとおり実現される。ユーザの通信端末10のトップページ上で、「抽選登録」と表記されたメニューm6(
図8参照)の選択操作がなされ、その選択結果を受信すると、ゲームサーバ20のCPU21は、
図10に例示するウェブページを表示するためのHTMLデータを生成して、当該ユーザの通信端末10宛に送信する。この場合、ユーザの通信端末10には、
図10に示すウェブページが表示される。
図10のウェブページの例には、抽選に当選するとゲーム上の特典(図の例ではプレゼント)が得られることを通知するためのメッセージと、抽選に登録するための「エントリーする」と表記されたメニューm11などが含まれる。ユーザがメニューm11の選択操作を行うと、ゲームサーバ20のCPU21は、メニューm11の選択操作を行ったユーザのユーザIDを、ゲームデータベース32内のエントリーデータに記録する。
図11にエントリーデータの構成例を示す。
図11に示すように、エントリーデータは、抽選登録処理を行った(メニューm11の選択操作を行った)ユーザのユーザIDと、当該ユーザIDに対応付けられた当選確率とが記述されたデータである。
なお、ユーザIDがエントリーデータに記録される時点では、当該ユーザIDに対応する当選確率にはデフォルトの値(図の例では30%)が記録される。また、後述する抽選制御手段57の機能によってユーザの当選確率が変動する場合には、当該ユーザの当選確率の調整値(図の例では、30%増加、あるいは70%増加)によって調整された当選確率の値が、エントリーデータ内の当該ユーザのユーザIDに対応する当選確率の項目に記録される。
なお、エントリーデータに記録されたユーザID及び当選確率は、例えば、1回の抽選が行われるごとに全て更新されてもよいし、所定回数の抽選が行われるごとに全て更新されてもよい。
また、本実施形態のゲームでは、抽選登録処理において登録(エントリー)したユーザを対象として抽選を行うように構成されているが、抽選登録処理は必須の機能ではない。つまり、ゲームを実行可能なユーザ(ゲームの登録処理を行ったユーザ)の全てが抽選対象として自動的に設定されるように構成されてもよい。この場合、
図8に示したトップページには、「抽選登録」と表記されたメニューm6を設けなくてもよい。また、例えば、後述する変形例1に関連して、野球の試合(イベント)が行われる試合時間帯(イベント期間内)に当該試合が行われるスタジアム(所定領域)に存在する通信端末10を保有するユーザを対象として抽選を行う場合には、「スタジアム観戦ありがとうございます。本日スタジアムにお越しの皆様のみを対象とするプレゼント抽選が行われます。お楽しみに。」などのように、抽選が行われることを通知するテキストなどがトップページに表示されてもよい。
【0065】
以上、ゲーム実行手段52の主要な機能(スカウト処理、強化処理、試合処理、アイテム抽選処理及び抽選登録処理)について説明した。
ゲーム実行手段52はさらに、ユーザが保持する各ポイントあるいは選手数に基づいて、ユーザによって選択されたメニューに応じた機能(スカウト処理、強化処理、試合処理及びアイテム抽選処理)が実行できるか否かを判定し、選択されたメニューに応じた機能が実行できない場合には、機能が実行できないことをユーザに報知するためのテキストを含むページを通信端末10上に表示する。例えば、ポイントが所定の閾値より低い場合にゲームの進行が制限されるように構成されている場合、具体的には、1回の探索に行動力が「5」必要となるエリアについてスカウト処理を実行しようとする場合に、ユーザの行動ポイントが「3」のときには、スカウト処理が実行できないため、例えば「行動力が足りません。行動力は3分ごとに1回復します。ゆっくり待ちましょう。」などといったテキストを表示させる。このとき、ゲームサーバ20のCPU21は、ユーザデータベース31にアクセスして、ユーザの行動ポイントのデータと、探索対象のエリアに要する行動力(既定値)との比較処理を行って、スカウト処理の実行可否を判定する。
【0066】
関係付け手段53は、ユーザ同士を関係付ける機能を備える。
例えば、関係付け手段53は、ユーザIDに基づく申請を契機として当該ユーザIDを他のユーザIDと関係付けて登録してもよい。すなわち、関係付け手段53は、ユーザIDに基づく申請を契機として、他のユーザIDを「仲間」として登録する。なお、以下の説明では、ユーザIDが仲間の関係にあることと、対応するユーザが仲間の関係にあることとは、同義である。
関係付け手段53の機能は、例えば以下のようにして実現できる。ゲームサーバ20のCPU21は、通信インタフェース部25を介して、あるユーザIDに対応するユーザの通信端末10から、仲間になりたいユーザID(あるいは、対応するユーザ名)を指定した申請メッセージ(申請)を受け付ける。この申請メッセージの送信は、ユーザの通信端末10に提供されるウェブページの機能として予め設定されている。CPU21は、申請メッセージを受け付けると、申請メッセージに含まれるユーザIDに基づくアクセスがあったタイミングで、そのユーザIDに対応する通信端末10宛に、他のユーザIDに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるHTMLデータを送信する。その申請を承認することが返信されれば、CPU21は、両者を仲間として登録する。具体的には、CPU21は、ユーザデータベース31内の対応する2つのユーザIDのユーザデータの「仲間」の箇所(
図6参照)にデータを書き込む。
なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限られず、同一のゲーム上のステージを実行するユーザや試合を行ったユーザを、ユーザとゲーム内で関係付けられたユーザ、つまり仲間として登録してもよい。あるいは、所定回数のメッセージ(例えば挨拶など)を送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間で試合や対戦を行うゲーム上のモードが存在する場合には、所定回数以上試合や対戦を行ったユーザ同士を自動的に仲間として登録してもよい。
【0067】
抽選手段54は、ユーザに対してゲーム上の抽選を行う機能を備える。
ここで、「ユーザに対してゲーム上の抽選を行う」とは、例えば、ユーザを識別するためのユーザ識別情報(ユーザID)を抽選対象としてゲーム上の抽選を行うことであってもよいし、ユーザが保有する通信端末固有の端末識別情報を抽選対象としてゲーム上の抽選を行うことであってもよい。
抽選手段54の機能は、例えば以下のようにして実現できる。ゲームサーバ20のCPU21は、例えばCPU21に内蔵されたタイマによって所定の抽選時刻が到来したことを認識すると、
図11に例示したエントリーデータに記録されたユーザIDに対応するユーザを対象とした抽選処理を行う。ここで、抽選時刻は任意に設定されてもよく、例えば、後述する試合時間帯(イベント期間内)の所定時刻に設定されてもよい。
また、抽選方法は、周知の方法が用いられてもよい。例えば、ユーザの当選確率が30%となるように抽選を行う場合には、CPU21は、
図11に示したエントリーデータのユーザIDごとに、0.1〜1.0の範囲内で0.1間隔の乱数を発生させ、発生した数が0.3以下のユーザIDに対応するユーザを当選者として決定するようにしてもよい。また、CPU21は、エントリーデータのユーザIDに対応する当選確率にデフォルト値(
図11の例では30%)以外の値が設定されている場合には、記録された値に基づいて当選確率を調整した上で抽選処理を行う。
図11に示す例を参照して説明すると、例えば、当選確率のデフォルト値が予め30%に設定されている場合に、CPU21は、ユーザIDが「112233」のユーザの当選確率を30%増加、すなわち当該ユーザの当選確率が60%となるように調整した上で抽選処理を実行する。この場合、CPU21は、0.1〜1.0の範囲内で0.1間隔の乱数を発生させ、発生した数が0.6以下の場合に、ユーザIDが「112233」のユーザを抽選の当選者として決定するようにしてもよい。また、CPU21は、ユーザIDが「000123」のユーザに対する抽選を行う場合、当該ユーザの当選確率を70%増加、すなわち当該ユーザの当選確率が100%となるように調整した上で抽選処理を実行する。この場合、CPU21は、ユーザIDが「000123」のユーザを抽選の当選者として決定するようにしてもよい。
なお、本実施形態では、所定の抽選時刻が到来すると自動的に抽選が実行されるように構成されているが、例えば、抽選登録処理において抽選に登録したユーザが所定数に達したことを契機として抽選が実行されてもよい。
【0068】
ここで、本実施形態のゲームでは、ユーザの通信端末10が、野球の試合(イベント)が行われる試合時間帯(イベント期間内)に当該試合が行われるスタジアム(所定領域)に存在する場合に、当該ユーザに関係付けられた仲間ユーザに関する情報に基づいて、抽選における当該ユーザの当選確率を変動する処理を行うようになっている。この処理は、取得手段55、判別手段56及び抽選制御手段57によって実行される。以降では、各手段の詳細について説明する。
【0069】
取得手段55は、ユーザの通信端末10の現在位置(位置)を示す位置情報を取得する機能を備える。取得手段55の機能は、以下のように実現される。
例えば、ユーザが、
図8に示すトップページ上でメニューm1〜m6のうち何れかのメニューを選択すると、通信端末10のCPU11は、ウェブページを表示するためのHTMLデータの送信要求メッセージを、通信インタフェース部17を介してゲームサーバ20に送信する。
一方、ゲームサーバ20のCPU21は、HTMLデータの送信要求メッセージを、通信インタフェース部25を介して受信すると、位置情報の送信要求メッセージを、通信インタフェース部25を介して通信端末10に送信する。
通信端末10のCPU11は、位置情報の送信要求メッセージを受信すると、通信端末10の現在位置をGPS測位部18に測位させる。そして、CPU11は、GPS測位部18の測位によって得られた位置情報を、ユーザIDと対応付けて、ゲームサーバ20に送信する。
ゲームサーバ20のCPU21は、位置情報を受信する(取得する)毎に、取得した位置情報をゲームデータベース32内の現在位置データに記録する。
図12に現在位置データの構成例を示す。
図12に示すように、現在位置データは、位置情報の取得日時(位置情報に含まれる測位時刻)と、位置情報に含まれる緯度及び経度とが、複数のユーザ(ユーザID)ごとに記述されたデータである。複数のユーザの各々に対応する取得日時、緯度及び経度は、CPU21が位置情報を受信する度に追記されるようになっていてもよい。そして、CPU21は、位置情報を現在位置データに記録すると、ユーザが選択したメニューに応じたウェブページを表示するためのHTMLデータを生成し、通信端末10宛に送信する。
【0070】
なお、上述した取得手段55の機能の実現例では、ゲームサーバ20のCPU21は、
図8に示すトップページ上でメニューm1〜m6のうち何れかのメニューが選択された場合に位置情報の送信要求メッセージを送信することとしているが、この場合に限られない。例えば、ゲームサーバ20のCPU21は、位置情報の送信要求メッセージを送信するためのメニューを予め設定(例えば、位置情報の送信要求メッセージを送信するのは、メニューm1が選択操作された場合のみ等)してもよいし、各メニューm1〜m6の選択回数が所定回数(例えば5回)に達する毎に位置情報の送信要求メッセージを送信してもよい。また、ゲームサーバ20のCPU21は、例えば、
図8に示すトップページを表示するためのHTMLデータの送信要求メッセージを受信した場合に、位置情報の送信要求メッセージを送信してもよいし、通信端末10との間で所定の認証処理(例えば、ログイン認証など)を行う際に、位置情報の送信要求メッセージを送信してもよい。さらに、ゲームサーバ20のCPU21は、例えば、位置情報の送信要求メッセージを、所定の時刻に自動的に送信してもよい。
【0071】
判別手段56は、ユーザの通信端末10が、野球の試合(所定のイベント)が行われる試合時間帯(イベント期間内)に当該試合が行われるスタジアム(所定領域)に存在するか否かを、位置情報に基づいて判別する機能を備える。
ここで、試合時間帯には、試合開始から試合終了までの時間だけではなく、例えば、試合開始前の練習時間や試合終了後のファンサービスの時間等が含まれてもよい。また、「所定のイベント」とは、所定期間の間開催される行事等であれば何でもよいが、例えば、ゲームにおいて模擬された現実世界のイベントであってもよい。ゲームにおいて模擬された現実世界のイベントとは、例えば、野球ゲームの場合には野球の試合であってよいし、サッカーゲームの場合にはサッカーの試合であってよいし、音楽ゲームの場合には音楽の演奏会であってよい。さらに、「所定領域」とは、例えば、野球やサッカー、アメリカンフットボールの試合等が行われるスタジアムであってもよいし、ゲームセンター、競馬場、コンサートホールやその他所定のイベントが行われる会場であってもよい。また、「所定領域」は、ゲームに関する領域であるか否かにかかわらず、例えば販売や展示等のイベントが行われる領域であれば任意に設定することができる。例えば、「所定領域」は、ゲームセンターなどの遊技施設、ゲームの販売を行う店舗あるいはゲームの展示を行う展示会場などであってもよいし、「東京都港区赤坂九丁目」などの地域の区画などであってもよい。
【0072】
判別手段56の機能は、以下のようにして実現できる。
ゲームサーバ20のCPU21は、ユーザの通信端末10の位置情報を取得し、取得した位置情報をゲームデータベース32内の現在位置データに記録すると、当該ユーザの通信端末10が、野球の試合の試合時間帯にスタジアム内に存在するか否かを判別する。具体的に説明すると、CPU21は、ゲームデータベース32にアクセスし、ユーザのユーザIDに対応する現在位置データを参照する。そして、CPU21は、現在位置データに記録された位置情報のうち最新の位置情報の緯度及び経度がスタジアム内に含まれるか否か、及び、最新の位置情報の取得日時が野球の試合時間帯に含まれるか否かを判別する。なお、通信端末10の現在位置がスタジアム内に存在するか否かを判別するために、スタジアムの外縁の緯度及び経度は、ゲームデータベース32に予め記録されていてもよい。また、野球の試合時間帯などの情報(例えば、練習開始時刻、試合開始時刻、各イニングの開始及び終了時刻、試合終了時刻、試合終了後のイベント(例えばファンサービスなど)の開始及び終了時刻など)は、ゲームデータベース32に逐次記録されるようにしてもよい。
最新の位置情報の緯度及び経度がスタジアム内に含まれ、且つ、最新の位置情報の取得日時が野球の試合時間帯に含まれる場合、CPU21は、ユーザの通信端末10が、試合時間帯にスタジアム内に存在すると判別する。
【0073】
抽選制御手段57は、ユーザ(第1のユーザ)の通信端末10が試合時間帯(イベント期間内)にスタジアム(所定領域)に存在すると判別された場合に、当該ユーザに関係付けられた仲間ユーザ(第2のユーザ)に関する情報に基づいて、抽選における当該ユーザ(第1のユーザ)の当選確率が変動するように抽選手段54を制御する機能を備える。
ここで、仲間ユーザに関する情報とは、例えば、仲間ユーザの数であってもよいし、仲間ユーザに対応付けられた情報(例えば、仲間ユーザがゲーム上保有するポイントの量やアイテムなどの数、仲間ユーザにより実行されたゲーム上の対戦数、ゲーム上の対戦における仲間ユーザの勝利数又は敗北数、仲間ユーザのゲームの進行度あるいは仲間ユーザのゲーム上の技能レベルなど)であってもよい。
【0074】
抽選制御手段57の機能は、以下のように実現される。なお、ここでは、ユーザの通信端末10が試合時間帯にスタジアムに存在すると判別された場合に、当該ユーザの仲間ユーザの数が多いほど(仲間ユーザに関する情報に基づいて)、抽選における当該ユーザの当選確率が高くなる(変動する)場合を一例として説明する。
ゲームサーバ20のCPU21は、例えば、
図13に例示した抽選制御データをゲームデータベース32に予め格納してもよい。
図13に抽選制御データの構成例を示す。
図13に示すように、抽選制御データには、仲間ユーザの数(仲間の人数)に応じた当選確率の調整値が含まれる。ここで、当選確率の調整値は、例えば、仲間ユーザの数が多くなるほど、当選確率が高くなるように設定されてもよい。
図13を参照して説明すると、例えば、ユーザの仲間ユーザの数が1名の場合には、抽選における当該ユーザの当選確率が30%増加することになる。また、ユーザの仲間ユーザの数が2〜5名の場合には、抽選における当該ユーザの当選確率が40%増加し、当該ユーザの仲間ユーザの数が6〜10名の場合には、抽選における当該ユーザの当選確率が50%増加することになる。さらに、当該ユーザの仲間ユーザの数が10名以上の場合には、抽選における当該ユーザの当選確率が70%増加することになる。つまり、抽選における当選確率のデフォルト値が30%に設定されている場合には、仲間ユーザの数が10名以上のユーザの抽選における当選確率は100%になる。なお、当選確率の調整値は、所定の演算式等を用いて、仲間ユーザの数を当該演算式に当てはめることで求められてもよい。
CPU21は、ユーザの通信端末10が試合時間帯にスタジアム内に存在すると判別された場合に、当該ユーザの仲間ユーザの数をユーザデータベース31から取得し、抽選制御データを参照して当選確率の調整値を決定する。そして、CPU21は、決定した当選確率の調整値を、エントリーデータ内の当該ユーザのユーザIDに対応する当選確率の値に加算する。上述したように、抽選手段54は、エントリーデータ内の当選確率を参照して当選確率を調整した上で抽選処理を行うように構成されている。このため、抽選手段54は、抽選制御手段57の機能によってエントリーデータ内の当選確率の値が更新されることによって、抽選におけるユーザの当選確率が変動するように制御されることになる。
【0075】
なお、上述した例では、ユーザの仲間ユーザの数が多いほど、抽選における当該ユーザの当選確率が高くなる場合について説明したが、当選確率の変動パターンは、この場合に限られない。例えば、ユーザの仲間ユーザの数が所定の閾値以上になった場合、仲間ユーザの数が多いほど、抽選における当該ユーザの当選確率が低減するように構成されてもよい。この構成によれば、仲間ユーザの数の増加に伴ってユーザの当選確率が極めて高くなることに起因して、他のユーザとの間で公平性を損なうことのない仕組みとすることができる。
また、抽選におけるユーザの当選確率は、例えば、当該ユーザの仲間ユーザがゲーム上保有するポイントの量やアイテムなどの数が多いほど、高く又は低くなるように設定されてもよいし、当該ユーザの仲間ユーザによって実行されたゲーム上の対戦数やゲーム上の対戦における仲間ユーザの勝利数又は敗北数が多いほど、高く又は低くなるように設定されてもよい。
さらに、CPU21は、抽選にエントリーしたユーザが当該抽選に当選しなかった場合には、当該ユーザが次回の抽選にエントリーし、且つ、当該ユーザの通信端末10が試合時間帯にスタジアム内に存在すると判別されたときに、当選確率を高めるように調整してもよい。例えば、1回目の抽選におけるユーザの当選確率がデフォルト値(例えば30%)であり、且つ、当該ユーザが1回目の抽選に当選しなかった場合には、CPU21は、当該ユーザが2回目の抽選にエントリーし、且つ、2回目の抽選において当該ユーザの通信端末10が試合時間帯にスタジアム内に存在すると判別されたときに、当該ユーザの当選確率を例えば60%に設定してもよい。また、CPU21は、当該ユーザが2回目の抽選に当選しなかった場合には、当該ユーザが3回目の抽選にエントリーし、且つ、3回目の抽選において当該ユーザの通信端末10が試合時間帯にスタジアム内に存在すると判別されたときに、当該ユーザの当選確率を例えば100%に設定してもよい。なお、CPU21は、当該ユーザが抽選に当選した場合には、当該ユーザの抽選確率をデフォルト値に戻す。
【0076】
付与手段58は、ユーザ(第1のユーザ)が抽選に当選した場合に、当該ユーザに対してゲーム上の特典を付与する機能を備える。
ここで、「ユーザに対してゲーム上の特典を付与する」とは、特典(例えば、ポイント、アイテムなど)に関する情報をユーザのユーザIDに対応付けた状態で所定の記憶装置(例えばユーザデータベース31が構成された記憶装置など)に記憶させることであってよい。また、所定の記憶装置は、例えばゲームサーバ20に設けられていてもよいし、ユーザの通信端末10などに設けられていてもよい。
また、「ゲーム上の特典」とは、例えば、ゲーム上のポイント若しくはアイテム、又はゲーム上の有利な効果などであってよい。ここで、アイテムとは、例えば、ユーザがゲーム上保有することができるものであってもよいし、ユーザがゲーム上で収集する必要があるものであってもよいし、ユーザがゲーム上で有利な効果を得られるものなどであってもよい。例えば、アイテムは、キャラクタのパラメータやポイントなどを回復する回復薬や、キャラクタの能力を上昇させる薬品などであってもよいし、キャラクタが使用する武器や防具などであってもよい。なお、キャラクタとは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカード等に表示されているものをも含む。
なお、ゲーム上のポイントやアイテムが特典として付与される場合には、当該ポイントやアイテムは、ゲーム上の通常のプレイにおいて入手可能なものと比べて、多量のものあるいは希少価値の高いものであることが好ましい。例えば、アイテムの一例として選手カードが付与される場合には、上述したアイテム抽選処理では入手困難なレアカードが付与されるようにしてもよい。あるいは、例えば、アイテム抽選処理において、レアカードを必ず入手できるようにゲーム上の設定を調整するアイテム(例えば、特殊な抽選チケット)が付与されるようにしてもよい。この場合、特殊な抽選チケットが付与されたユーザは、任意のタイミングで当該抽選チケットをゲーム上使用することにより、レアカードを入手することが可能となる。
さらに、ゲーム上の有利な効果とは、例えば、ユーザがゲーム上保有するアイテム(例えば選手カード)のパラメータを上昇させることであってもよいし、アイテムを用いることなくキャラクタの能力を向上させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。また、ゲーム上の有利な効果とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作に応じて消費するゲーム上の各種ポイント(例えば、行動ポイント、運営ポイント、強化ポイントなど)の消費量を通常よりも低減させることであってもよいし、ユーザが上記の各種ポイントを入手できることであってもよい。なお、仲間を作ることでポイントを入手できる構成が既に設けられている場合には、そのポイントよりも多くのポイントを入手できるようにすればよい。さらに、ゲーム上の有利な効果とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよいし、強化処理において選手カードの能力値が大幅に上昇する確率を上昇させることであってもよい。
さらにまた、「ゲーム上の特典」とは、ユーザが実行するゲームと同一のゲーム上の特典であってもよいし、ユーザが実行するゲームとは異なる他のゲーム上の特典であってもよい。ここで、異なる他のゲームとは、例えば一つのゲームシリーズのように、ゲームの構成やジャンルがほぼ同じであるがゲームのタイトルが異なる場合(例えば、「ゲームA(2011年度版)」と「ゲームA(2012年度版)」など)も含む。
【0077】
付与手段58の機能は、以下のようにして実現できる。なお、ユーザに対して付与される特典の内容については、予めROM22に記録されているものとする。ゲームサーバ20のCPU21は、ユーザが抽選に当選した場合、当該ユーザに対して特典を付与する処理を行う。なお、特典を付与する処理とは、特典の付与対象となるユーザのユーザIDと、付与される特典(例えばポイントやアイテムなど)とを関連付ける処理であってよい。例えば、所定量の強化ポイントが特典として付与される場合、CPU21は、付与対象となるユーザのユーザIDのユーザデータにおける強化ポイントを書き換える処理(所定量の強化ポイントを加算する処理)を行ってよい。また、特典としてアイテムやポイントなどがユーザに付与される場合には、アイテムやポイントなどは、所定の特典付与期間内に複数回付与されてもよい。
【0078】
なお、ユーザに付与される特典は、各種ポイント(行動ポイント、運営ポイント、強化ポイント、エールポイント)の付与量を、所定の特典付与期間の間、通常(つまり、特典が付与されない状態)よりも増加させることであってもよい。ここで、各種ポイントのうち少なくとも一種類のポイントの付与量が増加するようにしてもよい。
この場合、ユーザは、特典を得ることにより、ゲームを有利に進めることができる。例えば、特典が、行動ポイントの付与量を増加させることである場合、通常であれば所定時間(例えば3分)が経過する度に行動ポイントが1ポイントずつ回復(増加)するのに対し、特典付与期間内では、行動ポイントが3ポイントずつ回復(増加)してもよい。この場合、ユーザは、スカウト処理を実行する際に、1回の探索を行うために必要な行動ポイントを通常よりも早期に得ることができるので、ゲームの進行度を通常よりも早く上げることができるというメリットが得られる。
【0079】
また、特典が、ユーザの保有する選手カードのパラメータを、特典付与期間の間上昇させることである場合、CPU21は、特典を付与する処理として、特典付与期間の間、付与対象となるユーザの保有カードのパラメータを所定の割合だけ加算するようにしてもよい。例えば、試合処理における試合の結果が選手カードのパラメータに基づいて決定される場合には、ユーザは、特典付与期間内の試合処理において、他のユーザとの試合に勝利する可能性を高めることができるので、他のユーザと比べてゲームをより優位に進められるようになる。なお、CPU21は、特典付与期間が終了すると、保有カードのパラメータを元の値に戻す。
さらに、特典が、本実施形態のゲームと異なる他のゲーム上の特典である場合、CPU21は、特典の付与対象となるユーザのユーザIDと、特典を付与することを通知するためのメッセージ等とを、他のゲームの実行を制御するゲームサーバに送信すればよい。この場合、他のゲームの実行を制御するゲームサーバは、本実施形態におけるゲームサーバ20と同様に構成されてもよい。例えば、他のゲームの実行を制御するゲームサーバでは、上記のユーザID及びメッセージ等を受信すると、当該ユーザIDに対応するユーザに対して特典が付与される処理を実行するように構成されてもよい。
【0080】
なお、付与手段58は、抽選に当選しなかったユーザに対して、所定量のポイントやアイテムなどを付与してもよい。ここで、抽選に当選しなかったユーザに付与されるポイントやアイテムなどは、上記特典よりも小さいことが好ましい。例えば、特典としてポイントやアイテムが付与される場合には、特典のポイント量(例えば、10000強化ポイント)よりも少ないポイント(例えば、1000強化ポイント)が付与されてもよいし、特典のアイテム(例えば、レア度が4あるいは5の選手カード)よりも希少価値の少ないアイテム(例えば、レア度が1あるいは2の選手カード)が付与されてもよい。この場合、CPU21は、上述した特典を付与する処理と同様の処理を行えばよい。
【0081】
(6)本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、
図14のフローチャートを参照して説明する。
図14は、本実施形態のゲームの抽選登録処理における処理内容の一例を示すフローチャートである。
【0082】
先ず、
図8に示すトップページ上でユーザの通信端末10のトップページ上でメニューm6の選択操作がなされ(ステップS100:YES)、その選択結果を受信すると、ゲームサーバ20のCPU21は、
図10に例示するウェブページを表示するためのHTMLデータを生成して、当該ユーザの通信端末10宛に送信する(ステップS110)。この場合、ユーザの通信端末10には、
図10に示すウェブページが表示される。次に、ユーザがメニューm11の選択操作を行うと(ステップS120:YES)、ゲームサーバ20のCPU21は、メニューm11の選択操作を行ったユーザのユーザIDを、ゲームデータベース32内のエントリーデータに記録する。このとき、CPU21は、記録したユーザIDに対応する当選確率の項目にNULLデータを記録する。つまり、ユーザが抽選にエントリーした時点では、抽選における当選確率は、デフォルトの値(例えば30%)に設定されている。
なお、ステップS120の処理において、メニューm11の選択操作が行われることなく所定時間が経過した場合(ステップS120:NO)、CPU21は、抽選登録処理を終了してもよい。この場合、CPU21は、
図8に示すトップページを表示するためのHTMLデータを生成して、ユーザの通信端末10宛に送信してもよい。
【0083】
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、
図15のフローチャートを参照して説明する。
図15は、本実施形態のゲームにおいて抽選が行われるときの処理内容の一例を示すフローチャートである。なお、ここでは、野球の試合時間帯(イベント期間)の所定時刻(抽選時刻)に抽選が行われる場合を一例として説明する。
【0084】
ゲームサーバ20のCPU21は、例えばCPU21に内蔵されたタイマによって所定の抽選時刻が到来したことを認識すると(ステップS200:YES)、
図11に例示したエントリーデータに記録されたユーザIDに対応するユーザを対象とした抽選処理を開始する。また、CPU21は、抽選処理の開始に当たって、位置情報の送信要求メッセージを、エントリーデータに記録されたユーザIDに対応するユーザの通信端末10宛に送信する(ステップS210)。なお、ユーザの通信端末10固有の端末識別情報は、例えば登録処理(ユーザ登録)の際に、ユーザIDに対応付けられた状態でユーザデータに記録されてもよい。
【0085】
次に、通信端末10のCPU11は、位置情報の送信要求メッセージを受信すると、通信端末10の現在位置をGPS測位部18に測位させる。そして、CPU11は、GPS測位部18の測位によって得られた位置情報を、ユーザIDと対応付けて、ゲームサーバ20に送信する。
一方、ゲームサーバ20のCPU21は、位置情報を通信端末10から受信する(取得する)と、取得した位置情報をゲームデータベース32内の現在位置データに記録する(ステップS220)。
【0086】
次に、ゲームサーバ20のCPU21は、エントリーデータに記録されたユーザIDに対応するユーザのうち、通信端末10が、野球の試合(イベント)の試合時間帯(イベント期間内)にスタジアム(所定領域)に存在するユーザを抽出する(ステップS230)。具体的に説明すると、CPU21は、エントリーデータに記録されたユーザIDごとに、現在位置データ内の当該ユーザIDに対応する最新の位置情報の緯度及び経度がスタジアム内に含まれ、且つ、当該ユーザIDに対応する最新の位置情報の取得日時が野球の試合時間帯に含まれるか否かを判別する。ここで、CPU21は、最新の位置情報の緯度及び経度がスタジアム内に含まれ、且つ、最新の位置情報の取得日時が野球の試合時間帯に含まれる場合、当該ユーザIDに対応するユーザの通信端末10が試合時間帯にスタジアム内に存在すると判別する。そして、CPU21は、試合時間帯にスタジアム内に存在すると判別された通信端末10に対応するユーザIDをエントリーデータから抽出する。
【0087】
次いで、CPU21は、抽出したユーザの仲間の数に応じて、当選確率を変動する(ステップS240)。具体的に説明すると、CPU21は、ステップS230にて抽出したユーザIDのユーザデータを参照し、当該ユーザIDに対応する仲間ユーザの数を取得する。そして、CPU21は、抽選制御データを参照して当該ユーザIDに対応するユーザの当選確率の調整値を決定する。そして、CPU21は、決定した当選確率の調整値を、エントリーデータ内の当該ユーザIDに対応する当選確率の値に加算する。
【0088】
次に、CPU21は、エントリーデータに記録されたユーザIDに対応するユーザごとに、抽選処理を行う(ステップS250)。なお、抽選処理における抽選方法は、上述したとおりである。この場合、CPU21は、エントリーデータのユーザIDに対応する当選確率にデフォルト値(
図11の例では30%)以外の値が設定されている場合には、記録された値に基づいて当選確率を調整した上で抽選処理を行う。
【0089】
そして、CPU21は、抽選に当選したユーザに対して特典を付与する(ステップS260)。例えば、所定量の強化ポイントが特典として付与される場合、CPU21は、付与対象となるユーザのユーザIDのユーザデータにおける強化ポイントを書き換える処理(所定量の強化ポイントを加算する処理)を行ってよい。
また、CPU21は、抽選にエントリーしたユーザに抽選結果を通知するためのウェブページを表示するためのHTMLデータを生成し、抽選にエントリーした全てのユーザの通信端末10宛に送信する(ステップS270)。ここで、CPU21は、抽選に当選したユーザに対して抽選結果を通知する場合、通知用のウェブページには、例えば「おめでとうございます。抽選に当選しましたので、プレゼントを贈ります。」などのメッセージが含まれてもよい。一方、CPU21は、抽選に当選しなかったユーザに対して抽選結果を通知する場合、通知用のウェブページには、例えば「ごめんなさい。残念ですが抽選に外れてしまいました。」などのメッセージが含まれてもよい。また、CPU21は、例えば抽選にエントリーしたことに対する報酬として、抽選に当選しなかったユーザに対して所定量のポイントやアイテムなどを付与してもよい。
【0090】
上述したように、実施形態のゲーム制御装置によれば、ゲーム上の抽選におけるユーザの当選確率は、当該ユーザの通信端末10が試合時間帯にスタジアムに存在すると判別された場合に、当該ユーザの仲間ユーザに関する情報に基づいて変動するようになっている。これにより、ユーザは、例えば、抽選に当選する可能性、すなわちゲーム上の特典を得る可能性を高めるために、他のユーザと関係付ける(仲間になる)ことが動機付けられる。このため、ユーザ間の交流を促進することができ、ソーシャル性の高いゲームを実現することができる。
また、ユーザは、例えば、抽選に当選する可能性、すなわちゲーム上の特典を得る可能性を高めるために、試合時間帯にスタジアムに出向く(野球の試合を観戦する)ことが動機付けられる。この場合、スタジアムで野球の試合を観戦することが抽選に当選する要因になり得ることから、ユーザは、野球の試合とゲームが連動しているような感覚を得ることができる。このため、通信端末10の位置情報を利用する従来のゲームでは実現することができない興趣性の高いゲームを実現することができる。一方、イベントの運営側にとっては、ユーザをイベント会場(例えば、スタジアム、ゲームセンター、競馬場、コンサートホールなど)に来場させる誘因力あるシステムを構築することができる。
【0091】
(7)変形例
以下、上述した実施形態の変形例について説明する。
【0092】
(7−1)変形例1
上記実施形態において、抽選手段54は、試合時間帯(イベント期間内)にスタジアム(所定領域)に通信端末10が存在すると判別されたユーザに対して抽選を行ってもよい。
本変形例では、抽選対象となるユーザは、自身の通信端末10が試合時間帯にスタジアムに存在すると判別されたユーザに限定される。つまり、ユーザにとっては、試合時間帯にスタジアムに出向かなければ(スタジアムで野球の試合を観戦しなければ)、ゲーム上の特典が付与される機会を得ることができない。このため、ユーザは、ゲーム上の特典が付与される機会を得るために、スタジアムで野球の試合を観戦することが動機付けられる。これにより、野球の試合の運営側にとっては、ユーザをスタジアムに来場させる誘因力を高めたシステムを構築することができる。
【0093】
本変形例における抽選手段54の機能は、以下のようにして実現される。ゲームサーバ20のCPU21は、例えば、
図15に示したフローのステップS250において、エントリーデータに記録されたユーザIDのうち、
図15に示したフローのステップS230にて抽出されたユーザIDに対応するユーザのみに対して抽選処理を行ってもよい。この場合、CPU21は、エントリーデータに記録されたユーザIDのうち、ステップS230にて抽出されなかったユーザIDに対応するユーザに対する抽選処理を行わない。
また、CPU21は、ユーザの通信端末10が試合時間帯にスタジアムに存在する場合に、当該ユーザによる抽選登録処理が実行されるように構成してもよい。具体的に説明すると、CPU21は、
図14に示したフローのステップS120においてメニューm11が選択操作されたことを認識すると、位置情報の送信要求メッセージを、メニューm11の選択操作を行ったユーザの通信端末10宛に送信する。そして、CPU21は、位置情報を通信端末10から受信すると、位置情報の緯度及び経度と、位置情報の取得日時とに基づいて、通信端末10が試合時間帯にスタジアムに存在するか否かを判別する。CPU21は、通信端末10が試合時間帯にスタジアムに存在すると判別した場合に、当該ユーザのユーザIDをエントリーデータに記録する。一方、CPU21は、通信端末10が試合時間帯にスタジアムに存在しないと判別した場合に、当該ユーザのユーザIDをエントリーデータに記録しない。この場合、CPU21は、エントリーデータに記録されたユーザIDに対応するユーザを対象として抽選を行うようにすればよい。
【0094】
(7−2)変形例2
上記実施形態において、抽選制御手段57は、仲間ユーザ(第2のユーザ)の通信端末10のうち試合時間帯(イベント期間内)にスタジアム(所定領域)に存在すると判別された通信端末10に関する情報に基づいて、抽選におけるユーザ(第1のユーザ)の当選確率が変動するように抽選手段54を制御してもよい。
例えば、ユーザと関係付けられた仲間ユーザの通信端末10のうち、試合時間帯にスタジアムに存在すると判別された通信端末10の数が多いほど、抽選におけるユーザの当選確率が高くなるように構成されてもよい。つまり、スタジアムにおいて野球を観戦する仲間ユーザの数が多いほど、ユーザの当選確率が高くなるように構成されてもよい。この場合、ユーザは、抽選に当選する可能性、すなわちゲーム上の特典を得る可能性を高めるために、仲間ユーザとスタジアムで野球を観戦することが動機付けられる。これにより、ゲーム上及び現実世界におけるユーザ間の交流を促進することができるため、ソーシャル性をさらに高めたゲームを実現することができる。
【0095】
本変形例における抽選制御手段57の機能は、以下のようにして実現される。なお、ここでは、スタジアムにおいて野球を観戦する仲間ユーザの数が多いほど、ユーザの当選確率が高くなる場合を一例として説明する。
ゲームサーバ20のCPU21は、例えば、
図16に例示した抽選制御データをユーザデータベース31に予め格納してもよい。
図16に本変形例における抽選制御データの構成例を示す。
図16に例示した抽選制御データの構成が
図13に示した抽選制御データの構成と異なる点は、ユーザの仲間ユーザのうち、試合時間帯(イベント期間内)にスタジアム(所定領域)に存在する仲間ユーザの数に応じて、ユーザの当選確率の調整値が設定されている点にある。
図16を参照して説明すると、例えば、仲間ユーザのうち、試合時間帯にスタジアムに存在する仲間ユーザの数が1名の場合には、抽選におけるユーザの当選確率が30%増加することになる。また、仲間ユーザのうち、試合時間帯にスタジアムに存在する仲間ユーザの数が2〜5名の場合には、抽選における当該ユーザの当選確率が40%増加する。さらに、仲間ユーザのうち、試合時間帯にスタジアムに存在する仲間ユーザの数が6〜10名の場合には、抽選における当該ユーザの当選確率が50%増加する。さらにまた、仲間ユーザのうち、試合時間帯にスタジアムに存在する仲間ユーザの数が10名以上の場合には、抽選における当該ユーザの当選確率が70%増加する。なお、当選確率の調整値は、所定の演算式等を用いて、仲間ユーザのうち試合時間帯にスタジアムに存在する仲間ユーザの数を当該演算式に当てはめることで求められてもよい。
CPU21は、ユーザの通信端末10が試合時間帯にスタジアムに存在すると判別された場合に、当該ユーザの仲間ユーザの通信端末10に対して、位置情報の送信要求メッセージを送信する。そして、CPU21は、当該ユーザの仲間ユーザの通信端末10のうち、試合時間帯にスタジアムに存在すると判別された通信端末10の数を集計し、抽選制御データを参照して当該ユーザの当選確率の調整値を決定する。そして、CPU21は、決定した当選確率の調整値を、エントリーデータ内の当該ユーザのユーザIDに対応する当選確率の項目に記録する。
【0096】
なお、上述した例では、ユーザの仲間ユーザのうち、試合時間帯にスタジアムに存在する仲間ユーザの数が多いほど、抽選における当該ユーザの当選確率が高くなる場合について説明したが、当選確率の変動パターンは、この場合に限られない。例えば、試合時間帯にスタジアムに存在する仲間ユーザの数が所定の閾値以上になった場合、試合時間帯にスタジアムに存在する仲間ユーザの数が多いほど、抽選におけるユーザの当選確率が低減するように構成されてもよい。この構成によれば、試合時間帯にスタジアムに存在する仲間ユーザの数の増加に伴ってユーザの当選確率が極めて高くなることに起因して、他のユーザとの間で公平性を損なうことのない仕組みとすることができる。
また、抽選におけるユーザの当選確率は、例えば、試合時間帯にスタジアムに存在する仲間ユーザがゲーム上保有するポイントの量やアイテムなどの数の合計が多いほど、高く又は低くなるように設定されてもよいし、試合時間帯にスタジアムに存在する仲間ユーザによって実行されたゲーム上の対戦数やゲーム上の対戦における仲間ユーザの勝利数又は敗北数の合計が多いほど、高く又は低くなるように設定されてもよい。
【0097】
(7−3)変形例3
上記実施形態において、付与手段58は、ユーザ(第1のユーザ)が抽選に当選し、且つ、当該ユーザの通信端末10が試合時間帯(イベント期間)の終了時期にスタジアム(所定領域)に存在すると判別された場合に、当該ユーザに対して特典を付与してもよい。
例えば、ユーザが抽選に当選すると、当該ユーザに対してゲーム上の特典が即時付与されるように構成されている場合、スタジアムで野球の試合を観戦したことに基づいて抽選に当選したユーザは、特典が付与されると直ちにスタジアムを去ることが考えられる。このような行為は、ユーザが自らの利益を得ることのみを目的としてスタジアムで野球の試合を観戦することになるため、野球の試合の運営側にとっては好ましくない。
本変形例によれば、ユーザの通信端末10の位置についての判別を試合時間帯の終了時期に行うことにより、例えば、ユーザの通信端末10が試合時間帯の終了時期にスタジアムに存在しないと判別された場合には、当該ユーザに対して特典を付与しない仕組みとすることができる。これにより、ユーザは、特典を得るために、試合時間帯にスタジアムに留まることが動機付けられる。したがって、上記の行為を抑制することができる。また、ユーザにイベント参加、観戦等を十分行ってもらえることにより、イベント運営側にとっても有益なゲームを実現することができる。
【0098】
本変形例における付与手段58の機能は、以下のようにして実現される。
ゲームサーバ20のCPU21は、例えば、
図15に示すフローのステップS240において当選確率が変動したユーザが抽選に当選した場合、試合時間帯の終了時期が到来するまでの間、当該ユーザに対して特典を付与する処理を行わなくてもよい。そして、CPU21は、試合時間帯の終了時期が到来したときに、当該ユーザの通信端末10に対して、位置情報の送信要求メッセージを送信する。そして、CPU21は、当該ユーザの通信端末10がスタジアムに存在すると判別した場合に、当該ユーザに対して特典を付与する処理を行う。なお、試合時間帯の終了時期に関する情報(例えば、試合の終了時刻や試合終了後のファンサービスの終了時刻など)は、ゲームデータベース32に逐次記録されるようにしてもよい。
【0099】
(7−4)変形例4
上記実施形態において、特典には、有効期間が設定されており、前記特典が野球の試合A(第1のイベント)に基づいて付与された場合に、当該特典の有効期間の終了時期は、前記特典の付与以降の時期であって、試合A以降に行われる野球の試合B(第2のイベント)の開始以前の時期に設定されてもよい。
ここで、「第2のイベント」は、「第1のイベント」と同じイベントであってもよいし、異なるイベントであってもよい。例えば、第1のイベントが野球の試合の場合には、第2のイベントは、野球の試合であってもよいし、サッカーの試合であってもよいし、音楽の演奏会などであってもよい。
例えば、ユーザ(第1のユーザ)が試合Aの試合時間帯に行われた抽選に当選した場合には、当該ユーザに付与される特典の有効期間は、試合Bの開始以前の時期に終了することになる。この場合、ユーザは、特典を続けて得る可能性を高めるために、スタジアムで試合Bを観戦することが動機付けられる。これにより、抽選に当選したユーザに対してスタジアムで試合Bを観戦するように誘導することができるので、イベントの運営側にとっては、ユーザをイベント会場に来場させる誘因力をさらに高めたシステムを構築することができる。
【0100】
本変形例において、ゲームサーバ20のCPU21は、例えば、
図17に例示した特典付与データをゲームデータベース32に予め格納してもよい。
図17に特典付与データの構成例を示す。
図17に示すように、特典付与データは、特典の付与対象となるユーザ(抽選に当選したユーザ)のユーザIDごとに、特典の有効期間などが含まれるデータである。有効期間に記述されるデータは、例えば、特典が付与された日時を有効期間の開始時期とし、試合Bの開始日時を有効期間の終了時期としてもよい。
図17を参照して説明すると、例えば、「000001」というユーザIDに対応するユーザが試合Aの試合時間帯に行われた抽選に当選し、且つ、当選に基づく特典が試合Aの終了時期に付与される場合、試合Aの終了時期(図の例では、2012年4月1日21時00分)が有効期間の開始時期として特典付与データに記録される。また、試合A以降に開催される試合Bの開始時期(図の例では、2012年4月2日18時00分)が有効期間の終了時期として特典付与データに記録される。
CPU21は、
図15に示すフローのステップS260において、抽選に当選したユーザに特典を付与する処理を行うとともに、当該ユーザのユーザIDと、特典の有効期間とを特典付与データに記録する。ここで、アイテム又はポイントが特典として付与された場合を一例として説明すると、CPU21は、ユーザが、特典として付与されたアイテム又はポイントをゲーム上で使用する際に、特典付与データを参照して、使用対象のアイテム又はポイントが当該ユーザのユーザIDに対応する有効期間の範囲内か否かを判別する。そして、CPU21は、有効期間の範囲内であると判別した場合に、当該アイテム又はポイントを使用する処理を行ってもよい。一方、CPU21は、有効期間の範囲外であると判別した場合、当該アイテム又はポイントを使用する処理を行わなくてもよい。また、CPU21は、例えば、所定時間(例えば1分)が経過するごとに特典付与データを参照し、有効期間が終了したアイテム又はポイントを消去する処理を行ってもよい。
【0101】
(7−5)変形例5
上記実施形態において、付与手段58は、野球の試合(イベント)の状況に応じて、特典を変動させてもよい。
ここで、「イベントの状況」とは、例えば、イベントの参加人数であってもよいし、イベントの進行度合いであってもよい。また、「イベントの状況」とは、例えば、イベントが野球やサッカーなどの競技である場合には、競技の結果(例えば試合結果)や競技時間などであってもよい。
例えば、スタジアムの来場者数(イベントの参加人数)が多いほど、抽選に当選することにより付与される特典が多くなるように構成されてもよい。この場合、抽選に当選したユーザは、付与される特典がスタジアムの来場者数に応じて変動することから、野球の試合とゲームが強く連動しているような感覚を得ることができる。このため、ゲームの興趣性をさらに高めることができる。
【0102】
本変形例における付与手段58の機能は、以下のようにして実現される。なお、ここでは、ユーザが来場したスタジアムを本拠地とするチーム(以降、ホームチームという。)の試合結果(イベントの状況)に応じて、特典が変動する場合を一例として説明する。ゲームサーバ20のCPU21は、例えば、
図18に示す設定例に基づき構成された設定用データをゲームデータベース32に予め格納してもよい。
図18に示す設定例では、ホームチームの試合結果(ホームチームが敗北、引き分け、勝利)に応じて、異なる特典(図の例では強化ポイントの量)が付与されるように設定されている。
図18を参照して説明すると、特典は、例えば、ホームチームが大差(図の例では5点差以上)で敗北した場合を最小(図の例では5000強化ポイント)として、ホームチームが小差(図の例では1〜4点差)で敗北した場合、ホームチームが引き分けた場合、ホームチームが小差(図の例では1〜4点差)で勝利した場合、ホームチームが大差(図の例では5点差以上)で勝利した場合の順に大きくなっていくように設定されている。この場合、より大きな特典(より多くの強化ポイント)が付与されることにより、ユーザにとってはゲームをより有利に進行させることができる。具体的に説明すると、付与される強化ポイントの量が多いほど、強化処理において選手カードを強化する回数を増やすことが可能となる。これにより、選手カードのパラメータを早めに上昇させることができるので、例えば、試合処理における試合の結果が選手カードのパラメータに基づいて決定される場合には、ユーザは、他のユーザとの試合に勝利する可能性を高めることができる。
なお、上述した設定例では、ホームチームが勝利した場合に大きな特典が付与されるように設定されているが、例えば、ホームチームが敗北した場合に大きな特典が付与されるように設定されてもよい。また、イベントの来場者が多いほど、大きな又は小さな特典が付与されるように設定されてもよい。さらに、イベント期間が長いほど、大きな又は小さな特典が付与されるように設定されてもよい。
【0103】
(7−6)変形例6
上記実施形態において、付与手段58は、ユーザ(第1のユーザ)及び仲間ユーザ(第2のユーザ)のそれぞれの通信端末10が試合時間帯(イベント期間内)にスタジアム(所定領域)に存在すると判別された場合に、ユーザ又は仲間ユーザが抽選に当選すると、ユーザ及び仲間ユーザに対して、ゲーム上の特典を付与してもよい。
本変形例によれば、例えば、ユーザと、仲間ユーザとがスタジアムで野球の試合を観戦している場合に、ユーザ又は仲間ユーザが抽選に当選すれば、両者に特典が付与される。この場合、ユーザは、自らが抽選に当選しなくても、仲間ユーザが当選すれば特典を得ることができる。これにより、ユーザは、特典を得る可能性を高めるために、仲間ユーザとスタジアムで野球の試合を観戦することが動機付けられる。これにより、仲間関係の構築が活性化され、ソーシャル性のさらなる向上が期待できる。
【0104】
本変形例における付与手段58の機能は、以下のようにして実現される。ゲームサーバ20のCPU21は、
図15に示すフローのステップS260において、当選したユーザに特典を付与する処理を行うとともに、当選したユーザのユーザIDに対応する仲間ユーザのユーザIDのうち、エントリーデータに記録されている(つまり、抽選登録処理を行った)仲間のユーザIDをユーザデータから抽出する。そして、CPU21は、抽出したユーザIDに対応する仲間ユーザの通信端末10宛に、位置情報の送信要求メッセージを送信する。次に、CPU21は、位置情報を仲間ユーザの通信端末10から受信すると、位置情報の緯度及び経度と、位置情報の取得日時とに基づいて、仲間ユーザの通信端末10が試合時間帯にスタジアムに存在するか否かを判別する。CPU21は、仲間ユーザの通信端末10が試合時間帯にスタジアムに存在すると判別した場合に、当該仲間ユーザに対して特典を付与する処理を行う。
【0105】
(7−7)変形例7
上記実施形態のゲーム制御装置の変形例7の機能ブロック図を
図19に示す。
図19に示すように、この機能ブロック図は、
図7に示したものとは、抽選制御手段57を設けていない点で異なる。
本変形例において、抽選手段54は、試合時間帯(イベント期間内)にスタジアム(所
定領域)に通信端末10が存在すると判別されたユーザ(第1のユーザ)と、当該ユーザに関係付けられた仲間ユーザ(第2のユーザ)とを対象としてゲーム上の抽選を行う機能を備える。ここで、仲間ユーザ(第2のユーザ)はスタジアムにいる必要はなく、その所在がどこであるかは問わない。本変形例の構成では、1回の抽選における抽選対象のユーザ数が、抽選にエントリーしたユーザの仲間ユーザ数に応じて実質的に増えることになるので、言わば、1回の抽選に対する抽選券の枚数を多くすることを擬似的に実現していることになる。
また、本変形例において、付与手段58は、抽選に当選した当選ユーザ及び当該当選ユーザに関係付けられたユーザ(仲間ユーザ)のうち、試合時間帯(イベント期間内)にスタジアム(所定領域)に通信端末10が存在すると判別されたユーザに対してゲーム上の特典を付与する機能を備える。
本変形例では、抽選対象となるユーザは、試合時間帯にスタジアムに通信端末10が存在すると判別されたユーザだけでなく、当該ユーザに関係付けられた仲間ユーザをも
含むことになる。そして、当選ユーザ及び当該当選ユーザの仲間ユーザのうち、試合時間帯にスタジアムに通信端末10が存在すると判別されたユーザに対してゲーム上の特典が付与される。この場合、試合時間帯にスタジアムに出向いたユーザは、自身が抽選に当選しなくても、仲間ユーザが抽選に当選すれば、その仲間ユーザがスタジアムにいなくてもゲーム上の特典を得ることができる。つまり、試合時間帯にスタジアムに出向いたユーザにとっては、仲間ユーザの数が多いほど、自身及び仲間ユーザの少なくとも何れかが抽選に当選する可能性を高めることができ、ひいてはゲーム上の特典を得る可能性を高めることができる。このため、ユーザは、ゲーム上の特典を得る可能性を高めるために、スタジアムで野球の試合を観戦すること及び多くの他のユーザと仲間になることが動機付けられる。
【0106】
本変形例における抽選手段54の機能は、例えば以下のようにして実現される。ゲームサーバ20のCPU21は、例えば、
図11に例示したエントリーデータの代わりに、
図20に示すエントリーデータをゲームデータベース32に記憶してもよい。
図20に示すエントリーデータは、抽選登録処理を行った(メニューm11の選択操作を行った)ユーザのユーザIDと、当該ユーザIDに対応付けられた仲間のユーザIDとが記述されたデータである。CPU21は、例えば、ユーザがメニューm11の選択操作を行うと、メニューm11の選択操作を行ったユーザのユーザIDと、当該ユーザIDに対応する仲間のユーザIDとを、エントリーデータに記録する。
また、CPU21は、例えばCPU21に内蔵されたタイマによって所定の抽選時刻が到来したことを認識すると、
図20に例示したエントリーデータに記録されたユーザIDに対応するユーザと、当該ユーザIDに対応する仲間のユーザIDに対応する仲間ユーザを対象とした抽選処理を行う。ここで、CPU21は、エントリーデータに記録されたユーザIDに対応するユーザのうち、試合時間帯にスタジアムに通信端末10が存在しないと判別されたユーザ及び当該ユーザの仲間ユーザを抽選対象から除いてもよい。また、抽選処理は、例えば、エントリーデータに記録されたユーザID及び当該ユーザIDに対応する仲間のユーザIDから所定数のユーザIDをランダム、あるいは所定の規則に基づいて抽出することにより行われてもよい。この抽選処理の結果、抽出された所定数のユーザIDユーザのそれぞれに対応するユーザが、当選ユーザとなる。
なお、ユーザの仲間ユーザについて、抽選対象となるための条件を設けてもよい。例えば、ユーザの仲間ユーザのうち、当該ユーザとの関係度を示す親密度が所定の閾値以上の仲間ユーザを抽選対象としてもよい。ここで、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものであってもよく、例えば、ユーザ間の応援メッセージの送信あるいは受信の頻度(応援頻度)、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数(プレゼント回数)などに基づいて設定されてもよい。例えば、応援頻度やプレゼント回数が多いほど、親密度が高く設定されてもよい。この場合、ユーザは、抽選に当選する可能性を高めるために、抽選対象となり得る(つまり、親密度の高い)仲間ユーザの数を増やすことが動機付けられる。これにより、ユーザ間の交流をさらに促進することができるので、ソーシャル性を高めることができる。
【0107】
次に、本変形例における付与手段58の機能は、例えば以下のようにして実現される。ゲームサーバ20のCPU21は、当選ユーザ及び当該当選ユーザの仲間ユーザの通信端末10に対して、位置情報の送信要求メッセージを送信する。そして、CPU21は、当選ユーザ及び当該当選ユーザの仲間ユーザのうち、通信端末10がスタジアムに存在すると判別されたユーザに対して特典を付与する処理を行う。ここで、当選ユーザと、特典が付与されるユーザとの関係について、
図20のエントリーデータを参照して説明する。例えば、ユーザIDが「002244」のユーザが、試合時間帯にスタジアムに出向いている場合、当該ユーザ及び当該ユーザの仲間ユーザ(ユーザIDは「121212,…」)のうち少なくとも一人のユーザが当選ユーザになると、ユーザIDが「002244」のユーザに対して特典が付与される。なお、この場合、仲間ユーザが当選ユーザになったとしても、当該仲間ユーザが試合時間帯にスタジアムに出向いていなければ、当該仲間ユーザに対して特典が付与されない。
【0108】
次に、本変形例のゲーム制御装置により行われる主要な処理のフローの一例について、
図21のフローチャートを参照して説明する。
図21は、ゲーム上の抽選が行われるときの処理内容の一例を示すフローチャートである。なお、ここでは、野球の試合時間帯(イベント期間)の所定時刻(抽選時刻)に抽選が行われる場合を一例として説明する。
【0109】
ゲームサーバ20のCPU21は、例えばCPU21に内蔵されたタイマによって所定の抽選時刻が到来したことを認識すると(ステップS300:YES)、
図20に例示したエントリーデータに記録されたユーザIDに対応するユーザ及び当該ユーザの仲間ユーザを対象とした抽選処理を開始する。また、CPU21は、抽選処理の開始に当たって、位置情報の送信要求メッセージを、エントリーデータに記録されたユーザIDに対応するユーザの通信端末10宛に送信する(ステップS310)。なお、ユーザの通信端末10固有の端末識別情報は、例えば登録処理(ユーザ登録)の際に、ユーザIDに対応付けられた状態でユーザデータに記録されてもよい。
【0110】
次に、通信端末10のCPU11は、位置情報の送信要求メッセージを受信すると、通信端末10の現在位置をGPS測位部18に測位させる。そして、CPU11は、GPS測位部18の測位によって得られた位置情報を、ユーザIDと対応付けて、ゲームサーバ20に送信する。
一方、ゲームサーバ20のCPU21は、位置情報を通信端末10から受信する(取得する)と、取得した位置情報をゲームデータベース32内の現在位置データに記録する(ステップS320)。
【0111】
次に、ゲームサーバ20のCPU21は、エントリーデータに記録されたユーザIDに対応するユーザのうち、試合時間帯(イベント期間内)にスタジアム(所定領域)に通信端末10が存在すると判別されたユーザと、当該ユーザの仲間ユーザとを対象としてゲーム上の抽選処理を行う(ステップS330)。抽選処理の結果、例えば所定数のユーザが当選ユーザとなる。
【0112】
次いで、CPU21は、当選ユーザ及び当該当選ユーザの仲間ユーザのうち、試合時間帯(イベント期間内)にスタジアム(所定領域)に通信端末10が存在すると判別されたユーザに対して特典を付与する処理を行う(ステップS340)。
【0113】
また、CPU21は、抽選にエントリーしたユーザに抽選結果を通知するためのウェブページを表示するためのHTMLデータを生成し、抽選にエントリーした全てのユーザの通信端末10宛に送信する(ステップS350)。ここで、CPU21は、抽選に当選して特典が付与されたユーザに対して抽選結果を通知する場合、通知用のウェブページには、例えば「おめでとうございます。あなたは抽選に当選しましたので、プレゼントを贈ります。」などのメッセージが含まれてもよい。また、CPU21は、ユーザ自身は抽選には当選しなかったが仲間ユーザが抽選に当選したことにより特典が付与されたユーザに対して抽選結果を通知する場合、通知用のウェブページには、例えば「おめでとうございます。あなたの仲間が抽選に当選しましたので、あなたにプレゼントを贈ります。」などのメッセージが含まれてもよい。一方、CPU21は、自身及び仲間が抽選に当選しなかったユーザに対して抽選結果を通知する場合、通知用のウェブページには、例えば「ごめんなさい。残念ですが抽選に外れてしまいました。」などのメッセージが含まれてもよい。また、CPU21は、例えば抽選にエントリーしたことに対する報酬として、自身及び仲間が抽選に当選しなかったユーザに対して所定量のポイントやアイテムなどを付与してもよい。
【0114】
以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。
【0115】
上述した実施形態では、ユーザと通信端末10が1対1の関係である場合について説明したが、これに限られない。例えば、ユーザは、自身の保有する通信端末と異なる他の通信端末(例えば、複数のユーザが共有して使用する通信端末など)を用いてもよい。つまり、上述した実施形態では、現在位置データがユーザIDに対応付けられて管理されているので、ユーザが他の通信端末を用いた場合であっても、他の通信端末によって測位された位置情報を当該ユーザのユーザIDと対応付けることにより、ユーザの現在位置を認識することができる。
【0116】
また、上述した実施形態では、通信端末10のGPS測位部18が、通信端末10の位置情報を取得する構成例を示しているが、これに限定されるものではない。
例えば、通信端末10が無線電話機能(携帯電話機能またはPHS(Personal Handy-phone System)機能)を備える場合には、無線電話基地局の有する基地局識別情報を、通信端末10の位置情報として用いることもできる。すなわち、携帯電話やPHSの各基地局は、所定の通信エリアを有してセル状に配置されており、各基地局から受信した基地局識別情報に基づいて、当該基地局の通信エリア内に通信端末100が存在することを認識できる。この場合、GPS測位部18を用いたときと比較して、位置情報としての精度が低いものの、基地局識別情報を位置情報として利用することが可能である。
【0117】
また、例えば、通信端末10がWi−Fi(wireless fidelity、登録商標)等の無線LAN通信機能を備える場合には、無線通信親機(無線LANアクセスポイント又はルータ等)の識別情報(例えば、MAC(Media Access Control)アドレスまたはIP(Internet Protocol)アドレス)を位置情報として用いることもできる。すなわち、所定のエ
リアを無線通信範囲とする無線通信親機(一つまたは複数の無線LANアクセスポイント又はルータ等)を設置し、ユーザが、通信端末10を無線LANアクセスポイント等の無線通信親機にアクセスしたときに、通信端末10が、無線通信親機の識別情報を位置情報として取得するように構成する。この場合、ゲームサーバ20は、取得した無線通信親機の識別情報に基づいて、当該無線通信親機の通信エリア内に通信端末10が存在することを認識できるので、無線通信親機の識別情報を位置情報として利用することが可能である。
【0118】
さらに、取得手段55は、例えば、撮像装置(カメラ)が通信端末10に搭載されている場合、ユーザが所定の場所に存在しないと撮像することができない画像情報やバーコード情報などを位置情報として取得してもよい。例えば、所定の場所がスタジアムの場合には、スタジアム内の所定の領域に設置されたモニタや電光掲示板等の表示装置に画像情報やバーコード情報などを表示し、ユーザが当該画像情報やバーコード情報などを撮像できるようにしてもよい。また、取得手段55は、ユーザが所定の場所に存在しないと確認することができない合言葉やパスワード等の文字・数字・記号情報等を位置情報として取得してもよい。すなわち、ユーザは、上記の撮像に代えて、文字・数字・記号情報等を手入力あるいは音声入力することができるような構成としてもよい。
なお、ユーザが所定の場所に存在しないと撮像あるいは確認することができない画像情報等は、その画像情報等を取得したユーザによって他のユーザに転送される場合がある。この場合、所定の場所に存在していない他のユーザが、当該画像情報等を入手することが可能となるため、通信端末10の正確な現在位置を取得することが困難になる。
そこで、所定の場所で撮像あるいは確認できる画像情報等を所定時間毎(例えば1分毎)に変化させて、撮像あるいは確認した画像情報等に有効期限を設けてもよい。この場合、所定時間毎に変化する画像情報等を生成する情報生成部を備えるとともに、所定の場所を含むエリアを無線通信範囲とする無線通信親機(一つまたは複数の無線LANアクセスポイント又はルータ等)を設置し、ユーザが通信端末10を無線LANアクセスポイント等にアクセスすれば、無線LANアクセスポイント等に接続された情報生成部から所定時間毎に変化する画像情報等を取得できるように構成してもよい。なお、この構成を実現するために、情報生成部とゲームサーバ20とは時刻同期をしており、両者は同じアルゴリズムを用いて画像情報等を所定時間毎に変化させながら生成することが好ましい。
【0119】
上述した実施形態では、ユーザによる通信端末に対する所定の操作入力は、ユーザの通信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチャによる操作入力(ジェスチャ入力)であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能な通信端末の場合には、操作入力は、音声を入力することにより行われてもよい。
【0120】
上述した実施形態では、実行対象のゲームがデジタルカードゲームである場合の例について説明したが、本発明のゲームはこれに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲーム、テーブルゲーム、パズルゲーム、スポーツゲーム、レースゲーム、シューティングゲーム、アクションゲーム、アドベンチャーゲーム、シミュレーションゲームなどの各種ジャンルのゲームにおいてゲーム上の抽選が行われる場合には、本発明を好適に適用することができる。
【0121】
上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。
【0122】
例えば、上述した実施形態では、ネットワーク上のゲームサーバ20及びデータベースサーバ30によって、関係付け手段53、抽選手段54、取得手段55、判別手段56、抽選制御手段57及び付与手段58の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末10によって実現する構成としてもよいし、少なくとも一部の手段を通信端末10によって実現する構成としてもよい。通信端末10とゲームサーバ20とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末10によっても各機能を実現できる。例えば、
図22(a),(b)には、
図7に示した機能ブロック図の各機能について、通信端末10と、ゲームサーバ20及びデータベースサーバ30との機能分担の例を示す。なお、上述した実施形態では、各種データ(例えば、エントリーデータや抽選制御データなど)をデータベースサーバ30(ゲームデータベース32)が記憶している構成としたが、通信端末10内の記憶装置に記憶させてもよい。その場合には、記憶装置は、通信端末10内のRAM13や図示しないHDD(Hard Disk Drive)などの大容量記憶装置であってよい。