(57)【要約】　【課題】　任意のストアまたはストアの任意のサブセットにてトランザクションを実行できるように、ストアのセット間でクライアントの１回の認証を調整する方法を提供すること。　【解決手段】　参加サーバ及びコントローラ・サーバを含み、各参加サーバがコントローラ・サーバと通信できるサーバ・グループを持つクライアント／サーバ環境で、サーバ・グループのサーバ間で操作を調整する方法は、１）クライアント及びサーバ・グループのサーバの間でクライアント及びサーバの間で状態情報を受け渡す手順が制限されたまたは未定義のプロトコルを使用して通信するステップ、２）クライアントからサーバの１つに操作のリクエストを転送するステップ、及び３）リクエストに応答して複数のサーバ間でコントローラ・サーバと通信し、少なくともいくつかのサーバの操作を調整するステップを含む。【選択図】　図１
2004078967.tif 000002
【特許請求の範囲】
【請求項１】
　１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループを持ち、複数のコントローラ・サーバがコントローラ・サーバの階層の下のレベルになるようにされている、クライアント／サーバ環境にて、前記サーバ・グループのサーバ間で操作を調整する方法であって、
　クライアント及び前記サーバ・グループの少なくとも１つのサーバの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用して前記クライアント及び前記サーバの間で通信するステップと、
　前記クライアントから前記サーバの１つに操作のリクエストを転送するステップと、
　前記リクエストに応答して少なくとも１つの階層の下のレベルの複数のサーバ及びコントローラ・サーバの間で通信して、サーバ間の操作を調整するステップと、
　を含む、方法。
【請求項２】
　１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループを持つクライアント／サーバ環境にて、前記サーバ・グループのサーバ間で操作を調整する方法であって、
　クライアント及び前記サーバ・グループの少なくとも１つのサーバの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用して前記クライアント及び前記サーバの間で通信するステップと、
　前記クライアントから前記サーバの１つに操作のリクエストを転送するステップと、
　前記リクエストに応答して複数のサーバ及び少なくとも１つのコントローラ・サーバの間で通信して少なくともサーバのいくつかの操作を調整するステップと、
　少なくとも１つのサーバから前記クライアントによってプログラムを受け取り実行して、前記クライアントは前記サーバ・グループの少なくともいくつかの機能を実行するステップと、
　を含む、方法。
【請求項３】
　サーバ・グループのサーバ間でサーバの操作を調整するシステムであって、
　１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループと、
　状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用して前記サーバ・グループの少なくとも１つのサーバとの間で通信するクライアントと、
　前記クライアントから前記サーバの１つに複数のサーバによる参加を要求する操作についてのリクエストを転送する手段と、
　前記リクエストに応答して複数のサーバ及びそれらを調整する少なくとも１つのコントローラ・サーバの間で通信して、少なくとも１つの階層の下のレベルの複数のサーバ及び少なくとも１つのコントローラ・サーバの間で通信して少なくともいくつかのサーバの操作を調整する手段と、
　を含む、システム。
【請求項４】
　サーバ・グループのサーバ間でサーバの操作を調整するシステムであって、
　１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループと、
　前記サーバ・グループの少なくとも１つのサーバとの間で状態情報を受け渡す手順が制限されたまたは未定義の手順をもつプロトコルを使用して前記サーバとの間で通信するクライアントと、
　前記クライアントから前記サーバの１つに操作の複数のサーバによる参加を要求することについてのリクエストを転送する手段と、
　前記リクエストに応答して少なくとも１つのコントローラ・サーバを含むサーバとの間で通信して複数のサーバの操作を調整する手段と、
　少なくとも１つのサーバからプログラムを受け取り実行して、前記クライアントが前記サーバ・グループの少なくともいくつかの機能を実行する手段と、
　を含む、システム。
【請求項５】
　１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループを持ち、複数のコントローラ・サーバがコントローラ・サーバの階層の下にある、クライアント／サーバ環境にて、前記サーバ・グループのサーバ間で操作を調整する方法であって、
　クライアント及び前記サーバ・グループの少なくとも１つのサーバの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用して前記クライアント及び前記サーバの間で通信するステップと、
　認証を要求するサーバの１つにクライアントによって第１の操作についてのリクエストを転送するステップと、
　クライアントによってクライアント認証情報を与えるステップと、
　１つ以上のコントローラ・サーバによって前記クライアントによってクライアント認証情報を確認するステップと、
　１つ以上のコントローラ・サーバによってセッションＩＤを生成するステップと、
　１つ以上のコントローラ・サーバによってセッションＩＤを維持するステップと、
　１つ以上のコントローラ・サーバによって会話のセッションＩＤを保存して活用するステップと、
　前記クライアントによって、認証を要求するサーバの１つにクライアントによって第２の操作についてのリクエストを転送するステップと、
　前記会話において保存されて、クライアントを認証する１つ以上のサーバによって維持されている、セッションＩＤを使用するステップと、
　少なくとも１つの階層の下のレベルの複数のサーバ間で通信して、コントローラ・サーバの操作によって操作を調整するステップと、
　を含む、方法。
【請求項６】
　１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループを持ち、複数のコントローラ・サーバがコントローラ・サーバの階層の下にある、クライアント／サーバ環境にて、前記サーバ・グループのサーバ間で操作を調整する方法であって、
　クライアント及び前記サーバ・グループの少なくとも１つのサーバの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用して前記クライアント及び前記サーバの間で通信するステップと、
　前記クライアントから前記サーバの１つに複数のサーバによる参加を要求する操作のリクエストを転送するステップと、
　前記リクエストに応答して複数のサーバの操作を調整する少なくとも１つの階層の下のレベルの少なくとも１つのコントローラ・サーバとの間で通信して、少なくとも１つの階層の下のレベルの複数のコントローラ・サーバの操作を調整するステップと、
　を含む、方法。
【請求項７】
　１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループを持つクライアント／サーバ環境にて、前記サーバ・グループのサーバ間で操作を調整する方法であって、
　クライアント及び前記サーバ・グループの少なくとも１つのサーバの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用して前記クライアント及び前記サーバの間で通信するステップと、
　前記クライアントから、認証を要求するサーバの１つにクライアントによって第１の操作についてのリクエストを転送するステップと、
　クライアントによってクライアント認証情報を与えるステップと、
　１つ以上のコントローラ・サーバによってクライアント認証情報を確認するステップと、
　１つ以上のコントローラ・サーバによってセッションＩＤを生成するステップと、
　１つ以上のコントローラ・サーバによってセッションＩＤを維持するステップと、
　１つ以上のコントローラ・サーバによって会話におけるセッションＩＤを保存する手段を活用するステップと、
　前記クライアントから、認証を要求するサーバの１つにクライアントによって第２の操作についてのリクエストを転送するステップと、
　前記会話で１つ以上のコントローラ・サーバによって保持されている、セッションＩＤを使用するステップと、
　少なくとも１つのサーバから前記クライアントによってプログラムを受け取り実行して、前記クライアントは前記サーバ・グループの少なくともいくつかの機能を実行するステップと、
　を含む、方法。
【請求項８】
　１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループを持つクライアント／サーバ環境にて、前記サーバ・グループのサーバ間で操作を調整する方法であって、
　クライアント及び前記サーバ・グループの少なくとも１つのサーバの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用して前記クライアント及び前記サーバの間で通信するステップと、
　前記クライアントから前記サーバの１つに複数のサーバによる参加を要求する操作のリクエストを転送するステップと、
　前記リクエストに応答して複数のサーバ及びそれらを調整する少なくとも１つのコントローラ・サーバの間で通信してサーバの操作を調整するステップと、
　少なくとも１つのサーバから前記クライアントによってプログラムを受け取り実行して、前記クライアントが前記サーバ・グループにおいて実行されるステップと、
　を含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、一般的にはサーバ・グループ間で操作を調整する方法に関し、特にサーバ・グループ間でクライアントの認証、情報の収集、グループ・トランザクション、及び複数フェーズ・コミットを調整する方法に関する。本発明の好適な実施例はＷＷＷ（World Wide Web）上のトランザクションに関する。
【背景技術】
【０００２】
　電子取引は急激に増加しており、この傾向は特にＷＷＷで顕著である。Ｗｅｂサイトに出店する企業も増えている。消費者はＷｅｂサイトで製品のオンライン・ショッピングができる。こうした独立した仮想ストアを延長する形で、仮想モールまでＷｅｂに登場し始めている。
【０００３】
　現実のモールと同様、仮想モールも企業及び消費者の両方に資する機会を提供する。企業は、モール上に存在することから利益を得る可能性がある。例えば仮想モール上の仮想ストアは、初めは他のストアから商品を購入するためにアクセスした消費者の注意を引くこともできる。消費者は、モール上で消費及びサービスが統合され調整される機会から利益を得ることがある。仮想モールは、例えば多くの仮想ストアの商品及びサービスの総合ディレクトリを提供できる。また仮想モールは、モール上の全ての仮想ストアのための単独認証点（single point of authentication）となることもできる。更に仮想モールは、複数のストアが関係するグループ・トランザクションを調整することもできよう。
【０００４】
　これまで、Ｗｅｂに現れた仮想モールのアプローチは２種類ある。第１に、独立した仮想ストアとのハイパーリンクを持つＷｅｂページを提供するモールがある。第２に、同じＷｅｂサイト内で複数の仮想ストアを提供しているモールがある。これら後者のモールは、ＩＢＭのワールド・アベニュー・システム（http://mer．shop．ibm．com）、及びNetscapeのマーチャント・システム（http://home．netscape．com/comprod/products/iapps/capps/mersys．html）などのシステムを利用している。
【０００５】
　こうしたアプローチそれぞれに欠点がある。最初のアプローチは、ＵＲＬの収集を除いて独立したストア間で調整を行わない。もう１つのアプローチは、独立したストア間の調整を行うが、仮想ストアは１つのＷｅｂサイト内で実現し管理しなければならないという制限がある。従って、第２のアプローチで仮想モールに加わるためには、Ｗｅｂに仮想ストアを確立した企業は、その実現形態を大きく変更する必要があるかもしれない。
【０００６】
　よって、複数のＷｅｂサイトに分散できる独立した複数の仮想ストアを調整する方法が必要である。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
　本発明はサーバのグループ間で操作を調整する方法を対象とする。本発明の好適な実施例は、Ｗｅｂ上の複数の仮想ストアの調整に関係するが、本発明は他の形態のネットワーク通信にも適用される。
【０００８】
　本発明の目的は、クライアントが認証情報を求められた場合、認証を更に求められることなく、任意のストアまたはストアの任意のサブセットにてトランザクションを実行できるように、ストアのセット間でクライアントの１回の認証を調整する方法を提供する。
【０００９】
　本発明の他の目的は、複数のストアからの情報の統合を調整することである。例えばクライアントがアクセスした各ストアのショッピング・バスケットに含まれるアイテムを統合し、この情報の１つの表示をクライアントに与えることが望ましい。他の例として、クライアントが検索のためのキーワードを指定し、ストアの任意のサブセットにサーチ・リクエストを送り、組み合わせられたサーチ結果をクライアントに送ることができるようにすることが望ましい。
【００１０】
　本発明の他の目的は、複数のストアが関係するグループ・トランザクションのリクエストを調整することである。例えばクライアントはグループ購入を要求でき、これにはストア全体でアイテムのセットについて"オール・オア・ナッシング（all-or-nothing）"の購入が関係する。このような購入では、例えば別々のストアから組み合わせのいいジャケット及びスラックスを選ぶといったことが関係することもある。この種のリクエストは、ストア全体で１回のコミットまたは複数フェーズ・コミットと共に行うことができる。
【課題を解決するための手段】
【００１１】
　本発明のアーキテクチャはクライアント／サーバ環境であり、１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含むサーバ・グループがあり、参加サーバはそれぞれ少なくとも１つのコントローラ・サーバと通信できる。この環境で、本発明はサーバ・グループ内のサーバ間の操作を調整する方法を対象とする。方法のステップは、１）クライアント及びサーバの間で状態情報を受け渡す手順が制限された、または未定義のプロトコルを使用してクライアント及びサーバ・グループの少なくとも１つのサーバの間で通信するステップ、２）操作のリクエストをクライアントからサーバの１つへ転送するステップ、及び３）リクエストに応答して複数のサーバ間で少なくとも１つのコントローラ・サーバと通信し、少なくともいくつかのサーバの操作を調整するステップを含む。
【００１２】
　本発明の好適な実施例は、会話中のクライアント認証の調整及びクライアントによって要求されたグループ・トランザクションの調整を含む。会話中のクライアント認証を調整するために、本発明に従った好適な方法は、１）クライアント及びサーバの間で状態情報を受け渡すために手順が制限されたまたは未定義のプロトコルを使用してクライアント及びサーバ・グループの少なくとも１つのサーバの間で通信するステップ、２）認証を必要とする第１操作のリクエストをクライアントからサーバへ転送するステップ、３）クライアントによりクライアント識別情報を与えるステップ、４）コントローラ・サーバによりクライアント識別情報を確認するステップ、５）コントローラ・サーバによりクライアント認証情報を生成するステップ、６）サーバによりクライアント認証情報を維持するステップ、７）クライアント認証情報を会話で保存するためサーバにより手段を利用するステップ、８）認証を必要とするクライアントによる第２操作のリクエストをサーバの１つに転送するステップ、及び９）会話で保存されたクライアント認証情報及びサーバによって維持されるクライアント認証情報を使用してクライアントを認証するステップを含む。
【００１３】
　クライアントが要求したグループ・トランザクションを調整するために、本発明に従った好適な方法は、１）クライアント及びサーバの間で状態情報を受け渡すため、手順が制限されたまたは未定義のプロトコルを使用して、クライアント及びサーバ・グループの少なくとも１つのサーバの間で通信するステップ、２）複数のサーバによる参加を要求する操作のリクエストをクライアントからサーバの１つに転送するステップ、及び３）リクエストに応答してサーバ間で少なくとも１つのコントローラ・サーバと通信し、複数のサーバの操作を調整するステップを含む。
【発明を実施するための最良の形態】
【００１４】
　本明細書及び特許請求の範囲で用いているとおり、"クライアント"という用語は、コマンドをコマンドに関連したタスクを実行する他のプログラムまたはアプリケーション（サーバと呼ぶ）に発行するプログラムまたはアプリケーションである。
【００１５】
　本明細書及び特許請求の範囲で用いているとおり、"ＣＧＩ（共通ゲートウェイ・インタフェース）"という用語は、ＷＷＷクライアントがＷｅｂサイトでのプログラムの実行を要求できるメカニズムである。ＷｅｂサイトはＣＧＩプログラムを実行し、プログラムの出力をクライアントに送る。
【００１６】
　本明細書及び特許請求の範囲で用いているとおり、"接続法（continuation）"という用語は、クライアントがサーバに送ることのできる新しいリクエストであり、クライアントによる前のリクエストに応答してサーバにより与えられたものである。クライアント／サーバ通信での接続法の例としてハイパーテキスト・リンク（またはハイパーリンク）がある。クライアントがサーバにリクエストを出すときは、サーバはその応答に接続法を加えることができる。サーバにより与えられる接続法は任意の有効なリクエストでよいが、有益な接続法は、一般的にはクライアントによる最初のリクエストと論理的に関係する。
【００１７】
　本明細書及び特許請求の範囲で用いているとおり、"会話"という用語は、クライアント及びサーバの間の通信のシーケンスであり、サーバは会話の中でクライアントからの各リクエストに対して１組の接続法で応答し、クライアントは常にサーバから与えられた１組の接続法から次のリクエストを拾う。ＷＷＷではハイパーテキスト・リンクは接続法の例であり、クライアントは、サーバにより与えられたハイパーテキスト・リンクを辿るときにはサーバとの会話が関係する。具体的には、ＨＴＭＬの一連のＷｅｂページｈ1、ｈ2、．．．ｈnが会話をなすのは、１）ページｈ1、ｈ2、．．．ｈnが全てクライアントによって表示された場合、及び２）１＜ｉ＜＝ｎのときの全てのｉについて、ページｈiがページｈi−１上のハイパーテキスト・リンクを辿ることによって取得された場合である。割り込みのない会話では、クライアントはただｎ−１のハイパーテキスト・リンクを辿り、ページｈ1からｈnを得るだけであり、同じ経路で戻る（バックトラックする）ことはない。割り込みのある会話では、クライアントは少なくとも１回はバックトラックする。バックトラックはクライアントが、１）１＜＝ｉ＜ｎのとき最初にページｈiにアクセスする、２）ハイパーテキスト・リンクを辿り、ＵＲＬを明示的に要求することによってか、またはＷｅｂブラウザのキャッシュを使用することによって他のページを表示する、及び３）メモリから（ブラウザのキャッシュ等から）ｈiを再ロードすることによってページｈiに戻るプロセスをいう。
【００１８】
　本明細書及び特許請求の範囲で用いているとおり、"ホームページ"という用語は、Ｗｅｂサイトに格納された情報までＷＷＷユーザを案内する目次である。ホームページはしばしばマルチメディア・コンテンツを含む。
【００１９】
　本明細書及び特許請求の範囲で用いているとおり、"ハイパーリンク"または"ハイパーテキスト・リンク"は、語句、アイコン、ピクチャ等に組み込まれ、選択すると起動されるＵＲＬ（Universal Resource Locator）等のネットワーク・アドレスである。クライアントがハイパーリンクを起動すると、ハイパーリンクに対応した情報がクライアントに返され、Ｗｅｂブラウザを使用して表示される。
【００２０】
　本明細書及び特許請求の範囲で用いているとおり、"ＨＴＭＬ（ハイパーテキスト・マークアップ言語）"は、Ｗｅｂクライアントによって表示されるハイパーテキスト文書を作成し接続するためにＷｅｂサーバによって用いられる言語である。ハイパーテキスト文書の他の用法については、Bernsteinらによる１９９３年４月２０日付、米国特許番号第５２０４９４７号、Bernsteinらによる１９９４年３月２２日付、米国特許番号第５２９７２４９号、及びLewisによる１９９４年１０月１１日付、米国特許番号第５３５５４７２号を参照されたい。
【００２１】
　本明細書及び特許請求の範囲で用いているとおり、"ＨＴＴＰ（ハイパーテキスト転送プロトコル）"は、コンピュータ間でデータを転送するためにＷＷＷによって用いられるプロトコルである。ＨＴＴＰによりクライアントはファイルを要求するか、またはＣＧＩプログラムを起動することによって、サーバからデータを取得することができる。ＨＴＴＰは無状態プロトコル、つまりクライアントからサーバへのリクエストは全て個別に扱われるプロトコルである。サーバはクライアントとの前の接続について記録を持たない。ＵＲＬの先頭の"http:"は、使用されるプロトコルがＨＴＴＰであることを示す。
【００２２】
　本明細書及び特許請求の範囲で用いているとおり、"インターネット"という用語は、ＴＣＰ／ＩＰプロトコルを使用して互いに接続されたコンピュータのネットワーク及びゲートウェイの集まりである。
【００２３】
　本明細書及び特許請求の範囲で用いているとおり、"サーバ"という用語は、他のプログラムまたはアプリケーション（クライアントという）のコマンドでタスクを実行するプログラムまたはアプリケーションである。本明細書及び特許請求の範囲で用いているとおり、Ｗｅｂサイトはサーバにもなる。"サーバ"という用語はＷｅｂサイトをサポートするＷｅｂサーバと同義語ではない。
【００２４】
　本明細書及び特許請求の範囲で用いているとおり、"トランザクション"という用語は、サーバに対してクライアントによって出されるリクエストを指し示す。
【００２５】
　本明細書及び特許請求の範囲で用いているとおり、"ＴＣＰ／ＩＰ（転送制御プロトコル／インターネット・プロトコル）"は、データをパケットに分け、パケットをネットワークでルーティングし、宛先でパケットを再構成するプロトコルの集まりである。データは電子メール・テキストからビデオまで任意の形でよい。
【００２６】
　本明細書及び特許請求の範囲で用いているとおり、"ＵＲＬ（Universal Resource Locator）"は、Ｗｅｂ上の情報を一意に識別するまたはアドレスする仕方である。ＵＲＬは、Ｗｅｂでは電子メール・アドレスと同等とみなすことができる。ＵＲＬはしかし、他の文書内の深いところに埋められている文書に属する場合は厄介にもなるが、しばしばハイパーリンクでアクセスすることができる。ＵＲＬの一例として"http://www．arun．com:80/table．html"がある。
【００２７】
　ＵＲＬには４つのコンポーネントがある。左端のコンポーネントは使用されるプロトコルを指定する。これはＵＲＬの残りの部分とはコロンで分けられる。次のコンポーネントはターゲット・ホストのホスト名またはＩＰ（インターネット・プロトコル）アドレスである。このコンポーネントは左側が"//"で区切られ、右側は"/"またはコロンで区切られる。３つ目のコンポーネントはオプションのポート番号である。このコンポーネントが用いられるときは、左側はコロンで、右側は"/"で区切られる。４つ目のコンポーネントは実際のファイル名またはプログラム名である。
【００２８】
　上の例で、プロトコルは"http"、ホスト名は"www．arun．com"、ポート番号は"80"、ファイル名は"table．html"である。この例の"http"はハイパーテキスト転送プロトコルを指し示し、ファイル名の拡張子"html"はハイパーテキスト・マークアップ言語を指し示す。
【００２９】
　本明細書及び特許請求の範囲で用いているとおり、"Ｗｅｂブラウザ"は、ＷＷＷでハイパーテキスト文書を表示することのできるクライアント・プログラムである。Ｗｅｂブラウザはインターネットのツアー・ガイドとして働く。つまりビジュアルなデスクトップ、ディレクトリ、及びサーチ・ツールを備え、これらを使用してインターネットをナビゲートまたは"サーフ"することができる。
【００３０】
　本明細書及び特許請求の範囲で用いているとおり、"Ｗｅｂ"または"ＷＷＷ（World Wide Web）"は、インターネット上のハイパーテキスト文書の集まりである。ハイパーテキスト文書は、他の文書へのハイパーリンクを含み、これを使用して文書から文書へナビゲートすることができる。実際には、インターネットで情報を探す際にＷｅｂを使用してサーバからサーバへ、またデータベースからデータベースへの切り替えを行うためにハイパーリンクを選択するが、ハイパーリンクは普通は文書内の強調表示された語句として表示される。Ｗｅｂ上のリソースはＵＲＬ（Universal Resource Locator）を通してアクセスできる。ＷｅｂはＨＴＭＬ（ハイパーテキスト・マークアップ言語）を利用して、ＵＲＬに対応した情報を表示し、他のＵＲＬへのポイント／クリック・インタフェースを与える。
【００３１】
　図１に示すように、本発明の好適な実施例に従って用いられるアーキテクチャ全体は、クライアント１０３及びサーバ・グループ１０４で構成され、サーバ・グループ１０４は参加サーバ１０１及びコントローラ・サーバ１０２を含む。（コントローラ・サーバ１０２は本明細書では簡単にコントローラと呼ぶ。）参加サーバ及びコントローラの物理的位置は重要ではない。各参加サーバ１０１及びコントローラ・サーバ１０２は、ネットワークで接続された個別コンピュータ上にあってよく、また複数のサーバが１つのコンピュータにあってもよい。更にコントローラや１つ以上の参加サーバはいくつかのコンピュータ上に同時に存在することも可能である。例えばこれは、コントローラや１つ以上の参加サーバがスケーラブルなＷｅｂサーバとして実現された場合である。（スケーラブルＷｅｂサーバについては、D．Diasらによる"A Scalable and Highly Available Web Server"、Proceedings of COMPCON '96を参照されたい。）
【００３２】
　コントローラ・サーバ１０２はクライアント・アカウント情報（例えばユーザＩＤ、ユーザ名、パスワード、アドレス、電話番号）を維持する。図１に示すように、各参加サーバ１０１はコントローラ・サーバ１０２と通信することができ、クライアント１０３は各参加サーバ１０１及びコントローラ・サーバ１０２と通信することができる。コントローラ及び参加サーバはＨＴＴＰ等の標準プロトコルを使用して互いに通信できる。また独自プロトコルを使用して通信することもできる。
【００３３】
　クライアント１０３は、参加サーバ１０１及びコントローラ・サーバ１０２と、クライアント状態情報を維持するための手順が制限されたまたは未定義のＨＴＴＰ等の通信プロトコルを介して通信する。クライアント状態情報を維持する限定されたまたは未定義の手順とは、このプロトコルを使用したクライアント及びサーバの間の通信タイプの空でないサブセットについて、プロトコルによって定義された手順を使用した会話の中で、会話の残りの部分で状態変数をサーバにより後で取得できるように、クライアントのＩＤ、クライアント・パスワード等の状態変数を保存することが難しいまたは不可能なことである。
【００３４】
　参加サーバが実行できるトランザクションは２種類ある。第１に参加サーバは単純トランザクションを実行できる。参加サーバは他の参加サーバ及びコントローラから独立してクライアントを代表して単純トランザクションを実行できる。よってクライアントは単純トランザクションを参加サーバから直接的に要求できる。第２に参加サーバはグループ・トランザクションを実行できる。グループ・トランザクションは、コントローラによる調整の下で１つ以上の参加サーバによって実行される。好適にはクライアントはコントローラからのみグループ・トランザクションを要求できる。
【００３５】
　図２は、コントローラ・サーバ１０２が参加サーバ間でクライアント１０３の認証を調整する本発明の好適な実施例を示す。認証は、クライアント１０３がサーバ・グループ１０４のサーバに対して自体を識別するプロセスである。この好適な実施例でクライアント１０３は、会話中に会話の残りの部分でサーバ・グループの任意のサーバでトランザクションを実行するために、参加サーバまたはコントローラにより認証情報を一度要求されるだけである。
【００３６】
　ステップ２０１でコントローラは、好適には参加サーバとオープン接続を確立する。またコントローラは参加サーバと通信する必要のあるとき、その都度新しい接続を確立することもできる。しかしステップ２０１に示すようにオープン接続を維持すると、その都度新しい接続を確立する場合よりも性能が向上する可能性が大きい。
【００３７】
　ステップ２０２でクライアント１０３は自体を認証せずにサーバ・グループと対話する。例えばクライアントはこの場合カタログをブラウズする。
【００３８】
　ステップ２０４でクライアント１０３は、認証を必要とする会話の最初のトランザクションを実行しようとする。
【００３９】
　ステップ２０５でクライアントはユーザＩＤ４０１及びパスワードをＨＴＭＬ形式を介して入力する。機密を守るためにクライアント及びサーバ・グループの間で受け渡される情報は、好適にはＳＳＬ（Secure Sockets Layer）等のシステムを使用して暗号化される。（ＳＳＬについては、A．O．Freier、P．Karlton、P．C．Kocherによる"The SSL Protocol Version 3．0"、Internet Draft、March 1996、http://home．netscape．com/eng/ssl3/ssl-toc．htmlを参照されたい）。
【００４０】
　ステップ２０７でクライアントからコンタクトされたサーバは、クライアントが有効なユーザＩＤ４０１及びパスワードを入力したか確認する。クライアントからコンタクトされたサーバが参加サーバなら、参加サーバはコントローラにコンタクトしてユーザＩＤ４０１及びパスワードとを確認しなければならない。クライアントが有効なユーザＩＤ４０１及びパスワードを入力していない場合は、ステップ２０６でエラー処理が行われる。
【００４１】
　ステップ２０６はいくつかの形で実現できる。一例としてクライアントにユーザＩＤ４０１及びパスワードを入力する新しい機会を与えることができる。他の例としては、クライアントに新しいユーザとして登録する機会を与えることもできる。その場合にクライアントは、名前、住所、電話番号等の他の情報も入力するよう促される。他の例として、会話をエラー・メッセージで中断することもできる。この最後の例は、エラー処理を扱うには好適な方法である。もちろん他の実現形態も可能である。
【００４２】
　有効なユーザＩＤ４０１及びパスワードがステップ２０７で入力された場合、コントローラはステップ２０８でセッションＩＤ４０２を生成する。セッションＩＤは、会話中にクライアントを認証するために用いられる。セッションＩＤは、悪意あるユーザがセッションＩＤを類推しにくいように、充分に大きいキー・スペースからランダムに選択される。コントローラはユーザＩＤ及びセッションＩＤをデータベースに格納する。（ファイル・システム等他の記憶方法も使用できる）。現在のセッションＩＤは、特定のユーザＩＤに対して前に格納されたセッションＩＤを無効にする。
【００４３】
　ステップ２０８で、クライアントからコンタクトされたサーバは、会話でユーザＩＤ４０１及びセッションＩＤ４０２を状態変数として保存する。本明細書及び特許請求の範囲で用いているとおり、会話で状態情報を保存するとは、サーバ・グループの任意のサーバが後で会話中にクライアントと通信するときに情報にアクセスできるように情報を保存することをいう。
【００４４】
　ステップ２０８でサーバはまたそのＩＤをアクセス・ノード状態変数４０３にエンコードし、会話でアクセス・ノード状態変数を保存する。アクセス・ノード状態変数４０３は、認証の間にクライアントによりアクセスされた参加サーバを表す１つ以上の状態変数で構成される。１つの変数を使用して、アクセスした全てのサーバを表すことが可能である。しかし複数の変数を使用してより詳細な情報を表すことが望ましい場合もある。例えば認証の前にアクセスした参加サーバ、認証の後にアクセスした参加サーバ、単純トランザクションが実行された参加サーバ等である。
【００４５】
　クライアントを認証するためにコントローラがそのデータベースに格納する状態情報と、会話で保存される状態情報は必ずしも同一ではない。他より若干多いかまたは少ない状態変数が格納されることもある。しかしそれでも、それぞれに格納される少なくともいくつかの変数は同じである。例えば好適な実施例で、ユーザＩＤ及びセッションＩＤの変数は両方ともコントローラのデータベースに格納され、会話で保存される。本明細書及び特許請求の範囲で用いているとおり、"クライアント認証情報"という用語は、サーバによって格納され、会話でも保存される１組の変数をいう。
【００４６】
　会話で状態変数を保存する好適な方法は、動的引数組み込みである。動的引数組み込みでは、サーバがクライアントに送る接続法に状態情報を再帰的に組み込む。この方法によると、クライアントが接続法を選択するときには、クライアントは状態情報を接続法の一部としてサーバに送り返す。そこでサーバは必要に応じて状態情報を調べ、リクエストを処理し、クライアントに送られる接続法の次のセットに状態情報をもう一度組み込む。
【００４７】
　動的引数組み込みは、ＷＷＷのコンテキストでは、ハイパーリンクに変更を加えて状態情報を保存する。一般的にハイパーリンクは変更されて、引数エンベッダと呼ばれる特別なプログラムが起動される。引数エンベッダは、ハイパーリンクの保存された状態情報をＷｅｂサイトの他のＣＧＩスクリプトに受け渡す。更に引数エンベッダは、得られたＣＧＩスクリプトの出力の全てのハイパーリンクを変更して自体を起動する。従って、動的引数組み込みにより状態が保存された会話を辿るクライアントには、全てが引数エンベッダへのコールであるハイパーリンクが渡される。
【００４８】
　図６は、状態情報をＷｅｂのハイパーリンクに保存するために動的引数組み込みを使用する方法を示す。ステップ６０１でクライアントはＷｅｂサイトのＣＧＩスクリプトｐ1を起動する。
【００４９】
　ステップ６０３でＣＧＩスクリプトｐ1は、状態変数ｘ1、ｘ2、．．．ｘnをこれらの変数が、会話中に起動されるかもしれない全てのＣＧＩスクリプトからアクセスできるように会話に組み込むことを決定する。ＣＧＩスクリプトｐ1は、クライアントが会話を続けるためにハイパーテキスト・リンクを持つＨＴＭＬページｈを生成する。しかしページｈをクライアントに直接返す代わりに、ｐ1は、embed1と呼ばれる引数エンベッダのモジュールを起動する。ＣＧＩスクリプトｐ1はページｈ及び状態変数ｘ1、ｘ2、．．．ｘnをembed1に受け渡す。
【００５０】
　ステップ６０５でembed1モジュールは、ページｈの全てのハイパーテキスト・リンクを変更し、embed2と呼ばれる引数エンベッダの他のモジュールを起動する。embed2に渡される引数は、ページｈのリンクがＨＴＭＬファイルに対するものかＣＧＩスクリプトに対するものかにより異なる。ページｈのリンクがＨＴＭＬファイルに対するものなら、embed2には、ファイルへの絶対参照と全ての状態変数が渡される。ページｈのリンクがＣＧＩスクリプトに対するなら、embed2には、ＣＧＩスクリプトへの絶対参照、ＣＧＩスクリプトへのオリジナル引数、オリジナル引数の終わりを区切るパラメータ、及び状態変数が渡される。
【００５１】
　例えばＣＧＩスクリプトｐ1が、次の２つのハイパーリンクを含むＨＴＭＬページと共に、状態変数x1=32とx2=45をembed1に受け渡すとする。
　１）"http://www．watson．ibm．com/mail．html";及び
　２）"http://www．watson．ibm．com/cgi-bin/prog?argl=55"
【００５２】
　モジュールembed1はこれら２つのハイパーリンクをそれぞれ次のように変換する。
　１）"http://www．watson．ibm．com/cgi-bin/embed2?url=//www．watson．ibm．com/mail．html&x1=32&x2=45";及び
　２）"http://www．watson．ibm．com/cgi-bin/embed2?url=//www．watson．ibm．com/chi-bin/prog&argl=55&comma=1&x1=32&x2=45"
【００５３】
　embed2は、２つ目のハイパーリンクの文字列"comma=1"により、オリジナル引数、arg1を状態変数、x1、x2から区別する。一意の任意の変数名をデリミッタとして使用できる。"comma"が同じ名前の他の変数と衝突するような危険がある場合は、より洗練された方法により、一意のデリミッタ変数名を拾うこともできよう。
【００５４】
　ステップ６０７でembed1モジュールは、変更されたハイパーリンクで構成されたＨＴＭＬページｈ'をクライアントに送る。ページｈ'の全てのハイパーテキスト・リンクはembed2へのコールである。
【００５５】
　ステップ６０９でクライアントはページｈ'からハイパーテキスト・リンクを選択して会話を続ける。ハイパーテキスト・リンクはモジュールembed2を起動する。
【００５６】
　ステップ６１１でembed2はリクエストを処理する。embed2への引数がファイルを含む場合はファイルがフェッチされる。embed2への引数がＣＧＩスクリプトへのコールを含む場合は、ＣＧＩスクリプトがオリジナル引数及び状態変数で起動される。上の例では、最初のハイパーリンクがクライアントによって選択された場合、embed2はファイル"mail．html"をフェッチする。第２ハイパーリンクがクライアントによって選択された場合、embed2はオリジナル変数arg1=55と状態変数x1=32、x2=45でＣＧＩスクリプト"prog"をコールする。
【００５７】
　ステップ６１３で、対応するＨＴＭＬファイルがフェッチされるかＣＧＩスクリプトが起動されると、得られる出力と状態変数はembed1に受け渡される。プロセスは次にステップ６０５に戻り、そこでembed1は出力のハイパーリンクに変更を加える。（動的引数組み込みの詳細はA．Iyengarによる１９９６年６月７日付、米国特許出願番号第０８／６６０６３３号、"Preserving State in Stateless Network Protocols"を参照されたい。）
【００５８】
　動的引数組み込みは、会話で状態を保存する好適な方法ではあるが、ネットスケープ・クッキー（NETSCAPE cookies）もまた使用できる。ネットスケープ・クッキーは非標準ＨＴＴＰ機能であり、ＨＴＴＰオブジェクトをクライアントに返すサーバはこれにより、クライアントが格納する状態情報１つを送ることもできる。この状態情報に含まれるのは、状態情報が有効な範囲のＵＲＬの記述である。クライアントがネットスケープ・クッキーをサポートするなら、クライアントは、それが送るＨＴＴＰリクエストをチェックし、リクエストのＵＲＬがクライアントが格納している期限切れになっていないクッキーの範囲内かどうか確認する。ＨＴＴＰリクエストがクッキーによって定義された範囲内なら、クライアントはそのクッキーに対応した状態情報をそのＨＴＴＰリクエストに加える。（ネットスケープ・クッキーの詳細については"Persistent Client State HTTP Cookies"、Netscape Communications Corporation、1996、http://home．netscape．com/newsref/std/cookie_spec．htmlを参照されたい。）
【００５９】
　ネットスケープ・クッキー上で動的引数組み込みを使用することにはいくつか利点がある。動的引数組み込みにより、全ての状態情報の存続期間が会話の存続期間に結び付けられる。クライアントとサーバ・グループの間で新しい会話が開始される毎に新しい状態情報が生成される。クッキーを使用すると、状態情報の存続期間を会話の存続期間に結び付けることは不可能である。クッキーの他の欠点は、標準ＨＴＴＰプロトコルの一部ではないこと、よって全てのクライアント及びＷｅｂサーバと連係するとは限らないことである。対照的に、動的引数組み込みはＨＴＴＰをサポートする任意のクライアントまたはＷｅｂサーバと連係する。動的引数組み込みの他の利点は、クライアント側の異なるアカウントに対応したＷｅｂページをキャッシュすることによって複数のアカウントへのアクセスが同時に可能なことである。
【００６０】
　ＨＴＭＬ形式はまた状態を保存するのにも使用できる。ＨＴＭＬ形式は、サーバが隠し変数を形式に組み込むために使用できる。隠し変数は、形式がクライアントによって提出されたときサーバに返される。しかしＨＴＭＬ形式の使用は制限され、厄介である。これはサーバが会話全体で状態情報を保存するために、動的に生成されたＨＴＭＬ形式でクライアントに常に応答しなければならないからである。
【００６１】
　ステップ３００でトランザクションが処理される。トランザクションが単純トランザクションなら、参加サーバまたはコントローラは自体でトランザクションを処理する。要求されたトランザクションがコントローラからのグループ・トランザクションなら、処理は図３のステップによって行われる。
【００６２】
　ステップ２０９で単純トランザクションを処理するサーバは、会話を続けるためのハイパーテキスト・リンクと共にＨＴＭＬページをクライアントに返す。ページがクライアントに送られる前にページに状態情報を追加することもできる。例えばサーバ・グループが動的引数組み込みを使用している場合、ページ上のハイパーテキスト・リンクを先に述べたように変更しなければならない。サーバ・グループが動的引数組み込みを使用していない場合も、システムがクライアントの認証以降にアクセスしている参加サーバを管理できるように、ページのハイパーテキスト・リンクを変更しなければならないことがある。例えば、ページを送っていない参加サーバに対応したページのハイパーテキスト・リンクを変更して、アクセス・ノード状態変数４０３を必要に応じて更新するＣＧＩスクリプトが起動される。
【００６３】
　ステップ２１０でトランザクションが処理され、応答ページがクライアントに返されると、クライアントは、応答ページから新しいハイパーテキスト・リンクを選択することによって（場合によっては他の情報の入力と共に）会話を続ける。
【００６４】
　ステップ２１１では、ステップ２１０で選択されたハイパーテキスト・リンクが参加サーバをポイントする場合、認証以降にサーバがアクセスしたかどうかがＣＧＩスクリプトによって確認される。これはアクセス・ノード状態変数４０３を調べることによって行われる。認証以降にサーバがアクセスしていない場合、サーバはステップ２１２でアクセス・ノード状態変数４０３に追加される。
【００６５】
　ステップ２１３でクライアントからコンタクトされたサーバは、クライアントが認証を必要とするトランザクションを実行しようとしたか確認する。クライアントが実行しようとしなかった場合はトランザクションはステップ３００で処理される。
【００６６】
　認証を要するトランザクションが選択されていることをサーバが確認した場合は、処理はステップ２１４に続く。このステップでサーバは、ユーザＩＤ４０１及びセッションＩＤ４０２が有効か確認する。サーバが参加サーバならコントローラとのコンタクトが、好適な実施例では、ユーザＩＤ及びセッションＩＤの有効性を確認するために必要である。ユーザＩＤ及びセッションＩＤが有効でない場合は、エラー処理がステップ２１５で行われる。先にステップ２０６に関して述べたとおり、エラー処理はいくつかの形で処理できるが、好適にはサーバがエラー・メッセージを含むページで応答することによって会話を終了させる。ユーザＩＤ及びセッションＩＤが有効ならトランザクションは先に述べたようにステップ３００で処理される。
【００６７】
　クライアントによって要求されたトランザクションがグループ・トランザクションなら、図３の本発明の好適な実施例に従って参加サーバ間の調整が行われる。
【００６８】
　ステップ３０３でコントローラは、認証以降にアクセスした全ての参加サーバで構成される参加サーバのデフォルト・グループを構成する。この情報は、アクセス・ノード状態変数４０３に含まれる。クライアントは、デフォルト・グループを受け入れるか、または自体が選択する参加サーバのセットでデフォルト・グループを無効にするオプションを持つ。
【００６９】
　グループ・トランザクションは、ある有限なｎ＞０のときｎ個のフェーズで起こり得る。最初のｎ−１フェーズは準備フェーズと呼ばれる。最後のフェーズはコミット・フェーズと呼ばれる。ステップ３０４は準備フェーズをまだ実行すべきか確認する。準備フェーズを実行する必要のある場合、ステップ３０６でコントローラが対応する準備メッセージをステップ３０３で定義されたグループの全ての参加サーバに送る。
【００７０】
　ステップ３０７でコントローラは、定義済みグループの全ての参加サーバから応答を集め、先のフェーズからのものにこれらの応答を加える。参加サーバは肯定応答または否定応答で応答する。参加サーバがある時間内に応答しなかった場合、応答は否定とみなされる。参加サーバは、それらの応答の一部としてＨＴＭＬテキストを送ることもできる。ＨＴＭＬテキストの形式はフレキシブルなので、各参加サーバはグループ操作に対して、参加サーバが選択するハイパーテキスト・リンク、イメージ及びマルチメディア・コンテンツの組み合わせを含めて、カスタマイズされた応答を送ることができる。
【００７１】
　ステップ３０９でコントローラは、全ての応答が肯定かどうか確認する。参加サーバの応答が否定なら、処理はステップ３１１に移る。ステップ３１１でコントローラは、ステップ３０９で肯定応答した全ての参加サーバに、準備フェーズが失敗したことを通知する。
【００７２】
　ステップ３１２でコントローラは、肯定応答した参加サーバからの応答を、失敗した準備フェーズ及び準備フェーズに失敗した参加サーバをクライアントに通知するメッセージと共に１つのページにマージする。クライアントに返るページはまた、クライアントが会話を続けるためのハイパーテキスト・リンクを含む。
【００７３】
　コントローラがステップ３０９で、準備フェーズが定義済みグループの全ての参加サーバで成功したことを確認した場合は、処理はステップ３０４に戻る。準備フェーズが全て成功して完了した場合、処理はステップ３０５に進む。ステップ３０５でコントローラは、定義済みグループの全ての参加サーバにコミット・メッセージを送る。
【００７４】
　ステップ３０８でコントローラは、定義済みグループの全ての参加サーバから応答を集める。先に述べたように、参加サーバはそれらの応答にＨＴＭＬテキストを追加できる。ステップ３１０でコントローラは１つのページの応答を作成する。これはいくつかのアイテムをマージすることによってクライアントに送られる。第１にコントローラは、先にステップ３０７で準備フェーズから集められた応答とステップ３０８で受信された応答を全てマージする。コントローラは次に、全ての準備フェーズが成功したことを伝えるメッセージを追加する。参加サーバがステップ３０８で時間内に応答することができなかった場合、コントローラはまたこの情報を応答ページに追加することができる。最後にクライアントが会話を続けるられるようにするハイパーテキスト・リンクが追加される。ここでもページがクライアントに送られる前に状態情報を保存するために、またはシステムが先にアドレスされたノードを管理できるように、ページの変更が必要になることがある。
【００７５】
　上に述べた実施例ではいくつか拡張及び変形が可能である。１つの変形例はセッションＩＤの存続期間を制限することである。コントローラは各セッションＩＤの存続期間及び作成時刻（エフェメラル・セッションＩＤと呼ばれる）を、ステップ２０８でセッションＩＤが作成されたとき記録できる。現在時刻及び作成時刻の違いが、エフェメラル・セッションＩＤの存続期間を超えるときは、エフェメラル・セッションＩＤは期限を過ぎていることになる。エフェメラル・セッションＩＤの期限切れはステップ２１４でチェックできる。クライアントが期限の切れたエフェメラル・セッションＩＤでトランザクションを試行する場合は、ステップ２１５でエラー処理が行われる。期限切れエフェメラル・セッションＩＤを処理する好適な方法は、有効なユーザＩＤ及びパスワードを提出することで自体を再認証することをクライアントに要求することである。
【００７６】
　他の変形例として、各トランザクション・リクエストに新しいセッションＩＤを作成することが考えられる。この場合、各セッションＩＤは１つのトランザクションにのみ有効である。このアプローチでは、悪意ある侵入者がセッションＩＤを盗んでアカウントに侵入することは難しくなる。この変形例を実現するためには、ステップ２１４を変更して前のセッションＩＤを無効にし、新しいセッションＩＤを作成して新しいセッションＩＤを記録し、新しいセッションＩＤを会話で保存することができる。
【００７７】
　他の変形例は、セッションＩＤをクライアントに送られる前に暗号化し、コントローラによって認証される前にデコードすることである。動的引数組み込み、クッキー等の手法が用いられる場合は、この暗号化機能によりセッションＩＤの受け渡し先であるＵＲＬにもとづく異なるエンコーディングを作ることができる。従って異なるＵＲＬへのアクセスには異なる暗号化されたセッションＩＤが必要になる。暗号化されたセッションＩＤを何とか盗もうとした侵入者は、それを特定のＵＲＬ（また場合によっては特定の引数セットしかないＵＲＬ）でしか使用できないことになる。これによりこのような侵入者による損害が制限される。
【００７８】
　他の変形例は、コントローラが特定のセッションＩＤからの全てのトランザクションの出所をセッションＩＤを作成した認証プロセスに参加したクライアントと同じＩＰアドレスに限定することである。この機能を実現するためには、セッションＩＤがステップ２０８で作成されるときに自体を認証するクライアントのＩＰアドレスが記録される。ステップ２１４で、リクエストを出すクライアントのアドレスが、自体を認証したクライアントのアドレスと同じ場合にのみトランザクションを行うことができる。このアプローチでは、悪意あるユーザがクライアントからセッションＩＤを盗み、セッションＩＤを使用してクライアントのアカウントに他のマシンから侵入することを防ぐことはできる。しかし絶対確実ではない。異なるマシンが同じＩＰアドレスを持つように見えることがあるからである（例えばマシンが同じファイアウォール下にあるとき）。暗号化等他のセキュリティ機能を、このアプローチと併用してアカウント侵入の危険を更に小さくすることは可能である。
【００７９】
　他の変形例は、コントローラによって維持されるクライアントの認証及びアカウント情報を１つ以上の参加サーバに複製することである。その場合、コントローラは認証毎にコンタクトする必要はない。このアプローチでは、コントローラの負荷が減り、システム性能が向上する。しかし認証及びアカウントの情報の複数のコピーの間で一貫性を保つためには何らかの方法が必要になる。
【００８０】
　他の変形例は、作業負荷が大きいときにシステム性能を改良するもので、複数のサーバで実行するためにコントローラをスケーリングすることである。しかし複数のサーバで実行するためにコントローラをスケーリングする際の複雑さは、１つは、複数のノードで認証情報をどのように共有するかという課題である。認証情報は複数のノードに複製できるが、複数の一貫した認証情報のコピーを維持するオーバヘッドと複雑さのために、ステップ２０８で記録された認証情報のコピーは１つだけ維持することが望ましい場合もある。
【００８１】
　コントローラが複数のノードでスケーリングされるときに認証情報を維持する１つの方法は、（サーバ・グループと現在通信している全てのクライアントに属する）全てのセッションＩＤのセットをコントローラ・ノードに分散させることである。従って、あるセッションＩＤのコピー１つだけが維持されるが、セッションＩＤのセットはコントローラ・ノードに分散される。このアプローチを実現するために、コントローラは、あるクライアントのセッションＩＤ情報をステップ２０８でコントローラ・ノードｎに格納できる。コントローラ・ノードｎのＩＤは次に、そのクライアントとの会話で状態変数にエンコードできる。例えばセッションＩＤ変数４０２をエンコードして、実際のセッションＩＤ及びクライアントのセッションＩＤを格納したコントローラのノードの両方を格納できよう。クライアントが、そのセッションＩＤの認証を要するトランザクションを実行しようとしたときは、ステップ２１４で、クライアントとの会話で保存された対応する状態変数が調べられ、クライアントのセッションＩＤがどのコントローラ・ノードにあるか確認される。クライアントのセッションＩＤは次に対応するコントローラ・ノードで確認される。
【００８２】
　クライアント認証情報と同じく、クライアント・アカウント情報も複数のコントローラ・ノードに複製するか、または複数のコントローラ・ノードに分散させることができる。どのアプローチを取るかの決定は、クライアント認証情報についてどちらのアプローチを使用するかとは別に行える。クライアント・アカウント情報を複数のノードに分散させ場合、上に述べたアプローチが使用できる。あるクライアントについてアカウント情報を含むコントローラ・ノードのＩＤは、ユーザＩＤ変数４０１等の状態変数にエンコードできる。
【００８３】
　他の変形例は、通常はサーバ・グループによって実行される機能のいくつかをクライアントが実行できるようにすることである。Ｊａｖａ（Ｒ）等の言語を使用して、サーバ・グループによって実行される機能のいくつかをダウンロードしてクライアントによって実行できる。
【００８４】
　他の変形例は、会話でユーザＩＤとセッションＩＤ両方の状態変数を保存する代わりに、セッションＩＤ状態変数だけを保存することである。この例でサーバは、ユーザＩＤとセッションＩＤの対応を維持することになる。次にサーバはセッションＩＤからユーザＩＤを計算することができる。
【００８５】
　他の変形例は、セッションＩＤ状態変数を作成する代わりにクライアントのパスワードを状態変数として維持することである。しかしセッションＩＤは会話が続く間しか続かないので、パスワードの代わりにセッションＩＤを使用する利点は、盗まれたセッションＩＤは盗まれたパスワードよりも潜在的に害が少ない場合があるということである。
【００８６】
　他の変形例は、多数フェーズ・コミットを扱うためにＸＡプロトコルを実現することである。（ＸＡプロトコルの詳細についてはJ．Gray & A．ReuterによるTransaction Processing：Concepts & Techniques、Morgan Kaufmann、1993を参照されたい）。
【００８７】
　好適な実施例では、グループ・トランザクションの参加サーバのデフォルト・グループが、認証時刻とグループ・トランザクションが要求された時刻の間にアクセスした参加サーバで構成される。デフォルト・グループの選択についてはいくつかの変形例を簡単に実現できる。参加サーバのデフォルト・グループは次のサーバで構成することができる。１）会話の初め以降にアクセスした全てのサーバ、２）会話の初め以降に単純トランザクションに関係した全てのサーバ、３）最後のグループ・トランザクション以降にアクセスした全てのサーバ、４）最後のグループ・トランザクション以降に単純トランザクションに関係した全てのサーバ、及び５）最後のグループ・トランザクションに参加した全てのサーバ。またこれらを組み合わせたデフォルト・グループも可能である。
【００８８】
　一般的にデフォルト・グループは、トランザクションのタイプ、認証のタイプ及び重要イベントに関して決定することができる。トランザクションは、１）全てのトランザクション、２）単純トランザクション、及び３）グループ・トランザクションを含めたグループに分類することができる。トランザクションは更に、１）全てのトランザクション、２）認証が必要なトランザクション、及び３）認証が必要でないトランザクション等の認証タイプに従って分類できる。重要イベントは、トランザクションによって定義された会話中の１時点である。例えば次は重要イベントになる場合がある。１）会話の初め、２）クライアントが最初に有効な識別情報を与える時点、３）最後のグループ・トランザクション。デフォルト・グループは、サーバの重要なサブセット、ＣＳ（ｉ、ｊ、ｋ）に関して定義することもできる。これはトランザクション・タイプｊと認証タイプｋのトランザクションを与えた重要イベントｉ以降にクライアントが通信したサーバのサブセットである。例えば上に定義した分類によると、サーバの重要サブセットＣＳ（３、１、２）は、認証を要するトランザクションが実行された最後のグループ・トランザクション以降にクライアントが通信したサーバのセットである。
【００８９】
　他の変形例は、アクセスした参加サーバに依存しないデフォルト・グループを指定することである。この例ではアクセス・ノード状態変数４０３を保存する必要はなく、ステップ２１１、２１２も必要ない。
【００９０】
　参加サーバが複数のコントローラと通信することも可能である。図４に示すように、１つのコントローラが、階層の下のレベルのコントローラと参加サーバからの操作を調整する、コントローラの階層を持たせることも可能である。
【００９１】
　図３のステップ３１０、３１２の好適な実施例では、コントローラが全ての情報を１つのＨＴＭＬページとしてクライアントに送る。情報の量が多い場合は、これに代わる方法として、情報をいくつかのページに分けることが考えられる。コントローラは一度に１ページを送る。各ページにハイパーテキスト・リンクがあり、クライアントはこれにより他のページを見ることができる。ハイパーテキスト・リンクを（可能ならいくつかを）辿ることにより、クライアントは全ての情報を見ることができる。この技術はもちろん新しいものではない。例えばＵＲＬ、http://www．lycos．comのＬｙｃｏｓサーチ・エンジンはこの方法を実現している。
【００９２】
　他の変形例は、手動により識別情報を入力することをクライアントに促す代わりに、クライアントを識別するためにデジタル認証を用いることである。デジタル認証は、クライアントのディスクまたはスマート・カードに格納できる識別情報の文字列である。デジタル認証は、クライアントに手動での入力を期待できるものより長く複雑になる情報の文字列で構成できるので、デジタル認証を使用することはクライアントに識別情報を手動で入力させる場合よりも、クライアントを識別する方法としてより安全な方法を提供できる場合がある。またデジタル認証及び手動入力を組み合わせて使用することもできる。例えばクライアントには、そのスマート・カードを有効にするためにＰＩＮ（個人識別番号）の入力を要求することができる。
【００９３】
　上に述べた好適な実施例で、クライアント・アカウント情報はコントローラ・サーバによって維持される。他の変形例は、コントローラが、クライアントによって与えられたクライアント識別情報を確認するために認証機関と通信することである。
【００９４】
　まとめとして、本発明の構成に関して以下の事項を開示する。
【００９５】
　（１）１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループを持つクライアント／サーバ環境にて、前記サーバ・グループのサーバ間で操作を調整する方法であって、
　クライアント及び前記サーバ・グループの少なくとも１つのサーバの間で情報を受け渡す手順が制限されたまたは未定義のプロトコルを使用して前記クライアント及び前記サーバの間で通信するステップと、
　前記クライアントから前記サーバの１つに操作のリクエストを転送するステップと、
　前記リクエストに応答して複数のサーバ及び少なくとも１つのコントローラ・サーバの間で通信して少なくともいくつかのサーバの操作を調整するステップと、
　を含む、方法。
　（２）参加サーバとコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループを持つクライアント／サーバ環境にて、前記サーバ・グループのサーバ間で操作を調整する方法であって、
　クライアント及び前記サーバ・グループの少なくとも１つのサーバの間で情報を受け渡す手順が制限されたまたは未定義のプロトコルを使用して前記クライアントと前記サーバとの間で通信するステップと、
　認証を要するクライアントによる第１操作のリクエストを転送するステップと、
　前記クライアントによりクライアント識別情報を与えるステップと、
　前記クライアント識別情報をコントローラ・サーバにより確認するステップと、
　コントローラ・サーバによりクライアント認証情報を作成するステップと、
　サーバにより前記クライアント認証情報を維持するステップと、
　前記クライアント認証情報を会話で保存するためにサーバにより手段を利用するステップと、
　認証を要する前記サーバによる第２操作のリクエストを前記サーバの１つに転送するステップと、
　前記会話で保存された前記クライアント認証情報とサーバによって維持されたクライアント認証情報を使用して前記クライアントを認証するステップと、
　を含む、方法。
　（３）１つ以上の参加サーバ及び１つ以上のコントローラ・サーバを含み、各参加サーバが少なくとも１つのコントローラ・サーバと通信できるサーバ・グループを持つクライアント／サーバ環境にて、前記サーバ・グループのサーバ間で操作を調整する方法であって、
　クライアント及び前記サーバ・グループの少なくとも１つのサーバの間で情報を受け渡す手順が制限されたまたは未定義のプロトコルを使用して前記クライアント及び前記サーバの間で通信するステップと、
　参加を要する操作のリクエストを複数のサーバにより前記クライアントから前記サーバの１つに転送するステップと、
　前記リクエストに応答して前記サーバと少なくとも１つのコントローラ・サーバの間で通信して前記複数のサーバの操作を調整するステップと、
　を含む、方法。
　（４）クライアントによりクライアント識別情報を与える前記ステップは前記クライアントによる情報の手動入力により行われる、前記（２）記載のサーバ間で操作を調整する方法。
　（５）クライアントによりクライアント識別情報を与える前記ステップは永続メモリに格納された情報を取得することにより行われる、前記（２）記載のサーバ間で操作を調整する方法。
　（６）永続メモリに格納された情報はディスクまたはスマート・カード上の１つ以上のデジタル認証を含む、サーバ間で操作を調整する、前記（５）記載の方法。
　（７）クライアント識別情報を確認する前記ステップは、１つ以上のコントローラ・サーバによって維持されたクライアント・アカウント情報を取得し、前記クライアント識別情報を前記クライアント・アカウント情報と比較するステップを含む、サーバ間で操作を調整する、前記（２）記載の方法。
　（８）クライアント識別情報を確認する前記ステップは、前記サーバ・グループの外部の認証機関サーバと通信するステップを含む、サーバ間で操作を調整する、前記（２）記載の方法。
　（９）１つ以上のサーバにより前記クライアント認証情報を維持するステップは、前記クライアント認証情報を前記サーバ・グループの２つ以上のサーバに複製するステップを含む、サーバ間で操作を調整する、前記（２）記載の方法。
　（１０）前記クライアント認証情報を会話で保存する手段は動的引数組み込みである、サーバ間で操作を調整する、前記（２）記載の方法。
　（１１）前記クライアントはWorld Wide Webクライアントであり、前記サーバはWorld Wide Webサイトであり、前記クライアント認証情報を会話で保存する手段はネットスケープ・クッキー（NETSCAPE cookie）である、サーバ間で操作を調整する、前記（２）記載の方法。
　（１２）前記クライアントはWorld Wide Webクライアントであり、前記サーバはWorld Wide Webサイトであり、前記クライアント認証情報を会話で保存する手段はＨＴＭＬ形式である、サーバ間で操作を調整する、前記（２）記載の方法。
　（１３）クライアント認証情報を維持する前記サーバは少なくとも１つのコントローラ・サーバを含む、サーバ間で操作を調整する、前記（２）記載の方法。
　（１４）前記クライアント認証情報はセッションＩＤを含む、サーバ間で操作を調整する、前記（２）記載の方法。
　（１５）前記セッションＩＤは、経過すると有効ではなくなる存続期間を持つ、サーバ間で操作を調整する、前記（１４）記載の方法。
　（１６）前記クライアントにより、認証を要する指定数のリクエストを１つ以上のサーバに転送するステップと、
　前記指定数のリクエストの間に１つ以上のコントローラ・サーバにより新しいセッションＩＤを含む新しいクライアント認証情報を作成するステップと、
　１つ以上のサーバにより前記新しいクライアント認証情報を会話で保存する手段を利用するステップと、
　を含む、サーバ間で操作を調整する、前記（１４）記載の方法。
　（１７）クライアント認証情報を保存する手段は、前記セッションＩＤを暗号化する手段を含み、前記会話で保存されたクライアント認証情報を使用することは暗号化されたセッションＩＤのデコードを伴う、サーバ間で操作を調整する、前記（１４）記載の方法。
　（１８）前記セッションＩＤを暗号化する手段は、サーバとリクエストの特定の組み合わせについてのみ有効な暗号化されたセッションＩＤを作成する、サーバ間で操作を調整する、前記（１７）記載の方法。
　（１９）前記サーバ・グループのサーバはWorld Wide Webサイトであり、前記暗号化されたセッションＩＤは特定のＵＲＬについてのみ有効である、サーバ間で操作を調整する、前記（１８）記載の方法。
　（２０）少なくとも１つのサーバにより前記クライアント識別情報を与えた前記クライアントのアドレスを維持するステップと、
　前記会話中に認証を要し前記クライアントにより要求された少なくともいくつかの操作に応答して、前記アドレスを使用して前記クライアントを認証するステップと、
　を含む、サーバ間で操作を調整する、前記（２）記載の方法。
　（２１）少なくとも１つのコントローラ・サーバは複数のノードに分散される、サーバ間で操作を調整する、前記（２）記載の方法。
　（２２）前記クライアント認証情報はセッションＩＤを含み、１つ以上サーバにより前記クライアント認証情報を維持するステップは、前記セッションＩＤを前記分散されたコントローラ・サーバの１つの全てのノードよりも少ないノードに格納し、前記セッションＩＤが格納された前記ノードの少なくとも１つのＩＤを前記会話で状態変数に保存するステップを含む、サーバ間で操作を調整する、前記（２１）記載の方法。
　（２３）前記クライアント認証情報は前記分散されたコントローラ・サーバの１つの複数のノードに複製される、サーバ間で操作を調整する前記（２１）記載の方法。
　（２４）少なくとも１つのコントローラ・サーバが複数のノードに分散され、前記クライアント・アカウント情報は前記分散されたコントローラ・サーバの１つの複数のノードに複製される、サーバ間で操作を調整する、前記（７）記載の方法。
　（２５）前記複数のサーバの操作を調整するステップは、前記クライアントによるリクエストに応答して少なくとも１つのコントローラ・サーバによりサーバのデフォルト・グループを定義するステップを含む、サーバ間で操作を調整する、前記（３）記載の方法。
　（２６）前記サーバのデフォルト・グループは、前記クライアントが会話中に通信した前記サーバ・グループのサーバを含む、サーバ間で操作を調整する、前記（２５）記載の方法。
　（２７）前記サーバのデフォルト・グループは、サーバの重要サブセットに関して決定され、サーバの各重要サブセットは、トランザクション・タイプ、認証タイプ及び重要イベントに関して決定される、サーバ間で操作を調整する、前記（２６）記載の方法。
　（２８）前記トランザクション・タイプは全てのトランザクション、単純トランザクション、及びグループ・トランザクションを含む、サーバ間で操作を調整する、前記（２７）記載の方法。
　（２９）前記認証タイプは、全てのトランザクション、認証を要するトランザクション及び認証を要しないトランザクションを含む、サーバ間で操作を調整する、前記（２７）記載の方法。
　（３０）前記重要イベントは、会話の初め、クライアントが最初に有効な識別情報を与える時点、及び最後のグループ・トランザクションを含む、サーバ間で操作を調整する、前記（２７）記載の方法。
　（３１）前記サーバのデフォルト・グループは、前記最後のグループ・トランザクションに関係したサーバに関して決定される、サーバ間で操作を調整する前記（２５）記載の方法。
　（３２）前記操作のリクエストは複数のサーバから情報を集める操作を伴う、サーバ間で操作を調整する、前記（３）記載の方法。
　（３３）複数のサーバの参加を要する前記操作のリクエストは、有限なｎ＞０のとき複数のサーバからのｎフェーズ・コミットを伴う、サーバ間で操作を調整する、前記（３）記載の方法。
　（３４）前記サーバ間で少なくとも１つのコントローラ・サーバと通信して前記複数のサーバの操作を調整するステップは、
　少なくとも１つのコントローラ・サーバ及び前記複数のサーバのうち少なくともいくつかのサーバとの間で通信するステップと、
　前記複数のサーバのうち少なくともいくつかのサーバからの応答を少なくとも１つのコントローラ・サーバによりマージするステップと、
　を含む、サーバ間で操作を調整する、前記（３）記載の方法。
　（３５）前記サーバはWorld Wide Webサイトである、サーバ間で操作を調整する、前記（１）乃至前記（３）のいずれかに記載の方法。
　（３６）前記クライアント及びサーバの間の通信に用いられる前記プロトコルはハイパーテキスト転送プロトコルである、サーバ間で操作を調整する、前記（１）乃至前記（３）のいずれかに記載の方法。
　（３７）前記クライアント及びサーバの間の通信に用いられる前記プロトコルは安全である、サーバ間で操作を調整する、前記（１）乃至前記（３）のいずれかに記載の方法。
　（３８）少なくとも１つの参加サーバは複数のコントローラと通信する、サーバ間で操作を調整する、前記（１）乃至前記（３）のいずれかに記載の方法。
　（３９）コントローラ・サーバの階層が存在し、各コントローラ・サーバが下の階層レベルの参加サーバ及びコントローラ・サーバの間で操作を調整する、サーバ間で操作を調整する、前記（１）乃至前記（３）のいずれかに記載の方法。
　（４０）前記クライアントにより少なくとも１つのサーバからプログラムを受信し実行することによって、前記クライアントが前記サーバ・グループの機能の少なくともいくつかを実行するステップを含む、サーバ間で操作を調整する前記（１）乃至前記（３）のいずれかに記載の方法。
　（４１）前記参加サーバは互いに通信できない、サーバ間で操作を調整する前記（１）乃至前記（３）のいずれかに記載の方法。
【図面の簡単な説明】
【００９６】
【図１】本発明の好適な実施例に従って用いられるアーキテクチャ全体を示す図である。
【図２】本発明の好適な実施例に従ってクライアントの認証を調整する方法を示す図である。
【図３】本発明の好適な実施例に従って参加サーバ間でグループ・トランザクションを調整する方法を示す図である。
【図４】本発明の好適な実施例に従って用いられる他のアーキテクチャ全体を示す図である。
【図５】会話で保存される好適な変数のリストを示す図である。
【図６】状態情報をＷＷＷハイパーリンクに動的に組み込む方法を示す図である。
【符号の説明】
【００９７】
１０１　参加サーバ
１０２　コントロール・サーバ
１０３　クライアント
１０４　サーバ・グループ
４０１　ユーザＩＤ
４０２　セッションＩＤ
４０３　アクセス・ノード状態変数
【図１】
2004078967.tif 000003
【図２】
2004078967.tif 000004
【図３】
2004078967.tif 000005
【図４】
2004078967.tif 000006
【図５】
2004078967.tif 000007
【図６】
2004078967.tif 000008