(57)【要約】【課題】取引拒否に相当する条件がない限り、１回の暗証番号入力操作でオフラインデビットによる決済を完了させることができるオフラインデビット決済方法を提供すること。【解決手段】支払い代価がＩＣカードに格納されている電子通貨の金額を越えているかを判定し、超えていた場合には当該ＩＣカード内に搭載されている電子手形アプリケーションを店舗端末から選択するステップと、選択された電子手形アプリケーションと店舗端末との交信により取引の決済を行うステップとを備える。【選択図】        図１
2004258740.tif 000002
【特許請求の範囲】
【請求項１】
ＩＣカード内に格納した電子通貨を使用して取引の決済を行うオフラインデビット取引における決済方法であって、
支払い代価がＩＣカードに格納されている電子通貨の金額を越えているかを判定し、超えていた場合には当該ＩＣカード内に搭載されている電子手形アプリケーションを店舗端末から選択するステップと、
選択された電子手形アプリケーションと店舗端末との交信により取引の決済を行うステップと
を備えることを特徴とするオフラインデビット取引における電子手形決済処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、オフラインデビット取引における電子手形決済処理方法に関するものである。
【０００２】
【従来の技術】
従来、ＩＣカード内のメモリに電子通貨を格納しておき、加盟店等での商品購入に際してＩＣカード内に格納された電子通貨を使用して決済を行うオフラインデビット取引方法が提案されている。
このようなオフラインデビット取引方法において、商品購入にかかる支払い額がＩＣカードに格納されている電子通貨の金額を越える場合、加盟店端末を自動的にオンラインに切り替え（金融機関ホストにホストコンピュータに接続し）、ＩＣカード所有者の預金口座から購入代金を引き落とす方法（オンラインデビット取引方法）が提案されている（例えば、非特許文献１参照。）
【０００３】
【非特許文献１】
ＥＭＶ２０００［平成１３年２月１日検索］  （ｈｔｔｐ：／／ｗｗｗ．ｅｍｖｃｏ．ｃｏｍ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓ．ｃｆｍ）
【０００４】
図５は、従来のオフラインデビット取引方法におけるＩＣカードと加盟店端末とのやり取りを示す処理フロー図である。
オフラインデビットで商品を購入しようとする際、オフラインデビットアプリケーション及び電子手形アプリケーションを搭載したＩＣカード１をカード保有者が加盟店端末２に挿入する。実際には、カード保有者が直接挿入するのではなく、加盟店店員にＩＣカード１を渡し、加盟店店員がＩＣカード１を加盟店端末２に挿入する。
加盟店店員は、カード保有者から支払いを受けるべき取引金額を加盟店端末２のキーパッドから入力する。
加盟店端末２は、ＩＣカード１に対してオフラインデビットのアプリケーション選択コマンド（ＳＥＬＥＣＴコマンド）を発行し、アプリケーションを選択する。ＩＣカード１は、これを受けて、加盟店端末２に対してオフラインデビットのアプリケーション及びデータ（アプリデータ）を送信する。このデータには、口座番号、ＩＣカード内に格納されたオフラインデビットの残高などの情報が含まれる。
【０００５】
加盟店端末２は、ＩＣカード１に対してデータ認証を行い、ＩＣカード１が偽造カードで無いことをチェックし、これから送信されたデータの正当性を確認する。
データの正当性が確認できたならば、次に、加盟店端末２は、暗証番号（ＰＩＮ＝Ｐｅｒｓｏｎａｌ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｎｕｍｂｅｒ）の入力をカード保有者に要求する。カード保有者は暗証番号を加盟店端末２のキーパッドから入力する。加盟店端末２は、ＶＥＲＩＦＹコマンドにより照合キーをＩＣカード１に送信する。ＩＣカード１は照合キーを比較し、その応答として加盟店端末２にチェックが成功した旨応答する。なお、オフラインデビットの仕様により、取引金額が一定金額以内であれば、暗証番号の入力、及び照合は省略する場合もある。
【０００６】
ＩＣカード１は、加盟店端末２に端末アクション分析を要求する。端末アクション分析とは、格納残高不足、フロア・リミットチェック（オフライン利用限度額を超えているかのチェック）、ランダム・トランザクション・セレクション（利用金額がフロアリミット以下でも、一定の確率でオンラインにする）等を分析する処理である。
この結果、オフラインデビットでの取引が可能と判断した場合は、加盟店端末２はオフライン承認応答をＩＣカード１に送信し、ＩＣカード１に格納されている電子通貨から取引金額相当の電子通貨を引き落とし、決済を完了させる。
【０００７】
図６は、従来のオフラインデビット取引において加盟店端末内で行う端末アクション分析処理を示すフローチャートである。
まず、ＩＣカードのオフラインデビットアプリケーションは、オンライン接続をすることなしに取引拒否とするような条件が無いかチェックを行い（ステップ６０１）、該当する条件がある場合は、ＩＡＣ−Ｄｅｎｉａｌ（Ｉｓｓｕｅｒ  Ａｃｔｉｏｎ  Ｃｏｄｅ：発行者アクションコードの取引拒否を示すビット列）の該当するビットをＯＮ＝“１”にする。ＯＮにする条件としては、例えばＩＣカードがブロックされている（カード自体が使用停止）、オフラインデビットアプリケーションがブロックされているなどの場合がある。オフラインデビットアプリケーションの場合はこれらのビットをＯＮにする条件はカード発行金融機関が設定する。
ＯＮにする条件がない場合は、加盟店端末はＩＡＣ−Ｄｅｎｉａｌのデフォルト値として全ビットを“０”として扱う（ステップ６０２）。
【０００８】
一方、流通系端末（ＣＡＴ／ＣＣＴ、ＰＯＳ等）ではＴＡＣ−Ｄｅｎｉａｌ（Ｔｅｒｍｉｎａｌ  Ａｃｔｉｏｎ  Ｃｏｄｅ：端末アクションコードの取引拒否を示すビット列）を保有しており、取扱金融機関、情報処理センター等でオンライン接続要求をせずに取引拒否にする条件に対応するビットをＯＮに設定している。
ＩＣカードからＩＡＣ−Ｄｅｎｉａｌビット列を受信した後、ＴＡＣ−Ｄｅｎｉａｌで取引拒否にする条件が設定されているかどうかを判定し（ステップ６０３）、設定されていなければＴＡＣ−Ｄｅｎｉａｌデフォルト値として全ビットを“０”として扱う（ステップ６０４）。
しかし、取引拒否にする条件が設定されている場合は、加盟店端末は自分自身で保有しているＴＡＣ−ＤｅｎｉａｌとＩＣカードから受信したＩＡＣ−Ｄｅｎｉａｌとの突き合わせを行い、対応するビットの両方がＯＮになっているような条件が存在するかどうかを判定する（ステップ６０５）。
【０００９】
対応するビットの両方がＯＮになっているような条件が存在した場合は、処理を中断するようにＡＡＣ（取引拒否）をＩＣカードに送信し（ステップ６０６）、ＩＣカード側でも処理を中止し、終了させる。
ＩＡＣ−ＤｅｎｉａｌとＴＡＣ−Ｄｅｎｉａｌとの突き合わせの結果、取引拒否とならない場合は、ＩＣカードのオフラインデビットアプリケーションは、オンライン接続を要求するような条件が無いかチェックを行い（ステップ６０７）、該当する条件がある場合は、ＩＡＣ−Ｏｎｌｉｎｅ（発行者アクションコードの取引がオンライン接続に移行するための条件を示すビット列）の該当するビットをＯＮにする。ＯＮにする条件としては、例えば取引金額がオフライン利用限度額より上回っている（フロア・リミットチェック）、オフラインでの決済が一定回数以上連続している（ベロシティ・チェッキング）、乱数によりある程度の確率で取引がオンラインになる（ランダム・トランザクション・セレクション）などの場合がある。オフラインデビットアプリケーションの場合はこれらのビットをＯＮにする条件はカード発行金融機関が設定する。
【００１０】
ＯＮにする条件がない場合は、加盟店端末はＩＡＣ−Ｄｅｎｉａｌのデフォルト値として全ビットを“０”として扱う（ステップ６０８）。
一方、取引拒否の場合と同様に、加盟店端末ではＴＡＣ−Ｏｎｌｉｎｅ（Ｔｅｒｍｉｎａｌ  Ａｃｔｉｏｎ  Ｃｏｄｅ：端末アクションコードの取引がオンライン接続に移行するための条件を示すビット列）を保有しており、取扱金融機関、情報処理センター等でオンライン接続に要求を切り替える条件に対応するビットをＯＮに設定している。
【００１１】
ＩＣカードからＩＡＣ−Ｏｎｌｉｎｅビット列を受信した後、端末ではＴＡＣ−Ｏｎｌｉｎｅでオンライン接続に移行する条件が設定されているかどうかを判定し（ステップ６０９）、設定されていなければＴＡＣ−Ｏｎｌｉｎｅデフォルト値として全ビットを“０”として扱う（ステップ６１０）。
しかし、オンライン接続に移行する条件が設定されていた場合は、加盟店端末は自分自身で保有しているＴＡＣ−ＯｎｌｉｎｅとＩＣカードから受信したＩＡＣ−Ｏｎｌｉｎｅのビット列の突き合わせを行い、対応するビットの両方がＯＮになっているような条件が存在するかどうかを判定し（ステップ６１１）、存在した場合は、オフラインデビット処理を中断し、オンラインデビット接続に切り替えるようにＡＲＱＣ（オンライン取引）をＩＣカードに要求し、ＩＣカード側でもオフラインデビット処理を中止し、オンラインデビットアプリケーションで処理を継続させる。
【００１２】
ＩＡＣ−ＤｅｎｉａｌとＴＡＣ−Ｄｅｎｉａｌとの突き合わせの結果、ＡＡＣ（取引拒否）とならず、またＩＡＣ−ＯｎｌｉｎｅとＴＡＣ−Ｏｎｌｉｎｅとの突き合わせの結果、ＡＲＱＣ（オンライン取引）ともならない場合は、ＴＣ（Ｔｒａｎｓａｃｔｉｏｎ    Ｃｅｒｔｉｆｉｃａｔｅ：オフライン承認）をＩＣカードに要求し、ＩＣカード側ではオフラインデビットアプリケーション処理を継続させ、決済を完了させる。
【００１３】
【発明が解決しようとする課題】
上記の従来のオフラインデビット取引処理方法において、ＩＣカード内に格納されている電子通貨のチャージ残高が不足している場合や、フロア・リミットチェック、ランダム・トランザクション・セレクションチェック（オフライン利用限度額を超えているかのチェック）などでオンラインデビット取引を要求（ＡＲＱＣ）するように応答された場合、再度はじめからオンラインデビットの処理を加盟店端末に要求する必要がある。
しかしながら、オンラインデビットの処理に切り替えると、オンラインデビット処理にかかる通信時間がかかってしまう上に、ＩＣカードの所有者に暗証番号を再度入力させることになり、ＩＣカード所有者に２重引き落としが行われたかのような誤解を与え、システムの信頼性を損ねてしまうという問題がある。
【００１４】
ここで、金融機関の口座自体にも残高が無いような場合、例えば特開２０００−１１３０８９号公報（第５，７，１０図）で提案されているような電子手形を利用する方法が考えられるが、デビット取引としては一旦取引拒否として、電子手形による決済を最初からやり直す必要があるため、上記の場合と同様に、暗証番号の再入力操作が必要になり、２重引き落としが行われたかのような誤解を与えてしまう。
【００１５】
本発明の目的は、取引拒否に相当する条件がない限り、１回の暗証番号入力操作でオフラインデビットによる決済を完了させることができるオフラインデビット決済方法を提供することにある。
【００１６】
【課題を解決するための手段】
上記目的を達成するために、本発明は、支払い代価がＩＣカードに格納されている電子通貨の金額を越えているかを判定し、超えていた場合には当該ＩＣカード内に搭載されている電子手形アプリケーションを店舗端末から選択するステップと、選択された電子手形アプリケーションと店舗端末との交信により取引の決済を行うステップとを備えることを特徴とする。
【００１７】
【発明の実施の形態】
以下、本発明を実施する場合の一形態を、図面を参照して具体的に説明する。図１は、本発明に係るオフラインデビット決済方法の実施の形態を示す図であり、加盟店（オフラインデビット取引を扱っている加盟店）において、電子手形を利用して取引（商品購入）をした場合の処理の流れを示したものである。
この実施の形態において、カード所有者５はオフラインデビットアプリケーション７及び電子手形アプリケーション９を搭載したＩＣカード１を所有している。
オフラインデビットで商品を購入しようとする際、オフラインデビットアプリケーション７及び電子手形アプリケーション９を搭載したＩＣカード１をカード保有者５が加盟店端末２に挿入する（ステップ１０１）。実際には、カード保有者５が直接挿入するのではなく、加盟店店員６にＩＣカード１を渡し、加盟店店員６がＩＣカード１を加盟店端末２に挿入する。
【００１８】
加盟店店員６は、カード保有者５から支払いを受けるべき取引金額を加盟店端末２のキーパッドから入力する（ステップ１０２）。
加盟店端末２は、ＩＣカード１に対してオフラインデビットのアプリケーション７を選択するＳＥＬＥＣＴコマンドを発行し（ステップ１０３）、ＩＣカード１は、これを受けて、加盟店端末２に対してオフラインデビットのアプリケーション７及びデータ８を送信する（ステップ１０４，１０５）。このデータ８には、口座番号、ＩＣカード内にチャージされたオフラインデビットの残高などの情報が含まれる。
【００１９】
次に、加盟店端末２は、ＩＣカード１に対してデータ認証を行い（ステップ１０６）、ＩＣカード１が偽造カードで無いことをチェックし、これから送信されたデータ８の正当性を確認する。
データの正当性が確認できたならば、次に、加盟店端末２は、暗証番号の入力を要求し、カード保有者５に暗証番号を加盟店端末２のキーパッドから入力させる（ステップ１０７）。加盟店端末２は、ＶＥＲＩＦＹコマンドにより照合キーをＩＣカード１に送信し、ＩＣカード１に暗証番号を照合させる（ステップ１０８）。暗証番号が正しい場合は、ＩＣカード１は、その応答として加盟店端末２にチェックが成功した旨応答する（ステップ１０９）。なお、オフラインデビットの仕様により、取引金額が一定金額以内であれば、暗証番号の入力及び照合を省略する場合がある。
【００２０】
ＩＣカード１は、加盟店端末２に端末アクション分析を要求する（ステップ１１０）。加盟店端末２は、オフラインデビットでの取引が可能と判断した場合はこれ以後のオフラインデビットの取引を継続する。
しかし、オフラインデビットとしての取引が不能であると判断した場合、加盟店端末２は、オフラインデビットアプリケーション７を中断し、電子手形アプリケーション９を選択するＳＥＬＥＣＴコマンドを発行する（ステップ１１１）。
【００２１】
ＩＣカード１は、これを受けて、加盟店端末２に対して電子手形のアプリケーション９及びデータ１０を送信する（ステップ１１４，１１５）。このデータ１０には、口座番号、電子署名などの情報が含まれる。なお、ＩＣカード１内に電子手形のアプリケーション９が存在しても、そのアプリケーション９のオプションとしてカード保有者５の同意が必要となっている場合は、加盟店端末２にその旨を表示させ、加盟店店員６からカード保有者５に同意を入力するように依頼する（ステップ１１２）。同意が必要な場合、カード保有者５は、電子手形で取引することを承認する旨を加盟店端末２のキーパッドから入力する（ステップ１１６）。
電子手形のアプリケーション９及びデータ１０を受信した加盟店端末２は、電子手形での決済情報をチェックの上、電子手形による取引が成立した履歴をＩＣバンクカード１内の電子手形のアプリケーション９に出力し、レシート１１を印字する（ステップ１１６）。
【００２２】
加盟店店員６は、ＩＣカード１と印字されたレシート１１をカード保有者５に返却する（ステップ１１７，１１８）。
この取引情報は、加盟店端末６が取引金額、取引時刻、及び電子手形のデータ１０から取得した口座情報、電子署名などの情報を編集して送信データ３として夜間バッチなどの方法で金融機関のホストにまとめて送信する（ステップ１１９）。
これにより、取引時点ではオンライン通信を行うことなく取引が可能となる。
【００２３】
図２は、電子手形を利用したオフラインデビット取引処理の端末アクション分析処理を示すフローチャートである。
図２において、図６の従来方法と異なる点は、ＩＡＣ−ＯｎｌｉｎｅとＴＡＣ−Ｏｎｌｉｎｅのビット列との突き合わせを行い、対応する両方のビットがＯＮになっているような条件が存在する場合は、オフラインデビット処理を一旦中断し、電子手形アプリケーションを選択し、電子手形アプリケーションに決済を完了させるようにしたことである。この処理は、ステップ２１１から分岐するステップ２１４，２１５、２１７で行う。これらのステップ以外のステップ２０１〜２１３は図６のステップ６０１〜６１３（６１２は除く）と同様である。
【００２４】
図２において、ＩＡＣ−ＤｅｎｉａｌとＴＡＣ−Ｄｅｎｉａｌとの突き合わせの結果、取引拒否とならない場合は、ＩＣカード１のオフラインデビットアプリケーション７は、オンライン接続を要求するような条件が無いかチェックを行い、該当する条件がある場合は、ＩＡＣ−Ｏｎｌｉｎｅの該当するビットをＯＮにする。
加盟店端末２は、ＩＣカードからＩＡＣ−Ｏｎｌｉｎｅビット列を受信した後、自分自身で保有しているＴＡＣ−Ｏｎｌｉｎｅと突き合わせを行い、対応する両方のビットがＯＮになっているような条件が存在する場合は、オフラインデビット処理を一旦中断する。このとき、加盟店端末２は、電子手形アプリケーション９を取得するようにアプリケーション選択コマンド（ＳＥＬＥＣＴ）を発行し（ステップ２１４）、ＩＣカード１に電子手形アプリケーション９が存在するかチェックし、電子アプリケーション９が存在する場合は、電子手形アプリケーション９に処理を切り替え（ステップ２１７）、決済をするようにＩＣカード１に要求する。存在しないか、存在しても電子手形アプリケーション９が使用できない場合には、ＩＣカード１から応答コードが‘９０００または‘６１ｘｘ’以外のコードで返されて来るので、従来通りオンラインデビットアプリケーションに切り替えてオンラインデビットでの即時決済を試みる（ステップ２１５、２１６）。
【００２５】
ところで、加盟店端末２には電子手形アプリケーションを搭載していないＩＣカードが提示されたり、複数の電子手形アプリケーションを搭載したＩＣカードが提示される可能性がある。電子手形アプリケーションを搭載していないＩＣカードに対しては電子手形による決済を拒否する必要がある。また、複数の電子手形アプリケーションを搭載したＩＣカードについては、どの電子手形アプリケーションを使用するかを決定する必要がある。
図３は、加盟店端末２でＩＣカード内の電子手形行アプリケーションを決定する処理を示すフローチャートである。
まず、加盟店端末２は、ＩＣカード１内に搭載されている電子手形アプリケーションの一覧を実行可能のアプリケーションの候補リストとして作成する（ステップ３０１）。
具体的には、電子手形アプリケーションのＡＩＤ（Ａｐｐｌｉｃａｔｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ：アプリケーション識別子）をキーにＳＥＬＥＣＴコマンドを発行する。ＩＣカード１は、ＳＥＬＥＣＴコマンドの応答としてＦＣＩ（ファイル制御情報）と応答コードを返す。加盟店端末２はコマンド応答コードが’９０００’（正常終了）、あるいは’６１ｘｘ’（正常終了、下位バイトｘｘは応答データのバイト数を表す）の場合、ＡＩＤとＩＣカード１から選択されたＡＤＦ（Ａｐｐｌｉｃａｔｉｏｎ  Ｄａｔａ  Ｆｉｌｅ：アプリケーション適用ファイル）のＦＣＩ内のＤＦ（Ｄｅｄｉｃａｔｅｄ  Ｆｉｌｅ：専用ファイル）名称（ＡＤＦ  Ｎａｍｅ）を比較し、端末側ＡＩＤに対応する電子手形アプリケーションが複数あるかチェックする。加盟店端末２のＡＩＤとＡＤＦ  Ｎａｍｅが一致し、長さも同じ場合、ＩＣカード１に他の電子手形アプリケーションは存在しない。しかし、ＡＤＦ  Ｎａｍｅが端末のＡＩＤより長く、ＡＩＤの最後の文字まで一致する場合、ＩＣカード１にＡＩＤが一致する複数の電子手形アプリケーションが存在する可能性があるので、候補になる他の電子手形アプリケーションが無いか再度ＳＥＬＥＣＴコマンドを発行し、ＩＣカード１内にある電子手形アプリケーションの候補をすべて候補リストとして作成し登録する。
【００２６】
次に、作成した候補リスト中の電子手形アプリケーション数を取得し、その数を判定する（ステップ３０２、３０３）。候補リスト中に電子手形アプリケーションが何も登録されていない場合は、ＩＣカード１内に電子手形アプリケーション９が存在せず、電子手形による決済が不可能であるので、電子手形による決済処理を中止し（ステップ３０４）、オンラインデビット決済に移行する。
また、候補リスト中に電子手形アプリケーションの候補が１つしかない場合は、そのＦＣＩテンプレート内にあるＡｐｐｌｉｃａｔｉｏｎ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｏｒのｂｉｔ８を参照し（ステップ３０５）、カード保有者の同意が必要かチェックする。Ｂｉｔ８が“１”でカード保有者の同意が必要なように設定されていた場合は、加盟店端末２からカード保有者５の同意を入力させる（ステップ３０６）。カード保有者５の同意が入力されなかった場合には、処理を中止する。
【００２７】
電子手形アプリケーションの候補が１つであり、Ｂｉｔ８が“０”、またはカード保有者の同意があった場合、ＦＣＩのＡＤＦ  ＮａｍｅとＡＩＤが一致するかを判定し（ステップ３０７）、一致する場合には、その電子手形アプリケーションが要求したアプリケーションと完全一致したと判断し処理を終了する。一致しない（ＡＤＦ  Ｎａｍｅが端末のＡＩＤより長く、ＡＩＤの最後の文字まで一致する）場合は、そのアプリケーションの候補のＡＤＦ  Ｎａｍｅを取得し（ステップ３０８）、データ名（ファイル名）に取得した電子手形アプリケーションのＡＤＦを設定し（ステップ３０９）、  これをＫＥＹとして  再度ＳＥＬＥＣＴコマンドを発行する（ステップ３１０）。
【００２８】
一方、Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｏｒのｂｉｔ８が“０”（カード保有者の同意なしで使用してよい）か、あるいは“１”でカード保有者の同意が入力された場合は、その電子手形アプリケーションを選択する。なお、電子手形アプリケーションであれば、このｂｉｔは“１”（カード保有者の同意が必要）であることが望ましい。
【００２９】
複数の電子手形アプリケーションが候補リスト中に存在する場合、加盟店端末２はカード保有者５に電子手形アプリケーションのリストを表示する。この場合、各電子手形アプリケーションのＡｐｐｌｉｃａｔｉｏｎ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｏｒに優先順位が設定されている場合は、それに従い表示する（ステップ３１２、３１４）。優先順位が設定されていなければ、検索順に表示する（ステップ３１２，３１３）。表示されたリストに対し、今回の決済に使用する電子手形アプリケーションをカード保有者５に選択させる（ステップ３１５）。
なお、加盟店端末２に候補リストを表示する機能が無いなどの理由で候補リストを表示しないこともある。その場合はＡｐｐｌｉｃａｔｉｏｎ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｏｒを参照し、優先度の最も高い電子手形アプリケーションを選択するようにする。但し、選択された電子手形アプリケーションのＡｐｐｌｉｃａｔｉｏｎ  Ｐｒｉｏｒｉｔｙ  Ｉｎｄｉｃａｔｏｒのｂｉｔ８が“１”の場合は、カード保有者の同意が必要である。
【００３０】
対象の電子手形アプリケーションが決定した場合は、その電子手形アプリケーションのＡＩＤをＫＥＹにして再度ＳＥＬＥＣＴコマンドを発行する（ステップ３１０）。なお、加盟店端末のＡＩＤとＡＤＦ  Ｎａｍｅが一致し、候補リスト作成時に取得した内容が保証される場合は、再度ＳＥＬＥＣＴコマンドを発行することは不要である。  ＳＥＬＥＣＴコマンドが失敗（ＩＣカードからの応答コード’９０００’、’６１ｘｘ’以外）した場合（ステップ３１１）は、候補リストから該当のエントリを削除した上で（ステップ３１６）、候補リストから電子手形アプリケーションの決定を再度行う。
【００３１】
図４は、電子手形を利用したオフラインデビット取引における資金移動の例を示す図である。
加盟店端末２は、オフラインデビットアプリケーション及び電子手形アプリケーションを搭載したＩＣカード１により、まずオフラインデビットで決済しようとするが、残高不足などの理由でオフラインデビットによる即時決済が不能の場合、図２に示したような処理で電子手形アプリケーションに切り替えて処理を継続し、商品の売買を成立させる。
加盟店端末２には、電子手形による取引データ３（加入者口座番号、決済金額、決済日、電子手形署名など）を保存する。加盟店端末２に保存された取引データ３は、バッチ処理により金融機関ホスト４に送信し、電子手形で決済をした旨を金融機関に通知する。
【００３２】
金融機関ホスト４では、加盟店端末２から通知された取引データ３を元に、電子手形で予め取り決められている決済日に、次の通りの資金移動を行う。
（１）カード保有者５の金融機関口座４０から、取引金額に、電子手形の利用手数料を上乗せした金額を引き落とす。
（２）加盟店の口座４１には、取引金額から、加盟店手数料を差し引いて入金する。
この資金移動が完了することで、１つの取引に対する決済を完結させる。
【００３３】
【発明の効果】
以上説明したように、本発明によれば、オフラインデビットで決済できない場合であっても、カード保有者にとっては、オンラインデビットによる口座からの即時引落としだけでなく、電子手形による決済を取ることも可能になり、引き落とし手段の選択肢が増え、利便性が向上する。
また、加盟店、決済情報処理センター及び金融機関側としては、オフラインデビットが使用できないような場合であっても、電子手形アプリケーションが利用できるカード保有者であれば、オンラインデビットを利用せずに決済を完了させることができるため、通信時間を削減できる。また、回線障害などでオンラインデビットが使用できない等の状況であっても電子手形による決済が可能となる。特に、ＩＣカード内の残高が不足していた場合でも１回の暗証番号入力操作を行うだけで良いので、決済にかかる時間が短くなったうえ、従来のような２重引き落としが行われたかのような誤解も生じなくなり、システムの信頼性を高めることができる。
【図面の簡単な説明】
【図１】本発明に係る電子手形を利用した決済方法の実施の形態を示す図である。
【図２】加盟店端末における処理を示すフローチャートである。
【図３】加盟店端末内で電子手形アプリケーションを選択する処理を示すフローチャートである。
【図４】電子手形を利用したオフラインデビット取引における資金移動の例を示す図である。
【図５】従来のオフラインデビット取引における処理を示す図である。
【図６】従来のオフラインデビット取引における加盟店端末での処理を示すフローチャートである。
【符号の説明】
１…ＩＣカード、２…加盟店端末、３…取引データ、４…金融機関ホスト、５…カード保有者、７…オフラインデビットアプリケーション、９…電子手形アプリケーション。
【図１】
2004258740.tif 000003
【図２】
2004258740.tif 000004
【図３】
2004258740.tif 000005
【図４】
2004258740.tif 000006
【図５】
2004258740.tif 000007
【図６】
2004258740.tif 000008