カプセル化通信プロトコルを使用してネットワークコンポーネントをセキュアに横断する持続性および信頼性のあるセッション
本発明は、セッションの持続化および信頼性を提供するため、カプセル化通信プロトコルを使用してネットワークコンポーネントをセキュアに横断することにより、クライアント通信を再確立するシステムおよび方法に関する。複数の第２のプロトコルをカプセル化する第１のプロトコルは、クライアントおよびホストサービス間のセッションの持続化および信頼できる接続を提供するため、第１のプロトコルサービスを介し、ネットワークでの通信に使用される。チケットオーソリティはクライアントに関連する第１および第２のチケットを生成する。第１のチケットはクライアントに提供され、クラインアントはその第１のチケットを、第１のプロトコルサービスとの通信セッションを確立するために使用する。第２のチケットは第１のプロトコルサービスに提供され、第１のプロトコルサービスは第２のチケットを、ホストサービスとの通信セッションを確立するために使用する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してネットワーク通信に関する。より具体的には、本発明は、セッションの持続化および信頼性を提供するため、カプセル化通信プロトコルを使用してネットワークコンポーネントをセキュアに横断することにより、クライアント通信を再確立するシステムおよび方法に関する。
【背景技術】
【０００２】
２台のコンピュータ、例えばクライアントおよびサーバの間のネットワーク上における通信は、様々な周知の通信プロトコルを使用して実施されうる。概して、クライアントはサーバからネットワーク上でコンテンツをダウンロードするためにサーバと通信を行う。例えば、サーバはクライアントによりアクセス可能な１つ以上のアプリケーションをホスティングすることがある。さらに、クライアントは、概してルータまたはファイアウォール等の、サーバからのコンテンツが通過するセキュリティゲートウェイであるプロキシを介してサーバと通信を行うことがある。また、サーバは、そのサーバとの未許可の通信のやりとりを禁止するためファイアウォールを含むことがある。クライアントは、プロキシのセキュリティおよびサーバのファイアウォールを経由してサーバおよびサーバのコンテンツにアクセスする。しかしながら、多くの場合、プロキシを介してサーバまで行き着くネットワーク接続は断絶しやすい。例えば、クライアントとプロキシの間の無線接続は、多くの場合信頼できない。その他、ネットワーク接続が断続的となる場合がある。そのため、エレベーターまたはトンネルに入ると接続が失われ、そのエレベーターまたはトンネルから出ないかぎり回復できない場合がある。
【０００３】
クライアントおよびサーバコンピュータの間に確立された通信セッションが異常終了すると、クライアントは概して新しい通信セッションを開始することにより接続を再確立しなければならない。新しい通信セッションを始めるためには、ユーザーが新しい通信セッションに許可されるよう、ユーザーは概して、ログイン／パスワードのペア等の認証証明書をプロキシおよびサーバコンピュータへ再伝送しなければならない。この多数の通信セッションにわたるユーザーの認証証明書の再伝送は、そのユーザーの認証証明書を潜在的攻撃者に対し繰り返し露呈し、それによって認証証明書のセキュリティレベルを低下させる。さらに、攻撃者がプロキシのセキュリティまたはサーバのファイアウォールをバイパスした場合、その攻撃者は追加セキュリティに遭遇することなしにサーバのコンテンツにアクセスすることができる。また、ユーザーに認証証明書を再入力させることは、多くの場合、ユーザーにフラストレーションおよび不便さをもたらす時間のかかるプロセスである。
【０００４】
現在の多くのプロトコルを使用してネットワーク接続で通信を行う際、ネットワーク接続が中断した場合にはデータパケットが失われる。例えば、標準的なＴＣＰネットワーク接続を介して通信を行う場合、データバッファは概して接続の中断とともに消去される。そのため、ネットワーク接続が回復すると、サーバ上のユーザーセッションのようなネットワーク化アプリケーションは中断前の状態から再開することができない。概してエラーメッセージが表示され、ユーザーに不便さに対するフラストレーションを与えることになる。さらに、多くのプロトコルを使用するネットワーク上での通信では、トランスポート接続の再確立を必要とすることが多い。例えば、ＨＴＴＰを単独でまたはプロキシプロトコルと併せて使用し、標準的なＴＣＰ接続でウェブサイトを閲覧するには、各リソースに対する新しいＨＴＴＰ接続に加えて、以前のＴＣＰ／プロキシプロトコル接続を閉じて、各リソースに対する新しいＴＣＰ／プロキシプロトコル接続を開く必要がある。
【０００５】
従って、クライアントの認証証明書の再伝送を繰り返す必要がなく、また未許可のユーザーからのサーバ保護を高めながら、クライアントコンピュータとサーバコンピュータの間に通信セッションを再確立するための技術を提供することが望ましい。多数のネットワークコンポーネントをセキュアに横断するため、認証証明書の再伝送を繰り返す必要なくクライアントコンピュータとサーバコンピュータの間に通信セッションを再確立する、より高度なシステムおよび方法が必要とされる。
【発明の開示】
【課題を解決するための手段】
【０００６】
本発明は、クライアントをホストサービスとの持続的で信頼できる接続に再接続するためのシステムおよび方法に関し、その接続はネットワークコンポーネントをセキュアに横断する。クライアントの再接続は、クライアントのホストサービスへの接続の再確立と、クライアントとホストサービスの間にある１つ以上の接続の再認証を含む、クライアントのユーザーのホストサービスに対する再認証を含む。ホストサービスへの持続的で信頼できる接続は、クライアントを代表する１つ以上の第１のプロトコルサービスにより維持される。第１のプロトコルサービスは、クライアントとホストサービスの間で通信されるデータがバッファリングされ、クライアントとホストサービスの間にあるネットワーク接続におけるいかなる中断の間も維持されることを確実にする。ネットワーク接続における一時的な中断は、例えば、モバイルクライアント等のクライアントが同じネットワーク内の異なるアクセスポイント間でローミングを行う際、またはクライアントがネットワークを（例えば、有線ネットワークから無線ネットワークへ）切り替える際に起こりうる。
【０００７】
ネットワーク中断の間バッファリングされたデータを維持することに加え、第１のプロトコルサービスは、クライアントの第１のプロトコルサービスへの接続を再確立する際に、ホストサービスに対しクライアントを再認証する。これはクライアントのユーザーがそのホストサービスとの接続を再確立するために認証証明書を再入力するのを防止する。さらに、クライアントとホストサービスの間にある多数の接続のそれぞれは、ホストサービスへのアクセスにおいて追加セキュリティ保護を提供するために、例えばプロキシとして作用する第１のプロトコルサービスを介して再認証される。再認証後、第１のプロトコルサービスはクライアントの接続ホストサービスに再度リンクする。要約すると、本発明は、サーバに対するネットワークコンポーネントをセキュアに横断するため、またユーザーが認証証明書を再入力することなく、クライアントとホストサービスの間にあるネットワーク接続の再確立を提供するものである。
【０００８】
一局面において、本発明はクライアントとホストサービスを再接続するための方法に関する。前記方法は、クライアントと第１のプロトコルサービスの間にある第１の接続および第１のプロトコルサービスとホストサービスの間にある第２の接続を介し、クライアントおよびホストサービスの間に通信セッションを提供するステップを含む。前記方法は、第１の接続および第２の接続のうち一方における中断を検出し、第１の接続および第２の接続のうちもう一方を維持するステップをさらに含む。前記方法の別のステップにおいて、第１のプロトコルサービスは第１のチケットおよび第２のチケットを得て、中断した接続を再確立するために第１のチケットを有効にする。第１のプロトコルサービスは維持された接続の使用を継続するために第２のチケットを有効にし、再確立された接続を維持された接続にリンクする。
【０００９】
一実施態様において、前記方法は中断した接続において、中断の間、通信セッションを維持するステップを含む。別の実施態様において、前記方法は前記第１のプロトコルサービスおよびチケットオーソリティのうち少なくとも１つによって、前記第１のチケットおよび前記第２のチケットのうちいずれか１つを生成するステップをさらに含む。前記方法は、前記チケットオーソリティによって、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを有効にするステップを含んでよい。
【００１０】
別の実施態様において、前記方法は、ウェブサーバに対しクライアントを認証するステップと、ウェブサーバによって、前記第１のチケットを前記クライアントへ伝送するステップとをさらに含む。前記方法は、前記ホストサービスによって、通信セッションの確立時に前記クライアントを認証するステップをさらに含んでよい。一実施態様において、前記方法は、前記クライアントによって、前記第１のチケットを前記第１のプロトコルサービスへ伝送するステップを含む。
【００１１】
さらなる実施態様において、前記第１のプロトコルサービスはプロキシサーバを含む。別の実施態様において、前記第１のプロトコルサービスはセキュリティゲートウェイを含む。前記方法は、第２のプロトコルをカプセル化する第１のプロトコルを使用して通信を行う前記クライアントおよび前記第１のプロトコルサービスと、前記第２のプロトコルを使用して通信を行う前記第１のプロトコルサービスおよび前記ホストサービスとをさらに含んでよい。
【００１２】
別の実施態様において、前記第１のチケットは前記第１の接続に有効であり、前記第２のチケットは前記第２の接続に有効である。任意で、前記第２のチケットは、前記第１のチケットが有効にされるまで使用不可能であってよい。一実施態様において、前記再確立された接続は、前記第１のチケットおよび前記第２のチケットが有効にされた後、前記維持された接続にリンクされる。
【００１３】
さらなる実施態様において、前記第１の接続および前記第２の接続のうちいずれかまたは両方が、中間ノードおよび１つ以上の第１のプロトコルサービスのうちいずれか１つを介して接続された複数の接続を含んでよい。前記方法は、前記複数の接続のうち少なくとも１つのために第３のチケットを生成するステップをさらに含んでよい。前記第３のチケットは、前記複数の接続のうち少なくとも１つに有効であってよい
別の局面において、本発明はクライアントをホストサービスに再接続するためのシステムに関する。前記システムは、クライアントおよび第１のプロトコルサービスを含む。前記クライアントは、第１の接続を介しホストサービスとの通信セッションを確立する。前記第１のプロトコルサービスは、前記クライアントとの前記第１の接続および前記ホストサービスとの第２の接続を確立する。前記第１のプロトコルサービスは、前記第１の接続および前記第２の接続のうち少なくとも１つを含む接続を維持する。さらに、前記第１のプロトコルサービスは、前記第１の接続および前記第２の接続のうち一方において中断した接続を再確立するために第１のチケットを有効にし、前記第１の接続および前記第２の接続のうちもう一方を使用するために第２のチケットを有効にする。前記システムは、前記再確立された接続を前記維持された接続にリンクする前記第１のプロトコルサービスをさらに含む。
【００１４】
一実施態様において、前記システムは前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを生成するチケットオーソリティをさらに含む。別の実施態様において、前記第１のプロトコルサービスは、前記中断した接続において、中断の間、前記通信セッションを維持する。さらなる実施態様において、前記第１のプロトコルサービスは、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを生成する。前記システムは、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを有効にする前記チケットオーソリティを含んでよい。
【００１５】
別の実施態様において、前記システムはウェブサーバをさらに含む。前記ウェブサーバは前記クライアントを認証し、一実施態様において、前記第１のチケットを前記クライアントに伝送する。さらなる実施態様において、前記クライアントは前記第１のチケットを前記第１のプロトコルサービスに伝送する。さらに別の実施態様において、前記ホストサービスは前記通信セッションの確立時に前記クライアントを認証する。
【００１６】
一実施態様において、前記第１のプロトコルサービスはプロキシサーバを含み、別の実施態様において、前記第１のプロトコルサービスはセキュリティゲートウェイを含む。前記システムは、第２のプロトコルをカプセル化する第１のプロトコルを使用して通信を行う前記クライアントおよび前記第１のプロトコルサービスと、前記第２のプロトコルを使用して通信を行う前記第１のプロトコルサービスおよび前記ホストサービスとを含んでよい。
【００１７】
さらなる実施態様において、前記第１のチケットは前記第１の接続に有効であり、前記第２のチケットは前記第２の接続に有効である。また、前記第２のチケットは、前記第１のチケットが有効にされるまで使用不可能であってよい。一実施態様において、前記第１のプロトコルサービスは、前記第１のチケットおよび前記第２のチケットが有効にされた後、前記再確立された接続を前記維持された接続にリンクする。
【００１８】
さらなる実施態様において、前記第１の接続および前記第２の接続のうちいずれか１つは、中間ノードおよび１つ以上の第１のプロトコルサービスのうちいずれか１つを介して接続された複数の接続を含む。前記システムは、前記複数の接続のうち少なくとも１つのために第３のチケットの生成をさらに含み、一実施態様において、前記第３のチケットは、前記複数の接続のうち少なくとも１つに対し有効である。
【００１９】
付随する図面および以下の説明において、本発明の様々な実施態様を詳しく説明する。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の特定の実施態様について説明する。しかし、本発明は、これらの実施態様に限定されるものではなく、本願明細書に明白に開示した内容への追加および変更が本発明の範囲に明白に含まれることを意図していることに留意されたい。さらに、本願明細書に開示される種々の実施態様の特徴は排他的でなく、本願明細書に組み合わせまたは置き換えが明示されていなくても、本発明の精神と範囲から逸脱することなくそのような組み合わせおよび置き換えが存在しうると理解されたい。
【００２１】
本発明の具体例は、クライアントとホストサービスの間に確実で持続的な接続を確立し、接続において中断がある場合に接続を再接続するシステムおよび方法を提供する。クライアントはクライアントと第１のプロトコルサービスの間の第１の接続および第１のプロトコルサービスとホストサービスの間の第２の接続を介してホストサービスと通信セッションを確立する。クライアントは第１のプロトコルを使用して第１のプロトコルサービスと通信を行い、第１のプロトコルサービスは第２のプロトコルを使用してホストサービスと通信を行う。第２のプロトコルはクライアントから第１のプロトコル通信内でカプセル化された第１のプロトコルへの通信を行う。第１の接続または第２の接続いずれかにおいて中断が検出された場合、第１のプロトコルサービスは、中断されていない接続を維持しながら、中断された接続を再確立する。中断された接続は、クライアントをホストサービスに再接続するため、維持された接続とリンクされる。
【００２２】
さらに、本発明の具体例は、クライアントのホストサービスへの接続確立および再接続においてネットワークコンポーネントをセキュアに横断するシステムおよび方法を提供する。第１のプロトコルサービスはクライアントとホストサービスの間のプロキシとして作用することができ、セキュリティゲートウェイを含んでもよい。第１のプロトコルサービスはチケットオーソリティより第１のチケットおよび第２のチケットを得る。第１のチケットはクライアントと第１のプロトコルサービスの間の接続を有効にするために使用され、第２のチケットは第１のプロトコルサービスとホストサービスの間の接続を有効にするために使用される。第２のチケットは、第１のチケットが有効にされるまで使用不可能であってよい。第１のプロトコルサービスは第１のチケットを、第１の接続の使用の再確立または維持において有効にし、第２のチケットを、第２の接続の使用の再確立および維持において有効にする。第１および第２のチケットが有効にされ接続が再確立されると、第１のプロトコルサービスは、クライアントのホストサービスとの通信セッションを維持するため、第１の接続を第２の接続にリンクする。追加のチケットが生成され、ユーザーの追加通信、またはクライアントとホストサービスの間の「ホップ」を再確立または維持してもよい。このようにして、クライアントとホストサービスの間の各通信または「ホップ」は有効にされる。
【００２３】
図１Ａを参照すると、概して本発明は、ネットワーク通信に関し、特にクライアントへのホストサービスとの信頼できる接続の提供に有用となりうる。概観すると、ネットワーク通信のシステム１００は、ネットワーク１０４上で第１のプロトコルサービス１１２（例えば、第２のコンピュータ）と通信を行うクライアント１０８（例えば、第１のコンピュータ）を含む。またシステム１００は、ホストノード１８８上にあり、第１のプロトコルサービス１１２と通信を行い、第１のプロトコル１１２を経由してネットワーク１０４上でクライアント１０８と通信を行う複数のホストサービス１１６ａ乃至１１６ｎ（例えば、第３のコンピュータ）も含む。あるいは、本発明の別の実施態様では、図１Ｂを参照すると、第１のプロトコルサービス１１２およびホストサービス１１６ａ乃至１１６ｎは、独立したコンピュータとして使用されるのではなく、むしろ図１Ａのように、例えばホストノード１１８aのような同じコンピュータに組み込まれる。図１Ｂにおいて、ホストサービス１１６ａ乃至１１６ｎは、ネットワーク１０４’上で第１のプロトコルサービス１１２と通信を行う。システム１００は、１つ、２つ、または多数のホストノード１１８ａ乃至１１８ｎを含むことができる。
【００２４】
一実施態様において、図１Ｂに示すように、ネットワーク１０４および１０４’は独立したネットワークである。図１Ａに示すように、ネットワーク１０４および１０４’は同じネットワーク１０４とすることができる。一実施態様では、ネットワーク１０４および／またはネットワーク１０４’は、例えば、会社のイントラネットのようなローカルエリアネットワーク（ＬＡＮ）または、例えば、インターネットまたはワールドワイドウェブのようなワイドエリアネットワーク（ＷＡＮ）である。クライアント１０８、第１のプロトコルサービス１１２、ホストサービス１１６ａ乃至１１６ｎ、および／またはホストノード１１８ａ乃至１１８ｎは、これらに限定されないが、標準電話回線、ＬＡＮまたはＷＡＮのリンク（例えば、８０２．１１、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、ブロードバンド接続（例えば、ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）、無線接続、あるいはこれらのいずれかまたはすべてを組み合わせたものなど、様々な接続を介してネットワーク１０４および／またはネットワーク１０４’に接続することができる。
【００２５】
クライアント１０８は第１のプロトコルサービス１１２とクライアント‐第１のプロトコルサービス間通信チャネル１３５上で通信を行っており、またクライアント‐ウェブサーバ間通信チャネル１４０上でウェブサーバ１２０とも通信を行っている。第１のプロトコルサービス１１２は第１のプロトコルサービス‐オーソリティ間通信チャネル１４５でチケットオーソリティ１３６と通信を行っており、ウェブサーバ１２０はウェブサーバ‐オーソリティ間通信チャネル１５０上でチケットオーソリティ１３６と通信を行っている。第１のプロトコルサービス１１２は第１のプロトコルサービス‐サーバ間通信チャネル１２４ａ乃至１２４ｎ上でホストノード１１８とも通信を行っている。別の実施態様において、ウェブサーバ１２０はエージェント‐サーバ間通信チャネル１５５上でホストノード１１８と通信を行うことができる。同様に、ホストノード１１８はチケット‐サーバ間通信チャネル１５７上でチケットオーソリティ１３６と通信を行うことができる。一実施態様において、それぞれの通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４４、１５０、１５５、１５７は、ネットワーク１０４上に確立される。
【００２６】
通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４４、１５０、１５５、１５７の実施例は、標準電話回線、ＬＡＮまたはＷＡＮのリンク（例えば、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、ブロードバンド接続（ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）、および無線接続を含む。通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４４、１５０、１５５、１５７上での接続は、様々な通信プロトコル（例えば、ＨＴＴＰ、ＨＴＴＰＳ、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＰＸ、ＮｅｔＢＩＯＳ、イーサネット（登録商標）、ＲＳ２３２、メッセージングアプリケーションプログラミングインターフェイス（ＭＡＰＩ）プロトコル、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、ユーザーデータグラムプロトコルスキーム用リアルタイムストリーミングプロトコル（ＲＴＳＰＵ）、ＲｅａｌＮｅｔｗｏｒｋｓ社（Ｓｅａｔｔｌｅ、ＷＡ）製のＰｒｏｇｒｅｓｓｉｖｅ Ｎｅｔｗｏｒｋｓ Ｍｕｌｔｉｍｅｄｉａ（ＰＮＭ）プロトコル、マニュファクチャリングメッセージスペシフィケーション（ｍａｎｕｆａｃｔｕｒｉｎｇ ｍｅｓｓａｇｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＭＭＳ）プロトコル、および直接非同期接続等）を使用して確立される。
【００２７】
別の局面において、図１Aはコンテンツを渡してもらうための通信システム１００の実施態様のブロック図を示す。一実施態様において、第１のプロトコルサービス１１２はプロキシ１１５を備え、システム１００はウェブサーバ１２０およびチケットオーソリティ１３６を含む。システム１００は、ホストノード１１８へ／からの未許可の通信を禁止する２つのファイアウォール１６０、１６１も含む。ファイアウォール１６０、１６１の間のネットワークは多くの場合「非武装地帯」（DＭＺ）１３０と称される。一実施態様において、ＤＭＺ１３０はプロキシ１１５およびウェブサーバ１２０を備えるチケットプロトコルサービス１１２を含む。
【００２８】
ＤＭＺ１３０はホストサービス１１６ａ乃至１１６ｎを未許可の個人によりアクセス可能なシステム１００の構成要素（例えば、第１のプロトコルサービス１１２）から分離する。上述のように、ＤＭＺ１３０は未許可の通信を禁止する２つのファイアウォール１６０、１６１で線引きされている。第１のファイアウォール１６０および第２のファイアウォール１６１はそれぞれポリシールール一式を適用し、どのメッセージがＤＭＺ１３０を横断しうるか判断する。一実施態様において、第１のファイアウォール１６０および第２のファイアウォール１６１は同じポリシールール一式を適用する。あるいは、第１のファイアウォール１６０および第２のファイアウォール１６１は、異なるポリシールール一式を適用してもよい。各ファイアウォール１６０、１６１は、ルータ、コンピュータ、またはその他任意のネットワーク制御装置であってよい。別の実施態様において、システム１００はファイアウォール１６０、１６１のいずれか１つを含むか、またはファイアウォール１６０、１６１いずれも含まない。別の実施態様において、ファイアウォール１６０、１６１のうちいずれかがホストノード１１８上に配置されている。別の実施態様（図示なし）において、ファイアウォール１６０、１６１のうち１つ以上が中間ノードに配置されている。
【００２９】
一実施態様において、第１のプロトコルサービス１１２は、メッセージがクライアント‐第１のプロトコルサービス間通信チャネル１３５上で通過すべきセキュリティゲートウェイを備えるプロキシ１１５を含む。一実施態様において、ネットワークファイアウォール１６０は、クライアント‐第１のプロトコルサービス間通信チャネル１３５からの、その宛先として第１のプロトコルサービス１１２を持たないいかなる着信メッセージも拒否する。同様に、ネットワークファイアウォール１６０は、その発信元が第１のプロトコルサービス１１２でない限り、クライアント‐第１のプロトコルサービス間通信チャネル１３５へのいかなる送信メッセージも拒否する。第１のプロトコルサービス１１２のプロキシ１１５として図示されているが、セキュリティゲートウェイは代替としてルータ、ファイアウォール、中継器、または必要なセキュア性を提供できる任意のネットワークコンポーネントであってよい。別の実施態様において、プロキシ１１５は第１のプロトコルサービス１１２の同じコンピュータまたは異なるコンピュータ上で動作できる第１のプロトコルサービス１１２から分離したネットワークコンポーネントである。例えば、図１Ｂにおいて、プロキシ１１５は第１のプロトコルサービス１１２から分離されている。プロキシ１１５はウェブサーバ１２０とともにＤＭＺ１３０内にある。第１のプロトコルサービス１１２の多数の例がホストノード１１８ａ乃至１１８ｎのそれぞれにおいて動作している。各第１のプロトコルサービス１１２は通信チャネル１３５上でプロキシ１１５と通信を行い、これがクライアント‐第１のプロトコルサービス間通信チャネル１３５である。この場合、プロキシ１１５の要素はセキュアにクライアント１０８と第１のプロトコルサービス１１２の間の通信を通過するための中間段階である。
【００３０】
ネットワーク１０４は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、またはインターネットやワールドワイドウェブ（すなわちウェブ）等のネットワークのネットワークであってよい。各通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４５、１５０、１５５、１５７は、それぞれ異なるネットワークの一部であってよい。例えば、クライアント‐第１プロトコルサービス間通信チャネル１３５は第１のネットワーク（例えば、ワールドワイドウェブ）に属してよく、クライアント‐ウェブサーバ間通信チャネル１４０は第２のネットワーク（例えば、保護されたエクストラネットまたは仮想プライベートネットワーク（ＶＰＮ））に属してよい。別の実施態様において、ネットワーク１０４はサーバファーム１６９と同様にＤＭＺ２３０におよび、全体にわたり同じ通信プロトコルが使用される。同じ実施態様において、ファイアウォール１６０が第１のプロトコルサービス１１２およびウェブサーバ１２０をホストノード１１８およびチケットオーソリティ１３６から分離しない。
【００３１】
通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４４、１５０、１５５、１５７の実施例は、標準電話回線、ＬＡＮまたはＷＡＮのリンク（例えば、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、ブロードバンド接続（ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）、および無線接続を含む。通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４４、１５０、１５５、１５７上での接続は、様々な通信プロトコル（例えば、ＨＴＴＰ、ＨＴＴＰＳ、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＰＸ、ＮｅｔＢＩＯＳ、イーサネット（登録商標）、ＲＳ２３２、メッセージングアプリケーションプログラミングインターフェイス（ＭＡＰＩ）プロトコル、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、ユーザーデータグラムプロトコルスキーム用リアルタイムストリーミングプロトコル（ＲＴＳＰＵ）、ＲｅａｌＮｅｔｗｏｒｋｓ社（Ｓｅａｔｔｌｅ、ＷＡ）製のＰｒｏｇｒｅｓｓｉｖｅ Ｎｅｔｗｏｒｋｓ Ｍｕｌｔｉｍｅｄｉａ（ＰＮＭ）プロトコル、マニュファクチャリングメッセージスペシフィケーション（ｍａｎｕｆａｃｔｕｒｉｎｇ ｍｅｓｓａｇｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＭＭＳ）プロトコル、および直接非同期接続等）を使用して確立されることができる。
【００３２】
クライアント１０８は、任意のワークステーション、デスクトップコンピュータ、ラップトップ、ハンドヘルドコンピュータ、携帯電話、スマート端末またはダム端末、ネットワークコンピュータ、無線機器、情報家電、ミニコンピュータ、大型汎用コンピュータ、または通信が可能で、本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する他の形態のコンピュータまたはテレコミュニケーション装置とすることができる。さらに、クライアント１０８は、ローカルネットワーク１０４上のローカルデスクトップクライアントであってよく、または分離したネットワーク１０４’であってもよい。クライアント１０８は、例えば視覚的表示装置（例えば、コンピュータ用モニタ）、データ入力装置（例えば、キーボード）、持続的および／または揮発性記憶装置（例えば、コンピュータメモリ）、プロセッサ、およびマウスを含むことができる。クライアント１０８にサポートされるオペレーティングシステムは、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）のオペレーティングシステムであるＷＩＮＤＯＷＳ（登録商標）シリーズのいずれか、Ｍａｃｉｎｔｏｓｈオペレーティングシステム、Ｊａｖａ（登録商標）ＯＳ、および多種にわたるＵＮＩＸ（登録商標）（例えばＳｏｌａｒｉｓ、ＳｕｎＯＳ、Ｌｉｎｕｘ、ＨＰ−ＵＸ、Ａ／ＩＹおよびＢＳＤベースのディストリビューション）、または本願明細書に記載の動作の実行においてクライアント１０８をサポート可能なその他任意のオペレーティングシステムを含むことができる。
【００３３】
一実施態様において、クライアント１０８は、ウェブに接続するためにＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＩＮＴＥＲＮＥＴ ＥＸＰＬＯＲＥＲのようなウェブブラウザ１６２を含む。さらなる実施態様において、ウェブブラウザ１６２はウェブサーバ１２０に対するセキュアなクライアント‐ウェブサーバ間通信チャネル１４０を確立するため、既存のセキュアソケットレイヤー（ＳＳＬ）サポートを使用する。ＳＳＬは、Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ社（Ｍｏｕｎｔａｉｎ Ｖｉｅｗ、Ｃａｌｉｆｏｒｎｉａ）が開発し、インターネット技術特別調査委員会（ＩＥＴＦ）が広めた現在の標準である。
【００３４】
一部の実施態様においては、図１Ａおよび１Ｂに示すように、クライアントエージェント１２８がクライアント１０８内に含まれる。クライアントエージェント１２８は、クライアント‐第１のプロトコルサービス通信チャネル１３５上でホストサービス１１６ａ乃至１１６ｎとの通信を確立し交信を行うために使用されてよい。クライアントエージェント１２８は、例えばソフトウェアプログラムおよび／または例えば、ＡＳＩＣまたはＦＰＧＡなどのようなハードウェア装置として使用することができる。クライアントエージェント１２８は、あらゆるタイプのプロトコルを使用することができ、それには、例えば、ＨＴＴＰクライアントエージェント、ＦＴＰクライアントエージェント、Ｏｓｃａｒクライアントエージェント、Ｔｅｌｎｅｔクライアントエージェントが挙げられる。一実施態様において、クライアントエージェント１２８はＣｉｔｉｒｉｘ Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ Ｌａｕｄｅｒｄａｌｅ、Ｆｌｏｒｉｄａ）製のＩＣＡクライアントであり、これを以下ＩＣＡクライアント１２８と称する。クライアントエージェント１２８の他の実施態様は、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｏｔｎ）製のＲＤＰクライアント、従来型のクライアントサーバアプリケーションにおけるデータ入力クライアント、Ａｃｔｉｖｅ ＸコントロールまたはＪａｖａ（登録商標）アプレットを含む。一部の実施態様において、クライアントエージェント１２８は、それ自体が第１のプロトコルを使用して通信を行うよう構成される。一部の実施態様では（図示せず）、クライアント１０８は、複数のクライアントエージェント１２８ａ乃至１２８ｎを含み、それぞれがホストサービス１１６ａ乃至１１６ｎとそれぞれ通信を行う。さらに、ホストサービス１１６ａ乃至１１６ｎ上で実行するアプリケーションのアウトプットは、例えばクライアントエージェント１２８またはウェブブラウザ１６２を介してクライアント１０８に表示される。
【００３５】
別の実施態様において、スタンドアロンのクライアントエージェントは、第１のプロトコルを使用してクライアント１０８が通信できるように構成される。スタンドアロンのクライアントエージェントは、クライアント１０８内に組み込むか、または代わりに、スタンドアロンのクライアントエージェントをクライアント１０８から独立させることができる。スタンドアロンのクライアントエージェントは、例えば、ローカルホストのプロキシである。一般に、スタンドアロンのクライアントエージェントは、クライアントエージェント１２８に関する本願明細書に開示された機能のいずれかを実行することができる。
【００３６】
同様に、図１Ａを参照して、第１のプロトコルサービス１１２とホストサービス１１６ａ乃至１１６ｎのそれぞれは、通信が可能で本願明細書に開示した動作を行うのに十分なプロセッサ能力とメモリ容量を有する、任意のコンピュータ上で提供されることができる。あるいは、例えば図１Ｂのようにホストノード１１８ａ乃至１１８ｎのいずれかのような、第１のプロトコルサービス１１２およびホストサービス１１６ａ乃至１１６ｎの機能性が同じコンピュータに組み込まれている場合、第１のプロトコルサービス１１２および／またはホストサービス１１６ａ乃至１１６ｎは汎用コンピュータおよび／または、例えば、ＡＳＩＣまたはＦＰＧＡのような特殊用途向けハードウェア装置上で実行されるソフトウェアプログラムとしてとして使用することができる。
【００３７】
クライアント１０８と同様に、ホストノード１１８ａ乃至１１８ｎのそれぞれは上述した通信が可能で本願明細書に開示した動作を行うのに十分なプロセッサ能力とメモリ容量を有する任意のコンピュータ（例えばパーソナルコンピュータ）であってよい。ホストノード１１８ａ乃至１１８ｎのそれぞれは、様々な通信プロトコル（例えばＩＣＡ、ＨＴＴＰ、ＴＣＰ／ＩＰおよびＩＰＸ）、ＳＰＸ、ＮｅｔＢＩＯＳ、イーサネット（登録商標）、ＲＳ２３２、直接非同期接続を使用して通信チャネル１２４ａ乃至１２４ｎ上に通信を確立することができる。
【００３８】
一実施態様において、ホストサービス１１６ａ乃至１１６ｎのそれぞれは、クライアント１０８に対して遠隔で利用可能な１つ以上のアプリケーションプログラムをホストする。クライアント１０８に対して利用可能にされたアプリケーションを、公開されたアプリケーションと称する。１つまたは複数のホストサービス１１６ａ乃至１１６ｎが同じアプリケーションプログラムをホストすることができる。このようなアプリケーションの例には、ＭＩＣＲＯＳＯＦＴ ＷＯＲＤなどのワード処理プログラム、およびＭＩＣＲＯＳＯＦＴ ＥＸＣＥＬなどの表計算プログラムなどが挙げられ、そのどちらもＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｏｔｎ）から入手可能である。一部またはすべてのホストサービス１１６ａ乃至１１６ｎがホスト可能な他のアプリケーションプログラムの例には、財務報告プログラム、顧客登録プログラム、技術的なサポート情報を提供するプログラム、顧客データベースアプリケーション、およびアプリケーションの設定マネージャが挙げられる。さらに、一実施態様では、ホストサービス１１６ａ乃至１１６ｎのうち１つ以上は、ストリーミングオーディオおよび／またはストリーミングビデオをクライアント１０８に提供するオーディオ／ビデオストリーミングサーバである。別の実施態様では、ホストサービス１１６ａ乃至１１６ｎは、一部／すべてのファイルタイプをクライアント１０８に提供するファイルサーバを備える。一実施態様では、ホストサービス１１６ａ乃至１１６ｎは、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ Ｌａｕｄｅｒａｌｅ、Ｆｌｏｒｉｄａ）製のＩＣＡまたはＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＲＤＰのようなプレゼンテーションプロトコルを使用して、クライアント１０８と通信を行うことができる。
【００３９】
さらなる実施態様において、ホストノード１１８はサーバファーム１６９または単一エンティティとして管理される１つ以上のサーバの論理グループであるサーバネットワークの一部である。一実施態様において、サーバファーム１６９は多数のホストノード１１８ａ乃至１１８ｎ（概して１１８）を含む。図１Ｂに示される形態は３つのホストノード１１８ａ乃至１１８ｎを有しているが、サーバファーム１６９はホストノード１１８またはサーバをいくつでも有することができる。他の実施態様において、サーバファーム１６９は、企業イントラネット、仮想プライベートネットワーク（ＶＰＮ）、またはセキュアなエクストラネット等、未許可の個人によるアクセス不可能な、保護されたネットワークである。また、サーバファーム１６９を構成するサーバは、上記プロトコルのいずれかを使用して、上述したネットワーク（例えばＷＡＮ、ＬＡＮ）のいずれかで通信を行うことができる。
【００４０】
図１Ａに示されるチケットオーソリティ１３６は、サーバファーム１６９の一部であり、クライアント１０８に対して認証を行うために１つ以上のチケットを発行する。特に、チケットオーソリティ１３６は、認証証明書に基づき、１つの通信チャネル（すなわち、クライアント‐ウェブサーバ間通信チャネル１４０）上でクライアント１０８の認証を可能にする。チケットオーソリティ１３６はさらに、その他の通信チャネルにおいて繰り返し認証証明書を提供することなく、クライアント１０８が別の通信チャネル（すなわち、クライアント‐第１のプロトコルサービス通信チャネル１３５）上で認証されることを可能にする。
【００４１】
一実施態様において、チケットオーソリティ１３６はスタンドアロンのネットワークコンポーネントである。他の実施態様において、モジュールチケットオーソリティ１３６は１つ以上のホストノード１１８にあるソフトウェアモジュールである。例えば、図１Ｂに示されるように、ホストノード１１８ａ乃至１１８ｎのそれぞれに対しチケットオーソリティ１３６があってよい。この実施態様において、ウェブサーバ１２０は、エージェント‐サーバ間通信チャネル１５５上でチケットオーソリティ１３６および／またはホストノード１１８と通信を行うことができる。別の実施態様において、チケットオーソリティ１３６はホストノード１１８ａ乃至１１８ｎのいずれからも分離された中間ノードにあってよい。
【００４２】
一実施態様において、チケットオーソリティ１３６は第１のチケットおよび第２のチケットを生成する。一部の実施態様において、チケットはいずれもその場限りのものである。さらなる実施態様において、チケットは適切に乱数度をシードされた暗号化乱数発生器を使用して生成される。第１のチケットはクライアント１０８に伝送され、クライアント１０８と第１のプロトコルサービス１１２の間に第１の通信セッションを確立するために使用される。第２のチケットは第１のプロトコルサービス１１２に伝送され、第１のプロトコルサービス１１２とホストノード１１８の間に第２の通信セッションを確立するために使用される。
【００４３】
一実施態様において、ウェブサーバ１２０はウェブページをクライアント１０８に配信する。ウェブサーバ１２０は、任意のパーソナルコンピュータ（例えば、Ｍａｃｉｎｔｏｓｈコンピュータ、Ｉｎｔｅｌ社（Ｓａｎｔａ Ｃｌａｒａ、Ｃａｌｉｆｏｒｎｉａ）製のＩｎｔｅｌマイクロプロセッサを搭載したパーソナルコンピュータ、Ａｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ社（Ｓｕｎｎｙｖａｌｅ、Ｃａｌｉｆｏｒｎｉａ）製のＡＭＤを搭載したパーソナルコンピュータ等）、Ｗｉｎｄｏｗｓ（登録商標）ベースの端末、ネットワークコンピュータ、ワイヤレス機器（例えば携帯電話）、情報家電、ＲＩＳＣ Ｐｏｗｅｒ ＰＣ、Ｘ−ｄｅｖｉｃｅ、ワークステーション、ミニコンピュータ、大型汎用コンピュータ、携帯情報端末、またはクライアント１０８とのセキュアなクライアント‐ウェブサーバ間通信チャネル１４０を確立できるその他の通信機器であってよい。
【００４４】
別の実施態様において、ウェブサーバ１２０は企業情報ポータル（Ｅｎｔｅｒｐｒｉｓｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｏｒｔａｌ）とも称される企業内ポータルをクライアント１０８に提供する。企業内ポータルは、情報を組織化しより効率的に使用するための管理ツールを提供しながら、ユーザーにアプリケーション、データおよびコンテンツを情報集約し、個人化し、供給する、会社のウェブサイトである。他の実施態様において、ウェブサーバ１２０は、ウェブポータルまたはインターネットポータルをクライアント１０８に提供する。ウェブポータルは、企業ポータルと同様であるが、概して業務用の情報は含まない。
【００４５】
一実施態様において、クライアント１０８のユーザーは、ウェブサーバ１２０に対しユーザーを認証するためにウェブブラウザ１６２を使用する。一実施態様において、クライアント１０８はログインおよびパスワード情報等のユーザー認証証明書をウェブサーバ１２０へ伝送する。ウェブサーバ１２０は、ユーザーがサーバネットワーク１６９にアクセスできることを検証する。
【００４６】
さらなる実施態様において、ウェブブラウザ１６２は、セキュアなクライアント‐ウェブサーバ間通信チャネル１４０を確立するためにＳＳＬを使用する。ウェブブラウザ１６２は、Ｔｅｒｉｓａ Ｓｙｓｔｅｍｓ社（Ｌｏｓ Ａｌｔｏｓ、ＣＡ）製のセキュアハイパーテキスト転送プロトコル（ＳＨＴＴＰ）、ＳＳＬ上のＨＴＴＰ（ＨＴＴＰＳ）、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のプライベートコミュニケーションテクノロジー（ＰＣＴ）、およびインターネット技術特別調査委員会（ＩＥＴＦ）が広めたトランスポートレベルセキュリティ（ＴＬＳ）標準等であるがこれらに限定されないその他のセキュリティプロトコルを使用し、クライアント‐ウェブサーバ通信間チャネル１４０上で代替的にウェブサーバ１２０に接続することができる。一実施態様において、ウェブサーバ１２０は、上述のように、クライアント１０８がアプリケーションまたはサーバデスクトップを、例えば遠隔でクライアント１０８上に表示されるよう要求できるようにする、ユーザーの検証時にウェブポータルまたは企業ポータルをクライアント１０８へ伝送する。
【００４７】
クライアント‐ウェブサーバ間通信チャネル１４０は、任意のセキュアな通信チャネルである。一部の実施態様において、チャネル１４０上での通信は暗号化される。これらの実施態様のいくつかにおいて、クライアント１０８とウェブサーバ１２０は、ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）のセキュアソケットレイヤー（ＳＳＬ）を使用して通信を行うことができる。あるいは、クライアント１０８とウェブサーバ１２０は、通信を保護するため、対称的暗号化技術等、その他の暗号化技術を使用してもよい。
【００４８】
さらに、一実施態様において、クライアント‐第１のプロトコルサービス間通信チャネル１３５は、例えば、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ Ｌａｕｄｅｒｄａｌｅ、Ｆｌｏｒｉｄａ）製インディペンデントコンピューティングアーキテクチャ（ＩＣＡ）プロトコル等のプレゼンテーションサービスプロトコルを使用することによって確立できる。ＩＣＡは、ＴＣＰ／ＩＰ、ＩＰＸ／ＳＰＸ、ＮｅｔＢＥＵＩ等の業界標準ネットワークプロトコル上で、ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、および非同期転送モード（ＡＴＭ）等の業界標準トランスポートプロトコルを使用して実行するために設計された汎用プレゼンテーションサービスプロトコルである。ＩＣＡプロトコルは、データを交換するためのコマンドを発行するためにアプリケーション層コードが使用するセッション指向の伝送接続である仮想チャネルを提供する。別の実施態様において、クライアント‐第１のプロトコルサービス間通信チャネル１３５は、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＴｈｉｎ Ｘプロトコルまたはリモートディスプレイプロトコル（ＲＤＰ）を使用して確立できる。
【００４９】
クライアント１０８と第１のプロトコルサービス１１２の間の第１の通信セッション、および第１のプロトコルサービス１１２とホストノード１１８の間の第２の通信セッションとして説明したが、通信セッションは、クライアント１０８とホストサービス１１６の間の単一で論理的な通信セッションとみなされる場合もある。
【００５０】
引き続き図１Ａおよび図１Ｂを参照して、クライアント１０８は、第１のプロトコルを使用してネットワーク１０４を通じてクライアント１０８と第１のプロトコルサービス１１２との間の接続１３５を確立するように構成される。第１のプロトコルサービス１１２は、その役割として、接続１３５を受け入れるように構成される。従って、クライアント１０８および第１のプロトコルサービス１１２は、図２Ａ乃至２Ｂおよび図３を参照して以下に説明するように、第１のプロトコルを使用して互いに通信を行うことができる。
【００５１】
また以下でさらに説明するように、第１のプロトコルサービス１１２は、一実施態様において、それ自体が第１のプロトコルを使用して通信を行うよう構成される。第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２とホストサービス１１６ａ乃至１１６ｎの間にそれぞれ接続１２４ａ乃至１２４ｎを確立するよう構成されている。例えば、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２と１つのホストサービス１１６ａの間に接続１２４ａを、また第１のプロトコルサービス１１２と別のホストサービス１１６ｂの間に接続１２４ｂを確立することができる。一実施態様において、第１のプロトコルサービス１０８はそのような接続１２４ａ乃至１２４ｎを個別に確立することができる（すなわち、第１のプロトコルサービス１１２は１回に１つの接続を確立する）。別の実施態様において、第１のプロトコルサービス１１２は、そのような接続１２４ａ乃至１２４ｎを２つ以上同時に確立する。
【００５２】
さらに別の実施態様において、第１のプロトコルサービス１１２は、複数の接続１２４ａ乃至１２４ｎを同時に確立および維持することができる。第１のプロトコルサービス１１２は、接続１３５を中断せずに２つ以上の接続１２４ａ乃至１２４ｎをクライアント１０８に提供するよう構成される。例えば、第１のプロトコルサービス１１２は、クライアント１０８のユーザーがホストサービスに１１６ａに存在する第１のアプリケーションプログラムの実行を要求した場合、第１のプロトコルサービス１１２とホストサービス１１６ａとの間の接続１２４ａを確立するように構成することができる。ユーザーが第１のアプリケーションプログラムの実行を終了し、例えばホストサービス１１６ｂに存在する第１のアプリケーションプログラムの実行を終了し、第２のアプリケーションプログラムの実行を開始する場合、一実施態様では、第１のプロトコルサービス１１２は、接続１２４ａを中断して、第１のプロトコルサービス１１２とクライアント１０８との間の接続１３５を中断させずに第１のプロトコルサービス１１２とホストサービス１１６ｂとの間の接続１２４ｂを確立するように構成される。
【００５３】
第１のプロトコルサービス１１２およびホストサービス１１６ａ乃至１１６ｎは、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ Ｌａｕｄｅｒａｌｅ、Ｆｌｏｒｉｄａ）製のＩＣＡリモートディスプレイプロトコルおよび／またはＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＲＤＰリモートディスプレイプロトコルを含むがこれらに限定されない、様々な第２のプロトコルのうちのいずれか１つを使用して、接続１２４ａ乃至１２４ｎを通じて通信を行うことができる。例えば、第１のプロトコルサービス１１２およびホストサービス１１６ａは、ＩＣＡリモートディスプレイプロトコルを使用して接続１２４ａを通じて通信を行いながら、第１のプロトコルサービス１１２およびホストサービス１１６ｂは、ＲＤＰリモートディスプレイプロトコルを使用して接続１２４ｂを通じて通信を行うことができる。
【００５４】
一実施態様において、第１のプロトコルサービス１１２とホストサービス１１６との間の通信を行うために使用する、例えばＩＣＡリモートディスプレイプロトコルのような第２のプロトコルは、複数の仮想チャネルを含む。仮想チャネルは、データを交換するためのコマンドを発行するためにアプリケーション層コードが使用するセッション指向の伝送接続である。例えば、複数の仮想チャネルのそれぞれは、リモートクライアント１０８での機能を可能にする複数のプロトコルパケットを含むことができる。一実施態様において、複数の仮想チャネルのうちの１つが、クライアント１０８にグラフィカルユーザーインターフェイスを表示させるために、第１のプロトコルサービス１１２を介して、グラフィックスクリーンコマンドをホストサービス１１６からクライアント１０８に伝送するためのプロトコルパケットを含む。別の実施態様において、複数の仮想チャネルのうちの１つが、クライアント１０８で文書を印刷させるために、第１のプロトコルサービス１１２を介して、プリンタコマンドをホストサービス１１６からクライアント１０８に伝送するためのプロトコルパケットを含む。
【００５５】
一実施態様において、第１のプロトコルは、トンネリングプロトコルである。第１のプロトコルサービス１１２は、それぞれがホストサービス１１６ａ乃至１１６ｎの１つと第１のプロトコルサービス１１２との間の通信に使用する、複数の第２のプロトコルを第１のプロトコル内にカプセル化する。このように、ホストサービス１１６ａ乃至１１６ｎと第１のプロトコルサービス１１２は、複数の第２のプロトコルを介してクライアント１０８と通信を行う。一実施態様において、第１のプロトコルは、例えば、ＴＣＰ／ＩＰ接続を通じて複数の第２のプロトコルのトンネリングが可能な、アプリケーションレベルのトランスポートプロトコルである。
【００５６】
図２Ａを参照すると、接続１３５を介したクライアント１０８と第１のプロトコルサービス１１２との間の通信は、第１のプロトコル２０４内にカプセル化された複数の第２のプロトコル２００ａ乃至２００ｎ（例えば、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡ、および／またはＲＤＰ）の形をとる。これは、第１のプロトコル２０４の中の第２のプロトコル２００ａ乃至２００ｎの位置によって示される。セキュアな通信が要求されない場合は、図２Ａに示すように、第１のプロトコル２０４は、セキュアでないＴＣＰ／ＩＰ接続２０８を通じて通信を行うことができる。
【００５７】
ここで図２Ｂを参照すると、セキュアな通信を使用する場合、第１のプロトコル２０４は、例えば、セキュアソケットレイヤー（ＳＳＬ）のようなセキュアプロトコル２１６を使用して保護されるＴＣＰ／ＩＰ接続２１２などのような暗号化された接続を通じて通信を行う。ＳＳＬは、Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ社（Ｍｏｕｎｔａｉｎ Ｖｉｅｗ、Ｃａｌｉｆｏｒｎｉａ）が開発し、トランスポートレイヤセキュリティ（ＴＳＬ）プロトコルとしてインターネット技術特別調査委員会（ＩＥＴＦ）が広め、ＩＥＴＦ ＲＦＣ−２２４６に記載された、現在の標準である。
【００５８】
従って、複数の第２のプロトコル２００ａ乃至２００ｎは、接続１３５を通じてセキュリティ有り（図２Ｂ）またはセキュアプロトコル２１６なし（図２Ａ）で第１のプロトコル２０４内で通信を行う。接続１２４ａ乃至１２４ｎを通じて通信を行うために使用できる第２のプロトコルには、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡ、および、ＲＤＰを含むが、これらに限定されない。さらに、一実施態様において、上述のように、少なくとも１つの第２のプロトコルは、複数の仮想チャネルを含むが、それぞれリモートクライアント１０８での機能を可能にする複数のプロトコルパケットを含むことができる。例えば、一実施態様において、一方のホストサービス１１６ａはウェブサーバであり、ＨＴＴＰプロトコルを使用して接続１２４ａを通じて第１のプロトコルサービス１１２と通信を行い、他方のホストサービス１１６ｂはアプリケーションサーバであり、ＩＣＡプロトコルを使用して接続１２４ｂを通じて第１のプロトコルサービス１１２と通信を行う。ホストサービス１１６ｂは、クライアント１０８にグラフィカルユーザーインターフェイスを表示させるグラフィックスクリーンコマンドをクライアント１０８に伝送するためのプロトコルパケット、およびクライアント１０８で印刷する文書を生じさせるプリンタコマンドをクライアント１０８に伝送するためのプロトコルパケットの両方を生成する。
【００５９】
本発明の別の局面は、本願明細書に記載されている、ネットワーク接続の開閉回数を減らす方法およびシステムである。一実施態様において、第１のプロトコル２０４はその中にトンネリングした、例えば、ＨＴＴＰ接続２００ｎなどのような第２のプロトコル接続２００ａ乃至２００ｎが、第１のプロトコル２０４がそれを通じて通信を行うトランスポート接続（例えば、ＴＣＰ接続２０８および／または２１２）、セキュアプロトコル接続２１６、または第１のプロトコル接続２０４自身をも同様に繰り返して開くおよび／または閉じることを必要とせずに、開くおよび／または閉じるようにする。第１のプロトコル２０４のカプセル化なしに、第２のプロトコル２００ａ乃至２００ｎはＴＣＰ接続のようなネットワーク接続を頻繁に開閉できる。これは大きな遅延および間接費をシステムに追加するであろう。このような遅延および間接費は、ネットワーク接続の確立において大きな間接費のかかるＳＳＬ等のセキュアなカプセル化プロトコル２１４の使用によってさらに増加するであろう。第１のプロトコル２０４内において第２のプロトコル２００ａ乃至２００ｎをカプセル化し、トランスポート接続（２０８、２１２）の接続を維持することによって、第２のプロトコル２００ａ乃至２００ｎは、第１のプロトコル２０４のペイロードの一部として、頻繁で費用のかかるネットワーク接続１３５の開閉を行う必要がない。さらに、第２のプロトコル２００ａ乃至２００ｎは第１のプロトコル２０４内でセキュアプロトコル２１６と通信を行えるため、第２のプロトコル２００ａ乃至２００ｎはＳＳＬ等とのセキュアな接続を開閉する必要もない。トランスポート接続（２０８、２１２）は、カプセル化された第２のプロトコル２００ａ乃至２００ｎがセキュアなまたはセキュアでないネットワーク接続１３５を繰り返し開閉することなく通信を行えるよう、ネットワーク接続１３５を確立し維持する。これは第２のプロトコル２００ａ乃至２００ｎの通信における動作速度を大幅に上げる。
【００６０】
上述のように、第２のプロトコル２００ａ乃至２００ｎはアプリケーションに関連するプロトコルパケットを、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＲＤＡまたはＩＣＡ等のプロトコルを使用して運搬する。第２のプロトコルパケット３０４ａ乃至３０４ｎは、クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間でやりとりされるアプリケーション機能に関連するデータをトランスポートする。例えば、クライアント１０８上のユーザーは、ホストサービス１１６ａ乃至１１６ｎによって提供されるウェブページと情報のやりとりを行うことができる。クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間のトランザクションにおいて、第１のプロトコル２０４内でカプセル化された第２のプロトコル２００ａ乃至２００ｎは、ホストサービス１１６ａ乃至１１６ｎと通信を行うため、ウェブページの表示および任意のユーザー対話の受信に関連するｈｔｔｐプロトコルパケットを有することができる。トランスポート接続（２０８、２１２）は第２のプロトコル２００ａ乃至２００ｎによって維持されないため、第２のプロトコル２００ａ乃至２００ｎは任意のネットワーク接続中断に対処する必要がない。そのため、第２のプロトコル２００ａ乃至２００ｎは、そのペイロードにおいていずれのネットワーク接続中断情報も提供しなくてよい。上記の例において、クライアント１０８へ伝送される第２のプロトコル２００ａ乃至２００ｎの第２のプロトコルパケット３０４ａ乃至３０４ｎに関連するｈｔｔｐは、例えばウェブページ上でのエラーメッセージ等、ネットワーク中断が発生したという通知を提供しないであろう。従って、クライアント１０８上のユーザーは、いかなるネットワークレベル接続が中断しても第２のプロトコル２００ａ乃至２００ｎを介して通知されることはない。これは、第２のプロトコル２００ａ乃至２００ｎに関連するアプリケーションの使用中、ネットワーク接続中断をユーザーから効果的に隠す。
【００６１】
図３を参照すると、第１のプロトコルサービス１１２およびクライアント１０８のクライアントエージェント１２８が使用するプロセス例３００は、接続１３５を介して通信を行うために、複数の第２のプロトコル２００（例えば、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡおよび／またはＲＤＰ）を第１のプロトコル２０４内にカプセル化する。任意で、下記のように、第１のプロトコルサービス１１２およびクライアント１０８のクライアントエージェント１２８が使用するプロセス例３００はまた、接続１３５を介した通信の前に、第１のプロトコルのレベルで通信を圧縮および／または暗号化する。第１のプロトコルサービス１１２の観点から、第２のプロトコルパケット３０４ａ乃至３０４ｎは、接続１２４ａ乃至１２４ｎを介して第１のプロトコルサービス１１２で受信する。例えば、２つの第２のプロトコルパケット３０４ａおよび３０４ｂは、第１のプロトコルサービス１１２によって受信する。１つ、２つ、または任意の第２のプロトコルパケット３０４ａ乃至３０４ｎを受信することができる。一実施態様において、第２のプロトコルパケット３０４ａ乃至３０４ｎは、ホストサービス１１６によって接続１２４を通じて第１のプロトコルサービス１１２に伝送される。第２のプロトコルパケット３０４ａ乃至３０４ｎは、ヘッダ３０８およびデータペイロードとも呼ばれるデータパケット３１２を含む。
【００６２】
第２のプロトコルパケット３０４ａ乃至３０４ｎの受信の後に、第１のプロトコルサービス１１２は、１つ以上の第２のプロトコルパケット３０４を第１のプロトコルパケット３１６内にカプセル化する。一実施態様において、第１のプロトコルサービス１１２は、第１のプロトコルパケットヘッダ３２０を生成し、例えば、２つの第２のプロトコルパケット３０４ａおよび３０４ｂなどのような、１つ以上の第２のプロトコルパケット３０４ａ乃至３０４ｎを第１のプロトコルパケット３１６のデータペイロード３２４内にカプセル化する。別の実施態様において、１つの第２のプロトコルパケット３０４ａだけが、各第１のプロトコルパケット３１６内にカプセル化される。
【００６３】
一実施態様において、第１のプロトコルパケット３１６は、次いで接続１３５、例えば図２Ａを参照して説明される接続２０８を通じて、クライアント１０８のクライアントエージェント１２８に伝送される。あるいは、別の実施態様では、第１のプロトコルサービス１１２は、いずれの第１のプロトコルパケット３１６の伝送の前に、第１のプロトコル２０４のレベルでの通信を暗号化するようにさらに構成される。このような一実施態様において、第１のプロトコルパケット３１６は、例えば、図２Ｂを参照して説明されるＳＳＬプロトコルを使用して暗号化される。その結果、ヘッダ３３２と、データペイロード３３６としての暗号化された第１のプロトコルパケット３１６’を含むセキュアなパケット３２８が生成される。セキュアなパケット３２８は、次いで接続１３５、例えば図２Ｂを参照して説明されるセキュアなＴＣＰ／ＩＰ接続２１２を通じて、クライアント１０８のクライアントエージェント１２８に伝送される。
【００６４】
別の実施態様において、第１のプロトコルサービス１１２は、任意の第１のプロトコルパケット３１６の伝送の前に、第１のプロトコル２０４のレベルでの通信を暗号化するようにさらに構成される。一実施態様において、第１のプロトコルサービス１１２は、第１のプロトコルパケット３１６を暗号化する前に、標準的な圧縮技術を使用して第１のプロトコルパケット３１６を圧縮する。このように、システム１００の効率が改善される。
【００６５】
図１Ａおよび図１Ｂを再び参照すると、本発明のシステム１００は、一実施態様において、例えばホストサービス１１６ａのようなホストサービス１１６への持続的な接続を有するリモートクライアント１０８を提供する。例えば、クライアント１０８がクライアント１０８と第１のプロトコルサービス１１２との間の接続１３５を確立し、第１のプロトコルサービス１１２が第１のプロトコルサービス１１２とホストサービス１１６ａとの間の接続１２４ａを確立する場合は、次いでクライアントエージェント１２８または第１のプロトコルサービス１１２のいずれか、またはその両方が、接続１３５を介して直近に伝送された第１のプロトコルデータパケットのキューを維持するように構成される。例えば、キューに入れたデータパケットは、接続１３５の前でも失敗時でもクライアントエージェント１２８および／または第１のプロトコルサービス１１２によって維持されることができる。さらに、接続１３５の失敗時には、第１のプロトコルサービス１１２、および同様にホストサービス１１６ａは、接続１２４ａを維持するように構成される。
【００６６】
接続１３５の失敗を受けて、クライアント１０８は、いずれのデータも失わずに第１のプロトコルサービス１１２による新しい接続１３５を確立する。より具体的には、接続１３５の失敗時に接続１２４ａが維持されるので、新しく確立された接続１３５は、維持された接続１２４ａにリンクされることができる。さらに、直近に伝送された第１のプロトコルデータパケットがキューに入っているので、クライアント１０８によってそれらを第１のプロトコルサービス１１２に再び伝送することができ、および／または第１のプロトコルサービス１１２によって新しく確立された接続１３５を通じてクライアント１０８に再び伝送することができる。このように、ホストサービス１１６ａとクライアント１０８との間の通信セッションは、第１のプロトコルサービス１１２を介して、いずれのデータも失われずに持続的に進められる。
【００６７】
一実施態様において、クライアント１０８のクライアントエージェント１２８および／または第１のプロトコルサービス１１２は、それらが接続１３５を通じて伝送するデータパケットに番号を付ける。例えば、クライアントエージェント１２８および第１のプロトコルサービス１１２それぞれに、他のものがそのデータパケットにどのように番号を付けたかに関係なく、それ自身の伝送データパケットに別々に番号を付ける。さらに、データパケットの番号付けは、データパケットの番号を付け直さずに絶対的なものとすることができる。すなわち、クライアントエージェント１２８および／または第１のプロトコルサービス１１２により伝送された最初のデータパケットには、番号１を付けることができ、接続１３５を通じてクライアントエージェント１２８および／または第１のプロトコルサービス１１２により伝送された各データパケットには、その後にそれぞれ連続した番号が付けられる。
【００６８】
このような一実施態様において、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、接続１３５の中断および再確立を受けて、一方にそれが要求する次のデータパケットを通知する。例えば、クライアントエージェント１２８が、接続１３５の中断の前に番号１乃至１０のデータパケットを受信した場合、接続１３５の再確立時に、クライアントエージェント１２８は第１のプロトコルサービス１１２に現在データパケット番号１１を要求していることを通知する。同様に、第１のプロトコルサービス１１２も、このように機能することができる。あるいは、別のこのような実施態様において、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、受信した最後のパケットデータを一方に通知する。例えば、クライアントエージェント１２８が、接続１３５の中断の前に番号１乃至１０のデータパケットを受信した場合、接続１３５の再確立時に、クライアントエージェント１２８は第１のプロトコルサービス１１２に最後に受信したデータパケット番号１０を通知する。第１のプロトコルサービス１１２も同様に機能することができる。さらに別の実施態様において、クライアントエージェント１２８および／または第１のプロトコルサービスは１１２、接続１３５の再確立時に、受信した最後のデータパケットおよび要求する次のデータパケットの両方を一方に通知する。
【００６９】
このような実施態様において、接続１３５の再確立時に、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、他のものが受信していないバッファリングされたデータパケットを再伝送することができ、第１のプロトコルサービス１１２を介して、ホストサービス１１６とクライアント１０８との間の通信セッションをいかなるデータも失わずに進めることができる。さらに、接続１３５の再確立時に、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、現在一方が受信したことがわかっているバッファリングされたデータパケットをそれぞれのバッファから消去することができる。
【００７０】
概して、持続的な接続のためのバッファリングデータは単独の第１のプロトコルサービス１１２の観点で議論されるが、上述のデータバッファリングおよび再接続も、同様の方式で、複数の第１のプロトコルサービス１１２を横断するクライアントのホストサービス１１６との通信セッションに適用する。１つ以上の追加の第１のプロトコルサービス１１２は、クライアント１０８とホストサービス１１６との間のデータトラフィックの一部または全部をバッファリングする場合がある。別の実施態様において、クライアントとホストサービス１１６間の「ホップ」の１つを管理する第１のプロトコルサービス１１２は、当該「ホップ」と送受信されるデータをバッファリングする場合がある。このように、１つ以上の第１のプロトコルサービス１１２は、クライアント１０８とホストサービス１１６の間の中断した接続の確立時に、データパケットを再伝送するために使用される場合がある。
【００７１】
クライアント１０８にホストサービス１１６ａ乃至１１６ｎとの信頼できる持続的な接続を提供することにより、本発明は、ネットワーク接続中断を通じてユーザーセッションを維持することでホストサービス１１６ａ乃至１１６ｎとの新しいユーザーセッションを開くプロセスを回避する。ホストサービス１１６ａ乃至１１６ｎとの各ユーザーセッションのため、クライアント１０８およびホストサービス１１６ａ乃至１１６は、セッション固有のコンテキストおよびキャッシュ、ならびに本例のユーザーセッションに関連するその他のアプリケーション固有のメカニズムを維持する場合がある。確立した新しい各ユーザーセッションのために、これらのセッション固有のコンテキストおよびキャッシュを、新しいユーザーセッションを反映するため再配置および再確立する必要がある。例えば、クライアント１０８上のユーザーはホストサービス１１６ａ乃至１１６ｎとのｈｔｔｐセッションを有する場合がある。ホストサービス１１６ａ乃至１１６ｎは、本例のクライアント１０８とのｈｔｔｐセッションを提供するためのコンテキストを維持することができる。コンテキストはサーバのメモリ内、サーバのファイル内、データベースまたはホストサービス１１６ａ乃至１１６ｎの機能性の提供に関連するその他のコンポーネントに格納される。また、クライアント１０８は、ホストサービス１１６ａ乃至１１６ｎに対する未処理の要求のトラックを維持するためのメカニズム等、ｈｔｔｐセッションの例に特有のローカルコンテキストを有する場合がある。このコンテキストは、クライアント１０８のメモリ内、クライアント１０８のファイル内、またはクライアント１０８と適合するその他のソフトウェアコンポーネントに格納される場合がある。クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間の接続が持続的でない場合、ホストサービス１１６ａ乃至１１６ｎおよびクライアント１０８の新しいセッション特有コンテキストによって新しいユーザーセッションを確立する必要がある。本発明は、新しいセッション、また従って新しい特有のセッションコンテキストが再確立される必要のないよう、セッションを維持する。
【００７２】
本発明は、ネットワークレベル接続中断を通じて、クライアントのユーザーにセッションが中断されたことを通知することなく、ユーザーセッションを維持する。本発明の本局面の動作において、第１のプロトコルサービス１１２は、クライアント１０８との第１の接続およびホストサービス１１６ａ乃至１１６ｎとの第２の接続を確立および維持する。第１の接続および第２の接続を経由して、クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間のセッションは確立される。第１のプロトコルサービス１１２は、認証証明書のような任意のセッション関連情報ならびに確立されたセッションのためのクライアント１０８およびホストサービス１１６ａ乃至１１６ｎのコンテキストを格納および維持することができる。クライアント１０８上のユーザーは、確立されたセッションを通じて、ホストサービス１１６ａ乃至１１６ｎによって提供される機能性を行使するであろう。このように、関連する第２のプロトコルパケット３０４ａ乃至３０４ｎは、そのような機能性のトランザクションに関連するデータを含むであろう。これらの第２のプロトコルパケット３０４ａ乃至３０４ｎは、第２のプロトコル２００ａ乃至２００ｎの一部として、第１のプロトコル２０４内でカプセル化され、通信が行われる。第１の接続または第２の接続いずれかにおける中断検出時、第１のプロトコルサービス１１２は、中断されていないと思われるその他の接続を維持しながら、中断された接続を再確立することができる。ネットワーク接続中断は、クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間のセッションを中断する場合がある。しかしながら、トランスポートメカニズムは第２のプロトコル２００ａ乃至２００ｎによって維持されていないため、クライアント１０８上のユーザーにセッションが中断されたという通知を与えることなく、ネットワーク接続が再確立された後にセッションを再確立することができる。第２のプロトコル２００ａ乃至２００ｎは、クライアント１０８に伝送するための情報に関連するいかなる中断も含む必要がない。従って、ネットワーク接続中断によって生じるセッションの中断は、第１のプロトコル２０４のカプセル化によって、効果的にユーザーから隠される。
【００７３】
セッション関連情報を維持する第１のプロトコルサービス１１２は、クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間のセッションを再確立することができる。例えば、クライアント１０８と第１のプロトコルサービス１１６の間のセッションが中断した場合、第１のプロトコル１１２はクライアントの１０８セッションを第１のプロトコルサービス１１２とホストサービス１１６ａ乃至１１６ｂの間でアクティブまたはオープンに保つことができる。第１の接続が再確立した後、第１のプロトコルサービス１１２はクライアント１０８のセッションを第１のプロトコルサービス１１２とホストサービス１１６の間で維持されているセッションとリンクされることができる。第１のプロトコルサービス１１２は、クライアント１０８に第１の接続における中断の前にキューに入っていた任意のデータを送信することができる。このように、クライアント１０８は中断前と同じセッションを使用しているだろうし、ホストサービス１１６ａ乃至１１６ｎおよびクライアント１０８はメモリ内またはほかの場所に格納されていると思われる任意のセッション固有コンテキストの使用を継続できる。さらに、第１のプロトコルサービス１１２の仲介により、ホストサービス１１６ａ乃至１１６ｎは、第１のプロトコルサービス１１２とクライアント１０８の間のネットワーク中断に気づかない場合がある。
【００７４】
別の実施態様において、第１のプロトコルサービス１１２のホストサービス１１６ａ乃至１１６ｎの間の第２の接続が中断した場合、第１のプロトコルサービスは、ホストサービス１１６ａ乃至１１６ｎとの第２の接続を再確立しながら、クライアント１０８との第１の接続を維持することができる。第２の接続を再確立した後、第１のプロトコルサービス１１２は、クライアントを代表し、ホストサービス１１６ａ乃至１１６ｎとのクライアントセッションを再確立することができる。第１のプロトコルサービス１１２が任意のセッション関連情報を維持していたため、第１のプロトコルサービスは、クライアント１０８が、第２の接続における中断およびその結果生じた第１のプロトコルサービス１１２とホストサービス１１６ａ乃至１１６ｎの間のセッションへの中断に気づかないよう、同じセッションまたは同様のセッションを再確立することができる。第２のネットワーク接続およびセッションを再確立する間、第１のプロトコルサービス１１２は、クライアント１０８から中断中に送信されてきた任意のセッショントランザクションをキューに入れることができる。次いで、ホストサービス１１６ａ乃至１１６ｎとのセッションを再確立後、第１のプロトコルサービス１１２はそのキューに入れたトランザクションをホストサービス１１６ａ乃至１１６ｎへ伝送することができ、セッションは正常に継続できる。このような方法で、クライアント１０８はあたかもセッションの中断などなかったかのように動作を継続する。
【００７５】
また、信頼できる持続的な接続を提供することにより、本発明は、クライアント１０８とホストノード１１８またはホストサービス１１６ａ乃至１１６ｎの間で行使される機能性の一部として、トランザクション、コマンドまたは動作への中断を回避することもできる。例えば、Ｗｉｎｄｏｗｓ（登録商標） Ｅｘｐｌｏｒｅｒを使用するファイルコピー動作は、ネットワーク接続において中断があった後も動作継続するように設計されていない。クライアント１０８上のユーザーは、クライアント１０８のファイルをホストノード１１８へコピーするために、Ｗｉｎｄｏｗｓ（登録商標） Ｅｘｐｌｏｒｅｒのファイルコピー機能を使用することができる。ファイルのサイズにより、この動作が完了するまでには比較的長い時間がかかる。ホストノード１１８へのファイルコピー動作の途中にクライアント１０８とホストノード１１８の間のネットワーク接続に中断があった場合、ファイルコピーは失敗するであろう。クライアント１０８のファイルをホストノード１１８へコピーするため、ネットワーク接続が再確立されてすぐに、ユーザーはもう一度Ｗｉｎｄｏｗｓ（登録商標） Ｅｘｐｌｏｒｅｒのファイルコピー動作を開始する必要がある。本発明の下では、ユーザーはもう一度ファイルコピー動作を開始する必要がないであろう。ネットワーク接続は第１のプロトコル２０４接続の一部として再確立されるであろう。ファイルコピー動作は第２のプロトコル２００ａ乃至２００ｎのペイロードにおいてカプセル化されるであろう。このように、Ｗｉｎｄｏｗｓ（登録商標） Ｅｘｐｌｏｒｅｒのファイルコピーは、ネットワーク接続における中断の通知を受けることなく、従って失敗することがないであろう。第１のプロトコルサービス１１２は、動作が失敗なく継続できるよう、任意の接続を再確立し、キューに入れた任意のデータを伝送する。第１のプロトコル１１２は、ネットワーク接続の中断によりホストノード１１８に転送されなかったファイルコピー動作に関連するデータのキューを維持するであろう。ネットワーク接続が再確立されるとすぐに、第１のプロトコルサービス１１２はキューに入れたデータを伝送し、やがてファイルコピー操作に関連するデータの転送を継続することができる。
【００７６】
本発明の本局面は、ファイルコピー動作例の観点で説明されているが、通常当業者には、クライアント１０８とホストノード１１８またはホストサービス１１６ａ乃至１１６ｎ間でやりとりされるいかなる操作、トランザクション、コマンド、ファンクションコール等も、ネットワーク接続中断による失敗なく、またさらに、クライアント１０８が、中断があったことを認識したり中断の通知を受けたりすることなく、維持および継続できることが認識されるであろう。
【００７７】
さらに、信頼できる持続的な接続を提供することにより、本発明は、クライアント１０８に、クライアント１０８上でセッションまたはアプリケーションを再開することなく、異なるネットワークトポロジーを通じて横断させることもできる。例えば、クライアント１０８は無線ネットワーク接続を持つノート型パソコンであってよい。クライアント１０８が第１の無線ネットワークから第２の無線ネットワークへ移動する場合、クライアントのネットワーク接続１３５は、第２の無線ネットワークによってネットワーク接続が確立される際に第１の無線ネットワークから一時的に中断される場合がある。第２の無線ネットワークは、クライアント１０８に、ホスト名またはインターネットプロトコルアドレスのような新しいネットワーク識別子を割り当ててよい。この新しいネットワーク識別子は、第１の無線ネットワークによってクライアント１０８の割り当てられたネットワーク識別子と異なる場合がある。別の実施態様において、クライアント１０８は、イーサネット（登録商標）ケーブルを介してネットワーク上のポートに物理的に接続される場合がある。物理的な接続はプラグを抜かれる場合があり、クライアント１０８はネットワーク上の異なるポートに接続するため別の場所に移動する場合がある。これは、ネットワーク接続１３５への中断および割り当てられたネットワーク識別子における潜在的な変化を引き起こすであろう。本発明がなければ、クライアント１０８におけるホストサービス１１６ａ乃至１１６ｎとのいかなるセッションまたはネットワークにアクセスするクライアント１０８上のアプリケーションも、ネットワークトポロジーの変化、ネットワーク接続１３５への中断、および／または割り当てられたネットワーク識別子の変化によって再開される必要があるかもしれない。本願明細書に記載の方法およびシステムによって、本発明はクライアントのためのネットワーク接続ならびに、ネットワークトポロジーおよびネットワーク識別子における変化の処理も含む自動的に再確立されたクライアント１０８のネットワーク接続を維持する。クライアント１０８またはクライアント１０８上の任意のアプリケーションまたはセッションは、あたかもネットワーク接続中断もネットワーク識別子における変化もなかったかのように動作を継続することができる。さらに、クライアント１０８上のユーザーは、いかなる中断や変化があったことも認識しない場合があり、クライアント１０８はそのような中断のいかなる通知も受信しない場合がある。
【００７８】
別の局面において、本発明は、クライアント１０８とホストサービス１１６の間の通信セッションを、プロキシ、セキュリティゲートウェイ、ファイアウォール、またはルータ等、複数のネットワークコンポーネントを横断する複数の接続または「ホップ」を経由して確実に確立することに関する。複数ホップのセキュアな通信セッションの確立はさらに、セキュアなクライアント‐ウェブサーバ間通信チャネル１４０を経由して、例えばウェブブラウザ１６２とウェブサーバ１２０の間でＳＳＬを使用して開始される場合がある。チケットオーソリティ１３６は、クライアント‐第１のプロトコルサービス間接続１３５および第１のプロトコルサービスとホストサービスの接続１２４ａ乃至１２４ｎ等、各ホップにチケットを提供することができる。このように、クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間の接続をすべて経由して、クライアント１０８は認証される。
【００７９】
動作においては、図４も参照すると、クライアントユーザーは、クライアント１０８（すなわち、ＩＣＡクライアント１２８）上に遠隔で表示されるコンテンツ（例えば、アプリケーション、サーバデスクトップ）を要求する（ステップ４００）。別の実施態様において、クライアント１０８はウェブブラウザ１６２を使用してアプリケーションを要求し、次いでウェブサーバ１２０がユーザーを認証する。要求を受信後、ウェブサーバ１２０はチケットオーソリティ１３６によってその要求を有効にする（ステップ４０５）。次いでチケットオーソリティ１３６が、第１のチケットまたはクライアントチケット、および第２のチケットまたは第１のプロトコルサービスチケットを含むチケットを生成する（ステップ４１０）。第１および第２のチケットは、１度使用した後は価値のなくなる「１回限り」のチケットである。さらなる実施態様において、第１および第２のチケットは所定の期間内に使用しなければならない。
【００８０】
一実施態様において、チケットオーソリティ１３６は、第１および第２のチケットをそのチケットが使用されるまでメモリ（例えば、ＲＡＭ）内に格納する。あるいは、チケットオーソリティ１３６は、第１および第２のチケットをそのチケットが使用されるまで記憶装置（図示なし）内に格納する。記憶装置は、例えばデータベースまたは持続的メモリ（例えば、フロッピー（登録商標）ディスクまたはハードディスクドライブ上の）を含んでよい。チケットオーソリティ１３６は、その後クライアントチケットをウェブサーバ１２０へ伝送し（ステップ４１５）、次いでウェブサーバ１２０はそのクライアントチケットをクライアント１０８へ転送する（ステップ４２０）。
【００８１】
その後クライアント１０８は、プロキシ接続要求をクライアント‐第１のプロトコルサービス間通信チャネル１３５上に伝送することにより、第１のプロトコルサービス１１２との通信セッションを開始する（ステップ４２５）。プロキシ接続要求は、クライアントチケットを含む。一実施態様において、プロキシ接続要求は、ホストノード１１８との通信セッション確立時に第１のプロトコルサービス１１２に置き換え可能なダミーパスワードも含む。さらなる実施態様において、ウェブサーバ１２０は、第１のプロトコルサービス１１２にアクセス可能なフォーマットを有するプロキシ接続要求を未来に生成するため、ダミーパスワードをクライアント１０８に伝送する。第１のプロトコルサービス１１２はその後、プロキシ接続要求からクライアントチケットを開放し（ステップ４３０）、そのクライアントチケットを有効化するためチケットオーソリティ１３６へ転送する。チケットオーソリティ１３６はその後第１のチケットを有効にする（ステップ４３５）。一実施態様において、チケットオーソリティ１３６は、第１の予期されるチケットを求めてその記憶装置（例えば、データベース）を検索することにより、第１のチケットを検証する。
【００８２】
チケットオーソリティ１３６が記憶装置の中で第１のチケットを発見しない場合（例えば第１のチケットが既に使用されていた場合など）、チケットオーソリティ１３６は通信セッションを終了する。受信したチケットがチケットオーソリティ１３６の予期しているチケットと一致する場合、そのクライアントチケットは有効にされる。チケットオーソリティ１３６はその後、第２のまたは第１のプロトコルサービスチケットを第１のプロトコルサービス１１２へ伝送する（ステップ４４０）。また、クライアントチケットが１度使用されると、チケットオーソリティ１３６はそのクライアントチケットを記憶装置から削除する。別の実施態様において、チケットオーソリティ１３６は、ホストノード１１８のインターネットプロトコル（ＩＰ）アドレスも第１のプロトコルサービス１１２へ伝送する。さらに別の実施態様において、チケットオーソリティ１３６は、その後ＩＰアドレスに変換するため、ホストノード１１８のドメイン名を第１のプロトコルサービス１１２へ伝送する。
【００８３】
第１のプロトコルサービス１１２は、第２のチケットまたは第１のプロトコルサービスチケットを受信し、その後、第２のチケットをホストノード１１８へ伝送（ステップ１４５）することにより、プロキシ‐サーバ間通信チャネル１４５を通して通信を始める。ホストノード１１８は、第１のプロトコルサービスチケットを受信し、その後そのチケットを有効にするためチケット‐サーバ間通信チャネル１５７上でチケットオーソリティ１３６に伝送する（ステップ４４７）。一実施態様において、チケットオーソリティ１３６が、ホストノード１１８から受信した第１のプロトコルサービスが以前に使用されたことがあり、正当な価値（すなわち、関連する記憶装置内に格納されているのと同じ価値）がないと判断した場合、チケットオーソリティ１３６は、クライアント１０８との確立した通信セッションを終了させるため、第１のプロトコルサービス１１２（またはウェブサーバ１２０）にエラーメッセージを伝送する。チケットオーソリティ１３６が第１のプロトコルチケットを有効にする（ステップ４４８）と、ホストノード１１８はＩＣＡ公開アプリケーションを起動する（ステップ４５０）。ホストノード１１８は次いでアプリケーション情報を、クライアント１０８におけるアプリケーションの遠隔表示（ステップ４５５）のため、ＩＣＡクライアント１２８を使用して第１のプロトコルサービス１１２へ伝送する（ステップ４５３）。
【００８４】
さらなる実施態様において、クライアント１０８は、ステップ４２５における第１のプロトコルサービス１１２との通信開始時にＩＣＡクライアント１２８を起動する。その他の実施態様において、クライアント１０８は、クライアント１０８がステップ４５３において第１のプロトコルサービス１１２からアプリケーション情報を受信した際にＩＣＡクライアント１２８を起動する。
【００８５】
従って、クライアント１０８は、クライアントチケット以外、第１のプロトコルサービスチケットには気づかない。さらに、ＩＣＡクライアント１２８は、第１のプロトコルサービス１１２と通信を行い、クライアントチケットを提示することなしにはホストノード１１８にアクセスできない。.
チケットオーソリティ１３６は、第１のプロトコルサービスチケットを、クライアント１０８のユーザーのためのユーザーパスワードとして、ステップ４４０において第１のプロトコルサービス１１２に伝送する可能性もある。これは、第１のプロトコルサービス１１２が、第１のプロトコルサービスチケットを、ユーザーのログインパスワードをウェブの信用できない部分（すなわち、ステップ４２５中のセキュアでないクライアント‐プロトコルサービス間通信チャネル１３５）上にさらすことなくホストノード１１８にアクセスするためのログインパスワードとして使用できるようにする。従って、一実施態様において、通信システム１００は、チケットオーソリティ１３６により管理され、ユーザーのパスワードで第１のプロトコルサービスチケットをマップするためにホストノード１１８と同一場所に配置される、集中パスワードマッピングデータベースを含む可能性がある。
【００８６】
従って、パスワードは両方のチケット（すなわち、第１のプロトコルサービスチケットおよびクライアントチケット）を伴うことができるか、またはパスワードは２つのチケットのうち１つを伴うことができる。上述のように、パスワードが２つのチケットのうち１つ、例えばクライアントチケットを伴っていれば、第１のプロトコルサービスチケットがパスワードである。一実施態様において、パスワードは、価値が変わらないシステムパスワード、または、ＲＳＡ Ｓｅｃｕｒｉｔｙ社（Ｂｅｄｆｏｒｄ、 Ｍａｓｓａｃｈｕｓｅｔｔｓ）製のセキュアＩＤトークンによって生成されたパスワード等の、１回限りのパスワードであってよい。
【００８７】
また、本発明は、ホストノード１１８との通信セッションを確立する前にクライアント１０８が通信を行わなければならない第１のプロトコルサービス１１２または「ホップ」をいくつでも有する通信システムまで拡張することができる。第１のプロトコルサービス１１２に関連して説明したが、ホップは、プロキシ１１５、ファイアウォール、ルータ、リレー等、任意のネットワークコンポーネントを備えることができる。
【００８８】
例えば、また図５Ａを参照して、４つのホップの例は、プロキシ１１５’を持つ第１のプロトコルサービス１１２’、プロキシ１１５’’を持つ２番目の第１のプロトコルサービス１１２’’、およびプロキシ１１５’’’（概して１１５）を持つ３番目の第１のプロトコルサービス１１２’’’を有する通信システム５０５である。プロキシ１１５を持つ第１のプロトコルサービス１１２は、第１のプロキシ‐プロキシ間通信チャネル５１０’および第２のプロキシ‐プロキシ間通信チャネル５１０’’（概してプロキシ‐プロキシ間通信チャネル５１０）のようなプロキシ‐プロキシ間通信チャネル上で通信を行う。クライアント１０８は、２番目の第１のプロトコルサービス１１２’’と通信を行う第１のプロトコルサービス１１２’と通信を行う。同様に、２番目の第１のプロトコルサービス１１２’’は３番目の第１のプロトコルサービス１１２’’’と通信を行い、次いで３番目の第１のプロトコルサービス１１２’’’は、ホストノード１１８との通信セッションを確立するため、プロキシ‐サーバ間通信チャネル１４５上でホストノード１１８と通信を行う。さらに、上述の実施態様はクライアントチケットおよび第１のプロトコルチケットを有するチケットを含むが、別の実施態様は、多数のチケットを備えるチケットを含む。
【００８９】
さらに明確に、また図５Ｂも参照すると、ウェブサーバ１２０はクライアント１０８からアプリケーションの要求を受信し、ウェブサーバ１２０はその要求をチケットオーソリティ１３６で有効にする（ステップ４０５）。チケットオーソリティ１３６は、次いでステップ４１０においてＮ部のチケット（例えばＴ１乃至ＴＮ）を生成する。一実施態様において、チケットオーソリティ１３６はその後Ｎ部のチケットの一部Ｔｉ（例えば、チケットの第１部、または第１のチケットＴ１）をウェブサーバ１２０へ伝送する（ステップ４１５）。ウェブサーバ１２０はその後チケットＴ１をクライアント１０８に伝送する（ステップ４２０）。一実施態様において、チケットオーソリティ１３６は次の「ホップ」（例えば、第１のプロトコルサービス１１２’）のアドレスをウェブサーバ１２０へ伝送し、ウェブサーバ１２０はその後そのアドレスをクライアント１０８へ伝送する。このアドレスは、クライアント１０８が最終的にホストノード１１８に対して認証されるために、現在のホップ（例えば、クライアント１０８）が通信を行う必要がある次のホップ（例えば、第１のプロトコルサービス１１２）のアドレスである。
【００９０】
クライアント１０８は、次の「ホップ」（例えば、第１のプロトコルサービス１１２’）と接触するためのアドレスを使用し、プロキシ接続要求をクライアント‐第１のプロトコルサービス間チャネル１３５上に伝送することにより、１番目の第１の通信セッション１１２’との通信セッションを開始する。第１のプロトコルサービス１１２’’は、次いで第１のチケットＴ１をプロキシ接続要求から抽出し（ステップ５３０）、このチケットを有効にするためチケットオーソリティ１３６へ転送する。チケットオーソリティ１３６はその後、第１のチケットＴ１を有効にする（ステップ５３５）。
【００９１】
第１のチケットＴ１の適切な有効化時、チケットオーソリティ１３６は次のチケットＴｉをＮ部のチケット（例えば、Ｔ２）から次の第１のプロトコルｓサービス１１２（例えば、第１のプロトコルサービス１１２’）へ伝送する（ステップ５４０）。一部の実施態様において、チケットオーソリティ１３６は、次のホップ（例えば、２番目の第１のプロトコルサービス１１２’’）のアドレスも現在のホップ（例えば第１のプロトコルサービス１１２’）へ伝送する。第１のプロトコルサービス１１２’は、このチケットを次のホップ（例えば、２番目の第１のプロトコルサービス１１２’’）へ伝送する（ステップ５４５）。一実施態様において、２番目の第１のプロトコルサービス１１２’’は、このチケットをチケットオーソリティ１３６へ伝送することによりＴ２を検証する（ステップ５５０）。チケットオーソリティ１３６は第２のチケットＴを有効にし（ステップ５５５）、ステップ５６０から５７５に示されるようなプロセスが続く。Ｎ部のチケットの最後の部分が有効になると、図４に示すように、クライアント１０８上のアプリケーションを起動するために、ステップ４５０から４５５が発生する。
【００９２】
一実施態様において、各第１のプロトコルサービス１１２（すなわち、各ホップ）はＴｉ（例えば、Ｔ２）を第１のプロトコルサービス１１２（すなわち、ホップ）に関連するチケットオーソリティ１３６によって有効にする。この実施態様において、各第１のプロトコルサービス１１２がチケットＴｉ（例えば、Ｔ２）をチケットオーソリティ１３６によって有効にした後、有効化が行われるチケットオーソリティ１３６は、次のチケットＴｉ＋１（例えば、Ｔ３）および次の第１のプロトコルサービス１１２（すなわち、次の「ホップ」あて先）を、チケットＴｉを有効にした第１のプロトコルサービス１１２に伝送する。従って、各第１のプロトコルサービス１１２は、現在および次のホップチケットが組み込まれた（すなわち、Ｔｉを有効にしＴｉ＋１を伝送している）チケットオーソリティ１３６に関連している。その結果、次の第１のプロトコルサービス１１２は、当該ホップのためのクライアントとして作用する。このプロセスは、通信システム５０５においてホストノード１１８に届くまで繰り返される。従って、各ホップは、いずれのホップに対してもすべてのチケットをさらけ出すことなく、個別に有効にされる。
【００９３】
一実施態様において、チケットオーソリティ１３６は、多くの部分を持つ１つのチケットを発行するのではなく１つを超えるチケットを発行する。例えば、チケットオーソリティ１３６は、第１のホップチケットが第２のホップチケットと関連を持たないステップ５１０において、第１のホップチケットおよび第２のホップチケットを生成する。チケットオーソリティ１３６はその後、第１のホップチケットをウェブサーバ１２０へ伝送し、ウェブサーバ１２０は第１のホップチケットをクライアント１０８へ伝送する。クライアント１０８は、チケットオーソリティ１３６によってこの第１のホップチケットを有効にするため第１のプロトコルサービス１１２（例えば、第１のプロトコルサービス１１２’）へ伝送する。ステップ５３５における有効化時、チケットオーソリティ１３６は、第１のホップチケットが第２のホップチケットから独立している間に、ステップ５４０において第２のホップチケットを次の第１のプロトコルサービス１１２（例えば、２番目の第１のプロトコルサービス１１２’’）へ伝送する。
【００９４】
さらなる実施態様において、１つ以上のチケットオーソリティ１３６は、第１のプロトコルサービス１１２の一部として、または第１のプロトコルサービス１１２とは別で、ＳＯＣＫＳサーバ（例えば、ＮＥＣ社（東京、日本）製のＳＯＣＫＳ５サーバ）に接続するための暗号キー、ＳＳＬ方法設定情報、および認証情報等であるがこれらに限定されない、次のホップに接続するために必要な任意の必要情報とともに、プロキシ１１５を提供する。
【００９５】
さらに別の実施態様において、チケットオーソリティ１３６は単一のチケットのみを生成する。チケットオーソリティ１３６は単一のチケットをウェブサーバ１２０へ伝送する。ウェブサーバ１２０は単一のチケットをクライアント１０８へ転送する。第１のプロトコルサービス１１２はその後そのチケットをクライアント１０８から受信し、有効化時にその単一のチケットを「消費」する。結果として、通信システム１００は単一のチケットを、クライアント‐プロキシ間通信チャネル１３５およびクライアント‐ウェブサーバ間通信チャネル１４０上で任意の通信プロトコルを使用する能力を提供するために使用する。また、ホストノード１１８は単一のチケットを受信も検証もしないため、チケットはホストノード１１８に対して透過的であり、その結果、ホストノード１１８はチケットの使用に「気づく」ことがない。
【００９６】
セキュアなクライアント‐ウェブサーバ通信チャネル１４０上のクライアント１０８とウェブサーバ１２０の間のセキュアな通信のセキュリティを利用することにより、通信システム５０５はセキュアでないクライアント‐プロキシ通信チャネル１３５上に、クライアント１０８にデスクトップアプリケーションをセキュアに遠隔表示するためのセキュアな通信リンクを確立する。
【００９７】
さらに別の実施態様において、また図４を再度参照して、チケットオーソリティ１３６はステップ４１５において第１のプロトコルサービスの使用不可能なバージョンを、クライアント１０８への伝送のため、クライアントチケットとともにウェブサーバ１２０へ伝送する。クライアント１０８はその後第１のプロトコルサービスチケットを、プロキシ接続要求の一部として、クライアントチケットとともに第１のプロトコルサービス１１２へ伝送する（ステップ４２５）。第１のプロトコルサービス１１２は、次いで両方のチケットをチケットオーソリティ１３６へ転送する。使用不可能な第１のプロトコルサービスチケットを受信すると、チケットオーソリティ１３６はクライアントチケットを有効にした後、第１のプロトコルサービスチケットを使用可能にする。チケットオーソリティ１３６は次いで使用可能な第１のプロトコルサービスチケットを、ホストノード１１８に対する認証のために第１のプロトコルサービス１１２へ伝送する。
【００９８】
あるいは、別の実施態様において、ウェブサーバ１２０は使用不可能な第１のプロトコルサービスチケットおよび使用可能なクライアントチケットをチケットオーソリティ１３６から受信し、クライアントチケットのクライアント１０８への伝送のみ行う。クライアント１０８は、そのクライアントチケットをプロキシ接続要求の一部として第１のプロトコルサービス１１２へ伝送する（ステップ４２５）。第１のプロトコルサービス１１２は次いでクライアントチケットをチケットオーソリティ１３６へ転送する。チケットオーソリティ１３６はクライアントチケットを有効にし、有効化時に、以前ウェブサーバ１２０へ伝送された第１のプロトコルサービスチケットを使用可能にする。さらに別の実施態様において、チケットオーソリティ１３６は、使用可能な第１のプロトコルサービスチケットを、ホストノード１１８に対する認証のためのクライアントチケット有効化時に、ウェブサーバ１２０へ伝送する。
【００９９】
従って、常に、チケットオーソリティ１３６は、チケットオーソリティ１３６が有効にできる、クライアント１０８または第１のプロトコルサービス１１２に対して使用可能な１つのチケットのみを提供する。チケットオーソリティ１３６は、使用可能なチケットが有効になるまで、有効にできない別のチケット（例えば、使用不可能なチケット）を提供する。あるいは、チケットオーソリティ１３６は、チケットオーソリティ１３６が使用可能なチケットを有効にするまで、第１のプロトコルサービスチケットを第１のプロトコルサービス１１２へ伝送しない場合がある。以下でさらに詳しく説明するように、クライアント１０８は、チケットオーソリティ１３６に使用可能なチケットを有効にさせ、ホストノード１１８と通信を行うために必要なチケットを伝送させることなくウェブサーバ１２０または第１のプロトコルサービス１１２を横断することができないため、これは、通信システム５０５を使用して通信のネットワークルーティングを強制する。
【０１００】
別の実施態様において、ステップ４４０のように第１のプロトコルサービスチケットを第１のプロトコルサービス１１２へ伝送する代わりに、チケットオーソリティ１３６はウェブサーバ‐オーソリティ間通信チャネル２５０上で第１のプロトコルサービスチケットを直接ウェブサーバ１２０へ伝送する。ウェブサーバ１２０はその後自動的に第１のプロトコルサービスチケットをホストノード１１８へ伝送する。すなわち、ウェブサーバ１２０は第１のプロトコルサービスチケットをホストノード１１８へ「プッシュ」する。チケットオーソリティ１３６は、第１のプロトコルサービスチケットを第１のプロトコルサービス１１２へもウェブサーバ１２０へも伝送せずに、第１のプロトコルサービスチケットをホストノード１１８へプッシュすることもできる。
【０１０１】
さらに別の実施態様において、ホストノード１１８は、チケット‐コンテンツサーバ間通信チャネル１５７上で、チケットオーソリティ１３６から第１のプロトコルサービスチケットを回収する。すなわち、ホストノード１１８はチケットオーソリティ１３６から第１のプロトコルサービスチケットを「プル」する。上記の例は、ステップ３４５を（ステップ４４０における伝送あて先を変更しながら）排除するための技術の説明である。
【０１０２】
さらに、本発明は、第１のプロトコルサービス１１２を通じてクライアント１０８のルーティングを強制する。上述のように、クライアント１０８は、ホストノード１１８との通信セッションを確立するため、第１のプロトコルサービスチケットを所有しなければならない。より具体的には、ホストノード１１８との通信セッションを確立するために、ウェブサーバ１２０はまずチケットオーソリティ１３６でクライアント１０８の要求を有効にしなければならない。有効化されると、クライアント１０８は第１のチケットを得てこの第１のチケットを有効化のためチケットオーソリティ１３６へ伝送する。しかしながら、有効化時に、チケットオーソリティ１３６は、第１のプロトコルサービスチケットをクライアント１０８ではなく第１のプロトコルサービス１１２へ送り返す。クライアント１０８とホストサービス１１６の間の通信セッションは、ホストサービス１１６が第１のプロトコルサービスチケットを受信した際に確立される。従って、クライアント１０８は、第１のプロトコルサービスチケットをホストサービス１１６へ伝送させ、それによって第１のプロトコルサービス１１２によってクライアント１０８のルーティングを強制するため、第１のプロトコルサービス１１２と通信を行わなければならない。従って、本発明は、ホストノード１１８へのアクセスを許可する前に、セキュリティ装置（例えば、第１のプロトコルサービス１１２）を適切に横断することを確実に行える。
【０１０３】
例えば、ホストノード１１８は、ともにＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＭＩＣＲＯＳＯＦＴ ＷＯＲＤおよびＭＩＣＲＯＳＯＦＴ ＥＸＣＥＬ等、いくつかのアプリケーションを実行する。一実施態様において、クライアント１０８は、クライアント１０８がアプリケーションにアクセスするサーバファーム１６９から情報を得るために、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ Ｌａｕｄｅｒｄａｌｅ、Ｆｌｏｒｉｄａ）製ＮＦＵＳＥを使用する。クライアントユーザーがＭＩＣＲＯＳＯＦＴ ＷＯＲＤにアクセスし使用したい場合、クライアント１０８はウェブサーバ１２０からアプリケーションを要求する。しかしながら、ＭＩＣＲＯＳＯＦＴ ＷＯＲＤに対するアプリケーション料を支払っているユーザーのみがこのアプリケーションへのアクセスを認可されることができる。
【０１０４】
アプリケーション料の支払いを確認するため、通信システム５０５は、第１のプロトコルサービス１１２を介してクライアント１０８のルーティングを強制するための第１のプロトコルサービス１１２およびチケットオーソリティ１３６を含む。第１のプロトコルサービス１１２がアプリケーション料の徴収およびアプリケーションにアクセスするためのユーザー認可に使用される場合、第１のプロトコルサービス１１２を介するクライアント１０８のルーティングは、アプリケーションプロバイダにとって価値がある。
【０１０５】
チケットオーソリティ１３６は、その後アプリケーションの要求に関連するチケットを生成する。次いで使用可能な第１のチケットがクライアント１０８へ伝送される。クライアント１０８はホストノード１１８のアドレスを持たないため、クライアント１０８はアプリケーションにアクセスできない。さらに、クライアント１０８は第１のプロトコルサービス１１２によってまだ認可されていない（すなわち、まだ支払っていない）。従って、クライアント１０８は認可を受けるために第１のプロトコルサービス１１２と通信を行わなければならない。第１のプロトコルサービス１１２はその後、アプリケーション料の支払い時に、使用可能な第１のチケットをチケットオーソリティ１３６へ伝送する。
【０１０６】
チケットオーソリティは次いでクライアントチケットを有効にし、その後第１のプロトコルサービスチケットをプロキシ１１５へ伝送（または使用可能に）する。第１のプロトコルサービス１１２は次いで第１のプロトコルサービスチケットをホストノード１１８へ伝送し（例えば、クライアントユーザーがアプリケーション料を支払ったと想定して）、それによりホストノード１１８にアプリケーションをクライアント１０８へ伝送可能にさせる。通信システム５０５は、クライアント１０８に配信するＨＴＭＬページから、またはＨＴＭＬページへの埋め込みからアプリケーションの起動を可能にするために、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ社製のＡｐｐｌｉｃａｔｉｏｎ Ｌａｕｎｃｈｉｎｇ Ａｎｄ Ｅｍｂｅｄｄｉｎｇ（ＡＬＥ）技術を使用してもよい。
【０１０７】
別の実施態様において、本発明はクライアント１０８のホストサービス１１６への再接続およびクライアント１０８とホストサービス１１６の間の接続または「ホップ」の再認証を対象とする。図６Ａは、クライアント１０８をホストサービス１１６へできるシステム６００の別の実施例を示す。上述したネットワーク１０４および１０４’、クライアント１０８、第１のプロトコルサービス１１２、およびホストサービス１１６に加えて、システム６００は、中間ノード６３２およびチケットオーソリティ１３６をさらに含む。一実施態様において、中間ノード６３２は、ネットワーク１０４の構成上クライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき、例えばファイアウォールおよび／またはルータのようなセキュリティゲートウェイである。また、中間ノード６３２は、第１のプロトコルサービス１１２とともに、またはこれを伴わずに、第１のプロトコルサービス１１２のプロキシ１１５を備えてもよい。図示するように、チケットオーソリティ１３６は、通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する、スタンドアロンのネットワークコンポーネントとすることができる。
【０１０８】
図６Ａの実施態様に示すように、中間ノード６３２は、クライアント１０８によって開始される接続１３５ａを受け入れ、第１のプロトコルサービス１１２による第２の接続１３５ｂを確立するように構成される。併せて、接続１３５ａおよび第２の接続１３５ｂは、上述のように接続１３５を構成し、それらを通じて第１のプロトコルを使用してクライアント１０８および第１のプロトコルサービス１１２が通信を行う。
【０１０９】
図に示すように、中間ノード６３２はまた、チケットオーソリティ１３６と通信を行うように構成される。一実施態様では、チケットオーソリティ１３６は、中間ノード６３２からの第１の再接続チケットに対する要求を受信し、その後に第１の再構成チケットを生成するように構成される。第１の再接続チケットは、例えば、大きな乱数を含むことができる。別の実施態様において、チケットオーソリティ１３６は、クライアントとホストサービス１１６の間の各「ホップ」に対する第１の再接続チケットの要求を受信するように構成される。例えば、中間ノード６３２は、クライアント１０８と中間ノード６３２の間、中間ノード６３２と第１のプロトコルサービス１１２の間、および第１のプロトコルサービス１１２とホストサービス１１６の間の接続のための再接続チケットを要求してよい。これらの再接続チケットは、各「ホップ」に対してのみ有効となることができる。例えば、ホストサービス１１６への第１のプロトコルサービス１１２の第１の再接続チケットは、クライアント１０８を代表してホストサービス１１６に対し第１のプロトコルサービス１１２を認証するためにのみ有効である。
【０１１０】
別の実施態様において、チケットオーソリティ１３６は、ハンドルを生成するように構成される。ハンドルは、例えば、第１の再接続チケットと関連する（例えば、マップする）乱数とすることができる。一実施態様では、ハンドルは、第１の再接続チケットを形成している乱数よりも小さな乱数である。例えば、ハンドルは、３２ビット乱数としてよい。さらなる実施態様において、ティッカーまたは再接続チケットに関連するチケットは、クライアント１０８とホストサービス１１６の間の複数のホップ接続における次の「ホップ」のアドレスまたはそれを指すポインタである。この場合、チケットまたは再接続チケットは、次の「ホップ」へのポインタを持つ単独の「ホップ」に対して有効となる。次の「ホップ」は、１つ前の「ホップ」が有効となり、クライアント１０８を代表してホストサービス１１６に接続されるまで、異なるチケットまたは再接続チケット等を得る必要があるであろう。
【０１１１】
チケットオーソリティ１３６は、第１の再接続チケットおよびハンドルを中間ノード６３２に伝送しながら、第１の再接続チケットのコピーおよびハンドルのコピーを維持する。第１の再接続チケットのコピーは、後にチケットオーソリティ１３６が使用することができ、クライアント１０８の再接続プロセス中に、後にチケットオーソリティ１３６にそのコピーを示す際に、元々はクライアント１０８に伝送された第１の再接続チケットを検証する。一実施態様では、チケットオーソリティ１３６は、第１のプロトコルサービス１１２に対するアドレスも維持するが、そのアドレスは、後述するように、第１の接続チケットに関連し、第１の再接続チケットの検証時に、中間ノード６３２に伝送される。
【０１１２】
一実施態様では、中間ノード６３２は、チケットオーソリティ１３６がそこに伝送したハンドルを使用して、チケットオーソリティ１３６で維持された第１の再接続チケットを削除するようにさらに構成される。別の実施態様では、下記のように、チケットオーソリティ１３６は、クライアント１０８のホストサービス１１６への再接続プロセス中に、第１の再接続チケットを削除し、その後代替の第１の再接続チケットを生成するようにさらに構成される。加えて、別の実施態様では、第１の再接続チケットは、所定の時間の経過後に自動的に削除するように構成される。クライアントとホストサービス１１６の間の各「ホップ」のための再接続チケットの実施態様において、再接続チケットのうち１つ、一部、またはすべてが所定の時間の経過後に削除されるよう構成されてよい。その他の実施態様において、チケットオーソリティ１３６または中間ノード６３２は、複数のホップチケットのそれぞれを削除し代替のチケットを生成するように構成される。
【０１１３】
別の実施態様では、第１のプロトコルサービス１１２は、第１の再接続チケットなどの場合、例えば、大きな乱数を含むことができる第２の再接続チケットを生成するように構成される。一実施態様では、第１のプロトコルサービス１１２は、クライアント１０８とホストサービス１１６間の各「ホップ」に対して第２の再接続チケットを生成する。第１のプロトコルサービス１１２は、第２の接続チケットをクライアント１０８に伝送しながら、第２の再接続チケットのコピーおよびセッション番号を維持するようにも構成することができる。第２の再接続チケットのコピーは、後に第１のプロトコルサービス１１２が使用することができ、クライアント１０８の再接続プロセス中に、後に第１のプロトコルサービス１１２にそのコピーを示す際に、元々はクライアント１０８に伝送された第２の再接続チケットを検証する。一実施態様では、第１のプロトコルサービス１１２は、中間ノード６３２を介して第２の再接続チケットをクライアント１０８に伝送する。別の実施態様では、第１のプロトコルサービス１１２は、第２の再接続チケットをクライアント１０８に直接伝送する。さらなる実施態様では、第１のプロトコルサービス１１２は、第２の再接続チケットをその他の第１のプロトコルサービス１１２またはクライアント１０８とホストサービス１１６の間に複数のホップ接続を含む場合がある中間ノード６３２へ伝送してよい。
【０１１４】
さらに、下記にさらに詳しく説明するように、第１のプロトコルサービス１１２は、クライアント１０８のホストサービス１１６への再接続プロセス中に、第２の再接続チケットを削除し、その後代替の第２の再接続チケットを生成するようにさらに構成される。加えて、別の実施態様では、第２の再接続チケットは、所定の時間の経過後に自動的に削除するように構成される。さらなる実施態様では、複数のホップ接続における１つ以上の第１のプロトコルサービス１１２の第１のプロトコルサービス１１２は、各「ホップ」のための第２の再接続チケットを削除し、その後「ホップ」の１つ、一部またはすべてに対する代替の再接続チケットを生成するよう構成される。
【０１１５】
一実施態様では、中間ノード６３２は、第１および第２の再接続チケットに対する中間物としての機能を果たす。中間ノード６３２は、例えば、チケットオーソリティ１３６が生成する第１の再接続チケット、および第１のプロトコルサービス１１２が生成する第２の再接続チケットを受信する。中間ノード６３２は、次いで第１の再接続チケットおよび第２の再接続チケットをクライアント１０８に伝送することができる。さらに、クライアント１０８のホストサービス１１６への再接続プロセス中、中間ノード６３２は、クライアント１０８から第１の再接続チケットおよび第２の再接続チケットを受け入れることができ、その後第１の再接続チケットをチケットオーソリティ１３６に伝送することができ、適切な場合、第２の再接続チケットを第１のプロトコルサービス１１２に伝送することができる。
【０１１６】
別の実施態様において、中間ノード６３２は、再接続チケットの、クライアント１０８とホストサービス１１６との間の複数のホップへの仲介としての役割を果たす。中間ノード６３２は、例えば、クライアント１０８の第１のプロトコルサービス１１２への接続のための第１の再接続チケット、および第１のプロトコルサービス１１２のホストサービス１１６への第１の再接続チケットを受信する。さらなる実施態様では、中間ノード６３２は、中間ノード６３２と第１のプロトコルサービス１１２との間の接続のための第１の再接続チケットを受信する。中間ノード６３２は、次いでクライアントのための第１の再接続チケットをクライアント１０８へ、また第１のプロトコルサービス１１２のための第１の再接続チケットを第１のプロトコルサービス１１２へ伝送することができる。さらに、クライアント１０８のホストサービス１１６への再接続プロセス中、中間ノード６３２は、中間ノード６３２または第１のプロトコルサービス１１２に対するクライアントの接続を再確立するチケットを有効にするため、クライアント１０８から第１の再接続チケットを受け入れることができる。
【０１１７】
図６Ｂを参照して、ネットワーク通信のためのシステム６０２の別の実施態様は、上述のように、ネットワーク１０４および１０４’と、クライアント１０８と、第１のプロトコルサービス１１２と、ホストサービス１１６ａ乃至１１６ｎと、中間ノード６３２と、チケットオーソリティ１３６とを含み、さらに、一実施態様においてクライアント１０８をホストサービス１１６に最初に接続するためにどちらも使用する、第１の計算コード６４０および第２の計算ノード６４４を示す。さらに、図６Ａの実施態様では、クライアント１０８は、例えば、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、ＷＡ）製のＩＮＴＥＲＮＥＴ ＥＸＰＬＯＲＥＲなどのような、ワールドワイドウェブに接続するためのウェブブラウザ１６２をさらに含む。
【０１１８】
一実施態様では（図示せず）、システム６０２は、２つ以上の中間ノード６３２および／または２つ以上の第１のプロトコルサービス１１２を含む。それを介してクライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード６３２および／または第１のプロトコルサービス１１２は、例えばロードバランシング式に基づいてそれぞれ選択することができる。
【０１１９】
第１の計算ノード６４０および第２の計算ノード６４４のそれぞれは、通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する、任意のコンピュータとすることができる。例えば、一実施態様では、第１の計算ノード６４０は、１つ以上のウェブサイトを提供するウェブサーバ１２０を含む。別の実施態様では、第２の計算ノード６４４は、ＸＭＬサービスを提供する。
【０１２０】
一実施態様では、クライアント１０８およびネットワーク１０４は、外部ネットワーク６５２を形成するが、破線で示される第１のファイアウォール１６０によってシステム６０２の他の部分から切り離される。中間ノード６３２および第１の計算ノード６４０は、同様に破線で示される第１のファイアウォール１６０および第２のファイアウォール１６１によってシステム６０２の他の部分から切り離されるＤＭＺ１３０内に置くことができる。次いで、図に示すように、ネットワーク１０４’、第１のプロトコルサービス１１２、ホストサービス１１６ａ乃至１１６ｎ、チケットオーソリティ１３６、および、第２の計算ノード６４４は、内部ネットワーク６６８を形成するが、第２のファイアウォール１６１によってシステム６０２の他の部分から切り離される。
【０１２１】
あるいは、別の実施態様では、図６Ｃを参照して、システム６０４は、ＤＭＺ１３０内でネットワーク１０４と中間ノード６３２との間に配置される第３の計算ノード６４６をさらに含む。第３の計算ノード６４６は、ネットワーク化された通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する、任意のコンピュータとすることができる。下記のように、第３の計算ノード６４６は、一部の実施態様では、クライアント１０８のホストサービス１１６への最初の接続プロセス中、および／またはクライアント１０８のホストサービス１１６への再接続プロセス中に使用する。より具体的には、下記のように、システム６０４が２つ以上の中間ノード６３２を含む際には、第３の計算ノード６４６は、例えばロードバランシング式に基づいて、それを介してクライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間の通信が通過すべき中間ノード６３２を選択することができる。
【０１２２】
さらに、図６Ｄを参照して、図６Ｃの中間ノード６３２は、別の実施態様では、２つ以上のレベル「ａ」乃至「ｎ」の中間ノード６３２に置換することができる。図示するように、各レベル「ａ」乃至「ｎ」は、２つ以上の中間ノード６３２ａ乃至６３２ｎを含むことができる。下記のように、クライアント１０８のクライアントエージェント１２８は、例えばロードバランシング式に基づいて、中間ノード６３２の任意の組み合わせを介して送ることができる。例えば、図示するように、クライアントエージェント１２８は、接続６２２を介して中間ノード６３２を介して送ることができる。追加のセキュリティのため、各「ホップ」は接続６２２を介して、クライアント１０８とホストサービス１１６との間の複数のホップ接続を有効にし認証するためのチケットまたは再接続チケットを要求することができる。当業者にとって容易に明らかなように、他の構成のシステム６００、６０２および６０４も可能である。
【０１２３】
再び図６Ｂを参照すると、一実施態様では、ウェブブラウザ１６２は、第１の計算ノード６４０によるネットワーク１０４を通じて通信を行うが、それ自身が第２の計算ノード６４４およびチケットオーソリティ１３６と接続する。より具体的には、第１の計算ノード６４０は、第２の計算ノード６４４およびチケットオーソリティ１３６のアドレスによって構成される。一実施態様において、下記にさらに説明するように、第１の計算ノード６４０は、クライアント１０８のウェブブラウザ１６２と、第２の計算ノード６４４と、チケットオーソリティ１３６との間の情報を中継し、それによってそれらの直接的な通信を防ぐように構成される。このような直接的な通信を防ぐことによって、第１の計算ノード６４０は、システム６０２にさらなるレベルのセキュリティを付加する。第１の計算ノード６４０は、中間ノード６３２のアドレス、または代わりに、２つ以上の中間ノード６３２のアドレスによって構成することもできる。
【０１２４】
第２の計算ノード６４４は、その役割として、ホストサービス１１６上で実行するどのアプリケーションプログラムをクライアント１０８のユーザーが利用できるかを判断するように構成される。すなわち、第２の計算ノード６４４は、ユーザーがアクセスを許可されたのはどのアプリケーションプログラムなのかを判断する。一実施態様では、ユーザーが自身の所望するアプリケーションプログラムを選択した後、さらに下記のように、第２の計算ノード６４４は、ロードバランシングのためにユーザーの所望のアプリケーションを実行するため、どのホストサービス１１６を使用するかを判断するように構成される。第２の計算ノード６４４は、そのホストサービス１１６のアドレスを第１の計算ノード６４０に返す。第２の計算ノード６４４は、ロードバランシング式を使用して複数の第１のプロトコルサービス１１２の中からも選択される、第１のプロトコルサービス１１２のアドレスも第１の計算ノード６４０に返す。次に、第１の計算ノード６４０は、選択した第１のプロトコルサービス１１２および選択したホストサービス１１６のアドレスをチケットオーソリティ１３６に伝送する。
【０１２５】
チケットオーソリティ１３６は、その役割として、接続チケットを生成する。一実施態様では、チケットオーソリティ１３６は、クライアント１０８への伝送に対する最初の接続チケットを第１の計算ノード６４０に伝送する。別の実施態様では、チケットオーソリティ１３６は、最初の接続チケットを、クライアント１０８およびホストサービス１１６との間の１つ以上の「ホップ」のための第１の計算ノード６４０へ伝送する。
【０１２６】
図７を参照して、図６Ａ乃至図６Ｄの例示的実施態様を使用したネットワーク通信のための方法６００の一実施態様を示す。ステップ６０４で、クライアント１０８は、例えば下記に示す方法７００を用いて、クライアント１０８を複数のホストサービス１１６に接続する。クライアント１０８の複数のホストサービス１１６への接続後、クライアント１０８およびホストサービス１１６は、第１のプロトコルサービス１１２を介して、およびステップ６０８で、第１のプロトコル内にカプセル化された複数の第２のプロトコルを介して通信を行う。一実施態様では、第１のプロトコルサービス１１２は、いずれの第１のプロトコルパケットの伝送前に、通信を第１のプロトコル２０４のレベルで暗号化し、それによって通信を保護する。別の実施態様では、第１のプロトコルサービス１１２は、任意の第１のプロトコルパケットの伝送前に、通信を第１のプロトコルのレベルで圧縮し、それによって通信効率を改善する。
【０１２７】
ステップ６１２で、クライアントエージェント１２８は、クライアントエージェント１２８と第１のプロトコルサービス１１２との間の接続１３５が失敗したかどうかを判断する。例えば、クライアントエージェント１２８と中間ノード６３２との間の接続１３５ａが失敗した可能性があり、または中間ノード６３２と第１のプロトコルサービス１１２との間の接続１３５ｂが失敗した可能性があり、あるいは接続１３５ａおよび１３５ｂの両方が失敗した可能性がある。別の実施態様では、第１のプロトコルサービス１１２とホストサービス１１６との間の接続が失敗した可能性がある。クライアントエージェント１２８が、接続１３５は失敗しなかったと判断した場合は、方法６００はステップ６２０へ進む。一方で、クライアントエージェント１２８が、接続１３５は失敗したと判断した場合は、ステップ６１６で、クライアント１０８にホストサービス１１６への信頼できる接続を提供し、ホストサービス１１６に再接続する。
【０１２８】
ステップ６２０では、クライアント１０８がプロトコルサービス１１２との接続１３５を、そして結果的にホストサービス１１６との接続１２４ａ乃至１２４ｎを完全に完了することを望んでいるかどうかを判断する。望んでいない場合には、ステップ６０８で、第１のプロトコル内にカプセル化された複数の第２のプロトコルを介して、クライアント１０８と第１のプロトコルサービス１１２との間の通信を継続する。望んでいる場合は、次いでステップ６２４で、すべての接続１３５ａ、１３５ｂ、および１２４ａ乃至１２４ｎを中断し、すべての再接続チケットを削除する。一実施態様では、中間ノード６３２は、チケットオーソリティ１３６から受信したハンドルを使用して、チケットオーソリティ１３６に保存された第１の再接続チケットのコピーを削除する。別の実施態様では、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２に保存された第２の再接続チケットのコピーを削除する。さらなる実施態様では、何らかの理由で第２のプロトコル接続１２４が失敗した場合、関連する第１のプロトコルサービス１１２で保存された第２の再接続チケットのコピーを第１のプロトコルサービス１１２によって削除する。さらに別の実施態様では、第１の再接続チケットおよび／または第２の再接続チケットは、ステップ６１２でのように、接続１３５における失敗に続いて、および／またはステップ６２０でのように、接続１３５の完全な終了に続いて、所定の時間の経過後に自動的に削除される。一実施態様では、第１のプロトコルサービス１１２またはチケットオーソリティ１３６のいずれかが、クライアント１０８とホストサービス１１６との間の１つ以上の「ホップ」のための１つ以上の再接続チケットを削除する。
【０１２９】
図８Ａ乃至８Ｃを参照して、図６Ａ乃至図６Ｄの例示的実施態様を使用してクライアント１０８のホストサービス１１６への最初の接続（例えば、図７のステップ６０４で）のための方法７００の一実施態様を示す。ステップ７０４で、クライアント１０８は、ブラウザ１６２を使用して、例えばＨＴＴＰリクエストなどのような、リクエストを第１の計算ノード６４０に送信する。第１の計算ノード６４０は、認証情報（例えば、ユーザー名およびパスワード）を要求する、例えばＨＴＭＬフォームなどのようなウェブページを返す。クライアント１０８のユーザーは、自分の認証を入力して完了したフォームを第１の計算ノード６４０に伝送する。
【０１３０】
ステップ７０８で、第１の計算ノード６４０は、次いでクライアント１０８のユーザーに実行可能なアプリケーションを通知する。一実施態様では、第１の計算ノード６４０は、ユーザーの認証をログインページから取り出し、第２の計算ノード６４４に対しユーザーが利用可能なアプリケーションを列挙するよう求める要求とともに、その認証を第２の計算ノード６４４に伝送する。ユーザーの認証に基づいて、第２の計算ノード６４４は、ユーザーが利用可能な特定のアプリケーションのリストを第１の計算ノード６４０に返し、次いでそのリストは、例えばウェブページの形態で、クライアント１０８のユーザーに転送される。
【０１３１】
ステップ７１２で、ユーザーは、所望のアプリケーションと、そのアプリケーションを第１の計算ノード６４０に送信する要求を選択する。例えば、一実施態様では、ユーザーは、第１の計算ノード６４０がユーザーに示すウェブページにリストされた所望のアプリケーションと、そのアプリケーションを第１の計算ノード６４０に転送するＨＴＴＰ要求をクリックする。その要求は、第１の計算ノード６４０によって処理され、第２の計算ノード６４４に転送される。
【０１３２】
ステップ７１６で、第２の計算ノード６４４は、要求したアプリケーションを実行するホストサービス１１６を判断する。第２の計算ノード６４４は、例えば、ロードバランシング式に基づいてその決定を行うことができる。一実施態様では、第２の計算ノード６４４は、接続１２４を介してホストサービス１１６と通信を行うために使用する複数の第１のプロトコルサービス１１２の中から第１のプロトコルサービス１１２も判断する。また、第２の計算ノード６４４は、例えば、ロードバランシング式に基づいてその決定を行うことができる。第２の計算ノード６４４は、選択したホストサービス１１６および選択した第１のプロトコルサービス１１２のアドレスを第１の計算ノード６４０に返す。
【０１３３】
ステップ７２０で、クライアント１０８には、次いで最初の接続チケットと、中間ノード６３２（下記のように、その実際のアドレスか、またはその仮想アドレスである）のためのアドレスが提供される。一実施態様では、第１の計算ノード６４０は、最初の接続チケットの要求とともに、選択したホストサービス１１６および選択した第１のプロトコルサービス１１２のアドレスをチケットオーソリティ１３６に提供する。チケットオーソリティ１３６は、選択したホストサービス１１６および選択した第１のプロトコルサービス１１２のアドレスを保存し、最初の接続チケットを生成し、この最初の接続チケットを第１の計算ノード６４０に伝送しながら、自身のためのコピーを保存する。一実施態様において、チケットオーソリティ１３６は、第１の計算ノード６４０による最初の接続チケットを受けて、クライアント１０８とホストサービス１１６との間の各「ホップ」のための接続チケットを生成する。別の実施態様では、第１の計算ノード６４０は、単独要求または複数の要求における各「ホップ」のための最初の接続チケットを要求する。例えば、チケットオーソリティ１２６は、図５Ｂと併せて上述した複数部のチケットを生成する。
【０１３４】
一実施態様において中間ノード６３２の実際のアドレスによって構成される第１の計算ノード６４０は、次いで中間ノード６３２の実際のアドレスおよび最初の接続チケットをクライアント１０８のブラウザ１６２に伝送する。第１の計算ノード６４０は、例えば、中間ノード６３２の実際のアドレスおよび最初の接続チケットを含むファイルをまず作成し、次いでそのファイルをクライアント１０８のブラウザ１６２に伝送することができる。任意で、別の実施態様では、第１の計算ノード６４０は、２つ以上の中間ノード６３２の実際のアドレスによって構成される。このような実施態様では、第１の計算ノード６４０は、先ずそれを介してクライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード６３２を判断する。第１の計算ノード６４０は、次いでその選択した中間ノード１３２の実際のアドレスおよび最初の接続チケットを、例えば、上述のファイルを使用して、クライアント１０８のブラウザ１６２に伝送する。一実施態様では、第１の計算ノード６４０は、ロードバランシング式を使用して中間ノード６３２を選択する。次いでクライアント１０８のクライアントエージェント１２８が起動され、中間ノード６３２のアドレスを使用して、ステップ７２４で、クライアント１０８のクライアントエージェント１２８と中間ノード６３２との間の第１のプロトコル接続１３５ａを確立する。一実施態様では、第１の計算ノード６４０は、各々の接続を有効にするためにチケットオーソリティ１３６から得られた１つ以上の第１のプロトコルサービス１１２および／または中間ノード６３２への最初の接続チケットを提供してよい。
【０１３５】
あるいは、別の実施態様では、第１の計算ノード６４０は、中間ノード１３２の仮想アドレスとしての機能を果たす第３の計算ノード６４６の実際のアドレスによって構成される。このような実施態様では、ステップ７２０で、第１の計算ノード６４０は、第３の計算ノード６４６の実際のアドレスおよび最初の接続チケットを、例えば、上述のファイルを使用して、クライアント１０８のブラウザ１６２に伝送する。次いでクライアント１０８のクライアントエージェント１２８が起動され、第３の計算ノード６４６の実際のアドレスを使用して、ステップ７２４で、クライアント１０８のクライアントエージェント１２８と第３の計算ノード６４６との間の第１のプロトコル接続を確立する。第３の計算ノード６４６は、次いで、それを介してクライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード６３２を判断する。一実施態様では、第３の計算ノード６４６は、ロードバランシング式を使用して中間ノード６３２を選択する。中間ノード６３２を選択すると、第３の計算ノード６４６は、中間ノード６３２に対する第１のプロトコル接続を確立する。その結果、第３の計算ノード６４６を介して、第１のプロトコル接続１３５ａが、クライアント１０８のクライアントエージェント１２８と中間ノード６３２との間に存在する。従って、第３の計算ノード６４６の実際のアドレスは、中間ノード６３２の実際のアドレスにマップされる。クライアント１０８のクライアントエージェント１２８に対して、第３の計算ノード６４６の実際のアドレスが中間ノード６３２の仮想アドレスとしての機能を果たす。
【０１３６】
一実施態様では、複数のレベルの中間ノード６３２が存在する際には、上述のように、第１の計算ノード６４０または第３の計算ノード６４６はそれぞれ、クライアントエージェント１２８がレベル「ａ」で接続する中間ノード６３２だけを選択する。このような実施態様では、各々のレベル「ａ」乃至「ｎ−１」で、クライアントエージェント１２８がレベルで送られる中間ノード６３２は、その後、例えばロードバランシング式に基づいて、次のレベルで接続する中間ノード６３２を判断する。あるいは、他の実施態様では、第１の計算ノード６４０または第３の計算ノード６４６はそれぞれ、複数またはすべてのレベル「ａ」乃至「ｎ」に対して、クライアントエージェント１２８が送られる中間ノード６３２を選択する。
【０１３７】
クライアント１０８のクライアントエージェント１２８と中間ノード６３２との間の第１のプロトコル接続１３５ａ、例えば、レベル「ｎ」の中間ノード１３２（以下、方法７００において中間ノード６３２と称する）を確立すると、次いでクライアントエージェント１２８は、最初の接続チケットを中間ノード６３２に伝送する。
【０１３８】
次いで、ステップ７２８で、最初の接続チケットが有効かどうかを判断する。一実施態様では、中間ノード６３２は、検証のために最初の接続チケットをチケットオーソリティ１３６に伝送する。一実施態様では、チケットオーソリティ１３６は、ステップ７２０で保存した最初の接続チケットのコピーと比較することによって、最初の接続チケットの有効性を判断する。チケットオーソリティ１３６が最初の接続チケットを有効であると判断した場合、ステップ７３２で、チケットオーソリティ１３６は、第１のプロトコルサービス１１２のアドレスおよび選択したホストサービス１１６のアドレスを中間ノード６３２に伝送する。チケットオーソリティ１３６は、クライアント１０８がホストサービス１１６に接続するのに通過する第１のプロトコルサービス１１２および中間ノード６３２のための追加の接続チケットを伝送してもよい。第１のプロトコルサービス１１２は、最初の接続チケットおよびそのコピーを削除することもできる。一方で、チケットオーソリティ１３６が最初の接続チケットを無効であると判断した場合、ステップ７３０で、クライアント１０８は、第１のプロトコルサービス１１２への接続を拒否し、結果的に、ホストサービス１１６に接続する。
【０１３９】
ステップ７３２に続いて、中間ノード６３２は、選択した第１のプロトコルサービス１１２のアドレスを使用して、ステップ７３６で、中間ノード６３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１３５ｂを確立する。一実施態様では、中間ノード６３２は最初の接続チケットを使用して、中間ノード６３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１３５ｂを確立する。ある場合には、中間ノード６３２はクライアント１０８から受信した同じ最初の接続チケットを使用して、接続１３５ｂを有効にする。別の場合には、中間ノード６３２は、第１のプロトコル接続１３５ｂのために生成され有効にされた最初の接続チケットを使用する。したがってここでは、中間ノード６３２を介して、クライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間に、第１のプロトコル接続１３５が存在する。中間ノード６３２は、選択したホストサービス１１６のアドレスを第１のプロトコルサービス１１２に渡すこともできる。
【０１４０】
一実施態様では、ステップ７４０で、第１のプロトコルサービス１１２は、選択したホストサービス１１６のアドレスを使用して、第１のプロトコルサービス１１２と選択したホストサービス１１６との間の第２のプロトコル接続１２４を確立する。例えば、選択したホストサービス１１６は実際にホストサービス１１６ａであり、第２のプロトコル接続１２４ａが第１のプロトコルサービス１１２とホストサービス１１６ａとの間に確立される。
【０１４１】
一実施態様では、ステップ７４０に続いてステップ７４４で、ユーザーは実行する第２のアプリケーションを選択し、ステップ７４８で、第２の計算ノード６４４は第２のアプリケーションが実行されるホストサービス１１６を判断する。例えば、ロードバランシング式を計算することによって、第２の計算ノード６４４は、第２のアプリケーションプログラムを実行するためにホストサービス１１６ｂを選択することが可能である。第２の計算ノード６４４は、次いで選択したホストサービス１１６ｂのアドレスを第１のプロトコルサービス１１２に伝送する。一実施態様では、第２の計算ノード６４４は、第１のプロトコルサービス１１２による直接的な通信にあり、そこにアドレスを直接伝送する。別の実施態様では、選択したホストサービス１１６ｂのアドレスは、第１のプロトコルサービス１１２に間接的に伝送される。例えば、第１の計算ノード６４０、チケットオーソリティ１３６、中間ノード６３２、および第１のプロトコルサービス１１２の任意の組み合わせを介して第１のプロトコルサービス１１２にアドレスを伝送することができる。選択したホストサービス１１６ｂのアドレスを受信すると、第１のプロトコルサービス１１２は、ステップ７５２で、第１のプロトコルサービス１１２と選択したホストサービス１１６ｂとの間の第２のプロトコル接続１２４ｂを確立する。第２のプロトコル接続１２４ｂの確立において、第１のプロトコルサービス１１２は最初の接続チケットを有効にしてホストサービス１１６への接続を認証することができる。最初の接続チケットは、中間ノード６３２へのクライアント１０８の接続または中間ノード６３２の第１のプロトコルサービス１１２への接続いずれかのための最初の接続チケットと同じであってよい。別の実施態様では、チケットオーソリティ１３６または中間ノード６３２のいずれかが、第２のプロトコル接続１２４ｂにのみ有効なチケットを生成した。第１のプロトコルサービス１１２および／またはホストサービス１１６はこのチケットを使用して第２のプロトコル接続１２４ｂを有効にする。
【０１４２】
接続１２４ａおよび１２４ｂを通じて通信を行うために使用できる第２のプロトコルは、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡ、および、ＲＤＰを含むがこれらに限定されない。さらに、一実施態様では、上述のように、少なくとも１つの第２のプロトコルは、複数の仮想チャネルを含むが、それぞれリモートクライアント１０８での機能を可能にする複数のプロトコルパケットを含むことができる。例えば、一実施態様では、一方のホストサービス１１６ａはウェブサーバであり、ＨＴＴＰプロトコルを使用して接続１２４ａを通じて第１のプロトコルサービス１１２と通信を行い、他方のホストサービス１１６ｂはアプリケーションサーバであり、ＩＣＡプロトコルを使用して接続１２４ｂを通じて第１のプロトコルサービス１１２と通信を行う。ホストサービス１１６ｂは、クライアント１０８にグラフィカルユーザーインターフェイスを表示させるグラフィックスクリーンコマンドをクライアント１０８に伝送するためのプロトコルパケット、およびクライアント１０８で文書を印刷させるプリンタコマンドをクライアント１０８に伝送するためのプロトコルパケットの両方を生成する。
【０１４３】
ステップ７４４、７４８、および７５２は、複数回繰り返すことができる。このように、任意数のアプリケーションプログラムを任意数のホストサービス１１６ａ乃至１１６ｎ上で実行することができ、その出力は、任意数の第２のプロトコルを使用して接続１２４ａ乃至１２４ｎを通じて第１のプロトコルサービス１１２へ通信を行うことができる。
【０１４４】
ステップ７５６では、第１のプロトコルサービス１１２は、上述のように、第１のプロトコル内に複数の第２のプロトコルをカプセル化することができる。このように、クライアント１０８は、複数のホストサービス１１６に接続され、同時にそれらと通信を行う。
【０１４５】
別の実施態様では、ステップ７４４、７４８、および７５２を行う前に、例えば、ホストサービス１１６ｂなどのようなホストサービス１１６上で新しいアプリケーションプログラムを実行するために、クライアント１０８のユーザーは、例えば、ホストサービス１１６ａ上で実行しているアプリケーションプログラムなどのような、別のアプリケーションプログラムの実行を終了する。そのような場合、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２とホストサービス１１６ａとの間の接続１２４ａを中断させる。次いで第１のプロトコルサービス１１２は、ステップ７４４、７４８、および７５２を実行して、クライアント１０８と第１のプロトコルサービス１１２との間の接続１３５を中断せずに、第１のプロトコルサービス１１２とホストサービス１１６ｂとの間の接続１２４ｂを確立する。
【０１４６】
一実施態様では、第１の再接続チケットは、ステップ７６０で生成される。例えば、中間ノード６３２は、チケットオーソリティ１３６から第１の再接続チケットを要求するか、またはクライアント１０８とホストサービス１１６との間の各「ホップ」のための第１の再接続チケットを要求する。その要求を受信すると、チケットオーソリティ１３６は、１つ以上の第１の再接続チケットを生成する。再接続チケットは、例えば大きな乱数であり、例えばより小さな乱数であるハンドルも生成することができる。次いでチケットオーソリティ１３６は、ステップ７６４で、第１の再接続チケットおよびハンドルを中間ノード６３２に伝送することができ、一方で第１の再接続チケットのコピーおよびハンドルのコピーを保存する。チケットオーソリティ１３６は、ステップ７２０で第１の計算ノード６４０によってそこに伝送された第１のプロトコルサービス１１２のアドレスの維持を継続する。次いで中間ノード６３２は、ステップ７６８で、クライアントの第１の再接続チケットをクライアント１０８に伝送する。
【０１４７】
ステップ７７２では、次いで１つ以上の第２の再接続チケットを生成する。一実施態様では、第１のプロトコルサービス１１２は、例えば大きな乱数となりうるクライアント１０８のための第２の再接続チケットを生成する。別の実施態様では、第１のプロトコルサービス１１２は、クライアント１０８とホストサービス１１６との間の１つ以上の「ホップ」のための第２の再接続チケットを生成する。次いで第１のプロトコルサービス１１２は、ステップ７７６で、中間ノード６３２を介してクライアントの第２の再接続チケットをクライアント１０８に伝送する。この際、第１のプロトコルサービス１１２は、接続１３５の中断に続いて再接続されるセッションを識別するために、第２の再接続チケットのコピーおよびそれらに関連するセッション番号を保存する。一実施態様では、例えば、第１のプロトコルサービス１１２は、特定のセッション番号に対して、そのセッション番号に関連する第２のプロトコル接続１２４ａ乃至１２４ｎをリストしたテーブルを維持する。同様に、第１のプロトコルサービス１１２は、クライアント１０８をホストサービス１１６に再接続するよう有効にされた各「ホップ」のための第１および／または第２の再接続チケットを維持することができる。
【０１４８】
従って、第１のプロトコルサービス１１２、および／またはそれに続く任意の第１のプロトコルサービス１１２および／または中間ノード６３２における第１のプロトコル接続１３５の再確立および第２の再接続チケットの検証に続けて、第１のプロトコルサービス１１２は、クライアント１０８への通信のために、再確立された第１のプロトコル接続１３５内にカプセル化された第２のプロトコル接続１２４を識別することができる。あるいは、別の実施態様では、再度図１Ａを参照すると、本発明のシステム１００は、中間ノード１３２、チケットオーソリティ１３６、第３の計算ノード６４６のいずれも含まない。
【０１４９】
このような実施態様では、ステップ７６０乃至７７６では、第１および第２の再接続チケットの両方を生成および伝送するのではなく、システム１００および方法７００は、クライアント１０８のための、またはクライアント１０８とホストサービス１１６との間の１つ以上の「ホップ」のための、単一の再接続チケットだけを提供する。このような一実施態様では、第１のプロトコルサービス１１２は、例えば大きな乱数となりうる単一の再接続チケットを生成する。第１のプロトコルサービス１１２は、次いでクライアントの再接続チケットを接続１３５を通じてクライアント１０８に直接伝送する。この際、第１のプロトコルサービス１１２は、接続１３５の中断に続いて再接続されるセッションを識別するために、単一の再接続チケットのコピーおよびそれらに関連するセッション番号を保存する。別の実施態様では、第１のプロトコルサービス１１２はそのホストサービス１１６への接続のための再接続チケットおよびその再接続チケットの回収に関連するセッション番号を保存する。
【０１５０】
以下、図９を参照して、図６Ａ乃至６Ｄの例示的実施態様を使用した（例えば、図７のステップ６１６で）クライアント１０８に１つ以上のホストサービス１１６への信頼できる接続を提供し、クライアント１０８をホストサービス１１６へ再接続する方法８００の一実施態様を示す。特に、ステップ８０４で、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間の第２のプロトコル接続１２４を維持する。さらに、ステップ８０８で、例えば、図７のステップ６１６で中断していると判断された接続１３５を介して、クライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間の直近に伝送されたデータパケットのキューを維持する。一実施態様では、データパケットは、接続１３５の前でも失敗時でもキューに入れられ維持される。キューに入れたデータパケットは、例えば、クライアントエージェント１２８によってバッファ内に維持することができる。あるいは、第１のプロトコルサービス１１２は、キューに入れたデータパケットをバッファ内に維持することができる。さらに別の実施態様では、クライアントエージェント１２８および第１のプロトコルサービス１１２のどちらも、キューに入れたデータパケットをバッファ内に維持する。
【０１５１】
ステップ８１２で、新しい第１のプロトコル接続１３５が、クライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間に確立され、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間で維持された第２のプロトコル接続１２４にリンクされ、それによって、クライアント１０８をホストサービス１１６に再接続する。クライアント１０８の再接続後、ステップ８０８で維持されたキューに入れたデータパケットは、ステップ８１６で、新しく確立された第１のプロトコル接続１３５を介して伝送することができる。このように、ホストサービス１１６とクライアント１０８との間の通信セッションは、第１のプロトコルサービス１１２を介して、いずれのデータも失わずに持続的に進められる。
【０１５２】
ステップ８０８において、第１のプロトコルサービス１１２を横断する複数の「ホップ」を伴う実施態様では、データパケットの一部またはすべてが１つ以上の第１のプロトコルサービス１１２において維持されることができる。ステップ８１２において、各「ホップ」が再確立されることができる。上述のように、クライアント１０８が１つ以上の第１のプロトコルサービス１１２に再接続および再リンクされた後、残っている接続のそれぞれは、ホストサービス１１６への最後の「ホップ」が再確立されるまで、以前再接続した「ホップ」に再接続および再リンクされることができる。最後の「ホップ」が再確立または再リンクされた後、または各「ホップ」が再確立または際リンクされた際のいずれかに、ステップ８０８で維持されたキューに入れたデータパケットは、ステップ８１６で伝送されることができる。
【０１５３】
以下、図１０Ａおよび１０Ｂを参照して、図６Ａ乃至６Ｄの例示的実施態様を使用した、（例えば、図９のステップ８１２で）クライアント１０８を１つ以上のホストサービス１１６へ再接続する方法９００の一実施態様を示す。ステップ９０４で、クライアント１０８と第１のプロトコルサービス１１２との間のうちの残りの接続を中断する。例えば、接続１３５ａは失敗したが、接続１３５ｂは失敗していない場合、接続１３５ｂを中断する。あるいは、接続１３５ｂは失敗したが、接続１３５ａは失敗していない場合、接続１３５ａを中断する。
【０１５４】
一実施態様では、例えば、図８のステップ７２０で、クライアント１０８に提供した中間ノード６３２の実際のアドレスを使用して、ステップ９０８で、クライアント１０８のクライアントエージェント１２８は、次いでクライアントエージェント１２８と中間ノード６３２との間の第１のプロトコル接続１３５ａを再確立する。あるいは、別の実施態様では、例えば、図８のステップ７２０で、クライアント１０８に提供した第３の計算ノード６４６の実際のアドレスを使用して、ステップ９０８で、クライアント１０８のクライアントエージェント１２８は、次いでクライアントエージェント１２８と第３の計算ノード６４６との間の第１のプロトコル接続を再確立する。第３の計算ノード６４６は、クライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード６３２を判断する。一実施態様では、第３の計算ノード６４６は、ロードバランシング式を使用して中間ノード６３２を選択する。クライアント１０８の１つ以上のホストサービス１１６への再接続において、第３の計算ノード６４６によって選択された中間ノード６３２は、例えば、図８のステップ７２０で、クライアント１０８を１つ以上のホストサービス１１６に最初に接続するために、その選択とは異なることができる。一実施態様では、選択した中間ノード６３２のための最初の接続チケットは、クライアント１０８をホストサービス１１６へ再接続する際に生成される。
【０１５５】
中間ノード６３２を選択すると、第３の計算ノード６４６は、中間ノード６３２への第１のプロトコル接続１３５ａを再確立する。従って、第１のプロトコル接続１３５ａは、第３の計算ノード６４６を介して、クライアント１０８のクライアントエージェント１２８と中間ノード６３２との間に再確立される。一実施態様では、中間ノード６３２への第１のプロトコル接続１３５ａが再確立されると、第１のプロトコル接続１３５ａはこの「ホップ」のための第１または第２の再接続チケットをチケットオーソリティ１３６で有効にすることにより、有効化される。
【０１５６】
一実施態様では、１つより多いレベルの中間ノード６３２が存在する場合、クライアントエージェント１２８がレベル「ａ」乃至「ｎ−１」で送られる中間ノード６３２は、例えばロードバランシング式に基づいて、次のレベルで接続される中間ノード６３２を判断する。あるいは、別の実施態様では、第３の計算ノード６４６は、複数またはすべてのレベル「ａ」乃至「ｎ」に対して、それを介してクライアントエージェント１２８が送られる中間ノード６３２を判断する。その他の実施態様では、中間ノード６３２または計算ノードの１つ（例えば、第３の計算ノード６４６）のいずれかが、１つ以上の接続またはクライアントエージェント１２８が送られる「ホップ」のための第１または第２の再接続チケットを生成する。
【０１５７】
クライアント１０８のクライアントエージェント１２８と中間ノード６３２との間の第１のプロトコル接続１３５ａ、例えば、レベル「ｎ」の中間ノード１３２（以下、方法９００において中間ノード６３２と称する）を確立すると、次いでクライアントエージェント１２８は、ステップ９１２で、クライアント１０８のための第１の再接続チケットおよび第２の再接続チケットを中間ノード６３２に伝送する。
【０１５８】
次いで、ステップ９１６で、第１の再接続チケットが有効かどうかを判断する。一実施態様では、第１の再接続チケットの有効性は、チケットオーソリティ１３６を使用することによって判断される。例えば、中間ノード６３２は、第１の再接続チケットをチケットオーソリティ１３６に伝送する。一実施態様では、チケットオーソリティ１３６は、第１の再接続チケットの有効性を、以前に保存した第１の再接続チケットのコピーと比較することによって判断する。チケットオーソリティ１３６が第１の再接続チケットを有効であると判断した場合、ステップ９２０で、チケットオーソリティ１３６は、第１のプロトコルサービス１１２のアドレスを中間ノード６３２に伝送する。あるいは、チケットオーソリティ１３６が第１の再接続チケットを無効であると判断した場合、ステップ９２４で、クライアント１０８は、第１のプロトコルサービス１１２への再接続を拒否し、結果的に、ホストサービス１１６に接続する。
【０１５９】
ステップ９２８で、第１の再接続チケットは、例えばチケットオーソリティ１３６によって削除され、代替の第１の再接続チケットが、例えばチケットオーソリティ１３６により生成される。さらに、代替のハンドルが、例えばチケットオーソリティ１３６により生成されることができる。一部のこのような実施態様では、チケットオーソリティ１３６は、代替の第１の再接続チケットおよび代替のハンドルを中間ノード６３２に伝送する。さらに、一部のこのような実施態様では、チケットオーソリティ１３６は、代替の第１の再接続チケットのコピーを保存する。一部の実施態様では、チケットオーソリティ１３６は、クライアント１０８が第１の再接続チケットの削除に進む前に代替の第１の再接続を受信したことを認識するまで待つ。
【０１６０】
第１の再接続チケットの検証後、中間ノード６３２は、第１のプロトコルサービス１１２のアドレスを使用して、ステップ９３２で、中間ノード６３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１３５ｂを再確立する。中間ノード６３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１３５ｂを再確立すると、次いでステップ９３６で、第２の再接続チケットが有効かどうかを判断する。一実施態様では、第２の再接続チケットの有効性は、第１のプロトコルサービス１１２を使用することによって判断する。例えば、中間ノード６３２は、第２の再接続チケットを第１のプロトコルサービス１１２に伝送する。一実施態様では、第１のプロトコルサービス１１２は、第２の再接続チケットの有効性を、以前に保存した第２の再接続チケットのコピーと比較することによって判断する。ステップ９３６の別の実施態様では、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２とホストサービス１１６との間、または別の実施態様において、第１のプロトコルサービス１１２と別の第１のプロトコルサービス１１２または中間ノード６３２と間の接続のための第１の再接続チケットを有効にする。従って、同様に、第１のプロトコルサービス１１２とホストサービス１１６との間の各「ホップ」は、クライアント１０８を代表する「ホップ」の継続使用を有効にするための最初のまたは再接続チケットいずれかの１つ以上のチケットによって有効にされる。
【０１６１】
第１のプロトコルサービス１１２が第２の再接続チケットを有効であると判断した場合、第１の中間ノード１３２と第１のプロトコルサービス１１２との間で再確立された第１のプロトコル接続１３５ｂは、ステップ９４０で、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間で維持された第２のプロトコル接続１２４にリンクされる。さもなければ、第１のプロトコルサービス１１２が第２の再接続チケットを無効であると判断した場合、再確立された第１のプロトコル接続１３５ｂは、１つ以上の維持された第２のプロトコル接続１２４にはリンクされず、クライアント１０８は、ステップ９４４で、１つ以上のホストサービス１１６への再接続を拒否する。第１のプロトコルサービス１１２とホストサービス１１６との間の多数ホップ接続の場合、各「ホップ」は、再接続を有効にされ、ステップ９４０において、ホストサービス１１６への最後の「ホップ」が有効にされるまで、または「ホップ」の１つが再接続を拒否されるまで」、前の「ホップ」にリンクされる。
【０１６２】
ステップ９４８で、第２の再接続チケットは、例えば第１のプロトコルサービス１１２によって削除され、代替の第２の再接続チケットが、クライアント１０８への伝送のために、例えば第１のプロトコルサービス１１２により生成される。このような実施態様では、第１のプロトコルサービス１１２は、代替の第２の再接続チケットのコピーを保存する。一部の実施態様では、第１のプロトコルサービス１１２は、クライアント１０８が第２の再接続チケットの削除に進む前に代替の第２の再接続を受信したことを認識するまで待つ。クライアント１０８を再接続するための１つ以上の「ホップ」を有効にする場合、ステップ９４８において、チケットオーソリティ１３６、中間ノード６３２、計算ノードのいずれか、または１つ以上の第１のプロトコルサービス１１２によって、１つ以上の代替の再接続チケットが生成される、および／またはコピーが保存されることができる。
【０１６３】
ステップ９５２で、代替の第１の再接続チケットおよび代替の第２の再接続チケットは、クライアントに伝送される。例えば、チケットオーソリティ１３６は、中間ノード６３２を介して、代替の第１の再接続チケットをクライアント１０８に伝送することができる。さらに、一実施態様では、第１のプロトコルサービス１１２は、中間ノード６３２を介して、代替の第２の再接続チケットをクライアント１０８に伝送する。別の実施態様では、１つ以上の「ホップ」のための代替の再接続チケットを１つ以上の中間ノード６３２、計算ノードのいずれか、または１つ以上の第１のプロトコルサービス１１２に伝送することができる。
【０１６４】
あるいは、他の実施態様では、上述のように、本発明のシステム１００および方法は、クライアント１０８のための単一の再接続チケットおよび／またはクライアント１０８とホストサービス１１６との間の各「ホップ」のための単一の再接続だけを提供する。このように、第１および第２の再接続チケットの両方を使用するのではなく、例示的方法９００は、上述の単一の再接続チケットだけを使用する。このような一実施態様では、クライアント１０８のクライアントエージェント１２８には、第１のプロトコルサービス１１２のアドレスも提供される。ホストサービス１１６に再接続するために、クライアントエージェント１２８は、単一の再接続チケットを第１のプロトコルサービス１１２に直接伝送する。第１のプロトコルサービス１１２は、次いで単一の再接続チケットが有効であるかどうかを判断する。一実施態様では、第１のプロトコルサービス１１２は、単一の再接続チケットの有効性を、以前に保存した単一の再接続チケットのコピーと比較することによって判断する。第１のプロトコルサービス１１２が単一の再接続チケットを有効であると判断した場合、クライアント１０８と第１のプロトコルサービス１１２との間で再確立された第１のプロトコル接続１３５は、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間で維持された第２のプロトコル接続１２４にリンクする。さもなければ、第１のプロトコルサービス１１２が単一の再接続チケットを無効であると判断した場合、再確立された第１のプロトコル接続１３５は、１つ以上の維持された第２のプロトコル接続１２４にはリンクされず、クライアント１０８は、１つ以上のホストサービス１１６への再接続を拒否する。
【０１６５】
単一の再接続チケットの検証後、単一の再接続チケットは、例えば、第１のプロトコルサービス１１２によって削除され、代替の単一の再接続チケットが、クライアント１０８への伝送のために、例えば第１のプロトコルサービス１１２により生成される。代替の単一の再接続チケットのクライアント１０８への伝送では、第１のプロトコルサービス１１２は、代替の単一の再接続チケットのコピーを保存する。一部の実施態様では、第１のプロトコルサービス１１２は、クライアント１０８が単一の再接続チケットの削除に進む前に代替の単一の再接続を受信したことを認識するまで待つ。
【０１６６】
さらに別の実施態様では、第１および第２の再接続チケットと同様に、単一の再接続チケットは、ステップ６１２でのように、接続１３５における失敗に続いて、および／またはステップ６２０でのように、接続１３５の完全な終了に続いて、所定の時間の経過後に自動的に削除されるように構成される。
【０１６７】
本発明の趣旨および範囲から逸脱することなく、多くの修正および改良が当業者によってなされる場合がある。従って、例示的実施態様は例としての目的のみのために示されたものであり、以下の特許請求の範囲によって定義される本発明を限定するものと考えられるべきでないことは、明確に理解されなければならない。これらの特許請求の範囲は、上記の図に示し説明したものとその他の点で同一でないとしても、逐語的に説明するものおよび非現実的に異なる同等の要素を含むものとして解釈されたい。
【図面の簡単な説明】
【０１６８】
上述の本発明の他の目的、局面、特徴、および利点は、添付図面とともに以下の説明を参照することによって、より明らかになり、よりよく理解されるであろう。
【図１Ａ】図１Ａは、本発明の実施態様による、クライアントにホストサービスへの信頼できる接続を提供するシステムのブロック図である。
【図１Ｂ】図１Ｂは、本発明の実施態様による、クライアントにホストサービスへの信頼できる接続を提供するシステムのブロック図である。
【図２Ａ】図２Ａは、本発明の実施態様による、ネットワーク上で行われる通信を示す。
【図２Ｂ】図２Ｂは、本発明の別の実施態様による、ネットワーク上で行われる通信を示す。
【図３】図３は、本発明の実施態様による、ネットワーク上での通信のための第１のプロトコル内において複数の第２のプロトコルをカプセル化する過程を示す。
【図４】図４は、本発明による図１A〜１Bの通信システムの動作の実施態様を図解する流れ図である。
【図５Ａ】図５Ａは、本発明により構成される通信システムの別の実施態様を示すブロック図である。
【図５Ｂ】図５Ｂは、本発明による図５Aの通信システムの動作の実施態様を図解する流れ図である。
【図６Ａ】図６Ａは、本発明の実施態様によるクライアントをホストサービスに再接続するための構成要素をさらに含む、図１Ａの例示的システムのブロック図である。
【図６Ｂ】図６Ｂは、本発明の別の実施態様によるクライアントをホストサービスに初期に接続するための構成要素をさらに含む、図６Ａの例示的システムのブロック図である。
【図６Ｃ】図６Ｃは、本発明の別の実施態様によるクライアントをホストサービスに初期に接続し、クライアントをホストサービスに再接続するための構成要素をさらに含む、図６Ｂの例示的システムのブロック図である。
【図６Ｄ】図６Ｄは、図６Ｃのシステムの代替となる実施態様を示すブロック図である。
【図７】図７は、本発明の実施態様によるネットワーク通信のための方法を示す流れ図である。
【図８Ａ】図８Ａは、本発明の実施態様によるクライアントを複数のホストサービスに接続するための方法を示す流れ図である。
【図８Ｂ】図８Ｂは、本発明の実施態様によるクライアントを複数のホストサービスに接続するための方法を示す流れ図である。
【図８Ｃ】図８Ｃは、本発明の実施態様によるクライアントを複数のホストサービスに接続するための方法を示す流れ図である。
【図９】図９は、本発明の実施態様によるクライアントにホストサービスへの信頼できる接続を提供し、クライアントをホストサービスに再接続するための方法を示す流れ図である。
【図１０Ａ】図１０Ａは、本発明の実施態様によるクライアントをホストサービスに再接続するための方法を示す流れ図である。
【図１０Ｂ】図１０Ｂは、本発明の実施態様によるクライアントをホストサービスに再接続するための方法を示す流れ図である。
【技術分野】
【０００１】
本発明は、概してネットワーク通信に関する。より具体的には、本発明は、セッションの持続化および信頼性を提供するため、カプセル化通信プロトコルを使用してネットワークコンポーネントをセキュアに横断することにより、クライアント通信を再確立するシステムおよび方法に関する。
【背景技術】
【０００２】
２台のコンピュータ、例えばクライアントおよびサーバの間のネットワーク上における通信は、様々な周知の通信プロトコルを使用して実施されうる。概して、クライアントはサーバからネットワーク上でコンテンツをダウンロードするためにサーバと通信を行う。例えば、サーバはクライアントによりアクセス可能な１つ以上のアプリケーションをホスティングすることがある。さらに、クライアントは、概してルータまたはファイアウォール等の、サーバからのコンテンツが通過するセキュリティゲートウェイであるプロキシを介してサーバと通信を行うことがある。また、サーバは、そのサーバとの未許可の通信のやりとりを禁止するためファイアウォールを含むことがある。クライアントは、プロキシのセキュリティおよびサーバのファイアウォールを経由してサーバおよびサーバのコンテンツにアクセスする。しかしながら、多くの場合、プロキシを介してサーバまで行き着くネットワーク接続は断絶しやすい。例えば、クライアントとプロキシの間の無線接続は、多くの場合信頼できない。その他、ネットワーク接続が断続的となる場合がある。そのため、エレベーターまたはトンネルに入ると接続が失われ、そのエレベーターまたはトンネルから出ないかぎり回復できない場合がある。
【０００３】
クライアントおよびサーバコンピュータの間に確立された通信セッションが異常終了すると、クライアントは概して新しい通信セッションを開始することにより接続を再確立しなければならない。新しい通信セッションを始めるためには、ユーザーが新しい通信セッションに許可されるよう、ユーザーは概して、ログイン／パスワードのペア等の認証証明書をプロキシおよびサーバコンピュータへ再伝送しなければならない。この多数の通信セッションにわたるユーザーの認証証明書の再伝送は、そのユーザーの認証証明書を潜在的攻撃者に対し繰り返し露呈し、それによって認証証明書のセキュリティレベルを低下させる。さらに、攻撃者がプロキシのセキュリティまたはサーバのファイアウォールをバイパスした場合、その攻撃者は追加セキュリティに遭遇することなしにサーバのコンテンツにアクセスすることができる。また、ユーザーに認証証明書を再入力させることは、多くの場合、ユーザーにフラストレーションおよび不便さをもたらす時間のかかるプロセスである。
【０００４】
現在の多くのプロトコルを使用してネットワーク接続で通信を行う際、ネットワーク接続が中断した場合にはデータパケットが失われる。例えば、標準的なＴＣＰネットワーク接続を介して通信を行う場合、データバッファは概して接続の中断とともに消去される。そのため、ネットワーク接続が回復すると、サーバ上のユーザーセッションのようなネットワーク化アプリケーションは中断前の状態から再開することができない。概してエラーメッセージが表示され、ユーザーに不便さに対するフラストレーションを与えることになる。さらに、多くのプロトコルを使用するネットワーク上での通信では、トランスポート接続の再確立を必要とすることが多い。例えば、ＨＴＴＰを単独でまたはプロキシプロトコルと併せて使用し、標準的なＴＣＰ接続でウェブサイトを閲覧するには、各リソースに対する新しいＨＴＴＰ接続に加えて、以前のＴＣＰ／プロキシプロトコル接続を閉じて、各リソースに対する新しいＴＣＰ／プロキシプロトコル接続を開く必要がある。
【０００５】
従って、クライアントの認証証明書の再伝送を繰り返す必要がなく、また未許可のユーザーからのサーバ保護を高めながら、クライアントコンピュータとサーバコンピュータの間に通信セッションを再確立するための技術を提供することが望ましい。多数のネットワークコンポーネントをセキュアに横断するため、認証証明書の再伝送を繰り返す必要なくクライアントコンピュータとサーバコンピュータの間に通信セッションを再確立する、より高度なシステムおよび方法が必要とされる。
【発明の開示】
【課題を解決するための手段】
【０００６】
本発明は、クライアントをホストサービスとの持続的で信頼できる接続に再接続するためのシステムおよび方法に関し、その接続はネットワークコンポーネントをセキュアに横断する。クライアントの再接続は、クライアントのホストサービスへの接続の再確立と、クライアントとホストサービスの間にある１つ以上の接続の再認証を含む、クライアントのユーザーのホストサービスに対する再認証を含む。ホストサービスへの持続的で信頼できる接続は、クライアントを代表する１つ以上の第１のプロトコルサービスにより維持される。第１のプロトコルサービスは、クライアントとホストサービスの間で通信されるデータがバッファリングされ、クライアントとホストサービスの間にあるネットワーク接続におけるいかなる中断の間も維持されることを確実にする。ネットワーク接続における一時的な中断は、例えば、モバイルクライアント等のクライアントが同じネットワーク内の異なるアクセスポイント間でローミングを行う際、またはクライアントがネットワークを（例えば、有線ネットワークから無線ネットワークへ）切り替える際に起こりうる。
【０００７】
ネットワーク中断の間バッファリングされたデータを維持することに加え、第１のプロトコルサービスは、クライアントの第１のプロトコルサービスへの接続を再確立する際に、ホストサービスに対しクライアントを再認証する。これはクライアントのユーザーがそのホストサービスとの接続を再確立するために認証証明書を再入力するのを防止する。さらに、クライアントとホストサービスの間にある多数の接続のそれぞれは、ホストサービスへのアクセスにおいて追加セキュリティ保護を提供するために、例えばプロキシとして作用する第１のプロトコルサービスを介して再認証される。再認証後、第１のプロトコルサービスはクライアントの接続ホストサービスに再度リンクする。要約すると、本発明は、サーバに対するネットワークコンポーネントをセキュアに横断するため、またユーザーが認証証明書を再入力することなく、クライアントとホストサービスの間にあるネットワーク接続の再確立を提供するものである。
【０００８】
一局面において、本発明はクライアントとホストサービスを再接続するための方法に関する。前記方法は、クライアントと第１のプロトコルサービスの間にある第１の接続および第１のプロトコルサービスとホストサービスの間にある第２の接続を介し、クライアントおよびホストサービスの間に通信セッションを提供するステップを含む。前記方法は、第１の接続および第２の接続のうち一方における中断を検出し、第１の接続および第２の接続のうちもう一方を維持するステップをさらに含む。前記方法の別のステップにおいて、第１のプロトコルサービスは第１のチケットおよび第２のチケットを得て、中断した接続を再確立するために第１のチケットを有効にする。第１のプロトコルサービスは維持された接続の使用を継続するために第２のチケットを有効にし、再確立された接続を維持された接続にリンクする。
【０００９】
一実施態様において、前記方法は中断した接続において、中断の間、通信セッションを維持するステップを含む。別の実施態様において、前記方法は前記第１のプロトコルサービスおよびチケットオーソリティのうち少なくとも１つによって、前記第１のチケットおよび前記第２のチケットのうちいずれか１つを生成するステップをさらに含む。前記方法は、前記チケットオーソリティによって、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを有効にするステップを含んでよい。
【００１０】
別の実施態様において、前記方法は、ウェブサーバに対しクライアントを認証するステップと、ウェブサーバによって、前記第１のチケットを前記クライアントへ伝送するステップとをさらに含む。前記方法は、前記ホストサービスによって、通信セッションの確立時に前記クライアントを認証するステップをさらに含んでよい。一実施態様において、前記方法は、前記クライアントによって、前記第１のチケットを前記第１のプロトコルサービスへ伝送するステップを含む。
【００１１】
さらなる実施態様において、前記第１のプロトコルサービスはプロキシサーバを含む。別の実施態様において、前記第１のプロトコルサービスはセキュリティゲートウェイを含む。前記方法は、第２のプロトコルをカプセル化する第１のプロトコルを使用して通信を行う前記クライアントおよび前記第１のプロトコルサービスと、前記第２のプロトコルを使用して通信を行う前記第１のプロトコルサービスおよび前記ホストサービスとをさらに含んでよい。
【００１２】
別の実施態様において、前記第１のチケットは前記第１の接続に有効であり、前記第２のチケットは前記第２の接続に有効である。任意で、前記第２のチケットは、前記第１のチケットが有効にされるまで使用不可能であってよい。一実施態様において、前記再確立された接続は、前記第１のチケットおよび前記第２のチケットが有効にされた後、前記維持された接続にリンクされる。
【００１３】
さらなる実施態様において、前記第１の接続および前記第２の接続のうちいずれかまたは両方が、中間ノードおよび１つ以上の第１のプロトコルサービスのうちいずれか１つを介して接続された複数の接続を含んでよい。前記方法は、前記複数の接続のうち少なくとも１つのために第３のチケットを生成するステップをさらに含んでよい。前記第３のチケットは、前記複数の接続のうち少なくとも１つに有効であってよい
別の局面において、本発明はクライアントをホストサービスに再接続するためのシステムに関する。前記システムは、クライアントおよび第１のプロトコルサービスを含む。前記クライアントは、第１の接続を介しホストサービスとの通信セッションを確立する。前記第１のプロトコルサービスは、前記クライアントとの前記第１の接続および前記ホストサービスとの第２の接続を確立する。前記第１のプロトコルサービスは、前記第１の接続および前記第２の接続のうち少なくとも１つを含む接続を維持する。さらに、前記第１のプロトコルサービスは、前記第１の接続および前記第２の接続のうち一方において中断した接続を再確立するために第１のチケットを有効にし、前記第１の接続および前記第２の接続のうちもう一方を使用するために第２のチケットを有効にする。前記システムは、前記再確立された接続を前記維持された接続にリンクする前記第１のプロトコルサービスをさらに含む。
【００１４】
一実施態様において、前記システムは前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを生成するチケットオーソリティをさらに含む。別の実施態様において、前記第１のプロトコルサービスは、前記中断した接続において、中断の間、前記通信セッションを維持する。さらなる実施態様において、前記第１のプロトコルサービスは、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを生成する。前記システムは、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを有効にする前記チケットオーソリティを含んでよい。
【００１５】
別の実施態様において、前記システムはウェブサーバをさらに含む。前記ウェブサーバは前記クライアントを認証し、一実施態様において、前記第１のチケットを前記クライアントに伝送する。さらなる実施態様において、前記クライアントは前記第１のチケットを前記第１のプロトコルサービスに伝送する。さらに別の実施態様において、前記ホストサービスは前記通信セッションの確立時に前記クライアントを認証する。
【００１６】
一実施態様において、前記第１のプロトコルサービスはプロキシサーバを含み、別の実施態様において、前記第１のプロトコルサービスはセキュリティゲートウェイを含む。前記システムは、第２のプロトコルをカプセル化する第１のプロトコルを使用して通信を行う前記クライアントおよび前記第１のプロトコルサービスと、前記第２のプロトコルを使用して通信を行う前記第１のプロトコルサービスおよび前記ホストサービスとを含んでよい。
【００１７】
さらなる実施態様において、前記第１のチケットは前記第１の接続に有効であり、前記第２のチケットは前記第２の接続に有効である。また、前記第２のチケットは、前記第１のチケットが有効にされるまで使用不可能であってよい。一実施態様において、前記第１のプロトコルサービスは、前記第１のチケットおよび前記第２のチケットが有効にされた後、前記再確立された接続を前記維持された接続にリンクする。
【００１８】
さらなる実施態様において、前記第１の接続および前記第２の接続のうちいずれか１つは、中間ノードおよび１つ以上の第１のプロトコルサービスのうちいずれか１つを介して接続された複数の接続を含む。前記システムは、前記複数の接続のうち少なくとも１つのために第３のチケットの生成をさらに含み、一実施態様において、前記第３のチケットは、前記複数の接続のうち少なくとも１つに対し有効である。
【００１９】
付随する図面および以下の説明において、本発明の様々な実施態様を詳しく説明する。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の特定の実施態様について説明する。しかし、本発明は、これらの実施態様に限定されるものではなく、本願明細書に明白に開示した内容への追加および変更が本発明の範囲に明白に含まれることを意図していることに留意されたい。さらに、本願明細書に開示される種々の実施態様の特徴は排他的でなく、本願明細書に組み合わせまたは置き換えが明示されていなくても、本発明の精神と範囲から逸脱することなくそのような組み合わせおよび置き換えが存在しうると理解されたい。
【００２１】
本発明の具体例は、クライアントとホストサービスの間に確実で持続的な接続を確立し、接続において中断がある場合に接続を再接続するシステムおよび方法を提供する。クライアントはクライアントと第１のプロトコルサービスの間の第１の接続および第１のプロトコルサービスとホストサービスの間の第２の接続を介してホストサービスと通信セッションを確立する。クライアントは第１のプロトコルを使用して第１のプロトコルサービスと通信を行い、第１のプロトコルサービスは第２のプロトコルを使用してホストサービスと通信を行う。第２のプロトコルはクライアントから第１のプロトコル通信内でカプセル化された第１のプロトコルへの通信を行う。第１の接続または第２の接続いずれかにおいて中断が検出された場合、第１のプロトコルサービスは、中断されていない接続を維持しながら、中断された接続を再確立する。中断された接続は、クライアントをホストサービスに再接続するため、維持された接続とリンクされる。
【００２２】
さらに、本発明の具体例は、クライアントのホストサービスへの接続確立および再接続においてネットワークコンポーネントをセキュアに横断するシステムおよび方法を提供する。第１のプロトコルサービスはクライアントとホストサービスの間のプロキシとして作用することができ、セキュリティゲートウェイを含んでもよい。第１のプロトコルサービスはチケットオーソリティより第１のチケットおよび第２のチケットを得る。第１のチケットはクライアントと第１のプロトコルサービスの間の接続を有効にするために使用され、第２のチケットは第１のプロトコルサービスとホストサービスの間の接続を有効にするために使用される。第２のチケットは、第１のチケットが有効にされるまで使用不可能であってよい。第１のプロトコルサービスは第１のチケットを、第１の接続の使用の再確立または維持において有効にし、第２のチケットを、第２の接続の使用の再確立および維持において有効にする。第１および第２のチケットが有効にされ接続が再確立されると、第１のプロトコルサービスは、クライアントのホストサービスとの通信セッションを維持するため、第１の接続を第２の接続にリンクする。追加のチケットが生成され、ユーザーの追加通信、またはクライアントとホストサービスの間の「ホップ」を再確立または維持してもよい。このようにして、クライアントとホストサービスの間の各通信または「ホップ」は有効にされる。
【００２３】
図１Ａを参照すると、概して本発明は、ネットワーク通信に関し、特にクライアントへのホストサービスとの信頼できる接続の提供に有用となりうる。概観すると、ネットワーク通信のシステム１００は、ネットワーク１０４上で第１のプロトコルサービス１１２（例えば、第２のコンピュータ）と通信を行うクライアント１０８（例えば、第１のコンピュータ）を含む。またシステム１００は、ホストノード１８８上にあり、第１のプロトコルサービス１１２と通信を行い、第１のプロトコル１１２を経由してネットワーク１０４上でクライアント１０８と通信を行う複数のホストサービス１１６ａ乃至１１６ｎ（例えば、第３のコンピュータ）も含む。あるいは、本発明の別の実施態様では、図１Ｂを参照すると、第１のプロトコルサービス１１２およびホストサービス１１６ａ乃至１１６ｎは、独立したコンピュータとして使用されるのではなく、むしろ図１Ａのように、例えばホストノード１１８aのような同じコンピュータに組み込まれる。図１Ｂにおいて、ホストサービス１１６ａ乃至１１６ｎは、ネットワーク１０４’上で第１のプロトコルサービス１１２と通信を行う。システム１００は、１つ、２つ、または多数のホストノード１１８ａ乃至１１８ｎを含むことができる。
【００２４】
一実施態様において、図１Ｂに示すように、ネットワーク１０４および１０４’は独立したネットワークである。図１Ａに示すように、ネットワーク１０４および１０４’は同じネットワーク１０４とすることができる。一実施態様では、ネットワーク１０４および／またはネットワーク１０４’は、例えば、会社のイントラネットのようなローカルエリアネットワーク（ＬＡＮ）または、例えば、インターネットまたはワールドワイドウェブのようなワイドエリアネットワーク（ＷＡＮ）である。クライアント１０８、第１のプロトコルサービス１１２、ホストサービス１１６ａ乃至１１６ｎ、および／またはホストノード１１８ａ乃至１１８ｎは、これらに限定されないが、標準電話回線、ＬＡＮまたはＷＡＮのリンク（例えば、８０２．１１、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、ブロードバンド接続（例えば、ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）、無線接続、あるいはこれらのいずれかまたはすべてを組み合わせたものなど、様々な接続を介してネットワーク１０４および／またはネットワーク１０４’に接続することができる。
【００２５】
クライアント１０８は第１のプロトコルサービス１１２とクライアント‐第１のプロトコルサービス間通信チャネル１３５上で通信を行っており、またクライアント‐ウェブサーバ間通信チャネル１４０上でウェブサーバ１２０とも通信を行っている。第１のプロトコルサービス１１２は第１のプロトコルサービス‐オーソリティ間通信チャネル１４５でチケットオーソリティ１３６と通信を行っており、ウェブサーバ１２０はウェブサーバ‐オーソリティ間通信チャネル１５０上でチケットオーソリティ１３６と通信を行っている。第１のプロトコルサービス１１２は第１のプロトコルサービス‐サーバ間通信チャネル１２４ａ乃至１２４ｎ上でホストノード１１８とも通信を行っている。別の実施態様において、ウェブサーバ１２０はエージェント‐サーバ間通信チャネル１５５上でホストノード１１８と通信を行うことができる。同様に、ホストノード１１８はチケット‐サーバ間通信チャネル１５７上でチケットオーソリティ１３６と通信を行うことができる。一実施態様において、それぞれの通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４４、１５０、１５５、１５７は、ネットワーク１０４上に確立される。
【００２６】
通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４４、１５０、１５５、１５７の実施例は、標準電話回線、ＬＡＮまたはＷＡＮのリンク（例えば、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、ブロードバンド接続（ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）、および無線接続を含む。通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４４、１５０、１５５、１５７上での接続は、様々な通信プロトコル（例えば、ＨＴＴＰ、ＨＴＴＰＳ、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＰＸ、ＮｅｔＢＩＯＳ、イーサネット（登録商標）、ＲＳ２３２、メッセージングアプリケーションプログラミングインターフェイス（ＭＡＰＩ）プロトコル、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、ユーザーデータグラムプロトコルスキーム用リアルタイムストリーミングプロトコル（ＲＴＳＰＵ）、ＲｅａｌＮｅｔｗｏｒｋｓ社（Ｓｅａｔｔｌｅ、ＷＡ）製のＰｒｏｇｒｅｓｓｉｖｅ Ｎｅｔｗｏｒｋｓ Ｍｕｌｔｉｍｅｄｉａ（ＰＮＭ）プロトコル、マニュファクチャリングメッセージスペシフィケーション（ｍａｎｕｆａｃｔｕｒｉｎｇ ｍｅｓｓａｇｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＭＭＳ）プロトコル、および直接非同期接続等）を使用して確立される。
【００２７】
別の局面において、図１Aはコンテンツを渡してもらうための通信システム１００の実施態様のブロック図を示す。一実施態様において、第１のプロトコルサービス１１２はプロキシ１１５を備え、システム１００はウェブサーバ１２０およびチケットオーソリティ１３６を含む。システム１００は、ホストノード１１８へ／からの未許可の通信を禁止する２つのファイアウォール１６０、１６１も含む。ファイアウォール１６０、１６１の間のネットワークは多くの場合「非武装地帯」（DＭＺ）１３０と称される。一実施態様において、ＤＭＺ１３０はプロキシ１１５およびウェブサーバ１２０を備えるチケットプロトコルサービス１１２を含む。
【００２８】
ＤＭＺ１３０はホストサービス１１６ａ乃至１１６ｎを未許可の個人によりアクセス可能なシステム１００の構成要素（例えば、第１のプロトコルサービス１１２）から分離する。上述のように、ＤＭＺ１３０は未許可の通信を禁止する２つのファイアウォール１６０、１６１で線引きされている。第１のファイアウォール１６０および第２のファイアウォール１６１はそれぞれポリシールール一式を適用し、どのメッセージがＤＭＺ１３０を横断しうるか判断する。一実施態様において、第１のファイアウォール１６０および第２のファイアウォール１６１は同じポリシールール一式を適用する。あるいは、第１のファイアウォール１６０および第２のファイアウォール１６１は、異なるポリシールール一式を適用してもよい。各ファイアウォール１６０、１６１は、ルータ、コンピュータ、またはその他任意のネットワーク制御装置であってよい。別の実施態様において、システム１００はファイアウォール１６０、１６１のいずれか１つを含むか、またはファイアウォール１６０、１６１いずれも含まない。別の実施態様において、ファイアウォール１６０、１６１のうちいずれかがホストノード１１８上に配置されている。別の実施態様（図示なし）において、ファイアウォール１６０、１６１のうち１つ以上が中間ノードに配置されている。
【００２９】
一実施態様において、第１のプロトコルサービス１１２は、メッセージがクライアント‐第１のプロトコルサービス間通信チャネル１３５上で通過すべきセキュリティゲートウェイを備えるプロキシ１１５を含む。一実施態様において、ネットワークファイアウォール１６０は、クライアント‐第１のプロトコルサービス間通信チャネル１３５からの、その宛先として第１のプロトコルサービス１１２を持たないいかなる着信メッセージも拒否する。同様に、ネットワークファイアウォール１６０は、その発信元が第１のプロトコルサービス１１２でない限り、クライアント‐第１のプロトコルサービス間通信チャネル１３５へのいかなる送信メッセージも拒否する。第１のプロトコルサービス１１２のプロキシ１１５として図示されているが、セキュリティゲートウェイは代替としてルータ、ファイアウォール、中継器、または必要なセキュア性を提供できる任意のネットワークコンポーネントであってよい。別の実施態様において、プロキシ１１５は第１のプロトコルサービス１１２の同じコンピュータまたは異なるコンピュータ上で動作できる第１のプロトコルサービス１１２から分離したネットワークコンポーネントである。例えば、図１Ｂにおいて、プロキシ１１５は第１のプロトコルサービス１１２から分離されている。プロキシ１１５はウェブサーバ１２０とともにＤＭＺ１３０内にある。第１のプロトコルサービス１１２の多数の例がホストノード１１８ａ乃至１１８ｎのそれぞれにおいて動作している。各第１のプロトコルサービス１１２は通信チャネル１３５上でプロキシ１１５と通信を行い、これがクライアント‐第１のプロトコルサービス間通信チャネル１３５である。この場合、プロキシ１１５の要素はセキュアにクライアント１０８と第１のプロトコルサービス１１２の間の通信を通過するための中間段階である。
【００３０】
ネットワーク１０４は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、またはインターネットやワールドワイドウェブ（すなわちウェブ）等のネットワークのネットワークであってよい。各通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４５、１５０、１５５、１５７は、それぞれ異なるネットワークの一部であってよい。例えば、クライアント‐第１プロトコルサービス間通信チャネル１３５は第１のネットワーク（例えば、ワールドワイドウェブ）に属してよく、クライアント‐ウェブサーバ間通信チャネル１４０は第２のネットワーク（例えば、保護されたエクストラネットまたは仮想プライベートネットワーク（ＶＰＮ））に属してよい。別の実施態様において、ネットワーク１０４はサーバファーム１６９と同様にＤＭＺ２３０におよび、全体にわたり同じ通信プロトコルが使用される。同じ実施態様において、ファイアウォール１６０が第１のプロトコルサービス１１２およびウェブサーバ１２０をホストノード１１８およびチケットオーソリティ１３６から分離しない。
【００３１】
通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４４、１５０、１５５、１５７の実施例は、標準電話回線、ＬＡＮまたはＷＡＮのリンク（例えば、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、ブロードバンド接続（ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）、および無線接続を含む。通信チャネル１２４ａ乃至１２４ｎ、１３５、１４０、１４４、１５０、１５５、１５７上での接続は、様々な通信プロトコル（例えば、ＨＴＴＰ、ＨＴＴＰＳ、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＰＸ、ＮｅｔＢＩＯＳ、イーサネット（登録商標）、ＲＳ２３２、メッセージングアプリケーションプログラミングインターフェイス（ＭＡＰＩ）プロトコル、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、ユーザーデータグラムプロトコルスキーム用リアルタイムストリーミングプロトコル（ＲＴＳＰＵ）、ＲｅａｌＮｅｔｗｏｒｋｓ社（Ｓｅａｔｔｌｅ、ＷＡ）製のＰｒｏｇｒｅｓｓｉｖｅ Ｎｅｔｗｏｒｋｓ Ｍｕｌｔｉｍｅｄｉａ（ＰＮＭ）プロトコル、マニュファクチャリングメッセージスペシフィケーション（ｍａｎｕｆａｃｔｕｒｉｎｇ ｍｅｓｓａｇｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＭＭＳ）プロトコル、および直接非同期接続等）を使用して確立されることができる。
【００３２】
クライアント１０８は、任意のワークステーション、デスクトップコンピュータ、ラップトップ、ハンドヘルドコンピュータ、携帯電話、スマート端末またはダム端末、ネットワークコンピュータ、無線機器、情報家電、ミニコンピュータ、大型汎用コンピュータ、または通信が可能で、本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する他の形態のコンピュータまたはテレコミュニケーション装置とすることができる。さらに、クライアント１０８は、ローカルネットワーク１０４上のローカルデスクトップクライアントであってよく、または分離したネットワーク１０４’であってもよい。クライアント１０８は、例えば視覚的表示装置（例えば、コンピュータ用モニタ）、データ入力装置（例えば、キーボード）、持続的および／または揮発性記憶装置（例えば、コンピュータメモリ）、プロセッサ、およびマウスを含むことができる。クライアント１０８にサポートされるオペレーティングシステムは、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）のオペレーティングシステムであるＷＩＮＤＯＷＳ（登録商標）シリーズのいずれか、Ｍａｃｉｎｔｏｓｈオペレーティングシステム、Ｊａｖａ（登録商標）ＯＳ、および多種にわたるＵＮＩＸ（登録商標）（例えばＳｏｌａｒｉｓ、ＳｕｎＯＳ、Ｌｉｎｕｘ、ＨＰ−ＵＸ、Ａ／ＩＹおよびＢＳＤベースのディストリビューション）、または本願明細書に記載の動作の実行においてクライアント１０８をサポート可能なその他任意のオペレーティングシステムを含むことができる。
【００３３】
一実施態様において、クライアント１０８は、ウェブに接続するためにＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＩＮＴＥＲＮＥＴ ＥＸＰＬＯＲＥＲのようなウェブブラウザ１６２を含む。さらなる実施態様において、ウェブブラウザ１６２はウェブサーバ１２０に対するセキュアなクライアント‐ウェブサーバ間通信チャネル１４０を確立するため、既存のセキュアソケットレイヤー（ＳＳＬ）サポートを使用する。ＳＳＬは、Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ社（Ｍｏｕｎｔａｉｎ Ｖｉｅｗ、Ｃａｌｉｆｏｒｎｉａ）が開発し、インターネット技術特別調査委員会（ＩＥＴＦ）が広めた現在の標準である。
【００３４】
一部の実施態様においては、図１Ａおよび１Ｂに示すように、クライアントエージェント１２８がクライアント１０８内に含まれる。クライアントエージェント１２８は、クライアント‐第１のプロトコルサービス通信チャネル１３５上でホストサービス１１６ａ乃至１１６ｎとの通信を確立し交信を行うために使用されてよい。クライアントエージェント１２８は、例えばソフトウェアプログラムおよび／または例えば、ＡＳＩＣまたはＦＰＧＡなどのようなハードウェア装置として使用することができる。クライアントエージェント１２８は、あらゆるタイプのプロトコルを使用することができ、それには、例えば、ＨＴＴＰクライアントエージェント、ＦＴＰクライアントエージェント、Ｏｓｃａｒクライアントエージェント、Ｔｅｌｎｅｔクライアントエージェントが挙げられる。一実施態様において、クライアントエージェント１２８はＣｉｔｉｒｉｘ Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ Ｌａｕｄｅｒｄａｌｅ、Ｆｌｏｒｉｄａ）製のＩＣＡクライアントであり、これを以下ＩＣＡクライアント１２８と称する。クライアントエージェント１２８の他の実施態様は、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｏｔｎ）製のＲＤＰクライアント、従来型のクライアントサーバアプリケーションにおけるデータ入力クライアント、Ａｃｔｉｖｅ ＸコントロールまたはＪａｖａ（登録商標）アプレットを含む。一部の実施態様において、クライアントエージェント１２８は、それ自体が第１のプロトコルを使用して通信を行うよう構成される。一部の実施態様では（図示せず）、クライアント１０８は、複数のクライアントエージェント１２８ａ乃至１２８ｎを含み、それぞれがホストサービス１１６ａ乃至１１６ｎとそれぞれ通信を行う。さらに、ホストサービス１１６ａ乃至１１６ｎ上で実行するアプリケーションのアウトプットは、例えばクライアントエージェント１２８またはウェブブラウザ１６２を介してクライアント１０８に表示される。
【００３５】
別の実施態様において、スタンドアロンのクライアントエージェントは、第１のプロトコルを使用してクライアント１０８が通信できるように構成される。スタンドアロンのクライアントエージェントは、クライアント１０８内に組み込むか、または代わりに、スタンドアロンのクライアントエージェントをクライアント１０８から独立させることができる。スタンドアロンのクライアントエージェントは、例えば、ローカルホストのプロキシである。一般に、スタンドアロンのクライアントエージェントは、クライアントエージェント１２８に関する本願明細書に開示された機能のいずれかを実行することができる。
【００３６】
同様に、図１Ａを参照して、第１のプロトコルサービス１１２とホストサービス１１６ａ乃至１１６ｎのそれぞれは、通信が可能で本願明細書に開示した動作を行うのに十分なプロセッサ能力とメモリ容量を有する、任意のコンピュータ上で提供されることができる。あるいは、例えば図１Ｂのようにホストノード１１８ａ乃至１１８ｎのいずれかのような、第１のプロトコルサービス１１２およびホストサービス１１６ａ乃至１１６ｎの機能性が同じコンピュータに組み込まれている場合、第１のプロトコルサービス１１２および／またはホストサービス１１６ａ乃至１１６ｎは汎用コンピュータおよび／または、例えば、ＡＳＩＣまたはＦＰＧＡのような特殊用途向けハードウェア装置上で実行されるソフトウェアプログラムとしてとして使用することができる。
【００３７】
クライアント１０８と同様に、ホストノード１１８ａ乃至１１８ｎのそれぞれは上述した通信が可能で本願明細書に開示した動作を行うのに十分なプロセッサ能力とメモリ容量を有する任意のコンピュータ（例えばパーソナルコンピュータ）であってよい。ホストノード１１８ａ乃至１１８ｎのそれぞれは、様々な通信プロトコル（例えばＩＣＡ、ＨＴＴＰ、ＴＣＰ／ＩＰおよびＩＰＸ）、ＳＰＸ、ＮｅｔＢＩＯＳ、イーサネット（登録商標）、ＲＳ２３２、直接非同期接続を使用して通信チャネル１２４ａ乃至１２４ｎ上に通信を確立することができる。
【００３８】
一実施態様において、ホストサービス１１６ａ乃至１１６ｎのそれぞれは、クライアント１０８に対して遠隔で利用可能な１つ以上のアプリケーションプログラムをホストする。クライアント１０８に対して利用可能にされたアプリケーションを、公開されたアプリケーションと称する。１つまたは複数のホストサービス１１６ａ乃至１１６ｎが同じアプリケーションプログラムをホストすることができる。このようなアプリケーションの例には、ＭＩＣＲＯＳＯＦＴ ＷＯＲＤなどのワード処理プログラム、およびＭＩＣＲＯＳＯＦＴ ＥＸＣＥＬなどの表計算プログラムなどが挙げられ、そのどちらもＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｏｔｎ）から入手可能である。一部またはすべてのホストサービス１１６ａ乃至１１６ｎがホスト可能な他のアプリケーションプログラムの例には、財務報告プログラム、顧客登録プログラム、技術的なサポート情報を提供するプログラム、顧客データベースアプリケーション、およびアプリケーションの設定マネージャが挙げられる。さらに、一実施態様では、ホストサービス１１６ａ乃至１１６ｎのうち１つ以上は、ストリーミングオーディオおよび／またはストリーミングビデオをクライアント１０８に提供するオーディオ／ビデオストリーミングサーバである。別の実施態様では、ホストサービス１１６ａ乃至１１６ｎは、一部／すべてのファイルタイプをクライアント１０８に提供するファイルサーバを備える。一実施態様では、ホストサービス１１６ａ乃至１１６ｎは、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ Ｌａｕｄｅｒａｌｅ、Ｆｌｏｒｉｄａ）製のＩＣＡまたはＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＲＤＰのようなプレゼンテーションプロトコルを使用して、クライアント１０８と通信を行うことができる。
【００３９】
さらなる実施態様において、ホストノード１１８はサーバファーム１６９または単一エンティティとして管理される１つ以上のサーバの論理グループであるサーバネットワークの一部である。一実施態様において、サーバファーム１６９は多数のホストノード１１８ａ乃至１１８ｎ（概して１１８）を含む。図１Ｂに示される形態は３つのホストノード１１８ａ乃至１１８ｎを有しているが、サーバファーム１６９はホストノード１１８またはサーバをいくつでも有することができる。他の実施態様において、サーバファーム１６９は、企業イントラネット、仮想プライベートネットワーク（ＶＰＮ）、またはセキュアなエクストラネット等、未許可の個人によるアクセス不可能な、保護されたネットワークである。また、サーバファーム１６９を構成するサーバは、上記プロトコルのいずれかを使用して、上述したネットワーク（例えばＷＡＮ、ＬＡＮ）のいずれかで通信を行うことができる。
【００４０】
図１Ａに示されるチケットオーソリティ１３６は、サーバファーム１６９の一部であり、クライアント１０８に対して認証を行うために１つ以上のチケットを発行する。特に、チケットオーソリティ１３６は、認証証明書に基づき、１つの通信チャネル（すなわち、クライアント‐ウェブサーバ間通信チャネル１４０）上でクライアント１０８の認証を可能にする。チケットオーソリティ１３６はさらに、その他の通信チャネルにおいて繰り返し認証証明書を提供することなく、クライアント１０８が別の通信チャネル（すなわち、クライアント‐第１のプロトコルサービス通信チャネル１３５）上で認証されることを可能にする。
【００４１】
一実施態様において、チケットオーソリティ１３６はスタンドアロンのネットワークコンポーネントである。他の実施態様において、モジュールチケットオーソリティ１３６は１つ以上のホストノード１１８にあるソフトウェアモジュールである。例えば、図１Ｂに示されるように、ホストノード１１８ａ乃至１１８ｎのそれぞれに対しチケットオーソリティ１３６があってよい。この実施態様において、ウェブサーバ１２０は、エージェント‐サーバ間通信チャネル１５５上でチケットオーソリティ１３６および／またはホストノード１１８と通信を行うことができる。別の実施態様において、チケットオーソリティ１３６はホストノード１１８ａ乃至１１８ｎのいずれからも分離された中間ノードにあってよい。
【００４２】
一実施態様において、チケットオーソリティ１３６は第１のチケットおよび第２のチケットを生成する。一部の実施態様において、チケットはいずれもその場限りのものである。さらなる実施態様において、チケットは適切に乱数度をシードされた暗号化乱数発生器を使用して生成される。第１のチケットはクライアント１０８に伝送され、クライアント１０８と第１のプロトコルサービス１１２の間に第１の通信セッションを確立するために使用される。第２のチケットは第１のプロトコルサービス１１２に伝送され、第１のプロトコルサービス１１２とホストノード１１８の間に第２の通信セッションを確立するために使用される。
【００４３】
一実施態様において、ウェブサーバ１２０はウェブページをクライアント１０８に配信する。ウェブサーバ１２０は、任意のパーソナルコンピュータ（例えば、Ｍａｃｉｎｔｏｓｈコンピュータ、Ｉｎｔｅｌ社（Ｓａｎｔａ Ｃｌａｒａ、Ｃａｌｉｆｏｒｎｉａ）製のＩｎｔｅｌマイクロプロセッサを搭載したパーソナルコンピュータ、Ａｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ社（Ｓｕｎｎｙｖａｌｅ、Ｃａｌｉｆｏｒｎｉａ）製のＡＭＤを搭載したパーソナルコンピュータ等）、Ｗｉｎｄｏｗｓ（登録商標）ベースの端末、ネットワークコンピュータ、ワイヤレス機器（例えば携帯電話）、情報家電、ＲＩＳＣ Ｐｏｗｅｒ ＰＣ、Ｘ−ｄｅｖｉｃｅ、ワークステーション、ミニコンピュータ、大型汎用コンピュータ、携帯情報端末、またはクライアント１０８とのセキュアなクライアント‐ウェブサーバ間通信チャネル１４０を確立できるその他の通信機器であってよい。
【００４４】
別の実施態様において、ウェブサーバ１２０は企業情報ポータル（Ｅｎｔｅｒｐｒｉｓｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｏｒｔａｌ）とも称される企業内ポータルをクライアント１０８に提供する。企業内ポータルは、情報を組織化しより効率的に使用するための管理ツールを提供しながら、ユーザーにアプリケーション、データおよびコンテンツを情報集約し、個人化し、供給する、会社のウェブサイトである。他の実施態様において、ウェブサーバ１２０は、ウェブポータルまたはインターネットポータルをクライアント１０８に提供する。ウェブポータルは、企業ポータルと同様であるが、概して業務用の情報は含まない。
【００４５】
一実施態様において、クライアント１０８のユーザーは、ウェブサーバ１２０に対しユーザーを認証するためにウェブブラウザ１６２を使用する。一実施態様において、クライアント１０８はログインおよびパスワード情報等のユーザー認証証明書をウェブサーバ１２０へ伝送する。ウェブサーバ１２０は、ユーザーがサーバネットワーク１６９にアクセスできることを検証する。
【００４６】
さらなる実施態様において、ウェブブラウザ１６２は、セキュアなクライアント‐ウェブサーバ間通信チャネル１４０を確立するためにＳＳＬを使用する。ウェブブラウザ１６２は、Ｔｅｒｉｓａ Ｓｙｓｔｅｍｓ社（Ｌｏｓ Ａｌｔｏｓ、ＣＡ）製のセキュアハイパーテキスト転送プロトコル（ＳＨＴＴＰ）、ＳＳＬ上のＨＴＴＰ（ＨＴＴＰＳ）、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のプライベートコミュニケーションテクノロジー（ＰＣＴ）、およびインターネット技術特別調査委員会（ＩＥＴＦ）が広めたトランスポートレベルセキュリティ（ＴＬＳ）標準等であるがこれらに限定されないその他のセキュリティプロトコルを使用し、クライアント‐ウェブサーバ通信間チャネル１４０上で代替的にウェブサーバ１２０に接続することができる。一実施態様において、ウェブサーバ１２０は、上述のように、クライアント１０８がアプリケーションまたはサーバデスクトップを、例えば遠隔でクライアント１０８上に表示されるよう要求できるようにする、ユーザーの検証時にウェブポータルまたは企業ポータルをクライアント１０８へ伝送する。
【００４７】
クライアント‐ウェブサーバ間通信チャネル１４０は、任意のセキュアな通信チャネルである。一部の実施態様において、チャネル１４０上での通信は暗号化される。これらの実施態様のいくつかにおいて、クライアント１０８とウェブサーバ１２０は、ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）のセキュアソケットレイヤー（ＳＳＬ）を使用して通信を行うことができる。あるいは、クライアント１０８とウェブサーバ１２０は、通信を保護するため、対称的暗号化技術等、その他の暗号化技術を使用してもよい。
【００４８】
さらに、一実施態様において、クライアント‐第１のプロトコルサービス間通信チャネル１３５は、例えば、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ Ｌａｕｄｅｒｄａｌｅ、Ｆｌｏｒｉｄａ）製インディペンデントコンピューティングアーキテクチャ（ＩＣＡ）プロトコル等のプレゼンテーションサービスプロトコルを使用することによって確立できる。ＩＣＡは、ＴＣＰ／ＩＰ、ＩＰＸ／ＳＰＸ、ＮｅｔＢＥＵＩ等の業界標準ネットワークプロトコル上で、ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、および非同期転送モード（ＡＴＭ）等の業界標準トランスポートプロトコルを使用して実行するために設計された汎用プレゼンテーションサービスプロトコルである。ＩＣＡプロトコルは、データを交換するためのコマンドを発行するためにアプリケーション層コードが使用するセッション指向の伝送接続である仮想チャネルを提供する。別の実施態様において、クライアント‐第１のプロトコルサービス間通信チャネル１３５は、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＴｈｉｎ Ｘプロトコルまたはリモートディスプレイプロトコル（ＲＤＰ）を使用して確立できる。
【００４９】
クライアント１０８と第１のプロトコルサービス１１２の間の第１の通信セッション、および第１のプロトコルサービス１１２とホストノード１１８の間の第２の通信セッションとして説明したが、通信セッションは、クライアント１０８とホストサービス１１６の間の単一で論理的な通信セッションとみなされる場合もある。
【００５０】
引き続き図１Ａおよび図１Ｂを参照して、クライアント１０８は、第１のプロトコルを使用してネットワーク１０４を通じてクライアント１０８と第１のプロトコルサービス１１２との間の接続１３５を確立するように構成される。第１のプロトコルサービス１１２は、その役割として、接続１３５を受け入れるように構成される。従って、クライアント１０８および第１のプロトコルサービス１１２は、図２Ａ乃至２Ｂおよび図３を参照して以下に説明するように、第１のプロトコルを使用して互いに通信を行うことができる。
【００５１】
また以下でさらに説明するように、第１のプロトコルサービス１１２は、一実施態様において、それ自体が第１のプロトコルを使用して通信を行うよう構成される。第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２とホストサービス１１６ａ乃至１１６ｎの間にそれぞれ接続１２４ａ乃至１２４ｎを確立するよう構成されている。例えば、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２と１つのホストサービス１１６ａの間に接続１２４ａを、また第１のプロトコルサービス１１２と別のホストサービス１１６ｂの間に接続１２４ｂを確立することができる。一実施態様において、第１のプロトコルサービス１０８はそのような接続１２４ａ乃至１２４ｎを個別に確立することができる（すなわち、第１のプロトコルサービス１１２は１回に１つの接続を確立する）。別の実施態様において、第１のプロトコルサービス１１２は、そのような接続１２４ａ乃至１２４ｎを２つ以上同時に確立する。
【００５２】
さらに別の実施態様において、第１のプロトコルサービス１１２は、複数の接続１２４ａ乃至１２４ｎを同時に確立および維持することができる。第１のプロトコルサービス１１２は、接続１３５を中断せずに２つ以上の接続１２４ａ乃至１２４ｎをクライアント１０８に提供するよう構成される。例えば、第１のプロトコルサービス１１２は、クライアント１０８のユーザーがホストサービスに１１６ａに存在する第１のアプリケーションプログラムの実行を要求した場合、第１のプロトコルサービス１１２とホストサービス１１６ａとの間の接続１２４ａを確立するように構成することができる。ユーザーが第１のアプリケーションプログラムの実行を終了し、例えばホストサービス１１６ｂに存在する第１のアプリケーションプログラムの実行を終了し、第２のアプリケーションプログラムの実行を開始する場合、一実施態様では、第１のプロトコルサービス１１２は、接続１２４ａを中断して、第１のプロトコルサービス１１２とクライアント１０８との間の接続１３５を中断させずに第１のプロトコルサービス１１２とホストサービス１１６ｂとの間の接続１２４ｂを確立するように構成される。
【００５３】
第１のプロトコルサービス１１２およびホストサービス１１６ａ乃至１１６ｎは、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ Ｌａｕｄｅｒａｌｅ、Ｆｌｏｒｉｄａ）製のＩＣＡリモートディスプレイプロトコルおよび／またはＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＲＤＰリモートディスプレイプロトコルを含むがこれらに限定されない、様々な第２のプロトコルのうちのいずれか１つを使用して、接続１２４ａ乃至１２４ｎを通じて通信を行うことができる。例えば、第１のプロトコルサービス１１２およびホストサービス１１６ａは、ＩＣＡリモートディスプレイプロトコルを使用して接続１２４ａを通じて通信を行いながら、第１のプロトコルサービス１１２およびホストサービス１１６ｂは、ＲＤＰリモートディスプレイプロトコルを使用して接続１２４ｂを通じて通信を行うことができる。
【００５４】
一実施態様において、第１のプロトコルサービス１１２とホストサービス１１６との間の通信を行うために使用する、例えばＩＣＡリモートディスプレイプロトコルのような第２のプロトコルは、複数の仮想チャネルを含む。仮想チャネルは、データを交換するためのコマンドを発行するためにアプリケーション層コードが使用するセッション指向の伝送接続である。例えば、複数の仮想チャネルのそれぞれは、リモートクライアント１０８での機能を可能にする複数のプロトコルパケットを含むことができる。一実施態様において、複数の仮想チャネルのうちの１つが、クライアント１０８にグラフィカルユーザーインターフェイスを表示させるために、第１のプロトコルサービス１１２を介して、グラフィックスクリーンコマンドをホストサービス１１６からクライアント１０８に伝送するためのプロトコルパケットを含む。別の実施態様において、複数の仮想チャネルのうちの１つが、クライアント１０８で文書を印刷させるために、第１のプロトコルサービス１１２を介して、プリンタコマンドをホストサービス１１６からクライアント１０８に伝送するためのプロトコルパケットを含む。
【００５５】
一実施態様において、第１のプロトコルは、トンネリングプロトコルである。第１のプロトコルサービス１１２は、それぞれがホストサービス１１６ａ乃至１１６ｎの１つと第１のプロトコルサービス１１２との間の通信に使用する、複数の第２のプロトコルを第１のプロトコル内にカプセル化する。このように、ホストサービス１１６ａ乃至１１６ｎと第１のプロトコルサービス１１２は、複数の第２のプロトコルを介してクライアント１０８と通信を行う。一実施態様において、第１のプロトコルは、例えば、ＴＣＰ／ＩＰ接続を通じて複数の第２のプロトコルのトンネリングが可能な、アプリケーションレベルのトランスポートプロトコルである。
【００５６】
図２Ａを参照すると、接続１３５を介したクライアント１０８と第１のプロトコルサービス１１２との間の通信は、第１のプロトコル２０４内にカプセル化された複数の第２のプロトコル２００ａ乃至２００ｎ（例えば、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡ、および／またはＲＤＰ）の形をとる。これは、第１のプロトコル２０４の中の第２のプロトコル２００ａ乃至２００ｎの位置によって示される。セキュアな通信が要求されない場合は、図２Ａに示すように、第１のプロトコル２０４は、セキュアでないＴＣＰ／ＩＰ接続２０８を通じて通信を行うことができる。
【００５７】
ここで図２Ｂを参照すると、セキュアな通信を使用する場合、第１のプロトコル２０４は、例えば、セキュアソケットレイヤー（ＳＳＬ）のようなセキュアプロトコル２１６を使用して保護されるＴＣＰ／ＩＰ接続２１２などのような暗号化された接続を通じて通信を行う。ＳＳＬは、Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ社（Ｍｏｕｎｔａｉｎ Ｖｉｅｗ、Ｃａｌｉｆｏｒｎｉａ）が開発し、トランスポートレイヤセキュリティ（ＴＳＬ）プロトコルとしてインターネット技術特別調査委員会（ＩＥＴＦ）が広め、ＩＥＴＦ ＲＦＣ−２２４６に記載された、現在の標準である。
【００５８】
従って、複数の第２のプロトコル２００ａ乃至２００ｎは、接続１３５を通じてセキュリティ有り（図２Ｂ）またはセキュアプロトコル２１６なし（図２Ａ）で第１のプロトコル２０４内で通信を行う。接続１２４ａ乃至１２４ｎを通じて通信を行うために使用できる第２のプロトコルには、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡ、および、ＲＤＰを含むが、これらに限定されない。さらに、一実施態様において、上述のように、少なくとも１つの第２のプロトコルは、複数の仮想チャネルを含むが、それぞれリモートクライアント１０８での機能を可能にする複数のプロトコルパケットを含むことができる。例えば、一実施態様において、一方のホストサービス１１６ａはウェブサーバであり、ＨＴＴＰプロトコルを使用して接続１２４ａを通じて第１のプロトコルサービス１１２と通信を行い、他方のホストサービス１１６ｂはアプリケーションサーバであり、ＩＣＡプロトコルを使用して接続１２４ｂを通じて第１のプロトコルサービス１１２と通信を行う。ホストサービス１１６ｂは、クライアント１０８にグラフィカルユーザーインターフェイスを表示させるグラフィックスクリーンコマンドをクライアント１０８に伝送するためのプロトコルパケット、およびクライアント１０８で印刷する文書を生じさせるプリンタコマンドをクライアント１０８に伝送するためのプロトコルパケットの両方を生成する。
【００５９】
本発明の別の局面は、本願明細書に記載されている、ネットワーク接続の開閉回数を減らす方法およびシステムである。一実施態様において、第１のプロトコル２０４はその中にトンネリングした、例えば、ＨＴＴＰ接続２００ｎなどのような第２のプロトコル接続２００ａ乃至２００ｎが、第１のプロトコル２０４がそれを通じて通信を行うトランスポート接続（例えば、ＴＣＰ接続２０８および／または２１２）、セキュアプロトコル接続２１６、または第１のプロトコル接続２０４自身をも同様に繰り返して開くおよび／または閉じることを必要とせずに、開くおよび／または閉じるようにする。第１のプロトコル２０４のカプセル化なしに、第２のプロトコル２００ａ乃至２００ｎはＴＣＰ接続のようなネットワーク接続を頻繁に開閉できる。これは大きな遅延および間接費をシステムに追加するであろう。このような遅延および間接費は、ネットワーク接続の確立において大きな間接費のかかるＳＳＬ等のセキュアなカプセル化プロトコル２１４の使用によってさらに増加するであろう。第１のプロトコル２０４内において第２のプロトコル２００ａ乃至２００ｎをカプセル化し、トランスポート接続（２０８、２１２）の接続を維持することによって、第２のプロトコル２００ａ乃至２００ｎは、第１のプロトコル２０４のペイロードの一部として、頻繁で費用のかかるネットワーク接続１３５の開閉を行う必要がない。さらに、第２のプロトコル２００ａ乃至２００ｎは第１のプロトコル２０４内でセキュアプロトコル２１６と通信を行えるため、第２のプロトコル２００ａ乃至２００ｎはＳＳＬ等とのセキュアな接続を開閉する必要もない。トランスポート接続（２０８、２１２）は、カプセル化された第２のプロトコル２００ａ乃至２００ｎがセキュアなまたはセキュアでないネットワーク接続１３５を繰り返し開閉することなく通信を行えるよう、ネットワーク接続１３５を確立し維持する。これは第２のプロトコル２００ａ乃至２００ｎの通信における動作速度を大幅に上げる。
【００６０】
上述のように、第２のプロトコル２００ａ乃至２００ｎはアプリケーションに関連するプロトコルパケットを、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＲＤＡまたはＩＣＡ等のプロトコルを使用して運搬する。第２のプロトコルパケット３０４ａ乃至３０４ｎは、クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間でやりとりされるアプリケーション機能に関連するデータをトランスポートする。例えば、クライアント１０８上のユーザーは、ホストサービス１１６ａ乃至１１６ｎによって提供されるウェブページと情報のやりとりを行うことができる。クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間のトランザクションにおいて、第１のプロトコル２０４内でカプセル化された第２のプロトコル２００ａ乃至２００ｎは、ホストサービス１１６ａ乃至１１６ｎと通信を行うため、ウェブページの表示および任意のユーザー対話の受信に関連するｈｔｔｐプロトコルパケットを有することができる。トランスポート接続（２０８、２１２）は第２のプロトコル２００ａ乃至２００ｎによって維持されないため、第２のプロトコル２００ａ乃至２００ｎは任意のネットワーク接続中断に対処する必要がない。そのため、第２のプロトコル２００ａ乃至２００ｎは、そのペイロードにおいていずれのネットワーク接続中断情報も提供しなくてよい。上記の例において、クライアント１０８へ伝送される第２のプロトコル２００ａ乃至２００ｎの第２のプロトコルパケット３０４ａ乃至３０４ｎに関連するｈｔｔｐは、例えばウェブページ上でのエラーメッセージ等、ネットワーク中断が発生したという通知を提供しないであろう。従って、クライアント１０８上のユーザーは、いかなるネットワークレベル接続が中断しても第２のプロトコル２００ａ乃至２００ｎを介して通知されることはない。これは、第２のプロトコル２００ａ乃至２００ｎに関連するアプリケーションの使用中、ネットワーク接続中断をユーザーから効果的に隠す。
【００６１】
図３を参照すると、第１のプロトコルサービス１１２およびクライアント１０８のクライアントエージェント１２８が使用するプロセス例３００は、接続１３５を介して通信を行うために、複数の第２のプロトコル２００（例えば、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡおよび／またはＲＤＰ）を第１のプロトコル２０４内にカプセル化する。任意で、下記のように、第１のプロトコルサービス１１２およびクライアント１０８のクライアントエージェント１２８が使用するプロセス例３００はまた、接続１３５を介した通信の前に、第１のプロトコルのレベルで通信を圧縮および／または暗号化する。第１のプロトコルサービス１１２の観点から、第２のプロトコルパケット３０４ａ乃至３０４ｎは、接続１２４ａ乃至１２４ｎを介して第１のプロトコルサービス１１２で受信する。例えば、２つの第２のプロトコルパケット３０４ａおよび３０４ｂは、第１のプロトコルサービス１１２によって受信する。１つ、２つ、または任意の第２のプロトコルパケット３０４ａ乃至３０４ｎを受信することができる。一実施態様において、第２のプロトコルパケット３０４ａ乃至３０４ｎは、ホストサービス１１６によって接続１２４を通じて第１のプロトコルサービス１１２に伝送される。第２のプロトコルパケット３０４ａ乃至３０４ｎは、ヘッダ３０８およびデータペイロードとも呼ばれるデータパケット３１２を含む。
【００６２】
第２のプロトコルパケット３０４ａ乃至３０４ｎの受信の後に、第１のプロトコルサービス１１２は、１つ以上の第２のプロトコルパケット３０４を第１のプロトコルパケット３１６内にカプセル化する。一実施態様において、第１のプロトコルサービス１１２は、第１のプロトコルパケットヘッダ３２０を生成し、例えば、２つの第２のプロトコルパケット３０４ａおよび３０４ｂなどのような、１つ以上の第２のプロトコルパケット３０４ａ乃至３０４ｎを第１のプロトコルパケット３１６のデータペイロード３２４内にカプセル化する。別の実施態様において、１つの第２のプロトコルパケット３０４ａだけが、各第１のプロトコルパケット３１６内にカプセル化される。
【００６３】
一実施態様において、第１のプロトコルパケット３１６は、次いで接続１３５、例えば図２Ａを参照して説明される接続２０８を通じて、クライアント１０８のクライアントエージェント１２８に伝送される。あるいは、別の実施態様では、第１のプロトコルサービス１１２は、いずれの第１のプロトコルパケット３１６の伝送の前に、第１のプロトコル２０４のレベルでの通信を暗号化するようにさらに構成される。このような一実施態様において、第１のプロトコルパケット３１６は、例えば、図２Ｂを参照して説明されるＳＳＬプロトコルを使用して暗号化される。その結果、ヘッダ３３２と、データペイロード３３６としての暗号化された第１のプロトコルパケット３１６’を含むセキュアなパケット３２８が生成される。セキュアなパケット３２８は、次いで接続１３５、例えば図２Ｂを参照して説明されるセキュアなＴＣＰ／ＩＰ接続２１２を通じて、クライアント１０８のクライアントエージェント１２８に伝送される。
【００６４】
別の実施態様において、第１のプロトコルサービス１１２は、任意の第１のプロトコルパケット３１６の伝送の前に、第１のプロトコル２０４のレベルでの通信を暗号化するようにさらに構成される。一実施態様において、第１のプロトコルサービス１１２は、第１のプロトコルパケット３１６を暗号化する前に、標準的な圧縮技術を使用して第１のプロトコルパケット３１６を圧縮する。このように、システム１００の効率が改善される。
【００６５】
図１Ａおよび図１Ｂを再び参照すると、本発明のシステム１００は、一実施態様において、例えばホストサービス１１６ａのようなホストサービス１１６への持続的な接続を有するリモートクライアント１０８を提供する。例えば、クライアント１０８がクライアント１０８と第１のプロトコルサービス１１２との間の接続１３５を確立し、第１のプロトコルサービス１１２が第１のプロトコルサービス１１２とホストサービス１１６ａとの間の接続１２４ａを確立する場合は、次いでクライアントエージェント１２８または第１のプロトコルサービス１１２のいずれか、またはその両方が、接続１３５を介して直近に伝送された第１のプロトコルデータパケットのキューを維持するように構成される。例えば、キューに入れたデータパケットは、接続１３５の前でも失敗時でもクライアントエージェント１２８および／または第１のプロトコルサービス１１２によって維持されることができる。さらに、接続１３５の失敗時には、第１のプロトコルサービス１１２、および同様にホストサービス１１６ａは、接続１２４ａを維持するように構成される。
【００６６】
接続１３５の失敗を受けて、クライアント１０８は、いずれのデータも失わずに第１のプロトコルサービス１１２による新しい接続１３５を確立する。より具体的には、接続１３５の失敗時に接続１２４ａが維持されるので、新しく確立された接続１３５は、維持された接続１２４ａにリンクされることができる。さらに、直近に伝送された第１のプロトコルデータパケットがキューに入っているので、クライアント１０８によってそれらを第１のプロトコルサービス１１２に再び伝送することができ、および／または第１のプロトコルサービス１１２によって新しく確立された接続１３５を通じてクライアント１０８に再び伝送することができる。このように、ホストサービス１１６ａとクライアント１０８との間の通信セッションは、第１のプロトコルサービス１１２を介して、いずれのデータも失われずに持続的に進められる。
【００６７】
一実施態様において、クライアント１０８のクライアントエージェント１２８および／または第１のプロトコルサービス１１２は、それらが接続１３５を通じて伝送するデータパケットに番号を付ける。例えば、クライアントエージェント１２８および第１のプロトコルサービス１１２それぞれに、他のものがそのデータパケットにどのように番号を付けたかに関係なく、それ自身の伝送データパケットに別々に番号を付ける。さらに、データパケットの番号付けは、データパケットの番号を付け直さずに絶対的なものとすることができる。すなわち、クライアントエージェント１２８および／または第１のプロトコルサービス１１２により伝送された最初のデータパケットには、番号１を付けることができ、接続１３５を通じてクライアントエージェント１２８および／または第１のプロトコルサービス１１２により伝送された各データパケットには、その後にそれぞれ連続した番号が付けられる。
【００６８】
このような一実施態様において、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、接続１３５の中断および再確立を受けて、一方にそれが要求する次のデータパケットを通知する。例えば、クライアントエージェント１２８が、接続１３５の中断の前に番号１乃至１０のデータパケットを受信した場合、接続１３５の再確立時に、クライアントエージェント１２８は第１のプロトコルサービス１１２に現在データパケット番号１１を要求していることを通知する。同様に、第１のプロトコルサービス１１２も、このように機能することができる。あるいは、別のこのような実施態様において、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、受信した最後のパケットデータを一方に通知する。例えば、クライアントエージェント１２８が、接続１３５の中断の前に番号１乃至１０のデータパケットを受信した場合、接続１３５の再確立時に、クライアントエージェント１２８は第１のプロトコルサービス１１２に最後に受信したデータパケット番号１０を通知する。第１のプロトコルサービス１１２も同様に機能することができる。さらに別の実施態様において、クライアントエージェント１２８および／または第１のプロトコルサービスは１１２、接続１３５の再確立時に、受信した最後のデータパケットおよび要求する次のデータパケットの両方を一方に通知する。
【００６９】
このような実施態様において、接続１３５の再確立時に、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、他のものが受信していないバッファリングされたデータパケットを再伝送することができ、第１のプロトコルサービス１１２を介して、ホストサービス１１６とクライアント１０８との間の通信セッションをいかなるデータも失わずに進めることができる。さらに、接続１３５の再確立時に、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、現在一方が受信したことがわかっているバッファリングされたデータパケットをそれぞれのバッファから消去することができる。
【００７０】
概して、持続的な接続のためのバッファリングデータは単独の第１のプロトコルサービス１１２の観点で議論されるが、上述のデータバッファリングおよび再接続も、同様の方式で、複数の第１のプロトコルサービス１１２を横断するクライアントのホストサービス１１６との通信セッションに適用する。１つ以上の追加の第１のプロトコルサービス１１２は、クライアント１０８とホストサービス１１６との間のデータトラフィックの一部または全部をバッファリングする場合がある。別の実施態様において、クライアントとホストサービス１１６間の「ホップ」の１つを管理する第１のプロトコルサービス１１２は、当該「ホップ」と送受信されるデータをバッファリングする場合がある。このように、１つ以上の第１のプロトコルサービス１１２は、クライアント１０８とホストサービス１１６の間の中断した接続の確立時に、データパケットを再伝送するために使用される場合がある。
【００７１】
クライアント１０８にホストサービス１１６ａ乃至１１６ｎとの信頼できる持続的な接続を提供することにより、本発明は、ネットワーク接続中断を通じてユーザーセッションを維持することでホストサービス１１６ａ乃至１１６ｎとの新しいユーザーセッションを開くプロセスを回避する。ホストサービス１１６ａ乃至１１６ｎとの各ユーザーセッションのため、クライアント１０８およびホストサービス１１６ａ乃至１１６は、セッション固有のコンテキストおよびキャッシュ、ならびに本例のユーザーセッションに関連するその他のアプリケーション固有のメカニズムを維持する場合がある。確立した新しい各ユーザーセッションのために、これらのセッション固有のコンテキストおよびキャッシュを、新しいユーザーセッションを反映するため再配置および再確立する必要がある。例えば、クライアント１０８上のユーザーはホストサービス１１６ａ乃至１１６ｎとのｈｔｔｐセッションを有する場合がある。ホストサービス１１６ａ乃至１１６ｎは、本例のクライアント１０８とのｈｔｔｐセッションを提供するためのコンテキストを維持することができる。コンテキストはサーバのメモリ内、サーバのファイル内、データベースまたはホストサービス１１６ａ乃至１１６ｎの機能性の提供に関連するその他のコンポーネントに格納される。また、クライアント１０８は、ホストサービス１１６ａ乃至１１６ｎに対する未処理の要求のトラックを維持するためのメカニズム等、ｈｔｔｐセッションの例に特有のローカルコンテキストを有する場合がある。このコンテキストは、クライアント１０８のメモリ内、クライアント１０８のファイル内、またはクライアント１０８と適合するその他のソフトウェアコンポーネントに格納される場合がある。クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間の接続が持続的でない場合、ホストサービス１１６ａ乃至１１６ｎおよびクライアント１０８の新しいセッション特有コンテキストによって新しいユーザーセッションを確立する必要がある。本発明は、新しいセッション、また従って新しい特有のセッションコンテキストが再確立される必要のないよう、セッションを維持する。
【００７２】
本発明は、ネットワークレベル接続中断を通じて、クライアントのユーザーにセッションが中断されたことを通知することなく、ユーザーセッションを維持する。本発明の本局面の動作において、第１のプロトコルサービス１１２は、クライアント１０８との第１の接続およびホストサービス１１６ａ乃至１１６ｎとの第２の接続を確立および維持する。第１の接続および第２の接続を経由して、クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間のセッションは確立される。第１のプロトコルサービス１１２は、認証証明書のような任意のセッション関連情報ならびに確立されたセッションのためのクライアント１０８およびホストサービス１１６ａ乃至１１６ｎのコンテキストを格納および維持することができる。クライアント１０８上のユーザーは、確立されたセッションを通じて、ホストサービス１１６ａ乃至１１６ｎによって提供される機能性を行使するであろう。このように、関連する第２のプロトコルパケット３０４ａ乃至３０４ｎは、そのような機能性のトランザクションに関連するデータを含むであろう。これらの第２のプロトコルパケット３０４ａ乃至３０４ｎは、第２のプロトコル２００ａ乃至２００ｎの一部として、第１のプロトコル２０４内でカプセル化され、通信が行われる。第１の接続または第２の接続いずれかにおける中断検出時、第１のプロトコルサービス１１２は、中断されていないと思われるその他の接続を維持しながら、中断された接続を再確立することができる。ネットワーク接続中断は、クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間のセッションを中断する場合がある。しかしながら、トランスポートメカニズムは第２のプロトコル２００ａ乃至２００ｎによって維持されていないため、クライアント１０８上のユーザーにセッションが中断されたという通知を与えることなく、ネットワーク接続が再確立された後にセッションを再確立することができる。第２のプロトコル２００ａ乃至２００ｎは、クライアント１０８に伝送するための情報に関連するいかなる中断も含む必要がない。従って、ネットワーク接続中断によって生じるセッションの中断は、第１のプロトコル２０４のカプセル化によって、効果的にユーザーから隠される。
【００７３】
セッション関連情報を維持する第１のプロトコルサービス１１２は、クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間のセッションを再確立することができる。例えば、クライアント１０８と第１のプロトコルサービス１１６の間のセッションが中断した場合、第１のプロトコル１１２はクライアントの１０８セッションを第１のプロトコルサービス１１２とホストサービス１１６ａ乃至１１６ｂの間でアクティブまたはオープンに保つことができる。第１の接続が再確立した後、第１のプロトコルサービス１１２はクライアント１０８のセッションを第１のプロトコルサービス１１２とホストサービス１１６の間で維持されているセッションとリンクされることができる。第１のプロトコルサービス１１２は、クライアント１０８に第１の接続における中断の前にキューに入っていた任意のデータを送信することができる。このように、クライアント１０８は中断前と同じセッションを使用しているだろうし、ホストサービス１１６ａ乃至１１６ｎおよびクライアント１０８はメモリ内またはほかの場所に格納されていると思われる任意のセッション固有コンテキストの使用を継続できる。さらに、第１のプロトコルサービス１１２の仲介により、ホストサービス１１６ａ乃至１１６ｎは、第１のプロトコルサービス１１２とクライアント１０８の間のネットワーク中断に気づかない場合がある。
【００７４】
別の実施態様において、第１のプロトコルサービス１１２のホストサービス１１６ａ乃至１１６ｎの間の第２の接続が中断した場合、第１のプロトコルサービスは、ホストサービス１１６ａ乃至１１６ｎとの第２の接続を再確立しながら、クライアント１０８との第１の接続を維持することができる。第２の接続を再確立した後、第１のプロトコルサービス１１２は、クライアントを代表し、ホストサービス１１６ａ乃至１１６ｎとのクライアントセッションを再確立することができる。第１のプロトコルサービス１１２が任意のセッション関連情報を維持していたため、第１のプロトコルサービスは、クライアント１０８が、第２の接続における中断およびその結果生じた第１のプロトコルサービス１１２とホストサービス１１６ａ乃至１１６ｎの間のセッションへの中断に気づかないよう、同じセッションまたは同様のセッションを再確立することができる。第２のネットワーク接続およびセッションを再確立する間、第１のプロトコルサービス１１２は、クライアント１０８から中断中に送信されてきた任意のセッショントランザクションをキューに入れることができる。次いで、ホストサービス１１６ａ乃至１１６ｎとのセッションを再確立後、第１のプロトコルサービス１１２はそのキューに入れたトランザクションをホストサービス１１６ａ乃至１１６ｎへ伝送することができ、セッションは正常に継続できる。このような方法で、クライアント１０８はあたかもセッションの中断などなかったかのように動作を継続する。
【００７５】
また、信頼できる持続的な接続を提供することにより、本発明は、クライアント１０８とホストノード１１８またはホストサービス１１６ａ乃至１１６ｎの間で行使される機能性の一部として、トランザクション、コマンドまたは動作への中断を回避することもできる。例えば、Ｗｉｎｄｏｗｓ（登録商標） Ｅｘｐｌｏｒｅｒを使用するファイルコピー動作は、ネットワーク接続において中断があった後も動作継続するように設計されていない。クライアント１０８上のユーザーは、クライアント１０８のファイルをホストノード１１８へコピーするために、Ｗｉｎｄｏｗｓ（登録商標） Ｅｘｐｌｏｒｅｒのファイルコピー機能を使用することができる。ファイルのサイズにより、この動作が完了するまでには比較的長い時間がかかる。ホストノード１１８へのファイルコピー動作の途中にクライアント１０８とホストノード１１８の間のネットワーク接続に中断があった場合、ファイルコピーは失敗するであろう。クライアント１０８のファイルをホストノード１１８へコピーするため、ネットワーク接続が再確立されてすぐに、ユーザーはもう一度Ｗｉｎｄｏｗｓ（登録商標） Ｅｘｐｌｏｒｅｒのファイルコピー動作を開始する必要がある。本発明の下では、ユーザーはもう一度ファイルコピー動作を開始する必要がないであろう。ネットワーク接続は第１のプロトコル２０４接続の一部として再確立されるであろう。ファイルコピー動作は第２のプロトコル２００ａ乃至２００ｎのペイロードにおいてカプセル化されるであろう。このように、Ｗｉｎｄｏｗｓ（登録商標） Ｅｘｐｌｏｒｅｒのファイルコピーは、ネットワーク接続における中断の通知を受けることなく、従って失敗することがないであろう。第１のプロトコルサービス１１２は、動作が失敗なく継続できるよう、任意の接続を再確立し、キューに入れた任意のデータを伝送する。第１のプロトコル１１２は、ネットワーク接続の中断によりホストノード１１８に転送されなかったファイルコピー動作に関連するデータのキューを維持するであろう。ネットワーク接続が再確立されるとすぐに、第１のプロトコルサービス１１２はキューに入れたデータを伝送し、やがてファイルコピー操作に関連するデータの転送を継続することができる。
【００７６】
本発明の本局面は、ファイルコピー動作例の観点で説明されているが、通常当業者には、クライアント１０８とホストノード１１８またはホストサービス１１６ａ乃至１１６ｎ間でやりとりされるいかなる操作、トランザクション、コマンド、ファンクションコール等も、ネットワーク接続中断による失敗なく、またさらに、クライアント１０８が、中断があったことを認識したり中断の通知を受けたりすることなく、維持および継続できることが認識されるであろう。
【００７７】
さらに、信頼できる持続的な接続を提供することにより、本発明は、クライアント１０８に、クライアント１０８上でセッションまたはアプリケーションを再開することなく、異なるネットワークトポロジーを通じて横断させることもできる。例えば、クライアント１０８は無線ネットワーク接続を持つノート型パソコンであってよい。クライアント１０８が第１の無線ネットワークから第２の無線ネットワークへ移動する場合、クライアントのネットワーク接続１３５は、第２の無線ネットワークによってネットワーク接続が確立される際に第１の無線ネットワークから一時的に中断される場合がある。第２の無線ネットワークは、クライアント１０８に、ホスト名またはインターネットプロトコルアドレスのような新しいネットワーク識別子を割り当ててよい。この新しいネットワーク識別子は、第１の無線ネットワークによってクライアント１０８の割り当てられたネットワーク識別子と異なる場合がある。別の実施態様において、クライアント１０８は、イーサネット（登録商標）ケーブルを介してネットワーク上のポートに物理的に接続される場合がある。物理的な接続はプラグを抜かれる場合があり、クライアント１０８はネットワーク上の異なるポートに接続するため別の場所に移動する場合がある。これは、ネットワーク接続１３５への中断および割り当てられたネットワーク識別子における潜在的な変化を引き起こすであろう。本発明がなければ、クライアント１０８におけるホストサービス１１６ａ乃至１１６ｎとのいかなるセッションまたはネットワークにアクセスするクライアント１０８上のアプリケーションも、ネットワークトポロジーの変化、ネットワーク接続１３５への中断、および／または割り当てられたネットワーク識別子の変化によって再開される必要があるかもしれない。本願明細書に記載の方法およびシステムによって、本発明はクライアントのためのネットワーク接続ならびに、ネットワークトポロジーおよびネットワーク識別子における変化の処理も含む自動的に再確立されたクライアント１０８のネットワーク接続を維持する。クライアント１０８またはクライアント１０８上の任意のアプリケーションまたはセッションは、あたかもネットワーク接続中断もネットワーク識別子における変化もなかったかのように動作を継続することができる。さらに、クライアント１０８上のユーザーは、いかなる中断や変化があったことも認識しない場合があり、クライアント１０８はそのような中断のいかなる通知も受信しない場合がある。
【００７８】
別の局面において、本発明は、クライアント１０８とホストサービス１１６の間の通信セッションを、プロキシ、セキュリティゲートウェイ、ファイアウォール、またはルータ等、複数のネットワークコンポーネントを横断する複数の接続または「ホップ」を経由して確実に確立することに関する。複数ホップのセキュアな通信セッションの確立はさらに、セキュアなクライアント‐ウェブサーバ間通信チャネル１４０を経由して、例えばウェブブラウザ１６２とウェブサーバ１２０の間でＳＳＬを使用して開始される場合がある。チケットオーソリティ１３６は、クライアント‐第１のプロトコルサービス間接続１３５および第１のプロトコルサービスとホストサービスの接続１２４ａ乃至１２４ｎ等、各ホップにチケットを提供することができる。このように、クライアント１０８とホストサービス１１６ａ乃至１１６ｎの間の接続をすべて経由して、クライアント１０８は認証される。
【００７９】
動作においては、図４も参照すると、クライアントユーザーは、クライアント１０８（すなわち、ＩＣＡクライアント１２８）上に遠隔で表示されるコンテンツ（例えば、アプリケーション、サーバデスクトップ）を要求する（ステップ４００）。別の実施態様において、クライアント１０８はウェブブラウザ１６２を使用してアプリケーションを要求し、次いでウェブサーバ１２０がユーザーを認証する。要求を受信後、ウェブサーバ１２０はチケットオーソリティ１３６によってその要求を有効にする（ステップ４０５）。次いでチケットオーソリティ１３６が、第１のチケットまたはクライアントチケット、および第２のチケットまたは第１のプロトコルサービスチケットを含むチケットを生成する（ステップ４１０）。第１および第２のチケットは、１度使用した後は価値のなくなる「１回限り」のチケットである。さらなる実施態様において、第１および第２のチケットは所定の期間内に使用しなければならない。
【００８０】
一実施態様において、チケットオーソリティ１３６は、第１および第２のチケットをそのチケットが使用されるまでメモリ（例えば、ＲＡＭ）内に格納する。あるいは、チケットオーソリティ１３６は、第１および第２のチケットをそのチケットが使用されるまで記憶装置（図示なし）内に格納する。記憶装置は、例えばデータベースまたは持続的メモリ（例えば、フロッピー（登録商標）ディスクまたはハードディスクドライブ上の）を含んでよい。チケットオーソリティ１３６は、その後クライアントチケットをウェブサーバ１２０へ伝送し（ステップ４１５）、次いでウェブサーバ１２０はそのクライアントチケットをクライアント１０８へ転送する（ステップ４２０）。
【００８１】
その後クライアント１０８は、プロキシ接続要求をクライアント‐第１のプロトコルサービス間通信チャネル１３５上に伝送することにより、第１のプロトコルサービス１１２との通信セッションを開始する（ステップ４２５）。プロキシ接続要求は、クライアントチケットを含む。一実施態様において、プロキシ接続要求は、ホストノード１１８との通信セッション確立時に第１のプロトコルサービス１１２に置き換え可能なダミーパスワードも含む。さらなる実施態様において、ウェブサーバ１２０は、第１のプロトコルサービス１１２にアクセス可能なフォーマットを有するプロキシ接続要求を未来に生成するため、ダミーパスワードをクライアント１０８に伝送する。第１のプロトコルサービス１１２はその後、プロキシ接続要求からクライアントチケットを開放し（ステップ４３０）、そのクライアントチケットを有効化するためチケットオーソリティ１３６へ転送する。チケットオーソリティ１３６はその後第１のチケットを有効にする（ステップ４３５）。一実施態様において、チケットオーソリティ１３６は、第１の予期されるチケットを求めてその記憶装置（例えば、データベース）を検索することにより、第１のチケットを検証する。
【００８２】
チケットオーソリティ１３６が記憶装置の中で第１のチケットを発見しない場合（例えば第１のチケットが既に使用されていた場合など）、チケットオーソリティ１３６は通信セッションを終了する。受信したチケットがチケットオーソリティ１３６の予期しているチケットと一致する場合、そのクライアントチケットは有効にされる。チケットオーソリティ１３６はその後、第２のまたは第１のプロトコルサービスチケットを第１のプロトコルサービス１１２へ伝送する（ステップ４４０）。また、クライアントチケットが１度使用されると、チケットオーソリティ１３６はそのクライアントチケットを記憶装置から削除する。別の実施態様において、チケットオーソリティ１３６は、ホストノード１１８のインターネットプロトコル（ＩＰ）アドレスも第１のプロトコルサービス１１２へ伝送する。さらに別の実施態様において、チケットオーソリティ１３６は、その後ＩＰアドレスに変換するため、ホストノード１１８のドメイン名を第１のプロトコルサービス１１２へ伝送する。
【００８３】
第１のプロトコルサービス１１２は、第２のチケットまたは第１のプロトコルサービスチケットを受信し、その後、第２のチケットをホストノード１１８へ伝送（ステップ１４５）することにより、プロキシ‐サーバ間通信チャネル１４５を通して通信を始める。ホストノード１１８は、第１のプロトコルサービスチケットを受信し、その後そのチケットを有効にするためチケット‐サーバ間通信チャネル１５７上でチケットオーソリティ１３６に伝送する（ステップ４４７）。一実施態様において、チケットオーソリティ１３６が、ホストノード１１８から受信した第１のプロトコルサービスが以前に使用されたことがあり、正当な価値（すなわち、関連する記憶装置内に格納されているのと同じ価値）がないと判断した場合、チケットオーソリティ１３６は、クライアント１０８との確立した通信セッションを終了させるため、第１のプロトコルサービス１１２（またはウェブサーバ１２０）にエラーメッセージを伝送する。チケットオーソリティ１３６が第１のプロトコルチケットを有効にする（ステップ４４８）と、ホストノード１１８はＩＣＡ公開アプリケーションを起動する（ステップ４５０）。ホストノード１１８は次いでアプリケーション情報を、クライアント１０８におけるアプリケーションの遠隔表示（ステップ４５５）のため、ＩＣＡクライアント１２８を使用して第１のプロトコルサービス１１２へ伝送する（ステップ４５３）。
【００８４】
さらなる実施態様において、クライアント１０８は、ステップ４２５における第１のプロトコルサービス１１２との通信開始時にＩＣＡクライアント１２８を起動する。その他の実施態様において、クライアント１０８は、クライアント１０８がステップ４５３において第１のプロトコルサービス１１２からアプリケーション情報を受信した際にＩＣＡクライアント１２８を起動する。
【００８５】
従って、クライアント１０８は、クライアントチケット以外、第１のプロトコルサービスチケットには気づかない。さらに、ＩＣＡクライアント１２８は、第１のプロトコルサービス１１２と通信を行い、クライアントチケットを提示することなしにはホストノード１１８にアクセスできない。.
チケットオーソリティ１３６は、第１のプロトコルサービスチケットを、クライアント１０８のユーザーのためのユーザーパスワードとして、ステップ４４０において第１のプロトコルサービス１１２に伝送する可能性もある。これは、第１のプロトコルサービス１１２が、第１のプロトコルサービスチケットを、ユーザーのログインパスワードをウェブの信用できない部分（すなわち、ステップ４２５中のセキュアでないクライアント‐プロトコルサービス間通信チャネル１３５）上にさらすことなくホストノード１１８にアクセスするためのログインパスワードとして使用できるようにする。従って、一実施態様において、通信システム１００は、チケットオーソリティ１３６により管理され、ユーザーのパスワードで第１のプロトコルサービスチケットをマップするためにホストノード１１８と同一場所に配置される、集中パスワードマッピングデータベースを含む可能性がある。
【００８６】
従って、パスワードは両方のチケット（すなわち、第１のプロトコルサービスチケットおよびクライアントチケット）を伴うことができるか、またはパスワードは２つのチケットのうち１つを伴うことができる。上述のように、パスワードが２つのチケットのうち１つ、例えばクライアントチケットを伴っていれば、第１のプロトコルサービスチケットがパスワードである。一実施態様において、パスワードは、価値が変わらないシステムパスワード、または、ＲＳＡ Ｓｅｃｕｒｉｔｙ社（Ｂｅｄｆｏｒｄ、 Ｍａｓｓａｃｈｕｓｅｔｔｓ）製のセキュアＩＤトークンによって生成されたパスワード等の、１回限りのパスワードであってよい。
【００８７】
また、本発明は、ホストノード１１８との通信セッションを確立する前にクライアント１０８が通信を行わなければならない第１のプロトコルサービス１１２または「ホップ」をいくつでも有する通信システムまで拡張することができる。第１のプロトコルサービス１１２に関連して説明したが、ホップは、プロキシ１１５、ファイアウォール、ルータ、リレー等、任意のネットワークコンポーネントを備えることができる。
【００８８】
例えば、また図５Ａを参照して、４つのホップの例は、プロキシ１１５’を持つ第１のプロトコルサービス１１２’、プロキシ１１５’’を持つ２番目の第１のプロトコルサービス１１２’’、およびプロキシ１１５’’’（概して１１５）を持つ３番目の第１のプロトコルサービス１１２’’’を有する通信システム５０５である。プロキシ１１５を持つ第１のプロトコルサービス１１２は、第１のプロキシ‐プロキシ間通信チャネル５１０’および第２のプロキシ‐プロキシ間通信チャネル５１０’’（概してプロキシ‐プロキシ間通信チャネル５１０）のようなプロキシ‐プロキシ間通信チャネル上で通信を行う。クライアント１０８は、２番目の第１のプロトコルサービス１１２’’と通信を行う第１のプロトコルサービス１１２’と通信を行う。同様に、２番目の第１のプロトコルサービス１１２’’は３番目の第１のプロトコルサービス１１２’’’と通信を行い、次いで３番目の第１のプロトコルサービス１１２’’’は、ホストノード１１８との通信セッションを確立するため、プロキシ‐サーバ間通信チャネル１４５上でホストノード１１８と通信を行う。さらに、上述の実施態様はクライアントチケットおよび第１のプロトコルチケットを有するチケットを含むが、別の実施態様は、多数のチケットを備えるチケットを含む。
【００８９】
さらに明確に、また図５Ｂも参照すると、ウェブサーバ１２０はクライアント１０８からアプリケーションの要求を受信し、ウェブサーバ１２０はその要求をチケットオーソリティ１３６で有効にする（ステップ４０５）。チケットオーソリティ１３６は、次いでステップ４１０においてＮ部のチケット（例えばＴ１乃至ＴＮ）を生成する。一実施態様において、チケットオーソリティ１３６はその後Ｎ部のチケットの一部Ｔｉ（例えば、チケットの第１部、または第１のチケットＴ１）をウェブサーバ１２０へ伝送する（ステップ４１５）。ウェブサーバ１２０はその後チケットＴ１をクライアント１０８に伝送する（ステップ４２０）。一実施態様において、チケットオーソリティ１３６は次の「ホップ」（例えば、第１のプロトコルサービス１１２’）のアドレスをウェブサーバ１２０へ伝送し、ウェブサーバ１２０はその後そのアドレスをクライアント１０８へ伝送する。このアドレスは、クライアント１０８が最終的にホストノード１１８に対して認証されるために、現在のホップ（例えば、クライアント１０８）が通信を行う必要がある次のホップ（例えば、第１のプロトコルサービス１１２）のアドレスである。
【００９０】
クライアント１０８は、次の「ホップ」（例えば、第１のプロトコルサービス１１２’）と接触するためのアドレスを使用し、プロキシ接続要求をクライアント‐第１のプロトコルサービス間チャネル１３５上に伝送することにより、１番目の第１の通信セッション１１２’との通信セッションを開始する。第１のプロトコルサービス１１２’’は、次いで第１のチケットＴ１をプロキシ接続要求から抽出し（ステップ５３０）、このチケットを有効にするためチケットオーソリティ１３６へ転送する。チケットオーソリティ１３６はその後、第１のチケットＴ１を有効にする（ステップ５３５）。
【００９１】
第１のチケットＴ１の適切な有効化時、チケットオーソリティ１３６は次のチケットＴｉをＮ部のチケット（例えば、Ｔ２）から次の第１のプロトコルｓサービス１１２（例えば、第１のプロトコルサービス１１２’）へ伝送する（ステップ５４０）。一部の実施態様において、チケットオーソリティ１３６は、次のホップ（例えば、２番目の第１のプロトコルサービス１１２’’）のアドレスも現在のホップ（例えば第１のプロトコルサービス１１２’）へ伝送する。第１のプロトコルサービス１１２’は、このチケットを次のホップ（例えば、２番目の第１のプロトコルサービス１１２’’）へ伝送する（ステップ５４５）。一実施態様において、２番目の第１のプロトコルサービス１１２’’は、このチケットをチケットオーソリティ１３６へ伝送することによりＴ２を検証する（ステップ５５０）。チケットオーソリティ１３６は第２のチケットＴを有効にし（ステップ５５５）、ステップ５６０から５７５に示されるようなプロセスが続く。Ｎ部のチケットの最後の部分が有効になると、図４に示すように、クライアント１０８上のアプリケーションを起動するために、ステップ４５０から４５５が発生する。
【００９２】
一実施態様において、各第１のプロトコルサービス１１２（すなわち、各ホップ）はＴｉ（例えば、Ｔ２）を第１のプロトコルサービス１１２（すなわち、ホップ）に関連するチケットオーソリティ１３６によって有効にする。この実施態様において、各第１のプロトコルサービス１１２がチケットＴｉ（例えば、Ｔ２）をチケットオーソリティ１３６によって有効にした後、有効化が行われるチケットオーソリティ１３６は、次のチケットＴｉ＋１（例えば、Ｔ３）および次の第１のプロトコルサービス１１２（すなわち、次の「ホップ」あて先）を、チケットＴｉを有効にした第１のプロトコルサービス１１２に伝送する。従って、各第１のプロトコルサービス１１２は、現在および次のホップチケットが組み込まれた（すなわち、Ｔｉを有効にしＴｉ＋１を伝送している）チケットオーソリティ１３６に関連している。その結果、次の第１のプロトコルサービス１１２は、当該ホップのためのクライアントとして作用する。このプロセスは、通信システム５０５においてホストノード１１８に届くまで繰り返される。従って、各ホップは、いずれのホップに対してもすべてのチケットをさらけ出すことなく、個別に有効にされる。
【００９３】
一実施態様において、チケットオーソリティ１３６は、多くの部分を持つ１つのチケットを発行するのではなく１つを超えるチケットを発行する。例えば、チケットオーソリティ１３６は、第１のホップチケットが第２のホップチケットと関連を持たないステップ５１０において、第１のホップチケットおよび第２のホップチケットを生成する。チケットオーソリティ１３６はその後、第１のホップチケットをウェブサーバ１２０へ伝送し、ウェブサーバ１２０は第１のホップチケットをクライアント１０８へ伝送する。クライアント１０８は、チケットオーソリティ１３６によってこの第１のホップチケットを有効にするため第１のプロトコルサービス１１２（例えば、第１のプロトコルサービス１１２’）へ伝送する。ステップ５３５における有効化時、チケットオーソリティ１３６は、第１のホップチケットが第２のホップチケットから独立している間に、ステップ５４０において第２のホップチケットを次の第１のプロトコルサービス１１２（例えば、２番目の第１のプロトコルサービス１１２’’）へ伝送する。
【００９４】
さらなる実施態様において、１つ以上のチケットオーソリティ１３６は、第１のプロトコルサービス１１２の一部として、または第１のプロトコルサービス１１２とは別で、ＳＯＣＫＳサーバ（例えば、ＮＥＣ社（東京、日本）製のＳＯＣＫＳ５サーバ）に接続するための暗号キー、ＳＳＬ方法設定情報、および認証情報等であるがこれらに限定されない、次のホップに接続するために必要な任意の必要情報とともに、プロキシ１１５を提供する。
【００９５】
さらに別の実施態様において、チケットオーソリティ１３６は単一のチケットのみを生成する。チケットオーソリティ１３６は単一のチケットをウェブサーバ１２０へ伝送する。ウェブサーバ１２０は単一のチケットをクライアント１０８へ転送する。第１のプロトコルサービス１１２はその後そのチケットをクライアント１０８から受信し、有効化時にその単一のチケットを「消費」する。結果として、通信システム１００は単一のチケットを、クライアント‐プロキシ間通信チャネル１３５およびクライアント‐ウェブサーバ間通信チャネル１４０上で任意の通信プロトコルを使用する能力を提供するために使用する。また、ホストノード１１８は単一のチケットを受信も検証もしないため、チケットはホストノード１１８に対して透過的であり、その結果、ホストノード１１８はチケットの使用に「気づく」ことがない。
【００９６】
セキュアなクライアント‐ウェブサーバ通信チャネル１４０上のクライアント１０８とウェブサーバ１２０の間のセキュアな通信のセキュリティを利用することにより、通信システム５０５はセキュアでないクライアント‐プロキシ通信チャネル１３５上に、クライアント１０８にデスクトップアプリケーションをセキュアに遠隔表示するためのセキュアな通信リンクを確立する。
【００９７】
さらに別の実施態様において、また図４を再度参照して、チケットオーソリティ１３６はステップ４１５において第１のプロトコルサービスの使用不可能なバージョンを、クライアント１０８への伝送のため、クライアントチケットとともにウェブサーバ１２０へ伝送する。クライアント１０８はその後第１のプロトコルサービスチケットを、プロキシ接続要求の一部として、クライアントチケットとともに第１のプロトコルサービス１１２へ伝送する（ステップ４２５）。第１のプロトコルサービス１１２は、次いで両方のチケットをチケットオーソリティ１３６へ転送する。使用不可能な第１のプロトコルサービスチケットを受信すると、チケットオーソリティ１３６はクライアントチケットを有効にした後、第１のプロトコルサービスチケットを使用可能にする。チケットオーソリティ１３６は次いで使用可能な第１のプロトコルサービスチケットを、ホストノード１１８に対する認証のために第１のプロトコルサービス１１２へ伝送する。
【００９８】
あるいは、別の実施態様において、ウェブサーバ１２０は使用不可能な第１のプロトコルサービスチケットおよび使用可能なクライアントチケットをチケットオーソリティ１３６から受信し、クライアントチケットのクライアント１０８への伝送のみ行う。クライアント１０８は、そのクライアントチケットをプロキシ接続要求の一部として第１のプロトコルサービス１１２へ伝送する（ステップ４２５）。第１のプロトコルサービス１１２は次いでクライアントチケットをチケットオーソリティ１３６へ転送する。チケットオーソリティ１３６はクライアントチケットを有効にし、有効化時に、以前ウェブサーバ１２０へ伝送された第１のプロトコルサービスチケットを使用可能にする。さらに別の実施態様において、チケットオーソリティ１３６は、使用可能な第１のプロトコルサービスチケットを、ホストノード１１８に対する認証のためのクライアントチケット有効化時に、ウェブサーバ１２０へ伝送する。
【００９９】
従って、常に、チケットオーソリティ１３６は、チケットオーソリティ１３６が有効にできる、クライアント１０８または第１のプロトコルサービス１１２に対して使用可能な１つのチケットのみを提供する。チケットオーソリティ１３６は、使用可能なチケットが有効になるまで、有効にできない別のチケット（例えば、使用不可能なチケット）を提供する。あるいは、チケットオーソリティ１３６は、チケットオーソリティ１３６が使用可能なチケットを有効にするまで、第１のプロトコルサービスチケットを第１のプロトコルサービス１１２へ伝送しない場合がある。以下でさらに詳しく説明するように、クライアント１０８は、チケットオーソリティ１３６に使用可能なチケットを有効にさせ、ホストノード１１８と通信を行うために必要なチケットを伝送させることなくウェブサーバ１２０または第１のプロトコルサービス１１２を横断することができないため、これは、通信システム５０５を使用して通信のネットワークルーティングを強制する。
【０１００】
別の実施態様において、ステップ４４０のように第１のプロトコルサービスチケットを第１のプロトコルサービス１１２へ伝送する代わりに、チケットオーソリティ１３６はウェブサーバ‐オーソリティ間通信チャネル２５０上で第１のプロトコルサービスチケットを直接ウェブサーバ１２０へ伝送する。ウェブサーバ１２０はその後自動的に第１のプロトコルサービスチケットをホストノード１１８へ伝送する。すなわち、ウェブサーバ１２０は第１のプロトコルサービスチケットをホストノード１１８へ「プッシュ」する。チケットオーソリティ１３６は、第１のプロトコルサービスチケットを第１のプロトコルサービス１１２へもウェブサーバ１２０へも伝送せずに、第１のプロトコルサービスチケットをホストノード１１８へプッシュすることもできる。
【０１０１】
さらに別の実施態様において、ホストノード１１８は、チケット‐コンテンツサーバ間通信チャネル１５７上で、チケットオーソリティ１３６から第１のプロトコルサービスチケットを回収する。すなわち、ホストノード１１８はチケットオーソリティ１３６から第１のプロトコルサービスチケットを「プル」する。上記の例は、ステップ３４５を（ステップ４４０における伝送あて先を変更しながら）排除するための技術の説明である。
【０１０２】
さらに、本発明は、第１のプロトコルサービス１１２を通じてクライアント１０８のルーティングを強制する。上述のように、クライアント１０８は、ホストノード１１８との通信セッションを確立するため、第１のプロトコルサービスチケットを所有しなければならない。より具体的には、ホストノード１１８との通信セッションを確立するために、ウェブサーバ１２０はまずチケットオーソリティ１３６でクライアント１０８の要求を有効にしなければならない。有効化されると、クライアント１０８は第１のチケットを得てこの第１のチケットを有効化のためチケットオーソリティ１３６へ伝送する。しかしながら、有効化時に、チケットオーソリティ１３６は、第１のプロトコルサービスチケットをクライアント１０８ではなく第１のプロトコルサービス１１２へ送り返す。クライアント１０８とホストサービス１１６の間の通信セッションは、ホストサービス１１６が第１のプロトコルサービスチケットを受信した際に確立される。従って、クライアント１０８は、第１のプロトコルサービスチケットをホストサービス１１６へ伝送させ、それによって第１のプロトコルサービス１１２によってクライアント１０８のルーティングを強制するため、第１のプロトコルサービス１１２と通信を行わなければならない。従って、本発明は、ホストノード１１８へのアクセスを許可する前に、セキュリティ装置（例えば、第１のプロトコルサービス１１２）を適切に横断することを確実に行える。
【０１０３】
例えば、ホストノード１１８は、ともにＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＭＩＣＲＯＳＯＦＴ ＷＯＲＤおよびＭＩＣＲＯＳＯＦＴ ＥＸＣＥＬ等、いくつかのアプリケーションを実行する。一実施態様において、クライアント１０８は、クライアント１０８がアプリケーションにアクセスするサーバファーム１６９から情報を得るために、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ Ｌａｕｄｅｒｄａｌｅ、Ｆｌｏｒｉｄａ）製ＮＦＵＳＥを使用する。クライアントユーザーがＭＩＣＲＯＳＯＦＴ ＷＯＲＤにアクセスし使用したい場合、クライアント１０８はウェブサーバ１２０からアプリケーションを要求する。しかしながら、ＭＩＣＲＯＳＯＦＴ ＷＯＲＤに対するアプリケーション料を支払っているユーザーのみがこのアプリケーションへのアクセスを認可されることができる。
【０１０４】
アプリケーション料の支払いを確認するため、通信システム５０５は、第１のプロトコルサービス１１２を介してクライアント１０８のルーティングを強制するための第１のプロトコルサービス１１２およびチケットオーソリティ１３６を含む。第１のプロトコルサービス１１２がアプリケーション料の徴収およびアプリケーションにアクセスするためのユーザー認可に使用される場合、第１のプロトコルサービス１１２を介するクライアント１０８のルーティングは、アプリケーションプロバイダにとって価値がある。
【０１０５】
チケットオーソリティ１３６は、その後アプリケーションの要求に関連するチケットを生成する。次いで使用可能な第１のチケットがクライアント１０８へ伝送される。クライアント１０８はホストノード１１８のアドレスを持たないため、クライアント１０８はアプリケーションにアクセスできない。さらに、クライアント１０８は第１のプロトコルサービス１１２によってまだ認可されていない（すなわち、まだ支払っていない）。従って、クライアント１０８は認可を受けるために第１のプロトコルサービス１１２と通信を行わなければならない。第１のプロトコルサービス１１２はその後、アプリケーション料の支払い時に、使用可能な第１のチケットをチケットオーソリティ１３６へ伝送する。
【０１０６】
チケットオーソリティは次いでクライアントチケットを有効にし、その後第１のプロトコルサービスチケットをプロキシ１１５へ伝送（または使用可能に）する。第１のプロトコルサービス１１２は次いで第１のプロトコルサービスチケットをホストノード１１８へ伝送し（例えば、クライアントユーザーがアプリケーション料を支払ったと想定して）、それによりホストノード１１８にアプリケーションをクライアント１０８へ伝送可能にさせる。通信システム５０５は、クライアント１０８に配信するＨＴＭＬページから、またはＨＴＭＬページへの埋め込みからアプリケーションの起動を可能にするために、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ社製のＡｐｐｌｉｃａｔｉｏｎ Ｌａｕｎｃｈｉｎｇ Ａｎｄ Ｅｍｂｅｄｄｉｎｇ（ＡＬＥ）技術を使用してもよい。
【０１０７】
別の実施態様において、本発明はクライアント１０８のホストサービス１１６への再接続およびクライアント１０８とホストサービス１１６の間の接続または「ホップ」の再認証を対象とする。図６Ａは、クライアント１０８をホストサービス１１６へできるシステム６００の別の実施例を示す。上述したネットワーク１０４および１０４’、クライアント１０８、第１のプロトコルサービス１１２、およびホストサービス１１６に加えて、システム６００は、中間ノード６３２およびチケットオーソリティ１３６をさらに含む。一実施態様において、中間ノード６３２は、ネットワーク１０４の構成上クライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき、例えばファイアウォールおよび／またはルータのようなセキュリティゲートウェイである。また、中間ノード６３２は、第１のプロトコルサービス１１２とともに、またはこれを伴わずに、第１のプロトコルサービス１１２のプロキシ１１５を備えてもよい。図示するように、チケットオーソリティ１３６は、通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する、スタンドアロンのネットワークコンポーネントとすることができる。
【０１０８】
図６Ａの実施態様に示すように、中間ノード６３２は、クライアント１０８によって開始される接続１３５ａを受け入れ、第１のプロトコルサービス１１２による第２の接続１３５ｂを確立するように構成される。併せて、接続１３５ａおよび第２の接続１３５ｂは、上述のように接続１３５を構成し、それらを通じて第１のプロトコルを使用してクライアント１０８および第１のプロトコルサービス１１２が通信を行う。
【０１０９】
図に示すように、中間ノード６３２はまた、チケットオーソリティ１３６と通信を行うように構成される。一実施態様では、チケットオーソリティ１３６は、中間ノード６３２からの第１の再接続チケットに対する要求を受信し、その後に第１の再構成チケットを生成するように構成される。第１の再接続チケットは、例えば、大きな乱数を含むことができる。別の実施態様において、チケットオーソリティ１３６は、クライアントとホストサービス１１６の間の各「ホップ」に対する第１の再接続チケットの要求を受信するように構成される。例えば、中間ノード６３２は、クライアント１０８と中間ノード６３２の間、中間ノード６３２と第１のプロトコルサービス１１２の間、および第１のプロトコルサービス１１２とホストサービス１１６の間の接続のための再接続チケットを要求してよい。これらの再接続チケットは、各「ホップ」に対してのみ有効となることができる。例えば、ホストサービス１１６への第１のプロトコルサービス１１２の第１の再接続チケットは、クライアント１０８を代表してホストサービス１１６に対し第１のプロトコルサービス１１２を認証するためにのみ有効である。
【０１１０】
別の実施態様において、チケットオーソリティ１３６は、ハンドルを生成するように構成される。ハンドルは、例えば、第１の再接続チケットと関連する（例えば、マップする）乱数とすることができる。一実施態様では、ハンドルは、第１の再接続チケットを形成している乱数よりも小さな乱数である。例えば、ハンドルは、３２ビット乱数としてよい。さらなる実施態様において、ティッカーまたは再接続チケットに関連するチケットは、クライアント１０８とホストサービス１１６の間の複数のホップ接続における次の「ホップ」のアドレスまたはそれを指すポインタである。この場合、チケットまたは再接続チケットは、次の「ホップ」へのポインタを持つ単独の「ホップ」に対して有効となる。次の「ホップ」は、１つ前の「ホップ」が有効となり、クライアント１０８を代表してホストサービス１１６に接続されるまで、異なるチケットまたは再接続チケット等を得る必要があるであろう。
【０１１１】
チケットオーソリティ１３６は、第１の再接続チケットおよびハンドルを中間ノード６３２に伝送しながら、第１の再接続チケットのコピーおよびハンドルのコピーを維持する。第１の再接続チケットのコピーは、後にチケットオーソリティ１３６が使用することができ、クライアント１０８の再接続プロセス中に、後にチケットオーソリティ１３６にそのコピーを示す際に、元々はクライアント１０８に伝送された第１の再接続チケットを検証する。一実施態様では、チケットオーソリティ１３６は、第１のプロトコルサービス１１２に対するアドレスも維持するが、そのアドレスは、後述するように、第１の接続チケットに関連し、第１の再接続チケットの検証時に、中間ノード６３２に伝送される。
【０１１２】
一実施態様では、中間ノード６３２は、チケットオーソリティ１３６がそこに伝送したハンドルを使用して、チケットオーソリティ１３６で維持された第１の再接続チケットを削除するようにさらに構成される。別の実施態様では、下記のように、チケットオーソリティ１３６は、クライアント１０８のホストサービス１１６への再接続プロセス中に、第１の再接続チケットを削除し、その後代替の第１の再接続チケットを生成するようにさらに構成される。加えて、別の実施態様では、第１の再接続チケットは、所定の時間の経過後に自動的に削除するように構成される。クライアントとホストサービス１１６の間の各「ホップ」のための再接続チケットの実施態様において、再接続チケットのうち１つ、一部、またはすべてが所定の時間の経過後に削除されるよう構成されてよい。その他の実施態様において、チケットオーソリティ１３６または中間ノード６３２は、複数のホップチケットのそれぞれを削除し代替のチケットを生成するように構成される。
【０１１３】
別の実施態様では、第１のプロトコルサービス１１２は、第１の再接続チケットなどの場合、例えば、大きな乱数を含むことができる第２の再接続チケットを生成するように構成される。一実施態様では、第１のプロトコルサービス１１２は、クライアント１０８とホストサービス１１６間の各「ホップ」に対して第２の再接続チケットを生成する。第１のプロトコルサービス１１２は、第２の接続チケットをクライアント１０８に伝送しながら、第２の再接続チケットのコピーおよびセッション番号を維持するようにも構成することができる。第２の再接続チケットのコピーは、後に第１のプロトコルサービス１１２が使用することができ、クライアント１０８の再接続プロセス中に、後に第１のプロトコルサービス１１２にそのコピーを示す際に、元々はクライアント１０８に伝送された第２の再接続チケットを検証する。一実施態様では、第１のプロトコルサービス１１２は、中間ノード６３２を介して第２の再接続チケットをクライアント１０８に伝送する。別の実施態様では、第１のプロトコルサービス１１２は、第２の再接続チケットをクライアント１０８に直接伝送する。さらなる実施態様では、第１のプロトコルサービス１１２は、第２の再接続チケットをその他の第１のプロトコルサービス１１２またはクライアント１０８とホストサービス１１６の間に複数のホップ接続を含む場合がある中間ノード６３２へ伝送してよい。
【０１１４】
さらに、下記にさらに詳しく説明するように、第１のプロトコルサービス１１２は、クライアント１０８のホストサービス１１６への再接続プロセス中に、第２の再接続チケットを削除し、その後代替の第２の再接続チケットを生成するようにさらに構成される。加えて、別の実施態様では、第２の再接続チケットは、所定の時間の経過後に自動的に削除するように構成される。さらなる実施態様では、複数のホップ接続における１つ以上の第１のプロトコルサービス１１２の第１のプロトコルサービス１１２は、各「ホップ」のための第２の再接続チケットを削除し、その後「ホップ」の１つ、一部またはすべてに対する代替の再接続チケットを生成するよう構成される。
【０１１５】
一実施態様では、中間ノード６３２は、第１および第２の再接続チケットに対する中間物としての機能を果たす。中間ノード６３２は、例えば、チケットオーソリティ１３６が生成する第１の再接続チケット、および第１のプロトコルサービス１１２が生成する第２の再接続チケットを受信する。中間ノード６３２は、次いで第１の再接続チケットおよび第２の再接続チケットをクライアント１０８に伝送することができる。さらに、クライアント１０８のホストサービス１１６への再接続プロセス中、中間ノード６３２は、クライアント１０８から第１の再接続チケットおよび第２の再接続チケットを受け入れることができ、その後第１の再接続チケットをチケットオーソリティ１３６に伝送することができ、適切な場合、第２の再接続チケットを第１のプロトコルサービス１１２に伝送することができる。
【０１１６】
別の実施態様において、中間ノード６３２は、再接続チケットの、クライアント１０８とホストサービス１１６との間の複数のホップへの仲介としての役割を果たす。中間ノード６３２は、例えば、クライアント１０８の第１のプロトコルサービス１１２への接続のための第１の再接続チケット、および第１のプロトコルサービス１１２のホストサービス１１６への第１の再接続チケットを受信する。さらなる実施態様では、中間ノード６３２は、中間ノード６３２と第１のプロトコルサービス１１２との間の接続のための第１の再接続チケットを受信する。中間ノード６３２は、次いでクライアントのための第１の再接続チケットをクライアント１０８へ、また第１のプロトコルサービス１１２のための第１の再接続チケットを第１のプロトコルサービス１１２へ伝送することができる。さらに、クライアント１０８のホストサービス１１６への再接続プロセス中、中間ノード６３２は、中間ノード６３２または第１のプロトコルサービス１１２に対するクライアントの接続を再確立するチケットを有効にするため、クライアント１０８から第１の再接続チケットを受け入れることができる。
【０１１７】
図６Ｂを参照して、ネットワーク通信のためのシステム６０２の別の実施態様は、上述のように、ネットワーク１０４および１０４’と、クライアント１０８と、第１のプロトコルサービス１１２と、ホストサービス１１６ａ乃至１１６ｎと、中間ノード６３２と、チケットオーソリティ１３６とを含み、さらに、一実施態様においてクライアント１０８をホストサービス１１６に最初に接続するためにどちらも使用する、第１の計算コード６４０および第２の計算ノード６４４を示す。さらに、図６Ａの実施態様では、クライアント１０８は、例えば、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、ＷＡ）製のＩＮＴＥＲＮＥＴ ＥＸＰＬＯＲＥＲなどのような、ワールドワイドウェブに接続するためのウェブブラウザ１６２をさらに含む。
【０１１８】
一実施態様では（図示せず）、システム６０２は、２つ以上の中間ノード６３２および／または２つ以上の第１のプロトコルサービス１１２を含む。それを介してクライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード６３２および／または第１のプロトコルサービス１１２は、例えばロードバランシング式に基づいてそれぞれ選択することができる。
【０１１９】
第１の計算ノード６４０および第２の計算ノード６４４のそれぞれは、通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する、任意のコンピュータとすることができる。例えば、一実施態様では、第１の計算ノード６４０は、１つ以上のウェブサイトを提供するウェブサーバ１２０を含む。別の実施態様では、第２の計算ノード６４４は、ＸＭＬサービスを提供する。
【０１２０】
一実施態様では、クライアント１０８およびネットワーク１０４は、外部ネットワーク６５２を形成するが、破線で示される第１のファイアウォール１６０によってシステム６０２の他の部分から切り離される。中間ノード６３２および第１の計算ノード６４０は、同様に破線で示される第１のファイアウォール１６０および第２のファイアウォール１６１によってシステム６０２の他の部分から切り離されるＤＭＺ１３０内に置くことができる。次いで、図に示すように、ネットワーク１０４’、第１のプロトコルサービス１１２、ホストサービス１１６ａ乃至１１６ｎ、チケットオーソリティ１３６、および、第２の計算ノード６４４は、内部ネットワーク６６８を形成するが、第２のファイアウォール１６１によってシステム６０２の他の部分から切り離される。
【０１２１】
あるいは、別の実施態様では、図６Ｃを参照して、システム６０４は、ＤＭＺ１３０内でネットワーク１０４と中間ノード６３２との間に配置される第３の計算ノード６４６をさらに含む。第３の計算ノード６４６は、ネットワーク化された通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する、任意のコンピュータとすることができる。下記のように、第３の計算ノード６４６は、一部の実施態様では、クライアント１０８のホストサービス１１６への最初の接続プロセス中、および／またはクライアント１０８のホストサービス１１６への再接続プロセス中に使用する。より具体的には、下記のように、システム６０４が２つ以上の中間ノード６３２を含む際には、第３の計算ノード６４６は、例えばロードバランシング式に基づいて、それを介してクライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間の通信が通過すべき中間ノード６３２を選択することができる。
【０１２２】
さらに、図６Ｄを参照して、図６Ｃの中間ノード６３２は、別の実施態様では、２つ以上のレベル「ａ」乃至「ｎ」の中間ノード６３２に置換することができる。図示するように、各レベル「ａ」乃至「ｎ」は、２つ以上の中間ノード６３２ａ乃至６３２ｎを含むことができる。下記のように、クライアント１０８のクライアントエージェント１２８は、例えばロードバランシング式に基づいて、中間ノード６３２の任意の組み合わせを介して送ることができる。例えば、図示するように、クライアントエージェント１２８は、接続６２２を介して中間ノード６３２を介して送ることができる。追加のセキュリティのため、各「ホップ」は接続６２２を介して、クライアント１０８とホストサービス１１６との間の複数のホップ接続を有効にし認証するためのチケットまたは再接続チケットを要求することができる。当業者にとって容易に明らかなように、他の構成のシステム６００、６０２および６０４も可能である。
【０１２３】
再び図６Ｂを参照すると、一実施態様では、ウェブブラウザ１６２は、第１の計算ノード６４０によるネットワーク１０４を通じて通信を行うが、それ自身が第２の計算ノード６４４およびチケットオーソリティ１３６と接続する。より具体的には、第１の計算ノード６４０は、第２の計算ノード６４４およびチケットオーソリティ１３６のアドレスによって構成される。一実施態様において、下記にさらに説明するように、第１の計算ノード６４０は、クライアント１０８のウェブブラウザ１６２と、第２の計算ノード６４４と、チケットオーソリティ１３６との間の情報を中継し、それによってそれらの直接的な通信を防ぐように構成される。このような直接的な通信を防ぐことによって、第１の計算ノード６４０は、システム６０２にさらなるレベルのセキュリティを付加する。第１の計算ノード６４０は、中間ノード６３２のアドレス、または代わりに、２つ以上の中間ノード６３２のアドレスによって構成することもできる。
【０１２４】
第２の計算ノード６４４は、その役割として、ホストサービス１１６上で実行するどのアプリケーションプログラムをクライアント１０８のユーザーが利用できるかを判断するように構成される。すなわち、第２の計算ノード６４４は、ユーザーがアクセスを許可されたのはどのアプリケーションプログラムなのかを判断する。一実施態様では、ユーザーが自身の所望するアプリケーションプログラムを選択した後、さらに下記のように、第２の計算ノード６４４は、ロードバランシングのためにユーザーの所望のアプリケーションを実行するため、どのホストサービス１１６を使用するかを判断するように構成される。第２の計算ノード６４４は、そのホストサービス１１６のアドレスを第１の計算ノード６４０に返す。第２の計算ノード６４４は、ロードバランシング式を使用して複数の第１のプロトコルサービス１１２の中からも選択される、第１のプロトコルサービス１１２のアドレスも第１の計算ノード６４０に返す。次に、第１の計算ノード６４０は、選択した第１のプロトコルサービス１１２および選択したホストサービス１１６のアドレスをチケットオーソリティ１３６に伝送する。
【０１２５】
チケットオーソリティ１３６は、その役割として、接続チケットを生成する。一実施態様では、チケットオーソリティ１３６は、クライアント１０８への伝送に対する最初の接続チケットを第１の計算ノード６４０に伝送する。別の実施態様では、チケットオーソリティ１３６は、最初の接続チケットを、クライアント１０８およびホストサービス１１６との間の１つ以上の「ホップ」のための第１の計算ノード６４０へ伝送する。
【０１２６】
図７を参照して、図６Ａ乃至図６Ｄの例示的実施態様を使用したネットワーク通信のための方法６００の一実施態様を示す。ステップ６０４で、クライアント１０８は、例えば下記に示す方法７００を用いて、クライアント１０８を複数のホストサービス１１６に接続する。クライアント１０８の複数のホストサービス１１６への接続後、クライアント１０８およびホストサービス１１６は、第１のプロトコルサービス１１２を介して、およびステップ６０８で、第１のプロトコル内にカプセル化された複数の第２のプロトコルを介して通信を行う。一実施態様では、第１のプロトコルサービス１１２は、いずれの第１のプロトコルパケットの伝送前に、通信を第１のプロトコル２０４のレベルで暗号化し、それによって通信を保護する。別の実施態様では、第１のプロトコルサービス１１２は、任意の第１のプロトコルパケットの伝送前に、通信を第１のプロトコルのレベルで圧縮し、それによって通信効率を改善する。
【０１２７】
ステップ６１２で、クライアントエージェント１２８は、クライアントエージェント１２８と第１のプロトコルサービス１１２との間の接続１３５が失敗したかどうかを判断する。例えば、クライアントエージェント１２８と中間ノード６３２との間の接続１３５ａが失敗した可能性があり、または中間ノード６３２と第１のプロトコルサービス１１２との間の接続１３５ｂが失敗した可能性があり、あるいは接続１３５ａおよび１３５ｂの両方が失敗した可能性がある。別の実施態様では、第１のプロトコルサービス１１２とホストサービス１１６との間の接続が失敗した可能性がある。クライアントエージェント１２８が、接続１３５は失敗しなかったと判断した場合は、方法６００はステップ６２０へ進む。一方で、クライアントエージェント１２８が、接続１３５は失敗したと判断した場合は、ステップ６１６で、クライアント１０８にホストサービス１１６への信頼できる接続を提供し、ホストサービス１１６に再接続する。
【０１２８】
ステップ６２０では、クライアント１０８がプロトコルサービス１１２との接続１３５を、そして結果的にホストサービス１１６との接続１２４ａ乃至１２４ｎを完全に完了することを望んでいるかどうかを判断する。望んでいない場合には、ステップ６０８で、第１のプロトコル内にカプセル化された複数の第２のプロトコルを介して、クライアント１０８と第１のプロトコルサービス１１２との間の通信を継続する。望んでいる場合は、次いでステップ６２４で、すべての接続１３５ａ、１３５ｂ、および１２４ａ乃至１２４ｎを中断し、すべての再接続チケットを削除する。一実施態様では、中間ノード６３２は、チケットオーソリティ１３６から受信したハンドルを使用して、チケットオーソリティ１３６に保存された第１の再接続チケットのコピーを削除する。別の実施態様では、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２に保存された第２の再接続チケットのコピーを削除する。さらなる実施態様では、何らかの理由で第２のプロトコル接続１２４が失敗した場合、関連する第１のプロトコルサービス１１２で保存された第２の再接続チケットのコピーを第１のプロトコルサービス１１２によって削除する。さらに別の実施態様では、第１の再接続チケットおよび／または第２の再接続チケットは、ステップ６１２でのように、接続１３５における失敗に続いて、および／またはステップ６２０でのように、接続１３５の完全な終了に続いて、所定の時間の経過後に自動的に削除される。一実施態様では、第１のプロトコルサービス１１２またはチケットオーソリティ１３６のいずれかが、クライアント１０８とホストサービス１１６との間の１つ以上の「ホップ」のための１つ以上の再接続チケットを削除する。
【０１２９】
図８Ａ乃至８Ｃを参照して、図６Ａ乃至図６Ｄの例示的実施態様を使用してクライアント１０８のホストサービス１１６への最初の接続（例えば、図７のステップ６０４で）のための方法７００の一実施態様を示す。ステップ７０４で、クライアント１０８は、ブラウザ１６２を使用して、例えばＨＴＴＰリクエストなどのような、リクエストを第１の計算ノード６４０に送信する。第１の計算ノード６４０は、認証情報（例えば、ユーザー名およびパスワード）を要求する、例えばＨＴＭＬフォームなどのようなウェブページを返す。クライアント１０８のユーザーは、自分の認証を入力して完了したフォームを第１の計算ノード６４０に伝送する。
【０１３０】
ステップ７０８で、第１の計算ノード６４０は、次いでクライアント１０８のユーザーに実行可能なアプリケーションを通知する。一実施態様では、第１の計算ノード６４０は、ユーザーの認証をログインページから取り出し、第２の計算ノード６４４に対しユーザーが利用可能なアプリケーションを列挙するよう求める要求とともに、その認証を第２の計算ノード６４４に伝送する。ユーザーの認証に基づいて、第２の計算ノード６４４は、ユーザーが利用可能な特定のアプリケーションのリストを第１の計算ノード６４０に返し、次いでそのリストは、例えばウェブページの形態で、クライアント１０８のユーザーに転送される。
【０１３１】
ステップ７１２で、ユーザーは、所望のアプリケーションと、そのアプリケーションを第１の計算ノード６４０に送信する要求を選択する。例えば、一実施態様では、ユーザーは、第１の計算ノード６４０がユーザーに示すウェブページにリストされた所望のアプリケーションと、そのアプリケーションを第１の計算ノード６４０に転送するＨＴＴＰ要求をクリックする。その要求は、第１の計算ノード６４０によって処理され、第２の計算ノード６４４に転送される。
【０１３２】
ステップ７１６で、第２の計算ノード６４４は、要求したアプリケーションを実行するホストサービス１１６を判断する。第２の計算ノード６４４は、例えば、ロードバランシング式に基づいてその決定を行うことができる。一実施態様では、第２の計算ノード６４４は、接続１２４を介してホストサービス１１６と通信を行うために使用する複数の第１のプロトコルサービス１１２の中から第１のプロトコルサービス１１２も判断する。また、第２の計算ノード６４４は、例えば、ロードバランシング式に基づいてその決定を行うことができる。第２の計算ノード６４４は、選択したホストサービス１１６および選択した第１のプロトコルサービス１１２のアドレスを第１の計算ノード６４０に返す。
【０１３３】
ステップ７２０で、クライアント１０８には、次いで最初の接続チケットと、中間ノード６３２（下記のように、その実際のアドレスか、またはその仮想アドレスである）のためのアドレスが提供される。一実施態様では、第１の計算ノード６４０は、最初の接続チケットの要求とともに、選択したホストサービス１１６および選択した第１のプロトコルサービス１１２のアドレスをチケットオーソリティ１３６に提供する。チケットオーソリティ１３６は、選択したホストサービス１１６および選択した第１のプロトコルサービス１１２のアドレスを保存し、最初の接続チケットを生成し、この最初の接続チケットを第１の計算ノード６４０に伝送しながら、自身のためのコピーを保存する。一実施態様において、チケットオーソリティ１３６は、第１の計算ノード６４０による最初の接続チケットを受けて、クライアント１０８とホストサービス１１６との間の各「ホップ」のための接続チケットを生成する。別の実施態様では、第１の計算ノード６４０は、単独要求または複数の要求における各「ホップ」のための最初の接続チケットを要求する。例えば、チケットオーソリティ１２６は、図５Ｂと併せて上述した複数部のチケットを生成する。
【０１３４】
一実施態様において中間ノード６３２の実際のアドレスによって構成される第１の計算ノード６４０は、次いで中間ノード６３２の実際のアドレスおよび最初の接続チケットをクライアント１０８のブラウザ１６２に伝送する。第１の計算ノード６４０は、例えば、中間ノード６３２の実際のアドレスおよび最初の接続チケットを含むファイルをまず作成し、次いでそのファイルをクライアント１０８のブラウザ１６２に伝送することができる。任意で、別の実施態様では、第１の計算ノード６４０は、２つ以上の中間ノード６３２の実際のアドレスによって構成される。このような実施態様では、第１の計算ノード６４０は、先ずそれを介してクライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード６３２を判断する。第１の計算ノード６４０は、次いでその選択した中間ノード１３２の実際のアドレスおよび最初の接続チケットを、例えば、上述のファイルを使用して、クライアント１０８のブラウザ１６２に伝送する。一実施態様では、第１の計算ノード６４０は、ロードバランシング式を使用して中間ノード６３２を選択する。次いでクライアント１０８のクライアントエージェント１２８が起動され、中間ノード６３２のアドレスを使用して、ステップ７２４で、クライアント１０８のクライアントエージェント１２８と中間ノード６３２との間の第１のプロトコル接続１３５ａを確立する。一実施態様では、第１の計算ノード６４０は、各々の接続を有効にするためにチケットオーソリティ１３６から得られた１つ以上の第１のプロトコルサービス１１２および／または中間ノード６３２への最初の接続チケットを提供してよい。
【０１３５】
あるいは、別の実施態様では、第１の計算ノード６４０は、中間ノード１３２の仮想アドレスとしての機能を果たす第３の計算ノード６４６の実際のアドレスによって構成される。このような実施態様では、ステップ７２０で、第１の計算ノード６４０は、第３の計算ノード６４６の実際のアドレスおよび最初の接続チケットを、例えば、上述のファイルを使用して、クライアント１０８のブラウザ１６２に伝送する。次いでクライアント１０８のクライアントエージェント１２８が起動され、第３の計算ノード６４６の実際のアドレスを使用して、ステップ７２４で、クライアント１０８のクライアントエージェント１２８と第３の計算ノード６４６との間の第１のプロトコル接続を確立する。第３の計算ノード６４６は、次いで、それを介してクライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード６３２を判断する。一実施態様では、第３の計算ノード６４６は、ロードバランシング式を使用して中間ノード６３２を選択する。中間ノード６３２を選択すると、第３の計算ノード６４６は、中間ノード６３２に対する第１のプロトコル接続を確立する。その結果、第３の計算ノード６４６を介して、第１のプロトコル接続１３５ａが、クライアント１０８のクライアントエージェント１２８と中間ノード６３２との間に存在する。従って、第３の計算ノード６４６の実際のアドレスは、中間ノード６３２の実際のアドレスにマップされる。クライアント１０８のクライアントエージェント１２８に対して、第３の計算ノード６４６の実際のアドレスが中間ノード６３２の仮想アドレスとしての機能を果たす。
【０１３６】
一実施態様では、複数のレベルの中間ノード６３２が存在する際には、上述のように、第１の計算ノード６４０または第３の計算ノード６４６はそれぞれ、クライアントエージェント１２８がレベル「ａ」で接続する中間ノード６３２だけを選択する。このような実施態様では、各々のレベル「ａ」乃至「ｎ−１」で、クライアントエージェント１２８がレベルで送られる中間ノード６３２は、その後、例えばロードバランシング式に基づいて、次のレベルで接続する中間ノード６３２を判断する。あるいは、他の実施態様では、第１の計算ノード６４０または第３の計算ノード６４６はそれぞれ、複数またはすべてのレベル「ａ」乃至「ｎ」に対して、クライアントエージェント１２８が送られる中間ノード６３２を選択する。
【０１３７】
クライアント１０８のクライアントエージェント１２８と中間ノード６３２との間の第１のプロトコル接続１３５ａ、例えば、レベル「ｎ」の中間ノード１３２（以下、方法７００において中間ノード６３２と称する）を確立すると、次いでクライアントエージェント１２８は、最初の接続チケットを中間ノード６３２に伝送する。
【０１３８】
次いで、ステップ７２８で、最初の接続チケットが有効かどうかを判断する。一実施態様では、中間ノード６３２は、検証のために最初の接続チケットをチケットオーソリティ１３６に伝送する。一実施態様では、チケットオーソリティ１３６は、ステップ７２０で保存した最初の接続チケットのコピーと比較することによって、最初の接続チケットの有効性を判断する。チケットオーソリティ１３６が最初の接続チケットを有効であると判断した場合、ステップ７３２で、チケットオーソリティ１３６は、第１のプロトコルサービス１１２のアドレスおよび選択したホストサービス１１６のアドレスを中間ノード６３２に伝送する。チケットオーソリティ１３６は、クライアント１０８がホストサービス１１６に接続するのに通過する第１のプロトコルサービス１１２および中間ノード６３２のための追加の接続チケットを伝送してもよい。第１のプロトコルサービス１１２は、最初の接続チケットおよびそのコピーを削除することもできる。一方で、チケットオーソリティ１３６が最初の接続チケットを無効であると判断した場合、ステップ７３０で、クライアント１０８は、第１のプロトコルサービス１１２への接続を拒否し、結果的に、ホストサービス１１６に接続する。
【０１３９】
ステップ７３２に続いて、中間ノード６３２は、選択した第１のプロトコルサービス１１２のアドレスを使用して、ステップ７３６で、中間ノード６３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１３５ｂを確立する。一実施態様では、中間ノード６３２は最初の接続チケットを使用して、中間ノード６３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１３５ｂを確立する。ある場合には、中間ノード６３２はクライアント１０８から受信した同じ最初の接続チケットを使用して、接続１３５ｂを有効にする。別の場合には、中間ノード６３２は、第１のプロトコル接続１３５ｂのために生成され有効にされた最初の接続チケットを使用する。したがってここでは、中間ノード６３２を介して、クライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間に、第１のプロトコル接続１３５が存在する。中間ノード６３２は、選択したホストサービス１１６のアドレスを第１のプロトコルサービス１１２に渡すこともできる。
【０１４０】
一実施態様では、ステップ７４０で、第１のプロトコルサービス１１２は、選択したホストサービス１１６のアドレスを使用して、第１のプロトコルサービス１１２と選択したホストサービス１１６との間の第２のプロトコル接続１２４を確立する。例えば、選択したホストサービス１１６は実際にホストサービス１１６ａであり、第２のプロトコル接続１２４ａが第１のプロトコルサービス１１２とホストサービス１１６ａとの間に確立される。
【０１４１】
一実施態様では、ステップ７４０に続いてステップ７４４で、ユーザーは実行する第２のアプリケーションを選択し、ステップ７４８で、第２の計算ノード６４４は第２のアプリケーションが実行されるホストサービス１１６を判断する。例えば、ロードバランシング式を計算することによって、第２の計算ノード６４４は、第２のアプリケーションプログラムを実行するためにホストサービス１１６ｂを選択することが可能である。第２の計算ノード６４４は、次いで選択したホストサービス１１６ｂのアドレスを第１のプロトコルサービス１１２に伝送する。一実施態様では、第２の計算ノード６４４は、第１のプロトコルサービス１１２による直接的な通信にあり、そこにアドレスを直接伝送する。別の実施態様では、選択したホストサービス１１６ｂのアドレスは、第１のプロトコルサービス１１２に間接的に伝送される。例えば、第１の計算ノード６４０、チケットオーソリティ１３６、中間ノード６３２、および第１のプロトコルサービス１１２の任意の組み合わせを介して第１のプロトコルサービス１１２にアドレスを伝送することができる。選択したホストサービス１１６ｂのアドレスを受信すると、第１のプロトコルサービス１１２は、ステップ７５２で、第１のプロトコルサービス１１２と選択したホストサービス１１６ｂとの間の第２のプロトコル接続１２４ｂを確立する。第２のプロトコル接続１２４ｂの確立において、第１のプロトコルサービス１１２は最初の接続チケットを有効にしてホストサービス１１６への接続を認証することができる。最初の接続チケットは、中間ノード６３２へのクライアント１０８の接続または中間ノード６３２の第１のプロトコルサービス１１２への接続いずれかのための最初の接続チケットと同じであってよい。別の実施態様では、チケットオーソリティ１３６または中間ノード６３２のいずれかが、第２のプロトコル接続１２４ｂにのみ有効なチケットを生成した。第１のプロトコルサービス１１２および／またはホストサービス１１６はこのチケットを使用して第２のプロトコル接続１２４ｂを有効にする。
【０１４２】
接続１２４ａおよび１２４ｂを通じて通信を行うために使用できる第２のプロトコルは、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡ、および、ＲＤＰを含むがこれらに限定されない。さらに、一実施態様では、上述のように、少なくとも１つの第２のプロトコルは、複数の仮想チャネルを含むが、それぞれリモートクライアント１０８での機能を可能にする複数のプロトコルパケットを含むことができる。例えば、一実施態様では、一方のホストサービス１１６ａはウェブサーバであり、ＨＴＴＰプロトコルを使用して接続１２４ａを通じて第１のプロトコルサービス１１２と通信を行い、他方のホストサービス１１６ｂはアプリケーションサーバであり、ＩＣＡプロトコルを使用して接続１２４ｂを通じて第１のプロトコルサービス１１２と通信を行う。ホストサービス１１６ｂは、クライアント１０８にグラフィカルユーザーインターフェイスを表示させるグラフィックスクリーンコマンドをクライアント１０８に伝送するためのプロトコルパケット、およびクライアント１０８で文書を印刷させるプリンタコマンドをクライアント１０８に伝送するためのプロトコルパケットの両方を生成する。
【０１４３】
ステップ７４４、７４８、および７５２は、複数回繰り返すことができる。このように、任意数のアプリケーションプログラムを任意数のホストサービス１１６ａ乃至１１６ｎ上で実行することができ、その出力は、任意数の第２のプロトコルを使用して接続１２４ａ乃至１２４ｎを通じて第１のプロトコルサービス１１２へ通信を行うことができる。
【０１４４】
ステップ７５６では、第１のプロトコルサービス１１２は、上述のように、第１のプロトコル内に複数の第２のプロトコルをカプセル化することができる。このように、クライアント１０８は、複数のホストサービス１１６に接続され、同時にそれらと通信を行う。
【０１４５】
別の実施態様では、ステップ７４４、７４８、および７５２を行う前に、例えば、ホストサービス１１６ｂなどのようなホストサービス１１６上で新しいアプリケーションプログラムを実行するために、クライアント１０８のユーザーは、例えば、ホストサービス１１６ａ上で実行しているアプリケーションプログラムなどのような、別のアプリケーションプログラムの実行を終了する。そのような場合、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２とホストサービス１１６ａとの間の接続１２４ａを中断させる。次いで第１のプロトコルサービス１１２は、ステップ７４４、７４８、および７５２を実行して、クライアント１０８と第１のプロトコルサービス１１２との間の接続１３５を中断せずに、第１のプロトコルサービス１１２とホストサービス１１６ｂとの間の接続１２４ｂを確立する。
【０１４６】
一実施態様では、第１の再接続チケットは、ステップ７６０で生成される。例えば、中間ノード６３２は、チケットオーソリティ１３６から第１の再接続チケットを要求するか、またはクライアント１０８とホストサービス１１６との間の各「ホップ」のための第１の再接続チケットを要求する。その要求を受信すると、チケットオーソリティ１３６は、１つ以上の第１の再接続チケットを生成する。再接続チケットは、例えば大きな乱数であり、例えばより小さな乱数であるハンドルも生成することができる。次いでチケットオーソリティ１３６は、ステップ７６４で、第１の再接続チケットおよびハンドルを中間ノード６３２に伝送することができ、一方で第１の再接続チケットのコピーおよびハンドルのコピーを保存する。チケットオーソリティ１３６は、ステップ７２０で第１の計算ノード６４０によってそこに伝送された第１のプロトコルサービス１１２のアドレスの維持を継続する。次いで中間ノード６３２は、ステップ７６８で、クライアントの第１の再接続チケットをクライアント１０８に伝送する。
【０１４７】
ステップ７７２では、次いで１つ以上の第２の再接続チケットを生成する。一実施態様では、第１のプロトコルサービス１１２は、例えば大きな乱数となりうるクライアント１０８のための第２の再接続チケットを生成する。別の実施態様では、第１のプロトコルサービス１１２は、クライアント１０８とホストサービス１１６との間の１つ以上の「ホップ」のための第２の再接続チケットを生成する。次いで第１のプロトコルサービス１１２は、ステップ７７６で、中間ノード６３２を介してクライアントの第２の再接続チケットをクライアント１０８に伝送する。この際、第１のプロトコルサービス１１２は、接続１３５の中断に続いて再接続されるセッションを識別するために、第２の再接続チケットのコピーおよびそれらに関連するセッション番号を保存する。一実施態様では、例えば、第１のプロトコルサービス１１２は、特定のセッション番号に対して、そのセッション番号に関連する第２のプロトコル接続１２４ａ乃至１２４ｎをリストしたテーブルを維持する。同様に、第１のプロトコルサービス１１２は、クライアント１０８をホストサービス１１６に再接続するよう有効にされた各「ホップ」のための第１および／または第２の再接続チケットを維持することができる。
【０１４８】
従って、第１のプロトコルサービス１１２、および／またはそれに続く任意の第１のプロトコルサービス１１２および／または中間ノード６３２における第１のプロトコル接続１３５の再確立および第２の再接続チケットの検証に続けて、第１のプロトコルサービス１１２は、クライアント１０８への通信のために、再確立された第１のプロトコル接続１３５内にカプセル化された第２のプロトコル接続１２４を識別することができる。あるいは、別の実施態様では、再度図１Ａを参照すると、本発明のシステム１００は、中間ノード１３２、チケットオーソリティ１３６、第３の計算ノード６４６のいずれも含まない。
【０１４９】
このような実施態様では、ステップ７６０乃至７７６では、第１および第２の再接続チケットの両方を生成および伝送するのではなく、システム１００および方法７００は、クライアント１０８のための、またはクライアント１０８とホストサービス１１６との間の１つ以上の「ホップ」のための、単一の再接続チケットだけを提供する。このような一実施態様では、第１のプロトコルサービス１１２は、例えば大きな乱数となりうる単一の再接続チケットを生成する。第１のプロトコルサービス１１２は、次いでクライアントの再接続チケットを接続１３５を通じてクライアント１０８に直接伝送する。この際、第１のプロトコルサービス１１２は、接続１３５の中断に続いて再接続されるセッションを識別するために、単一の再接続チケットのコピーおよびそれらに関連するセッション番号を保存する。別の実施態様では、第１のプロトコルサービス１１２はそのホストサービス１１６への接続のための再接続チケットおよびその再接続チケットの回収に関連するセッション番号を保存する。
【０１５０】
以下、図９を参照して、図６Ａ乃至６Ｄの例示的実施態様を使用した（例えば、図７のステップ６１６で）クライアント１０８に１つ以上のホストサービス１１６への信頼できる接続を提供し、クライアント１０８をホストサービス１１６へ再接続する方法８００の一実施態様を示す。特に、ステップ８０４で、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間の第２のプロトコル接続１２４を維持する。さらに、ステップ８０８で、例えば、図７のステップ６１６で中断していると判断された接続１３５を介して、クライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間の直近に伝送されたデータパケットのキューを維持する。一実施態様では、データパケットは、接続１３５の前でも失敗時でもキューに入れられ維持される。キューに入れたデータパケットは、例えば、クライアントエージェント１２８によってバッファ内に維持することができる。あるいは、第１のプロトコルサービス１１２は、キューに入れたデータパケットをバッファ内に維持することができる。さらに別の実施態様では、クライアントエージェント１２８および第１のプロトコルサービス１１２のどちらも、キューに入れたデータパケットをバッファ内に維持する。
【０１５１】
ステップ８１２で、新しい第１のプロトコル接続１３５が、クライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間に確立され、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間で維持された第２のプロトコル接続１２４にリンクされ、それによって、クライアント１０８をホストサービス１１６に再接続する。クライアント１０８の再接続後、ステップ８０８で維持されたキューに入れたデータパケットは、ステップ８１６で、新しく確立された第１のプロトコル接続１３５を介して伝送することができる。このように、ホストサービス１１６とクライアント１０８との間の通信セッションは、第１のプロトコルサービス１１２を介して、いずれのデータも失わずに持続的に進められる。
【０１５２】
ステップ８０８において、第１のプロトコルサービス１１２を横断する複数の「ホップ」を伴う実施態様では、データパケットの一部またはすべてが１つ以上の第１のプロトコルサービス１１２において維持されることができる。ステップ８１２において、各「ホップ」が再確立されることができる。上述のように、クライアント１０８が１つ以上の第１のプロトコルサービス１１２に再接続および再リンクされた後、残っている接続のそれぞれは、ホストサービス１１６への最後の「ホップ」が再確立されるまで、以前再接続した「ホップ」に再接続および再リンクされることができる。最後の「ホップ」が再確立または再リンクされた後、または各「ホップ」が再確立または際リンクされた際のいずれかに、ステップ８０８で維持されたキューに入れたデータパケットは、ステップ８１６で伝送されることができる。
【０１５３】
以下、図１０Ａおよび１０Ｂを参照して、図６Ａ乃至６Ｄの例示的実施態様を使用した、（例えば、図９のステップ８１２で）クライアント１０８を１つ以上のホストサービス１１６へ再接続する方法９００の一実施態様を示す。ステップ９０４で、クライアント１０８と第１のプロトコルサービス１１２との間のうちの残りの接続を中断する。例えば、接続１３５ａは失敗したが、接続１３５ｂは失敗していない場合、接続１３５ｂを中断する。あるいは、接続１３５ｂは失敗したが、接続１３５ａは失敗していない場合、接続１３５ａを中断する。
【０１５４】
一実施態様では、例えば、図８のステップ７２０で、クライアント１０８に提供した中間ノード６３２の実際のアドレスを使用して、ステップ９０８で、クライアント１０８のクライアントエージェント１２８は、次いでクライアントエージェント１２８と中間ノード６３２との間の第１のプロトコル接続１３５ａを再確立する。あるいは、別の実施態様では、例えば、図８のステップ７２０で、クライアント１０８に提供した第３の計算ノード６４６の実際のアドレスを使用して、ステップ９０８で、クライアント１０８のクライアントエージェント１２８は、次いでクライアントエージェント１２８と第３の計算ノード６４６との間の第１のプロトコル接続を再確立する。第３の計算ノード６４６は、クライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード６３２を判断する。一実施態様では、第３の計算ノード６４６は、ロードバランシング式を使用して中間ノード６３２を選択する。クライアント１０８の１つ以上のホストサービス１１６への再接続において、第３の計算ノード６４６によって選択された中間ノード６３２は、例えば、図８のステップ７２０で、クライアント１０８を１つ以上のホストサービス１１６に最初に接続するために、その選択とは異なることができる。一実施態様では、選択した中間ノード６３２のための最初の接続チケットは、クライアント１０８をホストサービス１１６へ再接続する際に生成される。
【０１５５】
中間ノード６３２を選択すると、第３の計算ノード６４６は、中間ノード６３２への第１のプロトコル接続１３５ａを再確立する。従って、第１のプロトコル接続１３５ａは、第３の計算ノード６４６を介して、クライアント１０８のクライアントエージェント１２８と中間ノード６３２との間に再確立される。一実施態様では、中間ノード６３２への第１のプロトコル接続１３５ａが再確立されると、第１のプロトコル接続１３５ａはこの「ホップ」のための第１または第２の再接続チケットをチケットオーソリティ１３６で有効にすることにより、有効化される。
【０１５６】
一実施態様では、１つより多いレベルの中間ノード６３２が存在する場合、クライアントエージェント１２８がレベル「ａ」乃至「ｎ−１」で送られる中間ノード６３２は、例えばロードバランシング式に基づいて、次のレベルで接続される中間ノード６３２を判断する。あるいは、別の実施態様では、第３の計算ノード６４６は、複数またはすべてのレベル「ａ」乃至「ｎ」に対して、それを介してクライアントエージェント１２８が送られる中間ノード６３２を判断する。その他の実施態様では、中間ノード６３２または計算ノードの１つ（例えば、第３の計算ノード６４６）のいずれかが、１つ以上の接続またはクライアントエージェント１２８が送られる「ホップ」のための第１または第２の再接続チケットを生成する。
【０１５７】
クライアント１０８のクライアントエージェント１２８と中間ノード６３２との間の第１のプロトコル接続１３５ａ、例えば、レベル「ｎ」の中間ノード１３２（以下、方法９００において中間ノード６３２と称する）を確立すると、次いでクライアントエージェント１２８は、ステップ９１２で、クライアント１０８のための第１の再接続チケットおよび第２の再接続チケットを中間ノード６３２に伝送する。
【０１５８】
次いで、ステップ９１６で、第１の再接続チケットが有効かどうかを判断する。一実施態様では、第１の再接続チケットの有効性は、チケットオーソリティ１３６を使用することによって判断される。例えば、中間ノード６３２は、第１の再接続チケットをチケットオーソリティ１３６に伝送する。一実施態様では、チケットオーソリティ１３６は、第１の再接続チケットの有効性を、以前に保存した第１の再接続チケットのコピーと比較することによって判断する。チケットオーソリティ１３６が第１の再接続チケットを有効であると判断した場合、ステップ９２０で、チケットオーソリティ１３６は、第１のプロトコルサービス１１２のアドレスを中間ノード６３２に伝送する。あるいは、チケットオーソリティ１３６が第１の再接続チケットを無効であると判断した場合、ステップ９２４で、クライアント１０８は、第１のプロトコルサービス１１２への再接続を拒否し、結果的に、ホストサービス１１６に接続する。
【０１５９】
ステップ９２８で、第１の再接続チケットは、例えばチケットオーソリティ１３６によって削除され、代替の第１の再接続チケットが、例えばチケットオーソリティ１３６により生成される。さらに、代替のハンドルが、例えばチケットオーソリティ１３６により生成されることができる。一部のこのような実施態様では、チケットオーソリティ１３６は、代替の第１の再接続チケットおよび代替のハンドルを中間ノード６３２に伝送する。さらに、一部のこのような実施態様では、チケットオーソリティ１３６は、代替の第１の再接続チケットのコピーを保存する。一部の実施態様では、チケットオーソリティ１３６は、クライアント１０８が第１の再接続チケットの削除に進む前に代替の第１の再接続を受信したことを認識するまで待つ。
【０１６０】
第１の再接続チケットの検証後、中間ノード６３２は、第１のプロトコルサービス１１２のアドレスを使用して、ステップ９３２で、中間ノード６３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１３５ｂを再確立する。中間ノード６３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１３５ｂを再確立すると、次いでステップ９３６で、第２の再接続チケットが有効かどうかを判断する。一実施態様では、第２の再接続チケットの有効性は、第１のプロトコルサービス１１２を使用することによって判断する。例えば、中間ノード６３２は、第２の再接続チケットを第１のプロトコルサービス１１２に伝送する。一実施態様では、第１のプロトコルサービス１１２は、第２の再接続チケットの有効性を、以前に保存した第２の再接続チケットのコピーと比較することによって判断する。ステップ９３６の別の実施態様では、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２とホストサービス１１６との間、または別の実施態様において、第１のプロトコルサービス１１２と別の第１のプロトコルサービス１１２または中間ノード６３２と間の接続のための第１の再接続チケットを有効にする。従って、同様に、第１のプロトコルサービス１１２とホストサービス１１６との間の各「ホップ」は、クライアント１０８を代表する「ホップ」の継続使用を有効にするための最初のまたは再接続チケットいずれかの１つ以上のチケットによって有効にされる。
【０１６１】
第１のプロトコルサービス１１２が第２の再接続チケットを有効であると判断した場合、第１の中間ノード１３２と第１のプロトコルサービス１１２との間で再確立された第１のプロトコル接続１３５ｂは、ステップ９４０で、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間で維持された第２のプロトコル接続１２４にリンクされる。さもなければ、第１のプロトコルサービス１１２が第２の再接続チケットを無効であると判断した場合、再確立された第１のプロトコル接続１３５ｂは、１つ以上の維持された第２のプロトコル接続１２４にはリンクされず、クライアント１０８は、ステップ９４４で、１つ以上のホストサービス１１６への再接続を拒否する。第１のプロトコルサービス１１２とホストサービス１１６との間の多数ホップ接続の場合、各「ホップ」は、再接続を有効にされ、ステップ９４０において、ホストサービス１１６への最後の「ホップ」が有効にされるまで、または「ホップ」の１つが再接続を拒否されるまで」、前の「ホップ」にリンクされる。
【０１６２】
ステップ９４８で、第２の再接続チケットは、例えば第１のプロトコルサービス１１２によって削除され、代替の第２の再接続チケットが、クライアント１０８への伝送のために、例えば第１のプロトコルサービス１１２により生成される。このような実施態様では、第１のプロトコルサービス１１２は、代替の第２の再接続チケットのコピーを保存する。一部の実施態様では、第１のプロトコルサービス１１２は、クライアント１０８が第２の再接続チケットの削除に進む前に代替の第２の再接続を受信したことを認識するまで待つ。クライアント１０８を再接続するための１つ以上の「ホップ」を有効にする場合、ステップ９４８において、チケットオーソリティ１３６、中間ノード６３２、計算ノードのいずれか、または１つ以上の第１のプロトコルサービス１１２によって、１つ以上の代替の再接続チケットが生成される、および／またはコピーが保存されることができる。
【０１６３】
ステップ９５２で、代替の第１の再接続チケットおよび代替の第２の再接続チケットは、クライアントに伝送される。例えば、チケットオーソリティ１３６は、中間ノード６３２を介して、代替の第１の再接続チケットをクライアント１０８に伝送することができる。さらに、一実施態様では、第１のプロトコルサービス１１２は、中間ノード６３２を介して、代替の第２の再接続チケットをクライアント１０８に伝送する。別の実施態様では、１つ以上の「ホップ」のための代替の再接続チケットを１つ以上の中間ノード６３２、計算ノードのいずれか、または１つ以上の第１のプロトコルサービス１１２に伝送することができる。
【０１６４】
あるいは、他の実施態様では、上述のように、本発明のシステム１００および方法は、クライアント１０８のための単一の再接続チケットおよび／またはクライアント１０８とホストサービス１１６との間の各「ホップ」のための単一の再接続だけを提供する。このように、第１および第２の再接続チケットの両方を使用するのではなく、例示的方法９００は、上述の単一の再接続チケットだけを使用する。このような一実施態様では、クライアント１０８のクライアントエージェント１２８には、第１のプロトコルサービス１１２のアドレスも提供される。ホストサービス１１６に再接続するために、クライアントエージェント１２８は、単一の再接続チケットを第１のプロトコルサービス１１２に直接伝送する。第１のプロトコルサービス１１２は、次いで単一の再接続チケットが有効であるかどうかを判断する。一実施態様では、第１のプロトコルサービス１１２は、単一の再接続チケットの有効性を、以前に保存した単一の再接続チケットのコピーと比較することによって判断する。第１のプロトコルサービス１１２が単一の再接続チケットを有効であると判断した場合、クライアント１０８と第１のプロトコルサービス１１２との間で再確立された第１のプロトコル接続１３５は、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間で維持された第２のプロトコル接続１２４にリンクする。さもなければ、第１のプロトコルサービス１１２が単一の再接続チケットを無効であると判断した場合、再確立された第１のプロトコル接続１３５は、１つ以上の維持された第２のプロトコル接続１２４にはリンクされず、クライアント１０８は、１つ以上のホストサービス１１６への再接続を拒否する。
【０１６５】
単一の再接続チケットの検証後、単一の再接続チケットは、例えば、第１のプロトコルサービス１１２によって削除され、代替の単一の再接続チケットが、クライアント１０８への伝送のために、例えば第１のプロトコルサービス１１２により生成される。代替の単一の再接続チケットのクライアント１０８への伝送では、第１のプロトコルサービス１１２は、代替の単一の再接続チケットのコピーを保存する。一部の実施態様では、第１のプロトコルサービス１１２は、クライアント１０８が単一の再接続チケットの削除に進む前に代替の単一の再接続を受信したことを認識するまで待つ。
【０１６６】
さらに別の実施態様では、第１および第２の再接続チケットと同様に、単一の再接続チケットは、ステップ６１２でのように、接続１３５における失敗に続いて、および／またはステップ６２０でのように、接続１３５の完全な終了に続いて、所定の時間の経過後に自動的に削除されるように構成される。
【０１６７】
本発明の趣旨および範囲から逸脱することなく、多くの修正および改良が当業者によってなされる場合がある。従って、例示的実施態様は例としての目的のみのために示されたものであり、以下の特許請求の範囲によって定義される本発明を限定するものと考えられるべきでないことは、明確に理解されなければならない。これらの特許請求の範囲は、上記の図に示し説明したものとその他の点で同一でないとしても、逐語的に説明するものおよび非現実的に異なる同等の要素を含むものとして解釈されたい。
【図面の簡単な説明】
【０１６８】
上述の本発明の他の目的、局面、特徴、および利点は、添付図面とともに以下の説明を参照することによって、より明らかになり、よりよく理解されるであろう。
【図１Ａ】図１Ａは、本発明の実施態様による、クライアントにホストサービスへの信頼できる接続を提供するシステムのブロック図である。
【図１Ｂ】図１Ｂは、本発明の実施態様による、クライアントにホストサービスへの信頼できる接続を提供するシステムのブロック図である。
【図２Ａ】図２Ａは、本発明の実施態様による、ネットワーク上で行われる通信を示す。
【図２Ｂ】図２Ｂは、本発明の別の実施態様による、ネットワーク上で行われる通信を示す。
【図３】図３は、本発明の実施態様による、ネットワーク上での通信のための第１のプロトコル内において複数の第２のプロトコルをカプセル化する過程を示す。
【図４】図４は、本発明による図１A〜１Bの通信システムの動作の実施態様を図解する流れ図である。
【図５Ａ】図５Ａは、本発明により構成される通信システムの別の実施態様を示すブロック図である。
【図５Ｂ】図５Ｂは、本発明による図５Aの通信システムの動作の実施態様を図解する流れ図である。
【図６Ａ】図６Ａは、本発明の実施態様によるクライアントをホストサービスに再接続するための構成要素をさらに含む、図１Ａの例示的システムのブロック図である。
【図６Ｂ】図６Ｂは、本発明の別の実施態様によるクライアントをホストサービスに初期に接続するための構成要素をさらに含む、図６Ａの例示的システムのブロック図である。
【図６Ｃ】図６Ｃは、本発明の別の実施態様によるクライアントをホストサービスに初期に接続し、クライアントをホストサービスに再接続するための構成要素をさらに含む、図６Ｂの例示的システムのブロック図である。
【図６Ｄ】図６Ｄは、図６Ｃのシステムの代替となる実施態様を示すブロック図である。
【図７】図７は、本発明の実施態様によるネットワーク通信のための方法を示す流れ図である。
【図８Ａ】図８Ａは、本発明の実施態様によるクライアントを複数のホストサービスに接続するための方法を示す流れ図である。
【図８Ｂ】図８Ｂは、本発明の実施態様によるクライアントを複数のホストサービスに接続するための方法を示す流れ図である。
【図８Ｃ】図８Ｃは、本発明の実施態様によるクライアントを複数のホストサービスに接続するための方法を示す流れ図である。
【図９】図９は、本発明の実施態様によるクライアントにホストサービスへの信頼できる接続を提供し、クライアントをホストサービスに再接続するための方法を示す流れ図である。
【図１０Ａ】図１０Ａは、本発明の実施態様によるクライアントをホストサービスに再接続するための方法を示す流れ図である。
【図１０Ｂ】図１０Ｂは、本発明の実施態様によるクライアントをホストサービスに再接続するための方法を示す流れ図である。
【特許請求の範囲】
【請求項１】
クライアントをホストサービスに再接続するための方法であって、
クライアントと第１のプロトコルサービスの間にある第１の接続および前記第１のプロトコルサービスとホストサービスの間にある第２の接続を介し、クライアントおよびホストサービスの間に通信セッションを提供するステップと、
前記第１の接続および前記第２の接続のうち一方における中断を検出し、前記第１の接続および前記第２の接続のうちもう一方を維持するステップと、
前記第１のプロトコルサービスにおいて第１のチケットと第２のチケットを得るステップと、
中断した接続を再確立するために前記第１のチケットを有効にするステップと、
維持された接続の使用を継続するために前記第２のチケットを有効にするステップと、
再確立された接続を維持された接続にリンクするステップと、
を含む、方法。
【請求項２】
前記中断した接続において、中断の間、前記通信セッションを維持するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記第１のプロトコルサービスおよびチケットオーソリティのうち少なくとも１つによって、前記第１のチケットおよび前記第２のチケットのうちいずれか１つを生成するステップをさらに含む、請求項１に記載の方法。
【請求項４】
前記チケットオーソリティによって、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを有効にするステップをさらに含む、請求項１に記載の方法。
【請求項５】
ウェブサーバに対し前記クライアントを認証するステップをさらに含む、請求項１に記載の方法。
【請求項６】
ウェブサーバによって、前記第１のチケットを前記クライアントへ伝送するステップをさらに含む、請求項１に記載の方法。
【請求項７】
前記クライアントによって、前記第１のチケットを前記第１のプロトコルサービスへ伝送するステップをさらに含む、請求項１に記載の方法。
【請求項８】
前記ホストサービスによって、前記通信セッションの確立時に前記クライアントを認証するステップをさらに含む、請求項１に記載の方法。
【請求項９】
前記第１のプロトコルサービスがプロキシサーバを含む、請求項１に記載の方法。
【請求項１０】
前記第１のプロトコルサービスがセキュリティゲートウェイを含む、請求項１に記載の方法。
【請求項１１】
前記クライアントおよび前記第１のプロトコルサービスが第２のプロトコルをカプセル化する第１のプロトコルを使用して通信を行い、前記第１のプロトコルサービスおよび前記ホストサービスが前記第２のプロトコルを使用して通信を行う、請求項１に記載の方法。
【請求項１２】
前記第１のチケットが前記第１の接続に有効であり、前記第２のチケットが前記第２の接続に有効である、請求項１に記載の方法。
【請求項１３】
前記第２のチケットが、前記第１のチケットが有効にされるまで使用不可能である、請求項１に記載の方法。
【請求項１４】
前記再確立された接続が、前記第１のチケットおよび前記第２のチケットが有効にされた後、前記維持された接続にリンクされる、請求項１に記載の方法。
【請求項１５】
前記第１の接続および前記第２の接続のうちいずれか１つが、中間ノードおよび１つ以上の第１のプロトコルサービスのうちいずれか１つを介して接続された複数の接続を含む、請求項１に記載の方法。
【請求項１６】
前記複数の接続のうち少なくとも１つのために第３のチケットが生成される、請求項１５に記載の方法。
【請求項１７】
前記第３のチケットが、前記複数の接続のうち少なくとも１つに対し有効にされる、請求項１６に記載の方法。
【請求項１８】
クライアントをホストサービスに再接続するためのシステムであって、
第１の接続を介しホストサービスとの通信セッションを確立するクライアントと、
前記クライアントとの前記第１の接続および前記ホストサービスとの第２の接続を確立する第１のプロトコルサービスと、
前記第１の接続および前記第２の接続のうち少なくとも１つを含む接続を維持する前記第１のプロトコルサービスと、
前記第１の接続および前記第２の接続のうち一方において中断した接続を再確立するために第１のチケットを有効にし、前記第１の接続および前記第２の接続のうちもう一方を使用するために第２のチケットを有効にする前記第１のプロトコルサービスと、
前記再確立された接続を前記維持された接続にリンクする前記第１のプロトコルサービスと、
を含む、システム。
【請求項１９】
前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを生成するチケットオーソリティをさらに含む、請求項１７に記載のシステム。
【請求項２０】
前記第１のプロトコルサービスが、前記中断した接続において、中断の間、前記通信セッションを維持する、請求項１８に記載のシステム。
【請求項２１】
前記第１のプロトコルサービスが、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを生成する、請求項１８に記載のシステム。
【請求項２２】
前記チケットオーソリティが、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを有効にする、請求項１８に記載のシステム。
【請求項２３】
ウェブサーバをさらに含み、前記ウェブサーバは前記クライアントを認証する、請求項１８に記載のシステム。
【請求項２４】
前記ウェブサーバが前記第１のチケットを前記クライアントに伝送する、請求項２３に記載のシステム。
【請求項２５】
前記クライアントが、前記第１のチケットを前記第１のプロトコルサービスに伝送する、請求項１８に記載のシステム。
【請求項２６】
前記ホストサービスが前記通信セッションの確立時に前記クライアントを認証する、請求項１８に記載のシステム。
【請求項２７】
前記第１のプロトコルサービスがプロキシサーバを含む、請求項１８に記載のシステム。
【請求項２８】
前記第１のプロトコルサービスがセキュリティゲートウェイを含む、請求項１８に記載のシステム。
【請求項２９】
前記クライアントおよび前記第１のプロトコルサービスが第２のプロトコルをカプセル化する第１のプロトコルを使用して通信を行い、前記第１のプロトコルサービスおよび前記ホストサービスが前記第２のプロトコルを使用して通信を行う、請求項１８に記載のシステム。
【請求項３０】
前記第１のチケットが前記第１の接続に有効であり、前記第２のチケットが前記第２の接続に有効である、請求項１８に記載のシステム。
【請求項３１】
前記第２のチケットが、前記第１のチケットが有効にされるまで使用不可能である、請求項１８に記載のシステム。
【請求項３２】
前記第１のプロトコルサービスが、前記第１のチケットおよび前記第２のチケットが有効にされた後、前記再確立された接続を前記維持された接続にリンクする、請求項１８に記載のシステム。
【請求項３３】
前記第１の接続および前記第２の接続のうちいずれか１つが、中間ノードおよび１つ以上の第１のプロトコルサービスのうちいずれか１つを介して接続された複数の接続を含む、請求項１８に記載のシステム。
【請求項３４】
前記複数の接続のうち少なくとも１つのために第３のチケットが生成される、請求項３３に記載のシステム。
【請求項３５】
前記第３のチケットが、前記複数の接続のうち少なくとも１つに有効である、請求項３４に記載のシステム。
【請求項１】
クライアントをホストサービスに再接続するための方法であって、
クライアントと第１のプロトコルサービスの間にある第１の接続および前記第１のプロトコルサービスとホストサービスの間にある第２の接続を介し、クライアントおよびホストサービスの間に通信セッションを提供するステップと、
前記第１の接続および前記第２の接続のうち一方における中断を検出し、前記第１の接続および前記第２の接続のうちもう一方を維持するステップと、
前記第１のプロトコルサービスにおいて第１のチケットと第２のチケットを得るステップと、
中断した接続を再確立するために前記第１のチケットを有効にするステップと、
維持された接続の使用を継続するために前記第２のチケットを有効にするステップと、
再確立された接続を維持された接続にリンクするステップと、
を含む、方法。
【請求項２】
前記中断した接続において、中断の間、前記通信セッションを維持するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記第１のプロトコルサービスおよびチケットオーソリティのうち少なくとも１つによって、前記第１のチケットおよび前記第２のチケットのうちいずれか１つを生成するステップをさらに含む、請求項１に記載の方法。
【請求項４】
前記チケットオーソリティによって、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを有効にするステップをさらに含む、請求項１に記載の方法。
【請求項５】
ウェブサーバに対し前記クライアントを認証するステップをさらに含む、請求項１に記載の方法。
【請求項６】
ウェブサーバによって、前記第１のチケットを前記クライアントへ伝送するステップをさらに含む、請求項１に記載の方法。
【請求項７】
前記クライアントによって、前記第１のチケットを前記第１のプロトコルサービスへ伝送するステップをさらに含む、請求項１に記載の方法。
【請求項８】
前記ホストサービスによって、前記通信セッションの確立時に前記クライアントを認証するステップをさらに含む、請求項１に記載の方法。
【請求項９】
前記第１のプロトコルサービスがプロキシサーバを含む、請求項１に記載の方法。
【請求項１０】
前記第１のプロトコルサービスがセキュリティゲートウェイを含む、請求項１に記載の方法。
【請求項１１】
前記クライアントおよび前記第１のプロトコルサービスが第２のプロトコルをカプセル化する第１のプロトコルを使用して通信を行い、前記第１のプロトコルサービスおよび前記ホストサービスが前記第２のプロトコルを使用して通信を行う、請求項１に記載の方法。
【請求項１２】
前記第１のチケットが前記第１の接続に有効であり、前記第２のチケットが前記第２の接続に有効である、請求項１に記載の方法。
【請求項１３】
前記第２のチケットが、前記第１のチケットが有効にされるまで使用不可能である、請求項１に記載の方法。
【請求項１４】
前記再確立された接続が、前記第１のチケットおよび前記第２のチケットが有効にされた後、前記維持された接続にリンクされる、請求項１に記載の方法。
【請求項１５】
前記第１の接続および前記第２の接続のうちいずれか１つが、中間ノードおよび１つ以上の第１のプロトコルサービスのうちいずれか１つを介して接続された複数の接続を含む、請求項１に記載の方法。
【請求項１６】
前記複数の接続のうち少なくとも１つのために第３のチケットが生成される、請求項１５に記載の方法。
【請求項１７】
前記第３のチケットが、前記複数の接続のうち少なくとも１つに対し有効にされる、請求項１６に記載の方法。
【請求項１８】
クライアントをホストサービスに再接続するためのシステムであって、
第１の接続を介しホストサービスとの通信セッションを確立するクライアントと、
前記クライアントとの前記第１の接続および前記ホストサービスとの第２の接続を確立する第１のプロトコルサービスと、
前記第１の接続および前記第２の接続のうち少なくとも１つを含む接続を維持する前記第１のプロトコルサービスと、
前記第１の接続および前記第２の接続のうち一方において中断した接続を再確立するために第１のチケットを有効にし、前記第１の接続および前記第２の接続のうちもう一方を使用するために第２のチケットを有効にする前記第１のプロトコルサービスと、
前記再確立された接続を前記維持された接続にリンクする前記第１のプロトコルサービスと、
を含む、システム。
【請求項１９】
前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを生成するチケットオーソリティをさらに含む、請求項１７に記載のシステム。
【請求項２０】
前記第１のプロトコルサービスが、前記中断した接続において、中断の間、前記通信セッションを維持する、請求項１８に記載のシステム。
【請求項２１】
前記第１のプロトコルサービスが、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを生成する、請求項１８に記載のシステム。
【請求項２２】
前記チケットオーソリティが、前記第１のチケットおよび前記第２のチケットのうち少なくとも１つを有効にする、請求項１８に記載のシステム。
【請求項２３】
ウェブサーバをさらに含み、前記ウェブサーバは前記クライアントを認証する、請求項１８に記載のシステム。
【請求項２４】
前記ウェブサーバが前記第１のチケットを前記クライアントに伝送する、請求項２３に記載のシステム。
【請求項２５】
前記クライアントが、前記第１のチケットを前記第１のプロトコルサービスに伝送する、請求項１８に記載のシステム。
【請求項２６】
前記ホストサービスが前記通信セッションの確立時に前記クライアントを認証する、請求項１８に記載のシステム。
【請求項２７】
前記第１のプロトコルサービスがプロキシサーバを含む、請求項１８に記載のシステム。
【請求項２８】
前記第１のプロトコルサービスがセキュリティゲートウェイを含む、請求項１８に記載のシステム。
【請求項２９】
前記クライアントおよび前記第１のプロトコルサービスが第２のプロトコルをカプセル化する第１のプロトコルを使用して通信を行い、前記第１のプロトコルサービスおよび前記ホストサービスが前記第２のプロトコルを使用して通信を行う、請求項１８に記載のシステム。
【請求項３０】
前記第１のチケットが前記第１の接続に有効であり、前記第２のチケットが前記第２の接続に有効である、請求項１８に記載のシステム。
【請求項３１】
前記第２のチケットが、前記第１のチケットが有効にされるまで使用不可能である、請求項１８に記載のシステム。
【請求項３２】
前記第１のプロトコルサービスが、前記第１のチケットおよび前記第２のチケットが有効にされた後、前記再確立された接続を前記維持された接続にリンクする、請求項１８に記載のシステム。
【請求項３３】
前記第１の接続および前記第２の接続のうちいずれか１つが、中間ノードおよび１つ以上の第１のプロトコルサービスのうちいずれか１つを介して接続された複数の接続を含む、請求項１８に記載のシステム。
【請求項３４】
前記複数の接続のうち少なくとも１つのために第３のチケットが生成される、請求項３３に記載のシステム。
【請求項３５】
前記第３のチケットが、前記複数の接続のうち少なくとも１つに有効である、請求項３４に記載のシステム。
【図１Ａ】
【図１Ｂ】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図６Ｄ】
【図７】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１Ｂ】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図６Ｄ】
【図７】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図９】
【図１０Ａ】
【図１０Ｂ】
【公表番号】特表２００７−５１５８５２（Ｐ２００７−５１５８５２Ａ）
【公表日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願番号】特願２００６−５３４４１０（Ｐ２００６−５３４４１０）
【出願日】平成１６年１０月８日（２００４．１０．８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０３３３３４
【国際公開番号】ＷＯ２００５／０３６８５８
【国際公開日】平成１７年４月２１日（２００５．４．２１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｍａｃｉｎｔｏｓｈ
２．Ｌｉｎｕｘ
【出願人】（５０２２３９３１３）サイトリックス システムズ， インコーポレイテッド (36)
【Ｆターム（参考）】
【公表日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願日】平成１６年１０月８日（２００４．１０．８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０３３３３４
【国際公開番号】ＷＯ２００５／０３６８５８
【国際公開日】平成１７年４月２１日（２００５．４．２１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｍａｃｉｎｔｏｓｈ
２．Ｌｉｎｕｘ
【出願人】（５０２２３９３１３）サイトリックス システムズ， インコーポレイテッド (36)
【Ｆターム（参考）】
[ Back to top ]