JP2008186419A - 利用状況管理装置および電子マネーシステム - Google Patents

Abstract

【課題】不正の疑いのある記録媒体を抽出すること。
【解決手段】利用状況管理装置によって、複数の店舗において利用可能な記録媒体に記憶されている電子マネーの利用履歴として、電子マネーが利用された店舗の店舗識別情報と、利用された利用日と利用時刻と、利用された記録媒体の記録媒体識別情報とが対応付けて管理され、複数の店舗の所在地域を特定可能な所在地情報が管理され、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における利用履歴それぞれの店舗識別情報で示される店舗について管理されている所在地情報に基づいて、当該利用履歴の利用時刻が異常であるか否かが判定され（Ｓ２０８３〜Ｓ２１８３）、利用履歴が異常であると判定されたこと（Ｓ２１８３でＹＥＳ）を条件として、当該利用履歴の記録媒体識別情報が報知される（Ｓ２１８４）。
【選択図】図４６

Description

本発明は、利用状況管理装置および電子マネーシステムに関する。詳しくは、複数の店舗において利用可能で記録媒体に記憶されている電子マネーの利用履歴として、電子マネーが利用された店舗の店舗識別情報と、利用された利用日と利用時刻と、利用された記録媒体の記録媒体識別情報とを対応付けて管理する利用履歴管理手段を有する利用状況管理装置と、複数の店舗に設置され、前記記録媒体に記憶されている電子マネーを用いて取引処理を実行する取引処理実行手段を有する取引装置と、当該取引装置での電子マネーの利用情報を前記利用状況管理装置に送信する利用情報送信手段を有する取引装置管理装置とを含む電子マネーシステム、および、利用状況管理装置に関する。

従来、電子マネーの流通状況と利用履歴を把握でき、ユーザカードと１対１に対応したマネー口座を管理するイシュア（電子マネーの発行組織体（団体、企業等））サーバがあった（たとえば、特許文献１）。このようなイシュアサーバによれば、マネー口座から、現在ユーザカードにどの位の電子マネーが記憶され、あるいは利用されているかを把握できるようにされていた。
特開２００６−８５７２３号公報（第００３２段落）

複数の店舗で共通に利用できる電子マネーにおいては、不正を行なおうとする者にとっては、単一店舗限定の電子マネーに比べ、利用範囲が広いため、電子マネーのデータのデッドコピーなどの複製をすることによるメリットが大きいことから不正対象として狙われやすく、不正は集団で行なわれることも考えられる。しかし、特許文献１に記載の技術では、集団による不正が行なわれていることまでは判断できないといった問題があった。

この発明はかかる事情に鑑み考え出されたものであり、その目的の１つは、不正の疑いのある記録媒体を抽出することが可能な利用状況管理装置および電子マネーシステムを提供することである。

課題を解決するための手段の具体例およびその効果

（１） 複数の店舗（たとえば、遊技場３０）において利用可能な記録媒体（たとえば、携帯電話１００）に記憶されている電子マネー（たとえば、バリュー）の利用履歴として、電子マネーが利用された店舗の店舗識別情報（たとえば、店舗ＩＤ）と、利用された利用日（たとえば、利用日）と利用時刻（たとえば、利用時刻）と、利用された記録媒体の記録媒体識別情報（たとえば、携帯端末情報）とを対応付けて管理する利用履歴管理手段（たとえば、データ処理部２１０、残高管理ＡＰ２１４、図４５のステップＳ２９２、記憶部２２０、図６の取引情報ＤＢ２２４）を有する利用状況管理装置（たとえば、電子マネー管理サーバ２００）であって、
複数の前記店舗の所在地域を特定可能な所在地情報（たとえば、住所、最寄駅、または、郵便番号）を管理する所在地情報管理手段（たとえば、記憶部２２０、図４７の店舗ＤＢ）と、
前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報に基づいて、当該利用履歴の利用時刻が異常であるか否かを判定する利用履歴判定手段（たとえば、データ処理部２１０、図４６のステップＳ２０８３からステップＳ２１８３まで，図５５のステップＳ２０８３からステップＳ２１８３ａまで，図５６のステップＳ２０８３ａからステップＳ２１８３ｂまで）と、
該利用履歴判定手段によって利用履歴が異常であると判定されたこと（たとえば、ステップＳ２１８３，ステップＳ２１８３ａ，ステップＳ２１８３ｂでＹＥＳの場合）を条件として、当該利用履歴の記録媒体識別情報を報知する異常記録媒体報知手段（たとえば、データ処理部２１０、図４６，図５５のステップＳ２１８４，図５６のステップＳ２１８４ｂ）とを備える。

このような構成によれば、利用状況管理装置によって、複数の店舗において利用可能な記録媒体に記憶されている電子マネーの利用履歴として、電子マネーが利用された店舗の店舗識別情報と、利用された利用日と利用時刻と、利用された記録媒体の記録媒体識別情報とが対応付けて管理され、複数の店舗の所在地域を特定可能な所在地情報が管理され、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における利用履歴それぞれの店舗識別情報で示される店舗について管理されている所在地情報に基づいて、当該利用履歴の利用時刻が異常であるか否かが判定され、利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報が報知される。

このため、利用状況管理装置によって、利用履歴が異常であると判定された記録媒体、つまり、不正の疑いのある記録媒体の記録媒体識別情報が報知される。その結果、不正の疑いのある記録媒体を抽出することができる。

（２） 前記利用履歴判定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報に基づいて、先に利用された店舗から後に利用された店舗に到着する推定到着時刻（たとえば、推定到着時刻）を特定する到着時刻特定手段（たとえば、データ処理部２１０、図４６のステップＳ２０８３からステップＳ２１８２まで）と、前記対象利用履歴のうち後に利用された店舗の利用履歴の利用時刻が、前記到着時刻特定手段によって特定された推定到着時刻より前であるか否かを判定する利用時刻判定手段（たとえば、データ処理部２１０、図４６のステップＳ２１８３）とを含み、該利用時刻判定手段によって後に利用された店舗の利用履歴の利用時刻が推定到着時刻より前であると判定されたこと（たとえば、ステップＳ２１８３でＹＥＳの場合）を条件として、当該利用履歴が異常であると判定する。

このような構成によれば、利用状況管理装置によって、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について管理されている所在地情報に基づいて、先に利用された店舗から後に利用された店舗に到着する推定到着時刻が特定され、対象利用履歴のうち後に利用された店舗の利用履歴の利用時刻が、特定された推定到着時刻より前であるか否かが判定され、後に利用された店舗の利用履歴の利用時刻が推定到着時刻より前であると判定されたことを条件として、当該利用履歴が異常であると判定される。このため、所在地情報に基づいて、後に利用された店舗の利用履歴の利用時刻が後の店舗への推定到着時刻より前であるか否かが効率よく確実に判断できる。その結果、効率よく確実に不正の疑いのある記録媒体を抽出することができる。

（３） 前記到着時刻特定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報に基づいて、先に利用された店舗の所在地から後に利用された店舗の所在地までの推定移動時間を特定し（たとえば、データ処理部２１０、および、図４６のステップＳ２０８３からステップＳ２１８１まで）、特定した推定移動時間を先に利用された店舗の利用履歴の利用時刻に加算することにより、推定到着時刻を特定する（たとえば、データ処理部２１０、図４６のステップＳ２１８２）。

このような構成によれば、利用状況管理装置によって、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について管理されている所在地情報に基づいて、先に利用された店舗の所在地から後に利用された店舗の所在地までの推定移動時間が特定され、特定された推定移動時間が先に利用された店舗の利用履歴の利用時刻に加算されることにより、推定到着時刻が特定される。このため、所在地情報に基づいて、後に利用された店舗への推定到着時刻が効率よく確実に特定される。その結果、さらに効率よく確実に不正の疑いのある記録媒体を抽出することができる。

（４） 前記利用履歴判定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報で特定される所在地域間の推定移動時間（たとえば、推定移動時間）を特定する移動時間特定手段（たとえば、データ処理部２１０、図５５のステップＳ２０８３からステップＳ２１８１ａまで）と、前記対象利用履歴の利用時刻差が、前記移動時間特定手段によって特定された推定移動時間より短いか否かを判定する利用時刻差判定手段（たとえば、データ処理部２１０、図４６のステップＳ２１８３ａ）とを含み、該利用時刻差判定手段によって対象利用履歴の利用時刻差が推定移動時間より短いと判定されたこと（たとえば、ステップＳ２１８３ａでＹＥＳの場合）を条件として、当該対象利用履歴が異常であると判定する。

このような構成によれば、利用状況管理装置によって、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について管理されている所在地情報で特定される所在地域間の推定移動時間が特定され、対象利用履歴の利用時刻差が、特定された推定移動時間より短いか否かが判定され、対象利用履歴の利用時刻差が推定移動時間より短いと判定されたことを条件として、当該対象利用履歴が異常であると判定される。このため、所在地情報に基づいて、対象利用履歴の利用時刻差が推定移動時間より短いか否かが効率よく確実に判断できる。その結果、効率よく確実に不正の疑いのある記録媒体を抽出することができる。

（５） 前記利用履歴判定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ利用履歴それぞれの店舗識別情報で示される店舗が３つ以上あることを条件として、利用が連続する２つの店舗における利用履歴だけでなく、利用が連続しない２つの店舗における利用履歴についても、利用履歴が異常であるか否かを判定する（たとえば、データ処理部２１０、図５６のステップＳ２０８３ａからステップＳ２１８３ｂまで）。

このような構成によれば、利用状況管理装置によって、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ利用履歴それぞれの店舗識別情報で示される店舗が３つ以上あることを条件として、利用が連続する２つの店舗における利用履歴だけでなく、利用が連続しない２つの店舗における利用履歴についても、利用履歴が異常であるか否かが判定される。

このため、連続しない２つの店舗（たとえば、Ａ店およびＣ店）における利用履歴の間の利用履歴（たとえば、Ａ店、Ｂ店およびＣ店の順で利用履歴があるときのＢ店における利用履歴）が異常である場合であっても、当該連続しない２つの店舗における利用履歴が異常であるか否かが判定できる。その結果、不正の疑いのある記録媒体を洩れなく抽出することができる。

（６） 前記利用履歴判定手段は、前記対象利用履歴のうち先に利用された店舗での最終の利用履歴と後に利用された店舗での最初の利用履歴とについて、利用履歴が異常であるか否かを判定する（たとえば、図４６，図５５のステップＳ２０８３からステップＳ２０８６までの処理によって、先に利用された店舗での最終の利用履歴と後に利用された店舗での最初の利用履歴とが抽出され、ステップＳ２１８１からステップＳ２１８３までの処理，ステップＳ２１８１ａからステップＳ２１８３ａまでの処理によって、当該２つの利用履歴について異常であるか否かが判断される。また、図５６のステップＳ２０８３ａからステップＳ２１８３ｂまでの処理によって、先に利用された店舗での最終の利用履歴と後に利用された店舗での最初の利用履歴とについて、利用履歴が異常であるか否かが判断される。）。

このような構成によれば、利用状況管理装置によって、対象利用履歴のうち先に利用された店舗での最終の利用履歴と後に利用された店舗での最初の利用履歴とについて、利用履歴が異常であるか否かが判定される。

このため、それぞれの店舗のすべての利用履歴について利用履歴が異常であるか否かを判定する場合と比較して、効率よく、利用履歴が異常であるか否かを判定することができる。

（７） 前記利用履歴判定手段によって利用履歴が異常であると判定されたこと（たとえば、ステップＳ２１８３，ステップＳ２１８３ａ，ステップＳ２１８３ｂでＹＥＳの場合）を条件として、当該利用履歴の記録媒体識別情報で示される記録媒体での電子マネーの利用を停止させるための利用停止情報（たとえば、利用停止情報）を各店舗に送信する利用停止情報送信手段（たとえば、データ処理部２１０、図４６，図５５，図５６のステップＳ２１８５）をさらに備える。

このような構成によれば、利用状況管理装置によって、利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報で示される記録媒体での電子マネーの利用を停止させるための利用停止情報が各店舗に送信される。

このため、利用状況管理装置によって、各店舗において、不正の疑いのある記録媒体での電子マネーの利用を停止させることができる。その結果、不正の疑いのある記録媒体を用いた電子マネーの不正利用の被害の拡大を防止することができる。

（８） （１）から（６）までのいずれかで説明した利用状況管理装置と、複数の店舗に設置され、前記記録媒体に記憶されている電子マネーを用いて取引処理（たとえば、図３９の発券処理，図４２の球貸処理）を実行する取引処理実行手段（たとえば、データ処理部３１０、図３９のステップＳ３１０からステップＳ３６３まで，データ処理部６１０、図４２のステップＳ６１０からステップＳ６６３まで）を有する取引装置（たとえば、券売機３００，カードユニット６００）と、当該取引装置での電子マネーの利用情報を前記利用状況管理装置に送信する利用情報送信手段（たとえば、図５０のステップＳ８１４）を有する取引装置管理装置（たとえば、店舗サーバ８００）とを含む電子マネーシステム（たとえば、電子マネーシステム１０）であって、
前記利用履歴管理手段は、前記取引装置管理装置から送信されてきた利用情報で示される店舗識別情報と利用日と利用時刻と記録媒体識別情報とを利用履歴として管理する（たとえば、図４５のステップＳ２９１，ステップＳ２９２）。

このような構成によれば、電子マネーシステムによって、不正の疑いのある記録媒体を抽出することができる。

（９） 前記利用状況管理装置は、さらに、
前記利用履歴判定手段によって利用履歴が異常であると判定されたこと（たとえば、ステップＳ２１８３，ステップＳ２１８３ａ，ステップＳ２１８３ｂでＹＥＳの場合）を条件として、当該利用履歴の記録媒体識別情報で示される記録媒体での電子マネーの利用を停止させるための利用停止情報（たとえば、利用停止情報）を前記取引装置管理装置に送信する利用停止情報送信手段（たとえば、データ処理部２１０、図４６，図５５，図５６のステップＳ２１８５）を備え
前記取引装置管理装置は、さらに、
前記利用状況管理装置から送信されてきた前記利用停止情報を受信したこと（たとえば、図５０のステップＳ８２７でＹＥＳの場合）を条件として、前記取引装置における前記利用停止情報で示される記録媒体での電子マネーの利用を停止させるための利用停止処理を実行する利用停止処理実行手段（たとえば、図５０のステップＳ８２８）を備える。

このような構成によれば、利用状況管理装置によって、利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報で示される記録媒体での電子マネーの利用を停止させるための利用停止情報が取引装置管理装置に送信され、取引装置管理装置によって、利用状況管理装置から送信されてきた利用停止情報が受信されたことを条件として、取引装置における利用停止情報で示される記録媒体での電子マネーの利用を停止させるための利用停止処理が実行される。

このため、電子マネーシステムによって、各店舗において、不正の疑いのある記録媒体での電子マネーの利用を停止させることができる。その結果、不正の疑いのある記録媒体を用いた電子マネーの不正利用の被害の拡大を防止することができる。

（１０） 記録媒体に記録されている電子マネーの利用履歴として、電子マネーが利用された取引装置（たとえば、券売機３００，カードユニット６００）の取引装置識別情報（たとえば、装置ＩＤ）と、利用された利用時刻（たとえば、利用時刻）と、利用された記録媒体の記録媒体識別情報（たとえば、携帯端末情報）とを対応付けて管理する利用履歴管理手段（たとえば、図５１のステップＳ８３１）を有する利用状況管理装置（たとえば、店舗サーバ８００）をさらに備え、
前記利用状況管理装置は、さらに、
前記利用履歴管理手段によって管理されている利用履歴のうち、取引装置識別情報が異なり記録媒体識別情報が同じで利用が連続する２つの取引装置における利用履歴の利用時刻差が、予め設定された基準時間未満（たとえば、１分３０秒以内，取引装置の位置関係に対応して予め定められた時間未満）であるか否かを判定することによって、当該利用履歴が異常であるか否かを判定する店舗利用履歴判定手段（たとえば、図５１のステップＳ８３４）と、
該店舗利用履歴判定手段によって利用履歴が異常であると判定されたこと（たとえば、ステップＳ８３４でＹＥＳの場合）を条件として、当該利用履歴の記録媒体識別情報を報知する店舗異常記録媒体報知手段（たとえば、図５１のステップＳ８４３）とを備える。

このような構成によれば、利用状況管理装置によって、記録媒体に記録されている電子マネーの利用履歴として、電子マネーが利用された取引装置の取引装置識別情報と、利用された利用時刻と、利用された記録媒体の記録媒体識別情報とが対応付けて管理され、管理されている利用履歴のうち、取引装置識別情報が異なり記録媒体識別情報が同じで利用が連続する２つの取引装置における利用履歴の利用時刻差が、予め設定された基準時間未満であるか否かが判定されることによって、当該利用履歴が異常であるか否かが判定され、利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報が報知される。

このため、電子マネーシステムによって、利用履歴が異常であると判定された記録媒体、つまり、不正の疑いのある記録媒体の記録媒体識別情報が報知される。その結果、不正の疑いのある記録媒体を抽出することができる。

（１１） 前記利用状況管理装置は、さらに、
前記店舗利用履歴判定手段によって利用履歴が異常であると判定されたこと（たとえば、ステップＳ８３４でＹＥＳの場合）を条件として、当該利用履歴の取引装置識別情報で示される各々の取引装置の配置が、前記基準時間未満の時間で前記記録媒体を共用可能な配置であるか否かを判定する取引装置配置判定手段（たとえば、図５１のステップＳ８３５）と、
該取引装置配置判定手段によって前記取引装置が共用可能な配置であると判定されたこと（たとえば、ステップＳ８３５でＹＥＳ）を条件として、その旨を報知する配置報知手段（たとえば、図５１のステップＳ８３６）とを備える。

このような構成によれば、利用状況管理装置によって、利用履歴が異常であると判定されたことを条件として、当該利用履歴の取引装置識別情報で示される各々の取引装置の配置が、基準時間未満の時間で記録媒体を共用可能な配置であるか否かが判定され、取引装置が共用可能な配置であると判定されたことを条件として、その旨を報知される。

このため、記録媒体を共有可能な配置である２つの取引装置で記録媒体が共有されている場合は、たとえば、夫婦間や友人間での記録媒体の貸し借りの可能性もあるので、不正の疑いのある記録媒体の記録媒体識別情報の報知とは別報知を行なうことができる。その結果、正当な利用に対して不当な嫌疑をかけないようにすることができるので、利用者に不快感を与えないようにすることができる。

（１２） 前記店舗利用履歴判定手段は、さらに、前記利用履歴管理手段によって管理されている利用履歴のうち、所定時間内において、取引装置識別情報および記録媒体識別情報が同じで利用が連続しない利用履歴が、２組以上あるか否かを判定することによって、当該利用履歴が異常であるか否かを判定する（たとえば、図５１のステップＳ８４１、ステップＳ８４２）。

このような構成によれば、利用状況管理装置によって、管理されている利用履歴のうち、所定時間内において、取引装置識別情報および記録媒体識別情報が同じで利用が連続しない利用履歴が、２組以上あるか否かが判定されることによって、当該利用履歴が異常であるか否かが判定される。

このため、取引装置識別情報が異なり記録媒体識別情報が同じで利用が連続する２つの取引装置における利用履歴の利用時刻差が予め設定された基準時間以上となるように、数台の取引装置で順次、記録媒体識別情報が同じ不正な記録媒体が用いられる場合であっても、利用履歴が異常であると判定することができる。その結果、不正の疑いのある記録媒体の抽出の確実性を向上させることができる。

（１３） 前記利用状況管理装置は、さらに、
前記店舗利用履歴判定手段によって利用履歴が異常であると判定されたこと（たとえば、ステップＳ８３４でＹＥＳの場合）を条件として、当該利用履歴の取引装置識別情報で示される取引装置を特定可能な情報を出力する取引装置情報出力手段（たとえば、図５１のステップＳ８４４）を備える。

このような構成によれば、利用状況管理装置によって、利用履歴が異常であると判定されたことを条件として、当該利用履歴の取引装置識別情報で示される取引装置を特定可能な情報が出力される。

このため、出力された情報で示される取引装置の利用者を撮影する制御を行なったり、当該取引装置を係員に報知して確認させたりできる。その結果、不正の疑いのある記録媒体の取締りを強化することができる。

［第１の実施の形態］
以下に、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。なお、記録媒体に記録された電子マネーを利用可能な店舗は、コンビニエンスストア、レンタルビデオ店、遊技場３０、または、デパートなどの電子マネーが共通に使えるチェーン店であってもよいし、電子マネーが使える鉄道事業者の駅であってもよいし、電子マネーが使える自動販売機であってもよい。また、異なるチェーン店や鉄道事業者や個人店をまたいで共通利用可能な電子マネーの場合は、そのような電子マネーが共通利用可能な店舗や駅や個人店であってもよい。つまり、本発明における電子マネーは、単一店のみで用いることができる電子マネーではなく、複数の店舗において用いることができる電子マネーであればよい。以下の最良の形態においては、店舗の一例が遊技場３０であることとして実施の形態を説明する。

（電子マネーシステム１０の各構成の説明）
図１は、本発明に係る電子マネーシステム１０の構成の一例を示すブロック図である。図１を参照して、電子マネーシステム１０は、携帯電話１００と、電子マネー管理サーバ２００と、決済サーバ２８０と、リモート発行サーバ４００と、金融機関サーバ５００と、遊技場３０に設置される機器とを含む。

遊技場３０に設置される機器には、券売機３００、カードユニット６００、パチンコ遊技機７００、および、店舗サーバ８００が含まれる。カードユニット６００は、パチンコ遊技機７００に対応して設けられる。

携帯電話１００は、本実施の形態における主要な構成として、電子マネーアプリ１１１と、非接触型ＩＣ（Integrated Circuit）チップ１９０とを備える。携帯電話１００は、携帯電話インターネット網９１０を介して、電子マネー管理サーバ２００と通信することが可能である。

電子マネー管理サーバ２００は、本発明におけるデータとしての電子マネー（バリュー）を携帯電話１００に対して発行する発行処理を行なう発行処理サーバの一例であるとともに、本発明における発行書込処理サーバの一部を構成するものであって、本実施の形態における主要な構成として、初期登録時ＡＰ（Application Program）２１１と、バリュー購入時ＡＰ２１２と、バリュー発行時ＡＰ２１３と、残高管理ＡＰ２１４と、バリュー預かりＡＰ２１５と、バリュー返却ＡＰ２１６と、利用者情報ＤＢ（DataBase）２２１と、発行情報ＤＢ２２２と、取引情報ＤＢ２２４とを備える。

電子マネーシステム１０は、ユーザの携帯電話１００にチャージされた特定の種類の電子マネーであるバリューを用いて、遊技場３０に設置されたパチンコ遊技機７００でのパチンコ遊技を可能にするための電子マネー遊技使用サービスを提供するシステムである。

携帯電話１００は、通話機能、ウェブブラウザによるウェブページ閲覧機能、電子メール機能、アプリケーションソフト実行機能、および、非接触型ＩＣチップ１９０による短距離通信機能を備える。なお、ウェブページ閲覧機能、電子メール機能、アプリケーションソフト実行機能、および、非接触型ＩＣチップ１９０による短距離通信機能を備える装置であれば、携帯電話１００に替えて、通話機能がない携帯情報端末（Personal Digital Assistance、以下「ＰＤＡ」という）などの他の携帯端末であってもよい。

本実施の形態においては、携帯電話１００に、電子マネー遊技使用サービスを実行するための携帯電話１００側の処理手順を示すプログラムである電子マネーアプリ１１１が導入されることにより、後述するように、電子マネーシステム１０で、この携帯電話１００を用いることができるようになる。

電子マネーアプリ１１１は、携帯電話インターネット網９１０を介して、電子マネー管理サーバ２００や金融機関サーバ５００やリモート発行サーバ４００と通信することが可能である。また、電子マネーアプリ１１１は、バリューに関する処理状況を記憶部１２０に記憶することによって管理する。

非接触型ＩＣチップ１９０は、電子マネーアプリ１１１、および、外部のチップリーダライタと通信することが可能である。非接触型ＩＣチップ１９０と外部のチップリーダライタとの通信は、非接触型ＩＣチップ１９０がチップリーダライタから数センチメートルの距離に近接するように、携帯電話１００がチップリーダライタにかざされることによって行なわれる。

非接触型ＩＣチップ１９０と外部のチップリーダライタとの通信は、チップリーダライタからの電磁波である搬送波を、非接触型ＩＣチップ１９０やチップリーダライタが変調させることによって行なわれる。また、非接触型ＩＣチップ１９０には、チップリーダライタからの電磁波による電磁誘導によって、外部のチップリーダライタ側から電力が供給される。

このため、携帯電話１００側から電力が供給されない場合であっても、非接触型ＩＣチップ１９０がチップリーダライタに近づけられることによって、非接触型ＩＣチップ１９０は動作可能となる。

電子マネー管理サーバ２００は、初期登録時ＡＰ２１１、バリュー購入時ＡＰ２１２、バリュー発行時ＡＰ２１３、残高管理ＡＰ２１４、バリュー預かりＡＰ２１５、バリュー返却ＡＰ２１６、利用者情報ＤＢ２２１、発行情報ＤＢ２２２、および、取引情報ＤＢ２２４などの機能によって、携帯電話１００および遊技場３０に対して、後述するような電子マネー遊技使用サービスにおける様々なサービスを提供する。

決済サーバ２８０は、請求情報ＤＢ２８１を含み、電子マネー遊技使用サービスに対するユーザの決済を管理する。決済サーバ２８０は、専用線を介して、電子マネー管理サーバ２００と通信することが可能である。

リモート発行サーバ４００は、携帯電話１００の非接触型ＩＣチップ１９０に本発明におけるデータとしての電子マネー（バリュー）を書込むための書込処理を行なう書込処理サーバの一例であるとともに、本発明における発行書込処理サーバの一部を構成するものであって、複数のサービス提供機関により使用が可能とされた前記記憶部１９２に各サービス提供機関が提供するサービスに応じてサービス提供用領域の構築および削除のための処理を行なうとともに、該サービス提供用領域の構築に応じた対価を請求するために各サービス提供機関ごとに課金管理を行なうサービス提供用領域管理機関によって運営される。

リモート発行サーバ４００は、電子マネー管理サーバ２００および携帯電話１００からの非接触型ＩＣチップ１９０への記憶領域の確保および情報の書込みを管理する。具体的には、本実施例においては、リモート発行サーバ４００は、非接触型ＩＣチップ１９０の記憶部１９２にサービス提供機関である電子マネー管理サーバ２００の運営機関が提供する電子マネー遊技使用サービスに応じて電子マネー遊技使用サービス用の記憶領域の構築および削除のための処理を行なうとともに、電子マネー遊技使用サービス用の記憶領域の構築に応じた対価を請求するために課金管理を行なう。ここで、非接触型ＩＣチップ１９０の記憶部１９２は、複数のサービス提供機関により使用が可能とされた記憶媒体であって、携帯電話１００に搭載された記憶媒体である。

また、リモート発行サーバ４００は、携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域へバリューを書込むための依頼を携帯電話１００から受信する。次に、リモート発行サーバ４００は、この依頼に応じて、その電子マネー遊技使用サービス用の記憶領域へバリューを書込むための書込処理を行なう。そして、リモート発行サーバ４００は、書込処理の終了に基づいて、当該バリューを書込済であることを処理状況として記憶することによってバリューが書込済であるか否かの処理状況を管理する。また、リモート発行サーバ４００は、バリューの書込以外のバリューに関する処理状況も管理する。

金融機関サーバ５００は、電子マネー遊技使用サービスを利用するにあたって電子マネー遊技使用サービスの提供業者に対価を支払うためにユーザが利用する金融機関のサーバである。金融機関サーバ５００は、各種収納機関および金融機関が専用線で閉域接続された金融機関専用ネットワーク９２０を運営する団体に加盟する金融機関に設置される。金融機関サーバ５００は、金融機関専用ネットワーク９２０を介して、決済サーバ２８０と通信することが可能である。金融機関サーバ５００は、携帯電話インターネット網９１０を介して、携帯電話１００と通信することが可能である。

券売機３００は、ユーザから現金やバリューを受けて、遊技を可能とする所定の遊技価値を有するプリペイドデータを記録したプリペイドカード３７１を発券する。券売機３００は、後述するようにチップリーダライタを含み、前述したように、携帯電話１００の非接触型ＩＣチップ１９０と通信することが可能である。つまり、券売機３００は、取引装置の一例であって、携帯電話１００に記憶されたバリューを使用してプリペイドカード３７１を発券する処理を取引処理として行なう。

カードユニット６００は、パチンコ遊技機７００に対応して設けられる。カードユニット６００は、遊技者からプリペイドカード３７１や現金やバリューを受付けて、パチンコ遊技機７００に設けられた球貸ボタンの操作に応じて、プリペイドカード３７１に記録されたプリペイドデータで示される価値のうちから所定額相当（たとえば、５００円相当）の価値を減算する。

カードユニット６００は、減算した価値に見合った遊技球を払出すことを指示する球貸操作信号をパチンコ遊技機７００に送信する。カードユニット６００は、パチンコ遊技機７００に設けられた返却ボタン６３２の操作に応じて、プリペイドカード３７１を排出する。カードユニット６００は、後述するようにチップリーダライタを含み、前述したように、携帯電話１００の非接触型ＩＣチップ１９０と通信することが可能である。つまり、カードユニット６００は、取引装置の一例であって、携帯電話１００に記憶されたバリューを使用してパチンコ遊技機７００から遊技球を払出す処理を取引処理として行なう。

パチンコ遊技機７００は、パチンコ遊技をユーザである遊技者に提供する装置である。パチンコ遊技機７００は、カードユニット６００からの球貸操作信号を受けて、所定額相当の遊技球を払出す。そして、遊技者によるパチンコ遊技機７００に設けられた発射ハンドルの操作に応じて、払出された遊技球が遊技領域に発射されることによって、パチンコ遊技が行なわれる。

店舗サーバ８００は、遊技場３０内のＬＡＮ（Local Area Network）を介して、券売機３００およびカードユニット６００と通信することが可能である。店舗サーバ８００は、専用線または公衆回線を介して、電子マネー管理サーバ２００と通信することが可能である。

店舗サーバ８００は、券売機３００におけるプリペイドカード３７１の販売に伴なう取引情報、および、カードユニット６００におけるプリペイドカード３７１の使用に伴なう使用情報などの情報を、券売機３００やカードユニット６００から受けて、それらの情報を記憶する。

店舗サーバ８００は、記憶した情報のうち、後述するバリューの使用に関する情報を電子マネー管理サーバ２００に送信する。店舗サーバ８００は、電子マネー管理サーバ２００から電子マネー遊技使用サービスにおける不正に関する情報を受信する。

店舗サーバ８００は、電子マネー管理サーバ２００から受信した情報を、必要に応じて、券売機３００やカードユニット６００に送信する。

なお、決済サーバ２８０は、電子マネー管理サーバ２００に含まれるように構成されてもよい。また、初期登録時ＡＰ２１１、バリュー購入時ＡＰ２１２、バリュー発行時ＡＰ２１３、残高管理ＡＰ２１４、バリュー預かりＡＰ２１５、バリュー返却ＡＰ２１６、利用者情報ＤＢ２２１、発行情報ＤＢ２２２、および、取引情報ＤＢ２２３の構成は、それぞれ、電子マネー管理サーバ２００と異なるコンピュータに含まれるようにしてもよい。また、たとえば、携帯電話１００のウェブ処理時に情報をやり取りするサーバと、携帯電話１００の電子マネーアプリ１１１の処理時にやり取りするサーバとが、それぞれ別のコンピュータで構成されるようにしてもよい。

図２は、本発明に係る携帯電話１００の構成の一例を示すブロック図である。図２を参照して、携帯電話１００は、データ処理部１１０と、記憶部１２０と、データ入力部１３０と、表示部１４０と、音声入出力部１５０と、無線通信部１６０と、アンテナ１６１と、前述した非接触型ＩＣチップ１９０とを含む。

非接触型ＩＣチップ１９０は、制御部１９１と、記憶部１９２と、非接触通信部１９３と、アンテナ１９４とを含む。

記憶部１２０は、ＲＯＭ（Read Only Memory）やフラッシュメモリなどの不揮発性メモリやＲＡＭ（Random Access Memory）などの揮発性メモリなどの半導体メモリで構成される。記憶部１２０は、携帯電話１００の各種機能をデータ処理部１１０に実行させるためのプログラムやデータを記憶する。また、記憶部１２０は、携帯電話１００を識別するための携帯端末情報である携帯ＩＤを予め記憶する。また、記憶部１２０は、非接触型ＩＣチップ１９０を利用する各種サービスにおけるアプリケーションプログラム、本実施の形態においては、電子マネー管理サーバ２００から受信した本電子マネーサービスを享受するための処理手段が示された特定プログラムとしての電子マネーアプリ１１１を記憶する。また、記憶部１２０には、電子マネー（バリュー）の処理状況が記憶されて管理されるとともに、該処理状況は、電子マネーアプリ１１１の処理手順に従って、データ処理部１１０により更新される。

データ入力部１３０は、電話番号や各種データなどの数字やアルファベットやその他の文字などを入力するためのダイヤルキーや十字操作キーやその他のファンクションキーで構成される。データ入力部１３０は、ユーザからデータの入力を受付けて、入力されたデータをデータ処理部１１０に受渡す。

表示部１４０は、液晶表示装置（Liquid Crystal Display、以下「ＬＣＤ」という）で構成される。なお、表示部１４０は、ＥＬ（ElectroLuminescence）ディスプレイなど他の表示装置で構成されてもよい。表示部１４０は、データ処理部１１０から受けた文字データおよび画像データを表示する。

音声入出力部１５０は、マイクおよびスピーカで構成される。音声入出力部１５０は、外部から入力された音声を電気信号に変えて、データ処理部１１０に受渡し、データ処理部１１０からの電気信号を音声に変換して、外部に出力する。

無線通信部１６０は、他の携帯電話またはサーバからアンテナ１６１で受信した信号をデータ処理部１１０に受渡し、データ処理部１１０から他の携帯電話またはサーバへ送信する信号をアンテナ１６１から出力させる。

データ処理部１１０は、マイクロプロセッサ（Micro Processing Unit、以下「ＭＰＵ」という）で構成される。データ処理部１１０は、非接触型ＩＣチップ１９０の制御部１９１と通信することが可能である。データ処理部１１０は、記憶部１２０に記憶されたプログラムに従って、記憶部１２０、データ入力部１３０、無線通信部１６０、音声入出力部１５０、または、非接触型ＩＣチップ１９０の制御部１９１から入力されたデータを処理して、記憶部１２０、表示部１４０、無線通信部１６０、音声入出力部１５０、または、非接触型ＩＣチップ１９０の制御部１９１に出力する。

非接触型ＩＣチップ１９０の記憶部１９２は、非接触型ＩＣチップ１９０を利用する各種サービスで用いられるバリューなどの電子マネーやサービスポイントなどのデータ、および、アプリケーションプログラムで用いられるデータを記憶する。つまり、記憶部１９２は、本発明におけるデータとしての電子マネー（バリュー）を記憶する記憶手段を構成する。

非接触型ＩＣチップ１９０の非接触通信部１９３は、アンテナ１９４を介して外部のチップリーダライタと通信する。本実施の形態においては、非接触通信部１９３は、券売機３００に備えられたチップリーダライタ３９０およびカードユニット６００に備えられたチップリーダライタ６９０と通信する。また、前述したように、外部のチップリーダライタからの電磁波による電磁誘導によって、非接触通信部１９３は、アンテナ１９４から電力を受け、非接触型ＩＣチップ１９０の各部に電力を供給する。

非接触型ＩＣチップ１９０の制御部１９１は、記憶部１９２に記憶されたプログラムに従って、記憶部１９２、非接触通信部１９３、または、データ処理部１１０から入力されたデータを処理して、記憶部１９２、非接触通信部１９３、または、データ処理部１１０に出力する。

なお、本実施の形態においては、携帯電話１００は、音声入出力部１５０を含んでも含まなくてもよい。

図３は、本発明に係る電子マネー管理サーバ２００の構成の一例を示すブロック図である。図３を参照して、電子マネー管理サーバ２００は、データ処理部２１０と、記憶部２２０と、データ入力部２３０と、表示部２４０と、通信部２６０とを含む。

記憶部２２０は、ＲＯＭやフラッシュメモリなどの不揮発性メモリやＲＡＭなどの揮発性メモリなどの半導体メモリ、および、ハードディスクなどの外部記憶装置で構成される。記憶部２２０には、電子マネー管理サーバ２００の各種機能をデータ処理部２１０に実行させるためのプログラムやデータが記憶される。

本実施の形態においては、初期登録時ＡＰ２１１、バリュー購入時ＡＰ２１２、バリュー発行時ＡＰ２１３、残高管理ＡＰ２１４、バリュー預かりＡＰ２１５、および、バリュー返却ＡＰ２１６が記憶部２２０に記憶される。また、前述した利用者情報ＤＢ２２１、発行情報ＤＢ２２２および取引情報ＤＢ２２４も、記憶部２２０に構成される。

データ入力部２３０は、キーボードおよびマウスなどの入力装置で構成される。データ入力部２３０は、電子マネー管理サーバの管理者などのユーザからデータの入力を受付けて、入力されたデータをデータ処理部１１０に受渡す。

表示部２４０は、ＬＣＤで構成される。なお、表示部２４０は、ＣＲＴ（Cathode Ray Tube）ディスプレイやＥＬ（ElectroLuminescence）ディスプレイなど他の表示装置で構成されてもよい。表示部２４０は、データ処理部２１０から受けた文字データおよび画像データを表示する。

通信部２６０は、携帯電話１００または他のサーバから、携帯電話インターネット網９１０または他のネットワークを介して受信したデータをデータ処理部２１０に受渡し、データ処理部２１０から携帯電話インターネット網９１０または他のネットワークを介して携帯電話１００または他のサーバに送信するデータを出力する。

データ処理部２１０は、ＭＰＵで構成される。データ処理部２１０は、記憶部２２０に記憶されたプログラムに従って、記憶部２２０、データ入力部２３０、または、通信部２６０から入力されたデータを処理して、記憶部２２０、表示部２４０、または、通信部２６０に出力する。

なお、決済サーバ２８０、リモート発行サーバ４００、金融機関サーバ５００、および、店舗サーバ８００の構成は、図３で説明した電子マネー管理サーバ２００の構成と同様である。

図４は、本実施の形態における電子マネー管理サーバ２００が電子マネー遊技使用サービスを提供する際に用いる利用者情報データベース２２１を説明するための図である。

図４を参照して、利用者情報ＤＢ２２１では、会員ＩＤおよび携帯端末情報に対応付けて、携帯電話１００の電子メールアドレス、金融機関指定情報、未チャージ削除カウンタのカウント値、通常用であるかテスト用であるかの携帯電話１００の種別、携帯電話１００の１日購入限度額、携帯電話１００の携帯上保持限度額、および、バリューに関する処理状況が記憶される。

会員ＩＤは、電子マネー遊技使用サービスの会員を一意に識別するためのＩＤである。携帯端末情報は、携帯電話１００を一意に識別するための情報である。携帯電話１００の電子マネーアドレスは、携帯電話１００に対して一意に設定される電子メールに用いられるアドレスである。

金融機関指定情報は、会員がバリューのチャージ額の決済に用いる金融機関に対して予め一意に付与される番号である。未チャージ削除カウンタは、電子マネー遊技使用サービスに登録され、初期登録手数料の決済が終了していない回数を携帯端末１００ごとに計数するためのカウンタである。

テスト用の携帯電話は、電子マネーシステム１０における電子マネー遊技使用サービスが適正に提供されるか否かをテストするために用いられる携帯電話である。通常用の携帯電話は、一般ユーザが電子マネー遊技使用サービスを享受するために用いる携帯電話である。

１日購入限度額は、１日に購入できるバリューの限度額である。携帯上保持限度額は、携帯電話１００にチャージできるバリューの限度額である。ここで、１日購入限度額および携帯上保持限度額は、電子マネー管理サーバ２００において、設定変更できるようにされており、具体的には、通常用携帯電話に対する上限額よりも、テスト用携帯電話に対する上限額のほうが高く設定される。また、電子マネー管理サーバ２００においては、ユーザがバリューのチャージ額を選択する際の選択肢（表示金額リスト：図３２、図３３参照）についても、通常用携帯電話およびテスト用携帯電話それぞれに対して、上記設定された上限額に対応して設定変更できるようになっており、かかる設定された通常用携帯電話に対するチャージ額の選択肢とテスト用携帯電話に対するチャージ額の選択肢を管理している。

バリューに関する処理状況は、図５で後述する処理状況であるバリューの発行ごとの処理状況（発行状況）以外の処理状況であり、具体的には、図９で後述する初期登録時ＡＰ２１１における電子マネー遊技使用サービス用の記憶領域が確保するための情報を送信済であることを示す領域確保済、図２１で後述するバリュー預かりＡＰ２１５におけるバリューを預けて電子マネー遊技使用サービス用の記憶領域を削除するための情報を送信済であることを示す削除応答済、および、図２３のバリュー返却ＡＰ２１６におけるバリューの返却を受けるための情報を送信済であることを示す返却済のいずれかの状況を示す。

このため、電子マネー管理サーバ２００は、会員ＩＤまたは携帯端末情報に基づき、当該会員ＩＤまたは当該携帯端末情報に対応する、電子メールアドレス、金融機関指定情報、未チャージ削除カウンタのカウント値、種別、１日購入限度額、携帯上保持限度額、および、バリューに関する処理状況を容易に検索することができる。

図４では、たとえば、携帯端末情報として「ＭＮ７ＲＥ」，「ＮＯ８ＳＦ」のそれぞれ携帯電話のユーザに対して、会員ＩＤとして「１１０１」，「９９９９」が発行され、これらの会員ＩＤおよび携帯端末情報に対応付けて、それぞれ、電子メールアドレスとして「ｍａｉｌｔｏ＠ｊｐ」，「ｔｅｓｔｙｏ＠ｊｐ」、金融機関指定情報として所定の銀行の指定口座を特定するための「２４０９３２９」，「３５１０４３０」、未チャージ削除カウンタのカウント値として「２」，「０」、携帯電話の種別として「通常用」，「テスト用」、１日購入限度額として「３００００」円，「５０００００」円、携帯上保持限度額として「３００００」円，「１００００００」円、および、バリューに関する処理状況として「領域確保済」，「削除応答済」が記録されている。

図５は、本実施の形態における電子マネー管理サーバ２００が電子マネー遊技使用サービスを提供する際に用いる発行情報データベース２２２を説明するための図である。

図５を参照して、発行情報ＤＢ２２２では、前述した会員ＩＤおよび携帯端末情報に対応付けて、携帯電話１００のバリュー残高、購入番号、購入金額、手数料、タイムスタンプ、バリュー購入記録（未チャージバリューを含む）、バリュー購入回数、当日積算額、チャージ累計額、および、取引額が記憶される。

バリュー残高は、携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域に記憶されるバリューの残額である。購入番号は、それぞれのバリューの購入を識別するための番号である。購入金額は、購入するバリューの対価である。手数料は、電子マネー遊技使用サービスの会員が電子マネー遊技使用サービスの提供業者に支払うべきバリューの購入の際の手数料である。タイムスタンプは、バリューの購入のための処理が行なわれた時刻を示す情報である。バリュー購入記録は、会員ＩＤごとの未チャージバリューなどの購入に関する情報の記録である。バリュー購入回数は、その会員が会員となってからバリューを購入した回数である。当日積算額は、その当日にその会員によって購入されたバリューの積算額である。チャージ累計額は、その会員が現在までに購入したバリューの累計額である。取引額は、ユーザがバリューを用いて取引をした額である。

このため、電子マネー管理サーバ２００は、会員ＩＤまたは携帯端末情報に基づき、当該会員ＩＤまたは当該携帯端末情報に対応する、バリュー残高、購入番号、購入金額、手数料、タイムスタンプ、バリュー購入記録、バリュー購入回数、当日積算額、チャージ累計額、および、取引額を容易に検索することができる。なお、バリュー購入記録としては、バリューの額、および、バリューを発行済であるか未発行であるかを示す処理状況を含む。

図５では、たとえば、会員ＩＤ「１１０１」および携帯端末情報「ＭＮ７ＲＥ」に対応付けて、バリュー残高として「１１０００」円、バリュー購入回数として「２８」回目、当日積算額として「６０００」円、チャージ累計額として「２４０００」円、および、取引額として「２２０００」円が記憶されている。

また、前述した会員ＩＤ「１１０１」および携帯端末情報「ＭＮ７ＲＥ」に対応付けて、購入番号として「９００１０８０１」と「９０００５５８７」とが記憶されている。本実施の形態においては、バリュー購入が行なわれるごとに、会員ＩＤおよび携帯端末情報に対応付けて、購入番号が記憶される。

購入番号として「９００１０８０１」，「９０００５５８７」のそれぞれに対応して、購入金額として「１０００」円，「５０００」円、手数料として「２００」円，「２００」円、タイムスタンプとして「２００５０４２８１５３４５７」，「２００５０４１７０７１１３４」、バリューの額として「１０００」円，「５０００」円、および、処理状況として当該バリューが発行済である旨の「発行済」，当該バリューが発行済でない旨の「未発行」が記憶されている。つまり、未チャージバリューとは、処理状況が「未発行」であるバリューである。このように、発行情報ＤＢ２２２には、購入番号に対応する購入履歴が記憶される。

図６は、本実施の形態における電子マネー管理サーバ２００が電子マネー遊技使用サービスを提供する際に用いる取引情報データベース２２４を説明するための図である。

図６を参照して、取引情報ＤＢ２２４では、前述した会員ＩＤおよび携帯端末情報に対応付けて、携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２に記憶されているバリューの利用履歴として、バリューが利用された利用日、利用時刻、バリューが利用された店舗の店舗ＩＤ、バリューが利用された券売機３００またはカードユニット６００などの取引装置の装置ＩＤ、および、利用されたバリューの額である取引金額が、それぞれの利用ごとに記憶される。

このため、電子マネー管理サーバ２００は、会員ＩＤまたは携帯端末情報に基づき、当該会員ＩＤまたは当該携帯端末情報に対応する、利用日、利用時刻、店舗ＩＤ、装置ＩＤおよび取引金額を容易に検索することができる。

図６では、たとえば、会員ＩＤ「１１０１」および携帯端末情報「ＭＮ７ＲＥ］に対応付けて、利用日および利用時刻として、「２００６年９月２日」および「１０：００：００」、ならびに、「２００６年１１月２２日」および「１０：３０：００」、ならびに、「２００６年１１月２２日」および「１２：００：００」、ならびに、「２００６年１１月２２日」および「１２：０５：００」、ならびに、「２００６年１１月２２日」および「１２：１５：００」、ならびに、その他の日付および時刻の組合せが記憶されている。他の会員ＩＤ「２２０２」および携帯端末情報「ＬＭ６ＱＤ」についても同様に利用履歴が記憶されている。

また、利用日および利用時刻の組合せである「２００６年９月２日」および「１０：００：００」、ならびに、「２００６年１１月２２日」および「１０：３０：００」、ならびに、「２００６年１１月２２日」および「１２：００：００」、ならびに、「２００６年１１月２２日」および「１２：０５：００」、ならびに、「２００６年１１月２２日」および「１２：１５：００」のそれぞれに対応して、店舗ＩＤとして、「００００３」、「００００２」、「００００１」、「００００１」および「００００１」、装置ＩＤとして、「０１２３」、「０００１」、「０００１」、「０００２」および「０００２」、取引金額として、「１０００」円、「５００」円、「５００」円、「５００」円および「５００」円が記憶されている。

以上、本実施の形態における電子マネー管理サーバ２００のデータベースとして、利用者情報ＤＢ２２１と発行情報ＤＢ２２２と取引情報ＤＢ２２４からなる構成について説明した。しかし、これに限らず、１つのデータベースで構成されるものであってもよい。たとえば、会員ＩＤおよび携帯端末情報に対応付けて、当該会員ＩＤまたは当該携帯端末情報に対応する各種情報を記憶するように構成するものであってもよい。

以上のように、電子マネー管理サーバ２００は、利用者情報ＤＢ２２１において、各携帯電話１００を個々に識別可能な（携帯端末）識別情報（会員ＩＤ、携帯端末情報）に対応付けて、当該携帯電話１００の所有者が電子マネーのチャージの対価の決済用処理に利用する金融機関を特定するための金融機関指定情報と、該携帯電話１００の記憶部１９２に本電子マネー遊技使用サービス用の記憶領域を構築した回数を示す未チャージ削除カウンタと、該携帯電話１００が通常用携帯電話およびテスト用携帯電話のいずれであるかを示す種別と、該携帯電話１００の種別に対応した１日購入限度額および携帯上保持限度額とを記憶・管理している。

また、電子マネー管理サーバ２００は、図５の発行情報ＤＢ２２２において、各携帯電話１００を個々に識別可能な（携帯端末）識別情報（会員ＩＤ、携帯端末情報）に対応付けて、該携帯電話１００に対してチャージ可能となった電子マネーの額および当該電子マネーが発行済か否かを示す処理状況（発行状況）を含むバリュー購入記録と、当日（所定期間）においてチャージを許容された電子マネーの累計額である当日積算額とを記憶・管理している。

また、電子マネー管理サーバ２００は、図６の取引情報ＤＢ２２４において、各携帯電話１００を個々に識別可能な（携帯端末）識別情報（会員ＩＤ、携帯端末情報）に対応付けて、該携帯電話１００に記憶されているバリューの利用履歴として、バリューが利用された利用日と利用時刻と、バリューが利用された店舗の店舗識別情報（店舗ＩＤ）と、バリューが利用された取引装置（券売機３００、カードユニット６００）の取引装置識別情報（装置ＩＤ）と、利用されたバリューの額である取引金額とを記憶・管理している。

図７は、本発明に係る券売機３００の構成の一例を示すブロック図である。図７を参照して、券売機３００は、データ処理部３１０と、記憶部３２０と、操作部３３０と、表示部３４０と、通信部３６０と、カードリーダライタ３７０と、貨幣処理機３８０と、チップリーダライタ３９０とを含む。

チップリーダライタ３９０は、制御部３９１と、記憶部３９２と、非接触通信部３９３と、アンテナ３９４とを含む。

記憶部３２０は、ＲＯＭやフラッシュメモリなどの不揮発性メモリおよびＲＡＭなどの揮発性メモリなどの半導体メモリで構成される。記憶部３２０には、券売機３００の各種機能をデータ処理部３１０に実行させるためのプログラムおよびデータが記憶される。

操作部３３０は、購入するプリペイドカードの金額を選択するための金額ボタンを含む。また、金額ボタンは、選択されたときに、ランプが点灯するように構成される。操作部３３０は、ユーザからの操作を受付けて、受付けられた操作を示す信号をデータ処理部３１０に受渡す。

表示部３４０は、ＬＣＤで構成される。なお、表示部３４０は、ＥＬディスプレイなど他の表示装置で構成されてもよい。表示部３４０は、データ処理部３１０から受けた文字データおよび画像データを表示する。

通信部３６０は、店舗サーバ８００から、遊技場３０のＬＡＮを介して受信したデータを、データ処理部３１０に受渡し、データ処理部３１０から遊技場３０内のＬＡＮを介して店舗サーバ８００に送信するデータを出力する。

カードリーダライタ３７０は、プリペイドカード３７１からデータを読出して、読出したデータをデータ処理部３１０へ受渡し、データ処理部３１０から受けたデータをプリペイドカード３７１に記録して、プリペイドカード３７１を発券する。

貨幣処理機３８０は、コインおよび紙幣の現金を受入れて、受入れられた現金の額を示すデータをデータ処理部３１０へ受渡す。また、貨幣処理機３８０は、データ処理部３１０から受けたデータで示される額の現金を外部へ返却する。

データ処理部３１０は、ＭＰＵで構成される。データ処理部３１０は、チップリーダライタ３９０の制御部３９１と通信することが可能である。データ処理部３１０は、記憶部３２０に記憶されたプログラムに従って、記憶部３２０、操作部３３０、通信部３６０、カードリーダライタ３７０、貨幣処理機３８０、または、チップリーダライタ３９０の制御部３９１から入力されたデータを処理して、記憶部３２０、表示部３４０、通信部３６０、カードリーダライタ３７０、貨幣処理機３８０、または、チップリーダライタ３９０の制御部３９１に出力する。

チップリーダライタ３９０の記憶部３９２は、非接触型ＩＣチップ１９０を利用する各種サービスにおいて非接触型ＩＣチップ１９０とやり取りするためのアプリケーションプログラム、および、それらのアプリケーションプログラムで用いられるデータを記憶する。

チップリーダライタ３９０の非接触通信部３９３は、アンテナ３９４を介して携帯電話１００の非接触型ＩＣチップ１９０と通信する。また、前述したように、非接触通信部３９３からの搬送波である電磁波による電磁誘導によって、非接触通信部３９３は、アンテナ３９４を介して、非接触型ＩＣチップ１９０に電力を供給する。

チップリーダライタ３９０の制御部３９１は、記憶部３９２に記憶されたプログラムに従って、記憶部３９２、非接触通信部３９３、または、データ処理部３１０から入力されたデータを処理して、記憶部３９２、非接触通信部３９３、または、データ処理部３１０に出力する。

図８は、本発明に係るカードユニット６００の構成の一例を示すブロック図である。図８を参照して、カードユニット６００は、データ処理部６１０と、記憶部６２０と、表示部６４０と、通信部６６０と、カードリーダライタ６７０と、貨幣処理機６８０と、チップリーダライタ６９０とを含む。また、カードユニット６００に信号を入力する操作部として、パチンコ遊技機７００に設けられる球貸ボタン６３１および返却ボタン６３２がある。

チップリーダライタ６９０は、制御部６９１と、記憶部６９２と、非接触通信部６９３と、アンテナ６９４とを含む。

記憶部６２０は、ＲＯＭやフラッシュメモリなどの不揮発性メモリおよびＲＡＭなどの揮発性メモリなどの半導体メモリで構成される。記憶部６２０には、カードユニット６００の各種機能をデータ処理部６１０に実行させるためのプログラムおよびデータが記憶される。

球貸ボタン６３１は、遊技者により押下操作されることによって、遊技球の貸出を要求する球貸操作信号をデータ処理部６１０に出力する。返却ボタン６３２は、遊技者により押下操作されることによって、プリペイドカード３７１の返却を要求する返却操作信号をデータ処理部６１０に出力する。

表示部６４０は、ＬＣＤで構成される。なお、表示部６４０は、ＥＬディスプレイなど他の表示装置で構成されてもよい。表示部６４０は、データ処理部６１０から受けた文字データおよび画像データを表示する。

通信部６６０は、店舗サーバ８００から、遊技場３０のＬＡＮを介して受信したデータを、データ処理部６１０に受渡し、データ処理部６１０から遊技場３０内のＬＡＮを介して店舗サーバ８００に送信するデータを出力する。

カードリーダライタ６７０は、プリペイドカード３７１からデータを読出して、読出したデータをデータ処理部６１０へ受渡し、データ処理部６１０から受けたデータをプリペイドカード３７１に記録する。また、カードリーダライタ６７０は、返却ボタン６３２からデータ処理部６１０を介して受けた返却操作信号に応じて、プリペイドカード３７１を外部へ排出する。

貨幣処理機６８０は、コインおよび紙幣の現金を受入れて、受入れられた現金の額を示すデータをデータ処理部６１０へ受渡す。また、貨幣処理機６８０は、データ処理部６１０から受けたデータで示される額の現金を外部へ返却する。

データ処理部６１０は、ＭＰＵで構成される。データ処理部６１０は、チップリーダライタ６９０の制御部６９１と通信することが可能である。データ処理部６１０は、記憶部６２０に記憶されたプログラムに従って、記憶部６２０、球貸ボタン６３１、返却ボタン６３２、通信部６６０、カードリーダライタ６７０、貨幣処理機６８０、または、チップリーダライタ６９０の制御部６９１から入力されたデータを処理して、記憶部６２０、表示部６４０、通信部６６０、カードリーダライタ６７０、貨幣処理機６８０、または、チップリーダライタ６９０の制御部６９１に出力する。

チップリーダライタ６９０の記憶部６９２は、非接触型ＩＣチップ１９０を利用する各種サービスにおいて非接触型ＩＣチップ１９０とやり取りするためのアプリケーションプログラム、および、それらのアプリケーションプログラムで用いられるデータを記憶する。

チップリーダライタ６９０の制御部６９１は、記憶部６９２に記憶されたプログラムに従って、記憶部６９２、非接触通信部６９３、または、データ処理部６１０から入力されたデータを処理して、記憶部６９２、非接触通信部６９３、または、データ処理部６１０に出力する。

（電子マネーシステム１０への携帯電話１００の初期登録の説明）
図２４は、本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話１００の表示部１４０に表示される第１の表示画面図である。図２４（ａ）は、携帯電話１００において、ウェブブラウザ機能が実行されるときに、携帯電話１００の表示部１４０に、最初に表示されるウェブページの画面である。

図２４（ａ）の画面は、「メニュー」画面である。図２４（ａ）の画面には、他のウェブページへのリンクとして、「マイメニュー」「週間ガイド」「メニューリスト」「とくするメニュー」「エリア」「かんたん検索」が表示される。ここでは、「メニューリスト」が選択候補として反転表示されている。選択候補は、十字操作キーで切替えることができる。

また、図２４（ａ）以降の画面でも共通する表示として、画面の下部の「戻る」「選択」「メニュー」の表示がある。データ入力部１３０の左、中、右のファンクションキーを操作することによって、それぞれ「戻る」「選択」「メニュー」の機能を実行することができる。

「戻る」の機能を実行させると、１つ前のウェブページの画面が表示される。「選択」の機能を実行させると、十字操作キーの操作によって反転表示された選択候補のリンク先のウェブページの画面が表示される。「メニュー」の機能を実行させると、図２４（ａ）で説明した「メニュー」画面が表示される。

図２４（ａ）の画面で、「メニューリスト」のリンクが選択されると、図２４（ｂ）の画面が表示される。

図２４（ｂ）の画面は、「メニューリスト」画面である。図２４（ｂ）の画面には、他のウェブページへのリンクとして、「天気／ニュース／情報」「モバイルバンキング」「趣味」その他のリンクが表示される。ここでは、「趣味」のリンクが選択候補として反転表示されている。

図２４（ｂ）の画面で、「趣味」のリンクが選択されると、図２４（ｃ）の画面が表示される。

図２４（ｃ）の画面には、他のウェブページへのリンクとして、「パチンコ／パチスロ」「電子マネー」「→全２３サイト」その他のリンクが表示される。ここでは、「電子マネー」のリンクが選択候補として反転表示されている。

図２４（ｃ）の画面で、「→全２３サイト」のリンクが選択されると、他のサイトへのリンクがさらに表示される。図２４（ｃ）の画面で、「電子マネー」のリンクが選択されると、携帯電話１００から電子マネー管理サーバ２００に、「電子マネー」のリンクにアクセスされた旨が送信される。

図９は、本実施の形態における電子マネー管理サーバ２００により実行される初期登録時アプリケーションプログラム２１１の処理の流れを示すフローチャートである。図９を参照して、まず、ステップＳ２０１で、電子マネー管理サーバ２００のデータ処理部２１０は、図２４（ｃ）の画面で、「電子マネー」のＵＲＬ（Uniform Resource Locator）にアクセスがあったか否かを判断する。

アクセスがあったと判断した場合（ステップＳ２０１でＹＥＳの場合）、ステップＳ２０２で、データ処理部２１０は、携帯電話１００に、電子マネー遊技使用サービスへの登録のためのトップページの画面を送信する。なお、本実施の形態において、「画面を送信する」とは、画面を表示するためのデータを送信することである。アクセスがないと判断した場合（ステップＳ２０１でＮＯの場合）、および、ステップＳ２０２の後、データ処理部２１０は、ステップＳ２０３に処理を進める。

図２４に進んで、図２４（ｄ）の画面は、電子マネー遊技使用サービスへの携帯電話１００の登録のためのトップページの画面である。図２４（ｄ）の画面には、電子マネー遊技使用サービスへの登録の案内の文章のほか、他のウェブページへのリンクとして、電子マネー遊技使用サービスの概要のウェブページへのリンクである「電子マネーとは？」、お気に入りのウェブページをユーザ専用のメニューに登録するためのリンクである「マイメニュー登録」、電子マネー遊技使用サービスの更新履歴のウェブページへのリンクである「Ｗｈａｔ’ｓＮｅｗ！」、電子マネー遊技使用サービスへの新規会員登録のウェブページへのリンクである「新規会員登録はこちら！」、その他のリンクが表示される。ここでは、「新規会員登録はこちら！」が選択候補として反転表示されている。

図１０は、本実施の形態における携帯電話１００のウェブブラウザ機能により実行されるウェブ処理の流れを示すフローチャートである。図１０（ａ）はウェブ処理のうち初期登録時ウェブ処理の流れを示すフローチャートである。図１０（ａ）を参照して、まず、ステップＳ１０１で、携帯電話１００のデータ処理部１１０は、図２４（ｄ）の画面で、「新規会員登録はこちら！」のリンクが選択されたことによって、登録要求があったか否かを判断する。登録要求があったと判断すると（ステップＳ１０１でＹＥＳの場合）、ステップＳ１０２で、データ処理部１１０は、電子マネー管理サーバ２００に、携帯電話１００の機種情報を含む登録要求情報を送信する。

図９に戻って、ステップＳ２０３では、データ処理部２１０は、携帯電話１００から機種情報を含む登録要求情報が送信されてきたか否かを判断する。登録要求情報が送信されてきていないと判断した場合（ステップＳ２０３でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２０７に進める。一方、登録要求情報が送信されてきたと判断した場合（ステップＳ２０３でＹＥＳの場合）、ステップＳ２０４で、データ処理部２１０は、送信されてきた登録要求情報に含まれる機種情報が電子マネーシステム１０に対応した機種を示すか否かを判断する。

携帯電話１００が電子マネーシステム対応機種であると判断した場合（ステップＳ２０４でＹＥＳの場合）、ステップＳ２０５で、データ処理部２１０は、メール送信用画面を携帯電話１００に送信する。その後、データ処理部２１０は、実行する処理をステップＳ２０７に進める。一方、携帯電話１００が電子マネーシステム対応機種でないと判断した場合（ステップＳ２０４でＮＯの場合）、ステップＳ２０６で、データ処理部２１０は、非対応機種報知画面を携帯電話１００に送信する。その後、データ処理部２１０は、実行する処理をステップＳ２０１に戻す。

図２５は、本実施の形態における電子マネーシステム１０に携帯電話１００を初期登録するときに携帯電話１００の表示部１４０に表示される第２の表示画面図である。図２５（ａ）は、ステップＳ２０６で携帯電話１００に送信される非対応機種報知画面である。

図２５（ａ）の画面には、携帯電話１００が電子マネーシステム１０の対応機種でない旨の文章、電子マネー対応機種一覧へのリンクである「電子マネー対応携帯機種」、および、図２４（ｄ）で示したこのサイトのトップページへのリンクである「このサイトのトップへ」が表示される。

図２５（ｂ）は、ステップＳ２０５で携帯電話１００に送信されるメール送信用画面である。図２５（ｂ）の画面には、電子マネー遊技使用サービスへの登録にあたっての注意書き、メール送信画面を表示するためのリンクである「ここをクリック！（空メール送信画面へ）」、および、図２４（ｄ）で示したこのサイトのトップページへのリンクである「このサイトのトップへ」が表示される。図２５（ｂ）の画面で、「ここをクリック！（空メール送信画面へ）」のリンクが選択されると、携帯電話１００の電子メール機能が起動され、図２５（ｃ）のメール送信画面が表示される。

図２５（ｃ）のメール送信画面の宛先には、電子マネー遊技使用サービスへ登録するための電子メールアドレスが既に入力された状態でメール送信画面が表示される。また、メール送信画面の題名および本文には何も入力されていない。

図１０（ａ）に戻って、ステップＳ１０３で、データ処理部１１０は、ユーザによって、図２５（ｃ）のメール送信画面のメールの送信操作が行なわれたか否かを判断する。メール送信操作が行なわれたと判断した場合（ステップＳ１０３でＹＥＳの場合）、ステップＳ１０４で、データ処理部１１０は、図２５（ｃ）のメール送信画面のメールを電子マネー管理サーバ２００に送信する。つまり、空メールを送信する。

図９に戻って、ステップＳ２０７で、データ処理部２１０は、ユーザの携帯電話１００から空メールを受信したか否かを判断する。空メールを受信することによって、データ処理部２１０は、ユーザの携帯電話１００の電子メールアドレスを知ることができる。

空メールを受信したと判断した場合（ステップＳ２０７でＹＥＳの場合）、ステップＳ２０８で、データ処理部２１０は、登録手続を継続するための登録ＵＲＬを記載した電子メールを、ユーザの携帯電話１００の電子メールアドレス宛に送信する。その後、データ処理部２１０は、実行する処理をステップＳ２１０に進める。一方、電子メールアドレスを受信していないと判断した場合（ステップＳ２０７でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２１０に進める。

図２６は、本実施の形態における電子マネーシステム１０に携帯電話１００を初期登録するときに携帯電話１００の表示部１４０に表示される第３の表示画面図である。

図２６（ａ）は、携帯電話１００の電子メール機能において、新着メッセージの件数を報知するための画面である。ここでは、「メール 未読００１」の表示によって、新着の電子メールのうち、未読のものが１件であることが示されている。

図２６（ａ）の画面で、「メール 未読００１」が選択されると、図２６（ｂ）のように、ステップＳ２０８で、電子マネー管理サーバ２００から携帯電話１００に送信された新着メールの内容が表示される。

図２６（ｂ）の電子メールには、登録手続を継続するためのウェブページへの登録ＵＲＬを選択して電子マネー遊技使用サービスへの登録手続を継続する旨の文章、および、登録ＵＲＬが記載されたリンクが表示される。

図１０（ａ）に戻って、ステップＳ１０５で、データ処理部１１０は、図２６（ｂ）の画面で、登録ＵＲＬのリンクが選択されたか否かを判断する。登録ＵＲＬのリンクが選択されたと判断すると（ステップＳ１０５でＹＥＳの場合）、ステップＳ１０６で、データ処理部１１０は、登録ＵＲＬにアクセスするとともに、携帯電話１００の機種情報を電子マネー管理サーバ２００に送信する。

図９に戻って、ステップＳ２１０で、データ処理部２１０は、携帯電話１００から登録ＵＲＬにアクセスがあるとともに携帯電話１００の機種情報を受信したか否かを判断する。登録ＵＲＬにアクセスがあり機種情報を受信した場合（ステップＳ２１０でＹＥＳの場合）、ステップＳ２１１で、データ処理部２１０は、送信されてきた機種情報が電子マネーシステム１０に対応した機種を示すか否かを判断する。

図２６に進んで、図２６（ｃ）は、ステップＳ２１３で携帯電話１００に送信される非対応機種報知画面である。図２６（ｃ）の画面は、図２５（ａ）の画面と同様であるので、説明は繰返さない。

図２６（ｄ）は、ステップＳ２１２で携帯電話１００に送信される利用同意画面である。図２６（ｄ）の画面には、電子マネー遊技使用サービスへの登録にあたっての注意書き、サービス規約のウェブページへのリンクである「サービス規約を読み（必須）」、および、サービス規約に同意し登録手続を先に進めるためのリンクである「同意して登録する」が表示される。ここでは、「同意して登録する」が選択候補として反転表示されている。

図１０（ａ）に戻って、ステップＳ１０７で、データ処理部１１０は、ユーザによって、図２６（ｄ）の画面で、「同意して登録する」のリンクが選択されたか否かを判断する。「同意して登録する」のリンクが選択されたと判断した場合（ステップＳ１０７でＹＥＳの場合）、ステップＳ１０８で、データ処理部１１０は、携帯電話１００を一意に識別するための携帯端末情報（以下「携帯ＩＤ」ともいう）を電子マネー管理サーバ２００に送信する。

図９に戻って、ステップＳ２１４で、データ処理部２１０は、携帯電話１００から携帯端末情報が送信されてきたか否かを判断する。携帯端末情報が送信されてきていないと判断した場合（ステップＳ２１４でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２２１に進める。

一方、携帯端末情報が送信されてきたと判断した場合（ステップＳ２１４でＹＥＳの場合）、ステップＳ２１５で、データ処理部２１０は、図４の利用者情報ＤＢ２２１の携帯端末情報および会員ＩＤを参照することによって、受信した携帯端末情報が利用者情報ＤＢ２２１に登録されたことがあるか否かを判断する。受信した携帯端末情報の登録履歴があると判断した場合（ステップＳ２１５でＹＥＳの場合）、ステップＳ２１６で、データ処理部２１０は、図４の利用者情報ＤＢ２２１の携帯端末情報および未チャージ削除カウンタを参照することによって、受信した携帯端末情報で示される携帯電話１００に対応する未チャージ削除カウンタのカウント値が３以上であるか否かを判断する。

未チャージ削除カウンタのカウント値が３以上である場合（ステップＳ２１６でＹＥＳの場合）、ステップＳ２１７で、データ処理部２１０は、登録回数オーバ画面を携帯電話１００に送信する。その後、データ処理部２１０は、実行する処理をステップＳ２０１に戻す。つまり、この場合には、携帯電話１００の記憶部１９２に電子マネー遊技使用サービス用の記憶領域を構築するための領域確保情報（Ｓ２３６参照）の出力が禁止される。

図２７は、本実施の形態における電子マネーシステム１０に携帯電話１００を初期登録するときに携帯電話１００の表示部１４０に表示される第４の表示画面図である。図２７（ａ）は、ステップＳ２１７で携帯電話１００に送信される登録回数オーバ画面である。

図２７（ａ）の画面には、登録回数が制限を越えている旨の文章、および、図２４（ｄ）で示したこのサイトのトップページへのリンクである「このサイトのトップへ」が表示される。

図９に戻って、受信した携帯端末情報の登録履歴がないと判断した場合（ステップＳ２１５でＮＯの場合）、または、未チャージ削除カウンタのカウント値が３未満である場合（ステップＳ２１６でＮＯの場合）、ステップＳ２１８で、データ処理部２１０は、受信した携帯端末情報を利用者情報ＤＢ２２１に登録する。次に、ステップＳ２１９で、データ処理部２１０は、金融機関を選択するウェブページの最初の画面である金融機関選択画面を携帯電話１００に送信する。その後、データ処理部２１０は、実行する処理をステップＳ２２１に進める。

図２７に進んで、図２７（ｂ）の画面は、ステップＳ２１９で携帯電話１００に送信されるモバイルバンキング登録トップ画面である。図２７（ｂ）の画面には、電子マネー遊技使用サービスにおけるバリューの利用の方法を示す文章、モバイルバンキングへの登録を促がす旨の文章、モバイルバンキングの登録へ進むためのリンクである「ここから」、および、モバイルバンキングへの登録をスキップするためのリンクである「モバイルバンキング登録をスキップする方はこちらを選択してください」が表示される。

図１０（ａ）に戻って、ステップＳ１０９で、データ処理部１１０は、図２７（ｂ）の画面で、「ここから」の金融機関問合せリンクが選択されたか否か、図２７（ｃ）の画面で、いずれかの業態の金融機関問合せリンクが選択されたか否か、または、図２７（ｄ）の画面で、いずれかの金融機関問合せリンクが選択されたか否かを判断する。

金融機関問合せリンクが選択されたと判断すると（ステップＳ１０９でＹＥＳの場合）、ステップＳ１１０で、データ処理部１１０は、それぞれのリンクに対応する金融機関問合せ情報を電子マネー管理サーバ２００に送信する。

図９に戻って、ステップＳ２２１で、データ処理部２１０は、携帯電話１００から金融機関問合せ情報を受信したか否かを判断する。金融機関問合せ情報を受信したと判断した場合（ステップＳ２２１でＹＥＳの場合）、ステップＳ２２２で、データ処理部２１０は、金融機関問合せ情報に対応する画面を携帯電話１００に送信する。

図２７に進んで、図２７（ｃ）の画面は、図２７（ｂ）の画面の「ここから」のリンクの選択によって送信される金融機関問合せ情報に対応する第１の金融機関選択画面である。図２７（ｃ）の画面には、モバイルバンキングの業態の選択を促がす旨の文章、都市銀行を選択するためのリンクである「都市銀行」、地方銀行を選択するためのリンクである「地方銀行」、第２地方銀行を選択するためのリンクである「第２地銀」、労働金庫を選択するためのリンクである「労働金庫」、信用金庫を選択するためのリンクである「信用金庫」、信用組合を選択するためのリンクである「信用組合」、および、その他の金融機関を選択するためのリンクである「その他」が表示される。ここでは、図２７（ｃ）の画面で「都市銀行」のリンクが選択される場合について説明する。

図２７（ｄ）の画面は、図２７（ｃ）の画面の「都市銀行」のリンクの選択によって送信される金融機関問合せ情報に対応する第２の金融機関選択画面である。図２７（ｄ）の画面には、利用するモバイルバンキングの選択を促がす旨の文章、および、都市銀行のうちのいずれかを選択するためのリンクである「やまと銀行」「三友銀行」「ダイヤモンド銀行」「りえぞん銀行」が表示される。ここでは、図２７（ｄ）の画面で「やまと銀行」のリンクが選択される場合について説明する。

図２８は、本実施の形態における電子マネーシステム１０に携帯電話１００を初期登録するときに携帯電話１００の表示部１４０に表示される第５の表示画面図である。

図２８（ａ）の画面は、図２７（ｄ）の画面の「やまと銀行」のリンクの選択によって送信される金融機関問合せ情報に対応するモバイルバンキングを確認するための画面である。図２８（ａ）の画面には、利用するモバイルバンキングとしてやまと銀行を登録することを確認する旨の文章、登録することを確認して継続して手続を進めるためのリンクである「確認」、および、選択したモバイルバンキングを訂正するために前の画面に戻るためのリンクである「訂正する場合はこちらから」が表示される。

図１０（ａ）に戻って、ステップＳ１１１で、データ処理部１１０は、図２８（ａ）の画面で、「確認」のリンクが選択されたか否かを判断する。「確認」のリンクが選択されたと判断すると（ステップＳ１１１でＹＥＳの場合）、ステップＳ１１２で、データ処理部１１０は、電子マネー管理サーバ２００に、選択されたモバイルバンキングを示す金融機関指定情報および前述した携帯端末情報を送信する。つまり、バリューのチャージに関する対価の決済のための決済用処理に利用する決済用処理機関としてユーザが指定した金融機関を特定するための金融機関指定情報が送信される。

図９に戻って、ステップＳ２２３で、データ処理部２１０は、携帯電話１００から金融機関指定情報を受信したか否かを判断する。金融機関指定情報を受信していないと判断した場合（ステップＳ２２３でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２２６に進める。

一方、金融機関指定情報を受信したと判断した場合（ステップＳ２２３でＹＥＳの場合）、データ処理部２１０は、ステップＳ２２４で、金融機関指定情報とともに受信した携帯端末情報と同一であって利用者情報ＤＢ２２１に仮登録された携帯端末情報に対応させて、受信した金融機関指定情報を利用者情報ＤＢ２２１に仮登録する。なお、当該金融機関指定情報から特定される金融機関に指定口座が存在するか否かを金融機関サーバ５００に問合せ、存在する場合に仮登録するようにしてもよい。

次いで、ステップＳ２２５で、データ処理部２１０は、プロモーションメール受取可否設定画面を携帯電話１００に送信する。その後、データ処理部２１０は、実行する処理をステップＳ２２６に進める。

図２８に進んで、図２８（ｂ）は、ステップＳ２２５で携帯電話１００に送信されるプロモーションメール受取可否設定画面である。図２８（ｂ）の画面には、電子マネーに関する最新情報等のお知らせメールであるプロモーションメールの受取を希望するか否かを確認する旨の文章、「希望する」または「希望しない」を選択するためのラジオボタン、ラジオボタンでの選択結果の送信を指示するためのリンクである「送信」、および、図２４（ｄ）で示したこのサイトのトップページへのリンクである「このサイトのトップへ」が表示される。

図１０（ａ）に戻って、ステップＳ１１３で、データ処理部１１０は、図２８（ｂ）の画面で、「希望する」または「希望しない」のラジオボタンが選択され、「送信」のリンクが選択されることによって、プロモーションメールの受取可否が決定されたか否かを判断する。そして、ステップＳ１１４で、データ処理部１１０は、プロモーションメールの受取可否を示すプロモーション受取可否情報を電子マネー管理サーバ２００に送信する。

図９に戻って、ステップＳ２２６で、データ処理部２１０は、携帯電話１００からプロモーション受取可否情報を受信したか否かを判断する。プロモーション受取可否情報を受信していないと判断した場合（ステップＳ２２６でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２３１に進める。一方、プロモーション受取可否情報を受信したと判断した場合（ステップＳ２２６でＹＥＳの場合）、ステップＳ２２７で、データ処理部２１０は、会員ＩＤを発行し、その会員ＩＤ、ステップＳ２０７で受信したメールアドレス、ステップＳ２２４で仮登録された金融機関指定情報およびプロモーション受取可否情報を、プロモーション受取可否情報を送信した携帯電話１００の携帯端末情報と対応させて仮登録する。なお、ステップＳ２１５でＹＥＳと判断された場合には、新たな会員ＩＤを発行することなく、既に発行済みの会員ＩＤを仮登録するようにしてもよい。次いで、ステップＳ２２８で、データ処理部２１０は、電子マネーアプリ１１１のダウンロードを確認する画面を携帯電話１００に送信する。

図２８に進んで、図２８（ｃ）は、ステップＳ２２８で携帯電話１００に送信されるダウンロードを確認する画面である。図２８（ｃ）の画面には、バリューの利用方法の文章、電子マネーアプリ１１１のダウンロードを促がす旨の文章、ダウンロードの開始を指示するためのリンクである「ダウンロード開始」、および、電子マネーアプリ１１１のサイズを示す文章が表示される。

図１０（ａ）に戻って、ステップＳ１１５で、データ処理部１１０は、図２８（ｃ）の画面で、「ダウンロード開始」が選択されることによって、電子マネーアプリ１１１のダウンロードが要求されたか否かを判断する。「ダウンロード開始」が選択されたと判断すると（ステップＳ１１５でＹＥＳの場合）、ステップＳ１１６で、データ処理部１１０は、電子マネーアプリ１１１のダウンロードを要求する旨の情報であるアプリダウンロード要求情報を電子マネー管理サーバ２００に送信する。

図９に戻って、ステップＳ２３１で、データ処理部２１０は、携帯電話１００からアプリダウンロード要求情報を受信したか否かを判断する。アプリダウンロード要求情報を受信したと判断した場合（ステップＳ２３１でＹＥＳの場合）、ステップＳ２３２で、電子マネーアプリ１１１を携帯電話１００に送信する。

図２８に進んで、携帯電話１００で電子マネーアプリ１１１の受信が開始されると、図２８（ｃ）の画面は、図２８（ｄ）で示される状態になる。つまり、ダウンロード中である旨の表示が、図２８（ｃ）の画面上に表示される。

図１０（ａ）に戻って、ステップＳ１１６ａで、データ処理部１１０は、電子マネーアプリ１１１のダウンロードが終了したか否かを判断する。すなわち、電子マネーアプリ１１１が記憶部１２０に記憶されたか否かを判断する。ダウンロードが終了していないと判断した場合（ステップＳ１１６ａでＮＯの場合）、データ処理部１１０は、ステップＳ１１６ａの処理を繰返す。一方、ダウンロードが終了したと判断した場合（ステップＳ１１６ａでＹＥＳの場合）、データ処理部１１０は、初期登録時ウェブ処理を終了する。

以上のように、本実施例においては、電子マネー遊技使用サービスを享受するための登録を要求する登録要求情報として、ステップＳ１０２の登録要求情報、ステップＳ１０８の携帯端末情報、ステップＳ１１６のアプリダウンロード要求情報等、複数の情報が送信されているが、初期登録に際して電子マネー管理サーバ２００との間で送受信される情報は任意であり、少なくとも登録を要求する登録要求情報が１回送信されればよい。

電子マネーアプリ１１１のダウンロードが終了すると、携帯電話１００のデータ処理部１１０は、記憶部１２０に記憶された電子マネーアプリ１１１を起動させる。

図２９は、本実施の形態における電子マネーシステム１０に携帯電話１００を初期登録するときに携帯電話１００の表示部１４０に表示される第６の表示画面図である。図２９（ａ）は、電子マネーアプリ１１１の起動中に表示される画面である。図２９（ａ）の画面には、起動中であるアプリの名称である「電子マネーアプリ」の文字、および、全起動プロセスのうちの経過したプロセスの割合の概略を示すグラフが表示される。

図１１は、本実施の形態における携帯電話１００で実行される電子マネーアプリ１１１の処理の流れを示すフローチャートである。図１１を参照して、電子マネーアプリ１１１が起動されると、ステップＳ１２０で、データ処理部１１０は、電子マネーアプリ１１１がダウンロードされてから初回の起動であるか否かを判断する。初回起動でないと判断した場合（ステップＳ１２０でＮＯの場合）、データ処理部１１０は、実行する処理をステップＳ１８０に進める。一方、初回起動であると判断した場合（ステップＳ１２０でＹＥＳの場合）、ステップＳ１２００で、データ処理部１１０は、初回起動処理を実行する。

図１２は、本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである初回起動処理の流れを示すフローチャートである。図１２を参照して、まず、ステップＳ１２１で、データ処理部１１０は、携帯端末情報を電子マネー管理サーバ２００に送信する。

図９に戻って、電子マネー管理サーバ２００のデータ処理部２１０は、ステップＳ２３３で、携帯電話１００から携帯端末情報を受信して、受信した携帯端末情報が仮登録されているか否かを判断する。携帯端末情報が仮登録されていないと判断した場合（ステップＳ２３３でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２０１に戻す。

一方、携帯端末情報が仮登録されていると判断した場合（ステップＳ２３３でＹＥＳの場合）、データ処理部２１０は、ステップＳ２３４で、その携帯端末情報と対応させて仮登録された会員ＩＤ、メールアドレス、金融機関指定情報およびプロモーション受取可否情報を、その携帯端末情報と対応させて、利用者情報ＤＢ２２１に本登録させる。そして、ステップＳ２３５で、データ処理部２１０は、本登録した携帯端末１００に対応する未チャージ削除カウンタのカウント値を１加算する。なお、加算された未チャージ削除カウンタは、会員から脱退した場合（電子マネー遊技使用サービス用の記憶領域を削除した場合）であっても利用者情報ＤＢ２２１において保持される。

このようにステップＳ２３５において未チャージ削除カウンタが加算されることにより、ステップＳ２３６において送信される領域確保情報（領域構築情報）に対応する電子マネー遊技使用サービス用の記憶領域が携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２に構築された構築回数が管理される。

次に、ステップＳ２３６で、データ処理部２１０は、電子マネー遊技使用サービス用の記憶領域を携帯電話１００の記憶部１９２に確保（構築）させるための情報である領域確保情報（領域構築情報）を携帯電話１００に送信する。

なお、ステップＳ２３４で説明したように、本実施の形態においては、携帯電話１００を他の携帯電話と識別可能にするための識別情報として、携帯端末情報である場合を一例に説明するが、これに限らず、識別情報としては、会員ＩＤ等、携帯電話１００を他の携帯電話と識別可能な情報であればよい。たとえば、ステップＳ２３４においては、会員ＩＤに対応付けて金融機関指定情報等を登録し、以後携帯電話から送信されてくる会員ＩＤに基づき、当該携帯電話を識別し金融機関指定情報等を読出すようにしてもよい。この場合、会員ＩＤは、ステップＳ２３４において本登録された後に、携帯電話１００側に送信し記憶させるようにしてもよい。

図１２に進んで、データ処理部１１０は、ステップＳ１２２で、電子マネー管理サーバ２００から領域確保情報を受信したか否かを判断する。領域確保情報を受信していないと判断した場合（ステップＳ１２２でＮＯの場合）、データ処理部１１０は、ステップＳ１２２を繰返す。一方、領域確保情報を受信したと判断した場合（ステップＳ１２２でＹＥＳの場合）、ステップＳ１２２ａで、データ処理部１１０は、記憶部１２０で記憶管理している携帯電話１００におけるバリューに関する処理状況を、領域確保情報受信済に更新する。そして、ステップＳ１２２ｂで、データ処理部１１０は、領域確保情報を受信したことを電子マネー管理サーバ２００に知らせるための受信応答情報を、電子マネー管理サーバ２００に送信する。

図９に戻って、ステップＳ２３７で、データ処理部２１０は、携帯電話１００から受信応答情報を受信したか否かを判断する。受信応答情報を受信していないと判断した場合（ステップＳ２３７においてＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２０１に戻す。一方、受信応答情報を受信したと判断した場合（ステップＳ２３７においてＹＥＳの場合）、ステップＳ２３８で、データ処理部２１０は、図４に示す利用者情報ＤＢ２２１の処理状況を領域確保済に更新する。その後、データ処理部２１０は、実行する処理をステップＳ２０１に戻す。

図１２に進んで、次に、ステップＳ１２３で、データ処理部１１０は、電子マネー遊技使用サービス用の記憶領域を確保するための領域確保処理の開始を要求する領域確保処理開始要求（領域確保情報により示される電子マネー遊技使用サービス用の記憶領域の構築要求）を、リモート発行サーバ４００に送信する。領域確保処理開始要求は、携帯端末情報を含む。

リモート発行サーバ４００は、携帯電話１００から領域確保処理開始要求を受けると、領域確保処理開始要求を送信してきた携帯電話１００の非接触型ＩＣチップ１９０に電子マネー遊技使用サービスに用いるための記憶部１９２の記憶領域を確保し、確保した記憶領域に会員ＩＤを記憶させるための領域確保実行情報を、領域確保処理開始要求を送信してきた携帯電話１００に送信する。

図１２に戻って、携帯電話１００のデータ処理部１１０は、ステップＳ１２４で、リモート発行サーバ４００から領域確保実行情報を受信したか否かを判断する。領域確保実行情報を受信していないと判断した場合（ステップＳ１２４でＮＯの場合）、データ処理部１１０は、ステップＳ１２４を繰返す。

一方、領域確保実行情報を受信したと判断した場合（ステップＳ１２４でＹＥＳの場合）、データ処理部１１０は、ステップＳ１２５で、リモート発行サーバ４００からの領域確保実行情報で示される領域確保処理を実行する。領域確保処理は、非接触型ＩＣチップ１９０の記憶部１９２に電子マネー遊技使用サービス用の記憶領域を確保し、会員ＩＤをリモート発行サーバ４００に送信し、記憶部１９２の確保された記憶領域に０円相当のバリューを記憶させる処理である。

具体的には、この領域確保処理においては、リモート発行サーバ４００は、電子マネーアプリ１１１を介して、非接触型ＩＣチップ１９０の記憶部１９２に電子マネー遊技使用サービス用の記憶領域を確保する。携帯電話１００は、電子マネーアプリ１１１によって、会員ＩＤと書込みデータである０円相当のバリューとを、リモート発行サーバ４００に送信する。リモート発行サーバ４００は、電子マネーアプリ１１１を介さずに、非接触型ＩＣチップ１９０と直接やり取りして、非接触型ＩＣチップ１９０の記憶部１９２に、携帯電話１００から受信した会員ＩＤとバリューとを書込む。そして、記憶領域の確保および会員ＩＤとバリューとの書込みが終了した場合、リモート発行サーバ４００は、領域確保終了情報を携帯電話１００に送信する。

なお、ここでは、リモート発行サーバ４００は、電子マネーアプリ１１１を介して、記憶領域を確保するようにした。しかし、これに限定されず、リモート発行サーバ４００は、電子マネーアプリ１１１を介さずに、直接、非接触型ＩＣチップ１９０とやり取りして、記憶領域を確保するようにしてもよい。また、リモート発行サーバ４００は、電子マネーアプリ１１１を介さずに、会員ＩＤとバリューとを書込むようにした。しかし、これに限定されず、リモート発行サーバ４００は、電子マネーアプリ１１１を介して、会員ＩＤとバリューとを書込むようにしてもよい。

また、リモート発行サーバ４００は、電子マネー遊技使用サービス用の記憶領域を確保して、その記憶領域に０円相当のバリューを書込んだことを条件として、ステップＳ１２３で携帯電話１００から送信された領域確保処理開始要求に含まれる携帯端末情報と対応付けて、当該携帯端末情報の携帯電話１００に対する処理状況を、領域確保処理が終了したことを示す領域確保終了済として記憶する。

次いで、データ処理部１１０は、ステップＳ１２６で、リモート発行サーバ４００から領域確保終了情報を受信したことによって、領域確保処理が終了したか否かを判断する。領域確保処理が終了したと判断した場合（ステップＳ１２６でＹＥＳの場合）、ステップＳ１２７で、データ処理部１１０は、記憶部１２０で記憶している処理状況を、領域確保済に更新する。その後、データ処理部１１０は、実行する処理をこの処理の呼出元の処理である電子マネーアプリ１１１に戻す。

図１１に戻って、ステップＳ１２００の初回起動処理の実行後、データ処理部１１０は、実行する処理をステップＳ１９２に進める。

ステップＳ１８０では、データ処理部１１０は、電子マネーアプリ１１１の起動が非接触型ＩＣチップ１９０からの起動であるか否かを判断する。図３９で後述する券売機３００による発券処理において券売機３００の非接触型ＩＣチップ３９０、または、図４２で後述するカードユニット６００による球貸処理においてカードユニット６００の非接触型ＩＣチップ６９０から、携帯電話１００の非接触型ＩＣチップ１９０へ、電子マネーアプリ１１１を起動させるためのアプリ起動信号が送信された場合、携帯電話１００は、アプリ起動信号に応じて、電子マネーアプリ１１１を起動させる。アプリ起動信号については、図３９で説明する。また、電子マネーアプリ１１１の起動が非接触型ＩＣチップ１９０からの起動であると判断した場合（ステップＳ１８０でＹＥＳの場合）については、図３９の説明とともに説明する。

一方、電子マネーアプリ１１１の起動が非接触型ＩＣチップ１９０からの起動でないと判断した場合（ステップＳ１８０でＮＯの場合）、ステップＳ１１００で、データ処理部１１０は、電子マネーアプリ１１１の起動が後述するエラー説明画面からの起動であるか否かを判断する。エラー説明画面からの起動であると判断した場合（ステップＳ１１００でＹＥＳの場合）については後述する。

一方、電子マネーアプリ１１１の起動がエラー説明画面からの起動でないと判断した場合（ステップＳ１１００でＮＯの場合）、ステップＳ１１１０で、データ処理部１１０は、電子マネーアプリ１１１の起動が後述するエラー対応完了メールからの起動であるか否かを判断する。エラー対応完了メールからの起動であると判断した場合（ステップＳ１１１０でＹＥＳの場合）については後述する。

一方、エラー対応完了メールからの起動でないと判断した場合（ステップＳ１１１０でＮＯの場合）、ステップＳ１９１で、データ処理部１１０は、後述する図１７で説明する引継ぎ情報からの起動であるか否かを判断する。後述するように、バリューの購入後に引継ぎ情報が付された電子メールが携帯電話１００に送信され、その引継ぎ情報によって、電子マネーアプリ１１１が起動され、購入されたバリューが携帯電話１００にチャージされる。引継ぎ情報からの起動であると判断した場合（ステップＳ１９１でＹＥＳの場合）、データ処理部１１０は、実行する処理をステップＳ１５０に進める。

一方、引継ぎ情報からの起動でないと判断した場合（ステップＳ１９１でＮＯの場合）、ステップＳ１９８で、データ処理部１１０は、処理状況確認処理を実行する。

図１４は、本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである処理状況確認処理の流れを示すフローチャートである。図１４を参照して、ステップＳ１９８１で、データ処理部１１０は、記憶部１２０で管理されている処理状況が、図１２の初回起動処理のステップＳ１２２ａで更新される領域確保情報受信済であるか否かを判断する。

処理状況が領域確保情報受信済であると判断した場合（ステップＳ１９８１においてＹＥＳの場合）、データ処理部１１０は、実行する処理を図１２の初回起動処理のステップＳ１２３に進める。これによって、データ処理部１１０は、ステップＳ１２２で領域確保情報を受信したが、ステップＳ１２３からステップＳ１２６までのリモート発行サーバ４００とのやり取りにおいて、通信障害等により電子マネー遊技使用サービス用の記憶領域を確保できなかった場合、再度、ステップＳ１２１で携帯端末情報を電子マネー管理サーバ２００に送信することなく、ステップＳ１２３で領域確保処理開始要求をリモート発行サーバ４００に送信する。このため、電子マネー管理サーバ２００ではステップＳ２３８で図４に示す利用者情報ＤＢ２２１の処理状況が領域確保済に更新されているにもかかわらず、再度、電子マネー遊技使用サービス用の記憶領域を確保するために携帯端末情報が携帯電話１００から電子マネー管理サーバ２００に送信され、電子マネー管理サーバ２００側で管理している処理状況は領域確保済であるため、要求が受付けられずに領域の確保が行なえないという事態を防止することができる。

一方、処理状況が領域確保情報受信済でないと判断した場合（ステップＳ１９８１においてＮＯの場合）、データ処理部１１０は、実行する処理をステップＳ１９８２に進める。ステップＳ１９８２以降の処理については、後述する。

図１１に戻って、ステップＳ１９８の処理状況確認処理の実行後、データ処理部１１０は、実行する処理をステップＳ１９２に進める。

ステップＳ１９２では、データ処理部１１０は、非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域からバリュー残高を取得して、電子マネーアプリ１１１の起動時初期画面を表示部１４０に表示させる。

図２９に進んで、図２９（ｂ）は、ステップＳ１９２で表示される起動時初期画面である。図２９（ｂ）の画面には、非接触型ＩＣチップ１９０の製造時から与えられているチップＩＤが００００２００００１２３９８であること、ステップＳ１９２で取得された非接触型ＩＣチップ１９０に記憶されているバリューの残高が０円であること、バリューを購入するためのリンクである「バリュー購入（モバイルバンキング経由）」、購入済みのバリューを非接触型ＩＣチップ１９０にチャージするためのリンクである「ＩＣチップへの購入バリューのチャージ」、機種変更時にバリューをサーバに預けるためのリンクである「バリュー預け」、および、機種変更後にサーバに預けたバリューの返却を受けるためのリンクである「預けバリュー返却」が表示される。

（電子マネーシステム１０でのバリューの購入の説明）
図３０は、本実施の形態における電子マネーシステム１０において携帯電話１００でバリューを購入するときに携帯電話１００の表示部１４０に表示される第１の表示画面図である。

図３０（ａ）は、携帯電話１００において、アプリケーション実行機能が実行されるときに、携帯電話１００の表示部１４０に、最初に表示されるソフト一覧画面である。図３０（ａ）の画面には、携帯電話１００に導入されているアプリケーションプログラムを実行させるためのリンクとして、「電子マネーアプリ」および「旅行ナビゲータ」が表示される。つまり、本実施の形態における携帯電話１００には、電子マネーアプリ１１１、および、旅行ナビゲータという名称のアプリケーションプログラムが導入されていることが示される。

図１１に戻って、図３０（ａ）の画面で「電子マネーアプリ」のリンクが選択され、電子マネーアプリ１１１が起動されると、初回起動でなく（ステップＳ１２０でＮＯの場合）、ＩＣチップからの起動でなく（ステップＳ１８０でＮＯの場合）、エラー説明画面からの起動でなく（ステップＳ１１００でＮＯの場合）、エラー対応完了メールからの起動でなく（ステップＳ１１１０でＮＯの場合）、引継ぎ情報からの起動でない（ステップＳ１９１でＮＯの場合）ので、前述したステップＳ１９８の処理状況確認処理において処理状況が領域確保情報受信済でなく（ステップＳ１９８１においてＮＯの場合）、後述する処理状況確認処理のステップＳ１９８２からステップＳ１９８４においてもＮＯである場合、ステップＳ１９２で、データ処理部１１０は、非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の領域からバリュー残高を取得して、電子マネーアプリ１１１の起動時初期画面を表示させる。

図３０に進んで、図３０（ｂ）の画面は、ステップＳ１９２で表示される起動時初期画面である。図３０（ｂ）の画面は、前述した図２９（ｂ）の画面と同様であるので、重複する説明は繰返さない。ただし、非接触型ＩＣチップ１９０に記憶されているバリューの残高が、図２９（ｂ）の画面では、０円であるのに対して、図３０（ｂ）の画面では、１０００円である。また、図３０（ｂ）の画面では、「バリュー購入（モバイルバンキング経由）」のリンクが選択候補として網掛け表示されている。

図１１に戻って、ステップＳ１９３で、データ処理部１１０は、バリュー購入が選択されたか否かを判断する。図３０（ｂ）の画面で「バリュー購入（モバイルバンキング経由）」のリンクが選択されると、データ処理部１１０は、バリュー購入が選択されたと判断し（ステップＳ１９３でＹＥＳ）、ステップＳ１３０で、バリュー購入時処理を実行する。

図１５は、本実施の形態における携帯電話１００により実行される電子マネーアプリ１１１のサブルーチンであるバリュー購入時処理の流れを示すフローチャートである。図１５を参照して、まず、ステップＳ１３３で、データ処理部１１０は、会員ＩＤと携帯端末情報とバリュー残高とを含むチャージ要求情報を電子マネー管理サーバ２００に送信する。

図１６は、本実施の形態における電子マネー管理サーバ２００により実行されるバリュー購入時アプリケーションプログラム２１２の処理の流れを示すフローチャートである。図１６を参照して、まず、ステップＳ２４１で、データ処理部２１０は、携帯電話１００からチャージ要求情報を受信したか否かを判断する。チャージ要求情報を受信していないと判断した場合（ステップＳ２４１でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２５７に進める。

一方、チャージ要求情報を受信したと判断した場合（ステップＳ２４１でＹＥＳの場合）、データ処理部２１０は、ステップＳ２４２で、チャージ要求情報に含まれる会員ＩＤおよび携帯端末情報が利用者情報ＤＢ２２１に登録されたものであり、携帯電話１００が電子マネー遊技使用サービスで利用可能なものであるか否かを判断する。利用可能なものでないと判断した場合（ステップＳ２４２でＮＯの場合）、ステップＳ２４３で、データ処理部２１０は、使用不可画面を携帯電話１００に送信し、実行する処理をステップＳ２４１に戻す。

図３０に進んで、図３０（ｃ）は、ステップＳ２４３で送信される使用不可画面である。図３０（ｃ）の画面には、携帯電話１００が電子マネー管理サーバ２００に登録されていない旨の文章、および、その旨を確認して電子マネーアプリ１１１を終了させるためのリンクである「ＯＫ」が表示される。

図１６に戻って、一方、利用可能なものであると判断した場合（ステップＳ２４２でＹＥＳの場合）、ステップＳ２４４で、データ処理部２１０は、購入済みであるが携帯電話１００にチャージされていない未チャージバリューがあるか否かを判断する。

未チャージバリューがあるか否かについては、ステップＳ２４１で受信したチャージ要求情報に含まれる会員ＩＤおよび携帯端末情報に対応して、図５で説明した発行情報ＤＢ２２２において、処理状況として「未発行」が記憶されているバリューがあるか否かにより判断が行なわれる。本実施の形態においては、処理状況として「未発行」が記憶されているバリューがあると判断した場合には、データ処理部２１０は、未チャージバリューがあると判断する。

なお、未チャージバリューがあるか否かの判断については、このようなものに限るものではない。たとえば、チャージされ携帯電話１００に書込まれたバリューは、発行情報ＤＢ２２２から消去するものであってもよい。そして、未チャージバリューがあるか否かについては、発行情報ＤＢ２２２に未チャージバリューが記憶されているか否かにより判断が行なわれるものであってもよい。

未チャージバリューがあると判断した場合（ステップＳ２４４でＹＥＳの場合）、データ処理部２１０は、ステップＳ２４５で、チャージ誘導画面を携帯電話１００に送信し、実行する処理を後述する図１９のステップＳ２７７に進める。

すなわち、チャージ受付情報としての残高情報を送信するステップである後述するステップＳ２５６に進むことなく、当該未チャージバリューを発行するために、図１９に示すバリュー発行処理に移行する。

図３０に進んで、図３０（ｄ）は、ステップＳ２４５で表示されるチャージ誘導画面である。図３０（ｄ）の画面には、チャージされていないバリューがあるので、チャージを促がす旨の文章が表示される。この画面が表示された後、後述する図１９のバリュー発行時ＡＰ２１３のステップＳ２７７からの処理が実行され、チャージされていないバリューが携帯電話１００にチャージされる。

なお、ここでは、チャージ誘導画面が表示された後、自動的に、ステップＳ２７７からの処理に移行するようにした。しかし、これに限定されず、チャージ誘導画面でユーザからの確認操作があった後に、ステップＳ２７７からの処理に移行するようにしてもよい。

一方、未チャージバリューがないと判断した場合（ステップＳ２４４でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２４６に進める。

次に、ステップＳ２４６で、データ処理部２１０は、ステップＳ２４１で受信したチャージ要求情報を送信してきた携帯電話１００の携帯端末情報に対応する金融機関指定情報を利用者情報ＤＢ２２１から検索して読出す。

また、ステップＳ２４６ａで、データ処理部２１０は、受信したチャージ要求情報に含まれる携帯端末情報で示される携帯電話１００の種別がテスト用であるか通常用であるかを特定する。次いで、ステップＳ２４７で、データ処理部２１０は、特定された携帯電話１００の種別に応じた表示金額リスト情報を読出す。

なお、本実施の形態においては、携帯電話がテスト用であるか通常用であるかの判定は、チャージ要求情報に含まれる携帯端末情報が、利用者情報ＤＢ２２１にテスト用として記憶されているか通常用として記憶されているかによって行なわれる。しかし、これに限定されず、携帯端末情報ごとに利用者情報ＤＢ２２１に記憶された表示金額リスト情報が読出されるようにしてもよい。また、携帯電話１００からテスト用であるか通常用であるかを示す種別識別情報を受信して、その種別識別情報によって示される種別に応じて、それぞれの種別に対応して予め記憶された表示金額リスト情報が読出されるようにしてもよい。

種別に応じた表示金額リスト情報は、電子マネー管理サーバ２００の記憶部２２０に予め記憶される。表示金額リスト情報は、ユーザが携帯電話１００で選択可能なバリューの金額のリストを示す情報であり、本実施の形態においては、通常用の種別に対応して「１０００円」「５０００円」「１００００円」「２００００円」「３００００円」の５つの金額を示す情報あり、テスト用の種別に対応して「１００００円」「５００００円」「１０００００円」「３０００００円」「５０００００円」の５つの金額を示す情報である。選択可能なバリューの金額は、利用者の遊技へののめり込みを防止するために定められた携帯上保持限度額および１日購入限度額に基づいて、電子マネー遊技使用サービスの提供業者によって予め定められる。

ステップＳ２５０では、データ処理部２１０は、ステップＳ２４６ａで特定された携帯電話１００の種別に応じた携帯上保持限度額および１日購入限度額を読出す。

種別に応じた携帯上保持限度額および１日購入限度額は、電子マネー管理サーバ２００の記憶部２２０に予め記憶される。具体的には、前述した図４で説明したように、携帯端末情報に対応させて記憶される。携帯上保持限度額および１日購入限度額は、それぞれ、本実施の形態においては、通常用の種別に対応して「３００００円」「３００００円」の金額を示す情報であり、テスト用の種別に対応して「１００００００円」「５０００００円」の金額を示す情報である。

なお、本実施の形態においては、利用者情報ＤＢ２２１に、端末端末情報と対応付けて、テスト用か通常用かの種別、携帯上保持限度額および１日購入限度額を記憶するようにした。このため、ステップＳ２４１で受信したチャージ要求情報に含まれる携帯端末情報から、テスト用か通常用かの種別、携帯上保持限度額および１日購入限度額をそれぞれ一度に特定することができる。

しかし、これに限定されず、テスト用および通常用の種別に対応してそれぞれ携帯上保持限度額および１日購入限度額を第１のデータベースに記憶するとともに、携帯端末情報と対応付けてテスト用または通常用の種別を示す情報を第２のデータベースに記憶するようにしてもよい。これにより、まず、ステップＳ２４１で受信したチャージ要求情報に含まれる携帯端末情報から、第２のデータベースが参照されて、携帯電話の種別がテスト用であるか通常用であるかが特定され、次に、第１のデータベースが参照されて、特定された種別から携帯上保持限度額および１日購入限度額が特定される。

携帯端末情報の形式をテスト用と通常用とで異ならせ、携帯端末情報の各形式と携帯端末の種別とを対応付けて第１データベース（たとえば、Ｋ−＊＊＊の携帯端末情報は通常用、Ｔ−＊＊＊の携帯端末情報はテスト用）に記憶するとともに、テスト用および通常用の種別に対応してそれぞれの携帯上保持限度額および１日購入限度額を第２データベースに記憶するようにしてもよい。これにより、まず、ステップＳ２４１で受信したチャージ要求情報に含まれる携帯端末情報から第１データベースが参照されて携帯端末の種別が特定され、次に第２データベースが参照されて、特定された種別から携帯上保持限度額および１日購入限度額が特定されるようにしてもよい。

また、テスト用および通常用の種別に対応してそれぞれ携帯上保持限度額および１日購入限度額を第１のデータベースに記憶するとともに、テスト用の携帯電話の携帯端末情報を第２のデータベースに記憶するようにし、通常用の携帯電話の携帯端末情報を第３のデータベースに記憶するようにしてもよい。これにより、まず、ステップＳ２４１で受信したチャージ要求情報に含まれる携帯端末情報が第２のデータベースに含まれるか第３のデータベースに含まれるかによって携帯端末の種別が特定され、次に、第１のデータベースが参照されて、特定された種別から携帯上保持限度額および１日購入限度額が特定される。

また、表示金額リスト情報、携帯上保持限度額、および、１日購入限度額は、それぞれ、テスト用および通常用の２種類の種別に対応して記憶されることに限定されず、３種類以上の種別に対応して記憶されるようにしてもよいし、携帯電話ごとに記憶されるようにしてもよい。また、表示金額リスト情報に含まれる金額、携帯上保持限度額、および、１日購入限度額は、それぞれ、他の金額であってもよく、それぞれ任意に設定可能である。

次いで、ステップＳ２５１で、データ処理部２１０は、ステップＳ２４１で受信したチャージ要求情報に含まれる携帯電話１００にチャージされているバリュー残高に、ステップＳ２４７で読出した表示金額リスト情報で示される金額のうちの最低購入金額（チャージ要求時に選択可能な最低金額であり、本実施例においては、図３２（ｂ）、図３３に示す表示金額リストにおける最低の金額であり、図３２（ｂ）の通常用の表示金額リストの場合１０００円、テスト用の表示金額リストの場合１００００円）を加算した額が、ステップＳ２５０で読出した携帯上保持限度額以下であるか否かを判断する。つまり、バリュー残高と携帯上保持限度額とに基づいてチャージを許容するか否かを判定する。バリュー残高に最低購入金額を加算した額が携帯上保持限度額以下でない場合（ステップＳ２５１でＮＯの場合）、チャージを許容せず、ステップＳ２５２で、データ処理部２１０は、携帯上保持限度額購入不可画面を携帯電話１００に送信した後、実行する処理をステップＳ２４１に戻す。

図３１は、本実施の形態における電子マネーシステム１０において携帯電話１００でバリューを購入するときに携帯電話１００の表示部１４０に表示される第２の表示画面図である。図３１（ａ）は、ステップＳ２５２で携帯電話１００に送信される携帯上保持限度額購入不可画面である。図３１（ａ）の画面には、最低購入金額とバリュー残高との合計が携帯上保持限度額を超えるので、バリューを購入できない旨の文章、および、その旨を確認して電子マネーアプリ１１１を終了させるためのリンクである「ＯＫ」が表示される。

図１６に戻って、一方、バリュー残高に最低購入金額を加算した額が携帯上保持限度額以下である場合（ステップＳ２５１でＹＥＳの場合）、ステップＳ２５３で、データ処理部２１０は、発行情報ＤＢ２２２に記憶されているその日に携帯電話１００によって購入されたバリューの当日積算額に、最低購入金額を加算した額が１日購入限度額以下であるか否かを判断する。つまり、当日積算額と１日購入限度額とに基づいてチャージを許容するか否かを判定する。当日積算額に最低購入金額を加算した額が１日購入限度額以下でない場合（ステップＳ２５３でＮＯの場合）、チャージを許容せず、ステップＳ２５４で、データ処理部２１０は、１日購入限度額購入不可画面を携帯電話１００に送信した後、実行する処理をステップＳ２４１に戻す。

図３１に進んで、図３１（ｂ）は、ステップＳ２５４で携帯電話１００に送信される１日購入限度額購入不可画面である。図３１（ｂ）の画面には、最低購入金額と当日積算額との合計が１日購入限度額を超えるので、バリューを購入できない旨の文章、および、その旨を確認して電子マネーアプリ１１１を終了させるためのリンクである「ＯＫ」が表示される。

図１６に戻って、一方、当日積算額に最低購入金額を加算した額が１日購入限度額以下である場合（ステップＳ２５３でＹＥＳの場合）、ステップＳ２５５で、データ処理部２１０は、バリュー残高および当日積算額から購入可能金額を算出する。具体的には、データ処理部２１０は、携帯上保持限度額からバリュー残高を減算した額、および、１日購入限度額から当日積算額を減算した額のうち、低い方の額を購入可能金額として算出する。

なお、本実施の形態においては、バリュー残高および携帯上保持限度額、ならびに、当日積算額および１日購入限度額に基づいて、バリューを購入可能か否かを判断して、購入可能金額を算出するようにした。しかし、これに限定されず、バリュー残高および携帯上保持限度額、または、当日積算額および１日購入限度額に基づいて、バリューを購入可能か否かを判断して、購入可能金額を算出するようにしてもよい。

次に、ステップＳ２５６で、データ処理部２１０は、ステップＳ２４１で受信したチャージ要求情報に含まれる携帯端末情報に対応して利用者情報ＤＢ２２１に記憶されている電子メールアドレス、ステップＳ２４６で読出した金融機関指定情報、ステップＳ２４７で読出した携帯端末情報の携帯電話の種別に応じた表示金額リスト情報、ステップＳ２５０で読出した携帯上保持限度額、１日購入限度額、および、ステップＳ２５５で算出した購入可能金額情報を、残高情報（チャージ要求情報を受付けた旨を示すチャージ受付情報）として携帯電話１００に送信する。

図１５に戻って、ステップＳ１３４で、データ処理部１１０は、電子マネー管理サーバ２００から残高情報を受信したか否かを判断する。残高情報を受信したと判断した場合（ステップＳ１３４でＹＥＳの場合）、ステップＳ１３５で、データ処理部１１０は、受信した残高情報に含まれる電子メールアドレスがバリューの購入に用いる電子メールアドレスとして正しいか否かを確認するためのアドレス確認画面を表示部１４０に表示させる。その後、データ処理部１１０は、実行する処理をステップＳ１３６に進める。

図３１に進んで、図３１（ｃ）は、ステップＳ１３５で表示されるアドレス確認画面である。図３１（ｃ）の画面には、バリューのチャージの方法を説明するための文章、ステップＳ１３４で受信した残高情報に含まれる確認の対象である電子メールアドレス、表示されている電子メールアドレスが電子マネー遊技使用サービスで利用する携帯電話１００の電子メールアドレスとして正しいと確認したことを入力するためのリンクである「確認」、および、表示されている電子メールアドレスが電子マネー遊技使用サービスで利用する携帯電話１００の電子メールアドレスと異なる場合に選択するリンクである「→上記アドレスがご利用携帯のアドレスと異なる場合はこちら」が表示される。

図１５に戻って、ステップＳ１３６で、データ処理部１１０は、図３１（ｃ）の画面で「確認」のリンクが選択されることによって、ユーザにより電子メールアドレスが確認されたか否かを判断する。アドレスが確認されたと判断した場合（ステップＳ１３６でＹＥＳの場合）、ステップＳ１３７で、データ処理部１１０は、金融機関確認画面を表示部１４０に表示させる。

図３２は、本実施の形態における電子マネーシステム１０において携帯電話１００でバリューを購入するときに携帯電話１００の表示部１４０に表示される第３の表示画面図である。

図３２（ａ）は、ステップＳ１３７で携帯電話１００に表示される金融機関確認画面である。図３２（ａ）の画面には、利用するモバイルバンキングを確認する旨の文章、利用するモバイルバンキングの金融機関の名称、利用するモバイルバンキングを確認して継続して手続を進めるためのリンクである「確認」、および、金融機関を変更するためのリンクである「金融機関変更の場合はこちらを選択してください。」が表示される。金融機関の名称は、受信した残高情報に含まれる金融機関指定情報は、金融機関の名称に対応して予め一意に定められている。このため、金融機関の名称は、残高情報を受信することにより、携帯電話１００によって特定され得る。

図１５に戻って、ステップＳ１３８で、データ処理部１１０は、図３２（ａ）の画面で「確認」のリンクが選択されることによって、利用するモバイルバンキングの金融機関がユーザにより確認されたか否かを判断する。

金融機関が確認されていないと判断した場合（ステップＳ１３８でＮＯの場合）、ステップＳ１４０ａで、データ処理部１１０は、金融機関変更が選択されたか否かを判断する。金融機関変更が選択されていないと判断した場合（ステップＳ１４０ａでＮＯの場合）、データ処理部１１０は、実行する処理をステップＳ１３８の処理に戻す。

一方、金融機関変更が選択されたと判断した場合（ステップＳ１４０ａでＹＥＳの場合）、データ処理部１１０は、ステップＳ１４０ｂで金融機関変更問合せ情報を電子マネー管理サーバ２００に送信し、ステップＳ１４０ｄで電子マネー管理サーバ２００の利用者情報ＤＢ２２１に携帯端末情報と対応させて登録されている金融機関指定情報を他の金融機関指定情報に変更するための金融機関変更処理が行なわれ、実行する処理をステップＳ１３８の処理に戻す。金融機関変更処理においては、変更した金融機関の金融機関指定情報が送信される。

電子マネー管理サーバ２００のデータ処理部２１０は、携帯電話１００から金融機関変更問合せ情報を受信した場合、金融機関変更問合せ情報に対応する画面（図２７（ｃ），（ｄ），図２８（ａ）等参照）を携帯電話１００に送信する。そして、電子マネー管理サーバ２００のデータ処理部２１０は、携帯電話１００から金融機関指定情報（ユーザから変更先として指定を受付けた金融機関を指定する情報）を受信したと判断した場合、変更した金融機関の金融機関指定情報を、携帯端末情報に対応させて、利用者情報ＤＢ２２１に登録する処理を行なう。

なお、登録する処理としては、変更した金融機関のサーバが決済に利用される状態に更新するものであればよく、たとえば、変更前の金融機関の金融機関指定情報を消去して新たに変更後の金融機関の金融機関指定情報を登録する処理であってもよい。また、変更前の金融機関の金融機関指定情報を消去することなく変更後の金融機関の金融機関指定情報を決済に利用する金融機関として新たに登録する処理であってもよい。この場合、変更前の金融機関の金融機関指定情報を用いて、再度決済に利用する金融機関を変更前の金融機関に変更できるものであってもよい。

金融機関が確認されたと判断した場合（ステップＳ１３８でＹＥＳの場合）、データ処理部１１０は、ステップＳ１３９で、残高情報に含まれる表示金額リスト情報、携帯上保持限度額、１日購入限度額および購入可能金額情報でそれぞれ示される表示金額リストおよび購入可能金額に応じて、購入金額選択画面を表示部１４０に表示させる。

図３２に進んで、図３２（ｂ）は、ステップＳ１３９で通常用の携帯電話１００に表示される購入金額選択画面である。図３２（ｂ）の画面には、購入してチャージを希望するバリューの金額の選択を促がす旨の文章、１日購入限度額を示す文章、携帯上保持限度額に関する文章、購入希望金額の選択肢と対をなしたラジオボタン、および、選択されたバリューの購入希望金額の送信を指示するためのリンクである「送信」が表示される。

図３２（ｂ）の購入金額選択画面に表示される購入希望金額の選択肢、１日購入限度額、および、携帯上保持限度額は、それぞれ、電子マネー管理サーバ１０によってこの携帯電話１００が通常用の携帯電話であると判定されたことに応じて送信されてきた残高情報に含まれる表示金額リスト情報、１日購入限度額、および、携帯上保持限度額でそれぞれ示される「１０００円，５０００円，１００００円，２００００円，３００００円」「３００００円」および「３００００円」である。

ここで、ステップＳ１３４で受信された残高情報に含まれる購入可能金額情報で示される購入可能金額を超える金額の選択肢と対をなすラジオボタンは、表示されるが、選択できない。また、購入希望金額の選択肢と対をなすラジオボタンのいずれかが選択されない限り、「送信」のリンクを選択することはできない。なお、本実施の形態においては、購入希望金額を超える金額の選択肢と対をなすラジオボタンも表示される例について説明したが、これに限らず、購入可能金額の範囲内の金額の選択肢と対をなすラジオボタンのみを表示させ、購入可能金額を超える金額の選択肢と対をなすラジオボタンを表示させないようにしてもよい。また、購入可能金額を超える金額の選択肢を表示させないようにしてもよい。つまり、購入可能金額以下のチャージ額の選択肢を指定可能な表示態様で表示させればよい。

図３３は、本実施の形態における電子マネーシステム１０において携帯電話１００でバリューを購入するときに携帯電話１００の表示部１４０に表示される第４の表示画面図である。図３３（ａ）は、ステップＳ１３９でテスト用の携帯電話１００に表示される購入金額選択画面である。図３３（ａ）の画面は、図３２（ｂ）の画面と比較して、購入希望金額の選択肢、１日購入限度額、および、携帯上保持限度額が異なる。

図３３（ａ）の購入金額選択画面に表示される購入希望金額の選択肢、１日購入限度額、および、携帯上保持限度額は、それぞれ、電子マネー管理サーバ１０によりこの携帯電話１００がテスト用の携帯電話であると判定されたことに応じて送信されてきた残高情報に含まれる表示金額リスト情報、１日購入限度額、および、携帯上保持限度額でそれぞれ示される「１００００円，５００００円，１０００００円，３０００００円，５０００００円」「５０００００円」および「１００００００円」である。

図１５に戻って、図３２（ｂ）の画面または図３３（ａ）の画面で、購入希望金額と対をなすラジオボタンのいずれかが選択され、「送信」のリンクが選択されると、ステップＳ１４１で、携帯電話１００のデータ処理部１１０は、購入希望金額のラジオボタンが選択されることによって、購入希望金額が選択されたか否かを判断する。

購入希望金額が選択されたと判断した場合（ステップＳ１４１でＹＥＳの場合）、データ処理部１１０は、ステップＳ１４２で、選択を受付けた購入希望金額および会員ＩＤを示す情報を含む第１口座振替依頼情報を電子マネー管理サーバ２００に送信する。

図１６に進んで、ステップＳ２５７で、データ処理部２１０は、携帯電話１００から第１口座振替依頼情報を受信したか否かを判断する。第１口座振替依頼情報を受信していないと判断した場合（ステップＳ２５７でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２６５に進める。

一方、第１口座振替依頼情報を受信したと判断した場合（ステップＳ２５７でＹＥＳの場合）、ステップＳ２５８で、データ処理部２１０は、バリュー購入回数カウンタで携帯電話１００ごとに計数されているバリュー購入回数が０回か否かを判断する。つまり、携帯電話１００からチャージ要求が送信されステップＳ２４１においてＹＥＳと判断されたのが、ステップＳ２３６によって領域確保情報が携帯電話１００に送信されてから初回であるか否かが判断される。

バリュー購入回数が０回であると判断した場合（ステップＳ２５８でＹＥＳの場合）、携帯電話１００が電子マネー遊技使用サービスに登録されてから最初のバリューの購入であるので、初期登録手数料を徴収する必要がある。そこで、この場合、ステップＳ２５９で、データ処理部２１０は、初期登録手数料およびチャージ手数料を算出する。

一方、バリュー購入回数が０回でないと判断した場合（ステップＳ２５８でＮＯの場合）、すでに、初期登録手数料は徴収されているので、初期登録手数料を徴収しなくてもよい。そこで、この場合、ステップＳ２６０で、データ処理部２１０は、チャージ手数料を算出する。

なお、本実施の形態においては、ステップＳ２５９およびステップＳ２６０で、初期登録手数料およびチャージ手数料をそれぞれ算出するようにしたが、これに限定されず、初期登録手数料およびチャージ手数料を予め記憶部２２０に記憶させておき、それぞれ、ステップＳ２５９およびステップＳ２６０で読出すようにしてもよい。

次に、データ処理部２１０は、ステップＳ２６１で、今回のバリュー購入を他のバリュー購入と識別するための購入番号を発行し、ステップＳ２６２で、ステップＳ２５７で受信した第１口座振替依頼情報で示される購入希望金額と、ステップＳ２５９またはステップＳ２６０で算出された手数料との合計金額を算出する。

次いで、データ処理部２１０は、ステップＳ２６３で、ステップＳ２６２で算出した合計金額、ステップＳ２６１で発行した購入番号、および、現在の時刻であるタイムスタンプを、会員ＩＤに対応させて発行情報ＤＢ２２２に登録する。そして、データ処理部２１０は、ステップＳ２６４で、合計金額をユーザに確認するための合計金額確認画面を表示させるための合計金額確認情報を携帯電話１００に送信する。

図１５に戻って、ステップＳ１４３で、データ処理部１１０は、電子マネー管理サーバ２００から合計金額確認情報を受信したか否かを判断する。合計金額確認情報を受信したと判断した場合（ステップＳ１４３でＹＥＳの場合）、ステップＳ１４４で、データ処理部１１０は、合計金額確認情報に基づいて、合計金額確認画面を表示部１４０に表示させる。

図３２に進んで、図３２（ｃ）は、ステップＳ１４４で表示される合計金額確認画面である。図３２（ｃ）の画面には、合計金額の確認を求める旨の文章、合計金額を確認して第２口座振替依頼情報を送信するためのリンクである「確認」、および、１つ前の図３２（ｂ）の購入金額選択画面に戻るためのリンクである「こちら。」とが表示される。

図１５に戻って、ステップＳ１４５で、データ処理部１１０は、図３２（ｃ）の画面で「確認」のリンクが選択されることによって、ユーザにより合計金額が確認されたか否かを判断する。合計金額が確認されたと判断した場合（ステップＳ１４５でＹＥＳの場合）、モバイルバンキング確認画面が表示される（ステップＳ１４５ａ）。

図３２に進んで、図３２（ｄ）は、ステップＳ１４５ａで表示されるモバイルバンキング確認画面である。図３２（ｄ）の画面には、手続がモバイルバンキングへ遷移される旨の文章、その旨の確認を入力するためのリンクである「確認」、および、図３０（ｂ）の起動時初期画面に戻るためのリンクである「手続を中止する（アプリのメニュー画面に戻る）」が表示される。

図１５に戻って、ステップＳ１４５ｂでデータ処理部１１０は、図３２（ｄ）の画面で「確認」のリンクが選択されることによって、ユーザによりモバイルバンキングへの遷移が確認されたか否かを判断する。モバイルバンキングへの遷移が確認されたと判断した場合（ステップＳ１４５ｂでＹＥＳの場合）、ステップＳ１４６で、データ処理部１１０は、会員ＩＤを示す情報を含む第２口座振替依頼情報を電子マネー管理サーバ２００に送信し、バリュー購入時処理を終了する。以降、後述するように、電子マネー管理サーバ２００から送信される引継画面情報の受信に応じて、引継時ウェブ処理が実行される。

図１６に進んで、ステップＳ２６５で、データ処理部２１０は、携帯電話１００から第２口座振替依頼情報を受信したか否かを判断する。第２口座振替依頼情報を受信していないと判断した場合（ステップＳ２６５でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２６９に進める。

一方、第２口座振替依頼情報を受信したと判断した場合（ステップＳ２６５でＹＥＳの場合）、ステップＳ２６６で、データ処理部２１０は、ステップＳ２６３で登録したタイムスタンプと現在の時刻とを比較するタイムスタンプチェックを実行し、異常があるか否かを判断する。たとえば、タイムスタンプと現在の時刻との差が規定時間以上である場合に異常があると判断する。

異常があると判断した場合（ステップＳ２６６でＹＥＳの場合）、ステップＳ２６７で、データ処理部２１０は、タイムスタンプチェックエラー画面を携帯電話１００に送信する。

図３２に進んで、図３２（ｅ）は、ステップＳ２６７で携帯電話１００に送信されるタイムスタンプチェックエラー画面である。図３２（ｅ）の画面には、購入希望金額を選択してから一定時間が経過したので、手続のやり直しを促がす旨の文章、および、図３０（ｂ）の起動時初期画面に戻るためのリンクである「手続を中止する（アプリのメニュー画面に戻る）」が表示される。

図１６に戻って、一方、異常がないと判断した場合（ステップＳ２６６でＮＯの場合）、データ処理部２１０は、ステップＳ２６８で、モバイルバンキングへ遷移させるための引継画面情報を携帯電話１００に送信する。引継画面情報には、少なくとも、ステップＳ２４６において検索され読み出された当該携帯電話１００の携帯端末情報に対応付けて登録されている金融機関情報から特定される金融機関の金融機関サーバ５００のインターネットバンキングシステムにアクセス可能となる通信先指定情報としてのＵＲＬが含まれる。

図１０（ｂ）は、ウェブ処理のうち引継時ウェブ処理の流れを示すフローチャートである。引継時ウェブ処理は、ステップＳ２６８で送信される引継画面情報の受信に応じて実行される。図１０（ｂ）を参照して、ステップＳ１１７で、データ処理部１１０は、電子マネー管理サーバ２００から引継画面情報を受信したか否かを判断する。引継画面情報を受信したと判断した場合（ステップＳ１１７でＹＥＳの場合）、ステップＳ１１８で、データ処理部１１０は、引継画面情報に基づいて、モバイルバンキングへ遷移する旨を報知するためのモバイルバンキング遷移確認画面を表示部１４０に表示し、ステップＳ１１８ａで、モバイルバンキングでのバリューの購入に対する決済の処理を行なうモバイルバンキング処理を実行する。モバイルバンキング処理では、操作に応じてバリューの購入に対する決済に関する情報を金融機関サーバ５００に送信し、決済が完了すると引継時ウェブ処理が終了する。具体的には、引継画面情報に含まれるＵＲＬの示す金融機関サーバ５００のインターネットバンキングシステムにアクセスし、予め登録されている自己のモバイルバンキング口座にログインして振込み処理を行なうことで、ステップＳ１４３で受信した合計金額確認情報から特定される合計金額の決済要求を金融機関サーバ５００に送信することとなる。なお、この際、ステップＳ１４３で受信した合計金額確認情報から特定される合計金額についても、金融機関サーバ５００に送信されるため、ログイン後の入力操作が軽減される。ここで、このモバイルバンキング処理は、現在、各金融機関が提供しているモバイルバンキングのシステムを利用するものであるから詳細な説明は省略する。

このように、本実施の形態においては、バリューのチャージに関する対価の決済のための決済用処理として、金融機関によるモバイルバンキングを利用することで、当該モバイルバンキングによる振込み処理の時点で決済が完了するものとしているが、決済用処理としては、このように処理の時点で決済が完了するものに限らず、たとえばクレジットカード提供機関のサーバに対してチャージに関する対価の決済を要求し、クレジットカード提供機関のサーバが与信による決済を行ない、実際の決済は後日に行なわれるような処理でもよい。

図１に戻って、バリュー購入に対する決済が完了すると、金融機関サーバ５００から決済サーバ２８０に、バリュー購入に対する決済が完了した旨の消込電文が送信される。

決済サーバ２８０は、受信した消込電文を請求情報ＤＢ２８１に登録する。そして、決済サーバ２８０は、受信した消込電文に対応する消込速報を電子マネー管理サーバ２００に送信する。

図１６に進んで、ステップＳ２６９で、データ処理部２１０は、決済サーバ２８０から消込速報を受信したか否かを判断する。消込速報を受信したと判断した場合（ステップＳ２６９でＹＥＳの場合）、データ処理部２１０は、ステップＳ２７０で、バリュー対価決済後処理を実行する。バリュー対価決済後処理については、図１７で説明する。一方、消込速報を受信していないと判断した場合（ステップＳ２６９でＮＯの場合）、または、ステップＳ２７０の後、データ処理部２１０は、実行する処理をステップＳ２４１に戻す。

図１７は、本実施の形態における電子マネー管理サーバ２００により実行されるバリュー購入時アプリケーションプログラム２１２のサブルーチンであるバリュー対価決済後処理の流れを示すフローチャートである。

図１７を参照して、まず、電子マネー管理サーバ２００のデータ処理部２１０は、ステップＳ２７００で、ステップＳ２６９で決済サーバ２８０から受信した消込速報で示される購入番号が発行情報ＤＢ２２２に登録されているか否かを判断する。購入番号が登録されていないと判断した場合（ステップＳ２７００でＮＯの場合）、ステップＳ２７０１で、データ処理部２１０は、エラー処理を行なう。たとえば、警報を発生して、電子マネー管理サーバ２００の管理者が確認できるようにする。そして、確認操作後、データ処理部２１０は、実行する処理をこの処理の呼出元の処理であるバリュー購入時ＡＰ２１２に戻す。

一方、購入番号が登録されていると判断した場合（ステップＳ２７００でＹＥＳの場合）、ステップＳ２７０２で、データ処理部２１０は、購入番号で示されるバリューの購入が、その購入番号と対応する携帯電話１００での初回の購入であるか否かを判断する。具体的には、その携帯電話１００に対応するバリュー購入回数カウンタのカウント値が０であるか否かを判断する。

初回の購入であると判断した場合（ステップＳ２７０２でＹＥＳの場合）、ステップＳ２７０３で、データ処理部２１０は、未チャージ削除カウンタのカウント値を０にする。なお、初回の購入であると判断した場合には、データ処理部２１０は、未チャージ削除カウンタのカウント値を１減算するものであってもよい。その後、データ処理部２１０は、実行する処理をステップＳ２７０４に進める。一方、初回の購入でないと判断した場合（ステップＳ２７０２でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２７０４に進める。

次に、ステップＳ２７０４で、データ処理部２１０は、購入番号に対応する会員ＩＤに対応するバリュー購入記録を更新する。ここでは、未チャージバリューが有りとなるように設定する処理が行なわれる。具体的には、図５の発行情報ＤＢ２２２に、バリューの額を特定するための情報（たとえば、購入額が１０００円である場合は「１０００」）と、その額が未チャージであることを示す処理状況（たとえば、「未発行」）とが対応付けられて記憶される。これにより、ステップＳ２４１における判断により受信したチャージ要求に対応するバリューであって、当該チャージ要求元の携帯電話１００にチャージ可能となった未チャージバリューを特定するためのバリュー購入記録（特定用情報）を登録する手段が構成されている。

そして、データ処理部２１０は、ステップＳ２７０５で、バリュー購入回数カウンタのカウント値を１加算し、ステップＳ２７０６で、携帯電話１００に対応する当日積算額に購入金額を加算して、当日積算額を更新し、ステップＳ２７０７で、携帯電話１００に対応するチャージ累計額に購入金額を加算して、チャージ累計額を更新し記憶する。

次いで、ステップＳ２７０８で、データ処理部２１０は、ステップＳ２７００で受信した消込速報を正常に処理した旨の応答情報を決済サーバ２８０に送信する。そして、ステップＳ２７０９で、データ処理部２１０は、引継ぎ情報を付した電子メールを、消込速報に対応する会員ＩＤの電子メールアドレス宛に送信する。その後、データ処理部２１０は、バリュー対価決済後処理を終了し、実行する処理をこの処理の呼出元に戻す。

引継ぎ情報としては、リンク情報が含まれる。本実施の形態におけるリンク情報には、後述する電子マネーアプリ１１１を自動的に起動させるための情報が含まれている。電子マネーアプリ１１１が起動されると、引継ぎ情報からの起動である（ステップＳ１９１でＹＥＳである）ので、後述する図１８で説明するバリュー発行時処理が実行される。

（電子マネーシステム１０でのバリューのチャージの説明）
図３４は、本実施の形態における電子マネーシステム１０において携帯電話１００にバリューをチャージする（書込む）ときに携帯電話１００の表示部１４０に表示される第１の表示画面図である。

図３４（ａ）は、携帯電話１００の電子メール機能において、新着メッセージの件数を示す画面である。ここでは、「メール 未読００１」の表示によって、新着の電子メールのうち、未読のものが１件であることが示されている。

図３４（ａ）の画面で、「メール 未読００１」が選択されると、図３４（ｂ）のように、ステップＳ２７０９で、電子マネー管理サーバ２００から携帯電話１００に送信された新着メールの内容が表示される。

図３４（ｂ）の電子メールには、購入されたバリューが電子マネー管理サーバ２００に登録された旨、および、購入されたバリューをチャージするための引継ぎ情報としてのリンクである「ここをクリックしてアプリを起動し、ＩＣチップへのチャージを行ってください。」が表示される。図３４（ｂ）の画面で、このリンクが選択されると、電子マネーアプリ１１１が起動される。

図１１に戻って、図３４（ｂ）の画面で、引継ぎ情報としてのリンクが選択され、電子マネーアプリ１１１が起動されると、ステップＳ１９１で、データ処理部１１０は、引継ぎ情報からの起動であると判断して、実行する処理をステップＳ１５０に進める。

また、ステップＳ１９４で、データ処理部１１０は、図３０（ｂ）で説明した起動時初期画面で「ＩＣチップへの購入バリューのチャージ（最新残高更新）」のリンクが選択されることによって、バリュー発行が選択されたか否かを判断する。バリュー発行が選択された場合（ステップＳ１９４でＹＥＳの場合）、データ処理部１１０は、実行する処理をステップＳ１５０に進める。

ステップＳ１５０では、データ処理部１１０は、後述する図１８で説明するバリュー発行時処理を実行する。

本実施の形態においては、電子メールに付された引継ぎ情報としてのリンクが選択されると、電子マネーアプリ１１１が自動的に起動され、ステップＳ１５０でバリュー発行時処理が実行されるようにした。しかし、これに限定されず、リンクが選択されると、電子マネーアプリ１１１が自動的に起動され、図３０（ｂ）で説明した起動時初期画面が表示され、ユーザによりバリューのチャージのリンクが選択されることによってバリュー発行時処理が実行されるようにしてもよい。また、リンクが選択されると、図３０（ａ）で説明した画面が表示され、ユーザにより電子マネーアプリ１１１が起動され、バリューのチャージのリンクが選択されることによってバリュー発行時処理が実行されるようにしてもよい。

図１８は、本実施の形態における携帯電話１００により実行される電子マネーアプリ１１１のサブルーチンであるバリュー発行時処理の流れを示すフローチャートである。図１８を参照して、まず、ステップＳ１５１で、データ処理部１１０は、記憶部１２０に記憶されている処理状況が発行情報受信済であるか否かを判断する。処理状況は、後述するように、ステップＳ１５３で、バリュー発行情報が電子マネー管理サーバ２００から受信されることを条件として、ステップＳ１５３ａで、発行情報受信済に更新される。

処理状況が発行情報受信済であると判断した場合（ステップＳ１５１においてＹＥＳの場合）、データ処理部１１０は、実行する処理をステップＳ１５４に進める。一方、処理状況が発行情報受信済でないと判断した場合（ステップＳ１５１においてＮＯの場合）、ステップＳ１５２で、データ処理部１１０は、バリューのチャージ（発行）を要求するための情報であって会員ＩＤおよび携帯端末情報を含むバリュー発行要求情報を、電子マネー管理サーバ２００に送信する。

つまり、本実施の形態においては、電子マネーの発行を要求するための発行操作として、図３０（ｂ）の起動時初期画面において「ＩＣチップへの購入バリューのチャージ」のリンクの選択操作、または、電子メールに添付された引継ぎ情報としてのリンクの操作をユーザから受付けたことを条件として、具体的には、発行操作をユーザから受付け、さらに、記憶部１２０に記憶されている処理状況が発行情報受信済でないことを条件として、電子マネーの発行を要求するためのバリュー発行要求情報を電子マネー管理サーバ２００に送信する。

図１９は、本実施の形態における電子マネー管理サーバ２００により実行されるバリュー発行時アプリケーションプログラム２１３の処理の流れを示すフローチャートである。

図１９を参照して、まず、ステップＳ２７１で、データ処理部２１０は、携帯電話１００からバリュー発行要求情報を受信したことによって、バリュー発行要求があったか否かを判断する。バリュー発行要求がないと判断した場合（ステップＳ２７１でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２７１に戻す。

一方、バリュー発行要求があったと判断した場合（ステップＳ２７１でＹＥＳの場合）、ステップＳ２７２で、データ処理部２１０は、ステップＳ２７１で受信したバリュー発行要求情報に含まれる会員ＩＤおよび携帯端末情報が利用者情報ＤＢ２１１に登録された利用可能なものであるか否かを判断する。利用可能なものでないと判断した場合（ステップＳ２７２でＮＯの場合）、ステップＳ２７３で、データ処理部２１０は、使用不可画面を携帯電話１００に送信する。使用不可画面は、図３０（ｃ）で説明した画面と同様の画面である。

一方、利用可能なものであると判断した場合（ステップＳ２７２でＹＥＳの場合）、ステップＳ２７４で、データ処理部２１０は、会員ＩＤおよび携帯端末情報に対応する未チャージバリューが発行情報ＤＢ２２２に記憶されているか否かを判断する。未チャージバリューがないと判断した場合（ステップＳ２７４でＮＯの場合）、ステップＳ２７５で、データ処理部２１０は、未チャージバリュー無画面を携帯電話１００に送信する。なお、バリュー発行時ＡＰ２１３において、ステップＳ２７４およびステップＳ２７５の処理を実行する場合を説明したが、これに限らず、バリュー発行時ＡＰ２１３において、ステップＳ２７４およびステップＳ２７５の処理を実行しないものであってもよい。

図３４に進んで、図３４（ｃ）は、ステップＳ２７５で携帯電話１００に送信される未チャージバリュー無画面である。図３４（ｃ）の画面には、未受取のバリューが無い旨の文章、および、その旨を確認して電子マネーアプリ１１１を終了させるためのリンクである「ＯＫ」が表示される。

図１９に戻って、未チャージバリューがあると判断した場合（ステップＳ２７４でＹＥＳの場合）、チャージ要求時に未チャージバリューがあると判断した場合（ステップＳ２４４でＹＥＳの場合）、および後述する残高移行依頼時に未チャージバリューがあると判断した場合（ステップＳ２０６４でＹＥＳの場合）、データ処理部２１０は、ステップＳ２７７で、未チャージバリューのバリュー購入記録から特定される額のバリューをリモート発行サーバ４００から携帯電話１００に書込ませるためのバリュー発行情報を携帯電話１００に送信する。バリュー発行情報は、少なくとも書込み可能なバリューを含む。

これにより、ステップＳ２７１における判断によりバリュー発行要求を受信したことを条件として、さらには、バリュー発行要求情報に含まれる会員ＩＤに対応付けて発行情報ＤＢのバリュー購入記録にて管理されているバリューの処理状況（発行状況）が未発行であることを条件として、発行情報ＤＢ２２２に登録されている会員ＩＤに対応するバリュー購入記録（特定用情報）から特定される未チャージバリューを、当該バリュー発行要求元の携帯電話１００に送信するために出力する手段が構成されている。

図１８に戻って、ステップＳ１５３で、データ処理部１１０は、電子マネー管理サーバ２００からバリュー発行情報を受信したか否かを判断する。バリュー発行情報を受信したと判断した場合（ステップＳ１５３でＹＥＳの場合）、ステップＳ１５３ａで、データ処理部１１０は、記憶部１２０で管理している処理状況を、発行情報受信済（データ受信済）に更新する。なお、発行情報受信済の処理状況は、後述するステップＳ１５７ａで処理状況が書込済に更新される前であるので、バリューが未書込の処理状況に相当する。

そして、ステップＳ１５３ｂで、データ処理部１１０は、バリュー発行情報を受信したことを電子マネー管理サーバ２００に知らせるための受信応答情報を、電子マネー管理サーバ２００に送信する。

図１９に進んで、ステップＳ２７８で、データ処理部２１０は、携帯電話１００から受信応答情報を受信したか否かを判断する。受信応答情報を受信していないと判断した場合（ステップＳ２７８においてＮＯの場合）、データ処理部２１０は、ステップＳ２７８の処理を繰返す。一方、受信応答情報を受信したと判断した場合（ステップＳ２７８においてＹＥＳの場合）、ステップＳ２７９で、データ処理部２１０は、図５の発行情報ＤＢ２２２の処理状況を発行済に更新する。つまり、ステップＳ２７７でバリュー発行情報を送信したことを条件として、処理状況を発行済に更新する。その後、データ処理部２１０は、実行する処理をステップＳ２７１に戻す。

図１８に戻って、次に、ステップＳ１５４で、データ処理部１１０は、非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域に、バリュー発行情報から特定されるバリューを記憶させる書込処理を開始させるための情報であって、バリューの購入番号および携帯端末情報を含む書込処理開始要求情報（購入バリューの書込みを要求する書込要求情報）をリモート発行サーバ４００へ送信する。

図１に戻って、リモート発行サーバ４００は、バリュー書込実行情報を、書込処理開始要求情報に含まれる携帯端末情報で示される携帯電話１００に送信する。バリュー書込実行情報は、携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域に、書込み処理開始要求情報に含まれるバリュー発行額情報で示される額のバリューを記憶させるための情報である。

具体的には、リモート発行サーバ４００は、バリューの書込状況を記憶する書込状況記憶部を備えており、当該書込状況記憶部には、書込処理開始要求に含まれる購入番号と携帯端末情報とが対応付けて記憶されるとともに、当該バリューを書込済か否かを示すフラグを記憶する領域が設けられている。

そして、リモート発行サーバ４００は、携帯電話１００から書込処理開始要求を受信すると、該書込処理開始要求に含まれる購入番号および携帯端末情報が書込状況記憶部に記憶されているか否かを判定するとともに、記憶されている場合にはさらに、対応するフラグが書込済か否かを判定する。

かかる判定において、購入番号および携帯端末情報が記憶されていないか、あるいは記憶されているが対応するフラグが書込済でないと判定された場合、つまり、書込状況記憶部（書込状況管理手段）における管理状況が未書込である場合には、バリュー書込実行情報を携帯電話１００に送信する。

一方、購入番号および携帯端末情報が記憶されており、かつ対応するフラグが書込済であると判定された場合、つまり、書込状況記憶部（書込状況管理手段）における管理状況が書込済である場合には、バリュー書込実行情報を送信しない。また、購入番号および携帯端末情報が記憶されていないと判定された場合には、当該購入番号および携帯端末情報を書込状況記憶部に新たに記憶し、書込状況の管理を開始する。

図１８に進んで、データ処理部１１０は、ステップＳ１５５で、リモート発行サーバ４００からバリュー書込実行情報を受信したか否かを判断する。バリュー書込実行情報を受信したと判断した場合（ステップＳ１５５でＹＥＳの場合）、ステップＳ１５６で、データ処理部１１０は、リモート発行サーバ４００から受信したバリュー書込実行情報で示される書込処理を実行する。書込処理は、バリュー発行情報から特定されるバリューの額を示すバリュー発行額情報で示されるバリューを非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域に書込むための処理である。

具体的には、この書込処理においては、携帯電話１００は、電子マネーアプリ１１１によって、書込みデータであるバリュー発行額情報で示される額のバリューを、リモート発行サーバ４００に送信する。リモート発行サーバ４００は、電子マネーアプリ１１１を介さずに、非接触型ＩＣチップ１９０と直接やり取りして、非接触型ＩＣチップ１９０の記憶部１９２に、携帯電話１００から受信したバリューを書込む。つまり、リモート発行サーバ４００は、前記書込処理開始要求に対応するバリューの書込状況記憶部における書込状況が未書込を示すもの（購入番号等が記憶されていないか、フラグが書込済でない）であることを条件として、非接触型ＩＣチップ１９０の制御部１９１に対して前記バリュー発行情報に示されたバリュー（発行バリュー）の書込みを指示し（書込指示情報を送信し）、これに応じて、制御部１９１が非接触型ＩＣチップ１９０の記憶部１９２にバリューの書込みを行なう（つまり、制御部１９１がデータ書込実行手段を構成する）。この場合、記憶部１９２の電子マネー遊技使用サービス用の記憶領域に既にバリューが記憶されているときには、既に記憶されているバリューに発行バリューを加算した額のバリューを書込む処理が行なわれるが、かかる処理も発行バリューの書込みに該当する。そして、バリューの書込みが終了した場合、リモート発行サーバ４００は、書込終了情報を携帯電話１００に送信する。

以上のように、本実施の形態においては、電子マネーアプリ１１１を介することなく、リモート発行サーバ４００の指示に応じて非接触型ＩＣチップ１９０の制御部１９１が発行バリューの書込みを行なうように構成したが、これに限定されず、リモート発行サーバ４００から書込指示情報を受信したことに応じて、電子マネーアプリ１１１が制御部１９１に発行バリューの書込みを指示するようにしてもよい。

また、リモート発行サーバ４００は、電子マネー遊技使用サービス用の記憶領域にバリューを書込んだことを条件として、ステップＳ１５４で携帯電話１００から送信された書込処理開始要求に含まれるバリューの購入番号と対応付けて、当該バリューの処理状況を、書込終了済として記憶する。

つまり、リモート発行サーバ４００は、携帯電話１００（非接触型ＩＣチップ１９０の制御部１９１）に対して書込指示情報を送信したことを条件として、該書込指示情報で書込みが指示されたバリューの購入番号等に対応付けて書込状況記憶部に記憶されているフラグを書込済を示す状態に更新する。

なお、データ処理部１１０は、非接触型ＩＣチップ１９０の制御部１９１に対して書込要求信号を送信し、制御部１９１が記憶部１９２の電子マネー遊技使用サービス用の記憶領域にバリューを書込むものであってもよい。この場合、データ処理部１１０から制御部１９１に書込要求信号を送信する処理が、バリューを加算するための処理に該当する。

また、リモート発行サーバ４００と非接触型ＩＣチップ１９０の制御部１９１とがアンテナ１９４を介して通信し、制御部１９１が記憶部１９２の電子マネー遊技使用サービス用の領域にバリューを書込むものであってもよい。この場合、ステップＳ１５４においてデータ処理部１１０からリモート発行サーバ４００に書込処理開始要求情報を送信する処理が、バリューを加算するための処理に該当する。

次いで、データ処理部１１０は、ステップＳ１５７で、リモート発行サーバ４００から書込終了情報を受信したことによって、書込処理が終了したか否かを判断する。書込処理が終了したと判断した場合（ステップＳ１５７でＹＥＳの場合）、ステップＳ１５７ａで、データ処理部１１０は、記憶部１２０で管理している処理状況を、書込済に更新する。

なお、このようにリモート発行サーバ４００から書込終了情報を受信して処理状況を更新するものに限らず、たとえば、データ処理部１１０は、制御部１９１から書込終了信号を受信して、これに基づいて処理状況を更新してもよい。つまり、電子マネー（データ）を非接触型ＩＣチップ１９０の記憶部１９２に書込むための処理が実行されたことを条件として、処理状況をデータ書込済に更新すればよい。

次に、データ処理部１１０は、ステップＳ１５８で、非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域からバリュー残高を取得して、バリュー発行完了画面を表示部１４０に表示させる。

図３４に進んで、図３４（ｄ）の画面は、ステップＳ１５８で表示されるバリュー発行完了画面である。図３４（ｄ）の画面には、図２９（ｂ）の画面と同様のチップＩＤ、バリューのチャージが完了した旨の文章、今回のチャージ金額が１０００円であること、チャージ後のバリュー残高が１１０００円であること、および、バリュー使用時の注意事項が表示される。

図１８に戻って、ステップＳ１５９ａで、データ処理部１１０は、バリュー発行完了画面で確認操作がされたか否かを判断する。確認操作がされたと判断した場合（ステップＳ１５９ａでＹＥＳの場合）、ステップＳ１５９ｂで、データ処理部１１０は、図３０（ｂ）で説明した起動時初期画面を表示部１４０に表示させる。その後、データ処理部１１０は、実行する処理をこの処理の呼出元の処理に戻す。

図１４に戻って、ステップＳ１９８２で、データ処理部１１０は、記憶部１２０で管理されている処理状況が、図１８のステップＳ１５３ａで更新される発行情報受信済であるか否かを判断する。

処理状況が発行情報受信済であると判断した場合（ステップＳ１９８２においてＹＥＳの場合）、データ処理部１１０は、実行する処理を図１８のバリュー発行時処理のステップＳ１５４に進める。これによって、データ処理部１１０は、ステップＳ１５３でバリュー発行情報を受信したが、ステップＳ１５４からステップＳ１５７までのリモート発行サーバ４００とのやり取りにおいて、通信障害等によりバリューの書込みができなかった場合、再度、ステップＳ１５２でバリュー発行要求情報を電子マネー管理サーバ２００に送信することなく、ステップＳ１５４で書込処理開始要求をリモート発行サーバ４００に送信する。

具体的には、ステップＳ１５３ａで記憶部１２０にて管理している処理状況を発行情報受信済に更新した後、バリューの書込みが完了する前にリモート発行サーバ４００との通信が切断され、ユーザが図３０（ａ）に示す画面から電子マネーアプリ１１１の起動操作を実施した場合に、図１１に示す電子マネーアプリ１１１の処理において、ステップＳ１２０、ステップＳ１８０、ステップＳ１１００、ステップＳ１１１０およびステップＳ１９１がすべてＮＯと判断され、ステップＳ１９８の処理状況確認処理が実行される。

そして、図１４に示す処理状況確認処理のステップＳ１９８２において記憶部１２０で管理している処理状況が発行情報受信済であると判断され、図１８のステップＳ１５２（バリュー発行要求情報の送信）を経由することなくステップＳ１５４に進み、リモート発行サーバ４００に対して書込処理開始要求（書込要求情報）が送信される。すなわち、この場合には、ユーザから電子マネーアプリ１１１の起動操作を受付けることが、電子マネーの発行を要求するための発行操作を受付けることに該当する。

また、上記のようにリモート発行サーバ４００との通信が切断された後、前記発行操作として、前記電子メールに添付された引継ぎ情報としてのリンクの操作をユーザから受付けた場合には、図１１に示す電子マネーアプリ１１１の処理において、ステップＳ１９１でＹＥＳと判断されてステップＳ１５０のバリュー発行時処理が実行される。

そして、図１８に示すバリュー発行時処理のステップＳ１５１において、記憶部１２０で管理している処理状況が発行情報受信済であると判断され、ステップＳ１５２（バリュー発行要求情報の送信）を経由することなくステップＳ１５４に進み、リモート発行サーバ４００に対して書込処理開始要求（書込要求情報）が送信される。

これにより、電子マネー管理サーバ２００では、ステップＳ２７９において発行情報ＤＢ２２２の処理状況（発行状況）が発行済に更新されているにもかかわらず、再度バリュー発行要求情報が送信され、電子マネー管理サーバ２００における処理状況が発行済であるため、発行要求が受付けられずに、その後の書込処理に移行できず、バリューの書込みを受けられないという不都合を回避できる。

一方、処理状況が発行情報受信済でないと判断した場合（ステップＳ１９８２においてＮＯの場合）、データ処理部１１０は、実行する処理をステップＳ１９８３に進める。ステップＳ１９８３以降の処理については、後述する。

（電子マネーシステム１０でのバリュー預けの説明）
図３５は、本実施の形態における電子マネーシステム１０において携帯電話１００から電子マネー管理サーバ２００にバリューを預けるときに携帯電話の表示部に表示される第１の表示画面図である。図３５（ａ）の画面は、図１１のステップＳ１９２で表示される起動時初期画面である。図３５（ａ）の画面は、前述した図３０（ａ）の画面と同様であるので、重複する説明は繰返さない。ただし、図３５（ａ）の画面では、「バリュー預け」のリンクが選択候補として網掛け表示されている。

図１１に戻って、ステップＳ１９５で、データ処理部１１０は、バリュー預けが選択されたか否かを判断する。図３５（ａ）の画面で「バリュー預け」のリンクが選択されると、データ処理部１１０は、バリュー預けが選択されたと判断し（ステップＳ１９５でＹＥＳ）、ステップＳ１６０で、バリュー預け処理を実行する。

図２０は、本実施の形態における携帯電話１００により実行される電子マネーアプリ１１１のサブルーチンであるバリュー預け処理の流れを示すフローチャートである。図２０を参照して、まず、ステップＳ１６０１で、データ処理部１１０は、非接触型ＩＣチップ１９０の記憶部１９２からバリュー残高を取得する。

次に、ステップＳ１６０２で、データ処理部１１０は、ステップＳ１６０１で取得したバリュー残高を示すバリュー残高情報と会員ＩＤと携帯端末情報とを含む残高移行依頼情報を電子マネー管理サーバ２００に送信する。

図２１は、本実施の形態における電子マネー管理サーバ２００により実行されるバリュー預かりアプリケーションプログラム２１５の処理の流れを示すフローチャートである。図２１を参照して、まず、ステップＳ２０６１で、データ処理部２１０は、携帯電話１００から残高移行依頼情報を受信したか否かを判断する。残高移行依頼情報を受信していないと判断した場合（ステップＳ２０６１でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２１６１に進める。

一方、残高移行依頼情報を受信したと判断した場合（ステップＳ２０６１でＹＥＳの場合）、データ処理部２１０は、ステップＳ２０６２で、残高移行依頼情報に含まれる会員ＩＤおよび携帯端末情報が利用者情報ＤＢ２２１に登録されたものであり、携帯電話１００が電子マネー遊技使用サービスで利用可能なものであるか否かを判断する。利用可能なものでないと判断した場合（ステップＳ２０６２でＮＯの場合）、ステップＳ２０６３で、データ処理部２１０は、使用不可画面を携帯電話１００に送信し、実行する処理をステップＳ２１６１に進める。

図３５に進んで、図３５（ｂ）は、ステップＳ２０６３で送信される使用不可画面である。図３５（ｂ）の画面は、図３０（ｃ）の画面と同様であるので、重複する説明は繰返さない。

図２１に戻って、一方、利用可能なものであると判断した場合（ステップＳ２０６２でＹＥＳの場合）、ステップＳ２０６４ａで、データ処理部２１０は、図４に示す利用者情報ＤＢ２２１の処理状況が削除応答済であるか否かを判断する。処理状況は、後述するように、ステップＳ２０６６で送信する残高移行応答情報に対する受信応答情報が携帯電話１００から受信されることを条件として、ステップＳ２０６８で削除応答済に更新される。

処理状況が削除応答済であると判断した場合（ステップＳ２０６４ａにおいてＹＥＳの場合）、データ処理部２１０は、実行する処理をステップＳ２０６１の処理に戻し、残高移行依頼（削除要求）を受付けない。一方、処理状況が削除応答済でないと判断した場合（ステップＳ２０６４ａにおいてＮＯの場合）、ステップＳ２０６４で、データ処理部２１０は、購入済みであるが携帯電話１００にチャージされていない未チャージバリューがあるか否かを判断する。ステップＳ２０６４の処理は、図１６のステップＳ２４４の処理と同様であるので、重複する説明は繰返さない。

未チャージバリューがあると判断した場合（ステップＳ２０６４でＹＥＳの場合）、データ処理部２１０は、ステップＳ２０６５で、チャージ誘導画面を携帯電話１００に送信し、実行する処理を前述した図１９のステップＳ２７７に進めることで、当該未チャージバリューに対応するバリュー発行情報がステップＳ２７７において送信される。

図３５に進んで、図３５（ｃ）は、ステップＳ２０６５で送信されるチャージ誘導画面である。図３５（ｃ）の画面は、図３０（ｄ）の画面と同様であるので、重複する説明は繰返さない。この画面が表示された後、前述した図１９のバリュー発行時ＡＰ２１３のステップＳ２７７からの処理が実行され、チャージされていないバリューが携帯電話１００にチャージされる。

一方、未チャージバリューがないと判断した場合（ステップＳ２０６４でＮＯの場合）、ステップＳ２０６６で、データ処理部２１０は、残高移行応答情報をステップＳ２０６１で受信した残高移行依頼情報に含まれる携帯端末情報で示される携帯電話１００に送信する。残高移行応答情報には、ステップＳ２０６１で受信した残高移行依頼情報に含まれる会員ＩＤと携帯端末情報とに対応して利用者情報ＤＢ２２１に記憶されている電子メールアドレス、および、処理開始情報が含まれる。処理開始情報は、携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２に確保されている電子マネー遊技使用サービス用の記憶領域を削除する領域削除処理を実行するためにリモート発行サーバ４００に送信する情報である。なお、残高移行応答情報は、ステップＳ２０６４ａでＮＯの場合、すなわち、処理状況（削除状況）が未実行であることを条件として送信される。

図２０に戻って、ステップＳ１６０３で、データ処理部１１０は、電子マネー管理サーバ２００から残高移行応答情報を受信したか否かを判断する。残高移行応答情報を受信したと判断した場合（ステップＳ１６０３でＹＥＳの場合）、ステップＳ１６０４で、データ処理部１１０は、アドレス確認画面を表示部１４０に表示させる。

図３６は、本実施の形態における電子マネーシステム１０において携帯電話１００から電子マネー管理サーバ２００にバリューを預けるときに携帯電話１００の表示部１４０に表示される第２の表示画面図である。図３６（ａ）は、ステップＳ１６０４で携帯電話１００に表示されるアドレス確認画面である。図３６（ａ）の画面には、バリューの預かりに関する説明の文章、ステップＳ１６０３で受信した残高移行応答情報に含まれる電子メールアドレス、表示されている電子メールアドレスが利用している携帯電話１００の電子メールアドレスと異なる場合に電子メールアドレスを変更するためのリンクである「→上記アドレスがご利用携帯のアドレスと異なる場合はこちら。」、および、表示されている電子メールアドレスが正しいことを入力するためのリンクである「確認」が表示される。

図２０に戻って、ステップＳ１６０５で、データ処理部１１０は、「確認」のリンクが選択されることによって、確認の入力があったか否かを判断する。確認の入力があったと判断した場合（ステップＳ１６０５でＹＥＳの場合）、ステップＳ１６０６で、データ処理部１１０は、パスワード入力画面を表示部１４０に表示させる。

図３６に進んで、図３６（ｂ）は、ステップＳ１６０６で携帯電話１００に表示されるパスワード入力画面である。図３６（ｂ）の画面には、預けたバリューの返却を受けるときに必要となるパスワードの入力を促がす旨の文章、ユーザが決めたパスワードを入力するためのパスワード入力欄、入力されたパスワードの確認の再入力をするためのパスワード確認用再入力欄、入力したパスワードを確認して決定するためのリンクである「確認」が表示される。

図２０に戻って、ステップＳ１６０７で、データ処理部１１０は、「確認」のリンクが選択されることによって、確認の入力があったか否かを判断する。確認の入力があったと判断した場合（ステップＳ１６０７でＹＥＳの場合）、ステップＳ１６０７ａで、データ処理部１１０は、記憶部１２０で管理している処理状況を、残高移行応答受信済に更新する。そして、ステップＳ１６０７ｂで、データ処理部１１０は、残高移行応答情報を受信したことを電子マネー管理サーバ２００に知らせるための受信応答情報を、電子マネー管理サーバ２００に送信する。

図２１に進んで、ステップＳ２０６７で、データ処理部２１０は、携帯電話１００から受信応答情報を受信したか否かを判断する。受信応答情報を受信していないと判断した場合（ステップＳ２０６７においてＮＯの場合）、データ処理部２１０は、ステップＳ２０６７の処理を繰返す。一方、受信応答情報を受信したと判断した場合（ステップＳ２０６７においてＹＥＳの場合）、ステップＳ２０６８で、データ処理部２１０は、図４に示す利用者情報ＤＢ２２１の処理状況を削除応答済に更新する。

図２０に戻って、次に、ステップＳ１６１１で、データ処理部１１０は、領域削除処理開始要求をリモート発行サーバ４００へ送信する。領域削除処理開始要求には、ステップＳ１６０３で受信した残高移行応答情報に含まれる処理開始情報に基づいて作成した領域削除処理を実行するための処理ＩＤなどのパラメータ、および、携帯端末情報が含まれる。

図１に戻って、リモート発行サーバ４００は、領域削除開始要求に含まれる携帯端末情報で示される携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域を削除するための領域削除実行情報を、携帯端末情報で示される携帯電話１００に送信する。

図２０に進んで、データ処理部１１０は、ステップＳ１６１２で、リモート発行サーバ４００から領域削除実行情報を受信したか否かを判断する。領域削除実行情報を受信したと判断した場合（ステップＳ１６１２でＹＥＳの場合）、ステップＳ１６１３で、データ処理部１１０は、リモート発行サーバ４００から受信した領域削除実行情報で示される領域削除処理を実行する。領域削除処理は、領域削除実行情報で示される非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域を削除する処理である。

具体的には、この領域削除処理においては、リモート発行サーバ４００は、電子マネーアプリ１１１を介して、非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域を削除する。そして、記憶領域の削除が終了した場合、リモート発行サーバ４００は、領域削除終了情報を携帯電話１００に送信する。

なお、ここでは、リモート発行サーバ４００は、電子マネーアプリ１１１を介して、記憶領域を削除するようにした。しかし、これに限定されず、リモート発行サーバ４００は、電子マネーアプリ１１１を介さずに、非接触型ＩＣチップ１９０と直接やり取りして、記憶領域を削除するようにしてもよい。

また、リモート発行サーバ４００は、非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域を削除したことを条件として、ステップＳ１６１１で携帯電話１００から送信された領域削除処理開始要求に含まれる携帯端末情報と対応付けて、処理状況を削除終了済として記憶する。

なお、データ処理部１１０は、非接触型ＩＣチップ１９０の制御部１９１に対して領域削除要求信号を送信し、制御部１９１が記憶部１９２の電子マネー遊技使用サービス用の記憶領域を削除するようにしてもよい。

次いで、データ処理部１１０は、ステップＳ１６１４で、リモート発行サーバ４００から領域削除終了情報を受信したことによって、領域削除処理が終了したか否かを判断する。領域削除処理が終了したと判断した場合（ステップＳ１６１４でＹＥＳの場合）、ステップＳ１６１４ａで、データ処理部１１０は、記憶部１２０で管理している処理状況を、削除済に更新する。次に、データ処理部１１０は、ステップＳ１６１５で、電子マネー遊技使用サービス用の記憶領域の削除が完了したことを通知するための通知であって、ステップＳ１６０７で入力されたパスワードと携帯端末情報とを含む移行完了通知を電子マネー管理サーバ２００に送信する。

図２１に進んで、ステップＳ２１６１で、データ処理部２１０は、携帯電話１００から移行完了通知を受信したか否かを判断する。移行完了通知を受信していないと判断した場合（ステップＳ２１６１でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２０６１に戻す。

一方、移行完了通知を受信したと判断した場合（ステップＳ２１６１でＹＥＳの場合）、データ処理部２１０は、ステップＳ２１６２で、携帯電話１００からのバリューの預かりに対して割振られた番号であるお預かり番号を発行し、ステップＳ２１６３で、発行したお預かり番号と、ステップＳ２０６１で受信した残高移行依頼情報に含まれるバリュー残高情報で示されるバリュー残高である預かり残高と、ステップＳ２１６１で受信した移行完了通知に含まれるパスワードと、携帯端末情報とを対応させて記憶部２２０に記憶させる。つまり、携帯端末情報と対応して記憶されるお預かり番号、預かり残高、および、パスワードが、当該携帯端末情報と対応付けて利用者情報ＤＢ２２１に記憶されている処理状況と対応付けられて、記憶部２２０に登録されることとなる。

そして、ステップＳ２１６４で、データ処理部２１０は、ステップＳ２１６２で発行したお預かり番号を携帯電話１００に送信する。また、ステップＳ２１６５で、データ処理部２１０は、ステップＳ２１６２で発行したお預かり番号を付した電子メールであるお預かり番号通知メールを携帯電話１００の電子メールアドレス宛に送信する。その後、データ処理部２１０は、実行する処理をステップＳ２０６１に戻す。

図２０に戻って、ステップＳ１６１６で、データ処理部１１０は、電子マネー管理サーバ２００からお預かり番号を受信したか否かを判断する。お預かり番号を受信したと判断した場合（ステップＳ１６１６でＹＥＳの場合）、ステップＳ１６１７で、データ処理部１１０は、残高移行完了画面を表示部１４０に表示させる。

図３６に進んで、図３６（ｃ）の画面は、ステップＳ１６１７で表示される残高移行完了画面である。図３６（ｃ）の画面には、バリューの預けが完了した旨の文章、ステップＳ１６１６で受信したお預かり番号、および、預けたバリューの返却に関する説明の文章が表示される。

図２０に戻って、ステップＳ１６１８で、データ処理部１１０は、残高移行完了画面で確認操作がされたか否かを判断する。確認操作がされたと判断した場合（ステップＳ１６１８でＹＥＳの場合）、ステップＳ１６１９で、データ処理部１１０は、図３０（ｂ）で説明した起動時初期画面を表示部１４０に表示させる。その後、データ処理部１１０は、実行する処理をこの処理の呼出元の処理に戻す。

以上のように、バリュー預け処理においては、バリューの預けだけでなく、非接触型ＩＣチップ１９０の記憶部１９２に構築された電子マネー遊技使用サービス用の記憶領域の削除処理が行なわれ、当該削除処理により記憶部１９２に記憶されたデータとしての電子マネー（バリュー）も削除される。

つまり、図３５（ａ）に示す画面において、「バリュー預け」メニューが選択されたことに基づいて、記憶部１９２に記憶された電子マネーの削除が行なわれることから、同画面において「バリュー預け」メニューの選択操作を受付けることが、データとして電子マネーの削除を要求するための削除操作を受付けることに相当する。また、その選択操作に応じて図２０のバリュー預け処理のステップＳ１６０２において電子マネー管理サーバ２００に残高移行依頼情報を送信することが、データとして電子マネーの削除を要求するための削除要求情報を送信することに相当する。

また、電子マネー管理サーバ２００は、図４に示す利用者情報ＤＢ２２１の処理状況において、携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２の電子マネーを削除するための削除用処理が実行済か否かを管理している。具体的には、電子マネー管理サーバ２００は、削除用処理として、図２１に示すステップＳ２０６６で残高移行応答情報（削除応答情報）を送信し、ステップＳ２０６７で受信応答情報を受信する処理を行ない、これに基づいて該処理状況の項目を削除応答済に更新するため、該処理状況の項目が削除応答済か否かにより削除用処理が実行済か否かが示される。

図１４に戻って、ステップＳ１９８３で、データ処理部１１０は、記憶部１２０で管理されている処理状況が、図２０のステップＳ１６０７ａで更新される残高移行応答受信済であるか否かを判断する。

処理状況が残高移行応答受信済であると判断した場合（ステップＳ１９８３においてＹＥＳの場合）、データ処理部１１０は、実行する処理を図２０のバリュー預け処理のステップＳ１６１１に進める。これによって、データ処理部１１０は、ステップＳ１６０３で残高移行応答情報を受信したが、ステップＳ１６１１からステップＳ１６１４までのリモート発行サーバ４００とのやり取りにおいて、通信障害等により電子マネー遊技使用サービス用の記憶領域を削除できなかった場合、再度、ステップＳ１６０２で残高移行依頼情報を電子マネー管理サーバ２００に送信することなく、ステップＳ１６１１で領域削除処理開始要求をリモート発行サーバ４００に送信する。

つまり、ステップＳ１６０７ａで記憶部１２０にて管理している処理状況を残高移行応答受信済（削除応答情報受信済）に更新した後、電子マネー遊技使用サービス用の記憶領域（バリュー）の削除が完了する前にリモート発行サーバ４００との通信が切断され、ユーザが図３０（ａ）に示す画面から電子マネーアプリ１１１の起動操作を実施した場合に、図１１に示す電子マネーアプリ１１１の処理においてステップＳ１２０、ステップＳ１８０、ステップＳ１１００、ステップＳ１１１０およびステップＳ１９１がすべてＮＯと判断され、ステップＳ１９８の処理状況確認処理が実行される。

そして、図１４に示す処理情報確認処理のステップＳ１９８３において記憶部１２０で管理している処理状況が残高移行応答受信済であると判断され、図２０のステップＳ１６０２（削除要求情報としての残高移行依頼情報の送信）を経由することなくステップＳ１６１１に進み、リモート発行サーバ４００に対して削除処理開始要求（削除開始要求情報）が送信される。

これにより、電子マネー管理サーバ２００ではステップＳ２０６８において図４に示す利用者情報ＤＢ２２１の処理状況（削除状況）が削除応答済（削除済）に更新されているにもかかわらず、再度残高移行依頼情報（削除要求情報）が送信され、電子マネー管理サーバ２００における処理状況が削除済であるため、削除要求が受付けられずに、その後の削除処理に移行できず、バリュー（電子マネー遊技使用サービス用の記憶領域）の削除を行なえない（換言すればバリュー預けを行なえない）という不都合を回避できる。

一方、処理状況が残高移行応答受信済でないと判断した場合（ステップＳ１９８３においてＮＯの場合）、データ処理部１１０は、実行する処理をステップＳ１９８４に進める。ステップＳ１９８４以降の処理については、後述する。

（電子マネーシステム１０でのバリューの返却の説明）
図３７は、本実施の形態における電子マネーシステム１０において電子マネー管理サーバ２００に預けたバリューの返却を受けるときに携帯電話１００の表示部１４０に表示される第１の表示画面図である。図３７（ａ）の画面は、図１１のステップＳ１９２で表示される起動時初期画面である。図３７（ａ）の画面は、前述した図３０（ａ）の画面と同様であるので、重複する説明は繰返さない。ただし、図３７（ａ）の画面では、「預けバリュー返却」のリンクが選択候補として網掛け表示されている。

図１１に戻って、ステップＳ１９６で、データ処理部１１０は、バリュー返却が選択されたか否かを判断する。図３７（ａ）の画面で「預けバリュー返却」のリンクが選択されると、データ処理部１１０は、バリュー返却が選択されたと判断し（ステップＳ１９６でＹＥＳ）、ステップＳ１７０で、バリュー返却処理を実行する。

図２２は、本実施の形態における携帯電話１００により実行される電子マネーアプリ１１１のサブルーチンであるバリュー返却処理の流れを示すフローチャートである。図２２を参照して、まず、ステップＳ１７０１で、データ処理部１１０は、非接触型ＩＣチップ１９０の記憶部１９２からバリュー残高を取得する。

次に、ステップＳ１７０２で、データ処理部１１０は、ステップＳ１７０１で取得したバリュー残高を示すバリュー残高情報と会員ＩＤと携帯端末情報とを含む残高返却依頼情報を電子マネー管理サーバ２００に送信する。

図２３は、本実施の形態における電子マネー管理サーバ２００により実行されるバリュー返却アプリケーションプログラム２１６の処理の流れを示すフローチャートである。図２３を参照して、まず、ステップＳ２０７１で、データ処理部２１０は、携帯電話１００から残高返却依頼情報を受信したか否かを判断する。残高返却依頼情報を受信していないと判断した場合（ステップＳ２０７１でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２１７１に進める。

一方、残高返却依頼情報を受信したと判断した場合（ステップＳ２０７１でＹＥＳの場合）、データ処理部２１０は、ステップＳ２０７２で、残高返却依頼情報に含まれる会員ＩＤおよび携帯端末情報が利用者情報ＤＢ２２１に登録されたものであり、携帯電話１００が電子マネー遊技使用サービスで利用可能なものであるか否かを判断する。利用可能なものでないと判断した場合（ステップＳ２０７２でＮＯの場合）、ステップＳ２０６３で、データ処理部２１０は、使用不可画面を携帯電話１００に送信し、実行する処理をステップＳ２１７１に進める。

図３７に進んで、図３７（ｂ）は、ステップＳ２０７３で送信される使用不可画面である。図３７（ｂ）の画面は、図３０（ｃ）の画面と同様であるので、重複する説明は繰返さない。

図２３に戻って、一方、利用可能なものであると判断した場合（ステップＳ２０７２でＹＥＳの場合）、ステップＳ２０７４ａで、データ処理部２１０は、図４に示す利用者情報ＤＢ２２１の処理状況（返却状況）が返却済であるか否かを判断する。処理状況は、後述するように、ステップＳ２２７２で送信されるバリュー返却情報に対する受信応答情報が携帯電話１００から受信されることを条件として、ステップＳ２２７４で返却済に更新される。

処理状況が返却済であると判断した場合（ステップＳ２０７４ａにおいてＹＥＳの場合）、データ処理部２１０は、実行する処理をステップＳ２０７１の処理に戻す。一方、処理状況が返却済でないと判断した場合（ステップＳ２０７４ａにおいてＮＯの場合）、ステップＳ２０７４で、データ処理部２１０は、購入済みであるが携帯電話１００にチャージされていない未チャージバリューがあるか否かを判断する。ステップＳ２０７４の処理は、図１６のステップＳ２４４の処理と同様であるので、重複する説明は繰返さない。

未チャージバリューがあると判断した場合（ステップＳ２０７４でＹＥＳの場合）、データ処理部２１０は、ステップＳ２０７５で、チャージ誘導画面を携帯電話１００に送信し、実行する処理を前述した図１９のステップＳ２７７に進める。

図３７に進んで、図３７（ｃ）は、ステップＳ２０７５で送信されるチャージ誘導画面である。図３７（ｃ）の画面は、図３０（ｄ）の画面と同様であるので、重複する説明は繰返さない。この画面が表示された後、前述した図１９のバリュー発行時ＡＰ２１３のステップＳ２７７からの処理が実行され、チャージされていないバリューが携帯電話１００にチャージされる。

図２３に戻って、一方、未チャージバリューがないと判断した場合（ステップＳ２０７４でＮＯの場合）、ステップＳ２０７６で、データ処理部２１０は、番号入力指示情報をステップＳ２０７１で受信した残高返却依頼情報に含まれる携帯端末情報で示される携帯電話１００に送信する。番号入力指示情報は、携帯電話１００で後述する番号入力画面を表示させる契機となる情報である。

図２２に戻って、ステップＳ１７０３で、データ処理部１１０は、電子マネー管理サーバ２００から番号入力指示情報を受信したか否かを判断する。番号入力指示情報を受信したと判断した場合（ステップＳ１７０３でＹＥＳの場合）、ステップＳ１７０４で、データ処理部１１０は、番号入力画面を表示部１４０に表示させる。

図３８は、本実施の形態における電子マネーシステム１０において電子マネー管理サーバ２００に預けたバリューの返却を受けるときに携帯電話１００の表示部１４０に表示される第２の表示画面図である。図３８（ａ）は、ステップＳ１７０４で携帯電話１００に表示される番号入力画面である。図３８（ａ）の画面には、バリューを預けたときに発行されたお預かり番号とユーザによって定められたパスワードとの入力を求める旨の文章、お預かり番号を入力するためのお預かり番号入力欄、パスワードを入力するためのパスワード入力欄、および、入力したお預かり番号とパスワードとを確認して電子マネー管理サーバ２００に送信するためのリンクである「確認」が表示される。

図２２に戻って、ステップＳ１７０５で、データ処理部１１０は、「確認」のリンクが選択されることによって、確認の入力があったか否かを判断する。確認の入力があったと判断した場合（ステップＳ１７０５でＹＥＳの場合）、ステップＳ１７０６で、データ処理部１１０は、入力されたお預かり番号およびパスワード、ならびに、携帯端末情報を含む預かり番号情報（預かり残額返却要求情報）を電子マネー管理サーバ２００に送信する。

図２３に進んで、ステップＳ２１７１で、データ処理部２１０は、携帯電話１００からお預かり番号、パスワードおよび携帯端末情報を含む預かり番号情報を受信したか否かを判断する。受信していないと判断した場合（ステップＳ２１７１でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２２７１に進める。一方、受信したと判断した場合（ステップＳ２１７１でＹＥＳの場合）、ステップＳ２１７２で、データ処理部２１０は、ステップＳ２１７１で受信した預かり番号情報に含まれるお預かり番号およびパスワードが記憶部２２０に存在するか否かを判断する。

お預かり番号およびパスワードが存在しないと判断した場合（ステップＳ２１７２でＮＯの場合）、ステップＳ２１７３で、データ処理部２１０は、ステップＳ２１７１で受信した携帯端末情報で示される携帯電話１００に番号エラー画面を送信し、実行する処理をステップＳ２２７１に進める。

図３８に進んで、図３８（ｂ）は、ステップＳ２１７３で携帯電話１００に送信される番号エラー画面である。図３８（ｂ）の画面には、受信したお預かり番号またはパスワードが記憶部２２０に存在しない旨の文章、および、再度、番号入力画面を表示させるためのリンクである「ＯＫ」が表示される。

図２３に戻って、お預かり番号およびパスワードが存在すると判断した場合（ステップＳ２１７２でＹＥＳの場合）、ステップＳ２１７４で、データ処理部２１０は、ステップＳ２１７１で受信したお預かり番号およびパスワードに対応して記憶部２２０に記憶された携帯端末情報と、ステップＳ２１７１で受信した携帯端末情報とが一致するか否かを判断する。

携帯端末情報が一致すると判断した場合（ステップＳ２１７４でＹＥＳの場合）、本来機種変更されているので携帯端末情報が異なるはずであるのに携帯端末情報が一致していることとなり何らかの不正の疑いがあるので、バリューの返却処理を行なうことなく、ステップＳ２１７５で、データ処理部１１０は、携帯端末一致エラー画面を携帯電話１００に送信し、実行する処理をステップＳ２２７１に進める。携帯端末一致エラー画面には、図３８（ｂ）で説明した番号エラー画面のお預かり番号またはパスワードが記憶部２２０に存在しない旨の文書に替えて、バリューを預ける前の携帯端末情報とバリューの返却を受けようとしている携帯端末情報とが一致する旨の文章が表示される。

一方、携帯端末情報が一致しないと判断した場合（ステップＳ２１７４でＮＯの場合）、ステップＳ２１７６で、データ処理部２１０は、ステップＳ２１７１で受信したお預かり番号とパスワードとに対応して記憶部２２０に記憶された預かり残高を読出す。

そして、ステップＳ２１７７で、データ処理部２１０は、ステップＳ２０７１で受信した残高返却依頼情報に含まれるバリュー残高情報で示されるバリュー残高と、ステップＳ２１７６で読出した預かり残高とを加算した金額が、携帯端末情報と対応して利用者情報ＤＢ２２１に記憶された携帯上保持限度額以下であるか否かを判断する。つまり、預かり残高とバリュー残高との合計額、および携帯上保持限度額に基づいて預かり残高の返却を許容するか否かを判定する。

携帯上保持限度額以下でないと判断した場合（ステップＳ２１７６でＮＯの場合）、ステップＳ２１７８で、データ処理部２１０は、バリューの返却処理を行なうことなく、携帯上保持限度額返却不可画面を携帯電話１００に送信し、実行する処理をステップＳ２２７１に進める。携帯上保持限度額返却不可画面には、図３８（ｂ）で説明した番号エラー画面のお預かり番号またはパスワードが記憶部２２０に存在しない旨の文章に替えて、バリュー残高と預かり残高とを加算した額が携帯上保持限度額を超えるので預かり残高を返却することができない旨の文章が表示される。

一方、携帯上保持限度額以下であると判断した場合（ステップＳ２１７６でＹＥＳの場合）、ステップＳ２１７９で、データ処理部２１０は、ステップＳ２１７６で読出した預かり残高を示す預かり残高情報を、ステップＳ２１７１で受信した携帯端末情報で示される携帯電話１００に送信する。

図２２に戻って、ステップＳ１７１１で、データ処理部１１０は、電子マネー管理サーバ２００から預かり残高情報を受信したか否かを判断する。預かり残高情報を受信していないと判断した場合（ステップＳ１７１１でＮＯの場合）、ステップＳ１７１１ａで、データ処理部１１０は、電子マネー管理サーバ２００から携帯上保持限度額返却不可画面を受信したか否かを判断する。携帯上保持限度額返却不可画面を受信していないと判断した場合（ステップＳ１７１１ａでＮＯの場合）、データ処理部１１０は、実行する処理をステップＳ１７１１の処理に戻す。

一方、携帯上保持限度額返却不可画面を受信したと判断した場合（ステップＳ１７１１ａでＹＥＳの場合）、ステップＳ１７１１ｂで、データ処理部１１０は、携帯上保持限度額返却不可画面を表示部１４０に表示させる。その後、データ処理部１１０は、実行する処理をステップＳ１７２６に進める。

一方、預かり残高情報を受信したと判断した場合（ステップＳ１７１１でＹＥＳの場合）、ステップＳ１７１２で、データ処理部１１０は、ステップＳ１７１１で受信した預かり残高情報で示される預かり残高を含む預かり残高返却確認画面を表示部１４０に表示させる。

図３８に進んで、図３８（ｃ）は、ステップＳ１７１１で携帯電話１００に表示される預かり残高返却確認画面である。図３８の画面には、ステップＳ１７１１で受信した預かり残高情報で示される預かり残高、ステップＳ１７０１で取得されたバリュー残高、バリューの返却を実行するか否かを確認する旨の文章、および、バリューの返却を実行するためのリンクである「実行」が表示される。

図２２に戻って、ステップＳ１７１３で、データ処理部１１０は、「実行」のリンクが選択されることによって、実行の入力があったか否かを判断する。実行の入力があったと判断した場合（ステップＳ１７１３でＹＥＳの場合）、ステップＳ１７１４で、データ処理部１１０は、返却実行情報を電子マネー管理サーバ２００に送信する。返却実行情報は、返却されるバリューを非接触型ＩＣチップ１９０の記憶部１９２に記憶させる処理を開始させる契機となるバリュー返却情報の送信を要求するための情報であり、携帯端末情報を含む。

図２３に進んで、ステップＳ２２７１で、データ処理部２１０は、携帯電話１００から返却実行情報を受信したか否かを判断する。返却実行情報を受信したと判断した場合（ステップＳ２２７１でＹＥＳの場合）、ステップＳ２２７２で、データ処理部２１０は、返却実行情報に含まれる携帯端末情報で示される携帯電話１００に、バリュー返却情報を送信する。

図２２に戻って、ステップＳ１７１５で、データ処理部１１０は、電子マネー管理サーバ２００からバリュー返却情報を受信したか否かを判断する。バリュー返却情報を受信したと判断した場合（ステップＳ１７１５でＹＥＳの場合）、ステップＳ１７１６で、データ処理部１１０は、記憶部１２０で管理している処理状況を、返却情報受信済に更新する。そして、ステップＳ１７１７で、データ処理部１１０は、バリュー返却情報を受信したことを電子マネー管理サーバ２００に知らせるための受信応答情報を、電子マネー管理サーバ２００に送信する。

図２３に進んで、ステップＳ２２７３で、データ処理部２１０は、携帯電話１００から受信応答情報を受信したか否かを判断する。受信応答情報を受信していないと判断した場合（ステップＳ２２７３においてＮＯの場合）、データ処理部２１０は、ステップＳ２２７３の処理を繰返す。一方、受信応答情報を受信したと判断した場合（ステップＳ２２７３においてＹＥＳの場合）、ステップＳ２２７４で、データ処理部２１０は、図４の利用者情報ＤＢの処理状況を返却済に更新する。

図２２に戻って、次に、ステップＳ１７２１で、データ処理部１１０は、非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域にステップＳ１７１１で受信した預かり残高情報で示される預かり残高のバリューを記憶させる返却バリュー書込み処理を開始させるための情報であって、預かり残高情報および携帯端末情報を含むバリュー返却処理開始要求情報をリモート発行サーバ４００に送信する。

図１に戻って、リモート発行サーバ４００は、バリュー返却実行情報を、バリュー返却処理開始要求情報に含まれる携帯端末情報で示される携帯電話１００に送信する。バリュー返却実行情報は、携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域に、バリュー返却処理開始要求情報に含まれる預かり残高情報で示される額のバリューを記憶させるための情報である。

図２２に進んで、データ処理部１１０は、ステップＳ１７２２で、リモート発行サーバ４００からバリュー返却実行情報を受信したか否かを判断する。バリュー返却実行情報を受信したと判断した場合（ステップＳ１７２２でＹＥＳの場合）、ステップＳ１７２３で、データ処理部１１０は、リモート発行サーバ４００から受信したバリュー返却実行情報で示される返却バリュー書込処理を実行する。返却バリュー書込処理は、バリュー返却実行情報で示されるバリューを非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域に書込むための処理である。

具体的には、この返却バリュー書込処理においては、携帯電話１００は、電子マネーアプリ１１１によって、書込みデータである預かり残高情報で示される額のバリューを、リモート発行サーバ４００に送信する。リモート発行サーバ４００は、電子マネーアプリを介さず、非接触型ＩＣチップ１９０と直接やり取りして、非接触型ＩＣチップ１９０の記憶部１９２に、携帯電話１００から受信したバリューを書込む。つまり、リモート発行サーバ４００は、非接触型ＩＣチップ１９０の制御部１９１に対して前記預かり残高情報で示される額のバリュー（返却バリュー）の書込みを指示し（返却指示情報を送信し）、これに応じて、制御部１９１が非接触型ＩＣチップ１９０の記憶部１９２にバリューの書込みを行なう（つまり、制御部１９１がデータ返却実行手段を構成する）。この場合、記憶部１９２の電子マネー遊技使用サービス用の記憶領域に既にバリューが記憶されているときには、既に記憶されているバリューに返却バリューを加算した額のバリューを書込む処理が行なわれるが、かかる処理も返却バリューの書込みに該当する。そして、バリューの書込みが終了した場合、リモート発行サーバ４００は、返却バリュー書込終了情報を携帯電話１００に送信する。

以上のように、本実施の形態においては、電子マネーアプリ１１１を介することなく、リモート発行サーバ４００の指示に応じて非接触型ＩＣチップ１９０の制御部１９１が返却バリューの書込みを行なうように構成したが、これに限定されず、リモート発行サーバ４００から返却指示情報を受信したことに応じて、電子マネーアプリ１１１が制御部１９１に返却バリューの書込みを指示するようにしてもよい。

また、リモート発行サーバ４００は、電子マネー遊技使用サービス用の記憶領域にバリューを書込んだことを条件として、ステップＳ１７２１で携帯電話１００から送信されたバリュー返却処理開始要求に含まれる携帯端末情報と対応付けて、当該バリューの処理状況を、返却終了済として記憶する。

なお、データ処理部１１０は、非接触型ＩＣチップ１９０の制御部１９１に対して返却バリュー書込要求信号を送信し、制御部１９１が記憶部１９２の電子マネー遊技使用サービス用の記憶領域にバリューを書込むものであってもよい。この場合、データ処理部１１０から制御部１９１に返却バリュー書込要求信号を送信する処理が、バリューを加算するための処理に該当する。

次いで、データ処理部１１０は、ステップＳ１７２４で、リモート発行サーバ４００から返却バリュー書込終了情報を受信したことによって、返却バリュー書込処理が終了したか否かを判断する。返却バリュー書込処理が終了したと判断した場合（ステップＳ１７２４でＹＥＳの場合）、ステップＳ１７２４ａで、データ処理部１１０は、記憶部１２０で管理している処理状況を、返却済に更新する。次に、データ処理部１１０は、ステップＳ１７２５で、非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域からバリュー残高を取得して、返却完了画面を表示部１４０に表示させる。

図３８に進んで、図３８（ｄ）の画面は、ステップＳ１７２５で表示される返却完了画面である。図３８（ｄ）の画面には、図２９（ｂ）の画面と同様のチップＩＤ、バリューの返却が完了した旨の文章、返却金額が１０００円であること、および、返却後のバリューの残高が１０００円であることが表示される。

図２２に戻って、ステップＳ１７２６で、データ処理部１１０は、返却完了画面で確認操作がされたか否かを判断する。確認操作がされたと判断した場合（ステップＳ１７２６でＹＥＳの場合）、ステップＳ１７２７で、データ処理部１１０は、図３０（ｂ）で説明した起動時初期画面を表示部１４０に表示させる。その後、データ処理部１１０は、実行する処理をこの処理の呼出元の処理に戻す。

図１４に戻って、ステップＳ１９８４で、データ処理部１１０は、記憶部１２０で管理されている処理状況が、図２２のステップＳ１７１６で更新される返却情報受信済であるか否かを判断する。

処理状況が返却情報受信済であると判断した場合（ステップＳ１９８４においてＹＥＳの場合）、データ処理部１１０は、実行する処理を図２２のバリュー返却処理のステップＳ１７２１に進める。これによって、データ処理部１１０は、ステップＳ１７１５でバリュー返却情報を受信したが、ステップＳ１７２１からステップＳ１７２４までのリモート発行サーバ４００とのやり取りにおいて、通信障害等によりバリューの返却ができなかった場合、再度、ステップＳ１７０２で残高返却依頼情報を電子マネー管理サーバ２００に送信することなく、ステップＳ１７２１でバリュー返却処理開始要求をリモート発行サーバ４００に送信する。

具体的には、ステップＳ１７１６で記憶部１２０にて管理している処理状況を返却情報受信済に更新した後、バリューの返却が完了する前にリモート発行サーバ４００との通信が切断され、ユーザが図３０（ａ）に示す画面から電子マネーアプリ１１１の起動操作を実施した場合に、図１１に示す電子マネーアプリ１１１の処理において、ステップＳ１２０、ステップＳ１８０、ステップＳ１１００、ステップＳ１１１０およびステップＳ１９１がすべてＮＯと判断され、ステップＳ１９８の処理状況確認処理が実行される。

そして、図１４に示す処理状況確認処理のステップＳ１９８４において記憶部１２０で管理している処理状況が返却情報受信済であると判断され、図２２のステップＳ１７１４（返却実行情報の送信）を経由することなくステップＳ１７２１に進み、リモート発行サーバ４００に対してバリュー返却処理開始要求（返却要求情報）が送信される。すなわち、この場合には、ユーザから電子マネーアプリ１１１の起動操作を受付けることが、電子マネーの返却を要求するための返却操作を受付けることに該当する。

これにより、電子マネー管理サーバ２００では、ステップＳ２２７４において利用者情報ＤＢ２２１の処理状況（返却状況）が返却済に更新されているにもかかわらず、再度残高返却依頼情報が送信され、電子マネー管理サーバ２００における処理状況が返却済であるため、残高返却依頼が受付けられずに、その後の返却バリュー書込処理に移行できず、バリューの返却を受けられないという不都合を回避できる。

一方、処理状況が返却情報受信済でないと判断した場合（ステップＳ１９８４においてＮＯの場合）、データ処理部１１０は、実行する処理をこの処理の呼出元の処理である電子マネーアプリ１１１に戻す。

（電子マネーシステム１０でのバリューの使用の説明）
図３９は、本実施の形態における券売機３００で実行される発券処理の流れを示すフローチャートである。図３９を参照して、まず、ステップＳ３１０で、券売機３００のデータ処理部３１０は、不正登録処理を実行する。

図４０は、本実施の形態における券売機３００で実行される不正登録処理の流れを示すフローチャートである。図４０を参照して、データ処理部３１０は、ステップＳ３１１で、電子マネー管理サーバ２００から店舗サーバ８００を介して、携帯使用禁止情報を受信したか否かを判断する。

携帯使用禁止情報とは、遊技場３０においてすべての携帯電話１００でのバリューの使用を禁止させることを指示するための情報である。携帯使用禁止情報を送信する処理については、後述する図４５および図５０で説明する。

携帯使用禁止情報を受信したと判断した場合（ステップＳ３１１でＹＥＳの場合）、データ処理部３１０は、ステップＳ３１２で、携帯使用禁止情報を記憶部３２０に記憶させる。一方、携帯使用禁止情報を受信していないと判断した場合（ステップＳ３１１でＮＯの場合）、または、ステップＳ３１２の後、データ処理部３１０は、実行する処理をステップＳ３１３に進める。

ステップＳ３１３では、データ処理部３１０は、電子マネー管理サーバ２００から店舗サーバ８００を介して、不正端末情報を受信したか否かを判断する。

不正端末情報は、携帯ＩＤを含み、携帯ＩＤで示される携帯電話１００でのバリューの使用を禁止させることを指示するための情報である。不正端末情報を送信する処理については、後述する図４５および図５０で説明する。

不正端末情報を受信したと判断した場合（ステップＳ３１３でＹＥＳの場合）、データ処理部３１０は、ステップＳ３１４で、不正端末情報を記憶部３２０に記憶させる。一方、不正端末情報を受信していないと判断した場合（ステップＳ３１３でＮＯの場合）、または、ステップＳ３１４の後、データ処理部３１０は、実行する処理をステップＳ３１５に進める。

ステップＳ３１５では、データ処理部３１０は、電子マネー管理サーバ２００から店舗サーバ８００を介して、利用停止情報を受信したか否かを判断する。

利用停止情報は、携帯端末情報を含み、携帯端末情報で示される携帯電話１００でのバリューの利用を停止させることを指示するための情報である。利用停止情報を送信する処理については、後述する図４６および図５０で説明する。

利用停止情報を受信したと判断した場合（ステップＳ３１５でＹＥＳの場合）、データ処理部３１０は、ステップＳ３１６で、利用停止情報に含まれる携帯端末情報を利用停止携帯情報として記憶部３２０に記憶させる。一方、利用停止情報を受信していないと判断した場合（ステップＳ３１５でＮＯの場合）、または、ステップＳ３１６の後、データ処理部３１０は、実行する処理をこの不正登録処理の呼出元の処理である図３９の発券処理に戻す。

図３９に戻って、ステップＳ３２０で、データ処理部３１０は、貨幣処理機３８０から現金が投入された旨の現金投入信号を受信したか否かを判断する。

現金投入信号を受信したと判断した場合（ステップＳ３２０でＹＥＳの場合）、ステップＳ３２３で、データ処理部３１０は、貨幣処理機３８０から現金カウント信号を受信して、現金カウント信号で示される現金の額を現金投入額にセットする。

そして、ステップＳ３２４で、データ処理部３１０は、現金カウント信号を再度受信したか否かを判断することによって、現金が追加投入されたか否かを判断する。現金が追加投入されたと判断した場合（ステップＳ３２４でＹＥＳの場合）、データ処理部３１０は、再度受信された現金カウント信号で示される現金の額を現金投入額に加算する。

現金が追加投入されていないと判断した場合（ステップＳ３２４でＮＯの場合）、または、ステップＳ３２５の後、データ処理部３１０は、現金投入額以下の金額ボタンを有効化制御する。有効化制御が実行されることにより、操作部３３０の金額ボタンへの操作が有効に受付可能にされるとともに、有効となった金額ボタンに設けられているランプが点灯される。

そして、ステップＳ３２７で、データ処理部３１０は、ステップＳ３２６で有効化された金額ボタンが操作されたことを示す操作信号を操作部３３０から受信したか否かを判断する。つまり、現金投入額以下の金額ボタンが操作されたか否かを判断する。現金投入額以下の金額ボタンが操作されていないと判断した場合（ステップＳ３２７でＮＯの場合）、データ処理部３１０は、実行する処理をステップＳ３２４に戻す。

一方、有効化された金額ボタンが操作されたと判断した場合（ステップＳ３２７でＹＥＳの場合）、データ処理部３１０は、ステップＳ３２８で、操作信号で示される金額ボタンの金額を購入金額にセットする。その後、データ処理部３１０は、実行する処理をステップＳ３６１に進める。

一方、現金投入信号を受信していないと判断した場合（ステップＳ３２０でＮＯの場合）、データ処理部３１０は、ステップＳ３２１で、操作部３３０の利用ボタンの操作が操作されたことを示す操作信号を操作部３３０から受信したか否かを判断することによって、利用ボタンが操作されたか否かを判断する。利用ボタンは、バリューを使用するときにユーザが操作するボタンである。利用ボタンが操作されていないと判断した場合（ステップＳ３２１でＮＯの場合）、データ処理部３１０は、実行する処理をステップＳ３１０に戻す。

一方、利用ボタンが操作されたと判断した場合（ステップＳ３２１でＹＥＳの場合）、データ処理部３１０は、ステップＳ３２２で、図４０の不正登録処理で携帯使用禁止情報が記憶部３２０に記憶されたか否かを判断する。つまり、すべての携帯電話１００でのバリューの使用が禁止されているか否かを判断する。

すべての携帯電話１００でのバリューの使用が禁止されていないと判断した場合（ステップＳ３２２でＮＯの場合）、データ処理部３１０は、ステップＳ３３１で、全金額の金額ボタンを有効化制御する。そして、ステップＳ３３２で、データ処理部３１０は、ステップＳ３３１で有効化制御された金額ボタンが操作されたことを示す操作信号を操作部３３０から受信したか否かを判断する。つまり、いずれかの金額ボタンが操作されたか否かを判断する。いずれの金額ボタンも操作されていないと判断した場合（ステップＳ３３１でＮＯの場合）、データ処理部３１０は、ステップＳ３３１を繰返す。

一方、いずれかの金額ボタンが操作されたと判断した場合（ステップＳ３３１でＹＥＳの場合）、データ処理部３１０は、ステップＳ３３３で、操作信号で示される金額ボタンの金額を購入金額にセットする。

そして、データ処理部３１０は、ステップＳ３４１で、チップリーダライタ３９０によって携帯電話１００の非接触型ＩＣチップ１９０からバリュー残高が読込まれたか否かを判断する。バリュー残高はバリュー残額として読込まれる。読込まれていないと判断した場合（ステップＳ３４１でＮＯの場合）、データ処理部３１０は、ステップＳ３４１の処理を繰返す。なお、一定時間（たとえば、３０秒）、バリュー残高が読込まれないと判断した場合に、データ処理部３１０は、ステップＳ３３１で有効化された金額ボタンを無効化して、購入金額をリセットするようにしてもよい。

一方、携帯電話１００からバリュー残高が読込まれたと判断した場合（ステップＳ３４１でＹＥＳの場合）、データ処理部３１０は、ステップＳ３４２で、バリュー残高とともに読込まれた携帯ＩＤが図４０の不正登録処理で記憶部３２０に記憶された不正端末情報により示される携帯ＩＤまたは利用停止携帯情報により示される携帯ＩＤであるか否かを判断する。つまり、不正な携帯電話１００であるか否かを判断する。

不正携帯電話であると判断した場合（ステップＳ３４２でＹＥＳの場合）、データ処理部３１０は、ステップＳ３４３で、エラー報知する。エラー報知としては、たとえば、警報ランプを点滅させたり、警報ブザーを鳴動させたりする。そして、ステップＳ３４４で、データ処理部３１０は、遊技場３０の係員によって不正携帯電話であるか否かが確認されて、確認操作がされたか否かを判断する。確認操作がされていない場合（ステップＳ３４４でＮＯの場合）、データ処理部３１０は、ステップＳ３４４を繰返す。一方、確認操作がされたと判断した場合（ステップＳ３４４でＹＥＳの場合）、データ処理部３１０は、実行する処理をステップＳ３１０に戻す。

不正携帯電話でないと判断した場合（ステップＳ３４２でＮＯの場合）、データ処理部３１０は、ステップＳ３４５で、バリュー残高とともに読込まれた携帯ＩＤが、テスト用の携帯電話１００の携帯ＩＤであるか否かを判断する。つまり、バリュー残高が読込まれた携帯電話１００がテスト用であるか否かを判断する。テスト用の携帯電話１００の携帯ＩＤは、電子マネー管理サーバ２００から店舗サーバ８００を介して、または、直接、券売機３００に入力されることによって、券売機３００の記憶部３２０に予め記憶される。

テスト用携帯電話であると判断した場合（ステップＳ３４５でＹＥＳの場合）、ステップＳ３４６で、データ処理部３１０は、テスト用の携帯電話の使用を許可する設定がされているか否かを判断する。テスト用の携帯電話の使用を許可するか否かは、券売機３００に予め設定される。

なお、店舗サーバ８００にテスト用の携帯電話の使用を許可するか否かの設定が予め記憶されるようにして、ステップＳ３４６で、データ処理部３１０が、店舗サーバ８００に問合わせて、テスト用の携帯電話の使用を許可する設定がされているか否かを判断するようにしてもよい。

テスト用携帯電話の使用許可設定がされていないと判断した場合（ステップＳ３４６でＮＯの場合）、データ処理部３１０は、ステップＳ３４７で、ステップＳ３４３と同様に、エラー報知する。そして、ステップＳ３４８で、データ処理部３１０は、遊技場３０の係員によって不正携帯電話であるか否かが確認されて、確認操作がされたか否かを判断する。確認操作がされていない場合（ステップＳ３４８でＮＯの場合）、データ処理部３１０は、ステップＳ３４８を繰返す。一方、確認操作がされたと判断した場合（ステップＳ３４８でＹＥＳの場合）、データ処理部３１０は、実行する処理をステップＳ３１０に戻す。

一方、テスト用携帯端末でないと判断した場合（ステップＳ３４５でＮＯの場合）、または、テスト用携帯電話の使用許可設定がされていると判断した場合（ステップＳ３４６でＹＥＳの場合）、データ処理部３１０は、実行する処理をステップＳ３５１に進める。

一方、すべての携帯電話１００でのバリューの使用が禁止されていると判断した場合（ステップＳ３２２でＹＥＳの場合）、データ処理部３１０は、実行する処理をステップＳ３１０に戻す。

なお、ステップＳ３４２でＹＥＳの場合、および、ステップＳ３４６でＮＯの場合は、データ処理部３１０は、ステップＳ３３１で有効化された金額ボタンを無効化して、購入金額をリセットする。

ステップＳ３５１では、データ処理部３１０は、購入金額がバリュー残額よりも大きな額であるか否かを判断する。購入金額がバリュー残額よりも大きな額でないと判断した場合（ステップＳ３５１でＮＯの場合）、ステップＳ３５６において、データ処理部３１０は、購入金額分のバリューを携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２から減算させるための減算要求信号を携帯電話１００に送信させるように、チップリーダライタ３９０を制御する。

具体的には、データ処理部３１０は、複数種類の電子マネーのうちバリューを引落対象として指定する電子マネー識別情報と、引落額相当のバリューを減算する旨を示す減算額情報とを含む減算要求信号を携帯電話１００に送信するように非接触通信部３９３を制御する旨の減算制御コマンドをチップリーダライタ３９０の制御部３９１に送信する。チップリーダライタ３９０の制御部３９１は、減算制御コマンドに応じて、減算要求信号を携帯電話１００に送信するよう非接触通信部３９３を制御する。

一方、減算要求信号を受信した携帯電話１００では、非接触型ＩＣチップ１９０の制御部１９１により、記憶部１９２の確保された領域に記憶されている引落対象として指定されている電子マネーから、引落額相当のバリューを減算し、バリューの減算が終了するとその旨を示す減算終了信号を券売機３００のチップリーダライタ３９０に送信する処理が行なわれる。

そして、データ処理部３１０は、ステップＳ３５７で、携帯電話１００から減算終了信号を受信したか否かを判断する。具体的には、チップリーダライタ３９０の制御部３９１は、携帯電話１００からの減算終了信号の受信に応じて、減算が終了した旨の減算終了コマンドをデータ処理部３１０に送信する。データ処理部３１０は、減算終了コマンドを受信すると、引落額相当のバリューの減算が終了したと判断する。データ処理部３１０は、ステップＳ３５７において、減算終了コマンドが受信されるまで繰返し判断を行なう。なお、所定条件（判定回数、時間等）が成立するまでに、減算終了コマンドを受信しない場合には、減算が終了しない旨のエラーを表示部３４０において報知するようにしてもよい。

減算終了信号を受信したと判断した場合（ステップＳ３５７でＹＥＳの場合）、ステップＳ３５８で、データ処理部３１０は、バリュー残額から購入金額を減算した額が所定額以下であるか否かを判断する。バリュー残額から購入金額を減算した額が所定額以下であると判断した場合（ステップＳ３５８でＹＥＳの場合）、ステップＳ３５９で、データ処理部３１０は、携帯電話１００の非接触型ＩＣチップ１９０に、減算後残高僅少情報を含むアプリ起動信号を送信するように、チップリーダライタ３９０を制御する。

減算後残高僅少情報は、バリューの減算後に携帯電話１００に記憶されているバリューの額が僅少である旨を携帯電話１００に伝達するための情報である。アプリ起動信号は、携帯電話１００の電子マネーアプリ１１１を外部から起動させるための信号である。所定額は、たとえば、最低額のプリペイドカード３７１を１回購入できる額であり、本実施の形態においては、１０００円である。なお、所定額は、僅少な額であれば、他の額であってもよい。

一方、バリュー残額から購入金額を減算した額が所定額以下でないと判断した場合（ステップＳ３５８でＮＯの場合）、または、ステップＳ３５９の後、データ処理部３１０は、実行する処理をステップＳ３６１に進める。

一方、購入金額がバリュー残額よりも大きな額であると判断した場合（ステップＳ３５１でＹＥＳの場合）、ステップＳ３５２で、データ処理部３１０は、減算前残高不足情報を含むアプリ起動信号を携帯電話１００の非接触型ＩＣチップ１９０に送信するように、チップリーダライタ３９０を制御する。減算前残高不足情報は、バリューを減算する前に携帯電話１００に記憶されているバリューの額が不足している旨を携帯電話１００に伝達するための情報である。アプリ起動信号は、ステップＳ３５９で説明したものと同様である。その後、データ処理部３１０は、実行する処理をステップＳ３１０に戻す。

ステップＳ３６１では、データ処理部３１０は、発券するプリペイドカード３７１のカードＩＤ、購入に用いた現金額、購入に用いた携帯電話１００の携帯ＩＤ、購入に用いたバリューの額（以下、取引額ともいう）、購入日（以下、取引日ともいう）、購入時刻（以下、取引時刻ともいう）、および、当該券売機３００の装置ＩＤをそれぞれ特定する情報を含む取引情報を店舗サーバ８００に送信する。

次に、ステップＳ３６２で、データ処理部３１０は、購入金額のプリペイドカード３７１を発券するよう、カードリーダライタ３７０を制御する。なお、現金投入額が購入金額より多い場合は、データ処理部３１０は、現金投入額から購入金額を減算した釣銭を払出すよう、貨幣処理機３８０を制御する。そして、データ処理部３１０は、ステップＳ３６３で、購入金額、バリュー残額、および、現金投入額をリセットして、実行する処理をステップＳ３１０に戻す。

ステップＳ３５９、または、ステップＳ３５２が実行されることによって券売機３００から送信されたアプリ起動信号を非接触型ＩＣチップ１９０で受信すると、非接触型ＩＣチップ１９０の制御部１９１は、電子マネーアプリ１１１を起動させるコマンドをデータ処理部１１０に出力する。電子マネーアプリ１１１を起動させるコマンドを受けると、データ処理部１１０は、電子マネーアプリ１１１を起動させる。

図４１は、本実施の形態における電子マネーシステム１０において券売機３００から携帯電話１００の電子マネーアプリ１１１が起動されるときに携帯電話１００の表示部１４０に表示される第１の表示画面図である。図４１（ａ）の画面は、図２９（ａ）の画面と同様であるので、重複する説明は繰返さない。

図１１に戻って、電子マネーアプリ１１１のステップＳ１８０で、データ処理部１１０は、電子マネーアプリ１１１の起動が非接触型ＩＣチップ１９０からの起動であるか否かを判断する。非接触型ＩＣチップ１９０からの起動であると判断した場合（ステップＳ１８０でＹＥＳの場合）、ステップＳ１８００で、データ処理部１１０は、ＩＣチップ起動処理を実行する。

図１３は、本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるＩＣチップ起動処理の流れを示すフローチャートである。図１３を参照して、まず、ステップＳ１８１では、データ処理部１１０は、減算前残高不足情報を受信したか否かを判断する。つまり、電子マネーアプリ１１１を起動させたアプリ起動信号に減算前残高不足情報が含まれているか否かを判断する。減算前残高不足情報を受信していないと判断した場合（ステップＳ１８１でＮＯの場合）、ステップＳ１８２で、データ処理部３１０は、減算後残高不足情報を受信したか否かを判断する。つまり、電子マネーアプリ１１１を起動させたアプリ起動信号に減算後残高不足情報が含まれているか否かを判断する。

減算後残高不足情報を受信していないと判断した場合（ステップＳ１８２でＮＯの場合）、ステップＳ１８４で、データ処理部３１０は、携帯電話１００に記憶されているバリューの残高が僅少である旨を報知する。本実施の形態においては、残高が僅少である旨を表示部１４０に表示させることによって残高が僅少であることを報知する。しかし、これに限定されず、たとえば、データ処理部３１０は、残高が僅少である旨の音声を出力したり、残高が僅少である旨の振動を発生させたりすることによって、残高が僅少であることを報知するようにしてもよい。

図４１に進んで、図４１（ｂ）は、残高が僅少である旨の表示画面図である。図４１（ｂ）の画面には、携帯電話１００に記憶されているバリューの残高が僅少である旨、および、バリューの購入のための処理に移行する旨が表示される。

図１３に戻って、減算前残高不足情報を受信したと判断した場合（ステップＳ１８１でＹＥＳの場合）、または、減算後残高不足情報を受信したと判断した場合（ステップＳ１８２でＹＥＳの場合）、ステップＳ１８５で、データ処理部３１０は、携帯電話１００に記憶されているバリューの残高が不足している旨を報知する。本実施の形態においては、残高が不足している旨を表示部１４０に表示させることによって残高が不足していることを報知する。しかし、これに限定されず、たとえば、データ処理部３１０は、残高が不足している旨の音声を出力したり、残高が不足している旨の振動を発生させたりすることによって、残高が不足していることを報知するようにしてもよい。

図４１に進んで、図４１（ｃ）は、残高が不足している旨の表示画面図である。図４１（ｃ）の画面には、携帯電話１００に記憶されているバリューの残高が不足している旨、および、バリューの購入のための処理に移行する旨が表示される。

なお、本実施の形態においては、携帯電話１００に記憶されているバリューの残高が僅少であること、および、不足していることを分けて、券売機３００から携帯電話１００にアプリ起動信号を送信するようにして携帯電話１００で報知するようにした。しかし、これに限定されず、バリューの残高が僅少であること、および、不足していることを分けずに、携帯電話１００で報知するようにしてもよい。つまり、バリューの残高が０円であるときを含めてバリューの残高が所定額以下のときにバリューの残高が不足している旨の残高不足情報を券売機３００から携帯電話１００に送信するようにして携帯電話１００で残高が不足している旨を報知するようにしてもよい。

図１３に戻って、ステップＳ１８４、または、ステップＳ１８５の後、データ処理部１１０は、実行する処理をこの処理の呼出元の処理である電子マネーアプリ１１１に戻す。

図１１に戻って、ステップＳ１８００のＩＣチップ起動処理の後、ステップＳ１３０で、データ処理部３１０は、バリュー購入時処理を実行する。バリュー購入時処理が実行されることによって、図１５で説明したように、ステップＳ１３９で、購入金額選択画面が表示される。このように、ユーザが電子マネーアプリ１１１を起動させなくても、自動的に購入金額選択画面を表示させることができる。

なお、ステップＳ１８００のＩＣチップ起動処理の後、ステップＳ１３０に遷移するようにしたが、これに限定されず、ステップＳ１９２に遷移するようにしてもよい。これによって、ユーザが起動時初期画面でバリュー購入を選択することによって、バリュー購入時処理を実行させることができる。

図４２は、本実施の形態におけるカードユニット６００で実行される球貸処理の流れを示すフローチャートである。図４２を参照して、まず、ステップＳ６１０で、カードユニット６００のデータ処理部６１０は、ユニット不正登録処理を実行する。

図４４は、本実施の形態におけるカードユニット６００で実行されるユニット不正登録処理の流れを示すフローチャートである。図４４を参照して、ステップＳ６０１で、データ処理部６１０は、電子マネー管理サーバ２００から店舗サーバ８００を介して、携帯使用禁止情報を受信したか否かを判断する。携帯使用禁止情報は、図４０のステップＳ３１１で説明したので重複する説明は繰返さない。

携帯使用禁止情報を受信したと判断した場合（ステップＳ６０１でＹＥＳの場合）、データ処理部６１０は、ステップＳ６０２で、携帯使用禁止情報を記憶部６２０に記憶させる。一方、携帯使用禁止情報を受信していないと判断した場合（ステップＳ６０１でＮＯの場合）、または、ステップＳ６０２の後、データ処理部６１０は、実行する処理をステップＳ６０３に進める。

ステップＳ６０３では、データ処理部６１０は、電子マネー管理サーバ２００から店舗サーバ８００を介して、不正端末情報を受信したか否かを判断する。不正端末情報は、図４０のステップＳ３１３で説明したので重複する説明は繰返さない。

不正端末情報を受信したと判断した場合（ステップＳ６０３でＹＥＳの場合）、データ処理部６１０は、ステップＳ６０４で、不正端末情報を記憶部６２０に記憶させる。一方、不正端末情報を受信していないと判断した場合（ステップＳ６０３でＮＯの場合）、または、ステップＳ６０４の後、ステップＳ６０５で、データ処理部６１０は、電子マネー管理サーバ２００から店舗サーバ８００を介して、不正カードＩＤを受信したか否かを判断する。

不正カードＩＤは、不正な携帯電話１００で購入されたプリペイドカード３７１を識別するためのＩＤである。不正カードＩＤを送信する処理については、後述する図４５および図５０で説明する。

不正カードＩＤを受信したと判断した場合（ステップＳ６０５でＹＥＳの場合）、データ処理部６１０は、ステップＳ６０６で、不正カードＩＤを記憶部６２０に記憶させる。不正カードＩＤを受信していないと判断した場合（ステップＳ６０５でＮＯの場合）、または、ステップＳ６０６の後、ステップＳ６０７で、データ処理部６１０は、電子マネー管理サーバ２００から店舗サーバ８００を介して、利用停止情報を受信したか否かを判断する。利用停止情報は、図４０のステップＳ３１５で説明したので重複する説明は繰返さない。

利用停止情報を受信したと判断した場合（ステップＳ６０７でＹＥＳの場合）、データ処理部６１０は、ステップＳ６０８で、利用停止情報に含まれる携帯端末情報を利用停止携帯情報として記憶部６２０に記憶させる。一方、利用停止情報を受信していないと判断した場合（ステップＳ６０７でＮＯの場合）、または、ステップＳ６０８の後、データ処理部６１０は、実行する処理をこのユニット不正登録処理の呼出元の処理である図４２の球貸処理に戻す。

図４２に戻って、データ処理部６１０は、ステップＳ６１１で、カードリーダライタ６７０からプリペイドカード３７１が投入されたことを示す投入信号を受信したか否かを判断する。

投入信号を受信したと判断した場合（ステップＳ６１１でＹＥＳの場合）、データ処理部６１０は、ステップＳ６１２で、カードリーダライタ６７０から、投入されたプリペイドカード３７１のカードＩＤが、記憶部６２０に記憶された不正カードＩＤと同じであることを示す不正カード信号を受信したか否かを判断する。

不正カードでないと判断した場合（ステップＳ６１２でＮＯの場合）、データ処理部６１０は、実行する処理をステップＳ６９０に進める。一方、不正カードであると判断した場合（ステップＳ６１２でＹＥＳの場合）、データ処理部６１０は、ステップＳ６７１で、不正なプリペイドカードが投入された旨をエラー報知する。エラー報知は、たとえば、警報ランプを点滅させたり、警報ブザーを鳴動させたりすることによって行なう。そして、ステップＳ６７２で、データ処理部６１０は、遊技場３０の係員によってエラー報知が確認されたことを示す確認操作があったか否かを判断する。確認操作がないと判断した場合（ステップＳ６７２でＮＯの場合）、データ処理部６１０は、ステップＳ６７２の処理を繰返す。一方、確認操作があったと判断した場合（ステップＳ６７２でＹＥＳの場合）、データ処理部６１０は、実行する処理をステップＳ６１０に戻す。

一方、投入信号を受信していないと判断した場合（ステップＳ６１１でＮＯの場合）、データ処理部６１０は、ステップＳ６２０で、貨幣処理機６８０から現金が投入された旨の現金投入信号を受信したか否かを判断する。

現金投入信号を受信したと判断した場合（ステップＳ６２０でＹＥＳの場合）、ステップＳ６８１で、データ処理部６１０は、発券するプリペイドカード３７１のカードＩＤ、および、購入に用いた現金額をそれぞれ特定する情報を含む取引情報を店舗サーバ８００に送信する。

次に、ステップＳ６８２で、データ処理部６１０は、プリペイドカード３７１を発行し、貨幣処理機６８０からの現金カウント信号で示される現金投入額を、カードリーダライタ６７０の内部に予めストックされているプリペイドカード３７１に入金するよう、カードリーダライタ６７０を制御する。なお、ここでは、プリペイドカード３７１は、入金後、カードユニット６００の中に保持されて、排出されない。その後、データ処理部６１０は、実行する処理をステップＳ６９０に進める。

ステップＳ６９０では、データ処理部６１０は、プリペイド球貸処理を実行する。プリペイド球貸処理については、後述する図４３で説明する。

図４３は、本実施の形態におけるカードユニット６００で実行されるプリペイド球貸処理の流れを示すフローチャートである。

図４３を参照して、ステップＳ６９１で、データ処理部６１０は、貨幣処理機６８０から現金が投入された旨の現金投入信号を受信したか否かを判断する。現金投入信号を受信したと判断した場合（ステップＳ６９１でＹＥＳの場合）、ステップＳ６９２で、データ処理部６１０は、貨幣処理機６８０から現金カウント信号を受信して、現金カウント信号で示される現金の額をプリペイドカード３７１に加算するよう、カードリーダライタ６７０を制御する。

一方、現金投入信号を受信していないと判断した場合（ステップＳ６９１でＮＯの場合）、または、ステップＳ６９２の後、データ処理部６１０は、ステップＳ６１３で、カードリーダライタ６７０によって読込まれたプリペイドカード３７１に記録されたプリペイドの残高を、カードリーダライタ６７０から受信する。

次に、ステップＳ６１４で、データ処理部６１０は、受信した残高が０より大きい値であるか、すなわち残高が０でないか否かを判断する。残高が０よりも大きい値でないと判断した場合（ステップＳ６１４でＮＯの場合）、データ処理部６１０は、実行する処理をステップＳ６３２に進める。

一方、残高が０より大きい値であると判断した場合（ステップＳ６１４でＹＥＳの場合）、データ処理部６１０は、ステップＳ６１５で、球貸ボタン６３１から球貸操作信号を受信したか否かを判断する。球貸操作信号を受信していないと判断した場合（ステップＳ６１５でＮＯの場合）、データ処理部６１０は、実行する処理をステップＳ６３１に進める。

一方、球貸操作信号を受信したと判断した場合（ステップＳ６１５でＹＥＳの場合）、データ処理部６１０は、ステップＳ６１６で、プリペイドカード３７１の残高から所定貸球相当の対価を減算する。次に、データ処理部６１０は、ステップＳ６１７で、減算した残高をプリペイドカード３７１に書込むよう、カードリーダライタ６７０を制御する。

次いで、ステップＳ６１８で、データ処理部６１０は、所定個数の遊技球の払出しを要求するための球貸信号をパチンコ遊技機７００に送信する。この球貸信号に応じて、パチンコ遊技機７００は、所定個数の遊技球を払出す。遊技者は、払出された遊技球を用いてパチンコ遊技を行なうことができる。なお、カードユニット６００は、球貸信号を送信することによりパチンコ遊技機７００に遊技球を払出させるものに限らず、自ら遊技球を払出すものであってもよい。すなわち、ステップＳ６１８において、遊技球を払出す処理を実行するものであってもよい。その後、データ処理部６１０は、実行する処理をステップＳ６３１に進める。

ステップＳ６３１では、データ処理部６１０は、返却ボタン６３２から返却操作信号を受信したか否かを判断する。返却操作信号を受信していないと判断した場合（ステップＳ６３１でＮＯの場合）、データ処理部６１０は、実行する処理をステップＳ６９１に戻す。

一方、返却操作信号を受信したと判断した場合（ステップＳ６３１でＹＥＳの場合）、データ処理部６１０は、実行する処理をステップＳ６３２に進める。

ステップＳ６３２では、データ処理部６１０は、プリペイドカード３７１から読込まれた残高をリセットする。次に、ステップＳ６３３で、データ処理部６１０は、プリペイドカード３７１を返却するように、カードリーダライタ６７０を制御する。その後、データ処理部６１０は、実行する処理をこのプリペイド球貸処理の呼出元の処理である図４２の球貸処理に戻す。

図４２に戻って、ステップＳ６９０でプリペイド球貸処理の実行後、データ処理部６１０は、実行する処理をステップＳ６１０に戻す。

一方、現金投入信号を受信していないと判断した場合（ステップＳ６２０でＮＯの場合）、データ処理部６１０は、ステップＳ６２２で、図４４のユニット不正登録処理で携帯使用禁止情報が記憶部６２０に記憶されたか否かを判断する。つまり、すべての携帯電話１００でのバリューの使用が禁止されているか否かを判断する。すべての携帯電話１００でのバリューの使用が禁止されていると判断した場合（ステップＳ６２２でＹＥＳの場合）、データ処理部６１０は、実行する処理をステップＳ６１０に戻す。

一方、すべての携帯電話１００でのバリューの使用が禁止されていないと判断した場合（ステップＳ６２２でＮＯの場合）、データ処理部６１０は、ステップＳ６４１からステップＳ６４８までの処理を実行する。ステップＳ６４１からステップＳ６４８までの処理は、図３９で説明した発券処理のステップＳ３４１からステップＳ３４８と同様であるので、説明は繰返さない。

ステップＳ６５１では、データ処理部６１０は、バリュー残額が０円であるか否かを判断する。バリュー残額が０円であると判断した場合（ステップＳ６５１でＹＥＳの場合）、ステップＳ６５２で、データ処理部６１０は、図３９の発券処理のステップＳ３５２と同様の減算前残高不足情報を含むアプリ起動信号を携帯電話１００の非接触型ＩＣチップ１９０に送信するように、チップリーダライタ６９０を制御する。その後、データ処理部６１０は、実行する処理をステップＳ６１０に戻す。

なお、本実施の形態においては、ステップＳ６５１で、バリュー残額が０円であるか否かを判断した。これは、本実施の形態におけるバリューは、遊技のみに用いられ、球貸の単位である１００円単位でバリューが引落とされるため、０円であるか否かを判断することによって、球貸可能なバリューが残っているか否かを判断できるためである。しかし、遊技場３０以外でもバリューを用いることができるようにした場合、ステップＳ６５１で、バリュー残額が球貸に用いることができる最低額である１００円未満であるか否かを判断するようにしてもよい。

一方、バリュー残額が０円でないと判断した場合（ステップＳ６５１でＮＯの場合）、データ処理部６１０は、ステップＳ６５３で、バリュー残額が１０００円以上であるか否かを判断する。バリュー残額が１０００円以上であると判断した場合（ステップＳ６５３でＹＥＳの場合）、ステップＳ６５４で、データ処理部６１０は、１０００円を購入金額にセットする。一方、バリュー残額が１０００円未満であると判断した場合（ステップＳ６５３でＮＯの場合）、ステップＳ６５５で、データ処理部６１０は、バリュー残額を購入金額にセットする。

なお、ステップＳ６５３およびステップＳ６５４では、１０００円としたので、後述するステップＳ６６２で、１０００円に相当する貸球が払出される。しかし、これに限定されず、５００円に相当する貸球が払出されるようにしてもよい。この場合、ステップＳ６５３で、バリュー残額が５００円以上であるか否かを判断し、ステップＳ６５４で、データ処理部６１０は、５００円を購入金額にセットする。

ステップＳ６５４またはステップＳ６５５の後、ステップＳ６５６で、データ処理部６１０は、図３９の発券処理のステップＳ３５６と同様に、購入金額分のバリューを携帯電話１００の非接触型ＩＣチップ１９０の記憶部１９２から減算させるための減算要求信号を携帯電話１００に送信させるように、チップリーダライタ６９０を制御する。

そして、データ処理部６１０は、ステップＳ６５７で、図３９の発券処理のステップＳ３５７と同様に、携帯電話１００から減算終了信号を受信したか否かを判断する。減算終了信号を受信していないと判断した場合（ステップＳ６５７でＮＯの場合）、データ処理部６１０は、ステップＳ６５７を繰返す。

一方、減算終了信号を受信したと判断した場合（ステップＳ６５７でＹＥＳの場合）、ステップＳ６５８で、データ処理部６１０は、バリュー残額から購入金額を減算した額が０円であるか否かを判断する。バリュー残額から購入金額を減算した額が０円であると判断した場合（ステップＳ６５８でＹＥＳの場合）、ステップＳ６５９で、データ処理部６１０は、携帯電話１００の非接触型ＩＣチップ１９０に、減算後残高不足情報を含むアプリ起動信号を送信するように、チップリーダライタ６９０を制御する。

減算後残高不足情報は、バリューの減算後に携帯電話１００に記憶されているバリューの額が不足している旨を携帯電話１００に伝達するための情報である。アプリ起動信号は、ステップＳ３５９で説明したものと同様である。

なお、ステップＳ６５１と同様、ステップＳ６５８で、バリュー残額から購入金額を減算した額が球貸に用いることができる最低額である１００円未満であるか否かを判断するようにしてもよい。

さらに、ステップＳ６５８に加えて、図３９の発券処理のステップＳ３５８と同様に、バリュー残額から購入金額を減算した額が所定額以下か否かを判断して、所定額以下である場合、ステップＳ３５９と同様に、減算後残額僅少情報を含むアプリ起動信号を携帯電話１００に送信するようにしてもよい。

一方、バリュー残額から購入金額を減算した額が０円でないと判断した場合（ステップＳ６５８でＮＯの場合）、または、ステップＳ６５９の後、データ処理部６１０は、ステップＳ６６１からステップＳ６６３までの処理を実行する。ステップＳ６６１からステップＳ６６３までの処理は、図３９の発券処理のステップＳ３６１からステップＳ３６３までの処理と同様であるので、説明は繰返さない。ステップＳ６６３の後、データ処理部６１０は、実行する処理をステップＳ６１０に戻す。

ステップＳ６５９またはステップＳ６５２が実行されることによってカードユニット６００から送信されたアプリ起動信号が非接触型ＩＣチップ１９０で受信されることによって実行される電子マネーアプリ１１１のステップＳ１８１からステップＳ１８５までの処理については、図１１で説明したので、説明は繰返さない。

図４５は、本実施の形態における電子マネー管理サーバ２００により実行される残高管理アプリケーションプログラム２１４の処理の流れを示すフローチャートである。

図４５を参照して、まず、ステップＳ２９１で、電子マネー管理サーバ２００のデータ処理部２１０は、店舗サーバ８００から取引情報を受信したか否かを判断する。この取引情報には、図５０のステップＳ８１４で後述するように、携帯端末情報ごとの取引額、取引日、取引時刻、取引に用いられた装置ＩＤ、および、取引が行なわれた店舗ＩＤが含まれる。取引情報を受信した場合（ステップＳ２９１でＹＥＳの場合）、データ処理部２１０は、ステップＳ２９２で、取引情報に含まれる携帯端末情報に対応して発行情報ＤＢ２２２に記憶されているバリュー残高から、取引情報に含まれる取引額を減算する。また、取引情報に含まれる携帯端末情報に対応して発行情報ＤＢ２２２に記憶されている取引額に、取引情報に含まれる取引額を加算する。また、取引情報に含まれる携帯端末情報に対応する取引情報ＤＢ２２４の欄に、取引情報に含まれる利用日、利用時刻、店舗ＩＤ、装置ＩＤおよび取引額からなる利用履歴を追加する。なお、ここでは、利用日および利用時刻の古いものから順に利用履歴が追加される。

ステップＳ２９２の後、ステップＳ２９３で、データ処理部２１０は、履歴判定処理を実行する。履歴判定処理については、後述する図４６で説明する。

図４６は、本実施の形態における電子マネー管理サーバ２００により実行される残高管理アプリケーションプログラム２１４のサブルーチンである履歴判定処理の流れを示すフローチャートである。

図４６を参照して、まず、ステップＳ２０８１で、データ処理部２１０は、取引情報ＤＢ２２４に含まれる携帯端末情報ごとの利用履歴群のうち、最初の携帯端末情報の利用履歴群を対象利用履歴群とする。

次に、ステップＳ２０８２で、データ処理部２１０は、変数ｎを１に初期化する。そして、ステップＳ２０８３で、データ処理部２１０は、対象利用履歴群のうち、今回更新された利用履歴のなかでｎ番目の利用履歴を取引情報ＤＢ２２４から抽出する。さらに、ステップＳ２０８４で、データ処理部２１０は、ステップＳ２０８３で抽出した利用履歴の１つ前の利用時刻の利用履歴を取引情報ＤＢ２２４から抽出する。

次いで、ステップＳ２０８５で、データ処理部２１０は、ステップＳ２０８３およびステップＳ２０８４で抽出した２つの利用履歴の利用日が一致するか否かを判断する。一致しないと判断した場合（ステップＳ２０８５でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２１８６に進める。

一方、２つの利用履歴の利用日が一致すると判定した場合（ステップＳ２０８５でＹＥＳの場合）、ステップＳ２０８６で、データ処理部２１０は、ステップＳ２０８３およびステップＳ２０８４で抽出した２つの利用履歴の店舗ＩＤが一致するか否かを判断する。一致すると判断した場合（ステップＳ２０８６でＹＥＳの場合）、データ処理部２１０は、実行する処理をステップＳ２１８６に進める。

一方、２つの利用履歴の店舗ＩＤが一致しないと判断した場合（ステップＳ２０８６でＮＯの場合）、ステップＳ２１８１で、データ処理部２１０は、店舗ＤＢから２つの利用履歴の店舗ＩＤで示される店舗の所在地を特定する。

図４７は、本実施の形態における電子マネー管理サーバに記憶される店舗データベースを説明するための図である。図４７を参照して、店舗ＤＢでは、店舗ＩＤに対応付けて、店舗の郵便番号、店舗の住所、および、店舗の最寄駅が記憶される。なお、ここでは、郵便番号、住所および最寄駅が記憶されるようにするが、いずれか少なくとも１つが記憶されるようにしてもよい。

これにより、電子マネー管理サーバ２００は、店舗ＩＤに基づき、当該店舗ＩＤに対応する、郵便番号、住所および最寄駅を容易に検索することができる。

図４７では、たとえば、店舗ＩＤとして「００００１」、「００００２」および「００００３」のそれぞれに対して、郵便番号として「１５０−００１１」、「１６０−００００」および「５３０−０００５」、住所として「東京都渋谷区甲１丁目２−３」、「東京都新宿区乙２丁目３−４」および「大阪府大阪市北区丙３丁目４−５」、最寄駅として「渋谷駅」、「新宿駅」および「大阪駅」が記憶されている。

図４８は、本実施の形態における電子マネー管理サーバに記憶される店舗データベースに含まれる店舗の位置を示す地図である。図４８を参照して、店舗３０Ａは、店舗ＤＢの店舗ＩＤ「００００１」の店舗である。同様に、店舗３０Ｂ，３０Ｃは、店舗ＤＢの店舗ＩＤ「００００２」，「００００３」の店舗である。

図４６に戻って、ステップＳ２１８１で、続いて、データ処理部２１０は、特定された２つの利用履歴の店舗ＩＤで示される店舗の所在地から、先に利用された店舗の所在地から後に利用された店舗の所在地までの推定移動時間を特定する。

所在地間の推定移動時間を特定する方法としては、たとえば、２つの利用履歴の店舗ＩＤで示される店舗の最寄駅間の移動時間を、鉄道事業者のダイヤから駅間の所要時間を計算するソフトウェアを利用して特定し、２つの利用履歴の店舗ＩＤで示される店舗の住所から最寄駅までの移動時間を、地図での直線距離を標準歩行速度（たとえば、時速４ｋｍ）で割ることによって算出して、それぞれを加算することによって算出することができる。また、たとえば特許第２７６６０３２号に記載の技術を用いて、所在地間の推定移動時間を特定するようにしてもよい。

そして、ステップＳ２１８２で、データ処理部２１０は、ステップＳ２１８１で特定した推定移動時間を、２つの利用履歴の店舗ＩＤで示される店舗のうちの先に利用された店舗の利用履歴の利用時刻に加算することによって、後に利用された店舗への推定到着時刻を算出する。

次に、ステップＳ２１８３で、データ処理部２１０は、２つの利用履歴の店舗ＩＤで示される店舗のうちの後に利用された店舗の利用履歴の利用時刻が、ステップＳ２１８２で算出した推定到着時刻の前であるか否かを判断する。後の利用時刻が推定到着時刻の前でないと判断した場合（ステップＳ２１８３でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２１８６に進める。

一方、後の利用時刻が推定到着時刻の前であると判断した場合（ステップＳ２１８３でＹＥＳの場合）、ステップＳ２１８４で、データ処理部２１０は、対象利用履歴群の携帯端末情報と、２つの利用履歴の店舗ＩＤと、異常が発生した旨とを報知する。この報知としては、たとえば、データ処理部２１０は、表示部２４０に、携帯端末情報、２つの店舗ＩＤおよび「異常発生」の文字を表示させる。

さらに、ステップＳ２１８５で、データ処理部２１０は、当該携帯端末情報で示される携帯電話１００でのバリューの利用を停止させることを指示するための利用停止情報を、すべての店舗の店舗サーバ８００に送信する。利用停止情報は、図３９のステップＳ３１５で説明したように、携帯端末情報を含む。

ステップＳ２１８６では、データ処理部２１０は、対象利用履歴群に次の利用履歴があるか否かを判断する。次の利用履歴があると判断した場合（ステップＳ２１８６でＹＥＳの場合）、ステップＳ２１８７で、データ処理部２１０は、変数ｎに１を加算して、実行する処理をステップＳ２０８３に戻す。

一方、次の利用履歴がないと判断した場合（ステップＳ２１８６でＮＯの場合）、ステップＳ２１８８で、データ処理部２１０は、次の携帯端末情報の利用履歴群があるか否かを判断する。次の携帯端末情報の利用履歴群があると判断した場合（ステップＳ２１８８でＹＥＳの場合）、ステップＳ２１８９で、データ処理部２１０は、次の携帯端末情報の利用履歴群を対象利用履歴群として、実行する処理をステップＳ２０８２に戻す。

一方、次の携帯端末情報の利用履歴群がないと判断した場合（ステップＳ２１８８でＮＯの場合）、データ処理部２１０は、実行する処理をこの履歴判定処理の呼出元の残高管理ＡＰ２１４に戻す。

図６に戻って、たとえば、ステップＳ２０８１またはステップＳ２１８９で、携帯端末情報「ＭＮ７ＲＥ」の利用履歴群が対象利用履歴群とされた場合について説明する。そして、今回更新された利用履歴が「２００６年１１月２２日」の「１０：３０：００」から「１２：１５：００」までの４つの利用履歴である場合、ｎ＝２のとき、ステップＳ２０８３で、対象利用履歴群のうち今回更新されたｎ＝２番目の利用履歴である利用日「２００６年１１月２２日」、利用時刻「１２：００：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００１」、および、取引金額「５００」が取引情報ＤＢ２２４から抽出される。ステップＳ２０８４では、ステップＳ２０８３で抽出された利用履歴の１つ前の利用時刻の利用履歴である利用日「２００６年１１月２２日」、利用時刻「１０：３０：００」、店舗ＩＤ「００００２」、装置ＩＤ「０００１」、および、取引金額「５００」が取引情報ＤＢ２２４から抽出される。

ステップＳ２０８５では、２つの利用履歴の利用日が「２００６年１１月２２日」であり一致すると判断され、ステップＳ２０８６では、２つの利用履歴の店舗ＩＤがそれぞれ「００００１」「００００２」であるので一致しないと判断される。そして、ステップＳ２１８１で、先に利用された店舗および後に利用された店舗の住所がそれぞれ「東京都新宿区乙２丁目３−４」および「東京都渋谷区甲１丁目２−３」であり、最寄駅がそれぞれ「新宿駅」および「渋谷駅」であることが特定される。次に、店舗ＩＤ「００００２」の先に利用された店舗の住所からその最寄駅の「新宿駅」までの地図上での直線距離が０．４ｋｍであれば、その直線距離を標準歩行速度の時速４ｋｍで割ることによって、先に利用された店舗から「新宿駅」までの移動時間は６分と算出され、後に利用された店舗の最寄駅の「渋谷駅」からその店舗の住所までの地図上の直線距離が０．６ｋｍであれば、同様に、「渋谷駅」から後に利用された店舗までの移動時間は９分と算出され、鉄道事業者のダイヤから駅間の所要時間を計算するソフトウェアが利用されて「新宿駅」から「渋谷駅」までの所要時間が７分と特定され、それぞれが加算されることによって、先に利用された店舗の所在地から後に利用された店舗の所在地までの推定移動時間が、たとえば「２２分」と特定される。次いで、ステップＳ２１８２で、推定移動時間「２２分」を先に利用された店舗の利用履歴の利用時刻「１０：３０：００」に加算して、後に利用された店舗への推定到着時刻が「１０：５２：００」と算出される。この場合は、ステップＳ２１８３で、後に利用された店舗の利用履歴の利用時刻「１２：００：００」が推定到着時刻「１０：５２：００」の前ではないと判断されるので、利用履歴は異常ではなく、ステップＳ２１８４での異常発生の報知およびステップＳ２１８５での利用停止情報の送信は行なわれない。

図４９は、本実施の形態における電子マネー管理サーバ２００の取引情報データベース２２４の利用履歴が異常である場合を説明するための図である。図４９を参照して、たとえば、ステップＳ２０８１またはステップＳ２１８９で、携帯端末情報「ＬＭ６ＱＤ」の利用履歴群が対象利用履歴群とされた場合について説明する。そして、今回更新された利用履歴が「２００６年１１月２３日」の「１０：３０：００」から「１２：１５：００」までの４つの利用履歴である場合、ｎ＝２のとき、ステップＳ２０８３で、対象利用履歴群のうち今回更新されたｎ＝２番目の利用履歴である利用日「２００６年１１月２３日」、利用時刻「１２：００：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００１」、および、取引金額「５００」が取引情報ＤＢ２２４から抽出される。ステップＳ２０８４では、ステップＳ２０８３で抽出された利用履歴の１つ前の利用時刻の利用履歴である利用日「２００６年１１月２３日」、利用時刻「１０：３０：００」、店舗ＩＤ「００００３」、装置ＩＤ「０００１」、および、取引金額「５００」が取引情報ＤＢ２２４から抽出される。

ステップＳ２０８５で、２つの利用履歴の利用日が「２００６年１１月２３日」であり一致すると判断され、ステップＳ２０８６で、２つの利用履歴の店舗ＩＤがそれぞれ「００００１」「００００３」であるので一致しないと判断される。そして、ステップＳ２１８１で、先に利用された店舗および後に利用された店舗の住所がそれぞれ「大阪府大阪市北区丙３丁目４−５」および「東京都渋谷区甲１丁目２−３」であり、最寄駅がそれぞれ「大阪駅」および「渋谷駅」であることが特定され、先に利用された店舗の所在地から後に利用された店舗の所在地までの推定移動時間が、たとえば「３時間３０分」と特定される。次いで、ステップＳ２１８２で、推定移動時間「３時間３０分」を先に利用された店舗の利用履歴の利用時刻「１０：３０：００」に加算して、後に利用された店舗への推定到着時刻が「１４：００：００」と算出される。この場合は、ステップＳ２１８３で、後に利用された店舗の利用履歴の利用時刻「１２：００：００」が推定到着時刻「１４：００：００」の前であると判断されるので、利用履歴は異常であり、ステップＳ２１８４での異常発生の報知およびステップＳ２１８５での利用停止情報の送信が行なわれる。

図４５に戻って、ステップＳ２９３の後、または、取引情報を受信していないと判断した場合（ステップＳ２９１でＮＯの場合）、データ処理部２１０は、ステップＳ２８１で、チャージ累計額から取引額を減算した額がマイナスの会員ＩＤがあるか否かを判断する。

チャージ累計額から取引額を減算した額がマイナスの会員ＩＤがあると判断した場合（ステップＳ２８１でＹＥＳの場合）、ステップＳ２８２で、データ処理部２１０は、その会員ＩＤの不正回数を１回加算する。

ステップＳ２８２の後、または、チャージ累計額から取引額を減算した額がマイナスの会員ＩＤがないと判断した場合（ステップＳ２８１でＮＯの場合）、ステップＳ２８３で、データ処理部２１０は、不正回数が１回の会員ＩＤがあるか否かを判断する。

不正回数１回の会員ＩＤがあると判断した場合（ステップＳ２８３でＹＥＳの場合）、ステップＳ２８４で、データ処理部２１０は、その会員ＩＤに対応する携帯ＩＤの携帯電話のバリューを使用して購入されたプリペイドカードのカードＩＤをユニットに登録する旨および当該携帯ＩＤを含む不正媒体情報を遊技場３０側に送信する。

ステップＳ２８４の後、または、不正回数１回の会員ＩＤがないと判断した場合（ステップＳ２８３でＮＯの場合）、ステップＳ２８５で、データ処理部２１０は、不正回数が２回の会員ＩＤがあるか否かを判断する。

不正回数２回の会員ＩＤがあると判断した場合（ステップＳ２８５でＹＥＳの場合）、ステップＳ２８６で、データ処理部２１０は、その会員ＩＤに対応する携帯ＩＤを券売機３００に登録する旨、および、その会員ＩＤに対応する携帯ＩＤを含む不正端末情報を不正が発生した遊技場３０側に送信する。また、ステップＳ２８７で、データ処理部２１０は、不正端末情報を不正が発生した遊技場３０と同じ商圏の他の遊技場側にも送信する。なお、データ処理部２１０が不正端末情報を送信する遊技場は、不正が発生した遊技場３０、または、不正が発生した遊技場３０と同じ商圏の他の遊技場に限定されず、全国の遊技場であってもよいし、不正が発生した遊技場３０の近隣の遊技場であってもよい。

ステップＳ２８７の後、または、不正回数２回の会員ＩＤがないと判断した場合（ステップＳ２８５でＮＯの場合）、ステップＳ２８８で、データ処理部２１０は、全国の遊技場で発生した不正回数が３回以上であるか否かを判断する。

全国の遊技場で発生した不正回数が３回以上であると判断した場合（ステップＳ２８８でＹＥＳの場合）、ステップＳ２８９で、データ処理部２１０は、携帯使用禁止情報を遊技場３０側に送信する。また、ステップＳ２９０で、データ処理部２１０は、携帯使用禁止情報を不正が発生した遊技場３０と全国の遊技場側にも送信する。なお、データ処理部２１０が携帯使用禁止情報を、不正が発生した遊技場３０以外にも、全国の遊技場に送信する場合について説明したが、これに限らず、不正が発生した遊技場３０と同じ商圏の他の遊技場や、不正が発生した遊技場３０と近隣の遊技場に送信するものであってもよい。この場合、ステップＳ２８８においては、携帯使用禁止情報の送信対象となる遊技場で発生した不正回数が３回以上であるか否かを判断するようにしてもよい。その後、データ処理部２１０は、実行する処理をステップＳ２９１に戻す。

図５０は、本実施の形態における店舗サーバ８００で実行される店舗サーバ処理の流れを示すフローチャートである。図５０を参照して、店舗サーバ８００のデータ処理部は、ステップＳ８１１で、券売機３００またはカードユニット６００から取引情報を受信したか否かを判断する。

取引情報を受信したと判断した場合（ステップＳ８１１でＹＥＳの場合）、店舗サーバ８００のデータ処理部は、ステップＳ８１２で、店舗履歴判定処理を実行する。店舗履歴判定処理については、後述する図５１で説明する。

図５１は、本実施の形態における店舗サーバ８００により実行される店舗サーバ処理のサブルーチンである店舗履歴判定処理の流れを示すフローチャートである。

図５１を参照して、まず、ステップＳ８３１で、店舗サーバ８００のデータ処理部は、受信した取引情報に含まれる携帯端末情報ごとに、発券したプリペイドカード３７１のカードＩＤ、発券，球貸に用いた現金額、発券，球貸に用いたバリューの額、発券，球貸の利用日、発券，球貸の利用時刻、および、発券した発券機３００または球貸ししたカードユニット６００の装置ＩＤをそれぞれ特定する情報を対応させて記憶部の店舗内取引情報ＤＢに利用履歴として記憶させる。

次に、ステップＳ８３２で、店舗サーバ８００のデータ処理部は、受信した取引情報に含まれる携帯端末情報と同じ携帯端末情報の利用履歴であって受信した取引情報の１つ前の利用時刻の利用履歴を店舗内取引情報ＤＢから抽出する。

ステップＳ８３３では、店舗サーバ８００のデータ処理部は、受信した取引情報およびステップＳ８３２で抽出した取引情報のそれぞれに含まれる装置ＩＤが一致するか否かが判断される。一致すると判断した場合（ステップＳ８３３でＹＥＳの場合）、店舗サーバ８００のデータ処理部は、実行する処理をこの店舗履歴判定処理の呼出元の店舗サーバ処理に戻す。

一方、装置ＩＤが一致しないと判断した場合（ステップＳ８３３でＮＯの場合）、ステップＳ８３４で、店舗サーバ８００のデータ処理部は、受信した取引情報およびステップＳ８３２で抽出した取引情報のそれぞれに含まれる利用時刻の差が基準時間の１分３０秒以内であるか否かを判断する。この基準時間は、たとえば、カードユニット６００で５００円相当のバリューでの１回の球貸しで１２５発のパチンコ玉を払出して、パチンコ遊技機７００で１分間に１００発のパチンコ玉が発射可能な場合、１回の球貸しで払出されたパチンコ玉がすべて発射されるまでの所要時間が、最低１分１５秒掛かり、これに遊技者の別のパチンコ遊技機７００への移動時間を加味して１分３０秒とした。

図５２は、本実施の形態における遊技場３０Ａに設置されるカードユニット６００、パチンコ遊技機７００および座席のレイアウトを示す図である。図５２を参照して、基準時間は、１分３０秒のように一定の基準時間に限定されず、移動距離に応じた基準時間とするようにしてもよい。具体的には、まず、受信した取引情報およびステップＳ８３２で抽出した取引情報それぞれの装置ＩＤで示されるカードユニット６００が設置される遊技機島が何島分離れているかを特定し、次に、遊技機島がｎ島分離れている場合に、基準時間を１分１５秒＋（ｎ＋１）×１５秒のような式から算出するようにしてもよい。たとえば、座席７１０Ａから座席７１０Ｄまでが含まれる遊技機島と、座席７１０Ｅから座席７１０Ｌまでが含まれる遊技機島とは、１島分離れているので、基準時間が１分１５秒＋（１＋１）×１５秒＝１分４５秒と算出される。

図５１に戻って、利用時刻の差が基準時間以内であると判断した場合（ステップＳ８３４でＹＥＳの場合）、ステップＳ８３５で、店舗サーバ８００のデータ処理部は、受信した取引情報およびステップＳ８３２で抽出した取引情報のそれぞれに含まれる装置ＩＤで示されるカードユニット６００に対応する座席が隣接するか否かを判断する。

図５２に進んで、本実施の形態において、隣接とは、左右１つ隣りであることとする。たとえば、座席７１０Ｂに隣接する座席は、座席７１０Ａ，７１０Ｃとする。しかし、これに限定されず、隣接とは、１台の携帯電話１００を容易に共用可能な座席の配置関係であればよい。たとえば、背中合わせの座席を含むようにしてもよい。この場合、座席７１０Ｂの背中合わせの座席は、座席７１０Ｆである。また、左右２つ以上隣りの座席を含むようにしてもよいし、斜め後ろの座席を含むようにしてもよい。

図５１に戻って、座席が隣接すると判断した場合（ステップＳ８３５でＹＥＳの場合）、ステップＳ８３６で、店舗サーバ８００のデータ処理部は、店舗サーバ８００の表示部に、受信した取引情報の携帯端末情報と、受信した取引情報およびステップＳ８３２で抽出した取引情報の２台の装置ＩＤと、その装置ＩＤで示されるカードユニット６００に対応する座席が１台の携帯電話１００を容易に共用可能な配置関係である旨とを表示する。ステップＳ８３６の後、店舗サーバ８００のデータ処理部は、実行する処理をこの店舗履歴判定処理の呼出元の店舗サーバ処理に戻す。

利用時刻の差が基準時間以内でないと判断した場合（ステップＳ８３４でＮＯの場合）、ステップＳ８４１で、店舗サーバ８００のデータ処理部は、受信した取引情報に含まれる装置ＩＤと同じ携帯端末情報および装置ＩＤの利用履歴が、店舗内取引情報ＤＢに記憶されている利用履歴のうち、受信した取引情報に含まれる利用時刻から所定時間内の利用時刻の利用履歴に含まれるか否かを判断する。本実施の形態においては、所定時間は８分間であることとする。

同じ携帯端末情報および装置ＩＤの利用履歴が所定時間内にあると判断した場合（ステップＳ８４１でＹＥＳの場合）、ステップＳ８４２で、店舗サーバ８００のデータ処理部は、受信した取引情報に含まれる装置ＩＤと同じ携帯端末情報で異なる装置ＩＤの利用履歴の組が、店舗内取引情報ＤＢに記憶されている利用履歴のうち、受信した取引情報に含まれる利用時刻から所定時間内の利用時刻の利用履歴に含まれるか否かを判断する。

同じ携帯端末情報および装置ＩＤの利用履歴が所定時間内にないと判断した場合（ステップＳ８４１でＮＯの場合）、および、同じ携帯端末情報で異なる装置ＩＤの利用履歴の組が所定時間内にないと判断した場合（ステップＳ８４２でＮＯの場合）、店舗サーバ８００のデータ処理部は、実行する処理をこの店舗履歴判定処理の呼出元の店舗サーバ処理に戻す。

一方、座席が隣接しないと判断した場合（ステップＳ８３５でＮＯの場合）、または、同じ携帯端末情報で異なる装置ＩＤの利用履歴の組が所定時間内にあると判断した場合（ステップＳ８４２でＮＯの場合）、ステップＳ８４３で、店舗サーバ８００のデータ処理部は、受信した取引情報の携帯端末情報と、受信した取引情報およびステップＳ８３２で抽出した取引情報の２台の装置ＩＤと、異常が発生した旨とを表示する。さらに、ステップＳ８４４で、店舗サーバ８００のデータ処理部は、受信した取引情報およびステップＳ８３２で抽出した取引情報の２台の装置ＩＤに対応する座席を遊技場内３０のカメラで撮影するための制御信号を、遊技場内３０のカメラの制御装置に出力する。ステップＳ８４４の後、店舗サーバ８００のデータ処理部は、実行する処理をこの店舗履歴判定処理の呼出元の店舗サーバ処理に戻す。

図５２に進んで、たとえば、店舗ＩＤ「００００１」の遊技場３０Ａのカードユニット６００Ａ，６００Ｂ，６００Ｌの装置ＩＤが、それぞれ「０００１」，「０００２」，「００３９」であることとする。

図６に戻って、ステップＳ８１１で受信した取引情報が携帯端末情報「ＭＮ７ＲＥ」、利用日「２００６年１１月２２日」、利用時刻「１２：０５：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００２」および取引金額「５００」円の取引情報である場合、ステップＳ８３２で、受信した取引情報と同じ携帯端末情報「ＭＮ７ＲＥ」で１つ前の利用時刻の利用履歴である利用日「２００６年１１月２２日」、利用時刻「１２：００：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００１」および取引金額「５００」円の利用履歴が抽出される。

ステップＳ８３３では、受信した取引情報および抽出した利用履歴の装置ＩＤがそれぞれ「０００２」および「０００１」であり一致しないと判断され、ステップＳ８３５では、それぞれの利用時刻が「１２：０５：００」および「１２：００：００」であるので、利用時刻が１分３０秒以内でないと判断され、ステップＳ８４１では、受信した取引情報と同じ携帯端末情報「ＭＮ７ＲＥ」および装置ＩＤ「０００２」の利用履歴である携帯端末情報「ＭＮ７ＲＥ」、利用日「２００６年１１月２２日」、利用時刻「１２：１５：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００２」および取引金額「５００」円の利用履歴があるが、それぞれの利用時刻の差が１０分であり、所定時間である８分内でないので、何も行なわれず、店舗履歴判定処理が終了する。

図５３は、本実施の形態における店舗サーバ８００の店舗内取引情報データベースの利用履歴が異常である場合を説明するための第１の図である。図５３を参照して、ステップＳ８１１で受信した取引情報が携帯端末情報「ＫＬ５ＰＣ」、利用日「２００６年１１月２４日」、利用時刻「１２：０１：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００１」および取引金額「５００」円の取引情報である場合、ステップＳ８３２で、受信した取引情報と同じ携帯端末情報「ＫＬ５ＰＣ」で１つ前の利用時刻の利用履歴である利用日「２００６年１１月２４日」、利用時刻「１２：００：００」、店舗ＩＤ「００００１」、装置ＩＤ「００３９」および取引金額「５００」円の利用履歴が抽出される。

ステップＳ８３３では、受信した取引情報および抽出した利用履歴の装置ＩＤがそれぞれ「０００１」および「００３９」であり一致しないと判断され、ステップＳ８３５では、それぞれの利用時刻が「１２：０１：００」および「１２：００：００」であるので、利用時刻が１分３０秒以内であると判断され、ステップＳ８３５では、受信した取引情報および抽出した利用履歴の装置ＩＤに対応する座席がそれぞれ座席７００Ａおよび座席７００Ｌであり、座席が隣接しないと判断されるので、利用履歴は異常であり、ステップＳ８４３での異常発生の報知およびステップＳ８４４での２つの座席を撮影するための制御信号の出力が行なわれる。

また、ステップＳ８１１で受信した取引情報が携帯端末情報「ＫＬ５ＰＣ」、利用日「２００６年１１月２４日」、利用時刻「１２：０１：３０」、店舗ＩＤ「００００１」、装置ＩＤ「０００２」および取引金額「５００」円の取引情報である場合、ステップＳ８３２で、受信した取引情報と同じ携帯端末情報「ＫＬ５ＰＣ」で１つ前の利用時刻の利用履歴である利用日「２００６年１１月２４日」、利用時刻「１２：０１：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００１」および取引金額「５００」円の利用履歴が抽出される。

ステップＳ８３３では、受信した取引情報および抽出した利用履歴の装置ＩＤがそれぞれ「０００２」および「０００１」であり一致しないと判断され、ステップＳ８３５では、それぞれの利用時刻が「１２：０１：３０」および「１２：０１：００」であるので、利用時刻が１分３０秒以内であると判断され、ステップＳ８３５では、受信した取引情報および抽出した利用履歴の装置ＩＤに対応する座席がそれぞれ座席７００Ｂおよび座席７００Ａであり、座席が隣接すると判断されるので、利用履歴は異常であるとは断定できず、ステップＳ８３６での携帯電話１００が共用可能配置である旨の報知が行なわれる。

図５４は、本実施の形態における店舗サーバ８００の店舗内取引情報データベースの利用履歴が異常である場合を説明するための第２の図である。図５４を参照して、ステップＳ８１１で受信した取引情報が携帯端末情報「ＪＫ４ＯＢ」、利用日「２００６年１１月２５日」、利用時刻「１２：０２：００」、店舗ＩＤ「００００１」、装置ＩＤ「００３９」および取引金額「５００」円の取引情報である場合、ステップＳ８３２で、受信した取引情報と同じ携帯端末情報「ＪＫ４ＯＢ」で１つ前の利用時刻の利用履歴である利用日「２００６年１１月２５日」、利用時刻「１２：００：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００１」および取引金額「５００」円の利用履歴が抽出される。

ステップＳ８３３では、受信した取引情報および抽出した利用履歴の装置ＩＤがそれぞれ「００３９」および「０００１」であり一致しないと判断され、ステップＳ８３５では、それぞれの利用時刻が「１２：０２：００」および「１２：００：００」であるので、利用時刻が１分３０秒以内でないと判断され、ステップＳ８４１では、受信した取引情報と同じ携帯端末情報「ＪＫ４ＯＢ」および装置ＩＤ「００３９」の利用履歴である携帯端末情報「ＪＫ４ＯＢ」、利用日「２００６年１１月２５日」、利用時刻「１２：０６：００」、店舗ＩＤ「００００１」、装置ＩＤ「００３９」および取引金額「５００」円の利用履歴があるが、それぞれの利用時刻の差が４分であり、所定時間である８分内であると判断され、ステップＳ８４２では、受信した取引情報と同じ携帯端末情報「ＪＫ４ＯＢ」で「００３９」と異なる装置ＩＤの利用履歴の組である、携帯端末情報「ＪＫ４ＯＢ」、利用日「２００６年１１月２５日」、利用時刻「１２：００：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００１」および取引金額「５００」円の利用履歴、ならびに、携帯端末情報「ＪＫ４ＯＢ」、利用日「２００６年１１月２５日」、利用時刻「１２：０４：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００１」および取引金額「５００」円の利用履歴が、受信した取引情報の利用時刻「１２：０２：００」から所定時間である８分内にあるので、利用履歴は異常であり、ステップＳ８４３での異常発生の報知およびステップＳ８４４での２つの座席を撮影するための制御信号の出力が行なわれる。

図５０に戻って、ステップＳ８１２の後、または、取引情報を受信していないと判断した場合（ステップＳ８１１でＮＯの場合）、店舗サーバ８００のデータ処理部は、ステップＳ８１３で、電子マネー管理サーバ２００へ取引情報を前回送信してから所定時間経過したか否かを判断する。本実施の形態では、所定時間は、３時間である。

取引情報の前回送信から所定時間経過したと判断した場合（ステップＳ８１３でＹＥＳの場合）、店舗サーバ８００のデータ処理部は、ステップＳ８１４で、記憶部に記憶された前回送信後の携帯電話１００での取引情報を電子マネー管理サーバ２００に送信する。この取引情報には、少なくとも、携帯端末情報ごとの取引額、取引日、取引時刻、取引に用いられた装置ＩＤ、および、当該店舗を識別するための店舗ＩＤが含まれる。

ステップＳ８１４の後、または、取引情報の前回送信から所定時間経過していないと判断した場合（ステップＳ８１３でＮＯの場合）、店舗サーバ８００のデータ処理部は、ステップＳ８２１で、携帯使用禁止情報を電子マネー管理サーバ２００から受信したか否かを判断する。

携帯使用禁止情報を受信したと判断した場合（ステップＳ８２１でＹＥＳの場合）、店舗サーバ８００のデータ処理部は、ステップＳ８２２で、携帯使用禁止情報を遊技場３０内のすべての券売機３００およびカードユニット６００に送信する。

ステップＳ８２２の後、または、携帯使用禁止情報を受信していないと判断した場合（ステップＳ８２１でＮＯの場合）、店舗サーバ８００のデータ処理部は、ステップＳ８２３で、不正端末情報を電子マネー管理サーバ２００から受信したか否かを判断する。

不正端末情報を受信したと判断した場合（ステップＳ８２３でＹＥＳの場合）、店舗サーバ８００のデータ処理部は、ステップＳ８２４で、不正端末情報を遊技場３０内のすべての券売機３００およびカードユニット６００に送信する。

ステップＳ８２４の後、または、不正端末情報を受信していないと判断した場合（ステップＳ８２３でＮＯの場合）、店舗サーバ８００のデータ処理部は、ステップＳ８２５で、不正媒体情報を電子マネー管理サーバ２００から受信したか否かを判断する。

不正媒体情報を受信したと判断した場合（ステップＳ８２５でＹＥＳの場合）、店舗サーバ８００のデータ処理部は、ステップＳ８２６で、不正媒体情報に含まれる携帯ＩＤに対応して記憶部に記憶しているカードＩＤを、遊技場３０内のすべてのカードユニット６００に送信する。

ステップＳ８２６の後、または、不正媒体情報を受信していないと判断した場合（ステップＳ８２５でＮＯの場合）、ステップＳ８２７で、店舗サーバ８００のデータ処理部は、電子マネー管理サーバ２００から利用停止情報を受信したか否かを判断する。

利用停止情報を受信したと判断した場合（ステップＳ８２７でＹＥＳの場合）、ステップＳ８２８で、店舗サーバ８００のデータ処理部は、受信した利用停止情報を遊技場３０内のすべての券売機３００およびカードユニット６００に送信する。

ステップＳ８２８の後、または、利用停止情報を受信していないと判断した場合（ステップＳ８２７でＮＯの場合）、店舗サーバ８００のデータ処理部は、実行する処理をステップＳ８１１に戻す。

（電子マネーシステム１０でのエラー対応の説明）
図１８のステップＳ１５６で説明したように、バリューの書込処理が終了すると、リモート発行サーバ４００におけるバリューの処理状況（書込状況）は書込終了済とされる。また、ステップＳ１５７ａで説明したように、携帯電話１００におけるバリューの処理状況は書込済に更新される。しかし、携帯電話１００において、ステップＳ１５７ａで処理状況の更新に失敗すると、携帯電話１００の処理状況は発行情報受信済のまま、つまり、書込済でない一方、リモート発行サーバ４００の処理状況は書込終了済となる。このように、両者の処理状況に不一致が生じてしまい、その後の処理に不都合が発生する。

たとえば、本実施の形態の場合、携帯電話１００において、不一致のまま電子マネーアプリ１１１が起動されると、ステップＳ１９８の処理状況確認処理のステップＳ１９８２で処理状況が発行情報受信済であると判断され、図１８のステップＳ１５４へ処理が進められ、バリューの購入番号を含むリモート発行サーバへ書込処理開始要求が送信される。しかし、リモート発行サーバ４００では、携帯電話１００から送信されてきた書込処理開始要求に含まれる購入番号のバリューはすでに書込終了済として管理されているので、この書込処理開始要求は受付けられない。

したがって、携帯電話１００からは書込処理開始要求が電子マネーアプリ１１１を起動するごとに繰返し送信され続けられるが、リモート発行サーバ４００では受付けられないため、携帯電話１００で他の処理が実行できなくなってしまうといった問題が発生する。また、携帯電話１００の記憶部１２０にて管理されている処理状況が書込済であることを条件として、次のチャージ要求を電子マネー管理サーバ２００に送信可能となるような場合には、処理状況の書込済への更新に失敗すると、以降、一切チャージが不可能となるという問題が生じる。

このような処理状況の不一致のエラーが発生した場合、ユーザは、電話や電子メール等で、電子マネー遊技使用サービスの提供業者のオペレータに対して、上述したようなエラーが発生している旨を連絡する。

本実施の形態における電子マネー遊技使用サービスの提供業者のオペレータは、電話や電子メール等で、ユーザからのエラー問合せを受信した場合、ユーザに携帯電話１００の電子メールのアドレスを問合せ、ユーザの携帯電話１００の電子メールアドレスを取得する。

次に、オペレータは、取得したユーザの携帯電話１００の電子メールアドレス宛に、エラー対応開始メールを送信する。エラー対応開始メールには、エラーについて説明するエラー説明ページのＵＲＬが添付される。

エラー対応開始メールに含まれるエラー説明ページへのリンクが操作されると、データ処理部１１０は、エラー説明ページへのリンク先のＵＲＬのエラー説明画面を取得し、表示部１４０に表示する。エラー説明画面には、エラーについての説明が記載されるとともに、電子マネーアプリ１１１を起動させるために操作されるリンク情報が含まれており、当該リンク情報が選択操作されることにより、データ処理部１１０は、電子マネーアプリ１１１を起動させる。

図１１に戻って、ステップＳ１１００で、データ処理部１１０は、エラー説明画面からの電子マネーアプリ１１１の起動であると判断し、ステップＳ１１０１で、データ処理部１１０は、非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域のバリュー残高などの記憶内容を取得して、該取得した記憶内容と、記憶部１２０で管理されている処理状況とを電子マネー管理サーバ２００に送信する。その後、データ処理部１１０は、電子マネーアプリ１１１を終了する。

携帯電話１００から記憶部１９２の記憶内容および処理状況を受信した電子マネー管理サーバ２００は、受信した情報を表示部２４０に表示する。つまり、電子マネー管理サーバ２００は、携帯電話１００から取得した処理状況等に基づいた処理として、取得した処理状況等を表示部２４０に表示する処理を行なう。表示内容を確認したオペレータは、リモート発行サーバ４００の管理者にリモート発行サーバ４００における当該携帯電話１００のバリューに関する処理状況（書込状況）を問合せる。

そして、たとえば、携帯電話１００から取得した処理状況が発行情報受信済であり、リモート発行サーバ４００の管理者からの回答が書込終了済であった場合、オペレータは携帯電話１００において処理状況の更新失敗が生じたことを認識する。また、より慎重を期す場合には、取得したバリュー残高と電子マネー管理サーバ２００において管理しているバリュー残高が一致するか否かをさらに確認してもよい。そして、両バリュー残高が一致すれば、携帯電話１００においてバリューの書込みが行なわれていたことを確認できる。

かかる確認後、オペレータの操作に基づいて電子マネー管理サーバ２００は、電子マネーアプリ１１１を起動し処理状況をクリアするために操作されるリンク情報が添付された電子メールを携帯電話１００に送信する。

このように、本実施の形態においては、携帯電話１００の記憶部１２０に記憶された処理状況を更新するための更新指示情報として、上記のようなリンク情報が添付された電子メールが送信される例を示したが、これに限定されるものではなく、電子マネー管理サーバ２００が、携帯電話１００のデータ処理部１１０に対して処理状況の更新を指示する更新指示情報を送信し、ユーザによるリンク操作等を介することなく、更新指示情報の受信に基づいて処理状況の更新が行なわれるようにしてもよい。

そして、かかる電子メールを受信した携帯電話１００において、当該電子メールに添付されたリンク情報が選択操作されると、電子マネーアプリ１１１が起動され、図１１に示す処理のステップＳ１１１０においてＹＥＳの判断がなされる。

ステップＳ１１１０においてＹＥＳの判断がなされると、ステップＳ１１１１で、データ処理部１１０は、このエラー対応完了メールのリンク情報の操作による電子マネーアプリ１１１の起動が初回であるか否かを判断する。具体的には、エラー対応完了メールのリンク情報が操作されたか否かを示す操作フラグの状態がオン状態であるかオフ状態であるかを判断することによって、初回であるか否かを判断する。

操作フラグがオン状態である、つまり、このエラー対応完了メールからの起動が初回でないと判断した場合（ステップＳ１１１１においてＮＯの場合）、データ処理部１１０は、電子マネーアプリ１１１を終了する。一方、操作フラグがオフ状態である、つまり、このエラー対応完了メールからの起動が初回であると判断した場合（ステップＳ１１１１においてＹＥＳの場合）、ステップＳ１１１２で、データ処理部１１０は、操作フラグをオン状態にする。

次に、ステップＳ１１１３で、データ処理部１１０は、記憶部１２０で管理されている処理状況をクリアする。なお、処理状況がクリアされることに限定されず、処理状況が書込済に更新されるものであってもよい。これにより、前述したような、携帯電話１００から書込処理開始要求が送信され続けられるといった問題は解消する。

このように、データ処理部１１０は、本実施の形態における更新指示情報である前記電子メールを受信し、当該電子メールに添付されたリンク情報が操作されたことを条件として、さらには当該リンク情報の操作が初回であることを条件として、記憶部１２０にて管理している処理状況を強制的に更新する処理状況強制更新処理を実行する。また、図１１に示して説明した通り、この処理状況強制更新処理（ステップＳ１１１３）は、更新指示情報としての電子メールに添付されたリンク情報が操作されたことを条件として実施され、電子マネーアプリ１１１の初期画面等からは実行できないため、ユーザの過誤等により処理状況の更新が実施されるおそれがない。さらに、この処理状況強制更新処理は、リンク操作が初回であることを条件として実行されるため、携帯電話１００に保存されている電子メールのリンク情報をユーザの過誤等により複数回操作された場合にも、２回目以降の操作時には処理状況が更新されてしまうおそれがない。

（店舗履歴判定処理の第１の変形例）
図５５は、本実施の形態における電子マネー管理サーバ２００により実行される残高管理アプリケーションプログラム２１４のサブルーチンである履歴判定処理の第１の変形例の流れを示すフローチャートである。

図４６の履歴判定処理においては、２つの利用履歴から、後に利用された店舗への推定到着時刻を特定し、特定された推定到着時刻と、後に利用された店舗における利用時刻とを比較するようにした。図５５の第１の変形例の履歴判定処理においては、２つの利用履歴から、店舗間の推定移動時間を特定し、特定された推定移動時間と、２つの店舗の利用時刻の差とを比較するようにする。

図５５を参照して、ステップＳ２１８１ａからステップＳ２１８３ａまでの処理以外の処理は、図４６で説明した処理と同様であるので重複する説明は繰返さない。

ステップＳ２０８６でＮＯの場合、ステップＳ２１８１ａで、店舗ＤＢから２つの利用履歴の店舗ＩＤで示される店舗の所在地を特定する。続いて、データ処理部２１０は、特定された２つの利用履歴の店舗ＩＤで示される店舗の所在地から、先に利用された店舗の所在地から後に利用された店舗の所在地までの推定移動時間を特定する。所在地間の推定移動時間を特定する方法は、図４６のステップＳ２１８１で説明したので重複する説明は繰返さない。

そして、ステップＳ２１８２ａで、データ処理部２１０は、後に利用された店舗の利用履歴の利用時刻と、先に利用された店舗の利用履歴の利用時刻との利用時刻差を算出する。

次に、ステップＳ２１８３ａで、データ処理部２１０は、ステップＳ２１８２ａで算出された利用時刻差が、ステップＳ２１８１ａで特定された推定移動時間より短いか否かを判断する。利用時刻差が推定移動時間より短くないと判断した場合（ステップＳ２１８３ａでＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２１８６に進める。

一方、利用時刻差が推定移動時間より短いと判断した場合（ステップＳ２１８３ａでＹＥＳの場合）、データ処理部２１０は、実行する処理をステップＳ２１８４の処理に進める。

図６に戻って、たとえば、ステップＳ２０８１またはステップＳ２１８９で、携帯端末情報「ＭＮ７ＲＥ」の利用履歴群が対象利用履歴群とされた場合について説明する。そして、今回更新された利用履歴が「２００６年１１月２２日」の「１０：３０：００」から「１２：１５：００」までの４つの利用履歴である場合、ｎ＝２のとき、ステップＳ２０８３で、対象利用履歴群のうち今回更新されたｎ＝２番目の利用履歴である利用日「２００６年１１月２２日」、利用時刻「１２：００：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００１」、および、取引金額「５００」が取引情報ＤＢ２２４から抽出される。ステップＳ２０８４では、ステップＳ２０８３で抽出された利用履歴の１つ前の利用時刻の利用履歴である利用日「２００６年１１月２２日」、利用時刻「１０：３０：００」、店舗ＩＤ「００００２」、装置ＩＤ「０００１」、および、取引金額「５００」が取引情報ＤＢ２２４から抽出される。

ステップＳ２０８５では、２つの利用履歴の利用日が「２００６年１１月２２日」であり一致すると判断され、ステップＳ２０８６では、２つの利用履歴の店舗ＩＤがそれぞれ「００００１」「００００２」であるので一致しないと判断される。そして、ステップＳ２１８１ａで、先に利用された店舗および後に利用された店舗の住所がそれぞれ「東京都新宿区乙２丁目３−４」および「東京都渋谷区甲１丁目２−３」であり、最寄駅がそれぞれ「新宿駅」および「渋谷駅」であることが特定され、先に利用された店舗と後に利用された店舗との所在地間の推定移動時間が、たとえば「２０分」と特定される。次いで、ステップＳ２１８２ａで、後に利用された店舗と先に利用された店舗との利用履歴の利用時刻差が、「１２：００：００」から「１０：３０：００」を引いて、「１時間３０分」と算出される。この場合は、ステップＳ２１８３ａで、算出された利用時刻差「１時間３０分」が推定移動時間「２０分」より短くないと判断されるので、利用履歴は異常ではなく、ステップＳ２１８４での異常発生の報知およびステップＳ２１８５での利用停止情報の送信は行なわれない。

図４９に進んで、たとえば、ステップＳ２０８１またはステップＳ２１８９で、携帯端末情報「ＬＭ６ＱＤ」の利用履歴群が対象利用履歴群とされた場合について説明する。そして、今回更新された利用履歴が「２００６年１１月２３日」の「１０：３０：００」から「１２：１５：００」までの４つの利用履歴である場合、ｎ＝２のとき、ステップＳ２０８３で、対象利用履歴群のうち今回更新されたｎ＝２番目の利用履歴である利用日「２００６年１１月２３日」、利用時刻「１２：００：００」、店舗ＩＤ「００００１」、装置ＩＤ「０００１」、および、取引金額「５００」が取引情報ＤＢ２２４から抽出される。ステップＳ２０８４では、ステップＳ２０８３で抽出された利用履歴の１つ前の利用時刻の利用履歴である利用日「２００６年１１月２３日」、利用時刻「１０：３０：００」、店舗ＩＤ「００００３」、装置ＩＤ「０００１」、および、取引金額「５００」が取引情報ＤＢ２２４から抽出される。

ステップＳ２０８５で、２つの利用履歴の利用日が「２００６年１１月２３日」であり一致すると判断され、ステップＳ２０８６で、２つの利用履歴の店舗ＩＤがそれぞれ「００００１」「００００３」であるので一致しないと判断される。そして、ステップＳ２１８１ａで、先に利用された店舗および後に利用された店舗の住所がそれぞれ「大阪府大阪市北区丙３丁目４−５」および「東京都渋谷区甲１丁目２−３」であり、最寄駅がそれぞれ「大阪駅」および「渋谷駅」であることが特定され、先に利用された店舗と後に利用された店舗との所在地間の推定移動時間が、たとえば「３時間３０分」と特定される。次いで、ステップＳ２１８２ａで、後に利用された店舗と先に利用された店舗との利用履歴の利用時刻差が、「１２：００：００」から「１０：３０：００」を引いて、「１時間３０分」と算出される。この場合は、ステップＳ２１８３ａで、算出された利用時刻差「１時間３０分」が推定移動時間「３時間３０分」より短いと判断されるので、利用履歴は異常であり、ステップＳ２１８４での異常発生の報知およびステップＳ２１８５での利用停止情報の送信が行なわれる。

（店舗履歴判定処理の第２の変形例）
図５６は、本実施の形態における電子マネー管理サーバ２００により実行される残高管理アプリケーションプログラム２１４のサブルーチンである履歴判定処理の第２の変形例の流れを示すフローチャートである。

図４６の履歴判定処理においては、利用履歴ごとに１つ前の利用履歴と比較して、利用履歴が異常であるか否かを判定するようにした。図５６の第２の変形例の履歴判定処理においては、携帯端末情報および店舗ＩＤが同じで利用時刻が連続する利用履歴を利用履歴群として、当該利用履歴群の最初の利用履歴と、当該利用履歴群の前で利用日が一致する利用履歴群の最後の利用履歴とを比較して、利用履歴が異常であるか否かを判定するようにする。

図５６を参照して、ステップＳ２０８３ａからステップＳ２１８６ａまでの処理以外の処理は、図４６で説明した処理と同様であるので重複する説明は繰返さない。

ステップＳ２０８３ａで、データ処理部２１０は、対象利用履歴群のうち、店舗ＩＤが同じで利用時刻が連続する利用履歴を一纏まりの利用履歴群として、今回更新された利用履歴群のうちｎ番目の利用履歴群を取引情報ＤＢ２２４から抽出する。さらに、ステップＳ２０８４ａで、データ処理部２１０は、ステップＳ２０８３ａで抽出した利用履歴群の前の利用履歴群であって、利用日が一致するすべての店舗での利用履歴群を取引情報ＤＢ２２４から抽出する。

次いで、ステップＳ２１８１ｂで、データ処理部２１０は、ｎ番目の店舗での利用履歴群と、ステップＳ２０８４ａで抽出した利用履歴群のうち当該利用履歴群と店舗ＩＤが不一致の利用履歴群とのすべての組合せについて、先に利用された店舗の所在地から後に利用された店舗の所在地までの推定移動時間を特定する。所在地に基づいて推定移動時間を特定する方法については、図４６のステップＳ２１８１で説明したので重複する説明は繰返さない。

そして、ステップＳ２１８２ｂで、データ処理部２１０は、ステップＳ２１８１ｂで対象としたすべての利用履歴群の組合せについて、ステップＳ２１８１ｂで特定した推定移動時間を、先に利用された店舗の利用履歴群の最終の利用履歴の利用時刻に加算することによって、後に利用された店舗への推定到着時刻を算出する。

次に、ステップＳ２１８３ｂで、データ処理部２１０は、ステップＳ２１８１ｂで対象としたすべての利用履歴群の組合せのうち、後に利用された店舗の利用履歴群の最初の利用履歴の利用時刻が、ステップＳ２１８２ｂで算出した推定到着時刻の前である利用履歴群の組合せがあるか否かを判断する。後の利用時刻が推定到着時刻の前である利用履歴群の組合せがないと判断した場合（ステップＳ２１８３ｂでＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２１８６ａに進める。

一方、後の利用時刻が推定到着時刻の前である利用履歴群の組合せがあると判断した場合（ステップＳ２１８３ｂでＹＥＳの場合）、ステップＳ２１８４ｂで、データ処理部２１０は、ステップＳ２１８３ｂで該当した組合せの携帯端末情報と、利用履歴群の組合せそれぞれの２つの店舗ＩＤと、異常が発生した旨とを報知する。この報知としては、たとえば、データ処理部２１０は、表示部２４０に、携帯端末情報、２つの店舗ＩＤおよび「異常発生」の文字を表示させる。

さらに、ステップＳ２１８５で、データ処理部２１０は、当該携帯端末情報で示される携帯電話１００でのバリューの利用を停止させることを指示するための利用停止情報を、すべての店舗の店舗サーバ８００に送信する。利用停止情報は、図３９のステップＳ３１５で説明したように、携帯端末情報を含む。

ステップＳ２１８６ａでは、データ処理部２１０は、対象利用履歴群に次の店舗の利用履歴群があるか否かを判断する。次の店舗の利用履歴群があると判断した場合（ステップＳ２１８６ａでＹＥＳの場合）、ステップＳ２１８７で、データ処理部２１０は、変数ｎに１を加算して、実行する処理をステップＳ２０８３ａに戻す。

一方、次の店舗の利用履歴群がないと判断した場合（ステップＳ２１８６ａでＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２１８８に進める。

次に、前述した第１の実施の形態により得られる主な効果を説明する。
（１−１） 従来、電子マネーで遊技に使用する遊技用記録媒体の発行や遊技用記録媒体に追加入金をするものがあった（たとえば、特開２００２−２２４４２３号公報（たとえば、第００３５段落））。この電子マネーは、利用者の取引金融機関からチャージすることができる。そして、ユーザは、チャージされた電子マネーを用いて遊技用記録媒体を購入したり、遊技用記録媒体に追加入金したりする。しかし、このような技術によれば、電子マネーのチャージは、遊技場内の所定の入金機に接続して行なう必要がある。このため、電子マネーのチャージのために、わざわざ、入金機に出向く手間が必要であった。また、入金機の台数が少ない場合は、電子マネーをチャージするためにユーザが並んで待つ状態が発生し、遊技に費やす時間が少なくなる。このため、入金機の台数を増やすことが考えられるが、設備投資費用が発生したり、入金機を設置するスペースにも限界がある。いずれにせよ、遊技者が遊技場にいる時間のうちの遊技に費やす時間をチャージに費やす必要が生じるため、遊技機の稼動に悪影響を与えるといった問題があった。

しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段と、ユーザが前記電子マネー情報のチャージに関する対価の決済に利用する金融機関を特定するための金融機関情報を前記サービス提供用サーバに送信するために出力する携帯端末側金融機関情報出力手段とを備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段と、前記携帯端末側金融機関情報出力手段から送信されてきた前記金融機関情報を受信したことを条件として、当該金融機関情報を、当該金融機関情報送信元の携帯端末を他の携帯端末と識別可能にするための識別情報と対応付けて記憶するサーバ側金融機関情報記憶手段とを備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したことを条件として、前記サーバ側金融機関情報記憶手段に記憶された金融機関情報から、当該チャージ要求情報送信元の携帯端末である要求元携帯端末を識別するための識別情報に対応付けて記憶された金融機関情報を検索する金融機関情報検索手段と、該金融機関情報検索手段により検索された金融機関情報から特定される金融機関のサーバを前記決済を行なうための通信先として指定する通信先指定情報を、前記要求元携帯端末に送信するために出力する通信先指定情報出力手段とを備え、前記携帯端末は、さらに、前記通信先指定情報出力手段から送信されてきた前記通信先指定情報により指定される金融機関のサーバに対し、前記決済を要求する決済要求情報を送信するために出力する決済要求情報出力手段を備え、前記サービス提供用サーバは、さらに、前記金融機関のサーバにおける前記決済の終了を条件として、前記電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備える。このように構成しているため、バリューチャージ時の手間を低減させることが可能である。

具体的には、図１５のバリュー購入時処理に従って、ステップＳ１３３においてチャージ要求情報が携帯電話１００から電子マネー管理サーバ２００に送信されることにより、図１６のバリュー購入時ＡＰに従って、ステップＳ２６８において引継画面情報が電子マネー管理サーバ２００から携帯電話１００に送信される。引継画面情報を受信した携帯電話１００からは、図１０のウェブ処理に従って、ステップＳ１１８ａにおいてバリューの購入に対する決済に関する情報が金融機関サーバ５００に送信され、当該金融機関において決済が行なわれ、その後図１８のバリュー発行時処理に従って、未チャージバリューが記憶部１９２に書込まれる。これにより、携帯電話１００から、チャージ要求情報を電子マネー管理サーバ２００に送信することにより、いつでもどこでも事前にバリューをチャージあるいは遊技中であっても席を離れることなくバリューをチャージすることができるため、遊技場３０に設置されているパチンコ遊技機７００等の稼動に与える悪影響を減少させることができる。

（１−２） また、従来の技術においては、携帯電話１００から電子マネー管理サーバ２００にアクセスしてバリューを購入できるようにし、対価の決済についてはユーザの指定した金融機関サーバにアクセスすることによりモバイルバンキングサービスを利用する場合であっても、バリューを購入しようとするたびに入金に利用する金融機関を指定する必要があり、手間がかかる不都合が生じる。

しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージに関する対価の決済に利用する金融機関の指定をユーザから受付けるための処理を実行する金融機関指定処理手段と、該金融機関指定処理手段により指定を受付けた金融機関を特定するための金融機関情報を記憶する携帯端末側金融機関情報記憶手段と、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段と、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記チャージ要求情報出力手段が前記チャージ要求情報を出力したことを条件として、前記携帯端末側金融機関情報記憶手段に記憶されている前記金融機関情報から特定される金融機関のサーバに、前記決済を要求する決済要求情報を送信するために出力する決済要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記金融機関のサーバにおける前記決済の終了を条件として、前記電子マネー情報を、前記チャージ要求情報出力手段から送信されてきたチャージ要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備える。このように構成しているため、バリューチャージ時の手間を低減させることが可能である。

具体的には、図９の初期登録時ＡＰに従って、ステップＳ２１９〜Ｓ２２４においてユーザに金融機関を選択させ、利用者情報ＤＢ２２１に登録する。そして、電子マネー管理サーバ２００は、携帯電話１００からのチャージ要求情報を受信することにより、図１６のバリュー購入時ＡＰ２１２に従って、ステップＳ２４６において当該携帯電話１００に対応付けて登録している金融機関を検索し、ステップＳ２６８において検索された金融機関の金融機関サーバ５００のインターネットバンキングシステムにアクセス可能となる通信先指定情報を含む引継画面情報を当該携帯電話１００に送信する。そして、携帯電話１００は、図１０のウェブ処理に従って、ステップＳ１１８ａにおいて当該引継画面情報に基づき、指定される金融機関のサーバにバリューの購入に対する決済に関する情報を送信し決済を行なうことができる。このため、チャージを要求する度に、決済に利用する金融機関を指定する必要がないため、バリューのチャージ時の手間を低減させることができる。

（１−３） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記情報端末は、さらに、前記決済に利用する金融機関の変更をユーザから受付けるための処理を実行する金融機関変更受付手段と、該金融機関変更受付手段により受付けた金融機関を前記決済に利用する金融機関にする変更を要求するための金融機関変更要求情報を、前記サーバに送信するために出力する金融機関変更要求情報出力手段とを備え、前記サーバは、さらに、前記金融機関変更要求情報出力手段から送信されてきた前記金融機関変更要求情報を受信したことを条件として、前記サーバ側金融機関情報記憶手段において、金融機関変更要求情報送信元の情報端末の識別情報と対応付けて記憶されている金融機関情報を当該金融機関変更要求情報に従って変更される金融機関を特定するための金融機関情報に更新するサーバ側金融機関更新手段を備える。具体的には、図１５のバリュー購入時処理に従って、ステップＳ１４０ａにおいて金融機関変更が選択されたと判断した場合、金融機関変更問合せ情報が携帯電話１００から電子マネー管理サーバ２００に送信される。一方、電子マネー管理サーバ２００は、金融機関変更問合せ情報に対応する画面（図２７（ｃ），（ｄ），図２８（ａ）等参照）を携帯電話１００に送信し、携帯電話１００から金融機関指定情報を受信したと判断した場合、変更した金融機関の金融機関指定情報を携帯端末情報に対応させて、利用者情報ＤＢ２２１に登録する処理を行なう。これにより、決済に利用する金融機関を変更することができるため、ユーザの利便性を向上させることができる。

（１−４） （１−１）で説明した課題を解消するために、たとえば、携帯電話１００から電子マネー管理サーバ２００にアクセスしてバリューを購入できるようにし、対価の決済についてはユーザの指定した金融機関サーバ５００にアクセスすることによりモバイルバンキングサービスを利用してバリュー購入金額を決済することが考えられる。しかし、実際にバリュー購入の際には、金融機関サーバ５００と接続するため携帯電話１００と電子マネー管理サーバ２００との接続が分断されるため、電子マネー管理サーバ２００との通信を維持して一連の動作によりバリューをチャージすることができない。すなわち、電子マネー管理サーバ２００との接続を一旦分断し、金融機関サーバ５００に接続しバリュー購入金額の決済を済ませ、その後再度電子マネー管理サーバ２００に接続し直し、バリューを携帯電話１００にチャージする作業が必須となる。このため、バリューをチャージするための操作が複雑になり、ユーザの操作負担が増大する不都合が生じる。

しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段と、前記電子マネー情報のチャージに関する対価の決済を要求する決済要求情報を金融機関のサーバに送信するために出力する決済要求情報出力手段と、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記決済の終了した電子マネー情報の送信を要求する電子マネー情報送信要求を前記サービス提供用サーバに送信するために出力する電子マネー情報送信要求出力手段とを備え、前記サービス提供用サーバは、さらに、前記金融機関のサーバにおける前記決済が終了し、かつ前記電子マネー情報送信要求出力手段から送信されてきた前記電子マネー情報送信要求を受信したことを条件として、前記電子マネー情報を、当該電子マネー情報送信要求元の携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記金融機関のサーバにおける前記決済の終了を条件として、前記電子マネー情報送信要求出力手段により前記電子マネー情報送信要求を出力するために操作するリンク情報が添付された電子メールを、前記チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力する電子メール出力手段を備える。このように構成しているため、ユーザの操作負担を低減させることが可能である。

具体的には、金融機関サーバ５００からの消込速報を電子マネー管理サーバ２００が受信すると、図１６のバリュー購入時ＡＰ２１２に従って、ステップＳ２７０においてバリュー対価決済後処理が行なわれ、図１７のステップＳ２７０９において引継ぎ情報を付したメールが携帯電話１００に送信される。そして、携帯電話１００において、電子マネー管理サーバ２００からのメールに付された引継ぎ情報が選択されると、図１１のステップＳ１９１でＹＥＳと判断されて、図１８のバリュー発行時処理に従って、未チャージバリューが記憶部１９２に書込まれる。このため、ユーザは、メールを受信したことによりバリューがチャージ可能になったことを認識することができる。また、バリューをチャージするための操作負担を軽減させることができる。

（１−５） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、前記リンク情報が操作されることを条件として、前記特定プログラム記憶手段に記憶された前記特定プログラムを起動させる操作時起動手段を備え、前記電子マネー情報送信要求出力手段は、前記操作時起動手段により起動された前記特定プログラムが示す処理手順に従って、前記電子マネー情報送信要求を前記サービス提供用サーバに送信するために出力する。具体的には、メールに付された引継ぎ情報を操作することにより、図１８のバリュー発行時処理が起動し、ステップＳ１５２においてバリュー発行要求情報が電子マネー管理サーバ２００に送信されるため、バリューをチャージするための操作負担をより一層軽減させることができる。

（１−６） （１−４）で説明した課題に加えて、さらに、バリューが購入されてチャージ可能となっているか否かを確認することができないといった不都合が生じていた。このため、ユーザの過誤等により、未チャージバリューが電子マネー管理サーバに存在するにもかかわらず、重複してチャージを要求しバリューを購入してしまう不都合が生じる。

しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したことを条件として、当該チャージ要求情報を受付けた旨を示すチャージ受付情報を当該チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力するチャージ受付情報出力手段を備え、前記携帯端末は、さらに、前記チャージ受付情報出力手段から送信されてきた前記チャージ受付情報を受信したことを条件として、前記電子マネー情報のチャージに関する対価の決済を要求する決済要求情報を金融機関のサーバに送信するために出力する決済要求情報出力手段と、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記決済の終了した電子マネー情報の送信を要求する電子マネー情報送信要求を前記サービス提供用サーバに送信するために出力する電子マネー情報送信要求出力手段とを備え、前記サービス提供用サーバは、さらに、前記金融機関のサーバにおける前記決済の終了を条件として、前記要求元携帯端末に対してチャージ可能となった電子マネー情報を特定するための特定用情報を登録する特定用情報登録手段と、前記電子マネー情報送信要求出力手段から送信されてきた前記電子マネー情報送信要求を受信したことを条件として、前記特定用情報登録手段により登録された特定用情報から特定される電子マネー情報を、当該電子マネー情報送信要求元の携帯端末に送信するために出力する電子マネー情報出力手段と、該電子マネー情報出力手段によって前記電子マネー情報送信要求元の携帯端末に対して前記電子マネー情報が送信されたことを条件として、当該電子マネー情報を特定するための特定用情報の前記特定用情報登録手段における登録状態を送信済状態に更新する送信済状態更新手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から前記チャージ要求情報が送信されてきたことを条件として、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記要求元携帯端末について前記特定用情報登録手段に登録されているか否かを判定する登録判定手段を備え、前記チャージ受付情報出力手段は、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記特定用情報登録手段に登録されていると前記登録判定手段により判定されたことを条件として、前記チャージ受付情報を出力しない。このように構成しているため、ユーザの過誤等により発生する不都合を防止することが可能である。

具体的には、電子マネー管理サーバ２００は、携帯電話１００からのチャージ要求情報を受信した場合であっても、図１６のバリュー購入時ＡＰに従って、ステップＳ２４４において図５の発行情報ＤＢ２２２の処理状況として「発行済」が記憶されている状態に更新されていないバリュー購入記録が登録されておりＹＥＳと判断された場合には、ステップＳ２５６における残高情報、ステップＳ２６４における合計金額確認情報、およびステップＳ２６８における引継画面情報が送信されないため、ステップＳ１１８ａにおいてバリューの購入に対する決済に関する情報が金融機関サーバ５００に送信されることを防止することができる。このため、図５の発行情報ＤＢ２２２の処理状況として「未発行」が記憶されている状態の未チャージバリューがあるにもかかわらず、ユーザの過誤等により、さらに決済の要求が行なわれ重複してバリューが購入される不都合の発生を防止することができる。

（１−７） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記サービス提供用サーバは、さらに、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記特定用情報登録手段に登録されていると前記登録判定手段により判定されたことを条件として、当該特定用情報から特定される電子マネー情報を、前記要求元携帯端末に送信するために出力するチャージ要求時電子マネー情報出力手段を備え、前記送信済状態更新手段は、前記チャージ要求時電子マネー情報出力手段によって前記要求元携帯端末に対して前記電子マネー情報が送信されたことを条件として、当該電子マネー情報を特定するための特定用情報の前記特定用情報登録手段における登録状態を送信済状態に更新する。具体的には、電子マネー管理サーバ２００は、ステップＳ２４４において図５の発行情報ＤＢ２２２の処理状況として「発行済」が記憶されている状態に更新されていないバリュー購入記録が登録されておりＹＥＳと判断された場合に、ステップＳ２４５においてチャージ誘導画面が携帯電話１００に送信された後に、図１９のバリュー発行時処理ＡＰ２１３に従って、ステップ２７６〜Ｓ２７７において図５の発行情報ＤＢ２２２の処理状況として「未発行」が記憶されている状態のバリュー購入記録から特定される額のバリューを書込ませるためのバリュー発行情報が携帯電話１００に送信される。このため、未チャージバリューをチャージするための操作を省略でき、ユーザの利便性を向上させることができる。

（１−８） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記電子マネー情報出力手段は、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記特定用情報登録手段に複数登録されていることを条件として、当該複数の特定用情報から特定される電子マネー情報を、前記電子マネー情報送信要求元の携帯端末に送信するために出力する。具体的には、電子マネー管理サーバ２００が、ステップＳ２６９において金融機関サーバ５００からの消込速報を受信するまでに、ステップＳ２４１において新たなチャージ要求情報を受付けた場合、図５の発行情報ＤＢ２２２において処理状況として「未発行」が記憶されている状態のバリュー購入記録が複数記憶されている状態になる。このような状態であるときに、ステップＳ２４１においてさらにチャージ要求情報を受付けたとき、およびステップＳ２７１においてバリュー発行要求情報を受付けたときに、ステップ２７６〜Ｓ２７７において発行情報ＤＢ２２２に複数記憶されている処理状況として「未発行」が記憶されている状態のバリュー購入記録から特定される額のバリューを書込ませるためのバリュー発行情報が携帯電話１００に送信される。すなわち、一括してバリューをチャージすることができ、ユーザの利便性を向上させることができる。

（１−９） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報の送信を要求する電子マネー情報送信要求を前記サービス提供用サーバに送信するために出力する電子マネー情報送信要求出力手段を備え、前記サービス提供用サーバは、さらに、前記チャージ許容判定手段によりチャージを許容すると判定されたことを条件として、前記要求元携帯端末に対してチャージ可能となった電子マネー情報を特定するための特定用情報を登録する特定用情報登録手段を備え、前記電子マネー情報出力手段は、前記電子マネー情報送信要求出力手段から送信されてきた前記電子マネー情報送信要求を受信したことを条件として、前記特定用情報登録手段により登録された特定用情報から特定される電子マネー情報を、当該電子マネー情報送信要求元の携帯端末に送信するために出力し、前記サービス提供用サーバは、さらに、該電子マネー情報出力手段によって前記電子マネー情報送信要求元の携帯端末に対して前記電子マネー情報が送信されたことを条件として、当該電子マネー情報を特定するための特定用情報の前記特定用情報登録手段における登録状態を送信済状態に更新する送信済状態更新手段と、前記預かり要求情報出力手段から前記預かり要求情報が送信されてきたことを条件として、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記要求元携帯端末について前記特定用情報登録手段に登録されているか否かを判定する登録判定手段とを備え、前記預かり残額登録手段は、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記特定用情報登録手段に登録されていないと前記登録判定手段により判定されたことを条件として、前記預かり処理を行なう。具体的には、ステップＳ２０６１で携帯電話１００からの残高移行依頼情報を受信したと判断した場合であっても、ステップＳ２０６４で未チャージバリューがあると判断した場合には、以降のバリュー預かり処理が行なわれないようにすることができる。このため、携帯電話１００に加算可能なバリューが電子マネー管理サーバ２００に存在するにもかかわらず、ユーザの過誤等により、携帯電話１００の機種変更が行なわれてしまうことを防止することができる。

また、電子マネー管理サーバ２００は、ステップＳ２０６１で携帯電話１００からの残高移行依頼情報を受信した場合であっても、ステップＳ２０６４で発行済に設定されていない未チャージバリューがあると判断した場合には、ステップＳ２０６５，Ｓ２７７で説明したように、未チャージバリューを残高移行依頼情報の送信元の携帯電話１００に出力することができる。このため、バリュー残高を電子マネー管理サーバ２００に預けるときに、未チャージバリューを加算するための操作を省略することができる。その結果、ユーザの利便性を向上させることができる。

（１−１０） ステップＳ２５９で説明した初期登録手数料を徴収するタイミングとしては、初期登録手数料の決済が済んでから、領域確保情報を携帯電話１００に送信することが考えられる。しかし、このようにした場合、少額の初期登録手数料のためにわざわざ金融機関サーバ５００に対して決済をしなければならず、手間が掛かるといった問題が生じる。また、この手間を省くために、初回のチャージ手数料とともに初期登録手数料を決済することが考えられる。しかし、一度もバリューがチャージされることなく、電子マネー遊技使用サービスを退会して、再度、電子マネー遊技使用サービスへ登録するようなことが悪意で繰返された場合、電子マネー遊技使用サービスを提供する提供機関は、サービス提供用領域管理機関に電子マネー遊技使用サービス用の記憶領域の確保に対する対価を支払うにもかかわらず、確保に対する初期登録手数料をユーザから決済できないといった問題が生じる。

しかし、本発明は次のような構成を含む。つまり、複数のサービス提供機関により使用が可能とされた記憶媒体を搭載する携帯端末と、前記記憶媒体に各サービス提供機関が提供するサービスに応じてサービス提供用領域の構築および削除のための処理を行なうとともに、該サービス提供用領域の構築に応じた対価を請求するために各サービス提供機関ごとに課金管理を行なうサービス提供用領域管理サーバを運営するサービス提供用領域管理機関に登録しているサービス提供機関であり、提供サービスとして電子マネーサービスを提供する電子マネーサービス提供機関に設けられるサービス提供用サーバと、前記記憶媒体に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段と、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネー情報を記憶するためのサービス提供用領域である電子マネーサービス提供用領域を前記携帯端末の前記記憶媒体に構築するための領域構築情報を当該携帯端末に送信するために出力する領域構築情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、前記領域構築情報出力手段から送信されてきた前記領域構築情報を受信したことを条件として、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記領域構築情報で示される電子マネーサービス提供用領域の構築要求を前記サービス提供用領域管理サーバに送信するために出力する構築要求出力手段と、該構築要求出力手段によって出力された構築要求に応じて前記サービス提供用領域管理サーバによって前記記憶媒体に前記電子マネーサービス提供用領域が構築されたことを条件として、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報に対応する前記電子マネー情報を当該チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネーサービス提供用領域に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネーサービス提供用領域に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から前記チャージ要求情報が送信されてきたのが、前記領域構築情報出力手段によって前記領域構築情報が当該要求元携帯端末に出力されてから初回であるか否かを判定する初回チャージ要求判定手段を備え、前記電子マネー情報出力手段は、前記初回チャージ要求判定手段によって初回でないと判定されたときは、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報に対応する前記電子マネー情報のチャージに関するチャージ対価の決済の終了を条件として、前記電子マネー情報を出力し、前記初回チャージ要求判定手段によって初回であると判定されたときは、前記チャージ対価と、前記領域構築情報出力手段によって出力された前記領域構築情報に対応する前記電子マネーサービス提供用領域の構築に関する領域構築対価との合計額の決済の終了を条件として、前記電子マネー情報を出力し、前記サービス提供用サーバは、さらに、前記領域構築情報出力手段によって出力された前記領域構築情報に対応する前記電子マネーサービス提供用領域の構築回数を少なくとも前記領域構築対価が未決済の携帯端末について管理する構築回数管理手段と、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したときに、前記構築回数管理手段によって管理されている前記登録要求情報送信元の前記携帯端末の前記構築回数が所定回数に達していることを条件として、前記領域構築情報出力手段による当該携帯端末への前記領域構築情報の出力を禁止する領域構築情報出力禁止手段とを備える。このように構成しているため、電子マネー遊技使用サービス用の記憶領域の確保に対する対価の決済のためのユーザの操作負担を軽減できる一方で、未決済の初期登録手数料を低減させることが可能である。

具体的には、電子マネー管理サーバ２００は、携帯電話１００からチャージ要求情報が送信されてきたのが、領域確保情報がチャージ要求情報の送信元の携帯電話１００に送信されてから初回であるときは、チャージ手数料と初期登録手数料との合計額の決済の終了を条件として、バリュー発行情報をチャージ要求情報の送信元の携帯電話１００に送信する。つまり、バリューの初回チャージのときに、チャージ手数料に併せて初期登録手数料が決済される。一方、電子マネー管理サーバ２００は、携帯電話１００からの登録要求に応じた未チャージ削除カウンタのカウント値が所定回数（本実施形態においては３回）に達していることを条件に領域確保情報の送信を禁止する。これにより、サービス用供用領域管理機関のリモート発行サーバ４００に電子マネー遊技使用サービス用の記憶領域の領域確保情報が送信されないので、リモート発行サーバ４００によって初期登録手数料の課金が行なわれない。このため、初期登録手数料の決済のためのユーザの操作負担を軽減させることができる一方で、バリューの購入をせずに電子マネー遊技使用サービス用の記憶領域の確保を繰返すことによって生じる未決済の初期登録手数料を低減させること、つまり電子マネー遊技使用サービスの提供機関に生じる損害を低減させることができる。

（１−１１） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記サービス提供用サーバは、さらに、前記領域構築対価の決済が終了したことを条件として、前記構築回数管理手段に管理されている当該領域構築対価の決済が終了した携帯端末の前記構築回数を減算する構築回数減算手段を備える。具体的には、ステップＳ２７０３で説明したように、初期登録手数料が決済されたことを条件に、未チャージ削除カウンタのカウント値を減算する。このため、止むを得なく複数回登録をしなおした場合に、登録後の初回チャージ時に初期登録手数料を決済しているのに、未チャージ削除カウンタのカウント値が所定回数を超えてしまって、電子マネー遊技使用サービス用の記憶領域の確保ができなくなるといった不都合を防止できる。

（１−１２） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記構築回数管理手段は、前記構築回数として前記領域構築対価の決済が終了しているか否かを示す情報を管理し、前記領域構築情報出力禁止手段は、前記構築回数管理手段によって管理されている情報によって前記登録要求情報送信元の前記携帯端末の前記領域構築対価が未決済であることが示されることを条件として、前記領域構築情報出力手段による当該携帯端末への前記領域構築情報の出力を禁止する。具体的には、前述したように（１−１１）の所定回数は１回であってもよい。その場合、未チャージ削除カウンタのカウント値を管理しなくても、初期登録手数料の決済が終了しているか否かを示す情報を管理することによって、バリューの購入をせずに電子マネー遊技使用サービス用の記憶領域の確保を繰返すことによって生じる未決済の初期登録手数料を低減させることができる。

（１−１３） 従来、携帯電話においてチャージ要求額を入力してサーバに送信し、電子マネー管理サーバは要求された額のバリューを携帯電話に送信してチャージするものがあった（たとえば、特開２００４−２７２５６０号公報の第０１２５段落から第０１２９段落、第１１図、および、第１４図参照）。このようなシステムによれば、容易にバリューをチャージすることができる。この場合、ユーザのバリューの消費には特に制限が掛けられない。また、利便性が向上するが故に、遊技者が遊技にのめり込んでしまうといった問題が発生し得る。さらに、入金機に出向くことなくバリューをチャージすることができるようにした場合、さらに利便性が向上し、遊技者が遊技にのめり込むおそれが高くなる。

しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきたチャージ要求情報に対応する電子マネー情報のチャージに関する対価の決済が終了したことを条件として、前記電子マネー情報を当該チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、所定期間内に前記対価の決済が終了した電子マネー情報の累積額または所定期間内に前記電子マネー情報出力手段により出力された電子マネー情報の累積額を各携帯端末ごとに管理する累積額管理手段と、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したときに、前記要求元携帯端末について前記累積額管理手段にて管理されている累積額と当該累積額に関して予め定められた上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段とを備え、前記電子マネー情報出力手段は、該チャージ許容判定手段によりチャージを許容すると判定されたことをさらに条件として、前記電子マネー情報を前記要求元携帯端末に送信するために出力する。このように構成しているため、遊技への過度ののめり込みを防止することが可能である。

具体的には、電子マネー管理サーバ２００は、ステップＳ２５３で説明したように、チャージ要求情報の送信元の携帯電話１００について管理されている所定期間（本実施の形態においては当日）内の積算額である当日積算額と当該当日積算額に関して予め定められた１日購入限度額（本実施の形態においては３００００円）とに基づいて、バリューの購入を許容するか否かを判定し、許容すると判定したことを条件として、ステップＳ２７７で説明したように、バリュー発行情報をチャージ要求情報の送信元の携帯電話１００に送信する。このため、当日積算額と１日購入限度額とに基づいてバリューの購入を許容するか否かが判定されるので、所定期間内のチャージ額を制限することができる。その結果、チャージ要求情報の送信元の携帯電話１００を使用する遊技者の遊技への過度ののめり込みを防止することができる。

（１−１４） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記チャージ許容判定手段は、前記チャージ要求情報を受信したときに、前記要求元携帯端末の電子マネー情報記憶手段に記憶されている電子マネー情報の残額と当該残額に関して予め定められた上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定する。具体的には、電子マネー管理サーバ２００は、ステップＳ２５１で説明したように、チャージ要求情報の送信元の携帯電話１００に記憶されているバリューの残額であるバリュー残高とバリュー残高に関して予め定められた携帯上保持限度額とに基づいて、バリューの購入を許容するか否かを判定し、許容すると判定したことを条件として、ステップＳ２７７で説明したように、バリュー発行情報をチャージ要求情報の送信元の携帯電話１００に送信する。このため、さらに、携帯電話１００に記憶されているバリュー残高と携帯上保持限度額とに基づいてバリューの購入を許容するか否かが判定されるので、携帯電話１００に記憶しておけるバリュー残高を制限することができる。その結果、遊技場３０に出向かない日に１日購入限度額の範囲内で携帯電話１００にバリューを溜め込んでおくことを防止することができるので、チャージ要求情報の送信元の携帯電話１００を使用する遊技者の遊技への過度ののめり込みをさらに防止することができる。

（１−１５） 従来、携帯電話の機種変更時にバリューを一旦、サーバに預け、機種変更後に返却を受けるシステムがあった（たとえば、特開２００４−２７２７１７号公報の第００７４段落から第００９０段落、および、第１０図から第１２図参照）。このような携帯電話によれば、機種変更時にバリューを使い切ったり、放棄したりする必要がない。しかし、特開２００４−２７２７１７号公報に開示されている技術のように、機種変更前にサーバにバリューを預けて、機種変更をしてバリューを購入および発行した後で、預けていたバリューの返却を受けた場合、携帯電話に記憶されるバリュー残高が携帯上保持限度額を超過してしまう。その結果、ユーザの過度の消費を助長してしまうといった問題が発生し得る。

しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したときに、当該チャージ要求情報送信元の携帯端末である要求元携帯端末の電子マネー情報記憶手段に記憶されている電子マネー情報の残額、および、電子マネー情報記憶手段に記憶可能な電子マネー情報の上限額に基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段と、前記チャージ許容判定手段によりチャージを許容すると判定されたことを条件として、前記電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段と、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報記憶手段に記憶されている電子マネー情報の残額の預かりを要求するための預かり要求情報を前記サービス提供用サーバに送信するために出力する預かり要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記預かり要求情報出力手段から送信されてきた前記預かり要求情報から特定される電子マネー情報の残額を預かり残額として当該預かり残額を識別するための預かり残額識別情報と対応付けて登録する預かり処理を行なう預かり残額登録手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記預かり残額識別情報を含む預かり残額の返却を要求するための預かり残額返却要求情報を前記サービス提供用サーバに送信するために出力する預かり残額返却要求情報出力手段を備え、前記サービス提供用サーバは、さらに、前記預かり残額返却要求情報出力手段から送信されてきた前記預かり残額返却要求情報に含まれる預かり残額識別情報に対応して前記預かり残額登録手段に登録されている前記預かり残額と前記預かり残額返却要求情報送信元の携帯端末の電子マネー情報記憶手段に記憶されている電子マネー情報の残額との合計額、および、前記上限額に基づいて前記預かり残額の返却を許容するか否かを判定する預かり残額返却許容判定手段と、該預かり残額返却許容判定手段によって返却を許容すると判定されたことを条件として、前記預かり残額の電子マネー情報を前記預かり残額返却要求情報送信元の携帯端末に送信するために出力する返却要求時電子マネー情報出力手段とを備え、前記電子マネー情報処理実行手段は、前記返却要求時電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する。このように構成しているため、ユーザが過度の消費をしてしまうことを防止することができる。

具体的には、電子マネー管理サーバ２００は、ステップＳ２１７７で説明したように、預かり番号情報に含まれるお預かり番号に対応して登録されている預かり残高と預かり番号情報の送信元の携帯電話１００に記憶されているバリュー残高との合計額と携帯電話１００に記憶可能なバリューの上限額である携帯上保持限度額とに基づいて、預かり残高の返却を許容するか否かを判定し、許容すると判定したことを条件として、ステップＳ２１７９、Ｓ２２７２で説明したように、預かり残高を返却するための預かり残高情報およびバリュー返却情報を預かり番号情報の送信元の携帯電話に送信する。このため、預かり残高と携帯電話１００に記憶されているバリュー残高との合計額と携帯上保持限度額とに基づいて預かり残高の返却を許容するか否かが判定されるので、預かり残高の返却時にも、携帯電話１００に記憶しておけるバリュー残高を制限することができる。その結果、機種変更後の携帯電話１００でバリューの購入および発行を行なった後に預かり残高の返却を受けることで携帯上保持限度額を超えたバリューが携帯電話１００に記憶されることによって、ユーザが過度の消費をしてしまうことを防止することができる。

（１−１６） （１−１３）で説明したように、携帯電話にチャージされたバリューを遊技に使用させる場合、ユーザの過度の消費（のめり込み）を防止するために、携帯電話へのチャージ額（携帯電話に記憶できる額）や携帯電話に１日にチャージできる額に上限を設けるのが望ましい。しかし、このような上限額を設けると、バリューを使用して取引を行なう機器の試験を行なう場合に、携帯電話１台だけでは使用できるバリューの上限額をすぐに超過してしまうので、複数の携帯電話を用いる必要があり、不便であるといった問題があった。また、テスト用の携帯電話はサーバを経由せずにバリューをチャージすることができるようにすることが考えられる。しかし、このようにすると、テスト用の携帯電話になりすまされた場合、無償でバリューをチャージすることができることとなってしまい、セキュリティ上、問題となる。

しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、所定期間内に各携帯端末にチャージされた電子マネー情報の累積額を管理する累積額管理手段と、前記チャージ要求情報送信元の携帯端末である要求元携帯端末について前記累積額管理手段にて管理されている累積額である判定対象額と、前記所定期間内にチャージ可能な電子マネー情報の上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段と、該チャージ許容判定手段によりチャージを許容すると判定されたことを条件として、前記電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記上限額として、一般ユーザが前記電子マネーサービスを享受するために用いる通常用携帯端末に対する通常用上限額と、前記電子マネーサービスが適正に提供されるか否かをテストするために用いるテスト用携帯端末に対する前記通常用上限額よりも高いテスト用上限額とを設定する上限額設定手段と、前記要求元携帯端末が前記通常用携帯端末であるか前記テスト用携帯端末であるかを特定する携帯端末特定手段とを備え、前記チャージ許容判定手段は、前記携帯端末特定手段によって前記通常用携帯端末であると特定された場合は、前記判定対象額と前記上限額設定手段によって設定された前記通常用上限額とに基づいて、前記チャージを許容するか否かを判定し、前記携帯端末特定手段によって前記テスト用携帯端末であると特定された場合は、前記判定対象額と前記上限額設定手段によって設定された前記テスト用上限額とに基づいて、前記チャージを許容するか否かを判定する。

また、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報送信元の携帯端末である要求元携帯端末の前記電子マネー情報記憶手段に記憶されている電子マネー情報の残額である判定対象額と、前記電子マネー記憶手段に記憶可能な電子マネー情報の上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段と、該チャージ許容判定手段によりチャージを許容すると判定されたことを条件として、前記電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記上限額として、一般ユーザが前記電子マネーサービスを享受するために用いる通常用携帯端末に対する通常用上限額と、前記電子マネーサービスが適正に提供されるか否かをテストするために用いるテスト用携帯端末に対する前記通常用上限額よりも高いテスト用上限額とを設定する上限額設定手段と、前記要求元携帯端末が前記通常用携帯端末であるか前記テスト用携帯端末であるかを特定する携帯端末特定手段とを備え、前記チャージ許容判定手段は、前記携帯端末特定手段によって前記通常用携帯端末であると特定された場合は、前記判定対象額と前記上限額設定手段によって設定された前記通常用上限額とに基づいて、前記チャージを許容するか否かを判定し、前記携帯端末特定手段によって前記テスト用携帯端末であると特定された場合は、前記判定対象額と前記上限額設定手段によって設定された前記テスト用上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定する。このように構成しているため、ユーザの過度の消費を防止するとともに、電子マネーシステム１０のテストを行なう際の不便さを解消しつつ、セキュリティを担保することができる。

具体的には、ステップＳ２４６ａ〜Ｓ２５３で説明したように、テスト用の携帯電話については、通常用の携帯上保持限度額および１日購入限度額よりも高いテスト用の携帯上保持限度額および１日購入限度額に基づいて、チャージを許容するか否かが判定される。このため、通常用の携帯電話を用いる場合と比較してテスト用の携帯電話を用いる場合には、通常時の額よりも多くチャージすることができ、システムの試験を行なう際の不便さを解消することができる。

また、ステップＳ２４６ａ〜Ｓ２５３で説明したように、通常用の携帯電話とテスト用の携帯電話とで、携帯上保持限度額および１日購入限度額を異ならせるだけで同様の方法でチャージを許容するか否かを判定する。このため、たとえば、テスト用の携帯電話については上限額に基づいて制限を排除するために、電子マネー管理サーバ２００を経由せずにチャージを可能とするようなシステムと比較して、セキュリティホールが生じるおそれを低減できる。

（１−１７） 従来、バリューをチャージする際、チャージ額を入力するための数値入力欄を携帯電話１００に表示させて、ユーザに購入希望金額を入力させるものがあった。しかし、ユーザが自由に金額を入力できるため、入力金額が上限を超える場合にはユーザに再入力を促がす必要が生じ、ユーザに手間を掛けさせてしまうといった問題がある。このため、上限額の範囲内のバリューのチャージ額の選択肢を電子マネーアプリに予め組込んでおき、その選択肢から選択させることが考えられる。この場合、チャージ上限額の変更に伴なってチャージ額の選択肢を変更させるために、わざわざ、電子マネーアプリを導入し直す必要が生じる。

しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段と、前記特定プログラムが示す処理手順に従って、複数種類のチャージ額の選択肢を表示し、該選択肢のうちから、ユーザの所望するチャージ額の指定を受付けるチャージ額受付手段と、前記特定プログラムが示す処理手順に従って、該チャージ額受付手段により指定を受付けたチャージ額を示すチャージ額情報を前記サービス提供用サーバに送信するために出力するチャージ額情報出力手段とを備え、前記サービス提供サーバは、さらに、所定期間内に各携帯端末にチャージされた電子マネー情報の累積額を管理する累積額管理手段と、前記チャージ要求情報送信元の携帯端末である要求元携帯端末について前記累積額管理手段にて管理されている累積額と、予め定められた上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段と、該チャージ許容判定手段によりチャージを許容すると判定され、かつ前記チャージ額情報出力手段から送信されてきたチャージ額情報が示すチャージ額の決済が終了したことを条件として、当該チャージ額の電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したことを条件として、前記複数種類のチャージ額の選択肢を示す選択額情報を前記要求元携帯端末に送信するために出力する選択額情報出力手段を備え、前記チャージ額受付手段は、該選択額情報出力手段から送信されてきた選択額情報が示す複数種類のチャージ額の選択肢を表示する。

また、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段と、前記特定プログラムが示す処理手順に従って、複数種類のチャージ額の選択肢を表示し、該選択肢のうちから、ユーザの所望するチャージ額の指定を受付けるチャージ額受付手段と、前記特定プログラムが示す処理手順に従って、該チャージ額受付手段により指定を受付けたチャージ額を示すチャージ額情報を前記サービス提供用サーバに送信するために出力するチャージ額情報出力手段とを備え、前記サービス提供サーバは、さらに、前記チャージ要求情報送信元の携帯端末である要求元携帯端末の前記電子マネー情報記憶手段に記憶されている電子マネー情報の残額と、予め定められた上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段と、該チャージ許容判定手段によりチャージを許容すると判定され、かつ前記チャージ額情報出力手段から送信されてきたチャージ額情報が示すチャージ額の決済が終了したことを条件として、当該チャージ額の電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したことを条件として、前記複数種類のチャージ額の選択肢を示す選択額情報を前記要求元携帯端末に送信するために出力する選択額情報出力手段を備え、前記チャージ額受付手段は、該選択額情報出力手段から送信されてきた選択額情報が示す複数種類のチャージ額の選択肢を表示する。このように構成しているため、効率的にユーザに適切なチャージ額を選択させることが可能である。

具体的には、ステップＳ２５６で説明したように、ステップＳ２４７で読出された表示金額リスト情報を含む残高情報が携帯電話１００に送信される。このため、電子マネー管理サーバ２００において、携帯上保持限度額や１日購入限度額が変更された場合にも、電子マネーアプリを変更することなく、電子マネー管理サーバ２００において表示金額リスト情報を変更することにより、携帯電話１００に表示させるチャージ額の選択肢を変更することができる。

（１−１８） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記サービス提供用サーバは、さらに、前記選択額情報出力手段によって前記選択額情報が出力されるときに、前記上限額から前記累積額を減算した額であるチャージ可能額を示すチャージ可能額情報を前記携帯端末に送信するために出力するチャージ可能額情報出力手段を備え、前記チャージ額受付手段は、前記選択額情報により示される複数種類のチャージ額のうち、前記チャージ可能額情報出力手段から送信されてきたチャージ可能額情報により示されるチャージ可能額以下のチャージ額を指定可能であることを示す態様で表示する。

また、前記サービス提供用サーバは、さらに、前記選択額情報出力手段によって前記選択額情報が出力されるときに、前記上限額から前記残額を減算した額であるチャージ可能額を示すチャージ可能額情報を前記携帯端末に送信するために出力するチャージ可能額情報出力手段を備え、前記チャージ額受付手段は、前記選択額情報により示される複数種類のチャージ額のうち、前記チャージ可能額情報出力手段から送信されてきたチャージ可能額情報により示されるチャージ可能額以下のチャージ額を指定可能であることを示す態様で表示する。具体的には、図３２（ｂ）で説明したように、表示金額リスト情報に含まれる複数種類の金額のうち、１日購入限度額から当日積算額を減算したステップＳ２５５で算出される購入可能金額以下であって、携帯上保持限度額からバリュー残高を減算したステップＳ２５５で算出される購入可能金額以下の金額の選択肢が指定可能であることをユーザに認識させることができる。すなわち、表示金額リスト情報に含まれる複数種類の金額のうち、１日購入限度額と当日積算額との差額および携帯上保持限度額とバリュー残高との差額の範囲内の金額の選択肢が指定可能であることをユーザに認識させることができる。その結果、ユーザに、購入できない選択肢を選択させてしまうような無駄な操作をさせることを防止することができる。

（１−１９） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、前記特定プログラムが示す処理手順に従って、複数種類のチャージ額の選択肢を表示し、該選択肢のうちから、ユーザの所望するチャージ額の指定を受付けるチャージ額受付手段と、前記特定プログラムが示す処理手順に従って、該チャージ額受付手段により指定を受付けたチャージ額を示すチャージ額情報を前記サービス提供用サーバに送信するために出力するチャージ額情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記複数種類のチャージ額の選択肢を示す選択額情報として、前記通常用携帯端末に対する通常用選択額情報と、前記テスト用携帯端末に対するテスト用選択額情報とを管理する選択額情報管理手段と、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したことを条件として、前記携帯端末特定手段によって前記通常用携帯端末であると特定された場合は、前記選択額情報管理手段によって管理されている前記通常用選択額情報を前記要求元携帯端末に送信するために出力し、前記携帯端末特定手段によって前記テスト用携帯端末であると特定された場合は、前記選択額情報管理手段によって管理されている前記テスト用選択額情報を前記要求元携帯端末に送信するために出力する選択額情報出力手段とを備え、前記チャージ額受付手段は、該選択額情報出力手段から送信されてきた選択額情報が示す複数種類のチャージ額の選択肢を表示し、前記電子マネー情報出力手段は、前記チャージ額情報出力手段から送信されてきたチャージ額情報が示すチャージ額の電子マネー情報を送信する。具体的には、ステップＳ２５６で説明したように、チャージ要求情報の送信元の携帯電話が通常用の携帯電話であるかテスト用の携帯電話であるかに応じた複数種類の購入希望金額の選択肢である表示金額リストを示す表示金額リスト情報がチャージ要求情報の送信元の携帯電話に送信され、送信された表示金額リスト情報が示す複数種類の購入希望金額の選択肢が携帯電話の表示部に表示される。このため、携帯上保持限度額や１日購入限度額が変更された場合にも適切な購入希望金額の選択肢をユーザに提供できるとともに、チャージ要求情報の送信元の携帯電話が通常用であるかテスト用であるかに応じた適切な購入希望金額の選択肢を適用できる。

（１−２０） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記預かり要求情報出力手段は、前記携帯端末を識別するための携帯端末識別情報を含む前記預かり要求情報を出力し、前記預かり残額登録手段は、前記預かり残額を、前記預かり要求情報に含まれる前記携帯端末識別情報とさらに対応付けて登録する前記預かり処理を行ない、前記預かり残額返却要求情報出力手段は、前記携帯端末識別情報をさらに含む前記預かり残額返却要求情報を出力し、前記サービス提供用サーバは、さらに、前記預かり残額返却要求情報出力手段から送信されてきた前記預かり残額返却要求情報に含まれる預かり残額識別情報に対応して前記預かり残額登録手段に登録されている前記携帯端末識別情報と、前記預かり残額返却要求情報出力手段から送信されてきた前記預かり残額返却要求情報に含まれる前記携帯端末識別情報とが一致するか否かを判定する携帯端末識別情報判定手段を備え、前記返却要求時電子マネー情報出力手段は、該携帯端末識別情報判定手段によって前記携帯端末識別情報が一致しないと判定されたことをさらに条件として、前記預かり残額の電子マネー情報を出力する。具体的には、ステップＳ２１７４で残高移行依頼情報に含まれる携帯端末情報と預かり番号情報に含まれる携帯端末情報とが一致しないと判断したことを条件として、ステップＳ２１７９，Ｓ２２７２で説明したように、預かり残高のバリューを返却するための預かり残高情報および返却実行情報が出力される。このため、残高移行依頼情報の送信元の携帯電話と預かり番号情報の送信元の携帯電話とが同一であるという機種変更が行なわれる場合には本来起こり得ない状況、つまり、不正等の疑いのある状況で、預かり残高のバリューの返却が行なわれてしまうことを防止できる。

（１−２１） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、当該携帯端末が前記通常用携帯端末であるか前記テスト用携帯端末であるかを特定可能な種別特定情報を前記遊技可能化処理手段に送信するために出力する種別特定情報出力手段を備え、前記遊技可能化処理手段は、前記テスト用携帯端末の使用を許可するか否かを予め設定するためのテスト用携帯端末使用可否設定手段を含み、前記種別特定情報出力手段から送信されてきた前記種別特定情報によって当該種別特定情報の送信元の携帯端末が前記テスト用携帯端末であることが特定される場合に、前記テスト用携帯端末使用可否設定手段によって前記テスト用携帯端末の使用を許可すると設定されていることを条件として、当該種別特定情報の送信元の携帯端末の電子マネー情報記憶手段に記憶されている電子マネー情報を用いた前記遊技可能化処理を実行する。具体的には、ステップＳ３４５およびステップＳ３４６で説明したように、テスト用の携帯電話の盗難などが発生した場合には、盗まれたテスト用の携帯電話の使用を許可しないように設定しておくことによって、盗まれた携帯電話に記憶されているバリューを用いたプリペイドカード３７１の発券が実行されないようにすることができる。このため、テスト用の携帯電話の盗難などが発生した場合に、盗まれたテスト用の携帯電話の使用を防止できる。

（１−２２） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記遊技可能化処理手段は、前記電子マネー情報処理実行手段により実行される処理により加算される特定の種類の電子マネー情報を減算する対象として指定する種類指定情報を前記携帯端末に送信するために出力する種類指定情報出力手段を含み、前記電子マネー情報減算手段は、前記種類指定情報出力手段から送信されてきた前記種類指定情報に基づき、減算する対象として指定された前記特定の種類の電子マネー情報を減算する。具体的には、図３９の発券処理および図４２の球貸処理に従って、それぞれ、ステップＳ３５６およびＳ６５６において特定の種類の電子マネーであるバリューを引落対象として指定する電子マネー識別情報を含む減算要求信号が、券売機３００またはカードユニット６００から携帯電話１００に送信され、当該電子マネー識別情報により指定されるバリューのみを用いてプリペイドカード３７１の購入または球貸を行なうことができるため、異なる種類のバリューを用いてプリペイドカード３７１の購入または球貸が行なわれることを防止することができる。

（１−２３） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記遊技用電子マネーシステムは、さらに、前記遊技場において、前記遊技可能化処理手段によって前記遊技可能化処理に用いられた前記減算された電子マネー情報の額を特定可能な減算額特定情報と、該電子マネー情報が減算された携帯端末の識別情報とを対応付けて記憶する減算電子マネー情報記憶手段と、前記減算電子マネー情報記憶手段に記憶された前記減算額特定情報と該減算額特定情報に対応する前記識別情報とを含む取引情報を前記遊技場から前記サービス提供用サーバに所定時間ごとに送信するために出力する減算電子マネー情報出力手段とを含み、前記サービス提供用サーバは、さらに、前記電子マネー情報出力手段によって出力された前記電子マネー情報の額を特定可能な送信額特定情報と、前記要求元携帯端末の識別情報とを対応付けて記憶する送信電子マネー情報記憶手段と、前記減算電子マネー情報出力手段から送信されてきた前記取引情報と、前記送信電子マネー情報記憶手段に前記識別情報と対応して記憶された情報とに基づいて、識別情報ごとに電子マネー情報の残額を管理し、残額を超えた不正取引があったか否かを判定する不正取引判定手段と、該不正取引判定手段によって前記不正取引があると判定されたことを条件として、当該不正取引と判定された取引情報に対応する識別情報を、当該不正取引が発生した遊技場側に送信するために出力する不正取引識別情報出力手段とを備え、前記遊技用電子マネーシステムは、さらに、前記遊技場において、前記不正取引識別情報出力手段から送信されてきた前記識別情報を記憶する不正取引識別情報記憶手段と、前記遊技場において、前記遊技可能化処理手段により前記遊技可能化処理に用いられる携帯端末が、前記不正取引識別情報記憶手段に記憶された識別情報が示す不正携帯端末であるか否かを判定する不正携帯端末判定手段と、該不正携帯端末判定手段によって前記不正携帯端末であると判定されたことを条件として、該不正携帯端末に対して、前記遊技可能化処理手段による前記遊技可能化処理を停止する不正携帯端末使用停止手段とを含む。具体的には、ステップＳ８１２において、プリペイドカード３７１の購入または球貸処理に用いたバリューの額と当該購入または球貸に用いた携帯電話１００の携帯ＩＤとが各々対応付けて店舗サーバ８００に記憶される。そして、ステップＳ８１３において所定時間経過したと判断された場合、ステップＳ８１４において店舗サーバ８００に記憶されていた情報を取引情報として電子マネー管理サーバ２００に送信される。一方、ステップＳ２７０７においては、チャージ累計額と携帯ＩＤとが各々対応付けて発行情報ＤＢ２２２に記憶される。そして、ステップＳ２９２において、取引情報に含まれる携帯ＩＤに対応する会員ＩＤのチャージ累計額から取引情報に含まれる取引額が減算され、ステップＳ２８１において、チャージ累計額がマイナスの会員ＩＤがあるか否かを判断することにより不正取引があったか否かが判断される。不正取引があった場合は、ステップＳ２８６において不正端末情報が、不正取引が発生した遊技場３０に送信される。

不正端末情報を受信した遊技場３０においては、ステップＳ３１４およびＳ６０４において、当該不正端末情報が記憶され、バリューでプリペイドカード３７１を購入する際および球貸処理に用いる際、携帯電話１００の携帯ＩＤが不正端末情報と一致するか否かが判断され、一致する場合、残高をバリュー残額にセットしない処理、すなわち使用停止処理が行なわれる。これにより、残額を超えた不正が行なわれたときの被害を最小限に抑えることができる。

（１−２４） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記サービス提供用サーバは、さらに、前記不正取引判定手段によって前記不正取引があると判定された頻度を測定する不正取引頻度測定手段と、前記不正取引頻度測定手段によって測定された頻度に応じて、前記不正取引があった旨を示す不正取引発生情報を当該不正取引が発生した遊技場側に送信するために出力する不正取引発生情報出力手段とを備え、前記不正取引識別情報出力手段は、前記不正取引頻度測定手段によって測定された頻度に応じて前記識別情報を出力し、前記遊技用電子マネーシステムは、さらに、前記遊技場において、前記不正取引発生情報出力手段から前記不正取引発生情報が送信されてきたことを条件として、該遊技場内のすべての前記遊技可能化処理手段による前記遊技可能化処理を停止する電子マネー情報使用停止手段と、前記不正取引頻度測定手段によって測定された頻度に応じて、前記不正携帯端末使用停止手段または前記電子マネー情報使用停止手段を選択して、該選択された手段による停止処理を実行させる選択実行手段とを含む。具体的には、ステップＳ２８１において不正取引があった場合、ステップＳ２８２において不正回数が１加算され、不正取引の頻度が測定されている。そして、不正回数が１回の場合、ステップＳ２８４において不正媒体情報を不正取引が発生した遊技場３０に送信され、不正取引に用いられたプリペイドカードによる球貸を禁止する。また、不正回数が２回の場合、ステップＳ２８６およびステップＳ２８７において不正端末情報を不正取引が発生した遊技場３０および当該遊技場３０と同じ商圏の他の遊技場に送信され、不正取引に用いられた携帯電話１００によるプリペイドカード３１７の購入および球貸を禁止する。

さらに、不正回数が３回の場合、ステップＳ２８９およびステップＳ２９０において携帯使用禁止情報を不正取引が発生した遊技場３０および全国の遊技場に送信される。そして、携帯使用禁止情報を受信した遊技場においては、ステップＳ３１２およびステップＳ６０２において、それぞれ、当該携帯使用禁止情報が記憶され、ステップＳ３２２およびステップＳ６２２により、それぞれ、すべての携帯電話についてバリューを用いてのプリペイドカード３７１購入および球貸を禁止する処理が行なわれる。このように、不正取引の頻度に応じて禁止する内容が選択され実行されるため、より効果的に不正が行なわれたときの被害を最小限に抑えることができる。

（１−２５） 非接触型ＩＣチップを内蔵した携帯電話により電子マネー端末またはサーバと通信して、バリューの加減算を行なうものがあった（たとえば、特開２００５−３８２０９号公報の第００１６段落、第００１７段落、第００４９段落から第００５５段落、第０１１１段落から第０１１４段落、第０１３６段落、および、第０１３８段落参照）。この携帯電話のアプリケーション部には、決済を行なう対象の電子マネー端末を特定する端末ＩＤ、事業者コード、動作パラメータ、および、動作ファイルが対応付けられて記憶される。

この携帯電話が用いられて電子マネー端末で決済される場合、電子マネー端末から端末ＩＤおよび決済額分のバリューが減算された後、減算完了通知が送信されるとともに、この端末ＩＤから事業者コード、動作パラメータ、および、動作ファイルが特定され、この動作ファイルが用いられて所定の動作が実行される。また、携帯電話にログ確認部が設けられて、アプリケーション部に予め確認金額が設定されることにより、ログ確認部が定期的にバリューの残額を確認し、確認金額を下回った場合、アプリケーション部が動作ファイルを用いて所定の動作として画像や音声でアラームを発することで電子マネーのチャージをユーザに促がすようにする。しかし、特開２００５−３８２０９号公報に開示されている技術によれば、携帯電話で実行できる動作ファイルは、端末ＩＤに対応する各事業者コードに対して１ファイルであるため、実行される動作は、電子マネー端末との決済処理の都度実行される動作に限定される。また、携帯電話は能動的に動作ファイルを実行するため、バリューの残高の不足確認は、前述したように行なわれる。このため、バリューの残高が確認金額を上回っていても、決められた定期間隔で、バリューの残高を確認するという無駄な処理が発生してしまうといった問題がある。また、バリューの残高が確認金額を下回っていても、決められた定期間隔が長い間隔（たとえば、１時間）である場合は、バリューのチャージがユーザに促がされる前に、電子マネー端末またはサーバによりバリューの減算が行なわれる際に、ユーザが残高不足を認識してしまい、ユーザにチャージを促がす処理を実行するという特開２００５−３８２０９号公報に開示されている技術の本来の目的を達成できないこととなってしまう。このことから、ユーザが残高不足を認識してしまう前に、バリューのチャージを促がすために、バリューの残高を確認する定期間隔を短くする（たとえば、１分や３０秒にする）必要がある。このため、バリューの残高を確認するという無駄な処理を頻繁に実行しなければならず非効率であるとともに、携帯電話のバッテリーの持続時間にも影響が生じるといった問題が発生する。

しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきたチャージ要求情報を受信したことを条件として、前記電子マネー情報を当該チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段と、前記電子マネー情報記憶手段に記憶された電子マネー情報の残額を特定可能な残額特定情報を前記遊技可能化処理手段に送信するために出力する残額特定情報出力手段とを備え、前記遊技可能化処理手段は、前記残額特定情報出力手段から送信されてきた残額特定情報で特定される電子マネー情報の残額が、前記遊技可能化処理が実行されるときに用いられる額に不足しているか否かを判定する残額不足判定手段と、前記残額不足判定手段によって不足していると判定されたことを条件として、前記残額が不足していることを示す残額不足情報を前記残額特定情報の送信元の携帯端末に送信するために出力する残額不足情報出力手段とを含み、前記携帯端末は、さらに、前記残額不足情報出力手段から前記残額不足情報を受信したことを条件として、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記残額が不足している旨を報知する残額不足報知手段を備える。このように構成しているため、バリューの残額が少ないことを効率的に的確にユーザに認識させることができる。

具体的には、携帯電話１００の非接触型ＩＣチップ１９０の機能によってバリュー残高が券売機３００またはカードユニット６００に送信される。また、ステップＳ３５１で説明したように、券売機３００によって携帯電話１００に記憶されているバリュー残高がプリペイドカード３７１の購入金額に不足していると判定され、ステップＳ３５２で説明したように、減算前残高不足情報が携帯電話１００に送信される。また、ステップＳ６５１およびステップＳ６５８で説明したように、カードユニット６００によって携帯電話１００に記憶されているバリュー残高が球貸可能な最低額に不足していると判定され（本実施の形態においては、バリュー残高が０円であるか否かを判定、遊技場３０以外でバリューを使用できる場合は、バリュー残高が球貸可能な最低額である１００円未満であるか否かを判定）、ステップＳ６５２およびステップＳ６５９で説明したように、それぞれ、減算前残高不足情報または減算後残高不足情報が携帯電話１００に送信される。そして、ステップＳ１８５で説明したように、携帯電話１００によってバリュー残高が不足している旨が報知される。つまり、バリューが用いられるときに、携帯電話１００によって、受動的に、バリュー残高が不足している旨が報知される。その結果、バリュー残高が少ないことを効率的に的確にユーザに認識させることができる。

（１−２６） また、本発明は、次のような構成を含むようにしてもよい。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきたチャージ要求情報を受信したことを条件として、前記電子マネー情報を当該チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段と、前記電子マネー情報記憶手段に記憶された電子マネー情報の残額を特定可能な残額特定情報を前記遊技可能化処理手段に送信するために出力する残額特定情報出力手段とを備え、前記遊技可能化処理手段は、前記残額特定情報出力手段から送信されてきた残額特定情報で特定される電子マネー情報の残額から前記遊技可能化処理が実行されるときに用いられる額を減算した額が所定額以下となるか否かを判定する残額不足判定手段と、前記残額不足判定手段によって前記所定額以下となると判定されたことを条件として、前記残額が所定額以下となることを示す残額不足情報を前記残額特定情報の送信元の携帯端末に送信するために出力する残額不足情報出力手段とを含み、前記携帯端末は、さらに、前記残額不足情報出力手段から前記残額不足情報を受信したことを条件として、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記残額が前記所定額以下となる旨を報知する残額不足報知手段を備える。具体的には、携帯電話１００の非接触型ＩＣチップ１９０の機能によってバリュー残高が券売機３００に送信され、ステップＳ３５８で説明したように、券売機３００によって携帯電話１００に記憶されているバリュー残高からプリペイドカード３７１の購入金額を減算した額が所定額以下となると判定され、ステップＳ３５９で説明したように、減算後残高僅少情報が携帯電話１００に送信されて、ステップＳ１８４で説明したように、携帯電話１００によってバリュー残高が所定額以下となる旨が報知される。カードユニット６００についても同様である。つまり、バリューが用いられるときに、携帯電話１００によって、受動的に、バリュー残高が所定額以下となる旨が報知される。その結果、バリュー残高が少ないことを効率的に的確にユーザに認識させることができる。

（１−２７） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、前記残額不足情報出力手段から前記残額不足情報を受信したときに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求処理を実行するチャージ要求処理実行手段を備え、前記チャージ要求情報出力手段は、該チャージ要求処理実行手段によって前記チャージ要求処理が実行された後に、前記チャージ要求情報を出力する。具体的には、ステップＳ１８１またはステップＳ１８２で減算前残高不足情報、減算後残高不足情報、または、減算後残高僅少情報が受信されたときにバリュー購入時処理が実行され、ステップＳ１３３で説明したように、バリュー購入時処理の実行開始後に自動的にチャージ要求情報が送信されるため、ユーザがバリュー購入時処理を能動的に実行させなくてもよい。このため、バリュー購入時処理を実行させる手間をユーザに掛けさせないようにできる。また、バリュー購入時処理が即座に実行されるので、バリュー購入に要する時間が短縮され、遊技場３０におけるパチンコ遊技機７００やスロットマシン等の遊技機の稼動率を向上させることができる。

（１−２８） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記チャージ要求処理実行手段は、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、複数種類のチャージ額の選択肢を表示し、該選択肢のうちから、ユーザの所望するチャージ額の指定を受付けるチャージ額受付手段を含む。具体的には、バリュー購入時処理として、ステップＳ１３９で購入希望金額の選択肢が表示され、ステップＳ１４１で購入希望金額の選択が受付けられるので、ユーザが能動的にバリュー購入時処理を実行させて購入希望金額の選択肢を表示させなくてもよい。このため、バリュー購入時処理を実行させ購入希望金額の選択肢を表示させる手間をユーザに掛けさせないようにできる。また、バリュー購入時処理が即座に実行され購入希望金額の選択肢が表示されるので、バリュー購入に要する時間が短縮され、遊技場３０におけるパチンコ遊技機７００やスロットマシン等の遊技機の稼動率を向上させることができる。

（２−１） 従来、電子マネーをネットチャージするものがあった。ネットチャージとは、携帯端末からサーバへのチャージの要求に対してサーバがインターネットなどのネットワークを介して携帯端末に電子マネーをチャージすることをいう。この場合に、携帯端末は、電子マネーの書込みに伴なってログを更新するとともに、電子マネーサーバに書込完了を送信する。また、電子マネーサーバも取引ログを更新する（たとえば、特開２００４−２７２５６０号公報）。しかし、このような技術においては、携帯端末においてログの更新に失敗すると、携帯端末側の管理状況は未書込である一方、サーバ側の管理状況は書込済となる。このため、両者の管理状況に不一致が生じるために、その後の処理に不都合が発生するといった問題があった。

しかし、本発明は次のような構成を含む。つまり、ユーザが所望するデータが書込まれる記憶手段を備えた携帯端末と、該携帯端末に対して前記データを発行する発行処理と、該発行したデータを前記記憶手段に書込むための書込処理とを行なう発行書込処理サーバとを備えたデータ発行書込システムであって、前記携帯端末は、前記データの処理状況を管理する処理状況管理手段と、該処理状況管理手段によって管理されている処理状況が未書込であることを条件として、前記データの書込みを要求するための書込要求情報を前記発行書込処理サーバに送信するために出力する書込要求出力手段を備え、前記発行書込処理サーバは、前記携帯端末に対して書込むべきデータが書込済か否かを示す書込状況を管理する書込状況管理手段と、前記書込要求出力手段から送信されてきた前記書込要求情報に対応するデータの前記書込状況管理手段によって管理されている書込状況が未書込であることを条件として、当該データの前記記憶手段への書込みを指示する書込指示情報を、当該書込要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力する書込指示出力手段と、該書込指示出力手段によって前記書込指示情報が出力されたことを条件として、当該書込指示情報で書込みが指示されたデータの前記書込状況管理手段によって管理されている書込状況を、書込済に更新する書込状況更新手段とを備え、前記携帯端末は、さらに、前記書込指示出力手段から前記書込指示情報を受信したことを条件として、当該書込指示情報で書込みが指示されたデータを前記記憶手段に書込むための処理を実行するデータ書込実行手段と、該書込処理実行手段によって前記データを書込むための処理が実行されたことを条件として、当該データの前記処理状況管理手段によって管理されている処理状況を、データ書込済に更新する処理状況更新手段とを備え、前記発行書込処理サーバは、さらに、前記処理状況管理手段によって管理されている処理状況を更新させるための更新指示情報を前記携帯端末に送信するために出力する更新指示出力手段を備え、前記携帯端末は、前記更新指示出力手段からの前記更新指示情報の受信に基づいて、前記処理状況管理手段によって管理されている処理状況を更新する処理状況強制更新処理を実行する処理状況強制更新手段を備える。このように構成しているため、データの書込みに関し携帯端末とサーバとで管理されている状況の不一致を解消し、その後の処理の不都合を解消することができる。

具体的には、データ発行書込システム（たとえば、電子マネーシステム１０）は、ユーザが所望するデータ（たとえば、バリュー等の電子マネー情報）が書込まれる記憶手段（たとえば、非接触型ＩＣチップ１９０の記憶部１９２）を備えた携帯端末（たとえば、携帯電話１００）と、該携帯端末に対して前記データを発行する発行処理と、該発行したデータを前記記憶手段に書込むための書込処理とを行なう発行書込処理サーバ（たとえば、電子マネー管理サーバ２００、決済サーバ２８０、リモート発行サーバ４００）とを備える。ステップＳ１２２ａ，Ｓ１２７，Ｓ１５３ａ，Ｓ１５７ａ，Ｓ１６０７ａ，Ｓ１６１４ａ，Ｓ１７１６，Ｓ１７２４ａで説明したように、携帯端末によって、データの処理状況（たとえば、処理状況）が管理される。ステップＳ１５４で説明したように、携帯端末によって、管理されている処理状況が未書込であること（たとえば、ステップＳ１５１においてＹＥＳの場合）を条件として、データの書込みを要求するための書込要求情報（たとえば、書込処理開始要求）が発行書込処理サーバに送信するために出力される。図５の発行情報ＤＢ２２２で説明したように、発行書込処理サーバによって、携帯端末に対して書込むべきデータが書込済（たとえば、発行済）か否かを示す書込状況（たとえば、処理状況）が管理される。送信されてきた書込要求情報に対応するデータの管理されている書込状況が未書込であること（たとえば、ステップＳ２７４においてＹＥＳの場合）を条件として、当該データの書込みを指示する書込指示情報（たとえば、書込実行情報）が、当該書込要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力される（たとえば、リモート発行サーバ４００による書込実行情報の送信）。書込指示情報が出力されたこと（たとえば、リモート発行サーバ４００によって書込実行が送信されたこと）を条件として、当該書込指示情報で書込みが指示されたデータの管理されている書込状況が、書込済（たとえば、書込終了済）に更新される（たとえば、リモート発行サーバ４００による処理状況の書込終了済への更新、または、ステップＳ２７９６）。ステップＳ１５６で説明したように、携帯端末によって、書込指示情報を受信したこと（たとえば、ステップＳ１５５においてＹＥＳの場合）を条件として、当該書込指示情報で書込みが指示されたデータを書込むための処理（たとえば、書込処理）が実行される。ステップＳ１５７ａで説明したように、携帯端末によって、データを書込むための処理が実行されたこと（たとえば、ステップＳ１５７またはステップＳ１５７ｂにおいてＹＥＳの場合）を条件として、当該データの管理されている処理状況が、データ書込済（たとえば、書込済）に更新される。ステップＳ２９１８で説明したように、発行書込処理サーバによって、管理されている処理状況を更新させるための更新指示情報（たとえば、エラー対応完了メール）が携帯端末に送信するために出力される。Ｓ１１１３で説明したように、携帯端末によって、更新指示情報の受信に基づいて（たとえば、エラー対応完了メールから電子マネーアプリ１１１が起動されたことを条件として）、管理されている処理状況を更新する処理状況強制更新処理が実行される。これにより、通常は、発行書込処理サーバでは、書込指示情報の出力を条件として、書込状況が書込済に更新され、携帯端末では、書込指示情報で書込みが指示されたデータを書込むための処理の実行を条件として、処理状況がデータ書込済に更新される。しかし、データが書込まれたときに携帯端末側で処理状況のデータ書込済への更新に失敗した場合であっても、発行書込処理サーバからの指示で強制的に処理状況が更新される。その結果、データの書込みに関し携帯端末における処理状況と発行書込処理サーバにおける書込状況との不一致を解消し、その後の処理の不都合を解消することができる。

（２−２） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記発行書込処理サーバは、さらに、前記携帯端末から処理状況を取得する処理状況取得手段と、該処理状況取得手段によって取得された処理状況に基づいた処理を実行する取得状況処理実行手段とを備える。具体的には、ステップＳ２９１４で説明したように、発行書込処理サーバによって、携帯端末から処理状況が取得される。ステップＳ２９１６〜Ｓ２９１８で説明したように、発行書込処理サーバによって、取得された処理状況に基づいた処理が実行される。これにより、発行書込処理サーバによって取得された処理状況に基づいた処理が実行される。このため、処理状況が発行書込処理サーバで確認された上で必要な処理が実行されるようにすることができる。

（２−３） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記取得状況処理実行手段は、前記処理状況取得手段によって取得された処理状況と、前記書込状況管理手段によって管理されている書込状況とが一致するか否かを判断し、前記更新指示出力手段は、前記取得状況処理手段によって一致しないと判断されたことを条件として、前記更新指示情報を出力する。具体的には、ステップＳ２９１６およびステップＳ２９１７ａで説明したように、発行書込処理サーバによって、取得された処理状況と、管理されている書込状況とが一致するか否かが判断される。ステップＳ２９１８で説明したように、発行書込処理サーバによって、一致しないと判断されたこと（たとえば、ステップＳ２９１７ａにおいてＹＥＳの場合）を条件として、更新指示情報が出力される。これにより、オペレータによる確認作業等の手間を省くことができる。

（２−４） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記更新指示出力手段は、前記処理状況強制更新処理を実行させるために操作されるリンク情報が添付された電子メールを、前記更新指示情報として出力し、前記更新指示出力手段から送信されてきた前記電子メールに添付されたリンク情報が操作されることを条件として、前記処理状況強制更新手段は、前記処理状況強制更新処理を実行する。具体的には、ステップＳ２９１８で説明したように、発行書込処理サーバによって、処理状況強制更新処理を実行させるために操作されるリンク情報が添付された電子メール（たとえば、エラー対応完了メール）が、更新指示情報として出力される。ステップＳ１１１３で説明したように、携帯端末によって、送信されてきた電子メールに添付されたリンク情報が操作されること（たとえば、ステップＳ１１１０においてＹＥＳの場合）を条件として、処理状況強制更新処理が実行される。これにより、発行書込処理サーバ側での処理が終了し、処理状況の更新が可能となったことをユーザに確実に認識させることができるとともに、更新のためのユーザの操作負担も軽減させることができる。また、発行書込処理サーバから更新指示情報が出力されることなく処理状況強制更新処理が行なわれないようにすることができるので、ユーザの誤操作や悪用によって処理状況が強制的に更新されないようにすることができる。

（２−５） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、前記リンク情報の操作が初回か否かを判定するリンク操作判定手段を備え、前記処理状況強制更新手段は、前記リンク操作判定手段によって前記リンク情報の操作が初回であると判定されたことをさらに条件として、前記処理状況強制更新処理を実行する。具体的には、ステップＳ１１１１で説明したように、携帯端末によって、リンク情報の操作が初回か否かが判定される。ステップＳ１１１３で説明したように、携帯端末によって、リンク情報の操作が初回であると判定されたこと（たとえば、ステップＳ１１１１においてＹＥＳの場合）をさらに条件として、処理状況強制更新処理が実行される。これにより、ユーザの過誤等によりリンク情報が複数回操作されても、その度に処理状況が更新されないようにすることができる。

（３−１） 従来、データを発行する発行処理サーバと、発行されたデータを携帯端末に書込むデータ書込処理を行なう書込処理サーバとが別個に設けられるシステムがあった（たとえば、株式会社エヌ・ティ・ティ・ドコモ東海、新しいケータイの活用例「ｉモード（登録商標）Ｆｅｌｉｃａ（登録商標）」、［online］、［２００５年１２月９日］、インターネット〈ＵＲＬ：http://www.docomo-tokai.co.jp/businesshub/bh/felica/donyu.html〉）。しかし、このような技術によれば、発行処理サーバからデータの発行を受けた後に、当該データの書込処理において書込処理サーバとの通信が切断された場合に、再度データ発行のための処理をやり直し、発行処理サーバに発行要求を送信すると、発行処理サーバにおいてはデータを発行済であるため、発行要求が受付けられずデータを書込むことができなくなってしまうといった問題があった。

しかし、本発明は次のような構成を含む。つまり、ユーザが所望するデータの書込処理を行なう書込処理サーバからの指示に基づいて前記データが書込まれる記憶手段を備えた携帯端末と、該携帯端末に対して前記データを発行する発行処理サーバとを備えたデータ発行システムであって、前記携帯端末は、前記データの発行を要求するための発行操作をユーザから受付ける発行操作受付手段と、前記発行操作受付手段によって発行操作が受付けられたことを条件として、前記データの発行を要求するための発行要求情報を前記発行処理サーバに送信するために出力する発行要求出力手段とを備え、前記発行処理サーバは、前記携帯端末に対して発行すべきデータが発行済か否かを示す発行状況を管理する発行状況管理手段と、前記発行要求出力手段から送信されてきた前記発行要求情報に対応するデータの前記発行状況管理手段によって管理されている発行状況が、未発行であることを条件として、当該データを、当該発行要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力するデータ出力手段と、該データ出力手段によって前記データが出力されたことを条件として、当該データの前記発行状況管理手段によって管理されている発行状況を、発行済に更新する発行状況更新手段とを備え、前記携帯端末は、さらに、前記データの処理状況を管理する処理状況管理手段と、前記データ出力手段から送信されてきた前記データを受信したことを条件として、当該データの前記処理状況管理手段によって管理されている処理状況を、データ受信済に更新する処理状況更新手段と、前記データ出力手段から送信されてきた前記データを受信したことを条件として、当該データの前記記憶手段への書込みを要求する書込要求情報を、前記書込処理サーバに送信するために出力する書込要求出力手段と、前記書込処理サーバから前記データの前記記憶手段への書込みを指示する書込指示情報を受信したことを条件として、前記データを前記記憶手段に書込むデータ書込実行手段とを備え、前記処理状況更新手段は、前記データ書込実行手段によって前記データが書込まれたことを条件として、当該データの前記処理状況管理手段によって管理されている処理状況を、データ書込済に更新し、前記携帯端末は、さらに、前記発行操作受付手段によって発行操作が受付けられたときに、前記処理状況管理手段によって管理されている処理状況がデータ受信済であることを条件として、前記発行要求出力手段による前記発行要求情報の出力を実行することなく、前記書込要求出力手段による前記書込要求情報の前記書込処理サーバへの出力を実行する要求出力実行制御手段を備える。このように構成しているため、書込処理サーバとの通信が切断された場合であっても、再度行なった発行操作に基づいて確実にデータを書込むことができる。

具体的には、データ発行システム（電子マネーシステム１０）は、ユーザが所望するデータ（たとえば、バリュー等の電子マネー情報）の書込処理を行なう書込処理サーバ（たとえば、リモート発行サーバ４００）からの指示に基づいてデータが書込まれる記憶手段（たとえば、非接触型ＩＣチップ１９０の記憶部１９２）を備えた携帯端末（たとえば、携帯電話１００）と、該携帯端末に対してデータを発行する発行処理サーバ（たとえば、電子マネー管理サーバ２００、決済サーバ２８０）とを備える。ステップＳ１９４またはステップＳ１９１で説明したように、携帯端末によって、データの発行を要求するための発行操作（たとえば、図２８（ｂ）の画面で丸付き数字２の「ＩＣチップへの購入バリューのチャージ」の選択肢を選択する操作、または、図３３（ｂ）の画面で引継ぎ情報を選択する操作）がユーザから受付けられる。ステップＳ１５２で説明したように、携帯端末によって、発行操作が受付けられたこと（たとえば、ステップＳ１９４またはステップＳ１９１においてＹＥＳの場合）を条件として、データの発行を要求するための発行要求情報（たとえば、バリュー発行要求情報）が発行処理サーバに送信するために出力される。図５の発行情報ＤＢ２２２で説明したように、発行処理サーバによって、携帯端末に対して発行すべきデータが発行済（たとえば、発行済）か否（たとえば、未発行）かを示す発行状況（たとえば、処理状況）が管理される。ステップＳ２７７で説明したように、発行処理サーバによって、送信されてきた発行要求情報に対応するデータの管理されている発行状況が、未発行であること（たとえば、ステップＳ２７４においてＹＥＳの場合）を条件として、当該データ（たとえば、バリュー発行情報）が、当該発行要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力される。ステップＳ２７９で説明したように、データが出力されたこと（たとえば、ステップＳ２７８においてＹＥＳの場合）を条件として、当該データの管理されている発行状況が、発行済に更新される。ステップＳ１２２ａ，Ｓ１２７，Ｓ１５３ａ，Ｓ１５７ａ，Ｓ１６０７ａ，Ｓ１６１４ａ，Ｓ１７１６，Ｓ１７２４ａで説明したように、携帯端末によって、データの処理状況が管理される。ステップＳ１５３ａで説明したように、携帯端末によって、送信されてきたデータを受信したこと（たとえば、ステップＳ１５３においてＹＥＳの場合）を条件として、当該データの管理されている処理状況が、データ受信済（たとえば、発行情報受信済）に更新される。ステップＳ１５４で説明したように、携帯端末によって、送信されてきたデータを受信したこと（たとえば、ステップＳ１５３においてＹＥＳの場合）を条件として、当該データの書込みを要求する書込要求情報（たとえば、書込処理開始要求）が、書込処理サーバに送信するために出力される。ステップＳ１５６で説明したように、携帯端末によって、書込処理サーバからデータの書込みを指示する書込指示情報を受信したこと（たとえば、ステップＳ１５５においてＹＥＳの場合）を条件として、データが書込まれる。ステップＳ１５７ａで説明したように、携帯端末によって、データが書込まれたこと（たとえば、ステップＳ１５７においてＹＥＳの場合）を条件として、当該データの管理されている処理状況が、データ書込済（たとえば、書込済）に更新される。ステップＳ１５４で説明したように、携帯端末によって、発行操作が受付けられたときに、管理されている処理状況がデータ受信済であること（たとえば、ステップＳ１５１においてＹＥＳの場合）を条件として、発行要求情報の出力が実行されることなく（たとえば、ステップＳ１５２においてバリュー発行要求情報を送信することなく）、書込要求情報の書込処理サーバへの出力が実行される。これにより、発行処理サーバによってデータが送信され発行状況が発行済に更新された後に、携帯端末によって受信されたデータの書込みのための携帯端末による書込処理サーバとの通信が切断された場合であっても、携帯端末によって処理状況がデータ受信済に更新されているため、発行操作が改めて受付けられたときに、再度、発行要求情報が発行処理サーバに送信されることなく、データの書込みの要求が書込処理サーバに送信される。このため、発行処理サーバが発行済のデータに対して再度、携帯端末から送信された発行要求情報が、発行処理サーバで受付けられなくなることを防止することができる。その結果、書込処理サーバとの通信が切断された場合であっても、再度行なった発行操作に基づいて確実にデータを書込むことができる。

（４−１） 従来、電子マネーの流通状況と利用履歴を把握でき、ユーザカードと１対１に対応したマネー口座を管理するイシュア（電子マネーの発行組織体（団体、企業等））サーバがあった（たとえば、特開２００６−８５７２３号公報（第００３２段落））。このようなイシュアサーバによれば、マネー口座から、現在ユーザカードにどの位の電子マネーが記憶され、あるいは利用されているかを把握できるようにされていた。複数の店舗で共通に利用できる電子マネーにおいては、不正を行なおうとする者にとっては、単一店舗限定の電子マネーに比べ、利用範囲が広いため、電子マネーのデータのデッドコピーなどの複製をすることによるメリットが大きいことから不正対象として狙われやすく、不正は集団で行なわれることも考えられる。しかし、特開２００６−８５７２３号公報に記載の技術では、集団による不正が行なわれていることまでは判断できないといった問題があった。

しかし、本発明は次のような構成を含む。つまり、複数の店舗において利用可能な記録媒体に記憶されている電子マネーの利用履歴として、電子マネーが利用された店舗の店舗識別情報と、利用された利用日と利用時刻と、利用された記録媒体の記録媒体識別情報とを対応付けて管理する利用履歴管理手段を有する利用状況管理装置であって、複数の前記店舗の所在地域を特定可能な所在地情報を管理する所在地情報管理手段と、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報に基づいて、当該利用履歴の利用時刻が異常であるか否かを判定する利用履歴判定手段と、該利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報を報知する異常記録媒体報知手段とを備える。このように構成しているため、不正の疑いのある記録媒体を抽出することが可能である。

具体的には、図４５の残高管理ＡＰ２１４のステップＳ２９２および図６で説明したように、利用状況管理装置（たとえば、電子マネー管理サーバ２００）のデータ処理部２１０および記憶部２２０によって、複数の店舗（たとえば、遊技場３０）において利用可能な記録媒体（たとえば、携帯電話１００）に記憶されている電子マネー（たとえば、バリュー）の利用履歴として、電子マネーが利用された店舗の店舗識別情報（たとえば、店舗ＩＤ）と、利用された利用日（たとえば、利用日）と利用時刻（たとえば、利用時刻）と、利用された記録媒体の記録媒体識別情報（たとえば、携帯端末情報）とが対応付けて管理される。図４７で説明したように、記憶部２２０の店舗ＤＢによって、複数の店舗の所在地域を特定可能な所在地情報（たとえば、住所、最寄駅、または、郵便番号）が管理される。図４６のステップＳ２０８３からステップＳ２１８３まで、図５５のステップＳ２０８３からステップＳ２１８３ａまで、および、図５６のステップＳ２０８３ａからステップＳ２１８３ｂまでで説明したように、データ処理部２１０によって、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における利用履歴それぞれの店舗識別情報で示される店舗について管理されている所在地情報に基づいて、当該利用履歴の利用時刻が異常であるか否かが判定される。図４６および図５５のステップＳ２１８４、ならびに、図５６のステップＳ２１８４ｂで説明したように、データ処理部２１０によって、利用履歴が異常であると判定されたこと（たとえば、ステップＳ２１８３、ステップＳ２１８３ａまたはステップＳ２１８３ｂでＹＥＳの場合）を条件として、当該利用履歴の記録媒体識別情報が報知される。これにより、利用状況管理装置によって、利用履歴が異常であると判定された記録媒体、つまり、不正の疑いのある記録媒体の記録媒体識別情報が報知される。その結果、不正の疑いのある記録媒体を抽出することができる。

（４−２） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記利用履歴判定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報に基づいて、先に利用された店舗から後に利用された店舗に到着する推定到着時刻を特定する到着時刻特定手段と、前記対象利用履歴のうち後に利用された店舗の利用履歴の利用時刻が、前記到着時刻特定手段によって特定された推定到着時刻より前であるか否かを判定する利用時刻判定手段とを含み、該利用時刻判定手段によって後に利用された店舗の利用履歴の利用時刻が推定到着時刻より前であると判定されたことを条件として、当該利用履歴が異常であると判定する。具体的には、図４６のステップＳ２０８３からステップＳ２１８２までで説明したように、データ処理部２１０によって、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について管理されている所在地情報に基づいて、先に利用された店舗から後に利用された店舗に到着する推定到着時刻（たとえば、推定到着時刻）が特定される。図４６のステップＳ２１８３で説明したように、データ処理部２１０によって、対象利用履歴のうち後に利用された店舗の利用履歴の利用時刻が、特定された推定到着時刻より前であるか否かが判定され、後に利用された店舗の利用履歴の利用時刻が推定到着時刻より前であると判定されたこと（たとえば、ステップＳ２１８３でＹＥＳの場合）を条件として、当該利用履歴が異常であると判定される。これにより、所在地情報に基づいて、後に利用された店舗の利用履歴の利用時刻が後の店舗への推定到着時刻より前であるか否かが効率よく確実に判断できる。その結果、効率よく確実に不正の疑いのある記録媒体を抽出することができる。

（４−３） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記到着時刻特定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報に基づいて、先に利用された店舗の所在地から後に利用された店舗の所在地までの推定移動時間を特定し、特定した推定移動時間を先に利用された店舗の利用履歴の利用時刻に加算することにより、推定到着時刻を特定する。具体的には、図４６のステップＳ２０８３からステップＳ２１８１までで説明したように、データ処理部２１０によって、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について管理されている所在地情報に基づいて、先に利用された店舗の所在地から後に利用された店舗の所在地までの推定移動時間が特定される。図４６のステップＳ２１８２で説明したように、データ処理部２１０によって、特定された推定移動時間が先に利用された店舗の利用履歴の利用時刻に加算されることにより、推定到着時刻が特定される。このように、所在地情報に基づいて、後に利用された店舗への推定到着時刻が効率よく確実に特定される。その結果、さらに効率よく確実に不正の疑いのある記録媒体を抽出することができる。

（４−４） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記利用履歴判定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つ異なるの店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報で特定される所在地域間の推定移動時間を特定する移動時間特定手段と、前記対象利用履歴の利用時刻差が、前記移動時間特定手段によって特定された推定移動時間より短いか否かを判定する利用時刻差判定手段とを含み、該利用時刻差判定手段によって対象利用履歴の利用時刻差が推定移動時間より短いと判定されたことを条件として、当該対象利用履歴が異常であると判定する。具体的には、図５５のステップＳ２０８３からステップＳ２１８１ａまでで説明したように、データ処理部２１０によって、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について管理されている所在地情報で特定される所在地域間の推定移動時間（たとえば、推定移動時間）が特定される。図４６のステップＳ２１８３ａで説明したように、データ処理部２１０によって、対象利用履歴の利用時刻差が、特定された推定移動時間より短いか否かが判定され、対象利用履歴の利用時刻差が推定移動時間より短いと判定されたこと（たとえば、ステップＳ２１８３ａでＹＥＳの場合）を条件として、当該対象利用履歴が異常であると判定される。このように、所在地情報に基づいて、対象利用履歴の利用時刻差が推定移動時間より短いか否かが効率よく確実に判断できる。その結果、効率よく確実に不正の疑いのある記録媒体を抽出することができる。

（４−５） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記利用履歴判定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ利用履歴それぞれの店舗識別情報で示される店舗が３つ以上あることを条件として、利用が連続する２つの店舗における利用履歴だけでなく、利用が連続しない２つの店舗における利用履歴についても、利用履歴が異常であるか否かを判定する。具体的には、図５６のステップＳ２０８３ａからステップＳ２１８３ｂまでで説明したように、データ処理部２１０によって、管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ利用履歴それぞれの店舗識別情報で示される店舗が３つ以上あることを条件として、利用が連続する２つの店舗における利用履歴だけでなく、利用が連続しない２つの店舗における利用履歴についても、利用履歴が異常であるか否かが判定される。このように、連続しない２つの店舗（たとえば、Ａ店およびＣ店）における利用履歴の間の利用履歴（たとえば、Ａ店、Ｂ店およびＣ店の順で利用履歴があるときのＢ店における利用履歴）が異常である場合であっても、当該連続しない２つの店舗における利用履歴が異常であるか否かが判定できる。その結果、不正の疑いのある記録媒体を洩れなく抽出することができる。

（４−６） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記利用履歴判定手段は、前記対象利用履歴のうち先に利用された店舗での最終の利用履歴と後に利用された店舗での最初の利用履歴とについて、利用履歴が異常であるか否かを判定する。具体的には、図４６および図５５のステップＳ２０８３からステップＳ２０８６までの処理によって、対象利用履歴のうち先に利用された店舗での最終の利用履歴と後に利用された店舗での最初の利用履歴とが抽出され、ステップＳ２１８１からステップＳ２１８３までの処理、および、ステップＳ２１８１ａからステップＳ２１８３ａまでの処理によって、当該２つの利用履歴について異常であるか否かが判断される。また、図５６のステップＳ２０８３ａからステップＳ２１８３ｂまでの処理によって、対象利用履歴のうち先に利用された店舗での最終の利用履歴と後に利用された店舗での最初の利用履歴とについて、利用履歴が異常であるか否かが判断される。このように、対象利用履歴のうち先に利用された店舗での最終の利用履歴と後に利用された店舗での最初の利用履歴とについて、利用履歴が異常であるか否かが判定される。このため、それぞれの店舗のすべての利用履歴について利用履歴が異常であるか否かを判定する場合と比較して、効率よく、利用履歴が異常であるか否かを判定することができる。

（４−７） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報で示される記録媒体での電子マネーの利用を停止させるための利用停止情報を各店舗に送信する利用停止情報送信手段をさらに備える。具体的には、図４６、図５５および図５６のステップＳ２１８５で説明したように、データ処理部２１０によって、利用履歴が異常であると判定されたこと（たとえば、ステップＳ２１８３、ステップＳ２１８３ａおよびステップＳ２１８３ｂでＹＥＳの場合）を条件として、当該利用履歴の記録媒体識別情報で示される記録媒体での電子マネーの利用を停止させるための利用停止情報が各店舗に送信される。これにより、利用状況管理装置によって、各店舗において、不正の疑いのある記録媒体での電子マネーの利用を停止させることができる。その結果、不正の疑いのある記録媒体を用いた電子マネーの不正利用の被害の拡大を防止することができる。

（５−１） 従来、次のような遊技用システムがあった（たとえば、特開２００４−５７７００号公報（第００４１段落、第００４２段落、第００４６段落から第００５０段落まで、第００５９段落、第００６１段落、第００６２段落、第００９０段落、第００９１段落、第００９４段落および第００９７段落））。この遊技用システムにおいて、携帯電話に記憶されるプリペイドＩＤが、遊技媒体（たとえば、パチンコ玉やスロットマシンのコイン）の貸出ユニットに設けられた赤外線通信ユニットに送信されると、貸出ユニットは、受信したプリペイドＩＤを使用要求として管理コンピュータに送信する。管理コンピュータは、受信したプリペイドＩＤからプリペイド度数を抽出し、該抽出したプリペイド度数を貸出ユニットに返信すると共に、該プリペイドＩＤに対応する使用状態を「待機」から「使用中」に更新する。貸出ユニットは、返信されたプリペイド度数により貸出処理を行なうと共に、管理コンピュータに対して貸出処理の都度、プリペイド度数の更新要求を送る。それに伴ない、管理コンピュータは、プリペイド度数を減算する。プリペイド度数が残存する状態で終了ボタンが入力されると、貸出ユニットは、プリペイドＩＤを管理コンピュータに送信する。管理コンピュータは、該プリペイドＩＤに対応する使用状態を「使用中」から「待機」に更新する。管理コンピュータは、使用状態として「使用中」が登録されているプリペイドＩＤに対する使用要求が貸出ユニットより送信されると使用不可を返信する。これにより、同一プリペイドＩＤの重複使用を回避している。また、携帯電話を電子マネー端末のリーダライタ部にかざす（または置く）ことによりバリューのチャージおよび決済を行なうシステムがあった（たとえば、特開２００４−２７２５６０号公報（第００９３段落および第００９４段落））。しかし、特開２００４−５７７００号公報に記載の技術のように、携帯電話による貸出が従来のカードによる貸出と同様な方法であれば、携帯電話を貸出ユニット内に受付けっ放しにはしないものの、使用開始から終了までの間、当該貸出ユニットにより「使用中」であると管理コンピュータは認識しているため、重複使用を回避できる。重複使用をさせないのは、同じプリペイドＩＤが１以上存在することは無いシステムにも拘わらず、該プリペイドＩＤの状態が「使用中」のときに該プリペイドＩＤに対する使用要求があるということは、該プリペイドＩＤが複製（偽造）されている可能性が高いためである。このため、そのようなプリペイドＩＤを検出する必要がある。また、特開２００４−２７２５６０号公報に記載の技術のように、携帯電話による貸出方法を、貸出の度に携帯電話と貸出ユニットとを通信させることで貸出を行なう方法にすると、使用状態を「使用中」と「待機」とに切替える訳ではないので、特許文献１に記載の技術のように重複使用の判断をすることができない。このため、不正の疑いのある携帯電話などの記録媒体を抽出することができないといった問題があった。

しかし、本発明は次のような構成を含む。つまり、記録媒体に記録されている電子マネーの利用履歴として、電子マネーが利用された取引装置の取引装置識別情報と、利用された利用時刻と、利用された記録媒体の記録媒体識別情報とを対応付けて管理する利用履歴管理手段を有する利用状況管理装置であって、前記利用履歴管理手段によって管理されている利用履歴のうち、取引装置識別情報が異なり記録媒体識別情報が同じで利用が連続する２つの取引装置における利用履歴の利用時刻差が、予め設定された基準時間未満であるか否かを判定することによって、当該利用履歴が異常であるか否かを判定する店舗利用履歴判定手段と、該利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報を報知する異常記録媒体報知手段とを備える。このように構成しているため、不正の疑いのある記録媒体を抽出することが可能である。

具体的には、図５１のステップＳ８３１で説明したように、利用状況管理装置（たとえば、店舗サーバ８００）のデータ処理部によって、記録媒体（たとえば、携帯電話１００）に記録されている電子マネー（たとえば、バリュー）の利用履歴として、電子マネーが利用された取引装置（たとえば、券売機３００，カードユニット６００）の取引装置識別情報（たとえば、装置ＩＤ）と、利用された利用時刻（たとえば、利用時刻）と、利用された記録媒体の記録媒体識別情報（たとえば、携帯端末情報）とが対応付けて管理される。図５１のステップＳ８３４で説明したように、店舗サーバ８００のデータ処理部によって、管理されている利用履歴のうち、取引装置識別情報が異なり記録媒体識別情報が同じで利用が連続する２つの取引装置における利用履歴の利用時刻差が、予め設定された基準時間未満（たとえば、１分３０秒以内，取引装置の位置関係に対応して予め定められた時間未満）であるか否かが判定されることによって、当該利用履歴が異常であるか否かが判定される。図５１のステップＳ８４３で説明したように、店舗サーバ８００のデータ処理部によって、利用履歴が異常であると判定されたこと（たとえば、ステップＳ８３４でＹＥＳの場合）を条件として、当該利用履歴の記録媒体識別情報が報知される。これにより、利用状況管理装置によって、利用履歴が異常であると判定された記録媒体、つまり、不正の疑いのある記録媒体の記録媒体識別情報が報知される。その結果、不正の疑いのある記録媒体を抽出することができる。

（５−２） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記店舗利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の取引装置識別情報で示される各々の取引装置の配置が、前記基準時間未満の時間で前記記録媒体を共用可能な配置であるか否かを判定する取引装置配置判定手段と、該取引装置配置判定手段によって前記取引装置が記録媒体を共用可能な配置であると判定されたことを条件として、その旨を報知する配置報知手段とを備える。具体的には、図５１のステップＳ８３５で説明したように、店舗サーバ８００のデータ処理部によって、利用履歴が異常であると判定されたこと（たとえば、ステップＳ８３４でＹＥＳの場合）を条件として、当該利用履歴の取引装置識別情報で示される各々の取引装置の配置が、基準時間未満の時間で記録媒体を共用可能な配置であるか否かが判定される。図５１のステップＳ８３６で説明したように、店舗サーバ８００のデータ処理部によって、取引装置が携帯電話１００を共用可能な配置であると判定されたこと（たとえば、ステップＳ８３５でＹＥＳの場合）を条件として、その旨が報知される。これにより、記録媒体を共有可能な配置である２つの取引装置で記録媒体が共有されている場合は、たとえば、夫婦間や友人間での記録媒体の貸し借りの可能性もあるので、不正の疑いのある記録媒体の記録媒体識別情報の報知とは別報知を行なうことができる。その結果、正当な利用に対して不当な嫌疑をかけないようにすることができるので、利用者に不快感を与えないようにすることができる。

（５−３） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記店舗利用履歴判定手段は、さらに、前記利用履歴管理手段によって管理されている利用履歴のうち、所定時間内において、取引装置識別情報および記録媒体識別情報が同じで利用が連続しない利用履歴が、２組以上あるか否かを判定することによって、当該利用履歴が異常であるか否かを判定する。具体的には、図５１のステップＳ８４１およびステップＳ８４２で説明したように、店舗サーバ８００のデータ処理部によって、管理されている利用履歴のうち、所定時間内において、取引装置識別情報および記録媒体識別情報が同じで利用が連続しない利用履歴が、２組以上あるか否かが判定されることによって、当該利用履歴が異常であるか否かが判定される。これにより、取引装置識別情報が異なり記録媒体識別情報が同じで利用が連続する２つの取引装置における利用履歴の利用時刻差が予め設定された基準時間以上となるように、数台の取引装置で順次、記録媒体識別情報が同じ不正な記録媒体が用いられる場合であっても、利用履歴が異常であると判定することができる。その結果、不正の疑いのある記録媒体の抽出の確実性を向上させることができる。

（５−４） また、本発明は、次のような構成を含むようにしてもよい。つまり、前記店舗利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の取引装置識別情報で示される取引装置を特定可能な情報を出力する取引装置情報出力手段をさらに備える。具体的には、図５１のステップＳ８４４で説明したように、店舗サーバ８００のデータ処理部によって、利用履歴が異常であると判定されたこと（たとえば、ステップＳ８３４でＹＥＳの場合）を条件として、当該利用履歴の取引装置識別情報で示される取引装置を特定可能な情報が出力される。これにより、出力された情報で示される取引装置の利用者を撮影する制御を行なったり、当該取引装置を係員に報知して確認させたりできる。その結果、不正の疑いのある記録媒体の取締りを強化することができる。

［第２の実施の形態］
第１の実施の形態においては、電子マネー管理サーバ２００およびリモート発行サーバ４００が、別々の業者に備えられる場合について説明した。第２の実施の形態においては、電子マネー管理サーバ２００およびリモート発行サーバ４００が、同じ業者に備えられる場合について説明する。

なお、第２の実施の形態においては、リモート発行サーバ４００が電子マネー管理サーバ２００に含まれる、つまり、電子マネー管理サーバ２００およびリモート発行サーバ４００が１台のコンピュータで構成される場合について説明する（この場合には、該１台のコンピュータが、本発明の発行書込処理サーバを構成する）が、これに限定されず、電子マネー管理サーバ２００の利用者情報ＤＢ２２１および発行情報ＤＢ２２２にリモート発行サーバ４００が直接アクセスできるなど、電子マネー管理サーバ２００およびリモート発行サーバ４００が電子マネーに関するＤＢを共有できるのであれば、電子マネー管理サーバ２００およびリモート発行サーバ４００は、別々のコンピュータで構成されるようにしてもよい。

本第２の実施の形態のように、電子マネー管理サーバ２００とリモート発行サーバ４００とを一体に構成した場合には、第１の実施の形態の図１２で示した初回起動処理、図１８で示したバリュー発行時処理、図２０で示したバリュー預け処理および図２１で示したバリュー返却処理において、非接触型ＩＣチップ１９０の記憶部１９２に電子マネー遊技使用サービス用の記憶領域を構築したり、バリューを書込んだり、電子マネー遊技使用サービス用の記憶領域を削除したりするために、携帯電話１００とリモート発行サーバ４００との間で行なわれていた処理が、すべて電子マネー管理サーバ２００との間で行なわれることになる。以下においては、本発明に特に関連するバリュー発行時の処理と、携帯電話１００の記憶部１２０にて管理される処理状況の更新に失敗した場合のエラー対応処理とを説明する。

図５７は、第２の実施の形態における携帯電話１００により実行される電子マネーアプリ１１１のサブルーチンであるバリュー発行時処理の流れを示すフローチャートである。

図５７を参照して、ステップＳ１５２で、データ処理部１１０は、バリュー発行要求情報を、電子マネー管理サーバ２００に送信する。ここで、バリュー発行要求情報は、図１８と異なり、バリューのチャージ（発行）を要求するための情報であるとともに非接触型ＩＣチップ１９０の記憶部１９２の電子マネー遊技使用サービス用の記憶領域にバリューを書込むための書込処理を開始させるための情報であって会員ＩＤおよび携帯端末情報を含む情報である。つまり、図５７のバリュー発行要求情報は、図１８のバリュー発行要求情報（バリューの発行を要求するための発行要求情報）と書込処理開始要求情報（バリューの書込みを要求する書込要求情報）とを含む情報である。

図５８は、第２の実施の形態における電子マネー管理サーバ２００により実行されるバリュー発行時アプリケーションプログラムの処理の流れを示すフローチャートである。

図５８を参照して、まず、ステップＳ２７１で、データ処理部２１０は、携帯電話１００からバリュー発行要求情報を受信したことによって、バリュー発行要求があったか否かを判断する。バリュー発行要求がないと判断した場合（ステップＳ２７１でＮＯの場合）、データ処理部２１０は、実行する処理をステップＳ２７１に戻す。

一方、バリュー発行要求があったと判断した場合（ステップＳ２７１でＹＥＳの場合）、ステップＳ２７２で、データ処理部２１０は、ステップＳ２７１で受信したバリュー発行要求情報に含まれる会員ＩＤおよび携帯端末情報が利用者情報ＤＢ２１１に登録された利用可能なものであるか否かを判断する。利用可能なものでないと判断した場合（ステップＳ２７２でＮＯの場合）、ステップＳ２７３で、データ処理部２１０は、使用不可画面を携帯電話１００に送信する。使用不可画面は、図３０（ｃ）で説明した画面と同様の画面である。

一方、利用可能なものであると判断した場合（ステップＳ２７２でＹＥＳの場合）、ステップＳ２７４で、データ処理部２１０は、会員ＩＤおよび携帯端末情報に対応する未チャージバリューが発行情報ＤＢ２２２に記憶されているか否かを判断する。未チャージバリューがないと判断した場合（ステップＳ２７４でＮＯの場合）、ステップＳ２７５で、データ処理部２１０は、未チャージバリュー無画面を携帯電話１００に送信する。未チャージバリュー無画面は、図３４（ｃ）で説明したので重複する説明は繰返さない。

未チャージバリューがあると判断した場合（ステップＳ２７４でＹＥＳの場合）、チャージ要求時に未チャージバリューがあると判断した場合（ステップＳ２４４でＹＥＳの場合）、および、残高移行依頼時に未チャージバリューがあると判断した場合（ステップＳ２０６４でＹＥＳの場合）、ステップＳ２７９３で、データ処理部２１０は、書込処理を実行する。

具体的には、データ処理部２１０は、電子マネーアプリ１１１を介さずに、バリュー発行要求に含まれる携帯端末情報で示される携帯電話１００の非接触型ＩＣチップ１９０と直接やり取りして、非接触型ＩＣチップ１９０の記憶部１９２に、発行情報ＤＢ２２２に記憶された未チャージバリューを書込む。

つまり、電子マネー管理サーバ２００は、非接触型ＩＣチップ１９０の制御部１９１に対して未チャージバリュー（発行バリュー）の書込みを指示し（書込指示情報を送信し）、これに応じて、制御部１９１が非接触型ＩＣチップ１９０の記憶部１９２にバリューの書込みを行なう（つまり、制御部１９１がデータ書込実行手段を構成する）。この場合、記憶部１９２の電子マネー遊技使用サービス用の記憶領域に既にバリューが記憶されているときには、既に記憶されているバリューに発行バリューを加算した額のバリューを書込む処理が行なわれるが、かかる処理も発行バリューの書込みに該当する。

つまり、第２の実施の形態においては、図５７のステップＳ１５２でバリューの発行を要求するバリュー発行要求情報とバリューの書込みを要求するバリュー書込要求情報とを兼ねるバリュー発行要求情報が携帯電話１００から電子マネー管理サーバ２００に対して送信されてくるため、電子マネー管理サーバ２００は、図５８のステップＳ２７９３で携帯電話１００に対してバリューを発行する（送信する）処理を行なうとともに、当該発行したバリューを非接触型ＩＣチップ１９０の記憶部１９２に書込むための書込指示情報を送信する処理とを併せて行なうものである。

以上のように、本実施の形態においては、電子マネーアプリ１１１を介することなく、電子マネー管理サーバ２００の指示に応じて非接触型ＩＣチップ１９０の制御部１９１が発行バリューの書込みを行なうように構成したが、これに限定されず、電子マネー管理サーバ２００から書込指示情報を受信したことに応じて、電子マネーアプリ１１１が制御部１９１に発行バリューの書込みを指示するようにしてもよい。

そして、ステップＳ２７９４で、データ処理部２１０は、バリューの書込みが終了したか否かを判断する。終了していないと判断した場合（ステップＳ２７９４においてＮＯの場合）、データ処理部２１０は、ステップＳ２７９４の処理を繰返す。一方、終了したと判断した場合（ステップＳ２７９４においてＹＥＳの場合）、ステップＳ２７９５で、データ処理部２１０は、書込終了情報を携帯電話１００に送信する。

また、ステップＳ２７９６で、データ処理部２１０は、書込みが終了したバリューと対応付けて図５に示す発行情報ＤＢ２２２に記憶されている当該バリューの処理状況（書込状況）を、書込終了済に更新する。その後、データ処理部２１０は、実行する処理をステップＳ２７１の処理に戻す。

図５７に戻って、データ処理部１１０は、ステップＳ１５７ｂで、電子マネー管理サーバ２００から書込終了情報を受信したことによって、書込処理が終了したか否かを判断する。書込処理が終了したと判断した場合（ステップＳ１５７ｂでＹＥＳの場合）、ステップＳ１５７ａで、データ処理部１１０は、記憶部１２０で管理している処理状況を、書込済に更新する。ステップＳ１５７ａ以降の処理は、図１８で説明したので重複する説明は繰返さない。

図５９は、第２の実施の形態における電子マネー管理サーバ２００によって実行されるエラー対応処理の流れを示すフローチャートである。図５９を参照して、第１の実施の形態においては、処理状況の不整合のエラーに対応する処理をオペレータが行なうようにした。第２の実施の形態のおいては、処理状況の不整合のエラーに対応する処理を、エラー対応処理として電子マネー管理サーバ２００が行なう場合について説明する。なお、エラー対応処理は、電子マネー遊技使用サービスの提供機関のサーバで実行されるのであれば、電子マネー管理サーバ２００で実行されることに限定されない。

図５９を参照して、まず、電子マネー遊技使用サービスの提供業者のオペレータは、電話や電子メール等で、ユーザからのエラー問合せを受信した場合、ユーザに携帯電話１００の電子メールアドレスを問合せ、ユーザの携帯電話１００の電子メールアドレスを取得する。

次に、オペレータは、取得したユーザの携帯電話１００の電子メールアドレス宛に、エラー対応開始メールを送信するように、電子マネー管理サーバ２００を操作する。

この操作に応じて、電子マネー管理サーバ２００のデータ処理部２１０は、ステップＳ２９１１で、ユーザの携帯電話１００の電子メールアドレス宛に、エラー対応開始メールを送信する。エラー対応開始メールには、エラーについて説明するエラー説明ページのＵＲＬが添付される。

エラー対応開始メールに含まれるエラー説明ページへのリンクが操作されると、データ処理部１１０は、エラー説明ページへのリンク先のＵＲＬで示される電子マネー管理サーバ２００に、エラー説明画面を取得するためのエラー説明画面取得要求を送信する。

電子マネー管理サーバ２００のデータ処理部２１０は、ステップＳ２９１２で、携帯電話１００からエラー説明画面取得要求があったか否かを判断する。エラー説明画面取得要求を受信していないと判断した場合（ステップＳ２９１２においてＮＯの場合）、データ処理部２１０は、ステップＳ２９１２の処理を繰返す。一方、エラー説明画面取得要求を受信したと判断した場合（ステップＳ２９１２においてＹＥＳの場合）、ステップＳ２９１３で、データ処理部２１０は、エラー説明画面をエラー説明画面取得要求元の携帯電話１００に送信する。

携帯電話１００のデータ処理部１００は、電子マネー管理サーバ２００からエラー説明画面を取得し、表示部１４０に表示する。エラー説明画面には、エラーについての説明が記載されるとともに、電子マネーアプリ１１１を起動させるために操作されるリンク情報が含まれており、当該リンク情報が選択操作されることにより、データ処理部１１０は、電子マネーアプリ１１１を起動させる。そして、図１１で前述したステップＳ１１０１の処理が実行されることにより、バリュー残高などの非接触型ＩＣチップ１９０の記憶部１９２の記憶内容および記憶部１２０で管理されている処理状況が電子マネー管理サーバ２００に送信される。

電子マネー管理サーバ２００のデータ処理部２１０は、ステップＳ２９１４で、ユーザの携帯電話１００から非接触型ＩＣチップ１９０の記憶内容および処理状況を受信したか否かを判断する。非接触型ＩＣチップ１９０の記憶内容および処理状況を受信していないと判断した場合（ステップＳ２９１４においてＮＯの場合）、データ処理部２１０は、ステップＳ２９１４の処理を繰返す。

一方、非接触型ＩＣチップ１９０の記憶内容を受信したと判断した場合（ステップＳ２９１４においてＹＥＳの場合）、ステップＳ２９１６で、データ処理部２１０は、ステップＳ２９１４で受信したユーザの携帯電話１００の記憶部１２０で管理されていた処理状況および非接触型ＩＣチップ１９０の記憶内容であるバリュー残高と、発行情報ＤＢ２２２に記憶された当該携帯電話１００に書込んだバリューの処理状況および図５の発行情報ＤＢ２２２に記憶されたバリュー残高とを比較する。そして、処理状況が不一致でないと判断した場合（ステップＳ２９１７ａにおいてＮＯの場合）、処理状況の不一致に対する処理を行なう必要がないので、データ処理部２１０は、実行する処理をステップＳ２９１１の処理に戻す。

処理状況が不一致であり（ステップＳ２９１７ａにおいてＹＥＳであり）、かつ、バリュー残高が一致しないと判断した場合（ステップＳ２９１７ｂにおいてＮＯの場合）、バリューの書込みが行なわれていない可能性があり、オペレータによるエラーに対する対応が必要であるために、ステップＳ２９１７ｃで、データ処理部２１０は、処理状況およびバリュー残高が携帯電話１００と電子マネー管理サーバ２００とで不一致である旨を表示部２４０に表示させることによってオペレータに報知する。

そして、ステップＳ２９１７ｄで、データ処理部２１０は、オペレータによって確認操作がデータ入力部２３０から入力されたか否かを判断する。確認操作がないと判断した場合（ステップＳ２９１７ｄにおいてＮＯの場合）、データ処理部２１０は、ステップＳ２９１７ｄの処理を繰返す。一方、確認操作があったと判断した場合（ステップＳ２９１７ｄにおいてＹＥＳの場合）、データ処理部２１０は、実行する処理をステップＳ２９１１の処理に戻す。

処理状況が不一致であり（ステップＳ２９１７ａにおいてＹＥＳであり）、かつ、バリュー残高が一致すると判断した場合（ステップＳ２９１７ｂにおいてＹＥＳの場合）、バリューは書込まれたが処理状況の書込済への更新には失敗したこととなるので、処理状況を強制的に更新させるために、ステップＳ２９１８で、データ処理部２１０は、ユーザの携帯電話１００に、エラー対応完了メールを送信する。このエラー対応完了メールには、電子マネーアプリ１１１を起動させ処理状況をクリアさせるためのリンクが添付される。ステップＳ２９１８の後、データ処理部２１０は、実行する処理をステップＳ２９１１の処理に戻す。

なお、ここでは、バリューの処理状況およびバリュー残高を比較するようにしたが、これに限定されず、バリュー残高は比較せずにバリューの処理状況のみを比較するようにしてもよい。

そして、かかるエラー対応完了メールを受信した携帯電話１００において、当該エラー対応完了メールに添付されたリンク情報が選択操作されると、電子マネーアプリ１１１が起動され、図１１に示す処理のステップＳ１１１０においてＹＥＳの判断がなされ、ステップＳ１１１１以降の処理が実行され記憶部１２０の処理状況がクリアされる。ステップＳ１１１からの処理については前述した図１１で説明したので重複する説明は繰返さない。

このように、データ処理部１１０は、本実施の形態における更新指示情報である前記エラー対応完了メールを受信し、当該エラー対応完了メールに添付されたリンク情報が操作されたことを条件として、さらには当該リンク情報の操作が初回であることを条件として、記憶部１２０にて管理している処理状況を強制的に更新する処理状況強制更新処理を実行する。また、図１１に示して説明した通り、この処理状況強制更新処理（ステップＳ１１１３）は、更新指示情報としてのエラー対応完了メールに添付されたリンク情報が操作されたことを条件として実施され、電子マネーアプリ１１１の初期画面等からは実行できないため、ユーザの過誤等により処理状況の更新が実施されるおそれがない。さらに、この処理状況強制更新処理は、リンク操作が初回であることを条件として実行されるため、携帯電話１００に保存されている電子メールのリンク情報をユーザの過誤等により複数回操作された場合にも、２回目以降の操作時には処理状況が更新されてしまうおそれがない。

また、電子マネー管理サーバ２００では、ステップＳ２７９６で説明したように、書込処理の終了を条件として、処理状況が書込終了済に更新され、携帯電話１００では、ステップＳ１５７ａで説明したように、書込処理の実行を条件として、処理状況が書込済に更新される。しかし、バリューが書込まれたときに携帯電話１００側で処理状況の書込済への更新に失敗した場合であっても、ステップＳ２９１８およびステップＳ１１１３で説明したように、電子マネー管理サーバ２００からの指示で強制的に処理状況が更新される。その結果、バリューの書込みに関し携帯電話１００と電子マネー管理サーバ２００との処理状況の不一致を解消し、その後の処理の不都合を解消することができる。

また、ステップＳ２９１４からステップＳ２９１８までで説明したように、電子マネー管理サーバ２００によって携帯電話１００から取得された処理状況に基づいた処理が実行される。このため、処理状況が電子マネー管理サーバ２００で確認された上で必要な処理が実行されるようにすることができる。

また、ステップＳ２９１６からステップＳ２９１８までで説明したように、電子マネー管理サーバ２００によって、携帯電話１００と電子マネー管理サーバ２００との処理状況が一致するか否かが判断され、一致しないと判断されたことを条件として、携帯電話１００の処理状況をクリアさせるためのエラー対応完了メールが送信される。このため、オペレータによる確認作業等の手間を省くことができる。

また、ステップＳ２９１８、ステップＳ１１１０およびステップＳ１１１３で説明したように、電子マネー管理サーバ２００によって、エラー対応完了メールが送信され、エラー対応完了メールに添付されたリンク情報が操作されることを条件として、処理状況がクリアされるので、電子マネー管理サーバ２００側での処理が終了し、処理状況の更新が可能となったことをユーザに確実に認識させることができるとともに、処理状況の更新のためのユーザの操作負担も軽減させることができる。また、電子マネー管理サーバ２００からエラー対応完了メールが送信されることなく携帯電話１００での処理状況の更新が行なわれないようにすることができるので、ユーザの誤操作や悪用によって処理状況が強制的に更新されないようにすることができる。

また、ステップＳ１１１１およびステップＳ１１１３で説明したように、携帯電話１００によって、リンク情報の操作が初回か否かが判定され、初回であると判定されたことをさらに条件として、処理状況がクリアされるので、ユーザの過誤等によりリンク情報が複数回操作されても、その度に処理状況が更新されないようにすることができる。

次に前述した実施の形態の変形例を挙げる。
（１） 前述した実施の形態においては、ステップＳ２６９で決済サーバ２８０から消込速報を受信したことを条件として、電子マネー管理サーバ２００は、バリューの購入に対する決済が終了したと判断して、ステップＳ２７７でバリュー発行情報を携帯電話１００に送信するようにした。すなわち、決済用処理として、金融機関に対するバリューの購入に対する対価の決済を行なうための処理を例に説明した。

しかし、決済用処理としては、これに限定されるものではない。たとえば、決済用処理としては、クレジットカードの提供機関に対するバリューの購入に対する対価の決済のために与信の可否の判断において与信可との結果を得る処理であってもよい。具体的には、クレジットカードによる与信でバリューを購入できるようにして、実際の決済は済んでいなくても、バリュー発行情報を携帯電話１００に送信するようにしてもよい。バリュー購入時処理において、電子マネー管理サーバ２００または携帯電話１００にクレジットカードの提供機関、カード番号等を記憶させておき、電子マネー管理サーバ２００がクレジットカードの提供機関、カード番号等を読出してまたは携帯電話１００から取得して、当該提供機関に与信の可否を問合せ、与信可の返信があれば図１７に示すバリュー対価決済後処理を行ない、発行情報ＤＢ２２２への未チャージバリュー等の登録処理を行なうようにすればよい。

（２） 前述した実施の形態においては、所定時間ごとに券売機３００から店舗サーバ８００を介して電子マネー管理サーバ２００に取引情報が送信されるようにした。このため、電子マネー管理サーバ２００で管理されている携帯電話１００のバリュー残高は常に正確である訳ではない。したがって、バリューが携帯電話１００から電子マネー管理サーバ２００に預けられるときには、ステップＳ１６０２で携帯電話１００から電子マネー管理サーバ２００にバリュー残高が送信されるようにした。そして、電子マネー管理サーバ２００は、ステップＳ２１６３で携帯電話１００から送信されたバリュー残高を預かり残高として記憶するようにした。

しかし、これに限定されず、リアルタイムで券売機３００から電子マネー管理サーバ２００に取引情報が送信されるようにして、バリューが携帯電話１００から電子マネー管理サーバ２００に預けられるときに、電子マネー管理サーバ２００で管理されている携帯電話１００のバリュー残高を預かり残高として記憶するようにしてもよい。この場合には、ステップＳ１７０２で送信する残高返却依頼情報にはバリュー残高を含めないようにしてもよい。また、同様に、ステップＳ２５１においては、ステップＳ１３３で送信するチャージ要求情報に含まれるバリュー残高に基づき携帯上保持限度額を判定しているが、リアルタイムで電子マネー管理サーバ２００に取引情報が送信される場合、ステップＳ１３３においてバリュー残高を含まないチャージ要求情報に送信するようにしてもよい。

（３） 前述した実施の形態においては、ステップＳ１７０２で預かり番号を含まない残高返却依頼情報を送信するようにして、ステップＳ１７０６で預かり番号を送信するようにした。しかし、これに限定されず、ステップＳ１７０２で残高返却依頼情報を送信しないようにして、ステップＳ１７０６で預かり番号を含む残高依頼情報を送信するようにしてもよい。

（４） 前述した実施の形態においては、バリューが携帯電話１００から電子マネー管理サーバ２００に預けられるときに未チャージバリューがある場合（ステップＳ２０６４においてにＹＥＳの場合）は、一旦、未チャージバリューが携帯電話１００にチャージされてから、携帯電話１００のバリュー残高が預かり残高として記憶されるようにした。

しかし、これに限定されず、バリューが携帯電話１００から電子マネー管理サーバ２００に預けられるときに、電子マネー管理サーバ２００が、携帯電話１００から受取ったバリュー残高と未チャージバリューの額とを加算して、加算した額を預かり残高として記憶するようにしてもよい。

（５） 前述した実施の形態においては、ステップＳ２１７７でバリュー残高と預かり残高を加算した額が携帯上保持限度額より多いと判断された場合に、ステップＳ２１７８で携帯上保持限度額返却不可画面を送信して、預かり残高を返却しないようにした。しかし、これに限定されず、預かり残高のうち、バリュー残高と加算した額が携帯上保持限度額を超えない分を返却して、残りの分を未チャージバリューとするようにしてもよい。

（６） 本実施の形態においては、図９に示す初期登録時ＡＰ２１１のステップＳ２３６において領域確保情報が携帯電話１００に送信されることで、携帯電話１００の記憶部１９２に電子マネー遊技使用サービス用の記憶領域が構築（確保）されることから、当該領域確保情報の送信に先立ってステップＳ２３５において未チャージ削除カウンタを１加算することにより、携帯電話１００の記憶部１９２に電子マネー遊技使用サービス用の記憶領域が構築された構築回数を加算・管理し、ステップＳ２１６で未チャージ削除カウンタの値が３に達しているか否かを判定し、達していれば領域構築情報の送信を禁止するようにしているが、これに限らず、たとえばステップＳ２１６での判定対象とする回数を１回とするような場合には、未チャージ削除カウンタにおいて回数を計数するのではなく、ステップＳ２３６で領域構築情報が送信されることに関連して領域構築済を示すフラグを立てて、図１７に示すバリュー対価決済後処理のステップＳ２７０３において当該フラグを削除することで、領域構築対価の決済が終了しているか否かを管理し、ステップＳ２１６において当該フラグが立っているか否かを判定し、フラグが立っていれば領域構築対価の決済が未終了であるとして領域構築情報の送信を禁止するようにしてもよい。

また、本実施の形態においては、すべての携帯電話１００について未チャージ削除カウンタを管理しているが、領域構築対価の決済用処理が未終了の携帯電話１００の携帯端末情報のみを登録するデータベースを別途設け、当該データベースにおいて未チャージ削除カウンタを管理してもよい。

（７） 前述した実施の形態においては、サービス提供用サーバとして電子マネー管理サーバ２００、および決済サーバ２８０を例にして説明した。しかし、サーバに限らず、ネットワークを介して複数のコンピュータを結ぶことで仮想的に構築されるコンピュータであるグリッドコンピューティングシステムであってもよい。

（８） 前述した第１の実施の形態においては、電子マネー管理サーバ２００のデータ処理部によって、図１６のステップＳ２６８で、モバイルバンキングへの引継をユーザに確認するためのモバイルバンキング遷移確認画面を表示させるための引継画面情報が携帯電話１００に送信され、携帯電話１００のデータ処理部１１０によって、図１０（ｂ）のステップＳ１１７で、電子マネー管理サーバ２００から引継画面情報が受信されたことに応じて、ステップＳ１１８，Ｓ１１８ａでモバイルバンキングに遷移しモバイルバンキング処理が行なわれ、決済が行なわれるようにした。つまり、携帯電話１００と電子マネー管理サーバ２００との接続が一旦分断され、決済のために携帯電話１００から金融機関サーバ５００にアクセスし、その後、再度、電子マネー管理サーバ２００にアクセスして電子マネー情報の書込みを行なうようにした。

しかし、これに限定されず、電子マネー管理サーバ２００によって、ステップＳ２６８で引継画面情報が送信されることに替えて、携帯電話１００から電子マネー管理サーバ２００を介して、金融機関サーバ５００で決済が行なえるようにしてもよい。このようにすることで、携帯電話１００と金融機関サーバ５００とが決済のやり取りをする場合に分断してしまう携帯電話１００と電子マネー管理サーバ２００との接続を保ったまま、決済のやり取りを行なうことができるようになり、その後の電子マネー情報の携帯電話１００への書込みまでの処理を一連の処理として行なうことができる。

（９） 前述した実施の形態においては、電子マネーシステム１０は、遊技場３０に設置される装置、携帯電話１００、電子マネー管理サーバ２００、決済サーバ２８０、リモート発行サーバ４００、および、金融機関サーバ５００で構成されるようにした。

しかし、これに限定されず、電子マネー管理サーバ２００に、決済サーバ２８０、リモート発行サーバ４００、および、金融機関サーバ５００の全部または一部の機能が含まれるようにして、電子マネーシステム１０が、遊技場３０に設置される装置、携帯電話１００、および、電子マネー管理サーバ２００で構成されるようにしてもよい。

（１０） 前述した実施の形態では、電子マネーシステム１０の発明として説明した。しかし、これに限定されず、携帯電話１００、電子マネー管理サーバ２００、決済サーバ２８０、券売機３００、カードユニット６００、および、店舗サーバ８００の装置の発明として捉えることができる。

また、電子マネーアプリ１１１、初期登録時ＡＰ２１１、バリュー購入時ＡＰ２１２、バリュー発行時ＡＰ２１３、残高管理ＡＰ２１４、バリュー預かりＡＰ２１５、および、バリュー返却ＡＰ２１５のプログラムの発明として捉えることができる。

さらに、携帯電話１００、電子マネー管理サーバ２００、決済サーバ２８０、券売機３００、カードユニット６００、および、店舗サーバ８００の装置でそれぞれ行なわれる処理を処理方法の発明として捉えることができる。

（１１） 前述した実施の形態では、電子マネー遊技使用サービスの提供業者に対価を支払うためにユーザが利用する金融機関のサーバとして、金融機関ごとにそれぞれ金融機関サーバ５００が設けられている例について説明した。しかし、これに限らず、ユーザが利用する金融機関のサーバとしては、複数の金融機関からなるグループ用に設けられた共通の金融機関サーバであってよい。この場合、同じグループに属する金融機関を利用する場合には、異なる金融機関を利用する場合であっても、当該グループ用に設けられた共通の金融機関サーバと通信し対価の支払いが行なわれる。また、対価を支払うために利用するためのサーバとしては、金融機関のサーバに限らず、ユーザが登録した金融機関サーバと通信し対価の支払いを代行する代行業者のサーバであってもよい。つまり、これらの場合にも、金融機関のサーバに含まれる。

（１２） 前述した第１の実施の形態においては、携帯電話１００のデータ処理部１１０によって図１０のステップＳ１１２で金融機関指定情報が送信されたことに応じて、電子マネー管理サーバ２００のデータ処理部２１０によって、図９のステップＳ２２４で、金融機関指定情報が利用者情報ＤＢ２２１に登録されるようにした。

しかし、金融機関指定情報は新規会員登録時に登録されることに限定されず、他のタイミングで登録されるようにしてもよい。たとえば、バリューの初回購入時に登録されるようにしてもよいし、電子マネーアプリのメインメニューに金融機関を登録するためのメニューを設けて、遊技者の携帯電話１００からの金融機関指定情報の登録の要求があったときに登録されるようにしてもよい。

なお、金融機関変更処理が行なわれるタイミングについても同様である。前述した実施の形態においては、バリュー購入時処理において金融機関変更処理が行なわれる、すなわちバリュー購入時に金融機関を変更できる例について説明したが、これに限らず、金融機関変更処理が行なわれるタイミングは他のタイミングで変更されるようにしてもよいし、電子マネーアプリのメインメニューに金融機関を変更するためのメニューを設けて、遊技者の携帯電話１００からの金融機関指定情報の変更の要求があったときに変更されるようにしてもよい。

（１３） 前述した実施の形態においては、プリペイドカード３７１に残額を示す情報が記録されるようにした。しかし、これに限定されず、プリペイドカード３７１にはカードＩＤのみ記録しておき、店舗サーバ８００などのサーバで、カードＩＤに対応させて残額を示す情報を管理しておき、プリペイドカード３７１を発行したり、プリペイドカード３７１に入金したり、プリペイドカード３７１から残額を減算したりする場合に、店舗サーバ８００とやり取りするようにしてもよい。

（１４） 前述した実施の形態では、情報端末の一例として携帯電話１００について説明したが、これに限らず、ユーザが操作する情報端末であればどのようなものであってもよい。たとえば、情報端末として、ＰＤＡ（Personal Digital Assistance）、パーソナルコンピュータ、テレビ受信機、カーナビ等であってもよい。また、取引の一例としてバリュー対価決済後処理によりステップＳ２７０４においてバリュー購入記録を更新するもの（すなわちバリューの購入）について説明したが、これに限らず、商品や株式等の引渡を受ける場合には、当該引渡に対する請求金額の一部または全部について支払済みにするもの等であってもよい。すなわち、売買の行為が成立する場合に、当該売買行為で発生する請求金額の一部または全部について支払済みにするものであればどのようなものであってもよい。この場合、たとえば、情報端末から出力する取引要求情報としては、商品や株式等の引渡を希望する旨の情報が該当する。情報端末は、当該情報をサーバに出力すると通信先指定情報を受信する。また、情報端末は、当該通信先指定情報により指定される金融機関のサーバに対し、商品や株式等の引渡を受けるために必要な金額分の決済を要求する旨の決済要求情報を送信する。そして、サーバは、当該決済要求情報を受信した金融機関のサーバにおいて決済の終了を条件として、商品や株式等の引渡に対する請求金額が支払われた旨を記録等する処理を取引処理として行なう。かかる取引処理が行なわれた後、係員等がサーバの記録内容を確認し、商品の発送等を行なうこととなる。

（１５） 携帯電話１００の非接触型ＩＣチップ１９０にバリューがチャージされたとき、および、バリューの減算が完了したときに、非接触型ＩＣチップ１９０の記憶部１９２に記憶されたバリュー残高のバックアップが記憶部１２０にされるようにしてもよい。

また、携帯電話１００によってユーザからバックアップ操作の入力が受付けられたときに、バックアップがされるようにしてもよい。

また、携帯電話１００によって前回バックアップがされてから所定期間（たとえば、３時間、１日など）経過するごとに、バックアップがされるようにしてもよい。

（１６） 前述した実施の形態においては、当日に購入されたバリューの積算額を当日積算額として積算するようにした。しかし、これに限定されず、所定期間（たとえば、午前６時から翌日の午前６時までの期間）に購入されたバリューの積算額を積算するようにしてもよい。つまり、所定期間は、状況に応じて適宜設定変更可能とすればよい。

（１７） 前述した実施の形態においては、図４５の残高管理ＡＰ２１４によって、それぞれの会員ＩＤごとに不正回数の頻度に応じて、不正に対する処理を行なうようにした。しかし、これに限定されず、すべての携帯電話での不正回数を合計した回数の頻度に応じて、不正に対する処理を行なうようにしてもよい。

（１８） ステップＳ２８１で説明したように、取引額がチャージ累計額を超えているか否かにより不正取引の発生を判断して、チャージ累計額を超えた不正取引があった場合、ステップＳ２８４で説明したように、不正取引を行なった会員ＩＤの携帯ＩＤの不正な携帯電話１００で購入されたプリペイドカード３７１の使用を禁止するような電子マネーシステムであってもよい。

また、ステップＳ２８１で説明したように、取引額がチャージ累計額を超えているか否かにより不正取引の発生を判断して、チャージ累計額を超えた不正取引があった場合、ステップＳ２８６で説明したように、不正取引を行なった会員ＩＤの携帯ＩＤの不正な携帯電話１００のバリューの使用を禁止するような電子マネーシステムであってもよい。

また、ステップＳ２８１で説明したように、取引額がチャージ累計額を超えているか否かにより不正取引の発生を判断して、チャージ累計額を超えた不正取引があった場合、ステップＳ２８９で説明したように、不正取引が発生したホール（遊技場）でのすべての携帯電話でのバリューの使用を禁止するような電子マネーシステムであってもよい。

（１９） 前述した実施の形態では、電子マネー管理サーバ２００の残高管理ＡＰ２１４から店舗サーバ８００を介して送信されてきた携帯使用禁止情報および不正端末記憶情報に基づき、券売機３００のデータ処理部３１０は、記憶部３２０に携帯使用禁止情報および不正端末情報を記憶させる。そして、券売機３００において、プリペイドカード３７１の購入に使用されている携帯電話１００の携帯ＩＤが記憶部３１０に記憶されている不正端末情報でないか、または記憶部３１０に携帯使用禁止情報が記憶されていないかが判断され、記憶されているときに取引不能にする。すなわち、前述した実施の形態では、券売機３００において、不正取引であるか否か判断され、不正取引であると判断されたときに取引不能にする制御を行なう例について説明した。

しかし、これに限らず、店舗サーバ８００において、不正取引であるか否か判断され、不正取引であると判断されたときに取引不能である旨を示す取引不能信号を券売機３００に送信し、券売機３００において取引不能信号を受信したときに取引不能にする制御が行なわれるようにしてもよい。たとえば、店舗サーバ８００のデータ処理部は、電子マネー管理サーバ２００の残高管理ＡＰ２１４からの携帯使用禁止情報および不正端末記憶情報を、店舗サーバ８００の記憶部に記憶させる。一方、券売機３００のデータ処理部３１０は、取引が行なわれる毎に、取引に用いられる携帯電話１００の携帯ＩＤを店舗サーバ８００に送信する。店舗サーバ８００のデータ処理部は、送信されてきた当該携帯ＩＤが記憶部に記憶されている不正端末情報でないか、または記憶部に携帯使用禁止情報が記憶されていないかが判断され、記憶されているときに取引不能にする旨を示す取引不能信号を当該券売機３００に送信する。券売機３００のデータ処理部３１０は、取引不能信号に基づき、取引不能にする制御を行なう。

また、電子マネー管理サーバ２００の残高管理ＡＰ２１４から店舗サーバ８００に送信されてきた不正媒体情報に基づき、店舗サーバ８００のデータ処理部は、当該不正媒体情報に含まれる携帯ＩＤに対応して記憶部に記憶されているカードＩＤを不正カードＩＤとしてカードユニット６００に送信し、カードユニット６００の記憶部６２０に記憶させる。そして、カードユニット６００において、球貸に使用されているプリペイドカードのカードＩＤが記憶部６２０に記憶されている不正カードＩＤでないかが判断され、不正カードＩＤであるときに球貸不能にする。すなわち、前述した実施の形態では、カードユニット６００において、不正取引であるか否か判断され、不正取引であると判断されたときに球貸不能にする制御を行なう例について説明した。

しかし、これに限らず、店舗サーバ８００において、不正取引であるか否か判断され、不正取引であると判断されたときに球貸不能である旨を示す球貸不能信号をカードユニット６００に送信し、カードユニット６００において球貸不能信号を受信したときに球貸不能にする制御が行なわれるようにしてもよい。たとえば、店舗サーバ８００のデータ処理部は、電子マネー管理サーバ２００の残高管理ＡＰ２１４から店舗サーバ８００に送信されてきた不正媒体情報に基づき、当該不正媒体情報に含まれる携帯ＩＤに対応して記憶部に記憶されているカードＩＤを不正カードＩＤとして店舗サーバ８００の記憶部に記憶させる。一方、カードユニット６００のデータ処理部６１０は、球貸しが行なわれる毎に、球貸しに用いられるプリペイドカードのカードＩＤを店舗サーバ８００に送信する。店舗サーバ８００のデータ処理部は、送信されてきた当該カードＩＤが記憶部に記憶されている不正カードＩＤでないかが判断され、記憶されているときに球貸不能にする旨を示す球貸不能信号を当該カードユニット６００に送信する。カードユニット６００のデータ処理部６１０は、球貸不能信号に基づき、球貸不能にする制御を行なう。

（２０） 電子マネーのチャージに関する対価の決済のための決済用処理としては、金融機関サーバ５００が提供するモバイルバンキングを利用した振込処理や、クレジットカード機関サーバが提供する与信による処理に限らず、本実施の形態における電子マネー管理サーバ２００が提供するバリューとは異なる電子マネー等を使用して決済を行なう処理であってもよい。また、本実施の形態においては、携帯電話１００と金融機関サーバ５００が通信することにより決済用処理が行なわれたが、このように携帯電話１００を使用するものに限らず、ユーザが電子マネー提供機関の口座に現金振込を行なうことにより決済が行なわれ、当該振込の行なわれた金融機関のサーバから電子マネー管理サーバ２００に対して消込速報が通知されるようにしてもよい。

（２１） 第１の実施の形態におけるバリュー購入に関する処理においては、ユーザから購入希望金額を受付ける前に、図１６に示すバリュー購入時ＡＰ２１２のステップＳ２５１においてバリュー残高と最低購入金額との合計額が携帯上保持限度額以下か否かを判定するとともに、ステップＳ２５３において同日積算額と最低購入金額との合計金額が１日購入限度額以下か否かを判定し、両判定がＹＥＳの場合にさらに購入可能金額を算出して表示金額リスト情報とともに携帯電話１００に対して送信することで、携帯電話１００においては、表示金額リストのうち購入可能金額以下の選択肢のみが指定可能な態様で表示された。このようにすることは、ユーザに限度額を超過する無駄な選択操作をさせることがないことから好ましいが、これに限らず、ユーザに購入希望金額を先に選択させて、当該購入希望金額を電子マネー管理サーバ２００に送信し、バリュー残高と購入希望金額との合計額が携帯上保持限度額以下か否かを判定するとともに、当日積算額と購入希望金額との合計額が１日購入限度額以下か否かを判定するようにしてもよい。

（２２） 本実施の形態においては、図１７に示すバリュー対価決済後処理において当日積算額を加算更新している、つまり図１６に示すステップＳ２５１、Ｓ２５３において携帯上保持限度額あるいは１日購入限度額以下でありチャージを許容すると判定された電子マネーの額を当日積算額に加算して管理しているが、これに限らず、図１９に示すバリュー発行時ＡＰ２１３におけるステップＳ２７７のバリュー発行情報送信に関連して、つまり携帯電話１００に対してバリュー発行情報が送信されたバリューの額を当日積算額に加算して管理するようにしてもよい。

（２３） 本実施の形態においては、預かり残額を識別するための預かり残額識別情報として、電子マネー管理サーバ２００側において発行される預かり番号と遊技者から入力を受付けるパスワードの２種類の識別情報を使用しているが、これに限らず、いずれか一方のみでもよい。また、預かり番号やパスワードに限られず、預かり残額を識別可能な識別情報であればどのような形式のものであってもよい。

（２４） 本実施の形態においては、初期登録処理、バリュー購入処理、バリュー発行処理、バリュー預け処理、およびバリュー返却処理において、種々の情報が複数回に分けて携帯電話１００と電子マネー管理サーバ２００との間で送受信されているが、各情報を処理のどの段階で何回に分けて送信するかといったことは、実施の形態に限られるものではなく、適宜変更可能である。

たとえば、バリュー購入処理において、携帯電話１００から電子マネー管理サーバ２００に対して、チャージ要求情報、第１口座振替依頼情報および第２口座振替依頼情報が送信されるが、予め購入希望金額の選択を受付けるような場合には、第１口座振替依頼情報を送信することなく、購入希望金額を含むチャージ要求情報を送信すればよいし、合計金額の確認を受付けない場合には、第２口座振替依頼情報を送信することなく、第１口座振替依頼情報に対して引継ぎ画面情報を返信するようにしてもよい。一方、電子マネー管理サーバ２００から携帯電話１００に対しては、表示金額リスト等を含む残高情報がチャージ受付情報として返信されるとともに、合計金額確認情報および引継ぎ画面情報が送信されるが、表示金額リスト等とは別個にチャージ受付情報を送信してもよいし、合計金額確認情報を送信することなく引継ぎ画面情報を送信してもよい。

（２５） 本実施の形態においては、携帯電話１００を個々に識別するための識別情報として予め携帯電話１００に付与されている携帯端末情報（携帯ＩＤ）と電子マネー遊技使用サービスに会員登録することにより発行される会員ＩＤとを使用しているが、これに限らず、いずれか一方のＩＤのみを使用してもよいし、種類によって使用するＩＤを使い分けてもよい。

（２６） 本実施の形態の携帯電話１００においては、初期登録処理、バリュー発行処理、バリュー預け処理およびバリュー返却処理における処理状況を、記憶部１２０に設けた１つの処理状況を各処理において共通に更新するようにした。しかし、これに限定されるものではなく、たとえば、バリューを重複して購入できるような場合には、図６０に示す各バリューごとに処理状況（発行状況）を管理し、初期登録処理、バリュー預け処理およびバリュー返却処理における処理状況については、図示していないが発行状況とは別に記憶・管理するようにしてもよい。図６０で示すＤＢは、バリューの購入番号、購入したバリューの額、および、処理状況を対応付けて記憶する。たとえば、購入番号が「９００１０８０１」および「９０００５５８７」であるバリューの額は、それぞれ「１０００」円および「５０００」円であり、処理状況は、それぞれ「発行情報受信済」および「書込済」である。

（２７） 本実施の形態においては、データとして電子マネーを例にとり説明したが、データの種類は特に限定されるものではなく、たとえば、所定の会員登録を行なうことにより発行処理サーバから発行される会員ＩＤをデータとして携帯端末の記憶部に書込むものであってもよいし、発行処理サーバから発行されるポイント情報をデータとして書込むものであってもよい。

（２８） 本実施の形態においては、削除処理において、電子マネー（データ）とともに、電子マネー記憶領域も削除するものであったが、これに限定されるものではなく、電子マネー記憶領域を削除することなく、電子マネーのみを削除するものであってもよい。

（２９） 本実施の形態においては、図１１のステップＳ１１１３において処理状況をクリアして更新するようにしたが、これに限定されず、処理状況を書込済等、対応する処理が終了したことを示す状態に更新するものであってもよい。

（３０） 本実施の形態においては、電子マネー（電子マネー記憶領域）の削除がバリュー預け処理において実施される例について説明したが、これに限定されず、たとえば、電子マネーアプリ初期画面に「領域削除」のメニューを設けておき、当該メニューが操作されることにより、領域（データ）を削除する処理のみが行なわれるようにしてもよい。

（３１） 第１の実施の形態においては、携帯電話１００における処理状況とリモート発行サーバ４００における書込状況の比較をオペレータが実施したが、これに限定されず、電子マネー管理サーバ２００がリモート発行サーバ４００から書込状況を取得し、携帯電話１００から取得した処理状況と比較を行なうようにしてもよい。

（３２） 本実施の形態においては、電子マネー管理サーバ２００と店舗サーバ８００とを別体として構成した。しかし、これに限定されず、電子マネー管理サーバ２００が、店舗サーバ８００で行なわれる処理を行なうように構成してもよい。

（３３） 本実施の形態においては、複数の店舗において利用可能で電子マネーを記憶した記録媒体は、携帯電話１００であることとした。しかし、これに限定されず、このような記録媒体は、プリペイドカード３７１やＩＣカードのようなカードであってもよい。

（３４） 本実施の形態においては、図４６および図５５で説明したように、携帯端末情報および利用日が同じで店舗ＩＤが異なり利用時刻が連続する２つの利用履歴について利用履歴が異常であるか否かを判断するようにした。しかし、これに限定されず、携帯端末情報および利用日が同じで店舗ＩＤが異なる利用履歴の組合せについてたすき掛けで利用履歴が異常であるか否かを判断するようにしてもよい。

（３５） 本実施の形態においては、図５１で説明したように、店舗利用履歴判定手段によって、装置ＩＤが異なり携帯端末情報が同じで利用が連続する２つの取引装置における利用履歴の利用時刻差が、予め設定された基準時間未満であるか否かを判定することによって、当該利用履歴が異常であるか否かを判定した後に、利用履歴が異常であると判定されたことを条件として、取引装置配置判定手段によって、当該利用履歴の装置ＩＤで示される各々の取引装置の配置が、基準時間未満の時間で携帯電話１００を共用可能な配置であるか否かを判定するようにした。

しかし、これに限定されず、取引装置配置判定手段によって、装置ＩＤが異なり携帯端末情報が同じで利用が連続する２つの取引装置における利用履歴の装置ＩＤで示される各々の取引装置の配置が、予め設定された基準時間未満の時間で携帯電話１００を共用可能な配置であるか否かを判定した後に、取引装置が携帯電話１００を共用可能な配置でないと判定されたことを条件として、店舗利用履歴判定手段によって、当該利用履歴の利用時刻差が基準時間未満であるか否かを判定することによって、当該利用履歴が異常であるか否かを判定するようにしてもよい。これにより、取引装置が携帯電話１００を共用可能な配置である場合には、利用履歴が異常であるか否かを判定しないようにすることができる。その結果、さらに効率よく、不正の疑いのある携帯電話１００を抽出することができる。

（３６） 本実施の形態においては、図５１のステップＳ８３６で説明したように、取引装置が携帯電話１００を共用可能な配置である場合には、その旨を報知するようにした。しかし、これに限定されず、取引装置が携帯電話１００を共用可能な配置である場合に、その旨を報知しないようにしてもよい。

（３７） 今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

本発明に係る電子マネーシステムの構成の一例を示すブロック図である。 本発明に係る携帯電話の構成の一例を示すブロック図である。 本発明に係る電子マネー管理サーバの構成の一例を示すブロック図である。 本実施の形態における電子マネー管理サーバが電子マネー遊技使用サービスを提供する際に用いる利用者情報データベースを説明するための図である。 本実施の形態における電子マネー管理サーバが電子マネー遊技使用サービスを提供する際に用いる発行情報データベースを説明するための図である。 本実施の形態における電子マネー管理サーバが電子マネー遊技使用サービスを提供する際に用いる取引情報データベースを説明するための図である。 本発明に係る券売機の構成の一例を示すブロック図である。 本実施の形態におけるカードユニットの構成の一例を示すブロック図である。 本実施の形態における電子マネー管理サーバにより実行される初期登録時アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における携帯電話のウェブブラウザ機能により実行されるウェブ処理の流れを示すフローチャートである。 本実施の形態における携帯電話で実行される電子マネーアプリの処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである初回起動処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるＩＣチップ起動処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである処理状況確認処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー購入時処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー購入時アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー購入時アプリケーションプログラムのサブルーチンであるバリュー対価決済後処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー発行時処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー発行時アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー預け処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー預かりアプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー返却処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー返却アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第１の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第２の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第３の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第４の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第５の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第６の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第１の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第２の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第３の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第４の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話にバリューをチャージするときに携帯電話の表示部に表示される第１の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話から電子マネー管理サーバにバリューを預けるときに携帯電話の表示部に表示される第１の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話から電子マネー管理サーバにバリューを預けるときに携帯電話の表示部に表示される第２の表示画面図である。 本実施の形態における電子マネーシステムにおいて電子マネー管理サーバに預けたバリューの返却を受けるときに携帯電話の表示部に表示される第１の表示画面図である。 本実施の形態における電子マネーシステムにおいて電子マネー管理サーバに預けたバリューの返却を受けるときに携帯電話の表示部に表示される第２の表示画面図である。 本実施の形態における券売機で実行される発券処理の流れを示すフローチャートである。 本実施の形態における券売機で実行される不正登録処理の流れを示すフローチャートである。 本実施の形態における電子マネーシステムにおいて券売機から携帯電話の電子マネーアプリが起動されるときに携帯電話の表示部に表示される第１の表示画面図である。 本実施の形態におけるカードユニットで実行される球貸処理の流れを示すフローチャートである。 本実施の形態におけるカードユニットで実行されるプリペイド球貸処理の流れを示すフローチャートである。 本実施の形態におけるカードユニットで実行されるユニット不正登録処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行される残高管理アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行される残高管理アプリケーションプログラムのサブルーチンである履歴判定処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバに記憶される店舗データベースを説明するための図である。 本実施の形態における電子マネー管理サーバに記憶される店舗データベースに含まれる店舗の位置を示す地図である。 本実施の形態における電子マネー管理サーバの取引情報データベースの利用履歴が異常である場合を説明するための図である。 本実施の形態における店舗サーバで実行される店舗サーバ処理の流れを示すフローチャートである。 本実施の形態における店舗サーバにより実行される店舗サーバ処理のサブルーチンである店舗履歴判定処理の流れを示すフローチャートである。 本実施の形態における遊技場に設置されるカードユニット、パチンコ遊技機および座席のレイアウトを示す図である。 本実施の形態における店舗サーバの店舗内取引情報データベースの利用履歴が異常である場合を説明するための第１の図である。 本実施の形態における店舗サーバの店舗内取引情報データベースの利用履歴が異常である場合を説明するための第２の図である。 本実施の形態における電子マネー管理サーバにより実行される残高管理アプリケーションプログラムのサブルーチンである履歴判定処理の第１の変形例の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行される残高管理アプリケーションプログラムのサブルーチンである履歴判定処理の第２の変形例の流れを示すフローチャートである。 第２の実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー発行時処理の流れを示すフローチャートである。 第２の実施の形態における電子マネー管理サーバにより実行されるバリュー発行時アプリケーションプログラムの処理の流れを示すフローチャートである。 第２の実施の形態における電子マネー管理サーバによって実行されるエラー対応処理の流れを示すフローチャートである。 本実施の形態の変形例における携帯電話の記憶部に記憶されるデータベースを説明するための図である。

符号の説明

１０ 電子マネーシステム、３０，３０Ａ〜３０Ｃ 遊技場、１００ 携帯電話、１１０ データ処理部、１１１ 電子マネーアプリ、１２０ 記憶部、１３０ データ入力部、１４０ 表示部、１５０ 音声入出力部、１６０ 無線通信部、１６１ アンテナ、１９０ 非接触型ＩＣチップ、１９１ 制御部、１９２ 記憶部、１９３ 非接触通信部、１９４ アンテナ、２００ 電子マネー管理サーバ、２１０ データ処理部、２１１ 初期登録時ＡＰ、２１２ バリュー購入時ＡＰ、２１３ バリュー発行時ＡＰ、２１４ 残高管理ＡＰ、２１５ バリュー預かりＡＰ、２１６ バリュー返却ＡＰ、２２０ 記憶部、２２１ 利用者情報ＤＢ、２２２ 発行情報ＤＢ、２２４ 取引情報ＤＢ、２３０ データ入力部、２４０ 表示部、２６０ 通信部、２８０ 決済サーバ、３００ 券売機、３１０ データ処理部、３２０ 記憶部、３３０ 操作部、３４０ 表示部、３６０ 通信部、３７０ カードリーダライタ、３７１ プリペイドカード、３８０ 貨幣処理機、３９０ チップリーダライタ、３９１ 制御部、３９２ 記憶部、３９３ 非接触通信部、３９４ アンテナ、４００ リモート発行サーバ、５００ 金融機関サーバ、６００，６００Ａ〜６００Ｕ カードユニット、６１０ データ処理部、６２０ 記憶部、６３１ 球貸ボタン、６３２ 返却ボタン、６４０ 表示部、６６０ 通信部、６７０ カードリーダライタ、６８０ 貨幣処理機、６９０ チップリーダライタ、６９１ 制御部、６９２ 記憶部、６９３ 非接触通信部、６９４ アンテナ、７００，７００Ａ〜７００Ｕ パチンコ遊技機、７１０Ａ〜７１０Ｕ 座席、８００ 店舗サーバ。

Claims (13)

1. 複数の店舗において利用可能な記録媒体に記憶されている電子マネーの利用履歴として、電子マネーが利用された店舗の店舗識別情報と、利用された利用日と利用時刻と、利用された記録媒体の記録媒体識別情報とを対応付けて管理する利用履歴管理手段を有する利用状況管理装置であって、
   複数の前記店舗の所在地域を特定可能な所在地情報を管理する所在地情報管理手段と、
   前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報に基づいて、当該利用履歴の利用時刻が異常であるか否かを判定する利用履歴判定手段と、
   該利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報を報知する異常記録媒体報知手段とを備えることを特徴とする、利用状況管理装置。
2. 前記利用履歴判定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報に基づいて、先に利用された店舗から後に利用された店舗に到着する推定到着時刻を特定する到着時刻特定手段と、前記対象利用履歴のうち後に利用された店舗の利用履歴の利用時刻が前記到着時刻特定手段によって特定された推定到着時刻より前であるか否かを判定する利用時刻判定手段とを含み、該利用時刻判定手段によって後に利用された店舗の利用履歴の利用時刻が推定到着時刻より前であると判定されたことを条件として、当該利用履歴が異常であると判定することを特徴とする、請求項１に記載の利用状況管理装置。
3. 前記到着時刻特定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報に基づいて、先に利用された店舗の所在地から後に利用された店舗の所在地までの推定移動時間を特定し、特定した推定移動時間を先に利用された店舗の利用履歴の利用時刻に加算することにより、推定到着時刻を特定することを特徴とする、請求項２に記載の利用状況管理装置。
4. 前記利用履歴判定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ２つの異なる店舗における対象利用履歴それぞれの店舗識別情報で示される店舗について前記所在地情報管理手段によって管理されている所在地情報で特定される所在地域間の推定移動時間を特定する移動時間特定手段と、前記対象利用履歴の利用時刻差が、前記移動時間特定手段によって特定された推定移動時間より短いか否かを判定する利用時刻差判定手段とを含み、該利用時刻差判定手段によって対象利用履歴の利用時刻差が推定移動時間より短いと判定されたことを条件として、当該対象利用履歴が異常であると判定することを特徴とする、請求項１に記載の利用状況管理装置。
5. 前記利用履歴判定手段は、前記利用履歴管理手段によって管理されている利用履歴のうち、記録媒体識別情報および利用日が同じ利用履歴それぞれの店舗識別情報で示される店舗が３つ以上あることを条件として、利用が連続する２つの店舗における利用履歴だけでなく、利用が連続しない２つの店舗における利用履歴についても、利用履歴が異常であるか否かを判定することを特徴とする、請求項１から請求項４までのいずれかに記載の利用状況管理装置。
6. 前記利用履歴判定手段は、前記対象利用履歴のうち先に利用された店舗での最終の利用履歴と後に利用された店舗での最初の利用履歴とについて、利用履歴が異常であるか否かを判定することを特徴とする、請求項１から請求項５までのいずれかに記載の利用状況管理装置。
7. 前記利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報で示される記録媒体での電子マネーの利用を停止させるための利用停止情報を各店舗に送信する利用停止情報送信手段をさらに備えることを特徴とする、請求項１から請求項６までのいずれかに記載の利用状況管理装置。
8. 請求項１から請求項６までのいずれかに記載の利用状況管理装置と、複数の店舗に設置され、前記記録媒体に記憶されている電子マネーを用いて取引処理を実行する取引処理実行手段を有する取引装置と、当該取引装置での電子マネーの利用情報を前記利用状況管理装置に送信する利用情報送信手段を有する取引装置管理装置とを含む電子マネーシステムであって、
   前記利用履歴管理手段は、前記取引装置管理装置から送信されてきた利用情報で示される店舗識別情報と利用日と利用時刻と記録媒体識別情報とを利用履歴として管理することを特徴とする、電子マネーシステム。
9. 前記利用状況管理装置は、さらに、
   前記利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報で示される記録媒体での電子マネーの利用を停止させるための利用停止情報を前記取引装置管理装置に送信する利用停止情報送信手段を備え、
   前記取引装置管理装置は、さらに、
   前記利用状況管理装置から送信されてきた前記利用停止情報を受信したことを条件として、前記取引装置における前記利用停止情報で示される記録媒体での電子マネーの利用を停止させるための利用停止処理を実行する利用停止処理実行手段を備えることを特徴とする、請求項８に記載の電子マネーシステム。
10. 記録媒体に記録されている電子マネーの利用履歴として、電子マネーが利用された取引装置の取引装置識別情報と、利用された利用時刻と、利用された記録媒体の記録媒体識別情報とを対応付けて管理する利用履歴管理手段を有する利用状況管理装置をさらに備え、
    前記利用状況管理装置は、さらに、
    前記利用履歴管理手段によって管理されている利用履歴のうち、取引装置識別情報が異なり記録媒体識別情報が同じで利用が連続する２つの取引装置における利用履歴の利用時刻差が、予め設定された基準時間未満であるか否かを判定することによって、当該利用履歴が異常であるか否かを判定する店舗利用履歴判定手段と、
    該店舗利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の記録媒体識別情報を報知する店舗異常記録媒体報知手段とを備えることを特徴とする、請求項９に記載の電子マネーシステム。
11. 前記利用状況管理装置は、さらに、
    前記店舗利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の取引装置識別情報で示される各々の取引装置の配置が、前記基準時間未満の時間で前記記録媒体を共用可能な配置であるか否かを判定する取引装置配置判定手段と、
    該取引装置配置判定手段によって前記取引装置が共用可能な配置であると判定されたことを条件として、その旨を報知する配置報知手段とを備えることを特徴とする、請求項１０に記載の電子マネーシステム。
12. 前記店舗利用履歴判定手段は、さらに、前記利用履歴管理手段によって管理されている利用履歴のうち、所定時間内において、取引装置識別情報および記録媒体識別情報が同じで利用が連続しない利用履歴が、２組以上あるか否かを判定することによって、当該利用履歴が異常であるか否かを判定することを特徴とする、請求項１０または請求項１１に記載の電子マネーシステム。
13. 前記利用状況管理装置は、さらに、
    前記店舗利用履歴判定手段によって利用履歴が異常であると判定されたことを条件として、当該利用履歴の取引装置識別情報で示される取引装置を特定可能な情報を出力する取引装置情報出力手段を備える、請求項１０から請求項１３までのいずれかに記載の電子マネーシステム。

Images