JP4942245B2 - クレジットカードを用いた決済処理方法 - Google Patents
クレジットカードを用いた決済処理方法 Download PDFInfo
- Publication number
- JP4942245B2 JP4942245B2 JP2000352759A JP2000352759A JP4942245B2 JP 4942245 B2 JP4942245 B2 JP 4942245B2 JP 2000352759 A JP2000352759 A JP 2000352759A JP 2000352759 A JP2000352759 A JP 2000352759A JP 4942245 B2 JP4942245 B2 JP 4942245B2
- Authority
- JP
- Japan
- Prior art keywords
- user
- credit card
- payment
- information processing
- identification code
- 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.)
- Expired - Fee Related
Links
- 238000003672 processing method Methods 0.000 title claims description 50
- 230000010365 information processing Effects 0.000 claims description 187
- 238000000034 method Methods 0.000 claims description 78
- 238000004364 calculation method Methods 0.000 claims description 57
- 230000006870 function Effects 0.000 claims description 45
- 238000012545 processing Methods 0.000 claims description 39
- 230000008569 process Effects 0.000 claims description 30
- 238000004422 calculation algorithm Methods 0.000 claims description 19
- 230000005540 biological transmission Effects 0.000 claims description 14
- 230000002427 irreversible effect Effects 0.000 claims description 8
- 230000008859 change Effects 0.000 claims description 4
- 230000004044 response Effects 0.000 claims description 2
- 238000010586 diagram Methods 0.000 description 9
- 238000002360 preparation method Methods 0.000 description 7
- 230000000694 effects Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 235000008331 Pinus X rigitaeda Nutrition 0.000 description 2
- 235000011613 Pinus brutia Nutrition 0.000 description 2
- 241000018646 Pinus brutia Species 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 241000167854 Bourreria succulenta Species 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 235000019693 cherries Nutrition 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000004049 embossing Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 239000002360 explosive Substances 0.000 description 1
- 210000001061 forehead Anatomy 0.000 description 1
- 238000012905 input function Methods 0.000 description 1
- 235000012054 meals Nutrition 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000012216 screening Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Landscapes
- Credit Cards Or The Like (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
【発明の属する技術分野】
本発明は、クレジットカードを用いた決済処理方法に関し、特に、インターネット上の仮想ショッピングモールでの買い物の決済を行うのに適したクレジットカードを用いた決済処理方法に関する。
【0002】
【従来の技術】
近年のクレジットカードの普及はめざましく、最近では、1人のユーザが複数のクレジットカードを所持することも一般化しつつある。クレジットカードを利用すれば、現金を取り扱う必要がないため、ユーザと加盟店との双方に大きなメリットが得られ、クレジットカードの利用は、今後も益々普及してゆくものと予想される。クレジットカードを用いた決済処理は、古くは加盟店でクレジット決済用の伝票を作成し、この伝票をクレジットカード会社へ送る方法が採られていたが、最近は、各加盟店に設置された端末装置とクレジットカード会社の管理するホストコンピュータとをオンライン接続し、オンラインで情報のやりとりを行う方法が主流となってきている。
【0003】
ここ数年来のインターネットの爆発的な普及により、インターネット上の仮想ショッピングモールでの買い物の決済にも、クレジットカードを用いるのが一般的になってきている。この場合、ユーザはパソコンや携帯型端末装置から個々の加盟店の仮想ショッピングモールのWebページにアクセスし、Webブラウザの画面上で所望の商品を選択した上で、当該商品の代金をクレジットカードで決済することになる。クレジットカードによる決済を行う際には、ユーザの氏名、クレジットカード番号、有効期限といった情報を加盟店側に伝える必要があるので、通常は、Webブラウザの画面上でこれらの各情報を入力し、インターネットを介して、加盟店のWebページを運営しているサイトのサーバ装置に送信する処理が行われる。加盟店は、ユーザから送信されてきたこれらの情報に、決済対象となる金額の情報を加えて、クレジットカード会社側のホストコンピュータに決済要求を出すことになる。クレジットカード会社側では、加盟店からの決済要求を受けたら、加盟店側から送信されてきたユーザの氏名、クレジットカード番号、有効期限を、ホストコンピュータ内の登録データと照合し、問題がなければ決済要求を承認する。
【0004】
このように、クレジットカード会社では、基本的には、ユーザの氏名、クレジットカード番号、有効期限を照合して決済を行うので、これらの情報が犯罪者に盗まれると、悪用されるおそれがある。特に、インターネットの黎明期においては、ユーザがWebブラウザから送信したこれらの情報が、途中で不正に盗まれる事件が多発し、大きな社会問題となっていた。このような問題に対処するため、インターネット経由の情報送信のセキュリティを高める技術が開発されてきている。たとえば、現在では、SSL(Secure Sockets Layer)と呼ばれるTCP/IP通信のセキュリティを確保するためのプロトコルが一般的に利用されており、このプロトコルにより送信した情報に対しては、実用上、十分なセキュリティを確保することが可能である。
【0005】
【発明が解決しようとする課題】
このように、クレジットカードのユーザ氏名、番号、有効期限といった情報は、犯罪者の手に渡ると悪用されるおそれがある重要な情報であり、取り扱いには十分に注意する必要がある。もっとも、インターネット上の仮想ショッピングモールでの買い物の決済を、クレジットカードを用いて行う場合でも、上述のSSLなどの技術を利用してこれらの情報を送信すれば、一応、送信経路上で情報が盗まれるような被害は未然に防ぐことができる。しかしながら、これまでのクレジットカードに対するセキュリティ対策は、加盟店自身が不正な行為をすることはない、ということを大前提としたものであり、加盟店自身が不正行為を働いた場合には、全く機能しないという問題を含んでいる。そもそも加盟店は、クレジットカード会社による厳密な審査により、十分に信頼がおける企業であるとの判断がなされた店であり、これまでは加盟店自身が不正行為をなすという事態は全く想定されていない。しかし、インターネット上のビジネスなどが普及すればするほど、クレジットカードの加盟店も多種多様となり、加盟店自身による不正行為、あるいはその従業者による不正行為が行われる可能性も高まってきている。加盟店のもとには、多数のユーザに関する氏名、クレジットカード番号、有効期限といった情報が集まるので、万一、これらの情報を不正に取得して横流しをするような従業者がいた場合には、SSLなどの技術により通信セキュリティを確保しても無力である。
【0006】
このような問題点を解決するために、公開鍵暗号技術を利用したSET(Secure Electronic Transaction )なる決済方法が大手クレジットカード会社から提案され、現在、システムの実験が行われているが、かなり大掛かりなシステムが必要になるため、実用化には至っていない。
【0007】
そこで本発明は、各加盟店に対するセキュリティを十分に確保することが可能なクレジットカードを用いた新規な決済処理方法を提供することを目的とする。
【0008】
【課題を解決するための手段】
(1) 本発明の第1の態様は、クレジットカード会社から、所定のクレジットカード番号が付与されたクレジットカードの発行を受けたユーザが、当該クレジットカードの加盟店に対して当該クレジットカードを用いて決済を行う際の決済処理方法において、
ユーザが利用するユーザ用情報処理装置と、決済相手となる加盟店が管理する加盟店用情報処理装置と、を接続し、ユーザが加盟店に対して特定の決済事項に関する処理を1処理手続として行う際に、
加盟店用情報処理装置が、特定の決済事項に関する1処理手続に対応したコードであって、「すべての加盟店における加盟店用情報処理装置で発生させるすべてのセッション識別コードが、互いに異なるユニークなコードになる」という条件をもったセッション識別コードを発生させ、このセッション識別コードをユーザ用情報処理装置に送信する第1の段階と、
ユーザ用情報処理装置が、第1の段階によって送信されてきたセッション識別コードと予め格納されていたクレジットカード番号との少なくとも2つの情報に基づいてユーザ側演算対象データを作成し、このユーザ側演算対象データに対して、HASH関数もしくはその他の非可逆的な関数を作用させる演算処理を行うことにより一義的に決定される決済識別コードを発生させ、少なくとも、この決済識別コードと予め格納されていたユーザの氏名とを、第1の段階の送信に対する返信として、加盟店用情報処理装置に送信する第2の段階と、
クレジットカードによる決済を承認する権限をもった承認業者が管理する承認業者用情報処理装置と、加盟店用情報処理装置と、を接続し、加盟店が承認業者に対して特定の決済事項に関する処理を1処理手続として行う際に、
加盟店用情報処理装置が、少なくとも、上記特定の決済事項に関して決定した決済金額と、第1の段階で発生させたセッション識別コードと、このセッション識別コードの送信に対する返信として第2の段階で送信されてきた決済識別コードおよび氏名とを、承認業者用情報処理装置へ送信することにより当該決済金額についての決済要求を出す第3の段階と、
承認業者用情報処理装置が、予めデータベースとして用意されているクレジットカードの会員名簿の中から、第3の段階によって送信されてきた氏名と同姓同名のユーザに関するクレジットカード番号を検索し、第3の段階によって送信されてきたセッション識別コードと、検索されたn個(nは自然数)のクレジットカード番号のそれぞれと、の少なくとも2つの情報に基づいて、ユーザ側演算対象データと同一構成の承認業者側演算対象データをn通り作成し、このn通りの承認業者側演算対象データに対して、第2の段階で行った演算処理と同一の演算処理を行うことによりn通りの決済識別コードを求め、このn通りの決済識別コードの中に、第3の段階によって送信されてきた決済識別コードに一致するコードが存在した場合に、当該一致をもたらしたクレジットカード番号に対応する会員を決済主体となる特定のユーザと認識し、当該一致が得られることを第1の条件とし、第3の段階で送信されてきた決済識別コードが、上記特定のユーザに関して過去に行われた決済処理で用いられた決済識別コードとは異なることを第2の条件とし、これら2条件がともに満たされた場合に、当該特定のユーザに関して決済要求に対する承認を行う第4の段階と、
を有し、第2の段階において、ユーザ用情報処理装置から加盟店用情報処理装置に対して、クレジットカード番号自体の送信は行わないようにしたものである。
【0012】
(2) 本発明の第2の態様は、上述の第1の態様に係るクレジットカードを用いた決済処理方法において、
セッション識別コードを発生させる際に、決済日、決済時、セッション番号もしくはこれらの組合せを利用するようにしたものである。
【0013】
(3) 本発明の第3の態様は、上述の第1または第2の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ側演算対象データおよび承認業者側演算対象データとして、時期に応じて内容が変化するマジックコードを含ませるようにしたものである。
【0014】
(4) 本発明の第4の態様は、上述の第1〜第3の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ側演算対象データおよび承認業者側演算対象データとして、決済日、決済時、もしくは決済日時を示すコードを含ませるようにしたものである。
【0015】
(5) 本発明の第5の態様は、上述の第1〜第4の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ側演算対象データおよび承認業者側演算対象データとして、クレジットカードの有効期限を示すコードを含ませるようにしたものである。
【0018】
(6) 本発明の第6の態様は、上述の第1〜第5の態様に係るクレジットカードを用いた決済処理方法において、
ユーザが複数のクレジットカード会社からそれぞれクレジットカードの発行を受けているときに、ユーザ用情報処理装置内に、個々のクレジットカードについての各クレジットカード番号をそれぞれ格納しておき、
決済を行うときに、ユーザに特定のクレジットカードを指定する入力を行わせ、指定されたクレジットカードに対応するクレジットカード番号を用いて、ユーザ側演算対象データを作成するようにしたものである。
【0019】
(7) 本発明の第7の態様は、上述の第1〜第6の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置、加盟店用情報処理装置、承認業者用情報処理装置を、それぞれネットワークを介して接続し、加盟店のWebページ上に開かれた仮想ショッピングモールでユーザが買い物をした際に、ネットワークを介して必要な情報伝送を行うことにより決済が行われるようにしたものである。
【0021】
(8) 本発明の第8の態様は、上述の第1〜第7の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置を、ICカードと、このICカードに対する情報伝送を行うリーダライタ装置と、このリーダライタ装置を介してICカードへのアクセスを行うコンピュータと、によって構成し、少なくとも決済処理を行う際に、ICカードをリーダライタ装置に装着し、コンピュータによってアクセスを行うことにより、ユーザ用情報処理装置としての機能を実現させるようにしたものである。
【0022】
(9) 本発明の第9の態様は、上述の第8の態様に係るクレジットカードを用いた決済処理方法において、
少なくとも、決済識別コードを発生させるためのアルゴリズムをICカード内のメモリに格納し、決済識別コードの発生処理を、ICカード内において実行するようにしたものである。
【0024】
【発明の実施の形態】
以下、本発明を図示する実施形態に基づいて説明する。
【0025】
§1.インターネット上での従来の一般的な決済処理方法
はじめに、インターネット上の仮想ショッピングモールで買い物をする場合の従来の一般的なクレジットカードによる決済処理方法の手順を説明する。図1は、この手順を示すブロック図である。この例では、ユーザ用情報処理装置100、加盟店用情報処理装置200、承認業者用情報処理装置300がインターネット400を介して接続される。ユーザ用情報処理装置100は、ユーザの管理下にある情報処理装置であり、一般的には、インターネット400に接続する機能を有するパソコンや携帯型情報端末装置がユーザ用情報処理装置100として利用されている。加盟店用情報処理装置200は、クレジットカードの加盟店によって管理されている情報処理装置であり、一般的には、仮想ショッピングモールのWebページのサイトを提供するWebサーバ装置が加盟店用情報処理装置200として利用されることになる。承認業者用情報処理装置300は、クレジットカードによる決済を承認する権限をもった承認業者(クレジットカード会社自身もしくはその委託を受けた特定の業者)によって管理される情報処理装置であり、通常は、比較的大規模なホストコンピュータによって構成される。
【0026】
ユーザは、クレジットカード会社からクレジットカード10の発行を受けており、このクレジットカード10には、ユーザの氏名N、クレジットカード番号C、有効期限Dなる情報が記載されている(通常、エンボス加工によって刻まれている)。もちろん、クレジットカードによっては、この他にも種々の情報が記載されている場合がある。一方、このクレジットカード10上に記載された情報は、承認業者用情報処理装置300内のデータベースにも登録されている。このデータベースには、更に、各ユーザの住所、電話番号、勤務先、過去の決済履歴などのデータも格納されている。
【0027】
加盟店が運営する仮想ショッピングモールを利用するには、ユーザは、ユーザ用情報処理装置100のWebブラウザ機能を用いて、加盟店用情報処理装置200内のサイトの所定のWebページにアクセスすればよい。いま、ユーザが、このWebページ上で所望の商品を購入し、クレジットカード10を利用してその代金を決済する場合を考えよう。この場合、ユーザは手元にクレジットカード10を用意し、Web画面上で、氏名N、クレジットカード番号C、有効期限Dなる情報をキーボードなどを用いて入力する。入力したこれらの情報は、インターネット400を介して、加盟店用情報処理装置200へと送信される。通常、この送信処理は、SSLなどのセキュリティが確保されたプロトコルにより行われるため、インターネット400の伝送経路上でこれらの情報が盗まれる可能性は非常に小さい。こうして、加盟店用情報処理装置200に、ユーザが送信したこれらの情報が到達すると、今度は、加盟店が、自己の店名や決済金額Pなどの情報を付加して、これらの情報をインターネット400を介して(場合によっては、別な通信線を介して)、承認業者用情報処理装置300へと送信して承認を求める。承認業者は、承認業者用情報処理装置300内のデータベースに登録されている情報と、加盟店から送信されてきた情報とを照合し、問題がなければ当該決済を承認することになる。
【0028】
結局、クレジットカード10上の氏名N,クレジットカード番号C,有効期限Dという情報は、ユーザ用情報処理装置100から加盟店用情報処理装置200へと送信され、更に、加盟店用情報処理装置200から承認業者用情報処理装置300へと送信されることになる。このような送信経路におけるセキュリティは、前述したように、SSLなどの技術によって実用上十分なレベルまで確保されている。しかしながら、このようなセキュリティ対策は、加盟店自身が不正な行為をすることはない、ということを大前提としたものである。加盟店用情報処理装置200内には、多数のユーザのクレジットカードに関する情報が蓄積されており、万一、これらの蓄積情報を不正に取得して横流しをするような従業者が加盟店内にいた場合、クレジットカード情報に対するセキュリティ対策は根底から覆されてしまう。本発明は、このような問題を解決するための新たな決済処理方法を提案するものである。
【0029】
§2.本発明に係る決済処理方法の基本概念
続いて、図2のブロック図を参照しながら、本発明に係るクレジットカードを用いた決済処理方法の基本概念を説明する。この図2に示す例は、図1に示す例と同様に、ユーザ、加盟店、承認業者の三者間での決済処理の手順を示しているが、ここでは、多数のユーザのうちの第n番目のユーザという意味で、特定のユーザUnが決済処理を行う場合の処理手順を示すことにする。図に示す各符号のサフィックス「n」は、この第n番目のユーザについての情報であることを示すものである。また、ここでは、多数の加盟店のうちの第m番目の加盟店という意味で、特定の加盟店Smに対する決済処理手順を示すことにする。図に示す各符号のサフィックス「m」は、この第m番目の加盟店についての情報であることを示すものである。結局、以下に説明する決済処理は、ユーザUnが加盟店Smに対して、特定の決済事項に関する処理を1処理手続(以下、1セッションと呼ぶ)として行う場合の処理を示していることになる。なお、ここでは、第m番目の加盟店が個々のユーザとの間で行う特定の決済事項に関する1処理手続(すなわち、セッション)に、一連のシリアル番号iを付して示すことにする(以下、これをセッション番号iと呼ぶ)。図に示す各符号のサフィックス「i」は、第i番目のセッションについての情報であることを示すものである。
【0030】
図1に示す例と同様に、この図2の例でも、ユーザ用情報処理装置100、加盟店用情報処理装置200、承認業者用情報処理装置300がインターネット400を介して接続される。やはり、ユーザ用情報処理装置100は、ユーザの管理下にある情報処理装置であり、一般的には、インターネット400に接続する機能を有するパソコンや携帯型情報端末装置がユーザ用情報処理装置100として利用されることになる。ただ、実用上は、後に§3で述べるように、ICカードをユーザ用情報処理装置100の一部として利用するのが好ましい。加盟店用情報処理装置200は、前述したように、クレジットカードの加盟店によって管理されている情報処理装置であり、仮想ショッピングモールのWebページのサイトを提供するWebサーバ装置によって構成される。また、承認業者用情報処理装置300は、前述したように、承認業者によって管理される比較的大規模なホストコンピュータによって構成され、各ユーザに関する種々の情報をデータベースとして格納する機能を有している。
【0031】
この図2に示す決済処理方法は、あくまでもクレジットカードを用いた決済処理方法であり、その点では、図1に示す従来の決済処理方法と同じである。すなわち、第n番目のユーザUnは、クレジットカード会社から予めクレジットカード10の発行を受けており、このクレジットカード10には、ユーザの氏名Nn、クレジットカード番号Cn、有効期限Dnなる情報が記載されている。ただし、従来の決済処理方法では、加盟店側にこれらの各情報を知らせる必要があるが、本発明に係る決済処理方法では、その必要がなくなる。以下、この決済処理方法の基本概念を説明する。
【0032】
いま、第n番目のユーザUnが、ユーザ用情報処理装置100のWebブラウザ機能を利用して、第m番目の加盟店Smが管理する加盟店用情報処理装置200内のサイトにおけるショッピングモールにアクセスして所望の商品を購入し、クレジットカード10を利用してその代金を決済する場合を考える。この場合、加盟店用情報処理装置200は、1セッションとして決済処理の手続きを行うことになるが、ここでは、このセッションが第i番目のセッションであったとしよう。まず、加盟店用情報処理装置200は、この第i番目のセッションに固有のセッション識別コードSES(m,i)を発生させる。本発明で用いられるセッション識別コードは、特定の決済事項に関する1処理手続(1セッション)に対応したコードであって、少なくとも同一ユーザに関しては、各処理手続ごとに毎回異なるユニークなコードになるという条件をもったコードである。図示されているセッション識別コードSES(m,i)は、第m番目の加盟店Smについての第i番目のセッションに対応して発生されたコードであることを示している。
【0033】
セッション識別コードは、上述したように、少なくとも同一ユーザに関しては、各処理手続ごとに毎回異なるユニークなコードになる、という条件をもったコードであれば、どのようなコードを発生させてもかまわない。別言すれば、異なるユーザに対しては、同一のセッション識別コードを発生させてもかまわない。ただ、実用上は、少なくとも、同一の加盟店における加盟店用情報処理装置200で発生させるすべてのセッション識別コードが、互いに異なるユニークなコードになる、という条件下で、セッション識別コードを発生させた方が好ましい。これは、同一の加盟店で発行したセッション識別コードがすべて異なるようにしておけば、セッション識別コードとこれを発行した加盟店さえ特定できれば、どの加盟店がどのセッションのために当該セッション識別コードを発行したのかを一義的に決定できるためである。更に好ましくは、すべての加盟店における加盟店用情報処理装置200で発生させるすべてのセッション識別コードが、互いに異なるユニークなコードになる、という条件下で、セッション識別コードを発生させるとよい。そうすれば、セッション識別コードだけを見れば、どの加盟店がどのセッションのために当該セッション識別コードを発行したのかを一義的に決定できることになる。
【0034】
このようなユニークなセッション識別コードを発生させるためには、決済日、決済時、セッション番号、もしくはこれらの組合せを利用すると便利である。具体的には、ユーザUnからクレジットカードによる決済を行う旨の指示があった時点が、たとえば、2000年10月30日15時26分34秒であったとすると、「2000/10/30/15/26/34」のようなコードをセッション識別コードとして発生させることができる。あるいは、当該加盟店において決済があるたびに、シリアル番号からなるセッション番号を更新してゆくようにし、このセッション番号をセッション識別コードとして利用してもかまわない。もちろん、セッション番号を毎日リセットするようにし、2000年10月30日における第365番目のセッションであれば、「2000/10/30/365」のようなセッション識別コードを発生させることも可能である。更に、すべての加盟店で発生されたすべてのセッション識別コードをユニークにするのであれば、上述した各セッション識別コードに、個々の加盟店の名前や識別コードを付加したものを用いるようにすればよい。たとえば、第m番目の加盟店Smの2000年10月30日における第365番目のセッションであれば、「m/2000/10/30/365」のようなセッション識別コードを発生させることができる。
【0035】
さて、こうして、第m番目の加盟店が管理する加盟店用情報処理装置200において、第i番目のセッションについてのセッション識別コードSES(m,i)が発生されたら、インターネット400を介して、これをユーザ用情報処理装置100へと送信する。ユーザ用情報処理装置100では、この送信されてきたセッション識別コードSES(m,i)と、決済に利用するクレジットカード10のクレジットカード番号Cnと、の少なくとも2つの情報に基づいて、ユーザ側演算対象データを作成する。図2に示す実施形態の場合、クレジットカード番号Cnを示す数字列に、送信されてきたセッション識別コードSES(m,i)を構成する文字列を付加してなるデータを、ユーザ側演算対象データとしている。次に、このユーザ側演算対象データに対して、所定のアルゴリズムARGに基づく演算処理を行うことにより、決済識別コードID(m,i)を発生させる。
【0036】
ここで、決済識別コードID(m,i)は、クレジットカード番号Cnおよびセッション識別コードSES(m,i)を含んだユーザ側演算対象データに所定のアルゴリズムARGに基づく演算処理を行うことにより一義的に定まるコードである必要があるが、逆に、決済識別コードID(m,i)に基づいて、クレジットカード番号Cnを知ることはできないようにする必要がある。たとえば、アルゴリズムARGを秘密にしておけば、決済識別コードID(m,i)に基づいて、クレジットカード番号Cnを求めることはできないので、秘密のアルゴリズムARGを用いた所定の演算を利用すれば、このような目的は達成させることができる。ただ、実用上は、HASH関数もしくはその他の非可逆的な関数を作用させる演算処理により、決済識別コードID(m,i)を求めるようにするのが好ましい。ユーザ側演算対象データに対して、HASH関数などの非可逆的な関数を作用させる演算処理を行って決済識別コードID(m,i)を求めるようにすれば、必ず一義的な決済識別コードID(m,i)が求まり、かつ、この決済識別コードID(m,i)から元のユーザ側演算対象データを算出することは不可能である。このような非可逆的な関数を作用させる演算処理を利用するようにすれば、たとえば、「HASH関数を作用させる」というアルゴリズムARG自体は秘密にしておく必要はないので、秘密管理のための労力が不要になる。
【0037】
こうして、ユーザ用情報処理装置100において、決済識別コードID(m,i)が発生できたら、これをインターネット400を介して、加盟店用情報処理装置200へと送信する。結局、加盟店用情報処理装置200側からユーザ用情報処理装置100側に、セッション識別コードSES(m,i)が送信され、これに対する返信として、ユーザ用情報処理装置100側から加盟店用情報処理装置200側に、決済識別コードID(m,i)が戻されることになる。なお、本実施形態では、ユーザ用情報処理装置100側から加盟店用情報処理装置200側には、図示のとおり、ユーザUnの氏名Nnも送信されるようにしている。この氏名Nnの送信は、本発明に係る決済処理を実行する上で必須の事項ではないが、後述するように、承認業者用情報処理装置300における承認処理が円滑に行われるようにするために、実用上は、氏名Nnの送信を行うのが好ましい。また、通常は、加盟店SmからユーザUnに商品の発送などのサービスを提供する上でも、加盟店Sm側にユーザUnの氏名Nnを通知しておく必要がある。
【0038】
さて、図1で説明したように、従来の方法では、ユーザUnは、加盟店用情報処理装置200に対して、氏名Nn,クレジットカード番号Cn,有効期限Dnを送信する必要があったが、本実施形態に係る方法では、氏名Nnと決済識別コードID(m,i)とを送信すれば足りる。有効期限Dnについては、送信しても特に問題はないが、クレジットカード番号Cnについては、加盟店側に送信を行うと、加盟店側に悪意をもった従業員などがいた場合に不正利用が行われる可能性があり、セキュリティの面で問題が生じることになる。本発明に係る方法では、加盟店側には、クレジットカード番号Cnは一切知らされないので、このような問題は生じない。
【0039】
続いて、加盟店用情報処理装置200は、承認業者用情報処理装置300に対して、当該セッションについての決済金額P(m,i)についての決済要求を出すことになるが、このとき、承認業者用情報処理装置300に対しては、少なくとも、ユーザ用情報処理装置100から送信されてきた決済識別コードID(m,i)と、先程発生させたセッション識別コードSES(m,i)と、当該セッションについての決済金額P(m,i)と、を送信すればよい。もっとも、実用上は、これに更に、ユーザUnの氏名Nnを送信するのが好ましい。
【0040】
このような決済要求を受けた承認業者用情報処理装置300は、次のような方法で、この決済要求に対する2つの条件判断を行い、この2つの条件がともに満たされていた場合に、当該決済要求に対する承認を行う。すなわち、まず、加盟店用情報処理装置200から送信されてきた氏名Nnに着目し、データベースとして用意されているクレジットカードの会員名簿の中から、この氏名Nnと同姓同名の会員を検索する。氏名Nnによっては、唯一の会員が検索される場合もあるし、多数の同姓同名の会員が検索される場合もある。ここでは、たとえば7名の同姓同名の会員が検索されたものとしよう。クレジットカードの会員名簿には、各会員のクレジットカード番号のデータも用意されているので、この7名の会員について、ユーザ側演算対象データと同一構成の承認業者側演算対象データを作成する。具体的には、ここで述べる実施形態の場合、クレジットカード番号にセッション識別コードを付加することによりユーザ側演算対象データが作成されていたので、全く同様に、この7名のクレジットカード番号にそれぞれセッション識別コードを付加することにより、7通りの承認業者側演算対象データを作成する。そして、この7通りの承認業者側演算対象データのそれぞれに対して、ユーザ用情報処理装置100側で行った所定のアルゴリズムARGに基づく演算処理を施す。ここで述べる実施形態の場合、7通りの承認業者側演算対象データのそれぞれに対して、HASH関数を作用させて所定のコードを得る。
【0041】
こうして得られた7通りのコードのうち、加盟店用情報処理装置200から送信されてきた決済識別コードID(m,i)と同一のコードが存在すれば、当該一致をもたらしたクレジットカード番号に対応する会員が、当該セッションにおける決済主体となるユーザUnであると特定することができる。別言すれば、当該ユーザUnについては、そのクレジットカード番号Cnとセッション識別コードSES(m,i)とにより作成された演算対象データに対して、ユーザ側と承認業者側とで所定のアルゴリズムARGに基づく演算がそれぞれ別個に行われ、その結果として決済識別コードID(m,i)がそれぞれ別個に得られ、かつ、これら別個に得られた決済識別コードID(m,i)が一致したことになる。これは、加盟店用情報処理装置200側からの決済要求が、正規のクレジットカード会員であるユーザUnからの正規の決済要求に基づくものであることを示している。そこで、承認業者用情報処理装置300は、この決済識別コードID(m,i)の一致を第1の条件として、このユーザUnに関する決済要求に対する承認を行うことができる。
【0042】
一方、7通りの演算結果のうち、加盟店用情報処理装置200側から送信されてきた決済識別コードID(m,i)と一致するものが1つもない場合には、店用情報処理装置200側からの決済要求は、正規の決済要求ではないものと判断し、これに対する承認は行わないようにする。
【0043】
このように、承認業者用情報処理装置300に対して、ユーザUnの氏名Nnが伝えられると、承認業者用情報処理装置300における承認処理が円滑に進行することになる。すなわち、予め、決済主体となる会員の候補を、氏名Nnと同姓同名の会員のみ(上述の例の場合、7名の会員)に限定し、この候補となる会員についてのクレジットカード番号を用いた演算(上述の例の場合、7通りのHASH演算)を行えばすむ。一般に、大手のクレジットカード会社の場合、全会員数は数100万人のオーダーになるが、同姓同名の候補会員数はたかだか知れた数であり、候補となる会員のクレジットカード番号を用いた演算をすべて行ったとしても、演算負担はそれほど大きなものにはならない。
【0044】
もっとも、前述したように、本発明を実施する上では、ユーザUnの氏名Nnを加盟店用情報処理装置200および承認業者用情報処理装置300に送信することは必須要件ではない。すなわち、承認業者用情報処理装置300側に氏名Nnのデータが送信されなかったとしても、全会員を候補として、クレジットカード番号を用いた演算を行えば、原理的には、演算結果が決済識別コードID(m,i)に一致した会員を、ユーザUnと特定することができる。しかしながら、数100万人のオーダーになる全会員を候補とする演算負担は膨大なものになるため、実用上は、本実施形態のように、氏名Nnのデータを送信するのが好ましい。また、有効期限Dnのデータを送信することにより、候補となる会員数を絞り込むことも可能である。
【0045】
このように、承認業者用情報処理装置300側において、送信されてきた決済要求が正規の決済要求であるとの判断を下すための第1の条件は、予め登録されている多数のユーザのうちの特定のユーザUnのクレジットカード番号Cnと、加盟店用情報処理装置200側から送信されてきたセッション識別コードSES(m,i)と、に基づいて承認業者側演算対象データを作成し、この承認業者側演算対象データに対してHASH関数を作用して得られるデータが、加盟店用情報処理装置200側から送信されてきた決済識別コードID(m,i)と一致する、という条件である。しかしながら、この第1の条件が満たされたことだけをもって、当該決済要求が正規のものであると判断することでは、完全なセキュリティを確保することができない。なぜなら、加盟店Smには、第i番目のセッションの結果、ユーザUnの氏名Nn,セッション識別コードSES(m,i),決済識別コードID(m,i)という1セットの情報が知られてしまっているので、加盟店Smの悪意をもった従業員が、この情報を盗み出して不正利用する可能性があるためである。すなわち、承認業者用情報処理装置300において、第i番目のセッションに対する決済処理が完了した後に、再び、ユーザUnの氏名Nn,セッション識別コードSES(m,i),決済識別コードID(m,i)という1セットの情報を承認業者用情報処理装置300に対して送信し、任意の金額についての決済要求を出したとすると、上述した第1の条件判断だけでは、当該決済要求も正規のものであると判断されてしまう。
【0046】
そこで、承認業者用情報処理装置300では、次のような第2の条件判断を行う。すなわち、加盟店用情報処理装置200から送信されてきた決済識別コードID(m,i)が、第1の条件判断プロセスで決済主体として特定されたユーザUnに関して過去に行われた決済処理で用いられた決済識別コードとは異なることを第2の条件とし、この条件が満たされているか否かを判断するのである。もちろん、このような判断を行うためには、決済処理を行うたびに、用いた決済識別コードを記録蓄積しておく必要がある。上述したような不正利用は、この第2の条件判断において検出されるため、当該不正な決済要求は承認されることがない。すなわち、加盟店Smの悪意をもった従業員が、盗み出した1セットの情報を用いて決済要求を出したとしても、既に、ユーザUnの氏名Nn,セッション識別コードSES(m,i),決済識別コードID(m,i)という1セットの情報を用いた正規の決済処理が1度行われているため、決済識別コードID(m,i)は、ユーザUnに関する過去の決済処理において既に用いられたコードと同一であるとして、第2の条件を満たさず、当該承認は拒絶されることになる。
【0047】
加盟店用情報処理装置200において発生させるセッション識別コードを、少なくとも同一ユーザに関しては、各セッションごとに毎回異なるようなコードにするのは、上述した第2の条件判断により、不正利用を防止するために他ならない。一般に、クレジットカード番号は、各クレジットカード会社が相互に調整し合うことにより、世界中の全クレジットカード番号がすべて異なるようなユニークな番号となっている。したがって、ユーザが異なれば、当然、クレジットカード番号も異なる。そこで、少なくとも同一ユーザに関しては、各セッションごとに毎回異なるセッション識別コードを発生させるようにしておけば(同一のユーザUnが、同一の加盟店Smで複数セッションの決済を行った場合に発生させられるセッション識別コードをそれぞれ異ならせるだけでなく、同一のユーザUnが、複数の加盟店Sm,Sk,…で決済を行った場合に発生させられるセッション識別コードもそれぞれ異ならせるようにしておけば)、図2に示す実施形態において、クレジットカード番号Cn+セッション識別コードSES(m,i)として与えられるユーザ側演算対象データ(および承認業者側演算対象データ)は、ユニークなものとなる。したがって、このユーザ側演算対象データに基づいて作成される決済識別コードID(m,i)もユニークなものとなる(実際には、HASH関数などを用いて決済識別コードを発生させると、ユーザ側演算対象データが異なるにもかかわらず、偶然にも、同一の決済識別コードが生成される可能性もあり、厳密には「ユニーク」とは言えないが、偶然に一致する確率が実用上零と見なせるような設定で決済識別コードの発生を行えば、実用上の問題は生じない)。
【0048】
また、同一ユーザUnに対して、加盟店が異なっていれば、同一のセッション識別コードを発生させることを許すような運用も可能である。たとえば、同一のユーザUnが、加盟店Smで決済を行ったときに発生されるセッション識別コードSES(m,i)と、加盟店Skで決済を行ったときに発生されるセッション識別コードSES(k,j)とが同一になったとすると、これらに基づいて作成される決済識別コードID(m,i)とID(k,j)とが同一になるが、承認業者用情報処理装置300に対する決済要求時に、加盟店Smからの決済要求であるのか、加盟店Skからの決済要求であるのか、を特定することにより、同一の決済識別コードを、加盟店Smについての決済識別コードと、加盟店Skについての決済識別コードとに識別した運用が可能である。ただ、このように、同一の決済識別コードの存在を許すような運用は、無用な混乱を招くおそれがあるため、実用上はあまり好ましくない。
【0049】
更に、上述の実施形態では、承認業者用情報処理装置300において、決済要求に対する承認を行うための第2の条件として、「送信されてきた決済識別コードが、特定のユーザに関して過去に行われた決済処理で用いられた決済識別コードとは異なる」という条件を用いているが、決済識別コードがユニークなものであることを確認する代わりに、セッション識別コードがユニークであることを確認する方法を採ることも可能である。この場合は、決済要求に対する承認を行うための第2の条件として、「送信されてきたセッション識別コードを、過去に送信されてきたセッション識別コードと比較した結果、セッション識別コードの発生条件の範囲内でユニークなコードとなっている」という条件を設定すればよい。ここで、「セッション識別コードの発生条件の範囲内でユニーク」としているのは、加盟店用情報処理装置200におけるセッション識別コードを発生させる際の運用方法に何通りかのバリエーションがあり、承認業者用情報処理装置300において、セッション識別コードが所定の運用通りの条件で発生されたか否かが確認できればよい、という考え方に基づいている。
【0050】
たとえば、加盟店用情報処理装置200においてセッション識別コードを発生させる際に、「すべての加盟店における加盟店用情報処理装置で発生させるすべてのセッション識別コードが、互いに異なるユニークなコードになる」という発生条件を設定したとすれば、承認業者用情報処理装置300に送信されてきたセッション識別コードは、すべて異なっているはずである。一方、「同一の加盟店における加盟店用情報処理装置で発生させるすべてのセッション識別コードは、互いに異なるユニークなコードになる」という発生条件を設定したとすれば、異なる加盟店で発生されたセッション識別コードであれば、同一のものが存在する可能性があるし、更に、「同一の加盟店において同一のユーザについて発生させるすべてのセッション識別コードは、互いに異なるユニークなコードになる」という発生条件を設定したとすれば、異なるユーザについて発生されたセッション識別コードであれば、同一のものが存在する可能性がある。したがって、承認業者用情報処理装置300では、加盟店用情報処理装置におけるセッション識別コードの発生条件の範囲内でユニークなものとなっていることを確認すればよい。
【0051】
以上、本発明を、図2の実施形態に基づいて説明したが、実用上は、ユーザ用情報処理装置100から加盟店用情報処理装置200に対して送信される情報には、ユーザUnの氏名Nnおよび決済識別コードID(m,i)だけでなく、ユーザUnの住所などの情報や、買い物対象となる商品やその個数などを示すデータも含まれることになるが、このような情報送信についての図示は省略している。また、加盟店用情報処理装置200から承認業者用情報処理装置300に対して送信される情報には、加盟店自身を特定する識別コードなどのデータも含まれることになるが、このような情報送信の図示も省略している。
【0052】
§3.本発明に係る具体的な決済処理方法
続いて、本発明に係るクレジットカードを用いた決済処理方法のより具体的な実施形態を述べる。ここで述べる実施形態の第1の特徴は、ユーザ用情報処理装置100として、ICカードを利用した点にあり、第2の特徴は、複数のクレジットカードについて適用できるようにした点にある。
【0053】
図3は、この実施形態で用いられるユーザ用情報処理装置100の基本構成を示すブロック図である。ここに示す例では、ユーザ用情報処理装置100は、パソコン110、リーダライタ装置120、ICカード130によって構成されている。ICカード130としては、CPUおよびメモリを内蔵した演算処理機能をもったICカードであれば、どのようなICカードを用いてもかまわない。最近は、磁気カードに代わる携帯型情報記録媒体として、種々のタイプのICカードが普及し始めている。一般に、ICカードは、ソフトウエアをロードすることにより様々な機能を付加することができるので、ICカードを利用して本発明に係る決済処理方法を実施する場合、必ずしも新たな専用のICカードをユーザに配付する必要はない。ユーザが既に何らかのICカードを所持しているのであれば、このICカードに、本発明に係る決済処理方法を実行するための専用ソフトウエアあるいは専用のデータ、またはその両方をロードするだけで、既存のICカードをそのまま利用して本発明を実施することが可能になる。
【0054】
リーダライタ装置120は、このICカード130に対する情報伝送を行う汎用の読取/書込装置であり、パソコン110は、このリーダライタ装置120を介してICカード130へのアクセスを行う汎用のコンピュータである。ここ数年来、個人レベルでのパソコン所有率が高まり、かなりのユーザがパソコンを所有し、インターネットへの接続環境を備えている。本発明による決済処理方法を利用する場合、このような汎用のパソコン110に、汎用のリーダライタ装置120を接続し、所定のソフトウエアをロードしたICカード130を用意すればよい。このICカード130をリーダライタ装置120に装着し、パソコン110によってアクセスを行うようにすれば、このシステムが全体として、§2で述べたユーザ用情報処理装置100として機能することになる。
【0055】
このように、本実施形態では、パソコン110,リーダライタ装置120,ICカード130からなるシステムによって、ユーザ用情報処理装置100が構成されることになるが、実質的には、ICカード130がユーザ用情報処理装置100としての主たる機能を果たし、パソコン110およびリーダライタ装置120は、このICカード130をインターネット400へ接続するためのインターフェイスとしての役割を果たしているにすぎない。すなわち、本発明において重要な機能を果たす情報は、いずれもICカード130内に格納されることになる。以下、このICカード130内に格納されている情報について説明する。
【0056】
図3に示すように、ICカード130内には、「PRG」,「ARG」,「PIN」,「DATE」,「MAG」なる情報が収容されている。ここで、「PRG」は、このICカード130を本発明に係るユーザ用情報処理装置100の主たる構成要素として機能させるためのプログラムであり、§2で述べたユーザ用情報処理装置100の各機能は、このプログラムの制御のもとに実現されることになる。また、「ARG」は、図2に示す演算対象データ(図2の例では、クレジットカード番号Cn+セッション識別コードSES(m,i))に対して行うべき所定のアルゴリズムに基づく演算処理ルーチンであり、具体的には、たとえばHASH関数などを作用させるアルゴリズムのルーチンということになる。次の「PIN」は、このICカード130の利用を可能にするためのユーザUn自身の識別コードである。ユーザUnは、このICカード130をリーダライタ装置120に装着した後、パソコン110から正しい「PIN」コードを入力する作業を行う。入力した「PIN」コードは、ICカード130内部の「PIN」コードと照合され、両者が一致していた場合に、以後のICカード130へのアクセスが許可されることになる。この「PIN」コードの照合機能は、一般的なICカード130には必ず備わっている既存の機能であり、本発明に固有の機能というわけではない。「DATE」は、現在の日付および時刻を示すデータであり、一般に、外部からICカード130に知らされる(ICカードの中では、知らされた日付がシーケンシャルであるかをチェックすることもある。)。また、「MAG」はいわゆるマジックコードであり、後述するように、決済識別コードを作成するために利用される。
【0057】
上述の各情報のうち、「PIN」はICカード130を利用するための基本的なコードであり、「DATE」はICカード130に対して外部から与えられるデータであるので、いずれも、一般的なICカードに標準的に備わっている情報と言うことができる。これに対して、「PRG」,「ARG」,「MAG」は、本発明の実施のために用意される専用の情報である。ユーザUnが既に所有している既存のICカード(たとえば、社員証として機能するICカード、診察券として機能するICカード、サービスポイントを貯めるためのICカードなど、既に種々のICカードが実際に利用されている)を、本発明のためにも流用するというケースの場合は、準備手続として、パソコン110から、これら専用の情報「PRG」,「ARG」,「MAG」をICカード130側へとロードすればよい。ロード対象となるこれら専用の情報は、CD−ROMなどに収容してユーザUnに配付してもよいし、インターネット400を介してパソコン110へダウンロードさせるようにしてもよい。もちろん、「PRG」,「ARG」,「MAG」といったデータが予めロードされたICカードを用いて、社員証、診察券、サービスポイントカードなどを発行し、これを配布するようにすれば、これらのデータをロードする処理は不要になる。
【0058】
準備手続においてユーザUnが行う作業は、これら専用の情報をICカード130にロードする作業と(上述したように、これらの専用情報が予めロードされたICカードが配布されていた場合は、このロード作業は不要である。)、クレジットカードに関するデータをICカード130へ入力する作業である。図3に示す例では、ユーザUnが、異なる2つのクレジットカード会社から、それぞれクレジットカードαおよびクレジットカードβなるクレジットカードの発行を受けており、この2枚のクレジットカードの情報をICカード130へ入力して利用する例が示されている。このような情報入力は、既にICカード130内にロードされているプログラム「PRG」の処理機能に基づいて行うことができる。図示の例の場合、クレジットカードαに記載されている氏名αNn,クレジットカード番号αCn,有効期限αDnと、クレジットカードβに記載されている氏名βNn,クレジットカード番号βCn,有効期限βDnと、をICカード130内に書き込む作業が行われることになる(氏名αNnと氏名βNnとは同一である必要はなく、たとえば、一方を家族名義にしてもかまわない。)。ユーザUnは、クレジットカードα,βを手元に置いて、パソコン110のキーボードなどから、これらのデータを入力する作業を行う。なお、この例では、更に、利用限度額αLn,βLnを入力している。この利用限度額αLn,βLnの役目については、§4の変形例のところで述べる。
【0059】
こうして、各クレジットカードα,βについて、氏名αNn,βNn,クレジットカード番号αCn,βCn,有効期限αDn,βDn,利用限度額αLn,βLnの入力作業が完了すると、ユーザUn側の準備手続は完了である。一方、このような準備手続によりICカード130内に格納されることになった「PRG」,「ARG」,「MAG」といったデータは、承認業者用情報処理装置300側にも用意しておく必要がある。これは、ユーザ用情報処理装置100側と承認業者用情報処理装置300側とで、決済識別コードを生成するために同一の演算を行う必要があるためである。また、承認業者用情報処理装置300側には、個々のユーザUnについての氏名Nn,クレジットカード番号Cn,有効期限Dn,住所,電話番号などの情報が既にデータベースとして用意されている。
【0060】
このような準備手続が完了すれば、このICカード130自身を、クレジットカードα,βの代用カードとして利用することができるようになる。別言すれば、このICカード130は、クレジットカードα,βのいわゆる「子カード」として機能することになる。図3には、2枚のクレジットカードα,βの情報をICカード130内に入力した例が示されているが、もちろん、3枚以上のクレジットカードについての情報をICカード130内に入力することも可能であり、ユーザUnは、このICカード130を、多数のクレジットカードの「子カード」として利用することが可能になる。しかも、このICカード130は、本質的には、各クレジットカードと同等のカード(同一のクレジットアカウントについてのカード)であるので、ICカード130を発行するために、新たに各クレジットカード会社の審査を受ける必要はない。クレジットカード会社によっては、いわゆる 「家族カード」と称するユーザの家族名義の「子カード」を発行するサービスを提供していることがあるが、通常、このような「家族カード」の発行を受けるためには、その旨の申請書をクレジットカード会社に提出し、一応の審査を受ける必要がある。本発明によって発行されるICカード130は、このような「家族カード」とは全く性質の異なるカードであり、本質的に元のクレジットカードと同一のアカウントを利用したカードということになるので、発行に際してクレジットカード会社による新たな審査は必要なく、繁雑な事務処理を経ることなしに円滑な発行が可能である。
【0061】
続いて、このICカード130を用いた決済処理の手順を説明する。上述したように、ICカード130は、必ずしも本発明に利用する専用のカードにする必要はなく、他の種々の用途に共用することが可能である。ユーザUnは、このICカード130を、本発明に係る決済処理に利用する場合に、リーダライタ装置120に装着すればよい。ユーザUnが、パソコン110を用いて加盟店の仮想ショッピングモールのWebページにアクセスし、クレジットカードによる決済を行う場合は、まず、ICカード130をリーダライタ装置120に装着し、パソコン110を用いて「PIN」データを入力する。ICカード130の内部で「PIN」データの照合が完了すると、以下のような一連の決済処理が自動的に実行される。
【0062】
まず、ユーザUnは、どのクレジットカードを用いて決済を行うかを選択する入力を行う。たとえば、ユーザUnがクレジットカードαによって決済する旨の選択入力を行うと、ユーザUnの氏名αNn(クレジットカードαについて登録されている氏名)がインターネット400を介して加盟店用情報処理装置200へと送信される。実際には、この他、ユーザUnの住所、電話番号、Eメールアドレス、購入した商品や数量を示す情報なども送信されることになる。このような処理は、ICカード130内のプログラム「PRG」と、加盟店用情報処理装置200のWebサーバ内のプログラムの連繋動作によって行われる。
【0063】
加盟店用情報処理装置200は、ユーザ用情報処理装置100側から、これらの情報が送信されてきたら、§2で述べたように、ユニークなセッション識別コードを発生させる。本発明を実施する上で、セッション識別コードは、少なくとも同一ユーザに関しては、各処理手続ごとに毎回異なるユニークなコードが発生できればよいので、ユーザ用情報処理装置100側から送信されてきたユーザの氏名αNn、住所、電話番号などからユーザUnを特定し、少なくとも同一ユーザに関しては、各処理手続ごとに毎回異なるようなセッション識別コードを発生させるようにすればよい。ただ、ここで述べる実施形態では、すべての加盟店において発生されたすべてのセッション識別コードが、互いに異なるユニークなコードとなるように、たとえば、第m1番目の加盟店Sm1の第i1番目のセッションであれば、SES(m1,i1)なるセッション識別コードを発生させるようにしている。こうして発生されたセッション識別コードSES(m1,i1)は、インターネット400を介して、ユーザ用情報処理装置100へと送信される。
【0064】
ユーザ用情報処理装置100は、送信されてきたセッション識別コードSES(m1,i1)を利用して、決済識別コードID(m1,i1)を発生させる処理を行う。この処理は、図4に示すように、ICカード130内において行われる。図2に示す例では、「クレジットカード番号Cn+セッション識別コードSES(m,i)」をユーザ側演算対象データとして、これに所定のアルゴリズムに基づく演算を施すことにより、決済識別コードID(m,i)を発生させていたが、ここに述べる実施形態では、図4の左下に示すように、「αCn+αDn+DATE+MAG+SES(m1,i1)」をユーザ側演算対象データとして、このユーザ側演算対象データに対して所定のアルゴリズムARGに基づく演算(HASH関数もしくはその他の非可逆的な関数を作用させる演算)を施すことにより、決済識別コードID(m1,i1)を発生させている。ここで、αCnおよびαDnは、準備手続においてICカード130へ入力されたクレジットカードαについてのクレジットカード番号および有効期限である。クレジットカード番号αCnだけでなく、更に有効期限αDnを用いて決済識別コードを発生させることにより、更にセキュリティを高めることができる。
【0065】
一方、マジックコードMAGは、時期(年、月、日、週、時刻など)に応じて内容が変化する特有のコード(たとえば、任意の文字列)である。たとえば、1月は「松」、2月は「梅」、3月は「桜」、…というように、12か月分のマジックコードMAGを任意の文字列として定めておき、1月中に行われた決済には「松」なるマジックコードを採用し、2月中に行われた決済には「梅」なるマジックコードを採用する、というような運用を行えば、セキュリティをより向上させることができる。もちろん、月曜日、火曜日、水曜日、…というように曜日ごとに異なるマジックコードを設定することもできるし、偶数日と奇数日とで異なるマジックコードを設定するようなこともできる。このように、時期に応じて内容が変化するコードを演算対象データに含ませてから、決済識別コードID(m1,i1)を作成すれば、決済識別コードID(m1,i1)からクレジットカード番号αCnを類推することを困難にする上で極めて有効である。
【0066】
日付/時刻DATEは、決済時点の日付および時刻を示すデータである。たとえば、2000年10月30日午後3:00というようなデータが演算対象データの一部として組み込まれることになる。このようなDATEを加えることは、上述したマジックコードMAGを加えることと同様に、決済識別コードID(m1,i1)からクレジットカード番号αCnを類推することを困難にする上で極めて有効である。もちろん、日付/時刻DATEは、必ずしも決済日時を示すコードにする必要はなく、たとえば、2000年10月30日というように決済日のみを含むコードにすることもできるし、午後3:00というように決済時のみを含むコードにすることもできる。また、2000年10月30日午後3時13分24.2秒のように、正確な秒までも含むコードにすることも可能であるが、あまり精度の高い時刻コードを用いると、ICカード130内で決済識別コードを生成した時刻と、承認業者用情報処理装置300内で決済識別コードを生成した時刻とが不一致となり、両者の決済識別コードが一致しなくなるおそれがあるので、ICカード130側のクロックと承認業者用情報処理装置300側のクロックとの誤差や、インターネット400を介しての伝送遅延時間などを考慮して、両者で同一の時刻コードが用いられる範囲内の精度に抑える必要がある。
【0067】
上述の例は、クレジットカードαで決済を行う場合の処理であるが、クレジットカードβで決済を行う場合には、図4の右下に示すような処理が行われる。すなわち、第m2番目の加盟店から、SES(m2,i2)なるセッション識別コードが送信されてきた場合、「βCn+βDn+DATE+MAG+SES(m2,i2)」をユーザ側演算対象データとして、このユーザ側演算対象データに対して所定のアルゴリズムARGに基づく演算(HASH関数もしくはその他の非可逆的な関数を作用させる演算)を施すことにより、決済識別コードID(m2,i2)を発生させることになる。ここで、βCnおよびβDnは、準備手続においてICカード130へ入力されたクレジットカードβについてのクレジットカード番号および有効期限である。
【0068】
なお、ここに示す実施形態では、決済識別コードを発生させるためのアルゴリズムARGをICカード130内のメモリに格納し、決済識別コードの発生処理を、ICカード130内において実行するようにしているが、これはセキュリティを更に高めるための配慮である。一般に、CPU内蔵型のICカードでは、内部メモリに格納された情報に対して十分なセキュリティが確保されており、図4に示すICカード130内の各情報が、不正な手段で外部に読み出される可能性はないと考えてよい。したがって、万一、ユーザUnがこのICカード130を紛失したとしても、内部に格納された種々の情報が流出するおそれはない。本発明の決済処理に必要な種々の情報を、パソコン110側ではなく、ICカード130側に格納しているのは、ICカードがこのような高度なセキュリティを備えているからである。
【0069】
図5は、図4に示すICカード130内に格納されている情報に対応して、承認業者用情報処理装置300内に格納されている情報の一例を示す図である。ここで、「PRG」は、承認業者用情報処理装置300に決済要求に対する承認処理を行わせるためのプログラムであり、「ARG」は、ICカード130内に格納されているのと同一の演算アルゴリズム(HASH関数もしくはその他の非可逆的な関数を作用させる演算のアルゴリズム)であり、「DATE」は、現在の日付/時刻を示すコード(承認業者用情報処理装置300の内蔵クロックに基づいて生成される)であり、マジックコードMAGは、ICカード130内に格納されているのと同一のマジックコードである。また、クレジットカードαあるいはβに関するデータとして、複数のユーザU1,U2,…,Uk,…に関するデータがそれぞれ格納されている。ここで、たとえば、クレジットカードαに関する第k番目のユーザUkのデータとしては、図示のとおり、氏名αNk,クレジットカード番号αCk,有効期限αDk,利用限度額αLLk,その他、ユーザUkの住所や電話番号、決済金額データなどが格納されることになる。
【0070】
既に§2で述べたように、加盟店用情報処理装置200から承認業者用情報処理装置300に対しては、ユーザUnの氏名Nn,決済識別コードID(m1,i1),セッション識別コードSES(m1,i1),決済金額P(m1,i1),加盟店Smを示すコードなどのデータを送信することにより決済要求が出される。このような決済要求を受けた承認業者用情報処理装置300は、上述したように、2つの条件がともに満たされていた場合に、当該決済要求に対する承認を行う。すなわち、まず、加盟店用情報処理装置200から送信されてきた氏名Nnに着目し、データベースとして用意されているクレジットカードの会員名簿の中から、この氏名Nnと同姓同名の会員を検索する。たとえば7名の同姓同名の会員が検索されたとすると、クレジットカードの会員名簿には、各会員のクレジットカード番号のデータも用意されているので、この7名の会員について、ユーザ側演算対象データと同一構成の承認業者側演算対象データを作成する。
【0071】
たとえば、第k番目のユーザUkについての承認業者側演算対象データは、図5の右下に示すように、「αCk+αDk+DATE+MAG+SES(m1,i1)」ということになる。この第k番目のユーザUkは、第n番目のユーザUnと同姓同名であるため、氏名Nk=Nnということになるが、クレジットカード番号についてはそれぞれ異なる番号が与えられているので、αCk≠αCnということになる。また、有効期限については、偶然の一致がない限り、αDk≠αDnである。一方、DATEおよびMAGについては、ユーザ用情報処理装置100側の演算で用いられたデータと同一のデータが用いられるようにし、SES(m1,i1)は、加盟店用情報処理装置200から送信されてきたものをそのまま用いるようにする。
【0072】
こうして、承認業者側演算対象データが作成されたら、これに所定のアルゴリズムARGに基づく演算を施し、決済識別コードID(m1,i1)を作成し、加盟店用情報処理装置200から送信されてきた決済識別コードID(m1,i1)と一致するか否かを調べる。同姓同名の7名の会員について、このような方法で決済識別コードID(m1,i1)を作成すれば、第n番目のユーザUnについて作成された決済識別コードID(m1,i1)だけが、送信されてきた決済識別コードID(m1,i1)と一致することになる。このようにコードの一致が得られれば、当該一致をもたらしたクレジットカード番号に対応する会員が、当該セッションにおける決済主体となるユーザUnであると特定することができ、このユーザUnに関する決済要求に対する承認を行う上での第1の条件が満たされることになる。
【0073】
次に、承認業者用情報処理装置300では、次のような第2の条件判断を行う。すなわち、加盟店用情報処理装置200から送信されてきた決済識別コードID(m1,i1)が、決済主体として特定されたユーザUnに関して過去に行われた決済処理で用いられた決済識別コードとは異なるか否かを確認する。ユーザUnに関して、過去に決済識別コードID(m1,i1)と同一コードで決済が行われた事実がなければ、第2の条件も満たされたことになり、当該決済要求は承認されることになる。もちろん、§2で述べたように、決済識別コードID(m1,i1)がユニークであることを確認する代わりに、セッション識別コードSES(m1,i1)が発生条件の範囲内でユニークであることを確認してもよい。
【0074】
§4.いくつかの変形例
最後に、本発明に係るクレジットカードを用いた決済処理方法の変形例をいくつか述べておく。
【0075】
(1) 図2に示す実施形態では、ユーザ用情報処理装置100において発生させた決済識別コードID(m,i)を、加盟店用情報処理装置200を介して承認業者用情報処理装置300に送信するようにしているが、決済識別コードID(m,i)は必ずしも加盟店用情報処理装置200経由で承認業者用情報処理装置300へ送信する必要はなく、ユーザ用情報処理装置100から承認業者用情報処理装置300に直接送信する(たとえば、インターネット400を介して、ユーザ用情報処理装置100から承認業者用情報処理装置300へ伝達する)ようにしてもかまわない。この場合、承認業者用情報処理装置300は、加盟店用情報処理装置200から、ユーザ名Nn,セッション識別コードSES(m,i),決済金額P(m,i)の送信を受け、ユーザ用情報処理装置100から決済識別コードID(m,i)の送信を受けることになるので、両者から送信されてきた情報が、同一のセッションに関する情報であることを認識できるように、何らかの方法で同期をとるような工夫(送信時間を時間的に同期させる方法に限らず、たとえば、何らかの同期用コードを各情報に付加するような方法でもよいし、ユーザ用情報処理装置100から決済相手の加盟店を識別する情報を送信する方法でもよい)が必要になる。
【0076】
(2) 図4に示すICカード130内には、各クレジットカードα,βの利用限度額αLn,βLnが設定されている。一方、図5に示す承認業者用情報処理装置300内にも、各クレジットカードの各ユーザごとに、クレジットカードの利用限度額(たとえば、クレジットカードαの第n番目のユーザUnについては、利用限度額αLLn)が設定されている。ここで、承認業者用情報処理装置300側に設定されている利用限度額αLLnは、クレジットカード会社が設定した本来の利用限度額であり、ユーザUnは、1か月間に、この利用限度額αLLnを越える決済を行うことはできない(そのような決済要求は否認されることになる)。これに対して、ICカード130側に設定されている利用限度額αLn(あるいはβLn)は、準備手続の段階でユーザUn自身が任意に設定できる限度額である。一般的には、αLn=αLLnというように、クレジットカード会社が設定した利用限度額と同じ額を、ICカード130内の利用限度額として設定すればよいが、敢えて、αLn<αLLnのような設定を行い、無駄遣いを抑えるための自主管理の目的設定に用いることもできる。
【0077】
利用限度額αLnの設定を行った場合、クレジットカードαを用いてこの利用限度額αLnを越えるような決済が行われる場合には、その旨の警告が提示されるようにしておく。たとえば、ICカード130内に、今月の決済金額の累積値を記録しておくようにし、新たに決済しようとしている金額と、この累積値との合計が、利用限度額αLnを越えるような場合には、ICカード130内のプログラム「PRG」の機能によって、パソコン110の画面上に何らかの警告表示を行うようにしておけばよい。αLn<αLLnなる設定が行われていた場合には、この警告表示を無視して決済を断行することができるようにしておいてもよいし、警告表示が出されたら当該決済は拒絶されるようにしておいてもよい。
【0078】
(3) 前述の実施形態では、インターネット上の仮想ショッピングモールでの買い物の決済を、インターネット上で行う例について述べたが、本発明に係る決済方法は、必ずしもインターネット決済に限定されるものではない。たとえば、ユーザが実際の店舗に買い物や食事に行って代金を決済する場合、クレジットカードαやβを用いる代わりに、ICカード130を用いて決済することも可能である。この場合、当該店舗に設置されたリーダライタ装置120にICカード130を装着して決済を行えばよい。ICカード130は、1枚で複数枚のクレジットカードとして機能することができ、かつ、クレジットカード以外の種々の機能を有しているので、多数のクレジットカードを所持する代わりに、このICカード130を1枚だけ所持していれば、すべてのクレジットカードのアカウントを用いた決済が可能になる。このような利用形態では、ICカード130を装着したシステムがユーザ用情報処理装置100として機能することになる。ユーザ用情報処理装置100は必ずしもユーザの自宅に設置されている必要はなく、上述の利用形態の場合は、店舗に設置されたパソコン110およびリーダライタ装置120が、ユーザ用情報処理装置100としての機能を果たしていることになる。
【0079】
(4) 本発明に係るユーザ用情報処理装置100は、上述のように、ICカード130のような携帯型情報処理装置を利用して実現することができる。ICカードの場合、現在のところ、単独ではインタネットへの接続環境やデータ入力機能が備わっていないため、インターネット上の仮想ショッピングモールにおける決済を行う場合には、上述の実施形態のように、パソコン110およびリーダライタ装置120と組み合わせた形でユーザ用情報処理装置100を構成する必要があるが、携帯電話や携帯型情報端末装置など、単独でインターネットに接続する環境をもった装置を利用することができれば、そのような装置を単独でユーザ用情報処理装置100として用いることにより、インターネット上での決済が可能になる。
【0080】
【発明の効果】
以上のとおり、本発明に係るクレジットカードを用いた決済処理方法によれば、各加盟店に対するセキュリティを十分に確保することが可能になる。特に、前述した実施形態によれば、次のような種々の効果が得られる。
(1) ICカードを、クレジットカードの「子カード」として利用することになるが、ICカードは十分なセキュリティ対策が施されているため、紛失や盗難という事故が発生しても、本物のクレジットカードに比べて安全性が高い。すなわち、ICカードの内部に格納されたデータを不正な手段で外部に読み出すことは極めて困難であり、また、ICカードの表面にはクレジットカード番号は記載されないので、ICカードを目視しても、クレジットカード番号を認識することはできない。このため、紛失や盗難があっても、クレジットカード番号が第三者に知られる可能性は非常に低くなる。
(2) ICカード製のクレジットが普及するようになるまでには、まだ数年かかると予想されているが、本発明に係る方法では、正式なICカード製クレジットカードを用いる場合に比べて、カードの配布やカード発行のための審査といった作業に手間がかかることはないため、迅速な導入が可能になる。本発明は、特に、インターネットにおいてクレジットショッピングを実施したい場合に有効である。
(3) 本発明では、1枚のICカードに所有者が異なる複数枚のクレジットカードを登録することも可能である。したがって、たとえば、家族全員のクレジットカードの共通の 「子カード」となるようなICカードを作成することも可能になり、柔軟な運用が期待できる。
(4) 「子カード」化されたICカードの中には、必要な情報を記録しておくことができるので、端末装置からキー入力すべきデータ量を低減することができる。すなわち、決済識別コードは、プログラムに基づいて自動的に加盟店へと送られるため、個々のユーザが決済識別コードを入力する必要はない。実用上、ユーザはセッション識別コードや決済識別コードなどの存在すら意識する必要はない。
【図面の簡単な説明】
【図1】インターネット上の仮想ショッピングモールで買い物をする場合の従来の一般的なクレジットカードによる決済処理方法の手順を説明するブロック図である。
【図2】インターネット上の仮想ショッピングモールで買い物をする場合の本発明に係るクレジットカードによる決済処理方法の手順を説明するブロック図である。
【図3】本発明で用いるユーザ用情報処理装置100をICカード130を利用して構成した基本構成を示すブロック図である。
【図4】図3に示すICカード130における決済識別コードの発生手順を示す図である。
【図5】図3に示すICカード130に格納された情報に対応した、承認業者用情報処理装置300内の格納情報の一例を示す図である。
【符号の説明】
10…クレジットカード
100…ユーザ用情報処理装置
110…パソコン
120…リーダライタ装置
130…ICカード
200…加盟店用情報処理装置
300…承認業者用情報処理装置
400…インターネット
ARG…決済識別コード発生用アルゴリズム(HASH関数など)
C,Cn,Ck…クレジットカード番号
D,Dn,Dk…クレジットカードの有効期限
DATE…現時点の日付/時刻コード
ID(m,i)…セッション識別コードSES(m,i)に基づいて生成した決済識別コード
ID(m1,i1)…セッション識別コードSES(m1,i1)に基づいて生成した決済識別コード
ID(m2,i2)…セッション識別コードSES(m2,i2)に基づいて生成した決済識別コード
Ln,LLn,LLk…利用限度額
MAG…マジックコード
N,Nn,Nk…ユーザの氏名
P…決済金額
P(m,i)…第m番目の加盟店が生成した第i番目のセッションにおける決済金額
PIN…ユーザ識別コード
PRG…プログラム
SES(m,i)…第m番目の加盟店が生成した第i番目のセッション識別コード
SES(m1,i1)…第m1番目の加盟店が生成した第i1番目のセッション識別コード
SES(m2,i2)…第m2番目の加盟店が生成した第i2番目のセッション識別コード
Uk…第k番目のユーザ
Un…第n番目のユーザ
α,β…クレジットカード
α○○…クレジットカードαに関する○○
β○○…クレジットカードβに関する○○
Claims (9)
- クレジットカード会社から、所定のクレジットカード番号が付与されたクレジットカードの発行を受けたユーザが、当該クレジットカードの加盟店に対して当該クレジットカードを用いて決済を行う際の決済処理方法であって、
ユーザが利用するユーザ用情報処理装置と、決済相手となる加盟店が管理する加盟店用情報処理装置と、を接続し、前記ユーザが前記加盟店に対して特定の決済事項に関する処理を1処理手続として行う際に、
前記加盟店用情報処理装置が、前記特定の決済事項に関する1処理手続に対応したコードであって、「すべての加盟店における加盟店用情報処理装置で発生させるすべてのセッション識別コードが、互いに異なるユニークなコードになる」という条件をもったセッション識別コードを発生させ、このセッション識別コードを前記ユーザ用情報処理装置に送信する第1の段階と、
前記ユーザ用情報処理装置が、前記第1の段階によって送信されてきた前記セッション識別コードと予め格納されていた前記クレジットカード番号との少なくとも2つの情報に基づいてユーザ側演算対象データを作成し、このユーザ側演算対象データに対して、HASH関数もしくはその他の非可逆的な関数を作用させる演算処理を行うことにより一義的に決定される決済識別コードを発生させ、少なくとも、この決済識別コードと予め格納されていた前記ユーザの氏名とを、前記第1の段階の送信に対する返信として、前記加盟店用情報処理装置に送信する第2の段階と、
前記クレジットカードによる決済を承認する権限をもった承認業者が管理する承認業者用情報処理装置と、前記加盟店用情報処理装置と、を接続し、前記加盟店が前記承認業者に対して前記特定の決済事項に関する処理を1処理手続として行う際に、
前記加盟店用情報処理装置が、少なくとも、前記特定の決済事項に関して決定した決済金額と、前記第1の段階で発生させたセッション識別コードと、このセッション識別コードの送信に対する返信として前記第2の段階で送信されてきた前記決済識別コードおよび前記氏名とを、前記承認業者用情報処理装置へ送信することにより当該決済金額についての決済要求を出す第3の段階と、
前記承認業者用情報処理装置が、予めデータベースとして用意されているクレジットカードの会員名簿の中から、前記第3の段階によって送信されてきた前記氏名と同姓同名のユーザに関するクレジットカード番号を検索し、前記第3の段階によって送信されてきた前記セッション識別コードと、検索されたn個(nは自然数)のクレジットカード番号のそれぞれと、の少なくとも2つの情報に基づいて、前記ユーザ側演算対象データと同一構成の承認業者側演算対象データをn通り作成し、このn通りの承認業者側演算対象データに対して、前記第2の段階で行った演算処理と同一の演算処理を行うことによりn通りの決済識別コードを求め、このn通りの決済識別コードの中に、前記第3の段階によって送信されてきた前記決済識別コードに一致するコードが存在した場合に、当該一致をもたらしたクレジットカード番号に対応する会員を決済主体となる特定のユーザと認識し、前記一致が得られることを第1の条件とし、前記第3の段階で送信されてきた前記決済識別コードが、前記特定のユーザに関して過去に行われた決済処理で用いられた決済識別コードとは異なることを第2の条件とし、これら2条件がともに満たされた場合に、当該特定のユーザに関して前記決済要求に対する承認を行う第4の段階と、
を有し、前記第2の段階において、前記ユーザ用情報処理装置から前記加盟店用情報処理装置に対して、前記クレジットカード番号自体の送信は行わないことを特徴とするクレジットカードを用いた決済処理方法。 - 請求項1に記載の決済処理方法において、
セッション識別コードを発生させる際に、決済日、決済時、セッション番号もしくはこれらの組合せを利用することを特徴とするクレジットカードを用いた決済処理方法。 - 請求項1または2に記載の決済処理方法において、
ユーザ側演算対象データおよび承認業者側演算対象データとして、時期に応じて内容が変化するマジックコードを含ませることを特徴とするクレジットカードを用いた決済処理方法。 - 請求項1〜3のいずれかに記載の決済処理方法において、
ユーザ側演算対象データおよび承認業者側演算対象データとして、決済日、決済時、もしくは決済日時を示すコードを含ませることを特徴とするクレジットカードを用いた決済処理方法。 - 請求項1〜4のいずれかに記載の決済処理方法において、
ユーザ側演算対象データおよび承認業者側演算対象データとして、クレジットカードの有効期限を示すコードを含ませることを特徴とするクレジットカードを用いた決済処理方法。 - 請求項1〜5のいずれかに記載の決済処理方法において、
ユーザが複数のクレジットカード会社からそれぞれクレジットカードの発行を受けているときに、ユーザ用情報処理装置内に、個々のクレジットカードについての各クレジットカード番号をそれぞれ格納しておき、
決済を行うときに、ユーザに特定のクレジットカードを指定する入力を行わせ、指定されたクレジットカードに対応するクレジットカード番号を用いて、ユーザ側演算対象データを作成することを特徴とするクレジットカードを用いた決済処理方法。 - 請求項1〜6のいずれかに記載の決済処理方法において、
ユーザ用情報処理装置、加盟店用情報処理装置、承認業者用情報処理装置を、それぞれネットワークを介して接続し、加盟店のWebページ上に開かれた仮想ショッピングモールでユーザが買い物をした際に、前記ネットワークを介して必要な情報伝送を行うことにより決済が行われるようにしたことを特徴とするクレジットカードを用いた決済処理方法。 - 請求項1〜7のいずれかに記載の決済処理方法において、
ユーザ用情報処理装置を、ICカードと、このICカードに対する情報伝送を行うリーダライタ装置と、このリーダライタ装置を介してICカードへのアクセスを行うコンピュータと、によって構成し、少なくとも決済処理を行う際に、前記ICカードを前記リーダライタ装置に装着し、前記コンピュータによってアクセスを行うことにより、ユーザ用情報処理装置としての機能を実現させるようにしたことを特徴とするクレジットカードを用いた決済処理方法。 - 請求項8に記載の決済処理方法において、
少なくとも、決済識別コードを発生させるためのアルゴリズムをICカード内のメモリに格納し、決済識別コードの発生処理を、ICカード内において実行することを特徴とするクレジットカードを用いた決済処理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000352759A JP4942245B2 (ja) | 2000-11-20 | 2000-11-20 | クレジットカードを用いた決済処理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000352759A JP4942245B2 (ja) | 2000-11-20 | 2000-11-20 | クレジットカードを用いた決済処理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002157421A JP2002157421A (ja) | 2002-05-31 |
JP4942245B2 true JP4942245B2 (ja) | 2012-05-30 |
Family
ID=18825605
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000352759A Expired - Fee Related JP4942245B2 (ja) | 2000-11-20 | 2000-11-20 | クレジットカードを用いた決済処理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4942245B2 (ja) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002312707A (ja) * | 2001-04-13 | 2002-10-25 | Dainippon Printing Co Ltd | クレジットカードを用いた決済処理方法 |
CN105825371A (zh) | 2015-01-07 | 2016-08-03 | 阿里巴巴集团控股有限公司 | 业务处理方法和装置 |
US11935044B2 (en) | 2018-08-09 | 2024-03-19 | SSenStone Inc. | System, method and program for providing financial transaction by virtual code, virtual code generator and virtual code verification device |
KR102005549B1 (ko) * | 2018-08-09 | 2019-07-30 | 주식회사 센스톤 | 가상코드 기반의 금융거래제공시스템, 가상코드생성장치, 가상코드검증장치, 가상코드 기반의 금융거래제공방법 및 가상코드 기반의 금융거래제공프로그램 |
KR102005554B1 (ko) | 2018-08-09 | 2019-07-30 | 주식회사 센스톤 | 공카드를 이용한 금융거래제공방법 및 시스템 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH05347616A (ja) * | 1992-06-15 | 1993-12-27 | Hitachi Ltd | グループ暗号通信方法およびグループ暗号通信システム |
JP3497936B2 (ja) * | 1995-01-20 | 2004-02-16 | 松下電器産業株式会社 | 個人認証方法 |
JPH10105612A (ja) * | 1996-10-01 | 1998-04-24 | Fujitsu Ltd | 認証システム |
JP3385906B2 (ja) * | 1997-04-23 | 2003-03-10 | オムロン株式会社 | 取引処理システム、および、ホスト装置 |
JPH11272761A (ja) * | 1998-03-18 | 1999-10-08 | Toshiba Corp | 決済システム、決済方法、及び記録媒体 |
JP2000076336A (ja) * | 1998-08-31 | 2000-03-14 | Fujitsu Ltd | 電子決済認証システム及び電子商取引サービスプロバイダ装置 |
US6738749B1 (en) * | 1998-09-09 | 2004-05-18 | Ncr Corporation | Methods and apparatus for creating and storing secure customer receipts on smart cards |
JP2000315227A (ja) * | 1999-04-30 | 2000-11-14 | Kichinosuke Nagashio | インターネット通販システム |
-
2000
- 2000-11-20 JP JP2000352759A patent/JP4942245B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2002157421A (ja) | 2002-05-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110945554B (zh) | 注册表区块链架构 | |
US11887077B2 (en) | Generating exchange item utilization solutions in an exchange item marketplace network | |
US11847621B2 (en) | Systems and methods for math-based currency escrow transactions | |
US20230042977A1 (en) | Encrypting a portion of a block of an exchange item transactions chain | |
US6938019B1 (en) | Method and apparatus for making secure electronic payments | |
US11461783B2 (en) | Merchant verification in an exchange item marketplace network | |
EP3485448B1 (en) | Digital asset distribution by transaction device | |
US5883810A (en) | Electronic online commerce card with transactionproxy number for online transactions | |
US10621592B2 (en) | Methods for authenticating a products | |
US7725403B2 (en) | Method and system to verify a transaction | |
US20120246075A1 (en) | Secure electronic payment methods | |
WO2017223303A1 (en) | Determining exchange item compliance in an exchange item marketplace network | |
US6941282B1 (en) | Methods and systems for carrying out directory-authenticated electronic transactions including contingency-dependent payments via secure electronic bank drafts | |
JP2003099693A (ja) | 電子決済方法 | |
US20210158339A1 (en) | A method of facilitating transactions between users | |
US20230009639A1 (en) | Decentralized computer systems and methods for loyalty points payments using distributed ledgers | |
CN102770881A (zh) | 验证机制 | |
EP1334440A1 (en) | A computerized method and system for a secure on-line transaction using cardholder authentication | |
JP4942240B2 (ja) | クレジットカードを用いた決済処理方法 | |
JPH1063884A (ja) | 電子チケットシステムおよび該システムを用いた電子チケットの利用方法 | |
US20030061486A1 (en) | Electronic commerce information processing system and method | |
JP2001216360A (ja) | 予約証明証発行装置および方法 | |
JP2004126898A (ja) | 認証および決済システム | |
JP2008004042A (ja) | 電子商取引方法 | |
JP4942245B2 (ja) | クレジットカードを用いた決済処理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070730 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20091201 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100129 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20100330 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120228 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150309 Year of fee payment: 3 |
|
LAPS | Cancellation because of no payment of annual fees |