貨幣端末処理サーバ、貨幣端末処理方法、貨幣端末、演算命令入力装置、及び金額変更情報入力装置
【課題】オンライン端末とオフライン端末が混在した電子マネーシステムにおいて、適切に障害回復を行うことを目的とする。
【解決手段】電子マネーカードとセンタサーバの双方に、「取引中」及び「取引完了」の2つの値を選択的に設定できるフラグを用意する。そして、電子マネーカードとセンタサーバ間で情報処理を行う過程で、双方のフラグを立てたり(「取引完了」から「取引中」に反転させたり)、あるいは倒したり(「取引中」から「取引完了」に復帰させたり)して同期を取りながら処理を進める。処理の途中で障害が発生した場合、障害が発生した時点でのフラグの状態が両者で保存されているため、これらの状態から障害が発生した時点を特定することができる。
【解決手段】電子マネーカードとセンタサーバの双方に、「取引中」及び「取引完了」の2つの値を選択的に設定できるフラグを用意する。そして、電子マネーカードとセンタサーバ間で情報処理を行う過程で、双方のフラグを立てたり(「取引完了」から「取引中」に反転させたり)、あるいは倒したり(「取引中」から「取引完了」に復帰させたり)して同期を取りながら処理を進める。処理の途中で障害が発生した場合、障害が発生した時点でのフラグの状態が両者で保存されているため、これらの状態から障害が発生した時点を特定することができる。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、貨幣端末処理サーバ、貨幣端末処理方法、貨幣端末、演算命令入力装置、及び金額変更情報入力装置に関し、例えば、ICカードに記憶した電子マネーを処理するものに関する。
【背景技術】
【0002】
近年、一般の小売店や消費者の協力を得て行われた電子マネー(電子現金)の大規模な実用化実験が成功裡に終わり、我が国は電子マネー時代の到来を迎えつつある。
現在実用化されている電子マネーシステムは、例えば、非接触型ICカードで構成された電子マネーカードに貨幣価値の金額を記憶させるものである。
電子マネーカードは、CPU(中央処理装置:Central Processing Unit)を備えており、これに加算コマンドや減算コマンド(以下、演算コマンド)を入力して実行させることにより、カード内の貨幣価値の金額を増減することができる。カード内の貨幣価値はバリューと呼ばれる電子情報で表される。
【0003】
電子マネーを用いて商品・サービスなどの提供を行う事業者は、電子マネーシステムの主催者(以下、電子マネーセンタ)に登録して加盟店を形成し、電子マネーカードにアクセスするための取引端末を備えている。加盟店は、現金の授受の代わりに、この取引端末を用いて顧客の電子マネーカード内のバリュー残高を増減させて商取引を行う。
【0004】
取引端末には、電子マネーセンタのサーバ装置(センタサーバ)とオンライン接続されたオンライン端末と、バッチ処理にて一日数回程度センタサーバと接続するオフライン端末がある。
例えば、オンライン端末は、ブロードバンドなどの高速通信が行えるネットワーク環境において利用され、オフライン端末は、高速通信が行えない場合に利用される。
【0005】
電子マネーシステムが実用化した当初は取引端末としてオフライン端末が採用されていたが、今日はネットワークのブロードバンド化が進展し、次第にオンライン端末に置き換えられるようになってきている。しかし、未だオンライン端末を設置するのが困難な場所があり、現在の電子マネーシステムはオフライン端末とオンライン端末が混在した形となっている。
【0006】
オンライン端末は、電子マネーカードとセンタサーバとの通信の仲介を行い、これによって、センタサーバは、電子マネーカードに所定の演算命令を送信する。電子マネーカードは、この演算命令を実行して電子マネーカード内のバリューの金額を増減する。
【0007】
これに対し、オフライン端末は、オフラインで電子マネーカードに演算コマンドを入力してカード内のバリューの金額を増減させ、その取引情報をログデータとして蓄積する。そして、一日数回程度バッチ処理にてこれらをまとめてセンタサーバに送信する。
【0008】
電子マネーセンタは、オンライン端末との取引情報と、オフライン端末から受信した取引情報を集計し、その集計結果に応じて加盟店の銀行口座に対して現金の移動を行う。
このように、電子マネーセンタは取引情報を用いてバリューによる交換価値の移動と実際の現金との対応関係をとっている。
このように電子マネーを用いた技術に以下のものがある。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開2003−141428号公報
【0010】
この技術は、ユーザが携行する非接触型ICカードに貨幣的な価値を記憶させてこれを加減算することにより電子マネーを流通させるものである。
【発明の概要】
【発明が解決しようとする課題】
【0011】
オフライン端末の場合、オフライン端末と電子マネーカードとの間での通信で処理が完結するため、通信時間が短時間(例えば0.1秒程度)で済み、更に通信経路も短いため、電子マネーカードの処理中に障害が生じる可能性についてはほとんど考慮する必要がなかった。
しかし、オンライン端末を用いると、電子マネーカードとセンタサーバが通信を行うために通信時間が延び(例えば、1秒程度)、通信経路も複雑で長距離のものとなるため、電子マネーカードの処理中に障害が生じる可能性を考慮する必要が生じてくる。
【0012】
そして、障害が発生してこれを回復する場合、オンライン端末とオフライン端末が混在しているために、電子マネーカードでのバリュー残高とセンタサーバで記録しているバリュー残高の一致がとれない場合があり(電子マネーカードでの情報は常に最新情報となるが、センタサーバでの情報は、全てのオフライン端末から情報を受信するまで最新状態に更新されない)バリュー残高を用いて回復処理を行うことはできない。
【0013】
更に、ユーザの利便性の観点から、障害の発生によりセンタサーバと電子マネーカードのバリュー残高に不一致が生じてこれを回復する場合、ユーザの電子マネーカードに対するバリュー残高の修正が少なくとも減算処理とならない(即ち、電子マネーカードのバリュー残高は変わらないかあるいは加算される)ような回復システムを構築する必要がある。
【0014】
そこで、本発明の目的は、オンライン端末を用いた電子マネーシステムにおいて、適切に障害回復を行うことができる貨幣端末処理サーバ、貨幣端末処理方法、貨幣端末、演算命令入力装置、及び金額変更情報入力装置を提供することである。
【課題を解決するための手段】
【0015】
本発明は、前記目的を達成するために、請求項1に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、前記貨幣端末から残高金額を受信する残高受信手段と、前記貨幣端末に対する演算命令の送信要求を取得する要求取得手段と、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信手段と、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、を具備したことを特徴とする貨幣端末処理サーバを提供する。
請求項2に記載の発明では、前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記演算処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、を具備したことを特徴とする請求項1に記載の貨幣端末処理サーバを提供する。
請求項3に記載の発明では、前記演算命令として減算命令を送信する場合、前記残高更新手段は、前記貨幣端末での前記減算命令の実行を確認した後に前記残高金額を更新し、前記演算命令として加算命令を送信する場合、前記演算命令送信手段は、前記残高金額を更新した後に前記加算命令を送信し、前記回復手段は、前記貨幣端末で当該減算命令が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減算した分の金額を加算させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で当該加算命令を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に加算させることにより回復処理を行うことを特徴とする請求項2に記載の貨幣端末処理サーバを提供する。
請求項4に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う貨幣情報処理方法であって、前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、演算命令送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、前記要求取得手段によって、前記貨幣端末に対する演算命令の送信要求を取得する要求取得ステップと、前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、前記演算命令送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信ステップと、前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、から構成されたことを特徴とする貨幣端末処理方法を提供する。
請求項5に記載の発明では、請求項1の貨幣端末処理サーバが演算命令を送信する貨幣端末であって、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、所定の演算命令を実行して前記残高金額を演算処理する演算手段と、端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、を具備したことを特徴とする貨幣端末を提供する。
請求項6に記載の発明では、請求項5に記載の貨幣端末に前記加算命令を入力する演算命令入力装置であり、加算金額を取得する加算金額取得手段と、前記取得した加算金額分の貨幣価値を加算する加算命令を生成する加算命令生成手段と、前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、前記端末フラグが初期状態であった場合は、前記生成した加算命令を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記加算命令の前記貨幣端末への入力を制限する加算命令入力手段と、を具備したことを特徴とする演算命令入力装置を提供する。
請求項7に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、前記貨幣端末から残高金額を受信する残高受信手段と、前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得手段と、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信手段と、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、を具備したことを特徴とする貨幣端末処理サーバを提供する。
請求項8に記載の発明では、前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記金額変更処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、を具備したことを特徴とする請求項7に記載の貨幣端末処理サーバを提供する。
請求項9に記載の発明では、前記金額変更情報として金額を減額する金額変更情報を送信する場合、前記残高更新手段は、前記貨幣端末での金額変更処理の実行を確認した後に前記残高金額を更新し、前記金額変更情報として金額を加算する金額変更情報を送信する場合、前記金額変更情報送信手段は、前記残高金額を更新した後に前記金額変更情報を送信し、前記回復手段は、前記貨幣端末で金額を減額する金額変更処理が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減額した分の金額を増額させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で金額を増額する金額変更処理を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に増額させることにより回復処理を行うことを特徴とする請求項8に記載の貨幣端末処理サーバを提供する。
請求項10に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う情報処理方法であって、前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、金額変更情報送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、前記要求取得手段によって、前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得ステップと、前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、前記金額変更情報送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信ステップと、前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、から構成されたことを特徴とする貨幣端末処理方法を提供する。
請求項11に記載の発明では、請求項7の貨幣端末処理サーバが金額変更情報を送信する貨幣端末であって、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、所定の金額変更情報を用いて前記残高金額を金額変更処理する金額変更手段と、端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、を具備したことを特徴とする貨幣端末を提供する。
請求項12に記載の発明では、請求項11に記載の貨幣端末に前記残高金額を増額する金額変更情報を入力する金額変更情報入力装置であり、前記増額金額を取得する増額金額取得手段と、前記取得した増額金額分の貨幣価値を増額する金額変更情報を生成する金額変更情報生成手段と、前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、前記端末フラグが初期状態であった場合は、前記生成した金額変更情報を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記金額変更情報の前記貨幣端末への入力を制限する金額変更情報入力手段と、を具備したことを特徴とする金額変更情報入力装置を提供する。
【発明の効果】
【0016】
本発明によると、オンライン端末とオフライン端末が混在した電子マネーシステムにおいて、適切に障害回復を行うことができる。
【図面の簡単な説明】
【0017】
【図1】フラグの設定手順の概要を説明するための図である。
【図2】電子マネーシステムの構成を示したブロック図である。
【図3】電子マネーカードのハードウェア的な構成を表したブロック図である。
【図4】センタサーバのハードウェア的な構成を示したブロック図である。
【図5】取引情報の一例を示した図である。
【図6】支払い処理の手順を説明するためのフローチャートである。
【図7】障害1が発生した場合の処理手順を説明するためのフローチャートである。
【図8】障害2、及び障害3が発生した場合の処理手順を説明するためのフローチャートである。
【図9】障害2が発生した場合の回復処理手順を説明するためのフローチャートである。
【図10】障害3が発生した場合の回復処理手順を説明するためのフローチャートである。
【図11】障害4、及び障害5が発生した場合の処理手順を説明するためのフローチャートである。
【図12】障害4が発生した場合の回復処理手順を説明するためのフローチャートである。
【図13】障害5が発生した場合の回復処理手順を説明するためのフローチャートである。
【図14】入金処理の手順を説明するためのフローチャートである。
【図15】障害6が発生した場合の処理手順を説明するためのフローチャートである。
【図16】障害7、及び障害8が発生した場合の処理手順を説明するためのフローチャートである。
【図17】障害7が発生した場合の回復処理手順を説明するためのフローチャートである。
【図18】障害8が発生した場合の回復処理手順を説明するためのフローチャートである。
【図19】障害9、及び障害10が発生した場合の処理手順を説明するためのフローチャートである。
【図20】障害9が発生した場合の回復処理手順を説明するためのフローチャートである。
【図21】オフライン端末で電子マネーカードに入金を行う手順を説明するためのフローチャートである。
【図22】オンライン端末に表示される画面を説明するための図である。
【図23】障害回復を行うために必要な条件を説明するための図である。
【発明を実施するための形態】
【0018】
(実施の形態の概要)
電子マネーカードとセンタサーバの双方に、「取引中」及び「取引完了」の2つの値を選択的に設定できるフラグを用意する。
そして、電子マネーカードとセンタサーバ間で情報処理を行う過程で、双方のフラグを立てたり(「取引完了」から「取引中」に反転させたり)、あるいは倒したり(「取引中」から「取引完了」に復帰させたり)して同期をとりながら処理を進める。
処理の途中で障害が発生した場合、障害が発生した時点でのフラグの状態が両者で保存されているため、これらの状態から障害が発生した時点を特定することができる。
そして、その特定した時点に応じた回復処理を行う。
【0019】
また、電子マネーカードで演算処理を行うタイミングとセンタサーバ側で残高記録を更新するタイミングの時間的順序を減算処理と加算処理の場合で逆にすることにより、電子マネーカードに対する復帰処理が少なくとも加算処理となるように構成することができる。
【0020】
即ち、電子マネーカードで減算処理を行う場合は、まず、電子マネーカードで減算処理を行った後、センタサーバでの残高記録の減算処理を行い、電子マネーカードで加算処理を行う場合は、逆にまずセンタサーバ側で加算処理を行った後に、電子マネーカードで残高記録の加算処理を行う。
このように構成すると、電子マネーカードで減算処理した後、センタサーバで残高記録の減算処理を行う前に障害が生じた場合は、電子マネーカードに減算した金額分を加算して残高を減算処理前の状態に回復し、また、センタサーバで残高記録の加算処理を行って電子マネーカードで加算処理を行う前に障害が生じた場合は、電子マネーカードに加算処理を行わせて両者の整合性をとることができる。
【0021】
図1(a)を用いて、一例に係るフラグの設定手順の概要を説明する。
まず、センタサーバでは、センタ側フラグが取引完了(初期状態)に設定されており、これを取引中(反転状態)に設定した後、電子マネーカードに取引中コマンド(反転命令)を送信する(ステップ1)。
電子マネーカードは、この取引中コマンドを受信して実行し、端末フラグ(カード側のフラグ)を取引中に設定する。そして、センタサーバに対して取引中設定通知を送信する(ステップ2)。
【0022】
センタサーバは、取引中設定通知を受信した後、サーバフラグを取引中から取引完了に設定する。そして、その後電子マネーカードに取引完了コマンド(復帰命令)を送信する(ステップ3)。
電子マネーカードは、センタサーバから取引完了コマンドを受信して実行し、端末フラグを取引完了に設定する。そして、その後取引完了設定通知をセンタサーバに送信する(ステップ4)。センタサーバはこれを受信する。
【0023】
以上のように設定したフラグを用いると、ステップ1〜ステップ4の何れかで障害が発生した場合、どのステップで障害が発生したかをフラグの組合せから特定することができる。
例えば、端末フラグが「取引中」でサーバフラグも「取引中」の場合はステップ2で障害が発生したことになる。
また、端末フラグが「取引中」でサーバフラグが「取引完了」である場合はステップ3で障害が発生したことになる。
【0024】
以下同様に、ステップ1で障害が生じた場合は、端末フラグが「取引完了」でサーバフラグが「取引中」となり、ステップ4で障害が生じた場合は、端末フラグとサーバフラグが共に「取引完了」になる。
即ち、フラグの組合せは合計4通りあり、これを各ステップに対応させたのである。
【0025】
そして、センタサーバが、フラグの設定コマンド(取引中コマンド、又は取引完了コマンド)と演算コマンドを共に電子マネーカードに送信し、電子マネーカードがフラグの設定と演算の実行を共に行うように構成すると、電子マネーカード側の情報とセンタサーバ側の情報を同期しながら更新することができる。
【0026】
例えば、電子マネーカードで減算処理を行う場合、図1(b)に示したように、ステップ1において取引中コマンドと減算コマンドを送信する。電子マネーカードはこの減算コマンドを受信して実行した後、ステップ2において減算完了通知(取引中設定通知を兼ねている)をセンタサーバに送信する。
センタサーバは、電子マネーカードから減算完了通知を受信したのち、当該電子マネーカードの残高記録を減算する。その後、ステップ3、4の処理が行われる。
【0027】
以上の手順で電子マネーカードのバリュー残高と、センタサーバでの残高記録に不一致が生じるのは、ステップ2で通信障害が生じた場合である。即ち、端末フラグと、サーバフラグが共に「取引中」である場合、電子マネーカードでは、減算処理が行われたがセンタサーバ側では残高記録の減算処理が行われなかったことがわかる。
従って、減算処理中に障害が発生し、端末フラグとサーバフラグが共に「取引中」である場合、電子マネーカードに減算した金額を加算する加算コマンドを送信して実行させると、減算処理前の状態に回復することができる。
【0028】
同様に、電子マネーカードで加算処理を行う場合、図1(c)に示したように、ステップ1、2の処理を行った後、ステップ3において、取引完了コマンドと加算コマンドを送信する。電子マネーカードはこの加算コマンドを受信して実行した後、ステップ4において加算完了通知(取引完了設定通知を兼ねている)をセンタサーバに送信する。
【0029】
以上の手順で電子マネーカードの残高と、センタサーバでの残高記録に不一致が生じるのは、ステップ3で通信障害が生じた場合である。即ち、端末フラグが「取引中」で、サーバフラグが「取引完了」である場合、センタサーバ側では残高記録の加算処理が行われたが、電子マネーカードでは加算処理が行われなかったことがわかる。
従って、加算処理中に障害が発生し、端末フラグが「取引中」でサーバフラグが「取引完了」である場合、電子マネーカードに加算コマンドを送信して実行させると、加算処理後の状態に回復することができる。
【0030】
(実施の形態の詳細)
電子マネーによる商取引では、金銭と同等の交換価値を付与したバリューと呼ばれる電子情報の値を加減することにより交換価値の移動を生じさせる。
バリューは、バリュー処理機能を有するICカードである電子マネーカードに記憶されて利用者に携帯される。
バリューを用いた商品・サービスの購入は、バリューによる商取引を行う契約を結んでいる加盟店で行うことができる。
【0031】
加盟店は、店頭に電子マネーカードにアクセスする加盟店端末を設置しており、利用者の電子マネーカードに記憶されているバリューを代金分だけ減算して支払いを行う(決済とも呼ばれる)。
また、加盟店に金銭を支払い、その金額分のバリューを電子マネーカードに書き込んでもらうこともできる。このように電子マネーカードにバリューを書き込む処理は入金(又はチャージ)と呼ばれている。
この加盟店端末には、電子マネーカードセンタのセンタサーバとオンライン接続されているオンライン端末と、バッチ処理にてログデータを一括してセンタサーバに送信するオフライン端末がある。
【0032】
図2は、本実施の形態の電子マネーシステムの構成を模式的に示したブロック図である。
電子マネーシステム1は、電子マネーセンタ100に設置されたセンタサーバ2、各加盟店102に設置されたオンライン端末5、5、5、…、オフライン端末6、センタサーバ2とオンライン端末5、5、5、…、及びオフライン端末6、6、6、…をネットワーク接続するネットワーク4、及びオンライン端末5、及びオフライン端末6と近距離の無線通信を行う電子マネーカード7を用いて構成されている。
【0033】
電子マネーセンタ100は、電子マネーシステム1の運営維持管理を行う事業体であり、センタサーバ2(貨幣端末処理サーバ)を運用している。
センタサーバ2は、オンライン端末5と常時接続されており、リアルタイムでオンライン端末5と通信でき、オンライン端末5からの要求に従って演算コマンド(演算命令)を生成して送信することができる。
なお、本実施の形態では、センタサーバ2とオンライン端末5、5、5、…を常時接続することとするが、これに限定するものではなく、例えば、必要に応じて(電子マネーカード7に各種コマンドを入力する必要がある時点など)オンライン端末5をセンタサーバ2に接続するように構成することもできる。
【0034】
また、センタサーバ2は、例えば1日1回程度、オフライン端末6が電子マネーカード7に対して行った処理に関する取引情報をまとめて受信する。
更に、オフライン端末6にはネットワーク4に接続されないものもあり、これに関しては電子マネーセンタ100の担当者が、オフライン端末6から取引情報が記憶された記憶媒体を回収し、これをセンタサーバ2に入力する。
【0035】
加盟店102は、例えば、コンビニエンスストアやレストランなど、商品やサービスを顧客に提供する店舗であって、これら商品やサービスの対価としてバリューを使用することができるものである。
加盟店102は、例えばレジにオンライン端末5やオフライン端末6を備えており、これを用いて顧客の電子マネーカード7から対価分のバリューを減算して支払いを行う。また、顧客から代金を受領して、その金額分のバリューを電子マネーカード7に入金することもできる。
本実施の形態では、オンライン端末5にて支払い、入金の双方を行うことができるものとするが、支払いと入金の何れか一方を行うように構成することもできる。
【0036】
オンライン端末5は、端末コンピュータ5aとリーダライタ5bから構成されている。
端末コンピュータ5aは、所定のコンピュータプログラムをリーダライタ5bを備えた汎用のコンピュータにインストールして構成することもできるし、あるいは、専用モジュールを組み込んだ専用機を用いて構成することも可能である。
リーダライタ5bは、端末コンピュータ5aの周辺機器であり、電子マネーカード7と近距離の無線通信を行うためのアンテナを内蔵している。
【0037】
端末コンピュータ5aは、リーダライタ5bを介して電子マネーカード7に接続し、センタサーバ2から送信されてきた演算コマンドを電子マネーカード7に入力することができる。
これに対し、オフライン端末6は、自ら演算コマンドを生成し、電子マネーカード7に入力する。
図示しないが、オフライン端末6にはリーダライタ5bが内蔵されており、オフラインで電子マネーカード7に対して処理を行った後、その処理内容を記録した取引情報を1日1回程度ネットワーク4を介してセンタサーバ2に送信する。
【0038】
電子マネーカード7は、バリュー処理機能が組み込まれた非接触型ICカードで構成された貨幣端末である。
電子マネーカード7は、バリュー処理機能を行うICチップと、リーダライタ5bと無線通信を行うためのアンテナを備えている。
電子マネーカード7は、バリュー残高金額を記憶しており、リーダライタ5bから入力された加算コマンドや減算コマンドを実行してバリューの金額を加減算する。
【0039】
図2は電子マネーカード7の機能的な構成も示しており、図示したように電子マネーカード7は、バリュー処理部7a、残高記憶部7b、ログデータ記憶部7c、カードID記憶部7d、取引状態保持部7eなどを備えている。
残高記憶部7bは、バリュー残高を記憶する記憶部である。支払いや入金の際は、残高記憶部7bに記憶されてるバリューの金額を増減する。残高記憶部7bは、貨幣価値の金額を電子データ(バリュー)として記憶する貨幣情報記憶手段を構成している。
【0040】
ログデータ記憶部7cは、取引履歴をログデータとして記憶する記憶部である。取引履歴としては、例えば取引日時、取引を行った加盟店端末のID情報、支払い又は入金の別、取引額などがある。
取引履歴は、例えば6件まで記憶され、古いものから順次消去されるようになっている。
【0041】
カードID記憶部7dは、カードIDを記憶した記憶部である。カードIDは、電子マネーシステム1において電子マネーカード7に一意に与えられたID情報であって、電子マネーセンタ100は、カードIDにより電子マネーカード7を特定することができる。
なお、カードIDは、電子マネーセンタ100が電子マネーカード7に付与したものであるが、このほかに、電子マネーカード7の製造メーカが電子マネーカード7に付与したID情報を用いてもよい。
何れのID情報も電子マネーカード7に記憶されており、カードIDコマンドを電子マネーカード7に入力することによりこれらID情報を読み出すことができる。
【0042】
取引状態保持部7eは、取引状態を記憶する記憶部である。取引状態は、電子マネーカード7側での処理が終了したか否かを表すフラグ情報であり、端末フラグを構成している。
取引状態は、「取引中」(反転状態に対応)、「取引完了」(初期状態に対応)の2値を選択的にとることができる。ここで、取引状態保持部7eは、端末フラグ記憶手段を構成している。
【0043】
取引状態は、電子マネーカード7での処理が完了するまでは「取引中」に設定され、処理が完了すると「取引完了」に復帰させられる。
これら「取引中」と「取引完了」の設定は、後述のバリュー処理部7aが、センタサーバ2から送信されてきた取引中コマンド(反転命令に対応)と取引完了コマンド(復帰命令に対応)を実行することにより行われる。ここで、バリュー処理部7aはフラグ命令実行手段に対応している。
取引状態保持部7eに記憶されている取引状態は、センタサーバ2と電子マネーカード7の間の通信障害の発生時点を判断するのに用いられる。
【0044】
バリュー処理部7aは、リーダライタ5bから入力される各種コマンドを実行する中央演算処理部であり、演算手段を構成している。
バリュー処理部7aは、加算コマンド、又は減算コマンドの入力を受け付けた場合、これらコマンドにパラメータとして付属している金額分だけ残高記憶部7bのバリューを加算、又は減算する。
そして、バリュー処理部7aは、情報処理を行った場合、ログデータ記憶部7cの取引履歴を更新する。
【0045】
本実施の形態では、電子マネーカード7は、ネットワーク4、端末コンピュータ5a、及びリーダライタ5bから成る経路を経由してセンタサーバ2と電子マネーカード7が通信を行うが、この通信は暗号化されており、電子マネーカード7は、このための暗号化及び復号化を行う機能も備えている。
【0046】
ネットワーク4は、例えばインターネットによって構成されており、センタサーバ2とオンライン端末5、及びオフライン端末6の間の通信を媒介する。
ネットワーク4は、WAN(Wide Area Network)やLAN(Local Area Network)などで構成してもよく、また、通信衛星を用いた通信回線、電話回線網、光ケーブル網などを用いることもできる。
【0047】
図3は、電子マネーカード7のハードウェア的な構成の一例を模式的に表したブロック図である。
電子マネーカード7は、アンテナ701とICチップ702を内蔵したプラスチックカードである。
本実施の形態では、電子マネーカード7として非接触型ICカードを用いるものとするが、接触型ICカードによって構成することも可能である。この場合、電子マネーカード7は、アンテナ701の代わりにICチップ702にアクセスするための接触端子を備える。加盟店端末もこの接触端子に接続する端子を備え、これら端子を介して電子マネーカード7と加盟店端末が通信を行う。
【0048】
アンテナ701は、リーダライタ5bが備えたアンテナと無線通信を行うための素子である。
アンテナ701は、リーダライタ5bが放射した電波を受信すると共に、リーダライタ5bに対して電波を放射する。
また、アンテナ701は、リーダライタ5bから電力の供給を無線により受け、ICチップ702を駆動するための電力を発電する発電機能も有している。
【0049】
ICチップ702は、ROM(Read Only Memory)703、CPU(Central Processing Unit)704、高周波回路部705、RAM(Random Access Memory)706、記憶部707などの各素子を備えた一種のコンピュータである。これらの素子は1つのICチップの中に形成されている。
【0050】
CPU704は、各種のプログラムに従って情報処理を行ったり、電子マネーカード7全体の動作を制御する中央処理装置である。
ROM703は、電子マネーカード7を機能させるための基本的なプログラム(OS(Operating System)、リーダライタ5bとの通信プログラムなど)や各種データが記憶された読み取り専用メモリである。
【0051】
高周波回路部705は、アンテナ701を介してリーダライタ5bと通信を行うインターフェースである。CPU704は、高周波回路部705を介してリーダライタ5bと無線通信を行うことができる。
RAM706は、読み書き可能な揮発性のメモリであって、CPU704が各種の情報処理を行う際のワーキングエリアを提供する。本実施の形態では、例えば、CPU704が加算コマンドや減算コマンドを実行してバリューの金額を増減する際に使用する。
【0052】
記憶部707は、例えばEEPROM(Electrically Erasable and Programmable ROM)で構成され、CPU704によって情報の読み書きが可能な不揮発性のメモリである。
記憶部707には、各種のアプリケーションソフトを記憶させて(インストールして)これをCPU704に実行させ、各種の機能を電子マネーカード7に発揮させることが可能である。
本実施の形態では、CPU704に電子マネーカード7としての機能を発揮させるためのプログラムであるバリュー処理プログラムを記憶させてある。
【0053】
記憶部707には、バリュー処理プログラムが記憶されているほか、残高記憶部7b、ログデータ記憶部7c、カードID記憶部7d、取引状態保持部7eなどが形成されている。
電子マネーカード7をリーダライタ5bに近接させて駆動すると、CPU704がバリュー処理プログラムを実行し、バリュー処理部7aがソフトウェア的に構成される。これにより、残高記憶部7b、ログデータ記憶部7c、カードID記憶部7d、取引状態保持部7eにアクセスし、各種の情報処理を行うことができる。
【0054】
なお、近年はICチップ702を携帯電話などの携帯端末に内蔵させ、これら携帯端末に非接触型ICカードとしての機能を持たせる試みも行われている。
この利用形態では、ICチップ702とアンテナ701を携帯端末に備え、電子マネーカード7と同様にリーダライタ5bから無線によりアクセスすることができるほか、携帯端末が備えた表示装置にICチップ702内の情報を表示させたり、あるいは携帯端末の入力装置を介してICチップ702に情報を入力することも可能である。
以下、本実施の形態では、電子マネーカード7を用いて説明するが、これらICチップ702を内蔵した携帯端末を用いることもできる。
【0055】
図4は、センタサーバ2のハードウェア的な構成を模式的に表したブロック図である。
センタサーバ2は、制御部10にバスライン32を介して入力装置18、出力装置20、通信制御装置24、記憶装置30、などが接続して構成されている。
【0056】
制御部10は、CPU12、ROM14、RAM16などから構成されている。
CPU12は、ROM14、記憶装置30、その他に記憶されているプログラムをロードして実行する中央処理装置である。本実施の形態では、記憶装置30に記憶されている取引処理プログラムを実行し、センタサーバ2としての機能を発揮する。
【0057】
ROM14は、例えば、CPU12が機能するための基本的な制御を行うための各種プログラム、データ及びパラメータを格納した読み出し専用の不揮発性メモリである。ROM14内のプログラムは、例えば、センタサーバ2の起動時に実行される。
RAM16は、CPU12にワーキングメモリとして使用される読み書き可能なメモリであり、例えば、取引処理プログラムを実行する際に使用される。
【0058】
入力装置18は、例えばキーボード、マウスなどの入力デバイスから構成されている。
出力装置20は、例えばディスプレイなどで構成された表示装置、プリンタなどで構成された印刷装置などから構成されている。
電子マネーセンタ100のオペレータは、これら入力装置18や出力装置20を用いてセンタサーバ2にアクセスし、保守作業やプログラムのアップデートその他の作業を行うことができる。
【0059】
通信制御装置24は、センタサーバ2をネットワーク4に接続するための装置であって、モデム、ターミナルアダプタその他の接続装置によって構成されている。
通信制御装置24はCPU12によって制御され、所定のプロトコルに従って加盟店端末とデータやその他の情報の送受信を行う。
加盟店端末がオンライン端末5の場合は常時接続されており、オフライン端末6の場合は、オフライン端末6がバッチ処理を行う際に接続を受け付ける。
【0060】
記憶装置30は、読み書き可能な記憶媒体と、その記憶媒体に対してプログラムやデータを読み書きするための駆動装置によって構成されている。当該記憶媒体として主にハードディスクが使用されるが、その他に、例えば、光磁気ディスク、磁気ディスク、半導体メモリなどのほかの読み書き可能な記憶媒体によって構成することも可能である。
【0061】
記憶装置30には、各種プログラムを記憶したプログラム格納部34と各種のデータを記憶したデータ格納部36が形成されている。
プログラム格納部34には、OS40、取引処理プログラム42、…などのプログラムがインストールされている。
OS40は、ファイルの入出力や通信制御装置24の制御など、センタサーバ2を動作させる上で基本的な機能を実現するプログラムである。
【0062】
取引処理プログラム42は、センタサーバ2に、オンライン端末5を介して電子マネーカード7と通信し、例えば、以下のような処理を行わせるプログラムである。
(1)支払い処理
これは、電子マネーカード7に記憶されたバリューを商品代金などの支払い代金として決済する処理である。
この場合、センタサーバ2は、オンライン端末5から要求された減算コマンドを電子マネーカード7に送信し、これを電子マネーカード7で実行させる。
また、この際に、電子マネーカード7の取引状態とセンタサーバ2の取引状態の2つのフラグを設定しながら処理を進める。
【0063】
(2)入金処理
これは、電子マネーカード7に入金してバリュー残高を増額するものである。
この場合、センタサーバ2は、オンライン端末5から要求された加算コマンドを電子マネーカード7に送信し、これを電子マネーカード7で実行させる。
この場合も、電子マネーカード7の取引状態とセンタサーバ2の取引状態の2つのフラグを設定しながら処理を進める。
以上のように、センタサーバ2は、演算コマンド(演算命令)を送信する演算命令送信手段を備えている。
【0064】
(3)残高確認処理
これは、電子マネーカード7に記憶されているバリュー残高を提示するものである。
この場合、センタサーバ2は、残高確認コマンドを生成して電子マネーカード7に送信し、これを電子マネーカード7に実行させる。すると、電子マネーカード7は、バリュー残高をセンタサーバ2に送信するので、センタサーバ2は、これをオンライン端末5に表示させる。
また、オンライン端末5が電子マネーカード7に残高確認コマンドを入力し、これに対して電子マネーカード7が返してきたバリュー残高をオンライン端末5が表示するように構成することもできる。
(4)障害発生後の回復処理
これは、センタサーバ2と電子マネーカード7が通信を行っている際に障害が発生し、処理が中断した場合にその回復処理を行うものである。
センタサーバ2は、センタサーバ2及び電子マネーカード7の取引状態の設定状態から障害が発生した時点を判断し、その時点に応じた回復処理を行う。
センタサーバ2は、支払い処理、入金処理、及び残高確認処理を行う前に、センタサーバ2と電子マネーカード7の取引状態から前回の処理で障害が発生したか否かを確認し、障害が発生していた場合はこれを回復してから処理を続行する。このようにセンタサーバ2は、回復手段を備えている。
【0065】
次に、データ格納部36について説明する。
センタサーバ2の運用に必要な各種のデータが記憶されており、データ格納部36には、加盟店端末情報データベース44、取引情報データベース46、…などが記憶されている。
【0066】
加盟店端末情報データベース44は、各加盟店102に設置されたオンライン端末5やオフライン端末6に関する情報を記憶したデータベースである。
加盟店端末情報データベース44には、例えば、加盟店端末が設置されている加盟店102のID情報である加盟店ID、加盟店102内でオンライン端末5やオフライン端末6に設定されたID情報である端末ID、電子マネーシステム1内でオンライン端末5やオフライン端末6に一意に付与されたID情報であるシリアルID…などの情報が記憶されている。
【0067】
センタサーバ2は、加盟店102からシリアルIDを受信すると、当該オンライン端末5、又はオフライン端末6を特定でき、更に加盟店102を特定することができる。
また、オンライン端末5やオフライン端末6を特定するのに端末IDとシリアルIDの2つのID情報を付与したのは、加盟店102の便宜を図るためである。即ち、端末IDは、例えば、加盟店端末の設置順に01、02、…などと加盟店102にとって認識しやすい情報となっており、加盟店102は、加盟店内での管理や故障時の問い合わせを端末IDで行うことができる。
【0068】
取引情報データベース46は、オンライン端末5やオフライン端末6を介して電子マネーカード7に対して行った取引情報を履歴として蓄積するデータベースである。
取引情報は、電子マネーカード7に対して処理を行う際に生成されるログデータであり、オンライン端末5を介して電子マネーカード7を処理する場合はリアルタイムで生成され、オフライン端末6で処理する場合は、一旦オフライン端末6に蓄積された後、バッチ処理などでセンタサーバ2に送られてくる。
【0069】
図5は、オンライン端末5にてカードID「00001」なる電子マネーカード7を処理した場合に生成された取引情報61、62、63を時系列にて並べて示した図である。
図に示したように、取引情報はカードID52、残高53、取引額54、取引状態55、処理内容56、シリアルID57、取引日時58、…などの各項目から構成されている。
カードID52は、オンライン端末5を介して電子マネーカード7から受信したカードIDである。
【0070】
残高53は、電子マネーカード7の演算処理後のバリュー残高であり、取引額54は、演算の際に加減算した金額である。
センタサーバ2は、支払い、又は入金処理の際に電子マネーカード7からバリュー残高を受信すると共に(残高受信手段に対応)、オンライン端末5から演算コマンドの送信要求(加減算する金額が付属している)を取得する(要求取得手段に対応)。残高53は、これらの値を用いて計算されたものである。
【0071】
取引状態55は、「取引中」(反転状態に対応)と「取引完了」(初期状態に対応)のうちの何れかが選択的に設定されるフラグ情報であり、サーバフラグを構成している。
取引状態55は、センタサーバ2側の処理が開始した際に「取引中」に設定され、センタサーバ2側の処理が完了した際に「取引完了」に更新される。
【0072】
このように、センタサーバ2は、取引状態55を「取引完了」から「取引中」に反転させたり、あるいは「取引中」から「取引完了」に復帰させるサーバフラグ設定手段を備えている。
図5の例では、図中上から3番目の取引情報は取引状態55が「取引中」となっており、この取引情報に関するセンタサーバ2側の処理はまだ完了していないことがわかる。
【0073】
シリアルID57は、電子マネーカード7との通信を仲介しているオンライン端末5のシリアル番号である。このシリアル番号を加盟店端末情報データベース44と照合することにより、電子マネーカード7の処理を行った加盟店102を特定することができる。
取引日時58は、オンライン端末5と通信を行った日時である。例えば、通信開始時刻、及び通信終了時刻などが記憶されている。
【0074】
図5に示したように、カードID52「00001」で特定される電子マネーカード7に対して行った処理は取引情報として時系列的に記録される。
他のカードIDに係る電子マネーカード7に関しても同様に取引情報が蓄積される。
オンライン端末5で行った処理に関してはリアルタイムで取引情報が取引情報データベース46に記録されるが、オフライン端末6で行った処理に関しては、バッチ処理にてオフライン端末6から送信されてきてから取引情報データベース46に記録されるまでタイムラグが生じる。
【0075】
また、オフライン端末6での処理では、処理中にオフライン端末6と電子マネーカード7の間で障害が発生しないので、オフライン端末6での処理では必ずしも取引状態55の項目を設ける必要はない。
以上にセンタサーバ2について説明したが、オンライン端末5のハードウェア的な構成は、基本的にセンタサーバ2と同様である。
オンライン端末5は、加盟店102の担当者や電子マネーカード7を有する顧客などに情報を表示するための表示装置や、効果音などの音声により処理状況を通知する音声出力装置などを備えている。
【0076】
次に、図6〜図13のフローチャートを用いて、電子マネーカード7を用いた代金の支払い処理手順、及び支払い中に障害が発生した場合の回復手順などについて説明する。
ここでは、一例として20、000円チャージされた電子マネーカード7を用いて9、000円の支払いを行う場合について説明する。
【0077】
図6は、電子マネーカード7に支払い処理を施す手順を説明するためのフローチャートである。
このフローチャートでは、電子マネーカード7側とセンタサーバ2側でデータが更新される様子を説明するため、それぞれカード情報と取引情報を併記している。
【0078】
カード情報は、電子マネーカード7側で保持されているデータの論理的構成を示したものである。
カード情報は、「カードID」、「残高」、「取引額」、「取引状態」などの項目から構成されている。
これら「カードID」、「残高」、「取引額」、「取引状態」の各値は、それぞれ、バリュー処理部7a、残高記憶部7b、ログデータ記憶部7c、取引状態保持部7eに記憶されている情報を用いることができる。
【0079】
例えば、カード情報71では、カードIDが00001であり、バリュー残高が20、000円であり、また、取引状態は「取引完了」に設定されている。
カード情報71では、取引状態が「取引完了」に設定されているため、前回の処理において、電子マネーカード7側の処理は完了していることがわかる。
【0080】
このように構成されたカード情報と取引情報を参照しながら支払い処理について説明する。
まず、顧客は加盟店102の担当者(店員)に商品を提示して購入の意思表示を行う。
これに対し、担当者はバーコード読取装置などを用いて商品の代金9、000円を読み取り、これを支払額としてオンライン端末5に入力する。
すると、オンライン端末5の表示装置に図22(a)に示したような、カード確認画面が表示される。カード確認画面には、支払額が表示されるほか、「電子マネーカードをセットしてください」などと、電子マネーカード7をオンライン端末5のリーダライタ5bにセットするように促す指示が表示される。
顧客はカード確認画面の指示に従って、オンライン端末5に電子マネーカード7をセットする。
【0081】
図6に戻り、電子マネーカード7は、オンライン端末5にセットされるとリーダライタ5bの電波によって駆動され、オンライン端末5との通信を開始する(ステップ104)。
電子マネーカード7がオンライン端末5と接続されると、センタサーバ2は電子マネーカード7と通信できるようになる。
電子マネーカード7とセンタサーバ2が通信を行っている間、オンライン端末5の表示装置には、図22(b)に示したような通信中画面が表示される。これにより、顧客と加盟店102の担当者は電子マネーカード7とセンタサーバ2が通信中であることを認識することができる。
【0082】
図6に戻り、オンライン端末5は電子マネーカード7と通信を開始すると、電子マネーカード7からカードIDを読み取り、これを支払額と共にセンタサーバ2に送信する(ステップ204)。
なお、カードIDの読み取りは、オンライン端末5が電子マネーカード7にカードIDコマンドを電子マネーカード7に入力することにより行われる。
電子マネーカード7では、バリュー処理部7aがカードIDコマンドを実行し、カードID記憶部7dからカードIDを読み取ってオンライン端末5に返すようになっている。
【0083】
センタサーバ2はオンライン端末5からこれらの情報を受け付けると、電子マネーカード7に対して残高・状態確認要求を行う(ステップ304)。
この要求は、電子マネーカード7に対してバリュー残高と取引状態の送信を要求するものであり、電子マネーカード7にこれらの動作を行わせるためのコマンドを送信することにより行われる。
【0084】
電子マネーカード7は、オンライン端末5から残高・状態確認要求を受け、残高・状態確認応答を行う(ステップ106)。
この処理は、オンライン端末5から送信されてきたコマンドをバリュー処理部7aが実行して、残高記憶部7bに記憶されているバリュー残高と、取引状態保持部7eに記憶されている取引状態をセンタサーバ2に送信することにより行われる。このように、センタサーバ2は、端末フラグ受信手段(電子マネーカード7の取引状態を受信)を備えている。
【0085】
センタサーバ2は、電子マネーカード7からバリュー残高と取引状態を受信する。
そして、受信した取引状態と取引情報データベース46に記憶されている前回の取引情報の取引状態を確認し、前回の取引で障害が発生したか否かを確認する。
障害が発生していた場合は後述の方法により障害を回復する。ここでは、障害が発生しなかったものとする。
【0086】
センタサーバ2は、電子マネーカード7とセンタサーバ2側の取引情報を確認した後、今回の処理に関する取引情報81を生成して取引情報データベース46に記憶して登録する(ステップ306)。
取引情報81では、電子マネーカード7から受信したカードID、バリュー残高、及びオンライン端末5で入力された取引額などが記憶される。なお、図では処理内容、シリアルID、取引日時、…などのほかの項目は省略してある。
図に示したように、取引情報81では、カードIDが00001、残高が減算後の値で11、000円、取引額が9、000円となっている。
【0087】
なお、登録時には、取引情報81の取引状態は「取引中」に設定されている。このように、取引状態は、センタサーバ2側の処理が開始される際に「取引中」に設定される。そして、センタサーバ2側での処理が完了した際に「取引完了」に設定される。
【0088】
取引状態が「取引中」の場合は、取引情報の取引情報データベース46への記録が確定した訳ではなく、後述のように障害回復の際に無効とされる場合がある。
そのため、取引情報81で残高が減算後の値になっているが、これは、障害回復の際に利用するためであり、センタサーバ2側での減算処理が完了するのは、取引状態が「取引完了」に設定された時点である。
【0089】
次に、センタサーバ2は、電子マネーカード7に対して取引中・減算要求をおこなう(ステップ308)。
この要求は、電子マネーカード7に取引中コマンドと、支払額分の減算を実行させるための減算コマンドを送信することにより行われる。
【0090】
本実施の形態では、電子マネーカード7において、減算コマンドの実行と取引状態の更新を対応させるため、減算コマンドと取引中コマンドを共に送信することにした。即ち、取引状態が更新されたことを確認することにより、電子マネーカード7で減算コマンドが実行されたことを確認することができる。
後の入金処理でも加算コマンドと取引完了コマンドを共に電子マネーカード7に送信するのも同じ理由による。
【0091】
電子マネーカード7は、これらのコマンドを受信して実行し、取引状態を「取引中」に設定すると共に、バリュー残高を支払額分だけ減算する。この結果、カード情報71はカード情報72に更新される。図に示したように、カード情報72では、残高が11、000円と減算後の値となっており、また、取引状態は、「取引中」に設定されている。
次に、電子マネーカード7は、減算が完了し、取引状態を「取引中」に設定した旨を示す減算完了通知をセンタサーバ2に送信する(ステップ108)。
【0092】
センタサーバ2は、電子マネーカード7から減算完了通知を受信すると取引情報81の取引状態を「取引完了」に設定し、取引情報82へ更新する(ステップ310)。
これにより、センタサーバ2は、センタサーバ2側での減算処理を完了させると共に取引情報82の取引情報データベース46への登録が確定する。
【0093】
センタサーバ2は、センタサーバ2側での減算処理を完了させると、電子マネーカード7に対して取引完了設定要求を行う(ステップ312)。この要求は、電子マネーカード7に取引完了コマンドを送信することにより行われる。
これに対し、電子マネーカード7は、取引完了コマンドを受信して実行し、取引状態を「取引完了」に設定する(ステップ110)。即ち、取引状態の値を「取引中」から「取引完了」に復帰する。その結果、カード情報はカード情報73のように更新される。
電子マネーカード7は、取引完了コマンドを実行後、取引状態を「取引完了」に設定した旨を表す取引完了通知をセンタサーバ2に送信する。
【0094】
センタサーバ2は、電子マネーカード7から取引完了通知を受信すると、電子マネーカード7との処理が完了した旨を表す取引完了通知をオンライン端末5に送信する(ステップ314)。
オンライン端末5は、センタサーバ2から取引完了通知を受信して処理が完了したことを確認する(ステップ206)。
【0095】
このとき、オンライン端末5は、処理成功を表す効果音と共に表示装置に図22(c)に示したような支払い完了画面を表示する。
支払い完了画面では、カードIDと支払金額、及び支払い後のバリュー残高などが表示される。
【0096】
以上に説明した支払い処理で、電子マネーカード7とセンタサーバ2の通信に障害が発生する可能性がある箇所としては、ステップ106(障害1と呼ぶ、以下同様)、ステップ308(障害2)、ステップ108(障害3)、ステップ312(障害4)、ステップ110(障害5)がある。
なお、ステップ304で障害が発生する可能性もあるが、この場合の処理は障害1と同じであるので説明を省略する。
【0097】
以下に、これら障害1〜障害5が発生した場合の処理手順と、その回復処理手順について説明する。
図7は、障害1が発生した場合の処理手順を説明するためのフローチャートである。なお、以下では図6のフローチャートに対応するステップには同じステップ番号を付して説明を簡略化、あるいは省略することにする。
【0098】
まず、電子マネーカード7がバリュー残高と取引状態をオンライン端末5に送信する際に(ステップ106)障害1が発生した場合、センタサーバ2は、障害1を検出する(ステップ316)。
ここで、電子マネーシステム1は、タイムアウトにより障害を検出するものとする。即ち、センタサーバ2は、電子マネーカード7からの応答を受信するまでの時間を計測し、予め設定した所定時間内に応答がない場合、障害が発生したものと判断する。なお、これは一例であって他の方法により障害を検出してもよい。
【0099】
センタサーバ2は、障害1を検出すると、処理が失敗した旨を表す取引失敗通知をオンライン端末5に送信する(ステップ318)。
オンライン端末5は、センタサーバ2から取引失敗通知を受信して処理が失敗したことを確認する(ステップ208)。
オンライン端末5は、処理の失敗を確認すると取引失敗を表す効果音と共に図22(d)に示したようなエラー発生画面を表示する。
【0100】
エラー発生画面では、残高確認を指示する旨の表示が行われ、加盟店102の担当者は、電子マネーカード7の残高確認処理を行うことになる。
このように電子マネーシステム1は、エラーが発生すると残高確認を要求し、残高確認処理に伴って障害を回復するようになっている。
即ち、残高確認処理は、まずセンタサーバ2が電子マネーカード7側とセンタサーバ2側の取引状態を確認して前回の処理で障害が発生したか否かを確認する。障害が発生していない場合は残高確認を行い、障害が発生していた場合は回復処理を行った後残高確認を行う。
【0101】
なお、図6の説明では省略したが、支払い処理や後に説明する入金処理においても、まずセンタサーバ2は前回の処理で障害が発生したか否かを確認し、障害が発生していた場合はこれを回復してから支払い処理、あるいは入金処理を続行する。
【0102】
さて、障害1が発生した場合、カード情報71は未処理であり、またセンタサーバ2でも取引情報が登録される前なので回復処理を行う必要はない。このため、障害1が発生した場合は、回復処理をせずに残高確認が行われる。そして、加盟店102の担当者は、残高確認の後に支払い処理を最初から行うことになる。
【0103】
次に、図8のフローチャートを用いて障害2、及び障害3が発生した場合の処理手順を説明する。
ステップ308(障害2)、又はステップ108(障害3)で障害が発生した場合、センタサーバ2はこれを検出し(ステップ320)、オンライン端末5に対して取引失敗通知を送信する(ステップ322)。
オンライン端末5は、取引失敗通知を受信して失敗を確認し、効果音と共にエラー発生画面を表示する(ステップ210)。
【0104】
ここで障害2と障害3のうち、何れが発生したかは、カード情報と取引情報の取引状態の組合せから特定することができる。
即ち、障害2が発生した場合、カード情報はカード情報71となり、障害3が発生した場合はカード情報72となる。また、取引情報は、障害2、障害3の何れの場合でも取引情報81となる。
このためカード情報と取引情報の取引状態の組合せは、障害2が発生した場合は(取引完了、取引中)となり、障害3が発生した場合は(取引中、取引中)となる。
以下では、同様にカード情報と取引情報の取引状態の組合せをこの順序で括弧書きにて記すことにする。
【0105】
図9は、障害2が発生した場合の回復処理手順を説明するためのフローチャートである。
この処理は、オンライン端末5でエラー発生画面の指示に従って、加盟店102の担当者が電子マネーカード7の残高確認を要求することにより開始する。
【0106】
担当者は、電子マネーカード7をリーダライタ5bにセットして電子マネーカード7とオンライン端末5の通信を開始し(ステップ104)(なお、通常はエラーが発生した時点で電子マネーカード7がオンライン端末5にセットされているので、このまま引き続き残高確認処理に移行する)、オンライン端末5に設けられた残高確認ボタンを押すなどしてセンタサーバ2に残高確認を要求する(ステップ205)。
【0107】
センタサーバ2は、オンライン端末5より残高確認要求を受けて、残高・状態確認要求を電子マネーカード7に対して行い(ステップ304)、これに対し、電子マネーカード7は、残高・状態確認応答を行う(ステップ106)。
次に、センタサーバ2は、残高・状態確認応答により電子マネーカード7から送信されてきた取引状態と、前回の取引情報81の取引状態の組合せを確認する。
その結果、取引状態の組合せが(取引完了、取引中)となり、また、前回の処理が支払い処理であったため(図示しないが取引情報81に記録されている)、センタサーバ2は前回の処理が障害2により中断したと判断する。
【0108】
障害2が発生した場合、センタサーバ2は、取引情報81の取引状態を「取引回復」に設定することにより状態回復を行う。
センタサーバ2は、取引状態が「取引回復」に設定されている取引情報は無効になったものとして扱うように構成されており、その結果、前々回の取引情報80が電子マネーカード7に対して最新の取引情報となる。
換言すればセンタサーバ2は前回の取引情報81を前々回の取引情報80に更新することにより障害回復を行う(ステップ324)。
【0109】
センタサーバ2は、取引情報を更新した後、障害回復を行った旨を表す障害回復通知をオンライン端末5に送信する(ステップ326)。オンライン端末5はこれを受信して障害が回復したことを確認する(ステップ212)。
なお、本実施の形態では、障害回復通知として電子マネーカード7のバリュー残高を送信し、オンライン端末5ではバリュー残高が表示されるようになっている。即ち、残高確認と共に障害回復を行っている。
【0110】
そして、加盟店102の担当者は残高確認を行った後、支払い処理を再度最初から行う。
このように、障害2が発生した場合はカード情報が更新前のままであるので、取引情報を更新前のものに戻すことにより、両者の整合性をとることができる。
【0111】
図10は、障害3が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ104〜ステップ106までは障害2の場合と同様である。
そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報81の取引状態の組合せを確認し、取引状態の組合せが(取引中、取引中)であり、また前回の取引が支払い処理であったことから、前回の処理が障害3により中断したと判断する。
【0112】
障害3が発生した場合、センタサーバ2は、前回の処理において電子マネーカード7で減算した金額分の加算を行う加算コマンドを生成し、取引完了コマンドと共に電子マネーカード7に送信する(ステップ328)。
電子マネーカード7は、この加算コマンドを実行し、前回減算した分のバリューを加算し、取引状態を「取引完了」に設定する。そして、加算処理と「取引完了」に設定した旨を表す加算完了通知をセンタサーバ2に送信する(ステップ112)。
以上の処理によりカード情報はカード情報72からカード情報71に更新される。
【0113】
センタサーバ2は、電子マネーカード7から加算完了通知を受信すると、障害2の場合と同様に取引情報81の取引状態を「取引回復」に設定して取引情報を更新する(ステップ330)。これにより、前々回の取引情報80が最新の取引情報として扱われる。
次に、センタサーバ2は、オンライン端末5に障害回復通知を送信し(ステップ332)、オンライン端末5はこれにより障害が回復したことを確認する(ステップ214)。
そして、障害3を回復した後に支払い処理を再度最初から行う。
【0114】
以上のように、障害3が発生した場合は、電子マネーカード7に障害発生時に減算したバリューを加算してバリュー残高を障害発生前の状態に戻すと共に、取引情報も障害発生時前のものに戻す。
即ち、センタサーバ2で取引情報が確定する前(取引情報が支払い後のものに更新される前)に、電子マネーカード7で減算を実行するため、電子マネーカード7に減算したバリューを戻すことにより障害発生前の状態に復帰することができる。
【0115】
図11は、障害4、及び障害5が発生した場合の処理手順を説明するためのフローチャートである。
ステップ104〜ステップ310までは図6のフローチャートと同様である。センタサーバ2は、取引情報を取引情報82に更新した後(ステップ310)、電子マネーカード7に宛てて取引完了コマンドを送信する(ステップ312)。
【0116】
その後、障害4又は障害5が発生した場合、センタサーバ2はこれらの何れかの障害が発生したことを検出し(ステップ334)、オンライン端末5に対して取引失敗通知を行う(ステップ336)。
そして、オンライン端末5は、取引処理失敗を表す効果音と共に表示装置にエラー発生画面を表示する(ステップ216)。
【0117】
カード情報は障害4が発生した場合はカード情報72となり、障害5が発生した場合はカード情報73となる。また、取引情報は何れの場合も取引情報82である。
その結果、取引状態の組合せは、障害4の場合は(取引中、取引完了)となり、障害5の場合は(取引完了、取引完了)となる。
【0118】
図12は、障害4が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ104〜ステップ106までは障害2の場合と同様である。
そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報82の取引状態の組合せを確認し、取引状態の組合せが(取引中、取引完了)であり、また前回の取引が支払い処理であったことから、前回の処理が障害4により中断したと判断する。
【0119】
障害4が発生した場合は、電子マネーカード7とセンタサーバ2の何れも減算処理は完了しており、カード情報72の取引状態が不整合であるだけなのでこれを「取引中」から「取引完了」に復帰させることにより障害回復を行う。
そのため、センタサーバ2は電子マネーカード7に取引完了設定要求を行う(ステップ338)。この取引完了設定要求は、電子マネーカード7に取引完了コマンドを送信することにより行われる。
【0120】
電子マネーカード7は、取引完了コマンドを受信して実行し、カード情報72の取引状態を「取引完了」に設定する。これにより、カード情報はカード情報72からカード情報73に更新される。
そして、電子マネーカード7は、取引完了通知をセンタサーバ2に送信する(ステップ114)。
センタサーバ2は、取引完了通知を受信した後、障害回復通知をオンライン端末5に送信し(ステップ340)、オンライン端末5は、これを受信して障害4が回復されたことを確認する(ステップ218)。
【0121】
図13は、障害5が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ104〜ステップ106までは障害2の場合と同様である。
そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報82の取引状態の組合せを確認し、取引状態の組合せが(取引完了、取引完了)であり、また前回の取引が支払い処理であったことから、前回の処理が障害5により中断したと判断する。
【0122】
障害5が発生した場合は、カード情報と取引情報の何れも支払い処理後のものに更新されており、カード情報が更新されたことをセンタサーバ2が確認できていなかっただけなので、特に回復処理を行う必要はない。
そのため、センタサーバ2は、特に回復処理を行わずにオンライン端末5に障害回復通知を送信し(ステップ342)、オンライン端末5は、これにより障害が回復したことを確認する(ステップ220)。
【0123】
次に、図14〜図20のフローチャートを用いて、電子マネーカード7を用いた入金処理手順、及び入金中に障害が発生した場合の回復手順などについて説明する。
ここでは、一例として20、000円チャージされた電子マネーカード7に9、000円の入金を行う場合について説明する。
【0124】
図14は入金処理の手順を説明するためのフローチャートである。
入金処理の場合、まず顧客は加盟店102の担当者に現金9、000円を渡し、9、000円分の入金を依頼する。
担当者は、顧客から現金9、000円を受領すると共に、9、000円を入金額としてオンライン端末5に入力する。
すると、オンライン端末5の表示装置にカード確認画面が表示されるので、顧客は画面の指示に従って電子マネーカード7をリーダライタ5bにセットする。
【0125】
電子マネーカード7は、オンライン端末5にセットされると、オンライン端末5のリーダライタ5bから放射される電波によって駆動され、オンライン端末5との通信を開始する(ステップ504)。
電子マネーカード7がオンライン端末5と接続されると、センタサーバ2は電子マネーカード7と通信できるようになり、オンライン端末5の表示装置には通信中画面が表示される。
【0126】
オンライン端末5は電子マネーカード7と通信を開始すると、電子マネーカード7からカードIDを読み取り、これを入金額と共にセンタサーバ2に送信する(ステップ604)。
センタサーバ2はこれらの情報を受け付けると、電子マネーカード7に対して残高・状態確認要求を行う(ステップ704)。
電子マネーカード7は、これを受け、残高・状態確認応答を行う(ステップ506)。
【0127】
センタサーバ2は、電子マネーカード7から残高・状態確認応答を受けると、前回の処理で障害が発生したか否かを確認し、障害が発生していた場合は、これを回復してから処理を続行する。障害回復処理については後述し、ここでは、障害が発生しなかったものとする。
【0128】
センタサーバ2は、前回の処理で障害が発生していないことを確認した後、この処理に関する取引情報86を生成して取引情報データベース46に登録する(ステップ706)。
取引情報86では、残高が入金後の金額となっているが、取引状態が「取引中」に設定されており、取引情報データベース46への登録はまだ確定していない。即ち、センタサーバ2ではまだ加算処理は完了していない。
【0129】
次に、センタサーバ2は、電子マネーカード7に対して取引中設定要求を行う(ステップ708)。
電子マネーカード7は取引中設定要求を受けて取引状態を「取引中」に設定し、取引中設定通知をセンタサーバ2に送信する(ステップ508)。これにより、カード情報76は、カード情報77に更新される。
【0130】
センタサーバ2は、電子マネーカード7から取引中設定通知を受信すると取引状態を「取引完了」に設定し、これによって取引情報86を取引情報87に更新する(ステップ710)。
取引状態を「取引完了」に設定することにより取引情報87の取引情報データベース46への登録が確定し、センタサーバ2で加算が行われたことになる。
【0131】
次に、センタサーバ2は、電子マネーカード7に取引完了設定・加算要求を行う(ステップ714)。これは、入金額分の加算を行う加算コマンドと取引完了コマンドを共に電子マネーカード7に送信することにより行われる。
電子マネーカード7は、これらのコマンドを受信し、加算コマンドを実行して、バリュー残高を9、000増加させると共に、取引状態を「取引完了」に設定する。そして、加算処理と「取引完了」に設定した旨を表す加算完了通知をセンタサーバ2に送信する(ステップ510)。
【0132】
加算コマンドと取引完了コマンドの実行によりカード情報77はカード情報78に更新される。
図に示したようにカード情報78は、バリュー残高が29、000円となり、取引状態が「取引完了」に設定されている。
【0133】
センタサーバ2は、電子マネーカード7から加算完了通知を受信すると、取引完了通知をオンライン端末5に送信する(ステップ716)。
オンライン端末5は、センタサーバ2から取引完了通知を受信して処理が完了したことを確認する(ステップ606)。
このとき、オンライン端末5は、処理成功を表す効果音と共に表示装置に入金完了画面が表示される。
【0134】
図14に示した入金処理で、電子マネーカード7とセンタサーバ2の通信に障害が発生する可能性がある箇所としては、ステップ506(障害6)、ステップ708(障害7)、ステップ508(障害8)、ステップ714(障害9)、ステップ510(障害10)がある。
なお、ステップ704で障害が発生する可能性もあるが、この場合の処理は障害6と同じであるので説明を省略する。
【0135】
以下に、これら障害6〜障害10が発生した場合の処理手順と、回復処理手順について説明する。
図15は、障害6が発生した場合の処理手順を説明するためのフローチャートである。
なお、以下では図15のフローチャートに対応するステップには同じステップ番号を付して説明を簡略化、あるいは省略することにする。
【0136】
まず、電子マネーカード7がバリュー残高と取引状態をセンタサーバ2に送信する際に(ステップ506)障害6が発生した場合、センタサーバ2は、障害6を検出する(ステップ718)。
センタサーバ2は、障害6を検出すると、取引処理が失敗した旨を表す取引失敗通知をオンライン端末5に送信する(ステップ720)。
【0137】
オンライン端末5は、センタサーバ2から取引失敗通知を受信して処理が失敗したことを確認する(ステップ608)。
このとき、オンライン端末5は、取引失敗を表す効果音と共にエラー発生画面を表示する。エラー発生画面には残高確認を指示する旨の通知が行われ、加盟店102の担当者は、電子マネーカード7の残高確認処理を行うことになる。
【0138】
さて、障害6が発生した場合、カード情報76は未処理であり、またセンタサーバ2でも取引情報が登録される前なので回復処理を行う必要はない。このため、障害6が発生した場合は、回復処理をせずに残高確認が行われる。そして、加盟店102の担当者は、残高確認の後に処理を最初から行うことになる。
【0139】
図16は、障害7、及び障害8が発生した場合の処理手順を説明するためのフローチャートである。
ステップ708(障害7)、又はステップ508(障害8)で障害が発生した場合、センタサーバ2はこれを検出し(ステップ718)、オンライン端末5に対して取引失敗通知を送信する(ステップ720)。
オンライン端末5は、取引失敗通知を受信して失敗を確認し、効果音と共にエラー発生画面を表示する(ステップ608)。
【0140】
ここで障害7と障害8のうち、何れが発生したかは、カード情報と取引情報の取引状態の組合せから特定する。
即ち、障害7が発生した場合、カード情報はカード情報76となり、障害8が発生した場合はカード情報77となる。また、取引情報は、障害7、障害8の何れの場合でも取引情報86となる。
このためカード情報と取引情報の取引状態の組合せは、障害7が発生した場合は(取引完了、取引中)となり、障害8が発生した場合は(取引中、取引中)となる。
【0141】
図17は、障害7が発生した場合の回復処理手順を説明するためのフローチャートである。
この処理は、オンライン端末5でエラー発生画面の指示に従って、加盟店102の担当者が電子マネーカード7の残高確認を要求することにより開始する。
【0142】
担当者は、電子マネーカード7をリーダライタ5bにセットして電子マネーカード7とオンライン端末5の通信を開始し(ステップ504)(なお、通常はエラーが発生した時点で電子マネーカード7がオンライン端末5にセットされているので、このまま引き続き残高確認処理に移行する)、オンライン端末5に設けられた残高確認ボタンを押すなどしてセンタサーバ2に残高確認を要求する(ステップ605)。
【0143】
センタサーバ2は、オンライン端末5より残高確認要求を受けて、残高・状態確認要求を電子マネーカード7に対して行い(ステップ704)、これに対し、電子マネーカード7は、残高・状態確認応答を行う(ステップ506)。
次に、センタサーバ2は、残高・状態確認応答により電子マネーカード7から送信されてきた取引状態と、前回の取引情報86の取引状態の組合せを確認する。
その結果、取引状態の組合せが(取引完了、取引中)となり、また、前回の処理が入金処理であったため(図示しないが取引情報86に記録されている)、センタサーバ2は前回の処理が障害7により中断したと判断する。
【0144】
すると、センタサーバ2は、取引情報86の取引状態を「取引回復」に設定し、取引情報86を取引情報88に更新する。
センタサーバ2は、取引状態が「取引回復」に設定されている取引情報は無効になったものとして扱うため、前々回の取引情報85が最新の取引情報として復活する。
換言すればセンタサーバ2は前回の取引情報86を前々回の取引情報85に更新することにより障害回復を行う(ステップ722)。
【0145】
センタサーバ2は、取引情報を更新した後、障害回復を行った旨を表す障害回復通知をオンライン端末5に送信する(ステップ724)。オンライン端末5はこれを受信して障害が回復したことを確認する(ステップ610)。
そして、加盟店102の担当者は残高確認を行った後、入金処理を再度最初から行う。
【0146】
図18は、障害8が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ504〜ステップ506までは障害7と同様である。
そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報86の取引状態の組合せを確認し、取引状態の組合せが(取引中、取引中)であり、また前回の取引が入金処理であったことから、前回の処理が障害8により中断したと判断する。
【0147】
障害8が発生した場合、電子マネーカード7とセンタサーバ2の何れも加算処理が完了していないので、カード情報と取引情報を入金処理前の状態に戻すことにより障害回復を行う。
そのため、センタサーバ2は、電子マネーカード7に対して取引完了設定要求を行う(ステップ726)。この要求は、電子マネーカード7に取引完了コマンドを送信することにより行われる。
【0148】
これに対し、電子マネーカード7は、取引状態を「取引完了」に設定し、センタサーバ2に取引完了設定通知を送信する(ステップ512)。
これにより、カード情報はカード情報77からカード情報76に戻される。
【0149】
センタサーバ2は、電子マネーカード7から取引完了通知を受信すると、取引情報86の取引状態を「取引回復」に設定して取引情報88に更新する(ステップ728)。これにより、取引情報88は無効な取引情報となり、前々回の取引情報85が最新の取引情報として復活する。
次に、センタサーバ2は、オンライン端末5に処理回復通知を送信し(ステップ730)、オンライン端末5はこれにより障害が回復したことを確認する(ステップ612)。
その後、加盟店102の担当者は入金処理を最初からやり直す。
【0150】
図19は、障害9、及び障害10が発生した場合の処理手順を説明するためのフローチャートである。
ステップ504〜ステップ710は図14のフローチャートと同様である。
センタサーバ2は、取引情報を取引情報87に更新した後(ステップ714)、電子マネーカード7に宛てて取引完了コマンドと加算コマンドを送信する(ステップ714)。
【0151】
その後、障害9又は障害10が発生した場合、センタサーバ2はこれらの何れかの障害が発生したことを検出し(ステップ732)、オンライン端末5に対して取引失敗通知を行う(ステップ734)。
そして、オンライン端末5は、取引処理失敗を表す効果音と共に表示装置にエラー発生画面を表示する(ステップ614)。
【0152】
カード情報は障害9が発生した場合はカード情報77となり、障害10が発生した場合はカード情報78となる。また、取引情報は何れの場合も取引情報87である。
その結果、取引状態の組合せは、障害9の場合は(取引中、取引完了)となり、障害10の場合は(取引完了、取引完了)となる。
【0153】
図20は、障害9が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ504〜ステップ506までは障害6の場合と同様である。
そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報87の取引状態の組合せを確認し、取引状態の組合せが(取引中、取引完了)であり、また前回の取引が入金処理であったことから、前回の処理が障害9により中断したと判断する。
【0154】
障害9の場合、センタサーバ2では加算処理が完了し、電子マネーカード7ではまだ加算処理が行われていない状態であるため、電子マネーカード7に加算処理を行わせることにより回復処理を行う。
まず、センタサーバ2は、電子マネーカード7に対して取引完了設定・加算要求を再度行う(ステップ736)。
【0155】
電子マネーカード7は、これに応じて加算処理を行うと共に取引状態を「取引完了」に設定し、センタサーバ2に加算完了通知を送信する(ステップ514)。これにより、カード情報77はカード情報78に更新される。
センタサーバ2は、加算完了通知を受信した後、障害回復通知をオンライン端末5に送信し(ステップ738)、オンライン端末5は、これを受信して障害9が回復したことを確認する(ステップ616)。
【0156】
次に、障害10の回復処理について説明する。障害10では、電子マネーカード7とセンタサーバ2の何れでも加算処理が完了しており、また取引状態も共に「取引完了」に設定されているため状態回復処理を行う必要はない。
そのため、障害10の場合は障害回復を行うことなくそのまま残高確認が行われる。
【0157】
以上に説明したように、電子マネーシステム1では、支払い処理を行う場合は、電子マネーカード7で減算処理を行った後(図6ステップ108)、センタサーバ2で減算処理を行い(図6ステップ310)、また、入金処理を行う場合は、センタサーバ2で加算処理を行った後(図14ステップ710)、電子マネーカード7で加算を行っている(図14ステップ510)。
【0158】
そのため、障害により電子マネーカード7とセンタサーバ2でバリュー残高の食い違いが生じた場合(障害3、障害9)、何れも電子マネーカード7に対して加算処理を行うことにより回復処理を行うことができる。
このように、障害回復を行う場合は、電子マネーカード7への処理は減算処理となることはないので顧客は安心して電子マネーカード7を使用することができる。
【0159】
また、以上の例では、残高確認を行う際に併せて障害回復を行うこととしたが、顧客と加盟店102の担当者の何れもが障害が発生したことに気づかず、障害回復を行わない場合もあり得る。
センタサーバ2は、支払い処理、入金処理の際に、これらの処理に先立って前回の処理で障害が発生したか否かを確認するため、例え、前回の取引で障害回復を行わなかったとしても、今回の取引で障害回復を行ってから処理を行うことができる。
【0160】
次に、障害回復を行っていない電子マネーカード7(以下、未回復カードと呼ぶ)をオフライン端末6で使用する場合について説明する。
未回復カードを用いてオフライン端末6で支払いを行う場合は、特に制限することなく使用できる。何れの障害が発生しても未回復カードに記憶されているバリューの残高は、顧客が本来有しているバリュー残高以下であるので、これから減算しても不都合は生じないからである。
また、センタサーバ2は、取引情報で障害回復するため、未回復カードをオフライン端末6で使用して支払いを行った後、この未払いカードをオンライン端末5にセットして障害回復を行うこともできる。
【0161】
一方、未回復カードに入金を行う場合には不都合が生じる場合がある。即ち、電子マネーカード7が記憶できるバリュー残高には上限値が設けられているため、未回復カードに入金を行うとバリュー残高がこの上限値を超える場合が生じる可能性がある。
例えば、バリューの上限値が5万円であるとする。そして、現在未回復カードに記憶されているバリューが4万円であるが、障害を回復すると5千円加算されるとする。
【0162】
顧客が未回復カードに1万円を入金してバリュー残高5万円とした後、障害を回復するとバリュー残高が5万5千円となり上限値を越えてしまう。
そのため、オフライン端末6は、電子マネーカード7に入金を行う前に、電子マネーカード7が未回復カードか否かを確認し、未回復カードである場合は、入金を制限するようになっている。
【0163】
図21は、オフライン端末6で電子マネーカード7に入金を行う手順を説明するためのフローチャートである。なお、以下のようにオフライン端末6は、演算命令入力装置を構成している。
電子マネーカード7は、オフライン端末6のリーダライタにセットされているものとする。
まず、加盟店102の担当者は、オフライン端末6に入金額を入力する(ステップ904)。これは、加算金額取得手段に対応する。
【0164】
すると、オフライン端末6は、電子マネーカード7に対して残高・状態確認要求を行い(ステップ906)、これに対し、電子マネーカード7は、オフライン端末6に対して残高・状態確認応答を行う(ステップ804)。このように、センタサーバ2は、電子マネーカード7から取引状態を受信し、これは端末フラグ受信手段に対応する。
【0165】
オフライン端末6は、電子マネーカード7から受信した取引状態が「取引完了」と「取引中」の何れであるかを判断する(ステップ908)。
取引状態が「取引完了」であった場合(ステップ908;Y)、オフライン端末6は、加算コマンドを生成して電子マネーカード7に入力し、入金処理を行う(ステップ806)。
【0166】
一方、取引状態が「取引中」であった場合(ステップ908;N)、オフライン端末6は、入金処理をせずにアラームを発する(ステップ1000)。
このような、オフライン端末6は、加算命令生成手段と、取引状態が「取引中」であった場合、電子マネーカード7への入力を制限する加算命令入力手段を備えている。
【0167】
このように、オフライン端末6は、電子マネーカード7の取引状態を確認することにより、電子マネーカード7が未回復カードか否かを判断することができ、また、未回復カードであった場合は、入金処理を制限する(本実施の形態では入金処理を全く行わない)。
【0168】
なお、本実施の形態では、未回復カードに関しては、入金額を制限するように構成することも可能である。
即ち、障害により電子マネーカード7に記憶されているバリュー残高が、実際にユーザが保有しているバリュー残高より少なくなる場合は、障害3、及び障害9が発生した場合である。
この場合に、障害回復により加算される可能性のある金額を見越して、オフライン端末6で入金できる金額の上限を動的に制限することができる。
【0169】
即ち、電子マネーカード7のカード情報から、回復処理にて加算処理が行われた場合、その加算額は「取引額」に記憶されている金額である。障害の種類によりこの金額がバリュー残高に加算されるかもしれないし、又は加算されないかもしれないが、オフライン端末6は、少なくとも加算されるこの金額分だけ残高が加算される可能性があることがわかる。
そこで、オフライン端末6は、上限値からこの金額を減じた金額をこの電子マネーカード7の上限値として設定すればよい。
【0170】
以上、本実施の形態の一例について説明したが、各種の変形例が可能である。
障害が発生した場合、それが電子マネーカード7で演算が行われた後に発生したのか、あるいは前に障害が発生したのかが最低限わかれば障害回復を行うことができる。そこでここではそのための条件について考える。
【0171】
図23(a)に示したように本実施の形態では、ステップ1〜ステップ4の通信のタイミングがある。
即ち、センタサーバ2は、ステップ1で取引中コマンドを送信し、ステップ2で取引中設定通知を受信し、更にステップ3で取引完了コマンドを送信し、ステップ4で取引完了通知を受信する。
【0172】
電子マネーカード7に演算命令を送信するタイミングは、ステップ1とステップ3があり、図23(a)は、ステップ1で演算コマンドを送信する場合を示している。
ステップ2、3で障害が発生した場合は、電子マネーカード7の取引状態は「取引中」になっている。即ち、電子マネーカード7の取引状態が「取引中」であることさえわかれば、電子マネーカード7で演算処理後に障害が発生したことがわかる。そのため、ステップ2とステップ3を必ずしも識別する必要はない。
【0173】
一方、電子マネーカード7の取引状態が「取引完了」であった場合、演算処理前に障害が発生したのか(ステップ1)、あるいは演算処理後に障害が発生したのか(ステップ4)識別することができない。そのため、ステップ1〜ステップ4の間でセンタサーバ2の取引状態を(奇数回)反転させると、ステップ1での障害とステップ4での障害を区別することができる。
ここで、取引状態を反転させるとは、取引状態を「取引完了」→「取引中」、又は「取引中」→「取引完了」に設定することを意味する。
【0174】
このように、構成すると、電子マネーカード7とセンタサーバ2の取引状態の組合せだけから電子マネーカード7で演算処理が行われたか否かを判断することができる。
そして、更に、センタサーバ2で取引状態を反転させる際に、センタサーバ2で記憶しているバリュー残高を更新することにより、センタサーバ2で記憶しているバリュー残高が更新前のものかあるいは後のものかを取引状態から判断することができる。
【0175】
図23(b)は、ステップ3で演算コマンドを送信する場合を示している。この場合は、電子マネーカード7の取引情報が「取引中」である場合は、演算処理前に障害が発生したことがわかる。
一方取引情報が「取引完了」であった場合、これだけでは演算処理前に障害が発生したのか(ステップ1)、あるいは演算処理後に障害が発生したのか(ステップ4)を識別することができない。そのため、ステップ1〜ステップ4の間でセンタサーバ2側の取引状態を反転させれば、何れで障害が発生したのか特定することができる。また、その反転の際にセンタサーバ2側で記憶しているバリュー残高の更新も行う。
【0176】
以上をまとめると、電子マネーカード7の取引状態を「取引中」か「取引完了」に設定させる際に演算コマンドも一緒に送信し、電子マネーカード7に取引中コマンドを送信してから(ステップ1)、取引完了通知を受信するまで(ステップ4)にセンタサーバ2の取引状態を反転させ、更に、反転の際にセンタサーバ2側で記憶しているバリュー残高を更新すればよいことになる。
【0177】
即ち、センタサーバ2は、電子マネーカード7の取引状態を反転させる取引中コマンドを送信し、電子マネーカード7がこれを実行して取引状態が「取引中」に反転されたことを確認した後、取引完了コマンドを電子マネーカード7に送信して電子マネーカード7の取引状態を「取引完了」に復帰させ、前記取引中コマンド又は取引完了コマンドを送信する際に、演算コマンドも送信し、電子マネーカード7に取引中コマンドを送信してから、電子マネーカード7の取引状態が「取引完了」に復帰したことを確認するまでの間に、センタサーバ2の取引状態を反転又は復帰させ、その際にセンタサーバ2残高更新を確定すればよい。
以上の範囲内で、電子マネーシステム1は、各種変形可能である。
【0178】
以上に説明した電子マネーシステム1により、次のような効果を得ることができる。
(1)電子マネーカード7とセンタサーバ2の取引状態の組合せから、発生した障害を特定することができる。
(2)取引状態の組合せから障害の種類を特定するため、オンライン端末5とオフライン端末6が混在した電子マネーシステム1(バリュー残高が電子マネーカード7とセンタサーバ2で必ずしも一致しない)で障害の種類を特定することができる。
【0179】
(3)支払い処理の場合は、電子マネーカード7で減算した後、センタサーバ2の取引情報を更新し、入金処理の場合は、センタサーバ2で取引情報を更新した後電子マネーカード7で加算処理するため、何れの場合も電子マネーカード7へは加算処理にて回復処理を行うことができる。
(4)電子マネーカード7での処理が終了していない場合は、取引状態が「取引中」に設定されるため、オフライン端末6にて未回復カードを識別することができる。
(5)オフライン端末6は、未回復カードへの入金機能が制限されているため、バリュー残高限度を超えて電子マネーカード7に入金されることを防ぐことができる。
【0180】
以上、本実施の形態の一例について説明したが、各種の変形が可能である。
例えば、オンライン端末5を、インターネット接続可能なパーソナルコンピュータにより構成し、顧客の自宅に設置しても良い。この場合、顧客は自宅の通信で電子マネーカード7の処理に障害が発生したことに気づかずに加盟店102に行ったとしても、オンライン端末5にて障害を回復することができる。
【0181】
また、本実施の形態では、センタサーバ2が加算コマンド、減算コマンドを電子マネーカード7に送信し、電子マネーカード7はこれらコマンドを実行して記憶している残高を更新したが、残高の演算はセンタサーバ2で行うように構成することもできる。
【0182】
この場合、センタサーバ2は、電子マネーカード7が記憶している残高を電子マネーカード7から取得し、これに加減算処理を行って加減算処理後の金額を算出する。
そして、センタサーバ2は、算出した金額を電子マネーカード7に送信し、電子マネーカード7は、記憶している残高をセンタサーバ2から受信した金額に更新する。
【0183】
このように、加減算処理は、センタサーバ2で行っても電子マネーカード7で行ってもよく、あるいは、加算に関してはセンタサーバ2で行い、減算に関しては電子マネーカード7で行うというように、加減算の一方をセンタサーバ2で行い、他方を電子マネーカード7で行うように構成することもできる。
【0184】
センタサーバ2が加算コマンド、減算コマンドを電子マネーカード7に送信し、電子マネーカード7で加減算を行う場合、加算コマンド、減算コマンドは金額変更情報を構成している。
センタサーバ2が加減算後の金額を計算し、電子マネーカード7がこれを用いて金額を更新する場合、センタサーバ2が電子マネーカード7に送信する加減算後の金額が金額変更情報に該当する。
【0185】
このように、センタサーバ2が送信した金額変更情報によって電子マネーカード7の残高が増減されるとした場合、バリュー処理部7aは、金額変更情報を用いて残高金額を金額変更処理する金額変更手段を構成している。
また、センタサーバ2は、演算コマンドや演算後の金額などの金額変更情報を送信する金額変更情報送信手段を備えている。
【0186】
更に、オフライン端末6は、金額変更情報入力装置を構成している。
即ち、オフライン端末6は、ステップ904にて入金額を取得するが、これは増額金額を取得する増額金額取得手段を構成している。
また、オフライン端末6は、ステップ806にて入金処理を行うが、これは入力された増額金額分の貨幣価値を増額する金額変更情報を生成する金額変更情報生成手段を構成している。
【0187】
更に、オフライン端末6は、電子マネーカード7の取引状態が「取引完了」であった場合は生成した金額変更情報を電子マネーカード7に入力し、「取引中」であった場合は金額変更情報の入力を制限する金額変更情報入力手段を備えている。
【符号の説明】
【0188】
1 電子マネーシステム
2 センタサーバ
5 オンライン端末
6 オフライン端末
100 電子マネーセンタ
102 加盟店
【技術分野】
【0001】
本発明は、貨幣端末処理サーバ、貨幣端末処理方法、貨幣端末、演算命令入力装置、及び金額変更情報入力装置に関し、例えば、ICカードに記憶した電子マネーを処理するものに関する。
【背景技術】
【0002】
近年、一般の小売店や消費者の協力を得て行われた電子マネー(電子現金)の大規模な実用化実験が成功裡に終わり、我が国は電子マネー時代の到来を迎えつつある。
現在実用化されている電子マネーシステムは、例えば、非接触型ICカードで構成された電子マネーカードに貨幣価値の金額を記憶させるものである。
電子マネーカードは、CPU(中央処理装置:Central Processing Unit)を備えており、これに加算コマンドや減算コマンド(以下、演算コマンド)を入力して実行させることにより、カード内の貨幣価値の金額を増減することができる。カード内の貨幣価値はバリューと呼ばれる電子情報で表される。
【0003】
電子マネーを用いて商品・サービスなどの提供を行う事業者は、電子マネーシステムの主催者(以下、電子マネーセンタ)に登録して加盟店を形成し、電子マネーカードにアクセスするための取引端末を備えている。加盟店は、現金の授受の代わりに、この取引端末を用いて顧客の電子マネーカード内のバリュー残高を増減させて商取引を行う。
【0004】
取引端末には、電子マネーセンタのサーバ装置(センタサーバ)とオンライン接続されたオンライン端末と、バッチ処理にて一日数回程度センタサーバと接続するオフライン端末がある。
例えば、オンライン端末は、ブロードバンドなどの高速通信が行えるネットワーク環境において利用され、オフライン端末は、高速通信が行えない場合に利用される。
【0005】
電子マネーシステムが実用化した当初は取引端末としてオフライン端末が採用されていたが、今日はネットワークのブロードバンド化が進展し、次第にオンライン端末に置き換えられるようになってきている。しかし、未だオンライン端末を設置するのが困難な場所があり、現在の電子マネーシステムはオフライン端末とオンライン端末が混在した形となっている。
【0006】
オンライン端末は、電子マネーカードとセンタサーバとの通信の仲介を行い、これによって、センタサーバは、電子マネーカードに所定の演算命令を送信する。電子マネーカードは、この演算命令を実行して電子マネーカード内のバリューの金額を増減する。
【0007】
これに対し、オフライン端末は、オフラインで電子マネーカードに演算コマンドを入力してカード内のバリューの金額を増減させ、その取引情報をログデータとして蓄積する。そして、一日数回程度バッチ処理にてこれらをまとめてセンタサーバに送信する。
【0008】
電子マネーセンタは、オンライン端末との取引情報と、オフライン端末から受信した取引情報を集計し、その集計結果に応じて加盟店の銀行口座に対して現金の移動を行う。
このように、電子マネーセンタは取引情報を用いてバリューによる交換価値の移動と実際の現金との対応関係をとっている。
このように電子マネーを用いた技術に以下のものがある。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開2003−141428号公報
【0010】
この技術は、ユーザが携行する非接触型ICカードに貨幣的な価値を記憶させてこれを加減算することにより電子マネーを流通させるものである。
【発明の概要】
【発明が解決しようとする課題】
【0011】
オフライン端末の場合、オフライン端末と電子マネーカードとの間での通信で処理が完結するため、通信時間が短時間(例えば0.1秒程度)で済み、更に通信経路も短いため、電子マネーカードの処理中に障害が生じる可能性についてはほとんど考慮する必要がなかった。
しかし、オンライン端末を用いると、電子マネーカードとセンタサーバが通信を行うために通信時間が延び(例えば、1秒程度)、通信経路も複雑で長距離のものとなるため、電子マネーカードの処理中に障害が生じる可能性を考慮する必要が生じてくる。
【0012】
そして、障害が発生してこれを回復する場合、オンライン端末とオフライン端末が混在しているために、電子マネーカードでのバリュー残高とセンタサーバで記録しているバリュー残高の一致がとれない場合があり(電子マネーカードでの情報は常に最新情報となるが、センタサーバでの情報は、全てのオフライン端末から情報を受信するまで最新状態に更新されない)バリュー残高を用いて回復処理を行うことはできない。
【0013】
更に、ユーザの利便性の観点から、障害の発生によりセンタサーバと電子マネーカードのバリュー残高に不一致が生じてこれを回復する場合、ユーザの電子マネーカードに対するバリュー残高の修正が少なくとも減算処理とならない(即ち、電子マネーカードのバリュー残高は変わらないかあるいは加算される)ような回復システムを構築する必要がある。
【0014】
そこで、本発明の目的は、オンライン端末を用いた電子マネーシステムにおいて、適切に障害回復を行うことができる貨幣端末処理サーバ、貨幣端末処理方法、貨幣端末、演算命令入力装置、及び金額変更情報入力装置を提供することである。
【課題を解決するための手段】
【0015】
本発明は、前記目的を達成するために、請求項1に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、前記貨幣端末から残高金額を受信する残高受信手段と、前記貨幣端末に対する演算命令の送信要求を取得する要求取得手段と、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信手段と、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、を具備したことを特徴とする貨幣端末処理サーバを提供する。
請求項2に記載の発明では、前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記演算処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、を具備したことを特徴とする請求項1に記載の貨幣端末処理サーバを提供する。
請求項3に記載の発明では、前記演算命令として減算命令を送信する場合、前記残高更新手段は、前記貨幣端末での前記減算命令の実行を確認した後に前記残高金額を更新し、前記演算命令として加算命令を送信する場合、前記演算命令送信手段は、前記残高金額を更新した後に前記加算命令を送信し、前記回復手段は、前記貨幣端末で当該減算命令が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減算した分の金額を加算させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で当該加算命令を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に加算させることにより回復処理を行うことを特徴とする請求項2に記載の貨幣端末処理サーバを提供する。
請求項4に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う貨幣情報処理方法であって、前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、演算命令送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、前記要求取得手段によって、前記貨幣端末に対する演算命令の送信要求を取得する要求取得ステップと、前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、前記演算命令送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信ステップと、前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、から構成されたことを特徴とする貨幣端末処理方法を提供する。
請求項5に記載の発明では、請求項1の貨幣端末処理サーバが演算命令を送信する貨幣端末であって、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、所定の演算命令を実行して前記残高金額を演算処理する演算手段と、端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、を具備したことを特徴とする貨幣端末を提供する。
請求項6に記載の発明では、請求項5に記載の貨幣端末に前記加算命令を入力する演算命令入力装置であり、加算金額を取得する加算金額取得手段と、前記取得した加算金額分の貨幣価値を加算する加算命令を生成する加算命令生成手段と、前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、前記端末フラグが初期状態であった場合は、前記生成した加算命令を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記加算命令の前記貨幣端末への入力を制限する加算命令入力手段と、を具備したことを特徴とする演算命令入力装置を提供する。
請求項7に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、前記貨幣端末から残高金額を受信する残高受信手段と、前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得手段と、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信手段と、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、を具備したことを特徴とする貨幣端末処理サーバを提供する。
請求項8に記載の発明では、前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記金額変更処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、を具備したことを特徴とする請求項7に記載の貨幣端末処理サーバを提供する。
請求項9に記載の発明では、前記金額変更情報として金額を減額する金額変更情報を送信する場合、前記残高更新手段は、前記貨幣端末での金額変更処理の実行を確認した後に前記残高金額を更新し、前記金額変更情報として金額を加算する金額変更情報を送信する場合、前記金額変更情報送信手段は、前記残高金額を更新した後に前記金額変更情報を送信し、前記回復手段は、前記貨幣端末で金額を減額する金額変更処理が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減額した分の金額を増額させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で金額を増額する金額変更処理を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に増額させることにより回復処理を行うことを特徴とする請求項8に記載の貨幣端末処理サーバを提供する。
請求項10に記載の発明では、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う情報処理方法であって、前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、金額変更情報送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、前記要求取得手段によって、前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得ステップと、前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、前記金額変更情報送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信ステップと、前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、から構成されたことを特徴とする貨幣端末処理方法を提供する。
請求項11に記載の発明では、請求項7の貨幣端末処理サーバが金額変更情報を送信する貨幣端末であって、貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、所定の金額変更情報を用いて前記残高金額を金額変更処理する金額変更手段と、端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、を具備したことを特徴とする貨幣端末を提供する。
請求項12に記載の発明では、請求項11に記載の貨幣端末に前記残高金額を増額する金額変更情報を入力する金額変更情報入力装置であり、前記増額金額を取得する増額金額取得手段と、前記取得した増額金額分の貨幣価値を増額する金額変更情報を生成する金額変更情報生成手段と、前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、前記端末フラグが初期状態であった場合は、前記生成した金額変更情報を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記金額変更情報の前記貨幣端末への入力を制限する金額変更情報入力手段と、を具備したことを特徴とする金額変更情報入力装置を提供する。
【発明の効果】
【0016】
本発明によると、オンライン端末とオフライン端末が混在した電子マネーシステムにおいて、適切に障害回復を行うことができる。
【図面の簡単な説明】
【0017】
【図1】フラグの設定手順の概要を説明するための図である。
【図2】電子マネーシステムの構成を示したブロック図である。
【図3】電子マネーカードのハードウェア的な構成を表したブロック図である。
【図4】センタサーバのハードウェア的な構成を示したブロック図である。
【図5】取引情報の一例を示した図である。
【図6】支払い処理の手順を説明するためのフローチャートである。
【図7】障害1が発生した場合の処理手順を説明するためのフローチャートである。
【図8】障害2、及び障害3が発生した場合の処理手順を説明するためのフローチャートである。
【図9】障害2が発生した場合の回復処理手順を説明するためのフローチャートである。
【図10】障害3が発生した場合の回復処理手順を説明するためのフローチャートである。
【図11】障害4、及び障害5が発生した場合の処理手順を説明するためのフローチャートである。
【図12】障害4が発生した場合の回復処理手順を説明するためのフローチャートである。
【図13】障害5が発生した場合の回復処理手順を説明するためのフローチャートである。
【図14】入金処理の手順を説明するためのフローチャートである。
【図15】障害6が発生した場合の処理手順を説明するためのフローチャートである。
【図16】障害7、及び障害8が発生した場合の処理手順を説明するためのフローチャートである。
【図17】障害7が発生した場合の回復処理手順を説明するためのフローチャートである。
【図18】障害8が発生した場合の回復処理手順を説明するためのフローチャートである。
【図19】障害9、及び障害10が発生した場合の処理手順を説明するためのフローチャートである。
【図20】障害9が発生した場合の回復処理手順を説明するためのフローチャートである。
【図21】オフライン端末で電子マネーカードに入金を行う手順を説明するためのフローチャートである。
【図22】オンライン端末に表示される画面を説明するための図である。
【図23】障害回復を行うために必要な条件を説明するための図である。
【発明を実施するための形態】
【0018】
(実施の形態の概要)
電子マネーカードとセンタサーバの双方に、「取引中」及び「取引完了」の2つの値を選択的に設定できるフラグを用意する。
そして、電子マネーカードとセンタサーバ間で情報処理を行う過程で、双方のフラグを立てたり(「取引完了」から「取引中」に反転させたり)、あるいは倒したり(「取引中」から「取引完了」に復帰させたり)して同期をとりながら処理を進める。
処理の途中で障害が発生した場合、障害が発生した時点でのフラグの状態が両者で保存されているため、これらの状態から障害が発生した時点を特定することができる。
そして、その特定した時点に応じた回復処理を行う。
【0019】
また、電子マネーカードで演算処理を行うタイミングとセンタサーバ側で残高記録を更新するタイミングの時間的順序を減算処理と加算処理の場合で逆にすることにより、電子マネーカードに対する復帰処理が少なくとも加算処理となるように構成することができる。
【0020】
即ち、電子マネーカードで減算処理を行う場合は、まず、電子マネーカードで減算処理を行った後、センタサーバでの残高記録の減算処理を行い、電子マネーカードで加算処理を行う場合は、逆にまずセンタサーバ側で加算処理を行った後に、電子マネーカードで残高記録の加算処理を行う。
このように構成すると、電子マネーカードで減算処理した後、センタサーバで残高記録の減算処理を行う前に障害が生じた場合は、電子マネーカードに減算した金額分を加算して残高を減算処理前の状態に回復し、また、センタサーバで残高記録の加算処理を行って電子マネーカードで加算処理を行う前に障害が生じた場合は、電子マネーカードに加算処理を行わせて両者の整合性をとることができる。
【0021】
図1(a)を用いて、一例に係るフラグの設定手順の概要を説明する。
まず、センタサーバでは、センタ側フラグが取引完了(初期状態)に設定されており、これを取引中(反転状態)に設定した後、電子マネーカードに取引中コマンド(反転命令)を送信する(ステップ1)。
電子マネーカードは、この取引中コマンドを受信して実行し、端末フラグ(カード側のフラグ)を取引中に設定する。そして、センタサーバに対して取引中設定通知を送信する(ステップ2)。
【0022】
センタサーバは、取引中設定通知を受信した後、サーバフラグを取引中から取引完了に設定する。そして、その後電子マネーカードに取引完了コマンド(復帰命令)を送信する(ステップ3)。
電子マネーカードは、センタサーバから取引完了コマンドを受信して実行し、端末フラグを取引完了に設定する。そして、その後取引完了設定通知をセンタサーバに送信する(ステップ4)。センタサーバはこれを受信する。
【0023】
以上のように設定したフラグを用いると、ステップ1〜ステップ4の何れかで障害が発生した場合、どのステップで障害が発生したかをフラグの組合せから特定することができる。
例えば、端末フラグが「取引中」でサーバフラグも「取引中」の場合はステップ2で障害が発生したことになる。
また、端末フラグが「取引中」でサーバフラグが「取引完了」である場合はステップ3で障害が発生したことになる。
【0024】
以下同様に、ステップ1で障害が生じた場合は、端末フラグが「取引完了」でサーバフラグが「取引中」となり、ステップ4で障害が生じた場合は、端末フラグとサーバフラグが共に「取引完了」になる。
即ち、フラグの組合せは合計4通りあり、これを各ステップに対応させたのである。
【0025】
そして、センタサーバが、フラグの設定コマンド(取引中コマンド、又は取引完了コマンド)と演算コマンドを共に電子マネーカードに送信し、電子マネーカードがフラグの設定と演算の実行を共に行うように構成すると、電子マネーカード側の情報とセンタサーバ側の情報を同期しながら更新することができる。
【0026】
例えば、電子マネーカードで減算処理を行う場合、図1(b)に示したように、ステップ1において取引中コマンドと減算コマンドを送信する。電子マネーカードはこの減算コマンドを受信して実行した後、ステップ2において減算完了通知(取引中設定通知を兼ねている)をセンタサーバに送信する。
センタサーバは、電子マネーカードから減算完了通知を受信したのち、当該電子マネーカードの残高記録を減算する。その後、ステップ3、4の処理が行われる。
【0027】
以上の手順で電子マネーカードのバリュー残高と、センタサーバでの残高記録に不一致が生じるのは、ステップ2で通信障害が生じた場合である。即ち、端末フラグと、サーバフラグが共に「取引中」である場合、電子マネーカードでは、減算処理が行われたがセンタサーバ側では残高記録の減算処理が行われなかったことがわかる。
従って、減算処理中に障害が発生し、端末フラグとサーバフラグが共に「取引中」である場合、電子マネーカードに減算した金額を加算する加算コマンドを送信して実行させると、減算処理前の状態に回復することができる。
【0028】
同様に、電子マネーカードで加算処理を行う場合、図1(c)に示したように、ステップ1、2の処理を行った後、ステップ3において、取引完了コマンドと加算コマンドを送信する。電子マネーカードはこの加算コマンドを受信して実行した後、ステップ4において加算完了通知(取引完了設定通知を兼ねている)をセンタサーバに送信する。
【0029】
以上の手順で電子マネーカードの残高と、センタサーバでの残高記録に不一致が生じるのは、ステップ3で通信障害が生じた場合である。即ち、端末フラグが「取引中」で、サーバフラグが「取引完了」である場合、センタサーバ側では残高記録の加算処理が行われたが、電子マネーカードでは加算処理が行われなかったことがわかる。
従って、加算処理中に障害が発生し、端末フラグが「取引中」でサーバフラグが「取引完了」である場合、電子マネーカードに加算コマンドを送信して実行させると、加算処理後の状態に回復することができる。
【0030】
(実施の形態の詳細)
電子マネーによる商取引では、金銭と同等の交換価値を付与したバリューと呼ばれる電子情報の値を加減することにより交換価値の移動を生じさせる。
バリューは、バリュー処理機能を有するICカードである電子マネーカードに記憶されて利用者に携帯される。
バリューを用いた商品・サービスの購入は、バリューによる商取引を行う契約を結んでいる加盟店で行うことができる。
【0031】
加盟店は、店頭に電子マネーカードにアクセスする加盟店端末を設置しており、利用者の電子マネーカードに記憶されているバリューを代金分だけ減算して支払いを行う(決済とも呼ばれる)。
また、加盟店に金銭を支払い、その金額分のバリューを電子マネーカードに書き込んでもらうこともできる。このように電子マネーカードにバリューを書き込む処理は入金(又はチャージ)と呼ばれている。
この加盟店端末には、電子マネーカードセンタのセンタサーバとオンライン接続されているオンライン端末と、バッチ処理にてログデータを一括してセンタサーバに送信するオフライン端末がある。
【0032】
図2は、本実施の形態の電子マネーシステムの構成を模式的に示したブロック図である。
電子マネーシステム1は、電子マネーセンタ100に設置されたセンタサーバ2、各加盟店102に設置されたオンライン端末5、5、5、…、オフライン端末6、センタサーバ2とオンライン端末5、5、5、…、及びオフライン端末6、6、6、…をネットワーク接続するネットワーク4、及びオンライン端末5、及びオフライン端末6と近距離の無線通信を行う電子マネーカード7を用いて構成されている。
【0033】
電子マネーセンタ100は、電子マネーシステム1の運営維持管理を行う事業体であり、センタサーバ2(貨幣端末処理サーバ)を運用している。
センタサーバ2は、オンライン端末5と常時接続されており、リアルタイムでオンライン端末5と通信でき、オンライン端末5からの要求に従って演算コマンド(演算命令)を生成して送信することができる。
なお、本実施の形態では、センタサーバ2とオンライン端末5、5、5、…を常時接続することとするが、これに限定するものではなく、例えば、必要に応じて(電子マネーカード7に各種コマンドを入力する必要がある時点など)オンライン端末5をセンタサーバ2に接続するように構成することもできる。
【0034】
また、センタサーバ2は、例えば1日1回程度、オフライン端末6が電子マネーカード7に対して行った処理に関する取引情報をまとめて受信する。
更に、オフライン端末6にはネットワーク4に接続されないものもあり、これに関しては電子マネーセンタ100の担当者が、オフライン端末6から取引情報が記憶された記憶媒体を回収し、これをセンタサーバ2に入力する。
【0035】
加盟店102は、例えば、コンビニエンスストアやレストランなど、商品やサービスを顧客に提供する店舗であって、これら商品やサービスの対価としてバリューを使用することができるものである。
加盟店102は、例えばレジにオンライン端末5やオフライン端末6を備えており、これを用いて顧客の電子マネーカード7から対価分のバリューを減算して支払いを行う。また、顧客から代金を受領して、その金額分のバリューを電子マネーカード7に入金することもできる。
本実施の形態では、オンライン端末5にて支払い、入金の双方を行うことができるものとするが、支払いと入金の何れか一方を行うように構成することもできる。
【0036】
オンライン端末5は、端末コンピュータ5aとリーダライタ5bから構成されている。
端末コンピュータ5aは、所定のコンピュータプログラムをリーダライタ5bを備えた汎用のコンピュータにインストールして構成することもできるし、あるいは、専用モジュールを組み込んだ専用機を用いて構成することも可能である。
リーダライタ5bは、端末コンピュータ5aの周辺機器であり、電子マネーカード7と近距離の無線通信を行うためのアンテナを内蔵している。
【0037】
端末コンピュータ5aは、リーダライタ5bを介して電子マネーカード7に接続し、センタサーバ2から送信されてきた演算コマンドを電子マネーカード7に入力することができる。
これに対し、オフライン端末6は、自ら演算コマンドを生成し、電子マネーカード7に入力する。
図示しないが、オフライン端末6にはリーダライタ5bが内蔵されており、オフラインで電子マネーカード7に対して処理を行った後、その処理内容を記録した取引情報を1日1回程度ネットワーク4を介してセンタサーバ2に送信する。
【0038】
電子マネーカード7は、バリュー処理機能が組み込まれた非接触型ICカードで構成された貨幣端末である。
電子マネーカード7は、バリュー処理機能を行うICチップと、リーダライタ5bと無線通信を行うためのアンテナを備えている。
電子マネーカード7は、バリュー残高金額を記憶しており、リーダライタ5bから入力された加算コマンドや減算コマンドを実行してバリューの金額を加減算する。
【0039】
図2は電子マネーカード7の機能的な構成も示しており、図示したように電子マネーカード7は、バリュー処理部7a、残高記憶部7b、ログデータ記憶部7c、カードID記憶部7d、取引状態保持部7eなどを備えている。
残高記憶部7bは、バリュー残高を記憶する記憶部である。支払いや入金の際は、残高記憶部7bに記憶されてるバリューの金額を増減する。残高記憶部7bは、貨幣価値の金額を電子データ(バリュー)として記憶する貨幣情報記憶手段を構成している。
【0040】
ログデータ記憶部7cは、取引履歴をログデータとして記憶する記憶部である。取引履歴としては、例えば取引日時、取引を行った加盟店端末のID情報、支払い又は入金の別、取引額などがある。
取引履歴は、例えば6件まで記憶され、古いものから順次消去されるようになっている。
【0041】
カードID記憶部7dは、カードIDを記憶した記憶部である。カードIDは、電子マネーシステム1において電子マネーカード7に一意に与えられたID情報であって、電子マネーセンタ100は、カードIDにより電子マネーカード7を特定することができる。
なお、カードIDは、電子マネーセンタ100が電子マネーカード7に付与したものであるが、このほかに、電子マネーカード7の製造メーカが電子マネーカード7に付与したID情報を用いてもよい。
何れのID情報も電子マネーカード7に記憶されており、カードIDコマンドを電子マネーカード7に入力することによりこれらID情報を読み出すことができる。
【0042】
取引状態保持部7eは、取引状態を記憶する記憶部である。取引状態は、電子マネーカード7側での処理が終了したか否かを表すフラグ情報であり、端末フラグを構成している。
取引状態は、「取引中」(反転状態に対応)、「取引完了」(初期状態に対応)の2値を選択的にとることができる。ここで、取引状態保持部7eは、端末フラグ記憶手段を構成している。
【0043】
取引状態は、電子マネーカード7での処理が完了するまでは「取引中」に設定され、処理が完了すると「取引完了」に復帰させられる。
これら「取引中」と「取引完了」の設定は、後述のバリュー処理部7aが、センタサーバ2から送信されてきた取引中コマンド(反転命令に対応)と取引完了コマンド(復帰命令に対応)を実行することにより行われる。ここで、バリュー処理部7aはフラグ命令実行手段に対応している。
取引状態保持部7eに記憶されている取引状態は、センタサーバ2と電子マネーカード7の間の通信障害の発生時点を判断するのに用いられる。
【0044】
バリュー処理部7aは、リーダライタ5bから入力される各種コマンドを実行する中央演算処理部であり、演算手段を構成している。
バリュー処理部7aは、加算コマンド、又は減算コマンドの入力を受け付けた場合、これらコマンドにパラメータとして付属している金額分だけ残高記憶部7bのバリューを加算、又は減算する。
そして、バリュー処理部7aは、情報処理を行った場合、ログデータ記憶部7cの取引履歴を更新する。
【0045】
本実施の形態では、電子マネーカード7は、ネットワーク4、端末コンピュータ5a、及びリーダライタ5bから成る経路を経由してセンタサーバ2と電子マネーカード7が通信を行うが、この通信は暗号化されており、電子マネーカード7は、このための暗号化及び復号化を行う機能も備えている。
【0046】
ネットワーク4は、例えばインターネットによって構成されており、センタサーバ2とオンライン端末5、及びオフライン端末6の間の通信を媒介する。
ネットワーク4は、WAN(Wide Area Network)やLAN(Local Area Network)などで構成してもよく、また、通信衛星を用いた通信回線、電話回線網、光ケーブル網などを用いることもできる。
【0047】
図3は、電子マネーカード7のハードウェア的な構成の一例を模式的に表したブロック図である。
電子マネーカード7は、アンテナ701とICチップ702を内蔵したプラスチックカードである。
本実施の形態では、電子マネーカード7として非接触型ICカードを用いるものとするが、接触型ICカードによって構成することも可能である。この場合、電子マネーカード7は、アンテナ701の代わりにICチップ702にアクセスするための接触端子を備える。加盟店端末もこの接触端子に接続する端子を備え、これら端子を介して電子マネーカード7と加盟店端末が通信を行う。
【0048】
アンテナ701は、リーダライタ5bが備えたアンテナと無線通信を行うための素子である。
アンテナ701は、リーダライタ5bが放射した電波を受信すると共に、リーダライタ5bに対して電波を放射する。
また、アンテナ701は、リーダライタ5bから電力の供給を無線により受け、ICチップ702を駆動するための電力を発電する発電機能も有している。
【0049】
ICチップ702は、ROM(Read Only Memory)703、CPU(Central Processing Unit)704、高周波回路部705、RAM(Random Access Memory)706、記憶部707などの各素子を備えた一種のコンピュータである。これらの素子は1つのICチップの中に形成されている。
【0050】
CPU704は、各種のプログラムに従って情報処理を行ったり、電子マネーカード7全体の動作を制御する中央処理装置である。
ROM703は、電子マネーカード7を機能させるための基本的なプログラム(OS(Operating System)、リーダライタ5bとの通信プログラムなど)や各種データが記憶された読み取り専用メモリである。
【0051】
高周波回路部705は、アンテナ701を介してリーダライタ5bと通信を行うインターフェースである。CPU704は、高周波回路部705を介してリーダライタ5bと無線通信を行うことができる。
RAM706は、読み書き可能な揮発性のメモリであって、CPU704が各種の情報処理を行う際のワーキングエリアを提供する。本実施の形態では、例えば、CPU704が加算コマンドや減算コマンドを実行してバリューの金額を増減する際に使用する。
【0052】
記憶部707は、例えばEEPROM(Electrically Erasable and Programmable ROM)で構成され、CPU704によって情報の読み書きが可能な不揮発性のメモリである。
記憶部707には、各種のアプリケーションソフトを記憶させて(インストールして)これをCPU704に実行させ、各種の機能を電子マネーカード7に発揮させることが可能である。
本実施の形態では、CPU704に電子マネーカード7としての機能を発揮させるためのプログラムであるバリュー処理プログラムを記憶させてある。
【0053】
記憶部707には、バリュー処理プログラムが記憶されているほか、残高記憶部7b、ログデータ記憶部7c、カードID記憶部7d、取引状態保持部7eなどが形成されている。
電子マネーカード7をリーダライタ5bに近接させて駆動すると、CPU704がバリュー処理プログラムを実行し、バリュー処理部7aがソフトウェア的に構成される。これにより、残高記憶部7b、ログデータ記憶部7c、カードID記憶部7d、取引状態保持部7eにアクセスし、各種の情報処理を行うことができる。
【0054】
なお、近年はICチップ702を携帯電話などの携帯端末に内蔵させ、これら携帯端末に非接触型ICカードとしての機能を持たせる試みも行われている。
この利用形態では、ICチップ702とアンテナ701を携帯端末に備え、電子マネーカード7と同様にリーダライタ5bから無線によりアクセスすることができるほか、携帯端末が備えた表示装置にICチップ702内の情報を表示させたり、あるいは携帯端末の入力装置を介してICチップ702に情報を入力することも可能である。
以下、本実施の形態では、電子マネーカード7を用いて説明するが、これらICチップ702を内蔵した携帯端末を用いることもできる。
【0055】
図4は、センタサーバ2のハードウェア的な構成を模式的に表したブロック図である。
センタサーバ2は、制御部10にバスライン32を介して入力装置18、出力装置20、通信制御装置24、記憶装置30、などが接続して構成されている。
【0056】
制御部10は、CPU12、ROM14、RAM16などから構成されている。
CPU12は、ROM14、記憶装置30、その他に記憶されているプログラムをロードして実行する中央処理装置である。本実施の形態では、記憶装置30に記憶されている取引処理プログラムを実行し、センタサーバ2としての機能を発揮する。
【0057】
ROM14は、例えば、CPU12が機能するための基本的な制御を行うための各種プログラム、データ及びパラメータを格納した読み出し専用の不揮発性メモリである。ROM14内のプログラムは、例えば、センタサーバ2の起動時に実行される。
RAM16は、CPU12にワーキングメモリとして使用される読み書き可能なメモリであり、例えば、取引処理プログラムを実行する際に使用される。
【0058】
入力装置18は、例えばキーボード、マウスなどの入力デバイスから構成されている。
出力装置20は、例えばディスプレイなどで構成された表示装置、プリンタなどで構成された印刷装置などから構成されている。
電子マネーセンタ100のオペレータは、これら入力装置18や出力装置20を用いてセンタサーバ2にアクセスし、保守作業やプログラムのアップデートその他の作業を行うことができる。
【0059】
通信制御装置24は、センタサーバ2をネットワーク4に接続するための装置であって、モデム、ターミナルアダプタその他の接続装置によって構成されている。
通信制御装置24はCPU12によって制御され、所定のプロトコルに従って加盟店端末とデータやその他の情報の送受信を行う。
加盟店端末がオンライン端末5の場合は常時接続されており、オフライン端末6の場合は、オフライン端末6がバッチ処理を行う際に接続を受け付ける。
【0060】
記憶装置30は、読み書き可能な記憶媒体と、その記憶媒体に対してプログラムやデータを読み書きするための駆動装置によって構成されている。当該記憶媒体として主にハードディスクが使用されるが、その他に、例えば、光磁気ディスク、磁気ディスク、半導体メモリなどのほかの読み書き可能な記憶媒体によって構成することも可能である。
【0061】
記憶装置30には、各種プログラムを記憶したプログラム格納部34と各種のデータを記憶したデータ格納部36が形成されている。
プログラム格納部34には、OS40、取引処理プログラム42、…などのプログラムがインストールされている。
OS40は、ファイルの入出力や通信制御装置24の制御など、センタサーバ2を動作させる上で基本的な機能を実現するプログラムである。
【0062】
取引処理プログラム42は、センタサーバ2に、オンライン端末5を介して電子マネーカード7と通信し、例えば、以下のような処理を行わせるプログラムである。
(1)支払い処理
これは、電子マネーカード7に記憶されたバリューを商品代金などの支払い代金として決済する処理である。
この場合、センタサーバ2は、オンライン端末5から要求された減算コマンドを電子マネーカード7に送信し、これを電子マネーカード7で実行させる。
また、この際に、電子マネーカード7の取引状態とセンタサーバ2の取引状態の2つのフラグを設定しながら処理を進める。
【0063】
(2)入金処理
これは、電子マネーカード7に入金してバリュー残高を増額するものである。
この場合、センタサーバ2は、オンライン端末5から要求された加算コマンドを電子マネーカード7に送信し、これを電子マネーカード7で実行させる。
この場合も、電子マネーカード7の取引状態とセンタサーバ2の取引状態の2つのフラグを設定しながら処理を進める。
以上のように、センタサーバ2は、演算コマンド(演算命令)を送信する演算命令送信手段を備えている。
【0064】
(3)残高確認処理
これは、電子マネーカード7に記憶されているバリュー残高を提示するものである。
この場合、センタサーバ2は、残高確認コマンドを生成して電子マネーカード7に送信し、これを電子マネーカード7に実行させる。すると、電子マネーカード7は、バリュー残高をセンタサーバ2に送信するので、センタサーバ2は、これをオンライン端末5に表示させる。
また、オンライン端末5が電子マネーカード7に残高確認コマンドを入力し、これに対して電子マネーカード7が返してきたバリュー残高をオンライン端末5が表示するように構成することもできる。
(4)障害発生後の回復処理
これは、センタサーバ2と電子マネーカード7が通信を行っている際に障害が発生し、処理が中断した場合にその回復処理を行うものである。
センタサーバ2は、センタサーバ2及び電子マネーカード7の取引状態の設定状態から障害が発生した時点を判断し、その時点に応じた回復処理を行う。
センタサーバ2は、支払い処理、入金処理、及び残高確認処理を行う前に、センタサーバ2と電子マネーカード7の取引状態から前回の処理で障害が発生したか否かを確認し、障害が発生していた場合はこれを回復してから処理を続行する。このようにセンタサーバ2は、回復手段を備えている。
【0065】
次に、データ格納部36について説明する。
センタサーバ2の運用に必要な各種のデータが記憶されており、データ格納部36には、加盟店端末情報データベース44、取引情報データベース46、…などが記憶されている。
【0066】
加盟店端末情報データベース44は、各加盟店102に設置されたオンライン端末5やオフライン端末6に関する情報を記憶したデータベースである。
加盟店端末情報データベース44には、例えば、加盟店端末が設置されている加盟店102のID情報である加盟店ID、加盟店102内でオンライン端末5やオフライン端末6に設定されたID情報である端末ID、電子マネーシステム1内でオンライン端末5やオフライン端末6に一意に付与されたID情報であるシリアルID…などの情報が記憶されている。
【0067】
センタサーバ2は、加盟店102からシリアルIDを受信すると、当該オンライン端末5、又はオフライン端末6を特定でき、更に加盟店102を特定することができる。
また、オンライン端末5やオフライン端末6を特定するのに端末IDとシリアルIDの2つのID情報を付与したのは、加盟店102の便宜を図るためである。即ち、端末IDは、例えば、加盟店端末の設置順に01、02、…などと加盟店102にとって認識しやすい情報となっており、加盟店102は、加盟店内での管理や故障時の問い合わせを端末IDで行うことができる。
【0068】
取引情報データベース46は、オンライン端末5やオフライン端末6を介して電子マネーカード7に対して行った取引情報を履歴として蓄積するデータベースである。
取引情報は、電子マネーカード7に対して処理を行う際に生成されるログデータであり、オンライン端末5を介して電子マネーカード7を処理する場合はリアルタイムで生成され、オフライン端末6で処理する場合は、一旦オフライン端末6に蓄積された後、バッチ処理などでセンタサーバ2に送られてくる。
【0069】
図5は、オンライン端末5にてカードID「00001」なる電子マネーカード7を処理した場合に生成された取引情報61、62、63を時系列にて並べて示した図である。
図に示したように、取引情報はカードID52、残高53、取引額54、取引状態55、処理内容56、シリアルID57、取引日時58、…などの各項目から構成されている。
カードID52は、オンライン端末5を介して電子マネーカード7から受信したカードIDである。
【0070】
残高53は、電子マネーカード7の演算処理後のバリュー残高であり、取引額54は、演算の際に加減算した金額である。
センタサーバ2は、支払い、又は入金処理の際に電子マネーカード7からバリュー残高を受信すると共に(残高受信手段に対応)、オンライン端末5から演算コマンドの送信要求(加減算する金額が付属している)を取得する(要求取得手段に対応)。残高53は、これらの値を用いて計算されたものである。
【0071】
取引状態55は、「取引中」(反転状態に対応)と「取引完了」(初期状態に対応)のうちの何れかが選択的に設定されるフラグ情報であり、サーバフラグを構成している。
取引状態55は、センタサーバ2側の処理が開始した際に「取引中」に設定され、センタサーバ2側の処理が完了した際に「取引完了」に更新される。
【0072】
このように、センタサーバ2は、取引状態55を「取引完了」から「取引中」に反転させたり、あるいは「取引中」から「取引完了」に復帰させるサーバフラグ設定手段を備えている。
図5の例では、図中上から3番目の取引情報は取引状態55が「取引中」となっており、この取引情報に関するセンタサーバ2側の処理はまだ完了していないことがわかる。
【0073】
シリアルID57は、電子マネーカード7との通信を仲介しているオンライン端末5のシリアル番号である。このシリアル番号を加盟店端末情報データベース44と照合することにより、電子マネーカード7の処理を行った加盟店102を特定することができる。
取引日時58は、オンライン端末5と通信を行った日時である。例えば、通信開始時刻、及び通信終了時刻などが記憶されている。
【0074】
図5に示したように、カードID52「00001」で特定される電子マネーカード7に対して行った処理は取引情報として時系列的に記録される。
他のカードIDに係る電子マネーカード7に関しても同様に取引情報が蓄積される。
オンライン端末5で行った処理に関してはリアルタイムで取引情報が取引情報データベース46に記録されるが、オフライン端末6で行った処理に関しては、バッチ処理にてオフライン端末6から送信されてきてから取引情報データベース46に記録されるまでタイムラグが生じる。
【0075】
また、オフライン端末6での処理では、処理中にオフライン端末6と電子マネーカード7の間で障害が発生しないので、オフライン端末6での処理では必ずしも取引状態55の項目を設ける必要はない。
以上にセンタサーバ2について説明したが、オンライン端末5のハードウェア的な構成は、基本的にセンタサーバ2と同様である。
オンライン端末5は、加盟店102の担当者や電子マネーカード7を有する顧客などに情報を表示するための表示装置や、効果音などの音声により処理状況を通知する音声出力装置などを備えている。
【0076】
次に、図6〜図13のフローチャートを用いて、電子マネーカード7を用いた代金の支払い処理手順、及び支払い中に障害が発生した場合の回復手順などについて説明する。
ここでは、一例として20、000円チャージされた電子マネーカード7を用いて9、000円の支払いを行う場合について説明する。
【0077】
図6は、電子マネーカード7に支払い処理を施す手順を説明するためのフローチャートである。
このフローチャートでは、電子マネーカード7側とセンタサーバ2側でデータが更新される様子を説明するため、それぞれカード情報と取引情報を併記している。
【0078】
カード情報は、電子マネーカード7側で保持されているデータの論理的構成を示したものである。
カード情報は、「カードID」、「残高」、「取引額」、「取引状態」などの項目から構成されている。
これら「カードID」、「残高」、「取引額」、「取引状態」の各値は、それぞれ、バリュー処理部7a、残高記憶部7b、ログデータ記憶部7c、取引状態保持部7eに記憶されている情報を用いることができる。
【0079】
例えば、カード情報71では、カードIDが00001であり、バリュー残高が20、000円であり、また、取引状態は「取引完了」に設定されている。
カード情報71では、取引状態が「取引完了」に設定されているため、前回の処理において、電子マネーカード7側の処理は完了していることがわかる。
【0080】
このように構成されたカード情報と取引情報を参照しながら支払い処理について説明する。
まず、顧客は加盟店102の担当者(店員)に商品を提示して購入の意思表示を行う。
これに対し、担当者はバーコード読取装置などを用いて商品の代金9、000円を読み取り、これを支払額としてオンライン端末5に入力する。
すると、オンライン端末5の表示装置に図22(a)に示したような、カード確認画面が表示される。カード確認画面には、支払額が表示されるほか、「電子マネーカードをセットしてください」などと、電子マネーカード7をオンライン端末5のリーダライタ5bにセットするように促す指示が表示される。
顧客はカード確認画面の指示に従って、オンライン端末5に電子マネーカード7をセットする。
【0081】
図6に戻り、電子マネーカード7は、オンライン端末5にセットされるとリーダライタ5bの電波によって駆動され、オンライン端末5との通信を開始する(ステップ104)。
電子マネーカード7がオンライン端末5と接続されると、センタサーバ2は電子マネーカード7と通信できるようになる。
電子マネーカード7とセンタサーバ2が通信を行っている間、オンライン端末5の表示装置には、図22(b)に示したような通信中画面が表示される。これにより、顧客と加盟店102の担当者は電子マネーカード7とセンタサーバ2が通信中であることを認識することができる。
【0082】
図6に戻り、オンライン端末5は電子マネーカード7と通信を開始すると、電子マネーカード7からカードIDを読み取り、これを支払額と共にセンタサーバ2に送信する(ステップ204)。
なお、カードIDの読み取りは、オンライン端末5が電子マネーカード7にカードIDコマンドを電子マネーカード7に入力することにより行われる。
電子マネーカード7では、バリュー処理部7aがカードIDコマンドを実行し、カードID記憶部7dからカードIDを読み取ってオンライン端末5に返すようになっている。
【0083】
センタサーバ2はオンライン端末5からこれらの情報を受け付けると、電子マネーカード7に対して残高・状態確認要求を行う(ステップ304)。
この要求は、電子マネーカード7に対してバリュー残高と取引状態の送信を要求するものであり、電子マネーカード7にこれらの動作を行わせるためのコマンドを送信することにより行われる。
【0084】
電子マネーカード7は、オンライン端末5から残高・状態確認要求を受け、残高・状態確認応答を行う(ステップ106)。
この処理は、オンライン端末5から送信されてきたコマンドをバリュー処理部7aが実行して、残高記憶部7bに記憶されているバリュー残高と、取引状態保持部7eに記憶されている取引状態をセンタサーバ2に送信することにより行われる。このように、センタサーバ2は、端末フラグ受信手段(電子マネーカード7の取引状態を受信)を備えている。
【0085】
センタサーバ2は、電子マネーカード7からバリュー残高と取引状態を受信する。
そして、受信した取引状態と取引情報データベース46に記憶されている前回の取引情報の取引状態を確認し、前回の取引で障害が発生したか否かを確認する。
障害が発生していた場合は後述の方法により障害を回復する。ここでは、障害が発生しなかったものとする。
【0086】
センタサーバ2は、電子マネーカード7とセンタサーバ2側の取引情報を確認した後、今回の処理に関する取引情報81を生成して取引情報データベース46に記憶して登録する(ステップ306)。
取引情報81では、電子マネーカード7から受信したカードID、バリュー残高、及びオンライン端末5で入力された取引額などが記憶される。なお、図では処理内容、シリアルID、取引日時、…などのほかの項目は省略してある。
図に示したように、取引情報81では、カードIDが00001、残高が減算後の値で11、000円、取引額が9、000円となっている。
【0087】
なお、登録時には、取引情報81の取引状態は「取引中」に設定されている。このように、取引状態は、センタサーバ2側の処理が開始される際に「取引中」に設定される。そして、センタサーバ2側での処理が完了した際に「取引完了」に設定される。
【0088】
取引状態が「取引中」の場合は、取引情報の取引情報データベース46への記録が確定した訳ではなく、後述のように障害回復の際に無効とされる場合がある。
そのため、取引情報81で残高が減算後の値になっているが、これは、障害回復の際に利用するためであり、センタサーバ2側での減算処理が完了するのは、取引状態が「取引完了」に設定された時点である。
【0089】
次に、センタサーバ2は、電子マネーカード7に対して取引中・減算要求をおこなう(ステップ308)。
この要求は、電子マネーカード7に取引中コマンドと、支払額分の減算を実行させるための減算コマンドを送信することにより行われる。
【0090】
本実施の形態では、電子マネーカード7において、減算コマンドの実行と取引状態の更新を対応させるため、減算コマンドと取引中コマンドを共に送信することにした。即ち、取引状態が更新されたことを確認することにより、電子マネーカード7で減算コマンドが実行されたことを確認することができる。
後の入金処理でも加算コマンドと取引完了コマンドを共に電子マネーカード7に送信するのも同じ理由による。
【0091】
電子マネーカード7は、これらのコマンドを受信して実行し、取引状態を「取引中」に設定すると共に、バリュー残高を支払額分だけ減算する。この結果、カード情報71はカード情報72に更新される。図に示したように、カード情報72では、残高が11、000円と減算後の値となっており、また、取引状態は、「取引中」に設定されている。
次に、電子マネーカード7は、減算が完了し、取引状態を「取引中」に設定した旨を示す減算完了通知をセンタサーバ2に送信する(ステップ108)。
【0092】
センタサーバ2は、電子マネーカード7から減算完了通知を受信すると取引情報81の取引状態を「取引完了」に設定し、取引情報82へ更新する(ステップ310)。
これにより、センタサーバ2は、センタサーバ2側での減算処理を完了させると共に取引情報82の取引情報データベース46への登録が確定する。
【0093】
センタサーバ2は、センタサーバ2側での減算処理を完了させると、電子マネーカード7に対して取引完了設定要求を行う(ステップ312)。この要求は、電子マネーカード7に取引完了コマンドを送信することにより行われる。
これに対し、電子マネーカード7は、取引完了コマンドを受信して実行し、取引状態を「取引完了」に設定する(ステップ110)。即ち、取引状態の値を「取引中」から「取引完了」に復帰する。その結果、カード情報はカード情報73のように更新される。
電子マネーカード7は、取引完了コマンドを実行後、取引状態を「取引完了」に設定した旨を表す取引完了通知をセンタサーバ2に送信する。
【0094】
センタサーバ2は、電子マネーカード7から取引完了通知を受信すると、電子マネーカード7との処理が完了した旨を表す取引完了通知をオンライン端末5に送信する(ステップ314)。
オンライン端末5は、センタサーバ2から取引完了通知を受信して処理が完了したことを確認する(ステップ206)。
【0095】
このとき、オンライン端末5は、処理成功を表す効果音と共に表示装置に図22(c)に示したような支払い完了画面を表示する。
支払い完了画面では、カードIDと支払金額、及び支払い後のバリュー残高などが表示される。
【0096】
以上に説明した支払い処理で、電子マネーカード7とセンタサーバ2の通信に障害が発生する可能性がある箇所としては、ステップ106(障害1と呼ぶ、以下同様)、ステップ308(障害2)、ステップ108(障害3)、ステップ312(障害4)、ステップ110(障害5)がある。
なお、ステップ304で障害が発生する可能性もあるが、この場合の処理は障害1と同じであるので説明を省略する。
【0097】
以下に、これら障害1〜障害5が発生した場合の処理手順と、その回復処理手順について説明する。
図7は、障害1が発生した場合の処理手順を説明するためのフローチャートである。なお、以下では図6のフローチャートに対応するステップには同じステップ番号を付して説明を簡略化、あるいは省略することにする。
【0098】
まず、電子マネーカード7がバリュー残高と取引状態をオンライン端末5に送信する際に(ステップ106)障害1が発生した場合、センタサーバ2は、障害1を検出する(ステップ316)。
ここで、電子マネーシステム1は、タイムアウトにより障害を検出するものとする。即ち、センタサーバ2は、電子マネーカード7からの応答を受信するまでの時間を計測し、予め設定した所定時間内に応答がない場合、障害が発生したものと判断する。なお、これは一例であって他の方法により障害を検出してもよい。
【0099】
センタサーバ2は、障害1を検出すると、処理が失敗した旨を表す取引失敗通知をオンライン端末5に送信する(ステップ318)。
オンライン端末5は、センタサーバ2から取引失敗通知を受信して処理が失敗したことを確認する(ステップ208)。
オンライン端末5は、処理の失敗を確認すると取引失敗を表す効果音と共に図22(d)に示したようなエラー発生画面を表示する。
【0100】
エラー発生画面では、残高確認を指示する旨の表示が行われ、加盟店102の担当者は、電子マネーカード7の残高確認処理を行うことになる。
このように電子マネーシステム1は、エラーが発生すると残高確認を要求し、残高確認処理に伴って障害を回復するようになっている。
即ち、残高確認処理は、まずセンタサーバ2が電子マネーカード7側とセンタサーバ2側の取引状態を確認して前回の処理で障害が発生したか否かを確認する。障害が発生していない場合は残高確認を行い、障害が発生していた場合は回復処理を行った後残高確認を行う。
【0101】
なお、図6の説明では省略したが、支払い処理や後に説明する入金処理においても、まずセンタサーバ2は前回の処理で障害が発生したか否かを確認し、障害が発生していた場合はこれを回復してから支払い処理、あるいは入金処理を続行する。
【0102】
さて、障害1が発生した場合、カード情報71は未処理であり、またセンタサーバ2でも取引情報が登録される前なので回復処理を行う必要はない。このため、障害1が発生した場合は、回復処理をせずに残高確認が行われる。そして、加盟店102の担当者は、残高確認の後に支払い処理を最初から行うことになる。
【0103】
次に、図8のフローチャートを用いて障害2、及び障害3が発生した場合の処理手順を説明する。
ステップ308(障害2)、又はステップ108(障害3)で障害が発生した場合、センタサーバ2はこれを検出し(ステップ320)、オンライン端末5に対して取引失敗通知を送信する(ステップ322)。
オンライン端末5は、取引失敗通知を受信して失敗を確認し、効果音と共にエラー発生画面を表示する(ステップ210)。
【0104】
ここで障害2と障害3のうち、何れが発生したかは、カード情報と取引情報の取引状態の組合せから特定することができる。
即ち、障害2が発生した場合、カード情報はカード情報71となり、障害3が発生した場合はカード情報72となる。また、取引情報は、障害2、障害3の何れの場合でも取引情報81となる。
このためカード情報と取引情報の取引状態の組合せは、障害2が発生した場合は(取引完了、取引中)となり、障害3が発生した場合は(取引中、取引中)となる。
以下では、同様にカード情報と取引情報の取引状態の組合せをこの順序で括弧書きにて記すことにする。
【0105】
図9は、障害2が発生した場合の回復処理手順を説明するためのフローチャートである。
この処理は、オンライン端末5でエラー発生画面の指示に従って、加盟店102の担当者が電子マネーカード7の残高確認を要求することにより開始する。
【0106】
担当者は、電子マネーカード7をリーダライタ5bにセットして電子マネーカード7とオンライン端末5の通信を開始し(ステップ104)(なお、通常はエラーが発生した時点で電子マネーカード7がオンライン端末5にセットされているので、このまま引き続き残高確認処理に移行する)、オンライン端末5に設けられた残高確認ボタンを押すなどしてセンタサーバ2に残高確認を要求する(ステップ205)。
【0107】
センタサーバ2は、オンライン端末5より残高確認要求を受けて、残高・状態確認要求を電子マネーカード7に対して行い(ステップ304)、これに対し、電子マネーカード7は、残高・状態確認応答を行う(ステップ106)。
次に、センタサーバ2は、残高・状態確認応答により電子マネーカード7から送信されてきた取引状態と、前回の取引情報81の取引状態の組合せを確認する。
その結果、取引状態の組合せが(取引完了、取引中)となり、また、前回の処理が支払い処理であったため(図示しないが取引情報81に記録されている)、センタサーバ2は前回の処理が障害2により中断したと判断する。
【0108】
障害2が発生した場合、センタサーバ2は、取引情報81の取引状態を「取引回復」に設定することにより状態回復を行う。
センタサーバ2は、取引状態が「取引回復」に設定されている取引情報は無効になったものとして扱うように構成されており、その結果、前々回の取引情報80が電子マネーカード7に対して最新の取引情報となる。
換言すればセンタサーバ2は前回の取引情報81を前々回の取引情報80に更新することにより障害回復を行う(ステップ324)。
【0109】
センタサーバ2は、取引情報を更新した後、障害回復を行った旨を表す障害回復通知をオンライン端末5に送信する(ステップ326)。オンライン端末5はこれを受信して障害が回復したことを確認する(ステップ212)。
なお、本実施の形態では、障害回復通知として電子マネーカード7のバリュー残高を送信し、オンライン端末5ではバリュー残高が表示されるようになっている。即ち、残高確認と共に障害回復を行っている。
【0110】
そして、加盟店102の担当者は残高確認を行った後、支払い処理を再度最初から行う。
このように、障害2が発生した場合はカード情報が更新前のままであるので、取引情報を更新前のものに戻すことにより、両者の整合性をとることができる。
【0111】
図10は、障害3が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ104〜ステップ106までは障害2の場合と同様である。
そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報81の取引状態の組合せを確認し、取引状態の組合せが(取引中、取引中)であり、また前回の取引が支払い処理であったことから、前回の処理が障害3により中断したと判断する。
【0112】
障害3が発生した場合、センタサーバ2は、前回の処理において電子マネーカード7で減算した金額分の加算を行う加算コマンドを生成し、取引完了コマンドと共に電子マネーカード7に送信する(ステップ328)。
電子マネーカード7は、この加算コマンドを実行し、前回減算した分のバリューを加算し、取引状態を「取引完了」に設定する。そして、加算処理と「取引完了」に設定した旨を表す加算完了通知をセンタサーバ2に送信する(ステップ112)。
以上の処理によりカード情報はカード情報72からカード情報71に更新される。
【0113】
センタサーバ2は、電子マネーカード7から加算完了通知を受信すると、障害2の場合と同様に取引情報81の取引状態を「取引回復」に設定して取引情報を更新する(ステップ330)。これにより、前々回の取引情報80が最新の取引情報として扱われる。
次に、センタサーバ2は、オンライン端末5に障害回復通知を送信し(ステップ332)、オンライン端末5はこれにより障害が回復したことを確認する(ステップ214)。
そして、障害3を回復した後に支払い処理を再度最初から行う。
【0114】
以上のように、障害3が発生した場合は、電子マネーカード7に障害発生時に減算したバリューを加算してバリュー残高を障害発生前の状態に戻すと共に、取引情報も障害発生時前のものに戻す。
即ち、センタサーバ2で取引情報が確定する前(取引情報が支払い後のものに更新される前)に、電子マネーカード7で減算を実行するため、電子マネーカード7に減算したバリューを戻すことにより障害発生前の状態に復帰することができる。
【0115】
図11は、障害4、及び障害5が発生した場合の処理手順を説明するためのフローチャートである。
ステップ104〜ステップ310までは図6のフローチャートと同様である。センタサーバ2は、取引情報を取引情報82に更新した後(ステップ310)、電子マネーカード7に宛てて取引完了コマンドを送信する(ステップ312)。
【0116】
その後、障害4又は障害5が発生した場合、センタサーバ2はこれらの何れかの障害が発生したことを検出し(ステップ334)、オンライン端末5に対して取引失敗通知を行う(ステップ336)。
そして、オンライン端末5は、取引処理失敗を表す効果音と共に表示装置にエラー発生画面を表示する(ステップ216)。
【0117】
カード情報は障害4が発生した場合はカード情報72となり、障害5が発生した場合はカード情報73となる。また、取引情報は何れの場合も取引情報82である。
その結果、取引状態の組合せは、障害4の場合は(取引中、取引完了)となり、障害5の場合は(取引完了、取引完了)となる。
【0118】
図12は、障害4が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ104〜ステップ106までは障害2の場合と同様である。
そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報82の取引状態の組合せを確認し、取引状態の組合せが(取引中、取引完了)であり、また前回の取引が支払い処理であったことから、前回の処理が障害4により中断したと判断する。
【0119】
障害4が発生した場合は、電子マネーカード7とセンタサーバ2の何れも減算処理は完了しており、カード情報72の取引状態が不整合であるだけなのでこれを「取引中」から「取引完了」に復帰させることにより障害回復を行う。
そのため、センタサーバ2は電子マネーカード7に取引完了設定要求を行う(ステップ338)。この取引完了設定要求は、電子マネーカード7に取引完了コマンドを送信することにより行われる。
【0120】
電子マネーカード7は、取引完了コマンドを受信して実行し、カード情報72の取引状態を「取引完了」に設定する。これにより、カード情報はカード情報72からカード情報73に更新される。
そして、電子マネーカード7は、取引完了通知をセンタサーバ2に送信する(ステップ114)。
センタサーバ2は、取引完了通知を受信した後、障害回復通知をオンライン端末5に送信し(ステップ340)、オンライン端末5は、これを受信して障害4が回復されたことを確認する(ステップ218)。
【0121】
図13は、障害5が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ104〜ステップ106までは障害2の場合と同様である。
そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報82の取引状態の組合せを確認し、取引状態の組合せが(取引完了、取引完了)であり、また前回の取引が支払い処理であったことから、前回の処理が障害5により中断したと判断する。
【0122】
障害5が発生した場合は、カード情報と取引情報の何れも支払い処理後のものに更新されており、カード情報が更新されたことをセンタサーバ2が確認できていなかっただけなので、特に回復処理を行う必要はない。
そのため、センタサーバ2は、特に回復処理を行わずにオンライン端末5に障害回復通知を送信し(ステップ342)、オンライン端末5は、これにより障害が回復したことを確認する(ステップ220)。
【0123】
次に、図14〜図20のフローチャートを用いて、電子マネーカード7を用いた入金処理手順、及び入金中に障害が発生した場合の回復手順などについて説明する。
ここでは、一例として20、000円チャージされた電子マネーカード7に9、000円の入金を行う場合について説明する。
【0124】
図14は入金処理の手順を説明するためのフローチャートである。
入金処理の場合、まず顧客は加盟店102の担当者に現金9、000円を渡し、9、000円分の入金を依頼する。
担当者は、顧客から現金9、000円を受領すると共に、9、000円を入金額としてオンライン端末5に入力する。
すると、オンライン端末5の表示装置にカード確認画面が表示されるので、顧客は画面の指示に従って電子マネーカード7をリーダライタ5bにセットする。
【0125】
電子マネーカード7は、オンライン端末5にセットされると、オンライン端末5のリーダライタ5bから放射される電波によって駆動され、オンライン端末5との通信を開始する(ステップ504)。
電子マネーカード7がオンライン端末5と接続されると、センタサーバ2は電子マネーカード7と通信できるようになり、オンライン端末5の表示装置には通信中画面が表示される。
【0126】
オンライン端末5は電子マネーカード7と通信を開始すると、電子マネーカード7からカードIDを読み取り、これを入金額と共にセンタサーバ2に送信する(ステップ604)。
センタサーバ2はこれらの情報を受け付けると、電子マネーカード7に対して残高・状態確認要求を行う(ステップ704)。
電子マネーカード7は、これを受け、残高・状態確認応答を行う(ステップ506)。
【0127】
センタサーバ2は、電子マネーカード7から残高・状態確認応答を受けると、前回の処理で障害が発生したか否かを確認し、障害が発生していた場合は、これを回復してから処理を続行する。障害回復処理については後述し、ここでは、障害が発生しなかったものとする。
【0128】
センタサーバ2は、前回の処理で障害が発生していないことを確認した後、この処理に関する取引情報86を生成して取引情報データベース46に登録する(ステップ706)。
取引情報86では、残高が入金後の金額となっているが、取引状態が「取引中」に設定されており、取引情報データベース46への登録はまだ確定していない。即ち、センタサーバ2ではまだ加算処理は完了していない。
【0129】
次に、センタサーバ2は、電子マネーカード7に対して取引中設定要求を行う(ステップ708)。
電子マネーカード7は取引中設定要求を受けて取引状態を「取引中」に設定し、取引中設定通知をセンタサーバ2に送信する(ステップ508)。これにより、カード情報76は、カード情報77に更新される。
【0130】
センタサーバ2は、電子マネーカード7から取引中設定通知を受信すると取引状態を「取引完了」に設定し、これによって取引情報86を取引情報87に更新する(ステップ710)。
取引状態を「取引完了」に設定することにより取引情報87の取引情報データベース46への登録が確定し、センタサーバ2で加算が行われたことになる。
【0131】
次に、センタサーバ2は、電子マネーカード7に取引完了設定・加算要求を行う(ステップ714)。これは、入金額分の加算を行う加算コマンドと取引完了コマンドを共に電子マネーカード7に送信することにより行われる。
電子マネーカード7は、これらのコマンドを受信し、加算コマンドを実行して、バリュー残高を9、000増加させると共に、取引状態を「取引完了」に設定する。そして、加算処理と「取引完了」に設定した旨を表す加算完了通知をセンタサーバ2に送信する(ステップ510)。
【0132】
加算コマンドと取引完了コマンドの実行によりカード情報77はカード情報78に更新される。
図に示したようにカード情報78は、バリュー残高が29、000円となり、取引状態が「取引完了」に設定されている。
【0133】
センタサーバ2は、電子マネーカード7から加算完了通知を受信すると、取引完了通知をオンライン端末5に送信する(ステップ716)。
オンライン端末5は、センタサーバ2から取引完了通知を受信して処理が完了したことを確認する(ステップ606)。
このとき、オンライン端末5は、処理成功を表す効果音と共に表示装置に入金完了画面が表示される。
【0134】
図14に示した入金処理で、電子マネーカード7とセンタサーバ2の通信に障害が発生する可能性がある箇所としては、ステップ506(障害6)、ステップ708(障害7)、ステップ508(障害8)、ステップ714(障害9)、ステップ510(障害10)がある。
なお、ステップ704で障害が発生する可能性もあるが、この場合の処理は障害6と同じであるので説明を省略する。
【0135】
以下に、これら障害6〜障害10が発生した場合の処理手順と、回復処理手順について説明する。
図15は、障害6が発生した場合の処理手順を説明するためのフローチャートである。
なお、以下では図15のフローチャートに対応するステップには同じステップ番号を付して説明を簡略化、あるいは省略することにする。
【0136】
まず、電子マネーカード7がバリュー残高と取引状態をセンタサーバ2に送信する際に(ステップ506)障害6が発生した場合、センタサーバ2は、障害6を検出する(ステップ718)。
センタサーバ2は、障害6を検出すると、取引処理が失敗した旨を表す取引失敗通知をオンライン端末5に送信する(ステップ720)。
【0137】
オンライン端末5は、センタサーバ2から取引失敗通知を受信して処理が失敗したことを確認する(ステップ608)。
このとき、オンライン端末5は、取引失敗を表す効果音と共にエラー発生画面を表示する。エラー発生画面には残高確認を指示する旨の通知が行われ、加盟店102の担当者は、電子マネーカード7の残高確認処理を行うことになる。
【0138】
さて、障害6が発生した場合、カード情報76は未処理であり、またセンタサーバ2でも取引情報が登録される前なので回復処理を行う必要はない。このため、障害6が発生した場合は、回復処理をせずに残高確認が行われる。そして、加盟店102の担当者は、残高確認の後に処理を最初から行うことになる。
【0139】
図16は、障害7、及び障害8が発生した場合の処理手順を説明するためのフローチャートである。
ステップ708(障害7)、又はステップ508(障害8)で障害が発生した場合、センタサーバ2はこれを検出し(ステップ718)、オンライン端末5に対して取引失敗通知を送信する(ステップ720)。
オンライン端末5は、取引失敗通知を受信して失敗を確認し、効果音と共にエラー発生画面を表示する(ステップ608)。
【0140】
ここで障害7と障害8のうち、何れが発生したかは、カード情報と取引情報の取引状態の組合せから特定する。
即ち、障害7が発生した場合、カード情報はカード情報76となり、障害8が発生した場合はカード情報77となる。また、取引情報は、障害7、障害8の何れの場合でも取引情報86となる。
このためカード情報と取引情報の取引状態の組合せは、障害7が発生した場合は(取引完了、取引中)となり、障害8が発生した場合は(取引中、取引中)となる。
【0141】
図17は、障害7が発生した場合の回復処理手順を説明するためのフローチャートである。
この処理は、オンライン端末5でエラー発生画面の指示に従って、加盟店102の担当者が電子マネーカード7の残高確認を要求することにより開始する。
【0142】
担当者は、電子マネーカード7をリーダライタ5bにセットして電子マネーカード7とオンライン端末5の通信を開始し(ステップ504)(なお、通常はエラーが発生した時点で電子マネーカード7がオンライン端末5にセットされているので、このまま引き続き残高確認処理に移行する)、オンライン端末5に設けられた残高確認ボタンを押すなどしてセンタサーバ2に残高確認を要求する(ステップ605)。
【0143】
センタサーバ2は、オンライン端末5より残高確認要求を受けて、残高・状態確認要求を電子マネーカード7に対して行い(ステップ704)、これに対し、電子マネーカード7は、残高・状態確認応答を行う(ステップ506)。
次に、センタサーバ2は、残高・状態確認応答により電子マネーカード7から送信されてきた取引状態と、前回の取引情報86の取引状態の組合せを確認する。
その結果、取引状態の組合せが(取引完了、取引中)となり、また、前回の処理が入金処理であったため(図示しないが取引情報86に記録されている)、センタサーバ2は前回の処理が障害7により中断したと判断する。
【0144】
すると、センタサーバ2は、取引情報86の取引状態を「取引回復」に設定し、取引情報86を取引情報88に更新する。
センタサーバ2は、取引状態が「取引回復」に設定されている取引情報は無効になったものとして扱うため、前々回の取引情報85が最新の取引情報として復活する。
換言すればセンタサーバ2は前回の取引情報86を前々回の取引情報85に更新することにより障害回復を行う(ステップ722)。
【0145】
センタサーバ2は、取引情報を更新した後、障害回復を行った旨を表す障害回復通知をオンライン端末5に送信する(ステップ724)。オンライン端末5はこれを受信して障害が回復したことを確認する(ステップ610)。
そして、加盟店102の担当者は残高確認を行った後、入金処理を再度最初から行う。
【0146】
図18は、障害8が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ504〜ステップ506までは障害7と同様である。
そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報86の取引状態の組合せを確認し、取引状態の組合せが(取引中、取引中)であり、また前回の取引が入金処理であったことから、前回の処理が障害8により中断したと判断する。
【0147】
障害8が発生した場合、電子マネーカード7とセンタサーバ2の何れも加算処理が完了していないので、カード情報と取引情報を入金処理前の状態に戻すことにより障害回復を行う。
そのため、センタサーバ2は、電子マネーカード7に対して取引完了設定要求を行う(ステップ726)。この要求は、電子マネーカード7に取引完了コマンドを送信することにより行われる。
【0148】
これに対し、電子マネーカード7は、取引状態を「取引完了」に設定し、センタサーバ2に取引完了設定通知を送信する(ステップ512)。
これにより、カード情報はカード情報77からカード情報76に戻される。
【0149】
センタサーバ2は、電子マネーカード7から取引完了通知を受信すると、取引情報86の取引状態を「取引回復」に設定して取引情報88に更新する(ステップ728)。これにより、取引情報88は無効な取引情報となり、前々回の取引情報85が最新の取引情報として復活する。
次に、センタサーバ2は、オンライン端末5に処理回復通知を送信し(ステップ730)、オンライン端末5はこれにより障害が回復したことを確認する(ステップ612)。
その後、加盟店102の担当者は入金処理を最初からやり直す。
【0150】
図19は、障害9、及び障害10が発生した場合の処理手順を説明するためのフローチャートである。
ステップ504〜ステップ710は図14のフローチャートと同様である。
センタサーバ2は、取引情報を取引情報87に更新した後(ステップ714)、電子マネーカード7に宛てて取引完了コマンドと加算コマンドを送信する(ステップ714)。
【0151】
その後、障害9又は障害10が発生した場合、センタサーバ2はこれらの何れかの障害が発生したことを検出し(ステップ732)、オンライン端末5に対して取引失敗通知を行う(ステップ734)。
そして、オンライン端末5は、取引処理失敗を表す効果音と共に表示装置にエラー発生画面を表示する(ステップ614)。
【0152】
カード情報は障害9が発生した場合はカード情報77となり、障害10が発生した場合はカード情報78となる。また、取引情報は何れの場合も取引情報87である。
その結果、取引状態の組合せは、障害9の場合は(取引中、取引完了)となり、障害10の場合は(取引完了、取引完了)となる。
【0153】
図20は、障害9が発生した場合の回復処理手順を説明するためのフローチャートである。
ステップ504〜ステップ506までは障害6の場合と同様である。
そして、センタサーバ2は、電子マネーカード7から送信されてきた取引状態と、前回の取引情報87の取引状態の組合せを確認し、取引状態の組合せが(取引中、取引完了)であり、また前回の取引が入金処理であったことから、前回の処理が障害9により中断したと判断する。
【0154】
障害9の場合、センタサーバ2では加算処理が完了し、電子マネーカード7ではまだ加算処理が行われていない状態であるため、電子マネーカード7に加算処理を行わせることにより回復処理を行う。
まず、センタサーバ2は、電子マネーカード7に対して取引完了設定・加算要求を再度行う(ステップ736)。
【0155】
電子マネーカード7は、これに応じて加算処理を行うと共に取引状態を「取引完了」に設定し、センタサーバ2に加算完了通知を送信する(ステップ514)。これにより、カード情報77はカード情報78に更新される。
センタサーバ2は、加算完了通知を受信した後、障害回復通知をオンライン端末5に送信し(ステップ738)、オンライン端末5は、これを受信して障害9が回復したことを確認する(ステップ616)。
【0156】
次に、障害10の回復処理について説明する。障害10では、電子マネーカード7とセンタサーバ2の何れでも加算処理が完了しており、また取引状態も共に「取引完了」に設定されているため状態回復処理を行う必要はない。
そのため、障害10の場合は障害回復を行うことなくそのまま残高確認が行われる。
【0157】
以上に説明したように、電子マネーシステム1では、支払い処理を行う場合は、電子マネーカード7で減算処理を行った後(図6ステップ108)、センタサーバ2で減算処理を行い(図6ステップ310)、また、入金処理を行う場合は、センタサーバ2で加算処理を行った後(図14ステップ710)、電子マネーカード7で加算を行っている(図14ステップ510)。
【0158】
そのため、障害により電子マネーカード7とセンタサーバ2でバリュー残高の食い違いが生じた場合(障害3、障害9)、何れも電子マネーカード7に対して加算処理を行うことにより回復処理を行うことができる。
このように、障害回復を行う場合は、電子マネーカード7への処理は減算処理となることはないので顧客は安心して電子マネーカード7を使用することができる。
【0159】
また、以上の例では、残高確認を行う際に併せて障害回復を行うこととしたが、顧客と加盟店102の担当者の何れもが障害が発生したことに気づかず、障害回復を行わない場合もあり得る。
センタサーバ2は、支払い処理、入金処理の際に、これらの処理に先立って前回の処理で障害が発生したか否かを確認するため、例え、前回の取引で障害回復を行わなかったとしても、今回の取引で障害回復を行ってから処理を行うことができる。
【0160】
次に、障害回復を行っていない電子マネーカード7(以下、未回復カードと呼ぶ)をオフライン端末6で使用する場合について説明する。
未回復カードを用いてオフライン端末6で支払いを行う場合は、特に制限することなく使用できる。何れの障害が発生しても未回復カードに記憶されているバリューの残高は、顧客が本来有しているバリュー残高以下であるので、これから減算しても不都合は生じないからである。
また、センタサーバ2は、取引情報で障害回復するため、未回復カードをオフライン端末6で使用して支払いを行った後、この未払いカードをオンライン端末5にセットして障害回復を行うこともできる。
【0161】
一方、未回復カードに入金を行う場合には不都合が生じる場合がある。即ち、電子マネーカード7が記憶できるバリュー残高には上限値が設けられているため、未回復カードに入金を行うとバリュー残高がこの上限値を超える場合が生じる可能性がある。
例えば、バリューの上限値が5万円であるとする。そして、現在未回復カードに記憶されているバリューが4万円であるが、障害を回復すると5千円加算されるとする。
【0162】
顧客が未回復カードに1万円を入金してバリュー残高5万円とした後、障害を回復するとバリュー残高が5万5千円となり上限値を越えてしまう。
そのため、オフライン端末6は、電子マネーカード7に入金を行う前に、電子マネーカード7が未回復カードか否かを確認し、未回復カードである場合は、入金を制限するようになっている。
【0163】
図21は、オフライン端末6で電子マネーカード7に入金を行う手順を説明するためのフローチャートである。なお、以下のようにオフライン端末6は、演算命令入力装置を構成している。
電子マネーカード7は、オフライン端末6のリーダライタにセットされているものとする。
まず、加盟店102の担当者は、オフライン端末6に入金額を入力する(ステップ904)。これは、加算金額取得手段に対応する。
【0164】
すると、オフライン端末6は、電子マネーカード7に対して残高・状態確認要求を行い(ステップ906)、これに対し、電子マネーカード7は、オフライン端末6に対して残高・状態確認応答を行う(ステップ804)。このように、センタサーバ2は、電子マネーカード7から取引状態を受信し、これは端末フラグ受信手段に対応する。
【0165】
オフライン端末6は、電子マネーカード7から受信した取引状態が「取引完了」と「取引中」の何れであるかを判断する(ステップ908)。
取引状態が「取引完了」であった場合(ステップ908;Y)、オフライン端末6は、加算コマンドを生成して電子マネーカード7に入力し、入金処理を行う(ステップ806)。
【0166】
一方、取引状態が「取引中」であった場合(ステップ908;N)、オフライン端末6は、入金処理をせずにアラームを発する(ステップ1000)。
このような、オフライン端末6は、加算命令生成手段と、取引状態が「取引中」であった場合、電子マネーカード7への入力を制限する加算命令入力手段を備えている。
【0167】
このように、オフライン端末6は、電子マネーカード7の取引状態を確認することにより、電子マネーカード7が未回復カードか否かを判断することができ、また、未回復カードであった場合は、入金処理を制限する(本実施の形態では入金処理を全く行わない)。
【0168】
なお、本実施の形態では、未回復カードに関しては、入金額を制限するように構成することも可能である。
即ち、障害により電子マネーカード7に記憶されているバリュー残高が、実際にユーザが保有しているバリュー残高より少なくなる場合は、障害3、及び障害9が発生した場合である。
この場合に、障害回復により加算される可能性のある金額を見越して、オフライン端末6で入金できる金額の上限を動的に制限することができる。
【0169】
即ち、電子マネーカード7のカード情報から、回復処理にて加算処理が行われた場合、その加算額は「取引額」に記憶されている金額である。障害の種類によりこの金額がバリュー残高に加算されるかもしれないし、又は加算されないかもしれないが、オフライン端末6は、少なくとも加算されるこの金額分だけ残高が加算される可能性があることがわかる。
そこで、オフライン端末6は、上限値からこの金額を減じた金額をこの電子マネーカード7の上限値として設定すればよい。
【0170】
以上、本実施の形態の一例について説明したが、各種の変形例が可能である。
障害が発生した場合、それが電子マネーカード7で演算が行われた後に発生したのか、あるいは前に障害が発生したのかが最低限わかれば障害回復を行うことができる。そこでここではそのための条件について考える。
【0171】
図23(a)に示したように本実施の形態では、ステップ1〜ステップ4の通信のタイミングがある。
即ち、センタサーバ2は、ステップ1で取引中コマンドを送信し、ステップ2で取引中設定通知を受信し、更にステップ3で取引完了コマンドを送信し、ステップ4で取引完了通知を受信する。
【0172】
電子マネーカード7に演算命令を送信するタイミングは、ステップ1とステップ3があり、図23(a)は、ステップ1で演算コマンドを送信する場合を示している。
ステップ2、3で障害が発生した場合は、電子マネーカード7の取引状態は「取引中」になっている。即ち、電子マネーカード7の取引状態が「取引中」であることさえわかれば、電子マネーカード7で演算処理後に障害が発生したことがわかる。そのため、ステップ2とステップ3を必ずしも識別する必要はない。
【0173】
一方、電子マネーカード7の取引状態が「取引完了」であった場合、演算処理前に障害が発生したのか(ステップ1)、あるいは演算処理後に障害が発生したのか(ステップ4)識別することができない。そのため、ステップ1〜ステップ4の間でセンタサーバ2の取引状態を(奇数回)反転させると、ステップ1での障害とステップ4での障害を区別することができる。
ここで、取引状態を反転させるとは、取引状態を「取引完了」→「取引中」、又は「取引中」→「取引完了」に設定することを意味する。
【0174】
このように、構成すると、電子マネーカード7とセンタサーバ2の取引状態の組合せだけから電子マネーカード7で演算処理が行われたか否かを判断することができる。
そして、更に、センタサーバ2で取引状態を反転させる際に、センタサーバ2で記憶しているバリュー残高を更新することにより、センタサーバ2で記憶しているバリュー残高が更新前のものかあるいは後のものかを取引状態から判断することができる。
【0175】
図23(b)は、ステップ3で演算コマンドを送信する場合を示している。この場合は、電子マネーカード7の取引情報が「取引中」である場合は、演算処理前に障害が発生したことがわかる。
一方取引情報が「取引完了」であった場合、これだけでは演算処理前に障害が発生したのか(ステップ1)、あるいは演算処理後に障害が発生したのか(ステップ4)を識別することができない。そのため、ステップ1〜ステップ4の間でセンタサーバ2側の取引状態を反転させれば、何れで障害が発生したのか特定することができる。また、その反転の際にセンタサーバ2側で記憶しているバリュー残高の更新も行う。
【0176】
以上をまとめると、電子マネーカード7の取引状態を「取引中」か「取引完了」に設定させる際に演算コマンドも一緒に送信し、電子マネーカード7に取引中コマンドを送信してから(ステップ1)、取引完了通知を受信するまで(ステップ4)にセンタサーバ2の取引状態を反転させ、更に、反転の際にセンタサーバ2側で記憶しているバリュー残高を更新すればよいことになる。
【0177】
即ち、センタサーバ2は、電子マネーカード7の取引状態を反転させる取引中コマンドを送信し、電子マネーカード7がこれを実行して取引状態が「取引中」に反転されたことを確認した後、取引完了コマンドを電子マネーカード7に送信して電子マネーカード7の取引状態を「取引完了」に復帰させ、前記取引中コマンド又は取引完了コマンドを送信する際に、演算コマンドも送信し、電子マネーカード7に取引中コマンドを送信してから、電子マネーカード7の取引状態が「取引完了」に復帰したことを確認するまでの間に、センタサーバ2の取引状態を反転又は復帰させ、その際にセンタサーバ2残高更新を確定すればよい。
以上の範囲内で、電子マネーシステム1は、各種変形可能である。
【0178】
以上に説明した電子マネーシステム1により、次のような効果を得ることができる。
(1)電子マネーカード7とセンタサーバ2の取引状態の組合せから、発生した障害を特定することができる。
(2)取引状態の組合せから障害の種類を特定するため、オンライン端末5とオフライン端末6が混在した電子マネーシステム1(バリュー残高が電子マネーカード7とセンタサーバ2で必ずしも一致しない)で障害の種類を特定することができる。
【0179】
(3)支払い処理の場合は、電子マネーカード7で減算した後、センタサーバ2の取引情報を更新し、入金処理の場合は、センタサーバ2で取引情報を更新した後電子マネーカード7で加算処理するため、何れの場合も電子マネーカード7へは加算処理にて回復処理を行うことができる。
(4)電子マネーカード7での処理が終了していない場合は、取引状態が「取引中」に設定されるため、オフライン端末6にて未回復カードを識別することができる。
(5)オフライン端末6は、未回復カードへの入金機能が制限されているため、バリュー残高限度を超えて電子マネーカード7に入金されることを防ぐことができる。
【0180】
以上、本実施の形態の一例について説明したが、各種の変形が可能である。
例えば、オンライン端末5を、インターネット接続可能なパーソナルコンピュータにより構成し、顧客の自宅に設置しても良い。この場合、顧客は自宅の通信で電子マネーカード7の処理に障害が発生したことに気づかずに加盟店102に行ったとしても、オンライン端末5にて障害を回復することができる。
【0181】
また、本実施の形態では、センタサーバ2が加算コマンド、減算コマンドを電子マネーカード7に送信し、電子マネーカード7はこれらコマンドを実行して記憶している残高を更新したが、残高の演算はセンタサーバ2で行うように構成することもできる。
【0182】
この場合、センタサーバ2は、電子マネーカード7が記憶している残高を電子マネーカード7から取得し、これに加減算処理を行って加減算処理後の金額を算出する。
そして、センタサーバ2は、算出した金額を電子マネーカード7に送信し、電子マネーカード7は、記憶している残高をセンタサーバ2から受信した金額に更新する。
【0183】
このように、加減算処理は、センタサーバ2で行っても電子マネーカード7で行ってもよく、あるいは、加算に関してはセンタサーバ2で行い、減算に関しては電子マネーカード7で行うというように、加減算の一方をセンタサーバ2で行い、他方を電子マネーカード7で行うように構成することもできる。
【0184】
センタサーバ2が加算コマンド、減算コマンドを電子マネーカード7に送信し、電子マネーカード7で加減算を行う場合、加算コマンド、減算コマンドは金額変更情報を構成している。
センタサーバ2が加減算後の金額を計算し、電子マネーカード7がこれを用いて金額を更新する場合、センタサーバ2が電子マネーカード7に送信する加減算後の金額が金額変更情報に該当する。
【0185】
このように、センタサーバ2が送信した金額変更情報によって電子マネーカード7の残高が増減されるとした場合、バリュー処理部7aは、金額変更情報を用いて残高金額を金額変更処理する金額変更手段を構成している。
また、センタサーバ2は、演算コマンドや演算後の金額などの金額変更情報を送信する金額変更情報送信手段を備えている。
【0186】
更に、オフライン端末6は、金額変更情報入力装置を構成している。
即ち、オフライン端末6は、ステップ904にて入金額を取得するが、これは増額金額を取得する増額金額取得手段を構成している。
また、オフライン端末6は、ステップ806にて入金処理を行うが、これは入力された増額金額分の貨幣価値を増額する金額変更情報を生成する金額変更情報生成手段を構成している。
【0187】
更に、オフライン端末6は、電子マネーカード7の取引状態が「取引完了」であった場合は生成した金額変更情報を電子マネーカード7に入力し、「取引中」であった場合は金額変更情報の入力を制限する金額変更情報入力手段を備えている。
【符号の説明】
【0188】
1 電子マネーシステム
2 センタサーバ
5 オンライン端末
6 オフライン端末
100 電子マネーセンタ
102 加盟店
【特許請求の範囲】
【請求項1】
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、
前記貨幣端末から残高金額を受信する残高受信手段と、
前記貨幣端末に対する演算命令の送信要求を取得する要求取得手段と、
前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、
前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信手段と、
前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、
前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、
を具備したことを特徴とする貨幣端末処理サーバ。
【請求項2】
前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、
前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記演算処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、
を具備したことを特徴とする請求項1に記載の貨幣端末処理サーバ。
【請求項3】
前記演算命令として減算命令を送信する場合、前記残高更新手段は、前記貨幣端末での前記減算命令の実行を確認した後に前記残高金額を更新し、前記演算命令として加算命令を送信する場合、前記演算命令送信手段は、前記残高金額を更新した後に前記加算命令を送信し、
前記回復手段は、前記貨幣端末で当該減算命令が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減算した分の金額を加算させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で当該加算命令を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に加算させることにより回復処理を行うことを特徴とする請求項2に記載の貨幣端末処理サーバ。
【請求項4】
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う貨幣情報処理方法であって、
前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、演算命令送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、
前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、
前記要求取得手段によって、前記貨幣端末に対する演算命令の送信要求を取得する要求取得ステップと、
前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、
前記演算命令送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信ステップと、
前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、
前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、
から構成されたことを特徴とする貨幣端末処理方法。
【請求項5】
請求項1の貨幣端末処理サーバが演算命令を送信する貨幣端末であって、
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、
所定の演算命令を実行して前記残高金額を演算処理する演算手段と、
端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、
前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、
を具備したことを特徴とする貨幣端末。
【請求項6】
請求項5に記載の貨幣端末に前記加算命令を入力する演算命令入力装置であり、
加算金額を取得する加算金額取得手段と、
前記取得した加算金額分の貨幣価値を加算する加算命令を生成する加算命令生成手段と、
前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、
前記端末フラグが初期状態であった場合は、前記生成した加算命令を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記加算命令の前記貨幣端末への入力を制限する加算命令入力手段と、
を具備したことを特徴とする演算命令入力装置。
【請求項7】
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、
前記貨幣端末から残高金額を受信する残高受信手段と、
前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得手段と、
前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、
前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信手段と、
前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、
前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、
を具備したことを特徴とする貨幣端末処理サーバ。
【請求項8】
前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、
前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記金額変更処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、
を具備したことを特徴とする請求項7に記載の貨幣端末処理サーバ。
【請求項9】
前記金額変更情報として金額を減額する金額変更情報を送信する場合、前記残高更新手段は、前記貨幣端末での金額変更処理の実行を確認した後に前記残高金額を更新し、前記金額変更情報として金額を加算する金額変更情報を送信する場合、前記金額変更情報送信手段は、前記残高金額を更新した後に前記金額変更情報を送信し、
前記回復手段は、前記貨幣端末で金額を減額する金額変更処理が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減額した分の金額を増額させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で金額を増額する金額変更処理を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に増額させることにより回復処理を行うことを特徴とする請求項8に記載の貨幣端末処理サーバ。
【請求項10】
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う情報処理方法であって、
前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、金額変更情報送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、
前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、
前記要求取得手段によって、前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得ステップと、
前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、
前記金額変更情報送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信ステップと、
前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、
前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、
から構成されたことを特徴とする貨幣端末処理方法。
【請求項11】
請求項7の貨幣端末処理サーバが金額変更情報を送信する貨幣端末であって、
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、
所定の金額変更情報を用いて前記残高金額を金額変更処理する金額変更手段と、
端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、
前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、
を具備したことを特徴とする貨幣端末。
【請求項12】
請求項11に記載の貨幣端末に前記残高金額を増額する金額変更情報を入力する金額変更情報入力装置であり、
前記増額金額を取得する増額金額取得手段と、
前記取得した増額金額分の貨幣価値を増額する金額変更情報を生成する金額変更情報生成手段と、
前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、
前記端末フラグが初期状態であった場合は、前記生成した金額変更情報を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記金額変更情報の前記貨幣端末への入力を制限する金額変更情報入力手段と、
を具備したことを特徴とする金額変更情報入力装置。
【請求項1】
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、
前記貨幣端末から残高金額を受信する残高受信手段と、
前記貨幣端末に対する演算命令の送信要求を取得する要求取得手段と、
前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、
前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信手段と、
前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、
前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、
を具備したことを特徴とする貨幣端末処理サーバ。
【請求項2】
前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、
前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記演算処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、
を具備したことを特徴とする請求項1に記載の貨幣端末処理サーバ。
【請求項3】
前記演算命令として減算命令を送信する場合、前記残高更新手段は、前記貨幣端末での前記減算命令の実行を確認した後に前記残高金額を更新し、前記演算命令として加算命令を送信する場合、前記演算命令送信手段は、前記残高金額を更新した後に前記加算命令を送信し、
前記回復手段は、前記貨幣端末で当該減算命令が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減算した分の金額を加算させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で当該加算命令を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に加算させることにより回復処理を行うことを特徴とする請求項2に記載の貨幣端末処理サーバ。
【請求項4】
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の演算命令を実行して前記残高金額を演算処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う貨幣情報処理方法であって、
前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、演算命令送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、
前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、
前記要求取得手段によって、前記貨幣端末に対する演算命令の送信要求を取得する要求取得ステップと、
前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、
前記演算命令送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記演算命令を送信する演算命令送信ステップと、
前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、
前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、
から構成されたことを特徴とする貨幣端末処理方法。
【請求項5】
請求項1の貨幣端末処理サーバが演算命令を送信する貨幣端末であって、
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、
所定の演算命令を実行して前記残高金額を演算処理する演算手段と、
端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、
前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、
を具備したことを特徴とする貨幣端末。
【請求項6】
請求項5に記載の貨幣端末に前記加算命令を入力する演算命令入力装置であり、
加算金額を取得する加算金額取得手段と、
前記取得した加算金額分の貨幣価値を加算する加算命令を生成する加算命令生成手段と、
前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、
前記端末フラグが初期状態であった場合は、前記生成した加算命令を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記加算命令の前記貨幣端末への入力を制限する加算命令入力手段と、
を具備したことを特徴とする演算命令入力装置。
【請求項7】
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバであって、
前記貨幣端末から残高金額を受信する残高受信手段と、
前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得手段と、
前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定手段と、
前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信手段と、
前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定手段と、
前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新手段と、
を具備したことを特徴とする貨幣端末処理サーバ。
【請求項8】
前記貨幣端末との通信途中で障害が発生した場合に、障害発生時に前記貨幣端末で設定されていた端末フラグの状態を受信する端末フラグ受信手段と、
前記受信した端末フラグの状態と、前記障害発生時に設定されていたサーバフラグと、を用いて前記障害の発生が、前記貨幣端末が前記金額変更処理を実行する前に発生したか、あるいは後に発生したかを判断し、前記判断に応じて前記障害の回復処理を行う回復手段と、
を具備したことを特徴とする請求項7に記載の貨幣端末処理サーバ。
【請求項9】
前記金額変更情報として金額を減額する金額変更情報を送信する場合、前記残高更新手段は、前記貨幣端末での金額変更処理の実行を確認した後に前記残高金額を更新し、前記金額変更情報として金額を加算する金額変更情報を送信する場合、前記金額変更情報送信手段は、前記残高金額を更新した後に前記金額変更情報を送信し、
前記回復手段は、前記貨幣端末で金額を減額する金額変更処理が実行された後で前記残高金額の更新を行う前に障害が発生したと判断した場合は、前記貨幣端末に前記減額した分の金額を増額させて回復処理を行い、前記残高金額の更新を行った後で前記貨幣端末で金額を増額する金額変更処理を実行させる前に障害が発生したと判断した場合は、当該更新した金額分を前記貨幣端末に増額させることにより回復処理を行うことを特徴とする請求項8に記載の貨幣端末処理サーバ。
【請求項10】
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶し、所定の金額変更情報を用いて前記残高金額を金額変更処理し、端末フラグを初期状態と反転状態に選択的に記憶する貨幣端末と、前記貨幣端末と通信を行う貨幣情報処理サーバと、を用いて構成された貨幣情報処理システムで使用される貨幣情報処理サーバが行う情報処理方法であって、
前記貨幣情報処理サーバは、残高受信手段と、要求取得手段と、端末フラグ設定手段と、金額変更情報送信手段と、サーバフラグ設定手段と、残高更新手段と、を備えており、
前記残高受信手段によって、前記貨幣端末から残高金額を受信する残高受信ステップと、
前記要求取得手段によって、前記貨幣端末に対する金額変更情報の送信要求を取得する要求取得ステップと、
前記端末フラグ設定手段によって、前記貨幣端末に対して、端末フラグを反転状態に反転させる反転命令を送信し、前記貨幣端末で前記端末フラグが反転状態に反転されたことを確認した後、前記端末フラグを初期状態に復帰させる復帰命令を送信する端末フラグ設定ステップと、
前記金額変更情報送信手段によって、前記貨幣端末に前記反転命令、又は前記復帰命令を送信する際に、前記取得した送信要求によって要求された金額変更情報を送信する金額変更情報送信ステップと、
前記サーバフラグ設定手段によって、前記貨幣端末への反転命令の送信後、前記端末フラグの復帰を確認するまでの間にサーバフラグを反転、又は復帰させるサーバフラグ設定ステップと、
前記残高更新手段によって、前記サーバフラグの反転、又は復帰に伴って前記受信した残高金額を更新する残高更新ステップと、
から構成されたことを特徴とする貨幣端末処理方法。
【請求項11】
請求項7の貨幣端末処理サーバが金額変更情報を送信する貨幣端末であって、
貨幣価値の残高金額を電子データとして表した貨幣情報を記憶する貨幣情報記憶手段と、
所定の金額変更情報を用いて前記残高金額を金額変更処理する金額変更手段と、
端末フラグを初期状態と反転状態に選択的に保持する端末フラグ記憶手段と、
前記貨幣端末処理サーバから送信されてきた反転命令を実行して前記記憶した端末フラグを初期状態から反転状態に設定し、また、前記貨幣端末処理サーバから送信されてきた復帰命令を実行して前記記憶した端末フラグを反転状態から初期状態に復帰するフラグ命令実行手段と、
を具備したことを特徴とする貨幣端末。
【請求項12】
請求項11に記載の貨幣端末に前記残高金額を増額する金額変更情報を入力する金額変更情報入力装置であり、
前記増額金額を取得する増額金額取得手段と、
前記取得した増額金額分の貨幣価値を増額する金額変更情報を生成する金額変更情報生成手段と、
前記貨幣端末から前記端末フラグ記憶手段が記憶している端末フラグを受信する端末フラグ受信手段と、
前記端末フラグが初期状態であった場合は、前記生成した金額変更情報を前記貨幣端末に入力し、前記端末フラグが反転状態であった場合は前記金額変更情報の前記貨幣端末への入力を制限する金額変更情報入力手段と、
を具備したことを特徴とする金額変更情報入力装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【公開番号】特開2011−141902(P2011−141902A)
【公開日】平成23年7月21日(2011.7.21)
【国際特許分類】
【出願番号】特願2011−92484(P2011−92484)
【出願日】平成23年4月18日(2011.4.18)
【分割の表示】特願2006−512630(P2006−512630)の分割
【原出願日】平成17年4月26日(2005.4.26)
【出願人】(501044116)ビットワレット株式会社 (48)
【公開日】平成23年7月21日(2011.7.21)
【国際特許分類】
【出願日】平成23年4月18日(2011.4.18)
【分割の表示】特願2006−512630(P2006−512630)の分割
【原出願日】平成17年4月26日(2005.4.26)
【出願人】(501044116)ビットワレット株式会社 (48)
[ Back to top ]