JP2004258740A - Electronic bill settlement processing method in offline debit transaction - Google Patents
Electronic bill settlement processing method in offline debit transaction Download PDFInfo
- Publication number
- JP2004258740A JP2004258740A JP2003045850A JP2003045850A JP2004258740A JP 2004258740 A JP2004258740 A JP 2004258740A JP 2003045850 A JP2003045850 A JP 2003045850A JP 2003045850 A JP2003045850 A JP 2003045850A JP 2004258740 A JP2004258740 A JP 2004258740A
- Authority
- JP
- Japan
- Prior art keywords
- card
- electronic bill
- transaction
- application
- member store
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Cash Registers Or Receiving Machines (AREA)
Abstract
Description
【0001】
【発明の属する技術分野】
本発明は、オフラインデビット取引における電子手形決済処理方法に関するものである。
【0002】
【従来の技術】
従来、ICカード内のメモリに電子通貨を格納しておき、加盟店等での商品購入に際してICカード内に格納された電子通貨を使用して決済を行うオフラインデビット取引方法が提案されている。
このようなオフラインデビット取引方法において、商品購入にかかる支払い額がICカードに格納されている電子通貨の金額を越える場合、加盟店端末を自動的にオンラインに切り替え(金融機関ホストにホストコンピュータに接続し)、ICカード所有者の預金口座から購入代金を引き落とす方法(オンラインデビット取引方法)が提案されている(例えば、非特許文献1参照。)
【0003】
【非特許文献1】
EMV2000[平成13年2月1日検索] (http://www.emvco.com/specifications.cfm)
【0004】
図5は、従来のオフラインデビット取引方法におけるICカードと加盟店端末とのやり取りを示す処理フロー図である。
オフラインデビットで商品を購入しようとする際、オフラインデビットアプリケーション及び電子手形アプリケーションを搭載したICカード1をカード保有者が加盟店端末2に挿入する。実際には、カード保有者が直接挿入するのではなく、加盟店店員にICカード1を渡し、加盟店店員がICカード1を加盟店端末2に挿入する。
加盟店店員は、カード保有者から支払いを受けるべき取引金額を加盟店端末2のキーパッドから入力する。
加盟店端末2は、ICカード1に対してオフラインデビットのアプリケーション選択コマンド(SELECTコマンド)を発行し、アプリケーションを選択する。ICカード1は、これを受けて、加盟店端末2に対してオフラインデビットのアプリケーション及びデータ(アプリデータ)を送信する。このデータには、口座番号、ICカード内に格納されたオフラインデビットの残高などの情報が含まれる。
【0005】
加盟店端末2は、ICカード1に対してデータ認証を行い、ICカード1が偽造カードで無いことをチェックし、これから送信されたデータの正当性を確認する。
データの正当性が確認できたならば、次に、加盟店端末2は、暗証番号(PIN=Personal Identification number)の入力をカード保有者に要求する。カード保有者は暗証番号を加盟店端末2のキーパッドから入力する。加盟店端末2は、VERIFYコマンドにより照合キーをICカード1に送信する。ICカード1は照合キーを比較し、その応答として加盟店端末2にチェックが成功した旨応答する。なお、オフラインデビットの仕様により、取引金額が一定金額以内であれば、暗証番号の入力、及び照合は省略する場合もある。
【0006】
ICカード1は、加盟店端末2に端末アクション分析を要求する。端末アクション分析とは、格納残高不足、フロア・リミットチェック(オフライン利用限度額を超えているかのチェック)、ランダム・トランザクション・セレクション(利用金額がフロアリミット以下でも、一定の確率でオンラインにする)等を分析する処理である。
この結果、オフラインデビットでの取引が可能と判断した場合は、加盟店端末2はオフライン承認応答をICカード1に送信し、ICカード1に格納されている電子通貨から取引金額相当の電子通貨を引き落とし、決済を完了させる。
【0007】
図6は、従来のオフラインデビット取引において加盟店端末内で行う端末アクション分析処理を示すフローチャートである。
まず、ICカードのオフラインデビットアプリケーションは、オンライン接続をすることなしに取引拒否とするような条件が無いかチェックを行い(ステップ601)、該当する条件がある場合は、IAC−Denial(Issuer Action Code:発行者アクションコードの取引拒否を示すビット列)の該当するビットをON=“1”にする。ONにする条件としては、例えばICカードがブロックされている(カード自体が使用停止)、オフラインデビットアプリケーションがブロックされているなどの場合がある。オフラインデビットアプリケーションの場合はこれらのビットをONにする条件はカード発行金融機関が設定する。
ONにする条件がない場合は、加盟店端末はIAC−Denialのデフォルト値として全ビットを“0”として扱う(ステップ602)。
【0008】
一方、流通系端末(CAT/CCT、POS等)ではTAC−Denial(Terminal Action Code:端末アクションコードの取引拒否を示すビット列)を保有しており、取扱金融機関、情報処理センター等でオンライン接続要求をせずに取引拒否にする条件に対応するビットをONに設定している。
ICカードからIAC−Denialビット列を受信した後、TAC−Denialで取引拒否にする条件が設定されているかどうかを判定し(ステップ603)、設定されていなければTAC−Denialデフォルト値として全ビットを“0”として扱う(ステップ604)。
しかし、取引拒否にする条件が設定されている場合は、加盟店端末は自分自身で保有しているTAC−DenialとICカードから受信したIAC−Denialとの突き合わせを行い、対応するビットの両方がONになっているような条件が存在するかどうかを判定する(ステップ605)。
【0009】
対応するビットの両方がONになっているような条件が存在した場合は、処理を中断するようにAAC(取引拒否)をICカードに送信し(ステップ606)、ICカード側でも処理を中止し、終了させる。
IAC−DenialとTAC−Denialとの突き合わせの結果、取引拒否とならない場合は、ICカードのオフラインデビットアプリケーションは、オンライン接続を要求するような条件が無いかチェックを行い(ステップ607)、該当する条件がある場合は、IAC−Online(発行者アクションコードの取引がオンライン接続に移行するための条件を示すビット列)の該当するビットをONにする。ONにする条件としては、例えば取引金額がオフライン利用限度額より上回っている(フロア・リミットチェック)、オフラインでの決済が一定回数以上連続している(ベロシティ・チェッキング)、乱数によりある程度の確率で取引がオンラインになる(ランダム・トランザクション・セレクション)などの場合がある。オフラインデビットアプリケーションの場合はこれらのビットをONにする条件はカード発行金融機関が設定する。
【0010】
ONにする条件がない場合は、加盟店端末はIAC−Denialのデフォルト値として全ビットを“0”として扱う(ステップ608)。
一方、取引拒否の場合と同様に、加盟店端末ではTAC−Online(Terminal Action Code:端末アクションコードの取引がオンライン接続に移行するための条件を示すビット列)を保有しており、取扱金融機関、情報処理センター等でオンライン接続に要求を切り替える条件に対応するビットをONに設定している。
【0011】
ICカードからIAC−Onlineビット列を受信した後、端末ではTAC−Onlineでオンライン接続に移行する条件が設定されているかどうかを判定し(ステップ609)、設定されていなければTAC−Onlineデフォルト値として全ビットを“0”として扱う(ステップ610)。
しかし、オンライン接続に移行する条件が設定されていた場合は、加盟店端末は自分自身で保有しているTAC−OnlineとICカードから受信したIAC−Onlineのビット列の突き合わせを行い、対応するビットの両方がONになっているような条件が存在するかどうかを判定し(ステップ611)、存在した場合は、オフラインデビット処理を中断し、オンラインデビット接続に切り替えるようにARQC(オンライン取引)をICカードに要求し、ICカード側でもオフラインデビット処理を中止し、オンラインデビットアプリケーションで処理を継続させる。
【0012】
IAC−DenialとTAC−Denialとの突き合わせの結果、AAC(取引拒否)とならず、またIAC−OnlineとTAC−Onlineとの突き合わせの結果、ARQC(オンライン取引)ともならない場合は、TC(Transaction Certificate:オフライン承認)をICカードに要求し、ICカード側ではオフラインデビットアプリケーション処理を継続させ、決済を完了させる。
【0013】
【発明が解決しようとする課題】
上記の従来のオフラインデビット取引処理方法において、ICカード内に格納されている電子通貨のチャージ残高が不足している場合や、フロア・リミットチェック、ランダム・トランザクション・セレクションチェック(オフライン利用限度額を超えているかのチェック)などでオンラインデビット取引を要求(ARQC)するように応答された場合、再度はじめからオンラインデビットの処理を加盟店端末に要求する必要がある。
しかしながら、オンラインデビットの処理に切り替えると、オンラインデビット処理にかかる通信時間がかかってしまう上に、ICカードの所有者に暗証番号を再度入力させることになり、ICカード所有者に2重引き落としが行われたかのような誤解を与え、システムの信頼性を損ねてしまうという問題がある。
【0014】
ここで、金融機関の口座自体にも残高が無いような場合、例えば特開2000−113089号公報(第5,7,10図)で提案されているような電子手形を利用する方法が考えられるが、デビット取引としては一旦取引拒否として、電子手形による決済を最初からやり直す必要があるため、上記の場合と同様に、暗証番号の再入力操作が必要になり、2重引き落としが行われたかのような誤解を与えてしまう。
【0015】
本発明の目的は、取引拒否に相当する条件がない限り、1回の暗証番号入力操作でオフラインデビットによる決済を完了させることができるオフラインデビット決済方法を提供することにある。
【0016】
【課題を解決するための手段】
上記目的を達成するために、本発明は、支払い代価がICカードに格納されている電子通貨の金額を越えているかを判定し、超えていた場合には当該ICカード内に搭載されている電子手形アプリケーションを店舗端末から選択するステップと、選択された電子手形アプリケーションと店舗端末との交信により取引の決済を行うステップとを備えることを特徴とする。
【0017】
【発明の実施の形態】
以下、本発明を実施する場合の一形態を、図面を参照して具体的に説明する。図1は、本発明に係るオフラインデビット決済方法の実施の形態を示す図であり、加盟店(オフラインデビット取引を扱っている加盟店)において、電子手形を利用して取引(商品購入)をした場合の処理の流れを示したものである。
この実施の形態において、カード所有者5はオフラインデビットアプリケーション7及び電子手形アプリケーション9を搭載したICカード1を所有している。
オフラインデビットで商品を購入しようとする際、オフラインデビットアプリケーション7及び電子手形アプリケーション9を搭載したICカード1をカード保有者5が加盟店端末2に挿入する(ステップ101)。実際には、カード保有者5が直接挿入するのではなく、加盟店店員6にICカード1を渡し、加盟店店員6がICカード1を加盟店端末2に挿入する。
【0018】
加盟店店員6は、カード保有者5から支払いを受けるべき取引金額を加盟店端末2のキーパッドから入力する(ステップ102)。
加盟店端末2は、ICカード1に対してオフラインデビットのアプリケーション7を選択するSELECTコマンドを発行し(ステップ103)、ICカード1は、これを受けて、加盟店端末2に対してオフラインデビットのアプリケーション7及びデータ8を送信する(ステップ104,105)。このデータ8には、口座番号、ICカード内にチャージされたオフラインデビットの残高などの情報が含まれる。
【0019】
次に、加盟店端末2は、ICカード1に対してデータ認証を行い(ステップ106)、ICカード1が偽造カードで無いことをチェックし、これから送信されたデータ8の正当性を確認する。
データの正当性が確認できたならば、次に、加盟店端末2は、暗証番号の入力を要求し、カード保有者5に暗証番号を加盟店端末2のキーパッドから入力させる(ステップ107)。加盟店端末2は、VERIFYコマンドにより照合キーをICカード1に送信し、ICカード1に暗証番号を照合させる(ステップ108)。暗証番号が正しい場合は、ICカード1は、その応答として加盟店端末2にチェックが成功した旨応答する(ステップ109)。なお、オフラインデビットの仕様により、取引金額が一定金額以内であれば、暗証番号の入力及び照合を省略する場合がある。
【0020】
ICカード1は、加盟店端末2に端末アクション分析を要求する(ステップ110)。加盟店端末2は、オフラインデビットでの取引が可能と判断した場合はこれ以後のオフラインデビットの取引を継続する。
しかし、オフラインデビットとしての取引が不能であると判断した場合、加盟店端末2は、オフラインデビットアプリケーション7を中断し、電子手形アプリケーション9を選択するSELECTコマンドを発行する(ステップ111)。
【0021】
ICカード1は、これを受けて、加盟店端末2に対して電子手形のアプリケーション9及びデータ10を送信する(ステップ114,115)。このデータ10には、口座番号、電子署名などの情報が含まれる。なお、ICカード1内に電子手形のアプリケーション9が存在しても、そのアプリケーション9のオプションとしてカード保有者5の同意が必要となっている場合は、加盟店端末2にその旨を表示させ、加盟店店員6からカード保有者5に同意を入力するように依頼する(ステップ112)。同意が必要な場合、カード保有者5は、電子手形で取引することを承認する旨を加盟店端末2のキーパッドから入力する(ステップ116)。
電子手形のアプリケーション9及びデータ10を受信した加盟店端末2は、電子手形での決済情報をチェックの上、電子手形による取引が成立した履歴をICバンクカード1内の電子手形のアプリケーション9に出力し、レシート11を印字する(ステップ116)。
【0022】
加盟店店員6は、ICカード1と印字されたレシート11をカード保有者5に返却する(ステップ117,118)。
この取引情報は、加盟店端末6が取引金額、取引時刻、及び電子手形のデータ10から取得した口座情報、電子署名などの情報を編集して送信データ3として夜間バッチなどの方法で金融機関のホストにまとめて送信する(ステップ119)。
これにより、取引時点ではオンライン通信を行うことなく取引が可能となる。
【0023】
図2は、電子手形を利用したオフラインデビット取引処理の端末アクション分析処理を示すフローチャートである。
図2において、図6の従来方法と異なる点は、IAC−OnlineとTAC−Onlineのビット列との突き合わせを行い、対応する両方のビットがONになっているような条件が存在する場合は、オフラインデビット処理を一旦中断し、電子手形アプリケーションを選択し、電子手形アプリケーションに決済を完了させるようにしたことである。この処理は、ステップ211から分岐するステップ214,215、217で行う。これらのステップ以外のステップ201〜213は図6のステップ601〜613(612は除く)と同様である。
【0024】
図2において、IAC−DenialとTAC−Denialとの突き合わせの結果、取引拒否とならない場合は、ICカード1のオフラインデビットアプリケーション7は、オンライン接続を要求するような条件が無いかチェックを行い、該当する条件がある場合は、IAC−Onlineの該当するビットをONにする。
加盟店端末2は、ICカードからIAC−Onlineビット列を受信した後、自分自身で保有しているTAC−Onlineと突き合わせを行い、対応する両方のビットがONになっているような条件が存在する場合は、オフラインデビット処理を一旦中断する。このとき、加盟店端末2は、電子手形アプリケーション9を取得するようにアプリケーション選択コマンド(SELECT)を発行し(ステップ214)、ICカード1に電子手形アプリケーション9が存在するかチェックし、電子アプリケーション9が存在する場合は、電子手形アプリケーション9に処理を切り替え(ステップ217)、決済をするようにICカード1に要求する。存在しないか、存在しても電子手形アプリケーション9が使用できない場合には、ICカード1から応答コードが‘9000または‘61xx’以外のコードで返されて来るので、従来通りオンラインデビットアプリケーションに切り替えてオンラインデビットでの即時決済を試みる(ステップ215、216)。
【0025】
ところで、加盟店端末2には電子手形アプリケーションを搭載していないICカードが提示されたり、複数の電子手形アプリケーションを搭載したICカードが提示される可能性がある。電子手形アプリケーションを搭載していないICカードに対しては電子手形による決済を拒否する必要がある。また、複数の電子手形アプリケーションを搭載したICカードについては、どの電子手形アプリケーションを使用するかを決定する必要がある。
図3は、加盟店端末2でICカード内の電子手形行アプリケーションを決定する処理を示すフローチャートである。
まず、加盟店端末2は、ICカード1内に搭載されている電子手形アプリケーションの一覧を実行可能のアプリケーションの候補リストとして作成する(ステップ301)。
具体的には、電子手形アプリケーションのAID(Application Identifier:アプリケーション識別子)をキーにSELECTコマンドを発行する。ICカード1は、SELECTコマンドの応答としてFCI(ファイル制御情報)と応答コードを返す。加盟店端末2はコマンド応答コードが’9000’(正常終了)、あるいは’61xx’(正常終了、下位バイトxxは応答データのバイト数を表す)の場合、AIDとICカード1から選択されたADF(Application Data File:アプリケーション適用ファイル)のFCI内のDF(Dedicated File:専用ファイル)名称(ADF Name)を比較し、端末側AIDに対応する電子手形アプリケーションが複数あるかチェックする。加盟店端末2のAIDとADF Nameが一致し、長さも同じ場合、ICカード1に他の電子手形アプリケーションは存在しない。しかし、ADF Nameが端末のAIDより長く、AIDの最後の文字まで一致する場合、ICカード1にAIDが一致する複数の電子手形アプリケーションが存在する可能性があるので、候補になる他の電子手形アプリケーションが無いか再度SELECTコマンドを発行し、ICカード1内にある電子手形アプリケーションの候補をすべて候補リストとして作成し登録する。
【0026】
次に、作成した候補リスト中の電子手形アプリケーション数を取得し、その数を判定する(ステップ302、303)。候補リスト中に電子手形アプリケーションが何も登録されていない場合は、ICカード1内に電子手形アプリケーション9が存在せず、電子手形による決済が不可能であるので、電子手形による決済処理を中止し(ステップ304)、オンラインデビット決済に移行する。
また、候補リスト中に電子手形アプリケーションの候補が1つしかない場合は、そのFCIテンプレート内にあるApplication Priority Indicatorのbit8を参照し(ステップ305)、カード保有者の同意が必要かチェックする。Bit8が“1”でカード保有者の同意が必要なように設定されていた場合は、加盟店端末2からカード保有者5の同意を入力させる(ステップ306)。カード保有者5の同意が入力されなかった場合には、処理を中止する。
【0027】
電子手形アプリケーションの候補が1つであり、Bit8が“0”、またはカード保有者の同意があった場合、FCIのADF NameとAIDが一致するかを判定し(ステップ307)、一致する場合には、その電子手形アプリケーションが要求したアプリケーションと完全一致したと判断し処理を終了する。一致しない(ADF Nameが端末のAIDより長く、AIDの最後の文字まで一致する)場合は、そのアプリケーションの候補のADF Nameを取得し(ステップ308)、データ名(ファイル名)に取得した電子手形アプリケーションのADFを設定し(ステップ309)、 これをKEYとして 再度SELECTコマンドを発行する(ステップ310)。
【0028】
一方、Application Priority Indicatorのbit8が“0”(カード保有者の同意なしで使用してよい)か、あるいは“1”でカード保有者の同意が入力された場合は、その電子手形アプリケーションを選択する。なお、電子手形アプリケーションであれば、このbitは“1”(カード保有者の同意が必要)であることが望ましい。
【0029】
複数の電子手形アプリケーションが候補リスト中に存在する場合、加盟店端末2はカード保有者5に電子手形アプリケーションのリストを表示する。この場合、各電子手形アプリケーションのApplication Priority Indicatorに優先順位が設定されている場合は、それに従い表示する(ステップ312、314)。優先順位が設定されていなければ、検索順に表示する(ステップ312,313)。表示されたリストに対し、今回の決済に使用する電子手形アプリケーションをカード保有者5に選択させる(ステップ315)。
なお、加盟店端末2に候補リストを表示する機能が無いなどの理由で候補リストを表示しないこともある。その場合はApplication Priority Indicatorを参照し、優先度の最も高い電子手形アプリケーションを選択するようにする。但し、選択された電子手形アプリケーションのApplication Priority Indicatorのbit8が“1”の場合は、カード保有者の同意が必要である。
【0030】
対象の電子手形アプリケーションが決定した場合は、その電子手形アプリケーションのAIDをKEYにして再度SELECTコマンドを発行する(ステップ310)。なお、加盟店端末のAIDとADF Nameが一致し、候補リスト作成時に取得した内容が保証される場合は、再度SELECTコマンドを発行することは不要である。 SELECTコマンドが失敗(ICカードからの応答コード’9000’、’61xx’以外)した場合(ステップ311)は、候補リストから該当のエントリを削除した上で(ステップ316)、候補リストから電子手形アプリケーションの決定を再度行う。
【0031】
図4は、電子手形を利用したオフラインデビット取引における資金移動の例を示す図である。
加盟店端末2は、オフラインデビットアプリケーション及び電子手形アプリケーションを搭載したICカード1により、まずオフラインデビットで決済しようとするが、残高不足などの理由でオフラインデビットによる即時決済が不能の場合、図2に示したような処理で電子手形アプリケーションに切り替えて処理を継続し、商品の売買を成立させる。
加盟店端末2には、電子手形による取引データ3(加入者口座番号、決済金額、決済日、電子手形署名など)を保存する。加盟店端末2に保存された取引データ3は、バッチ処理により金融機関ホスト4に送信し、電子手形で決済をした旨を金融機関に通知する。
【0032】
金融機関ホスト4では、加盟店端末2から通知された取引データ3を元に、電子手形で予め取り決められている決済日に、次の通りの資金移動を行う。
(1)カード保有者5の金融機関口座40から、取引金額に、電子手形の利用手数料を上乗せした金額を引き落とす。
(2)加盟店の口座41には、取引金額から、加盟店手数料を差し引いて入金する。
この資金移動が完了することで、1つの取引に対する決済を完結させる。
【0033】
【発明の効果】
以上説明したように、本発明によれば、オフラインデビットで決済できない場合であっても、カード保有者にとっては、オンラインデビットによる口座からの即時引落としだけでなく、電子手形による決済を取ることも可能になり、引き落とし手段の選択肢が増え、利便性が向上する。
また、加盟店、決済情報処理センター及び金融機関側としては、オフラインデビットが使用できないような場合であっても、電子手形アプリケーションが利用できるカード保有者であれば、オンラインデビットを利用せずに決済を完了させることができるため、通信時間を削減できる。また、回線障害などでオンラインデビットが使用できない等の状況であっても電子手形による決済が可能となる。特に、ICカード内の残高が不足していた場合でも1回の暗証番号入力操作を行うだけで良いので、決済にかかる時間が短くなったうえ、従来のような2重引き落としが行われたかのような誤解も生じなくなり、システムの信頼性を高めることができる。
【図面の簡単な説明】
【図1】本発明に係る電子手形を利用した決済方法の実施の形態を示す図である。
【図2】加盟店端末における処理を示すフローチャートである。
【図3】加盟店端末内で電子手形アプリケーションを選択する処理を示すフローチャートである。
【図4】電子手形を利用したオフラインデビット取引における資金移動の例を示す図である。
【図5】従来のオフラインデビット取引における処理を示す図である。
【図6】従来のオフラインデビット取引における加盟店端末での処理を示すフローチャートである。
【符号の説明】
1…ICカード、2…加盟店端末、3…取引データ、4…金融機関ホスト、5…カード保有者、7…オフラインデビットアプリケーション、9…電子手形アプリケーション。[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an electronic bill settlement processing method in offline debit transactions.
[0002]
[Prior art]
Conventionally, there has been proposed an off-line debit transaction method in which electronic currency is stored in a memory in an IC card and settlement is performed using the electronic currency stored in the IC card when purchasing goods at a member store or the like.
In such an off-line debit transaction method, if the payment amount for purchasing the product exceeds the amount of the electronic currency stored in the IC card, the member store terminal is automatically switched online (connected to the host computer of the financial institution and connected to the host computer). And a method of withdrawing the purchase price from the IC card owner's deposit account (online debit transaction method) has been proposed (for example, see Non-Patent Document 1).
[0003]
[Non-patent document 1]
EMV2000 [Searched February 1, 2001] (http://www.emvco.com/specifications.cfm)
[0004]
FIG. 5 is a processing flowchart showing the exchange between the IC card and the member store terminal in the conventional offline debit transaction method.
When attempting to purchase a product by offline debit, the card holder inserts the IC card 1 equipped with the offline debit application and the electronic bill application into the
The member store clerk inputs the transaction amount to be paid by the cardholder from the keypad of the
The
[0005]
The
If the validity of the data can be confirmed, the
[0006]
The IC card 1 requests the
As a result, if it is determined that the transaction with offline debit is possible, the
[0007]
FIG. 6 is a flowchart showing a terminal action analysis process performed in a member store terminal in a conventional offline debit transaction.
First, the off-line debit application of the IC card checks whether there is a condition for rejecting the transaction without connecting online (step 601), and if there is such a condition, the IAC-Denial (Issuer Action Code). : The corresponding bit of the issuer action code (bit string indicating transaction refusal) is set to ON = "1". The conditions for turning ON include, for example, a case where the IC card is blocked (the card itself stops being used) and a case where the offline debit application is blocked. In the case of an off-line debit application, the conditions for turning on these bits are set by the card issuing financial institution.
If there is no condition for turning ON, the member store terminal treats all bits as "0" as a default value of IAC-Denial (step 602).
[0008]
On the other hand, distribution terminals (CAT / CCT, POS, etc.) have TAC-Denial (Terminal Action Code: a bit string indicating refusal of transaction of terminal action code), and online financial institutions, information processing centers, etc. request online connection. The bit corresponding to the condition for rejecting the transaction without performing is set to ON.
After receiving the IAC-Denial bit string from the IC card, it is determined whether or not a condition for rejecting the transaction is set in the TAC-Denial (step 603). If not set, all bits are set to "TAC-Denial default value". Treated as "0" (step 604).
However, if the conditions for rejecting the transaction are set, the member store terminal compares its own TAC-Denial with the IAC-Denial received from the IC card, and both corresponding bits are set. It is determined whether there is a condition that is ON (step 605).
[0009]
If there is such a condition that both of the corresponding bits are ON, AAC (transaction refusal) is transmitted to the IC card so as to interrupt the processing (step 606), and the processing is also stopped on the IC card side. , To end.
If the transaction is not rejected as a result of the matching between the IAC-Denial and the TAC-Denial, the offline debit application of the IC card checks whether there is any condition that requires an online connection (step 607). If there is, the corresponding bit of IAC-Online (a bit string indicating a condition for the transaction of the issuer action code to shift to online connection) is turned ON. The conditions for turning ON include, for example, that the transaction amount exceeds the offline usage limit (floor limit check), that offline settlement is continued for a certain number of times or more (velocity checking), and that a certain probability is set by random numbers. And the transaction goes online (random transaction selection). In the case of an off-line debit application, the conditions for turning on these bits are set by the card issuing financial institution.
[0010]
If there is no condition to turn ON, the member store terminal treats all bits as "0" as a default value of IAC-Denial (step 608).
On the other hand, as in the case of the transaction refusal, the member store terminal has TAC-Online (Terminal Action Code: a bit string indicating a condition for transition of terminal action code transaction to online connection), A bit corresponding to a condition for switching a request to online connection is set to ON at an information processing center or the like.
[0011]
After receiving the IAC-Online bit string from the IC card, the terminal determines whether or not the condition for shifting to the online connection is set in the TAC-Online (step 609). If not, the terminal sets the TAC-Online default value as the TAC-Online default value. The bit is treated as "0" (step 610).
However, when the condition for shifting to the online connection is set, the member store terminal compares the bit string of the TAC-Online held by itself with the bit string of the IAC-Online received from the IC card, and determines the corresponding bit. It is determined whether or not there is a condition that both of them are ON (step 611). If there is, the ARQC (online transaction) is interrupted by interrupting the offline debit processing and switching to the online debit connection. , The offline debit processing is also stopped on the IC card side, and the processing is continued by the online debit application.
[0012]
If the result of the match between the IAC-Denial and the TAC-Denial does not result in AAC (transaction refusal), and the result of the match between the IAC-Online and the TAC-Online does not result in an ARQC (online transaction), the TC (Transaction Certificate) : Offline approval) to the IC card, and the IC card side continues the offline debit application processing to complete the settlement.
[0013]
[Problems to be solved by the invention]
In the conventional offline debit transaction processing method described above, when the charge balance of the electronic currency stored in the IC card is insufficient, floor limit check, random transaction selection check (exceeding the offline use limit amount) In such a case, it is necessary to request the online merchant terminal to perform online debit processing again from the beginning.
However, when switching to online debit processing, the communication time required for online debit processing is increased, and the owner of the IC card is required to re-enter the password, and the IC card owner is debited twice. There is a problem that a misunderstanding as if we were given is given and the reliability of the system is impaired.
[0014]
Here, when there is no balance in the account of the financial institution itself, for example, a method using an electronic bill as proposed in Japanese Patent Application Laid-Open No. 2000-113089 (FIGS. 5, 7, and 10) can be considered. However, as a debit transaction, it is necessary to redo the settlement with the electronic bill from the beginning as a transaction refusal, so it is necessary to re-enter the password as in the above case, as if double deduction was performed Misunderstanding.
[0015]
An object of the present invention is to provide an off-line debit payment method capable of completing an off-line debit payment by one password input operation unless there is a condition corresponding to transaction refusal.
[0016]
[Means for Solving the Problems]
In order to achieve the above object, the present invention determines whether the payment price exceeds the amount of the electronic currency stored in the IC card, and if the payment price exceeds the electronic currency, the electronic money installed in the IC card is determined. The method includes a step of selecting a bill application from a store terminal and a step of performing transaction settlement by communication between the selected electronic bill application and the store terminal.
[0017]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, an embodiment of the present invention will be specifically described with reference to the drawings. FIG. 1 is a diagram showing an embodiment of an offline debit settlement method according to the present invention. In a member store (a member store that handles offline debit transactions), a transaction (purchase of goods) is performed using an electronic bill. It shows the flow of processing in the case.
In this embodiment, a card holder 5 owns an IC card 1 on which an
When purchasing a product by offline debit, the card holder 5 inserts the IC card 1 equipped with the
[0018]
The
The
[0019]
Next, the
If the validity of the data is confirmed, the
[0020]
The IC card 1 requests the
However, if it is determined that the transaction as offline debit is impossible, the
[0021]
In response, the IC card 1 transmits the electronic bill application 9 and the data 10 to the member store terminal 2 (
Upon receipt of the electronic bill application 9 and the data 10, the
[0022]
The
The transaction information is obtained by editing the information such as the transaction amount, the transaction time, the account information and the electronic signature acquired from the electronic bill data 10 by the
Thereby, at the time of the transaction, the transaction can be performed without performing the online communication.
[0023]
FIG. 2 is a flowchart showing a terminal action analysis process in an offline debit transaction process using an electronic bill.
2 differs from the conventional method of FIG. 6 in that the bit strings of the IAC-Online and the TAC-Online are compared, and if there is a condition that both corresponding bits are ON, the offline method is performed. The debit processing is temporarily interrupted, an electronic bill application is selected, and the electronic bill application completes the settlement. This processing is performed in
[0024]
In FIG. 2, if the transaction is not rejected as a result of matching between the IAC-Denial and the TAC-Denial, the
After receiving the IAC-Online bit string from the IC card, the
[0025]
By the way, there is a possibility that an IC card without an electronic bill application is presented to the
FIG. 3 is a flowchart showing a process of determining the electronic bill line application in the IC card at the
First, the
Specifically, a SELECT command is issued using an AID (Application Identifier: application identifier) of the electronic bill application as a key. The IC card 1 returns FCI (file control information) and a response code as a response to the SELECT command. If the command response code is “9000” (normal end) or “61xx” (normal end, lower byte xx indicates the number of bytes of response data), the
[0026]
Next, the number of electronic bill applications in the created candidate list is obtained, and the number is determined (
If there is only one candidate for the electronic bill application in the candidate list, reference is made to bit 8 of the Application Priority Indicator in the FCI template (step 305), and it is checked whether or not the consent of the card holder is necessary. If
[0027]
If there is only one candidate for the electronic bill application and
[0028]
On the other hand, if
[0029]
If a plurality of electronic bill applications are present in the candidate list, the
The candidate list may not be displayed because the
[0030]
When the target electronic bill application is determined, the AID of the electronic bill application is set to KEY and a SELECT command is issued again (step 310). If the AID of the member store terminal and the ADF Name match and the contents acquired at the time of creating the candidate list are guaranteed, it is not necessary to issue the SELECT command again. If the SELECT command has failed (response code other than '9000' and '61xx' from the IC card) (step 311), the corresponding entry is deleted from the candidate list (step 316), and the electronic bill application is deleted from the candidate list. Decision is made again.
[0031]
FIG. 4 is a diagram showing an example of the transfer of funds in an offline debit transaction using an electronic bill.
The
The
[0032]
The financial institution host 4 performs the following fund transfer on a settlement date predetermined by an electronic bill based on the
(1) Withdraw the amount obtained by adding the usage fee of the electronic bill to the transaction amount from the
(2) Deposit into the account 41 of the member store by subtracting the member store fee from the transaction amount.
Completion of this fund transfer completes settlement for one transaction.
[0033]
【The invention's effect】
As described above, according to the present invention, even if the payment cannot be made by offline debit, for the cardholder, not only immediate debit from the account by online debit, but also payment by electronic bill can be performed. It becomes possible, the options of debit means increase, and convenience improves.
In addition, even if offline debit cannot be used, cardholders who can use the electronic bill application can make payments without using online debit, even if offline debit cannot be used. Can be completed, so that the communication time can be reduced. Further, even in a situation where online debit cannot be used due to a line failure or the like, settlement by electronic bill is possible. In particular, even if the balance in the IC card is insufficient, only one password input operation is required, so that the time required for settlement is reduced, and it is as if a double debit as in the past was performed. Misunderstanding does not occur, and the reliability of the system can be improved.
[Brief description of the drawings]
FIG. 1 is a diagram showing an embodiment of a settlement method using an electronic bill according to the present invention.
FIG. 2 is a flowchart showing processing in a member store terminal.
FIG. 3 is a flowchart showing a process of selecting an electronic bill application in a member store terminal.
FIG. 4 is a diagram illustrating an example of fund transfer in an off-line debit transaction using an electronic bill.
FIG. 5 is a diagram showing processing in a conventional offline debit transaction.
FIG. 6 is a flowchart showing a process at a member store terminal in a conventional offline debit transaction.
[Explanation of symbols]
1 ... IC card, 2 ... Merchant terminal, 3 ... Transaction data, 4 ... Financial institution host, 5 ... Card holder, 7 ... Offline debit application, 9 ... Electronic bill application.
Claims (1)
支払い代価がICカードに格納されている電子通貨の金額を越えているかを判定し、超えていた場合には当該ICカード内に搭載されている電子手形アプリケーションを店舗端末から選択するステップと、
選択された電子手形アプリケーションと店舗端末との交信により取引の決済を行うステップと
を備えることを特徴とするオフラインデビット取引における電子手形決済処理方法。A settlement method in an off-line debit transaction for performing transaction settlement using an electronic currency stored in an IC card,
Determining whether the payment price exceeds the amount of the electronic currency stored in the IC card, and if so, selecting an electronic bill application installed in the IC card from the store terminal;
An electronic bill settlement processing method in an offline debit transaction, comprising: performing a transaction settlement by communication between a selected electronic bill application and a store terminal.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003045850A JP2004258740A (en) | 2003-02-24 | 2003-02-24 | Electronic bill settlement processing method in offline debit transaction |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003045850A JP2004258740A (en) | 2003-02-24 | 2003-02-24 | Electronic bill settlement processing method in offline debit transaction |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004258740A true JP2004258740A (en) | 2004-09-16 |
Family
ID=33112559
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003045850A Pending JP2004258740A (en) | 2003-02-24 | 2003-02-24 | Electronic bill settlement processing method in offline debit transaction |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004258740A (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007034637A (en) * | 2005-07-26 | 2007-02-08 | Ntt Docomo Inc | Mobile terminal device and electronic payment system |
JP2012194905A (en) * | 2011-03-17 | 2012-10-11 | Toshiba Corp | Communication medium, ic card, and communication method |
JP2015531093A (en) * | 2012-05-24 | 2015-10-29 | ジェーヴィーエル ベンチャ−ズ, エルエルシーJVL Ventures, LLC. | Systems, methods, and computer program products for providing contactless protocols |
CN111868771A (en) * | 2018-02-08 | 2020-10-30 | 索尼公司 | Information processing apparatus and information processing system |
JP7493402B2 (en) | 2020-07-16 | 2024-05-31 | ニデックインスツルメンツ株式会社 | Payment system and payment method |
JP7599538B1 (en) | 2023-11-22 | 2024-12-13 | 株式会社りそなホールディングス | Delayed debit payment system, delayed debit payment method, and delayed debit payment program |
-
2003
- 2003-02-24 JP JP2003045850A patent/JP2004258740A/en active Pending
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007034637A (en) * | 2005-07-26 | 2007-02-08 | Ntt Docomo Inc | Mobile terminal device and electronic payment system |
JP4663441B2 (en) * | 2005-07-26 | 2011-04-06 | 株式会社エヌ・ティ・ティ・ドコモ | Mobile terminal device and electronic payment system |
JP2012194905A (en) * | 2011-03-17 | 2012-10-11 | Toshiba Corp | Communication medium, ic card, and communication method |
US9092713B2 (en) | 2011-03-17 | 2015-07-28 | Kabushiki Kaisha Toshiba | IC card controlling access to files according to conditions, and manufacturing method, issuing method, and communication method of the same |
US11526870B2 (en) | 2012-05-24 | 2022-12-13 | Google Llc | Systems, methods, and computer program products for providing a contactless protocol |
US10311428B2 (en) | 2012-05-24 | 2019-06-04 | Google Llc | Systems, methods, and computer program products for providing a contactless protocol |
US10949832B2 (en) | 2012-05-24 | 2021-03-16 | Google Llc | Systems, methods, and computer program products for providing a contactless protocol |
JP2015531093A (en) * | 2012-05-24 | 2015-10-29 | ジェーヴィーエル ベンチャ−ズ, エルエルシーJVL Ventures, LLC. | Systems, methods, and computer program products for providing contactless protocols |
US11972411B2 (en) | 2012-05-24 | 2024-04-30 | Google Llc | Systems, methods, and computer program products for providing a contactless protocol |
CN111868771A (en) * | 2018-02-08 | 2020-10-30 | 索尼公司 | Information processing apparatus and information processing system |
JPWO2019155793A1 (en) * | 2018-02-08 | 2021-02-04 | ソニー株式会社 | Information processing equipment and information processing system |
US11748742B2 (en) | 2018-02-08 | 2023-09-05 | Sony Corporation | Information processing device and information processing system |
JP7367531B2 (en) | 2018-02-08 | 2023-10-24 | ソニーグループ株式会社 | Information processing equipment and information processing system |
JP7493402B2 (en) | 2020-07-16 | 2024-05-31 | ニデックインスツルメンツ株式会社 | Payment system and payment method |
JP7599538B1 (en) | 2023-11-22 | 2024-12-13 | 株式会社りそなホールディングス | Delayed debit payment system, delayed debit payment method, and delayed debit payment program |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11880827B1 (en) | Payment vehicle with on and off function | |
CN109214792B (en) | Method and system for electronic vouchers via a blockchain | |
US6786400B1 (en) | Multiple account banking system and method | |
US8515871B2 (en) | Authorizing use of a financial instrument | |
JP5518740B2 (en) | System and method for data completion including a push identifier | |
US7891561B2 (en) | Cash redemption of gift cards systems and methods | |
US7599888B2 (en) | Electronic confirmation to debit or credit an account | |
US20100036741A1 (en) | Application currency code for dynamic currency conversion transactions with contactless consumer transaction payment device | |
US20090063339A1 (en) | System and method for loading prepaid debit card at an atm | |
US20240242190A1 (en) | Financial terminal that automatically reconfigures into different financial processing terminal types | |
AU2024204771A1 (en) | Payment terminal device and method | |
JP2018530049A (en) | Card continuation system and method | |
US20240119480A1 (en) | Systems and methods for electronic loyalty-based transactions over electronic monetary exchange networks | |
EP2613287B1 (en) | Computer system and method for initiating payments based on cheques | |
JPH11259585A (en) | Electronic wallet system, electronic wallet device, and computer-readable recording medium recording money information transfer program | |
JPH11259586A (en) | Electronic check system, financial information management system, electronic check management device, and medium recording electronic check management program | |
JP2008158638A (en) | Payment processing support system, payment processing support method, payment processing support apparatus and credit card back end system | |
JP2004258740A (en) | Electronic bill settlement processing method in offline debit transaction | |
US20090144198A1 (en) | Money transfer using an automated banking machine | |
JP7222453B2 (en) | System, apparatus, server and method for transaction security | |
KR20180068838A (en) | Card settlement system | |
US20060036540A1 (en) | Method and system for merchant indemnification for online financial transactions | |
US20200234282A1 (en) | Method and system for loading reloadable cards | |
KR101887458B1 (en) | Method for providing information of cash settlement | |
JP7395880B2 (en) | Management server and programs |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050614 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080418 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080502 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080903 |