JP4942240B2 - クレジットカードを用いた決済処理方法 - Google Patents
クレジットカードを用いた決済処理方法 Download PDFInfo
- Publication number
- JP4942240B2 JP4942240B2 JP2000240878A JP2000240878A JP4942240B2 JP 4942240 B2 JP4942240 B2 JP 4942240B2 JP 2000240878 A JP2000240878 A JP 2000240878A JP 2000240878 A JP2000240878 A JP 2000240878A JP 4942240 B2 JP4942240 B2 JP 4942240B2
- Authority
- JP
- Japan
- Prior art keywords
- credit card
- information processing
- payment
- user
- 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
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、クレジットカードを用いた決済処理方法に関し、特に、インターネット上の仮想ショッピングモールでの買い物の決済を行うのに適したクレジットカードを用いた決済処理方法に関する。
【０００２】
【従来の技術】
近年のクレジットカードの普及はめざましく、最近では、１人のユーザが複数のクレジットカードを所持することも一般化しつつある。クレジットカードを利用すれば、現金を取り扱う必要がないため、ユーザと加盟店との双方に大きなメリットが得られ、クレジットカードの利用は、今後も益々普及してゆくものと予想される。クレジットカードを用いた決済処理は、古くは加盟店でクレジット決済用の伝票を作成し、この伝票をクレジットカード会社へ送る方法が採られていたが、最近は、各加盟店に設置された端末装置とクレジットカード会社の管理するホストコンピュータとをオンライン接続し、オンラインで情報のやりとりを行う方法が主流となってきている。
【０００３】
ここ数年来のインターネットの爆発的な普及により、インターネット上の仮想ショッピングモールでの買い物の決済にも、クレジットカードを用いるのが一般的になってきている。この場合、ユーザはパソコンや携帯型端末装置から個々の加盟店の仮想ショッピングモールのＷｅｂページにアクセスし、Ｗｅｂブラウザの画面上で所望の商品を選択した上で、当該商品の代金をクレジットカードで決済することになる。クレジットカードによる決済を行う際には、ユーザの氏名、クレジットカード番号、有効期限といった情報を加盟店側に伝える必要があるので、通常は、Ｗｅｂブラウザの画面上でこれらの各情報を入力し、インターネットを介して、加盟店のＷｅｂページを運営しているサイトのサーバ装置に送信する処理が行われる。加盟店は、ユーザから送信されてきたこれらの情報に、決済対象となる金額の情報を加えて、クレジットカード会社側のホストコンピュータに決済要求を出すことになる。クレジットカード会社側では、加盟店からの決済要求を受けたら、加盟店側から送信されてきたユーザの氏名、クレジットカード番号、有効期限を、ホストコンピュータ内の登録データと照合し、問題がなければ決済要求を承認する。
【０００４】
このように、クレジットカード会社では、基本的には、ユーザの氏名、クレジットカード番号、有効期限を照合して決済を行うので、これらの情報が犯罪者に盗まれると、悪用されるおそれがある。特に、インターネットの黎明期においては、ユーザがＷｅｂブラウザから送信したこれらの情報が、途中で不正に盗まれる事件が多発し、大きな社会問題となっていた。このような問題に対処するため、インターネット経由の情報送信のセキュリティを高める技術が開発されてきている。たとえば、現在では、ＳＳＬ（Secure Sockets Layer）と呼ばれるＴＣＰ／ＩＰ通信のセキュリティを確保するためのプロトコルが一般的に利用されており、このプロトコルにより送信した情報に対しては、実用上、十分なセキュリティを確保することが可能である。
【０００５】
【発明が解決しようとする課題】
このように、クレジットカードのユーザ氏名、番号、有効期限といった情報は、犯罪者の手に渡ると悪用されるおそれがある重要な情報であり、取り扱いには十分に注意する必要がある。もっとも、インターネット上の仮想ショッピングモールでの買い物の決済を、クレジットカードを用いて行う場合でも、上述のＳＳＬなどの技術を利用してこれらの情報を送信すれば、一応、送信経路上で情報が盗まれるような被害は未然に防ぐことができる。しかしながら、これまでのクレジットカードに対するセキュリティ対策は、加盟店自身が不正な行為をすることはない、ということを大前提としたものであり、加盟店自身が不正行為を働いた場合には、全く機能しないという問題を含んでいる。そもそも加盟店は、クレジットカード会社による厳密な審査により、十分に信頼がおける企業であるとの判断がなされた店であり、これまでは加盟店自身が不正行為をなすという事態は全く想定されていない。しかし、インターネット上のビジネスなどが普及すればするほど、クレジットカードの加盟店も多種多様となり、加盟店自身による不正行為、あるいはその従業者による不正行為が行われる可能性も高まってきている。加盟店のもとには、多数のユーザに関する氏名、クレジットカード番号、有効期限といった情報が集まるので、万一、これらの情報を不正に取得して横流しをするような従業者がいた場合には、ＳＳＬなどの技術により通信セキュリティを確保しても無力である。
【０００６】
このような問題点を解決するために、公開鍵暗号技術を利用したＳＥＴ（Secure Electronic Transaction ）なる決済方法が大手クレジットカード会社から提案され、現在、システムの実験が行われているが、かなり大掛かりなシステムが必要になるため、実用化には至っていない。
【０００７】
そこで本発明は、各加盟店に対するセキュリティを十分に確保することが可能なクレジットカードを用いた新規な決済処理方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
(1) 本発明の第１の態様は、クレジットカード会社から、所定の番号が付与されたクレジットカードの発行を受けたユーザが、当該クレジットカードの加盟店に対して当該クレジットカードを用いて決済を行うためのクレジットカードを用いた決済処理方法において、
個々のユーザについて準備を行う準備段階と、ユーザが特定の加盟店に対して決済を行う決済段階とを行い、
準備段階では、
個々のユーザが利用する個々のユーザ用情報処理装置が、当該ユーザに対して発行された特定のクレジットカードの番号の代わりに用いられるコードであって、個々のクレジットカードごとにユニークなコードである所定の代用コードを格納し、
この特定のクレジットカードによる決済を承認する権限をもった承認業者が管理する承認業者用情報処理装置が、個々のユーザごとのクレジットカード番号と代用コードとの対応関係を示す対応関係情報を格納し、
ユーザ用情報処理装置と承認業者用情報処理装置との双方が、所定の共通データを用いた演算処理により決済識別コードを発生させる所定のアルゴリズムを格納し、
決済段階では、
ユーザ用情報処理装置が、特定の加盟店が管理する加盟店用情報処理装置に対して、ユーザ用情報処理装置内に格納された代用コードと、ユーザ用情報処理装置によって発生された決済識別コードと、を送信し、
加盟店用情報処理装置が、ユーザ用情報処理装置から送信されてきた代用コードおよび決済識別コードを、承認業者用情報処理装置に送信することにより決済要求を出し、
この決済要求を受けた承認業者用情報処理装置が、予め格納されていた対応関係情報に基づき、送信されてきた代用コードに１対１に対応するクレジットカード番号を参照することによりユーザを特定し、当該ユーザについての共通データを用いた演算処理により決済識別コードを発生し、発生した決済識別コードと送信されてきた決済識別コードとが一致することを条件として、決済要求に対する承認を行い、
個々のユーザ用情報処理装置には、少なくとも、格納されている代用コードと、決済に用いるクレジットカードによる決済回数を示すコードと、を含む共通データを作成し、当該共通データを用いた演算処理により決済識別コードを発生させるアルゴリズムを格納しておき、承認業者用情報処理装置には、個々のユーザ用情報処理装置に格納されているアルゴリズムとそれぞれ同じアルゴリズムを格納しておき、
決済が行われる際には、ユーザ用情報処理装置と承認業者用情報処理装置との双方において、共通データを用いた同じアルゴリズムによる演算処理を行うことにより、それぞれ同一の決済識別コードが発生できるようにしたものである。
【００１０】
(2) 本発明の第２の態様は、上述の第１の態様に係るクレジットカードを用いた決済処理方法において、
特定のクレジットカードの番号の代わりに用いられる代用コードを、当該特定のクレジットカードの番号を利用して発生させるようにしたものである。
【００１２】
(3) 本発明の第３の態様は、上述の第１または第２の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置と承認業者用情報処理装置との双方で作成される共通データとして、時期に応じて内容が変化するマジックコードを含むデータを用いるようにしたものである。
【００１３】
(4) 本発明の第４の態様は、上述の第１または第２の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置と承認業者用情報処理装置との双方で作成される共通データとして、決済日、決済時、もしくは決済日時を示すコードを含むデータを用いるようにしたものである。
【００１５】
(5) 本発明の第５の態様は、上述の第１〜第４の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置と承認業者用情報処理装置とをネットワークを介して接続し、所定の期間ごとに、共通データ作成用もしくは決済識別コード発生用のアルゴリズムの内容を変更する処理を行うようにしたものである。
【００１６】
(6) 本発明の第６の態様は、上述の第１〜第５の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置内に、クレジットカードの利用限度額を示す情報を格納できるようにし、この利用限度額を越える決済が行われる場合には、その旨の警告が提示されるようにしたものである。
【００１７】
(7) 本発明の第７の態様は、上述の第１〜第６の態様に係るクレジットカードを用いた決済処理方法において、
特定のユーザが複数のクレジットカード会社からそれぞれクレジットカードの発行を受けているときに、各クレジットカードごとにそれぞれ別個の代用コードを作成してユーザ用情報処理装置に格納し、承認業者用情報処理装置には、各代用コードと各クレジットカード番号との対応関係を示す対応関係情報を格納し、複数のクレジットカードの中からユーザが選択した特定のクレジットカードについての決済処理を行うことができるようにしたものである。
【００１８】
(8) 本発明の第８の態様は、上述の第１〜第７の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置、加盟店用情報処理装置、承認業者用情報処理装置を、それぞれネットワークを介して接続し、加盟店のＷｅｂページ上に開かれた仮想ショッピングモールでユーザが買い物をした際に、ネットワークを介して代用コードおよび決済識別コードを送信することにより決済が行われるようにしたものである。
【００１９】
(9) 本発明の第９の態様は、上述の第１〜第８の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置を、ＩＣカードと、このＩＣカードに対する情報伝送を行うリーダライタ装置と、このリーダライタ装置を介してＩＣカードへのアクセスを行うコンピュータと、によって構成し、少なくとも決済処理を行う際に、ＩＣカードをリーダライタ装置に装着してコンピュータによってアクセスを行うことにより、ユーザ用情報処理装置としての機能を実現させるようにしたものである。
【００２０】
(10) 本発明の第１０の態様は、上述の第９の態様に係るクレジットカードを用いた決済処理方法において、
少なくとも、共通データおよび秘密アルゴリズムをＩＣカード内のメモリに格納し、決済識別コードの発生処理を、ＩＣカード内において実行するようにしたものである。
【００２２】
【発明の実施の形態】
以下、本発明を図示する実施形態に基づいて説明する。
【００２３】
§１．インターネット上での従来の一般的な決済処理方法
はじめに、インターネット上の仮想ショッピングモールで買い物をする場合の従来の一般的なクレジットカードによる決済処理方法の手順を説明する。図１は、この手順を示すブロック図である。この例では、ユーザ用情報処理装置１００、加盟店用情報処理装置２００、承認業者用情報処理装置３００がインターネット４００を介して接続される。ユーザ用情報処理装置１００は、ユーザの管理下にある情報処理装置であり、一般的には、インターネット４００に接続する機能を有するパソコンや携帯型情報端末装置がユーザ用情報処理装置１００として利用されている。加盟店用情報処理装置２００は、クレジットカードの加盟店によって管理されている情報処理装置であり、一般的には、仮想ショッピングモールのＷｅｂページのサイトを提供するＷｅｂサーバ装置が加盟店用情報処理装置２００として利用されることになる。承認業者用情報処理装置３００は、クレジットカードによる決済を承認する権限をもった承認業者（クレジットカード会社自身もしくはその委託を受けた特定の業者）によって管理される情報処理装置であり、通常は、比較的大規模なホストコンピュータによって構成される。
【００２４】
ユーザは、クレジットカード会社からクレジットカード１０の発行を受けており、このクレジットカード１０には、ユーザの氏名Ｎ、クレジットカード番号Ｃ、有効期限Ｄなる情報が記載されている（通常、エンボス加工によって刻まれている）。もちろん、クレジットカードによっては、この他にも種々の情報が記載されている場合がある。一方、このクレジットカード１０上に記載された情報は、承認業者用情報処理装置３００内のデータベースにも登録されている。このデータベースには、更に、各ユーザの住所、電話番号、勤務先、過去の決済履歴などのデータも格納されている。
【００２５】
加盟店が運営する仮想ショッピングモールを利用するには、ユーザは、ユーザ用情報処理装置１００のＷｅｂブラウザ機能を用いて、加盟店用情報処理装置２００内のサイトの所定のＷｅｂページにアクセスすればよい。いま、ユーザが、このＷｅｂページ上で所望の商品を購入し、クレジットカード１０を利用してその代金を決済する場合を考えよう。この場合、ユーザは手元にクレジットカード１０を用意し、Ｗｅｂ画面上で、氏名Ｎ、クレジットカード番号Ｃ、有効期限Ｄなる情報をキーボードなどを用いて入力する。入力したこれらの情報は、インターネット４００を介して、加盟店用情報処理装置２００へと送信される。通常、この送信処理は、ＳＳＬなどのセキュリティが確保されたプロトコルにより行われるため、インターネット４００の伝送経路上でこれらの情報が盗まれる可能性は非常に小さい。こうして、加盟店用情報処理装置２００に、ユーザが送信したこれらの情報が到達すると、今度は、加盟店が、自己の店名や決済金額などの情報を付加して、これらの情報をインターネット４００を介して（場合によっては、別な通信線を介して）、承認業者用情報処理装置３００へと送信して承認を求める。承認業者は、承認業者用情報処理装置３００内のデータベースに登録されている情報と、加盟店から送信されてきた情報とを照合し、問題がなければ当該決済を承認することになる。
【００２６】
結局、クレジットカード１０上の氏名Ｎ，クレジットカード番号Ｃ，有効期限Ｄという情報は、ユーザ用情報処理装置１００から加盟店用情報処理装置２００へと送信され、更に、加盟店用情報処理装置２００から承認業者用情報処理装置３００へと送信されることになる。このような送信経路におけるセキュリティは、前述したように、ＳＳＬなどの技術によって実用上十分なレベルまで確保されている。しかしながら、このようなセキュリティ対策は、加盟店自身が不正な行為をすることはない、ということを大前提としたものである。加盟店用情報処理装置２００内には、多数のユーザのクレジットカードに関する情報が蓄積されており、万一、これらの蓄積情報を不正に取得して横流しをするような従業者が加盟店内にいた場合、クレジットカード情報に対するセキュリティ対策は根底から覆されてしまう。本発明は、このような問題を解決するための新たな決済処理方法を提案するものである。
【００２７】
§２．本発明に係る決済処理方法の基本概念
続いて、図２のブロック図を参照しながら、本発明に係るクレジットカードを用いた決済処理方法の基本概念を説明する。この図２に示す例は、図１に示す例と同様に、ユーザ、加盟店、承認業者の三者間での決済処理の手順を示しているが、ここでは、多数のユーザのうちの第ｎ番目のユーザという意味で、特定のユーザＵｎが決済処理を行う場合の処理手順を示すことにする。図に示す各符号のサフィックス「ｎ」は、この第ｎ番目のユーザについての情報であることを示すものである。
【００２８】
図１に示す例と同様に、この図２の例でも、ユーザ用情報処理装置１００、加盟店用情報処理装置２００、承認業者用情報処理装置３００がインターネット４００を介して接続される。やはり、ユーザ用情報処理装置１００は、ユーザの管理下にある情報処理装置であり、一般的には、インターネット４００に接続する機能を有するパソコンや携帯型情報端末装置がユーザ用情報処理装置１００として利用されることになる。ただ、実用上は、後に§３で述べるように、ＩＣカードをユーザ用情報処理装置１００の一部として利用するのが好ましい。加盟店用情報処理装置２００は、前述したように、クレジットカードの加盟店によって管理されている情報処理装置であり、仮想ショッピングモールのＷｅｂページのサイトを提供するＷｅｂサーバ装置によって構成される。また、承認業者用情報処理装置３００は、前述したように、承認業者によって管理される比較的大規模なホストコンピュータによって構成され、各ユーザに関する種々の情報をデータベースとして格納する機能を有している。
【００２９】
この図２に示す決済処理方法は、あくまでもクレジットカードを用いた決済処理方法であり、その点では、図１に示す従来の決済処理方法と同じである。すなわち、第ｎ番目のユーザＵｎは、クレジットカード会社から予めクレジットカード１０の発行を受けており、このクレジットカード１０には、ユーザの氏名Ｎｎ、クレジットカード番号Ｃｎ、有効期限Ｄｎなる情報が記載されている。ただし、従来の決済処理方法では、加盟店側にこれらの各情報を知らせる必要があるが、本発明に係る決済処理方法では、その必要がなくなる。もっとも、この新規な決済処理方法を利用するためには、ユーザは事前に、承認業者との間で所定の準備手続を行っておく必要がある。
【００３０】
この準備手続は、特定のユーザＵｎと承認事業者との間で、代用コードＳＵＢｎ，共通データＣＯＭｎ，秘密アルゴリズムＡＲＧｎなる決済用情報２０を決める手続きである。代用コードＳＵＢｎは、ユーザＵｎに対して発行されたクレジットカード番号Ｃｎの代わりに用いられるコードであり、加盟店に対しては、クレジットカード番号Ｃｎの代わりに、この代用コードＳＵＢｎが知らされることになる。この代用コードＳＵＢｎは、ユーザ用情報処理装置１００内に格納されるとともに、承認業者用情報処理装置３００内にも格納される。しかも、承認業者用情報処理装置３００内へは、代用コードＳＵＢｎとクレジットカード番号Ｃｎとの対応関係を示す対応関係情報３０として格納される。もともと承認業者用情報処理装置３００内には、多数のユーザについて、それぞれこれまでに発行したクレジットカードの番号が格納されている。本発明では、この承認業者用情報処理装置３００内に、更に、個々のユーザごとのクレジットカード番号との対応関係を示す対応関係情報３０として、各代用コードが格納されるので、承認業者に対して、特定の代用コードを知らせると、これに対応したクレジットカード番号を参照することができ、ユーザを特定することができる。
【００３１】
なお、特定の代用コードに対して、特定のクレジットカード番号を１対１に対応させるためには、個々のクレジットカードごとにそれぞれユニークな代用コードを定義するようにすればよい。世界中で唯一無二の代用コードをそれぞれ各クレジットカードごとに定義し、このようなユニークな代用コードを用いるようにすれば、対応関係情報３０に基づいて、特定の代用コードと特定のクレジットカード番号とを１対１に対応させることができる。すなわち、特定の代用コードを用いて決済要求を受けた承認業者は、当該代用コードに対して１対１に対応するクレジットカード番号を対応関係情報３０に基づいて参照することができる。
【００３２】
このようなユニークな代用コードを定義する最も簡単な方法は、十分な桁数をもった乱数を発生させ、この乱数に基づいて所定桁の代用コードを定める方法である。このような乱数を用いた方法では、理論的には、全く同一の代用コードが偶然に発生される可能性があるが、その可能性が実用上零とみなせる程度の十分な桁数の乱数を用いるようにすれば、実質的には、ユニークな代用コードを得ることができる。ユニークな代用コードを定義するためのより実用的な方法は、クレジットカード番号を利用する方法である。現在流通しているクレジットカード番号は、各クレジットカード会社が相互に調整することにより、世界中で唯一無二のユニークな１６桁の番号となっている。したがって、特定のクレジットカード番号についての代用コードを定めるのに、当該クレジットカード番号自身を利用した方法を採れば、やはりユニークな代用コードを定義することができる。具体的には、たとえば、クレジットカード番号Ｃｎ（あるいはそれに更にユーザの氏名Ｎｎなどを必要に応じて付加したデータ列）に対してハッシュ関数を作用させて得られるハッシュ値を、当該クレジットカード番号Ｃｎの代用コードとすればよい。
【００３３】
一方、共通データＣＯＭｎは、ユーザ用情報処理装置１００と承認業者用情報処理装置３００との双方に格納されるべきデータであり、個々のユーザごとに異なるデータであれば、どのようなデータであってもかまわない。たとえば、上述した代用コードＳＵＢｎを、そのまま共通データＣＯＭｎとして用いることも可能である。ただ、この共通データＣＯＭｎは、セキュリティを確保する上で、ユーザＵｎと承認業者との間だけの秘密のデータとして保持されていることが好ましく、そのような意味では、代用コードＳＵＢｎだけでなく、より複雑なデータを利用するのが好ましい。この共通データＣＯＭｎのより実用的な例については、§３で述べることにする。同様に、秘密アルゴリズムＡＲＧｎも、ユーザ用情報処理装置１００と承認業者用情報処理装置３００との双方に格納されるべきものであり、共通データＣＯＭｎを用いた何らかの演算処理を定義するものであれば、どのようなアルゴリズムでもよい。もっとも、この秘密アルゴリズムＡＲＧｎも、セキュリティを確保する上で、ユーザＵｎと承認業者との間だけの秘密のアルゴリズムとして保持されていることが好ましく、そのような点では、第三者による類推が困難になるように、できるだけ複雑なアルゴリズムにするのが好ましい。
【００３４】
この秘密アルゴリズムＡＲＧｎは、共通データＣＯＭｎを用いた演算により、所定の決済識別コードＩＤ（ｎ，ｉ）を発生させる機能を有している。この決済識別コードＩＤ（ｎ，ｉ）の文字「ｎ」は、第ｎ番目のユーザＵｎのためのコードであることを示しており、文字「ｉ」は第ｉ回目の決済のために発生されたコードであることを示している。別言すれば、決済識別コードＩＤ（ｎ，ｉ）は、各ユーザごとに異なるコードであるとともに、決済が行われるたびに毎回異なるコードということになる。上述したように、共通データＣＯＭｎは各ユーザごとに異なるデータであるから、この共通データＣＯＭｎを用いて発生される決済識別コードＩＤ（ｎ，ｉ）は、当然、各ユーザごとに異なるコードとなるが、同一のユーザＵｎについて発生された決済識別コードＩＤ（ｎ，ｉ）であったとしても、第１回目の決済のときには、決済識別コードＩＤ（ｎ，１）が発生され、第２回目の決済のときには、決済識別コードＩＤ（ｎ，２）が発生される、というように、決済ごとに異なる決済識別コードＩＤ（ｎ，ｉ）が発生されるようにしておく。逆に言えば、秘密アルゴリズムＡＲＧｎとして、決済が行われるたびに毎回異なる決済識別コードが発生されるようなアルゴリズムを定めておくようにすればよい。
【００３５】
かくして、この準備段階では、ユーザＵｎと承認業者との間で、代用コードＳＵＢｎ，共通データＣＯＭｎ，秘密アルゴリズムＡＲＧｎが定められ、これらの決済用情報２０は、ユーザ用情報処理装置１００と承認業者用情報処理装置３００との双方に格納される。なお、ここでは、代用コードＳＵＢｎ，共通データＣＯＭｎ，秘密アルゴリズムＡＲＧｎのいずれもが、各ユーザごとに異なる例を示しているが、秘密アルゴリズムＡＲＧｎについては、必ずしも各ユーザごとに変える必要はなく、全ユーザについて共通の秘密アルゴリズムＡＲＧを用いるようにしてもかまわない。実用上は、簡便な運用を図るために、全ユーザについて共通の秘密アルゴリズムＡＲＧを用いるようにした方が好ましい。
【００３６】
このように、双方に同一の決済用情報２０が格納されているため、ユーザ用情報処理装置１００側で第ｎ番目のユーザＵｎの第ｉ回目の決済のために発生させた決済識別コードＩＤ（ｎ，ｉ）と、承認業者用情報処理装置３００側で発生させた同コードとは、全く同一になる。すなわち、ユーザ用情報処理装置１００と承認業者用情報処理装置３００との双方において、共通データＣＯＭｎを用いた秘密アルゴリズムＡＲＧｎによる演算処理を行うことにより、それぞれ同一の決済識別コード決済識別コードＩＤ（ｎ，ｉ）が発生されることになる。
【００３７】
さて、上述した準備手続が完了したら、ユーザＵｎは、この新規な決済処理方法を利用してクレジットカード決済を行うことが可能になる。いま、ユーザＵｎが、加盟店の提供するＷｅｂページ上で所望の商品を購入し、クレジットカード１０を利用してその代金を決済する場合を考えよう。従来の方法では、図１で説明したように、加盟店用情報処理装置２００に対して、氏名Ｎｎ，クレジットカード番号Ｃｎ，有効期限Ｄｎを送信する必要があったが、本発明に係る方法では、少なくとも、ユーザ用情報処理装置１００内に格納されている代用コードＳＵＢｎと、ユーザ用情報処理装置１００によって発生された決済識別コードＩＤ（ｎ，ｉ）とを送信すればよい。加盟店用情報処理装置２００は、ユーザＵｎから送信されてきた代用コードＳＵＢｎおよび決済識別コードＩＤ（ｎ，ｉ）を、承認業者用情報処理装置３００に送信することにより決済要求を出すことになる。
【００３８】
このような決済要求を受けた承認業者用情報処理装置３００は、まず、対応関係情報３０に基づいて、送信されてきた代用コードＳＵＢｎに対応するクレジットカード番号Ｃｎを参照することによりユーザＵｎを特定する。従来は、クレジットカード番号Ｃｎの送信を受けることによりユーザＵｎの特定を行っていたわけであるが、本発明では、クレジットカード番号Ｃｎの代わりに代用コードＳＵＢｎを送信することにより、ユーザＵｎの特定が可能になる。続いて、承認業者用情報処理装置３００は、このユーザＵｎについての共通データＣＯＭｎを用い、秘密アルゴリズムＡＲＧｎに基づく演算を行うことにより、決済識別コードＩＤ（ｎ，ｉ）を発生させる。そして、加盟店用情報処理装置２００側から決済要求とともに送信されてきた決済識別コードＩＤ（ｎ，ｉ）と、内部で発生させた決済識別コードＩＤ（ｎ，ｉ）とが一致するか否かを判定する。両者が一致すれば、加盟店用情報処理装置２００側からの当該決済要求は、ユーザＵｎの正当なカード利用に基づく要求であると認定し、これに対する承認を行うことになる。もちろん、両者が一致しなかった場合には、何らかの不正な要求であるか、何らかの誤りに基づく要求であると認定し、当該決済要求に対する否認処理が行われることになる。
【００３９】
なお、実用上は、ユーザ用情報処理装置１００から加盟店用情報処理装置２００に対して送信される情報には、代用コードＳＵＢｎおよび決済識別コードＩＤ（ｎ，ｉ）だけでなく、ユーザＵｎの氏名や住所などの情報や、買い物対象となる商品やその個数などを示すデータも含まれることになるが、このような情報送信についての図示は省略している。また、加盟店用情報処理装置２００から承認業者用情報処理装置３００に対して送信される情報には、代用コードＳＵＢｎおよび決済識別コードＩＤ（ｎ，ｉ）だけでなく、ユーザＵｎの氏名，決済金額，加盟店自身を特定する識別コードなどのデータも含まれることになるが、このような情報送信の図示も省略している。
【００４０】
このように、本発明に係る決済処理方法によれば、従来の決済処理方法と全く同様のスムーズな決済処理が可能になる。しかも、重要な点は、加盟店側には、クレジットカード番号Ｃｎや有効期限Ｄｎという情報が送信されないという点である。有効期限Ｄｎについては、送信しても特に問題はないが、クレジットカード番号Ｃｎについては、加盟店側に送信を行うとセキュリティの面で問題が生じることになる。前述したように、加盟店用情報処理装置２００内に、ユーザＵｎの氏名Ｎｎとクレジットカード番号Ｃｎとのデータが蓄積されることになるため、不正利用の危険性が生じるからである。
【００４１】
本発明の特徴は、代用コードＳＵＢｎと決済識別コードＩＤ（ｎ，ｉ）とを組み合わせることにより、セキュリティの向上を図った点にある。これは、代用コードＳＵＢｎだけを用いた決済処理では、セキュリティの面で問題が生じるためである。すなわち、もし、代用コードＳＵＢｎだけを用いた決済処理を行ったとすると、加盟店用情報処理装置２００内には、特定のユーザＵｎについての氏名Ｎｎと代用コードＳＵＢｎとが蓄積されることになるので、この氏名Ｎｎと代用コードＳＵＢｎとを盗み取った犯罪者が、不正な手段で承認業者用情報処理装置３００にアクセスし、ユーザＵｎが買い物をしたように見せかけた決済要求を行う危険性がある。ところが、本発明で正当な決済を行うためには、代用コードＳＵＢｎと決済識別コードＩＤ（ｎ，ｉ）との組み合わせが必要になる。しかも、決済識別コードＩＤ（ｎ，ｉ）は、決済を行うたびに毎回異なるコードとなるようにしてあるため、同一の決済識別コードＩＤ（ｎ，ｉ）を用いた決済は１回だけに限られる。万一、同一の決済識別コードＩＤ（ｎ，ｉ）を用いた２回目の決済要求があっても、承認業者用情報処理装置３００は、そのような決済要求を否認することになる。
【００４２】
たとえば、ユーザＵｎが第ｉ回目の決済として、正当な決済を行ったとすると、代用コードＳＵＢｎと、第ｉ回目の決済についての決済識別コードＩＤ（ｎ，ｉ）とが、承認業者用情報処理装置３００に送信されることになるので、この場合は、正当な決済要求であるとして承認される。このとき、加盟店用情報処理装置２００内には、決済に用いた代用コードＳＵＢｎと決済識別コードＩＤ（ｎ，ｉ）とが残っていることになるので、加盟店の従業員などがこれらの情報を不正利用して、虚偽の決済要求を出すかもしれない。ところが、このような虚偽の決済要求は、第（ｉ＋１）回目の決済要求ということになるので、承認業者用情報処理装置３００内で発生される決済識別コードがＩＤ（ｎ，ｉ＋１）であるのに対し、虚偽の決済要求により送信されてきた決済識別コードはＩＤ（ｎ，ｉ）であるため、両者は不一致となり、虚偽の決済要求は否認されることになる。いわば、決済識別コードＩＤ（ｎ，ｉ）は、個々の決済ごとに使い捨てのコードということになり、たとえ不正な方法で代用コードＳＵＢｎと決済識別コードＩＤ（ｎ，ｉ）とが盗まれたとしても、虚偽の決済が承認されることはないのである。
【００４３】
このように、本発明に係るクレジットカードを用いた決済処理方法では、加盟店側にクレジットカード番号Ｃｎを知らせる必要がないので、クレジットカード番号Ｃｎの盗難による不正利用を防止することができる。加盟店側には、代用コードＳＵＢｎおよび決済識別コードＩＤ（ｎ，ｉ）を知らせる必要はあるが、決済識別コードＩＤ（ｎ，ｉ）は各決済ごとに異なる使い捨てコードになるため、万一盗まれたとしても、不正に利用されることはない。
【００４４】
§３．本発明に係る具体的な決済処理方法
続いて、本発明に係るクレジットカードを用いた決済処理方法のより具体的な実施形態を述べる。ここで述べる実施形態の第１の特徴は、ユーザ用情報処理装置１００として、ＩＣカードを利用した点にあり、第２の特徴は、複数のクレジットカードについて適用できるようにした点にある。
【００４５】
図３は、この実施形態で用いられるユーザ用情報処理装置１００の基本構成を示すブロック図である。ここに示す例では、ユーザ用情報処理装置１００は、パソコン１１０、リーダライタ装置１２０、ＩＣカード１３０によって構成されている。ＩＣカード１３０としては、ＣＰＵおよびメモリを内蔵した演算処理機能をもったＩＣカードであれば、どのようなＩＣカードを用いてもかまわない。最近は、磁気カードに代わる携帯型情報記録媒体として、種々のタイプのＩＣカードが普及し始めている。一般に、ＩＣカードは、ソフトウエアをロードすることにより様々な機能を付加することができるので、ＩＣカードを利用して本発明に係る決済処理方法を実施する場合、必ずしも新たな専用のＩＣカードをユーザに配付する必要はない。ユーザが既に何らかのＩＣカードを所持しているのであれば、このＩＣカードに、本発明に係る決済処理方法を実行するための専用ソフトウエアあるいは専用のデータ、またはその両方をロードするだけで、既存のＩＣカードをそのまま利用して本発明を実施することが可能になる。
【００４６】
リーダライタ装置１２０は、このＩＣカード１３０に対する情報伝送を行う汎用の読取／書込装置であり、パソコン１１０は、このリーダライタ装置１２０を介してＩＣカード１３０へのアクセスを行う汎用のコンピュータである。ここ数年来、個人レベルでのパソコン所有率が高まり、かなりのユーザがパソコンを所有し、インターネットへの接続環境を備えている。本発明による決済処理方法を利用する場合、このような汎用のパソコン１１０に、汎用のリーダライタ装置１２０を接続し、所定のソフトウエアをロードしたＩＣカード１３０を用意すればよい。このＩＣカード１３０をリーダライタ装置１２０に装着し、パソコン１１０によってアクセスを行うようにすれば、このシステムが全体として、§２で述べたユーザ用情報処理装置１００として機能することになる。
【００４７】
このように、本実施形態では、パソコン１１０，リーダライタ装置１２０，ＩＣカード１３０からなるシステムによって、ユーザ用情報処理装置１００が構成されることになるが、実質的には、ＩＣカード１３０がユーザ用情報処理装置１００としての主たる機能を果たし、パソコン１１０およびリーダライタ装置１２０は、このＩＣカード１３０をインターネット４００へ接続するためのインターフェイスとしての役割を果たしているにすぎない。すなわち、本発明において重要な機能を果たす情報は、いずれもＩＣカード１３０内に格納されることになる。以下、このＩＣカード１３０内に格納されている情報について説明する。
【００４８】
図３に示すように、ＩＣカード１３０内には、「ＰＲＧ」，「ＡＲＧ」，「ＰＩＮ」，「ＤＡＴＥ」，「ＭＡＧ」なる情報が収容されている。ここで、「ＰＲＧ」は、このＩＣカード１３０を本発明に係るユーザ用情報処理装置１００の主たる構成要素として機能させるためのプログラムであり、§２で述べたユーザ用情報処理装置１００の各機能は、このプログラムの制御のもとに実現されることになる。また、「ＡＲＧ」は、図２に示す決済用情報２０内の秘密アルゴリズムＡＲＧｎに相当するアルゴリズムであり、承認業者用情報処理装置３００側にも同じ秘密アルゴリズムが格納されている。この実施形態では、すべてのユーザについて同一のアルゴリズムを採用している。次の「ＰＩＮ」は、このＩＣカード１３０の利用を可能にするためのユーザＵｎ自身の識別コードである。ユーザＵｎは、このＩＣカード１３０をリーダライタ装置１２０に装着した後、パソコン１１０から正しい「ＰＩＮ」コードを入力する作業を行う。入力した「ＰＩＮ」コードは、ＩＣカード１３０内部の「ＰＩＮ」コードと照合され、両者が一致していた場合に、以後のＩＣカード１３０へのアクセスが許可されることになる。この「ＰＩＮ」コードの照合機能は、一般的なＩＣカード１３０には必ず備わっている既存の機能であり、本発明に固有の機能というわけではない。「ＤＡＴＥ」は、現在の日付および時刻を示すデータであり、一般に、外部からＩＣカード１３０に知らされる（ＩＣカードの中では、知らされた日付がシーケンシャルであるかをチェックすることもある。）。また、「ＭＡＧ」はいわゆるマジックコードであり、後述するように、共通データＣＯＭｎの一部として利用され、承認業者用情報処理装置３００側にも同じマジックコードが格納されている。
【００４９】
上述の各情報のうち、「ＰＩＮ」はＩＣカード１３０を利用するための基本的なコードであり、「ＤＡＴＥ」はＩＣカード１３０に対して外部から与えられるデータであるので、いずれも、一般的なＩＣカードに標準的に備わっている情報と言うことができる。これに対して、「ＰＲＧ」，「ＡＲＧ」，「ＭＡＧ」は、本発明の実施のために用意される専用の情報であり、ユーザＵｎが準備手続を行う際に、外部からロードされる情報である。ユーザＵｎが既に所有している既存のＩＣカード（たとえば、社員証として機能するＩＣカード、診察券として機能するＩＣカード、サービスポイントを貯めるためのＩＣカードなど、既に種々のＩＣカードが実際に利用されている）を、本発明のためにも流用するというケースの場合は、準備手続を行うときに、パソコン１１０から、これら専用の情報をＩＣカード１３０側へとロードすればよい。ロード対象となるこれら専用の情報は、ＣＤ−ＲＯＭなどに収容してユーザＵｎに配付してもよいし、インターネット４００を介してパソコン１１０へダウンロードさせるようにしてもよい。もちろん、「ＰＲＧ」，「ＡＲＧ」，「ＭＡＧ」といったデータが予めロードされたＩＣカードを用いて、社員証、診察券、サービスポイントカードなどを発行し、これを配布するようにすれば、これらのデータをロードする処理は不要になる。
【００５０】
準備手続においてユーザＵｎが行う作業は、これら専用の情報をＩＣカード１３０にロードする作業と（上述したように、これらの専用情報が予めロードされたＩＣカードが配布されていた場合は、このロード作業は不要である。）、クレジットカードに関するデータをＩＣカード１３０へ入力する作業である。図３に示す例では、ユーザＵｎが、異なる２つのクレジットカード会社から、それぞれクレジットカードαおよびクレジットカードβなるクレジットカードの発行を受けており、この２枚のクレジットカードの情報をＩＣカード１３０へ入力して利用する例が示されている。このような情報入力は、既にＩＣカード１３０内にロードされているプログラム「ＰＲＧ」の処理機能に基づいて行うことができる。図示の例の場合、クレジットカードαに記載されている氏名αＮｎ，クレジットカード番号αＣｎ，有効期限αＤｎと、クレジットカードβに記載されている氏名βＮｎ，クレジットカード番号βＣｎ，有効期限βＤｎと、をＩＣカード１３０内に書き込む作業が行われることになる（氏名αＮｎと氏名βＮｎとは同一である必要はなく、たとえば、一方を家族名義にしてもかまわない。）。ユーザＵｎは、クレジットカードα，βを手元に置いて、パソコン１１０のキーボードなどから、これらのデータを入力する作業を行う。なお、この例では、更に、利用限度額αＬｎ，βＬｎを入力している。この利用限度額αＬｎ，βＬｎの役目については、§４の変形例のところで述べる。
【００５１】
こうして、各クレジットカードα，βについて、氏名αＮｎ，βＮｎ，クレジットカード番号αＣｎ，βＣｎ，有効期限αＤｎ，βＤｎ，利用限度額αＬｎ，βＬｎの入力作業が完了すると、続いて、代用コードαＳＵＢｎ，βＳＵＢｎを発生させる処理が行われる。ここに示す実施例では、ＩＣカード１３０にロードされているプログラム「ＰＲＧ」内に、この代用コードを発生させる処理ルーチンを組み込んでおり、ユーザＵｎが入力したクレジットカード番号αＣｎ，βＣｎに基づいて、ＩＣカード１３０の内部で代用コードαＳＵＢｎ，βＳＵＢｎが発生され、そのままＩＣカード１３０内部に格納される。具体的には、この実施形態の場合、１６桁の数字からなるクレジットカード番号αＣｎ，βＣｎに対してハッシュ関数を作用させ、得られるハッシュ値を代用コードαＳＵＢｎ，βＳＵＢｎとして用いるようにしている。セキュリティを更に高める上では、１６桁のクレジットカード番号に、更に何らかの文字列（たとえば、マジックコード「ＭＡＧ」など）を付加してから、ハッシュ関数を作用させるのが好ましい。一般に、ハッシュ関数は一方向性の関数とされており、クレジットカード番号Ｃｎにハッシュ関数を作用させてハッシュ値（代用コード）ＳＵＢｎを得る演算は誰でも行うことができるが、逆に、ハッシュ値ＳＵＢｎを元のクレジットカード番号Ｃｎに戻すことはできない。したがって、ハッシュ値を代用コードＳＵＢｎとして用いれば、代用コードＳＵＢｎが第三者に知られたとしても、クレジットカード番号Ｃｎまでが知られてしまう危険性はない。
【００５２】
ここに示す実施形態では、更に、各クレジットカードα，βについての決済回数αｉ，βｉをＩＣカード１３０内に格納するようにしている。決済回数αｉ，βｉは、それぞれ各クレジットカードα，βを用いた本発明による決済処理が、これまでに何回行われたかを示す数字であり、準備手続の段階では、これら決済回数αｉ，βｉは初期値０に設定される。以後、本発明による決済処理が行われるたびに、各決済回数αｉ，βｉはそれぞれ１だけ増加してゆくことになる。
【００５３】
このような準備手続によりＩＣカード１３０内に格納されることになった情報は、承認業者へ送信される。すなわち、ＩＣカード１３０内の情報は、リーダライタ装置１２０、パソコン１１０、インターネット４００を介して、承認業者用情報処理装置３００へと送られ、承認業者側にも知らされることになる（「ＰＩＮ」については、承認業者側に知らせる必要はない）。この送信処理は、十分なセキュリティが確保できるＳＳＬなどのプロトコルで行われる。承認業者側では、こうして送信されてきた情報に基づいて、対応関係情報３０を作成する。もっとも、承認業者側には、個々のユーザＵｎについての氏名Ｎｎ，クレジットカード番号Ｃｎ，有効期限Ｄｎ，住所，電話番号などの情報が既にデータベースとして用意されているので、実際には、このデータベースに代用コードＳＵＢｎを付加する処理を行うだけですむ。
【００５４】
以上の各作業により、準備手続は完了である。なお、上述した準備手続の例では、ＩＣカード１３０の内部において代用コードＳＵＢｎを発生させ、これを承認業者用情報処理装置３００側へ送信するという手順を採っているが、逆に、承認業者用情報処理装置３００側で代用コードＳＵＢｎを発生させ、これをＩＣカード１３０側へ送信するという手順を採ることもできるし、ＩＣカード１３０および承認業者用情報処理装置３００のそれぞれが独立して代用コードＳＵＢｎを発生させる処理を行うという手順を採ることもできる（同一のクレジットカード番号Ｃｎに対して、同一のハッシュ関数を適用すれば、同一の代用コードＳＵＢｎが生成される）。要するに、上記準備手続により、各クレジットカードについての代用コードＳＵＢｎと、共通データとして用いられる情報（この例では、後述するように、代用コードＳＵＢｎ自身と、決済回数ｉ，「ＤＡＴＥ」，「ＭＡＧ」の各データ）とが、ＩＣカード１３０と承認業者用情報処理装置３００との双方に格納された状態になれば、どのような手順で準備手続を行ってもかまわない。
【００５５】
このような準備手続が完了すれば、このＩＣカード１３０自身を、クレジットカードα，βの代用カードとして利用することができるようになる。別言すれば、このＩＣカード１３０は、クレジットカードα，βのいわゆる「子カード」として機能することになる。図３には、２枚のクレジットカードα，βの情報をＩＣカード１３０内に入力した例が示されているが、もちろん、３枚以上のクレジットカードについての情報をＩＣカード１３０内に入力することも可能であり、ユーザＵｎは、このＩＣカード１３０を、多数のクレジットカードの「子カード」として利用することが可能になる。しかも、このＩＣカード１３０は、本質的には、各クレジットカードと同等のカード（同一のクレジットアカウントについてのカード）であるので、ＩＣカード１３０を発行するために、新たに各クレジットカード会社の審査を受ける必要はない。クレジットカード会社によっては、いわゆる「家族カード」と称するユーザの家族名義の「子カード」を発行するサービスを提供していることがあるが、通常、このような「家族カード」の発行を受けるためには、その旨の申請書をクレジットカード会社に提出し、一応の審査を受ける必要がある。本発明によって発行されるＩＣカード１３０は、このような「家族カード」とは全く性質の異なるカードであり、本質的に元のクレジットカードと同一のアカウントを利用したカードということになるので、発行に際してクレジットカード会社による新たな審査は必要なく、繁雑な事務処理を経ることなしに円滑な発行が可能である。
【００５６】
続いて、このＩＣカード１３０を用いた決済処理の手順を説明する。上述したように、ＩＣカード１３０は、必ずしも本発明に利用する専用のカードにする必要はなく、他の種々の用途に共用することが可能である。ユーザＵｎは、このＩＣカード１３０を、本発明に係る決済処理に利用する場合に、リーダライタ装置１２０に装着すればよい。ユーザＵｎが、パソコン１１０を用いて加盟店の仮想ショッピングモールのＷｅｂページにアクセスし、クレジットカードによる決済を行う場合は、次のような作業を行えばよい。まず、ＩＣカード１３０をリーダライタ装置１２０に装着し、パソコン１１０を用いて「ＰＩＮ」データを入力する。ＩＣカード１３０の内部で「ＰＩＮ」データの照合が完了すると、次に、どのクレジットカードを用いて決済を行うかを選択する入力を行う。たとえば、ユーザＵｎがクレジットカードαによって決済する旨の選択入力を行うと、ユーザＵｎの氏名Ｎｎと、クレジットカードαについての代用コードαＳＵＢｎと、当該決済（第αｉ回目の決済）について生成された決済識別コードαＩＤ（ｎ，αｉ）とが、インターネット４００を介して加盟店用情報処理装置２００へと送信されることになる（実際には、この他、ユーザＵｎの住所や、購入した商品や数量を示す情報なども送信されることになる）。このような処理は、ＩＣカード１３０内のプログラム「ＰＲＧ」と、加盟店用情報処理装置２００のＷｅｂサーバ内のプログラムの連繋動作によって行われる。
【００５７】
既に§２で述べたように、加盟店用情報処理装置２００は、ユーザＵｎ側から送信されてきた情報のうちの氏名Ｎｎ，代用コードαＳＵＢｎ，決済識別コードαＩＤ（ｎ，αｉ）と、決済金額および加盟店自身を特定する識別コードを承認業者用情報処理装置３００へ送信して決済要求を出す。承認業者用情報処理装置３００は、代用コードαＳＵＢｎに対応するクレジットカード番号αＣｎを参照し、この決済要求がユーザＵｎについてのものであることを特定する。そして、承認業者用情報処理装置３００内で発生させた決済識別コードαＩＤ（ｎ，αｉ）と、加盟店用情報処理装置２００側から送信された決済識別コードαＩＤ（ｎ，αｉ）とが一致することを確認した上で、加盟店用情報処理装置２００に対して当該決済を承認する旨の回答を行う。
【００５８】
一般に、ＣＰＵ内蔵型のＩＣカードでは、内部メモリに格納された情報に対して十分なセキュリティが確保されており、図３に示すＩＣカード１３０内の各情報が、不正な手段で外部に読み出される可能性はないと考えてよい。したがって、万一、ユーザＵｎがこのＩＣカード１３０を紛失したとしても、内部に格納された種々の情報が流出するおそれはない。本発明の決済処理に必要な種々の情報を、パソコン１１０側ではなく、ＩＣカード１３０側に格納しているのは、ＩＣカードがこのような高度なセキュリティを備えているからである。しかも、ここに示す実施形態では、決済識別コードＩＤ（ｎ，ｉ）を発生する処理も、ＩＣカード１３０の内部で行うようにしているため、パソコン１１０内には、決済識別コードＩＤ（ｎ，ｉ）を発生するための処理履歴が一切残らない。このように、決済識別コードＩＤ（ｎ，ｉ）を発生するために必要な共通データＣＯＭｎおよび秘密アルゴリズムＡＲＧを、すべてＩＣカード１３０内に格納しておくようにし、決済識別コードＩＤ（ｎ，ｉ）を、ＩＣカード１３０の内部で発生させることは、高度のセキュリティを確保する上で極めて有効である。
【００５９】
続いて、共通データＣＯＭｎの具体的な例についての説明を、図４のブロック図を参照して行う。§２で述べたように、本発明における共通データＣＯＭｎの役割は、秘密アルゴリズムＡＲＧを用いて決済識別コードＩＤ（ｎ，ｉ）を発生させる際に元となる「タネ」としての役割であり、ＩＣカード１３０と承認業者用情報処理装置３００との双方に共通して格納され、各ユーザＵｎごとにそれぞれ異なるようなデータであれば、どのようなデータを用いてもかまわない。ただ、この共通データが第三者に類推されるようなデータであると、セキュリティの面から好ましくないので、できるだけ複雑なデータを共通データとして定めておくのが好ましい。また、本発明の基本原理上、各決済処理ごとに異なる決済識別コードＩＤ（ｎ，ｉ）が生成される必要があり、そのためには、元になる共通データ自体が、各決済処理ごとに変化するような性質のデータであることが好ましい。
【００６０】
そこで、本実施形態では、図４の下欄に示すような共通データを定義している。すなわち、クレジットカードαを用いた決済用の共通データαＣＯＭｎとしては、代用コードαＳＵＢｎ，マジックコードＭＡＧ，日付／時刻ＤＡＴＥ，決済回数αｉの４つのデータの組み合わせからなるデータ（たとえば、４つのデータを構成する文字列をそのまま結合することにより得られるデータ）を用いており、同様に、クレジットカードβを用いた決済用の共通データβＣＯＭｎとしては、代用コードβＳＵＢｎ，マジックコードＭＡＧ，日付／時刻ＤＡＴＥ，決済回数βｉの４つのデータの組み合わせからなるデータを用いている。
【００６１】
共通データＣＯＭｎの一部として、代用コードＳＵＢｎを用いるのは、個々のユーザごとに、それぞれ異なる共通データを定義できるようにするためである。代用コードＳＵＢｎは、クレジットカード番号Ｃｎのハッシュ値として与えられるコードであり、基本的には、個々のユーザごと（実際には、個々のクレジットカードごと）に異なるコードになる。そこで、この代用コードＳＵＢｎを共通データＣＯＭｎの一部として用いれば、ユーザごとにそれぞれ異なる共通データＣＯＭｎを定義することが可能になる。
【００６２】
一方、マジックコードＭＡＧは、時期（年、月、日、週、時刻など）に応じて内容が変化する特有のコード（たとえば、任意の文字列）である。たとえば、１月は「松」、２月は「梅」、３月は「桜」、…というように、１２か月分のマジックコードＭＡＧを任意の文字列として定めておき、１月中に行われた決済には「松」なるマジックコードを採用し、２月中に行われた決済には「梅」なるマジックコードを採用する、というような運用を行えば、セキュリティをより向上させることができる。もちろん、月曜日、火曜日、水曜日、…というように曜日ごとに異なるマジックコードを設定することもできるし、偶数日と奇数日とで異なるマジックコードを設定するようなこともできる。このように、時期に応じて内容が変化するコードを共通データＣＯＭｎの一部に含ませておくことは、第三者による共通データの類推を困難にする上で極めて有効である。
【００６３】
日付／時刻ＤＡＴＥは、既に述べたとおり、決済時点の日付および時刻を示すデータである。たとえば、２０００年７月１５日午後３：００というようなデータが共通データＣＯＭｎの一部に組み込まれることになる。共通データＣＯＭｎの一部にこのようなデータを組み込む第１の理由は、上述したマジックコードＭＡＧと同様に、第三者による共通データの類推を困難にさせるためであり、第２の理由は、各決済処理ごとに異なる共通データを生成するためである。たとえば、第ｉ回目の決済が２０００年７月１５日午後３：００に行われ、第（ｉ＋１）回目の決済が同日の午後５：００に行われたとすれば、第ｉ回目の決済に用いられる共通データと第（ｉ＋１）回目の決済に用いられる共通データとは、それぞれ一部分が異なることになり、発生される決済識別コードＩＤ（ｎ，ｉ）とＩＤ（ｎ，ｉ＋１）も異なることになる。本発明を実施する上では、秘密アルゴリズムＡＲＧは、決済が行われるたびに毎回異なる決済識別コードが発生されるようなアルゴリズムにしておく必要があるが、このように、「決済が行われるたびに毎回異なるようなデータが含まれた共通データを用いる」というアルゴリズムを採用すれば、アルゴリズムの骨格自体を変更せずに、決済が行われるたびに毎回異なる決済識別コードを発生させることが可能になる。
【００６４】
もちろん、日付／時刻ＤＡＴＥは、必ずしも決済日時を示すコードにする必要はなく、たとえば、２０００年７月１５日というように決済日のみを含むコードにすることもできるし、午後３：００というように決済時のみを含むコードにすることもできる。また、２０００年７月１５日午後３時１３分２４．２秒のように、正確な秒までも含むコードにすることも可能であるが、あまり精度の高い時刻コードを用いると、ＩＣカード１３０内で決済識別コードを生成した時刻と、承認業者用情報処理装置３００内で決済識別コードを生成した時刻とが不一致となり、両者の決済識別コードが一致しなくなるおそれがあるので、ＩＣカード１３０側のクロックと承認業者用情報処理装置３００側のクロックとの誤差や、インターネット４００を介しての伝送遅延時間などを考慮して、両者で同一の時刻コードが用いられる範囲内の精度に抑える必要がある。
【００６５】
本実施形態では、更に、決済回数ｉ（αｉまたはβｉ）を共通データの一部として組み込むようにしている。その理由は、もちろん、各決済処理ごとに異なる共通データを生成するためである。上述したように、日付／時刻ＤＡＴＥなるコードを共通データの一部に組み込むことにより、原理的には、決済が行われるたびに毎回異なる決済識別コードを発生させることが可能である。しかしながら、上述した時刻精度の問題があるため、日付／時刻ＤＡＴＥなるコードについては、精度をあまり高めることはできない。したがって、日付／時刻ＤＡＴＥなるコードのみに依存して、毎回異なる決済識別コードを発生させるよりは、更に、決済回数を共通データの一部に組み込んだ方が好ましい。たとえば、日付／時刻ＤＡＴＥなるコードを分単位の精度で設定したとすると、１分以上の時間間隔をおいて２つの決済処理が行われた場合には、これらの決済処理ではそれぞれ異なる日付／時刻ＤＡＴＥが利用されることになるが、万一、１分以内に２つの決済処理が行われると、両決済処理で同一の日付／時刻ＤＡＴＥが利用されることになる。このような弊害を避けるためには、決済回数ｉを共通データの一部に組み込むようにするのが好ましい。この決済回数αｉ，βｉは、決済処理が行われるごとに逐次更新されることになる。
【００６６】
結局、図４に示す実施形態の場合、クレジットカードαを用いた第ｉ回目の決済には、代用コードαＳＵＢｎ，マジックコードＭＡＧ，日付／時刻ＤＡＴＥ，決済回数αｉなる４種類のデータの組み合わせからなる共通データαＣＯＭｎに対して、所定の秘密アルゴリズムＡＲＧが適用され、第ｉ回目の決済についての決済識別コードαＩＤ（ｎ，αｉ）が生成されることになる。同様に、クレジットカードβを用いた第ｉ回目の決済には、代用コードβＳＵＢｎ，マジックコードＭＡＧ，日付／時刻ＤＡＴＥ，決済回数βｉなる４種類のデータの組み合わせからなる共通データβＣＯＭｎに対して、所定の秘密アルゴリズムＡＲＧが適用され、第ｉ回目の決済についての決済識別コードβＩＤ（ｎ，αｉ）が生成されることになる。
【００６７】
図５は、図４に示すＩＣカード１３０内に格納されている情報に対応して、承認業者用情報処理装置３００内に格納されている情報の一例を示す図である。ここで、「ＰＲＧ」は、承認業者用情報処理装置３００に決済要求に対する承認処理を行わせるためのプログラムであり、「ＡＲＧ」は、ＩＣカード１３０内に格納されているのと同一の秘密アルゴリズムであり、「ＤＡＴＥ」は、現在の日付／時刻を示すコード（承認業者用情報処理装置３００の内蔵クロックに基づいて生成される）であり、マジックコードＭＡＧは、ＩＣカード１３０内に格納されているのと同一のマジックコードである。また、クレジットカードαあるいはβに関するデータとして、複数のユーザＵ１，Ｕ２，…，Ｕｎ，…に関するデータがそれぞれ格納されている。ここで、たとえば、クレジットカードαに関する第ｎ番目のユーザＵｎのデータとしては、図示のとおり、氏名αＮｎ，クレジットカード番号αＣｎ，有効期限αＤｎ，利用限度額αＬＬｎ，代用コードαＳＵＢｎ，決済回数αｉ，その他、ユーザＵｎの住所や電話番号、決済金額データなどが格納されることになる。
【００６８】
承認業者用情報処理装置３００側で決済識別コードＩＤ（ｎ，ｉ）を発生させる処理も、上述したＩＣカード１３０側での処理と全く同様である。すなわち、クレジットカードαを用いた第ｉ回目の決済には、代用コードαＳＵＢｎ，マジックコードＭＡＧ，日付／時刻ＤＡＴＥ，決済回数αｉなる４種類のデータの組み合わせからなる共通データαＣＯＭｎ（承認業者用情報処理装置３００内のデータベースに格納されているデータ）に対して、所定の秘密アルゴリズムＡＲＧが適用され、第ｉ回目の決済についての決済識別コードαＩＤ（ｎ，ｉ）が生成されることになる。決済要求に対する承認は、図４に示すプロセスでＩＣカード１３０内で生成された決済識別コードαＩＤ（ｎ，αｉ）と、図５に示すプロセスで承認業者用情報処理装置３００内で生成された決済識別コードαＩＤ（ｎ，αｉ）との一致を条件として行われることになる。もちろん、決済処理が完了した後は、承認業者用情報処理装置３００側でも決済回数αｉあるいはβｉの更新が行われる。
【００６９】
§４．いくつかの変形例
最後に、本発明に係るクレジットカードを用いた決済処理方法の変形例をいくつか述べておく、
【００７０】
(1) 前述した実施形態では、準備手続の段階で、共通データＣＯＭｎおよび秘密アルゴリズムＡＲＧをＩＣカード１３０内にロードし、以後、このロードした共通データＣＯＭｎおよび秘密アルゴリズムＡＲＧを使用し続けることになるが、セキュリティを向上させる上では、ＩＣカード１３０内にロードした共通データＣＯＭｎおよび秘密アルゴリズムＡＲＧの内容を所定の期間ごとに変更する処理を行うのが好ましい。具体的には、準備手続と同様に、ユーザ用情報処理装置１００と承認業者用情報処理装置３００とをインターネット４００を介して接続し、新たな共通データＣＯＭｎおよび秘密アルゴリズムＡＲＧへの変更処理が双方同時に行われるようにすればよい。
【００７１】
(2) 図４に示すＩＣカード１３０内には、各クレジットカードα，βの利用限度額αＬｎ，βＬｎが設定されている。一方、図５に示す承認業者用情報処理装置３００内にも、各クレジットカードの各ユーザごとに、クレジットカードの利用限度額（たとえば、クレジットカードαの第ｎ番目のユーザＵｎについては、利用限度額αＬＬｎ）が設定されている。ここで、承認業者用情報処理装置３００側に設定されている利用限度額αＬＬｎは、クレジットカード会社が設定した本来の利用限度額であり、ユーザＵｎは、１か月間に、この利用限度額αＬＬｎを越える決済を行うことはできない（そのような決済要求は否認されることになる）。これに対して、ＩＣカード１３０側に設定されている利用限度額αＬｎ（あるいはβＬｎ）は、準備手続の段階でユーザＵｎ自身が任意に設定できる限度額である。一般的には、αＬｎ＝αＬＬｎというように、クレジットカード会社が設定した利用限度額と同じ額を、ＩＣカード１３０内の利用限度額として設定すればよいが、敢えて、αＬｎ＜αＬＬｎのような設定を行い、無駄遣いを抑えるための自主管理の目的設定に用いることもできる。
利用限度額αＬｎの設定を行った場合、クレジットカードαを用いてこの利用限度額αＬｎを越えるような決済が行われる場合には、その旨の警告が提示されるようにしておく。たとえば、ＩＣカード１３０内に、今月の決済金額の累積値を記録しておくようにし、新たに決済しようとしている金額と、この累積値との合計が、利用限度額αＬｎを越えるような場合には、ＩＣカード１３０内のプログラム「ＰＲＧ」の機能によって、パソコン１１０の画面上に何らかの警告表示を行うようにしておけばよい。αＬｎ＜αＬＬｎなる設定が行われていた場合には、この警告表示を無視して決済を断行することができるようにしておいてもよいし、警告表示が出されたら当該決済は拒絶されるようにしておいてもよい。
【００７２】
(3) 前述の実施形態では、代用コードＳＵＢｎは唯一無二のユニークなコードであるものとしたが、本発明を実施する上では、必ずしも代用コードＳＵＢｎを唯一無二のコードにする必要はない。実用上は、代用コードＳＵＢｎとともにユーザの氏名Ｎｎが承認業者用情報処理装置３００側に送信されるので、仮に代用コードＳＵＢｎがユニークなものではなかったとしても、通常は、代用コードＳＵＢｎと氏名Ｎｎとの組合わせによって、ユーザＵｎを特定することが可能である。ただし、同姓同名のユーザも存在するので、代用コードＳＵＢｎは、できる限り他のユーザとは異なるコードを用いるのが好ましく、ユニークな代用コードＳＵＢｎを設定するのが好ましい。
【００７３】
(4) 前述の実施形態では、インターネット上の仮想ショッピングモールでの買い物の決済を、インターネット上で行う例について述べたが、本発明に係る決済方法は、必ずしもインターネット決済に限定されるものではない。たとえば、ユーザが実際の店舗に買い物や食事に行って代金を決済する場合、クレジットカードαやβを用いる代わりに、ＩＣカード１３０を用いて決済することも可能である。この場合、当該店舗に設置されたリーダライタ装置１２０にＩＣカード１３０を装着して決済を行えばよい。ＩＣカード１３０は、１枚で複数枚のクレジットカードとして機能することができ、かつ、クレジットカード以外の種々の機能を有しているので、多数のクレジットカードを所持する代わりに、このＩＣカード１３０を１枚だけ所持していれば、すべてのクレジットカードのアカウントを用いた決済が可能になる。このような利用形態では、ＩＣカード１３０を装着したシステムがユーザ用情報処理装置１００として機能することになる。ユーザ用情報処理装置１００は必ずしもユーザの自宅に設置されている必要はなく、上述の利用形態の場合は、店舗に設置されたパソコン１１０およびリーダライタ装置１２０が、ユーザ用情報処理装置１００としての機能を果たしていることになる。
【００７４】
(5) 本発明に係るユーザ用情報処理装置１００は、上述のように、ＩＣカード１３０のような携帯型情報処理装置を利用して実現することができる。ＩＣカードの場合、現在のところ、単独ではインタネットへの接続環境やデータ入力機能が備わっていないため、インターネット上の仮想ショッピングモールにおける決済を行う場合には、上述の実施形態のように、パソコン１１０およびリーダライタ装置１２０と組み合わせた形でユーザ用情報処理装置１００を構成する必要があるが、携帯電話や携帯型情報端末装置など、単独でインターネットに接続する環境をもった装置を利用することができれば、そのような装置を単独でユーザ用情報処理装置１００として用いることにより、インターネット上での決済が可能になる。
【００７５】
【発明の効果】
以上のとおり、本発明に係るクレジットカードを用いた決済処理方法によれば、各加盟店に対するセキュリティを十分に確保することが可能になる。特に、前述した実施形態によれば、次のような種々の効果が得られる。
(1) ＩＣカードを、クレジットカードの「子カード」として利用することになるが、ＩＣカードは十分なセキュリティ対策が施されているため、紛失や盗難という事故が発生しても、本物のクレジットカードに比べて安全性が高い。すなわち、ＩＣカードの内部に格納されたデータを不正な手段で外部に読み出すことは極めて困難であり、また、ＩＣカードの表面にはクレジットカード番号は記載されないので、ＩＣカードを目視しても、クレジットカード番号を認識することはできない。このため、紛失や盗難があっても、クレジットカード番号が第三者に知られる可能性は非常に低くなる。
(2) ＩＣカード製のクレジットが普及するようになるまでには、まだ数年かかると予想されているが、本発明に係る方法では、正式なＩＣカード製クレジットカードを用いる場合に比べて、カードの配布やカード発行のための審査といった作業に手間がかかることはないため、迅速な導入が可能になる。本発明は、特に、インターネットにおいてクレジットショッピングを実施したい場合に有効である。
(3) 本発明では、１枚のＩＣカードに所有者が異なる複数枚のクレジットカードを登録することも可能である。したがって、たとえば、家族全員のクレジットカードの共通の「子カード」となるようなＩＣカードを作成することも可能になり、柔軟な運用が期待できる。
(4) 「子カード」化されたＩＣカードの中には、必要な情報を記録しておくことができるので、端末装置からキー入力すべきデータ量を低減することができる。すなわち、代用コードや決済識別コードは、プログラムに基づいて自動的に加盟店へと送られるため、個々のユーザがこれらのコードを入力する必要はない。実用上、ユーザはこれらのコードの存在すら意識する必要はない。
【図面の簡単な説明】
【図１】インターネット上の仮想ショッピングモールで買い物をする場合の従来の一般的なクレジットカードによる決済処理方法の手順を説明するブロック図である。
【図２】インターネット上の仮想ショッピングモールで買い物をする場合の本発明に係るクレジットカードによる決済処理方法の手順を説明するブロック図である。
【図３】本発明で用いるユーザ用情報処理装置１００をＩＣカード１３０を利用して構成した基本構成を示すブロック図である。
【図４】図３に示すＩＣカード１３０における決済識別コードの発生手順を示す図である。
【図５】図３に示すＩＣカード１３０に格納された情報に対応した、承認業者用情報処理装置３００内の格納情報の一例を示す図である。
【符号の説明】
１０…クレジットカード
２０…決済用情報
３０…対応関係情報
１００…ユーザ用情報処理装置
２００…加盟店用情報処理装置
３００…承認業者用情報処理装置
４００…インターネット
ＡＲＧ，ＡＲＧｎ…秘密アルゴリズム
Ｃ，Ｃｎ…クレジットカード番号
ＣＯＭｎ…第ｎ番目のユーザの共通データ
Ｄ，Ｄｎ…クレジットカードの有効期限
ＤＡＴＥ…現時点の日付／時刻コード
ｉ…決済回数
ＩＤ（ｎ，ｉ）…第ｎ番目のユーザの第ｉ回目の決済時の決済識別コード
ＭＡＧ…マジックコード
Ｎ，Ｎｎ…ユーザの氏名
ＰＩＮ…ユーザ識別コード
ＰＲＧ…プログラム
ＳＵＢｎ，αＳＵＢｎ，βＳＵＢｎ…第ｎ番目のユーザの代用コード
Ｕｎ…第ｎ番目のユーザ
α，β…クレジットカード
α○○…クレジットカードαに関する○○
β○○…クレジットカードβに関する○○
【発明の属する技術分野】
本発明は、クレジットカードを用いた決済処理方法に関し、特に、インターネット上の仮想ショッピングモールでの買い物の決済を行うのに適したクレジットカードを用いた決済処理方法に関する。
【０００２】
【従来の技術】
近年のクレジットカードの普及はめざましく、最近では、１人のユーザが複数のクレジットカードを所持することも一般化しつつある。クレジットカードを利用すれば、現金を取り扱う必要がないため、ユーザと加盟店との双方に大きなメリットが得られ、クレジットカードの利用は、今後も益々普及してゆくものと予想される。クレジットカードを用いた決済処理は、古くは加盟店でクレジット決済用の伝票を作成し、この伝票をクレジットカード会社へ送る方法が採られていたが、最近は、各加盟店に設置された端末装置とクレジットカード会社の管理するホストコンピュータとをオンライン接続し、オンラインで情報のやりとりを行う方法が主流となってきている。
【０００３】
ここ数年来のインターネットの爆発的な普及により、インターネット上の仮想ショッピングモールでの買い物の決済にも、クレジットカードを用いるのが一般的になってきている。この場合、ユーザはパソコンや携帯型端末装置から個々の加盟店の仮想ショッピングモールのＷｅｂページにアクセスし、Ｗｅｂブラウザの画面上で所望の商品を選択した上で、当該商品の代金をクレジットカードで決済することになる。クレジットカードによる決済を行う際には、ユーザの氏名、クレジットカード番号、有効期限といった情報を加盟店側に伝える必要があるので、通常は、Ｗｅｂブラウザの画面上でこれらの各情報を入力し、インターネットを介して、加盟店のＷｅｂページを運営しているサイトのサーバ装置に送信する処理が行われる。加盟店は、ユーザから送信されてきたこれらの情報に、決済対象となる金額の情報を加えて、クレジットカード会社側のホストコンピュータに決済要求を出すことになる。クレジットカード会社側では、加盟店からの決済要求を受けたら、加盟店側から送信されてきたユーザの氏名、クレジットカード番号、有効期限を、ホストコンピュータ内の登録データと照合し、問題がなければ決済要求を承認する。
【０００４】
このように、クレジットカード会社では、基本的には、ユーザの氏名、クレジットカード番号、有効期限を照合して決済を行うので、これらの情報が犯罪者に盗まれると、悪用されるおそれがある。特に、インターネットの黎明期においては、ユーザがＷｅｂブラウザから送信したこれらの情報が、途中で不正に盗まれる事件が多発し、大きな社会問題となっていた。このような問題に対処するため、インターネット経由の情報送信のセキュリティを高める技術が開発されてきている。たとえば、現在では、ＳＳＬ（Secure Sockets Layer）と呼ばれるＴＣＰ／ＩＰ通信のセキュリティを確保するためのプロトコルが一般的に利用されており、このプロトコルにより送信した情報に対しては、実用上、十分なセキュリティを確保することが可能である。
【０００５】
【発明が解決しようとする課題】
このように、クレジットカードのユーザ氏名、番号、有効期限といった情報は、犯罪者の手に渡ると悪用されるおそれがある重要な情報であり、取り扱いには十分に注意する必要がある。もっとも、インターネット上の仮想ショッピングモールでの買い物の決済を、クレジットカードを用いて行う場合でも、上述のＳＳＬなどの技術を利用してこれらの情報を送信すれば、一応、送信経路上で情報が盗まれるような被害は未然に防ぐことができる。しかしながら、これまでのクレジットカードに対するセキュリティ対策は、加盟店自身が不正な行為をすることはない、ということを大前提としたものであり、加盟店自身が不正行為を働いた場合には、全く機能しないという問題を含んでいる。そもそも加盟店は、クレジットカード会社による厳密な審査により、十分に信頼がおける企業であるとの判断がなされた店であり、これまでは加盟店自身が不正行為をなすという事態は全く想定されていない。しかし、インターネット上のビジネスなどが普及すればするほど、クレジットカードの加盟店も多種多様となり、加盟店自身による不正行為、あるいはその従業者による不正行為が行われる可能性も高まってきている。加盟店のもとには、多数のユーザに関する氏名、クレジットカード番号、有効期限といった情報が集まるので、万一、これらの情報を不正に取得して横流しをするような従業者がいた場合には、ＳＳＬなどの技術により通信セキュリティを確保しても無力である。
【０００６】
このような問題点を解決するために、公開鍵暗号技術を利用したＳＥＴ（Secure Electronic Transaction ）なる決済方法が大手クレジットカード会社から提案され、現在、システムの実験が行われているが、かなり大掛かりなシステムが必要になるため、実用化には至っていない。
【０００７】
そこで本発明は、各加盟店に対するセキュリティを十分に確保することが可能なクレジットカードを用いた新規な決済処理方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
(1) 本発明の第１の態様は、クレジットカード会社から、所定の番号が付与されたクレジットカードの発行を受けたユーザが、当該クレジットカードの加盟店に対して当該クレジットカードを用いて決済を行うためのクレジットカードを用いた決済処理方法において、
個々のユーザについて準備を行う準備段階と、ユーザが特定の加盟店に対して決済を行う決済段階とを行い、
準備段階では、
個々のユーザが利用する個々のユーザ用情報処理装置が、当該ユーザに対して発行された特定のクレジットカードの番号の代わりに用いられるコードであって、個々のクレジットカードごとにユニークなコードである所定の代用コードを格納し、
この特定のクレジットカードによる決済を承認する権限をもった承認業者が管理する承認業者用情報処理装置が、個々のユーザごとのクレジットカード番号と代用コードとの対応関係を示す対応関係情報を格納し、
ユーザ用情報処理装置と承認業者用情報処理装置との双方が、所定の共通データを用いた演算処理により決済識別コードを発生させる所定のアルゴリズムを格納し、
決済段階では、
ユーザ用情報処理装置が、特定の加盟店が管理する加盟店用情報処理装置に対して、ユーザ用情報処理装置内に格納された代用コードと、ユーザ用情報処理装置によって発生された決済識別コードと、を送信し、
加盟店用情報処理装置が、ユーザ用情報処理装置から送信されてきた代用コードおよび決済識別コードを、承認業者用情報処理装置に送信することにより決済要求を出し、
この決済要求を受けた承認業者用情報処理装置が、予め格納されていた対応関係情報に基づき、送信されてきた代用コードに１対１に対応するクレジットカード番号を参照することによりユーザを特定し、当該ユーザについての共通データを用いた演算処理により決済識別コードを発生し、発生した決済識別コードと送信されてきた決済識別コードとが一致することを条件として、決済要求に対する承認を行い、
個々のユーザ用情報処理装置には、少なくとも、格納されている代用コードと、決済に用いるクレジットカードによる決済回数を示すコードと、を含む共通データを作成し、当該共通データを用いた演算処理により決済識別コードを発生させるアルゴリズムを格納しておき、承認業者用情報処理装置には、個々のユーザ用情報処理装置に格納されているアルゴリズムとそれぞれ同じアルゴリズムを格納しておき、
決済が行われる際には、ユーザ用情報処理装置と承認業者用情報処理装置との双方において、共通データを用いた同じアルゴリズムによる演算処理を行うことにより、それぞれ同一の決済識別コードが発生できるようにしたものである。
【００１０】
(2) 本発明の第２の態様は、上述の第１の態様に係るクレジットカードを用いた決済処理方法において、
特定のクレジットカードの番号の代わりに用いられる代用コードを、当該特定のクレジットカードの番号を利用して発生させるようにしたものである。
【００１２】
(3) 本発明の第３の態様は、上述の第１または第２の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置と承認業者用情報処理装置との双方で作成される共通データとして、時期に応じて内容が変化するマジックコードを含むデータを用いるようにしたものである。
【００１３】
(4) 本発明の第４の態様は、上述の第１または第２の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置と承認業者用情報処理装置との双方で作成される共通データとして、決済日、決済時、もしくは決済日時を示すコードを含むデータを用いるようにしたものである。
【００１５】
(5) 本発明の第５の態様は、上述の第１〜第４の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置と承認業者用情報処理装置とをネットワークを介して接続し、所定の期間ごとに、共通データ作成用もしくは決済識別コード発生用のアルゴリズムの内容を変更する処理を行うようにしたものである。
【００１６】
(6) 本発明の第６の態様は、上述の第１〜第５の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置内に、クレジットカードの利用限度額を示す情報を格納できるようにし、この利用限度額を越える決済が行われる場合には、その旨の警告が提示されるようにしたものである。
【００１７】
(7) 本発明の第７の態様は、上述の第１〜第６の態様に係るクレジットカードを用いた決済処理方法において、
特定のユーザが複数のクレジットカード会社からそれぞれクレジットカードの発行を受けているときに、各クレジットカードごとにそれぞれ別個の代用コードを作成してユーザ用情報処理装置に格納し、承認業者用情報処理装置には、各代用コードと各クレジットカード番号との対応関係を示す対応関係情報を格納し、複数のクレジットカードの中からユーザが選択した特定のクレジットカードについての決済処理を行うことができるようにしたものである。
【００１８】
(8) 本発明の第８の態様は、上述の第１〜第７の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置、加盟店用情報処理装置、承認業者用情報処理装置を、それぞれネットワークを介して接続し、加盟店のＷｅｂページ上に開かれた仮想ショッピングモールでユーザが買い物をした際に、ネットワークを介して代用コードおよび決済識別コードを送信することにより決済が行われるようにしたものである。
【００１９】
(9) 本発明の第９の態様は、上述の第１〜第８の態様に係るクレジットカードを用いた決済処理方法において、
ユーザ用情報処理装置を、ＩＣカードと、このＩＣカードに対する情報伝送を行うリーダライタ装置と、このリーダライタ装置を介してＩＣカードへのアクセスを行うコンピュータと、によって構成し、少なくとも決済処理を行う際に、ＩＣカードをリーダライタ装置に装着してコンピュータによってアクセスを行うことにより、ユーザ用情報処理装置としての機能を実現させるようにしたものである。
【００２０】
(10) 本発明の第１０の態様は、上述の第９の態様に係るクレジットカードを用いた決済処理方法において、
少なくとも、共通データおよび秘密アルゴリズムをＩＣカード内のメモリに格納し、決済識別コードの発生処理を、ＩＣカード内において実行するようにしたものである。
【００２２】
【発明の実施の形態】
以下、本発明を図示する実施形態に基づいて説明する。
【００２３】
§１．インターネット上での従来の一般的な決済処理方法
はじめに、インターネット上の仮想ショッピングモールで買い物をする場合の従来の一般的なクレジットカードによる決済処理方法の手順を説明する。図１は、この手順を示すブロック図である。この例では、ユーザ用情報処理装置１００、加盟店用情報処理装置２００、承認業者用情報処理装置３００がインターネット４００を介して接続される。ユーザ用情報処理装置１００は、ユーザの管理下にある情報処理装置であり、一般的には、インターネット４００に接続する機能を有するパソコンや携帯型情報端末装置がユーザ用情報処理装置１００として利用されている。加盟店用情報処理装置２００は、クレジットカードの加盟店によって管理されている情報処理装置であり、一般的には、仮想ショッピングモールのＷｅｂページのサイトを提供するＷｅｂサーバ装置が加盟店用情報処理装置２００として利用されることになる。承認業者用情報処理装置３００は、クレジットカードによる決済を承認する権限をもった承認業者（クレジットカード会社自身もしくはその委託を受けた特定の業者）によって管理される情報処理装置であり、通常は、比較的大規模なホストコンピュータによって構成される。
【００２４】
ユーザは、クレジットカード会社からクレジットカード１０の発行を受けており、このクレジットカード１０には、ユーザの氏名Ｎ、クレジットカード番号Ｃ、有効期限Ｄなる情報が記載されている（通常、エンボス加工によって刻まれている）。もちろん、クレジットカードによっては、この他にも種々の情報が記載されている場合がある。一方、このクレジットカード１０上に記載された情報は、承認業者用情報処理装置３００内のデータベースにも登録されている。このデータベースには、更に、各ユーザの住所、電話番号、勤務先、過去の決済履歴などのデータも格納されている。
【００２５】
加盟店が運営する仮想ショッピングモールを利用するには、ユーザは、ユーザ用情報処理装置１００のＷｅｂブラウザ機能を用いて、加盟店用情報処理装置２００内のサイトの所定のＷｅｂページにアクセスすればよい。いま、ユーザが、このＷｅｂページ上で所望の商品を購入し、クレジットカード１０を利用してその代金を決済する場合を考えよう。この場合、ユーザは手元にクレジットカード１０を用意し、Ｗｅｂ画面上で、氏名Ｎ、クレジットカード番号Ｃ、有効期限Ｄなる情報をキーボードなどを用いて入力する。入力したこれらの情報は、インターネット４００を介して、加盟店用情報処理装置２００へと送信される。通常、この送信処理は、ＳＳＬなどのセキュリティが確保されたプロトコルにより行われるため、インターネット４００の伝送経路上でこれらの情報が盗まれる可能性は非常に小さい。こうして、加盟店用情報処理装置２００に、ユーザが送信したこれらの情報が到達すると、今度は、加盟店が、自己の店名や決済金額などの情報を付加して、これらの情報をインターネット４００を介して（場合によっては、別な通信線を介して）、承認業者用情報処理装置３００へと送信して承認を求める。承認業者は、承認業者用情報処理装置３００内のデータベースに登録されている情報と、加盟店から送信されてきた情報とを照合し、問題がなければ当該決済を承認することになる。
【００２６】
結局、クレジットカード１０上の氏名Ｎ，クレジットカード番号Ｃ，有効期限Ｄという情報は、ユーザ用情報処理装置１００から加盟店用情報処理装置２００へと送信され、更に、加盟店用情報処理装置２００から承認業者用情報処理装置３００へと送信されることになる。このような送信経路におけるセキュリティは、前述したように、ＳＳＬなどの技術によって実用上十分なレベルまで確保されている。しかしながら、このようなセキュリティ対策は、加盟店自身が不正な行為をすることはない、ということを大前提としたものである。加盟店用情報処理装置２００内には、多数のユーザのクレジットカードに関する情報が蓄積されており、万一、これらの蓄積情報を不正に取得して横流しをするような従業者が加盟店内にいた場合、クレジットカード情報に対するセキュリティ対策は根底から覆されてしまう。本発明は、このような問題を解決するための新たな決済処理方法を提案するものである。
【００２７】
§２．本発明に係る決済処理方法の基本概念
続いて、図２のブロック図を参照しながら、本発明に係るクレジットカードを用いた決済処理方法の基本概念を説明する。この図２に示す例は、図１に示す例と同様に、ユーザ、加盟店、承認業者の三者間での決済処理の手順を示しているが、ここでは、多数のユーザのうちの第ｎ番目のユーザという意味で、特定のユーザＵｎが決済処理を行う場合の処理手順を示すことにする。図に示す各符号のサフィックス「ｎ」は、この第ｎ番目のユーザについての情報であることを示すものである。
【００２８】
図１に示す例と同様に、この図２の例でも、ユーザ用情報処理装置１００、加盟店用情報処理装置２００、承認業者用情報処理装置３００がインターネット４００を介して接続される。やはり、ユーザ用情報処理装置１００は、ユーザの管理下にある情報処理装置であり、一般的には、インターネット４００に接続する機能を有するパソコンや携帯型情報端末装置がユーザ用情報処理装置１００として利用されることになる。ただ、実用上は、後に§３で述べるように、ＩＣカードをユーザ用情報処理装置１００の一部として利用するのが好ましい。加盟店用情報処理装置２００は、前述したように、クレジットカードの加盟店によって管理されている情報処理装置であり、仮想ショッピングモールのＷｅｂページのサイトを提供するＷｅｂサーバ装置によって構成される。また、承認業者用情報処理装置３００は、前述したように、承認業者によって管理される比較的大規模なホストコンピュータによって構成され、各ユーザに関する種々の情報をデータベースとして格納する機能を有している。
【００２９】
この図２に示す決済処理方法は、あくまでもクレジットカードを用いた決済処理方法であり、その点では、図１に示す従来の決済処理方法と同じである。すなわち、第ｎ番目のユーザＵｎは、クレジットカード会社から予めクレジットカード１０の発行を受けており、このクレジットカード１０には、ユーザの氏名Ｎｎ、クレジットカード番号Ｃｎ、有効期限Ｄｎなる情報が記載されている。ただし、従来の決済処理方法では、加盟店側にこれらの各情報を知らせる必要があるが、本発明に係る決済処理方法では、その必要がなくなる。もっとも、この新規な決済処理方法を利用するためには、ユーザは事前に、承認業者との間で所定の準備手続を行っておく必要がある。
【００３０】
この準備手続は、特定のユーザＵｎと承認事業者との間で、代用コードＳＵＢｎ，共通データＣＯＭｎ，秘密アルゴリズムＡＲＧｎなる決済用情報２０を決める手続きである。代用コードＳＵＢｎは、ユーザＵｎに対して発行されたクレジットカード番号Ｃｎの代わりに用いられるコードであり、加盟店に対しては、クレジットカード番号Ｃｎの代わりに、この代用コードＳＵＢｎが知らされることになる。この代用コードＳＵＢｎは、ユーザ用情報処理装置１００内に格納されるとともに、承認業者用情報処理装置３００内にも格納される。しかも、承認業者用情報処理装置３００内へは、代用コードＳＵＢｎとクレジットカード番号Ｃｎとの対応関係を示す対応関係情報３０として格納される。もともと承認業者用情報処理装置３００内には、多数のユーザについて、それぞれこれまでに発行したクレジットカードの番号が格納されている。本発明では、この承認業者用情報処理装置３００内に、更に、個々のユーザごとのクレジットカード番号との対応関係を示す対応関係情報３０として、各代用コードが格納されるので、承認業者に対して、特定の代用コードを知らせると、これに対応したクレジットカード番号を参照することができ、ユーザを特定することができる。
【００３１】
なお、特定の代用コードに対して、特定のクレジットカード番号を１対１に対応させるためには、個々のクレジットカードごとにそれぞれユニークな代用コードを定義するようにすればよい。世界中で唯一無二の代用コードをそれぞれ各クレジットカードごとに定義し、このようなユニークな代用コードを用いるようにすれば、対応関係情報３０に基づいて、特定の代用コードと特定のクレジットカード番号とを１対１に対応させることができる。すなわち、特定の代用コードを用いて決済要求を受けた承認業者は、当該代用コードに対して１対１に対応するクレジットカード番号を対応関係情報３０に基づいて参照することができる。
【００３２】
このようなユニークな代用コードを定義する最も簡単な方法は、十分な桁数をもった乱数を発生させ、この乱数に基づいて所定桁の代用コードを定める方法である。このような乱数を用いた方法では、理論的には、全く同一の代用コードが偶然に発生される可能性があるが、その可能性が実用上零とみなせる程度の十分な桁数の乱数を用いるようにすれば、実質的には、ユニークな代用コードを得ることができる。ユニークな代用コードを定義するためのより実用的な方法は、クレジットカード番号を利用する方法である。現在流通しているクレジットカード番号は、各クレジットカード会社が相互に調整することにより、世界中で唯一無二のユニークな１６桁の番号となっている。したがって、特定のクレジットカード番号についての代用コードを定めるのに、当該クレジットカード番号自身を利用した方法を採れば、やはりユニークな代用コードを定義することができる。具体的には、たとえば、クレジットカード番号Ｃｎ（あるいはそれに更にユーザの氏名Ｎｎなどを必要に応じて付加したデータ列）に対してハッシュ関数を作用させて得られるハッシュ値を、当該クレジットカード番号Ｃｎの代用コードとすればよい。
【００３３】
一方、共通データＣＯＭｎは、ユーザ用情報処理装置１００と承認業者用情報処理装置３００との双方に格納されるべきデータであり、個々のユーザごとに異なるデータであれば、どのようなデータであってもかまわない。たとえば、上述した代用コードＳＵＢｎを、そのまま共通データＣＯＭｎとして用いることも可能である。ただ、この共通データＣＯＭｎは、セキュリティを確保する上で、ユーザＵｎと承認業者との間だけの秘密のデータとして保持されていることが好ましく、そのような意味では、代用コードＳＵＢｎだけでなく、より複雑なデータを利用するのが好ましい。この共通データＣＯＭｎのより実用的な例については、§３で述べることにする。同様に、秘密アルゴリズムＡＲＧｎも、ユーザ用情報処理装置１００と承認業者用情報処理装置３００との双方に格納されるべきものであり、共通データＣＯＭｎを用いた何らかの演算処理を定義するものであれば、どのようなアルゴリズムでもよい。もっとも、この秘密アルゴリズムＡＲＧｎも、セキュリティを確保する上で、ユーザＵｎと承認業者との間だけの秘密のアルゴリズムとして保持されていることが好ましく、そのような点では、第三者による類推が困難になるように、できるだけ複雑なアルゴリズムにするのが好ましい。
【００３４】
この秘密アルゴリズムＡＲＧｎは、共通データＣＯＭｎを用いた演算により、所定の決済識別コードＩＤ（ｎ，ｉ）を発生させる機能を有している。この決済識別コードＩＤ（ｎ，ｉ）の文字「ｎ」は、第ｎ番目のユーザＵｎのためのコードであることを示しており、文字「ｉ」は第ｉ回目の決済のために発生されたコードであることを示している。別言すれば、決済識別コードＩＤ（ｎ，ｉ）は、各ユーザごとに異なるコードであるとともに、決済が行われるたびに毎回異なるコードということになる。上述したように、共通データＣＯＭｎは各ユーザごとに異なるデータであるから、この共通データＣＯＭｎを用いて発生される決済識別コードＩＤ（ｎ，ｉ）は、当然、各ユーザごとに異なるコードとなるが、同一のユーザＵｎについて発生された決済識別コードＩＤ（ｎ，ｉ）であったとしても、第１回目の決済のときには、決済識別コードＩＤ（ｎ，１）が発生され、第２回目の決済のときには、決済識別コードＩＤ（ｎ，２）が発生される、というように、決済ごとに異なる決済識別コードＩＤ（ｎ，ｉ）が発生されるようにしておく。逆に言えば、秘密アルゴリズムＡＲＧｎとして、決済が行われるたびに毎回異なる決済識別コードが発生されるようなアルゴリズムを定めておくようにすればよい。
【００３５】
かくして、この準備段階では、ユーザＵｎと承認業者との間で、代用コードＳＵＢｎ，共通データＣＯＭｎ，秘密アルゴリズムＡＲＧｎが定められ、これらの決済用情報２０は、ユーザ用情報処理装置１００と承認業者用情報処理装置３００との双方に格納される。なお、ここでは、代用コードＳＵＢｎ，共通データＣＯＭｎ，秘密アルゴリズムＡＲＧｎのいずれもが、各ユーザごとに異なる例を示しているが、秘密アルゴリズムＡＲＧｎについては、必ずしも各ユーザごとに変える必要はなく、全ユーザについて共通の秘密アルゴリズムＡＲＧを用いるようにしてもかまわない。実用上は、簡便な運用を図るために、全ユーザについて共通の秘密アルゴリズムＡＲＧを用いるようにした方が好ましい。
【００３６】
このように、双方に同一の決済用情報２０が格納されているため、ユーザ用情報処理装置１００側で第ｎ番目のユーザＵｎの第ｉ回目の決済のために発生させた決済識別コードＩＤ（ｎ，ｉ）と、承認業者用情報処理装置３００側で発生させた同コードとは、全く同一になる。すなわち、ユーザ用情報処理装置１００と承認業者用情報処理装置３００との双方において、共通データＣＯＭｎを用いた秘密アルゴリズムＡＲＧｎによる演算処理を行うことにより、それぞれ同一の決済識別コード決済識別コードＩＤ（ｎ，ｉ）が発生されることになる。
【００３７】
さて、上述した準備手続が完了したら、ユーザＵｎは、この新規な決済処理方法を利用してクレジットカード決済を行うことが可能になる。いま、ユーザＵｎが、加盟店の提供するＷｅｂページ上で所望の商品を購入し、クレジットカード１０を利用してその代金を決済する場合を考えよう。従来の方法では、図１で説明したように、加盟店用情報処理装置２００に対して、氏名Ｎｎ，クレジットカード番号Ｃｎ，有効期限Ｄｎを送信する必要があったが、本発明に係る方法では、少なくとも、ユーザ用情報処理装置１００内に格納されている代用コードＳＵＢｎと、ユーザ用情報処理装置１００によって発生された決済識別コードＩＤ（ｎ，ｉ）とを送信すればよい。加盟店用情報処理装置２００は、ユーザＵｎから送信されてきた代用コードＳＵＢｎおよび決済識別コードＩＤ（ｎ，ｉ）を、承認業者用情報処理装置３００に送信することにより決済要求を出すことになる。
【００３８】
このような決済要求を受けた承認業者用情報処理装置３００は、まず、対応関係情報３０に基づいて、送信されてきた代用コードＳＵＢｎに対応するクレジットカード番号Ｃｎを参照することによりユーザＵｎを特定する。従来は、クレジットカード番号Ｃｎの送信を受けることによりユーザＵｎの特定を行っていたわけであるが、本発明では、クレジットカード番号Ｃｎの代わりに代用コードＳＵＢｎを送信することにより、ユーザＵｎの特定が可能になる。続いて、承認業者用情報処理装置３００は、このユーザＵｎについての共通データＣＯＭｎを用い、秘密アルゴリズムＡＲＧｎに基づく演算を行うことにより、決済識別コードＩＤ（ｎ，ｉ）を発生させる。そして、加盟店用情報処理装置２００側から決済要求とともに送信されてきた決済識別コードＩＤ（ｎ，ｉ）と、内部で発生させた決済識別コードＩＤ（ｎ，ｉ）とが一致するか否かを判定する。両者が一致すれば、加盟店用情報処理装置２００側からの当該決済要求は、ユーザＵｎの正当なカード利用に基づく要求であると認定し、これに対する承認を行うことになる。もちろん、両者が一致しなかった場合には、何らかの不正な要求であるか、何らかの誤りに基づく要求であると認定し、当該決済要求に対する否認処理が行われることになる。
【００３９】
なお、実用上は、ユーザ用情報処理装置１００から加盟店用情報処理装置２００に対して送信される情報には、代用コードＳＵＢｎおよび決済識別コードＩＤ（ｎ，ｉ）だけでなく、ユーザＵｎの氏名や住所などの情報や、買い物対象となる商品やその個数などを示すデータも含まれることになるが、このような情報送信についての図示は省略している。また、加盟店用情報処理装置２００から承認業者用情報処理装置３００に対して送信される情報には、代用コードＳＵＢｎおよび決済識別コードＩＤ（ｎ，ｉ）だけでなく、ユーザＵｎの氏名，決済金額，加盟店自身を特定する識別コードなどのデータも含まれることになるが、このような情報送信の図示も省略している。
【００４０】
このように、本発明に係る決済処理方法によれば、従来の決済処理方法と全く同様のスムーズな決済処理が可能になる。しかも、重要な点は、加盟店側には、クレジットカード番号Ｃｎや有効期限Ｄｎという情報が送信されないという点である。有効期限Ｄｎについては、送信しても特に問題はないが、クレジットカード番号Ｃｎについては、加盟店側に送信を行うとセキュリティの面で問題が生じることになる。前述したように、加盟店用情報処理装置２００内に、ユーザＵｎの氏名Ｎｎとクレジットカード番号Ｃｎとのデータが蓄積されることになるため、不正利用の危険性が生じるからである。
【００４１】
本発明の特徴は、代用コードＳＵＢｎと決済識別コードＩＤ（ｎ，ｉ）とを組み合わせることにより、セキュリティの向上を図った点にある。これは、代用コードＳＵＢｎだけを用いた決済処理では、セキュリティの面で問題が生じるためである。すなわち、もし、代用コードＳＵＢｎだけを用いた決済処理を行ったとすると、加盟店用情報処理装置２００内には、特定のユーザＵｎについての氏名Ｎｎと代用コードＳＵＢｎとが蓄積されることになるので、この氏名Ｎｎと代用コードＳＵＢｎとを盗み取った犯罪者が、不正な手段で承認業者用情報処理装置３００にアクセスし、ユーザＵｎが買い物をしたように見せかけた決済要求を行う危険性がある。ところが、本発明で正当な決済を行うためには、代用コードＳＵＢｎと決済識別コードＩＤ（ｎ，ｉ）との組み合わせが必要になる。しかも、決済識別コードＩＤ（ｎ，ｉ）は、決済を行うたびに毎回異なるコードとなるようにしてあるため、同一の決済識別コードＩＤ（ｎ，ｉ）を用いた決済は１回だけに限られる。万一、同一の決済識別コードＩＤ（ｎ，ｉ）を用いた２回目の決済要求があっても、承認業者用情報処理装置３００は、そのような決済要求を否認することになる。
【００４２】
たとえば、ユーザＵｎが第ｉ回目の決済として、正当な決済を行ったとすると、代用コードＳＵＢｎと、第ｉ回目の決済についての決済識別コードＩＤ（ｎ，ｉ）とが、承認業者用情報処理装置３００に送信されることになるので、この場合は、正当な決済要求であるとして承認される。このとき、加盟店用情報処理装置２００内には、決済に用いた代用コードＳＵＢｎと決済識別コードＩＤ（ｎ，ｉ）とが残っていることになるので、加盟店の従業員などがこれらの情報を不正利用して、虚偽の決済要求を出すかもしれない。ところが、このような虚偽の決済要求は、第（ｉ＋１）回目の決済要求ということになるので、承認業者用情報処理装置３００内で発生される決済識別コードがＩＤ（ｎ，ｉ＋１）であるのに対し、虚偽の決済要求により送信されてきた決済識別コードはＩＤ（ｎ，ｉ）であるため、両者は不一致となり、虚偽の決済要求は否認されることになる。いわば、決済識別コードＩＤ（ｎ，ｉ）は、個々の決済ごとに使い捨てのコードということになり、たとえ不正な方法で代用コードＳＵＢｎと決済識別コードＩＤ（ｎ，ｉ）とが盗まれたとしても、虚偽の決済が承認されることはないのである。
【００４３】
このように、本発明に係るクレジットカードを用いた決済処理方法では、加盟店側にクレジットカード番号Ｃｎを知らせる必要がないので、クレジットカード番号Ｃｎの盗難による不正利用を防止することができる。加盟店側には、代用コードＳＵＢｎおよび決済識別コードＩＤ（ｎ，ｉ）を知らせる必要はあるが、決済識別コードＩＤ（ｎ，ｉ）は各決済ごとに異なる使い捨てコードになるため、万一盗まれたとしても、不正に利用されることはない。
【００４４】
§３．本発明に係る具体的な決済処理方法
続いて、本発明に係るクレジットカードを用いた決済処理方法のより具体的な実施形態を述べる。ここで述べる実施形態の第１の特徴は、ユーザ用情報処理装置１００として、ＩＣカードを利用した点にあり、第２の特徴は、複数のクレジットカードについて適用できるようにした点にある。
【００４５】
図３は、この実施形態で用いられるユーザ用情報処理装置１００の基本構成を示すブロック図である。ここに示す例では、ユーザ用情報処理装置１００は、パソコン１１０、リーダライタ装置１２０、ＩＣカード１３０によって構成されている。ＩＣカード１３０としては、ＣＰＵおよびメモリを内蔵した演算処理機能をもったＩＣカードであれば、どのようなＩＣカードを用いてもかまわない。最近は、磁気カードに代わる携帯型情報記録媒体として、種々のタイプのＩＣカードが普及し始めている。一般に、ＩＣカードは、ソフトウエアをロードすることにより様々な機能を付加することができるので、ＩＣカードを利用して本発明に係る決済処理方法を実施する場合、必ずしも新たな専用のＩＣカードをユーザに配付する必要はない。ユーザが既に何らかのＩＣカードを所持しているのであれば、このＩＣカードに、本発明に係る決済処理方法を実行するための専用ソフトウエアあるいは専用のデータ、またはその両方をロードするだけで、既存のＩＣカードをそのまま利用して本発明を実施することが可能になる。
【００４６】
リーダライタ装置１２０は、このＩＣカード１３０に対する情報伝送を行う汎用の読取／書込装置であり、パソコン１１０は、このリーダライタ装置１２０を介してＩＣカード１３０へのアクセスを行う汎用のコンピュータである。ここ数年来、個人レベルでのパソコン所有率が高まり、かなりのユーザがパソコンを所有し、インターネットへの接続環境を備えている。本発明による決済処理方法を利用する場合、このような汎用のパソコン１１０に、汎用のリーダライタ装置１２０を接続し、所定のソフトウエアをロードしたＩＣカード１３０を用意すればよい。このＩＣカード１３０をリーダライタ装置１２０に装着し、パソコン１１０によってアクセスを行うようにすれば、このシステムが全体として、§２で述べたユーザ用情報処理装置１００として機能することになる。
【００４７】
このように、本実施形態では、パソコン１１０，リーダライタ装置１２０，ＩＣカード１３０からなるシステムによって、ユーザ用情報処理装置１００が構成されることになるが、実質的には、ＩＣカード１３０がユーザ用情報処理装置１００としての主たる機能を果たし、パソコン１１０およびリーダライタ装置１２０は、このＩＣカード１３０をインターネット４００へ接続するためのインターフェイスとしての役割を果たしているにすぎない。すなわち、本発明において重要な機能を果たす情報は、いずれもＩＣカード１３０内に格納されることになる。以下、このＩＣカード１３０内に格納されている情報について説明する。
【００４８】
図３に示すように、ＩＣカード１３０内には、「ＰＲＧ」，「ＡＲＧ」，「ＰＩＮ」，「ＤＡＴＥ」，「ＭＡＧ」なる情報が収容されている。ここで、「ＰＲＧ」は、このＩＣカード１３０を本発明に係るユーザ用情報処理装置１００の主たる構成要素として機能させるためのプログラムであり、§２で述べたユーザ用情報処理装置１００の各機能は、このプログラムの制御のもとに実現されることになる。また、「ＡＲＧ」は、図２に示す決済用情報２０内の秘密アルゴリズムＡＲＧｎに相当するアルゴリズムであり、承認業者用情報処理装置３００側にも同じ秘密アルゴリズムが格納されている。この実施形態では、すべてのユーザについて同一のアルゴリズムを採用している。次の「ＰＩＮ」は、このＩＣカード１３０の利用を可能にするためのユーザＵｎ自身の識別コードである。ユーザＵｎは、このＩＣカード１３０をリーダライタ装置１２０に装着した後、パソコン１１０から正しい「ＰＩＮ」コードを入力する作業を行う。入力した「ＰＩＮ」コードは、ＩＣカード１３０内部の「ＰＩＮ」コードと照合され、両者が一致していた場合に、以後のＩＣカード１３０へのアクセスが許可されることになる。この「ＰＩＮ」コードの照合機能は、一般的なＩＣカード１３０には必ず備わっている既存の機能であり、本発明に固有の機能というわけではない。「ＤＡＴＥ」は、現在の日付および時刻を示すデータであり、一般に、外部からＩＣカード１３０に知らされる（ＩＣカードの中では、知らされた日付がシーケンシャルであるかをチェックすることもある。）。また、「ＭＡＧ」はいわゆるマジックコードであり、後述するように、共通データＣＯＭｎの一部として利用され、承認業者用情報処理装置３００側にも同じマジックコードが格納されている。
【００４９】
上述の各情報のうち、「ＰＩＮ」はＩＣカード１３０を利用するための基本的なコードであり、「ＤＡＴＥ」はＩＣカード１３０に対して外部から与えられるデータであるので、いずれも、一般的なＩＣカードに標準的に備わっている情報と言うことができる。これに対して、「ＰＲＧ」，「ＡＲＧ」，「ＭＡＧ」は、本発明の実施のために用意される専用の情報であり、ユーザＵｎが準備手続を行う際に、外部からロードされる情報である。ユーザＵｎが既に所有している既存のＩＣカード（たとえば、社員証として機能するＩＣカード、診察券として機能するＩＣカード、サービスポイントを貯めるためのＩＣカードなど、既に種々のＩＣカードが実際に利用されている）を、本発明のためにも流用するというケースの場合は、準備手続を行うときに、パソコン１１０から、これら専用の情報をＩＣカード１３０側へとロードすればよい。ロード対象となるこれら専用の情報は、ＣＤ−ＲＯＭなどに収容してユーザＵｎに配付してもよいし、インターネット４００を介してパソコン１１０へダウンロードさせるようにしてもよい。もちろん、「ＰＲＧ」，「ＡＲＧ」，「ＭＡＧ」といったデータが予めロードされたＩＣカードを用いて、社員証、診察券、サービスポイントカードなどを発行し、これを配布するようにすれば、これらのデータをロードする処理は不要になる。
【００５０】
準備手続においてユーザＵｎが行う作業は、これら専用の情報をＩＣカード１３０にロードする作業と（上述したように、これらの専用情報が予めロードされたＩＣカードが配布されていた場合は、このロード作業は不要である。）、クレジットカードに関するデータをＩＣカード１３０へ入力する作業である。図３に示す例では、ユーザＵｎが、異なる２つのクレジットカード会社から、それぞれクレジットカードαおよびクレジットカードβなるクレジットカードの発行を受けており、この２枚のクレジットカードの情報をＩＣカード１３０へ入力して利用する例が示されている。このような情報入力は、既にＩＣカード１３０内にロードされているプログラム「ＰＲＧ」の処理機能に基づいて行うことができる。図示の例の場合、クレジットカードαに記載されている氏名αＮｎ，クレジットカード番号αＣｎ，有効期限αＤｎと、クレジットカードβに記載されている氏名βＮｎ，クレジットカード番号βＣｎ，有効期限βＤｎと、をＩＣカード１３０内に書き込む作業が行われることになる（氏名αＮｎと氏名βＮｎとは同一である必要はなく、たとえば、一方を家族名義にしてもかまわない。）。ユーザＵｎは、クレジットカードα，βを手元に置いて、パソコン１１０のキーボードなどから、これらのデータを入力する作業を行う。なお、この例では、更に、利用限度額αＬｎ，βＬｎを入力している。この利用限度額αＬｎ，βＬｎの役目については、§４の変形例のところで述べる。
【００５１】
こうして、各クレジットカードα，βについて、氏名αＮｎ，βＮｎ，クレジットカード番号αＣｎ，βＣｎ，有効期限αＤｎ，βＤｎ，利用限度額αＬｎ，βＬｎの入力作業が完了すると、続いて、代用コードαＳＵＢｎ，βＳＵＢｎを発生させる処理が行われる。ここに示す実施例では、ＩＣカード１３０にロードされているプログラム「ＰＲＧ」内に、この代用コードを発生させる処理ルーチンを組み込んでおり、ユーザＵｎが入力したクレジットカード番号αＣｎ，βＣｎに基づいて、ＩＣカード１３０の内部で代用コードαＳＵＢｎ，βＳＵＢｎが発生され、そのままＩＣカード１３０内部に格納される。具体的には、この実施形態の場合、１６桁の数字からなるクレジットカード番号αＣｎ，βＣｎに対してハッシュ関数を作用させ、得られるハッシュ値を代用コードαＳＵＢｎ，βＳＵＢｎとして用いるようにしている。セキュリティを更に高める上では、１６桁のクレジットカード番号に、更に何らかの文字列（たとえば、マジックコード「ＭＡＧ」など）を付加してから、ハッシュ関数を作用させるのが好ましい。一般に、ハッシュ関数は一方向性の関数とされており、クレジットカード番号Ｃｎにハッシュ関数を作用させてハッシュ値（代用コード）ＳＵＢｎを得る演算は誰でも行うことができるが、逆に、ハッシュ値ＳＵＢｎを元のクレジットカード番号Ｃｎに戻すことはできない。したがって、ハッシュ値を代用コードＳＵＢｎとして用いれば、代用コードＳＵＢｎが第三者に知られたとしても、クレジットカード番号Ｃｎまでが知られてしまう危険性はない。
【００５２】
ここに示す実施形態では、更に、各クレジットカードα，βについての決済回数αｉ，βｉをＩＣカード１３０内に格納するようにしている。決済回数αｉ，βｉは、それぞれ各クレジットカードα，βを用いた本発明による決済処理が、これまでに何回行われたかを示す数字であり、準備手続の段階では、これら決済回数αｉ，βｉは初期値０に設定される。以後、本発明による決済処理が行われるたびに、各決済回数αｉ，βｉはそれぞれ１だけ増加してゆくことになる。
【００５３】
このような準備手続によりＩＣカード１３０内に格納されることになった情報は、承認業者へ送信される。すなわち、ＩＣカード１３０内の情報は、リーダライタ装置１２０、パソコン１１０、インターネット４００を介して、承認業者用情報処理装置３００へと送られ、承認業者側にも知らされることになる（「ＰＩＮ」については、承認業者側に知らせる必要はない）。この送信処理は、十分なセキュリティが確保できるＳＳＬなどのプロトコルで行われる。承認業者側では、こうして送信されてきた情報に基づいて、対応関係情報３０を作成する。もっとも、承認業者側には、個々のユーザＵｎについての氏名Ｎｎ，クレジットカード番号Ｃｎ，有効期限Ｄｎ，住所，電話番号などの情報が既にデータベースとして用意されているので、実際には、このデータベースに代用コードＳＵＢｎを付加する処理を行うだけですむ。
【００５４】
以上の各作業により、準備手続は完了である。なお、上述した準備手続の例では、ＩＣカード１３０の内部において代用コードＳＵＢｎを発生させ、これを承認業者用情報処理装置３００側へ送信するという手順を採っているが、逆に、承認業者用情報処理装置３００側で代用コードＳＵＢｎを発生させ、これをＩＣカード１３０側へ送信するという手順を採ることもできるし、ＩＣカード１３０および承認業者用情報処理装置３００のそれぞれが独立して代用コードＳＵＢｎを発生させる処理を行うという手順を採ることもできる（同一のクレジットカード番号Ｃｎに対して、同一のハッシュ関数を適用すれば、同一の代用コードＳＵＢｎが生成される）。要するに、上記準備手続により、各クレジットカードについての代用コードＳＵＢｎと、共通データとして用いられる情報（この例では、後述するように、代用コードＳＵＢｎ自身と、決済回数ｉ，「ＤＡＴＥ」，「ＭＡＧ」の各データ）とが、ＩＣカード１３０と承認業者用情報処理装置３００との双方に格納された状態になれば、どのような手順で準備手続を行ってもかまわない。
【００５５】
このような準備手続が完了すれば、このＩＣカード１３０自身を、クレジットカードα，βの代用カードとして利用することができるようになる。別言すれば、このＩＣカード１３０は、クレジットカードα，βのいわゆる「子カード」として機能することになる。図３には、２枚のクレジットカードα，βの情報をＩＣカード１３０内に入力した例が示されているが、もちろん、３枚以上のクレジットカードについての情報をＩＣカード１３０内に入力することも可能であり、ユーザＵｎは、このＩＣカード１３０を、多数のクレジットカードの「子カード」として利用することが可能になる。しかも、このＩＣカード１３０は、本質的には、各クレジットカードと同等のカード（同一のクレジットアカウントについてのカード）であるので、ＩＣカード１３０を発行するために、新たに各クレジットカード会社の審査を受ける必要はない。クレジットカード会社によっては、いわゆる「家族カード」と称するユーザの家族名義の「子カード」を発行するサービスを提供していることがあるが、通常、このような「家族カード」の発行を受けるためには、その旨の申請書をクレジットカード会社に提出し、一応の審査を受ける必要がある。本発明によって発行されるＩＣカード１３０は、このような「家族カード」とは全く性質の異なるカードであり、本質的に元のクレジットカードと同一のアカウントを利用したカードということになるので、発行に際してクレジットカード会社による新たな審査は必要なく、繁雑な事務処理を経ることなしに円滑な発行が可能である。
【００５６】
続いて、このＩＣカード１３０を用いた決済処理の手順を説明する。上述したように、ＩＣカード１３０は、必ずしも本発明に利用する専用のカードにする必要はなく、他の種々の用途に共用することが可能である。ユーザＵｎは、このＩＣカード１３０を、本発明に係る決済処理に利用する場合に、リーダライタ装置１２０に装着すればよい。ユーザＵｎが、パソコン１１０を用いて加盟店の仮想ショッピングモールのＷｅｂページにアクセスし、クレジットカードによる決済を行う場合は、次のような作業を行えばよい。まず、ＩＣカード１３０をリーダライタ装置１２０に装着し、パソコン１１０を用いて「ＰＩＮ」データを入力する。ＩＣカード１３０の内部で「ＰＩＮ」データの照合が完了すると、次に、どのクレジットカードを用いて決済を行うかを選択する入力を行う。たとえば、ユーザＵｎがクレジットカードαによって決済する旨の選択入力を行うと、ユーザＵｎの氏名Ｎｎと、クレジットカードαについての代用コードαＳＵＢｎと、当該決済（第αｉ回目の決済）について生成された決済識別コードαＩＤ（ｎ，αｉ）とが、インターネット４００を介して加盟店用情報処理装置２００へと送信されることになる（実際には、この他、ユーザＵｎの住所や、購入した商品や数量を示す情報なども送信されることになる）。このような処理は、ＩＣカード１３０内のプログラム「ＰＲＧ」と、加盟店用情報処理装置２００のＷｅｂサーバ内のプログラムの連繋動作によって行われる。
【００５７】
既に§２で述べたように、加盟店用情報処理装置２００は、ユーザＵｎ側から送信されてきた情報のうちの氏名Ｎｎ，代用コードαＳＵＢｎ，決済識別コードαＩＤ（ｎ，αｉ）と、決済金額および加盟店自身を特定する識別コードを承認業者用情報処理装置３００へ送信して決済要求を出す。承認業者用情報処理装置３００は、代用コードαＳＵＢｎに対応するクレジットカード番号αＣｎを参照し、この決済要求がユーザＵｎについてのものであることを特定する。そして、承認業者用情報処理装置３００内で発生させた決済識別コードαＩＤ（ｎ，αｉ）と、加盟店用情報処理装置２００側から送信された決済識別コードαＩＤ（ｎ，αｉ）とが一致することを確認した上で、加盟店用情報処理装置２００に対して当該決済を承認する旨の回答を行う。
【００５８】
一般に、ＣＰＵ内蔵型のＩＣカードでは、内部メモリに格納された情報に対して十分なセキュリティが確保されており、図３に示すＩＣカード１３０内の各情報が、不正な手段で外部に読み出される可能性はないと考えてよい。したがって、万一、ユーザＵｎがこのＩＣカード１３０を紛失したとしても、内部に格納された種々の情報が流出するおそれはない。本発明の決済処理に必要な種々の情報を、パソコン１１０側ではなく、ＩＣカード１３０側に格納しているのは、ＩＣカードがこのような高度なセキュリティを備えているからである。しかも、ここに示す実施形態では、決済識別コードＩＤ（ｎ，ｉ）を発生する処理も、ＩＣカード１３０の内部で行うようにしているため、パソコン１１０内には、決済識別コードＩＤ（ｎ，ｉ）を発生するための処理履歴が一切残らない。このように、決済識別コードＩＤ（ｎ，ｉ）を発生するために必要な共通データＣＯＭｎおよび秘密アルゴリズムＡＲＧを、すべてＩＣカード１３０内に格納しておくようにし、決済識別コードＩＤ（ｎ，ｉ）を、ＩＣカード１３０の内部で発生させることは、高度のセキュリティを確保する上で極めて有効である。
【００５９】
続いて、共通データＣＯＭｎの具体的な例についての説明を、図４のブロック図を参照して行う。§２で述べたように、本発明における共通データＣＯＭｎの役割は、秘密アルゴリズムＡＲＧを用いて決済識別コードＩＤ（ｎ，ｉ）を発生させる際に元となる「タネ」としての役割であり、ＩＣカード１３０と承認業者用情報処理装置３００との双方に共通して格納され、各ユーザＵｎごとにそれぞれ異なるようなデータであれば、どのようなデータを用いてもかまわない。ただ、この共通データが第三者に類推されるようなデータであると、セキュリティの面から好ましくないので、できるだけ複雑なデータを共通データとして定めておくのが好ましい。また、本発明の基本原理上、各決済処理ごとに異なる決済識別コードＩＤ（ｎ，ｉ）が生成される必要があり、そのためには、元になる共通データ自体が、各決済処理ごとに変化するような性質のデータであることが好ましい。
【００６０】
そこで、本実施形態では、図４の下欄に示すような共通データを定義している。すなわち、クレジットカードαを用いた決済用の共通データαＣＯＭｎとしては、代用コードαＳＵＢｎ，マジックコードＭＡＧ，日付／時刻ＤＡＴＥ，決済回数αｉの４つのデータの組み合わせからなるデータ（たとえば、４つのデータを構成する文字列をそのまま結合することにより得られるデータ）を用いており、同様に、クレジットカードβを用いた決済用の共通データβＣＯＭｎとしては、代用コードβＳＵＢｎ，マジックコードＭＡＧ，日付／時刻ＤＡＴＥ，決済回数βｉの４つのデータの組み合わせからなるデータを用いている。
【００６１】
共通データＣＯＭｎの一部として、代用コードＳＵＢｎを用いるのは、個々のユーザごとに、それぞれ異なる共通データを定義できるようにするためである。代用コードＳＵＢｎは、クレジットカード番号Ｃｎのハッシュ値として与えられるコードであり、基本的には、個々のユーザごと（実際には、個々のクレジットカードごと）に異なるコードになる。そこで、この代用コードＳＵＢｎを共通データＣＯＭｎの一部として用いれば、ユーザごとにそれぞれ異なる共通データＣＯＭｎを定義することが可能になる。
【００６２】
一方、マジックコードＭＡＧは、時期（年、月、日、週、時刻など）に応じて内容が変化する特有のコード（たとえば、任意の文字列）である。たとえば、１月は「松」、２月は「梅」、３月は「桜」、…というように、１２か月分のマジックコードＭＡＧを任意の文字列として定めておき、１月中に行われた決済には「松」なるマジックコードを採用し、２月中に行われた決済には「梅」なるマジックコードを採用する、というような運用を行えば、セキュリティをより向上させることができる。もちろん、月曜日、火曜日、水曜日、…というように曜日ごとに異なるマジックコードを設定することもできるし、偶数日と奇数日とで異なるマジックコードを設定するようなこともできる。このように、時期に応じて内容が変化するコードを共通データＣＯＭｎの一部に含ませておくことは、第三者による共通データの類推を困難にする上で極めて有効である。
【００６３】
日付／時刻ＤＡＴＥは、既に述べたとおり、決済時点の日付および時刻を示すデータである。たとえば、２０００年７月１５日午後３：００というようなデータが共通データＣＯＭｎの一部に組み込まれることになる。共通データＣＯＭｎの一部にこのようなデータを組み込む第１の理由は、上述したマジックコードＭＡＧと同様に、第三者による共通データの類推を困難にさせるためであり、第２の理由は、各決済処理ごとに異なる共通データを生成するためである。たとえば、第ｉ回目の決済が２０００年７月１５日午後３：００に行われ、第（ｉ＋１）回目の決済が同日の午後５：００に行われたとすれば、第ｉ回目の決済に用いられる共通データと第（ｉ＋１）回目の決済に用いられる共通データとは、それぞれ一部分が異なることになり、発生される決済識別コードＩＤ（ｎ，ｉ）とＩＤ（ｎ，ｉ＋１）も異なることになる。本発明を実施する上では、秘密アルゴリズムＡＲＧは、決済が行われるたびに毎回異なる決済識別コードが発生されるようなアルゴリズムにしておく必要があるが、このように、「決済が行われるたびに毎回異なるようなデータが含まれた共通データを用いる」というアルゴリズムを採用すれば、アルゴリズムの骨格自体を変更せずに、決済が行われるたびに毎回異なる決済識別コードを発生させることが可能になる。
【００６４】
もちろん、日付／時刻ＤＡＴＥは、必ずしも決済日時を示すコードにする必要はなく、たとえば、２０００年７月１５日というように決済日のみを含むコードにすることもできるし、午後３：００というように決済時のみを含むコードにすることもできる。また、２０００年７月１５日午後３時１３分２４．２秒のように、正確な秒までも含むコードにすることも可能であるが、あまり精度の高い時刻コードを用いると、ＩＣカード１３０内で決済識別コードを生成した時刻と、承認業者用情報処理装置３００内で決済識別コードを生成した時刻とが不一致となり、両者の決済識別コードが一致しなくなるおそれがあるので、ＩＣカード１３０側のクロックと承認業者用情報処理装置３００側のクロックとの誤差や、インターネット４００を介しての伝送遅延時間などを考慮して、両者で同一の時刻コードが用いられる範囲内の精度に抑える必要がある。
【００６５】
本実施形態では、更に、決済回数ｉ（αｉまたはβｉ）を共通データの一部として組み込むようにしている。その理由は、もちろん、各決済処理ごとに異なる共通データを生成するためである。上述したように、日付／時刻ＤＡＴＥなるコードを共通データの一部に組み込むことにより、原理的には、決済が行われるたびに毎回異なる決済識別コードを発生させることが可能である。しかしながら、上述した時刻精度の問題があるため、日付／時刻ＤＡＴＥなるコードについては、精度をあまり高めることはできない。したがって、日付／時刻ＤＡＴＥなるコードのみに依存して、毎回異なる決済識別コードを発生させるよりは、更に、決済回数を共通データの一部に組み込んだ方が好ましい。たとえば、日付／時刻ＤＡＴＥなるコードを分単位の精度で設定したとすると、１分以上の時間間隔をおいて２つの決済処理が行われた場合には、これらの決済処理ではそれぞれ異なる日付／時刻ＤＡＴＥが利用されることになるが、万一、１分以内に２つの決済処理が行われると、両決済処理で同一の日付／時刻ＤＡＴＥが利用されることになる。このような弊害を避けるためには、決済回数ｉを共通データの一部に組み込むようにするのが好ましい。この決済回数αｉ，βｉは、決済処理が行われるごとに逐次更新されることになる。
【００６６】
結局、図４に示す実施形態の場合、クレジットカードαを用いた第ｉ回目の決済には、代用コードαＳＵＢｎ，マジックコードＭＡＧ，日付／時刻ＤＡＴＥ，決済回数αｉなる４種類のデータの組み合わせからなる共通データαＣＯＭｎに対して、所定の秘密アルゴリズムＡＲＧが適用され、第ｉ回目の決済についての決済識別コードαＩＤ（ｎ，αｉ）が生成されることになる。同様に、クレジットカードβを用いた第ｉ回目の決済には、代用コードβＳＵＢｎ，マジックコードＭＡＧ，日付／時刻ＤＡＴＥ，決済回数βｉなる４種類のデータの組み合わせからなる共通データβＣＯＭｎに対して、所定の秘密アルゴリズムＡＲＧが適用され、第ｉ回目の決済についての決済識別コードβＩＤ（ｎ，αｉ）が生成されることになる。
【００６７】
図５は、図４に示すＩＣカード１３０内に格納されている情報に対応して、承認業者用情報処理装置３００内に格納されている情報の一例を示す図である。ここで、「ＰＲＧ」は、承認業者用情報処理装置３００に決済要求に対する承認処理を行わせるためのプログラムであり、「ＡＲＧ」は、ＩＣカード１３０内に格納されているのと同一の秘密アルゴリズムであり、「ＤＡＴＥ」は、現在の日付／時刻を示すコード（承認業者用情報処理装置３００の内蔵クロックに基づいて生成される）であり、マジックコードＭＡＧは、ＩＣカード１３０内に格納されているのと同一のマジックコードである。また、クレジットカードαあるいはβに関するデータとして、複数のユーザＵ１，Ｕ２，…，Ｕｎ，…に関するデータがそれぞれ格納されている。ここで、たとえば、クレジットカードαに関する第ｎ番目のユーザＵｎのデータとしては、図示のとおり、氏名αＮｎ，クレジットカード番号αＣｎ，有効期限αＤｎ，利用限度額αＬＬｎ，代用コードαＳＵＢｎ，決済回数αｉ，その他、ユーザＵｎの住所や電話番号、決済金額データなどが格納されることになる。
【００６８】
承認業者用情報処理装置３００側で決済識別コードＩＤ（ｎ，ｉ）を発生させる処理も、上述したＩＣカード１３０側での処理と全く同様である。すなわち、クレジットカードαを用いた第ｉ回目の決済には、代用コードαＳＵＢｎ，マジックコードＭＡＧ，日付／時刻ＤＡＴＥ，決済回数αｉなる４種類のデータの組み合わせからなる共通データαＣＯＭｎ（承認業者用情報処理装置３００内のデータベースに格納されているデータ）に対して、所定の秘密アルゴリズムＡＲＧが適用され、第ｉ回目の決済についての決済識別コードαＩＤ（ｎ，ｉ）が生成されることになる。決済要求に対する承認は、図４に示すプロセスでＩＣカード１３０内で生成された決済識別コードαＩＤ（ｎ，αｉ）と、図５に示すプロセスで承認業者用情報処理装置３００内で生成された決済識別コードαＩＤ（ｎ，αｉ）との一致を条件として行われることになる。もちろん、決済処理が完了した後は、承認業者用情報処理装置３００側でも決済回数αｉあるいはβｉの更新が行われる。
【００６９】
§４．いくつかの変形例
最後に、本発明に係るクレジットカードを用いた決済処理方法の変形例をいくつか述べておく、
【００７０】
(1) 前述した実施形態では、準備手続の段階で、共通データＣＯＭｎおよび秘密アルゴリズムＡＲＧをＩＣカード１３０内にロードし、以後、このロードした共通データＣＯＭｎおよび秘密アルゴリズムＡＲＧを使用し続けることになるが、セキュリティを向上させる上では、ＩＣカード１３０内にロードした共通データＣＯＭｎおよび秘密アルゴリズムＡＲＧの内容を所定の期間ごとに変更する処理を行うのが好ましい。具体的には、準備手続と同様に、ユーザ用情報処理装置１００と承認業者用情報処理装置３００とをインターネット４００を介して接続し、新たな共通データＣＯＭｎおよび秘密アルゴリズムＡＲＧへの変更処理が双方同時に行われるようにすればよい。
【００７１】
(2) 図４に示すＩＣカード１３０内には、各クレジットカードα，βの利用限度額αＬｎ，βＬｎが設定されている。一方、図５に示す承認業者用情報処理装置３００内にも、各クレジットカードの各ユーザごとに、クレジットカードの利用限度額（たとえば、クレジットカードαの第ｎ番目のユーザＵｎについては、利用限度額αＬＬｎ）が設定されている。ここで、承認業者用情報処理装置３００側に設定されている利用限度額αＬＬｎは、クレジットカード会社が設定した本来の利用限度額であり、ユーザＵｎは、１か月間に、この利用限度額αＬＬｎを越える決済を行うことはできない（そのような決済要求は否認されることになる）。これに対して、ＩＣカード１３０側に設定されている利用限度額αＬｎ（あるいはβＬｎ）は、準備手続の段階でユーザＵｎ自身が任意に設定できる限度額である。一般的には、αＬｎ＝αＬＬｎというように、クレジットカード会社が設定した利用限度額と同じ額を、ＩＣカード１３０内の利用限度額として設定すればよいが、敢えて、αＬｎ＜αＬＬｎのような設定を行い、無駄遣いを抑えるための自主管理の目的設定に用いることもできる。
利用限度額αＬｎの設定を行った場合、クレジットカードαを用いてこの利用限度額αＬｎを越えるような決済が行われる場合には、その旨の警告が提示されるようにしておく。たとえば、ＩＣカード１３０内に、今月の決済金額の累積値を記録しておくようにし、新たに決済しようとしている金額と、この累積値との合計が、利用限度額αＬｎを越えるような場合には、ＩＣカード１３０内のプログラム「ＰＲＧ」の機能によって、パソコン１１０の画面上に何らかの警告表示を行うようにしておけばよい。αＬｎ＜αＬＬｎなる設定が行われていた場合には、この警告表示を無視して決済を断行することができるようにしておいてもよいし、警告表示が出されたら当該決済は拒絶されるようにしておいてもよい。
【００７２】
(3) 前述の実施形態では、代用コードＳＵＢｎは唯一無二のユニークなコードであるものとしたが、本発明を実施する上では、必ずしも代用コードＳＵＢｎを唯一無二のコードにする必要はない。実用上は、代用コードＳＵＢｎとともにユーザの氏名Ｎｎが承認業者用情報処理装置３００側に送信されるので、仮に代用コードＳＵＢｎがユニークなものではなかったとしても、通常は、代用コードＳＵＢｎと氏名Ｎｎとの組合わせによって、ユーザＵｎを特定することが可能である。ただし、同姓同名のユーザも存在するので、代用コードＳＵＢｎは、できる限り他のユーザとは異なるコードを用いるのが好ましく、ユニークな代用コードＳＵＢｎを設定するのが好ましい。
【００７３】
(4) 前述の実施形態では、インターネット上の仮想ショッピングモールでの買い物の決済を、インターネット上で行う例について述べたが、本発明に係る決済方法は、必ずしもインターネット決済に限定されるものではない。たとえば、ユーザが実際の店舗に買い物や食事に行って代金を決済する場合、クレジットカードαやβを用いる代わりに、ＩＣカード１３０を用いて決済することも可能である。この場合、当該店舗に設置されたリーダライタ装置１２０にＩＣカード１３０を装着して決済を行えばよい。ＩＣカード１３０は、１枚で複数枚のクレジットカードとして機能することができ、かつ、クレジットカード以外の種々の機能を有しているので、多数のクレジットカードを所持する代わりに、このＩＣカード１３０を１枚だけ所持していれば、すべてのクレジットカードのアカウントを用いた決済が可能になる。このような利用形態では、ＩＣカード１３０を装着したシステムがユーザ用情報処理装置１００として機能することになる。ユーザ用情報処理装置１００は必ずしもユーザの自宅に設置されている必要はなく、上述の利用形態の場合は、店舗に設置されたパソコン１１０およびリーダライタ装置１２０が、ユーザ用情報処理装置１００としての機能を果たしていることになる。
【００７４】
(5) 本発明に係るユーザ用情報処理装置１００は、上述のように、ＩＣカード１３０のような携帯型情報処理装置を利用して実現することができる。ＩＣカードの場合、現在のところ、単独ではインタネットへの接続環境やデータ入力機能が備わっていないため、インターネット上の仮想ショッピングモールにおける決済を行う場合には、上述の実施形態のように、パソコン１１０およびリーダライタ装置１２０と組み合わせた形でユーザ用情報処理装置１００を構成する必要があるが、携帯電話や携帯型情報端末装置など、単独でインターネットに接続する環境をもった装置を利用することができれば、そのような装置を単独でユーザ用情報処理装置１００として用いることにより、インターネット上での決済が可能になる。
【００７５】
【発明の効果】
以上のとおり、本発明に係るクレジットカードを用いた決済処理方法によれば、各加盟店に対するセキュリティを十分に確保することが可能になる。特に、前述した実施形態によれば、次のような種々の効果が得られる。
(1) ＩＣカードを、クレジットカードの「子カード」として利用することになるが、ＩＣカードは十分なセキュリティ対策が施されているため、紛失や盗難という事故が発生しても、本物のクレジットカードに比べて安全性が高い。すなわち、ＩＣカードの内部に格納されたデータを不正な手段で外部に読み出すことは極めて困難であり、また、ＩＣカードの表面にはクレジットカード番号は記載されないので、ＩＣカードを目視しても、クレジットカード番号を認識することはできない。このため、紛失や盗難があっても、クレジットカード番号が第三者に知られる可能性は非常に低くなる。
(2) ＩＣカード製のクレジットが普及するようになるまでには、まだ数年かかると予想されているが、本発明に係る方法では、正式なＩＣカード製クレジットカードを用いる場合に比べて、カードの配布やカード発行のための審査といった作業に手間がかかることはないため、迅速な導入が可能になる。本発明は、特に、インターネットにおいてクレジットショッピングを実施したい場合に有効である。
(3) 本発明では、１枚のＩＣカードに所有者が異なる複数枚のクレジットカードを登録することも可能である。したがって、たとえば、家族全員のクレジットカードの共通の「子カード」となるようなＩＣカードを作成することも可能になり、柔軟な運用が期待できる。
(4) 「子カード」化されたＩＣカードの中には、必要な情報を記録しておくことができるので、端末装置からキー入力すべきデータ量を低減することができる。すなわち、代用コードや決済識別コードは、プログラムに基づいて自動的に加盟店へと送られるため、個々のユーザがこれらのコードを入力する必要はない。実用上、ユーザはこれらのコードの存在すら意識する必要はない。
【図面の簡単な説明】
【図１】インターネット上の仮想ショッピングモールで買い物をする場合の従来の一般的なクレジットカードによる決済処理方法の手順を説明するブロック図である。
【図２】インターネット上の仮想ショッピングモールで買い物をする場合の本発明に係るクレジットカードによる決済処理方法の手順を説明するブロック図である。
【図３】本発明で用いるユーザ用情報処理装置１００をＩＣカード１３０を利用して構成した基本構成を示すブロック図である。
【図４】図３に示すＩＣカード１３０における決済識別コードの発生手順を示す図である。
【図５】図３に示すＩＣカード１３０に格納された情報に対応した、承認業者用情報処理装置３００内の格納情報の一例を示す図である。
【符号の説明】
１０…クレジットカード
２０…決済用情報
３０…対応関係情報
１００…ユーザ用情報処理装置
２００…加盟店用情報処理装置
３００…承認業者用情報処理装置
４００…インターネット
ＡＲＧ，ＡＲＧｎ…秘密アルゴリズム
Ｃ，Ｃｎ…クレジットカード番号
ＣＯＭｎ…第ｎ番目のユーザの共通データ
Ｄ，Ｄｎ…クレジットカードの有効期限
ＤＡＴＥ…現時点の日付／時刻コード
ｉ…決済回数
ＩＤ（ｎ，ｉ）…第ｎ番目のユーザの第ｉ回目の決済時の決済識別コード
ＭＡＧ…マジックコード
Ｎ，Ｎｎ…ユーザの氏名
ＰＩＮ…ユーザ識別コード
ＰＲＧ…プログラム
ＳＵＢｎ，αＳＵＢｎ，βＳＵＢｎ…第ｎ番目のユーザの代用コード
Ｕｎ…第ｎ番目のユーザ
α，β…クレジットカード
α○○…クレジットカードαに関する○○
β○○…クレジットカードβに関する○○
Claims (10)
- クレジットカード会社から、所定の番号が付与されたクレジットカードの発行を受けたユーザが、当該クレジットカードの加盟店に対して当該クレジットカードを用いて決済を行う際の決済処理方法であって、
個々のユーザについて準備を行う準備段階と、ユーザが特定の加盟店に対して決済を行う決済段階とを有し、
前記準備段階では、
個々のユーザが利用する個々のユーザ用情報処理装置が、当該ユーザに対して発行された特定のクレジットカードの番号の代わりに用いられるコードであって、個々のクレジットカードごとにユニークなコードである所定の代用コードを格納し、
前記特定のクレジットカードによる決済を承認する権限をもった承認業者が管理する承認業者用情報処理装置が、個々のユーザごとのクレジットカード番号と前記代用コードとの対応関係を示す対応関係情報を格納し、
前記ユーザ用情報処理装置と前記承認業者用情報処理装置との双方が、所定の共通データを用いた演算処理により決済識別コードを発生させる所定のアルゴリズムを格納し、
前記決済段階では、
前記ユーザ用情報処理装置が、前記特定の加盟店が管理する加盟店用情報処理装置に対して、前記ユーザ用情報処理装置内に格納された代用コードと、前記ユーザ用情報処理装置によって発生された決済識別コードと、を送信し、
前記加盟店用情報処理装置が、前記ユーザ用情報処理装置から送信されてきた代用コードおよび決済識別コードを、前記承認業者用情報処理装置に送信することにより決済要求を出し、
前記決済要求を受けた承認業者用情報処理装置が、前記対応関係情報に基づき、送信されてきた代用コードに１対１に対応するクレジットカード番号を参照することによりユーザを特定し、当該ユーザについての共通データを用いた演算処理により決済識別コードを発生し、発生した決済識別コードと送信されてきた決済識別コードとが一致することを条件として、前記決済要求に対する承認を行い、
前記個々のユーザ用情報処理装置には、少なくとも、格納されている代用コードと、決済に用いるクレジットカードによる決済回数を示すコードと、を含む共通データを作成し、当該共通データを用いた演算処理により決済識別コードを発生させるアルゴリズムが格納されており、前記承認業者用情報処理装置には、前記個々のユーザ用情報処理装置に格納されているアルゴリズムとそれぞれ同じアルゴリズムが格納されており、
決済が行われる際には、前記ユーザ用情報処理装置と前記承認業者用情報処理装置との双方において、前記共通データを用いた前記同じアルゴリズムによる演算処理を行うことにより、それぞれ同一の決済識別コードが発生できるようにしたことを特徴とするクレジットカードを用いた決済処理方法。 - 請求項１に記載の決済処理方法において、
特定のクレジットカードの番号の代わりに用いられる代用コードを、当該特定のクレジットカードの番号を利用して発生させるようにしたことを特徴とするクレジットカードを用いた決済処理方法。 - 請求項１または２に記載の決済処理方法において、
ユーザ用情報処理装置と承認業者用情報処理装置との双方で作成される共通データとして、時期に応じて内容が変化するマジックコードを含むデータを用いることを特徴とするクレジットカードを用いた決済処理方法。 - 請求項１または２に記載の決済処理方法において、
ユーザ用情報処理装置と承認業者用情報処理装置との双方で作成される共通データとして、決済日、決済時、もしくは決済日時を示すコードを含むデータを用いることを特徴とするクレジットカードを用いた決済処理方法。 - 請求項１〜４のいずれかに記載の決済処理方法において、
ユーザ用情報処理装置と承認業者用情報処理装置とをネットワークを介して接続し、所定の期間ごとに、共通データ作成用もしくは決済識別コード発生用のアルゴリズムの内容を変更する処理を行うことを特徴とするクレジットカードを用いた決済処理方法。 - 請求項１〜５のいずれかに記載の決済処理方法において、
ユーザ用情報処理装置内に、クレジットカードの利用限度額を示す情報を格納できるようにし、この利用限度額を越える決済が行われる場合には、その旨の警告が提示されるようにしたことを特徴とするクレジットカードを用いた決済処理方法。 - 請求項１〜６のいずれかに記載の決済処理方法において、
特定のユーザが複数のクレジットカード会社からそれぞれクレジットカードの発行を受けているときに、各クレジットカードごとにそれぞれ別個の代用コードを作成してユーザ用情報処理装置に格納し、承認業者用情報処理装置には、各代用コードと各クレジットカード番号との対応関係を示す対応関係情報を格納し、複数のクレジットカードの中からユーザが選択した特定のクレジットカードについての決済処理を行うことができるようにしたことを特徴とするクレジットカードを用いた決済処理方法。 - 請求項１〜７のいずれかに記載の決済処理方法において、
ユーザ用情報処理装置、加盟店用情報処理装置、承認業者用情報処理装置を、それぞれネットワークを介して接続し、加盟店のＷｅｂページ上に開かれた仮想ショッピングモールでユーザが買い物をした際に、前記ネットワークを介して代用コードおよび決済識別コードを送信することにより決済が行われるようにしたことを特徴とするクレジットカードを用いた決済処理方法。 - 請求項１〜８のいずれかに記載の決済処理方法において、
ユーザ用情報処理装置を、ＩＣカードと、このＩＣカードに対する情報伝送を行うリーダライタ装置と、このリーダライタ装置を介してＩＣカードへのアクセスを行うコンピュータと、によって構成し、少なくとも決済処理を行う際に、前記ＩＣカードを前記リーダライタ装置に装着し、前記コンピュータによってアクセスを行うことにより、ユーザ用情報処理装置としての機能を実現させるようにしたことを特徴とするクレジットカードを用いた決済処理方法。 - 請求項９に記載の決済処理方法において、
少なくとも、共通データおよび秘密アルゴリズムをＩＣカード内のメモリに格納し、決済識別コードの発生処理を、ＩＣカード内において実行することを特徴とするクレジットカードを用いた決済処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000240878A JP4942240B2 (ja) | 2000-08-09 | 2000-08-09 | クレジットカードを用いた決済処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000240878A JP4942240B2 (ja) | 2000-08-09 | 2000-08-09 | クレジットカードを用いた決済処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002056332A JP2002056332A (ja) | 2002-02-20 |
| JP4942240B2 true JP4942240B2 (ja) | 2012-05-30 |
Family
ID=18732163
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000240878A Expired - Fee Related JP4942240B2 (ja) | 2000-08-09 | 2000-08-09 | クレジットカードを用いた決済処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4942240B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002312707A (ja) * | 2001-04-13 | 2002-10-25 | Dainippon Printing Co Ltd | クレジットカードを用いた決済処理方法 |
| JP4563780B2 (ja) * | 2004-11-16 | 2010-10-13 | 株式会社三共 | 特定取引用システムおよびアプリケーションプログラム |
| US20070206743A1 (en) * | 2006-02-23 | 2007-09-06 | Industrial Technology Research Institute | System and method for facilitating transaction over a communication network |
| JP2007293497A (ja) * | 2006-04-24 | 2007-11-08 | National Institute Of Advanced Industrial & Technology | カード認証システム及びカード認証方法 |
| KR101553975B1 (ko) * | 2011-04-26 | 2015-09-18 | 허용회 | 해시를 이용한 거래 방법 및 시스템 |
| CN105825371A (zh) * | 2015-01-07 | 2016-08-03 | 阿里巴巴集团控股有限公司 | 业务处理方法和装置 |
| JP6652379B2 (ja) * | 2015-12-17 | 2020-02-19 | 株式会社Ｎｔｔドコモ | 決済システム |
| JP7060687B2 (ja) | 2018-05-30 | 2022-04-26 | 株式会社日立ハイテク | ウエハ検査装置およびウエハ検査方法 |
| KR102005549B1 (ko) * | 2018-08-09 | 2019-07-30 | 주식회사 센스톤 | 가상코드 기반의 금융거래제공시스템, 가상코드생성장치, 가상코드검증장치, 가상코드 기반의 금융거래제공방법 및 가상코드 기반의 금융거래제공프로그램 |
| 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 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA1301334C (en) * | 1988-02-08 | 1992-05-19 | Pitney Bowes Inc. | Postal charge accounting system |
| JPH06282556A (ja) * | 1993-03-30 | 1994-10-07 | Hisashi Iwata | ワンタイム・クレジットカード決済システム |
| JPH08286904A (ja) * | 1995-02-14 | 1996-11-01 | Fujitsu Ltd | ソフトウエア暗号化・復号化方法、ソフトウエア暗号化システムおよびソフトウエア復号化システム |
| JPH1115873A (ja) * | 1997-06-20 | 1999-01-22 | Hitachi Ltd | 資金管理と連動した電子商取引システム |
| JPH11203248A (ja) * | 1998-01-16 | 1999-07-30 | Nissin Electric Co Ltd | 認証装置、および、そのプログラムを記録した記録媒体 |
| JPH11272762A (ja) * | 1998-03-19 | 1999-10-08 | Hitachi Ltd | オフラインデータの課金制御方法および装置 |
| JP2000020541A (ja) * | 1998-07-03 | 2000-01-21 | Nec Corp | 問題解決支援システム |
| JP2000113085A (ja) * | 1998-10-08 | 2000-04-21 | Sony Corp | 電子現金システム |
-
2000
- 2000-08-09 JP JP2000240878A patent/JP4942240B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002056332A (ja) | 2002-02-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6938019B1 (en) | Method and apparatus for making secure electronic payments | |
| AU2001257280B2 (en) | Online payer authentication service | |
| US20070179866A1 (en) | Method for anonymous purchase of goods via an ecommerce website | |
| US20080243702A1 (en) | Tokens Usable in Value-Based Transactions | |
| US20030018587A1 (en) | Checkout system for on-line, card present equivalent interchanges | |
| KR20190028517A (ko) | 트랜잭션 장치에 의한 디지털 자산 분산 | |
| US20080230599A1 (en) | System and method for processing transactions | |
| AU2001257280A1 (en) | Online payer authentication service | |
| JP2005505824A (ja) | 集積回路カードデータ記録装置のためのシステム並び方法、及びメモリ装置 | |
| EP1277180A2 (en) | Online payer authentication service | |
| JP2003108777A (ja) | 決済情報通知方法および装置並びに決済情報管理装置およびプログラム | |
| US20040153410A1 (en) | Anonymous payment system and method | |
| JP2008305392A (ja) | カード決済サービスの提供方法、カード決済サービスの提供システム、及びコンピュータシステムにカード決済サービスの提供処理を実行させるためのコンピュータプログラム | |
| JP2001306827A (ja) | サービス提供装置及び記録媒体 | |
| JP4942240B2 (ja) | クレジットカードを用いた決済処理方法 | |
| JP2002109237A (ja) | カード取引用ｉｃカード | |
| JP2004126898A (ja) | 認証および決済システム | |
| JP2002083237A (ja) | プリペイドシステムによる電子商取引の決済管理方法 | |
| JP2005512225A (ja) | 埋込コンテンツの自動化された権利管理及び支払いシステム | |
| CN1327361C (zh) | 电子商务系统 | |
| JP4942245B2 (ja) | クレジットカードを用いた決済処理方法 | |
| JP2001243503A (ja) | キャッシュレスカード決済対応オンライン発券システム | |
| CN100595785C (zh) | 用于小额支付的动态密码运用方法 | |
| BG63233B1 (bg) | Чип-карта и метод за използване на чип-картата | |
| JP2002312707A (ja) | クレジットカードを用いた決済処理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070608 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20091218 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100112 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100312 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20100525 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20101008 |
|
| 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 |