JP5149342B2 - ゲーム提供システム、プログラム、及び情報記憶媒体 - Google Patents

Description

本発明は、ゲーム提供システム、プログラム、及び情報記憶媒体に関する。

従来から、ソーシャル・ネットワーキング・サービス（以下、「ＳＮＳ」という。）と呼ばれる、コミュニティ型のサービスをユーザに提供するネットワークシステムが知られている。このようなネットワークシステムでは、ユーザが友人を自らのフレンドリストに追加して、友人に自己の日記を見せたり、メール交換する等によりコミュニティを図ることを目的としている（特許文献１）。

最近では、ＳＮＳでゲームを提供し、ゲーム結果をメールで友人に通知したり、日記やマイページに披露したりして楽しむユーザも多い。

またＳＮＳのサービスは、携帯電話等の移動端末にも提供されており、移動時間の合間に、ＳＮＳで提供されるゲームを楽しむことも可能である。

特開２００８−２４２９８９

最近では携帯電話等の移動端末はＧＰＳ等の位置情報取得システムを搭載しているものが多く、この様なシステムを利用して様々なサービスも提供され始めている。

携帯電話等の移動端末を用いてＳＮＳで提供されるゲームを楽しむユーザは、移動中移動先でゲームを行うことが多い。従って位置情報取得システムで取得された現在位置の情報をゲーム要素として活用することで、ゲームをバラエティに富んだものとすることができる。

かかるユーザの現在位置情報を活用したゲームは、幾つか提供されているが、いずれもユーザ自身の現在位置に関するゲーム動作でゲームが閉じており、他のユーザの現在位置に関するゲーム動作から影響を受けたり、自己の現在位置に関するゲーム動作が他のユーザに影響を与えたりするものではなく、他のユーザと影響を与えあっているという感覚を味わうことはできなかった。

本発明は、以上のような課題に鑑みてなされたものであり、その目的とするところは、複数のユーザの現在位置情報をうまく活用して、各ユーザの現在位置を活用したゲーム動作が、他のユーザのゲームに影響を与えることの可能なゲーム提供システム、プログラム、及び情報記憶媒体を提供することにある。

（１）本発明は、
サーバがネットワークを介して複数の移動端末にゲームを提供するゲーム提供プログラムであって、
前記移動端末において取得した現在位置情報に基づき、取得した現在位置から所与の範囲内の位置情報に対応づけられた仮想イベントエリアを抽出する仮想イベントエリア抽出手段と、
仮想イベントエリア抽出手段が抽出した仮想イベントエリアに関する情報を取得候補情報として移動端末を介してユーザに提供し、提供した取得候補情報の仮想イベントエリアに対する取得要求を前記移動端末から受け取った場合、当該仮想イベントエリアをユーザの取得情報としてユーザ識別情報に対応づけて記憶させる取得処理手段と、
仮想イベントエリア抽出手段が抽出した仮想イベントエリアに関する情報を訪問候補情報として移動端末を介してユーザに提供し、提供した訪問候補情報の仮想イベントエリアに対する訪問要求を前記移動端末から受け取る訪問処理手段と、
前記仮想イベントエリアの取得要求及び／又は訪問要求に応じて、ユーザの成績値及びゲームパラメータの少なくとも１つを演算するパラメータ演算手段と、してコンピュータを機能させ、
前記パラメータ演算手段は、
仮想イベントエリアに対する訪問要求を受け取った場合、当該仮想イベントエリアを取得情報として記憶するユーザの成績値又は所定のゲームパラメータを変更することを特徴とする。

現在位置情報は、実世界の緯度、経度、住所、最寄りの基地局等の情報でもよい。

取得処理手段は、取得した現在位置情報の示す位置から所定範囲内の（例えば実世界の）位置情報に対応づけられた仮想イベントエリアを抽出して、取得候補情報として提供してもよい。また抽出した仮想イベントエリアの中から所定の条件を満たす仮想イベントエリアを、取得候補情報としてもよい。所定の条件とは、例えば仮想イベントエリアの仮想価格と、ユーザのゲームパラメータ（例えば所持金）等により定まる条件でもよい。

訪問処理手段は、取得した現在位置情報の示す位置から所定範囲内の（例えば実世界の）位置情報に対応づけられた仮想イベントエリアを抽出して、訪問候補情報として提供してもよい。

また抽出した仮想イベントエリアの中にユーザの取得した仮想イベントエリアが含まれている場合にはこれを除いた仮想イベントエリアを取得候補情報として提供してもよい。

パラメータ演算手段は、ユーザの取得した仮想イベントエリアに対する他のユーザの訪問要求を受け取った場合には、ユーザの成績値又は所定のゲームパラメータを有利に変更してもよい。また他のユーザの訪問回数が多いほど、ユーザの成績値又は所定のゲームパラメータを有利に変更してもよい。

ユーザの取得情報として、ユーザの識別情報（移動端末の機器ＩＤ又はゲームにおいて指定されたユーザＩＤ）に関連づけて仮想イベントエリアの識別情報（ＩＤやコード）を記憶させてもよい。

ユーザの取得した仮想イベントエリアに対して、当該ユーザは訪問要求を行えないようにしてもよい。

例えば訪問要求が所定の条件を満たしていない場合には、訪問要求を行えないようにしてもよい。

このように、ユーザの実世界での位置に基づき取得した仮想イベントエリアに他のユーザの実世界での位置に基づきなされた訪問があると、ユーザのゲーム成績やパラメータを変更するゲームを提供することができる。

従って、各ユーザの現在位置情報を用いたゲーム動作が当該ユーザや他のユーザの成績やゲームパラメータに影響を与えるとともに、他のユーザの現在位置情報を用いたゲーム動作が当該ユーザの成績やゲームパラメータにも影響するというおもしろいゲームを提供することができる。

本発明によれば、複数のユーザの現在位置情報をうまく活用して、各ユーザの現在位置を活用したゲーム動作が、他のユーザのゲーム結果に影響を与えることの可能なプログラムを提供することができる。

（２）このプログラムにおいて、
前記訪問処理手段は、
仮想イベントエリアへの訪問要求を受け取った場合、訪問要求元のユーザの識別情報を当該仮想イベントエリアに対応づけられた訪問記録情報として記憶させ、
前記パラメータ演算手段は、
ユーザと友人関係にある他のユーザを特定するための友人情報及び訪問記録情報に基づき、当該仮想イベントエリアに訪問要求を行ったユーザと当該仮想イベントエリアを取得情報として記憶するユーザとが友人関係にあるか否かを判定して、友人関係にあると判断した場合には、友人関係にない場合に比べて、当該仮想イベントエリアを取得情報として記憶するユーザの成績値又は所定のゲームパラメータをより有利に変更してもよい。

（３）このプログラムにおいて、
前記訪問処理手段は、
前記友人情報に基づき、ユーザと友人関係にある他のユーザを判断して、当該他のユーザの取得情報として記憶された仮想イベントエリアを、訪問候補情報として、移動端末を介してユーザに提供してもよい。

（４）このプログラムにおいて、
前記パラメータ演算手段は、
仮想イベントエリアへの訪問要求を受け取った場合、訪問要求元のユーザの成績値又は所定のゲームパラメータを変更してもよい。

（５）このプログラムにおいて、
ユーザと友人関係にあり、ゲームユーザとして登録されている他のユーザに関する情報を、協力者候補情報として、移動端末を介してユーザに提供し、前記移動端末から、他のユーザを指定した協力要求を受け取った場合、当該他のユーザをユーザの協力者として登録する協力者登録手段と、してさらにコンピュータを機能させ、
前記パラメータ演算手段は、
ユーザに協力者が登録された場合には、当該ユーザの成績値及びゲームパラメータの少なくとも１つを変更してもよい。

（６）このプログラムにおいて、
前記取得処理手段は、
前記友人情報および取得情報に基づき、抽出した仮想イベントエリアの取得者に要求元のユーザと友人関係にあるユーザがいるか否か判断し、判断結果に基づきユーザの移動端末に提供する際の優先順位を決定してもよい。

（７）このプログラムにおいて、
前記位置情報に対応する地価情報に基づき、仮想イベントエリアの仮想価格を演算する仮想価格演算手段と、してさらにコンピュータを機能させ、
前記取得処理手段は、
抽出した仮想イベントエリアの前記仮想価格を含む情報を、移動端末を介してユーザに提供してもよい。

（８）このプログラムにおいて、
前記パラメータ演算手段は、
ユーザの取得情報として記憶されている仮想イベントエリアについて、当該仮想イベントエリアの仮想価格に基づいてユーザの成績値及びゲームパラメータの少なくとも１つを演算してもよい。

（９）このプログラムにおいて、
前記取得処理手段は、
取得した現在位置情報と、仮想イベントエリアに対応づけられた位置情報に基づき、現在位置から所定範囲内にある仮想イベントエリアであって、所与の金額以下の仮想価格を有する仮想イベントエリアを抽出して取得候補情報として提供するよう構成され、
前記所定範囲内に取得候補がない場合には、所定範囲を段階的に拡大して所与の金額以下の仮想価格を有する仮想イベントエリアを抽出して取得候補としてもよい。

（１０）このプログラムにおいて、
前記仮想イベントエリアに関連づけて他のアプリケーションにより更新可能な評価情報が記憶されており、
前記仮想価格演算手段は、
仮想イベントエリアに関連づけて記憶されている評価情報に基づいて、当該仮想イベントエリアの仮想価格の演算を行ってもよい。

（１１）このプログラムにおいて、
前記パラメータ演算手段は、
ユーザの取得物である仮想イベントエリアについて、所定の条件にしたがって設定された上限値に達するまで仮想売上値を増加させる処理を行い、
前記移動端末からユーザの取得した仮想イベントエリアについての売上回収要求を受け付けた場合には、仮想売上値を当該ユーザの所持金に参入して、仮想売上値をリセットする仮想売上回収処理を行う仮想売上回収処理手段を含んでもよい。

（１２）このプログラムにおいて、
友人関係にある他のユーザの取得した仮想イベントエリアについては取得できないように排他制御を行う排他制御処理手段と、してさらにコンピュータを機能させてもよい。

例えば取得要求を行った後発ユーザは当該仮想イベントエリアについて取得できないよう排他制御を行ってもよい。

（１３）このプログラムにおいて、
前記排他制御処理手段は、
仮想イベントエリア抽出手段が抽出した仮想イベントエリアを取得したユーザの中にユーザと友人関係にある他のユーザいる場合には、前記他のユーザ対して交渉要求を通知するとともに、他のユーザから交渉受け入れ可を示す応答を受信した場合には、他のユーザの当該仮想イベントエリアの取得を解除するとともに、ユーザについて当該仮想イベントエリアを取得させる処理を行ってもよい。

（１４）本発明は、上記のいずれかのプログラムが記憶されたコンピュータ読み取り可能な情報記憶媒体である。

（１５）本発明は、
サーバがネットワークを介して複数の移動端末にゲームを提供するゲーム提供システムであって、
仮想イベントエリアとそれに対応する位置情報を含む仮想イベントエリア情報が記憶された仮想イベントエリア情報記憶手段と、
前記移動端末において取得した現在位置情報に基づき、取得した現在位置から所与の範囲内の位置情報に対応づけられた仮想イベントエリアを抽出する仮想イベントエリア抽出手段と、
仮想イベントエリア抽出手段が抽出した仮想イベントエリアに関する情報を取得候補情報として移動端末を介してユーザに提供し、提供した取得候補情報の仮想イベントエリアに対する取得要求を前記移動端末から受け取った場合、当該仮想イベントエリアをユーザの取得情報としてユーザ識別情報に対応づけて記憶させる取得処理手段と、
仮想イベントエリア抽出手段が抽出した仮想イベントエリアに関する情報を訪問候補情報として移動端末を介してユーザに提供し、提供した訪問候補情報の仮想イベントエリアに対する訪問要求を前記移動端末から受け取る訪問処理手段と、
前記仮想イベントエリアの取得要求及び／又は訪問要求に応じて、ユーザの成績値及びゲームパラメータの少なくとも１つを演算するパラメータ演算手段と、を含み、
前記パラメータ演算手段は、
仮想イベントエリアに対する訪問要求を受け取った場合、当該仮想イベントエリアを取得情報として記憶するユーザの成績値又は所定のゲームパラメータを変更することを特徴とする。

ゲーム提供システムは、１のサーバで実現してもよい。また複数のサーバで実現し、複数のサーバに本ゲームシステムの処理を分散して実行させてもよい。

（１６）このゲーム提供システムにおいて、
ユーザと友人関係にある他のユーザを特定するための友人情報を含むユーザ情報が記憶されたユーザ情報記憶手段を含み、
前記訪問処理手段は、
仮想イベントエリアへの訪問要求を受け取った場合、訪問要求元のユーザの識別情報を当該仮想イベントエリアに対応づけられた訪問記録情報として記憶させ、
前記パラメータ演算手段は、
ユーザと友人関係にある他のユーザを特定するための友人情報及び訪問記録情報に基づき、当該仮想イベントエリアに訪問要求を行ったユーザと当該仮想イベントエリアを取得情報として記憶するユーザとが友人関係にあるか否かを判定して、友人関係にあると判断した場合には、友人関係にない場合に比べて、当該仮想イベントエリアを取得情報として記憶するユーザの成績値又は所定のゲームパラメータをより有利に変更してもよい。

（１７）このゲーム提供システムにおいて、
前記訪問処理手段は、
前記友人情報に基づき、ユーザと友人関係にある他のユーザを判断して、当該他のユーザの取得情報として記憶された仮想イベントエリアを、訪問候補情報として、移動端末を介してユーザに提供してもよい。

（１８）このゲーム提供システムにおいて、
前記パラメータ演算手段は、
仮想イベントエリアへの訪問要求を受け取った場合、訪問要求元のユーザの成績値又は所定のゲームパラメータを変更してもよい。

（１９）このゲーム提供システムにおいて、
ユーザと友人関係にあり、ゲームユーザとして登録されている他のユーザに関する情報を、協力者候補情報として、移動端末を介してユーザに提供し、前記移動端末から、他のユーザを指定した協力要求を受け取った場合、当該他のユーザをユーザの協力者として登録する協力者登録手段と、を含み、
前記パラメータ演算手段は、
ユーザに協力者が登録された場合には、当該ユーザの成績値及びゲームパラメータの少なくとも１つを変更してもよい。

（２０）このゲーム提供システムにおいて、
前記取得処理手段は、
前記友人情報および取得情報に基づき、抽出した仮想イベントエリアの取得者に要求元のユーザと友人関係にあるユーザがいるか否か判断し、判断結果に基づきユーザの移動端末に提供する際の優先順位を決定してもよい。

（２１）このゲーム提供システムにおいて、
位置情報に対応する地価情報が記憶された地価情報記憶手段と、
前記位置情報に対応する地価情報に基づき、仮想イベントエリアの仮想価格を演算する仮想価格演算手段と、を含み、
前記取得処理手段は、
抽出した仮想イベントエリアの前記仮想価格を含む情報を、移動端末を介してユーザに提供してもよい。

（２２）このゲーム提供システムにおいて、
前記パラメータ演算手段は、
ユーザの取得情報として記憶されている仮想イベントエリアについて、当該仮想イベントエリアの仮想価格に基づいてユーザの成績値及びゲームパラメータの少なくとも１つを演算してもよい。

（２３）このゲーム提供システムにおいて、
前記取得処理手段は、
取得した現在位置情報と、仮想イベントエリアに対応づけられた位置情報に基づき、現在位置から所定範囲内にある仮想イベントエリアであって、所与の金額以下の仮想価格を有する仮想イベントエリアを抽出して取得候補情報として提供するよう構成され、
前記所定範囲内に取得候補がない場合には、所定範囲を段階的に拡大して所与の金額以下の仮想価格を有する仮想イベントエリアを抽出して取得候補としてもよい。

（２４）このゲーム提供システムにおいて、
前記仮想イベントエリアに関連づけて他のアプリケーションにより更新可能な評価情報が記憶されており、
前記仮想価格演算手段は、
仮想イベントエリアに関連づけて記憶されている評価情報に基づいて、当該仮想イベントエリアの仮想価格の演算を行ってもよい。

（２５）このゲーム提供システムにおいて、
前記パラメータ演算手段は、
ユーザの取得物である仮想イベントエリアについて、所定の条件にしたがって設定された上限値に達するまで仮想売上値を増加させる処理を行い、
前記移動端末からユーザの取得した仮想イベントエリアについての売上回収要求を受け付けた場合には、仮想売上値を当該ユーザの所持金に参入して、仮想売上値をリセットする仮想売上回収処理を行う仮想売上回収処理手段を含んでもよい。

（２６）このゲーム提供システムにおいて、
友人関係にある他のユーザの取得した仮想イベントエリアについては取得できないように排他制御を行う排他制御処理手段と、してさらにコンピュータを機能させてもよい。

（２７）このゲーム提供システムにおいて、
前記排他制御処理手段は、
仮想イベントエリア抽出手段が抽出した仮想イベントエリアを取得したユーザの中にユーザと友人関係にある他のユーザいる場合には、前記他のユーザ対して交渉要求を通知するとともに、他のユーザから交渉受け入れ可を示す応答を受信した場合には、他のユーザの当該仮想イベントエリアの取得を解除するとともに、ユーザについて当該仮想イベントエリアを取得させる処理を行ってもよい。

本実施形態のゲーム提供システムのネットワーク図の一例。 本実施形態の移動端末のブロック図。 本実施形態のサーバの機能ブロック図。 ユーザ情報について説明するための図。 店舗情報について説明するための図。 地価情報について説明するための図 ゲームサイクルの一例について説明するための図。 ユーザに関するゲームデータについて説明するための図。 店舗に関するゲームデータについて説明するための図。 移動端末の画面遷移図。 図１１（Ａ）〜（Ｃ）は、店舗の表示優先順位について説明するための図。 移動端末の画面遷移図。 移動端末の画面遷移図。 移動端末の画面遷移図。 図１５（Ａ）（Ｂ）は、アルバイト先候補店舗の表示優先順位について説明するための図。 ユーザ情報データベースに登録されている友人情報の一例。 ユーザ情報データベースに登録されている所有店舗情報の一例。 店舗情報データベースに登録されているアルバイト者リストの一例。 移動端末の画面遷移図。 移動端末の画面遷移図。 移動端末の画面遷移図。 移動端末の画面遷移図。 移動端末の画面遷移図。 初回の店舗購入処理におけるサーバと移動端末の処理について説明するための図。 サーバで行われる移動端末用プログラム送信処理から初回購入店舗情報送信処理まで流れを示すフローチャート。 サーバで行われる店舗購入処理の流れを示すフローチャート。 ２回目以降の店舗購入処理におけるサーバと移動端末の処理について説明するための図。 サーバで行われる２回目以降購入候補店舗情報送信処理の流れを示すフローチャート。 アルバイト処理（訪問地でアルバイトを行う場合）におけるサーバと移動端末の処理について説明するための図。 サーバで行われるアルバイト先候補店舗情報送信処理の流れを示すフローチャート。 サーバで行われるアルバイト処理の流れを示すフローチャート。 アルバイト処理（友人の店舗でアルバイトを行う場合）におけるサーバと移動端末の処理について説明するための図。 スタッフ追加処理におけるサーバと移動端末の処理について説明するための図。 売上回収処理におけるサーバと移動端末の処理について説明するための図。 初回購入時の抽出範囲について説明するための図。 ユーザの店舗の売上値について説明するための図。 図３７（Ａ）（Ｂ）は、売上回収処理と店舗の売上値及び所持金額について説明するための図。 図３８（Ａ）（Ｂ）は、店舗価格の異なる店舗の売上推移について説明するための図。 図３９（Ａ）（Ｂ）は、アルバイトと売上値の関係について説明するための図。 図４０（Ａ）（Ｂ）は、アルバイトイベント発生と残り時間の関係について説明するための図。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。

１．ゲーム提供システム
図１は、本実施形態のゲーム提供システムについて説明するための図である。

本実施形態のゲーム提供システム１は、サーバ２０を含み、ネットワーク３０を介して複数の移動端末に接続可能に構成されている。なお本実施形態のゲーム提供システムは、複数の移動端末を構成要素としないシステムを指すが、複数の移動端末を含む構成も本発明のゲーム提供システムの範囲内である。

サーバ２０は、複数のユーザ間でコミュニケーションを提供することが可能なサービスを提供する情報処理装置であり、ＳＮＳを提供するサーバでもよいし、所与のゲームを提供するサーバでもよい。また、複数台の情報処理装置（サーバ）がネットワークを介して接続され分散処理を行うシステムも本発明のサーバの範囲内である。

本実施形態のゲーム提供システム１のサーバ２０は、Ｗｅｂ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバ機能やメールサーバ機能を備え、移動端末１０（１０Ａ、１０Ｂ、１０Ｃ、・・・）がＷｅｂページを閲覧可能なウェブブラウザを備えるシステムでもよい。

移動端末１０は、携帯電話（ＰＨＳ移動端末も含む）、携帯情報移動端末（ＰＤＡ等）、携帯型ゲーム機、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、電子ブック等の現在位置情報取得機能を有する情報処理装置であり、インターネット（ＷＡＮ）、ＬＡＮ、携帯電話回線網、パケット回線網、有線電話回線網などのネットワーク３０を介してサーバ２０に接続可能な装置である。なお、移動端末１０とサーバ２０との通信回線は、有線でもよいし無線でもよい。

また移動端末１０は、図示しない基地局を介してネットワーク３０と接続されてもよい。

なお図示しない基地局はネットワーク３０に接続され、半径数ｋｍ〜数十ｋｍ程度の通信エリア（セル）ごとに少なくとも１つ配置されており、移動する移動端末１０との間で無線通信を行うものでもよい。

図２に本実施形態の移動端末のブロック図の一例を示す。

移動端末１０は、無線アンテナ１９ａを介して無線信号を送受信して信号処理する通信処理部１１と、位置情報取得部１２（例えばＧＰＳアンテナ１９ｂを介して図示しないＧＰＳ衛星からのＧＰＳ信号を受信するＧＰＳ受信部でもよい）と、ユーザによる操作により各種データを入力する入力操作部１３と、マイク１７から入力、スピーカ１８から出力される音信号を処理する音信号処理部１４と、各種情報を表示する表示部１５と、各部を制御する制御部１６を含んで構成されてもよい。

なお位置情報取得部１２は、ＧＰＳ衛星からの電波を受信して位置情報を取得するものに限られず、携帯電話やＰＨＳ等の基地局から現在位置を特定するものでもよい。

移動端末１０はＷｅｂページを閲覧可能なウェブブラウザを備え、表示部１５でサーバ２０が提供するＷｅｂページを参照することができる。

また移動端末１０の制御部１６は、以下の実施例で説明する画面遷移の制御を行い、表示部１５に以下の実施例で説明する画面（Ｗｅｂページ）が表示され、入力操作部１３からユーザの入力を受け付ける。また通信処理部１１はネットワークを介してサーバとデータを送受信する処理を行う。

図３に本実施形態のサーバの機能ブロック図の例を示す。

本実施形態のサーバ２０は図３の構成要素（各部）の一部を省略した構成としてもよい。

記憶部２７０は、処理部２００や通信部２９６などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などにより実現できる。

情報格納部（例えば、データベース）２６０には、本実施形態のゲーム提供システムに参加する複数のユーザそれぞれのユーザ情報２６１が格納され、ユーザ情報データベースとして機能する。

また情報格納部（例えば、データベース）２６０には、仮想イベントエリア情報２６２が格納され、仮想イベントエリア情報データベースとして機能する。仮想イベントエリア情報２６２として、前記仮想イベントエリアに関連づけて他のアプリケーションにより更新可能な評価情報が記憶されていてもよい。

また情報格納部（例えば、データベース）２６０には、地価情報２６３が格納され、地価情報データベースとして機能する。

情報記憶媒体２８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）などにより実現できる。処理部２００は、情報記憶媒体２８０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体２８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。

通信部２９６は外部（例えば、移動端末、他のサーバや他のゲーム提供システム）との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。

処理部２００（プロセッサ）は、情報記憶媒体２８０に記憶されるプログラム等に基づいて、所与の処理を行う。具体的には、移動端末からの要求に応じて所与のサービスを提供する。

また、処理部２００は記憶部２７０内の主記憶部２７２をワーク領域として各種処理を
行う。処理部２００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。

特に、本実施形態のサーバの処理部２００は、ネットワーク設定部２１０、通信制御部２１１、取得処理部２１２、訪問処理部２１３、協力者登録処理部２１４、パラメータ演算部２１５、仮想価格演算部２１６、排他制御処理部２１７、仮想売上回収処理部２１８、仮想イベントエリア抽出処理部２１９とを含む。なおこれらの一部を省略する構成としてもよい。

ネットワーク設定部２１０は、ユーザ識別情報、移動端末識別情報などを移動端末１０から取得し、取得したユーザ識別情報や移動端末識別情報に対応づけて、ユーザ情報２６１を、情報格納部（例えばデータベース）２６０に格納する。また、ネットワーク設定部２１０は、ユーザ識別情報、移動端末識別情報に基づいて、当該ユーザのユーザ情報を参照、更新（変更）、削除する処理を行う。

通信制御部２１１は、移動端末１０とネットワークを介してデータを送受信する処理を行う。つまり、通信制御部２１１は、ユーザの移動端末からの要求に基づいて、当該ユーザに関連付けられている他のユーザの情報（例えば「ユーザ名」など）を当該ユーザの移動端末に送信する処理を行う。

仮想イベントエリア抽出処理部２１９は、移動端末において取得した現在位置情報に基づき、取得した現在位置から所与の範囲内の位置情報に対応づけられた仮想イベントエリアを抽出する処理を行う。取得処理部２１２は、仮想イベントエリア抽出処理部２１９が抽出した仮想イベントエリアに関する情報を取得候補情報として移動端末を介してユーザに提供し、提供した取得候補情報の仮想イベントエリアに対する取得要求を前記移動端末から受け取った場合、当該仮想イベントエリアをユーザの取得情報としてユーザ識別情報に対応づけて記憶させる処理を行う。訪問処理部２１３は、仮想イベントエリア抽出処理部２１９が抽出した仮想イベントエリアに関する情報を訪問候補情報として移動端末を介してユーザに提供し、提供した訪問候補情報の仮想イベントエリアに対する訪問要求を前記移動端末から受け取る処理を行う。パラメータ演算部２１５は、前記仮想イベントエリアの取得要求及び／又は訪問要求に応じて、ユーザの成績値及びゲームパラメータの少なくとも１つを演算し、仮想イベントエリアに対する訪問要求を受け取った場合、当該仮想イベントエリアを取得情報として記憶するユーザの成績値又は所定のゲームパラメータを変更する。

訪問処理部２１３は、仮想イベントエリアへの訪問要求を受け取った場合、訪問要求元のユーザの識別情報を当該仮想イベントエリアに対応づけられた訪問記録情報として記憶させ、パラメータ演算部２１５は、ユーザと友人関係にある他のユーザを特定するための友人情報及び訪問記録情報に基づき、当該仮想イベントエリアに訪問要求を行ったユーザと当該仮想イベントエリアを取得情報として記憶するユーザとが友人関係にあるか否かを判定して、友人関係にあると判断した場合には、友人関係にない場合に比べて、当該仮想イベントエリアを取得情報として記憶するユーザの成績値又は所定のゲームパラメータをより有利に変更してもよい。

また訪問処理部２１３は、前記友人情報に基づき、ユーザと友人関係にある他のユーザを判断して、当該他のユーザの取得情報として記憶された仮想イベントエリアを、訪問候補情報として、移動端末を介してユーザに提供してもよい。

またパラメータ演算部２１５は、仮想イベントエリアへの訪問要求を受け取った場合、訪問要求元のユーザの成績値又は所定のゲームパラメータを変更してもよい。

また協力者登録処理部２１４は、ユーザと友人関係にあり、ゲームユーザとして登録されている他のユーザに関する情報を、協力者候補情報として、移動端末を介してユーザに提供し、前記移動端末から、他のユーザを指定した協力要求を受け取った場合、当該他のユーザをユーザの協力者として登録し、パラメータ演算部２１５は、ユーザに協力者が登録された場合には、当該ユーザの成績値及びゲームパラメータの少なくとも１つを変更してもよい。

また取得処理部２１２は、前記友人情報および取得情報に基づき、抽出した仮想イベントエリアの取得者に要求元のユーザと友人関係にあるユーザがいるか否か判断し、判断結果に基づきユーザの移動端末に提供する際の優先順位を決定してもよい。

また仮想価格演算部２１６は、前記位置情報に対応する地価情報に基づき、仮想イベントエリアの仮想価格を演算し、取得処理部２１２は、抽出した仮想イベントエリアの前記仮想価格を含む情報を、移動端末を介してユーザに提供してもよい。

またパラメータ演算部２１５は、ユーザの取得情報として記憶されている仮想イベントエリアについて、当該仮想イベントエリアの仮想価格に基づいてユーザの成績値及びゲームパラメータの少なくとも１つを演算してもよい。

また取得処理部２１２は、取得した現在位置情報と、仮想イベントエリアに対応づけられた位置情報に基づき、現在位置から所定範囲内にある仮想イベントエリアであって、所与の金額以下の仮想価格を有する仮想イベントエリアを抽出して取得候補情報として提供するよう構成され、前記所定範囲内に取得候補がない場合には、所定範囲を段階的に拡大して所与の金額以下の仮想価格を有する仮想イベントエリアを抽出して取得候補としてもよい。

また仮想価格演算部２１６は、仮想イベントエリアに関連づけて記憶されている評価情報に基づいて、当該仮想イベントエリアの仮想価格の演算を行ってもよい。

またパラメータ演算部２１５は、ユーザの取得物である仮想イベントエリアについて、所定の条件にしたがって設定された上限値に達するまで仮想売上値を増加させる処理を行い、前記移動端末からユーザの取得した仮想イベントエリアについての売上回収要求を受け付けた場合には、仮想売上値を当該ユーザの所持金に参入して、仮想売上値をリセットする仮想売上回収処理を行う仮想売上回収処理手段を含んでもよい。

また排他制御処理部２１７は、友人関係にある他のユーザの取得した仮想イベントエリアについては取得できないように排他制御を行う。

また排他制御処理部２１７は、
仮想イベントエリア抽出手段が抽出した仮想イベントエリアを取得したユーザの中にユーザと友人関係にある他のユーザいる場合には、前記他のユーザ対して交渉要求を通知するとともに、他のユーザから交渉受け入れ可を示す応答を受信した場合には、他のユーザの当該仮想イベントエリアの取得を解除するとともに、ユーザについて当該仮想イベントエリアを取得させる処理を行ってもよい。

２．データベース
図４は、ユーザ情報について説明するための図である。

ユーザ情報２６１は、本システムのサーバが管理するデータベースに格納されていてもよいし、他のシステムが管理するデータベースに格納されていてもよい。またユーザ情報は、他のアプリケーション（例えばＳＮＳサービスであって、本発明のサービスと別サービスであってもよい）等から参照、更新可能に構成されていてもよい。

またユーザ情報２６１は、他のアプリケーションのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を利用し他のアプリケーションのデータを参照し、更新されるように構成されていてもよい。

ユーザ情報２６１は、複数のユーザのユーザ情報の集合として構成され、各ユーザに関するユーザ情報が各ユーザのユーザ識別情報３１０に関連づけて記憶されている。ユーザ識別情報３１０は、各ユーザに割り振られた識別ＩＤでもよいし、移動端末の機器に割り振られた機器ＩＤでもよいし、ユーザによって登録されたゲームＩＤでもよい。

ユーザ情報２６１は各ユーザの友人に関する情報である友人情報３１２を含んでもよい。友人情報３１２として、ユーザと友人関係にある他のユーザのユーザ識別情報のリストを記憶させてもよい。友人情報は、例えばＳＮＳサービスのアプリケーション等によって更新されるようにしてもよい。

ユーザ情報２６１は各ユーザのパーソナル情報３１４を含んでもよい。パーソナル情報３１４として、ユーザの名前やニックネームや生年月日や血液型等の情報を各ユーザのユーザ識別情報３１０に関連づけて記憶させてもよい。パーソナル情報３１４は、例えばＳＮＳサービスでユーザによって登録された情報でもよい。

ユーザ情報２６１はゲーム提供システムで生成又は使用される各ユーザについてのゲームデータ３１６を含んでもよい。ゲームデータ３１６として本実施の形態が提供するゲームのパラメータや取得情報等を各ユーザのユーザ識別情報３１０に関連づけて記憶させてもよい。各ユーザについてのゲームデータ３１６は例えば図８に示すデータを含んでいてもよい。

ユーザ情報２６１は各ユーザの移動端末情報３１８を含んでもよい。移動端末情報３１８は、移動端末１０にアクセスするための移動端末１０の移動端末識別情報（識別番号）、移動端末１０の「宛先情報」（ＩＰアドレス、メールアドレス、ポート番号、ＭＡＣアドレス、電話番号等）を各ユーザのユーザ識別情報に関連づけて記憶させてもよい。

図５は、仮想イベントエリア情報について説明するための図である。

ここでは仮想イベントエリアがゲームにおける店舗である場合を例にとり説明するが、店舗に限られず、土地や家屋等の不動産でもよいし、池や木等の自然物でもよい。

店舗情報（仮想イベントエリア情報の一例）２６１は、本システムが管理するサーバのデータベースに格納されていてもよいし、他のシステムが管理するデータベースに格納されていてもよい。また店舗情報は、他のアプリケーション（例えばナビゲーションサービス）等から参照、更新可能に構成されていてもよい。

店舗情報２６２は、複数の仮想店舗の店舗情報の集合として構成され、各店舗に関する店舗情報が各店舗の店舗識別情報３２０に関連づけて記憶されている。

店舗情報２６２は、位置情報３２２を含む。位置情報は、当該店舗が実世界に配置されていると仮定した場合の実世界の位置情報であり、例えば実世界の緯度（ｉｎ）、経度（ｋｉ）等の情報でもよい。なお例えば他のアプリケーション等で使用されている実世界の店舗に対応した位置情報データを利用してもよい。

店舗情報２６２は店舗の住所情報３２４を含んでもよい。住所情報３２４は、都道府県（ａｎ）、区市町村（ｂｎ）、町名番地（ｃｎ）等の情報でもよい。住所は店舗価格演算に用いる地価情報データベースを参照する際に使用することができる。このような場合には、地価データを検索する際のキーとなる情報を含んでいることが好ましい。

店舗情報２６２は属性情報３２６を含んでもよい。属性情報３２６は店舗の種類（たとえば飲食店、本屋、駅等のカテゴリ情報）等の情報を含んでもよい。属性情報は店舗価格演算に用いてもよい。

店舗情報２６２は店舗の口コミページリンク情報３２８を含んでもよい。

口コミページリンク情報３２８には、ゲーム上の店舗または店舗に対応する実在の店舗に対する口コミ情報が記載されているページへのリンクアドレス等である。口コミ情報は、他のアプリケーションにより更新可能な評価情報を含む。評価情報を用いて所有店舗の売却を行う際の店舗の評価額である店舗価値を演算してもよい。

店舗情報２６２はゲーム提供システムで生成又は使用される各店舗についてのゲームデータ３３０を含んでもよい。各店舗についてのゲームデータ３３０は例えば図９に示すデータを含んでいてもよい。

図６は、地価情報について説明するための図である。

地価情報２６３は、本システムのサーバが管理するデータベースに格納されていてもよいし、他のシステムが管理するデータベースに格納されていてもよい。また地価情報は、他のアプリケーション（例えば公示地価提供サービス）等から参照、更新可能に構成されていてもよい。また他のアプリケーションのＡＰＩを利用し他のアプリケーションのデータを参照し、更新されるように構成されていてもよい。

地価情報は、例えば住所の構成要素である都道府県ａ、区市町村ｂ、町名番地ｃ等のキー情報と住所に対応する地価が所定のデータ構造（例えばツリー構造）で接続され、住所に対応する地価３４０が検索可能に構成されていてもよい。

３．本実施の形態の処理
３−１．ゲーム概要
本実施の形態のゲーム内容について、ＳＮＳで提供されるゲームを例にとり説明する。

図７は、本実施の形態で提供するゲームのゲームサイクルの一例について説明するための図である。

本実施の形態では、ユーザは初回ゲーム時に、一店舗だけ購入可能な所持金（パラメータの一例）を付与され（Ｓ０）、当該所持金で初回の店舗購入（店舗取得の一例）を行う。ユーザは現在位置情報に基づきリストアップされる付近の店舗から所望の店舗を選択して購入（取得の一例）することができる（Ｓ１）。購入によりユーザの所持金は減少するが、所有店舗の売上値（パラメータの一例）は、所定のアルゴリズムに従って増加するので、ユーザは所有店舗から売上値を回収することで、所持金を増やすことができる（Ｓ２）。

またユーザは、自己所有の店舗以外の店舗でアルバイト（訪問の一例）を行うことができる（Ｓ３）。アルバイト先は現在位置情報に基づきリストアップされる付近の店舗から選択することができる。またユーザは、友人関係にある他のユーザの店では、現在位置に関係なくアルバイトすることができる（Ｓ４）。アルバイトによりユーザの経験値（パラメータの一例）や所持金が増加し、スタミナ値（パラメータの一例）が減少する（Ｓ５）。

なお友人関係にある他のユーザが自己の所有店舗でアルバイト（訪問の一例）を行った場合には、当該店舗の売上値の増加の速度が速くなるようにしてもよい（ユーザの成績値又は所定のゲームパラメータを変更する一例）。

ユーザはゲームユーザである他の友人をスタッフに追加することでスタミナ値を増加させることができる（Ｓ６）。

この様に本実施の形態では、ユーザが所持する移動端末の現在位置情取得して、現在位置付近の店舗（仮想イベントエリアの一例であり現在位置付近の位置情報を有する仮想的な店舗）を購入して、購入した所有店舗からの売上を回収したり、他の店舗でアルバイト（訪問の一例）したりして自己の総資産や自己の所有店舗数を増やして楽しむゲームを提供する。

３−２．ゲームデータ
図８は、本実施の形態のユーザに関するゲームデータについて説明するための図である。

本実施の形態では、ユーザ毎に各ユーザのユーザ識別情報３１０に関連づけて各ユーザに関連するゲームデータを記憶している。各ユーザに関するゲームデータ３１６は、図４に示すユーザ情報の一部として、他のアプリケーションからも参照可能なユーザ情報データベースに格納されてもよいし、ゲーム独自のユーザデータテーブルを作成してもよい。
また他のアプリケーションのＡＰＩを利用し他のアプリケーションのデータを参照し、更新されるように構成されていてもよい。

各ユーザに関連するゲームデータ３１６として、ユーザ毎に設定された所持金３５０、総資産３５２、レベル３５４、スタミナ３５６、経験値２５８等のゲームで設定／更新されるパラメータ等を各ユーザのユーザ識別情報３１０に関連づけて記憶してもよい。

所持金３５０は、ユーザが所持している現金の額であり、店舗を購入すると、購入価格分減少し、店舗を売却すると売却価格（売却時の店舗価値によって決まるので購入価格と同じとは限らない）分増加する。またアルバイトを行うとアルバイトで得た賃金分上昇するパラメータである。

総資産３５２は、ユーザの所持金３５０と所有店舗の現在価格（この価格は購入価格と同じとは限らずユーザのゲーム動作に応じて変化する）を合わせた額を示すパラメータであり、ランキング対象となるゲーム成績としてもよい。

レベル３５４は経験値に応じて増加するパラメータである。レベル３５４の値に応じて購入できる店舗数に制限を設けてもよい。

スタミナ３５６は、アルバイト等により減少するが、時間の経過により回復するパラメータである。またスタッフを追加することでスタミナ値３５６を増加させることができるようにしてもよい。

経験値３５８は、アルバイト実行により増加するパラメータである。

また各ユーザに関連するゲームデータ３１６として、各ユーザのユーザ識別情報３１０に関連づけて各ユーザが購入した店舗（所有店舗）に関する情報である所有店舗リスト３６０を記憶してもよい。所有店舗リスト３６０は、ユーザの所有店舗毎に店舗識別情報３６１−１、３６１−２、・・・、３６１−ｎ、来客数３６２−１、３６２−２、・・・、３６２−ｎ、残り時間３６３−１、３６３−２、・・・、３６３−ｎ、累計アルバイト人数３６４−１、３６４−２、・・・、３６４−ｎ、今回アルバイト人数３６５−１、３６５−２、・・・、３６５−ｎ、売上値３６６−１、３６６−２、・・・、３６６−ｎ、売上上限値３６７−１、３６７−２、・・・、３６７−ｎ、店舗価値３６８−１、３６８−２、・・・、３６８−ｎ、購入価格３６９−１、３６９−２、・・・、３６９−ｎ等のゲームで設定／更新されるパラメータ等を記憶してもよい。

本実施の形態では店舗毎に売上上限値３６７を設定し、各店舗の売上値３６６を売上上限値３６７に達するまで増加させるように制御しており、売上上限値に達したら、売上値をそれ以上増加させず、売上の回収（売上値を所持金に参入して売上値をリセットすること）が可能となる。売上を回収すると、売上値はリセットされ、再び時間の経過とともに売上上限値まで増加する。売上上限値３６７や残り時間３６３の初期値（売上上限値に達するまでの時間）は、各店舗の購入価格（購入時の店舗価格）３６９に応じて設定してもよい。

本実施の形態では来客数３６２は売上値３６６と同じ意味で使用されており、来客数は売上値と比例関係にあるのでどちらか１のパラメータをもたせるだけでもよい。例えば、来客数を最大来客数（売上上限値に相当）に達するまで増加させ、最大来客数に達したら来客数をそれ以上増加させずに、売上の回収が可能となるようにしてもよい。また売上値や残り時間は、当該店舗で行われた他のユーザのアルバイトにより影響をうけるようにしてもよい。

累計アルバイト人数３６４は、ユーザの所有店舗を指定したアルバイト要求の店舗所有開始時から現在までの受理の累計件数（累計件数）であり、今回アルバイト人数３６５はユーザの所有店舗を指定したアルバイト要求の前回の売上回収時後からの受理の件数である。なお累計アルバイト人数３６４や今回アルバイト人数３６５の更新は、店舗に関するゲームデータのアルバイト件数（図９の３７０）の更新と連動して行うようにしてもよい。

なお所有店舗リスト３６０の各店舗別情報は、各店舗の取得処理の際に初期設定してもよい。すなわち各店舗取得の際に、取得した店舗の識別情報３６１、購入価格３６９を設定する。そして購入価格に基づき算出した残り時間３６３、売上上限値３６７、店舗価値３６８を設定し、他の項目には初期値を設定してもよい。

また各ユーザに関連するゲームデータ３１６として、各ユーザのユーザ識別情報３３０に関連づけて各ユーザのスタッフリスト３７０を記憶してもよい。スタッフリスト３７０は、各ユーザによってスタッフに追加されたユーザ（各ユーザと友人関係にあるユーザ）のユーザ識別情報が記憶される。

また各ユーザに関連するゲームデータ３１６として、各ユーザのユーザ識別情報３３０に関連づけて、各ユーザのゲーム参加フラグ３８０を記憶してもよい。ゲーム参加フラグは初期値がＯＦＦで、各ユーザがゲーム参加登録を行った時や初回ゲームを行った時にＯＮになるよう制御してもよい。

図９は、本実施の形態の店舗に関するゲームデータについて説明するための図である。

本実施の形態では、店舗（仮想イベントエリアの一例）毎に各店舗の店舗識別情報３２０に関連づけて各店舗に関連するゲームデータを記憶している。各店舗に関するゲームデータ３３０は、図５に示すように、店舗情報の一部として、他のアプリケーションからも参照可能な店舗情報データベースに格納されてもよいし、ゲーム独自の店舗データテーブルを作成してもよい。

各店舗に関連するゲームデータ３３０として、各店舗で行われたアルバイト件数（訪問記録情報の一例）３７０を各店舗の店舗識別情報３２０に関連づけて記憶してもよい。 例えばユーザの移動端末からいずれかの店舗についてのアルバイト要求を受け付けた場合（訪問処理部が、ユーザの仮想イベントエリアへの訪問要求を受け取った場合の一例）に、各店舗のアルバイト件数カウンタをカウントアップし、各店舗に対応したアルバイト件数３７０を更新する処理を行うようにしてもよい。

なお各店舗のアルバイト件数がカウントアップされた際に、各店舗の所有者リスト３９０を参照して、所有者リストに登録されているユーザ識別情報に対応するユーザ情報の所有店舗リストの累計アルバイト人数（図８の３６４）や今回アルバイト人数（図８の３６５）をカウントアップしてもよい。

また各店舗に関連するゲームデータ３３０として、店舗識別情報３２０に関連づけて各店舗でアルバイトしたユーザの情報であるアルバイト者リスト（訪問記録情報の一例）３８０を記憶してもよい。アルバイト者リスト３８０は、当該店舗でアルバイトしたユーザの識別情報３８２−１、３８２−２、・・・、３８２−ｎを記憶してもよい。

また各店舗に関連するゲームデータ３３０として、店舗識別情報３２０に関連づけて各店舗を購入したユーザの情報である所有者リスト３９０を記憶してもよい。所有者リスト３９０は、当該店舗を購入したユーザの識別情報３９２−１、３９２−２、・・・、３９２−ｎを記憶してもよい。

また各店舗に関連するゲームデータ３３０として、各店舗の店舗価格３８４を各店舗の店舗識別情報３２０に関連づけて記憶してもよい。各店舗の店舗価格３８４は、各店舗の位置情報（図５の３２２）と当該位置に対応する地価情報（図６の３４０）に基づき演算してもよい。演算されるタイミングは、所定のタイミング（例えばゲームサービスの開始時や所定のイベントが発生した時）でもよい。また購入候補情報（取得候補情報の一例）として各店舗が抽出された時でもよいし、例えば当該店舗の店舗価格が必要になった場合に当該店舗についてゲームデータとして店舗価格が設定されていない場合（例えばゲームデータにデフォルト値が設定されている場合）等、店舗価格の算出を行いゲームデータとして設定するようにしてもよい。

店舗価格は地価情報に基づき算出されるが、所定のタイミングで算出基礎となる地価情報の変更又は入れ替えを行ってもよい。例えば地価情報として地価公示データを利用することで、現実世界の地価を反映させて都心部ほど、店舗価格が高くなるよう設定することができる。また所定のタイミングで算出基礎となる地価公示データを別の年度の地価公示データ（例えば２０年前のデータ）に入れ替えることで現実的な感覚を反映したまま店舗価格を一斉に変更することもできる。

また例えば所定の属性（図５の３２６）を持つ店舗（例えばコンビニ、ファミレス等）については一律での値段の設定を行うようにしてもよいし、地価に連動する価格で設定できるようにしてもよい。これらを切り替えて設定できるようにしてもよい。また、属性毎に異なる値を設定し、この値を係数、地価を変数として積算し店舗価格を算出してもよい。

３−３．店舗購入処理
店舗購入処理を例にとり本実施の形態の仮想イベントエリアの取得処理について説明する。

以下に説明する店舗購入処理は仮想イベントエリアの取得処理の一例であり、本発明の取得処理は、ユーザが実世界で訪れたエリア付近の位置情報を有する仮想イベントエリア（実世界の位置情報に関連づけられている仮想イベントエリア）を、取得という手続きを経てユーザに関連づけて管理する処理（例えばユーザの所有物や取得物として、ユーザ識別情報に関連づけて記憶させる処理）を行うものであればよい。

本実施の形態では、ユーザが、移動端末の表示部を見ながら、移動端末から操作入力を行うことにより、移動端末及びサーバでゲーム処理が行われる。

図１０は初回店舗購入処理における移動端末の画面遷移例である。

４１０〜４６０は移動端末の表示部に表示される画面（Ｗｅｂページ）の例を示している。初回ゲーム時にユーザはまず１軒目の店舗を購入する。店名登録画面（Ｗｅｂページ）４１０の店の名前欄４１２に対応するユーザの店の名前が入力され、画面上の「決定ボタン」４１４の確定操作が行われると（項目にカーソルを位置づけて決定入力が行われる）ことにより、今後ユーザ取得の店に付される名前「カフェボタン」が登録され、これにより今後、当該ユーザの所有店舗には「カフェボタン○○店」という店舗名が付されることになる。

次に店舗購入（初回）画面（Ｗｅｂページ）４２０を表示し、「お店を購入する」４２２を指定して確定操作が行われると、位置情報取得承認画面（Ｗｅｂページ）４３０を表示する。位置情報取得承認画面４３０で、「はい」４３２を指定して確定操作が行われると、移動端末の位置情報取得部は移動端末の現在位置情報を取得する処理を行い、緯度、経度等の現在位置情報を取得する。そして位置情報確認画面（Ｗｅｂページ）４４０に取得した緯度情報４４２、経度情報４４４を表示する。そして「ＯＫ」４４６を指定して確定操作が行われると、購入候補表示画面（Ｗｅｂページ）４５０に遷移する。

購入候補表示画面４５０には、現在の所持金４５２、購入候補となる店舗情報（店名４５４、店舗価格５００）を表示する。購入候補となる店舗は、店舗価格が所定金額以下で、取得した移動端末の現在位置に一番近い店舗を抽出して１店舗のみを表示するようにしてもよい。店舗の位置は店舗情報データベースの位置情報に基づき判断される。店舗には、現実世界の位置情報が対応づけられているため、ユーザの移動先における現在位置に近い店舗が購入候補として抽出される。

なおサーバが店舗を抽出する処理やデータベースを参照してユーザの現在の所持金を取得する処理を行い移動端末に送信し、移動端末は、サーバから受け取った情報に基づき表示するようにしてもよい。

購入候補表示画面４５０において「この店を購入」４５８の確定操作が行われると、最初のお店の購入が完了し、店舗購入完了画面（Ｗｅｂページ）４６０に遷移する。

なお上記実施例では、初回の購入候補として、１店舗のみ抽出する例について説明したがこれに限られず、現在位置から所定範囲内にあり、所定の金額以下の店舗を抽出し、条件に該当する店舗が複数ある場合には、ユーザに選択させるようにしてもよい。この様な場合、現在位置から所定範囲内に、所定の金額以下の物件がない場合には、所定範囲を段階的に拡大して、所定の金額以下の店舗を抽出するようにしてもよい。

図３５は、初回購入時の抽出範囲について説明するための図である。

例えば検索範囲設定値ｌ１、ｌ２、ｌ３（ｌ１＜ｌ２＜ｌ３）が与えられ、この検索範囲設定値に基づき段階的に拡大された検索範囲を設定してもよい。まずユーザの現在位置Ｏから半径ｌ１の円で示す所定範囲（第１の範囲７１０）の位置情報を有する店舗を検索する。検索結果として抽出された店舗に、所定の金額（ここでは５００万とする）以下の店舗があるか否か検索する。図３５に示すように第１の範囲に価格６０００万円の店舗Ｅ２１と価格３５００万円の店舗Ｅ２２しかない場合、所定の金額（ここでは５００万とする）以下の店舗がないため、検索範囲をユーザの現在位置Ｏから半径ｌ２の円で示す所定範囲（第２の範囲７１２）に拡大する。拡大した範囲に価格２０００万円の店舗Ｅ２３と価格４０００万円の店舗Ｅ２４しかない場合、所定の金額（ここでは５００万とする）以下の店舗がないため、検索範をさらにユーザの現在位置Ｏから半径ｌ３の円で示す所定範囲（第３の範囲７１４）に拡大する。この場合拡大した範囲に所定の金額（ここでは５００万とする）以下という条件を満たす店舗Ｅ２５（価格５００万円）があるので、店舗Ｅ３５が購入候補として抽出される。

本実施の形態では、ユーザは現在位置付近の店舗を購入できること、すなわちユーザが実際に訪れた実世界の場所に対応して設定されている店舗を購入できるというのがゲームの重要な要素となっている。

しかし、店舗（一部を除くの）の価格は、地価に基づき設定されるので、地価の高いエリアでは店舗価格も高く、ユーザの初期の所持金では購入可能な店舗が少ないこと、初回は店舗を購入しないと以降のゲームに進めないこと等を考慮して、初回に限って店舗購入のエリア制限を緩和するようにしてもよい。

図１２は２回目以降の店舗購入処理における移動端末の画面遷移例である。

４７０〜４８０は移動端末の表示部に表示される画面例を示している。２軒目以降についてはユーザの所望のタイミングで店舗を購入することができる。自己の所有店舗一覧画面（Ｗｅｂページ）４７０で「お店を新しく購入」４７２を指定して確定操作が行われると、位置情報取得承認画面４３０を表示する。位置情報取得承認画面４３０で、「はい」４３２を指定して確定操作が行われると、移動端末の位置情報取得部が移動端末の現在位置情報を取得する処理を行い、緯度、経度等の現在位置情報を取得する。そして位置情報確認画面４４０に取得した緯度情報４４２、経度情報４４４を表示する。そして「ＯＫ」４４６を指定して確定操作が行われると２軒目以降購入候補表示画面（Ｗｅｂページ）４８０に遷移する。

２軒目以降購入候補表示画面４８０では、表示優先順位４８２、現在の所持金４８３、購入候補となる店舗情報４８４の一覧を表示してもよい。店舗情報４８４は店舗価格４８６を含む。購入候補は、取得した移動端末の現在位置から所定範囲内の位置情報（図５の３２２）を有する店舗でもよい。購入候補となる店舗は既にユーザの取得しているものを除いてもよい。また店舗価格に制限を設けずユーザの所持金以上の店舗も表示してもよいし、ユーザの所持金以下の店舗のみ表示するようにしてもよい。

なおサーバが購入候補となる店舗を抽出する処理やデータベースを参照してユーザの現在の所持金を取得する処理を行い移動端末に送信し、移動端末は、サーバから受け取った情報に基づき表示するようにしてもよい。

抽出される店舗価格に制限を設けていない場合を例にとり、表示優先順位による並べ替えについて説明する。 表示優先順位４８２の「近い順」「購入可能」「高い」「安い」のいずれかが選択され確定操作が行われると、店舗一覧の表示順序を変更する処理を行う。「近い順」が選択されると現在位置情報と購入候補の各店舗の位置情報に基づき距離を演算し、距離が短い順に並べ替えて表示する。「購入可能」が選択されるとユーザの所持金（４８３に表示の額）以下の店舗を購入価格が高い又は低い順に並べ替えて表示する。

ユーザは店舗一覧を参照して、自己の所持金の範囲内で所望の店舗を選択して「この店を購入」４８８を指定して確定操作を行うことで、店舗を購入することができる。店舗が購入されると、現在の所持金（パラメータ）を現在の所持金値から店舗価格を減じた値に更新する。

なお２回目以降の店舗購入においては、初回時のように抽出エリアの範囲拡大はおこなわないようにしてもよい。１回目はゲーム開始にあたり店舗を取得することが必要であるため条件の緩和を行ってもよいが、２回目以降は、ユーザの現在位置から所定範囲内にユーザの所持金で購入可能な店舗がない場合には、ユーザはより地価の安いエリアに移動してより安い店舗を探すこともできる。本実施の形態では、店舗（一部を除くの）の価格は、地価に基づき設定されるので、地価の低いエリアの店舗は地価の高いエリアの店舗に比べて店舗価格が低いからである。またアルバイトを行って所持金を増やすこともできるからである。

図１１（Ａ）〜（Ｃ）は、店舗の表示優先順位について説明するための図である。

ユーザの現在位置Ｏから半径Ｌ１の円で示す所定範囲に店舗Ｅ１１（距離ｌ１１、店舗価格Ｐ１１）、Ｅ１２（距離ｌ１２、店舗価格Ｐ１２）、Ｅ１３（距離ｌ１３、店舗価格Ｐ１３）、Ｅ１４（距離ｌ１４、店舗価格Ｐ１４）、Ｅ１５（距離ｌ１５、店舗価格Ｐ１５）の店舗があり、各店舗の現在位置Ｏからの距離はｌ１１＜ｌ１３＜Ｅ１２＜ｌ１５＜ｌ１４＜Ｌ１、各店舗の価格はＰ１４＜Ｐ１１＜Ｐ１５＜「ユーザの所持金」＜Ｐ１２＜Ｐ１３であるとする。この様な場合表示優先順位で「近い順」選択された場合図１１（Ｂ）に示すように、所定範囲内の全店舗を距離が短い順に並べ替えて表示してもよい。また「安い順」が選択されたら図１１（Ｃ）に示すように、所定範囲内の全店舗を価格が安い順に並べ替えて表示してもよい。表示順位で店舗情報が表示され、「購入可能」選択されたら図１１（Ｄ）に示すように、購入可能な金額以下の店舗３件が抽出され、金額の高い順に店舗情報を表示してもよい。

３−４．アルバイト処理（訪問地でアルバイトを行う場合）
アルバイト処理を例にとり本実施の形態の訪問処理について説明する。

以下に説明するアルバイト処理は訪問処理の一例であり、本発明の訪問処理は、ユーザが実世界で訪れたエリア付近の位置情報を有する仮想イベントエリア（実世界の位置情報に関連づけられている仮想イベントエリア）を、訪問という手続きを経て訪問先の店舗のパラメータを変更や更新する処理（例えば店舗識別情報に関連づけて訪問回数等を記憶させる処理でもよい）を行うものであればよい。本実施の形態ではアルバイトが訪問目的である場合のゲーム例について説明しているが、お客として訪問する場合（店舗で買い物、飲食、各種サービスの利用、アミューズメント施設やスポーツ施設の利用）を行う設定でもよい。

図１３、図１４はアルバイト処理における移動端末の画面遷移例である。

図１３の４９０はゲームマイページ画面（Ｗｅｂページ）の一例を示している。ゲームマイページ画面（Ｗｅｂページ）４９０には、ユーザ自身のステータス情報４９１や、ユーザ自身の所有店舗に関する情報４９８等を表示する。自己のステータス情報４９１として現在のゲーム成績や各種ゲームパラメータ（レベル４９２、スタミナ４９３、店舗４９４、所持金４９５、総資産４９６）を表示してもよい。

なおサーバがデータベースを参照してこれらの情報を取得する処理を行い移動端末に送信し、移動端末は、サーバから受け取った情報に基づき表示するようにしてもよい。

本画面において「アルバイトに行く」４９７を指定して確定操作が行われると、位置情報取得承認画面（Ｗｅｂページ）４３０を表示する。位置情報取得承認画面４３０で、「はい」４３２を指定して確定操作が行われると、移動端末の位置情報取得部が移動端末の現在位置情報を取得する処理を行い、緯度、経度等の現在位置情報を取得する。そして位置情報確認画面（Ｗｅｂページ）４４０に取得した緯度情報４４２、経度情報４４４を表示する。そして「ＯＫ」４４６を指定して確定操作が行われるとアルバイト先一覧画面（Ｗｅｂページ）５００に遷移する。

図１４のアルバイト先一覧画面５００には、アルバイト先候補となる店舗情報一覧５０２が表示される。アルバイト先候補となる店舗は、現在位置から所定範囲内の位置情報（図５の３２２）が対応づけられた店舗である。アルバイト候補となる店舗は当該ユーザが取得している店舗を除く（自分の店ではアルバイトできないようにする）。またアルバイト実行後、所定時間の間は同じ店舗でアルバイトできないように制御し、同じ店舗で続けてアルバイトができないようにしてもよい。アルバイト先一覧の表示順位は、当該ユーザと友人関係にあるユーザの店舗が先にくるように並べ替えて表示してもよい。

なおサーバがアルバイト先候補となる店舗を抽出する処理を行い移動端末に送信し、移動端末は、サーバから受け取った情報に基づき表示するようにしてもよい。またサーバは、友人情報３１２として登録されているユーザ識別情報と、当該ユーザ識別情報に関連付けられている情報のうち少なくとも店舗識別情報を参照し抽出してもよい。この友人情報３１２は、外部のシステム（例えば他のＳＮＳサービス）の情報を参照し、友人として関連付けられて記憶されている所与の情報を抽出し一時的にサーバに保存された情報でもよいし、ゲームにおいて友人の名前、ゲームＩＤ、識別ＩＤ等を検索する検索手段を設け、検索した友人のユーザ識別情報を自身のユーザ識別情報に関連付けて友人情報として記憶する友人登録手段を設けるようにしてもよい

アルバイト先一覧画面において、所与の店舗の「この店でアルバイト」５０４を指定して確定操作が行われると、アルバイト結果画面（Ｗｅｂページ）５１０に遷移する。

アルバイト結果画面５１０にはアルバイト結果５１２と、アルバイト後のユーザのステータス情報５１４，５１６、５１８が表示される。このアルバイト入力により、経験値、アルバイト代、スタミナ等のパラメータを加算又は減算し経験値、所持金が増加し、スタミナが減少する画像を画面に表示する（５１４，５１６、５１８参照）。なお、経験値、アルバイト代、スタミナ等のパラメータを、店舗価値、購入価格と同様に、店舗毎に変動させてもよい。

なおサーバがアルバイト後のユーザのステータス情報５１４，５１６、５１８を演算する処理を行い移動端末に送信し、移動端末は、サーバから受け取った情報に基づき表示するようにしてもよい。

図１５（Ａ）（Ｂ）は、アルバイト先候補店舗の表示優先順位について説明するための図である。

ユーザの現在位置Ｏから半径Ｌ２の円で示す所定範囲に店舗Ｅ１（友人所有）、Ｅ２（友人所有）、Ｅ３、Ｅ４，Ｅ５の店舗がある場合、図１５（Ｂ）に示すように、ユーザの友人である他のユーザ所有の店舗Ｅ１，Ｅ２を優先的に表示するように並べ替えて表示してもよい。

ユーザの友人とは、例えばＳＮＳサービスにおいて友人登録を行っている他のユーザであり、ユーザ情報データベース（図４参照）に、当該ユーザのユーザ識別情報に関連づけて友人情報として記憶されている他のユーザのことである。

３−５．アルバイト処理（友人の店舗でアルバイトを行う場合）
本実施の形態では、ユーザの友人の店舗については例外的にユーザの現在位置に関わらずアルバイトを行うことができる。

図１９はアルバイト処理（友人の店舗でアルバイトを行う場合）における移動端末の画面遷移例である。

図１９の５２０はユーザの友人のトップページ画面（Ｗｅｂページ）の一例を示している。ユーザの移動端末から当該ユーザの友人のトップページ画面５２０にアクセスされ、「友人のお店でバイトする」５２２を指定して確定操作が行われると、友人店舗一覧画面（Ｗｅｂページ）５３０に遷移する。

友人店舗一覧画面５３０には、アルバイト先候補として、友人の店舗情報一覧を表示する。友人店舗一覧画面５３０で所与の店舗の「この店でアルバイト」５３２を指定して確定操作が行われると、アルバイト結果画面（Ｗｅｂページ）５４０に遷移する。

なおサーバがアルバイト先候補となる友人の店舗を抽出する処理を行い移動端末に送信し、移動端末は、サーバから受け取った情報に基づき表示するようにしてもよい。

友人の店舗でのアルバイトについては、時間と回数の制限を設けてもよい。この様にすると友人の店舗のみでのアルバイトだけでなく、訪問先でのアルバイトを実行させる動機付けを与えることができる。

３−６．売上演算処理
本実施の形態のパラメータ演算処理の一例である売上演算処理について説明する。

図３６は、ユーザの店舗の売上値について説明するための図である。グラフの横軸は時間、縦軸は売上値を示している。

本実施の形態では、店舗毎に売上上限値を設け、各店舗の売上値を、時間とともに増加させるよう制御している。売上上限値は、各店舗の購入時の店舗価格に応じて設定してもよい。例えば売上上限値を購入時の店舗価格×αパーセントとしてもよい。

所与の店舗の売上上限値をＵとすると、売上上限値Ｕに達するまでの所用時間ＴはＵの値に応じて設定される。例えばＴの値はＵの値に比例して増加するようにしてもよいし、所定の関数に従って設定されるようにしてもよい。売上上限値が高くなるほど、所用時間Ｔが長くなるようにしてもよい。

時刻ｔ０において０であった所与の店舗の売上値７４０は、時間とともに増加し、所用時間Ｔ経過後の時刻ｔ１において売上上限値Ｕに達し、その後は上限値を維持する。そしてユーザからの売上回収指示７５０があると（時刻ｔ２）、売上値７４０は０にリセットされ、再び時間とともに増加し、売上回収が行われた時刻時ｔ２から所定時間Ｔ経過後の時刻ｔ３において再び売上上限値Ｕに達し、次の売上回収が行われるまで、その上限値を維持する。

ユーザからの売上回収要求を受けると、売上値をリセットして、再び売上上限値に達するまで増加させる処理を繰り返し行う。売上回収が行われると、回収した売上値をユーザの所持金に加算する。

図３７（Ａ）（Ｂ）は、売上回収処理と店舗の売上値及び所持金額について説明するための図である。グラフの横軸は時間、縦軸は売上値を示している。

本実施の形態では、売上値が上限値に達した後は、ユーザが所望のタイミングで売上値の回収要求を行うことができる。図３７（Ａ）は、売上値が上限値に達するとすぐに売上回収要求が行われる場合の売上値７４０と、ユーザの所持金７８０の推移を示している。また３７（Ｂ）は、売上値が上限値に達してもすぐに売上回収要求が行われず、所定時間Ｔ２を経過してから売上回収要求が行われる場合の売上値７４０’と、ユーザの所持金７８０’の推移を示している。図３７（Ａ）の場合は、図３７（Ｂ）の場合に比べて、売上回収サイクルが早いので、ユーザの所持金７８０も早く増加する。

すなわちユーザは、自己の店舗の売上をこまめにチェックして、売上上限値に達したら、なるべく早く回収するようにすると、所持金を効率よく短時間で増加させることができる。この様にするとユーザがこまめにゲームを実行するほど有利になるので、ゲーム実行への強い動機付けを与えることができる。

図３８（Ａ）（Ｂ）は、店舗価格の異なる店舗の売上推移について説明するための図である。各グラフの横軸は時間、縦軸は売上値を示している。

図３８（Ａ）は店舗価格１０００万の売上推移グラフ７６０であり、売上上限値Ｕは１００万で、売上上限値Ｕに達するまでの所用時間Ｔは１０分である。図３８（Ｂ）は店舗価格１００００万の売上推移グラフ７７０であり、売上上限値Ｕは１０００万で、売上上限値Ｕに達するまでの所用時間Ｔは３０分である。

この様に店舗価格が高いほうが、売上値が有利になるように設定してもよい。

図３９（Ａ）（Ｂ）は、アルバイトと売上値の関係について説明するための図である。

本実施の形態では、各ユーザの所有店舗（ユーザの取得した仮想イベントエリアの一例）でアルバイトイベントが発生すると、各店舗の売上値（ユーザの成績値又は所定のゲームパラメータの一例）をアルバイトイベントが発生しない場合に比べて有利に変更してもよい。

図３９（Ａ）のグラフ７６０は、図３８（Ａ）のグラフ７６０に対応しており、当該店舗でのアルバイト件数がない場合の売上の推移を示している。グラフ７６２は所定件数（例えば１件でもよい）のアルバイトがあった場合の売上推移のグラフである。

例えば、ユーザの店舗でアルバイトが行われると、当該店舗の売上上限値Ｕがαパーセント（ここでは１０パーセント）加算され、売上上限値Ｕに達するまでの所用時間Ｔがβパーセント（ここでは１０パーセント）短縮されるようにしてもよい。この様にするとグラフ７６２に示すように売上上限値が１１０万円になり、所用時間が９分となる。

図３９（Ｂ）のグラフ７７０は、図３８７（Ａ）のグラフ７７０に対応しており、当該店舗でのアルバイト件数がない場合の売上の推移を示している。グラフ７７２は所定件数のアルバイトがあった場合の売上推移のグラフである。

例えば、ユーザの店舗でアルバイトが行われると、当該店舗の売上上限値Ｕがαパーセント（ここでは１０パーセント）加算され、売上上限値Ｕに達するまでの所用時間Ｔがβパーセント（ここでは１０パーセント）短縮されるようにしてもよい。この様にするとグラフ７７２に示すように売上上限値が１１００万円になり、所用時間が２７分となる。

なお上記実施例では売上上限値と所要時間の両方が変化する場合を例に取り説明したが、これに限られず、いずれか一方のみを変化させるようにしてもよい

また上記実施例は説明を簡単にするために最初から売上上限値及び所要時間が変更されている場合を例にとり説明したが、アルバイトが行われたタイミングで変更してもよい。また所用時間内に複数回のアルバイトが行われた場合には、変更後の売上上限値及び所要時間をさらに変更するようにしてもよい。この様にすると各店舗における他のユーザのアルバイト件数が多いほど、各店舗の売上速度を速くすることができる。

アルバイトイベントに応じた売上値の制御は、各店舗の売上値を、時間とともに増加するよう設定し、各店舗のアルバイト件数に応じて増加速度を早める変更を行うようにしてもよい。このようにすると各店舗におけるアルバイト件数が多いほど売上増加速度がはやくなるので、当該店舗所有のユーザに有利になる。

なおアルバイト件数に応じて売上値を有利に設定する手法は上記に限られず、例えばアルバイト件数がカウントアップされるたびに売上値を加算（積み増し）するようにしてもよい。

またユーザの店舗でアルバイトした他のユーザの中にユーザと友人関係にある他のユーザがいる場合には各店舗の売上値の増加速度をはやめてもよい（ユーザの成績値又は所定のゲームパラメータをより有利に変更する例）。

図３９（Ａ）のグラフ７６４は、当該店舗で当該店舗の所有主のユーザと友人関係にある他のユーザがアルバイトした場合の売上推移のグラフである。

例えば、ユーザの店舗で当該ユーザと友人関係にある他のユーザがアルバイトした場合、当該店舗の売上上限値Ｕがα’パーセント（ここでは２０パーセント）加算され、売上上限値Ｕに達するまでの所用時間Ｔがβ’パーセント（ここでは２０パーセント）短縮されるようにしてもよい。この様にするとグラフ７６４に示すように売上上限値が１２０万円になり、所用時間が８分となる。

図３９（Ｂ）のグラフ７７４は、当該店舗で当該店舗の所有主のユーザと友人関係にある他のユーザがアルバイトした場合の売上推移のグラフである。

例えば、ユーザの店舗で当該ユーザと友人関係にある他のユーザがアルバイトした場合、当該店舗の売上上限値Ｕがα’パーセント（ここでは２０パーセント）加算され、売上上限値Ｕに達するまでの所用時間Ｔがβ’パーセント（ここでは２０パーセント）短縮されるようにしてもよい。この様にするとグラフ７７４に示すように売上上限値が１２００万円になり、所用時間が２４分となる。

図４０（Ａ）（Ｂ）は、アルバイトイベント発生と残り時間の関係について説明するための図である。

各ユーザの所有店舗でアルバイトイベントが発生すると、店舗の売上値が売上上限値に達するまでの残り時間が、アルバイトイベントが発生しない場合に比べて短縮されるようにしてもよい。図４０（Ａ）（Ｂ）の横軸は売上値がリセットされてからの経過時間、縦軸は店舗の売上値が売上上限値に達するまでの残り時間を示している。また８４０は、店舗の売上値が売上上限値に達するまでの所用期間が１０分でありアルバイトイベントが発生しなかった場合の残り時間の遷移を表すグラフである。

図４０（Ａ）に示すように、売上値が売上上限値に達するまでの間、１回だけ７９０のタイミング（４秒経過後）でアルバイトイベントが発生した場合には、この時点で残り時間が１分短縮され、最終的に所要時間９分で、売上値が売上上限値に達することになる。

図４０（Ｂ）に示すように、売上値が売上上限値に達するまでの間、７９２（２秒経過後、７９４（４秒経過後）、７９６のタイミング（６秒経過後）で３回アルバイトイベントが発生した場合には、各時点で残り時間が１分ずつ短縮され、最終的に所要時間７分で、売上値が売上上限値に達することになる。

このようにユーザの店舗で他のユーザのアルバイトイベントが発生すればするほど、ユーザの店舗の売上速度が速くなる。すなわち他のユーザがアルバイトしやすい場所（他のユーザが実世界で訪れる機会の多い場所、例えば人が多い場所）にある店舗ほど売上速度が速いということになる。従ってユーザは、資産を有利に増加させるために、人の多い場所等の店舗を購入するという遊び方もできる。ただし人の多いところは概して地価が高いので、購入資金も多く必要になる。そこで購入資金を得るためにアルバイトするというさらなるゲーム動作への動機付けを与えることもできる。

次に、店舗が複数のユーザに所有されている場合の処理ついて説明する。

図１６はユーザ情報データベースに登録されている友人情報の一例である。

ユーザＹ１の友人としてユーザＹ２、Ｙ３が登録され、ユーザＹ２の友人としてユーザＹ４、Ｙ１が登録され、ユーザＹ３の友人としてユーザＹ１が登録され、ユーザＹ４１の友人としてユーザＹ２が登録されているとする。

図１７はユーザ情報データベースに登録されている所有店舗情報の一例である。

ユーザＹ１の所有店舗として店舗Ｅ１、Ｅ２、Ｅ３が登録され、ユーザＹ２の所有店舗として店舗Ｅ４が登録され、ユーザＹ３の所有店舗として店舗Ｅ１、Ｅ４が登録され、ユーザＹ４の所有店舗として店舗Ｅ５が登録されているとする。

図１８は店舗情報データベースに登録されているアルバイト者リストの一例である。

店舗Ｅ１のアルバイト者としてユーザＹ２、Ｙ４が登録され、店舗Ｅ２のアルバイト者としてユーザＹ２、Ｙ３、Ｙ４が登録され、店舗Ｅ３のアルバイト者の登録はなく、店舗Ｅ４のアルバイト者としてユーザＹ１、Ｙ４が登録され、店舗Ｅ５のアルバイト者としてユーザＹ１が登録されているとする。

ユーザの店舗の売上値を演算する場合には、ユーザの店舗で当該ユーザと友人関係にある他のユーザがアルバイトしているか否かを調べる。

例えばユーザＹ１は店舗Ｅ１を所有しており（図１７の８３０参照）、店舗Ｅ１では、ユーザＹ２、Ｙ４がアルバイトを行っている（図１８の８３２参照）。またユーザＹ１の友人はユーザＹ２、Ｙ３であるため（図１６の８３４参照）、ユーザＹ１の店舗Ｅ１で、ユーザＹ１の友人であるＹ２がアルバイトしたタイミングで、当該店舗の売上上限値Ｕをα’パーセント（例えば２０パーセント）加算し、売上上限値Ｕに達するまでの所用時間Ｔをβ’パーセント（例えば２０パーセント）短縮する処理（第１の優遇処理）が行われる。またユーザＹ１の店舗Ｅ１で、ユーザＹ１の友人でないＹ４がアルバイトしたタイミングで、当該店舗の売上上限値Ｕをαパーセント（例えば１０パーセント）加算し、売上上限値Ｕに達するまでの所用時間Ｔをβパーセント（例えば１０パーセント）短縮する処理（第２の優遇処理）が行われる。

また例えばユーザＹ３は店舗Ｅ１を所有しており（図１８の８３６参照）、店舗Ｅ１では、ユーザＹ２、Ｙ４がアルバイトを行っている（図１８の８３２参照）。またユーザＹ３の友人はユーザＹ１であるため（図１６の８３８参照）、ユーザＹ３の店舗Ｅ１で、友人はアルバイトしていない。従ってユーザＹ３の友人でないＹ２がアルバイトしたタイミングで、当該店舗の売上上限値Ｕをαパーセント（例えば１０パーセント）加算し、売上上限値Ｕに達するまでの所用時間Ｔをβパーセント（例えば１０パーセント）短縮する処理（第２の優遇処理）が行われる。またユーザＹ３の店舗Ｅ３で、ユーザＹ３の友人でないＹ４がアルバイトしたタイミングで、当該店舗の売上上限値Ｕをαパーセント（例えば１０パーセント）加算し、売上上限値Ｕに達するまでの所用時間Ｔがβパーセント（例えば１０パーセント）短縮する処理（第２の優遇処理）が行われる。

この様に、同じ店舗でも、アルバイトの売上値や所用時間への影響は所有するユーザ毎に異ななり、また売上回収のタイミングもユーザ毎に異なるため、各店舗の売上や所用時間は所有するユーザ毎に個別に制御する。

図２０は、売上回収処理における移動端末の画面遷移例である。

図２０の４９０はゲームマイページ画面の一例を示している。

ゲームマイページ画面（Ｗｅｂページ）４９０には、ユーザの所有店舗に関する情報４９８等を表示する。ユーザの所有店舗に関する情報４９８の「各店の様子を見る」４９９を指定して確定操作が行われると、所有店舗一覧画面（Ｗｅｂページ）５６０に遷移する。

所有店舗一覧画面５６０ユーザの所有する店舗情報の一覧５６１を表示する。店舗情報として来客数５６２、今回のアルバイト人数５６４、売上回収表示５６４又は残り時間５６５のいずれか（店舗の売上が売上上限値に達している場合には売上回収表示５６４、売上上限値に達していない場合には、売上上限値に達するまでの残り時間５６５）等を表示する。所与の店舗の「売上回収」５６３を指定して確定操作が行われると、売上回収完了画面（Ｗｅｂページ）５７０に遷移する。

売上回収完了画面（Ｗｅｂページ）５７０では、売上回収による所持金の変化５６２、総資産の変化５６４、アルバイト人数のリセット５６６を表示する。売上上限値に達しているか否かは「売上回収」表示の有無で判断することができる。また残り時間をこまめにチェックすることにより、時間的なロスを減らして無駄なく売上回収して所持金を増やすことができる。

なおサーバがユーザの所有する店舗情報の一覧の店舗に関する情報を取得する処理や売上回収後の所持金や総資産やアルバイト人数を演算する処理を行い移動端末に送信し、移動端末は、サーバから受け取った情報に基づきそれらを表示するようにしてもよい。

３−７．店舗売却処理
図２１は、店舗売却処理における移動端末の画面遷移例である。

図２１の５８０は店舗情報画面の一例を示している。

店舗情報画面（Ｗｅｂページ）５８０では、お店の価値「７４８１万」５８４を表示し、「売却する」５８２を指定して確定操作が行われると、売却確認画面（Ｗｅｂページ）５９０に遷移する。お店の価値５８４は、当該店舗を購入時の価格にゲームで行われたグレードアップ等の内容を反映した値である。

売却確認画面（Ｗｅｂページ）５９０では、売却価格の提示５９２、売却後の所持金の変化５９４を表示する。売却価格はお店の価値５４８で示された額に基づき算出された額であり、例えばお店の価値５８４を四捨五入した値でもよい。売却後の所持金は売却前の所持金に売却価格を加算した値となる。「はい」５９６を指定して確定操作が行われると、売却完了画面（Ｗｅｂページ）６００に遷移する。

なおサーバがユーザの所有する店舗の情報（お店の価値等）を取得する処理や売却価格を演算する処理を行い移動端末に送信し、移動端末は、サーバから受け取った情報に基づきそれらを表示するようにしてもよい。

３−８．友人情報提供処理
図２２は、友人情報提供処理における移動端末の画面遷移例である。

図２２の５８０は店舗情報画面の一例を示している。

友人情報提供画面（Ｗｅｂページ）６１０では、友人関係にある他のユーザのアルバイト情報６１１、友人関係にある他のユーザの総資産ランキング６１３、友人関係にある他のユーザの更新情報６１５等を表示する。「もっと見る」６１２を指定して確定操作が行われると、アルバイト情報画面（Ｗｅｂページ）６４０に遷移する。また友人関係にある他のユーザの総資産ランキング６１３の「もっと見る」６１４を指定して確定操作が行われると、友人総資産ランキング情報画面（Ｗｅｂページ）６２０に遷移する。また友人関係にある他のユーザの更新情報６１５の「もっと見る」６１６を指定して確定操作が行われると、友人更新情報画面（Ｗｅｂページ）６３０に遷移する。

なおサーバが友人関係にある他のユーザのアルバイト情報や友人関係にある他のユーザの総資産ランキングや、友人関係にある他のユーザの更新情報等ユーザの所有する店舗の情報を取得する処理を行い移動端末に送信し、移動端末は、サーバから受け取った情報に基づきそれらを表示するようにしてもよい。

３−９．スタッフ追加処理
スタッフ追加処理を例にとり本実施の形態の協力者登録処理について説明する。

図２３は、スタッフ追加処理における移動端末の画面遷移例である。

友人情報画面（Ｗｅｂページ）６５０の「スタッフ」６５２を指定して確定操作が行われると、スタッフ一覧画面（Ｗｅｂページ）６６０に遷移する。スタッフ一覧画面６６０にスタッフとして追加可能な友人一覧６７２を表示し、友人一覧６７２の所与の友人について「スタッフに加える」６７４を指定して確定操作が行われると、スタッフ追加完了画面（Ｗｅｂページ）６６０に遷移する。

スタッフとして追加可能な友人は、ユーザと友人関係にある他のユーザであって、本ゲームのゲーム登録をしており、現在本ユーザのスタッフになっていない他のユーザである。

なおサーバが上記条件を満たすユーザをスタッフ追加可能な友人として抽出する処理を行い移動端末に送信し、移動端末は、サーバから受け取った情報に基づきそれらを表示するようにしてもよい。ユーザと友人関係にある他のユーザ（友人情報３１２）は、外部のシステム（例えば他のＳＮＳサービス）の情報を参照し、友人として関連付けられて記憶されている所与の情報（ユーザ識別情報、ゲーム参加フラグ等）を抽出し一時的にサーバに保存された情報でもよいし、ゲームにおいて友人の名前、ゲームＩＤ、識別ＩＤ等を検索する検索手段を設け、検索した友人のユーザ識別情報を自身のユーザ識別情報に関連付けてスタッフ情報として記憶するスタッフ登録手段を設けるようにしてもよい。

４．ゲーム提供システムの処理
４−１．初回の店舗購入処理
図２４は、初回の店舗購入処理におけるサーバと移動端末の処理について説明するための図である。

初回ゲーム時には移動端末には本ゲームに対応した移動端末用ゲームプログラムがダウンロードされていない場合について説明する。

ユーザが移動端末にゲーム登録入力（初回ゲーム時行う処理）を行うと（Ｕ１２）、移動端末は移動端末用ゲームプログラムダウンロード処理ルーチン（Ｔ１２）を実行し、サーバに対して移動端末用ゲームプログラム送信要求を送信する（ｔ１３）。

移動端末用ゲームプログラム送信要求を受信したサーバは、移動端末用ゲームプログラム送信処理ルーチン（Ｓ１２）を実行し、要求元の移動端末に対して、移動端末用ゲームプログラムを送信する（ｓ１３）。

移動端末に移動端末用ゲームプログラムがダウンロードされると、移動端末は初回購入候補店舗情報送信要求処理ルーチン（Ｔ１６）を実行し、例えば図１０の４２０〜４４０で説明したような画面遷移処理を行う。そしてユーザが購入希望入力を行うと（Ｕ１６）、移動端末は位置情報を取得し、取得した位置情報を含む初回購入候補店舗情報送信要求をサーバに送信する（ｔ１７）。

初回購入候補店舗情報要求を受信したサーバは、初回購入候補店舗情報送信処理ルーチン（Ｓ１６）を実行し、店舗情報データベース２６２の店舗の位置情報、地価情報データベース２６３の地価情報等を参照して初回購入候補店舗情報を作成し、要求元の移動端末に送信する（ｓ１７）。なお店舗情報データベース２６２や地価情報データベース２６３は当該サーバ以外のサーバに記憶されていてもよく、他のアプリケーションのＡＰＩを利用し他のアプリケーションのデータベースを参照してもよい。またアプリケーション、データベースを分散し、相互に適宜参照、更新可能に構成してもよい。

初回購入候補店舗情報を受信した移動端末は、店舗購入要求処理ルーチン（Ｔ１８）を実行し、例えば例えば図１０の４５０〜４６０に示すような画面遷移処理を行う。そしてユーザが購入対象指定入力を行うと（Ｕ１８）、購入対象店舗指定情報を含む店舗購入要求をサーバに送信する（ｔ１９）。

店舗購入要求を受信したサーバは、店舗購入処理ルーチン（Ｓ１８）を実行し、店舗購入結果に基づきユーザ情報データベースのゲームデータ（所有店舗リスト）や店舗情報データベースのゲームデータ（所有者リスト）等を更新し、店舗購入完了通知を移動端末に送信する（ｓ１９）。

図２５はサーバで行われる移動端末用プログラム送信処理から初回購入店舗情報送信処理まで流れを示すフローチャートである。

移動端末から移動端末用プログラムダウンロード要求を受信すると（ステップＳ１０２）、移動端末用ゲームプログラムを要求元の移動端末に送信する（ステップＳ１０６）。

また移動端末から、現在位置情報を含む初回購入候補店舗情報送信要求を受信すると（ステップＳ１０８）、店舗情報データベースを検索して、受信した現在位置から所定範囲内の店舗を抽出する（ステップＳ１１０）。

抽出した店舗の店舗価格が演算済みでない場合には、当該店舗の住所情報に基づき地価情報データベースを検索して、住所に対応する地価を求め、求めた地価に基づき当該店舗の店舗価格を演算する（ステップＳ１１２）。

抽出した店舗に、所定金額以下の価格のものがない場合には（ステップＳ１１４でＮ）、所定範囲を拡大して、店舗情報データベースを検索して、受信した現在位置から拡大された所定範囲内の店舗を抽出し（ステップＳ１１６）、ステップＳ１１４にいく。抽出した店舗に所定金額以下の価格のものがある場合には（ステップＳ１１４でＹ）、抽出した店舗に関する情報を初回購入候補店舗情報として、要求元の移動端末に送信する（ステップＳ１１８）。

図２６はサーバで行われる店舗購入処理の流れを示すフローチャートである。

移動端末から、購入対象店舗指定情報を含む店舗購入要求を受信すると（ステップＳ１２０）、購入対象として指定された店舗を要求元のユーザの所有店舗リストに加える（ステップＳ１２２）。具体的にはユーザ情報データベースの要求元のユーザのユーザ識別情報に関連づけられたゲームデータである所有店舗リスト（図８の３６０）を更新する。また要求元のユーザを購入対象として指定された店舗の所有者リストに加える（ステップＳ１２４）。具体的には、店舗データベースの当該店舗の店舗識別情報に関連づけられたゲームデータである所有者リスト（図９の３９０）に要求元のユーザのユーザ識別情報を登録する。そして店舗購入完了通知を要求元の移動端末に送信する（ステップＳ１２６）。

４−２．２回目以降の店舗購入処理
図２７は、２回目以降の店舗購入処理におけるサーバと移動端末の処理について説明するための図である。

移動端末は２回目以降購入候補店舗情報送信要求処理ルーチン（Ｔ２２）を実行し、例えば図１２の４７０、４３０、４４０で説明したような画面遷移処理を行う。そしてユーザが購入希望入力を行うと（Ｕ２２）、移動端末は位置情報を取得し、取得した位置情報を含む購入候補店舗情報送信要求をサーバに送信する（ｔ２３）。

２回目以降購入候補店舗情報要求を受信したサーバは、２回目以降購入候補店舗情報送信処理ルーチン（Ｓ２２）を実行し、店舗情報データベース２６２の店舗の位置情報、地価情報データベース２６３の地価情報、ユーザ情報データベースの所持金やレベル等を参照して２回目以降購入候補店舗情報を作成し、要求元の移動端末に送信する（ｓ２３）。なお店舗情報データベース２６２や地価情報データベース２６３は、当該サーバ以外のサーバに記憶されていてもよく、他のアプリケーションのＡＰＩを利用し他のアプリケーションのデータベースを参照してもよく、アプリケーション、データベースを分散し、相互に適宜参照、更新可能に構成してもよい。

２回目以降購入候補店舗情報を受信した移動端末は、店舗購入要求処理ルーチン（Ｔ２４）を実行し、例えば例えば図１２の４８０に示すような画面遷移処理を行う。そしてユーザが購入対象指定入力を行うと（Ｕ２４）、購入対象店舗指定情報を含む店舗購入要求をサーバに送信する（ｔ２５）。

店舗購入要求を受信したサーバは、店舗購入処理ルーチン（Ｓ２４）を実行し、店舗購入結果に基づきユーザ情報データベースのゲームデータ（所有店舗リスト）や店舗情報データベースのゲームデータ（所有者リスト）等を更新し、店舗購入完了通知を移動端末に送信する（ｓ２５）。

図２８はサーバで行われる２回目以降購入候補店舗情報送信処理の流れを示すフローチャートである。

また移動端末から、現在位置情報を含む購入候補店舗情報送信要求を受信すると（ステップＳ１３２）、店舗情報データベースを検索して、受信した現在位置から所定範囲内の店舗を抽出する（ステップＳ１３６）。

抽出した店舗の店舗価格が演算済みでない場合には、当該店舗の住所情報に基づき地価情報データベースを検索して、住所に対応する地価を求め、求めた地価に基づき当該店舗の店舗価格を演算する（ステップＳ１３８）。

要求もとのユーザのパラメータテーブル（図８の所持金等）を参照して要求元のユーザの所持金を取得する（ステップＳ１４０）。

抽出した店舗に、要求元のユーザの所持金以下の店舗価格のものがあるか否か判断し、ある場合には（ステップＳ１４２でＹ）、抽出した店舗に関する情報を購入候補店舗情報として移動端末に送信する。ここで、要求元のユーザの所持金より高い店舗を含めて購入公報店舗情報として送信してもよい。このとき、要求元のユーザの所持金以下の店舗については、購入可能フラグを付与して送信してもよい。

要求元のユーザの所持金以下の店舗価格ない場合には（ステップＳ１４２でＮ）、購入可能な店舗がない旨を送信する（ステップＳ１５２）。なお購入可能な店舗がない場合でも抽出した店舗に関する情報を購入候補店舗情報として移動端末に送信してもよい。このときこのとき、要求元のユーザの所持金以下の店舗については、購入可能フラグを付与して送信してもよい。そして移動端末側でこの購入可能フラグがあるか否か参照して購入可能な店舗があるか否か判断して画面表示制御を行ってもよい。

４−３．アルバイト処理（訪問地でアルバイトを行う場合）
図２９は、アルバイト処理（訪問地でアルバイトを行う場合）におけるサーバと移動端末の処理について説明するための図である。

移動端末はアルバイト先候補店舗情報送信要求処理ルーチン（Ｔ３２）を実行し、例えば図１３の４９０、４３０、４４０で説明したような画面遷移処理を行う。そしてユーザがアルバイト希望入力を行うと（Ｕ３２）、移動端末は位置情報を取得し、取得した位置情報を含むアルバイト先候補店舗情報送信要求をサーバに送信する（ｔ３３）。

アルバイト先候補店舗情報送信要求を受信したサーバは、アルバイト先候補店舗情報送信処理ルーチン（Ｓ３２）を実行し、店舗情報データベース２６２の店舗の位置情報、ユーザ情報データベースのスタミナ等を参照してアルバイト先候補店舗情報を作成し、要求元の移動端末に送信する（ｓ３３）。なお店舗情報データベース２６２やユーザ情報データベース２６１は、当該サーバ以外のサーバに記憶されていてもよく、他のアプリケーションのＡＰＩを利用し他のアプリケーションのデータベースを参照してもよく、アプリケーション、データベースを分散し、相互に適宜参照、更新可能に構成してもよい。

アルバイト先候補店舗情報を受信した移動端末は、アルバイト要求処理ルーチン（Ｔ３４）を実行し、例えば例えば図１４の５００、５１０に示すような画面遷移処理を行う。そしてユーザがアルバイト先指定入力を行うと（Ｕ３４）、アルバイト先店舗指定情報を含むアルバイト要求をサーバに送信する（ｔ３５）。

アルバイト要求を受信したサーバは、アルバイト処理ルーチン（Ｓ３４）を実行しアルバイト結果を反映させてユーザ情報データベースのスタミナ、所持金、経験値や所有店舗リストの今回アルバイト人数や累計アルバイト人数等を更新し、店舗情報データベースのアルバイト件数やアルバイト者リスト等を更新し、アルバイト完了通知を移動端末に送信する（ｓ３５）。

図３０はサーバで行われるアルバイト先候補店舗情報送信処理の流れを示すフローチャートである。

移動端末から、現在位置情報を含むアルバイト先候補店舗情報送信要求を受信すると（ステップＳ１６２）、店舗情報データベースを検索して、受信した現在位置から所定範囲内の店舗を抽出する（ステップＳ１６６）。

抽出した店舗に関する情報をアルバイト先候補店舗情報として要求元の移動端末に送信する（ステップＳ１７０）。

図３１はサーバで行われるアルバイト処理の流れを示すフローチャートである。

移動端末からアルバイト先店舗指定情報を含むアルバイト要求を受信すると以下の処理を行う（ステップＳ１７２）。

要求元のユーザのスタミナ値はアルバイト可能条件を満たしているか否か判断し、満たしていない場合には（ステップＳ１７４でＮ）、アルバイト不可通知を要求元の移動端末に送信する（ステップＳ１７６）。例えばスタミナ値が所定値以上あればアルバイト可能要件を満たしていると判断してもよい。

満たしている場合には（ステップＳ１７４でＹ）、要求元のユーザの所定のゲームパラメータを更新する（ステップＳ１７８）。例えばスタミナ値から所定値を減算してもよいし、経験値を所定だけ増加させてもよいし、所持金額を所定値だけ増加させてもよい。

また要求元のユーザをアルバイト先として指定された店舗のアルバイト者リストに追加するとともに、当該店舗のアルバイト件数を更新する（ステップＳ１８０）。さらにアルバイト先として指定された店舗の所有者リストに登録されている他のユーザの所定のゲームパラメータを更新する（ステップＳ１８２）。例えば来客数や残り時間や累計アルバイト人数や今回アルバイト人数や売上値や売上増減値等の少なくとも１つを更新するようにしてもよい。

そしてアルバイト完了通知を要求元の移動端末に送信する（ステップＳ１８４）。

４−４．アルバイト処理（友人の店舗でアルバイトを行う場合）
図３２は、アルバイト処理（友人の店舗でアルバイトを行う場合）におけるサーバと移動端末の処理について説明するための図である。

移動端末は他のユーザのアルバイト先候補の友人店舗情報送信要求処理ルーチン（Ｔ４０）を実行し、例えば図１９の５２０で説明したような画面遷移処理を行う。そしてユーザがアルバイト希望入力を行うと（Ｕ４２）、アルバイト先候補の友人店舗情報送信要求をサーバに送信する（ｔ４３）。

アルバイト先候補の友人店舗情報送信要求を受信したサーバは、アルバイト先候補の友人店舗情報送信処理ルーチン（Ｓ４２）を実行し、ユーザ情報データベース２６１の所有店舗リスト店舗情報データベースの店舗情報等を参照してアルバイト先候補の友人店舗情報を作成し、要求元の移動端末に送信する（ｓ４３）。なお店舗情報データベース２６２やユーザ情報データベース２６１は、当該サーバ以外のサーバに記憶されていてもよく、他のアプリケーションのＡＰＩを利用し他のアプリケーションのデータベースを参照してもよく、アプリケーション、データベースを分散し、相互に適宜参照、更新可能に構成してもよい。

アルバイト先候補の友人店舗情報を受信した移動端末は、アルバイト要求処理ルーチン（Ｔ４４）を実行し、例えば図１９の５３０、５４０に示すような画面遷移処理を行う。そしてユーザがアルバイト先指定入力を行うと（Ｕ４４）、アルバイト先店舗指定情報を含むアルバイト要求をサーバに送信する（ｔ４５）。

アルバイト要求を受信したサーバは、アルバイト処理ルーチン（Ｓ４４）を実行しアルバイト結果を反映させてユーザ情報データベースのスタミナ、所持金、経験値や所有店舗リストの今回アルバイト人数や累計アルバイト人数等を更新し、店舗情報データベースのアルバイト件数やアルバイト者リスト等を更新し、アルバイト完了通知を移動端末に送信する（ｓ４５）。

４−５．スタッフ追加処理
図３３は、スタッフ追加処理におけるサーバと移動端末の処理について説明するための図である。

移動端末は追加可能スタッフ情報送信要求処理ルーチン（Ｔ５０）を実行し、例えば図２３の６５０、６６０で説明したような画面遷移処理を行う。そしてユーザがスタッフ追加希望入力を行うと（Ｕ５２）、追加可能スタッフ情報送信要求をサーバに送信する（ｔ５３）。

追加可能スタッフ情報送信要求を受信したサーバは、追加可能スタッフ情報送信処理ルーチン（Ｓ５２）を実行し、追加可能スタッフ情報を生成し、要求元の移動端末に送信する（ｓ５３）。例えばユーザ情報データベース２６１の友人情報から要求元のユーザの友人である他のユーザを検索し、他のユーザのゲームデータのゲーム参加フラグ（図８の３７０）が、当該ユーザがゲーム参加者であることを示している場合に、スタッフとして追加可能な友人であると判断して追加可能スタッフ情報を生成してもよい。なおユーザ情報データベース２６１は、当該サーバ以外のサーバに記憶されていてもよく、他のアプリケーションのＡＰＩを利用し他のアプリケーションのデータベースを参照してもよく、アプリケーション、データベースを分散し、相互に適宜参照、更新可能に構成してもよい。

追加可能スタッフ情報を受信した移動端末は、スタッフ追加要求処理ルーチン（Ｔ５４）を実行し、例えば図２３の６７０に示すような画面遷移処理を行う。そしてユーザがスタッフ先指定入力を行うと（Ｕ５４）、指定スタッフ情報を含むスタッフ追加要求をサーバに送信する（ｔ５５）。

スタッフ追加要求を受信したサーバは、スタッフ追加処理ルーチン（Ｓ５４）を実行しユーザ情報データベースのスタミナ数やスタッフリストにスタッフ追加を反映させて更新し、スタッフ追加完了通知を移動端末に送信する（ｓ５５）。

４−６．売上回収処理
図３４は、売上回収処理におけるサーバと移動端末の処理について説明するための図である。

移動端末は所有店舗情報送信要求処理ルーチン（Ｔ６２）を実行し、例えば図２０の４９０で説明したような画面遷移処理を行う。そしてユーザが所有店舗閲覧希望入力を行うと（Ｕ６２）、所有店舗情報閲覧要求をサーバに送信する（ｔ６３）。

所有店舗情報閲覧要求を受信したサーバは、所有店舗情報送信処理ルーチン（Ｓ６２）を実行し、ユーザ情報データベースに要求元のユーザのユーザ識別情報に関連づけて記憶されているゲームデータである所有店舗リストの各種情報等に基づき、所有店舗情報を生成し、要求元の移動端末に送信する（ｓ６３）。なお店舗情報データベース２６２やユーザ情報データベース２６１は、当該サーバ以外のサーバに記憶されていてもよく、他のアプリケーションのＡＰＩを利用し他のアプリケーションのデータベースを参照してもよく、アプリケーション、データベースを分散し、相互に適宜参照、更新可能に構成してもよい。

所有店舗情報を受信した移動端末は、売上回収要求処理ルーチン（Ｔ６４）を実行し、例えば図２０の５６０に示すような画面遷移処理を行う。そしてユーザが売上回収店舗指定入力を行うと（Ｕ６４）、指定店舗情報を含む売上回収要求をサーバに送信する（ｔ６５）。

売上回収要求を受信したサーバは、売上回収処理ルーチン（Ｓ６４）を実行しユーザ情報データベースに要求元のユーザのユーザ識別情報に関連づけて記憶されているゲームデータである所有店舗リストの各種情報等を、売上回収を反映させて更新し、売上回収完了通知を移動端末に送信する（ｓ６５）。

また上記実施の形態では仮想的な店舗を購入して売上を回収し、他の仮想的な店舗でアルバイトして資金や経験値を増加させて楽しむゲームを例にとり説明したが、これに限られない。例えば他の仮想的な店舗に客として訪問するゲームでもよい。実世界の位置情報に関連づけて設定されている少なくとも２種類のイベントについて、各イベントに関連づけられている実世界の位置情報と、移動端末の現在位置情報に基づき行われるゲームであれば、イベントの設定が異なっていても本発明の範囲内である。

上記実施の形態では、撮影装置が撮影装置である場合を例にとり説明したがこれに限られない。例えば撮影装置は、業務用ゲームシステム、家庭用ゲームシステム、携帯型ゲームシステム等のいずれのタイプでも構成可能であり、ゲームの種類もシューティングゲームやレースゲームやロールプレイングゲームやパズルゲーム等の種々のゲームシステムに適用できる。

１ ゲーム提供システム、１０ 移動端末、１１ 通信制御部、１２ 位置情報取得処理部、１３ 入力操作部、１４ 音信号処理部、１５ 表示部、１６ 制御部、１７ マイク、１８ スピーカ、１９ａ、１９ｂ アンテナ、２０ サーバ、部、
１１２ 移動・動作処理部、１１３ ネットワーク設定部、
２００ 処理部、２１０ ネットワーク設定部、２１１ 通信制御部、２１２ 取得処理部、２１３ 訪問処理部、２１４ 協力者登録処理部、２１５ パラメータ演算部、２１６ 仮想価格演算部、２１７ 排他制御部、２１８ 仮想売上回収処理部、２１９ 仮想イベントエリア抽出処理部、２６０ 情報格納部、２６１ ユーザ情報、２６２ 仮想イベントエリア情報、２６３ 地価情報、２８０ 情報記憶媒体、２９６ 通信部

Claims (7)

1. サーバがネットワークを介して複数の移動端末にゲームを提供するゲーム提供プログラムであって、
   前記移動端末において取得した現在位置情報に基づき、取得した現在位置から所与の範囲内の位置情報に対応づけられた仮想イベントエリアを抽出する仮想イベントエリア抽出手段と、
   仮想イベントエリア抽出手段が抽出した仮想イベントエリアに関する情報を取得候補情報として移動端末を介してユーザに提供し、提供した取得候補情報の仮想イベントエリアに対する取得要求を前記移動端末から受け取った場合、当該仮想イベントエリアをユーザの取得情報としてユーザ識別情報に対応づけて記憶させる取得処理手段と、
   仮想イベントエリア抽出手段が抽出した仮想イベントエリアに関する情報を訪問候補情報として移動端末を介してユーザに提供し、提供した訪問候補情報の仮想イベントエリアに対する訪問要求を前記移動端末から受け取る訪問処理手段と、
   前記仮想イベントエリアの取得要求及び／又は訪問要求に応じて、ユーザの成績値及びゲームパラメータの少なくとも１つを演算するパラメータ演算手段と、
   してコンピュータを機能させ、
   前記訪問処理手段は、
   ユーザと関係付けられた他のユーザを特定するための情報に基づき、ユーザと関係のある他のユーザを判断して、当該他のユーザの取得情報として記憶された仮想イベントエリアに関する情報を訪問候補情報として移動端末を介してユーザに提供することを特徴とするプログラム。
2. 請求項１において、
   前記訪問処理手段は、
   仮想イベントエリアへの訪問要求を受け取った場合、訪問要求元のユーザの識別情報を当該仮想イベントエリアに対応づけられた訪問記録情報として記憶させ、
   前記パラメータ演算手段は、
   仮想イベントエリアへの訪問要求を受け取った場合、訪問要求元のユーザの成績値又は所定のゲームパラメータを変更することを特徴とするプログラム。
3. 請求項１又は２において、
   前記取得処理手段は、
   ユーザと関係付けられた他のユーザを特定するための情報および取得情報に基づき、抽出した仮想イベントエリアの取得者に要求元のユーザと関係のあるユーザがいるか否か判断し、判断結果に基づきユーザの移動端末に提供する際の優先順位を決定することを特徴とするプログラム。
4. 請求項１乃至３のいずれかにおいて、
   ユーザと関係付けられた他のユーザの取得した仮想イベントエリアについては取得できないように排他制御を行う排他制御処理手段と、してさらにコンピュータを機能させることを特徴とするプログラム。
5. 請求項４において、
   前記排他制御処理手段は、
   仮想イベントエリア抽出手段が抽出した仮想イベントエリアを取得したユーザの中に、ユーザと関係付けられた他のユーザいる場合には、前記他のユーザ対して交渉要求を通知するとともに、他のユーザから交渉受け入れ可を示す応答を受信した場合には、他のユーザの当該仮想イベントエリアの取得を解除するとともに、ユーザについて当該仮想イベントエリアを取得させる処理を行うことを特徴とするプログラム。
6. 請求項１乃至５のいずれかにおいて、
   ゲームユーザとして登録されている他のユーザに関する情報を、協力者候補情報として、移動端末を介してユーザに提供し、前記移動端末から、他のユーザを指定した協力要求を受け取った場合、当該他のユーザをユーザの協力者として登録する協力者登録手段と、してさらにコンピュータを機能させ、
   前記パラメータ演算手段は、
   ユーザに協力者が登録された場合には、当該ユーザの成績値及びゲームパラメータの少なくとも１つを変更することを特徴とするプログラム。
7. サーバがネットワークを介して複数の移動端末にゲームを提供するゲーム提供システムであって、
   仮想イベントエリアとそれに対応する位置情報を含む仮想イベントエリア情報が記憶された仮想イベントエリア情報記憶手段と、
   前記移動端末において取得した現在位置情報に基づき、取得した現在位置から所与の範囲内の位置情報に対応づけられた仮想イベントエリアを抽出する仮想イベントエリア抽出手段と、
   仮想イベントエリア抽出手段が抽出した仮想イベントエリアに関する情報を取得候補情報として移動端末を介してユーザに提供し、提供した取得候補情報の仮想イベントエリアに対する取得要求を前記移動端末から受け取った場合、当該仮想イベントエリアをユーザの取得情報としてユーザ識別情報に対応づけて記憶させる取得処理手段と、
   仮想イベントエリア抽出手段が抽出した仮想イベントエリアに関する情報を訪問候補情報として移動端末を介してユーザに提供し、提供した訪問候補情報の仮想イベントエリアに対する訪問要求を前記移動端末から受け取る訪問処理手段と、
   前記仮想イベントエリアの取得要求及び／又は訪問要求に応じて、ユーザの成績値及びゲームパラメータの少なくとも１つを演算するパラメータ演算手段と、を含み、
   前記訪問処理手段は、
   ユーザと関係付けられた他のユーザを特定するための情報に基づき、ユーザと関係のある他のユーザを判断して、当該他のユーザの取得情報として記憶された仮想イベントエリアに関する情報を訪問候補情報として移動端末を介してユーザに提供することを特徴とす
   るゲーム提供システム。

Images