(57)【特許請求の範囲】
【請求項１】
ネットワーク上での支払取引を認証するためのコンピュータ実施の方法であって、
支払い認証サーバーで、メモリのプロフィルデータベースに、公開キーおよび秘密キーを含む公開キー基盤(PKI: public key infrastructure)キーペアに関連する前記公開キーを格納するステップと、
少なくとも前記公開キーを、少なくともメモリにおける買い手の第１支払い証券にリンクさせるステップと、
前記プロフィルデータベースから、少なくとも前記公開キーにリンクされると共に複数の支払い証券と複数の送り先住所を含む買い手プロフィルを読み取るステップと、
売り手の識別と前記支払取引の記述を含む電子認証リクエストを受信すると、前記ネットワークを介して前記買い手に関連する装置に前記支払取引の要約を含む電子チャレンジリクエストを送信するステップと、
前記買い手の装置から前記第１支払い証券の選択の電子指示を受信するステップと、
前記ネットワークを介して前記買い手の装置から前記支払取引のデジタル署名された要約を含む電子チャレンジ応答を受信すると、前記公開キーを用いて前記支払取引の前記デジタル署名された要約を解読するステップと、
前記解読から、前記買い手が前記秘密キーにアクセスできることと、前記買い手が前記第１支払い証券を使用することを承認されたことを判定するステップと、
前記ネットワークを介して前記買い手プロフィルからのデータを前記買い手の装置に送信するステップと、
前記支払取引のデジタル署名された記録をメモリの取引アーカイブに格納するステップと、
前記売り手に、前記買い手が前記第１支払い証券の使用を承認されたことを通知するステップと
を含む方法。
【請求項２】
前記電子認証リクエストは、前記買い手の装置から受信される請求項１記載の方法。
【請求項３】
前記秘密キーを含む前記ＰＫＩキーペアを生成するステップと、
前記ネットワークを介して前記買い手の装置に前記秘密キーを送信するステップと
をさらに含む請求項１記載の方法。
【請求項４】
前記支払取引の前記記録は、前記秘密キーを用いてデジタル署名された請求項３記載の方法。
【請求項５】
前記オンライン取引の前記記録は、ローカルな秘密キーを用いてデジタル署名された請求項１記載の方法。
【請求項６】
前記公開キーは、該公開キーが前記買い手に結び付けられていることを表すデジタル証明書の形式で格納される請求項１記載の方法。
【請求項７】
前記ネットワークを介して前記買い手の装置から、前記複数の支払い証券のうちの一つと前記複数の送り先住所のうちの一つの選択の電子指示を受信するステップ
をさらに含む請求項１記載の方法。
【請求項８】
支払いゲートウェイを介して前記支払取引を処理するステップをさらに含む請求項１記載の方法。
【請求項９】
プロセッサによって実行されると、前記プロセッサに、ネットワークを介して支払取引を認証するための方法を実行させる命令を含むコンピュータ読み取り可能な記録媒体であって、
前記方法が、
支払い認証サーバーで、メモリのプロフィルデータベースに、公開キーおよび秘密キーを含む公開キー基盤(PKI: public key infrastructure)キーペアに関連する前記公開キーを格納するステップと、
少なくとも前記公開キーを少なくとも買い手の第１支払い証券にリンクさせる買い手プロフィルをメモリに格納するステップと、
前記プロフィルデータベースから、少なくとも前記公開キーにリンクされると共に複数の支払い証券と複数の送り先住所を含む買い手プロフィルを読み取るステップと、
売り手の識別と前記支払取引の記述を含む電子認証リクエストを受信すると、前記ネットワークを介して前記買い手に関連する装置に前記支払取引の要約を含む電子チャレンジリクエストを送信するステップと、
前記買い手の装置から前記第１支払い証券の選択の電子指示を受信するステップと、
前記ネットワークを介して前記買い手の装置から前記支払取引のデジタル署名された要約を含む電子チャレンジ応答を受信すると、前記公開キーを用いて前記支払取引の前記デジタル署名された要約を解読するステップと、
前記解読から、前記買い手が前記秘密キーにアクセスできることと、前記買い手が前記第１支払い証券を使用することを承認されたことを判定するステップと、
前記ネットワークを介して前記買い手プロフィルからのデータを前記買い手の装置に送信するステップと、
前記支払取引のデジタル署名された記録をメモリの取引アーカイブに格納するステップと、
前記売り手に、前記買い手が前記第１支払い証券の使用を承認されたことを通知するステップと
を含む、コンピュータ読み取り可能な記録媒体。
【請求項１０】
前記電子認証リクエストは、前記買い手の装置から受信された請求項９記載のコンピュータ読み取り可能な記録媒体。
【請求項１１】
前記命令により特定される前記方法は、
前記秘密キーを含む前記ＰＫＩキーペアを生成するステップと、
前記ネットワークを介して前記買い手の装置に前記秘密キーを送信するステップ
をさらに含む請求項９記載のコンピュータ読み取り可能な記録媒体。
【請求項１２】
前記支払取引の前記記録は、前記秘密キーを用いてデジタル署名された請求項１１記載のコンピュータ読み取り可能な記録媒体。
【請求項１３】
前記オンライン取引の前記記録は、ローカルな秘密キーを用いてデジタル署名された請求項９記載のコンピュータ読み取り可能な記録媒体。
【請求項１４】
前記公開キーは、該公開キーが前記買い手に結び付けられていることを表すデジタル証明書の形式で格納される請求項９記載のコンピュータ読み取り可能な記録媒体。
【請求項１５】
前記命令により特定される前記方法は、
前記ネットワークを介して前記買い手の装置から、前記複数の支払い証券のうちの一つと前記複数の送り先住所のうちの一つの選択の電子指示を受信するステップ
をさらに含む請求項９記載のコンピュータ読み取り可能な記録媒体。
【請求項１６】
前記命令により特定される前記方法は、
支払いゲートウェイを介して前記支払取引を処理するステップをさらに含む請求項９記載のコンピュータ読み取り可能な記録媒体。
【請求項１７】
ネットワークを介して支払取引を認証するためのシステムであって、
プロフィルデータベースと、
取引アーカイブと、
命令を記憶するメモリと、
当該システムに方法を実施行させるための命令を実行するプロセッサと、
を備え、
前記方法は、
メモリの前記プロフィルデータベースに、公開キーおよび秘密キーを含む公開キー基盤(PKI: public key infrastructure)キーペアに関連する前記公開キーを格納するステップと、
少なくとも前記公開キーを、少なくともメモリにおける買い手の第１支払い証券にリンクさせるステップと、
前記プロフィルデータベースから、少なくとも前記公開キーにリンクされると共に複数の支払い証券と複数の送り先住所を含む買い手プロフィルを読み取るステップと、
ネットワークを介して売り手の識別と前記支払取引の記述を含む電子認証リクエストを受信すると、前記ネットワークを介して前記買い手に関連する装置に前記支払取引の要約を含む電子チャレンジリクエストを送信するステップと、
前記買い手の装置から前記第１支払い証券の選択の電子指示を受信するステップと、
前記ネットワークを介して前記買い手の装置から前記支払取引のデジタル署名された要約を含む電子チャレンジ応答を受信すると、前記公開キーを用いて前記支払取引の前記デジタル署名された要約を解読するステップと、
前記解読から、前記買い手が前記秘密キーにアクセスできることと、前記買い手が前記第１支払い証券を使用することを承認されたことを判定するステップと、
前記ネットワークを介して前記買い手プロフィルからのデータを前記買い手の装置に送信するステップと、
前記支払取引のデジタル署名された記録をメモリの前記取引アーカイブに格納するステップと、
前記売り手に、前記買い手が前記第１支払い証券の使用を承認されたことを通知するステップと
を含む、システム。
【請求項１８】
前記電子認証リクエストは、前記買い手の装置から受信された請求項１７記載のシステム。
【請求項１９】
前記命令により特定される前記方法は、
前記秘密キーを含む前記ＰＫＩキーペアを生成するステップと、
前記ネットワークを介して前記買い手の装置に前記秘密キーを送信するステップ
をさらに含む請求項１７記載のシステム。
【請求項２０】
前記支払取引の前記記録は、前記秘密キーを用いてデジタル署名された請求項１７記載のシステム。
【請求項２１】
前記オンライン取引の前記記録は、ローカルな秘密キーを用いてデジタル署名された請求項１７記載のシステム。
【請求項２２】
前記公開キーは、該公開キーが前記買い手に結び付けられていることを表すデジタル証明書の形式で格納される請求項１７記載のシステム。
【請求項２３】
前記命令により特定される前記方法は、
前記ネットワークを介して前記買い手の装置から、前記複数の支払い証券のうちの一つと前記複数の送り先住所のうちの一つの選択の電子指示を受信するステップ
をさらに含む請求項１７記載のシステム。
【請求項２４】
前記命令により特定される前記方法は、
支払いゲートウェイを介して前記支払取引を処理するステップをさらに含む請求項１７記載のシステム。
【発明の詳細な説明】
【０００１】
発明の属する技術分野
この発明は、オンライン商取引における買い手（バイヤ）の認証に係り、とくに買い手を認証する別個の認証サービスを持つようにすることに関する。
【０００２】
この発明は米合衆国のプロビジョナル特許出願番号６０／１９８，１１０、題名“Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｐａｙｍｅｎｔ（認証された支払い）”  ｂｙ  Ｇｒｅｇ  Ｗｈｉｔｅｈｅａｄ，Ｍｉｃｈａｅｌ  Ｇｒａｖｅｓ，ａｎｄ  Ｔｈａｎｅ  Ｐｌａｍｂｅｃｋ、２０００年４月１７日出願を優先権主張とするものであり、この出願の主題をここでは参考のために組入れている。
【０００３】
従来の技術
ここでは背景となる技術を記述する。インターネット及び他の形式の網形成された通信の普及と受入れとが増大した結果、オンラインコマース（商取引）が大きなビジネスとなっている。例えば、消費者購買、ビジネス間商取引、株式売買及び他の投資形態でインターネット及び／又は無線網上で生ずるものの量や規模（ボリューム）は恒常的に増加しており、これはオンライン商取引の他の形態と同様である。加えて、かなりの努力が払われて、他のビジネスモデル（オークションとかグループ購入といったもの）とか支払いの別の形式（ｅキャッシュとかインターネットで承認が与えられている資金の振替（ファンドのトランスファ））とを開発して、オンライン商取引のユニークな特性の好都合な点を採用しようと試みられている。
【０００４】
発明が解決しようとする課題
しかしながら、オンライン商取引の欠点の一つは、買い手の認証が困難なことである。例えば、消費者がクレジットカードを用いて物品（アイテム、ここでは、サービスを含むこととする）を購入したいと望んでいる場合を考える。もしこの買い手が実際の世界の中でこれをしていたとすると、この買い手はその者の物理的な（有体の、フィジカルな）クレジットカード（恐らくはカード上に写真がついているもの）を提示することを求められることになり、そのクレジットカード上にあるものと整合する署名でクレジットカードスリップ（伝票）に署名（サイン）しなければならないことになる。こういった動作は二つの重要な目的を果している。第一に、動作がこの買い手はそのクレジットカードを使用することの権限を有している（承認が与えられている）という何らかの確信を設定していることであり、第二に、買い手が後になって購入を承認したことを否定することをむづかしくする記録を作り出すことである。こういった両要因は不正行為の（詐欺的な）取引（トランザクション）の危険を著しく減らしている。
【０００５】
この取引のオンライン版（バージョン）では、物理的なクレジットカードを提示して、クレジットカード伝票に署名をすることに対応している動作はいずれも存在しないし、もしあったとしても、危険（リスク）を減らす上で有効ではない。例えば、多くの場合に、買い手は単にその者のクレジットカード番号をタイプイン（打ち込み）をしてから、購入する（メークパーチェス）ボタン上をクリックすることを求められるだけである。こういった二つの動作は、実世界での対応する動作よりも不正行為を受け易い傾向にあり、その理由は、売り手がその動作をしている人物はそのクレジットカードを使用する実際の権限をもっているかどうかを知らないことにある。言い換えると、売り手にとっては買い手を認証することが困難である。さらに、もしかりに真正なクレジットカードの所有者がその取引を承認したとしていても、残された記録は同程度に強固なものでないとする不正行為（詐欺）の危険が増すのであって、その理由として、クレジットカードの所有者は詐欺師がその取引を承認したと主張することができることがあげられる。この“カード不存在（Ｃａｒｄ  ｎｏｔ  ｐｒｅｓｅｎｔ）”状態での詐欺についての追加の危険は、インターネット及び他の商取引システム上で処理される取引についての、より高額の交換レート及び手数料を生じさせて、恐らくはインターネット商取引にとってのコスト基盤に対する一番大きな単独の貢献（寄与）をもたらすもの（コントリビュータ）となる。
【０００６】
インターネット及び他のオンライン詐欺が成長してしまった理由の一つは、個人的な支払い証券（パーソナルペイメントインスルツメント、ｉｎｓｔｒｕｍｅｎｔは道具（ツール）を意味する。金融部門では法律効果のある書面を指すのが普通であり、ここではツールと訳出せずに、金融部門の例にならって証券と訳出することとする）の情報である、クレジットカード番号、小切手振出し用口座（チェッキングアカウント）番号、及び関連のデータなどが本質的に“公開情報（パブリックインフォメーション）”となっていて、このデータがすぐに利用可能となっているという意味で公開されている。例えば、ある消費者がその者のクレジットカード番号と、有効期限日付などを保護されていない形式で、各取引で各オンライン商人に与えることになる。加えて、氏名、アドレス、社会的なセキュリティ番号などのような情報がカード保有者以外のソース（源）から入手可能にもなる。例えば、探索（サーチ）可能な、ウェブでアクセスできる電話番号帳（ディレクトリィ）や他のディレクトリィがこの形式の情報の多くの部分を含むことができる。支払い証券情報についての繰返しとなる、保護されていない開示は、他のソースからこの情報の多くが入手可能であるという事実と一緒になって、詐欺的な取引の危険を増している。例えば、ハッカにとっては、クレジットカード番号とその関係する氏名と住所情報のデータベースを捕捉することだけが必要となることがしばしばあり、それによって、数多くのオンライン取引環境での実際のカード保持者のように仮面をつけるようにする。
【０００７】
便利なことに、買い手認証システムが、パスワードの使用を介してインターネット（ウェブ）商取引環境で通常採用されているやり方に取組んでいて、この環境は買い手が一般に単純な使用者名とパスワードとを用いて自分自身を認証している。前述したように、パスワードは、この目的に使用するためには生来弱点を有していて、現在の実施はこういった弱点をさらに悪化させる。例えば、消費者は一般にオンラインプロセスを用いて各商人と個別に登録をしなければならない。その結果、その商人はその消費者の登録を確認するのに限られた機会しかなく、その理由はオンライン登録のタイミングがときとして意味が十分にあるような確認を許さず、もしあったとしても、各商人がその者自身の確認のコストを負担しなければならないことが理由となって、コストがそれを禁じてしまうのである。加えて、消費者はしばしば複数の口座について同じ使用者名とパスワードとを用いることになる。これは、ユーザ名とパスワードとが秘密を敵にさらす機会を増し、またもしさらされてしまうと、蒙らなければならない可能性がある損害が増す。さらに、ユーザ名とパスワードとは一般に平文として商人に転送されるので、誠実でない商人はまたこの情報を用いて消費者の別な口座の秘密を知るようにできる。最後の例として、多くの現在の認証システムは消費者のアイデンティティ（識別子、ＩＤ）−例えば実際にＪｏｈｎ  Ｄｏｅなる人物が使用者であることを証明すること−を目的としているが、誰かの識別子を認証することは、特定の支払い証券を使用することの権限がある誰かを確認することと同じであることは必ずしも要しない。
【０００８】
セキュリティのある（安全な）電子取引（すなわちＳＥＴ；Ｓｅｃｕｒｅ  Ｅｌｅｃｔｒｏｎｉｃ  Ｔｒａｎｓａｃｔｉｏｎ）プロトコルは、インターネットを介した安全なカード取引に機能するために買い手認証問題を取扱うようにする一つの試みである。ＳＥＴでは、ディジタル証明（書）が使用されて、取引全体にわたって信用の鎖（トラストチェーン）を作るようにしている。例えば、消費者はディジタル証明（書）を持つことになり、それを消費者が商人に提示する。商人はディジタル証明（書）を持つことになり、これを商人が消費者に提示する。各々が他の者のディジタル証明（書）と、その中に置かれているディジタル証明（書）のチェーンとを確認して、信用に値すること（トラストワージィネス）を確定する。しかしながら、このやり方は相当な管理上の、そしてまた動作上の複雑さを消費者と商人と、対応する取引処理用情報とに負わせている。例えば、買い手と商人との両方が特殊の技術を求められていてプロトコルに関与することになり、また、新しいディジタル証明技術が採用されるとその都度、技術の格上げをすることが必要となる。その結果として、ＳＥＴは広く採用されていなかった。
【０００９】
このようにして、オンライン商取引での実のある買い手認証についての必要性（ニーズ）が存在している。さらに、買い手認証へのやり方についての必要性があり、これはまた違った応用についてのセキュリティのいろいろと変るレベルに容易に適応するのに十分な融通性があり、また新しい技術の採用にも容易に適応するよう十分な融通性があるものとする。このやり方はまた著しい負担を既存の取引処理用インフラストラクチャ（基盤構造）に求めたり、また大幅な変更を必要としないものであることが好いとされている。
【００１０】
課題を解決するための手段
この発明によると、オンライン商取引システム（１００）は買い手（１１０）と、売り手（１２０）と、認証サービス（１３０）とを含んでいる。買い手１００が支払証券（ツール）を売り手（１２０）とのオンライン取引の一部として使用することの承認がされている（権限を有している）ことを売り手（１２０）に対して認証することが望まれている。これをするために、認証サービス（１３０）が以下の段階を実行するが、そのすべてはそのオンライン商取引の一部として実時間で発生する。認証サービス（１３０）はその買い手（１１０）が支払い証券（ツール）を使用することの承認がされ（権能を与えられ）ていることを確認するための要求を受領する。売り手（１２０）に対して秘密の情報を開示することなしにある種の秘密情報へのアクセスをその買い手（１１０）が有しているかをこのサービスは判断する。この秘密情報へのアクセスは支払い証券（ツール）を用いるための権限を確認する。買い手が秘密の情報へアクセスを有しているかどうかの判断に応答して、認証サービス（１３０）は売り手（１２０）に応答を送り（２５０）、この応答には、買い手（１１０）が支払い証券（ツール）を使用する権限があるかどうかを含んでいる。この発明の別な特徴（アスペクト）では、認証サービス（１３０）はまた買い手（１１０）についてのプロフィル情報をオンライン商取引及び／又は複数のプロセス（２７０）に適用するか（２６０）、あるいは少くとも部分的に支払い業務を処理する。認証サービス（１３０）はまた、支払い証券の使用及び／又は取引業務（トランザクション）の記録を記憶する（２８０）こともできる。
【００１１】
発明の実施の形態
好ましい実施例（３００）では、オンライン商取引はインターネット上で発生する。買い手（１１０）は、ウェブブラウザを経由してインターネットにアクセスし、売り手（１２０）は、インターネットストアフロント（店舗の正面）であって、ウェブサーバによってホストされているものを操作し、認証サービス（１３０）がウェブサーバ上で実施される。
【００１２】
さらに、秘密情報は私的な（プライベート、公開（パブリック）の反対）キーを含んでいる。換言すると、私的なキーを用いてディジタル署名（シグネチャ）を創り出すことは、署名者が対応している支払い証券（ツール）を用いることに権限を有していることの証しとなる。この実施形態では、認証についての要求（３３０）は買い手による形式（フォーム）（４００）の提出によってトリガがかけられて、この形式は認証サービス（１３０）を識別する動作属性（アクションアトリビュート）を含んでいる。認証サービス（１３０）に対する要求はまた売り手のアドレスを含んでいて、それにより認証サービスはそれがした認証プロセスの結果をどこへ送る（３５０）べきかを知る。売り手（１２０）を認証するために、認証サービス（１３０）は買い手（１１０）に向けた呼びかけの要求（チャレンジリクエスト）を送り（３４０）、買い手（１１０）があるデータにディジタル署名をするために私的なキーを使用することを求める。認証サービス（１３０）は買い手の応答（３４２）を用いて、買い手（１１０）が私的なキーへのアクセスを有するかどうか判断し（３４６）、それから売り手（１２０）に向けてその結果を送る。認証サービス（１３０）はさらに、買い手（１１０）が取引の記録にディジタル署名をして、それにより取引の強固な記録を創り出す（３８０）ようにすることを要求してよい。
【００１３】
この発明はとくに好都合なものであり、その理由は売り手（１２０）ではなく、別個の認証サービス（１３０）が買い手（１１０）を認証するために使用されることにある。その結果、売り手（１２０）は買い手の支払い証券（ツール）と関係している秘密情報へのアクセスを取得しない。これが売り手（１２０）にとってこの秘密情報を再使用して、詐欺的な取引を権限あるものとすることがないようにしている。
【００１４】
さらにまた、認証サービスにおける認証機能の集中は、著しい融通性（フレキシビリティ）とスケール（規模）の経済性とをもたらしている。多くの形式の秘密情報が適当なものとされ、その各々が実施のために異なる技術を必要としている。認証サービス（１３０）における認証機能を集中することは、必要とされる技術のコストを多くの売り手（１２０）の間で分ち合うことができる。さらに、もしくは秘密情報の形式か、対応する買い手の認証プロセスかが変更されるとすると、この変更の塊りは、認証サービス（１３０）だけに影響を与え、したがって新しい認証技術が容易に実施できるようにする。もし認証サービス（１３０）が、他の機能である取引に買い手プロフィル情報を加えたり、支払い証券（ツール）を処理したり、あるいは取引の記録を保存するといったことを実行するとすると、スケールについての追加の経済性が実現され、その理由は認証サービス（１３０）がこういった他の機能についての自然な集中点となることによる。
【００１５】
実施例
以下、本明細書では、上記の、また別のより詳細な、特定の本発明の目的と特徴とを、添付の図面を参照して記述していく。図１はこの発明によるシステム１００のブロック図である。システム１００は買い手１１０と、売り手１２０と、認証サービス１３０とを含み、それらが互に通信をする。システム１００はまた適宜（オプションとして）認証サービスのディレクトリィ１４０を含んでいて、それが買い手１１０によりアクセス可能であり、また買い手プロフィルのデータベース１５０と取引記録書類（トランザクションアーカイブ）１７０とを含んでいて、その両方が認証サービス１３０によってアクセス可能とされている。オプションの支払いゲートウェイ１６０もまた認証サービス１３０によってアクセス可能とされており、代りとなる実施例では、これが売り手１２０であるか、あるは認証サービス１３０と売り手１２０との両方であってよいし、これらが支払いゲートウェイ１６０にアクセスするものとなっている。支払いゲートウェイ１６０は、単純にコンジット（導管）であり、ここを通って支払い取引業務がそれぞれの金融機関に向けて送られる。この発明は、数多くの異なる形式の支払いゲートウェイ１６０（あるいは支払いゲートウェイのないもの）を一緒に使用できるし、またゲートウェイ技術の特殊形式に限定されることを意図していない。
【００１６】
買い手１１０は、売り手１２０とのオンライン商取引の一部として支払い証券を使用したいとしている。例えば、一つの応用では、買い手１１０は消費者であり、売り手１２０は、インターネットストアフロント（店頭）に居る商人であり、この消費者がその者のクレジットカードを用いてある製品、情報、もしくはサービスをその商人から購入したいとしている。別な例では、買い手１１０は個人であって、その者が無線電話もしくは手持ちのパーソナル・ディジタル・アシスタント（ＰＤＡ）を介して売り手１２０に接続していて、売り手１２０が請求書支払いサービスであって、個人がその者の月々の請求書の支払いをするために“インターネット小切手（チェック）”を書くことを望んでいる。さらに別な例では、買い手１１０が企業もしくは個人であって、企業の供給元１２０から材料またはサービスを購入している企業に代って働いているものである。支払い証券（ツール）についての他の例は、小切手勘定書の送り先を記した番号（Ｃｈｅｃｋｉｎｇ  ａｃｃｏｕｎｔ  ｒｏｕｔｉｎｇ  ｎｕｍｂｅｒｓ）や仮想金銭、もしくは現金の電子表示、電子ウォレット（財布）内に貯えられた前払い現金値、購買カード（パーチェスカード）、及びインターネットクレジットまたはクーポンを含んでいる。
【００１７】
こういった例から明らかになることは、数多くの他の応用が可能であることと、用語“買い手（バイヤ）”と“売り手（セラー）”は便宜的なラベルとして使用されているが、その意味はこういったエンティティ（存在するもの）に限定されないことである。“買い手１１０”はある物を実際に買うことを求められていないし、“売り手１２０”は実際に売ることを求められていない。同じように、“オンライン商取引”は売買という取引業務に限定されない。むしろ、そうではなくて、オンライン商取引はどんな取引（トランザクション）でもよく、そこでは買い手１１０が取引業務の一部として支払い証券（ツール、インスツルメント）を使用したいとしており、あるいはもっと一般的には、買い手１１０の認証から恩恵を受けるような取引の一部として、支払い証券を使用したいとしている場合を言う。支払い証券を利用しない応用の例として、“買い手”１００が個人であって、また“売り手”１２０が保険会社であり、この会社とはその買い手がポリシィを有していて、“取引業務（トランザクション）”はその買い手がその者の信託、年金など受給を変えたいとしている場合がある。売り手は先ず、買い手の口座へアクセスを許す前に買い手の識別を認証したいとする。
【００１８】
図２はシステム１００の動作２００を示している事象追跡図（イベントトレース）である。方法２００は大きく三つの主要部分に分割される。買い手登録２０２と、買い手認証２０４と、取引業務を記録すること２０６とである。すべての実施が三つの段階２０２〜２０６を利用するのではないし、また図２に示した個別段階のすべてを利用するのでもないが、これらがこの発明のいろいろな特徴（アスペクト）を示すためにこの例の中に含まれている。買い手の登録２０２では、買い手を認証するために段階２０４で秘密情報が使用されることになり、また支払い証券が買い手１１０と認証サービス１３０との間で設定される。買い手登録２０２は支払い証券について一度限り発生するのが好ましい。買い手の承認（権限付与、オーソライゼーション）２０４はオンライン商取引の一部として実時間で発生する。この段階で、買い手１１０は認証サービス１３０に向けた秘密情報へのアクセスを実際に行なう（デモンストレートする）。このアクセスが成功のうちに行なわれると、認証サービス１３０は売り手１２０に対して、買い手１１０が支払い証券を用いることの承認を与えられていることを知らせる。取引記録２０６段階では、認証サービス１３０は取引の記録を創り出して、この記録が後に証拠として使用されて、ある種の取引が発生したかどうかを証しする。
【００１９】
個別の認証サービス１３０の使用は多くの利点を備えている。例えば、以下の記述からもっとはっきりとすることになろうが、買い手認証プロセス２０４の塊り（バルク）が認証サービス１３０により実行される。認証サービス１３０は、買い手１１０が秘密情報へのアクセスを実際に行ない、それによって支払い証券を使用することの承認がされているかどうかを判断する。買い手１１０は最低限だけ関与するようにされ、また売り手１２０は全く本質的には関与しない。認証サービス１３０におけるこの機能の集中は著しい融通性とスケール（規模、大きさ）の経済性とをもたらす。例えば、単純なＰＩＮ（個人識別番号）から高度に進んだ複雑なディジタル証明プロトコルに至る範囲の秘密情報についての異なる形式が、異なる支払い証券についてのセキュリティに関する異なるレベルを生じさせるのに使用できる。秘密情報の異なる形式は買い手認証段階２０４を実行するために異なる基盤構造（インフラストラクチャ）を必要とすることになる。買い手認証段階２０４を認証サービス１３０の中で集中させることはこの基盤構造のコストが多くの売り手１２０の間で分けられるようにする。さらにまた、もし秘密情報もしくは対応している買い手認証プロセスが変更されるとすると、変更の塊りが認証サービス１３０だけに影響を及ぼすことになるので、新しい認証技術が容易に実施できるようになる。これと対照的なのは、以前のＳＥＴのようなやり方であって、各売り手が必要とされる基盤構造の大部分を用意することを求めている。これが高コストと、遅い初期適応と、新技術への切換えの困難さとに通じ、終局的にはこれらがＳＥＴとそれと類似のやり方の失敗に導いている。
【００２０】
このやり方はまた好都合であり、その理由として、売り手１２０が買い手１１０の秘密情報へのアクセスを取得しないことがあり、買い手認証２０４に売り手が関与していないことがあげられる。これが詐欺的な取引に権限を持たせるために、買い手１１０の秘密情報を後に売り手１２０が再使用できないようにしている。例えば、秘密情報がＰＩＮ番号であると仮定する。もし売り手１２０が買い手の認証２０４に対して責任があったとすると、買い手１１０はその者のＰＩＮ番号を売り手１２０に開示することになり、売り手１２０はそれを不法な目的で後に使用できることになる。しかしながら、現在のやり方では、売り手１２０がＰＩＮ番号を認証サービス１３０に対してだけ開示し、売り手１２０には開示していない。
【００２１】
再び図２を参照すると、破線の箱１１０，１２０，１３０の各々はシステム１００内の構成要素の一つを表わしている。実線の箱は方法２００内の各種の段階を表わしている。破線の箱の中での実線の箱の位置は、段階がこういった構成要素によって一般に実行されることを表わしている。例えば、段階２１０は認証サービス１３０についての破線の箱の内部に置かれている。これが示しているのは、認証サービス１３０が一般に段階２１０を実行するということである。ある段階は二つの箱を有していて、これがその段階が二つの構成要素上で生ずることを示している。例えば一つの構成要素はメッセージを他の構成要素に送ることができる。こういった段階はシステム１００内部の各種の部品上で実行されているソフトウェアによって実施されるのがよく、システムでは恐らくはハードウェアモジュールによる支援がされる。こういったことはハードウェア及び／又はファームウェアで実施することもできる。
【００２２】
買い手登録段階２０２は実際のオンライン商取引の前に発生するのが好い。段階２０２では、秘密情報が買い手１１０と認証サービス１３０との間に設定される。情報は、理想的には、買い手（もしくは買い手１１０と認証サービス１３０との両者により共用されている秘密である場合にはその両者）によってのみ知られ及び／又はアクセス可能であるという意味で、秘密である。これは一般には公衆により入手可能でないし、あるいは売手１２０によって入手可能ではない。さらに、この秘密情報は特定の支払い証券に対応していて、秘密情報へのアクセスを証明することは支払い証券を用いるための承認（権限付与）として行なわれる。
【００２３】
異なる形式の秘密情報が必要とされるセキュリティの形式に依存して使用されてよい。秘密情報の例は、ＰＩＮ番号とかパスワード、網で記憶されている信用証明書（例えば移動（ローミング）を支持するためのもの）、“ローミング”ディジタル署名能力、買い手の機械に対して局在する私的なキーのようなソフトウェア信用証明書（クレデンシャル）、ハードウェアのトークンとかスマートカード上に搭載されている私的なキー、生物測度の信用証明書、及び暗号法の呼びかけ（チャレンジ）応答プロトコルで使用される情報を含んでいる。
【００２４】
図２の特定の例では、秘密情報は次のように設定される。認証サービス１３０は確認（コンファメーション）情報を受領し（２１０）、この情報は買い手１１０が秘密情報へのアクセスを有しているかどうか後に判断することができるようにする。認証サービス１３０はそこでこの確認情報であって支払い証券と関係しているものを、例えば買い手プロフィルデータベース１５０の一部として、記憶する（２１２）。一実施例でこのモデルによるものでは、買い手の秘密情報は私的なキーであり、また対応している確認情報は対応している公開キーである。
【００２５】
別な実施例では、買い手登録が別なやり方で実施される。例えば、確認情報は認証サービス１３０で記憶されなくてよい。その代りに、別なところに記憶されて、必要なときに認証サービス１３０によって回復（検索読出し）される。これに代って、秘密情報とは違っている確認情報を記憶するのではなくて、認証サービス１３０が単に秘密情報それ自体を記憶することができる（例えばパスワードとかパスワードをハッシュ（小間切れと）したものを記憶する）。別の例では、買い手登録２０２がオンラインではなくオフラインで発生してよい。例えば、買い手１１０はある申込（書）を充填して、それを銀行へ送る。銀行は申込（書）上の情報を確認してクレジットカードを買い手１１０に対して発給して、認証サービス１３０に対して口座情報を送る。認証サービス１３０はスマートカードを創り出し、そこには埋込まれた秘密情報があり、またこのスマートカードが買い手１１０に向けて、郵便サービスを例えば経由して、送られる。この最後の例では、買い手登録２０２はクレジットカードエンロールメント（登録）プロセスの好都合な点を採用することに注目されたい。買い手登録はまた他のプロセスの好都合な点を採用してもよい。
【００２６】
秘密情報は買い手１１０によって生成されて、他の当事者への開示を最少とするようにするのが好ましい。しかしながら、別の実施例では、秘密情報は他の当事者によって生成され及び／又は共用されてよく、例えば認証サービスが他の当事者にあたり、とくにこういった当事者によってもたらされる危険が小さいと考えられるときにはそのようにされる。
【００２７】
買い手認証段階２０４では、買い手１１０は支払い証券を、売り手１２０とのオンライン商取引の一部として使用したいとする。認証サービス１３０は、取引の一部として、実時間で、買い手１１０がそうすることが承認されている（権限がある）かどうかについて判断する。買い手１１０は支払い証券を使用することの提案をする（２２０）。例えば、買い手１１０はクレジットカードを用いて購入に対する支払いを申し出る。
【００２８】
売り手１２０は、その買い手がその支払い証券（ツール）を使用する権限があるかどうかを知りたいと思い、買い手の権限を確認するために認証サービス１３０へ要求を送る（２３０）。支払い証券に依り、認証サービス１３０の識別は即座に明らかにならないことがある。複数の認証サービスがあってよい。例えば、各クレジットカード会社は、自己の認証サービスを用意することになる。この問題を解決する一つの方法は、ディレクトリィ１４０を備えて、それが支払い証券に認証サービスを関係付けするようにする。この場合に売り手１２０はディレクトリィ１４０にアクセスして、どの認証サービスが買い手１１０により呈示された支払い証券について適切なものであるかを判断するようにする。
【００２９】
認証サービス１３０は、買い手１１０が秘密情報へのアクセスを有しているかどうかを段階２４０〜２４６で判断する。認証サービス１３０は“チャレンジリクエスト（呼びかけ要求）”を買い手１１０に向けて送る（２４０）。呼びかけ要求は買い手が秘密情報へのアクセスを有していることの証明を求めるものである。例えば、もし秘密情報がパスワードであるとすると、呼びかけ要求はこのパスワードを求めるものであってよい。もし秘密情報が私的なキーであれば、呼びかけ要求は、買い手がその私的なキーを用いて何かにディジタル署名することを要求してよい。一実施例では、この呼びかけ要求はまたオンライン商取引についての記述を含んでいて、買い手がその取引を止めることができるようにし、例えばこれはその記述が買い手の期待と整合していないときに行なわれる。同じように、呼びかけ要求は、代って、その取引について買い手の同意を求めるものであってよい。もし買い手１１０が先へ進みたいのであれば、その者は“呼びかけ応答（チャレンジレスポンス）”を認証サービス１３０に送り戻す（２４２）。
【００３０】
認証サービス１３０は早期に記憶した支払い証券についての確認情報を検索読出しして、この確認情報と呼びかけ応答とを用いて、買い手１１０が秘密情報へのアクセスを有しているかどうかの判断をする。例えば、パスワードの例の実施例では、認証サービスは、呼びかけ応答からの伝えられた（アレッジされた）パスワードを小間切れにして、これを確認情報として記憶された小間切れと比較する。私的なキーの例の実施例では、認証サービス１３０は、確認情報として記憶された公開キーを用いて、呼びかけ応答内のディジタル署名されたメッセージが対応している私的なキーを用いて本当にディジタル署名されたかどうか判断する。
【００３１】
認証サービス１３０はそこで売り手１２０に向けて、売り手のもともとの要求に対する応答を送る。この応答は、買い手１１０がその支払い証券を使用する権限をもっている（承認されている）かどうかを含んでいる。また、追加の情報を含むこともできて、そのことは段階２６０と２７０の情況の下で記述されることになる。買い手認証２０４の間に、秘密情報は売り手１２０には示されないことに留意されたい。
【００３２】
段階２６０と２７０とへ移る前に、認証段階２４０〜２５０として図２に示されているものは、買い手認証段階２０４を実施する一つのやり方にすぎないことに留意されたい。他の実施は明白なものとなろう。例えば、認証サービス１３０は売り手１２０からではなく、買い手１１０から認証のための要求を受領する（２３０）ことができる。他の例では、認証サービス１３０は呼びかけ要求２４０と呼びかけ応答２４２とを使用しないかもしれない。秘密情報へのアクセスの立証は、代って最初の要求２３０の一部として含まれていてもよい。加えて、買い手登録のフェーズ（相）２０２で述べたように、認証サービス１３０は確認情報（段階２４４と２４６）以外の方法を用いて、買い手が秘密情報へのアクセスを有しているかどうかを判断してよい。
【００３３】
図２に戻って、ある実施例では、認証サービス１３０はまた追加の買い手プロフィル情報を取引に適用することもできる。例えば、売り手１２０は、買い手の送り先住所が取引業務に加えられることを要求してよい。認証サービス１３０データベース１５０からこの情報を検索読出して、それを進行中の取引に加える。この追加の情報は取引業務中の各種のところで加えられるようにできて、買い手１１０もしくは売り手１２０のいずれかとの通信を含んでいてよい。例えば送り先住所の中では、買い手１１０はこの住所を確認することを求められてよいし、及び／又は売り手１２０は送付料金を計算するためにこの住所を使うこともでき、この料金はその先で取引業務のドル金額に変えられることになる。
【００３４】
同じように、認証サービス１３０はまた支払い取引業務を例えば支払いゲートウェイ１６０を介して処理（２７０）することもできる。一つの極端な処理では、認証サービス１３０は単に売り手１２０に通知して（２５０）、買い手１１０が支払い証券を使用する権限があるが、売り手１２０は支払い証券を処理するのに必要とされる他のすべての段階をとることを知らせる。他の極端な処理では、支払い取引業務を処理するため段階を実行するのは認証サービス１３０となっていてよい。中間の場合には、認証サービス１３０はいくつかの段階を実行して、買い手が他のものを完了することとしている。
【００３５】
買い手のプロフィル形成２６０と支払い処理２７０との両方は、認証サービス１３０がこういった活動についての自然の集中点であることが原因となって、魅力的なものである。実際の認証段階２４０〜２４６についてみると、スケールの経済性は認証サービス１３０を有することによって実現されてよく、各個別の売り手１２０がするのではなく、これらの機能を認証サービスが実行する。
【００３６】
取引記録段階２０６では、認証サービス１３０は取引業務記録文書（トランザクションアーカイブ）１７０内に取引業務の記録を記憶する（２８０）。この記録が信用に値する程度は特定の応用に依存することになる。一例として、認証サービス１３０は取引業務の平文記述を単に記憶してよい。別な例では、ディジタル署名し、かつ時間スタンプを押した記録はより適切なものとなる。上記のパスワード例を続けると、ディジタル署名した記録は、自分自身の私的なキーを用いて記録にディジタル署名する認証サービスをもつことによって創り出されてよい。私的なキーの例では、買い手１１０自体はその者自身の私的なキーを用いて取引業務についてのディジタル的に署名した記録を創り出す。こういった例の両方では、結果は永続性のある、ディジタル署名した取引の記録であり、これはその取引業務についての紛争を解決するために買い手１１０、売り手１２０、もしくは他の当事者により使用できるものである。
【００３７】
図３ないし９は、システム１００と方法２００との好ましい実施形態である。インターネット実施例では、オンライン商取引はＨＴＴＰ応用システム、とくにインターネット上で発生する。買い手１１０は通常のウェブブラウザを用いてインターネットにアクセスする。売り手１２０は商人であり、この者がインターネット上のウェブサイト店舗正面（店頭）、この場合には仮想的なＰｅｔｅ’ｓ  Ｓｏｃｃｅｒ  Ｅｍｐｏｒｉｕｍ、を操作する。店舗の正面は通常のウェブサーバ上で実行する。認証サービス１３０もまたウェブサーバを介してインターネットへのインターフェースとなる。買い手１１０は、支払い証券としてその者のクレジットカードを使用して、ピートのサッカー百貨店（Ｐｅｔｅ’ｓ  Ｓｏｃｃｅｒ  Ｅｍｐｏｒｉｕｍ）からある特定のカップ（ｔｈｅ  Ａｄｉｄａｓ  Ｅｐｔ．Ｐｒｅｄａｔｏｒ  Ａｃｃｅｌｅｒａｔｏｒ  Ｃｕｐ）を購入したいとしている。取引の安全を確保するために使用される秘密情報は支払い証券と関係している私的なキーである。便宜上、この実施例はインターネット実施形態としているが、この実施形態がインターネットについて可能な唯一のものであることを意味していない。
【００３８】
図３はイベントトレース（事象の形跡）であって、インターネット実施例の動作を示している。方法２００のように、方法３００も大きく三つの主要部分に分けられる。買い手登録３０２と、買い手認証３０４と、取引業務を記録に残すこと３０６とである。しかしながら、買い手認証３０４と、記録に残すこと３０６とは互にからみ合っている。
【００３９】
買い手登録フェーズ（相）３０２では、買い手１１０はその者の“口座（アカウント）”を認証サービス１３０で設定する。この場合に、いずれものオフライン調査が行なわれることを意味しており、例えば、その買い手１１０がそのクレジットカードを使用する権限があることのクレジットカード会社からの確認を受領する。さらに、私的と公開キーとの組合せでその口座についてのものが生成されて、公開キーが認証サービスのデータベース１５０内に記憶される（３１２）。好ましい実施例では、公開キーはディジタル証明（書）の形態で記憶され、この証明はその公開キーがその買い手の口座と連結していることを表わしている。
【００４０】
この実施例では、口座とキーの対とが多数の支払い証券と連結していて、支払い証明には使用されることになる特定のクレジットカードを含んでいる。言い換えると、ディジタル証明とキーの対とは買い手の“財布（ウオレット）”についてのものであり、この財布は数多くの支払い証券（ツール）を含んでいて、一つの特定の支払い証券についてのものではない。しかしながら、他の実施例は別の仕組み（スキーム）を使用してよく、各支払い証券について異なる口座とキーの対とを用いるといったものである。加えて、買い手は多数の口座とキーの対とを有していてよい。この実施例では、買い手の私的なキーと、関係している公開キー基礎構造（ＰＫＩ，ｐｕｂｌｉｃ  ｋｅｙ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）サービスがソフトウェアエージェントによって買い手１１０のために管理されていて、とくにVeriSignパーソナル・トラスト・エージェント（ＰＴＡ）によって管理されている。このＰＴＡは、汎用キーと証明（書）管理機能とを用意し、ウェブ応用に容易に組込めるように設計されている。
【００４１】
VeriSign ＰＴＡは買い手のＰＫＩ信用保証（クレデンシャル）を管理する。例えば、もし、買い手１１０がディジタル証明（書）もしくはキーの対をもっていないとすると、ＰＴＡは買い手１１０を証明登録（エンロールメント）ページに取込む。もしこの買い手のディジタル証明がすぐに期限切れとなるのであれば、ＰＴＡは買い手１１０に助言を与えて、継続前に証明を更新するようにし、また買手１１０を証明更新ページに取込めるようにする。同じように、もし、買い手の証明がすでに期限切れとなっていれば、ＰＴＡは、期限の切れた証明を更新するために証明更新ページへ進めるようなオプションを提案する。こういったことのすべては違ったブラウザにまたがって一致しているダイアログ（会話）の組によって実施できる。さらに、この特定の実施例はブラウザを用いているが、ＰＴＡはまた他のデバイスを支持するのであって、その中には無線電話や、手持ちのＰＤＡ（パーソナルデータアシスタント）などが含まれている。
【００４２】
ＰＴＡと私的なキーとは数多くの場所でホストされ（アクセスされ）てよい。この例では、個別のサーバ（図示せず）がＰＴＡを実施しているソフトウェアをホストし、対応している私的なキーを記憶する。このやり方の一つの利点は、ＰＴＡと私的なキーとがゼロクライアントの、ホストされたサービスとして実施されるので、買い手のブラウザに対しては何の変更もされることを要さないということである。別の利点は、買い手のブラウザは特定のソフトウェアを何ら必要としないので、買い手１１０は可能性としていずれかの標準ブラウザからＰＴＡとその者の私的なキーとにアクセスできるということである。これがどのように実施できるかの例については、未決米合衆国特許出願一連番号Ｎｏ．０９／５７４，６８７，“Ｓｅｒｖｅｒ−Ａｓｓｉｓｔｅｄ  Ｒｅｇｅｎｅｒａｔｉｏｎ  ｏｆ  ａ  Ｓｔｒｏｎｇ  Ｓｅｃｒｅｔ  ｆｒｏｍ  ａ  Ｗｅａｋ  ｓｅｃｔｒｅｔ”，ｂｙ  Ｗａｒｗｉｃｋ  Ｆｏｒｄ，２０００年５月１７日出願を参照されたく、この文献をここに組入れることとする。ＰＴＡをホストしているサーバが認証サービス１３０をホストしているものと同じであるとすると、二つの機能はある程度統合されてよい。別な実施例では、ＰＴＡ及び／又は対応する私的なキーは買い手のクライアントで実施される。例えば、ＰＴＡは、買い手のクライアント上に局所的に、あるいは専用のハードウェア（例えばハードウェアトークン）内に、局所的に記憶された買い手の私的なキーと買い手のブラウザへのプラグイン（例えばＡｃｔｉｖｅＸ  ｃｏｎｔｒｏｌ）として実施されてよい。
【００４３】
サッカの例を続けると、登録３０２の後に、買い手１１０はＰｅｔｅのところで買物をしていて、何かの製品を買うことを決める。図４は買い手がチェックアウト（検討、品定め、支払完了）プロセスを開始するときの、買い手のブラウザのスクリーンショット（描写）である。ＨＴＭＬ注文形式４００は注文領域４１０とともに、急ぎの認証された支払いについてのボタン４２０とを含んでいる。注文領域はこの注文についての合計金額と税とが５９．９５ドルであることを示している。買い手１１０は、認証されていないやり方で、この形式の残りの部分を用いて、クレジットカード情報や、請求書送り先住所などを充填してチェックアウト（支払をすませる）ことができる。しかしながら、買い手１１０は認証された支払いを望んでおり、そこで代って“ＡｕｔｈＰａｙ”（すなわち認証された支払い，ａｕｔｈｅｎｔｉｃａｔｅｄ  ｐａｙｍｅｎｔ）についてのボタン４２０をクリックする。
【００４４】
認証された支払いボタン４２０をクリックする結果として、認証についての要求が買い手のブラウザから認証サービス１３０に向けて送られる（３３０）。この要求は、支払い取引業務（トランザクション）の記述を含み、また売り手１２０を特定識別する。認証サービス１３０は、買い手１１０が秘密情報（この場合は選ばれた口座についての私的なキー）へのアクセスを有しているかどうか判断する（段階３４０〜３４６）。とくに、認証サービス１３０は呼びかけ要求（チャレンジリクエスト）を買い手１１０に向けて送る。呼びかけ要求は買い手１１０に、選ばれた口座についての私的なキーを用いてあるデータにディジタル署名することを求める。買い手１１０はその者の呼びかけ応答（チャレンジレスポンス）を認証サービス１３０に向けて送り戻す。認証サービス１３０は早期に記憶した公開キーを検索読出して、それを用いて、その買い手１１０が対応する私的なキーへのアクセスを有しているかどうかを判断する。認証プロセスは一般に計算機間で実行され、人間である買い手１１０の積極的な関与なしに行なわれる。
【００４５】
この実施例では、ＰＴＡはまた、買い手１１０が、その者の使用したいとしているその者のどの口座を選び、またその後にその口座内部でそこからの特定の支払い証券（ツール）を選ぶことができるようするために呼出される。さらに特定すると、ボタン４２０をクリックすることは、買い手のウェブブラウザがＰＴＡと図５と６の対話箱（ダイアログボックス）を介して相互作用（対話）するようにしている。図５では、買い手１１０はユーザ名前（名称）フィールド５１０を充填することによって、どの口座をその者が使用したいとしているかを特定し、それから正しいパスワード５２０で充填することによってＰＴＡに対して自分自身を認証する。ＰＴＡは図６の対話箱を表示し、そこには目視可能な（ビジュアルな）表示５３０が選ばれた口座について含まれている。買い手１１０は、その者がこの口座を使用したいことを確認するのに、ログイン（Ｌｏｇｉｎ）ボタン５４０上をクリックして行なう。この口座についての私的なキーはここで認証とディジタル署名にとって利用可能となっている。
【００４６】
もし買い手１１０が認証段階で不成功であるとすると、認証サービス１３０は適切な動作を採用する。例えば、売り手１２０に対して通告をして、その買い手が認証されなかったことを知らせる。代って、それ以上の取引業務についての処理を拒否して、その買手に初期のスクリーン（例えばチェックアウトスクリーン４００）を戻すことができる。
【００４７】
もし買い手１１０が認証されれば、認証サービス１３０は追加の買い手プロフィル情報を取引業務に適用する（３６０）。この場合に、認証サービス１３０は買い手プロフィル情報を検索して、この情報を図７に示した形式でブラウザに向けて送る。この情報はこの口座の中で異なる支払い証券（ツール）６１０を含んでいるし、また異なる出荷先住所６２０も含んでいる。この買い手のプロフィル情報は、敏感な性質をもつものであるから、認証サービス１３０は買い手１１０を認証してからその情報をその者に送るようにするのがよい。この形式（フォーム）は、また取引業務についての情報６３０を反復繰返している。買い手１１０は支払い証券６１０を請求書送り先住所６２０とを選択して、Ｃｏｎｔｉｎｕｅ（継続）ボタンをクリックすることによりこの形式（フォーム）を送る。
【００４８】
買い手１１０と認証サービス１３０とは図８と９とに示した形式（フォーム）と対話箱とを用いて取引業務のディジタル署名をした記録を創り出す（３８０）。この形式６００の提出に応答して、認証サービス１３０は、図８の形式を戻すが、そこには取引業務の要約７１０を含んでいて、また買い手１１０が取引を承認することを要求もする。買い手１１０がそれをするには取引業務承認ボタン（Ａｕｔｈｏｒｉｚｅ  Ｔｒａｎｓａｃｔｉｏｎ  ｂｕｔｔｏｎ）７２０上をクリックする。これが図９のＰＴＡ対話箱を呼出す。署名（Ｓｉｇｎ）ボタン７３０をクリックすることにより、買い手はＰＴＡにその要約にディジタル署名するようにさせ、これによって、取引業務についてのディジタル書名した記録を作る。認証サービス１３０はそこで売り手１２０に通知して（３５０）、その買手が支払い証券を使用することを承認していることを告げ、好ましいのは、さらに買い手に、この取引が認可されたものであることも告げる。
【００４９】
この実施例では、認証サービス１３０は、また売り手１２０について支払い証券を支払いゲートウェイ１６０を介して処理するが、これにはVeriSignから利用可能とされているＰａｙｆｌｏｗサービスのようなものが用いられる。
【００５０】
買い手１１０と売り手１２０と認証サービス１３０で方法３００内にあるものとの間の情報の伝送は通常のウェブ技術を用いて達成される。例えば、形式４００は売り手１２０によって提供されるが、認証支払い（ａｕｔｈｅｎｔｉｃａｔｅｄ  ｐａｙｍｅｎｔ）ボタン上をクリックすることは売り手１２０から認証サービス１３０に向けて買い手のブラウザをハンドオフ（手渡し）することである。同じように、一度認証プロセスが完了すると、買い手のブラウザは認証サービス１３０から売り手１２０に向けて戻される。
【００５１】
こういった転送（トランスファ）の両方とも、ＧＥＴ，ＰＯＳＴ（郵送）、及び／又は転送（再宛名指定）といった従来の技術を用いて達成される。例えば、送られるべきデータを含んでいる形式のＨＴＴＰ  ＰＯＳＴによってトランスファが達成できる。これは堅牢なものであるが、時には望んでいない、中間のウェブページをもたらすことになる。しかしながら、自動的にトリガされたクライアント記述（スクリプト）が使用できて、中間ページを介してクリックするという必要性を排除するようにする。別のオプション（選択肢）はＵＲＬに向けてＨＴＴＰ転送されることであり、ＵＲＬには伝えられるべきデータが含まれている。これが中間ページを排除できるが、現状では伝えられるようにできるデータの量に制限がある（ＨＴＴＰ  ＧＥＴだけが転送できることが原因である）。別のオプションは、伝えられるべきデータの位置を参照しているＵＲＬにＨＴＴＰ転送することであり、これは何らかの他の機構を介して実際に転送されたデータと一緒に参照される。これは他の二つの方法よりももっと複雑であるが、伝えることができるデータの量を制限せずに、中間ページを排除できる。データは何らかの他の機構（方法）によって伝送されて、宛先で識別子（ＩＤ）を指定されて、キャッシュに入れられる。買い手１１０はそこで指定された識別子を含んでいるＵＲＬと一緒に転送される。
【００５２】
簡単にした例では、認証された支払いボタン４２０をクリックすることが認証サーバ１３０に向けて認証についての要求を送る瞬間を仮定しているとする。この実施例では次の構造（数１）を備えた形式４００を用いて、これが達成される。
【００５３】
【数１】
0004880171.tif 000002
【００５４】
ここで、「https://authpay.verisign.com/authenticate.dll」は認証サービス１３０のＵＲＬである。「ｒｅｔｕｒｎ  ＵＲＬ」フィールドは売り手１２０のウェブサイトにおける位置を特定していて、そこに向けて買い手は認証が完了した後に戻ることになる。「ｍｓｇ」フィールドは認証についての要求を帯している。他のフィールドは追加の機能を支持するために使用されてよく、この機能はプロフィル情報や支払い処理を適用することを含んでいる。
【００５５】
支払い承認プロセスが完了すると、買い手１１０は認証サービス１３０から売り手１２０へ向けて、要求の中で特定された戻りＵＲＬ（「ｒｅｔｕｒｎ  ＵＲＬ」）へのＨＴＴＰ  ＰＯＳＴを介して、戻るように手渡される。ＨＴＭＬ形式であって売り手１２０へ送り戻されたものは、次の（数２）の構造を有している：
【数２】
0004880171.tif 000003
【００５６】
ここで「ｔｒａｎｓＩＤ」フィールドは取引業務（トランザクション）識別子を含んでいて、これが買い手１１０か売り手１２０かのいずれかにより使用することができて、取引業務記録文書１７０内の取引業務を参照するのにあてられる。「ｍｓｇ」フィールドは認証サービス１３０から売り手１２０への応答を帯している。
【００５７】
この発明はかなり詳細にわたってある好ましい実施例を参照して記述されて来たが、他の実施例も可能である。例えば、無線（例をあげればＷＡＰ応用の）実施例では、買い手１１０と、売り手１２０と、認証サービス１３０との間の通信のある部分もしくは全部が無線接続を介して生ずるか無線基盤構造を有線基盤構造に接続しているゲートウェイを介して生ずるかしている。例えば、買い手１１０はＷＡＰが可能とされている手持ちのデバイスから通信をすることになろう。したがって、特許請求の範囲はここに含まれている好ましい実施例の記述に限定されるべきものではない。
【図面の簡単な説明】
【図１】  この発明によるシステムのブロック図。
【図２】  図１のシステムを動作する方法を示す事象（イベント）トレースを示す図。
【図３】  図１のシステムの好ましい実施例を動作する好ましい方法を示す事象（イベント）トレースを示す図。
【図４】  図３の方法を示す各種のスクリーンショット（一場面）とダイアログ（自然言語による対話）ボックスを示す図。
【図５】  図３の方法を示す各種のスクリーンショット（一場面）とダイアログ（自然言語による対話）ボックスを示す図。
【図６】  図３の方法を示す各種のスクリーンショット（一場面）とダイアログ（自然言語による対話）ボックスを示す図。
【図７】  図３の方法を示す各種のスクリーンショット（一場面）とダイアログ（自然言語による対話）ボックス示す図。
【図８】  図３の方法を示す各種のスクリーンショット（一場面）とダイアログ（自然言語による対話）ボックス示す図。
【図９】  図３の方法を示す各種のスクリーンショット（一場面）とダイアログ（自然言語による対話）ボックス示す図。
【図１】
0004880171.tif 000004
【図２】
0004880171.tif 000005
【図３】
0004880171.tif 000006
【図４】
0004880171.tif 000007
【図５】
0004880171.tif 000008
【図６】
0004880171.tif 000009
【図７】
0004880171.tif 000010
【図８】
0004880171.tif 000011
【図９】
0004880171.tif 000012