JP2004199534A - Ｉｃカードを利用した決済システム - Google Patents
Ｉｃカードを利用した決済システム Download PDFInfo
- Publication number
- JP2004199534A JP2004199534A JP2002369174A JP2002369174A JP2004199534A JP 2004199534 A JP2004199534 A JP 2004199534A JP 2002369174 A JP2002369174 A JP 2002369174A JP 2002369174 A JP2002369174 A JP 2002369174A JP 2004199534 A JP2004199534 A JP 2004199534A
- Authority
- JP
- Japan
- Prior art keywords
- credit
- card
- management system
- provision management
- bank
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3825—Use of electronic signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Computer Security & Cryptography (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
【課題】ICカードを用いたクレジット決済処理において、利用代金入金後のクレジットサービス利用時にその代金をクレジット利用可能額へ反映する。
【解決手段】銀行サービス提供管理システム１０１とクレジットサービス提供管理システム１２１は公開鍵を予め交換する。銀行サービス提供管理システム１０１は利用者からのクレジット利用代金入金要求を受け、前記公開鍵で暗号化、自身の秘密鍵で署名付与し入金データをICカード１１０に格納する。クレジットサービス提供管理システム１２１は、利用者からのクレジット利用要求を受け、入金データをICカードから抽出し、前記の公開鍵により署名を検証、自身の秘密鍵でデータを復号化し与信情報データベース１２４に仮反映する。またクレジットサービス提供管理システム１２１は、期日に銀行サービス提供管理システム１０１から振り込まれたクレジット利用代金を与信情報データベース１２４に反映する。
【選択図】 図２
【解決手段】銀行サービス提供管理システム１０１とクレジットサービス提供管理システム１２１は公開鍵を予め交換する。銀行サービス提供管理システム１０１は利用者からのクレジット利用代金入金要求を受け、前記公開鍵で暗号化、自身の秘密鍵で署名付与し入金データをICカード１１０に格納する。クレジットサービス提供管理システム１２１は、利用者からのクレジット利用要求を受け、入金データをICカードから抽出し、前記の公開鍵により署名を検証、自身の秘密鍵でデータを復号化し与信情報データベース１２４に仮反映する。またクレジットサービス提供管理システム１２１は、期日に銀行サービス提供管理システム１０１から振り込まれたクレジット利用代金を与信情報データベース１２４に反映する。
【選択図】 図２
Description
【０００１】
【発明の属する技術分野】
本発明は、ICカードを利用し、クレジットサービスシステムと銀行サービスシステムを連携した決済システムに関する。
【０００２】
【従来の技術】
従来、クレジットカードを利用した決済処理を行った場合、その支払いは銀行口座からの期日引落し、もしくは小切手や現金による振込みであった。利用者はクレジットカード会社から送付される請求書に従い、期日までに代金を支払う。クレジットカード会社は、銀行や利用者からの振込みを確認した上で、支払われた金額分だけ利用可能額を引き上げるという方式を取っている。
近年、磁気カードに代わり、1枚のカードに複数のサービスが搭載可能な多機能ICカードが普及しつつあるが、これを用いた場合も上記方式と同様である。多機能ICカードでは、クレジットサービスを行うICカードアプリケーション（以下AP）と、銀行口座の預貯金などを行うAPが1枚のICカード上に存在可能である。
【０００３】
【発明が解決しようとする課題】
上記従来技術において、クレジット決済の支払を銀行口座からの自動引落しにしている場合、利用者が銀行にクレジット利用額を入金し引落されてから、クレジットカード会社の利用可能額に反映されるまで数日かかるという問題点があった。また、通常は銀行口座からの自動引落しを支払い方式として選択する利用者が多いが、該方式だと「手元にある今、クレジット利用額を払っておきたい」「今、払った金額分をリアルタイムにクレジット利用可能額に反映させたい」という要求に対応できないという課題がある。以下では、この課題について詳細に説明する。
図1は従来のクレジットサービス決済システムの構成を表している。まず、システムの構成要素について概要を説明する。
符号１０１は銀行サービス提供管理システム（以下銀行システム）であり、銀行は該システムを用いて顧客情報や口座情報の管理、預貯金や引き落し・振込みなどの銀行業務を行う。該システムには、銀行サービス提供管理サーバ（１０２）と銀行サービス提供管理端末（１０５）が存在する。銀行サービス提供管理サーバは、利用者個人口座（１０３）と銀行業務を行う銀行サービス提供管理処理部（１０４）を有する。銀行サービス提供管理端末は、銀行の各支店などに設置され、利用者が直接アクセスする、いわゆるATM端末である。
符号１２１はクレジットサービス提供管理システム（以下クレジットシステム）であり、クレジットカード会社は該システムを用いて顧客情報やクレジットカード情報の管理、クレジット利用時の与信チェック、決済処理などのクレジットサービス業務を行う。該システムには、クレジットサービス提供管理システム（１２２）とクレジットサービス加盟店端末（１２５）が存在する。クレジットサービス提供管理サーバは、クレジットサービス業務を行うクレジットサービス提供管理処理部（１２３）と、顧客情報やカード情報、顧客の与信情報などを持つデータベース（１２４）を有する。クレジットサービス加盟店端末は、クレジットカード会社と契約をした加盟店に設置され、ショッピングやキャッシングなどのクレジットサービスを利用可能な端末を有する。
銀行システムとクレジットシステム間は公衆網などのネットワークあるいは専用線によるネットワークあるいは、書面や情報記録媒体の郵送・手渡しにより情報のやり取りを実現する。また、各システムの端末／サーバ間は、公衆網もしくは専用線のネットワークにより情報のやり取りを実現する。
また、上述の銀行システム（１０１）とクレジットシステム（１２１）は、各々の処理部（１０４、１２３）に、口座管理や預貯金などの銀行業務処理機能や、クレジット決済、与信情報チェックなどのクレジットサービス処理機能を有している。これらの各処理機能は、コンピュータ・プログラムとして実現され、動作する。
次に、上記システムにおけるクレジット決済と代金支払業務の動作手順を例にとり、従来システムの課題を説明する。
クレジット決済を行った利用者（１１１）は、口座引落し期日までに銀行サービス提供管理端末（１０５）にアクセスし（１３１）、支払金額を本人の引落し指定口座（１０３）に入金する（１３２）。引落し期日になると銀行サービス提供管理処理部（１０４）はクレジットカード会社からの指定された金額を利用者口座（１０３）から引き出しクレジットサービス提供管理処理部（１２３）に振り込む（１３８）。クレジットサービス提供管理処理部（１２３）は振り込まれた金額を確認し、利用者の与信情報データベース（１２４）を更新する。与信情報データベースには、利用者の利用可能額と未支払金額などの情報が格納されている。利用者がクレジット加盟端末に移動し（１３３）、クレジット決済を要求した際は（１３４）、加盟店端末はこの与信情報を確認し（１３５）、結果を受信し（１３６）、利用者に対して利用可否を提示する（１３７）。
ここで従来のシステムにおける第1の課題は、銀行システムからクレジットシステムへ代金が支払われてから、与信情報データベースへ反映されるまでがリアルタイムでない場合があることである。これは、振り込まれてからデータ解析処理とデータベース更新処理に時間がかかることや、銀行システムによる振込み処理がバッチ処理であることなどに起因する。
第2の課題は、利用者が銀行システムに対して行うクレジット決済代金の入金は、通常の預金と処理手順が変わらないため、利用者が余裕のある時に「ある時払い」を行いたい場合に、口座入金を行ってもクレジットサービスに振り込まれるのは決まった期日となるため、与信情報への反映が遅れる点である。また「口座に残っていれば使ってしまう」といった利用者の気持ちにも対応していない。利用者が「ある時払い」をしたい場合は、クレジットシステムへ振り込み処理を行う、あるいはクレジットシステムの窓口に行って直接支払うなどの通常と違った支払方法を行わなければならない。また、最近では「ある時払い」専用のカードも利用可能となっているが、これはクレジット支払方式のデフォルトが「ある時払い」であり、デフォルトの支払方式を銀行口座からの自動引落しとし、時々「ある時払い」を行いたいなどの利用者の多様な要求に柔軟に対応するのは難しい。
また「ある時払い」したい状況としては、上記のように余裕のある時に払ってしまいたいという利用者の希望だけでなく、ボーナス払いにしてある金額の引き落とし日とボーナス支給日の間にかなり開きがあるのでボーナス支給と同時に支払いたいという場合や、手元に現金があるが海外渡航するためクレジット利用可能額を引き上げておきたいといった場合がある。
以上で、従来システムにおける２つの課題についての説明を終える。
【０００４】
【課題を解決するための手段】
上記課題を解決するために、本発明は利用者の入金情報を示したデータをICカード上に格納することで銀行システムとクレジットシステム間の連携可能とし、利用者が好きな時にクレジット決済の代金を銀行に入金し、その直後でも入金情報を反映したクレジット利用が可能なクレジット決済システムを提供する。
以下、詳細に説明する。
まず第1の課題である、利用者の銀行口座からの代金引落しとクレジットの与信情報への反映の間がリアルタイムでないという問題に対して本発明の実施例では、ICカード上に入金情報を示したデータを格納し、クレジット決済時はこのデータを確認し、与信情報の仮反映させることで解決する。本発明ではこの入金情報を示したデータをトークン（TOKEN）と呼ぶ。利用者が銀行サービスに対してクレジット決済の代金を入金した際、銀行システムはその金額、日付、有効期限などを示したトークンに自身の暗号鍵で署名し、ICカード上に格納する。ICカードには銀行サービスを行うAPが搭載されているため、ICカードとシステム間で相互認証することで該口座以外のICカードへの搭載を防ぐことが可能である。そして、利用者が直後にクレジット決済を利用する際は、直前の入金は銀行サービスからクレジットサービスへまだ振り込まれておらず与信情報データベースに反映されていないため、従来は利用可能額に直前の入金額は反映されないが、クレジットシステムにトークン検証手段を持たせることで解決する。クレジットシステムがトークンを検証し正当性を確認できた場合はトークンを信用し、記載の入金額を与信情報に仮反映させる。通常でもクレジット決済利用の際は、サーバに与信情報をオンラインで確認しているため、同時にトークンもサーバに渡すことで署名検証と与信情報への仮反映を行えばよい。また、期日には銀行システムからの振込み処理が行われているため、トークンによる仮反映の正当性を実際に確認することが可能でなる。
また、第2の課題である、利用者がクレジット決済の代金を払いたい時に「ある時払い」し、なおかつクレジット利用可能額へのリアルタイムな反映を行いたいという課題に対して、本発明での実施例では、銀行システム内にクレジットシステムへ振り込むべき金額を入金しておく共通の口座を設置することで解決する。本発明ではこの口座をプール口座と呼ぶ。利用者は通常は銀行の本人口座に入金し期日になると引落されるという支払方式だが、「ある時払い」をしたい場合はこのプール口座に入金する。もしくは本人口座から振替を行う。この場合も同様に銀行システムは、入金額、日付、有効期限などを示したトークンをICカード上に格納する。プール口座は利用者の本人口座ではないため、クレジット利用代金の引落し期日に関係なく入金すれば、それ以降の出金は不可能である。
利用者はこのトークンをクレジット決済の際に使用することで、リアルタイムな利用可能額への反映が可能となる。銀行システムは期日になったら、通常は利用者口座からの引落しするところを、プール口座からの引き落としを行いクレジットシステムに振込みを行う。振り込み処理はバッチ処理であることが多いが、本発明の実施例では引落し先が利用者口座かプール口座かの違いだけであって、これまでのバッチ処理に対する修正点は少ない。
具体的に、上記２つの解決手段を用いて銀行システムとクレジットシステムが連携して行う、クレジット決済処理について説明する。まず前処理として銀行システムとクレジットシステム間でトークン用の暗号鍵を交換する。銀行システムの暗号鍵はトークンに対して署名処理を行い、銀行が生成した正当なトークンであることを示すために使用される。クレジットサービスのシステムの暗号鍵はトークンに対して暗号化処理を行い、クレジットシステム以外が復号化不可能なためトークンの秘匿性を保持するために使用される。これらの暗号鍵はオープン情報である公開鍵証明書の場合もあるし、銀行とクレジットカード会社間の契約時に専用に生成した暗号鍵である場合もあるだろう。また、暗号鍵の種類は公開鍵系暗号だけはなく、共通鍵系暗号でも可能である。以下、本特許の実施例では公開鍵系暗号鍵により説明するが、共通鍵をシステム間で交換し派生データにより派生鍵を生成させることで同様の処理が可能である。ただし、この場合は両システム間以外に対してはクローズなデータであることと、後に説明するトークンの受け渡し処理の際に派生データを付加することに注意する必要がある。
次に銀行システムによる利用者の入金処理に移る。利用者はクレジット決済の代金の入金を銀行システムに要求する。要求されたクレジットシステムが契約をしており上記処理による暗号鍵の交換を行っているかどうかを確認する。交換している場合はトークン作成が可能である。利用者の入金額をプール口座に預金し、その金額、日付、有効期限などのデータをトークンとして作成する。そして、トークンを該クレジットシステムから受領した公開鍵で暗号化し、暗号化したデータに対して自身の秘密鍵で署名をつける。この秘密鍵は上記前処理でクレジットシステムに渡した自身の公開鍵に対応するものである。このように署名・暗号化されたトークンをICカード上に格納する。ICカード上には銀行サービスを行うAPが搭載されているため、ICカード上のAPと銀行システム間で相互認証が可能である。銀行システムは、当該利用者の銀行APが搭載されたICカードであることを確認した上でトークンを搭載する。そのため、異なる利用者のICカード上にトークンが搭載されず別人による不正利用を防ぐことが可能となる。またトークンはICカード上にセキュアに格納されるためコピーはできない仕組みとなっているが、もし無断コピーされた場合でも、トークン内にトークン作成日付やトークン有効期限、トークンをユニークに識別するIDなどのデータを含むことで、無断コピーによる二重使用の防止が可能となる。次の処理でクレジットシステムが使用可能とするために、トークンをICカード内で銀行APとクレジットAP間で共有する。もしくは、ICカード内の銀行APからクレジットAPへトークンを転送する。
次に銀行システムによる振込処理に移る。銀行システムは、あらかじめ設定された期日にクレジットシステムへの代金振込処理を行う。まずクレジットシステムからの引落しデータを受領する。これはどの利用者からどの金額を引落すかを記載した明細である。銀行システムは該クレジットシステムで決済を行った全利用者の支払代金をプール口座よりそれぞれ引き出す。もし利用者が「ある時払い」ではなく従来通り本人口座に入金している場合はプール口座に該当代金は入金されていないので、利用者本人口座から引き出す。本人口座残高が引落し額に不足の場合は、引き出し不可の事実をクレジットシステムに伝える。これは従来の処理と同様である。プール口座あるいは利用者本人口座から引き出せた場合は、クレジットシステムに対して振込処理を行う。これも従来の処理と同様であり、通常は全利用者の支払代金をまとめてクレジットシステムに対してバッチ処理を行う。
次にクレジットシステムが行う処理について説明する。まず前処理として銀行システムとクレジットシステム間でトークン用の暗号鍵を交換する。銀行システムの暗号鍵はトークンに対して署名処理を行い、銀行が生成した正当なトークンであることを示すために使用される。クレジットサービスのシステムの暗号鍵はトークンに対して暗号化処理を行い、クレジットシステム以外が復号化不可能なためトークンの秘匿性を保持するために使用される。これらの暗号鍵はオープン情報である公開鍵証明書の場合もあるし、銀行とクレジットカード会社間の契約時に専用に生成した暗号鍵である場合もあるだろう。また、暗号鍵の種類は公開鍵系暗号だけはなく、共通鍵系暗号でも可能である。以下、本特許の実施例では公開鍵系暗号鍵により説明するが、共通鍵をシステム間で交換し派生データにより派生鍵を生成させることで同様の処理が可能である。ただし、この場合は両システム間以外に対してはクローズなデータであることと、後に説明するトークンの受け渡し処理の際に派生データを付加する必要がある。
次にクレジットシステムによるクレジット決済時処理に移る。利用者はショッピングやキャッシングを行う際、クレジット決済を指定する。加盟店端末で読み取ったクレジットサービス情報を基に、クレジットシステムは与信情報をチェックする。これは現在行われている処理であり、与信情報とは、該クレジットカードあるいはクレジットAPが搭載されたICカードが紛失・盗難カードではないか、利用可能額は要求された代金に不足していないかなどの内容である。また次にICカード上のトークンを抽出し、前処理で受け取った銀行システムの公開鍵でトークンの署名を検証し正当性を確認する。確認できた場合、自身の秘密鍵でトークンを復号化する。この秘密鍵は上記前処理で銀行システムに渡した自身の公開鍵に対応するものである。ICカード上にはクレジットサービスを行うAPが搭載されているため、ICカード上のAPとクレジットシステム間で相互認証が可能である。クレジットシステムは、当該利用者のクレジットAPが搭載されたICカードであることを確認した上でトークンを抽出する。そのため、異なる利用者のICカード上のトークンを渡されるなどの不正利用を防ぐことが可能となる。またトークンはICカード上にセキュアに格納されるためコピーはできない仕組みとなっているが、もし無断コピーされた場合でも、トークン内にトークン作成日付やトークン有効期限、トークンをユニークに識別するIDなどのデータを含むことで、無断コピーによる二重使用の防止が可能となる。またトークンに含まれる利用者識別データや入金額などのデータを解析し、与信情報に仮反映させる。利用者がクレジット決済要求している金額を与信情報の利用可能額を比較し利用可否を判定し、加盟店端末に結果を提示する。以降は従来のクレジット決済処理と同様である。
次にクレジットシステムによる振込時の与信情報反映処理に移る。クレジットシステムは、銀行システムに利用者と引落し額の対応を記載した明細を渡し、あらかじめ設定された期日に銀行システムからの代金振込を受ける。クレジットシステムは振り込まれた内容により与信情報データベースを反映する。その際、トークンにより仮反映されていた情報の確認を行うことが可能であるため、不正なトークンによる仮反映があった場合は本処理により判明する。
以上が本発明により提供可能な処理の説明であるが、ICカード内の処理は別の方法も可能である。上記では、銀行システムがトークンを格納する際はICカード上の銀行APと相互認証し格納した。その後銀行APが同一ICカード内のクレジットAPに転送あるいは共有した上で、クレジット利用の際は、クレジットシステムがICカード上のクレジットAPと相互認証し当該トークンを抽出するといった手順であった。しかし、銀行システムがトークンを格納する際に、ICカード上のクレジットAPと相互認証し、直接クレジットAPにトークンを格納することも可能である。そのためには、銀行システムとクレジットシステム間の暗号鍵交換処理において、トークン用の鍵の他にICカード上のクレジットAPの公開鍵と、クレジットシステムに署名された銀行システムの公開鍵をクレジットシステムが銀行システムに渡すことが必要である。銀行システムは渡された署名付き自身の公開鍵をICカード上のクレジットAPに渡すことで、お互いがお互いの公開鍵を所有するため、銀行システムとICカード上のクレジットAP間での相互認証が可能となる。ICカードへのトークン格納するための当該方式も本発明の内容の一実現形式である。
また、トークンに含まれるデータとしては、利用者氏名、利用者ID、入金額、入金日、トークンID、トークン有効期限、銀行ID、銀行口座番号、クレジットカード会社ID、クレジットカード番号などである。
以上の本発明が提供するクレジット決済方法により、銀行システムとクレジットシステム間でICカード上のデータを用いた連携が可能となり、利用者が好きな時にクレジット決済の代金を銀行に入金し、その直後でも入金情報を反映したクレジット利用が可能となる。
【０００５】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。本発明に係わるシステムの基本構成は、図2に示される。図2には、符号１０１は銀行サービス提供管理システム（以下銀行システム）であり、銀行は該システムを用いて顧客情報や口座情報の管理、預貯金や引き落し・振込みなどの銀行業務を行う。該システムには、銀行サービス提供管理サーバ（１０２）と銀行サービス提供管理端末（１０５）が存在する。銀行サービス提供管理サーバは、利用者個人口座（１０３）と銀行業務を行う銀行サービス提供管理処理部（１０４）と、そして本発明の特徴であるプール口座（２０１）を有する。プール口座は、利用者がクレジット決済の支払代金として入金しておくために銀行が用意した一時預けのための口座であり、利用者の本人口座ではないため、クレジット利用代金の引落し期日に関係なく入金すれば、それ以降の出金は不可能である。銀行が引落し期日までの間、当該口座を用いて運用することも可能である。銀行サービス提供管理端末は、銀行の各支店などに設置され、利用者が直接アクセスする、いわゆるATM端末である。
符号１２１はクレジットサービス提供管理システム（以下クレジットシステム）であり、クレジットカード会社は該システムを用いて顧客情報やクレジットカード情報の管理、クレジット利用時の与信チェック、決済処理などのクレジットサービス業務を行う。該システムには、クレジットサービス提供管理システム（１２２）とクレジットサービス提供管理端末（１２５）が存在する。クレジットサービス提供管理サーバは、クレジットサービス業務を行うクレジットサービス提供管理処理部（１２３）と、顧客やカード、顧客の与信情報などを持つデータベース（１２４）を有する。クレジットサービス加盟店端末は、クレジットカード会社と契約をした加盟店に設置され、ショッピングやキャッシングなどのクレジットサービスを利用可能な端末を有する。
銀行システムとクレジットシステム間、各システムの端末／サーバ間は、基本的に公衆網や専用線などによるネットワークを通して接続され、情報のやり取りはオンライン上で電文メッセージの送受信により実現されている。しかし、運用事業者のポリシーにより書面や情報記録媒体の郵送・手渡しにより情報のやり取りを実現することも可能である。
また、本発明の実施例の構成は、銀行システム（１０１）とクレジットシステム（１２１）の各処理部（１０４、１２３）に、口座管理や預貯金などの銀行業務処理機能や、クレジット決済、与信情報チェックなどのクレジットサービス処理機能を有している。これらの各処理機能は、コンピュータ・プログラムにしたがって動作させられるものである。
次に本発明の実施例の提案方式によるクレジット決済と代金支払を行う場合の大まかな手順を説明する。
クレジット決済処理は利用者（１１１）からの入金により処理は始まるが、その前処理として行うべき処理がある。それは符号２０２により示される処理であり、銀行システムとクレジットシステム間でお互いの暗号鍵を交換する処理である。これは後で説明するICカードに格納するトークン（TOKEN）に対する署名・暗号化処理のために用いる。交換する暗号鍵は、ベリサインなどの一般的な認証機関により認証された公開鍵証明書である場合もあるし、銀行とクレジットカード会社間の契約時に専用に生成した暗号鍵ペアの公開鍵である場合もある。
以上の前処理が正常に終了した場合、クレジット決済処理を行うことが可能となる。まず、利用者の入金処理に移る。クレジット決済を行った利用者（１１１）は、クレジット利用日から口座引落し期日までのいつでも好きな時に銀行サービス提供管理端末にアクセスし（２０３）、支払代金を銀行が設定したプール口座（２０１）に入金する（２０４）。これは現金を入金する場合もあるし、銀行の利用者本人口座（１０３）からの口座振替の場合もある（２１２）。銀行サービス提供管理処理部（１０４）は、入金対象のクレジットカード会社が契約済みであるかどうか、上記前処理により暗号鍵を交換しているかどうかを確認し、プール口座への入金を行った証明としてトークンを作成し発行する（２０５）。トークンに含まれる事項とは例えば、利用者氏名と入金額、入金日、銀行とクレジットカード会社それぞれの事業者ID、トークンIDや有効期間などである。またこのトークンには符号２０２で受領したクレジットシステムの公開鍵による暗号化を行う。これにより、クレジットシステム以外がデータを復号化し読み取ることが不可能になるため、トークンの秘匿性を保持することが可能となる。また、暗号化したトークンに対して、銀行システムの秘密鍵による署名を付与する。この秘密鍵は符号２０２でクレジットシステムに送付した公開鍵に対応する鍵であり、クレジットシステムがトークンを受け取った際に該署名を検証することで、トークンの正当性をクレジットシステムが確認することが可能となる。このように署名・暗号化処理されたトークンは利用者が保持するICカード（１１０）上に格納される。ICカード上には銀行サービスを行うAPが搭載されているため、ICカード上のAPと銀行システム間で相互認証が可能である。銀行システムは、当該利用者の銀行APが搭載されたICカードであることを確認した上でトークンを搭載する。そのため、異なる利用者のICカード上にトークンが搭載されず別人による不正利用を防ぐことが可能となる。またトークンはICカード上にセキュアに格納されるためコピーはできない仕組みとなっているが、もし無断コピーされた場合でも、トークン内にトークン作成日付やトークン有効期限、トークンをユニークに識別するIDなどのデータを含むことで、無断コピーによる二重使用の防止が可能となる。次の処理でクレジットシステムが使用可能とするため、トークンをICカード内で銀行APとクレジットAP間で共有する。もしくは、ICカード内の銀行APからクレジットAPへトークンを転送する。
クレジット利用時の処理に移る。利用者はショッピングやキャッシングを行う際、クレジット決済を指定する。加盟店端末で、クレジットサービス情報とトークンを読み取り（２０８）、クレジットサービス提供管理サーバに送信する（２０９）。クレジットサービス提供管理処理部（１２３）は受信したクレジットサービス情報を基に、クレジットシステムは与信情報をチェックする。これは現在行われている処理であり、与信情報とは、該クレジットカードあるいはクレジットAPが搭載されたICカードが紛失・盗難カードではないか、利用可能額は要求された代金に不足していないかなどの内容である。また次に、前処理（２０２）で受け取った銀行システムの公開鍵でトークンの署名を検証し正当性を確認する。確認できた場合、自身の秘密鍵でトークンを復号化する。この秘密鍵は上記前処理（２０２）で銀行システムに渡した自身の公開鍵に対応するものである。ICカード上にはクレジットサービスを行うAPが搭載されているため、ICカード上のAPとクレジットシステム間で相互認証が可能である。クレジットシステムは、当該利用者のクレジットAPが搭載されたICカードであることを確認した上でトークンを抽出する。そのため、異なる利用者のICカード上のトークンを渡されるなどの不正利用を防ぐことが可能となる。またトークンはICカード上にセキュアに格納されるためコピーはできない仕組みとなっているが、もし無断コピーされた場合でも、トークン内にトークン作成日付やトークン有効期限、トークンをユニークに識別するIDなどのデータを含むことで、無断コピーによる二重使用の防止が可能となる。クレジットサービス提供管理処理部（１２３）はトークンに含まれる利用者識別データや入金額などのデータを解析し、与信情報データベース（１２４）に仮反映させる。そして、利用者がクレジット決済要求している金額を仮反映した与信情報の利用可能額と比較し利用可否を判定し、加盟店端末に結果を提示する（２１０）。加盟店端末はこの結果をもとにクレジット決済処理を進めるか、あるいは処理を中止する（２１１）。以降は従来のクレジット決済処理を同様である。
次に口座引落し日における振込処理に移る。銀行システムは、クレジットシステムからの引落しデータを受領する。これはどの利用者からどの金額を引落すかを記載した明細である。銀行システムは該クレジットシステムで決済を行った全利用者の支払代金をプール口座よりそれぞれ引き出し、あらかじめ設定された期日にクレジットシステムへの代金振込処理（２１２）を行う。もし利用者が「ある時払い」ではなく従来通り本人口座に入金している場合はプール口座に該当代金は入金されていないので、利用者本人口座から引き出す。本人口座残高が引落し額に不足の場合は、引き出し不可の事実をクレジットシステムに伝える。これは従来の処理と同様である。プール口座あるいは利用者本人口座から引き出せた場合は、クレジットシステムに対して振込処理を行う。このクレジットシステムへの振込処理（２１２）は従来と同様の処理であり、全利用者分をまとめてバッチ処理で振り込むことが多い。
以上が本発明に係わるシステムの基本構成と処理であるが、ICカード内の処理については２つの方法が可能であり、それに対応してシステム側の処理にも変更点が生じてくる。図14と図１５を用いて詳細に説明する。図14はこれまでに説明した1番目の方式を示す図であり、銀行システムがトークンを格納する際はICカード上の銀行APと相互認証し格納した（１４１１）。その後銀行APが同一ICカード内のクレジットAPに転送あるいは共有した上で（１４１２）、クレジット利用の際は、クレジットシステムがICカード上のクレジットAPと相互認証し当該トークンを抽出する（１４１３）といった手順であった。しかし、銀行システムがトークンを格納する際に、ICカード上のクレジットAPと相互認証し、直接クレジットAPにトークンを格納することも可能である。図１５を用いて、2番目の方法を説明する。あらかじめ銀行システムとクレジットシステム間で暗号鍵交換処理を行うが、トークン用の鍵の他にICカード上のクレジットAPの公開鍵と、クレジットシステムに署名された銀行システムの公開鍵をクレジットシステムが銀行システムに渡しておく（１５０１）。銀行システムは、ICカード内の銀行APと通信するのではなく、符号１５０１でクレジットシステムから受け取ったICカード内クレジットAPの公開鍵を用いてクレジットAPと通信し、相互認証した上でトークンを格納する（１５０２）。この場合符号１５０３のクレジットシステムのよるトークン抽出処理に関してはクレジットシステムとICカード内クレジットAPとの通信であるため変更点は生じない。
またトークンと呼ぶデータに含まれてる項目の例を示したのが図１２である。利用者氏名、利用者ID、入金額、入金日、トークンID、トークン有効期限、銀行ID、銀行口座番号、クレジットカード会社ID、クレジットカード番号などを含むことで、トークンの二重使用防止や、利用者本人以外の使用防止を実現することが可能となる。
トークンの署名暗号化については図１３で説明する。図12に例示されたような内容のトークンを銀行システムはまず、クレジットシステムの公開鍵で暗号化する。これにより、クレジットシステムの秘密鍵以外では復号化は不可能であり、クレジットシステム以外への秘匿性が保持される。次に、銀行システムは自身の秘密鍵で署名を付与する。この秘密鍵に対応する公開鍵は予めクレジットシステムに渡しているため、当該トークンを銀行システムが作成したことをクレジットシステムが検証することが可能となる。
以上が、システム構成を含めた全体の流れとなる。次にシステムの各構成要素について説明を行う。
図3はICカード・システムの例の概要を示す図である。ICカード１１０の中にはチップ３０２があって、リーダライタ（もしくはリーダライタを有する端末）３０３とデータのやりとりを行う例を示している。リーダライタの中にはコントロール・プロセッサ３０４やデータベースとなる磁気ディスク３０５などが存在する。ICカード１１０には、通例通り、例えば、Vcc（供給電源）、GND（グランド）、RST（リセット）、I/O（入出力）、及びCLK（クロック）などの諸端子が示されている。また、図中、符号３０６はリーダライタ３０３からICカード１１０に対しての、例えばカードIDなどの各種問合せを示す。符号３０７はICカードが前述の問合せに対して行った返答を示す。こうした、諸情報の伝達は通例のシステムで十分である。
【０００６】
なお、ICカード内のICチップにおいて、具体的には前述のアプリケーションはメモリ領域に搭載される。一般に、メモリとしては、RAM（Random Access Memory）、EEPROM（Electrical Erasable Programmable Read Only Memory）あるいはROM（Read Only Memory）などが用いられる。
次に図4にこのようなICカード（１１０）内に搭載されているIC内部の基本的な領域の論理的な構成を示す。当該ICは、通例のマイクロ・コンピュータと同様に、ハードウェア層（４０３）とOSが搭載される領域、即ちOS層（４０２）とアプリケーションが搭載される領域、即ちアプリケーション層（４０１）とを有する。ここで、マルチアプリケーション搭載可能とは、アプリケーション層（４０１）に複数のアプリケーション（４０４−４０６）が搭載できるということである。また、アプリケーションの初期搭載とはこのアプリケーション（４０４−４０６）をICカード発行時に既に搭載された状態で利用申請者のもとに配布することであり、ダイナミックローディング可能とはこのアプリケーション（４０４−４０６）をカード発行後に、搭載あるいは削除が可能であることを示す。OS層（４０２）は通信処理部（４０７）、インタープリタ（４０８）、セキュリティ機構（４０９）などを有し、外部端末からのコマンド受信やアプリケーションのコマンド転送などを行っている。当然、アプリケーション層（４０１）とOS層（４０２）との間にはアプリケーション・インターフェイス、OS層（４０２）とハードウェア層（４０３）との間にはハードウェア・インターフェイスが設置されている。
次に本発明の実施例に係わる、クレジット決済処理の具体的方法を説明する。まず図5のシーケンスを用いて利用者による入金処理とクレジット利用、代金振込処理を説明する。まず、銀行（５０３）とクレジットカード会社（５０４）間でトークン用に暗号鍵を交換する（ステップ５１１）。クレジットサービスを利用した利用者（５０１）はその代金を期日までのいつでも好きな時に銀行に入金する（ステップ５１２）。銀行は入金したことの証明としてトークンを作成し利用者のICカード（５０２）に送信する（ステップ５１３）。次に、利用者がクレジットサービスを利用する際、ICカードからクレジットカード番号などのクレジットサービス情報とトークンを抽出し、クレジットカード会社に送信する（ステップ５１４）。クレジットカード会社は受信したクレジットサービス情報により、該カードが紛失・盗難カードかどうか、有効期限は過ぎてないかなどの与信情報を確認する。また受信したトークンの正当性を確認し、トークンに記載された入金額を利用可能限度額に仮反映する。仮反映した利用可能限度額を、クレジット利用を要求されている額の比較検討を行い、その結果を利用者に提示し（ステップ５０１）、以降は従来のクレジット利用処理を続行する。
以上で説明した本発明の実施例におけるクレジット決済方法の詳細について、銀行システムとクレジットシステムの各システムの動作フローチャート（図６〜図11）を用いて説明する。これらは図5のシーケンスを詳細化したものである。
図６〜図8は本発明の実施例における銀行システムの動作フローチャートである。
まず図6において銀行システムの鍵交換時処理について説明する。銀行システムはクレジットシステムと公開鍵を交換する（ステップ６０１）。前述したようにICカード内の処理に関連して、銀行システムがトークンをICカード内のクレジットAPに直接格納する場合は、通信を確立し相互認証するためのクレジットAP公開鍵とクレジットシステムに署名された銀行システムの公開鍵を、ステップ６０１でクレジットシステムから合わせて受け取っておく。
次に図7において銀行システムの利用者による入金時処理について説明する。利用者はクレジット決済の代金の入金を銀行システムに要求する（ステップ７０１）。銀行システムは要求されたクレジットシステムが契約をしており上記処理による暗号鍵の交換を行っているかどうかを確認する（ステップ７０２）。契約済でない場合は本発明に記載の方法によるクレジット利用代金の支払いはできない旨を利用者に提示し、処理を中止する（ステップ７０６）。契約済の場合ははトークン作成が可能であるため、利用者の入金額をプール口座に預金し、その金額、日付、有効期限などのデータをトークンとして作成する（ステップ７０３）。そして、トークンを該クレジットシステムから受領した公開鍵で暗号化し、暗号化したデータに対して自身の秘密鍵で署名をつける（ステップ７０４）。この秘密鍵は上記前処理でクレジットシステムに渡した自身の公開鍵に対応するものである。このように署名・暗号化されたトークンをICカード上に格納する（ステップ７０５）。ICカード上には銀行サービスを行うAPが搭載されているため、ICカード上のAPと銀行システム間で相互認証が可能である。銀行システムは、当該利用者の銀行APが搭載されたICカードであることを確認した上でトークンを搭載する。トークンは次の処理でクレジットシステムが使用可能とするため、ICカード内で銀行APとクレジットAP間で共有する。もしくは、ICカード内の銀行APからクレジットAPへトークンを転送する。また、クレジットシステムからICカード内クレジットAPの公開鍵を受け取っている場合は、ICカード内のクレジットAPと相互認証可能であり、その上でトークンを格納する。
次に図8において銀行システムの振込時処理について説明する。銀行システムは、あらかじめ設定された期日にクレジットシステムへの代金振込処理を行う。まずクレジットシステムからの引落しデータを受領する（ステップ８０１）。これはどの利用者からどの金額を引落すかを記載した明細である。銀行システムは該クレジットシステムで決済を行った全利用者の支払代金をプール口座よりそれぞれ引き出す（ステップ８０２）。利用者が「ある時払い」ではなく従来通り本人口座に入金している場合、プール口座に該当代金は入金されていないので、利用者本人口座から引き出す。本人口座残高が引落し額に不足の場合は、引き出し不可の事実をクレジットシステムに伝える（ステップ８０５）。これは従来の処理と同様である。プール口座あるいは利用者本人口座から引き出せた場合は、クレジットシステムに対して振込処理を行う（ステップ８０４）。これも従来の処理と同様であり、通常は全利用者の支払代金をまとめてクレジットシステムに対してバッチ処理を行う。
図9〜図11は本発明の実施例におけるクレジットシステムの動作フローチャートである。
まず図9においてクレジットシステムの鍵交換時処理について説明する。クレジットシステムは銀行システムと公開鍵を交換する（ステップ９０１）。前述したようにICカード内の処理に関連して、銀行システムがトークンをICカード内のクレジットAPに直接格納する場合は、通信を確立し相互認証するためのクレジットAP公開鍵とクレジットシステムが署名した銀行システムの公開鍵を、ステップ９０１で銀行システムに合わせて送付する必要がある。
次に図10においてクレジットシステムの利用者によるクレジット利用時処理について説明する。利用者はショッピングやキャッシングを行う際、クレジット決済を指定し加盟店端末では受信する（ステップ１００１）。加盟店端末で読み取ったクレジットサービス情報を基に、クレジットシステムは与信情報をチェックする（ステップ１００２）。これは従来行われている処理であり、与信情報とは、該クレジットカードあるいはクレジットAPが搭載されたICカードが紛失・盗難カードではないか、利用可能額は要求された代金に不足していないかなどの内容である。与信情報に問題がある場合は、利用不可を利用者に提示し処理を中止する（ステップ１００９）。与信情報に問題がない場合は、ICカード上のトークンを抽出し、前処理で受け取った銀行システムの公開鍵でトークンの署名を検証し正当性を確認する（ステップ１００３）。正当性を確認できない場合、あるいは、トークンがICカード内に存在しない場合はトークンに関連するステップを省略しステップ１００６へ続ける。ステップ１００３においてトークンの正当性を確認できた場合、自身の秘密鍵でトークンを復号化する（ステップ１００４）。この秘密鍵は上記前処理で銀行システムに渡した自身の公開鍵に対応するものである。次に復号化したトークンに含まれる利用者識別データや入金額などのデータを解析し、与信情報データベースに仮反映させる（ステップ１００５）。利用者がクレジット決済要求している金額を与信情報データベースの利用可能額と比較する（ステップ１００６）。比較結果により利用可否を判定し（ステップ１００７）、利用要求額が利用可能額より大きい場合は利用不可を利用者に提示し処理を中止する（ステップ１０１０）。利用要求額が利用可能額の範囲内である場合は利用者に利用可能であることを提示し、クレジットサービスの利用処理を進める（ステップ１００８）。以降は従来のクレジット決済処理を同様である。
次に図11においてクレジットシステムの振込時処理について説明する。クレジットシステムは、銀行システムに利用者と引落し額の対応を記載した明細を渡し（ステップ１１０１）、あらかじめ設定された期日に銀行システムからの代金振込を受ける（ステップ１１０２）。クレジットシステムは振り込まれた内容により与信情報データベースを反映する（ステップ１１０３）。その際、トークンにより仮反映されていた情報の確認を行うことが可能であるため、不正なトークンによる仮反映があった場合は本処理により判明する。
以上が本発明の実施の形態である。ICカードには接触型ICカード、非接触型ICカードなどがあるが、本発明の実施例ではこうしたICカードの構成自体によらず適用することが可能である。
【０００７】
以上説明したように、本発明の実施例によれば次のようなことが可能となる。
（１） 利用者がクレジットサービスを利用し、その代金支払い方式を口座引き落としにしている場合、利用者が期日までに銀行に入金した際、その入金した情報をICカード内にセキュアに格納し、クレジット利用時にクレジットシステムにアップロードすることで、クレジット利用の利用可能額にリアルタイムに反映することが可能となる。
（２） また、利用者がクレジット利用代金を、手元にあるときに「ある時払い」を、通常利用している銀行端末を通じて行うことが可能となる。また、その際入金した情報をICカード内にセキュアに格納することで、（１）と同様にクレジット利用の利用可能額にリアルタイムに反映することが可能となる。
【０００８】
【発明の効果】
利用者がクレジット利用代金を銀行口座に入金した際、入金した情報をデータ化しICカード内に格納することで、銀行サービス提供管理システムとクレジットサービス提供管理システムとの間の連携をとることが可能となる。
【０００９】
また、銀行サービス提供管理システム内に、利用者がクレジットカード会社に支払う代金をまとめて入金しておく共通の口座を設けることで、利用者が手元に代金あるときや都合の良いいつでも好きなタイミングで入金する「ある時払い」を行うことが可能となる。
【図面の簡単な説明】
【図１】従来のクレジット決済システム構成を示す図。
【図2】本発明の実施形態に係るトークンを利用したクレジット利用代金支払い方法を実施するクレジット決済システム構成を示す図。
【図3】カードシステムの概要を示す図。
【図4】ICカードの基本構成を示す図。
【図5】利用者の入金に応じてトークンをICカードに格納し、クレジット利用時の与信情報に反映するための本発明に係るシーケンスを示す図。
【図6】銀行システムが、クレジットシステムと公開鍵を交換するための本発明に係るシーケンスを示す図。
【図７】銀行システムが、利用者からの入金要求を受け付け、トークンを作成・発行するための本発明に係るシーケンスを示す図。
【図8】銀行システムが、期日にクレジット利用代金をクレジットシステムに振り込むための本発明に係るシーケンスを示す図。
【図９】クレジットシステムが、銀行システムと公開鍵を交換するための本発明に係るシーケンスを示す図。
【図１０】クレジットシステムが、利用者からのクレジット利用要求を受け付け、トークンを抽出・確認し、与信情報に反映させるための本発明に係るシーケンスを示す図。
【図１１】クレジットシステムが、期日に銀行からのクレジット利用代金振込みを受け付け、与信情報に反映し、トークン情報の正当性を確認するための本発明に係るシーケンスを示す図。
【図１２】銀行システムが、利用者が入金したことを示すためにICカード内に格納するトークンに含まれる項目例。
【図１３】トークンの署名と暗号方式例。
【図１４】本発明の他の実施例を説明するための図である。
【図１５】本発明の他の実施例を説明するための図である。
【符号の説明】
１０１： 銀行サービス提供管理システム
１０２： 銀行サービス提供管理サーバ
１０３： 利用者個人口座
１０４： 銀行サービス提供管理処理部
１０５： 銀行サービス提供管理端末
１１０： ICカード
１１１： 利用者
１２１： クレジットサービス提供管理システム
１２２： クレジットサービス提供管理サーバ
１２３： クレジットサービス提供管理処理部
１２４： 与信情報データベース
１２５： クレジットサービス加盟店端末
１３１： クレジット利用代金入金処理
１３２： クレジット利用代金口座入金処理
１３３： 利用者移動
１３４： クレジット利用要求処理
１３５： 与信情報確認処理
１３６： 与信情報結果提示処理
１３７： クレジット利用可否提示処理
１３８： クレジット利用代金振込み処理
２０１： プール口座
２０２： 公開鍵交換処理
２０３： クレジット利用代金入金処理
２０４： クレジット利用代金口座入金処理
２０５： トークン送信処理
２０６： トークン格納処理
２０７： 利用者移動
２０８： クレジット利用要求処理
２０９： クレジット利用可否確認処理
２１０： クレジット利用可否提示処理
２１１： クレジット利用可否提示処理
３０２： ICチップ
３０３： ICカード処理端末
３０４： ICカードシステム処理部
３０５： ICカードシステムデータベース
３０６： ICカードコマンド要求
３０７： ICカードコマンド応答
４０１： アプリケーション層
４０２： OS層
４０３： ハードウェア層
４０４、４０５、４０６： ICカードアプリケーション
４０７： 通信処理部
４０８： インタープリタ
４０９： セキュリティ機構
５０１： 利用者
５０２： ICカード
５０３： 銀行
５０４： クレジットカード会社
１４０１： ICカード内銀行サービスAP
１４０２： ICカード内クレジットサービスAP
１４１１： トークン格納処理
１４１２： ICカード内トークン転送処理
１４１３： トークン抽出処理
１５０１： ICカード内クレジットAP公開鍵送信処理
１５０２： トークン格納処理
１５０３： トークン抽出処理。
【発明の属する技術分野】
本発明は、ICカードを利用し、クレジットサービスシステムと銀行サービスシステムを連携した決済システムに関する。
【０００２】
【従来の技術】
従来、クレジットカードを利用した決済処理を行った場合、その支払いは銀行口座からの期日引落し、もしくは小切手や現金による振込みであった。利用者はクレジットカード会社から送付される請求書に従い、期日までに代金を支払う。クレジットカード会社は、銀行や利用者からの振込みを確認した上で、支払われた金額分だけ利用可能額を引き上げるという方式を取っている。
近年、磁気カードに代わり、1枚のカードに複数のサービスが搭載可能な多機能ICカードが普及しつつあるが、これを用いた場合も上記方式と同様である。多機能ICカードでは、クレジットサービスを行うICカードアプリケーション（以下AP）と、銀行口座の預貯金などを行うAPが1枚のICカード上に存在可能である。
【０００３】
【発明が解決しようとする課題】
上記従来技術において、クレジット決済の支払を銀行口座からの自動引落しにしている場合、利用者が銀行にクレジット利用額を入金し引落されてから、クレジットカード会社の利用可能額に反映されるまで数日かかるという問題点があった。また、通常は銀行口座からの自動引落しを支払い方式として選択する利用者が多いが、該方式だと「手元にある今、クレジット利用額を払っておきたい」「今、払った金額分をリアルタイムにクレジット利用可能額に反映させたい」という要求に対応できないという課題がある。以下では、この課題について詳細に説明する。
図1は従来のクレジットサービス決済システムの構成を表している。まず、システムの構成要素について概要を説明する。
符号１０１は銀行サービス提供管理システム（以下銀行システム）であり、銀行は該システムを用いて顧客情報や口座情報の管理、預貯金や引き落し・振込みなどの銀行業務を行う。該システムには、銀行サービス提供管理サーバ（１０２）と銀行サービス提供管理端末（１０５）が存在する。銀行サービス提供管理サーバは、利用者個人口座（１０３）と銀行業務を行う銀行サービス提供管理処理部（１０４）を有する。銀行サービス提供管理端末は、銀行の各支店などに設置され、利用者が直接アクセスする、いわゆるATM端末である。
符号１２１はクレジットサービス提供管理システム（以下クレジットシステム）であり、クレジットカード会社は該システムを用いて顧客情報やクレジットカード情報の管理、クレジット利用時の与信チェック、決済処理などのクレジットサービス業務を行う。該システムには、クレジットサービス提供管理システム（１２２）とクレジットサービス加盟店端末（１２５）が存在する。クレジットサービス提供管理サーバは、クレジットサービス業務を行うクレジットサービス提供管理処理部（１２３）と、顧客情報やカード情報、顧客の与信情報などを持つデータベース（１２４）を有する。クレジットサービス加盟店端末は、クレジットカード会社と契約をした加盟店に設置され、ショッピングやキャッシングなどのクレジットサービスを利用可能な端末を有する。
銀行システムとクレジットシステム間は公衆網などのネットワークあるいは専用線によるネットワークあるいは、書面や情報記録媒体の郵送・手渡しにより情報のやり取りを実現する。また、各システムの端末／サーバ間は、公衆網もしくは専用線のネットワークにより情報のやり取りを実現する。
また、上述の銀行システム（１０１）とクレジットシステム（１２１）は、各々の処理部（１０４、１２３）に、口座管理や預貯金などの銀行業務処理機能や、クレジット決済、与信情報チェックなどのクレジットサービス処理機能を有している。これらの各処理機能は、コンピュータ・プログラムとして実現され、動作する。
次に、上記システムにおけるクレジット決済と代金支払業務の動作手順を例にとり、従来システムの課題を説明する。
クレジット決済を行った利用者（１１１）は、口座引落し期日までに銀行サービス提供管理端末（１０５）にアクセスし（１３１）、支払金額を本人の引落し指定口座（１０３）に入金する（１３２）。引落し期日になると銀行サービス提供管理処理部（１０４）はクレジットカード会社からの指定された金額を利用者口座（１０３）から引き出しクレジットサービス提供管理処理部（１２３）に振り込む（１３８）。クレジットサービス提供管理処理部（１２３）は振り込まれた金額を確認し、利用者の与信情報データベース（１２４）を更新する。与信情報データベースには、利用者の利用可能額と未支払金額などの情報が格納されている。利用者がクレジット加盟端末に移動し（１３３）、クレジット決済を要求した際は（１３４）、加盟店端末はこの与信情報を確認し（１３５）、結果を受信し（１３６）、利用者に対して利用可否を提示する（１３７）。
ここで従来のシステムにおける第1の課題は、銀行システムからクレジットシステムへ代金が支払われてから、与信情報データベースへ反映されるまでがリアルタイムでない場合があることである。これは、振り込まれてからデータ解析処理とデータベース更新処理に時間がかかることや、銀行システムによる振込み処理がバッチ処理であることなどに起因する。
第2の課題は、利用者が銀行システムに対して行うクレジット決済代金の入金は、通常の預金と処理手順が変わらないため、利用者が余裕のある時に「ある時払い」を行いたい場合に、口座入金を行ってもクレジットサービスに振り込まれるのは決まった期日となるため、与信情報への反映が遅れる点である。また「口座に残っていれば使ってしまう」といった利用者の気持ちにも対応していない。利用者が「ある時払い」をしたい場合は、クレジットシステムへ振り込み処理を行う、あるいはクレジットシステムの窓口に行って直接支払うなどの通常と違った支払方法を行わなければならない。また、最近では「ある時払い」専用のカードも利用可能となっているが、これはクレジット支払方式のデフォルトが「ある時払い」であり、デフォルトの支払方式を銀行口座からの自動引落しとし、時々「ある時払い」を行いたいなどの利用者の多様な要求に柔軟に対応するのは難しい。
また「ある時払い」したい状況としては、上記のように余裕のある時に払ってしまいたいという利用者の希望だけでなく、ボーナス払いにしてある金額の引き落とし日とボーナス支給日の間にかなり開きがあるのでボーナス支給と同時に支払いたいという場合や、手元に現金があるが海外渡航するためクレジット利用可能額を引き上げておきたいといった場合がある。
以上で、従来システムにおける２つの課題についての説明を終える。
【０００４】
【課題を解決するための手段】
上記課題を解決するために、本発明は利用者の入金情報を示したデータをICカード上に格納することで銀行システムとクレジットシステム間の連携可能とし、利用者が好きな時にクレジット決済の代金を銀行に入金し、その直後でも入金情報を反映したクレジット利用が可能なクレジット決済システムを提供する。
以下、詳細に説明する。
まず第1の課題である、利用者の銀行口座からの代金引落しとクレジットの与信情報への反映の間がリアルタイムでないという問題に対して本発明の実施例では、ICカード上に入金情報を示したデータを格納し、クレジット決済時はこのデータを確認し、与信情報の仮反映させることで解決する。本発明ではこの入金情報を示したデータをトークン（TOKEN）と呼ぶ。利用者が銀行サービスに対してクレジット決済の代金を入金した際、銀行システムはその金額、日付、有効期限などを示したトークンに自身の暗号鍵で署名し、ICカード上に格納する。ICカードには銀行サービスを行うAPが搭載されているため、ICカードとシステム間で相互認証することで該口座以外のICカードへの搭載を防ぐことが可能である。そして、利用者が直後にクレジット決済を利用する際は、直前の入金は銀行サービスからクレジットサービスへまだ振り込まれておらず与信情報データベースに反映されていないため、従来は利用可能額に直前の入金額は反映されないが、クレジットシステムにトークン検証手段を持たせることで解決する。クレジットシステムがトークンを検証し正当性を確認できた場合はトークンを信用し、記載の入金額を与信情報に仮反映させる。通常でもクレジット決済利用の際は、サーバに与信情報をオンラインで確認しているため、同時にトークンもサーバに渡すことで署名検証と与信情報への仮反映を行えばよい。また、期日には銀行システムからの振込み処理が行われているため、トークンによる仮反映の正当性を実際に確認することが可能でなる。
また、第2の課題である、利用者がクレジット決済の代金を払いたい時に「ある時払い」し、なおかつクレジット利用可能額へのリアルタイムな反映を行いたいという課題に対して、本発明での実施例では、銀行システム内にクレジットシステムへ振り込むべき金額を入金しておく共通の口座を設置することで解決する。本発明ではこの口座をプール口座と呼ぶ。利用者は通常は銀行の本人口座に入金し期日になると引落されるという支払方式だが、「ある時払い」をしたい場合はこのプール口座に入金する。もしくは本人口座から振替を行う。この場合も同様に銀行システムは、入金額、日付、有効期限などを示したトークンをICカード上に格納する。プール口座は利用者の本人口座ではないため、クレジット利用代金の引落し期日に関係なく入金すれば、それ以降の出金は不可能である。
利用者はこのトークンをクレジット決済の際に使用することで、リアルタイムな利用可能額への反映が可能となる。銀行システムは期日になったら、通常は利用者口座からの引落しするところを、プール口座からの引き落としを行いクレジットシステムに振込みを行う。振り込み処理はバッチ処理であることが多いが、本発明の実施例では引落し先が利用者口座かプール口座かの違いだけであって、これまでのバッチ処理に対する修正点は少ない。
具体的に、上記２つの解決手段を用いて銀行システムとクレジットシステムが連携して行う、クレジット決済処理について説明する。まず前処理として銀行システムとクレジットシステム間でトークン用の暗号鍵を交換する。銀行システムの暗号鍵はトークンに対して署名処理を行い、銀行が生成した正当なトークンであることを示すために使用される。クレジットサービスのシステムの暗号鍵はトークンに対して暗号化処理を行い、クレジットシステム以外が復号化不可能なためトークンの秘匿性を保持するために使用される。これらの暗号鍵はオープン情報である公開鍵証明書の場合もあるし、銀行とクレジットカード会社間の契約時に専用に生成した暗号鍵である場合もあるだろう。また、暗号鍵の種類は公開鍵系暗号だけはなく、共通鍵系暗号でも可能である。以下、本特許の実施例では公開鍵系暗号鍵により説明するが、共通鍵をシステム間で交換し派生データにより派生鍵を生成させることで同様の処理が可能である。ただし、この場合は両システム間以外に対してはクローズなデータであることと、後に説明するトークンの受け渡し処理の際に派生データを付加することに注意する必要がある。
次に銀行システムによる利用者の入金処理に移る。利用者はクレジット決済の代金の入金を銀行システムに要求する。要求されたクレジットシステムが契約をしており上記処理による暗号鍵の交換を行っているかどうかを確認する。交換している場合はトークン作成が可能である。利用者の入金額をプール口座に預金し、その金額、日付、有効期限などのデータをトークンとして作成する。そして、トークンを該クレジットシステムから受領した公開鍵で暗号化し、暗号化したデータに対して自身の秘密鍵で署名をつける。この秘密鍵は上記前処理でクレジットシステムに渡した自身の公開鍵に対応するものである。このように署名・暗号化されたトークンをICカード上に格納する。ICカード上には銀行サービスを行うAPが搭載されているため、ICカード上のAPと銀行システム間で相互認証が可能である。銀行システムは、当該利用者の銀行APが搭載されたICカードであることを確認した上でトークンを搭載する。そのため、異なる利用者のICカード上にトークンが搭載されず別人による不正利用を防ぐことが可能となる。またトークンはICカード上にセキュアに格納されるためコピーはできない仕組みとなっているが、もし無断コピーされた場合でも、トークン内にトークン作成日付やトークン有効期限、トークンをユニークに識別するIDなどのデータを含むことで、無断コピーによる二重使用の防止が可能となる。次の処理でクレジットシステムが使用可能とするために、トークンをICカード内で銀行APとクレジットAP間で共有する。もしくは、ICカード内の銀行APからクレジットAPへトークンを転送する。
次に銀行システムによる振込処理に移る。銀行システムは、あらかじめ設定された期日にクレジットシステムへの代金振込処理を行う。まずクレジットシステムからの引落しデータを受領する。これはどの利用者からどの金額を引落すかを記載した明細である。銀行システムは該クレジットシステムで決済を行った全利用者の支払代金をプール口座よりそれぞれ引き出す。もし利用者が「ある時払い」ではなく従来通り本人口座に入金している場合はプール口座に該当代金は入金されていないので、利用者本人口座から引き出す。本人口座残高が引落し額に不足の場合は、引き出し不可の事実をクレジットシステムに伝える。これは従来の処理と同様である。プール口座あるいは利用者本人口座から引き出せた場合は、クレジットシステムに対して振込処理を行う。これも従来の処理と同様であり、通常は全利用者の支払代金をまとめてクレジットシステムに対してバッチ処理を行う。
次にクレジットシステムが行う処理について説明する。まず前処理として銀行システムとクレジットシステム間でトークン用の暗号鍵を交換する。銀行システムの暗号鍵はトークンに対して署名処理を行い、銀行が生成した正当なトークンであることを示すために使用される。クレジットサービスのシステムの暗号鍵はトークンに対して暗号化処理を行い、クレジットシステム以外が復号化不可能なためトークンの秘匿性を保持するために使用される。これらの暗号鍵はオープン情報である公開鍵証明書の場合もあるし、銀行とクレジットカード会社間の契約時に専用に生成した暗号鍵である場合もあるだろう。また、暗号鍵の種類は公開鍵系暗号だけはなく、共通鍵系暗号でも可能である。以下、本特許の実施例では公開鍵系暗号鍵により説明するが、共通鍵をシステム間で交換し派生データにより派生鍵を生成させることで同様の処理が可能である。ただし、この場合は両システム間以外に対してはクローズなデータであることと、後に説明するトークンの受け渡し処理の際に派生データを付加する必要がある。
次にクレジットシステムによるクレジット決済時処理に移る。利用者はショッピングやキャッシングを行う際、クレジット決済を指定する。加盟店端末で読み取ったクレジットサービス情報を基に、クレジットシステムは与信情報をチェックする。これは現在行われている処理であり、与信情報とは、該クレジットカードあるいはクレジットAPが搭載されたICカードが紛失・盗難カードではないか、利用可能額は要求された代金に不足していないかなどの内容である。また次にICカード上のトークンを抽出し、前処理で受け取った銀行システムの公開鍵でトークンの署名を検証し正当性を確認する。確認できた場合、自身の秘密鍵でトークンを復号化する。この秘密鍵は上記前処理で銀行システムに渡した自身の公開鍵に対応するものである。ICカード上にはクレジットサービスを行うAPが搭載されているため、ICカード上のAPとクレジットシステム間で相互認証が可能である。クレジットシステムは、当該利用者のクレジットAPが搭載されたICカードであることを確認した上でトークンを抽出する。そのため、異なる利用者のICカード上のトークンを渡されるなどの不正利用を防ぐことが可能となる。またトークンはICカード上にセキュアに格納されるためコピーはできない仕組みとなっているが、もし無断コピーされた場合でも、トークン内にトークン作成日付やトークン有効期限、トークンをユニークに識別するIDなどのデータを含むことで、無断コピーによる二重使用の防止が可能となる。またトークンに含まれる利用者識別データや入金額などのデータを解析し、与信情報に仮反映させる。利用者がクレジット決済要求している金額を与信情報の利用可能額を比較し利用可否を判定し、加盟店端末に結果を提示する。以降は従来のクレジット決済処理と同様である。
次にクレジットシステムによる振込時の与信情報反映処理に移る。クレジットシステムは、銀行システムに利用者と引落し額の対応を記載した明細を渡し、あらかじめ設定された期日に銀行システムからの代金振込を受ける。クレジットシステムは振り込まれた内容により与信情報データベースを反映する。その際、トークンにより仮反映されていた情報の確認を行うことが可能であるため、不正なトークンによる仮反映があった場合は本処理により判明する。
以上が本発明により提供可能な処理の説明であるが、ICカード内の処理は別の方法も可能である。上記では、銀行システムがトークンを格納する際はICカード上の銀行APと相互認証し格納した。その後銀行APが同一ICカード内のクレジットAPに転送あるいは共有した上で、クレジット利用の際は、クレジットシステムがICカード上のクレジットAPと相互認証し当該トークンを抽出するといった手順であった。しかし、銀行システムがトークンを格納する際に、ICカード上のクレジットAPと相互認証し、直接クレジットAPにトークンを格納することも可能である。そのためには、銀行システムとクレジットシステム間の暗号鍵交換処理において、トークン用の鍵の他にICカード上のクレジットAPの公開鍵と、クレジットシステムに署名された銀行システムの公開鍵をクレジットシステムが銀行システムに渡すことが必要である。銀行システムは渡された署名付き自身の公開鍵をICカード上のクレジットAPに渡すことで、お互いがお互いの公開鍵を所有するため、銀行システムとICカード上のクレジットAP間での相互認証が可能となる。ICカードへのトークン格納するための当該方式も本発明の内容の一実現形式である。
また、トークンに含まれるデータとしては、利用者氏名、利用者ID、入金額、入金日、トークンID、トークン有効期限、銀行ID、銀行口座番号、クレジットカード会社ID、クレジットカード番号などである。
以上の本発明が提供するクレジット決済方法により、銀行システムとクレジットシステム間でICカード上のデータを用いた連携が可能となり、利用者が好きな時にクレジット決済の代金を銀行に入金し、その直後でも入金情報を反映したクレジット利用が可能となる。
【０００５】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。本発明に係わるシステムの基本構成は、図2に示される。図2には、符号１０１は銀行サービス提供管理システム（以下銀行システム）であり、銀行は該システムを用いて顧客情報や口座情報の管理、預貯金や引き落し・振込みなどの銀行業務を行う。該システムには、銀行サービス提供管理サーバ（１０２）と銀行サービス提供管理端末（１０５）が存在する。銀行サービス提供管理サーバは、利用者個人口座（１０３）と銀行業務を行う銀行サービス提供管理処理部（１０４）と、そして本発明の特徴であるプール口座（２０１）を有する。プール口座は、利用者がクレジット決済の支払代金として入金しておくために銀行が用意した一時預けのための口座であり、利用者の本人口座ではないため、クレジット利用代金の引落し期日に関係なく入金すれば、それ以降の出金は不可能である。銀行が引落し期日までの間、当該口座を用いて運用することも可能である。銀行サービス提供管理端末は、銀行の各支店などに設置され、利用者が直接アクセスする、いわゆるATM端末である。
符号１２１はクレジットサービス提供管理システム（以下クレジットシステム）であり、クレジットカード会社は該システムを用いて顧客情報やクレジットカード情報の管理、クレジット利用時の与信チェック、決済処理などのクレジットサービス業務を行う。該システムには、クレジットサービス提供管理システム（１２２）とクレジットサービス提供管理端末（１２５）が存在する。クレジットサービス提供管理サーバは、クレジットサービス業務を行うクレジットサービス提供管理処理部（１２３）と、顧客やカード、顧客の与信情報などを持つデータベース（１２４）を有する。クレジットサービス加盟店端末は、クレジットカード会社と契約をした加盟店に設置され、ショッピングやキャッシングなどのクレジットサービスを利用可能な端末を有する。
銀行システムとクレジットシステム間、各システムの端末／サーバ間は、基本的に公衆網や専用線などによるネットワークを通して接続され、情報のやり取りはオンライン上で電文メッセージの送受信により実現されている。しかし、運用事業者のポリシーにより書面や情報記録媒体の郵送・手渡しにより情報のやり取りを実現することも可能である。
また、本発明の実施例の構成は、銀行システム（１０１）とクレジットシステム（１２１）の各処理部（１０４、１２３）に、口座管理や預貯金などの銀行業務処理機能や、クレジット決済、与信情報チェックなどのクレジットサービス処理機能を有している。これらの各処理機能は、コンピュータ・プログラムにしたがって動作させられるものである。
次に本発明の実施例の提案方式によるクレジット決済と代金支払を行う場合の大まかな手順を説明する。
クレジット決済処理は利用者（１１１）からの入金により処理は始まるが、その前処理として行うべき処理がある。それは符号２０２により示される処理であり、銀行システムとクレジットシステム間でお互いの暗号鍵を交換する処理である。これは後で説明するICカードに格納するトークン（TOKEN）に対する署名・暗号化処理のために用いる。交換する暗号鍵は、ベリサインなどの一般的な認証機関により認証された公開鍵証明書である場合もあるし、銀行とクレジットカード会社間の契約時に専用に生成した暗号鍵ペアの公開鍵である場合もある。
以上の前処理が正常に終了した場合、クレジット決済処理を行うことが可能となる。まず、利用者の入金処理に移る。クレジット決済を行った利用者（１１１）は、クレジット利用日から口座引落し期日までのいつでも好きな時に銀行サービス提供管理端末にアクセスし（２０３）、支払代金を銀行が設定したプール口座（２０１）に入金する（２０４）。これは現金を入金する場合もあるし、銀行の利用者本人口座（１０３）からの口座振替の場合もある（２１２）。銀行サービス提供管理処理部（１０４）は、入金対象のクレジットカード会社が契約済みであるかどうか、上記前処理により暗号鍵を交換しているかどうかを確認し、プール口座への入金を行った証明としてトークンを作成し発行する（２０５）。トークンに含まれる事項とは例えば、利用者氏名と入金額、入金日、銀行とクレジットカード会社それぞれの事業者ID、トークンIDや有効期間などである。またこのトークンには符号２０２で受領したクレジットシステムの公開鍵による暗号化を行う。これにより、クレジットシステム以外がデータを復号化し読み取ることが不可能になるため、トークンの秘匿性を保持することが可能となる。また、暗号化したトークンに対して、銀行システムの秘密鍵による署名を付与する。この秘密鍵は符号２０２でクレジットシステムに送付した公開鍵に対応する鍵であり、クレジットシステムがトークンを受け取った際に該署名を検証することで、トークンの正当性をクレジットシステムが確認することが可能となる。このように署名・暗号化処理されたトークンは利用者が保持するICカード（１１０）上に格納される。ICカード上には銀行サービスを行うAPが搭載されているため、ICカード上のAPと銀行システム間で相互認証が可能である。銀行システムは、当該利用者の銀行APが搭載されたICカードであることを確認した上でトークンを搭載する。そのため、異なる利用者のICカード上にトークンが搭載されず別人による不正利用を防ぐことが可能となる。またトークンはICカード上にセキュアに格納されるためコピーはできない仕組みとなっているが、もし無断コピーされた場合でも、トークン内にトークン作成日付やトークン有効期限、トークンをユニークに識別するIDなどのデータを含むことで、無断コピーによる二重使用の防止が可能となる。次の処理でクレジットシステムが使用可能とするため、トークンをICカード内で銀行APとクレジットAP間で共有する。もしくは、ICカード内の銀行APからクレジットAPへトークンを転送する。
クレジット利用時の処理に移る。利用者はショッピングやキャッシングを行う際、クレジット決済を指定する。加盟店端末で、クレジットサービス情報とトークンを読み取り（２０８）、クレジットサービス提供管理サーバに送信する（２０９）。クレジットサービス提供管理処理部（１２３）は受信したクレジットサービス情報を基に、クレジットシステムは与信情報をチェックする。これは現在行われている処理であり、与信情報とは、該クレジットカードあるいはクレジットAPが搭載されたICカードが紛失・盗難カードではないか、利用可能額は要求された代金に不足していないかなどの内容である。また次に、前処理（２０２）で受け取った銀行システムの公開鍵でトークンの署名を検証し正当性を確認する。確認できた場合、自身の秘密鍵でトークンを復号化する。この秘密鍵は上記前処理（２０２）で銀行システムに渡した自身の公開鍵に対応するものである。ICカード上にはクレジットサービスを行うAPが搭載されているため、ICカード上のAPとクレジットシステム間で相互認証が可能である。クレジットシステムは、当該利用者のクレジットAPが搭載されたICカードであることを確認した上でトークンを抽出する。そのため、異なる利用者のICカード上のトークンを渡されるなどの不正利用を防ぐことが可能となる。またトークンはICカード上にセキュアに格納されるためコピーはできない仕組みとなっているが、もし無断コピーされた場合でも、トークン内にトークン作成日付やトークン有効期限、トークンをユニークに識別するIDなどのデータを含むことで、無断コピーによる二重使用の防止が可能となる。クレジットサービス提供管理処理部（１２３）はトークンに含まれる利用者識別データや入金額などのデータを解析し、与信情報データベース（１２４）に仮反映させる。そして、利用者がクレジット決済要求している金額を仮反映した与信情報の利用可能額と比較し利用可否を判定し、加盟店端末に結果を提示する（２１０）。加盟店端末はこの結果をもとにクレジット決済処理を進めるか、あるいは処理を中止する（２１１）。以降は従来のクレジット決済処理を同様である。
次に口座引落し日における振込処理に移る。銀行システムは、クレジットシステムからの引落しデータを受領する。これはどの利用者からどの金額を引落すかを記載した明細である。銀行システムは該クレジットシステムで決済を行った全利用者の支払代金をプール口座よりそれぞれ引き出し、あらかじめ設定された期日にクレジットシステムへの代金振込処理（２１２）を行う。もし利用者が「ある時払い」ではなく従来通り本人口座に入金している場合はプール口座に該当代金は入金されていないので、利用者本人口座から引き出す。本人口座残高が引落し額に不足の場合は、引き出し不可の事実をクレジットシステムに伝える。これは従来の処理と同様である。プール口座あるいは利用者本人口座から引き出せた場合は、クレジットシステムに対して振込処理を行う。このクレジットシステムへの振込処理（２１２）は従来と同様の処理であり、全利用者分をまとめてバッチ処理で振り込むことが多い。
以上が本発明に係わるシステムの基本構成と処理であるが、ICカード内の処理については２つの方法が可能であり、それに対応してシステム側の処理にも変更点が生じてくる。図14と図１５を用いて詳細に説明する。図14はこれまでに説明した1番目の方式を示す図であり、銀行システムがトークンを格納する際はICカード上の銀行APと相互認証し格納した（１４１１）。その後銀行APが同一ICカード内のクレジットAPに転送あるいは共有した上で（１４１２）、クレジット利用の際は、クレジットシステムがICカード上のクレジットAPと相互認証し当該トークンを抽出する（１４１３）といった手順であった。しかし、銀行システムがトークンを格納する際に、ICカード上のクレジットAPと相互認証し、直接クレジットAPにトークンを格納することも可能である。図１５を用いて、2番目の方法を説明する。あらかじめ銀行システムとクレジットシステム間で暗号鍵交換処理を行うが、トークン用の鍵の他にICカード上のクレジットAPの公開鍵と、クレジットシステムに署名された銀行システムの公開鍵をクレジットシステムが銀行システムに渡しておく（１５０１）。銀行システムは、ICカード内の銀行APと通信するのではなく、符号１５０１でクレジットシステムから受け取ったICカード内クレジットAPの公開鍵を用いてクレジットAPと通信し、相互認証した上でトークンを格納する（１５０２）。この場合符号１５０３のクレジットシステムのよるトークン抽出処理に関してはクレジットシステムとICカード内クレジットAPとの通信であるため変更点は生じない。
またトークンと呼ぶデータに含まれてる項目の例を示したのが図１２である。利用者氏名、利用者ID、入金額、入金日、トークンID、トークン有効期限、銀行ID、銀行口座番号、クレジットカード会社ID、クレジットカード番号などを含むことで、トークンの二重使用防止や、利用者本人以外の使用防止を実現することが可能となる。
トークンの署名暗号化については図１３で説明する。図12に例示されたような内容のトークンを銀行システムはまず、クレジットシステムの公開鍵で暗号化する。これにより、クレジットシステムの秘密鍵以外では復号化は不可能であり、クレジットシステム以外への秘匿性が保持される。次に、銀行システムは自身の秘密鍵で署名を付与する。この秘密鍵に対応する公開鍵は予めクレジットシステムに渡しているため、当該トークンを銀行システムが作成したことをクレジットシステムが検証することが可能となる。
以上が、システム構成を含めた全体の流れとなる。次にシステムの各構成要素について説明を行う。
図3はICカード・システムの例の概要を示す図である。ICカード１１０の中にはチップ３０２があって、リーダライタ（もしくはリーダライタを有する端末）３０３とデータのやりとりを行う例を示している。リーダライタの中にはコントロール・プロセッサ３０４やデータベースとなる磁気ディスク３０５などが存在する。ICカード１１０には、通例通り、例えば、Vcc（供給電源）、GND（グランド）、RST（リセット）、I/O（入出力）、及びCLK（クロック）などの諸端子が示されている。また、図中、符号３０６はリーダライタ３０３からICカード１１０に対しての、例えばカードIDなどの各種問合せを示す。符号３０７はICカードが前述の問合せに対して行った返答を示す。こうした、諸情報の伝達は通例のシステムで十分である。
【０００６】
なお、ICカード内のICチップにおいて、具体的には前述のアプリケーションはメモリ領域に搭載される。一般に、メモリとしては、RAM（Random Access Memory）、EEPROM（Electrical Erasable Programmable Read Only Memory）あるいはROM（Read Only Memory）などが用いられる。
次に図4にこのようなICカード（１１０）内に搭載されているIC内部の基本的な領域の論理的な構成を示す。当該ICは、通例のマイクロ・コンピュータと同様に、ハードウェア層（４０３）とOSが搭載される領域、即ちOS層（４０２）とアプリケーションが搭載される領域、即ちアプリケーション層（４０１）とを有する。ここで、マルチアプリケーション搭載可能とは、アプリケーション層（４０１）に複数のアプリケーション（４０４−４０６）が搭載できるということである。また、アプリケーションの初期搭載とはこのアプリケーション（４０４−４０６）をICカード発行時に既に搭載された状態で利用申請者のもとに配布することであり、ダイナミックローディング可能とはこのアプリケーション（４０４−４０６）をカード発行後に、搭載あるいは削除が可能であることを示す。OS層（４０２）は通信処理部（４０７）、インタープリタ（４０８）、セキュリティ機構（４０９）などを有し、外部端末からのコマンド受信やアプリケーションのコマンド転送などを行っている。当然、アプリケーション層（４０１）とOS層（４０２）との間にはアプリケーション・インターフェイス、OS層（４０２）とハードウェア層（４０３）との間にはハードウェア・インターフェイスが設置されている。
次に本発明の実施例に係わる、クレジット決済処理の具体的方法を説明する。まず図5のシーケンスを用いて利用者による入金処理とクレジット利用、代金振込処理を説明する。まず、銀行（５０３）とクレジットカード会社（５０４）間でトークン用に暗号鍵を交換する（ステップ５１１）。クレジットサービスを利用した利用者（５０１）はその代金を期日までのいつでも好きな時に銀行に入金する（ステップ５１２）。銀行は入金したことの証明としてトークンを作成し利用者のICカード（５０２）に送信する（ステップ５１３）。次に、利用者がクレジットサービスを利用する際、ICカードからクレジットカード番号などのクレジットサービス情報とトークンを抽出し、クレジットカード会社に送信する（ステップ５１４）。クレジットカード会社は受信したクレジットサービス情報により、該カードが紛失・盗難カードかどうか、有効期限は過ぎてないかなどの与信情報を確認する。また受信したトークンの正当性を確認し、トークンに記載された入金額を利用可能限度額に仮反映する。仮反映した利用可能限度額を、クレジット利用を要求されている額の比較検討を行い、その結果を利用者に提示し（ステップ５０１）、以降は従来のクレジット利用処理を続行する。
以上で説明した本発明の実施例におけるクレジット決済方法の詳細について、銀行システムとクレジットシステムの各システムの動作フローチャート（図６〜図11）を用いて説明する。これらは図5のシーケンスを詳細化したものである。
図６〜図8は本発明の実施例における銀行システムの動作フローチャートである。
まず図6において銀行システムの鍵交換時処理について説明する。銀行システムはクレジットシステムと公開鍵を交換する（ステップ６０１）。前述したようにICカード内の処理に関連して、銀行システムがトークンをICカード内のクレジットAPに直接格納する場合は、通信を確立し相互認証するためのクレジットAP公開鍵とクレジットシステムに署名された銀行システムの公開鍵を、ステップ６０１でクレジットシステムから合わせて受け取っておく。
次に図7において銀行システムの利用者による入金時処理について説明する。利用者はクレジット決済の代金の入金を銀行システムに要求する（ステップ７０１）。銀行システムは要求されたクレジットシステムが契約をしており上記処理による暗号鍵の交換を行っているかどうかを確認する（ステップ７０２）。契約済でない場合は本発明に記載の方法によるクレジット利用代金の支払いはできない旨を利用者に提示し、処理を中止する（ステップ７０６）。契約済の場合ははトークン作成が可能であるため、利用者の入金額をプール口座に預金し、その金額、日付、有効期限などのデータをトークンとして作成する（ステップ７０３）。そして、トークンを該クレジットシステムから受領した公開鍵で暗号化し、暗号化したデータに対して自身の秘密鍵で署名をつける（ステップ７０４）。この秘密鍵は上記前処理でクレジットシステムに渡した自身の公開鍵に対応するものである。このように署名・暗号化されたトークンをICカード上に格納する（ステップ７０５）。ICカード上には銀行サービスを行うAPが搭載されているため、ICカード上のAPと銀行システム間で相互認証が可能である。銀行システムは、当該利用者の銀行APが搭載されたICカードであることを確認した上でトークンを搭載する。トークンは次の処理でクレジットシステムが使用可能とするため、ICカード内で銀行APとクレジットAP間で共有する。もしくは、ICカード内の銀行APからクレジットAPへトークンを転送する。また、クレジットシステムからICカード内クレジットAPの公開鍵を受け取っている場合は、ICカード内のクレジットAPと相互認証可能であり、その上でトークンを格納する。
次に図8において銀行システムの振込時処理について説明する。銀行システムは、あらかじめ設定された期日にクレジットシステムへの代金振込処理を行う。まずクレジットシステムからの引落しデータを受領する（ステップ８０１）。これはどの利用者からどの金額を引落すかを記載した明細である。銀行システムは該クレジットシステムで決済を行った全利用者の支払代金をプール口座よりそれぞれ引き出す（ステップ８０２）。利用者が「ある時払い」ではなく従来通り本人口座に入金している場合、プール口座に該当代金は入金されていないので、利用者本人口座から引き出す。本人口座残高が引落し額に不足の場合は、引き出し不可の事実をクレジットシステムに伝える（ステップ８０５）。これは従来の処理と同様である。プール口座あるいは利用者本人口座から引き出せた場合は、クレジットシステムに対して振込処理を行う（ステップ８０４）。これも従来の処理と同様であり、通常は全利用者の支払代金をまとめてクレジットシステムに対してバッチ処理を行う。
図9〜図11は本発明の実施例におけるクレジットシステムの動作フローチャートである。
まず図9においてクレジットシステムの鍵交換時処理について説明する。クレジットシステムは銀行システムと公開鍵を交換する（ステップ９０１）。前述したようにICカード内の処理に関連して、銀行システムがトークンをICカード内のクレジットAPに直接格納する場合は、通信を確立し相互認証するためのクレジットAP公開鍵とクレジットシステムが署名した銀行システムの公開鍵を、ステップ９０１で銀行システムに合わせて送付する必要がある。
次に図10においてクレジットシステムの利用者によるクレジット利用時処理について説明する。利用者はショッピングやキャッシングを行う際、クレジット決済を指定し加盟店端末では受信する（ステップ１００１）。加盟店端末で読み取ったクレジットサービス情報を基に、クレジットシステムは与信情報をチェックする（ステップ１００２）。これは従来行われている処理であり、与信情報とは、該クレジットカードあるいはクレジットAPが搭載されたICカードが紛失・盗難カードではないか、利用可能額は要求された代金に不足していないかなどの内容である。与信情報に問題がある場合は、利用不可を利用者に提示し処理を中止する（ステップ１００９）。与信情報に問題がない場合は、ICカード上のトークンを抽出し、前処理で受け取った銀行システムの公開鍵でトークンの署名を検証し正当性を確認する（ステップ１００３）。正当性を確認できない場合、あるいは、トークンがICカード内に存在しない場合はトークンに関連するステップを省略しステップ１００６へ続ける。ステップ１００３においてトークンの正当性を確認できた場合、自身の秘密鍵でトークンを復号化する（ステップ１００４）。この秘密鍵は上記前処理で銀行システムに渡した自身の公開鍵に対応するものである。次に復号化したトークンに含まれる利用者識別データや入金額などのデータを解析し、与信情報データベースに仮反映させる（ステップ１００５）。利用者がクレジット決済要求している金額を与信情報データベースの利用可能額と比較する（ステップ１００６）。比較結果により利用可否を判定し（ステップ１００７）、利用要求額が利用可能額より大きい場合は利用不可を利用者に提示し処理を中止する（ステップ１０１０）。利用要求額が利用可能額の範囲内である場合は利用者に利用可能であることを提示し、クレジットサービスの利用処理を進める（ステップ１００８）。以降は従来のクレジット決済処理を同様である。
次に図11においてクレジットシステムの振込時処理について説明する。クレジットシステムは、銀行システムに利用者と引落し額の対応を記載した明細を渡し（ステップ１１０１）、あらかじめ設定された期日に銀行システムからの代金振込を受ける（ステップ１１０２）。クレジットシステムは振り込まれた内容により与信情報データベースを反映する（ステップ１１０３）。その際、トークンにより仮反映されていた情報の確認を行うことが可能であるため、不正なトークンによる仮反映があった場合は本処理により判明する。
以上が本発明の実施の形態である。ICカードには接触型ICカード、非接触型ICカードなどがあるが、本発明の実施例ではこうしたICカードの構成自体によらず適用することが可能である。
【０００７】
以上説明したように、本発明の実施例によれば次のようなことが可能となる。
（１） 利用者がクレジットサービスを利用し、その代金支払い方式を口座引き落としにしている場合、利用者が期日までに銀行に入金した際、その入金した情報をICカード内にセキュアに格納し、クレジット利用時にクレジットシステムにアップロードすることで、クレジット利用の利用可能額にリアルタイムに反映することが可能となる。
（２） また、利用者がクレジット利用代金を、手元にあるときに「ある時払い」を、通常利用している銀行端末を通じて行うことが可能となる。また、その際入金した情報をICカード内にセキュアに格納することで、（１）と同様にクレジット利用の利用可能額にリアルタイムに反映することが可能となる。
【０００８】
【発明の効果】
利用者がクレジット利用代金を銀行口座に入金した際、入金した情報をデータ化しICカード内に格納することで、銀行サービス提供管理システムとクレジットサービス提供管理システムとの間の連携をとることが可能となる。
【０００９】
また、銀行サービス提供管理システム内に、利用者がクレジットカード会社に支払う代金をまとめて入金しておく共通の口座を設けることで、利用者が手元に代金あるときや都合の良いいつでも好きなタイミングで入金する「ある時払い」を行うことが可能となる。
【図面の簡単な説明】
【図１】従来のクレジット決済システム構成を示す図。
【図2】本発明の実施形態に係るトークンを利用したクレジット利用代金支払い方法を実施するクレジット決済システム構成を示す図。
【図3】カードシステムの概要を示す図。
【図4】ICカードの基本構成を示す図。
【図5】利用者の入金に応じてトークンをICカードに格納し、クレジット利用時の与信情報に反映するための本発明に係るシーケンスを示す図。
【図6】銀行システムが、クレジットシステムと公開鍵を交換するための本発明に係るシーケンスを示す図。
【図７】銀行システムが、利用者からの入金要求を受け付け、トークンを作成・発行するための本発明に係るシーケンスを示す図。
【図8】銀行システムが、期日にクレジット利用代金をクレジットシステムに振り込むための本発明に係るシーケンスを示す図。
【図９】クレジットシステムが、銀行システムと公開鍵を交換するための本発明に係るシーケンスを示す図。
【図１０】クレジットシステムが、利用者からのクレジット利用要求を受け付け、トークンを抽出・確認し、与信情報に反映させるための本発明に係るシーケンスを示す図。
【図１１】クレジットシステムが、期日に銀行からのクレジット利用代金振込みを受け付け、与信情報に反映し、トークン情報の正当性を確認するための本発明に係るシーケンスを示す図。
【図１２】銀行システムが、利用者が入金したことを示すためにICカード内に格納するトークンに含まれる項目例。
【図１３】トークンの署名と暗号方式例。
【図１４】本発明の他の実施例を説明するための図である。
【図１５】本発明の他の実施例を説明するための図である。
【符号の説明】
１０１： 銀行サービス提供管理システム
１０２： 銀行サービス提供管理サーバ
１０３： 利用者個人口座
１０４： 銀行サービス提供管理処理部
１０５： 銀行サービス提供管理端末
１１０： ICカード
１１１： 利用者
１２１： クレジットサービス提供管理システム
１２２： クレジットサービス提供管理サーバ
１２３： クレジットサービス提供管理処理部
１２４： 与信情報データベース
１２５： クレジットサービス加盟店端末
１３１： クレジット利用代金入金処理
１３２： クレジット利用代金口座入金処理
１３３： 利用者移動
１３４： クレジット利用要求処理
１３５： 与信情報確認処理
１３６： 与信情報結果提示処理
１３７： クレジット利用可否提示処理
１３８： クレジット利用代金振込み処理
２０１： プール口座
２０２： 公開鍵交換処理
２０３： クレジット利用代金入金処理
２０４： クレジット利用代金口座入金処理
２０５： トークン送信処理
２０６： トークン格納処理
２０７： 利用者移動
２０８： クレジット利用要求処理
２０９： クレジット利用可否確認処理
２１０： クレジット利用可否提示処理
２１１： クレジット利用可否提示処理
３０２： ICチップ
３０３： ICカード処理端末
３０４： ICカードシステム処理部
３０５： ICカードシステムデータベース
３０６： ICカードコマンド要求
３０７： ICカードコマンド応答
４０１： アプリケーション層
４０２： OS層
４０３： ハードウェア層
４０４、４０５、４０６： ICカードアプリケーション
４０７： 通信処理部
４０８： インタープリタ
４０９： セキュリティ機構
５０１： 利用者
５０２： ICカード
５０３： 銀行
５０４： クレジットカード会社
１４０１： ICカード内銀行サービスAP
１４０２： ICカード内クレジットサービスAP
１４１１： トークン格納処理
１４１２： ICカード内トークン転送処理
１４１３： トークン抽出処理
１５０１： ICカード内クレジットAP公開鍵送信処理
１５０２： トークン格納処理
１５０３： トークン抽出処理。
Claims (10)
- ICカードを利用した、クレジットサービスの決済システムにおいて、
前記クレジットサービスの提供管理システムと、クレジット利用代金が引き落とされる銀行サービスの提供管理システムが独立して設けられ、
銀行サービス提供管理システムは、代金の振込み及び口座管理を行う銀行サービス提供管理処理部と、利用者ごとの個人口座と、利用者がクレジット代金を引き落とし日まで入金しておく共通の口座と、各銀行支店に設置されているATM端末を有し、
前記銀行サービス提供管理処理部が、予め契約を締結したクレジットサービス提供管理システムと公開鍵を交換する手段と、
利用者からのクレジット利用代金の入金を、前記共通の口座に入金し、入金したことを示すデータに署名暗号化処理を行った上で、利用者の所有するICカードに格納する手段と、
引き落とし日に、前記共通の口座あるいは利用者の個人口座からクレジット利用代金を引き出し、クレジットサービス提供管理システムへ振込む手段を有し、
クレジットサービス提供管理システムは、クレジット利用時の与信確認やクレジット利用者情報を管理するクレジットサービス提供管理処理部と、利用者ごとの与信情報を格納する与信情報データベースと、各加盟店でクレジット決済を行う暮れ時とサービス加盟店端末を有し、
前記クレジットサービス提供管理処理部が、予め契約を締結した銀行サービス提供管理システムと公開鍵を交換する手段と、
利用者がクレジット利用を要求した際に、利用者の与信情報を確認する手段と、銀行サービスシステムがICカードに格納した、入金したことを示すデータを抽出し正当性を確認し、与信情報データベースに仮反映させる手段と、
引き落とし日に、銀行サービス提供管理システムからの振込みを受け付け、与信情報データベースに仮反映されている情報を確認する手段を有することを特徴とするクレジットサービスの決済システム。 - 前記クレジットサービスの決済システムにおいて、
予め銀行サービス提供管理システムとクレジットサービス提供管理システム間で、お互いの公開鍵証明書を交換し、
銀行サービス提供管理システムが前記入金したことを示すデータを、クレジットサービス提供管理システムの公開鍵で暗号化処理を行い、自身の公開鍵で署名付与処理を行う手段を有し、
ICカードへ当該データを格納する際に、ICカード内の自身の所有する銀行サービスアプリケーションと通信を行い格納する手段を有し、
ICカードが、前記銀行サービスアプリケーションが受信したデータを、同じくICカード内に存在するクレジットサービスアプリケーションに転送あるいは、共有化する手段を有し、
クレジットサービス提供管理システムが、前記入金したことを示すデータを抽出する際は、ICカード内のクレジットサービスアプリケーションと通信を行い抽出する手段を有することを特徴とする、
請求項１記載のクレジットサービスの決済システム。 - 前記クレジットサービスの決済システムにおいて、
予め銀行サービス提供管理システムとクレジットサービス提供管理システム間で、お互いの公開鍵証明書を交換し、
予めクレジットサービス提供管理システムは銀行サービス提供管理システムにICカード内のクレジットサービスアプリケーションの公開鍵を渡しておき、
銀行サービス提供管理システムが前記入金したことを示すデータを、クレジットサービス提供管理システムの公開鍵で暗号化処理を行い、自身の公開鍵で署名付与処理を行う手段を有し、
ICカードへ当該データを格納する際に、前記クレジットサービス提供管理システムから受け取ったICカード内クレジットサービスアプリケーションの公開鍵を用いて、ICカード内のクレジットサービスアプリケーションと通信を行い格納する手段を有し、
クレジットサービス提供管理システムが、前記入金したことを示すデータを抽出する際は、ICカード内のクレジットサービスアプリケーションと通信を行い抽出する手段を有することを特徴とする、
請求項１記載のクレジットサービスの決済システム。 - ICカードを利用した、銀行サービスの提供管理システムにおいて、
銀行サービス提供管理システムは、代金の振込み及び口座管理を行う銀行サービス提供管理処理部と、利用者ごとの個人口座と、利用者がクレジット代金を引き落とし日まで入金しておく共通の口座と、各銀行支店に設置されているATM端末を有し、
前記銀行サービス提供管理処理部が、予め契約を締結したクレジットサービス提供管理システムと公開鍵を交換する手段と、
利用者からのクレジット利用代金の入金を、前記共通の口座に入金し、入金したことを示すデータに署名暗号化処理を行った上で、利用者の所有するICカードに格納する手段と、
引き落とし日に、前記共通の口座あるいは利用者の個人口座からクレジット利用代金を引き出し、クレジットサービス提供管理システムへ振込む手段を有することを特徴とする、
銀行サービス提供管理システム。 - 前記銀行サービス提供管理システムにおいて、
予めクレジットサービス提供管理システムとの間で、お互いの公開鍵証明書を交換し、
前記入金したことを示すデータを、クレジットサービス提供管理システムの公開鍵で暗号化処理を行い、自身の公開鍵で署名付与処理を行う手段を有し、
ICカードへ当該データを格納する際に、ICカード内の自身の所有する銀行サービスアプリケーションと通信を行い格納する手段を有することを特徴とする、
請求項４記載の銀行サービス提供管理システム。 - 前記銀行サービス提供管理システムにおいて、
予めクレジットサービス提供管理システム間で、お互いの公開鍵証明書を交換し、
予めクレジットサービス提供管理システムからICカード内のクレジットサービスアプリケーションの公開鍵を受け取り、
前記入金したことを示すデータを、クレジットサービス提供管理システムの公開鍵で暗号化処理を行い、自身の公開鍵で署名付与処理を行う手段を有し、
ICカードへ当該データを格納する際に、前記クレジットサービス提供管理システムから受け取ったICカード内クレジットサービスアプリケーションの公開鍵を用いて、ICカード内のクレジットサービスアプリケーションと通信を行い格納する手段を有し、
請求項４記載の銀行サービス提供管理システム。 - ICカードを利用した、クレジットサービス提供管理システムにおいて、
クレジットサービス提供管理システムは、クレジット利用時の与信確認やクレジット利用者情報を管理するクレジットサービス提供管理処理部と、利用者ごとの与信情報を格納する与信情報データベースと、各加盟店でクレジット決済を行う暮れ時とサービス加盟店端末を有し、
予め契約を締結した銀行サービス提供管理システムと公開鍵を交換する手段と、利用者がクレジット利用を要求した際に、利用者の与信情報を確認する手段と、銀行サービスシステムがICカードに格納した、入金したことを示すデータを抽出し正当性を確認し、与信情報データベースに仮反映させる手段と、
引き落とし日に、銀行サービス提供管理システムからの振込みを受け付け、与信情報データベースに仮反映されている情報を確認する手段を有することを特徴とするクレジットサービス提供管理システム。 - 前記クレジットサービス提供管理システムにおいて、
予め銀行サービス提供管理システムとの間で、お互いの公開鍵証明書を交換し、前記入金したことを示すデータを抽出する際は、ICカード内のクレジットサービスアプリケーションと通信を行い抽出する手段を有することを特徴とする、
請求項７記載のクレジットサービス提供管理システム。 - 前記クレジットサービス提供管理システムにおいて、
予め銀行サービス提供管理システムとの間で、お互いの公開鍵証明書を交換し、予め銀行サービス提供管理システムにICカード内のクレジットサービスアプリケーションの公開鍵を渡しておき、
前記入金したことを示すデータを抽出する際は、ICカード内のクレジットサービスアプリケーションと通信を行い抽出する手段を有することを特徴とする、
請求項７記載のクレジットサービスの決済システム。 - 請求項１から９の何れか１つに記載のシステムにおいて、
入金したことを示すデータに、利用者氏名、利用者ID、入金額、入金日、データ有効期限、銀行ID、銀行口座番号、クレジットカード会社ID、クレジットカード番号を含むことを特徴とするシステム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002369174A JP2004199534A (ja) | 2002-12-20 | 2002-12-20 | Ｉｃカードを利用した決済システム |
| US10/735,872 US20040128247A1 (en) | 2002-12-20 | 2003-12-16 | Bank system program, credit service program and IC card |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002369174A JP2004199534A (ja) | 2002-12-20 | 2002-12-20 | Ｉｃカードを利用した決済システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004199534A true JP2004199534A (ja) | 2004-07-15 |
| JP2004199534A5 JP2004199534A5 (ja) | 2005-10-27 |
Family
ID=32652640
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002369174A Pending JP2004199534A (ja) | 2002-12-20 | 2002-12-20 | Ｉｃカードを利用した決済システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20040128247A1 (ja) |
| JP (1) | JP2004199534A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009223685A (ja) * | 2008-03-17 | 2009-10-01 | Felica Networks Inc | 認証システム、認証方法、リーダ／ライタおよびプログラム |
| WO2011125774A1 (ja) * | 2010-03-31 | 2011-10-13 | 楽天株式会社 | クレジットカード利用管理システム、クレジットカード利用管理方法、プログラム及び情報記録媒体 |
| JP2018038068A (ja) * | 2012-02-27 | 2018-03-08 | モルフォ | 通信端末および関連システムのユーザーの識別情報を確認するための方法 |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7302582B2 (en) * | 2000-08-21 | 2007-11-27 | United States Postal Service | Delivery point validation system |
| US7664731B2 (en) | 2002-03-21 | 2010-02-16 | United States Postal Service | Method and system for storing and retrieving data using hash-accessed multiple data stores |
| AU2003213722A1 (en) * | 2002-03-21 | 2003-10-08 | David J. Payne | Method and system for storing and retrieving data using hash-accessed multiple data stores |
| US7159119B2 (en) * | 2002-09-06 | 2007-01-02 | United States Postal Service | Method and system for efficiently retrieving secured data by securely pre-processing provided access information |
| US20060031158A1 (en) * | 2004-08-09 | 2006-02-09 | Suze Orman | Credit card with incentives tied to credit score |
| US8117453B2 (en) * | 2005-11-23 | 2012-02-14 | Proton World International N.V. | Customization of an electronic circuit |
| US8769275B2 (en) * | 2006-10-17 | 2014-07-01 | Verifone, Inc. | Batch settlement transactions system and method |
| US9361617B2 (en) * | 2008-06-17 | 2016-06-07 | Verifone, Inc. | Variable-length cipher system and method |
| US8769279B2 (en) * | 2006-10-17 | 2014-07-01 | Verifone, Inc. | System and method for variable length encryption |
| US8024238B2 (en) * | 2008-04-24 | 2011-09-20 | Visa U.S.A. Inc. | Negative balance management |
| US9053480B1 (en) | 2008-09-30 | 2015-06-09 | Amazon Technologies, Inc. | Secure validation using hardware security modules |
| US8892868B1 (en) | 2008-09-30 | 2014-11-18 | Amazon Technologies, Inc. | Hardening tokenization security and key rotation |
| DE102009027682A1 (de) * | 2009-07-14 | 2011-01-20 | Bundesdruckerei Gmbh | Verfahren zur Erzeugung eines Soft-Tokens |
| MY177161A (en) | 2011-04-28 | 2020-09-08 | Rakuten Inc | Payment module, payment method, program, and information recording medium |
| CN103493078B (zh) * | 2011-04-28 | 2016-12-07 | 乐天株式会社 | 结账模块、结账方法、结账装置及结账装置的控制方法 |
| DE102011084728B4 (de) * | 2011-10-18 | 2015-04-02 | Bundesdruckerei Gmbh | Verfahren zum Starten einer externen Applikation und bidirektionaler Kommunikation zwischen einem Browser und einer externen Applikation ohne Browsererweiterungen |
| CN103150672A (zh) * | 2013-04-09 | 2013-06-12 | 长沙钢为网络科技有限公司 | 一种银行快速授信系统及方法 |
| CN104917738B (zh) * | 2014-03-14 | 2018-03-16 | 陈衡 | 金融平台数据处理方法和系统 |
| CN106055200A (zh) * | 2016-05-27 | 2016-10-26 | 上海优走信息科技有限公司 | 电子设备及其应用的认证进度显示方法、及系统 |
| CN111949694B (zh) * | 2020-08-14 | 2024-03-26 | 中国工商银行股份有限公司 | 账户存续期动态监测方法及装置 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH03223958A (ja) * | 1990-01-29 | 1991-10-02 | Hitachi Ltd | 取引照会方法 |
| US5557516A (en) * | 1994-02-04 | 1996-09-17 | Mastercard International | System and method for conducting cashless transactions |
| JPH09259193A (ja) * | 1996-03-19 | 1997-10-03 | Fujitsu Ltd | 電子マネーシステムの取引方法 |
| US6304860B1 (en) * | 1997-10-03 | 2001-10-16 | Joseph B. Martin, Jr. | Automated debt payment system and method using ATM network |
| US20020065772A1 (en) * | 1998-06-08 | 2002-05-30 | Saliba Bassam A. | System, method and program for network user access |
| US6345281B1 (en) * | 1999-03-01 | 2002-02-05 | Electronic Data Systems Corporation | Recovery method and system for a resource management system |
| CA2347528A1 (en) * | 2001-05-15 | 2002-11-15 | Ibm Canada Limited-Ibm Canada Limitee | System and method for on-line payment |
| US7546274B2 (en) * | 2001-08-09 | 2009-06-09 | Ncr Corporation | System and method for facilitating electronic commerce transactions at an automatic teller machine |
| KR20030090435A (ko) * | 2002-05-23 | 2003-11-28 | 에스케이 텔레콤주식회사 | 금융 거래 시스템 및 방법 |
| US20040128546A1 (en) * | 2002-12-31 | 2004-07-01 | International Business Machines Corporation | Method and system for attribute exchange in a heterogeneous federated environment |
-
2002
- 2002-12-20 JP JP2002369174A patent/JP2004199534A/ja active Pending
-
2003
- 2003-12-16 US US10/735,872 patent/US20040128247A1/en not_active Abandoned
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009223685A (ja) * | 2008-03-17 | 2009-10-01 | Felica Networks Inc | 認証システム、認証方法、リーダ／ライタおよびプログラム |
| WO2011125774A1 (ja) * | 2010-03-31 | 2011-10-13 | 楽天株式会社 | クレジットカード利用管理システム、クレジットカード利用管理方法、プログラム及び情報記録媒体 |
| WO2011125765A1 (ja) * | 2010-03-31 | 2011-10-13 | 楽天株式会社 | クレジットカード利用管理システム、クレジットカード利用管理方法、プログラム及び情報記録媒体 |
| US8676701B2 (en) | 2010-03-31 | 2014-03-18 | Rakuten, Inc. | Credit card usage management system, credit card usage management method, program, and information storage medium |
| JP2018038068A (ja) * | 2012-02-27 | 2018-03-08 | モルフォ | 通信端末および関連システムのユーザーの識別情報を確認するための方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040128247A1 (en) | 2004-07-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004199534A (ja) | Ｉｃカードを利用した決済システム | |
| US7680736B2 (en) | Payment system | |
| US6098053A (en) | System and method for performing an electronic financial transaction | |
| US5949044A (en) | Method and apparatus for funds and credit line transfers | |
| KR101531476B1 (ko) | 통행 요금 징수에 사용된 은행 발행의 비접촉 지불 카드 | |
| US7299980B2 (en) | Computer readable universal authorization card system and method for using same | |
| JP3027128B2 (ja) | 電子マネーシステム | |
| US20030154376A1 (en) | Optical storage medium for storing, a public key infrastructure (pki)-based private key and certificate, a method and system for issuing the same and a method for using | |
| US20030070080A1 (en) | Electronic-monetary system | |
| KR100411448B1 (ko) | 공개키 기반구조의 개인키와 인증서를 저장하는 광학기록매체의 발급방법 및 발급시스템 | |
| WO2000062259A1 (en) | Person-to-person, person-to-business, business-to-person, and business-to-business financial transaction system | |
| US7308429B1 (en) | Electronic withdrawal authorization store and forward for cash and credit accounts | |
| WO2000002150A1 (en) | Transaction authorisation method | |
| US20040034597A1 (en) | System and method for managing micropayment transactions, corresponding client terminal and trader equipment | |
| JP2003504759A (ja) | トランザクションを実行するためのシステム | |
| JP2000200320A (ja) | 電子マネ― | |
| JP2003507824A (ja) | 電子商取引を行うための保証システムおよびそれに用いる方法 | |
| KR100857739B1 (ko) | 온라인 계좌 예치 금액 출금 방법 및 시스템과 이를 위한기록매체 | |
| KR101004078B1 (ko) | 온라인 계좌 연계 카드 충전금액 환불 방법 | |
| Pilioura | Electronic payment systems on open computer networks: a survey | |
| Pardhi et al. | Electronic Cash Payment System | |
| JP2000040116A (ja) | 電子マネーのゲートウェイ装置、及び電子マネー転送方法 | |
| JP2002279192A (ja) | 口座の引き落とし予約通知システム | |
| Hansmann et al. | Smart Cards and e-business | |
| KR100982293B1 (ko) | 온라인 계좌를 이용한 거스름돈 충전 방법 및 시스템과이를 위한 기록매체 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050722 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050722 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060420 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080617 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080807 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080902 |