JP4942245B2 - クレジットカードを用いた決済処理方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、クレジットカードを用いた決済処理方法に関し、特に、インターネット上の仮想ショッピングモールでの買い物の決済を行うのに適したクレジットカードを用いた決済処理方法に関する。
【０００２】
【従来の技術】
近年のクレジットカードの普及はめざましく、最近では、１人のユーザが複数のクレジットカードを所持することも一般化しつつある。クレジットカードを利用すれば、現金を取り扱う必要がないため、ユーザと加盟店との双方に大きなメリットが得られ、クレジットカードの利用は、今後も益々普及してゆくものと予想される。クレジットカードを用いた決済処理は、古くは加盟店でクレジット決済用の伝票を作成し、この伝票をクレジットカード会社へ送る方法が採られていたが、最近は、各加盟店に設置された端末装置とクレジットカード会社の管理するホストコンピュータとをオンライン接続し、オンラインで情報のやりとりを行う方法が主流となってきている。
【０００３】
ここ数年来のインターネットの爆発的な普及により、インターネット上の仮想ショッピングモールでの買い物の決済にも、クレジットカードを用いるのが一般的になってきている。この場合、ユーザはパソコンや携帯型端末装置から個々の加盟店の仮想ショッピングモールのＷｅｂページにアクセスし、Ｗｅｂブラウザの画面上で所望の商品を選択した上で、当該商品の代金をクレジットカードで決済することになる。クレジットカードによる決済を行う際には、ユーザの氏名、クレジットカード番号、有効期限といった情報を加盟店側に伝える必要があるので、通常は、Ｗｅｂブラウザの画面上でこれらの各情報を入力し、インターネットを介して、加盟店のＷｅｂページを運営しているサイトのサーバ装置に送信する処理が行われる。加盟店は、ユーザから送信されてきたこれらの情報に、決済対象となる金額の情報を加えて、クレジットカード会社側のホストコンピュータに決済要求を出すことになる。クレジットカード会社側では、加盟店からの決済要求を受けたら、加盟店側から送信されてきたユーザの氏名、クレジットカード番号、有効期限を、ホストコンピュータ内の登録データと照合し、問題がなければ決済要求を承認する。
【０００４】
このように、クレジットカード会社では、基本的には、ユーザの氏名、クレジットカード番号、有効期限を照合して決済を行うので、これらの情報が犯罪者に盗まれると、悪用されるおそれがある。特に、インターネットの黎明期においては、ユーザがＷｅｂブラウザから送信したこれらの情報が、途中で不正に盗まれる事件が多発し、大きな社会問題となっていた。このような問題に対処するため、インターネット経由の情報送信のセキュリティを高める技術が開発されてきている。たとえば、現在では、ＳＳＬ（Secure Sockets Layer）と呼ばれるＴＣＰ／ＩＰ通信のセキュリティを確保するためのプロトコルが一般的に利用されており、このプロトコルにより送信した情報に対しては、実用上、十分なセキュリティを確保することが可能である。
【０００５】
【発明が解決しようとする課題】
このように、クレジットカードのユーザ氏名、番号、有効期限といった情報は、犯罪者の手に渡ると悪用されるおそれがある重要な情報であり、取り扱いには十分に注意する必要がある。もっとも、インターネット上の仮想ショッピングモールでの買い物の決済を、クレジットカードを用いて行う場合でも、上述のＳＳＬなどの技術を利用してこれらの情報を送信すれば、一応、送信経路上で情報が盗まれるような被害は未然に防ぐことができる。しかしながら、これまでのクレジットカードに対するセキュリティ対策は、加盟店自身が不正な行為をすることはない、ということを大前提としたものであり、加盟店自身が不正行為を働いた場合には、全く機能しないという問題を含んでいる。そもそも加盟店は、クレジットカード会社による厳密な審査により、十分に信頼がおける企業であるとの判断がなされた店であり、これまでは加盟店自身が不正行為をなすという事態は全く想定されていない。しかし、インターネット上のビジネスなどが普及すればするほど、クレジットカードの加盟店も多種多様となり、加盟店自身による不正行為、あるいはその従業者による不正行為が行われる可能性も高まってきている。加盟店のもとには、多数のユーザに関する氏名、クレジットカード番号、有効期限といった情報が集まるので、万一、これらの情報を不正に取得して横流しをするような従業者がいた場合には、ＳＳＬなどの技術により通信セキュリティを確保しても無力である。
【０００６】
このような問題点を解決するために、公開鍵暗号技術を利用したＳＥＴ（Secure Electronic Transaction ）なる決済方法が大手クレジットカード会社から提案され、現在、システムの実験が行われているが、かなり大掛かりなシステムが必要になるため、実用化には至っていない。
【０００７】
そこで本発明は、各加盟店に対するセキュリティを十分に確保することが可能なクレジットカードを用いた新規な決済処理方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
(1) 本発明の第１の態様は、クレジットカード会社から、所定のクレジットカード番号が付与されたクレジットカードの発行を受けたユーザが、当該クレジットカードの加盟店に対して当該クレジットカードを用いて決済を行う際の決済処理方法において、
ユーザが利用するユーザ用情報処理装置と、決済相手となる加盟店が管理する加盟店用情報処理装置と、を接続し、ユーザが加盟店に対して特定の決済事項に関する処理を１処理手続として行う際に、
加盟店用情報処理装置が、特定の決済事項に関する１処理手続に対応したコードであって、「すべての加盟店における加盟店用情報処理装置で発生させるすべてのセッション識別コードが、互いに異なるユニークなコードになる」という条件をもったセッション識別コードを発生させ、このセッション識別コードをユーザ用情報処理装置に送信する第１の段階と、
ユーザ用情報処理装置が、第１の段階によって送信されてきたセッション識別コードと予め格納されていたクレジットカード番号との少なくとも２つの情報に基づいてユーザ側演算対象データを作成し、このユーザ側演算対象データに対して、ＨＡＳＨ関数もしくはその他の非可逆的な関数を作用させる演算処理を行うことにより一義的に決定される決済識別コードを発生させ、少なくとも、この決済識別コードと予め格納されていたユーザの氏名とを、第１の段階の送信に対する返信として、加盟店用情報処理装置に送信する第２の段階と、
クレジットカードによる決済を承認する権限をもった承認業者が管理する承認業者用情報処理装置と、加盟店用情報処理装置と、を接続し、加盟店が承認業者に対して特定の決済事項に関する処理を１処理手続として行う際に、
加盟店用情報処理装置が、少なくとも、上記特定の決済事項に関して決定した決済金額と、第１の段階で発生させたセッション識別コードと、このセッション識別コードの送信に対する返信として第２の段階で送信されてきた決済識別コードおよび氏名とを、承認業者用情報処理装置へ送信することにより当該決済金額についての決済要求を出す第３の段階と、
承認業者用情報処理装置が、予めデータベースとして用意されているクレジットカードの会員名簿の中から、第３の段階によって送信されてきた氏名と同姓同名のユーザに関するクレジットカード番号を検索し、第３の段階によって送信されてきたセッション識別コードと、検索されたｎ個（ｎは自然数）のクレジットカード番号のそれぞれと、の少なくとも２つの情報に基づいて、ユーザ側演算対象データと同一構成の承認業者側演算対象データをｎ通り作成し、このｎ通りの承認業者側演算対象データに対して、第２の段階で行った演算処理と同一の演算処理を行うことによりｎ通りの決済識別コードを求め、このｎ通りの決済識別コードの中に、第３の段階によって送信されてきた決済識別コードに一致するコードが存在した場合に、当該一致をもたらしたクレジットカード番号に対応する会員を決済主体となる特定のユーザと認識し、当該一致が得られることを第１の条件とし、第３の段階で送信されてきた決済識別コードが、上記特定のユーザに関して過去に行われた決済処理で用いられた決済識別コードとは異なることを第２の条件とし、これら２条件がともに満たされた場合に、当該特定のユーザに関して決済要求に対する承認を行う第４の段階と、
を有し、第２の段階において、ユーザ用情報処理装置から加盟店用情報処理装置に対して、クレジットカード番号自体の送信は行わないようにしたものである。
【００１２】
(2) 本発明の第２の態様は、上述の第１の態様に係るクレジットカードを用いた決済処理方法において、
セッション識別コードを発生させる際に、決済日、決済時、セッション番号もしくはこれらの組合せを利用するようにしたものである。
【００１３】
(3) 本発明の第３の態様は、上述の第１または第２の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ側演算対象データおよび承認業者側演算対象データとして、時期に応じて内容が変化するマジックコードを含ませるようにしたものである。
【００１４】
(4) 本発明の第４の態様は、上述の第１〜第３の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ側演算対象データおよび承認業者側演算対象データとして、決済日、決済時、もしくは決済日時を示すコードを含ませるようにしたものである。
【００１５】
(5) 本発明の第５の態様は、上述の第１〜第４の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ側演算対象データおよび承認業者側演算対象データとして、クレジットカードの有効期限を示すコードを含ませるようにしたものである。
【００１８】
(6) 本発明の第６の態様は、上述の第１〜第５の態様に係るクレジットカードを用いた決済処理方法において、
ユーザが複数のクレジットカード会社からそれぞれクレジットカードの発行を受けているときに、ユーザ用情報処理装置内に、個々のクレジットカードについての各クレジットカード番号をそれぞれ格納しておき、
決済を行うときに、ユーザに特定のクレジットカードを指定する入力を行わせ、指定されたクレジットカードに対応するクレジットカード番号を用いて、ユーザ側演算対象データを作成するようにしたものである。
【００１９】
(7) 本発明の第７の態様は、上述の第１〜第６の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置、加盟店用情報処理装置、承認業者用情報処理装置を、それぞれネットワークを介して接続し、加盟店のＷｅｂページ上に開かれた仮想ショッピングモールでユーザが買い物をした際に、ネットワークを介して必要な情報伝送を行うことにより決済が行われるようにしたものである。
【００２１】
(8) 本発明の第８の態様は、上述の第１〜第７の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置を、ＩＣカードと、このＩＣカードに対する情報伝送を行うリーダライタ装置と、このリーダライタ装置を介してＩＣカードへのアクセスを行うコンピュータと、によって構成し、少なくとも決済処理を行う際に、ＩＣカードをリーダライタ装置に装着し、コンピュータによってアクセスを行うことにより、ユーザ用情報処理装置としての機能を実現させるようにしたものである。
【００２２】
(9) 本発明の第９の態様は、上述の第８の態様に係るクレジットカードを用いた決済処理方法において、
少なくとも、決済識別コードを発生させるためのアルゴリズムをＩＣカード内のメモリに格納し、決済識別コードの発生処理を、ＩＣカード内において実行するようにしたものである。
【００２４】
【発明の実施の形態】
以下、本発明を図示する実施形態に基づいて説明する。
【００２５】
§１．インターネット上での従来の一般的な決済処理方法
はじめに、インターネット上の仮想ショッピングモールで買い物をする場合の従来の一般的なクレジットカードによる決済処理方法の手順を説明する。図１は、この手順を示すブロック図である。この例では、ユーザ用情報処理装置１００、加盟店用情報処理装置２００、承認業者用情報処理装置３００がインターネット４００を介して接続される。ユーザ用情報処理装置１００は、ユーザの管理下にある情報処理装置であり、一般的には、インターネット４００に接続する機能を有するパソコンや携帯型情報端末装置がユーザ用情報処理装置１００として利用されている。加盟店用情報処理装置２００は、クレジットカードの加盟店によって管理されている情報処理装置であり、一般的には、仮想ショッピングモールのＷｅｂページのサイトを提供するＷｅｂサーバ装置が加盟店用情報処理装置２００として利用されることになる。承認業者用情報処理装置３００は、クレジットカードによる決済を承認する権限をもった承認業者（クレジットカード会社自身もしくはその委託を受けた特定の業者）によって管理される情報処理装置であり、通常は、比較的大規模なホストコンピュータによって構成される。
【００２６】
ユーザは、クレジットカード会社からクレジットカード１０の発行を受けており、このクレジットカード１０には、ユーザの氏名Ｎ、クレジットカード番号Ｃ、有効期限Ｄなる情報が記載されている（通常、エンボス加工によって刻まれている）。もちろん、クレジットカードによっては、この他にも種々の情報が記載されている場合がある。一方、このクレジットカード１０上に記載された情報は、承認業者用情報処理装置３００内のデータベースにも登録されている。このデータベースには、更に、各ユーザの住所、電話番号、勤務先、過去の決済履歴などのデータも格納されている。
【００２７】
加盟店が運営する仮想ショッピングモールを利用するには、ユーザは、ユーザ用情報処理装置１００のＷｅｂブラウザ機能を用いて、加盟店用情報処理装置２００内のサイトの所定のＷｅｂページにアクセスすればよい。いま、ユーザが、このＷｅｂページ上で所望の商品を購入し、クレジットカード１０を利用してその代金を決済する場合を考えよう。この場合、ユーザは手元にクレジットカード１０を用意し、Ｗｅｂ画面上で、氏名Ｎ、クレジットカード番号Ｃ、有効期限Ｄなる情報をキーボードなどを用いて入力する。入力したこれらの情報は、インターネット４００を介して、加盟店用情報処理装置２００へと送信される。通常、この送信処理は、ＳＳＬなどのセキュリティが確保されたプロトコルにより行われるため、インターネット４００の伝送経路上でこれらの情報が盗まれる可能性は非常に小さい。こうして、加盟店用情報処理装置２００に、ユーザが送信したこれらの情報が到達すると、今度は、加盟店が、自己の店名や決済金額Ｐなどの情報を付加して、これらの情報をインターネット４００を介して（場合によっては、別な通信線を介して）、承認業者用情報処理装置３００へと送信して承認を求める。承認業者は、承認業者用情報処理装置３００内のデータベースに登録されている情報と、加盟店から送信されてきた情報とを照合し、問題がなければ当該決済を承認することになる。
【００２８】
結局、クレジットカード１０上の氏名Ｎ，クレジットカード番号Ｃ，有効期限Ｄという情報は、ユーザ用情報処理装置１００から加盟店用情報処理装置２００へと送信され、更に、加盟店用情報処理装置２００から承認業者用情報処理装置３００へと送信されることになる。このような送信経路におけるセキュリティは、前述したように、ＳＳＬなどの技術によって実用上十分なレベルまで確保されている。しかしながら、このようなセキュリティ対策は、加盟店自身が不正な行為をすることはない、ということを大前提としたものである。加盟店用情報処理装置２００内には、多数のユーザのクレジットカードに関する情報が蓄積されており、万一、これらの蓄積情報を不正に取得して横流しをするような従業者が加盟店内にいた場合、クレジットカード情報に対するセキュリティ対策は根底から覆されてしまう。本発明は、このような問題を解決するための新たな決済処理方法を提案するものである。
【００２９】
§２．本発明に係る決済処理方法の基本概念
続いて、図２のブロック図を参照しながら、本発明に係るクレジットカードを用いた決済処理方法の基本概念を説明する。この図２に示す例は、図１に示す例と同様に、ユーザ、加盟店、承認業者の三者間での決済処理の手順を示しているが、ここでは、多数のユーザのうちの第ｎ番目のユーザという意味で、特定のユーザＵｎが決済処理を行う場合の処理手順を示すことにする。図に示す各符号のサフィックス「ｎ」は、この第ｎ番目のユーザについての情報であることを示すものである。また、ここでは、多数の加盟店のうちの第ｍ番目の加盟店という意味で、特定の加盟店Ｓｍに対する決済処理手順を示すことにする。図に示す各符号のサフィックス「ｍ」は、この第ｍ番目の加盟店についての情報であることを示すものである。結局、以下に説明する決済処理は、ユーザＵｎが加盟店Ｓｍに対して、特定の決済事項に関する処理を１処理手続（以下、１セッションと呼ぶ）として行う場合の処理を示していることになる。なお、ここでは、第ｍ番目の加盟店が個々のユーザとの間で行う特定の決済事項に関する１処理手続（すなわち、セッション）に、一連のシリアル番号ｉを付して示すことにする（以下、これをセッション番号ｉと呼ぶ）。図に示す各符号のサフィックス「ｉ」は、第ｉ番目のセッションについての情報であることを示すものである。
【００３０】
図１に示す例と同様に、この図２の例でも、ユーザ用情報処理装置１００、加盟店用情報処理装置２００、承認業者用情報処理装置３００がインターネット４００を介して接続される。やはり、ユーザ用情報処理装置１００は、ユーザの管理下にある情報処理装置であり、一般的には、インターネット４００に接続する機能を有するパソコンや携帯型情報端末装置がユーザ用情報処理装置１００として利用されることになる。ただ、実用上は、後に§３で述べるように、ＩＣカードをユーザ用情報処理装置１００の一部として利用するのが好ましい。加盟店用情報処理装置２００は、前述したように、クレジットカードの加盟店によって管理されている情報処理装置であり、仮想ショッピングモールのＷｅｂページのサイトを提供するＷｅｂサーバ装置によって構成される。また、承認業者用情報処理装置３００は、前述したように、承認業者によって管理される比較的大規模なホストコンピュータによって構成され、各ユーザに関する種々の情報をデータベースとして格納する機能を有している。
【００３１】
この図２に示す決済処理方法は、あくまでもクレジットカードを用いた決済処理方法であり、その点では、図１に示す従来の決済処理方法と同じである。すなわち、第ｎ番目のユーザＵｎは、クレジットカード会社から予めクレジットカード１０の発行を受けており、このクレジットカード１０には、ユーザの氏名Ｎｎ、クレジットカード番号Ｃｎ、有効期限Ｄｎなる情報が記載されている。ただし、従来の決済処理方法では、加盟店側にこれらの各情報を知らせる必要があるが、本発明に係る決済処理方法では、その必要がなくなる。以下、この決済処理方法の基本概念を説明する。
【００３２】
いま、第ｎ番目のユーザＵｎが、ユーザ用情報処理装置１００のＷｅｂブラウザ機能を利用して、第ｍ番目の加盟店Ｓｍが管理する加盟店用情報処理装置２００内のサイトにおけるショッピングモールにアクセスして所望の商品を購入し、クレジットカード１０を利用してその代金を決済する場合を考える。この場合、加盟店用情報処理装置２００は、１セッションとして決済処理の手続きを行うことになるが、ここでは、このセッションが第ｉ番目のセッションであったとしよう。まず、加盟店用情報処理装置２００は、この第ｉ番目のセッションに固有のセッション識別コードＳＥＳ（ｍ，ｉ）を発生させる。本発明で用いられるセッション識別コードは、特定の決済事項に関する１処理手続（１セッション）に対応したコードであって、少なくとも同一ユーザに関しては、各処理手続ごとに毎回異なるユニークなコードになるという条件をもったコードである。図示されているセッション識別コードＳＥＳ（ｍ，ｉ）は、第ｍ番目の加盟店Ｓｍについての第ｉ番目のセッションに対応して発生されたコードであることを示している。
【００３３】
セッション識別コードは、上述したように、少なくとも同一ユーザに関しては、各処理手続ごとに毎回異なるユニークなコードになる、という条件をもったコードであれば、どのようなコードを発生させてもかまわない。別言すれば、異なるユーザに対しては、同一のセッション識別コードを発生させてもかまわない。ただ、実用上は、少なくとも、同一の加盟店における加盟店用情報処理装置２００で発生させるすべてのセッション識別コードが、互いに異なるユニークなコードになる、という条件下で、セッション識別コードを発生させた方が好ましい。これは、同一の加盟店で発行したセッション識別コードがすべて異なるようにしておけば、セッション識別コードとこれを発行した加盟店さえ特定できれば、どの加盟店がどのセッションのために当該セッション識別コードを発行したのかを一義的に決定できるためである。更に好ましくは、すべての加盟店における加盟店用情報処理装置２００で発生させるすべてのセッション識別コードが、互いに異なるユニークなコードになる、という条件下で、セッション識別コードを発生させるとよい。そうすれば、セッション識別コードだけを見れば、どの加盟店がどのセッションのために当該セッション識別コードを発行したのかを一義的に決定できることになる。
【００３４】
このようなユニークなセッション識別コードを発生させるためには、決済日、決済時、セッション番号、もしくはこれらの組合せを利用すると便利である。具体的には、ユーザＵｎからクレジットカードによる決済を行う旨の指示があった時点が、たとえば、２０００年１０月３０日１５時２６分３４秒であったとすると、「２０００／１０／３０／１５／２６／３４」のようなコードをセッション識別コードとして発生させることができる。あるいは、当該加盟店において決済があるたびに、シリアル番号からなるセッション番号を更新してゆくようにし、このセッション番号をセッション識別コードとして利用してもかまわない。もちろん、セッション番号を毎日リセットするようにし、２０００年１０月３０日における第３６５番目のセッションであれば、「２０００／１０／３０／３６５」のようなセッション識別コードを発生させることも可能である。更に、すべての加盟店で発生されたすべてのセッション識別コードをユニークにするのであれば、上述した各セッション識別コードに、個々の加盟店の名前や識別コードを付加したものを用いるようにすればよい。たとえば、第ｍ番目の加盟店Ｓｍの２０００年１０月３０日における第３６５番目のセッションであれば、「ｍ／２０００／１０／３０／３６５」のようなセッション識別コードを発生させることができる。
【００３５】
さて、こうして、第ｍ番目の加盟店が管理する加盟店用情報処理装置２００において、第ｉ番目のセッションについてのセッション識別コードＳＥＳ（ｍ，ｉ）が発生されたら、インターネット４００を介して、これをユーザ用情報処理装置１００へと送信する。ユーザ用情報処理装置１００では、この送信されてきたセッション識別コードＳＥＳ（ｍ，ｉ）と、決済に利用するクレジットカード１０のクレジットカード番号Ｃｎと、の少なくとも２つの情報に基づいて、ユーザ側演算対象データを作成する。図２に示す実施形態の場合、クレジットカード番号Ｃｎを示す数字列に、送信されてきたセッション識別コードＳＥＳ（ｍ，ｉ）を構成する文字列を付加してなるデータを、ユーザ側演算対象データとしている。次に、このユーザ側演算対象データに対して、所定のアルゴリズムＡＲＧに基づく演算処理を行うことにより、決済識別コードＩＤ（ｍ，ｉ）を発生させる。
【００３６】
ここで、決済識別コードＩＤ（ｍ，ｉ）は、クレジットカード番号Ｃｎおよびセッション識別コードＳＥＳ（ｍ，ｉ）を含んだユーザ側演算対象データに所定のアルゴリズムＡＲＧに基づく演算処理を行うことにより一義的に定まるコードである必要があるが、逆に、決済識別コードＩＤ（ｍ，ｉ）に基づいて、クレジットカード番号Ｃｎを知ることはできないようにする必要がある。たとえば、アルゴリズムＡＲＧを秘密にしておけば、決済識別コードＩＤ（ｍ，ｉ）に基づいて、クレジットカード番号Ｃｎを求めることはできないので、秘密のアルゴリズムＡＲＧを用いた所定の演算を利用すれば、このような目的は達成させることができる。ただ、実用上は、ＨＡＳＨ関数もしくはその他の非可逆的な関数を作用させる演算処理により、決済識別コードＩＤ（ｍ，ｉ）を求めるようにするのが好ましい。ユーザ側演算対象データに対して、ＨＡＳＨ関数などの非可逆的な関数を作用させる演算処理を行って決済識別コードＩＤ（ｍ，ｉ）を求めるようにすれば、必ず一義的な決済識別コードＩＤ（ｍ，ｉ）が求まり、かつ、この決済識別コードＩＤ（ｍ，ｉ）から元のユーザ側演算対象データを算出することは不可能である。このような非可逆的な関数を作用させる演算処理を利用するようにすれば、たとえば、「ＨＡＳＨ関数を作用させる」というアルゴリズムＡＲＧ自体は秘密にしておく必要はないので、秘密管理のための労力が不要になる。
【００３７】
こうして、ユーザ用情報処理装置１００において、決済識別コードＩＤ（ｍ，ｉ）が発生できたら、これをインターネット４００を介して、加盟店用情報処理装置２００へと送信する。結局、加盟店用情報処理装置２００側からユーザ用情報処理装置１００側に、セッション識別コードＳＥＳ（ｍ，ｉ）が送信され、これに対する返信として、ユーザ用情報処理装置１００側から加盟店用情報処理装置２００側に、決済識別コードＩＤ（ｍ，ｉ）が戻されることになる。なお、本実施形態では、ユーザ用情報処理装置１００側から加盟店用情報処理装置２００側には、図示のとおり、ユーザＵｎの氏名Ｎｎも送信されるようにしている。この氏名Ｎｎの送信は、本発明に係る決済処理を実行する上で必須の事項ではないが、後述するように、承認業者用情報処理装置３００における承認処理が円滑に行われるようにするために、実用上は、氏名Ｎｎの送信を行うのが好ましい。また、通常は、加盟店ＳｍからユーザＵｎに商品の発送などのサービスを提供する上でも、加盟店Ｓｍ側にユーザＵｎの氏名Ｎｎを通知しておく必要がある。
【００３８】
さて、図１で説明したように、従来の方法では、ユーザＵｎは、加盟店用情報処理装置２００に対して、氏名Ｎｎ，クレジットカード番号Ｃｎ，有効期限Ｄｎを送信する必要があったが、本実施形態に係る方法では、氏名Ｎｎと決済識別コードＩＤ（ｍ，ｉ）とを送信すれば足りる。有効期限Ｄｎについては、送信しても特に問題はないが、クレジットカード番号Ｃｎについては、加盟店側に送信を行うと、加盟店側に悪意をもった従業員などがいた場合に不正利用が行われる可能性があり、セキュリティの面で問題が生じることになる。本発明に係る方法では、加盟店側には、クレジットカード番号Ｃｎは一切知らされないので、このような問題は生じない。
【００３９】
続いて、加盟店用情報処理装置２００は、承認業者用情報処理装置３００に対して、当該セッションについての決済金額Ｐ（ｍ，ｉ）についての決済要求を出すことになるが、このとき、承認業者用情報処理装置３００に対しては、少なくとも、ユーザ用情報処理装置１００から送信されてきた決済識別コードＩＤ（ｍ，ｉ）と、先程発生させたセッション識別コードＳＥＳ（ｍ，ｉ）と、当該セッションについての決済金額Ｐ（ｍ，ｉ）と、を送信すればよい。もっとも、実用上は、これに更に、ユーザＵｎの氏名Ｎｎを送信するのが好ましい。
【００４０】
このような決済要求を受けた承認業者用情報処理装置３００は、次のような方法で、この決済要求に対する２つの条件判断を行い、この２つの条件がともに満たされていた場合に、当該決済要求に対する承認を行う。すなわち、まず、加盟店用情報処理装置２００から送信されてきた氏名Ｎｎに着目し、データベースとして用意されているクレジットカードの会員名簿の中から、この氏名Ｎｎと同姓同名の会員を検索する。氏名Ｎｎによっては、唯一の会員が検索される場合もあるし、多数の同姓同名の会員が検索される場合もある。ここでは、たとえば７名の同姓同名の会員が検索されたものとしよう。クレジットカードの会員名簿には、各会員のクレジットカード番号のデータも用意されているので、この７名の会員について、ユーザ側演算対象データと同一構成の承認業者側演算対象データを作成する。具体的には、ここで述べる実施形態の場合、クレジットカード番号にセッション識別コードを付加することによりユーザ側演算対象データが作成されていたので、全く同様に、この７名のクレジットカード番号にそれぞれセッション識別コードを付加することにより、７通りの承認業者側演算対象データを作成する。そして、この７通りの承認業者側演算対象データのそれぞれに対して、ユーザ用情報処理装置１００側で行った所定のアルゴリズムＡＲＧに基づく演算処理を施す。ここで述べる実施形態の場合、７通りの承認業者側演算対象データのそれぞれに対して、ＨＡＳＨ関数を作用させて所定のコードを得る。
【００４１】
こうして得られた７通りのコードのうち、加盟店用情報処理装置２００から送信されてきた決済識別コードＩＤ（ｍ，ｉ）と同一のコードが存在すれば、当該一致をもたらしたクレジットカード番号に対応する会員が、当該セッションにおける決済主体となるユーザＵｎであると特定することができる。別言すれば、当該ユーザＵｎについては、そのクレジットカード番号Ｃｎとセッション識別コードＳＥＳ（ｍ，ｉ）とにより作成された演算対象データに対して、ユーザ側と承認業者側とで所定のアルゴリズムＡＲＧに基づく演算がそれぞれ別個に行われ、その結果として決済識別コードＩＤ（ｍ，ｉ）がそれぞれ別個に得られ、かつ、これら別個に得られた決済識別コードＩＤ（ｍ，ｉ）が一致したことになる。これは、加盟店用情報処理装置２００側からの決済要求が、正規のクレジットカード会員であるユーザＵｎからの正規の決済要求に基づくものであることを示している。そこで、承認業者用情報処理装置３００は、この決済識別コードＩＤ（ｍ，ｉ）の一致を第１の条件として、このユーザＵｎに関する決済要求に対する承認を行うことができる。
【００４２】
一方、７通りの演算結果のうち、加盟店用情報処理装置２００側から送信されてきた決済識別コードＩＤ（ｍ，ｉ）と一致するものが１つもない場合には、店用情報処理装置２００側からの決済要求は、正規の決済要求ではないものと判断し、これに対する承認は行わないようにする。
【００４３】
このように、承認業者用情報処理装置３００に対して、ユーザＵｎの氏名Ｎｎが伝えられると、承認業者用情報処理装置３００における承認処理が円滑に進行することになる。すなわち、予め、決済主体となる会員の候補を、氏名Ｎｎと同姓同名の会員のみ（上述の例の場合、７名の会員）に限定し、この候補となる会員についてのクレジットカード番号を用いた演算（上述の例の場合、７通りのＨＡＳＨ演算）を行えばすむ。一般に、大手のクレジットカード会社の場合、全会員数は数１００万人のオーダーになるが、同姓同名の候補会員数はたかだか知れた数であり、候補となる会員のクレジットカード番号を用いた演算をすべて行ったとしても、演算負担はそれほど大きなものにはならない。
【００４４】
もっとも、前述したように、本発明を実施する上では、ユーザＵｎの氏名Ｎｎを加盟店用情報処理装置２００および承認業者用情報処理装置３００に送信することは必須要件ではない。すなわち、承認業者用情報処理装置３００側に氏名Ｎｎのデータが送信されなかったとしても、全会員を候補として、クレジットカード番号を用いた演算を行えば、原理的には、演算結果が決済識別コードＩＤ（ｍ，ｉ）に一致した会員を、ユーザＵｎと特定することができる。しかしながら、数１００万人のオーダーになる全会員を候補とする演算負担は膨大なものになるため、実用上は、本実施形態のように、氏名Ｎｎのデータを送信するのが好ましい。また、有効期限Ｄｎのデータを送信することにより、候補となる会員数を絞り込むことも可能である。
【００４５】
このように、承認業者用情報処理装置３００側において、送信されてきた決済要求が正規の決済要求であるとの判断を下すための第１の条件は、予め登録されている多数のユーザのうちの特定のユーザＵｎのクレジットカード番号Ｃｎと、加盟店用情報処理装置２００側から送信されてきたセッション識別コードＳＥＳ（ｍ，ｉ）と、に基づいて承認業者側演算対象データを作成し、この承認業者側演算対象データに対してＨＡＳＨ関数を作用して得られるデータが、加盟店用情報処理装置２００側から送信されてきた決済識別コードＩＤ（ｍ，ｉ）と一致する、という条件である。しかしながら、この第１の条件が満たされたことだけをもって、当該決済要求が正規のものであると判断することでは、完全なセキュリティを確保することができない。なぜなら、加盟店Ｓｍには、第ｉ番目のセッションの結果、ユーザＵｎの氏名Ｎｎ，セッション識別コードＳＥＳ（ｍ，ｉ），決済識別コードＩＤ（ｍ，ｉ）という１セットの情報が知られてしまっているので、加盟店Ｓｍの悪意をもった従業員が、この情報を盗み出して不正利用する可能性があるためである。すなわち、承認業者用情報処理装置３００において、第ｉ番目のセッションに対する決済処理が完了した後に、再び、ユーザＵｎの氏名Ｎｎ，セッション識別コードＳＥＳ（ｍ，ｉ），決済識別コードＩＤ（ｍ，ｉ）という１セットの情報を承認業者用情報処理装置３００に対して送信し、任意の金額についての決済要求を出したとすると、上述した第１の条件判断だけでは、当該決済要求も正規のものであると判断されてしまう。
【００４６】
そこで、承認業者用情報処理装置３００では、次のような第２の条件判断を行う。すなわち、加盟店用情報処理装置２００から送信されてきた決済識別コードＩＤ（ｍ，ｉ）が、第１の条件判断プロセスで決済主体として特定されたユーザＵｎに関して過去に行われた決済処理で用いられた決済識別コードとは異なることを第２の条件とし、この条件が満たされているか否かを判断するのである。もちろん、このような判断を行うためには、決済処理を行うたびに、用いた決済識別コードを記録蓄積しておく必要がある。上述したような不正利用は、この第２の条件判断において検出されるため、当該不正な決済要求は承認されることがない。すなわち、加盟店Ｓｍの悪意をもった従業員が、盗み出した１セットの情報を用いて決済要求を出したとしても、既に、ユーザＵｎの氏名Ｎｎ，セッション識別コードＳＥＳ（ｍ，ｉ），決済識別コードＩＤ（ｍ，ｉ）という１セットの情報を用いた正規の決済処理が１度行われているため、決済識別コードＩＤ（ｍ，ｉ）は、ユーザＵｎに関する過去の決済処理において既に用いられたコードと同一であるとして、第２の条件を満たさず、当該承認は拒絶されることになる。
【００４７】
加盟店用情報処理装置２００において発生させるセッション識別コードを、少なくとも同一ユーザに関しては、各セッションごとに毎回異なるようなコードにするのは、上述した第２の条件判断により、不正利用を防止するために他ならない。一般に、クレジットカード番号は、各クレジットカード会社が相互に調整し合うことにより、世界中の全クレジットカード番号がすべて異なるようなユニークな番号となっている。したがって、ユーザが異なれば、当然、クレジットカード番号も異なる。そこで、少なくとも同一ユーザに関しては、各セッションごとに毎回異なるセッション識別コードを発生させるようにしておけば（同一のユーザＵｎが、同一の加盟店Ｓｍで複数セッションの決済を行った場合に発生させられるセッション識別コードをそれぞれ異ならせるだけでなく、同一のユーザＵｎが、複数の加盟店Ｓｍ，Ｓｋ，…で決済を行った場合に発生させられるセッション識別コードもそれぞれ異ならせるようにしておけば）、図２に示す実施形態において、クレジットカード番号Ｃｎ＋セッション識別コードＳＥＳ（ｍ，ｉ）として与えられるユーザ側演算対象データ（および承認業者側演算対象データ）は、ユニークなものとなる。したがって、このユーザ側演算対象データに基づいて作成される決済識別コードＩＤ（ｍ，ｉ）もユニークなものとなる（実際には、ＨＡＳＨ関数などを用いて決済識別コードを発生させると、ユーザ側演算対象データが異なるにもかかわらず、偶然にも、同一の決済識別コードが生成される可能性もあり、厳密には「ユニーク」とは言えないが、偶然に一致する確率が実用上零と見なせるような設定で決済識別コードの発生を行えば、実用上の問題は生じない）。
【００４８】
また、同一ユーザＵｎに対して、加盟店が異なっていれば、同一のセッション識別コードを発生させることを許すような運用も可能である。たとえば、同一のユーザＵｎが、加盟店Ｓｍで決済を行ったときに発生されるセッション識別コードＳＥＳ（ｍ，ｉ）と、加盟店Ｓｋで決済を行ったときに発生されるセッション識別コードＳＥＳ（ｋ，ｊ）とが同一になったとすると、これらに基づいて作成される決済識別コードＩＤ（ｍ，ｉ）とＩＤ（ｋ，ｊ）とが同一になるが、承認業者用情報処理装置３００に対する決済要求時に、加盟店Ｓｍからの決済要求であるのか、加盟店Ｓｋからの決済要求であるのか、を特定することにより、同一の決済識別コードを、加盟店Ｓｍについての決済識別コードと、加盟店Ｓｋについての決済識別コードとに識別した運用が可能である。ただ、このように、同一の決済識別コードの存在を許すような運用は、無用な混乱を招くおそれがあるため、実用上はあまり好ましくない。
【００４９】
更に、上述の実施形態では、承認業者用情報処理装置３００において、決済要求に対する承認を行うための第２の条件として、「送信されてきた決済識別コードが、特定のユーザに関して過去に行われた決済処理で用いられた決済識別コードとは異なる」という条件を用いているが、決済識別コードがユニークなものであることを確認する代わりに、セッション識別コードがユニークであることを確認する方法を採ることも可能である。この場合は、決済要求に対する承認を行うための第２の条件として、「送信されてきたセッション識別コードを、過去に送信されてきたセッション識別コードと比較した結果、セッション識別コードの発生条件の範囲内でユニークなコードとなっている」という条件を設定すればよい。ここで、「セッション識別コードの発生条件の範囲内でユニーク」としているのは、加盟店用情報処理装置２００におけるセッション識別コードを発生させる際の運用方法に何通りかのバリエーションがあり、承認業者用情報処理装置３００において、セッション識別コードが所定の運用通りの条件で発生されたか否かが確認できればよい、という考え方に基づいている。
【００５０】
たとえば、加盟店用情報処理装置２００においてセッション識別コードを発生させる際に、「すべての加盟店における加盟店用情報処理装置で発生させるすべてのセッション識別コードが、互いに異なるユニークなコードになる」という発生条件を設定したとすれば、承認業者用情報処理装置３００に送信されてきたセッション識別コードは、すべて異なっているはずである。一方、「同一の加盟店における加盟店用情報処理装置で発生させるすべてのセッション識別コードは、互いに異なるユニークなコードになる」という発生条件を設定したとすれば、異なる加盟店で発生されたセッション識別コードであれば、同一のものが存在する可能性があるし、更に、「同一の加盟店において同一のユーザについて発生させるすべてのセッション識別コードは、互いに異なるユニークなコードになる」という発生条件を設定したとすれば、異なるユーザについて発生されたセッション識別コードであれば、同一のものが存在する可能性がある。したがって、承認業者用情報処理装置３００では、加盟店用情報処理装置におけるセッション識別コードの発生条件の範囲内でユニークなものとなっていることを確認すればよい。
【００５１】
以上、本発明を、図２の実施形態に基づいて説明したが、実用上は、ユーザ用情報処理装置１００から加盟店用情報処理装置２００に対して送信される情報には、ユーザＵｎの氏名Ｎｎおよび決済識別コードＩＤ（ｍ，ｉ）だけでなく、ユーザＵｎの住所などの情報や、買い物対象となる商品やその個数などを示すデータも含まれることになるが、このような情報送信についての図示は省略している。また、加盟店用情報処理装置２００から承認業者用情報処理装置３００に対して送信される情報には、加盟店自身を特定する識別コードなどのデータも含まれることになるが、このような情報送信の図示も省略している。
【００５２】
§３．本発明に係る具体的な決済処理方法
続いて、本発明に係るクレジットカードを用いた決済処理方法のより具体的な実施形態を述べる。ここで述べる実施形態の第１の特徴は、ユーザ用情報処理装置１００として、ＩＣカードを利用した点にあり、第２の特徴は、複数のクレジットカードについて適用できるようにした点にある。
【００５３】
図３は、この実施形態で用いられるユーザ用情報処理装置１００の基本構成を示すブロック図である。ここに示す例では、ユーザ用情報処理装置１００は、パソコン１１０、リーダライタ装置１２０、ＩＣカード１３０によって構成されている。ＩＣカード１３０としては、ＣＰＵおよびメモリを内蔵した演算処理機能をもったＩＣカードであれば、どのようなＩＣカードを用いてもかまわない。最近は、磁気カードに代わる携帯型情報記録媒体として、種々のタイプのＩＣカードが普及し始めている。一般に、ＩＣカードは、ソフトウエアをロードすることにより様々な機能を付加することができるので、ＩＣカードを利用して本発明に係る決済処理方法を実施する場合、必ずしも新たな専用のＩＣカードをユーザに配付する必要はない。ユーザが既に何らかのＩＣカードを所持しているのであれば、このＩＣカードに、本発明に係る決済処理方法を実行するための専用ソフトウエアあるいは専用のデータ、またはその両方をロードするだけで、既存のＩＣカードをそのまま利用して本発明を実施することが可能になる。
【００５４】
リーダライタ装置１２０は、このＩＣカード１３０に対する情報伝送を行う汎用の読取／書込装置であり、パソコン１１０は、このリーダライタ装置１２０を介してＩＣカード１３０へのアクセスを行う汎用のコンピュータである。ここ数年来、個人レベルでのパソコン所有率が高まり、かなりのユーザがパソコンを所有し、インターネットへの接続環境を備えている。本発明による決済処理方法を利用する場合、このような汎用のパソコン１１０に、汎用のリーダライタ装置１２０を接続し、所定のソフトウエアをロードしたＩＣカード１３０を用意すればよい。このＩＣカード１３０をリーダライタ装置１２０に装着し、パソコン１１０によってアクセスを行うようにすれば、このシステムが全体として、§２で述べたユーザ用情報処理装置１００として機能することになる。
【００５５】
このように、本実施形態では、パソコン１１０，リーダライタ装置１２０，ＩＣカード１３０からなるシステムによって、ユーザ用情報処理装置１００が構成されることになるが、実質的には、ＩＣカード１３０がユーザ用情報処理装置１００としての主たる機能を果たし、パソコン１１０およびリーダライタ装置１２０は、このＩＣカード１３０をインターネット４００へ接続するためのインターフェイスとしての役割を果たしているにすぎない。すなわち、本発明において重要な機能を果たす情報は、いずれもＩＣカード１３０内に格納されることになる。以下、このＩＣカード１３０内に格納されている情報について説明する。
【００５６】
図３に示すように、ＩＣカード１３０内には、「ＰＲＧ」，「ＡＲＧ」，「ＰＩＮ」，「ＤＡＴＥ」，「ＭＡＧ」なる情報が収容されている。ここで、「ＰＲＧ」は、このＩＣカード１３０を本発明に係るユーザ用情報処理装置１００の主たる構成要素として機能させるためのプログラムであり、§２で述べたユーザ用情報処理装置１００の各機能は、このプログラムの制御のもとに実現されることになる。また、「ＡＲＧ」は、図２に示す演算対象データ（図２の例では、クレジットカード番号Ｃｎ＋セッション識別コードＳＥＳ（ｍ，ｉ））に対して行うべき所定のアルゴリズムに基づく演算処理ルーチンであり、具体的には、たとえばＨＡＳＨ関数などを作用させるアルゴリズムのルーチンということになる。次の「ＰＩＮ」は、このＩＣカード１３０の利用を可能にするためのユーザＵｎ自身の識別コードである。ユーザＵｎは、このＩＣカード１３０をリーダライタ装置１２０に装着した後、パソコン１１０から正しい「ＰＩＮ」コードを入力する作業を行う。入力した「ＰＩＮ」コードは、ＩＣカード１３０内部の「ＰＩＮ」コードと照合され、両者が一致していた場合に、以後のＩＣカード１３０へのアクセスが許可されることになる。この「ＰＩＮ」コードの照合機能は、一般的なＩＣカード１３０には必ず備わっている既存の機能であり、本発明に固有の機能というわけではない。「ＤＡＴＥ」は、現在の日付および時刻を示すデータであり、一般に、外部からＩＣカード１３０に知らされる（ＩＣカードの中では、知らされた日付がシーケンシャルであるかをチェックすることもある。）。また、「ＭＡＧ」はいわゆるマジックコードであり、後述するように、決済識別コードを作成するために利用される。
【００５７】
上述の各情報のうち、「ＰＩＮ」はＩＣカード１３０を利用するための基本的なコードであり、「ＤＡＴＥ」はＩＣカード１３０に対して外部から与えられるデータであるので、いずれも、一般的なＩＣカードに標準的に備わっている情報と言うことができる。これに対して、「ＰＲＧ」，「ＡＲＧ」，「ＭＡＧ」は、本発明の実施のために用意される専用の情報である。ユーザＵｎが既に所有している既存のＩＣカード（たとえば、社員証として機能するＩＣカード、診察券として機能するＩＣカード、サービスポイントを貯めるためのＩＣカードなど、既に種々のＩＣカードが実際に利用されている）を、本発明のためにも流用するというケースの場合は、準備手続として、パソコン１１０から、これら専用の情報「ＰＲＧ」，「ＡＲＧ」，「ＭＡＧ」をＩＣカード１３０側へとロードすればよい。ロード対象となるこれら専用の情報は、ＣＤ−ＲＯＭなどに収容してユーザＵｎに配付してもよいし、インターネット４００を介してパソコン１１０へダウンロードさせるようにしてもよい。もちろん、「ＰＲＧ」，「ＡＲＧ」，「ＭＡＧ」といったデータが予めロードされたＩＣカードを用いて、社員証、診察券、サービスポイントカードなどを発行し、これを配布するようにすれば、これらのデータをロードする処理は不要になる。
【００５８】
準備手続においてユーザＵｎが行う作業は、これら専用の情報をＩＣカード１３０にロードする作業と（上述したように、これらの専用情報が予めロードされたＩＣカードが配布されていた場合は、このロード作業は不要である。）、クレジットカードに関するデータをＩＣカード１３０へ入力する作業である。図３に示す例では、ユーザＵｎが、異なる２つのクレジットカード会社から、それぞれクレジットカードαおよびクレジットカードβなるクレジットカードの発行を受けており、この２枚のクレジットカードの情報をＩＣカード１３０へ入力して利用する例が示されている。このような情報入力は、既にＩＣカード１３０内にロードされているプログラム「ＰＲＧ」の処理機能に基づいて行うことができる。図示の例の場合、クレジットカードαに記載されている氏名αＮｎ，クレジットカード番号αＣｎ，有効期限αＤｎと、クレジットカードβに記載されている氏名βＮｎ，クレジットカード番号βＣｎ，有効期限βＤｎと、をＩＣカード１３０内に書き込む作業が行われることになる（氏名αＮｎと氏名βＮｎとは同一である必要はなく、たとえば、一方を家族名義にしてもかまわない。）。ユーザＵｎは、クレジットカードα，βを手元に置いて、パソコン１１０のキーボードなどから、これらのデータを入力する作業を行う。なお、この例では、更に、利用限度額αＬｎ，βＬｎを入力している。この利用限度額αＬｎ，βＬｎの役目については、§４の変形例のところで述べる。
【００５９】
こうして、各クレジットカードα，βについて、氏名αＮｎ，βＮｎ，クレジットカード番号αＣｎ，βＣｎ，有効期限αＤｎ，βＤｎ，利用限度額αＬｎ，βＬｎの入力作業が完了すると、ユーザＵｎ側の準備手続は完了である。一方、このような準備手続によりＩＣカード１３０内に格納されることになった「ＰＲＧ」，「ＡＲＧ」，「ＭＡＧ」といったデータは、承認業者用情報処理装置３００側にも用意しておく必要がある。これは、ユーザ用情報処理装置１００側と承認業者用情報処理装置３００側とで、決済識別コードを生成するために同一の演算を行う必要があるためである。また、承認業者用情報処理装置３００側には、個々のユーザＵｎについての氏名Ｎｎ，クレジットカード番号Ｃｎ，有効期限Ｄｎ，住所，電話番号などの情報が既にデータベースとして用意されている。
【００６０】
このような準備手続が完了すれば、このＩＣカード１３０自身を、クレジットカードα，βの代用カードとして利用することができるようになる。別言すれば、このＩＣカード１３０は、クレジットカードα，βのいわゆる「子カード」として機能することになる。図３には、２枚のクレジットカードα，βの情報をＩＣカード１３０内に入力した例が示されているが、もちろん、３枚以上のクレジットカードについての情報をＩＣカード１３０内に入力することも可能であり、ユーザＵｎは、このＩＣカード１３０を、多数のクレジットカードの「子カード」として利用することが可能になる。しかも、このＩＣカード１３０は、本質的には、各クレジットカードと同等のカード（同一のクレジットアカウントについてのカード）であるので、ＩＣカード１３０を発行するために、新たに各クレジットカード会社の審査を受ける必要はない。クレジットカード会社によっては、いわゆる 「家族カード」と称するユーザの家族名義の「子カード」を発行するサービスを提供していることがあるが、通常、このような「家族カード」の発行を受けるためには、その旨の申請書をクレジットカード会社に提出し、一応の審査を受ける必要がある。本発明によって発行されるＩＣカード１３０は、このような「家族カード」とは全く性質の異なるカードであり、本質的に元のクレジットカードと同一のアカウントを利用したカードということになるので、発行に際してクレジットカード会社による新たな審査は必要なく、繁雑な事務処理を経ることなしに円滑な発行が可能である。
【００６１】
続いて、このＩＣカード１３０を用いた決済処理の手順を説明する。上述したように、ＩＣカード１３０は、必ずしも本発明に利用する専用のカードにする必要はなく、他の種々の用途に共用することが可能である。ユーザＵｎは、このＩＣカード１３０を、本発明に係る決済処理に利用する場合に、リーダライタ装置１２０に装着すればよい。ユーザＵｎが、パソコン１１０を用いて加盟店の仮想ショッピングモールのＷｅｂページにアクセスし、クレジットカードによる決済を行う場合は、まず、ＩＣカード１３０をリーダライタ装置１２０に装着し、パソコン１１０を用いて「ＰＩＮ」データを入力する。ＩＣカード１３０の内部で「ＰＩＮ」データの照合が完了すると、以下のような一連の決済処理が自動的に実行される。
【００６２】
まず、ユーザＵｎは、どのクレジットカードを用いて決済を行うかを選択する入力を行う。たとえば、ユーザＵｎがクレジットカードαによって決済する旨の選択入力を行うと、ユーザＵｎの氏名αＮｎ（クレジットカードαについて登録されている氏名）がインターネット４００を介して加盟店用情報処理装置２００へと送信される。実際には、この他、ユーザＵｎの住所、電話番号、Ｅメールアドレス、購入した商品や数量を示す情報なども送信されることになる。このような処理は、ＩＣカード１３０内のプログラム「ＰＲＧ」と、加盟店用情報処理装置２００のＷｅｂサーバ内のプログラムの連繋動作によって行われる。
【００６３】
加盟店用情報処理装置２００は、ユーザ用情報処理装置１００側から、これらの情報が送信されてきたら、§２で述べたように、ユニークなセッション識別コードを発生させる。本発明を実施する上で、セッション識別コードは、少なくとも同一ユーザに関しては、各処理手続ごとに毎回異なるユニークなコードが発生できればよいので、ユーザ用情報処理装置１００側から送信されてきたユーザの氏名αＮｎ、住所、電話番号などからユーザＵｎを特定し、少なくとも同一ユーザに関しては、各処理手続ごとに毎回異なるようなセッション識別コードを発生させるようにすればよい。ただ、ここで述べる実施形態では、すべての加盟店において発生されたすべてのセッション識別コードが、互いに異なるユニークなコードとなるように、たとえば、第ｍ１番目の加盟店Ｓｍ１の第ｉ１番目のセッションであれば、ＳＥＳ（ｍ１，ｉ１）なるセッション識別コードを発生させるようにしている。こうして発生されたセッション識別コードＳＥＳ（ｍ１，ｉ１）は、インターネット４００を介して、ユーザ用情報処理装置１００へと送信される。
【００６４】
ユーザ用情報処理装置１００は、送信されてきたセッション識別コードＳＥＳ（ｍ１，ｉ１）を利用して、決済識別コードＩＤ（ｍ１，ｉ１）を発生させる処理を行う。この処理は、図４に示すように、ＩＣカード１３０内において行われる。図２に示す例では、「クレジットカード番号Ｃｎ＋セッション識別コードＳＥＳ（ｍ，ｉ）」をユーザ側演算対象データとして、これに所定のアルゴリズムに基づく演算を施すことにより、決済識別コードＩＤ（ｍ，ｉ）を発生させていたが、ここに述べる実施形態では、図４の左下に示すように、「αＣｎ＋αＤｎ＋ＤＡＴＥ＋ＭＡＧ＋ＳＥＳ（ｍ１，ｉ１）」をユーザ側演算対象データとして、このユーザ側演算対象データに対して所定のアルゴリズムＡＲＧに基づく演算（ＨＡＳＨ関数もしくはその他の非可逆的な関数を作用させる演算）を施すことにより、決済識別コードＩＤ（ｍ１，ｉ１）を発生させている。ここで、αＣｎおよびαＤｎは、準備手続においてＩＣカード１３０へ入力されたクレジットカードαについてのクレジットカード番号および有効期限である。クレジットカード番号αＣｎだけでなく、更に有効期限αＤｎを用いて決済識別コードを発生させることにより、更にセキュリティを高めることができる。
【００６５】
一方、マジックコードＭＡＧは、時期（年、月、日、週、時刻など）に応じて内容が変化する特有のコード（たとえば、任意の文字列）である。たとえば、１月は「松」、２月は「梅」、３月は「桜」、…というように、１２か月分のマジックコードＭＡＧを任意の文字列として定めておき、１月中に行われた決済には「松」なるマジックコードを採用し、２月中に行われた決済には「梅」なるマジックコードを採用する、というような運用を行えば、セキュリティをより向上させることができる。もちろん、月曜日、火曜日、水曜日、…というように曜日ごとに異なるマジックコードを設定することもできるし、偶数日と奇数日とで異なるマジックコードを設定するようなこともできる。このように、時期に応じて内容が変化するコードを演算対象データに含ませてから、決済識別コードＩＤ（ｍ１，ｉ１）を作成すれば、決済識別コードＩＤ（ｍ１，ｉ１）からクレジットカード番号αＣｎを類推することを困難にする上で極めて有効である。
【００６６】
日付／時刻ＤＡＴＥは、決済時点の日付および時刻を示すデータである。たとえば、２０００年１０月３０日午後３：００というようなデータが演算対象データの一部として組み込まれることになる。このようなＤＡＴＥを加えることは、上述したマジックコードＭＡＧを加えることと同様に、決済識別コードＩＤ（ｍ１，ｉ１）からクレジットカード番号αＣｎを類推することを困難にする上で極めて有効である。もちろん、日付／時刻ＤＡＴＥは、必ずしも決済日時を示すコードにする必要はなく、たとえば、２０００年１０月３０日というように決済日のみを含むコードにすることもできるし、午後３：００というように決済時のみを含むコードにすることもできる。また、２０００年１０月３０日午後３時１３分２４．２秒のように、正確な秒までも含むコードにすることも可能であるが、あまり精度の高い時刻コードを用いると、ＩＣカード１３０内で決済識別コードを生成した時刻と、承認業者用情報処理装置３００内で決済識別コードを生成した時刻とが不一致となり、両者の決済識別コードが一致しなくなるおそれがあるので、ＩＣカード１３０側のクロックと承認業者用情報処理装置３００側のクロックとの誤差や、インターネット４００を介しての伝送遅延時間などを考慮して、両者で同一の時刻コードが用いられる範囲内の精度に抑える必要がある。
【００６７】
上述の例は、クレジットカードαで決済を行う場合の処理であるが、クレジットカードβで決済を行う場合には、図４の右下に示すような処理が行われる。すなわち、第ｍ２番目の加盟店から、ＳＥＳ（ｍ２，ｉ２）なるセッション識別コードが送信されてきた場合、「βＣｎ＋βＤｎ＋ＤＡＴＥ＋ＭＡＧ＋ＳＥＳ（ｍ２，ｉ２）」をユーザ側演算対象データとして、このユーザ側演算対象データに対して所定のアルゴリズムＡＲＧに基づく演算（ＨＡＳＨ関数もしくはその他の非可逆的な関数を作用させる演算）を施すことにより、決済識別コードＩＤ（ｍ２，ｉ２）を発生させることになる。ここで、βＣｎおよびβＤｎは、準備手続においてＩＣカード１３０へ入力されたクレジットカードβについてのクレジットカード番号および有効期限である。
【００６８】
なお、ここに示す実施形態では、決済識別コードを発生させるためのアルゴリズムＡＲＧをＩＣカード１３０内のメモリに格納し、決済識別コードの発生処理を、ＩＣカード１３０内において実行するようにしているが、これはセキュリティを更に高めるための配慮である。一般に、ＣＰＵ内蔵型のＩＣカードでは、内部メモリに格納された情報に対して十分なセキュリティが確保されており、図４に示すＩＣカード１３０内の各情報が、不正な手段で外部に読み出される可能性はないと考えてよい。したがって、万一、ユーザＵｎがこのＩＣカード１３０を紛失したとしても、内部に格納された種々の情報が流出するおそれはない。本発明の決済処理に必要な種々の情報を、パソコン１１０側ではなく、ＩＣカード１３０側に格納しているのは、ＩＣカードがこのような高度なセキュリティを備えているからである。
【００６９】
図５は、図４に示すＩＣカード１３０内に格納されている情報に対応して、承認業者用情報処理装置３００内に格納されている情報の一例を示す図である。ここで、「ＰＲＧ」は、承認業者用情報処理装置３００に決済要求に対する承認処理を行わせるためのプログラムであり、「ＡＲＧ」は、ＩＣカード１３０内に格納されているのと同一の演算アルゴリズム（ＨＡＳＨ関数もしくはその他の非可逆的な関数を作用させる演算のアルゴリズム）であり、「ＤＡＴＥ」は、現在の日付／時刻を示すコード（承認業者用情報処理装置３００の内蔵クロックに基づいて生成される）であり、マジックコードＭＡＧは、ＩＣカード１３０内に格納されているのと同一のマジックコードである。また、クレジットカードαあるいはβに関するデータとして、複数のユーザＵ１，Ｕ２，…，Ｕｋ，…に関するデータがそれぞれ格納されている。ここで、たとえば、クレジットカードαに関する第ｋ番目のユーザＵｋのデータとしては、図示のとおり、氏名αＮｋ，クレジットカード番号αＣｋ，有効期限αＤｋ，利用限度額αＬＬｋ，その他、ユーザＵｋの住所や電話番号、決済金額データなどが格納されることになる。
【００７０】
既に§２で述べたように、加盟店用情報処理装置２００から承認業者用情報処理装置３００に対しては、ユーザＵｎの氏名Ｎｎ，決済識別コードＩＤ（ｍ１，ｉ１），セッション識別コードＳＥＳ（ｍ１，ｉ１），決済金額Ｐ（ｍ１，ｉ１），加盟店Ｓｍを示すコードなどのデータを送信することにより決済要求が出される。このような決済要求を受けた承認業者用情報処理装置３００は、上述したように、２つの条件がともに満たされていた場合に、当該決済要求に対する承認を行う。すなわち、まず、加盟店用情報処理装置２００から送信されてきた氏名Ｎｎに着目し、データベースとして用意されているクレジットカードの会員名簿の中から、この氏名Ｎｎと同姓同名の会員を検索する。たとえば７名の同姓同名の会員が検索されたとすると、クレジットカードの会員名簿には、各会員のクレジットカード番号のデータも用意されているので、この７名の会員について、ユーザ側演算対象データと同一構成の承認業者側演算対象データを作成する。
【００７１】
たとえば、第ｋ番目のユーザＵｋについての承認業者側演算対象データは、図５の右下に示すように、「αＣｋ＋αＤｋ＋ＤＡＴＥ＋ＭＡＧ＋ＳＥＳ（ｍ１，ｉ１）」ということになる。この第ｋ番目のユーザＵｋは、第ｎ番目のユーザＵｎと同姓同名であるため、氏名Ｎｋ＝Ｎｎということになるが、クレジットカード番号についてはそれぞれ異なる番号が与えられているので、αＣｋ≠αＣｎということになる。また、有効期限については、偶然の一致がない限り、αＤｋ≠αＤｎである。一方、ＤＡＴＥおよびＭＡＧについては、ユーザ用情報処理装置１００側の演算で用いられたデータと同一のデータが用いられるようにし、ＳＥＳ（ｍ１，ｉ１）は、加盟店用情報処理装置２００から送信されてきたものをそのまま用いるようにする。
【００７２】
こうして、承認業者側演算対象データが作成されたら、これに所定のアルゴリズムＡＲＧに基づく演算を施し、決済識別コードＩＤ（ｍ１，ｉ１）を作成し、加盟店用情報処理装置２００から送信されてきた決済識別コードＩＤ（ｍ１，ｉ１）と一致するか否かを調べる。同姓同名の７名の会員について、このような方法で決済識別コードＩＤ（ｍ１，ｉ１）を作成すれば、第ｎ番目のユーザＵｎについて作成された決済識別コードＩＤ（ｍ１，ｉ１）だけが、送信されてきた決済識別コードＩＤ（ｍ１，ｉ１）と一致することになる。このようにコードの一致が得られれば、当該一致をもたらしたクレジットカード番号に対応する会員が、当該セッションにおける決済主体となるユーザＵｎであると特定することができ、このユーザＵｎに関する決済要求に対する承認を行う上での第１の条件が満たされることになる。
【００７３】
次に、承認業者用情報処理装置３００では、次のような第２の条件判断を行う。すなわち、加盟店用情報処理装置２００から送信されてきた決済識別コードＩＤ（ｍ１，ｉ１）が、決済主体として特定されたユーザＵｎに関して過去に行われた決済処理で用いられた決済識別コードとは異なるか否かを確認する。ユーザＵｎに関して、過去に決済識別コードＩＤ（ｍ１，ｉ１）と同一コードで決済が行われた事実がなければ、第２の条件も満たされたことになり、当該決済要求は承認されることになる。もちろん、§２で述べたように、決済識別コードＩＤ（ｍ１，ｉ１）がユニークであることを確認する代わりに、セッション識別コードＳＥＳ（ｍ１，ｉ１）が発生条件の範囲内でユニークであることを確認してもよい。
【００７４】
§４．いくつかの変形例
最後に、本発明に係るクレジットカードを用いた決済処理方法の変形例をいくつか述べておく。
【００７５】
(1) 図２に示す実施形態では、ユーザ用情報処理装置１００において発生させた決済識別コードＩＤ（ｍ，ｉ）を、加盟店用情報処理装置２００を介して承認業者用情報処理装置３００に送信するようにしているが、決済識別コードＩＤ（ｍ，ｉ）は必ずしも加盟店用情報処理装置２００経由で承認業者用情報処理装置３００へ送信する必要はなく、ユーザ用情報処理装置１００から承認業者用情報処理装置３００に直接送信する（たとえば、インターネット４００を介して、ユーザ用情報処理装置１００から承認業者用情報処理装置３００へ伝達する）ようにしてもかまわない。この場合、承認業者用情報処理装置３００は、加盟店用情報処理装置２００から、ユーザ名Ｎｎ，セッション識別コードＳＥＳ（ｍ，ｉ），決済金額Ｐ（ｍ，ｉ）の送信を受け、ユーザ用情報処理装置１００から決済識別コードＩＤ（ｍ，ｉ）の送信を受けることになるので、両者から送信されてきた情報が、同一のセッションに関する情報であることを認識できるように、何らかの方法で同期をとるような工夫（送信時間を時間的に同期させる方法に限らず、たとえば、何らかの同期用コードを各情報に付加するような方法でもよいし、ユーザ用情報処理装置１００から決済相手の加盟店を識別する情報を送信する方法でもよい）が必要になる。
【００７６】
(2) 図４に示すＩＣカード１３０内には、各クレジットカードα，βの利用限度額αＬｎ，βＬｎが設定されている。一方、図５に示す承認業者用情報処理装置３００内にも、各クレジットカードの各ユーザごとに、クレジットカードの利用限度額（たとえば、クレジットカードαの第ｎ番目のユーザＵｎについては、利用限度額αＬＬｎ）が設定されている。ここで、承認業者用情報処理装置３００側に設定されている利用限度額αＬＬｎは、クレジットカード会社が設定した本来の利用限度額であり、ユーザＵｎは、１か月間に、この利用限度額αＬＬｎを越える決済を行うことはできない（そのような決済要求は否認されることになる）。これに対して、ＩＣカード１３０側に設定されている利用限度額αＬｎ（あるいはβＬｎ）は、準備手続の段階でユーザＵｎ自身が任意に設定できる限度額である。一般的には、αＬｎ＝αＬＬｎというように、クレジットカード会社が設定した利用限度額と同じ額を、ＩＣカード１３０内の利用限度額として設定すればよいが、敢えて、αＬｎ＜αＬＬｎのような設定を行い、無駄遣いを抑えるための自主管理の目的設定に用いることもできる。
【００７７】
利用限度額αＬｎの設定を行った場合、クレジットカードαを用いてこの利用限度額αＬｎを越えるような決済が行われる場合には、その旨の警告が提示されるようにしておく。たとえば、ＩＣカード１３０内に、今月の決済金額の累積値を記録しておくようにし、新たに決済しようとしている金額と、この累積値との合計が、利用限度額αＬｎを越えるような場合には、ＩＣカード１３０内のプログラム「ＰＲＧ」の機能によって、パソコン１１０の画面上に何らかの警告表示を行うようにしておけばよい。αＬｎ＜αＬＬｎなる設定が行われていた場合には、この警告表示を無視して決済を断行することができるようにしておいてもよいし、警告表示が出されたら当該決済は拒絶されるようにしておいてもよい。
【００７８】
(3) 前述の実施形態では、インターネット上の仮想ショッピングモールでの買い物の決済を、インターネット上で行う例について述べたが、本発明に係る決済方法は、必ずしもインターネット決済に限定されるものではない。たとえば、ユーザが実際の店舗に買い物や食事に行って代金を決済する場合、クレジットカードαやβを用いる代わりに、ＩＣカード１３０を用いて決済することも可能である。この場合、当該店舗に設置されたリーダライタ装置１２０にＩＣカード１３０を装着して決済を行えばよい。ＩＣカード１３０は、１枚で複数枚のクレジットカードとして機能することができ、かつ、クレジットカード以外の種々の機能を有しているので、多数のクレジットカードを所持する代わりに、このＩＣカード１３０を１枚だけ所持していれば、すべてのクレジットカードのアカウントを用いた決済が可能になる。このような利用形態では、ＩＣカード１３０を装着したシステムがユーザ用情報処理装置１００として機能することになる。ユーザ用情報処理装置１００は必ずしもユーザの自宅に設置されている必要はなく、上述の利用形態の場合は、店舗に設置されたパソコン１１０およびリーダライタ装置１２０が、ユーザ用情報処理装置１００としての機能を果たしていることになる。
【００７９】
(4) 本発明に係るユーザ用情報処理装置１００は、上述のように、ＩＣカード１３０のような携帯型情報処理装置を利用して実現することができる。ＩＣカードの場合、現在のところ、単独ではインタネットへの接続環境やデータ入力機能が備わっていないため、インターネット上の仮想ショッピングモールにおける決済を行う場合には、上述の実施形態のように、パソコン１１０およびリーダライタ装置１２０と組み合わせた形でユーザ用情報処理装置１００を構成する必要があるが、携帯電話や携帯型情報端末装置など、単独でインターネットに接続する環境をもった装置を利用することができれば、そのような装置を単独でユーザ用情報処理装置１００として用いることにより、インターネット上での決済が可能になる。
【００８０】
【発明の効果】
以上のとおり、本発明に係るクレジットカードを用いた決済処理方法によれば、各加盟店に対するセキュリティを十分に確保することが可能になる。特に、前述した実施形態によれば、次のような種々の効果が得られる。
(1) ＩＣカードを、クレジットカードの「子カード」として利用することになるが、ＩＣカードは十分なセキュリティ対策が施されているため、紛失や盗難という事故が発生しても、本物のクレジットカードに比べて安全性が高い。すなわち、ＩＣカードの内部に格納されたデータを不正な手段で外部に読み出すことは極めて困難であり、また、ＩＣカードの表面にはクレジットカード番号は記載されないので、ＩＣカードを目視しても、クレジットカード番号を認識することはできない。このため、紛失や盗難があっても、クレジットカード番号が第三者に知られる可能性は非常に低くなる。
(2) ＩＣカード製のクレジットが普及するようになるまでには、まだ数年かかると予想されているが、本発明に係る方法では、正式なＩＣカード製クレジットカードを用いる場合に比べて、カードの配布やカード発行のための審査といった作業に手間がかかることはないため、迅速な導入が可能になる。本発明は、特に、インターネットにおいてクレジットショッピングを実施したい場合に有効である。
(3) 本発明では、１枚のＩＣカードに所有者が異なる複数枚のクレジットカードを登録することも可能である。したがって、たとえば、家族全員のクレジットカードの共通の 「子カード」となるようなＩＣカードを作成することも可能になり、柔軟な運用が期待できる。
(4) 「子カード」化されたＩＣカードの中には、必要な情報を記録しておくことができるので、端末装置からキー入力すべきデータ量を低減することができる。すなわち、決済識別コードは、プログラムに基づいて自動的に加盟店へと送られるため、個々のユーザが決済識別コードを入力する必要はない。実用上、ユーザはセッション識別コードや決済識別コードなどの存在すら意識する必要はない。
【図面の簡単な説明】
【図１】インターネット上の仮想ショッピングモールで買い物をする場合の従来の一般的なクレジットカードによる決済処理方法の手順を説明するブロック図である。
【図２】インターネット上の仮想ショッピングモールで買い物をする場合の本発明に係るクレジットカードによる決済処理方法の手順を説明するブロック図である。
【図３】本発明で用いるユーザ用情報処理装置１００をＩＣカード１３０を利用して構成した基本構成を示すブロック図である。
【図４】図３に示すＩＣカード１３０における決済識別コードの発生手順を示す図である。
【図５】図３に示すＩＣカード１３０に格納された情報に対応した、承認業者用情報処理装置３００内の格納情報の一例を示す図である。
【符号の説明】
１０…クレジットカード
１００…ユーザ用情報処理装置
１１０…パソコン
１２０…リーダライタ装置
１３０…ＩＣカード
２００…加盟店用情報処理装置
３００…承認業者用情報処理装置
４００…インターネット
ＡＲＧ…決済識別コード発生用アルゴリズム（ＨＡＳＨ関数など）
Ｃ，Ｃｎ，Ｃｋ…クレジットカード番号
Ｄ，Ｄｎ，Ｄｋ…クレジットカードの有効期限
ＤＡＴＥ…現時点の日付／時刻コード
ＩＤ（ｍ，ｉ）…セッション識別コードＳＥＳ（ｍ，ｉ）に基づいて生成した決済識別コード
ＩＤ（ｍ１，ｉ１）…セッション識別コードＳＥＳ（ｍ１，ｉ１）に基づいて生成した決済識別コード
ＩＤ（ｍ２，ｉ２）…セッション識別コードＳＥＳ（ｍ２，ｉ２）に基づいて生成した決済識別コード
Ｌｎ，ＬＬｎ，ＬＬｋ…利用限度額
ＭＡＧ…マジックコード
Ｎ，Ｎｎ，Ｎｋ…ユーザの氏名
Ｐ…決済金額
Ｐ（ｍ，ｉ）…第ｍ番目の加盟店が生成した第ｉ番目のセッションにおける決済金額
ＰＩＮ…ユーザ識別コード
ＰＲＧ…プログラム
ＳＥＳ（ｍ，ｉ）…第ｍ番目の加盟店が生成した第ｉ番目のセッション識別コード
ＳＥＳ（ｍ１，ｉ１）…第ｍ１番目の加盟店が生成した第ｉ１番目のセッション識別コード
ＳＥＳ（ｍ２，ｉ２）…第ｍ２番目の加盟店が生成した第ｉ２番目のセッション識別コード
Ｕｋ…第ｋ番目のユーザ
Ｕｎ…第ｎ番目のユーザ
α，β…クレジットカード
α○○…クレジットカードαに関する○○
β○○…クレジットカードβに関する○○

Claims (9)

1. クレジットカード会社から、所定のクレジットカード番号が付与されたクレジットカードの発行を受けたユーザが、当該クレジットカードの加盟店に対して当該クレジットカードを用いて決済を行う際の決済処理方法であって、
   ユーザが利用するユーザ用情報処理装置と、決済相手となる加盟店が管理する加盟店用情報処理装置と、を接続し、前記ユーザが前記加盟店に対して特定の決済事項に関する処理を１処理手続として行う際に、
   前記加盟店用情報処理装置が、前記特定の決済事項に関する１処理手続に対応したコードであって、「すべての加盟店における加盟店用情報処理装置で発生させるすべてのセッション識別コードが、互いに異なるユニークなコードになる」という条件をもったセッション識別コードを発生させ、このセッション識別コードを前記ユーザ用情報処理装置に送信する第１の段階と、
   前記ユーザ用情報処理装置が、前記第１の段階によって送信されてきた前記セッション識別コードと予め格納されていた前記クレジットカード番号との少なくとも２つの情報に基づいてユーザ側演算対象データを作成し、このユーザ側演算対象データに対して、ＨＡＳＨ関数もしくはその他の非可逆的な関数を作用させる演算処理を行うことにより一義的に決定される決済識別コードを発生させ、少なくとも、この決済識別コードと予め格納されていた前記ユーザの氏名とを、前記第１の段階の送信に対する返信として、前記加盟店用情報処理装置に送信する第２の段階と、
   前記クレジットカードによる決済を承認する権限をもった承認業者が管理する承認業者用情報処理装置と、前記加盟店用情報処理装置と、を接続し、前記加盟店が前記承認業者に対して前記特定の決済事項に関する処理を１処理手続として行う際に、
   前記加盟店用情報処理装置が、少なくとも、前記特定の決済事項に関して決定した決済金額と、前記第１の段階で発生させたセッション識別コードと、このセッション識別コードの送信に対する返信として前記第２の段階で送信されてきた前記決済識別コードおよび前記氏名とを、前記承認業者用情報処理装置へ送信することにより当該決済金額についての決済要求を出す第３の段階と、
   前記承認業者用情報処理装置が、予めデータベースとして用意されているクレジットカードの会員名簿の中から、前記第３の段階によって送信されてきた前記氏名と同姓同名のユーザに関するクレジットカード番号を検索し、前記第３の段階によって送信されてきた前記セッション識別コードと、検索されたｎ個（ｎは自然数）のクレジットカード番号のそれぞれと、の少なくとも２つの情報に基づいて、前記ユーザ側演算対象データと同一構成の承認業者側演算対象データをｎ通り作成し、このｎ通りの承認業者側演算対象データに対して、前記第２の段階で行った演算処理と同一の演算処理を行うことによりｎ通りの決済識別コードを求め、このｎ通りの決済識別コードの中に、前記第３の段階によって送信されてきた前記決済識別コードに一致するコードが存在した場合に、当該一致をもたらしたクレジットカード番号に対応する会員を決済主体となる特定のユーザと認識し、前記一致が得られることを第１の条件とし、前記第３の段階で送信されてきた前記決済識別コードが、前記特定のユーザに関して過去に行われた決済処理で用いられた決済識別コードとは異なることを第２の条件とし、これら２条件がともに満たされた場合に、当該特定のユーザに関して前記決済要求に対する承認を行う第４の段階と、
   を有し、前記第２の段階において、前記ユーザ用情報処理装置から前記加盟店用情報処理装置に対して、前記クレジットカード番号自体の送信は行わないことを特徴とするクレジットカードを用いた決済処理方法。
2. 請求項１に記載の決済処理方法において、
   セッション識別コードを発生させる際に、決済日、決済時、セッション番号もしくはこれらの組合せを利用することを特徴とするクレジットカードを用いた決済処理方法。
3. 請求項１または２に記載の決済処理方法において、
   ユーザ側演算対象データおよび承認業者側演算対象データとして、時期に応じて内容が変化するマジックコードを含ませることを特徴とするクレジットカードを用いた決済処理方法。
4. 請求項１〜３のいずれかに記載の決済処理方法において、
   ユーザ側演算対象データおよび承認業者側演算対象データとして、決済日、決済時、もしくは決済日時を示すコードを含ませることを特徴とするクレジットカードを用いた決済処理方法。
5. 請求項１〜４のいずれかに記載の決済処理方法において、
   ユーザ側演算対象データおよび承認業者側演算対象データとして、クレジットカードの有効期限を示すコードを含ませることを特徴とするクレジットカードを用いた決済処理方法。
6. 請求項１〜５のいずれかに記載の決済処理方法において、
   ユーザが複数のクレジットカード会社からそれぞれクレジットカードの発行を受けているときに、ユーザ用情報処理装置内に、個々のクレジットカードについての各クレジットカード番号をそれぞれ格納しておき、
   決済を行うときに、ユーザに特定のクレジットカードを指定する入力を行わせ、指定されたクレジットカードに対応するクレジットカード番号を用いて、ユーザ側演算対象データを作成することを特徴とするクレジットカードを用いた決済処理方法。
7. 請求項１〜６のいずれかに記載の決済処理方法において、
   ユーザ用情報処理装置、加盟店用情報処理装置、承認業者用情報処理装置を、それぞれネットワークを介して接続し、加盟店のＷｅｂページ上に開かれた仮想ショッピングモールでユーザが買い物をした際に、前記ネットワークを介して必要な情報伝送を行うことにより決済が行われるようにしたことを特徴とするクレジットカードを用いた決済処理方法。
8. 請求項１〜７のいずれかに記載の決済処理方法において、
   ユーザ用情報処理装置を、ＩＣカードと、このＩＣカードに対する情報伝送を行うリーダライタ装置と、このリーダライタ装置を介してＩＣカードへのアクセスを行うコンピュータと、によって構成し、少なくとも決済処理を行う際に、前記ＩＣカードを前記リーダライタ装置に装着し、前記コンピュータによってアクセスを行うことにより、ユーザ用情報処理装置としての機能を実現させるようにしたことを特徴とするクレジットカードを用いた決済処理方法。
9. 請求項８に記載の決済処理方法において、
   少なくとも、決済識別コードを発生させるためのアルゴリズムをＩＣカード内のメモリに格納し、決済識別コードの発生処理を、ＩＣカード内において実行することを特徴とするクレジットカードを用いた決済処理方法。

Images