(57)【要約】【課題】障害が発生した場合に取引が成功したか否かを確認できるようにする。【解決手段】入金端末２に電子マネーカード５をセットして、入金端末２に紙幣を投入すると、投入金額分のバリューを電子マネーカード５にチャージすることができる。入金端末２は、電子マネーカード５にチャージを行う際に電子マネーサーバ３と通信し、電子マネーサーバ３が取引ログを作成する。電子マネーシステム１は電子マネーサーバ３が取引ログを作成した時点で紙幣を受領する。そのため、入金端末２は、紙幣を収納したにも関わらず取引ログが作成されたか不明な場合は、取引未完ログを生成して電子マネーサーバ３に送信する。電子マネーサーバ３は、入金端末２から取引未完ログを受信した場合、当該取引未完ログに対応する取引ログが作成されているか否かを確認し、取引ログが作成されていない場合は、その旨を出力する。【選択図】図１
2009053753.tif 000002
【特許請求の範囲】
【請求項１】
貨幣価値を電子データとして記憶する貨幣端末から当該貨幣端末を特定する貨幣端末ＩＤを取得するＩＤ取得手段と、
通貨を受け付けて収納する収納手段と、
前記取得した貨幣端末ＩＤと前記収納した通貨の金額を含む入金情報を所定のサーバに送信する入金情報送信手段と、
前記所定のサーバから、前記送信した入金情報の記録を完了した旨の記録完了通知を受信する記録完了通知受信手段と、
前記記録完了通知を受信した場合に、前記収納した通貨の金額分の貨幣価値を前記貨幣端末に増額させる増額手段と、
前記所定のサーバから前記記録完了通知を受信しなかった場合に、前記入金情報を特定する特定情報を生成する特定情報生成手段と、
前記生成した特定情報を前記所定のサーバに送信する特定情報送信手段と、
を具備したことを特徴とする入金端末。
【請求項２】
前記所定のサーバから前記記録完了通知を受信しなかった場合に、前記所定のサーバに前記入金情報の記録を完了したか否かを確認させる確認情報を前記所定のサーバに送信する確認情報送信手段を具備したことを特徴とする請求項１に記載の入金端末。
【請求項３】
前記特定情報生成手段は、前記送信した確認情報に対して前記所定のサーバから応答が無かった場合に特定情報を生成することを特徴とする請求項２に記載の入金端末。
【請求項４】
前記所定のサーバは、前記入金情報を受信してから当該入金情報を記録するための準備を行い、当該準備が完了した旨の準備完了通知を送信し、
前記所定のサーバが送信した準備完了通知を受信する準備完了通知受信手段を具備し、
前記収納手段は、前記準備完了通知を受信した後は、前記収納した通貨の返金を行わないことを特徴とする請求項１、請求項２、又は請求項３に記載の入金端末。
【請求項５】
通貨の投入を受け付けて収納し、貨幣価値を電子データとして記憶する貨幣端末に当該通貨の金額分の貨幣価値を増額させる入金端末と通信するサーバであって、
前記入金端末から、貨幣端末を特定する貨幣端末ＩＤと収納した通貨の金額を含む入金情報を受信する入金情報受信手段と、
前記受信した入金情報を記録する入金記録手段と、
前記記録を完了した場合に、記録完了通知を前記入金端末に送信する完了通知送信手段と、
前記入金端末から、当該入金端末が送信した入金情報を特定する特定情報を受信する特定情報受信手段と、
前記特定情報を受信した場合に、当該特定情報を用いて、前記入金端末が送信した入金情報を前記入金記録手段で記録したか否かを確認する確認手段と、
前記確認手段による確認結果を出力する出力手段と、
を具備したことを特徴とするサーバ。
【請求項６】
前記入金端末から当該入金端末が送信した入金情報の記録を完了したか否かを確認させる確認情報を受信する確認情報受信手段を具備し、
前記入金情報を記録する前に前記確認情報を受信した場合は、前記入金記録手段による入金情報の記録から処理を開始し、前記入金情報を記録した後に前記確認情報を受信した場合は、前記完了通知送信手段による記録完了通知の送信から処理を開始することを特徴とする請求項５に記載のサーバ。
【請求項７】
ＩＤ取得手段と、収納手段と、入金情報送信手段と、記録完了通知受信手段と、増額手段と、特定情報生成手段と、特定情報送信手段と、を備えた入金端末において、
前記ＩＤ取得手段で、貨幣価値を電子データとして記憶する貨幣端末から当該貨幣端末を特定する貨幣端末ＩＤを取得するＩＤ取得ステップと、
前記収納手段で、通貨を受け付けて収納する収納ステップと、
前記入金情報送信手段で、前記取得した貨幣端末ＩＤと前記収納した通貨の金額を含む入金情報を所定のサーバに送信する入金情報送信ステップと、
前記記録完了通知受信手段で、前記所定のサーバから、前記送信した入金情報の記録を完了した旨の記録完了通知を受信する記録完了通知受信ステップと、
前記増額手段で、前記記録完了通知を受信した場合に、前記収納した通貨の金額分の貨幣価値を前記貨幣端末に増額させる増額ステップと、
前記特定情報生成手段で、前記所定のサーバから前記記録完了通知を受信しなかった場合に、前記入金情報を特定する特定情報を生成する特定情報生成ステップと、
前記特定情報送信手段で、前記生成した特定情報を前記所定のサーバに送信する特定情報送信ステップと、
から構成されたことを特徴とする入金方法。
【請求項８】
通貨の投入を受け付けて収納し、貨幣価値を電子データとして記憶する貨幣端末に当該通貨の金額分の貨幣価値を増額させる入金端末と通信するコンピュータが行う情報処理方法であって、
前記コンピュータは、入金情報受信手段と、入金記録手段と、完了通知送信手段と、特定情報受信手段と、確認手段と、出力手段と、を備えており、
前記入金情報受信手段で、前記入金端末から、貨幣端末を特定する貨幣端末ＩＤと収納した通貨の金額を含む入金情報を受信する入金情報受信ステップと、
前記入金記録手段で、前記受信した入金情報を記録する入金記録ステップと、
前記完了通知送信手段で、前記記録を完了した場合に、記録完了通知を前記入金端末に送信する完了通知送信ステップと、
前記入金端末から、当該入金端末が送信した入金情報を特定する特定情報を前記特定情報受信手段で受信する特定情報受信ステップと、
前記特定情報を受信した場合に、前記確認手段で、当該特定情報を用いて、前記入金端末が送信した入金情報を前記入金記録手段で記録したか否かを確認する確認ステップと、
前記出力手段で、前記確認手段による確認結果を出力する出力ステップと、
から構成されたことを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
入金端末、サーバ、入金方法、及び情報処理方法に関し、例えば、入金端末が通貨を収納して貨幣端末の記憶する貨幣価値を増額させるものに関する。
【背景技術】
【０００２】
近年、電子マネーを用いた決済システムが小売店やデパートなどで導入され、広く利用されるようになってきた。
電子マネーシステムでは、ＩＣチップを内蔵した電子マネーカード（携帯電話などの場合もある）にバリューと呼ばれる金銭に対応する電子データを記憶させ、これを増減することにより貨幣価値の移動を生じさせる。
なお、ＩＣチップが記憶するバリューを増額する処理はチャージと呼ばれ、減額する処理は決済と呼ばれている。
【０００３】
電子マネーカードには、店舗の会計装置と連動した電子マネー端末でチャージや決済を行うことができるほか、手軽にチャージできる装置として入金端末と呼ばれるチャージ専用機が存在する。
入金端末は、例えば、店舗の一角や広場などに設置されており、電子マネーカードをセットするリーダライタ部と通貨投入口を備えている。
ユーザが電子マネーカードをリーダライタ部にセットして通貨を投入すると、入金端末は通貨の金額分のバリューを電子マネーカードにチャージする。
このように電子マネーを用いた発明としては、本出願人による次の文献がある。
【０００４】
【特許文献１】特開２００３−１４１４２８公報
【０００５】
図１４は、従来の入金端末がチャージを行う手順を示したフローチャートである。なお、電子マネーカードはリーダライタ部にセットされているものとする。
まず、入金端末は紙幣によって通貨の投入を受け付け、電子マネーサーバに金額や電子マネーカードのＩＤなどを通知する（ステップ１０）。
電子マネーサーバは、当該通知を受けると、入金端末を介して、電子マネーカードにカード側取引フラグを取引中に設定するように要求する（ステップ４０）。
【０００６】
ここで、カード側取引フラグは、取引中、取引完了の２値をとり、障害が発生した場合にリカバリのために使用するものである。
また、簡略化のため、説明を省略するが、電子マネーサーバも取引中と取引完了の２値をとるサーバ側取引フラグを備えている。これら取引フラグの使用方法については実施の形態で説明する。
【０００７】
電子マネーカードは、カード側取引フラグを取引中に設定し、入金端末を介して当該設定した旨を電子マネーサーバに通知する（ステップ４５）。
電子マネーサーバは、当該通知を受けると、当該チャージに関する内容を記録した取引ログを作成する（ステップ５５）。
電子マネーシステムでは、取引ログの作成を以て取引成功とし、ユーザから通貨を受領したものとする。
【０００８】
電子マネーサーバは、取引ログを作成すると、入金端末に電子マネーカードの残高の更新と、カード側取引フラグを取引完了に設定するように要求する（ステップ６５）。
入金端末は、当該要求を受けて、電子マネーカードのバリュー残高を通貨の金額分だけ増額するように更新し（ステップ７０）、更に、カード側取引フラグを取引完了に設定させる（ステップ７５）。
このようにして、電子マネーサーバでは取引ログが作成されると共に電子マネーカードではチャージが行われる。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
図１４で、障害Ｂが発生した場合、電子マネーサーバで取引ログが作成されず、電子マネーシステムは、ユーザから通貨を受領したことにはならない。
また、障害Ｃが発生した場合、取引ログが作成され、電子マネーシステムはユーザから通貨を受領したことになる。
そのため、障害Ｂが発生した場合、入金端末は、収納した通貨を返却する必要があり、障害Ｃが発生した場合は、通貨を返却する必要がない。
【００１０】
障害Ｂ、又は障害Ｃが発生した場合、入金端末は、電子マネーサーバから応答がないことにより何れかが発生したことを認識することができるが、何れの障害が発生したかを識別することができなかった。
そのため、障害Ｂ、又は障害Ｃが発生した場合、入金端末は一律に通貨を収納し、後ほど、取引フラグやその他の記録を用いて返金を行っていた。
【００１１】
なお、取引フラグを用いて障害Ｂと障害Ｃの何れが生じたかを判断することも可能であるが、この場合、電子マネーカードを再度リーダライタ部にアクセスさせる必要がある。
電子マネーカードを再度アクセスさせると、これは新規の取引となるが、入金端末は今回の取引が先の取引のリカバリのための取引であることを認識することができないため、入金端末は、先の取引で収納した通貨を返金することはできない。
【００１２】
そこで、本発明の目的は、障害が発生した場合に取引が成功したか否かを確認できるようにすることである。
【課題を解決するための手段】
【００１３】
本発明は、前記目的を達成するために、請求項１に記載の発明では、貨幣価値を電子データとして記憶する貨幣端末から当該貨幣端末を特定する貨幣端末ＩＤを取得するＩＤ取得手段と、通貨を受け付けて収納する収納手段と、前記取得した貨幣端末ＩＤと前記収納した通貨の金額を含む入金情報を所定のサーバに送信する入金情報送信手段と、前記所定のサーバから、前記送信した入金情報の記録を完了した旨の記録完了通知を受信する記録完了通知受信手段と、前記記録完了通知を受信した場合に、前記収納した通貨の金額分の貨幣価値を前記貨幣端末に増額させる増額手段と、前記所定のサーバから前記記録完了通知を受信しなかった場合に、前記入金情報を特定する特定情報を生成する特定情報生成手段と、前記生成した特定情報を前記所定のサーバに送信する特定情報送信手段と、を具備したことを特徴とする入金端末を提供する。
請求項２に記載の発明では、前記所定のサーバから前記記録完了通知を受信しなかった場合に、前記所定のサーバに前記入金情報の記録を完了したか否かを確認させる確認情報を前記所定のサーバに送信する確認情報送信手段を具備したことを特徴とする請求項１に記載の入金端末を提供する。
請求項３に記載の発明では、前記特定情報生成手段は、前記送信した確認情報に対して前記所定のサーバから応答が無かった場合に特定情報を生成することを特徴とする請求項２に記載の入金端末を提供する。
請求項４に記載の発明では、前記所定のサーバは、前記入金情報を受信してから当該入金情報を記録するための準備を行い、当該準備が完了した旨の準備完了通知を送信し、前記所定のサーバが送信した準備完了通知を受信する準備完了通知受信手段を具備し、前記収納手段は、前記準備完了通知を受信した後は、前記収納した通貨の返金を行わないことを特徴とする請求項１、請求項２、又は請求項３に記載の入金端末を提供する。
請求項５に記載の発明では、通貨の投入を受け付けて収納し、貨幣価値を電子データとして記憶する貨幣端末に当該通貨の金額分の貨幣価値を増額させる入金端末と通信するサーバであって、前記入金端末から、貨幣端末を特定する貨幣端末ＩＤと収納した通貨の金額を含む入金情報を受信する入金情報受信手段と、前記受信した入金情報を記録する入金記録手段と、前記記録を完了した場合に、記録完了通知を前記入金端末に送信する完了通知送信手段と、前記入金端末から、当該入金端末が送信した入金情報を特定する特定情報を受信する特定情報受信手段と、前記特定情報を受信した場合に、当該特定情報を用いて、前記入金端末が送信した入金情報を前記入金記録手段で記録したか否かを確認する確認手段と、前記確認手段による確認結果を出力する出力手段と、を具備したことを特徴とするサーバを提供する。
請求項６に記載の発明では、前記入金端末から当該入金端末が送信した入金情報の記録を完了したか否かを確認させる確認情報を受信する確認情報受信手段を具備し、前記入金情報を記録する前に前記確認情報を受信した場合は、前記入金記録手段による入金情報の記録から処理を開始し、前記入金情報を記録した後に前記確認情報を受信した場合は、前記完了通知送信手段による記録完了通知の送信から処理を開始することを特徴とする請求項５に記載のサーバを提供する。
請求項７に記載の発明では、ＩＤ取得手段と、収納手段と、入金情報送信手段と、記録完了通知受信手段と、増額手段と、特定情報生成手段と、特定情報送信手段と、を備えた入金端末において、前記ＩＤ取得手段で、貨幣価値を電子データとして記憶する貨幣端末から当該貨幣端末を特定する貨幣端末ＩＤを取得するＩＤ取得ステップと、前記収納手段で、通貨を受け付けて収納する収納ステップと、前記入金情報送信手段で、前記取得した貨幣端末ＩＤと前記収納した通貨の金額を含む入金情報を所定のサーバに送信する入金情報送信ステップと、前記記録完了通知受信手段で、前記所定のサーバから、前記送信した入金情報の記録を完了した旨の記録完了通知を受信する記録完了通知受信ステップと、前記増額手段で、前記記録完了通知を受信した場合に、前記収納した通貨の金額分の貨幣価値を前記貨幣端末に増額させる増額ステップと、前記特定情報生成手段で、前記所定のサーバから前記記録完了通知を受信しなかった場合に、前記入金情報を特定する特定情報を生成する特定情報生成ステップと、前記特定情報送信手段で、前記生成した特定情報を前記所定のサーバに送信する特定情報送信ステップと、から構成されたことを特徴とする入金方法を提供する。
請求項８に記載の発明では、通貨の投入を受け付けて収納し、貨幣価値を電子データとして記憶する貨幣端末に当該通貨の金額分の貨幣価値を増額させる入金端末と通信するコンピュータが行う情報処理方法であって、前記コンピュータは、入金情報受信手段と、入金記録手段と、完了通知送信手段と、特定情報受信手段と、確認手段と、出力手段と、を備えており、前記入金情報受信手段で、前記入金端末から、貨幣端末を特定する貨幣端末ＩＤと収納した通貨の金額を含む入金情報を受信する入金情報受信ステップと、前記入金記録手段で、前記受信した入金情報を記録する入金記録ステップと、前記完了通知送信手段で、前記記録を完了した場合に、記録完了通知を前記入金端末に送信する完了通知送信ステップと、前記入金端末から、当該入金端末が送信した入金情報を特定する特定情報を前記特定情報受信手段で受信する特定情報受信ステップと、前記特定情報を受信した場合に、前記確認手段で、当該特定情報を用いて、前記入金端末が送信した入金情報を前記入金記録手段で記録したか否かを確認する確認ステップと、前記出力手段で、前記確認手段による確認結果を出力する出力ステップと、から構成されたことを特徴とする情報処理方法を提供する。
【発明の効果】
【００１４】
本発明によれば、障害が発生した場合、入金端末がその記録を所定のサーバに送信し、サーバ側の記録と照合することにより取引成功の有無を判断することができる。
【発明を実施するための最良の形態】
【００１５】
（１）実施の形態の概要
入金端末２（図１）に電子マネーカード５をセットして、入金端末２に紙幣を投入すると、投入金額分のバリューを電子マネーカード５にチャージすることができる。
入金端末２は、電子マネーカード５にチャージを行う際に電子マネーサーバ３と通信し、電子マネーサーバ３が取引ログを作成する。電子マネーシステム１は、電子マネーサーバ３が取引ログを作成した時点で紙幣を受領する。
【００１６】
入金端末２が電子マネーサーバ３と通信している際に通信障害が発生した場合、入金端末２が紙幣を収納したにも拘わらず、電子マネーサーバ３で取引ログを作成していない場合があり得る。
そのため、入金端末２は、紙幣を収納したにも拘わらず取引ログが作成されたか不明な場合は、取引未完ログを生成して電子マネーサーバ３に送信する。
電子マネーサーバ３は、入金端末２から取引未完ログを受信した場合、当該取引未完ログに対応する取引ログが作成されているか否かを確認し、取引ログが作成されていない場合は、その旨を出力する。
【００１７】
（２）実施の形態の詳細
図１は、本実施の形態に係る電子マネーシステム１のシステム構成の一例を示した図である。
電子マネーシステム１は、電子マネーサーバ３、電子マネー端末４、４、４、・・・、入金端末２、及び電子マネーカード５などから構成されている。
【００１８】
電子マネーカード５は、バリュー処理機能を有するＩＣチップを内蔵したカードであり、ユーザに電子財布として携帯される。
このＩＣチップは、演算機能や記憶機能を発揮することができ、バリューを記憶すると共に、金額変更情報が入力されると、これを用いて記憶しているバリューの残高を増減する。
また、本実施の形態では、ＩＣチップを内蔵する媒体として電子マネーカードを用いて説明するが、例えば、携帯電話などの携帯端末に当該ＩＣチップを内蔵して電子マネーカードと同様に使用することもできる。
【００１９】
電子マネー端末４は、店舗のレジと併設して設置された端末装置であり、オフラインにて電子マネーカード５に金額変更情報を入力してチャージや決済を行うことができる。
電子マネー端末４は、電子マネーカード５にチャージや決済などの取引を行った際に、これを記録した取引ログを生成し、一時記憶しておく。
そして、電子マネー端末４は、１日に１回程度、バッチ処理にて取引ログを電子マネーサーバ３に送信する。
【００２０】
入金端末２は、ユーザからの通貨の投入を受け付けて、当該通貨の金額分のバリューを電子マネーカード５にチャージするチャージ専用の端末である。
なお、通貨は、硬貨を受け付けることも可能であるが、装置が煩雑となりコストが高くなる上、実需に乏しいため、本実施の形態では、通貨の投入を紙幣によって、紙幣単位で受け付けるものとする。
即ち、１０００円札の投入を受け付ける場合は、１０００円分のチャージを行い、５０００円札の投入を受け付ける場合は、５０００円分のチャージを行う。
また、１０００円札３枚の投入を受け付ける場合は、１０００円ずつ３回チャージを行う。
【００２１】
入金端末２は、電子マネーカード５にチャージする際に、電子マネーサーバ３とオンラインにて通信し、電子マネーサーバ３が取引ログを作成する。
このように、入金端末２を用いる場合、電子マネーサーバ３側の取引ログをリアルタイムで作成することができる。
【００２２】
一方、このように入金端末２と電子マネーサーバ３を接続して処理を行うため、電子マネーサーバ３との通信が切断するなどの障害が発生する可能性がある。
障害が発生した場合に、事後的にリカバリ処理を行うため、電子マネーサーバ３はサーバ側取引フラグを実装し、電子マネーカード５はカード側取引フラグを実装している。
【００２３】
これら取引フラグは、取引完了と取引中の２値をとることができ、障害が発生した場合は、これらの組合せにより障害が発生した段階を特定することができるようになっている。
これによって、障害が発生した段階に応じたリカバリ処理が可能となる。これら取引フラグの用法については後述する。
【００２４】
入金端末２は、投入された紙幣を収納したことを電子マネーサーバ３に通知したにも拘わらず、電子マネーサーバ３から残高更新の指令が来なかった場合、電子マネーサーバ３が取引ログを作成したのか（取引が完了したため返金の必要なし）、あるいは、取引ログを作成していないのか（取引が未完了のため返金の必要あり）を認識することができない。
【００２５】
そのため、入金端末２は、障害が発生して取引が完了したか否かが不明な場合、取引未完ログを生成して電子マネーサーバ３に送信するようになっている。
なお、取引未完ログの送信はリアルタイムで行うことも可能であるが、通信障害の直後であり、更に通信障害が起こる可能性があるため、入金端末２は、生成した取引未完ログを一時的に記憶しておき、後ほど一括して電子マネーサーバ３に送信する。
電子マネーサーバ３は、入金端末２から送信されてきた取引未完ログを、後述の入金管理情報と突合することにより、当該取引に関して取引ログが作成されたか否かを判断することができる。
【００２６】
図２（ａ）は、電子マネーカード５のハードウェア的な構成の一例を示したブロック図である。
電子マネーカード５は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２１、高周波回路２２、アンテナ２６、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２３、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２４、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）２５などを内蔵している。
【００２７】
これらの素子は、電子マネーカード５内に埋め込まれたＩＣチップ上に形成されている。
ただし、アンテナ２６は、電子マネーカード５内部の外縁部付近に張り巡らされた空中線により構成され、端部がＩＣチップに接続されている。
このように、本実施の形態では、ＩＣチップを無線により送受信する非接触型とするが、電極によって接続する接触型のＩＣチップにて構成することも可能である。
ここで、当該ＩＣチップは、貨幣価値を電子データとして記憶する貨幣端末として機能している。
【００２８】
ＣＰＵ２１は、ＲＯＭ２３やＥＥＰＲＯＭ２５に記憶されているプログラムに従って情報処理を行う中央処理装置である。
アンテナ２６は、リーダライタ部に内蔵されたアンテナと近距離の無線通信を行うためのアンテナである。
電子マネーカード５は、アンテナ２６を介してリーダライタ部から無線により駆動電力を得ると共に無線通信を行う。
【００２９】
高周波回路２２は、リーダライタ部からアンテナ２６に送信されてきた高周波をデジタル信号に変換してＣＰＵ２１に出力したり、逆にＣＰＵ２１が出力したデジタル信号を高周波に変換してアンテナ２６に出力し、リーダライタ部に送信する。
【００３０】
ＲＡＭ２４は、ＣＰＵ２１が情報処理を行う際のワーキングメモリを提供する随時書き込み読み出しメモリである。
ＲＡＭ２４は、電子マネーカード５に電力が供給されている間、記憶内容を保持することができるが、電力の供給が止まると記憶内容は失われる。
ＲＯＭ２３は、電子マネーカード５を機能させるための基本的なプログラムやパラメータ、データなどを記憶した読み出し専用メモリである。
【００３１】
ＥＥＰＲＯＭ２５は、情報の書込消去が可能なＲＯＭである。ＥＥＰＲＯＭ２５に記憶してある情報は、電子マネーカード５への電力の供給がない場合でも保たれる。
ＥＥＰＲＯＭ２５には、例えば、電子マネーカード５を機能させるための基本的なプログラムであるＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や、金額更新情報に基づいてバリューの残高を更新したりなど、バリューに関する処理を行うバリュー処理プログラムや、各種データが記憶されている。
【００３２】
図２（ｂ）は、電子マネーカード５の機能を概念的に示したブロック図である。
電子マネーカード５は、通信部１２、バリュー処理部１４、記憶部１６などから構成されている。
通信部１２は、アンテナ２６、高周波回路２２などを用いて構成されており、入金端末２や図示しない電子マネー端末４と近距離の無線通信を行う。
【００３３】
バリュー処理部１４は、ＥＥＰＲＯＭ２５に記憶されているバリュー処理プログラムをＣＰＵ２１で実行することにより構成され、通信部１２を介して入金端末２や電子マネー端末４との通信処理を行ったり、金額更新情報を用いてバリューの残高を更新したり、後述の電子マネー機能部ＩＤを出力したり、カード側取引フラグを設定したりなどする。
【００３４】
記憶部１６は、ＥＥＰＲＯＭ２５の所定領域に形成されており、電子マネーカード５に対応して一意に付与されたＩＤ情報である電子マネー機能部ＩＤ、バリュー残高、カード側取引フラグ、その他のデータが記憶されている。
ここで、電子マネー機能部ＩＤは、貨幣端末を特定する貨幣端末ＩＤとして機能している。
【００３５】
図３は、入金端末２の外観を示した模式図である。
入金端末２は、直方体形状を有しており、前面パネルに表示操作部３１、紙幣投入口３６、入金ボタン３２、取消ボタン３３、レシートボタン３４、リーダライタ部３８が形成されている。
【００３６】
表示操作部３１は、例えば、液晶ディスプレイなどの表示装置を備えており、文字・記号などを表示する。
表示操作部３１により、ユーザに対して「電子マネーカードをセットしてください。」とか「紙幣を入れてください。」などと、指示を出すことができる。
【００３７】
紙幣投入口３６は、紙幣を投入する投入口である。紙幣投入口３６は、スリット状の開口部が設けられており、この開口部に紙幣の一端を挿入すると、ローラなどの機構により紙幣が自動的に入金端末２の内部に取り込まれて収納される。
また、例えば、紙幣に異常がある場合や、電子マネーサーバ３に取引ログの作成を指示する前に障害が発生した場合、入金端末２は、返金の必要があると判断し、一旦取り込んだ紙幣を紙幣投入口３６から排出する。
【００３８】
入金ボタン３２は、リーダライタ部３８にセットされた電子マネーカード５にチャージを実行させるためのボタンである。
なお、チャージは紙幣単位となっており、ユーザは紙幣を投入するごとに入金ボタン３２を押して電子マネーカード５にチャージする。
【００３９】
そのため、例えば、１０００円札３枚を投入して入金する場合、入金端末２は、１０００円札の投入受け付け→入金ボタン３２の押下受け付け→チャージ、という処理を３回繰り返すことになる。
なお、一度に複数枚の紙幣を投入し、入金ボタン３２が押下されると、入金端末２が紙幣ごとにチャージするように構成することもできる。
【００４０】
取消ボタン３３は、処理を途中で終了するためのボタンである。取消ボタン３３が押下された場合、入金端末２が行っている処理のうち、電子マネーサーバ３に取引ログの作成を指示する前の取引に関してはその時点で取消となり、紙幣は返却される。
レシートボタン３４は、レシートを発行するためのボタンである。ユーザがチャージ後にレシートボタン３４を押下すると、レシートがリーダライタ部３８の上部に設けられたレシート出力口（図示せず）から出力される。
【００４１】
入金端末２の前面パネルの下半部には、入金端末２の内部に向かって窪んだ凹部があり、その凹部の下端の平坦部にリーダライタ部３８が設けられている。
リーダライタ部３８には、リーダライタが内蔵されており、この凹部に電子マネーカード５を置いて入金端末２とこれらのカード間で無線通信が行われる。
なお、携帯電話にＩＣチップを内蔵している場合は、携帯電話を凹部にセットすると、電子マネーカード５と同様にチャージすることができる。
【００４２】
図４は、入金端末２のハードウェア的な構成の一例を示した図である。
図４に示したように入金端末２は、ＣＰＵ６１、ＲＯＭ６３、ＲＡＭ６４、通信制御部６５、記憶部６６、入力部６７、出力部６８、リーダライタ部３８、入金部６９などがバスライン４６で接続されて構成されている。
【００４３】
ＣＰＵ６１は、所定のプログラムに従って情報処理を行うほか、入金端末２全体の制御などを行い、例えば、電子マネーカード５と電子マネーサーバ３の通信を仲介したり、電子マネーカード５をチャージしたり、後述の取引未完ログを作成したりする。
ＲＯＭ６３は、入金端末２を動作させるための基本的なプログラムやパラメータなどを記憶した読み出し専用メモリである。
ＲＡＭ６４は、ＣＰＵ６１のワーキングメモリを提供したり、記憶部６６に記憶されたプログラムやデータをロードして記憶したりなどする随時書き込み読み出しメモリである。
【００４４】
通信制御部６５は、入金端末２をネットワーク経由で電子マネーサーバ３に接続する接続装置である。
記憶部６６は、例えば、半導体記憶装置、ハードディスク、磁気記憶媒体などで構成された記憶媒体と、これらを駆動する駆動装置から構成されており、各種プログラムを格納したプログラム格納部７２、データを格納したデータ格納部７４などから構成されている。
【００４５】
データ格納部７４には、取引未完ログが一時記憶され、バッチ処理などにより電子マネーサーバ３に送信される。
また、データ格納部７４には、自身のＩＤ情報である端末ＩＤが記憶されている。電子マネーサーバ３は、端末ＩＤにより入金端末２を特定することができる。
プログラム格納部７２には、入金端末２を機能させるための基本的なプログラムであるＯＳや、電子マネーカード５をチャージするためのプログラムなどが記憶されている。
【００４６】
入力部６７は、入金ボタン３２、取消ボタン３３、レシートボタン３４、などの入力装置を備えており、外部からの情報の入力を受け付ける。
出力部６８は、レシートを印刷するプリンタや表示操作部３１（ディスプレイ３１）などの出力装置を備えている。
【００４７】
入金部６９は、紙幣投入口３６を備えており、外部からの紙幣の入力を受け付ける。入金部６９は、紙幣の真贋を判断し、更に光学装置などにより額面金額を読み取る。
リーダライタ部３８は、先に説明した通りである。
【００４８】
図５は、電子マネーサーバ３のハードウェア的な構成の一例を示した図である。
電子マネーサーバ３は、ＣＰＵ５１、ＲＯＭ５２、ＲＡＭ５４、通信制御部５３、記憶部５５などがバスラインで接続されて構成されている。
ＣＰＵ５１は、入金端末２と通信して電子マネーカード５へのチャージ処理を行ったり、入金端末２との処理で作成した取引ログや電子マネー端末４から受信した取引ログデータを集計したりなどする。
【００４９】
ＲＯＭ５２は、電子マネーサーバ３を動作させるための基本的なプログラムやパラメータなどを記憶した読み出し専用メモリである。
ＲＡＭ５４は、ＣＰＵ５１のワーキングメモリを提供したり、記憶部５５に記憶されたプログラムやデータをロードして記憶したりなどする随時書き込み読み出し可能なメモリである。
通信制御部５３は、ネットワークを介して入金端末２と接続する接続装置である。
【００５０】
記憶部５５は、例えばハードディスクやその他の記憶媒体と、これらを駆動する駆動装置から構成されており、各種プログラムを格納したプログラム格納部５６、データを格納したデータ格納部５７などから構成されている。
プログラム格納部５６には、電子マネーサーバ３を機能させるための基本的なプログラムであるＯＳや、入金端末２と通信して電子マネーカード５に金額変更処理を行わせたり、取引ログを生成したり、あるいは取引ログを集計したりするためのプログラムなどが記憶されている。
【００５１】
データ格納部５７には、入金管理情報ＤＢ（データベース）、取引ログＤＢ、取引未完ログＤＢ、サーバ側取引フラグＤＢなどが形成されている。
入金管理情報ＤＢは、入金管理情報を記憶するデータベースである。
入金管理情報は、取引未完ログと突合して取引ログが作成されたか否かを判断するための情報であり、入金端末２から入金情報を受信すると作成される。そして、入金端末２との進捗状況などにより状態１、状態２、状態３と３つの状態に更新される。
以下では、状態１の入金管理情報を入金管理情報（状態１）などと適宜略記する。
【００５２】
取引ログＤＢは、入金端末２と協働して電子マネーカード５にチャージする際に生成した取引ログや、電子マネー端末４からバッチ処理にて送信されてきた取引ログを記憶するデータベースである。
取引ログを集計することにより、バリューによる貨幣価値の移動を把握し、電子マネーシステム１に加盟している加盟店との間で資金決済を行うことができる。
【００５３】
取引未完ログＤＢは、入金端末２から送信されてきた取引未完ログを記憶したデータベースである。
電子マネーサーバ３は、取引未完ログＤＢに記憶されている取引未完ログを、入金管理情報ＤＢに記憶されている入金管理情報と突合し、取引ログが作成されているか否か、即ち、返金の必要性を判断する。
サーバ側取引フラグＤＢは、各電子マネーカード５ごとのサーバ側取引フラグを記憶したデータベースである。
【００５４】
図６は、入金端末２で電子マネーカード５にチャージを行う場合の処理手順を説明するためのフローチャートである。
以下の処理は、電子マネーカード５、入金端末２、及び電子マネーサーバ３のＣＰＵが所定のプログラムに従って行うものである。
なお、電子マネーカード５は、前回の取引が正常終了しており、カード側取引フラグとサーバ側取引フラグは共に取引完了となっているものとする。
【００５５】
まず、ユーザが電子マネーカード５を入金端末２のリーダライタ部３８（図３）に置いてこれをセットする。
すると、入金端末２は、電子マネーカード５と通信してカード検知処理を行い、電子マネーカード５を認識する（ステップ５）。
入金端末２は、カード検知処理により、電子マネーカード５から電子マネー機能部ＩＤなどを読み取る。
このように、入金端末２は、貨幣端末（電子マネーカード５のＩＣチップ）から当該貨幣端末を特定する貨幣端末ＩＤ（電子マネー機能部ＩＤ）を取得するＩＤ取得手段を備えている。
【００５６】
次に、ユーザは紙幣投入口３６（図３）に紙幣を投入し、入金ボタン３２を押下する。
これに対応して、入金端末２は、紙幣の投入を受け付けて収納し（ステップ１０）、入金ボタン３２の押下を受け付ける（ステップ１５）。このように、入金端末２は、通貨を受け付けて収納する収納手段を備えている。
入金端末２は、入金ボタン３２の押下を受け付けると、電子マネーサーバ３に接続し、電子マネーカード５に対する入金処理を行う（ステップ２０）。
【００５７】
図７は、ステップ２０（図６）の入金処理を説明するためのフローチャートである。
入金端末２は、入金処理を開始すると、自身の端末ＩＤ、電子マネーカード５から読み取った電子マネー機能部ＩＤ、投入金額、取引日時（現在日時）などを含む入金情報を生成して電子マネーサーバ３に送信する（ステップ２５）。
このように、入金端末２は、貨幣端末（電子マネーカード５のＩＣチップ）から取得した貨幣端末ＩＤ（電子マネー機能部ＩＤ）と収納した通貨の金額を含む入金情報を所定のサーバ（電子マネーサーバ３）に送信する入金情報送信手段を備えている。
【００５８】
電子マネーサーバ３は、入金端末２から送信された入金情報を受信する。このように、電子マネーサーバ３は、入金端末２から、貨幣端末（電子マネーカード５のＩＣチップ）を特定する貨幣端末ＩＤ（電子マネー機能部ＩＤ）と収納した通貨の金額を含む入金情報を受信する入金情報受信手段を備えている。
【００５９】
そして、電子マネーサーバ３は、入金情報の電子マネー機能部ＩＤから電子マネーカード５を特定し、当該電子マネーカード５に対してサーバ側取引フラグＤＢ（図５）に記憶してあるサーバ側取引フラグを取引完了から取引中に設定する（ステップ３０）。
次に、電子マネーサーバ３は、入金情報を用いて入金管理情報（状態１）を作成する（ステップ３５）。
【００６０】
ここで、図８（ａ）を用いて入金管理情報（状態１）の構成について説明する。
入金管理情報（状態１）は、端末ＩＤ、電子マネー機能部ＩＤ、投入金額、取引日時、決済状態フラグ、返金要否フラグなどの各項目から構成されている。
これらのうち、入金端末、電子マネー機能部ＩＤ、投入金額、取引日時は、入金情報に記録されていたものである。
【００６１】
決済状態フラグは、取引ログが生成されたか否かを表すフラグであり、未成立と成立の２値をとることができる。
未成立は、取引ログが作成されていない場合に対応し、成立は取引ログが作成済みである場合に対応している。
状態１では、まだ取引ログが作成されていないため、決済状態フラグは未成立に設定されている。
【００６２】
返金要否フラグは、ユーザに返金を要するか否かを表すフラグであり、返金必要なしと、返金必要ありの２値をとることができる。
返金要否フラグのデフォルト値は返金必要なしとなっており、後に取引未完ログと突合して返金の必要があると判明した場合に、返金必要ありに設定される。
【００６３】
図７に戻り、電子マネーサーバ３は、入金管理情報（状態１）を作成した後、入金端末２を経由して電子マネーカード５にカード側取引フラグを取引中に設定することを要求する（ステップ４０）。
電子マネーカード５は、入金端末２を介して当該要求を受けると、カード側取引フラグを取引完了から取引中に設定する（ステップ４５）。
そして、電子マネーカード５は、入金端末２を経由して、カード側取引フラグを取引中に設定したことを電子マネーサーバ３に通知する。
【００６４】
電子マネーサーバ３は、当該通知を受けると、取引ログを作成する（ステップ５０）と共に、入金管理情報（状態１）を入金管理情報（状態２）に更新する（ステップ５５）。
なお、入金管理情報（状態１）を更新してから取引ログを作成するように構成することもできる。
取引ログは、ユーザが行った入金の記録を入金情報を用いて行ったものであり、このように、電子マネーサーバ３は、入金端末２から受信した入金情報を記録する入金記録手段を備えている。
【００６５】
図８（ｂ）は、入金管理情報（状態２）の構成を示した図である。
入金管理情報（状態２）では、決済状態フラグが成立に更新されている。
これは、取引ログが作成され、取引が完了したこと（即ち、電子マネーシステム１が紙幣を受領したこと）を意味している。
【００６６】
図９は、取引ログの構成を説明するための図である。
取引ログは、電子マネー機能部ＩＤ、端末ＩＤ、取引番号、取引種別、取引金額などの項目から構成されている。
取引ログは、入金端末２で電子マネーカード５にチャージしたものに関しては、電子マネーサーバ３が作成したものであり、電子マネー端末４がチャージ又は決済したものに関しては、電子マネー端末４で作成して電子マネーサーバ３に送信してきたものである。
図９には、これらの取引ログのうち、入金端末２がチャージし、電子マネーサーバ３が作成したものが図示してある。
【００６７】
電子マネー機能部ＩＤは、入金端末２がチャージを行った電子マネーカード５の電子マネー機能部ＩＤや、電子マネー端末４がチャージや決済を行った電子マネーカード５の電子マネー機能部ＩＤである。
端末ＩＤは、電子マネーカード５に対して処理を行った入金端末２や電子マネー端末４の端末ＩＤである。
【００６８】
取引番号は、入金端末２や電子マネー端末４が取引ごとに付与している通番であり、シーケンス番号とも呼ばれている。電子マネーサーバ３は、端末ＩＤと取引番号により取引を特定することができる。
取引種別は、チャージと決済の区別であり、入金端末２に関してはチャージとなり、電子マネー端末４の場合は、取引によってチャージ又は決済となる。
取引金額は、入金端末２に関してはチャージした金額であり、電子マネー端末４に関しては、チャージ又は決済した金額である。
【００６９】
取引ログは、障害Ｂが発生した場合は生成されず、障害Ｃが発生した場合は生成される。
そのため、例えば、取引番号１０６の取引ログ８１を作成する取引において、障害Ｂが発生した場合、取引ログ８１は生成されず、障害Ｃが発生した場合、取引ログ８１は生成される。
【００７０】
図７に戻り、電子マネーサーバ３は、取引ログを作成して入金管理情報を状態２に更新した後、サーバ側取引フラグを取引中から取引完了に設定する（ステップ６０）。
そして、電子マネーサーバ３は、入金端末２を介して電子マネーカード５に残高更新と、カード側取引フラグの設定を要求する（ステップ６５）。
この残高更新要求は、ユーザが入金した金額分のバリューをチャージさせる金額変更情報を電子マネーサーバ３が生成して電子マネーカード５に送信してもよいし、あるいは、電子マネーサーバ３が入金端末２に当該金額変更情報を生成させてもよい。
なお、ステップ５０からステップ６０までは、１つのまとまった処理として行うことができ、ステップ５０からステップ６０の順序を入れ替えた処理も可能である。
【００７１】
この残高更新とカード側取引フラグの設定の要求により、取引ログの作成が完了したことが入金端末２に通知されるため、この要求は入金記録の記録完了を通知する記録完了通知として機能している。
このように、電子マネーサーバ３は、記録を完了した場合に（即ち、取引ログを作成して入金管理情報を状態２に更新した場合に）、記録完了通知を入金端末２に送信する完了通知送信手段を備えている。
【００７２】
入金端末２は、これらの要求を受信し、これを電子マネーカード５に伝える。
このように入金端末２は、所定のサーバ（電子マネーサーバ３）から、（ステップ２５で）送信した入金情報の記録を完了した旨の記録完了通知を受信する記録完了通知受信手段を備えている。
【００７３】
そして、電子マネーカード５は、当該要求によって記憶部１６（図２）に記憶してあるバリューの残高をユーザが入金した金額分だけ増額して残高更新を行うことによりチャージを行う（ステップ７０）。
更に、電子マネーカード５は、記憶部１６に記憶してあるカード側取引フラグを取引中から取引完了に設定し（ステップ７５）、入金端末２を介して取引フラグを設定した旨の通知を電子マネーサーバ３に送信する。
このように、入金端末２は、記録完了通知（ステップ６５の要求）を受信した場合に、収納した通貨の金額分の貨幣価値を貨幣端末（電子マネーカード５のＩＣチップ）に増額させる増額手段を備えている。
【００７４】
電子マネーサーバ３は、入金端末２から当該通知を受信すると、入金が成功した旨の入金成功通知を生成し、入金端末２に送信する（ステップ８０）。
入金端末２は、電子マネーサーバ３から入金成功通知を受信すると入金ログを生成して（ステップ８５）データ格納部７４（図４）に記憶する。
なお、入金ログは、入金端末２で成功した入金処理を記録しておくものであり、電子マネーシステム１において、取引の完了は電子マネーサーバ３の取引ログが作成されたか否かにより判断される。
【００７５】
以上は、入金端末２による入金処理が成功した場合であるが、次に、ネットワークに障害が発生した場合の処理について説明する。
まず、図７においてステップ２５の入金情報の送信時、又はステップ４０の障害Ａが発生した場合は次のようになる。
入金端末２は、ステップ２５で入金情報を送信した後、所定時間以内に電子マネーサーバ３からカード側取引フラグ設定要求がない場合は、入金情報を電子マネーサーバ３に送信した際に障害が発生したか、あるいは障害Ａが発生したと判断し、収納した紙幣を排出してこれをユーザに返却する。
【００７６】
一方、電子マネーサーバ３からカード側取引フラグ設定要求があった場合、入金端末２は収納した紙幣を保持し、以降は障害が発生した場合でも紙幣の返却は行わないようになっている。
なお、これはどの時点で紙幣の返却を行わないようにするかの一例であって、例えば、障害Ｂが発生した場合や、その他の時点で紙幣を返却しないように構成することもできる。
電子マネーサーバ３は、このように入金端末２から入金情報を受信してから、入金管理情報（状態１）を作成するなど、取引ログを作成するための準備を行い、当該準備が完了したことをステップ４０のカード側取引フラグの設定要求によって入金端末２に通知する。
【００７７】
このため、所定のサーバ（電子マネーサーバ３）は、入金情報を受信してから当該入金情報を記録するための準備を行い、当該準備が完了した旨の準備完了通知を送信する。
そして、入金端末２は、当該所定のサーバが送信した準備完了通知（ステップ４０で送信される要求）を受信する準備完了通知受信手段を具備し、収納手段は、当該準備完了通知を受信した後は、当該収納した通貨の返金を行わない。
【００７８】
次に、障害Ｂ、又は障害Ｃが発生した場合は次のようになる。
入金端末２は、ステップ４５で通知を電子マネーサーバ３に送信した後、所定時間内に電子マネーサーバ３からステップ６５の要求がない場合、障害Ｂ、又は障害Ｃが発生したと判断する。
すると、入金端末２は、電子マネーサーバ３に入金情報を再度送信するか、入金情報を特定する情報を電子マネーサーバ３に送信するなどして電子マネーサーバ３に問い合わせを行う（ステップ１００）。
この問い合わせは、電子マネーサーバ３によって、障害Ｂが発生した場合はステップ５０の前で受信され、障害Ｃが発生した場合はステップ６５の後で受信される。
【００７９】
このように、入金端末２は、所定のサーバ（電子マネーサーバ３）から記録完了通知（ステップ６５で送信される要求）を受信しなかった場合に、当該所定のサーバに入金情報の記録を完了したか否か（取引ログを作成して入金管理情報を状態２に更新したか否か）を確認させる確認情報（問い合わせ）を当該所定のサーバに送信する確認情報送信手段を備えている。
【００８０】
電子マネーサーバ３は、入金端末２から問い合わせを受けると、問い合わせに係る入金情報について取引ログを作成したか否かを確認する。
取引ログを作成していなかった場合、障害Ｂが発生していたことになり、電子マネーサーバ３は、ステップ５０から処理を開始し、入金管理情報の更新や取引ログの作成を行って処理を続行する。
【００８１】
一方、取引ログを作成していた場合、障害Ｃが発生したことになり、電子マネーサーバ３は、ステップ６５から処理を再開する。
そして、入金端末２は、問い合わせに対して電子マネーサーバ３からステップ６５の要求があった場合、ステップ７０から処理を続行する。
このように、障害Ｂ、又は障害Ｃが発生した場合でも入金端末２の問い合わせ機能により、リアルタイムで復旧することが可能である。
【００８２】
また、上記の通り、電子マネーサーバ３は、入金情報を記録する前（取引ログを作成して入金管理情報を状態２に更新する前）に確認情報（問い合わせ）を受信した場合は、入金記録手段による入金情報の記録（ステップ５０）から処理を開始し、当該入金情報を記録した後に確認情報を受信した場合は、完了通知送信手段による記録完了通知の送信（ステップ６５）から処理を開始する。
【００８３】
更に、入金端末２が電子マネーサーバ３に対して問い合わせを行ったにも拘わらず、所定時間内に電子マネーサーバ３からステップ６５の要求がなかった場合、入金端末２は、障害Ｂ、又は障害Ｃの何れが発生したか区別できないため、取引未完ログを作成して（ステップ１０５）処理を終了する。
入金端末２は、取引未完ログを作成した場合、これをデータ格納部７４（図４）に記憶し、後ほどバッチ処理にて電子マネーサーバ３に送信する。
電子マネーサーバ３は、この取引未完ログを受信して取引未完ログＤＢ（図５）に記憶する。
【００８４】
ここで、取引未完ログは、ステップ２５で送信した入金情報を特定する特定情報として機能している。
このため、入金端末２は、所定のサーバ（電子マネーサーバ３）から記録完了通知（ステップ６５の要求）を受信しなかった場合に、（ステップ２５で送信した）入金情報を特定する特定情報を生成する特定情報生成手段と、当該生成した特定情報を所定のサーバ（電子マネーサーバ３）に送信する特定情報送信手段を備えている。
また、電子マネーサーバ３は、入金端末３から、当該入金端末３が送信した入金情報を特定する特定情報を受信する特定情報受信手段を備えている。
なお、入金端末２にステップ１００の問い合わせ機能を実装せずに、障害Ｂ、又は障害Ｃが発生した場合は速やかに取引未完ログを作成するように構成することも可能である。
【００８５】
図１０は、取引未完ログの構成を説明するための図である。
取引未完ログは、端末ＩＤ、取引番号、及び取引日時などの項目から構成されている。
端末ＩＤは、入金端末２の端末ＩＤである。
取引番号は、入金端末２が入金処理に対して付与した取引番号である。
取引時間は、入金処理を開始した日時であり、入金端末２が入金情報に記録したものである。
【００８６】
取引未完ログは、端末ＩＤと取引日時によって入金管理情報と対応しており、電子マネーサーバ３は、入金端末２から取引未完ログを受信した場合、これらをキーとして対応する入金管理情報を特定し突合することができる。
なお、本実施の形態では、一例として端末ＩＤと取引日時をキーワードとしたが、これに限定するものではなく、取引未完ログと入金管理情報を突合できる情報であればキーとして使用することができる。
【００８７】
図１１は、サーバ側取引フラグとカード側取引フラグの組合せと障害の対応を説明するための図である。
図７のフローチャートから明らかなように、障害Ａが発生した場合、カード側取引フラグは取引完了となっており、サーバ側取引フラグは取引中となっている。
同様に、障害Ｂが発生した場合、カード側取引フラグは取引中となっており、サーバ側取引フラグも取引中となっている。
【００８８】
障害Ｃが発生した場合、カード側取引フラグは取引中となっており、サーバ側取引フラグは取引完了となっている。
障害Ｄが発生した場合、カード側取引フラグは取引完了となっており、サーバ側取引フラグも取引完了となっている。
このように、取引フラグの組合せによっても障害が発生した箇所を特定することができる。
【００８９】
電子マネーサーバ３は、電子マネーカード５に接続した際に、電子マネーカード５からカード側取引フラグを読み取り、自己が記憶しているサーバ側取引フラグと対比して、何れの箇所で障害が発生したかを判断し、リカバリを行う。
このように、取引フラグを用いて障害箇所を特定することもできるが、取引フラグによる判断は、電子マネーカード５を入金端末２や他の端末を介して再度電子マネーサーバ３に接続する必要がある。
【００９０】
図１２は、取引未完ログが発生した場合の返金の必要性の有無を説明するための図である。
図に示したように取引未完ログが発生した場合、入金管理情報の状態が状態１の場合、入金端末２が紙幣を収納したにも拘わらず取引ログが作成されていないので、返金が必要となる。
一方、入金管理情報の状態が状態２の場合、取引ログが作成されているので、返金の必要はないことになる。
このように、返金の必要性の有無を取引未完ログと入金管理情報によって判断可能である。
【００９１】
図１３は、電子マネーサーバ３が取引未完ログと入金管理情報を突合する手順を説明するためのフローチャートである。
電子マネーサーバ３は、この処理を例えば、定期的、又は不定期にバッチ処理にて行う。
まず、電子マネーサーバ３は、取引未完ログＤＢ（図５）から取引未完ログを１つ読み込む（ステップ１２０）。
次に、電子マネーサーバ３は、端末ＩＤと取引日時をキーとして対応する入金管理情報を入金管理情報ＤＢで特定する（ステップ１２５）。
【００９２】
次に、電子マネーサーバ３は、特定した入金管理情報の状態を確認する（ステップ１３０）。
状態が状態２であった場合（ステップ１３０；状態２）、取引ログが作成されているため、電子マネーサーバ３は当該取引未完ログに関する突合処理を終了し、取引未完ログＤＢに記憶してある全ての取引未完ログを確認したか判断する（ステップ１４０）。
全ての取引未完ログを確認した場合（ステップ１４０；Ｙ）、電子マネーサーバ３は突合処理を終了し、まだ未確認の取引未完ログがある場合（ステップ１４０；Ｎ）、ステップ１２０に戻って未確認の取引未完ログについて突合処理を続行する。
【００９３】
一方、入金管理情報の状態が状態１であった場合（ステップ１３０；状態１）、取引ログが作成されていないため、電子マネーサーバ３は、入金管理情報の状態を状態３に更新する（ステップ１３５）。
そして、電子マネーサーバ３は、ステップ１４０に移行する。
このように、電子マネーサーバ３は、入金端末２から特定情報（取引未完ログ）を受信した場合に、当該特定情報を用いて、入金端末２が送信した入金情報を入金記録手段で記録したか否か（入金管理情報を状態２に更新し、取引ログを作成したか否か）を確認する確認手段を備えいる。
【００９４】
図８（ｃ）は、入金管理情報（状態３）の構成を示した図である。
入金管理情報（状態３）は、入金管理情報（状態１）の返金要否フラグを返金必要ありに変更することにより更新されている。
そして、入金管理情報（状態３）に記録されている電子マネー機能部ＩＤと投入金額により、電子マネーシステム１は、返金すべき電子マネーカード５と返金額を特定することができる。
【００９５】
電子マネーサーバ３では、以上の突合処理によって入金管理情報を状態３に更新するものがあった場合、これをファイルとして出力し、電子マネーシステム１の担当者がこれを確認することができるようになっている。
その後は、担当者がユーザに個別に対応するなどして返金手続を行うことになる。
このように、電子マネーサーバ３は、確認手段による確認結果をファイルなどに出力する出力手段を備えている。
【００９６】
以上の例では、取引未完ログと入金管理情報を突合することにより返金の必要性を判断したが、取引未完ログと取引ログを突合することにより返金の必要性を判断することも可能である。
この場合、取引未完ログと取引ログは、端末ＩＤや取引番号などを用いて対応させることができるため、電子マネーサーバ３は、取引未完ログに対応する取引ログが存在した場合、返金の必要性なしと判断し、取引未完ログに対応する取引ログが存在しなかった場合、返金の必要性ありと判断する。
【００９７】
以上に説明した本実施の形態により次のような効果を得ることができる。
（１）入金端末２は、障害が発生し、電子マネーサーバ３が取引ログを作成したか否かが不明な場合は、取引未完ログを作成することができる。
（２）電子マネーサーバ３は、入金管理情報を用いて入金処理の進捗状況を記録することができる。
（３）電子マネーサーバ３は、取引未完ログと入金管理情報を突合することにより、入金端末２が収納した紙幣に対して取引ログを作成したか否かを判断することができる。
（４）入金端末２は、電子マネーサーバ３が取引ログを作成したか否かが不明な場合、電子マネーサーバ３に問い合わせを行ってリアルタイムでリカバリを行うことができる。
【００９８】
なお、本実施の形態では、入金端末２が取引未完ログを蓄積しておき、一括して電子マネーサーバ３に送信するように構成したが、入金端末２が取引未完ログを作成すると即座に電子マネーサーバ３に送信するように構成することもできる。
この場合、電子マネーサーバ３は、リアルタイムで取引未完ログと入金管理情報を突合し、突合結果を入金端末２に送信する。
入金端末２は、電子マネーサーバ３から突合結果を受信し、その結果を判断する。そして、その結果が取引ログが作成されていないものであった場合、入金端末２は、紙幣を返金し、取引ログが作成されたものであった場合は、紙幣を保持する。
【図面の簡単な説明】
【００９９】
【図１】電子マネーシステムの構成を示した図である。
【図２】電子マネーカードの構成を説明するための図である。
【図３】入金端末の外観を示した模式図である。
【図４】入金端末のハードウェア的な構成の一例を示した図である。
【図５】電子マネーサーバのハードウェア的な構成の一例を示した図である。
【図６】チャージを行う場合の処理手順を説明するためのフローチャートである。
【図７】入金処理を説明するためのフローチャートである。
【図８】入金管理情報の構成を説明するための図である。
【図９】取引ログの構成を説明するための図である。
【図１０】取引未完ログの構成を説明するための図である。
【図１１】取引フラグの組合せと障害の対応を説明するための図である。
【図１２】返金の必要性の有無を説明するための図である。
【図１３】取引未完ログと入金管理情報を突合する手順を説明するためのフローチャートである。
【図１４】従来の入金端末がチャージを行う手順を示したフローチャートである。
【符号の説明】
【０１００】
１  電子マネーシステム
２  入金端末
３  電子マネーサーバ
４  電子マネー端末
５  電子マネーカード
【図１】
2009053753.tif 000003
【図２】
2009053753.tif 000004
【図３】
2009053753.tif 000005
【図４】
2009053753.tif 000006
【図５】
2009053753.tif 000007
【図６】
2009053753.tif 000008
【図７】
2009053753.tif 000009
【図８】
2009053753.tif 000010
【図９】
2009053753.tif 000011
【図１０】
2009053753.tif 000012
【図１１】
2009053753.tif 000013
【図１２】
2009053753.tif 000014
【図１３】
2009053753.tif 000015
【図１４】
2009053753.tif 000016