電子取引を行うための方法および装置
【課題】オーバーヘッドなく、インターネットウォレットやベンダのサービスと一体化しうる高いセキュリティの電子取引システムを提供する。
【解決手段】電子商取引を行うためのシステムおよび方法を開示する。電子取引は、購入取引である。ユーザ１１０に、デジタル証明書を含むスマートカードなどのインテリジェントトークンが提供される。このインテリジェントトークンは、ユーザに代わって取引のすべてまたはその部分を行うネットワーク１０２上のサーバと適切に認証を行う。ウォレットサーバ１４０がセキュリティサーバ１３０と対話して、取引におけるより高い信頼性と信用を提供する。ウォレットサーバは、ツールバーを含む。デジタルウォレットが、書式を事前記入する。書式は、自動記憶構成要素を使用して事前記入されることが可能である。
【解決手段】電子商取引を行うためのシステムおよび方法を開示する。電子取引は、購入取引である。ユーザ１１０に、デジタル証明書を含むスマートカードなどのインテリジェントトークンが提供される。このインテリジェントトークンは、ユーザに代わって取引のすべてまたはその部分を行うネットワーク１０２上のサーバと適切に認証を行う。ウォレットサーバ１４０がセキュリティサーバ１３０と対話して、取引におけるより高い信頼性と信用を提供する。ウォレットサーバは、ツールバーを含む。デジタルウォレットが、書式を事前記入する。書式は、自動記憶構成要素を使用して事前記入されることが可能である。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、一般に、ネットワーク取引を行うための方法および装置に関する。より詳細には、本発明は、インターネットなどのデータネットワークを介してビジネスを認証し、行うためのシステムに関する。
【背景技術】
【０００２】
発明の背景
近年、多くの消費者が、電子方式で商品およびサービスを購入することの便利さと経済性を知るようになった。電子購入（通常、「ｅ購入」と呼ばれる）のためのいくつかのチャネルが利用可能であり、これには、ショップアットホームテレビジョンネットワークやテレビジョン広告に対するコールイン応答等が含まれる。最近では、インターネットを介する直接購入が極めて普及してきている。
【０００３】
通常のインターネット取引においては、消費者は、一般に、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）ブラウザを介して提供されるハイパーテキストマークアップ言語（ＨＴＭＬ）文書などのオンライン広告を閲覧することにより、購入する商品および／またはサービスを識別している。支払いは、通常、消費者と商店の間で確立されるセキュアソケットレイヤ（ＳＳＬ）接続などのセキュアなチャネルを介して提供される課金カード番号を介して行われる。課金カード口座番号は、通常、１６桁のクレジットカード番号である。クレジットカード番号は、通常、番号「００００ ００００ ００００ ００００」によって代表されるような間隔を有する４組の数字を有する標準化された形式に準拠している。最初の５桁から７桁は、処理目的のために予約されており、発行銀行、カードタイプ等を識別する。最後の第１６桁は、１６桁番号のための合計検査として使用される。中間の８から１０桁は、顧客を一意的に識別するのに使用される。この場合、商店は、例えば、カード発行者から直接に認証を受けることによって課金カード番号を処理し、その後、取引を完了する。ＳＳＬ標準は、例えば、「ｈｔｔｐ：／／ｈｏｍｅ．ｎｅｔｓｃａｐｅ．ｃｏｍ／ｅｎｇ／ｓｓｌ３／ｄｒａｆｔ３０２．ｔｘｔ」においてオンラインで利用できる１９９６年１１月１８日付けの「Ｔｈｅ ＳＳＬ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ３．０」によって説明されており、その内容全体が、参照により、本明細書に組み込まれる。
【０００４】
毎日、数百万の取引がインターネットを介して行われるが、従来のＳＳＬ取引は、しばしば、いくつかの顕著な欠点を示す。ＳＳＬは、通常、非良心的なサードパーティが盗聴（例えば、「スニフィング」）する、または別の仕方で購入者の課金カード番号を入手するのを防止するセキュアな終端間接続を提供するが、このプロトコルは、課金カード番号そのものが有効であること、またはそのカード番号を提供している人がそうすることを法的に許可されていることを確実にするためのどのような手段も提供していない。インターネット取引における詐欺の発生件数が高いため、ほとんどの課金カード発行者は、より高い割引率が適用される「Ｃａｒｄ Ｎｏｔ Ｐｒｅｓｅｎｔ」取引であるとネットワーク取引を見なす。言い換えれば、「Ｃａｒｄ Ｎｏｔ Ｐｒｅｓｅｎｔ」取引によるより高いリスクのため、ほとんどの課金カード発行者は、電子手段を介してカード番号を受諾することに関して、カードが商店に物理的に提示された場合に課されるよ
りも高いレートを商店に課す。
【０００５】
セキュアでないネットワークを介して課金カード番号をトランスポートすることに固有のセキュリティの不備を改善するため、多くの人々が、「スマートカード」の使用を示唆している。スマートカードは、通常、そのカード上に直接にデータを記憶するためのマイクロプロセッサおよびメモリを有する集積回路チップを含む。そのデータは、例えば、暗号キーに対応する、または通貨の電子価値を保持する電子財布に対応することが可能である。従来技術において多くのスマートカードスキームが示唆されているが、これらは、通常、非標準であるという点で、顕著な欠点を示している。言い換えれば、商店は、通常、自体のＷｅｂ店頭でスマートカード取引を受諾するためには、新しいプロプラエタリ・ソフトウェアを入手しなければならない。さらに、スマートカードと関連する暗号情報を割り当て、それを維持することに関わる管理コストは、現在まで、非常に高いものとなっている。
【０００６】
様々な暗号技法の使用を介してインターネット取引のセキュリティを改善するＳｅｃｕｒｅ Ｅｌｅｃｔｒｏｎｉｃ Ｔｒａｎｓａｃｔｉｏｎ（ＳＥＴ）標準が示唆されている。ＳＥＴは、標準ＳＳＬ取引に優るより高いセキュリティを提供するが、取引を行うのに必要とされる様々な公開キーおよび秘密キーに関わる管理のため、ＳＥＴは、広く受け入れられずに留まっている。また、ＳＥＴは、ＳＥＴ取引をサポートすることを所望する商店が特別のソフトウェアを有するこ
とを必要とする。
【０００７】
例えば、テキサス州、７８７４６、 Ａｕｓｔｉｎ、１２５０ Ｃａｐｉｔａｌ ｏｆ Ｔｅｘａｓ Ｈｉｇｈｗａｙ Ｓｏｕｔｈ、 Ｂｕｉｌｄｉｎｇ Ｏｎｅ、Ｓｕｉｔｅ ３００のＧｌｏｂｅＳｅｔ，Ｉｎｃ．によって提供されるデジタルウォレット技術などの既存のデジタルウォレット技術は、顧客が取引カード商品（例えば、クレジットカード、課金カード、デビットカード、スマートカード、口座番号等）を利用してオンラインで商品およびサービスのための支払いを行うための手段を提供している。一般に、デジタルウォレットは、電子商取引または他のネットワーク対話を円滑にするために、個人情報（名前、アドレス、課金カード番号、クレジットカード番号等）を記憶するツールである。個人情報は、汎用サーバ上に、またはクライアントロケーション（ＰＣまたはスマートカード）で、あるいは汎用サーバとクライアントサーバの混成物上に記憶することができる。デジタルウォレット汎用サーバは、Ｗｅｂサーバ、および顧客の個人情報およびクレジットカード情報、シッピング選好、ならびにオンライン商店のプロファイルを集中的に格納するデータベースサーバから構成される。
【０００８】
デジタルウォレットは、好ましくは、シングルサインオン／ワンパスワード、チェックアウトページの自動書式記入、ワンクリック購入またはツークリック購入、Ｗｅｂサイトの個人設定、オンライン注文および配送追跡、項目別電子領収書、ならびに支出パターンおよびオプトインに基づくカストマイズされた売出しおよびカストマイズされた販売促進などの機能を行う。より詳細には、ワンクリック購入がウォレットを活動化し、それと同時に、購入を確認する。ツークリックチェックアウトは、まず、ウォレットを活動化し、次に、第２のクリックが購入を確認する。
【０００９】
使用の際、ウォレットブックマークが、通常、顧客によってクリックされて、ウォレットサーバとのＳＳＬセッションが確立される。ブラウザプラグインが実行され、顧客が、ウォレットデータに対するアクセスを得るために、認証のためのＩＤ／パスワードまたはスマートカードを供給する。オンライン商店で買物をする際、適切なウォレットデータが、ウォレットサーバから商店のＷｅｂサーバに転送される。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
したがって、電子取引を行う新しいシステムが所望される。そのようなシステムは、顧客および商店にとってのさらなるオーバーヘッドなしに、より高いセキュリティを提供しなければならない。さらに、そのような新しいシステムは、様々なインターネットウォレットおよび様々なベンダによって提供される他のサービスとよく一体化しなければならない。
【課題を解決するための手段】
【００１１】
発明の概要
本発明の例としての実施形態では、ユーザに、電子取引を行う際に使用することが可能な、スマートカードなどのインテリジェントトークンが提供される。インテリジェントトークンは、デジタル証明書を含み、ユーザに代わって取引のすべてまたはいくつかの部分を行うネットワーク上のサーバと適切に認証を行う。ユーザは、購入取引を行う購入者であり、またサーバは、セキュリティサーバと対話して取引におけるより高い信頼性および信用を提供するウォレットサーバである。
【００１２】
購入取引などの電子取引は、サーバにおいてユーザからの取引要求を受信し、ユーザに対する課題を発行し、その課題に基づいてユーザから応答を受信し、その応答を処理して取引機器を検証し、その電子取引に関する少なくとも１つのキーを含む信用証明を集め、その信用証明の少なくとも一部をユーザに提供し、その信用証明のその一部を含む第２の要求をユーザから受信し、その信用証明のその一部をそのキーで妥当性検査して取引サービスに対するアクセスを提供することによって行われる。
【００１３】
さらに、本発明は、少なくとも選択されたプロトコルに関してネットワークサーバに対するアクセスをそのネットワークサーバの一部分に制限し、また選択されたプロトコルと関連する特定の文字に関してネットワークサーバのその部分をスキャンすることによって、ネットワークサーバを攻撃から守る。それらの特定の文字は、選択されたプロトコルによってもたらされるセキュリティリスクを減らすために、除去すること、または当たり障りのない文字によって置き換えることができる。好ましくは、セキュリティログを形成するために、それらの文字をログ記録することができる。このセキュリティログを検査して、特定の文字が敵意のあるものであるかどうかを判定することができる。あるいは、要求を拒否することができる。
【００１４】
また、本発明は、アクティベータおよびツールバーを有する、購入取引を行うのに使用するデジタルウォレットなどの、取引ツールも含む。好ましくは、ツールバーにより、ユーザは、アクティベータの小さいダウンロードを行うことができ、またツールバーは、例えば、１つまたは複数のオペレーティングシステムコントロール、例えば、システムトレイアイコンを利用する。また、取引ツールは、書式記入構成要素、およびユーザによって以前に提供された情報で書式を事前記入するための自動記憶構成要素も含む。
【００１５】
本発明の以上の特徴および利点、ならびにその他の特徴および利点は、添付の図面と併せて読まれるべき例としての実施形態の以下の詳細な説明において、以降、説明する。図面では、同じ参照番号は、同様の図面における同一または同様の部分を識別するために使用する。
【図面の簡単な説明】
【００１６】
【図１Ａ】図１Ａ〜１Ｃは実施例としての取引システムの様々な実施形態を示すブロック図である。
【図１Ｂ】図１Ａ〜１Ｃは実施例としての取引システムの様々な実施形態を示すブロック図である。
【図１Ｃ】図１Ａ〜１Ｃは実施例としての取引システムの様々な実施形態を示すブロック図である。
【図２】実施例としての購入システムを示すブロック図である。
【図３】実施例としてのセキュリティシステムを示すブロック図である。
【図４】実施例としてのウォレットサーバを示すブロック図である。
【図５】本発明によって形成したデジタルウォレットの実施形態に関する実施例としてのスクリーン表示である。
【図６】本発明によって形成したデジタルウォレットの実施形態に関する実施例としてのスクリーン表示である。
【図７】本発明によって形成したデジタルウォレットの実施形態に関する実施例としてのスクリーン表示である。
【図８】本発明によって形成したデジタルウォレットの実施形態に関する実施例としてのスクリーン表示である。
【図９】実施例としてのアクティベータアプリケーションによって実行される例としてのプロセスを示す流れ図である。
【図１０】実施例のログインのシーケンスを示すメッセージシーケンスチャートである。
【図１１】実施例としての購入のシーケンスを示すメッセージシーケンスチャートである。
【図１２】図１２Ａは、多くのスクリプト記述言語で遭遇するセキュリティ問題の可能性を示すメッセージシーケンスチャートである。 図１２Ｂは、図１２Ａに示したセキュリティ問題のない正しい通信フローを示すメッセージシーケンスチャートである。
【図１３】不要な実行可能コードを削減または除去するための実施例としてのプロセスを示す流れ図である。
【発明を実施するための形態】
【００１７】
好適な例示的実施形態の詳細な説明
本発明は、本明細書では、機能ブロック構成要素および様々な処理ステップの点で説明することができる。そのような機能ブロックは、特定の機能を行うように構成された任意の数のハードウェア構成要素および／またはソフトウェア構成要素によって実現するのが可能なことを理解されたい。例えば、本発明は、様々な集積回路（Ｉ．Ｃ．）構成要素、例えば、メモリ要素、処理要素、論理要素、ルックアップテーブル等を使用することが可能であり、これらの構成要素は、１つまたは複数のマイクロプロセッサまたはその他の制御デバイスの制御の下で、様々な機能を実行することができる。同様に、本発明のソフトウェア要素は、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、ＣＯＢＯＬ、アセンブラ、ＰＥＲＬ、またはそれに類するものなどの、任意のプログラミング言語またはスクリプト記述を使用して実装することが可能であり、その様々なアルゴリズムは、データ構造、オブジェクト、プロセス、ルーチン、またはその他のプログラミング要素の任意の組合せで実装される。さらに、本発明は、データ伝送、シグナリング、データ処理、ネットワーク制御等のための任意の数の従来の技法を使用することができる。また、さらに、本発明を使用して、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、ＶＢＳｃｒｉｐｔ、またはそれに類するものなどのスクリプト記述言語のセキュリティ問題を検出または防止することが可能である。
【００１８】
本明細書に示し、説明する特定の実施態様は、本発明およびその最適の形態を例示するものであり、それ以外にいかなる意味でも本発明の範囲を限定するものではないことを理解されたい。実際、簡明にするため、本明細書では、システムの従来のデータネットワーク機能の態様、アプリケーション開発の態様、およびその他の機能の態様（およびシステムの個々に動作する構成要素の構成要素）は、詳細に説明しないことがあり得る。さらに、本明細書に含まれる様々な図に示す接続回線は、様々な要素間の実施例としての機能関係および／または物理結合を表すものとする。実際の電子取引システムにおいては、多くの代替または追加の機能関係または物理接続が存在する可能性があることに留意されたい。
【００１９】
例としての実施形態の説明を簡明にするため、本発明は、しばしば、インターネット上で動作する電子商取引のシステムに関するものとして説明する。ただし、本発明の多くの適用例を構想できることが理解されよう。例えば、このシステムは、コンピュータシステムのユーザを認証するために、またはパスコードシステムを起動するために、あるいは他の任意の目的で使用するのが可能である。同様に、本発明は、任意のバージョンのＷｉｎｄｏｗｓ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標） ＮＴ、Ｗｉｎｄｏｗｓ（登録商標）２０００、Ｗｉｎｄｏｗｓ（登録商標） ９８、Ｗｉｎｄｏｗｓ（登録商標） ９５、ＭａｃＯＳ、ＯＳ／２、ＢｅＯＳ、Ｌｉｎｕｘ、ＵＮＩＸ（登録商標）、またはそれに類するものなどの任意のオペレーティングシステムを実行する任意のタイプのパーソナルコンピュータ、ネットワークコンピュータ、ワークステーション、ミニコンピュータ、メインフレーム、またはそれに類するものと併せて使用するのが可能である。さらに、本発明は、本明細書では、しばしば、ＴＣＰ／ＩＰ通信プロトコルを使用して実装されるものとして説明するが、ＩＰＸ、Ａｐｐｌｅｔａｌｋ、ＩＰ−６、ＮｅｔＢＩＯＳ、ＯＳＩ、あるいは任意の数の既存のプロトコルまたは将来のプロトコルを使用して本発明を実装することも可能なことが容易に理解されよう。
【００２０】
さらに、顧客および商店は、個々の人々、エンティティ、またはビジネスを代表することが可能であり、一方、銀行は、クレジットカード会社、カードスポンサ会社、または金融機関と契約しているサードパーティ発行者などの他のタイプのカード発行機関を代表することが可能である。支払いネットワークには、クレジットカード、デビットカード、およびその他のタイプの融資／金融カードに関する取引に現在、対応している既存のプロプラエタリネットワークが含まれる。支払いネットワークは、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（登録商標）ネットワーク、ＶｉｓａＮｅｔ（登録商標）ネットワーク、またはＶｅｒｉｐｈｏｎｅ（登録商標）などの、盗聴に対してセキュアであると考えられる閉じたネットワークである。
【００２１】
さらに、中間決済機関などの他の参加者が取引のいくつかの段階において関与していることが可能であるが、これらの参加者は図示していない。各参加者は、取引を円滑にするためのコンピュータシステムを備えている。顧客はパーソナルコンピュータを有し、商店はコンピュータ／サーバを有し、また銀行はメインフレームコンピュータを有している。ただし、これらのコンピュータのどれも、ミニコンピュータ、ＰＣサーバ、コンピュータのネットワークセット、ラップトップ、ノートブック、ハンドヘルドコンピュータ、セットトップボックス等である
ことが可能である。
【００２２】
次に、図１Ａを参照すると、取引システム１００が、少なくとも１つのユーザコンピュータ１１０と、取引オーソライザコンピュータ１２０と、セキュリティサーバ１３０と、オプションの取引ツールサーバ１４０とを適切に含んでいる。本明細書に詳細に説明する様々な実施形態では、取引システム１００は、購入取引を行うために電子商取引で使用される。具体的には、ユーザコンピュータ１１０が購入者または顧客のコンピュータであり、取引オーソライザコンピュータ１２０が商店コンピュータであり、また取引ツールサーバ１４０がデジタルウォレットサーバである。本明細書に説明する取引システムは、電子商取引システムであるが、本発明は他の様々な電子取引システムにも同様に適用可能であることが
理解されよう。
【００２３】
様々なコンピュータシステムおよびサーバは、インターネットまたは別の公衆データネットワークなどの任意のデータネットワークであるデータネットワーク１０２によって適切に相互接続されている。その他の適切なネットワーク１０２には、公衆交換電話網（ＰＳＴＮ）、企業イントラネットまたは大学イントラネット等が含まれる。図１Ｂに示すもののような様々な実施形態では、商店コンピュータ１２０は、ネットワーク１０２とは別個のデータ接続１５２を介してセキュリティサーバ１３０に電子的に結合されている。同様に、様々な実施形態は、ウォレットサーバ１４０とセキュリティサーバ１３０を接続するネットワーク１０２とは別個の接続１５０を含む。接続１５０および１５２で使用するのに適した実施例としてのデータ接続には、電話接続、ＩＳＤＮ接続、専用Ｔ１、またはその他のデータ接続、ワイヤレス接続等が含まれる。接続１５０および接続１５２は、同一の接続であること、あるいは、それぞれが、本発明の様々な実施形態における完全に別の形態の接続であることが可能であるのが理解されよう。
【００２４】
また、図１Ｃに示すもののような様々な実施形態は、アプリケーションサーバ１６０を含む。様々な実施形態では、データベース（図示せず）および／またはプロファイルサーバ（図示せず）がアプリケーションサーバ１６０および／またはウォレットサーバ１４０に接続されていることが可能である。アプリケーションサーバ１６０は、ワークロードの均衡をとるのに使用することができる。デジタルウォレット１４０とアプリケーションサーバ１６０の間でワークロードを分散することにより、効率および／またはセキュリティを高めることができる。例えば、アプリケーションサーバ１６０は、データベースアクセスなどの、ウォレットサーバ１４０によって行われる機能性のいくらかを行うことができる。アプリケーションサーバ１６０はデータネットワーク１０２に接続されていないので、データベースアクセスをウォレットサーバ１４０ではなくアプリケーションサーバ１６０によって行わせることにより、セキュリティを高めることができる。
【００２５】
図１Ａ〜１Ｃに様々な例としての実施形態を示したが、その他の実施形態も可能であることが理解されよう。例えば、一実施形態は、接続１５０を含むが、接続１５２は含まないこと、またはその逆であることが可能である。さらに、構成要素（例えば、顧客１１０、商店１２０、セキュリティサーバ１３０、ウォレットサーバ１４０、およびアプリケーションサーバ１６０）は、個々のコンピュータであること、あるいは、本明細書に説明する機能を満たす同様の目的で動作するネットワーク化されたグループのコンピュータであることが可能である。前述の機能性を満たすために、単一の構成要素に帰せられた機能性を１つまたは複数の個々のコンピュータに分散することが可能である。例えば、ウォレットサーバ１４０は、実際には、Ｗｅｂサーバ、アプリケーションサーバ、データベースサーバ、およびその他のタイプのサーバの集合であることが可能である。
【００２６】
取引を行うため、顧客１１０が、ネットワーク１０２を介して商店１２０と適切に接続を確立する。購入を達しようとするとき、顧客１１０がウォレットサーバ１４０にアクセスする。この時点で、顧客１１０がセキュリティサーバ１３０にリダイレクトされ、顧客がスマートカードを有していることが検証される。スマートカードは、そのカードを一意的に識別するデジタル証明書を含み、以下に説明するとおり、取引に関係するデジタル信用証明を作成できるようにしている。様々な実施形態では、デジタル信用証明のいくつかの部分が顧客１１０に戻され、一部がセキュアな接続１５０を介してウォレットサーバ１４０に提供される。次に、顧客１１０は、そのデジタル信用証明を使用してウォレットサーバ１４０に対して認証を行うことができ、このウォレットサーバが顧客１１０のためのプロキシとして電子取引を完了することができる。ウォレットサーバ１４０は、例えば、商店コンピュータ１２０に関連する購入書式を完成させるための機能性を含むことが可能である。商店１２０が顧客１１０から、またはウォレットサーバ１４０からセキュア購入機器識別子を受信したとき、通常の任意の課金カード認証と同様に、接続１５２を介してカード認証が行われる。前述したとおり、通信は、様々なプロトコル、例えば、ＳＳＬまたはＶＰＮ等を使用して行うことができる。スマートカードは、特定のカードに固有であり、また電子手段を介してネットワークに知らせることの可能な識別情報を含むので、スマートカードを使用して行われる購入取引は、通常の課金カードまたはクレジットカードを使用して行われる取引よりもセキュアである。セキュアな取引に対しては、より低い割引率が見合うものとなる可能性があり、この取引は、カード発行者によって「Ｃａｒｄ Ｐｒｅｓｅｎｔ」取引として処理される可能性がある。さらに、取引が「Ｃａｒｄ Ｐｒｅｓｅｎｔ」取引である場合、詐欺のリスクを商店からカード発行者に転移することができる。
【００２７】
次に、図２を参照すると、実施例としての購入者コンピュータ１１０（クライアントコンピュータ、顧客コンピュータ、またはユーザコンピュータとも呼ぶ）は、データネットワーク１０２上で電子購入取引を開始することができる任意のコンピュータシステムである。様々な実施形態では、購入者コンピュータ１１０は、ワシントン州、ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能な任意のバージョンのＷｉｎｄｏｗｓ（登録商標）オペレーティングシステム、またはカリフォルニア州、ＣｕｐｅｒｔｉｎｏのＡｐｐｌｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能な任意のバージョンのＭａｃＯＳオペレーティングシステムなどの任意のオペレーティングシステムを実行するパーソナルコンピュータである。
【００２８】
購入者コンピュータ１１０は、スマートカード２０２が、オペレーティングシステム２１２を介してＷｅｂブラウザ２１６とインターフェースをとることを可能にするハードウェアおよび／またはソフトウェアを適切に含む。Ｗｅｂブラウザ２１６は、カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＮｅｔｓｃａｐｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＮｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｏｒ、ワシントン州、ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、またはバージニア州、ＤｕｌｌｅｓのＡｍｅｒｉｃａ Ｏｎｌｉｎｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＡＯＬ Ｂｒｏｗｓｅｒなどの、ネットワーク１０２を介して通信する、購入者コンピュータ１１０と適合する任意のプログラムである。様々な実施形態では、購入者コンピュータ１１０は、ウォレットサーバ１４０と通信するように構成された任意のコンピュータプログラムであるウォレットクライアント２１４を含む。実施例としてのウォレットクライアント２１４は、Ｍｉｃｒｏｓｏｆｔ Ｗａｌｌｅｔ、またはテキサス州、ＡｕｓｔｉｎのＧｌｏｂｅｓｅｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＧｌｏｂｅｓｅｔ Ｗａｌｌｅｔである。ただし、任意のウォレットプログラムを使用することが可能である。
【００２９】
ウォレットクライアント２１４およびブラウザ２１６は、オペレーティングシステム２１２を介してカードリーダ２０４にデータを送ることによってスマートカード２０２と対話することができる。カードリーダ２０４は、ウォレットクライアント２１４とスマートカード２０２の間で情報を転送することができる任意のリーダデバイスである。様々な実施形態では、カードリーダ２０４は、カリフォルニア州、Ｒｅｄｗｏｏｄ ＣｉｔｙのＧｅｍｐｌｕｓ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＭｏｄｅｌ ＧＣＲ４１０などのＩＳＯ−７８１６対応のリーダ、またはその他の任意の適切なリーダである。
【００３０】
スマートカード２０２は、以下のＩＳＯ標準に対応する任意のスマートカードなどの、電子取引を行うことができる任意のカードであり、これらすべての標準は、参照により、その全体が本明細書に組み込まれる。
【００３１】
ＩＳＯ／ＩＥＣ ７８１６−１：１９９８ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ １： Ｐｈｙｓｉｃａｌ ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ、
ＩＳＯ／ＩＥＣ ７８１６−２：１９９９ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ２： Ｄｉｍｅｎｓｉｏｎｓ ａｎｄ ｌｏｃａｔｉｏｎ ｏｆ ｔｈｅ ｃｏｎｔａｃｔｓ、
ＩＳＯ／ＩＥＣ ７８１６−３：１９９７ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ３： Ｅｌｅｃｔｒｏｎｉｃ ｓｉｇｎａｌｓ ａｎｄ ｔｒａｎｓｍｉｓｓｉｏｎ ｐｒｏｔｏｃｏｌｓ、
ＩＳＯ／ＩＥＣ ７８１６−４：１９９５ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ４： Ｉｎｔｅｒｉｎｄｕｓｔｒｙ ｃｏｍｍａｎｄｓ ｆｏｒ ｉｎｔｅｒｃｈａｎｇｅ、
ＩＳＯ／ＩＥＣ ７８１６−５：１９９４ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ５： Ｎｕｍｂｅｒｉｎｇ ｓｙｓｔｅｍ ａｎｄ ｒｅｇｉｓｔｒａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ ｆｏｒ ａｐｐｌｉｃａｔｉｏｎ ｉｄｅｎｔｉｆｉｅｒｓ、
ＩＳＯ／ＩＥＣ ７８１６−６：１９９６ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ６： Ｉｎｔｅｒｉｎｄｕｓｔｒｙ ｄａｔａ ｅｌｅｍｅｎｔｓ、および
ＩＳＯ／ＩＥＣ ７８１６−７：１９９９ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ７： Ｉｎｔｅｒｉｎｄｕｓｔｒｙ ｃｏｍｍａｎｄｓ ｆｏｒ Ｓｔｒｕｃｔｕｒｅｄ Ｃａｒｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ（ＳＣＱＬ）。
【００３２】
実施例としてのスマートカード２０２は、独国、ＭｕｎｉｃｈのＩｎｆｉｎｅｏｎ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なモデルＳＬＥ６６チップを含むＩＳＯ ７８１６規格に準拠するスマートカードである。ＳＬＥ６６チップは、メモリ（１６ｋメモリなどであるが、より多いまたはより少ないメモリを使用することも可能である）、および、例えば、Ｍｕｌｔｏｓオペレーティングシステム（Ｍｕｌｔｏｓ ｖ．４など）を実行するプロセッサを含む。様々な実施形態では、スマートカード２０２は、また、デジタル証明書を記憶し、それを処理するためのアプレットまたはその他の暗号関数も含む。暗号法の基本的な概説に関しては、Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓによって刊行されたＢｒｕｃｅ Ｓｃｈｎｅｉｅｒによる「Ａｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ： Ｐｒｏｔｏｃｏｌｓ，Ａｌｇｏｒｔｈｍｓ，Ａｎｄ Ｓｏｕｒｃｅ Ｃｏｄｅ Ｉｎ Ｃ」（第２版、１９９６年）を参照されたい。この刊行物は、参照によって本明細書に組み込まれる。例えば、Ｘ．５０９ Ｊａｖａ（登録商標）アプレットをスマートカード２０２上に、そこに記憶されたＸ．５０９証明書を処理するために含めることが可能である。本明細書に説明する実施形態はスマートカードを利用するが、その他のインテリジェントトークン、例えば、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＧＳＭ）のモバイル電話機で本発明の様々な実施形態におけるスマートカードを置き換えることが可能である。
【００３３】
次に、図３を参照すると、セキュリティサーバ１３０が、ネットワーク１０２に対するインターフェース、セキュリティエンジン３０４、およびデータベース３１０と通信する認証サーバ３０６を適切に含む。ネットワークインターフェース３０２は、Ｗｅｂサーバなどの、ネットワーク１０２上の通信を円滑にする任意のプログラムである。様々な実施形態では、ネットワークインターフェース３０２は、カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＮｅｔｓｃａｐｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＮｅｔｓｃａｐｅ Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｅｒに基づく。ネットワークインターフェース３０２は、ネットワーク１０２上で電子メッセージを受信し、適切なように、それらをセキュリティエンジン３０４または認証サーバ３０６に経路指定する。
【００３４】
セキュリティエンジン３０４と認証サーバ３０６は、ファイアウォール３０８によって隔てられていることが可能である。ファイアウォール３０８は、内部ネットワークと外部ネットワーク（図示せず）の間におけるデータフローを制限することができる任意のハードウェアまたはソフトウェアのコントロール（ルータアクセスコントロールなど）である。様々な実施形態では、セキュリティエンジン３０４は、ファイアウォールの外側に常駐して、セキュリティサーバ１３０と顧客１１０またはウォレットサーバ１４０との間におけるデータ転送を適切に管理する。認証サーバ３０６は、システム１００と関連する様々なスマートカード２０２上に記憶されたｘ．５０９証明書の相互参照を含むことが可能な、データベース３１０などの貴重な機密情報を保持し、したがって、より高いセキュリティのために内部ネットワーク上で適切に保守されていることが可能である。本発明の範囲を逸脱することなく、セキュリティエンジン３０４の機能性と認証サーバ３０６の機能性を適切に組み合わせる、または分離するのが可能なことが理解されよう。
【００３５】
次に、図４を参照すると、実施例としてのウォレットサーバ１４０が、ネットワークインターフェース４０２と、オプションのアプレットサーバ４０４と、ウォレットアプリケーション４０６とを含む。ネットワークインターフェース４０２は、Ｗｅｂサーバなどの、ネットワーク１０２上の通信を円滑にする任意のプログラムである。様々な実施形態では、ネットワークインターフェース４０２は、カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＮｅｔｓｃａｐｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＮｅｔｓｃａｐｅ Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｅｒに基づく。オプションのアプレットサーバ４０４は、Ｊａｖａ（登録商標）プログラムまたはＡｃｔｉｖｅＸコントロールなどの分散型プログラムのためのサーバ機能性を提供する。実施例としてのアプレットサーバは、カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓから入手可能なＪａｖａ（登録商標） Ａｐｐｌｅｔ Ｓｅｒｖｅｒである。アプレットサーバ４０４およびネットワークインターフェース４０２は、ログイン機能性を扱い、ウォレットデータベース４０８からウォレットデータを検索し、かつ／または本明細書に説明する取引を管理することができる、ウォレットアプリケーション４０６のためのサポート機能性を提供する。本発明の様々な実施形態では、ウォレットサーバ１４０は、テキサス州、ＡｕｓｔｉｎのＧｌｏｂｅｓｅｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＳＥＲＶＥＲＷＡＬＬＥＴ（別名、ＮＥＴＷＡＬＬＥＴ）プログラムを含むことが可能である。
【００３６】
本発明の様々な実施形態は、ウォレット購入プロセスで消費者を適切に助けるアクティベータアプリケーションを含むことが可能である。アクティベータアプリケーションは、例えば、ステータス情報を提示すること、または、適切なときにウォレットクライアント２１４（図２）を能動的に起動することができる。さらに、アクティベータは、ウォレットによってサポートされるサイトのローカルキャッシュを保持することができる。
【００３７】
アクティベータアプリケーションプログラムは、従来のコンピュータアプリケーションとして実装することができる。様々な実施形態では、アクティベータアプリケーションは、システムトレイアイコンとして、「浮動ビットマップ」として、またはその他の任意の適切な仕方で情報を表示する。グラフィック表現（例えば、アイコン）が、「サポートされたサイトでブラウズ中」、「サポートされたチェックアウトページでブラウズ中」、「サポートされた支払いページでブラウザ中」、「開いたブラウザウィンドウなし」、「サポートされていないページでブラウズ中」、および／またはそれに類するものなどのステータス情報を示す
ことが可能である。
【００３８】
浮動ビットマップは、任意のグラフィックファイルまたはグラフィック形式、例えば、Ｇｒａｐｈｉｃｓ Ｉｎｔｅｒｃｈａｎｇｅ Ｆｏｒｍａｔ（ＧＩＦ）ファイルで実装することができる。代替の実施形態は、グラフィック形式、オーディオ形式、ビジュアル形式、オーディオビジュアル形式、マルチメディア形式、動画形式、またはその他の形式で情報を提示する。さらに、ＧＩＦファイルは、ＬＺＷファイル、ＴＩＦＦファイル、動画ＧＩＦファイル、ＪＰＥＧファイル、ＭＰＥＧファイル、あるいは他の任意の種類のグラフィック、オーディオ、もしくはマルチメディアの形式またはファイルで置き換えることが可能である。
【００３９】
好ましくは、本発明は、ユーザがより容易に取引ツールを使用できるようにするコントロールを含むウィンドウを備えた取引ツールを提供することによって機能強化される。取引ツールは、様々な電子取引のために使用することができる。例えば、購入取引、財務相談取引、保険取引、物々交換取引などの消費者間取引、売出しまたは報償に関する取引等である。本明細書に詳細に説明する取引ツールは、電子購入取引のために使用されるデジタルウォレットである。デジタルウォレットは、顧客がより容易にウォレットを使用するためのコントロールを備えたウィンドウを提供することによって機能強化される。好ましくは、本発明は、デジタルウォレット機能性にアクセスするためのクライアント側の実装（「アクティベータ」）、およびユーザがアクティベータの小さいダウンロードを行い、かつオペレーティングシステムユーザインターフェースの１つまたは複数の制御要素、例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）システムトレイアイコンを利用することができるようにするサーバ側のツールバーを含む。
【００４０】
アクティベータは、ユーザのコンピュータ上で動作するオブジェクトコードであり、ウォレットサーバにアクセスするためのルーチンを含む。アクティベータは、イベントを生成することができ、またアクティベータは、特定のユーザ処理またはイベントおよび特定のシステム処理またはイベントに応答するウォレットサーバとの通信を可能にする手続き論理を含む。好ましくは、アクティベータは、単一のグラフィック要素、例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）の実施形態ではＷｉｎｄｏｗｓ（登録商標）システムトレイアイコンとして現れ、ユーザがウォレットツールバーの出現をトリガすることができるようにするアイコンを提示する。様々な実施形態では、ウォレットツールバーは、実際には、ウォレットサーバにアクセスする特別ブラウザウィンドウである。アクティベータは、ウォレットサーバと通信し、小さいダウンロードを介してアクティベータオブジェクトコードの更新を自動化する。好ましくは、ユーザは、アクティベータのダウンロードを行う前に確認を求められる。様々な実施形態では、アクティベータは、ウォレット以外のアプリケーション、例えば、報償の提供のアプリケーションと通信する。
【００４１】
システムは、関係のあるオプションの内容をそのウェブページのそれぞれ上で提供する。内容とは、すなわち、ユーザによって閲覧される各ページに固有の動的な文脈による情報である。このことは、アクティベータがＵＲＬを監視し、場合によっては、ページ上に記号を入れてユーザに潜在的な機会を気付かせるのを可能にすることによって実現される。例えば、アクティベータは、ユーザが商店サイトを閲覧しているかをチェックして、該当する申し出（例えば、商品の値引き等）をユーザに提示することができる。また、アクティベータは、ユーザのシステム上のソフトウェアのバージョンを監視し、そのユーザに可能なアップグレードバージョンのことを知らせることができる。例としての実施形態では、システムは、ＷＡＮ、ＬＡＮ、インターネットなどの任意のネットワーク上、あるいは任意のパーソナルコンピュータ上、ワイヤレス電子デバイス上、またはその他の任意の同様なデバイス上に実装される。システムは、オペレーティングシステム上に、例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃ ＯＳ、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ（登録商標） ＣＥ、Ｐａｌｍ ＯＳ、その他のものの上に実装することができる。
【００４２】
好ましくは、クライアント側で実装されるアクティベータにより、ユーザ１１０は、デジタルウォレット１４０発行者、例えば、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓと常時、または断続的に通信することができ、ユーザのディスプレイ上で邪魔なウィンドウに空間を占領させる必要がない。前述したとおり、これにより、ウォレット発行者は、監視を行い、適切なときに、可能な興味のアイテムをユーザに提示することができる。ウィンドウ内に提示される構成可能なコントロールにより、顧客は、所望のＷｅｂサイトに迅速にナビゲートすることができ、またデジタルショッピングカートチェックアウトなどの所望の機能性を即時に呼び出すことができる。好ましくは、クライアントツールバーは、ユーザのブラウザウィンドウと関連する別個のウィンドウであることが可能であり、それを実質的にユーザブラウザの一部分にする形状を保持する。ユーザがそのコントロール上でクリックしたとき、ウィンドウはその元の状態のままであるが、すなわち、ウィンドウは、ブラウザウィンドウが所望のＵＲＬを訪問するようにダイレクトして、特定の処理（デジタルウォレットの使用など）を呼び出す。例えば、システムトレイからデジタルウォレットアイコンを選択した後、デジタルウォレットツールバー５０２が、図５に示すとおり、ユーザのブラウザウィンドウ５００と関連する別個のウィンドウとして表示される。代替の実施形態では、クライアントツールバーは、既存のウォレットウィンドウのフレームとなり、既存のウォレットによって提供されるウィンドウエリアの延長で、前述したとおり、追加のコントロールを提供する。別の代替の実施形態では、エリアがユーザの標準ブラウザウィンドウ内で分割されて、ウォレットおよび前述したその他のコントロールとして使用することができるエリアが作成される。
【００４３】
システムは、好ましくは、顧客が気に入ったＵＲＬを訪問するためだけでなく、そうでなければ多くのステップが課される可能性があり、ベンダのサイトが常に更新されるために変化する可能性のある特定の機能性を呼び出すための便利な手立てを提供する。また、システムは、好ましくは、ウォレットおよびｅコマースサイトを使用しやすくするだけでなく、ウォレットおよびクライアントツールバーを見つけやすくすることによって、よりシンプルなユーザ体験も提供する。ユーザに多数の異なるウィンドウが開かれているとき、ウォレットウィンドウを見つけるのは、困難で面倒である可能性があり、特に、通常のナビゲーションおよびサイトとの対話の最中に、異なるブラウザウィンドウがＧＵＩの中心となるので、そうである。このため、システムトレイアイコンおよびサーバ側の機能性を使用することで、よりよいユーザ体験が提供される。好ましい実施形態では、本システムは、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒなどの当技術分野で知られる任意のブラウザで機能する。
【００４４】
従来技術のシステムは、単に、ユーザがページを訪問し、次にそのページからリンクを渡ることを可能にするカストマイズすることができるポータル（例えば、ＭｙＡｍｅｒｉｃａｎＥｘｐｒｅｓｓ．ｃｏｍ）を提供することができるが、本発明の例としての実施形態は、ユーザがＷｅｂをナビゲートするなかで、ユーザのデスクトップ上に留まることになるコントロールを有するウィンドウを提供する。さらに、クライアントツールバーは、ユーザのための処理を自動化する手段を提供し、これらの処理は、サードパーティのｅコマースサイトで行われる。さらに、従来技術のシステムは、別個のブラウザウィンドウを利用してウォレットコントロールを提供することができるが、本発明は、分割された標準のブラウザウィンドウを利用してウォレットが占めるべきエリアを提供する。例えば、好ましい実施形態では、デジタルウォレットアイコンが、システムトレイアイコン（図示せず）としてユーザに利用可能である。デジタルウォレットアイコンを呼び出すと、デジタルウォレットツールバー５０２が、図５に示すとおり表示される。デジタルウォレットツールバーは、ユーザがデジタルウォレットを利用できるようにするコントロールを含みながらも、目障りではない。好ましくは、ツールバー５０２は、ブラウザウィンドウ５００と関連している。
【００４５】
図６に示すとおり、ユーザがツールバー５０２からショッピングディレクトリボタンを選択した場合、ツールバーがショッピングディレクトリページ６０２まで拡張する。ユーザは、このショッピングディレクトリページ６０２内に表示された商店６０４のリストから商店を選択することができる。商店のリスト６０４から商店を選択したとき、デジタルウォレットが、図７に示すように、選択された商店サイト７０２にユーザを連れて行く。好ましくは、デジタルウォレットが、商店サイト７０２にユーザを連れて行ったとき、ツールバー５０２はその通常のサイズに戻る。
【００４６】
ユーザが、例えば、アイテムをショッピングカートに入れ、商店のサイトでチェックアウトに取りかかることにより、商店から購入を行うとき、チェックアウト機能が、部分的に、本発明のデジタルウォレットによって行われる。図８に示すとおり、ユーザが商店サイト７０２で所望の購入を示したとき、デジタルウォレットのチェックアウトユーザインターフェース８０２が表示される。例えば、チェックアウト表示８０２がブラウザウィンドウの一方の側に現れ、他方、商店ウィンドウ７０２は、ブラウザウィンドウの反対の側にまだ表示されている。商店チェックアウトでユーザが通常、入力しなければならないことになる情報の多く（例えば、名前、住所、電子メールアドレス、クレジットカード情報等）は、デジタルウォレットによって既に知られており、デジタルウォレットチェックアウトウィンドウ８０２内で事前記入される。好ましい実施形態では、ユーザは、事前記入された情報を編集することができる。
【００４７】
好ましくは、本システムは、また、Ｗｅｂサイト上にＨＴＭＬ書式を確実に入れるのを容易にする方法および装置も含む。最終結果として、ユーザは、様々なｅコマースＷｅｂサイトの実際の外観、ラベル付け、および挙動とは独立に、自らがサイトに提供することを所望する情報内容を一般的な形で識別することができる。好ましくは、本発明は、ユーザが入力されたデータをキャプチャすることを可能にする「自動記憶」構成要素、およびいくつかの異なるサイトおよびユーザのモデルの組合せからもたらされる強力な一組のプロセスを含む「書式記入」構成要素を含む。
【００４８】
本発明は、ユーザから情報を収集し、それをサーバ上にセキュアかつ信頼の置ける仕方で記憶し、次に、それをユーザの指示の下で適切な書式フィールドに提供する。システムは、ユーザの関心対象であるサイトの様々なＨＴＭＬ書式フィールドに対するユーザ情報のマッピングを維持する。次に、この情報が、これらのサイトと対話することを所望するユーザのために、どのようにＨＴＭＬ書式が記入される（または事前記入される）べきかを指示することができる。
【００４９】
「自動記憶」機構に関して、従来技術のデジタルウォレットは、記憶機能を実装することができるが、その機能はユーザによって開始されなければならない。本「自動記憶」機構では、デジタルウォレットユーザは、自らが記入したばかりの書式を記憶するのにボタンをクリックする必要がない。というのは、本システムは、ユーザが商店ウィンドウ上でサブミットするフィールドを記憶するからである。書式がサブミットされたとき（例えば、「Ｓｕｂｍｉｔ」ボタンまたは「Ｂｕｙ」ボタンを押すことにより）、オンラインウォレットは、その書式提出をトリガしたウィンドウが、関与の商店ウィンドウであるかを判定することで応答する。関与の商店ウィンドウであった場合、ウォレットは、そのデータを適切に記憶し、そうでない場合、ウォレットは、書式提出のオカレンスを無視して、通常通り動作しつづけることができる。デジタルウォレットコントロールは、「記憶」とラベル付けされたボタンを含むことができ、あるいは、常時、アクティブである自動記憶機構もサポートすることができる。一般に、ウォレットによって自動的に埋められたもの以外のフィールドが、記憶されることが可能である。このコンテキストでは、フィールドを記憶することは、ユーザが特定のフィールドにデータを入力したとき、その値がシステムによって格納されることになることを意味する。ウォレット構成要素は、この仕方で入力されたフィールド値を検出し、インターネットを介してそれらをセキュアな仕方でサーバに伝送することになる。ユーザが次回にこのページに行ったとき、ウォレットは、ウォレットシステムから検索されたフィールドで書式を埋めることに加え、以前に記憶されている値でその書式を埋めることにもなる。書式を処理する（事前記入する）際、ウォレットは、サーバからセキュアな仕方でフィールド値を検索することになる。
【００５０】
より詳細には、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザに関して、本発明は、例えば、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ ＷａｌｌｅｔなどのＷｅｂページに自体を付加するＡｃｔｉｖｅＸコントロールを適切に実装する。好ましい実施形態では、ＡｃｔｉｖｅＸコントロールは、すべてのＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザのブラウザイベントをキャプチャするメソッドを含み、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔが、必要な場合、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔ内にロードされるＪａｖａ（登録商標）Ｓｃｒｉｐｔ関数により、これらのイベントに応答できるようにしており、これにより、システムが、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザ内で完全にダウンロードされた文書を得ることを可能にしている。具体的には、これにより、システムは、文書のロードがいつ済んだのかを特定するＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザによって生成される「Ｄｏｃｕｍｅｎｔ Ｃｏｍｐｌｅｔｅ」イベントをキャプチャすることができる。このイベントがキャプチャされたとき、ｃｔｉｖｅＸコントロールが、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔ内にロードされたＪａｖａ（登録商標）Ｓｃｒｉｐｔ関数をコールすることによってＡｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔに通知する。この関数は、ＡｃｔｉｖｅＸコントロールと通信して、すべてのＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザ上ですべての書式に関する「Ｆｏｒｍ Ｓｕｂｍｉｔ」イベントを適切にキャプチャすることでこのイベントに応答する。
【００５１】
ユーザが、Ｗｅｂページ上の書式を記入して、そのページに関する「Ｓｕｂｍｉｔ」（すなわち、書式をサブミットする、ボタンなどの任意のコントロール）ボタンをクリックしたとき、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔ内にロードされたＪａｖａ（登録商標）Ｓｃｒｉｐｔ関数をコールするＡｃｔｉｖｅＸコントロールにより、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔに通知が行われる。次に、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔは、イベントを生成したウィンドウのＵＲＬを検査することにより、「Ｓｕｂｍｉｔ」イベントを生成している文書が関与のものであるかを適切に判定する。そのイベントが処理されるべき場合、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔは、そのイベントを生成した文書オブジェクトモデル（ＤＯＭ）を入手するＡｃｔｉｖｅＸコントロール内の適切な関数をコールしなければならない。次に、ＤＯＭを走査して書式値を保存し、それらの値をメモリ内に記憶するためにサーバに送信できるようにする。好ましい実施形態では、ＡｃｔｉｖｅＸコントロールは、自体を適切に、ブラウザイベントおよび書式「Ｓｕｂｍｉｔ」イベントをキャプチャすることとは切り離して、ランタイムエラーが最小限に抑えられるようにする。
【００５２】
Ｎｅｔｓｃａｐｅブラウザに関しては、Ｎｅｔｓｃａｐｅのイベントの実施態様の理由で、システムは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ内だけからイベントをキャプチャする。システムがうまく「Ｕｎｉｖｅｒｓａｌ Ｂｒｏｗｓｅｒ Ｗｒｉｔｅ」特権を得た（すなわち、ユーザによって与えられた）場合、次に、システムは、外部ウィンドウが別のウィンドウのイベントをキャプチャするのを可能にする関数をうまくコールすることができる。次に、システムは、そのウィンドウのすべてのフレームに関して、その文書オブジェクトモデルを走査することができる。これを行う際、システムは、ウィンドウの各書式に、システムが「Ｓｕｂｍｉｔ」イベントをキャプチャするのを所望していることを知らせる。このため、システムが通知したウィンドウ上の書式をユーザが記入し、そのページに関する「Ｓｕｂｍｉｔ」ボタン（すなわち、書式をサブミットするボタンなどの任意のコントロール）をクリックしたとき、オンラインウォレットが通知を受けて、適切に応答する。本発明は、任意の適切なデジタルウォレットシステムを含むが、それには限定されない任意の適切な取引システムにおいて実装できることが、当分野の技術者には理解されよう。
【００５３】
書式記入機能に関しては、例えば、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔなどのデジタルウォレットが、書式を埋める際にユーザを助ける書式記入機能性を提供する。ＧｌｏｂｅＳｅｔ，Ｉｎｃ．によって提供されるシステムのような従来技術のシステムは、通常、Ｂｒｏｗｓｅｒ Ｈｅｌｐｅｒ Ｏｂｊｅｃｔ（ＢＨＯ）を使用する。ＢＨＯ手法は、しばしば、例えば、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ ５．０ブラウザが、レジストリ内で指定された第１のＢＨＯしかロードしないというバグを有するといったような欠点を含む。このことは、そのＢＨＯがロードされたかどうか確信できないため、どの適用例に関しても問題となる。さらに、ＢＨＯがＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒの各インスタンスごとにロードされて、ＢＨＯの複数のインスタンスが任意の所与の時点で動作し、したがって、メモリを食い、関与の１つのブラウザだけのためにすべてのブラウザに関してナビゲーションの速度を低下させることになる可能性がある。
【００５４】
本発明は、好ましくは、「自動記憶」機構で指定したのと同じ「ＡｃｔｉｖｅＸコントロール」を使用することで、ＢＨＯの解決策の代りにする。Ｏｎｌｉｎｅ Ｗａｌｌｅｔ ＷｅｂページにＡｃｔｉｖｅＸコントロールを付加することにより、システムは、例えば、Ｓｈｅｌｌ Ｗｉｎｄｏｗｓ（登録商標） ＡＰＩを使用することによって任意の所与のＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザ内にロードされる任意の文書に関する文書オブジェクトモデルを適切に獲得する。ユーザがＯｎｌｉｎｅ Ｗａｌｌｅｔ上で「Ｆｉｌｌ Ｆｏｒｍ」ボタンをクリックしたとき、ウォレットは、まず、ＡｃｔｉｖｅＸコントロールを介して文書オブジェクトモデルを獲得することで応答することができる。次に、ウォレットは、書式を構成するフィールドの名前を保存し、それらをサーバ上のヒューリスティックエンジンに送信することができる。サーバは、これらのフィールドを埋めるのに使用されるべき値を戻すことでこの要求に応答することになる。次に、以前に獲得したのと同じ文書オブジェクトモデルを使用して、フィールドを埋めることができる。このため、本発明は、Ｗｅｂサイトで書式に反復性のデータを入力しなければならないという問題を抑える。顧客の側での労力を節約することに加え、本発明は、入力されたデータの正確さを高める。
【００５５】
より詳細には、本発明のアーキテクチャは、各サイトのサーバ側モデル（例えば、フィールド、ページ、リンク等）、ユーザのサーバ側モデル（例えば、プロファイル）、サイトのユーザ生成モデル（例えば、マクロ記録、タグ付け、ドラッグアンドドロップ）、システムによって手動で生成されたサイトのモデル（例えば、ユーザ生成モデルを強化および妥当性検査するため）、およびヒューリスティックに生成されたサイトのモデル（例えば、フィールド、処理等に関する意味情報の推論）を組み合わせる。本システムは、いくつかの別々のタイプのモデルを作成し、記憶する。第１のモデルは、例えば、どのように個人がチェックアウトするか、どのように個人が何かをショッピングカートに追加するか、どのように個人があるタイプの製品を探索するか、どのように個人が選好を入力するか（例えば、旅行）等、サイトを特徴付ける。第２のモデルは、例えば、ユーザが行うことができるのは何であるか、またユーザのプロフィル属性がどのようなものであるか、ユーザを特徴付ける。これら２つのモデルを組み合わせることにより、本システムは、高い柔軟性とパワーを追加する特別なプロセスを作成する。システムは、ユーザが何を行うことができるかというモデルから、サイトのモデルに対してマッピングを行い、サイトモデルは、知られている任意の方法によって生成される。このため、サイトモデルは、ユーザ、ホスト、または取引カード会社（発行者）により、あるいはサイトプロバイダによっても作成されることが可能である。好ましい実施形態では、ＥＣＭＬ／ＸＭＬを使用してサイトに関するモデルを表すことができる。様々な実施形態では、サイトモデルを他のシステムと交換することが可能である。
【００５６】
例えば、ユーザは、航空券を購入するため、異なる航空サービスおよび旅行サービスのサイトを日常的に訪れることが可能である。各サイトは、通常、様々なサイト間で比較的似通った情報を収集するために、様々なスクリーン上でフィールドを有する。ただし、各サイトは、異なるＵＲＬ上に配置された異なるＨＴＭＬ書式フィールドを使用することになり、また、これらのフィールドは、時間の経過とともに変わる可能性がある。異なるサイトを通じて情報が似通った性質のものであっても、現行では、ユーザの旅行の選好に関して（例えば、座席配置、食事、旅行時期、アフィニティ報償等）に関してフィールドを埋めるプロセスを自動化する共通の機構が存在しない。各サイトは、この情報の多くを記憶するユーザの独自のプロファイルを有する。ただし、ユーザは、それでも、現在の慣行では、各サイトごとに独立にそのようなプロファイルを作成しなければならないことになる。
【００５７】
本発明は、ヒューリスティックスベースのフィールド認識を含む。この手法では、フィールドラベルが、関与の書式フィールドに対する空間的近接性によって識別される。フィールドラベルと書式フィールドＨＴＭＬ属性（とりわけ、ＨＴＭＬの「入力」要素、「選択」要素、および「処理」要素の「名前」属性）の組合せが、所望のフィールドの識別を助ける辞書を含むヒューリスティックエンジンに対する入力として使用されることになる。
【００５８】
別の実施形態では、本発明は、ユーザ介在フィールド認識を含む。この手法では、ユーザは、ユーザが実行する処理のシーケンスに関する情報をサーバがキャプチャすることを可能にする「Ｒｅｍｅｍｂｅｒ」ボタンまたは同様のコントロールを介して意図的に入力をキャプチャする。ユーザは、これを行う際、その処理を実質的に「再生」することができる（他のソフトウェアシステムで使用されるマクロスクリプト記述と同様に）。このため、ユーザの処理をヒューリスティックエンジンに送り込むことが可能であり、また、このエンジンのプロセスによって使用されるフィールドマッピングテーブルに直接に送り込むことも可能であ
る。
【００５９】
好ましい実施形態では、前述した２つの手法は、この発明を可能にするナビゲーションの可能性および書式フィールド完成の可能性を正確に描写するプロセスマップおよび書式フィールドマップを完全に作成するためには、何らかの手動の対話を必要とする可能性がある。それが必要なとき、人間の分析者が、ユーザ介在フィールド認識中に行われるのと同様の仕方で作業することになる。ただし、分析者は、通常のユーザよりもはるかに多くの情報を自らのナビゲーションプロセスおよび書式記入プロセスに関して提供することになる。すべての場合で、収集された情報は、様々な活動をそれによって行うことができる処理のシーケンス（書式記入、ＨＴＴＰ Ｐｏｓｔ、ＨＴＴＰ Ｇｅｔ等）を描写するプロセスマップ（または詳細なサイトマップ）を作成するのに使用される。また、フィールドマップも、プロセスマップ内のＷｅｂページのそれぞれに対して生成されることになり、このフィールドマップは、書式提出を自動化するのに使用することができるフィールドの正確な名前を定義する。また、ユーザがＷｅｂサイトと対話するなかで、ユーザの状態を追跡するために、状態マップも必要とされる可能性がある（ログオンしている対ログオンしていないなどのユーザの状態により、サイト上における特定の処理の結果が変わることになる）。
【００６０】
好ましい実施形態では、ユーザがそれによって対話するプロセスは、完全に自動化すること（その場合、ユーザは、単に、スクリプト記述された処理を行う要望を伝える）、またはユーザ介在型にすること（その場合、本発明は、ユーザのために書式フィールドを事前記入することができ、これにより、さらなるデータ入力を必要とする任意のフィールドを修正、変更、または完成する機会をユーザに与える）ができる。前述した製品およびサービスに加えて、会社が自体のサイトの訪問者に関する書式データの入力を自動化することを可能にするなどの、新しい製品およびサービスのために、プロセスマップおよびフィールドマップの形態での実施を可能にする技術を活用することができる。例えば、会社が、自体の顧客のためにプロセスマップおよびフィールドマップをまとめた場合（前述した手段のどれかにより）には、この会社は、この情報、サービス、および製品のライセンスをサードパーティの顧客に供与することができる。また、これらのマップが自体に関して存在するサイトも、本発明を使用して、このシステムの恩恵を受けていない自体の顧客に同様のサービスを提供することで、自体のサイトが恩恵を受けるようにすることができる。また、基礎のプロセス自体も、この情報を獲得し、それを例えばＸＭＬやＥＣＭＬとして再フォーマットするシステムを利用することになる。これらの標準の表現は、後述する２つの製品／サービスのための情報交換の基礎を成すことになる。
【００６１】
次に、図９を参照すると、実施例としてのアクティベータプログラムによって実装されるプロセス９００が、アプリケーションを初期化すること（ステップ９０２）と、ユーザがオンラインでブラウズまたはショッピングするなかで、ユニフォームリソースロケータ（ＵＲＬ）を監視すること（ステップ９０４）と、ユーザがサポートされるサイトでブラウズしているかどうかを判定すること（ステップ９０６）と、サポートされるサイトのタイプを判定すること（ステップ９０８および９１２）と、処理ステップ９１０および９１４（それぞれ）で適切に応答することとを適切に含む。その他の機構（クーポン、特別売出し、監視、セキュリティ等）は、ステップ９１６で実装することができる。
【００６２】
初期化ステップ９０２は、アクティベータアプリケーションを開くこと、およびアプリケーションを適切に初期化することに適切に関わる。アクティベータアプリケーションは、システム始動、ネットワーク（インターネットまたはＬＡＮなど）に対する接続、またはブラウザ（ワシントン州、ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、またはカリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＮｅｔｓｃａｐｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＮｅｔｓｃａｐｅ Ｅｘｐｌｏｒｅｒなど）の初期化に応答して初期化することができる。様々な実施形態では、アクティベータアプリケーションが、ウォレットサーバ１４０（図１）、ウォレットアプリケーション４０６（図４）、またはネットワーク１０２上の別のサーバに接触することができる。アクティベータアプリケーションは、遠隔サーバに適切に接触して、ウォレットによってサポートされるＷｅｂサイトのリスト、ドメイン名のリスト、またはＵＲＬのリストなどの情報を入手する。この情報は、定期的に（例えば、毎日、毎週、毎月、またはエージェントアプリケーションの初期化のたびに毎回）入手することができ、あるいは、アクティベータアプリケーションまたはサーバによってポーリングされたときに入手することができる。様々な実施形態では、アクティベータアプリケーションは、ローカルドライブ上のキャッシュまたはファイル内に、またはクライアントコンピュータ上のメモリ内に、サポートされるＵＲＬのリストを記憶する。
【００６３】
ユーザがインターネットまたはその他のデータネットワーク１０２上でブラウズするなかで、アクティベータアプリケーションは、そのネットワーク上のユーザの位置を適切に監視する。ユーザのブラウズを監視する一方法は、ユーザのブラウザによって使用されるＵＲＬを監視することである。そのような実施形態では、アクティベータアプリケーションは、ユーザのブラウザから（または、それが適切な場合、システムネットワークインターフェースから）現在のＵＲＬを入手し、初期化ステップ９０２において遠隔サーバから入手したサポートされるＵＲＬのリストに対してその現在のＵＲＬを比較する（ステップ９０６）。この比較を図９で論理的に別々のステップ９０６、９０８、９１２、９１６によって示している。ただし、これらのステップは、本発明の範囲を逸脱することなく、任意の仕方で組み合わせること、または分離することが可能である。例えば、図９は複数回の比較が実行されるのを示しているが、いくつかの実施形態では、サポートされるＵＲＬのリストに対し、各現在のＵＲＬを単一回、比較することで十分である可能性がある。
【００６４】
現在のＵＲＬがサポートされるＵＲＬに該当する場合、アクティベータアプリケーションは適切に応答する。例えば、現在のＵＲＬがサポートされるチェックアウトページである場合（ステップ９０８で「はい」）、アクティベータアプリケーションは、チェックアウトプロセスを実行する（ステップ９１０）。チェックアウトプロセスは、ポップアップメッセージを介して、あるいはシステムトレイ内または浮動ウィンドウ内に特定のアイコンを表示することにより、そのチェックアウトページがサポートされているのをユーザに通知することを含むのが可能である。ウォレットクライアントアプリケーション２１４がもはや開いていない場合、アクティベータアプリケーションは、ユーザにダイアログボックスまたはその他のプロンプトを提示して、そのページがウォレットアプリケーション２１４によってサポートされているのを示すことができる。また、このプロンプトは、ユーザがそれによってウォレットアプリケーション２１４を開くことができるボタンまたはその他の機構を提供することも可能である。
【００６５】
現在のＵＲＬがサポートされる支払いページに該当する場合（ステップ９１２で「はい」）、アクティベータアプリケーションは、ウォレットアプリケーションに支払い命令を提供する、または、別の仕方で、ウォレットアプリケーションに制御を渡すことができる（ステップ９１４）。アクティベータアプリケーション、ウォレットアプリケーション、ブラウザ等の間で送信されるメッセージは、Ｏｐｅｎ Ｄｅｓｋｔｏｐメッセージで、Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ（ＯＬＥ）メッセージで、オブジェクトルーチンコールで、ＯＳコールで、またはそれに類するもので送信することができる。
【００６６】
様々な実施形態では、前述した機能性は、以下に説明するクッキーを使用して実現することができる。クッキーは、有効なユーザコンテキストを検出するのに使用される。有効なユーザコンテキストが検出された場合、アクティベータは、サーバアプリケーションを立ち上げるか、またはユーザが他のアプリケーションを立ち上げるのを可能にするサーバツールバーを立ち上げる。例えば、ユーザのブラウザは、個人支払いまたは特定のカード商品を介して購入を行う能力を意味するいくつかのクッキーを有することが可能である。アクティベータは、ユーザが所望の支払い機器（例えば、個人支払いまたはユーザのデジタルウォレット内のカードから）を選択できるようにするツールバーを立ち上げることができる。利用できる適用例は、必ずしもすべて購入取引に関係していないことが理解されよう。様々な実施形態では、コンテキスト情報は、サーバ上と、ブラウザに関連するクッキー内の両方で記憶される。例えば、クッキーは、コンテキスト情報をそれによってサーバから検索することができるキーとして、働くことが可能である。
【００６７】
また、その他の機能性（ステップ９１６）も、アクティベータアプリケーションに組み込むことができる。例えば、セキュリティ機構（前述したもの、および以下に説明するものなど）、顧客監視機能、クーポン、特別売出し等を実装することが可能である。クーポンまたは特別売出しの場合、アクティベータは、現在のＵＲＬを特定の製品または特定のＷｅｂページに対応するものとして感知することが可能である。ユーザがその特定のサポートされたＵＲＬに「サーフィン」またはブラウズしたとき、アクティベータアプリケーションは、その一致に気付き、特定の商品を購入する機会、または購入で特別割引きを受ける機会などの特別の申し出をユーザに提示する（ダイアログウィンドウを介して、またはブラウザを介して、またはそれに類するものを介して）。本適用例の範囲を逸脱することなく、その他の機能性をアクティベータアプリケーションに組み込むのが可能なことが理解されよう。
【００６８】
本発明の様々な実施形態では、ウォレットクライアント２１４（図２）が、特定のユーザ／顧客に固有の情報で事前記入される。図１を参照すると、ユーザは、ネットワーク１０２上のウォレットサーバ１４０などのＷｅｂサーバに接触することによってデジタルウォレットの申し込みを行うことができる。ユーザは、登録書式（例えば、ＣＧＩスクリプトで生成することが可能な）を完成させてウォレットの申し込みを行う。ウォレットサーバ１４０は、認証サーバ３０６（図３）または私設ネットワーク上の別のサーバから人口統計情報、口座情報、およびその他の情報（例えば、アドレス、発送アドレス、名前、クレジットカード番号等）を適切に受信する。この情報を使用して、特定のユーザに固有のウォレットクライアント２１４（図２）を構成することができる。ウォレットクライアント２１４を構成する一方法は、クライアント２１４と関連し、クライアント２１４によって読み取られる構成ファイルを作成して、前述したとおり、ウォレット情報を獲得することである。
【００６９】
好ましくは、登録情報は、カードリーダポートがシリアルポートでなければならないか、またはＵＳＢポートでなければならないかを含むカードリーダ情報も含む。ウォレット申し込みが承認された場合、カードリーダをユーザに発送する、または別の仕方でユーザに提供することが可能であり、特別コード（暗号キー、またはパスワード、または他の任意の種類の電子コードまたは印刷されたコード）もユーザに提供される。次に、ユーザは、ウォレットサーバ１４０と電子的に接触をとり、カードおよび／または特別コードを使用してサーバに対する認証を行うことによってオンラインウォレットサービスに登録する。特別コードを提供した後、ユーザは、特別に構成したコピーのウォレットソフトウェアを受け取り、これを適切に顧客コンピュータ１１０にインストールすることができる。ウォレットプログラムのバージョンを単に特別コードと関連付けることにより、ウォレット事前記入手続きを任意のクレジットカードまたは任意の課金カードで使用することができる。特定のユーザに関する構成情報が、ユーザに提供されるコードと関連付けられ、後に、このユーザは、その特別コードを提示してウォレットサーバ１４０に対して自らの認証を行い、特定のユーザに固有のデータで既に事前構成されているウォレットのコピーを入手することができる。
【００７０】
次に、図１および図１０を主に参照すると、顧客１１０は、スマートカード２０２を使用してウォレットサーバ１４０にログインすることにより、取引を適切に開始する。ウォレットサーバ１４０にログインするためには、顧客１１０は、まず、ブラウザ２１６を介してセキュリティサーバ１３０に接続することができる。ユーザは、ブックマーク、インターネットショートカット、ハイパーリンク、または他の任意の適切な技法を介してログインページのための特定のユニフォームリソースロケータ（ＵＲＬ）を選択する。次に、セキュリティサーバ１３０が、ネットワークインターフェース３０２を介してログインページを戻すことが可能である。様々な実施形態では、ユーザ／パスワードログインのための書式入力および提出ボタン、ならびにスマートカードログインのためのハイパーテキストリンクが、ログインページの一部として提供される。ユーザが、スマートカードログインを選択し、ブラウザ２１６が、ログオン要求メッセージ１００２（図１０）を転送することによって適切に応答する。セキュリティサーバ１３０が、ログオン要求１００２を受信して、適切にスマートカードログオンプロセスを開始する。様々な実施形態では、セキュリティサーバ１３０は、ログオン要求メッセージ１００２に応答して、認証サーバ３０６またはセキュリティエンジン３０４による暗号課題をフォーマットする。暗号課題１００４は、ランダムデータに基づき、スマートカード２０２上に記憶されたＸ．５０９アプリケーションから応答を求めるように設計された課題などの、再生攻撃（例えば、前に送信された認証パケットを再送信することによって作成された不正なメッセージ）を防止する任意の種類の課題メッセージである。次に、この課題が、課題メッセージ１００４として、ネットワーク１０２を介して顧客１１０に適切に提供される。
【００７１】
課題メッセージ１００４を受信すると、ブラウザ２１６は、スマートカード２０２を使用する処理のために、メッセージ１００４をウォレットクライアント２１４に適切に渡す。ウォレットクライアント２１４が動作していない場合、ブラウザ２１６は、そのプログラムを自動的に開くことができる。次に、ウォレットクライアント２１４が、適切に署名応答を準備する。例えば、ウォレットクライアント２１４は、サーバ課題情報を抽出し、新しいクライアント課題（すなわち、スマートカード２０２に対する第２の暗号課題）をフォーマットし、両方の課題を二重課題に結合し、例えば、公開キー暗号システム１（ＰＫＣＳ１）暗号ブロック内で、後の使用のためにこの二重課題のハッシュを計算することができる。ハッシュは、例えば、ＭＤ３やＭＤ４などの任意のアルゴリズムに従って計算することができ、二重課題ブロック内のデータの完全性と正確さを保証するために適切に使用される。ＰＫＣＳ１は、ＲＳＡ公開キークリプトシステムを使用してデータを暗号化し、それに署名するための機構を定義する公開キー暗号法の標準である。ＰＫＣＳ標準は、１９９８年９月付けの、参照によって本明細書にその全体が組み込まれるＰＫＣＳ ＃１： ＲＳＡ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ Ｖｅｒｓｉｏｎ ２．０（ｈｔｔｐ：／／ｗｗｗ．ｒｓａ．ｃｏｍ／ｒｓａｌａｂｓ／ｐｕｂｓ／ＰＫＣＳ／ｈｔｍｌ／ｐｋｃｓ−１．ｈｔｍｌからオンラインで入手可能である）で、十分に定義されている。
【００７２】
ＰＫＣＳ１ブロックは、処理のために、リーダ２０４を介してスマートカード２０２に適切に提供される（図１０のステップ１００６）。様々な実施形態では、カードリーダ２０４が顧客コンピュータ１１０と対話し、カードにアクセスするための個人識別子、例えば、個人識別番号（ＰＩＮ）または他の固有識別子を求めて、ユーザにプロンプト指示を出す。好ましい実施形態では、ＰＩＮは、スマートカード２０２上に記憶される。別法では、ＰＩＮまたはその他の個人識別子は、システム上の別のどこかに、例えば、リーダ２０４上または顧客コンピュータ１１０上に記憶することができる。ユーザは、それが適切な場合、スマートカード２０２をロック解除するために個人識別子を適切に入力し、スマートカードは、ウォレットクライアント２１４から二重課題ブロックを受け取り、そのブロックに適切にデジタル方式で署名する。様々な実施形態では、スマートカード２０２は、ブロックのデジタル署名を計算するのに使用する秘密キーを含む。次に、署名されたブロックが、適切に、ウォレットクライアント２１４に戻される。様々な実施形態では、スマートカード２０２は、デジタル署名を計算するのに使用する秘密キーに該当する証明書（Ｘ．５０９証明書など）も提供する。
【００７３】
スマートカード２０２から署名および証明書を受信した後、ウォレットクライアント２１４は、セキュリティサーバ１３０に送信されるべき適切な応答メッセージ１００８を適切に作成する。応答メッセージ１００８は任意の形式であることが可能であるが、様々な実施形態は、１９９３年１１月１日に改定され、ｆｔｐ：／／ｆｔｐ．ｒｓａ．ｃｏｍ／ｐｕｂ／ｐｋｃｓ／ｄｏｃ／ｐｋｃｓ−７．ｄｏｃからオンラインで入手可能であり、参照によって本明細書にその全体が組み込まれるＰＫＣＳ ＃７： Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｍｅｓｓａｇｅ Ｓｙｎｔａｘ Ｓｔａｎｄａｒｄ， Ａｎ ＲＳＡ Ｌａｂｏｒａｔｏｒｉｅｓ Ｔｅｃｈｎｉｃａｌ Ｎｏｔｅ、Ｖｅｒｓｉｏｎ １．５に定義されるＰＫＣＳ７メッセージとして応答メッセージ１００８をフォーマットする。
【００７４】
応答メッセージ１００８を受信した後、セキュリティサーバ１３０は、適切にメッセージを処理する（図１０のステップ１０１０）。様々な実施形態では、応答メッセージ１００８は認証サーバ３０６に経路指定され、この認証サーバが、スマートカード２０２によって提供される証明書および署名を検証する。証明書がうまく検証され、かつ署名の妥当性検査がうまく行われた後、様々な実施形態では、セキュリティトークンが生成されて、顧客１１０またはスマートカード２０２に戻されることが可能である。
【００７５】
このようにして、セキュリティトークンの後の提示により、ユーザが身元を確認し、ウォレットサーバとセキュアな仕方で対話するための手段が提供される。様々な実施形態では、認証サーバ３０６は、ユーザを識別する追加のセキュリティトークンを作成することも可能である。様々な実施形態では、このトークンは、複数の部分から構成されることが可能であり、これらの部分が、次に、場合によっては、データベース３１０内のデータを利用して、適切なデジタル証明書、スマートカード、またはその他のデータにマッピングされる。様々な実施形態では、追加のセキュリティトークンおよび／またはその中の部分は、リダイレクトメッセージ１０１２と併せて顧客１１０に提供することができる。様々な実施形態では、追加のセキュリティトークンは、顧客に提供すること、または認証サーバ３０６上で保持することが可能である。
【００７６】
リダイレクトメッセージ１０１２を受信すると、顧客１１０は、ウォレットサーバ１４０に適切に接触して、接続を要求する。様々な実施形態では、「接続要求」メッセージ１０１４は、適切には、セキュリティトークンを含み、場合によっては、リダイレクトメッセージ１０１２の一部として追加のセキュリティトークン全体またはその一部も含む。ウォレットサーバ１４０は、セキュリティトークンの何らかの組合せの全体またはその一部を使用してセキュリティサーバ１３０に対して照会を行い、顧客１１０の識別を入手する。照会１０１６および応答１０１８は、ネットワーク１５０を介して適切に伝送され、このネットワークは、いくつかの実施形態では、ネットワーク１０２とは独立に維持されて、システム１００のセキュリティを高めている。代替の実施形態は、いくつかの実施形態では、仮想プライベートネットワーク、ＳＳＬプロトコル、共有の秘密の使用、および／またはその他の暗号手段によるより高いセキュリティを提供するネットワーク１０２を使用する。リターン信用証明１０１８が整っている場合、ウォレットサーバ１４０が、ウォレットデータベース４０８から顧客１１０に対応する属性を検索し、メッセージ１０２０を介してログインが成功したことを顧客１１０に通知する。ログオンシーケンスの代替の実施形態も可能であることが理解されよう。また、ログインシーケンス１０００を実装するために、任意の種類の暗号化スキーム、メッセージ形式等を使用するのが可能なことも理解されよう。
【００７７】
次に、図１１を参照すると、購入取引中の使用に適した実施例としての認証フロー１１００が、認証がそのために必要とされるイベント（購入など）に関して、顧客１１０がウォレットサーバ１４０に要求１１０２を出すことで開始する。ウォレットサーバ１４０は、そのイベントを適切に認識し、例えば、通信チャネル１５０を介してセキュリティサーバ１３０に要求メッセージ１１０４をサブミットして課題メッセージをフォーマットする。次に、認証サーバ３０６（または、それが適切な場合、セキュリティサーバ１３０の何らかの他の構成要素）が、課題メッセージ１１０６（これはランダムデータを含むことが可能である）をフォーマットして、その課題メッセージ１１０６をウォレットサーバ１４０に、例えば、接続１５０を介して提供する。ウォレットサーバ１４０は、課題メッセージ１１０６を受信し、その課題データを署名要求メッセージ１１０８としてブラウザ２１６に転送する。ブラウザ２１６は、それが必要な場合、ウォレットクライアント２１４を開き、署名要求メッセージ１１０８を転送する。前述したとおり、ウォレットクライアント２１４は、サーバ課題、クライアント課題、およびハッシュを含むＰＫＣＳ１ブロックなどの署名要求ブロックをフォーマットする。結果の署名要求ブロックが、リーダ２０４を介してスマートカード２０２に提供される。スマートカード２０２は、そのブロックに適切に署名して、適切なように、そのＸ．５０９証明書のコピーを提供する。
【００７８】
次に、署名されたブロックがウォレットクライアント２１４に戻されることが可能であり、ウォレットクライアントは、適切な署名応答メッセージ１１１０（ＰＫＣＳ７メッセージなど）を適切にフォーマットして、それをウォレットサーバ１４０に送信する。次に、ウォレットサーバ１４０が、妥当性検査メッセージ１１１２を構成し、このメッセージは、署名応答メッセージ１１１０からのデータ、ならびにログオンプロセス（図１０に示す実施例としてのログオンプロセスなど）中に顧客１１０と関連するセキュリティトークンを含む。代替の実施形態では、提供されたセキュリティトークンが、顧客１１０から署名応答メッセージ１１１０の一部として受信される。妥当性検査メッセージ１１１２が、適切に、接続１５０を介してセキュリティサーバ１３０に送信される。セキュリティサーバ１３０が、次に、妥当性検査メッセージを認証サーバ３０６に適切に経路指定して、この認証サーバが、その署名を検査し、データベース３１０から適切なセキュリティトークンを検索することができる（図１１のステップ１１１４）。データベースから検索されたセキュリティトークンおよび／またはオプションの固有識別コードが、ウォレットサーバ１４０から受信されたセキュリティトークンまたはＩＤと比較される。２つのオブジェクト（例えば、セキュリティトークンまたはＩＤ）が一致する場合、顧客１１０によって現在、使用されているカードが、顧客１１０によってログオン時に使用されたカードと同じであることを推論することができる。次に、適切な承認または否認のメッセージ１１１６が、セキュリティサーバ１３０からウォレットサーバ１４０に送信され、取引を進めることが許される。
【００７９】
様々な実施形態では、ウォレットサーバ１４０は、取引中、顧客１１０のためのプロキシの役割をする。例えば、ウォレットサーバ１４０は、購入者１１０のために、発送アドレス、カード番号等を含む購入書式を完成させることができる。次に、商店１２０が、その購入取引を従来のハードウェアおよびソフトウェアを使用して標準の課金カード取引として許可することができる。ただし、本明細書に開示するシステムによって提供されるさらなるセキュリティにより、購入者の身元におけるさらなる信頼性が可能となり、これにより、その取引に関するより低い割引率が妥当となる。
【００８０】
本発明の様々な実施形態は、セキュリティ違犯からのさらなる保護を組み込む。例えば、セキュリティサーバ１３０またはウォレットサーバ１４０に組み込まれた多くのサーバ側機能が、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ（カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓによって定義される）またはＶＢｓｃｒｉｐｔ（ワシントン州、ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって定義される）などのスクリプト記述言語で書かれた様々なスクリプト記述構成要素を組み込むことが可能であり、ネットワーク１０２に結合されたサーバが、サーバからクライアントにスクリプト（またはコード）を提供することにより、そのようなサーバ言語を介して複数のクライアント１１０に様々な機能性を提供することが可能である。このコードは、クライアントコンピュータ１１０によって解釈され、コンパイルされ、または別の仕方で実行される。例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔを組み込んだ実施形態では、クライアントコンピュータ１１０上で動作するブラウザプログラム（例えば、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｏｒ、またはそれに類するもの）によってスクリプトが解釈され、実行される。その他の実施形態は、他の非ＰＣのブラウザ、例えば、ワイヤレスマークアップ言語（ＷＭＬ）スクリプトをサポートするワイヤレスアプリケーションプロトコル（ＷＡＰ）電話機を含む。様々なスクリプト記述言語は、例えば、ユーザのハードドライブ上のファイルにアクセスするため、または別の仕方でユーザのコンピュータ上のデータを操作するための命令、オブジェクト、またはその他のデータ機構を含んでいることが可能である。許可のないソースがユーザに実行可能コードを提供するのを防止するため、スクリプト記述言語は、信用されるソースから提供されたスクリプトだけをユーザが許可するのを可能にするための機構を含むことができる。例えば、前述したとおり、電子取引を行うユーザは、ウォレットサーバから提供されたスクリプトが実行されるのを許すが、その他のソースから提供されたその他のスクリプトがユーザのコンピュータ上で実行されるのを防止することが可能である。
【００８１】
多くのスクリプト記述言語で遭遇する可能性のあるセキュリティ問題を図１２Ａに示している。非良心的な「クラッカー」が、正規のＷｅｂサーバ１２０６のユーザに対して、悪意のある活動を行うように設計されたＷｅｂサイト１２０４を作成する可能性がある。クラッカーサイト１２０４（図では「犯罪的サイト」として示す）は、例えば、スクリプトなどの、コードの一部分をユーザに提供することが可能である。また、犯罪的サイト１２０４は、正規のサーバ１２０６（ウォレットサーバ１４０、またはネットワーク１０２上における他の任意のサーバ）において特定のユニフォームリソースロケータ（ＵＲＬ）を要求するようにユーザのＷｅｂブラウザ２１６を誘導することが可能である。参照されるＵＲＬは、正規のサーバ１２０６が、例えば、クライアントブラウザ２１６にエラーメッセージまたはその他の応答を戻すように、意図的に作られていることが可能である。様々な実施形態では、正規のサーバ１２０６からの応答は、ユーザのＷｅｂブラウザ２１６からの要求の一部分またはその変形を自動的に含むことが可能である。その応答が、犯罪的サイト１２０４の悪意のある意図の結果、生成されたＪａｖａ（登録商標）Ｓｃｒｉｐｔ、ＶＢｓｃｒｉｐｔ、またはその他のコードを含む場合には、そのコードがユーザのコンピュータ上で実行される可能性がある。この例は、「クラッカー」が、それにより、正規のＷｅｂサーバ１２０６を誘導して悪意のある命令をユーザのＷｅｂブラウザ２１６に送信することのできる多くの技法の１つを例示するものである。様々なコーディング言語およびスクリプト記述言語が、ホストコンピュータのファイルシステム、レジストリ、またはそれに類するものにアクセスするための命令を含んでいるので、そのようなコードの許可のない実行は、極めて望ましくないことが理解されよう。それでも、図１２Ａに示す技法により、犯罪的サイト１２０４からのスクリプト記述またはその他のコードがユーザのコンピュータに提供されることが可能である。ユーザのコンピュータは、そのスクリプト記述が信用されるソース（すなわち、ウォ
レットサーバ）から来たと考えるので、クライアントのコンピュータが犯罪的サイトからのそのコードを実行する可能性があり、これにより、損害、許可のないデータの配布または破壊、またはそれに類するものの可能性が生じることになる。図１２Ｂは、行われるべき正しい通信フローを示している（図１２Ａに示す犯罪的攻撃のフローと対比される）。
【００８２】
この潜在的なセキュリティ問題を防止するため、本発明の様々な実施形態は、不要の実行可能コードを削減または除去するための技法を適切に含む。図１３を参照すると、スクリプト攻撃の可能性を減らすためのプロセス１３００が、高い許可を有するサーバの部分を制限するステップ（ステップ１３０２）と、サイトのその部分内の危険な文字を除去するステップ（ステップ１３０４）と、それが必要な場合、ある文字をエンコードするステップ（ステップ１３０６）と、オプションとして、Ｗｅｂサイトの関係のある部分からユーザに提供されるデータをログ記録するステップ（ステップ１３０８）を適切に含む。
【００８３】
ステップ１３０２に関して、Ｗｅｂサイトは、通常、様々なページを含み、各ページは固有のＵＲＬを有している。サイトのユーザは、あるサーバ（評判のよい金融機関または商店に対応するサーバなど）に高い信用を置くことが可能である。高い信用をそのＷｅｂサイトの一部分（例えば、信用されるＷｅｂサイトに対応するＵＲＬの限られたサブセット）だけに限定することにより、そのサイトの残りの部分に与える信用のレベルが適切に下げられ、セキュリティが高められる。信用は、例えば、サイトの一部分だけを信用するようにユーザのＷｅｂブラウザを構成することにより、そのサイトの限られた部分に限定することができる。ユーザのＷｅｂブラウザは、手動で構成すること、または、例えば、ウォレットサーバによって提供される構成スクリプトによって構成することが可能である。Ｗｅｂサイトのあるページ（例えば、一部分）だけが、高い信用で使用可能にされているとき、その他のページに関連して含まれるどのスクリプトも、実行されないか、または高い信用では実行されないことになる。
【００８４】
サーバのある部分だけをクライアントが「信用」するようにクライアントを構成することに加えて（または、その代替として）、クライアント−サーバ対話のセキュリティを高めるようにサーバを構成することができる。例えば、セキュリティを高めるためにサーバ上の大部分において高い信用のスクリプト記述を許さないことが可能である。さらに、Ｗｅｂサイトの信用される部分に提供されるデータを、ユーザに戻される前に、監視すること、および／または変更することが可能である（ステップ１３０４および１３０６）。ほとんどのスクリプト記述言語は、コマンドをフォーマットするためにある文字を必要とする。例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ言語は、しばしば、スクリプト命令が山形括弧（「＜」と「＞」）内に入れられてエンコードされる。したがって、Ｗｅｂサイトの信用される部分から戻されることになるどの内容からも、山形括弧を除去することが可能である。例えば、Ｗｅｂサイトの信用される部分から提供されたＷｅｂページが、山形括弧を使用しようと試みる「犯罪的」Ｊａｖａ（登録商標）Ｓｃｒｉｐｔプログラムを含むことがあれば、そのスクリプト命令は、ユーザのコンピュータ上で実行されないことになる。というのは、山形括弧が除去された後には、スクリプト命令が適切にフォーマットされていないことになるからである。別法では、ある「危険な」文字（Ｊａｖａ（登録商標）Ｓｃｒｉｐｔにおける山形括弧など）を別の形式で、例えば、アンパサンド（「＆」）、およびその特定の文字に関する情報交換用米国標準コード（ＡＳＣＩＩ）値を有する「アンパサンド表記」で戻すこと、あるいは「危険な」文字を「スペース」文字などの安全な文字で置換することによって戻すことが可能である（ステップ１３０６）。利用されることが可能な特定の言語、スクリプト記述環境等に応じて、本発明の様々な実施形態において、どの文字でも除去またはエンコードすることが可能であることが理解されよう。
【００８５】
様々な実施形態では、オプションのステップ１３０８は、Ｗｅｂサイトの様々な部分によって提供される情報のデータログを維持することを適切に含む。文字がそこでエンコードまたは除去されたすべての内容をログ記録し、そのログを検査して、ネットワーククライアントを危険にさらすようにＷｅｂサイトが使用されているかを判定できるようにすることが可能である。例えば、Ｗｅｂページから提供されるすべての内容、その信用される部分内から提供されるすべての内容、スクリプト記述／プログラミング内容を有するすべての内容、信用される部分の外部からのすべての内容、またはＷｅｂサイト内容の他の任意の部分を１つまたは複数のデータファイルにログ記録することが可能である。データファイルを適切に探索して、または別の仕方で調べて、サーバによってユーザに許可のない内容を提供しようとする試みが存在したかどうかを判定することができる。
【００８６】
いくつかの場合、監査証跡（例えば、ログ）ファイル内に内容をログ記録することができるネットワークサーバにスクリプトを含む内容を送信する「犯罪的」サイトにより、内部マシンが攻撃されることが可能である。サーバ上に常駐するファイルに関してブラウザが高い信用に構成されている可能性があるので、様々な実施形態では、ユーザがブラウザを使用してＷｅｂサーバおよびその他のｅコマースサーバの監査証跡ファイルを検査するとき、監査証跡記録を送達したネットワークサーバの信用レベルで（例えば、高い信用レベルで）スクリプトがネットワーククライアント上において実行される可能性がある。このスクリプトの実行は、そのスクリプトがネットワークサーバに送信されてずっと後になってから行われることが可能な攻撃を引き起こす可能性がある。この攻撃は、前述した「犯罪的」攻撃のような、クロスサイトスクリプト記述を防止する前述したのと同じ方法および手続きを使用して防止することが可能である。Ｗｅｂサーバなどのネットワークサーバ上で動作する、またはＰＣブラウザなどのネットワーククライアント上で動作する、図１３に記載したもののようなフィルタが、スクリプト制御文字に関するフィルタリングを行ってその文字をエンコードする、その文字を拒否する、またはその記録全体を拒否することができる。
【００８７】
頭記の特許請求の範囲におけるすべての要素に対応する構造、資材、処理、および等価のものには、具体的に請求するその他の請求する要素と組み合わせた機能を行うための任意の構造、資材、または処理が含まれるものとする。本発明の範囲は、以上に提示した実施例によってではなく、許可された特許請求の範囲およびそれと法的等価のものによって決定されなければならない。
【技術分野】
【０００１】
発明の分野
本発明は、一般に、ネットワーク取引を行うための方法および装置に関する。より詳細には、本発明は、インターネットなどのデータネットワークを介してビジネスを認証し、行うためのシステムに関する。
【背景技術】
【０００２】
発明の背景
近年、多くの消費者が、電子方式で商品およびサービスを購入することの便利さと経済性を知るようになった。電子購入（通常、「ｅ購入」と呼ばれる）のためのいくつかのチャネルが利用可能であり、これには、ショップアットホームテレビジョンネットワークやテレビジョン広告に対するコールイン応答等が含まれる。最近では、インターネットを介する直接購入が極めて普及してきている。
【０００３】
通常のインターネット取引においては、消費者は、一般に、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）ブラウザを介して提供されるハイパーテキストマークアップ言語（ＨＴＭＬ）文書などのオンライン広告を閲覧することにより、購入する商品および／またはサービスを識別している。支払いは、通常、消費者と商店の間で確立されるセキュアソケットレイヤ（ＳＳＬ）接続などのセキュアなチャネルを介して提供される課金カード番号を介して行われる。課金カード口座番号は、通常、１６桁のクレジットカード番号である。クレジットカード番号は、通常、番号「００００ ００００ ００００ ００００」によって代表されるような間隔を有する４組の数字を有する標準化された形式に準拠している。最初の５桁から７桁は、処理目的のために予約されており、発行銀行、カードタイプ等を識別する。最後の第１６桁は、１６桁番号のための合計検査として使用される。中間の８から１０桁は、顧客を一意的に識別するのに使用される。この場合、商店は、例えば、カード発行者から直接に認証を受けることによって課金カード番号を処理し、その後、取引を完了する。ＳＳＬ標準は、例えば、「ｈｔｔｐ：／／ｈｏｍｅ．ｎｅｔｓｃａｐｅ．ｃｏｍ／ｅｎｇ／ｓｓｌ３／ｄｒａｆｔ３０２．ｔｘｔ」においてオンラインで利用できる１９９６年１１月１８日付けの「Ｔｈｅ ＳＳＬ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ３．０」によって説明されており、その内容全体が、参照により、本明細書に組み込まれる。
【０００４】
毎日、数百万の取引がインターネットを介して行われるが、従来のＳＳＬ取引は、しばしば、いくつかの顕著な欠点を示す。ＳＳＬは、通常、非良心的なサードパーティが盗聴（例えば、「スニフィング」）する、または別の仕方で購入者の課金カード番号を入手するのを防止するセキュアな終端間接続を提供するが、このプロトコルは、課金カード番号そのものが有効であること、またはそのカード番号を提供している人がそうすることを法的に許可されていることを確実にするためのどのような手段も提供していない。インターネット取引における詐欺の発生件数が高いため、ほとんどの課金カード発行者は、より高い割引率が適用される「Ｃａｒｄ Ｎｏｔ Ｐｒｅｓｅｎｔ」取引であるとネットワーク取引を見なす。言い換えれば、「Ｃａｒｄ Ｎｏｔ Ｐｒｅｓｅｎｔ」取引によるより高いリスクのため、ほとんどの課金カード発行者は、電子手段を介してカード番号を受諾することに関して、カードが商店に物理的に提示された場合に課されるよ
りも高いレートを商店に課す。
【０００５】
セキュアでないネットワークを介して課金カード番号をトランスポートすることに固有のセキュリティの不備を改善するため、多くの人々が、「スマートカード」の使用を示唆している。スマートカードは、通常、そのカード上に直接にデータを記憶するためのマイクロプロセッサおよびメモリを有する集積回路チップを含む。そのデータは、例えば、暗号キーに対応する、または通貨の電子価値を保持する電子財布に対応することが可能である。従来技術において多くのスマートカードスキームが示唆されているが、これらは、通常、非標準であるという点で、顕著な欠点を示している。言い換えれば、商店は、通常、自体のＷｅｂ店頭でスマートカード取引を受諾するためには、新しいプロプラエタリ・ソフトウェアを入手しなければならない。さらに、スマートカードと関連する暗号情報を割り当て、それを維持することに関わる管理コストは、現在まで、非常に高いものとなっている。
【０００６】
様々な暗号技法の使用を介してインターネット取引のセキュリティを改善するＳｅｃｕｒｅ Ｅｌｅｃｔｒｏｎｉｃ Ｔｒａｎｓａｃｔｉｏｎ（ＳＥＴ）標準が示唆されている。ＳＥＴは、標準ＳＳＬ取引に優るより高いセキュリティを提供するが、取引を行うのに必要とされる様々な公開キーおよび秘密キーに関わる管理のため、ＳＥＴは、広く受け入れられずに留まっている。また、ＳＥＴは、ＳＥＴ取引をサポートすることを所望する商店が特別のソフトウェアを有するこ
とを必要とする。
【０００７】
例えば、テキサス州、７８７４６、 Ａｕｓｔｉｎ、１２５０ Ｃａｐｉｔａｌ ｏｆ Ｔｅｘａｓ Ｈｉｇｈｗａｙ Ｓｏｕｔｈ、 Ｂｕｉｌｄｉｎｇ Ｏｎｅ、Ｓｕｉｔｅ ３００のＧｌｏｂｅＳｅｔ，Ｉｎｃ．によって提供されるデジタルウォレット技術などの既存のデジタルウォレット技術は、顧客が取引カード商品（例えば、クレジットカード、課金カード、デビットカード、スマートカード、口座番号等）を利用してオンラインで商品およびサービスのための支払いを行うための手段を提供している。一般に、デジタルウォレットは、電子商取引または他のネットワーク対話を円滑にするために、個人情報（名前、アドレス、課金カード番号、クレジットカード番号等）を記憶するツールである。個人情報は、汎用サーバ上に、またはクライアントロケーション（ＰＣまたはスマートカード）で、あるいは汎用サーバとクライアントサーバの混成物上に記憶することができる。デジタルウォレット汎用サーバは、Ｗｅｂサーバ、および顧客の個人情報およびクレジットカード情報、シッピング選好、ならびにオンライン商店のプロファイルを集中的に格納するデータベースサーバから構成される。
【０００８】
デジタルウォレットは、好ましくは、シングルサインオン／ワンパスワード、チェックアウトページの自動書式記入、ワンクリック購入またはツークリック購入、Ｗｅｂサイトの個人設定、オンライン注文および配送追跡、項目別電子領収書、ならびに支出パターンおよびオプトインに基づくカストマイズされた売出しおよびカストマイズされた販売促進などの機能を行う。より詳細には、ワンクリック購入がウォレットを活動化し、それと同時に、購入を確認する。ツークリックチェックアウトは、まず、ウォレットを活動化し、次に、第２のクリックが購入を確認する。
【０００９】
使用の際、ウォレットブックマークが、通常、顧客によってクリックされて、ウォレットサーバとのＳＳＬセッションが確立される。ブラウザプラグインが実行され、顧客が、ウォレットデータに対するアクセスを得るために、認証のためのＩＤ／パスワードまたはスマートカードを供給する。オンライン商店で買物をする際、適切なウォレットデータが、ウォレットサーバから商店のＷｅｂサーバに転送される。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
したがって、電子取引を行う新しいシステムが所望される。そのようなシステムは、顧客および商店にとってのさらなるオーバーヘッドなしに、より高いセキュリティを提供しなければならない。さらに、そのような新しいシステムは、様々なインターネットウォレットおよび様々なベンダによって提供される他のサービスとよく一体化しなければならない。
【課題を解決するための手段】
【００１１】
発明の概要
本発明の例としての実施形態では、ユーザに、電子取引を行う際に使用することが可能な、スマートカードなどのインテリジェントトークンが提供される。インテリジェントトークンは、デジタル証明書を含み、ユーザに代わって取引のすべてまたはいくつかの部分を行うネットワーク上のサーバと適切に認証を行う。ユーザは、購入取引を行う購入者であり、またサーバは、セキュリティサーバと対話して取引におけるより高い信頼性および信用を提供するウォレットサーバである。
【００１２】
購入取引などの電子取引は、サーバにおいてユーザからの取引要求を受信し、ユーザに対する課題を発行し、その課題に基づいてユーザから応答を受信し、その応答を処理して取引機器を検証し、その電子取引に関する少なくとも１つのキーを含む信用証明を集め、その信用証明の少なくとも一部をユーザに提供し、その信用証明のその一部を含む第２の要求をユーザから受信し、その信用証明のその一部をそのキーで妥当性検査して取引サービスに対するアクセスを提供することによって行われる。
【００１３】
さらに、本発明は、少なくとも選択されたプロトコルに関してネットワークサーバに対するアクセスをそのネットワークサーバの一部分に制限し、また選択されたプロトコルと関連する特定の文字に関してネットワークサーバのその部分をスキャンすることによって、ネットワークサーバを攻撃から守る。それらの特定の文字は、選択されたプロトコルによってもたらされるセキュリティリスクを減らすために、除去すること、または当たり障りのない文字によって置き換えることができる。好ましくは、セキュリティログを形成するために、それらの文字をログ記録することができる。このセキュリティログを検査して、特定の文字が敵意のあるものであるかどうかを判定することができる。あるいは、要求を拒否することができる。
【００１４】
また、本発明は、アクティベータおよびツールバーを有する、購入取引を行うのに使用するデジタルウォレットなどの、取引ツールも含む。好ましくは、ツールバーにより、ユーザは、アクティベータの小さいダウンロードを行うことができ、またツールバーは、例えば、１つまたは複数のオペレーティングシステムコントロール、例えば、システムトレイアイコンを利用する。また、取引ツールは、書式記入構成要素、およびユーザによって以前に提供された情報で書式を事前記入するための自動記憶構成要素も含む。
【００１５】
本発明の以上の特徴および利点、ならびにその他の特徴および利点は、添付の図面と併せて読まれるべき例としての実施形態の以下の詳細な説明において、以降、説明する。図面では、同じ参照番号は、同様の図面における同一または同様の部分を識別するために使用する。
【図面の簡単な説明】
【００１６】
【図１Ａ】図１Ａ〜１Ｃは実施例としての取引システムの様々な実施形態を示すブロック図である。
【図１Ｂ】図１Ａ〜１Ｃは実施例としての取引システムの様々な実施形態を示すブロック図である。
【図１Ｃ】図１Ａ〜１Ｃは実施例としての取引システムの様々な実施形態を示すブロック図である。
【図２】実施例としての購入システムを示すブロック図である。
【図３】実施例としてのセキュリティシステムを示すブロック図である。
【図４】実施例としてのウォレットサーバを示すブロック図である。
【図５】本発明によって形成したデジタルウォレットの実施形態に関する実施例としてのスクリーン表示である。
【図６】本発明によって形成したデジタルウォレットの実施形態に関する実施例としてのスクリーン表示である。
【図７】本発明によって形成したデジタルウォレットの実施形態に関する実施例としてのスクリーン表示である。
【図８】本発明によって形成したデジタルウォレットの実施形態に関する実施例としてのスクリーン表示である。
【図９】実施例としてのアクティベータアプリケーションによって実行される例としてのプロセスを示す流れ図である。
【図１０】実施例のログインのシーケンスを示すメッセージシーケンスチャートである。
【図１１】実施例としての購入のシーケンスを示すメッセージシーケンスチャートである。
【図１２】図１２Ａは、多くのスクリプト記述言語で遭遇するセキュリティ問題の可能性を示すメッセージシーケンスチャートである。 図１２Ｂは、図１２Ａに示したセキュリティ問題のない正しい通信フローを示すメッセージシーケンスチャートである。
【図１３】不要な実行可能コードを削減または除去するための実施例としてのプロセスを示す流れ図である。
【発明を実施するための形態】
【００１７】
好適な例示的実施形態の詳細な説明
本発明は、本明細書では、機能ブロック構成要素および様々な処理ステップの点で説明することができる。そのような機能ブロックは、特定の機能を行うように構成された任意の数のハードウェア構成要素および／またはソフトウェア構成要素によって実現するのが可能なことを理解されたい。例えば、本発明は、様々な集積回路（Ｉ．Ｃ．）構成要素、例えば、メモリ要素、処理要素、論理要素、ルックアップテーブル等を使用することが可能であり、これらの構成要素は、１つまたは複数のマイクロプロセッサまたはその他の制御デバイスの制御の下で、様々な機能を実行することができる。同様に、本発明のソフトウェア要素は、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、ＣＯＢＯＬ、アセンブラ、ＰＥＲＬ、またはそれに類するものなどの、任意のプログラミング言語またはスクリプト記述を使用して実装することが可能であり、その様々なアルゴリズムは、データ構造、オブジェクト、プロセス、ルーチン、またはその他のプログラミング要素の任意の組合せで実装される。さらに、本発明は、データ伝送、シグナリング、データ処理、ネットワーク制御等のための任意の数の従来の技法を使用することができる。また、さらに、本発明を使用して、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、ＶＢＳｃｒｉｐｔ、またはそれに類するものなどのスクリプト記述言語のセキュリティ問題を検出または防止することが可能である。
【００１８】
本明細書に示し、説明する特定の実施態様は、本発明およびその最適の形態を例示するものであり、それ以外にいかなる意味でも本発明の範囲を限定するものではないことを理解されたい。実際、簡明にするため、本明細書では、システムの従来のデータネットワーク機能の態様、アプリケーション開発の態様、およびその他の機能の態様（およびシステムの個々に動作する構成要素の構成要素）は、詳細に説明しないことがあり得る。さらに、本明細書に含まれる様々な図に示す接続回線は、様々な要素間の実施例としての機能関係および／または物理結合を表すものとする。実際の電子取引システムにおいては、多くの代替または追加の機能関係または物理接続が存在する可能性があることに留意されたい。
【００１９】
例としての実施形態の説明を簡明にするため、本発明は、しばしば、インターネット上で動作する電子商取引のシステムに関するものとして説明する。ただし、本発明の多くの適用例を構想できることが理解されよう。例えば、このシステムは、コンピュータシステムのユーザを認証するために、またはパスコードシステムを起動するために、あるいは他の任意の目的で使用するのが可能である。同様に、本発明は、任意のバージョンのＷｉｎｄｏｗｓ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標） ＮＴ、Ｗｉｎｄｏｗｓ（登録商標）２０００、Ｗｉｎｄｏｗｓ（登録商標） ９８、Ｗｉｎｄｏｗｓ（登録商標） ９５、ＭａｃＯＳ、ＯＳ／２、ＢｅＯＳ、Ｌｉｎｕｘ、ＵＮＩＸ（登録商標）、またはそれに類するものなどの任意のオペレーティングシステムを実行する任意のタイプのパーソナルコンピュータ、ネットワークコンピュータ、ワークステーション、ミニコンピュータ、メインフレーム、またはそれに類するものと併せて使用するのが可能である。さらに、本発明は、本明細書では、しばしば、ＴＣＰ／ＩＰ通信プロトコルを使用して実装されるものとして説明するが、ＩＰＸ、Ａｐｐｌｅｔａｌｋ、ＩＰ−６、ＮｅｔＢＩＯＳ、ＯＳＩ、あるいは任意の数の既存のプロトコルまたは将来のプロトコルを使用して本発明を実装することも可能なことが容易に理解されよう。
【００２０】
さらに、顧客および商店は、個々の人々、エンティティ、またはビジネスを代表することが可能であり、一方、銀行は、クレジットカード会社、カードスポンサ会社、または金融機関と契約しているサードパーティ発行者などの他のタイプのカード発行機関を代表することが可能である。支払いネットワークには、クレジットカード、デビットカード、およびその他のタイプの融資／金融カードに関する取引に現在、対応している既存のプロプラエタリネットワークが含まれる。支払いネットワークは、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（登録商標）ネットワーク、ＶｉｓａＮｅｔ（登録商標）ネットワーク、またはＶｅｒｉｐｈｏｎｅ（登録商標）などの、盗聴に対してセキュアであると考えられる閉じたネットワークである。
【００２１】
さらに、中間決済機関などの他の参加者が取引のいくつかの段階において関与していることが可能であるが、これらの参加者は図示していない。各参加者は、取引を円滑にするためのコンピュータシステムを備えている。顧客はパーソナルコンピュータを有し、商店はコンピュータ／サーバを有し、また銀行はメインフレームコンピュータを有している。ただし、これらのコンピュータのどれも、ミニコンピュータ、ＰＣサーバ、コンピュータのネットワークセット、ラップトップ、ノートブック、ハンドヘルドコンピュータ、セットトップボックス等である
ことが可能である。
【００２２】
次に、図１Ａを参照すると、取引システム１００が、少なくとも１つのユーザコンピュータ１１０と、取引オーソライザコンピュータ１２０と、セキュリティサーバ１３０と、オプションの取引ツールサーバ１４０とを適切に含んでいる。本明細書に詳細に説明する様々な実施形態では、取引システム１００は、購入取引を行うために電子商取引で使用される。具体的には、ユーザコンピュータ１１０が購入者または顧客のコンピュータであり、取引オーソライザコンピュータ１２０が商店コンピュータであり、また取引ツールサーバ１４０がデジタルウォレットサーバである。本明細書に説明する取引システムは、電子商取引システムであるが、本発明は他の様々な電子取引システムにも同様に適用可能であることが
理解されよう。
【００２３】
様々なコンピュータシステムおよびサーバは、インターネットまたは別の公衆データネットワークなどの任意のデータネットワークであるデータネットワーク１０２によって適切に相互接続されている。その他の適切なネットワーク１０２には、公衆交換電話網（ＰＳＴＮ）、企業イントラネットまたは大学イントラネット等が含まれる。図１Ｂに示すもののような様々な実施形態では、商店コンピュータ１２０は、ネットワーク１０２とは別個のデータ接続１５２を介してセキュリティサーバ１３０に電子的に結合されている。同様に、様々な実施形態は、ウォレットサーバ１４０とセキュリティサーバ１３０を接続するネットワーク１０２とは別個の接続１５０を含む。接続１５０および１５２で使用するのに適した実施例としてのデータ接続には、電話接続、ＩＳＤＮ接続、専用Ｔ１、またはその他のデータ接続、ワイヤレス接続等が含まれる。接続１５０および接続１５２は、同一の接続であること、あるいは、それぞれが、本発明の様々な実施形態における完全に別の形態の接続であることが可能であるのが理解されよう。
【００２４】
また、図１Ｃに示すもののような様々な実施形態は、アプリケーションサーバ１６０を含む。様々な実施形態では、データベース（図示せず）および／またはプロファイルサーバ（図示せず）がアプリケーションサーバ１６０および／またはウォレットサーバ１４０に接続されていることが可能である。アプリケーションサーバ１６０は、ワークロードの均衡をとるのに使用することができる。デジタルウォレット１４０とアプリケーションサーバ１６０の間でワークロードを分散することにより、効率および／またはセキュリティを高めることができる。例えば、アプリケーションサーバ１６０は、データベースアクセスなどの、ウォレットサーバ１４０によって行われる機能性のいくらかを行うことができる。アプリケーションサーバ１６０はデータネットワーク１０２に接続されていないので、データベースアクセスをウォレットサーバ１４０ではなくアプリケーションサーバ１６０によって行わせることにより、セキュリティを高めることができる。
【００２５】
図１Ａ〜１Ｃに様々な例としての実施形態を示したが、その他の実施形態も可能であることが理解されよう。例えば、一実施形態は、接続１５０を含むが、接続１５２は含まないこと、またはその逆であることが可能である。さらに、構成要素（例えば、顧客１１０、商店１２０、セキュリティサーバ１３０、ウォレットサーバ１４０、およびアプリケーションサーバ１６０）は、個々のコンピュータであること、あるいは、本明細書に説明する機能を満たす同様の目的で動作するネットワーク化されたグループのコンピュータであることが可能である。前述の機能性を満たすために、単一の構成要素に帰せられた機能性を１つまたは複数の個々のコンピュータに分散することが可能である。例えば、ウォレットサーバ１４０は、実際には、Ｗｅｂサーバ、アプリケーションサーバ、データベースサーバ、およびその他のタイプのサーバの集合であることが可能である。
【００２６】
取引を行うため、顧客１１０が、ネットワーク１０２を介して商店１２０と適切に接続を確立する。購入を達しようとするとき、顧客１１０がウォレットサーバ１４０にアクセスする。この時点で、顧客１１０がセキュリティサーバ１３０にリダイレクトされ、顧客がスマートカードを有していることが検証される。スマートカードは、そのカードを一意的に識別するデジタル証明書を含み、以下に説明するとおり、取引に関係するデジタル信用証明を作成できるようにしている。様々な実施形態では、デジタル信用証明のいくつかの部分が顧客１１０に戻され、一部がセキュアな接続１５０を介してウォレットサーバ１４０に提供される。次に、顧客１１０は、そのデジタル信用証明を使用してウォレットサーバ１４０に対して認証を行うことができ、このウォレットサーバが顧客１１０のためのプロキシとして電子取引を完了することができる。ウォレットサーバ１４０は、例えば、商店コンピュータ１２０に関連する購入書式を完成させるための機能性を含むことが可能である。商店１２０が顧客１１０から、またはウォレットサーバ１４０からセキュア購入機器識別子を受信したとき、通常の任意の課金カード認証と同様に、接続１５２を介してカード認証が行われる。前述したとおり、通信は、様々なプロトコル、例えば、ＳＳＬまたはＶＰＮ等を使用して行うことができる。スマートカードは、特定のカードに固有であり、また電子手段を介してネットワークに知らせることの可能な識別情報を含むので、スマートカードを使用して行われる購入取引は、通常の課金カードまたはクレジットカードを使用して行われる取引よりもセキュアである。セキュアな取引に対しては、より低い割引率が見合うものとなる可能性があり、この取引は、カード発行者によって「Ｃａｒｄ Ｐｒｅｓｅｎｔ」取引として処理される可能性がある。さらに、取引が「Ｃａｒｄ Ｐｒｅｓｅｎｔ」取引である場合、詐欺のリスクを商店からカード発行者に転移することができる。
【００２７】
次に、図２を参照すると、実施例としての購入者コンピュータ１１０（クライアントコンピュータ、顧客コンピュータ、またはユーザコンピュータとも呼ぶ）は、データネットワーク１０２上で電子購入取引を開始することができる任意のコンピュータシステムである。様々な実施形態では、購入者コンピュータ１１０は、ワシントン州、ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能な任意のバージョンのＷｉｎｄｏｗｓ（登録商標）オペレーティングシステム、またはカリフォルニア州、ＣｕｐｅｒｔｉｎｏのＡｐｐｌｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能な任意のバージョンのＭａｃＯＳオペレーティングシステムなどの任意のオペレーティングシステムを実行するパーソナルコンピュータである。
【００２８】
購入者コンピュータ１１０は、スマートカード２０２が、オペレーティングシステム２１２を介してＷｅｂブラウザ２１６とインターフェースをとることを可能にするハードウェアおよび／またはソフトウェアを適切に含む。Ｗｅｂブラウザ２１６は、カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＮｅｔｓｃａｐｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＮｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｏｒ、ワシントン州、ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、またはバージニア州、ＤｕｌｌｅｓのＡｍｅｒｉｃａ Ｏｎｌｉｎｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＡＯＬ Ｂｒｏｗｓｅｒなどの、ネットワーク１０２を介して通信する、購入者コンピュータ１１０と適合する任意のプログラムである。様々な実施形態では、購入者コンピュータ１１０は、ウォレットサーバ１４０と通信するように構成された任意のコンピュータプログラムであるウォレットクライアント２１４を含む。実施例としてのウォレットクライアント２１４は、Ｍｉｃｒｏｓｏｆｔ Ｗａｌｌｅｔ、またはテキサス州、ＡｕｓｔｉｎのＧｌｏｂｅｓｅｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＧｌｏｂｅｓｅｔ Ｗａｌｌｅｔである。ただし、任意のウォレットプログラムを使用することが可能である。
【００２９】
ウォレットクライアント２１４およびブラウザ２１６は、オペレーティングシステム２１２を介してカードリーダ２０４にデータを送ることによってスマートカード２０２と対話することができる。カードリーダ２０４は、ウォレットクライアント２１４とスマートカード２０２の間で情報を転送することができる任意のリーダデバイスである。様々な実施形態では、カードリーダ２０４は、カリフォルニア州、Ｒｅｄｗｏｏｄ ＣｉｔｙのＧｅｍｐｌｕｓ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＭｏｄｅｌ ＧＣＲ４１０などのＩＳＯ−７８１６対応のリーダ、またはその他の任意の適切なリーダである。
【００３０】
スマートカード２０２は、以下のＩＳＯ標準に対応する任意のスマートカードなどの、電子取引を行うことができる任意のカードであり、これらすべての標準は、参照により、その全体が本明細書に組み込まれる。
【００３１】
ＩＳＯ／ＩＥＣ ７８１６−１：１９９８ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ １： Ｐｈｙｓｉｃａｌ ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ、
ＩＳＯ／ＩＥＣ ７８１６−２：１９９９ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ２： Ｄｉｍｅｎｓｉｏｎｓ ａｎｄ ｌｏｃａｔｉｏｎ ｏｆ ｔｈｅ ｃｏｎｔａｃｔｓ、
ＩＳＯ／ＩＥＣ ７８１６−３：１９９７ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ３： Ｅｌｅｃｔｒｏｎｉｃ ｓｉｇｎａｌｓ ａｎｄ ｔｒａｎｓｍｉｓｓｉｏｎ ｐｒｏｔｏｃｏｌｓ、
ＩＳＯ／ＩＥＣ ７８１６−４：１９９５ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ４： Ｉｎｔｅｒｉｎｄｕｓｔｒｙ ｃｏｍｍａｎｄｓ ｆｏｒ ｉｎｔｅｒｃｈａｎｇｅ、
ＩＳＯ／ＩＥＣ ７８１６−５：１９９４ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ５： Ｎｕｍｂｅｒｉｎｇ ｓｙｓｔｅｍ ａｎｄ ｒｅｇｉｓｔｒａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ ｆｏｒ ａｐｐｌｉｃａｔｉｏｎ ｉｄｅｎｔｉｆｉｅｒｓ、
ＩＳＯ／ＩＥＣ ７８１６−６：１９９６ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ６： Ｉｎｔｅｒｉｎｄｕｓｔｒｙ ｄａｔａ ｅｌｅｍｅｎｔｓ、および
ＩＳＯ／ＩＥＣ ７８１６−７：１９９９ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃａｒｄｓ−Ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ（ｓ） ｃａｒｄｓ ｗｉｔｈ ｃｏｎｔａｃｔｓ−Ｐａｒｔ ７： Ｉｎｔｅｒｉｎｄｕｓｔｒｙ ｃｏｍｍａｎｄｓ ｆｏｒ Ｓｔｒｕｃｔｕｒｅｄ Ｃａｒｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ（ＳＣＱＬ）。
【００３２】
実施例としてのスマートカード２０２は、独国、ＭｕｎｉｃｈのＩｎｆｉｎｅｏｎ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なモデルＳＬＥ６６チップを含むＩＳＯ ７８１６規格に準拠するスマートカードである。ＳＬＥ６６チップは、メモリ（１６ｋメモリなどであるが、より多いまたはより少ないメモリを使用することも可能である）、および、例えば、Ｍｕｌｔｏｓオペレーティングシステム（Ｍｕｌｔｏｓ ｖ．４など）を実行するプロセッサを含む。様々な実施形態では、スマートカード２０２は、また、デジタル証明書を記憶し、それを処理するためのアプレットまたはその他の暗号関数も含む。暗号法の基本的な概説に関しては、Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓによって刊行されたＢｒｕｃｅ Ｓｃｈｎｅｉｅｒによる「Ａｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ： Ｐｒｏｔｏｃｏｌｓ，Ａｌｇｏｒｔｈｍｓ，Ａｎｄ Ｓｏｕｒｃｅ Ｃｏｄｅ Ｉｎ Ｃ」（第２版、１９９６年）を参照されたい。この刊行物は、参照によって本明細書に組み込まれる。例えば、Ｘ．５０９ Ｊａｖａ（登録商標）アプレットをスマートカード２０２上に、そこに記憶されたＸ．５０９証明書を処理するために含めることが可能である。本明細書に説明する実施形態はスマートカードを利用するが、その他のインテリジェントトークン、例えば、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＧＳＭ）のモバイル電話機で本発明の様々な実施形態におけるスマートカードを置き換えることが可能である。
【００３３】
次に、図３を参照すると、セキュリティサーバ１３０が、ネットワーク１０２に対するインターフェース、セキュリティエンジン３０４、およびデータベース３１０と通信する認証サーバ３０６を適切に含む。ネットワークインターフェース３０２は、Ｗｅｂサーバなどの、ネットワーク１０２上の通信を円滑にする任意のプログラムである。様々な実施形態では、ネットワークインターフェース３０２は、カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＮｅｔｓｃａｐｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＮｅｔｓｃａｐｅ Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｅｒに基づく。ネットワークインターフェース３０２は、ネットワーク１０２上で電子メッセージを受信し、適切なように、それらをセキュリティエンジン３０４または認証サーバ３０６に経路指定する。
【００３４】
セキュリティエンジン３０４と認証サーバ３０６は、ファイアウォール３０８によって隔てられていることが可能である。ファイアウォール３０８は、内部ネットワークと外部ネットワーク（図示せず）の間におけるデータフローを制限することができる任意のハードウェアまたはソフトウェアのコントロール（ルータアクセスコントロールなど）である。様々な実施形態では、セキュリティエンジン３０４は、ファイアウォールの外側に常駐して、セキュリティサーバ１３０と顧客１１０またはウォレットサーバ１４０との間におけるデータ転送を適切に管理する。認証サーバ３０６は、システム１００と関連する様々なスマートカード２０２上に記憶されたｘ．５０９証明書の相互参照を含むことが可能な、データベース３１０などの貴重な機密情報を保持し、したがって、より高いセキュリティのために内部ネットワーク上で適切に保守されていることが可能である。本発明の範囲を逸脱することなく、セキュリティエンジン３０４の機能性と認証サーバ３０６の機能性を適切に組み合わせる、または分離するのが可能なことが理解されよう。
【００３５】
次に、図４を参照すると、実施例としてのウォレットサーバ１４０が、ネットワークインターフェース４０２と、オプションのアプレットサーバ４０４と、ウォレットアプリケーション４０６とを含む。ネットワークインターフェース４０２は、Ｗｅｂサーバなどの、ネットワーク１０２上の通信を円滑にする任意のプログラムである。様々な実施形態では、ネットワークインターフェース４０２は、カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＮｅｔｓｃａｐｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＮｅｔｓｃａｐｅ Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｅｒに基づく。オプションのアプレットサーバ４０４は、Ｊａｖａ（登録商標）プログラムまたはＡｃｔｉｖｅＸコントロールなどの分散型プログラムのためのサーバ機能性を提供する。実施例としてのアプレットサーバは、カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓから入手可能なＪａｖａ（登録商標） Ａｐｐｌｅｔ Ｓｅｒｖｅｒである。アプレットサーバ４０４およびネットワークインターフェース４０２は、ログイン機能性を扱い、ウォレットデータベース４０８からウォレットデータを検索し、かつ／または本明細書に説明する取引を管理することができる、ウォレットアプリケーション４０６のためのサポート機能性を提供する。本発明の様々な実施形態では、ウォレットサーバ１４０は、テキサス州、ＡｕｓｔｉｎのＧｌｏｂｅｓｅｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＳＥＲＶＥＲＷＡＬＬＥＴ（別名、ＮＥＴＷＡＬＬＥＴ）プログラムを含むことが可能である。
【００３６】
本発明の様々な実施形態は、ウォレット購入プロセスで消費者を適切に助けるアクティベータアプリケーションを含むことが可能である。アクティベータアプリケーションは、例えば、ステータス情報を提示すること、または、適切なときにウォレットクライアント２１４（図２）を能動的に起動することができる。さらに、アクティベータは、ウォレットによってサポートされるサイトのローカルキャッシュを保持することができる。
【００３７】
アクティベータアプリケーションプログラムは、従来のコンピュータアプリケーションとして実装することができる。様々な実施形態では、アクティベータアプリケーションは、システムトレイアイコンとして、「浮動ビットマップ」として、またはその他の任意の適切な仕方で情報を表示する。グラフィック表現（例えば、アイコン）が、「サポートされたサイトでブラウズ中」、「サポートされたチェックアウトページでブラウズ中」、「サポートされた支払いページでブラウザ中」、「開いたブラウザウィンドウなし」、「サポートされていないページでブラウズ中」、および／またはそれに類するものなどのステータス情報を示す
ことが可能である。
【００３８】
浮動ビットマップは、任意のグラフィックファイルまたはグラフィック形式、例えば、Ｇｒａｐｈｉｃｓ Ｉｎｔｅｒｃｈａｎｇｅ Ｆｏｒｍａｔ（ＧＩＦ）ファイルで実装することができる。代替の実施形態は、グラフィック形式、オーディオ形式、ビジュアル形式、オーディオビジュアル形式、マルチメディア形式、動画形式、またはその他の形式で情報を提示する。さらに、ＧＩＦファイルは、ＬＺＷファイル、ＴＩＦＦファイル、動画ＧＩＦファイル、ＪＰＥＧファイル、ＭＰＥＧファイル、あるいは他の任意の種類のグラフィック、オーディオ、もしくはマルチメディアの形式またはファイルで置き換えることが可能である。
【００３９】
好ましくは、本発明は、ユーザがより容易に取引ツールを使用できるようにするコントロールを含むウィンドウを備えた取引ツールを提供することによって機能強化される。取引ツールは、様々な電子取引のために使用することができる。例えば、購入取引、財務相談取引、保険取引、物々交換取引などの消費者間取引、売出しまたは報償に関する取引等である。本明細書に詳細に説明する取引ツールは、電子購入取引のために使用されるデジタルウォレットである。デジタルウォレットは、顧客がより容易にウォレットを使用するためのコントロールを備えたウィンドウを提供することによって機能強化される。好ましくは、本発明は、デジタルウォレット機能性にアクセスするためのクライアント側の実装（「アクティベータ」）、およびユーザがアクティベータの小さいダウンロードを行い、かつオペレーティングシステムユーザインターフェースの１つまたは複数の制御要素、例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）システムトレイアイコンを利用することができるようにするサーバ側のツールバーを含む。
【００４０】
アクティベータは、ユーザのコンピュータ上で動作するオブジェクトコードであり、ウォレットサーバにアクセスするためのルーチンを含む。アクティベータは、イベントを生成することができ、またアクティベータは、特定のユーザ処理またはイベントおよび特定のシステム処理またはイベントに応答するウォレットサーバとの通信を可能にする手続き論理を含む。好ましくは、アクティベータは、単一のグラフィック要素、例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）の実施形態ではＷｉｎｄｏｗｓ（登録商標）システムトレイアイコンとして現れ、ユーザがウォレットツールバーの出現をトリガすることができるようにするアイコンを提示する。様々な実施形態では、ウォレットツールバーは、実際には、ウォレットサーバにアクセスする特別ブラウザウィンドウである。アクティベータは、ウォレットサーバと通信し、小さいダウンロードを介してアクティベータオブジェクトコードの更新を自動化する。好ましくは、ユーザは、アクティベータのダウンロードを行う前に確認を求められる。様々な実施形態では、アクティベータは、ウォレット以外のアプリケーション、例えば、報償の提供のアプリケーションと通信する。
【００４１】
システムは、関係のあるオプションの内容をそのウェブページのそれぞれ上で提供する。内容とは、すなわち、ユーザによって閲覧される各ページに固有の動的な文脈による情報である。このことは、アクティベータがＵＲＬを監視し、場合によっては、ページ上に記号を入れてユーザに潜在的な機会を気付かせるのを可能にすることによって実現される。例えば、アクティベータは、ユーザが商店サイトを閲覧しているかをチェックして、該当する申し出（例えば、商品の値引き等）をユーザに提示することができる。また、アクティベータは、ユーザのシステム上のソフトウェアのバージョンを監視し、そのユーザに可能なアップグレードバージョンのことを知らせることができる。例としての実施形態では、システムは、ＷＡＮ、ＬＡＮ、インターネットなどの任意のネットワーク上、あるいは任意のパーソナルコンピュータ上、ワイヤレス電子デバイス上、またはその他の任意の同様なデバイス上に実装される。システムは、オペレーティングシステム上に、例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃ ＯＳ、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ（登録商標） ＣＥ、Ｐａｌｍ ＯＳ、その他のものの上に実装することができる。
【００４２】
好ましくは、クライアント側で実装されるアクティベータにより、ユーザ１１０は、デジタルウォレット１４０発行者、例えば、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓと常時、または断続的に通信することができ、ユーザのディスプレイ上で邪魔なウィンドウに空間を占領させる必要がない。前述したとおり、これにより、ウォレット発行者は、監視を行い、適切なときに、可能な興味のアイテムをユーザに提示することができる。ウィンドウ内に提示される構成可能なコントロールにより、顧客は、所望のＷｅｂサイトに迅速にナビゲートすることができ、またデジタルショッピングカートチェックアウトなどの所望の機能性を即時に呼び出すことができる。好ましくは、クライアントツールバーは、ユーザのブラウザウィンドウと関連する別個のウィンドウであることが可能であり、それを実質的にユーザブラウザの一部分にする形状を保持する。ユーザがそのコントロール上でクリックしたとき、ウィンドウはその元の状態のままであるが、すなわち、ウィンドウは、ブラウザウィンドウが所望のＵＲＬを訪問するようにダイレクトして、特定の処理（デジタルウォレットの使用など）を呼び出す。例えば、システムトレイからデジタルウォレットアイコンを選択した後、デジタルウォレットツールバー５０２が、図５に示すとおり、ユーザのブラウザウィンドウ５００と関連する別個のウィンドウとして表示される。代替の実施形態では、クライアントツールバーは、既存のウォレットウィンドウのフレームとなり、既存のウォレットによって提供されるウィンドウエリアの延長で、前述したとおり、追加のコントロールを提供する。別の代替の実施形態では、エリアがユーザの標準ブラウザウィンドウ内で分割されて、ウォレットおよび前述したその他のコントロールとして使用することができるエリアが作成される。
【００４３】
システムは、好ましくは、顧客が気に入ったＵＲＬを訪問するためだけでなく、そうでなければ多くのステップが課される可能性があり、ベンダのサイトが常に更新されるために変化する可能性のある特定の機能性を呼び出すための便利な手立てを提供する。また、システムは、好ましくは、ウォレットおよびｅコマースサイトを使用しやすくするだけでなく、ウォレットおよびクライアントツールバーを見つけやすくすることによって、よりシンプルなユーザ体験も提供する。ユーザに多数の異なるウィンドウが開かれているとき、ウォレットウィンドウを見つけるのは、困難で面倒である可能性があり、特に、通常のナビゲーションおよびサイトとの対話の最中に、異なるブラウザウィンドウがＧＵＩの中心となるので、そうである。このため、システムトレイアイコンおよびサーバ側の機能性を使用することで、よりよいユーザ体験が提供される。好ましい実施形態では、本システムは、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒなどの当技術分野で知られる任意のブラウザで機能する。
【００４４】
従来技術のシステムは、単に、ユーザがページを訪問し、次にそのページからリンクを渡ることを可能にするカストマイズすることができるポータル（例えば、ＭｙＡｍｅｒｉｃａｎＥｘｐｒｅｓｓ．ｃｏｍ）を提供することができるが、本発明の例としての実施形態は、ユーザがＷｅｂをナビゲートするなかで、ユーザのデスクトップ上に留まることになるコントロールを有するウィンドウを提供する。さらに、クライアントツールバーは、ユーザのための処理を自動化する手段を提供し、これらの処理は、サードパーティのｅコマースサイトで行われる。さらに、従来技術のシステムは、別個のブラウザウィンドウを利用してウォレットコントロールを提供することができるが、本発明は、分割された標準のブラウザウィンドウを利用してウォレットが占めるべきエリアを提供する。例えば、好ましい実施形態では、デジタルウォレットアイコンが、システムトレイアイコン（図示せず）としてユーザに利用可能である。デジタルウォレットアイコンを呼び出すと、デジタルウォレットツールバー５０２が、図５に示すとおり表示される。デジタルウォレットツールバーは、ユーザがデジタルウォレットを利用できるようにするコントロールを含みながらも、目障りではない。好ましくは、ツールバー５０２は、ブラウザウィンドウ５００と関連している。
【００４５】
図６に示すとおり、ユーザがツールバー５０２からショッピングディレクトリボタンを選択した場合、ツールバーがショッピングディレクトリページ６０２まで拡張する。ユーザは、このショッピングディレクトリページ６０２内に表示された商店６０４のリストから商店を選択することができる。商店のリスト６０４から商店を選択したとき、デジタルウォレットが、図７に示すように、選択された商店サイト７０２にユーザを連れて行く。好ましくは、デジタルウォレットが、商店サイト７０２にユーザを連れて行ったとき、ツールバー５０２はその通常のサイズに戻る。
【００４６】
ユーザが、例えば、アイテムをショッピングカートに入れ、商店のサイトでチェックアウトに取りかかることにより、商店から購入を行うとき、チェックアウト機能が、部分的に、本発明のデジタルウォレットによって行われる。図８に示すとおり、ユーザが商店サイト７０２で所望の購入を示したとき、デジタルウォレットのチェックアウトユーザインターフェース８０２が表示される。例えば、チェックアウト表示８０２がブラウザウィンドウの一方の側に現れ、他方、商店ウィンドウ７０２は、ブラウザウィンドウの反対の側にまだ表示されている。商店チェックアウトでユーザが通常、入力しなければならないことになる情報の多く（例えば、名前、住所、電子メールアドレス、クレジットカード情報等）は、デジタルウォレットによって既に知られており、デジタルウォレットチェックアウトウィンドウ８０２内で事前記入される。好ましい実施形態では、ユーザは、事前記入された情報を編集することができる。
【００４７】
好ましくは、本システムは、また、Ｗｅｂサイト上にＨＴＭＬ書式を確実に入れるのを容易にする方法および装置も含む。最終結果として、ユーザは、様々なｅコマースＷｅｂサイトの実際の外観、ラベル付け、および挙動とは独立に、自らがサイトに提供することを所望する情報内容を一般的な形で識別することができる。好ましくは、本発明は、ユーザが入力されたデータをキャプチャすることを可能にする「自動記憶」構成要素、およびいくつかの異なるサイトおよびユーザのモデルの組合せからもたらされる強力な一組のプロセスを含む「書式記入」構成要素を含む。
【００４８】
本発明は、ユーザから情報を収集し、それをサーバ上にセキュアかつ信頼の置ける仕方で記憶し、次に、それをユーザの指示の下で適切な書式フィールドに提供する。システムは、ユーザの関心対象であるサイトの様々なＨＴＭＬ書式フィールドに対するユーザ情報のマッピングを維持する。次に、この情報が、これらのサイトと対話することを所望するユーザのために、どのようにＨＴＭＬ書式が記入される（または事前記入される）べきかを指示することができる。
【００４９】
「自動記憶」機構に関して、従来技術のデジタルウォレットは、記憶機能を実装することができるが、その機能はユーザによって開始されなければならない。本「自動記憶」機構では、デジタルウォレットユーザは、自らが記入したばかりの書式を記憶するのにボタンをクリックする必要がない。というのは、本システムは、ユーザが商店ウィンドウ上でサブミットするフィールドを記憶するからである。書式がサブミットされたとき（例えば、「Ｓｕｂｍｉｔ」ボタンまたは「Ｂｕｙ」ボタンを押すことにより）、オンラインウォレットは、その書式提出をトリガしたウィンドウが、関与の商店ウィンドウであるかを判定することで応答する。関与の商店ウィンドウであった場合、ウォレットは、そのデータを適切に記憶し、そうでない場合、ウォレットは、書式提出のオカレンスを無視して、通常通り動作しつづけることができる。デジタルウォレットコントロールは、「記憶」とラベル付けされたボタンを含むことができ、あるいは、常時、アクティブである自動記憶機構もサポートすることができる。一般に、ウォレットによって自動的に埋められたもの以外のフィールドが、記憶されることが可能である。このコンテキストでは、フィールドを記憶することは、ユーザが特定のフィールドにデータを入力したとき、その値がシステムによって格納されることになることを意味する。ウォレット構成要素は、この仕方で入力されたフィールド値を検出し、インターネットを介してそれらをセキュアな仕方でサーバに伝送することになる。ユーザが次回にこのページに行ったとき、ウォレットは、ウォレットシステムから検索されたフィールドで書式を埋めることに加え、以前に記憶されている値でその書式を埋めることにもなる。書式を処理する（事前記入する）際、ウォレットは、サーバからセキュアな仕方でフィールド値を検索することになる。
【００５０】
より詳細には、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザに関して、本発明は、例えば、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ ＷａｌｌｅｔなどのＷｅｂページに自体を付加するＡｃｔｉｖｅＸコントロールを適切に実装する。好ましい実施形態では、ＡｃｔｉｖｅＸコントロールは、すべてのＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザのブラウザイベントをキャプチャするメソッドを含み、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔが、必要な場合、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔ内にロードされるＪａｖａ（登録商標）Ｓｃｒｉｐｔ関数により、これらのイベントに応答できるようにしており、これにより、システムが、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザ内で完全にダウンロードされた文書を得ることを可能にしている。具体的には、これにより、システムは、文書のロードがいつ済んだのかを特定するＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザによって生成される「Ｄｏｃｕｍｅｎｔ Ｃｏｍｐｌｅｔｅ」イベントをキャプチャすることができる。このイベントがキャプチャされたとき、ｃｔｉｖｅＸコントロールが、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔ内にロードされたＪａｖａ（登録商標）Ｓｃｒｉｐｔ関数をコールすることによってＡｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔに通知する。この関数は、ＡｃｔｉｖｅＸコントロールと通信して、すべてのＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザ上ですべての書式に関する「Ｆｏｒｍ Ｓｕｂｍｉｔ」イベントを適切にキャプチャすることでこのイベントに応答する。
【００５１】
ユーザが、Ｗｅｂページ上の書式を記入して、そのページに関する「Ｓｕｂｍｉｔ」（すなわち、書式をサブミットする、ボタンなどの任意のコントロール）ボタンをクリックしたとき、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔ内にロードされたＪａｖａ（登録商標）Ｓｃｒｉｐｔ関数をコールするＡｃｔｉｖｅＸコントロールにより、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔに通知が行われる。次に、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔは、イベントを生成したウィンドウのＵＲＬを検査することにより、「Ｓｕｂｍｉｔ」イベントを生成している文書が関与のものであるかを適切に判定する。そのイベントが処理されるべき場合、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔは、そのイベントを生成した文書オブジェクトモデル（ＤＯＭ）を入手するＡｃｔｉｖｅＸコントロール内の適切な関数をコールしなければならない。次に、ＤＯＭを走査して書式値を保存し、それらの値をメモリ内に記憶するためにサーバに送信できるようにする。好ましい実施形態では、ＡｃｔｉｖｅＸコントロールは、自体を適切に、ブラウザイベントおよび書式「Ｓｕｂｍｉｔ」イベントをキャプチャすることとは切り離して、ランタイムエラーが最小限に抑えられるようにする。
【００５２】
Ｎｅｔｓｃａｐｅブラウザに関しては、Ｎｅｔｓｃａｐｅのイベントの実施態様の理由で、システムは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ内だけからイベントをキャプチャする。システムがうまく「Ｕｎｉｖｅｒｓａｌ Ｂｒｏｗｓｅｒ Ｗｒｉｔｅ」特権を得た（すなわち、ユーザによって与えられた）場合、次に、システムは、外部ウィンドウが別のウィンドウのイベントをキャプチャするのを可能にする関数をうまくコールすることができる。次に、システムは、そのウィンドウのすべてのフレームに関して、その文書オブジェクトモデルを走査することができる。これを行う際、システムは、ウィンドウの各書式に、システムが「Ｓｕｂｍｉｔ」イベントをキャプチャするのを所望していることを知らせる。このため、システムが通知したウィンドウ上の書式をユーザが記入し、そのページに関する「Ｓｕｂｍｉｔ」ボタン（すなわち、書式をサブミットするボタンなどの任意のコントロール）をクリックしたとき、オンラインウォレットが通知を受けて、適切に応答する。本発明は、任意の適切なデジタルウォレットシステムを含むが、それには限定されない任意の適切な取引システムにおいて実装できることが、当分野の技術者には理解されよう。
【００５３】
書式記入機能に関しては、例えば、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ Ｏｎｌｉｎｅ Ｗａｌｌｅｔなどのデジタルウォレットが、書式を埋める際にユーザを助ける書式記入機能性を提供する。ＧｌｏｂｅＳｅｔ，Ｉｎｃ．によって提供されるシステムのような従来技術のシステムは、通常、Ｂｒｏｗｓｅｒ Ｈｅｌｐｅｒ Ｏｂｊｅｃｔ（ＢＨＯ）を使用する。ＢＨＯ手法は、しばしば、例えば、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ ５．０ブラウザが、レジストリ内で指定された第１のＢＨＯしかロードしないというバグを有するといったような欠点を含む。このことは、そのＢＨＯがロードされたかどうか確信できないため、どの適用例に関しても問題となる。さらに、ＢＨＯがＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒの各インスタンスごとにロードされて、ＢＨＯの複数のインスタンスが任意の所与の時点で動作し、したがって、メモリを食い、関与の１つのブラウザだけのためにすべてのブラウザに関してナビゲーションの速度を低下させることになる可能性がある。
【００５４】
本発明は、好ましくは、「自動記憶」機構で指定したのと同じ「ＡｃｔｉｖｅＸコントロール」を使用することで、ＢＨＯの解決策の代りにする。Ｏｎｌｉｎｅ Ｗａｌｌｅｔ ＷｅｂページにＡｃｔｉｖｅＸコントロールを付加することにより、システムは、例えば、Ｓｈｅｌｌ Ｗｉｎｄｏｗｓ（登録商標） ＡＰＩを使用することによって任意の所与のＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザ内にロードされる任意の文書に関する文書オブジェクトモデルを適切に獲得する。ユーザがＯｎｌｉｎｅ Ｗａｌｌｅｔ上で「Ｆｉｌｌ Ｆｏｒｍ」ボタンをクリックしたとき、ウォレットは、まず、ＡｃｔｉｖｅＸコントロールを介して文書オブジェクトモデルを獲得することで応答することができる。次に、ウォレットは、書式を構成するフィールドの名前を保存し、それらをサーバ上のヒューリスティックエンジンに送信することができる。サーバは、これらのフィールドを埋めるのに使用されるべき値を戻すことでこの要求に応答することになる。次に、以前に獲得したのと同じ文書オブジェクトモデルを使用して、フィールドを埋めることができる。このため、本発明は、Ｗｅｂサイトで書式に反復性のデータを入力しなければならないという問題を抑える。顧客の側での労力を節約することに加え、本発明は、入力されたデータの正確さを高める。
【００５５】
より詳細には、本発明のアーキテクチャは、各サイトのサーバ側モデル（例えば、フィールド、ページ、リンク等）、ユーザのサーバ側モデル（例えば、プロファイル）、サイトのユーザ生成モデル（例えば、マクロ記録、タグ付け、ドラッグアンドドロップ）、システムによって手動で生成されたサイトのモデル（例えば、ユーザ生成モデルを強化および妥当性検査するため）、およびヒューリスティックに生成されたサイトのモデル（例えば、フィールド、処理等に関する意味情報の推論）を組み合わせる。本システムは、いくつかの別々のタイプのモデルを作成し、記憶する。第１のモデルは、例えば、どのように個人がチェックアウトするか、どのように個人が何かをショッピングカートに追加するか、どのように個人があるタイプの製品を探索するか、どのように個人が選好を入力するか（例えば、旅行）等、サイトを特徴付ける。第２のモデルは、例えば、ユーザが行うことができるのは何であるか、またユーザのプロフィル属性がどのようなものであるか、ユーザを特徴付ける。これら２つのモデルを組み合わせることにより、本システムは、高い柔軟性とパワーを追加する特別なプロセスを作成する。システムは、ユーザが何を行うことができるかというモデルから、サイトのモデルに対してマッピングを行い、サイトモデルは、知られている任意の方法によって生成される。このため、サイトモデルは、ユーザ、ホスト、または取引カード会社（発行者）により、あるいはサイトプロバイダによっても作成されることが可能である。好ましい実施形態では、ＥＣＭＬ／ＸＭＬを使用してサイトに関するモデルを表すことができる。様々な実施形態では、サイトモデルを他のシステムと交換することが可能である。
【００５６】
例えば、ユーザは、航空券を購入するため、異なる航空サービスおよび旅行サービスのサイトを日常的に訪れることが可能である。各サイトは、通常、様々なサイト間で比較的似通った情報を収集するために、様々なスクリーン上でフィールドを有する。ただし、各サイトは、異なるＵＲＬ上に配置された異なるＨＴＭＬ書式フィールドを使用することになり、また、これらのフィールドは、時間の経過とともに変わる可能性がある。異なるサイトを通じて情報が似通った性質のものであっても、現行では、ユーザの旅行の選好に関して（例えば、座席配置、食事、旅行時期、アフィニティ報償等）に関してフィールドを埋めるプロセスを自動化する共通の機構が存在しない。各サイトは、この情報の多くを記憶するユーザの独自のプロファイルを有する。ただし、ユーザは、それでも、現在の慣行では、各サイトごとに独立にそのようなプロファイルを作成しなければならないことになる。
【００５７】
本発明は、ヒューリスティックスベースのフィールド認識を含む。この手法では、フィールドラベルが、関与の書式フィールドに対する空間的近接性によって識別される。フィールドラベルと書式フィールドＨＴＭＬ属性（とりわけ、ＨＴＭＬの「入力」要素、「選択」要素、および「処理」要素の「名前」属性）の組合せが、所望のフィールドの識別を助ける辞書を含むヒューリスティックエンジンに対する入力として使用されることになる。
【００５８】
別の実施形態では、本発明は、ユーザ介在フィールド認識を含む。この手法では、ユーザは、ユーザが実行する処理のシーケンスに関する情報をサーバがキャプチャすることを可能にする「Ｒｅｍｅｍｂｅｒ」ボタンまたは同様のコントロールを介して意図的に入力をキャプチャする。ユーザは、これを行う際、その処理を実質的に「再生」することができる（他のソフトウェアシステムで使用されるマクロスクリプト記述と同様に）。このため、ユーザの処理をヒューリスティックエンジンに送り込むことが可能であり、また、このエンジンのプロセスによって使用されるフィールドマッピングテーブルに直接に送り込むことも可能であ
る。
【００５９】
好ましい実施形態では、前述した２つの手法は、この発明を可能にするナビゲーションの可能性および書式フィールド完成の可能性を正確に描写するプロセスマップおよび書式フィールドマップを完全に作成するためには、何らかの手動の対話を必要とする可能性がある。それが必要なとき、人間の分析者が、ユーザ介在フィールド認識中に行われるのと同様の仕方で作業することになる。ただし、分析者は、通常のユーザよりもはるかに多くの情報を自らのナビゲーションプロセスおよび書式記入プロセスに関して提供することになる。すべての場合で、収集された情報は、様々な活動をそれによって行うことができる処理のシーケンス（書式記入、ＨＴＴＰ Ｐｏｓｔ、ＨＴＴＰ Ｇｅｔ等）を描写するプロセスマップ（または詳細なサイトマップ）を作成するのに使用される。また、フィールドマップも、プロセスマップ内のＷｅｂページのそれぞれに対して生成されることになり、このフィールドマップは、書式提出を自動化するのに使用することができるフィールドの正確な名前を定義する。また、ユーザがＷｅｂサイトと対話するなかで、ユーザの状態を追跡するために、状態マップも必要とされる可能性がある（ログオンしている対ログオンしていないなどのユーザの状態により、サイト上における特定の処理の結果が変わることになる）。
【００６０】
好ましい実施形態では、ユーザがそれによって対話するプロセスは、完全に自動化すること（その場合、ユーザは、単に、スクリプト記述された処理を行う要望を伝える）、またはユーザ介在型にすること（その場合、本発明は、ユーザのために書式フィールドを事前記入することができ、これにより、さらなるデータ入力を必要とする任意のフィールドを修正、変更、または完成する機会をユーザに与える）ができる。前述した製品およびサービスに加えて、会社が自体のサイトの訪問者に関する書式データの入力を自動化することを可能にするなどの、新しい製品およびサービスのために、プロセスマップおよびフィールドマップの形態での実施を可能にする技術を活用することができる。例えば、会社が、自体の顧客のためにプロセスマップおよびフィールドマップをまとめた場合（前述した手段のどれかにより）には、この会社は、この情報、サービス、および製品のライセンスをサードパーティの顧客に供与することができる。また、これらのマップが自体に関して存在するサイトも、本発明を使用して、このシステムの恩恵を受けていない自体の顧客に同様のサービスを提供することで、自体のサイトが恩恵を受けるようにすることができる。また、基礎のプロセス自体も、この情報を獲得し、それを例えばＸＭＬやＥＣＭＬとして再フォーマットするシステムを利用することになる。これらの標準の表現は、後述する２つの製品／サービスのための情報交換の基礎を成すことになる。
【００６１】
次に、図９を参照すると、実施例としてのアクティベータプログラムによって実装されるプロセス９００が、アプリケーションを初期化すること（ステップ９０２）と、ユーザがオンラインでブラウズまたはショッピングするなかで、ユニフォームリソースロケータ（ＵＲＬ）を監視すること（ステップ９０４）と、ユーザがサポートされるサイトでブラウズしているかどうかを判定すること（ステップ９０６）と、サポートされるサイトのタイプを判定すること（ステップ９０８および９１２）と、処理ステップ９１０および９１４（それぞれ）で適切に応答することとを適切に含む。その他の機構（クーポン、特別売出し、監視、セキュリティ等）は、ステップ９１６で実装することができる。
【００６２】
初期化ステップ９０２は、アクティベータアプリケーションを開くこと、およびアプリケーションを適切に初期化することに適切に関わる。アクティベータアプリケーションは、システム始動、ネットワーク（インターネットまたはＬＡＮなど）に対する接続、またはブラウザ（ワシントン州、ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、またはカリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＮｅｔｓｃａｐｅ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＮｅｔｓｃａｐｅ Ｅｘｐｌｏｒｅｒなど）の初期化に応答して初期化することができる。様々な実施形態では、アクティベータアプリケーションが、ウォレットサーバ１４０（図１）、ウォレットアプリケーション４０６（図４）、またはネットワーク１０２上の別のサーバに接触することができる。アクティベータアプリケーションは、遠隔サーバに適切に接触して、ウォレットによってサポートされるＷｅｂサイトのリスト、ドメイン名のリスト、またはＵＲＬのリストなどの情報を入手する。この情報は、定期的に（例えば、毎日、毎週、毎月、またはエージェントアプリケーションの初期化のたびに毎回）入手することができ、あるいは、アクティベータアプリケーションまたはサーバによってポーリングされたときに入手することができる。様々な実施形態では、アクティベータアプリケーションは、ローカルドライブ上のキャッシュまたはファイル内に、またはクライアントコンピュータ上のメモリ内に、サポートされるＵＲＬのリストを記憶する。
【００６３】
ユーザがインターネットまたはその他のデータネットワーク１０２上でブラウズするなかで、アクティベータアプリケーションは、そのネットワーク上のユーザの位置を適切に監視する。ユーザのブラウズを監視する一方法は、ユーザのブラウザによって使用されるＵＲＬを監視することである。そのような実施形態では、アクティベータアプリケーションは、ユーザのブラウザから（または、それが適切な場合、システムネットワークインターフェースから）現在のＵＲＬを入手し、初期化ステップ９０２において遠隔サーバから入手したサポートされるＵＲＬのリストに対してその現在のＵＲＬを比較する（ステップ９０６）。この比較を図９で論理的に別々のステップ９０６、９０８、９１２、９１６によって示している。ただし、これらのステップは、本発明の範囲を逸脱することなく、任意の仕方で組み合わせること、または分離することが可能である。例えば、図９は複数回の比較が実行されるのを示しているが、いくつかの実施形態では、サポートされるＵＲＬのリストに対し、各現在のＵＲＬを単一回、比較することで十分である可能性がある。
【００６４】
現在のＵＲＬがサポートされるＵＲＬに該当する場合、アクティベータアプリケーションは適切に応答する。例えば、現在のＵＲＬがサポートされるチェックアウトページである場合（ステップ９０８で「はい」）、アクティベータアプリケーションは、チェックアウトプロセスを実行する（ステップ９１０）。チェックアウトプロセスは、ポップアップメッセージを介して、あるいはシステムトレイ内または浮動ウィンドウ内に特定のアイコンを表示することにより、そのチェックアウトページがサポートされているのをユーザに通知することを含むのが可能である。ウォレットクライアントアプリケーション２１４がもはや開いていない場合、アクティベータアプリケーションは、ユーザにダイアログボックスまたはその他のプロンプトを提示して、そのページがウォレットアプリケーション２１４によってサポートされているのを示すことができる。また、このプロンプトは、ユーザがそれによってウォレットアプリケーション２１４を開くことができるボタンまたはその他の機構を提供することも可能である。
【００６５】
現在のＵＲＬがサポートされる支払いページに該当する場合（ステップ９１２で「はい」）、アクティベータアプリケーションは、ウォレットアプリケーションに支払い命令を提供する、または、別の仕方で、ウォレットアプリケーションに制御を渡すことができる（ステップ９１４）。アクティベータアプリケーション、ウォレットアプリケーション、ブラウザ等の間で送信されるメッセージは、Ｏｐｅｎ Ｄｅｓｋｔｏｐメッセージで、Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ（ＯＬＥ）メッセージで、オブジェクトルーチンコールで、ＯＳコールで、またはそれに類するもので送信することができる。
【００６６】
様々な実施形態では、前述した機能性は、以下に説明するクッキーを使用して実現することができる。クッキーは、有効なユーザコンテキストを検出するのに使用される。有効なユーザコンテキストが検出された場合、アクティベータは、サーバアプリケーションを立ち上げるか、またはユーザが他のアプリケーションを立ち上げるのを可能にするサーバツールバーを立ち上げる。例えば、ユーザのブラウザは、個人支払いまたは特定のカード商品を介して購入を行う能力を意味するいくつかのクッキーを有することが可能である。アクティベータは、ユーザが所望の支払い機器（例えば、個人支払いまたはユーザのデジタルウォレット内のカードから）を選択できるようにするツールバーを立ち上げることができる。利用できる適用例は、必ずしもすべて購入取引に関係していないことが理解されよう。様々な実施形態では、コンテキスト情報は、サーバ上と、ブラウザに関連するクッキー内の両方で記憶される。例えば、クッキーは、コンテキスト情報をそれによってサーバから検索することができるキーとして、働くことが可能である。
【００６７】
また、その他の機能性（ステップ９１６）も、アクティベータアプリケーションに組み込むことができる。例えば、セキュリティ機構（前述したもの、および以下に説明するものなど）、顧客監視機能、クーポン、特別売出し等を実装することが可能である。クーポンまたは特別売出しの場合、アクティベータは、現在のＵＲＬを特定の製品または特定のＷｅｂページに対応するものとして感知することが可能である。ユーザがその特定のサポートされたＵＲＬに「サーフィン」またはブラウズしたとき、アクティベータアプリケーションは、その一致に気付き、特定の商品を購入する機会、または購入で特別割引きを受ける機会などの特別の申し出をユーザに提示する（ダイアログウィンドウを介して、またはブラウザを介して、またはそれに類するものを介して）。本適用例の範囲を逸脱することなく、その他の機能性をアクティベータアプリケーションに組み込むのが可能なことが理解されよう。
【００６８】
本発明の様々な実施形態では、ウォレットクライアント２１４（図２）が、特定のユーザ／顧客に固有の情報で事前記入される。図１を参照すると、ユーザは、ネットワーク１０２上のウォレットサーバ１４０などのＷｅｂサーバに接触することによってデジタルウォレットの申し込みを行うことができる。ユーザは、登録書式（例えば、ＣＧＩスクリプトで生成することが可能な）を完成させてウォレットの申し込みを行う。ウォレットサーバ１４０は、認証サーバ３０６（図３）または私設ネットワーク上の別のサーバから人口統計情報、口座情報、およびその他の情報（例えば、アドレス、発送アドレス、名前、クレジットカード番号等）を適切に受信する。この情報を使用して、特定のユーザに固有のウォレットクライアント２１４（図２）を構成することができる。ウォレットクライアント２１４を構成する一方法は、クライアント２１４と関連し、クライアント２１４によって読み取られる構成ファイルを作成して、前述したとおり、ウォレット情報を獲得することである。
【００６９】
好ましくは、登録情報は、カードリーダポートがシリアルポートでなければならないか、またはＵＳＢポートでなければならないかを含むカードリーダ情報も含む。ウォレット申し込みが承認された場合、カードリーダをユーザに発送する、または別の仕方でユーザに提供することが可能であり、特別コード（暗号キー、またはパスワード、または他の任意の種類の電子コードまたは印刷されたコード）もユーザに提供される。次に、ユーザは、ウォレットサーバ１４０と電子的に接触をとり、カードおよび／または特別コードを使用してサーバに対する認証を行うことによってオンラインウォレットサービスに登録する。特別コードを提供した後、ユーザは、特別に構成したコピーのウォレットソフトウェアを受け取り、これを適切に顧客コンピュータ１１０にインストールすることができる。ウォレットプログラムのバージョンを単に特別コードと関連付けることにより、ウォレット事前記入手続きを任意のクレジットカードまたは任意の課金カードで使用することができる。特定のユーザに関する構成情報が、ユーザに提供されるコードと関連付けられ、後に、このユーザは、その特別コードを提示してウォレットサーバ１４０に対して自らの認証を行い、特定のユーザに固有のデータで既に事前構成されているウォレットのコピーを入手することができる。
【００７０】
次に、図１および図１０を主に参照すると、顧客１１０は、スマートカード２０２を使用してウォレットサーバ１４０にログインすることにより、取引を適切に開始する。ウォレットサーバ１４０にログインするためには、顧客１１０は、まず、ブラウザ２１６を介してセキュリティサーバ１３０に接続することができる。ユーザは、ブックマーク、インターネットショートカット、ハイパーリンク、または他の任意の適切な技法を介してログインページのための特定のユニフォームリソースロケータ（ＵＲＬ）を選択する。次に、セキュリティサーバ１３０が、ネットワークインターフェース３０２を介してログインページを戻すことが可能である。様々な実施形態では、ユーザ／パスワードログインのための書式入力および提出ボタン、ならびにスマートカードログインのためのハイパーテキストリンクが、ログインページの一部として提供される。ユーザが、スマートカードログインを選択し、ブラウザ２１６が、ログオン要求メッセージ１００２（図１０）を転送することによって適切に応答する。セキュリティサーバ１３０が、ログオン要求１００２を受信して、適切にスマートカードログオンプロセスを開始する。様々な実施形態では、セキュリティサーバ１３０は、ログオン要求メッセージ１００２に応答して、認証サーバ３０６またはセキュリティエンジン３０４による暗号課題をフォーマットする。暗号課題１００４は、ランダムデータに基づき、スマートカード２０２上に記憶されたＸ．５０９アプリケーションから応答を求めるように設計された課題などの、再生攻撃（例えば、前に送信された認証パケットを再送信することによって作成された不正なメッセージ）を防止する任意の種類の課題メッセージである。次に、この課題が、課題メッセージ１００４として、ネットワーク１０２を介して顧客１１０に適切に提供される。
【００７１】
課題メッセージ１００４を受信すると、ブラウザ２１６は、スマートカード２０２を使用する処理のために、メッセージ１００４をウォレットクライアント２１４に適切に渡す。ウォレットクライアント２１４が動作していない場合、ブラウザ２１６は、そのプログラムを自動的に開くことができる。次に、ウォレットクライアント２１４が、適切に署名応答を準備する。例えば、ウォレットクライアント２１４は、サーバ課題情報を抽出し、新しいクライアント課題（すなわち、スマートカード２０２に対する第２の暗号課題）をフォーマットし、両方の課題を二重課題に結合し、例えば、公開キー暗号システム１（ＰＫＣＳ１）暗号ブロック内で、後の使用のためにこの二重課題のハッシュを計算することができる。ハッシュは、例えば、ＭＤ３やＭＤ４などの任意のアルゴリズムに従って計算することができ、二重課題ブロック内のデータの完全性と正確さを保証するために適切に使用される。ＰＫＣＳ１は、ＲＳＡ公開キークリプトシステムを使用してデータを暗号化し、それに署名するための機構を定義する公開キー暗号法の標準である。ＰＫＣＳ標準は、１９９８年９月付けの、参照によって本明細書にその全体が組み込まれるＰＫＣＳ ＃１： ＲＳＡ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ Ｖｅｒｓｉｏｎ ２．０（ｈｔｔｐ：／／ｗｗｗ．ｒｓａ．ｃｏｍ／ｒｓａｌａｂｓ／ｐｕｂｓ／ＰＫＣＳ／ｈｔｍｌ／ｐｋｃｓ−１．ｈｔｍｌからオンラインで入手可能である）で、十分に定義されている。
【００７２】
ＰＫＣＳ１ブロックは、処理のために、リーダ２０４を介してスマートカード２０２に適切に提供される（図１０のステップ１００６）。様々な実施形態では、カードリーダ２０４が顧客コンピュータ１１０と対話し、カードにアクセスするための個人識別子、例えば、個人識別番号（ＰＩＮ）または他の固有識別子を求めて、ユーザにプロンプト指示を出す。好ましい実施形態では、ＰＩＮは、スマートカード２０２上に記憶される。別法では、ＰＩＮまたはその他の個人識別子は、システム上の別のどこかに、例えば、リーダ２０４上または顧客コンピュータ１１０上に記憶することができる。ユーザは、それが適切な場合、スマートカード２０２をロック解除するために個人識別子を適切に入力し、スマートカードは、ウォレットクライアント２１４から二重課題ブロックを受け取り、そのブロックに適切にデジタル方式で署名する。様々な実施形態では、スマートカード２０２は、ブロックのデジタル署名を計算するのに使用する秘密キーを含む。次に、署名されたブロックが、適切に、ウォレットクライアント２１４に戻される。様々な実施形態では、スマートカード２０２は、デジタル署名を計算するのに使用する秘密キーに該当する証明書（Ｘ．５０９証明書など）も提供する。
【００７３】
スマートカード２０２から署名および証明書を受信した後、ウォレットクライアント２１４は、セキュリティサーバ１３０に送信されるべき適切な応答メッセージ１００８を適切に作成する。応答メッセージ１００８は任意の形式であることが可能であるが、様々な実施形態は、１９９３年１１月１日に改定され、ｆｔｐ：／／ｆｔｐ．ｒｓａ．ｃｏｍ／ｐｕｂ／ｐｋｃｓ／ｄｏｃ／ｐｋｃｓ−７．ｄｏｃからオンラインで入手可能であり、参照によって本明細書にその全体が組み込まれるＰＫＣＳ ＃７： Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｍｅｓｓａｇｅ Ｓｙｎｔａｘ Ｓｔａｎｄａｒｄ， Ａｎ ＲＳＡ Ｌａｂｏｒａｔｏｒｉｅｓ Ｔｅｃｈｎｉｃａｌ Ｎｏｔｅ、Ｖｅｒｓｉｏｎ １．５に定義されるＰＫＣＳ７メッセージとして応答メッセージ１００８をフォーマットする。
【００７４】
応答メッセージ１００８を受信した後、セキュリティサーバ１３０は、適切にメッセージを処理する（図１０のステップ１０１０）。様々な実施形態では、応答メッセージ１００８は認証サーバ３０６に経路指定され、この認証サーバが、スマートカード２０２によって提供される証明書および署名を検証する。証明書がうまく検証され、かつ署名の妥当性検査がうまく行われた後、様々な実施形態では、セキュリティトークンが生成されて、顧客１１０またはスマートカード２０２に戻されることが可能である。
【００７５】
このようにして、セキュリティトークンの後の提示により、ユーザが身元を確認し、ウォレットサーバとセキュアな仕方で対話するための手段が提供される。様々な実施形態では、認証サーバ３０６は、ユーザを識別する追加のセキュリティトークンを作成することも可能である。様々な実施形態では、このトークンは、複数の部分から構成されることが可能であり、これらの部分が、次に、場合によっては、データベース３１０内のデータを利用して、適切なデジタル証明書、スマートカード、またはその他のデータにマッピングされる。様々な実施形態では、追加のセキュリティトークンおよび／またはその中の部分は、リダイレクトメッセージ１０１２と併せて顧客１１０に提供することができる。様々な実施形態では、追加のセキュリティトークンは、顧客に提供すること、または認証サーバ３０６上で保持することが可能である。
【００７６】
リダイレクトメッセージ１０１２を受信すると、顧客１１０は、ウォレットサーバ１４０に適切に接触して、接続を要求する。様々な実施形態では、「接続要求」メッセージ１０１４は、適切には、セキュリティトークンを含み、場合によっては、リダイレクトメッセージ１０１２の一部として追加のセキュリティトークン全体またはその一部も含む。ウォレットサーバ１４０は、セキュリティトークンの何らかの組合せの全体またはその一部を使用してセキュリティサーバ１３０に対して照会を行い、顧客１１０の識別を入手する。照会１０１６および応答１０１８は、ネットワーク１５０を介して適切に伝送され、このネットワークは、いくつかの実施形態では、ネットワーク１０２とは独立に維持されて、システム１００のセキュリティを高めている。代替の実施形態は、いくつかの実施形態では、仮想プライベートネットワーク、ＳＳＬプロトコル、共有の秘密の使用、および／またはその他の暗号手段によるより高いセキュリティを提供するネットワーク１０２を使用する。リターン信用証明１０１８が整っている場合、ウォレットサーバ１４０が、ウォレットデータベース４０８から顧客１１０に対応する属性を検索し、メッセージ１０２０を介してログインが成功したことを顧客１１０に通知する。ログオンシーケンスの代替の実施形態も可能であることが理解されよう。また、ログインシーケンス１０００を実装するために、任意の種類の暗号化スキーム、メッセージ形式等を使用するのが可能なことも理解されよう。
【００７７】
次に、図１１を参照すると、購入取引中の使用に適した実施例としての認証フロー１１００が、認証がそのために必要とされるイベント（購入など）に関して、顧客１１０がウォレットサーバ１４０に要求１１０２を出すことで開始する。ウォレットサーバ１４０は、そのイベントを適切に認識し、例えば、通信チャネル１５０を介してセキュリティサーバ１３０に要求メッセージ１１０４をサブミットして課題メッセージをフォーマットする。次に、認証サーバ３０６（または、それが適切な場合、セキュリティサーバ１３０の何らかの他の構成要素）が、課題メッセージ１１０６（これはランダムデータを含むことが可能である）をフォーマットして、その課題メッセージ１１０６をウォレットサーバ１４０に、例えば、接続１５０を介して提供する。ウォレットサーバ１４０は、課題メッセージ１１０６を受信し、その課題データを署名要求メッセージ１１０８としてブラウザ２１６に転送する。ブラウザ２１６は、それが必要な場合、ウォレットクライアント２１４を開き、署名要求メッセージ１１０８を転送する。前述したとおり、ウォレットクライアント２１４は、サーバ課題、クライアント課題、およびハッシュを含むＰＫＣＳ１ブロックなどの署名要求ブロックをフォーマットする。結果の署名要求ブロックが、リーダ２０４を介してスマートカード２０２に提供される。スマートカード２０２は、そのブロックに適切に署名して、適切なように、そのＸ．５０９証明書のコピーを提供する。
【００７８】
次に、署名されたブロックがウォレットクライアント２１４に戻されることが可能であり、ウォレットクライアントは、適切な署名応答メッセージ１１１０（ＰＫＣＳ７メッセージなど）を適切にフォーマットして、それをウォレットサーバ１４０に送信する。次に、ウォレットサーバ１４０が、妥当性検査メッセージ１１１２を構成し、このメッセージは、署名応答メッセージ１１１０からのデータ、ならびにログオンプロセス（図１０に示す実施例としてのログオンプロセスなど）中に顧客１１０と関連するセキュリティトークンを含む。代替の実施形態では、提供されたセキュリティトークンが、顧客１１０から署名応答メッセージ１１１０の一部として受信される。妥当性検査メッセージ１１１２が、適切に、接続１５０を介してセキュリティサーバ１３０に送信される。セキュリティサーバ１３０が、次に、妥当性検査メッセージを認証サーバ３０６に適切に経路指定して、この認証サーバが、その署名を検査し、データベース３１０から適切なセキュリティトークンを検索することができる（図１１のステップ１１１４）。データベースから検索されたセキュリティトークンおよび／またはオプションの固有識別コードが、ウォレットサーバ１４０から受信されたセキュリティトークンまたはＩＤと比較される。２つのオブジェクト（例えば、セキュリティトークンまたはＩＤ）が一致する場合、顧客１１０によって現在、使用されているカードが、顧客１１０によってログオン時に使用されたカードと同じであることを推論することができる。次に、適切な承認または否認のメッセージ１１１６が、セキュリティサーバ１３０からウォレットサーバ１４０に送信され、取引を進めることが許される。
【００７９】
様々な実施形態では、ウォレットサーバ１４０は、取引中、顧客１１０のためのプロキシの役割をする。例えば、ウォレットサーバ１４０は、購入者１１０のために、発送アドレス、カード番号等を含む購入書式を完成させることができる。次に、商店１２０が、その購入取引を従来のハードウェアおよびソフトウェアを使用して標準の課金カード取引として許可することができる。ただし、本明細書に開示するシステムによって提供されるさらなるセキュリティにより、購入者の身元におけるさらなる信頼性が可能となり、これにより、その取引に関するより低い割引率が妥当となる。
【００８０】
本発明の様々な実施形態は、セキュリティ違犯からのさらなる保護を組み込む。例えば、セキュリティサーバ１３０またはウォレットサーバ１４０に組み込まれた多くのサーバ側機能が、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ（カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓによって定義される）またはＶＢｓｃｒｉｐｔ（ワシントン州、ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって定義される）などのスクリプト記述言語で書かれた様々なスクリプト記述構成要素を組み込むことが可能であり、ネットワーク１０２に結合されたサーバが、サーバからクライアントにスクリプト（またはコード）を提供することにより、そのようなサーバ言語を介して複数のクライアント１１０に様々な機能性を提供することが可能である。このコードは、クライアントコンピュータ１１０によって解釈され、コンパイルされ、または別の仕方で実行される。例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔを組み込んだ実施形態では、クライアントコンピュータ１１０上で動作するブラウザプログラム（例えば、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｏｒ、またはそれに類するもの）によってスクリプトが解釈され、実行される。その他の実施形態は、他の非ＰＣのブラウザ、例えば、ワイヤレスマークアップ言語（ＷＭＬ）スクリプトをサポートするワイヤレスアプリケーションプロトコル（ＷＡＰ）電話機を含む。様々なスクリプト記述言語は、例えば、ユーザのハードドライブ上のファイルにアクセスするため、または別の仕方でユーザのコンピュータ上のデータを操作するための命令、オブジェクト、またはその他のデータ機構を含んでいることが可能である。許可のないソースがユーザに実行可能コードを提供するのを防止するため、スクリプト記述言語は、信用されるソースから提供されたスクリプトだけをユーザが許可するのを可能にするための機構を含むことができる。例えば、前述したとおり、電子取引を行うユーザは、ウォレットサーバから提供されたスクリプトが実行されるのを許すが、その他のソースから提供されたその他のスクリプトがユーザのコンピュータ上で実行されるのを防止することが可能である。
【００８１】
多くのスクリプト記述言語で遭遇する可能性のあるセキュリティ問題を図１２Ａに示している。非良心的な「クラッカー」が、正規のＷｅｂサーバ１２０６のユーザに対して、悪意のある活動を行うように設計されたＷｅｂサイト１２０４を作成する可能性がある。クラッカーサイト１２０４（図では「犯罪的サイト」として示す）は、例えば、スクリプトなどの、コードの一部分をユーザに提供することが可能である。また、犯罪的サイト１２０４は、正規のサーバ１２０６（ウォレットサーバ１４０、またはネットワーク１０２上における他の任意のサーバ）において特定のユニフォームリソースロケータ（ＵＲＬ）を要求するようにユーザのＷｅｂブラウザ２１６を誘導することが可能である。参照されるＵＲＬは、正規のサーバ１２０６が、例えば、クライアントブラウザ２１６にエラーメッセージまたはその他の応答を戻すように、意図的に作られていることが可能である。様々な実施形態では、正規のサーバ１２０６からの応答は、ユーザのＷｅｂブラウザ２１６からの要求の一部分またはその変形を自動的に含むことが可能である。その応答が、犯罪的サイト１２０４の悪意のある意図の結果、生成されたＪａｖａ（登録商標）Ｓｃｒｉｐｔ、ＶＢｓｃｒｉｐｔ、またはその他のコードを含む場合には、そのコードがユーザのコンピュータ上で実行される可能性がある。この例は、「クラッカー」が、それにより、正規のＷｅｂサーバ１２０６を誘導して悪意のある命令をユーザのＷｅｂブラウザ２１６に送信することのできる多くの技法の１つを例示するものである。様々なコーディング言語およびスクリプト記述言語が、ホストコンピュータのファイルシステム、レジストリ、またはそれに類するものにアクセスするための命令を含んでいるので、そのようなコードの許可のない実行は、極めて望ましくないことが理解されよう。それでも、図１２Ａに示す技法により、犯罪的サイト１２０４からのスクリプト記述またはその他のコードがユーザのコンピュータに提供されることが可能である。ユーザのコンピュータは、そのスクリプト記述が信用されるソース（すなわち、ウォ
レットサーバ）から来たと考えるので、クライアントのコンピュータが犯罪的サイトからのそのコードを実行する可能性があり、これにより、損害、許可のないデータの配布または破壊、またはそれに類するものの可能性が生じることになる。図１２Ｂは、行われるべき正しい通信フローを示している（図１２Ａに示す犯罪的攻撃のフローと対比される）。
【００８２】
この潜在的なセキュリティ問題を防止するため、本発明の様々な実施形態は、不要の実行可能コードを削減または除去するための技法を適切に含む。図１３を参照すると、スクリプト攻撃の可能性を減らすためのプロセス１３００が、高い許可を有するサーバの部分を制限するステップ（ステップ１３０２）と、サイトのその部分内の危険な文字を除去するステップ（ステップ１３０４）と、それが必要な場合、ある文字をエンコードするステップ（ステップ１３０６）と、オプションとして、Ｗｅｂサイトの関係のある部分からユーザに提供されるデータをログ記録するステップ（ステップ１３０８）を適切に含む。
【００８３】
ステップ１３０２に関して、Ｗｅｂサイトは、通常、様々なページを含み、各ページは固有のＵＲＬを有している。サイトのユーザは、あるサーバ（評判のよい金融機関または商店に対応するサーバなど）に高い信用を置くことが可能である。高い信用をそのＷｅｂサイトの一部分（例えば、信用されるＷｅｂサイトに対応するＵＲＬの限られたサブセット）だけに限定することにより、そのサイトの残りの部分に与える信用のレベルが適切に下げられ、セキュリティが高められる。信用は、例えば、サイトの一部分だけを信用するようにユーザのＷｅｂブラウザを構成することにより、そのサイトの限られた部分に限定することができる。ユーザのＷｅｂブラウザは、手動で構成すること、または、例えば、ウォレットサーバによって提供される構成スクリプトによって構成することが可能である。Ｗｅｂサイトのあるページ（例えば、一部分）だけが、高い信用で使用可能にされているとき、その他のページに関連して含まれるどのスクリプトも、実行されないか、または高い信用では実行されないことになる。
【００８４】
サーバのある部分だけをクライアントが「信用」するようにクライアントを構成することに加えて（または、その代替として）、クライアント−サーバ対話のセキュリティを高めるようにサーバを構成することができる。例えば、セキュリティを高めるためにサーバ上の大部分において高い信用のスクリプト記述を許さないことが可能である。さらに、Ｗｅｂサイトの信用される部分に提供されるデータを、ユーザに戻される前に、監視すること、および／または変更することが可能である（ステップ１３０４および１３０６）。ほとんどのスクリプト記述言語は、コマンドをフォーマットするためにある文字を必要とする。例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ言語は、しばしば、スクリプト命令が山形括弧（「＜」と「＞」）内に入れられてエンコードされる。したがって、Ｗｅｂサイトの信用される部分から戻されることになるどの内容からも、山形括弧を除去することが可能である。例えば、Ｗｅｂサイトの信用される部分から提供されたＷｅｂページが、山形括弧を使用しようと試みる「犯罪的」Ｊａｖａ（登録商標）Ｓｃｒｉｐｔプログラムを含むことがあれば、そのスクリプト命令は、ユーザのコンピュータ上で実行されないことになる。というのは、山形括弧が除去された後には、スクリプト命令が適切にフォーマットされていないことになるからである。別法では、ある「危険な」文字（Ｊａｖａ（登録商標）Ｓｃｒｉｐｔにおける山形括弧など）を別の形式で、例えば、アンパサンド（「＆」）、およびその特定の文字に関する情報交換用米国標準コード（ＡＳＣＩＩ）値を有する「アンパサンド表記」で戻すこと、あるいは「危険な」文字を「スペース」文字などの安全な文字で置換することによって戻すことが可能である（ステップ１３０６）。利用されることが可能な特定の言語、スクリプト記述環境等に応じて、本発明の様々な実施形態において、どの文字でも除去またはエンコードすることが可能であることが理解されよう。
【００８５】
様々な実施形態では、オプションのステップ１３０８は、Ｗｅｂサイトの様々な部分によって提供される情報のデータログを維持することを適切に含む。文字がそこでエンコードまたは除去されたすべての内容をログ記録し、そのログを検査して、ネットワーククライアントを危険にさらすようにＷｅｂサイトが使用されているかを判定できるようにすることが可能である。例えば、Ｗｅｂページから提供されるすべての内容、その信用される部分内から提供されるすべての内容、スクリプト記述／プログラミング内容を有するすべての内容、信用される部分の外部からのすべての内容、またはＷｅｂサイト内容の他の任意の部分を１つまたは複数のデータファイルにログ記録することが可能である。データファイルを適切に探索して、または別の仕方で調べて、サーバによってユーザに許可のない内容を提供しようとする試みが存在したかどうかを判定することができる。
【００８６】
いくつかの場合、監査証跡（例えば、ログ）ファイル内に内容をログ記録することができるネットワークサーバにスクリプトを含む内容を送信する「犯罪的」サイトにより、内部マシンが攻撃されることが可能である。サーバ上に常駐するファイルに関してブラウザが高い信用に構成されている可能性があるので、様々な実施形態では、ユーザがブラウザを使用してＷｅｂサーバおよびその他のｅコマースサーバの監査証跡ファイルを検査するとき、監査証跡記録を送達したネットワークサーバの信用レベルで（例えば、高い信用レベルで）スクリプトがネットワーククライアント上において実行される可能性がある。このスクリプトの実行は、そのスクリプトがネットワークサーバに送信されてずっと後になってから行われることが可能な攻撃を引き起こす可能性がある。この攻撃は、前述した「犯罪的」攻撃のような、クロスサイトスクリプト記述を防止する前述したのと同じ方法および手続きを使用して防止することが可能である。Ｗｅｂサーバなどのネットワークサーバ上で動作する、またはＰＣブラウザなどのネットワーククライアント上で動作する、図１３に記載したもののようなフィルタが、スクリプト制御文字に関するフィルタリングを行ってその文字をエンコードする、その文字を拒否する、またはその記録全体を拒否することができる。
【００８７】
頭記の特許請求の範囲におけるすべての要素に対応する構造、資材、処理、および等価のものには、具体的に請求するその他の請求する要素と組み合わせた機能を行うための任意の構造、資材、または処理が含まれるものとする。本発明の範囲は、以上に提示した実施例によってではなく、許可された特許請求の範囲およびそれと法的等価のものによって決定されなければならない。
【特許請求の範囲】
【請求項１】
データネットワーク上でユーザコンピュータを操作するユーザによって要求された金銭上の取引を円滑にするための取引システムであって、
コンピュータベースのシステムで実行される取引オーソライザと、
有形のインテリジェントトークンと物理的にインターフェース接続するように構成された有形のデバイスと有形のメモリとを備えたリーダと、
前記リーダと電子的に通信するクライアント取引ツールであって、前記有形のインテリジェントトークンの認証および存在を検証するように構成された、クライアント取引ツールと、
有形のインテリジェントトークンが前記ユーザの所有の下にあることを検証し、かつ前記検証が成功した場合、前記データネットワークを介して前記ユーザコンピュータにデジタル信用証明を電子的に提供するように構成され、前記データネットワークと通信する有形のメモリとコンピュータプロセッサとを備えたセキュリティサーバと、
を含み、
前記取引オーソライザが、前記データネットワークを介して前記ユーザコンピュータによって提供される前記デジタル信用証明に少なくとも部分的に基づいて、前記ユーザによって要求される取引を許可するように構成されているシステム。
【請求項２】
前記データネットワークと通信する有形のメモリとコンピュータプロセッサとを備えた取引ツールサーバをさらに含む、請求項１に記載の取引システム。
【請求項３】
前記デジタルネットワークを介して前記ユーザコンピュータと通信し、前記データネットワークと通信する有形のメモリとコンピュータプロセッサとを備えるウォレットサーバをさらに含む、請求項１に記載の取引システム。
【請求項４】
前記ウォレットサーバが、前記データネットワークによって前記ユーザコンピュータからの取引の要求を受信し、商店コンピュータシステムと接触を行い、かつ前記商店コンピュータシステムに前記ユーザに関する情報を提供するように構成されている、請求項３に記載の取引システム。
【請求項５】
前記リーダが、前記取引ツールと前記インテリジェントトークンとの間で情報を転送するように構成されている、請求項１または４に記載の取引システム。
【請求項６】
前記クライアント取引ツールがウォレットクライアントである、請求項１に記載の取引システム。
【請求項７】
有形のインテリジェントトークンがスマートカードである、請求項１に記載の取引システム。
【請求項８】
前記セキュリティサーバと前記取引オーソライザコンピュータの間の接続が、前記データネットワークとは独立のデータ接続を介する、請求項１に記載の取引システム。
【請求項９】
前記クライアント取引ツールが、前記データネットワークとは独立のデータ接続を介して前記セキュリティサーバと通信する、請求項１に記載の取引システム。
【請求項１０】
有形のインテリジェントトークンが、該有形のインテリジェントトークンと関連するユーザを一意的に識別するデジタル証明書を含む、請求項１に記載の取引システム。
【請求項１１】
前記有形のインテリジェントトークンのユーザが、英数字の文字を含む個人識別子の使用によってデジタル証明書に対するアクセスを得る、請求項１０に記載の取引システム。
【請求項１２】
有形のインテリジェントトークンが発行者によって発行され、かつ前記取引システムを使用して行われる取引が、前記有形のインテリジェントトークンの前記発行者によって考えられるところの「カード存在」取引と見なされる、請求項１に記載の取引システム。
【請求項１３】
サービスに対するアクセスを円滑にするためのコンピュータ実装された方法であって、
有形のメモリ及びコンピュータプロセッサを包含するサーバで、ユーザから電子的にログオン要求を受信することと、
前記ユーザが、有形のインテリジェントトークンと物理的にインターフェース接続するように構成された有形のデバイスと有形のメモリとを備えたリーダから認証信号を受信することにより、有形のインテリジェントトークンを所有していることを、前記サーバによって検証することと、
前記検証がうまく行われた場合、前記ユーザに電子的な信用証明を提供することと、
前記サーバで、ユーザから取引要求を受信するステップであって、前記取引要求が前記電子的な信用証明の少なくとも一部分を含むことと、
前記電子的な信用証明の前記少なくとも一部分を処理して前記サービスに対するアクセスを提供することと
を含む方法。
【請求項１４】
前記検証ステップが課題−応答を含む、請求項１３に記載の方法。
【請求項１５】
前記課題−応答が、前記トークンに提供されたランダムデータを含む、請求項１４に記載の方法。
【請求項１６】
前記課題−応答が前記ランダムデータのデジタル署名をさらに含む、請求項１５に記載の方法。
【請求項１７】
前記サービスが金銭上の取引である、請求項１３から１６のいずれかに記載の方法。
【請求項１】
データネットワーク上でユーザコンピュータを操作するユーザによって要求された金銭上の取引を円滑にするための取引システムであって、
コンピュータベースのシステムで実行される取引オーソライザと、
有形のインテリジェントトークンと物理的にインターフェース接続するように構成された有形のデバイスと有形のメモリとを備えたリーダと、
前記リーダと電子的に通信するクライアント取引ツールであって、前記有形のインテリジェントトークンの認証および存在を検証するように構成された、クライアント取引ツールと、
有形のインテリジェントトークンが前記ユーザの所有の下にあることを検証し、かつ前記検証が成功した場合、前記データネットワークを介して前記ユーザコンピュータにデジタル信用証明を電子的に提供するように構成され、前記データネットワークと通信する有形のメモリとコンピュータプロセッサとを備えたセキュリティサーバと、
を含み、
前記取引オーソライザが、前記データネットワークを介して前記ユーザコンピュータによって提供される前記デジタル信用証明に少なくとも部分的に基づいて、前記ユーザによって要求される取引を許可するように構成されているシステム。
【請求項２】
前記データネットワークと通信する有形のメモリとコンピュータプロセッサとを備えた取引ツールサーバをさらに含む、請求項１に記載の取引システム。
【請求項３】
前記デジタルネットワークを介して前記ユーザコンピュータと通信し、前記データネットワークと通信する有形のメモリとコンピュータプロセッサとを備えるウォレットサーバをさらに含む、請求項１に記載の取引システム。
【請求項４】
前記ウォレットサーバが、前記データネットワークによって前記ユーザコンピュータからの取引の要求を受信し、商店コンピュータシステムと接触を行い、かつ前記商店コンピュータシステムに前記ユーザに関する情報を提供するように構成されている、請求項３に記載の取引システム。
【請求項５】
前記リーダが、前記取引ツールと前記インテリジェントトークンとの間で情報を転送するように構成されている、請求項１または４に記載の取引システム。
【請求項６】
前記クライアント取引ツールがウォレットクライアントである、請求項１に記載の取引システム。
【請求項７】
有形のインテリジェントトークンがスマートカードである、請求項１に記載の取引システム。
【請求項８】
前記セキュリティサーバと前記取引オーソライザコンピュータの間の接続が、前記データネットワークとは独立のデータ接続を介する、請求項１に記載の取引システム。
【請求項９】
前記クライアント取引ツールが、前記データネットワークとは独立のデータ接続を介して前記セキュリティサーバと通信する、請求項１に記載の取引システム。
【請求項１０】
有形のインテリジェントトークンが、該有形のインテリジェントトークンと関連するユーザを一意的に識別するデジタル証明書を含む、請求項１に記載の取引システム。
【請求項１１】
前記有形のインテリジェントトークンのユーザが、英数字の文字を含む個人識別子の使用によってデジタル証明書に対するアクセスを得る、請求項１０に記載の取引システム。
【請求項１２】
有形のインテリジェントトークンが発行者によって発行され、かつ前記取引システムを使用して行われる取引が、前記有形のインテリジェントトークンの前記発行者によって考えられるところの「カード存在」取引と見なされる、請求項１に記載の取引システム。
【請求項１３】
サービスに対するアクセスを円滑にするためのコンピュータ実装された方法であって、
有形のメモリ及びコンピュータプロセッサを包含するサーバで、ユーザから電子的にログオン要求を受信することと、
前記ユーザが、有形のインテリジェントトークンと物理的にインターフェース接続するように構成された有形のデバイスと有形のメモリとを備えたリーダから認証信号を受信することにより、有形のインテリジェントトークンを所有していることを、前記サーバによって検証することと、
前記検証がうまく行われた場合、前記ユーザに電子的な信用証明を提供することと、
前記サーバで、ユーザから取引要求を受信するステップであって、前記取引要求が前記電子的な信用証明の少なくとも一部分を含むことと、
前記電子的な信用証明の前記少なくとも一部分を処理して前記サービスに対するアクセスを提供することと
を含む方法。
【請求項１４】
前記検証ステップが課題−応答を含む、請求項１３に記載の方法。
【請求項１５】
前記課題−応答が、前記トークンに提供されたランダムデータを含む、請求項１４に記載の方法。
【請求項１６】
前記課題−応答が前記ランダムデータのデジタル署名をさらに含む、請求項１５に記載の方法。
【請求項１７】
前記サービスが金銭上の取引である、請求項１３から１６のいずれかに記載の方法。
【図１Ａ】
【図１Ｂ】
【図１Ｃ】
【図２】
【図３】
【図４】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図５】
【図６】
【図７】
【図８】
【図１Ｂ】
【図１Ｃ】
【図２】
【図３】
【図４】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１１−６０２９１（Ｐ２０１１−６０２９１Ａ）
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−２０２９３０（Ｐ２０１０−２０２９３０）
【出願日】平成２２年９月１０日（２０１０．９．１０）
【分割の表示】特願２００１−５２０３７０（Ｐ２００１−５２０３７０）の分割
【原出願日】平成１２年８月３０日（２０００．８．３０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
２．ＧＳＭ
【出願人】（５０２０７３２５６）アメリカン エクスプレス トラベル リレイテッド サービシーズ カンパニー， インコーポレイテッド (23)
【Ｆターム（参考）】
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願番号】特願２０１０−２０２９３０（Ｐ２０１０−２０２９３０）
【出願日】平成２２年９月１０日（２０１０．９．１０）
【分割の表示】特願２００１−５２０３７０（Ｐ２００１−５２０３７０）の分割
【原出願日】平成１２年８月３０日（２０００．８．３０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
２．ＧＳＭ
【出願人】（５０２０７３２５６）アメリカン エクスプレス トラベル リレイテッド サービシーズ カンパニー， インコーポレイテッド (23)
【Ｆターム（参考）】
[ Back to top ]