JP4676058B2 - 電子決済システム、代金決済方法、決済サーバ - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上での売買取引に係わる代金決済を行うシステムおよび方法に関する。
【０００２】
【従来の技術】
近年、インターネット上には、いわゆる電子商店や電子モール等の商品販売サイトが多数構築されており、インターネット上で商品購入を行うことが一般的になっている。また、インターネット上にはオークションサイトも数多く見られるようになっており、ネット上での個人間売買も普及しつつある。このような電子商店サイトやオークションサイトにおいて商品の売買取引が行われる場合、代金の決済方法として、一般に、クレジットカードによる決済用銀行振込みによる決済、および、商品着払いによる決済等が用いられている。
【０００３】
【発明が解決しようとする課題】
しかし、クレジットカードによる決済では、購入者はクレジットカード番号や個人情報を入力せねばならず、セキュリティ上不安を感じる者も多い。一方、銀行振込による決済では、購入する都度、銀行へ代金を振り込みに行かねばならず煩雑であり、また、振込み手数料もかかる。さらに、商品着払いによる決済は、配送業者に割増料金を支払うことが必要となる場合が多く、コスト高である。
【０００４】
本発明は、上記のような従来の決済方法に係わる問題を解消すべくなされたものであり、クレジットカードを使用することなく、かつ、安全確実にネットワーク上での代金決済を行うことが可能な電子決済システムおよび電子決済方法を提供することを目的とする。
【０００５】
【課題を解決するための手段】
上記の目的を達成するため、本発明は、ユーザ端末と販売者サーバと決済サーバからなる電子決済システムであって、
前記ユーザ端末は、
ユーザから入力を受けた購入価格を含む取引情報を決済サーバから受け取った暗号化キーにより暗号化し、暗号化コードを生成する暗号生成手段と、
前記暗号化手段で生成された暗号化コードをユーザIDおよび購入注文時に販売者サーバから通知された取引番号とともに販売者サーバに送信する第一送信手段と、
前記暗号化コードおよび前記ユーザIDを決済サーバに送信する第二送信手段とを有し、
前記販売者サーバは、
前記ユーザ端末から受信した暗号化コード、販売者ID、および、前記ユーザ端末から受信した取引番号で特定される取引における販売価格を決済サーバに送信する第三送信手段を有し、
決済サーバは、
各ユーザのユーザIDと、暗号復号キーとが記録されたデータベースと、
前記ユーザ端末から受信したユーザIDに関係付けられて前記データベースに記録された暗号復号キーを用いて前記暗号化コードを復号する復号処理手段と、
前記ユーザ端末から受信した暗号化コードと前記販売者サーバから受信した暗号化コードとが所定の対応関係を有するかを判定する判定手段と、
前記判定手段において、対応関係を有すると判定され、かつ、前記ユーザ端末から受信した暗号化コードを前記復号処理手段により復号して得られた購入価格と、前記販売者サーバから受信した販売価格とが一致する場合にのみ、代金の決済処理を実行する決済処理手段とを有することを特徴とする。
【０００７】
また、本発明は、ネットワーク上で行われた売買取引についての代金決済を行う方法であって、
前記ユーザ端末が、
ユーザから入力を受けた購入価格を含む取引情報を決済サーバから受け取った暗号化キーにより暗号化し、暗号化コードを生成する暗号生成ステップと、
前記暗号化手段で生成された暗号化コードをユーザIDおよび購入注文時に販売者サーバから通知された取引番号とともに販売者サーバに送信する第一送信ステップと、
前記暗号化コードおよび前記ユーザIDを決済サーバに送信する第二送信ステップとを実行し、
前記販売者サーバが、
前記ユーザ端末から受信した暗号化コード、販売者ID、および、前記ユーザ端末から受信した取引番号で特定される取引における販売価格を決済サーバに送信する第三送信ステップを実行し、
決済サーバが、
前記ユーザ端末から受信したユーザIDに基づいて、ユーザIDと暗号復号キーとが記録されたデータベースを参照し、暗号復号キーを用いて前記暗号化コードを復号する復号処理ステップと、
前記ユーザ端末から受信した暗号化コードと前記販売者サーバから受信した暗号化コードとが所定の対応関係を有するかを判定する判定ステップと、
前記判定ステップにおいて、対応関係を有すると判定され、かつ、前記ユーザ端末から受信した暗号化コードを前記復号処理手段により復号して得られた購入価格と、前記販売者サーバから受信した販売価格とが一致する場合にのみ、代金の決済処理を行なう決済処理ステップとを実行することを特徴とする。
【０００８】
また、本発明は、ユーザ端末と販売者サーバとネットワーク上で接続された決済サーバであって、
前記ユーザ端末から、取引毎に入力された当該取引における購入価格を含む取引情報を暗号化した暗号化コードとユーザIDを受信する第一受信手段と、
前記販売者サーバから暗号化コード、販売者IDおよび販売価格を受信する第二受信手段と、
前記ユーザ端末から受信したユーザIDに基づいて、ユーザIDと暗号復号キーとが記録されたデータベースを参照し、暗号復号キーを用いて前記暗号化コードを復号する復号処理手段と、
前記ユーザ端末から受信した暗号化コードと前記販売者サーバから受信した暗号化コードとが所定の対応関係を有するかを判定する判定手段と、
前記判定手段において、対応関係を有すると判定された場合にのみ、代金の決済処理を実行する決済処理手段とを有することを特徴とする。
なお、上記各発明において、前記ユーザ端末から受信した暗号化コードと前記販売者サーバから受信した暗号化コードとが所定の対応関係を有すると判定され、かつ、前記ユーザ端末から受信した暗号化コードを復号して得られた購入価格と、前記販売者サーバから受信した販売価格とが一致する場合にのみ、代金の決済処理を実行することとしてもよい。
【００１１】
【発明の実施の形態】
図１は本発明の一実施形態を示すネットワーク全体構成図である。図１に示す如く、本実施形態では、決済サーバー１０、販売者サーバー１２、およびユーザ端末（例えばパーソナルコンピュータ、あるいは、携帯電話やＰＤＡ等の携帯型情報処理端末）１４がインターネット１６を介して相互に接続されている。また、決済サーバー１０には、決済用銀行（決済サーバー１０からの指示に応じて口座開設、口座引き落とし、口座振替等の決済処理を行うべき旨の契約を決済サーバー１０の運営会社との間で締結した金融機関）の口座管理を行うホストコンピュータ１８が専用回線１９を介して接続されている。なお、決済サーバー１０の運営会社が金融機関である場合には、その運営会社自身が決済用銀行となることができる。
【００１２】
決済サーバー１０および販売者サーバー１２は、共に、大容量記憶装置（例えばハードディスク）や通信インターフェース等を備えたコンピュータシステムであり、インターネット１６からアクセスしてきたユーザ端末１４と、例えばＨＴＴＰ等のプロトコルに従ってデータ通信を行うことでＷＷＷサーバとして機能する。
【００１３】
販売者サーバー１２は、電子商店のＷＷＷサーバーとして機能し、ユーザはそのユーザ端末１４から販売者サーバー１２にアクセスすることで、当該電子商店から所望の商品の購入注文を行うことができる。本実施形態では、このように販売者サーバー１２にて行った購入注文に係わる代金決済が、決済サーバー１０を介して、決済用銀行に開設した購入者の口座から引き落とすことにより行われる。
【００１４】
図１に示す如く、決済サーバー１０は、顧客データベース２０、販売者データベース２２、および、コード記録データベース２４を備えている。
【００１５】
図２は、顧客データベース２０のデータ構成を示す。
図２に示す如く、顧客データベース２０には、決済用銀行に口座を開設したユーザ（以下、登録ユーザという）について、ユーザＩＤ、パスワード、個人情報（住所、氏名、メールアドレス等）、暗号復号キー、口座番号、現在口座残高、および、購入情報（購入日、購入商品名、購入数量、購入金額、購入後の口座残高等を含む購入履歴を示す情報）が互いに関係付けられて記録される。後述するように、暗号復号コードは、ユーザ端末１４から送信されてきた暗号化コードを復号するために用いられる。
【００１６】
図３は、販売者データベース２２のデータ構成を示す。
図３に示す如く、販売者データベース２２には、決済サーバー１０を介して決済を行う旨の契約を締結した電子商店サイト（以下、契約サイトという）の販売者サーバー１２について、販売者ＩＤ、入金用口座の口座番号、および、連絡先メールアドレスが互いに関係付けられて記録される。なお、本実施形態では、販売者の入金用口座も決済用銀行に開設されているものとするが、入金用口座が他の金融機関に開設されるものとしてもよく、その場合には、販売者データベース２２に、口座番号と共に金融機関コードを記録する。
【００１７】
また、コード記録データベース２４には、後述するように、販売者サーバー１２から送信されてきた暗号化コード（販売者側コード）およびユーザ端末１４から送信されてきた暗号化コード（購入者側コード）が記録される。
【００１８】
以下、本実施形態における処理の内容について説明する。
ユーザ端末１４から決済サーバー１０へのアクセスが行われると、図４に示すメニュー画面が決済サーバー１０からユーザ端末１４へ送信される。図４に示すように、メニュー画面には、「口座開設」、「購入履歴閲覧」、「購入コード送信」、「パスワード変更」、「ソフトダウンロード」等のメニュー項目が表示される。また、このメニュー画面には各契約サイトへのリンク（例えばバナー広告）が表示され、ユーザはメニュー画面から所望の契約サイトへ直接ジャンプすることができる。
【００１９】
決済用銀行に新たに口座を開設しようとするユーザは、図４に示すメニュー画面において「口座開設」メニューを選択する。すると、決済サーバー１０は、ユーザの住所、氏名、電話番号、メールアドレス等の個人情報の入力欄を含む口座開設申込画面をユーザ端末１４へ送信する。ユーザ端末１４において口座開設申込画面に入力された個人情報が決済サーバー１０に返送されてくると、決済サーバー１０は、申込者であるユーザに固有のユーザＩＤおよびパスワードを発行してユーザ端末１４へ送信すると共に、ホストコンピュータ１８へ申込者名義の口座を新規に開設すべき旨の指示情報を送信する。ホストコンピュータ１８は、この指示情報に応じて口座開設処理を完了すると、開設した口座の口座番号を決済サーバー１０へ通知する。この通知を受けた決済サーバー１０は、ユーザＩＤ、パスワード、および口座番号を通知するための通知画面をユーザ端末１４へ送信すると共に、顧客データベース２０に、ユーザＩＤ、パスワード、個人情報、口座番号、および現在口座残高（０円）を記録する。なお、ユーザの身分確認のため、ユーザの身分証明書のコピーを決済サーバー１０の運営会社または決済用銀行へ送付してもらい、身分確認を行ったうえで、口座開設を行うようにしてもよい。
【００２０】
決済用銀行に口座を開設したユーザ（すなわち登録ユーザ）は、上記のメニュー画面で「パスワード変更」メニューを選択することにより、パスワードを自由に変更することができる。
【００２１】
また、登録ユーザは、メニュー画面で「ソフトダウンロード」メニューを選択することにより、決済サーバー１０を利用した代金決済に必要な暗号化コードを発生する暗号化プログラムをダウンロードすることができる。この暗号化プログラムは、商品の購入注文日、商品名、および購入価格を入力データとし、プログラム内に埋め込まれた暗号化キーで入力データを暗号化して暗号化コードを生成する。ただし、暗号化プログラムへの入力データはこれらに限るものではなく、購入数量や購入注文先のサイト名等を入力データに含めてもよい。
【００２２】
なお、本実施形態では、暗号化キーおよび復号キーとして同じキーを用いる共通鍵方式で暗号化を行うものとしたが、暗号化キーと復号キーとが異なっていてもよい。また、暗号化処理には、各種の公知の暗号化アルゴリズムを用いることができる。
【００２３】
決済サーバー１０は、メニュー画面にて「ソフトダウンロード」メニューが選択されると、ユーザ端末１４に対してユーザＩＤおよびパスワードの入力を求めてユーザ認証を行ったうえで、当該ユーザに固有の暗号化キーを生成する。そして、生成した暗号化キーを暗号化プログラムに埋め込んでユーザ端末１４へ送信すると共に、この暗号化キーを暗号復号キーとして当該ユーザのユーザＩＤに関係付けて顧客データベース２０に記録する。なお、暗号化プログラムのダウンロードは、口座開設申込時に自動的に行われるようにしてもよい。
【００２４】
次に、登録ユーザが販売者サーバー１２にアクセスして商品の購入注文を行ってから、決済サーバー１０を介して代金決済が完了するまでの処理の流れを説明する。なお、登録ユーザは、予め、決済用銀行の自分の口座に適宜な額の資金を入金しておくものとする。決済用銀行の口座に入金されると、入金額および口座番号がホストコンピュータ１８から決済サーバー１０へ通知される。決済サーバー１０では、通知された口座番号に該当するユーザＩＤを特定し、顧客データベース２０において、このユーザＩＤに関係付けられた現在口座残高に入金額を加算する。
【００２５】
登録ユーザは、ユーザ端末１４から販売者サーバー１２にアクセスして商品の購入注文を行うと、暗号化プログラムを起動して、購入注文日、商品名、および購入価格を入力する。暗号化プログラムは、これらの入力データから、プログラム内に埋め込まれた暗号化キーを用いて暗号化コードを生成する。
【００２６】
登録ユーザは、販売者サーバー１２での購入注文に係わる取引番号（この取引番号は購入注文時に販売者サーバー１２から通知される）、および、上記の暗号化コードを販売者サーバー１２へ送信する。具体的には、例えば、販売者サーバー１２にアクセスしたユーザ端末１４において購入注文操作を行うと、ユーザＩＤおよび暗号化コードを入力するための入力画面が販売者サーバー１２からユーザ端末１４へ送信されてくる。この時点で、暗号化プログラムを起動して暗号化コードを生成し、上記入力画面にユーザＩＤ、取引番号、および暗号化コードを入力することによって、これらのデータが販売者サーバー１２へ送信される。
【００２７】
これと共に、登録ユーザは、生成された暗号化コードをユーザＩＤと共に決済サーバー１０へ送信する。具体的には、例えば、ユーザ端末１４から決済サーバー１０へアクセスし、メニュー画面で「購入コード送信」メニューを選択すると、暗号化コードを入力するための入力画面が決済サーバー１０からユーザ端末１４へ送信されてくる。この入力画面にユーザＩＤおよび暗号化コードを入力することで、ユーザＩＤおよび暗号化コードが決済サーバー１０へ送信される。
【００２８】
なお、ユーザ端末１４から販売者サーバー１２および決済サーバー１０への暗号化コード等の送信を、電子メールその他の手段によって行うこととしてもよい。また、暗号化プログラムに通信機能を持たせることにより、または、暗号化プログラムを既存のブラウザプログラムへのプラグインプログラムとして構成することにより、販売者サーバー１２へアクセスして購入注文を行ってから、暗号化コードを生成し、決済サーバー１０および販売者サーバー１２へ暗号化コードを送信するまでの一連の処理を自動的に行えるようにしてもよい。
【００２９】
販売者サーバー１２は、ユーザ端末１４から取引番号および暗号化コードが送信されてくると、販売データを参照すること等により、その取引番号で特定される売買取引における販売価格を取得する。そして、取得した販売価格、および送信されてきた暗号化コードを、自身の販売者ＩＤと共に決済サーバー１０へ送信する。
【００３０】
決済サーバー１０は、ユーザ端末１４からユーザＩＤおよび暗号化コードが送信されてくると、図５に示すように、この暗号化コードを購入者側コードとして、ユーザＩＤに関係付けてコード記録データベース２４に記録する。また、販売者サーバー１２から販売者ＩＤ、販売価格、および暗号化コードが送信されてくると、図６に示すように、この暗号化コードを販売者側コードとして、販売価格と共に販売者ＩＤに関係付けてコード記録データベース２４に記録する。そして、適宜なタイミングで（例えば毎日１回等）、コード記録データベース２４の記録内容に基づいて、代金決済処理を実行する。
【００３１】
以下、図７および図８に示すフローチャートを参照して、この代金決済処理の内容について説明する。
図７に示す如く、先ず、ステップ１００において、インデックスｉが「１」に初期化される。
【００３２】
次に、ステップ１０２において、コード記録データベース２４を参照して、ｉ番目の販売者側コードＳiに一致する購入者側コードＰjが記録されているか否かが判別される。その結果、販売者側コードＳiに一致する購入者側コードＰjが記録されていれば、ステップ１０４の処理が実行される。一方、記録されていなければ、図８に示すステップ１０６において、インデックスｉがインクリメントされ、続くステップ１０８において、ｉ番目の販売者側コードＳiが記録されていることが確認されたうえで、再びステップ１０２の処理が実行される。
【００３３】
ステップ１０４では、コード記録データベース２４から購入者側コードＰjに関係付けられたユーザＩＤ（すなわち購入者のユーザＩＤ）が読み出され、顧客データベース２０から、このユーザＩＤに関係付けられた復号キーＣjが読み出される。そして、続くステップ１１０において、復号キーＣjを用いて、購入者側コードＰjから購入注文日、商品名、および購入価格が復号される。
【００３４】
ステップ１１２では、コード記録データベースを参照して、販売者側コードＳiに関係付けられた販売価格と、復号された購入価格とが一致するか否かが判別される。その結果、一致しなければ、購入者から通知された購入価格と、販売者から通知された販売価格とが一致しないこととなり、ステップ１１４において、価格の不一致により売買取引は成立しない旨が、該当するユーザ端末１４および販売者サーバー１２へ電子メール等により通知される。そして、図８に示すステップ１１５において、購入者側コードＰjおよび販売者側コードＳiがコード記録データベース２４から削除された後、上記ステップ１０６の処理が実行される。一方、復号された購入価格が販売者側コードＰjに関係付けられた販売価格に一致すれば、次にステップ１１６の処理が実行される。
【００３５】
ステップ１１６では、顧客データベース２０を参照して、購入者のユーザＩＤに関係付けられた口座番号および現在口座残高が読み出される。
【００３６】
ステップ１１８では、上記ステップ１１６で読み出された口座残高が決済金額、すなわち、購入者側コードＰjから復号された購入価格（決済サーバー１０において購入者側から手数料を徴収する場合には、購入価格に手数料を加えた額）以上であるか否かが判別される。その結果、現在口座残高が決済金額に満たない場合はステップ１２０の処理が実行され、一方、現在口座残高が決済金額以上である場合にはステップ１２２の処理が実行される。
【００３７】
ステップ１２０では、購入者（つまり購入者側コードＰjの送信者）のユーザ端末１４および販売者（つまり販売者側コードＳiの送信者）の販売者サーバー１２に、購入者の残高不足により代金決済を行えない旨が例えば電子メールにより通知された後、ステップ１１６において、購入者側コードＰjおよび販売者側コードＳiが削除される。
【００３８】
ステップ１２２では、販売者データベース２２を参照して、販売者ＩＤに関係付けられた口座番号（販売者側口座番号）が読み出される。
【００３９】
ステップ１２４では、ホストコンピュータ１８に対して、ステップ１１６で読み出した購入者口座番号の口座から決済金額を引き落とし、その引き落とし額から手数料分を差し引いた金額をステップ１２２で読み出した販売者口座番号の口座へ入金すべき旨の振替指示情報が送信される。ホストコンピュータ１８は、送信されてきた送金指示情報に基づいて、例えば所定の期日（例えば毎月末）に振替処理を実行する。なお、購入者の口座からの引き落とし額から差し引かれた手数料は、決済サーバー１０の運営会社の口座へ入金される。ステップ１２４の処理が終了すると、次に図８に示すステップ１２６の処理が実行される。
【００４０】
ステップ１２６では、販売者サーバー１２宛に、ステップ１１０で復号された取引番号の商品売買取引について、購入者の口座からの入金が確実に行われる旨の情報が送信される。販売者サーバー１２の運営者は、この情報を受信したうえで商品発送を行うことにより、未入金等のトラブルを防止することが可能となる。
【００４１】
ステップ１２８では、顧客データベース２０において、購入者のユーザＩＤに関係付けられた現在口座残高から決済金額が差し引かれると共に、ステップ１１０で復号された購入注文日、商品名、および購入価格、並びに、決済金額が差し引かれた後の口座残高が購入情報として記録される。
【００４２】
本ステップ１２８の処理が終了すると、次に上記したステップ１１５において、コード記録データベース２４から販売者側コードＳiおよび購入者側コードＰiが削除された後、ステップ１０６においてインデックスｉの値がインクリメントされ、更に、ステップ１０８においてｉ番目の販売者側コードがコード記録データベース２４に記録されていることが確認されたうえで再び図７に示す上記ステップ１０２の処理が実行される。
【００４３】
次に、購入者が購入履歴を閲覧する場合の処理について説明する。購入履歴を閲覧しようとする登録ユーザはユーザ端末１４から決済サーバー１０にアクセスし、上記したメニュー画面において、「購入履歴閲覧」メニューを選択する。これに応答して、決済サーバー１０は、ユーザＩＤおよびパスワードを入力するための入力画面をユーザ端末１４へ送信する。そして、ユーザ端末１４から返送されてきたユーザＩＤおよびパスワードに基づいて認証を行ったうえで、顧客データベース２０から当該ユーザＩＤに関係付けられて記録された購入情報および現在口座残高を読み出し、この購入情報を一覧表示した購入履歴一覧画面を生成してユーザ端末１４へ送信する。これにより、登録ユーザは、ユーザ端末１４の画面で自らの購入履歴および口座残高の推移を確認することができる。すなわち、登録ユーザは決済サーバー１０を購入記録メモおよび通帳代わりに用いることができる。
【００４４】
以上説明したように、本実施形態のシステムによれば、決済サーバー１０では、購入者から送信されてきた暗号化コード（購入者側コード）と販売者から送信されてきた暗号化コード（販売者側コード）とが互いに一致する場合にのみ、購入者の口座から代金を引き落とすようにしたので、売買取引の成立を確認したうえでの安全・確実な代金決済が可能となる。また、購入者が通知した購入価格と販売者側が通知した販売価格とが一致しない場合には、決済が行われず、売買取引は成立しないので、購入注文時の価格と異なる不当な価格で決済が行われるのを防止することもできる。
【００４５】
さらに、暗号化コードは暗号化プログラムにより購入者が発生するので、購入者のクレジットカード番号を用いることが不要となり、購入者側はセキュリティ上の不安を感ずることなく、安心して代金決済を行うことができる。そのうえ、クレジットカード番号の入力が不要となることで、クレジットカードを所有できないユーザも本実施形態の決済サーバー１０を利用してインターネット上で決済を行うことができる。すなわち、本実施形態によれば、インターネット上で決済を行うユーザ層が格段に拡大されることとなり、インターネットを利用した商取引の活発化を促進することが可能となる。
【００４６】
また、本実施形態では、暗号化プログラムを各登録ユーザに固有の暗号化キーで暗号化を行うように構成すると共に、顧客データベース２０には各ユーザＩＤに関係付けてその暗号化キーを記録しておき、決済サーバー１０では、各登録ユーザから送信されてきた購入者側コードを、その送信者であるユーザに固有の暗号化キーで復号する。このため、万一、他人が購入者になりすまして購入者側コードを送信した場合にも、決済サーバー１０では購入者側コードを復号できず、したがって、その後の決済処理が進められることはない。このように、本実施形態のシステムは、他人が購入者になりすまして暗号化コードを送信することに対しても高い安全性を備えている。
【００４７】
さらに、決済用銀行に設けた口座の残高が不足する場合には、代金決済が行われないため、購入者は、万一、不測の事態が生じても、口座残高を超えて損失を受けることがないという安心感を持つこともできる。
【００４８】
一方、販売者側にとっても、購入者からの入金が確実であることを確認したうえで商品の発送を行えるので、購入者から入金されないといったトラブルを防止できるという利益がある。
【００４９】
また、登録ユーザは、決済サーバー１０にアクセスした際に表示されるメニュー画面において、販売者サイトへのジャンプ、購入代金決済の依頼（購入者側コードの送信）、購入履歴の閲覧、パスワードの変更等の商品購入および決済に係わる一連の手続きを行うことができる。すなわち決済サーバー１０は電子決済についてのポータルサイト的な機能を有することとなり、インターネット上で商品購入を行うユーザにとって便宜性の高いＷＥＢサイトを実現することができる。
【００５０】
なお、上記実施形態では、販売者サーバー１２が電子商店のＷＥＢサーバーとして機能し、電子商店での売買に係わる代金決済を決済サーバー１０を利用して行うものとして説明した。しかしながら、本発明はこれに限定されるものではなく、インターネット上でのオークション等の個人間売買の代金決済を行う場合にも適用が可能である。すなわち、オークションにおける販売者について、上記実施形態における契約サイトと同様に、販売者ＩＤおよび入金用口座番号を販売者データベース２２に登録しておき、オークションの落札者（購入者）は暗号化プログラムにより発生した暗号化コードを決済サーバー１０および販売者のユーザ端末１４へ送信し、販売者がこの暗号化コードを決済サーバー１０へ送信するようにすることで、決済サーバー１０において上記実施形態と同様の決済処理を行うことができる。
【００５１】
また、上記実施形態では、購入者のユーザ端末１４から決済サーバー１０へ送信される暗号化コード（購入者側コード）と販売者サーバー１２へ送信される暗号化コード（販売者側コード）とが一致するものとしたが、本発明はこれに限定されるものではなく、これら２つの暗号化コードが一定の対応関係を有するようにしてもよい。すなわち、例えば、購入者側コードとして生成した暗号化コードを所定の規則で変換して得られたコードを、販売者側コードとして販売者サーバー１２へ送信することとしてもよい。この場合、決済サーバーでは、購入者側コードと販売者側コードとが一致するか否かの判断に代えて、両コードが上記対応関係を有するか否かを判断するようにすればよい。
【００５２】
【発明の効果】
本発明によれば、購入者側から送信されてきた第１の暗号化コードと、販売者側から送信されてきた第２の暗号化コードとが所定の対応関係を有する場合にのみ、購入者の口座から代金を引き落とすようにしたので、クレジットカード番号を用いることなく、売買取引の成立を確認したうえでの安全・確実なネットワーク上での代金決済を、実現することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態を示すネットワーク全体構成図である。
【図２】顧客データベースのデータ構成を示す図である。
【図３】販売者データベースのデータ構成を示す図である。
【図４】決済サーバーから送信されるメニュー画面を示す図である。
【図５】コード記録データベースへの記録データ（購入者側）の一例を示す図である。
【図６】コード記録データベースへの記録データ（販売者側）の一例を示す図である。
【図７】決済サーバーが実行する代金決済処理の内容を表すフローチャート（その１）である。
【図８】決済サーバーが実行する代金決済処理の内容を表すフローチャート（その２）である。
【符号の説明】
１０ 決済サーバー
１２ 販売者サーバー
１４ ユーザ端末
１６ インターネット
２０ 顧客データベース
２２ 販売者データベース
２４ コード記録データベース

Claims (3)

1. ユーザ端末と販売者サーバと決済サーバからなる電子決済システムであって、
   前記ユーザ端末は、
   ユーザから入力を受けた購入価格を含む取引情報を決済サーバから受け取った暗号化キーにより暗号化し、暗号化コードを生成する暗号生成手段と、
   前記暗号化手段で生成された暗号化コードをユーザIDおよび購入注文時に販売者サーバから通知された取引番号とともに販売者サーバに送信する第一送信手段と、
   前記暗号化コードおよび前記ユーザIDを決済サーバに送信する第二送信手段とを有し、
   前記販売者サーバは、
   前記ユーザ端末から受信した暗号化コード、販売者ID、および、前記ユーザ端末から受信した取引番号で特定される取引における販売価格を決済サーバに送信する第三送信手段を有し、
   決済サーバは、
   各ユーザのユーザIDと、暗号復号キーとが記録されたデータベースと、
   前記ユーザ端末から受信したユーザIDに関係付けられて前記データベースに記録された暗号復号キーを用いて前記暗号化コードを復号する復号処理手段と、
   前記ユーザ端末から受信した暗号化コードと前記販売者サーバから受信した暗号化コードとが所定の対応関係を有するかを判定する判定手段と、
   前記判定手段において、対応関係を有すると判定され、かつ、前記ユーザ端末から受信した暗号化コードを前記復号処理手段により復号して得られた購入価格と、前記販売者サーバから受信した販売価格とが一致する場合にのみ、代金の決済処理を実行する決済処理手段とを有することを特徴とする電子決済システム。
2. ネットワーク上で行われた売買取引についての代金決済を行う方法であって、
   前記ユーザ端末が、
   ユーザから入力を受けた購入価格を含む取引情報を決済サーバから受け取った暗号化キーにより暗号化し、暗号化コードを生成する暗号生成ステップと、
   前記暗号化手段で生成された暗号化コードをユーザIDおよび購入注文時に販売者サーバから通知された取引番号とともに販売者サーバに送信する第一送信ステップと、
   前記暗号化コードおよび前記ユーザIDを決済サーバに送信する第二送信ステップとを実行し、
   前記販売者サーバが、
   前記ユーザ端末から受信した暗号化コード、販売者ID、および、前記ユーザ端末から受信した取引番号で特定される取引における販売価格を決済サーバに送信する第三送信ステップを実行し、
   決済サーバが、
   前記ユーザ端末から受信したユーザIDに基づいて、ユーザIDと暗号復号キーとが記録されたデータベースを参照し、暗号復号キーを用いて前記暗号化コードを復号する復号処理ステップと、
   前記ユーザ端末から受信した暗号化コードと前記販売者サーバから受信した暗号化コードとが所定の対応関係を有するかを判定する判定ステップと、
   前記判定ステップにおいて、対応関係を有すると判定され、かつ、前記ユーザ端末から受信した暗号化コードを前記復号処理ステップで復号して得られた購入価格と、前記販売者サーバから受信した販売価格とが一致する場合にのみ、代金の決済処理を行なう決済処理ステップとを実行することを特徴とする代金決済方法。
3. ユーザ端末と販売者サーバとネットワーク上で接続された決済サーバであって、
   前記ユーザ端末から、取引毎に入力された当該取引における購入価格を含む取引情報を暗号化した暗号化コードとユーザIDを受信する第一受信手段と、
   前記販売者サーバから暗号化コード、販売者IDおよび販売価格を受信する第二受信手段と、
   前記ユーザ端末から受信したユーザIDに基づいて、ユーザIDと暗号復号キーとが記録されたデータベースを参照し、暗号復号キーを用いて前記暗号化コードを復号する復号処理手段と、
   前記ユーザ端末から受信した暗号化コードと前記販売者サーバから受信した暗号化コードとが所定の対応関係を有するかを判定する判定手段と、
   前記判定手段において、対応関係を有すると判定され、かつ、前記ユーザ端末から受信した暗号化コードを前記復号処理手段により復号して得られた購入価格と、前記販売者サーバから受信した販売価格とが一致する場合にのみ、代金の決済処理を実行する決済処理手段とを有することを特徴とする決済サーバ。

Images