(57)【特許請求の範囲】
【請求項１】
買い手に提供される製品を売り手コンピュータから購入するシステムであって、当該製品は買い手と関連するコンピュータ（買い手コンピュータ）によって前記売り手コンピュータに要求され、
(a)  前記買い手コンピュータは、コマースゲートウェイにより保持された仮想支払アカウントを用いて前記売り手コンピュータから製品を購入し、製品の購入は前記買い手コンピュータが前記仮想支払アカウントを用いて前記売り手コンピュータから製品を購入するリクエストを前記売り手コンピュータに送信することで開始され、
(b)  前記売り手コンピュータは、前記コマースゲートウェイにより保持された仮想支払アカウントを用いた当該売り手コンピュータからの製品購入のリクエストを買い手コンピュータから受信し、
(c)  前記コマースゲートウェイは、複数の仮想支払アカウントを保持し、クレジット処理サーバと連係して、仮想支払アカウントを用いた製品購入の許可および決済を行うように構成されたシステムであって、
(i)  前記売り手コンピュータが前記買い手コンピュータから仮想支払アカウントを用いた購入リクエストを受信したことに応じて、当該売り手コンピュータは購入オファーを前記買い手コンピュータに返信し、
(ii)  前記売り手コンピュータから返信された購入オファーを受信したことに応じて、前記買い手コンピュータは、
(1)  前記コマースゲートウェイに対してセキュア接続を確立し、
(2)  仮想支払アカウントを識別するデジタル証明書が当該買い手コンピュータにインストールされているか否かを決定し、
(3)  当該買い手コンピュータに仮想支払アカウントを識別するデジタル証明書がインストールされている場合には、当該インストールされたデジタル証明書から取得した仮想支払アカウントに関する情報を含む認証コンテナを前記コマースゲートウェイに送信し、
(iii)  前記買い手コンピュータから認証コンテナを受信したことに応じて、前記コマースゲートウェイは前記買い手コンピュータが仮想支払アカウントに関連しているか否かを決定し、決定の結果を買い手コンピュータに返信し、
(iv)  前記売り手コンピュータが前記買い手コンピュータに関連する仮想支払アカウントに関する情報を含む購入コンファメーションを前記買い手コンピュータから受信することに応じて、当該売り手コンピュータはコマースゲートウェイに購入許可を要求し、
(v)  前記売り手コンピュータが前記コマースゲートウェイから購入許可を受信することに応じて、当該売り手コンピュータは、前記買い手コンピュータに関連した買い手に対する製品の提供の準備を行い、前記コマースゲートウェイに支払を要求する、システム。
【請求項２】
前記コマースゲートウェイは、前記買い手コンピュータが仮想支払アカウントと関連していること及び当該仮想支払アカウントが有効であることの決定に応じて、アカウント識別コンテナを前記買い手コンピュータに送信する、請求項１に記載のシステム。
【請求項３】
仮想支払アカウントに関連するデジタル証明書が前記買い手コンピュータにインストールされていない場合には、当該買い手コンピュータは代替の許可を要求し、
代替の許可が要求された場合には、前記仮想支払アカウントに関する情報に代えて前記代替の許可に関する情報を、前記コマースゲートウェイに送信される前記認証コンテナに含ませる、請求項１に記載のシステム。
【請求項４】
前記コマースゲートウェイが前記売り手コンピュータから許可リクエストを受信したことに応じて、当該コマースゲートウェイは、
前記仮想支払アカウントに製品のコストの請求ができるか否かを決定し、
前記仮想支払アカウントに製品のコストの請求ができるという決定に応じて、有効なトランザクション許可を前記売り手コンピュータに送信する、請求項３に記載のシステム。
【請求項５】
前記コマースゲートウェイが前記売り手コンピュータから許可リクエストを受信したことに応じて、当該コマースゲートウェイは、
前記仮想支払アカウントに製品のコストの請求ができるか否かを決定し、
前記仮想支払アカウントに製品のコストの請求ができるという決定に応じて、有効なトランザクション許可を前記売り手コンピュータに送信する、請求項１に記載のシステム。
【請求項６】
前記デジタル証明書は保証トークンに格納されている、請求項１に記載のシステム。
【請求項７】
前記コマースゲートウェイによって前記買い手コンピュータに返信された結果が、買い手が仮想支払アカウントに関連していることを示している場合には、前記買い手コンピュータは、
購入コンファメーションを取得し、
前記購入コンファメーションを前記売り手コンピュータに送信する、
請求項１に記載のシステム。
【請求項８】
前記コマースゲートウェイが前記売り手コンピュータから許可リクエストを受信したことに応じて、当該コマースゲートウェイは、
前記仮想支払アカウントに製品のコストの請求ができるか否かを決定し、
前記仮想支払アカウントに製品のコストの請求ができるという決定に応じて、有効なトランザクション許可を前記売り手コンピュータに送信する、請求項１に記載のシステム。
【請求項９】
支払アカウントを用いて売り手コンピュータから製品を購入する方法であって、当該製品は買い手と関連するコンピュータ（買い手コンピュータ）によって要求され、
前記支払アカウントは仮想支払アカウントであり、
前記売り手コンピュータが前記仮想支払アカウントを用いて当該売り手コンピュータから製品を購入するための注文を前記買い手コンピュータから受信することに応じて、前記買い手コンピュータに前記仮想支払アカウントを識別するデジタル証明書がインストールされているかを決定し、
前記買い手コンピュータに仮想支払アカウントを識別するデジタル証明書がインストールされている場合には、当該売り手コンピュータを含む複数の売り手コンピュータに仕えるコマースゲートウェイにセキュアリンクを介して認証リクエストを送信し、
前記コマースゲートウェイが前記認証リクエストを受信したことに応じて、当該コマースゲートウェイにより保持される有効な仮想支払アカウントが前記買い手コンピュータに関連しているか否かを決定し、
有効な仮想支払アカウントが前記買い手コンピュータに関連していることの決定に応じて、アカウント識別子を前記買い手コンピュータに返信し、
前記売り手コンピュータが前記買い手コンピュータから前記アカウント識別子を受信したことに応じて、前記コマースゲートウェイから有効なトランザクション許可を取得し、
前記売り手コンピュータが前記有効なトランザクション許可を受信したことに応じて、製品購入が成立する、方法。
【請求項１０】
前記コマースゲートウェイに保持された有効な仮想支払アカウントが前記買い手コンピュータに関連しているか否かの決定は、
前記買い手コンピュータから前記認証リクエストを前記コマースゲートウェイに送信し、
前記コマースゲートウェイにおいて有効な仮想支払アカウントが前記買い手コンピュータに関連しているか否を決定し、
前記買い手コンピュータが前記有効な仮想支払アカウントに関連していることの決定に応じて、アカウント識別コンテナを前記買い手コンピュータに送信する、請求項９に記載の方法。
【請求項１１】
前記認証リクエストはデジタル証明書を含んでいる、請求項１０に記載の方法。
【請求項１２】
前記コマースゲートウェイから有効なトランザクション許可を取得することは、
前記売り手コンピュータにおいて前記アカウント識別コンテナを受信し、
前記アカウント識別コンテナ及び製品のコストを前記売り手コンピュータから前記コマースゲートウェイに送信し、
前記仮想支払アカウントに製品のコストの請求ができるか否かを決定し、
前記仮想支払アカウントに製品のコストの請求ができるという決定に応じて、有効なトランザクション許可を前記コマースゲートウェイから前記売り手コンピュータに送信する、請求項１０に記載の方法。
【請求項１３】
前記仮想支払アカウントがメインアカウント及び少なくとも１つのサブアカウントを有する請求項１０に記載の方法。
【請求項１４】
前記サブアカウントが、所定のリストにある商用サーバからの請求のみを受け取る請求項１３に記載の方法。
【請求項１５】
消費リミットが、前記サブアカウントに対して設定される、請求項１３に記載の方法。
【請求項１６】
買い手コンピュータ、売り手サーバ、及びコマースゲートウェイに格納され、前記売り手サーバからの製品購入のために実行可能なコンポーネントを備えたコンピュータ読取り可能な媒体であって、
前記製品購入のために実行可能なコンポーネントは、
前記売り手サーバが前記買い手コンピュータから製品を購入するためのリクエストを受信したことに応じて、前記売り手サーバが前記買い手コンピュータに購入オファーを返信し、
前記買い手コンピュータが前記購入オファーを受信したことに応じて、前記買い手コンピュータは製品を購入するための支払い源として仮想支払アカウントを識別すると共に認証リクエストをコマースゲートウェイに送信し、前記買い手コンピュータは当該仮想支払アカウントに関連するデジタル証明書を検索することで製品の支払い源としての仮想支払アカントを識別し、前記デジタル証明書は前記コマースゲートウェイに送信される認証リクエストに含まれており、
前記コマースゲートウェイにおいて前記仮想支払アカウントが前記買い手コンピュータに関連しているか及び前記仮想支払アカウントが有効であるかを決定し、
前記仮想支払アカウントが前記買い手コンピュータに関連しており、かつ、前記仮想支払アカウントが有効である場合には、前記コマースゲートウェイはアカウント識別コンテナを前記買い手コンピュータに送信し、
前記買い手コンピュータが前記アカウント識別コンテナを受信したことに応じて、前記買い手コンピュータは、前記アカウント識別コンテナを含む購入コンファメーションを前記売り手サーバに送信し、
前記購入コンファメーションを受信したことに応じて、前記売り手サーバは許可リクエストを前記コマースゲートウェイに送信し、
前記コマースゲートウェイが前記許可リクエストを受信したことに応じて、当該コマースゲートウェイは前記仮想支払アカウントを製品の支払いに用いることができるかを決定し、
前記コマースゲートウェイが前記仮想支払アカウントを製品の支払いに用いることができるとの決定に応じて、前記コマースゲートウェイは当該コマースゲートウェイからトランザクション許可を前記売り手サーバに送信すると共に前記製品に関するコストを前記仮想支払アカウントに請求し、
前記売り手サーバが前記トランザクション許可を受信したことに応じて、当該売り手サーバは前記買い手コンピュータに関連した買い手に前記製品を提供する準備を行う、コンピュータ読取り可能な媒体。
【請求項１７】
前記デジタル証明書は前記買い手コンピュータに格納されている、請求項１６に記載のコンピュータ読取り可能な媒体。
【請求項１８】
前記デジタル証明書は、保証トークンから検索される、請求項１６に記載のコンピュータ読取り可能な媒体。
【請求項１９】
前記買い手コンピュータが前記製品の支払い源として前記仮想支払アカウントを識別できない場合には、前記買い手コンピュータは代替の識別のエントリを要求し、
前記代替の識別がエントリされた場合には、前記買い手コンピュータは、前記認証リクエストに代えて代替認証リクエストを前記コマースゲートウェイに送信し、
前記コマースゲートウェイにおいて代替支払アカウントが買い手と関連しているか否か決定し、
代替支払アカウントが買い手と関連している場合には、前記コマースゲートウェイはアカウント識別コンテナを買い手コンピュータに送信する、請求項１６に記載のコンピュータ読取り可能な媒体。
【請求項２０】
前記実行可能なコンポーネントは、
前記買い手からアプリケーションデータを前記コマースゲートウェイに送信し、
前記コマースゲートウェイがアプリケーションデータを受信したことに応じて、当該コマースゲートウェイは前記アプリケーションデータに基づいて前記買い手に対するクレジットスコアを決定し、
前記コマースゲートウェイが買い手のクレジットスコアを決定したことに応じて、当該コマースゲートウェイは前記クレジットスコアがしきいクレジットスコアを超えるか否かを決定し、
前記コマースゲートウェイによる前記クレジットスコアが前記しきいクレジットスコアを超えることの決定に応じて、当該コマースゲートウェイは前記買い手に関連する仮想支払アカウント確立し、
前記仮想支払アカウントの登録所有者として前記買い手を識別するデジタル証明書を前記買い手コンピュータにインストールすることにより、
製品の支払いに用いられ得る仮想支払アカウントを生成する、請求項１６に記載のコンピュータ読取り可能な媒体。
【請求項２１】
前記買い手コンピュータが前記製品の支払い源として前記仮想支払アカウントを識別できない場合には、前記買い手コンピュータは代替の識別のエントリを要求し、
前記代替の識別がエントリされた場合には、前記買い手コンピュータは、前記認証リクエストに代えて代替認証リクエストを前記コマースゲートウェイに送信し、
前記コマースゲートウェイにおいて代替支払アカウントが買い手と関連しているか否か決定し、
代替支払アカウントが買い手と関連している場合には、前記コマースゲートウェイはアカウント識別コンテナを前記買い手コンピュータに送信する、請求項２０に記載のコンピュータ読取り可能な媒体。
【請求項２２】
前記デジタル証明書は前記買い手コンピュータに格納されている、請求項２０に記載のコンピュータ読取り可能な媒体。
【請求項２３】
前記デジタル証明書は保証トークンから検索される、請求項２０に記載のコンピュータ読取り可能な媒体。
【請求項２４】
前記実行可能なコンポーネントは、
前記コマースゲートウェイが買い手からアプリケーションデータを受信したことに応じて、当該コマースゲートウェイは当該買い手のアイデンティティスコアを決定し、
前記コマースゲートウェイが前記アプリケーションデータに基づいて前記買い手に対するアイデンティティスコアを決定することに応じて、当該コマースゲートウェイは、前記アイデンティティスコアがしきいアイデンティティスコアを超えるか否かを決定し、
前記コマースゲートウェイによる前記アイデンティティスコアが前記しきいアイデンティティスコアを超えることの決定に応じて、当該コマースゲートウェイはクレジットスコアの決定を行うことにより、仮想支払アカウントを生成する、請求項２０に記載のコンピュータ読取り可能な媒体。
【請求項２５】
前記デジタル証明書は前記買い手コンピュータに格納されている、請求項２４に記載のコンピュータ読取り可能な媒体。
【請求項２６】
前記デジタル証明書は保証トークンから検索される、請求項２４に記載のコンピュータ読取り可能な媒体。
【請求項２７】
前記実行可能なコンポーネントは、
前記コマースゲートウェイが前記売り手サーバから決済トランザクションリクエストを受信したことに応じて、当該コマースゲートウェイは当該決済トランザクションリクエストを許容できるか決定し、
前記コマースゲートウェイによる前記決済トランザクションリクエストが許容できることの決定に応じて、当該コマースゲートウェイは前記決済トランザクションリクエストの処理を行い、
前記コマースゲートウェイが前記決済トランザクションリクエストの処理を行うことに応じて、前記売り手サーバに関連する売り手のアカウントを調整することにより、仮想支払アカウントトランザクションの決済を行う、請求項１６に記載のコンピュータ読取り可能な媒体。
【請求項２８】
前記デジタル証明書は前記買い手コンピュータに格納されている、請求項２７に記載のコンピュータ読取り可能な媒体。
【請求項２９】
前記デジタル証明書は保証トークンから検索される、請求項２７に記載のコンピュータ読取り可能な媒体。
【請求項３０】
前記買い手コンピュータが前記製品の支払い源として前記仮想支払アカウントを識別できない場合には、前記買い手コンピュータは代替の識別のエントリを要求し、
前記代替の識別がエントリされた場合には、前記買い手コンピュータは、前記認証リクエストに代えて代替認証リクエストを前記コマースゲートウェイに送信し、
前記コマースゲートウェイにおいて代替支払アカウントが買い手と関連しているか否か決定し、
代替支払アカウントが買い手と関連している場合には、前記コマースゲートウェイはアカウント識別コンテナを前記買い手コンピュータに送信する、請求項２７に記載のコンピュータ読取り可能な媒体。
【請求項３１】
前記実行可能なコンポーネントは、
前記買い手からアプリケーションデータを前記コマースゲートウェイに送信し、
前記コマースゲートウェイがアプリケーションデータを受信したことに応じて、当該コマースゲートウェイは前記アプリケーションデータに基づいて前記買い手に対するクレジットスコアを決定し、
前記コマースゲートウェイが買い手のクレジットスコアを決定したことに応じて、当該コマースゲートウェイは前記クレジットスコアがしきいクレジットスコアを超えるか否かを決定し、
前記コマースゲートウェイによる前記クレジットスコアが前記しきいクレジットスコアを超えることの決定に応じて、当該コマースゲートウェイは買い手に関連する仮想支払アカウント確立し、
前記仮想支払アカウントの登録所有者として前記買い手を識別するデジタル証明書を前記買い手コンピュータにインストールすることにより、製品の支払いに用いられ得る仮想支払アカウントを生成する、請求項３０に記載のコンピュータ読取り可能な媒体。
【請求項３２】
前記デジタル証明書は前記買い手コンピュータに格納されている、請求項３１に記載のコンピュータ読取り可能な媒体。
【請求項３３】
前記デジタル証明書は保証トークンから検索される、請求項３１に記載のコンピュータ読取り可能な媒体。
【請求項３４】
前記実行可能なコンポーネントは、
前記コマースゲートウェイが買い手からアプリケーションデータを受信したことに応じて、当該コマースゲートウェイは買い手のアイデンティティスコアを決定し、
前記コマースゲートウェイが前記アプリケーションデータに基づいて前記買い手に対するアイデンティティスコアを決定することに応じて、当該コマースゲートウェイは前記アイデンティティスコアがしきいアイデンティティスコアを超えるか否かを決定し、
前記コマースゲートウェイによる前記アイデンティティスコアが前記しきいアイデンティティスコアを超えることの決定に応じて、当該コマースゲートウェイはクレジットスコアの決定を行うことにより、仮想支払アカウントを生成する、請求項３０に記載のコンピュータ読取り可能な媒体。
【請求項３５】
前記デジタル証明書は前記買い手コンピュータに格納されている、請求項３４に記載のコンピュータ読取り可能な媒体。
【請求項３６】
前記デジタル証明書は保証トークンから検索される、請求項３４に記載のコンピュータ読取り可能な媒体。
【発明の詳細な説明】
【０００１】関連出願の参照
本願は、先願である1999年8月9日に出願された米国特許出願第09/140,949号の一部継続出願であり、米国特許法第120条に基づき、当該出願の出願日に基づきここに優先権主張する。また本願は、米国特許法第119条に基づき、1999年6月18日に出願された仮出願第60/140,039号に基づく優先権も主張する。
【０００２】発明の分野
本発明は一般に、共通の通信リンクを介して接続された１以上の他のコンピュータから商品、サービスおよびコンテンツを注文するための方法および装置、より詳細には、仮想支払アカウントを用いてインターネットに接続されたコンピュータから商品、サービスおよびコンテンツを注文するための方法および装置に関する。
【０００３】発明の背景
通信ネットワークは、コンピュータ通信分野において周知である。定義として、ネットワークとは、通信機能（communications facilities）またはリンクによって接続されるコンピュータおよび関連機器からなる１つのグループである。ネットワーク通信は、ケーブルを介するもの等の永久的な性質のものであってもよいし、あるいは電話や無線のリンクを介して行われる接続などの一時的な性質のものであってもよい。ネットワークのサイズは、少数のコンピュータもしくはワークステーションおよび関連機器からなるローカルエリアネットワーク（LAN）から、地理的に分散されたコンピュータおよびLANを相互に接続する広域ネットワーク（WAN）、一時的通信リンクを介して遠隔コンピュータを相互接続する遠隔アクセスサービス（RAS）まで、様々である。次に、インターネットワークは様々なネットワークからのデータの転送および交換を容易にするゲートウェイまたはルーターを使って複数のコンピュータネットワーク（同種および異種ネットワークの両方）をつなげたものである。インターネットワークという用語の代わりに用いられる周知の略語は「インターネット（Internet）」である。現在理解されている通り、大文字で書かれた「インターネット（Internet）」という用語は、伝送制御プロトコル/インターネットプロトコル（TCP/IP）を使用して互いに通信するネットワークおよびルーターの集合を指す。
【０００４】  インターネット40の代表的なセクションを図１に示す（従来技術）。図１では、複数のローカルエリアネットワーク（LAN）44および広域ネットワーク（WAN）46がルーター42によって相互に接続されている。ルーター42は一般に１つのLANまたはWANを他のLANまたはWANにインターフェース接続するために使用される専用コンピュータである。LAN内の通信リンクは、撚線対または同軸ケーブルであっても良く、ネットワーク間の通信リンクは56Kbpsのアナログ電話回線、または1MbpsのデジタルT-1回線および/または45MbpsのT-3回線を利用するものであってもよい。さらに、コンピュータおよび他の関連電子機器は、モデムおよび一時的電話リンクを介して遠くにあるLAN 44またはWAN 46に接続されることができる。このようなコンピュータおよび電子装置48が破線によってLAN 44のうちの１つに接続されているところを図１に示す。インターネットが膨大な数のこのような相互接続されたネットワーク、コンピュータおよびルーターを含むこと、ならびにインターネット40のごく小さな代表的なセクションのみが図１に示されていることを理解されたい。
【０００５】  インターネットは、世界中にあるコンピュータをリンクすることができるその機能によって、近年爆発的な成長を遂げた。インターネットが広まるにつれ、ワールド・ワイド・ウェブ（WWW）も広まった。WWWは、インターネット中の「ウェブサイト」に電子的に格納されるハイパーテキスト作成言語（HTML）で書かれた相互接続されたまたは「ハイパーテキスト」文書（「ウェブページ」としても知られている）の膨大な集合である。ウェブサイトは、インターネットに接続されたハイパーテキスト文書を格納するための大容量記憶装置を有するサーバであり、これらの格納されたハイパーテキスト文書に対するリクエストを処理するための管理ソフトウェアを実行する。ハイパーテキスト文書は通常多数のハイパーリンク（すなわちその文書をインターネット上のどこかのウェブサイトに格納されているかもしれない他のハイパーリンク文書にリンクするハイライト部分）を含む。各ハイパーリンクは、インターネットに接続されたサーバ上のリンクされた文書の正確な位置を提供するユニフォーム・リソース・ロケータ（Uniform Resource Locator, URL）に関連している。したがって、任意のウェブサーバからハイパーテキスト文書が検索されるときは常に、その文書はWWWから検索されたものとみなされる。
【０００６】  ユーザは、WWWからハイパーテキスト文書を検索することができる。すなわち、ユーザは、ウェブブラウザを介して「ウェブをサーフ（surf the Web）」することができる。NETSCAPE NAVIGATOR（登録商標）やMICROSOFT（登録商標）インターネットエクスプローラ等のウェブブラウザは、WWWにグラフィカル・ユーザ・インターフェースを提供するためにウェブ・クライアント（すなわちユーザのコンピュータ）によって実行されるソフトウェアプログラムである。ウェブブラウザを介してユーザからリクエストがあると、ウェブ・クライアントは、その文書のURLおよびハイパーテキスト転送プロトコル（HTTP）として知られるプロトコルを用いて適当なウェブサーバからの所望のハイパーテキスト文書またはウェブページにアクセスし検索する。HTTPはTCP/IPよりも高いレベルのプロトコルであり、特にWWWの必要条件に合わせて設計される。これは、TCP/IPの上でサーバとクライアントとの間でハイパーテキスト文書を転送するために使用される。
【０００７】  WWWが現れた当初は、インターネット上に格納された情報は、その情報に興味を持つこれらの当事者の間で自由に相互に転送されていた。しかし、間もなくWWWが商業活動の手段となり、これによって沢山の企業は彼らの商品およびサービスを宣伝および販売するために彼ら独自のウェブサイトを開発した。接続されたコンピュータによって行われる商業活動は、電子的商取引すなわちe-コマースとして知られ、オンライン情報サービス、インターネット、掲示板システム（BBS）を介して買い手と売り手との間で、または電子データ交換（EDI）を介して買い手のコンピュータと売り手のコンピュータとの間で行うことができる。買い手（e-コマースとの関連上、ユーザ、カスタマーまたは買い手とも呼ばれる）は、企業または売り手の「ウェブサイトを訪れ」（すなわち、特定の売り手のウェブサーバ上にあるハイパーテキスト文書を検索し）、その売り手が提供する商品またはサービスを注文することができる。その商品またはサービスが電子的に格納された情報である場合（例えば本、ビデオ、コンピュータゲーム等）、買い手はその企業のウェブサイトからその商品またはサービスを彼もしくは彼女のコンピュータに単にダウンロードしてすぐに消費および使用することができる。その商品またはサービスがより実体的なものである場合（例えばオンラインカタログで注文した器具や衣類等）、もっと伝統的な受渡し方法（例えば郵便サービスまたは一般的な運送業者等）が使用される。
【０００８】  e-コマース購入のための一般的な支払方法は、電子クレジットまたはe-クレジットである。e-クレジットは、インターネット上で行われるクレジットカードトランザクションをしばしば含む電子的コマースの形態である。伝統的なe-クレジット購入は、大手のクレジットカードによって支払われ、この場合は、買い手は彼もしくは彼女のクレジット情報（例えばアカウント番号および有効期限日）をインターネット上でその企業のウェブサイトに送る必要がある。多くの買い手はこのような電子送信の安全性および機密性について心配している。さらに、多くの買い手は、このような購入を行うための大手のクレジットカードを持っていない。他の請求方法（例えばファクシミリや郵便サービスによってクレジット情報を提供する等）はあまり便利ではなく、全体的に見て販売を妨げる十分な障害となることが多いことが分かっている。最後に、伝統的な請求および支払い方法では、不正な購入から売り手または買い手を十分に保護できない。
【０００９】  したがって、ネットワーク（および最終的にはインターネット）上で商品、サービスおよびコンテンツを注文および請求するためのより効果的な方法および装置が必要である。この方法および装置は、不正な購入から売り手および買い手を保護しなければならない。さらに、この方法および装置は、全てのトランザクションに否認防止の要素（an element of non-repudiation）を提供しなければならない。また、この方法および装置は、不払いの経歴を持つ買い手がさらに商品、サービスおよび／またはコンテンツを購入するのを防止しなければならない。最後に、この方法および装置は、大手のクレジットカードを持たない買い手が商品、サービスおよびコンテンツをインターネット上で購入できるようにしなければならない。
【００１０】発明の概要
本発明は、インターネットに接続されたコンピュータから商品を注文するためのコンピュータプログラムであって、注文された商品、サービスまたはコンテンツに対して、コマースゲートウェイ（commerce gateway）によって維持された仮想支払アカウントに基づいて買い手が自動的に請求を受けるようなプログラムを提供する。
【００１１】  本発明の他の態様に従って、コマースゲートウェイは、商品、サービスおよび／またはコンテンツの購入に関わる金融的状況を扱うクレジット処理サーバにインターフェース接続する。このクレジット処理サーバは、買い手のアカウントを実際に扱う１以上の金融機関にインターフェース接続する。例えば、買い手は、そのコマースゲートウェイのプロバイダに、その買い手が金融機関で持っている銀行アカウントから購入に対して電子送金することにより、またはチェックを送ることによりその購入に対して前払いすることにより、支払うこともできる。あるいは、仮想支払アカウントを用いて蓄積した報酬ポイントを購入に当てることができる。
【００１２】  本発明のさらに他の態様に従って、クレジット処理サーバまたはコマースゲートウェイは、仮想支払アカウントを作成する前に買い手のアイデンティティを確認するために、１つ又は２以上のアイデンティティビューロー（identity bureau）に連絡をとる。
【００１３】  本発明のさらに他の態様に従って、クレジット処理サーバは、買い手の仮想支払アカウントの信用限度額（credit limit）を決定するために、１つ又は２以上のアイデンティティビューローに連絡をとる。
【００１４】  本発明のさらに他の態様に従って、仮想支払アカウントは関連するサブアカウントを持つことができる。サブアカウントはメインアカウントの信用限度額よりも少ない信用限度額を持つことができる。サブアカウントは、商品、サービスおよび／またはコンテンツを購入することができる売り手のサイトを制限することができる。
【００１５】  本発明のさらなる態様に従って、購入は、登録された売り手から登録された買い手によって行われなければならない。安全性は、その当事者のトランザクションを認証することによって確保される。認証（authentication）は、デジタル証明書（degital certificate）もしくはデジタル署名の照合（verification）によって、または他の認証方法によって行うことができる。
【００１６】  本発明の前述の態様および付随する多くの利点は、添付の図面と一緒に以下の詳細な説明を参照することによってより深くこれらを理解することにより、より簡単に認識できるであろう。
【００１７】好適な実施形態の詳細な説明
既に記載されかつ図１に示すように、インターネット４０は、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）を用いて互いに通信するローカルエリアネットワーク（ＬＡＮｓ）４４、ワイドエリアネットワーク（ＷＡＮｓ）４６、リモートコンピュータ４８、ルーター４２の集合である。一方、ワールドワイドウェブ（ＷＷＷ）は、インターネット４０中のいたるところで接続されているサーバに存在し、相互接続された電子的に保存されている情報の莫大な集合である。今や、多くの企業が、商品、サービス、有料コンテンツへのアクセスを、ＷＷＷを用いてインターネットで販売している。本発明によると、買い手は商品、サービス、および／またはコンテンツ（これらのものは「製品」と置き換えることができる）、をウェブブラウザからインターネットを介して注文し、アカウント番号や有効期限のようなセンセィティブなアカウント情報を送信することなく、インターネット４０を通して、仮想支払いアカウントを用いて購入に対して自動的な請求が行なわれる。仮想支払いアカウントは、買い手をして、プリペイドあるいはクレジットアカウントを用いて仮想支払いアカウントの取引を決済することを可能とする。本発明の一つの実施例では、仮想支払いアカウントは、例えば、ナショナルオートメイテットクリアリングハウス（ＮＡＣＨＡ）、電子コマース取引標準を促進する標準グループ、によって維持されたオートメイテットクリアリングハウス（ＡＣＨ）、を用いて、銀行電子ファンド転送を用いている。他の実施例では、仮想支払いアカウントは、例えばポスタルサービスを用いて、買い手がチェックを仮想支払いシステムのプロバイダに郵送することによって、従来のペーパーチェックによって資金を賄うこともできる。あるいは、ＣＨＥＣＫＦＲＥＥ（商標）のような、ファンド転送サービスおよび電子請求支払いサービスを用いてもよい。仮想支払いアカウントを使用することによって獲得された報酬ポイントも買い手の仮想支払いアカウントに適用されて製品の支払いに用いられる。
【００１８】さらに詳しくは、図２に示すように、買い手は、インターネット４０に接続されたコンピュータ５０から売り手のサーバに注文を出すことで、商品、サービス、および／あるいは有料コンテンツを、売り手のサーバ５１、すなわち、製品をスポンサーし、あるいは販売する売り手によって所有されるコンピュータ、から購入する。発注はインターネット４０のどこかに配設されたＬＡＮ４４に接続するコマースゲートウェイ５２によって処理され再確認される。コマースゲートウェイ５２はＬＡＮ４４を介してクレジット処理サーバ５３に接続されている。クレジット処理サーバ５３は一つあるいは複数のアイデンティティビューロー５６と通信することで、買い手のアイデンティティを認証する。買い手のアイデンティティを認証すると、クレジット処理サーバ５３は一つあるいは複数のクレジットビューロー５８と通信して、買い手のクレジット価値を決定する。
【００１９】ここに述べられる本発明の一つの実施例では、アイデンティティビューロー５６は買い手のアイデンティティを認証するためのエージェンシーによって提供され維持されるサーバであり、クレジットビューロー５８は買い手のクレジットレポートを処理するエージェンシーによって提供され維持されるサーバである。アイデンティティビューロー５６およびクレジットビューロー５８はＬＡＮ４４上に配置されてもよく、あるいはインターネット４０上の他の場所に配置されてもよい。
【００２０】他の実施例では、クレジット処理サーバは、ＬＡＮ４４あるいはインターネット４０のいずれにも接続されていないリモートアイデンティティビューロー、あるいはクレジットビューローとポイント−ポイント接続を確立するものであってもよい。クレジット処理サーバ５３とアイデンティティビューロー５６あるいはクレジットビューロー５８との間の他の通信手法、例えば、それぞれ、アイデンティティチェッキング、クレジット格付けのみを目的とするアイデンティティビューローあるいはクレジットビューローによって維持され運営される安全な（暗号化された）バーチャルプライベートネットワーク（ＶＰＮ）、が用いられることは理解される。
【００２１】最後に、さらに他の実施例として、アイデンティティおよびクレジットビューローは実際にサーバを全く提供しないものであってもよい。アイデンティティあるいはクレジットビューローのためのカスタマサービス代表がアイデンティティおよびクレジットレポートを処理し、本発明の管理者にマニュアルでレポートを提供し、該管理者はマニュアルでクレジット処理サーバ５３にレポートを入力する。
【００２２】クレジット処理サーバ５３は、買い手の支払いを獲得するために、すなわち、製品を購入するため資金の転送、一つあるいは複数の金融機関と通信する。アイデンティティおよびクレジットビューロー５８の場合には、金融機関５９は、クレジット処理サーバ５３と電子通信する他のサーバ、クレジット処理サーバ５３とより伝統的な通信を行うカスタマサービス代表、あるいはこれらの組み合わせである。
【００２３】最後に、コマースゲートウェイ５２に加えて、ＬＡＮ４４は、買い手および売り手の情報、コマースゲートウェイ５２によって提供されたサービス、およびクレジット処理サーバ５３を管理するために用いられる管理コンピュータ５４を含んでいる。
【００２４】図２に示す本発明の実施例では、ＬＡＮ４４はそこを通る全てのデータの流れを追跡しかつ制御するファイヤーウォール５５によってインターネット４４から隔離されている。ファイヤーウォール５５は、悪意を持ったインバウンドデータトラフィックからＬＡＮ４４を保護する。ＬＡＮ４４は様々なコンピュータおよびサーバを相互に連結するバスネットワークである。図２に示すＬＡＮ４４は、ガラスあるいはプラスチックの光ファイバケーブル、同軸ケーブル、ツイストワイヤペアケーブル、リボンケーブル等の数々の接続媒体によって形成される。さらに、当業者にとって、接続媒体は、ラジオ周波数接続媒体あるいは他の目に見えない接続媒体が含まれることは理解される。これらに限定されないが、必要なインターフェースハードウェアを備えたワークステーション、パーソナルコンピュータ、ラップトップコンピュータ、パーソナルデータアシスタント、サーバ、リモートコンピュータ等を含むいかなるコンピュータシステムあるいは複数のコンピュータシステムが一時的あるいは永続的にＬＡＮ４４、したがってインターネット４０、に接続されてもよい。しかしながら、電話回線を介してＬＡＮ４４に連結された他の装置へ一時的な接続を行なう場合には、リモートコンピュータ４８およびそれに接続された該装置の双方のインターフェースハードウェアはモデムを有している必要がある。
【００２５】また図２には、認証装置２０５が例示されており、この目的は以下に詳細に説明される。本発明の一つの実施例では、認証装置は無線モデムを備えたパーソナルデータアシスタント（ＰＤＡ）である。しかしながら、認証装置は、ラップトップコンピュータ、携帯電話、ペイジャ、あるいはリモートメッセージを受信することができるいかなる装置であってもよいことは当業者に理解される。
【００２６】最後に、図２では、一つの買い手コンピュータ５０、一つの売り手サーバ５１が示してあるが、下記のハードウエアおよびソフトウエアコンポーネントを備えた多くの買い手コンピュータおよび売り手サーバがインターネット４０に接続されることは当業者に理解される。また、ここにおける「買い手」という用語は、商品および／あるいはサービスのいかなる購入に対しても適用され、そして、個人、非商業的購入者、ビジネスあるいは商業的購入者に対して同等に適用される。換言すれば、「買い手」という言葉はいかなる買い手にも適用され、「売り手」という言葉は、いかなる売り手、あるいはマーチャントに適用され、個人、非商業的売り手、ビジネスあるいは商業的売り手を問わない。
【００２７】関連した買い手コンピュータ、売り手サーバ、コマースゲートウェイ、
およびクレジット処理サーバコンポーネント
図３は買い手コンピュータ５０の重要な構成要素の幾つかを示している。当業者において、買い手コンピュータ５０は、買い手の仮想支払いアカウントを用いるために買い手によって使用されるいかなるコンピュータであってもよい。さらに、当業者において、買い手コンピュータ５０は図３に示したものの他に数多くの構成要素を有している。しかしながら、本発明の実施の例示を開示するために、これらの全ての従来の構成要素を示す必要はない。図３に示すように、買い手のコンピュータはＬＡＮ４４あるいはＷＡＮ４６に接続するため、あるいはＬＡＮあるいはＷＡＮに遠隔的に接続するためのネットワークインターフェース６０を含んでいる。ネットワークインターフェース６０はこのような接続のために必要な回路を有しており、そして、ＴＣＰ／ＩＰプロトコール、それが接続されているＬＡＮあるいはＷＡＮの特有の構成態様、および特有なタイプの接続媒体、と共に使用されるように構成されることは当業者に理解される。
【００２８】買い手コンピュータ５０は処理装置６１、ディスプレイ６２およびメモリ６３を有している。メモリ６３は一般にランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、およびディスクドライブのような永久容量記憶装置を含んでいる。メモリ６３は本発明にしたがってインターネット４０を介して製品を発注して支払うために必要なプログラムコードおよびデータを格納している。さらに詳しくは、メモリ６３はネットスケープナビゲータ（商標）やマイクロソフト（商標）インターネットエクスプロ−ラのようなウェブブラウザ６４、および、いかなる仮想支払いアカウント決済を実行する前に、買い手が仮想支払いシステムの登録された参加者であることを確認するために本発明にしたがって形成された買い手オーセンティケータコンポーネント６５を有している。これらのコンポーネントは、コンピュータ読み出し可能媒体に格納され、フロッピードライブやＤＶＤ／ＣＤ−ＲＯＭドライブのような該コンピュータ読み出し可能媒体と関連したドライブ機構を用いることによって、買い手コンピュータ５０のメモリ６３に読み込むこともできることは理解される。
【００２９】以下により詳細に述べるように、買い手によって発注された製品は、例えば図２に示すＬＡＮ４４のようなインターネットのいずれかに置かれたリモートサーバ、すなわち、後で述べるコマースゲートウェイ５２からの認証に引き続いて、次に述べるように、売り手サーバ５１によって供給される。図４は、売り手サーバ５１の重要な構成要素の幾つかを図示している。売り手サーバ５１は図４に示したもの以外にもさらに多くの構成要素を含んでいることは当業者にとって理解される。しかしながら、本発明を実行する実施例を開示するためにはこれらの全ての従来の構成要素を示す必要がない。図４に示すように、売り手サーバ５１はＬＡＮ４４あるいはＷＡＮ４６に接続するため、あるいはＬＡＮあるいはＷＡＮに遠隔的に接続するためのネットワークインターフェース７０を含んでいる。ネットワークインターフェース７０はこのような接続のために必要な回路を有しており、そして、ＴＣＰ／ＩＰプロトコール、それが接続されているＬＡＮあるいはＷＡＮの特有の構成態様、および特有なタイプの接続媒体、と共に使用されるように構成されることは当業者に理解される。
【００３０】売り手コンピュータ５１は処理装置７１、ディスプレイ７２およびメモリ７３を有している。メモリ７３は一般にランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、およびハードディスクドライブ、テープドライブ、オプティカルドライブ、フロッピーディスクドライブ、これらの組み合わせのような永久容量記憶装置を含んでいる。本発明の一つの実施例では、メモリは買い手からの電子的に発注された商品あるいはサービスを含む製品データベース７４を含んでいる。本発明の他の実施例では、製品データベース７４は、買い手によって発注された有料コンテンツ、すなわち、売り手にとって金銭的価値があると考えられるハイパーテキストドキュメントや他の電子的に格納された情報を格納している。本発明のさらに他の実施例では、商品は電子的に格納することができない有体物であり、この場合は、製品データベースは製品を説明する情報を含んでいる。
【００３１】メモリ７３はまた売り手のウェブサイトから製品を購入するためのコマースエンジンコンポーネント７５を含んでいる。コマースエンジンコンポーネント７５は、ＶＩＳＡ（商標）やＭＡＴＥＲＣＡＲＤ（商標）のようなメジャーなクレジットカードを用いてインターネットを通して発注した製品の支払いを可能とするような、マイクロソフト（商標）サイトサーバのような、現存するコマースエンジンであってもよい。コマースゲートウェイアダプタコンポーネント７６が、コマースエンジンコンポーネント７５がコマースゲートウェイ５２とインターフェイスするために提供される。また、メモリには、売り手が本発明の仮想支払いシステムのオーソライズされた、すなわち登録された売り手であることを認証するための売り手オーセンティケータコンポーネント７７が含まれている。製品データベース７４、コマースエンジンコンポーネント７５、コマースゲートウェイアダプタコンポーネント７６および売り手オーセンティケータコンポーネント７７は、コンピュータ読み出し可能媒体に格納され、フロッピードライブやＤＶＤ／ＣＤ−ＲＯＭドライブのような該コンピュータ読み出し可能媒体と関連したドライブ機構を用いることによって、売り手コンピュータ５１のメモリ７３に読み込むこともできることは理解される。最後に、メモリ７３は、インターネットおよびＷＷＷを介して受信した格納された情報の要求を取り扱うためのウェブサーバコンポーネント７８を格納している。
【００３２】図５は、コマースゲートウェイ５２の重要なコンポーネントの幾つかを示している。コマースゲートウェイ５２は図５に示したもの以外にもさらに多くの構成要素を含んでいることは当業者にとって理解される。しかしながら、本発明を実行する実施例を開示するためにはこれらの全ての従来の構成要素を示す必要がない。図５に示すように、コマースゲートウェイ５２はネットワークインターフェース８０を介してＬＡＮ４４に接続される。ネットワークインターフェース８０はコマースゲートウェイ５２をＬＡＮ４４およびファイヤーウォール５５に接続するために必要な回路を有しており、そして、ＴＣＰ／ＩＰプロトコール、ＬＡＮ４４の特有の構成態様、および特有なタイプの接続媒体、と共に使用されるように構成されることは当業者に理解される。
【００３３】コマースゲートウェイ５２は処理装置８１、ディスプレイ８２およびメモリ８３を有している。メモリ８３は一般にランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、およびハードディスクドライブ、テープドライブ、オプティカルドライブ、フロッピーディスクドライブ、これらの組み合わせのような永久容量記憶装置を含んでいる。メモリ８３は、売り手サーバ５１を認可して買い手に製品を供給し、本発明にしたがってクレジット処理サーバ５３を介して製品の支払いを獲得するために必要なプログラムコードおよびデータを格納している。さらに詳しくは、メモリ８３は、売り手が発注された製品を供給することをオーソライズし、クレジット処理サーバ５３から発注された製品の支払いを獲得するために、本発明にしたがって形成されたトランザクションサーバコンポ−ネント８４を格納している。メモリ８３はさらに、買い手あるいは売り手のアイデンティティを認証するために本発明にしたがって形成されたアイデンティティビューローアダプタ７９を含んでいる。また、メモリ８３には、申請者のクレジット価値を決定するために本発明にしたがって形成された登録サーバコンポーネント８９を格納している。メモリ８３には、内部アカウントアイデンティフィケーションを決定するための、アカウントアイデンティフィケーションコンテナ生成コンポーネント８８が格納されている。メモリ８３には、レポートのためのリクエストを処理し、要求されたレポートの情報を整理統合するための、レポートサーバ８５が格納されている。メモリ８３には、以下に述べるクレジット処理サーバ５３と通信するための、クレジット処理サーバアダプタコンポーネント８６が格納されている。トランザクションサーバコンポーネント８４、クレジット処理サーバアダプタコンポーネント８６、アカウントアイデンティフィケーションコンテナ生成コンポーネント８８、および登録サーバコンポーネント８９は、コンピュータ読み出し可能媒体に格納され、フロッピードライブやＣＤ−ＲＯＭドライブのような該コンピュータ読み出し可能媒体と関連したドライブ機構を用いることによって、コマースゲートウェイ５２のメモリ８３に読み込むこともできることは理解される。最後に、メモリ８３は、インターネット４０およびＷＷＷを介して受信した格納された情報の要求を取り扱うためのウェブサーバコンポーネント８７を格納している。
【００３４】図６は、クレジット処理サーバ５３の重要な構成要素の幾つかを図示している。クレジット処理サーバ５３は図６に示したもの以外にもさらに多くの構成要素を含んでいることは当業者にとって理解される。しかしながら、本発明を実行する実施例を開示するためにはこれらの全ての従来の構成要素を示す必要がない。図６に示すように、クレジット処理サーバ５３はネットワークインターフェース９０を介してＬＡＮ４４に接続されている。ネットワークインターフェース９０はクレジット処理サーバ５３をＬＡＮ４４およびファイヤーウォール５５に接続するために必要な回路を有しており、そして、ＴＣＰ／ＩＰプロトコール、ＬＡＮ４４の特有の構成態様、および特有なタイプの接続媒体、と共に使用されるように構成されることは当業者に理解される。
【００３５】クレジット処理サーバ５３は処理装置９１、ディスプレイ９２およびメモリ９３を有している。メモリ９３は一般にランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、およびハードディスクドライブ、テープドライブ、オプティカルドライブ、フロッピーディスクドライブ、これらの組み合わせのような永久容量記憶装置を含んでいる。メモリ９３は、本発明にしたがう仮想支払いアカウントを用いた購入された商品の支払いをオーソライズし暗号化するために必要なプログラムコードおよびデータを格納している。より詳しくは、クレジット処理サーバのメモリ９３は以下に述べるクレジット処理サブシステム９５を格納している：仮想支払いアカウントを用いて購入した製品の請求を買い手に行なうアカウント／ビリングサブシステム９４；仮想支払いアカウントを使用した購入のために受信した支払いを処理するために金融機関５９と通信するための支払い処理サブシステム９５；そして、一つあるいは複数のクレジットビューロー５８から受信した情報によって決定された申請者のクレジット上限を決定するためのアカウント登録サブシステム９６。
【００３６】メモリ９３には、アカウント／ビリングサブシステム９４、支払い処理サブシステム９５、アイデンティティビューローアダプタ９９、そしてアカウント登録サブシステム９６がこれらの要求された機能を実行するために必要とされるアカウントデータベース９７および金融データベース９８が格納されている。アカウント／ビリングサブシステム９４、支払い処理サブシステム９５、アカウントデータベース９７、アイデンティティビューローアダプタ９９、金融データベース９８は、コンピュータ読み出し可能媒体に格納され、フロッピードライブやＤＶＤ／ＣＤ−ＲＯＭドライブのような該コンピュータ読み出し可能媒体と関連したドライブ機構を用いることによって、クレジット処理システムのメモリ９３に読み込むこともできることは理解される。アカウント／ビリングサブシステム９４、支払い処理サブシステム９５、アカウント登録サブシステム９６は、全体あるいは一部において、既存の伝統的なクレジットカード支払いシステムを含んでいてもよいことは理解される。
【００３７】図３乃至６は、図２に示した本発明の一つの実施例の、買い手コンピュータ５０、売り手サーバ５１、コマースゲートウェイ５２、およびクレジット処理サーバ５３の重要なコンポーネントを示している。他の多くの実行および変形が可能であることは理解される。例えば、クレジット処理サーバ５３に代えて、コマースゲートウェイ５２に一つあるいは複数のクレジット処理サブシステム９４，９５，９６を含めてもよい。あるいは、クレジット処理サーバのクレジット処理サブシステム９４，９５，９６の夫々を別個のサーバに含ませても良い。さらに、追加のコマースゲートウェイ５２およびクレジット処理サーバ５３をＬＡＮ４４あるいはインターネット４０の他の場所に置いてもよい。
【００３８】仮想支払いアカウントの申請
一旦仮想支払いアカウントがセットアップされると、本発明の仮想支払いシステムはインターネットを介した製品の購入の安全な手法を買い手に提供するような閉じられたシステムである。閉じられたシステムは、登録された買い手のコンピュータ５０、登録された売り手サーバ５１、コマースゲートウェイ５２（仮想支払いシステムの提供者によって管理される）、そしてクレジット処理サーバ５３（これもまた仮想支払いシステムの提供者によって管理される）のみを含む。購入に対する買い手へのチャージに必要なアカウント情報は既にコマースゲートウェイ５２およびクレジット処理サーバ５３に入手されているので、本発明の閉鎖されたシステムは、登録された買い手が、インターネットを通して売り手に対してセンセィティブなアカウント情報を送信することなく、登録された売り手から製品を購入することが可能となる。本発明の仮想支払いシステムの会員となるためには、買い手は、仮想支払いアカウントを獲得して登録ユーザとなる。図７は、買い手のための仮想支払いアカウントを生成するために、買い手のコンピュータ５０、コマースゲートウェイ５２、クレジット処理システム５３、クレジットビューロー５８によって行なわれるアクションを示している。数々のコンポーネントのインターアクションが例示され、図１２、２７、４２に示された図を参照して本発明によって実行される数々の決済が後に詳述される。図７に示すように、買い手が買い手のコンピュータ５０にインストールされたウェブブラウザ６４を用いてインターネットを介して申請フォームをリクエスト１００する時に、仮想支払いアカウントの申請処理が開始される。買い手は、コマースゲートウェイ５２に置かれた仮想支払いアカウントウェブサイトから直接に仮想支払いアカウントを申請してもよく、あるいは、買い手サーバ５１に置かれた登録買い手サイトから間接的に仮想支払いアカウントを申請してもよい。申請フォームのリクエスト１００がコマースゲートウェイ５２によって受信されると、コマースゲートウェイ５２は買い手コンピュータ５０に申請フォーム１０２を提供し、買い手が買い手コンピュータ５０のウェブブラウザ６４に表示されたフォームを記入させるようになっている。
【００３９】申請フォームの記入が完了すると、買い手コンピュータ５０は記入された申請フォーム１０４をコマースゲートウェイ５２に提出する。そしてコマースゲートウェイ５２は記入されたフォームからのアプリケーションデータ１０６を、アカウントおよびクレジットリミットオーソライゼーションのためにクレジット処理サーバ５３に提出する。クレジット処理サーバ５３はアイデンティティビューロー５６からアイデンティティ情報１１６を要求することによってアプリケーションデータを認証する。アイデンティティビューローは要求されたアイデンティティ情報１１８を提供し、もし、提供されたアイデンティティ情報がアプリケーションデータに対応している場合には、クレジット処理サーバ５３はクレジットビューロー５８から買い手に関するクレジット情報１０８を要求する。しかしながら、本発明の一つの実施例では、アプリケーションデータがアイデンティティビューロー５６からのアイデンティティ情報に対応していない場合には、いかなる仮想支払いアカウントも生成されず、アプリケーションは可能性のある不正発見のためにカスタマサービスへと転送される。上述のように、本発明の実施例において、アイデンティティビューロー５６はアイデンティティを認証するエージェンシーによって維持され提供されるサーバであり、クレジットビューロー５８は、クレジットレポートを処理するクレジットエージェンシーによって管理され提供されるサーバである。よって、クレジット処理サーバ５３は望ましいアイデンティティおよびクレジット情報を、アイデンティティビューロー５６およびクレジットビューロー５８から電子的に、例えば、適切なデータベースクエリを介して、要求する。
【００４０】例示の実施例において、クレジットビューロー５８は要求されたクレジット情報１１０をクレジット処理サーバ５３との接続を介してクレジット処理サーバ５３に提供する。クレジット処理サーバ５３はアプリケーション、アイデンティティ、およびクレジット情報をアイデンティティビューローからのアイデンティティ情報とクレジットビューロー５８から受信したクレジット情報とをアプリケーションデータと組み合わせることで評価して、クレジットスコア１１１を決定する。クレジットスコアがある閾値を越える場合には、クレジットリミットが設定され、仮想支払いアカウントが生成１１２される。もし、スコアが該閾値に届かない場合であっても、仮想支払いアカウントは生成１１２されるが、全ての購入が前払いとする必要があり、アカウント情報が可能性のある後のクレジットの付与のレビューのために、カスタマサービス代表に送られる。
【００４１】一旦仮想支払いアカウントが生成されると、クレジット処理サーバ５３は、評価１１３の結果、例えば、許可／拒否、前払いアカウントのみ、クレジットリミット等、をコマースゲートウェイ５２に戻す。コマースゲートウェイ５２は、買い手のコンピュータ上の買い手オーセンティケータ６５が、シークレットキーおよびパブリックキーを有するパブリックキー暗号化キーペア１２２を生成することを要求する。買い手オーセンティケータ６５はパブリックキーをコマースゲートウェイ５２にサブミットする。コマースゲートウェイ５２はデジタルにパブリックキーを署名し、デジタル証明書１２６を生成する。当業者にとって、デジタル証明書は、信用に値する主体によってデジタル的に署名されたパブリックキーを含んでいることは理解される。コマースゲートウェイ５２は、デジタル証明書および申請結果ページ１１４を買い手のコンピュータ５０に送り、買い手のウェブブラウザ６４を介して表示する。最後に、買い手コンピュータは、仮想支払いアカウントの後の使用とため、デジタル証明書１２８を格納する。
【００４２】デジタル証明書は、買い手コンピュータ５０のメモリ６３に格納されてもよく、あるいは、例えば、これらには限定されないが、安全が保証されたトークン、スマートカード、他のコンピュータ読み出し可能媒体上の暗号化されたファイルのような買い手コンピュータと対話することができる幾つかの形式の装置に格納される。当業者にとって、図７に示すオペレーションの順序は、本発明のオペレーションに実質的に影響を与えることなく変更され得ることは理解される。例えば、買い手は、パブリックキー暗号化ペアが生成される前に、申請の結果を知るようにしてもよい。
【００４３】図８Ａ―８Ｇは、上述した仮想支払いアカウントを提供することに関連して買い手コンピュータ５０のウェブブラウザ６４によって買い手に提供されたウェブページの例示である。図８Ａに示すウェブページ６００を用いることによって、買い手は、彼らが望む仮想支払いアカウントの型、例えば、クレジットあるいはプレペイド、を選択し、「継続」をクリックすることで該情報を送信する。次いで、申請フォームのための図８Ｂ−８Ｄに示すウェブページ６０５，６１０，６１５がウェブブラウザ６４を介して買い手に表示される。本発明の一つの実施例において、買い手はオンラインで適切な申請データによって申請フォームを記入する。あるいは、買い手は印刷した形式においてアプリケーションを要求し、ファクシミリやレギュラーメールを介して印刷されたフォームを提出することもでき、この場合、カスタマサービス代表は、管理ユーザコンピュータ５４を介して、クレジット処理サーバ５３のアカウントデータベース９７へ該情報を入力する。アプリケーションデータは、ソーシャルセキュリティナンバーや、買い手のクレジットリミットを決定することに用いられる収入のような情報を含んでいる。申請フォームにおいて買い手によって入力された情報は、またデモグラフィックの目的に用いられる。例えば、買い手コンピュータ５０上にはウェブブラウザ６４を介してバナー広告が表示され、バナー広告は、買い手の年齢や地理的位置等のデモグラフィック情報に基づいて買い手に狙いを定める。
【００４４】買い手が、図８Ｂ−８Ｄに示されたウェブページ６０５，６１０，６１５に含まれたアプリケーションフォームを記入し終え、アプリケーションがクレジット処理サーバ５３によって処理されると、図８Ｅに示すウェブページ６２０が買い手のコンピュータのウェブブラウザ６４に送信され表示され、買い手に、アプリケーション処理の結果、すなわち、アカウント許可および、アカウントクレジットリミットを含む、買い手の仮想支払いアカウントの詳細を知らせる。アカウント許可が完了しアカウントが買い手に受け入れられると、コマースゲートウェイ５２が、図８Ｆに示すようにインストールのため、買い手オーセンティケータコンポーネント６５（上述したように、パブリックキー暗号化キーペアを生成する）を買い手のコンピュータに送信する。図８Ｇは、買い手がその仮想支払いアカウントを作動できるような例示のウェブページ６３０が示されている。
【００４５】仮想支払いアカウントのカスタマイズおよび修正
上述したように、仮想支払いアカウントが許可されクレジットリミットが設定されると、アカウントは買い手によってカスタマイズされる。そして、アカウント情報はクレジット処理サーバ５３のアカウントデータベース９７に格納される。図９Ａ−９Ｃはコマースゲートウェイ５２からダウンロードされ、買い手の仮想支払い口座をカスタマイズするために買い手のコンピュータ５０のウェブブラウザ６４によって表示されたウェブページのセットを例示している。図９Ａ−９Ｂは、メインアカウントカスタマイゼーションのためのウェブページ６４０および６４５を例示している。図９Ａに示すように、買い手は、仮想アカウントコンタクト情報および好みをカスタマイズする。図９Ｂは、メインアカウントホルダーが、ウェブページ６４５に示すような、アカウントおよび全てのサブアカウントのためのアクセス制御を設定できることを示している。
【００４６】図９Ｃに示すように、買い手は、また、買い手自身が使用する、あるいは、ビジネスパートナー、配偶者、および／あるいは子供が使用する、サブアカウントをカスタマイズする。下記により詳述するように、買い手は自身の消費リミットをサブアカウントに課すことができる。一つの実施例において、買い手が報酬ポイントをサブアカウントに転送するために報酬ポイントがメインアカウントに生じる。他の実施例においては、買い手が望む場合には、報酬ポイントが個人サブアカウントに生じるようにしてもよいことは理解される。報酬あるいは報酬ポイントは、後に、例えば、購入の支払いのために、売り手ディスカウントを受け取ることに、あるいはフリークエントフライヤーマイルの購入、等に用いられる。当業者にとって、報酬ポイントは買い手によって獲得され、買い手の仮想支払いアカウントに無数の異なる手法によって適用されることは理解される。
【００４７】買い手がオーソライズされた、すなわち登録された買い手となるためには、同様のプロセスが実行されることは理解される。一つの実施例において、売り手は、オンラインで申請フォームを記入することで参加者となることを申請することができる。他の実施例において、売り手は、より伝統的なマニュアル申請手続きを用いることで参加者となることを申請する。さらに他の実施例では、オンラインとマニュアルプロセスの組み合わせが用いられる。売り手の申請プロセスが全体あるいは一部においてオンラインで実行される場合には、ウェブブラウザコンポーネント（図４には図示せず）が売り手のコンピュータディスプレイ７２上にウェブページを表示することに用いられることは理解される。売り手は、コマースゲートウェイ５２のプロバイダと契約を形成する。一つの実施例では、この契約は、請求時期およびコマースゲートウェイプロバイダに支払われる料金のような条項が含まれる。売り手は、仮想支払いアカウントを有する買い手に対して製品を売るので、売り手は、買い手が持つサブアカウントと同じ意味でのサブアカウントを有しない。しかしながら、異なるタイプのデータを販売する売り手は異なるアカウントを有する。例えば、ブックストアはジェネラルアカウントと、一つあるいは複数の制限されたアカウントを有してもよく、例えば、制限されたアカウントは、未成年へのアダルト製品の販売を禁止する。これは、レーティングシステム（例えば、Ｇ，ＰＧ，ＰＧ１３，ＮＣ１７，Ｒ等）の形成で行なわれる。買い手の申請プロセスと同様に、売り手が許可されると、売り手アカウントがカスタマイズされ、デジタル証明書が売り手のコンピュータ５１にインストールされ、仮想支払いシステムにおける登録売り手として売り手を認証する。デジタル証明書は、売り手サーバ５１によって生成されるシークレットキーおよび売り手サーバによって生成されたパブリックキーと組み合わせて用いられ、ゲートウェイ５２に送られて、より大きな安全のためメッセージを暗号化／復元する。
【００４８】先に述べたように、売り手は買い手アカウントを申請することもできる。換言すると、売り手は、仮想支払いアカウントの所有者として製品を購入することができる。
【００４９】デジタルセキュリティ
例示の実施例において、買い手は、サブアカウントのカスタムパッケージを生成することができる。当業者にとって容易に理解されるように、買い手は、本発明の仮想支払いシステムを提供し、管理する者の望みによって、いかなる数、タイプあるいは組み合わせのサブアカウントを与えられる。
【００５０】買い手は、図９Ｃに示すようにウェブページ６５０を介してサブアカウント（例えば、補助ユーザ、若年買物客等）を追加する。サブアカウントは、図９Ｃに示すように、例えば、若年買物客の消費リミットを設定し、そこから若年買物客が製品を購入することができる売り手ウェブサイトへのみの認証を行なうことによって、若年買物客のためにカスタマイズされる。
【００５１】以下により詳細に記載するように、仮想支払いアカウントがオーソライズ１１４され、カスタマイズされると、デジタル証明書がコマースゲートウェイ５２によって転送され、買い手コンピュータ５０上にインストールされる。デジタル証明書は、買い手が仮想支払いアカウントの登録されたホルダ−であることを確認する特有の信用証明書として、続くトランザクションにおいて用いられる。本発明の実施例において、買い手あるいは売り手は、買い手の仮想支払いアカウントに関連するデジタル証明書におけるコマースゲートウェイのデジタル証明を認証するコマースゲートウェイ５２によって仮想支払いシステムの登録されたユーザとして確認される。
【００５２】幾つかのレベルのセキュリティがオンライントランザクションに課されることは理解される。最も低いレベルから最も高いレベルに向かって、（１）セキュリティ制限が課されない；（２）アカウントネームおよびパスワード認証のような最小限のセキュリティ；（３）デジタル証明書あるいはシークレットキーのような、中間セキュリティ；（４）買い手のシークレットキーを使用したデジタル署名によって署名されたトランザクションのような、高いセキュリティ；（５）デジタル署名および、アカウントナンバー、ラスト購入認証、スマートカード、暗号化されたトークン、あるいはこれらの組み合わせのような、最大のセキュリティである。後述するように、ここに記載された仮想支払いシステムの実施例においては、「デジタル証明書」という用語は、用いられるオーソライゼーションを記述することに用いられるが、デジタル署名、あるいは追加のアクセス制御を伴うデジタル署名のようなより高度のセキュリティが、仮想支払いアカウントトランザクションに関連する全てのパーティ（すなわち、買い手、売り手、コマースゲートウェイ、そしてクレジット処理サーバ）の最も高いセキュリティのためには、望ましい。
【００５３】セキュリティトランザクションの実施例では、売り手サーバ５１は、デジタル的に、コマースゲートウェイ５２によって発行された証明書で購入オファーに署名をし、それを売り手サーバ５１に送信する。売り手サーバ５１は二重に署名された購入オファーをコマースゲートウェイ５２に送る。コマースゲートウェイ５２は、両方の署名を認証し、両方が有効でトランザクションが可能である時には、二重に署名されたオファーに署名を行い、結果として三重に署名された購入オファーを売り手サーバ５１に送る。売り手サーバはコマースゲートウェイ５２の署名を認証し、それが有効な場合には、購入トランザクションが完了する。上述の実施例において、売り手サーバ５１は買い手コンピュータ５０に知らせてもよく、あるいは知らせなくてもよい。
【００５４】製品の発注
買い手が買い手の仮想支払いアカウントを生成し、カスタマイズすると、買い手がアカウント申請プロセスにおいてクレジットが与えられた場合には、買い手はインターネットを介して直ぐに製品を発注することができる。しかしながら、もし、買い手の仮想支払いアカウントがプリペイドアカウントのみの場合には、買い手が製品を発注する前に、前払いが行なわれる必要がある。他の実施例では、プリペイドアカウントのみの買い手は製品を発注できるが、プリペイドアカウントが該製品をカバーするのに十分な資金で賄われるまで、製品の出荷は止められる。より詳細には、これは、いかなる登録された買い手は「デジタルレイアウェイ」の形式を有し、いかなる登録された売り手のウェブサイトから直接製品を発注することを可能としている。さらに他の実施例では、買い手と売り手は同じタイプの仮想支払いアカウントを有し、いかなる買い手も売り手として、あるいはその逆として振舞うことができる。追加的に、売り手はオークションウェブサイトであり、売り手は、オークションウェブサイトから購入した商品、サービス、および／あるいはコンテンツの支払いのための仮想支払いアカウントを用いることができることは理解される。
【００５５】図１１Ａ−１１Ｃに示した本発明の一つの実施例において、買い手は、ウェブをサーフすることができ、ウェブブラウザ６４を使用した「バーチャルストア」１００のような、登録された売り手のウェブサイトを訪問することができる。買い手が登録された売り手のウェブサイトを訪問すると、買い手は買い手の仮想支払いアカウントを用いてウェブサイトからオファーされた製品をオーダーし支払うことができる。より詳しくは、買い手コンピュータ５０を使用する買い手およびウェブブラウザ６４は、バーチャルストアとして仮想的に知られた売り手のウェブサイトから図１１Ａに示すようなウェブページ１１００を検索する。買い手は、セレクション１１１０の上のマウスおよびシングルクリッキングのような、ポインティングデバイスを用いてグラフィックカーソルを操作することによって特別な製品１１０５のセレクションを行なう。他のページ、例えば、買い手が製品をキーワードによって要求するようなクエリページが、表示されることが理解される。また、図１１Ａに示すウェブページ１１００は簡略化されたものであることが理解される。売り手のサイトにおいて、買い手が複数の製品を選択して、これらをショッピングカートに置くことは一般的である。買い手は該カートの中のアイテムを見ることができ、望む場合には、カートからアイテムを除去する。買い手が望ましいアイテムを購入のために選択すると、例えば、「ＯＫ」ボタンや「Ｂｕｙ」ボタンをクリックすることによって、買い手は選択したアイテムを購入することを望むことを示す。図１１Ａに示す簡略化された例では、買い手は、バーチャルストアパーソナルコンピュータ１１０５のようなアイテムを選択し、「発注」ボタンを押すことで、購入トランザクションを開始する。
【００５６】購入トランザクションを開始すると、売り手サーバ５１は買い手のコンピュータ５０のウェブブラウザ６４に、図１１Ｂに示すウェブページ１１５０を提供し、ストリートアドレスのような買い手からの出荷情報１１６０を要求する。さらに、ウェブページ１１５０は、クレジット情報の電子送信を伴う数々の支払いオプション、すなわち、ＶＩＳＡ（商標）やＭＡＳＴＥＲＣＡＲＤ（商標）のようなメジャーなクレジットカード、を含んでいる。本発明では、仮想支払いアカウントオプションは登録された売り手に対して支払いオプションとして表示される。出荷情報および支払い情報１１６０を入力し、仮想支払いオプション１１５５を選択した後には、買い手は、「購入」オプション１１６５をクリックすることによって継続することができる。本発明の一つの実施例では、買い手オーセンティケータ６５が、買い手に対して、認証パスフレーズ１１７５を伴って、アカウント１１７２のチョイスの選択の要求をするウィンドウ１１７０を表示する。アカウントを選択し、正確なパスフレーズを入力すると、買い手は、「継続」１１７７をクリックし、購入を進める。これに応答して、買い手サーバ５１は、タックスおよび出荷およびハンドリングを含む発注の全体のコストを計算し、買い手には図１１Ｃに示す確認スクリーン１１８０が呈示される。購入をオーソライズした後には、買い手には図１１Ｄに示す支払い確認スクリーン１１８５が呈示される。さらに、買い手は図１１Ｅに示す発注確認スクリーン１１９０が呈示される。
【００５７】図１２は、仮想支払いアカウントオプション１１５５が選択された時に、買い手のコンピュータ５０上にインストールされたウェブブラウザ６４を介して実行されるロジックを示している。ロジックはブロック２２０に始まり、ブロック２２２に進み、そこで、買い手コンピュータ５０とコマースゲートウェイ５２の安全な接続が確立される。本発明の一つの実施例において、セキュアソケットレイヤ（ＳＳＬ）プロトコルが安全な接続のために用いられる。ＳＳＬは、ネットスケープナビケータ（商標）ウェブブラウザやネットスケープコマースサーバのような、ウェブブラウザに組み込まれるパブリックキー暗号を用いることで、インターネットを通して伝送される情報を安全化する。ロジックはブロック２２４に進み、そこで、買い手コンピュータ５０上の買い手オーセンティケータコンポーネント６５が実行される。買い手オーセンティケータコンポーネント６５は、部分的にあるいは全体としてウェブブラウザ６４に含まれる。買い手オーセンティケータコンポーネント６５は図１３に詳細に示され、次に説明する。
【００５８】買い手オーセンティケータコンポーネント６５は買い手が、仮想支払いアカウントの登録されたホルダーであるか、あるいは別の言い方をすると、本発明の閉じられた仮想支払いシステムの登録された参加者であるかを決定する。図１３のロジックはブロック２４３で始まり、ブロック２４４に進み、そこでは、認証要求およびコンテナがウェブブラウザ６４から受け取られる。コンテナは以下のものを含んでいる：購入詳細のようなトランザクション情報；例えば、上述したように買い手が仮想支払いアカウントを生成したときに買い手に事前に発行されるデジタル証明書のような買い手を確認する買い手同一確認のような、パーティのアイデンティフィケーション；例えば、売り手のアカウントの生成によって売り手に発行されるデジタル証明書のような売り手アイデンティフィケーション；トランザクションの日および時間のようなコンテキスト。コンテナは初期には空であり、数々のコンポーネントによってデータがコンテナに付加されることは理解される。前に述べたように、本発明の実施例は、ウェブブラウザ６４において買い手オーセンティケータ６５を実行する。一つの実施例では、買い手オーセンティケータ６５はウェブブラウザ６４内で操作されるアプレットである。
【００５９】次いで、決定ブロック２４６において、デジタル証明書が買い手のコンピュータ５０にインストールされているかを決定するテストが行なわれる。デジタル証明書は買い手コンピュータ５０のメモリ６３に格納されるか、あるいは、保証トークン、スマートカード、コンピュータ読み出し可能媒体上の暗号化されたファイルのような、買い手コンピュータと関連する他の装置に格納される。他のデジタル認証の手段も採用されることは理解される。デジタル証明書がインストールされると、デジタル証明書認証が認証コンテナに挿入され、認証要求およびコンテナがブロック２４８，２５０におけるウェブブラウザに返される。コンテナは、数々のデータフォーマットの何れか一つであり、例えば、本発明の一つの実施例では、プロプリエタリプロトコルが使用される。本発明の一つの実施例では、買い手コンピュータによって生成され、コマースゲートウェイ（デジタル証明書を形成する）によって署名されるパブリックキーもコンテナに挿入される。シークレットキーは、本発明の仮想支払いシステムのいかなる場所へも伝送されない。シークレットキーとデジタル証明書の組み合わせは、買い手認証プロセスに対するセキュリティのレベルを高くする。デジタル署名は一般に、パブリックキーペアのシークレットキーによって暗号化されたドキュメントである。同じキーペアのパブリックキーのみが該ドキュメントをオリジナルの形式に復元することができる。これは、シークレットキーのホルダーのみが文書を署名（暗号化）できることを示すことにおいて特に有用である。実際の観点からすると、パブリックキー暗号技術を用いて膨大なドキュメントを署名することは、とても時間を要するものである。ほとんど同じに効果的なことは、ドキュメントの暗号化メーッセージダイジェストを生成し、シークレットキーを用いてダイジェストを暗号化することである。したがって、当業者において、対応するパブリックキーおよびダイジェストアルゴリズムを知っているいかなる者も、メッセージが変更されておらず、そしてそれが対応するシークレットキーのホルダーから来たものであることを認証することができることが理解される。デジタル証明書はここでは、プロバイダの否認防止購入ポリシーを厳守する仮想支払いアカウントのプロバイダによって認められた認証識別子を意味する。
【００６０】もし、決定ブロック２４６において、デジタル証明書が買い手コンピュータ５０にインストールされていないと決定された場合には、ロジックは決定ブロック２５２に進み、そこで、「存在しない証明書」処理を実行するか否かを決定するテストが行なわれる。存在しない証明書処理は、デジタル証明書が存在しないときに、買い手がマニュアルでアイデンティフィケーション情報を入力することを可能とする。アイデンティフィケーション情報は、電子メールアドレス、パスワード、例えば、抵当支払い額のような個人情報を含むものである。決定２５２の結果がポジティブの場合には、ロジックはブロック２５４における他の認証に進む。他の認証はさらに詳細に図１４に示されており、次に述べる。
【００６１】図１４のロジックはブロック１４０１で始まり、ブロック１４０５に進み、そこで、オーソライゼーションオプションが買い手に表示される。次いで、ブロック１４１０において、買い手が、他のオーソライゼーションメカニズムとしてオーソライゼーションコードを要求したかを決定する。買い手がオーソライゼーションコードの受信を選択している場合には、オーソライゼーションコードエントリーフォームがブロック１４１５において買い手コンピュータのウェブブラウザ６４に送られ、オーソライゼーションコードがブロック１４２０において認証装置に送られる。例示の認証装置２８００あるいは２９００がそれぞれ図２８、２９に示されている。オーソライゼーションコードを受信した後で、買い手はブロック１４２５において、オーソライゼーションコードエントリーフォームにコードを入力する。
【００６２】ブロック１４０５において、買い手がオーソライゼーションコードを要求することを決定しない場合には、ロジックはブロック１４１０からブロック１４５０に流れ、そこでは、対話型認証ウェブフォーム３０００が買い手のコンピュータ５０のウェブブラウザ６４に送られる。対話型認証ウェブフォーム３０００が図３０に例示されている。次いで、ブロック１４５５において、買い手は対話型認証ウェブフォーム３０００を記入する。
【００６３】次いで、記入が完了したオーソライゼーションエントリーフォームブロック１４２５、あるいは１４５５はブロック１４３０におけるコマースゲートウェイに送信される。そしてロジックはブロック１４３５に進み、そこでは、認証が成功したかどうかが決定される。認証が成功した場合には、ロジックはブロック１４９８で終わり、成功認証に戻る。認証が不成功の場合には、ロジックはブロック１４９９で終わり、不成功認証に戻る。
【００６４】図１３に戻ると、ロジックはブロック２５６に進み、そこで、他の認証プロセスからの情報が買い手のオーセンティケータ６５を通過して戻され、ロジックはブロック２６２で終わる。デジタル証明がインストールされていない場合（決定ブロック２４６における「Ｎｏ」）で、存在しない証明書処理は実行されない場合には、例えば、図３０（あるいは決定ブロック２５２における「Ｎｏ」）に示す存在しない証明書オーソライゼーションウェブページ３０００における「キャンセル」のユーザの選択によって、買い手は仮想支払いアカウントを有しない。したがって、図１３のロジックは決定ブロック２５８に進み、そこで、買い手が仮想支払いアカウントを適用することを希望するかを決定するテストが行なわれる。買い手が仮想支払いアカウントの適用を希望する場合には、ロジックはブロック２６０に進み、そこで、買い手は図１５に示し、かつ次に説明するように、仮想支払いアカウントの適用が可能となる。さもなければ、買い手認証６５は不成功オーソライゼーションメッセージをブロック２６１におけるウェブブラウザ６４に返し、ロジックがブロック２６２で終了する。
【００６５】図１５は買い手が仮想支払いアカウントを申請した時に、ウェブブラウザ６４によって実行されるロジックを表している。仮想支払いアカウントの申請は、コマースゲートウェイ５２から直接アカウントを要求する買い手あるいは登録された売り手から製品を注文する意思のある登録されていない買い手によって呼び出される。いずれの場合にも、ウェブブラウザ６４を介して仮想支払いアカウントを申請するためのロジックはブロック２７０で始まり、ブロック２７２に進み、そこで、アプリケーションフォームの要求はウェブブラウザ６４によって受信される。次いで、ブロック２７３において、アプリケーションフォームの要求はコマースゲートウェイ５２のウェブサーバーコンポーネント８７に送られる。要求されたアプリケーションフォームはコマースゲートウェイ５２のウェブサーバーコンポーネント８７から受信され、ブロック２７４において買い手のウェブブラウザに表示される。
【００６６】次いで、ブロック２７５において、記入が完了したアカウントアプリケーションフォームはコマースゲートウェイ５２に送られ、図１６に示され、次に説明される登録サーバコンポーネント８９によって処理される。他の実施例において、アカウントアプリケーションは、財務トランザクションを取扱うと共に登録のような非財務トランザクションを扱うトランザクションサーバコンポーネント８７に送信される。
【００６７】図１６に示す登録サーバ８９のロジックはブロック２８０で開始し、ブロック２８２に進み、そこにおいて、完成されたアプリケーションフォームがウェブブラウザから受信される。次いで、ブロック２８３において、ネーム、従業者、現在の住まい、等のアイデンティティ情報が、そのロジックが図２７に示され次いで述べられるアイデンティティビューローアダプタ７９を介してアイデンティティビューロー５６から要求される。
【００６８】よって、図２７のロジックはブロック２７０５で始まり、ブロック２７１０に進み、そこにおいて、アイデンティティリクエストが受け取られる。リクエストはブロック２７１５において特別なアイデンティティビューローとコンパチブルなようにフォーマットされる。次いで、ロジックはブロック２７２０に進み、そこで、フォーマットされたリクエストはアイデンティティビューロー５６に送られる。リクエストの結果はブロック２７２５においてアイデンティティビューローから受け取られる。次いで、ブロック２７３０において、結果は要求者に戻される。図２７のロジックはブロック２７３５で終了する。
【００６９】図１６において、ブロック２８４において、この場合は登録サーバ８９、アイデンティティビューローアダプタ７９を介してアイデンティティビューロー５６から受信したアイデンティティ情報がブロック２８２における受け取られたアプリケーションにおける情報に対応するときには、処理はブロック２８５に進み、そこにおいて、登録サーバは、図２１に示すと共に、後に購入オーソライゼーションリクエストと共に説明するクレジット処理サーバアダプタ８６を介して、クレジットビューロー５８から、収入、現在の雇用者のもとでの期間、現在の住まいにおける期間等のクレジット情報を要求する。
【００７０】クレジット情報が受け取られると、ロジックはブロック２８６に進み、そこでは、アプリケーションが、アイデンティティビューロー情報およびクレジットビューロー情報に基づいて、内部クライテリアとの組み合わせにおいて、スコア付けされる。内部クライテリアは数々のクレジット情報のためのスコアを提供する。例えば、収入が複数の範囲に分割され、各範囲にポイント価値が割り当てられる。同様に、ポイント価値は、申請者が現在の住居に住んでいる期間等に基づいても割り当てされる。クレジット情報の各ポイントは結合され、申請者のスコアを決定する。スコアは買い手のクレジット価値と同一視され、申請者がクレジットアカウントを受け取るかを決定することに用いられ、あるいはスコアが中間範囲、にある場合には、プリペイドアカウントを受け取るか、そして、そうである場合には、申請者、すなわち買い手のクレジットリミットを確立する。次に、スコアが閾値よりも上にある場合には、ロジックは、ブロック２８８に示すウェブブラウザに戻された成功した登録結果で終わる。しかしながら、スコアがある閾値より下の場合には、すなわち、アイデンティティビューロー５６によって提供されたアイデンティティ情報が買い手アプリケーションのものに対応しない場合には、ブロック２８９において、不成功結果が戻される。そして、処理は図１５に戻る。
【００７１】図１５において、登録サーバ８９から応答を受信すると、ブロック２６５がアカウントが生成されたかを検査する。もしその時には、リクエストは売り手コンピュータ５０に送信され、ブロック２６７においてパブリックキー暗号化ペアを生成し、該パブリックキーをコマースゲートウェイ５２の登録サーバ８９に送信する。そして登録サーバはパブリックキーを署名してデジタル証明書を生成し、ブロック２７８におけるデジタル証明書と共にブロック２７６において受信され、図８Ｅに示された、成功登録ウェブページ６２０を返信する。ブロック２６５において、アカウントが生成されていない場合には、不成功アプリケーションウェブページがブロック２６６において表示される（図示せず）。仮想支払いアカウントを申請する場合において、結果ページ６２０は買い手の新アカウントの詳細を提供し、あるいは、アカウントを生成するにあたりエラーがあることを買い手に知らせるメッセージを含んでいる。仮想支払いアカウントを申請する図１５のロジックは、ブロック２７９において終わり、処理は図１３に戻る。
【００７２】図１３に戻って、買い手が仮想支払いアカウントを申請した後に、ロジックは決定ブロック２４６に戻り、そこで、デジタル証明書が買い手のコンピュータ５０にインストールされているかを決定するテストが繰り返される。決定ブロック２４６の結果に依存して、ブロック２４８−２５０あるいはブロック２５２−２５６が、仮想支払いアカウントの新しい申請者のために繰り返される。ロジックはブロック２６２で終わる。
【００７３】図１３に示され、ここで説明された買い手を認証するロジックは、デジタル証明書を買い手を認証するための主要手段として用いているが、他の手段も可能であることは理解される。例えば、よりレベルの低いセキュリティが採用され、ユーザは、図１４に示す他の認証に入力された情報のような、認証情報を入力するように要求される。あるいは、より程度の高いセキュリティが採用され、デジタル証明書が要求され、かつ、存在しない証明書処理は許可されない。あるいは、デジタル署名および買い手からの他の情報を認証することを要求するようなさらに程度の高いセキュリティも用いられる。
【００７４】図１２に戻って、買い手の認証がブロック２２４で完了した場合には、ロジックは決定ブロック２２６に進み、そこでは、買い手の認証が成功したかを決定するテストが行なわれる。成功していない場合には、ロジックはブロック２２７に進み、そこで、エラーメッセージがウェブブラウザ６４によって買い手コンピュータ５０上に表示され、失敗した認証を買い手に通知する。図１２のロジックはブロック２４２で終わる。
【００７５】しかしながら、買い手の認証が成功した場合には、ロジックはブロック２２８に進み、そこでは、図１１Ｂに示すような、仮想支払いアカウントセレクションウェブページ１１７０が表示される。仮想支払いアカウントセレクションウェブページ１１７０の要求された情報には、それに対して購入が適用されるべき、適用可能なアカウントあるいはサブアカウントのアイデンティフィケーションが含まれている。次に、ブロック２３０において、サブアカウントおよびパスワード情報（買い手のデジタル証明書のアンロックに用いる）が、買い手が、情報が「継続」１１７７を選択することによって入力されたことを示した時に、図１１Ｂに示す仮想支払いアカウントセレクションウェブページ１１７０において入力された情報から買い手より獲得される。図１２のロジックはブロック２３２に進み、そこで、サブアカウント、および認証コンテナがコマースゲートウェイ５２に送信され、そして図１７に示されかつ次に記載されるアカウントアイデンティフィケーションコンテナジェネレータ８８によって処理される。
【００７６】図１７のロジックはブロック８００において始まり、ブロック８０２に進み、そこで、サブアカウントおよび認証コンテナが買い手コンピュータ５０のウェブブラウザ６４から受け取られる。ロジックはブロック８０４に進み、そこで、認証コンテナに関連する内部アカウントアイデンティフィケーションが決定される。空のアカウントアイデンティフィケーションコンテナはブロック８０６において生成される。次に、ブロック８０８において、内部アカウントアイデンティフィケーションおよびサブアカウント情報が空のアカウントアイデンティフィケーションコンテナに付加される。ロジックはブロック８１０に進み、そこで内部デジタル署名がアカウントアイデンティフィケーションコンテナに適用される。例えば、メッセージダイジェストロジックが、可変の長さのメッセージを受け取り、メッセージを暗号化して安全にする一方向ハッシングアルゴリズムを用いて、固定された長さのダイジェストをアウトプットとして生成するアルゴリズムを適用することで、用いられる。最後に、アカウントアイデンティフィケーションコンテナはブロック８１２においてウェブブラウザ６４に戻される。図１７のロジックはブロック８１４で終わり、処理は図１２に戻る。
【００７７】図１２に戻って、サブアカウントおよび認証コンテナがコマースゲートウェイ５２に送られた後、ロジックはブロック２３４に進み、そこで、ロジックはコマースゲートウェイ５２のアカウントアイデンティフィケーションコンテナジェネレータコンポーネント８８からのアカウントアイデンティフィケーションの受け取りを待機する。アカウントアイデンティフィケーションコンテナがコマースゲートウェイ５２から受け取られると、ロジックはブロック２３８に進み、そこで、購入要求が、図１８に示され、次に述べるように処理のために、リクエストおよびアカウントアイデンティフィケーションコンテナの形式でコマースエンジン７５に送られる。
【００７８】コマースエンジン７５は、オーダが処理されるか否か、および要求された製品が最終的に買い手に提供されるかを決定する売り手サーバ５１のコンポーネントである。コマースエンジンは業界において周知であることは理解される。コマースゲートウェイアダプタコンポーネント７６と共に用いられるコマースエンジンコンポーネント７５によって、本発明の仮想支払いシステムは伝統的なクレジットシステムに現在用いられている既存の技術を広げて、本発明の仮想支払いアカウントを含むようにすることが可能となる。図示され説明された実施例は、この仮想性を獲得するためにコマースエンジンを改良するものであるが（このことは、コマースエンジンの既存のＡＰＩコールを通して可能となる）、他の実施例も可能である。この拡張されたコマースエンジン仮想性は図１８に示してある。
【００７９】図１８のロジックはブロック３００において始まり、ブロック３０２に進み、そこにおいて、購入リクエストおよびアカウントアイデンティフィケーションコンテナが買い手コンピュータ５０のウェブブラウザ６４から受信される。ロジックは決定ブロック３０４に進み、そこでは、購入リクエストがコマースゲートウェイアダプタ７６に伝送されるべきかを決定するテストが行なわれる。もし、購入リクエストが仮想支払いアカウントを用いて製品を購入するものであるならば、リクエストは、本発明の仮想支払いシステムに従って処理されるためにコマースゲートウェイアダプタ７６に転送されるべきである、他の実施例では、要求のみ（アカウントアイデンティフィケーションコンテナなし）がブロック３０２でウェブブラウザから受け取られ、ブロック３０４で、購入リクエストがコマースゲートウェイアダプタ７６に転送されるべきであると決定された場合には、アカウントアイデンティフィケーションがウェブブラウザ６４から獲得される。いずれの場合にも、ブロック３０４において、購入リクエストがコマースゲートウェイアダプタ７６に転送されるべきであると決定された場合には、ロジックはブロック３０６に進み、そこで、リクエストはコマースゲートウェイアダプタに転送される。コマースゲートウェイアダプタ７６は図１９により詳細に示され、次に説明される。
【００８０】コマースゲートウェイアダプタ７６は売り手サーバに常駐するコンポーネントであり、売り手をして、コマースエンジン７５のオーソライゼーションファンクションを拡張して仮想支払いアカウントトランザクションを含むように、コマースゲートウェイ５２のトランザクションオーソライゼーションファンクションと直接通信することを可能とする。したがって、図１９のロジックはブロック３３０で始まり、ブロック３３２に進み、そこで、送られた購入リクエストおよびアカウントアイデンティフィケーションコンテナがコマースエンジン７５から受信される。次に、ブロック３３４において、購入リクエストおよびアカウントアイデンティフィケーションコンテナは、図２０に示しかつ次に述べるようなさらなる処理のために、トランザクションリクエストの形式においてトランザクションサーバ８４に送られる。
【００８１】コマースゲートウェイ５２のトランザクションサーバコンポーネント８４は、システムの他のコンポーネントとインターフェイスすること、および、要求されたトランザクションが買い手の仮想支払いアカウントに適用されるか否かを決定することに責任を有している。図２０のロジックはブロック３５０で始まり、ブロック３５２に進み、そこで、トランザクションリクエストが受け取られる。次いで、ブロック３５３において、アカウントアイデンティフィケーションコンテナが復元され照合される。リクエストのオリジンすなわちソース、および、リクエストのコンテキスト、すなわち、日付および時間、はブロック３５４において、コマースゲートウェイ５２のメモリ８３に格納される。次いで、ロジックは決定ブロック３５６に進み、そこで、要求されたトランザクションが許可されるかを決定するするテストが行なわれる。要求されたトランザクションが許可されるかの決定を行なうには様々なファクタが考慮される。例えば、消費リミットは越えることはできないし、若年買物客カウントに課したようなユーザに課した制限、例えば、図９Ｃに示すように、若年買物客がそこから購入することができるサイト、その間若年買物客が購入することができる時間、は破られてはならない。
【００８２】もしトランザクションが許可されない場合には、ロジックはブロック３５７に進み、そこで、許可されないメッセージが要求者（例えば、購入リクエストの文脈におけるコマースゲートウェイアダプタ７６）に送られる。図２０のロジックはブロック３７６で終わる。もし、トランザクションが許可される場合には、ロジックは決定ブロック３５６からブロック３６０ヘ進み、そこでは、トランザクションリクエストが、図２１に示され、次に述べるように、さらなる処理のために、クレジット処理サーバアダプタ８６に送られる。
【００８３】クレジット処理サーバアダプタ８６は、コマースゲートウェイ５２に常駐するコンポーネントであり、トランザクションサーバ８４や登録サーバ８９のようなコマースゲートウェイ５２コンポーネントがクレジット処理サーバ５３の数々のサブシステムと直接通信することを可能とするものであり、買い手の実際の支払いアカウントに要求されたトランザクションの適用を提供する。したがって、図２１のロジックはブロック３８０において始まり、ブロック３８２に進み、そこでリクエストが受け取られる。例えば、購入オーソライゼーション（認可）リクエストあるいは払い戻しリクエストはトランザクションサーバ８４から受け取られ、クレジット情報リクエストは登録サーバ８９から受け取られる。リクエストは、適切なクレジット処理サブシステム、すなわち、ブロック３８４におけるクレジット処理サーバ５３上の、アカウント／ビリングサブシステム９４、支払い処理サブシステム９５、および／あるいはアカウント登録サブシステム９６、とコンパチブルなようにリフォーマットされる。次いで、ロジックはブロック３８６に進み、そこでは、リフォーマツトされたリクエストが、図２２に示され、次に述べるような適切なクレジット処理サブシステムによる処理のために、クレジット処理サーバ５３に送られる。
【００８４】いかなるクレジット処理サブシステムにとって、図２２のロジックはブロック３９０において始まり、ブロック３９２に進み、そこでは、トランザクションリクエストがクレジット処理サーバアダプタ８６から受け取られる。次いで、アカウントデータおよびサブアカウントデータがブロック３９４において、適切なデータベース、例えば、アカウントデータベース９７および財務データベース９８から受け取られる。標準クレジットトランザクション処理はブロック３９８において実施される。アカウント／ビリングサブシステム９４の標準トランザクションの例は以下のものを含む：名前や住所のようなアカウントホルダー情報およびアカウント情報の保持を含むアカウントの生成および維持；金利の計算；月々のミニマム支払いの計算；月々の電子計算書の生成；ディスカウントとして知られる他のチャージの計算。ディスカウントは、トランザクション額の部分であり、コマースゲートウェイ５２のプロバイダに行き、トランザクションベース毎で固定した額に基づいて、あるいは、トランザクション額ベースの割合に基づいて決定され得る。支払い処理サブシステム９５の標準トランザクションの例は以下のものを含む：買い手から支払いを回収し、支払いを買い手のアカウントに適用する；例えば、ＡＣＨトランザクションのために金融機関５９とインターフェースすることによって、売り手と買い手との間でファンドを伝送する。アカウント登録サブシステムの標準トランザクションの例は以下のものを含む：クレジットビューローからクレジット情報を獲得する；クレジット情報に基づいてクレジットスコアを決定し、該スコアをコマースゲートウェイに提供する；そしてアカウント生成のために、スコアリング情報をアカウント／ビリングサブシステム９４に提供する。
【００８５】ロジックはブロック３９９に進み、そこで、適用が可能であれば、必要なアカウント調整が適用される。例えば、アカウントバランスは、認可された購入トランザクションの額によって減らされる。本発明の一つの実施例では、報酬ポイントが購入の時に生じるが、例えば、マンスリー、計算書準備プロセス等の期間の間のように、後に付する。あるいは、報酬ポイントは、ポイントがそこに帰する製品のための支払いが行なわれるまで生じないようにしてもよい。次に、クレジット情報あるいは購入認可のようなトランザクション結果がブロック４００においてクレジット処理サーバアダプタ８６に送られる。図２２のロジックはブロック４０２において終了し、処理は図２１に戻る。
【００８６】図２１に戻って、トランザクションリクエストの結果は、ブロック３８７において、クレジット処理サブシステム９４，９５，９６から受け取られる。次いで、ブロック３８８において、結果は、要求者に戻される、すなわち、購入認可リクエストの結果はトランザクションサーバ８４に戻され、例えばクレジットリミットのような、クレジット情報は、買い手のアカウントを確立するのに用いられるクレジット情報例クエストのリクエストに応答して登録サーバ８９に戻される。図２１のロジックはブロック３８９において終了し、処理は要求者、例えば、トランザクションサーバ８４（図２０）あるいは登録サーバ８９（図１６）に戻される。
【００８７】図２０に戻って、トランザクションサーバがそのトランザクションリクエストに対する応答を、例えば、購入リクエストの認可の結果、ブロック３６３におけるクレジット処理アダプタから受け取ると、ロジックはブロック３６４に進み、そこにおいて、トランザクションレコード、例えば、購入の額を含む購入情報、がコマースゲートウェイ５２のメモリ８３に格納される。ロジックは決定ブロック３６６に進み、そこで、トランザクションが成功して処理されたかを決定するテストが行なわれる。もしそうなら、ロジックはブロック３７０に進み、そこでトランザクション応答が有効なステータスと共に要求者（例えば、コマースゲートウェイアダプタ７６あるいはウェブブラウザ６４、いずれの場合であってもよい）に送られる。もしトランザクションが成功して処理されなかった場合には、ロジックは決定ブロック３６６からブロック３７４に進み、そこで、エラーステータスを伴うトランザクション応答がブロック３７６において要求者に返される。
【００８８】有効なトランザクション応答３７０の後で、エラートランザクション応答３７４、あるいは、許可されないトランザクション応答３５７が要求者に送信され、図２０のロジックはブロック３７６で終わり、処理は要求者に返される。購入リクエストの場合、要求者はコマースゲートウェイアダプタ７６である。一つの実施例において、全てのトランザクションのレコードは財務データベース９８に格納される。
【００８９】図１９に戻って、コマースゲートウェイアダプタ７６によって行なわれる購入リクエストに対する応答がブロック３３６において、トランザクションサーバから受け取られると、ロジックはブロック３３８に進み、そこで、トランザクションステータスを含む応答がコマースエンジン７５とコンパチブルとなるようにフォーマットされる。フォーマットされた応答はブロック３４０においてコマースエンジンに送られる。図１９のロジックはブロック３４２で終了し、処理は図１８におけるコマースエンジン７５に戻る。
【００９０】図１８に戻って、応答がコマースエンジン７５によってブロック３０８のコマースゲートウェイアダプタ８６から受け取られると、ブロック３１０において、認可されかつ注文された製品は買い手に出荷される。当業者にとって、発注された製品がダウンロード可能であれば、例えば、製品が電子的に格納された製品、有料コンテンツウェブサイトのＵＲＬ等の場合、製品は単に売り手のサーバ５１から買い手のコンピュータ５０に送信されることは理解される。さもなければ、製品は、より伝統的な手法、例えば、レギュラーメールや、ハンドデリバリ等によって出荷され、提供される。出荷が完了すると、ロジックはブロック３１２に進み、そこでは、ファンドの移動を始動するために、決済リクエストがコマースゲートウェイ５２に送信される。本発明の実際の実施例では、売り手の決済バッチが次に処理されるとき、売り手は支払いの決済バッチへとトランザクションを送信する。処理のタイミングはその夜、あるいは契約、すなわち購入トランザクションの条件、に基づいた後の日である。図４１は、バッチが処理されるべき時を指定するウェブページ４００を例示している。決済トランザクションは図２４に記載され、図２４に参照されたより詳しく以下に説明される。
【００９１】図１８に戻って、ブロック３１４において、オーダの完了を確認する応答が買い手のコンピュータ５０のウェブブラウザ６４に送られる。図１８のロジックはブロック３２４において終了する。
【００９２】しかしながら、決定ブロック３０４において、購入リクエストがコマースゲートウェイ５２に送信されるべきではないと決定されると、ロジックはブロック３１６に進み、そこでは、標準コマースエンジン処理が実行される。より詳しくは、ブロック３１６において、ＶＩＳＡ（商標）やＭＡＳＴＥＲＣＡＲＤ（商標）のようなクレジットカードのユーザの許可あるいは不許可をような、伝統的なクレジットあるいはデビットカード認可が、特定の購入額のために、実行される。次いで、認可された商品はブロック３１８において出荷される。ロジックはブロック３２０に進み、そこでは、決済リクエストが、ＶＩＳＡ（商標）やＭＡＳＴＥＲＣＡＲＤ（商標）のような伝統的なクレジットプロバイダへと送信される。オーダの完了を確認する応答がブロック３２２において買い手のコンピュータ５０のウェブブラウザ６４に送られる。図１８のロジックはブロック３２４において終了し、処理は図１２に戻る。
【００９３】図１２に戻って、買い手のコンピュータ５０のウェブブラウザ６４がブロック２４０においてその購入リクエストに対する応答を受け取ると、ロジックはブロック２４１に進み、そこでは、オーダコンファメーションウェブページ１１９０が図１１Ｅに示すように表示される。図１２のロジックはブロック２４２において終了する。
【００９４】図２３は、仮想支払いアカウントシステムを使用して製品を発注するために、買い手コンピュータ５０、売り手サーバ５１、コマースゲートウェイ５２によって行なわれるアクションを示す図である。この図は、上述したフローチャートに示した詳細な処理の高いレベルの示すものである。製品２３０５を購入する質問に応答して、売り手は購入オファー２３１０を買い手コンピュータ５０に戻す。この地点において、買い手は図１２に示す購入処理を開始するオプションを有している。継続するために、買い手オーセンティケイタ６５は、どの信用証、例えば、証明書が買い手にとって利用できるかをチェックし、全ての利用可能な信用証を選択して買い手の認可のためにコマースゲートウェイ２３１５に使用させる。買い手コンピュータ５０は全てのアカウントあるいはサブアカウント２３２０のリストを、コマースゲートウェイ５２からの信用証のために要求する。コマースゲートウェイ５２は、選択された信用証を用いて、買い手２３２５により利用可能なアカウントのみに戻される。買い手コンピュータ５０は、コマースゲートウェイ５２から戻されたリストにおけるアカウントの一つを使用することで購入コンファメーション２３３０を生成する。買い手コンピュータ５０は購入コンファメーション２３３５を買い手サーバ５１に送る。売り手サーバ５１はコマースゲートウェイから認可２３４０を要求し、購入コンファメーションが有効であることを認証する。コマースゲートウェイは購入コンファメーションが有効であるという認可２３５０を返す。売り手サーバ５１は売り手コンピュータ５０に、購入コンファメーションが認可されたことを通知する。売り手サーバはデリバリ２３６０のために購入を準備する。この地点で、売り手はコマースゲートウェイ５２から決済トランザクション２３６５を要求する。そして売り手サーバ５１に戻す決済トランザクション２３７０を提供する。売り手サーバ５１は買い手コンピュータ５０にデリバリの詳細を知らせる。最後に、買い手が購入した商品あるいはサービスが配達される２３８０。
【００９５】売り手がオークションウェブサイトの場合には、コマースゲートウェイ５２によって売り手サーバ５１に送られた認可２３４０は、買い手アカウントアイデンティフィケーション、売り手アイデンティフィケーション、売り手販売オファーリング、買い手認可、売り手認可、マスターアイデンティフィケーション、すなわち、コマースゲートウェイ５２のプロバイダのアイデンティフィケーション、のような情報を含む。このタイプの応答に特有なのは、買い手および売り手が、トランザクションに関連するファンドを「保留」する意思があるという最大期間の短い方を合図するのに用いられる失効日／時である。もし、トランザクションが、すなわち、決済リクエスト２３６５、がトランザクションの失効日／時の前にコマースゲートウェイ５２によって受け取られない場合には、製品および／あるいはファンドはその所有者に戻される。後の時において、買い手が購入を行なうと、買い手は売り手が製品を遅滞なくオンデマンドで出荷する能力を証明したことを知っているので、コマースゲートウェイ５２のプロバイダに対して認可をリリースする。これは、ファンドの実際の決済を始動させ、売り手とのさらなるインターアクションを行なうことなく、次の決済バッチにおいて売り手に対する支払いを作動させる。この支払い手法は、オークションやギフト証明購入のような、失効日／時を伴った、買い手始動で、事前許可された購入をサポートする。
【００９６】図２３は有効な購入トランザクションの処理を図示するものであることが理解される。処理の間のいかなる時にエラーがある場合には、例えば、買い手が登録された買い手でないかった場合、消費リミットを越えてしまっている場合等に認可されないような場合、適切なエラー応答が買い手のコンピュータ５０に戻されウェブブラウザ６４を介して買い手に表示された後に、処理は終了する。
【００９７】決済トランザクション
売り手が売り手アカウントを設立すると、売り手とコマースゲートウェイプロバイダとの間の関係を決める契約が形成される。この契約は、いつ支払いがファンドされるか、およびどのような料金がコマースゲートウェイプロバイダに与えられるべきかと言った条件を規定する。コマースゲートウェイフィーは決済毎のフィーあるいはトランザクションの額に基づく料率フィーである。仮想支払いアカウントのための決済トランザクションのロジックは標準クレジットカード決済トランザクションに用いられるロジックと同様である。売り手が製品を出荷した後に、売り手は決済トランザクションを図２４に示すようにコマースゲートウェイ５２に送信する。売り手サーバ５１によって実行されるロジックはコマースエンジンコンポーネント７５、あるいは他のコンポーネント、例えば、売り手サーバ５１に常駐するウェブブラウザ（図示せず）、によって実行され得ることが理解される。
【００９８】図２４は、売り手が決済トランザクションを実行することを希望する時に、売り手サーバ５１によって実行されるロジックを示している。ロジックはブロック５３０で始まり、ブロック５３２に進み、ここでは、図１２のブロック２２２における買い手に関連して示しかつ記載した同じロジックを用いることで、買い手コンピュータ５１とコマースゲートウェイ５２との間の暗号化された接続が確立される。ロジックはブロック５３４に進み、そこで、買い手オーセンティケータ処理が実行される。売り手オーセンティケータ処理は図１３に示され上述された買い手オーセンティケータ処理と同様である。次に、決定ブロック５３６において、売り手が登録された参加者（すなわち、売り手のデジタル証明書がコマースゲートウェイプロバイダによって発行されており、売り手のデジタル証明書が失効しておらず、売り手のデジタル証明書が無効となっていない）かどうかを決定するためのテストが行なわれる。もしそうでないなら、ロジックはブロック５３８に進み、そこでは、売り手認可エラーメッセージが、例えば、ウェブブラウザを介して、売り手サーバのディスプレイ７２に表示される。図２４のロジックはブロック５４８で終了する。
【００９９】売り手認可処理が成功すると、ロジックは決定ブロック５３６からブロック５４４に進み、そこで、決済リクエストがコマースゲートウェイ５２上のトランザクションサーバ８４に送られる。図２５に示され記載されるように、トランザクションサーバ８４はリクエストをクレジット処理サーバアダプタ８６に送り、クレジット処理サーバアダプタは、トランザクションリクエストを適切なクレジット処理サブシステムに送る。決済トランザクションリクエストの場合において、支払い処理サブシステム９５はトランザクションを処理する。支払い処理サブシステムは、決済リクエストを金融機関５９に送る。金融機関はコマースゲートウェイプロバイダアカウントにトランザクションをファンドする。コマースゲートウェイプロバイダはそのパーセンテージを取り、売り手にかららの取り分を支払う。
金融機関５９はその請求サイクル、例えば、マンスリー、を待って、買い手に対して購入および金利をチャージする。金融機関は買い手の支払いを待つ。買い手が支払わない場合には、標準遅延支払い処理、遅延通知、金融チャージ等のような、が実行される。
【０１００】図２５のロジックはブロック２５０５において始まり、ブロック２５１０に進み、そこでは、決済リクエストが受け取られる。決済リクエストのオリジンすなわちソースは、リクエストのコンテキスト、すなわち、日付および時間、と共に、ブロック２５１５において、コマースゲートウェイ５２のメモリ８３に記憶される。要求された決済が許されるかどうかの決定を行なうには数々のファクターが考慮され得る。幾つかのファクターは、オークション決済であって、その時が失効しており、信用証がもはや有効ではない、買い手からの購入コンファメーションを有しない、あるいは、十分なファンドをアカウントに有しない買い手からの購入コンファメーションを有する、トランザクションのための決済リクエストを含む。決済トランザクションを可能としないための他のファクターがあることは理解される。トランザクションが許されない場合には、ロジックはブロック２５６０に進み、そこにおいて、不許可決済リクエストメッセージが要求者、すなわち、この場合は売り手、に送られる。トランザクションが許可される場合には、ロジックは決定ブロック２５２０からブロック２５２５に進み、そこにおいて、トランザクションリクエストは、図２１に示しかつ上述したように、さらなる処理のためにクレジット処理サーバアダプタ８６に送られる。図２０において引き続き、トランザクションサーバがそのトランザクションリクエストに対する応答、例えば、決済リクエストの認可の結果、をブロック２５３０においてクレジット処理アダプタから受け取ると、ロジックはブロック２５３５に進み、そこでは、トランザクションレコード、例えば、購入額を含む購入情報、がコマースゲートウェイ５２のメモリ８３に格納される。ロジックは決定ブロック２５４０に進み、そこでは、トランザクションが成功して処理されたかについて決定するテストが行なわれる。もしそうなら、ロジックはブロック２５４５に進み、そこでは、有効なステータスを伴ったトランザクション応答が要求者、すなわち、この場合には売り手、に送られる。トランザクションが成功して処理されない場合には、ロジックは決定ブロック２５４０からブロック２５５５に進み、そこでは、エラーステータスを伴うトランザクション応答が要求者に返される。
【０１０１】有効なトランザクション応答２５４５の後に、エラートランザクション応答２５５５、すなわち、許可されないトランザクション応答２５６０が要求者に送られ、図２５のロジックはブロック２５５０で終了し、処理は要求者に戻る。
【０１０２】図２４に戻って、トランザクションサーバ８４が決済トランザクションを処理し、決済トランザクションの結果を売り手コンピュータ５１に送信した後、決済トランザクションの結果は、例えば、売り手サーバのウェブブラウザを介して売り手のディスプレイ７３に表示される。図２４のロジックはブロック５４８において終了する。
【０１０３】払い戻しトランザクション
図２６は、払い戻しトランザクションが始動された時、例えば、買い手がその仮想支払いアカウントに対するチャージに異論を唱えた時に、本発明にしたがって実行されるロジックを表している。支払いが問題となった時には、買い手が議論となっている額の全てあるいは部分を受け取るのかを決定しなければならない。この処理は、本発明の仮想支払いシステムに対して外部にあるものである。議論がメリットを有するかは売り手によって決定される。もし売り手が議論がメリットがあると決定すると、売り手はカスタマサービス代表に通知し払い戻しが始動される。図２６に示され、ここに記載される実施例では、買い手によって議論されている額が払い戻しを受けるものである場合には、カスタマサービス代表は払い戻しを始動し、あるいは図２に示す管理コンピュータ５４を介してチェックバックトランザクションを行なう。実際の実施例において、管理コンピュータは「ダムターミナル」であって、これによってカスタマサービス代表はコマースゲートウェイ５２上のトランザクションサーバ８４に情報を直接入力する。他の実施例において、管理コンピュータは、管理者がファイヤーウォール５５の後のＬＡＮ４４上のみで、すなわち、買い手および売り手がこれらの管理ウェブページにアクセスできない、利用可能なウェブページを用いて管理者が情報の入力を行なうことを可能とするウェブブラウザを有している。
【０１０４】図２６において、ロジックはブロック５５０で始まり、ブロック５５２に進み、そこにおいて、アカウント、サブアカウント、および額を含む払い戻し情報が獲得される。払い戻しトランザクション情報は、ブロック５５４において、払い戻しリクエストの形式で、管理コンピュータ５４によってトランザクションサーバ８４に送られる。トランザクションサーバ８４処理は図２０に示されると共に、図２０を参照して記述される。
【０１０５】上述したように、払い戻しリクエストの処理において、トランザクションサーバ８４は、図２２に示すようにアカウント／ビリングサブシステム９４によって処理されるように、トランザクションリクエストを、クレジット処理サーバ５３に送る。買い手の仮想支払い口座に適用される払い戻しは、買い手のバランスを、支払額の分だけ減じる。さらに図２６において、トランザクションサーバ８４が払い戻しトランザクションを処理した後に、トランザクション処理の結果が管理コンピュータ５４によって受け取られて表示される。図２６のロジックはブロック５５８で終了する。購入トランザクションとは異なり、払い戻しトランザクションはウェブサーバ６４を介しての買い手によっては始動されない；したがって、買い手は、他の手段によって、例えば、買い手のコンピュータ５０に電子メールを送信することによって、買い手に知らされる。本発明の他の実施例では、管理コンピュータ５４ではなく、売り手サーバ５１が払い戻しリクエストを始動するようにしてもよいことは理解される。
【０１０６】買い手アカウント管理
標準クレジットカードアカウントのようなアカウントと関連する他のトランザクションは一般的に本発明の仮想支払いアカウントにも適用可能である。図１０Ａ−１０Ｃは、仮想支払いアカウントを有する買い手によるウェブページの幾つかを例示している。これらのトランザクションの処理は、フローチャートに示され、上述されたような他のトランザクション処理と同様であり、したがって、ここでは詳細には説明しない。図１０Ａは、サブアカウント６３４を伴うプライマリーアカウント６３２の詳細を含むウェブパージ６６０を示している。図１０Ｂはマスターアカウント６３４のためのサブアカウントを集計するウェブページ６３２を例示している。図１０Ｃは、与えられたマスターアカウントのためのサブアカウントのトランザクションサマリーウェブページ６７０を示している。
【０１０７】売り手レポート
売り手にとっては、往々にして、そのビジネスの現在の状態を判断するために用いられる詳細なレポートが与えられることが望ましい。したがって、本発明はトランザクションの記録を、容易に検索できるフォーマットにおいて維持する。また、売り手のビジネスに関する同様のレポートには競合者がアクセスできないことが望ましい。したがって、本発明は、売り手のレポートに対する暗号化された確認アクセスを提供する。図４２は、売り手レポートを作るためのロジックを示している。ロジックはブロック４２０１において始まり、ブロック４２１０に進み、売り手コンピュータ５１とコマースゲートウェイ５２との間の暗号化された接続が確立される。ロジックはブロック４２１５に進み、そこにおいて、図１３に示す買い手オーセンティケータと同様に買い手も確認される。フローはブロック４２２０に進み、そこでは、買い手が確認されたかを見るテストが実行される。確認が成功した場合には、ロジックはブロック４２２５に継続し、そこでは、売り手はトランザクションサーバ８４に要求してレポートを生成させる。ブロック４２３０において、トランザクションサーバは関連する情報を検索し、レポート生成し、レポートは、ブロック４２３５において、売り手による閲覧のために売り手のコンピュータによって受け取られる。ロジックはブロック４２９９において終了する。
【０１０８】本発明の実際の実施例において、コマースゲートウェイ５２は、クレジット処理サーバ５３から、特に、クレジット処理サーバに格納された財務データベース９８から、レポート情報を要求する。当業者にとって、財務データベースが報告作成のための情報を格納することに用いられるが、他の目的に関連する情報を格納してもよいことは理解される。
【０１０９】図３１，３３，３５，３７および３９は、売り手に利用可能な報告の例を示すウェブページ３１００，３３００，３５００，３７００および３９００を例示している。図３１は、年間における各月に起きた売上を描くグラフを伴うウェブページ３１００を例示している。図３３は、受け取った特別な注文に関するステータスおよび情報を示す表を伴ったウェブページ３３００を例示している。図３５は、各オーダに関して既に処理が行なわれたとトランザクションおよびその処理の結果をリストする表を伴うウェブページ３５００を例示している。図３７は、販売されたユニットの数、どのくらいの割合のユニットが販売されたか、全体の売上の何パーセントをそのアイテムが占めるか、のような関連する統計に沿ってアイテムの売上をリストする表を伴うウェブページ３７００を例示する。図３９は、まだ処理されていないトランザクションであって、実行されるべき次のトランザクションのバッチを待っているトランザクションをリストする表を伴うウェブページ３９００を例示している。
【０１１０】図３２，３４，３６，３８および４０は、売り手報告をカスタマイズするためのウェブページフォーム３２００，３４００，３６００，４０００を例示している。
【０１１１】好ましい実施形態について図示しかつ説明したが、本発明の精神および範囲を逸脱しないで数々の変更が行なわれ得ることは理解される。例えば、本発明の仮想支払いアカウントに適用可能な他のトランザクション、例えば、アカウントクロージャ、クレジットリミット変更、期限経過アカウント通知等、があることは容易に理解される。これらのトランザクションは、システムの様々なコンポーネントによって始動されることも理解され、例えば、金融機関は、クレジット処理サーバのサブシステムの一つにリクエストを送ることによって、クレジットリミットにおける変更を始める。当業者において、このようなトランザクションのリクエストは、上記に詳述した購入決済や払い戻しトランザクションの処理と同様な態様において、本発明の仮想支払いシステムによって処理されることは理解される。
【図面の簡単な説明】
【図１】  インターネットの代表的な部分のブロック図である（従来技術）。
【図２】  本発明に従って、インターネット上のどこかにあるコンピュータを用いて買い手により注文された商品、サービスおよび／またはコンテンツを供給するインターネットに接続されたローカルエリアネットワーク（LAN）を描いた図である。
【図３】  本発明に従って、インターネットから商品、サービスおよび／またはコンテンツを注文するために使用される、図２に示した買い手のコンピュータの幾つかのコンポーネントのブロック図である。
【図４】  本発明に従って、注文された商品、サービスおよび／またはコンテンツを提供する、図２に示した売り手のコンピュータの幾つかのコンポーネントのブロック図である。
【図５】  本発明に従って、インターネットとクレジット処理サーバとのインターフェースに使用される、図２に示したコマースゲートウェイの幾つかのコンポーネントのブロック図である。
【図６】  本発明に従って、注文された商品、サービスおよび／またはコンテンツの支払いを行う、図２に示したクレジット処理サーバの幾つかのコンポーネントのブロック図である。
【図７】  買い手の仮想支払アカウントを作成するために、買い手のコンピュータ、コマースゲートウェイ、クレジット処理サーバ、アイデンティティビューローおよびクレジットビューローによって行われる作業を示す図である。
【図８】  図８Ａ〜図８Ｇは、本発明に従って仮想支払アカウントを申し込んだときに買い手のコンピュータ上に表示されるウェブページの例である。
【図９】  図９Ａ〜図９Ｃは、本発明に従って申し込まれた仮想支払アカウントをカスタマイズするために買い手によって使用されるウェブページの例である。
【図１０】  図１０Ａ〜図１０Ｃは、本発明に従って買い手のコンピュータに表示される、買い手の仮想支払アカウントについてのアカウントの明細書およびレポートを含むウェブページの例である。
【図１１】  図１１Ａ〜図１１Ｅは、本発明に従って商品、サービスおよび／またはコンテンツを購入するために買い手によって使用されるウェブページの例である。
【図１２】  ウェブブラウザを使用してインターネットから商品、サービスおよび／またはコンテンツを注文するために買い手のコンピュータによって使用されるロジックを示す流れ図である。
【図１３】  買い手が登録された仮想支払アカウントの加入者であることを有効にするためにその買い手のコンピュータの買い手のオーセンティケータ（authenticator）によって使用されるロジックを示す流れ図である。
【図１４】  買い手が登録された仮想支払アカウントの加入者であることを有効にするためにその買い手のコンピュータの他の買い手のオーセンティケータによって使用されるロジックを示す流れ図である。
【図１５】  ウェブブラウザを用いて仮想支払アカウントを申し込むために買い手のコンピュータによって使用されるロジックを示す流れ図である。
【図１６】  本発明に従って新しい買い手のアカウントを開設するために図５に示したコマースゲートウェイの登録サーバ（enrollment server）によって使用されるロジックを示す流れ図である。
【図１７】  あるトランザクションに対するアカウント確認を作成するために図５に示したコマースゲートウェイのアカウント確認コンテナ生成装置（account identification container generator）によって使用されるロジックを示す流れ図である。
【図１８】  インターネット上で商品、サービスおよび／またはコンテンツの注文、出荷、および支払いをするために図４に示した売り手コンピュータのコマース・エンジンによって使用されるロジックを示す流れ図である。
【図１９】  コマースゲートウェイ上のトランザクションサーバにコマース・エンジンを通信させるために図４に示した売り手サーバのコマースゲートウェイ・アダプタによって使用されるロジックを示す流れ図である。
【図２０】  仮想支払アカウントを用いてインターネット上で商品、サービスおよび／またはコンテンツの注文を処理するために図５に示したコマースゲートウェイのトランザクションサーバによって使用されるロジックを示す流れ図である。
【図２１】  仮想支払アカウントを用いてインターネット上で注文された商品、サービスおよび／またはコンテンツの支払いを行うために図６に示したクレジット処理サーバの様々なサブシステムによって使用されるロジックを示す流れ図である。
【図２２】  仮想支払アカウントを用いてインターネット上で注文された商品、サービスおよび／またはコンテンツの支払いを行うために図６に示したクレジット処理サーバの様々なサブシステムによって使用されるロジックを示す流れ図である。
【図２３】  仮想支払アカウントを用いて商品、サービスおよび／またはコンテンツを注文するために買い手のコンピュータ、売り手のサーバおよびコマースゲートウェイによって行われる作業を示す図である。
【図２４】  決済トランザクション、即ち送金の開始を行うために売り手のコンピュータによって使用されるロジックを示す流れ図である。
【図２５】  決済トランザクションを処理するために図５に示したコマースゲートウェイのトランザクションサーバによって使用されるロジックを示す流れ図である。
【図２６】  本発明に従って仮想支払アカウントに当てられる払戻しを開始するために管理者のコンピュータによって使用されるロジックを示す流れ図である。
【図２７】  アイデンティティビューローからの情報に対するリクエストを処理するためにコマースゲートウェイによって使用されるロジックを示す流れ図である。
【図２８】  他の認証メッセージを含むE-メール・コンピュータプログラムのウィンドウの例である。
【図２９】  他の認証メッセージを示す装置の例を描いた図である。
【図３０】  他の認証ダイアログを示すウェブページの例である。
【図３１】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図３２】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図３３】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図３４】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図３５】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図３６】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図３７】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図３８】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図３９】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図４０】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図４１】  トランザクション、支払い状況およびレポートを見るために売り手によって使用されるウェブページの例である。
【図４２】  売り手を認証して売り手のレポートを作成するために使用されるロジックを示す流れ図である。
【図１】
0005405704.tif 000002
【図２】
0005405704.tif 000003
【図３】
0005405704.tif 000004
【図４】
0005405704.tif 000005
【図５】
0005405704.tif 000006
【図６】
0005405704.tif 000007
【図７】
0005405704.tif 000008
【図８Ａ】
0005405704.tif 000009
【図８Ｂ】
0005405704.tif 000010
【図８Ｃ】
0005405704.tif 000011
【図８Ｄ】
0005405704.tif 000012
【図８Ｅ】
0005405704.tif 000013
【図８Ｆ】
0005405704.tif 000014
【図８Ｇ】
0005405704.tif 000015
【図９Ａ】
0005405704.tif 000016
【図９Ｂ】
0005405704.tif 000017
【図９Ｃ】
0005405704.tif 000018
【図１０Ａ】
0005405704.tif 000019
【図１０Ｂ】
0005405704.tif 000020
【図１０Ｃ】
0005405704.tif 000021
【図１１Ａ】
0005405704.tif 000022
【図１１Ｂ】
0005405704.tif 000023
【図１１Ｃ】
0005405704.tif 000024
【図１１Ｄ】
0005405704.tif 000025
【図１１Ｅ】
0005405704.tif 000026
【図１２】
0005405704.tif 000027
【図１３】
0005405704.tif 000028
【図１４】
0005405704.tif 000029
【図１５】
0005405704.tif 000030
【図１６】
0005405704.tif 000031
【図１７】
0005405704.tif 000032
【図１８】
0005405704.tif 000033
【図１９】
0005405704.tif 000034
【図２０】
0005405704.tif 000035
【図２１】
0005405704.tif 000036
【図２２】
0005405704.tif 000037
【図２３】
0005405704.tif 000038
【図２４】
0005405704.tif 000039
【図２５】
0005405704.tif 000040
【図２６】
0005405704.tif 000041
【図２７】
0005405704.tif 000042
【図２８】
0005405704.tif 000043
【図２９】
0005405704.tif 000044
【図３０】
0005405704.tif 000045
【図３１】
0005405704.tif 000046
【図３２】
0005405704.tif 000047
【図３３】
0005405704.tif 000048
【図３４】
0005405704.tif 000049
【図３５】
0005405704.tif 000050
【図３６】
0005405704.tif 000051
【図３７】
0005405704.tif 000052
【図３８】
0005405704.tif 000053
【図３９】
0005405704.tif 000054
【図４０】
0005405704.tif 000055
【図４１】
0005405704.tif 000056
【図４２】
0005405704.tif 000057