(57)【特許請求の範囲】
【請求項１】
商品の購入を行う購入者の購入者端末と、前記商品を販売する販売業者の販売者システムと、前記購入者の後払い方式情報を発行する後払い方式情報発行者の後払い方式情報発行者システムとがネットワークを介して接続され、また前記販売業者に代わって決済代行を行う決済代行業者の決済代行者システムが前記販売者システム及び前記後払い方式情報発行者システムと安全な回線を介して接続された電子商取引システムにおいて商品の代金支払いに後払い方式を使用する電子商取引方法であって、
前記購入者端末が、前記後払い方式情報発行者システムが発行した使い捨ての後払い方式情報を含む注文メッセージを送信することにより、前記販売者システムへ購入する商品の代金支払いを依頼する決済依頼工程と、
前記販売者システムが、前記注文メッセージに含まれた使い捨ての後払い方式情報を含む審査依頼メッセージを送信することにより、前記決済代行者システムに前記代金支払いの代行を依頼する決済代行依頼工程と、
前記決済代行者システムが、前記使い捨ての後払い方式情報と前記購入者の後払い方式情報とを対応付けた対応表を参照し、前記使い捨ての後払い方式情報に対応する前記購入者の後払い方式情報を用いて前記代金支払いが可能か否かを審査し、前記代金支払可能であるときは前記代金支払いを代行する代金支払い代行工程と、
前記決済代行者システムが、前記代金支払いを代行したとき、前記使い捨ての後払い方式情報が使用されたことを通知する使用通知メッセージを、前記後払い方式情報発行者システムに送信する後払い方式情報使用通知工程と、
前記後払い方式情報発行者システムが、前記使用通知メッセージを受信したとき、前記購入者端末へ、使用された前記使い捨ての後払い方式情報とは異なる新たな使い捨ての後払い方式情報を発行する新規使い捨て後払い方式情報発行工程と、
前記後払い方式情報発行者システムが、前記新たな使い捨ての後払い方式情報を発行したとき、前記決済代行者システムへ、当該新たな使い捨ての後払い方式情報と前記購入者の後払い方式情報とを対応付けた対応メッセージを送信する新規使い捨て後払い方式情報送信工程と、
前記決済代行者システムが、前記対応メッセージを受信したとき、当該対応メッセージに基づき、前記新たな使い捨ての後払い方式情報と前記購入者の後払い方式情報とを対応付けて前記対応表に登録する情報対応工程と、
を有することを特徴とする電子商取引方法。
【請求項２】
前記決済依頼工程の前に、
前記購入者端末が、購入者を特定する情報を含むメッセージを送信にすることにより、前記後払い方式情報発行者システムに前記使い捨ての後払い方式情報を要求する使い捨て後払い方式情報要求工程と、
前記後払い方式情報発行者が、前記メッセージに応じて前記購入者端末に前記使い捨ての後払い方式情報を発行する使い捨て後払い方式情報発行工程と、
を有することを特徴とする請求項１記載の電子商取引方法。
【請求項３】
前記後払い方式情報発行者システムが前記使い捨ての後払い方式情報を発行した場合、前記決済代行者システムは、前記後払い方式情報と前記使い捨て後払い方式情報とを対応付けて前記対応表に登録する情報対応工程を有することを特徴とする請求項２に記載の電子商取引方法。
【請求項４】
前記決済代行者システムが、使用済みの前記使い捨ての後払い方式情報を前記対応表より削除する対応情報削除工程を有することを特徴とする請求項１ないし３いずれか１項に記載の電子商取引方法。
【請求項５】
前記購入者端末と前記販売業者システムと前記決済代行者システムと前記後払い方式情報発行者システムとの間において、前記後払い方式情報、前記使い捨ての後払い方式情報、又は前記新たな使い捨ての後払い方式情報を暗号化して伝送することを特徴とする請求項１から４のいずれか１項に記載の電子商取引方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、電子商取引方法に関する。
【０００２】
【従来の技術】
近年インターネット等の普及に伴い、従来の物流に依存しない様々な形態の商取引が行われている。その中に、計算機システム及びインターネットを利用して電子決済を行う電子商取引システムがある。
【０００３】
このような電子商取引システムの例を以下に挙げる。
【０００４】
まず、第１の例としては、特開平１１−３５３３８２号公報が開示するところの『電子商取引方法およびそのシステム』がある。
【０００５】
本従来技術が解決しようとしている課題は、「決済のための買い手に識別番号を、売り手に渡すことなく、決済代行業者に直接送ることにより、経済的かつ安全な電子商取引システムを提供すること」である。
【０００６】
この課題を解決するために、本従来技術は、「所定の期間毎に各買い手についての複数の課金データを集計してなる決済代行データ及び該決済データに関連する決済データを作成し、決済データを決済代行業者に送信するとともに、決済データを、決済代行データに該当する買い手に与えられた決算のための識別番号を買い手から決済代行業者に送信することを促すための催促情報として、買い手に送信すること」を要件としている。つまり一定期間毎の決済をまとめて買い手に識別番号を決済代行業者に送ることを促すことを要件としている。
【０００７】
また、第２の例としては、特開２０００−７６３６６号公報が開示するところの『電子決済システム及び電子商取引サービスプロバイダ装置』がある。
【０００８】
本従来技術が解決しようとしている課題は、「インターネットによるオンラインショッピング等の電子商取引における電子決済認証システムに関し、クレジットカード番号等の秘匿情報の漏洩を防ぎ、簡便且つ安全に電子商取引を行うことができるようにすること」である。
【０００９】
この課題を解決するために、本従来技術は、秘匿情報の漏洩を防ぐために公衆網を使って利用者の端末をコールバックすることを要件としている。
【００１０】
また、第３の例としては、特開平１１−３４５２６４号公報が開示するところの『代金決済システム及び代金決済方法』がある。
【００１１】
本従来技術が解決しようとしている課題は、「クレジットカードによる代金決済の際に必要であった信用照会通信装置を用いることなく代金決済を行うことを可能にすること」である。
【００１２】
この課題を解決するために、本従来技術では、信用照会通信装置の代わりに「発信者番号送り出し機能を有する移動体通信端末装置」を用いることを要件としている。
【００１３】
また、第４の例としては、米国特許第５３１７６３６号公報が開示するところの『Method and apparatus for securing credit card transaction』がある。
【００１４】
本従来技術によると、クレジットカードをスマートカードにし、使用するごとに何回目の取引かの順序番号を暗号化して表示する。その値をクレジットカードのパスワードとして使用する。認証を行うコンピュータでは、そのクレジットカードに特有の方法でパスワードを解読し順序番号を求め、それがコンピュータ側に記録されているものと合致するかで認証を行う。
【００１５】
また、第５の例としては、米国特許第５６７１２７９号公報が開示するところの『Electronic commerce using a secure courier system』がある。
【００１６】
本従来技術によると、クレジットカードを使う支払いを、盗聴されるかもしれない公衆回線上を利用して安全に行うためのプロトコルが開示されている。これによれば、ユーザは販売者に暗号化したクレジットカード番号を送り、販売者は支払い機関に暗号化されたクレジットカード番号をそのまま送ることで認証を受けることが可能となる。
【００１７】
しかしながら、本従来技術では、暗号化しているとはいえ、クレジットカード番号を販売者に教えることには違いがない。
【００１８】
また、第６の例としては、米国特許第５７１５３９９号公報が開示するところの『Secure method and system for communicating a list of credit card numbers over a non-secure network』がある。
【００１９】
本従来技術によれば、電子モール側が受注したユーザのクレジットカード番号をすでに複数知っている場合、ユーザにどのクレジットカードを今回利用するか選択してもらう。この際にクレジットカード番号を表示するのでなく、クレジットカード番号の一部を表示することにより、他人に盗み見られていてもユーザのクレジットカード番号が知られないようにすることを特徴としている。
【００２０】
また、第７の例としては、米国特許第５７２４４２４号公報が開示するところの『Digital active advertising』がある。
【００２１】
本従来技術によれば、クレジットカードをオンラインで利用してユーザ認証を行うための主な事項として、ユーザが販売者にクレジットカード情報を送って買い物をする流れが開示されているが、ユーザが指定するクレジットカード情報は、単に「Account Information」と書かれているだけで具体的な開示がなされていない。また、従来技術では、電子モールに注文書を送る前に決済代行業者から承認を受けてから販売会社に送る方式が開示されている。
【００２２】
また、第８の例としては、米国特許第５７２７１６３号公報が開示するところの『Secure method for communicating credit card data when placing an order on a non-secure network』がある。
【００２３】
本従来技術によると、ユーザが電子モールで買い物をする際に注文書に品物や配達先、支払方法等を記入するがクレジットカードの番号は一部分しか記入しない。電子モールのシステムは注文書を受付けると注文書に書かれたユーザの電話番号に電話をして、ユーザにクレジットカードの番号を、たとえば電話のボタンを押して、入力してもらう。電子モールのシステムは入力された番号と注文表に書かれた番号を比べて一致していれば受付ける。
【００２４】
また、第９の例としては、米国特許第６０１６４８４号公報が開示するところの『System, method and articles of manufacture for network electronic payment instrument and certification of payment and credit collection utilizing a payment』がある。
【００２５】
本従来技術は、電子マネーに関するものである。
【００２６】
また、第１０の例としては、米国特許第６０２３６８２号公報が開示するところの『Method and apparatus for credit card purchase authorization utilizing a comparison of a purchase token with test information』がある。
【００２７】
本従来技術は、店舗におかれているクレジットカードの読み取り機に関するものであり、クレジットカードを読み取る際に同時にユーザにパスワードを入れてもらいそのパスワードをキーにクレジット番号と購入金額を暗号化して決済機関に送り、決済機関では保持しているパスワードで暗号化された情報を解読しそれが同時に送られたクレジットカード番号と購入金額と合致するかどうかで購入を許可するか否か判定し店側に知らせることを特徴としている。
【００２８】
上記に挙げた従来技術において、インターネットを用いる電子決済方式は、先払い方式と後払い方式とに大別することができる。
【００２９】
先払い方式の代表例としてはプリペイド方式があり、後払い方式の代表例としてはクレジットカード方式がある。
【００３０】
プリペイド方式では、予めある金額を、販売者であるプリペードカード発行者に支払っておき、その支払済みの金額の範囲内で商品の購買を認める。
【００３１】
しかしながら、プリペイド方式を用いた電子決済を行う場合には購買する時点で即時に決済することができるが、予め支払った金額を使い残す可能性や、プリペードカード発行者が倒産したとき未使用の金額が回収できない恐れがある。
【００３２】
これに対して、クレジットカードを用いた後払い方式には、このような欠点がなくなる。
【００３３】
クレジットカードを用いた後払い方式では、購入者は、先に購買する商品群を決め、その商品群の合計金額に対する決済をクレジットカード番号により行う。
【００３４】
しかしながら、この方式には、利便性が高いがゆえに数々の問題が存在する。
【００３５】
たとえば、この方式ではクレジットカード番号をインターネットを利用して送る必要があるが、インターネットでは誰かに盗聴される可能性がないとはいえない。
【００３６】
この危険性を回避するために、インターネット上で流れる情報を暗号化する方法が幾つも提案されている。これらの技術としては、たとえばＳＳＬ(K.E.B. Hickman, The SSL Protocol, Internet Draft <draft-hickman-netscape-ssl-00.txt>,April 1995), ＳＨＴＴＰ(E. Rescorla, A. Schiffman, The Secure HyperText Transfer Protocol, Internet Draft <draft-rescorla-shttp-00.txt., December 1994), ＰＥＭ(J. Linn, Privacy Enhancement for Internet Electronic Mail: Part 1: Message Encryption and Authentication Procedures, RFC 1421, February 1993), ＭＯＳＳ(S. Crocker, N. Freed, J. Galvin, MIME Object Security Services, Internet Draft,draft-ietf-pem-mime-08.txt>, March 1995), ＩＰＳＰ(R. Atkinson, Security Architecture for the Internet Protocol, Internet Draft<draft-ietf-ipsec-arch-02.txt>, May 1995)などがある。
【００３７】
これ以外にも特開２０００-７６７３号公報や米国特許第５７２７１６３号公報では、クレジットカード番号がインターネットを使用せず公衆電話網を利用して別に送られる方式が、また、特開平１１-３４５２６４号公報では、携帯無線電話を利用する方式などが開示されている。
【００３８】
【発明が解決しようとする課題】
しかしながら、これらの方法で安全にクレジットカード番号を送れるようになったとしても、購入者にとっては未だ問題が残る。
【００３９】
即ち、これらで開示している方式では、購入者がクレジットカード番号を教える相手が販売者とされている。従って、購入者は販売者に対して名前、住所、電話番号など詳しい個人情報とともにクレジットカード番号を教えることになる。
【００４０】
このように構成された場合、販売者自身に悪用される可能性があるばかりでなく、販売者から漏洩したり、販売者が倒産し情報が転売された場合など、購入者にとっては悪用されると被害が大きくなる可能性がある。
【００４１】
このような可能性を回避せんと、米国特許第５６７１２７９号公報では、購入者が販売者にクレジットカード番号を暗号化したものを送り、販売者が暗号化したクレジットカード番号を決済代行機関に送って支払い可能かどうか調査する方式が開示されている。
【００４２】
しかしながら、この方式をとっても購入者のクレジットカード番号が販売者の手元に残ることには変化がなく、現在のコンピュータの能力の向上スピードを考えると長期間安全な暗号方式を仮定することは難しく、悪用される危険性が減ることがあってもなくなったということができない。
【００４３】
従って、もっとも確実で安全な方法は、購入者が販売者に実際のクレジットカード番号を教えずに済ます方法である。
【００４４】
米国特許第５７２４４２４号公報はその一方式を開示している。その方式によれば、購入者は注文書にクレジットカード番号を添付して決済代行業者にインターネット上で送る。これに対し、決済代行業者は支払いを許可する際に許可証を購入者に発行する。従って、購入者はこの許可証と注文表とを販売業者にインターネットを利用して送る。
【００４５】
しかしながら、この方式では購入者が悪意を持っている場合にリスクを販売業者、決済機関に負わせることになる。
【００４６】
たとえば１回の支払い限度が５万円の購入者がいたとする。この購入者が５０万円の注文表を改ざんして５万円にして決済機関から許可書をもらい、それに本来の５０万円の注文表につけて販売業者に回してしまう。販売業者はその許可証を信じて品物を発送すると入金は５万円しかなくなる。このような事故がおこりうる。また悪意あるユーザが許可書そのものを偽造してしまうことも考えられる。
【００４７】
また、米国特許第５７２４４２４号公報では決済機関が発行する許可証に関しては、単に改ざん不可能なとしか開示されておらず、具体的方法が明示されていない。しかし、どのような方法を取るにしろ、たとえば暗号化したとしても、コンピュータの発達を考えると購入者が悪意を持って行えば、改ざんされてしまう危険性が絶対にないとは言いきれない。この可能性を完全に無くすには購入者に許可証がわたることがないようにする必要がある。
【００４８】
従って、本発明は、上記問題に鑑みなされたもので、不正が排除された電子商取引方法、決済代行方法、使い捨て後払い方式情報発行方法、および決済依頼方法を提供することを目的とする。
【００４９】
【課題を解決するための手段】
係る目的を達成するために、本発明は、商品の代金支払いに後払い方式を使用する電子商取引方法であって、購入者端末が、決済代行者システムまたは後払い方式情報発行者システムが発行した使い捨ての後払い方式情報を用いて販売者システムへ購入する商品の代金支払いを依頼する決済依頼工程と、販売者システムが、使い捨ての後払い方式情報を用いて決済代行者システムに代金支払いの代行を依頼する決済代行依頼工程と、決済代行者システムが、使い捨ての後払い方式情報に対応する購入者の後払い方式情報を用いて代金支払いを代行する代金支払い代行工程と、を有することを特徴としている。
【００５０】
これにより、本発明では、不正が排除された電子商取引方法を提供することが可能となる。
【００５１】
さらに、本発明は、購入者端末が、購入者を特定する情報を含むメッセージを用いて、決済代行者システムまたは後払い方式情報発行者システムに使い捨ての後払い方式情報を要求する使い捨て後払い方式情報要求工程と、決済代行者システムまたは後払い方式情報発行者が、メッセージに応じて購入者端末に使い捨ての後払い方式情報を発行する使い捨て後払い方式情報発行工程と、を有することを特徴としている。
【００５２】
これにより、本発明では、購入者の必要に応じて使い捨て後払い方式情報を提供することが可能となり、不必要に使い捨て後払い方式情報を存在させることがなく、購入者が余分な情報を管理する必要がなくなる。
【００５３】
さらに、本発明は、決済代行者システムが、使い捨ての後払い方式情報が使用されたことを後払い方式情報発行者システムに通知する後払い方式情報使用通知工程と、後払い方式情報発行者システムが、購入者端末へ新たに使い捨ての後払い方式情報を発行する使い捨て後払い方式情報発行工程と、を有することを特徴としている。
【００５４】
これにより、本発明では、購入者に、使い捨て後払い方式情報の使用の度に新たな使い捨て後払い方式情報を提供することが可能となるため、購入者が常に使用可能な使い捨て後払い方式情報を保持することが可能となり、購入時の余分な手間を省くことが可能となる。
【００５５】
さらに、本発明は、後払い方式情報発行者システムが使い捨ての後払い方式情報を発行した場合、決済代行者システムは、後払い方式情報と使い捨て後払い方式情報との対応をとる情報対応工程を有することを特徴としている。
【００５６】
これにより、本発明では、使い捨て後払い方式情報が後払い方式情報発行者システムにおいて発行されるよう構成された場合でも、常に最新の状態で、決済代行者において後払い方式情報と使い捨て後払い方式情報との対応を管理することが可能となるため、決済の代行にあたり、使い捨ての後払い方式情報から購入者の真（正規）の後払い方式情報を確実に特定することが可能となる。
【００５７】
さらに、本発明は、決済代行者システムが、使い捨ての後払い方式情報が使用されると、購入者へ新たに使い捨ての後払い方式情報を生成する使い捨て後払い方式情報生成工程と、決済代行者システムが、使い捨て後払い方式情報発行工程において発行した使い捨ての後払い方式情報と後払い方式情報との対応をとる情報対応工程と、を有することを特徴としている。
【００５８】
これにより、本発明では、新たな使い捨て後払い方式情報を決済代行者システムにおいて発行することが可能となるため、使い捨て後払い方式情報と真の後払い方式情報との対応を一カ所で生成・管理することが可能となり、同様の情報が複数のシステムに存在する場合よりも管理が容易となり、かつ安全性を向上させることが可能となる。
【００５９】
さらに、本発明は、決済代行者システムが、使用済みの使い捨ての後払い方式情報を対応より削除する対応情報削除工程を有することを特徴としている。
【００６０】
これにより、本発明では、一度使用した使い捨て後払い方式情報が再度使用されること避けることが可能となるため、使い捨て後払い方式情報のライフサイクルを購入者に従い適度な長さにすることが可能となる。
【００６１】
さらに、本発明では、購入者端末と販売業者システムと決済代行者システムと後払い方式情報発行者システムとの間において、後払い方式情報または使い捨ての後払い方式情報を暗号化して伝送することを特徴としている。
【００６２】
これにより、本発明では、電子商取引の当事者以外による盗聴を困難とすることが可能となり、個人情報が当事者以外に漏れる可能性を減少させることが可能となる。
【００６３】
さらに、本発明では、決済代行者システムと方式情報発行者システムとは、同一システムであることを特徴としている。
【００６４】
これにより、本発明では、本方法を実現するための構成を簡略化することが可能となり、さらに運用にあたっても、各工程を簡略化して実施することが可能となる。
【００６５】
また、本発明は、商品の代金支払いに後払い方式を使用する電子商取引方法における決済代行者システムの決済代行方法において、決済代行者システムまたは後払い方式情報発行者システムが、購入者の要求または購入者の使用に応じて、購入者に対して発行した使い捨ての後払い方式情報を用いた代金支払いの代行の依頼を販売者システムより受ける決済代行依頼受注工程と、使い捨ての後払い方式情報に対応する購入者の後払い方式情報を用いて代金支払いを代行する代金支払い代行工程と、を有することを特徴としている。
【００６６】
これにより、本発明では、不正を排除して決済の代行を行うことが可能となる。
【００６７】
また、本発明は、商品の代金支払いに後払い方式を使用する電子商取引方法における後払い方式情報発行者システムの使い捨て後払い方式情報発行方法において、購入者端末から購入者を特定する情報を含むメッセージを用いて使い捨ての後払い方式情報が要求された場合、または、決済代行者システムから使い捨ての後払い方式情報の使用が通知された場合に、購入者端末へ新たに使い捨ての後払い方式情報を発行する使い捨て後払い方式情報発行工程と、該使い捨て後払い方式情報発行工程において発行された使い捨ての後払い方式情報と後払い方式情報との対応を決済代行者システムへ通知する情報対応通知工程と、を有することを特徴としている。
【００６８】
これにより、本発明では、不正を排除した電子商取引を行うための使い捨て後払い方式情報を発行することが可能となる。
【００６９】
また、本発明は、商品の代金支払いに後払い方式を使用する電子商取引方法における販売者システムの決済依頼方法において、決済代行者システムまたは後払い方式情報発行者システムが、購入者の要求または購入者の使用に応じて、購入者に対して発行した使い捨ての後払い方式情報を用いた購入する商品の代金支払いの依頼を、購入者端末より受ける決済依頼受注工程と、使い捨ての後払い方式情報を用いて決済代行者システムに代金支払いの代行を依頼する決済代行依頼工程と、を有することを特徴としている。
【００７０】
これにより、本発明では、販売者から決済代行者へ決済を依頼するにあたり、不正が生じる可能性を防止することが可能となる。
【００７１】
また、上述した従来技術と本願との相違としては、以下に挙げる事項となる。
【００７２】
まず、従来技術における第１の例に対して本発明は、取引一件ごとに決済を行い、買い手に識別番号を決済代行業者に送ることを促さなくてすむので異なる。
【００７３】
また、従来技術における第２の例に対して本発明は、コールバックを要件とせず、必要もないので異なる。
【００７４】
また、従来技術における第３の例に対して本発明は、示されているような移動体通信端末を必要としないので異なる。
【００７５】
また、従来技術における第４の例に対して本発明は、クレジットカードをスマートカードにすることが要件でもなく、取引の順序番号を暗号化することも行ってないので異なる。
【００７６】
また、従来技術における第５の例に対して本発明では、ユーザが販売業者に使い捨てクレジットカード番号を教え実際のクレジットカード情報を教えないことを特徴としているので異なる。
【００７７】
また、従来技術における第６の例に対して本発明は、電子モール側に一度限りの使い捨てのクレジットカード番号を知らせることを特徴としているので異なる。
【００７８】
また、従来技術における第７の例に対して本発明では、販売者に送るクレジットカード情報は使い捨ての情報であるところを要件とし、さらに、ユーザが販売業者に決済代行業者が発行する使い捨てクレジットカード情報を送り、それを使用して承認手続きを行うことを要件としているので異なる。
【００７９】
また、従来技術における第８の例に対して本発明は、電子モールに使い捨てのクレジット番号を一度に全て知らせることを特徴としているので異なる。
【００８０】
また、従来技術における第９の例に対して本発明は、クレジットカードを使用した支払いシステムに関するので異なる。
【００８１】
また、従来技術における第１０の例に対して本発明は、インターネットを利用した電子商取引に関するものであり適用分野が異なる。
【００８２】
【発明の実施の形態】
〔本発明の特徴〕
本発明は、計算機システム及びネットワークを用いて、ネットワーク上で商品の購入から代金の支払い手続きまでの電子商取引を行うのに好適な方法及び該方法を実施するための電子商取引方法、決済代行方法、使い捨て後払い方式情報発行方法、および決済依頼方法である。
【００８３】
以下に示す各実施形態では、本発明に後払い方式としてクレジットカードを用いた決済手段を利用した電子商取引を適用した場合について、例を挙げて説明する。
【００８４】
〔第１の実施形態〕
まず、本発明を好適に実施した第１の実施形態について、以下に図面を用いて詳細に説明する。
【００８５】
以下、本実施形態に関し、３通りの構成例を挙げて説明する。
【００８６】
（第１の実施形態の第１の構成例）
図１は、本実施形態の第１の構成例に関わる典型的な電子商取引システムのダイアグラムである。図１に示すように、本構成例では、購入者が有する購入者コンピュータＢと、販売業者が有する販売業者コンピュータＭと、決済代行業者が有するカード情報発行コンピュータＩと、がインターネットＮを介して接続される。また、インターネットＮとは別に、専用線または公衆電話回線等の比較的安全な回線（以下、安全な回線という）を介して、決済代行業者が有する決済代行業者コンピュータＰがカード情報発行コンピュータＩおよび販売業者コンピュータＭと接続される。ただし、カード情報発行コンピュータＩは、決済代行業者とことなる業者であるカード発行業者が有するよう構成してもよい。この構成は、以下の他の構成例においても同様である。また、上記において、販売業者コンピュータＭと決済代行業者コンピュータＰとカード情報発行業者コンピュータＩとは、各々１つのコンピュータで構成することも、複数のコンピュータより成るシステムとして構成することも可能である。
【００８７】
この構成において、１０で購入者コンピュータＢは、カード情報発行コンピュータＩに使い捨てクレジットカード情報（使い捨ての後払い方式情報）を要求する（使い捨てクレジットカード情報要求メッセージ送信）。これに対して、カード情報発行コンピュータＩは、２０で使い捨てクレジットカード情報を購入者コンピュータＢにインターネットＮを介して送り（使い捨てクレジットカード情報メッセージ送信）、２５で購入者コンピュータＢに送った使い捨てクレジットカード情報と本当のクレジットカード情報との対応データを決済代行業者コンピュータＰに安全な回線を介して送る（対応データ送信）。また、３０で購入者コンピュータＢは、注文表と使い捨てクレジットカード情報とをインターネットＮを介して販売業者コンピュータＭに送る（注文メッセージ送信）。４０で販売業者コンピュータＭは、購入者コンピュータＢから送られた使い捨てクレジットカード情報と注文表とを安全な回線を介して決済代行業者コンピュータＰに送り（審査依頼メッセージ送信）、決済の許可を求める。これにより、決済代行業者コンピュータＰは、販売業者コンピュータＭから送られてきた使い捨てクレジットカード情報から実際のクレジットカード情報を知り、その情報と注文表とから決済の可否を決め、この結果を５０で安全な回線を介して販売業者コンピュータＭに送る（可否メッセージ送信）。また、販売業者コンピュータＭは、送られてきた決済の可否を、６０でインターネットＮを介して購入者コンピュータＢに知らせ（受注メッセージまたは不可メッセージ送信）、決済が可の場合には商品の発送処理を行う。
【００８８】
ただし、上記構成において、販売業者には、個人等による販売者も含まれる。
【００８９】
（第１の実施形態の第１の構成例の動作）
次に、本実施形態の第１の構成例の動作について、図面を用いて詳細に説明する。
【００９０】
図２を参照すると、購入者は、購入者コンピュータＢを使用して、自身のクレジットカード情報など個人を特定できる情報を入力し、この情報を含む使い捨てクレジットカード情報要求メッセージを作成し（Ｂ１１）、この使い捨てクレジットカード情報要求メッセージをカード情報発行コンピュータＩにインターネットＮを介して送る（Ｂ１２→Ｉ１１）。ただし、使い捨てクレジットカード情報要求メッセージには、カード情報発行コンピュータＩが要求するクレジットカード情報(クレジットカード番号と必要ならパスワード及び有効期間)が必要に応じて含まれる。
【００９１】
これに対して、カード情報発行コンピュータＩは購入者コンピュータＢから送られてきた個人を特定するための情報を検査し、正しければ使い捨てクレジットカード情報を生成し、これを含む使い捨てクレジットカード情報メッセージを作成し（Ｉ１２）、この使い捨てクレジットカード情報メッセージを購入者コンピュータＢへ送信する（Ｉ１３→Ｂ１３）。また、この動作と別に、カード情報発行コンピュータＩは購入者のクレジットカード情報と使い捨てクレジットカード情報との対応データを作成して対応メッセージを作成し（Ｉ１４）、これを安全な回線を通じて決済代行業者コンピュータＰに送る（Ｉ１５→Ｐ１１）。これに対して、決済代行業者コンピュータＰは、使い捨てクレジットカード情報と購入者のクレジットカード情報（以下、真のクレジットカード情報という）との対応が図れるように、これを保持しているテーブル（以下、これを対応表という）に登録する（Ｐ１２）。この対応表はファイルやデータベース等で作成されるものである。従って、対応のとり方は、たとえばリレーショナルデータベースで作成した場合、真のクレジットカード情報と使い捨てクレジットカード情報とを同一のレコード内に格納することで実現される。
【００９２】
また、購入者コンピュータＢはカード情報発行コンピュータＩから送られてきた使い捨てクレジットカード情報のほか、購入者の指定する購入品目、個数並びに販売者画が販売に際して要求する情報（注文表）をまとめて注文メッセージを作成し（Ｂ１４）、これを販売業者コンピュータＭにインターネットＮを介して送付する（Ｂ１５→Ｍ１１）。
【００９３】
その後、販売業者コンピュータＭでは購入者コンピュータＢから送られてきた注文表と、これに含まれている使い捨てクレジットカード情報とを検査する。そして送られてきた使い捨てクレジットカード情報とクレジット会社が審査に際して要求する情報とをまとめて審査依頼メッセージを作成し（Ｍ１２）、これを安全な回線を利用して決済代行業者コンピュータＰに送り（Ｍ１３→Ｐ１３）、決済代行業者において審査を受ける。
【００９４】
決済代行業者コンピュータＰでは送られてきた審査依頼メッセージに含まれる使い捨てのクレジットカード情報から、Ｐ１２において更新した対応表を検索し、対応する実際のクレジットカード情報を得、また、真のクレジットカード情報と販売業者コンピュータＭから送られてきた他の情報とを使用して審査を行い、決済の代行の可否を示すメッセージ（以下、可否メッセージという）を作成し、また、ともに、使用された使い捨てクレジットカード情報と実際のクレジットカード情報との対応データを破棄する（ただし、破棄をするにあたり、使い捨てクレジットカード情報を削除する；Ｐ１４）。その後、この可否メッセージを安全な回線を利用して販売業者コンピュータＭへ通知する（Ｐ１５→Ｍ１４）。
【００９５】
このように、支払いの可否（決済の代行の可否）が通知されると、販売業者コンピュータＭでは、決済代行業者コンピュータＰから送られてきた審査結果に基づくメッセージ（受注メッセージまたは受注を拒否するメッセージ）を作成し（Ｍ１５）、審査結果が可であれば、購入者コンピュータＢに対して受注したことをインターネットＮを介して知らせ、受注内容を通知するために受注メッセージを送信し（Ｍ１６→Ｂ１６）、実際に商品の発送処理を行う（Ｍ１７，Ｍ１８→Ｂ１７）。また、不可であれば受注できないことを購入者コンピュータＢにインターネットＮを介して知らせる（Ｍ１６→Ｂ１６）。
【００９６】
この構成例では、クレジットカードを利用しているが、キャッシュカード、デビットカードのような他の後払い方式を利用してもかまわない。
【００９７】
また、図２に示す動作において、インターネットＮを介して情報を送る際には、インターネット上を情報が流れるのであるから、当事者以外に情報が漏洩する危険を減らすために情報を暗号化して流すことが望ましい。
【００９８】
さらに、Ｉ１２でカード情報発行コンピュータＩが使い捨てクレジットカード情報を生成する際においては、乱数などを用いてランダムな情報を生成し、どのような順番でクレジットカード情報が生成されるか他者からは伺えないようにすることが望ましい。ただし、現在使用中の使い捨て情報と、同じ値にならないようにする。
【００９９】
この構成では、決済代行業者コンピュータＰとカード情報発行コンピュータＩとを別のコンピュータにしたが、決済代行業者コンピュータＰとカード情報発行コンピュータＩとは同一のコンピュータ上で実現されていても良い。
【０１００】
さらに、上記における各メッセージの一例について、図面を用いて詳細に説明する。
【０１０１】
・使い捨てクレジットカード情報要求メッセージ
図２のＢ１１において、購入者コンピュータＢで作成される使い捨てクレジットカード情報要求メッセージは、図３に示すように、使い捨てクレジットカード情報を要求する要求者（購入者）の情報と、要求する使い捨てクレジットカード情報の内容を示す要求クレジットカード情報と、を含んで構成される。
【０１０２】
この構成において、購入者の情報としては、たとえば、図３に示すように、名前と真のクレジットカード番号と真のクレジットカードの有効期限と真のクレジットカードのパスワードとが含まれ、また、要求使い捨てクレジットカード情報には、たとえば、要求する使い捨てクレジットカードの有効期限とパスワードとが含まれる。従って、この要求者の情報は、暗号化等により第３者に理解されないよう構成するとよい。
【０１０３】
このように構成することで、カード情報発行コンピュータＩが、購入者の正当性および購入者の真のクレジットカード情報とを確認し、その後、新たに使い捨てクレジットカード情報を生成することが可能となる。
【０１０４】
・使い捨てクレジットカード情報メッセージ
また、図２のＩ１２で作成される使い捨てクレジットカード情報メッセージには、図４に示すように、カード情報発行コンピュータＩで生成された使い捨てクレジットカード情報が含まれる。ただし、ここで、使い捨てクレジットカード情報要求メッセージに含まれていた要求者の情報は、含ませる必要がないため、あえて含ませない方がよい。これは、要求者の情報にクレジットカード番号等の情報が含まれるため、なるべくインターネットＮ上に存在することを避けるためである。さらに、安全のため、使い捨てクレジットカード情報を暗号化して、第３者に理解されないよう構成するとよい。
【０１０５】
・注文メッセージ
また、図２のＢ１４で作成される注文メッセージは、図５に示すように、購入者より入力された注文内容を含む注文表と、使い捨てクレジットカード情報と、が含まれている。ただし、購入者コンピュータＢにおいて、注文メッセージを作成する際に、注文表に対して一方向ハッシュ関数等を利用してメッセージダイジェスト（注文表メッセージダイジェスト：高度に暗号化されたテェックサム）を計算し、これを注文メッセージに含ませるとともに、購入者コンピュータＢにおいて保存しておくよう構成するとよい。これは、後に同じ注文表に対して同じ計算をすることで内容が改ざんされているか否かを判別可能とするためである。これにより、悪意を持った者が、データを改ざんして悪用することを防ぐことが可能となる。また、メッセージダイジェストの計算動作は、購入者より注文メッセージの送信命令が入力された後に実行され、注文メッセージに付加されるよう構成するとよい。さらに、使い捨てクレジットカード情報は、暗号化されているものとするとよい。
【０１０６】
・対応メッセージ
また、図２のＩ１４で作成される対応メッセージは、図６に示すように、真のクレジットカード情報と使い捨てクレジットカード情報とを含んでおり、これを受信した決済代行業者コンピュータＰにおいて、対応表に対応して格納されるよう構成される。ただし、このとき、真のクレジットカード情報と使い捨てクレジットカード情報とは、ともに暗号化されていることが望ましい。
【０１０７】
・審査依頼メッセージ
また、図２のＭ１２で作成される審査依頼メッセージには、図７に示すように、注文表と注文表メッセージダイジェストと使い捨てクレジットカード情報とが含まれる。ここで、注文表メッセージダイジェストとしては、購入者コンピュータＢから通知されたものを転用するとよい。これは、販売業者コンピュータＭで新たに算出する必要がないためである。
【０１０８】
・可否メッセージ
また、図２のＰ１５で作成される可否メッセージには、図８に示すように、注文表と注文表メッセージダイジェストと可否情報とが含まれている。ここで、決済代行業者コンピュータＰが、購入者コンピュータＢと同一のメッセージダイジェスト算出手段を備えていることが必要となる。これは、決済代行業者コンピュータＰにおいて、注文表と注文表メッセージダイジェストとの整合を確認するだけでなく、決済代行業者に通知された注文表に対するメッセージダイジェストを可否メッセージに添付する必要があるためである。従って、決済代行業者コンピュータＰは、新たに算出した注文表メッセージダイジェストと注文表と可否情報とを含めて可否メッセージを作成する。
【０１０９】
・受注メッセージ
また、受注メッセージは、可否メッセージの可否情報において、決済の代行が可である場合に販売業者コンピュータＭにおいて作成されるものであり、注文表と注文表ダイジェストと受注データとを含んで構成される。ここで、注文表メッセージダイジェストは、決済代行業者コンピュータＰから通知されたものをそのまま転用する必要がある。これは、受注メッセージを受け取った購入者コンピュータＢにおいて、注文表が途中で改ざんされていないか否かを判別するためである。また、受注情報は、販売業者（販売業者コンピュータＭ）で付加された受注番号と、商品の発送日と、を含んでいる。
【０１１０】
（第１の実施形態の第２の構成例）
次に、本実施形態の第２の構成例を図面を用いて詳細に説明する。図１０は、本実施形態の第２の構成例に関わる典型的な電子商取引システムのダイアグラムである。図１０に示すように、本構成例では、第１の構成例と同様に、購入者コンピュータＢと販売業者コンピュータＭとカード情報発行コンピュータＩとがインターネットＮを介して接続され、このインターネットＮとは別に、専用線または公衆電話回線等の比較的安全な回線を介して、決済代行業者コンピュータＰがカード情報発行コンピュータＩおよび販売業者コンピュータＭと接続されている。
【０１１１】
この構成において、購入者コンピュータＢは１０で注文表と予めカード情報発行コンピュータＩから送られてきている使い捨てクレジットカード情報とをインターネットＮを介して販売業者コンピュータＭに送る。２０で販売業者コンピュータＭは購入者コンピュータＢから送られた使い捨てクレジットカード情報と注文表とを安全な回線を通じて決済代行業者コンピュータＰに送り、決済の許可を求める。決済代行業者コンピュータＰは販売業者コンピュータＭから送られてきた使い捨てクレジットカード情報から実際のクレジットカード情報を知り、その情報と注文表とから決済の可否を決め、３０で安全な回線を介して販売業者コンピュータＭに送る。それと同時に決済代行業者コンピュータＰは使い捨てクレジットカード情報が使用されたことを４０で安全な回線を介してカード情報発行コンピュータＩに知らせる。カード情報発行コンピュータＩは新しい使い捨てクレジットカード情報を生成し、５０で購入者コンピュータＢにインターネットＮを介して送るとともに、新しく生成した使い捨てクレジットカード情報と実際のクレジットカード情報の対応データを５５で安全な回線を通じて決済代行業者コンピュータＰに送る。販売業者コンピュータＭは送られてきた決済の可否を６０でインターネットＮを介して購入者コンピュータＢに知らせ、決済が可の場合は商品の発送処理を行う。
【０１１２】
（第１の実施形態の第２の構成例の動作）
次に、本実施形態の第２の構成例の動作について、図面を用いて詳細に説明する。ただし、本構成例では、購入者はあらかじめ使い捨てクレジットカード情報を有している。これは、本構成例では、決済代行業者が使い捨てクレジットカードが利用される毎に新たに使い捨てクレジットカードを購入者に与えるためである。ただし、初回の利用に使用される使い捨てクレジットカード情報は、あらかじめ、クレジットカード加入時または後の申請により、決済代行業者から付与されたものであるとする。
【０１１３】
図１１を参照すると、購入者は、購入者コンピュータＢを使用して、カード情報発行コンピュータＩから予め送られていた使い捨てクレジットカード情報のほか、購入者の指定する購入品目、個数並びに販売者画が販売に際して要求する情報をまとめて注文メッセージを作成し（Ｂ２１）、これをインターネットＮを介して販売業者コンピュータＭへ送信する（Ｂ２２→Ｍ２１）。
【０１１４】
これに対して、販売業者コンピュータＭでは購入者コンピュータＢから送られてきた注文表と、これに含まれる使い捨てクレジットカード情報とを検査する。
その後、送られてきた使い捨てクレジットカード情報とクレジット会社が審査に際して要求する情報とをまとめ審査依頼メッセージを作成し（Ｍ２２）、これを安全な回線を利用して決済代行業者コンピュータＰに送信して（Ｍ２３→Ｐ２１）、決済代行業者において審査を受ける。
【０１１５】
決済代行業者コンピュータＰでは送られてきた使い捨てクレジットカード情報を用いて、あらかじめカード情報発行コンピュータＩから送られている対応データを検索し、対応する真のクレジットカード情報を知る。その後、実際のクレジットカード情報と販売業者コンピュータＭから送られてきた他の情報とを使用して審査を行い、支払い（決済の代行）に関する可否を決定し、この決定を含むメッセージ（可否ッメッセージ）を作成し（Ｐ２２）、これを安全な回線を利用して販売業者コンピュータＭに知らせる（Ｐ２３→Ｍ２４）。
【０１１６】
また、決済代行業者コンピュータＰでは可否メッセージを販売業者コンピュータＭに知らせるとともに、カード情報発行コンピュータＩに対して使い捨てクレジットカード情報が利用されたことを知らせるメッセージ（使用通知メッセージ）を作成し（Ｐ２４）、これを安全な回線を通じてカード情報発行コンピュータＩに知らせるとともに（Ｐ２５→Ｉ２１）、使用された使い捨てクレジットカード情報と実際のクレジットカード情報との対応するデータを対応表より破棄する（Ｐ２４）。
【０１１７】
また、カード情報発行コンピュータＩは決済代行業者コンピュータＰから送られてきた使用された使い捨てクレジットカード情報の替わりに、新たに使い捨てクレジットカード情報を生成して新規使い捨てクレジットカード情報メッセージを作成し（Ｉ２２）、これを購入者コンピュータＢに送る（Ｉ２３→Ｂ２４）。
それと同時に、カード情報発行コンピュータＩは実際のクレジットカード情報と使い捨てクレジットカード情報との対応データを作成して対応メッセージを作成し（Ｉ２４）、これを安全な回線を通じて決済代行業者コンピュータＰに送る（Ｉ２５→Ｐ２６）。
【０１１８】
また、販売業者コンピュータＭでは決済代行業者コンピュータＰから送られてきた審査結果に応じたメッセージ（受注メッセージまたは決済の代行の不可を通知するメッセージ）を作成する。ここで、支払いが可能であるとされた場合、販売業者コンピュータＭは、受注したことを知らせる受注メッセージを作成し（Ｍ２５）、これをインターネットＮを介して購入者コンピュータＢに介して知らせ（Ｍ２６→Ｂ２３）、実際に商品の発送処理を行う（Ｍ２７，Ｍ２８→Ｂ２５）。これに対して、決済の代行が不可であれば受注できないことを購入者コンピュータＢにインターネットＮを介して知らせる（Ｍ２６→Ｂ２３に対応）。
【０１１９】
この構成例では、クレジットカードを利用しているが、キャッシュカード、デビットカードのような他の後払い方式を利用してもかまわない。
【０１２０】
また、図１１において、インターネットＮを介して情報を送る際には、インターネット上を情報が流れるのであるから、当事者以外に情報が漏洩する危険を減らすために情報を暗号化して流すことが望ましい。
【０１２１】
さらに、Ｉ２２でカード情報発行コンピュータＩが使い捨てクレジットカード情報を生成する際においては、乱数などを用いてランダムな情報を生成し、どのような順番でクレジットカード情報が生成されるか他者からは伺えないようにすることが望ましい。ただし、現在使用中の使い捨て情報と、同じ値にならないようにする。
【０１２２】
さらにまた、この構成では決済代行業者コンピュータＰとカード情報発行コンピュータＩとを別のコンピュータにしたが、決済代行業者コンピュータＰとカード情報発行コンピュータＩとは同一のコンピュータ上で実現されていても良い。
【０１２３】
また、本構成例において、注文メッセージ、審査依頼メッセージ、可否メッセージ、受注メッセージ、対応メッセージは、ともに第１の構成例におけるものと同様である。本構成例における使用通知メッセージは、使用された使い捨てクレジットカード情報が含まれるものであり、新規使い捨てクレジットカード情報メッセージは、新たにカード情報発行コンピュータＩで付与された使い捨てクレジットカード情報が含まれるものである。
【０１２４】
さらに、本構成例において、注文メッセージと審査依頼メッセージと可否メッセージと受注メッセージと対応メッセージとは、第１の構成例と同様である。また、使用通知メッセージは、使用された使い捨てクレジットカード情報を含むものであり、新規使い捨てクレジットカード情報メッセージは、新たに付与された使い捨てクレジットカード情報を含むものである。
【０１２５】
（第１の実施形態の第３の構成例）
次に、本実施形態の第３の構成例を図面を用いて詳細に説明する。図１２は、本実施形態の第３の構成例に関わる典型的な電子商取引システムのダイアグラムである。図１２に示すように、本構成例では、第１の構成例と同様に、購入者コンピュータＢと販売業者コンピュータＭとカード情報発行コンピュータＩとがインターネットＮを介して接続され、このインターネットＮとは別に、専用線または公衆電話回線等の比較的安全な回線を介して、決済代行業者コンピュータＰがカード情報発行コンピュータＩおよび販売業者コンピュータＭと接続されている。
【０１２６】
この構成において、購入者コンピュータＢは、１０で注文表と予めカード情報発行コンピュータＩから送られてきている使い捨てクレジットカード情報とをインターネットＮを介して販売業者コンピュータＭに送る。２０で販売業者コンピュータＭは購入者コンピュータＢから送られた使い捨てクレジットカード情報と注文表とを安全な回線を通じて決済代行業者コンピュータＰに送り、決済の許可を求める。決済代行業者コンピュータＰは販売業者コンピュータＭから送られてきた使い捨てクレジットカード情報から実際のクレジットカード情報を知り、その情報と注文表とから決済の可否を決め、３０で安全な回線を介して販売業者コンピュータＭに送る。それと同時に、決済代行業者コンピュータＰは新しい使い捨てクレジットカード情報を生成して４０で安全な回線を介してカード情報発行コンピュータＩに知らせる。カード情報発行コンピュータＩは新しい使い捨てクレジットカード情報を５０で購入者コンピュータＢにインターネットＮを介して送る。販売業者コンピュータＭは送られてきた決済の可否に従って６０でインターネットＮを介して購入者コンピュータＢに知らせ、決済が可の場合は商品の発送処理を行う。
【０１２７】
（第１の実施形態の第３の構成例の動作）
次に、本実施形態の第３の構成例の動作について、図面を用いて詳細に説明する。
【０１２８】
図１３を参照すると、購入者は、カード情報発行コンピュータＩから予め送られていた使い捨てクレジットカード情報のほか、購入者の指定する購入品目、個数並びに販売者が販売に際して要求する情報をまとめて注文メッセージを作成し（Ｂ３１）、これをインターネットＮを介して販売業者コンピュータＭに送付する（Ｂ３２→Ｍ３１）。ただし、初回に使用される使い捨てクレジットカード情報は、第２の構成例におけるものと同様である。
【０１２９】
また、販売業者コンピュータＭでは購入者コンピュータＢから送られてきた注文表と使い捨てクレジットカード情報とを検査する。その後、送られてきた使い捨てクレジットカード情報とクレジット会社が審査に際して要求する情報とをまとめて審査依頼メッセージを作成し（Ｍ３２）、これを安全な回線を利用して決済代行業者コンピュータＰに送り（Ｍ３３→Ｐ３１）、支払い（決済の代行）の審査を受ける。
【０１３０】
決済代行業者コンピュータＰでは送られてきた使い捨てクレジットカード情報から、対応データを検索し、対応する実際のクレジットカード情報を知る。また、真のクレジットカード情報と販売業者コンピュータＭから送られてきた他の情報とを使用して審査を行い、可否を決定する。その後、この決定を通知するためのメッセージ（可否メッセージ）を作成し（Ｐ３２）、これを安全な回線を利用して販売業者コンピュータＭに知らせる（Ｐ３３→Ｍ３４）。
【０１３１】
また、決済代行業者コンピュータＰでは、決済の代行が可の場合、可否メッセージを販売業者コンピュータＭに知らせるとともに、新しい使い捨てクレジットカード情報を生成し、これにより、対応表における使い捨てクレジットカード情報と真のクレジットカード情報との対応データを更新し（Ｐ３４）、かつ、この新しい使い捨てクレジットカード情報を含む新規使い捨てクレジットカード情報メッセージを安全な回線を通じてカード情報発行コンピュータＩに知らせる（Ｐ３５→Ｉ３３）。
【０１３２】
これに対して、カード情報発行コンピュータＩは決済代行業者コンピュータＰから送られてきた使い捨てクレジットカード情報メッセージをインターネットＮを介して購入者コンピュータＢに転送する。
【０１３３】
また、販売業者コンピュータＭでは決済代行業者コンピュータＰから送られてきた審査結果をにおいて、支払い（決済の代行）が可であれば、受注したことをインターネットＮを介して購入者コンピュータＢに知らせる受注メッセージを送信し（Ｍ３６→Ｂ３３）、実際に商品の発送処理を行う（Ｍ３７，Ｍ３８→Ｂ３５）。また、決済代行業者コンピュータＰより通知された支払い可否のメッセージの内容が不可を通知するものであれば、受注できないことをインターネットＮを介して購入者コンピュータＢへ知らせる（Ｍ３６→Ｂ３３に対応）。
【０１３４】
この構成例では、クレジットカードを利用しているが、キャッシュカード、デビットカードのような他の後払い方式を利用してもかまわない。
【０１３５】
また、図１３において、インターネットＮを介して情報を送る際には、インターネット上を情報が流れるのであるから、当事者以外に情報が漏洩する危険を減らすために情報を暗号化して流すことが望ましい。
【０１３６】
さらに、Ｐ３４において、決済代行業者コンピュータＰが使い捨てクレジットカード情報を生成する際においては、乱数などを用いてランダムな情報を生成し、どのような順番でクレジットカード情報が生成されるか他者からは伺えないようにすることが望ましい。ただし、現在使用中の使い捨て情報と、同じ値にならないようにする。
【０１３７】
さらにまた、この構成では決済代行業者コンピュータＰとカード情報発行コンピュータＩとを別のコンピュータにしたが、決済代行業者コンピュータＰとカード情報発行コンピュータＩとは同一のコンピュータ上で実現されていても良い。
【０１３８】
また、本構成例における注文メッセージと審査依頼メッセージと可否メッセージと受注メッセージと新規使い捨てクレジットカード情報メッセージとは、第２の構成例によるものと同様である。
【０１３９】
（第１の実施形態による効果）
このように構成することで、本実施形態では、購入者は自身の後払い方式の個人情報を販売業者に知られることなく電子商取引を行うことが可能となる。さらに、販売業者は既存の設備を変えることなく支払いの認証を受けて取引を行うことができる。
【０１４０】
さらに、本実施形態によれば、購入者は必要なときのみ使い捨て後払い方式情報を得ることができ、余分の情報を保持しておく手間が省ける。
【０１４１】
さらに、本実施形態によれば、当事者以外による盗聴が困難になり個人情報が当事者以外に漏れなくなる。
【０１４２】
さらに、本実施形態によれば、支払い代行業者は余分の設備を新設する必要がなくなる。
【０１４３】
さらに、本実施形態によれば、購入者は常に使用可能な使い捨て後払い情報を保持しており、それを得るという余分の作業が不要となる。
さらに、本実施形態によれば、支払い代行業者は使い捨て後払い方式情報と実際の後払い方式情報の対応を一箇所で生成、管理することになり、同様の情報が複数のところにある場合より管理が容易になり、また安全性が高まる。
【０１４４】
〔第２の実施形態〕
次に、本発明を好適に実施した第２の実施形態について、図面を用いて詳細に説明する。ただし、本実施形態は、第１の実施形態とことなり、カード情報発行コンピュータＩを設けない構成となっている。
【０１４５】
（第２の実施形態の構成）
図１４は、本実施形態に関わる典型的な電子商取引システムのダイアグラムである。
【０１４６】
図１４に示すように、本実施形態では、購入者と販売業者と決済代行業者とが存在し、購入者が購入者コンピュータＢを、販売業者が販売業者コンピュータＭを、決済代行業者が決済代行業者コンピュータＰを、各々有して構成され、また、各コンピュータがインターネットＮを介して接続されるよう構成される。
【０１４７】
また、図１４において、１０で注文表が販売業者コンピュータＭから購入者コンピュータＢに送られ、２０で注文表と後払い方式情報とを合わせた情報が購入者コンピュータＢから決済代行業者コンピュータＰに送られ、３０で注文表と支払い許可とが決済代行業者コンピュータＰから販売業者コンピュータＭに送られ、４０で販売業者コンピュータＭが購入者からの注文を受注したことを購入者コンピュータＢに知らせる構成とされている。
【０１４８】
（第２の実施形態の動作）
上記の構成を基に、本実施形態の動作を図面を用いて詳細に説明する。
【０１４９】
図１５を参照すると、この構成において、まず、購入者は、購入品目、数量、住所、氏名、電話番号等、取引に必要な情報（注文表）とともに使用するクレジットカードの種類（クレジットカード会社を特定する情報）を購入者コンピュータＢに入力し、購入を依頼するための購入依頼メッセージを作成する（Ｂ１）。また、購入者コンピュータＢはこのように作成された購入依頼メッセージを作成し、これをインターネットＮを介して販売業者コンピュータＭへ送信する（Ｂ２→Ｍ１）。
【０１５０】
これに対して、販売業者コンピュータＭは、購入依頼メッセージを受信すると、この購入依頼メッセージに含まれる注文表の内容に基づいて、購入品目、数量を確認して在庫等を検査し、販売代金の総計を計算した後、通知された注文表に、販売代金と、購入者コンピュータＢより通知されたクレジットカードの発行会社から発行された販売業者自身を特定する情報と、を付加して注文メッセージを作成し（Ｍ２）、これをインターネットＮを介して購入者コンピュータＢへ送信する（Ｍ３→Ｂ３）。即ち、本実施形態では、あらかじめ販売業者と決済代行業者との間で登録の契約等がなされ、販売業者または販売業者コンピュータＭを識別（特定）するための情報が、決済代行業者コンピュータＰに登録、または決済代行業者で管理されている。
【０１５１】
このように、販売業者コンピュータＢより注文メッセージが通知されると、購入者は、この送られた注文表に誤りがないか否かを確認し、自分の要求に合致していれば、購入者のクレジットカード情報（クレジットカード番号等）を送られてきた注文表に付加して、決済代行業者に決済の代行を依頼するための決済依頼メッセージを作成し（Ｂ４）、これをインターネットＮを介して決済代行業者コンピュータＰへ送信する（Ｂ５→Ｐ１）。
【０１５２】
これに対して、決済代行業者コンピュータＰでは購入者コンピュータＢから送られてきた決済依頼メッセージに含まれる注文表とクレジットカード情報とを検査し、支払いを許可するか否か（決済を代行するか否か）を判断する。この判断の結果、支払いを許可する場合、決済代行業者コンピュータＰは、受信した決済依頼メッセージに含まれる注文表に支払いを許可（決済を代行）する情報を付加してメッセージ（決済の代行を許可する可否情報が付加された可否メッセージ）を作成する（Ｐ２）。また、決済代行業者コンピュータＰは、受信した注文表に添付されている販売業者を特定する情報より販売業者または販売業者コンピュータＭを特定し、作成した可否メッセージをこの販売業者コンピュータＭへインターネットＮを介して送信する（Ｐ３→Ｍ４）。この際、販売業者コンピュータＭには購入者コンピュータＢから送られてきたクレジットカード情報（クレジットカード番号等）は送られない。また、決済代行業者コンピュータＰは、支払い（決済の代行）を許可しない場合、購入者コンピュータＢへ支払いを許可（決済を代行）しないことを通知するメッセージ（決済の代行を許可しない可否情報が付加された可否メッセージ）を作成して（Ｐ２）、これをインターネットＮを介して販売業者コンピュータＭへ送信する（Ｐ３→Ｍ４）。
【０１５３】
また、このように可否メッセージを受信すると、決済の代行が許可の場合、販売業者コンピュータＭは送られてきた可否メッセージに含まれる注文表と支払いを許可する情報とを検査し、正しければ、受注が正式に行われたことを通知する受注メッセージを作成し（Ｍ５）、これをインターネットＮを介して購入者コンピュータＢへ送信する（Ｍ６→Ｂ６）。
【０１５４】
ただし、上記の例では、クレジットカードを利用しているが、キャッシュカード、デビットカードのような他の後払い方式を利用してもかまわない。
【０１５５】
また、各ステップで情報を送る際には、インターネット上を情報が流れるのであるから、当事者以外に情報が漏洩する危険を減らすために情報を暗号化して流すことが望ましい。
【０１５６】
さらに、Ｍ２で販売業者が注文表を作成する際に、販売業者コンピュータＭにおいて、作成したデータをもとに一方向ハッシュ関数等を使用したメッセージダイジェスト(高度に暗号化されたチェックサム)を同時に計算して注文表に付加し、これを購入者コンピュータＢに送るとともに保存しておくとよい。このように、注文表に対してメッセージダイジェストを付加することで、後に同じ注文表に対して同じ計算をして内容が改竄されているか否かを販売業者が判定することができる。これにより、悪意を持った購入者や盗聴者が、データを改竄して悪用することを防止することが可能となる。
【０１５７】
・注文メッセージ
ここで、Ｍ２で作成される注文メッセージの一例を図１６に示す。図１６を参照すると、<注文表>と</注文表>とではさまれた間のデータを使用して、メッセージダイジェストが計算され付加されている。
【０１５８】
また、Ｂ４で購入者は、自身がＢ１で入力した情報と販売業者コンピュータＭから受信した注文表の内容とが合致しているか否かを検査して、合致したときのみ次に進む。よってＢ２→Ｍ１で送った情報が改竄されたとしても、Ｂ４から次に進まねば良いので、Ｂ２→Ｍ１で情報を送る際に盗聴を防止するための暗号化は必要でも、改竄防止のための処理は不要となる。
【０１５９】
さらにＢ４で販売業者コンピュータＭから送られた注文表に自身のクレジットカード情報、クレジットカード番号、パスワード等、クレジットカード決済を実行する機関が指定する情報（以下、クレジットカード情報データという）を付加する際には、購入者コンピュータＢにおいて、注文表とクレジットカード情報データとをあわせたデータに対してメッセージダイジェストを計算して同時に付加後、決済代行業者コンピュータＰに送るとともに、これを保存しておく。このメッセージダイジェストを付加することで、後に同じデータに対して同じ計算をして内容が改竄されているか否かを購入者は知ることができる。ただし、クレジットカード情報は非常に大切であるので、盗聴できないように暗号化して送ることが望ましい。
【０１６０】
・決済依頼メッセージ
ここで、Ｂ４で作成される決済依頼メッセージの一例を図１７に示す。図１７を参照すると、<決済依頼>と</決済依頼>ではさまれた間のデータを使用して、メッセージダイジェストが計算され付加されている。
【０１６１】
また、Ｐ２において、決済代行業者コンピュータＰでは、送られてきたクレジットカード情報が検査され、正しいものか否かが検査される。その際に、可能であれば購入者コンピュータＢとメッセージダイジェストを作成する方法を共有しておき、まず送られてきた支払い許可依頼メッセージに含まれる注文表とクレジットカード情報とのメッセージダイジェストを計算して添付されているものと等しいことを検査し、改竄されていないことを確認するよう構成する。ただし、もしクレジットカード情報が暗号化されているときには、復号化して内容を検査する。
【０１６２】
さらに、決済代行業者コンピュータＰは、可能であれば販売業者コンピュータＰと注文表のメッセージダイジェストを計算する方式を共有しておき、注文表から計算された値と添付されている値とを比較して同値であることを確認して改竄されてないことを確認するよう構成する。
【０１６３】
このように、これらの確認が全て取れた後、決済代行業者（クレジットカード決済代行機関）は、定めるその他の条件と送られてきたデータと検査し、たとえば支払額は限度額を超えてないか等、それらの条件を満たせば支払い可能と判断する。
【０１６４】
ここで、支払い可能と判断された場合、購入者コンピュータＢから送られてきたデータよりクレジットカード情報と、もしあるなら購入者コンピュータＢが付加したメッセージダイジェスト情報とを削除し、残った販売業者コンピュータＭが作成した注文表と、もしあるなら販売業者コンピュータＭが付加したメッセージダイジェスト情報とに決済代行業者（決済代行業者コンピュータＰ）が支払いを許可したことを示す情報を付加する。その後出来上がった情報（支払い許可メッセージ）からメッセージダイジェストを計算してさらに付加し、出来上がったデータを注文表の中に記された販売者自身を特定する情報から販売業者コンピュータＭの通知先（アドレス等）を特定し、インターネットＮを介して支払い許可メッセージを販売業者コンピュータＭに送信する。
【０１６５】
・可否メッセージ
ここで、支払いＰ２で作成される可否メッセージの一例を図１８に示す。図１８を参照すると、<決済許可>と</決済許可>とではさまれた間のデータを使用して、メッセージダイジェストが計算され付加されている。また、このメッセージには図１７に含まれていたクレジットカード情報は含まれていないので、購入者のクレジットカード情報が販売者に知られることはない。よって販売者から情報が他に漏洩し悪用されることを購入者が心配する必要はない。
【０１６６】
また、Ｍ５において、販売業者コンピュータＭは決済代行業者コンピュータＰから送られてきたデータを検査する。ここで、可能であれば販売業者コンピュータＭは決済代行業者コンピュータＰとメッセージダイジェストの算出方法を共有し、送られてきたデータのメッセージダイジェストを計算して一致するか否かを判定することで、改竄されてないことを確認するよう構成する。また、Ｍ５では注文書データが保存されているものと一致することも確認され、改竄されてないことが確認される。その後、決済代行業者コンピュータＰから送られた支払いを許可する情報があることを確認後、購入者コンピュータＢに対して受注したことを知らせるデータ（受注メッセージ）を送信する。受注したことを知らせるデータとしては、以前購入者コンピュータＢに送ったデータと同じものに発送日等を知らせる情報を付加してデータを作り、それに対してメッセージダイジェストを計算したものを付加して送る。それとともに販売業者は、実際の商品の発送処理に取りかかかる。
【０１６７】
・受注メッセージ
ここで、Ｍ５で作成される受注メッセージの一例を図１９に示す。図１９を参照すると、<受注表>と</受注表>とではさまれた間のデータを使用して、メッセージダイジェストが計算され付加されている。このメッセージには図１８に含まれていた許可情報は含まれていないので、決済代行業者が作成する許可情報の形式が購入者に知られることはない。よって、購入者が決済代行業者に成りすまして許可情報を偽造することは困難であり、販売業者は偽造されているかどうかを他の手段で検査しなくとも信頼できる。
【０１６８】
また、購入者コンピュータＢは販売業者コンピュータＭから受注したことを知らせるデータを受け取ったのち、これをディスプレイ等を介して購入者に知らせる。ここで、購入者コンピュータＢでは、販売業者コンピュータＭから注文表と発送日等が含まれたデータが送られてきた場合、まず注文表が以前送られてきた注文表と等しいか否かが検査され改竄のないことがチェックされ、改ざんされていないことが確認された後、発送日等の情報を購入者に示し受注されたことが購入者へ通知される。
【０１６９】
また、Ｐ２において、決済代行業者（または決済代行業者コンピュータＰ）が何らかの理由で支払い（決済の代行）を拒否した場合、決済代行業者コンピュータＰは、販売業者コンピュータＭへ支払い許可メッセージを送信する（Ｐ３→Ｍ４）代わりに、購入者コンピュータＢへ、支払いを許可しない旨を知らせるデータを送信する。この支払いを許可しない旨を知らせるデータとしては、たとえば注文表と販売業者コンピュータＭのメッセージダイジェストデータ及び支払いを拒否することを示す情報が挙げられる。これに対して、支払いを許可しない旨のデータが送付された購入者コンピュータＢは、購入者に対してたとえば注文表の内容を表示し、それの決済に関して決済代行業者コンピュータＰによって支払いが拒否されたことを知らせる。
【０１７０】
（第２の実施形態による効果）
このように構成することで、本実施形態では、購入者が自身の後払い方式の個人情報を販売業者に知られることなく電子商取引を行うことが可能となる。また決済代行業者の支払いを許可する情報は決済代行業者から販売業者に直接送られるので、購入者によって偽造されている危険がない。また、本実施形態では購入者、販売業者、決済代行業者の各々が処理をするに必要な情報のみを各々に渡しているために偽造の危険がなくなり、決済業務の信用性が向上される。
【０１７１】
さらに、本実施形態によれば、電子商取引の当事者以外による盗聴が困難になり個人情報が当事者以外に漏れなくなる。
【０１７２】
さらに、本実施形態によれば、注文表を改竄されても販売業者コンピュータＭはメッセージダイジェストを再計算することで改竄を発見することが容易となり、事故を防ぐことができる。
【０１７３】
さらに、本実施形態によれば、販売業者コンピュータＭは悪意ある偽造した注文表をすばやく発見し事故を防ぐことができる。
【０１７４】
さらに、本実施形態によれば、決済代行業者コンピュータＰに送ったデータを改竄されても購入者コンピュータＢがメッセージダイジェストを再計算することで改竄を発見することが容易となり、事故を防ぐことができる。
【０１７５】
さらに、本実施形態によれば、後払い方式情報が購入者コンピュータＢと決済代行業者コンピュータＰのみが知る暗号化方式で暗号化されることによりより盗聴されにくくなり個人情報が秘匿される。
【０１７６】
さらに、本実施形態によれば、決済代行業者コンピュータＰは購入者コンピュータＢから送られてきたデータが改竄されてないことを確認でき事故が防げる。
【０１７７】
さらに、本実施形態によれば、決済代行業者コンピュータＰは購入者コンピュータＢから送られてきたデータ中の注文表が改竄されていないことを確認でき事故を防げる。
【０１７８】
さらに、本実施形態によれば、データを改竄されても決済代行業者コンピュータＰはメッセージダイジェストを再計算することで改竄を発見することが容易となり、事故を防ぐことができる。
【０１７９】
さらに、本実施形態によれば、販売業者コンピュータＭは決済代行業者コンピュータＰから送られてきたデータが改竄されていないことを確認でき事故を防げる。
【０１８０】
さらに、本実施形態によれば、データを改竄されても販売業者コンピュータＭはメッセージダイジェストを再計算することで改竄を発見することが容易となり、事故を防ぐことができる。
【０１８１】
さらに、本実施形態によれば、購入者コンピュータＢは販売業者コンピュータＭから送られてきたデータが改竄されていないことを確認でき事故を防げる。
【０１８２】
【発明の効果】
以上説明したように、請求項１記載の発明によれば、不正が排除された電子商取引方法を提供することが可能となる。即ち、購入者が自身の後払い方式の個人情報を販売業者に知らせることなく電子商取引を行うことが可能となる。さらに、本発明では、販売業者が従来の後払い方式情報を用いる設備を変更することなく支払いの認証を受けて取引を行うことが可能となる。
【０１８３】
また、請求項２記載の発明によれば、購入者の必要に応じて使い捨て後払い方式情報を提供することが可能となり、不必要に使い捨て後払い方式情報を存在させることがなく、購入者が余分な情報を管理する必要がなくなる。
【０１８４】
さらに、請求項３記載の発明によれば、購入者に、使い捨て後払い方式情報の使用の度に新たな使い捨て後払い方式情報を提供することが可能となるため、購入者が常に使用可能な使い捨て後払い方式情報を保持することが可能となり、購入時の余分な手間を省くことが可能となる。
【０１８５】
さらに、請求項４記載の発明によれば、使い捨て後払い方式情報が後払い方式情報発行者システムにおいて発行されるよう構成された場合でも、常に最新の状態で、決済代行者において後払い方式情報と使い捨て後払い方式情報との対応を管理することが可能となるため、決済の代行にあたり、使い捨ての後払い方式情報から購入者の真（正規）の後払い方式情報を確実に特定することが可能となる。
【０１８６】
また、請求項５記載の発明によれば、新たな使い捨て後払い方式情報を決済代行者システムにおいて発行することが可能となるため、使い捨て後払い方式情報と真の後払い方式情報との対応を一カ所で生成・管理することが可能となり、同様の情報が複数のシステムに存在する場合よりも管理が容易となり、かつ安全性を向上させることが可能となる。
【０１８７】
さらに、請求項６記載の発明によれば、一度使用した使い捨て後払い方式情報が再度使用されること避けることが可能となるため、使い捨て後払い方式情報のライフサイクルを購入者に従い適度な長さにすることが可能となる。
【０１８８】
さらに、請求項７記載の発明によれば、電子商取引の当事者以外による盗聴を困難とすることが可能となり、個人情報が当事者以外に漏れる可能性を減少させることが可能となる。
【０１８９】
また、請求項８記載の発明によれば、本方法を実現するための構成を簡略化することが可能となり、さらに運用にあたっても、各工程を簡略化して実施することが可能となる。
【０１９０】
さらに、請求項９記載の発明によれば、不正を排除して決済の代行を行うことが可能となる。
【０１９１】
さらに、請求項１０記載の発明によれば、不正を排除した電子商取引を行うための使い捨て後払い方式情報を発行することが可能となる。
【０１９２】
また、請求項１１記載の発明によれば、販売者から決済代行者へ決済を依頼するにあたり、不正が生じる可能性を防止することが可能となる。
【図面の簡単な説明】
【図１】本発明第１の実施形態における第１の構成例に関わる典型的な電子商取引システムのダイアグラムである。
【図２】本発明の第１の実施形態における第１の構成例に対応する販売業者コンピュータ、購入者コンピュータ、決済代行業者コンピュータ、カード情報発行コンピュータ間で電子商取引が行われるフローチャートである。
【図３】本発明の第１の実施形態の第１の構成例による使い捨てクレジットカード情報要求メッセージの一例を示す図である。
【図４】本発明の第１の実施形態の第１の構成例による使い捨てクレジットカード情報メッセージの一例を示す図である。
【図５】本発明の第１の実施形態の第１の構成例による注文メッセージの一例を示す図である。
【図６】本発明の第１の実施形態の第１の構成例による対応メッセージの一例を示す図である。
【図７】本発明の第１の実施形態の第１の構成例による審査依頼メッセージの一例を示す図でる。
【図８】本発明の第１の実施形態の第１の構成例による可否メッセージの一例を示す図である。
【図９】本発明の第１の実施形態の第１の構成例による受注メッセージの一例を示す図である。
【図１０】本発明第１の実施形態における第２の構成例に関わる典型的な電子商取引システムのダイアグラムである。
【図１１】本発明の第１の実施形態における第２の構成例に対応する販売業者コンピュータ、購入者コンピュータ、決済代行業者コンピュータ、カード情報発行コンピュータ間で電子商取引が行われるフローチャートである。
【図１２】本発明の第１の実施形態における第３の構成例に関わる典型的な電子商取引システムのダイアグラムである。
【図１３】本発明の第１の実施形態における第３の構成例に対応する販売業者コンピュータ、購入者コンピュータ、決済代行業者コンピュータ、カード情報発行コンピュータ間で電子商取引が行われるフローチャートである。
【図１４】本発明の第２の実施形態に関わる典型的な電子商取引システムのダイアグラムである。
【図１５】本発明の第２の実施形態において、販売業者コンピュータ、購入者コンピュータ、決済代行業者コンピュータ間で電子商取引が行われるフローチャートである。
【図１６】本発明の第２の実施形態において、販売業者コンピュータが購入者コンピュータに送る注文メッセージの一例である。
【図１７】本発明の第２の実施形態において、購入者コンピュータが決済代行業者コンピュータに送る、決済の許可を得るための決済依頼メッセージの一例である。
【図１８】本発明の第２の実施形態において、決済代行業者が販売業者コンピュータに送る、決済の代行の可否を示す可否メッセージの一例である。
【図１９】本発明の第２の実施形態において、販売業者コンピュータが購入者コンピュータに送る、受注したことを示す受注メッセージの一例である。
【符号の説明】
Ｂ  購入者コンピュータ
Ｉ  カード情報発行コンピュータ
Ｍ  販売業者コンピュータ
Ｎ  インターネット
Ｐ  決済代行業者コンピュータ
【図１】
0004616510.tif 000002
【図２】
0004616510.tif 000003
【図３】
0004616510.tif 000004
【図４】
0004616510.tif 000005
【図５】
0004616510.tif 000006
【図６】
0004616510.tif 000007
【図７】
0004616510.tif 000008
【図８】
0004616510.tif 000009
【図９】
0004616510.tif 000010
【図１０】
0004616510.tif 000011
【図１１】
0004616510.tif 000012
【図１２】
0004616510.tif 000013
【図１３】
0004616510.tif 000014
【図１４】
0004616510.tif 000015
【図１５】
0004616510.tif 000016
【図１６】
0004616510.tif 000017
【図１７】
0004616510.tif 000018
【図１８】
0004616510.tif 000019
【図１９】
0004616510.tif 000020