JP4822869B2

JP4822869B2 - 電子マネー情報発行書込システム、発行書込処理サーバ、携帯端末、および、アプリケーションプログラム

Info

Publication number: JP4822869B2
Application number: JP2006048964A
Authority: JP
Inventors: 詔八鵜川; 勉村山
Original assignee: Sankyo Co Ltd
Current assignee: Sankyo Co Ltd
Priority date: 2006-02-24
Filing date: 2006-02-24
Publication date: 2011-11-24
Anticipated expiration: 2026-02-24
Also published as: JP2007226668A

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）にアクセスがあったか否かを判断する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次いで、ステップＳ２７０８で、データ処理部２１０は、ステップＳ２７００で受信した消込速報を正常に処理した旨の応答情報を決済サーバ２８０に送信する。そして、ステップＳ２７０９で、データ処理部２１０は、引継ぎ情報を付した電子メールを、消込速報に対応する会員ＩＤの電子メールアドレス宛に送信する。その後、データ処理部２１０は、バリュー対価決済後処理を終了し、実行する処理をこの処理の呼出元に戻す。引継ぎ情報としては、リンク情報が含まれる。本実施の形態におけるリンク情報には、後述する電子マネーアプリ１１１を自動的に起動させるための情報が含まれている。電子マネーアプリ１１１が起動されると、引継ぎ情報からの起動である（ステップＳ１９１でＹＥＳである）ので、後述する図１７で説明するバリュー発行時処理が実行される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

不正カードＩＤを受信したと判断した場合（ステップＳ６０５でＹＥＳの場合）、データ処理部６１０は、ステップＳ６０６で、不正カードＩＤを記憶部６２０に記憶させる。不正カードＩＤを受信していないと判断した場合（ステップＳ６０５でＮＯの場合）、または、ステップＳ６０６の後、データ処理部６１０は、実行する処理をこのユニット不正登録処理の呼出元の処理である図４１の球貸処理に戻す。一方、不正カードＩＤを受信していないと判断した場合（ステップＳ６０５でＮＯの場合）、データ処理部６１０は、実行する処理を図４１の球貸処理に戻す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図４４を参照して、まず、ステップＳ２９１で、電子マネー管理サーバ２００のデータ処理部２１０は、店舗サーバ８００から取引情報を受信したか否かを判断する。取引情報を受信した場合（ステップＳ２９１でＹＥＳの場合）、データ処理部２１０は、ステップＳ２９２で、取引情報に含まれる携帯ＩＤに対応する会員ＩＤのチャージ累計額から取引情報に含まれる取引額を減算する。

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

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

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

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

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

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

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

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

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

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

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

取引情報の前回送信から所定時間経過したと判断した場合（ステップＳ８１４でＹＥＳの場合）、店舗サーバ８００のデータ処理部は、ステップＳ８１４で、記憶部に記憶された前回送信後の携帯電話１００での取引情報を電子マネー管理サーバ２００に送信する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（３）図１４のバリュー購入時処理に従って、ステップＳ１４０ａにおいて金融機関変更が選択されたと判断した場合、金融機関変更問合せ情報が携帯電話１００から電子マネー管理サーバ２００に送信される。一方、電子マネー管理サーバ２００は、金融機関変更問合せ情報に対応する画面（図２６（ｃ），（ｄ），図２７（ａ）等参照）を携帯電話１００に送信し、携帯電話１００から金融機関指定情報を受信したと判断した場合、変更した金融機関の金融機関指定情報を携帯端末情報に対応させて、利用者情報ＤＢ２２１に登録する処理を行なう。これにより、決済に利用する金融機関を変更することができるため、ユーザの利便性を向上させることができる。

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

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

（５）メールに付された引継ぎ情報を操作することにより、図１７のバリュー発行時処理が起動し、ステップＳ１５２においてバリュー発行要求情報が電子マネー管理サーバ２００に送信されるため、バリューをチャージするための操作負担をより一層軽減させることができる。

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

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

（７）電子マネー管理サーバ２００は、ステップＳ２４４において図５の発行情報ＤＢ２２２の処理状況として「発行済」が記憶されている状態に更新されていないバリュー購入記録が登録されておりＹＥＳと判断された場合に、ステップＳ２４５においてチャージ誘導画面が携帯電話１００に送信された後に、図１８のバリュー発行時処理ＡＰに従って、ステップ２７６〜Ｓ２７７において図５の発行情報ＤＢ２２２の処理状況として「未発行」が記憶されている状態のバリュー購入記録から特定される額のバリューを書込ませるためのバリュー発行情報が携帯電話１００に送信される。このため、未チャージバリューをチャージするための操作を省略でき、ユーザの利便性を向上させることができる。

（８）電子マネー管理サーバ２００が、ステップＳ２６９において金融機関サーバ５００からの消込速報を受信するまでに、ステップＳ２４１において新たなチャージ要求情報を受付けた場合、図５の発行情報ＤＢ２２２において処理状況として「未発行」が記憶されている状態のバリュー購入記録が複数記憶されている状態になる。このような状態であるときに、ステップＳ２４１においてさらにチャージ要求情報を受付けたとき、およびステップＳ２７１においてバリュー発行要求情報を受付けたときに、ステップ２７６〜Ｓ２７７において発行情報ＤＢ２２２に複数記憶されている処理状況として「未発行」が記憶されている状態のバリュー購入記録から特定される額のバリューを書込ませるためのバリュー発行情報が携帯電話１００に送信される。すなわち、一括してバリューをチャージすることができ、ユーザの利便性を向上させることができる。

（９−１）ステップＳ２０６１で携帯電話１００からの残高移行依頼情報を受信したと判断した場合であっても、ステップＳ２０６４で未チャージバリューがあると判断した場合には、以降のバリュー預かり処理が行なわれないようにすることができる。このため、携帯電話１００に加算可能なバリューが電子マネー管理サーバ２００に存在するにもかかわらず、ユーザの過誤等により、携帯電話１００の機種変更が行なわれてしまうことを防止することができる。

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

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

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

（１１）ステップＳ２７０３で説明したように、初期登録手数料が決済されたことを条件に、未チャージ削除カウンタのカウント値を減算する。このため、止むを得なく複数回登録をしなおした場合に、登録後の初回チャージ時に初期登録手数料を決済しているのに、未チャージ削除カウンタのカウント値が所定回数を超えてしまって、電子マネー遊技使用サービス用の記憶領域の確保ができなくなるといった不都合を防止できる。

（１２）前述したように（１１）の所定回数は１回であってもよい。その場合、未チャージ削除カウンタのカウント値を管理しなくても、初期登録手数料の決済が終了しているか否かを示す情報を管理することによって、バリューの購入をせずに電子マネー遊技使用サービス用の記憶領域の確保を繰返すことによって生じる未決済の初期登録手数料を低減させることができる。

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

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

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

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

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

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

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

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

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

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

（１８）図３１（ｂ）で説明したように、表示金額リスト情報に含まれる複数種類の金額のうち、１日購入限度額から当日積算額を減算したステップＳ２５５で算出される購入可能金額以下であって、携帯上保持限度額からバリュー残高を減算したステップＳ２５５で算出される購入可能金額以下の金額の選択肢が指定可能であることをユーザに認識させることができる。すなわち、表示金額リスト情報に含まれる複数種類の金額のうち、１日購入限度額と当日積算額との差額および携帯上保持限度額とバリュー残高との差額の範囲内の金額の選択肢が指定可能であることをユーザに認識させることができる。その結果、ユーザに、購入できない選択肢を選択させてしまうような無駄な操作をさせることを防止することができる。

（１９）ステップＳ２５６で説明したように、チャージ要求情報の送信元の携帯電話が通常用の携帯電話であるかテスト用の携帯電話であるかに応じた複数種類の購入希望金額の選択肢である表示金額リストを示す表示金額リスト情報がチャージ要求情報の送信元の携帯電話に送信され、送信された表示金額リスト情報が示す複数種類の購入希望金額の選択肢が携帯電話の表示部に表示される。このため、携帯上保持限度額や１日購入限度額が変更された場合にも適切な購入希望金額の選択肢をユーザに提供できるとともに、チャージ要求情報の送信元の携帯電話が通常用であるかテスト用であるかに応じた適切な購入希望金額の選択肢を適用できる。

（２０）ステップＳ２１７４で残高移行依頼情報に含まれる携帯端末情報と預かり番号情報に含まれる携帯端末情報とが一致しないと判断したことを条件として、ステップＳ２１７９，Ｓ２２７２で説明したように、預かり残高のバリューを返却するための預かり残高情報および返却実行情報が出力される。このため、残高移行依頼情報の送信元の携帯電話と預かり番号情報の送信元の携帯電話とが同一であるという機種変更が行なわれる場合には本来起こり得ない状況、つまり、不正等の疑いのある状況で、預かり残高のバリューの返却が行なわれてしまうことを防止できる。

（２１）ステップＳ３４５およびステップＳ３４６で説明したように、テスト用の携帯電話の盗難などが発生した場合には、盗まれたテスト用の携帯電話の使用を許可しないように設定しておくことによって、盗まれた携帯電話に記憶されているバリューを用いたプリペイドカード３７１の発券が実行されないようにすることができる。このため、テスト用の携帯電話の盗難などが発生した場合に、盗まれたテスト用の携帯電話の使用を防止できる。

（２２）図３８の発券処理および図４１の球貸処理に従って、それぞれ、ステップＳ３５６およびＳ６５６において特定の種類の電子マネーであるバリューを引落対象として指定する電子マネー識別情報を含む減算要求信号が、券売機３００またはカードユニット６００から携帯電話１００に送信され、当該電子マネー識別情報により指定されるバリューのみを用いてプリペイドカード３７１の購入または球貸を行なうことができるため、異なる種類のバリューを用いてプリペイドカード３７１の購入または球貸が行なわれることを防止することができる。

（２３）ステップＳ８１２において、プリペイドカード３７１の購入または球貸処理に用いたバリューの額と当該購入または球貸に用いた携帯電話１００の携帯ＩＤとが各々対応付けて店舗サーバ８００に記憶される。そして、ステップＳ８１３において所定時間経過したと判断された場合、ステップＳ８１４において店舗サーバ８００に記憶されていた情報を取引情報として電子マネー管理サーバ２００に送信される。一方、ステップＳ２７０７においては、チャージ累計額と携帯ＩＤとが各々対応付けて発行情報ＤＢ２２２に記憶される。そして、ステップＳ２９２において、取引情報に含まれる携帯ＩＤに対応する会員ＩＤのチャージ累計額から取引情報に含まれる取引額が減算され、ステップＳ２８１において、チャージ累計額がマイナスの会員ＩＤがあるか否かを判断することにより不正取引があったか否かが判断される。不正取引があった場合は、ステップＳ２８６において不正端末情報が、不正取引が発生した遊技場３０に送信される。

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

（２４）ステップＳ２８１において不正取引があった場合、ステップＳ２８２において不正回数が１加算され、不正取引の頻度が測定されている。そして、不正回数が１回の場合、ステップＳ２８４において不正媒体情報を不正取引が発生した遊技場３０に送信され、不正取引に用いられたプリペイドカードによる球貸を禁止する。また、不正回数が２回の場合、ステップＳ２８６およびステップＳ２８７において不正端末情報を不正取引が発生した遊技場３０および当該遊技場３０と同じ商圏の他の遊技場に送信され、不正取引に用いられた携帯電話１００によるプリペイドカード３１７の購入および球貸を禁止する。

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

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

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

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

（２６）携帯電話１００の非接触型ＩＣチップ１９０の機能によってバリュー残高が券売機３００に送信され、ステップＳ３５８で説明したように、券売機３００によって携帯電話１００に記憶されているバリュー残高からプリペイドカード３７１の購入金額を減算した額が所定額以下となると判定され、ステップＳ３５９で説明したように、減算後残高僅少情報が携帯電話１００に送信されて、ステップＳ１８４で説明したように、携帯電話１００によってバリュー残高が所定額以下となる旨が報知される。カードユニット６００についても同様である。つまり、バリューが用いられるときに、携帯電話１００によって、受動的に、バリュー残高が所定額以下となる旨が報知される。その結果、バリュー残高が少ないことを効率的に的確にユーザに認識させることができる。

（２７）ステップＳ１８１またはステップＳ１８２で減算前残高不足情報、減算後残高不足情報、または、減算後残高僅少情報が受信されたときにバリュー購入時処理が実行され、ステップＳ１３３で説明したように、バリュー購入時処理の実行開始後に自動的にチャージ要求情報が送信されるため、ユーザがバリュー購入時処理を能動的に実行させなくてもよい。このため、バリュー購入時処理を実行させる手間をユーザに掛けさせないようにできる。また、バリュー購入時処理が即座に実行されるので、バリュー購入に要する時間が短縮され、遊技場３０におけるパチンコ遊技機７００やスロットマシン等の遊技機の稼動率を向上させることができる。

（２８）バリュー購入時処理として、ステップＳ１３９で購入希望金額の選択肢が表示され、ステップＳ１４１で購入希望金額の選択が受付けられるので、ユーザが能動的にバリュー購入時処理を実行させて購入希望金額の選択肢を表示させなくてもよい。このため、バリュー購入時処理を実行させ購入希望金額の選択肢を表示させる手間をユーザに掛けさせないようにできる。また、バリュー購入時処理が即座に実行され購入希望金額の選択肢が表示されるので、バリュー購入に要する時間が短縮され、遊技場３０におけるパチンコ遊技機７００やスロットマシン等の遊技機の稼動率を向上させることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図４９を参照して、まず、電子マネー遊技使用サービスの提供業者のオペレータは、電話や電子メール等で、ユーザからのエラー問合せを受信した場合、ユーザに携帯電話１００の電子メールアドレスを問合せ、ユーザの携帯電話１００の電子メールアドレスを取得する
次に、オペレータは、取得したユーザの携帯電話１００の電子メールアドレス宛に、エラー対応開始メールを送信するように、電子マネー管理サーバ２００を操作する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（２１）第１の実施の形態におけるバリュー購入に関する処理においては、ユーザから購入希望金額を受付ける前に、図１５に示すバリュー購入時ＡＰ２１２のステップＳ２５１においてバリュー残高と最低購入金額との合計額が携帯上保持限度額以下か否かを判定するとともに、ステップＳ２５３において同日積算額と最低購入金額との合計金額が１日購入限度額以下か否かを判定し、両判定がＹＥＳの場合にさらに購入可能金額を算出して表示金額リスト情報とともに携帯電話１００に対して送信することで、携帯電話１００においては、表示金額リストのうち購入可能金額以下の選択肢のみが指定可能な態様で表示された。このようにすることは、ユーザに限度額を超過する無駄な選択操作をさせることがないことから好ましいが、これに限らず、ユーザに購入希望金額を先に選択させて、当該購入希望金額を電子マネー管理サーバ２００に送信し、バリュー残高と購入希望金額との合計額が携帯上保持限度額以下か否かを判定するとともに、当日積算額と購入希望金額との合計額が１日購入限度額以下か否かを判定するようにしてもよい。

（２２）本実施の形態においては、図１６に示すバリュー対価決済後処理において当日積算額を加算更新している、つまり図１５に示すステップＳ２５１、Ｓ２５３において携帯上保持限度額あるいは１日購入限度額以下でありチャージを許容すると判定された電子マネーの額を当日積算額に加算して管理しているが、これに限らず、図１８に示すバリュー発行時ＡＰ２１３におけるステップＳ２７７のバリュー発行情報送信に関連して、つまり携帯電話１００に対してバリュー発行情報が送信されたバリューの額を当日積算額に加算して管理するようにしてもよい。

（２３）本実施の形態においては、預かり残額を識別するための預かり残額識別情報として、電子マネー管理サーバ２００側において発行される預かり番号と遊技者から入力を受付けるパスワードの２種類の識別情報を使用しているが、これに限らず、いずれか一方のみでもよい。また、預かり番号やパスワードに限られず、預かり残額を識別可能な識別情報であればどのような形式のものであってもよい。

（２４）本実施の形態においては、携帯電話１００に記憶されたバリューを使用して取引処理を行なう取引手段として、プリペイドカード３７１を発行する処理を行なう発券機３００と球貸処理を行なうカードユニット６００とを説明しているが、取引処理手段はこのような遊技場に設置される装置に限らず、たとえば携帯電話１００に記憶されたバリューを使用して物品やチケット等を払出す取引処理を行なう自動販売装置であってもよいし、インターネットショッピング等でユーザが購入した商品の対価としてバリューを使用するような場合には、当該対価としてバリューを徴収するための処理を行なうショッピングサイト運営サーバが取引処理手段を構成する。

（２５）本実施の形態においては、初期登録処理、バリュー購入処理、バリュー発行処理、バリュー預け処理、およびバリュー返却処理において、種々の情報が複数回に分けて携帯電話１００と電子マネー管理サーバ２００との間で送受信されているが、各情報を処理のどの段階で何回に分けて送信するかといったことは、実施の形態に限られるものではなく、適宜変更可能である。

たとえば、バリュー購入処理において、携帯電話１００から電子マネー管理サーバ２００に対して、チャージ要求情報、第１口座振替依頼情報および第２口座振替依頼情報が送信されるが、予め購入希望金額の選択を受付けるような場合には、第１口座振替依頼情報を送信することなく、購入希望金額を含むチャージ要求情報を送信すればよいし、合計金額の確認を受付けない場合には、第２口座振替依頼情報を送信することなく、第１口座振替依頼情報に対して引継ぎ画面情報を返信するようにしてもよい。一方、電子マネー管理サーバ２００から携帯電話１００に対しては、表示金額リスト等を含む残高情報がチャージ受付情報として返信されるとともに、合計金額確認情報および引継ぎ画面情報が送信されるが、表示金額リスト等とは別個にチャージ受付情報を送信してもよいし、合計金額確認情報を送信することなく引継ぎ画面情報を送信してもよい。

（２６）本実施の形態においては、携帯電話１００を個々に識別するための識別情報として予め携帯電話１００に付与されている携帯端末情報（携帯ＩＤ）と電子マネー遊技使用サービスに会員登録することにより発行される会員ＩＤとを使用しているが、これに限らず、いずれか一方のＩＤのみを使用してもよいし、種類によって使用するＩＤを使い分けてもよい。

（２７）本実施の形態の携帯電話１００においては、初期登録処理、バリュー発行処理、バリュー預け処理およびバリュー返却処理における処理状況を、記憶部１２０に設けた１つの処理状況を各処理において共通に更新するようにした。しかし、これに限定されるものではなく、たとえば、バリューを重複して購入できるような場合には、図４６に示す各バリューごとに処理状況（発行状況）を管理し、初期登録処理、バリュー預け処理およびバリュー返却処理における処理状況については、図示していないが発行状況とは別に記憶・管理するようにしてもよい。図４６で示すＤＢは、バリューの購入番号、購入したバリューの額、および、処理状況を対応付けて記憶する。たとえば、購入番号が「９００１０８０１」および「９０００５５８７」であるバリューの額は、それぞれ「１０００」円および「５０００」円であり、処理状況は、それぞれ「発行情報受信済」および「書込済」である。

（２８）本実施の形態においては、データとして電子マネーを例にとり説明したが、データの種類は特に限定されるものではなく、たとえば、所定の会員登録を行なうことにより発行処理サーバから発行される会員ＩＤをデータとして携帯端末の記憶部に書込むものであってもよいし、発行処理サーバから発行されるポイント情報をデータとして書込むものであってもよい。

（２９）本実施の形態においては、削除処理において、電子マネー（データ）とともに、電子マネー記憶領域も削除するものであったが、これに限定されるものではなく、電子マネー記憶領域を削除することなく、電子マネーのみを削除するものであってもよい。

（３０）本実施の形態においては、図１０のステップＳ１１１３において処理状況をクリアして更新するようにしたが、これに限定されず、処理状況を書込済等、対応する処理が終了したことを示す状態に更新するものであってもよい。

（３１）本実施の形態においては、電子マネー（電子マネー記憶領域）の削除がバリュー預け処理において実施される例について説明したが、これに限定されず、たとえば、電子マネーアプリ初期画面に「領域削除」のメニューを設けておき、当該メニューが操作されることにより、領域（データ）を削除する処理のみが行なわれるようにしてもよい。

（３２）第１の実施の形態においては、携帯電話１００における処理状況とリモート発行サーバ４００における書込状況の比較をオペレータが実施したが、これに限定されず、電子マネー管理サーバ２００がリモート発行サーバ４００から書込状況を取得し、携帯電話１００から取得した処理状況と比較を行なうようにしてもよい。

（３３）今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

本発明に係る電子マネーシステムの構成の一例を示すブロック図である。本発明に係る携帯電話の構成の一例を示すブロック図である。本発明に係る電子マネー管理サーバの構成の一例を示すブロック図である。本実施の形態における電子マネー管理サーバが電子マネー遊技使用サービスを提供する際に用いる利用者情報データベースを説明するための図である。本実施の形態における電子マネー管理サーバが電子マネー遊技使用サービスを提供する際に用いる発行情報データベースを説明するための図である。本発明に係る券売機の構成の一例を示すブロック図である。本実施の形態におけるカードユニットの構成の一例を示すブロック図である。本実施の形態における電子マネー管理サーバにより実行される初期登録時アプリケーションプログラムの処理の流れを示すフローチャートである。本実施の形態における携帯電話のウェブブラウザ機能により実行されるウェブ処理の流れを示すフローチャートである。本実施の形態における携帯電話で実行される電子マネーアプリの処理の流れを示すフローチャートである。本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである初回起動処理の流れを示すフローチャートである。本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるＩＣチップ起動処理の流れを示すフローチャートである。本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである処理状況確認処理の流れを示すフローチャートである。本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー購入時処理の流れを示すフローチャートである。本実施の形態における電子マネー管理サーバにより実行されるバリュー購入時アプリケーションプログラムの処理の流れを示すフローチャートである。本実施の形態における電子マネー管理サーバにより実行されるバリュー購入時アプリケーションプログラムのサブルーチンであるバリュー対価決済後処理の流れを示すフローチャートである。本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー発行時処理の流れを示すフローチャートである。本実施の形態における電子マネー管理サーバにより実行されるバリュー発行時アプリケーションプログラムの処理の流れを示すフローチャートである。本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー預け処理の流れを示すフローチャートである。本実施の形態における電子マネー管理サーバにより実行されるバリュー預かりアプリケーションプログラムの処理の流れを示すフローチャートである。本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー返却処理の流れを示すフローチャートである。本実施の形態における電子マネー管理サーバにより実行されるバリュー返却アプリケーションプログラムの処理の流れを示すフローチャートである。本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第１の表示画面図である。本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第２の表示画面図である。本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第３の表示画面図である。本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第４の表示画面図である。本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第５の表示画面図である。本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第６の表示画面図である。本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第１の表示画面図である。本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第２の表示画面図である。本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第３の表示画面図である。本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第４の表示画面図である。本実施の形態における電子マネーシステムにおいて携帯電話にバリューをチャージするときに携帯電話の表示部に表示される第１の表示画面図である。本実施の形態における電子マネーシステムにおいて携帯電話から電子マネー管理サーバにバリューを預けるときに携帯電話の表示部に表示される第１の表示画面図である。本実施の形態における電子マネーシステムにおいて携帯電話から電子マネー管理サーバにバリューを預けるときに携帯電話の表示部に表示される第２の表示画面図である。本実施の形態における電子マネーシステムにおいて電子マネー管理サーバに預けたバリューの返却を受けるときに携帯電話の表示部に表示される第１の表示画面図である。本実施の形態における電子マネーシステムにおいて電子マネー管理サーバに預けたバリューの返却を受けるときに携帯電話の表示部に表示される第２の表示画面図である。本実施の形態における券売機で実行される発券処理の流れを示すフローチャートである。本実施の形態における券売機で実行される不正登録処理の流れを示すフローチャートである。本実施の形態における電子マネーシステムにおいて券売機から携帯電話の電子マネーアプリが起動されるときに携帯電話の表示部に表示される第１の表示画面図である。本実施の形態におけるカードユニットで実行される球貸処理の流れを示すフローチャートである。本実施の形態におけるカードユニットで実行されるプリペイド球貸処理の流れを示すフローチャートである。本実施の形態におけるカードユニットで実行されるユニット不正登録処理の流れを示すフローチャートである。本実施の形態における電子マネー管理サーバにより実行される残額管理アプリケーションプログラムの処理の流れを示すフローチャートである。本実施の形態における店舗サーバで実行される店舗サーバ処理の流れを示すフローチャートである。本実施の形態の変形例における携帯電話の記憶部に記憶されるデータベースを説明するための図である。第２の実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー発行時処理の流れを示すフローチャートである。第２の実施の形態における電子マネー管理サーバにより実行されるバリュー発行時アプリケーションプログラムの処理の流れを示すフローチャートである。第２の実施の形態における電子マネー管理サーバによって実行されるエラー対応処理の流れを示すフローチャートである。

符号の説明

１０電子マネーシステム、３０遊技場、１００携帯電話、１１０データ処理部、１１１電子マネーアプリ、１２０記憶部、１３０データ入力部、１４０表示部、１５０音声入出力部、１６０無線通信部、１６１アンテナ、１９０非接触型ＩＣチップ、１９１制御部、１９２記憶部、１９３非接触通信部、１９４アンテナ、２００電子マネー管理サーバ、２１０データ処理部、２１１初期登録時ＡＰ、２１２バリュー購入時ＡＰ、２１３バリュー発行時ＡＰ、２１４残高管理ＡＰ、２１５バリュー預かりＡＰ、２１６バリュー返却ＡＰ、２２０記憶部、２２１利用者情報ＤＢ、２２２発行情報ＤＢ、２３０データ入力部、２４０表示部、２６０通信部、２８０決済サーバ、３００券売機、３１０データ処理部、３２０記憶部、３３０操作部、３４０表示部、３６０通信部、３７０カードリーダライタ、３７１プリペイドカード、３８０貨幣処理機、３９０チップリーダライタ、３９１制御部、３９２記憶部、３９３非接触通信部、３９４アンテナ、４００リモート発行サーバ、５００金融機関サーバ、６００カードユニット、６１０データ処理部、６２０記憶部、６３１球貸ボタン、６３２返却ボタン、６４０表示部、６６０通信部、６７０カードリーダライタ、６８０貨幣処理機、６９０チップリーダライタ、６９１制御部、６９２記憶部、６９３非接触通信部、６９４アンテナ、７００パチンコ遊技機、８００店舗サーバ。

Claims

ユーザが所望する電子マネー情報が書込まれる記憶手段を備えた携帯端末と、該携帯端末に対して前記記憶手段への前記電子マネー情報の書込みをするための書込前処理と、該書込前処理した電子マネー情報を前記記憶手段に書込むための書込処理とを行なう発行書込処理サーバとを備えた電子マネー情報発行書込システムであって、
前記携帯端末は、
前記電子マネー情報の処理状況を管理する処理状況管理手段と、
該処理状況管理手段によって管理されている処理状況が未書込であることを条件として、前記電子マネー情報の書込みを要求するための書込要求情報を前記発行書込処理サーバに送信するために出力する書込要求出力手段を備え、
前記発行書込処理サーバは、
前記携帯端末に対して書込むべき電子マネー情報が書込済か否かを示す書込状況を管理する書込状況管理手段と、
前記書込要求出力手段から送信されてきた前記書込要求情報に対応する電子マネー情報の前記書込状況管理手段によって管理されている書込状況が未書込であることを条件として、当該電子マネー情報の前記記憶手段への書込みを指示する書込指示情報を、当該書込要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力する書込指示出力手段と、
該書込指示出力手段によって前記書込指示情報が出力されたことを条件として、当該書込指示情報で書込みが指示された電子マネー情報の前記書込状況管理手段によって管理されている書込状況を、書込済に更新する書込状況更新手段とを備え、
前記携帯端末は、さらに、
前記書込指示出力手段から前記書込指示情報を受信したことを条件として、当該書込指示情報で書込みが指示された電子マネー情報を前記記憶手段に書込むための処理を実行する電子マネー情報書込実行手段と、
該電子マネー情報書込実行手段によって前記電子マネー情報を書込むための処理が実行されたことを条件として、当該電子マネー情報の前記処理状況管理手段によって管理されている処理状況を、電子マネー情報書込済に更新する処理状況更新手段とを備え、
前記発行書込処理サーバは、さらに、
前記処理状況管理手段によって管理されている処理状況を更新させるための更新指示情報を前記携帯端末に送信するために出力する更新指示出力手段を備え、
前記携帯端末は、
前記更新指示出力手段からの前記更新指示情報の受信に基づいて、前記処理状況管理手段によって管理されている処理状況を更新する処理状況強制更新処理を実行する処理状況強制更新手段を備え、
さらに、前記更新指示出力手段は、前記処理状況強制更新処理を実行させるために操作されるリンク情報が添付された電子メールを、前記更新指示情報として出力し、
前記更新指示出力手段から送信されてきた前記電子メールに添付されたリンク情報が操作されることを条件として、前記処理状況強制更新手段は、前記処理状況強制更新処理を実行し、
前記携帯端末は、さらに、
前記リンク情報の操作が初回か否かを判定するリンク操作判定手段を備え、
前記処理状況強制更新手段は、前記リンク操作判定手段によって前記リンク情報の操作が初回であると判定されたことをさらに条件として、前記処理状況強制更新処理を実行することを特徴とする、電子マネー情報発行書込システム。
前記発行書込処理サーバは、さらに、
前記携帯端末から処理状況を取得する処理状況取得手段と、
該処理状況取得手段によって取得された処理状況に基づいた処理を実行する取得状況処理実行手段とを備えることを特徴とする、請求項１に記載の電子マネー情報発行書込システム。
前記取得状況処理実行手段は、前記処理状況取得手段によって取得された処理状況と、前記書込状況管理手段によって管理されている書込状況とが一致するか否かを判断し、
前記更新指示出力手段は、前記取得状況処理実行手段によって一致しないと判断されたことを条件として、前記更新指示情報を出力することを特徴とする、請求項２に記載の電子マネー情報発行書込システム。
ユーザが所望する電子マネー情報が書込まれる記憶手段を備えるとともに前記電子マネー情報の処理状況が未書込か書込済であるかを管理する携帯端末に対して前記記憶手段への前記電子マネー情報の書込みをするための書込前処理と、該書込前処理した電子マネー情報を前記記憶手段に書込むための書込処理とを行なう発行書込処理サーバであって、
前記携帯端末に対して書込むべき電子マネー情報が書込済か否かを示す書込状況を管理する書込状況管理手段と、
前記携帯端末にて管理されている処理状況が未書込であることを条件として前記携帯端末から送信されてくる書込要求情報に対応する電子マネー情報の前記書込状況管理手段によって管理されている書込状況が未書込であることを条件として、当該電子マネー情報の前記記憶手段への書込みを指示する書込指示情報を、当該書込要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力する書込指示出力手段と、
該書込指示出力手段によって前記書込指示情報が出力されたことを条件として、当該書込指示情報で書込みが指示された電子マネー情報の前記書込状況管理手段によって管理されている書込状況を、書込済に更新する書込状況更新手段と、
前記携帯端末にて管理されている処理状況を更新させるための更新指示情報を前記携帯端末に送信するために出力する更新指示出力手段とを備え、
前記更新指示出力手段は、前記携帯端末に前記処理状況を更新させるために操作されるリンク情報が添付された電子メールを、前記更新指示情報として出力し、
前記更新指示出力手段から送信した前記電子メールに添付されたリンク情報が操作されることを条件として、前記携帯端末は、前記処理状況を更新し、
さらに、前記携帯端末における前記リンク情報の操作が初回か否かを判定するリンク操作判定手段によって、前記リンク情報の操作が初回であると判定されたことをさらに条件として、前記携帯端末は、前記処理状況を更新することを特徴とする、発行書込処理サーバ。
ユーザが所望する電子マネー情報が書込まれる記憶手段と、
前記電子マネー情報の処理状況を管理する処理状況管理手段と、
該処理状況管理手段によって管理されている処理状況が未書込であることを条件として、前記電子マネー情報の書込みを要求するための書込要求情報を、前記記憶手段への前記電子マネー情報の書込みをするための書込前処理と該書込前処理した電子マネー情報を前記記憶手段に書込むための書込処理とを行なうとともに前記記憶手段に対して書込むべき電子マネー情報が書込済か否かを示す書込状況を管理する発行書込処理サーバに送信するために出力する書込要求出力手段と、
前記書込要求情報に応じて前記発行書込処理サーバから送信されてきた書込指示情報を受信したことを条件として、当該書込指示情報で書込みが指示された電子マネー情報を前記記憶手段に書込むための処理を実行する電子マネー情報書込実行手段と、
該電子マネー情報書込実行手段によって前記電子マネー情報を書込むための処理が実行されたことを条件として、当該電子マネー情報の前記処理状況管理手段によって管理されている処理状況を、電子マネー情報書込済に更新する処理状況更新手段と、
前記発行書込処理サーバから前記処理状況管理手段によって管理されている処理状況を更新させるための更新指示情報を受信したことに基づいて、前記処理状況管理手段によって管理されている処理状況を更新する処理状況強制更新処理を実行する処理状況強制更新手段とを備え、
前記処理状況強制更新手段は、前記発行書込処理サーバから送信されてきた前記処理状況強制更新処理を実行させるために操作されるリンク情報が添付された電子メールに添付されたリンク情報が操作されることを条件として、前記処理状況強制更新処理を実行し、
さらに、
前記リンク情報の操作が初回か否かを判定するリンク操作判定手段を備え、
前記処理状況強制更新手段は、前記リンク操作判定手段によって前記リンク情報の操作が初回であると判定されたことをさらに条件として、前記処理状況強制更新処理を実行することを特徴とする、携帯端末。
ユーザが所望する電子マネー情報が書込まれる記憶手段を備えるとともに前記電子マネー情報の処理状況を管理する携帯端末で実行されるアプリケーションプログラムであって、
前記処理状況が未書込であることを条件として、前記電子マネー情報の書込みを要求するための書込要求情報を、前記携帯端末に対して前記記憶手段への前記電子マネー情報の書込みをするための書込前処理と該書込前処理した電子マネー情報を前記記憶手段に書込むための書込処理とを行なうとともに前記携帯端末に対して書込むべき電子マネー情報が書込済か否かを示す書込状況を管理する発行書込処理サーバに送信するために出力するステップと、
前記書込要求情報に応じて前記発行書込処理サーバから送信されてきた書込指示情報で書込みが指示された電子マネー情報を前記記憶手段に書込むための処理が実行されたことを条件として、前記処理状況を電子マネー情報書込済に更新するステップと、
前記発行書込処理サーバから前記処理状況を更新させるための更新指示情報を受信したことに基づいて、前記処理状況を更新する処理状況強制更新処理を実行するステップと、
前記発行書込処理サーバから送信されてきた前記処理状況強制更新処理を実行させるために操作されるリンク情報が添付された電子メールに添付されたリンク情報が操作されることを条件として、前記処理状況強制更新処理を実行するステップと、
前記リンク情報の操作が初回か否かを判定するステップと、
前記リンク情報の操作が初回であると判定されたことをさらに条件として、前記処理状況強制更新処理を実行するステップとを実行させることを特徴とする、アプリケーションプログラム。