JP5258124B2 - オフライン端末、オフライン端末の制御方法、及びオフライン端末の制御プログラム - Google Patents

Description

本発明は、オフライン端末、オフライン端末の制御方法、及びオフライン端末の制御プログラムに関し、例えば、ＩＣカードに記憶した電子マネーを処理するものに関する。

近年、一般の小売店や消費者の協力を得て行われた電子マネー（電子現金）の大規模な実用化実験が成功裡に終わり、我が国は電子マネー時代の到来を迎えつつある。
現在実用化されている電子マネーシステムは、例えば、非接触型ＩＣカードで構成された電子マネーカードに貨幣価値の金額を記憶させるものである。
電子マネーカードは、ＣＰＵ（中央処理装置：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備えており、これに加算コマンドや減算コマンド（以下、演算コマンド）を入力して実行させることにより、カード内の貨幣価値の金額を増減することができる。カード内の貨幣価値はバリューと呼ばれる電子情報で表される。

電子マネーを用いて商品・サービスなどの提供を行う事業者は、電子マネーシステムの主催者（以下、電子マネーセンタ）に登録して加盟店を形成し、電子マネーカードにアクセスするための取引端末を備えている。加盟店は、現金の授受の代わりに、この取引端末を用いて顧客の電子マネーカード内のバリュー残高を増減させて商取引を行う。

取引端末には、電子マネーセンタのサーバ装置（センタサーバ）とオンライン接続されたオンライン端末と、バッチ処理にて一日数回程度センタサーバと接続するオフライン端末がある。
例えば、オンライン端末は、ブロードバンドなどの高速通信が行えるネットワーク環境において利用され、オフライン端末は、高速通信が行えない場合に利用される。

電子マネーシステムが実用化した当初は取引端末としてオフライン端末が採用されていたが、今日はネットワークのブロードバンド化が進展し、次第にオンライン端末に置き換えられるようになってきている。しかし、未だオンライン端末を設置するのが困難な場所があり、現在の電子マネーシステムはオフライン端末とオンライン端末が混在した形となっている。

オンライン端末は、電子マネーカードとセンタサーバとの通信の仲介を行い、これによって、センタサーバは、電子マネーカードに所定の演算命令を送信する。電子マネーカードは、この演算命令を実行して電子マネーカード内のバリューの金額を増減する。

これに対し、オフライン端末は、オフラインで電子マネーカードに演算コマンドを入力してカード内のバリューの金額を増減させ、その取引情報をログデータとして蓄積する。そして、一日数回程度バッチ処理にてこれらをまとめてセンタサーバに送信する。

電子マネーセンタは、オンライン端末との取引情報と、オフライン端末から受信した取引情報を集計し、その集計結果に応じて加盟店の銀行口座に対して現金の移動を行う。
このように、電子マネーセンタは取引情報を用いてバリューによる交換価値の移動と実際の現金との対応関係をとっている。
このように電子マネーを用いた技術に以下のものがある。

特開２００３−１４１４２８号公報

この技術は、ユーザが携行する非接触型ＩＣカードに貨幣的な価値を記憶させてこれを加減算することにより電子マネーを流通させるものである。

オフライン端末の場合、オフライン端末と電子マネーカードとの間での通信で処理が完結するため、通信時間が短時間（例えば０．１秒程度）で済み、更に通信経路も短いため、電子マネーカードの処理中に障害が生じる可能性についてはほとんど考慮する必要がなかった。
しかし、オンライン端末を用いると、電子マネーカードとセンタサーバが通信を行うために通信時間が延び（例えば、１秒程度）、通信経路も複雑で長距離のものとなるため、電子マネーカードの処理中に障害が生じる可能性を考慮する必要が生じてくる。

そして、障害が発生してこれを回復する場合、オンライン端末とオフライン端末が混在しているために、電子マネーカードでのバリュー残高とセンタサーバで記録しているバリュー残高の一致がとれない場合があり（電子マネーカードでの情報は常に最新情報となるが、センタサーバでの情報は、全てのオフライン端末から情報を受信するまで最新状態に更新されない）バリュー残高を用いて回復処理を行うことはできない。

更に、ユーザの利便性の観点から、障害の発生によりセンタサーバと電子マネーカードのバリュー残高に不一致が生じてこれを回復する場合、ユーザの電子マネーカードに対するバリュー残高の修正が少なくとも減算処理とならない（即ち、電子マネーカードのバリュー残高は変わらないかあるいは加算される）ような回復システムを構築する必要がある。

そこで、本発明の目的は、オンライン端末とオフライン端末が混在した情報処理システムにおいて、オンラインでの決済処理に障害が発生した場合、その回復処理が完了していない貨幣端末との間で、一定の制限のもとオフラインでの決済処理を可能とすることである。

本発明は、前記目的を達成するために、請求項１に記載の発明では、貨幣端末と情報処理サーバとの間で行われるオンライン取引をリアルタイムで仲介するオンライン端末と、貨幣端末との間で行われたオフライン取引に係る情報をバッチ処理にて情報処理サーバに送信するオフライン端末と、を含む情報処理システムにおけるオフライン端末であって、支払又は入金に係る取引金額を取得する取引金額取得手段と、前記取得される取引金額分の金額変更情報を生成する金額変更情報生成手段と、前記生成される金額変更情報を前記貨幣端末に出力する金額変更情報出力手段と、貨幣価値の残高金額を電子データとして記憶する残高記憶手段と、所定の金額変更情報を用いて前記残高金額に対する変更処理を実行する金額変更手段と、少なくとも前記金額変更手段による直近のオンライン取引に係る変更処理について該変更処理が完了しているか否かを示す状態データを記憶する状態データ記憶手段と、前記変更処理が完了していないオンライン取引に係る取引金額を示す未完了取引金額を少なくとも含む過去の取引に係る取引金額を記憶する取引金額記憶手段と、を備える前記貨幣端末から、前記状態データ記憶手段に記憶される状態データを取得する状態データ取得手段と、前記取得される取引金額が入金に係る取引金額でありかつ前記取得される状態データが未完了を示す場合に限り、該入金に係るオフライン取引を制限するか否かを、前記取引金額記憶手段に記憶される前記未完了取引金額分の回復処理が前記情報処理サーバにより後に実施されることを見越し、前記取得される入金に係る取引金額に応じて決定する決定手段と、前記決定手段により前記入金に係るオフライン取引を制限することが決定された場合に、該オフライン取引を途中で停止させる取引制限手段と、
を具備したことを特徴とするオフライン端末を提供する。
請求項２に記載の発明では、前記決定手段が、前記入金に係るオフライン取引を制限するか否かを、前記残高記憶手段に記憶される残高金額に前記未完了取引金額を加算した後の金額に対し前記取得される入金に係る取引金額分の変更処理が可能であるか否かを基準として決定する、ことを特徴とする請求項１記載のオフライン端末を提供する。
請求項３に記載の発明では、前記残高記憶手段に記憶される残高金額には、上限値が設けられており、前記決定手段が、前記残高記憶手段に記憶される残高金額に前記未完了取引金額分の加算処理を実施した後の金額に対し前記取得される入金に係る取引金額を加算した金額が前記上限値を上回るとき、前記入金に係るオフライン取引を制限する旨を決定する、ことを特徴とする請求項２記載のオフライン端末を提供する。
請求項４に記載の発明では、前記貨幣端末から前記残高記憶手段に記憶される残高金額を取得する残高金額取得手段と、前記取得される状態データが未完了を示す場合に限り、前記貨幣端末から前記取引金額記憶手段に記憶される前記未完了取引金額を取得する未完了取引金額取得手段と、をさらに備える、ことを特徴とする請求項１から請求項３までのいずれか１項に記載のオフライン端末を提供する。
請求項５に記載の発明では、前記オンライン取引及び前記オフライン取引に係る取引金額を直近の取引に係るものから所定数だけ記憶する前記取引金額記憶手段に、入金又は支払に係るオフライン取引に係る取引金額を新たに記憶させる手段をさらに具備する、ことを特徴とする請求項１から請求項４までのいずれか１項に記載のオフライン端末を提供する。
請求項６に記載の発明では、貨幣端末と情報処理サーバとの間で行われるオンライン取引をリアルタイムで仲介するオンライン端末と、貨幣端末との間で行われたオフライン取引に係る情報をバッチ処理にて情報処理サーバに送信するオフライン端末と、を含む情報処理システムにおけるオフライン端末であって、支払又は入金に係る取引金額を取得する取引金額取得手段と、前記取得される取引金額分の金額変更情報を生成する金額変更情報生成手段と、前記生成される金額変更情報を前記貨幣端末に出力する金額変更情報出力手段と、を具備するオフライン端末を構成するコンピュータに、貨幣価値の残高金額を電子データとして記憶する残高記憶手段と、所定の金額変更情報を用いて前記残高金額に対する変更処理を実行する金額変更手段と、少なくとも前記金額変更手段による過去のオンライン取引に係る変更処理について該変更処理が完了しているか否かを示す状態データを記憶する状態データ記憶手段と、前記変更処理が完了していないオンライン取引に係る取引金額を示す未完了取引金額を少なくとも含む過去の取引に係る取引金額を記憶する取引金額記憶手段と、を備える前記貨幣端末から、前記状態データ記憶手段に記憶される状態データを取得する状態データ取得処理と、前記取得される取引金額が入金に係る取引金額でありかつ前記取得される状態データが未完了を示す場合に限り、該入金に係るオフライン取引を制限するか否かを、前記取引金額記憶手段に記憶される前記未完了取引金額分の回復処理が前記情報処理サーバにより後に実施されることを見越し、前記取得される入金に係る取引金額に応じて決定する決定処理と、前記決定処理において前記入金に係るオフライン取引を制限することが決定された場合に、該オフライン取引を途中で停止させる取引制限処理と、を実行させる、オフライン端末の制御方法を提供する。
請求項７に記載の発明では、貨幣端末と情報処理サーバとの間で行われるオンライン取引をリアルタイムで仲介するオンライン端末と、貨幣端末との間で行われたオフライン取引に係る情報をバッチ処理にて情報処理サーバに送信するオフライン端末と、を含む情報処理システムにおけるオフライン端末であって、支払又は入金に係る取引金額を取得する取引金額取得手段と、前記取得される取引金額分の金額変更情報を生成する金額変更情報生成手段と、前記生成される金額変更情報を前記貨幣端末に出力する金額変更情報出力手段と、を具備するオフライン端末を構成するコンピュータに、貨幣価値の残高金額を電子データとして記憶する残高記憶手段と、所定の金額変更情報を用いて前記残高金額に対する変更処理を実行する金額変更手段と、少なくとも前記金額変更手段による過去のオンライン取引に係る変更処理について該変更処理が完了しているか否かを示す状態データを記憶する状態データ記憶手段と、前記変更処理が完了していないオンライン取引に係る取引金額を示す未完了取引金額を少なくとも含む過去の取引に係る取引金額を記憶する取引金額記憶手段と、を備える前記貨幣端末から、前記状態データ記憶手段に記憶される状態データを取得する状態データ取得機能と、前記取得される取引金額が入金に係る取引金額でありかつ前記取得される状態データが未完了を示す場合に限り、該入金に係るオフライン取引を制限するか否かを、前記取引金額記憶手段に記憶される前記未完了取引金額分の回復処理が前記情報処理サーバにより後に実施されることを見越し、前記取得される入金に係る取引金額に応じて決定する決定機能と、前記決定機能により前記入金に係るオフライン取引を制限することが決定された場合に、該オフライン取引を途中で停止させる取引制限機能と、を実現させる、オフライン端末の制御プログラムを提供する。

本発明によると、オンライン端末とオフライン端末が混在した情報処理システムにおいて、オンラインでの決済処理に障害が発生した場合、その回復処理が完了していない貨幣端末とオフライン端末との間で、後にオンラインで行われる障害回復処理において矛盾が生じない範囲内でオフラインでの決済処理が可能となる。

フラグの設定手順の概要を説明するための図である。 電子マネーシステムの構成を示したブロック図である。 電子マネーカードのハードウェア的な構成を表したブロック図である。 センタサーバのハードウェア的な構成を示したブロック図である。 取引情報の一例を示した図である。 支払い処理の手順を説明するためのフローチャートである。 障害１が発生した場合の処理手順を説明するためのフローチャートである。 障害２、及び障害３が発生した場合の処理手順を説明するためのフローチャートである。 障害２が発生した場合の回復処理手順を説明するためのフローチャートである。 障害３が発生した場合の回復処理手順を説明するためのフローチャートである。 障害４、及び障害５が発生した場合の処理手順を説明するためのフローチャートである。 障害４が発生した場合の回復処理手順を説明するためのフローチャートである。 障害５が発生した場合の回復処理手順を説明するためのフローチャートである。 入金処理の手順を説明するためのフローチャートである。 障害６が発生した場合の処理手順を説明するためのフローチャートである。 障害７、及び障害８が発生した場合の処理手順を説明するためのフローチャートである。 障害７が発生した場合の回復処理手順を説明するためのフローチャートである。 障害８が発生した場合の回復処理手順を説明するためのフローチャートである。 障害９、及び障害１０が発生した場合の処理手順を説明するためのフローチャートである。 障害９が発生した場合の回復処理手順を説明するためのフローチャートである。 オフライン端末で電子マネーカードに入金を行う手順を説明するためのフローチャートである。 オンライン端末に表示される画面を説明するための図である。 障害回復を行うために必要な条件を説明するための図である。

（実施の形態の概要）
電子マネーカードとセンタサーバの双方に、「取引中」及び「取引完了」の２つの値を選択的に設定できるフラグを用意する。
そして、電子マネーカードとセンタサーバ間で情報処理を行う過程で、双方のフラグを立てたり（「取引完了」から「取引中」に反転させたり）、あるいは倒したり（「取引中」から「取引完了」に復帰させたり）して同期をとりながら処理を進める。
処理の途中で障害が発生した場合、障害が発生した時点でのフラグの状態が両者で保存されているため、これらの状態から障害が発生した時点を特定することができる。
そして、その特定した時点に応じた回復処理を行う。

また、電子マネーカードで演算処理を行うタイミングとセンタサーバ側で残高記録を更新するタイミングの時間的順序を減算処理と加算処理の場合で逆にすることにより、電子マネーカードに対する復帰処理が少なくとも加算処理となるように構成することができる。

即ち、電子マネーカードで減算処理を行う場合は、まず、電子マネーカードで減算処理を行った後、センタサーバでの残高記録の減算処理を行い、電子マネーカードで加算処理を行う場合は、逆にまずセンタサーバ側で加算処理を行った後に、電子マネーカードで残高記録の加算処理を行う。
このように構成すると、電子マネーカードで減算処理した後、センタサーバで残高記録の減算処理を行う前に障害が生じた場合は、電子マネーカードに減算した金額分を加算して残高を減算処理前の状態に回復し、また、センタサーバで残高記録の加算処理を行って電子マネーカードで加算処理を行う前に障害が生じた場合は、電子マネーカードに加算処理を行わせて両者の整合性をとることができる。

図１（ａ）を用いて、一例に係るフラグの設定手順の概要を説明する。
まず、センタサーバでは、センタ側フラグが取引完了（初期状態）に設定されており、これを取引中（反転状態）に設定した後、電子マネーカードに取引中コマンド（反転命令）を送信する（ステップ１）。
電子マネーカードは、この取引中コマンドを受信して実行し、端末フラグ（カード側のフラグ）を取引中に設定する。そして、センタサーバに対して取引中設定通知を送信する（ステップ２）。

センタサーバは、取引中設定通知を受信した後、サーバフラグを取引中から取引完了に設定する。そして、その後電子マネーカードに取引完了コマンド（復帰命令）を送信する（ステップ３）。
電子マネーカードは、センタサーバから取引完了コマンドを受信して実行し、端末フラグを取引完了に設定する。そして、その後取引完了設定通知をセンタサーバに送信する（ステップ４）。センタサーバはこれを受信する。

以上のように設定したフラグを用いると、ステップ１〜ステップ４の何れかで障害が発生した場合、どのステップで障害が発生したかをフラグの組合せから特定することができる。
例えば、端末フラグが「取引中」でサーバフラグも「取引中」の場合はステップ２で障害が発生したことになる。
また、端末フラグが「取引中」でサーバフラグが「取引完了」である場合はステップ３で障害が発生したことになる。

以下同様に、ステップ１で障害が生じた場合は、端末フラグが「取引完了」でサーバフラグが「取引中」となり、ステップ４で障害が生じた場合は、端末フラグとサーバフラグが共に「取引完了」になる。
即ち、フラグの組合せは合計４通りあり、これを各ステップに対応させたのである。

そして、センタサーバが、フラグの設定コマンド（取引中コマンド、又は取引完了コマンド）と演算コマンドを共に電子マネーカードに送信し、電子マネーカードがフラグの設定と演算の実行を共に行うように構成すると、電子マネーカード側の情報とセンタサーバ側の情報を同期しながら更新することができる。

例えば、電子マネーカードで減算処理を行う場合、図１（ｂ）に示したように、ステップ１において取引中コマンドと減算コマンドを送信する。電子マネーカードはこの減算コマンドを受信して実行した後、ステップ２において減算完了通知（取引中設定通知を兼ねている）をセンタサーバに送信する。
センタサーバは、電子マネーカードから減算完了通知を受信したのち、当該電子マネーカードの残高記録を減算する。その後、ステップ３、４の処理が行われる。

以上の手順で電子マネーカードのバリュー残高と、センタサーバでの残高記録に不一致が生じるのは、ステップ２で通信障害が生じた場合である。即ち、端末フラグと、サーバフラグが共に「取引中」である場合、電子マネーカードでは、減算処理が行われたがセンタサーバ側では残高記録の減算処理が行われなかったことがわかる。
従って、減算処理中に障害が発生し、端末フラグとサーバフラグが共に「取引中」である場合、電子マネーカードに減算した金額を加算する加算コマンドを送信して実行させると、減算処理前の状態に回復することができる。

同様に、電子マネーカードで加算処理を行う場合、図１（ｃ）に示したように、ステップ１、２の処理を行った後、ステップ３において、取引完了コマンドと加算コマンドを送信する。電子マネーカードはこの加算コマンドを受信して実行した後、ステップ４において加算完了通知（取引完了設定通知を兼ねている）をセンタサーバに送信する。

以上の手順で電子マネーカードの残高と、センタサーバでの残高記録に不一致が生じるのは、ステップ３で通信障害が生じた場合である。即ち、端末フラグが「取引中」で、サーバフラグが「取引完了」である場合、センタサーバ側では残高記録の加算処理が行われたが、電子マネーカードでは加算処理が行われなかったことがわかる。
従って、加算処理中に障害が発生し、端末フラグが「取引中」でサーバフラグが「取引完了」である場合、電子マネーカードに加算コマンドを送信して実行させると、加算処理後の状態に回復することができる。

（実施の形態の詳細）
電子マネーによる商取引では、金銭と同等の交換価値を付与したバリューと呼ばれる電子情報の値を加減することにより交換価値の移動を生じさせる。
バリューは、バリュー処理機能を有するＩＣカードである電子マネーカードに記憶されて利用者に携帯される。
バリューを用いた商品・サービスの購入は、バリューによる商取引を行う契約を結んでいる加盟店で行うことができる。

加盟店は、店頭に電子マネーカードにアクセスする加盟店端末を設置しており、利用者の電子マネーカードに記憶されているバリューを代金分だけ減算して支払いを行う（決済とも呼ばれる）。
また、加盟店に金銭を支払い、その金額分のバリューを電子マネーカードに書き込んでもらうこともできる。このように電子マネーカードにバリューを書き込む処理は入金（又はチャージ）と呼ばれている。
この加盟店端末には、電子マネーカードセンタのセンタサーバとオンライン接続されているオンライン端末と、バッチ処理にてログデータを一括してセンタサーバに送信するオフライン端末がある。

図２は、本実施の形態の電子マネーシステムの構成を模式的に示したブロック図である。
電子マネーシステム１は、電子マネーセンタ１００に設置されたセンタサーバ２、各加盟店１０２に設置されたオンライン端末５、５、５、…、オフライン端末６、センタサーバ２とオンライン端末５、５、５、…、及びオフライン端末６、６、６、…をネットワーク接続するネットワーク４、及びオンライン端末５、及びオフライン端末６と近距離の無線通信を行う電子マネーカード７を用いて構成されている。

電子マネーセンタ１００は、電子マネーシステム１の運営維持管理を行う事業体であり、センタサーバ２（貨幣端末処理サーバ）を運用している。
センタサーバ２は、オンライン端末５と常時接続されており、リアルタイムでオンライン端末５と通信でき、オンライン端末５からの要求に従って演算コマンド（演算命令）を生成して送信することができる。
なお、本実施の形態では、センタサーバ２とオンライン端末５、５、５、…を常時接続することとするが、これに限定するものではなく、例えば、必要に応じて（電子マネーカード７に各種コマンドを入力する必要がある時点など）オンライン端末５をセンタサーバ２に接続するように構成することもできる。

また、センタサーバ２は、例えば１日１回程度、オフライン端末６が電子マネーカード７に対して行った処理に関する取引情報をまとめて受信する。
更に、オフライン端末６にはネットワーク４に接続されないものもあり、これに関しては電子マネーセンタ１００の担当者が、オフライン端末６から取引情報が記憶された記憶媒体を回収し、これをセンタサーバ２に入力する。

加盟店１０２は、例えば、コンビニエンスストアやレストランなど、商品やサービスを顧客に提供する店舗であって、これら商品やサービスの対価としてバリューを使用することができるものである。
加盟店１０２は、例えばレジにオンライン端末５やオフライン端末６を備えており、これを用いて顧客の電子マネーカード７から対価分のバリューを減算して支払いを行う。また、顧客から代金を受領して、その金額分のバリューを電子マネーカード７に入金することもできる。
本実施の形態では、オンライン端末５にて支払い、入金の双方を行うことができるものとするが、支払いと入金の何れか一方を行うように構成することもできる。

オンライン端末５は、端末コンピュータ５ａとリーダライタ５ｂから構成されている。
端末コンピュータ５ａは、所定のコンピュータプログラムをリーダライタ５ｂを備えた汎用のコンピュータにインストールして構成することもできるし、あるいは、専用モジュールを組み込んだ専用機を用いて構成することも可能である。
リーダライタ５ｂは、端末コンピュータ５ａの周辺機器であり、電子マネーカード７と近距離の無線通信を行うためのアンテナを内蔵している。

端末コンピュータ５ａは、リーダライタ５ｂを介して電子マネーカード７に接続し、センタサーバ２から送信されてきた演算コマンドを電子マネーカード７に入力することができる。
これに対し、オフライン端末６は、自ら演算コマンドを生成し、電子マネーカード７に入力する。
図示しないが、オフライン端末６にはリーダライタ５ｂが内蔵されており、オフラインで電子マネーカード７に対して処理を行った後、その処理内容を記録した取引情報を１日１回程度ネットワーク４を介してセンタサーバ２に送信する。

電子マネーカード７は、バリュー処理機能が組み込まれた非接触型ＩＣカードで構成された貨幣端末である。
電子マネーカード７は、バリュー処理機能を行うＩＣチップと、リーダライタ５ｂと無線通信を行うためのアンテナを備えている。
電子マネーカード７は、バリュー残高金額を記憶しており、リーダライタ５ｂから入力された加算コマンドや減算コマンドを実行してバリューの金額を加減算する。

図２は電子マネーカード７の機能的な構成も示しており、図示したように電子マネーカード７は、バリュー処理部７ａ、残高記憶部７ｂ、ログデータ記憶部７ｃ、カードＩＤ記憶部７ｄ、取引状態保持部７ｅなどを備えている。
残高記憶部７ｂは、バリュー残高を記憶する記憶部である。支払いや入金の際は、残高記憶部７ｂに記憶されてるバリューの金額を増減する。残高記憶部７ｂは、貨幣価値の金額を電子データ（バリュー）として記憶する貨幣情報記憶手段を構成している。

ログデータ記憶部７ｃは、取引履歴をログデータとして記憶する記憶部である。取引履歴としては、例えば取引日時、取引を行った加盟店端末のＩＤ情報、支払い又は入金の別、取引額などがある。
取引履歴は、例えば６件まで記憶され、古いものから順次消去されるようになっている。

カードＩＤ記憶部７ｄは、カードＩＤを記憶した記憶部である。カードＩＤは、電子マネーシステム１において電子マネーカード７に一意に与えられたＩＤ情報であって、電子マネーセンタ１００は、カードＩＤにより電子マネーカード７を特定することができる。
なお、カードＩＤは、電子マネーセンタ１００が電子マネーカード７に付与したものであるが、このほかに、電子マネーカード７の製造メーカが電子マネーカード７に付与したＩＤ情報を用いてもよい。
何れのＩＤ情報も電子マネーカード７に記憶されており、カードＩＤコマンドを電子マネーカード７に入力することによりこれらＩＤ情報を読み出すことができる。

取引状態保持部７ｅは、取引状態を記憶する記憶部である。取引状態は、電子マネーカード７側での処理が終了したか否かを表すフラグ情報であり、端末フラグを構成している。
取引状態は、「取引中」（反転状態に対応）、「取引完了」（初期状態に対応）の２値を選択的にとることができる。ここで、取引状態保持部７ｅは、端末フラグ記憶手段を構成している。

取引状態は、電子マネーカード７での処理が完了するまでは「取引中」に設定され、処理が完了すると「取引完了」に復帰させられる。
これら「取引中」と「取引完了」の設定は、後述のバリュー処理部７ａが、センタサーバ２から送信されてきた取引中コマンド（反転命令に対応）と取引完了コマンド（復帰命令に対応）を実行することにより行われる。ここで、バリュー処理部７ａはフラグ命令実行手段に対応している。
取引状態保持部７ｅに記憶されている取引状態は、センタサーバ２と電子マネーカード７の間の通信障害の発生時点を判断するのに用いられる。

バリュー処理部７ａは、リーダライタ５ｂから入力される各種コマンドを実行する中央演算処理部であり、演算手段を構成している。
バリュー処理部７ａは、加算コマンド、又は減算コマンドの入力を受け付けた場合、これらコマンドにパラメータとして付属している金額分だけ残高記憶部７ｂのバリューを加算、又は減算する。
そして、バリュー処理部７ａは、情報処理を行った場合、ログデータ記憶部７ｃの取引履歴を更新する。

本実施の形態では、電子マネーカード７は、ネットワーク４、端末コンピュータ５ａ、及びリーダライタ５ｂから成る経路を経由してセンタサーバ２と電子マネーカード７が通信を行うが、この通信は暗号化されており、電子マネーカード７は、このための暗号化及び復号化を行う機能も備えている。

ネットワーク４は、例えばインターネットによって構成されており、センタサーバ２とオンライン端末５、及びオフライン端末６の間の通信を媒介する。
ネットワーク４は、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などで構成してもよく、また、通信衛星を用いた通信回線、電話回線網、光ケーブル網などを用いることもできる。

図３は、電子マネーカード７のハードウェア的な構成の一例を模式的に表したブロック図である。
電子マネーカード７は、アンテナ７０１とＩＣチップ７０２を内蔵したプラスチックカードである。
本実施の形態では、電子マネーカード７として非接触型ＩＣカードを用いるものとするが、接触型ＩＣカードによって構成することも可能である。この場合、電子マネーカード７は、アンテナ７０１の代わりにＩＣチップ７０２にアクセスするための接触端子を備える。加盟店端末もこの接触端子に接続する端子を備え、これら端子を介して電子マネーカード７と加盟店端末が通信を行う。

アンテナ７０１は、リーダライタ５ｂが備えたアンテナと無線通信を行うための素子である。
アンテナ７０１は、リーダライタ５ｂが放射した電波を受信すると共に、リーダライタ５ｂに対して電波を放射する。
また、アンテナ７０１は、リーダライタ５ｂから電力の供給を無線により受け、ＩＣチップ７０２を駆動するための電力を発電する発電機能も有している。

ＩＣチップ７０２は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）７０３、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）７０４、高周波回路部７０５、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）７０６、記憶部７０７などの各素子を備えた一種のコンピュータである。これらの素子は１つのＩＣチップの中に形成されている。

ＣＰＵ７０４は、各種のプログラムに従って情報処理を行ったり、電子マネーカード７全体の動作を制御する中央処理装置である。
ＲＯＭ７０３は、電子マネーカード７を機能させるための基本的なプログラム（ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、リーダライタ５ｂとの通信プログラムなど）や各種データが記憶された読み取り専用メモリである。

高周波回路部７０５は、アンテナ７０１を介してリーダライタ５ｂと通信を行うインターフェースである。ＣＰＵ７０４は、高周波回路部７０５を介してリーダライタ５ｂと無線通信を行うことができる。
ＲＡＭ７０６は、読み書き可能な揮発性のメモリであって、ＣＰＵ７０４が各種の情報処理を行う際のワーキングエリアを提供する。本実施の形態では、例えば、ＣＰＵ７０４が加算コマンドや減算コマンドを実行してバリューの金額を増減する際に使用する。

記憶部７０７は、例えばＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）で構成され、ＣＰＵ７０４によって情報の読み書きが可能な不揮発性のメモリである。
記憶部７０７には、各種のアプリケーションソフトを記憶させて（インストールして）これをＣＰＵ７０４に実行させ、各種の機能を電子マネーカード７に発揮させることが可能である。
本実施の形態では、ＣＰＵ７０４に電子マネーカード７としての機能を発揮させるためのプログラムであるバリュー処理プログラムを記憶させてある。

記憶部７０７には、バリュー処理プログラムが記憶されているほか、残高記憶部７ｂ、ログデータ記憶部７ｃ、カードＩＤ記憶部７ｄ、取引状態保持部７ｅなどが形成されている。
電子マネーカード７をリーダライタ５ｂに近接させて駆動すると、ＣＰＵ７０４がバリュー処理プログラムを実行し、バリュー処理部７ａがソフトウェア的に構成される。これにより、残高記憶部７ｂ、ログデータ記憶部７ｃ、カードＩＤ記憶部７ｄ、取引状態保持部７ｅにアクセスし、各種の情報処理を行うことができる。

なお、近年はＩＣチップ７０２を携帯電話などの携帯端末に内蔵させ、これら携帯端末に非接触型ＩＣカードとしての機能を持たせる試みも行われている。
この利用形態では、ＩＣチップ７０２とアンテナ７０１を携帯端末に備え、電子マネーカード７と同様にリーダライタ５ｂから無線によりアクセスすることができるほか、携帯端末が備えた表示装置にＩＣチップ７０２内の情報を表示させたり、あるいは携帯端末の入力装置を介してＩＣチップ７０２に情報を入力することも可能である。
以下、本実施の形態では、電子マネーカード７を用いて説明するが、これらＩＣチップ７０２を内蔵した携帯端末を用いることもできる。

図４は、センタサーバ２のハードウェア的な構成を模式的に表したブロック図である。
センタサーバ２は、制御部１０にバスライン３２を介して入力装置１８、出力装置２０、通信制御装置２４、記憶装置３０、などが接続して構成されている。

制御部１０は、ＣＰＵ１２、ＲＯＭ１４、ＲＡＭ１６などから構成されている。
ＣＰＵ１２は、ＲＯＭ１４、記憶装置３０、その他に記憶されているプログラムをロードして実行する中央処理装置である。本実施の形態では、記憶装置３０に記憶されている取引処理プログラムを実行し、センタサーバ２としての機能を発揮する。

ＲＯＭ１４は、例えば、ＣＰＵ１２が機能するための基本的な制御を行うための各種プログラム、データ及びパラメータを格納した読み出し専用の不揮発性メモリである。ＲＯＭ１４内のプログラムは、例えば、センタサーバ２の起動時に実行される。
ＲＡＭ１６は、ＣＰＵ１２にワーキングメモリとして使用される読み書き可能なメモリであり、例えば、取引処理プログラムを実行する際に使用される。

入力装置１８は、例えばキーボード、マウスなどの入力デバイスから構成されている。
出力装置２０は、例えばディスプレイなどで構成された表示装置、プリンタなどで構成された印刷装置などから構成されている。
電子マネーセンタ１００のオペレータは、これら入力装置１８や出力装置２０を用いてセンタサーバ２にアクセスし、保守作業やプログラムのアップデートその他の作業を行うことができる。

通信制御装置２４は、センタサーバ２をネットワーク４に接続するための装置であって、モデム、ターミナルアダプタその他の接続装置によって構成されている。
通信制御装置２４はＣＰＵ１２によって制御され、所定のプロトコルに従って加盟店端末とデータやその他の情報の送受信を行う。
加盟店端末がオンライン端末５の場合は常時接続されており、オフライン端末６の場合は、オフライン端末６がバッチ処理を行う際に接続を受け付ける。

記憶装置３０は、読み書き可能な記憶媒体と、その記憶媒体に対してプログラムやデータを読み書きするための駆動装置によって構成されている。当該記憶媒体として主にハードディスクが使用されるが、その他に、例えば、光磁気ディスク、磁気ディスク、半導体メモリなどのほかの読み書き可能な記憶媒体によって構成することも可能である。

記憶装置３０には、各種プログラムを記憶したプログラム格納部３４と各種のデータを記憶したデータ格納部３６が形成されている。
プログラム格納部３４には、ＯＳ４０、取引処理プログラム４２、…などのプログラムがインストールされている。
ＯＳ４０は、ファイルの入出力や通信制御装置２４の制御など、センタサーバ２を動作させる上で基本的な機能を実現するプログラムである。

取引処理プログラム４２は、センタサーバ２に、オンライン端末５を介して電子マネーカード７と通信し、例えば、以下のような処理を行わせるプログラムである。
（１）支払い処理
これは、電子マネーカード７に記憶されたバリューを商品代金などの支払い代金として決済する処理である。
この場合、センタサーバ２は、オンライン端末５から要求された減算コマンドを電子マネーカード７に送信し、これを電子マネーカード７で実行させる。
また、この際に、電子マネーカード７の取引状態とセンタサーバ２の取引状態の２つのフラグを設定しながら処理を進める。

（２）入金処理
これは、電子マネーカード７に入金してバリュー残高を増額するものである。
この場合、センタサーバ２は、オンライン端末５から要求された加算コマンドを電子マネーカード７に送信し、これを電子マネーカード７で実行させる。
この場合も、電子マネーカード７の取引状態とセンタサーバ２の取引状態の２つのフラグを設定しながら処理を進める。
以上のように、センタサーバ２は、演算コマンド（演算命令）を送信する演算命令送信手段を備えている。

（３）残高確認処理
これは、電子マネーカード７に記憶されているバリュー残高を提示するものである。
この場合、センタサーバ２は、残高確認コマンドを生成して電子マネーカード７に送信し、これを電子マネーカード７に実行させる。すると、電子マネーカード７は、バリュー残高をセンタサーバ２に送信するので、センタサーバ２は、これをオンライン端末５に表示させる。
また、オンライン端末５が電子マネーカード７に残高確認コマンドを入力し、これに対して電子マネーカード７が返してきたバリュー残高をオンライン端末５が表示するように構成することもできる。
（４）障害発生後の回復処理
これは、センタサーバ２と電子マネーカード７が通信を行っている際に障害が発生し、処理が中断した場合にその回復処理を行うものである。
センタサーバ２は、センタサーバ２及び電子マネーカード７の取引状態の設定状態から障害が発生した時点を判断し、その時点に応じた回復処理を行う。
センタサーバ２は、支払い処理、入金処理、及び残高確認処理を行う前に、センタサーバ２と電子マネーカード７の取引状態から前回の処理で障害が発生したか否かを確認し、障害が発生していた場合はこれを回復してから処理を続行する。このようにセンタサーバ２は、回復手段を備えている。

次に、データ格納部３６について説明する。
センタサーバ２の運用に必要な各種のデータが記憶されており、データ格納部３６には、加盟店端末情報データベース４４、取引情報データベース４６、…などが記憶されている。

加盟店端末情報データベース４４は、各加盟店１０２に設置されたオンライン端末５やオフライン端末６に関する情報を記憶したデータベースである。
加盟店端末情報データベース４４には、例えば、加盟店端末が設置されている加盟店１０２のＩＤ情報である加盟店ＩＤ、加盟店１０２内でオンライン端末５やオフライン端末６に設定されたＩＤ情報である端末ＩＤ、電子マネーシステム１内でオンライン端末５やオフライン端末６に一意に付与されたＩＤ情報であるシリアルＩＤ…などの情報が記憶されている。

センタサーバ２は、加盟店１０２からシリアルＩＤを受信すると、当該オンライン端末５、又はオフライン端末６を特定でき、更に加盟店１０２を特定することができる。
また、オンライン端末５やオフライン端末６を特定するのに端末ＩＤとシリアルＩＤの２つのＩＤ情報を付与したのは、加盟店１０２の便宜を図るためである。即ち、端末ＩＤは、例えば、加盟店端末の設置順に０１、０２、…などと加盟店１０２にとって認識しやすい情報となっており、加盟店１０２は、加盟店内での管理や故障時の問い合わせを端末ＩＤで行うことができる。

取引情報データベース４６は、オンライン端末５やオフライン端末６を介して電子マネーカード７に対して行った取引情報を履歴として蓄積するデータベースである。
取引情報は、電子マネーカード７に対して処理を行う際に生成されるログデータであり、オンライン端末５を介して電子マネーカード７を処理する場合はリアルタイムで生成され、オフライン端末６で処理する場合は、一旦オフライン端末６に蓄積された後、バッチ処理などでセンタサーバ２に送られてくる。

図５は、オンライン端末５にてカードＩＤ「００００１」なる電子マネーカード７を処理した場合に生成された取引情報６１、６２、６３を時系列にて並べて示した図である。
図に示したように、取引情報はカードＩＤ５２、残高５３、取引額５４、取引状態５５、処理内容５６、シリアルＩＤ５７、取引日時５８、…などの各項目から構成されている。
カードＩＤ５２は、オンライン端末５を介して電子マネーカード７から受信したカードＩＤである。

残高５３は、電子マネーカード７の演算処理後のバリュー残高であり、取引額５４は、演算の際に加減算した金額である。
センタサーバ２は、支払い、又は入金処理の際に電子マネーカード７からバリュー残高を受信すると共に（残高受信手段に対応）、オンライン端末５から演算コマンドの送信要求（加減算する金額が付属している）を取得する（要求取得手段に対応）。残高５３は、これらの値を用いて計算されたものである。

取引状態５５は、「取引中」（反転状態に対応）と「取引完了」（初期状態に対応）のうちの何れかが選択的に設定されるフラグ情報であり、サーバフラグを構成している。
取引状態５５は、センタサーバ２側の処理が開始した際に「取引中」に設定され、センタサーバ２側の処理が完了した際に「取引完了」に更新される。

このように、センタサーバ２は、取引状態５５を「取引完了」から「取引中」に反転させたり、あるいは「取引中」から「取引完了」に復帰させるサーバフラグ設定手段を備えている。
図５の例では、図中上から３番目の取引情報は取引状態５５が「取引中」となっており、この取引情報に関するセンタサーバ２側の処理はまだ完了していないことがわかる。

シリアルＩＤ５７は、電子マネーカード７との通信を仲介しているオンライン端末５のシリアル番号である。このシリアル番号を加盟店端末情報データベース４４と照合することにより、電子マネーカード７の処理を行った加盟店１０２を特定することができる。
取引日時５８は、オンライン端末５と通信を行った日時である。例えば、通信開始時刻、及び通信終了時刻などが記憶されている。

図５に示したように、カードＩＤ５２「００００１」で特定される電子マネーカード７に対して行った処理は取引情報として時系列的に記録される。
他のカードＩＤに係る電子マネーカード７に関しても同様に取引情報が蓄積される。
オンライン端末５で行った処理に関してはリアルタイムで取引情報が取引情報データベース４６に記録されるが、オフライン端末６で行った処理に関しては、バッチ処理にてオフライン端末６から送信されてきてから取引情報データベース４６に記録されるまでタイムラグが生じる。

また、オフライン端末６での処理では、処理中にオフライン端末６と電子マネーカード７の間で障害が発生しないので、オフライン端末６での処理では必ずしも取引状態５５の項目を設ける必要はない。
以上にセンタサーバ２について説明したが、オンライン端末５のハードウェア的な構成は、基本的にセンタサーバ２と同様である。
オンライン端末５は、加盟店１０２の担当者や電子マネーカード７を有する顧客などに情報を表示するための表示装置や、効果音などの音声により処理状況を通知する音声出力装置などを備えている。

次に、図６〜図１３のフローチャートを用いて、電子マネーカード７を用いた代金の支払い処理手順、及び支払い中に障害が発生した場合の回復手順などについて説明する。
ここでは、一例として２０、０００円チャージされた電子マネーカード７を用いて９、０００円の支払いを行う場合について説明する。

図６は、電子マネーカード７に支払い処理を施す手順を説明するためのフローチャートである。
このフローチャートでは、電子マネーカード７側とセンタサーバ２側でデータが更新される様子を説明するため、それぞれカード情報と取引情報を併記している。

カード情報は、電子マネーカード７側で保持されているデータの論理的構成を示したものである。
カード情報は、「カードＩＤ」、「残高」、「取引額」、「取引状態」などの項目から構成されている。
これら「カードＩＤ」、「残高」、「取引額」、「取引状態」の各値は、それぞれ、バリュー処理部７ａ、残高記憶部７ｂ、ログデータ記憶部７ｃ、取引状態保持部７ｅに記憶されている情報を用いることができる。

例えば、カード情報７１では、カードＩＤが００００１であり、バリュー残高が２０、０００円であり、また、取引状態は「取引完了」に設定されている。
カード情報７１では、取引状態が「取引完了」に設定されているため、前回の処理において、電子マネーカード７側の処理は完了していることがわかる。

このように構成されたカード情報と取引情報を参照しながら支払い処理について説明する。
まず、顧客は加盟店１０２の担当者（店員）に商品を提示して購入の意思表示を行う。
これに対し、担当者はバーコード読取装置などを用いて商品の代金９、０００円を読み取り、これを支払額としてオンライン端末５に入力する。
すると、オンライン端末５の表示装置に図２２（ａ）に示したような、カード確認画面が表示される。カード確認画面には、支払額が表示されるほか、「電子マネーカードをセットしてください」などと、電子マネーカード７をオンライン端末５のリーダライタ５ｂにセットするように促す指示が表示される。
顧客はカード確認画面の指示に従って、オンライン端末５に電子マネーカード７をセットする。

図６に戻り、電子マネーカード７は、オンライン端末５にセットされるとリーダライタ５ｂの電波によって駆動され、オンライン端末５との通信を開始する（ステップ１０４）。
電子マネーカード７がオンライン端末５と接続されると、センタサーバ２は電子マネーカード７と通信できるようになる。
電子マネーカード７とセンタサーバ２が通信を行っている間、オンライン端末５の表示装置には、図２２（ｂ）に示したような通信中画面が表示される。これにより、顧客と加盟店１０２の担当者は電子マネーカード７とセンタサーバ２が通信中であることを認識することができる。

図６に戻り、オンライン端末５は電子マネーカード７と通信を開始すると、電子マネーカード７からカードＩＤを読み取り、これを支払額と共にセンタサーバ２に送信する（ステップ２０４）。
なお、カードＩＤの読み取りは、オンライン端末５が電子マネーカード７にカードＩＤコマンドを電子マネーカード７に入力することにより行われる。
電子マネーカード７では、バリュー処理部７ａがカードＩＤコマンドを実行し、カードＩＤ記憶部７ｄからカードＩＤを読み取ってオンライン端末５に返すようになっている。

センタサーバ２はオンライン端末５からこれらの情報を受け付けると、電子マネーカード７に対して残高・状態確認要求を行う（ステップ３０４）。
この要求は、電子マネーカード７に対してバリュー残高と取引状態の送信を要求するものであり、電子マネーカード７にこれらの動作を行わせるためのコマンドを送信することにより行われる。

電子マネーカード７は、オンライン端末５から残高・状態確認要求を受け、残高・状態確認応答を行う（ステップ１０６）。
この処理は、オンライン端末５から送信されてきたコマンドをバリュー処理部７ａが実行して、残高記憶部７ｂに記憶されているバリュー残高と、取引状態保持部７ｅに記憶されている取引状態をセンタサーバ２に送信することにより行われる。このように、センタサーバ２は、端末フラグ受信手段（電子マネーカード７の取引状態を受信）を備えている。

センタサーバ２は、電子マネーカード７からバリュー残高と取引状態を受信する。
そして、受信した取引状態と取引情報データベース４６に記憶されている前回の取引情報の取引状態を確認し、前回の取引で障害が発生したか否かを確認する。
障害が発生していた場合は後述の方法により障害を回復する。ここでは、障害が発生しなかったものとする。

センタサーバ２は、電子マネーカード７とセンタサーバ２側の取引情報を確認した後、今回の処理に関する取引情報８１を生成して取引情報データベース４６に記憶して登録する（ステップ３０６）。
取引情報８１では、電子マネーカード７から受信したカードＩＤ、バリュー残高、及びオンライン端末５で入力された取引額などが記憶される。なお、図では処理内容、シリアルＩＤ、取引日時、…などのほかの項目は省略してある。
図に示したように、取引情報８１では、カードＩＤが００００１、残高が減算後の値で１１、０００円、取引額が９、０００円となっている。

なお、登録時には、取引情報８１の取引状態は「取引中」に設定されている。このように、取引状態は、センタサーバ２側の処理が開始される際に「取引中」に設定される。そして、センタサーバ２側での処理が完了した際に「取引完了」に設定される。

取引状態が「取引中」の場合は、取引情報の取引情報データベース４６への記録が確定した訳ではなく、後述のように障害回復の際に無効とされる場合がある。
そのため、取引情報８１で残高が減算後の値になっているが、これは、障害回復の際に利用するためであり、センタサーバ２側での減算処理が完了するのは、取引状態が「取引完了」に設定された時点である。

次に、センタサーバ２は、電子マネーカード７に対して取引中・減算要求をおこなう（ステップ３０８）。
この要求は、電子マネーカード７に取引中コマンドと、支払額分の減算を実行させるための減算コマンドを送信することにより行われる。

本実施の形態では、電子マネーカード７において、減算コマンドの実行と取引状態の更新を対応させるため、減算コマンドと取引中コマンドを共に送信することにした。即ち、取引状態が更新されたことを確認することにより、電子マネーカード７で減算コマンドが実行されたことを確認することができる。
後の入金処理でも加算コマンドと取引完了コマンドを共に電子マネーカード７に送信するのも同じ理由による。

電子マネーカード７は、これらのコマンドを受信して実行し、取引状態を「取引中」に設定すると共に、バリュー残高を支払額分だけ減算する。この結果、カード情報７１はカード情報７２に更新される。図に示したように、カード情報７２では、残高が１１、０００円と減算後の値となっており、また、取引状態は、「取引中」に設定されている。
次に、電子マネーカード７は、減算が完了し、取引状態を「取引中」に設定した旨を示す減算完了通知をセンタサーバ２に送信する（ステップ１０８）。

センタサーバ２は、電子マネーカード７から減算完了通知を受信すると取引情報８１の取引状態を「取引完了」に設定し、取引情報８２へ更新する（ステップ３１０）。
これにより、センタサーバ２は、センタサーバ２側での減算処理を完了させると共に取引情報８２の取引情報データベース４６への登録が確定する。

センタサーバ２は、センタサーバ２側での減算処理を完了させると、電子マネーカード７に対して取引完了設定要求を行う（ステップ３１２）。この要求は、電子マネーカード７に取引完了コマンドを送信することにより行われる。
これに対し、電子マネーカード７は、取引完了コマンドを受信して実行し、取引状態を「取引完了」に設定する（ステップ１１０）。即ち、取引状態の値を「取引中」から「取引完了」に復帰する。その結果、カード情報はカード情報７３のように更新される。
電子マネーカード７は、取引完了コマンドを実行後、取引状態を「取引完了」に設定した旨を表す取引完了通知をセンタサーバ２に送信する。

センタサーバ２は、電子マネーカード７から取引完了通知を受信すると、電子マネーカード７との処理が完了した旨を表す取引完了通知をオンライン端末５に送信する（ステップ３１４）。
オンライン端末５は、センタサーバ２から取引完了通知を受信して処理が完了したことを確認する（ステップ２０６）。

このとき、オンライン端末５は、処理成功を表す効果音と共に表示装置に図２２（ｃ）に示したような支払い完了画面を表示する。
支払い完了画面では、カードＩＤと支払金額、及び支払い後のバリュー残高などが表示される。

以上に説明した支払い処理で、電子マネーカード７とセンタサーバ２の通信に障害が発生する可能性がある箇所としては、ステップ１０６（障害１と呼ぶ、以下同様）、ステップ３０８（障害２）、ステップ１０８（障害３）、ステップ３１２（障害４）、ステップ１１０（障害５）がある。
なお、ステップ３０４で障害が発生する可能性もあるが、この場合の処理は障害１と同じであるので説明を省略する。

以下に、これら障害１〜障害５が発生した場合の処理手順と、その回復処理手順について説明する。
図７は、障害１が発生した場合の処理手順を説明するためのフローチャートである。なお、以下では図６のフローチャートに対応するステップには同じステップ番号を付して説明を簡略化、あるいは省略することにする。

まず、電子マネーカード７がバリュー残高と取引状態をオンライン端末５に送信する際に（ステップ１０６）障害１が発生した場合、センタサーバ２は、障害１を検出する（ステップ３１６）。
ここで、電子マネーシステム１は、タイムアウトにより障害を検出するものとする。即ち、センタサーバ２は、電子マネーカード７からの応答を受信するまでの時間を計測し、予め設定した所定時間内に応答がない場合、障害が発生したものと判断する。なお、これは一例であって他の方法により障害を検出してもよい。

センタサーバ２は、障害１を検出すると、処理が失敗した旨を表す取引失敗通知をオンライン端末５に送信する（ステップ３１８）。
オンライン端末５は、センタサーバ２から取引失敗通知を受信して処理が失敗したことを確認する（ステップ２０８）。
オンライン端末５は、処理の失敗を確認すると取引失敗を表す効果音と共に図２２（ｄ）に示したようなエラー発生画面を表示する。

エラー発生画面では、残高確認を指示する旨の表示が行われ、加盟店１０２の担当者は、電子マネーカード７の残高確認処理を行うことになる。
このように電子マネーシステム１は、エラーが発生すると残高確認を要求し、残高確認処理に伴って障害を回復するようになっている。
即ち、残高確認処理は、まずセンタサーバ２が電子マネーカード７側とセンタサーバ２側の取引状態を確認して前回の処理で障害が発生したか否かを確認する。障害が発生していない場合は残高確認を行い、障害が発生していた場合は回復処理を行った後残高確認を行う。

なお、図６の説明では省略したが、支払い処理や後に説明する入金処理においても、まずセンタサーバ２は前回の処理で障害が発生したか否かを確認し、障害が発生していた場合はこれを回復してから支払い処理、あるいは入金処理を続行する。

さて、障害１が発生した場合、カード情報７１は未処理であり、またセンタサーバ２でも取引情報が登録される前なので回復処理を行う必要はない。このため、障害１が発生した場合は、回復処理をせずに残高確認が行われる。そして、加盟店１０２の担当者は、残高確認の後に支払い処理を最初から行うことになる。

次に、図８のフローチャートを用いて障害２、及び障害３が発生した場合の処理手順を説明する。
ステップ３０８（障害２）、又はステップ１０８（障害３）で障害が発生した場合、センタサーバ２はこれを検出し（ステップ３２０）、オンライン端末５に対して取引失敗通知を送信する（ステップ３２２）。
オンライン端末５は、取引失敗通知を受信して失敗を確認し、効果音と共にエラー発生画面を表示する（ステップ２１０）。

ここで障害２と障害３のうち、何れが発生したかは、カード情報と取引情報の取引状態の組合せから特定することができる。
即ち、障害２が発生した場合、カード情報はカード情報７１となり、障害３が発生した場合はカード情報７２となる。また、取引情報は、障害２、障害３の何れの場合でも取引情報８１となる。
このためカード情報と取引情報の取引状態の組合せは、障害２が発生した場合は（取引完了、取引中）となり、障害３が発生した場合は（取引中、取引中）となる。
以下では、同様にカード情報と取引情報の取引状態の組合せをこの順序で括弧書きにて記すことにする。

図９は、障害２が発生した場合の回復処理手順を説明するためのフローチャートである。
この処理は、オンライン端末５でエラー発生画面の指示に従って、加盟店１０２の担当者が電子マネーカード７の残高確認を要求することにより開始する。

担当者は、電子マネーカード７をリーダライタ５ｂにセットして電子マネーカード７とオンライン端末５の通信を開始し（ステップ１０４）（なお、通常はエラーが発生した時点で電子マネーカード７がオンライン端末５にセットされているので、このまま引き続き残高確認処理に移行する）、オンライン端末５に設けられた残高確認ボタンを押すなどしてセンタサーバ２に残高確認を要求する（ステップ２０５）。

センタサーバ２は、オンライン端末５より残高確認要求を受けて、残高・状態確認要求を電子マネーカード７に対して行い（ステップ３０４）、これに対し、電子マネーカード７は、残高・状態確認応答を行う（ステップ１０６）。
次に、センタサーバ２は、残高・状態確認応答により電子マネーカード７から送信されてきた取引状態と、前回の取引情報８１の取引状態の組合せを確認する。
その結果、取引状態の組合せが（取引完了、取引中）となり、また、前回の処理が支払い処理であったため（図示しないが取引情報８１に記録されている）、センタサーバ２は前回の処理が障害２により中断したと判断する。

障害２が発生した場合、センタサーバ２は、取引情報８１の取引状態を「取引回復」に設定することにより状態回復を行う。
センタサーバ２は、取引状態が「取引回復」に設定されている取引情報は無効になったものとして扱うように構成されており、その結果、前々回の取引情報８０が電子マネーカード７に対して最新の取引情報となる。
換言すればセンタサーバ２は前回の取引情報８１を前々回の取引情報８０に更新することにより障害回復を行う（ステップ３２４）。

センタサーバ２は、取引情報を更新した後、障害回復を行った旨を表す障害回復通知をオンライン端末５に送信する（ステップ３２６）。オンライン端末５はこれを受信して障害が回復したことを確認する（ステップ２１２）。
なお、本実施の形態では、障害回復通知として電子マネーカード７のバリュー残高を送信し、オンライン端末５ではバリュー残高が表示されるようになっている。即ち、残高確認と共に障害回復を行っている。

そして、加盟店１０２の担当者は残高確認を行った後、支払い処理を再度最初から行う。
このように、障害２が発生した場合はカード情報が更新前のままであるので、取引情報を更新前のものに戻すことにより、両者の整合性をとることができる。

図１０は、障害３が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ１０４〜ステップ１０６までは障害２の場合と同様である。
そして、センタサーバ２は、電子マネーカード７から送信されてきた取引状態と、前回の取引情報８１の取引状態の組合せを確認し、取引状態の組合せが（取引中、取引中）であり、また前回の取引が支払い処理であったことから、前回の処理が障害３により中断したと判断する。

障害３が発生した場合、センタサーバ２は、前回の処理において電子マネーカード７で減算した金額分の加算を行う加算コマンドを生成し、取引完了コマンドと共に電子マネーカード７に送信する（ステップ３２８）。
電子マネーカード７は、この加算コマンドを実行し、前回減算した分のバリューを加算し、取引状態を「取引完了」に設定する。そして、加算処理と「取引完了」に設定した旨を表す加算完了通知をセンタサーバ２に送信する（ステップ１１２）。
以上の処理によりカード情報はカード情報７２からカード情報７１に更新される。

センタサーバ２は、電子マネーカード７から加算完了通知を受信すると、障害２の場合と同様に取引情報８１の取引状態を「取引回復」に設定して取引情報を更新する（ステップ３３０）。これにより、前々回の取引情報８０が最新の取引情報として扱われる。
次に、センタサーバ２は、オンライン端末５に障害回復通知を送信し（ステップ３３２）、オンライン端末５はこれにより障害が回復したことを確認する（ステップ２１４）。
そして、障害３を回復した後に支払い処理を再度最初から行う。

以上のように、障害３が発生した場合は、電子マネーカード７に障害発生時に減算したバリューを加算してバリュー残高を障害発生前の状態に戻すと共に、取引情報も障害発生時前のものに戻す。
即ち、センタサーバ２で取引情報が確定する前（取引情報が支払い後のものに更新される前）に、電子マネーカード７で減算を実行するため、電子マネーカード７に減算したバリューを戻すことにより障害発生前の状態に復帰することができる。

図１１は、障害４、及び障害５が発生した場合の処理手順を説明するためのフローチャートである。
ステップ１０４〜ステップ３１０までは図６のフローチャートと同様である。センタサーバ２は、取引情報を取引情報８２に更新した後（ステップ３１０）、電子マネーカード７に宛てて取引完了コマンドを送信する（ステップ３１２）。

その後、障害４又は障害５が発生した場合、センタサーバ２はこれらの何れかの障害が発生したことを検出し（ステップ３３４）、オンライン端末５に対して取引失敗通知を行う（ステップ３３６）。
そして、オンライン端末５は、取引処理失敗を表す効果音と共に表示装置にエラー発生画面を表示する（ステップ２１６）。

カード情報は障害４が発生した場合はカード情報７２となり、障害５が発生した場合はカード情報７３となる。また、取引情報は何れの場合も取引情報８２である。
その結果、取引状態の組合せは、障害４の場合は（取引中、取引完了）となり、障害５の場合は（取引完了、取引完了）となる。

図１２は、障害４が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ１０４〜ステップ１０６までは障害２の場合と同様である。
そして、センタサーバ２は、電子マネーカード７から送信されてきた取引状態と、前回の取引情報８２の取引状態の組合せを確認し、取引状態の組合せが（取引中、取引完了）であり、また前回の取引が支払い処理であったことから、前回の処理が障害４により中断したと判断する。

障害４が発生した場合は、電子マネーカード７とセンタサーバ２の何れも減算処理は完了しており、カード情報７２の取引状態が不整合であるだけなのでこれを「取引中」から「取引完了」に復帰させることにより障害回復を行う。
そのため、センタサーバ２は電子マネーカード７に取引完了設定要求を行う（ステップ３３８）。この取引完了設定要求は、電子マネーカード７に取引完了コマンドを送信することにより行われる。

電子マネーカード７は、取引完了コマンドを受信して実行し、カード情報７２の取引状態を「取引完了」に設定する。これにより、カード情報はカード情報７２からカード情報７３に更新される。
そして、電子マネーカード７は、取引完了通知をセンタサーバ２に送信する（ステップ１１４）。
センタサーバ２は、取引完了通知を受信した後、障害回復通知をオンライン端末５に送信し（ステップ３４０）、オンライン端末５は、これを受信して障害４が回復されたことを確認する（ステップ２１８）。

図１３は、障害５が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ１０４〜ステップ１０６までは障害２の場合と同様である。
そして、センタサーバ２は、電子マネーカード７から送信されてきた取引状態と、前回の取引情報８２の取引状態の組合せを確認し、取引状態の組合せが（取引完了、取引完了）であり、また前回の取引が支払い処理であったことから、前回の処理が障害５により中断したと判断する。

障害５が発生した場合は、カード情報と取引情報の何れも支払い処理後のものに更新されており、カード情報が更新されたことをセンタサーバ２が確認できていなかっただけなので、特に回復処理を行う必要はない。
そのため、センタサーバ２は、特に回復処理を行わずにオンライン端末５に障害回復通知を送信し（ステップ３４２）、オンライン端末５は、これにより障害が回復したことを確認する（ステップ２２０）。

次に、図１４〜図２０のフローチャートを用いて、電子マネーカード７を用いた入金処理手順、及び入金中に障害が発生した場合の回復手順などについて説明する。
ここでは、一例として２０、０００円チャージされた電子マネーカード７に９、０００円の入金を行う場合について説明する。

図１４は入金処理の手順を説明するためのフローチャートである。
入金処理の場合、まず顧客は加盟店１０２の担当者に現金９、０００円を渡し、９、０００円分の入金を依頼する。
担当者は、顧客から現金９、０００円を受領すると共に、９、０００円を入金額としてオンライン端末５に入力する。
すると、オンライン端末５の表示装置にカード確認画面が表示されるので、顧客は画面の指示に従って電子マネーカード７をリーダライタ５ｂにセットする。

電子マネーカード７は、オンライン端末５にセットされると、オンライン端末５のリーダライタ５ｂから放射される電波によって駆動され、オンライン端末５との通信を開始する（ステップ５０４）。
電子マネーカード７がオンライン端末５と接続されると、センタサーバ２は電子マネーカード７と通信できるようになり、オンライン端末５の表示装置には通信中画面が表示される。

オンライン端末５は電子マネーカード７と通信を開始すると、電子マネーカード７からカードＩＤを読み取り、これを入金額と共にセンタサーバ２に送信する（ステップ６０４）。
センタサーバ２はこれらの情報を受け付けると、電子マネーカード７に対して残高・状態確認要求を行う（ステップ７０４）。
電子マネーカード７は、これを受け、残高・状態確認応答を行う（ステップ５０６）。

センタサーバ２は、電子マネーカード７から残高・状態確認応答を受けると、前回の処理で障害が発生したか否かを確認し、障害が発生していた場合は、これを回復してから処理を続行する。障害回復処理については後述し、ここでは、障害が発生しなかったものとする。

センタサーバ２は、前回の処理で障害が発生していないことを確認した後、この処理に関する取引情報８６を生成して取引情報データベース４６に登録する（ステップ７０６）。
取引情報８６では、残高が入金後の金額となっているが、取引状態が「取引中」に設定されており、取引情報データベース４６への登録はまだ確定していない。即ち、センタサーバ２ではまだ加算処理は完了していない。

次に、センタサーバ２は、電子マネーカード７に対して取引中設定要求を行う（ステップ７０８）。
電子マネーカード７は取引中設定要求を受けて取引状態を「取引中」に設定し、取引中設定通知をセンタサーバ２に送信する（ステップ５０８）。これにより、カード情報７６は、カード情報７７に更新される。

センタサーバ２は、電子マネーカード７から取引中設定通知を受信すると取引状態を「取引完了」に設定し、これによって取引情報８６を取引情報８７に更新する（ステップ７１０）。
取引状態を「取引完了」に設定することにより取引情報８７の取引情報データベース４６への登録が確定し、センタサーバ２で加算が行われたことになる。

次に、センタサーバ２は、電子マネーカード７に取引完了設定・加算要求を行う（ステップ７１４）。これは、入金額分の加算を行う加算コマンドと取引完了コマンドを共に電子マネーカード７に送信することにより行われる。
電子マネーカード７は、これらのコマンドを受信し、加算コマンドを実行して、バリュー残高を９、０００増加させると共に、取引状態を「取引完了」に設定する。そして、加算処理と「取引完了」に設定した旨を表す加算完了通知をセンタサーバ２に送信する（ステップ５１０）。

加算コマンドと取引完了コマンドの実行によりカード情報７７はカード情報７８に更新される。
図に示したようにカード情報７８は、バリュー残高が２９、０００円となり、取引状態が「取引完了」に設定されている。

センタサーバ２は、電子マネーカード７から加算完了通知を受信すると、取引完了通知をオンライン端末５に送信する（ステップ７１６）。
オンライン端末５は、センタサーバ２から取引完了通知を受信して処理が完了したことを確認する（ステップ６０６）。
このとき、オンライン端末５は、処理成功を表す効果音と共に表示装置に入金完了画面が表示される。

図１４に示した入金処理で、電子マネーカード７とセンタサーバ２の通信に障害が発生する可能性がある箇所としては、ステップ５０６（障害６）、ステップ７０８（障害７）、ステップ５０８（障害８）、ステップ７１４（障害９）、ステップ５１０（障害１０）がある。
なお、ステップ７０４で障害が発生する可能性もあるが、この場合の処理は障害６と同じであるので説明を省略する。

以下に、これら障害６〜障害１０が発生した場合の処理手順と、回復処理手順について説明する。
図１５は、障害６が発生した場合の処理手順を説明するためのフローチャートである。
なお、以下では図１５のフローチャートに対応するステップには同じステップ番号を付して説明を簡略化、あるいは省略することにする。

まず、電子マネーカード７がバリュー残高と取引状態をセンタサーバ２に送信する際に（ステップ５０６）障害６が発生した場合、センタサーバ２は、障害６を検出する（ステップ７１８）。
センタサーバ２は、障害６を検出すると、取引処理が失敗した旨を表す取引失敗通知をオンライン端末５に送信する（ステップ７２０）。

オンライン端末５は、センタサーバ２から取引失敗通知を受信して処理が失敗したことを確認する（ステップ６０８）。
このとき、オンライン端末５は、取引失敗を表す効果音と共にエラー発生画面を表示する。エラー発生画面には残高確認を指示する旨の通知が行われ、加盟店１０２の担当者は、電子マネーカード７の残高確認処理を行うことになる。

さて、障害６が発生した場合、カード情報７６は未処理であり、またセンタサーバ２でも取引情報が登録される前なので回復処理を行う必要はない。このため、障害６が発生した場合は、回復処理をせずに残高確認が行われる。そして、加盟店１０２の担当者は、残高確認の後に処理を最初から行うことになる。

図１６は、障害７、及び障害８が発生した場合の処理手順を説明するためのフローチャートである。
ステップ７０８（障害７）、又はステップ５０８（障害８）で障害が発生した場合、センタサーバ２はこれを検出し（ステップ７１８）、オンライン端末５に対して取引失敗通知を送信する（ステップ７２０）。
オンライン端末５は、取引失敗通知を受信して失敗を確認し、効果音と共にエラー発生画面を表示する（ステップ６０８）。

ここで障害７と障害８のうち、何れが発生したかは、カード情報と取引情報の取引状態の組合せから特定する。
即ち、障害７が発生した場合、カード情報はカード情報７６となり、障害８が発生した場合はカード情報７７となる。また、取引情報は、障害７、障害８の何れの場合でも取引情報８６となる。
このためカード情報と取引情報の取引状態の組合せは、障害７が発生した場合は（取引完了、取引中）となり、障害８が発生した場合は（取引中、取引中）となる。

図１７は、障害７が発生した場合の回復処理手順を説明するためのフローチャートである。
この処理は、オンライン端末５でエラー発生画面の指示に従って、加盟店１０２の担当者が電子マネーカード７の残高確認を要求することにより開始する。

担当者は、電子マネーカード７をリーダライタ５ｂにセットして電子マネーカード７とオンライン端末５の通信を開始し（ステップ５０４）（なお、通常はエラーが発生した時点で電子マネーカード７がオンライン端末５にセットされているので、このまま引き続き残高確認処理に移行する）、オンライン端末５に設けられた残高確認ボタンを押すなどしてセンタサーバ２に残高確認を要求する（ステップ６０５）。

センタサーバ２は、オンライン端末５より残高確認要求を受けて、残高・状態確認要求を電子マネーカード７に対して行い（ステップ７０４）、これに対し、電子マネーカード７は、残高・状態確認応答を行う（ステップ５０６）。
次に、センタサーバ２は、残高・状態確認応答により電子マネーカード７から送信されてきた取引状態と、前回の取引情報８６の取引状態の組合せを確認する。
その結果、取引状態の組合せが（取引完了、取引中）となり、また、前回の処理が入金処理であったため（図示しないが取引情報８６に記録されている）、センタサーバ２は前回の処理が障害７により中断したと判断する。

すると、センタサーバ２は、取引情報８６の取引状態を「取引回復」に設定し、取引情報８６を取引情報８８に更新する。
センタサーバ２は、取引状態が「取引回復」に設定されている取引情報は無効になったものとして扱うため、前々回の取引情報８５が最新の取引情報として復活する。
換言すればセンタサーバ２は前回の取引情報８６を前々回の取引情報８５に更新することにより障害回復を行う（ステップ７２２）。

センタサーバ２は、取引情報を更新した後、障害回復を行った旨を表す障害回復通知をオンライン端末５に送信する（ステップ７２４）。オンライン端末５はこれを受信して障害が回復したことを確認する（ステップ６１０）。
そして、加盟店１０２の担当者は残高確認を行った後、入金処理を再度最初から行う。

図１８は、障害８が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ５０４〜ステップ５０６までは障害７と同様である。
そして、センタサーバ２は、電子マネーカード７から送信されてきた取引状態と、前回の取引情報８６の取引状態の組合せを確認し、取引状態の組合せが（取引中、取引中）であり、また前回の取引が入金処理であったことから、前回の処理が障害８により中断したと判断する。

障害８が発生した場合、電子マネーカード７とセンタサーバ２の何れも加算処理が完了していないので、カード情報と取引情報を入金処理前の状態に戻すことにより障害回復を行う。
そのため、センタサーバ２は、電子マネーカード７に対して取引完了設定要求を行う（ステップ７２６）。この要求は、電子マネーカード７に取引完了コマンドを送信することにより行われる。

これに対し、電子マネーカード７は、取引状態を「取引完了」に設定し、センタサーバ２に取引完了設定通知を送信する（ステップ５１２）。
これにより、カード情報はカード情報７７からカード情報７６に戻される。

センタサーバ２は、電子マネーカード７から取引完了通知を受信すると、取引情報８６の取引状態を「取引回復」に設定して取引情報８８に更新する（ステップ７２８）。これにより、取引情報８８は無効な取引情報となり、前々回の取引情報８５が最新の取引情報として復活する。
次に、センタサーバ２は、オンライン端末５に処理回復通知を送信し（ステップ７３０）、オンライン端末５はこれにより障害が回復したことを確認する（ステップ６１２）。
その後、加盟店１０２の担当者は入金処理を最初からやり直す。

図１９は、障害９、及び障害１０が発生した場合の処理手順を説明するためのフローチャートである。
ステップ５０４〜ステップ７１０は図１４のフローチャートと同様である。
センタサーバ２は、取引情報を取引情報８７に更新した後（ステップ７１４）、電子マネーカード７に宛てて取引完了コマンドと加算コマンドを送信する（ステップ７１４）。

その後、障害９又は障害１０が発生した場合、センタサーバ２はこれらの何れかの障害が発生したことを検出し（ステップ７３２）、オンライン端末５に対して取引失敗通知を行う（ステップ７３４）。
そして、オンライン端末５は、取引処理失敗を表す効果音と共に表示装置にエラー発生画面を表示する（ステップ６１４）。

カード情報は障害９が発生した場合はカード情報７７となり、障害１０が発生した場合はカード情報７８となる。また、取引情報は何れの場合も取引情報８７である。
その結果、取引状態の組合せは、障害９の場合は（取引中、取引完了）となり、障害１０の場合は（取引完了、取引完了）となる。

図２０は、障害９が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ５０４〜ステップ５０６までは障害６の場合と同様である。
そして、センタサーバ２は、電子マネーカード７から送信されてきた取引状態と、前回の取引情報８７の取引状態の組合せを確認し、取引状態の組合せが（取引中、取引完了）であり、また前回の取引が入金処理であったことから、前回の処理が障害９により中断したと判断する。

障害９の場合、センタサーバ２では加算処理が完了し、電子マネーカード７ではまだ加算処理が行われていない状態であるため、電子マネーカード７に加算処理を行わせることにより回復処理を行う。
まず、センタサーバ２は、電子マネーカード７に対して取引完了設定・加算要求を再度行う（ステップ７３６）。

電子マネーカード７は、これに応じて加算処理を行うと共に取引状態を「取引完了」に設定し、センタサーバ２に加算完了通知を送信する（ステップ５１４）。これにより、カード情報７７はカード情報７８に更新される。
センタサーバ２は、加算完了通知を受信した後、障害回復通知をオンライン端末５に送信し（ステップ７３８）、オンライン端末５は、これを受信して障害９が回復したことを確認する（ステップ６１６）。

次に、障害１０の回復処理について説明する。障害１０では、電子マネーカード７とセンタサーバ２の何れでも加算処理が完了しており、また取引状態も共に「取引完了」に設定されているため状態回復処理を行う必要はない。
そのため、障害１０の場合は障害回復を行うことなくそのまま残高確認が行われる。

以上に説明したように、電子マネーシステム１では、支払い処理を行う場合は、電子マネーカード７で減算処理を行った後（図６ステップ１０８）、センタサーバ２で減算処理を行い（図６ステップ３１０）、また、入金処理を行う場合は、センタサーバ２で加算処理を行った後（図１４ステップ７１０）、電子マネーカード７で加算を行っている（図１４ステップ５１０）。

そのため、障害により電子マネーカード７とセンタサーバ２でバリュー残高の食い違いが生じた場合（障害３、障害９）、何れも電子マネーカード７に対して加算処理を行うことにより回復処理を行うことができる。
このように、障害回復を行う場合は、電子マネーカード７への処理は減算処理となることはないので、未回復カードを用いてオフライン端末６で行われる支払いを特に制限する必要がない。

また、以上の例では、残高確認を行う際に併せて障害回復を行うこととしたが、顧客と加盟店１０２の担当者の何れもが障害が発生したことに気づかず、障害回復を行わない場合もあり得る。
センタサーバ２は、支払い処理、入金処理の際に、これらの処理に先立って前回の処理で障害が発生したか否かを確認するため、例え、前回の取引で障害回復を行わなかったとしても、今回の取引で障害回復を行ってから処理を行うことができる。

次に、障害回復を行っていない電子マネーカード７（以下、未回復カードと呼ぶ）をオフライン端末６で使用する場合について説明する。
未回復カードを用いてオフライン端末６で支払いを行う場合は、特に制限することなく使用できる。何れの障害が発生しても未回復カードに記憶されているバリューの残高は、顧客が本来有しているバリュー残高以下であるので、これから減算しても不都合は生じないからである。
また、センタサーバ２は、取引情報で障害回復するため、未回復カードをオフライン端末６で使用して支払いを行った後、この未払いカードをオンライン端末５にセットして障害回復を行うこともできる。

一方、未回復カードに入金を行う場合には不都合が生じる場合がある。即ち、電子マネーカード７が記憶できるバリュー残高には上限値が設けられているため、未回復カードに入金を行うとバリュー残高がこの上限値を超える場合が生じる可能性がある。
例えば、バリューの上限値が５万円であるとする。そして、現在未回復カードに記憶されているバリューが４万円であるが、障害を回復すると５千円加算されるとする。

顧客が未回復カードに１万円を入金してバリュー残高５万円とした後、障害を回復するとバリュー残高が５万５千円となり上限値を越えてしまう。
そのため、オフライン端末６は、電子マネーカード７に入金を行う前に、電子マネーカード７が未回復カードか否かを確認し、未回復カードである場合は、入金を制限するようになっている。

図２１は、オフライン端末６で電子マネーカード７に入金を行う手順を説明するためのフローチャートである。なお、以下のようにオフライン端末６は、演算命令入力装置を構成している。
電子マネーカード７は、オフライン端末６のリーダライタにセットされているものとする。
まず、加盟店１０２の担当者は、オフライン端末６に入金額を入力する（ステップ９０４）。これは、加算金額取得手段に対応する。

すると、オフライン端末６は、電子マネーカード７に対して残高・状態確認要求を行い（ステップ９０６）、これに対し、電子マネーカード７は、オフライン端末６に対して残高・状態確認応答を行う（ステップ８０４）。このように、センタサーバ２は、電子マネーカード７から取引状態を受信し、これは端末フラグ受信手段に対応する。

オフライン端末６は、電子マネーカード７から受信した取引状態が「取引完了」と「取引中」の何れであるかを判断する（ステップ９０８）。
取引状態が「取引完了」であった場合（ステップ９０８；Ｙ）、オフライン端末６は、加算コマンドを生成して電子マネーカード７に入力し、入金処理を行う（ステップ８０６）。

一方、取引状態が「取引中」であった場合（ステップ９０８；Ｎ）、オフライン端末６は、入金処理をせずにアラームを発する（ステップ１０００）。
このような、オフライン端末６は、加算命令生成手段と、取引状態が「取引中」であった場合、電子マネーカード７への入力を制限する加算命令入力手段を備えている。

このように、オフライン端末６は、電子マネーカード７の取引状態を確認することにより、電子マネーカード７が未回復カードか否かを判断することができ、また、未回復カードであった場合は、入金処理を制限する（本実施の形態では入金処理を全く行わない）。

なお、本実施の形態では、未回復カードに関しては、入金額を制限するように構成することも可能である。
即ち、障害により電子マネーカード７に記憶されているバリュー残高が、実際にユーザが保有しているバリュー残高より少なくなる場合は、障害３、及び障害９が発生した場合である。
この場合に、障害回復により加算される可能性のある金額を見越して、オフライン端末６で入金できる金額の上限を動的に制限することができる。

即ち、電子マネーカード７のカード情報から、回復処理にて加算処理が行われた場合、その加算額は「取引額」に記憶されている金額である。障害の種類によりこの金額がバリュー残高に加算されるかもしれないし、又は加算されないかもしれないが、オフライン端末６は、少なくとも加算されるこの金額分だけ残高が加算される可能性があることがわかる。
そこで、オフライン端末６は、上限値からこの金額を減じた金額をこの電子マネーカード７の上限値として設定すればよい。

以上、本実施の形態の一例について説明したが、各種の変形例が可能である。
障害が発生した場合、それが電子マネーカード７で演算が行われた後に発生したのか、あるいは前に障害が発生したのかが最低限わかれば障害回復を行うことができる。そこでここではそのための条件について考える。

図２３（ａ）に示したように本実施の形態では、ステップ１〜ステップ４の通信のタイミングがある。
即ち、センタサーバ２は、ステップ１で取引中コマンドを送信し、ステップ２で取引中設定通知を受信し、更にステップ３で取引完了コマンドを送信し、ステップ４で取引完了通知を受信する。

電子マネーカード７に演算命令を送信するタイミングは、ステップ１とステップ３があり、図２３（ａ）は、ステップ１で演算コマンドを送信する場合を示している。
ステップ２、３で障害が発生した場合は、電子マネーカード７の取引状態は「取引中」になっている。即ち、電子マネーカード７の取引状態が「取引中」であることさえわかれば、電子マネーカード７で演算処理後に障害が発生したことがわかる。そのため、ステップ２とステップ３を必ずしも識別する必要はない。

一方、電子マネーカード７の取引状態が「取引完了」であった場合、演算処理前に障害が発生したのか（ステップ１）、あるいは演算処理後に障害が発生したのか（ステップ４）識別することができない。そのため、ステップ１〜ステップ４の間でセンタサーバ２の取引状態を（奇数回）反転させると、ステップ１での障害とステップ４での障害を区別することができる。
ここで、取引状態を反転させるとは、取引状態を「取引完了」→「取引中」、又は「取引中」→「取引完了」に設定することを意味する。

このように、構成すると、電子マネーカード７とセンタサーバ２の取引状態の組合せだけから電子マネーカード７で演算処理が行われたか否かを判断することができる。
そして、更に、センタサーバ２で取引状態を反転させる際に、センタサーバ２で記憶しているバリュー残高を更新することにより、センタサーバ２で記憶しているバリュー残高が更新前のものかあるいは後のものかを取引状態から判断することができる。

図２３（ｂ）は、ステップ３で演算コマンドを送信する場合を示している。この場合は、電子マネーカード７の取引情報が「取引中」である場合は、演算処理前に障害が発生したことがわかる。
一方取引情報が「取引完了」であった場合、これだけでは演算処理前に障害が発生したのか（ステップ１）、あるいは演算処理後に障害が発生したのか（ステップ４）を識別することができない。そのため、ステップ１〜ステップ４の間でセンタサーバ２側の取引状態を反転させれば、何れで障害が発生したのか特定することができる。また、その反転の際にセンタサーバ２側で記憶しているバリュー残高の更新も行う。

以上をまとめると、電子マネーカード７の取引状態を「取引中」か「取引完了」に設定させる際に演算コマンドも一緒に送信し、電子マネーカード７に取引中コマンドを送信してから（ステップ１）、取引完了通知を受信するまで（ステップ４）にセンタサーバ２の取引状態を反転させ、更に、反転の際にセンタサーバ２側で記憶しているバリュー残高を更新すればよいことになる。

即ち、センタサーバ２は、電子マネーカード７の取引状態を反転させる取引中コマンドを送信し、電子マネーカード７がこれを実行して取引状態が「取引中」に反転されたことを確認した後、取引完了コマンドを電子マネーカード７に送信して電子マネーカード７の取引状態を「取引完了」に復帰させ、前記取引中コマンド又は取引完了コマンドを送信する際に、演算コマンドも送信し、電子マネーカード７に取引中コマンドを送信してから、電子マネーカード７の取引状態が「取引完了」に復帰したことを確認するまでの間に、センタサーバ２の取引状態を反転又は復帰させ、その際にセンタサーバ２残高更新を確定すればよい。
以上の範囲内で、電子マネーシステム１は、各種変形可能である。

以上に説明した電子マネーシステム１により、次のような効果を得ることができる。
（１）電子マネーカード７とセンタサーバ２の取引状態の組合せから、発生した障害を特定することができる。
（２）取引状態の組合せから障害の種類を特定するため、オンライン端末５とオフライン端末６が混在した電子マネーシステム１（バリュー残高が電子マネーカード７とセンタサーバ２で必ずしも一致しない）で障害の種類を特定することができる。

（３）支払い処理の場合は、電子マネーカード７で減算した後、センタサーバ２の取引情報を更新し、入金処理の場合は、センタサーバ２で取引情報を更新した後電子マネーカード７で加算処理するため、何れの場合も電子マネーカード７へは加算処理にて回復処理を行うことができる。
（４）電子マネーカード７での処理が終了していない場合は、取引状態が「取引中」に設定されるため、オフライン端末６にて未回復カードを識別することができる。
（５）オフライン端末６は、未回復カードへの入金機能が制限されているため、バリュー残高限度を超えて電子マネーカード７に入金されることを防ぐことができる。

以上、本実施の形態の一例について説明したが、各種の変形が可能である。
例えば、オンライン端末５を、インターネット接続可能なパーソナルコンピュータにより構成し、顧客の自宅に設置しても良い。この場合、顧客は自宅の通信で電子マネーカード７の処理に障害が発生したことに気づかずに加盟店１０２に行ったとしても、オンライン端末５にて障害を回復することができる。

また、本実施の形態では、センタサーバ２が加算コマンド、減算コマンドを電子マネーカード７に送信し、電子マネーカード７はこれらコマンドを実行して記憶している残高を更新したが、残高の演算はセンタサーバ２で行うように構成することもできる。

この場合、センタサーバ２は、電子マネーカード７が記憶している残高を電子マネーカード７から取得し、これに加減算処理を行って加減算処理後の金額を算出する。
そして、センタサーバ２は、算出した金額を電子マネーカード７に送信し、電子マネーカード７は、記憶している残高をセンタサーバ２から受信した金額に更新する。

このように、加減算処理は、センタサーバ２で行っても電子マネーカード７で行ってもよく、あるいは、加算に関してはセンタサーバ２で行い、減算に関しては電子マネーカード７で行うというように、加減算の一方をセンタサーバ２で行い、他方を電子マネーカード７で行うように構成することもできる。

センタサーバ２が加算コマンド、減算コマンドを電子マネーカード７に送信し、電子マネーカード７で加減算を行う場合、加算コマンド、減算コマンドは金額変更情報を構成している。
センタサーバ２が加減算後の金額を計算し、電子マネーカード７がこれを用いて金額を更新する場合、センタサーバ２が電子マネーカード７に送信する加減算後の金額が金額変更情報に該当する。

このように、センタサーバ２が送信した金額変更情報によって電子マネーカード７の残高が増減されるとした場合、バリュー処理部７ａは、金額変更情報を用いて残高金額を金額変更処理する金額変更手段を構成している。
また、センタサーバ２は、演算コマンドや演算後の金額などの金額変更情報を送信する金額変更情報送信手段を備えている。

更に、オフライン端末６は、金額変更情報入力装置を構成している。
即ち、オフライン端末６は、ステップ９０４にて入金額を取得するが、これは増額金額を取得する増額金額取得手段を構成している。
また、オフライン端末６は、ステップ８０６にて入金処理を行うが、これは入力された増額金額分の貨幣価値を増額する金額変更情報を生成する金額変更情報生成手段を構成している。

更に、オフライン端末６は、電子マネーカード７の取引状態が「取引完了」であった場合は生成した金額変更情報を電子マネーカード７に入力し、「取引中」であった場合は金額変更情報の入力を制限する金額変更情報入力手段を備えている。

１ 電子マネーシステム
２ センタサーバ
５ オンライン端末
６ オフライン端末
１００ 電子マネーセンタ
１０２ 加盟店

Claims (7)

1. 貨幣端末と情報処理サーバとの間で行われるオンライン取引をリアルタイムで仲介するオンライン端末と、貨幣端末との間で行われたオフライン取引に係る情報をバッチ処理にて情報処理サーバに送信するオフライン端末と、を含む情報処理システムにおけるオフライン端末であって、
   支払又は入金に係る取引金額を取得する取引金額取得手段と、
   前記取得される取引金額分の金額変更情報を生成する金額変更情報生成手段と、
   前記生成される金額変更情報を前記貨幣端末に出力する金額変更情報出力手段と、
   貨幣価値の残高金額を電子データとして記憶する残高記憶手段と、所定の金額変更情報を用いて前記残高金額に対する変更処理を実行する金額変更手段と、少なくとも前記金額変更手段による直近のオンライン取引に係る変更処理について該変更処理が完了しているか否かを示す状態データを記憶する状態データ記憶手段と、前記変更処理が完了していないオンライン取引に係る取引金額を示す未完了取引金額を少なくとも含む過去の取引に係る取引金額を記憶する取引金額記憶手段と、を備える前記貨幣端末から、前記状態データ記憶手段に記憶される状態データを取得する状態データ取得手段と、
   前記取得される取引金額が入金に係る取引金額でありかつ前記取得される状態データが未完了を示す場合に限り、該入金に係るオフライン取引を制限するか否かを、前記取引金額記憶手段に記憶される前記未完了取引金額分の回復処理が前記情報処理サーバにより後に実施されることを見越し、前記取得される入金に係る取引金額に応じて決定する決定手段と、
   前記決定手段により前記入金に係るオフライン取引を制限することが決定された場合に、該オフライン取引を途中で停止させる取引制限手段と、
   を具備したことを特徴とするオフライン端末。
   
2. 前記決定手段が、前記入金に係るオフライン取引を制限するか否かを、前記残高記憶手段に記憶される残高金額に前記未完了取引金額を加算した後の金額に対し前記取得される入金に係る取引金額分の変更処理が可能であるか否かを基準として決定する、
   ことを特徴とする請求項１記載のオフライン端末。
   
3. 前記残高記憶手段に記憶される残高金額には、上限値が設けられており、
   前記決定手段が、前記残高記憶手段に記憶される残高金額に前記未完了取引金額分の加算処理を実施した後の金額に対し前記取得される入金に係る取引金額を加算した金額が前記上限値を上回るとき、前記入金に係るオフライン取引を制限する旨を決定する、
   ことを特徴とする請求項２記載のオフライン端末。
   
4. 前記貨幣端末から前記残高記憶手段に記憶される残高金額を取得する残高金額取得手段と、
   前記取得される状態データが未完了を示す場合に限り、前記貨幣端末から前記取引金額記憶手段に記憶される前記未完了取引金額を取得する未完了取引金額取得手段と、
   をさらに備える、ことを特徴とする請求項１から請求項３までのいずれか１項に記載のオフライン端末。
   
5. 前記オンライン取引及び前記オフライン取引に係る取引金額を直近の取引に係るものから所定数だけ記憶する前記取引金額記憶手段に、入金又は支払に係るオフライン取引に係る取引金額を新たに記憶させる手段をさらに具備する、
   ことを特徴とする請求項１から請求項４までのいずれか１項に記載のオフライン端末。
   
6. 貨幣端末と情報処理サーバとの間で行われるオンライン取引をリアルタイムで仲介するオンライン端末と、貨幣端末との間で行われたオフライン取引に係る情報をバッチ処理にて情報処理サーバに送信するオフライン端末と、を含む情報処理システムにおけるオフライン端末であって、
   支払又は入金に係る取引金額を取得する取引金額取得手段と、
   前記取得される取引金額分の金額変更情報を生成する金額変更情報生成手段と、
   前記生成される金額変更情報を前記貨幣端末に出力する金額変更情報出力手段と、
   を具備するオフライン端末を構成するコンピュータに、
   貨幣価値の残高金額を電子データとして記憶する残高記憶手段と、所定の金額変更情報を用いて前記残高金額に対する変更処理を実行する金額変更手段と、少なくとも前記金額変更手段による過去のオンライン取引に係る変更処理について該変更処理が完了しているか否かを示す状態データを記憶する状態データ記憶手段と、前記変更処理が完了していないオンライン取引に係る取引金額を示す未完了取引金額を少なくとも含む過去の取引に係る取引金額を記憶する取引金額記憶手段と、を備える前記貨幣端末から、前記状態データ記憶手段に記憶される状態データを取得する状態データ取得処理と、
   前記取得される取引金額が入金に係る取引金額でありかつ前記取得される状態データが未完了を示す場合に限り、該入金に係るオフライン取引を制限するか否かを、前記取引金額記憶手段に記憶される前記未完了取引金額分の回復処理が前記情報処理サーバにより後に実施されることを見越し、前記取得される入金に係る取引金額に応じて決定する決定処理と、
   前記決定処理において前記入金に係るオフライン取引を制限することが決定された場合に、該オフライン取引を途中で停止させる取引制限処理と、
   を実行させる、オフライン端末の制御方法。
   
7. 貨幣端末と情報処理サーバとの間で行われるオンライン取引をリアルタイムで仲介するオンライン端末と、貨幣端末との間で行われたオフライン取引に係る情報をバッチ処理にて情報処理サーバに送信するオフライン端末と、を含む情報処理システムにおけるオフライン端末であって、
   支払又は入金に係る取引金額を取得する取引金額取得手段と、
   前記取得される取引金額分の金額変更情報を生成する金額変更情報生成手段と、
   前記生成される金額変更情報を前記貨幣端末に出力する金額変更情報出力手段と、
   を具備するオフライン端末を構成するコンピュータに、
   貨幣価値の残高金額を電子データとして記憶する残高記憶手段と、所定の金額変更情報を用いて前記残高金額に対する変更処理を実行する金額変更手段と、少なくとも前記金額変更手段による過去のオンライン取引に係る変更処理について該変更処理が完了しているか否かを示す状態データを記憶する状態データ記憶手段と、前記変更処理が完了していないオンライン取引に係る取引金額を示す未完了取引金額を少なくとも含む過去の取引に係る取引金額を記憶する取引金額記憶手段と、を備える前記貨幣端末から、前記状態データ記憶手段に記憶される状態データを取得する状態データ取得機能と、
   前記取得される取引金額が入金に係る取引金額でありかつ前記取得される状態データが未完了を示す場合に限り、該入金に係るオフライン取引を制限するか否かを、前記取引金額記憶手段に記憶される前記未完了取引金額分の回復処理が前記情報処理サーバにより後に実施されることを見越し、前記取得される入金に係る取引金額に応じて決定する決定機能と、
   前記決定機能により前記入金に係るオフライン取引を制限することが決定された場合に、該オフライン取引を途中で停止させる取引制限機能と、
   を実現させる、オフライン端末の制御プログラム。

Images