JP4571712B2 - 分散ネットワークを通じた商取引システムのための方法及びそのためのコンピュータ読み取り可能記憶媒体 - Google Patents

Description

優先権
本願は、“SYSTEM AND METHOD FOR CONDUCTING COMMERCE OVER A DISTRIBUTED NETWORK”（分散ネットワークを通じた商取引システムおよび方法）と題し、１９９６年６月２８日に郵送した予備特許出願第６０／０２０，８９１号からの優先権を主張する。
発明の概要
発明の分野
本発明は、インターネットのような分散コンピュータ・ネットワークに関する。更に特定すれば、本発明は、分散ネットワークを通じて商人からの商品やサービスの購入を消費者に可能にする、クライアント−サーバ・コンポーネントに関するものである。
関連技術の説明
現在電子ショッピング・システムが出現し、インターネットのような分散コンピュータ・ネットワークを通じて遠隔地から多種多様のオンライン商人（on-line merchant）からの商品やサービスの購入を消費者に可能としている。この種のシステムでは、オンライン商人は典型的にオンライン・カタログを発行する。ネットワークのエンド・ユーザは、パーソナル・コンピュータを用いて、このオンライン・カタログを双方向的に見ることができる。これらのカタログは、各商人の製品および／またはサービスに関する画像、文章による説明、および価格情報を含み、典型的に、ユーザが購入の注文をネットワークを通じて当該商人に返送できるように、オンライン書式を含む。ワールド・ワイド・ウエブ（「ウエブ」）を基本とする実現例では、オンライン・カタログは、ハイパーテキスト文書の形態となっており、各商人のウエブ・サイトがホストとなっている。カタログにアクセスするには、ユーザのコンピュータ上で走る標準的なウエブ・ブラウザ・アプリケーションを用いる。（ウエブ・サイトとは、インターネットに接続したコンピュータまたはコンピュータ・システムのことであり、ワールド・ワイド・ウエブの標準プロトコルを用いて情報提供するサーバ・ソフトウエアを走らせる。）他の実現例では、オンライン・カタログは、例えば、ＭＳＮサービス・ネットワークのようなオンライン・サービス・ネットワークの集中型コンピュータ、またはある企業に固有のクライアント・アプリケーション（eShop Inc.（イーショップ社）のクライアント・アプリケーション等）がホストとなる場合がある。
発明の概要
現存のコンピュータを用いたショッピング・システムには、ユーザが選択的に製品情報（および種々の形式の「買い物状態」情報）を記憶しておき、後に呼び出して使用できるようにしたものがある。これによって、ユーザは、以前に商人サイトを訪問した際に見た情報を素早く取り出し、以前にユーザが中止した買い物セッションを本質的に継続することが可能となる。しかしながら、これらのシステムは、一般にサーバ側の製品情報（例えば、商人ウエブ・サイトの情報）のみを記憶するものであって、ユーザが消費者コンピュータ上に選択的に製品情報を記憶できるようにするために必要なクライアント・サーバ・ソフトウエア・コンポーネントを含んでいない。この既存のコンピュータを用いたショッピング・システムでは、ソフトウエア・アーキテクチャにおける欠陥のために、消費者にはいくつかの制約が強いられる。第１に、消費者は、多数の商人から共通のローカル記憶エリアに製品情報を収集することが困難である。このために、買い物の比較が非常に困難となる。即ち、消費者は、かなりの不便さなくしては、異なるオンライン商品からの類似した製品（またはサービス）を比較することができない。第２に、情報は、ある限定時間期間（典型的に数日）だけ商人サイトに保持してあることが多いので、消費者は、記憶した製品情報を利用する際、時間的な制約下にある。更に、商人のサイトに製品情報を記憶する要求が消費者から数百または数千にも上ると、商人サイトの応答時間の劣化を招き、記憶の負担が大きいことに関連する他の問題も発生する可能性がある。
更に、既存のコンピュータを用いたショッピング・システムは、典型的に、サーバ側の殆どまたは全てのトランザクション・オプションを取り仕切る（host）ので、商人サイトによってショッピングの手順（experience）が異なる場合が多い。即ち、消費者がある商人サイトから次の商人サイトに移動する際、消費者に提示されるオプション、およびこれらのオプションをナビゲートし有効に利用するために必要なステップがかなり異なることが多い。したがって、多数の商人が提供する製品情報を閲覧し、製品および／またはサービスを購入するために、消費者は、各商人サイトが提供するオプションに順応しかつこれらを学習しなければならない。
既存のコンピュータを用いたショッピング・システムに伴う他の問題として、これらは、各購入毎にユーザに購入情報や送付先情報（shipping information）の入力を要求することが多く、少なくとも消費者に各ショッピング・セッション毎に身分を証明することを要求する。これらの取り決め（restriction）は、時間がかかり、退屈で、しかも煩わしい。更に、支払い情報や送付先情報を繰り返し入力すると、消費者が間違った情報を誤入力する可能性も増大する。
本発明は、既存の電子ショッピング・システムに伴うこれらおよびその他の問題に対処するものである。本発明によれば、既存のクライアントおよびサーバ・ソフトウエア・コンポーネントならびにワールド・ワイド・ウエブのプロトコルを利用し、種々のクライアント−サーバ・ファンクショナリティを追加してユーザがユーザ・コンピュータ上で製品情報（複数の商人ウエブ・サイトから収集した）、支払い情報、および送付先情報の記憶、視認および処理を可能にする、電子ショッピング・システムを提供する。本システムは、特殊なクライアント・アプリケーション（「商取引クライアント（commerce client）」と呼ぶ）を含み、標準的なウエブ・ブラウザと共に消費者のコンピュータ上で走る。商取引クライアントは、双方向機能コール・プロトコルを用いて、特殊商取引サーバ（ウエブ・サーバと共に商人ウエブ・サイト上で走る）と通信を行う。商人ウエブ・サイトが供給するハイパーテキスト（ＨＴＭＬ）カタログ・ページおよびユーザ・コンピュータ上に記憶してある「ユーザ・インターフェース」ハイパーテキスト文書は、埋め込み機能コールを含み、消費者は、ウエブ・ブラウザを用いてハイパーテキスト・ページを視認しながら、これらを選択的に呼び出すことができる。これら埋め込み機能コールを用いて、ユーザは、商人ウエブ・サイトからの特定の製品に関する価格および在庫情報の要求、クライアント側ショッピング・バスケット内への製品情報の選択的な記憶、ショッピング・バスケットの内容視認、ならびに暗号化した送付先および／または支払い情報（消費者コンピュータ上に記憶する）を商人ウエブ・サイトに送信するというようなアクションを実行することができる。
本発明の一形態によれば、このように分散ネットワークを通じて製品情報を収集する方法を提供する。この方法は、（ａ）分散ネットワークを通じてユーザ・コンピュータに第１のハイパーテキスト文書を送るステップであって、（ｉ）第１の製品、（ｉｉ）選択可能な製品収集オプション、および（ｉｉｉ）製品収集オプションと関連付けてある機能コール情報の説明から成る、第１のハイパーテキスト文書を送るステップと、（ｂ）ユーザ・コンピュータを介して、第１のハイパーテキスト文書をユーザに表示し、ユーザの入力を監視し製品収集オプションの選択を検出するステップと、（ｃ）機能コール情報が指定する実行可能機能をコールすることにより、製品収集オプションのユーザ選択に応答し、前述の機能が、第１の製品の説明をユーザ・コンピュータがアクセス可能なデータ記憶エリアに記憶するステップとから成る。この形態の別の実施形態では、更に、（ｄ）分散ネットワークを通じてユーザ・コンピュータに第２のハイパーテキスト文書を送るステップであって、（ｉ）第２の製品の説明と、（ｉｉ）第２の選択可能な製品収集オプションと、（ｉｉｉ）第２の製品収集オプションと関連付けてある機能コール情報とから成る、第２のハイパーテキスト文書を送るステップと、（ｅ）ユーザ・コンピュータを介して、第２のハイパーテキスト文書をユーザに表示し、ユーザの入力を監視し第２の製品収集オプションの選択を検出するステップと、（ｆ）機能コール情報内に示す第２の実行可能機能をコールすることにより、第２の製品収集オプションの選択に応答し、前述の機能が、第２の製品の説明をデータ記憶エリアに記憶するステップと、（ｇ）ユーザ・コンピュータを介して、製品比較オプションをユーザに表示し、ユーザの入力を監視し製品比較オプションの選択を検出するステップと、（ｈ）ローカル記憶エリアから、第１の製品の説明および第２の製品の説明を検索し、説明をフォーマット化し、ユーザ・コンピュータを介してユーザに説明を表示することによって製品比較オプションの選択に応答するステップとを含む。
本発明の別の形態は、ウエブ・ブラウザを用いてローカル・データを管理する方法である。ローカル・データは、ユーザ・コンピュータがアクセス可能なコンピュータ記憶媒体上に記憶する。この方法は、（ａ）ウエブ・ブラウザを用いて、ユーザ選択可能な視認オプションと、視認オプションと関連する機能コール情報とを備えるＨＴＭＬ文書（ハイパーテキスト・マークアップ言語）を受信するステップと、（ｂ）ユーザ・コンピュータを介して、ＨＴＭＬ文書をユーザに表示するステップであって、表示が視認オプションを含む、ステップと、（ｃ）ユーザ入力を監視して、視認オプションの選択を検出するステップと、（ｄ）機能コール情報に示す機能をコールすることにより、視認オプションの選択に応答するステップであって、前述の機能が、ローカル・データにアクセスし、これをフォーマット化し、ローカル・データをユーザに表示するステップとから成る。
【図面の簡単な説明】
これらおよびその他の本発明の特徴について、コンピュータを用いたショッピング・システムの好適な実施形態の図面を参照しながら、以下に説明する。このショッピング・システムは、例示することを意図するのであり、本発明を限定することを意図するのではない。図面において、
図１は、本発明によるシステムの２箇所の商人ウエブ・サイトと通信する消費者コンピュータを示す。
図２は、標準的ウエブ・ブラウザとウエブ・サーバとの間のＨＴＴＰメッセージ・ストリームを用いて、本システムの消費者コンピュータと商人ウエブ・サイトとの間で、機能コール要求および応答を転送するための好適なプロトコルを示す。
図３は、本システムの商人ウエブ・サイトの好適なソフトウエア・アーキテクチャを示す。
図４は、本システムの消費者コンピュータの好適なソフトウエア・アーキテクチャを示す。
図５は、消費者コンピュータ上において、ショッピング・バスケット・オブジェクト、ウオレット・オブジェクト、および住所録オブジェクトによってアクセスし操作するデータ構造を示す。
図６は、製品に関する情報（商人ウエブ・サイトが提供する）をショッピング・バスケット・オブジェクトに追加する際に実行するステップを示す。
図７は、ショッピング・バスケット内に記憶した製品情報を視認する際に実行するステップを示す。
図８は、ショッピング・バスケットから製品を削除する際に実行するステップを示す。
図９は、電子ショッピング・バスケットから製品に関する詳細を視認する際に実行するステップを示す。
図１０は、消費者コンピュータ上において、ウオレット・オブジェクト内の支払い源データを視認し操作する際に実行するステップを示す。
図１１は、消費者コンピュータ上において、住所録オブジェクト内の送付先住所データを視認し操作する際に実行するステップを示す。
図１２は、分散ネットワークを通じて、システムの商人ウエブ・サイトから選択した製品を購入する際に実行するステップを示す。
好適な実施形態の詳細な説明
本発明は、電子ショッピングに関し、ユーザがパーソナル・コンピュータを用いて、分散ネットワークを介して販売に供された製品の比較および購入を可能にするものである。本発明は、既存のプロトコルおよびワールド・ワイド・ウエブのコンポーネントを利用する、コンユーピュータ系ショッピング・システム内に実体化する。コンピュータを用いたショッピング・システムについてこれより詳細に説明する。
好適な実施形態では、本システムは、標準的なウエブ・ブラウザと共に消費者のコンピュータ上で走る「商取引クライアント」プロセスを含む。商取引クライアントは、インターネットを通じて、商人ウエブ・サイト上で実行する「商取引サーバ」（双方向機能コール・プロトコルを用いる）と通信する。好適な実施形態では、商取引クライアントがショッピング・バスケット、ウオレット、および住所録と同様のファンクショナリティを含み、商取引サーバが種々の商取引関連サービス（製品情報へのアクセスや返送、税金の計算、注文の処理等のような）を提供するファンクショナリティを含む場合もある。
商取引クライアントおよび商取引サーバは、共に動作し、消費者のコンピュータがインターネットに接続されている間、消費者があらゆる数の商人からでも製品情報を収集することを可能にする。また、商人クライアントは、消費者が種々の商人から収集した製品情報を検討することにより、比較ショッピングを行うことも可能にする。この製品比較は、消費者のコンピュータがインターネットに接続中か否かには関係なく、いつでも（例えば、オフライン中）いかなる時間長にわたってでも行うことができる。
本発明を実体化するコンピュータを用いたショッピング・システムの動作に不慣れなユーザは、ヘルプ・オプションを選択することにより、指導情報（またはアプリケーションのヘルプ）にアクセスすることができる。指導情報は、１つ以上のＨＴＭＬコード化したウエブ文書に記憶してあり、ユーザの要望に応じて検索し表示する。
本発明を実体化する、コンピュータを用いたショッピング・システムによって、ユーザはオンライン商人からの製品購入が可能となる。消費者は、商取引クライアントを用いて、支払いを許可し、支払い源を選択し、送付先住所を選択し（いずれもネットワーク接続を必要としない）、更に選択した製品の注文を商人に発行することができる。商取引クライアントが注文を商取引サーバに伝達するためにネットワーク接続を確立する。支払いおよび送付先情報は、暗号化技術を用いて、第三者の傍受（discovery）から保護してある。
以下の章および小章によって、本発明を更に詳しく説明する。
Ａ．用語および省略語集
Ｂ．コンピュータを用いたショッピング・セッションの一例
Ｃ．商取引クライアントと商取引サーバとの間の通信
Ｄ．商人ウエブ・サイトのソフトウエア・アーキテクチャ
Ｅ．消費者コンピュータのソフトウエア・アーキテクチャ
Ａ．用語および省略語集
詳細な説明全体にわたって以下の用語および省略語を用いる。
インターネット。１組の標準プロトコル（ＴＣＰ／ＩＰおよびＨＴＴＰのような）によって互いにリンクし全地球的な分散ネットワークを形成する、相互接続（公衆および／または私用）ネットワークの集合体。（この用語は、今日一般的にインターネットとして知られているものに言及することを意図しているが、既存の標準プロトコルに対する変更や追加を含む、将来発生し得る様々な変更も含むことを意図するものとする）。
ワールド・ワイド・ウエブ（「ウエブ」）。ここで用いる場合、一般に、（ｉ）相互リンクしてありユーザが視認可能なハイパーテキスト文書（一般的には「ウエブ文書」または「ウエブ・ページ」と呼ばれている）の分散した集合体であり、インターネットを通じてアクセス可能な文書、および（ｉｉ）標準化したインターネット・プロトコルを用いてこのような文書に対するアクセスをユーザに与えるクライアントおよびサーバ・ソフトウエア・コンポーネントの双方に言及するものとする。現在、アプリケーションにウエブ文書を見つけ出し獲得させるための主要な標準プロトコルは、ＨＴＴＰ（以下で論ずる）であり、ウエブ・ページはＨＴＭＬ（これも以下で論ずる）を用いてエンコードしてある。しかしながら、「ウエブ」および「ワールド・ワイド・ウエブ」という用語は、ＨＴＭＬおよびＨＴＴＰに代わって（または、これらに加えて）用いる可能性がある、将来のマークアップ言語およびトランスポート・プロトコルも含むことを意図している。
クライアント・サーバ。分散システムにおける双方向処理のモデルであり、あるサイトにおけるプログラムが、他のサイトにおけるプログラムに要求を送り、応答を待つ。要求側プログラムを「クライアント」と呼び、要求に応答するプログラムを「サーバ」と呼ぶ。ワールド・ワイド・ウエブの関連では、クライアントは、ユーザのコンピュータ上で走る「ウエブ・ブラウザ」（または単に「ブラウザ」）であり、ブラウザの要求に応答してウエブ・ページを提供するプログラムのことを、一般的に「ウエブ・サーバ」と呼んでいる。
ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）。標準的なインターネット・プロトコル（またはプロトコル集合）であり、２台のコンピュータがインターネットを通じてどのようにデータ交換を行うかについて指定する。ＴＣＰ／ＩＰは、パケット化、パケット・アドレシング、ハンドシェーキング、およびエラー訂正のような問題を扱う。ＴＣＰ／ＩＰに関する更なる情報については、ComerおよびStevens（コマーおよびスチーブンス）の“Internetworking with TCP/IP”（ＴＣＰ／ＩＰを用いた相互ネットワーク構築）の第Ｉ，ＩＩおよびＩＩＩ巻（Prentice Hall, Inc.（プレンティス ホール社）,ISBN 0-13-468505-9（第Ｉ巻）、0-13-125527-4（第２巻）、および0-13-474222-2（第３巻））を参照されたい。
ＨＴＭＬ（ハイパーテキスト・マークアップ言語）。文書内の情報コンテンツに、プレゼンテーションやリンク属性を添付するための標準的なコード化規則および１組のコード。（現在ウエブ文書を作成するために用いる主要な標準は、ＨＴＭＬ２．０である。）文書オーサリング段階の間に、文書の情報コンテンツ内にＨＴＭＬコード（「タグ」と呼ぶ）を埋め込む。続いてウエブ・サーバからブラウザにウエブ文書（または「ＨＴＭＬ文書」）を転送するとき、ブラウザがコードを解釈し、文書の解析および表示に用いる。ウエブ・ブラウザが文書をどのように表示するのかについて指定することに加えて、ＨＴＭＬタグは、他のウエブ文書へのリンク（一般的に、「ハイパーリンク」と呼ぶ）を作成するために用いることも可能である。ＨＴＭＬに関する更なる情報については、Ian S.Graham（アイアン Ｓ．グラハム）の“The HTML Source Book”（ＨＴＭＬソース・ブック）（John Wiley and Sons,Inc.,（ジョン ワイリー アンド サンズ社）、１９９５年）（ISBN 0471-11894-4）を参照されたい。
ポートまたはポート番号：（「ソケット番号」とも呼ぶ）インターネットの関連では、ＴＣＰ／ＩＰが用いて着信データを特定のアプリケーションに送達するための数値識別子（通常、ＩＰアドレスと共に与える）。あるポートは、あるアプリケーションのために、Internet Assigned Number Authority（IANA:インターネット割り当て番号機関）が予約してある。例えば、ポート８０は、ＨＴＴＰのために予約してあり、ウエブ・サイト上で着信トラフィックをウエブ・サーバに送達するために用いる（次の「ＵＲＬ」を参照のこと）。
ＵＲＬ（Uniform Resource Locator）。インターネット上でファイルまたはその他のリソースの場所を完全に指定する一意のアドレス。ＵＲＬの一般的なフォーマットは、「プロトコル：／／機械アドレス：ポート／パス／ファイル名」となる。ポート指定はオプションであり、ユーザが何も入力しない場合、ブラウザは、プロトコルとしていずれのサービスが指定されても、デフォルトの標準ポートを用いる。ＨＴＴＰをプロトコルとして指定した場合、ブラウザは、８０のＨＴＴＰデフォルト・ポートを用いる。
ＨＴＴＰ（Hypertext Transport Protocol）。ブラウザとウエブ・サーバとの間の情報（ＨＴＭＬ文書や、このような文書に対するクライアントの要求等）の交換に用いる、標準的なワールド・ワイド・ウエブ・クライアント−サーバ・プロトコル。ＨＴＴＰは、多数の異なる種類のメッセージを含み、これらをクライアントからサーバに送ることによって、異なる種類のサーバ・アクションを要求することができる。例えば、“GET”メッセージは、GET<URL>というフォーマットを有し、指定されたＵＲＬに位置する文書またはファイルを、サーバに返還させる。
ＨＴＴＰ ＰＯＳＴ。ＨＴＴＰメッセージの一種であり、ウエブ・サーバがウエブ・クライアントからの情報を受け入れることを要求するために用いる。この情報は、例えば、ニュースグループに転記（post）するメッセージ、またはＣＧＩスクリプト（以下の「ＣＧＩ」を参照のこと）が実行するデータベース・サブミッション（database submission）という形態を取ることができる。
ＭＩＭＥ（Multipurpose Internet Multimedia Extensions）形式。ファイルの形式即ちフォーマット（例えば、ＨＴＭＬ、テキスト、グラフィックス、オーディオ等）を指定するファイル拡張子またはアタッチメント。ＭＩＭＥ形式を指定することにより、ウエブ・ブラウザは、ウエブ・サーバから受信したファイルをどのように処理するのかについて決定することが可能になる。例えば、ＭＩＭＥ形式ＨＴＭＬ（拡張子“.htm”または“.html”）のファイルは、ブラウザが表示するものであり、ＭＩＭＥ形式Ｘ−ＷＡＶ（拡張子“.wav”）は、典型的に、マイクロソフトのWAVフォーマットを扱うことができるオーディオ・プレーヤに受け渡す。標準的なＷＥＢブラウザは、普及しているＭＩＭＥ形式を扱うようなコンフィギュレーションを予め備えつつある。加えて、標準的なウエブ・ブラウザは、新たなＭＩＭＥ形式を扱うように、ユーザが簡単にコンフィギュレーションを設定することができる。このためには、典型的に、新たな各ＭＩＭＥ形式のファイル拡張子を指定し、このような形式のファイルを受け渡すべきアプリケーション（「ＭＩＭＥハンドラ」と呼ぶ）のパスおよびファイル名を指定する必要がある。
インターネット・ファイアウオール（Internet Firewall）。インターネットとある団体のネットワーク（ＬＡＮ等）との間に設置する防犯システムであり、機密上の攻撃に対するバリアを備える。典型的に、インターネット・ファイアフォールを動作させると、当該団体のネットワークに対する着信トラフィックおよび／または出立トラフィックを監視し、ある種の形式のメッセージのみを通過させる。例えば、ポート８０にアドレスされたＴＣＰ／ＩＰトラフィック全ての通過を許可し、他の全てのトラフィックを拒絶するように構成することも可能である。インターネット・ファイアウオールに関する更なる詳細については、Chapman（チャップマン）およびZwicky（ズイッキー）の“Building Internet Firewalls”（インターネット・ファイアウオールの構築）（O’Reilly publishing（オレイリー出版、１９９５年）（ISBN 1-56592-124-0）を参照されたい。
ＣＧＩ（Common Gateway Interface）。標準的なインターフェースであり、ウエブ・サーバ（または他の情報サーバの場合もあり得る）が、クライアントからの要求に応答して、どのように起動し（launch）外部プログラム（データベース探索エンジン等）と双方向処理を行うのかについて指定する。ＣＧＩを用いると、ウエブ・サーバは、クライアントが読むことができないフォーマットで記憶した情報を提供し、このような情報をクライアントが読むことのできるウエブ・ページの形態で提示することができる。ＣＧＩプログラム（「ＣＧＩスクリプト」と呼ぶ）は、例えば、データーベース・クエリを指定するスクリーン上の書式にウエブ・ユーザが記入したときに呼び出すことができる。ＣＧＩの欠点の１つとして、一般に、受信した各クライアント要求毎に、別個のプロセスを起動しなければならないことがあげられる。ＣＧＩに関する更なる詳細については、Ian S.Graham（アイアン Ｓ．グラハム）の“The HTML Source Book”（ＨＴＭＬソース・ブック）の２３１〜２７８ページ（John Wiley and Sons,Inc.,（ジョン ワイリー アンド サンズ社）、１９９５年）（ISBN 0471-11894-4）を参照されたい。
ＩＳＡＰＩ（Internet Server Application Program Interface）。ウエブ・サーバ（またはその他の情報サーバ）が、クライアントからの要求に応答して起動し外部プログラムと双方向処理を行うことを可能にするマイクロソフトのインターフェース。ＩＳＡＰＩプログラムは、ダイナミック・リンク・ライブラリ（ＤＬＬ：dynamic link library）の形態であり、ウエブ・サーバと同じプロセス空間で走る。したがって、ＩＳＡＰＩはＣＧＩと同様の機能を行うが、別個のプロセスの起動を必要としない。ＩＳＡＰＩに関する文書資料は、Microsoft Internet Information Server Software Development kit（マイクロソフト・インターネット情報サーバ・ソフトウエア開発キット）の一部として、Microsoft Corporation（マイクロソフト社）から入手可能である。
Ｂ．コンピュータを用いたショッピング・セッションの一例
この章は、本発明の特徴を用いた、仮説的なコンピュータを用いたショッピング・セッションの一例を示す。図１は、消費者コンピュータ１０２、第１の商人サイト（「商人サイトＡ」）１０４、および第２の商人サイト（「商人サイトＢ」）１０６を示し、各々インターネットに接続してあり、ワールド・ワイド・ウエブ（「ＷＷＷ」）１０８を利用する。商人サイトＡ１０４および商人サイトＢ１０６は、ショッピング指向トランザクション（shopping-oriented transaction）を取り仕切り、インターネットを通じた製品の広告および販売を行う。消費者コンピュータ１０２および商人ウエブ・サイト１０４，１０６は、クライアントおよびサーバ・ソフトウエア・アプリケーションを走らせ、消費者がＷＷＷを通じて流されている製品情報を閲覧し、製品や商人に関する情報を入手し、クライアント側のデータベースに製品情報および商人情報を選択的に記憶し、異なる商人からの製品情報を比較し、インターネットを通じて販売されている製品を購入することを可能にする。
消費者コンピュータ１０２は、処理部１１０、データ記憶エリア１０２、ならびにモニタ１１４、キーボード１１６、およびマウス１１８を備えている。標準的なウエブ・ブラウザ１２０（例えば、Microsoft Internet Explorer 2.0（マイクロソフト・インターネット・エクスプローラ２．０）またはNetscape Navigator 2.0（ネットスケープ・ナビゲータ２．０）等）、および特殊商取引クライアント・プロセス１２２が、処理部１１０上で実行する。
商人サイトＡ１０４は、処理部１２４およびデータ記憶エリア１２６を備えている。標準的なウエブ・サーバ１２８（Microsoft Internet Information Server 1.0（マイクロソフト・インターネット情報サーバ１．０）等）、および特殊商取引サーバ１３０が処理部１２４上で実行する。データ記憶エリア１２６は、ＨＴＭＬ文書１４４および商人データベース１４６を記憶する。同様に、商人サイトＢも処理部１３２およびデータ記憶エリア１３４を備えている。標準的なウエブ・ブラウザ１３６が処理部１３２上で実行し、特殊商取引サーバ１３８も同様である。データ記憶エリア１３４は、ＨＴＭＬ文書および商人データベースも記憶する。
消費者コンピュータ１０２を使用する消費者は、クレジット・カード番号、有効期限、発行元銀行のような支払い源情報１４０を、記憶エリア１１２に記憶させる。消費者は、支払い源情報と関連付けてパスワードを与える。パスワードは、今後の無許可アクセスを防止するだけでなく、支払い源情報を暗号化するためにも用いる。支払い源情報は、製品および／またはサービスを購入するための好適な資金源および／または与信源（credit source）を表す。商取引クライアント１２２は、暗号化した支払源データをデータ記憶エリア１１２に書き込む。一旦支払い源情報を入力し、その精度（accuracy）を確認した後、情報は消費者コンピュータ１０２に永続するので、消費者が再入力する必要はない。消費者は、優先する支払い源として、複数の支払い源の１つを指定する。
また、消費者は、消費者コンピュータ１０２を通じて、送付先住所情報１４２を記憶エリア１１２に記憶させる。送付先住所情報は、製品配達に好ましい宛先を示し、例えば、個人の住所、私書箱、または会社の居所を含む。再度、商取引クライアント１２２は、消費者が入力した送付先住所情報１４２を記憶エリア１１２に書き込む。好ましい送付先を入力した後、これらは２回入力する必要はない。支払い源データの場合と同様、消費者は、好ましい送付先住所として、１つの送付先住所を指定する。
消費者は、消費者コンピュータ１０２を用いて、ワールド・ワイド・ウエブ１０８を通じて商人が提供する、例えば、音楽用コンパクト・ディスク、ダウンロード可能なソフトウエア・プログラム、希少な貨幣、または冷蔵庫のような製品の買い物をする。冷蔵庫を買う場合を例に取ると、消費者は消費者コンピュータ１０２を用いてインターネットへの接続を確立し、ウエブ・ブラウザを用いてワールド・ワイド・ウエブ１０８のサイトをナビゲート（navigate）する。インターネットへの接続およびＷＷＷの閲覧は周知であり、それい伴う工程についてはこれ以上説明しない。
消費者はウエブ・ブラウザ１２０を用いて、ＷＷＷ上の商人サイトＡ１０４にアクセスする。商人サイトＡ１０４のウエブ・サーバ１２８は、消費者コンピュータ１０２が開始したアクセスに応答し、ＨＴＭＬ文書集合１４４から第１のＨＴＭＬ文書（即ち、ハイパー・テキスト・マークアップ言語にしたがってエンコードしたデータの集合体）を検索し、次いでこの第１のＨＴＭＬ文書を消費者コンピュータ１０２のウエブ・ブラウザ１２０に送信する。
ウエブ・ブラウザ１２０は、ＨＴＭＬ文書を解釈し、モニタ１１４上に、文書のページ指向表示（page-oriented representation）を作成する。消費者はモニタ１１４上の文書を視認する。文書は、例えば、提供する製品の特徴（nature）や受け入れる支払い形態というような、商人サイトＡ１０４について記述するテキスト情報を、製品の注文書に記入する際に消費者に提示することができる。消費者は、例えば、商人サイトＡが冷蔵庫の販売を提供し、支払いにはＶＩＳＡを受け入れることがわかる。
一般的に、消費者が選択可能なオプション（「ハイパーテキスト・リンク」）も、ＨＴＭＬ文書内には提示してあり、マウス１１８またはキーボード１１６を用いて消費者が選択した場合、消費者コンピュータ１０２は、関連情報または更に詳細な情報を提供する追加のＨＴＭＬ文書を検索し送信する要求を、ウエブ・サーバ１２８に送信する。消費者は、追加のハイパーテキスト・リンクをナビゲートし、商人サイトＡが販売する冷蔵庫の特徴を纏めた追加のＨＴＭＬ文書を閲覧する。
消費者は、商人サイトＡが提供する冷蔵庫の１つが消費者の要望に一致すると判断する。消費者には多数の属性が提示され、各属性には多数の値の内１つを設定することができる。したがって、例えば、ユーザは、色属性を「卵の殻の白」に設定し、内部噴水口（indoor water spout）属性を「不要」に設定し、自動製氷機属性を「要」に設定する。次に、消費者は、例えば、「ショッピング・バスケットに品目を追加して下さい」と記されたオプションを選択する。ウエブ・ブラウザ１２０は、対応するメッセージを商取引クライアント１２２に送達し、選択した属性を含む、選択した商人Ａの冷蔵庫に関する情報を、製品一括データベース（gathered products database）１４８内に記憶する。（この種の動作を実行可能にするプロトコルおよびソフトウエア・コンポーネントについては、以下の章で説明する。）このような情報は、例えば、冷蔵庫の色、立方フィート単位の容量、温度範囲、使用電力、製造会社の保証、価格、消費者が設定した属性、商人サイトＡのＵＲＬを含み、更に優先する支払い源および優先する送付先住所も含む。次いで、消費者は、別のワールド・ワイド・ウエブ・サイトにアクセスするか、あるいはインターネットへのネットワーク接続を終了するように消費者コンピュータ１０２に指令することにより、商人サイトＡとのショッピング・セッションを終わらせる。
二日後、消費者が再び買い物をする時間ができ、消費者コンピュータ１０２にワールド・ワイド・ウエブを通じて商人サイトＢに接続するように指令する。商人サイトＢも冷蔵庫の販売を提供する。商人サイトＢが販売する冷蔵庫の特徴を記述するＨＴＭＬ文書全体をナビゲートした後、消費者はある冷蔵庫を選択し、必要に応じて冷蔵庫の属性を設定し、「品目をショッピング・バスケットに追加して下さい」というオプションを呼び出す。これを行うコマンドは、商人サイトＡの冷蔵庫に関する情報をショッピング・バスケットに追加する際に必要なコマンドと同一である。商取引クライアント１２２は、呼び出されたオプションに応答し、商人サイトＢの冷蔵庫に関する情報を、製品一括データベース１４８に追加する。次いで、消費者は、商人サイトＢ１０６とのショッピング・セッションを終了する。
３週間後、消費者は消費者コンピュータ１０２を用いて、商人サイトＡの冷蔵庫に関する情報と商人サイトＢの冷蔵庫に関する情報を比較する。消費者は、２台の冷蔵庫を比較するためにワールド・ワイド・ウエブに接続する必要はない。消費者は、例えば、「ショッピング・バスケット内の品目を見る」と称するオプションを呼び出す。商取引クライアント１２２は、製品一括情報１４８から２台の冷蔵庫に関する情報を抽出し、消費者がそれをモニタ１１４上で視認できるようにこれらの情報をフォーマット化する。２台の冷蔵庫の特徴、保証、および価格を秤にかけた後、消費者は商人サイトＡの冷蔵庫を購入することを決心する。
次に、消費者は、消費者自身にしかわからないパスワードを入力することにより、消費者コンピュータ上に記憶してある支払い源情報および住所情報へのアクセスを許可する。消費者がパスワードを入力した後、商取引クライアント１２２は、支払い源情報１４０にアクセスし、暗号を解読し、商人Ａの冷蔵庫に関する情報とこれを組み合わせ、商品およびサービス注文書（「ＧＳＯ:goods and services order」）を作成する。次いで、ＧＳＯを暗号化し、ＨＴＴＰ ＰＯＳＴメッセージの一部として含ませ、商人ＡのＵＲＬに送る。商人Ａはこのメッセージを受信し、解読し、注文を処理し、消費者が指定した送付先住所に製品を送付する。
冷蔵庫を購入して数年後、消費者は製品購入履歴を調べ、例えば、冷蔵庫が未だ保証期間内にあるか否かについて判定を行う。電子ショッピング・バスケットは、購入した全製品の履歴全てを閲覧可能に保持している。
Ｃ．商取引クライアントと商取引サーバとの間の通信
本発明は、ショッピングに関連する特徴、即ち、製品情報を収集可能なショッピング・バスケット、支払い源を記憶可能なウオレット（wallet）、および送付先住所を記録可能な住所録を追加することによって、標準的なウエブ・ブラウザ１２０のファンクショナリティを拡張する。標準的なウエブ・ブラウザ１２０をこのように拡張すると、ワールド・ワイド・ウエブを通じて製品を購入する非常に便利で一貫性のある購入方法を消費者に提供することになる。この章では、ウエブ・ブラウザがそれ自体のローカル・コンピュータ上およびウエブ・サーバを実行するコンピュータ上の双方において機能をコールする方法について説明する。加えて、ウエブ・サーバにウエブ・ブラウザを実行するコンピュータ上で機能をコールさせる方法についても説明する。
図２は、消費者コンピュータ１０２と商人コンピュータ２０２との間の通信を示す。消費者は、消費者コンピュータ１０２を通じて、インターネット２０４上の商人コンピュータ２０２にアクセスする。消費者コンピュータ１０２は、標準的なウエブ・ブラウザ１２０を含み、一方商人コンピュータ２０２はウエブ・サーバ１２８を含む。ウエブ・ブラウザ１２０およびウエブ・サーバ１２８は、ＨＴＴＰプロトコルを用いて、インターネットを通じ互いに通信を行う。
商人コンピュータ２０２上で走るウエブ・サーバ１２８は、ＨＴＭＬ文書（一般的に「ウエブ文書」または「ウエブ・ページ」とも呼んでいる）のローカル記憶部１４４にアクセスする。消費者コンピュータ１０２上のウエブ・ブラウザ１２０がＨＴＭＬ文書を要求すると、ウエブ・サーバ１２８はＨＴＭＬ文書を検索し、消費者コンピュータ１０２上のウエブ・ブラウザ１２０にこれを送信し、消費者はこれを消費者コンピュータ１０２上で視認する。これらの文書は、典型的に、商人が販売する製品に関する情報（製品の写真や説明および製品価格）だけでなく、商人に関する情報も含む。
消費者と商人との間で更に精巧なショッピング・トランザクションを行うために、消費者指向ショッピング機能を与える専用ソフトウエア（商取引クライアント１２２）を消費者のコンピュータ上で実行し、商人指向ショッピング機能を与える専用ソフトウエア（商取引サーバ１３０）を商人コンピュータ２０２上で実行する。本発明の目的の１つは、消費者コンピュータ１０２上で走りウエブ・ブラウザ１２０と直接通信する商取引クライアント１２２と、商人コンピュータ２０２上で走りウエブ・サーバ１２８と直接通信する商取引サーバ１３０との双方を提供することである。
商取引クライアント１２２および商取引サーバ１３０は、ウエブ・ブラウザ１２０とウエブ・サーバ１２８との間で、インターネットを用いた通信を利用することにより、互いに通信を行う。拡張可能なウエブ機能コール・プロトコル（「ＷＦＣＰ」（Web function-calling protocol）によって、商取引クライアント１２２および商取引サーバ１３０は、互いに機能コールを渡し合うことができる。その際、ウエブ・ブラウザ１２０およびウエブ・サーバ１２８が、インターネットを通じて交換するデータに機能コールを埋め込む。図２に示すように、ウエブ機能コール・プロトコルは、標準的なウエブ・ブラウザ１２０とウエブ・サーバ１２８との間で、ＨＴＴＰメッセージ・ストリーム（破線で示す）を通じて、機能コール情報（要求および応答）を効果的に「潜り抜け」させる。ＨＴＴＰを使用することによる大きな利点の１つは、消費者コンピュータ１０２が、ＨＴＴＰトラフィックの通過を許可するインターネット・ファイアウオールの後ろから、商人ウエブ・サイトとの通信を可能にすることである。
ウエブ・サーバ１２８は、埋め込み機能コール情報を含むＨＴＭＬ文書を供給する。この機能コール情報は、標準的なＨＴＭＬタグを用いて、隠れた形態で埋め込んであり、商取引クライアント１２２および商取引サーバ１３０が認識する所定のフォーマット（ＷＦＣＰの一部として指定する）で与える。一般的に、埋め込み機能コール情報は、ＨＴＭＬ文書内の消費者が選択可能なオプション（例えば、ハイパーリンクまたはボタン）に対応し、消費者がトランザクション・オプションを（マウスまたはキーボードを用いて）選択することにより、インターネットを介してクライアント−サーバ機能コールを開始させる。
図２は、ウエブ・ブラウザ１２０が表示するＨＴＭＬ文書２０６を示す。ＨＴＭＬ文書１２６は、実行すべき対応するアクションのテキスト記述（“buy”（購入）、“update shopping basket”（ショッピング・バスケット更新）、“retrieve price information”（価格情報検索）、“retrieve account information”（アカウント情報検索）等）に関連付けてある、消費者選択可能ボタン２０８を含む。消費者がこのボタン上でクリックすると、対応する機能コール情報が、消費者コンピュータ１０２から商人コンピュータ２０２に標準的なＨＴＴＰ ＰＯＳＴメッセージとしてインターネットを介して受け渡される。
対応する機能コールを行う機能コール情報は、典型的に、オブジェクトの名称、オブジェクト・インターフェース、メソッド、および引数リストを含む。ボタン２０８が“Calculate Tax”（税金計算）オプションを活性化する場合、このボタンに関連する対応機能コール情報は、例えば、以下のテキストを含む。
OBJECT=MSTaxEngine.1
INTERFACE=ItaxCalculation
METHOD=CalculateTaxDue
ARGS=arglist
この機能コール情報は、ターゲットのＵＲＬ（商人ウエブ・サイト１０４，１０６の）と共にＨＴＭＬ文書内に備え、消費者がボタン２０８上でクリックした場合、この情報を含むＨＴＴＰ ＰＯＳＴメッセージをＵＲＬに送るようになっている。ＨＴＴＰ ＰＯＳＴメッセージのＨＴＭＬコード化形態の一例は、以下のようになる。

この例のターゲットＵＲＬは、ＨＴＭＬ文書のソースであるウエブ・サイトに対応するが、ターゲットＵＲＬは異なるウエブ・サイトのそれである可能性もある。
したがって、消費者がボタン２０８上でクリックすると、ウエブ・ブラウザ１２０はＨＴＭＬを用いてコード化したＨＴＴＰ ＰＯＳＴメッセージを発生し、このＨＴＴＰ ＰＯＳＴメッセージを商人ウエブ・サイト１０４，１０６のＵＲＬに送る。このメッセージは、商人コンピュータ上のメソッド・ライブラリ２１２の１つのメソッド（即ち、ソフトウエアでコール可能なプロシージャまたは関数）を呼び出す、機能コール情報（オブジェクト、インターフェース、メソッドおよび引数）を含む。ボタン２０８に多数の機能コールをリンクしてある場合、ＨＴＴＰ ＰＯＳＴメッセージは、このような機能コール毎に機能コール情報を含む。
ＨＴＴＰ ＰＯＳＴメッセージの受信時に、ウエブ・サーバ１２８はこのメッセージを解析し、商取引サーバ１３０を呼び出し（未だ実行していない場合）、機能コール情報を商取引サーバ１３０に受け渡す。すると、商取引サーバ１３０は指定したオブジェクトを呼び出し、指定したインターフェースを用いて引数を指定したメソッドに受け渡し、これによって商取引サーバ１３０は、商取引クライアント１２２の代わりに、機能コールを行う。コールするメソッドに応じて、機能は、例えば、商人データベースのクエリおよび／または商人データベースに対する更新を伴う場合がある。
この機能コールは、典型的に、消費者コンピュータ１０２に伝達しなければならない応答を生成する。（電子ショッピングとの関連では、応答メッセージは、例えば、特定の製品に価格または在庫情報、あるいはは消費者が要求した税金計算の結果を含むことがある。）応答は、商取引クライアント１２２に特定して送達する、機能コールまたはその他の情報を含む場合がある。ウエブ・ブラウザ１２０は、商人コンピュータ２０２から消費者コンピュータ１０２に送信される全データを受信する。しかしながら、ウエブ・ブラウザ１２２が受信するデータの中には、更に商取引クライアント１２２に送出するものもある。
ウエブ・サーバ１２８は、消費者コンピュータ１０２にデータを送信する際、まず最初にデータをＭＩＭＥメッセージとしてパッケージ化し、ウエブ・サーバ１２８からウエブ・ブラウザ１２０にインターネットを介してこのＭＩＭＥメッセージを送る。応答メッセージが、ウエブ・ブラウザ１２０が表示するＨＴＭＬ応答の形態である場合、メッセージのＭＩＭＥ形式はＨＴＭＬとなる。一方、応答メッセージを商取引クライアント１２２に送達する場合（応答が非ＨＴＭＬ製品情報を含む場合等）、応答メッセージには、商取引クライアント１２２に対応するＭＩＭＥ形式を添付し、ウエブ・ブラウザ１２０にメッセージを商取引クライアント１２２に送出させる。
好適な実施形態では、商取引クライアントに関連するＭＩＭＥ形式は、“x-ishopper”である。サーバ側で発生したメッセージは、消費者コンピュータ１０２上の機能をコールするための情報を含む場合があり、この場合、ＭＩＭＥ情報は機能コール情報を含む。このサーバ−クライアント機能コール情報は、クライアント側機能コールのオブジェクト、メソッド、インターフェースおよび引数を指定し、クライアント−サーバ機能コールに用いるのと同じフォーマット（先に示した）を用いて、ＭＩＭＥメッセージ内で指定する。
形式“x-ishopper”のＭＩＭＥメッセージを受信すると、ウエブ・ブラウザ１２０はＭＩＭＥヘッダを抜き取り、メッセージを商取引クライアント１２２に受け渡す。以下で更に詳しく説明するが、商取引クライアントは、形式“x-ishopper”のメッセージに対しては、ＭＩＭＥハンドラとして機能する。商取引クライアント１２２は、次に、商取引サーバ１３０が商人コンピュータ２０２上で実行するのと同様に、消費者コンピュータ１０２上でＭＩＭＥメッセージ内に指示されているメソッドを読み出す。
このように、ＨＴＴＰ ＰＯＳＴメッセージおよびＭＩＭＥメッセージを用いて、消費者コンピュータ１０２が商人コンピュータ２０２上に機能コールを置き、商人コンピュータ２０２は消費者コンピュータ１０２上に機能コールを置く。ＷＦＣＰは、いずれの特定の機能または機能集合にも束縛されないという利点がある。このため、既存の機能コール・コンポーネントに変更を加えることなく、新たなクライアント側機能およびサーバ側機能を追加（しＨＴＭＬ文書内に埋め込む）することができる。ＷＦＣＰプロトコルについては、“SYSTEM AND METHOD FOR MAKING FUNCTION CALLS OVER A DISTRIBUTED NETWORK”（分散ネットワークを通じて機能コールを行うシステムおよび方法）と題し、１９９６年６月２８日に出願した、同時係属中の特許出願番号第０８／６７０．８８２号に更に詳しく記載してある。その内容はこの言及により全体的に本願にも含まれるものとする。
しかしながら、消費者コンピュータ１０２上でローカル機能を呼び出すメソッドをウエブ・ブラウザ１２０に備えることにより、更に別の利点が得られる。同じＨＴＴＰ ＰＯＳＴメッセージ・フォーマットを用いて、ウエブ・ブラウザ１２０は、ローカル・ポートを決定する（resolve）ＵＲＬアドレスを指定することにより、ローカル機能を呼び出す。“http://www.sporting_goods.com”と同様のＵＲＬを用いることによりＨＴＴＰ ＰＯＳＴメッセージをウエブ上のリモート・サイトにアドレスするのではなく、ウエブ・ブラウザ１２０は、ＵＲＬ“127.0.0.1:100”（“:100”はローカル・ポート１００を指定することに注意されたい）を用いることにより、ＨＴＴＰ ＰＯＳＴをローカルの消費者コンピュータ１０２に送達する。このＨＴＴＰ ＰＯＳＴメッセージをローカル・コンピュータに送達する方法は、ＴＣＰ／ＩＰプロトコル・スタックのローカル・ホスト・サービスによって簡便化する。ＵＲＬ“127.0.0.1”は、ローカル・ホスト・サービスが認識するローカル・ループ・バック・アドレスであり、ローカル・マシンをメッセージの受け取り側として識別する。
ポート・リスナ・プロセス（port listener process）がローカル・マシーン１０２上で動作し、例えば、ポート１００のような、指定したポートを監視する。ポート・リスナはＨＴＴＰ ＰＯＳＴメッセージを受信し、コンテンツを解析し、機能コール・データを商取引クライアント１２２に直接受け渡す。このように、ローカル機能を呼び出すのは、ウエブ文書内でコード化し当該ウエブ文書がホストとなる、選択したオプションである。ウエブ文書内では、機能コール情報が、選択したオプションに関連付けてある。このウエブ・ブラウザからローカル機能コールを行う方法については、“SYSTEM AND METHOD FOR MAKING FUNCTION CALLS FROM A WEB BROWSER TO A LOCAL APPLICATION”（ウエブ・ブラウザからローカル・アプリケーションに機能コールを行うシステムおよび方法と題し、１９９６年６月２８日に出願した、同時係属中の特許出願に詳細に記載してある。その内容は、この言及により全体的に本願にも含まれるものとする。
特殊クライアント・プロセスおよびサーバ・プロセスは、コンピュータを用いたショッピングに関して大きな利点を与えることを当業者は認めよう。例えば、商人は比較的静的なカタログ情報をＨＴＭＬ文書として記憶しつつ、商取引サーバ１３０がアクセスする別個のデータベース（図２には示していない）に比較的動的な製品情報（価格および在庫等）を記憶することができるという利便性がある。この製品情報は、特殊商取引クライアント１２２だけが認識するフォーマットで記憶し供給するようにすれば有利である（標準的なウエブ・ブラウザ１２０とは逆に）。商取引クライアント１２２はウエブ・ブラウザ１２０と共に走るので、商取引クライアント１２２は、商人のウエブ・ページからの、消費者が選択したＨＴＭＬ（カタログ）データ、およびクライアント−サーバ機能コールを通じて検索した関連の非ＨＴＭＬ製品情報の双方を容易に記憶することができる。
先に注記したように、全ての情報はＨＴＴＰを通じて受け渡すので、商取引クライアント１２２および商取引サーバ１３０は、インターネット・ファイアウオール２１４を介して通信することができるという利点がある。インターネット・ファイアウオール２１４は、典型的に、ポート８０にアドレスしたＴＣＰ／ＩＰメッセージの通過を許すように構成してあり、機密上の理由により、他のポートにアドレスした通信を禁止するように構成してある。
図２は、単一の商取引サーバ１３０と双方向処理を行う単一のウエブ・サーバ１２８を示すが、他のシステム・コンフィギュレーションも可能であることは認められよう。例えば、単一の共有商取引サーバ１３０と双方向処理を行う多数のウエブ・サーバ１２８（同じマシン上または異なるマシン上で走る）を備えることも可能であり、あるいは単一のウエブ・サーバ１２８と双方向処理を行う多数の商取引サーバ１３０を備えることも可能である。
Ｄ．商人ウエブ・サイトのソフトウエア・アーキテクチャ
図３は、コンピュータを用いたショッピング・システムの商人ウエブ・サイト３０２の好適なアーキテクチャを示す。図３に示すように、商人ウエブ・サイト３０２は、商人コンピュータ２０２、記憶装置３０４（機能的に図２の記憶装置１４４に対応する）、およびインターネット接続部３０６を含む。商人コンピュータ２０２上で動作するソフトウエアは、ウエブ・サーバ１２８、商取引サーバ１３０、および商取引サーバ・オブジェクトの集合を有するメソッド・ライブラリ３０８（図２のメソッド・ライブラリ２１２に対応する）を含む。ウエブ文書３１０の集合体を、種々の商人データベース３１２として、記憶装置３０４に記憶してある。
商人ウエブ・サイト３０２は、例えば、単一の商人に関して独立に情報を提供する単体のサイトでも、多くの異なる商人の情報を供給する中央または分散電子モール・システム（またはその一部）の形態でもよい。ウエブ・サーバ１２８は、Microsoft Internet Information Server 1.0が好ましいが、他の従来からのウエブ・サーバも使用可能である。商取引サーバ１３０は、ＩＳＡＰＩ（インターネット・サーバ・アプリケーション・プログラム・インターフェース）ＤＬＬ（動的リンク・ライブラリ）の形態で、ウエブ・サーバ１２８と同じプロセス空間内で走るようにすると好ましい。ＣＧＩスクリプトまたは他のサーバの拡張ＡＰＩ（ネットスケープのNSAPI等）を用いるＤＬＬも代わりに使用可能である。
商人ウエブ・サイト３０２上に記憶してあるウエブ文書３１０は、ＨＴＭＬを用いてコード化することが好ましい。ウエブ文書３１０は、ＨＴＭＬコード化を含み、ウエブ・ブラウザ１２０が受信すると、ウエブ文書のコンテンツから成るテキストまたは画像と共に、消費者コンピュータ１０２の画面１１４上に種々のアイコンまたはボタンを表示する。上述のように、これらのアイコンまたはボタンは、ショッピング関連トランザクションに対応する、選択可能なオプションを備えている。好適な実施形態では、ウエブ文書３１０は、製品情報を電子ショッピング・バスケットに追加したり、収集したが未だ購入していない製品を視認したり、既に購入した製品を視認したり、支払い情報を電子ウオレットに入力したり、電子住所録に送付先住所を記入したり、ウエブに拠点を持つ商人からの商品を注文するといった、消費者のオプションを提供する。これらウエブ文書３１０内にコード化した選択可能なオプションは、それらに関連付けた機能コール情報であり（前述のように）、選択すると、消費者コンピュータ１０２上実行可能な機能を呼び出すか、または遡ってウエブ・サーバ１２８上で実行可能な機能を呼び出す。埋め込みクライアント側機能コールを有するウエブ文書も、消費者コンピュータ１０２のハード・ディスク上に、商取引クライアント１３０のユーザ・インターフェースの一部として記憶しておき、オフラインの間にユーザがクライアント側機能（ショッピング・バスケットの視認等）を呼び出せるようにすることが好ましい。
商人ウエブ・サイトのメソッド・ライブラリ３０８は、製品情報の検索、販売税（sales tax）の計算、および注文の捕獲というようなクライアント・サービスを実行するためのメソッドを含む。これらの方法のいくつかを、表１に纏め、説明する。

商取引サーバ１３０は、２種類の主要なタスクを実行する。最初に、製品情報に対する要求を受信した場合（ウエブ・サーバ１２８が受信したＨＴＴＰ ＰＯＳＴメッセージ内に埋め込まれている機能コール情報により）、商取引サーバは、ＳＫＵ（stock keeping uni：在庫保持単位）番号、製品名、製品の説明、ロゴ、価格、有効期限、税金および送付費用のような、製品に関する種々のデータ項目を検索する。このデータは、形式“x-ishopper”のＭＩＭＥファイルとしてパッケージ化し、前述のように、ウエブ・ブラウザ１２０を通じて消費者コンピュータに返送する。第２に、商取引サーバ１３０は、消費者が提示した製品の注文を受け、処理する。
本発明によれば、システムの商人サイトは、View Shopping Basket（ショッピング・バスケットを見る），Show Wallet,（ウオレットを示す）およびInitiate Payment（支払いを開始する）のような、均一トランザクション・オプションを提示するＨＴＭＬウエブ文書３１０を用意し、供給する。
多種多様な在庫管理システムおよび旧来の（長期間存在し変更が難しい）製品情報データベース、ならびにアカウントを受信可能なシステムのために、商取引サーバは商人毎に変化するカスタムインターフェース・ソフトウエアを備えることが多い。本発明は、主に消費者プラットフォームに関するものである。
Ｅ．消費者コンピュータのソフトウエア・アーキテクチャ
図４は、消費者コンピュータ１０２のソフトウエア・アーキテクチャを示す。このアーキテクチャは、従来からのウエブ・ブラウザ１２０（マイクロソフトのInternet Explorer 2.0またはNetscape Navigator 2.0等）、商取引クライアント１２２、および商取引クライアント・オブジェクト・ライブラリ４０２、ならびに記憶エリア１１２を備えている。商取引クライアント・オブジェクト・ライブラリ４０２は、関連するショッピング・バスケット・メソッド４０６を有するショッピング・バスケット・オブジェクト４０４、関連するウオレット・メソッド４１０を有するウオレット・オブジェクト４０８、および関連する住所録メソッド４１４を有する住所録オブジェクト４１２を備えている。記憶エリア１１２は、商人情報４１６、製品情報４１８、支払い源データ１４０、および送付先住所データ１４２を備え、これらは全て、ユーザが選択的に記憶したか、あるいは手作業で入力したものである。
ウエブ・ブラウザ１２０は、商取引クライアント１２２がＭＩＭＥハンドラ・アプリケーションであるように構成することが好ましい。一般的に、ＭＩＭＥハンドラとは、ウエブ・ブラウザ１２０がインターネットを通じて受信する特定形式のファイルの特殊処理を行うように設計した、ソフトウエア・アプリケーションのことである。本発明のウエブ・ブラウザ１２０は、ＭＩＭＥ形式“x-ishopper”を“ish.”のようなある種のファイル名拡張子と関連付けるように構成してある。ウエブ・ブラウザ１２０が形式“x-ishopper”のファイルを受信すると、ウエブ・ブラウザは、商取引クライアント１２２のアプリケーションに、実行を開始させる（未だ走っていない場合）。次に、ウエブ・ブラウザは、受信した“x-ishopper”ファイルを商取引クライアント１２２に受け渡し、更に処理を進める。特定のファイル形式をファイル名拡張子と関連付けるようにウエブ・ブラウザを構成し、更に特殊なＭＩＭＥハンドラ・アプリケーションをファイル名拡張子と関連付けることによって、ウエブ・ブラウザのファンクショナリティを拡張することは周知であり、ここではこれ以上論じないことにする。
商取引クライアント１２２は、消費者コンピュータ１０２上で、ウエブ・ブラウザ１２０からの別個のプロセスとして実行するものであり、標準的な実行可能プログラムである。商取引クライアント１２２は、ＭＩＭＥ形式“x-ishopper”のファイルをウエブ・ブラウザが受信したときに、ウエブ・ブラウザ１２０が起動し、実行を開始する。商取引クライアント１２２が実行を開始する別の場合は、ローカル・ポート・リスナ・タスクが、ウエブ・ブラウザ１２０からローカル・ポートに送達したメッセージを受信したときである。ポート・リスナは、商取引クライアント１２２が未だ実行していない場合、これを起動する。
商取引クライアント１２２を起動する更に他の方法は、商取引クライアント・プログラムを直接走らせることによるものである。以下で更に詳しく説明するが、商取引クライアント１２２の多くの機能（「ローカル」機能）は、インターネット接続も、ウエブ・サイト間のデータ伝送も必要としない。これらのローカル機能は、消費者コンピュータのハード・ディスク上に位置する、ユーザ−インターフェースＨＴＭＬ文書を通じて使用可能である。商取引クライアント１２２の実行は、消費者があるオプションを選択したことにより商取引クライアント１２２に実行を中止させるまで続けられる。
商取引クライアント１２２が走り始めると、ハード・ディスクまたはその他の固定記憶媒体上に記憶してあるデータから、メモリ内に構造をロードするという最初のタスクを実行する。このデータは、商人情報、製品情報、支払い源情報、および送付先住所を表す。これらのデータは、データ間の関係（リンク）を維持しつつ容易にメモリに読み込めるように記憶する。このようなハード・ディスク上に記憶してあるデータから、相互リンクしたメモリ内構造を構築することは当技術分野では周知である。商取引クライアント１２２が動作中止するかまたはそれ以外で正常に終了した場合、データ間の関係を全て保存するように、相互リンクメモリ内構造をハード・ディスク記憶装置に書き込む。
メモリ内データ構造を構成するデータのアクセスおよび操作は、オブジェクトを通じて行う。ショッピング・バスケット・オブジェクト４０４は、ショッピング・バスケット・メソッド４０６と関連付けてあり、消費者に興味のある商人および／または製品に関する情報の読み取り、書き込み、変更、および表示を行う。ショッピング・バスケット・メソッド４０６は、主に製品情報および商人情報から成るメモリ内構造との双方向処理を行う。本発明によれば、各製品毎のデータは、表２に示すように、グループに組織化することが好ましい。

製品に関連するプロパティには、当該製品に対して一意であり、他の製品には関連付けていない種々のものがあり得る。このようなプロパティは、メモリ内に名称／値の対で表現してあり、このようなプロパティのリンク・リストに対して関連付けてあるポインタによって、メモリ内製品構造から参照することができる。プロパティ・データは、表３に示すように組織化してある。

商人データは、表４に示すように、関連する欄を備えることが好ましい。

ウオレット・オブジェクト４０８は、オンラインで購入する場合に用いる支払い源データ（クレジット・カード番号および当座預金口座番号）にアクセスするウオレット・メソッド４１０と関連付けてある。支払い源データは、好ましくは、表５に示すように関連付けた欄にしたがって、メモリに記憶する。

住所録オブジェクト４１２は、送付の目的のためにアドレス情報にアクセスする住所録メソッド４１４に関連付けてある。住所録メソッド４１４は、好ましくは表６に示すように組織化した住所データにアクセスする。

ショッピング・バスケット・オブジェクト４０４、ウオレット・オブジェクト４０８、および住所録オブジェクト４１２は、単一のＤＬＬ（ダイナミック・リンク・ライブラリ）として実施する、プロセス内ＣＯＭ（コンポーネント・オブジェクト・モデル）に準拠したオブジェクトとして実施することが好ましい。コンポーネント・オブジェクト・モデルは当技術分野では周知であるので、これ以上論じない。しかしながら、ショッピング・バスケット・オブジェクト４０４、ウオレット・オブジェクト４０８、および住所録オブジェクト４１２、ならびにそれらに関連付けた各メソッド４０６，４１０，４１４の代わりに、適切な関連データ構造を有するコール可能な機能も使用可能であることを当業者は認めよう。
図５は、概略的に、商取引クライアントの主要オブジェクトがアクセスするデータの形式を示す。ショッピング・バスケット・オブジェクト５０２は、商人データ構造５０４、製品データ構造５０６、および製品プロパティ・データ構造５０８にアクセスしこれらを操作する。ウオレット・オブジェクト５１０は、支払い源データ構造５１２にアクセスしこれを操作する。住所録オブジェクト５１４は住所録データ構造５１６にアクセスしこれを操作する。
前述のように、商取引クライアント１２０は、ウエブ・ブラウザ１２０を通じて、ウエブ・サーバ１２８から受け渡される形式“x-ishopper”のＭＩＭＥファイルに埋め込んである種々の機能コール情報に応答し、更に、ウエブ・ブラウザが商取引クライアント１２２に宛てたデータを送達するローカル・ポートを介して、ウエブ・ブラウザ１２０から間接的に受信した機能コール情報にも応答する。機能コール情報は、商取引クライアント１２２が呼び出すオブジェクトおよびメソッドを識別する。
例えば、製品を説明し（品目のホストとなる）、本発明にしたがってコード化したウエブ文書３１０を見る場合、標準的なウエブ・ブラウザは、消費者にＡＤＤ ＩＴＥＭ（品目追加）型オプションを表示する。これは、製品に関する情報を電子ショッピング・バスケット（コンピュータ・メモリ内、最終的にはハード・ディスクに書き込む）に記憶させる。ＡＤＤ ＩＴＥＭオプションは、例えば、消費者が製品に興味を持ったときに、当該製品を購入する決心が未だついていない場合でも、選択することができる。また、ウエブ文書３１０は、典型的に、消費者のコンピュータ画面に表示する製品の形態も含む。製品形態は、多数の属性を表し、消費者が値を記入することによって設定することができる。属性を好みに応じて設定した後（例えば、製品のサイズまたは色を選択する）、消費者はＡＤＤ ＩＴＥＭオプションを選択し、このような「ユーザ好みの」属性を、商人が提供した情報と共に記憶させる。
図６は、消費者がＡＤＤ ＩＴＥＭオプションを選択する場合に実行するステップを示す。最初のステップ６０２において、ウエブ・ブラウザ１２０はＨＴＴＰ ＰＯＳＴメッセージをウエブ・サーバ１２８に発行し、消費者がＡＤＤ ＩＴＥＭオプションを選択したことを示す。次のステップ６０４において、ウエブ・サーバ１２８は、商人ウエブ・サイトから製品情報を検索し、その情報を、形式“x-ishopper”のＭＩＭＥメッセージとして、ウエブ・ブラウザ１２０に送る。次に、ステップ６０６において、ウエブ・ブラウザ１２０は、形式x-ishopperのＭＩＭＥメッセージの受信を確保した後、商取引クライアント１２２を起動する（未だ走っていない場合）。商取引クライアントは、ステップ６０８において、ハード・ディスクから読み取った商人、製品、支払いおよび住所データのメモリ内表現を構築する。次に、ステップ６１０において、ウエブ・ブラウザ１２０はＭＩＭＥメッセージを商取引クライアント１２２に受け渡す。
商取引クライアント１２２は、受け渡されたＭＩＭＥメッセージに埋め込んである機能コール情報を用いてメソッドAddLineItemをコールする。ステップ６１２において、AddLineItemメソッドは、メモリ構造（ステップ６０８において構築した）をナビゲートし、ＭＩＭＥメッセージによって受け渡された商人名に一致する名称欄を有する商人データ構造を探す。ステップ６１２においてこのような商人構造が見つからない場合、メモリを割り当てることにより、商人のリンク・リストに新たな商人構造を添付し、新たなデータ構造に、受け渡されたＭＩＭＥメッセージからの商人データを移植する（populate）。次に、ステップ６１４においてAddLineItemメソッドは、当該商人構造（ステップ６１２において見つけたかあるいは作成した）に関連する製品データ構造のリンク・リストをナビゲートする。リスト内の各製品データ構造は、商人が販売に提供する１つの製品を表す。ステップ６１６において、AddLineItemメソッドは、新たな製品データ構造にメモリを割り当て、製品のＳＫＵ、価格、数量、説明、名称、ロゴ、色、またはサイズのような、ＭＩＭＥメッセージにパッケージ化してあるデータをそれに移植する。次に、AddLineItemメソッドは、新たな製品データ構造を、当該商人のためのリンク製品データ構造の終端にリンクする。
ステップ６１８において、商取引クライアント１２２はSetItemPropertyメソッドを呼び出し、受け渡された商人名と一致する商人名を有する商人構造を見つけるまで、商人構造のリンク・リストを再度ナビゲートする。ステップ６２０において、ＭＩＭＥメッセージ内で受け渡されたＳＫＵ番号と等価のＳＫＵ欄を有する製品データ構造を見つけるまで、商人構造と関係する（referenced）製品データ構造をナビゲートする。次に、ステップ６２２において、SetItemPropertyメソッドが、見つけた製品データ構造と関係するプロパティのリンク・リストをナビゲートし、ＭＩＭＥメッセージ内で受け渡された各プロパティ毎に繰り返す。受け渡されたプロパティ名と名称が一致するプロパティ構造を見つけたなら、一致したプロパティ名に関連する値を、そのプロパティ名と共に受け渡された値と置換する。プロパティ・リストをナビゲートし、一致するプロパティ名が見つからない各場合毎に、SetItemPropertyメソッドは、新たなプロパティ・データ構造をプロパティのリンク・リストに添付していく。SetItemPropertyメソッドは、新たなプロパティ・データ構造にメモリを割り当て、受け渡されたＭＩＭＥメッセージ内のデータから適宜名称欄、値欄およびフラグ欄に記入していく。
ステップ６２４において、商取引クライアント１２２は次に、以下で述べるＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴ（ショッピング・バスケット視認）を構成するステップを実行する。こうして、ＡＤＤ ＩＴＥＭオプションを構成するステップが完了すると、ＳＫＵ、価格、数量、画像、説明、参照ＵＲＬ、および商人情報というようなデータ欄から成る、新たな製品データ構造は既にメモリ内に記憶されている。また、サイズ、色、または終了というような、製品に関連するいずれの特殊プロパティも、新たな製品データ構造に記憶する。以下で説明するが、デフォルトの支払い源情報およびデフォルトの送付先住所情報も、新たな製品データ構造に関連付ける。
商人ウエブ・サイトが提供するウエブ文書３１０および／または消費者コンピュータ１０２内部に記憶させてあるウエブ文書３１０は、ＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴと称する選択可能なオープションを消費者に提供する。このオプションは、消費者がＡＤＤ ＩＴＥＭオプションを用いて、電子ショッピング・バスケット内に入れてある全ての製品のリストを検索することを可能にする。
図７は、ＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴオプションを実行する際のステップを示す。最初のステップ７０２において、消費者は、ウエブ・ブラウザ内部からＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴオプションを選択する。次のステップ７０４において、ウエブ・ブラウザ１２０はローカル機能コールを発行する。次に、ステップ７０６において、ローカル・ポート・モニタがローカル機能コールを検出することによって、商取引クライアント１２２を起動する（未だ実行していない場合）。次に、ステップ７０８において、商取引クライアント１２２は、ショッピング・バスケットＣＯＭオブジェクトをロードする。次のステップ７１０において、変数CheckFlagを０に等しくセットする。次いで、ステップ７１２において、ループに入り、各商人データ構造毎に１回実行する。
ステップ７１４において、商取引クライアント１２２はGetFirstItemメソッドを呼び出す。ステップ７１４において、GetFirstItemメソッドは所与の商人にナビゲートする。このループの最初の繰り返しでは、所与の商人は、単に商人データ構造リスト内の最初の商人となる。ステップ７１６において、最初の商人データ構造から関係付けられた製品データ構造のリンク・リストを、最初の製品データ構造までナビゲートする。ステップ７１８において、この商人に対する製品データ構造がないと判定したか、あるいは製品データ構造リストのナビゲーションでリストの終端に到達した場合、ステップ７２０においてGetFirstItemメソッドは０の値を返す。ステップ７１８において、別の製品データ構造が存在し、製品データ構造リストの終端に未だ到達していないことを判定した場合、製品データ構造のフラグ欄を、CheckFlag変数と比較する。CheckFlagは０に等しいので、製品フラグを値０と比較することになり、製品の購入が未だ行われていないことを示す。ステップ７２２において、製品フラグがCheckFlagに等しくないと判定した場合、処理はステップ７１６に逆戻りし、リスト内の次の製品データ構造をチェックする。しかしながら、ステップ７２２において、製品フラグがCheckFlagに等しく、製品の購入が未だ行われていないことを示す場合、次いでステップ７２４において、未だ購入が行われていない製品の製品データ構造を指し示すポインタを返し、未だ購入が行われていない製品の名称をリスト・ボックス構造に追加する。次に、ステップ７２６において、この製品データ構造へのポインタをセーブし、ループの繰り返しを終了する。
ステップ７２８において、GetNextItemメソッドを呼び出す。これは、初めに所与の商人までナビゲートする。ステップ７３０において、現在のリンク製品データ構造のチェーンを、セーブしたポインタの位置に等しい点までナビゲートする（このGetNextItemの呼び出しがGetFirstItemメソッドの終了直後である場合、ステップ７２６においてセーブしたポインタ位置。その他の場合、ステップ７２４においてセーブしたポインタ位置を用いる）。次に、ステップ７３２において、リンク・リスト内の次の製品データ構造を検査する。ステップ７３４において、製品データ構造リストの終端に到達したことを判定した場合、次にステップ７３６において０を返す。しかしながら、ステップ７３４において、製品データ構造リストの終端に未だ到達していないことを判定した場合、ステップ７３８において、製品フラグをCheckFlagと比較する。ステップ７３８において、製品フラグがCheckFlagに等しくない場合、ステップ７３２における処理を再開し、リスト内の次の製品データ構造を検査する。しかしながら、ステップ７３８において、製品フラグがCheckFlagに等しい場合、次いでステップ７４０において、この製品データ構造にポインタを戻し、この製品の名称をリスト・ボックス構造に追加する。次に、ステップ７４２において、製品データ構造へのポインタをセーブする。次いで、GetNextItemメソッドを呼び出し、再びステップ７２８から開始し、商人データ構造のリストを現商人までナビゲートし、商人データ構造の終端に到達するまで、ステップ７２８ないし７４２を繰り返す。
ステップ７４４において、商人データ構造リストの終端に到達したなら、次にステップ７４６において、スクロール可能な製品名リストが消費者のコンピュータ画面に現れる。製品名リストは、現在電子ショッピング・バスケットにあるが未購入の全製品に対応する。
また、ウエブ文書３１０は消費者にＶＩＥＷ ＨＩＳＴＯＲＹ（履歴視認）オプションも提供する。ＶＩＥＷ ＨＩＳＴＯＲＹを選択することにより、既に購入済みの製品名リストをユーザ・コンピュータ上に表示する。一実施形態では、図７に示すＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴオプションに関係するステップは、１つの例外を除いて、ＶＩＥＷ ＨＩＳＴＯＲＹオプションに関して全て実行する。ＶＩＥＷ ＨＩＳＴＯＲＹオプションを実行する際、ステップ７１０において、CheckFlag変数は、０の代わりに、１に等しくセットする。このように変更すると、前述のステップは、フラグが１にセットされており、既に購入済みであることを示す製品データ構造全てを検出することになる。したがって、図７のステップは、既に購入済みの製品の全てを反映する製品名リストを構築する。
別の実施形態では、ＶＩＥＷ ＨＩＳＴＯＲＹオプションを選択することにより、全ての製品注文リストを表示する。各商人構造は、注文構造リストに対して参照ポインタを有する。各注文構造は、支払い、送付、および注文追跡情報の欄を有することに加えて、製品構造リストに対する参照ポインタも有する。これによって、商人のリンク・リストを精査（traverse）する。各商人毎に、各商人の注文構造リストを精査する。各注文構造から、１つの表示項目を生成する。各表示項目は、ユーザ・コンピュータの画面上に、購入日付、支払い情報、送付先住所、注文追跡識別子、および注文した製品を表示する。尚、注文した製品を判定するには、各注文構造と関連のある製品構造のリンク・リストを精査することを注記しておく。ＶＩＥＷ ＨＩＳＴＯＲＹオプションは、過去の購入に関して、このような購入はつい最近行ったのかあるいは何年も前に行ったのかについての調査を、消費者に可能とするという利点がある。
ＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴオプションおよびＶＩＥＷ ＨＩＳＴＯＲＹオプションは、動作のために、インターネットへの接続を必要としない。加えて、これらの機能はオプションとして、ウエブ・ブラウザを用いずに呼び出すことができる。ウエブ・ブラウザ１２０なくしてこれらの機能を実行するには、消費者は、例えば、マウスを用い、消費者コンピュータ１０２のグラフィカル・ユーザ・インターフェース上にあるアイコン（商取引クライアント１２２の実行可能なプログラムを関連付けてあるアイコン）をダブル・クリックすることによって、商取引クライアント１２２の実行を開始させる。商取引クライアントのユーザ・インターフェースは、消費者に、インターネットへの接続を必要としないオプションの選択を提供する。これらのオプションについて、ウエブを用いた通信を必要とするオプションからこれらを区別するために、以下に注記しておく。
また、本システムのウエブ文書３１０は、ある品目を電子ショッピング・バスケットから除去するＤＥＬＥＴＥ ＩＴＥＭ（品目削除）オプションのホストになることも可能である。図８は、ＤＥＬＥＴＥ ＩＴＥＭオプションを実行する際に実行するステップを示す。最初のステップ８０２において、消費者がＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴオプションを選択すると、収集したが購入していない製品のリストを提示する。次いで、ＤＥＬＥＴＥ ＩＴＥＭオプションを提示する。
次のステップ８０４において、消費者はリストからある製品名を選択する。次に、ステップ８０６において、消費者はＤＥＬＥＴＥ ＩＴＥＭボタンを選択するか、あるいはキーボードの削除キーを押下する。すると、ステップ８０８において、消費者は削除を確認するように催促を受ける。ステップ８０８において消費者が削除を確認しない場合、ステップ８１０において、図８のステップは終了する。しかしながら、ステップ８０８において、消費者が削除を確認した場合、DeleteLineItemメソッドを呼び出す。
次に、ステップ８１２において、選択した製品の製品データ構造へのポインタを用いて、リンク・リスト内の直前の製品データ構造を突き止める。リンク・リスト内で直前の構造を突き止めるには、このリストを二重リンク・リスト（構造が直前の構造だけでなく次の構造を双方共指し示すリスト）として実施することが好ましい。直前の製品データ構造がない場合、即ち、選択した製品の製品データ構造が、商人データ構造と関係するこのような製品データ構造リストにおける先頭であるという可能性がある。いずれの場合にせよ、製品データ構造へのポインタを突き止める。これは、直前の製品データ構造ではなく、単に商人データ構造に属する。
ステップ８１４において、選択した製品の製品データ構造と同じポインタを用いて、次の製品データ構造（即ち、選択した製品に対応する製品データ構造に続く構造）を突き止める。次の製品データ構造がない可能性、言い換えると、選択した製品の製品データ構造が次の製品データ構造に対してＮＵＬＬポインタを有するという可能性がある。
最後に、ステップ８１６において、ステップ８１２で突き止めたポインタ（即ち、選択した製品の製品データ構造を指し示すポインタ）を、選択した製品の製品データ構造に続く製品データ構造を指し示すようにセットする。選択した製品の製品データ構造に続く製品データ構造がない場合、ステップ８１２で突き止めたポインタを単にＮＵＬＬにセットする。したがって、選択した製品の製品データ構造は、メモリ内データ構造とは無関係となり（リンク解除する）、事実上削除したことになる。ＤＥＬＥＴＥ ＩＴＥＭオプションは、商取引クライアントのユーザ・インターフェースを通じて、およびウエブ・ブラウザ１２０が表示するウエブ文書上で消費者に提供する。
ＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴオプションの選択に続いて消費者に提示する別のオプションは、ＳＥＥ ＩＴＥＭ ＤＥＴＡＩＬＳ（品目詳細を見る）オプションである。ＳＥＥ ＩＴＥＭ ＤＥＴＡＩＬＳオプションは、消費者が、製品の一意のプロパティの値（例えば、選択した色またはサイズ）、購入に関して用いる支払い源、および注文した場合に、製品を送付するアドレスをもチェックすることを可能にする。
図９は、ＳＥＥ ＩＴＥＭ ＤＥＴＡＩＬＳオプションに関して実行するステップを示す。最初に、ステップ９０２において、消費者がＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴボタンを選択すると、製品リストを提示する。次のステップ９０４において、消費者はリストからある製品名を選択する。次に、ステップ９０６において、消費者はＳＥＥ ＩＴＥＭ ＤＥＴＡＩＬＳボタンを選択する。
次に、ステップ９０８において、ウエブ・ブラウザ１２０は、ローカル・ポートを対象としたローカルＨＴＴＰ ＰＯＳＴメッセージを送る。ステップ９１０においてポート・リスナはこのメッセージに応答し、ステップ９１２においてメッセージを商取引クライアント１２２に送出する。
ステップ９１４において、商取引クライアント１２２は、選択した製品の製品データ構造へのポインタを都合よく用い（このポインタは、ＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴオプションとの関連で、製品の選択以降維持してある）、選択した製品の製品データ構造を突き止める。次に、ステップ９１６において、唯一のエントリとして、支払い源の愛称（Friendly Name）（即ち、製品データ構造のPaymentFriendlyName欄と関連する値）を有するドロップ−ダウン・ボックス（drop-down box）を作成する。同様に、ステップ９１８において、唯一のエントリとして、送付先住所の愛称（即ち、製品データ構造のAddressFriendlyName欄と関連する値）を有する第２のドロップ−ダウン・ボックスを作成する。
次に、メソッドGetFirstProperty９２２を呼び出し、ステップ９２０においてGetFirstPropertyメソッドは、選択した製品の製品データ構造と関連するプロパティ・リスト・ポインタの内容を検査し、製品データ構造と関係するプロパティ・データ構造のリンク・リストにおける最初のプロパティ・データ構造を突き止める。
次に、ステップ９２６において、メソッドGetNextProperty９２４を繰り返しコールして、プロパティ・データ構造のリンク・リストをナビゲートする。ステップ９２８において、プロパティ・データ構造のリンク・リストをナビゲートしている際に発見した各プロパティ名／プロパティ値の対毎にエントリを有するリスト・ボックスを作成する。
ステップ９３０において、GetPaymentFirstFriendlyNameメソッド９３２を呼び出し、リンクした支払源構造へのルート・ポインタを検査し、最初の支払い源構造の愛称の値を返す。愛称とは、以下で論ずるが、支払い源を指定する際に使用すると便利な、“Bob’s Visa Card”（ボブのビザ・カード）というような単なる名称である。ステップ９３４において、GetPaymentNextFriendlyNameメソッド９３６を用いて、支払い源構造のリンク・リストをナビゲートし、ステップ９１６において既に作成してあるドロップ−ダウン・ボックス内に各々の愛称を入れる。
次のステップ９３８において、GetAddressFirstFriendlyNameメソッド９４０を呼び出し、リンクした送付先住所構造へのルート・ポインタを検査し、最初の送付先住所構造の愛称の値を返す。愛称は、住所に関して用いる場合、送付先住所を指定する際に使用すると便利な、「事務所」または“Debbie’s house”（デビーの家）というような名称である。ステップ９４２において、GetAddressNextFriendNameメソッド９４４を用いて、送付先住所構造のリンク・リストをナビゲートし、ステップ９１８において既に作成してあるドロップ−ダウン・ボックスに各々の愛称を入れる。
このように、消費者は、全てのプロパティのリスト（スクロール可能なリスト・ボックスとして消費者のコンピュータ１０２の画面上に表示してある）、および選択した製品に関連するそれらの対応する値を閲覧することができ、必要であればプロパティの値を変更することができる。また、消費者は、消費者コンピュータ１０２上に表示している２つのドロップ−ダウン・ボックスのいずれかから選択し、製品を購入する際に用いる支払い源を変更したり、あるいは購入する場合の製品配達のための送付先住所を変更することも可能である。
ステップ９４６において、消費者に選択ボックスを表示し、ＯＫまたはＣＡＮＣＥＬの選択肢を提供する。ステップ９４８において、消費者がＣＡＮＣＥＬを選択したと判定した場合、ステップ９５０において、消費者のコンピュータからリスト・ボックスおよび２つのドロップ−ダウン・ボックスを消去し、図９のステップを終了する。しかしながら、ステップ９４８において、消費者がＯＫを選択した場合、ステップ９５２において、SetItemPropertyメソッド９５４を呼び出し、消費者が変更したプロパティの値を置換し、支払い源または送付先住所に対する愛称のいずれかを消費者が変更した場合には、これも置換する。商取引クライアントのユーザ・インターフェースおよびウエブ文書上に、ＳＥＥ ＩＴＥＭ ＤＥＴＡＩＬＳオプションを提示する。
支払い源情報を管理するために、本発明は、消費者が電子ウオレットの内容を視認し変更することも許している。ウエブ文書は、オプションＶＩＥＷ ＷＡＬＬＥＴ（ウオレットの視認）のホストとなり（消費者に与える）、ウオレットに関係する機能を呼び出す埋め込み機能コール情報を含む。ウエブ・ブラウザ１２０は、ローカルの消費者コンピュータ１０２に宛てたＨＴＴＰ ＰＯＳＴメッセージを生成すること、およびポート・リスナ・プロセスがこのメッセージを受信し、それを商取引クライアント１２２に受け渡すと共に、必要であれば商取引クライアントの起動（実行）も行うことは理解されよう。
図１０は、支払い源データの視認および操作との関連で実行するステップを示す。最初のステップ１００２において、消費者はＶＩＥＷ ＷＡＬＬＥＴオプションを選択する。次に、ステップ１００４において、商取引クライアント１２２は、ポート・リスナから機能コール情報を既に受信しており、ウオレット・オブジェクトをロードする。ステップ１００６において、GetPaymentFirstFriendlyNameメソッド１００８を呼び出し、維持してあるルート・ポインタ（支払い源データ構造のリンク・リストにおける先頭へのポインタ）を検査し、最初の支払い源データ構造と関連する愛称の値を判定する。この最初の愛称は、リスト・ボックス内の最初のエントリとして用いる。次に、ステップ１０１０において、GetPaymentNextFriendlyNameメソッド１０１２を呼び出し、支払い源データ構造のリンク・リストを精査し、各々と関連する愛称をエントリとしてリスト・ボックス内に入れる。
ステップ１０１４において、消費者に閲覧可能なリスト・ボックスを表示し、支払い源に割り当てられている愛称を全て掲示する。次のステップ１０１６において、支払い源の１つをＭＡＫＥ ＰＲＥＦＥＲＲＥＤ（優先的に使用する）（デフォルトとして確定する）オプションとして、支払い源のＡＤＤ（追加），ＥＤＩＴ（編集），ＤＥＬＥＴＥ（削除）を行うためのオプションを消費者に提示する。
ステップ１０１６において、消費者が支払い源のＡＤＤオプションを選択した場合、ステップ１０１８において、支払い源情報に対応する空白の欄または不完全な欄を有するダイアログ・ボックスを表示する。これらの欄は、クレジット・カード番号、発行元銀行、有効期限、カード上の氏名、愛称、および請求先住所のような情報を引き出すように設計してある。消費者は、クレジット・カード、支払いカードまたは他のいずれかの現金代用物（cash substitute）に対応する情報を入力することができる。次に、ステップ１０２０において、消費者は欄に記入し、消費者が入力した情報を電子ウオレット内に保持することを望む場合、ステップ１０２２において確認のためパスワードを２回入力するようにユーザに催促する。パスワードを２回正しくタイプした場合、ステップ１０２４において、このパスワードを用いて、入力された支払い源データを暗号化し、消費者が入力し暗号化しない愛称と関連付けて、暗号化したデータを記憶する。次いで、消費者はウオレットの視認を終了するか、あるいは支払い源データの操作を更に続けることができる。
ステップ１０１６において、消費者が支払い源データのＥＤＩＴを選択した場合、支払い源データに対応する愛称を選択する際、ステップ１０２６において消費者にパスワードを入力するように催促する。パスワードが正しい場合、これを用いて、選択した愛称と関連する暗号化支払い源情報を解読する。ステップ１０２８において、ダイアログ・ボックス内に、解読した支払い源情報を消費者に提示する。データは、消費者が編集するために、複数の欄に分解してある。
ステップ１０３０において、消費者はデータ欄を修正する。消費者が支払い源情報の更新を終了したなら、ステップ１０３２においてパスワードを２回入力するように消費者に催促する。このパスワードは、支払い源データにアクセスするために先に入力したパスワードとは異なっていてもよい。パスワードの入力が適正であれば、更新した支払い源データを暗号化し、愛称（暗号化していない）と関連付けて記憶する。消費者コンピュータ１０２のレベルでのパスワード保護は、本発明の利点の１つであり、クレジット・カード番号およびその他の金銭情報へのアクセスを有する人は唯一人であることを保証する。
ステップ１０１６において、消費者は支払い源データのＤＥＬＥＴＥを選択することも可能である。ステップ１０１４のリスト・ボックスから、削除する支払い源データに対応する愛称を選択し、更に支払い源ＤＥＬＥＴＥオプションを選択すると、ステップ１０３６において削除要求を確認するように、消費者に要求する。消費者が削除を確認すると、ステップ１０３８において、選択した愛称と関連する支払い源データを、支払い源データ構造のリンク・リストから除去する。削除ステップにパスワードの催促を追加し、望ましくない削除に対する保護も可能であることは、当業者には認められよう。
また、ステップ１０１６は、支払い源の１つについてＭＡＫＥ ＰＲＥＦＥＲＲＥＤを実行するオプションも提供する。ある支払い源を優先すると、その愛称を、電子ショッピング・バスケットに追加する製品情報とデフォルトで関連付けることになる。一般的に、優先する支払い源とは、頻繁に使用するクレジット・カード口座であり、恐らく利息が非常に有利であるか、あるいは支払いを行う毎に航空会社の無料搭乗マイルの加算（airline frequent flyer miles）をカード所持者に与えるというようなものであろう。ステップ１０１６において、消費者がステップ１０１４のリスト・ボックスから愛称を選択し、次いでＭＡＫＥ ＰＲＥＦＥＲＲＥＤを選択すると、ステップ１０４０において、選択した愛称をデフォルトの支払い源と関連付ける。ＭＡＫＥ ＰＲＥＦＥＲＲＥＤステップに確認チェックを追加し、以前のデフォルト支払源を誤って置換してしまう事態の回避も可能であることを、当業者は理解しよう。消費者が支払い源データの視認および操作を終了すると、ユーザは、ＥＸＩＴ（または同様の名称を付した）ボタンを選択することにより、ＶＩＥＷ ＷＡＬＬＥＴオプションおよび画面表示を終了させる。
本発明が電子ウオレットにおける支払い源データの視認および操作を簡便化する態様に酷似しているのが、電子住所録における送付先住所データの視認および操作を消費者に許可する際の本発明の態様である。図１１は、住所録データを視認または操作する際のステップを示す。最初のステップ１１０２において、消費者はＶＩＥＷ ＡＤＤＲＥＳＳ ＢＯＯＫオプションを選択する。次のステップ１１０４において、商取引クライアント１２２は住所録オブジェクトをロードする。
ステップ１１０６において、GetAddressFirstFriendlyNameメソッド１１０８は、維持してあるルート・ポインタ（常に送付先住所データ構造のリンク・リストの先頭を指し示す）を用いて、最初の送付先住所データ構造を検査し、関連する愛称を返す。送付先住所に対する愛称は、例えば、“My Castle”（私の城）、または“Jill’s Office”（ジルの事務所）というようなものも考えられる。最初の送付先住所データ構造と関連する愛称は、閲覧可能なリスト・ボックスにおける最初のエントリとして用いる。
次に、ステップ１１１０において、GetAddressNextFriendlyNameメソッド１１１２を用いて、送付先住所データ構造のリンク・リストを精査し、ステップ１１０６において作成したリスト・ボックス内に、各構造と関連する愛称を含ませる。ステップ１１１４において、リスト・ボックスを消費者に表示する。ステップ１１１６において、送付先住所のＡＤＤ、ＥＤＩＴ、ＤＥＬＥＴＥおよびＭＡＫＥ ＰＲＥＦＥＲＲＥＤを実行するオプションを消費者に提示する。
ステップ１１１６において、消費者が送付先住所データのＡＤＤを選択した場合、ステップ１１１８において、道路名（street address）、都市、州、国、郵便番号、氏名および愛称というような送付先住所データに対応する空白欄または不完全な欄を含むダイアログ・ボックスを消費者に表示する。次のステップ１１２０において、消費者は情報を欄に入力する。情報が完全であり正確であることに消費者が満足したなら、消費者はステップ１１２２においてＯＫボタンを選択すると、新たな送付先住所を新たに入力した愛称と関連付けてセーブする。
電子ウオレットの場合と同様、消費者は、電子住所録内のデータのＥＤＩＴを実行することも選択可能である。機密性に対する要望はさほど多くないので、送付先住所データについてはパスワードのアクセスや暗号化を行わない。支払い源データに関して指定したように、送付先住所データについてもパスワードによるアクセス保護を実施可能であることを当業者は理解しよう。消費者が送付先住所データのＥＤＩＴを選択した場合、ステップ１１１４において表示した閲覧可能なリストから愛称を選択した後、選択した愛称に関連する既存のデータに対応する、入力データ項目（fielded data items）を提示するダイアログ・ボックスをステップ１１２４において表示する。ステップ１１２６において、消費者は既存の送付先住所データを修正する。変更が完了したことに満足したなら、ステップ１１２８において消費者はＯＫボタンを選択する。これにより、愛称（ユーザが変更したばかりである場合もある）に関連付けて、変更した送付先住所情報をセーブすることになる。
ステップ１１１６において、消費者が送付先住所データのＤＥＬＥＴＥを選択した場合、ある送付先住所に対応する愛称を選択した後に、ステップ１１３０において削除要求を確認するようにユーザに催促する。ステップ１１３０で消費者が削除要求を確認したなら、ステップ１１３２において送付先住所データを愛称と共に削除する。
ステップ１１１６において送付先住所のＭＡＫＥ ＰＲＥＦＥＲＲＥＤを実行するオプションを選択した場合、ステップ１１３４において、選択した愛称と関連する送付先住所データを、デフォルトの送付先住所と関連付ける。その後、電子ショッピング・バッグに入れてあるあらゆる製品が、新たな送付先住所との関連をデフォルトとして自動的に獲得する。送付先住所データの削除に関して、ステップ１１３０におけるような確認ステップを追加し、デフォルトの送付先住所に対する意図しない修正に対して保護することも可能であることを当業者は認めよう。ＶＩＥＷ ＷＡＬＬＥＴオプションおよびＶＩＥＷ ＡＤＤＲＥＳＳ ＢＯＯＫオプションは双方共、商取引クライアントのユーザ・インターフェースから利用することができることを注記しておく。
電子ウオレット内の支払い源情報および電子住所録内の送付先住所情報によって、本発明は、消費者が電子ショッピング・バスケット内の製品を購入することを可能にする。ウエブ文書は、ＲＥＡＤＹ ＴＯ ＢＵＹ（購入の用意あり）オプションのホストとなる。
図１２は、製品を購入する際のステップを示す。ステップ１２０２において、消費者はＲＥＡＤＹ ＴＯ ＢＵＹオプションを選択する。次に、ステップ１２０４において、ショッピング・バスケット・オブジェクトをロードする。次いで、ステップ１２０６において、GetFirstItemメソッド１２０８を用いて、維持してある最初の商人データ構造へのルート・ポインタを検査し、次いで最初の商人と関連する製品データ構造のリンク・リストを横断して検査し、最初に突き止めた未購入製品を返す。各製品データ構造のFlagを検査し、当該製品が既に購入済みか否かについて判定を行う。最初の商人データ構造との関連では未購入の製品が見つからなかった場合、GetFirstItemは、商人のリンク・リスト内の次の商人構造に移動する。GetFirstItemメソッドは、その商人構造および製品構造の精査において発見した未購入製品と関連する最初の製品構造を識別する情報（ポインタ等）を返す。
次のステップ１２１０において、GetNextItemメソッド１２１２を用いて、商人構造および製品構造の精査を完了し、未購入製品に関連する全ての製品構造を識別する情報を返す。ステップ１２１４において、全ての未購入製品のリストを生成し、次いで商人およびPaymentFriendlyNameによってソートする。次に、ステップ１２１６において、未購入製品のリストを消費者に表示し、購入要求を確認するように消費者に催促する。ステップ１２１６において消費者が購入を確認した場合、ステップ１２１８においてウオレット・オブジェクトをロードする。その他の場合、図１２のステップを終了し、購入を行わない。
電子ショッピング・バスケット内の未購入製品品目を商人でソートする場合（例えば、“L.L. Bean”または“Sears”）、ステップ１２２０は製品項目を商人毎に複数のグループまたは１つのグループに分割する。第１の商人と関連する第１の製品グループを処理のために指定する。次に、ステップ１２２２において、第１のグループを更に、PaymentFriendlyName（例えば、“Gold Card”または“Mary’s Amex”）の値にしたがってサブグループに分割（即ちソート）する。このようにして、異なる注文を１箇所の商人に委託しつつ、異なる支払い源を用いて支払うことが可能になる。
例えば、AddressFriendlyName（例えば、“Grandma’s House”または“Alaska Cabin”）の値に基づく再分類のような、第３の再分類も可能であることを当業者は認めよう。このような追加の再分類を行うと、１箇所の商人に委託し、異なる支払い源から支払いを行い、製品を異なる場所に送付するというような注文に対応し、商人を補佐するので便利である。更に、同じ支払い源から支払う製品を異なる住所に送付可能とすれば便利であろう。
単一の支払い源から購入する、単一の商人に対する１群の製品を関連付け、ＧＳＯ（製品およびサービスの注文）を、ウオレット・オブジェクト上でGenerateGSOPIメソッド１２４２に提出（submit）する。ステップ１２２４において、GenerateGSOPIメソッド１２４２は、記憶し暗号化してあるデータ（即ち、ブロッブ（blob））の内受け渡したPaymentFriendlyNameと関連するものを抽出する。次のステップ１２２６において、受け渡したPaymentFriendlyNameと関連する支払い源からの支払いを許可するために、パスワードを消費者に催促する。パスワードが正しくない場合、購入は許可されず、次の製品のサブグループを識別し、これに対してステップ１２２２を繰り返す。しかしながら、パスワードが正しい場合、ステップ１２２８において暗号化してある支払い源データを解読し、支払い源情報および製品情報から支払い命令を形成する。この支払い命令は、商人に注文を完了させるために十分なデータを含む。次のステップ１２３０において、支払い命令を製品リストと共に暗号化ＤＬＬに受け渡し、暗号化する。暗号化ＤＬＬは、公知のＲＳＡ暗号化技術（公開／個人キー暗号化の形態）を用いる。本発明は、暗号化技術によって限定される訳ではなく、他の形態の暗号化も使用可能である。次に、GenerateGSOPIメソッド１２４２は、暗号化した注文をステップ１２３２に受け渡し、ここでＨＴＴＰ ＰＯＳＴメッセージの一部として注文を商人の注文ＵＲＬ（製品データ構造に関連する欄として保持してある）に送る。こうして、商取引クライアント１２２は、ウエブ・ブラウザを迂回し、ＨＴＴＰ ＰＯＳＴメッセージをそれ自体で送信することができる。
注文を送信した後、商取引クライアント１２２は次に各商人に対するメモリ内構造を更新する。各商人構造は、注文構造のリンク・リストへの基準ポインタを含む。商取引クライアント１２２は、注文構造のリンク・リストが少しでもあれば、最後の注文構造に達するまでこれを精査する。商取引クライアント１２２は、新たなな注文構造にメモリを割り当て、新たな構造を当該商人に対する注文構造のリストにリンクし、支払情報、送付先住所情報、および注文した製品と関連する製品構造へのポインタを新たな注文構造に移植する。新たな注文構造の注文追跡識別子（「ＯＴＩ」）欄は、空白にしておく。構造のリンク・リストは、データ項目を互いに関連付ける１方法に過ぎず、リレーショナル・データベースのような他の方法を用いて同様の関連付けを行うことも可能であることを当業者は認めよう。
製品購入の注文を受信した商人サイトは、注文確認メッセージをウエブ・ブラウザ１２０に送信する。注文確認メッセージは、注文追跡識別子（「ＯＴＩ」）をウエブ・ブラウザ１２０に送信する。ウエブ・ブラウザ１２０は、ユーザ・コンピュータの画面上に、例えば、“Thank you for your order. If there is any problem, please phone 1 800 123 4567 and be prepared to refer to the following order tracking identifier”（「ご注文ありがとうございます。何らかの問題がある場合は、１ ８００ １２３ ４５６７にお電話し、以下の注文追跡識別子でお問い合わせ下さい。）というようなことを述べるメッセージと共に、ＯＴＩを表示する。また、ＯＴＩは、ウエブ・ブラウザ１２０が商取引クライアント１２２に受け渡す、形式x-ishopperのＭＩＭＥメッセージにも埋め込む。次に、商取引クライアント１２２は注文構造の空白のＯＴＩ欄にこのＯＴＩをコピーし、購入に関する情報の記憶を完了する。
ステップ１２３４は、現商人に対して追加製品の購入が続いているか否かについて判定を行う。肯定の場合、ステップ１２２２から処理を再開し、否定の場合、ステップ１２２０において次の商人からの次の製品グループについて処理を再開する。ステップ１２３６において、全ての商人に対する全ての製品を購入したか否かについて判定を行う。未購入の製品がある場合、１２２０から処理を再開する。ステップ１２３６において全ての製品を購入したと判定した場合、ステップ１２３８において、電子ショッピング・バスケット内の各製品毎にそのFlag欄に「購入済み」とマークする（即ち１に等しくセットする）。最後に、ステップ１２４０において、ＶＩＥＷ ＳＨＯＰＰＩＮＧ ＢＡＳＫＥＴオプションおよびＶＩＥＷ ＨＩＳＴＯＲＹオプションを含むステップを呼び出し、メモリ構造および画面表示の更新を行って、いずれの製品についても実際に購入したか否かの混乱を生ずるような事態を回避する。
ＶＩＥＷ ＨＩＳＴＯＲＹオプションの選択の後、商取引クライアント１２２によってユーザにＯＲＤＥＲ ＳＴＡＴＵＳオプションを提示する。前述のように、一旦注文のリストを生成しユーザに表示したなら、ユーザは注文を選択する（好ましくは、注文と関連する情報の上にマウス・ポインタを位置付け、マウス・ボタンをクリックする）。次に、ユーザはＯＲＤＥＲ ＳＴＡＴＵＳオプションを選択する。次いで、商取引クライアントは、注文追跡識別子（「ＯＴＩ」）を含むＨＴＴＰ ＰＯＳＴメッセージを生成し、購入した製品（または複数の製品）と関連する注文ＵＲＬ（販売する商人のインターネット・アドレスを一意に識別する）に、このＨＴＴＰ ＰＯＳＴメッセージを送信する。ＯＴＩを含むＨＴＴＰ ＰＯＳＴメッセージを受信した商人サイトは、注文のステータスを判定する（例えば、“SHIPPED”（送付済み），“CANCELED”（取消），“WAITING FOR INVENTORY”（在庫待ち）等）。商人サイトは、ステータス情報を含むＨＴＭＬ文書をウエブ・ブラウザに送信する。ユーザ・コンピュータのウエブ・ブラウザは、ユーザ・コンピュータの画面上にこのステータス情報を表示する。
消費者は、ＨＥＬＰオプションを選択することにより、コンピュータを用いたショッピング・システムを用いる際に、オンライン補助（即ち、ヘルプ）を受ける。一実施形態では、ＨＥＬＰオプションは、ウエブ文書のＨＴＭＬコード化に含ませ、ウエブ・ブラウザによってユーザに表示する。ＨＥＬＰオプションを選択すると、ウエブ・ブラウザ１２０はＨＥＬＰウエブ・サイトにアクセスする。
他の実施形態では、商取引クライアント１２２のユーザ・インターフェースによってＨＥＬＰオプションをユーザに表示する。この実施形態において、ＨＥＬＰオプションを選択することにより、商取引クライアント１２２は、他のコンピュータへのＴＣＰ／ＩＰ通信リンクが未だ確立されていない場合、このようなリンクを確立する。商取引クライアント１２２は、ＨＴＴＰ ＰＯＳＴメッセージを直接ＨＥＬＰウエブ・サイトに送信する。商取引クライアント１２２は、ウエブ・ブラウザ１２０が未だ走っていない場合、これをユーザ・コンピュータ上で走り始めさせる。
ＨＥＬＰオプションのいずれの実施形態においても、ウエブ・ブラウザは、ＨＥＬＰウエブ・サイトのウエブ・サーバが提供する文書内に含まれているヘルプ情報を表示する。ヘルプ情報は、例えば、コンピュータを用いたショッピング・システムの使用法、またはコンピュータを用いたショッピング・システムを動作させる際に遭遇するエラーの原因を説明し、チップス（tips）を提供する。即ち、画像および図によってコンピュータを用いたショッピング・システムの特徴を示す。代わりに、オンライン・ヘルプは、消費者コンピュータ１０２上に位置する情報を階層的に順序付けた集合体（トピックス、サブトピックス、サブサブトピックス）として、これを通じて消費者に利用させることも可能であることを当業者は認めよう。
消費者は、ＪＵＭＰ ＴＯ ＭＥＲＣＨＡＮＴオプションを選択することによって、製品情報を得た商人ウエブ・サイト３０２にアクセスすると便利である。商取引クライアントのユーザ・インターフェースは、ＪＵＭＰ ＴＯ ＭＥＲＣＨＡＮＴオプションを含む。各製品毎の製品データ構造内において製品名と商人ウエブ・サイトＵＲＬとの間の関連を維持することにより、コンピュータを用いたショッピング・システムは、ある製品の製品データ構造にアクセスすることにより、当該製品を販売する商人と関連するＵＲＬを突き止める。商取引クライアント１２２は、ＨＴＴＰ ＰＯＳＴメッセージを生成し、当該製品と関連のある商人ウエブ・サイトにアクセスする。商人ウエブ・サイトは応答して、ＨＴＭＬ文書をウエブ・ブラウザ１２０に送信する。このように、消費者は、製品に関する情報を得たウエブ・サイトにアクセスでき、便利である。
消費者は、コンピュータを用いたショッピング・システムを終了する際、ＥＸＩＴボタンを選択する。ＥＸＩＴボタンによって、商取引クライアント１２２は、リンクの関係を保存するように、リンクしたメモリ内データ構造をハード・ディスクに書き込む（他の記憶装置でもよい場合もある）。次に、商取引クライアント１２２は、消費者コンピュータ１０２上での実行を停止する。
本発明は、ここに記載した必須の特徴から逸脱することなく、他の特定形態においても実体化可能である。上述の実施形態は、あらゆる観点においても例示的に解釈し、決して限定的に解釈すべきものではない。本発明の範囲は、前述の記載によってではなく、以下の請求の範囲によって示す。特許請求の範囲の均等の意味および範囲に該当するいずれの変更およびあらゆる変更も、その範囲に該当すると解釈することとする。
以下に続く請求の範囲では、請求項のステップを明記するために用いたアルファベット文字は、記載の利便性のためにのみ与えるのであり、当該ステップを実行するいかなる特定の順序をも暗示することを意図する訳ではない。

Claims (6)

1. インターネットを通じて電子商取引を行うクライアント・アーキテクチャをコンピュータ上で実現するために複数のコンピュータ命令を含むコンピュータプログラム及び情報を記憶したコンピュータ読み取り可能記憶媒体であって、
   前記クライアント・アーキテクチャが、
   前記コンピュータ上で走るように構成してあるウエブ・ブラウザ・アプリケーションと、
   ユーザ・インターフェイスを提供するために前記ウエブ・ブラウザ・アプリケーションと共に前記コンピュータ上で走るように構成してある商取引クライアント・アプリケーションであって、コール可能機能を含む、商取引クライアント・アプリケーションと、
   前記商取引クライアント・アプリケーションの前記コール可能機能を実行することによって起動して、前記コンピュータ読み取り可能記憶媒体上に記憶してある製品情報および商人情報にアクセスして操作するように構成してある電子ショッピング・バスケット・オブジェクトと、
   各々が前記商取引クライアント・アプリケーションの前記コール可能機能に対応する、埋め込み機能コール情報を含む少なくとも２つのウエブ文書であって、ユーザが前記ウエブ・ブラウザを用いて前記ウエブ文書の１つを視認しながら、前記ユーザ・インターフェイスを介して前記コール可能機能の実行を選択的に開始できるように、前記機能コール情報を埋め込んである、少なくとも２つのウエブ文書と、を備え
   前記ユーザ・インターフェイスは、前記各々のウエブ文書について表示されて独立に機能し、
   前記電子ショッピング・バスケット・オブジェクトが、（ｉ）前記コンピュータを介して、製品比較オプションをユーザに表示し、ユーザの入力を監視し前記製品比較オプションの選択を検出し、（ｉｉ）前記コンピュータ読み取り可能記憶媒体から、第１の製品の前記製品情報および第２の製品の前記製品情報を検索し、前記製品情報をフォーマット化し、前記コンピュータを介してユーザに表示することによって、前記製品比較オプションのユーザ選択に応答することを特徴とするコンピュータ読み取り可能記憶媒体。
2. 請求項１記載のコンピュータ読み取り可能記憶媒体において、前記商取引クライアント・アプリケーションが第２のコール可能機能を含み、前記各ウエブ文書が、前記商取引クライアント・アプリケーションの前記第２のコール可能機能に対応する埋め込み機能コール情報を含み、前記第２のコール可能機能の実行は、ユーザが前記ウエブ・ブラウザを用いて前記ウエブ文書の１つを視認しながら選択的に開始し、前記クライアント・アーキテクチャが、更に、
   前記コンピュータ読み取り可能記憶媒体上に記憶してある支払い源情報にアクセスしこれを操作するように構成してある電子ウオレット機能を備え、前記商取引クライアント・アプリケーションの前記第２のコール可能機能を実行することによって、前記支払源情報へアクセスして操作を開始することを特徴とするコンピュータ読み取り可能記憶媒体。
3. 請求項１記載のコンピュータ読み取り可能記憶媒体において、前記商取引クライアント・アプリケーションが第２のコール可能機能を含み、前記各ウエブ文書が、前記商取引クライアント・アプリケーションの前記第２のコール可能機能に対応する埋め込み機能コール情報を含み、前記第２のコール可能機能の実行は、ユーザが前記ウエブ・ブラウザを用いて前記ウエブ文書の１つを視認しながら選択的に開始し、前記クライアント・アーキテクチャが、更に、
   前記コンピュータ読み取り可能記憶媒体上に記憶してある送付先住所情報にアクセスしこれを操作するように構成してある電子住所録機能を備え、前記商取引クライアント・アプリケーションの前記第２のコール可能機能を実行することによって、前記送付先住所情報へアクセスして操作を実行することを特徴とするコンピュータ読み取り可能記憶媒体。
4. インターネットを通じて電子商取引を行うクライアント・アーキテクチャをコンピュータ上で実現するために複数のコンピュータ命令を含むコンピュータプログラム及び情報を記憶したコンピュータ読み取り可能記憶媒体であって、
   前記クライアント・アーキテクチャが、
   前記コンピュータ上で走るように構成してあるウエブ・ブラウザ・アプリケーションと、
   前記ウエブ・ブラウザ・アプリケーションと共に前記コンピュータ上で走るように構成してある商取引クライアント・アプリケーションであって、コール可能機能及びユーザ・インターフェイスを含む商取引クライアント・アプリケーションと、
   前記コンピュータがアクセス可能な前記コンピュータ読み取り可能記憶媒体に製品情報および商人情報を記憶するように構成してある電子ショッピング・バスケット機能であって、該電子ショッピング・バスケット機能が、前記コンピュータがアクセス可能な前記コンピュータ読み取り可能記憶媒体上に記憶してある実行可能コンピュータ命令から成り、前記ウエブ・ブラウザによって前記インターネットを通じて商人ウエブ・サイトから前記製品情報および商人情報を検索し、前記商取引クライアント・アプリケーションの前記コール可能機能を実行することにより前記記憶を開始する、電子ショッピング・バスケット機能と、
   各々が前記商取引クライアント・アプリケーションの前記コール可能機能に対応する、埋め込み機能コール情報を含む少なくとも２つのウエブ文書であって、ユーザが前記ウエブ・ブラウザを用いて前記ウエブ文書の１つを視認しながら、前記ユーザ・インターフェイスを介して前記コール可能機能の実行を選択的に開始できるように、前記機能コール情報を埋め込んである、少なくとも２つのウエブ文書と、を備え、
   前記ユーザ・インターフェイスは、前記各々のウエブ文書について表示されて独立に機能し、
   そして前記電子ショッピング・バスケット機能が、（ｉ）前記コンピュータを介して、製品比較オプションをユーザに表示し、ユーザの入力を監視し前記製品比較オプションの選択を検出し、（ｉｉ）前記コンピュータ読み取り可能記憶媒体から、第１の製品の前記製品情報および第２の製品の前記製品情報を検索し、前記製品情報をフォーマット化し、前記コンピュータを介してユーザに表示することによって、前記製品比較オプションのユーザ選択に応答することを特徴とするコンピュータ読み取り可能記憶媒体。
5. インターネットを通じて製品を購入するクライアント・アーキテクチャをコンピュータ上で実現するために複数のコンピュータ命令を含むコンピュータプログラム及び情報を記憶したコンピュータ読み取り可能記憶媒体であって、
   前記クライアント・アーキテクチャが、
   前記コンピュータ上で走るように構成してあり且つユーザ・インターフェイスを有する商取引クライアント・アプリケーションであって、該商取引クライアント・アプリケーションが、ワールド・ワイド・ウエブ・プロトコルに応じてワールド・ワイド・ウエブ・サイトに情報を送信するように構成してあり、前記商取引クライアント・アプリケーションが、ウエブ・ブラウザと共に走るように構成してあり、前記商取引クライアント・アプリケーションが、製品情報と、商人情報と、支払い源情報とを組み合わせ、該情報の組み合わせをワールド・ワイド・ウエブ・サイトに送信する、製品購入機能を含み、該製品購入機能が、前記コンピュータ読み取り可能記憶媒体上に記憶してある実行可能コンピュータ命令から成る、商取引クライアント・アプリケーションと、
   前記コンピュータ上で走るように構成してあるウエブ・ブラウザ・アプリケーションと、
   各々が前記商取引クライアント・アプリケーションの前記製品購入機能に対応する、埋め込み機能コール情報を含む少なくとも２つのウエブ文書であって、ユーザが前記ウエブ・ブラウザを用いて前記ウエブ文書の１つを視認しながら、前記ユーザ・インターフェイスを介して前記製品購入機能の実行を選択的に開始できるように、前記機能コール情報を埋め込んである、少なくとも２つのウエブ文書と、を備え、
   前記ユーザ・インターフェイスは、前記各々のウエブ文書について表示されて独立に機能し、
   前記商取引クライアント・アプリケーションが、更に、
   （ｉ）前記コンピュータを介して、製品比較オプションをユーザに表示し、ユーザの入力を監視し前記製品比較オプションの選択を検出し、（ｉｉ）前記コンピュータ読み取り可能記憶媒体から、第１の製品の前記製品情報および第２の製品の前記製品情報を検索し、前記製品情報をフォーマット化し、前記コンピュータを介してユーザに表示することによって、前記製品比較オプションのユーザ選択に応答し、
   前記クライアント・アーキテクチャが、更に、
   前記コンピュータ読み取り可能記憶媒体上に記憶してある製品情報および商人情報にアクセスしこれを操作するように構成してある電子ショッピング・バスケット・オブジェクトであって、該電子ショッピング・バスケット機能が、前記商取引クライアント・アプリケーションの前記製品購入機能の実行中に、前記商取引クライアント・アプリケーションに製品情報および商人情報を送信し、前記コンピュータ読み取り可能媒体上に記憶してある実行可能コンピュータ命令から成る、電子ショッピング・バスケット・オブジェクトを備えることを特徴とするコンピュータ読み取り可能記憶媒体。
6. 請求項５記載のコンピュータ読み取り可能記憶媒体であって、前記クライアント・アーキテクチャが、更に、
   前記コンピュータによりアクセス可能な前記コンピュータ読み取り可能記憶媒体上に記憶してある支払い源情報および商人情報にアクセスしこれを操作するように構成してある電子ウオレット・オブジェクトであって、該電子ウオレット・オブジェクトが、前記商取引クライアント・アプリケーションの前記製品購入機能の実行中に、前記商取引クライアント・アプリケーションに支払源情報および商人情報を送信し、前記コンピュータ読み取り可能記憶媒体上に記憶してある実行可能コンピュータ命令から成る電子ウオレット・オブジェクトを、備えることを特徴とするコンピュータ読み取り可能記憶媒体。

Images