JP4237943B2 - 電子取引においてセキュリティを改善する方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、電子商取引を処理する際のセキュリティを改善する方法に関する。より詳細には本発明は、インターネットなどの安全でないネットワークで営業する信用あるブローカが、より安全な支払機構を提供できるようにするフレームワークを定義する。
【０００２】
【従来の技術】
電子商取引は、品目の電子的交換に基づき、典型的交換の１つに、電子支払があるが、これはデジタルで署名された契約でもよい。品目の交換において、セキュリティに対する重要な一要件は公正性である。取引終了時に、どちらの当事者も自分が期待した品目を受取るか、どちらの当事者もそれを受取らないか、または受け取った品目が期待に合わない場合に、解決を求めて第三者に提出することができる法的拘束力のある取引のレシートをそれぞれの当事者が得る場合に、交換は公正である。現在、そのような商取引は通常、ユーザと商人の間で直接行われ（もちろん支払を得る際には、銀行が仲介し）、インターネット上の直接的ポイント・ツー・ポイント・コンタクトになる。電子商取引の文脈において取引または交換は、安全でないネットワークを介して実行される可能性がある。残念ながらハッカが、プロトコルおよびアプリケーションの弱みにつけこむこと、または他の当事者に使用されているシステムを改竄することが可能である。したがって、電子商取引の取引においてセキュリティの保証を助けるために、注意深く設計された交換プロトコルが使用される。１９９４年にNetscapeによって導入されたSecure Socket Layerまたは「ＳＳＬ」安全通信プロトコルは、そのようなプロトコルの一例である。このプロトコルは、ユーザと商人の間など、ウェブ・ブラウザとサーバの間の暗号化および認証を提供し、利用するための処理パワーをほとんど必要としないことを特徴とする。ＳＳＬは、インターネットを介して暗号化されたクレジット・カード番号を送るために一般的に使用される。かなりより大きなコンピューティング・パワーを必要とする、非常により安全な支払プロトコルが、Mastercard、ＶＩＳＡ等により１９９６年２月に導入された（１９９６年６月にアップグレードされた）。このプロトコルは、Secure Electronic Transactionまたは「ＳＥＴ」として知られている。その目的は、情報の機密性を提供すること、支払の整合性を保証すること、ならびに商人およびカード保有者双方を認証することである。ＳＥＴプロトコルを実施するための現在のコンピューティング要件のため、このプロトコルは、買い物客／ユーザが自分のブラウザから直接稼働するプロトコルとして不適切である。もしそのようなものがユーザに使用されたら、例えばアプレットをダウンロードする際に、ダウンロード時間および性能損失が、許容不能な水準に増大する可能性が高い。
【０００３】
さらに、ユーザが何らかの公正な交換機構を有しない限り、ユーザはこの商人、すなわち、このユーザと取引したことがない可能性があり、この商人自身からしか情報を得ることができない実体、を信頼しなければならない。商人のサーバの自己証明に対する正当な理由のある不信（例えば、商人の詐欺の恐れ）は、電子商取引の成長および許容可能性を制限することになる。したがって、支払機能を実行するために、諸組織がＳＥＴプロトコルを使用するときでさえ、ユーザの匿名性の欠如は一欠点である。
【０００４】
従来技術は、セキュリティを改善する様々な企てを記載している。これらの解決の企ては、（１）通常、中立者によってしかるべく登録された、信用あるオンラインの第三者を利用する第三者プロトコル、および（２）公正な交換を得る確実性が、数回の通信を介して徐々に向上するゆるやかな交換プロトコル、という２つのカテゴリに分かれる。一般的な商業用語において、この後者のプロトコルは、交換に関与する当事者間の「取引経過」と共通点がある。信用ある第三者のアプローチでは、信用ある第三者を管理する組織が、いくつかの要件に従わなければならない。例えば、信用ある第三者は、（１）最低限の財務基準を満たすこと、（２）詐欺に対する保険を有すること、および（３）社会的に信用があること、を必要とされる可能性がある。これらの要件に対する適切な順守および実施は、ユーザから信用ある第三者に開示された情報が、安全な方法で処理されることを保証する。
【０００５】
これら２つの従来技術の解決には欠点がある。例えば、この第三者の方法には、単一の信用ある第三者が、多数の幅広い様々な取引において、しかるべく役割を果たすよう求められる可能性があるという事実のため、この第三者がボトルネックになる危険がある。
【０００６】
代替の公正交換プロトコルは、紛争の場合などの例外的情況において、第三者のサーバの使用を要する。例えば両当事者は、交換する品目、および例外の場合にどの第三者を使用するか、を合意する。これは、第三者の使用に対する楽観的アプローチとして知られている。危険を取る当事者（組成者）だけが、（顧客が購入した商品に不満があるということで）第三者に訴えることができる。商人もまた同様に（例えば、不正な小切手に関して）訴えることができる。したがってこの方法は、信用ある第三者がボトルネックになる従来の危険を克服する助けとなるが、他方の当事者の償還請求権を制限する。他のアプローチは、危険を取る当事者が第三者に訴えなくても、他方の当事者が取引を解決できることを保証する全体的期限のパラメータを使用して来た。
【０００７】
様々な程度の効果を有するその他の方法が開発されて来た。ほとんどどれも、充分な効果が不足するか、匿名性を可能にしないか、あるいは関与する当事者側で相当な処理時間または処理パワーを必要とする。
【０００８】
【発明が解決しようとする課題】
したがって必要とされることは、過度のプロセッサ時間を必要とせず、ユーザのハードウェア要件を増大させない（公正交換およびユーザの匿名性の両方を有する）電子交換のセキュリティを改善する方法である。
【０００９】
【課題を解決するための手段】
安全でないネットワークにおいてデータ・セキュリティを改善する、安全でないネットワークにおいて電子商取引を処理するコンピュータ化された方法が提供される。本方法は、信用ある第三者との取引関係を確立したユーザと商人、に対してその間で動作する。本方法は、（１）ユーザと信用ある第三者ブローカ、および（２）信用ある第三者ブローカと商人、の間のネットワーク・リンクを利用する。本方法はさらに、少なくとも部分的には、各ネットワーク・リンクにおいて利用可能と期待することができるコンピュータ・リソースに基づき選択されたプロトコルを利用する。本方法を適用すると、ユーザは、ＳＥＴに必要とされるコンピュータ・リソースより少ないリソースしか必要としないが、同時に、信用ある第三者ブローカによるＳＥＴプロトコルの使用を介して、許容可能なセキュリティ・レベルを維持するプロトコルを使用することができる。
【００１０】
本発明の機能において、このコンピュータ化された方法は、（ａ）ブローカ・サービスを要求するために、ユーザが、ブラウザおよびリソース低集約的プロトコルを用いて、信用ある第三者ブローカにアクセスすることを可能にするステップ、（ｂ）前記信用ある第三者ブローカが、ユーザの要求を満足させることができると前記ブローカが考える競合商品を提案する商人のウェブ・サーバから、情報を収集するステップ、（ｃ）前記ユーザが前記競合商品間の相違を比較し、前記競合商品間で選択することを可能にする対話型ウィンドウを、前記ブラウザが前記ユーザに提示するステップ、（ｄ）前記ユーザが、前記競合商品間で選択し、したがって商人を選択し、前記商人の利益のために、前記信用ある第三者ブローカを介して支払指図を発行するステップ、（ｅ）前記信用ある第三者ブローカが、高度に安全な支払プロトコルを用いて、前記商人に対する支払指図を送信し、したがって前記ユーザに代わって前記商人に支払うステップ、および（ｆ）前記商人と銀行が、例えばＳＥＴプロトコルを用いて連携し、前記商人が前記銀行から安全に支払いを受けることを可能にするステップ、を含む。
【００１１】
本発明の他の機能において、このコンピュータ化された方法は、このユーザへの支払い指図に対する支払い確認を可能にする追加的ステップを有する。
【００１２】
本発明の他の機能において、前記ブラウザはＪＡＶＡイネーブルであり、前記対話型ウィンドウはＣＧＩ技術を利用するアプレットである。
【００１３】
本発明の一目的は、公正交換のサポート、および前記商人に対する前記ユーザの匿名性を提供することである。
【００１４】
本発明の他の目的は、保険商品など、従来より電子的に市販できなかった商品において、電子商取引を可能にする効率的かつ安全な手段を提供することである。
【００１５】
本発明の他の目的は、パーソナル・デジタル・アシスタント（「ＰＤＡ」）、携帯電話、またはハンドヘルド・コンピュータのユーザが、そのような装置を使用して電子商取引をより安全に処理する手段を提供することである。
【００１６】
本発明の他の目的は、（所与の利用可能なコンピュータ・リソースで）最大のセキュリティを有する電子商取引の取引を、商業的に許容可能な期限内で可能にすることである。
【００１７】
【発明の実施の形態】
図１に示すように、安全でないネットワーク１２において処理される電子商取引のデータ・セキュリティを改善するコンピュータ化された方法１０が提供される。方法１０は、ユーザ側１６上、すなわちネットワーク・リンクのユーザまたは顧客１８が接続する側など、限定的コンピューティング・リソースを有するネットワーク・リンク１４（実線および破線で示されている）に特に適合する。
【００１８】
本発明の第１実施形態である保険の文脈において、方法１０は、保険を販売する商人２０ａ〜２０ｄと、保険証券の信用ある第三者ブローカ（「ＴＴＰ」）２２（すなわち、保険ブローカ）と取引関係を確立したユーザ１８に対してその間で動作する。取引関係は、少なくとも、ＴＴＰ２２により再指図される支払いをしているとユーザが気付く程度にはユーザ１８によって確立されている。ＴＴＰ２２は、保険証券などの商品またはサービスについての情報に対する要求を、インターネットなどの安全でないネットワーク１２上で受取り処理する、信用あるサーバである。方法１０は、（１）ユーザ１８とＴＴＰ２２の間のネットワーク・リンク１４に関連付けられた支払いと、（２）ＴＴＰと商人２０ａ〜２０ｄの間のネットワーク・リンク２４に関連付けられた支払い、の２つの部分に支払いを分けることにより、支払いのセキュリティ改善を達成する。方法１０は、少なくとも部分的には、各ネットワーク・リンク１４および２４において利用可能と期待することができるコンピュータ・リソースに基づいて選択されたプロトコルを利用する。
【００１９】
ユーザ１８とＴＴＰ２２の間のネットワーク・リンク１４のユーザ側１６に対するコンピューティング・リソースは、一般に限定的であるので、ＳＳＬプロトコルが使用される。ＳＳＬは、ユーザ１８の異常なコンピューティング・リソースを必要としない単純なプロトコルである。ユーザ１８は、さもなければＳＥＴプロトコルで使用可能な非支払い拒否機能を使用することはできないが、ユーザは、ＴＴＰ２２の信憑性を検証することによってセキュリティを確信することができ、したがってＴＴＰサーバに対する自分の信頼を増す。
【００２０】
ＴＴＰ２２と商人２０ａ、２０ｂ、２０ｃ、または２０ｄとの間のコンピューティング・リソースは、一般にユーザ側１６上で利用可能なリソースより大きいので、適切な商人サーバ、例えば商人２０ｄのサーバを介してユーザ支払いを指図し、商人サーバとその銀行２６の間の取引を安全にするために、ＳＥＴプロトコルが使用される。これは、彼または彼女の代わりにＴＴＰ２２によってなされた支払いが、非常に高いレベルのセキュリティでなされるということをユーザ１８に確信させる助けとなる。さらに取引がＴＴＰ２２を介してなされるので、ユーザ１８の識別を商人２０ｄに明らかにする必要がなく、したがって、取引をオブザーバに対して追跡不能にし、ユーザに対する支払い処理においても（商人に対して）匿名性を提供する。したがってＴＴＰ２２だけしか、ユーザ１８の識別を知る必要がない。
【００２１】
オブザーバに対するユーザ匿名性および追跡不能性という追加的セキュリティ機能は、他の文脈、すなわち採用調査の文脈において有利に利用される。この文脈においてＴＴＰ２２は、認可当局によって認可された採用サービスまたは管理職調査会社であり、商人２０ａ〜２０ｄは見込み雇用者である。匿名性および追跡不能性の機能は、雇用契約に署名するまでは多数の求職者ユーザ１８が匿名でいることを望む求職調査において有利である。上述の支払い指図を送るユーザ１８の処理は、経歴書または履歴書を見込み雇用者に送る求職者ユーザに類似する。求職者ユーザ１８は、ＳＳＬプロトコルを用い安全なチャネルを介してＴＴＰ２２に自分の経歴書を送る。経歴書は、自分の名前、住所、または現在の雇用場所など求職者ユーザ１８の識別情報を示さない。したがって、求職者ユーザ１８のいくつかの詳細の匿名性を維持しながら、３者間で交渉を行うことができる。次いでＴＴＰ２２は、雇用者と求職者ユーザ１８の要件を一致させる。一致が行われると、求職者ユーザ１８または雇用者すなわち「商人」２０ｄが、このサービスに対してＴＴＰ２２にＳＥＴ支払いを実行する。この場合、ＳＥＴ支払いがＴＴＰ２２になされることに留意されたい。これは、ユーザ１８がＴＴＰ２２を介して商人２０ｄに支払いを行う上述の保険の文脈の支払いとは異なる。
【００２２】
本発明の機能において、閲覧者がサーバの「信頼性」を検証できるようにする機構が追加され、したがって信用あるサーバであると主張するＴＴＰ２２のサーバが実際信用されることを検証する手段をユーザ１８に提供する。これは、特定のタイプの認可を受取るときに、一意な識別アイコン（図に示されていない）を表示することにより達成される。識別アイコンは、違反者を識別しアイコンの整合性を維持する責任のある認可当局に登録される。さらにＴＴＰ２２自体が、２次的な認可当局として役割を果たすことができる。ＴＴＰ２２は、違反者、すなわち以前に不正を行った商人２０ａ〜２０ｄ、およびユーザ１８、例えば紛争が解決された後に確立された合意を履行しなかった者、のリストを維持管理することにより、この２次的認可の役割を部分的に達成する。特定のユーザ１８（または採用調査の文脈の商人２０ｄ）が取引に関与するとき、ＴＴＰ２２は、ユーザ（または商人）の署名を認識し、次いで署名にアイコンで印を付け、したがって支払い者の匿名性を維持することができる。
【００２３】
図２に示すように、本発明の代替実施形態において、ＴＴＰ２２'は、ユーザ１８が直接かつ物理的にインタフェースするローカル・マシン２８内に常駐する。マシン２８は、サーバがＴＴＰ２２'として活動することを可能にするのに必要なデータおよびソフトウェアがロードされたサーバ３２を納めるハウジング３０、キーボード３６を含みサーバと通信するＸ端末３４、オプションで、銀行カードまたはＳＭＡＲＴ ＣＡＲＤ４４でなされた支払いを受け取り処理するカード・リーダ４２を有する現金自動預払機サブシステム（「ＡＴＭ」）４０および航空券リーダ４６、ならびにインターネットあるいは他の非専用または半専用ネットワーク１２にサーバを接続するネットワーク・デバイス４８を含む。このマシン２８は、空港の旅行保険機としての使用に特に応用可能であり、ここで商人は保険会社２０ａ'〜２０ｄ'であり、ＴＴＰ２２'は保険ブローカであり、商品は旅行保険証券である。保険証券もまた広くサービスと考えられていることに留意されたい。したがって、本明細書全体で使用される「商品」という用語は、「サービス」という用語と交換可能であり、限定的に解釈すべきではない。したがってこのマシン２８は、旅行者ユーザ１８が飛行機に乗り込む前に保険商品を購入することを可能にする。さらにその物理的特性のため、このマシン２８には、通行人の注意を引くために、標識５０などの物理的視覚装置を付けることができる。旅行者ユーザ１８は、マシン可読航空券５２をリーダ４６に挿入し、例えば、ＳＭＡＲＴＣＡＲＤ４４をＡＴＭ４０のリーダ４２に挿入することができる。ＡＴＭ４０は、航空券５２から便の詳細を読取り、マルチメディア・ブラウザを用いて、ユーザの便に対応する保険証券およびサービスのリストを提示する。マルチメディア・ブラウザ／対話型ユーザ・インタフェース１１０の一例が、自動車保険販売の文脈で図４に示されていることに留意されたい。旅行者ユーザ１８がそのような商品を購入すると決定すると、選択された保険商人２０ｄ'からのデジタルで署名されたステートメントがＳＭＡＲＴＣＡＲＤ４４に（または航空券５２だけを使用する場合にはＴＴＰ２２'に）格納され、保険商人に対する支払いがネットワーク１２を介して実行される。この閉じたシステムにおいてマシン２８を使用することは、Ｘ端末３４がブラウザ５４と対話する場合、ユーザ１８が、（１）たとえＸ端末入力またはブラウザとＴＴＰ２２'が同じマシン内にあっても、両者間で局所的にＳＳＬを利用し、ＴＴＰの使用を介して匿名を受け取ること、（２）ＴＴＰと選択された保険商人２０ｄ'の間でＳＥＴを利用すること、ができるので有利である。システムが閉じているように見えるときでも、ネットワーク・リンク１２または２４のいずれかの通信を攻撃するか、妨害することができるウィルスまたはスプライス（splice）をハッカが依然挿入することができたことに留意すべきであり、したがって、すべての処理間通信は暗号化される。さらにマシン２８はオプションで、旅行者ユーザ１８が空港でＴＴＰを介して航空券を閲覧し購入することを可能にするために利用することができる。この場合であれば、商人２０ａ'〜２０ｄ'は航空会社である。
【００２４】
（Ｘ端末３４などの）ユーザ・インタフェースおよびＴＴＰ２２'が同じ場所に配置される上述の実施形態では、（ＴＴＰがユーザ・インタフェースから離れている実施形態に比較すると）ユーザ１８の部分のある程度の匿名性は失われる。さらに、現地に備えられたいかなる視覚装置５０も、見ることはできず、したがってネットワーク１２内の遠隔地点からＴＴＰにアクセスするユーザには何の効果もない。しかしマシン２８の物理的位置に物理的にいるオブザーバに対して匿名性の利点は残っている。
【００２５】
次に図１および３を参照すると、本発明のコンピュータ化された方法は次の諸ステップを含む。
【００２６】
アクセスするステップ１００において本方法は、ユーザ１８が、好ましくはＪＡＶＡイネーブルのブラウザ１０２（図１に示す）およびＳＳＬなどのリソース低集約的な安全な通信プロトコル（すなわち、ＳＥＴより少ないコンピュータ・リソースを要求する安全な通信プロトコル）を用いて、ブローカ・サービスを要求するためにＴＴＰ２２にアクセスすることを可能にする（ＪＡＶＡは、Sun Microsystemsに登録された登録商標であり、インターネット１２などの分散環境において動作する小さいプログラム・オブジェクトを作成するために設計されたプログラム言語を識別する）。ＪＡＶＡプログラム言語が使用されるこのステップ１００において、ユーザのマシン上で稼働するＪＡＶＡアプレットは、ユーザの要求をＴＴＰ２２に送る（ＪＡＶＡアプレットは、通常ＪＡＶＡプログラム言語に構築される専用のアプリケーション・プログラムである）。ＷＩＮＤＯＷＳ（Microsoft Corporationの登録商標）と共に来るいくつかのビルトインの文書作成および描画アプレットもまた、ＪＡＶＡアプレットと共にまたはその代わりに使用することができる。さらに、他のインターネット技術が、これらの専用プログラムを代用することができるが、インターネット通信の標準化により、これらのプログラムを実際的に選択できる。
【００２７】
情報収集ステップ１０６において、ＴＴＰ２２は、ユーザ１８の要求を満足させることができるとＴＴＰが考える競合的商品を提案する商人２０ａ〜２０ｄのウェブ・サーバから情報を収集する。任意の収集処理を使用することができる。例えばＴＴＰ２２は、ＴＴＰがすべての商人についての情報を維持管理する自分自身のデータベースにアクセスすることができる。
【００２８】
比較ステップ１０８においてブラウザ１０２は、ユーザが、競争する商人２０ａ〜２０ｄによって提案される商品間の相違を比較し、競合する商品間で選択できるようにする対話型ウィンドウ、または図４および５にそれぞれ示されたアプレット１１０および１１２をユーザ１８に提示する。アプレット１１０により、ユーザ１８が、競争する商人２０ａ〜２０ｄによって提案される同様の商品間の相違を対照させ、彼または彼女の要件に最も適合するものを選択することが可能になる。アプレット１１２は、「支払い」機能１１４もまた提供する。これらの機能は、動的にＨＴＭＬページを作り出すための、インターネット上の動的内容に対するプロトコルであるCommon Gateway Interfaceまたは「ＣＧＩ」技術の使用を介して得られる。ＣＧＩ技術は、ユーザ１８がオンラインの間に、要求に応じてウェブ・ページを作成することを可能にし、そのようなページは、ボタン、チェックボックス、テキスト入力その他のユーザ入力からの情報に基づき作成される。これらのＣＧＩ動的作成ページは、インターネット１２を介して転送することができる、画像、音声、テキストおよび他のほとんど任意の視覚的または音声的仕組みを構成することができる。動的に作成されたそのようなページは、ハイパーテキストを介して他のウェブ・ページもまた参照することができる。ユーザ１８がこのハイパーテキスト上をクリックすることにより、特定の商人２０ａ〜２０ｄのサーバにソースのあるグラフィックを表示するアプレットを有するフレームを生成することができる。
【００２９】
選択ステップ１２０においてユーザ１８は、競合商品の間で選択し、したがって商人２０ｄを選択する。
【００３０】
第１の支払いステップ１３０において、ユーザ１８は、「支払い」機能１１４を活動化し、したがって支払い指図をＴＴＰ２２に発行する。「支払い」機能１１４は、対話型ウィンドウ・グラフィカル・インタフェースまたはアプレット１１２の一部である。ユーザのデリケートな金融情報を、ＴＴＰ２２の暗号化鍵を用いてＳＳＬプロトコルで暗号化してこのＴＴＰに送るユーザのマシン上で稼働するアプレット１１２を用いて支払いが実行される。ＴＴＰ２２は信用ある第３者なので、これは、ユーザに与えるセキュリティの危険を最低にすべきである。例えば支払い指図フォームは、ＣＧＩ技術を用いて作成し、それをアプレットとしてＴＴＰ２２に送ることができる。
【００３１】
第２の支払いステップ１４０において、ＴＴＰ２２は、支払い情報を復号化し、高度に安全な支払いプロトコルを用いて商人２０ｄに支払い指図を送信し、したがってユーザ１８に代わって商人に支払う。このクレジット・カード情報の送信は、選択された商品を提案する商人２０ｄのサーバに、トンネル１３４（図１に示す）を介して「トンネルを通過させる」ことが好ましい。「トンネルを通過させること」は、インターネット１２を専用の安全なネットワークの一部として使用することを可能にするさらに他のセキュリティ・プロトコルであり、したがって公衆回線を用いたインターネットを介して仮想専用ネットワークを作り出す。これは、公衆ネットワークの安全な使用を可能にすることによって、広域通信用のリース回線の必要をなくす助けとなる。取引のこの部分はＳＥＴプロトコルを用いることで行われる。
【００３２】
第３の支払いステップ１５０において、商人２０ｄおよび関連付けられた銀行２６は、再びＳＥＴプロトコルを用いて連携し、商人が銀行から支払いを受け取ることを可能にする。ＳＥＴ支払いを実行するために、ＴＴＰ２２は、ユーザのクレジット・カード情報を銀行の公開鍵で暗号化する。このように、商人２０ｄは、ユーザ１８についてのいかなる金融詳細も見ることができず、銀行２６だけがこの情報を復号化できる。さらにＴＴＰ２２は、商人２０ｄの商人認可（識別）を検証し、支払い指図に自分自身の認可を送る。この支払い指図は、商人の公開鍵で暗号化され、したがってネットワーク１２を介して平文で送られるメッセージはない。次いで商人２０ｄは、メッセージを復号化し、暗号化されたクレジット・カード情報を銀行２６に送る。銀行２６は、支払い指図を処理し、ユーザ１８の銀行口座上の残高が支払い可能である場合に限り、肯定的な支払い許可を発行する。
【００３３】
本発明の他の機能において、コンピュータ化された方法１０は、購入した商品の配達前に、支払い指図に対する支払い確認をユーザ１８に提供する追加ステップ１６０を含む。このステップにおいて、商人２０ｄは、支払いが正常であったかどうかを示すメッセージをＴＴＰ２２に戻す。次いでＴＴＰ２２は、この情報をユーザ１８に送信する。支払いが正常であるとき、このメッセージは、法的債務を証明するために使用することができる、すなわちこれを、購入のレシートと考えることができる。このレシートは、取引に関与するすべての当事者により署名されると、受け取ったサービスに関するユーザ１８の不満を解決する際に、証拠として使用することができ、したがって電子取引において公正交換を保証する助けとなる。次にＴＴＰ２２は、ブラウザ１０２を介して取引についての詳細な報告をユーザ１８に戻すことができる。
【００３４】
このアプリケーションの目的に対して、「高度に安全な支払いプロトコル」という記述句は、支払いを行う際のセキュリティのレベルが、ユーザ１８とＴＴＰ２２の間で支払い情報を送るために使用される通信プロトコルにより提供されるレベルより高い任意のプロトコルである。好ましい高度に安全な支払いプロトコルは、各参加者に認証を提供し、クレジット・カード情報など支払いのみの情報を処理するために特に設計されているＳＥＴプロトコルである。「リソース低集約的プロトコル」という記述句は、高度に安全な支払いプロトコルよりも少ないコンピュータ・リソースしか必要としない任意のプロトコルを指す。好ましいリソース低集約的プロトコルは、ＳＳＬプロトコルである。さらに、このアプリケーションの目的に対して、「安全」は、（１）誰もメッセージの内容を発見されずに変更することはできないという整合性、（２）受取人の実際のアドレスに含まれていない限り、メッセージの内容を誰も読取ることができないという機密性、をプロトコルが保証することを意味する。
【００３５】
方法１０は、３つの部分方法２００、３００、４００からなるアプリケーションを介して可能になり、そのそれぞれが、特定のネットワーク・リンク１４または２４の一端上で（すなわち、ＴＴＰ２２、ユーザ１８、または商人２０ａ〜２０ｄのいずれかの見地から）この方法の対話を制御する。
【００３６】
次に図６を参照すると、第１の部分方法２００は、ＴＴＰ２２とユーザ１８の間、およびＴＴＰと商人２０ａ〜２０ｄの間の対話を制御する。この第１の部分方法２００は、ＴＴＰ２２が、安全でないネットワーク１２上のユーザ１８とインタフェースしながら、ユーザとＴＴＰの間の通信セキュリティのレベルとは無関係に、安全な支払い機構を用いて閲覧、比較、購入する能力をユーザに提供できるようにする。この部分方法２００は、次の諸ステップを含む。ステップ２０２では、リソース低集約的な安全な通信プロトコルを用いて、ＴＴＰ２２が、関心のある商品に関する情報を求めるユーザ１８の要求を受け取る。ステップ２０４においてＴＴＰ２２は、要求された情報を商人２０ａ〜２０ｄから収集する。ステップ２０６において、ＴＴＰ２２は、この要求された情報を対話型ウィンドウ１１０を介してユーザ１８に送信する。ステップ２０８において、ユーザ１８は、商人２０ｄによって提案された商品を選択し、ＴＴＰ２２が受け取る支払い指図を生成する。ステップ２１０では、高度に安全な支払いプロトコルを用いて、ＴＴＰ２２が、選択された商人２０ｄに支払い指図を送信し、次いでこの商人は、それに対する支払いを受け取り、その後、支払い確認をＴＴＰに送信する。ステップ２１２においてＴＴＰ２２は、支払い確認をユーザ１８に送信する。
【００３７】
次に図７を参照すると、第２の部分方法３００は、ユーザ１８が、ユーザと商人の間の通信において利用可能なセキュリティ・レベルとは無関係に、安全な支払い機構を用いて、商人２０ａ〜２０ｄから提案された商品を閲覧、比較、購入することを可能にする。第２の部分方法３００は、次の諸ステップを含む。ステップ３０２において、ユーザ１８は、リソース低集約的な安全な通信プロトコルを使用して、商人２０ａ〜２０ｄから提案された関心のある商品に関する情報を求める要求をＴＴＰ２２に送信する。ＴＴＰ２２は、ＳＳＬプロトコルを用いて、対応する商人２０ａ〜２０ｄからのこの情報にアクセスする。ステップ３０４において、ユーザ１８は、ＴＴＰ２２によって構成された対話型ウィンドウ１１０（図４に示す）を介してそのような要求された情報を受け取る。ステップ３０６においてユーザ１８は、商人２０ｄによって提案された商品を選択し、支払い指図を作成し、この指図は、高度に安全な支払いプロトコルを用いてＴＴＰ２２により商人に送信される。選択された商人２０ｄは、支払い指図に対応する支払いを受け取る。ステップ３０８において、ユーザ１８は、選択された商人２０ｄまたはＴＴＰ２２からの支払い確認を待ち、受け取る。
【００３８】
次に図８を参照すると、第３の部分方法４００は、商人２０ｄが商品をフォーラムに提案できるようにし、このフォーラムの中では、ユーザ１８が、その商人の商品の機能と他の商人２０ａ〜２０ｃから提案された商品を閲覧、比較し、ユーザと商人の間の通信セキュリティとは無関係に、安全な支払い機構を用いてそのような商品を購入することができる。第３の部分方法４００は、次の諸ステップを含む。ステップ４０２において、商人２０ａ、２０ｂ、２０ｃ、２０ｄは、商品情報を求める要求をＴＴＰ２２から受け取る。ステップ４０４において、商人２０ａ、２０ｂ、２０ｃ、２０ｄは、ネットワーク１２経由で対話型ウィンドウ１１０（図４に示す）を介して商品情報をＴＴＰ２２に提供する。ステップ４０６では、高度に安全な支払いプロトコルを用いて、選択された商人２０ｄが、ＴＴＰ２２を介してユーザ１８から支払い指図を受け取る。ステップ４０８では、高度に安全な支払いプロトコルを用いて、商人２０ｄが支払い指図に対する支払いを得る。ステップ４１０において、商人２０ｄは、支払い受領の確認をＴＴＰ２２に送信し、ＴＴＰ２２は、ユーザ１８に確認を提供する。
【００３９】
本発明のコンピュータ化された方法は、ネットワーク回線１４および２４上の、商人２０ａ〜２０ｄのサーバ、ＴＴＰ２２のサーバ、ならびにユーザ１８のＰＣの上、中および間で動作するコンピュータ可読媒体内に符号化される。上述の部分方法２００、３００、４００は、ＰＣ、Ｘ端末３４のＣＰＵ、あるいはその関連付けられたサーバまたはホスト・コンピュータを制御するコンピュータ可読媒体内に符号化され、入力の受け取りを容易にする適切なインタフェースが生成され、出力が暗号化され、受取人が受け取ることのできる形態にリフォーマットされ、そのような形態で送信される。
【００４０】
本発明の一目的は、公正交換に対するサポートおよび選択された商人２０ｄに対するユーザ１８の匿名性を提供することである。
【００４１】
本発明の他の目的は、保険サービスなど従来より電子的に利用可能でなかった商品に対する電子商取引を可能にする効率的かつ安全な手段を提供することである。
【００４２】
本発明の他の目的は、パーソナル・デジタル・アシスタント（「ＰＤＡ」）などのハンドヘルド・デバイス、携帯電話、ポケット・コンピュータのユーザ１８が、より安全に電子商取引を処理するためにそのような装置を使用する手段を提供することである。ハンドヘルド・デバイスは一般に、ＳＥＴプロトコルを利用するには不充分な処理パワーしかないが、そのような装置の多くは、ＳＳＬプロトコルを有効に使用する充分な処理パワーを有するのでこれが可能となる。ＳＳＬプロトコルは、ＴＴＰ２２のサーバと接続するときには、充分なセキュリティを提供する。上述のように、ＳＥＴプロトコルを用いて、ＴＴＰ２２が支払いを含む取引の詳細を処理できるようにすることは、ＴＴＰがユーザ１８に対する代理人としてふるまうことを可能にし、したがって（ＳＳＬプロトコルを用いて、単に商人２０ａ〜２０ｄと直接接続されることと比較すると）取引を行う際のセキュリティをかなり改善する。したがって本発明の他の目的は、商業的に許容可能な期限内に（すなわち、関与する全ての本質的な当事者が、取引から正味の利益を実現するのに充分短く）、（所与のコンピュータ・リソースで）最大のセキュリティを有する電子商取引の取引を可能にすることである。
【００４３】
本明細書に述べた本発明の諸実施形態において、複数の変形形態および修正が可能である。本発明の特定の例示的実施形態を本明細書に示し述べて来たが、前述の開示には、広範囲の修正、変更、および代用を予期している。ある場合には、本発明のいくつかの機能を、他の機能を対応して使用することなく用いることができる。したがって、前記記述は、広く解釈し、図示および例示だけのために与えられており、本発明の精神および範囲は、付随の請求の範囲によってのみ限定されると理解されたい。
【００４４】
３つのセキュリティ概念、すなわち信用ある第三者、ならびにＳＳＬおよびＳＥＴプロトコルの概念、を統合する新奇で効果的な方法１０が述べられ、この方法は、ユーザ１８が高レベルのセキュリティおよび匿名性で閲覧、購入できるようにする一方、ユーザの最小セットのコンピュータ・リソースしか必要とせず、したがって、ユーザが、ＰＤＡ、携帯電話、またはポケット・コンピュータなど単純なハンドヘルド・デバイスを用いて電子商取引に参加できるようにする。そのような方法１０は、商業的な電子取引の文脈においてそのようなプロトコルを応用する、マシンまたはマシンで動作する処理に産業的に応用可能である。
【図面の簡単な説明】
【図１】 本発明の方法のブロック図である。
【図２】 旅行保険を販売する文脈に応用した、本発明の方法のブロック図である。
【図３】 本発明の方法の流れ図である。
【図４】 自動車保険を販売する文脈に応用した、本発明の方法の対話型ユーザ・インタフェースのレイアウト図である。
【図５】 本発明の方法において使用される第２の対話型ユーザ・インタフェースのレイアウト図である。
【図６】 本発明の３つの部分方法の流れ図である。
【図７】 本発明の３つの部分方法の流れ図である。
【図８】 本発明の３つの部分方法の流れ図である。

Claims (6)

1. ユーザの端末と、第三者のサーバと、商品の情報が格納された複数の商人のサーバと、銀行のサーバとがネットワークに接続され、前記ネットワーク上の前記ユーザの端末と、前記第三者のサーバが通信することで、前記ユーザの端末と前記複数の商人のサーバとの間の通信のセキュリティ・レベルに拘わらず、前記商人のサーバが提示する商品の閲覧、比較、購入を行う方法を、前記ユーザの端末に提供する方法であって、
   ａ．前記ユーザの端末が、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）プロトコルを用いて、前記商品の情報を閲覧する要求を、前記第三者のサーバへ送信して、前記第三者のサーバが、対話型ウィンドウを介して前記情報を比較できるインタフェースを前記ユーザの端末に送信するステップと、
   ｂ．前記第三者のサーバが、前記ＳＳＬプロトコルを用いて、前記ユーザの端末から要求された商品の情報を、これに関する情報が格納された複数の商人のサーバから、収集するステップと、
   ｃ．前記第三者のサーバが、前記収集した情報を、前記ＳＳＬプロトコルを用いて、前記対話型ウィンドウを介して前記ユーザの端末に提供するステップと、
   ｄ．前記ユーザの端末が、前記提供された情報から商品を選択して、前記第三者のサーバの暗号化鍵で暗号化された支払い指図を前記第三者のサーバに発行し、前記第三者のサーバが、前記ＳＳＬプロトコルを用いて、この選択した商品の前記支払い指図を前記ユーザの端末から受け取るステップと、
   ｅ．前記第三者のサーバが、過去に不正を行った商人を登録したリストに応じて、選択された商品の情報を送信した商人について認可するか否かを判定して、認可するとＳＥＴ（Ｓｅｃｕｒｅ Ｅｌｅｃｔｒｏｎｉｃ Ｔｒａｎｓａｃｔｉｏｎ）プロトコルを用いて、前記選択された商品の情報を送信した商人のサーバに、前記支払い指図を当該商人のサーバの公開鍵で暗号化して送信するとともに、クレジットカード情報を前記銀行のサーバの公開鍵で暗号化して送信し、次いで、前記選択された商品の情報を送信した商人のサーバが、前記ＳＥＴプロトコルを用いて、前記支払い指図及び前記暗号化されたクレジットカード情報を前記銀行のサーバに送信し、前記支払い指図に対する支払い情報を、前記銀行のサーバから受け取り、前記支払い情報に対する支払い確認を前記第三者のサーバに送信するステップと、
   ｆ．前記第三者のサーバが、前記支払い確認を、前記ＳＳＬプロトコルを用いて前記ユーザの端末に送信するステップと、
   を含む方法。
2. 前記ユーザの端末は、ＪＡＶＡイネーブルのブラウザを備え、前記対話型ウィンドウが、前記ブラウザの機能を使用したアプレットである、請求項１に記載の方法。
3. ユーザの端末と、第三者のサーバと、商品の情報が格納された複数の商人のサーバと、銀行のサーバとがネットワークに接続され、前記ネットワーク上の前記ユーザの端末と、前記複数の商人のサーバが通信を行うことにより、前記ユーザの端末と前記複数の商人のサーバとの間の通信のセキュリティ・レベルに拘わらず、前記商人のサーバにより提示された商品を、前記ユーザが閲覧、比較、購入できるようにする方法であって、
   ａ．前記ユーザの端末がＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）プロトコルを用いて、前記ユーザの関心がある商品に関する情報を求める要求を前記第三者のサーバに送信するステップと、
   ｂ．前記第三者のサーバが、前記情報を前記複数の商人のサーバから収集し、前記ユーザの端末に対話型ウィンドウを提示し、前記対話型ウィンドウを介して前記収集した情報を、前記ＳＳＬプロトコルを用いて、前記ユーザの端末が受け取るステップと、
   ｃ．前記情報から前記ユーザが商品を選択して、前記第三者のサーバの暗号化鍵で暗号化された支払い指図を前記第三者のサーバに発行すると、前記第三者のサーバが、過去に 不正を行った商人を登録したリストに応じて、選択された商品の情報を送信した商人について認可するか否かを判定して、認可すると当該選択された商品の情報を送信した商人のサーバに、ＳＥＴ（Ｓｅｃｕｒｅ Ｅｌｅｃｔｒｏｎｉｃ Ｔｒａｎｓａｃｔｉｏｎ）プロトコルを用いて、選択された商品の支払い指図を当該商人のサーバの公開鍵で暗号化して送信するとともに、クレジットカード情報を前記銀行のサーバの公開鍵で暗号化して送信し、次いで、前記選択された商品の情報を送信した商人のサーバが、前記ＳＥＴプロトコルを用いて、前記支払い指図及び前記暗号化されたクレジットカード情報を前記銀行のサーバに送信し、前記支払い指図に対する支払い情報を、前記ＳＥＴプロトコルを用いて、前記銀行のサーバから受け取るステップと、
   ｄ．前記選択された商品の情報を送信した商人のサーバは、前記第三者のサーバに、前記ＳＥＴプロトコルを用いて、前記ユーザの支払い確認を送信し、前記ユーザの端末が、この支払い確認を、前記ＳＳＬプロトコルを用いて、前記第三者のサーバから受け取るステップと、
   を含む方法。
4. 前記ユーザの端末は、ＪＡＶＡイネーブルのブラウザを備え、前記対話型ウィンドウが、前記ブラウザの機能を使用したアプレットである、請求項３に記載の方法。
5. ユーザの端末と、第三者のサーバと、商品の情報が格納された複数の商人のサーバと、銀行のサーバとがネットワークに接続され、前記ネットワーク上の前記ユーザの端末と、前記第三者のサーバが通信を行うことにより、前記ユーザの端末と前記商人のサーバとの間の通信のセキュリティに拘わらず、前記ユーザが、前記商人の商品と、他の商人のサーバにより提示された商品とを閲覧、比較し、前記商品を購入することができるフォーラムに、前記商人のサーバが商品を提示できるようにする方法であって、
   ａ．前記ユーザの端末から前記第三者のサーバに商品の情報を求める要求が、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）プロトコルを用いて送信され、前記商人のサーバが、前記商品の情報を求める要求を前記第三者のサーバから受け取るステップと、
   ｂ．前記商人のサーバが、前記商品の情報に対応した商品の情報を前記第三者のサーバに送信し、前記第三者のサーバが、対話型ウィンドウを介して前記ユーザの端末に、前記商品の情報を提供するステップと、
   ｃ．前記ユーザの端末が、前記提供された情報から商品を選択して、前記第三者のサーバの暗号化鍵で暗号化された支払い指図を前記第三者のサーバに発行した際、前記商人のサーバがＳＥＴ（Ｓｅｃｕｒｅ Ｅｌｅｃｔｒｏｎｉｃ Ｔｒａｎｓａｃｔｉｏｎ）プロトコルを用いて、前記第三者のサーバを介して前記ユーザの端末から前記支払い指図を受け取るステップと、
   ｄ．前記第三者のサーバが、過去に不正を行った商人を登録したリストに応じて、選択された商品の情報を送信した商人について認可するか否かを判定して、認可するとＳＥＴプロトコルを用いて、前記商人のサーバに前記支払い指図を当該商人のサーバの公開鍵で暗号化して送信するとともに、クレジットカード情報を前記銀行のサーバの公開鍵で暗号化して送信した際、前記商人のサーバが、前記ＳＥＴプロトコルを用いて、前記支払い指図及び前記暗号化されたクレジットカード情報を前記銀行のサーバに送信し、前記支払い指図に対する支払い情報を、前記銀行のサーバから受け取ステップと、
   ｅ．前記支払い情報を前記銀行のサーバから受け取った後に、前記商人のサーバが、支払いの受領確認を、前記ＳＥＴプロトコルを用いて、前記第三者のサーバに送信し、前記第三者のサーバが、前記ユーザの端末に、前記ＳＳＬプロトコルを用いて前記支払いの受領確認を送信するステップと、
   を含む方法。
6. 前記ユーザの端末は、ＪＡＶＡイネーブルのブラウザを備え、前記対話型ウィンドウが、前記ブラウザの機能を使用したアプレットである、請求項５に記載の方法。

Images