JP7721735B2 - プログラム、及び、システム - Google Patents

Description

本発明は、プログラム、及び、システムに関する。

従来、Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ（ＧＮＳＳ）等の位置情報を利用したゲーム、又は、アプリケーションソフトウェアが知られている。具体的には、ユーザが操作する操作端末が、位置情報を取得する。そして、ユーザの位置情報に基づき、仮想マップ上でオブジェクトの位置を変更する技術が知られている（例えば、特許文献１等である）。

特許６０７５４８９号公報

例えば、ゲームを進行させていくと、ユーザの位置、又は、周囲の状況等によって、位置情報を取得できない場合がある。このように、位置情報が取得できない状態になると、ゲームが中断する、又は、エラーになる等といった不具合が生じる課題がある。

本発明は、位置情報取得の状態による不具合が生じるのを防ぐことを目的とする。

本発明は、前記課題を解決するため、プログラムは、
コンピュータに、
ユーザが利用するアカウントに関連付けられた第１位置情報によりイベントを進行させ、
前記第１位置情報が取得できない場合、操作用のＧＵＩを出力し、前記操作用のＧＵＩで前記ユーザが入力する情報により、前記イベントを進行させ、
前記操作用のＧＵＩによるイベントの進行を制限することを可能にさせる。

本発明によれば、位置情報取得の状態による不具合が生じるのを防ぐことができる。

システムの構成例を示す図である。 情報処理装置のハードウェア構成例を示す図である。 イベントの進行例を示す図である。 全体処理例を示すシーケンス図である。 第２位置情報の使用例である。 移動履歴情報の例を示す図である。 第２位置情報の使用の通知例を示す図である。 報酬の例を示す図である。 報酬の保留例を示す図である。 バーチャルパットの例を示す図である。 第２情報処理端末を用いる変形例を示す図である。 機能構成例を示す図である。

以下、実施形態を図面に基づいて説明する。

［システム構成例］
図１は、システムの構成例を示す図である。例えば、システム１は、第１情報処理端末３、及び、サーバ４等を有する構成である。

第１情報処理端末３は、例えば、スマートフォン、パーソナルコンピューター、ゲーム機、スマートグラス（眼鏡型の端末である。）、リストバンド型の端末、又は、その他身体に取り付けるウェアラブルデバイス等である。

サーバ４は、ゲーム等の運用に用いる情報処理装置である。例えば、サーバ４は、管理者等が管理するゲームを運用するのに用いる情報処理装置である。また、サーバ４には、各ユーザのアカウント情報が記憶される。例えば、ユーザ２がゲームを開始する前に個人情報等を登録すると、アカウントが生成されてアカウント情報がサーバ４に記憶される。以降、ユーザ２は、アカウントを利用してゲーム等のサービスを利用できる。

ユーザ２が使用する第１情報処理端末３からの指示により、情報を引き出すことでゲーム等のアプリを実行する。すなわち、ユーザ２が使用する情報処理装置が違っていても利用するアカウントが同じであれば、同じゲームデータを進行させることが可能である。もちろん、セキュリティの観点から、第１情報処理端末３のハードウェア固有の識別情報（例えば、物理アドレス等である。）を用いて、登録された所定の情報処理装置からしかアカウントを利用できないようにしてもよい。

なお、アカウントは、メールアドレス、Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ（ＳＮＳ）、電話番号、又は、生体情報等のセキュリティ情報と紐づけてよい。そして、ログイン等において、事前にアカウントに紐づけされている情報を用いて、ユーザ２を認証する。このようにして、アカウントを使用する際におけるセキュリティを確保する。

また、同じアカウントに関連付けられた他のサービスのデータは、適宜連携させることができる。

第１情報処理端末３は、ＧＮＳＳにより、位置情報を取得する。具体的には、衛星５が上空から第１情報処理端末３の位置を計測した結果を第１情報処理端末３に送って、第１情報処理端末３が現在位置を示す位置情報を取得する。なお、位置情報は、サーバ４を介する等で取得されてもよい。また、位置情報は、実行中のアプリのアカウントに関連付けられる。

なお、システム１の構成は、上記以外の装置があってもよい。例えば、システム１には、サーバ４がなく、第１情報処理端末３だけで構成する、所謂スタンドアロン型の構成でもよい。一方で、システム１は、例えば、サーバ４が複数ある構成等でもよい。

［情報処理装置の例］
図２は、情報処理装置のハードウェア構成例を示す図である。例えば、第１情報処理端末３、及び、サーバ４は、図示するようなハードウェア構成の情報処理装置である。ただし、第１情報処理端末３、及び、サーバ４は、異なるハードウェア構成であってもよい。以下、第１情報処理端末３を例に説明する。

第１情報処理端末３は、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（以下「ＣＰＵ３Ｈ１」という。）、記憶装置３Ｈ２、センサ３Ｈ３、入出力装置３Ｈ４、及び、通信装置３Ｈ５を有するハードウェア構成である。

ＣＰＵ３Ｈ１は、演算装置、及び、制御装置の例である。したがって、ＣＰＵ３Ｈ１は、プログラムに基づき、各種の処理、及び、制御を行う。

記憶装置３Ｈ２は、データ等を記憶する主記憶装置（揮発性である。）である。また、記憶装置３Ｈ２は、Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）、又は、ハードディスク等の補助記憶装置（不揮発性である。）を有してもよい。

センサ３Ｈ３は、センシングにより、位置情報等を取得する。なお、センサ３Ｈ３は、取得する情報の種類によって異なる。また、センサ３Ｈ３は、複数であってもよい。

入出力装置３Ｈ４は、ユーザ２による操作を入力する、及び、ユーザ２に対して処理結果を出力する装置である。具体的には、入出力装置３Ｈ４は、タッチパネル等である。ただし、入出力装置３Ｈ４は、入力装置、及び、出力装置の組み合わせ等でもよい。

通信装置３Ｈ５は、外部装置とデータを送受信する。例えば、通信装置３Ｈ５は、アンテナ等である。ただし、通信装置３Ｈ５は、有線通信を用いてもよい。

なお、情報処理装置のハードウェア構成は、上記の構成に限られない。例えば、第１情報処理端末３は、演算装置、制御装置、記憶装置、入力装置、出力装置、及び、補助装置を外部、又は、内部に更に備えてもよい。

［イベントの例］
図３は、イベントの進行例を示す図である。以下、イベントの進行がゲーム、すなわち、仮想空間内に反映される例で説明する。

例えば、第１情報処理端末３は、ゲームのアプリを起動し、ユーザ２の進行情報が記録されたアカウントを利用してゲームを進行させる。なお、ユーザ２が選択可能なアカウントが複数存在する場合、ユーザ２にどのアカウントを利用してゲームの実行を始めるか選択させる。

また、この起動時等に、ユーザ２のアカウントと情報処理端末が取得する位置情報等のセンサ情報の同期を行う。次に、ゲーム画面１０を出力して、ユーザ２にイベントの進行を表示する。具体的には、ユーザ２が現実空間において移動すると、仮想空間内におけるキャラクタ１１（オブジェクトの一例である。）が移動するイベントが進行する。すなわち、ゲームでは、ユーザ２の位置情報に応じて、キャラクタ１１の移動というイベントが進行する。

位置情報に基づき、例えば、ユーザ２が「北に１ｍ（歩行によって）移動」したと判定されると、キャラクタ１１が「（仮想空間内の）北に１００歩移動」のように、ユーザ２の移動する方角（進行方向等でもよい。）、距離（歩数等でもよい。）、速度、及び、高低差等が考慮されて、仮想空間上に反映される。

なお、イベントは、キャラクタ１１の移動に限られず、事前に設定するゲーム上の他のイベントでもよい。例えば、イベントは、キャラクタ１１の移動中に、アイテム１２の取得、目的地への到達、拠点の制圧、他のユーザとの対戦、他のユーザとの共同作業、又は、敵キャラクタ１３との戦闘等があってもよい。

ただし、アイテム１２、及び、敵キャラクタ１３等は、事前に仮想空間上のマップに配置され、キャラクタ１１の移動結果に応じて、アイテム１２の取得等のイベントが生じる。

したがって、イベントが進行すると、仮想空間内におけるキャラクタ１１の位置が変化、キャラクタ１１のパラメータが変化（例えば、キャラクタ１１の回復、又は、強化等である。）、又は、ストーリが変化等が生じる。

［シーケンス例］
図４は、全体処理例を示すシーケンス図である。例えば、全体処理は、以下のような手順で実行される。

ステップＳ０１では、第１情報処理端末３は、位置情報（以下「第１位置情報」という。）を取得する。第１位置情報の取得方法等は事前に設定される。なお、第１位置情報は、実行中のアプリのアカウントに関連付けられる。

ステップＳ０２では、第１情報処理端末３は、第１位置情報が取得できない場合（図において「第１位置情報が取得できない場合」と判断された場合である。）、第１位置情報とは異なる位置情報（以下「第２位置情報」という。）を取得する。

第２位置情報は、第１位置情報と同じように、実行中のアプリのアカウントに関連付けられる。また、アカウントには、「第１位置情報が取得できない」等の判断結果も関連付けして記憶されてもよい。

ステップＳ０３では、第１情報処理端末３は、サーバ４に、第１位置情報、又は、第２位置情報を送信する。すなわち、第１情報処理端末３は、第１位置情報を取得できた場合には、第１位置情報をサーバ４に送信する。一方で、第１情報処理端末３は、第１位置情報を取得できなかった場合には、第２位置情報をサーバ４に送信する。

ステップＳ０４では、サーバ４は、第１情報処理端末３に、第１位置情報、又は、第２位置情報の反映結果を送信する。すなわち、ステップＳ０４は、ステップＳ０３による送信に対する返信となる。

ステップＳ０５では、第１情報処理端末３は、反映結果に基づき、イベントを進行させる。すなわち、ステップＳ０５では、第１位置情報、又は、第２位置情報を反映させたゲームの進行結果が第１情報処理端末３によって、ユーザ２に表示される。なお、イベントの進行状況、又は、イベントの進行結果等は、実行中のアプリのアカウントに関連付けられる。

第１位置情報は、例えば、ＧＮＳＳにおける衛星５と通信を行って取得される。例えば、第１情報処理端末３が地下に位置する、又は、人が多くいる場（例えば、花火会場、又は、満員電車等である。）であると、第１情報処理端末３は、第１位置情報を取得できない場合がある。

そこで、第１位置情報を取得できない場合（何度かリトライしてもよい。）、第１情報処理端末３は、第２位置情報に切り替える。

第１位置情報、及び、第２位置情報の切り替え（第１位置情報から第２位置情報に切り替え、及び、第２位置情報から第１位置情報に切り替えの両方を含む。図４ではステップＳ０２等が該当する。）は、事前の設定に基づき、自動的に実行されるのが望ましい。すなわち、第１位置情報、及び、第２位置情報の切り替えは、ユーザ２の操作がなく実行されるのが望ましい。

ユーザ２の操作を必要とせず、第１位置情報、及び、第２位置情報の切り替えが実行されると、ユーザ２が第１情報処理端末３の画面を見る等の行動を減らすことができ、所謂「歩きスマホ」を少なくできる。

第１位置情報、及び、第２位置情報をどのように取得する等は事前に設定される。なお、第１位置情報、及び、第２位置情報は、複数種類の組み合わせ等でもよい。

［第１位置情報、及び、第２位置情報の例］
第１位置情報は、例えば、ＧＮＳＳを利用して取得される位置情報である。なお、第１位置情報は、ＧＮＳＳによる位置情報をセンサデータ等によって補正した位置情報等でもよい。したがって、第１位置情報は、ＧＮＳＳ以外を利用して取得される位置情報でもよい。

第２位置情報は、例えば、カメラによる位置判定結果、第１位置情報とは異なる衛星で取得する位置情報、歩数計による計測結果、加速度センサによる計測結果、地磁気の計測結果、気圧センサによる計測結果、無線による位置特定結果、生体情報（例えば、発汗量、又は、カロリー消費量等である。）の変化に基づく移動量に換算した位置情報、又は、これらの組み合わせである。

第１位置情報と第２位置情報は、どちらもユーザ２の位置を特定する情報であるが、情報を生成する方法が異なる。例えば、第１位置情報と第２位置情報は、情報源、又は、異なる種類のセンサで生成される。したがって、何らかの理由により、第１位置情報用のセンサ等が情報を生成できない場合であっても、第２位置情報用のセンサであれば、情報の生成が可能な場合がある。

このように、第１位置情報と第２位置情報は、同一のユーザ２における同一の時点を示す関係である。ゆえに、第１位置情報と第２位置情報は、例えば、どちらもＧＰＳを利用して生成し、かつ、計測を行った時点のみが異なる位置情報の組み合わせ等ではない（これはどちらも第１位置情報となる場合である）。したがって、どのようにして第１位置情報、及び、第２位置情報を生成するかは事前に設定されるが、第２位置情報は、第１位置情報が使用できない環境下でも取得できる可能性が高いセンサ等で生成されるのが望ましい。

カメラによる位置判定は、例えば、ＳＬＡＭ（Ｓｉｍｕｌｔａｎｅｏｕｓ Ｌｏｃａｌｉｚａｔｉｏｎ ａｎｄ Ｍａｐｐｉｎｇ）等である。すなわち、第１情報処理端末３がカメラを備える場合、カメラでユーザ２の周辺を撮影する。撮影後、撮像データに基づき、周辺にある建物等を画像認識する。このような画像認識が行われると、周辺に存在する建物等が特定できるため、建物等の住所、及び、位置関係等によって、ユーザ２の位置、及び、進行方向等が特定できる。

第１位置情報とは異なる衛星で取得する位置情報は、例えば、第２位置情報は、準天頂衛星を利用して取得される等である。日本国である場合、準天頂衛星を利用するシステムは、ＱＺＳＳ（Ｑｕａｓｉ－Ｚｅｎｉｔｈ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）等である。例えば、第１位置情報がＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）を利用する場合、第２位置情報、すなわち、第１位置情報とは異なる衛星を利用して位置情報を取得すると、第１位置情報は取得できなくとも、第２位置情報は取得できる場合がある。

歩数計による計測結果、加速度センサによる計測結果、地磁気の計測結果、又は、気圧センサによる計測結果は、例えば、第１位置情報が取得できた最後の位置から、その後、歩数計、又は、加速度センサ等のセンサでユーザ２の動作を計測して計測結果を加えて現在位置（すなわち、第２位置情報とする。）と推測する。

もし、歩数計等では、進行方向が不明とする場合には、最後の位置までの進行方向がその後も同じであると仮定して現在位置を推定してもよい。一方で、地磁気、又は、気圧等によって、高低差、又は、進行方向等が特定できる場合には、最後の位置までの進行速度がその後も同じであると仮定して現在位置を推定してもよい。

無線は、例えば、Ｗｉ－Ｆｉ（登録商標）、又は、Ｂｌｕｅｔｏｏｔｈ（登録商標）等である。すなわち、無線を用いると、電波が届く範囲等に基づき、位置、及び、方向を特定できる場合がある。具体的には、Ｂｌｕｅｔｏｏｔｈ（登録商標）では、受信角度（ＡｏＡ：Ａｎｇｌｅ ｏｆ Ａｒｒｉｖａｌ）、及び、放射角度（ＡｏＤ：Ａｎｇｌｅ ｏｆ Ｄｅｐａｒｔｕｒｅ）等で方向が特定できる。このように、特に屋内では、ユーザ２の位置等を特定するのに無線を用いると、精度良く特定できる場合が多い。

なお、無線の規格等は、上記以外の近距離通信用の規格等でもよい。

位置情報の生成には、上記以外のセンサ情報が用いられてもよい。例えば、位置情報の生成には、音、光、電波、又は、速度等を計測するセンサによる計測結果が用いられてもよい。

また、第１位置情報、及び、第２位置情報は、複数のデータから平均値等の統計値を計算して生成されてもよい。

図５は、第２位置情報の使用例である。例えば、ユーザ２は、第１情報処理端末３を携帯して移動しているとする。

ユーザ２が移動し、ある位置に到達した時点（以下「第１時点Ｔ１」という。）から、第１位置情報が取得できなくなるとする。例えば、第１時点Ｔ１は、ユーザ２が地下道に入った時点等である。

第１時点Ｔ１から、次に第１位置情報の取得を再開できる時点（以下「第２時点Ｔ２」という。）までは、第１情報処理端末３は、第１位置情報に代えて、第２位置情報を取得する。したがって、第１時点Ｔ１から第２時点Ｔ２までの間は、第２位置情報に基づき、ゲームが進行する。

そして、第２時点Ｔ２、例えば、ユーザ２が地下道から出た時点になると、第１位置情報の取得が再開される。したがって、第２時点Ｔ２以降、すなわち、第１位置情報の取得が再開された場合、第１情報処理端末３は、第１位置情報に基づき、ゲームを進行する。

なお、第２位置情報を用いる場合は、第１位置情報を取得できていた場合を条件にするのが望ましい。すなわち、第２位置情報を用いるのは、直前まで第１位置情報が取得できていた場合に限るのが望ましい。

最初から第１位置情報が取得できない状態でゲームが開始された場合は、第１位置情報を意図的に取得できないようにしている場合があり、ゲームにおいて不正の操作となる可能性がある。したがって、図５に示す第１時点Ｔ１までの時間のように、第１位置情報でゲームを進行させた履歴があるのを条件に、第１情報処理端末３は、第２位置情報を用いるように切り替える。このような第１位置情報を取得した履歴があるのを条件にすると、不正を防ぐことができる。

なお、履歴は、ゲームの進行のバックグラウンドで位置情報が第１位置情報であるか第２位置情報であるか等を時刻と伴に記録される。

［移動履歴情報の例］
図６は、移動履歴情報の例を示す図である。例えば、移動履歴情報は、過去ルート２０のように記憶される。なお、図６に示す地図は、現実空間の地図である。

過去ルート２０は、第１ルート２１、第２ルート２２、及び、第３ルート２３で構成されるとする。そして、第１ルート２１、第２ルート２２、及び、第３ルート２３のうち、第１ルート２１、及び、第３ルート２３が第１位置情報に基づいて特定されたルートであるとする。一方で、第２ルート２２は、第２位置情報に基づいて特定されたルートであるとする。

例えば、ユーザ２が第１地点Ｐ１で地下道に入り、その後、第２地点Ｐ２で地下道から出るようなルートを歩くと、過去ルート２０が記録される。すなわち、過去ルート２０は、第１地点Ｐ１から第２地点Ｐ２の間、第２位置情報が使用される例である。

過去ルート２０が記録されている場合、第１情報処理端末３は、第２位置情報として、過去ルート２０を用いてよい。

例えば、第１地点Ｐ１付近までは、第１位置情報が取得でき、かつ、第２地点Ｐ２付近で第１位置情報の取得が再開できた場合には、第１情報処理端末３は、記録しているルート（群）データを検索する。そして、第１情報処理端末３は、第１位置情報が取得不可となった地点、及び、第１位置情報が取得再開となった地点が近しいを同様のルートと推定する。そして、第１情報処理端末３は、推定された過去ルート２０を今回も同様の移動をしたと推定し、第２位置情報とする。このような移動履歴情報に基づく推定結果を使用できると、第１情報処理端末３は、センサ等を使用しなくともイベントを進行させることができる。

なお、過去ルート２０は、複数（例えば、３回以上等である。）記録がある場合に限定されるのが望ましい。複数の同様の過去ルート２０が記録されるのは、ユーザ２が同様のルートを高い頻度で使用する場合である。

具体的には、複数の同様の過去ルート２０が記録されるのは、所謂「通勤路」、又は、「通学路」等であって、ユーザ２が日常生活等でよく使用するルートである。このようなルートであれば、推定結果と実際にユーザ２が移動したルートが一致する可能性が高い。

すなわち、複数の移動履歴情報がある場合、第１地点Ｐ１及び第２地点Ｐ２等のような第１位置情報によって特定できる情報で、第１位置情報が取得できない間の位置情報を移動履歴情報に基づく推定結果で精度良く補うことができる。

なお、ルートの判定等は、例えば、Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ（ＡＩ、人工知能）等が用いられてもよい。すなわち、ＡＩにルートを事前に学習させ、学習済みモデルがどのようなルートを取るか推定する構成であってもよい。

［第２位置情報の使用制限例］
第２位置情報を用いるのは、時間、回数、又は、移動量の制限があるのが望ましい。また、第２位置情報を用いたイベントの進行（以下、第２位置情報に基づいて進行するイベントの進行度合いを「イベントの進行度」という。）は、制限されるのが望ましい。

例えば、第２位置情報を用いる時間が制限される。制限時間は、例えば、「１時間」等のように事前に設定される。このような制限がある場合には、第２位置情報を用いたゲームの進行は、最大１時間である。つまり、この制限では、第１位置情報が取得できない時間は、第１位置情報が取得できない状態になってから最大１時間の間、第２位置情報が代わりに用いられる。

同様に、回数を制限する場合には、例えば、第２位置情報を用いてイベントを進行させる１日における回数を制限する等である。なお、制限を行う単位は、「日（１日）」に限られず、時間、月、地理的な範囲、又は、距離等で制限してもよい。

移動量は、例えば、第２位置情報に基づいてキャラクタ１１を仮想空間内において移動させる距離等である。なお、移動量は、ユーザ２が現実空間で移動する量、すなわち、第２位置情報で計測された距離等でもよい。

イベントの進行度は、例えば、第２位置情報に基づいて進行させるイベントの数等である。具体的には、イベントをアイテムの取得とすれば、第２位置情報に基づいて取得できるアイテムの数等が制限される。ほかにも、例えば、イベントにおける重要場面（例えば、ボスキャラとの「戦闘」が開始、又は、終了する場面等である。）は、第２位置情報では進行させない等のように進行度を一時的に停止させる制限等でもよい。

このように、イベントは、キャラクタ１１の仮想空間内における移動、ゲーム内で生じるシナリオ、敵キャラクタ１３との「戦闘」、又は、これらの組み合わせ等であり、ゲーム内で生じる出来事であれば種類を問わない。

以上のように、第１位置情報の代わりに第２位置情報が使用される時間、回数、移動量、又は、イベントの進行度等が制限されてもよい。

第２位置情報は、第１位置情報より位置の精度が低い場合もある。したがって、第２位置情報を長く使用すると、ゲームにおいて不整合が生じる場合がある。例えば、速度、又は、位置等を計測する精度が低いデータに基づき、第２位置情報が生成される場合、ユーザ２が現実的には難しい速度で移動等という場合がある。このような位置情報が長く使用されると、ユーザ２が歩行不可能な位置に位置する等の不整合が生じる場合がある。そこで、第２位置情報の使用には制限がされるのが望ましい。

［通知例］
図７は、第２位置情報の使用の通知例を示す図である。第２位置情報を使用している状態は、ユーザ２に通知されるのが望ましい。以下、ゲーム画面１０上にメッセージ形式のＧｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ（ＧＵＩ）を出力して、第２位置情報を使用している状態を通知する例で説明する。ただし、通知は、メッセージ形式に限られない。例えば、通知は、振動、音、光、又は、ゲーム外の機能等による出力でもよい。

図７は、図３と比較すると、第１メッセージ１４、及び、第２メッセージ１５が表示されている点が異なる。以下、異なる点を中心に説明し、重複する説明を省略する。

第１メッセージ１４は、第１位置情報が取得できない状態であることを通知するＧＵＩである。

第２メッセージ１５は、第２位置情報を使用してゲームを進行させている状態であることを通知するＧＵＩである。

なお、通知は、第１位置情報、及び、第２位置情報の切り替えの際に出力されてもよい。例えば、第２位置情報に切り替えるか否かの切り替え操作用ＧＵＩ、又は、第２位置情報が複数種類可能である場合には、どの種類を第２位置情報として使用するか等がユーザ２に操作できてもよい。

具体的には、第２位置情報が複数種類取得できる場合（例えば、歩数情報と無線による特定情報の両方が可能等である。）、切り替えの際に、種類を選択するボタン等のＧＵＩが表示されてもよい。なお、第２位置情報の種類の選択は、事前に設定できてもよい。例えば、第２位置情報の種類がアカウントに対して関連付けされる。また、選択する第２位置情報の種類に対して、優先して使用する順（所謂「優先度」である。）が設定できてもよい。

以上のような通知がされると、ユーザ２に使用している位置情報の種類等を伝えることができる。

［第２位置情報によりイベントを進行させることの通知例］
第１位置情報が取得できない場合となり、第１位置情報に代えて第２位置情報を取得してイベントを進行させるように切り替える場合、第１情報処理端末３は、第１位置情報から第２位置情報に切り替えたことをユーザ２に通知するのが望ましい。

通知は、第２メッセージ１５のように視覚情報（例えば、ポップアップ、メール、又は、点滅等も含む。）以外の形式でもよい。具体的には、通知は、振動等の触覚情報でもよい。ほかにも、通知は、音声等の聴覚情報でもよい。このように、第１位置情報から第２位置情報への切り替えを知らせる通知があると、ユーザ２は、位置情報が切り替わったのを気づくことができる。

なお、第１位置情報から第２位置情報への切り替えは、ユーザ２に問い合わせをして、ユーザ２が許可した場合に切り替えが実行されてもよい。

例えば、第１情報処理端末３は、第１位置情報から第２位置情報への切り替えを知らせる通知と一緒に、第１位置情報から第２位置情報への切り替えを許可するか否かを操作するＧＵＩが表示する。例えば、ＧＵＩは、「許可ボタン」と「拒否ボタン」を表示する。

そして、ユーザ２が「許可ボタン」を押す、すなわち、第１位置情報から第２位置情報への切り替えを許可すると、第１情報処理端末３は、第１位置情報から第２位置情報への切り替えを行う。このように、第１位置情報から第２位置情報への切り替えを許可するか否かをユーザ２に操作させると、ユーザ２が意図しない位置情報が使用されるのを防ぐことができる。

なお、第１位置情報から第２位置情報への切り替え、又は、第２位置情報から第１位置情報への切り替えは、切り替えを禁止する時間帯があってもよい。第１位置情報から第２位置情報への切り替え、及び、第２位置情報から第１位置情報への切り替えが頻発すると、処理が複雑になりやすい。したがって、第１位置情報から第２位置情報への切り替えがされた後、第１位置情報が取得できるようになっても、しばらくの間は、直ぐに第２位置情報から第１位置情報への切り替えをせず、第２位置情報でイベントを進行させる状態が続いてもよい。

［第２位置情報による移動量と、第１位置情報による進行方向の組み合わせ例］
イベントの進行は、第１位置情報が取得できない場合、第２位置情報による移動量と、第１位置情報による進行方向の組み合わせで進行されてもよい。

例えば、第２位置情報の種類が歩数情報等の場合には、第２位置情報から移動量に換算が可能であっても、第２位置情報から進行方向が特定しづらい場合がある。

このような場合には、直近の第１位置情報（例えば、最後に取得できた位置情報を記憶しておく。）に基づいて進行方向を特定する。その後に第１位置情報が取得できない場合、進行方向は維持されているとする。一方で、移動量は、第２位置情報から換算する。このように、第２位置情報による移動量と、第１位置情報による進行方向の組み合わせでイベントを進行させてもよい。

ただし、第２位置情報によって進行方向が補正されてもよい。第２位置情報は、種類によって進行方向を示す情報を含む場合がある。以下、第１位置情報に基づいて特定される進行方向を「第１進行方向」という。一方で、第２位置情報に基づいて特定される進行方向を「第２進行方向」という。例えば、加速度センサ等を用いて第２位置情報を生成すると、第２位置情報は、第２進行方向を示すことができる。

具体的には、第１進行方向が「北」を示す例とする。一方で、第２進行方向が「東」を示すとする。このような場合には、第１進行方向が補正されて「北東」の進行方向となる。この例は、第１進行方向と第２進行方向の間に補正する例であるが、補正は、これに限られない。例えば、基準となる第１進行方向を高い重みにして、第１進行方向寄りに補正してもよい。この例では、「北北東」等のように補正した進行方向となる。

また、第１進行方向を最初は基準にし、時間経過に伴い徐々に第２進行方向の方へ進行方向を補正していってもよい。

［報酬の保留例］
図８は、報酬の例を示す図である。例えば、ユーザ２の移動が反映されて、キャラクタ１１が報酬ポイント３１を通過、又は、到達すると、ゲームにおける報酬が付与されるとする。なお、報酬ポイント３１は事前に設定される。

報酬は、例えば、キャラクタ１１が回復する等である。報酬ポイント３１が所謂「回復ポイント」である。なお、報酬はキャラクタ１１の回復に限られない。例えば、報酬は、何らかのアイテムが得られる、経験値等のポイント（ゲーム内で使用できる通貨等でもよい。）が得られる、キャラクタ１１のパラメータが向上する、キャラクタ１１のパラメータが一時的に向上する（所謂「バフ」がかかる状態をいう。）、又は、イベントが進行する（所謂「チェックポイント」である。）等でもよい。

図９は、報酬の保留例を示す図である。以下、図５の同様の時点で第１位置情報の取得状態が変化する例で説明する。また、図９において、報酬ポイント３１を通過する時点を「第３時点Ｔ３」とする。

第１位置情報が取得できない、すなわち、第１時点Ｔ１から第２時点Ｔ２までを「エラー」とする。そして、エラー状態中は、報酬の付与が保留とされるのが望ましい。なお、保留されるのは、報酬に限られず、第２位置情報に基づくキャラクタ１１の移動（移動量等である。）、又は、その他のイベントも保留されてもよい。

したがって、保留状態では、報酬による効果がエラー状態中は反映されない。例えば、第３時点Ｔ３で付与される報酬がキャラクタ１１の回復である場合には、保留状態では、キャラクタ１１は体力等が回復する前の状態である。

保留状態となった後、エラーが解除されると（図９における第２時点Ｔ２である。）、第１情報処理端末３は、保留状態である報酬を付与するか否かを判定条件に基づき追加して付与する。具体的には、第３時点Ｔ３で付与される報酬がキャラクタ１１の回復である場合には、判定条件を満たす場合には、キャラクタ１１は体力が第２時点Ｔ２で回復したと遡及して効果を付与する。

判定条件は事前に設定される。例えば、判定条件は、エラーの時間、第３時点Ｔ３におけるキャラクタ１１の強さ、第３時点Ｔ３で遭遇する敵キャラクタ１３の強さ、又は、ユーザ２の操作内容（タップの速さ等である。）を考慮する。

つまり、判定条件は、エラーでなければ、報酬が付与されたであろうとする現実性を判定する。したがって、第３時点Ｔ３におけるキャラクタ１１の強さでは勝てない敵キャラクタ１３と遭遇した場合では、判定条件に基づき、敵キャラクタ１３を倒した場合の報酬は付与されない。

以上のように、判定条件に基づいて報酬が付与されると、保留されている報酬のうち、現実的に取得可能な報酬が選別されて付与される。したがって、エラーを利用して不正に高い報酬を取得する等の行為を防ぐことができる。

上記のように付与される報酬は、上限値が設定されるのが望ましい。すなわち、保留状態の報酬が上限値以上の値である場合、かつ、報酬が判定結果により付与される場合、報酬は、上限値が付与される。このように、保留状態の報酬は、上限値以外の値が付与されないように制限されるのが望ましい。

特に保留状態の期間が長い場合、保留されていた報酬が一気に大量に付与されると、一気に状況が変化してしまう場合がある。このような状況になると、ユーザ２は、状況を把握できずに混乱する場合がある。したがって、上限値を設定して、キャラクタ１１のステータス等が余りに急激に変化するのを防げるのが望ましい。

また、報酬は、過去の報酬履歴を統計処理した統計結果に基づいて付与されるでもよい。例えば、報酬が経験値等の付与（以下付与される値を「付与値」という。）であるとする。まず、事前に、過去の報酬履歴には、過去に数か所の報酬ポイント３１（報酬ポイント３１の位置は異なる位置でもよい。）通過による付与値が記録される。なお、過去の報酬履歴は、ユーザ２に限られず、付近の他ユーザ、又は、同様のレベルの他ユーザの過去の報酬履歴を参照したデータでもよい。

次に、複数の付与値が統計処理される。例えば、統計処理は、平均値、中央値、又は、移動平均値等を計算する処理である。したがって、統計処理により、過去の報酬履歴に基づき、平均値等といった統計結果が計算される。なお、どのような統計処理を行うかは事前に設定される。

このような統計結果が得られると、過去に付与された実績のある付与値に近しい値が報酬として付与される。ゆえに、保留状態の報酬に基づき、過去に実績のないような大きな値が付与される等の例外的な報酬が付与されるといった事態が起きるのを防ぐことができる。

［バーチャルパットの例］
図１０は、バーチャルパットの例を示す図である。以下、図７と同様に、第１位置情報が取得できない状態である例で説明する。

第１位置情報が取得できない状態下において、第１情報処理端末３は、操作用のＧＵＩ（以下「バーチャルパット３２」の例とする。）を出力してもよい。なお、操作を入力するインタフェースは、バーチャルパット３２に限られない。例えば、インタフェースは、ゲームコントローラ等のハードウェア等もよい。又は、インタフェースは、音声認識による音声入力、手振り等のジェスチャ入力、視線検知による視線入力等でもよい。

バーチャルパット３２は、ユーザ２の操作を入力するＧＵＩである。例えば、バーチャルパット３２上にユーザ２の指が触れると、方向等が入力される。

このようにして、エラー中は、バーチャルパット３２等でユーザ２の進行方向、又は、移動量等が入力されてもよい。

バーチャルパット３２の形状、出力範囲、及び、出力タイミングは上記以外でもよい。すなわち、ＧＵＩは、他の種類でもよい。

なお、バーチャルパット３２による入力量、入力回数、又は、入力時間等は制限されるのが望ましい。例えば、制限なくバーチャルパット３２で移動量が入力できると、実際には数キロメートルの移動量が必要の内容を数メートルの移動量であってもバーチャルパット３２で数キロメートルの移動量と入力する不正等ができる場合がある。ゆえに、バーチャルパット３２による入力量、入力回数、又は、入力時間等を制限すると、不正な操作による影響を少なくできる。

［第２情報処理端末を用いる変形例］
図１１は、第２情報処理端末を用いる変形例を示す図である。図１１は、図１に示すシステム構成と比較すると、第２情報処理端末６が追加される構成である点が異なる。以下、異なる構成について説明する。

第２情報処理端末６は、例えば、時計型の情報処理装置である。すなわち、第２情報処理端末６は、ユーザ２が装着する形態であるのが望ましい。

第２情報処理端末６は、例えば、心拍計、又は、振動センサ等のセンサを備えるハードウェア構成である。なお、第２情報処理端末６は、第１情報処理端末３とは異なるセンサを備えるハードウェア構成、又は、異なる種類のデータを計測できる情報処理装置であるのが望ましい。ただし、第２情報処理端末６は、運動器具、又は、体重計等でもよい。すなわち、第２情報処理端末６は、ユーザ２の所有物に限られず、少なくとも一時的に接続が可能な情報処理装置でもよい。また、第２情報処理端末６は、複数の装置であってもよい。

第１情報処理端末３は、ネットワークを介して、又は、近距離通信等によって第２情報処理端末６と接続する。したがって、第１情報処理端末３は、第２情報処理端末６からユーザ２に関する情報（以下「外部情報」という。）を取得する。なお、外部情報は、サーバ４を介して取得されてもよい。

例えば、第２情報処理端末６がユーザ２の心拍数等を計測できる場合、心拍数等の生体情報に基づき、ユーザ２の状態（例えば、歩行している状態か、又は、走っている状態か等である。）が推定できる。

外部情報は、例えば、ユーザ２の移動速度、ユーザ２の歩数、又は、ユーザ２の移動状態等を示すセンサデータ等である。また、外部情報は、ユーザ２の移動速度、ユーザ２の歩数、又は、ユーザ２の移動状態等を直接計測した結果に限られず、センサデータに基づく推定結果でもよい。

このように、外部情報が取得できると、ユーザ２の位置、又は、状態等が精度良く推定できる。なお、外部情報は、そのまま第２位置情報となってもよいし、第２位置情報を生成する上で補助的な情報となってもよい。ゆえに、第２位置情報を生成する上で、外部情報を使用できると、第１情報処理端末３は、ユーザ２の位置等が精度良く特定できる。

以上の構成において、第１情報処理端末３のように、第１位置情報を取得する機器を「第１機器」とする。一方で、第２情報処理端末６のように、第２位置情報を取得し、かつ、第１情報処理端末３と連携する機器を「第２機器」とする。

第１機器、及び、第２機器は、情報処理装置でなくともよい。例えば、第１機器、及び、第２機器は、センサ等でもよい。また、第１機器、及び、第２機器は、第１位置情報、及び、第２位置情報の生成方法等により異なる。

そして、第１機器、及び、第２機器が演算装置等を有さないハードウェア構成であり、かつ、第１機器、及び、第２機器によるセンシング結果に基づき、第１機器、及び、第２機器に接続する情報処理装置が演算を行って第１位置情報、及び、第２位置情報を生成する構成等でもよい。

［機能構成例］
図１２は、機能構成例を示す図である。例えば、第１情報処理端末３は、第１位置情報取得部３Ｆ１、第２位置情報取得部３Ｆ２、切り替え部３Ｆ３、及び、イベント進行部３Ｆ４等を備える機能構成である。

第１位置情報取得部３Ｆ１は、第１位置情報を取得する第１位置情報取得手順を行う。例えば、第１位置情報取得部３Ｆ１は、通信装置３Ｈ５等で実現する。

第２位置情報取得部３Ｆ２は、第２位置情報を取得する第２位置情報取得手順を行う。例えば、第２位置情報取得部３Ｆ２は、センサ３Ｈ３等で実現する。

切り替え部３Ｆ３は、第１位置情報が取得できない場合、イベント進行部３Ｆ４が使用する位置情報を第１位置情報から第２位置情報に切り替える切り替え手順を行う。例えば、切り替え部３Ｆ３は、ＣＰＵ３Ｈ１等で実現する。

イベント進行部３Ｆ４は、第１位置情報、又は、第２位置情報に基づき、イベントを進行させるイベント進行手順を行う。例えば、イベント進行部３Ｆ４は、ＣＰＵ３Ｈ１等で実現する。

以上のような構成であると、ＧＰＳが遮断される等によって第１位置情報が取得できない場合でも、第２位置情報を代わりにしてイベントを進行させることができる。例えば、位置情報を利用するゲームにおいて、第１位置情報が取得できない状態下では、移動量が反映されない、アイテムの取得が反映されない、又は、ゲームにおけるストーリの展開に不整合が生じるといった位置情報取得の状態による不具合が生じる場合がある。

一方で、第２位置情報を代用してイベントが進行できると、位置情報取得の状態による不具合が生じるのを防ぐことができる。

［その他の実施形態］
イベントは、ゲームにおける場合に限られない。例えば、イベントは、スマートフォンにおける飲食店用のアプリケーションソフト等における処理でもよい。例えば、アプリケーションソフトがユーザ２の位置を認証して、クーポンを付与する等のイベントを実行する場合に本発明が適用されてもよい。

仮想空間は、ゲームに限られない。例えば、仮想空間は、メタバース等でもよい。メタバースとは、「メタ（ｍｅｔａ、超越）」と「ユニバース（ｕｎｉｖｅｒｓｅ、宇宙、世界）」を組み合わせた言葉である。そして、メタバースは、多人数が参加可能であって、参加者がその中で自由に行動できるコンピュータネットワーク上の３次元仮想空間等をいう。したがって、ユーザ２が操作可能なキャラクタは、メタバース空間におけるアバター等でもよい。

前述の処理、及び、本実施形態で実行される処理に用いるデータは、情報処理システムによって実行、及び、記憶されてもよい。例えば、情報処理システムは、処理又は記憶を冗長、分散、並列、又は、これらの組み合わせを実現するため、複数の情報処理装置で実行又は記憶してもよい。したがって、本発明は、前述に示すハードウェア構成以外の装置、及び、前述に示す装置以外のシステムで実現されてもよい。

また、本発明に係るプログラムは、単一のプログラムに限定されず、複数のプログラムの集合体でもよい。本発明に係るプログラムは、単一の装置で実行されるものに限定されず、複数の情報処理装置で分担して実行されてもよい。更に、各情報処理装置の役割分担は、前述の例に限定されない。すなわち、前述した情報処理方法の一部、又は、全部が前述した情報処理装置とは異なる情報処理装置が実行してもよい。

更に、プログラムによって実現される各部の一部、又は、全部は、集積回路等のハードウェアで実現することもできる。更に、プログラムは、コンピュータによって読み出し可能な非一過性の記録媒体に記録されて提供されてもよい。記録媒体とは、例えば、ハードディスク、ＳＤカード（登録商標）、ＤＶＤ等の光学ディスク、又は、インターネット上のサーバ等を指す。したがって、プログラムは、インターネット等の電気通信回線を介して配信されでもよい。

また、情報処理システムを構成する情報処理装置等は、海外にあってもよい。

なお、本発明は、前述に例示する各実施形態に限定されない。したがって、本発明は、技術的な要旨を逸脱しない範囲で、構成要素の追加、一部削除、各実施形態の組み合わせ、又は、変形が可能である。ゆえに、特許請求の範囲に記載された技術思想に含まれる技術的事項のすべてが本発明の対象となる。なお、前述に例示する実施形態は、実施において好適な具体例である。そして、当業者であれば、開示した内容から様々な変形例を実現可能であって、このような変形例は、特許請求の範囲に記載された技術的範囲に含まれる。

［付記］ 本発明は、以下の発明を含む。

＜１＞
コンピュータに、
ユーザが利用するアカウントに関連付けられた第１位置情報によりイベントを進行させ、
前記第１位置情報が取得できない場合、前記第１位置情報とは異なる第２位置情報を入力する操作を受け付け、
前記第２位置情報により、前記イベントを進行させる
プログラム。

＜２＞
前記第１位置情報が取得できなくなった後、前記第１位置情報の取得が再開された場合、
前記第１位置情報により、前記イベントを進行させる
＜１＞に記載のプログラム。

＜３＞
前記第２位置情報によって前記イベントを進行させる場合、
前記イベントの進行度、時間、回数、又は、移動量の制限がある
＜１＞に記載のプログラム。

＜４＞
前記第１位置情報が取得できていない間に取得した報酬を保留状態とし、
前記第１位置情報が再度取得可能になった場合、前記保留状態の前記報酬を付与するか否かを判定条件に基づき判定し、
前記判定条件を満たす場合、前記保留状態の前記報酬が追加して付与される
＜１＞に記載のプログラム。

＜５＞
前記保留状態の前記報酬を追加して付与する場合、
前記報酬の上限値が設定される
＜４＞に記載のプログラム。

＜６＞
前記第２位置情報によって前記イベントを進行させる場合、
前記第２位置情報により前記イベントを進行させることを通知する
＜１＞に記載のプログラム。

＜７＞
ユーザが操作する第１情報処理端末を有するシステムであって、
前記第１情報処理端末は、
前記ユーザが利用するアカウントに関連付けられた第１位置情報によりイベントを進行させ、
前記第１位置情報が取得できない場合、前記第１位置情報とは異なる第２位置情報を入力する操作を受け付け、
前記第２位置情報により、前記イベントを進行させる
システム。

＜８＞
ユーザが操作するコンピュータが実行する情報処理方法であって、
前記ユーザが利用するアカウントに関連付けられた第１位置情報によりイベントを進行させる手順と、
前記第１位置情報が取得できない場合、前記第１位置情報とは異なる第２位置情報を入力する操作を受け付ける手順と、
前記第２位置情報により、前記イベントを進行させる手順と
を含む情報処理方法。

上記＜１＞乃至＜８＞の発明は、例えば、図１０等に示す記載に基づく発明である。

＜９＞
コンピュータに、
ユーザが利用するアカウントに関連付けられた第１位置情報によりイベントを進行させ、
前記第１位置情報が取得できない場合、前記第１位置情報とは異なる第２位置情報により、前記イベントを進行させる
プログラム。

＜１０＞
前記第１位置情報を取得した履歴がある場合、
前記第２位置情報により、前記イベントを進行させる
＜９＞に記載のプログラム。

＜１１＞
前記第１位置情報が取得できなくなった後、前記第１位置情報の取得が再開された場合、
前記第１位置情報により、前記イベントを進行させる
＜９＞に記載のプログラム。

＜１２＞
前記第２位置情報によって前記イベントを進行させる場合、
前記イベントの進行度、時間、回数、又は、移動量の制限がある
＜９＞に記載のプログラム。

＜１３＞
前記第１位置情報が取得できていない間に取得した報酬を保留状態とし、
前記第１位置情報が再度取得可能になった場合、前記保留状態の前記報酬を付与するか否かを判定条件に基づき判定し、
前記判定条件を満たす場合、前記保留状態の前記報酬が追加して付与される
＜９＞に記載のプログラム。

＜１４＞
前記保留状態の前記報酬を追加して付与する場合、
前記報酬の上限値が設定される
＜１３＞に記載のプログラム。

＜１５＞
前記保留状態の前記報酬を追加して付与する場合、
前記報酬は、
過去の報酬履歴を統計処理した統計結果に基づき付与される
＜１３＞に記載のプログラム。

＜１６＞
前記第２位置情報により、前記イベントを進行させる場合、
前記ユーザに対し、前記第２位置情報により前記イベントを進行させる状態であることを通知する
＜９＞に記載のプログラム。

＜１７＞
前記第２位置情報は、
カメラによる位置判定結果、前記第１位置情報とは異なる衛星で取得する位置情報、歩数計による計測結果、加速度センサによる計測結果、地磁気の計測結果、気圧センサによる計測結果、無線による特定結果のうち少なくとも１つ以上である
＜９＞に記載のプログラム。

＜１８＞
前記第２位置情報は、
移動履歴情報に基づく推定結果である
＜９＞に記載のプログラム。

＜１９＞
前記第２位置情報は、
前記第１位置情報を取得する第１機器に連携する第２機器から取得する情報である
＜９＞に記載のプログラム。

＜２０＞
前記第２位置情報によって前記イベントを進行させる場合、
前記第２位置情報により前記イベントを進行させることを通知する
＜９＞に記載のプログラム。

＜２１＞
前記第２位置情報が複数種類取得できる場合であって、
前記第１位置情報が取得できない場合、
前記第２位置情報として使用する種類の選択を受け付けさせる
＜９＞に記載のプログラム。

＜２２＞
前記第１位置情報が取得できない場合、
前記第２位置情報による移動量と、前記第１位置情報による進行方向に基づき、前記イベントを進行させる
＜９＞に記載のプログラム。

＜２３＞
前記第１位置情報が取得できない場合、
前記第２位置情報による移動量と、
前記第１位置情報による第１進行方向を基準にして前記第２位置情報による第２進行方向で補正した進行方向に基づき、前記イベントを進行させる
＜９＞に記載のプログラム。

＜２４＞
ユーザが操作する第１情報処理端末を有するシステムであって、
前記第１情報処理端末は、
前記ユーザが利用するアカウントに関連付けられた第１位置情報によりイベントを進行させ、
前記第１位置情報が取得できない場合、前記第１位置情報とは異なる第２位置情報により、前記イベントを進行させる
システム。

＜２５＞
ユーザが操作するコンピュータが実行する情報処理方法であって、
前記ユーザが利用するアカウントに関連付けられた第１位置情報によりイベントを進行させる手順と、
前記第１位置情報が取得できない場合、前記第１位置情報とは異なる第２位置情報により、前記イベントを進行させる手順と
を含む情報処理方法。

１ ：システム
２ ：ユーザ
３ ：第１情報処理端末
３Ｆ１ ：第１位置情報取得部
３Ｆ２ ：第２位置情報取得部
３Ｆ３ ：切り替え部
３Ｆ４ ：イベント進行部
４ ：サーバ
５ ：衛星
６ ：第２情報処理端末
１０ ：ゲーム画面
１１ ：キャラクタ
１２ ：アイテム
１３ ：敵キャラクタ
１４ ：第１メッセージ
１５ ：第２メッセージ
２０ ：過去ルート
２１ ：第１ルート
２２ ：第２ルート
２３ ：第３ルート
３１ ：報酬ポイント
３２ ：バーチャルパット
Ｐ１ ：第１地点
Ｐ２ ：第２地点
Ｔ１ ：第１時点
Ｔ２ ：第２時点
Ｔ３ ：第３時点

Claims (2)

1. コンピュータに、
   ユーザの現実空間の位置情報を利用するゲームにおいて、
   ユーザが利用するアカウントに関連付けられた現在の現実空間のユーザの位置情報によりイベントを進行させ、
   前記現在の現実空間のユーザの位置情報が取得できない場合、操作用のＧＵＩを出力し、前記操作用のＧＵＩで前記ユーザが入力する情報により、前記イベントを進行させ、
   切り替えがあってから、所定の時間の間、前記現在の現実空間のユーザの位置情報によるイベントの進行、又は、前記操作用のＧＵＩによるイベントの進行の切り替えを制限する、
   プログラム。
2. ユーザの現実空間の位置情報を利用するゲームにおいて、前記ユーザが操作する情報処理端末を有するシステムであって、
   前記情報処理端末は、
   前記ユーザが利用するアカウントに関連付けられた現在の現実空間のユーザの位置情報によりイベントを進行させ、
   前記現在の現実空間のユーザの位置情報が取得できない場合、操作用のＧＵＩを出力し、前記操作用のＧＵＩで前記ユーザが入力する情報により、前記イベントを進行させ、
   切り替えがあってから、所定の時間の間、前記現在の現実空間のユーザの位置情報によるイベントの進行、又は、前記操作用のＧＵＩによるイベントの進行の切り替えを制限する、
   システム。