(57)【特許請求の範囲】
【請求項１】
貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバであって、
前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を発生させる支払債務発生手段と、
前記支払債務発生手段による支払債務の発生を前記携帯端末に通知する支払債務通知手段と、
前記携帯端末から支払期日が到達している支払債務が存在するか否かの問い合わせを受け付ける支払債務存否確認受付手段と、
前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信手段と、
前記支払債務存否確認受付手段が支払期日が到達している支払債務が存在するか否かの問い合わせを受け付け、当該支払債務の存在を確認した後、
前記金額変更情報送信手段がバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消手段と、
を備え、
前記金額変更情報送信手段が、支払債務に対応した金額を減少させる金額変更情報を送信するとバリュー残高がマイナスになる場合、前記金額変更情報送信手段が当該マイナスになる金額よりも多い金額を増額する金額変更情報を事前に送信することを特徴とする電子マネーサーバ。
【請求項２】
支払債務の所定日に前記携帯端末に支払の承認を求める支払承認要求手段と、
前記支払承認要求手段による支払の承認要求に対して、前記携帯端末から承認の通知を受信した後、前記金額変更情報送信手段がバリューを支払債務額に対応させて減少させる金額変更情報を送信することを特徴とする請求項１記載の電子マネーサーバ。
【請求項３】
前記支払承認要求手段による支払の承認要求に対して、前記携帯端末から不承認の通知を受信しないことを条件に、不応答の場合に承認があったものとみなすことを特徴とする請求項２記載の電子マネーサーバ。
【請求項４】
前記支払債務存否確認受付手段で、支払債務が存在するか否かの問い合わせを受け付けた際、支払債務が存在した場合、前記支払承認要求手段が支払の承認を求めることを特徴とする請求項２または請求項３記載の電子マネーサーバ。
【請求項５】
前記支払承認要求手段が、一定の要件の下にある複数の支払債務に対して、一括して支払いの承認を求めることを特徴とする請求項２から請求項４の何れか１項に記載の電子マネーサーバ。
【請求項６】
前記携帯端末から、支払債務発生の要求、支払債務の額および固有の識別情報を受信する支払債務発生要求受付手段をさらに備え、
前記支払債務発生要求受付手段が支払債務発生の要求を受信した後、前記支払債務発生手段が支払債務を発生させることを特徴とする請求項１から請求項５の何れか１項に記載の電子マネーサーバ。
【請求項７】
貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバにおける電子マネー処理方法であって、
前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を発生させる支払債務発生ステップと、
前記支払債務発生ステップによる支払債務の発生を前記携帯端末に通知する支払債務通知ステップと、
前記携帯端末から支払期日が到達している支払債務が存在するか否かの問い合わせを受け付ける支払債務存否確認受付ステップと、
前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信ステップと、
前記支払債務存否確認受付ステップで支払期日が到達している支払債務が存在するか否かの問い合わせを受け付け、当該支払債務の存在を確認した後、
前記金額変更情報送信ステップでバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消ステップと、
を備え、
前記金額変更情報送信ステップで、支払債務に対応した金額を減少させる金額変更情報を送信するとバリュー残高がマイナスになる場合、前記金額変更情報送信ステップで当該マイナスになる金額よりも多い金額を増額する金額変更情報を事前に送信することを特徴とする電子マネー処理方法。
【請求項８】
貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバにおける電子マネー処理プログラムであって、
前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を発生させる支払債務発生機能と、
前記支払債務発生機能による支払債務の発生を前記携帯端末に通知する支払債務通知機能と、
前記携帯端末から支払期日が到達している支払債務が存在するか否かの問い合わせを受け付ける支払債務存否確認受付機能と、
前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信機能と、
前記支払債務存否確認受付機能で支払期日が到達している支払債務が存在するか否かの問い合わせを受け付け、当該支払債務の存在を確認した後、
前記金額変更情報送信機能でバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消機能と、
前記金額変更情報送信機能で、支払債務に対応した金額を減少させる金額変更情報を送信するとバリュー残高がマイナスになる場合、前記金額変更情報送信機能で当該マイナスになる金額よりも多い金額を増額する金額変更情報を事前に送信すること
をコンピュータに実現させる電子マネー処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子マネーサーバ、電子マネー処理方法及び電子マネー処理プログラムに関するものである。
【背景技術】
【０００２】
近年、電子マネーの利用が広く普及してきている。プリペイド方式の電子マネーシステムでは、バリューと呼ばれる金銭と同様の交換価値を付与した電子情報をユーザが携帯するＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）チップに記憶させ、これを店舗の端末などで減額することにより商品やサービスの決済を行うようになっている（このタイプの電子マネーはストアドバリュー型の電子マネーと呼ばれている）。
一方、ＩＣチップが記憶するバリューの金額（以下、バリュー残高）を増額する処理は、チャージと呼ばれ、チャージの際に、バリュー相当の金額をユーザから徴収することにより、バリューと実際の金銭との対応が図られ、バリューの交換価値が担保されている。
なお、現在、広く普及している電子マネーは、電子マネーの運用者側で、ユーザの名前や住所を特定していない無記名式である。
【０００３】
また、電子マネーは、店舗での代金や鉄道の運賃の支払だけでなく、携帯端末などを用いて、ネットワークを介した決済にも用いられている。特許文献１には、このような例が開示されている。
このように、電子マネーの利用が広がるにつれて、各種支払を可能な限り電子マネーで済ませてしまいたいとするユーザからの要求が高まってきている。例えば、定期的に支払う必要がある公共料金（電気、ガス、水道、受信料など）、新聞の定期購読料、税金、保険料などを電子マネーを介して支払うことができれば、電子マネーの利便性がより一層高まることとなる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第４３３４２８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、電子マネーを用いて、定期的な料金の支払いに対応できる電子マネーサーバ、電子マネー処理方法、電子マネー処理プログラム及び電子マネー処理プログラムが記憶された記憶媒体を提供することを目的とする。
【課題を解決するための手段】
【０００６】
請求項１に記載の発明では、貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバであって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を発生させる支払債務発生手段と、前記支払債務発生手段による支払債務の発生を前記携帯端末に通知する支払債務通知手段と、前記携帯端末から支払期日が到達している支払債務が存在するか否かの問い合わせを受け付ける支払債務存否確認受付手段と、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信手段と、前記支払債務存否確認受付手段が支払期日が到達している支払債務が存在するか否かの問い合わせを受け付け、当該支払債務の存在を確認した後、前記金額変更情報送信手段がバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消手段と、を備え、前記金額変更情報送信手段が、支払債務に対応した金額を減少させる金額変更情報を送信するとバリュー残高がマイナスになる場合、前記金額変更情報送信手段が当該マイナスになる金額よりも多い金額を増額する金額変更情報を事前に送信することを特徴とする電子マネーサーバを提供する。
請求項２に記載の発明では、支払債務の所定日に前記携帯端末に支払の承認を求める支払承認要求手段と、前記支払承認要求手段による支払の承認要求に対して、前記携帯端末から承認の通知を受信した後、前記金額変更情報送信手段がバリューを支払債務額に対応させて減少させる金額変更情報を送信することを特徴とする請求項１記載の電子マネーサーバを提供する。
請求項３に記載の発明では、前記支払承認要求手段による支払の承認要求に対して、前記携帯端末から不承認の通知を受信しないことを条件に、不応答の場合に承認があったものとみなすことを特徴とする請求項２記載の電子マネーサーバを提供する。
請求項４に記載の発明では、前記支払債務存否確認受付手段で、支払債務が存在するか否かの問い合わせを受け付けた際、支払債務が存在した場合、前記支払承認要求手段が支払の承認を求めることを特徴とする請求項２または請求項３記載の電子マネーサーバを提供する。
請求項５に記載の発明では、前記支払承認要求手段が、一定の要件の下にある複数の支払債務に対して、一括して支払いの承認を求めることを特徴とする請求項２から請求項４の何れか１項に記載の電子マネーサーバを提供する。
請求項６に記載の発明では、前記携帯端末から、支払債務発生の要求、支払債務の額および固有の識別情報を受信する支払債務発生要求受付手段をさらに備え、前記支払債務発生要求受付手段が支払債務発生の要求を受信した後、前記支払債務発生手段が支払債務を発生させることを特徴とする請求項１から請求項５の何れか１項に記載の電子マネーサーバを提供する。
請求項７に記載の発明では、貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバにおける電子マネー処理方法であって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を発生させる支払債務発生ステップと、前記支払債務発生ステップによる支払債務の発生を前記携帯端末に通知する支払債務通知ステップと、前記携帯端末から支払期日が到達している支払債務が存在するか否かの問い合わせを受け付ける支払債務存否確認受付ステップと、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信ステップと、前記支払債務存否確認受付ステップで支払期日が到達している支払債務が存在するか否かの問い合わせを受け付け、当該支払債務の存在を確認した後、前記金額変更情報送信ステップでバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消ステップと、を備え、前記金額変更情報送信ステップで、支払債務に対応した金額を減少させる金額変更情報を送信するとバリュー残高がマイナスになる場合、前記金額変更情報送信ステップで当該マイナスになる金額よりも多い金額を増額する金額変更情報を事前に送信することを特徴とする電子マネー処理方法を提供する。
請求項８に記載の発明では、貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバにおける電子マネー処理プログラムであって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を発生させる支払債務発生機能と、前記支払債務発生機能による支払債務の発生を前記携帯端末に通知する支払債務通知機能と、前記携帯端末から支払期日が到達している支払債務が存在するか否かの問い合わせを受け付ける支払債務存否確認受付機能と、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信機能と、前記支払債務存否確認受付機能で支払期日が到達している支払債務が存在するか否かの問い合わせを受け付け、当該支払債務の存在を確認した後、前記金額変更情報送信機能でバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消機能と、前記金額変更情報送信機能で、支払債務に対応した金額を減少させる金額変更情報を送信するとバリュー残高がマイナスになる場合、前記金額変更情報送信機能で当該マイナスになる金額よりも多い金額を増額する金額変更情報を事前に送信することをコンピュータに実現させる電子マネー処理プログラムを提供する。
【発明の効果】
【０００７】
本発明によれば、電子マネーにより、定期的な料金の支払いを行うことができる。
【図面の簡単な説明】
【０００８】
【図１】電子マネーシステムのネットワーク構成を示した図である。
【図２】携帯端末の構成を説明するための図である。
【図３】電子マネーサーバのハードウェア的な構成の一例を示した図である。
【図４】支払債務ＤＢの構成を示した図である。
【図５】本実施の形態の処理手順を示したフローチャートである。
【図６】支払債務の承認画面の一例を示した図である。
【図７】オートチャージの設定を説明するための図である。
【発明を実施するための形態】
【０００９】
（Ａ）実施形態の概要
図１は、本実施の形態に係る電子マネーシステムの基本的な構成を説明するための図である。
この電子マネーシステム１は、電子マネーサーバ２、クレジット会社サーバ３、インターネット４、携帯端末５、基地局７、加盟店８１に設置された店舗端末８などから構成されている。
また、携帯端末５は、図２に示すように、バリューを記憶するＩＣチップ１２と、電子マネーアプリケーション１５を備えている。この電子マネーアプリケーション１５は、電子マネーに関する各種の処理を行う。また、後述するオートチャージに関する、予めユーザが設定した残高基準金額とオートチャージ金額を記憶している。
以下、括弧に示した番号の順に従って本実施の形態の処理が行われる。
【００１０】
（１）電子マネーサーバ２で、携帯端末５からの要請により、または電子マネーサーバ側２で、電子マネー機能部ＩＤに対応付けて、支払債務を発生させる。具体的には、各種の公共料金、新聞の定期購読料、税金のなどの支払である。
（２）携帯端末５の電子マネーアプリケーション１５は、電子マネーサーバ２に支払債務の確認要求を出す。
（３）電子マネーサーバ２では、支払債務の有無を確認し、支払債務が存在しなければ、その旨を通知し、支払債務が存在すれば、支払接続要求を送信する。
（４）これに対して、携帯端末５の電子マネーアプリケーション１５は、ユーザから「支払承認」の入力を受けると、「支払接続要求承認」を電子マネーサーバ２へ送信する。
（５）この「支払接続要求承認」を受けた電子マネーサーバ２は、「支払要求」を携帯端末５へ送信し、ＩＣチップ１２に記憶されたバリューを減額する。同時に、振込先サーバに送金の手続を行う。
（６）そして、電子マネーサーバ２は、発生してた支払債務を消滅させ、携帯端末５へ、支払が完了した旨を通知する。
【００１１】
（Ｂ）実施形態の詳細
（第１の実施の形態）
図１は、本実施の形態に係る電子マネーシステム１のネットワーク構成を示した図である。
この電子マネーシステム１は、電子マネーサーバ２、クレジット会社サーバ３、インターネット４、携帯端末５、基地局７、加盟店８１に設置された店舗端末８などから構成されており、これらが互いに協働することで電子マネーシステム１を維持、運営している。
【００１２】
携帯端末５は、例えば、スマートフォンや携帯電話などのインターネット通信機能を有する携帯型の端末であって、ＩＣチップ１２を内蔵している。
携帯端末５は、基地局７と無線通信することによりインターネット４を介して電子マネーサーバ２と通信することができる。
【００１３】
ＩＣチップ１２は、近距離無線通信用のアンテナを備えており、店舗端末８と近距離無線通信を行うことができる。
ＩＣチップ１２は、バリューを記憶することができ、店舗端末８から送信されるコマンドを実行することにより、チャージや決済を行うことができる。
また、ＩＣチップ１２は、携帯端末５を介して電子マネーサーバ２と通信し、電子マネーサーバ２から送信されるコマンドを実行することにより、チャージや決済を行うこともできる。
【００１４】
携帯端末５には、電子マネーアプリケーション１５がインストールされている。電子マネーアプリケーション１５は、携帯端末５において、電子マネーに関する各種処理を行う。
また、ＩＣチップ１２に対してオートチャージを行う機能も有している。この機能は、定期的にＩＣチップ１２のバリュー残高を確認し、バリュー残高が残高基準金額以下または未満である場合は、電子マネーサーバ２にアクセスして、電子マネーサーバ２にチャージを要求する。
【００１５】
この要求に対し、電子マネーサーバ２は、ＩＣチップ１２に対してコマンドを送信し、ＩＣチップ１２にチャージする。このように、電子マネーアプリケーション１５によって行われる自動的なチャージをオートチャージと呼ぶことにする。
【００１６】
電子マネーサーバ２は、電子マネーシステム１におけるバリューの流通を管理するサーバである。
電子マネーサーバ２は、定期的、又は、不定期に店舗端末８からチャージや決済の履歴を記録したログデータを収集する。そして、これとＩＣチップ１２に直接チャージや決済を行った際のログデータを合わせて集計し、バリューの流通と通貨との対応をとっている。
【００１７】
加盟店８１は、小売店舗、営業所、営業車両などのユーザから対価を取って商品やサービスを提供する事業者である。
加盟店８１は、電子マネーシステム１が提供する電子マネーサービスを利用する連合体に加盟しており、単数、又は複数の店舗端末８を備えている。
【００１８】
店舗端末８は、ＩＣチップ１２と近距離無線通信を行い、ＩＣチップ１２にコマンドを送信してチャージや決済を行う。
店舗端末８は、ＩＣチップ１２との処理内容を記録したログデータを定期、又は不定期にバッチ処理にて電子マネーサーバ２に送信する。
【００１９】
クレジット会社サーバ３は、オートチャージを行う際に用いられる構成であり、クレジット会社がクレジットカードによる支払を管理するためのサーバである。
ＩＣチップ１２のユーザは、当該クレジット会社と契約しており、電子マネーサーバ２に自己のクレジットカード番号を登録してある。
クレジット会社サーバ３は、電子マネーサーバ２がＩＣチップ１２にチャージする際に、その代金をユーザのクレジットカード番号にて決済する。
【００２０】
図２は、携帯端末５の構成を説明するための図である。
携帯端末５は、端末機能部１０、ＩＣチップ１２、両者を接続するインターフェース部１１、及び近距離無線用のアンテナを備えたＩＣチップで形成された端末通信部１６を備えている。なお、端末通信部１６を内蔵したＩＣチップ１２も存在する。
【００２１】
ＩＣチップ１２は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）などを備えており、コンピュータとしての機能を有している。
後述するように、端末機能部１０もコンピュータとしての機能を有しており、携帯端末５は、２つのコンピュータがインターフェース部１１によって接続した状態となっている。
【００２２】
ＥＥＰＲＯＭには、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）の他、例えば、ポイントカードとして機能するアプリケーションや会員カードとして機能するアプリケーションなど、複数のアプリケーションソフトウェアをインストールして実行することが可能である。
本実施の形態では、電子マネー処理用のアプリケーションプログラムがインストールしてあり、当該プログラムをＣＰＵで実行することにより、バリュー処理部１７、電子マネー記憶部１８などが構成される。
【００２３】
電子マネー記憶部１８は、電子マネー機能部ＩＤ、バリュー残高、ログデータなどを記憶している。
電子マネー機能部ＩＤは、ＩＣチップ１２にインストールされている電子マネー処理用のアプリケーションを特定するための識別情報である。
バリュー残高は、現在記憶しているバリューの金額である。
ログデータは、チャージ、決済、残高参照など、電子マネーに関する処理が行われた場合の処理内容を記録したログデータである。
【００２４】
バリュー処理部１７は、端末通信部１６を介して店舗端末８から入力されたコマンドを実行する。これにより、バリュー処理部１７は、チャージや決済、残高参照、電子マネー機能部ＩＤの参照、ログデータの参照などを行う。
なお、端末通信部１６は、近距離無線用のアンテナを備えており、店舗端末８とバリュー処理部１７の通信を仲介する。店舗端末８は、近距離無線用のアンテナを備えたリーダライタを備えており、端末通信部１６は、このリーダライタを介して店舗端末８と通信する。
【００２５】
チャージを行うチャージコマンドとしては、加算コマンド、又は上書きコマンドを利用することができる。
加算コマンドは、パラメータで指定した金額分の加算処理をバリュー処理部１７に行わせる命令である。
例えば、１０００円分のチャージを行う場合、バリュー処理部１７は、店舗端末８から入力された加算コマンドに従って、電子マネー記憶部１８のバリュー残高に１０００円を加算し、加算後の値を電子マネー記憶部１８のバリュー残高に上書きする。
【００２６】
上書きコマンドは、パラメータで指定した金額での上書き処理をバリュー処理部１７に行わせる命令である。
例えば、１０００円分のチャージを行う場合、まず、店舗端末８は、残高参照コマンドによってＩＣチップ１２からバリュー残高を読み出す。次に、店舗端末８は、当該バリュー残高に１０００円を加算し、加算後の値で上書きする上書きコマンドをＩＣチップ１２に入力する。ＩＣチップ１２は、これを実行して、電子マネー記憶部１８のバリュー残高を上書きする。
【００２７】
また、決済を行う決済コマンドとしては、減算コマンド、又は上書きコマンドを利用することができる。
減算コマンドは、パラメータで指定した金額分の減算処理をバリュー処理部１７に行わせる命令である。
【００２８】
例えば、１０００円分の決済を行う場合、バリュー処理部１７は、店舗端末８から入力された減算コマンドに従って、電子マネー記憶部１８のバリュー残高から１０００円を減算し、減算後の値を電子マネー記憶部１８のバリュー残高に上書きする。
上書きコマンドで決済する場合は、上書きコマンドでチャージする場合と同様にして行うことができる。
チャージコマンドに加算コマンドと上書きコマンドの何れを用いるか、また、決済コマンドに減算コマンドと上書きコマンドの何れを用いるかは、電子マネーシステム１のシステム設計による。
【００２９】
端末機能部１０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、マルチタッチスクリーン、スピーカ、マイクロフォン、ＲＦ回路などを備えたコンピュータであって、インターフェース部１１を介してＩＣチップ１２と接続している。
端末機能部１０は、図示しないＲＦ回路によって基地局７と通信することができ、また、インターフェース部１１を介してＩＣチップ１２と通信することができる。
【００３０】
ＥＥＰＲＯＭには、ＯＳの他、ブラウザやゲームなど複数のアプリケーションソフトウェアをインストールして実行することが可能である。
マルチタッチスクリーンは、携帯端末５の表示画面に設置されており、ユーザが画面を指先でタッチして項目を選択するなどしてアプリケーションソフトウェアを操作できるようになっている。
【００３１】
本実施の形態では、ＥＥＰＲＯＭに電子マネーに関する各種サービスを提供するアプリケーションソフトウェアである電子マネーアプリケーション１５をインストールして動作させる。
電子マネーアプリケーション１５は、例えば、電子マネーサーバ２から電子マネーアプリケーション１５用のプログラムを端末機能部１０にダウンロードしてインストールしたり、あるいは、当該プログラムを記録した記録媒体をユーザに配布して、当該記録媒体から端末機能部１０にインストールして形成される。
【００３２】
電子マネーアプリケーション１５は、携帯端末５の通信機能を用いて電子マネーサーバ２と通信することができる。
そして、電子マネーアプリケーション１５は、電子マネーサーバ２に対してユーザ登録、支払債務存在の有無の問い合せ、支払接続の承認、オートチャージの設定を行ったり、また、電子マネーサーバ２と協働してオートチャージを実施したりする。
【００３３】
また、電子マネーアプリケーション１５は、インターフェース部１１を介してＩＣチップ１２と通信することもできる。
これにより、電子マネーアプリケーション１５は、ＩＣチップ１２に残高参照コマンドを入力してＩＣチップ１２からバリュー残高を読み出したり、ＩＤ参照コマンドを入力して電子マネー機能部ＩＤを読み出したり、ログデータ参照コマンドを入力してログデータを読み出したりすることができる。
【００３４】
図３は、電子マネーサーバ２のハードウェア的な構成の一例を示した図である。
電子マネーサーバ２は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、通信制御部３４、記憶部３５などがバスラインで接続されて形成され、情報処理サーバを構成している。
【００３５】
ＣＰＵ３１は、所定のプログラムに従って各種の情報処理を行う中央処理装置である。
本実施の形態では、携帯端末５から支払債務の有無の問い合わせを受けたり、オートチャージの要求を受けてオートチャージを行う。また、店舗端末８からログデータを収集して集計したりもする。
なお、これらの機能の全てをＣＰＵ３１で行う必要はなく、複数台のサーバ装置を組み合わせて電子マネーサーバ２と同等の機能を有するシステムを構成してもよい。
【００３６】
ＲＯＭ３２は、読み出し専用のメモリであり、電子マネーサーバ２を動作させるための基本的なプログラムやパラメータなどが記憶されている。
ＲＡＭ３３は、読み書き可能なメモリであって、ＣＰＵ３１にワーキングメモリを提供したり、記憶部３５に記憶されたプログラムやデータをロードして記憶したりなどする。
通信制御部３４は、店舗端末８と通信したり、インターネット４や基地局７を介して携帯端末５と通信したりする。
【００３７】
記憶部３５は、例えばハードディスクなどの大容量の記憶装置を用いて構成されており、各種プログラムを格納したプログラム格納部３６、データを格納したデータ格納部３７などから構成されている。
プログラム格納部３６には、ＯＳ、オートチャージを行うためのプログラム、ログデータを処理するプログラム、その他のプログラムが格納されている。
【００３８】
データ格納部３７には、携帯端末５や電子マネーカードのＩＣチップ１２で電子マネーシステム１を使用するユーザを登録したユーザＤＢ（データベース）３８、発生した支払債務を記録する支払債務ＤＢ３９、ログデータＤＢ４０、オートチャージの条件などを登録したオートチャージ登録ＤＢ４１、図示しないが、加盟店８１を登録した加盟店ＤＢ、バリューによる取引履歴を記録した取引履歴ＤＢ、その他のデータベースが格納されている。
【００３９】
ユーザＤＢ３８には、ユーザＩＤ、パスワード、ユーザの氏名、住所、生年月日、電話番号、電子メールアドレス、ＩＣチップ１２の電子マネー機能部ＩＤ、クレジットカード番号、オートチャージの利用登録の有無などが、ユーザＩＤごとに対応づけられて記憶されている。このように、電子マネーシステム１では、オートチャージを利用する旨をユーザＤＢ３８に登録したユーザがオートチャージサービスの対象となる。
なお、ユーザＤＢ３８には、ユーザの預貯金口座（例えば、銀行口座）からオートチャージの代金を引き落とす場合は、ユーザの預貯金口座番号（例えば、銀行口座番号）を記憶し、オートチャージ金額を電話料金に合算する場合は、携帯電話会社のユーザＩＤを記憶する。また、複数の決済手段（クレジットカード、預貯金口座など）を用いる場合は、決済手順を記憶することもできる。
【００４０】
図４は、支払債務ＤＢ３９の論理的構成を説明するための図である。
この支払債務ＤＢ３９には、「（ユーザ）識別情報」、「取引ＩＤ」、「支払金額」、「支払日」、「支払先」、「支払承認の有無」、「支払（支払の完了の有無）」が記憶されている。
「（ユーザ）識別情報」とは、ユーザを識別するための情報であり、例えば、電子マネー機能部ＩＤを用いることができる。
「取引ＩＤ」とは、支払債務を発生させた取引を識別するための情報である。
具体的には、「○○氏の１月分○×新聞購読料」を識別するための情報である。この「取引ＩＤ」は、支払債務発生の前提となる契約の際に予め定めておく。そして、支払債務発生時に、当該取引ＩＤに係る取引について、支払債務を発生させた旨の通知を料金の振込先に行うようにしてもよい。
また、振込サーバ１００への振り込みの際、紐づけて通知するようになっている。こうすることで、振込先（債権者）は何に対する支払が行われたのかを確認することができる。
【００４１】
次に、図５のフローチャートを参照して、本実施の形態に係る定期的な料金の支払い処理を説明する。
電子マネーサーバ２側で、電子マネー機能部ＩＤに対応付けて支払債務を発生させる（ステップ１０５）。この支払債務の発生には、債権者と債務者の契約ないし同意が存在することが前提となる。具体的には、「○○氏の毎月の○×新聞購読料４０００円を毎月２５日電子マネーで支払う。○○氏は、電子マネー機能部ＩＤを備えた携帯端末５で、支払処理を行う。」といったものである。この際「取引ＩＤ」も取り決めておく。
この支払債務の発生は、契約に基づいて、電子マネーサーバ２側で自発的に行う。しかし、例えば、携帯端末５から支払債務の発生要求を受けて発生するようにしてもよい（ステップ１００ａ)。この場合は、ユーザは、携帯端末５の電子マネーアプリケーション１５を起動させ、電子マネー機能部ＩＤと「取引ＩＤ」を紐付けて送信し、支払債務の発生を要請する。
また、振込先サーバ１００からの支払債務の発生要求を受けて発生するようにしてもよい（ステップ１００ｂ)。このケースでは、支払債務の発生要求とともに「取引ＩＤ」も電子マネーサーバ２へ送信するようにする。
電子マネーサーバ２は、支払債務を発生されたときに、当該発生債務を支払債務ＤＢ３９に記録する。このとき、取引ＩＤも記録されるため、両者が紐付くこととなる。
【００４２】
支払債務が発生した場合、電子マネーサーバ２は、振込先サーバ１００に支払債務が発生した旨及び「取引ＩＤ」を通知する（ステップ１１０）。この処理は、必ずしも必須のものでなく、省略することもできる。
なお、電子マネーサーバ２は、支払債務が発生したとき、または発生後所定の時間経過後に例えば電子メールで携帯端末５にその旨を通知するようにしてもよい。
事前に通知しておくことで、予め決済に必要なバリューのチャージを促し、決済時不足分が出ないようにすることができる。
一方、携帯端末５の電子マネーアプリケーション１５は、電子マネーサーバ２に対して、支払債務が存在しているか否かを確認する支払債務の確認要求を行う(ステップ１１５）。この確認は、毎日行うように設定してもよいが、例えば１日おき、週２回、毎週など状況に応じて適宜設定するようにできる。
具体的には、携帯端末５は、電子マネーアプリケーション１５を起動し、支払債務が存在するか否かのポーリングを行う。
【００４３】
これに対して、電子マネーサーバ２は、支払債務が存在するか否かの確認を行う（ステップ１２０）。この確認は、支払債務ＤＢ３９を検索することにより行う。
その結果、支払債務（支払期日が到達しているもの）が存在しない場合は（ステップ１２０；Ｎ）、電子マネーサーバ２は、支払債務が存在しない旨を携帯端末５に通知する（ステップ１２５）。
一方、支払債務が存在し、且つ支払期日が到達している場合は(ステップ１２０；Ｙ）、電子マネーサーバ２は、携帯端末５に支払接続要求を送信する(ステップ１３０）。この支払接続要求を受けて、電子マネーアプリケーション１５は、携帯端末５の画面に図６に示すような表示を行い、ユーザからの承認を求める。
【００４４】
ユーザが「承認」ボタンをタッチすることで、ユーザからの承認する旨の意思表示を受信した場合は、電子マネーアプリケーション１５は、支払接続要求承認の通知を電子マネーサーバ２へ送信する（ステップ１３５）。
電子マネーサーバ２は、携帯端末５のＩＣチップ１２に対して減算コマンドを送信して支払要求を行う（ステップ１４０）。これを受けて、ＩＣチップ１２で減算処理（支払）が行われると、携帯端末５の電子マネーアプリケーション１５は、減算が行われた旨を電子マネーサーバ２へ通知する（ステップ１４５）。
これを受けて、電子マネーサーバ２は、支払債務を消滅させる。具体的には、支払債務ＤＢ３９の「支払」を「済」と入力する。同時に、対応する金額を振込先サーバに送金する（ステップ１５０）。このとき、取引ＩＤも送信する。こうすることで、振込先サーバ１００でどの取引に関する支払かを識別することができる。
ここで、電子マネーサーバ２は、公共料金の徴収元へ支払うデータを出力する。そして、公共料金の徴収元へ電子的に振り込んでもよいし、電子マネーサーバ２の運営者が振込を行うための振込用紙を出力して、別途振込を行うようにしてもよい。
そして、電子マネーサーバ２は、支払完了通知を携帯端末５に送信して（ステップ１５５）、処理を終了する。
【００４５】
本実施の形態の処理は、例えば新聞の購読料、電気料金、ガス料金の場合は、上記処理を月１回、毎月繰り返すこととなる。
また、水道料金のように２ヶ月に１回の支払の場合は、２ヶ月に１回毎に上記処理を繰り返す。
さらに、固定資産税のように年４回に分割納付が可能なものについては、年４回上記処理を繰り返す。なお、固定資産税のように、一括納付と分割納付が可能なものについては、第１回目の納付の際に、どちらの納付にするかをユーザに選択させるようにしてもよい。
【００４６】
次に、図５のステップ１３５における支払接続要求承認について他の例を説明する。
上記した例では、支払債務が存在した場合（ステップ１２０；Ｙ）、電子マネーサーバ２から携帯端末５に対して支払接続要求を出し（ステップ１３０）、これに対し、携帯端末５から支払接続要求承認（ステップ１３５）を送信する構成とした。
しかし、本実施の形態は、これに限られず、他の時点で携帯端末５から「承認」を得る構成としてもよい。
例えば、ステップ１００ａの携帯端末５から支払債務発生要求があった場合、この時点でステップ１３０、ステップ１３５に相当する処理を行い、事前に「承認」を得ておくようにする。
また、ステップ１００ｂの振込先サーバ１００から支払債務発生要求があった場合にも、この時点でステップ１３０、ステップ１３５に相当する処理を行い、事前に「承認」を得ておくようにする。
この「承認」を得る処理は、ステップ１０５の支払債務を発生させる処理の前であっても後であってもよい。
なお、上記例では、既に「承認」を得ているので、ステップ１２０（ステップ１２０；Ｙ）の場合、ステップ１３０、ステップ１３５の処理を省略し、直ちにステップ１４０の処理へ移行することができる。
【００４７】
次に、ステップ１３５の携帯端末５から支払接続要求承認の通知が送信されてこない場合の処理について説明する。
この場合、積極的に「不承認」の通知がないことを条件として、「承認」があったものとみなすように構成することもできる。
このように構成することで、携帯端末５のユーザが対応を失念した場合に、決済を停止してしまうという不都合を防止することができる。
一方、携帯端末５のユーザからすると、ステップ１３０の要求を受信した際、何ら対応せずに、単に放置しておけば自動的に「承認」とすることができる。
但し、このように構成する場合は、事前に「不応答の場合は、みなし承認となる」旨を周知させておくことが重要となる。
【００４８】
（変形例１）
上記実施の形態では、各支払債務毎に支払の承認を得ていたが、その都度承認を得るのは煩雑であり、ユーザの利便性に反することも考えられる。
そこで、一定期間の支払債務について一括して承認を行うようにする。例えば、月末に新聞の購読料、電気料金、水道料金の支払がある場合、これらの図５のステップ１３０の処理を一括して行う。こうすることで、ユーザが何度も承認の処理を行う煩わしさを減少させることができる。
一括承認を求める際に、ユーザの利便のため、トータルで必要な金額を提示するようにしてもよい。
一方、電子マネーサーバ２側では、各支払債務の処理を各々通常の債務の処理と同様に行う。
なお、この変形例１でも上記の例と同様に、「承認」を得る時点を図５の例と異なる時点にしたり、「不承認」の通知がないことを条件として、「不応答の場合は、みなし承認となる」構成としてもよい。
【００４９】
（変形例２）
次に、図５のステップ１４０で、携帯端末５に支払要求した際、残高不足で決済ができない場合の処理について説明する。
残高が不足した場合、オートチャージを行うようにする。
まず、このオートチャージを説明する。
電子マネーアプリケーション１５は、ユーザが設定した残高基準金額を記憶している。残高基準金額は、オートチャージを実行する際の基準となる金額である。
電子マネーアプリケーション１５は、定期的に（例えば、１時間おきに）ＩＣチップ１２に残高参照コマンドを入力してバリュー残高を取得し、バリュー残高が残高基準金額以下（あるいは未満）となると、オートチャージ動作を開始する。
この場合、電子マネーアプリケーション１５は、電子マネーサーバ２にアクセスしてオートチャージの要求を行う。
【００５０】
そして、電子マネーアプリケーション１５は、この要求に対して電子マネーサーバ２が送信してきたチャージコマンドをＩＣチップ１２に入力して、ＩＣチップ１２にチャージさせる。
この際、電子マネーアプリケーション１５は、電子マネーサーバ２からＩＣチップ１２に至る通信経路を暗号化してセキュリティを高めている。
【００５１】
なお、電子マネーサーバ２にオートチャージする金額を記憶しておき（オートチャージ登録ＤＢ４１）、これをオートチャージに使用するが、電子マネーアプリケーション１５にオートチャージする金額を記憶しておき、これをオートチャージの度に電子マネーサーバ２に送信するように構成してもよい。
【００５２】
電子マネーサーバ２のオートチャージ登録ＤＢ４１には（図３参照）、電子マネー機能部ＩＤ、残高基準額、オートチャージ金額、日額限度額、月額限度額などが、ユーザごとに対応づけられて記憶されている。
残高基準金額は、電子マネーアプリケーション１５に記憶しているものと同じである。そのため、必ずしも電子マネーサーバ２が記憶する必要はないが、ＩＣチップ１２の管理のために電子マネーサーバ２にも記憶してある。
【００５３】
オートチャージ金額は、１回のオートチャージでＩＣチップ１２にチャージする金額である。
日額限度額は、オートチャージによる１日当たりのチャージ合計値の上限値である。
月額限度額は、オートチャージによる１ヶ月当たりのチャージ合計値の上限値である。
また、１日当たりの限度回数、１ヶ月当たりの限度回数を設定するように構成してもよい。」
【００５４】
図７は、携帯端末５に表示されるオートチャージ設定画面を示した図である。
オートチャージ設定画面は、電子マネーアプリケーション１５が電子マネーサーバ２にアクセスして表示したものである。
なお、電子マネーサーバ２が携帯端末５に提供する画面には、この他に、ユーザ登録画面など各種のものがある。
【００５５】
オートチャージ設定画面では、「１．オートチャージ金額を選択して下さい。」との表示の下に、残高基準金額設定欄５１とオートチャージ金額設定欄５２が表示されている。
残高基準金額設定欄５１、オートチャージ金額設定欄５２は、何れもコンボボックスとなっており、ユーザがそれぞれ、残高基準金額、１回のオートチャージでチャージする金額を選択するようになっている。なお、ユーザが任意の金額を入力するように構成することもできる。
【００５６】
その下側には、「２．１日のオートチャージ上限額を選択して下さい。」との表示があり、これに続いて上限額設定欄５３が表示されている。
上限額設定欄５３は、ドロップダウンメニューとなっており、ユーザが、１日の上限額を選択するようになっている。なお、ユーザが任意の金額を入力するように構成することもできる。
なお、図示しないが、更に、「３．１ヶ月のオートチャージ上限額を選択して下さい。」などと、１ヶ月間の上限を選択（あるいは任意の金額を入力）する欄も設けられている。
【００５７】
更に、上限額設定欄５３の下側には、設定ボタン５４と戻るボタン５５が表示されている。
設定ボタン５４は、ユーザが選択した内容を電子マネーサーバ２に通知するためのボタンであり、設定ボタン５４が選択されると、電子マネーアプリケーション１５は、ユーザが設定した内容を電子マネーサーバ２に送信する。
戻るボタン５５は、オートチャージ設定画面を表示する前に表示していた画面に戻るためのボタンである。
【００５８】
オートチャージ設定の処理は、携帯端末５のＩＣチップ１２に実装されたＣＰＵ、携帯端末５の端末機能部１０に実装されたＣＰＵ、電子マネーサーバ２のＣＰＵ３１が、それぞれ、電子マネー処理用のアプリケーションプログラム、電子マネーアプリケーション１５のプログラム、及び電子マネーサーバ用のプログラムに従って行う。
【００５９】
ここで、図７での設定を前提に、仮に新聞の購読料４０００円の支払債務が存在し、残高が１０００円だったとする。この場合、所定値の３０００円をオートチャージすることで支払を完了することができる。
しかし、直ちに、残金が０円となってしまう。そこで、再度オートチャージが必要となる。このような場合、例えば、図５のステップ１３５の「承認」を条件に、１日のオートチャージ上限額（図７、５３）にかかわらず、３０００円２回分の６０００円を１回のオートチャージでチャージできる設定とする。
また、支払債務が３０００円で、残高１０００円だった場合、不足分２０００円と、１回分のオートチャージ額３０００円の計５０００円を１回のオートチャージで行うようにしてもよい。
このように、残高と支払債務を比較し、支払債務の方が大きくて、残高がマイナスとなる場合、そのマイナスなる額と通常のオートチャージの額を１度にチャージするようにする。こうすることで、チャージの回数を減少させることができる。
なお、残高と支払債務を比較し、残高の方が大きくて、残高がマイナスとならない場合でも、残高が下限額（２０００円）を下回った場合、設定に従い通常のオートチャージが行われる。
【００６０】
（変形例３）
次に、携帯端末５のロック機能について説明する。
携帯端末５を紛失したり第三者に渡って、電子マネー機能やオートチャージ機能を悪用されるのを防止するため、電子マネーサーバ２は、リモートロック機能を有している。
リモートロック機能では、ユーザからのアクセスを受け、ユーザ認証が成功した場合に電子マネー機能やオートチャージのサービスを停止する。ユーザ認証に用いる情報の組み合わせは、例えば、（ユーザ氏名、電子メールアドレス、パスワード）、（ユーザ氏名、生年月日、電子メールアドレス、パスワード）、（電話番号、生年月日、電子メールアドレス、パスワード）などを用いることが可能である。
【００６１】
このロック機能は、選択により、ＩＣチップ１２の特定のエリア、特定のブロック、特定の記憶領域にロックをかけることができる。
そのため、仮に、ユーザが携帯端末５を紛失した場合、通常の電子マネー機能やオートチャージ機能を利用できないようにロックをかけ、一方で、本実施の形態にかかる公共料金等の自動支払の機能は存続させることが可能である。
従って、ユーザからリモートロック機能により、各機能の停止を設定した場合でも、ユーザの選択により、本実施の形態にかかる公共料金等の自動支払の機能のみをロックをかけずに継続させるように設定する。こうすることで、仮に、ユーザが携帯端末５を紛失した場合でも、とりあえず支払わなければならない、電気料金等を電子マネーで支払うことができる。
【００６２】
以上に説明した実施の形態、及び変形例によって、次の効果を得ることができる。
（１）本実施の形態によれば、定期的に発生する公共料金等の支払を電子マネーで支払うことができる。銀行引き落としと異なり、捺印した書面を送付するといった面倒な手続きを行う必要がなくなる。
また、日常生活のより多くの場面で電子マネーを使用できるようになるので、電子マネーの利便性がより一層向上する。特に、携帯端末５のみで、各種支払が完結できるので、現金を用意し、持ち歩く必要性がより減少する。
（２）本実施の形態によれば、支払の前に承認の手続きがあるため、本来支払う必要のない支払債務については、支払を拒否することができる。
（３）支払債務が存在することについて、通知を受けることができ、自動で支払を完了できるので、従来のように支払を失念してしまうことがなくなる。
（４）ステップ１３５の処理で「みなし承認」を適用することで、携帯端末５のユーザは、支払を「承認」する場合は、単に「放置」するだけで、支払の処理を進めることができる。
【００６３】
（５）変形例１によれば、複数の承認の手続きを一括して行えるので、毎月何度も承認の処理を行う煩わしさを減少させることができる。
（６）変形例２によれば、残高が不足していた場合、オートチャージを行うので、残高不足で支払が滞ることを防止できる。
また、オートチャージの設定を変えることで、支払債務の処理後に、残高が下限額以下になることを防止できる。
（７）変形例３によれば、携帯端末５のロック機能を選択的に用いることで、電子マネーの機能やオートチャージの機能は、停止させつつ、公共料金等の自動支払の機能のみをロックをかけずに継続させることができる。こうすることで、携帯端末５を紛失しても、必ず支払わなければならい公共料金等の支払を停止しないで済むこととなる。
【符号の説明】
【００６４】
１  電子マネーシステム
２  電子マネーサーバ
３  クレジット会社サーバ
４  インターネット
５  携帯端末
７  基地局
８  店舗端末
１０  端末機能部
１１  インターフェース部
１２  ＩＣチップ
１５  電子マネーアプリケーション
１６  端末通信部
１７  バリュー処理部
１８  電子マネー記憶部
３１  ＣＰＵ
３２  ＲＯＭ
３３  ＲＡＭ
３４  通信制御部
３５  記憶部
３６  プログラム格納部
３７  データ格納部
３８  ユーザＤＢ
３９  支払債務ＤＢ
４０  ログデータＤＢ
４１  オートチャージ登録ＤＢ
８１  加盟店
【図１】
0005550630.tif 000002
【図２】
0005550630.tif 000003
【図３】
0005550630.tif 000004
【図４】
0005550630.tif 000005
【図５】
0005550630.tif 000006
【図６】
0005550630.tif 000007
【図７】
0005550630.tif 000008