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

Abstract

(57)【要約】 【課題】 加盟店におけるクレジットカード番号の不正
利用を阻止する。 【解決手段】 ユーザＵｎが加盟店Ｓｍの仮想モールで
買い物をする場合、装置２００においてセッションごと
にユニークなコードＳＥＳ（ｍ，ｉ）を発生させて、装
置１００へ送信する。装置１００では、クレジットカー
ド番号ＣｎとコードＳＥＳ（ｍ，ｉ）とにＨＡＳＨ関数
を作用させ、決済識別コードＩＤ（ｍ，ｉ）を発生さ
せ、氏名Ｎｎとともに装置２００へ送信する。装置２０
０は、Ｎｎ，ＩＤ（ｍ，ｉ），ＳＥＳ（ｍ，ｉ）に決済
金額Ｐ（ｍ，ｉ）を付加し、装置３００に対して決済要
求を出す。装置３００では、氏名Ｎｎと同姓同名の会員
の各クレジットカード番号とＳＥＳ（ｍ，ｉ）とにＨＡ
ＳＨ関数を作用させ、送信されてきたＩＤ（ｍ，ｉ）と
同一のコードが得られるユーザを特定し、当該ユーザに
対する決済として承認を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クレジットカード
を用いた決済処理方法に関し、特に、インターネット上
の仮想ショッピングモールでの買い物の決済を行うのに
適したクレジットカードを用いた決済処理方法に関す
る。

【０００２】

【従来の技術】近年のクレジットカードの普及はめざま
しく、最近では、１人のユーザが複数のクレジットカー
ドを所持することも一般化しつつある。クレジットカー
ドを利用すれば、現金を取り扱う必要がないため、ユー
ザと加盟店との双方に大きなメリットが得られ、クレジ
ットカードの利用は、今後も益々普及してゆくものと予
想される。クレジットカードを用いた決済処理は、古く
は加盟店でクレジット決済用の伝票を作成し、この伝票
をクレジットカード会社へ送る方法が採られていたが、
最近は、各加盟店に設置された端末装置とクレジットカ
ード会社の管理するホストコンピュータとをオンライン
接続し、オンラインで情報のやりとりを行う方法が主流
となってきている。

【０００３】ここ数年来のインターネットの爆発的な普
及により、インターネット上の仮想ショッピングモール
での買い物の決済にも、クレジットカードを用いるのが
一般的になってきている。この場合、ユーザはパソコン
や携帯型端末装置から個々の加盟店の仮想ショッピング
モールのＷｅｂページにアクセスし、Ｗｅｂブラウザの
画面上で所望の商品を選択した上で、当該商品の代金を
クレジットカードで決済することになる。クレジットカ
ードによる決済を行う際には、ユーザの氏名、クレジッ
トカード番号、有効期限といった情報を加盟店側に伝え
る必要があるので、通常は、Ｗｅｂブラウザの画面上で
これらの各情報を入力し、インターネットを介して、加
盟店のＷｅｂページを運営しているサイトのサーバ装置
に送信する処理が行われる。加盟店は、ユーザから送信
されてきたこれらの情報に、決済対象となる金額の情報
を加えて、クレジットカード会社側のホストコンピュー
タに決済要求を出すことになる。クレジットカード会社
側では、加盟店からの決済要求を受けたら、加盟店側か
ら送信されてきたユーザの氏名、クレジットカード番
号、有効期限を、ホストコンピュータ内の登録データと
照合し、問題がなければ決済要求を承認する。

【０００４】このように、クレジットカード会社では、
基本的には、ユーザの氏名、クレジットカード番号、有
効期限を照合して決済を行うので、これらの情報が犯罪
者に盗まれると、悪用されるおそれがある。特に、イン
ターネットの黎明期においては、ユーザがＷｅｂブラウ
ザから送信したこれらの情報が、途中で不正に盗まれる
事件が多発し、大きな社会問題となっていた。このよう
な問題に対処するため、インターネット経由の情報送信
のセキュリティを高める技術が開発されてきている。た
とえば、現在では、ＳＳＬ（Secure Sockets Layer）と
呼ばれるＴＣＰ／ＩＰ通信のセキュリティを確保するた
めのプロトコルが一般的に利用されており、このプロト
コルにより送信した情報に対しては、実用上、十分なセ
キュリティを確保することが可能である。

【０００５】

【発明が解決しようとする課題】このように、クレジッ
トカードのユーザ氏名、番号、有効期限といった情報
は、犯罪者の手に渡ると悪用されるおそれがある重要な
情報であり、取り扱いには十分に注意する必要がある。
もっとも、インターネット上の仮想ショッピングモール
での買い物の決済を、クレジットカードを用いて行う場
合でも、上述のＳＳＬなどの技術を利用してこれらの情
報を送信すれば、一応、送信経路上で情報が盗まれるよ
うな被害は未然に防ぐことができる。しかしながら、こ
れまでのクレジットカードに対するセキュリティ対策
は、加盟店自身が不正な行為をすることはない、という
ことを大前提としたものであり、加盟店自身が不正行為
を働いた場合には、全く機能しないという問題を含んで
いる。そもそも加盟店は、クレジットカード会社による
厳密な審査により、十分に信頼がおける企業であるとの
判断がなされた店であり、これまでは加盟店自身が不正
行為をなすという事態は全く想定されていない。しか
し、インターネット上のビジネスなどが普及すればする
ほど、クレジットカードの加盟店も多種多様となり、加
盟店自身による不正行為、あるいはその従業者による不
正行為が行われる可能性も高まってきている。加盟店の
もとには、多数のユーザに関する氏名、クレジットカー
ド番号、有効期限といった情報が集まるので、万一、こ
れらの情報を不正に取得して横流しをするような従業者
がいた場合には、ＳＳＬなどの技術により通信セキュリ
ティを確保しても無力である。

【０００６】このような問題点を解決するために、公開
鍵暗号技術を利用したＳＥＴ（Secure Electronic Tran
saction ）なる決済方法が大手クレジットカード会社か
ら提案され、現在、システムの実験が行われているが、
かなり大掛かりなシステムが必要になるため、実用化に
は至っていない。

【０００７】そこで本発明は、各加盟店に対するセキュ
リティを十分に確保することが可能なクレジットカード
を用いた新規な決済処理方法を提供することを目的とす
る。

【０００８】

【課題を解決するための手段】(1) 本発明の第１の態
様は、クレジットカード会社から、所定のクレジットカ
ード番号が付与されたクレジットカードの発行を受けた
ユーザが、当該クレジットカードの加盟店に対して当該
クレジットカードを用いて決済を行う際の決済処理方法
において、ユーザが利用するユーザ用情報処理装置と、
決済相手となる加盟店が管理する加盟店用情報処理装置
と、を接続し、ユーザが加盟店に対して特定の決済事項
に関する処理を１処理手続として行う際に、加盟店用情
報処理装置において、特定の決済事項に関する１処理手
続に対応したコードであって、少なくとも同一ユーザに
関しては、各処理手続ごとに毎回異なるユニークなコー
ドになるという条件をもったセッション識別コードを発
生させ、このセッション識別コードをユーザ用情報処理
装置に送信する段階と、ユーザ用情報処理装置におい
て、送信されてきたセッション識別コードとクレジット
カード番号との少なくとも２つの情報に基づいてユーザ
側演算対象データを作成し、このユーザ側演算対象デー
タに対して、所定のアルゴリズムに基づく演算処理を行
うことにより一義的に決定される決済識別コードを発生
させ、少なくとも、この決済識別コードを加盟店用情報
処理装置に送信する段階と、クレジットカードによる決
済を承認する権限をもった承認業者が管理する承認業者
用情報処理装置と、加盟店用情報処理装置と、を接続
し、少なくとも、決済識別コードとセッション識別コー
ドと決済金額とを、加盟店用情報処理装置から承認業者
用情報処理装置へ送信することにより当該決済金額につ
いての決済要求を出す段階と、承認業者用情報処理装置
において、送信されてきたセッション識別コードと、予
め登録されている多数のユーザのうちの特定のユーザの
クレジットカード番号と、の少なくとも２つの情報に基
づいて、ユーザ側演算対象データと同一構成の承認業者
側演算対象データを作成し、この承認業者側演算対象デ
ータに対して、所定のアルゴリズムに基づく演算処理を
行うことにより、送信されてきた決済識別コードと同一
の決済識別コードが得られることを第１の条件とし、送
信されてきた決済識別コードが、当該特定のユーザに関
して過去に行われた決済処理で用いられた決済識別コー
ドとは異なることを第２の条件とし、これら２条件がと
もに満たされた場合に、当該特定のユーザに関して決済
要求に対する承認を行うようにしたものである。

【０００９】(2) 本発明の第２の態様は、上述の第１
の態様に係るクレジットカードを用いた決済処理方法に
おいて、少なくとも、同一の加盟店における加盟店用情
報処理装置で発生させるすべてのセッション識別コード
が、互いに異なるユニークなコードになる、という条件
下で、セッション識別コードを発生させるようにしたも
のである。

【００１０】(3) 本発明の第３の態様は、上述の第２
の態様に係るクレジットカードを用いた決済処理方法に
おいて、すべての加盟店における加盟店用情報処理装置
で発生させるすべてのセッション識別コードが、互いに
異なるユニークなコードになる、という条件下で、セッ
ション識別コードを発生させるようにしたものである。

【００１１】(4) 本発明の第４の態様は、上述の第１
〜第３の態様に係るクレジットカードを用いた決済処理
方法において、承認業者用情報処理装置において判定さ
れる第２の条件として、「送信されてきた決済識別コー
ドが、特定のユーザに関して過去に行われた決済処理で
用いられた決済識別コードとは異なる」という条件の代
わりに、「送信されてきたセッション識別コードを、過
去に送信されてきたセッション識別コードと比較した結
果、セッション識別コードの発生条件の範囲内でユニー
クなコードとなっている」という条件を用いるようにし
たものである。

【００１２】(5) 本発明の第５の態様は、上述の第１
〜第４の態様に係るクレジットカードを用いた決済処理
方法において、セッション識別コードを発生させる際
に、決済日、決済時、セッション番号もしくはこれらの
組合せを利用するようにしたものである。

【００１３】(6) 本発明の第６の態様は、上述の第１
〜第５の態様に係るクレジットカードを用いた決済処理
方法において、ユーザ側演算対象データおよび承認業者
側演算対象データとして、時期に応じて内容が変化する
マジックコードを含ませるようにしたものである。

【００１４】(7) 本発明の第７の態様は、上述の第１
〜第６の態様に係るクレジットカードを用いた決済処理
方法において、ユーザ側演算対象データおよび承認業者
側演算対象データとして、決済日、決済時、もしくは決
済日時を示すコードを含ませるようにしたものである。

【００１５】(8) 本発明の第８の態様は、上述の第１
〜第７の態様に係るクレジットカードを用いた決済処理
方法において、ユーザ側演算対象データおよび承認業者
側演算対象データとして、クレジットカードの有効期限
を示すコードを含ませるようにしたものである。

【００１６】(9) 本発明の第９の態様は、上述の第１
〜第８の態様に係るクレジットカードを用いた決済処理
方法において、ユーザ側演算対象データもしくは承認業
者側演算対象データに対する演算処理として、ＨＡＳＨ
関数もしくはその他の非可逆的な関数を作用させる演算
処理を用いるようにしたものである。

【００１７】(10) 本発明の第１０の態様は、上述の第
１〜第９の態様に係るクレジットカードを用いた決済処
理方法において、ユーザの氏名を、ユーザ用情報処理装
置から加盟店用情報処理装置に対して送信し、これを更
に、承認業者用情報処理装置に対して送信するように
し、承認業者用情報処理装置において、送信されてきた
氏名と同姓同名のユーザに関するクレジットカード番号
を用いた承認業者側演算対象データを作成し、この作成
した承認業者側演算対象データに対する演算処理結果に
基づいて、同姓同名のユーザの中から決済主体となるユ
ーザを特定するようにしたものである。

【００１８】(11) 本発明の第１１の態様は、上述の第
１〜第１０の態様に係るクレジットカードを用いた決済
処理方法において、ユーザが複数のクレジットカード会
社からそれぞれクレジットカードの発行を受けていると
きに、ユーザ用情報処理装置内に、個々のクレジットカ
ードについての各クレジットカード番号をそれぞれ格納
しておき、決済を行うときに、ユーザに特定のクレジッ
トカードを指定する入力を行わせ、指定されたクレジッ
トカードに対応するクレジットカード番号を用いて、ユ
ーザ側演算対象データを作成するようにしたものであ
る。

【００１９】(12) 本発明の第１２の態様は、上述の第
１〜第１１の態様に係るクレジットカードを用いた決済
処理方法において、ユーザ用情報処理装置、加盟店用情
報処理装置、承認業者用情報処理装置を、それぞれネッ
トワークを介して接続し、加盟店のＷｅｂページ上に開
かれた仮想ショッピングモールでユーザが買い物をした
際に、ネットワークを介して必要な情報伝送を行うこと
により決済が行われるようにしたものである。

【００２０】(13) 本発明の第１３の態様は、上述の第
１〜第１２の態様に係るクレジットカードを用いた決済
処理方法において、ユーザ用情報処理装置において発生
させた決済識別コードを、加盟店用情報処理装置を介し
て承認業者用情報処理装置に送信する代わりに、ユーザ
用情報処理装置から承認業者用情報処理装置に直接送信
するようにしたものである。

【００２１】(14) 本発明の第１４の態様は、上述の第
１〜第１３の態様に係るクレジットカードを用いた決済
処理方法において、ユーザ用情報処理装置を、ＩＣカー
ドと、このＩＣカードに対する情報伝送を行うリーダラ
イタ装置と、このリーダライタ装置を介してＩＣカード
へのアクセスを行うコンピュータと、によって構成し、
少なくとも決済処理を行う際に、ＩＣカードをリーダラ
イタ装置に装着し、コンピュータによってアクセスを行
うことにより、ユーザ用情報処理装置としての機能を実
現させるようにしたものである。

【００２２】(15) 本発明の第１５の態様は、上述の第
１４の態様に係るクレジットカードを用いた決済処理方
法において、少なくとも、決済識別コードを発生させる
ためのアルゴリズムをＩＣカード内のメモリに格納し、
決済識別コードの発生処理を、ＩＣカード内において実
行するようにしたものである。

【００２３】(16) 本発明の第１６の態様は、上述の第
１５の態様に係るクレジットカードを用いた決済処理方
法に利用することができるように、少なくとも、決済識
別コード発生用のアルゴリズムを格納し、内部において
決済識別コードの発生処理を行う機能をもったＩＣカー
ドを実現するようにしたものである。

【００２４】

【発明の実施の形態】以下、本発明を図示する実施形態
に基づいて説明する。

【００２５】§１．インターネット上での従来の一般的
な決済処理方法 はじめに、インターネット上の仮想ショッピングモール
で買い物をする場合の従来の一般的なクレジットカード
による決済処理方法の手順を説明する。図１は、この手
順を示すブロック図である。この例では、ユーザ用情報
処理装置１００、加盟店用情報処理装置２００、承認業
者用情報処理装置３００がインターネット４００を介し
て接続される。ユーザ用情報処理装置１００は、ユーザ
の管理下にある情報処理装置であり、一般的には、イン
ターネット４００に接続する機能を有するパソコンや携
帯型情報端末装置がユーザ用情報処理装置１００として
利用されている。加盟店用情報処理装置２００は、クレ
ジットカードの加盟店によって管理されている情報処理
装置であり、一般的には、仮想ショッピングモールのＷ
ｅｂページのサイトを提供するＷｅｂサーバ装置が加盟
店用情報処理装置２００として利用されることになる。
承認業者用情報処理装置３００は、クレジットカードに
よる決済を承認する権限をもった承認業者（クレジット
カード会社自身もしくはその委託を受けた特定の業者）
によって管理される情報処理装置であり、通常は、比較
的大規模なホストコンピュータによって構成される。

【００２６】ユーザは、クレジットカード会社からクレ
ジットカード１０の発行を受けており、このクレジット
カード１０には、ユーザの氏名Ｎ、クレジットカード番
号Ｃ、有効期限Ｄなる情報が記載されている（通常、エ
ンボス加工によって刻まれている）。もちろん、クレジ
ットカードによっては、この他にも種々の情報が記載さ
れている場合がある。一方、このクレジットカード１０
上に記載された情報は、承認業者用情報処理装置３００
内のデータベースにも登録されている。このデータベー
スには、更に、各ユーザの住所、電話番号、勤務先、過
去の決済履歴などのデータも格納されている。

【００２７】加盟店が運営する仮想ショッピングモール
を利用するには、ユーザは、ユーザ用情報処理装置１０
０のＷｅｂブラウザ機能を用いて、加盟店用情報処理装
置２００内のサイトの所定のＷｅｂページにアクセスす
ればよい。いま、ユーザが、このＷｅｂページ上で所望
の商品を購入し、クレジットカード１０を利用してその
代金を決済する場合を考えよう。この場合、ユーザは手
元にクレジットカード１０を用意し、Ｗｅｂ画面上で、
氏名Ｎ、クレジットカード番号Ｃ、有効期限Ｄなる情報
をキーボードなどを用いて入力する。入力したこれらの
情報は、インターネット４００を介して、加盟店用情報
処理装置２００へと送信される。通常、この送信処理
は、ＳＳＬなどのセキュリティが確保されたプロトコル
により行われるため、インターネット４００の伝送経路
上でこれらの情報が盗まれる可能性は非常に小さい。こ
うして、加盟店用情報処理装置２００に、ユーザが送信
したこれらの情報が到達すると、今度は、加盟店が、自
己の店名や決済金額Ｐなどの情報を付加して、これらの
情報をインターネット４００を介して（場合によって
は、別な通信線を介して）、承認業者用情報処理装置３
００へと送信して承認を求める。承認業者は、承認業者
用情報処理装置３００内のデータベースに登録されてい
る情報と、加盟店から送信されてきた情報とを照合し、
問題がなければ当該決済を承認することになる。

【００２８】結局、クレジットカード１０上の氏名Ｎ，
クレジットカード番号Ｃ，有効期限Ｄという情報は、ユ
ーザ用情報処理装置１００から加盟店用情報処理装置２
００へと送信され、更に、加盟店用情報処理装置２００
から承認業者用情報処理装置３００へと送信されること
になる。このような送信経路におけるセキュリティは、
前述したように、ＳＳＬなどの技術によって実用上十分
なレベルまで確保されている。しかしながら、このよう
なセキュリティ対策は、加盟店自身が不正な行為をする
ことはない、ということを大前提としたものである。加
盟店用情報処理装置２００内には、多数のユーザのクレ
ジットカードに関する情報が蓄積されており、万一、こ
れらの蓄積情報を不正に取得して横流しをするような従
業者が加盟店内にいた場合、クレジットカード情報に対
するセキュリティ対策は根底から覆されてしまう。本発
明は、このような問題を解決するための新たな決済処理
方法を提案するものである。

【００２９】§２．本発明に係る決済処理方法の基本概
念 続いて、図２のブロック図を参照しながら、本発明に係
るクレジットカードを用いた決済処理方法の基本概念を
説明する。この図２に示す例は、図１に示す例と同様
に、ユーザ、加盟店、承認業者の三者間での決済処理の
手順を示しているが、ここでは、多数のユーザのうちの
第ｎ番目のユーザという意味で、特定のユーザＵｎが決
済処理を行う場合の処理手順を示すことにする。図に示
す各符号のサフィックス「ｎ」は、この第ｎ番目のユー
ザについての情報であることを示すものである。また、
ここでは、多数の加盟店のうちの第ｍ番目の加盟店とい
う意味で、特定の加盟店Ｓｍに対する決済処理手順を示
すことにする。図に示す各符号のサフィックス「ｍ」
は、この第ｍ番目の加盟店についての情報であることを
示すものである。結局、以下に説明する決済処理は、ユ
ーザＵｎが加盟店Ｓｍに対して、特定の決済事項に関す
る処理を１処理手続（以下、１セッションと呼ぶ）とし
て行う場合の処理を示していることになる。なお、ここ
では、第ｍ番目の加盟店が個々のユーザとの間で行う特
定の決済事項に関する１処理手続（すなわち、セッショ
ン）に、一連のシリアル番号ｉを付して示すことにする
（以下、これをセッション番号ｉと呼ぶ）。図に示す各
符号のサフィックス「ｉ」は、第ｉ番目のセッションに
ついての情報であることを示すものである。

【００３０】図１に示す例と同様に、この図２の例で
も、ユーザ用情報処理装置１００、加盟店用情報処理装
置２００、承認業者用情報処理装置３００がインターネ
ット４００を介して接続される。やはり、ユーザ用情報
処理装置１００は、ユーザの管理下にある情報処理装置
であり、一般的には、インターネット４００に接続する
機能を有するパソコンや携帯型情報端末装置がユーザ用
情報処理装置１００として利用されることになる。た
だ、実用上は、後に§３で述べるように、ＩＣカードを
ユーザ用情報処理装置１００の一部として利用するのが
好ましい。加盟店用情報処理装置２００は、前述したよ
うに、クレジットカードの加盟店によって管理されてい
る情報処理装置であり、仮想ショッピングモールのＷｅ
ｂページのサイトを提供するＷｅｂサーバ装置によって
構成される。また、承認業者用情報処理装置３００は、
前述したように、承認業者によって管理される比較的大
規模なホストコンピュータによって構成され、各ユーザ
に関する種々の情報をデータベースとして格納する機能
を有している。

【００３１】この図２に示す決済処理方法は、あくまで
もクレジットカードを用いた決済処理方法であり、その
点では、図１に示す従来の決済処理方法と同じである。
すなわち、第ｎ番目のユーザＵｎは、クレジットカード
会社から予めクレジットカード１０の発行を受けてお
り、このクレジットカード１０には、ユーザの氏名Ｎ
ｎ、クレジットカード番号Ｃｎ、有効期限Ｄｎなる情報
が記載されている。ただし、従来の決済処理方法では、
加盟店側にこれらの各情報を知らせる必要があるが、本
発明に係る決済処理方法では、その必要がなくなる。以
下、この決済処理方法の基本概念を説明する。

【００３２】いま、第ｎ番目のユーザＵｎが、ユーザ用
情報処理装置１００のＷｅｂブラウザ機能を利用して、
第ｍ番目の加盟店Ｓｍが管理する加盟店用情報処理装置
２００内のサイトにおけるショッピングモールにアクセ
スして所望の商品を購入し、クレジットカード１０を利
用してその代金を決済する場合を考える。この場合、加
盟店用情報処理装置２００は、１セッションとして決済
処理の手続きを行うことになるが、ここでは、このセッ
ションが第ｉ番目のセッションであったとしよう。ま
ず、加盟店用情報処理装置２００は、この第ｉ番目のセ
ッションに固有のセッション識別コードＳＥＳ（ｍ，
ｉ）を発生させる。本発明で用いられるセッション識別
コードは、特定の決済事項に関する１処理手続（１セッ
ション）に対応したコードであって、少なくとも同一ユ
ーザに関しては、各処理手続ごとに毎回異なるユニーク
なコードになるという条件をもったコードである。図示
されているセッション識別コードＳＥＳ（ｍ，ｉ）は、
第ｍ番目の加盟店Ｓｍについての第ｉ番目のセッション
に対応して発生されたコードであることを示している。

【００３３】セッション識別コードは、上述したよう
に、少なくとも同一ユーザに関しては、各処理手続ごと
に毎回異なるユニークなコードになる、という条件をも
ったコードであれば、どのようなコードを発生させても
かまわない。別言すれば、異なるユーザに対しては、同
一のセッション識別コードを発生させてもかまわない。
ただ、実用上は、少なくとも、同一の加盟店における加
盟店用情報処理装置２００で発生させるすべてのセッシ
ョン識別コードが、互いに異なるユニークなコードにな
る、という条件下で、セッション識別コードを発生させ
た方が好ましい。これは、同一の加盟店で発行したセッ
ション識別コードがすべて異なるようにしておけば、セ
ッション識別コードとこれを発行した加盟店さえ特定で
きれば、どの加盟店がどのセッションのために当該セッ
ション識別コードを発行したのかを一義的に決定できる
ためである。更に好ましくは、すべての加盟店における
加盟店用情報処理装置２００で発生させるすべてのセッ
ション識別コードが、互いに異なるユニークなコードに
なる、という条件下で、セッション識別コードを発生さ
せるとよい。そうすれば、セッション識別コードだけを
見れば、どの加盟店がどのセッションのために当該セッ
ション識別コードを発行したのかを一義的に決定できる
ことになる。

【００３４】このようなユニークなセッション識別コー
ドを発生させるためには、決済日、決済時、セッション
番号、もしくはこれらの組合せを利用すると便利であ
る。具体的には、ユーザＵｎからクレジットカードによ
る決済を行う旨の指示があった時点が、たとえば、２０
００年１０月３０日１５時２６分３４秒であったとする
と、「２０００／１０／３０／１５／２６／３４」のよ
うなコードをセッション識別コードとして発生させるこ
とができる。あるいは、当該加盟店において決済がある
たびに、シリアル番号からなるセッション番号を更新し
てゆくようにし、このセッション番号をセッション識別
コードとして利用してもかまわない。もちろん、セッシ
ョン番号を毎日リセットするようにし、２０００年１０
月３０日における第３６５番目のセッションであれば、
「２０００／１０／３０／３６５」のようなセッション
識別コードを発生させることも可能である。更に、すべ
ての加盟店で発生されたすべてのセッション識別コード
をユニークにするのであれば、上述した各セッション識
別コードに、個々の加盟店の名前や識別コードを付加し
たものを用いるようにすればよい。たとえば、第ｍ番目
の加盟店Ｓｍの２０００年１０月３０日における第３６
５番目のセッションであれば、「ｍ／２０００／１０／
３０／３６５」のようなセッション識別コードを発生さ
せることができる。

【００３５】さて、こうして、第ｍ番目の加盟店が管理
する加盟店用情報処理装置２００において、第ｉ番目の
セッションについてのセッション識別コードＳＥＳ
（ｍ，ｉ）が発生されたら、インターネット４００を介
して、これをユーザ用情報処理装置１００へと送信す
る。ユーザ用情報処理装置１００では、この送信されて
きたセッション識別コードＳＥＳ（ｍ，ｉ）と、決済に
利用するクレジットカード１０のクレジットカード番号
Ｃｎと、の少なくとも２つの情報に基づいて、ユーザ側
演算対象データを作成する。図２に示す実施形態の場
合、クレジットカード番号Ｃｎを示す数字列に、送信さ
れてきたセッション識別コードＳＥＳ（ｍ，ｉ）を構成
する文字列を付加してなるデータを、ユーザ側演算対象
データとしている。次に、このユーザ側演算対象データ
に対して、所定のアルゴリズムＡＲＧに基づく演算処理
を行うことにより、決済識別コードＩＤ（ｍ，ｉ）を発
生させる。

【００３６】ここで、決済識別コードＩＤ（ｍ，ｉ）
は、クレジットカード番号Ｃｎおよびセッション識別コ
ードＳＥＳ（ｍ，ｉ）を含んだユーザ側演算対象データ
に所定のアルゴリズムＡＲＧに基づく演算処理を行うこ
とにより一義的に定まるコードである必要があるが、逆
に、決済識別コードＩＤ（ｍ，ｉ）に基づいて、クレジ
ットカード番号Ｃｎを知ることはできないようにする必
要がある。たとえば、アルゴリズムＡＲＧを秘密にして
おけば、決済識別コードＩＤ（ｍ，ｉ）に基づいて、ク
レジットカード番号Ｃｎを求めることはできないので、
秘密のアルゴリズムＡＲＧを用いた所定の演算を利用す
れば、このような目的は達成させることができる。た
だ、実用上は、ＨＡＳＨ関数もしくはその他の非可逆的
な関数を作用させる演算処理により、決済識別コードＩ
Ｄ（ｍ，ｉ）を求めるようにするのが好ましい。ユーザ
側演算対象データに対して、ＨＡＳＨ関数などの非可逆
的な関数を作用させる演算処理を行って決済識別コード
ＩＤ（ｍ，ｉ）を求めるようにすれば、必ず一義的な決
済識別コードＩＤ（ｍ，ｉ）が求まり、かつ、この決済
識別コードＩＤ（ｍ，ｉ）から元のユーザ側演算対象デ
ータを算出することは不可能である。このような非可逆
的な関数を作用させる演算処理を利用するようにすれ
ば、たとえば、「ＨＡＳＨ関数を作用させる」というア
ルゴリズムＡＲＧ自体は秘密にしておく必要はないの
で、秘密管理のための労力が不要になる。

【００３７】こうして、ユーザ用情報処理装置１００に
おいて、決済識別コードＩＤ（ｍ，ｉ）が発生できた
ら、これをインターネット４００を介して、加盟店用情
報処理装置２００へと送信する。結局、加盟店用情報処
理装置２００側からユーザ用情報処理装置１００側に、
セッション識別コードＳＥＳ（ｍ，ｉ）が送信され、こ
れに対する返信として、ユーザ用情報処理装置１００側
から加盟店用情報処理装置２００側に、決済識別コード
ＩＤ（ｍ，ｉ）が戻されることになる。なお、本実施形
態では、ユーザ用情報処理装置１００側から加盟店用情
報処理装置２００側には、図示のとおり、ユーザＵｎの
氏名Ｎｎも送信されるようにしている。この氏名Ｎｎの
送信は、本発明に係る決済処理を実行する上で必須の事
項ではないが、後述するように、承認業者用情報処理装
置３００における承認処理が円滑に行われるようにする
ために、実用上は、氏名Ｎｎの送信を行うのが好まし
い。また、通常は、加盟店ＳｍからユーザＵｎに商品の
発送などのサービスを提供する上でも、加盟店Ｓｍ側に
ユーザＵｎの氏名Ｎｎを通知しておく必要がある。

【００３８】さて、図１で説明したように、従来の方法
では、ユーザＵｎは、加盟店用情報処理装置２００に対
して、氏名Ｎｎ，クレジットカード番号Ｃｎ，有効期限
Ｄｎを送信する必要があったが、本実施形態に係る方法
では、氏名Ｎｎと決済識別コードＩＤ（ｍ，ｉ）とを送
信すれば足りる。有効期限Ｄｎについては、送信しても
特に問題はないが、クレジットカード番号Ｃｎについて
は、加盟店側に送信を行うと、加盟店側に悪意をもった
従業員などがいた場合に不正利用が行われる可能性があ
り、セキュリティの面で問題が生じることになる。本発
明に係る方法では、加盟店側には、クレジットカード番
号Ｃｎは一切知らされないので、このような問題は生じ
ない。

【００３９】続いて、加盟店用情報処理装置２００は、
承認業者用情報処理装置３００に対して、当該セッショ
ンについての決済金額Ｐ（ｍ，ｉ）についての決済要求
を出すことになるが、このとき、承認業者用情報処理装
置３００に対しては、少なくとも、ユーザ用情報処理装
置１００から送信されてきた決済識別コードＩＤ（ｍ，
ｉ）と、先程発生させたセッション識別コードＳＥＳ
（ｍ，ｉ）と、当該セッションについての決済金額Ｐ
（ｍ，ｉ）と、を送信すればよい。もっとも、実用上
は、これに更に、ユーザＵｎの氏名Ｎｎを送信するのが
好ましい。

【００４０】このような決済要求を受けた承認業者用情
報処理装置３００は、次のような方法で、この決済要求
に対する２つの条件判断を行い、この２つの条件がとも
に満たされていた場合に、当該決済要求に対する承認を
行う。すなわち、まず、加盟店用情報処理装置２００か
ら送信されてきた氏名Ｎｎに着目し、データベースとし
て用意されているクレジットカードの会員名簿の中か
ら、この氏名Ｎｎと同姓同名の会員を検索する。氏名Ｎ
ｎによっては、唯一の会員が検索される場合もあるし、
多数の同姓同名の会員が検索される場合もある。ここで
は、たとえば７名の同姓同名の会員が検索されたものと
しよう。クレジットカードの会員名簿には、各会員のク
レジットカード番号のデータも用意されているので、こ
の７名の会員について、ユーザ側演算対象データと同一
構成の承認業者側演算対象データを作成する。具体的に
は、ここで述べる実施形態の場合、クレジットカード番
号にセッション識別コードを付加することによりユーザ
側演算対象データが作成されていたので、全く同様に、
この７名のクレジットカード番号にそれぞれセッション
識別コードを付加することにより、７通りの承認業者側
演算対象データを作成する。そして、この７通りの承認
業者側演算対象データのそれぞれに対して、ユーザ用情
報処理装置１００側で行った所定のアルゴリズムＡＲＧ
に基づく演算処理を施す。ここで述べる実施形態の場
合、７通りの承認業者側演算対象データのそれぞれに対
して、ＨＡＳＨ関数を作用させて所定のコードを得る。

【００４１】こうして得られた７通りのコードのうち、
加盟店用情報処理装置２００から送信されてきた決済識
別コードＩＤ（ｍ，ｉ）と同一のコードが存在すれば、
当該一致をもたらしたクレジットカード番号に対応する
会員が、当該セッションにおける決済主体となるユーザ
Ｕｎであると特定することができる。別言すれば、当該
ユーザＵｎについては、そのクレジットカード番号Ｃｎ
とセッション識別コードＳＥＳ（ｍ，ｉ）とにより作成
された演算対象データに対して、ユーザ側と承認業者側
とで所定のアルゴリズムＡＲＧに基づく演算がそれぞれ
別個に行われ、その結果として決済識別コードＩＤ
（ｍ，ｉ）がそれぞれ別個に得られ、かつ、これら別個
に得られた決済識別コードＩＤ（ｍ，ｉ）が一致したこ
とになる。これは、加盟店用情報処理装置２００側から
の決済要求が、正規のクレジットカード会員であるユー
ザＵｎからの正規の決済要求に基づくものであることを
示している。そこで、承認業者用情報処理装置３００
は、この決済識別コードＩＤ（ｍ，ｉ）の一致を第１の
条件として、このユーザＵｎに関する決済要求に対する
承認を行うことができる。

【００４２】一方、７通りの演算結果のうち、加盟店用
情報処理装置２００側から送信されてきた決済識別コー
ドＩＤ（ｍ，ｉ）と一致するものが１つもない場合に
は、店用情報処理装置２００側からの決済要求は、正規
の決済要求ではないものと判断し、これに対する承認は
行わないようにする。

【００４３】このように、承認業者用情報処理装置３０
０に対して、ユーザＵｎの氏名Ｎｎが伝えられると、承
認業者用情報処理装置３００における承認処理が円滑に
進行することになる。すなわち、予め、決済主体となる
会員の候補を、氏名Ｎｎと同姓同名の会員のみ（上述の
例の場合、７名の会員）に限定し、この候補となる会員
についてのクレジットカード番号を用いた演算（上述の
例の場合、７通りのＨＡＳＨ演算）を行えばすむ。一般
に、大手のクレジットカード会社の場合、全会員数は数
１００万人のオーダーになるが、同姓同名の候補会員数
はたかだか知れた数であり、候補となる会員のクレジッ
トカード番号を用いた演算をすべて行ったとしても、演
算負担はそれほど大きなものにはならない。

【００４４】もっとも、前述したように、本発明を実施
する上では、ユーザＵｎの氏名Ｎｎを加盟店用情報処理
装置２００および承認業者用情報処理装置３００に送信
することは必須要件ではない。すなわち、承認業者用情
報処理装置３００側に氏名Ｎｎのデータが送信されなか
ったとしても、全会員を候補として、クレジットカード
番号を用いた演算を行えば、原理的には、演算結果が決
済識別コードＩＤ（ｍ，ｉ）に一致した会員を、ユーザ
Ｕｎと特定することができる。しかしながら、数１００
万人のオーダーになる全会員を候補とする演算負担は膨
大なものになるため、実用上は、本実施形態のように、
氏名Ｎｎのデータを送信するのが好ましい。また、有効
期限Ｄｎのデータを送信することにより、候補となる会
員数を絞り込むことも可能である。

【００４５】このように、承認業者用情報処理装置３０
０側において、送信されてきた決済要求が正規の決済要
求であるとの判断を下すための第１の条件は、予め登録
されている多数のユーザのうちの特定のユーザＵｎのク
レジットカード番号Ｃｎと、加盟店用情報処理装置２０
０側から送信されてきたセッション識別コードＳＥＳ
（ｍ，ｉ）と、に基づいて承認業者側演算対象データを
作成し、この承認業者側演算対象データに対してＨＡＳ
Ｈ関数を作用して得られるデータが、加盟店用情報処理
装置２００側から送信されてきた決済識別コードＩＤ
（ｍ，ｉ）と一致する、という条件である。しかしなが
ら、この第１の条件が満たされたことだけをもって、当
該決済要求が正規のものであると判断することでは、完
全なセキュリティを確保することができない。なぜな
ら、加盟店Ｓｍには、第ｉ番目のセッションの結果、ユ
ーザＵｎの氏名Ｎｎ，セッション識別コードＳＥＳ
（ｍ，ｉ），決済識別コードＩＤ（ｍ，ｉ）という１セ
ットの情報が知られてしまっているので、加盟店Ｓｍの
悪意をもった従業員が、この情報を盗み出して不正利用
する可能性があるためである。すなわち、承認業者用情
報処理装置３００において、第ｉ番目のセッションに対
する決済処理が完了した後に、再び、ユーザＵｎの氏名
Ｎｎ，セッション識別コードＳＥＳ（ｍ，ｉ），決済識
別コードＩＤ（ｍ，ｉ）という１セットの情報を承認業
者用情報処理装置３００に対して送信し、任意の金額に
ついての決済要求を出したとすると、上述した第１の条
件判断だけでは、当該決済要求も正規のものであると判
断されてしまう。

【００４６】そこで、承認業者用情報処理装置３００で
は、次のような第２の条件判断を行う。すなわち、加盟
店用情報処理装置２００から送信されてきた決済識別コ
ードＩＤ（ｍ，ｉ）が、第１の条件判断プロセスで決済
主体として特定されたユーザＵｎに関して過去に行われ
た決済処理で用いられた決済識別コードとは異なること
を第２の条件とし、この条件が満たされているか否かを
判断するのである。もちろん、このような判断を行うた
めには、決済処理を行うたびに、用いた決済識別コード
を記録蓄積しておく必要がある。上述したような不正利
用は、この第２の条件判断において検出されるため、当
該不正な決済要求は承認されることがない。すなわち、
加盟店Ｓｍの悪意をもった従業員が、盗み出した１セッ
トの情報を用いて決済要求を出したとしても、既に、ユ
ーザＵｎの氏名Ｎｎ，セッション識別コードＳＥＳ
（ｍ，ｉ），決済識別コードＩＤ（ｍ，ｉ）という１セ
ットの情報を用いた正規の決済処理が１度行われている
ため、決済識別コードＩＤ（ｍ，ｉ）は、ユーザＵｎに
関する過去の決済処理において既に用いられたコードと
同一であるとして、第２の条件を満たさず、当該承認は
拒絶されることになる。

【００４７】加盟店用情報処理装置２００において発生
させるセッション識別コードを、少なくとも同一ユーザ
に関しては、各セッションごとに毎回異なるようなコー
ドにするのは、上述した第２の条件判断により、不正利
用を防止するために他ならない。一般に、クレジットカ
ード番号は、各クレジットカード会社が相互に調整し合
うことにより、世界中の全クレジットカード番号がすべ
て異なるようなユニークな番号となっている。したがっ
て、ユーザが異なれば、当然、クレジットカード番号も
異なる。そこで、少なくとも同一ユーザに関しては、各
セッションごとに毎回異なるセッション識別コードを発
生させるようにしておけば（同一のユーザＵｎが、同一
の加盟店Ｓｍで複数セッションの決済を行った場合に発
生させられるセッション識別コードをそれぞれ異ならせ
るだけでなく、同一のユーザＵｎが、複数の加盟店Ｓ
ｍ，Ｓｋ，…で決済を行った場合に発生させられるセッ
ション識別コードもそれぞれ異ならせるようにしておけ
ば）、図２に示す実施形態において、クレジットカード
番号Ｃｎ＋セッション識別コードＳＥＳ（ｍ，ｉ）とし
て与えられるユーザ側演算対象データ（および承認業者
側演算対象データ）は、ユニークなものとなる。したが
って、このユーザ側演算対象データに基づいて作成され
る決済識別コードＩＤ（ｍ，ｉ）もユニークなものとな
る（実際には、ＨＡＳＨ関数などを用いて決済識別コー
ドを発生させると、ユーザ側演算対象データが異なるに
もかかわらず、偶然にも、同一の決済識別コードが生成
される可能性もあり、厳密には「ユニーク」とは言えな
いが、偶然に一致する確率が実用上零と見なせるような
設定で決済識別コードの発生を行えば、実用上の問題は
生じない）。

【００４８】また、同一ユーザＵｎに対して、加盟店が
異なっていれば、同一のセッション識別コードを発生さ
せることを許すような運用も可能である。たとえば、同
一のユーザＵｎが、加盟店Ｓｍで決済を行ったときに発
生されるセッション識別コードＳＥＳ（ｍ，ｉ）と、加
盟店Ｓｋで決済を行ったときに発生されるセッション識
別コードＳＥＳ（ｋ，ｊ）とが同一になったとすると、
これらに基づいて作成される決済識別コードＩＤ（ｍ，
ｉ）とＩＤ（ｋ，ｊ）とが同一になるが、承認業者用情
報処理装置３００に対する決済要求時に、加盟店Ｓｍか
らの決済要求であるのか、加盟店Ｓｋからの決済要求で
あるのか、を特定することにより、同一の決済識別コー
ドを、加盟店Ｓｍについての決済識別コードと、加盟店
Ｓｋについての決済識別コードとに識別した運用が可能
である。ただ、このように、同一の決済識別コードの存
在を許すような運用は、無用な混乱を招くおそれがある
ため、実用上はあまり好ましくない。

【００４９】更に、上述の実施形態では、承認業者用情
報処理装置３００において、決済要求に対する承認を行
うための第２の条件として、「送信されてきた決済識別
コードが、特定のユーザに関して過去に行われた決済処
理で用いられた決済識別コードとは異なる」という条件
を用いているが、決済識別コードがユニークなものであ
ることを確認する代わりに、セッション識別コードがユ
ニークであることを確認する方法を採ることも可能であ
る。この場合は、決済要求に対する承認を行うための第
２の条件として、「送信されてきたセッション識別コー
ドを、過去に送信されてきたセッション識別コードと比
較した結果、セッション識別コードの発生条件の範囲内
でユニークなコードとなっている」という条件を設定す
ればよい。ここで、「セッション識別コードの発生条件
の範囲内でユニーク」としているのは、加盟店用情報処
理装置２００におけるセッション識別コードを発生させ
る際の運用方法に何通りかのバリエーションがあり、承
認業者用情報処理装置３００において、セッション識別
コードが所定の運用通りの条件で発生されたか否かが確
認できればよい、という考え方に基づいている。

【００５０】たとえば、加盟店用情報処理装置２００に
おいてセッション識別コードを発生させる際に、「すべ
ての加盟店における加盟店用情報処理装置で発生させる
すべてのセッション識別コードが、互いに異なるユニー
クなコードになる」という発生条件を設定したとすれ
ば、承認業者用情報処理装置３００に送信されてきたセ
ッション識別コードは、すべて異なっているはずであ
る。一方、「同一の加盟店における加盟店用情報処理装
置で発生させるすべてのセッション識別コードは、互い
に異なるユニークなコードになる」という発生条件を設
定したとすれば、異なる加盟店で発生されたセッション
識別コードであれば、同一のものが存在する可能性があ
るし、更に、「同一の加盟店において同一のユーザにつ
いて発生させるすべてのセッション識別コードは、互い
に異なるユニークなコードになる」という発生条件を設
定したとすれば、異なるユーザについて発生されたセッ
ション識別コードであれば、同一のものが存在する可能
性がある。したがって、承認業者用情報処理装置３００
では、加盟店用情報処理装置におけるセッション識別コ
ードの発生条件の範囲内でユニークなものとなっている
ことを確認すればよい。

【００５１】以上、本発明を、図２の実施形態に基づい
て説明したが、実用上は、ユーザ用情報処理装置１００
から加盟店用情報処理装置２００に対して送信される情
報には、ユーザＵｎの氏名Ｎｎおよび決済識別コードＩ
Ｄ（ｍ，ｉ）だけでなく、ユーザＵｎの住所などの情報
や、買い物対象となる商品やその個数などを示すデータ
も含まれることになるが、このような情報送信について
の図示は省略している。また、加盟店用情報処理装置２
００から承認業者用情報処理装置３００に対して送信さ
れる情報には、加盟店自身を特定する識別コードなどの
データも含まれることになるが、このような情報送信の
図示も省略している。

【００５２】§３．本発明に係る具体的な決済処理方法 続いて、本発明に係るクレジットカードを用いた決済処
理方法のより具体的な実施形態を述べる。ここで述べる
実施形態の第１の特徴は、ユーザ用情報処理装置１００
として、ＩＣカードを利用した点にあり、第２の特徴
は、複数のクレジットカードについて適用できるように
した点にある。

【００５３】図３は、この実施形態で用いられるユーザ
用情報処理装置１００の基本構成を示すブロック図であ
る。ここに示す例では、ユーザ用情報処理装置１００
は、パソコン１１０、リーダライタ装置１２０、ＩＣカ
ード１３０によって構成されている。ＩＣカード１３０
としては、ＣＰＵおよびメモリを内蔵した演算処理機能
をもったＩＣカードであれば、どのようなＩＣカードを
用いてもかまわない。最近は、磁気カードに代わる携帯
型情報記録媒体として、種々のタイプのＩＣカードが普
及し始めている。一般に、ＩＣカードは、ソフトウエア
をロードすることにより様々な機能を付加することがで
きるので、ＩＣカードを利用して本発明に係る決済処理
方法を実施する場合、必ずしも新たな専用のＩＣカード
をユーザに配付する必要はない。ユーザが既に何らかの
ＩＣカードを所持しているのであれば、このＩＣカード
に、本発明に係る決済処理方法を実行するための専用ソ
フトウエアあるいは専用のデータ、またはその両方をロ
ードするだけで、既存のＩＣカードをそのまま利用して
本発明を実施することが可能になる。

【００５４】リーダライタ装置１２０は、このＩＣカー
ド１３０に対する情報伝送を行う汎用の読取／書込装置
であり、パソコン１１０は、このリーダライタ装置１２
０を介してＩＣカード１３０へのアクセスを行う汎用の
コンピュータである。ここ数年来、個人レベルでのパソ
コン所有率が高まり、かなりのユーザがパソコンを所有
し、インターネットへの接続環境を備えている。本発明
による決済処理方法を利用する場合、このような汎用の
パソコン１１０に、汎用のリーダライタ装置１２０を接
続し、所定のソフトウエアをロードしたＩＣカード１３
０を用意すればよい。このＩＣカード１３０をリーダラ
イタ装置１２０に装着し、パソコン１１０によってアク
セスを行うようにすれば、このシステムが全体として、
§２で述べたユーザ用情報処理装置１００として機能す
ることになる。

【００５５】このように、本実施形態では、パソコン１
１０，リーダライタ装置１２０，ＩＣカード１３０から
なるシステムによって、ユーザ用情報処理装置１００が
構成されることになるが、実質的には、ＩＣカード１３
０がユーザ用情報処理装置１００としての主たる機能を
果たし、パソコン１１０およびリーダライタ装置１２０
は、このＩＣカード１３０をインターネット４００へ接
続するためのインターフェイスとしての役割を果たして
いるにすぎない。すなわち、本発明において重要な機能
を果たす情報は、いずれもＩＣカード１３０内に格納さ
れることになる。以下、このＩＣカード１３０内に格納
されている情報について説明する。

【００５６】図３に示すように、ＩＣカード１３０内に
は、「ＰＲＧ」，「ＡＲＧ」，「ＰＩＮ」，「ＤＡＴ
Ｅ」，「ＭＡＧ」なる情報が収容されている。ここで、
「ＰＲＧ」は、このＩＣカード１３０を本発明に係るユ
ーザ用情報処理装置１００の主たる構成要素として機能
させるためのプログラムであり、§２で述べたユーザ用
情報処理装置１００の各機能は、このプログラムの制御
のもとに実現されることになる。また、「ＡＲＧ」は、
図２に示す演算対象データ（図２の例では、クレジット
カード番号Ｃｎ＋セッション識別コードＳＥＳ（ｍ，
ｉ））に対して行うべき所定のアルゴリズムに基づく演
算処理ルーチンであり、具体的には、たとえばＨＡＳＨ
関数などを作用させるアルゴリズムのルーチンというこ
とになる。次の「ＰＩＮ」は、このＩＣカード１３０の
利用を可能にするためのユーザＵｎ自身の識別コードで
ある。ユーザＵｎは、このＩＣカード１３０をリーダラ
イタ装置１２０に装着した後、パソコン１１０から正し
い「ＰＩＮ」コードを入力する作業を行う。入力した
「ＰＩＮ」コードは、ＩＣカード１３０内部の「ＰＩ
Ｎ」コードと照合され、両者が一致していた場合に、以
後のＩＣカード１３０へのアクセスが許可されることに
なる。この「ＰＩＮ」コードの照合機能は、一般的なＩ
Ｃカード１３０には必ず備わっている既存の機能であ
り、本発明に固有の機能というわけではない。「ＤＡＴ
Ｅ」は、現在の日付および時刻を示すデータであり、一
般に、外部からＩＣカード１３０に知らされる（ＩＣカ
ードの中では、知らされた日付がシーケンシャルである
かをチェックすることもある。）。また、「ＭＡＧ」は
いわゆるマジックコードであり、後述するように、決済
識別コードを作成するために利用される。

【００５７】上述の各情報のうち、「ＰＩＮ」はＩＣカ
ード１３０を利用するための基本的なコードであり、
「ＤＡＴＥ」はＩＣカード１３０に対して外部から与え
られるデータであるので、いずれも、一般的なＩＣカー
ドに標準的に備わっている情報と言うことができる。こ
れに対して、「ＰＲＧ」，「ＡＲＧ」，「ＭＡＧ」は、
本発明の実施のために用意される専用の情報である。ユ
ーザＵｎが既に所有している既存のＩＣカード（たとえ
ば、社員証として機能するＩＣカード、診察券として機
能するＩＣカード、サービスポイントを貯めるためのＩ
Ｃカードなど、既に種々のＩＣカードが実際に利用され
ている）を、本発明のためにも流用するというケースの
場合は、準備手続として、パソコン１１０から、これら
専用の情報「ＰＲＧ」，「ＡＲＧ」，「ＭＡＧ」をＩＣ
カード１３０側へとロードすればよい。ロード対象とな
るこれら専用の情報は、ＣＤ−ＲＯＭなどに収容してユ
ーザＵｎに配付してもよいし、インターネット４００を
介してパソコン１１０へダウンロードさせるようにして
もよい。もちろん、「ＰＲＧ」，「ＡＲＧ」，「ＭＡ
Ｇ」といったデータが予めロードされたＩＣカードを用
いて、社員証、診察券、サービスポイントカードなどを
発行し、これを配布するようにすれば、これらのデータ
をロードする処理は不要になる。

【００５８】準備手続においてユーザＵｎが行う作業
は、これら専用の情報をＩＣカード１３０にロードする
作業と（上述したように、これらの専用情報が予めロー
ドされたＩＣカードが配布されていた場合は、このロー
ド作業は不要である。）、クレジットカードに関するデ
ータをＩＣカード１３０へ入力する作業である。図３に
示す例では、ユーザＵｎが、異なる２つのクレジットカ
ード会社から、それぞれクレジットカードαおよびクレ
ジットカードβなるクレジットカードの発行を受けてお
り、この２枚のクレジットカードの情報をＩＣカード１
３０へ入力して利用する例が示されている。このような
情報入力は、既にＩＣカード１３０内にロードされてい
るプログラム「ＰＲＧ」の処理機能に基づいて行うこと
ができる。図示の例の場合、クレジットカードαに記載
されている氏名αＮｎ，クレジットカード番号αＣｎ，
有効期限αＤｎと、クレジットカードβに記載されてい
る氏名βＮｎ，クレジットカード番号βＣｎ，有効期限
βＤｎと、をＩＣカード１３０内に書き込む作業が行わ
れることになる（氏名αＮｎと氏名βＮｎとは同一であ
る必要はなく、たとえば、一方を家族名義にしてもかま
わない。）。ユーザＵｎは、クレジットカードα，βを
手元に置いて、パソコン１１０のキーボードなどから、
これらのデータを入力する作業を行う。なお、この例で
は、更に、利用限度額αＬｎ，βＬｎを入力している。
この利用限度額αＬｎ，βＬｎの役目については、§４
の変形例のところで述べる。

【００５９】こうして、各クレジットカードα，βにつ
いて、氏名αＮｎ，βＮｎ，クレジットカード番号αＣ
ｎ，βＣｎ，有効期限αＤｎ，βＤｎ，利用限度額αＬ
ｎ，βＬｎの入力作業が完了すると、ユーザＵｎ側の準
備手続は完了である。一方、このような準備手続により
ＩＣカード１３０内に格納されることになった「ＰＲ
Ｇ」，「ＡＲＧ」，「ＭＡＧ」といったデータは、承認
業者用情報処理装置３００側にも用意しておく必要があ
る。これは、ユーザ用情報処理装置１００側と承認業者
用情報処理装置３００側とで、決済識別コードを生成す
るために同一の演算を行う必要があるためである。ま
た、承認業者用情報処理装置３００側には、個々のユー
ザＵｎについての氏名Ｎｎ，クレジットカード番号Ｃ
ｎ，有効期限Ｄｎ，住所，電話番号などの情報が既にデ
ータベースとして用意されている。

【００６０】このような準備手続が完了すれば、このＩ
Ｃカード１３０自身を、クレジットカードα，βの代用
カードとして利用することができるようになる。別言す
れば、このＩＣカード１３０は、クレジットカードα，
βのいわゆる「子カード」として機能することになる。
図３には、２枚のクレジットカードα，βの情報をＩＣ
カード１３０内に入力した例が示されているが、もちろ
ん、３枚以上のクレジットカードについての情報をＩＣ
カード１３０内に入力することも可能であり、ユーザＵ
ｎは、このＩＣカード１３０を、多数のクレジットカー
ドの「子カード」として利用することが可能になる。し
かも、このＩＣカード１３０は、本質的には、各クレジ
ットカードと同等のカード（同一のクレジットアカウン
トについてのカード）であるので、ＩＣカード１３０を
発行するために、新たに各クレジットカード会社の審査
を受ける必要はない。クレジットカード会社によって
は、いわゆる 「家族カード」と称するユーザの家族名
義の「子カード」を発行するサービスを提供しているこ
とがあるが、通常、このような「家族カード」の発行を
受けるためには、その旨の申請書をクレジットカード会
社に提出し、一応の審査を受ける必要がある。本発明に
よって発行されるＩＣカード１３０は、このような「家
族カード」とは全く性質の異なるカードであり、本質的
に元のクレジットカードと同一のアカウントを利用した
カードということになるので、発行に際してクレジット
カード会社による新たな審査は必要なく、繁雑な事務処
理を経ることなしに円滑な発行が可能である。

【００６１】続いて、このＩＣカード１３０を用いた決
済処理の手順を説明する。上述したように、ＩＣカード
１３０は、必ずしも本発明に利用する専用のカードにす
る必要はなく、他の種々の用途に共用することが可能で
ある。ユーザＵｎは、このＩＣカード１３０を、本発明
に係る決済処理に利用する場合に、リーダライタ装置１
２０に装着すればよい。ユーザＵｎが、パソコン１１０
を用いて加盟店の仮想ショッピングモールのＷｅｂペー
ジにアクセスし、クレジットカードによる決済を行う場
合は、まず、ＩＣカード１３０をリーダライタ装置１２
０に装着し、パソコン１１０を用いて「ＰＩＮ」データ
を入力する。ＩＣカード１３０の内部で「ＰＩＮ」デー
タの照合が完了すると、以下のような一連の決済処理が
自動的に実行される。

【００６２】まず、ユーザＵｎは、どのクレジットカー
ドを用いて決済を行うかを選択する入力を行う。たとえ
ば、ユーザＵｎがクレジットカードαによって決済する
旨の選択入力を行うと、ユーザＵｎの氏名αＮｎ（クレ
ジットカードαについて登録されている氏名）がインタ
ーネット４００を介して加盟店用情報処理装置２００へ
と送信される。実際には、この他、ユーザＵｎの住所、
電話番号、Ｅメールアドレス、購入した商品や数量を示
す情報なども送信されることになる。このような処理
は、ＩＣカード１３０内のプログラム「ＰＲＧ」と、加
盟店用情報処理装置２００のＷｅｂサーバ内のプログラ
ムの連繋動作によって行われる。

【００６３】加盟店用情報処理装置２００は、ユーザ用
情報処理装置１００側から、これらの情報が送信されて
きたら、§２で述べたように、ユニークなセッション識
別コードを発生させる。本発明を実施する上で、セッシ
ョン識別コードは、少なくとも同一ユーザに関しては、
各処理手続ごとに毎回異なるユニークなコードが発生で
きればよいので、ユーザ用情報処理装置１００側から送
信されてきたユーザの氏名αＮｎ、住所、電話番号など
からユーザＵｎを特定し、少なくとも同一ユーザに関し
ては、各処理手続ごとに毎回異なるようなセッション識
別コードを発生させるようにすればよい。ただ、ここで
述べる実施形態では、すべての加盟店において発生され
たすべてのセッション識別コードが、互いに異なるユニ
ークなコードとなるように、たとえば、第ｍ１番目の加
盟店Ｓｍ１の第ｉ１番目のセッションであれば、ＳＥＳ
（ｍ１，ｉ１）なるセッション識別コードを発生させる
ようにしている。こうして発生されたセッション識別コ
ードＳＥＳ（ｍ１，ｉ１）は、インターネット４００を
介して、ユーザ用情報処理装置１００へと送信される。

【００６４】ユーザ用情報処理装置１００は、送信され
てきたセッション識別コードＳＥＳ（ｍ１，ｉ１）を利
用して、決済識別コードＩＤ（ｍ１，ｉ１）を発生させ
る処理を行う。この処理は、図４に示すように、ＩＣカ
ード１３０内において行われる。図２に示す例では、
「クレジットカード番号Ｃｎ＋セッション識別コードＳ
ＥＳ（ｍ，ｉ）」をユーザ側演算対象データとして、こ
れに所定のアルゴリズムに基づく演算を施すことによ
り、決済識別コードＩＤ（ｍ，ｉ）を発生させていた
が、ここに述べる実施形態では、図４の左下に示すよう
に、「αＣｎ＋αＤｎ＋ＤＡＴＥ＋ＭＡＧ＋ＳＥＳ（ｍ
１，ｉ１）」をユーザ側演算対象データとして、このユ
ーザ側演算対象データに対して所定のアルゴリズムＡＲ
Ｇに基づく演算（ＨＡＳＨ関数もしくはその他の非可逆
的な関数を作用させる演算）を施すことにより、決済識
別コードＩＤ（ｍ１，ｉ１）を発生させている。ここ
で、αＣｎおよびαＤｎは、準備手続においてＩＣカー
ド１３０へ入力されたクレジットカードαについてのク
レジットカード番号および有効期限である。クレジット
カード番号αＣｎだけでなく、更に有効期限αＤｎを用
いて決済識別コードを発生させることにより、更にセキ
ュリティを高めることができる。

【００６５】一方、マジックコードＭＡＧは、時期
（年、月、日、週、時刻など）に応じて内容が変化する
特有のコード（たとえば、任意の文字列）である。たと
えば、１月は「松」、２月は「梅」、３月は「桜」、…
というように、１２か月分のマジックコードＭＡＧを任
意の文字列として定めておき、１月中に行われた決済に
は「松」なるマジックコードを採用し、２月中に行われ
た決済には「梅」なるマジックコードを採用する、とい
うような運用を行えば、セキュリティをより向上させる
ことができる。もちろん、月曜日、火曜日、水曜日、…
というように曜日ごとに異なるマジックコードを設定す
ることもできるし、偶数日と奇数日とで異なるマジック
コードを設定するようなこともできる。このように、時
期に応じて内容が変化するコードを演算対象データに含
ませてから、決済識別コードＩＤ（ｍ１，ｉ１）を作成
すれば、決済識別コードＩＤ（ｍ１，ｉ１）からクレジ
ットカード番号αＣｎを類推することを困難にする上で
極めて有効である。

【００６６】日付／時刻ＤＡＴＥは、決済時点の日付お
よび時刻を示すデータである。たとえば、２０００年１
０月３０日午後３：００というようなデータが演算対象
データの一部として組み込まれることになる。このよう
なＤＡＴＥを加えることは、上述したマジックコードＭ
ＡＧを加えることと同様に、決済識別コードＩＤ（ｍ
１，ｉ１）からクレジットカード番号αＣｎを類推する
ことを困難にする上で極めて有効である。もちろん、日
付／時刻ＤＡＴＥは、必ずしも決済日時を示すコードに
する必要はなく、たとえば、２０００年１０月３０日と
いうように決済日のみを含むコードにすることもできる
し、午後３：００というように決済時のみを含むコード
にすることもできる。また、２０００年１０月３０日午
後３時１３分２４．２秒のように、正確な秒までも含む
コードにすることも可能であるが、あまり精度の高い時
刻コードを用いると、ＩＣカード１３０内で決済識別コ
ードを生成した時刻と、承認業者用情報処理装置３００
内で決済識別コードを生成した時刻とが不一致となり、
両者の決済識別コードが一致しなくなるおそれがあるの
で、ＩＣカード１３０側のクロックと承認業者用情報処
理装置３００側のクロックとの誤差や、インターネット
４００を介しての伝送遅延時間などを考慮して、両者で
同一の時刻コードが用いられる範囲内の精度に抑える必
要がある。

【００６７】上述の例は、クレジットカードαで決済を
行う場合の処理であるが、クレジットカードβで決済を
行う場合には、図４の右下に示すような処理が行われ
る。すなわち、第ｍ２番目の加盟店から、ＳＥＳ（ｍ
２，ｉ２）なるセッション識別コードが送信されてきた
場合、「βＣｎ＋βＤｎ＋ＤＡＴＥ＋ＭＡＧ＋ＳＥＳ
（ｍ２，ｉ２）」をユーザ側演算対象データとして、こ
のユーザ側演算対象データに対して所定のアルゴリズム
ＡＲＧに基づく演算（ＨＡＳＨ関数もしくはその他の非
可逆的な関数を作用させる演算）を施すことにより、決
済識別コードＩＤ（ｍ２，ｉ２）を発生させることにな
る。ここで、βＣｎおよびβＤｎは、準備手続において
ＩＣカード１３０へ入力されたクレジットカードβにつ
いてのクレジットカード番号および有効期限である。

【００６８】なお、ここに示す実施形態では、決済識別
コードを発生させるためのアルゴリズムＡＲＧをＩＣカ
ード１３０内のメモリに格納し、決済識別コードの発生
処理を、ＩＣカード１３０内において実行するようにし
ているが、これはセキュリティを更に高めるための配慮
である。一般に、ＣＰＵ内蔵型のＩＣカードでは、内部
メモリに格納された情報に対して十分なセキュリティが
確保されており、図４に示すＩＣカード１３０内の各情
報が、不正な手段で外部に読み出される可能性はないと
考えてよい。したがって、万一、ユーザＵｎがこのＩＣ
カード１３０を紛失したとしても、内部に格納された種
々の情報が流出するおそれはない。本発明の決済処理に
必要な種々の情報を、パソコン１１０側ではなく、ＩＣ
カード１３０側に格納しているのは、ＩＣカードがこの
ような高度なセキュリティを備えているからである。

【００６９】図５は、図４に示すＩＣカード１３０内に
格納されている情報に対応して、承認業者用情報処理装
置３００内に格納されている情報の一例を示す図であ
る。ここで、「ＰＲＧ」は、承認業者用情報処理装置３
００に決済要求に対する承認処理を行わせるためのプロ
グラムであり、「ＡＲＧ」は、ＩＣカード１３０内に格
納されているのと同一の演算アルゴリズム（ＨＡＳＨ関
数もしくはその他の非可逆的な関数を作用させる演算の
アルゴリズム）であり、「ＤＡＴＥ」は、現在の日付／
時刻を示すコード（承認業者用情報処理装置３００の内
蔵クロックに基づいて生成される）であり、マジックコ
ードＭＡＧは、ＩＣカード１３０内に格納されているの
と同一のマジックコードである。また、クレジットカー
ドαあるいはβに関するデータとして、複数のユーザＵ
１，Ｕ２，…，Ｕｋ，…に関するデータがそれぞれ格納
されている。ここで、たとえば、クレジットカードαに
関する第ｋ番目のユーザＵｋのデータとしては、図示の
とおり、氏名αＮｋ，クレジットカード番号αＣｋ，有
効期限αＤｋ，利用限度額αＬＬｋ，その他、ユーザＵ
ｋの住所や電話番号、決済金額データなどが格納される
ことになる。

【００７０】既に§２で述べたように、加盟店用情報処
理装置２００から承認業者用情報処理装置３００に対し
ては、ユーザＵｎの氏名Ｎｎ，決済識別コードＩＤ（ｍ
１，ｉ１），セッション識別コードＳＥＳ（ｍ１，ｉ
１），決済金額Ｐ（ｍ１，ｉ１），加盟店Ｓｍを示すコ
ードなどのデータを送信することにより決済要求が出さ
れる。このような決済要求を受けた承認業者用情報処理
装置３００は、上述したように、２つの条件がともに満
たされていた場合に、当該決済要求に対する承認を行
う。すなわち、まず、加盟店用情報処理装置２００から
送信されてきた氏名Ｎｎに着目し、データベースとして
用意されているクレジットカードの会員名簿の中から、
この氏名Ｎｎと同姓同名の会員を検索する。たとえば７
名の同姓同名の会員が検索されたとすると、クレジット
カードの会員名簿には、各会員のクレジットカード番号
のデータも用意されているので、この７名の会員につい
て、ユーザ側演算対象データと同一構成の承認業者側演
算対象データを作成する。

【００７１】たとえば、第ｋ番目のユーザＵｋについて
の承認業者側演算対象データは、図５の右下に示すよう
に、「αＣｋ＋αＤｋ＋ＤＡＴＥ＋ＭＡＧ＋ＳＥＳ（ｍ
１，ｉ１）」ということになる。この第ｋ番目のユーザ
Ｕｋは、第ｎ番目のユーザＵｎと同姓同名であるため、
氏名Ｎｋ＝Ｎｎということになるが、クレジットカード
番号についてはそれぞれ異なる番号が与えられているの
で、αＣｋ≠αＣｎということになる。また、有効期限
については、偶然の一致がない限り、αＤｋ≠αＤｎで
ある。一方、ＤＡＴＥおよびＭＡＧについては、ユーザ
用情報処理装置１００側の演算で用いられたデータと同
一のデータが用いられるようにし、ＳＥＳ（ｍ１，ｉ
１）は、加盟店用情報処理装置２００から送信されてき
たものをそのまま用いるようにする。

【００７２】こうして、承認業者側演算対象データが作
成されたら、これに所定のアルゴリズムＡＲＧに基づく
演算を施し、決済識別コードＩＤ（ｍ１，ｉ１）を作成
し、加盟店用情報処理装置２００から送信されてきた決
済識別コードＩＤ（ｍ１，ｉ１）と一致するか否かを調
べる。同姓同名の７名の会員について、このような方法
で決済識別コードＩＤ（ｍ１，ｉ１）を作成すれば、第
ｎ番目のユーザＵｎについて作成された決済識別コード
ＩＤ（ｍ１，ｉ１）だけが、送信されてきた決済識別コ
ードＩＤ（ｍ１，ｉ１）と一致することになる。このよ
うにコードの一致が得られれば、当該一致をもたらした
クレジットカード番号に対応する会員が、当該セッショ
ンにおける決済主体となるユーザＵｎであると特定する
ことができ、このユーザＵｎに関する決済要求に対する
承認を行う上での第１の条件が満たされることになる。

【００７３】次に、承認業者用情報処理装置３００で
は、次のような第２の条件判断を行う。すなわち、加盟
店用情報処理装置２００から送信されてきた決済識別コ
ードＩＤ（ｍ１，ｉ１）が、決済主体として特定された
ユーザＵｎに関して過去に行われた決済処理で用いられ
た決済識別コードとは異なるか否かを確認する。ユーザ
Ｕｎに関して、過去に決済識別コードＩＤ（ｍ１，ｉ
１）と同一コードで決済が行われた事実がなければ、第
２の条件も満たされたことになり、当該決済要求は承認
されることになる。もちろん、§２で述べたように、決
済識別コードＩＤ（ｍ１，ｉ１）がユニークであること
を確認する代わりに、セッション識別コードＳＥＳ（ｍ
１，ｉ１）が発生条件の範囲内でユニークであることを
確認してもよい。

【００７４】§４．いくつかの変形例 最後に、本発明に係るクレジットカードを用いた決済処
理方法の変形例をいくつか述べておく。

【００７５】(1) 図２に示す実施形態では、ユーザ用
情報処理装置１００において発生させた決済識別コード
ＩＤ（ｍ，ｉ）を、加盟店用情報処理装置２００を介し
て承認業者用情報処理装置３００に送信するようにして
いるが、決済識別コードＩＤ（ｍ，ｉ）は必ずしも加盟
店用情報処理装置２００経由で承認業者用情報処理装置
３００へ送信する必要はなく、ユーザ用情報処理装置１
００から承認業者用情報処理装置３００に直接送信する
（たとえば、インターネット４００を介して、ユーザ用
情報処理装置１００から承認業者用情報処理装置３００
へ伝達する）ようにしてもかまわない。この場合、承認
業者用情報処理装置３００は、加盟店用情報処理装置２
００から、ユーザ名Ｎｎ，セッション識別コードＳＥＳ
（ｍ，ｉ），決済金額Ｐ（ｍ，ｉ）の送信を受け、ユー
ザ用情報処理装置１００から決済識別コードＩＤ（ｍ，
ｉ）の送信を受けることになるので、両者から送信され
てきた情報が、同一のセッションに関する情報であるこ
とを認識できるように、何らかの方法で同期をとるよう
な工夫（送信時間を時間的に同期させる方法に限らず、
たとえば、何らかの同期用コードを各情報に付加するよ
うな方法でもよいし、ユーザ用情報処理装置１００から
決済相手の加盟店を識別する情報を送信する方法でもよ
い）が必要になる。

【００７６】(2) 図４に示すＩＣカード１３０内に
は、各クレジットカードα，βの利用限度額αＬｎ，β
Ｌｎが設定されている。一方、図５に示す承認業者用情
報処理装置３００内にも、各クレジットカードの各ユー
ザごとに、クレジットカードの利用限度額（たとえば、
クレジットカードαの第ｎ番目のユーザＵｎについて
は、利用限度額αＬＬｎ）が設定されている。ここで、
承認業者用情報処理装置３００側に設定されている利用
限度額αＬＬｎは、クレジットカード会社が設定した本
来の利用限度額であり、ユーザＵｎは、１か月間に、こ
の利用限度額αＬＬｎを越える決済を行うことはできな
い（そのような決済要求は否認されることになる）。こ
れに対して、ＩＣカード１３０側に設定されている利用
限度額αＬｎ（あるいはβＬｎ）は、準備手続の段階で
ユーザＵｎ自身が任意に設定できる限度額である。一般
的には、αＬｎ＝αＬＬｎというように、クレジットカ
ード会社が設定した利用限度額と同じ額を、ＩＣカード
１３０内の利用限度額として設定すればよいが、敢え
て、αＬｎ＜αＬＬｎのような設定を行い、無駄遣いを
抑えるための自主管理の目的設定に用いることもでき
る。

【００７７】利用限度額αＬｎの設定を行った場合、ク
レジットカードαを用いてこの利用限度額αＬｎを越え
るような決済が行われる場合には、その旨の警告が提示
されるようにしておく。たとえば、ＩＣカード１３０内
に、今月の決済金額の累積値を記録しておくようにし、
新たに決済しようとしている金額と、この累積値との合
計が、利用限度額αＬｎを越えるような場合には、ＩＣ
カード１３０内のプログラム「ＰＲＧ」の機能によっ
て、パソコン１１０の画面上に何らかの警告表示を行う
ようにしておけばよい。αＬｎ＜αＬＬｎなる設定が行
われていた場合には、この警告表示を無視して決済を断
行することができるようにしておいてもよいし、警告表
示が出されたら当該決済は拒絶されるようにしておいて
もよい。

【００７８】(3) 前述の実施形態では、インターネッ
ト上の仮想ショッピングモールでの買い物の決済を、イ
ンターネット上で行う例について述べたが、本発明に係
る決済方法は、必ずしもインターネット決済に限定され
るものではない。たとえば、ユーザが実際の店舗に買い
物や食事に行って代金を決済する場合、クレジットカー
ドαやβを用いる代わりに、ＩＣカード１３０を用いて
決済することも可能である。この場合、当該店舗に設置
されたリーダライタ装置１２０にＩＣカード１３０を装
着して決済を行えばよい。ＩＣカード１３０は、１枚で
複数枚のクレジットカードとして機能することができ、
かつ、クレジットカード以外の種々の機能を有している
ので、多数のクレジットカードを所持する代わりに、こ
のＩＣカード１３０を１枚だけ所持していれば、すべて
のクレジットカードのアカウントを用いた決済が可能に
なる。このような利用形態では、ＩＣカード１３０を装
着したシステムがユーザ用情報処理装置１００として機
能することになる。ユーザ用情報処理装置１００は必ず
しもユーザの自宅に設置されている必要はなく、上述の
利用形態の場合は、店舗に設置されたパソコン１１０お
よびリーダライタ装置１２０が、ユーザ用情報処理装置
１００としての機能を果たしていることになる。

【００７９】(4) 本発明に係るユーザ用情報処理装置
１００は、上述のように、ＩＣカード１３０のような携
帯型情報処理装置を利用して実現することができる。Ｉ
Ｃカードの場合、現在のところ、単独ではインタネット
への接続環境やデータ入力機能が備わっていないため、
インターネット上の仮想ショッピングモールにおける決
済を行う場合には、上述の実施形態のように、パソコン
１１０およびリーダライタ装置１２０と組み合わせた形
でユーザ用情報処理装置１００を構成する必要がある
が、携帯電話や携帯型情報端末装置など、単独でインタ
ーネットに接続する環境をもった装置を利用することが
できれば、そのような装置を単独でユーザ用情報処理装
置１００として用いることにより、インターネット上で
の決済が可能になる。

【００８０】

【発明の効果】以上のとおり、本発明に係るクレジット
カードを用いた決済処理方法によれば、各加盟店に対す
るセキュリティを十分に確保することが可能になる。特
に、前述した実施形態によれば、次のような種々の効果
が得られる。 (1) ＩＣカードを、クレジットカードの「子カード」
として利用することになるが、ＩＣカードは十分なセキ
ュリティ対策が施されているため、紛失や盗難という事
故が発生しても、本物のクレジットカードに比べて安全
性が高い。すなわち、ＩＣカードの内部に格納されたデ
ータを不正な手段で外部に読み出すことは極めて困難で
あり、また、ＩＣカードの表面にはクレジットカード番
号は記載されないので、ＩＣカードを目視しても、クレ
ジットカード番号を認識することはできない。このた
め、紛失や盗難があっても、クレジットカード番号が第
三者に知られる可能性は非常に低くなる。 (2) ＩＣカード製のクレジットが普及するようになる
までには、まだ数年かかると予想されているが、本発明
に係る方法では、正式なＩＣカード製クレジットカード
を用いる場合に比べて、カードの配布やカード発行のた
めの審査といった作業に手間がかかることはないため、
迅速な導入が可能になる。本発明は、特に、インターネ
ットにおいてクレジットショッピングを実施したい場合
に有効である。 (3) 本発明では、１枚のＩＣカードに所有者が異なる
複数枚のクレジットカードを登録することも可能であ
る。したがって、たとえば、家族全員のクレジットカー
ドの共通の 「子カード」となるようなＩＣカードを作
成することも可能になり、柔軟な運用が期待できる。 (4) 「子カード」化されたＩＣカードの中には、必要
な情報を記録しておくことができるので、端末装置から
キー入力すべきデータ量を低減することができる。すな
わち、決済識別コードは、プログラムに基づいて自動的
に加盟店へと送られるため、個々のユーザが決済識別コ
ードを入力する必要はない。実用上、ユーザはセッショ
ン識別コードや決済識別コードなどの存在すら意識する
必要はない。

【図面の簡単な説明】

【図１】インターネット上の仮想ショッピングモールで
買い物をする場合の従来の一般的なクレジットカードに
よる決済処理方法の手順を説明するブロック図である。

【図２】インターネット上の仮想ショッピングモールで
買い物をする場合の本発明に係るクレジットカードによ
る決済処理方法の手順を説明するブロック図である。

【図３】本発明で用いるユーザ用情報処理装置１００を
ＩＣカード１３０を利用して構成した基本構成を示すブ
ロック図である。

【図４】図３に示すＩＣカード１３０における決済識別
コードの発生手順を示す図である。

【図５】図３に示すＩＣカード１３０に格納された情報
に対応した、承認業者用情報処理装置３００内の格納情
報の一例を示す図である。

【符号の説明】

１０…クレジットカード １００…ユーザ用情報処理装置 １１０…パソコン １２０…リーダライタ装置 １３０…ＩＣカード ２００…加盟店用情報処理装置 ３００…承認業者用情報処理装置 ４００…インターネット ＡＲＧ…決済識別コード発生用アルゴリズム（ＨＡＳＨ
関数など） Ｃ，Ｃｎ，Ｃｋ…クレジットカード番号 Ｄ，Ｄｎ，Ｄｋ…クレジットカードの有効期限 ＤＡＴＥ…現時点の日付／時刻コード ＩＤ（ｍ，ｉ）…セッション識別コードＳＥＳ（ｍ，
ｉ）に基づいて生成した決済識別コード ＩＤ（ｍ１，ｉ１）…セッション識別コードＳＥＳ（ｍ
１，ｉ１）に基づいて生成した決済識別コード ＩＤ（ｍ２，ｉ２）…セッション識別コードＳＥＳ（ｍ
２，ｉ２）に基づいて生成した決済識別コード Ｌｎ，ＬＬｎ，ＬＬｋ…利用限度額 ＭＡＧ…マジックコード Ｎ，Ｎｎ，Ｎｋ…ユーザの氏名 Ｐ…決済金額 Ｐ（ｍ，ｉ）…第ｍ番目の加盟店が生成した第ｉ番目の
セッションにおける決済金額 ＰＩＮ…ユーザ識別コード ＰＲＧ…プログラム ＳＥＳ（ｍ，ｉ）…第ｍ番目の加盟店が生成した第ｉ番
目のセッション識別コード ＳＥＳ（ｍ１，ｉ１）…第ｍ１番目の加盟店が生成した
第ｉ１番目のセッション識別コード ＳＥＳ（ｍ２，ｉ２）…第ｍ２番目の加盟店が生成した
第ｉ２番目のセッション識別コード Ｕｋ…第ｋ番目のユーザ Ｕｎ…第ｎ番目のユーザ α，β…クレジットカード α○○…クレジットカードαに関する○○ β○○…クレジットカードβに関する○○

フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/60 ５０４ Ｇ０６Ｆ 17/60 ５０４ ５１０ ５１０ ５１２ ５１２ Ｂ４２Ｄ 15/10 ５０１ Ｂ４２Ｄ 15/10 ５０１Ｌ ５２１ ５２１ Ｇ０６Ｋ 17/00 Ｇ０６Ｋ 17/00 Ｓ Ｆターム(参考） 2C005 HA01 HB09 LB55 MA01 MB08 SA01 5B058 CA27 KA02 KA04 KA08 KA31 KA35 YA02

Claims (16)

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