JP6712781B2 - 情報処理方法 - Google Patents

Description

本開示は、ビーコン装置の不正利用を抑制するための情報処理方法に関する。

特許文献１には、機器装置が所定位置とは異なる位置に位置していることが検出されると、機器装置が盗難状態にあると判定する盗難防止システムが開示されている。

特許文献２には、盗難防止対象物の移動を検知する盗難防止装置が開示されている。

特許文献３には、中継装置を利用する通信装置の数に応じて中継装置の盗難被疑の検知を行う通信監視装置が開示されている。

特開２００６−２７９８５４号公報 特開平１０−２２６３１５号公報 特開２０１３−２４７４１７号公報

ところで、店舗などの建物には、スマートフォンなどの携帯端末に情報を送信するビーコン装置が設置される場合がある。このような場合、設置されたビーコン装置が盗難されるなどして不正に利用されることは望ましくない。

本開示は、ビーコン装置の不正利用を抑制するための情報処理方法を提供する。

本開示の一態様に係る情報処理方法は、サーバ装置が実行する情報処理方法であって、第一ビーコン装置からビーコン信号を受信した第一携帯端末から、当該第一携帯端末の現在位置を示す第一位置情報を取得する取得ステップと、取得された前記第一位置情報と、前記サーバ装置によって予め管理されている第二位置情報であって前記第一ビーコン装置の設置位置を示す前記第二位置情報とを比較することにより、前記第一ビーコン装置の異常度を算出する算出ステップと、算出された前記異常度に応じた処理を行う処理ステップとを含む。

なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよい。また、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本開示の一態様に係る情報処理方法によれば、ビーコン装置の異常度に応じて、ビーコン装置の不正利用を抑制するための処理を行うことができる。

図１は、実施の形態１に係るゲーム報酬付与システムの概略構成を示す図である。 図２は、実施の形態１に係るゲーム報酬付与システムの機能構成を示すブロック図である。 図３は、店舗情報ＤＢに記憶される情報を示す図である。 図４は、ゲームアプリ情報ＤＢに記憶される情報を示す図である。 図５は、ユーザ情報ＤＢに記憶される情報を示す図である。 図６は、初期化処理のシーケンス図である。 図７は、モバイル端末の表示部に表示される表示画面の一例を示す図である。 図８は、初期化処理におけるゲーム部の動作のフローチャートである。 図９は、初期化処理におけるＳＤＫ部の動作のフローチャートである。 図１０は、部品要求、ログイン要求、およびログイン要求に対する応答のＨＴＭＬ文書の一例を示す図である。 図１１は、部品要求に対する応答のＨＴＭＬ文書の一例を示す図である。 図１２は、初期化処理におけるサーバの動作のフローチャートである。 図１３は、ユーザ情報ＤＢ内のユーザログイン情報およびユーザ達成度情報を示す図である。 図１４は、店舗コラボ情報の取得方法のフローチャートである。 図１５は、店舗コラボ情報要求および店舗コラボ情報の一例を示す図である。 図１６は、サーバ情報ＤＢ内のサーバ情報の一例を示す図である。 図１７は、スタンプシート画面の一例を示す図である。 図１８は、店舗コラボ情報の生成方法のフローチャートである。 図１９は、店舗情報ＤＢ内の店舗属性情報の一例を示す図である。 図２０は、ゲームアプリ情報ＤＢ内のスタンプ情報の一例を示す図である。 図２１Ａは、店舗情報ＤＢから一定数の店舗属性情報を取得する処理のフローチャート（前半）である。 図２１Ｂは、店舗情報ＤＢから一定数の店舗属性情報を取得する処理のフローチャート（後半）である。 図２２は、ユーザチェックインログおよびゲーム属性情報の一例を示す図である。 図２３は、ＳＱＬで近隣５００ｍの店舗属性情報を検索する場合の記述を示す図である。 図２４は、ゲーム画面描画・表示処理のフローチャートである。 図２５は、店舗コラボ画像の生成処理のフローチャートである。 図２６は、店舗コラボ画像の一例を示す図である。 図２７は、ゲーム処理および報酬付与処理のシーケンス図である。 図２８は、ゲーム上で商品を販売するときのゲーム画面を示す図である。 図２９は、スタンプシート画面にスタンプが押される様子を示す図である。 図３０は、ゲーム処理および報酬付与処理のフローチャートである。 図３１は、達成度送信処理のフローチャートである。 図３２は、報酬付与判定要求および報酬付与情報の一例を示す図である。 図３３は、報酬付与判定処理のフローチャートである。 図３４は、報酬付与条件情報の一例を示す図である。 図３５は、ユーザ達成度ログおよびユーザ報酬付与情報の一例を示す図である。 図３６は、報酬画面表示処理のフローチャートである。 図３７は、報酬画面情報要求の一例を示す図である。 図３８は、スタンプシート画面を表示する場合の報酬画面情報の一例を示す図である。 図３９は、アイテム付与画面を表示する場合の報酬画面情報の一例を示す図である。 図４０は、報酬画面情報の生成方法のフローチャートである。 図４１は、報酬一覧情報の一例を示す図である。 図４２は、報酬付与処理のフローチャートである。 図４３は、報酬情報要求および報酬情報の一例を示す図である。 図４４は、報酬情報生成処理のフローチャートである。 図４５は、チェックインに基づく報酬付与のシーケンス図である。 図４６は、来店予備行動感知処理のフローチャートである。 図４７は、近隣店舗判定要求および近隣店舗情報の一例を示す図である。 図４８は、近隣店舗判定処理のフローチャートである。 図４９は、来店情報取得処理のフローチャートである。 図５０は、チェックイン要求および報酬付与情報の一例を示す図である。 図５１は、チェックインに用いられる２次元コードの一例を示す図である。 図５２は、チェックイン処理（購買処理）のフローチャートである。 図５３は、報酬出現確率情報の一例を示す図である。 図５４は、広告情報の一例を示す図である。 図５５は、購入者特典情報の一例を示す図である。 図５６は、バナーイメージを追加した報酬画面情報の一例を示す図である。 図５７は、購入者特典付与処理に用いられる２次元コードが印刷されたチケットの一例を示す図である。 図５８は、購入者特典付与処理のフローチャートである。 図５９は、購入者特典報酬情報の一例を示す図である。 図６０は、実施の形態２に係るゲーム報酬付与システムの機能構成を示す図である。 図６１は、実施の形態２に係るゲーム報酬付与システムの詳細な機能構成を示すブロック図である。 図６２は、サーバ記憶部に記憶される情報を示す図である。 図６３は、ビーコンＩＤ情報の一例を示す図である。 図６４は、チェックイン履歴の一例を示す図である。 図６５Ａは、実施の形態２に係るゲーム報酬付与システムの動作の第一のシーケンス図である。 図６５Ｂは、実施の形態２に係るゲーム報酬付与システムの動作の第二のシーケンス図である。 図６６は、異常発生時のチェックイン履歴の一例を示す図である。 図６７は、ビーコン制御部の異常度に応じた処理の決定方法のフローチャートである。 図６８は、報酬付与認証処理のシーケンス図である。 図６９は、他のビーコン装置を用いた報酬付与認証処理のシーケンス図である。 図７０は、報酬付与をペンディングする処理のシーケンス図である。 図７１は、メッセージ１が表示されたモバイル端末の模式図である。 図７２は、ビーコン装置の機能を一時停止する処理のシーケンス図である。 図７３は、メッセージ２が表示されたモバイル端末の模式図である。 図７４は、ビーコン装置の機能を完全に停止する処理のシーケンス図である。 図７５は、メッセージ３が表示されたモバイル端末の模式図である。

本開示の一態様に係る情報処理方法は、サーバ装置が実行する情報処理方法であって、第一ビーコン装置からビーコン信号を受信した第一携帯端末から、当該第一携帯端末の現在位置を示す第一位置情報を取得する取得ステップと、取得された前記第一位置情報と、前記サーバ装置によって予め管理されている第二位置情報であって前記第一ビーコン装置の設置位置を示す前記第二位置情報とを比較することにより、前記第一ビーコン装置の異常度を算出する算出ステップと、算出された前記異常度に応じた処理を行う処理ステップとを含む。

このような情報処理方法によれば、ビーコン装置の設置位置のずれに基づいてビーコン装置の異常度を算出することができる。また、このような情報処理方法によれば、算出した異常度に応じてビーコン装置の不正利用を抑制するための処理を行うことができる。

また、前記算出ステップにおいては、前記第一位置情報が示す現在位置と、前記第二位置情報が示す設置位置との差が大きいほど、前記異常度を高く算出してもよい。

このように、上記情報処理方法では、具体的には、ビーコン装置の設置位置のずれが大きいほど、異常度が高く算出されてもよい。

また、前記情報処理方法は、さらに、複数の第二携帯端末のそれぞれが前記第一ビーコン装置から受信したビーコン信号に含まれる第一ＩＤの受信日時を第一チェックイン履歴として管理する第一管理ステップを含み、前記算出ステップにおいては、前記第一チェックイン履歴をさらに用いて前記異常度を算出してもよい。

このような情報処理方法によれば、例えば、携帯端末の現在位置情報の改ざんが行われた場合であっても、異常度を精度よく算出することができる。

例えば、前記算出ステップにおいては、前記第一位置情報の取得をしたときの前記第一チェックイン履歴と、前記第一位置情報の取得をしたときよりも前の前記第一チェックイン履歴とを比較することにより、前記異常度を算出してもよい。

このような情報処理方法によれば、現在と過去のチェックイン履歴の比較に基づいて異常度を算出することができる。

また、前記第一管理ステップにおいては、前記複数の第二携帯端末のそれぞれから送信される前記第一ＩＤの受信日時を、当該第一ＩＤを送信した前記第二携帯端末から送信されるユーザＩＤと対応付けて前記第一チェックイン履歴として管理し、前記算出ステップにおいては、前記第一チェックイン履歴に含まれる同一のユーザＩＤの数に応じて前記異常度を算出してもよい。

このような情報処理方法によれば、ビーコン装置を利用するユーザ数の偏りに基づいて異常度を算出することができる。

また、前記情報処理方法は、さらに、複数の第三携帯端末のそれぞれが前記第一ビーコン装置とは異なる第二ビーコン装置から受信したビーコン信号に含まれる第二ＩＤの受信日時を第二チェックイン履歴として管理する第二管理ステップを含み、前記算出ステップにおいては、前記第一チェックイン履歴と、前記第二チェックイン履歴とを比較することにより、前記異常度を算出してもよい。

このような情報処理方法によれば、一のビーコン装置の利用状況と他のビーコン装置の利用状況との比較に基づいて異常度を算出することができる。

また、前記処理ステップにおいては、算出された前記異常度が所定値以上の場合に、前記第一ビーコン装置とは異なる第三ビーコン装置からのビーコン信号の取得を前記第一携帯端末に指示する前記処理を行ってもよい。

このような情報処理方法によれば、一のビーコン装置で異常が疑われる場合に、他のビーコン装置を利用して異常の有無を判断できる。

また、前記処理ステップにおいては、算出された前記異常度が所定値よりも低い場合、前記第一携帯端末に関する所定の処理を行い、算出された前記異常度が所定値以上の場合、前記所定の処理を保留してもよい。

このような情報処理方法によれば、異常度に応じて所定の処理を保留することができる。

また、前記第一携帯端末には、前記サーバ装置によってデータが管理されるゲームのアプリケーションがインストールされ、前記所定の処理は、前記ゲーム内で使用されるゲーム報酬を前記データ上で付与する処理であってもよい。

このように、上記情報処理方法は、例えば、ビーコン装置との通信に基づくゲーム報酬の付与に利用できる。

また、前記処理ステップにおいては、算出された前記異常度が所定値以上の場合、前記第一ビーコン装置の機能を停止させるための情報を、前記第一携帯端末を介して前記第一ビーコン装置に送信する前記処理を行ってもよい。

このような情報処理方法によれば、異常度が高い場合にビーコン装置を停止させることができる。

また、前記第一ビーコン装置の機能を停止させるための情報は、前記第一ビーコン装置が保持する鍵情報によって復号可能な、暗号化された情報であってもよい。

このような情報処理方法によれば、ビーコン装置とサーバ装置との通信をこれらの装置以外の装置が傍受することを抑制できる。

また、前記第一ビーコン装置の機能を停止させるための情報は、前記第一ビーコン装置が保持する前記鍵情報を削除するための情報を含んでもよい。

このような情報処理方法によれば、異常度が高い場合にビーコン装置を完全に停止させ、鍵情報を削除して安全性を高めることができる。

また、前記第二位置情報は、前記サーバ装置が備える記憶部に記憶されていてもよい。

また、前記取得ステップ、前記算出ステップおよび前記処理ステップの少なくとも１つは、前記サーバ装置が備えるプロセッサにより行われてもよい。

なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよい。また、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

以下、実施の形態について、図面を参照しながら具体的に説明する。

なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

なお、各図は模式図であり、必ずしも厳密に図示されたものではない。また、各図において、実質的に同一の構成に対しては同一の符号を付しており、重複する説明は省略または簡略化される場合がある。

（実施の形態１）
［実施の形態１に係る情報提供方法の基礎となった知見］
実施の形態１では、ゲーム用アプリケーションを搭載した情報機器に対する情報提供方法について説明する。

ユーザ（プレーヤ）は、例えばスマートフォンのような情報機器を用いてゲーム用アプリケーションをダウンロードすることできる。ダウンロードされるゲームの中には、ゲームの進行レベルに応じてゲーム報償（ゲームアイテム）が得られるタイプのものがある。

例えば、ユーザがゲーム上で商品を販売し、その売り上げが最初の目標額に達するとスタンプが付与されるルールのゲームがある。このようなゲームでは、ユーザの売り上げが次の目標額に達すると次のスタンプがさらに付与される。ユーザが所定数（例えば５個）のスタンプを取得すると、ユーザはゲームを進める上で有効なゲームアイテムを獲得できる。

また、例えば、ユーザがゲームをプレイできる時間に制限を設け、一定時間を経過しなければ、同一のゲームを再開できない仕組みを有するゲームがある。この場合、有効なゲームアイテムは、上記の一定時間を短縮する機能を有する。このため、ユーザは、有効なゲームアイテムを使用することにより、上記一定時間の経過を待たずに、ゲームと同一のゲームを再開できる。

本願発明者は、この種のゲーム用アプリケーションと、例えば、薬局、雑貨店、または衣料販売店などの店舗とを連携させ、ゲーム用アプリケーションにおけるスタンプ又はゲームアイテムの取得を、店舗での販売促進に結びつける方法を見出した。

そこで、実施の形態１では、ゲームを利用してゲームのプレーヤに現実の店舗への来店の動機を与えることができる情報提供方法（ゲーム報酬付与システム）について説明する。

［構成］
以下、実施の形態１に係るゲーム報酬付与システムについて説明する。図１は、ゲーム報酬付与システムの概略構成を示す図である。

図１に示されるように、ゲーム報酬付与システム１００は、サーバ１０と、モバイル端末２０とを備える。サーバ１０とモバイル端末２０とはネットワーク４０（例えば、インターネット）を通じて接続されている。また、図１には、モバイル端末２０によって実行されるゲームのコラボレーションの対象となる店舗３０も図示されている。

なお、ゲーム報酬付与システム１００においては、ユーザは、モバイル端末２０を用いてサーバ１０からゲーム用アプリケーション（以下、単に「ゲームアプリ」とも記載する。）をダウンロードする。ユーザのゲームの進行状況などの情報は、サーバ１０に記憶される。

また、実施の形態１では、モバイル端末２０で実行されるゲームは、ユーザがゲーム上で商品を販売し、その売り上げが最初の目標額に達するとスタンプが付与されるルールのゲームであるものとする。このゲームでは、ユーザの売り上げが次の目標額に達すると次のスタンプがさらに付与される。ユーザが所定数（例えば５個）のスタンプを取得すると、ユーザはゲームを進める上で有効なゲームアイテムを獲得できる。

ゲーム報酬付与システム１００においては、上記スタンプがゲームの進行によって付与されるだけでなく、ユーザがモバイル端末２０を現実の店舗３０に持参することによっても付与される点が特徴である。

次に、ゲーム報酬付与システム１００の具体的な構成について説明する。図２は、ゲーム報酬付与システム１００の機能構成を示すブロック図である。まず、サーバ１０について説明する。

図２に示されるように、サーバ１０は、サーバ制御部１１と、店舗情報ＤＢ１３と、ゲームアプリ情報ＤＢ１４と、ユーザ情報ＤＢ１５とを備える。

サーバ制御部１１は、モバイル端末２０からの各要求を受信し、要求に応じて各ＤＢ（店舗情報ＤＢ１３、ゲームアプリ情報ＤＢ１４、およびユーザ情報ＤＢ１５）を参照し、必要な場合は各ＤＢ情報の更新を行う。また、サーバ制御部１１は、上記要求に応じてゲームに必要な情報（画面情報など）をモバイル端末２０に送信する。

サーバ制御部１１は、具体的には、プロセッサであるが、マイクロコンピュータや専用回路など、どのような態様であってもよい。

次に、モバイル端末２０について説明する。モバイル端末２０は、制御部２１と、記憶部２２と、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）２６とを備える。また、記憶部２２には、ゲームアプリが記憶されており、ゲームアプリには、ゲーム部２３と、ＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）部２４と、サーバ情報ＤＢ２５とが含まれる。モバイル端末２０は、具体的には、スマートフォン、タブレット端末、またはノートＰＣなどの表示部を有する端末である。なお、図２では表示部の図示が省略されている。

制御部２１は、ＯＳ２６を立ち上げて記憶部２２に記憶されたゲームアプリを実行する。制御部２１は、プロセッサであるが、マイクロコンピュータや専用回路など、どのような態様であってもよい。なお、以下の実施の形態では、制御部２１がゲームアプリを実行することによって行われる処理は、単に「ゲーム部２３は・・する」または「ＳＤＫ部２４は・・する」と記載される。

次に、上記各ＤＢに記憶される情報について簡単に説明する。図３は、店舗情報ＤＢ１３に記憶される情報を示す図である。図４は、ゲームアプリ情報ＤＢ１４に記憶される情報を示す図である。図５は、ユーザ情報ＤＢ１５に記憶される情報を示す図である。

図３に示されるように、店舗情報ＤＢ１３には、店舗属性情報１３１と、広告情報１３２と、購入者特典情報１３３とが記憶される。

また、図４に示されるように、ゲームアプリ情報ＤＢ１４には、スタンプ情報１４１と、ゲーム属性情報１４２と、報酬付与条件情報１４３と、報酬一覧情報１４４と、報酬出現確率情報１４５と、購入者特典報酬情報１４６とが記憶される。

さらに、図５に示されるように、ユーザ情報ＤＢ１５には、ユーザログイン情報１５１と、ユーザ達成度情報１５２と、ユーザチェックインログ１５３と、ユーザ達成度ログ１５４と、ユーザ報酬付与情報１５５とが記憶される。

［初期化処理］
次に、モバイル端末２０においてゲームアプリを実行する場合の初期化処理について説明する。まず、初期化処理の全体の流れについて説明する。図６は、初期化処理のシーケンス図である。

ゲーム初期化処理（Ｓ１０）においては、ゲーム部２３は、ＳＤＫ部２４にログイン要求を送信し（Ｓ１１）、ＳＤＫ部２４は、ログイン要求処理を行う（Ｓ１２）。ＳＤＫ部２４は、具体的には、サーバ制御部１１へログイン要求を送信する（Ｓ１３）。

サーバ制御部１１は、受信したログイン要求に応じてログイン処理（Ｓ１４）を行い、ログイン処理の完了後、ユーザＩＤをＳＤＫ部２４に送信する（Ｓ１５）。ＳＤＫ部２４は、ログイン完了通知をゲーム部２３に送信する（Ｓ１６）。

ログインが完了すると、ゲーム部２３は、店舗コラボ情報取得要求をＳＤＫ部２４に送信し（Ｓ１７）、ＳＤＫ部２４は、店舗コラボ情報取得処理を行う（Ｓ１８）。ＳＤＫ部２４は、具体的には、サーバ制御部１１へ店舗コラボ情報生成要求を送信する（Ｓ１９）。

サーバ制御部１１は、受信した店舗コラボ情報生成要求に応じて店舗コラボ情報生成処理を行い（Ｓ２０）、生成した店舗コラボ情報をＳＤＫ部２４に送信する（Ｓ２１）。そして、ＳＤＫ部２４は、店舗コラボ情報取得完了通知をゲーム部２３に送信する（Ｓ２２）。

以上により、ゲーム初期化処理（Ｓ１０）が完了する。続いて、ゲーム部２３は、ゲーム画面描画・表示処理（Ｓ２３）を行う。具体的には、ゲーム部２３は、店舗コラボ画像描画・表示要求をＳＤＫ部２４に送信し（Ｓ２４）、ＳＤＫ部２４は、店舗コラボ画像描画・表示処理を行う（Ｓ２５）。店舗コラボ画像描画・表示処理の完了後、ＳＤＫ部２４は、店舗コラボ画像描画・表示完了通知をゲーム部２３に送信する。

なお、ログイン処理時には、モバイル端末２０の表示部には、図７の（ａ）のようなログイン画面２７ａが表示される。また、ゲーム画面描画・表示処理完了時には、図７の（ｂ）のようなゲーム画面２７ｂが表示される。なお、ゲーム画面２７ｂには、ゲーム固有画像２８ａと店舗コラボ画像２８ｂとが含まれる。

次に、初期化処理におけるゲーム部２３、ＳＤＫ部２４およびサーバ１０（サーバ制御部１１）の動作の詳細について説明する。まず、初期化処理におけるゲーム部２３の動作について説明する。図８は、初期化処理におけるゲーム部２３の動作のフローチャートである。

図８に示されるように、ゲーム部２３は、ゲーム初期化処理（Ｓ３１）を行った後、ＳＤＫ部２４にログイン要求を送信し（Ｓ３２）、ＳＤＫ部２４に店舗コラボ情報取得要求を送信する（Ｓ３３）。ゲーム部２３が店舗コラボ情報の取得に成功した場合（Ｓ３４でＹｅｓ）、店舗コラボフラグがＯＮされる（Ｓ３５）。ゲーム部２３が店舗コラボ情報の取得に失敗した場合（Ｓ３４でＮｏ）、リトライ（Ｓ３６でＹｅｓ）が行われた後、店舗コラボフラグがＯＦＦされる（Ｓ３７）。なお、リトライは、例えば、所定回数行われる。

なお、これ以降のゲーム部２３からＳＤＫ部２４への各種処理要求（例えば、図６の店舗コラボ画像描画・表示要求）は、店舗コラボフラグがＯＮの場合のみ行われる。

続いて、初期化処理におけるＳＤＫ部の動作について説明する。図９は、初期化処理におけるＳＤＫ部２４の動作のフローチャートである。

まず、ＳＤＫ部２４は、アプリユーザＩＤが生成済みであるか否かを判断する（Ｓ４１）。アプリユーザＩＤが生成済みでない場合は（Ｓ４１でＮｏ）、ＳＤＫ部２４は、ＯＳ２６からＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）を取得し、取得したＵＵＩＤをアプリユーザＩＤとする（Ｓ４２）。

次に、ＳＤＫ部２４は、ＷｅｂＶｉｅｗを作成し、アプリユーザＩＤとアプリＩＤとを引数とする、ログインページ表示の部品要求をサーバ１０に送信する（Ｓ４３）。なお、ＷｅｂＶｉｅｗは、モバイル端末２０のアプリ（ここでは、ゲームアプリ）がアプリ内にＷｅｂページを表示するための機能（仕組み）である。

そして、ＳＤＫ部２４は、サーバ１０からログインページ表示の部品を受信し、ＷｅｂＶｉｅｗ上にログイン画面２７ａを表示する（Ｓ４４）。ここで、ユーザは、モバイル端末２０を通じてユーザ名およびパスワードの入力を行う。つまり、ＳＤＫ部２４は、ユーザが入力するユーザ名およびパスワードを取得する。

続いて、ＳＤＫ部２４は、ユーザが入力したユーザ名およびパスワード、アプリユーザＩＤ並びにアプリＩＤを引数とするログイン要求をサーバ１０へ送信する（Ｓ４５）。サーバ１０からの応答がない場合（Ｓ４６でＮｏ）、ログイン要求の再送信が行われる。サーバ１０からの応答が得られれば（Ｓ４６でＹｅｓ）、処理は終了となる。

次に、部品要求、ログイン要求、およびこれらの応答の具体例について説明する。図１０および図１１は、部品要求、ログイン要求、およびこれらの応答のＨＴＭＬ文書の一例を示す図である。

図１０の（ａ）に示されるように、部品要求２９は、アプリユーザＩＤ２９ａ、アプリＩＤ２９ｂ、およびアクション２９ｃを含む。

また、図１０の（ｂ）に示されるように、ログイン要求３１は、アプリユーザＩＤ３１ａ、アプリＩＤ３１ｂ、アクション３１ｃ、ユーザ名３１ｄ、およびパスワード３１ｅを含む。

ログイン要求３１に対し、サーバ１０は、図１０の（ｃ）に示される応答３２ｂ（エラーなしを示す応答）を送信する（ステップＳ４６でＹｅｓ）。なお、ログイン要求３１で指定したユーザ名とパスワードとの組み合わせではログインができないような場合には、図１０の（ｄ）に示される応答３２ｃが送信される（ステップＳ４６でＮｏとなり、ステップＳ４５の処理が再度行われる）。

なお、ログイン画面を表示する場合には、部品要求２９に対して図１１に示される応答３２ａのように、ｈｔｍｌおよびｊａｖａｓｃｒｉｐｔ（登録商標）の形式の応答が送信される。つまり、ＷｅｂＶｉｅｗ表示用の「部品」は、ｈｔｍｌおよびｊａｖａｓｃｒｉｐｔ（登録商標）形式で送信される。応答３２ａでは、前半部分（図１１の上方の枠で囲まれた部分）は、モバイル端末２０において送信ボタンが押された場合のログイン要求送信処理およびリトライ処理が記述されている。応答３２ａでは、後半部分（図１１の下方の枠で囲まれた部分）は、ログイン画面２７ａをモバイル端末２０の表示部に表示するための部品が記述されている。

続いて、サーバ１０（サーバ制御部１１）の動作について説明する。図１２は、初期化処理におけるサーバ１０の動作のフローチャートである。図１３は、ユーザ情報ＤＢ１５内のユーザログイン情報１５１およびユーザ達成度情報１５２を示す図である。なお、図１３の（ａ）に示されるように、ユーザログイン情報１５１においては、ユーザＩＤ１５１ａとユーザ名およびパスワードとが対応付けられている。図１３の（ｂ）に示されるように、ユーザ達成度情報１５２に含まれる各ユーザ達成度情報１５２ｆにおいては、ユーザＩＤ１５２ａと、アプリユーザＩＤ、アプリＩＤ、ゲームのスコア、レベル１５２ｄ、スタンプシート１５２ｂ、およびスタンプ数１５２ｃとが対応付けられている。

サーバ制御部１１は、モバイル端末２０から送信された部品要求２９またはログイン要求３１からアプリユーザＩＤ２９ａ（３１ａ）、アプリＩＤ２９ｂ（３１ｂ）、およびアクション２９ｃ（３１ｃ）を取得する（Ｓ５１）。アクションが「ｌｏｇｉｎ」を示す場合、つまり、モバイル端末２０からログイン要求３１が送信された場合（Ｓ５２でＹｅｓ）、サーバ制御部１１は、ログイン要求からユーザ名３１ｄおよびパスワード３１ｅを取得する（Ｓ５３）。そして、サーバ制御部１１は、ユーザログイン情報１５１を検索してユーザＩＤ１５１ａを取得する（Ｓ５４）。

サーバ制御部１１は、ユーザＩＤ１５１ａの取得に成功した場合（Ｓ５５でＹｅｓ）、かつユーザＩＤ１５１ａ、アプリユーザＩＤ３１ａ、およびアプリＩＤ３１ｂの組み合わせがユーザ達成度情報１５２に存在しない場合は、ユーザＩＤ１５１ａ、アプリユーザＩＤ３１ａ、およびアプリＩＤ３１ｂの組み合わせをユーザ達成度情報１５２に登録する（Ｓ５６）。なお、ユーザＩＤ、アプリユーザＩＤ、及びアプリＩＤ以外の値については、デフォルト値（例えば、スコアー＝０、レベル＝１、スタンプシート＝１、スタンプ数＝０）とする。そして、サーバ制御部１１は、ユーザ達成度情報１５２の登録の有無に関わらずモバイル端末２０にログイン成功を示す応答３２ｂを送信する（Ｓ５８）。

また、サーバ制御部１１は、ユーザＩＤの取得に失敗した場合（Ｓ５５でＮｏ）、モバイル端末２０にログイン失敗を示す応答３２ｃを送信する（Ｓ５７）。

一方、ステップＳ５２でアクションが「Ｖｉｅｗ」を示す場合、つまり、モバイル端末２０から部品要求２９が送信された場合（Ｓ５２でＮｏ）、サーバ制御部１１は、アプリユーザＩＤ２９ａおよびアプリＩＤ２９ｂに基づいて応答３２ａを生成し、モバイル端末２０に送信する（Ｓ５９）。

［店舗コラボ情報の生成処理］
次に、ゲーム画面の描画・表示処理のうち店舗コラボ情報の生成処理について説明する。まず、ＳＤＫ部２４の店舗コラボ情報の取得方法について説明する。図１４は、店舗コラボ情報の取得方法のフローチャートである。図１５は、店舗コラボ情報要求（図１５の（ａ））および店舗コラボ情報（図１５の（ｂ））の一例を示す図である。図１６は、サーバ情報ＤＢ２５内のサーバ情報の一例を示す図である。図１７は、スタンプシート画面の一例を示す図である。

ＳＤＫ部２４は、アプリユーザＩＤ３３ａおよびアプリＩＤ３３ｂを引数とする店舗コラボ情報要求を送信する（Ｓ６１）。そして、ＳＤＫ部２４は、店舗コラボ情報３４をサーバ制御部１１から受信し、サーバ情報ＤＢ２５内にサーバ情報３５として格納する（Ｓ６２）。そして、ＳＤＫ部２４は、ゲーム部２３に店舗コラボ情報３４の取得完了通知を行う（Ｓ６３）。

なお、店舗コラボ情報３４は、店舗コラボ画像を生成するための情報であり、店舗コラボ情報３４には、応答３４ａと、スタンプ数３４ｂと、メッセージ３４ｃとが含まれ、サーバ情報３５についてもこれらの情報が含まれる。

応答３４ａは、サーバ制御部１１にて店舗コラボ情報３４の生成に成功したか否か（エラーが発生しないかどうか）を示す情報である。店舗コラボ情報３４の生成に成功した場合は、”ＮＯＮＥ”、サーバ制御部１１とのネットワーク接続に失敗した場合は、”ｃｏｎｎｅｃｔｉｏｎ＿ｅｒｒｏｒ”、アプリＩＤがサーバに登録されていない場合は、”ｂａｄ＿ａｐｐ＿ｉｄ”と記述される。

スタンプ数３４ｂは、アプリＩＤによって特定されるゲームにて、アプリユーザＩＤによって特定（識別）されるアプリユーザのスタンプの進捗を示す情報である。実施の形態１では、獲得スタンプ数／ゴールスタンプ数のように表現される。なお、ゴールスタンプ数とは、スタンプシートをいっぱいにするために必要なスタンプ数であり、実施の形態１では「５」である。したがって、図１７に示されるスタンプシート画面２７ｃのようにスタンプが１つも押されていない場合は０／５のように表現される。

メッセージ３４ｃは、サーバ制御部１１が生成した、店舗３０への来店を喚起するためのメッセージである。

次に、サーバ１０（サーバ制御部１１）の店舗コラボ情報３４の生成処理について説明する。図１８は、店舗コラボ情報３４の生成方法のフローチャートである。図１９は、店舗情報ＤＢ１３内の店舗属性情報の一例を示す図である。図２０は、ゲームアプリ情報ＤＢ１４内のスタンプ情報１４１の一例を示す図である。

サーバ制御部１１は、制御部２１（ＳＤＫ部２４）から受信した店舗コラボ情報要求３３からアプリユーザＩＤ３３ａおよびアプリＩＤ３３ｂを取り出す（Ｓ７１）。そして、サーバ制御部１１は、取り出したアプリユーザＩＤ３３ａおよびアプリＩＤ３３ｂに基づいて、ユーザ情報ＤＢ１５から対応するユーザ達成度情報１５２ｆを取得する（Ｓ７２）。

続いて、サーバ制御部１１は、店舗情報ＤＢ１３から一定数の店舗属性情報１３１（図１９）を取得し（Ｓ７３）、これらより、ランダムに１つを選択する（Ｓ７４）。なお、ステップＳ７３の処理の詳細については後述する。

そして、サーバ制御部１１は、ゲームアプリ情報ＤＢ１４内のスタンプ情報１４１からアプリＩＤ３３ｂに対応するアプリのスタンプシート枚数のゴールスタンプ数を取得する（Ｓ７５）。ここで、スタンプシート枚数は、ユーザ達成度情報１５２ｆに含まれるスタンプシート１５２ｂにより特定され、ここでは「２」である。また、図２０のスタンプ情報１４１ａに示されるように、このときのゴールスタンプ数は、「５」である。

最後に、サーバ制御部１１は、ユーザ達成度情報１５２ｆに含まれるスタンプ数１５２ｃより特定される獲得スタンプ数と、上記ゴールスタンプ数と、上記ステップＳ７４にて選択した店舗属性情報に含まれるメッセージ（例えばステップＳ７４で選択された店舗属性情報が１３１ｄの場合は、メッセージ３６ｆ）とが含まれる店舗コラボ情報３４を生成し、モバイル端末２０に送信する（Ｓ７６）。

次に、店舗情報ＤＢ１３から一定数の店舗属性情報１３１を取得する処理（上記ステップＳ７３の処理）の一例について説明する。図２１Ａおよび図２１Ｂは、店舗情報ＤＢ１３から一定数の店舗属性情報１３１を取得する処理のフローチャートである。図２２は、ユーザチェックインログ１５３（図２２の（ａ））およびゲーム属性情報１４２（図２２の（ｂ））の一例を示す図である。

なお、以下の説明では、サーバ制御部１１が、チェックインリストＣＬ、店舗リストＳＬ１およびＳＬ２、並びにスコアＳＣを用いて一定数の店舗属性情報１３１を取り出す例について説明する。

サーバ制御部１１は、ユーザ情報ＤＢ１５内のユーザチェックインログ１５３から一定期間のチェックイン情報（チェックインの履歴。例えば、一定期間＝１ヶ月、現在時刻が２０１４年２月７日１２：００である場合、時刻が２０１４年１月７日１２：００〜２０１４年２月７日１２：００迄である、図２２の（ａ）のチェックイン情報１５３ａおよび１５３ｂ。）を取得し、チェックインリストＣＬに追加する（Ｓ８１）。そして、サーバ制御部１１は、店舗リストＳＬを空にし（Ｓ８２）、チェックインリストＣＬが空であるか否かを判定する（Ｓ８３）。

チェックインリストＣＬが空でない場合（Ｓ８３でＮｏ）、サーバ制御部１１は、チェックインリストＣＬからチェックイン情報を１つ取り出す（Ｓ８４）。また、サーバ制御部１１は、店舗属性情報１３１を参照して、取り出したチェックイン情報の店舗ＩＤと一致する店舗ＩＤを有する店舗属性情報１３１を取得し、店舗リストＳＬに追加する（Ｓ８５）。例えば、図２２の（ａ）のチェックイン情報１５３ａが取り出された場合、店舗ＩＤ１５３ｃは、ｓｔｒ００００５であり、図１９の店舗属性情報１３１のうち店舗属性情報１３１ｅが取得される。

さらに、サーバ制御部１１は、店舗属性情報１３１を参照して、チェックイン情報の店舗ＩＤ１５３ｃが示す店舗の近隣の店舗の店舗属性情報１３１を取得し、店舗リストＳＬに追加する（Ｓ８６）。なお、近隣の店舗の有無の判定は、店舗属性情報に含まれる緯度、及び経度を利用して、店舗間の距離を算出することによって行われる。具体的には、店舗間の距離が一定値以下（例えば、５００ｍ以内）であれば、近隣の店舗であると判定される。ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）で近隣５００ｍの店舗属性情報１３１を検索する場合、図２３のように記述される。例えば、店舗属性情報１３１ｅ（緯度３４．７２１０１、経度１３５．３１２２）から５００ｍ以内の緯度・経度情報をもつ店舗属性情報は、店舗属性情報１３１ｂ及び１３１ｄである。この場合、店舗リストＳＬには、店舗属性情報１３１ｂ及び１３１ｄが追加される。

ステップＳ８４からステップＳ８６の処理は、チェックインリストＣＬが空になるまで（Ｓ８３でＹｅｓ）行われる。

次に、サーバ制御部１１は、ゲームアプリ情報ＤＢ１４のゲーム属性情報１４２から、店舗コラボ情報要求３３に含まれるアプリＩＤ３３ｂとアプリＩＤが一致するゲーム属性情報（ここでは、ゲーム属性情報１４２ａ）を取得する（Ｓ８７）。

店舗リストＳＬが空でない場合（Ｓ８８でＮｏ）、サーバ制御部１１は、スコアＳＣ＝０として店舗リストＳＬから店舗属性情報１３１を１つ取り出す（Ｓ８９）。取り出した店舗属性情報１３１（以下、対象の店舗属性情報１３１とも記載する。）のジャンル傾向が、ゲーム属性情報１４２ａのジャンル１４２ｂと同一の場合、サーバ制御部１１は、対象の店舗属性情報１３１のスコアＳＣに所定値（店舗属性情報１３１のジャンル傾向にて括弧内に記載される数値、例えば、店舗属性情報１３１ｄの場合は、０．５）を加える（Ｓ９０）。

また、対象の店舗属性情報１３１のアプリ傾向が、店舗コラボ情報要求３３に含まれるアプリＩＤ３３ｂと同一の場合は、サーバ制御部１１は、対象の店舗属性情報１３１のスコアＳＣに所定値（店舗属性情報１３１のアプリ傾向にて括弧内に記載される数値、例えば、店舗属性情報１３１ａの場合は、０．２）を加える（Ｓ９１）。

また、対象の店舗属性情報１３１の開発者傾向が、ゲーム属性情報１４２ａの開発者１４２ｃと同一の場合は、サーバ制御部１１は、対象の店舗属性情報１３１のスコアＳＣに所定値（店舗属性情報１３１の開発者傾向にて括弧内に記載される数値、例えば店舗属性情報１３１ｂの場合は、０．３）を加える（Ｓ９２）。

最後に、サーバ制御部１１は、対象の店舗属性情報１３１にステップＳ９０〜ステップＳ９２で算出したスコアＳＣを含めて店舗リストＳＬ２に追加し、店舗リストＳＬ２内の店舗属性情報１３１をスコアＳＣが高い順番に並べ替える（Ｓ９３）。

ステップＳ８９からステップＳ９３の処理は、店舗リストＳＬが空になるまで（Ｓ８８でＹｅｓ）、店舗リストＳＬ内の各店舗属性情報１３１に対して行われる。

以上のような処理により、店舗リストＳＬ２の上位一定数の店舗属性情報１３１、つまり、過去一定期間にプレーヤが来店した近隣の店舗であって、プレーヤが現在プレイするゲームアプリに関連性の高い店舗が一定数取り出される（Ｓ９４）。

［ゲーム画面描画・表示処理］
以上説明したような店舗コラボ情報３４を用いたゲーム画面描画・表示処理について説明する。図２４は、ゲーム画面描画・表示処理のフローチャートである。図２５は、店舗コラボ画像２８ｂの生成処理のフローチャートである。図２６は、店舗コラボ画像２８ｂの一例を示す図である。

図２４に示されるように、ゲーム部２３は、まず、ゲーム固有画像２８ａの描画・表示を行う（Ｓ１０１）。店舗コラボフラグがＯＮである場合（Ｓ１０２でＹｅｓ）、ゲーム部２３は、ＳＤＫ部２４に店舗コラボ画像２８ｂの描画・表示要求を送信する（Ｓ１０３）。

図２５に示されるように、店舗コラボ画像２８ｂの描画・表示要求を受信したＳＤＫ部２４は、まず、店舗コラボ画像２８ｂ（図２６）の背景部分を描画する（Ｓ１１１）。続いて、ＳＤＫ部２４は、店舗コラボ情報３４からスタンプ数３４ｂ（獲得スタンプ数およびゴールスタンプ数）を取得し（Ｓ１１２）、店舗コラボ画像２８ｂのうちスタンプ数表示部２８ｃを描画する（Ｓ１１３）。

さらに、ＳＤＫ部２４は、店舗コラボ情報３４からメッセージ３４ｃを取得し（Ｓ１１４）、店舗コラボ画像２８ｂのうちメッセージ表示部２８ｄを描画する（Ｓ１１５）。なお、メッセージ表示部２８ｄにおいては、メッセージ３４ｃは、スクロール表示される。

［ゲーム処理および報酬付与処理］
次に、ゲーム処理および報酬付与処理について説明する。図２７は、ゲーム処理および報酬付与処理のシーケンス図である。

ゲーム処理Ｓ１２１において、ゲーム部２３は、達成度送信要求をＳＤＫ部に送信する（Ｓ１２２）。達成度送信要求を受信したＳＤＫ部２４は、達成度送信処理を行う（Ｓ１２３）。ＳＤＫ部２４は、具体的には、サーバ制御部１１に報酬付与判定要求を送信する（Ｓ１２４）。なお、報酬付与判定要求には、達成度が含まれる。

サーバ制御部１１は、送信された報酬付与判定要求に基づいて報酬付与判定処理を行い（Ｓ１２５）、報酬付与が不要であると判定した場合には、報酬付与無しの応答（報酬付与情報）をＳＤＫ部２４に送信する（Ｓ１２６）。そして、ＳＤＫ部２４は、報酬付与無しの応答（報酬付与情報）をゲーム部２３に送信する（Ｓ１２７）。

報酬付与がなされる場合も同様に、ゲーム部２３は、達成度送信要求をＳＤＫ部に送信し（Ｓ１２８）、ＳＤＫ部２４は、達成度送信処理を行う（Ｓ１２９、Ｓ１３０）。サーバ制御部１１は、送信された報酬付与判定要求に基づいて報酬付与判定処理を行い（Ｓ１３１）、報酬付与が必要であると判定した場合には、報酬付与有りの応答（報酬付与情報）をＳＤＫ部２４に送信する（Ｓ１３２）。そして、ＳＤＫ部２４は、報酬付与有りの応答をゲーム部２３に送信する（Ｓ１３３）。

報酬付与有りの応答を受信したゲーム部２３は、報酬画面表示要求をＳＤＫ部２４に送信する（Ｓ１３４）。報酬画面表示要求を受信したＳＤＫ部２４は、報酬画面表示処理を行う（Ｓ１３５）。具体的には、ＳＤＫ部２４は、報酬画面情報要求をサーバ制御部１１に送信する（Ｓ１３６）。報酬画面情報要求を受信したサーバ制御部１１は、報酬画面情報を生成し（Ｓ１３７）、生成した報酬画面情報をＳＤＫ部２４に送信する（Ｓ１３８）。ＳＤＫ部２４は、受信した報酬画面情報を利用して、モバイル端末２０の表示部に報酬獲得の旨の表示を行う。

報酬画面情報を表示した後、ＳＤＫ部２４は、報酬付与処理を行う（Ｓ１３９）。ＳＤＫ部２４は、具体的には、報酬情報要求をサーバ制御部１１に送信する（Ｓ１４０）。報酬情報要求を受信したサーバ制御部１１は、報酬情報を生成し（Ｓ１４１）、生成した報酬情報をＳＤＫ部２４に送信する（Ｓ１４２）。

ＳＤＫ部２４は、受信した報酬情報をゲーム部２３に送信し（Ｓ１４３）、ゲーム部２３は、報酬処理を行う（Ｓ１４４）。

上述のように、実施の形態１に係るゲームにおいては、ユーザがゲーム上で商品を販売し、その売り上げが所定の金額に達するとスタンプが付与される。図２８は、ゲーム上で商品を販売するときのゲーム画面２７ｂを示す図である。

図２８の（ａ）に示されるように、ゲーム画面の左上には、売り上げが示されている。ここで、図２８の（ｂ）に示されるように、売り上げが「１９０Ｇ」（Ｇは、ゲーム内での通貨単位）の状態でゲーム上の商品の販売がなされると、図２８の（ｃ）に示されるように、売り上げが増える。ここでは、「８０Ｇ」が追加され、売り上げは「２７０Ｇ」に増える。このような、売り上げの増加は、「達成度」として上記達成度送信要求に含められ、ゲーム部２３からＳＤＫ部２４に送信される。また、この達成度は、上記報酬付与判定要求にも含められ、ＳＤＫ部２４からサーバ制御部１１に送信される。

ここで、上記達成度に応じて行われるスタンプの付与、つまり、上述のスタンプシート画面２７ｃにおいてスタンプを追加する処理は、上記報酬付与判定処理に含まれる（なお、スタンプシートを表示する処理は、上記報酬画面表示処理に含まれる。）。図２９は、スタンプシート画面２７ｃにスタンプが押される様子を示す図である。

図２９の（ａ）〜（ｅ）に示されるように、報酬付与判定処理においては、ゲームで一定の達成をする毎にひとつずつスタンプが報酬として与えられ、報酬画面情報生成処理によって、スタンプシート画面２７ｃにスタンプがひとつずつ押されていく画面が生成される。スタンプは、サーバ１０で管理される報酬情報であり、ゲーム部２３は獲得スタンプ数、ゴールスタンプ数を意識する必要はない。獲得スタンプ数がゴールスタンプ数（ここでは５つ）に達した場合、図２９の（ｆ）に示されるように、ユーザに対してゲーム内で貴重なアイテムが付与される。

ここでユーザに付与されるアイテムは、スタンプと異なり、ゲーム部２３が付与処理を行う必要のある情報である。アイテム付与に関する表示は、報酬画面情報生成処理によって行われるが、付与アイテムをゲームへ反映させる処理は、ＳＤＫ部２４より送信される報酬情報を受け取ったゲーム部２３が、報酬処理にて行う。

次に、ゲーム処理および報酬処理についてフローチャートを用いて詳細に説明する。図３０は、ゲーム処理および報酬処理のフローチャートである。

ゲーム部２３は、ＳＤＫ部２４から報酬情報を受信している場合、つまり報酬情報がある場合（Ｓ１５１でＹｅｓ）、報酬情報にしたがってゲーム制御用の変数・ＤＢを更新する（Ｓ１５８）。

報酬情報がない場合（Ｓ１５１でＮｏ）、または、ステップＳ１５８の処理の後には、ゲーム固有ロジック処理が行われる（Ｓ１５２）。そして、ゲーム部２３は、ＳＤＫ部２４に達成度送信要求を送信する（Ｓ１５３）。

ここで、ゲーム部２３は、報酬付与有りの応答を受信した場合（Ｓ１５４でＹｅｓ）には、ＳＤＫ部２４に報酬画面表示要求を送信し、報酬画面表示終了を待つ（Ｓ１５７）。

ゲーム部２３が報酬付与無しの応答を受信した場合（Ｓ１５４でＮｏ）、又は報酬画面表示が終了した後、ゲーム部２３は、ゲーム固有画描画・表示処理を行い（Ｓ１５５）、ＳＤＫ部２４は、店舗コラボ画像描画・表示処理を行う（Ｓ１５６）。そして、再度、報酬情報の有無の判断（Ｓ１５１）が行われる。

次に、ＳＤＫ部２４の達成度送信処理についてフローチャートを用いて詳細に説明する。図３１は、達成度送信処理のフローチャートである。図３２は、報酬付与判定要求（図３２の（ａ））および報酬付与情報（図３２の（ｂ））の一例を示す図である。

図３１に示されるように、ＳＤＫ部２４は、アプリユーザＩＤ３８ａ、アプリＩＤ３８ｂ、および達成度３８ｃを引数とする報酬付与判定要求３８をサーバ１０（サーバ制御部１１）に送信する（Ｓ１６１）。そして、ＳＤＫ部２４は、サーバ１０から報酬付与情報３９を受信する（Ｓ１６２）。報酬付与情報には、エラーの有無を示す応答３９ａと、報酬付与の有無を示す応答３９ｂとが含まれる。

報酬付与情報が報酬付与有りを示す応答３９ｂを含む場合（Ｓ１６３でＹｅｓ）、ＳＤＫ部２４は、ゲーム部２３に報酬付与有りの応答を送信する（Ｓ１６４）。一方、報酬付与情報が報酬付与無しを示す応答３９ｂを含む場合（Ｓ１６３でＮｏ）、ＳＤＫ部２４は、ゲーム部２３に報酬付与無しの応答を送信する（Ｓ１６５）。

次に、サーバ制御部１１の報酬付与判定処理についてフローチャートを用いて詳細に説明する。図３３は、報酬付与判定処理のフローチャートである。図３４は、報酬付与条件情報１４３の一例を示す図である。図３５は、ユーザ達成度ログ１５４（図３５の（ａ）および（ｂ））およびユーザ報酬付与情報１５５（図３５の（ｃ））の一例を示す図である。

サーバ制御部１１は、ＳＤＫ部２４から受信した報酬付与判定要求３８からアプリユーザＩＤ３８ａ、アプリＩＤ３８ｂ、および達成度３８ｃを取得する（Ｓ１７１）。サーバ制御部１１は、ユーザ情報ＤＢ１５内のユーザ達成度情報を参照して、アプリユーザＩＤ３８ａおよびアプリＩＤ３８ｂの組合せに対応するユーザ達成度情報１５２ｆを取得する（Ｓ１７２）。

そして、サーバ制御部１１は、アプリユーザＩＤ３８ａ、アプリＩＤ３８ｂ、および達成度３８ｃに現在時刻を付与したユーザ達成度ログ情報１５４ａを生成し、ユーザ達成度ログ１５４に追加する（Ｓ１７３）。また、サーバ制御部１１は、報酬付与条件情報１４３を参照してアプリＩＤ３８ｂおよびユーザのレベルに対応する報酬付与条件情報１４３ａを取得する（Ｓ１７４）。なお、図３４に示されるように、報酬付与条件情報１４３ａには報酬ＩＤ１４３ｂが含まれる。

ユーザ達成度ログ１５４を集計した結果が報酬付与条件情報１４３ａを満たす場合（Ｓ１７５でＹｅｓ）、サーバ制御部１１は、ユーザ報酬付与情報１５５を生成する（Ｓ１７７）。図３５の（ｃ）に示されるように、具体的なユーザ報酬付与情報１５５ａは、アプリユーザＩＤ３８ａ、アプリＩＤ３８ｂ、報酬ＩＤ１４３ｂ、ギフトＩＤ、画面表示済みフラグ、および報酬付与済みフラグを含む。なお、ギフトＩＤは、任意のユニークな数値であり（例えば１より単純増加する整数であり、他のユーザ報酬付与情報と重複しない）、画面表示済みフラグおよび報酬付与済みフラグは、いずれもこの時点では「ＦＡＬＳＥ」に設定される。

そして、サーバ制御部１１は、報酬付与有りを示す応答３９ｂを含む報酬付与情報３９をＳＤＫ部２４に送信する（Ｓ１７８）。

ステップＳ１７５においてユーザ達成度ログ１５４を集計した結果が報酬付与条件情報１４３ａを満たさない場合（Ｓ１７５でＮｏ）、サーバ制御部１１は、報酬付与無しを示す応答３９ｂを含む報酬付与情報３９をＳＤＫ部２４に送信する（Ｓ１７６）。

次に、報酬画面表示処理についてフローチャートを用いて詳細に説明する。図３６は、報酬画面表示処理のフローチャートである。図３７は、報酬画面情報要求の一例を示す図である。図３８は、スタンプシート画面２７ｃを表示する場合の報酬画面情報の一例を示す図である。図３９は、アイテム付与画面を表示する場合の報酬画面情報の一例を示す図である。

ＳＤＫ部２４は、ＷｅｂＶｉｅｗを作成し、アプリユーザＩＤ４１ａおよびアプリＩＤ４１ｂを引数とする報酬画面情報要求４１を、サーバ１０（サーバ制御部１１）に送信する（Ｓ１８１）。

次に、ＳＤＫ部２４は、サーバ制御部１１から報酬画面情報４２ａ（または報酬画面情報４２ｂ）を受信し、ＷｅｂＶｉｅｗ上に報酬画面としてスタンプシート画面２７ｃ（またはアイテム付与画面２７ｄ）を表示する（Ｓ１８２）。

例えば、スタンプシート画面２７ｃにスタンプが４つ押された状態から５つ目のスタンプを押すような表示を行う場合、報酬画面情報４２ａは、図３８の太線枠のように記述される。また、例えば、アイテムの画像と、名称と、個数とを指定してアイテム付与画面２７ｄを表示する場合、報酬画面情報４２ｂは、図３９のように記述される。すなわち、ＪａｖａＳｃｒｉｐｔ（登録商標）にて記述された画面表示処理ｓｈｏｗＳｃｒｅｅｎ（）が、引数に応じてスタンプ付与画面や、報酬画面の表示を動的に行う。なお、ｓｈｏｗＳｃｒｅｅｎ（）の処理詳細については、記載しない。

なお、報酬画面情報４２ａ（または報酬画面情報４２ｂ）にゲーム側報酬付与情報４２ｄが含まれる場合（Ｓ１８３でＹｅｓ）、報酬付与処理が行われる（Ｓ１８４）。ゲーム側報酬付与情報４２ｄとは、具体的には、報酬画面情報４２ｂの１４行目の「ｌｏｃａｔｉｏｎ．ｈｒｅｆ＝”ａｐｐｃｍｄ：ｇｉｆｔ＝”＋ＧＩＦＴ＿ＩＤ」のことである。これは、ＪａｖａＳｃｒｉｐｔ（登録商標）で記述された処理から、ＳＤＫ部２４の報酬付与処理を呼び出すための一般的な方法である。

ｌｏｃａｔｉｏｎ．ｈｒｅｆ＝ＵＲＬは、ＷｅｂＶｉｅｗにて表示しているＷＥＢページをＵＲＬへ切り替えるために利用されるが、ＷｅｂＶｉｅｗは、切り替え可否をＷｅｂＶｉｅｗの生成元であるＳＤＫ部２４に問い合わせる。ＳＤＫ部２４は、ＵＲＬとａｐｐｃｍｄ：が前方一致する場合、ＵＲＬ切り替えとは判断せず、ＪａｖａＳｃｒｉｐｔ（登録商標）からＳＤＫ部２４への処理要求と判断する。報酬画面情報４２ｂの場合は、「ｇｉｆｔ＝１」を引数として報酬付与処理が行われる。

なお、報酬画面情報４２ｂの１４行目の処理は、関数ｓｃｒｅｅｎ＿ｓｈｏｗ＿ｃｏｍｐｌｅｔｅｄ（）内部の処理である。この関数ｓｃｒｅｅｎ＿ｓｈｏｗ＿ｃｏｍｐｌｅｔｅｄ（）は、前記のｓｈｏｗＳｃｒｅｅｎ（）の引数として指定され、ｓｈｏｗＳｃｒｅｅｎ（）は、報酬画面の表示後、ｓｃｒｅｅｎ＿ｓｈｏｗ＿ｃｏｍｐｌｅｔｅｄ（）を呼び出す。

次に、報酬画面情報の生成方法についてフローチャートを用いて説明する。図４０は、報酬画面情報の生成方法のフローチャートである。図４１は、報酬一覧情報１４４の一例を示す図である。

サーバ制御部１１は、報酬画面情報要求４１からアプリユーザＩＤ４１ａおよびアプリＩＤ４１ｂを取得する（Ｓ１９１）。次に、サーバ制御部１１は、取得したアプリユーザＩＤ４１ａおよびアプリＩＤ４１ｂに対応するユーザ報酬付与情報１５５ａをユーザ報酬付与情報１５５から取得する（Ｓ１９２）。なお、このときの検索条件には、画面表示済みフラグが「ＦＡＬＳＥ」であるという条件、すなわち、未だ表示されていないユーザ報酬付与情報１５５ａのみに限定するという条件が含まれる。

続いて、サーバ制御部１１は、アプリＩＤ４１ｂおよび取得したユーザ報酬付与情報１５５に対応する報酬一覧情報１４４ａを報酬一覧情報１４４から取得する（Ｓ１９３）。

報酬一覧情報１４４ａの報酬種別がスタンプである場合（Ｓ１９４でＹｅｓ）、サーバ制御部１１は、報酬画面情報４２ａを生成する（Ｓ１９５）。サーバ制御部１１は、具体的には、ユーザ達成度情報１５２ｆに含まれるスタンプシート１５２ｂおよびスタンプ数１５２ｃ、及び当該スタンプ数に報酬一覧情報１４４ａの「報酬個数」を加算した報酬付与後スタンプ数（加算した結果、ゴールスタンプ数を超える場合は、ゴールスタンプ数とする）とを用いて報酬画面情報４２ａを生成する。

報酬一覧情報１４４ａの報酬種別がアイテムである場合（Ｓ１９４でＮｏ）、サーバ制御部１１は、ユーザ報酬付与情報１５５ａに含まれるギフトＩＤと、報酬一覧情報１４４ａに含まれる報酬イメージおよび報酬名とを用いて報酬画面情報４２ｂを生成する（Ｓ１９６）。

最後に、サーバ制御部１１は、ユーザ報酬付与情報１５５の画面表示済みフラグを「ＴＲＵＥ（ＯＮ）」とし、報酬画面情報４２ａ（または報酬画面情報４２ｂ）をＳＤＫ部２４に送信する（Ｓ１９７）。なお、サーバ制御部１１は、報酬画面情報４２ａ（または報酬画面情報４２ｂ）をＳＤＫ部２４に送信してからユーザ報酬付与情報１５５の画面表示済みフラグを「ＴＲＵＥ」としてもよい。

次に、報酬付与処理（図３６のＳ１８４）についてフローチャートを用いて詳細に説明する。図４２は、報酬付与処理のフローチャートである。図４３は、報酬情報要求（図４３の（ａ））および報酬情報（図４３の（ｂ））の一例を示す図である。

ＳＤＫ部２４は、サーバ制御部１１から送信された報酬画面情報４２ａ（または報酬画面情報４２ｂ）からギフトＩＤを取得する（Ｓ２０１）。そして、アプリユーザＩＤ４３ａ、アプリＩＤ４３ｂ、およびギフトＩＤ４３ｃを引数とする報酬情報要求４３を生成し、サーバ制御部１１に送信する（Ｓ２０２）。

続いて、ＳＤＫ部２４は、サーバ制御部１１から報酬情報４４を受信する（Ｓ２０３）。報酬情報４４にエラーなしを示す応答（”ＥＲＲＯＲ”：”ＮＯＮＥ”）が含まれている場合（Ｓ２０４でＹｅｓ）、報酬情報４４の報酬ＩＤおよび報酬個数を少なくとも含む、ゲーム部２３用の報酬情報をゲーム部２３に送信する（Ｓ２０５）。

次に、報酬情報生成処理についてフローチャートを用いて詳細に説明する。図４４は、報酬情報生成処理のフローチャートである。

サーバ制御部１１は、ＳＤＫ部２４から取得した報酬情報要求４３からアプリユーザＩＤ４３ａ、アプリＩＤ４３ｂ、およびギフトＩＤ４３ｃを取得する（Ｓ２１１）。そして、サーバ制御部１１は、アプリユーザＩＤ４３ａ、アプリＩＤ４３ｂ、およびギフトＩＤ４３ｃに対応するユーザ報酬付与情報１５５ａをユーザ報酬付与情報１５５から取得する（Ｓ２１２）。なお、このときの検索条件には、報酬付与済みフラグが「ＦＡＬＳＥ」であるという条件も含まれる。

対応するユーザ報酬付与情報１５５ａを取得できた場合（Ｓ２１３でＹｅｓ）、サーバ制御部１１は、アプリＩＤ４３ｂおよびユーザ報酬付与情報１５５ａに含まれる報酬ＩＤに対応する報酬一覧情報１４４ａを報酬一覧情報１４４から取得する（Ｓ２１４）。

報酬一覧情報１４４ａの報酬種別がスタンプである場合（Ｓ２１５でＹｅｓ）、サーバ制御部１１は、アプリユーザＩＤ４３ａおよびアプリＩＤ４３ｂに対応するユーザ達成度情報１５２ｆをユーザ達成度情報１５２から取得する（Ｓ２１６）。そして、サーバ制御部１１は、ユーザ達成度情報１５２ｆのスタンプ数に報酬一覧情報１４４ａにより特定される報酬個数（スタンプ数）を加算し、かつ、報酬情報４４を生成および送信する（Ｓ２１７）。これにより、上述した図１３の（ｃ）に示されるように、ユーザ達成度情報１５２ｆのスタンプ数が加算される。

報酬一覧情報１４４ａの報酬種別がアイテムである場合（Ｓ２１５でＮｏ）、サーバ制御部１１は、報酬情報４４を生成および送信する（Ｓ２１８）。このときの報酬情報４４には、ユーザ報酬付与情報１５５ａに含まれる報酬ＩＤと、報酬一覧情報１４４ａに含まれる報酬個数とが含まれる。

サーバ制御部１１は、ステップＳ２１７、またはステップＳ２１８の後、ユーザ報酬付与情報１５５ａの報酬付与済みフラグを「ＴＲＵＥ」とする（Ｓ２１９）。

上記ステップＳ２１３で対応するユーザ報酬付与情報１５５ａを取得できなかった場合（Ｓ２１３でＮｏ）、サーバ制御部１１は、エラーが発生したことを示す応答（”ＥＲＲＯＲ”：”ＮＯ＿ＲＥＷＡＲＤ＿ＦＯＵＮＤ”）を含む報酬情報４４を生成および送信する（Ｓ２２０）。

なお、図示されないが、上記スタンプ加算処理において、スタンプ数がゴールスタンプ数を超えた場合は、サーバ制御部１１は、スタンプ情報１４１から、現在のスタンプシート１５２ｂの報酬ＩＤを取得し、ユーザ報酬付与情報１５５ａを生成する。なお、ユーザ報酬付与情報生成の手順は、ステップＳ１７７と同様であるため、詳細な説明は省略する。サーバ制御部１１は、あわせて、ユーザ達成度情報１５２ｆを更新する（スタンプシートの枚数を１加算し、スタンプ数をリセットする）。

［チェックインに基づく報酬付与］
次に、ゲーム報酬付与システム１００の特徴的な処理であるチェックイン（または店舗３０における購買）に基づく報酬付与について説明する。図４５は、チェックインに基づく報酬付与のシーケンス図である。なお、実施の形態１において、チェックインとは、店舗３０に設けられた２次元コードをモバイル端末２０の撮像部により読み取る等により、モバイル端末２０がスタンプ付与のための識別情報（実施の形態１では店舗ＩＤまたは購入ＩＤを含む情報）を取得する処理を意味する。

まず、ＳＤＫ部２４は、来店予備行動感知処理を行い（Ｓ２２１）、近隣店舗判定要求をサーバ制御部１１に送信する（Ｓ２２２）。サーバ制御部１１は、近隣店舗判定処理を行い（Ｓ２２３）、近隣店舗情報をＳＤＫ部２４に送信する（Ｓ２２４）。

ＳＤＫ部２４は、近隣店舗判定処理の結果に応じて、表示切替要求をゲーム部２３に送信する（Ｓ２２５）。このときゲーム部２３は、ゲーム処理中であるため（Ｓ２２６）、表示切替要求を受信後、プレーヤに対するゲーム体験を妨げないようゲーム処理を進めた後、来店情報取得要求をＳＤＫ部２４に送信する（Ｓ２２７）。なお、ゲーム部２３は、表示切替要求受信時に、「チェックイン画面に切り替える」旨のボタンを表示し、ユーザが本ボタンを押下したタイミングで来店情報取得要求をＳＤＫ部２４に送信してもよい。

続いて、ＳＤＫ部は、来店情報取得処理を行う（Ｓ２２８）。具体的には、チェックイン要求（または購買要求）をサーバ制御部１１に送信し（Ｓ２２９）、サーバ制御部１１は、チェックイン処理（購買処理）を行う（Ｓ２３０）。サーバ制御部１１は、報酬付与が必要である場合には、報酬付与有りの応答（報酬付与情報）をＳＤＫ部２４に送信する（Ｓ２３１）。以降、報酬画面表示処理（Ｓ２３２）〜報酬処理（Ｓ２４１）が行われるが、これらの処理は、既に説明した処理と同様であるため、詳細な説明は省略される。

次に、来店予備行動感知処理についてフローチャートを用いて詳細に説明する。図４６は、来店予備行動感知処理のフローチャートである。図４７は、近隣店舗判定要求（図４７の（ａ））および近隣店舗情報（図４７の（ｂ））の一例を示す図である。

まず、ＳＤＫ部２４は、モバイル端末２０が備える位置情報取得部を起動し、位置情報を取得する（Ｓ２５１）。位置情報取得部は、具体的にはＧＰＳモジュールであるが、モバイル端末２０の位置が取得できるのであればどのような態様であってもよい。

次に、ＳＤＫ部２４は、近隣店舗判定要求４５を生成し、サーバ制御部１１に送信する（Ｓ２５２）。図４７の（ａ）に示されるように、近隣店舗判定要求４５は、アプリユーザＩＤ４５ａ、アプリＩＤ４５ｂ、および位置情報４５ｃを含む。

続いて、ＳＤＫ部２４は、サーバ制御部１１から近隣店舗情報４６を受信する（Ｓ２５３）。図４７の（ｂ）に示されるように、近隣店舗情報４６は、近隣店舗の有無を示す応答４６ａを含む。

近隣店舗がある場合、すなわち、近隣店舗情報４６に近隣店舗が有ることを示す応答４６ａが含まれる場合（Ｓ２５４でＹｅｓ）、ＳＤＫ部２４は、ゲーム部２３に表示切替要求を送信する（Ｓ２５５）。

次に、近隣店舗判定処理についてフローチャートを用いて詳細に説明する。図４８は、近隣店舗判定処理のフローチャートである。

サーバ制御部１１は、受信した近隣店舗判定要求４５から、アプリユーザＩＤ４５ａ、アプリＩＤ４５ｂ、および位置情報４５ｃを取得する（Ｓ２６１）。続いて、サーバ制御部１１は、店舗属性情報１３１を参照して店舗の位置が所定の範囲内である店舗についての店舗属性情報を取得する（Ｓ２６２）。サーバ制御部１１は、例えば、位置情報４５ｃが示す位置から５００ｍの範囲内の店舗属性情報を取得する。

店舗属性情報を１つ以上取得できた場合（Ｓ２６３でＹｅｓ）、近隣店舗が有ることを示す応答４６ａを含む近隣店舗情報４６を生成し、ＳＤＫ部２４に送信する（Ｓ２６４）。店舗属性情報を取得できなかった場合（Ｓ２６３でＮｏ）、近隣店舗が無いことを示す応答４６ａを含む近隣店舗情報４６を生成し、ＳＤＫ部２４に送信する（Ｓ２６５）。

次に、来店情報取得処理についてフローチャートを用いて詳細に説明する。図４９は、来店情報取得処理のフローチャートである。図５０は、チェックイン要求（図５０の（ａ））および報酬付与情報（図５０の（ｂ））の一例を示す図である。図５１は、チェックインに用いられる２次元コードの一例を示す図である。

まず、ＳＤＫ部２４は、モバイル端末２０が備える撮像部を起動し、撮像部に２次元コードを読み取らせることによって２次元コードから店舗ＩＤ（店舗ＩＤを含む識別情報）を取得する（Ｓ２７１）。図５１に示されるように、店舗３０には２次元コードが印刷されたパネルが設置されており、この２次元コードは、店舗ＩＤを情報として含む。ユーザは、店舗３０に来店してモバイル端末２０によって２次元コードの読み取りを行う。２次元コードは、例えば、ＱＲコード（登録商標）であるが、その他の２次元コードであってもよい。また、２次元コードに代えてバーコード等、その他の識別情報が用いられてもよい。なお、ステップＳ２７１において取得されるＩＤは、後述する購買ＩＤであってもよい。

続いて、ＳＤＫ部２４は、モバイル端末２０が備える位置情報取得部を起動し、位置情報を取得する（Ｓ２７２）。

次に、ＳＤＫ部２４は、チェックイン要求４７を生成し、サーバ制御部１１に送信する（Ｓ２７３）。図５０の（ａ）に示されるように、チェックイン要求４７は、アプリユーザＩＤ４７ａ、アプリＩＤ４７ｂ、位置情報４７ｃ、および店舗又は購買ＩＤ４７ｄを含む。

続いて、ＳＤＫ部２４は、サーバ制御部１１から報酬付与情報４８を受信する（Ｓ２７４）。図５０の（ｂ）に示されるように、報酬付与情報４８は、報酬付与の有無を示す応答４８ａを含む。

報酬付与がある場合（Ｓ２７５でＹｅｓ）、ＳＤＫ部２４は、ゲーム部２３に報酬画面の表示を行う旨を通知する（Ｓ２７６）。そして、上述の報酬画面表示処理が行われる。なお、実際ここで行われる報酬画面表示処理には、上述の報酬画面表示処理とは、広告バナーが表示されるなどの差異がある。

次に、チェックイン処理（購買処理）についてフローチャートを用いて詳細に説明する。図５２は、チェックイン処理（購買処理）のフローチャートである。図５３は、報酬出現確率情報１４５の一例を示す図である。図５４は、広告情報１３２の一例を示す図である。図５５は、購入者特典情報１３３の一例を示す図である。

サーバ制御部１１は、ＳＤＫ部２４からチェックイン要求４７を受信し、アプリユーザＩＤ４７ａ、アプリＩＤ４７ｂ、位置情報４７ｃ、および店舗又は購買ＩＤ４７ｄを受信したチェックイン要求４７から取得する（Ｓ２８１）。

ここで、サーバ制御部１１は、店舗又は購買ＩＤ４７ｄが店舗ＩＤか、又は購買ＩＤかを判定するために、購入者特典情報１３３を参照して店舗又は購買ＩＤ４７ｄと購買ＩＤが一致する購入者特典情報１３３ａを取得する（Ｓ２８２）。ここで購入者特典情報１３３ａを取得できなかった場合（Ｓ２８３でＮｏ）、サーバ制御部１１は、店舗又は購買ＩＤ４７ｄは、購買ＩＤであると判定し、店舗属性情報１３１を参照して、店舗又は購買ＩＤ４７ｄと店舗ＩＤが一致する店舗属性情報（一例として店舗属性情報１３１ａとする）を取得する（Ｓ２８４）。なお、購入者特典情報１３３ａを取得できた場合は、（Ｓ２８３でＹｅｓ）、後述する購入者特典付与処理が行われる（Ｓ２９６）。

ステップＳ２８４において取得の対象となる店舗属性情報１３１ａは、店舗ＩＤ４７ｄ（以下、店舗又は購買ＩＤ４７ｄではなく、店舗ＩＤ４７ｄと記載する）、および、取得した位置情報４７ｃが示す位置に近接する位置を示す位置情報（緯度および経度）を有する店舗属性情報１３１ａである。ここで、これらの条件を満たす店舗属性情報１３１ａを取得できなかった場合（Ｓ２８５でＮｏ）は、サーバ制御部１１は、報酬付与無しを示す応答を含む報酬付与情報をＳＤＫ部２４に送信する（Ｓ２８６）。

このような、ステップＳ２８４〜ステップＳ２８６の処理は、ユーザがチェックインに基づく報酬付与を受けるためには、２次元コードを読み取るだけでは十分でなく、店舗３０の近辺で２次元コードを読み取らなければならないことを意味する。このような構成によりユーザを確実に店舗３０に集めることができる。

ステップＳ２８５において条件を満たす店舗属性情報１３１ａを取得できた場合（Ｓ２８５でＹｅｓ）、サーバ制御部１１は、ユーザ達成度情報１５２を参照してアプリユーザＩＤ４７ａおよびアプリＩＤ４７ｂを有するユーザ達成度情報１５２ｆを取得する。サーバ制御部１１は、取得したユーザ達成度情報１５２ｆからユーザＩＤ１５２ａを取り出す（Ｓ２８７）。そして、サーバ制御部１１は、ユーザチェックインログ１５３を参照して、取り出したユーザＩＤ１５２ａに対応するユーザＩＤを有し、かつ、時刻が当日の時刻であるチェックイン情報（一例としてチェックイン情報１５３ａとする）を取得する（Ｓ２８８）。

チェックイン情報１５３ａが取得できた場合（Ｓ２８９でＹｅｓ）、サーバ制御部１１は、報酬付与無しを示す応答を含む報酬付与情報をＳＤＫ部２４に送信する（Ｓ２８６）。

このような、ステップＳ２８７〜ステップＳ２８９の処理は、ユーザが１日に１回だけチェックインに基づく報酬付与を受けることができるようにするために行われる。なお、チェックインに基づく報酬付与を再度受けるために必要な期間は、上記のように１日に限定されるものではなく、どのように設定されてもよい。また、期間に関係なく１回だけ報酬付与が行われる場合は、ステップＳ２８７〜ステップＳ２８９において時刻の判断が不要となる。

ステップＳ２８９においてチェックイン情報１５３ａが取得できなかった場合（Ｓ２８９でＮｏ）、サーバ制御部１１は、ユーザチェックインログ１５３に、ユーザＩＤ１５２ａ、店舗ＩＤ４７ｄ、アプリＩＤ４７ｂ、および現在時刻を含むチェックイン情報を追加（登録）する（Ｓ２９０）。

次に、サーバ制御部１１は、ステップＳ２８７において取得したユーザ達成度情報１５２ｆからレベル１５２ｄを取り出し、報酬出現確率情報１４５を参照して、アプリＩＤ４７ｂおよびレベル１５２ｄを有する報酬出現確率情報１４５ａを１以上取得する（Ｓ２９１）。

ここで、レベル１５２ｄは、ゲームの進行状況を示す進行レベルを意味し、レベル１５２ｄは、進行レベルに応じて報酬の内容を変えるために用いられる。

例えば、報酬として付与されるスタンプまたはアイテムの数は、ゲームの進行レベルが進む程多く設定される。一般に、ゲームにおいては、ゲームの進行レベルが進むほど難易度が上がるため、ゲームバランスを保つために上記のように設定される。

次に、サーバ制御部１１は、取得した１以上の報酬出現確率情報１４５ａの抽選を行う（Ｓ２９２）。抽選は、報酬出現確率情報に含まれる報酬出現確率に基づいて行われる。また、サーバ制御部１１は、抽選した報酬出現確率情報に含まれる報酬ＩＤを取り出す（Ｓ２９３）。一方で、サーバ制御部１１は、広告情報１３２から店舗ＩＤ４７ｄに関連する広告情報１３２ａを取り出す（Ｓ２９４）。なお、広告情報１３２は、店舗属性情報１３１と組み合わせられて使用される情報であるため、広告情報１３２には、店舗ＩＤ等は含まれない。

最後に、サーバ制御部１１は、ステップＳ２９３において取り出した報酬ＩＤに基づいて報酬画面情報の生成処理（図４０のステップＳ１９３〜Ｓ１９７）を行う（Ｓ２９５）。

なお、ステップＳ２９４において広告情報１３２ａを取り出すことができた場合は、取り出した広告情報に含まれるバナーイメージ（バナー情報）を追加した報酬画面情報が生成される。図５６は、バナーイメージを追加した報酬画面情報の一例を示す図である。なお、図５６に示される報酬画面情報は、アイテム付与画面２７ｄの表示に用いられるものであるが、スタンプシート画面２７ｃの表示に用いられる報酬画面情報についても同様である。

図５６に示される報酬画面情報４２ｃによれば、モバイル端末２０の表示部には、バナーイメージを含むアイテム付与画面２７ｄが表示される。アイテム付与画面２７ｄのように、バナーイメージには、例えば、チェックイン用の２次元コードが設けられた店舗にて買い物を行えばさらにスタンプが追加で付与される旨が表示されてもよい。これにより、ユーザに対して店舗３０における商品の購入を促すことができる。

次に、購入者特典付与処理について説明する。図５７は、購入者特典付与処理に用いられる２次元コードが印刷されたチケットの一例を示す図である。

図５７に示されるチケットは、購買ＩＤを含む２次元コードを含む名刺サイズ程度の紙であって、店舗３０で商品を購入した場合に配布されるものである。実施の形態１では、商品の購入金額に応じて異なるチケットが配布される。例えば、商品の購入金額が所定の金額（ここでは１０００円）未満のユーザには、図５７の（ａ）に示されるチケットが配布され、商品の購入金額が所定の金額以上のユーザには図５７の（ｂ）に示されるチケットが配布される。つまり、ユーザの購入金額に応じて異なる種類のチケットが配布される。なお、図５７に示されるチケットは、商品購入の対価として配布されるため、店舗３０に設けられたチェックイン用の２次元コード（図５１）とは異なり、店舗３０の近隣において読み取られる必要はない。

以下、購入者特典付与処理（図５２のステップＳ２８３でＹｅｓの場合の処理）について、フローチャートを用いて詳細に説明する。図５８は、購入者特典付与処理のフローチャートである。図５９は、購入者特典報酬情報１４６の一例を示す図である。

図５２のステップＳ２８３において取得した購入者特典情報１３３ａの使用済みフラグが「ＴＲＵＥ」である場合（Ｓ３０１でＹｅｓ）、サーバ制御部１１は、報酬付与無しを示す応答を含む報酬付与情報をＳＤＫ部２４に送信する（Ｓ３０２）。

図５２のステップＳ２８３において取得した購入者特典情報１３３ａの使用済みフラグが「ＦＡＬＳＥ」である場合（Ｓ３０１でＮｏ）、サーバ制御部１１は、購入者特典報酬情報１４６を参照して、購入者特典報酬情報１４６ａを取得する（Ｓ３０３）。ここで、取得の対象となる購入者特典報酬情報１４６ａは、購入者特典情報１３３ａに含まれる購入者特典ＩＤと一致する購入者特典ＩＤを有する購入者特典報酬情報である。

続いて、購入者特典情報１３３ａの使用済みフラグを「ＴＲＵＥ」に更新する（Ｓ３０４）。そして、サーバ制御部１１は、取得した購入者特典報酬情報１４６ａに含まれる報酬ＩＤに基づいて報酬画面情報の生成処理（図４０のステップＳ１９３〜Ｓ１９７）を行う（Ｓ３０５）。

以上説明したように、実施の形態１に係るゲーム報酬付与システム１００によれば、ユーザは、ゲーム進行させて得られる報酬と同じ態様の報酬をチェックインに基づいて得ることができる。

ゲーム報酬付与システム１００においては、小さな達成の積み重ねをスタンプの押印のような効果的な視覚効果で表現し、大きな達成と報酬につなげるゲーム的手法をユーザの現実の行動（店舗への来店）に適用しているといえる。このような手法は、ゲーミフィケーションと呼ばれ、効果的であることが実証されている。なお、ゲーミフィケーションとは、ゲームのメカニズムを健康・教育等の他分野へ応用し、これらを改善する方法論を意味する。

また、ゲーム報酬付与システム１００を実現するためには、既存のゲーム用アプリケーション（ゲーム部２３）に上記ＳＤＫ（ＳＤＫ部２４）を組み込むだけでよい。言い換えれば、既存のゲーム用アプリケーションに、上述のチェックインに基づく報酬付与機能を付加することは容易である。つまり、ゲーム報酬付与システム１００は、汎用性が高いといえる。

［まとめ］
以上、実施の形態１に係るゲーム報酬付与システム１００を用いた情報提供方法について説明した。ここで、ゲーム報酬付与システム１００は、ゲームの進行レベルに応じてゲーム報償を得るタイプのゲーム用アプリケーションを搭載し且つディスプレイを有するモバイル端末２０とネットワーク４０を介して接続される。

ここで、ゲーム報酬付与システム１００は、情報管理システムの一例であり、モバイル端末２０は、情報機器の一例である。また、ゲーム報償は、具体的には、ゲーム上で得られるスタンプまたはアイテムである。

実施の形態１に係る情報提供方法においては、所定の店舗を示す店舗ＩＤを含む識別情報（２次元コードに含まれる情報）を取得したモバイル端末２０からネットワーク４０を介して、店舗ＩＤと共にモバイル端末２０において起動中のゲーム用アプリケーションを示すアプリＩＤ及びゲーム用アプリケーションのユーザを示すユーザＩＤ（アプリユーザＩＤ）を受信する。

そして、実施の形態１に係る情報提供方法においては、アプリＩＤ及びアプリユーザＩＤに応じて、第１データベース（ユーザ情報ＤＢ１５）、及び、第２データベース（ゲームアプリ情報ＤＢ１４）を参照して、ゲームの進行レベルに応じた第１ゲーム報償が付与される旨の第１指示データ（報酬画面情報）を、ネットワーク４０を介してモバイル端末２０に送信する。

ここで、ユーザ情報ＤＢ１５内のユーザ達成度情報１５２においては、アプリＩＤ及びユーザＩＤと対応付けてユーザによるゲームの進行レベルが管理されている。また、ゲームアプリ情報ＤＢ１４の報酬出現確率情報１４５においては、アプリＩＤ及び進行レベルに対応して付与される第１ゲーム報償を示す第１ゲーム報償ＩＤ（報酬ＩＤ）が管理されている。

また、上記情報提供方法においては、具体的には、登録されている登録店舗を管理する第３データベース（店舗情報ＤＢ１３の店舗属性情報１３１）を参照して、受信した店舗ＩＤ示す店舗が登録店舗に含まれるか否かを判断する（図５２のＳ２８５）。そして、受信した店舗ＩＤ示す店舗が登録店舗に含まれる場合、第１指示データを、ネットワーク４０を介してモバイル端末２０に送信する（図５２のＳ２９５）。

また、上記識別情報は、所定の店舗の位置を示す第１位置情報を含む（識別情報に含まれる店舗ＩＤが店舗属性情報１３１において位置情報（緯度および経度）と対応付けられている）。

そこで、上記情報提供方法においては、モバイル端末２０からモバイル端末２０の位置を示す第２位置情報を、ＧＰＳシステムを用いて取得する（図５２のＳ２８１）。そして、第２位置情報が示す位置が、第１位置情報が示す位置から所定距離の範囲内にある場合（図５２のＳ２８５でＹｅｓ）、第１指示データを、ネットワーク４０を介してモバイル端末２０に送信する（図５２のＳ２９５）。

また、上記情報提供方法においては、第１指示データがモバイル端末に送信された後、アプリＩＤが示すアプリケーションを起動しているユーザＩＤが示すユーザに対して、第１ゲーム報償を既に付与した旨を示す状態情報（報酬付与済みフラグが「ＴＲＵＥ」）を管理する。

また、第１指示データは、店舗ＩＤが示す店舗にて購買すればさらにゲーム報償が追加で付与される旨の広告情報（図５６のバナーイメージ）を含む。そこで、上記情報提供方法においては、店舗３０にて商品又はサービスを購買したことを示す購入ＩＤ（図５７に示される２次元コードに含まれる購買ＩＤ）を読み取ったモバイル端末２０からネットワーク４０を介して、購入ＩＤと共にアプリＩＤを受信する（図５２のＳ２８１）。

そして、アプリＩＤに応じて、アプリＩＤ及びアプリＩＤに対応して付与される第２ゲーム報償を示す第２ゲーム報償ＩＤ（報酬ＩＤ）を管理する第３データベース（ゲームアプリ情報ＤＢ１４の購入者特典報酬情報１４６）を参照して（図５８のＳ３０３）、第２ゲーム報償が追加で付与される旨の第２指示データ（報酬画面情報）を、ネットワーク４０を介してモバイル端末２０に送信する（図５８のＳ３０５）。

また、第３データベースは、アプリＩＤ及び第２ゲーム報償ＩＤと対応付けて、どの価格帯の商品又はサービスを購入したかを示す特典ＩＤ（購入者特典ＩＤ）を管理している。

そこで、上記情報提供方法では、購入ＩＤ及び特典ＩＤを読み取ったモバイル端末２０からネットワーク４０を介して、購入ＩＤ及び特典ＩＤと共にアプリＩＤを受信する（図５２のＳ２８１）。そして、特典ＩＤ及びアプリＩＤに応じて、第３データベースを参照して（図５８のＳ３０３）、第２ゲーム報償が追加で付与される旨の第２指示データを、ネットワーク４０を介してモバイル端末２０に送信する。

このような情報提供方法によれば、ゲームのプレーヤに現実の店舗３０への来店の動機を与えることができる。

［実施の形態１の変形例］
上記実施の形態１において説明された複数のデータベース（店舗情報ＤＢ１３、ゲームアプリ情報ＤＢ１４、およびユーザ情報ＤＢ１５）は、１つのデータベースとして構成されてもよい。また、上記実施の形態１において説明されたデータベースに記憶される情報の内容や、情報のデータベースへの振り分けは、一例であり、特に限定されるものではない。また、上記実施の形態１では、サーバ１０が複数のデータベースを備えたが、複数のデータベースは、サーバ１０の外部に設けられてもよい。

また、上記実施の形態１においてゲーム画面２７ｂ、スタンプシート画面２７ｃ、またはアイテム付与画面２７ｄには、チェックインに基づく報酬付与のイベントが開催されている旨の広告（バナー広告）が表示されてもよい。また、このような広告は、モバイル端末２０が備える位置情報取得部の位置情報の取得により、ユーザが店舗３０の位置から所定の範囲内に位置している場合に表示されてもよい。これにより、さらに店舗３０へ集客を図ることができる。なお、このような広告の表示は、上記実施の形態１で説明した、モバイル端末２０のユーザ（モバイル端末２０）が店舗３０の近くにいるか否かの判定処理と同様の処理を用いて実現可能である。

（実施の形態２）
［実施の形態２に係る情報処理方法の基礎となった知見］
上記実施の形態１では、チェックインの際には、モバイル端末２０の撮像部により２次元コードの読み取りが行われた。しかしながら、モバイル端末２０が店舗ＩＤを取得できるのであれば、２次元コードの読み取り以外でチェックインが行われてもよい。例えば、店舗３０において無線通信によって店舗ＩＤ（実施の形態２では、後述するビーコン装置のデバイスＩＤ）が配信されることによりチェックインが行われてもよい。

例えば、店舗３０内にビーコン装置を設置し、ビーコン装置から送信される無線信号であるビーコン信号をモバイル端末２０で受信することにより、チェックインが行われる構成が考えられる。

このような構成においては、ビーコン装置が送信するビーコン信号の盗聴や、ビーコン装置の盗難が行われると、ゲームのプレーヤに現実の店舗３０への来店の動機を与えることが難しくなる。したがって、ビーコン装置の不正利用を抑制するための対策が課題となる。

そこで、実施の形態２では、ビーコン装置の不正利用を抑制することができる情報処理方法（ゲーム報酬付与システム）について説明する。なお、以下の実施の形態２では、実施の形態１との相違点を中心に説明し、実質的に同一の内容については説明が省略される場合がある。

［構成］
まず、実施の形態２に係るゲーム報酬付与システムの構成について説明する。図６０は、実施の形態２に係るゲーム報酬付与システムの機能構成を示す図である。

図６０に示されるように、実施の形態２に係るゲーム報酬付与システム１００ａは、サーバ１０ａ（サーバ装置の一例）と、モバイル端末２０ａ（携帯端末の一例）とを備える。サーバ１０ａとモバイル端末２０ａとはネットワーク４０（例えば、インターネット）を通じて接続されている。また、図６０には、モバイル端末２０ａにおいて実行されるゲームのコラボレーションの対象となる店舗３０ａも図示されている。

モバイル端末２０ａとモバイル端末２０との違いは、ＳＤＫ部２４ａの処理内容である。また、モバイル端末２０ａは、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）部２１ａ（実施の形態１の位置情報取得部。実施の形態１では図示せず。)と、無線通信部２１ｂとを備える点もモバイル端末２０と異なる。

ＧＰＳ部２１ａは、モバイル端末２０ａの現在位置情報を取得するＧＰＳモジュールである。現在位置情報の取得は、制御部２１がＧＰＳ部２１ａを制御することにより行われる。

無線通信部２１ｂは、モバイル端末２０ａと、店舗３０ａに設けられた複数のビーコン装置５０ａ〜５０ｎとが無線通信を行うための無線通信モジュールである。モバイル端末２０ａと複数のビーコン装置５０ａ〜５０ｎとの間の信号の送受信は、制御部２１が無線通信部２１ｂを制御することにより行われる。無線通信部２１ｂが行う無線通信の通信規格は、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）であるが、無線ＬＡＮなど、その他の通信規格であってもよい。

サーバ１０と、サーバ１０ａとの違いは、サーバ制御部１１ａの処理内容である。また、サーバ１０ａは、サーバ記憶部１６を備える点もサーバ１０と異なる。さらに、実施の形態２では、店舗３０ａに複数のビーコン装置５０ａ〜５０ｎと、ＰＣ６０とが設けられている点が実施の形態１と異なる。

以下、ゲーム報酬付与システム１００ａの詳細な機能構成について説明する。図６１は、ゲーム報酬付与システム１００ａの詳細な機能構成を示すブロック図である。なお、図６１では、以下の実施の形態２の説明において主に説明される構成要素が図示されており、図６０において図示された構成要素のうち一部の構成要素については図示が省略されている。

また、実施の形態１と同様に、以下の実施の形態２では、制御部２１がゲームアプリを実行することによって行われる処理は、単に「ゲーム部２３は・・する」または「ＳＤＫ部２４ａは・・する」と記載される。また、ＳＤＫ部２４ａの構成要素によって行われる処理も同様に、構成要素を主体とした表現で記載される。

また、モバイル端末２０ａ（ＳＤＫ部２４ａ）とサーバ１０ａ（サーバ制御部１１ａ）との間の通信（例えば、ビーコン通信部７３と、ビーコン制御部８３との間の通信）は、制御部２１（通信部）及びネットワーク４０を通じて行われるものとする。

また、モバイル端末２０ａ（ＳＤＫ部２４ａ）と複数のビーコン装置５０ａ〜５０ｎとの間の通信は、無線通信部２１ｂを通じて行われるものとする。つまり、モバイル端末２０ａ（ＳＤＫ部２４ａ）と複数のビーコン装置５０ａ〜５０ｎとの通信は、モバイル端末２０ａの無線通信機能を利用して行われる。

まず、モバイル端末２０ａのＳＤＫ部２４ａについて詳細に説明する。ＳＤＫ部２４ａは、情報収集部７１と、広告表示部７２と、ビーコン通信部７３と、リワード付与部７４とを備える。

情報収集部７１は、ユーザの性別、年齢、及び、住所（居所）などのユーザに関する情報を取得する。また、情報収集部７１は、ユーザに関する情報をサーバ１０ａの情報取得部８１に送信する。なお、ユーザに関する情報は、例えば、情報収集部７１がモバイル端末２０ａの表示部に表示する入力受付画面を通じて取得されるが、モバイル端末２０ａ内に予め記憶されていてもよい。

広告表示部７２は、図１４に示される店舗コラボ情報の取得処理と同様の処理、及び、図２５に示される店舗コラボ画像の描画処理と同様の処理を行う。

ビーコン通信部７３は、店舗３０ａに設置されたビーコン装置（例えば、ビーコン装置５０ａ）からビーコン信号を受信し、受信したビーコン信号に含まれるデバイスＩＤをビーコン制御部８３に送信する。また、ビーコン通信部７３は、アプリＩＤ、アプリユーザＩＤ、及びモバイル端末２０ａの現在位置情報をビーコン制御部８３に送信する。アプリＩＤ及びアプリユーザＩＤは、ゲーム部２３に含まれる。また、現在位置情報は、モバイル端末２０ａが備えるＧＰＳ部２１ａから取得される。

リワード付与部７４は、図３６に示される報酬画面表示処理と同様の処理、及び、図４２に示される報酬付与処理と同様の処理を行う。

次に、サーバ１０ａのサーバ制御部１１ａについて説明する。サーバ制御部１１ａは、情報取得部８１と、広告配信部８２と、ビーコン制御部８３と、リワード制御部８４と、広告指定受付部８５とを備える。

情報取得部８１は、情報収集部７１からユーザに関する情報を取得し、取得した情報をアプリ利用者情報としてサーバ記憶部１６に記憶する。

広告配信部８２は、図１８に示される店舗コラボ情報の生成処理と同様の処理、及び、図１８に示される店舗コラボ情報の送信処理と同様の処理を行う。

なお、実施の形態２では、実施の形態１と異なり、広告配信部８２が生成する店舗コラボ情報の内容を、店舗３０ａに設けられたＰＣ６０を通じて指定することも可能である。具体的には、広告指定受付部８５は、店舗３０ａの広告担当者がＰＣ６０を通じて入力する、コラボレーションの対象となる店舗の指定や、ゲーム報酬の内容の指定を受け付ける。

また、店舗３０ａの広告担当者は、アプリ利用者情報に基づいて、店舗コラボ情報を送信するモバイル端末２０ａを指定することも可能である。つまり、店舗３０ａの広告担当者は、ＰＣ６０を通じて広告の配信先を指定することができる。店舗３０ａの広告担当者は、具体的には、例えば、３０歳以上のユーザのモバイル端末にのみ店舗コラボ情報を送信することができる。

なお、広告指定受付部８５が受け付けた指定の内容は、例えば、サーバ記憶部１６に記憶される。

ビーコン制御部８３は、モバイル端末２０ａの周辺に存在するビーコン装置情報の提供、異常度の算出、及び、算出した異常度に応じた処理を行う。ビーコン制御部８３は、具体的には、モバイル端末２０ａのビーコン通信部７３から、当該モバイル端末２０ａの現在位置を示す現在位置情報（第一位置情報の一例）を取得する。また、ビーコン制御部８３は、取得された現在位置情報と、ビーコン装置５０ａの設置位置を示す設置位置情報（後述する、ビーコンＩＤ情報）とを比較することにより、モバイル端末２０ａの周囲に存在するビーコン装置に関する情報の提供を行う。また、ビーコン制御部８３は、取得された現在位置情報と、ビーコン装置５０ａの設置位置を示す設置位置情報とを比較することにより、ビーコン装置５０ａの異常度を算出し、算出された異常度に応じた処理を行う。ビーコン制御部８３のこのような動作は、サーバ１０ａの特徴的な動作であり、詳細については後述する。

ビーコン制御部８３内には、鍵情報８６ａ〜８６ｎが保持（記憶）されている。鍵情報８６ａ〜８６ｎは、それぞれビーコン装置５０ａ〜５０ｎと暗号化通信を行うための鍵情報である。鍵情報８６ａによって暗号化された信号は、ビーコン装置５０ａが保持する鍵情報５１ａによって復号可能であり、鍵情報５１ａによって暗号化された信号は、鍵情報８６ａによって復号可能である。同様に、鍵情報８６ｎによって暗号化された信号は、ビーコン装置５０ｎが保持する鍵情報５１ｎによって復号可能であり、鍵情報５１ｎによって暗号化された信号は、鍵情報８６ｎによって復号可能である。なお、鍵情報５１ｎと鍵情報８６ｎは同一であってもよい（共通鍵暗号）。

リワード制御部８４は、図４０に示される報酬画面情報の生成処理と同様の処理、及び図４４に示される報酬情報生成処理と同様の処理を行う。

次に、店舗３０ａに設置された構成要素（ビーコン装置５０ａ〜５０ｎ及びＰＣ６０）について説明する。

ビーコン装置５０ａ〜５０ｎのそれぞれは、店舗３０ａに設けられ、無線通信用の電波であるビーコン信号を周期的に繰り返し送信する装置である。ビーコン信号には、例えば、当該ビーコン信号を送信したビーコン装置のデバイスＩＤ（識別情報）が含まれる。ビーコン装置５０ａは、第一ビーコン装置の一例であり、ビーコン装置５０ｎは、第二ビーコン装置の一例である。

ビーコン装置５０ａ〜５０ｎの態様は、特に限定されるものではないが、実施の形態２では、３ｃｍ×３ｃｍ程度の基板に回路部品が実装された小さなモジュールが使用される。また、実施の形態２では、ビーコン装置５０ａ〜５０ｎは、ボタン電池で駆動するが、メンテナンスの観点から、電池交換の頻度が抑えられることが望ましい。そこで、ビーコン装置５０ａ〜５０ｎは、消費電力を抑えるために、ＧＰＳモジュールなどの自装置の位置情報を取得するための構成要素を有しない。

また、上述のように、ビーコン装置５０ａ〜５０ｎのそれぞれは、ビーコン制御部８３と暗号化通信を行うための鍵情報５１ａ〜５１ｎを保持している。なお、ビーコン装置５０ａ〜５０ｎは、サーバ１０ａと直接通信を行う構成要素を有しないため、ビーコン装置５０ａ〜５０ｎがサーバ１０ａと通信を行う場合には、モバイル端末２０ａを介して情報の送受信が行われる。しかしながら、モバイル端末２０ａは、鍵情報５１ａ〜５１ｎに対応する鍵情報を保持していないため、モバイル端末２０ａにおいて情報の改ざん等を行うことは難しい。

なお、実施の形態２では、１つの店舗３０ａ、つまり、１つの建物（空間）内に複数のビーコン装置が設置されているが、店舗３０ａには少なくとも１つのビーコン装置が設置されていればよく、複数設置される必要はない。

ＰＣ６０は、店舗３０ａに設けられたパーソナルコンピュータであり、店舗３０ａの広告担当者が店舗コラボ情報の内容の指定などに使用する。なお、ＰＣ６０は、必ずしも店舗３０ａに設けられる必要はない。また、ＰＣ６０に代えて、スマートフォンなどの他の情報通信端末が用いられてもよい。

最後に、サーバ記憶部１６について説明する。図６２は、サーバ記憶部１６に記憶される情報を示す図である。

図６２に示されるように、サーバ記憶部１６には、ビーコンＩＤ情報１６１と、チェックイン履歴１６２とが記憶される。また、図示されないが、サーバ記憶部１６には、上述のアプリ利用者情報、及び、広告指定受付部８５が受け付けた指定の内容も記憶される。

ビーコンＩＤ情報１６１は、第二位置情報の一例であって、サーバ１０ａによって予め管理されている情報であり、具体的には図６３に示されるような情報である。図６３は、ビーコンＩＤ情報の一例を示す図である。

図６３に示されるように、ビーコンＩＤ情報１６１においては、複数のビーコン装置のデバイスＩＤと、当該ビーコン装置の設置位置とが対応付けられた情報である。なお、ビーコンＩＤ情報１６１には、その他に、複数のビーコン装置それぞれのデバイス名、設置店舗の店舗ＩＤ、設置場所、電波強度（ＲＳＳＩ：ｒｅｃｅｉｖｅｄ ｓｉｇｎａｌ ｓｔｒｅｎｇｔｈ ｉｎｔｅｎｓｉｔｙ）、不正フラグなどの情報も含まれる。

チェックイン履歴１６２は、チェックインのログである。図６４は、チェックイン履歴の一例を示す図である。後述するように、ビーコン装置５０ａ〜５０ｎからビーコン信号を受信したモバイル端末２０ａは、ビーコン信号に含まれるデバイスＩＤをサーバ１０ａに送信する。このとき、サーバ１０ａは、モバイル端末２０ａから送信されるデバイスＩＤを、当該デバイスＩＤの受信日時と対応付けてチェックイン履歴としてサーバ記憶部１６に記憶する。同様に、サーバ１０ａは、他のモバイル端末から送信されるデバイスＩＤの受信日時についても、サーバ記憶部１６にチェックイン履歴１６２として記憶する。

つまり、複数のモバイル端末（第二携帯端末の一例）のそれぞれは、ビーコン装置５０ａから受信したビーコン信号に含まれるビーコンＩＤ（第一ＩＤの一例）を、サーバ１０ａに送信する。サーバ１０ａは、複数のモバイル端末のそれぞれから送信されるビーコンＩＤの受信日時をチェックイン履歴１６２として管理する。同様に、複数のモバイル端末（第三携帯端末の一例）のそれぞれは、ビーコン装置５０ａとは異なるビーコン装置（例えば、ビーコン装置５０ｎ）から受信したビーコン信号に含まれるビーコンＩＤ（第二ＩＤの一例）を、サーバ１０ａに送信する。サーバ１０ａは、さらに、複数のモバイル端末のそれぞれから送信されるビーコンＩＤの受信日時をチェックイン履歴１６２として管理する。

なお、図６４に示されるように、チェックイン履歴１６２には、その他に、チェックイン時におけるモバイル端末の現在位置であるチェックイン位置、アプリユーザＩＤ、及び、アプリＩＤ（図示せず）などの情報も含まれる。

なお、以下の実施の形態２では、ビーコン装置５０ａのデバイスＩＤの受信日時からなるチェックイン履歴は、第一チェックイン履歴とも記載される。また、複数のビーコン装置５０ａ〜５０ｎのうちビーコン装置５０ａ以外のビーコン装置のデバイスＩＤの受信日時からなるチェックイン履歴は、第二チェックイン履歴とも記載される。

［動作］
次に、ゲーム報酬付与システム１００ａの動作について説明する。図６５Ａは、ゲーム報酬付与システム１００ａの動作のシーケンス図である。なお、図６５Ａの動作は、ユーザが店舗３０ａに来店し、モバイル端末２０ａ内に記憶されたゲームアプリを起動したときに行われる。具体的には、例えば、アプリ起動中の画面からユーザがトリガボタンを押下することにより図６５Ａの動作が開始される。

まず、モバイル端末２０ａのビーコン通信部７３は、モバイル端末２０ａの現在位置付近のデバイスのデバイスＩＤの取得要求をサーバ１０ａのビーコン制御部８３に送信する（Ｓ３１１）。このとき、ビーコン通信部７３は、ＧＰＳ部２１ａを起動し、ＧＰＳ部２１ａから取得したモバイル端末２０ａの現在位置情報を、デバイスＩＤの取得要求に含めて送信する。

次に、ビーコン制御部８３は、モバイル端末２０ａの現在位置の近傍に位置するビーコン装置のデバイスＩＤのリストを送信する（Ｓ３１２）。例えば、ビーコン制御部８３は、サーバ記憶部１６内のビーコンＩＤ情報１６１を参照して、モバイル端末２０ａの現在位置から所定の範囲内（例えば、１ｋｍ圏内）に設置されているビーコン装置を選択し、選択したビーコン装置のデバイスＩＤのリストをビーコン通信部７３に送信する。ただし、ビーコンＩＤ情報１６１において不正フラグの値が「ペンディング」、「一時停止」、「完全停止」を示すビーコン装置は、不正に利用されている可能性がある。このため、ビーコン制御部８３は、このようなビーコン装置のデバイスＩＤは、上記リストには含めない。

一方、店舗３０ａに設けられた複数のビーコン装置５０ａ〜５０ｎのそれぞれ（例えば、ビーコン装置５０ａ）は、ビーコン信号を周期的に繰り返し送信している（Ｓ３１３）。ここで、ビーコン通信部７３は、ビーコン装置５０ａからビーコン信号を受信すると、ビーコン装置５０ａに接続し（Ｓ３１４）、ビーコン装置５０ａにデバイスＩＤの取得要求を送信する（Ｓ３１５）。

デバイスＩＤの取得要求を受信したビーコン装置５０ａは、当該ビーコン装置５０ａのデバイスＩＤを含むビーコン信号をビーコン通信部７３に送信する（Ｓ３１６）。

なお、ビーコン装置５０ａは、上記ステップＳ３１３〜ステップＳ３１６のように、ビーコン装置５０ａとモバイル端末２０ａとの間の双方向通信によりデバイスＩＤをモバイル端末２０ａに送信してもよいし、上記ステップＳ３１３においてデバイスＩＤを含むビーコン信号をモバイル端末２０ａへ送信（ブロードキャスト）してもよい。図６５Ｂは、ゲーム報酬付与システム１００ａのこのような動作のシーケンス図である。

図６５Ｂに示されるようなゲーム報酬付与システム１００ａの動作においては、上記ステップＳ３１４〜ステップＳ３１６の処理が省略され、ステップＳ３１３においてビーコン装置５０ａデバイスＩＤを含むビーコン信号がブロードキャストされる。つまり、デバイスＩＤの送信のために双方向通信を行う必要がなくなり、通信の高速化、通信のための消費電力の低減が可能である。一方、ビーコン信号に含めることができる情報量には制限があるため、デバイスＩＤのデータ長が制限されることになる。

ビーコン通信部７３は、ビーコン信号を受信すると、受信したビーコン信号に含まれるデバイスＩＤと、この時点でＧＰＳ部２１ａから取得されるモバイル端末２０の現在位置情報とを含む報酬付与の要求をビーコン制御部８３に送信する（Ｓ３１７）。なお、報酬付与の要求には、アプリＩＤ及びアプリユーザＩＤも含まれる。

ビーコン制御部８３は、ビーコン通信部７３から、報酬付与の要求を受信する（Ｓ３１８）。言い換えれば、ビーコン制御部８３は、デバイスＩＤ及び当該モバイル端末２０ａの現在位置を示す現在位置情報を取得する。次に、ビーコン制御部８３は、チェックイン情報を保存する（Ｓ３１９）。つまり、ビーコン制御部８３は、モバイル端末２０ａから送信されるデバイスＩＤ及び現在位置情報の受信日時をチェックイン履歴１６２（第一チェックイン履歴）として管理（記憶）する。そして、ビーコン制御部８３は、ビーコン装置５０ａの異常度を算出する（Ｓ３２０）。ビーコン制御部８３は、例えば、サーバ記憶部１６に記憶されたビーコンＩＤ情報１６１を参照してモバイル端末２０ａの設置位置を読み出し、読み出した設置位置と取得された現在位置情報とを比較することによりビーコン装置５０ａの異常度を算出する。そして、ビーコン制御部８３は、ステップＳ３２０において算出された異常度に応じた処理を行う（Ｓ３２１）。

［異常度の算出方法］
次に、図６５ＡのステップＳ３２０の異常度の算出方法について詳細に説明する。なお、以下の説明では、一例として、最も異常度が高い場合は、異常度＝１、最も異常度が低い場合、つまり正常な場合は、異常度＝０とする。

上述のようにサーバ記憶部１６には、ビーコンＩＤ情報１６１が記憶されている。つまり、ビーコン制御部８３は、ビーコン装置５０ａの設置位置を示すビーコンＩＤ情報１６１を予め管理している。

ここで、ステップＳ３１８で取得されたモバイル端末２０ａの現在位置情報が示す位置が、ビーコンＩＤ情報１６１が示すビーコン装置５０ａの設置位置と大きく異なる場合、ビーコン装置５０ａが盗難等によりビーコンＩＤ情報１６１が示す設置位置と異なる位置に設置されていることが疑われる。

そこで、ビーコン制御部８３は、例えば、ビーコンＩＤ情報１６１が示す設置位置と、モバイル端末２０ａの現在位置との差が所定値以内であればビーコン装置５０ａが正常（異常度＝０）、所定値よりも大きい場合異常（異常度＝１）と判断する。

上記の判断は最もシンプルな例である。実施の形態２では、ビーコン制御部８３は、ステップＳ３１８で取得されたモバイル端末２０ａの現在位置情報が、ビーコンＩＤ情報１６１が示す設置位置と、取得された現在位置情報が示す現在位置との差が大きいほど、異常度を高く算出する。

なお、異常度の算出においては、上記のような現在位置情報以外の情報が用いられてもよい。上述のように、ビーコン制御部８３は、複数のモバイル端末のそれぞれから送信されるビーコン装置５０ａのビーコンＩＤの受信日時を第一チェックイン履歴として管理（サーバ記憶部１６に記憶）している。異常度の算出には、この第一チェックイン履歴が用いられてもよい。

店舗３０ａにビーコン装置５０ａが設けられる場合には、チェックイン数は、店舗ごと、時間帯ごとにばらつく傾向がある（例えば、店舗１では、１２時〜１３時の時間帯は、チェックイン数が比較的多いが、２０時〜２１時の時間帯は、比較的少ない、など）。

しかしながら、ビーコン装置５０ａが不正に利用されている場合には、上記チェックイン数の傾向が通常と異なったり、チェックイン数が通常よりも激減していたりする場合が多い。つまり、このような場合、現在の第一チェックイン履歴は、過去の第一チェックイン履歴と比べて大きく異なるものと考えられる。

したがって、ビーコン制御部８３は、ステップＳ３１８で現在位置情報の取得を行ったときの第一チェックイン履歴と、これよりも前の過去の第一チェックイン履歴とを比較することにより、異常度を算出してもよい。例えば、ビーコン制御部８３は、現在のチェックイン数の分布と、過去のチェックイン数の分布間との類似度を算出し、算出した類似度が低いほど異常度が高いと算出する。なお、類似度の算出には、公知の手法が用いられる。

例えば、モバイル端末２０ａのユーザが、ＧＰＳ部２１ａのデータ改ざん等を行った場合、上記、ビーコン装置５０ａの示す設置位置と、モバイル端末２０ａの現在位置との比較によっては異常度を正しく算出できない可能性がある。このような場合、チェックイン履歴を用いた異常度の算出が有効である。

また、異常度の算出においては、店舗３０ａに設置されたビーコン装置５０ａ〜５０ｎのうち、ビーコン装置５０ａ以外のビーコン装置（例えば、ビーコン装置５０ｎ）のデバイスＩＤの受信日時からなる第二チェックイン履歴が用いられてもよい。具体的には、ビーコン制御部８３は、第一チェックイン履歴と、第二チェックイン履歴とを比較することにより、異常度を算出してもよい。

上述のように、ビーコン制御部８３は、複数のモバイル端末のそれぞれから送信されるビーコン装置５０ａ以外のビーコン装置のビーコンＩＤの受信日時を第二チェックイン履歴として管理（サーバ記憶部１６に記憶）している。ここで、第二チェックイン履歴を構成するチェックインの数の分布と、第一チェックイン履歴を構成するチェックイン数の分布とが大きく異なる場合、ビーコン装置５０ａは、他のビーコン装置と利用のされ方が異なるものと考えられる。つまり、ビーコン装置５０ａは、店舗３０ａ以外の場所に設置されて不正に利用されていると判断できる。

例えば、ビーコン制御部８３は、第一チェックイン履歴を構成するチェックインの数の分布と、第二チェックイン履歴を構成するチェックイン数の分布との類似度を算出し、算出した類似度が低いほど異常度が高いと算出する。なお、類似度の算出には、公知の手法が用いられる。

また、上述のように第一チェックイン履歴には、アプリユーザＩＤが含まれるが、同一のアプリユーザＩＤの数に基づいて異常度が算出されてもよい。例えば、ビーコン制御部８３は、第一チェックイン履歴に含まれる同一のアプリユーザＩＤの数に応じて異常度を算出してもよい。

図６６に示されるように、同一のアプリユーザＩＤのチェックインが所定数以上連続する場合や、同一のアプリユーザＩＤのチェックインの割合（頻度）が所定値よりも高い場合が考えられる。図６６は、異常発生時のチェックイン履歴１６２ａの一例を示す図である。図６６に示されるような場合、特定のユーザがビーコン装置５０ａを不正利用していることが疑われる。そこで、このような場合、ビーコン制御部８３は、異常度が高いと算出してもよい。また、ビーコン制御部８３は、例えば、所定期間内に含まれる同一のアプリユーザＩＤの数が多いほど、異常度が高いと算出してもよい。ただし、ビーコン装置５０ａが正常に利用されているが、たまたま特定のユーザのみがその店舗に来店している、という場合も十分に考えられる。このため、所定期間内に含まれる同一のアプリユーザＩＤの数は、上記過去履歴の類似度比較とあわせて、補助的な条件として用いられる。

以上説明したように、異常度の算出には、ビーコン装置５０ａの設置位置とモバイル端末２０ａの現在位置とのずれ、または、チェックイン履歴１６２が用いられる。なお、異常度の算出には、ビーコン装置５０ａの設置位置とモバイル端末２０ａの現在位置とのずれと、チェックイン履歴１６２との両方が用いられてもよい。この場合は、それぞれの手法で異常度が算出された後、算出された異常度の重み付け和が算出されること等により、１つの異常度が決定される。

［異常度に応じた処理］
次に、図６５ＡのステップＳ３２１の異常度に応じた処理について説明する。ビーコン制御部８３は、上述のように算出した異常度に応じた処理を実行する。実施の形態２では、ビーコン制御部８３は、異常度に応じて５種類の処理を行う。図６７は、ビーコン制御部８３の異常度に応じた処理の決定方法のフローチャートである。なお、図６７のフローチャートで使用される異常度の閾値や、閾値の数などは一例である。

まず、ビーコン制御部８３は、算出された異常度が第１の閾値である０．２よりも小さいか否かを判断する（Ｓ３３１）。算出された異常度が０．２よりも小さい場合（Ｓ３３１でＹｅｓ）、ビーコン制御部８３は、ビーコン装置５０ａを用いた報酬付与認証処理（アクション１）を実行する（Ｓ３３２）。

算出された異常度が０．２以上である場合（Ｓ３３１でＮｏ）、ビーコン制御部８３は、算出された異常度が第２の閾値である０．４よりも小さいか否かを判断する（Ｓ３３３）。算出された異常度が０．４よりも小さい場合（Ｓ３３３でＹｅｓ）、ビーコン制御部８３は、ビーコン通信部７３にビーコン装置５０ａとは異なる他のビーコン装置（例えば、ビーコン装置５０ｎ）を用いた報酬付与認証処理（アクション２）を実行する（Ｓ３３４）。

算出された異常度が０．４以上である場合（Ｓ３３３でＮｏ）、ビーコン制御部８３は、算出された異常度が第３の閾値である０．６よりも小さいか否かを判断する（Ｓ３３５）。算出された異常度が０．６よりも小さい場合（Ｓ３３５でＹｅｓ）、ビーコン制御部８３は、報酬付与をペンディングする処理（アクション３）を実行する（Ｓ３３６）。

算出された異常度が０．６以上である場合（Ｓ３３５でＮｏ）、ビーコン制御部８３は、算出された異常度が第４の閾値である０．８よりも小さいか否かを判断する（Ｓ３３７）。算出された異常度が０．８よりも小さい場合（Ｓ３３７でＹｅｓ）、ビーコン制御部８３は、ビーコン装置５０ａの機能を一時停止する処理（アクション４）を実行する（Ｓ３３８）。

算出された異常度が０．８以上である場合（Ｓ３３７でＮｏ）、ビーコン制御部８３は、ビーコン装置５０ａの機能を完全に停止する処理（アクション５）を実行する（Ｓ３３９）。

以下、異常度に応じた各処理の詳細について説明する。

［報酬付与認証処理（アクション１）］
まず、報酬付与認証処理（アクション１）について詳細に説明する。図６８は、報酬付与認証処理のシーケンス図である。報酬付与認証処理は、異常度が低い場合（正常な場合）に行われる所定の処理であり、報酬付与認証処理が完了すると、ゲームアプリ内で使用されるゲーム報酬（例えば、スタンプまたはアイテム）がデータ上で付与される。

まず、サーバ１０ａのビーコン制御部８３は、ビーコン装置５０ａ及びモバイル端末２０ａにアクション１を指示する制御信号と、乱数（ワンタイムパスワード）とを生成する。なお、乱数は、通信の傍受（盗聴）に対する対策に用いられる。

ビーコン制御部８３は、生成した制御信号及び乱数を、ビーコン装置５０ａが有する鍵情報５１ａに対応した鍵情報８６ａによって暗号化した暗号化信号をビーコン通信部７３に送信する（Ｓ３４１）。

モバイル端末２０ａのビーコン通信部７３は、ビーコン制御部８３から暗号化信号を受信するが、モバイル端末２０ａ内には鍵情報５１ａが記憶されていない。つまり、ビーコン通信部７３は、暗号化信号を復号することができない。よって、ビーコン通信部７３は、受信した暗号化信号をそのままビーコン装置５０ａに送信する（Ｓ３４２）。

ビーコン装置５０ａは、受信した暗号化信号を鍵情報５１ａで復号し（Ｓ３４３）、制御信号と乱数とを取得する。そして、ビーコン装置５０ａは、制御信号が示すアクション１の指示にしたがって当該指示を含む応答信号をビーコン通信部７３に送信する（Ｓ３４４）。このとき、ビーコン装置５０ａは、鍵情報５１ａによって暗号化信号を復号することによって得られる乱数を当該鍵情報５１ａによって再度暗号化し、応答信号に含めて送信する。

応答信号を受信したビーコン通信部７３は、応答信号に含まれるアクション１の指示にしたがって、暗号化された乱数を含む報酬付与要求をビーコン制御部８３に送信する（Ｓ３４５）。

ビーコン制御部８３は、報酬付与要求を受信し、乱数を確認して報酬を付与するための処理を行う（Ｓ３４６）。より具体的には、ビーコン制御部８３は、まず、暗号化された乱数を鍵情報８６ａによって復号し、復号の結果得られる乱数が、ステップＳ３４１においてビーコン制御部８３が送信した乱数と一致するかどうかを確認する。そして、一致した場合には、報酬を付与するための処理を開始する。

ここで、報酬を付与するための処理は、図４０で説明した報酬画面の生成と同様の処理や、図４４で説明した報酬情報生成処理と同様の処理であり、リワード制御部８４によって行われる。この結果、ゲームアプリ内で使用されるゲーム報酬（例えば、スタンプまたはアイテム）がデータ上で付与される。

このように、ビーコン制御部８３は、算出された異常度が所定値（ここでは、０．２）よりも低い場合、モバイル端末２０ａに報酬を付与するための所定の処理を行う。

［他のビーコン装置を用いた報酬付与認証処理（アクション２）］
次に、他のビーコン装置を用いた報酬付与認証処理（アクション２）について詳細に説明する。図６９は、他のビーコン装置を用いた報酬付与認証処理のシーケンス図である。なお、図６９では、図６８と実質的に同一のステップについては図６８と同様の符号が付され、説明が簡略化される。

上述のように、店舗３０ａには複数のビーコン装置が設置されているため、ビーコン装置５０ａの不正利用が疑われる場合には、ビーコン装置５０ａ以外の他のビーコン装置（ここでは、ビーコン装置５０ｎ）を用いて報酬付与認証処理を行う。これにより、ビーコン装置５０ａが盗難されているような場合には、報酬付与認証処理が実施できないため、不正なゲーム報酬の取得を抑制できる。

まず、サーバ１０ａのビーコン制御部８３は、アクション２を指示する制御信号及び乱数を含む暗号化信号をビーコン通信部７３に送信する（Ｓ３４１）。ビーコン通信部７３は、受信した暗号化信号をそのままビーコン装置５０ａに送信する（Ｓ３４２）。

ビーコン装置５０ａは、受信した暗号化信号を鍵情報５１ａで復号し（Ｓ３４３）、制御信号と乱数とを取得する。そして、ビーコン装置５０ａは、制御信号が示すアクション２の指示にしたがって当該指示と再度暗号化された乱数とを含む応答信号をビーコン通信部７３に送信する（Ｓ３４４）。

ここで、応答信号を受信したビーコン通信部７３は、応答信号に含まれるアクション２の指示（ビーコン装置５０ｎとの通信指示）にしたがって、暗号化された乱数を含む再認証要求をビーコン制御部８３に送信する（Ｓ３５１）。

ビーコン制御部８３は、再認証要求を受信し、乱数を確認して暗号化信号を再度送信する（Ｓ３５２）。具体的には、ビーコン制御部８３は、ビーコン装置５０ｎ及びモバイル端末２０ａにアクションを指示する制御信号と、乱数とを生成し、生成した制御信号及び乱数を含む、鍵情報８６ｎによって暗号化した暗号化信号をビーコン通信部７３に送信する（Ｓ３５２）。ビーコン通信部７３は、受信した暗号化信号をそのままビーコン装置５０ｎに送信する（Ｓ３５３）。

ビーコン装置５０ｎは、受信した暗号化信号を鍵情報５１ｎで復号し（Ｓ３５４）、制御信号と乱数とを取得する。そして、ビーコン装置５０ｎは、制御信号が示すアクションの指示にしたがって当該指示と再度暗号化された乱数とを含む応答信号をビーコン通信部７３に送信する（Ｓ３５５）。

応答信号を受信したビーコン通信部７３は、応答信号に含まれるアクションの指示にしたがって、暗号化された乱数を含む報酬付与要求をビーコン制御部８３に送信する（Ｓ３５６）。

ビーコン制御部８３は、報酬付与要求を受信し、乱数を確認して報酬を付与するための処理を行う（Ｓ３５７）。より具体的には、ビーコン制御部８３は、まず、暗号化された乱数を鍵情報８６ｎによって復号し、復号の結果得られる乱数が、ステップＳ３５２においてビーコン制御部８３が送信した乱数と一致するかどうかを確認する。そして、一致した場合には、報酬を付与するための処理を開始する。

このように、ビーコン制御部８３は、算出された異常度が所定値（ここでは、０．２）以上の場合に、ビーコン装置５０ａとは異なるビーコン装置５０ｎからのビーコン信号（応答信号）の取得をモバイル端末２０ａに指示する処理を行う。

これにより、ビーコン装置５０ａが盗難されているような場合には、モバイル端末２０ａは、ビーコン装置５０ａからのビーコン信号を受信できないため、ビーコン装置５０ａの不正な利用を抑制できる。

なお、ビーコン装置５０ａとは異なるビーコン装置の選択方法は、特に限定されるものではない。例えば、ビーコン制御部８３は、ビーコン装置の設置位置情報を参照し、ビーコン装置５０ａに最も近接するビーコン装置を選択してもよい。また、ビーコン制御部８３は、ビーコン装置の設置位置情報を参照し、ビーコン装置５０ａ近傍のビーコン装置群の中からランダムにビーコン装置を選択してもよい。

［報酬付与をペンディングする処理（アクション３）］
次に、報酬付与をペンディングする処理（アクション３）について詳細に説明する。図７０は、報酬付与をペンディングする処理のシーケンス図である。なお、図７０では、図６８と実質的に同一のステップについては図６８と同様の符号が付され、説明が簡略化される。

報酬付与をペンディングする処理においては、ビーコン装置５０ａの不正利用が疑われる場合に、報酬を付与するための処理の開始をペンディング状態とする。ペンディング状態の間、店舗３０ａにて、店員がビーコン装置５０ａの状態を実際に確認し、正常であることが確認された場合に、報酬を付与するための処理が開始される。

まず、サーバ１０ａのビーコン制御部８３は、ビーコンＩＤ情報１６１におけるビーコン装置５０ａのデバイスＩＤに対応する不正フラグを「ペンディング」に設定した後（Ｓ３６０）、アクション３の動作を指示する制御信号及び乱数を含む暗号化信号をビーコン通信部７３に送信する（Ｓ３４１）。ビーコン通信部７３は、受信した暗号化信号をそのままビーコン装置５０ａに送信する（Ｓ３４２）。

ビーコン装置５０ａは、受信した暗号化信号を鍵情報５１ａで復号し（Ｓ３４３）、制御信号と乱数とを取得する。そして、ビーコン装置５０ａは、制御信号が示すアクション３の指示にしたがって当該指示と再度暗号化された乱数とを含む応答信号をビーコン通信部７３に送信する（Ｓ３４４）。

ここで、応答信号を受信したビーコン通信部７３は、応答信号に含まれるアクション３の指示にしたがって、表示部にメッセージ１を表示する（Ｓ３６１）。図７１は、メッセージ１が表示されたモバイル端末２０ａの模式図である。

図７１に示されるように、メッセージ１では、報酬の付与がペンディングされる旨がメッセージとして表示される。

ここで、ビーコン通信部７３は、さらに、上記アクション３の指示にしたがって、暗号化された乱数を含む報酬付与要求をビーコン制御部８３に送信する（Ｓ３６２）。

ビーコン制御部８３は、報酬付与要求を受信し、乱数を確認した上で報酬を付与するための処理をペンディング状態とする（Ｓ３６３）。ここで、ペンディング状態の解除（報酬を付与するための処理の開始）は、例えば、ビーコン装置５０ａが正常であることを確認した店員がＰＣ６０を通じてその旨をビーコン制御部８３に通知することにより行われる。なお、正常動作が確認された場合は、ビーコン制御部８３は、ビーコンＩＤ情報１６１におけるビーコン装置５０ａのデバイスＩＤに対応する不正フラグを「なし」にリセットする。

このように、ビーコン制御部８３は、算出された異常度が所定値（ここでは、０．４）以上の場合、報酬を付与するための所定の処理を保留する処理を行う。これにより、ビーコン装置５０ａの状態を確認した上で、報酬を付与するための所定の処理を開始することを抑制できる。

［ビーコン装置の機能を一時停止する処理（アクション４）］
次に、ビーコン装置５０ａの機能を一時停止する処理（アクション４）について詳細に説明する。図７２は、ビーコン装置５０ａの機能を一時停止する処理のシーケンス図である。なお、図７２では、図６８と実質的に同一のステップについては図６８と同様の符号が付され、説明が簡略化される。

ビーコン装置５０ａの機能を一時停止する処理は、異常度が比較的高い場合に行われる処理である。

まず、サーバ１０ａのビーコン制御部８３は、ビーコンＩＤ情報１６１におけるビーコン装置５０ａのデバイスＩＤに対応する不正フラグを「一時停止」に設定した後（Ｓ３７０）、アクション４を指示する制御信号を含む暗号化信号をビーコン通信部７３に送信する（Ｓ３４１）。ビーコン通信部７３は、受信した暗号化信号をそのままビーコン装置５０ａに送信する（Ｓ３４２）。

ビーコン装置５０ａは、受信した暗号化信号を鍵情報５１ａで復号し（Ｓ３４３）、制御信号を取得する。そして、ビーコン装置５０ａは、制御信号が示すアクション４の指示にしたがって当該指示を含む応答信号をビーコン通信部７３に送信する（Ｓ３４４）。

ここで、応答信号を受信したビーコン通信部７３は、応答信号に含まれるアクション４の指示にしたがって、表示部にメッセージ２を表示する（Ｓ３７１）。図７３は、メッセージ２が表示されたモバイル端末２０ａの模式図である。

図７３に示されるように、メッセージ２では、デバイスの機能が一時停止する旨がメッセージとして表示される。

一方、ビーコン装置５０ａは、ステップＳ３４４において応答信号を送信した後、アクション４の指示にしたがって機能を一時停止する（Ｓ３７２）。ビーコン装置５０ａは、具体的には、ビーコン信号の送信を停止する。なお、この場合、ビーコン装置５０ａは、ビーコン装置５０ａの管理者等による所定の復帰処置が行われることにより、再稼動が可能である。管理者による復帰処置の実施後、ビーコン制御部８３は、ビーコンＩＤ情報１６１におけるビーコン装置５０ａのデバイスＩＤに対応する不正フラグを「なし」にリセットする。

このように、ビーコン制御部８３は、算出された異常度が所定値（ここでは、０．６）以上の場合、ビーコン装置５０ａの機能を一時的に停止させるための情報を、モバイル端末２０ａを介してビーコン装置５０ａに送信する処理を行う。これにより、ビーコン装置５０ａが不正に利用されることを抑制できる。

［ビーコン装置の機能を完全に停止する処理（アクション５）］
次に、ビーコン装置５０ａの機能を完全に停止する処理（アクション５）について詳細に説明する。図７４は、ビーコン装置５０ａの機能を完全に停止する処理のシーケンス図である。なお、図７４では、図６８と実質的に同一のステップについては図６８と同様の符号が付され、説明が簡略化される。

ビーコン装置５０ａの機能を完全停止する処理は、異常度が非常に高い場合に行われる処理である。

まず、サーバ１０ａのビーコン制御部８３は、ビーコンＩＤ情報１６１におけるビーコン装置５０ａのデバイスＩＤに対応する不正フラグを完全停止に設定した後（Ｓ３８０）、アクション５を指示する制御信号を含む暗号化信号をビーコン通信部７３に送信する（Ｓ３４１）。ビーコン通信部７３は、受信した暗号化信号をそのままビーコン装置５０ａに送信する（Ｓ３４２）。

ビーコン装置５０ａは、受信した暗号化信号を鍵情報５１ａで復号し（Ｓ３４３）、制御信号を取得する。そして、ビーコン装置５０ａは、制御信号が示すアクション５の指示にしたがってビーコン装置５０ａ内に保持（記憶）された鍵情報５１ａを削除して、機能を完全に停止させる（Ｓ３８１）。なお、この場合、ビーコン装置５０ａの再稼動は不可能である。

ここで、ビーコン通信部７３は、ステップＳ３４２で暗号化信号を送信してから所定期間以上応答信号を受信できない場合、表示部にメッセージ３を表示する（Ｓ３８２）。図７５は、メッセージ３が表示されたモバイル端末２０ａの模式図である。

図７５に示されるように、メッセージ３では、処理に失敗した旨がメッセージとして表示される。

このように、ビーコン制御部８３は、算出された異常度が所定値（ここでは、０．８）以上の場合、ビーコン装置５０ａの機能を完全に停止させるための情報を、モバイル端末２０ａを介してビーコン装置５０ａに送信する処理を行う。ここで、ビーコン装置５０ａの機能を停止させるための情報は、ビーコン装置５０ａが保持している鍵情報５１ａによって復号可能な、暗号化された情報である。そして、ビーコン装置５０ａの機能を停止させるための情報は、ビーコン装置５０ａが保持する鍵情報５１ａを削除するための情報を含む。

これにより、鍵情報５１ａが流出する可能性を低減し、ゲーム報酬付与システム１００ａの不正利用を抑制することができる。

［まとめ］
以上、実施の形態２に係るゲーム報酬付与システム１００ａを用いた情報処理方法について説明した。実施の形態２に係る情報処理方法においては、サーバ１０ａは、ビーコン装置５０ａからビーコン信号を受信したモバイル端末２０ａから、モバイル端末２０ａの現在位置を示す現在位置情報を取得する。また、サーバ１０ａは、取得された現在位置情報と、サーバ１０ａによって予め管理されている設置位置情報（ビーコンＩＤ情報）であってビーコン装置５０ａの設置位置を示す設置位置情報とを比較することにより、ビーコン装置５０ａの異常度を算出する。そして、サーバ１０ａは、算出された異常度に応じた処理を行う。

このような情報処理方法においては、モバイル端末２０ａが有するＧＰＳ部２１ａを利用して、ビーコン装置５０ａの異常度が算出される。異常度の算出の対象となるビーコン装置５０ａには、ＧＰＳモジュールが搭載される必要はなく、ビーコン装置５０ａの簡素化（低消費電力化）が実現される。

また、このような情報処理方法によれば、ビーコン装置の異常度に応じて、ビーコン装置の不正利用を抑制するための処理を行うことができる。

［実施の形態２の変形例］
上記実施の形態２では、ビーコンＩＤ情報１６１（設置位置情報）は、サーバ１０ａが備えるサーバ記憶部１６に記憶された。しかしながら、ビーコンＩＤ情報１６１は、サーバ１０ａの外部に設けられた記憶装置から取得されてもよい。なお、ビーコンＩＤ情報１６１は、ビーコン装置５０ａ〜５０ｎから送信される情報ではなく、予めサーバ１０ａの管理者またはビーコン装置５０ａ〜５０ｎの管理者によってサーバ記憶部１６に登録されている情報である。

また、本開示の技術は、ゲーム報酬付与システム１００ａとして実現されてもよいし、サーバ１０ａとして実現されてもよい。また、本開示の技術は、モバイル端末２０ａに適用されるアプリケーションや、ゲームアプリ（ゲーム部２３）に適用されるＳＤＫ（ＳＤＫ部２４ａ）として実現されてもよい。

また、本開示の情報処理方法は、ゲーム報酬付与システム１００ａ以外のシステム（例えばゲームに関連しない他のシステム）にも適用可能である。

（その他の実施の形態）
以上のように、本出願において開示する技術の例示として、実施の形態１及び２を説明した。しかしながら、本開示における技術は、これに限定されず、適宜、変更、置き換え、付加、省略などを行った実施の形態にも適用可能である。また、上記実施の形態１及び２で説明した各構成要素を組み合わせて、新たな実施の形態とすることも可能である。

例えば、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。

また、上記各実施の形態において、特定の処理部が実行する処理を別の処理部が実行してもよい。また、複数の処理の順序が変更されてもよいし、複数の処理が並行して実行されてもよい。

以上、一つまたは複数の態様に係る情報提供方法及び情報処理方法について、実施の形態に基づいて説明したが、本開示は、この実施の形態に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。

本開示の技術は、ビーコン装置の不正利用を抑制するための情報処理方法に適用できる。また、本開示の技術は、ビーコン装置の異常度に応じて、ビーコン装置の不正利用を抑制するための処理を行うことができ、ビーコン装置との通信に基づいてゲームアプリ内で使用されるゲーム報酬を付与するゲーム報酬付与システム等に適用できる。

１０、１０ａ サーバ
１１、１１ａ サーバ制御部
１３ 店舗情報ＤＢ
１４ ゲームアプリ情報ＤＢ
１５ ユーザ情報ＤＢ
１６ サーバ記憶部
２０、２０ａ モバイル端末
２１ 制御部
２１ａ ＧＰＳ部
２１ｂ 無線通信部
２２ 記憶部
２３ ゲーム部
２４、２４ａ ＳＤＫ部
２５ サーバ情報ＤＢ
２６ ＯＳ
２７ａ ログイン画面
２７ｂ ゲーム画面
２７ｃ スタンプシート画面
２７ｄ アイテム付与画面
２８ａ ゲーム固有画像
２８ｂ 店舗コラボ画像
２８ｃ スタンプ数表示部
２８ｄ メッセージ表示部
２９ 部品要求
２９ａ、３１ａ、３３ａ、３８ａ、４１ａ、４３ａ、４５ａ、４７ａ アプリユーザＩＤ
２９ｂ、３１ｂ、３３ｂ、３８ｂ、４１ｂ、４３ｂ、４５ｂ、４７ｂ アプリＩＤ
２９ｃ、３１ｃ アクション
３０、３０ａ 店舗
３１ ログイン要求
３１ｄ ユーザ名
３１ｅ パスワード
３２ａ、３２ｂ、３２ｃ、３４ａ、３９ａ、３９ｂ、４６ａ、４８ａ 応答
３３ 店舗コラボ情報要求
３４ 店舗コラボ情報
３４ｂ、１５２ｃ スタンプ数
３４ｃ、３６ｆ メッセージ
３４ｄ ゲーム側報酬付与情報
３５ サーバ情報
３８ 報酬付与判定要求
３８ｃ 達成度
３９、４８ 報酬付与情報
４０ ネットワーク
４１ 報酬画面情報要求
４２ａ、４２ｂ、４２ｃ 報酬画面情報
４２ｄ ゲーム側報酬付与情報
４３ 報酬情報要求
４３ｃ ギフトＩＤ
４４ 報酬情報
４５ 近隣店舗判定要求
４５ｃ、４７ｃ 位置情報
４６ 近隣店舗情報
４７ チェックイン要求
４７ｄ、１５３ｃ 店舗ＩＤ
５０ａ、５０ｎ ビーコン装置
５１ａ、５１ｎ、８６ａ、８６ｎ 鍵情報
６０ ＰＣ
７１ 情報収集部
７２ 広告表示部
７３ ビーコン通信部
７４ リワード付与部
８１ 情報取得部
８２ 広告配信部
８３ ビーコン制御部
８４ リワード制御部
８５ 広告指定受付部
１００、１００ａ ゲーム報酬付与システム
１３１、１３１ａ、１３１ｂ、１３１ｃ、１３１ｄ、１３１ｅ 店舗属性情報
１３２、１３２ａ 広告情報
１３３、１３３ａ 購入者特典情報
１４１、１４１ａ スタンプ情報
１４２、１４２ａ ゲーム属性情報
１４２ｂ ジャンル
１４２ｃ 開発者
１４３、１４３ａ 報酬付与条件情報
１４３ｂ 報酬ＩＤ
１４４、１４４ａ 報酬一覧情報
１４５、１４５ａ 報酬出現確率情報
１４６、１４６ａ 購入者特典報酬情報
１５１ ユーザログイン情報
１５１ａ ユーザＩＤ
１５２、１５２ｆ ユーザ達成度情報
１５２ａ ユーザＩＤ
１５２ｂ スタンプシート
１５２ｄ レベル
１５３ ユーザチェックインログ
１５３ａ、１５３ｂ チェックイン情報
１５４ ユーザ達成度ログ
１５４ａ ユーザ達成度ログ情報
１５５、１５５ａ ユーザ報酬付与情報
１６１ ビーコンＩＤ情報
１６２、１６２ａ チェックイン履歴

Claims (14)

1. サーバ装置が実行する情報処理方法であって、
   第一ビーコン装置から前記第一ビーコン装置の識別情報である第一ＩＤを含むビーコン信号を受信した第一携帯端末から、前記第一ＩＤ及び当該第一携帯端末のＧＰＳ部により取得された当該第一携帯端末の現在位置を示す第一位置情報を取得する取得ステップと、
   取得された前記第一位置情報と、前記サーバ装置によって予め管理されている第二位置情報であって前記第一ビーコン装置の設置位置を示す前記第二位置情報とを比較することにより、前記第一ビーコン装置の異常度を算出する算出ステップと、
   算出された前記異常度に応じた処理を行う処理ステップとを含む
   情報処理方法。
2. 前記算出ステップにおいては、前記第一位置情報が示す現在位置と、前記第二位置情報が示す設置位置との差が大きいほど、前記異常度を高く算出する
   請求項１に記載の情報処理方法。
3. 前記情報処理方法は、さらに、複数の第二携帯端末のそれぞれが前記第一ビーコン装置から受信したビーコン信号に含まれる前記第一ＩＤの受信日時を第一チェックイン履歴として管理する第一管理ステップを含み、
   前記算出ステップにおいては、前記第一チェックイン履歴をさらに用いて前記異常度を算出する
   請求項１または２に記載の情報処理方法。
4. 前記算出ステップにおいては、前記第一位置情報の取得をしたときの前記第一チェックイン履歴と、前記第一位置情報の取得をしたときよりも前の前記第一チェックイン履歴とを比較することにより、前記異常度を算出する
   請求項３に記載の情報処理方法。
5. 前記第一管理ステップにおいては、前記複数の第二携帯端末のそれぞれから送信される前記第一ＩＤの受信日時を、当該第一ＩＤを送信した前記第二携帯端末から送信されるユーザＩＤと対応付けて前記第一チェックイン履歴として管理し、
   前記算出ステップにおいては、前記第一チェックイン履歴に含まれる同一のユーザＩＤの数に応じて前記異常度を算出する
   請求項３に記載の情報処理方法。
6. 前記情報処理方法は、さらに、複数の第三携帯端末のそれぞれが前記第一ビーコン装置とは異なる第二ビーコン装置から受信したビーコン信号に含まれる第二ＩＤの受信日時を第二チェックイン履歴として管理する第二管理ステップを含み、
   前記算出ステップにおいては、前記第一チェックイン履歴と、前記第二チェックイン履歴とを比較することにより、前記異常度を算出する
   請求項３に記載の情報処理方法。
7. 前記処理ステップにおいては、算出された前記異常度が所定値以上の場合に、前記第一ビーコン装置とは異なる第三ビーコン装置からのビーコン信号の取得を前記第一携帯端末に指示する前記処理を行う
   請求項１〜６のいずれか１項に記載の情報処理方法。
8. 前記処理ステップにおいては、算出された前記異常度が所定値よりも低い場合、前記第一携帯端末に関する所定の処理を行い、算出された前記異常度が所定値以上の場合、前記所定の処理を保留する
   請求項１〜６のいずれか１項に記載の情報処理方法。
9. 前記第一携帯端末には、前記サーバ装置によってデータが管理されるゲームのアプリケーションがインストールされ、
   前記所定の処理は、前記ゲーム内で使用されるゲーム報酬を前記データ上で付与する処理である
   請求項８に記載の情報処理方法。
10. 前記処理ステップにおいては、算出された前記異常度が所定値以上の場合、前記第一ビーコン装置の機能を停止させるための情報を、前記第一携帯端末を介して前記第一ビーコン装置に送信する前記処理を行う
    請求項１〜６のいずれか１項に記載の情報処理方法。
11. 前記第一ビーコン装置の機能を停止させるための情報は、前記第一ビーコン装置が保持する鍵情報によって復号可能な、暗号化された情報である
    請求項１０に記載の情報処理方法。
12. 前記第一ビーコン装置の機能を停止させるための情報は、前記第一ビーコン装置が保持する前記鍵情報を削除するための情報を含む
    請求項１１に記載の情報処理方法。
13. 前記第二位置情報は、前記サーバ装置が備える記憶部に記憶されている
    請求項１〜１２のいずれか１項に記載の情報処理方法。
14. 前記取得ステップ、前記算出ステップ、および前記処理ステップの少なくとも１つは、前記サーバ装置が備えるプロセッサにより行われる
    請求項１に記載の情報処理方法。

Images