JP4959817B2 - アイテムを注文するためのクライアント・システムにおける方法及びアイテムの注文を受け付けるサーバ・システムにおける方法 - Google Patents

Description

本発明は、注文を出すためのコンピュータ方法およびシステムに関し、さらに具体的には、アイテムを注文するためのクライアント・システムにおける方法及びアイテムの注文を受け付けるサーバ・システムにおける方法に関する。

インターネット（the Internet）は非常に多数のコンピュータとコンピュータ・ネットワークから構成され、これらは通信リンクを通して相互に接続されている。相互に接続されたコンピュータは、電子メール、ゴーファー（Gopher）、およびワールドワイド・ウェブ（World Wide Web: "WWW" ）などの、様々なサービスを利用して情報をやりとりしている。ＷＷＷサービスを利用すると、サーバ・コンピュータ・システム（つまり、ＷｅｂサーバまたはＷｅｂサイト）はグラフィック情報（図形、画像など）のＷｅｂページをリモート・クライアント・コンピュータ・システムに送信することができる。その後、リモート・クライアント・コンピュータ・システムはそのＷｅｂページを表示することができる。ＷＷＷの各リソース（例えば、コンピュータやＷｅｂページ）はＵＲＬ（Uniform Resource Locator）によって一意的に識別可能になっている。特定のＷｅｂページを表示するには、クライアント・コンピュータ・システムは要求（例えば、ハイパーテキスト転送プロトコル（HTTP: Hyper Text Transfer Protocol）要求）の中でそのＷｅｂページのＵＲＬを指定する。この要求はそのＷｅｂページをサポートするＷｅｂサーバに転送される。Ｗｅｂサーバは要求を受信すると、そのＷｅｂページをクライアント・コンピュータ・システムに送信する。クライアント・コンピュータ・システムはそのＷｅｂページを受信したとき、ブラウザを使用してＷｅｂページを表示するのが代表的である。ブラウザはＷｅｂページの要求とＷｅｂページの表示を実行する特殊目的のアプリケーション・プログラムである。

現在、Ｗｅｂページはハイパーテキスト・マークアップ言語（HTML: Hyper Text Markup Language）を使用して定義されているのが代表的である。ＨＴＭＬはＷｅｂページをどのように表示するかを定義するタグの集まりからなる標準である。ユーザがＷｅｂページを表示するようにブラウザに指示すると、ブラウザは、そのＷｅｂページを定義しているＨＴＭＬドキュメントをクライアント・コンピュータ・システムに転送するように要求をサーバ・コンピュータ・システムに送信する。要求したＨＴＭＬドキュメントがクライアント・コンピュータ・システムによって受信されると、ブラウザはＨＴＭＬドキュメントで定義されたとおりにＷｅｂページを表示する。ＨＴＭＬドキュメントはテキスト、グラフィックス、コントロール、およびその他の機能の表示を制御する様々なタグを含んでいる。ＨＴＭＬドキュメントには、そのサーバ・コンピュータ・システムまたは他のサーバ・コンピュータ・システムで利用できる他のＷｅｂページのＵＲＬを含めることが可能である。

ワールドワイド・ウェブ（World Wide Web）は電子的取引を行うのに特に役立っている。そこを通してベンダ（取引業者）が製品を宣伝し、販売できるようにするＷｅｂサーバが多数開発されている。これらの製品の中には、インターネットを利用して購入者に電子的に配送されるアイテム（例えば、音楽）や、従来の配送チャネル（例えば、運輸業者）を通して配送されるアイテム（例えば、書籍）などがある。サーバ・コンピュータ・システムは、提供されるアイテムをリストした電子版のカタログを用意している場合がある。潜在的購入者であるユーザはブラウザを使用してカタログをブラウジングしていき、購入しようとする種々のアイテムを選択することが可能になっている。ユーザが購入しようとするアイテムの選択を完了すると、サーバ・コンピュータ・システムはそのアイテムの注文を完成するための情報をユーザに要求する。この購入者固有注文情報としては、購入者の氏名、購入者のクレジット・カード番号、注文の出荷アドレスなどがある。その後、サーバ・コンピュータ・システムは、確認のＷｅｂページをクライアント・コンピュータ・システムに送信して注文を確認してから、アイテムの出荷をスケジュールするのが代表的である。

購入者固有注文情報はセンシティブ（機密を要する）情報（例えば、クレジット・カード番号）を含んでいるので、ベンダと購入者のどちらも、かかる情報のセキュリティ（機密）が保証されることを望んでいる。セキュリティが関心事であるのは、インターネットを利用して伝送される情報がその最終的デスティネーション（宛先）に到達するまでの途中に様々な中間コンピュータ・システムを経由する可能性があるためである。この情報は中間システムにいる心ない人によってインターセプトされる可能性がある。センシティブ情報のセキュリティを保証することに役立つために、かかる情報をクライアント・コンピュータ・システムとサーバ・コンピュータ・システムの間で伝送するときに様々な暗号化手法が使用されている。このような暗号化情報が例えインターセプトされるようなことがあっても、この情報は暗号化されているので、インターセプトする人には使いものにならないのが一般である。それにもかかわらず、かかるセンシティブ情報がインターセプトする人によって解読されるかも知れないという可能性は常に存在する。従って、望ましいことは、注文を出すとき伝送されるセンシティブ情報を最小限にすることである。

電子カタログから種々のアイテムを選択することは、「ショッピンク・カート（shopping cart ）」モデルを基礎にしているのが一般である。購入者が電子カタログからあるアイテムを選択すると、サーバ・コンピュータ・システムは暗喩的に（metaphorically）そのアイテムをショッピンク・カートに追加する。購入者がアイテムの選択を完了すると、ショッピンク・カート内の全てのアイテムは、購入者が請求書発行と出荷に関する情報を与えたとき「チェック・アウト」される（つまり、発注される）。いくつかのモデルでは、購入者が任意のアイテムを選択したとき、そのアイテムは請求書発行と出荷情報をユーザに自動的に要求することによって「チェック・アウト」されている。ショッピンク・カート・モデルは非常に柔軟性があり、直観的であるが、購入者側に多数のやりとりを要求するという欠点がある。例えば、購入者は電子カタログから種々のアイテムを選択した後、選択が完了したことを指示している。その後、購入者には、注文を完成するために購入者固有注文情報を購入者に要求する注文Ｗｅｂページが表示される。このＷｅｂページには、別の注文を行ったとき購入者が与えていた情報が事前に入っていることがある。この情報はサーバ・コンピュータ・システムによって有効性検査され、注文が完成する。このような注文モデルはいくつかの理由で問題となる可能性がある。ある購入者がアイテムを１つだけ注文する場合、注文プロセスの種々ステップを確認し、購入者固有注文情報を待ち、表示し、更新するオーバヘッドは、その項目を選択すること自体のオーバヘッドよりもはるかに大きくなる可能性がある。このオーバヘッドは単一アイテムの購入を煩わしくする。また、かかる注文モデルによると、注文が出される度に、センシティブ情報がインターネット上を伝送されている。このセンシティブ情報はインターネット上を伝送される度に、インターセプトされ、解読される可能性がある。

本発明の実施形態によれば、クライアント・システムからアイテムを注文する方法及びそのシステム、具体的にはギフト発送方法及びそのシステムが提供されている。クライアント・システムには、カストマを特定するＩＤ（識別子）が与えられる。クライアント・システムはアイテムを特定する情報を表示し、特定されたアイテムを注文するために購入者に実行させるアクション（例えば、マウス・ボタンをクリックする、といったシングル・アクション）を表示する。表示されたアクションが実行されると、それに応答してクライアント・システムは与えられたＩＤと特定されたアイテムを注文する要求をサーバ・システムに送信する。サーバ・システムはそのＩＤを使用して、アイテムの注文を生成するために必要な追加情報を特定した後、注文を生成する。

サーバ・システムは種々のコンピュータ・システムを使用してカストマの追加情報を受信し、ストアしておき、サーバ・システムが上記注文を生成できるようにする。サーバ・システムは受信した追加情報をカストマのＩＤと関連付けてストアしておき、そのＩＤをクライアント・システムに提供する。クライアント・システムから要求されると、サーバ・システムはアイテムを記述した情報を要求元クライアント・システムに提供する。サーバ・システムがクライアント・システムから要求を受け取ると、サーバ・システムはその要求に含まれるＩＤと関連付けてストアされた追加情報を結合して、アイテムの注文を出す。

本発明は、クライアント／サーバ環境においてシングル・アクションでアイテムを注文するための方法およびシステムを提供している。本発明のシングル・アクション注文システムは、注文を出すために必要とされる購入者のやりとりの数を低減化し、クライアント・システムとサーバ・システムの間で伝送されるセンシティブ（機密）情報の量を低減化する。本発明の一実施形態では、サーバ・システムは各クライアント・システムに一意的なクライアントＩＤを割り当てている。また、サーバ・システムは様々な潜在的購入者の購入者固有注文情報をストアしている。この購入者固有注文情報は購入者が出した以前の注文から収集されている場合もある。サーバ・システムは各クライアントＩＤを、そのクライアント・システムを使用して注文を出す可能性のある購入者にマッピング（対応付けること）している。サーバ・システムはこれらのクライアントＩＤを、そのクライアント・システムを使用して最後に注文を出した購入者にマッピングすることもできる。購入者が注文を出す必要が起こると、その購入者はクライアント・システムを使用して、注文するアイテムを記述している情報の要求をそのクライアントＩＤと一緒に送信する。サーバ・システムはそのクライアント・システムのクライアントＩＤが購入者にマッピングされているかどうかを判断する。マッピングされていることを判断すると、サーバ・システムはそのクライアント・システムにいるその購入者のためにシングル・アクション注文が許可（enabled ）されているかどうかを判断する。許可されていれば、サーバ・システムは要求された情報を（例えば、Ｗｅｂページを通して）、アイテムの注文を出すために実行すべきシングル・アクションの指示と一緒にクライアント・コンピュータ・システムに送信する。シングル・アクション注文が許可されているときは、購入者はシングル・アクションを実行するだけで（例えば、マウス・ボタンをクリックする）、アイテムを注文することができる。購入者がそのシングル・アクションを実行すると、クライアント・システムはそのことをサーバ・システムに通知する。通知を受けたサーバ・システムはそのクライアントＩＤにマッピングされている購入者の購入者固有注文情報をアイテム注文情報（例えば、製品のＩＤと数量）に追加することによって注文を完成する。従って、項目の記述が表示されたとき、購入者はシングル・アクションをとるだけで、そのアイテムを購入する注文を出すことができる。また、サーバ・システム側にすでにストアされている購入者固有注文情報はクライアントＩＤで特定されるので、かかるセンシティブ情報をインターネットや他の通信媒体経由で伝送する必要がない。

本発明の一実施形態におけるシングル・アクション注文を示す図である。 本発明の一実施形態におけるシングル・アクション注文を示す図である。 本発明の一実施形態におけるシングル・アクション注文を示す図である。 本発明の実施形態を示すブロック図である。 カストマのためにシングル・アクション注文を許可するルーチンを示すフロー図である。 シングル・アクション注文が許可されているＷｅｂページを生成するルーチンを示すフロー図である。 シングル・アクション注文を処理するルーチンを示すフロー図である。 シングル・アクション注文要約Ｗｅｂページを生成するルーチンを示すフロー図である。 促進注文選択アルゴリズムを実現するルーチンを示すフロー図である。 本発明の一実施形態における階層データ入力メカニズムを示す図である。 本発明の一実施形態における階層データ入力メカニズムを示す図である。 本発明の一実施形態における階層データ入力メカニズムを示す図である。 シングル・アクションを使用してアイテムをギフトとして一人または複数の受取人に贈る方法を示す図である。 シングル・アクションを使用してアイテムをギフトとして一人または複数の受取人に贈る方法を示す図である。 グループを作成し、そのグループに関連付けられた受取人の識別情報を入力するためのグリッドを示す図である。 ギフト発送システムの全体的フローを示すフロー図である。 ギフト発送システムのコンポーネントを示すブロック図である。 ギフト注文の種々のステートを示すステート図である。 ギフト注文の受信を制御するルーチンを示すフロー図である。 受取人への最初のコンタクトの試みを制御するルーチンを示すブロック図である。 初回音声電話コンタクトの処理を制御するルーチンを示すフロー図である。 初回応答の処理を制御するルーチンを示すフロー図である。 追加コンタクト先情報の収集を制御するルーチンを示すフロー図である。 発送情報の検証を制御するルーチンを示すフロー図である。

図１乃至図３は、本発明の一実施形態におけるシングル・アクション注文を示す図である。図１は、注文が可能なアイテムを記述しているＷｅｂページのディスプレイを示す図である。このＷｅｂページの例は、購入者がアイテムに関する詳細情報をレビューすることを要求したときにサーバ・システムからクライアント・システムに送信されたものである。このＷｅｂページの例は要約記述セクション１０１、ショッピンク・カート・セクション１０２、シングル・アクション注文セクション１０３、および詳細記述セクション１０４を含んでいる。当業者ならば理解されるように、これらの各種セクションは省くことも、様々な方法で並べ替えたり、適応させたりすることも可能である。一般的には、購入者はシングル・アクションで注文される１つまたは複数のアイテムまたは注文を出すために必要なシングル・アクションを知っているだけで十分である。要約記述セクションと詳細記述セクションには、注文が可能な１つまたは複数のアイテムを特定し、記述している情報が入っている。ショッピンク・カート・セクションを使用すると、従来と同じように、記述されたアイテムをショッピンク・カートに追加することができる。サーバ・システムは要約記述、詳細記述、およびショッピンク・カートの各セクションを、注文が可能なアイテムの各Ｗｅｂページに追加する。しかし、サーバ・システムがシングル・アクション注文セクションを追加するのは、シングル・アクション注文がそのクライアント・システムにいるその購入者に許可されているときだけである（当業者ならば理解されるように、サーバ・システム上のシングルＷｅｂページは全てのセクションを含むことが可能であるが、シングル・アクション注文セクションはＷｅｂページをクライアント・システムに送信する前に選択的に含めることも、除外することも可能である。）。このシングル・アクション注文セクションを使用すると、購入者はマウス・ボタンをシングル・クリック（１−click ）するだけで記述されたアイテムを指定して注文することができる。購入者がマウス・ボタンをクリックすると、購入者がそのとき注文を変更するためになんらかのアクションをとっていなければ、アイテムが注文される。シングル・アクション注文セクションはシングル・アクション注文ボタン１０３ａ、購入者ＩＤサブセクション１０３ｂ、およびシングル・アクション注文情報サブセクション１０３ｃと１０３ｄを含んでいる。購入者情報サブセクションには、サーバ・システムが購入者を正しく認識したことを購入者が確認できるだけの十分な情報が表示される。センシティブ情報がインターセプトされる可能性を少なくするために、サーバ・システムはサーバ・システムが購入者を正しく特定したと購入者が確信するのに十分な情報だけを送信し、心ないインターセプトをする人に好都合な情報は送信しない。追加情報サブセクションを使用すると、購入者は種々の設定値を取得したり、シングル・アクション注文に関する詳細情報を取得したりできる。購入者が出荷アドレスを検証することを望まなければ、購入者は「出荷アドレスのチェック（check shipping address）」ラベルを選択することができる。これを選択すると、サーバ・システムはユーザに「ログイン（login ）」を行うように要求し、購入者が本人であることが検証されてから出荷情報が表示または変更されるようにする。その後、サーバ・システムはＷｅｂページをクライアント・システムに送り、出荷アドレスが表示されるか、変更できるようにする。このようにすると、センシティブな出荷アドレスを送信することは、検証された購入者が要求しない限り防止される。

購入者がシングル・アクション注文ボタンを選択すると、クライアント・システムはメッセージをサーバ・システムに送信し、表示されたアイテムが注文されるように要求する。サーバ・システムがそのメッセージを処理すると、サーバ・システムはシングル・アクション注文の受信を確認する新しいＷｅｂページをクライアント・システムに提供する。図２は、シングル・アクション注文を確認するＷｅｂページのディスプレイを示す図である。この確認Ｗｅｂページは、注文確認セクション１０５がＷｅｂページの上部に表示されることを除けば、アイテム記述Ｗｅｂページ（図１参照）とほぼ同じ情報を収めている。注文確認セクションは注文が出されたことを確認し、購入者がシングル・アクション注文をレビューし、変更する機会を与える。上記とは別に、確認Ｗｅｂページは、シングル・アクション注文ボタンが注文確認メッセージで置き換えられることを除けば、アイテム記述Ｗｅｂページ（図１参照）と同じにすることができる。

シングル・アクション注文が現在クライアント・システムでは許可されていないが、許可することが可能であれば、サーバ・システムは、シングル・アクション注文ボタン１０３ａがシングル・アクション注文許可ボタンで置き換えられることを除けば、図１と同じＷｅｂページを生成することができる。このような置換ボタンには、購入者がボタンをクリックすると、シングル・アクション注文が許可されることを指示するテキストを含めることが可能である。購入者がこのボタンをクリックすると、サーバ・システムは図１のＷｅｂページを送信して表示することになる。シングル・アクション注文は、そのクライアント・システムがシングル・アクション注文を完成するだけの十分な購入者固有注文情報をサーバ・システムがストアしているときは、いつでも許可することができる。サーバ・システムに十分な情報がなければ、購入者がシングル・アクション・ボタンを選択したとき、サーバ・システムは必要とする追加情報を収集するためにＷｅｂページを提供することができる。サーバ・システムは購入者に「ログイン」することを要求し、購入者が本人であることが検証されてからシングル・アクション注文が許可されるようにする。

出荷コストと購入者の混乱を最小限にするために、サーバ・システムは種々のシングル・アクション注文を複数アイテム注文に結合することができる。例えば、ある購入者がシングル・アクション注文を使用してあるアイテムを注文し、５分後にシングル・アクション注文を使用して別のアイテムを注文したときは、これらの注文はコスト効率よく単一の注文に結合されて出荷されることになる。サーバ・システムは予定出荷日が類似しているときにシングル・アクション注文を結合する。例えば、一方のアイテムが即時に出荷可能（在庫がある）であり、他方のアイテムが一日後に出荷可能であれば、２つのシングル・アクション注文はコスト効率よく結合することができる。しかし、他方のアイテムが２週間後でなければ出荷できないときは、２つの単アイテム注文は結合されない。図３はアイテムが出荷可能かどうか（在庫があるかどうか）に基づいて２つの別々の複数アイテム注文に結合された４つのシングル・アクション注文を示すＷｅｂページのディスプレイを示している。注文情報１０６は、アイテム１とアイテム２が３日以内に出荷可能であるため、１つの注文に結合されていることを示している。注文情報１０７は、アイテム３とアイテム４が１週間以内に出荷できないため、別々の注文に結合されていることを示している。本発明の一実施形態では、サーバ・システムはある時間期間（例えば、９０分）以内に出されたシングル・アクション注文を結合することができる。また、サーバ・システムは注文が出荷予定にあるとき、注文されたアイテムが現在出荷可能であるかどうかに基づいて注文を結合または分割することができる。このように注文の変更を遅らせることを「促進注文選択（expedited order selection ）」または「急送注文選択」と呼び、これについては以下で詳しく説明する。

図４は、本発明の実施形態を示すブロック図である。この実施形態はワールドワイド・ウェブ（ World Wide Web ）を使用してインターネット経由でシングル・アクション注文を行うことをサポートしている。サーバ・システム２１０はサーバ・エンジン２１１、クライアントＩＤ／カストマ・テーブル２１２、種々のＷｅｂページ２１３、カストマ・データベース２１４、注文データベース２１５、およびインベントリ（在庫品）データベース２１６を備えている。サーバ・エンジンはＵＲＬで識別されたＷｅｂページにアクセスするＨＴＴＰ要求を受け取り、Ｗｅｂページを種々のクライアント・システムに提供する。かかるＨＴＴＰ要求は、購入者がシングル・アクションを実行してシングル・アクション注文を行ったことを示すことができる。カストマ・データベースは種々の購入者または潜在的購入者に関するカストマ情報を収めている。カストマ情報としては、カストマの氏名、請求書発行情報、および出荷情報などの購入者固有注文情報がある。注文データベース２１５は、まだ購入者に出荷されていない各注文のエントリを収めている。インベントリ・データベース２１６は注文可能な種々アイテムの記述を収めている。クライアントＩＤ／カストマ・テーブル２１２は、クライアント・システムを一意的に特定している、グローバルに一意的な識別子である各クライアントＩＤと、そのクライアント・システムと最後に関連付けられたカストマとを対応付けているマッピングを収めている。クライアント・システム２２０はブラウザ２２１と、割り当てられたクライアントＩＤ２２２とを持っている。このクライアントＩＤは「cookie」と名付けたファイルにストアされている。一実施形態によれば、サーバ・システムは、クライアント・システムが初めてサーバ・システムとやりとりするとき一度だけクライアントＩＤを割り当てて、それをクライアント・システムに送付する。それ以降、クライアント・システムはサーバ・システムに送信される全てのメッセージにそのクライアントＩＤを付けるので、サーバ・システムはメッセージの発信元を特定することができる。サーバ・システムとクライアント・システムは通信リンク２３０を経由して情報を交換することによってやりとりを行う。なお、この通信リンクには、インターネットを利用した伝送も含まれる。

当業者ならば理解されるように、シングル・アクション注文手法はインターネット以外の種々の環境で使用することが可能である。例えば、シングル・アクション注文は電子メール環境で使用することも可能であり、この環境においてアイテムは、アイテムの注文を出すために実行されるシングル・アクションの指示と一緒に電子メール・メッセージに記述されている。また、ローカル・エリア・ネットワーク、広域ネットワーク、またはポイント・ツー・ポイント（２地点間）ダイヤルアップ接続などの、種々の通信チャネルを使用することも可能である。また、サーバ・システムは、シングル・アクションが実行されたときにそれに応答して注文を生成できるハードウェアまたはソフトウェアの任意の組み合わせで構成することができる。クライアント・システムは、サーバ・システムとやりとりできるハードウェアまたはソフトウェアの任意の組み合わせで構成することができる。これらのシステムには、そこを通して注文を出すことができるテレビジョン・ベースのシステム、または他の種々の消費者製品を含めることも可能である。

図５は、カストマのためにシングル・アクション注文を許可するルーチンを示すフロー図である。シングル・アクション注文を許可するためには、サーバ・システムは、購入者固有注文情報に相当するカストマに関する情報を持っている必要がある。サーバ・システムはこの情報を様々な方法で取得することができる。第一に、サーバ・システムはカストマがシングル・アクション注文の許可を望んでいるかどうかをカストマに尋ねることができる。望んでいれば、サーバ・システムはＷｅｂページを使用して購入者固有注文情報をカストマに要求することができる。第二に、サーバ・システムは注文が従来の方法で出されたとき収集された購入者固有注文情報を格納しておくこともできる。サーバ・システムはシングル・アクション注文を自動的に許可することも、カストマの同意を得て許可することもできる。ステップ３０１で、サーバ・システムはクライアント・システムから送られてきたクライアントＩＤを検索する。ステップ３０２でサーバ・システムは、生成されたクライアントＩＤがそのカストマと関連付けられたことを示すようにクライアントＩＤ／カストマ・テーブルを更新する。ステップ３０３で、サーバ・システムは、シングル・アクション注文がそのクライアントＩＤとそのカストマの組み合わせで許可されていることを示すフラグをセットする。このフラグはクライアントＩＤ／カストマ・テーブルにストアしておくことができる。ステップ３０４で、サーバ・システムは確認Ｗｅｂページをクライアント・システムに提供する。購入者がアイテムの注文を次回に試みたとき、クライアント・システムはそのクライアントＩＤをサーバ・システムに提供する。シングル・アクション注文がその購入者に許可されていれば、サーバ・システムは、購入者がクライアントＩＤ／カストマ・テーブル内のそのクライアントＩＤと関連付けられたカストマであると想定する。従って購入者は、誰か他の人が同じクライアント・システムを使用する可能性がある場合には、サーバ・システムにシングル・アクション注文を許可させないこともできる。

図６は、シングル・アクション注文が許可されているときの、Ｗｅｂページを生成するルーチンを示すフロー図である。シングル・アクション注文が許可されているときは、サーバ・システムは従来と同じように、アイテムを記述しているＷｅｂページを生成し、その後シングル・アクション注文セクションを追加する。一実施形態では、サーバ・システムは部分的購入者固有注文情報をこのセクションに追加する。この情報としては、カストマの氏名、購入者が選択した出荷アドレスの別名（moniker ）（例えば、「在宅」）、およびクレジット・カード番号の最後の５桁または購入者が選択したニックネームがある。この部分的情報はサーバ・システムが正しい購入者固有注文情報を使用しているかどうかを購入者に知らせるのに十分な最小限の情報にしておく必要がある。ステップ４０１で、サーバ・システムはアイテムの標準的ショッピンク・カート・タイプのＷｅｂページを生成する。ステップ４０２で、シングル・アクション注文フラグがクライアントＩＤとカストマの組み合わせのためにセットされていれば、サーバ・システムはステップ４０３に進み、そうでなければ終了する。ステップ４０３で、サーバ・システムはシングル・アクション・セクションをＷｅｂページに追加し、終了する。

図７は、シングル・アクション注文を処理するルーチンを示すフロー図である。注文を出すために必要なシングル・アクションを購入者が実行すると、クライアント・システムはそのことをサーバ・システムに通知する。その後、サーバ・システムはクライアント・システムと関連付けられたカストマの購入者固有注文情報をアイテム注文情報と結合して注文を完成する。シングル・アクション注文は出荷コストを低減するために、他のシングル・アクション注文と結合することも、場合によっては従来の方法で出された注文と結合することも可能である。一実施形態では、シングル・アクション注文は相互に対して一定時間期間（例えば、９０分）以内に出されたとき結合することができる。このルーチンは、シングル・アクション注文がどのようにして短期注文（例えば、一週間以内に出荷可能である）および長期注文（例えば、一週間後に出荷可能である）に結合されるかを示している。当業者ならば理解されるように、シングル・アクション注文は出荷の規模や中期の出荷可能といった、他の要因に基づいて様々な方法で結合することができる。ステップ５０１で、アイテムが短期に出荷される予定にあれば、サーバ・システムはステップ５０２に進み、そうでなければステップ５０５に進む。ステップ５０２で、短期注文が購入者のためにすでにオープンされていれば、サーバ・システムはステップ５０４に進み、そうでなければステップ５０３に進む。ステップ５０３で、サーバ・システムは購入者のために短期注文を作成する。ステップ５０４で、サーバ・システムはアイテムを短期注文に追加し、ステップ５０８に進む。ステップ５０５で、長期注文が購入者のためにすでにオープンされていれば、サーバ・システムはステップ５０７に進み、そうでなければステップ５０６に進む。ステップ５０６で、サーバ・システムは購入者のために長期注文を作成する。ステップ５０７で、サーバ・システムはアイテムを長期注文に追加する。ステップ５０８で、サーバ・システムは確認を生成し、それを送信して完了する。

図８は、シングル・アクション注文要約Ｗｅｂページを生成するルーチンを示すフロー図である。このＷｅｂページ（例えば、図３）は短期と長期のシングル・アクション注文をユーザが調べ、変更する機会を与える。ステップ６０１で、サーバ・システムは標準的シングル・アクション注文情報をＷｅｂページに追加する。ステップ６０２で、短期注文がオープンしていれば、サーバ・システムはステップ６０３で短期注文をＷｅｂページに追加する。ステップ６０４で、長期注文がオープンしていれば、サーバ・システムはステップ６０５で長期注文情報をＷｅｂページに追加し、完了する。

図９は、促進注文選択アルゴリズムを実装しているルーチンを示すフロー図である。促進注文選択アルゴリズムの目標は、各デスティネーションに送られる注文の数を最小限にして出荷コストを低減化することである。デスティネーションは特定の出荷アドレスと特定の購入者の請求明細とを結合したものにすることができる。同じデスティネーションに送られる注文は「兄弟注文（sibling orders）」と呼ばれる。このアルゴリズムは２ステージからなっている。第１ステージでは、アルゴリズムは全ての兄弟注文が満たされるデスティネーション宛ての注文の出荷スケジュールを行う。注文は、その注文の全てのアイテムが現在インベントリにあるとき（つまり、在庫品がある（available ）とき）満たされ、出荷が可能になる。兄弟注文の各グループ毎に、アルゴリズムはこれらの兄弟注文を単一の結合注文に結合し、１つの注文だけが各デスティネーションに出荷されるようにスケジュールする。第２ステージでは、アルゴリズムは兄弟注文の一部が満たされないか、部分的に満たされている兄弟注文のグループを結合し、スケジュールする。アルゴリズムは部分的に満たされた各兄弟注文を満たされた兄弟注文と、まったく満たされない兄弟注文とに分割することができる。その後、アルゴリズムは満たされた全ての兄弟注文を単一の結合注文に結合し、その結合注文の出荷スケジュールを行う。いずれかのグループの兄弟注文が１つだけで、その注文が部分的に満たされていれば、一実施形態によるアルゴリズムはそのデスティネーションに余分の出荷が行われるのを防止するためにその注文を分割しない。

第２ステージでは、アルゴリズムはグループ内のあるアイテムが次回に満たされる時期（next fulfillment time ）を基準にしたシーケンスで、兄弟注文のグループを選択し、スケジュールすることができる。兄弟注文のグループが次回に満たされる時期とは、その兄弟注文グループ内のアイテムが満たされる最小限の予定時期である。例えば、ある兄弟注文グループにまだ満たされていないアイテムがいくつかあり、そのアイテムが満たされる予定時期が３日から１４日の範囲内にあれば、そのグループの次回に満たされる時期は３日となる。アルゴリズムはまず、次回に満たされる時期が最長である兄弟注文グループを最初にスケジュールすることから始める。例えば、６つのグループがあって、それぞれの次回に満たされる時期が３、５、７、１０、１１、および１４日であれば、アルゴリズムは、まず、次回に満たされる時期が１４日であるグループ内の兄弟注文を選択してスケジュールし、次に、次回に満たされる時期が１１日であるグループを選択してスケジュールし、以下、同様にスケジュールしていく。次回に満たされる時期が短いグループのスケジュールを遅らせることによって、アルゴリズムは、追加のアイテムが出荷可能となって（次回に満たされる時期が短いために）、スケジュール済みの注文と結合される機会を増加する。

ステップ７０１〜７０３は促進注文選択アルゴリズムの第１ステージを示し、ステップ７０４〜７０６は促進注文選択アルゴリズムの第２ステージを示している。ステップ７０１〜７０３で、アルゴリズムはループに入って、全ての兄弟注文が満たされるグループを選択し、注文を結合する。ステップ７０１で、アルゴリズムは次に満たされる全ての兄弟注文を持つグループを選択する。ステップ７０３で、かかる全てのグループがすでに選択されていれば、アルゴリズムはステップ７０４で第２ステージに進む。そうでなければアルゴリズムはステップ７０３に進む。ステップ７０３で、アルゴリズムは選択したグループ内の注文を結合し、スケジュールしてから、ループしてステップ７０１に戻る。ステップ７０４で、アルゴリズムは次回に満たされる時期が最長である、次の兄弟注文グループを選択する。ステップ７０５で、かかる全てのグループがすでに選択されていれば、アルゴリズムは完了し、そうでなければステップ７０６に進む。ステップ７０６で、アルゴリズムは選択したグループ内の注文を結合し、スケジュールしてから、ループしてステップ７０４に戻る。促進注文選択アルゴリズムが実行中のとき、新しい注文と新しいインベントリが受信される場合がある。そのような新しい注文と新しいインベントリが受信されると、アルゴリズムはリスタートし、これらの新しい注文をそれぞれに見合った形でスケジュールし、結合する。

アルゴリズムは２ステージからなるものとして説明してきたが、アルゴリズムをインクリメント方式で実現し、各注文がスケジュールされた後で第１ステージと第２ステージの評価がやり直されるようにすることも可能である。当業者ならば理解されるように、これらのステージの可能とされる組み合わせは他にもあり、その場合でも、表される基本的アルゴリズムは同じである。

図１０乃至図１２は、本発明の一実施形態における階層データ入力メカニズムを示した図である。ユーザから情報を収集するとき、Ｗｅｂページは全てがディスプレイ上に同時に収まらないような、長い一連のデータ入力フィールドからなっているのが代表的である。従って、ユーザは情報を入力するためにＷｅｂページをスクロールしていく必要がある。データ入力フィールドがディスプレイ上に同時に収まらないときは、ユーザは入力しようとするデータのタイプと編成を全体的に把握することが困難である。階層データ入力メカニズムによると、ユーザは全てのデータ入力フィールドがディスプレイ上に同時に収まらない場合であっても、入力しようとするデータの全体的編成を理解することができる。図１０は、そこに入力されるサンプル・フォームの全体的フォーマットを示す図である。このサンプル・フォームは、Ａ、Ｂ、Ｃ、およびＤの文字で示した種々のセクションを含んでいる。ユーザが「スタート」ボタンを選択すると、セクションＡはカストマ名とアドレスのデータ入力フィールドが含まれるように拡大される。図１１はセクションＡの拡大を示している。セクションＡだけが拡大されているので、ユーザはセクションＡのデータ入力フィールドと他のセクションの要約情報を同時に見ることができる。その後、ユーザは表示されている種々のデータ入力フィールドにデータを入力する。入力を完了したら、ユーザは「次へ」または「戻る」ボタンのどちらかを選択する。「次へ」ボタンを選択すると、セクションＡは縮小され、セクションＢが拡大されるので、財務情報を入力することができる。図１２はセクションＢの拡大を示している。「戻る」ボタンを選択すると、セクションＡは縮小し、図１０に示すように表示される。この縮小と拡大は各セクション毎に繰り返される。データ入力を行っている途中で、エラーが検出されると、Ｗｅｂページが生成され、エラーのあるデータ入力フィールドの近くに（例えば、下の行に）エラー・メッセージがある。このＷｅｂページはユーザにエラーを知らせるためにクライアント・システムによって表示される。さらに、データ「入力」フィールドの各々は、ユーザがそのデータ入力フィールドをクリックするか、あるいはそのデータ入力フィールドに関連する「編集」ボタンを選択するまでは編集ができないようになっている。このようにすると、ユーザが編集フィールドのコンテンツを誤って変更することが防止される。ユーザがあるデータ入力フィールドをクリックすると、新しいＷｅｂページがユーザに示されるので、そのフィールドに関連するデータの編集が可能になる。編集が完了すると、編集データはデータ「入力」フィールドに表示される。以上のように、このフォームのフィールドは直接に編集できないので、「named-submit」ボタンも、Ｊａｖａも不要である。また、種々のデータ入力オプション（例えば、ラジオボタン）はフィールドを編集しようとするときだけ新しいＷｅｂページに表示されるので、このフォームはコンパクト化されている。

本発明の他の実施形態によれば、シングル・アクションを使用して特定の受取人（一人または複数）にギフトを贈るメカニズムが提供されている。アイテムを記述している情報が表示されるとき、システムは受取人を特定した後、「贈与（GIVE）」ボタンを選択してその特定受取人にアイテムを贈るように指示を表示する。ユーザがギフトを贈ろうとする受取人が一人だけのときは、ユーザはｅメール・アドレスといった、その受取人の識別情報を入力する。ユーザが二人以上の受取人にギフトを贈るときは、ユーザは各受取人の識別情報を入力することができるが、別の方法として、ユーザはグループの各メンバ（つまり、受取人）の識別情報に関連付けられたグループ名を入力することも可能である。システムは識別情報を使用してギフトの発送アドレスを特定する。以下で詳しく説明するように、システムは種々のデータベースを使用して、特定された受取人の情報を探し出すことができる。

図１３及び図１４は、シングル・アクションを使用して、あるアイテムをギフトとして一人または複数の受取人に贈る方法を示す図である。図１３は、ギフトを一人の受取人に贈る場合を示す図である。セクション１０１〜１０４は図１で説明したものと同じである。ギフト贈与セクション９０１は指示サブセクション９０１ａ、識別情報サブセクション９０１ｂ、およびシングル・アクション贈答サブセクション９０１ｃを含んでいる。受取人にギフトを贈るには、ユーザはその受取人のｅメール・アドレスを識別情報サブセクション９０１ｂに入力し、次にシングル・アクション贈答サブセクション９０１ｃを選択する。システムはｅメール・アドレスを受け取ると、そのｅメール・アドレスを使用して受取人の発送アドレスを探し出す。これについては、以下で詳しく説明する。システムはユーザに対するアイテム請求書を、シングル・アクション注文のときそのユーザに関してストアされていた情報に基づいて発行し、発送アドレスにいる受取人にアイテムを出荷する。以下で説明するように、このシステムによると、ユーザは多種類の識別情報を指定することができる。

図１４は、ギフトを複数の受取人に贈る場合を示している。ギフト贈答セクション９０２は指示サブセクション９０２ａ、グループ名サブセクション９０２ｂ、およびシングル・アクション贈答サブセクション９０２ｃを含んでいる。複数の受取人にギフトを贈るには、ユーザは受取人を特定するグループの名前をグループ名サブセクション９０２ｂに入力し、次にシングル・アクション贈答サブセクション９０２ｃを選択する。システムはグループ名を使用して、そのグループ名に関連付けられた受取人のリストを特定する。図１５は、グループを作成し、そのグループに関連する受取人（つまり、メンバ）の識別情報を入力するためのグリッドを示す図である。ユーザはグループ名をグループ名セクション１００１に入力し、次に受取人に関する情報をメンバ情報セクション１００２の各行に入力する。ユーザはグループに関連する各受取人に関する情報を、ユーザが知っている限り入力することができる。例えば、ユーザはあるユーザにはｅメール・アドレスだけを入力し、他の受取人には氏名、ｅメール・アドレス、および発送アドレスを入力することができる。システムはグループに関連する各受取人にギフトを送るように要求を受けると、システムは各受取人に関してストアされていた情報を使用して、ギフトの発送を行うために必要な追加情報を特定する。これについては、以下で説明する。システムは各受取人の特定された追加情報をストアしておくこともできるので、その後で別のアイテムがその受取人に贈られるとき、そのアイテムの発送を行うために必要な追加情報を即時に検索することができる。別の方法として、可能な限りの受取人に関する情報を収めている、ユーザ用のシングル・アドレス帳（address book）を保存しておくこともできる。ユーザは、アドレスがアドレス帳にある受取人の何人かを指示することによってグループを指定する。アドレス帳を使用すると、一人または複数の受取人を共通して持つ複数のグループの維持が容易になる。さらに、ユーザは受取人に関する追加情報をいつでも与えることができるので、アイテムの発送を行うための十分な情報の検索が迅速化される。

本発明によれば、ギフト注文を受け取り、ギフト注文に指定されていない追加発送情報を収集し、追加発送情報に基づいてギフトを発送することによってギフトの発送をコーディネートするコンピュータ・ベースの方法およびシステムも提供されている。本発明の一実施形態であるギフト発送システムは、ＷＷＷ上に用意されたＷｅｂページを通してギフト注文を受信する。ギフト注文は受取人に発送すべきギフトを指定している。受取人はその受取人の発送アドレスを含んでいない情報によって特定することができる。例えば、受取人は、氏名および電子メール・アドレスや電話番号などの、コンタクト先情報だけによって特定することが可能である。ギフト発送システムは十分な発送情報を得るために受取人にコンタクトすることを試みる。コンタクトに失敗すると、ギフト発送システムは種々の情報データベースをサーチして追加コンタクト先情報を特定する。十分な発送情報が得られると、ギフトは受取人に発送され、ギフト贈答者にその通知が行われる。しかし、十分な発送情報が得られなかったときは、ギフトが発送できなかったとギフト贈答者に通知される。

図１６は、ギフト発送システムの全体的流れを示すフロー図である。ステップ１１０１で、ギフト発送システムはギフトの注文をギフト贈答者から受け取る。一実施形態では、注文はＷｅｂページを通してアクセスすることによって受け取られるが、音声電話コール、郵便メール、ファクシミリ、または電子メールなどの他の通信モードで受け取ることも可能である。ステップ１１０２で、ギフト発送システムはギフトの受取人にコンタクトすることを試みる。ギフト注文は受取人の電子メール・アドレスや電話番号などの、受取人のコンタクト先情報を指定することができる。ギフト注文と一緒に与えられたコンタクト先情報に基づいて、電子メールまたは自動音声電話コールで初回に受取人にコンタクトして、十分な発送情報を収集する試みが行われる。別の方法として、ユーザが受取人とのコンタクトを音声電話で試みることも可能である。ステップ１１０３で、初回のコンタクトに成功すれば、システムはステップ１１０６に進み、そうでなければステップ１１０４に進む。ステップ１１０４で、システムは追加コンタクト先情報を収集することを試みる。システムはギフト注文と一緒に与えられた情報を使用して、種々のデータベース・ソースから追加コンタクト先情報を得ることができる。例えば、システムは受取人の氏名または受取人の電子メール・アドレスを使用して、インターネット・ベースのデータベース・システムにアクセスすることができる。ステップ１１０５で、システムが上記追加のソースから追加コンタクト先情報を取得していれば、システムはループしてステップ１１０２に戻り、追加コンタクト先情報を使用して受取人にコンタクトすることを試み、そうでなければ、システムはステップ１１１１に進む。ステップ１１０６で、システムは成功したコンタクトから発送情報を収集する。例えば、成功したコンタクトが電話コールであれば、電話コールを行ったオペレータが発送情報を入力することが好ましい。成功したコンタクトが電子メール交換であれば、システムが受取人の応答メッセージを解析して発送情報を収集することが好ましい。ステップ１１０７で、システムは発送情報が正しいかどうかを検証する。システムは、全ての正しいストリート・アドレスのリストを収容している種々のデータベースを使用してアドレスを検証することができる。ステップ１１０８で、発送情報が正しいと検証されれば、システムはステップ１１０９に進み、そうでなければステップ１１１１に進む。ステップ１１０９で、システムはギフトを受取人に送付する。ステップ１１１０で、システムはギフトが正常に送付されたことを通知する電子メールをギフト贈答者に送信する。ステップ１１１１で、十分な発送情報が収集できないか、あるいは発送情報が正しいと検証できなかったときは、システムはギフトが発送できなかったため保留（on hold）にされたとの通知を行うメッセージを（例えば、電子メールで）ギフト贈答者に送信する。

別の実施形態（図示せず）では、受取人にコンタクトする試みがステップ１１０３で失敗していれば、システムはデータベースおよび図１０乃至図１２を参照して以下に述べるものと類似の他のソースなどの、受取人以外のソースから受取人の追加発送情報を取得することを試みる。システムが受取人の十分な発送情報を上記の方法で取得できるときは、システムは取得した発送情報を使用してギフトを受取人に送付することが好ましい。

図１７は、ギフト発送システムのコンポーネントを示すブロック図である。コンピュータ・システム１２０１は、中央処理ユニット、メモリ、およびディスク・ドライブ装置やＣＤ−ＲＯＭなどの周辺デバイスを装備している。ギフト発送システムは注文入力システム１２０２と注文発送システム１２０３を含んでいる。注文入力システムは、ギフト贈答者がギフト注文を入力するときのユーザ・インタフェースとなるものである。一実施形態における注文入力システムは、ギフト・データベース１２０４にアクセスするＷｅｂページを含んでいる。ギフト贈答者は用意されたＷｅｂページを使用して、どのギフトを受取人に送るべきかを選択する。ギフト贈答者はさらに、受取人を記述した情報を提供する。その後、注文入力システムは注文情報を注文データベース１２０５にストアする。ギフト発送システムは追加発送情報の検索を制御し、ギフトが正しく受取人に発送されるようにする。ギフト発送システムは注文データベースから情報を検索し、ギフト注文と一緒に提供された情報に基づいて受取人にコンタクトすることを試みる。その情報に基づいて受取人にコンタクトできなければ、ギフト発送システムはカストマ・データベース１２０６やインターネット・ベースのデータベース１２０８などの、他のデータベース・ソースにアクセスして、受取人の追加コンタクト先情報を収集する。

図１８は、ギフト注文の種々ステージを示すステート図である。ギフト注文は６ステート、すなわち、受信済み（received）、応答待ち（response pending）、発送情報検証（verifying delivery information）、追加コンタクト先情報収集（collecting additional contact information ）、保留中（on hold）、および発送スケジュール済み（scheduled for delivery）の１つに置かれている。初めに、注文が受信されると、システムは注文を受信済みステート１３０１に置く。システムがギフト贈答者によって与えられた情報を使用して受取人にコンタクトすることを試みると、ギフト注文は応答待ちステート１３０２に変わる。応答待ちステートは、コンタクトの試みが進行中であるが応答が受取人からまだ受信されていないことを示している。十分な応答が割り当て時間（例えば、２４時間）以内に受取人から受信されると、ギフト注文は発送情報検証ステート１３０３に変わる。発送情報検証ステートにあるとき、システムは発送情報が正しいかどうかを検証することを試みる。発送アドレスが正しければ、ギフト注文は発送スケジュール済みステート１３０４に入る。初回応答が不十分であるか、割り当て時間内に受信されていなければ、システムはギフト注文を追加コンタクト先情報収集ステート１３０５に置く。追加コンタクト先情報収集ステートにあるとき、システムは追加情報ソースをサーチして受取人に関する追加コンタクト先情報を判断する。追加コンタクト先情報が見つかれば、システムは追加のコンタクトを試み、ギフト注文を応答待ちステート１３０２に置く。他方、追加コンタクト先情報が見つからなければ、システムはギフト注文を保留中ステート１３０８に置く。

さらに別の好適実施形態では、初回応答が不十分であれば、システムはギフト注文を追加発送情報収集ステートに置く（図示せず）。追加発送情報収集ステートにあるとき、システムは追加情報ソースをサーチして受取人の追加発送情報を取得する。システムが上記の方法で十分な発送情報を取得できれば、システムはギフト注文を発送情報検証ステート１３０３に置く。そうでなければ、システムはギフト注文を保留中ステート１３０８に置く。

図１９は、ギフト注文の受信を制御するルーチンを示すフロー図である。ギフト注文受信ルーチンはギフト贈答者とのやりとりを制御して、ギフト・データベースからギフトを選択し、受取人に関する情報を受信し、支払いを受け取り、ギフト注文をデータベースにストアする。このルーチンにより、電子的に受信したギフト注文を処理する。当業者ならば理解されるように、他形態のギフト注文受信を取り扱う類似のルーチンを開発することも可能である。ステップ１４０１で、ルーチンはギフトをギフト贈答者から受取人に送る要求を、Ｗｅｂページを通して電子的に受信する。ステップ１４０２で、ルーチンはギフト贈答者とのセッションを作成する。このセッションはギフト贈答者およびギフト発送システムとのやりとりをトラッキングするために使用される。ステップ１４０3 で、このルーチンはギフト選択情報を受け取る。ギフト選択情報は、出荷可能なギフトがギフト・データベースから表示されたときに、それに応答して選択することができる。ステップ１４０４で、ルーチンはギフト贈答者から受取人コンタクト先情報を受信する。受取人コンタクト先情報の代表例としては、受取人の氏名と電子メール・アドレスがある。ステップ１４０５で、ルーチンは支払い情報を受信する。この支払い情報はクレジット・カード、デビット・カード、または電子マネー（digital cash）といった電子形態にすることも、小切手や為替といった従来形態にすることも可能である。従来形態のときは、ギフト注文は支払いの受信待ちの追加ステートに置くことができる。ステップ１４０６で、支払いが承認されていれば、ルーチンはステップ１４０８に進み、そうでなければ、ルーチンは支払いが拒否されたことをギフト贈答者に通知する。ステップ１４０８で、ルーチンはギフト注文にギフト注文トラッキング番号を割り当てる。このギフト注文トラッキング番号は、その処理期間中にギフト注文を特定するためにシステムによって使用される。ステップ１４０９で、ルーチンはギフト注文情報をギフト注文データベースにストアする。ステップ１４１０で、ルーチンはギフト注文が受け付けられたことをギフト贈答者に通知する。ステップ１４１１で、ルーチンはギフト贈答者とのセッションを終了する。

図２０は、受取人との最初のコンタクトの試みを制御するルーチンを示すブロック図である。最初のコンタクトは電子メール・アドレスや電話番号などの、ギフト贈答者から与えられたコンタクト先情報を使用して行われる。十分な情報が与えられていないため受取人にコンタクトする初回の試みさえもできないときは、ギフト発送システムは種々のデータベースをサーチし、受取人の氏名に基づいてコンタクト先情報を取得する。ステップ１５０１ａで、受取人の電子メール・アドレスがギフト注文に与えられていれば、ルーチンはステップ１５０１ｂに進み、そうでなければステップ１５０２ａに進む。ステップ１５０１ｂで、ルーチンは与えられた電子メール・アドレスに電子メールを送信する。この電子メールはギフトが受取人に送られることを示す情報を収めており、ギフトの発送情報を要求する。電子メールはシステムによって割り当てられたトラッキング番号を含んでいるので、応答メールが受信されたとき、ギフト発送システムはそれがどのギフト注文に対応するのかを判断することができる。ステップ１５０２ａで、受取人の電話番号が与えられていれば、ルーチンは１５０２ｂに進み、そうでなければ、ルーチンは受取人にコンタクトする他の様々な試みを続ける。例えば、ファクシミリ番号が与えられていれば、ファクシミリ・メッセージはその番号に送られる。ステップ１５０２ｂで、ルーチンは受取人との初回電話コンタクトをスケジュールする。初回電話コンタクトを自動音声電話システムを通して行うと、メッセージを電話応答する人にも、応答マシンにも残しておくことができる。別の方法として、人間のオペレータが初回音声コンタクトを行うことも可能である。初回コンタクトが行われた後、ギフト注文は応答待ちステートに置かれる。

図２１は、初回音声電話コンタクトの処理を制御するルーチンを示すフロー図である。このルーチンは人間のオペレータのための情報を表示することも、自動化オペレータに情報を与えることも可能である。ステップ１６０１で、電話に対する応答があれば、ルーチンはステップ１６０２に進み、そうでなければ、ルーチンはギフト注文を初回コンタクトのためにスケジュールしたままにしておく。ステップ１６０２で、メッセージが人間または音声メール・システムに残されていれば、ルーチンはステップ１６０３に進み、そうでなければ、ルーチンはギフト注文を初回コンタクトのためにスケジュールしたままにしておく。ステップ１６０３で、十分な応答が受信されていれば、ルーチンはステップ１６０５に進み、そうでなければステップ１６０４に進む。ステップ１６０４で、ルーチンは受取人に関する追加コンタクト先情報を検索するようにギフト注文をスケジュールする。ステップ１６０５で、ルーチンは受取人に関する追加情報で注文データベースを更新する。ステップ１６０６で、ルーチンはその発送情報が検証されるようにギフト注文をスケジュールし、そのステートを発送情報検証に変更する。

図２２は、初回応答の処理を制御するルーチンを示すフロー図である。この初回応答は電子メール、音声電話、またはファクシミリ・メッセージで行うことができる。ステップ１７０１で、トラッキング番号が応答に含まれていれば、ルーチンはステップ１７０２に進み、そうでなければステップ１７０４に進む。ステップ１７０２で、ルーチンはギフト注文データベースを使用してトラッキング番号を検証する。ステップ１７０３でトラッキング番号が正しいと検証されていれば、ルーチンはステップ１７０６に進み、そうでなければステップ１７０４に進む。ステップ１７０４で、ルーチンは応答で与えられた情報に基づいてトラッキング番号を見付けることを試みる。ステップ１７０５で、トラッキング番号が見つかれば、ルーチンはステップ１７０６に進み、そうでなければステップ１７０７に進む。ステップ１７０６で、応答に十分な発送情報が含まれていて、ギフト注文が発送可能であれば、ルーチンはステップ１７０８に進み、そうでなければステップ１７０７に進む。ステップ１７０７で、ルーチンは追加発送情報を検索するように注文をスケジュールする。ステップ１７０８で、ルーチンはその発送情報が検証されるように注文をスケジュールし、そのステートを発送情報検証に変更する。

図２３は、追加コンタクト先情報の収集を制御するルーチンを示すフロー図である。このルーチンはギフト注文で与えられた情報に基づいて種々のデータベース・ソースをサーチする。例えば、ステップ１８０１で、ルーチンは、Switchboard ， Four11 ，およびAccumailなどの、インターネット・ベースの電話および電子メール・ディレクトリをサーチする。ステップ１８０２で、ルーチンはSelect Phoneなどの電話および電子メール情報の種々ＣＤ−ＲＯＭデータベースをサーチする。ステップ１８０３で、ルーチンはカストマ情報のローカル・データベースをサーチする。カストマ情報のローカル・データベースは以前の受取人とギフト贈答者の情報を収めている。ステップ１８０４で、ルーチンは、 Digital Equipmento 社の Alta Vista や Infoseek 社のUltraseek などの、種々のインターネット・ベースのサーチ・エンジンをサーチする。ステップ１８０５で、ルーチンは電子メール・アドレスまたは電話番号を調べて受取人の地理的ロケーションを特定する。具体的には、ルーチンは InterNIC Registration Services of Network Services にアクセスして、受取人の電子メール・アドレスのドメイン・ネーム登録を調べる。別の方法として、ルーチンは市外局番と電話番号プレフィックスの標準テーブルにアクセスして、受取人の地理的ロケール（local ）を判断する。ギフト発送システムはこれらの情報ソースの各々、これらの情報ソースのサブセット、または追加情報ソースを使用して追加情報を探し出すことができる。ステップ１８０６で、ルーチンは検索情報を分析し、受取人に最も近い情報を地理的またはコンテキスト合致に基づいて判断する。この分析は電子的に行うことも、人間のオペレータと対話しながら行うこともできる。ステップ１８０７で、ルーチンにより人間のオペレータに情報を表示して、以後の処理に関する指示を要求する。ステップ１８０８で、このルーチンは人間のオペレータに情報を表示し、更なる処理についての指示を要求する。これらの指示としては、十分な発送情報が収集されなかったため注文を保留中に置くこと、初回コンタクトを受取人に送信すること、ギフトの発送をそのまま続けること、などが可能である。

図２４は、発送情報の検証を制御するルーチンを示すフロー図である。ギフト発送システムは発送情報を検証して、ギフトが発送可能なアドレスに送られるようになっているかを確かめる。ステップ１９０１で、ルーチンは発送情報の有効性を自動的にチェックする。ルーチンはU.S. Postal Service アドレスのデータベースを使用して、発送アドレスが有効なU.S. Postal Service アドレスであるかどうかを判断する。ステップ１９０２で、アドレスが有効であれば、ルーチンはステップ１９０６に進み、そうでなければステップ１９０３に進む。ステップ１９０３で、ルーチンはアドレスをマニュアルで検証するように人間のオペレータに要求する。ステップ１９０４で、オペレータがマニュアルでアドレスを正しいと検証していれば、ルーチンはステップ１９０６に進み、そうでなければステップ１９０５に進む。ステップ１９０５で、ルーチンは注文が満たされないことをギフト贈答者に通知し、注文を保留中に置く。ステップ１９０６で、ルーチンはギフトを発送するようにスケジュールし、その旨をギフト贈答者に通知する。

以上、種々の実施形態を示して本発明について説明してきたが、本発明はこれらの実施形態に限定されるものではない。当業者ならば理解されるように本発明の精神の範囲内で種々の変更および改良が可能である。例えば、サーバ・システムはクライアントＩＤを、最近にクライアント・システムを使用した複数のカストマにマッピング（対応付けること）することができる。その後、サーバ・システムを使用すれば、ユーザは、好ましくは、部分的購入者固有注文情報の表示に基づいてこれらのマッピングの１つを選択することで本人であることを示すことができる。また、種々の異なるシングル・アクションを使用して注文を出すことができる。例えば、音声コマンドで購入者が伝えること、キーを購入者が押すこと、テレビジョン・リモート・コントロール・デバイス上のボタンを購入者が押すこと、または、いずれかのポインティング・デバイスを使用した選択を購入者が行うこと、などが可能である。シングル・アクションに先立って購入者の複数の物理的動き（例えば、マウス・ポインタがボタン上に置かれるようにマウスを動かすこと）が必要になることがあっても、ここでいうシングル・アクションとは、一般的に、注文を出すことを指示し、クライアント・システムによって受信されるシングル・イベントのことである。最後に、購入者は、カストマがサーバ・システムへのアクセスするときカストマによって与えられ、各メッセージと一緒にサーバ・システムに送られる一意的なカストマＩＤで特定することも可能である。このカストマＩＤは、クライアント・システム側に永続的にストアしておくこともできるので、購入者はアクセスを行う度に自分のカストマＩＤを入れ直す必要がなくなる。本発明の範囲は請求の範囲の記載に基づいてのみ判断されるものである。

２１０ サーバ・システム
２１１ サーバ・エンジン
２１２ クライアントＩＤ／カストマ・テーブル
２１３ Ｗｅｂページ
２１４ カストマ・データベース
２１５ 注文データベース
２１６ インベントリ・データベース
２２０ クライアント・システム
２２１ ブラウザ
２２２ クライアントＩＤ
２３０ 通信リンク
９０１ ギフト贈答セクション
９０１ａ 指示サブセクション
９０１ｂ 識別情報サブセクション
９０１ｃ シングル・アクション贈答サブセクション
９０２ ギフト贈答セクション
９０２ａ 指示サブセクション
９０２ｂ グループ名サブセクション
９０２ｃ シングル・アクション贈答サブセクション
１００１ グループ名セクション
１００２ メンバ情報セクション
１２０１ コンピュータ・システム
１２０２ 注文入力システム
１２０３ 注文発送システム
１２０４ ギフト・データベース
１２０５ 注文データベース
１２０６ カストマ・データベース
１２０８ インターネット・ベース・データベース
１３０１ 受信済みステート
１３０２ 応答待ステート
１３０３ 発送情報検証ステート
１３０４ 発送スケジュール済みステート
１３０５ 追加コンタクト先情報収集ステート
１３０８ 保留中ステート

Claims (12)

1. アイテムを注文するためのクライアント・システムにおける方法であって、
   前記クライアント・システムのクライアント識別子を、前記クライアント・システムのコンピュータによりサーバ・システムから受信すること、
   前記クライアント・システムで前記クライアント識別子を永続的にストアすること、
   複数のアイテムの各々のアイテムについて、
   前記アイテムを特定する情報と、前記特定されたアイテムを注文するのに実行すべきシングル・アクションの指示部分とを、前記クライアント・システムのディスプレイに表示することであって、前記シングル・アクションは、前記特定のアイテムの注文を完成させるために前記クライアント・システムに要求される唯一のアクションであり、前記クライアント・システムに対して前記シングル・アクションの実行に続いて前記注文の確認を要求しないこと、および
   前記シングル・アクションが実行されることに応答して、前記特定されたアイテムの注文要求と前記クライアント識別子とを、前記サーバ・システムに送信することであって、前記注文要求は、前記シングル・アクションによって示されたシングル・アクション注文要求であり、前記クライアント識別子は、ユーザのアカウント情報を特定することを備え、
   前記サーバ・システムが、前記シングル・アクションによって示されたシングル・アクション注文要求と、前記クライアント識別子に関連付けられた１または複数の以前のシングル・アクション注文要求とを組み合わせ、１つの注文に結合することを特徴とする方法。
2. 前記１つの注文は、他のシングル・アクション注文要求から時間間隔９０分内にあるシングル・アクション注文要求を含むことを特徴とする請求項１に記載の方法。
3. 前記１つの注文は、前記アイテムの有用性に基づいてシングル・アクション注文要求を結合し、前記アイテムの有用性は、短期間または長期間に分類され、前記短期間は、前記注文要求から１週間以内に出荷されるべき注文に相当し、前記長期間は、前記注文要求から出荷までに１週間以上かかる注文に相当することを特徴とする請求項１に記載の方法。
4. 前記１つの注文は、前記アイテムの有用性に基づいてシングル・アクション注文要求を結合し、前記アイテムの有用性は、短期間または長期間に分類され、前記短期間は、在庫のある注文に相当し、注文要求を受けたときに出荷可能であり、前記長期間は、注文要求を受けたときに出荷可能でない注文に相当することを特徴とする請求項１に記載の方法。
5. 前記クライアント・システムでシングル・アクション注文が許可されていないとき、前記ユーザがシングル・アクション注文ができるようにするシングル・アクション注文オプションを、前記サーバ・システムから受信してディスプレイに表示することをさらに備えたことを特徴とする請求項１に記載の方法。
6. 前記ディスプレイに表示することは、前記クライアント・システムのユーザの同一性に関する部分的情報、部分的出荷情報、または部分的支払い情報を提供することを含むことを特徴とする請求項１に記載の方法。
7. 前記クライアント・システムは、前記シングル・アクション注文要求を介して注文がなされたことを確認するための情報を受信し、前記ユーザに前記注文を見直し、変更する機会を与えることを特徴とする請求項１に記載の方法。
8. 前記ユーザがすでになされた前記注文を変更し、キャンセルする場合にのみ、付加的なアクションが要求されることを特徴とする請求項１に記載の方法。
9. アイテムの注文を受け付けるサーバ・システムにおける方法であって、
   前記サーバ・システムからクライアント・システムのコンピュータへ、前記クライアント・システムで永続的にストアしておくための前記クライアント・システムのクライアント識別子を送信すること、
   複数のアイテムの各々のアイテムについて、
   前記アイテムを特定する情報と、前記特定されたアイテムを注文するのに実行すべきシングル・アクションの指示部分とを、前記クライアント・システムのディスプレイに表示することであって、前記シングル・アクションは、前記特定のアイテムの注文を完成させるために前記クライアント・システムに要求される唯一のアクションであり、前記クライアント・システムに対して前記シングル・アクションの実行に続いて前記注文の確認を要求しないこと、および
   前記クライアント・システムで前記シングル・アクションが実行されることに応答して、前記特定されたアイテムの注文要求と前記クライアント識別子とを受信することであって、前記注文要求は、前記シングル・アクションによって示されたシングル・アクション注文要求であり、前記クライアント識別子は、ユーザのアカウント情報を特定すること、および
   前記シングル・アクション注文要求を受信すると、前記サーバ・システムにおいて、前記シングル・アクションによって示されたシングル・アクション注文要求と、前記クライアント識別子に関連付けられた１または複数の以前のシングル・アクション注文要求とを組み合わせ、１つの注文に結合すること
   を備えたことを特徴とする方法。
10. 前記１つの注文に結合することは、
    前記シングル・アクションによって示されたシングル・アクション注文要求と、全てのアイテムが共通の宛先に配達される兄弟注文の１または複数のグループに出荷することができる場合の前記１または複数の以前のシングル・アクション注文要求とを組み合わせる第１ステージと、
    前記シングル・アクションによって示されたシングル・アクション注文要求と、全てのアイテムが共通の宛先に配達される兄弟注文の１または複数のグループに出荷することができず、後に配送される場合の前記１または複数の以前のシングル・アクション注文要求とを組み合わせる第２ステージと
    を含むことを特徴とする請求項９に記載の方法。
11. 前記シングル・アクションの実行に続いて、前記ユーザに、前記注文をキャンセルする第２のアクションを実行するまでの間に制限された時間期間を提供することを特徴とする請求項９に記載の方法。
12. 前記サーバ・システムは、前記ユーザが、前記サーバ・システムが前記ユーザを正しく認識したことを確認できるだけの十分な情報であり、他人が、前記ユーザを特定するには不十分な情報を送信することを特徴とする請求項９に記載の方法。

Images