貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、前記貨幣端末から残高金額を受信する残高受信手段と、前記貨幣端末に対する演算命令の送信要求を取得する要求取得手段と、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信手段と、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、を具備したことを特徴とする貨幣端末処理サーバ。前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記演算処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、を具備したことを特徴とする請求項1に記載の貨幣端末処理サーバ。前記演算命令として減算命令を送信する場合、前記残高更新手段は、前記貨幣端末での前記減算命令の実行を確認した後に前記残高金額を更新し、前記演算命令として加算命令を送信する場合、前記演算命令送信手段は、前記残高金額を更新した後に前記加算命令を送信し、前記回復手段は、前記貨幣端末で当該減算命令が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減算した分の金額を加算させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で当該加算命令を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に加算させることにより回復処理を行うことを特徴とする請求項2に記載の貨幣端末処理サーバ。貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う貨幣情報処理方法であって、前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、演算命令送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、前記要求取得手段によって、前記貨幣端末に対する演算命令の送信要求を取得する要求取得ステップと、前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、前記演算命令送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信ステップと、前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、から構成されたことを特徴とする貨幣端末処理方法。請求項1の貨幣端末処理サーバが演算命令を送信する貨幣端末であって、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、所定の演算命令を実行して前記残高金額を演算処理する演算手段と、端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、を具備したことを特徴とする貨幣端末。請求項5に記載の貨幣端末に前記加算命令を入力する演算命令入力装置であり、加算金額を取得する加算金額取得手段と、前記取得した加算金額分の貨幣価値を加算する加算命令を生成する加算命令生成手段と、前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、前記端末フラグが初期状態であった場合は、前記生成した加算命令を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記加算命令の前記貨幣端末への入力を制限する加算命令入力手段と、を具備したことを特徴とする演算命令入力装置。貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、前記貨幣端末から残高金額を受信する残高受信手段と、前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得手段と、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信手段と、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、を具備したことを特徴とする貨幣端末処理サーバ。前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記金額変更処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、を具備したことを特徴とする請求項7に記載の貨幣端末処理サーバ。前記金額変更情報として金額を減額する金額変更情報を送信する場合、前記残高更新手段は、前記貨幣端末での金額変更処理の実行を確認した後に前記残高金額を更新し、前記金額変更情報として金額を加算する金額変更情報を送信する場合、前記金額変更情報送信手段は、前記残高金額を更新した後に前記金額変更情報を送信し、前記回復手段は、前記貨幣端末で金額を減額する金額変更処理が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減額した分の金額を増額させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で金額を増額する金額変更処理を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に増額させることにより回復処理を行うことを特徴とする請求項8に記載の貨幣端末処理サーバ。貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う情報処理方法であって、前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、金額変更情報送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、前記要求取得手段によって、前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得ステップと、前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、前記金額変更情報送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信ステップと、前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、から構成されたことを特徴とする貨幣端末処理方法。請求項7の貨幣端末処理サーバが金額変更情報を送信する貨幣端末であって、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、所定の金額変更情報を用いて前記残高金額を金額変更処理する金額変更手段と、端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、を具備したことを特徴とする貨幣端末。請求項11に記載の貨幣端末に前記残高金額を増額する金額変更情報を入力する金額変更情報入力装置であり、前記増額金額を取得する増額金額取得手段と、前記取得した増額金額分の貨幣価値を増額する金額変更情報を生成する金額変更情報生成手段と、前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、前記端末フラグが初期状態であった場合は、前記生成した金額変更情報を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記金額変更情報の前記貨幣端末への入力を制限する金額変更情報入力手段と、を具備したことを特徴とする金額変更情報入力装置。オフライン端末の場合、オフライン端末と電子マネーカードとの間での通信で処理が完結するため、通信時間が短時間例えば0.1秒程度で済み、更に通信経路も短いため、電子マネーカードの処理中に障害が生じる可能性についてはほとんど考慮する必要がなかった。しかし、オンライン端末を用いると、電子マネーカードとセンタサーバが通信を行うために通信時間が延び例えば、1秒程度、通信経路も複雑で長距離のものとなるため、電子マネーカードの処理中に障害が生じる可能性を考慮する必要が生じてくる。そして、障害が発生してこれを回復する場合、オンライン端末とオフライン端末が混在しているために、電子マネーカードでのバリュー残高とセンタサーバで記録しているバリュー残高の一致がとれない場合があり電子マネーカードでの情報は常に最新情報となるが、センタサーバでの情報は、全てのオフライン端末から情報を受信するまで最新状態に更新されないバリュー残高を用いて回復処理を行うことはできない。更に、ユーザの利便性の観点から、障害の発生によりセンタサーバと電子マネーカードのバリュー残高に不一致が生じてこれを回復する場合、ユーザの電子マネーカードに対するバリュー残高の修正が少なくとも減算処理とならない即ち、電子マネーカードのバリュー残高は変わらないかあるいは加算されるような回復システムを構築する必要がある。そこで、本発明の目的は、オンライン端末を用いた電子マネーシステムにおいて、適切に障害回復を行うことができる貨幣端末処理サーバ、貨幣端末処理方法、貨幣端末、演算命令入力装置、及び金額変更情報入力装置を提供することである。本発明は、前記目的を達成するために、請求項1に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、前記貨幣端末から残高金額を受信する残高受信手段と、前記貨幣端末に対する演算命令の送信要求を取得する要求取得手段と、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信手段と、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、を具備したことを特徴とする貨幣端末処理サーバを提供する。請求項2に記載の発明では、前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記演算処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、を具備したことを特徴とする請求項1に記載の貨幣端末処理サーバを提供する。請求項3に記載の発明では、前記演算命令として減算命令を送信する場合、前記残高更新手段は、前記貨幣端末での前記減算命令の実行を確認した後に前記残高金額を更新し、前記演算命令として加算命令を送信する場合、前記演算命令送信手段は、前記残高金額を更新した後に前記加算命令を送信し、前記回復手段は、前記貨幣端末で当該減算命令が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減算した分の金額を加算させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で当該加算命令を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に加算させることにより回復処理を行うことを特徴とする請求項2に記載の貨幣端末処理サーバを提供する。請求項4に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う貨幣情報処理方法であって、前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、演算命令送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、前記要求取得手段によって、前記貨幣端末に対する演算命令の送信要求を取得する要求取得ステップと、前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、前記演算命令送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信ステップと、前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、から構成されたことを特徴とする貨幣端末処理方法を提供する。請求項5に記載の発明では、請求項1の貨幣端末処理サーバが演算命令を送信する貨幣端末であって、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、所定の演算命令を実行して前記残高金額を演算処理する演算手段と、端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、を具備したことを特徴とする貨幣端末を提供する。請求項6に記載の発明では、請求項5に記載の貨幣端末に前記加算命令を入力する演算命令入力装置であり、加算金額を取得する加算金額取得手段と、前記取得した加算金額分の貨幣価値を加算する加算命令を生成する加算命令生成手段と、前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、前記端末フラグが初期状態であった場合は、前記生成した加算命令を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記加算命令の前記貨幣端末への入力を制限する加算命令入力手段と、を具備したことを特徴とする演算命令入力装置を提供する。請求項7に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、前記貨幣端末から残高金額を受信する残高受信手段と、前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得手段と、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信手段と、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、を具備したことを特徴とする貨幣端末処理サーバを提供する。請求項8に記載の発明では、前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記金額変更処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、を具備したことを特徴とする請求項7に記載の貨幣端末処理サーバを提供する。請求項9に記載の発明では、前記金額変更情報として金額を減額する金額変更情報を送信する場合、前記残高更新手段は、前記貨幣端末での金額変更処理の実行を確認した後に前記残高金額を更新し、前記金額変更情報として金額を加算する金額変更情報を送信する場合、前記金額変更情報送信手段は、前記残高金額を更新した後に前記金額変更情報を送信し、前記回復手段は、前記貨幣端末で金額を減額する金額変更処理が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減額した分の金額を増額させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で金額を増額する金額変更処理を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に増額させることにより回復処理を行うことを特徴とする請求項8に記載の貨幣端末処理サーバを提供する。請求項10に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う情報処理方法であって、前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、金額変更情報送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、前記要求取得手段によって、前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得ステップと、前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、前記金額変更情報送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信ステップと、前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、から構成されたことを特徴とする貨幣端末処理方法を提供する。請求項11に記載の発明では、請求項7の貨幣端末処理サーバが金額変更情報を送信する貨幣端末であって、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、所定の金額変更情報を用いて前記残高金額を金額変更処理する金額変更手段と、端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、を具備したことを特徴とする貨幣端末を提供する。請求項12に記載の発明では、請求項11に記載の貨幣端末に前記残高金額を増額する金額変更情報を入力する金額変更情報入力装置であり、前記増額金額を取得する増額金額取得手段と、前記取得した増額金額分の貨幣価値を増額する金額変更情報を生成する金額変更情報生成手段と、前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、前記端末フラグが初期状態であった場合は、前記生成した金額変更情報を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記金額変更情報の前記貨幣端末への入力を制限する金額変更情報入力手段と、を具備したことを特徴とする金額変更情報入力装置を提供する。本発明によると、オンライン端末とオフライン端末が混在した電子マネーシステムにおいて、適切に障害回復を行うことができる。実施の形態の概要電子マネーカードとセンタサーバの双方に、取引中及び取引完了の2つの値を選択的に設定できるフラグを用意する。そして、電子マネーカードとセンタサーバ間で情報処理を行う過程で、双方のフラグを立てたり取引完了から取引中に反転させたり、あるいは倒したり取引中から取引完了に復帰させたりして同期をとりながら処理を進める。処理の途中で障害が発生した場合、障害が発生した時点でのフラグの状態が両者で保存されているため、これらの状態から障害が発生した時点を特定することができる。そして、その特定した時点に応じた回復処理を行う。また、電子マネーカードで演算処理を行うタイミングとセンタサーバ側で残高記録を更新するタイミングの時間的順序を減算処理と加算処理の場合で逆にすることにより、電子マネーカードに対する復帰処理が少なくとも加算処理となるように構成することができる。即ち、電子マネーカードで減算処理を行う場合は、まず、電子マネーカードで減算処理を行った後、センタサーバでの残高記録の減算処理を行い、電子マネーカードで加算処理を行う場合は、逆にまずセンタサーバ側で加算処理を行った後に、電子マネーカードで残高記録の加算処理を行う。このように構成すると、電子マネーカードで減算処理した後、センタサーバで残高記録の減算処理を行う前に障害が生じた場合は、電子マネーカードに減算した金額分を加算して残高を減算処理前の状態に回復し、また、センタサーバで残高記録の加算処理を行って電子マネーカードで加算処理を行う前に障害が生じた場合は、電子マネーカードに加算処理を行わせて両者の整合性をとることができる。図1aを用いて、一例に係るフラグの設定手順の概要を説明する。まず、センタサーバでは、センタ側フラグが取引完了初期状態に設定されており、これを取引中反転状態に設定した後、電子マネーカードに取引中コマンド反転命令を送信するステップ1。電子マネーカードは、この取引中コマンドを受信して実行し、端末フラグカード側のフラグを取引中に設定する。そして、センタサーバに対して取引中設定通知を送信するステップ2。センタサーバは、取引中設定通知を受信した後、サーバフラグを取引中から取引完了に設定する。そして、その後電子マネーカードに取引完了コマンド復帰命令を送信するステップ3。電子マネーカードは、センタサーバから取引完了コマンドを受信して実行し、端末フラグを取引完了に設定する。そして、その後取引完了設定通知をセンタサーバに送信するステップ4。センタサーバはこれを受信する。以上のように設定したフラグを用いると、ステップ1~ステップ4の何れかで障害が発生した場合、どのステップで障害が発生したかをフラグの組合せから特定することができる。例えば、端末フラグが取引中でサーバフラグも取引中の場合はステップ2で障害が発生したことになる。また、端末フラグが取引中でサーバフラグが取引完了である場合はステップ3で障害が発生したことになる。以下同様に、ステップ1で障害が生じた場合は、端末フラグが取引完了でサーバフラグが取引中となり、ステップ4で障害が生じた場合は、端末フラグとサーバフラグが共に取引完了になる。即ち、フラグの組合せは合計4通りあり、これを各ステップに対応させたのである。そして、センタサーバが、フラグの設定コマンド取引中コマンド、又は取引完了コマンドと演算コマンドを共に電子マネーカードに送信し、電子マネーカードがフラグの設定と演算の実行を共に行うように構成すると、電子マネーカード側の情報とセンタサーバ側の情報を同期しながら更新することができる。例えば、電子マネーカードで減算処理を行う場合、図1bに示したように、ステップ1において取引中コマンドと減算コマンドを送信する。電子マネーカードはこの減算コマンドを受信して実行した後、ステップ2において減算完了通知取引中設定通知を兼ねているをセンタサーバに送信する。センタサーバは、電子マネーカードから減算完了通知を受信したのち、当該電子マネーカードの残高記録を減算する。その後、ステップ3、4の処理が行われる。以上の手順で電子マネーカードのバリュー残高と、センタサーバでの残高記録に不一致が生じるのは、ステップ2で通信障害が生じた場合である。即ち、端末フラグと、サーバフラグが共に取引中である場合、電子マネーカードでは、減算処理が行われたがセンタサーバ側では残高記録の減算処理が行われなかったことがわかる。従って、減算処理中に障害が発生し、端末フラグとサーバフラグが共に取引中である場合、電子マネーカードに減算した金額を加算する加算コマンドを送信して実行させると、減算処理前の状態に回復することができる。同様に、電子マネーカードで加算処理を行う場合、図1cに示したように、ステップ1、2の処理を行った後、ステップ3において、取引完了コマンドと加算コマンドを送信する。電子マネーカードはこの加算コマンドを受信して実行した後、ステップ4において加算完了通知取引完了設定通知を兼ねているをセンタサーバに送信する。以上の手順で電子マネーカードの残高と、センタサーバでの残高記録に不一致が生じるのは、ステップ3で通信障害が生じた場合である。即ち、端末フラグが取引中で、サーバフラグが取引完了である場合、センタサーバ側では残高記録の加算処理が行われたが、電子マネーカードでは加算処理が行われなかったことがわかる。従って、加算処理中に障害が発生し、端末フラグが取引中でサーバフラグが取引完了である場合、電子マネーカードに加算コマンドを送信して実行させると、加算処理後の状態に回復することができる。実施の形態の詳細電子マネーによる商取引では、金銭と同等の交換価値を付与したバリューと呼ばれる電子情報の値を加減することにより交換価値の移動を生じさせる。バリューは、バリュー処理機能を有するICカードである電子マネーカードに記憶されて利用者に携帯される。バリューを用いた商品サービスの購入は、バリューによる商取引を行う契約を結んでいる加盟店で行うことができる。加盟店は、店頭に電子マネーカードにアクセスする加盟店端末を設置しており、利用者の電子マネーカードに記憶されているバリューを代金分だけ減算して支払いを行う決済とも呼ばれる。また、加盟店に金銭を支払い、その金額分のバリューを電子マネーカードに書き込んでもらうこともできる。このように電子マネーカードにバリューを書き込む処理は入金又はチャージと呼ばれている。この加盟店端末には、電子マネーカードセンタのセンタサーバとオンライン接続されているオンライン端末と、バッチ処理にてログデータを一括してセンタサーバに送信するオフライン端末がある。図2は、本実施の形態の電子マネーシステムの構成を模式的に示したブロック図である。電子マネーシステム1は、電子マネーセンタ100に設置されたセンタサーバ2、各加盟店102に設置されたオンライン端末5、5、5、...、オフライン端末6、センタサーバ2とオンライン端末5、5、5、...、及びオフライン端末6、6、6、...をネットワーク接続するネットワーク4、及びオンライン端末5、及びオフライン端末6と近距離の無線通信を行う電子マネーカード7を用いて構成されている。電子マネーセンタ100は、電子マネーシステム1の運営維持管理を行う事業体であり、センタサーバ2貨幣端末処理サーバを運用している。センタサーバ2は、オンライン端末5と常時接続されており、リアルタイムでオンライン端末5と通信でき、オンライン端末5からの要求に従って演算コマンド演算命令を生成して送信することができる。なお、本実施の形態では、センタサーバ2とオンライン端末5、5、5、...を常時接続することとするが、これに限定するものではなく、例えば、必要に応じて電子マネーカード7に各種コマンドを入力する必要がある時点などオンライン端末5をセンタサーバ2に接続するように構成することもできる。また、センタサーバ2は、例えば1日1回程度、オフライン端末6が電子マネーカード7に対して行った処理に関する取引情報をまとめて受信する。更に、オフライン端末6にはネットワーク4に接続されないものもあり、これに関しては電子マネーセンタ100の担当者が、オフライン端末6から取引情報が記憶された記憶媒体を回収し、これをセンタサーバ2に入力する。加盟店102は、例えば、コンビニエンスストアやレストランなど、商品やサービスを顧客に提供する店舗であって、これら商品やサービスの対価としてバリューを使用することができるものである。加盟店102は、例えばレジにオンライン端末5やオフライン端末6を備えており、これを用いて顧客の電子マネーカード7から対価分のバリューを減算して支払いを行う。また、顧客から代金を受領して、その金額分のバリューを電子マネーカード7に入金することもできる。本実施の形態では、オンライン端末5にて支払い、入金の双方を行うことができるものとするが、支払いと入金の何れか一方を行うように構成することもできる。オンライン端末5は、端末コンピュータ5aとリーダライタ5bから構成されている。端末コンピュータ5aは、所定のコンピュータプログラムをリーダライタ5bを備えた汎用のコンピュータにインストールして構成することもできるし、あるいは、専用モジュールを組み込んだ専用機を用いて構成することも可能である。リーダライタ5bは、端末コンピュータ5aの周辺機器であり、電子マネーカード7と近距離の無線通信を行うためのアンテナを内蔵している。端末コンピュータ5aは、リーダライタ5bを介して電子マネーカード7に接続し、センタサーバ2から送信されてきた演算コマンドを電子マネーカード7に入力することができる。これに対し、オフライン端末6は、自ら演算コマンドを生成し、電子マネーカード7に入力する。図示しないが、オフライン端末6にはリーダライタ5bが内蔵されており、オフラインで電子マネーカード7に対して処理を行った後、その処理内容を記録した取引情報を1日1回程度ネットワーク4を介してセンタサーバ2に送信する。電子マネーカード7は、バリュー処理機能が組み込まれた非接触型ICカードで構成された貨幣端末である。電子マネーカード7は、バリュー処理機能を行うICチップと、リーダライタ5bと無線通信を行うためのアンテナを備えている。電子マネーカード7は、バリュー残高金額を記憶しており、リーダライタ5bから入力された加算コマンドや減算コマンドを実行してバリューの金額を加減算する。図2は電子マネーカード7の機能的な構成も示しており、図示したように電子マネーカード7は、バリュー処理部7a、残高記憶部7b、ログデータ記憶部7c、カードID記憶部7d、取引状態保持部7eなどを備えている。残高記憶部7bは、バリュー残高を記憶する記憶部である。支払いや入金の際は、残高記憶部7bに記憶されてるバリューの金額を増減する。残高記憶部7bは、貨幣価値の金額を電子データバリューとして記憶する貨幣情報記憶手段を構成している。ログデータ記憶部7cは、取引履歴をログデータとして記憶する記憶部である。取引履歴としては、例えば取引日時、取引を行った加盟店端末のID情報、支払い又は入金の別、取引額などがある。取引履歴は、例えば6件まで記憶され、古いものから順次消去されるようになっている。カードID記憶部7dは、カードIDを記憶した記憶部である。カードIDは、電子マネーシステム1において電子マネーカード7に一意に与えられたID情報であって、電子マネーセンタ100は、カードIDにより電子マネーカード7を特定することができる。なお、カードIDは、電子マネーセンタ100が電子マネーカード7に付与したものであるが、このほかに、電子マネーカード7の製造メーカが電子マネーカード7に付与したID情報を用いてもよい。何れのID情報も電子マネーカード7に記憶されており、カードIDコマンドを電子マネーカード7に入力することによりこれらID情報を読み出すことができる。取引状態保持部7eは、取引状態を記憶する記憶部である。取引状態は、電子マネーカード7側での処理が終了したか否かを表すフラグ情報であり、端末フラグを構成している。取引状態は、取引中反転状態に対応、取引完了初期状態に対応の2値を選択的にとることができる。ここで、取引状態保持部7eは、端末フラグ記憶手段を構成している。取引状態は、電子マネーカード7での処理が完了するまでは取引中に設定され、処理が完了すると取引完了に復帰させられる。これら取引中と取引完了の設定は、後述のバリュー処理部7aが、センタサーバ2から送信されてきた取引中コマンド反転命令に対応と取引完了コマンド復帰命令に対応を実行することにより行われる。ここで、バリュー処理部7aはフラグ命令実行手段に対応している。取引状態保持部7eに記憶されている取引状態は、センタサーバ2と電子マネーカード7の間の通信障害の発生時点を判断するのに用いられる。バリュー処理部7aは、リーダライタ5bから入力される各種コマンドを実行する中央演算処理部であり、演算手段を構成している。バリュー処理部7aは、加算コマンド、又は減算コマンドの入力を受け付けた場合、これらコマンドにパラメータとして付属している金額分だけ残高記憶部7bのバリューを加算、又は減算する。そして、バリュー処理部7aは、情報処理を行った場合、ログデータ記憶部7cの取引履歴を更新する。本実施の形態では、電子マネーカード7は、ネットワーク4、端末コンピュータ5a、及びリーダライタ5bから成る経路を経由してセンタサーバ2と電子マネーカード7が通信を行うが、この通信は暗号化されており、電子マネーカード7は、このための暗号化及び復号化を行う機能も備えている。ネットワーク4は、例えばインターネットによって構成されており、センタサーバ2とオンライン端末5、及びオフライン端末6の間の通信を媒介する。ネットワーク4は、WANWideAreaNetworkやLANLocalAreaNetworkなどで構成してもよく、また、通信衛星を用いた通信回線、電話回線網、光ケーブル網などを用いることもできる。図3は、電子マネーカード7のハードウェア的な構成の一例を模式的に表したブロック図である。電子マネーカード7は、アンテナ701とICチップ702を内蔵したプラスチックカードである。本実施の形態では、電子マネーカード7として非接触型ICカードを用いるものとするが、接触型ICカードによって構成することも可能である。この場合、電子マネーカード7は、アンテナ701の代わりにICチップ702にアクセスするための接触端子を備える。加盟店端末もこの接触端子に接続する端子を備え、これら端子を介して電子マネーカード7と加盟店端末が通信を行う。アンテナ701は、リーダライタ5bが備えたアンテナと無線通信を行うための素子である。アンテナ701は、リーダライタ5bが放射した電波を受信すると共に、リーダライタ5bに対して電波を放射する。また、アンテナ701は、リーダライタ5bから電力の供給を無線により受け、ICチップ702を駆動するための電力を発電する発電機能も有している。ICチップ702は、ROMReadOnlyMemory703、CPUCentralProcessingUnit704、高周波回路部705、RAMRandomAccessMemory706、記憶部707などの各素子を備えた一種のコンピュータである。これらの素子は1つのICチップの中に形成されている。CPU704は、各種のプログラムに従って情報処理を行ったり、電子マネーカード7全体の動作を制御する中央処理装置である。ROM703は、電子マネーカード7を機能させるための基本的なプログラムOSOperatingSystem、リーダライタ5bとの通信プログラムなどや各種データが記憶された読み取り専用メモリである。高周波回路部705は、アンテナ701を介してリーダライタ5bと通信を行うインターフェースである。CPU704は、高周波回路部705を介してリーダライタ5bと無線通信を行うことができる。RAM706は、読み書き可能な揮発性のメモリであって、CPU704が各種の情報処理を行う際のワーキングエリアを提供する。本実施の形態では、例えば、CPU704が加算コマンドや減算コマンドを実行してバリューの金額を増減する際に使用する。記憶部707は、例えばEEPROMElectricallyErasableandProgrammableROMで構成され、CPU704によって情報の読み書きが可能な不揮発性のメモリである。記憶部707には、各種のアプリケーションソフトを記憶させてインストールしてこれをCPU704に実行させ、各種の機能を電子マネーカード7に発揮させることが可能である。本実施の形態では、CPU704に電子マネーカード7としての機能を発揮させるためのプログラムであるバリュー処理プログラムを記憶させてある。記憶部707には、バリュー処理プログラムが記憶されているほか、残高記憶部7b、ログデータ記憶部7c、カードID記憶部7d、取引状態保持部7eなどが形成されている。電子マネーカード7をリーダライタ5bに近接させて駆動すると、CPU704がバリュー処理プログラムを実行し、バリュー処理部7aがソフトウェア的に構成される。これにより、残高記憶部7b、ログデータ記憶部7c、カードID記憶部7d、取引状態保持部7eにアクセスし、各種の情報処理を行うことができる。なお、近年はICチップ702を携帯電話などの携帯端末に内蔵させ、これら携帯端末に非接触型ICカードとしての機能を持たせる試みも行われている。この利用形態では、ICチップ702とアンテナ701を携帯端末に備え、電子マネーカード7と同様にリーダライタ5bから無線によりアクセスすることができるほか、携帯端末が備えた表示装置にICチップ702内の情報を表示させたり、あるいは携帯端末の入力装置を介してICチップ702に情報を入力することも可能である。以下、本実施の形態では、電子マネーカード7を用いて説明するが、これらICチップ702を内蔵した携帯端末を用いることもできる。図4は、センタサーバ2のハードウェア的な構成を模式的に表したブロック図である。センタサーバ2は、制御部10にバスライン32を介して入力装置18、出力装置20、通信制御装置24、記憶装置30、などが接続して構成されている。制御部10は、CPU12、ROM14、RAM16などから構成されている。CPU12は、ROM14、記憶装置30、その他に記憶されているプログラムをロードして実行する中央処理装置である。本実施の形態では、記憶装置30に記憶されている取引処理プログラムを実行し、センタサーバ2としての機能を発揮する。ROM14は、例えば、CPU12が機能するための基本的な制御を行うための各種プログラム、データ及びパラメータを格納した読み出し専用の不揮発性メモリである。ROM14内のプログラムは、例えば、センタサーバ2の起動時に実行される。RAM16は、CPU12にワーキングメモリとして使用される読み書き可能なメモリであり、例えば、取引処理プログラムを実行する際に使用される。入力装置18は、例えばキーボード、マウスなどの入力デバイスから構成されている。出力装置20は、例えばディスプレイなどで構成された表示装置、プリンタなどで構成された印刷装置などから構成されている。電子マネーセンタ100のオペレータは、これら入力装置18や出力装置20を用いてセンタサーバ2にアクセスし、保守作業やプログラムのアップデートその他の作業を行うことができる。通信制御装置24は、センタサーバ2をネットワーク4に接続するための装置であって、モデム、ターミナルアダプタその他の接続装置によって構成されている。通信制御装置24はCPU12によって制御され、所定のプロトコルに従って加盟店端末とデータやその他の情報の送受信を行う。加盟店端末がオンライン端末5の場合は常時接続されており、オフライン端末6の場合は、オフライン端末6がバッチ処理を行う際に接続を受け付ける。記憶装置30は、読み書き可能な記憶媒体と、その記憶媒体に対してプログラムやデータを読み書きするための駆動装置によって構成されている。当該記憶媒体として主にハードディスクが使用されるが、その他に、例えば、光磁気ディスク、磁気ディスク、半導体メモリなどのほかの読み書き可能な記憶媒体によって構成することも可能である。記憶装置30には、各種プログラムを記憶したプログラム格納部34と各種のデータを記憶したデータ格納部36が形成されている。プログラム格納部34には、OS40、取引処理プログラム42、...などのプログラムがインストールされている。OS40は、ファイルの入出力や通信制御装置24の制御など、センタサーバ2を動作させる上で基本的な機能を実現するプログラムである。取引処理プログラム42は、センタサーバ2に、オンライン端末5を介して電子マネーカード7と通信し、例えば、以下のような処理を行わせるプログラムである。1支払い処理これは、電子マネーカード7に記憶されたバリューを商品代金などの支払い代金として決済する処理である。この場合、センタサーバ2は、オンライン端末5から要求された減算コマンドを電子マネーカード7に送信し、これを電子マネーカード7で実行させる。また、この際に、電子マネーカード7の取引状態とセンタサーバ2の取引状態の2つのフラグを設定しながら処理を進める。2入金処理これは、電子マネーカード7に入金してバリュー残高を増額するものである。この場合、センタサーバ2は、オンライン端末5から要求された加算コマンドを電子マネーカード7に送信し、これを電子マネーカード7で実行させる。この場合も、電子マネーカード7の取引状態とセンタサーバ2の取引状態の2つのフラグを設定しながら処理を進める。以上のように、センタサーバ2は、演算コマンド演算命令を送信する演算命令送信手段を備えている。3残高確認処理これは、電子マネーカード7に記憶されているバリュー残高を提示するものである。この場合、センタサーバ2は、残高確認コマンドを生成して電子マネーカード7に送信し、これを電子マネーカード7に実行させる。すると、電子マネーカード7は、バリュー残高をセンタサーバ2に送信するので、センタサーバ2は、これをオンライン端末5に表示させる。また、オンライン端末5が電子マネーカード7に残高確認コマンドを入力し、これに対して電子マネーカード7が返してきたバリュー残高をオンライン端末5が表示するように構成することもできる。4障害発生後の回復処理これは、センタサーバ2と電子マネーカード7が通信を行っている際に障害が発生し、処理が中断した場合にその回復処理を行うものである。センタサーバ2は、センタサーバ2及び電子マネーカード7の取引状態の設定状態から障害が発生した時点を判断し、その時点に応じた回復処理を行う。センタサーバ2は、支払い処理、入金処理、及び残高確認処理を行う前に、センタサーバ2と電子マネーカード7の取引状態から前回の処理で障害が発生したか否かを確認し、障害が発生していた場合はこれを回復してから処理を続行する。このようにセンタサーバ2は、回復手段を備えている。次に、データ格納部36について説明する。センタサーバ2の運用に必要な各種のデータが記憶されており、データ格納部36には、加盟店端末情報データベース44、取引情報データベース46、...などが記憶されている。加盟店端末情報データベース44は、各加盟店102に設置されたオンライン端末5やオフライン端末6に関する情報を記憶したデータベースである。加盟店端末情報データベース44には、例えば、加盟店端末が設置されている加盟店102のID情報である加盟店ID、加盟店102内でオンライン端末5やオフライン端末6に設定されたID情報である端末ID、電子マネーシステム1内でオンライン端末5やオフライン端末6に一意に付与されたID情報であるシリアルID...などの情報が記憶されている。センタサーバ2は、加盟店102からシリアルIDを受信すると、当該オンライン端末5、又はオフライン端末6を特定でき、更に加盟店102を特定することができる。また、オンライン端末5やオフライン端末6を特定するのに端末IDとシリアルIDの2つのID情報を付与したのは、加盟店102の便宜を図るためである。即ち、端末IDは、例えば、加盟店端末の設置順に01、02、...などと加盟店102にとって認識しやすい情報となっており、加盟店102は、加盟店内での管理や故障時の問い合わせを端末IDで行うことができる。取引情報データベース46は、オンライン端末5やオフライン端末6を介して電子マネーカード7に対して行った取引情報を履歴として蓄積するデータベースである。取引情報は、電子マネーカード7に対して処理を行う際に生成されるログデータであり、オンライン端末5を介して電子マネーカード7を処理する場合はリアルタイムで生成され、オフライン端末6で処理する場合は、一旦オフライン端末6に蓄積された後、バッチ処理などでセンタサーバ2に送られてくる。図5は、オンライン端末5にてカードID00001なる電子マネーカード7を処理した場合に生成された取引情報61、62、63を時系列にて並べて示した図である。図に示したように、取引情報はカードID52、残高53、取引額54、取引状態55、処理内容56、シリアルID57、取引日時58、...などの各項目から構成されている。カードID52は、オンライン端末5を介して電子マネーカード7から受信したカードIDである。残高53は、電子マネーカード7の演算処理後のバリュー残高であり、取引額54は、演算の際に加減算した金額である。センタサーバ2は、支払い、又は入金処理の際に電子マネーカード7からバリュー残高を受信すると共に残高受信手段に対応、オンライン端末5から演算コマンドの送信要求加減算する金額が付属しているを取得する要求取得手段に対応。残高53は、これらの値を用いて計算されたものである。取引状態55は、取引中反転状態に対応と取引完了初期状態に対応のうちの何れかが選択的に設定されるフラグ情報であり、サーバフラグを構成している。取引状態55は、センタサーバ2側の処理が開始した際に取引中に設定され、センタサーバ2側の処理が完了した際に取引完了に更新される。このように、センタサーバ2は、取引状態55を取引完了から取引中に反転させたり、あるいは取引中から取引完了に復帰させるサーバフラグ設定手段を備えている。図5の例では、図中上から3番目の取引情報は取引状態55が取引中となっており、この取引情報に関するセンタサーバ2側の処理はまだ完了していないことがわかる。シリアルID57は、電子マネーカード7との通信を仲介しているオンライン端末5のシリアル番号である。このシリアル番号を加盟店端末情報データベース44と照合することにより、電子マネーカード7の処理を行った加盟店102を特定することができる。取引日時58は、オンライン端末5と通信を行った日時である。例えば、通信開始時刻、及び通信終了時刻などが記憶されている。図5に示したように、カードID5200001で特定される電子マネーカード7に対して行った処理は取引情報として時系列的に記録される。他のカードIDに係る電子マネーカード7に関しても同様に取引情報が蓄積される。オンライン端末5で行った処理に関してはリアルタイムで取引情報が取引情報データベース46に記録されるが、オフライン端末6で行った処理に関しては、バッチ処理にてオフライン端末6から送信されてきてから取引情報データベース46に記録されるまでタイムラグが生じる。また、オフライン端末6での処理では、処理中にオフライン端末6と電子マネーカード7の間で障害が発生しないので、オフライン端末6での処理では必ずしも取引状態55の項目を設ける必要はない。以上にセンタサーバ2について説明したが、オンライン端末5のハードウェア的な構成は、基本的にセンタサーバ2と同様である。オンライン端末5は、加盟店102の担当者や電子マネーカード7を有する顧客などに情報を表示するための表示装置や、効果音などの音声により処理状況を通知する音声出力装置などを備えている。次に、図6~図13のフローチャートを用いて、電子マネーカード7を用いた代金の支払い処理手順、及び支払い中に障害が発生した場合の回復手順などについて説明する。ここでは、一例として20、000円チャージされた電子マネーカード7を用いて9、000円の支払いを行う場合について説明する。図6は、電子マネーカード7に支払い処理を施す手順を説明するためのフローチャートである。このフローチャートでは、電子マネーカード7側とセンタサーバ2側でデータが更新される様子を説明するため、それぞれカード情報と取引情報を併記している。カード情報は、電子マネーカード7側で保持されているデータの論理的構成を示したものである。カード情報は、カードID、残高、取引額、取引状態などの項目から構成されている。これらカードID、残高、取引額、取引状態の各値は、それぞれ、バリュー処理部7a、残高記憶部7b、ログデータ記憶部7c、取引状態保持部7eに記憶されている情報を用いることができる。例えば、カード情報71では、カードIDが00001であり、バリュー残高が20、000円であり、また、取引状態は取引完了に設定されている。カード情報71では、取引状態が取引完了に設定されているため、前回の処理において、電子マネーカード7側の処理は完了していることがわかる。このように構成されたカード情報と取引情報を参照しながら支払い処理について説明する。まず、顧客は加盟店102の担当者店員に商品を提示して購入の意思表示を行う。これに対し、担当者はバーコード読取装置などを用いて商品の代金9、000円を読み取り、これを支払額としてオンライン端末5に入力する。すると、オンライン端末5の表示装置に図22aに示したような、カード確認画面が表示される。カード確認画面には、支払額が表示されるほか、電子マネーカードをセットしてくださいなどと、電子マネーカード7をオンライン端末5のリーダライタ5bにセットするように促す指示が表示される。顧客はカード確認画面の指示に従って、オンライン端末5に電子マネーカード7をセットする。図6に戻り、電子マネーカード7は、オンライン端末5にセットされるとリーダライタ5bの電波によって駆動され、オンライン端末5との通信を開始するステップ104。電子マネーカード7がオンライン端末5と接続されると、センタサーバ2は電子マネーカード7と通信できるようになる。電子マネーカード7とセンタサーバ2が通信を行っている間、オンライン端末5の表示装置には、図22bに示したような通信中画面が表示される。これにより、顧客と加盟店102の担当者は電子マネーカード7とセンタサーバ2が通信中であることを認識することができる。図6に戻り、オンライン端末5は電子マネーカード7と通信を開始すると、電子マネーカード7からカードIDを読み取り、これを支払額と共にセンタサーバ2に送信するステップ204。なお、カードIDの読み取りは、オンライン端末5が電子マネーカード7にカードIDコマンドを電子マネーカード7に入力することにより行われる。電子マネーカード7では、バリュー処理部7aがカードIDコマンドを実行し、カードID記憶部7dからカードIDを読み取ってオンライン端末5に返すようになっている。センタサーバ2はオンライン端末5からこれらの情報を受け付けると、電子マネーカード7に対して残高状態確認要求を行うステップ304。この要求は、電子マネーカード7に対してバリュー残高と取引状態の送信を要求するものであり、電子マネーカード7にこれらの動作を行わせるためのコマンドを送信することにより行われる。電子マネーカード7は、オンライン端末5から残高状態確認要求を受け、残高状態確認応答を行うステップ106。この処理は、オンライン端末5から送信されてきたコマンドをバリュー処理部7aが実行して、残高記憶部7bに記憶されているバリュー残高と、取引状態保持部7eに記憶されている取引状態をセンタサーバ2に送信することにより行われる。このように、センタサーバ2は、端末フラグ受信手段電子マネーカード7の取引状態を受信を備えている。センタサーバ2は、電子マネーカード7からバリュー残高と取引状態を受信する。そして、受信した取引状態と取引情報データベース46に記憶されている前回の取引情報の取引状態を確認し、前回の取引で障害が発生したか否かを確認する。障害が発生していた場合は後述の方法により障害を回復する。ここでは、障害が発生しなかったものとする。センタサーバ2は、電子マネーカード7とセンタサーバ2側の取引情報を確認した後、今回の処理に関する取引情報81を生成して取引情報データベース46に記憶して登録するステップ306。取引情報81では、電子マネーカード7から受信したカードID、バリュー残高、及びオンライン端末5で入力された取引額などが記憶される。なお、図では処理内容、シリアルID、取引日時、...などのほかの項目は省略してある。図に示したように、取引情報81では、カードIDが00001、残高が減算後の値で11、000円、取引額が9、000円となっている。なお、登録時には、取引情報81の取引状態は取引中に設定されている。このように、取引状態は、センタサーバ2側の処理が開始される際に取引中に設定される。そして、センタサーバ2側での処理が完了した際に取引完了に設定される。取引状態が取引中の場合は、取引情報の取引情報データベース46への記録が確定した訳ではなく、後述のように障害回復の際に無効とされる場合がある。そのため、取引情報81で残高が減算後の値になっているが、これは、障害回復の際に利用するためであり、センタサーバ2側での減算処理が完了するのは、取引状態が取引完了に設定された時点である。次に、センタサーバ2は、電子マネーカード7に対して取引中減算要求をおこなうステップ308。この要求は、電子マネーカード7に取引中コマンドと、支払額分の減算を実行させるための減算コマンドを送信することにより行われる。本実施の形態では、電子マネーカード7において、減算コマンドの実行と取引状態の更新を対応させるため、減算コマンドと取引中コマンドを共に送信することにした。即ち、取引状態が更新されたことを確認することにより、電子マネーカード7で減算コマンドが実行されたことを確認することができる。後の入金処理でも加算コマンドと取引完了コマンドを共に電子マネーカード7に送信するのも同じ理由による。電子マネーカード7は、これらのコマンドを受信して実行し、取引状態を取引中に設定すると共に、バリュー残高を支払額分だけ減算する。この結果、カード情報71はカード情報72に更新される。図に示したように、カード情報72では、残高が11、000円と減算後の値となっており、また、取引状態は、取引中に設定されている。次に、電子マネーカード7は、減算が完了し、取引状態を取引中に設定した旨を示す減算完了通知をセンタサーバ2に送信するステップ108。センタサーバ2は、電子マネーカード7から減算完了通知を受信すると取引情報81の取引状態を取引完了に設定し、取引情報82へ更新するステップ310。これにより、センタサーバ2は、センタサーバ2側での減算処理を完了させると共に取引情報82の取引情報データベース46への登録が確定する。センタサーバ2は、センタサーバ2側での減算処理を完了させると、電子マネーカード7に対して取引完了設定要求を行うステップ312。この要求は、電子マネーカード7に取引完了コマンドを送信することにより行われる。これに対し、電子マネーカード7は、取引完了コマンドを受信して実行し、取引状態を取引完了に設定するステップ110。即ち、取引状態の値を取引中から取引完了に復帰する。その結果、カード情報はカード情報73のように更新される。電子マネーカード7は、取引完了コマンドを実行後、取引状態を取引完了に設定した旨を表す取引完了通知をセンタサーバ2に送信する。センタサーバ2は、電子マネーカード7から取引完了通知を受信すると、電子マネーカード7との処理が完了した旨を表す取引完了通知をオンライン端末5に送信するステップ314。オンライン端末5は、センタサーバ2から取引完了通知を受信して処理が完了したことを確認するステップ206。このとき、オンライン端末5は、処理成功を表す効果音と共に表示装置に図22cに示したような支払い完了画面を表示する。支払い完了画面では、カードIDと支払金額、及び支払い後のバリュー残高などが表示される。以上に説明した支払い処理で、電子マネーカード7とセンタサーバ2の通信に障害が発生する可能性がある箇所としては、ステップ106障害1と呼ぶ、以下同様、ステップ308障害2、ステップ108障害3、ステップ312障害4、ステップ110障害5がある。なお、ステップ304で障害が発生する可能性もあるが、この場合の処理は障害1と同じであるので説明を省略する。以下に、これら障害1~障害5が発生した場合の処理手順と、その回復処理手順について説明する。図7は、障害1が発生した場合の処理手順を説明するためのフローチャートである。なお、以下では図6のフローチャートに対応するステップには同じステップ番号を付して説明を簡略化、あるいは省略することにする。まず、電子マネーカード7がバリュー残高と取引状態をオンライン端末5に送信する際にステップ106障害1が発生した場合、センタサーバ2は、障害1を検出するステップ316。ここで、電子マネーシステム1は、タイムアウトにより障害を検出するものとする。即ち、センタサーバ2は、電子マネーカード7からの応答を受信するまでの時間を計測し、予め設定した所定時間内に応答がない場合、障害が発生したものと判断する。なお、これは一例であって他の方法により障害を検出してもよい。センタサーバ2は、障害1を検出すると、処理が失敗した旨を表す取引失敗通知をオンライン端末5に送信するステップ318。オンライン端末5は、センタサーバ2から取引失敗通知を受信して処理が失敗したことを確認するステップ208。オンライン端末5は、処理の失敗を確認すると取引失敗を表す効果音と共に図22dに示したようなエラー発生画面を表示する。エラー発生画面では、残高確認を指示する旨の表示が行われ、加盟店102の担当者は、電子マネーカード7の残高確認処理を行うことになる。このように電子マネーシステム1は、エラーが発生すると残高確認を要求し、残高確認処理に伴って障害を回復するようになっている。即ち、残高確認処理は、まずセンタサーバ2が電子マネーカード7側とセンタサーバ2側の取引状態を確認して前回の処理で障害が発生したか否かを確認する。障害が発生していない場合は残高確認を行い、障害が発生していた場合は回復処理を行った後残高確認を行う。なお、図6の説明では省略したが、支払い処理や後に説明する入金処理においても、まずセンタサーバ2は前回の処理で障害が発生したか否かを確認し、障害が発生していた場合はこれを回復してから支払い処理、あるいは入金処理を続行する。さて、障害1が発生した場合、カード情報71は未処理であり、またセンタサーバ2でも取引情報が登録される前なので回復処理を行う必要はない。このため、障害1が発生した場合は、回復処理をせずに残高確認が行われる。そして、加盟店102の担当者は、残高確認の後に支払い処理を最初から行うことになる。次に、図8のフローチャートを用いて障害2、及び障害3が発生した場合の処理手順を説明する。ステップ308障害2、又はステップ108障害3で障害が発生した場合、センタサーバ2はこれを検出しステップ320、オンライン端末5に対して取引失敗通知を送信するステップ322。オンライン端末5は、取引失敗通知を受信して失敗を確認し、効果音と共にエラー発生画面を表示するステップ210。ここで障害2と障害3のうち、何れが発生したかは、カード情報と取引情報の取引状態の組合せから特定することができる。即ち、障害2が発生した場合、カード情報はカード情報71となり、障害3が発生した場合はカード情報72となる。また、取引情報は、障害2、障害3の何れの場合でも取引情報81となる。このためカード情報と取引情報の取引状態の組合せは、障害2が発生した場合は取引完了、取引中となり、障害3が発生した場合は取引中、取引中となる。以下では、同様にカード情報と取引情報の取引状態の組合せをこの順序で括弧書きにて記すことにする。図9は、障害2が発生した場合の回復処理手順を説明するためのフローチャートである。この処理は、オンライン端末5でエラー発生画面の指示に従って、加盟店102の担当者が電子マネーカード7の残高確認を要求することにより開始する。担当者は、電子マネーカード7をリーダライタ5bにセットして電子マネーカード7とオンライン端末5の通信を開始しステップ104なお、通常はエラーが発生した時点で電子マネーカード7がオンライン端末5にセットされているので、このまま引き続き残高確認処理に移行する、オンライン端末5に設けられた残高確認ボタンを押すなどしてセンタサーバ2に残高確認を要求するステップ205。センタサーバ2は、オンライン端末5より残高確認要求を受けて、残高状態確認要求を電子マネーカード7に対して行いステップ304、これに対し、電子マネーカード7は、残高状態確認応答を行うステップ106。次に、センタサーバ2は、残高状態確認応答により電子マネーカード7から送信されてきた取引状態と、前回の取引情報81の取引状態の組合せを確認する。その結果、取引状態の組合せが取引完了、取引中となり、また、前回の処理が支払い処理であったため図示しないが取引情報81に記録されている、センタサーバ2は前回の処理が障害2により中断したと判断する。障害2が発生した場合、センタサーバ2は、取引情報81の取引状態を取引回復に設定することにより状態回復を行う。センタサーバ2は、取引状態が取引回復に設定されている取引情報は無効になったものとして扱うように構成されており、その結果、前々回の取引情報80が電子マネーカード7に対して最新の取引情報となる。換言すればセンタサーバ2は前回の取引情報81を前々回の取引情報80に更新することにより障害回復を行うステップ324。センタサーバ2は、取引情報を更新した後、障害回復を行った旨を表す障害回復通知をオンライン端末5に送信するステップ326。オンライン端末5はこれを受信して障害が回復したことを確認するステップ212。なお、本実施の形態では、障害回復通知として電子マネーカード7のバリュー残高を送信し、オンライン端末5ではバリュー残高が表示されるようになっている。即ち、残高確認と共に障害回復を行っている。そして、加盟店102の担当者は残高確認を行った後、支払い処理を再度最初から行う。このように、障害2が発生した場合はカード情報が更新前のままであるので、取引情報を更新前のものに戻すことにより、両者の整合性をとることができる。図10は、障害3が発生した場合の回復処理手順を説明するためのフローチャートである。ステップ104~ステップ106までは障害2の場合と同様である。そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報81の取引状態の組合せを確認し、取引状態の組合せが取引中、取引中であり、また前回の取引が支払い処理であったことから、前回の処理が障害3により中断したと判断する。障害3が発生した場合、センタサーバ2は、前回の処理において電子マネーカード7で減算した金額分の加算を行う加算コマンドを生成し、取引完了コマンドと共に電子マネーカード7に送信するステップ328。電子マネーカード7は、この加算コマンドを実行し、前回減算した分のバリューを加算し、取引状態を取引完了に設定する。そして、加算処理と取引完了に設定した旨を表す加算完了通知をセンタサーバ2に送信するステップ112。以上の処理によりカード情報はカード情報72からカード情報71に更新される。センタサーバ2は、電子マネーカード7から加算完了通知を受信すると、障害2の場合と同様に取引情報81の取引状態を取引回復に設定して取引情報を更新するステップ330。これにより、前々回の取引情報80が最新の取引情報として扱われる。次に、センタサーバ2は、オンライン端末5に障害回復通知を送信しステップ332、オンライン端末5はこれにより障害が回復したことを確認するステップ214。そして、障害3を回復した後に支払い処理を再度最初から行う。以上のように、障害3が発生した場合は、電子マネーカード7に障害発生時に減算したバリューを加算してバリュー残高を障害発生前の状態に戻すと共に、取引情報も障害発生時前のものに戻す。即ち、センタサーバ2で取引情報が確定する前取引情報が支払い後のものに更新される前に、電子マネーカード7で減算を実行するため、電子マネーカード7に減算したバリューを戻すことにより障害発生前の状態に復帰することができる。図11は、障害4、及び障害5が発生した場合の処理手順を説明するためのフローチャートである。ステップ104~ステップ310までは図6のフローチャートと同様である。センタサーバ2は、取引情報を取引情報82に更新した後ステップ310、電子マネーカード7に宛てて取引完了コマンドを送信するステップ312。その後、障害4又は障害5が発生した場合、センタサーバ2はこれらの何れかの障害が発生したことを検出しステップ334、オンライン端末5に対して取引失敗通知を行うステップ336。そして、オンライン端末5は、取引処理失敗を表す効果音と共に表示装置にエラー発生画面を表示するステップ216。カード情報は障害4が発生した場合はカード情報72となり、障害5が発生した場合はカード情報73となる。また、取引情報は何れの場合も取引情報82である。その結果、取引状態の組合せは、障害4の場合は取引中、取引完了となり、障害5の場合は取引完了、取引完了となる。図12は、障害4が発生した場合の回復処理手順を説明するためのフローチャートである。ステップ104~ステップ106までは障害2の場合と同様である。そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報82の取引状態の組合せを確認し、取引状態の組合せが取引中、取引完了であり、また前回の取引が支払い処理であったことから、前回の処理が障害4により中断したと判断する。障害4が発生した場合は、電子マネーカード7とセンタサーバ2の何れも減算処理は完了しており、カード情報72の取引状態が不整合であるだけなのでこれを取引中から取引完了に復帰させることにより障害回復を行う。そのため、センタサーバ2は電子マネーカード7に取引完了設定要求を行うステップ338。この取引完了設定要求は、電子マネーカード7に取引完了コマンドを送信することにより行われる。電子マネーカード7は、取引完了コマンドを受信して実行し、カード情報72の取引状態を取引完了に設定する。これにより、カード情報はカード情報72からカード情報73に更新される。そして、電子マネーカード7は、取引完了通知をセンタサーバ2に送信するステップ114。センタサーバ2は、取引完了通知を受信した後、障害回復通知をオンライン端末5に送信しステップ340、オンライン端末5は、これを受信して障害4が回復されたことを確認するステップ218。図13は、障害5が発生した場合の回復処理手順を説明するためのフローチャートである。ステップ104~ステップ106までは障害2の場合と同様である。そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報82の取引状態の組合せを確認し、取引状態の組合せが取引完了、取引完了であり、また前回の取引が支払い処理であったことから、前回の処理が障害5により中断したと判断する。障害5が発生した場合は、カード情報と取引情報の何れも支払い処理後のものに更新されており、カード情報が更新されたことをセンタサーバ2が確認できていなかっただけなので、特に回復処理を行う必要はない。そのため、センタサーバ2は、特に回復処理を行わずにオンライン端末5に障害回復通知を送信しステップ342、オンライン端末5は、これにより障害が回復したことを確認するステップ220。次に、図14~図20のフローチャートを用いて、電子マネーカード7を用いた入金処理手順、及び入金中に障害が発生した場合の回復手順などについて説明する。ここでは、一例として20、000円チャージされた電子マネーカード7に9、000円の入金を行う場合について説明する。図14は入金処理の手順を説明するためのフローチャートである。入金処理の場合、まず顧客は加盟店102の担当者に現金9、000円を渡し、9、000円分の入金を依頼する。担当者は、顧客から現金9、000円を受領すると共に、9、000円を入金額としてオンライン端末5に入力する。すると、オンライン端末5の表示装置にカード確認画面が表示されるので、顧客は画面の指示に従って電子マネーカード7をリーダライタ5bにセットする。電子マネーカード7は、オンライン端末5にセットされると、オンライン端末5のリーダライタ5bから放射される電波によって駆動され、オンライン端末5との通信を開始するステップ504。電子マネーカード7がオンライン端末5と接続されると、センタサーバ2は電子マネーカード7と通信できるようになり、オンライン端末5の表示装置には通信中画面が表示される。オンライン端末5は電子マネーカード7と通信を開始すると、電子マネーカード7からカードIDを読み取り、これを入金額と共にセンタサーバ2に送信するステップ604。センタサーバ2はこれらの情報を受け付けると、電子マネーカード7に対して残高状態確認要求を行うステップ704。電子マネーカード7は、これを受け、残高状態確認応答を行うステップ506。センタサーバ2は、電子マネーカード7から残高状態確認応答を受けると、前回の処理で障害が発生したか否かを確認し、障害が発生していた場合は、これを回復してから処理を続行する。障害回復処理については後述し、ここでは、障害が発生しなかったものとする。センタサーバ2は、前回の処理で障害が発生していないことを確認した後、この処理に関する取引情報86を生成して取引情報データベース46に登録するステップ706。取引情報86では、残高が入金後の金額となっているが、取引状態が取引中に設定されており、取引情報データベース46への登録はまだ確定していない。即ち、センタサーバ2ではまだ加算処理は完了していない。次に、センタサーバ2は、電子マネーカード7に対して取引中設定要求を行うステップ708。電子マネーカード7は取引中設定要求を受けて取引状態を取引中に設定し、取引中設定通知をセンタサーバ2に送信するステップ508。これにより、カード情報76は、カード情報77に更新される。センタサーバ2は、電子マネーカード7から取引中設定通知を受信すると取引状態を取引完了に設定し、これによって取引情報86を取引情報87に更新するステップ710。取引状態を取引完了に設定することにより取引情報87の取引情報データベース46への登録が確定し、センタサーバ2で加算が行われたことになる。次に、センタサーバ2は、電子マネーカード7に取引完了設定加算要求を行うステップ714。これは、入金額分の加算を行う加算コマンドと取引完了コマンドを共に電子マネーカード7に送信することにより行われる。電子マネーカード7は、これらのコマンドを受信し、加算コマンドを実行して、バリュー残高を9、000増加させると共に、取引状態を取引完了に設定する。そして、加算処理と取引完了に設定した旨を表す加算完了通知をセンタサーバ2に送信するステップ510。加算コマンドと取引完了コマンドの実行によりカード情報77はカード情報78に更新される。図に示したようにカード情報78は、バリュー残高が29、000円となり、取引状態が取引完了に設定されている。センタサーバ2は、電子マネーカード7から加算完了通知を受信すると、取引完了通知をオンライン端末5に送信するステップ716。オンライン端末5は、センタサーバ2から取引完了通知を受信して処理が完了したことを確認するステップ606。このとき、オンライン端末5は、処理成功を表す効果音と共に表示装置に入金完了画面が表示される。図14に示した入金処理で、電子マネーカード7とセンタサーバ2の通信に障害が発生する可能性がある箇所としては、ステップ506障害6、ステップ708障害7、ステップ508障害8、ステップ714障害9、ステップ510障害10がある。なお、ステップ704で障害が発生する可能性もあるが、この場合の処理は障害6と同じであるので説明を省略する。以下に、これら障害6~障害10が発生した場合の処理手順と、回復処理手順について説明する。図15は、障害6が発生した場合の処理手順を説明するためのフローチャートである。なお、以下では図15のフローチャートに対応するステップには同じステップ番号を付して説明を簡略化、あるいは省略することにする。まず、電子マネーカード7がバリュー残高と取引状態をセンタサーバ2に送信する際にステップ506障害6が発生した場合、センタサーバ2は、障害6を検出するステップ718。センタサーバ2は、障害6を検出すると、取引処理が失敗した旨を表す取引失敗通知をオンライン端末5に送信するステップ720。オンライン端末5は、センタサーバ2から取引失敗通知を受信して処理が失敗したことを確認するステップ608。このとき、オンライン端末5は、取引失敗を表す効果音と共にエラー発生画面を表示する。エラー発生画面には残高確認を指示する旨の通知が行われ、加盟店102の担当者は、電子マネーカード7の残高確認処理を行うことになる。さて、障害6が発生した場合、カード情報76は未処理であり、またセンタサーバ2でも取引情報が登録される前なので回復処理を行う必要はない。このため、障害6が発生した場合は、回復処理をせずに残高確認が行われる。そして、加盟店102の担当者は、残高確認の後に処理を最初から行うことになる。図16は、障害7、及び障害8が発生した場合の処理手順を説明するためのフローチャートである。ステップ708障害7、又はステップ508障害8で障害が発生した場合、センタサーバ2はこれを検出しステップ718、オンライン端末5に対して取引失敗通知を送信するステップ720。オンライン端末5は、取引失敗通知を受信して失敗を確認し、効果音と共にエラー発生画面を表示するステップ608。ここで障害7と障害8のうち、何れが発生したかは、カード情報と取引情報の取引状態の組合せから特定する。即ち、障害7が発生した場合、カード情報はカード情報76となり、障害8が発生した場合はカード情報77となる。また、取引情報は、障害7、障害8の何れの場合でも取引情報86となる。このためカード情報と取引情報の取引状態の組合せは、障害7が発生した場合は取引完了、取引中となり、障害8が発生した場合は取引中、取引中となる。図17は、障害7が発生した場合の回復処理手順を説明するためのフローチャートである。この処理は、オンライン端末5でエラー発生画面の指示に従って、加盟店102の担当者が電子マネーカード7の残高確認を要求することにより開始する。担当者は、電子マネーカード7をリーダライタ5bにセットして電子マネーカード7とオンライン端末5の通信を開始しステップ504なお、通常はエラーが発生した時点で電子マネーカード7がオンライン端末5にセットされているので、このまま引き続き残高確認処理に移行する、オンライン端末5に設けられた残高確認ボタンを押すなどしてセンタサーバ2に残高確認を要求するステップ605。センタサーバ2は、オンライン端末5より残高確認要求を受けて、残高状態確認要求を電子マネーカード7に対して行いステップ704、これに対し、電子マネーカード7は、残高状態確認応答を行うステップ506。次に、センタサーバ2は、残高状態確認応答により電子マネーカード7から送信されてきた取引状態と、前回の取引情報86の取引状態の組合せを確認する。その結果、取引状態の組合せが取引完了、取引中となり、また、前回の処理が入金処理であったため図示しないが取引情報86に記録されている、センタサーバ2は前回の処理が障害7により中断したと判断する。すると、センタサーバ2は、取引情報86の取引状態を取引回復に設定し、取引情報86を取引情報88に更新する。センタサーバ2は、取引状態が取引回復に設定されている取引情報は無効になったものとして扱うため、前々回の取引情報85が最新の取引情報として復活する。換言すればセンタサーバ2は前回の取引情報86を前々回の取引情報85に更新することにより障害回復を行うステップ722。センタサーバ2は、取引情報を更新した後、障害回復を行った旨を表す障害回復通知をオンライン端末5に送信するステップ724。オンライン端末5はこれを受信して障害が回復したことを確認するステップ610。そして、加盟店102の担当者は残高確認を行った後、入金処理を再度最初から行う。図18は、障害8が発生した場合の回復処理手順を説明するためのフローチャートである。ステップ504~ステップ506までは障害7と同様である。そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報86の取引状態の組合せを確認し、取引状態の組合せが取引中、取引中であり、また前回の取引が入金処理であったことから、前回の処理が障害8により中断したと判断する。障害8が発生した場合、電子マネーカード7とセンタサーバ2の何れも加算処理が完了していないので、カード情報と取引情報を入金処理前の状態に戻すことにより障害回復を行う。そのため、センタサーバ2は、電子マネーカード7に対して取引完了設定要求を行うステップ726。この要求は、電子マネーカード7に取引完了コマンドを送信することにより行われる。これに対し、電子マネーカード7は、取引状態を取引完了に設定し、センタサーバ2に取引完了設定通知を送信するステップ512。これにより、カード情報はカード情報77からカード情報76に戻される。センタサーバ2は、電子マネーカード7から取引完了通知を受信すると、取引情報86の取引状態を取引回復に設定して取引情報88に更新するステップ728。これにより、取引情報88は無効な取引情報となり、前々回の取引情報85が最新の取引情報として復活する。次に、センタサーバ2は、オンライン端末5に処理回復通知を送信しステップ730、オンライン端末5はこれにより障害が回復したことを確認するステップ612。その後、加盟店102の担当者は入金処理を最初からやり直す。図19は、障害9、及び障害10が発生した場合の処理手順を説明するためのフローチャートである。ステップ504~ステップ710は図14のフローチャートと同様である。センタサーバ2は、取引情報を取引情報87に更新した後ステップ714、電子マネーカード7に宛てて取引完了コマンドと加算コマンドを送信するステップ714。その後、障害9又は障害10が発生した場合、センタサーバ2はこれらの何れかの障害が発生したことを検出しステップ732、オンライン端末5に対して取引失敗通知を行うステップ734。そして、オンライン端末5は、取引処理失敗を表す効果音と共に表示装置にエラー発生画面を表示するステップ614。カード情報は障害9が発生した場合はカード情報77となり、障害10が発生した場合はカード情報78となる。また、取引情報は何れの場合も取引情報87である。その結果、取引状態の組合せは、障害9の場合は取引中、取引完了となり、障害10の場合は取引完了、取引完了となる。図20は、障害9が発生した場合の回復処理手順を説明するためのフローチャートである。ステップ504~ステップ506までは障害6の場合と同様である。そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報87の取引状態の組合せを確認し、取引状態の組合せが取引中、取引完了であり、また前回の取引が入金処理であったことから、前回の処理が障害9により中断したと判断する。障害9の場合、センタサーバ2では加算処理が完了し、電子マネーカード7ではまだ加算処理が行われていない状態であるため、電子マネーカード7に加算処理を行わせることにより回復処理を行う。まず、センタサーバ2は、電子マネーカード7に対して取引完了設定加算要求を再度行うステップ736。電子マネーカード7は、これに応じて加算処理を行うと共に取引状態を取引完了に設定し、センタサーバ2に加算完了通知を送信するステップ514。これにより、カード情報77はカード情報78に更新される。センタサーバ2は、加算完了通知を受信した後、障害回復通知をオンライン端末5に送信しステップ738、オンライン端末5は、これを受信して障害9が回復したことを確認するステップ616。次に、障害10の回復処理について説明する。障害10では、電子マネーカード7とセンタサーバ2の何れでも加算処理が完了しており、また取引状態も共に取引完了に設定されているため状態回復処理を行う必要はない。そのため、障害10の場合は障害回復を行うことなくそのまま残高確認が行われる。以上に説明したように、電子マネーシステム1では、支払い処理を行う場合は、電子マネーカード7で減算処理を行った後図6ステップ108、センタサーバ2で減算処理を行い図6ステップ310、また、入金処理を行う場合は、センタサーバ2で加算処理を行った後図14ステップ710、電子マネーカード7で加算を行っている図14ステップ510。そのため、障害により電子マネーカード7とセンタサーバ2でバリュー残高の食い違いが生じた場合障害3、障害9、何れも電子マネーカード7に対して加算処理を行うことにより回復処理を行うことができる。このように、障害回復を行う場合は、電子マネーカード7への処理は減算処理となることはないので顧客は安心して電子マネーカード7を使用することができる。また、以上の例では、残高確認を行う際に併せて障害回復を行うこととしたが、顧客と加盟店102の担当者の何れもが障害が発生したことに気づかず、障害回復を行わない場合もあり得る。センタサーバ2は、支払い処理、入金処理の際に、これらの処理に先立って前回の処理で障害が発生したか否かを確認するため、例え、前回の取引で障害回復を行わなかったとしても、今回の取引で障害回復を行ってから処理を行うことができる。次に、障害回復を行っていない電子マネーカード7以下、未回復カードと呼ぶをオフライン端末6で使用する場合について説明する。未回復カードを用いてオフライン端末6で支払いを行う場合は、特に制限することなく使用できる。何れの障害が発生しても未回復カードに記憶されているバリューの残高は、顧客が本来有しているバリュー残高以下であるので、これから減算しても不都合は生じないからである。また、センタサーバ2は、取引情報で障害回復するため、未回復カードをオフライン端末6で使用して支払いを行った後、この未払いカードをオンライン端末5にセットして障害回復を行うこともできる。一方、未回復カードに入金を行う場合には不都合が生じる場合がある。即ち、電子マネーカード7が記憶できるバリュー残高には上限値が設けられているため、未回復カードに入金を行うとバリュー残高がこの上限値を超える場合が生じる可能性がある。例えば、バリューの上限値が5万円であるとする。そして、現在未回復カードに記憶されているバリューが4万円であるが、障害を回復すると5千円加算されるとする。顧客が未回復カードに1万円を入金してバリュー残高5万円とした後、障害を回復するとバリュー残高が5万5千円となり上限値を越えてしまう。そのため、オフライン端末6は、電子マネーカード7に入金を行う前に、電子マネーカード7が未回復カードか否かを確認し、未回復カードである場合は、入金を制限するようになっている。図21は、オフライン端末6で電子マネーカード7に入金を行う手順を説明するためのフローチャートである。なお、以下のようにオフライン端末6は、演算命令入力装置を構成している。電子マネーカード7は、オフライン端末6のリーダライタにセットされているものとする。まず、加盟店102の担当者は、オフライン端末6に入金額を入力するステップ904。これは、加算金額取得手段に対応する。すると、オフライン端末6は、電子マネーカード7に対して残高状態確認要求を行いステップ906、これに対し、電子マネーカード7は、オフライン端末6に対して残高状態確認応答を行うステップ804。このように、センタサーバ2は、電子マネーカード7から取引状態を受信し、これは端末フラグ受信手段に対応する。オフライン端末6は、電子マネーカード7から受信した取引状態が取引完了と取引中の何れであるかを判断するステップ908。取引状態が取引完了であった場合ステップ908;Y、オフライン端末6は、加算コマンドを生成して電子マネーカード7に入力し、入金処理を行うステップ806。一方、取引状態が取引中であった場合ステップ908;N、オフライン端末6は、入金処理をせずにアラームを発するステップ1000。このような、オフライン端末6は、加算命令生成手段と、取引状態が取引中であった場合、電子マネーカード7への入力を制限する加算命令入力手段を備えている。このように、オフライン端末6は、電子マネーカード7の取引状態を確認することにより、電子マネーカード7が未回復カードか否かを判断することができ、また、未回復カードであった場合は、入金処理を制限する本実施の形態では入金処理を全く行わない。なお、本実施の形態では、未回復カードに関しては、入金額を制限するように構成することも可能である。即ち、障害により電子マネーカード7に記憶されているバリュー残高が、実際にユーザが保有しているバリュー残高より少なくなる場合は、障害3、及び障害9が発生した場合である。この場合に、障害回復により加算される可能性のある金額を見越して、オフライン端末6で入金できる金額の上限を動的に制限することができる。即ち、電子マネーカード7のカード情報から、回復処理にて加算処理が行われた場合、その加算額は取引額に記憶されている金額である。障害の種類によりこの金額がバリュー残高に加算されるかもしれないし、又は加算されないかもしれないが、オフライン端末6は、少なくとも加算されるこの金額分だけ残高が加算される可能性があることがわかる。そこで、オフライン端末6は、上限値からこの金額を減じた金額をこの電子マネーカード7の上限値として設定すればよい。以上、本実施の形態の一例について説明したが、各種の変形例が可能である。障害が発生した場合、それが電子マネーカード7で演算が行われた後に発生したのか、あるいは前に障害が発生したのかが最低限わかれば障害回復を行うことができる。そこでここではそのための条件について考える。図23aに示したように本実施の形態では、ステップ1~ステップ4の通信のタイミングがある。即ち、センタサーバ2は、ステップ1で取引中コマンドを送信し、ステップ2で取引中設定通知を受信し、更にステップ3で取引完了コマンドを送信し、ステップ4で取引完了通知を受信する。電子マネーカード7に演算命令を送信するタイミングは、ステップ1とステップ3があり、図23aは、ステップ1で演算コマンドを送信する場合を示している。ステップ2、3で障害が発生した場合は、電子マネーカード7の取引状態は取引中になっている。即ち、電子マネーカード7の取引状態が取引中であることさえわかれば、電子マネーカード7で演算処理後に障害が発生したことがわかる。そのため、ステップ2とステップ3を必ずしも識別する必要はない。一方、電子マネーカード7の取引状態が取引完了であった場合、演算処理前に障害が発生したのかステップ1、あるいは演算処理後に障害が発生したのかステップ4識別することができない。そのため、ステップ1~ステップ4の間でセンタサーバ2の取引状態を奇数回反転させると、ステップ1での障害とステップ4での障害を区別することができる。ここで、取引状態を反転させるとは、取引状態を取引完了→取引中、又は取引中→取引完了に設定することを意味する。このように、構成すると、電子マネーカード7とセンタサーバ2の取引状態の組合せだけから電子マネーカード7で演算処理が行われたか否かを判断することができる。そして、更に、センタサーバ2で取引状態を反転させる際に、センタサーバ2で記憶しているバリュー残高を更新することにより、センタサーバ2で記憶しているバリュー残高が更新前のものかあるいは後のものかを取引状態から判断することができる。図23bは、ステップ3で演算コマンドを送信する場合を示している。この場合は、電子マネーカード7の取引情報が取引中である場合は、演算処理前に障害が発生したことがわかる。一方取引情報が取引完了であった場合、これだけでは演算処理前に障害が発生したのかステップ1、あるいは演算処理後に障害が発生したのかステップ4を識別することができない。そのため、ステップ1~ステップ4の間でセンタサーバ2側の取引状態を反転させれば、何れで障害が発生したのか特定することができる。また、その反転の際にセンタサーバ2側で記憶しているバリュー残高の更新も行う。以上をまとめると、電子マネーカード7の取引状態を取引中か取引完了に設定させる際に演算コマンドも一緒に送信し、電子マネーカード7に取引中コマンドを送信してからステップ1、取引完了通知を受信するまでステップ4にセンタサーバ2の取引状態を反転させ、更に、反転の際にセンタサーバ2側で記憶しているバリュー残高を更新すればよいことになる。即ち、センタサーバ2は、電子マネーカード7の取引状態を反転させる取引中コマンドを送信し、電子マネーカード7がこれを実行して取引状態が取引中に反転されたことを確認した後、取引完了コマンドを電子マネーカード7に送信して電子マネーカード7の取引状態を取引完了に復帰させ、前記取引中コマンド又は取引完了コマンドを送信する際に、演算コマンドも送信し、電子マネーカード7に取引中コマンドを送信してから、電子マネーカード7の取引状態が取引完了に復帰したことを確認するまでの間に、センタサーバ2の取引状態を反転又は復帰させ、その際にセンタサーバ2残高更新を確定すればよい。以上の範囲内で、電子マネーシステム1は、各種変形可能である。以上に説明した電子マネーシステム1により、次のような効果を得ることができる。1電子マネーカード7とセンタサーバ2の取引状態の組合せから、発生した障害を特定することができる。2取引状態の組合せから障害の種類を特定するため、オンライン端末5とオフライン端末6が混在した電子マネーシステム1バリュー残高が電子マネーカード7とセンタサーバ2で必ずしも一致しないで障害の種類を特定することができる。3支払い処理の場合は、電子マネーカード7で減算した後、センタサーバ2の取引情報を更新し、入金処理の場合は、センタサーバ2で取引情報を更新した後電子マネーカード7で加算処理するため、何れの場合も電子マネーカード7へは加算処理にて回復処理を行うことができる。4電子マネーカード7での処理が終了していない場合は、取引状態が取引中に設定されるため、オフライン端末6にて未回復カードを識別することができる。5オフライン端末6は、未回復カードへの入金機能が制限されているため、バリュー残高限度を超えて電子マネーカード7に入金されることを防ぐことができる。以上、本実施の形態の一例について説明したが、各種の変形が可能である。例えば、オンライン端末5を、インターネット接続可能なパーソナルコンピュータにより構成し、顧客の自宅に設置しても良い。この場合、顧客は自宅の通信で電子マネーカード7の処理に障害が発生したことに気づかずに加盟店102に行ったとしても、オンライン端末5にて障害を回復することができる。また、本実施の形態では、センタサーバ2が加算コマンド、減算コマンドを電子マネーカード7に送信し、電子マネーカード7はこれらコマンドを実行して記憶している残高を更新したが、残高の演算はセンタサーバ2で行うように構成することもできる。この場合、センタサーバ2は、電子マネーカード7が記憶している残高を電子マネーカード7から取得し、これに加減算処理を行って加減算処理後の金額を算出する。そして、センタサーバ2は、算出した金額を電子マネーカード7に送信し、電子マネーカード7は、記憶している残高をセンタサーバ2から受信した金額に更新する。このように、加減算処理は、センタサーバ2で行っても電子マネーカード7で行ってもよく、あるいは、加算に関してはセンタサーバ2で行い、減算に関しては電子マネーカード7で行うというように、加減算の一方をセンタサーバ2で行い、他方を電子マネーカード7で行うように構成することもできる。センタサーバ2が加算コマンド、減算コマンドを電子マネーカード7に送信し、電子マネーカード7で加減算を行う場合、加算コマンド、減算コマンドは金額変更情報を構成している。センタサーバ2が加減算後の金額を計算し、電子マネーカード7がこれを用いて金額を更新する場合、センタサーバ2が電子マネーカード7に送信する加減算後の金額が金額変更情報に該当する。このように、センタサーバ2が送信した金額変更情報によって電子マネーカード7の残高が増減されるとした場合、バリュー処理部7aは、金額変更情報を用いて残高金額を金額変更処理する金額変更手段を構成している。また、センタサーバ2は、演算コマンドや演算後の金額などの金額変更情報を送信する金額変更情報送信手段を備えている。更に、オフライン端末6は、金額変更情報入力装置を構成している。即ち、オフライン端末6は、ステップ904にて入金額を取得するが、これは増額金額を取得する増額金額取得手段を構成している。また、オフライン端末6は、ステップ806にて入金処理を行うが、これは入力された増額金額分の貨幣価値を増額する金額変更情報を生成する金額変更情報生成手段を構成している。更に、オフライン端末6は、電子マネーカード7の取引状態が取引完了であった場合は生成した金額変更情報を電子マネーカード7に入力し、取引中であった場合は金額変更情報の入力を制限する金額変更情報入力手段を備えている。