貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバであって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を前記携帯端末からの要求または独自に発生させる支払債務発生手段と、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信手段と、前記金額変更情報送信手段がバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消手段と、を備えることを特徴とする電子マネーサーバ。前記支払債務発生手段が独自に発生させた支払債務の場合、当該支払債務の所定日に前記携帯端末に支払の承認を求める支払承認要求手段と、前記支払承認要求手段による支払の承認要求に対して、前記携帯端末から承認の通知を受信した後、前記金額変更情報送信手段がバリューを支払債務額に対応させて減少させる金額変更情報を送信することを特徴とする電子マネーサーバ。前記支払承認要求手段による支払の承認要求に対して、前記携帯端末から不承認の通知を受信しないことを条件に、不応答の場合に承認があったものとみなすことを特徴とする請求項2記載の電子マネーサーバ。前記携帯端末から支払債務が存在するか否かの問い合わせを受け付ける支払債務存否確認受付手段をさらに備え、前記支払債務存否確認受付手段で、支払債務が存在するか否かの問い合わせを受け付けた際、支払債務が存在した場合、前記支払承認要求手段が支払の承認を求めることを特徴とする請求項2記載の電子マネーサーバ。前記携帯端末から、支払債務発生の要求、支払債務の額および固有の識別情報を受信する支払債務発生要求受付手段をさらに備え、前記支払債務発生要求受付手段が支払債務発生の要求を受信した後、前記支払債務発生手段が支払債務を発生させることを特徴とする請求項1記載の電子マネーサーバ。前記支払承認要求手段が、一定の要件の下にある複数の支払債務に対して、一括して支払いの承認を求めることを特徴とする請求項2、請求項3または請求項4記載の電子マネーサーバ。前記金額変更情報送信手段が、支払債務に対応した金額を減少させる金額変更情報を送信するとバリュー残高がマイナスになる場合、前記金額変更情報送信手段が当該マイナスになる金額および所定の金額を増額する金額変更情報を事前に送信することを特徴とする請求項1、請求項2、請求項3、請求項4、請求項5または請求項6記載の電子マネーサーバ。貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバにおける電子マネー処理方法であって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を前記携帯端末からの要求または独自に発生させる支払債務発生ステップと、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信ステップと、前記金額変更情報送信ステップでバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消ステップと、を備えることを特徴とする電子マネー処理方法。貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバにおける電子マネー処理プログラムであって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を前記携帯端末からの要求または独自に発生させる支払債務発生機能と、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信機能と、前記金額変更情報送信機能でバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消機能と、をコンピュータに実現させる電子マネー処理プログラム。貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバにおける電子マネー処理プログラムであって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を前記携帯端末からの要求または独自に発生させる支払債務発生機能と、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信機能と、前記金額変更情報送信機能でバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消機能と、をコンピュータに実現させる電子マネー処理プログラムが記憶された記憶媒体。本発明は、電子マネーを用いて、定期的な料金の支払いに対応できる電子マネーサーバ、電子マネー処理方法、電子マネー処理プログラム及び電子マネー処理プログラムが記憶された記憶媒体を提供することを目的とする。請求項1に記載の発明では、貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバであって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を前記携帯端末からの要求または独自に発生させる支払債務発生手段と、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信手段と、前記金額変更情報送信手段がバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消手段と、を備えることを特徴とする電子マネーサーバを提供する。請求項2に記載の発明では、前記支払債務発生手段が独自に発生させた支払債務の場合、当該支払債務の所定日に前記携帯端末に支払の承認を求める支払承認要求手段と、前記支払承認要求手段による支払の承認要求に対して、前記携帯端末から承認の通知を受信した後、前記金額変更情報送信手段がバリューを支払債務額に対応させて減少させる金額変更情報を送信することを特徴とする電子マネーサーバを提供する。請求項3に記載の発明では、前記支払承認要求手段による支払の承認要求に対して、前記携帯端末から不承認の通知を受信しないことを条件に、不応答の場合に承認があったものとみなすことを特徴とする請求項2記載の電子マネーサーバを提供する。請求項4に記載の発明では、前記携帯端末から支払債務が存在するか否かの問い合わせを受け付ける支払債務存否確認受付手段をさらに備え、前記支払債務存否確認受付手段で、支払債務が存在するか否かの問い合わせを受け付けた際、支払債務が存在した場合、前記支払承認要求手段が支払の承認を求めることを特徴とする請求項2記載の電子マネーサーバを提供する。請求項5に記載の発明では、前記携帯端末から、支払債務発生の要求、支払債務の額および固有の識別情報を受信する支払債務発生要求受付手段をさらに備え、前記支払債務発生要求受付手段が支払債務発生の要求を受信した後、前記支払債務発生手段が支払債務を発生させることを特徴とする請求項1記載の電子マネーサーバを提供する。請求項6に記載の発明では、前記支払承認要求手段が、一定の要件の下にある複数の支払債務に対して、一括して支払いの承認を求めることを特徴とする請求項2、請求項3または請求項4記載の電子マネーサーバを提供する。請求項7に記載の発明では、前記金額変更情報送信手段が、支払債務に対応した金額を減少させる金額変更情報を送信するとバリュー残高がマイナスになる場合、前記金額変更情報送信手段が当該マイナスになる金額および所定の金額を増額する金額変更情報を事前に送信することを特徴とする請求項1、請求項2、請求項3、請求項4、請求項5または請求項6記載の電子マネーサーバを提供する。請求項8に記載の発明では、貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバにおける電子マネー処理方法であって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を前記携帯端末からの要求または独自に発生させる支払債務発生ステップと、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信ステップと、前記金額変更情報送信ステップでバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消ステップと、を備えることを特徴とする電子マネー処理方法を提供する。請求項9に記載の発明では、貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバにおける電子マネー処理プログラムであって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を前記携帯端末からの要求または独自に発生させる支払債務発生機能と、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信機能と、前記金額変更情報送信機能でバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消機能と、をコンピュータに実現させる電子マネー処理プログラムを提供する。請求項10に記載の発明では、貨幣価値の金額を電子データで表した電子マネーのバリューを記憶する機能を備え、固有の識別情報を有する携帯端末と接続可能な電子マネーサーバにおける電子マネー処理プログラムであって、前記携帯端末の固有の識別情報と対応付けて所定日に支払うべき支払債務を前記携帯端末からの要求または独自に発生させる支払債務発生機能と、前記携帯端末に記憶されたバリューを増減させる金額変更情報を前記携帯端末に送信する金額変更情報送信機能と、前記金額変更情報送信機能でバリューを支払債務額に対応させて減少させる金額変更情報を送信し、当該金額変更情報で携帯端末に記憶されたバリューを減少させたとき、当該支払債務を抹消させる支払債務抹消機能と、をコンピュータに実現させる電子マネー処理プログラムが記憶された記憶媒体を提供する。本発明によれば、電子マネーにより、定期的な料金の支払いを行うことができる。A実施形態の概要図1は、本実施の形態に係る電子マネーシステムの基本的な構成を説明するための図である。この電子マネーシステム1は、電子マネーサーバ2、クレジット会社サーバ3、インターネット4、携帯端末5、基地局7、加盟店81に設置された店舗端末8などから構成されている。また、携帯端末5は、図2に示すように、バリューを記憶するICチップ12と、電子マネーアプリケーション15を備えている。この電子マネーアプリケーション15は、電子マネーに関する各種の処理を行う。また、後述するオートチャージに関する、予めユーザが設定した残高基準金額とオートチャージ金額を記憶している。以下、括弧に示した番号の順に従って本実施の形態の処理が行われる。1電子マネーサーバ2で、携帯端末5からの要請により、または電子マネーサーバ側2で、電子マネー機能部IDに対応付けて、支払債務を発生させる。具体的には、各種の公共料金、新聞の定期購読料、税金のなどの支払である。2携帯端末5の電子マネーアプリケーション15は、電子マネーサーバ2に支払債務の確認要求を出す。3電子マネーサーバ2では、支払債務の有無を確認し、支払債務が存在しなければ、その旨を通知し、支払債務が存在すれば、支払接続要求を送信する。4これに対して、携帯端末5の電子マネーアプリケーション15は、ユーザから支払承認の入力を受けると、支払接続要求承認を電子マネーサーバ2へ送信する。5この支払接続要求承認を受けた電子マネーサーバ2は、支払要求を携帯端末5へ送信し、ICチップ12に記憶されたバリューを減額する。同時に、振込先サーバに送金の手続を行う。6そして、電子マネーサーバ2は、発生してた支払債務を消滅させ、携帯端末5へ、支払が完了した旨を通知する。B実施形態の詳細第1の実施の形態図1は、本実施の形態に係る電子マネーシステム1のネットワーク構成を示した図である。この電子マネーシステム1は、電子マネーサーバ2、クレジット会社サーバ3、インターネット4、携帯端末5、基地局7、加盟店81に設置された店舗端末8などから構成されており、これらが互いに協働することで電子マネーシステム1を維持、運営している。携帯端末5は、例えば、スマートフォンや携帯電話などのインターネット通信機能を有する携帯型の端末であって、ICチップ12を内蔵している。携帯端末5は、基地局7と無線通信することによりインターネット4を介して電子マネーサーバ2と通信することができる。ICチップ12は、近距離無線通信用のアンテナを備えており、店舗端末8と近距離無線通信を行うことができる。ICチップ12は、バリューを記憶することができ、店舗端末8から送信されるコマンドを実行することにより、チャージや決済を行うことができる。また、ICチップ12は、携帯端末5を介して電子マネーサーバ2と通信し、電子マネーサーバ2から送信されるコマンドを実行することにより、チャージや決済を行うこともできる。携帯端末5には、電子マネーアプリケーション15がインストールされている。電子マネーアプリケーション15は、携帯端末5において、電子マネーに関する各種処理を行う。また、ICチップ12に対してオートチャージを行う機能も有している。この機能は、定期的にICチップ12のバリュー残高を確認し、バリュー残高が残高基準金額以下または未満である場合は、電子マネーサーバ2にアクセスして、電子マネーサーバ2にチャージを要求する。この要求に対し、電子マネーサーバ2は、ICチップ12に対してコマンドを送信し、ICチップ12にチャージする。このように、電子マネーアプリケーション15によって行われる自動的なチャージをオートチャージと呼ぶことにする。電子マネーサーバ2は、電子マネーシステム1におけるバリューの流通を管理するサーバである。電子マネーサーバ2は、定期的、又は、不定期に店舗端末8からチャージや決済の履歴を記録したログデータを収集する。そして、これとICチップ12に直接チャージや決済を行った際のログデータを合わせて集計し、バリューの流通と通貨との対応をとっている。加盟店81は、小売店舗、営業所、営業車両などのユーザから対価を取って商品やサービスを提供する事業者である。加盟店81は、電子マネーシステム1が提供する電子マネーサービスを利用する連合体に加盟しており、単数、又は複数の店舗端末8を備えている。店舗端末8は、ICチップ12と近距離無線通信を行い、ICチップ12にコマンドを送信してチャージや決済を行う。店舗端末8は、ICチップ12との処理内容を記録したログデータを定期、又は不定期にバッチ処理にて電子マネーサーバ2に送信する。クレジット会社サーバ3は、オートチャージを行う際に用いられる構成であり、クレジット会社がクレジットカードによる支払を管理するためのサーバである。ICチップ12のユーザは、当該クレジット会社と契約しており、電子マネーサーバ2に自己のクレジットカード番号を登録してある。クレジット会社サーバ3は、電子マネーサーバ2がICチップ12にチャージする際に、その代金をユーザのクレジットカード番号にて決済する。図2は、携帯端末5の構成を説明するための図である。携帯端末5は、端末機能部10、ICチップ12、両者を接続するインターフェース部11、及び近距離無線用のアンテナを備えたICチップで形成された端末通信部16を備えている。なお、端末通信部16を内蔵したICチップ12も存在する。ICチップ12は、CPUCentralProcessingUnit、ROMReadOnlyMemory、RAMRandomAccessMemory、EEPROMElectricallyErasableProgrammableROMなどを備えており、コンピュータとしての機能を有している。後述するように、端末機能部10もコンピュータとしての機能を有しており、携帯端末5は、2つのコンピュータがインターフェース部11によって接続した状態となっている。EEPROMには、OSOperatingSystemの他、例えば、ポイントカードとして機能するアプリケーションや会員カードとして機能するアプリケーションなど、複数のアプリケーションソフトウェアをインストールして実行することが可能である。本実施の形態では、電子マネー処理用のアプリケーションプログラムがインストールしてあり、当該プログラムをCPUで実行することにより、バリュー処理部17、電子マネー記憶部18などが構成される。電子マネー記憶部18は、電子マネー機能部ID、バリュー残高、ログデータなどを記憶している。電子マネー機能部IDは、ICチップ12にインストールされている電子マネー処理用のアプリケーションを特定するための識別情報である。バリュー残高は、現在記憶しているバリューの金額である。ログデータは、チャージ、決済、残高参照など、電子マネーに関する処理が行われた場合の処理内容を記録したログデータである。バリュー処理部17は、端末通信部16を介して店舗端末8から入力されたコマンドを実行する。これにより、バリュー処理部17は、チャージや決済、残高参照、電子マネー機能部IDの参照、ログデータの参照などを行う。なお、端末通信部16は、近距離無線用のアンテナを備えており、店舗端末8とバリュー処理部17の通信を仲介する。店舗端末8は、近距離無線用のアンテナを備えたリーダライタを備えており、端末通信部16は、このリーダライタを介して店舗端末8と通信する。チャージを行うチャージコマンドとしては、加算コマンド、又は上書きコマンドを利用することができる。加算コマンドは、パラメータで指定した金額分の加算処理をバリュー処理部17に行わせる命令である。例えば、1000円分のチャージを行う場合、バリュー処理部17は、店舗端末8から入力された加算コマンドに従って、電子マネー記憶部18のバリュー残高に1000円を加算し、加算後の値を電子マネー記憶部18のバリュー残高に上書きする。上書きコマンドは、パラメータで指定した金額での上書き処理をバリュー処理部17に行わせる命令である。例えば、1000円分のチャージを行う場合、まず、店舗端末8は、残高参照コマンドによってICチップ12からバリュー残高を読み出す。次に、店舗端末8は、当該バリュー残高に1000円を加算し、加算後の値で上書きする上書きコマンドをICチップ12に入力する。ICチップ12は、これを実行して、電子マネー記憶部18のバリュー残高を上書きする。また、決済を行う決済コマンドとしては、減算コマンド、又は上書きコマンドを利用することができる。減算コマンドは、パラメータで指定した金額分の減算処理をバリュー処理部17に行わせる命令である。例えば、1000円分の決済を行う場合、バリュー処理部17は、店舗端末8から入力された減算コマンドに従って、電子マネー記憶部18のバリュー残高から1000円を減算し、減算後の値を電子マネー記憶部18のバリュー残高に上書きする。上書きコマンドで決済する場合は、上書きコマンドでチャージする場合と同様にして行うことができる。チャージコマンドに加算コマンドと上書きコマンドの何れを用いるか、また、決済コマンドに減算コマンドと上書きコマンドの何れを用いるかは、電子マネーシステム1のシステム設計による。端末機能部10は、CPU、ROM、RAM、EEPROM、マルチタッチスクリーン、スピーカ、マイクロフォン、RF回路などを備えたコンピュータであって、インターフェース部11を介してICチップ12と接続している。端末機能部10は、図示しないRF回路によって基地局7と通信することができ、また、インターフェース部11を介してICチップ12と通信することができる。EEPROMには、OSの他、ブラウザやゲームなど複数のアプリケーションソフトウェアをインストールして実行することが可能である。マルチタッチスクリーンは、携帯端末5の表示画面に設置されており、ユーザが画面を指先でタッチして項目を選択するなどしてアプリケーションソフトウェアを操作できるようになっている。本実施の形態では、EEPROMに電子マネーに関する各種サービスを提供するアプリケーションソフトウェアである電子マネーアプリケーション15をインストールして動作させる。電子マネーアプリケーション15は、例えば、電子マネーサーバ2から電子マネーアプリケーション15用のプログラムを端末機能部10にダウンロードしてインストールしたり、あるいは、当該プログラムを記録した記録媒体をユーザに配布して、当該記録媒体から端末機能部10にインストールして形成される。電子マネーアプリケーション15は、携帯端末5の通信機能を用いて電子マネーサーバ2と通信することができる。そして、電子マネーアプリケーション15は、電子マネーサーバ2に対してユーザ登録、支払債務存在の有無の問い合せ、支払接続の承認、オートチャージの設定を行ったり、また、電子マネーサーバ2と協働してオートチャージを実施したりする。また、電子マネーアプリケーション15は、インターフェース部11を介してICチップ12と通信することもできる。これにより、電子マネーアプリケーション15は、ICチップ12に残高参照コマンドを入力してICチップ12からバリュー残高を読み出したり、ID参照コマンドを入力して電子マネー機能部IDを読み出したり、ログデータ参照コマンドを入力してログデータを読み出したりすることができる。図3は、電子マネーサーバ2のハードウェア的な構成の一例を示した図である。電子マネーサーバ2は、CPU31、ROM32、RAM33、通信制御部34、記憶部35などがバスラインで接続されて形成され、情報処理サーバを構成している。CPU31は、所定のプログラムに従って各種の情報処理を行う中央処理装置である。本実施の形態では、携帯端末5から支払債務の有無の問い合わせを受けたり、オートチャージの要求を受けてオートチャージを行う。また、店舗端末8からログデータを収集して集計したりもする。なお、これらの機能の全てをCPU31で行う必要はなく、複数台のサーバ装置を組み合わせて電子マネーサーバ2と同等の機能を有するシステムを構成してもよい。ROM32は、読み出し専用のメモリであり、電子マネーサーバ2を動作させるための基本的なプログラムやパラメータなどが記憶されている。RAM33は、読み書き可能なメモリであって、CPU31にワーキングメモリを提供したり、記憶部35に記憶されたプログラムやデータをロードして記憶したりなどする。通信制御部34は、店舗端末8と通信したり、インターネット4や基地局7を介して携帯端末5と通信したりする。記憶部35は、例えばハードディスクなどの大容量の記憶装置を用いて構成されており、各種プログラムを格納したプログラム格納部36、データを格納したデータ格納部37などから構成されている。プログラム格納部36には、OS、オートチャージを行うためのプログラム、ログデータを処理するプログラム、その他のプログラムが格納されている。データ格納部37には、携帯端末5や電子マネーカードのICチップ12で電子マネーシステム1を使用するユーザを登録したユーザDBデータベース38、発生した支払債務を記録する支払債務DB39、ログデータDB40、オートチャージの条件などを登録したオートチャージ登録DB41、図示しないが、加盟店81を登録した加盟店DB、バリューによる取引履歴を記録した取引履歴DB、その他のデータベースが格納されている。ユーザDB38には、ユーザID、パスワード、ユーザの氏名、住所、生年月日、電話番号、電子メールアドレス、ICチップ12の電子マネー機能部ID、クレジットカード番号、オートチャージの利用登録の有無などが、ユーザIDごとに対応づけられて記憶されている。このように、電子マネーシステム1では、オートチャージを利用する旨をユーザDB38に登録したユーザがオートチャージサービスの対象となる。なお、ユーザDB38には、ユーザの預貯金口座例えば、銀行口座からオートチャージの代金を引き落とす場合は、ユーザの預貯金口座番号例えば、銀行口座番号を記憶し、オートチャージ金額を電話料金に合算する場合は、携帯電話会社のユーザIDを記憶する。また、複数の決済手段クレジットカード、預貯金口座などを用いる場合は、決済手順を記憶することもできる。図4は、支払債務DB39の論理的構成を説明するための図である。この支払債務DB39には、ユーザ識別情報、取引ID、支払金額、支払日、支払先、支払承認の有無、支払支払の完了の有無が記憶されている。ユーザ識別情報とは、ユーザを識別するための情報であり、例えば、電子マネー機能部IDを用いることができる。取引IDとは、支払債務を発生させた取引を識別するための情報である。具体的には、○○氏の1月分○×新聞購読料を識別するための情報である。この取引IDは、支払債務発生の前提となる契約の際に予め定めておく。そして、支払債務発生時に、当該取引IDに係る取引について、支払債務を発生させた旨の通知を料金の振込先に行うようにしてもよい。また、振込サーバ100への振り込みの際、紐づけて通知するようになっている。こうすることで、振込先債権者は何に対する支払が行われたのかを確認することができる。次に、図5のフローチャートを参照して、本実施の形態に係る定期的な料金の支払い処理を説明する。電子マネーサーバ2側で、電子マネー機能部IDに対応付けて支払債務を発生させるステップ105。この支払債務の発生には、債権者と債務者の契約ないし同意が存在することが前提となる。具体的には、○○氏の毎月の○×新聞購読料4000円を毎月25日電子マネーで支払う。○○氏は、電子マネー機能部IDを備えた携帯端末5で、支払処理を行う。といったものである。この際取引IDも取り決めておく。この支払債務の発生は、契約に基づいて、電子マネーサーバ2側で自発的に行う。しかし、例えば、携帯端末5から支払債務の発生要求を受けて発生するようにしてもよいステップ100a。この場合は、ユーザは、携帯端末5の電子マネーアプリケーション15を起動させ、電子マネー機能部IDと取引IDを紐付けて送信し、支払債務の発生を要請する。また、振込先サーバ100からの支払債務の発生要求を受けて発生するようにしてもよいステップ100b。このケースでは、支払債務の発生要求とともに取引IDも電子マネーサーバ2へ送信するようにする。電子マネーサーバ2は、支払債務を発生されたときに、当該発生債務を支払債務DB39に記録する。このとき、取引IDも記録されるため、両者が紐付くこととなる。支払債務が発生した場合、電子マネーサーバ2は、振込先サーバ100に支払債務が発生した旨及び取引IDを通知するステップ110。この処理は、必ずしも必須のものでなく、省略することもできる。なお、電子マネーサーバ2は、支払債務が発生したとき、または発生後所定の時間経過後に例えば電子メールで携帯端末5にその旨を通知するようにしてもよい。事前に通知しておくことで、予め決済に必要なバリューのチャージを促し、決済時不足分が出ないようにすることができる。一方、携帯端末5の電子マネーアプリケーション15は、電子マネーサーバ2に対して、支払債務が存在しているか否かを確認する支払債務の確認要求を行うステップ115。この確認は、毎日行うように設定してもよいが、例えば1日おき、週2回、毎週など状況に応じて適宜設定するようにできる。具体的には、携帯端末5は、電子マネーアプリケーション15を起動し、支払債務が存在するか否かのポーリングを行う。これに対して、電子マネーサーバ2は、支払債務が存在するか否かの確認を行うステップ120。この確認は、支払債務DB39を検索することにより行う。その結果、支払債務支払期日が到達しているものが存在しない場合はステップ120;N、電子マネーサーバ2は、支払債務が存在しない旨を携帯端末5に通知するステップ125。一方、支払債務が存在し、且つ支払期日が到達している場合はステップ120;Y、電子マネーサーバ2は、携帯端末5に支払接続要求を送信するステップ130。この支払接続要求を受けて、電子マネーアプリケーション15は、携帯端末5の画面に図6に示すような表示を行い、ユーザからの承認を求める。ユーザが承認ボタンをタッチすることで、ユーザからの承認する旨の意思表示を受信した場合は、電子マネーアプリケーション15は、支払接続要求承認の通知を電子マネーサーバ2へ送信するステップ135。電子マネーサーバ2は、携帯端末5のICチップ12に対して減算コマンドを送信して支払要求を行うステップ140。これを受けて、ICチップ12で減算処理支払が行われると、携帯端末5の電子マネーアプリケーション15は、減算が行われた旨を電子マネーサーバ2へ通知するステップ145。これを受けて、電子マネーサーバ2は、支払債務を消滅させる。具体的には、支払債務DB39の支払を済と入力する。同時に、対応する金額を振込先サーバに送金するステップ150。このとき、取引IDも送信する。こうすることで、振込先サーバ100でどの取引に関する支払かを識別することができる。ここで、電子マネーサーバ2は、公共料金の徴収元へ支払うデータを出力する。そして、公共料金の徴収元へ電子的に振り込んでもよいし、電子マネーサーバ2の運営者が振込を行うための振込用紙を出力して、別途振込を行うようにしてもよい。そして、電子マネーサーバ2は、支払完了通知を携帯端末5に送信してステップ155、処理を終了する。本実施の形態の処理は、例えば新聞の購読料、電気料金、ガス料金の場合は、上記処理を月1回、毎月繰り返すこととなる。また、水道料金のように2ヶ月に1回の支払の場合は、2ヶ月に1回毎に上記処理を繰り返す。さらに、固定資産税のように年4回に分割納付が可能なものについては、年4回上記処理を繰り返す。なお、固定資産税のように、一括納付と分割納付が可能なものについては、第1回目の納付の際に、どちらの納付にするかをユーザに選択させるようにしてもよい。次に、図5のステップ135における支払接続要求承認について他の例を説明する。上記した例では、支払債務が存在した場合ステップ120;Y、電子マネーサーバ2から携帯端末5に対して支払接続要求を出しステップ130、これに対し、携帯端末5から支払接続要求承認ステップ135を送信する構成とした。しかし、本実施の形態は、これに限られず、他の時点で携帯端末5から承認を得る構成としてもよい。例えば、ステップ100aの携帯端末5から支払債務発生要求があった場合、この時点でステップ130、ステップ135に相当する処理を行い、事前に承認を得ておくようにする。また、ステップ100bの振込先サーバ100から支払債務発生要求があった場合にも、この時点でステップ130、ステップ135に相当する処理を行い、事前に承認を得ておくようにする。この承認を得る処理は、ステップ105の支払債務を発生させる処理の前であっても後であってもよい。なお、上記例では、既に承認を得ているので、ステップ120ステップ120;Yの場合、ステップ130、ステップ135の処理を省略し、直ちにステップ140の処理へ移行することができる。次に、ステップ135の携帯端末5から支払接続要求承認の通知が送信されてこない場合の処理について説明する。この場合、積極的に不承認の通知がないことを条件として、承認があったものとみなすように構成することもできる。このように構成することで、携帯端末5のユーザが対応を失念した場合に、決済を停止してしまうという不都合を防止することができる。一方、携帯端末5のユーザからすると、ステップ130の要求を受信した際、何ら対応せずに、単に放置しておけば自動的に承認とすることができる。但し、このように構成する場合は、事前に不応答の場合は、みなし承認となる旨を周知させておくことが重要となる。変形例1上記実施の形態では、各支払債務毎に支払の承認を得ていたが、その都度承認を得るのは煩雑であり、ユーザの利便性に反することも考えられる。そこで、一定期間の支払債務について一括して承認を行うようにする。例えば、月末に新聞の購読料、電気料金、水道料金の支払がある場合、これらの図5のステップ130の処理を一括して行う。こうすることで、ユーザが何度も承認の処理を行う煩わしさを減少させることができる。一括承認を求める際に、ユーザの利便のため、トータルで必要な金額を提示するようにしてもよい。一方、電子マネーサーバ2側では、各支払債務の処理を各々通常の債務の処理と同様に行う。なお、この変形例1でも上記の例と同様に、承認を得る時点を図5の例と異なる時点にしたり、不承認の通知がないことを条件として、不応答の場合は、みなし承認となる構成としてもよい。変形例2次に、図5のステップ140で、携帯端末5に支払要求した際、残高不足で決済ができない場合の処理について説明する。残高が不足した場合、オートチャージを行うようにする。まず、このオートチャージを説明する。電子マネーアプリケーション15は、ユーザが設定した残高基準金額を記憶している。残高基準金額は、オートチャージを実行する際の基準となる金額である。電子マネーアプリケーション15は、定期的に例えば、1時間おきにICチップ12に残高参照コマンドを入力してバリュー残高を取得し、バリュー残高が残高基準金額以下あるいは未満となると、オートチャージ動作を開始する。この場合、電子マネーアプリケーション15は、電子マネーサーバ2にアクセスしてオートチャージの要求を行う。そして、電子マネーアプリケーション15は、この要求に対して電子マネーサーバ2が送信してきたチャージコマンドをICチップ12に入力して、ICチップ12にチャージさせる。この際、電子マネーアプリケーション15は、電子マネーサーバ2からICチップ12に至る通信経路を暗号化してセキュリティを高めている。なお、電子マネーサーバ2にオートチャージする金額を記憶しておきオートチャージ登録DB41、これをオートチャージに使用するが、電子マネーアプリケーション15にオートチャージする金額を記憶しておき、これをオートチャージの度に電子マネーサーバ2に送信するように構成してもよい。電子マネーサーバ2のオートチャージ登録DB41には図3参照、電子マネー機能部ID、残高基準額、オートチャージ金額、日額限度額、月額限度額などが、ユーザごとに対応づけられて記憶されている。残高基準金額は、電子マネーアプリケーション15に記憶しているものと同じである。そのため、必ずしも電子マネーサーバ2が記憶する必要はないが、ICチップ12の管理のために電子マネーサーバ2にも記憶してある。オートチャージ金額は、1回のオートチャージでICチップ12にチャージする金額である。日額限度額は、オートチャージによる1日当たりのチャージ合計値の上限値である。月額限度額は、オートチャージによる1ヶ月当たりのチャージ合計値の上限値である。また、1日当たりの限度回数、1ヶ月当たりの限度回数を設定するように構成してもよい。図7は、携帯端末5に表示されるオートチャージ設定画面を示した図である。オートチャージ設定画面は、電子マネーアプリケーション15が電子マネーサーバ2にアクセスして表示したものである。なお、電子マネーサーバ2が携帯端末5に提供する画面には、この他に、ユーザ登録画面など各種のものがある。オートチャージ設定画面では、1.オートチャージ金額を選択して下さい。との表示の下に、残高基準金額設定欄51とオートチャージ金額設定欄52が表示されている。残高基準金額設定欄51、オートチャージ金額設定欄52は、何れもコンボボックスとなっており、ユーザがそれぞれ、残高基準金額、1回のオートチャージでチャージする金額を選択するようになっている。なお、ユーザが任意の金額を入力するように構成することもできる。その下側には、2.1日のオートチャージ上限額を選択して下さい。との表示があり、これに続いて上限額設定欄53が表示されている。上限額設定欄53は、ドロップダウンメニューとなっており、ユーザが、1日の上限額を選択するようになっている。なお、ユーザが任意の金額を入力するように構成することもできる。なお、図示しないが、更に、3.1ヶ月のオートチャージ上限額を選択して下さい。などと、1ヶ月間の上限を選択あるいは任意の金額を入力する欄も設けられている。更に、上限額設定欄53の下側には、設定ボタン54と戻るボタン55が表示されている。設定ボタン54は、ユーザが選択した内容を電子マネーサーバ2に通知するためのボタンであり、設定ボタン54が選択されると、電子マネーアプリケーション15は、ユーザが設定した内容を電子マネーサーバ2に送信する。戻るボタン55は、オートチャージ設定画面を表示する前に表示していた画面に戻るためのボタンである。オートチャージ設定の処理は、携帯端末5のICチップ12に実装されたCPU、携帯端末5の端末機能部10に実装されたCPU、電子マネーサーバ2のCPU31が、それぞれ、電子マネー処理用のアプリケーションプログラム、電子マネーアプリケーション15のプログラム、及び電子マネーサーバ用のプログラムに従って行う。ここで、図7での設定を前提に、仮に新聞の購読料4000円の支払債務が存在し、残高が1000円だったとする。この場合、所定値の3000円をオートチャージすることで支払を完了することができる。しかし、直ちに、残金が0円となってしまう。そこで、再度オートチャージが必要となる。このような場合、例えば、図5のステップ135の承認を条件に、1日のオートチャージ上限額図7、53にかかわらず、3000円2回分の6000円を1回のオートチャージでチャージできる設定とする。また、支払債務が3000円で、残高1000円だった場合、不足分2000円と、1回分のオートチャージ額3000円の計5000円を1回のオートチャージで行うようにしてもよい。このように、残高と支払債務を比較し、支払債務の方が大きくて、残高がマイナスとなる場合、そのマイナスなる額と通常のオートチャージの額を1度にチャージするようにする。こうすることで、チャージの回数を減少させることができる。なお、残高と支払債務を比較し、残高の方が大きくて、残高がマイナスとならない場合でも、残高が下限額2000円を下回った場合、設定に従い通常のオートチャージが行われる。変形例3次に、携帯端末5のロック機能について説明する。携帯端末5を紛失したり第三者に渡って、電子マネー機能やオートチャージ機能を悪用されるのを防止するため、電子マネーサーバ2は、リモートロック機能を有している。リモートロック機能では、ユーザからのアクセスを受け、ユーザ認証が成功した場合に電子マネー機能やオートチャージのサービスを停止する。ユーザ認証に用いる情報の組み合わせは、例えば、ユーザ氏名、電子メールアドレス、パスワード、ユーザ氏名、生年月日、電子メールアドレス、パスワード、電話番号、生年月日、電子メールアドレス、パスワードなどを用いることが可能である。このロック機能は、選択により、ICチップ12の特定のエリア、特定のブロック、特定の記憶領域にロックをかけることができる。そのため、仮に、ユーザが携帯端末5を紛失した場合、通常の電子マネー機能やオートチャージ機能を利用できないようにロックをかけ、一方で、本実施の形態にかかる公共料金等の自動支払の機能は存続させることが可能である。従って、ユーザからリモートロック機能により、各機能の停止を設定した場合でも、ユーザの選択により、本実施の形態にかかる公共料金等の自動支払の機能のみをロックをかけずに継続させるように設定する。こうすることで、仮に、ユーザが携帯端末5を紛失した場合でも、とりあえず支払わなければならない、電気料金等を電子マネーで支払うことができる。以上に説明した実施の形態、及び変形例によって、次の効果を得ることができる。1本実施の形態によれば、定期的に発生する公共料金等の支払を電子マネーで支払うことができる。銀行引き落としと異なり、捺印した書面を送付するといった面倒な手続きを行う必要がなくなる。また、日常生活のより多くの場面で電子マネーを使用できるようになるので、電子マネーの利便性がより一層向上する。特に、携帯端末5のみで、各種支払が完結できるので、現金を用意し、持ち歩く必要性がより減少する。2本実施の形態によれば、支払の前に承認の手続きがあるため、本来支払う必要のない支払債務については、支払を拒否することができる。3支払債務が存在することについて、通知を受けることができ、自動で支払を完了できるので、従来のように支払を失念してしまうことがなくなる。4ステップ135の処理でみなし承認を適用することで、携帯端末5のユーザは、支払を承認する場合は、単に放置するだけで、支払の処理を進めることができる。5変形例1によれば、複数の承認の手続きを一括して行えるので、毎月何度も承認の処理を行う煩わしさを減少させることができる。6変形例2によれば、残高が不足していた場合、オートチャージを行うので、残高不足で支払が滞ることを防止できる。また、オートチャージの設定を変えることで、支払債務の処理後に、残高が下限額以下になることを防止できる。7変形例3によれば、携帯端末5のロック機能を選択的に用いることで、電子マネーの機能やオートチャージの機能は、停止させつつ、公共料金等の自動支払の機能のみをロックをかけずに継続させることができる。こうすることで、携帯端末5を紛失しても、必ず支払わなければならい公共料金等の支払を停止しないで済むこととなる。