クライアントリダイレクトによるプライベートネットワークへの安全なアクセス提供方法およびシステム

プライベートネットワーク上で維持されているリソースへの安全なアクセスを提供するための改善された方法を開示する。安全なアクセスは、クライアント／サーバソフトウェアのクライアントソフトウエアを使用し、および／またはファイルシステムソフトウェアを用いて、公衆ネットワークを介し、提供することができる。複数のリモートユーザが、リモートネットワークの中間サーバのような、共通のアクセスポイントを介し、プライベートネットワークの少なくとも一部に、制限およびコントロールされた環境下でアクセスすることができる。

【発明の詳細な説明】
【関連出願への相互参照】
【０００１】
本出願は、２００１年１１月２日出願の米国仮出願第６０／３５０，０９７号の利益を主張する、２００２年１月２９日出願の米国特許出願第１０／０６０，７９２号の一部継続出願である。
【技術分野】
【０００２】
本発明は、クライアント／サーバコンピューティングに関し、より詳しくは、ネットワーク上で安全にリソースにアクセスするためのクライアント／サーバコンピューティングに関するものである。
【背景技術】
【０００３】
ネットスケープナビゲーターもしくはマイクロソフトエクスプローラのようなネットワークブラウザ（ブラウザアプリケーション）により、クライアントマシンのユーザは、インターネットを介して、遠隔地に位置するサーバマシンにリソースを要求し検索することができる。これらのネットワークブラウザは、遠隔地に位置するサーバマシンから提供されるハイパーテキストマークアップランゲージ（ＨＴＭＬ）ドキュメントを表示もしくは提供することができる。更に、ブラウザは、あるローカル機能を提供するために、ＨＴＭＬドキュメントに埋め込まれたスクリプトプログラムを実行することができる。
【０００４】
従来、ネットワークブラウザは、インターネットのようなパブリックネットワークにアクセスするのに用いられている。プライベートネットワーク外のコンピュータィングマシン上にあるネットワークブラウザが、プライベートネットワーク上のいかなるリソースにもアクセスできないように、プライベートネットワークは、ファイアウォールによって通常保護されている。
【０００５】
ファイアウォールは、プライベートネットワークへの外部アクセスを防ぐ上で効果的であるが、外部の個人または企業が、他人または他企業のプライベートネットワークへの少なくとも制限された範囲内でのアクセスを必要とする場合がしばしばある。たとえば、企業顧客に対するパーツのサプライヤは、企業顧客のプライベートネットワーク上で維持された情報（例えば、在庫レベルや注文）にアクセスすることにより、企業顧客により良いサービスを提供できる場合もある。従来用いられている方法の一つとしては、サプライヤのマシンに、パブリックネットワークを通じてファイアウォールを介し、プライベートネットワークにアクセスさせることが挙げられるが、この場合、ファイアウォールに「セキュリティホール」ができ、プライベートネットワークのセキュリティを深刻な危険にさらすことになる。従って、セキュリティが重要事項である場合、この従来の方法は通常許されない。他の従来の方法としては、サプライヤのマシンで仮想私設網（ＶｉｒｔｕａｌＰｒｉｖａｔｅＮｅｔｗｏｒｋ：ＶＰＮ）を確立することが挙げられる。この場合、サプライヤのマシンは、パブリックネットワークやファイアウォールを介してプライベートネットワークにアクセスすることもできるが、全てのデータ伝送は暗号化される。ファイアウォールの中には、ＶＰＮをサポートしているものもあり、ＰＰＴＰ（Ｐｏｉｎｔ−ｔｏ−ＰｏｉｎｔＴｕｎｎｅｌｉｎｇＰｒｏｔｏｃｏｌ）のような暗号化された通信を提供するプロトコルを使用することができる。ＶＰＮは、セキュアリモートアクセスを提供するが、準備、構成、管理が難しい。各ＶＰＮは、プライベートネットワークへのアクセスを許可された外部の各個人または企業にも提供されなければならない。更に、ＶＰＮは高価であり、また、各ＶＰＮは、プライベートネットワーク全体のセキュリティを、多少なりとも危険にさらすことになる。
【０００６】
したがって、プライベートネットワーク上で維持されているリソースへのセキュアリモートアクセスを提供するための改善された方法が必要とされている。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、プライベートネットワーク上で維持されているリソースへの安全なアクセスを提供するための改善された方法に関する。クライアント／サーバソフトウェアのクライアントソフトウェアを使用し、および／またはファイルシステムソフトウェアを用いて、公衆ネットワークを介し、安全なアクセスを提供することができる。また、複数のリモートユーザが、リモートネットワークの中間サーバのような、共通のアクセスポイントを介し、プライベートネットワークの少なくとも一部に、制限およびコントロールされた環境下でアクセスすることができる。リモートネットワークの一例は、プライベートネットワークでる。
【課題を解決するための手段】
【０００８】
本発明は、システム、方法、デバイスおよびコンピュータ読み取り可能メディアを含め、多くの手段で実現できる。以下、本発明のいくつかの実施形態について説明する。
【０００９】
一方法実施形態では、ネットワーク接続要求を受け、そのネットワーク接続要求を転送し、データを中間サーバに送信する。この方法は、リモートネットワークへのセキュアリモートアクセスを可能にする。
【００１０】
ネットワーク接続要求は、ローカルネットワーク上のコンピュータで受け取ることがでる。ネットワーク接続要求は、クライアント／サーバプリケーションのクライアントアプリケーションによって開始される。クライアントアプリケーションは前記コンピュータ上にあってもよい。ネットワーク接続要求は、リモートネットワーク上の宛先を含んでいてもよい。クライアント／サーバプリケーションのサーバプリケーションは、リモートネットワーク上にあってもよい。
【００１１】
ネットワーク接続要求は、コンピュータ上のＷｉｎｄｏｗｓ（登録商標）ソケットレイヤ内に転送することができる。これには、ネームスペースプロバイダ（例えば、リモートネットワーク上のドメインネームサービスルックアップに利用）およびレイヤドサービスプロバイダ（例えば、ローカルネットワークからリモートネットワークへのクライアントアプリケーションのデータ転送に利用）を用いて、ネットワーク接続要求を転送することが含まれる。ネットワーク接続要求は、コンピュータのトランスポートサービスプロバイダ（例えば、ＴＣＰ／ＩＰトランスポートサービスプロバイダ）を避けて転送することができる。ネットワーク接続要求は、リモートネットワーク内の中間サーバに転送することができる。中間サーバは、コンピュータに代わってネットワーク接続要求を行なうことができる。転送は、クライアントアプリケーションの名前、クライアントアプリケーションのチェックサム、クライアントアプリケーションのバージョン、宛先のサーバ、および宛先のポートの内の一つ又はそれ以上に基づいて行われる。転送に先立ち、ネットワーク要求は、ＷｉｎｓｏｃｋダイナミックリンクライブラリおよびＷｉｎｓｏｃｋ２ダイナミックリンクライブラリの少なくとも一方を介することができる。ネットワーク接続要求は、コンピュータ上の少なくとも一つのプロキシにより、リモートネットワーク内の中間サーバに転送することができる。
【００１２】
クライアントアプリケーションのデータは、コンピュータから中間サーバへ向けて送信することができる。セキュア・ソケット・レイヤ（ＳＳＬ）は、コンピュータと中間サーバ間の通信を暗号化することができる。クライアントアプリケーションのデータは、中間サーバからサーバプリケーションへ向けて送信することができる。様々な実施形態は、中間サーバからサーバプリケーションへ向けてクライアントアプリケーションのデータを送信したり、あるいは、実施形態外部のソフトウェアまたはハードウェアによりこれを行わせる。クライアントアプリケーションのデータは、クライアントアプリケーションのデータを中間サーバへ向けて送信する前に、コンピュータの少なくとも一ローカルアドレスおよび一ローカルポートを介して送信される。
【００１３】
いくつかの実施形態においては、クライアントアプリケーションと中間サーバとの間のセキュア接続を示すためビジュアルキューが設けられる。ネームスペースプロバイダおよびレイヤドサービスプロバイダは、自動的にコンピュータにインストールおよび／またはコンピュータからアンインストールすることができる。
【００１４】
他の方法実施形態では、ネットワーク接続要求を受け、そのネットワーク接続要求を転送し、データを中間サーバから受け取る。この方法は、リモートネットワークへのセキュアリモートアクセスを可能にする。
【００１５】
ネットワーク接続要求は、ローカルネットワーク上のコンピュータ上で受け取ることができる。ネットワーク接続要求は、リモートネットワーク上のファイルシステムに対して開始される。ネットワーク接続要求は、ファイルシステムの名前を含んでいてもよい。
【００１６】
ネットワーク接続要求は、コンピュータ上でトランスポートドライバインターフェイスを用いて転送することができ、さらにネームスペースプロバイダを使用してもよい。転送することにより、ネットワークファイルシステムトラフィックをキャプチャーすることができる。ネットワーク接続要求は、コンピュータ上のトランスポートドライバ（例えば、ＴＣＰ／ＩＰトランスポートドライバ）を避けて転送することができる。そのネットワーク接続要求は、リモートネットワーク内の中間サーバに転送することができる。中間サーバは、コンピュータに代わりネットワーク接続要求を行なう。転送は、宛先サーバおよび宛先ポートの少なくとも一方に基づいて行われる。転送前に、ネットワーク接続要求は、少なくとも一つのトランスポートドライバインターフェースフィルタを通過することができる。
【００１７】
中間サーバからのファイルシステムのコンピュータデータを受け取ることができる。セキュア・ソケット・レイヤ（ＳＳＬ）は、コンピュータと中間サーバ間の通信を暗号化することができる。ファイルシステムのデータは、リモートネットワーク上の中間サーバとファイルシステム間で転送することができる。様々な実施形態では、中間サーバとファイルシステム間でファイルシステムのデータを転送するか、あるいは、実施形態外部のハードウェアあるいはソフトウェアによりこれを行わせる。
【００１８】
いくつかの実施形態では、トランスポートドライバインターフェースは、自動的にコンピュータにインストールおよび／またはコンピュータからアンインストールすることができる。
【００１９】
種々の態様、特徴、実施形態あるいは上記のいくつかの実施形態のインプリメンテーションは、単独あるいは様々な組み合わせで用いることができる。
【００２０】
いくつかの実施形態は、ソフトウェアにおいてインプリメントできるが、ハードウェアにおいて、またはハードウェアとソフトウェアの組み合わせにおいてインプリメントすることもできる。本発明のいくつかの実施形態はまた、コンピュータ読み取り可能メディア上のコンピュータ読み取り可能コードとして実施することができる。コンピュータ読み取り可能メディアは、データを格納することができ、その後コンピュータシステムにより読み取ることができる任意のデータ記憶装置である。コンピュータ読み取り可能メディアの例としては、読み取り専用メモリ、ランダムアクセスメモリ、ＣＤ−ＲＯＭ、ＤＶＤ、磁気テープ、光学データ記憶装置、および搬送波が挙げられる。コンピュータ読み取り可能メディアはまた、コンピュータ読み取り可能コードが分散して格納され、実行されるよう、複数のネットワーク結合コンピュータシステムに分散させることができる。
【００２１】
様々な実施形態におけるコンピュータコードは、ハードウェア、ソフトウェア、あるいはハードウェアとソフトウェアの組み合わせにおいてインプリメントできる。
【００２２】
本発明の他の態様および利点は、本発明の原理を例示する添付の図面を参照した以下の詳細な説明から明白となるであろう。
【発明を実施するための最良の形態】
【００２３】
本発明は、添付の図面を参照した以下の詳細な説明により容易に理解されるであろう。図面中、同様の参照番号は、同様の構造要素を示す。
【００２４】
本発明は、プライベートネットワーク上で維持されているリソースへの安全なアクセスを提供するための改善された方法に関する。安全なアクセスは、標準ネットワークブラウザを使用し、公衆ネットワークを介して提供することができる。多数のリモートユーザは、共通のアクセスポイントを経由し、制限およびコントロールされた環境下で、プライベートネットワークの少なくとも一部にアクセスすることができる。
【００２５】
このソリューションにより、従業員、契約者、あるいはパートナーといったユーザは、プライベートネットワークへの直接接続から離れた場所にいながら、安全な方法でプライベートネットワーク上にあるリソースにアクセスすることができる。本発明のいくつかの実施形態により提供されるソリューションは、容易に設定および操作できるだけでなく、多くのリモートユーザをコスト効率の良くサポートすることもできる。
【００２６】
以下、本発明に係るこの態様の実施形態を、図１Ａ〜図２７を参照しながら説明する。しかしながら、当業者には、これらの図に関してここで述べている詳細な説明は、あくまでも説明を目的としたものであり、本発明はこれらの限定された実施形態の範囲を超えるものであることは容易に理解されるであろう。
【００２７】
図１Ａは、本発明の一実施形態に係る情報検索システム１００を示すブロック図である。情報検索システム１００は、ネットワーク１０２、クライアントマシン１０４、１０６、仲介サーバ１０８、リモートサーバ１１０、１１２、プライベートネットワーク１１４、およびプライベートサーバ１１６、１１８を備えている。ネットワーク１０２は、クライアントマシン１０４、１０６、仲介サーバ１０８、およびリモートサーバ１１０、１１２の通信を可能にする通信媒体としての役割を果たす。ネットワーク１０２は、例えば、インターネット、広域ネットワーク、あるいはローカルエリアネットワークを含むデータネットワークである。インターネットとは、相互に接続されたコンピュータのグローバネットワークのことをいう。プライベートネットワーク１１４は、さらに、仲介サーバ１０８およびプライベートサーバ１１６、１１８の通信を可能にする通信媒体としての役割も果たす。ネットワーク１１４はまた、データネットワークでもある。プライベートネットワーク１１４はエンティティに関連付けられていることが多いため、プライベートネットワーク１１４上でコンピューティングデバイスを操作する従業員は、プライベートサーバ１１６、１１８と通信することができる。例えば、プライベートネットワーク１１４は、企業ネットワークあるいはイントラネットと呼ぶことができる。しかしながら、外部コンピュータィングデバイスによるプライベートネットワーク１１４へのアクセスは、一般にファイアウォール（図示なし）により制限されている。仲介サーバ１０８は、ファイアウォールを介してプライベートネットワーク１１４と通信することが許可されている。ここで、クライアントマシン（リクエスタ）が認可および許可されている範囲で、仲介サーバ１０８はクライアントマシン（リクエスタ）に代わりプライベートネットワーク１１４と通信する。仲介サーバ１０８は、外部コンピューティングデバイスにプライベートネットワーク１１４へアクセスさせる範囲を実質的にコントロールする。
【００２８】
本発明のいくつかの実施形態によれば、プライベートサーバ１１６、１１８上にあるコンテンツに対する要求は、クライアントマシン１０４、１０６から受け取ることができる。ここで使用されているように、「コンテンツ」とは、サーバ上に格納することができ、クライアントが検索することのできるあらゆる情報またはリソースのことである。一般に、コンテンツは電子ファイルとして表示され、テキストおよび／またはイメージを含む。しばしば、クライアントマシン１０４、１０６は、ネットワーク１０２およびプライベートネットワーク１１４を介してコンテンツの要求および検索を容易にするブラウザアプリケーションを操作する。そのような場合、ブラウザアプリケーションが同一のコンテンツを表示することができるよう、コンテンツは、多くの場合、ブラウザを通して表示可能なドキュメント（例えば、マークアップ言語ドキュメント、ウェブページなど）としてブラウザアプリケーションに返される。クライアントマシン１０４、１０６は、仲介サーバ１０８と通信する。まず、仲介サーバ１０８は、コンテンツを求めているクライアントマシン１０４、１０６が、プライベートネットワーク１１４へのそのようなアクセスに認証および許可されているかどうか判断する。認証および許可検査を正常に終えた後、仲介サーバ１０８は、次に、クライアントマシン１０４、１０６に代わりプライベートネットワーク１１４上にあるプライベートサーバ１１６、１１８にアクセスする。仲介サーバ１０８が、要求されたコンテンツをプライベートサーバ１１６、１１８から得ると、仲介サーバ１０８は、クライアントマシン１０４、１０６に要求されたコンテンツを直接返すか、あるいは要求されたコンテンツをまず修正した後、クライアントマシン１０４、１０６に送信することができる。
【００２９】
仲介サーバ１０８は、要求されたコンテンツを様々な形式で修正することができる。一例として、仲介サーバ１０８は、クライアントマシン１０４、１０６に送信する前に、要求されたコンテンツにツールバーを挿入することができる。別の例としては、仲介サーバ１０８は、一仲介サーバ（例えば、仲介サーバ１０８）に転送されるように、要求されたコンテンツ内のハイパーリンクを修正することができる。仲介サーバ１０８は、要求されたコンテンツに関して、その他様々なタスクを実行することができる。さらに、情報検索システム１００はまた、サーバに格納された情報の仲介サーバ１０８における集中格納をサポートすることもできる。サーバに格納された情報は、「クッキー」と呼ばれることが多いが、クッキーは、通常クライアントマシンに格納される。
【００３０】
図１Ａに示した報検索システム１００は、一対のクライアントマシン、一対のリモートサーバ、単一の仲介サーバ、および一対のプライベートサーバのみを示しているが、情報検索システム１００は、多くのクライアントマシンおよび多くのサーバマシンをサポートできるものと理解されたい。情報検索システム１００はまた、多数の仲介サーバもサポートすることができることも理解されたい。
【００３１】
図１Ｂは、本発明の一実施形態に係る情報検索システム１５０を示すブロック図である。情報検索システム１５０は、例えば、図１に示した情報検索システム１００の更に詳細なインプリメンテーションである。
【００３２】
情報検索システム１５０は、インターネット１５２と、有線または無線手段を介してインターネット１５２に接続したクライアントマシン１５４、１５６とを利用している。一般に、クライアントマシン１５４、１５６は、ネットワークブラウザまたはメールアプリケーションといったクライアント側アプリケーションを操作する。クライアントマシン１５４、１５６のリクエスタ（ユーザ）が、リモートリソースにアクセスすることを望む場合、リソース要求がクライアントマシン１５４、１５６からインターネット１５２を介して仲介サーバ１５８に送られる。一般に、クライアントマシン１５４、１５６と仲介サーバ１５８間の通信は、暗号化技術（例えば、セキュア・ソケット・レイヤ（ＳＳＬ））によって保護される。仲介サーバ１５８は、イントラネット１６０へのアクセスを可能にする。クライアントマシン１５４、１５６により要求されているリソースは、イントラネット１６０内にある。一般に、ファイアウォールは、イントラネット１６０への外部アクセスを制限または排除するため、仲介サーバ１５８は、ファイアウォール１６２を介してイントラネットと通信することができなければならない。イントラネット１６０は、一般に、電子的にアクセスすることができる様々な異なったタイプのリソースを含む。一般に、これらのリソースは、イントラネットに接続した、またはその一部をなすサーバマシンに格納されている。図１Ｂに示しているように、イントラネット１６０は、認証サーバ１６４、ウェブサーバ１６６、メールサーバ１６８、ファイルサーバ１７０、およびログサーバ１７２に接続されているか、またはそれらを備えている。よって、所定のクライアントマシンは、仲介サーバ１５８を経由し、イントラネット１６０内またはイントラネット１６０上にあるサーバ１６４〜１７２のいずれにもアクセスすることができる。従って、所定のクライアントマシンは、ネットワークブラウザアプリケーションを使用し、ウェブサーバ１６６上にあるリソースを要求し受け取ることができる。別の例として、所定のクライアントマシンは、クライアント側メールアプリケーションを使用し、メールサーバ１６８上にあるメールリソースにアクセスすることができる。更に別の例として、所定のクライアントマシンは、イントラネット１６０内またはイントラネット１６０上にあるファイルサーバ１７０にアクセスし、そこで電子ファイルを得る、格納する、あるいは表示することができる。
【００３３】
仲介サーバ１５８は、仲介サーバ１５８を介したイントラネット１６０へのアクセスが継続的に確実に保護されるよう構成される。この点で、イントラネット１６０上にあるリソースまたはコンテンツにアクセスしようとしているリクエスタは、認証されなければならない。認証には、イントラネット１６０内またはイントラネット１６０上にある認証サーバ１６４を利用することができる。この点に関しては、イントラネット１６０が利用するネイティブの認証技術を、仲介サーバ１５８でリクエスタを認証する際に使用することができる。更に、管理者は、様々なリクエスタ（例えば、クライアントマシンのユーザ）に、イントラネット１６０内またはイントラネット１６０上の種々のリソース（例えば、サーバ）に対し、異なったアクセス権を与えることができるように仲介サーバ１５８を構成することができる。ログサーバ１７２は、仲介サーバ１５８における、イントラネット１６０へのアクセス要求に関するログ情報の格納を可能にする。ログ情報は、ユーザがよりよく認識できるように、アプリケーションレベルごとに提供することができる。
【００３４】
図２Ａは、本発明の一実施形態に係る仲介サーバ２００を示すブロック図である。仲介サーバ２００は、例えば、図１に示した仲介サーバ１０８としての使用に適している。仲介サーバはまた、中間サーバとも称される。
【００３５】
仲介サーバ２００は、仲介サーバにより利用される処理装置により実行されるコンピュータプログラムコードにより一般にインプリメントされる様々な処理モジュールを含む。より詳しくは、仲介サーバ２００の処理モジュールは、ウェブサーバ２０２およびプロトコルハンドラ２０４を含む。ウェブサーバ２０２は、リンク２０６により（ネットワークを介して）クライアントマシンに接続され、プロトコルハンドラ２０４は、リンク２０８により（ネットワークを介して）リモートサーバに接続される。ウェブサーバ２０２およびプロトコルハンドラ２０４は互いに通信すると同様に、様々な支援モジュールおよびデータ記憶装置２１０とも通信する。データ記憶装置２１０は、仲介サーバ２００により維持されている様々なデータ項目の永続性または不揮発性の記憶を可能にする。一般に、一クライアントマシンを使用する各ユーザまたはリクエスタに対し、データ記憶装置は個別に記憶することを可能にする。
【００３６】
処理モジュールは、認証マネージャ２１２およびアクセスマネージャ２１４を備えている。認証マネージャ２１２は、リクエスタが、申告通り本人かどうかを判断する役目を果たす認証処理を管理する。認証処理は、仲介サーバ２００内部または外部で行われる。例えば、外部認証は、プライベートネットワーク（例えば、認証サーバ１６４）内の認証サーバにより提供される。アクセスマネージャ２１４は、プライベートネットワーク上の様々なリソースへのアクセスを制限する。すなわち、異なるリクエスタに、様々なアクセス権レベル、タイプ、あるいはエリアを割り当てることができる。例えば、リクエスタＡは、サーバＸにはアクセスできるが、サーバＹおよびＺにはアクセスできず、リクエスタＢは、サーバＹには読み出し専用でアクセスできるが、サーバＸおよびＺにはアクセスできない。
【００３７】
仲介サーバ２００はまた、コンテンツトランスフォーマ２１６も備えている。これは、リモートサーバから受け取った要求コンテンツを解析した後、所定の方法でコンテンツを修正するのに使用される、別の処理モジュールである。
【００３８】
仲介サーバ２００が備えている場合もある別の処理モジュールは、クッキーマネージャ２１８である。クッキーマネージャは、リモートサーバから受け取る「クッキー」が、データ記憶装置２１０に格納され、データ記憶装置２１０に前もって格納されたものが適切なタイミングでリモートサーバに送信されるように「クッキー」を管理する。より一般的には、「クッキー」は、サーバに格納された情報のことを指す。そのようなサーバに格納された情報は、多くの場合、リモートサーバにより設定され、セッション、状態、あるいは識別を目的として使用される。
【００３９】
図２Ｂは、本発明の一実施形態に係るリモートアクセスシステム２５０を示すブロック図である。リモートアクセスシステム２５０は、クライアント／サーバ環境下で作動し、クライアントのユーザが、リモートサーバでリソースにアクセスできるようにする。具体的には、リモートアクセスシステム２５０は、ネットワークブラウザ２５４およびメールクライアント２５６を備えている。ネットワークブラウザ２５４およびメールクライアント２５６は、クライアントマシン上で作動又は実行されるクライアントアプリケーションである。一般に、ユーザまたはリクエスタは、リモートサーバにあるリソースを要求するために、これら一以上のクライアントプログラムと対話する。ネットワークブラウザ２５４およびメールクライアント２５６は、セキュアリンクあるいは接続を介して仲介サーバ２５２に接続される。仲介サーバ２５２はまた、セキュアまたは非セキュア接続あるいはリンクのいずれかを通じてリモートサーバに接続される。仲介サーバ２５２は、プライベートネットワーク上で見られるサーバのような様々な異なったサーバへの接続をサポートすることができる。プライベートネットワークの一例は、企業ネットワークである。図２Ｂに示したサーバは、ウェブサーバ２５８、Ｅメールサーバ２６０、Ｗｉｎｄｏｗｓ（登録商標）ファイルサーバ２６２、ＵＮＩＸ（登録商標）ファイルサーバ２６４、認証サーバ２６６、およびログサーバ２６８を備えている。
【００４０】
仲介サーバ２５２は、フロントエンドプロトコルハンドラレイヤ２７０に達する前にクライアントアプリケーションとの接続またはリンクに暗号化処理を提供するセキュア・ソケット・レイヤ（ＳＳＬ）２７２を備えている。フロントエンドプロトコルハンドラレイヤ２７０は、様々なクライアントアプリケーションにより利用され得る、送信されてくる異なったタイプのプロトコルを処理するため、複数のプロトコルハンドラを有する。図２１３に示されているように、フロントエンドプロトコルハンドラレイヤ２７０は、ＨＴＴＰ、ＩＭＡＰ、ＳＭＴＰ、ＰＯＰ、およびＭＡＰＩのプロトコル用に個別のプロトコルハンドラを有する。送られてくる要求に、適切なプロトコルハンドラが利用された後、仲介サーバ２５２内の他の機能モジュールが利用される。具体的には、アクセスマネージャ２７４は、要求を送信したリクエスタに、要求しているタイプのアクセスが許可されているかどうか判断することができる。認証マネージャ２７６は、リクエスタが認証され得るかどうか判断することができる。コンテンツトランスフォーマ２７８は、受信したリクエスト、またはリモートサーバにより提供された要求されたレスポンスのコンテンツを変換することができる。システム管理マネージャ２８０は、アクセス権、システム構成、およびログイン機能を構成するために、システム管理者が仲介サーバ２５２と対話できるようにする。
【００４１】
仲介サーバ２５２はまた、バックエンドプロトコルハンドラ２８２も有する。バックエンドプロトコルハンドラ２８２は、特定のサーバに関して、送信されてくる通信および発信される通信に適切なプロトコルを提供する。図２Ｂに示されているバックエンドプロトコルハンドラのレイヤは、ＨＴＴＰ、ＩＭＡＰ、ＳＭＴＰ、ＰＯＰ、ＳＭＢ、ＮＦＳ、ＮＩＳ、ＲＡＤＩＵＳ、ＬＤＡＰ、およびＮＴのプロトコル用のプロトコルハンドラを有する。仲介サーバ２５２に送信されてくるプロトコルと、仲介サーバ２５２から発信されるプロトコルとが異なる場合、コンテンツトランスフォーマ２７８は、プロトコルを変換（例えば、翻訳）することができる。さらに、仲介サーバ２５２は、データストア２８４、ログマネージャ２８６、およびデータ同期マネージャ２８８を有する。データストア２８４は、仲介サーバ２５２の様々なコンポーネントに一時的または半永久的なデータの格納を可能にする。例えば、認証を目的としたローカルレコードは、各クライアントまたはリクエスタのために、データストア２８４に格納することができる。さらに、クライアントまたはリクエスタのためのセッションＩＤまたはクッキーも、データストア２８４に集中的に格納できる。データ同期マネージャ２８８は、フォルトトレランスを提供するため、一仲介サーバと別の仲介サーバとの接続を可能にするモジュールである。従って、一仲介サーバが機能しなくなった場合、機能しなくなった仲介サーバは、リンク２９０を介して作動している仲介サーバに接続することができ、一般に一仲介サーバに関連したオペレーションのうちのいくつかあるいは全てを提供することができる。ログマネージャ２８６は、仲介サーバ２５２を介してなされる様々なアクセス要求のアプリケーションレベルのロギングを可能にするために設けられている。ログマネージャ２８６により作成されたログは、ログサーバ２６８に格納される。
【００４２】
図３は、本発明の一実施形態に係る要求処理３００を示すフローチャートである。図１Ａに示した仲介サーバ１０８、図１Ｂに示した仲介サーバ１５８、図２Ａに示した仲介サーバ２００、または、図２Ｂに示した仲介サーバ２５２といった仲介サーバが、リクエスタからの要求を受け取ると、常に要求処理３００が実行される。
【００４３】
要求処理３００は、受信した要求がシステムログイン要求かどうかを判断する決定３０２から始まる。受信した要求が、システムログイン要求であると決定３０２で判断されると、要求処理３００はリクエスタを認証しようとする３０４。認証は、ローカルまたはリモートで行なわれる。認証についての更なる詳細を以下記載する。その後、決定３０６により、リクエスタが認証されたかどうか判断される。決定３０６により、リクエスタを認証することができないと判断された場合、ログインの試みは失敗に終わり、ログインページがリクエスタに返される３０８。そのログインページは、リクエスタによるログインの再試行を容易にする。ログイン要求が失敗に終わった場合、オペレーション３０８をもって要求処理３００は完了し終了となる。
【００４４】
また、決定３０６で、リクエスタが認証されると判断された場合には、セッションＩＤがリクエスタに返される３１０。リクエスタは、コンテキストによって、クライアントデバイスのユーザあるいはクライアントデバイスに照会することができる。セッションが実行中である限り、セッションＩＤは仲介サーバへの次の要求に使用される。さらに、最初のアクセスページが、リクエスタに返される３１２。最初のアクセスページから、リクエスタはプライベートネットワーク上で利用可能な様々なリソースにアクセスすることができる。ログイン要求が達成された場合、オペレーション３１２をもって、要求処理３００は完了し終了となる。
【００４５】
ログイン要求の処理に加えて、要求処理３００はさらに、仲介サーバを介して他のすべてのリモートアクセス要求を処理すべく機能する。従って、決定３０２で、受信した要求がシステムログイン要求ではないと判断された場合、決定３１４で、受信した要求が有効なセッションＩＤを有するかどうか判断される。リクエスタが既に認証されており（つまり、仲介サーバにログインしている）、セッションがまだ有効であれば、受信した要求は有効なセッションＩＤを有するであろう。従って、決定３１４で、受信した要求に関連したセッションＩＤが有効ではないと判断された場合、仲介サーバへのアクセスは拒否され、ログインページがリクエスタに返される３０８。あるいは、決定３１４で、セッションＩＤが有効であると判断された場合、決定３１６で、セッションがタイムアウトしているかどうか判断される。決定３１６で、セッションはタイムアウトしていると断定された場合、仲介サーバへのアクセスは拒否され、ログインページがリクエスタに返される３０８。ここで、リクエスタが、無効のセッションＩＤを有するか、セッションがタイムアウトしている場合、リクエスタはログインし認証を得るよう強いられる。
【００４６】
一方、決定３１６で、セッションはタイムアウトしていないと断定された場合、リクエスタは、仲介サーバを介してプライベートネットワークにアクセスすることが許される。その後、リクエスタがアクセスしようとしているアクセスのタイプによって、更なる処理が行われ、リクエスタが、確実に適切かつ対象とみなされるリソースのみにアクセスするようにする。特に、要求処理３００に関しては、リクエスタに関連したアクセス権が得られる３１８。アクセス権は、リクエスタがどのリソースにアクセスする権利を与えられているかを示す。次に、決定３２０で、受信した要求に関連した特定のアクセスタイプが許可されるかどうか判断される。決定３２０で、受信した要求に関連したアクセスタイプが許可されていないと判断された場合、アクセスを拒否されたページは、リクエスタに返される３２２。また、決定３２０で、受信した要求のアクセスのタイプが許可されていると判断された場合、受信した要求は許可され３２４、処理される。この場合、この受信した要求の処理により、リクエスタは、プライベートネットワークの保護されたリソースにアクセス（例えば、表示、検索など）することができる。オペレーション３２２および３２４をもって要求処理３００は完了し、アクセスが許可される場合のみ、受信した要求が処理され終了となる。
【００４７】
図４は、本発明の一実施形態に係る認証処理４００を示すフローチャートである。認証処理４００は、例えば、図３に示した認証オペレーション３０４に関連した処理である。
【００４８】
認証処理４００は、リクエスタ（ユーザ）に関するローカルレコードが存在するかどうか判断する決定４０２で開始される。リクエスタに関するローカルレコードが存在すると決定４０２で判断された場合、決定４０４で、内部または外部認証が必要かどうか判断される。ここで、ローカルレコードは、内部または外部認証が行なわれるべきかどうかを示す。内部又は外部認証が行なわれるべきかどうかを示す他に、ローカルレコードは更に他の有用な情報、例えば、リクエスタ（ユーザ）の名前、最後にログインした時間、アカウントステータスなどを格納することもできる。決定４０４で、内部認証が行われるべきであると判断された場合、認証されるべく処理されるログイン要求と共に提供されたパスワードがハッシュされる４０６。ハッシングとは、文字列を、オリジナルの文字列を示す「キー」と呼ばれる別の文字列に変換することである。ハッシュ機能によりハッシングオペレーションが行われる。ハッシングは、暗号化および復号化コンテキストにおいて行なわれることが多い。
【００４９】
次に、決定４０８で、ハッシュされたパスワードが、格納されたハッシュパスワードと一致するかどうか判断される。決定４０８で、一致すると判断された場合、認証が得られたとみなされる４１０。また、決定４０８で、一致しないと判断された場合、認証に失敗したとみなされる４１２。さらに、決定４０８で、一致しないと判断された場合、アクセス失敗もログに記録させることができる４１４。一実施形態では、ログはログサーバにより提供することができる。アクセス失敗のロギング４１４は、後にログを閲覧する際、生じたアクセス失敗の性質についての理解を容易にする、アプリケーションレベル情報を提供することができる。オペレーション４１０および４１４をもって、認証処理４００は完了し、ログイン要求が正しいパスワードを有しているかどうかにより、認証が得られるかまたは得られず終了となる。
【００５０】
一方、決定４０２で、リクエスタに関するローカルレコードが存在しないと判断された場合、決定４１６で、ローカル設定が必要かどうか判断される。システム設定を用いて、ローカルレコードが必要かどうか示すことができる。管理者は、このようなシステム設定を用いてローカルレコードを有するユーザのみにアクセスを限定することができる。決定４１６で、ローカル設定が必要であると判断された場合、利用可能なローカルレコードがないため、認証に失敗したとみなされる４１２。ここでも、アクセス失敗を記録することができる４１４。また、決定４１６で、ローカル設定は必要ではないと判断された場合、あるいは、決定４０４で、外部認証が行なわれるべきであると判断された場合、認証に使用される外部認証サーバ（ＥＡＳ）のアドレスおよびタイプが得られる４１８。別の処理は、一般に、異なったタイプの外部認証サーバで行なわれる。通常、これらの外部認証サーバは、認証を行なうことを目的としてプライベートネットワーク内に前もって設けられている。一般に、使用される特定の外部認証サーバを示すシステム設定がある。従って、認証処理４００には、そのような外部認証サーバによって提供されるネイティブ認証機能を利用することができる。以下、図７に関する説明により、異なるタイプの外部認証に関する更なる詳細を提供する。
【００５１】
次に、決定４２０で、外部認証が得られたかどうか判断される。ここで、外部認証は示された特定タイプの外部認証により行われる。決定４２０で、外部認証が得られないと判断された場合、認証に失敗したものとみなされる４１２。更に、上述のように、アクセス失敗をログすることができる４１４。一方、決定４２０で、外部認証が得られたと判断された場合、認証が得られたとみなされる４２２。オペレーション４２２をもって、認証処理４００は完了し、リクエスタは認証され終了する。
【００５２】
図５は、本発明の一実施形態に係るアクセス権処理５００を示すフローチャートである。アクセス権処理５００は、例えば、図３の決定３２０によって行なわれる処理である。すなわち、アクセス権処理５００は、要求されているアクセスタイプが、特定のリクエスタに許可されるかどうかを判断する。事実上、アクセスタイプにより、リクエスタによるアクセスを制限するために使用することのできる様々な基準が提供される。図５に示した実施形態に関して、その基準には、ソースインターネットプロトコル（ＩＰ）アドレス、時刻、およびオペレーションが含まれる。
【００５３】
アクセス権処理５００は、受信した要求に関連したソースＩＰアドレス（すなわち、リクエスタ）が認可されるかどうかが判断される決定５０２で始まる。決定５０２で、受信した要求に関連したソースＩＰアドレスが認可されないと判断された場合、アクセス権処理５００はアクセスを拒否する５０４。ここで、認可されていないアクセスの危険性を低減するため、アクセス権処理５００は、確実に既知のリクエスタのＩＰアドレスだけがプライベートリソースにアクセスすることができるようにする。
【００５４】
決定５０２で、ソースＩＰアドレスが認可されると判断された場合、決定５０６で、要求がなされている時間が、時刻アクセス制限の条件を満たすかどうか判断される。一般に、この制限は、全リクエスタ、あるいはそれぞれ個別のリクエスタに対して設定することができる。ここで、必要であれば、仲介サーバを構成し、ある一定の期間のみプライベートリソースへのアクセスを許可することができる。これは、例えば、営業時間内または他の限定時間内にのみアクセスを許可することができる。決定５０６で、要求を受信した時間が、許可された時間外であると判断された場合、アクセス権処理５００はアクセスを拒否する５０４。
【００５５】
要求を受信した時間が、許可された時間内であると判断された場合５０６、決定５０８で、受信した要求に関連した特定のオペレーションが許可されるかどうか判断される。ここで、送信されてきた要求は、プライベートリソースに関して様々な異なったオペレーションが行なわれることを要求することができる。これらの様々な異なったオペレーションは、提供されているアプリケーションのタイプに応じて異なる傾向にある。決定５０８を行うことにより、異なったリクエスタにより使用されることが許可されるオペレーションを制限することができる。決定５０８で、要求されているオペレーションが許可されないと判断された場合、アクセスは拒否される５０４。一方、決定５０８で、要求されたオペレーションが許可されると判断された場合、アクセスが許可される５１０。オペレーション５０４および５１０をもって、アクセス権処理５００は完全し終了となる。
【００５６】
図６は、本発明の一実施形態に係る、操作権限処理６００を示すフローチャートである。操作権限処理６００は、例えば、図５に示した決定５０８により行なわれる。操作権限処理６００は、要求されたオペレーションが許可されると判断された場合、そのようなオペレーションを実行することから、図３のオペレーション３２０および３２４に関連させることができる点にも注意されたい。
【００５７】
操作権限処理６００は、ファイルブラウズオペレーションが要求されているかどうか判断する決定６０２で始まる。決定６０２で、ファイルブラウズオペレーションが要求されていると判断された場合、決定６０４で、ファイルブラウズがリクエスタに許可されているかどうか判断される。決定６０４で、ファイルブラウズがリクエスタに許可されていないと判断された場合、アクセスは拒否され６０６、操作権限処理６００は終了する。また、決定６０４で、ファイルブラウズがリクエスタに許可されていると判断された場合、決定６０８で、読み取りまたは書き込みオペレーションが要求されているかどうか判断される。決定６０８で、書き込みオペレーションが要求されていると判断された場合、決定６１０で、書き込みアクセスが許可されているかどうか判断される。一実施形態では、決定６１０で、要求をしている特定のリクエスタによる書き込みアクセスが、許可されているかどうか判断される。決定６１０で、書き込みアクセスが許可されていないと判断された場合、アクセスは拒否され６０６、操作権限処理６００は終了する。また、決定６１０で、書き込みアクセスが許可されていると判断された場合、書き込み要求処理が行われ６１２、受信した要求を実行する。オペレーション６１２をもって、要求されたオペレーションが実行され、操作権限処理６００が終了する。
【００５８】
一方、決定６０８で、読み取りオペレーションが要求されていると判断された場合、決定６１４で、読み取りアクセスが許可されているかどうか判断される。一実施形態では、決定６１４で、要求している特定のリクエスタによる読み取りアクセスが許可されているかどうか判断される。決定６１４で、読み取りアクセスが許可されていないと判断された場合、アクセスは拒否される６０６。また、決定６１４で、読み取りアクセスが許可されていると判断された場合、読み取り要求処理が行われ６１６、要求されたオペレーションが実行される。オペレーション６１６をもって操作権限処理６００は完了し、要求されたオペレーションが実行され、終了する。
【００５９】
一方、決定６０２で、要求されたオペレーションがファイルブラウズオペレーションではないと判断された場合、決定６１８で、要求されたオペレーションがウェブブラウズオペレーションかどうか判断される。決定６１８で、要求されたオペレーションがウェブブラウズオペレーションであると判断された場合、決定６２０で、そのウェブブラウズオペレーションに関連したサーバが、リクエスタにアクセス可能かどうか判断される。決定６２０で、サーバがリクエスタにアクセス不可能であると判断された場合、アクセスは拒否される６０６。一実施形態では、仲介サーバは、特定のリクエスタによりアクセス可能なサーバのリストを保持することができる。これにより、仲介サーバは、特定のリクエスタがサーバ名によってブラウズすることができるリソースをコントロールすることができる。例えば、プライベートネットワークには多数のサーバが含まれている場合もあるが、リクエスタは、ある一定のサーバにのみアクセスできるよう、個別に制限することができる。また、決定６２０で、そのウェブブラウズオペレーションに関連したサーバが、リクエスタにアクセス可能であると判断された場合、ウェブブラウズ要求処理が行われる６２２。言い換えれば、リクエスタに特定のサーバにアクセスする権限が与えられていたため、要求されたウェブブラウズオペレーションが行われる６２２。オペレーション６２２をもって、要求されたオペレーションが実行され、操作権限処理６００は終了する。
【００６０】
一方、決定６１８で、要求されたオペレーションが、ウェブブラウズオペレーションではないと判断された場合、決定６２４で、要求されたオペレーションがＥメールオペレーションであるかどうか判断される。決定６２４で、要求されたオペレーションがＥメールオペレーションであると判断された場合、決定６２６で、Ｅメール（電子メール）がリクエスタに許可されているかどうか判断される。決定６２６で、Ｅメールがリクエスタに許可されていないと判断された場合、アクセスは拒否される６０６。ここで、仲介サーバは、特定のリクエスタによるＥメールオペレーションへのアクセスをコントロールすることができる。また、決定６２６で、Ｅメールがリクエスタに許可されている判断された場合、Ｅメール要求処理が行われる６２８。言い換えれば、リクエスタがそのオペレーションを行なうための適切な権限を持っていたため、要求されたＥメールオペレーションが実行される。オペレーション６２８をもって、要求されたオペレーションが実行され、操作権限処理６００は終了する。
【００６１】
更に、決定６２４で、要求されたオペレーションがＥメールオペレーションではないと判断された場合、決定６３０で、要求されたオペレーションが、仲介サーバにより許可されている他の何らかのオペレーションであるかどうか判断される。この場合、他のオペレーションとしては、仲介サーバにより容易になされる適切ないかなるオペレーションであってもよい。実質的に、他のオペレーションは、仲介サーバで利用可能な汎用オペレーションであってもよい。他のオペレーションはまた、プライベートネットワークにアクセスすることなく、仲介サーバが実行するローカルオペレーションのことであってもよい。ローカルオペレーションの例は多種多様であるが、ブックマークの付加、ローカルレコードの追加、編集、および削除、ファイルシェアの修正などが挙げられる。しかしながら、前記他のオペレーションは、プライベートネットワーク内で行なわれるオペレーションであってもよい。決定６３０で、要求されたオペレーションが上記他のオペレーションのうちの一つであると判断された場合、決定６３２で、当該他のオペレーションが許可されているかどうか判断される。決定６３２で、要求されたオペレーションが許可されている上記他のオペレーションのうちの一つではないと判断された場合、アクセスは拒否される６０６。また、決定６３２で、前記他のオペレーションが許可されていると判断された場合、他の要求処理が行われる６３４。オペレーション６３４をもって、操作権限処理６００は完了し、他のタイプのオペレーションが行われ、終了となる。
【００６２】
一方、決定６３０で、要求されたオペレーションが許可されている（リクエスタによる）他のオペレーションのうちの一つではないと判断された場合、操作権限処理６００は、要求されたオペレーションを行うことなく終了となる。この場合、要求されたオペレーションが、操作権限処理６００によりサポートされず、要求されたオペレーションは仲介サーバで処理されない（つまり、ブロックされる）。
【００６３】
図７は、本発明の一実施形態に係る詳細な外部認証処理７００を示すフローチャートである。詳細な外部認証処理７００は、例えば、図４に示した決定４２０に関連した詳細な処理である。詳細な外部認証処理７００は、ネットワーク情報システム（ＮＩＳ）、リモート・オーセンティケイション・ダイアル・イン・ユーザ・サービス（ＲＡＤＩＵＳ）、ライトウェイト・ディレクトリー・アクセス・プロトコル（ＬＤＡＰ）、およびＮＴドメインを含む様々な異なったタイプの外部認証システムをサポートする。従って、仲介サーバに対し行なわれる外部認証は、プライベートネットワークが提供している場合もある、様々なネイティブの認証アプローチのうちのいずれかを使用することができる。
【００６４】
詳細な外部認証処理７００は、外部認証サーバ（ＥＡＳ）がＮＩＳであるかどうか判断する決定７０２で開始される。外部認証サーバがＮＩＳである場合、ＮＩＳレコードが読み取られる７０４。その後、ログイン要求と共に提供されたパスワードが、ハッシュされる７０６。ハッシュされたパスワードは、ＮＩＳレコード内に提供されているものと比較される７０８。そして、決定７１０で、ハッシュされたパスワードが一致するかどうか判断される。パスワードが一致した場合、認証が行われる７１２。パスワードが一致しない場合、認証は失敗に終わる７１４。
【００６５】
一方、決定７０２で、外部の認証サーバがＮＩＳではないと判断された場合、決定７１６で、外部認証サーバがＲＡＤＩＵＳであるかどうか判断される。外部認証サーバがＲＡＤＩＵＳである場合、ログイン要求と共に提供されたユーザ名およびパスワードが、ＲＡＤＩＵＳの共有秘密を用いて暗号化される７１８。ＲＡＤＩＵＳの共有秘密は、一般に共有鍵である。その後、暗号化された値は、認証のためＲＡＤＩＵＳサーバに送られる７２０。そして、決定７２２で、ＲＡＤＩＵＳサーバからのレスポンスが受け取られたかどうか判断される。レスポンスは、受け取られると、認証成功か失敗かを示す７２４。
【００６６】
一方、決定７１６で、外部認証サーバがＲＡＤＩＵＳではないと判断された場合、決定７２６で、外部認証サーバがＬＤＡＰであるかどうか判断される。決定７２６で、外部認証サーバがＬＤＡＰであると判断された場合、ログイン要求と共に提供されたユーザ名とパスワードが認証のためにＬＤＡＰサーバに送られる７２８。その後、決定７３０で、ＬＤＡＰサーバからのレスポンスが受け取られたかどうか判断される。レスポンスは、受け取られると、認証成功か失敗かを示す７３２。
【００６７】
一方、決定７２６で、外部認証サーバがＬＤＡＰではないと判断された場合、決定７３４で、外部認証サーバがＮＴドメイン（ＮＴドメインサーバ）であるかどうか判断される。決定７３４で、外部認証サーバがＮＴドメインであると判断された場合、ＮＴドメインサーバから乱数が得られる７３６。その後、ログイン要求と共に提供されたパスワードは、その乱数を用いてハッシュされる７３８。次に、ハッシュされた値は、認証のためＮＴドメインサーバに送られる７４０。その後、決定７４２で、ＮＴドメインサーバからのレスポンが受け取られたかどうか判断される。レスポンスは、認証成功か失敗かを示す７４４。
【００６８】
図８Ａおよび図８Ｂは、本発明の一実施形態に係るファイルアクセス要求処理８００を示すフローチャートである。ファイルアクセス要求処理８００は、例えば、ウェブブラウズオペレーションがリクエスタによって要求された場合行われる処理である。言い換えれば、ファイルアクセス要求処理８００は、例えば、図６のブロック６２２の一実施形態により行なわれる処理であってもよい。
【００６９】
ファイルアクセス要求処理８００は、サーバが発見されているかどうか判断される決定８０２で始まる。決定８０２で、サーバが既に発見されていると判断した場合、決定８０４で、ファイルアクセス要求がフォルダコンテンツを表示しようとするものかどうか判断される。決定８０４で、ファイルアクセス要求がフォルダコンテンツの表示を望むものであると判断された場合、フォルダのコンテンツが検索される８０６。そして、検索されたコンテンツが、リクエスタに送られる８０８。
【００７０】
一方、決定８０４で、ファイルアクセス要求がフォルダコンテンツを表示しようとするものではないと判断された場合、決定８１０で、ファイルアクセス要求が新しいフォルダを要求しているものかどうか判断される。決定８１０で、ファイルアクセス要求が新しいフォルダを要求しようとしていると判断された場合、リクエスタは新しいフォルダ名の入力を促される８１２。その後、決定８１３で、フォルダ名が受け取られたかどうか判断される。決定８１３で、フォルダ名がまだ受け取られていないと判断された場合、ファイルアクセス要求処理８００はフォルダ名の入力を待つ。決定８１３で、フォルダ名が受け取られたと判断されると、新しいフォルダが作成される８１４。
【００７１】
また、決定８１０で、ファイルアクセス要求が新しいフォルダの作成を求めていないと判断された場合、決定８１６で、ファイルアクセス要求がファイルのダウンロードを求めているものかどうか判断される。決定８１６で、ファイルアクセス要求がファイルのダウンロードを求めていると判断された場合、リクエスタに対し、要求されたファイルがダウンロードされる８１８。一方、決定８１６で、ファイルアクセス要求がファイルのダウンロードを求めているものではないと判断された場合、決定８２０で、ファイルアクセス要求がファイルのアップロードを求めているものかどうか判断される。決定８２０で、ファイルアクセス要求がファイルのアップロードを求めていると判断した場合、リクエスタに対し、要求されたファイルがアップロードされる８２２。また、決定８２０で、ファイルアクセス要求がファイルのアップロードを求めていないと判断した場合、図８Ａには示していないが、更なるタイプのファイルアクセス要求を処理することができる。従って、ファイルアクセス要求がファイルのアップロードを求めているものではない（また、更なるタイプのファイルアクセス要求がサポートされていない）場合、決定８２０をもって、ファイルアクセス要求処理８００は完了し、ファイルアクセスオペレーションは実行されず終了となる。同様に、ブロック８０８、８１４、８１８、および８２２をもって、ファイルアクセス要求処理８００は完了し終了するが、要求されたファイルアクセスは実行されていない。
【００７２】
更に、決定８０２で、サーバがまだ発見されていないと判断された場合、ファイルアクセス要求処理８００は、図８Ｂに示した処理を行う。この場合、利用可能なサーバのリストがまず発見される８２４。その後、決定８２６で、リクエスタが利用可能なサーバの中から一つを選択するのを待つ。決定８２６で、サーバ選択がなされたと判断された場合、選択されたサーバに関する共有情報が検索される８２８。一実施形態では、共用情報は、リモートリクエスタなどのサードパーティと共用可能である、選択されたサーバに格納されたフォルダの情報を識別する。その後、決定８３０で、サーバに関する情報を永続的に保存するべきであるかどうか判断される。決定８３０で、サーバに関する情報を永続的に保存するべきであると判断された場合、サーバ情報は保存される８３２。サーバ情報の保存により、当該サーバは、次回システムにログインした際、利用可能なサーバを発見する必要がなくなるよう「利用可能なサーバ」となる。一方、決定８３０で、サーバに関する情報を永続的に保存すべきではないと判断された場合、ブロック８３２はバイパスされる。いかなる場合も、サーバ情報が永続的に保存されるべきではない場合、ブロック８３０をもって、また同様に、サーバ情報が永続的に保存されるべきである場合、ブロック８３２をもって、サーバを発見するための処理は完了し、よって、ファイルアクセス処理８００は、決定８０２に戻り、それ以降のオペレーションを繰り返す。
【００７３】
図９Ａ〜９Ｃは、本発明の一実施形態に係るウェブリソース要求処理９００を示すフローチャートである。ウェブリソース要求処理９００は、例えば、図１Ａに示した仲介サーバ１０８あるいは図１Ｂに示した仲介サーバ１５８といった仲介サーバにより行なわれる。ウェブリソース要求処理９００は、ウェブリソース要求を処理するために行われる。
【００７４】
まず、適切なリモートサーバのホスト名を得る９０２。一実施形態では、ホスト名はストレージから得ることができる。この場合、ストレージは、例えば、図２Ａに示したデータ記憶装置２１４であってもよい。別の実施形態では、ホスト名は、ウェブリソース要求に関連したＵＲＬから得ることができる。適切なリモートサーバのホスト名が得られた９０２後、ホスト名が検索され９０４、適切なリモートサーバのＩＰアドレスを得る。その後、リモートサーバに接続される９０６（あるいは、既に接続されている場合維持される）。次に、必要に応じて、仲介サーバとリモートサーバ間で安全なハンドシェークが行われる９０８。その後、得られたホスト名に関連するあらゆる「クッキー」が得られる９１０。オペレーション９１０をもって、仲介サーバにおけるウェブリソース要求の前処理は完了し、こうして、当該要求はリモートサーバへ転送されることができる。この時、関連した「クッキー」を備えたウェブリソースに対する要求がリモートサーバに送られる９１２。
【００７５】
その後、決定９１４で、レスポンスが受け取られたかどうか判断される。決定９１４で、レスポンスがまだ受け取られていないと判断された場合、ウェブリソース要求処理９００は、そのレスポンスを待つ。決定９１４で、レスポンスが受け取られたと判断された場合、決定９１で、レスポンス内に「クッキー」が存在するかどうか判断される。決定９１６で、「クッキー」がレスポンス内に存在すると判断された場合、「クッキー」はレスポンスから抽出される９１８。そして、抽出された「クッキー」は保存される９２０。一般に、「クッキー」は、仲介サーバ内に設けられた中央ストレージ、あるいは、仲介サーバに関連したまたは接続された他のストレージに格納される。オペレーション９２０、および「クッキー」がレスポンス内に存在しないと判断された場合は、決定９１６に引き続き、レスポンスのヘッダー内のＵＲＬが修正される９２２。
【００７６】
その後、決定９２４で、レスポンスが修正されるべきタイプのものであるかどうか判断される。この場合、一般的に、レスポンスは、ＨＴＭＬ、グラフィックス、ｐｄｆ、ＭＰＥＧあるいは他のフォーマットといった様々な形式のものであり得る。決定９２４で、レスポンスが修正できないタイプのもの（例えば、グラフィックス）であると判断された場合、レスポンスは直ちにリクエスタに送られる（または転送される）９２６。その後、決定９２８で、レスポンスが完了したかどうか判断される。決定９２８で、レスポンスが完了したと判断された場合、ウェブリソース要求処理９００は、更なるウェブリソース要求を処理することができるように、決定９１４に戻り、それ以降のオペレーションを繰り返す。また、決定９２８で、これまでのところレスポンスの一部のみがリクエスタに送信されていると判断された場合、ウェブリソース要求処理９００は、レスポンスの後続部分を同様に処理することができるように、決定９１４に戻り、それ以降のオペレーションなどを繰り返す。
【００７７】
一方、決定９２４で、レスポンスは修正可能なタイプのもの（例えば、ＨＴＭＬ）であると判断された場合、レスポンスを処理し、レスポンスがリクエスタに戻る前に修正する。図９Ｃに示した処理は、レスポンスを修正するために行うことができる処理の一実施形態である。詳細には、決定９３２では、ツールバーが求められているかどうか判断される。仲介サーバは、ツールバーを、常にまたは時によって挿入するように、あるいは、まったく挿入しないように構成することができる。ツールバーは、仲介サーバにより標準化またはカスタマイズすることができる。決定９３２で、ツールバーが求められていると判断された場合、ツールバーＨＴＭＬがレスポンスに挿入される。ツールバーＨＴＭＬによって作成されるツールバーは、仲介サーバによって提供されたフィーチャまたはファンクションを容易にするように、得られたレスポンスに付加されるコントロールあるいはコンテンツを提供することができる。
【００７８】
次に、レスポンスのＨＴＭＬ部分内の一定のＵＲＬは修正できる９３６。一実施形態では、一定のＵＲＬの修正は、得られたＨＴＭＬの一定のタグ内でＵＲＬのホスト名部分を修正することにより行なうことができる。別の実施形態では、一定のＵＲＬは、そのＵＲＬにサフィックスを付加することにより修正することができる。サフィックスは、このようにＵＲＬに追加情報を持たせる役目をする。さらに、得られたＨＴＭＬ内の言語部分をスクリプトすることにより提供または作成される一定のＵＲＬを修正することができる９３８。言語をスクリプトする例としては、Ｊａｖａ（登録商標）ＳｃｒｉｐｔとＶＢｓｃｒｉｐｔが挙げられる。一実施形態においては、得られたＨＴＭＬ内の言語部分をスクリプトすることにより提供または作成される一定のＵＲＬのホスト名部分を修正する９３８。別の実施形態においては、言語部分をスクリプトすることにより提供または作成される一定のＵＲＬを修正し９３８、補足的情報を有するサフィックスを含むようにする。以下、言語部分のスクリプトの修正に関する更なる詳細を、図１３Ａおよび図１３Ｂを参照し説明する。その後、修正されたレスポンスは、リクエスタに送信される９４０。
【００７９】
その後、決定９４２で、要求が終了したかどうか判断される。決定９４２で、要求は終了したと断定された場合、ウェブリソース要求処理９００は完了し終了となる。一方、決定９４２で、要求はまだ完了していないと判断された場合、ウェブリソース要求処理９００は、レスポンスの残りの部分が、受け取られると同時に同様に処理されるように、決定９１４に戻りそれ以降のオペレーションを繰り返す。このように、ウェブリソース要求処理９００は実行され、多数のデータ部分あるいはデータブロック中のリソース要求に対する単一のレスポンスを処理することができる。このような場合、リクエスタへの応答性が阻害されないように、ウェブリソース要求処理９００は、リモートサーバからのレスポンスを受け取るとすぐ処理することができる。この点に関して、ウェブリソース要求処理９００は、レスポンスに関連した各データ部分あるいはデータブロックに対して、オペレーション９１４〜９４２が繰り返されるようにする。
【００８０】
図１０は、本発明の一実施形態に係る情報検索システム１０００を示す図である。情報検索システム１０００は、図１Ａの情報検索システム１００または図１Ｂの情報検索システム１５０と概して同様のものである。情報検索システム１０００のオペレーションに関して、一実施形態に係るそのオペレーションを示す代表例を挙げて以下論じる。情報検索システム１０００は、クライアント１００２、データストア１００６を備えた仲介サーバ１００４、およびリモートサーバ１００８を含む。図３の要求処理３００は、既に行なわれているものとし、また、リクエスタは、試みた方法で、要求されたリソースにアクセスすることを許可されているものとする。
【００８１】
この代表的な例は、ユーザが、ウェブブラウズ要求のコンテンツ内に表示されたウェブページ中のハイパーリンクを選択することで開始される安全な要求に関する。選択されたハイパーリンクを、
ｈｔｔｐｓ：／／ｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ／ｑｕｏｔｅ／ｍｓｆｔ：ｄａｎａｉｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ
と仮定する。ここで、「ｈｔｔｐｓ」は、セキュア・ソケット・レイヤ（ＳＳＬ）を使用するプロトコルであり、「ｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ」は、「ｄａｎａｓｔｒｅｅｔ．ｃｏｍ」をドメインとし、「ｓｅｃｕｒｅ」をサブドメインとするホスト名であり、「／ｑｕｏｔｅ／ｍｓｆｔ」は、前記ハイパーリンクの選択により要求される特定のリソースへのパスであり、「ｄａｎａｉｎｆｏ」はキーワードであり、「ｗｗｗ．ｘｙｚ．ｃｏｍ」は、要求されたリソースが存在するホストある。従って、ホスト名前「ｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ」のドメインネームの検索は、この例に関する仲介サーバ１００４であるｄａｎａｓｔｒｅｅｔ．ｃｏｍのＩＰアドレスによりなされる。そして、その要求はクライアント１００２から仲介サーバ１００４へ送信される。その要求は、例えば、以下のようなものである：
ＧＥＴ：／ｑｕｏｔｅ／ｍｓｆｔ：ｄａｎａｉｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍＨＴＴＰ／１．０
Ｈｏｓｔ：ｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ
Ｃｏｏｋｉｅ：ＤＳＩＤ＝１２３ｘｙｚｚｂｃ
追加のクッキー、暗号化の容認等、他の情報も、要求内に含まれていてもよい。クッキーは、この例では、セッションクッキー（セッションＩＤ）であり、クライアント１００２に、仲介サーバ１００４を用いた使用が許可されているかどうかを判断する際に使用される。
【００８２】
安全な要求の場合には、要求内のホスト名は、要求が最終的に送信されるリモートサーバ１００８を直接識別することはできない。しかしながら、リモートサーバ１００８に関するホスト名は、要求と共に提供される情報から得られる。より詳しくは、情報（つまり、ホスト変数）は、要求と共にサフィックスとして提供される。この例において、サフィックスは、リモートサーバ１００８のホスト名が、「ｗｗｗ．ｘｙｚ．ｃｏｍ」であるという情報を含む。適切なホスト名が得られると、ホスト名（「ｗｗｗ．ｘｙｚ．ｃｏｍ」）に関するドメインネーム検索が行われる。次に、仲介サーバ１００４およびリモートサーバ１００８からの接続が行われ（あるいは、既に接続されていた場合は、維持され）、安全なハンドシェークがオプションとして行われる。その後、ホスト名およびリクエスタに関連したデータストア１００６内のあらゆるクッキーを得ることができる。次に、仲介サーバ１００４による要求は、リモートサーバ１００８に送信される。その要求は、例えば、
ＧＥＴ：／ｑｕｏｔｅ／ｍｓｆｔＨＴＴＰ／１．０
Ｈｏｓｔ：ｗｗｗ．ｘｙｚ．ｃｏｍ
Ｃｏｏｋｉｅ：ｘｙｚＵｓｅｒＩＤ＝ｓａｍ
である。他の情報も前記要求に含まれていてもよい。オリジナルの要求と共に提供されるクッキーは、仲介サーバ１００４に関したものであり、よって、リモートサーバ１００８へ要求と共に転送されることはないという点に注意されたい。
【００８３】
リモートサーバ１００８は、要求を受け取り、レスポンスヘッダーおよび要求されたリソースのコンテンツの一部または全てを送り返す。典型的なレスポンスは、以下のフォーマットを有していてもよい：
ＨＴＴＰ／１．０２００ＯＫ
Ｓｅｔ−ｃｏｏｋｉｅ：ｘｙｚｕｓｅｒＩＤ＝Ｓａｍｕａｌ，ｅｘｐｉｒｅｓ＝０１−Ｊｕｌ−２００２
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：ｔｅｘｔ／ｈｔｍｌ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：２０００
Ｌｏｃａｔｉｏｎ：ｈｔｔｐｓ：／／ｗｗｗ．ｘｙｚ．ｃｏｍ／ｑｕｏｔｅ／ｍｓｆｔ＜ＨＴＭＬ＞

＊＊
＜／ＨＴＭＬ＞
レスポンスが、設定すべき「クッキー」を含んでいたため、クッキー設定コマンドは、レスポンスから取り除かれた後、データストア１００６に保存される。次に、ヘッダー内のＵＲＬは、存在する範囲内で、仲介サーバ１００４に向けられるように修正される。この例において、位置ヘッダはフルパス（ホスト名を含む）を含む、すなわちｈｔｔｐｓ：／／ｗｗｗ．ｘｙｚ．ｃｏｍ／ｑｕｏｔｅ／ｍｓｆｔを含み、よって、これは、ｈｔｔｐｓ：／／ｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ／ｑｕｏｔｅ／ｍｓｆｔ：ｄａｎａｉｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ，ＳＳＬに修正される。この例においては、ホスト名が修正されただけでなく、ＵＲＬの終わり（つまり、サフィックス）に変数も付加されている。付加された変数情報は、要求されたリソースを持つホストサーバのインジケータおよびＳＳＬインジケータである。この例では、関連ＵＲＬの終わりに変数情報（「ｄａｎａｉｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ」）を含むように、関連ＵＲＬを修正する必要がある。関連ＵＲＬのホスト名は、現在のホスト名（「ｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ」）をそのようなパスに使用させるクライアント１００２上で作動するブラウザアプリケーションにより適切に提供される。もし必要であれば、仲介サーバ１００４にサポートされたオペレーションまたはファンクションを容易にするために、ツールバーをＨＴＭＬデータに挿入することができる。更に、得られたＨＴＭＬの一定のタグ内のＵＲＬ、または言語をスクリプトすることにより作成されたものは、仲介サーバ１００４に向けられるように修正される。
【００８４】
例えば、ＨＴＭＬデータが、
＜ａｒｅｆ＝ｈｔｔｐｓ：／／ｗｗｗ．ｘｙｚ．ｃｏｍ／ｑｕｏｔｅ／ｍｓｆｔ＞
といったハイパーリンクを含んでいた場合、ハイパーリンクは、
＜ａｒｅｆ＝ｈｔｔｐｓ：Ｈｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ
／ｑｕｏｔｅ／ｍｓｆｔ：ｄａｎａｉｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ，
ＳＳＬ＞
に修正されるであろう。
また、ＨＴＭＬデータが
＜ａｒｅｆ＝ａ．ｈｔｍｌ＞
という関連したハイパーリンクを含んでいた場合、このハイパーリンクは、
＜ａｒｅｆ＝ａ．ｈｔｍｌ：ｄａｎａｉｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ，
ＳＳＬ＞
に修正されるであろう。
ＵＲＬの終わり（すなわち、サフィックス）に提供される変数情報は、実際に末尾にある必要はない点に注意されたい。この場合、サフィックスは、一般にドメインネームの右側に示すのに使用される。事実、変数情報は、ＵＲＬ中の様々な異なった位置に（ドメインネームの左側にさえ）配置することができる。例えば、オリジナルのハイパーリンク自体が、記号「？」または「＃」に続くような変数を有する場合、一実施例において、変数情報（「ｄａｎａｉｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ」）は、オリジナルの変数を示す記号「？」または「＃」の前に配置できる。例えば、ＨＴＭＬデータが、ハイパーリンク：
＜ａｒｅｆ＝ｈｔｔｐｓ：／／ｗｗｗ．ｘｙｚ．ｃｏｍ／ｑｕｏｔｅ／ｍｓｆｔ？ｃｏｌｏｒ＝ｒｅｄ＞
を含んでいた場合、このハイパーリンクは、
＜ａｒｅｆ＝ｈｔｔｐｓ：Ｈｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ
／ｑｕｏｔｅ／ｍｓｆｔ：ｄａｎａｉｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ？
ｃｏｌｏｒ＝ｒｅｄ＞
に修正されるであろう。
また、ＨＴＭＬデータが、関連したハイパーリンク：
＜ａｒｅｆ＝ａ．ｈｔｍｌ？ｘ＝１２３４＞
を含んでいた場合、このハイパーリンクは、
＜ａｒｅｆ＝ａ．ｈｔｍｌ：ｄａｎａｉｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ？
ｘ＝１２３４＞
に修正されるであろう。
また別の例として、ＨＴＭＬデータが、関連したハイパーリンク：
＜ａｒｅｆ＝ａ．ｈｔｍｌ，ｐｏｒｔ＝１２３４＞
を含んでいた場合、このハイパーリンクは、
＜ａｒｅｆ＝ａ．ｈｔｍｌ：ｄａｎａｉｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．
ｃｏｍ，ｐｏｒｔ＝１２３４＞
に修正されるであろう。
【００８５】
図１１は、本発明の一実施形態に係るＵＲＬ修正処理１１００を示すフローチャートである。ＵＲＬ修正処理１１００は、例えば、図９Ｃのオペレーション９３６によって行われる処理である。ＵＲＬ修正処理１１００は、例えば、図２Ａに示したコンテンツトランスフォーマ２１６または図２Ｂに示したコンテンツトランスフォーマ２７８により行うことができる。
【００８６】
ＵＲＬ修正処理１１００は、レスポンスのＨＴＭＬ部分内のターゲットＵＲＬ（例えば、ウェブページ）を選択１１０２することにより開始される。一般に、一つ以上のターゲットＵＲＬが、前もってＨＴＭＬデータのスキャンにより識別される。その後、決定１１０４で、ターゲットＵＲＬが関連ＵＲＬかどうか判断される。関連ＵＲＬは、そのソースＵＲＬの特性を継承する。ソースＵＲＬは、ターゲットＵＲＬを含むウェブページ（得られたＨＴＭＬを含む）に関連したＵＲＬである。決定１１０４で、ターゲットＵＲＬが関連ＵＲＬであると判断された場合、ソースＵＲＬからのホスト名および／またはポートサフィックスが、ターゲットＵＲＬに付加される１１０６。
【００８７】
また、決定１１０４で、ターゲットＵＲＬが関連ＵＲＬではないと判断された場合、決定１１０８で、ターゲットＵＲＬが安全な要求（例えば、ＨＴＴＰＳ）に関連しているかどうか判断される。決定１１０８で、ターゲットＵＲＬに対する要求が、安全な要求であると判断された場合、安全標識（例えば、ＨＴＴＰＳ）がターゲットＵＲＬに付加される１１１０。一方、決定１１０８で、ターゲットＵＲＬが安全な要求に関連したものではないと判断された場合、オペレーション１１１０はバイパスされる。
【００８８】
オペレーション１１１０に引き続き、また、ターゲットＵＲＬが安全な要求に関連していない場合は決定１１０８の直後に、ターゲットＵＲＬと共に提供されたホスト名は、ターゲットＵＲＬのどこか他の位置に追加される１１１２。例えば、ターゲットＵＲＬと共に提供されたホスト名は、ターゲットＵＲＬにアペンドすることができる。そして、ターゲットＵＲＬと共に提供されたオリジナルのホスト名は、所定のホスト名に置き換えられる１１１４。言い換えれば、ターゲットＵＲＬに元々提供されていたホスト名は、オリジナルのホスト名が所定のホスト名に置き換えられるように効果的に書き換えられるが、オリジナルのホスト名は、ターゲットＵＲＬの一部として残る。例えば、所定のホスト名は、適切な仲介サーバのホスト名である。
【００８９】
次に、決定１１１６で、ポート番号がターゲットＵＲＬの中で指定されているかどうか判断される。決定１１１６で、ポート番号がターゲットＵＲＬの中で指定されていると判断された場合、ポート番号サフィックスが、ターゲットＵＲＬに付加される１１１８。ホスト名に続くターゲットＵＲＬの中で本来指定されていたポート番号は、削除される１１２０。
【００９０】
オペレーション１１２０に引き続き、ＵＲＬ修正処理１１００は決定１１２２を行う。さらに、決定１１１６で、ポート番号がターゲットＵＲＬ内で指定されていないと判断された場合、ポート番号処理は必要なく、決定１１２２が行われる。決定１１２２で、更にターゲットＵＲＬが処理されることになっているかどうか判断される。先に述べたように、これらのターゲットＵＲＬは、得られたＨＴＭＬデータのスキャンにより前もって識別されている。決定１１２２で、処理すべきターゲットＵＲＬがまだあると判断された場合、ＵＲＬ修正処理１１００は、更なるターゲットＵＲＬを処理できるように、オペレーション１１０２に戻り、それ以降のオペレーションを繰り返す。また、決定１１２２で、それ以上ターゲットＵＲＬはないと判断された場合、ＵＲＬ修正処理１１００は完了し、終了となる。
【００９１】
図１２は、本発明の一実施形態に係るスクリプト修正処理１２００を示すフローチャートである。スクリプト修正処理１２００は、例えば、図９Ｃに示したオペレーション９３８によって行われる。一般に、スクリプト修正処理１２００は、得られたＨＴＭＬ内のスクリプト部分を修正する働きをする。
【００９２】
スクリプト修正処理１２００は、まず、＜ｓｃｒｉｐｔ＞タグに関するＨＴＭＬデータ（例えば、得られたＨＴＭＬのデータ）をスキャンする１２０２。その後、決定１２０４で、スクリプトが見つかったかどうか判断される。決定１２０４で、スクリプトが見つからなかったと判断された場合、決定１２０６で、スキャンすべき更なるＨＴＭＬデータがあるかどうか判断される。決定１２０６で、更にスキャンすべきＨＴＭＬデータがあると判断された場合、スクリプト修正処理１２００は、オペレーション１２０２に戻り、それ以降のオペレーションを繰り返す。また、決定１２０６で、スキャンすべきＨＴＭＬデータはこれ以上ないと判断された場合、スクリプト修正処理１２００は完了し、終了となる。
【００９３】
一方、決定１２０４で、スクリプトが発見されたと判断された場合、ホスト名が後に続くテキストストリング「ｈｔｔｐ：／／」または「ｈｔｔｐｓ：／／」を配置するためスクリプトを検索する１２０８。そして、決定１２１０で、スクリプトの検索１２０８によりＵＲＬホスト名が発見されたかどうか判断される。決定１２１０で、ＵＲＬホスト名が発見されなかったと判断された場合、決定１２１２で、スクリプトの最後に達したかどうか判断される。決定１２１２で、まだスクリプトの最後に達していないと判断された場合、スクリプト修正処理１２００はオペレーション１２０８に戻り、それ以降のオペレーションを繰り返す。また、決定１２１２で、スクリプトの最後に達したと判断された場合、スクリプト修正処理１２００は、更なるスクリプトを発見し処理することができるように、オペレーション１２０２に戻り、それ以降のオペレーションを繰り返す。
【００９４】
一方、決定１２１０で、ＵＲＬホスト名が発見されたと判断された場合、書き換えられたホスト名が作成される１２１４。スクリプトに設けられたホスト名は、その書き換えられたホスト名で置き換えられる１２１６。オペレーション１２１６に引き続き、スクリプト内の更なるホスト名を同様に処理できるように、スクリプト修正処理１２００は、オペレーション１２０８に戻り、それ以降のオペレーションを繰り返す。
【００９５】
図１３Ａおよび図１３Ｂは、本発明の別の実施形態に係るスクリプト修正処理１３００を示すフローチャートである。スクリプト修正処理１３００は、例えば、図９Ｃに示したオペレーション９３８によって行われる。一般に、スクリプト修正処理１３００は、得られたＨＴＭＬのスクリプト部分を修正する働きをする。
【００９６】
スクリプト修正処理１３００は、最初に、＜スクリプト＞タグに関するＨＴＭＬデータ（例えば、得られたＨＴＭＬのデータ）をスキャンする１３０１。その後、決定１３０２で、スクリプトが発見されたかどうか判断される。決定１３０２で、スクリプトが発見されたと判断された場合、スクリプトは解析され１３０４、スクリプトに関連した所定のプロパティおよび関数を判断または検出する。その後、決定１３０６で、スクリプト内に少なくとも一つのプロパティまたは関数が発見されたかどうか判断される。決定１３０６で、少なくとも一つのプロパティまたは関数が発見されたと判断された場合、スクリプト修正処理１３００は、仲介サーバがクライアントデバイスとリモートサーバの間に配置されている場合でも、スクリプトが意図通り働くように、スクリプト内で発見されたプロパティまたは関数に関してスクリプトが修正されるように継続される。
【００９７】
とりわけ、スクリプト内で発見された各プロパティまたは関数に関しては、処理は以下のように行われる。決定１３０８で、スクリプト内で発見された、選択されたプロパティまたは関数が、クッキープロパティの読み取りに関するものかどうか判断される。決定１３０８で、識別されたプロパティまたは関数がクッキープロパティの読み取りに関するものであると判断された場合、クッキープロパティの読み取りは、ｇｅｔＣｏｏｋｉｅｓ関数呼び出しに置き換えられる１３１０。また、決定１３０８で、識別されたプロパティまたは関数がクッキープロパティの読み取りではないと判断された場合、および、オペレーション１３１０の後、決定１３１２で、識別されたプロパティまたは関数がクッキープロパティへの書き込みに関するかものであるかどうか判断される。決定１３１２で、識別されたプロパティまたは関数がクッキープロパティへの書き込みに関するものであると判断された場合、クッキープロパティへの書き込みは、ｓｅｔ＿Ｃｏｏｋｉｅｓ関数呼び出しに置き換えられる１３１４。
【００９８】
一方、決定１３１２で、識別されたプロパティまたは関数がクッキープロパティへの書き込みに関連のないものであると判断された場合、およびオペレーション１３１４の後、決定１３１６で、識別されたプロパティまたは関数が、要求を開始するプロパティへの書き込みに関するものかどうか判断される。決定１３１６で、識別されたプロパティまたは関数が、要求を開始するプロパティへの書き込みに関するものであると判断された場合、要求を開始する（引き起こす）プロパティへの書き込みが、ｓｅｔＵＲＬ関数呼び出しに置き換えられる１３１８。また、決定１３１６で、識別されたプロパティまたは関数が要求を開始するプロパティへの書き込みに関するものではないと判断された場合、およびオペレーション１３１８の後、決定１３２０で、識別されたプロパティまたは関数が、ＵＲＬを返すプロパティからの読み出しに関するものかどうか判断される。決定１３２０で、識別されたプロパティまたは関数が、ＵＲＬを返すプロパティからの読み出しに関するものであると判断された場合、ＵＲＬを返すプロパティからの読み出しは、適切なストリングに置き換えられる１３２２。
【００９９】
また、識別されたプロパティまたは関数が、ＵＲＬを返すプロパティからの読み出しに関するものではない場合は決定１３２０の後、および、オペレーション１３２２の後、決定１３２４で、スクリプト内に、更に処理を必要とするプロパティまたは関数が発見されたかどうか判断される。更なるプロパティまたは関数が発見され、処理を必要とする場合、スクリプト修正処理１３００は、更なるプロパティまたは関数を同様に処理できるように、決定１３０８に戻り、それ以降のオペレーションを繰り返す。一方、決定１３２４で、スクリプト内で発見されたプロパティまたは関数が全て処理されていると判断された場合、スクリプト修正処理１３００は、決定１３２６を行う。決定１３２６はまた、決定１３０２で、スクリプトは発見されなかったと判断された場合にも行われる。決定１３２６で、スキャンすべき更なるＨＴＭＬデータがあるかどうか判断される。決定１３２６で、スキャンすべき更なるＨＴＭＬデータがあると判断された場合、スクリプト修正処理１３００は、オペレーション１３０１に戻り、それ以降のオペレーションを繰り返す。また、決定１３２６で、スキャンすべきＨＴＭＬデータはこれ以上ないと判断された場合、スクリプト修正処理１３００は完了し、終了となる。
【０１００】
以下、ｇｅｔｃｏｏｋｉｅｓ関数、ｓｅｔ＿ｃｏｏｋｉｅｓ関数、ｓｅｔＵＲＬ関数、およびストリング置換の代表的な例を記載する。これらの例は、理解を助けるために挙げられているものであり、よって、本発明のいずれかの態様に関する限定とみなされるべきではない。以下の例では、スクリプト言語としてＪａｖａ（登録商標）Ｓｃｒｉｐｔを使用する。
【０１０１】
ｇｅｔｃｏｏｋｉｅｓ関数およびオペレーション１３１０に関する第一の例を以下説明する。この例において、スクリプトは、スクリプト命令
ｖａｒｃ＝ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ；
を含んでいる。これは、そのドキュメント（ページ）に関連したクッキーを変数ｃに割り当てるものである。このスクリプト命令は、
ｖａｒｃ＝ｇｅｔｃｏｏｋｉｅｓ（「ｏｔｈｅｒｃｏｏｋｉｅ＝ａｂｃ」）；
と置き換えられるであろう。これは、そのドキュメント（ページ）の特定のドメインおよび特定のユーザ（例えば、「ｏｔｈｅｒｃｏｏｋｉｅ＝ａｂｃ」）の仲介サーバに存在するクッキーを割り当てるものである。更に、ｇｅｔｃｏｏｋｉｅｓ関数は、その引数として仲介サーバからクッキーを取り、それにスクリプトによって設定される他のクッキーを加える。
【０１０２】
ｓｅｔｃｏｏｋｉｅｓ関数およびオペレーション１３１４に関する第二の例を以下説明する。この例において、スクリプトはスクリプト命令
ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ＝"ｓｅｌｅｃｔｉｏｎ＝ｉｊｋ；ｅｘｐｉｒｅｓ＝．．．"：
を含む。これは、ドキュメント（ページ）に関連したクッキーをブラウザに格納する。このスクリプト命令（ステートメント）は
ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ＝ｓｅｔ＿ｃｏｏｋｉｅ（"＜ｄｏｍａｉｎ＞"，"ｓｅｌｅｃｔｉｏｎ＝ｉｊｋ；ｅｘｐｉｒｅｓ＝．．．"；）；
と置き換えられる。これは、ドキュメント（ページ）に関連したクッキーをブラウザおよび仲介サーバにも格納する。ｓｅｔｃｏｏｋｉｅｓ関数は、２つの引数を含んでいる。第一の引数は、スクリプトを有するページのドメインを識別する。第２の引数は、元々ドキュメントクッキープロパティに割り当てられていた値である。ｓｅｔｃｏｏｋｉｅｓ関数は、これら２つの引数を組み合わせ、有効期限のないｓｅｒｖｅｒｃｏｏｋｉｅＸと呼ばれるクッキーを設定する。但し、Ｘは、識別数値を表す。ブラウザにより、このクッキーは仲介サーバに送られるであろう。その後、仲介サーバはユーザ用のクッキーストレージにクッキーを組み入れることができる。クッキーはまた、ユーザ用のストレージ中の既存のクッキーを失効させるために使用することができる。一旦、クッキーが仲介サーバに格納されると、仲介サーバが返送する次のページでは、ｓｅｒｖｅｒｃｏｏｋｉｅＸはもはや必要とされないため、失効する。ｓｅｔｃｏｏｋｉｅｓ関数に対する呼び出しはまた、ｓｅｒｖｅｒｃｏｏｋｉｅＸ内にあるいかなるクッキー価値をも付加するであろう。
【０１０３】
更なる説明を目的として、次の例について考えてみる。次の例では、ｗｗｗ．ｘｙｚ．ｃｏｍのページが、以下のスクリプトを有する：
ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ＝"ａ＝ｂ"；
ｖａｒｘ＝ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ；．
また、ｗｗｗ．ｘｙｚ．ｃｏｍサーバは、値"ｓａｍ"を持つ"ｉｄ１"という名前を有する仲介サーバに前もってクッキーを返しているものとする。上記コードは、
ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ＝ｓｅｔｃｏｏｋｉｅ（"ｗｗｗ．ｘｙｚ．ｃｏｍ"，"ａ＝ｂ"）；
ｖａｒｘ＝ｇｅｔｃｏｏｋｉｅ（"ｉｄ１＝ｓａｍ"）；
に変換されるであろう。
一行目により、「ａ＝ｂ−ｄｏｍａｉｎ＝ｗｗｗ．ｘｙｚ．ｃｏｍ」といった値を有するクッキー「ｓｅｒｖｅｒｃｏｏｋｉｅ（）」が設定される。従って、クッキー全体は以下のようになる：
ｓｅｒｖｅｒｃｏｏｋｉｅ（）＝ａ＝ｂ−ｄｏｍａｉｎ＝ｗｗｗ．ｘｙｚ．ｃｏｍ。
ｓｅｒｖｅｒｃｏｏｋｉｅ（）のドメイン部分は、どのドメインがクッキーを設定しているかが分かるように、仲介サーバによってのみ使用されることに注意されたい。二行目は、その最初の引数（スクリプトが書き換えられると同時に、仲介サーバによって書き込まれた）をとり、ブラウザで全てのｓｅｒｖｅｒｃｏｏｋｉｅ（）のクッキーを検査するｇｅｔｃｏｏｋｉｅｓ関数を呼び出す。それは、あらゆるｓｅｒｖｅｒｃｏｏｋｉｅＸクッキーと共に最初の引数を連結し、その結果：
ｉｄ１＝ｓａｍ；ａ＝ｂ
を返す。これは、たとえ書き換えられていなかったとしても、オリジナルのページから返されるのと同様の結果であることに注意されたい。
【０１０４】
ｓｅｔＵＲＬ関数およびオペレーション１３１８に関する第三の例を以下説明する。そのｓｅｔＵＲＬ関数は、要求をさせるプロパティを修正する働きをする。この例において、スクリプトはスクリプト命令
ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ＝"ｈｔｔｐ：／／ｗｗｗ．ｘｙｚ．ｃｏｍ／ｆｏｏ．ｈｔｍｉ"；
を含む。これは、ブラウザを新しいページに導く。このようなスクリプト命令は、
ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ＝ｓｅｔＵＲＬ
" " ，"ｈｔｔｐ：／／ｗｗｗ．ｘｙｚ．ｃｏｍ／ｆｏｏ．ｈｔｍｌ"）；
と置き換えられる。
ｓｅｔＵＲＬ関数呼び出しは、２つの引数をとる。第一の引数は仲介サーバによって書き込まれる一方で、スクリプトは書き換えられ、ＵＲＬに従うためにサフィックス（例えば、「ｄａｎａｉｎｆｏ：」）に通常設けられているあらゆるパラメーターを含んでいる。後で説明するように、これは必ずしも必要とは限らない。第二の引数は、ＵＲＬであるが、実際には、ＵＲＬを組み立てるか返信するスクリプト表現（例えば、関数呼び出し）であり得る。
【０１０５】
ｓｅｔＵＲＬ関数は、設定されているＵＲＬを検査し、ブラウザを仲介サーバに導く形式になるようにそれを書き換える。上述のように、ＵＲＬは様々な手法で修正することができる。
【０１０６】
そのページが、ホスト名修正手法を用いている場合、ホスト名が必要な情報をエンコードするため、関連ＵＲＬを修正する必要はない。前記ＵＲＬが、全ＵＲＬである場合、ｓｅｔＵＲＬ関数は、ＵＲＬを変換するために必要とする全ての情報を有する。例えば、サフィックス（例えば、「：ｄａｎａｌｎｆｏ：ｈｏｓｔ＝ｘｘｘ」）をＵＲＬにアペンドすることができる。従って、スクリプトが現われるページが、ホスト名修正手法を用いている場合、ｓｅｔＵＲＬ関数は、第一の引数を必要としない。
【０１０７】
また、スクリプトの存在するページが、ＵＲＬサフィックス手法を用いている場合、ｓｅｔＵＲＬ関数に渡される関連ＵＲＬは、それに適用されているのと同様のサフィックスを有していなければならない。この場合、仲介サーバは、ｓｅｔＵＲＬ関数に対する第一の引数として、サフィックスにおいて渡される必要のあるあらゆる引数を挿入するであろう。例えば、そのページのＵＲＬが、
ｈｔｔｐｓ：／／ｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ／ｑｕｏｔｅ／ｍｓｆｔ：ｄａｎａｌｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ
であり、そのページのスクリプト命令が、
ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ＝"／ｕｑｏｔｅ／ｉｂｍ"；
を含む場合、書き換えられたスクリプト命令は、
ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ＝ｓｅｔＵＲＬ（"Ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ"，"／ｑｕｏｔｅ／ｉｂｍ"）；
といったものになるであろう。そして、ｓｅｔＵＲＬ関数から返された結果は、
／ｑｕｏｔｅ／ｉｂｍ：ｄａｎａｌｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ
となるであろう。これは、
ｈｔｔｐｓ：／／ｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ／ｑｕｏｔｅ／ｉｂｍ：ｄａｎａｌｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ
に対するブラウザからの要求となるであろう。
また、スクリプト命令が上記の代わりに
ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ＝"ｈｔｔｐｓ：／／ｗｗｗ．ａｂｃ．ｃｏｍ／ｉｎｆｏ／ｍｓｆｔ"；
であった場合、書き換えられたスクリプト命令は、
ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ＝ｓｅｔＵＲＬ（"Ｈｏｓｔ＝ｗｗｗ．ｘｙｚ．ｃｏｍ"，"ｈｔｔｐｓ：／／ｗｗｗ．ａｂｃ．ｃｏｍ／ｉｎｆｏ／ｍｓｆｔ"）；
といったものになるであろう。そして、ｓｅｔＵＲＬ関数から返された結果は、
ｈｔｔｐｓ：／／ｓｅｃｕｒｅ．ｄａｎａｓｔｒｅｅｔ．ｃｏｍ／ｉｎｆｏ／ｍｓｆｔ：ｄａｎａｌｎｆｏ：ｈｏｓｔ＝ｗｗｗ．ａｂｃ．ｃｏｍ
となるであろう。
この場合、第二の引数が完全ＵＲＬであり、最終ＵＲＬを構築するのに必要な情報を全て含んでいるため、ｓｅｔＵＲＬ関数に対する第一の引数は必要とされないことに注意されたい。
【０１０８】
書かれた時、ブラウザにＵＲＬをフェッチさせることのできる多くの関数またはプロパティがあることに注意すべきである。例としては、
ｗｉｎｄｏｗ．ｏｐｅｎ（'ｕｒｌ'，．．．）
ｆｏｒｍ．ａｃｔｉｏｎ＝'ｕｒｌ'；
ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ＝'ｕｒｌ'；
ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ．ｒｅｐｌａｃｅ（'ｕｒｌ'）；
ｉｍａｇｅ．ｓｒｃ＝'ｕｒｌ'；
などが挙げられる。
【０１０９】
ストリング置換およびオペレーション１３２２に関する第四の実施例を、以下説明する。ストリング置換は、ＵＲＬを返すプロパティを修正する働きをする。ここで、ＵＲＬを返すプロパティから読み取るスクリプト命令は、定数ストリングと置き換えられる。この例において、スクリプトが、
ｖａｒｕｒｌ＝ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ；
を含んでいる場合、そのようなものは、
ｖａｒｕｒｌ＝"ｈｔｔｐ：／／ｗｗｗ．ｙａｈｏｏ．ｃｏｍ／ｆｏｏ．ｈｔｍｉ"；
によって置き換えられるであろう。
このオペレーションは、その環境を検査するいかなるスクリプトも、そのページの実際のＵＲＬが、予期するものとは異なることにより混乱することがないよう徹底する役目を果たす。修正を必要とするかもしれない二つ以上のプロパティがあることに注意されたい。そのような修正をすることのできるプロパティのいくつかの例としては、
ｄｏｃｕｍｅｎｔ．ｌｏｃａｔｉｏｎ（全ＵＲＬを返す）
ｄｏｃｕｍｅｎｔ．ｄｏｍａｉｎ（ＵＲＬのホスト名部分のみを返す）
が挙げられる。
【０１１０】
図１４は、本発明の一実施形態に係る、Ｅメール要求処理１４００を示すフローチャートである。Ｅメール要求処理１４００は、例えば、図６のブロック６２８で行われたＥメール要求処理としての使用に適している。
【０１１１】
Ｅメール要求処理１４００は、まず、メールクライアントとのセキュア接続を受け入れる１４０２。ここで、メールクライアントと、受け入れられている１４０２仲介サーバとの間のセキュア接続は、例えば、セキュア・ソケット・レイヤ（ＳＳＬ）を使用することにより安全なものとすることができる。次に、リクエスタは、認証のため入力を促される１４０４。一般に、リクエスタは、リクエスタを認証するために使用できる少なくとも一つのパスワードを入力するように促される１４０４。そして、決定１４０６で、パスワードが受け取られたかどうか判断される。一般に、受け取られたパスワードは、なんらかの方法でエンコードされるが、必ずしもエンコードされるとは限らない。例えば、Ｂａｓｅ６４エンコードがよく利用される。決定１４０６で、パスワードが受け取られたと判断された場合、そのパスワードは、メールサーバパスワードと認証サーバパスワードとに分けられる１４０８。一例として、受け取られたパスワードは、パスワードセパレータによって分離されたメールサーバパスワードおよび認証サーバパスワードの両方を含んでいてもよい。
【０１１２】
次に、Ｅメールサーバは、メールサーバパスワードの確認１４１０を試みる。ほぼ同時に、認証サーバパスワードは、認証サーバにより確認１４１２が試みられる。次に、決定１４１４で、ブロック１４１０および１４１２の両方の確認ができたかどうか判断される。決定１４１４で、両方の確認ができたと判断された場合、パスワードのハッシュされたバージョンが格納される１４１６。そして、Ｅメール要求に関連したメールオペレーション処理１４１８が行われる。一方、決定１４１４で、ブロック１４１０および１４１２の両方の確認ができないと判断された場合、Ｅメール要求は拒否される１４２０。オペレーション１４１８および１４２０をもって、Ｅメール要求処理１４００は完了し、終了となる。
【０１１３】
図１５は、本発明の一実施形態に係るメールオペレーション処理１５００を示すフローチャートである。メールオペレーション処理１５００は、例えば、図１４に示したブロック１４１８によって行われる処理の一例である。
【０１１４】
メールオペレーション処理１５００は、接続が時間切れあるいはクローズしたかどうかを判断する決定１５０２で始まる。この場合、接続とは、メールクライアントと仲介サーバとの間のセキュア接続のことを言う。決定１５０２で、セキュア接続が時間切れあるいはクローズしたと判断された場合、メールサーバへのＥメールアクセスは拒否される１５０４。従って、セキュア接続が時間切れあるいはクローズした場合、ブロック１５０４をもって、メールオペレーション処理は完了し終了となる。しかしながら、前記処理を続け、メールサーバにアクセスするために、リクエスタがログインし認証されるようにするため、ログインページをリクエスタに返すこともできる。
【０１１５】
その一方で、決定１５０２で、既存の接続が時間切れあるいはクローズしていないと判断された場合、決定１５０６で、メールクライアントからのコマンドを受け取ったかどうか判断される。決定１５０６で、メールクライアントからのコマンドを受け取っていないと判断された場合、メールオペレーション処理１５００は、決定１５０２に戻り、メールクライアントからのコマンドを受け取るか、接続が時間切れあるいはクローズするまで、それ以降のオペレーションを繰り返す。
【０１１６】
決定１５０６で、メールクライアントからのコマンドを受け取ったと判断されると、コマンドはメールサーバに送られる１５０８。次に、決定１５１０で、メールサーバからレスポンを受け取ったかどうか判断される。決定１５１０で、メールサーバからレスポンスをまだ受け取っていないと判断された場合、メールオペレーション処理１５００は、そのようなレスポンスを待つ。決定１５１０で、レスポンスを受け取ったと判断されると、レスポンス内の一定のユニバーサル・リソース・ロケーター（ＵＲＬ）を修正する１５１２。例えば、コンテンツトランスフォーマの一部として、リンクまたはＵＲＬは、仲介サーバを介してリンクを転送するように修正することができる。次に、レスポンスは、メールクライアントに送られる１５１４。ここで、レスポンスは、メールクライアントと仲介サーバとの間に存在する接続を用いて、メールクライアントに送られる。ブロック１５１４に引き続き、メールオペレーション処理１５００は、メールサーバに関して更なるコマンドを処理することができるように決定１５０２に戻り、それ以降のオペレーションを繰り返す。
【０１１７】
図１６は、本発明の一実施形態に係る認証処理１６００を示すフローチャートである。認証処理１６００は、図１４に示したブロック１４１２の一実施形態を表す。この実施形態では、ある条件が満たされた場合、仲介サーバは、認証サーバによるパスワードの実際の確認をバイパスまたは回避することができる。そうすることにより、認証は、多くの場合、非常に迅速、且つ、リクエスタに負担をかけたり、いらだたせたりすることなく行なうことができる。
【０１１８】
認証処理１６００は、格納されているハッシュされたパスワードが利用可能かどうか判断する決定１６０２で始まる。ハッシュされたパスワードが前もって格納されている（図１４のオペレーション１４１６）場合、そのハッシュされたパスワードは、この事項に関して後に検索され使用される。従って、決定１６０２で、格納されているハッシュされたパスワードが利用可能であると判断された場合、その格納されているハッシュされたパスワード、最後に許可された時間、および最後にパスワードが使用された時間が検索される１６０４。一般に、これらの値は、仲介サーバに関連したデータストアに格納されており、そのリクエスタに特有の保管値である。
【０１１９】
次に、決定１６０６で、受け取ったパスワードのハッシュが格納されているハッシュされたパスワードと等しいかどうか判断される。決定１６０６で、受け取ったパスワードのハッシュが、格納されているハッシュされたパスワードと等しいと判断された場合、リクエスタは事実上認証される。これは、セッションの初めに、適切なパスワードを入力し、そして認証されたためである。さらに、決定１６１０で、最後に許可されてからの時間が、セッション継続時間の上限より長いかどうか判断される。ここで、最後に許可されてから有効期限が切れていた時間の長さを示す変数を、セッション継続時間の上限と比較する。一般に、セッション継続時間の上限は、リクエスタ、あるいは仲介サーバのシステム管理者によって設定される。
【０１２０】
いかなる場合も、決定１６１０で、最後に許可されてからの時間がセッション継続時間の上限を超過していないと判断された場合、決定１６１２で、最後にパスワードが使用されてからの時間が、アイドルタイムの上限を超過しているかどうか判断される。ここで、最後にパスワードが使用されてから有効期限が切れていた時間の長さを示す変数を、アイドルタイムの上限と比較する。決定１６１２で、最後にパスワードが使用されてからの時間が、アイドルタイムの上限を超過していないと判断された場合、認証サーバと対話する必要なく、認証サーバによる認証１６１４が正常に得られたものとされる。従って、最後に許可されてからの時間がセッション継続時間の上限を超過しておらず、更に、最後にパスワードが使用されてからの時間がアイドルタイムの上限を超過していなければ、受け取ったパスワードのハッシュが、格納されているハッシュパスワードと等しい場合、許可サーバに関する認証はバイパスすることができる。
【０１２１】
一方、特別な条件が存在しない場合、パスワードは認証サーバにより確認される１６０８。例えば、決定１６０２で、格納されているハッシュパスワードが利用不可能であると判断された場合、認証サーバによる確認１６０８が行われる。同様に、決定１６０６で、受け取ったパスワードのハッシュが格納されているハッシュパスワードと等しくないと判断された場合も、認証サーバによるパスワードの確認１６０８が必要となる。さらにまた、決定１６１０で、最後に許可されてからの時間が、セッション継続時間の上限を超過していると判断された場合、または、決定１６１２で、最後にパスワードが使用されてからの時間がアイドルタイムの上限を超過していると判断された場合、パスワードは、認証サーバにより確認１６０８される必要がある。
【０１２２】
オペレーション１６０８および１６１４に引き続き、認証処理１６００は、他の処理を行うため前のオペレーション、すなわち図１４に示したオペレーション１４１４に戻る。従って、上記の特別な条件が存在するため確認１６０８がバイパスされる場合、認証処理は非常に簡素化され、多くの場合、認証サーバに関する複雑な認証処理を行なったり、リクエスタに認証情報の入力を促したりする必要がなくなる。
【０１２３】
図１７Ａと１７１３は、本発明のいくつかの実施形態により使用できるコンピュータシステムの一例を示す。このコンピュータシステムは、例えば、クライアントマシン、仲介サーバ、あるいはリモートまたはプライベートサーバのうちのいずれかに該当し得る。図１７Ａは、ディスプレイ１７２３、スクリーン１７２５、キャビネット１７２７、キーボード１７２９、およびマウス１７３１を備えたコンピュータシステム１７２１を示している。マウス１７３１は、グラフィカルユーザインターフェースとの対話のため一以上のボタンを備えていてもよい。キャビネット１７２７は、本発明のいくつかの実施形態をインプリメントするコンピュータコードを組み込むソフトウェアプログラムや、本発明のいくつかの実施形態で使用するデータ等を格納したり検索したりするのに利用できる取出し可能なメディア（例えば、ＣＤ−ＲＯＭ）ドライブ１７３３、システムメモリ、およびハードドライブ（図１７１３参照）を収容している。ＣＤ−ＲＯＭ１７３５は、典型的なコンピュータ読み取り可能記憶媒体として示しているが、フロッピー（登録商標）ディスク、テープ、ＤＶＤ、フラッシュメモリ、システムメモリ、およびハードドライブを含む他のコンピュータ読み取り可能記憶媒体を利用してもよい。さらに、搬送波（例えば、インターネットを含むネットワーク）に組み込まれたデータ信号が、コンピュータ読み取り可能記憶媒体であってもよい。一インプリメンテーションにおいて、コンピュータシステム１７２１用のオペレーティングシステムは、システムメモリ、ハードドライブ、ＣＤ−ＲＯＭ１７３５、または他のコンピュータ読み取り可能な記憶媒体に設けられ、本発明のいくつかの実施形態をインプリメントするコンピュータコードを組込む役目を果たす。
【０１２４】
図１７１３は、本発明の一実施形態に係る処理を行なうために使用されるコンピュータシステム１７２１のシステムブロック図を示す。図１７Ａに示すように、コンピュータシステム１７２１は、モニター１７２３、キーボード１７２９、およびマウス１７３１を備えている。コンピュータシステム１７２１は、更に、中央処理装置１７５１、システムメモリ１７５３、固定記憶装置１７５５（例えば、ハードドライブ）、取外し可能記憶装置１７５７（例えば、コンパクトディスク）、ディスプレイアダプタ１７５９、サウンドカード１７６１、スピーカー１７６３、およびネットワークインターフェイス１７６５等のサブシステムを備えている。中央処理装置１７５１は、例えば、コンピュータプログラムコード（例えば、オペレーティングシステム）を実行し、本発明のいくつかの実施形態をインプリメントすることができる。オペレーティングシステムは、通常、実行中はシステムメモリ１７５３内に存在するが、必ずしもそうでなくてもよい。本発明のいくつかの実施形態における使用に適した他のコンピュータシステムは、更なるサブシステムを備えていてもよいし、より少ない数のサブシステムを備えていてもよい。例えば、別のコンピュータシステムは、二以上のプロセッサ１７５１（すなわち、マルチプロセッサシステム）またはキャッシュメモリを備えていてもよい。
【０１２５】
コンピュータシステム１７２１のシステムバスアーキテクチャは、矢印１７６７で示されている。しかしながら、これらの矢印は、サブシステムをリンクする役目を果たす相互連結スキームを説明するものである。例えば、システムメモリやディスプレイアダプタに中央処理装置を接続するためにローカルバスを利用することができる。図１７Ａに示したコンピュータシステム１７２１は、単に、本発明のいくつかの実施形態での使用に適したコンピュータシステムの例に過ぎない。サブシステムの構成が異なるその他のコンピュータアーキテクチャも利用できる。
【０１２６】
上記実施形態では、情報検索システム内の単一仲介サーバの使用について説明したが、情報検索システムは複数の仲介サーバを備えていてもよいことに気付くべきである。様々な仲介サーバは、クライアントマシンから個々に要求を受け、適切なサーバに転送し、仲介サーバを介してクライアントマシンにレスポンスを返すことができる。複数のサーバを有することによって、更なる処理能力が得られるだけでなく、ロードバランシング、フォルトトレランス、およびローカライゼーション問題もさらに対処することができる。
【０１２７】
図１８は、いくつかの実施形態を示すブロック図である。いくつかの実施形態は、少なくともクライアント側の部分を含み、いくつかの実施形態は、少なくともサーバ側の部分を含み、また、いくつかの実施形態は、少なくともそれぞれ一つづつを含む。図１８は、この例ではクライアントマシンを含むクライアントネットワーク１８１０と、この例では、企業サーバを含むリモートネットワーク１８４０と、クライアントネットワーク１８１０とリモートネットワーク１８４０を接続するインターネット１８９０とを示している。クライアントマシン１８１０は、Ｗｉｎ３２アプリケーション等のクライアント／サーバプリケーションのクライアントアプリケーション１８１２と、レイヤドサービスプロバイダ（ＬＳＰ）１８１４と、ネームスペースプロバイダ（ＮＳＰ）１８１５と、セッションマネージャ１８１６と、ＷｉｎｓｏｃｋＡＰＩ１８１８とを備えている。リモートネットワーク１８４０は、クライアント／サーバプリケーションのサーバプリケーション１８４２と、ＤＮＳサーバ１８４４と、中間サーバ１８４６とを備えている。中間サーバ１８４６は、デーモン１８４８を備えている。セッションマネージャ１８１６とデーモン１８４８は、（例えば、ポート４４３を介して）通信プロトコル１８５０によりインターネット１８９０上で通信する。セッションマネージャ１８１６は、通信プロトコルクライアントと呼ぶことができる。多くの実施形態では、中間サーバはリモートネットワークの一部と考えられる。
【０１２８】
いくつかの実施形態は、セキュアアプリケーションマネージャと呼ばれる。セキュアアプリケーションマネージャのいくつかの実施形態は、クライアントと企業リソース間のネットワークレベルで分離されており、したがって、より安全である。
【０１２９】
セキュアアプリケーションマネージャのいくつかの実施形態は、クライアントソフトウェア、例えば、Ｗｉｎ３２ベースのソフトウェアを備えており、これは、リモートアクセスセキュアネットワークコネクションを、アプリケーション毎および／またはホスト毎に、中間サーバを介して安全に、企業クライアント／サーバプリケーションリソースにトランスペアレントに転送できる。例えば、中間サーバの管理者は、特定のクライアントアプリケーションから、企業リソースへのアクセスの一部または全てを保護するよういくつかの実施形態を構成することができる。クライアント側アプリケーションのいくつかの例としては、Ｏｕｔｌｏｏｋ等のＥメールアプリケーション、連絡先管理アプリケーション、またはメモ帳アプリケーション；ＳＡＰＲ／３クライアント等のクライアント側エンタープライズリソースプランニングアプリケーション、ＣｉｔｒｉｘＩＣＡ等のクライアント側アプリケーションサービスソフトウェア、インターネットエクスプローラ等のブラウザなどが挙げられる。
【０１３０】
いくつかの実施形態は、Ｗｉｎｄｏｗｓ（登録商標）（登録商標）ソケットレイヤの内でネットワーク接続要求を転送する。Ｗｉｎｄｏｗｓ（登録商標）（登録商標）ソケットレイヤは、Ｗｉｎｓｏｃｋダイナミックリンクライブラリ、Ｗｉｎｓｏｃｋ２ダイナミックリンクライブラリ、アプリケーションプログラムインターフェイス、レイヤドサービスプロバイダ（ＬＳＰ）、レイヤドサービスプロバイダのためのサービスプロバイダインターフェース、ネームスペースプロバイダ（ＮＳＰ）、ネームスペースプロバイダインターフェース、トランスポートサービスプロバイダインターフェース、およびトランスポートサービスプロバイダのうち少なくとも一つを含むことができる。
【０１３１】
図１９は、ＷｉｎｓｏｃｋアプリケーションおよびＷｉｎｄｏｗｓ（登録商標）（登録商標）ソケットレイヤを備えた実施形態を示す。図１９は、Ｗｉｎｓｏｃｋアプリケーション１９１０、ＷｉｎｓｏｃｋＡＰＩ１９１５、ＷｉｎｓｏｃｋＤＬＬ１９２０、ＷｉｎｓｏｃｋトランスポートＳＰＩおよびネームスペースＳＰＩ１９３０、ＬＳＰＳＰＩ１９３５、ＬＳＰ１９３６および１９３８、トランスポートサービスプロバイダ１９４５（図示されているＴＣＰ／ＩＰトランスポートサービスプロバイダおよびＩＰＸ／ＳＰＸトランスポートサービスプロバイダ）、およびネームスペースプロバイダ１９５５（図示されているＤＮＳネームスペースプロバイダおよびＩＰＸネームスペースプロバイダ）を示している。
【０１３２】
図２０は、ＷｉｎｓｏｃｋアプリケーションとＷｉｎｄｏｗｓ（登録商標）（登録商標）ソケットレイヤを含む別の実施形態を示す。図２０は、Ｗｉｎｓｏｃｋ２アプリケーション２０１０、Ｗｉｎｓｏｃｋ２ＡＰＩ２０１５、Ｗｉｎｓｏｃｋ２ＤＬＬ２０２０、Ｗｉｎｓｏｃｋ２トランスポートＳＰＩ２０３０、Ｗｉｎｓｏｃｋ２ネームスペースＳＰＩ２０４０、トランスポートサービスプロバイダ２０５０、およびネームスペースプロバイダ２０６０を示している。
【０１３３】
クライアントソフトウェアは、（例えば、中間サーバ上にあるＡｃｔｉｖｅＸコントロールから）ダウンロードし、起動することができる。ＬＳＰとＮＳＰは、システムにインストールすることができる。セキュアアプリケーションマネージャプロキシは、(例えば、ＡｃｔｉｖｅＸコントロールにより)ダウンロードし、起動することができる。
【０１３４】
１９９０年代の初めに、いくつかのソフトウエアベンダーが協力し、Ｗｉｎｄｏｗｓ（登録商標）（登録商標）に初めて標準化されたＴＣＰ／ＩＰ接続が導入され、これはＷｉｎｓｏｃｋとしてよく知られている。この成功に伴い、ソフトウエアベンダーは、ネットワークトラフィックストリームに接続するための多くのアプリケーションを見つけ出し、ＷｉｎｓｏｃｋＤＬＬの接続、チェーニング、および置き換えを開始した。これにより、ネットワークトラフィックをモニター、修正、または転送するためのソリューションを提供した。しかしながら、それらを提供する上で基準となる方法がなかったため、Ｗｉｎｄｏｗｓ（登録商標）（登録商標）プラットフォームに多くのコンパティビリティ問題が生じた。
【０１３５】
１９９０年代中頃に、Ｗｉｎｓｏｃｋフォーラムが、Ｗｉｎｓｏｃｋ２のスペックを作成した。この新しいＡＰＩの目的の例としては、オーバーラップした、イベントベースの入出力等、より多くのＷｉｎ３２入出力機構のサポート、複数のベンダーが、ＷｉｎｓｏｃｋＡＰＩにあらゆるタイプのネットワークプロトコルを接続することができるようプロトコルの独立性の確立、そして、Ｗｉｎｓｏｃｋ呼び出しを接続するためのメカニズム（ＬＳＰ）を標準化することが挙げられる。
【０１３６】
マイクロソフトは、Ｗｉｎｄｏｗｓ（登録商標）（登録商標）ＮＴ４．０と共に１９９６年に最初のＷｉｎｓｏｃｋ２の使用を可能にしたＯＳの販売を開始し、後にＷｉｎｄｏｗｓ（登録商標）（登録商標）９８のリリースと共に、古いシステムをＷｉｎｓｏｃｋ２にアップグレードするためにＷｉｎｄｏｗｓ（登録商標）（登録商標）９５最新版をリリースした。
【０１３７】
最初のＷｉｎｓｏｃｋ２およびベンダーＬＳＰインプリメンテーションはバグが多く、これらをベースとした製品は、限定された範囲での成功に終わった。２００３年の今日、Ｗｉｎｓｏｃｋ２フレームワークは安定し、ＬＳＰをベースにしたいくつかの製品により、その技術は証明されている。
【０１３８】
Ｗｉｎｓｏｃｋ２は、アプリケーションプログラムインターフェイス（ＡＰＩ）だけでなく、トランスポートおよびネームスペースプロバイダ双方のためのサービスプロバイダーインターフェース（ＳＰＩ）も標準化している。さらに、そのフレームワークは、トランスポートプロバイダ、別名、ＬＳＰの階層化をサポートする。実際のＷｉｎｓｏｃｋＤＬＬは、マイクロソフトによりインプリメントされ、あらゆるベンダーが自由にトランスポートおよびネームスペースプロバイダをインプリメントし、それらをシステムにインストールすることができる。レガシーＷｉｎｓｏｃｋ１ＡＰＩ（例えば、ｗｉｎｓｏｃｋ．ｄｌｌ、ｗｓｏｃｋ３２．ｄＩＩ；いずれもＷｉｎｓｏｃｋダイナミックリンクライブラリとして知られている）に書き込まれたアプリケーションは、新しいＷｉｎｓｏｃｋ２ＡＰＩ（ｗｓ２３２．ｄＩＩ、さらに、Ｗｉｎｓｏｃｋダイナミックリンクライブラリとも呼ばれる）にサンクされている。
【０１３９】
レイヤドサービスプロバイダー（ＬＳＰ）は、Ｗｉｎｄｏｗｓ（登録商標）（登録商標）で使用することができ、アプリケーションがＴＣＰ／ＩＰスタック上でカスタムトランスポートサービスを行うことを可能にするＬＳＰアーキテクチャを提供する。クライアントマシンにＬＳＰサービスがインストールさている場合、クライアントマシン上で作動するＷｉｎ３２アプリケーションは自動的にＬＳＰサービスを読み込むことができる。そして、ＬＳＰサービスは、Ｗｉｎｓｏｃｋ呼び出しに対する呼び出しの一部または全てをインターセプトすることができ、更なるカスタムトランスポートメカニズムを付加することができる。また、ネットワークデータおよび／またはＷｉｎｓｏｃｋＡＰＩからのイベントを検査、修正、および／または転送することができる。このレベルでネットワークトラフィックをキャプチャすることにより、ＬＳＰは、呼び出しアプリケーションのコンテキストにおいて実行することができ、そのプロセス情報にフルにアクセスできる。アプリケーションレベルデータへのアクセスは可能であるが、ＴＣＰおよび／またはＩＰレベルヘッダー情報へのアクセスはできない場合もある。
【０１４０】
ＬＳＰサービスは、（例えば、中間サーバにおいて）アプリケーションの設定リストから送られてくるソケット接続呼び出しの一部または全てといったトラフィックをインターセプトすることができ、セッションマネージャを介して、通信プロトコル、例えば、カスタムまたは標準プロトコルを使用するＨＴＴＰＳによる場合のように安全に送信できる。同様に、ＮＳＰは、（例えば、中間サーバにおいて）アプリケーションの設定リストから送られてくる宛先ホスト名に関するＤＮＳ照会を処理し、セッションマネージャを介して、通信プロトコル、例えば、カスタムまたは標準プロトコルを使用するＨＴＴＰＳによる場合のように安全に送信できる。
【０１４１】
セッションタイムアウト処理および／または他のアクセス機構の同時処理のために、ＬＳＰサービスは、ホストを対象としたトラフィックを無視する（ＷｉｎｓｏｃｋＡＰＩに直接渡す）ことを自動的に選択することができる。このトラフィックは、クライアント側部分がダウンロードされるホストのＩＰアドレスであってもよい。これは、たとえブラウザが、セキュアアプリケーションマネージャを介して保護されるアプリケーションとなるように構成されている場合でも可能である。
【０１４２】
いくつかの実施形態は、ＷＳＰＳｔａｒｔｕｐ（）関数をエクスポートすることができるＷｉｎ３２ＤＬＬのようなダイナミックリンクライブラリを備えている。インストーラーは、他のＬＳＰ上にレイヤとなるプロトコルおよび他のＬＳＰに関してのオーダーについて記述する一以上のプロトコルチェーンとＬＳＰとを登録することができる。アプリケーションがＷｉｎｓｏｃｋライブラリーを読み込む場合、ＷｉｎｓｏｃｋはＬＳＰのＷＳＰＳｔａｒｔｕｐ（）関数を呼び出すことができる。この時、ＬＳＰは、チェーン内で上に位置するＬＳＰまたはＷｉｎｓｏｃｋカタログにそのＳＰＩエントリーポイントを返すことができる。ＬＳＰは、チェーン内の次のプロバイダを読み込み、同様のエントリーポイント交換を行なうことができる。チェーンは、ベーストランスポートプロバイダと呼ばれるトランスポートサービスプロバイダで終わっていてもよい。この時点で、呼び出しは、カーネル内のＴＤＩプロトコルドライバに、またはＴＤＩプロトコルドライバからディスパッチすることができる。
【０１４３】
ＬＳＰは、マイクロソフトにより供給される参照インプリメンテーションをベースにすることができる。
【０１４４】
ＬＳＰプロトコルチェーンインストール／アンインストールコードは、インストーラーへの組み込みを容易にするため、自動登録機能、ＤＩＩＲｅｇｉｓｔｅｒＳｅｒｖｅｒ（）およびＤＩＩＵｎｒｅｇｉｓｔｅｒＳｅｒｖｅｒ（）を使用し、同じＤＬＬにおいてインプリメントすることができる。他の実施形態は、複数のＤＬＬにおいてインプリメントすることができる。
【０１４５】
ネームスペースプロバイダ（ＮＳＰ）は、所定のネームスペースに対しネーム解決を行なうことができる。ＴＣＰ／ＩＰネームスペースに対して、マイクロソフト・インプリメンテーションは、ＤＮＳレゾリューションを行なうことができる。ＮＳＰは、ＮＳＰＳｔａｒｔｕｐ（）関数をエクスポートするＷｉｎ３２ＤＬＬのようなダイナミックリンクライブラリを含むことができる。ＬＳＰ同様、インストーラーはＮＳＰを登録することができる。Ｗｉｎｓｏｃｋは、必要に応じてＮＳＰを読み込んだり、エントリーポイントを交換したりすることができる。ＮＳＰが階層化されている場合、例えば、複数のＮＳＰが同じネームスペースを共有して、インストールされている場合、その動作はＷｉｎｓｏｃｋ２では不確定である。
【０１４６】
ＮＳＰは、安全なリモートネットワークにＤＮＳ要求を中継するためにＤＮＳ検索をインターセプトすることができる。ＬＳＰは、Ｗｉｎｓｏｃｋｃｏｎｎｅｃｔ（）呼び出しをインターセプトし、発信ＴＣＰ接続の一部または全てを、セキュアアプリケーションマネージャプロキシに転送することができる。セキュアアプリケーションマネージャは、多数のオペレーションモードを有することができる。アプリケーションプロキシモードのような一モードにおいて、ＬＳＰは、管理者の選択したアプリケーションセットに読み込み、それらアプリケーション内の接続の一部または全てを中間サーバに転送する。宛先プロキシモードのような別のモードでは、ＬＳＰは、プロセスの一部または全てに読み込み、管理者の選択した宛先ホスト、アドレス、および／またはポートのリストに基づき転送する。
【０１４７】
ＮＳＰは、インストールすることができ、マイクロソフトＤＮＳプロバイダと共存することができる。セキュアアプリケーションマネージャＮＳＰは、ＤＮＳ要求をリモートネットワークに安全に中継することができる。マイクロソフトＷｉｎｓｏｃｋ２インプリメンテーションは、レジストリ内に列挙された順序で各プロバイダを呼び出す。照会において空でない結果を返す第一のプロバイダは、サイクルを終了し、それを有効なレスポンスであるとみなす。ＮＳＰは、Ｗｉｎｓｏｃｋ２構成ＡＰＩを用いて、指定された方法でインストールすることができ、レジストリ内に列挙されたキーの名前を交換することにより、レジストリ内で再配列することができる。
【０１４８】
マイクロソフトは、この動作の仕方を変更することができる。別の実施形態は、ＤＮＳ要求を解析しスプーフする。しかしながら、ＬＳＰからの生のＤＮＳトラフィックを解析しスプーフすることにより、どのアプリケーションがＤＮＳ要求を行なっているかのトラッキングが困難になり、アプリケーション単位でホスト名検索を行う性能が損なわれる。
【０１４９】
ＮＳＰエントリーポイントは、インストール済み環境をシンプルかつ軽量にしておくため、ＬＳＰと同じＤＬＬにインプリメントすることができる。他の実施形態は、複数のＤＬＬをインプリメントする。
【０１５０】
ＮＳＰインストール／アンインストールコードは、インストーラーへの組み込みを容易にするため、自動登録機能、ＤＩＩＲｅｇｉｓｔｅｒＳｅｒｖｅｒ（）およびＤＩＩＵｎｒｅｇｉｓｔｅｒＳｅｒｖｅｒ（）を使用し、同じＤＬＬにインプリメントすることができる。他の実施形態は、複数のＤＬＬをインプリメントする。
【０１５１】
セキュアアプリケーションマネージャプロキシは、下記のうち一つ以上のオペレーションを行なうことのできるウィンドウレスＷｉｎ３２アプリケーションであってもよい：中間サーバへの接続を管理する、ＮＳＰに対するＤＮＳ要求を行なう、ＬＳＰに関するポートマッピングを管理する、中間サーバからセキュアアプリケーションマネージャコンフィギュレーションデータを取り出す、転送テーブルを維持する。
【０１５２】
セッションマネージャ（通信プロトコルクライアント）は、例えば、ＬＳＰサービスからトラフィックの一部または全てを受け入れることができ、および／または通信プロトコルを用いて、トラフィックを中間サーバへ転送することができるＷｉｎ３２クライアント（場合によっては、ＡｃｔｉｖｅＸをベースとした）のようなクライアントであってもよい。セッションマネージャは、例えば、ＬＳＰサービスによって保護された一つ、一部、または全ての宛先ホストのループバックアドレス（１２７．０．０．１、１２７．０．０．２．など）をリスンする。
【０１５３】
セッションマネージャは、システムトレー内で実行することができ、クライアントアプリケーションに関して保護されたアプリケーションのリストを表示することができる。個々のアクティブアプリケーションに関して、このセッションマネージャは、既存のセッションマネージャと同様に、送信／受信バイト数といった、セッションのステータスを表示することもできる。
【０１５４】
通信プロトコルは、ＨＴＴＰＳセッションを用いて、ＴＣＰソケット接続をシミュレートすることができる。ソケット接続はそれぞれ、二つの半二重ＨＴＴＰＳセッション（上流および下流）を用いてシミュレートすることができる。通信プロトコルは、セッションマネージャが、ＳＳＬによりクライアント／サーバプリケーションから発信されるトラフィックの一部または全てを保護することを可能にすることができる。ＨＴＴＰＳにより送信することで、通信プロトコルは、プロキシやファイアウォールを介して作用することができる。
【０１５５】
単一ワーカースレッド（他の実施形態においては、複数のスレッドあるいはプロセス）は、これらのタスクを処理することができる一方で、個別の要求スレッド（他の実施形態においては、同一スレッドあるいは異なるプロセス）は、ＬＳＰおよび／またはＮＳＰから送られてくる要求を処理することができる。要求スレッドは、応答時間を最短化することができ、要求を行なったクライアントアプリケーションにおける不必要なブロッキングを回避することができる。ワーカースレッドにより行なわれるタスクの一部または全ては非同期であってもよく、全てのタスクを一スレッドで十分にすることができる。単一スレッドがそれらのタスクを処理することにより、パフォーマンスに何らかの問題が生じた場合、異なるワーカースレッドに関するような、いくつかのタスクを、オフロードすることができる。
【０１５６】
セキュアアプリケーションマネージャは、例えば、中間サーバ上のウェブページに組み込まれたＡｃｔｉｖｅＸコントロールから起動することができる。ＳＳＬセッション認証は、インターネットエクスプローラのようなブラウザによって処理される。セキュアアプリケーションマネージャプロキシは、起動されると、中間サーバへの接続を確立しようとすることができる。これは、現行のセッションクッキーおよび中間サーバホストの名前を用いて行なうことができる。ＡｃｔｉｖｅＸコントロールは、例えば、メモリおよびミューテックの以下の名前を持つメモリマップファイルを用いて共用メモリ領域にホストおよびクッキーを書き込むことができる。
【０１５７】
＜ｎａｍｅ＞：＜ｃｏｍｍｕｎｉｃａｔｉｏｎｐｒｏｔｏｃｏｌ＞：Ｐａｇｅｌｎｆｏｒｍａｔｉｏｎ：ＳｈａｒｅｄＭｅｍｏｒｙ
【０１５８】
＜ｎａｍｅ＞：＜ｃｏｍｍｕｎｉｃａｔｉｏｎｐｒｏｔｏｃｏｌ＞：Ｐａｇｅｌｎｆｏｒｍａｔｉｏｎ：Ｍｕｔｅｘ
【０１５９】
この共用メモリ領域が得られた場合、その場所に格納されたデータは、以下のようなフォーマットになっている。
【０１６０】
ＤａｔａＦｏｒｍａｔ：＜ｓｅｓｓｉｏｎｃｏｏｋｉｅ＞＋’ ￥（但し、原文は逆スラッシュ。以下同じ）０’＋＜ｉｖｅｈｏｓｔｎａｍｅ＞＋’ ￥０’
【０１６１】
データパラメーターは、通信プロトコルセッションを確立するために通信プロトコルＡＰＩへ渡すことができる。セッションがタイムアウトした場合、通信プロトコルＡＰＩは、セキュアアプリケーションマネージャプロキシに通知することができる。セキュアアプリケーションマネージャプロキシは、例えば、モーダルダイアログボックスのポップアップによって、ユーザに再接続することを望むか、あるいはセキュアアプリケーションマネージャを終了することを望むかをユーザに照会することができる。ユーザが、再接続することを選択した場合、セキュアアプリケーションマネージャプロキシは、セキュアアプリケーションマネージャページに、インターネットエクスプローラウィンドウのような新しいウィンドウを開くことができる。これにより、ログインを促し、セキュアアプリケーションマネージャプロキシの別のインスタンスの再起動を促すことができる。プロキシの新しいインスタンスは、前インスタンスを検知しシグナル通知し、中間サーバに再接続するために伝えることができる。新しいインスタンスは、前インスタンスをシグナル通知した後に終了することができる。
【０１６２】
中間サーバセッションが確立された状態で、セキュアアプリケーションマネージャプロキシは、新しい通信プロトコルコマンドでコンフィギュレーションデータをダウンロードすることができる。データは、「；」で分離された名前＝値の複数対のような形式で、セキュアアプリケーションマネージャプロキシまで降りて来ることができる。例としての構成ストリングは、以下のようなものであってもよい。
【０１６３】
“ｏｐｍｏｄｅ＝０；ｅｘｉｔｍｏｄｅ＝０；ａｐｐｓ＝ｏｕｔｌｏｏｋ．ｅｘｅ｜ＭｉｃｒｏｓｏｆｔＯｕｔｌｏｏｋ｜２８ｃｂ４８ｂｄ８ｆ，ｔｅｌｎｅｔ．ｅｘｅ，ｎｅｔｓｃｐ^＊；ｄｅｓｔｓ＝１０．１０．３．０／８”
【０１６４】
セキュアアプリケーションマネージャを宛先プロキシモードで実行するように構成することができる場合、ＩＰアドレス／マスク／ポートの組み合わせは、静的転送用の転送テーブルに配置することができる。ホスト名は、別のリストに配置することができ、ＤＮＳ検索結果は、実行時、そのホスト名に関連したアドレスに基づき転送することおよび／またはＩＰアドレスに関連したホスト名を通信プロトコル接続呼び出しへ渡すことを目的として転送テーブルに配置することができる。
【０１６５】
ワーカースレッドは、共有メモリキューからＤＮＳ要求を受け取り、その要求を中間サーバへ渡すことができる。結果が届くと、要求において指定されたＬＳＰ応答キューにその結果を返すことができる。中間サーバがホスト名を解決できない場合、マイクロソフトＤＮＳプロバイダに検索を行なわせることができるＮＳＰから空の結果を返すことができる。
【０１６６】
接続を開始する前に、ポートマップ要求がＬＳＰから届く。セキュアアプリケーションマネージャプロキシは、バインドするために利用可能なローカルアドレスとポート、例えばループバックアドレスとポートを見つけることができ、その関連を記録し、その双方をＬＳＰに返す。そして、ＬＳＰは、このループバックアドレスとポートへの接続を開始することができる。セキュアアプリケーションマネージャプロキシが、接続指示を受け取ると、中間サーバへの接続を開始することができる。この接続がうまくいった場合、前記ループバックアドレスから入ってくる接続が受け入れられる。一旦接続がなされれば、例えば、ＷｉｎｓｏｃｋＡＰＩおよび／または通信プロトコルＡＰＩの非同期の１０個の特性に基づいたステートマシンは、ポートマップデータを処理することができる。
【０１６７】
セキュアアプリケーションマネージャは、１２７．１．０．１で始まり、１２７．１．２５５．２５４で終わる、ポートマッピング用の一連のループバックアドレスを使用することができる。ループバックアドレスの選択方法は数多くある。一実施形態では、セキュアアプリケーションマネージャは、まず、開始アドレス１２７．１．０．１と宛先ポートをバインドすることを試みることができる。このアドレスが既に使用されている場合には、次のアドレス１２７．１．０．２にバインドすることを試みることができる。これは、バインドするために利用可能なアドレスを見つけるまで、続けることができる。６５ｋのアドレス全てが所定のポートで使用されている場合、代替のポート番号へのバインドを試み、再度１２７．１．０．１から始めることができる。
【０１６８】
ユーザインターフェースは、別個のＷｉｎ３２として構築することができる。このインプリメンテーションは、セキュアアプリケーションマネージャプロキシから抜け出すことができ、ユーザインターフェースインプリメンテーションをウィンドウレスのセキュアアプリケーションマネージャプロキシの制約から解放することができる。マイクロソフトファンデーションクラスは、ユーザインターフェースをインプリメントすることができる。これは、システムトレーアイコンを持つ隠しアプリケーションとして起動することができる。セレクション（例えば、アイコンの右クリック）により、プルアップメニューを表示することができる。ユーザインターフェースは、セレクション（例えば、アイコンのダブルクリック、右クリックメニューから「開く」を選択する）により開くことができる。
【０１６９】
ユーザに、どのアプリケーションが安全でありまた安全でないかといった感覚を提供するために、ＤＬＬ、例えば個別のＤＬＬは、各プロセスに関しＷＭＰＡＩＮＴメッセージをインターセプトするためにＷｉｎ３２ステータスフックを使用することができる。フックは、例えば、ステータスアイコンの書き込みにより、ビジュアルキューを、例えば、各ウィンドウの上部右側に提供することができ、アプリケーションが中間サーバに安全に接続されているかどうか示すことができる。ステータス情報は、セキュアアプリケーションマネージャプロキシによって作成された共有メモリ領域を読み取ることで得られる。
【０１７０】
ＬＳＰは、システムに適切にインストールし、ロックされたファイル、バージョニングおよび／またはアンインストールに対処することができる。
【０１７１】
ＡｃｔｉｖｅＸコントロールは、ブラウザ内で実行することができ、中間サーバのサーバから提供されてもよい。このコントロールは、セキュアアプリケーションマネージャに関連したプログラムおよび／またはインストールを、ダウンロード、解凍、および／または実行することができる。これは、ネットワーク接続およびセキュアアプリケーションマネージャと共に使用することができる。これが起動するアプリケーションはスクリプタブルであってもよい。例えば、ＶＢｓｃｒｉｐｔは、プログラム名を、ダウンロード、解凍、および／または起動のため、コントロールへ渡すことができる。
【０１７２】
中間サーバデーモンは、セッションマネージャから受け取ったトラフィックの一部または全てを処理する。次に、デーモンは、企業内の宛先ホストへのソケット接続をすることができ、クライアントアプリケーションに代わってデータを送受信することができる。デーモンは、さらに、クライアント上で実行されているＬＳＰ／セッションマネージャのために最初のホスト名解決を行なうことを目的としてＤＮＳサーバとコンタクトすることができる。
【０１７３】
中間サーバセキュアアプリケーションマネージャは、一以上の機能を有することができる。
【０１７４】
１．ＴＣＰベースのクライアント／サーバプリケーションはすべてサポートされる。例えば、サーバ開始コネクションを含んでいないもの等。
【０１７５】
２．いくつかの実施形態は、アウトルック（Ｏｕｔｌｏｏｋ）、ロータスノーツ（ＬｏｔｕｓＮｏｔｅｓ）、および／またはＮｅｔＢＩＯＳプロキシング（Ｗｉｎｄｏｗｓ（登録商標）（登録商標）マップネットワークドライブへのアクセス）等のアプリケーションをサポートすることができる。
【０１７６】
３．いくつかの実施形態では、Ｗｉｎｄｏｗｓ（登録商標）プラットフォームや、インターネットエクスプローラのようなブラウザ上でサポートされる。
【０１７７】
４．いくつかの実施形態は、クライアントマシンからのダイアルアップ、ブロードバンドおよび／またはＬＡＮシナリオといった、あらゆるインターネットアクセスモードで動作可能である。
【０１７８】
５．いくつかの実施形態は、ポート４４３を介したＳＳＬトラフィックを許可するデバイスのように、クライアント側プロキシおよびファイアウォールを介して作動可能である。
【０１７９】
６．いくつかの実施形態は、サードパーティのエンドポイントセキュリティ製品をサポートする。アプリケーションレベルでのアクセスを有するいくつかの実施形態は、安全なクライアントマシンから使用することができる。いくつかの実施形態は、ネットワークレベルでのアクセスセッションを起動する前に、ＷｈｏｌｅＳｅｃｕｒｉｔｙ、Ｓｙｇａｔｅなどのパーソナルファイアウォールに対処する。
【０１８０】
前記中間サーバは、最初のリリースから「ＷｈｏｌｅＳｅｃｕｒｉｔｙ」のベンダーとの統合をサポートすることができる。指定されたレジストリ設定は、クライアントマシン上でチェックし、セッションを起動する前に、いくつかのプロセスが実行されていることを確かめることができる。
【０１８１】
ここで、「ＷｈｏｌｅＳｅｃｕｒｉｔｙ」／ＺｏｎｅＡｌａｒｍの統合をサポートする例を挙げる。
【０１８２】
１．ネットワーククライアントは、レジストリキーの既存のものをチェックする
ＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥ￥ＳＯＦＴＷＡＲＥ￥ＺｏｎｅＬａｂｓ
または
ＨＫＥＹ＿ＣＵＲＲＥＮＴＵＳＥＲ￥Ｓｏｆｔｗａｒｅ￥ＺｏｎｅＬａｂｓ
【０１８３】
２．その後、ネットワーククライアントは、ＺｏｎｅＡｌａｒｍｅｘｅに結合されている実行中プロセスをチェックする。
【０１８４】
いくつかの実施形態は、管理者が、ベンダー名および関連のレジストリキー・プロセス名を指定することができ、セキュアアプリケーションマネージャクライアントによりサポートされるよう、一般的に十分に統合をインプリメントする。
【０１８５】
下記の内、一またはそれ以上の項目が管理者必要条件となり得る。
【０１８６】
１．セキュアアプリケーションマネージャはグループレベルの機能であってもよい。管理者は、中間サーバグループをベースとしたポリシーを用いた場合のように、セキュアアプリケーションマネージャにアクセスするユーザを制限することができる。
【０１８７】
２．管理者は、アプリケーションレベルでのアクセス、指定された宛先ホストのみへのアクセス、および／または指定された宛先ホストおよびポートへのアクセスといったモードにセキュアアプリケーションマネージャ機能を構成することができる。
【０１８８】
２．Ａ．アプリケーションレベルでのアクセスに関して、管理者は、保護する必要のあるアプリケーションのリストを指定することができる。例えば、ｓａｐＲ３．ｅｘｅ、ｏｕｔｌｏｏｋ．ｅｘｅ、ｉｅ．ｅｘｅ等である。ＮｅｔＢＩＯＳプロキシングは、キーワード「ｎｅｔｂｉｏｓ」を用いる等、特別のアプリケーションとして処理される。
【０１８９】
一つまたはそれ以上のアプリケーションに関して、管理者は、実行可能なものの下記パスのうち一つ以上を指定することができる：（例えば、"％ｓｙｓｔｅｍＲｏｏｔ￥ＰｒｏｇｒａｍＦｉｌｅｓ￥ＳＡＰ￥ｓａｐｒ３．ｅｘｅ”といった実行可能なものの完全パス、分かりやすい記述（例えば、ＳＡＰＲ／３クライアント、および／または実行可能名のデフォルト）、セキュリティ上の理由からセキュアアプリケーションマネージャＬＳＰにより強化され得る実行可能なアプリケーションに関するＭＤ５チェックサム値のオプションリスト、およびクライアントアプリケーションから保護できる宛先ホスト／ポートのオプションリスト。
【０１９０】
２．Ｂ．指定された宛先ホストのみに対するアクセスに関して、管理者は、保護される必要のある宛先ホストのリストを指定することができる。セキュアアプリケーションマネージャは、自動的にＴＣＰポート、ＵＤＰポートおよび／またはアプリケーションバージョン番号の一部または全てに関して、宛先ホストを対象とするトラフィックの一部または全てを保護することができる。
【０１９１】
宛先ホストは、下記のうちの一つまたはそれ以上のもので表わすことができる：単一のＩＰアドレスまたはＩＰアドレス範囲；宛先ホスト名またはホスト名のリスト。ホスト名は、^＊や？のようなワイルドカード表現を使用することができる。ここで、^＊は、任意の数のキャラクタのパターンを表し、？は単一キャラクタのパターンを表わす。ＩＰアドレスが指定され、アプリケーションがホスト名を照会する場合、セキュアアプリケーションマネージャは、そのＩＰアドレスを、ＩＰアドレス範囲内のホストのリストに照らし合わしチェックすることができる。セキュアアプリケーションマネージャは、ホスト名に関する少なくとも単方向のＤＮＳ検索サポートをサポートすることができる。
【０１９２】
宛先ホストは、ホスト名またはＩＰアドレスであってもよい。ホスト名に関しては、ワイルドカードをサポートすることができる。宛先ホストは、フォーマット１０．１０．０．０／２５５．２５５．０．０でサブネットを表わすマスクを用いて指定することができる。
【０１９３】
２．Ｃ．指定された宛先ホストおよびポートへのアクセスに関し、管理者は、保護する必要のある宛先ホストのリストおよびポートを指定することができる。セキュアアプリケーションマネージャは、これらの宛先ホストおよびポートを対象としたトラフィックを自動的に保護することができる。
【０１９４】
３．管理者は、同一グループに対し、ウェブブラウジング、ファイル、ｔｅｌｎｅｔ／ｓｓｈ等のような他の中間サーバ機能へのアクセスを提供することを決めることができる。セキュアアプリケーションマネージャは、サブグループのための追加アクセス機構として構成することができる。
【０１９５】
４．管理者は、一グループ用にセキュアアプリケーションマネージャを構成することができる。Ｊａｖａ（登録商標）対セキュアアプリケーションマネージャ（例えば、ＡｃｔｉｖｅＸ）バージョンの構成は、ユーザエージェントストリングを調べることによりクライアントオペレーティングシステム（例えば、非Ｗｉｎｄｏｗｓ（登録商標）対Ｗｉｎｄｏｗｓ（登録商標））に基づいて自動的に行なうことができる。
【０１９６】
５．いくつかの実施形態では、管理者は、エンドユーザ（セッションマネージャ等）のための「自動起動」セキュアアプリケーションマネージャクライアントを構成することができる。
【０１９７】
６．管理者は、例えば、グループ単位で「セキュアアプリケーションマネージャクライアントの自動完全クリーンアップ（アンインストール）」を選択することができる。このデフォルト値は、「使用不可」とすることもでき、セキュアアプリケーションマネージャのセッションマネージャ上のコンポーネントをすべてアンインストールするオプションをエンドユーザに提供することができる。
【０１９８】
７．管理者は、「完全セキュリティ」といったエンドポイントセキュリティ製品との統合を指定することができる。選択された場合、セキュアアプリケーションマネージャクライアントはまず、指定されたソフトウエアパッケージの存在をチェックし、セキュアアプリケーションマネージャセッションを起動する前に、それが作動していることを確認することができる。ユーザのマシンが指定されたソフトウェアを備えていないか、あるいは作動していない場合、ユーザに対し、セッションを起動することなく、適切な記述でエラーを返すことができる。
【０１９９】
セキュアアプリケーションマネージャプロキシに対し、ＬＳＰの各インスタンスからＤＮＳおよび／またはポートマップ要求するために、何らかの形のプロセス間通信が必要とされる場合もある。Ｗｉｎｄｏｗｓ（登録商標）には、依存性を有する多くのプロセス間通信タイプがある。ネットワークに依存するプロセス間通信は、ＬＳＰに再送信され、無限ループを作ることがある。Ｗｉｎｄｏｗｓ（登録商標）メッセージに依存するプロセス間通信は、それが実行されているプロセスおよびスレッドを殆どコントロールできないＬＳＰ内からエラーおよびデッドロックが生じる傾向にある。残りの選択肢は、多くのマイクロソフトプラットフォームではインプリメントされない。
【０２００】
プロセス間通信機構として、メモリマップファイルは、依存性を有することはできず、多くのプラットフォームに存在することができ、尚且つ比較的効率的であり得る。
【０２０１】
セキュアアプリケーションマネージャプロキシに対し、ＬＳＰから複数のプロセスで同期呼び出しを行なうため、複数のキュー（例えば、二つのキュー）とＷｉｎ３２ＮａｍｅｄＭｕｔｅｘを使用することができる。メッセージキューは、連続したメモリブロック（メモリマップファイル）によりインプリメントすることができ、各種サイズのメッセージをサポートすることができる。このキューは、最初から終わりまでラップアラウンドするデータに対処することができる。一つのキューは、一送信側と一受信側を持つことができ、このような二つのキューは、要求／応答シーケンス、例えば、既知の名前を持つシステム上の要求キューの場合や、固有の名前を持つＬＳＰプロセスによる応答キューの場合に使用することができる。ＮａｍｅｄＭｕｔｅｘは、メモリへのアクセスの同期化に対処することができる。要求／応答シーケンスを同期化するため、応答データを待機させる場合、要求をしているスレッドは、応答キューミューテックからの信号を待つことができる。
【０２０２】
図２１は複数のキューを示す。図２１は、Ｗｉｎｓｏｃｋアプリケーション２１１０およびＬＳＰ２１２０、要求キュー２１３０、応答キュー２１４０、そして、セキュアアプリケーションマネージャプロキシ２１５０を示す。
【０２０３】
メモリマップファイル領域および／またはｎａｍｅｄｍｕｔｅｘはそれぞれ、アクセスするために既知の名前を要求することができる。名前が知られている場合、同一アカウント（または、例えば、Ｗｉｎ９ｘにおけるシステム全体）で実行されているプロセスは、このメモリにアクセスすることができるため、このメモリへのアクセスをより困難にするため、更なるステップを設定することができる。セキュアアプリケーションマネージャが公開する既知のメモリとミューテック名は、リアルメモリとミューテック名を暗号化したフォーマットで格納するために使用することができる。リアルメモリとミューテック名は、それら各々の機能を示すためストリング「：ＳｈａｒｅｄＭｅｍｏｒｙ」および「：Ｍｕｔｅｘ」を含むような、実行時に作成されたランダムな名前をベースにしていてもよい。
【０２０４】
既知の共有メモリ領域名は以下のように定義することができる：
【０２０５】
＜ｎａｍｅ＞：ＡｐｐＰｒｏｘｙ：ＳｔａｒｔｕｐＲｅｑｕｅｓｔＱｕｅｕｅ
【０２０６】
＜ｎａｍｅ＞：ＡｐｐＰｒｏｘｙ：ＤｎｓＲｅｑｕｅｓｔＱｕｅｕｅ
【０２０７】
＜ｎａｍｅ＞：ＡｐｐＰｒｏｘｙ：ＰｏｒｔｍａｐＲｅｑｕｅｓｔＱｕｅｕｅ
【０２０８】
＜ｎａｍｅ＞：ＡｐｐＰｒｏｘｙ：Ｓｔａｔｉｓｔｉｃｓ
【０２０９】
＜ｎａｍｅ＞：ＡｐｐＰｒｏｘｙ：ＡｐｐＴａｂｌｅ
【０２１０】
＜ｎａｍｅ＞：ＡｐｐＰｒｏｘｙ：ＦｌｏｗＴａｂｌｅ
【０２１１】
＜ｎａｍｅ＞：＜ｃｏｍｍｕｎｉｃａｔｉｏｎｐｒｏｔｏｃｏｌ＞：ＰａｇｅIｎｆｏｒｍａｔｉｏｎ
【０２１２】
ＳｔａｒｔｕｐＲｅｓｐｏｎｓｅｔＱｕｅｕｅ、ＤｎｓＲｅｓｐｏｎｓｅＱｕｅｕｅ、およびＰｏｒｔｍａｐＲｅｓｐｏｎｓｅＱｕｅｕｅは、実行時に作成されるランダムなストリングであってもよく、要求と共に渡すことができる。
【０２１３】
一旦セキュアアプリケーションマネージャプロキシが、＜ｃｏｍｍｕｎｉｃａｔｉｏｎｐｒｏｔｏｃｏｌ＞：ＰａｇｅＩｎｆｏｒｍａｔｉｏｎ領域からセッションクッキーを読み取れば、メモリに常に「ぶら下がって」いなくてもすむようクッキーを消去することができる。
【０２１４】
以下の疑似コードは、セキュアアプリケーションマネージャプロキシが、共有メモリからセッションクッキーを読み取る一方法を示す。
【０２１５】
ＥｎｔｅｒＲｅａｄＬｏｃｋ（"＜ｎａｍｅ＞：＜ｃｏｍｍｕｎｉｃａｔｉｏｎｐｒｏｔｏｃｏｌ＞：ＰａｇｅＩｎｆｏｒｍａｔｉｏｎ：Ｍｕｔｅｘ″）
ＯｐｅｎＳｈａｒｅｄＭｅｍｏｒｙ（"＜ｎａｍｅ＞：＜ｃｏｍｍｕｎｉｃａｔｉｏｎｐｒｏｔｏｃｏｌ＞：ＰａｇｅＩｎｆｏｒｍａｔｉｏｎ：ＳｈａｒｅｄＭｅｍｏｒｙ″）
ＥｎｃｒｙｐｔｅｄＭｅｍｏｒｙＮａｍｅ＝ＲｅａｄＥｎｃｒｙｐｔｅｄＭｅｍｏｒｙＮａｍｅ（）
ＣｌｏｓｅＳｈａｒｅｄＭｅｍｏｒｙ（"＜ｎａｍｅ＞：＜ｃｏｍｍｕｎｉｃａｔｉｏｎｐｒｏｔｏｃｏｌ＞：ＰａｇｅＩｎｆｏｒｍａｔｉｏｎ：ＳｈａｒｅｄＭｅｍｏｒｙ″）
ＬｅａｖｅＲｅａｄＬｏｃｋ（"＜ｎａｍｅ＞：＜ｃｏｍｍｕｎｉｃａｔｉｏｎｐｒｏｔｏｃｏｌ＞：ＰａｇｅＩｎｆｏｒｍａｔｉｏｎ：Ｍｕｔｅｘ″）
ＤｅｃｒｙｐｔｅｄＭｅｍｏｒｙＮａｍｅ＝Ｄｅｃｒｙｐｔ（ＥｎｃｒｙｐｔｅｄＭｅｍｏｒｙＮａｍｅ）
ＥｎｔｅｒＷｒｉｔｅＬｏｃｋ（ＤｅｃｒｙｐｔｅｄＭｅｍｏｒｙＮａｍｅ＋ "：Ｍｕｔｅｘ″）
ＯｐｅｎＳｈａｒｅｄＭｅｍｏｒｙ（ＤｅｃｒｙｐｔｅｄＭｅｍｏｒｙＮａｍｅ＋ "：ＳｈａｒｅｄＭｅｍｏｒｙ″）
ＳｅｓｓｉｏｎＣｏｏｋｉｅ＝ＲｅａｄＳｅｓｓｉｏｎＣｏｏｋｉｅ（）
ＣｌｅａｒＳｅｓｓｉｏｎＣｏｏｋｉｅ
ＣｌｏｓｅＳｈａｒｅｄＭｅｍｏｒｙ（ＤｅｃｒｙｐｔｅｄＭｅｍｏｒｙＮａｍｅ＋ "：ＳｈａｒｅｄＭｅｍｏｒｙ″）
ＬｅａｖｅＷｒｉｔｅＬｏｃｋ（ＤｅｃｒｙｐｔｅｄＭｅｍｏｒｙＮａｍｅ＋ "：Ｍｕｔｅｘ″）
【０２１６】
ＬＳＰは、通常のクライアントアプリケーションのようにシステム上にインストールすることができる。ＬＳＰがＡｃｔｉｖｅＸダウンロードエリアからインストールされる場合、インターネットエクスプローラによってこれらのファイルを一掃することができ、故障したネットワークコンフィギュレーションを残すことができる。リブートシナリオ上のＬｏｃｋｅｄＦｉｌｅｓおよびＣｏｐｙ／Ｄｅｌｅｔｅは、他のクライアントソフトウエアインストールと同様に処理できる。一実施形態のインストールパッケージングツールは、ＬＳＰ関連ファイルを自己解凍型ＥＸＥファイルに圧縮する。別の二つのファイルと共にこのＥＸＥファイルは、Ａｃｔｉｖｅ−Ｘダウンローダと使用できるようキャビネットファイル化される。
【０２１７】
図２２は、インストールパッケージの例を示している。ＬＳＰ、ＮＳＰおよびｓａｍｓｐ．ｄｌｌ２２１０、インストールスクリプト２２１４、およびＭＳｒｅｄｉｓｔＳｐｏｒｄｅｒ．ｄｌｌ２２１８は、自己解凍型．ＥＸＥｓａｍｓｐ．ｅｘｅ２２２０に圧縮される。これは、ｓａｍｓｐ．ｃａｂ２２３０にキャビネットファイル化される。ＳＡＭＰＰｒｏｘｙｓａｍｓｖｃ．ｅｘｅ２２４０は、ｓａｍｓｖｃ．ｃａｂ２２６０にキャビネットファイル化される。ＳＡＭＵＩＳａｍｕｉ．ｅｘｅ２２５０は、ｓａｍｕｉ．ｃａｂ２２７０にキャビネットファイル化される。タイトルバーＴｉｔｌｅｂａｒ．ｅｘｅ２２８０は、ｔｉｔｌｅｂａｒ．ｃａｂ２２９０にキャビネットファイル化される。
【０２１８】
下記は、セキュアアプリケーションマネージャのオペレーションの一例である。様々な実施形態は、オペレーションの一部を追加、削除、再配置、および／または修正することができる。
【０２１９】
１．ユーザは、中間サーバの作成したウェブページ上のセキュアアプリケーションマネージャを選択する
ａ．ＡｃｔｉｖｅＸコントロールが、ＬＳＰ、ＮＳＰをダウンロードしインストールする
ｂ．ＡｃｔｉｖｅＸコントロールが，セキュアアプリケーションマネージャプロキシをダウンロードし起動する
ｃ．セキュアアプリケーションマネージャプロキシは、中間サーバからコンフィギュレーションデータを取り出す
ｄ．宛先モードで作動する場合、アドレス／マスク／ポートの組み合わせをリダイレクトテーブルに書き込むことができる
【０２２０】
２．ユーザは、以下のプロセスで読み込まれた新しいアプリケーション、ＬＳＰ、ＮＳＰを起動する
ａ．アプリケーションは、ＬＳＰからセキュアアプリケーションマネージャプロキシにＳｔａｒｔｕｐＲｅｑｕｅｓｔを送出し、オペレーティングモードおよび／またはこのアプリケーションがプロキシ化されるべきかどうか判断する
ｂ．オペレーティングモードが、アップリケーションプロキシであり、このアプリケーションがリストにない場合、ＬＳＰはプロセスから外れ、ＮＳＰは、ＤＮＳリクエストを無視することができる
ｃ．セキュアアプリケーションマネージャのユーザインターフェースは、アプリケーションＥＸＥファイルからアイコンを抽出し、システムトレーのリストに加える。
【０２２１】
３．アプリケーションは、ＤＮＳ検索を実行する
ａ．ＮＳＰは、セキュアアプリケーションマネージャプロキシにＤＮＳ要求を出す
ｂ．セキュアアプリケーションマネージャプロキシは、中間サーバにＤＮＳ要求を出す
ｉ．これが、中間サーバホスト名である場合、ローカルＤＮＳ検索を実行し、アドレスを記憶する
ｃ．ＤＮＳ応答は、もしあれば、同様のパスで返される。
【０２２２】
４．アプリケーションは、ＩＰアドレスへの接続を行なう
ａ．ＬＳＰは、セキュアアプリケーションマネージャプロキシにポートマップ要求を出す
ｂ．このアプリケーション、関連の宛先ホスト名、宛先アドレス／ポートが、リダイレクトテーブルにあれば、ポートマップを設定し、ローカルアドレス／ポートをＬＳＰに返す
ｃ．ＬＳＰは、セキュアアプリケーションマネージャプロキシにより指定されたアドレス／ポートへの接続を行なう
【０２２３】
５．クライアントアプリケーションは、接続をシャットダウンおよび／またはソケットをクローズする
ａ．セキュアアプリケーションマネージャプロキシは、Ｗｉｎｓｏｃｋ終了通知を受け取る
ｂ．セキュアアプリケーションマネージャプロキシは、通信プロトコル接続をクローズする
ｃ．セキュアアプリケーションマネージャプロキシは、ローカルポートマップソケットをクローズする
【０２２４】
６．サーバは、接続をクローズする
ａ．セキュアアプリケーションマネージャプロキシは、通信プロトコル終了通知を受け取る
ｂ．セキュアアプリケーションマネージャプロキシは、ローカルポートマップ接続およびソケットをクローズする
ｃ．アプリケーションは、通常のＷｉｎｓｏｃｋ終了通知を得る
【０２２５】
７．アプリケーション終了
ａ．ＬＳＰは、セキュアアプリケーションマネージャプロキシにＡｐｐｌｉｃａｔｉｏｎＣｌｅａｎｕｐメッセージを出し、現行アプリケーションをアクティブリストから削除する。
【０２２６】
ユーザインターフェースは、セキュアアプリケーションマネージャのステータスを表示するためのシステムトレーアイコンアプリケーションおよびＷｉｎ３２フック等のコンポーネントを、例えば、各アプリケーションのタイトルバーに含むことができる。
【０２２７】
いくつかの実施形態は、エンドユーザのユーザインターフェースにおいて、下記のうちの一以上を備えている
【０２２８】
１．エンドユーザは、中間サーバグループをベースとしたポリシーに基づいて、許可されている場合のみ、中間サーバに「セキュアクライアントアプリケーション（ＳｅｃｕｒｅＣｌｉｅｎｔＡｐｐｌｉｃａｔｉｏｎｓ）」アクセス機構を有することができる。セキュアクライアントアプリケーションアクセス機構は、サブグループに関する管理機能構成によって、セキュアアプリケーションマネージャ（例えば、ＡｃｔｉｖｅＸを備えた）をベースとしたセッションまたはＪａｖａ（登録商標）セッションマネージャを起動することができる。いくつかの実施形態では、エンドユーザは、例えば、Ｊａｖａ（登録商標）対ＡｃｔｉｖｅＸをベースにしたセキュアアプリケーションアクセス機構の間で選択することができ、その他の実施形態では、ユーザが選択することなく、自動的に選択される。
【０２２９】
２．ユーザは、中間サーバにおいてユーザのサブグループに対し使用可能となっている場合、ウェブブラウジング、ファイルブラウジング、ｔｅｌｎｅｔ／ｓｓｈ等のような他の中間サーバクセス機構を、セキュアアプリケーションマネージャと共に選択することができる。セキュアアプリケーションマネージャアクセス機構は、中間サーバ上の追加アクセス機構であってもよい。
【０２３０】
３．セキュアアプリケーションマネージャクライアントダウンロードは、いかなるサイズのものであってもよい。いくつかの実施形態では、ダウンロードにかかる時間は、ダイヤルアップ接続（約５６Ｋｂｐｓ）で約３０秒以下である。セキュアアプリケーションセッションマネージャのいくつかの実施形態は、１分以下で開始され、ユーザは企業アプリケーションにアクセスを開始できるようになる。
【０２３１】
４．セキュアアプリケーションマネージャクライアントのインストールは、コンポーネントをインストールするために、いくつかの管理者権限を要求することができる。ユーザが正しい権限を持っていなければ、ユーザに権限に関する問題があることを通知することができる。ユーザは、セキュアアプリケーションマネージャクライアントコンポーネントをインストールするために、正しい管理者認証情報を提供するように促される。
【０２３２】
５．セキュアアプリケーションマネージャのセッションマネージャは、セキュアアプリケーションマネージャによって保護されるクライアントアプリケーションのリスト等の統計情報、および／またはセキュアアプリケーションマネージャによって保護されるクライアントアプリケーションのうちの一以上のステータスを表示することができる。セキュアアプリケーションマネージャによって保護されるクライアントアプリケーションのリストは、管理者が構成した、保護される必要のあるアプリケーションリストであってもよい。これらのクライアントアプリケーションに関連したアイコンを表示することができる。これらアプリケーション／アイコンは、選択（例えば、クリック）することにより、保護されたバージョンのクライアントアプリケーションを起動することができる。セキュアアプリケーションマネージャによって保護されたクライアントアプリケーションのうち一つ以上に対し、セッションマネージャは、例えば、このアプリケーションに関する送受信バイト数がオプションとして共に提供されるアクティブ（例えば、ユーザがアプリケーションを起動した）、非アクティブ（例えば、アプリケーションがまだ起動されていない）、およびエラー（例えば、セッションのエラー）といったステータスを提供することができる。
【０２３３】
６．セキュアアプリケーションマネージャのセッションマネージャは、セキュアアプリケーションマネージャを起動したユーザと同じアカウント権限の下、バックグラウンドアプリケーションとして実行することができる。ユーザは、セキュアアプリケーションマネージャセッションのステータスを表示するためにシステムトレーアイコンを選択（例えば、クリック）することができる。
【０２３４】
７．セッションマネージャ（例えば、クライアント／サーバ、セキュアアプリケーションマネージャのセッションマネージャ、および／またはネットワーク接続）は、バックグラウンドアプリケーションとして実行することができる。
【０２３５】
８．クライアントにおいては、セッションマネージャによるセキュアアプリケーションマネージャセッションは、円滑に閉じる（切断および／または終了する）ことができる。セッションマネージャを閉じると、セキュアアプリケーションマネージャのセッションマネージャは、自動的にマシンを正常な状態に回復させることができる。いくつかの場合には、セッションマネージャを終了した後、マシンを正常な状態に回復させることができ、他の場合には、マシンが次回リブートされた後、正常な状態に回復させる。
【０２３６】
９．セッションマネージャウィンドウは、中間サーバウィンドウを開くためのオプションを有することができる。
【０２３７】
１０．ユーザセッションがタイムアウトになった場合、中間サーバのユーザは、Ｊａｖａ（登録商標）セッションマネージャの機能と同様の経験をすることもある。セキュアアプリケーションマネージャのセッションマネージャは、「エラー」等のステータスを表示することができる。また、セッションを再開するオプションがあってもよい。セッション再開を選択（例えば、クリック）することにより、例えば、ユーザが認証情報を再入力するために新しいブラウザを開けることもできる。一旦ユーザが中間サーバにログインすれば、セキュアアプリケーションマネージャセッションは再起動される。いくつかの実施形態では、セッションマネージャは、中間サーバへのログインウェブページを開くことにより、クライアント側で認証情報を再入力するようユーザに促すことができる。ユーザは、既存のアプリケーションセッションを閉じることなく継続することができる。
【０２３８】
１１．セキュアアプリケーションマネージャクライアントインストールや、セッションスタートアップ／回復に際して生じたエラー、および／またはセッションの失敗は、Ｗｉｎｄｏｗｓ（登録商標）ＥｖｅｎｔＬｏｇ（ウインドウズイベントログ）（ＡｐｐｌｉｃａｔｉｏｎＬｏｇ（アプリケーションログ））などのログおよび／またはセッションマネージャのカスタムユーザインターフェースログにレポートされる。
【０２３９】
モジュールは、ＬＳＰ（例えば、％ＰｒｏｇｒａｍＦｉｌｅｓ％￥ｎａｍｅ￥ＡｐｐｌｉｃａｔｉｏｎＰｒｏｘｙ￥ｓａｍｌｏｇ．ｔｘｔ）と同じディレクトリに存在することのできるテキストファイルにメッセージを記録することができる。このログは、例えば、システムトレーアプリケーションからの要求で読まれたり表示したりすることができる。アンインストールに際して、このログファイルは削除することができる。
【０２４０】
ＬＳＰは、多くの方法でアップグレードすることができる。現行のＬＳＰは、メモリへロックすることができ、また、リブートなしでは、新バージョンでそれに上書きすることはできない場合もある。このリブートを避けるために、インストーラがロックされたファイルを検出した場合、末尾に数を付加したコピーをインストールすることができる。例えば、ｓａｍｓｐ．ｄｌｌがロックされていた場合、インストールでは、ｓａｍｓｐ１．ｄｌｌをインストールディレクトリーに書き込み、それによってＷｉｎｓｏｃｋカタログを更新することができる。古いｄｌｌは、再起動の際に削除するためフラグを立てておくことができる。多数の異なったバージョンのＬＳＰは、異なるアプリケーション内で同時に実行することができる。
【０２４１】
プロセス間通信メッセージ通信および共有メモリテーブルヘッダーは、モジュール間に後方互換性に関するバージョン番号を含んでいてもよい。ダウンロードされ、インストールされ、および／または実行されているモジュールは、いつアップグレードが必要であるかを判断するために、バイナリーファイルに組み込まれたバージョン番号を持っていてもよい。
【０２４２】
多くのＷｉｎｄｏｗｓ（登録商標）デスクトップソフトウェアは、あまり安全な環境でないことが知られている。そこで、セキュリティ強化の大部分は、中間サーバ上で行なうことができる。クライアント側では、ユーザが、認可されていないアプリケーションを安全な環境に導きいれるのを防ぐための取り組みを行なうことができる。これに関するいくつかの例としては、アプリケーションに関する、オプションとしてのチェックサムリスト、および／または悪意のあるユーザがポートマップ要求プロトコルをインターセプトしないようにするため共有メモリ名を暗号化することが挙げられる。
【０２４３】
標準のＷｉｎ３２のローカライゼーション技術は、ユーザインターフェースに使用できる（例えば、Ｕｎｉｃｏｄｅ（ユニコード））。
【０２４４】
接続は、インターネットエクスプローラのようなブラウザを用いて開始することができるため、いくつかの実施形態では、プロキシを介して中間サーバホストに宛てられたインターネットエクスプローラのトラフィックを転送しないように注意する。セキュアアプリケーションマネージャプロキシは、起動されると、中間サーバホスト名および／またはアドレスを、例えば、ＡｃｔｉｖｅＸコントロールから取り出すことができる。アプリケーションが、中間サーバホスト名に対するＤＮＳ要求を出すと、ローカルＤＮＳ検索が行なわれ、その結果がアプリケーションに返される。そして、セキュアアプリケーションマネージャプロキシは、得られたアドレスを記録することができる。アプリケーションが、これらアドレスのうちの１つへの接続を実行した場合、いくつかの実施形態では、この接続は転送されない。
【０２４５】
ＬＳＰが、実行されプロセスに付加されるために、ＬＳＰがプロトコルカタログにインストールされた後、アプリケーションの新しいインスタンスを起動することができる。中間サーバＵＩは、ユーザにこれを警告することができる。ウィンドウが開かれる場合、インターネットエクスプローラのようないくつかのアプリケーションは必ずしも新しいプロセスを作成するとは限らない場合もある。アプリケーション起動アイコンは、システムトレーアプリケーションに配置することができ、インターネットエクスプローラを起動し、新しいプロセスが確実に作成されるようにする。
【０２４６】
ＬＳＰが前もってシステムにインストールされていた場合、アプリケーションを再始動する必要はない場合もある。
【０２４７】
いくつかの実施形態は、インターネットエクスプローラをベースとしたブラウザでのみ機能するであろうＡｃｔｉｖｅＸコントロールに依存する。他の実施形態は、例えば、独立型インストールパッケージを備えた他のブラウザをサポートする。いくつかの実施形態は、Ｊａｖａ（登録商標）またはネットスケープ（Ｎｅｔｓｃａｐｅ）プラグインを用いて、モジュールを起動する。
【０２４８】
いくつかの実施形態は、ＵＤＰおよび／またはＲＡＷＩＰトラフィックを保護する上でサポートする。セキュアアプリケーションマネージャが、アプリケーションプロキシモードで実行されている場合、非ＴＣＰトラフィックの一部または全てが、ＬＳＰにより拒絶される。
【０２４９】
ネットワーク化されたファイルシステムの大部分は、カーネルのファイルシステムドライバによりインプリメントされ、ファイルシステム要求をネットワークに転送するために、カーネルをベースとしたＴＤＩインターフェースを使用している。これは、ＬＳＰはこのトラフィックを処理しない場合もあることを意味する。
【０２５０】
マイクロソフトは、ＮｅｔＢＩＯＳのためのＷｉｎｓｏｃｋ２トランスポートプロバイダ（ＴｒａｎｓｐｏｒｔＰｒｏｖｉｄｅｒ）を提供している。もしアプリケーションが,このトランスポートプロバイダを使用したならば、ＬＳＰはＮｅｔＢＩＯＳトラフィックを処理することができるであろう。しかしながら、Ｗｉｎｄｏｗｓ（登録商標）エクスプローラは、このトランスポートプロバイダをそのＮｅｔＢＩＯＳ処理に使用していない。
【０２５１】
多くの実施形態は、他のＬＳＰをベースにした製品と相互協調処理するＬＳＰを有する。いかなるＴＣＰベースのクライアント／サーバプリケーションも、セキュアアプリケーションマネージャのいくつかの実施形態を用いて作動できる。
【０２５２】
いくつかの実施形態は、トラフィックをプロキシングするため、ループバックアドレスにより接続をポートマッピングする。ネットワークデータは、ユーザスペースからカーネルへそしてまたユーザスペースへと余分に往復する。一定のＷｉｎｄｏｗｓ（登録商標）サービスは、Ｗｉｎｓｏｃｋの知らないカーネル内のループバックアドレスおよびポートにバインドする。これを、セキュアアプリケーションマネージャプロキシは、カーネルサービスが要求をインターセプトしたことにより、いかなる接続もデータもまだ受け取ってはいないにもかかわらず、ループバックアドレスおよびポートに正常にバインドされたものとみなすことがある。この一例として、マイクロソフトリモートデスクトッププロトコルは、Ｗｉｎｓｏｃｋに通知することなく、１２７．０．０．１：３３８９を引き継ぎ、コントロールする。
【０２５３】
いくつかの実施形態は、ソケット入出力を行なうため、ＬＳＰとセキュアアプリケーションマネージャプロキシとの間にプロセス間通信インターフェースを設ける。これは、Ｗｉｎｓｏｃｋ２トランスポートプロバイダが、プロセス間通信により、データおよびイベントを別のプロセスにコピーすることでインプリメントすることができる。こうして、ＬＳＰは、セキュアアプリケーションマネージャによって保護されたアプリケーションを、新たなトランスポートプロバイダに転送するスイッチとしての役割を果たすことができる。
【０２５４】
セキュアアプリケーションマネージャは、インターネットエクスプローラ、ネットスケープ、オペラ（Ｏｐｅｒａ）などのウェブブラウザをサポートすることができる。いくつかの実施形態では、ウェブページからネイティブＷｉｎ３２アプリケーションを起動するために接続するＪａｖａ（登録商標）あるいはネットスケープを使用する。
【０２５５】
ＴＤＩフックドライバは、ＮｅｔＢＩＯＳトラフィックの一部または全てのキャプチャおよび転送を可能にすることができる。
【０２５６】
通信プロトコルは、ＵＤＰベースのアプリケーションをサポートすることができる。ＬＳＰおよびセキュアアプリケーションマネージャプロキシは、例えば、「ＵＤＰ関連付け」コマンドを使い、その間のＵＤＰフローをセットアップすることができる。
【０２５７】
通信プロトコルのプロトコルは、入ってくるＴＣＰ接続をサポートすることができる。ＬＳＰおよびセキュアアプリケーションマネージャプロキシは、「バインド」コマンドを使用し、プロキシからアプリケーションに入ってくる接続をセットアップすることができる。
【０２５８】
ＳＯＣＫＳは、ＵＤＰと、入って来るＴＣＰ接続をサポートすることができる。いくつかの実施形態において、ＳＯＣＫＳはサポートされている。
【０２５９】
一度ＡｃｔｉｖｅＸコントロールが、ネットワーク接続またはセキュアアプリケーションマネージャ用のシステム上にダウンロードされインストールされると、ウェブサイトは、コントロールをスクリプトすることができ、．ｅｘｅのファイルをそれら独自のサーバからダウンロードし実行することができる。いくつかのコントロールは、特定のホストまたはドメインから実行されるようにそれを制限することによるなど、コントロールをロックするサイトによりこの問題に対処する。
【０２６０】
いくつかの実施形態は、コントロールと中間サーバの間でハンドシェークが行なわれ、これが本物の中間サーバからスクリプトされていることを確認する。
【０２６１】
いくつかの実施形態は、下記の一以上を行う。下記リストの要素は、修正、再配置、追加、および／または削除できる。
【０２６２】
１．クライアントは、ウェブブラウザから中間サーバにログインすることができる。このクライアントに対して、中間サーバ管理者は、中間サーバグループをベースとしたポリシーを使用して、例証を目的としたＳＡＰクライアントのように、アプリケーションにアクセスするための中間サーバ機能を使用可能にすることができる。
【０２６３】
２．セッションを始めるクライアントが選択することにより、中間サーバメニューからセキュアアプリケーションマネージャセッションを起動することができる。
【０２６４】
３．クライアントマシン上にＬＳＰサービスをインストールするセキュアアプリケーションマネージャクライアント（これは、ＡｃｔｉｖｅＸコントロールであってもよい）をダウンロードすることができる。クライアントマシン上で起動される新しいアプリケーションは、ＬＳＰサービスにより読み込むことができる。セキュアアプリケーションマネージャクライアントは、さらにシステムトレー内のプロセスとして実行することもできる。上記のように、セッションマネージャは、設定されたアプリケーションのためのＬＳＰサービスによってインターセプトされたトラフィックの一部または全てを保護することができる。さらに、セッションマネージャは、アクティブなセキュアアプリケーションマネージャセッションの一部または全てのステータスを表示することができる。
【０２６５】
４．ユーザは、クライアントアプリケーション、例えば、ＳＡＰクライアントを起動し、企業ＳＡＰアプリケーションリソースに接続することができる。
【０２６６】
５．クライアントが、リソース、例えば、ｓａｐｓｅｒｖｌ．ｍｙｃｏｍｐａｎｙ．ｃｏｍへの接続を試みると、その呼び出しはＮＳＰサービスによってインターセプトされる。
【０２６７】
６．そして、ＮＳＰサービスは、通信プロトコルにより、ホスト名を中間サーバへ転送することができる。
【０２６８】
７．中間サーバにおいて実行することができるセキュアアプリケーションマネージャデーモン（プロトコルコネクターサービス）は、イントラネットにおいて、ホスト名、ｓａｐｓｒｖｌ．ｍｙｃｏｍｐａｎｙ．ｃｏｍを解決し、応答をセキュアアプリケーションマネージャクライアントに返す。
【０２６９】
８．中間サーバからの正常に「解決された」応答に基づくセキュアアプリケーションマネージャクライアントは、例えば、１２７．０．０．９のような利用可能なループバックアドレスの自動プロビジョニングにより、ポートフォワーディングチャネルを自動的に構成することができる。
【０２７０】
９．その後、セキュアアプリケーションマネージャクライアントは、アプリケーションにループバックアドレスを返すことができる。
【０２７１】
いくつかの実施形態は、下記のうち一つ以上をサポートする：静的クライアント／サーバプリケーション；動的および／または複数ポートＴＣＰをベースとしたクライアント／サーバプリケーション；特定クライアント／サーバプリケーションに関するクライアントポートおよび／またはサーバポート、宛先ホスト名リストのスペック；クライアント／サーバポートフォワーディング；ポート、宛先ホストアドレスなどの余分なスペックを作成するクライアントとの統合；単一ポートおよび／または複数ポートに関する宛先ホストおよび／または一以上のアプリケーション；サーバ開始接続（例えば、ＡｃｔｉｖｅＦＴＰ）および／またはクライアント開始アプリケーションを含むクライアント／サーバプリケーション；ＴＣＰおよび／またはＵＤＰベースのクライアント／サーバプリケーション；Ｗｉｎｄｏｗｓ（登録商標）メディア（Ｍｅｄｉａ）、リアル（Ｒｅａｌ）、クイックタイム（Ｑｕｉｃｋｔｉｍｅ）といった、ライブストリーミングを含む企業ストリーミングリソース；および、企業リアルタイムコラボレーションアプリケーションおよび／またはＥラーンニングリソース（例えば、ネットミーティング（Ｎｅｔｍｅｅｔｉｎｇ）、サムタイム（Ｓａｍｅｔｉｍｅ）オーディオ／ビデオなど）。
【０２７２】
セキュアアプリケーションマネージャは、例えば、少なくとも５００または１０００の同時ユーザを、サポートするためなどに調整することができる。
【０２７３】
いくつかの実施形態は、セキュアＭＡＰＩおよび／またはロータスノーツのような、セキュアメッセージング機能を有する。
【０２７４】
いくつかの実施形態は、静的ポートクライアント／サーバプリケーションなどのセキュアクライアント／サーバプリケーションを保護する。
【０２７５】
セキュアアプリケーションマネージャのいくつかの実施形態は、ＴＣＰを使用するクライアント／サーバプリケーションの一部または全てを保護し、一部または全ての接続は、クライアントから開始される。
【０２７６】
いくつかの実施形態は、セッションタイムアウトを処理するおよび／または同時に他の中間サーバクセス機構に対処するといった、クラスタリングサポートを有する。ＬＳＰサービスは、ＩＥが、セキュアアプリケーションマネージャによって保護されるアプリケーションになるよう構成される場合でも、中間サーバホスト（セキュアアプリケーションマネージャがダウンロードされるホストのＩＰアドレス）に向けられたトラフィックを無視することを自動的に決めることができる。
【０２７７】
いくつかの実施形態は、ＵＤＰベースのアプリケーション、および／または、通信プロトコルの代わりに、あるいは通信プロトコルに加えてＳＯＣＫＳＶ５のようなプロトコルの使用に対応している。
【０２７８】
いくつかの実施形態は、ＦＴＰのようなサーバ開始接続を含むことができるＴＣＰベースのアプリケーションに対応している。ＳＯＣＫＳＶ５のようなプロトコルは、通信プロトコルの代わりに、あるいは通信プロトコルに加えて使用することができる。
【０２７９】
いくつかの実施形態は、ウィルススキャンおよび／またはエンドポイントセキュリティ製品といったサードパーティベンダーとの統合性を有する。
【０２８０】
入って来るＴＣＰ接続を必要とする一例は、ほとんどのインプリメンテーションにおいてデフォルトモードであってもよい、ＦＴＰｎアクティブモードをサポートすることである。これはクライアントマシン上のクライアントアプリケーションを参照することができる。アプリケーションがソケットでリスンする場合、それはｗｉｎｓｏｃｋＡＰＩ関数ｌｉｓｔｅｎ（）に呼び出しをする。ＬＳＰ内で、この呼び出しはインターセプトされ得る。ローカルセキュアアプリケーションマネージャ（ＳＡＭ）プロキシに要求をする。これは、「バインド要求」と呼ばれる。バインド要求は、クライアントマシンがバインドされているＩＰアドレスおよびポートを含んでいる。次に、ローカルＳＡＭプロキシは、リモートネットワーク上のＩＰアドレスと、ローカルクライアントマシン上のクライアントアプリケーションにより指定されたポートとを割り当てることができる中間サーバへのバインド要求をすることができる。中間サーバは、新たに割り当てられたアドレス／ポートで、入って来る接続をリスンすることができる。接続が行なわれた場合、入って来る接続要求は、クライアントマシン上のローカルＳＡＭプロキシに返送され、次に、前記接続要求を、クライアントアプリケーションがリスンしている実アドレスおよび実ポートに転送することができる。その後、このアドレス／ポート（ソケット）にリモートネットワークから入って来るデータは、クライアントのクライアントアプリケーションに転送することができ、また逆も同様である。ローカルクライアントマシン上のクライアントアプリケーションがＴＣＰ接続をクローズする場合、ＳＡＭプロキシは、接続を切断するために中間サーバへ接続終了メッセージを送ることができる。
【０２８１】
リモートネットワーク上のクライアントアプリケーションがＴＣＰ接続をクローズする場合、中間サーバはローカルマシン上のＳＡＭプロキシに接続終了メッセージを送ることができ、そして、ローカルクライアントマシン上のサーバプリケーションへのＴＣＰ接続を切断することができる。
【０２８２】
クライアントマシン上のクライアントアプリケーションが、リスンしていたソケットをクローズする場合、レイヤドサービスプロバイダは、「バインドクローズ」メッセージをセキュアアプリケーションマネージャプロキシに送信することができ、次にその要求を、中間サーバに転送し、そのアドレスおよびポート上でのリスンをやめさせることができる。
【０２８３】
ＵＤＰアプリケーションは、ＩＰを使用したヴォイス（Ｖｏｉｃｅ）、シーユーシーミー（ＣＵ−ＳｅｅＭｅ）、リアルオーディオ（Ｒｅａｌ−Ａｕｄｉｏ）等のリアルタイムマルチメディアアプリケーションであってもよい。一般的な方法でＵＤＰをサポートするため、ＵＤＰトラフィックはクライアントから開始されるべきである。他の実施形態では、非クライアントから開始されたＵＤＰトラフィックをサポートする。
【０２８４】
ＬＳＰ内で、ＷＳＰＳｅｎｄ（）およびＷＳＰＳｅｎｄＴｏ（）呼び出しは、ＵＤＰソケット上でインターセプトすることができる。これが、このアドレス／ポート上で検出された最初のＵＤＰトラフィックである場合、クライアントアプリケーションからローカルセキュアアプリケーションマネージャプロキシに「ＵＤＰフロー要求」を送ることができる。ローカルセキュアアプリケーションマネージャプロキシは、、次に、中間サーバに「ＵＤＰフロー要求」をすることができる。一旦これが完了すれば、セキュアアプリケーションマネージャプロキシは、クライアントアプリケーションにローカルループバックアドレスおよびＵＤＰポートを割り当てることができる。レイヤドサービスプロバイダー内で、前記要求が完了すると、宛先パラメーターにおいて、ＷＳＰＳｅｎｄＴｏ（）呼び出し（または、Ｗｉｎｓｏｃｋフックインプリメンテーションではｓｅｎｄｔｏ（））か、あるいは、ＷＳＰＣｏｎｎｅｃｔ（）呼び出しの間であれば、接続されたＵＤＰソケットＡＰＩ使用（Ｗｉｎｓｏｃｋフックインプリメンテーションではｃｏｎｎｅｃｔ（））の代わりに新たに割り当てられたアドレスを使用することができる。
【０２８５】
中間サーバはＵＤＰフロータイマーをインプリメントすることができる。一定の期間の後、アドレスおよびポートにおいて、ＵＤＰトラフィックが検出されない場合、その「ＵＤＰフロー」クライアント結合を切断することができる。そして、ＵＤＰフロー切断メッセージが、ローカル結合を切断するクライアントマシン上のローカルセキュアアプリケーションマネージャプロキシに送信される。ＵＤＰのステートレスな性質により、クライアントアプリケーションに通知が送られない場合もある。タイムアウト期間が終了した後、アプリケーションがＵＤＰアドレスおよびポートにモーレスデータ（ｍｏｒｅｓｄａｔａ）を送る場合、新たなＵＤＰフロー要求が開始される。データがアドレスとポートに送信されると、ＵＤＰタイムアウト期間はリセットされる
【０２８６】
図２３は、アプリケーションの一例と、ローカルネットワーク上のクライアントコンピュータのトランスポートドライバインターフェースを示す。図２３は、ソケットアプリケーション２３１０と、ＮｅｔＢＩＯＳアプリケーション２３１５とを示している。トランスポートドライバインターフェースクライアントは、ソケットエミュレータ２３３０、ＮｅｔＢＩＯＳエミュレータ２３３４、およびリダイレクタやサーバなど２３３８を備えている。ソケットインターフェース２３２０は、ソケットアプリケーション２３１０とソケットエミュレータ２３３０の間にある。ＮｅｔＢＩＯＳインターフェース２３２５は、ＮｅｔＢＩＯＳアプリケーション２３１５とＮｅｔＢＩＯＳエミュレータ２３３４の間にある。トランスポートドライバ（トランスポートプロバイダとも呼ばれる）は、Ａｐｐｌｅｔａｌｋトランスポートドライバ２３５０、ＮｅｔＢＴトランスポートドライバ２３５２、Ｎｂｆトランスポートドライバ２３５４、ＴＣＰ／ＩＰトランスポートドライバ２３５６、およびＮＷｌｉｎｋトランスポートドライバ２３５８を備えている。トランスポートドライバインターフェース２３４０は、トランスポートドライバインターフェースクライアントとトランスポートプロバイダの間にある。
【０２８７】
カーネルベースＴＤＩクライアントのいくつかの例としては、ＮｅｔＢＩＯＳ、ＮＦＳ、ＭＳリモートデスクトッププロトコルおよびマイクロソフトインターネットインフォメーションサーバが挙げられる。ＴＤＩクライアントは、Ｗｉｎｓｏｃｋをネーム解決に使用することもでき、その場合には、Ｗｉｎｓｏｃｋ２ネームスペースプロバイダはリモートネームサービスを提供することができる。ＮｅｔＢＩＯＳのような他のネットワークアプリケーションは、カーネルで作成された名前検索および／またはブロードキャストディスカバリなどの追加機能を実行してもよい。その場合、これらのイベントは、カーネルでトラップでき、および／またはカスタム処理を実行することができる。いくつかの実施形態は、一以上の操作モードを有することができる。一モードとしては、一般モードが挙げられ、Ｗｉｎｓｏｃｋネームスペースプロバイダにより行なわれた名前検索結果を、フィルタリングやリダイレクションのためドライバに結果を渡すことができる。別のモードでは、アプリケーションまたはプロトコルに特有のカスタムハンドラを用いることができる。
【０２８８】
図２４は、一般的なオペレーティングモードを示す。エクスプローラやＩＩＳといったアプリケーション２４１０、ネームスペースプロバイダ２４２０、ＮｅｔＢＩＯＳおよび／またはＮＦＳのようなＴＣＰ／ＩＰＴＤＩクライアント２４３０、ＴＤＩフックドライバ２４４０、ＴＣＰ／ＩＰトランスポートドライバ２４５０、セキュアアプリケーションマネージャプロキシ２４６０、中間サーバへのリモート接続２４７０が示されている。
【０２８９】
図２５は、カスタムハンドラを用いたモードを示し、図２４と類似しているが、ネームスペースプロバイダが関与していない。
【０２９０】
サーバ上で、一アプリケーションに非Ｗｉｎｓｏｃｋアプリケーションのフラグを立てる場合、ＤＮＳ検索を行なうことができ、および／またはその結果は、ＴＤＩフィルタドライバに渡される。ループバックアドレスおよびポートはプロキシによって開かれ、さらに、ドライバに渡されることにより、ターゲットアドレスが修正されそのトラフィックを中間サーバに転送することができる。
【０２９１】
ＮｅｔＢＩＯＳは、ＤＮＳを使用するだけではないため、プロトコル特定のハンドラにより処理できる。それはＷＩＮＳを使用して（ＵＤＰ要求をサーバに送信）、ブロードキャストディスカバリおよびＬＡＮ上でＵＤＰブロードキャストを行なうことができる。そして、それはＷＩＮＳを用いたＮｅｔＢＩＯＳ特定のホスト名解決および／またはＵＤＰブロードキャストを行うこともでき、その後ＤＮＳが使用される。マイクロソフトＷｉｎｄｏｗｓ（登録商標）へのシームレス統合をサポートするために、プロトコル特定のハンドラは、リモートネットワーク上でネットワークディスカバリ要求を行なうことができる。たとえＮｅｔＢＩＯＳが、ＷＩＮＳおよびブロードキャスト検索の後ＤＮＳにフォールバックできるとしても、カスタム名検索処理を行なうことができる。カスタム名検索処理により、ＮｅｔＢＩＯＳネーム解決が、タイムアウトおよびＤＮＳへのフォールバックを待つ代わりとして使用されれば、より効率的であり、また、ＮｅｔＢＩＯＳＤＮＳ解決は、ユーザがセキュアアプリケーションマネージャを起動する前に開始したシステムサービスによって行なうことができ、これは、ＳＡＭのモデルに反することもある。
【０２９２】
ＴＤＩフックドライバは、ＮｅｔＢＩＯＳディスカバリ要求をキャプチャし、要求をコピーし、中間サーバに要求を転送することのできるセキュアアプリケーションマネージャプロキシに渡すことができる。中間サーバから返された結果は、クライアントが結果を発見できるようにローカルに再送信することができる。
【０２９３】
中間サーバは、ブロードキャストディスカバリおよび／またはＮｅｔＢＩＯＳネーム検索をサポートするために特別なプロトコルハンドラを必要とすることもある。このハンドラは、リモートクライアントの代わりに典型的なＮｅｔＢＩＯＳのタスクを行なうことができ、および／またはセキュアリンクにより結果を返すことができる。
【０２９４】
下記は、ＮｅｔＢＩＯＳを用いた一例である。ステップは、追加、削除、再配置、および／または修正することができる。
【０２９５】
１．管理者は、リモートアクセスするＮｅｔＢＩＯＳホストおよび／またはアドレスを設定する
【０２９６】
２．ユーザがログインすると、設定がクライアントに送られる
【０２９７】
３．ＴＤＩフックドライバが読み込む
【０２９８】
４．セキュアアプリケーションマネージャプロキシが読み込み、ドライバへの入出力チャネルを開く
【０２９９】
５．ユーザは、ＮｅｔＢＩＯＳ名によりネットワーク共用回線を開く要求を出す
【０３００】
６．ＴＤＩフックドライバは、既知のＮｅｔＢＩＯＳポートに関する指定ＷＩＮＳの照会またはブロードキャスト要求を検知する
【０３０１】
７．ＴＤＩフックドライバは、要求を消化し、ｉｏｃｔｌを介してプロキシに渡す
【０３０２】
８．プロキシは、ホスト名をフィルタリング処理にかける。マッチングが確認された場合、ＮｅｔＢＩＯＳネーム検索は中間サーバ上のＮｅｔＢＩＯＳネームサービスハンドラに転送される。マッチングが確認されなかった場合、要求は通常のオペレーションを行なうためローカルネットワーク上で再送信される
【０３０３】
９．中間サーバは、リモートネットワーク設定によってＷＩＮＳおよび／またはブロードキャストネーム検索を行う
【０３０４】
１０．プロキシは、ＮｅｔＢＩＯＳネーム検索応答を受け取る
【０３０５】
ａ．転送のためループバックアドレスおよびポートを開く
【０３０６】
ｂ．実ＩＰアドレス、ポート＋ループバックＩＰアドレスおよびポートをＴＤＩフィルタドライバに渡す
【０３０７】
ｃ．クライアントアプリケーションにネーム検索結果を再送信
【０３０８】
１１．ＴＤＩフィルタは、得られた宛先ＩＰアドレスでＮｅｔＢＩＯＳトラフィックを検出する
【０３０９】
１２．ＴＤＩフィルタは、宛先ＩＰアドレスを、割り当てられたループバックアドレスおよびポートと置き換え、結果として、ＴＣＰ／ＩＰスタックは、データをセキュアアプリケーションマネージャプロキシに送信する
【０３１０】
１３．プロキシは、中間サーバへＮｅｔＢＩＯＳを転送する。
【０３１１】
図２６は、方法の一実施形態を示す。２６１０において、ネットワーク接続要求が受信される。２６２０において、ネットワーク接続要求が転送される。２６３０において、データは中間サーバに向け送信される。この方法は、リモートネットワークへのセキュアリモートアクセスを可能にすることができる。
【０３１２】
ネットワーク接続要求は、ローカルネットワーク上のコンピュータで受信されることができる。ネットワーク接続要求は、クライアント／サーバプリケーションのクライアントアプリケーションにより開始することができる。クライアントアプリケーションはコンピュータ上にあってもよい。ネットワーク接続要求は、リモートネットワーク上の宛先を含むことができる。クライアント／サーバプリケーションのサーバプリケーションは、リモートネットワーク上にあってもよい。
【０３１３】
ネットワーク接続要求は、コンピュータ上のＷｉｎｄｏｗｓ（登録商標）ソケットレイヤ内に転送することができる。これには、ネームスペースプロバイダ（例えば、リモートネットワーク上のドメインネームサービス検索に利用）およびレイヤドサービスプロバイダ（例えば、ローカルネットワークからリモートネットワークへのクライアントアプリケーションのデータ転送に利用）を用いて、ネットワーク接続要求を転送することが含まれる。ネットワーク接続要求は、コンピュータのトランスポートサービスプロバイダ（例えば、ＴＣＰ／ＩＰトランスポートサービスプロバイダ）を避けて転送することができる。ネットワーク接続要求は、リモートネットワーク内の中間サーバに転送することができる。その中間物サーバは、コンピュータに代わってネットワーク接続要求を行なうことができる。転送は以下のうちの一以上に基づいて行うことができる：クライアントアプリケーションの名前、クライアントアプリケーションのチェックサム、クライアントアプリケーションのバージョン、宛先のサーバ、および宛先のポート。転送前に、ネットワーク要求は、ＷｉｎｓｏｃｋダイナミックリンクライブラリおよびＷｉｎｓｏｃｋ２ダイナミックリンクライブラリの少なくとも一つ通過することができる。ネットワーク接続要求は、コンピュータ上の少なくともプロキシを介して、リモートネットワーク内の中間サーバに転送することができる。
【０３１４】
クライアントアプリケーションのデータは、コンピュータから中間サーバに向けて送信することができる。セキュア・ソケット・レイヤ（ＳＳＬ）は、コンピュータと中間サーバの間の通信を暗号化することができる。クライアントアプリケーションのデータは、中間サーバからサーバプリケーションに向けて送信することができる。様々な実施形態は、中間サーバからサーバプリケーションに向けてクライアントアプリケーションのデータを送信するか、あるいは、実施形態外部のソフトウェアまたはハードウェアによってこれを行わせる。クライアントアプリケーションのデータは、中間サーバに向けてクライアントアプリケーションのデータを送信する前に、少なくとも前記コンピュータのローカルアドレスおよびローカルポートにより送信することができる。
【０３１５】
いくつかの実施形態では、クライアントアプリケーションと中間サーバとの間のセキュア接続を示すためビジュアルキューが設けられる。ネームスペースプロバイダおよびレイヤドサービスプロバイダは、自動的にコンピュータにインストールおよび／またはコンピュータからアンインストールすることができる。
【０３１６】
図２７は別の方法実施形態を示す。２７１０において、ネットワーク接続要求が受信される。２７２０において、ネットワーク接続要求が転送される。２７３０において、中間サーバからデータを受信する。この方法は、リモートネットワークへのセキュアリモートアクセスを可能にすることができる。
【０３１７】
ネットワーク接続要求は、ローカルネットワーク上のコンピュータで受信できる。ネットワーク接続要求は、リモートネットワーク上のファイルシステムに対し、開始することができる。ネットワーク接続要求は、前記ファイルシステムの名前を含んでいてもよい。
【０３１８】
ネットワーク接続要求は、コンピュータ上のトランスポートドライバインターフェースを用いて転送することができ、更に、ネームスペースプロバイダを使用してもよい。転送することにより、ネットワークファイルシステムトラフィックをキャプチャすることができる。ネットワーク接続要求は、コンピュータ上でトランスポートドライバ（例えば、ＴＣＰ／ＩＰトランスポートドライバ）を避けて転送することができる。ネットワーク接続要求は、リモートネットワーク内の中間サーバに転送することができる。中間サーバは、コンピュータに代わってネットワーク接続要求を行う。転送は、宛先サーバおよび宛先ポートの内の一以上に基づいて行なわれる。転送に先立ち、ネットワーク接続要求は、少なくともトランスポートドライバインターフェースフィルタを通過することができる。
【０３１９】
中間サーバからのファイルシステムのデータはコンピュータで受信することができる。セキュア・ソケット・レイヤ（ＳＳＬ）は、コンピュータと中間サーバの間の通信を暗号化することができる。ファイルシステムのデータは、リモートネットワーク上の中間サーバとファイルシステムの間で転送することができる。様々な実施形態は、中間サーバとファイルシステムの間でファイルシステムのデータをやりとりするか、或いは、実施形態外部のハードウェアまたはソフトウェアによってこれを行わせる。
【０３２０】
いくつかの実施形態では、トランスポートドライバインターフェースは、自動的にコンピュータにインストールおよび／またはコンピュータからアンインストールすることができる。
【０３２１】
種々様々な態様、特徴、実施形態、または上述のいくつかの実施形態のインプリメンテーションは、単独であるいは様々な組み合わせで使用することができる。
【０３２２】
いくつかの実施形態は、ソフトウェアにおいてインプリメントすることができるが、ハードウェアまたはハードウェアとソフトウェアの組み合わせにおいてインプリメントすることもできる。本発明のいくつかの実施形態はまた、コンピュータ読み取り可能メディア上のコンピュータ読み取り可能コードとして実施することができる。コンピュータ読み取り可能メディアとは、データを格納することができ、その後コンピュータシステムにより読み取ることができる任意のデータ記憶装置である。コンピュータ読み取り可能メディアの例としては、読み取り専用メモリ、ランダムアクセスメモリ、ＣＤ−ＲＯＭ、ＤＶＤ、磁気テープ、光学データ記憶装置、および搬送波が挙げられる。コンピュータ読み取り可能メディアはまた、コンピュータ読み取り可能コードが分散して格納され、実行されるよう、複数のネットワーク結合コンピュータシステムに分散させることができる。
【０３２３】
いくつかの実施形態は、多数の利点を有する。様々な実施形態またはインプリメンテーションにより、下記利点の中から一つ以上が得られる。いくつかの実施形態の一利点は、仲介サーバをリモートサーバとクライアント間に配置し、安全なアクセスを容易にすることができる点である。いくつかの実施形態の別の利点は、クライアントが要求したコンテンツを変更し、次のクライアントの要求を仲介サーバに送信することで、仲介サーバはクライアントのために要求されたコンテンツを得ることができる点である。また、いくつかの実施形態の更に別の利点は、仲介サーバが、プライベートネットワークによって提供されるネイティブ認証の使用を通じてプライベートネットワーク上のリソースへのアクセスを求めるリクエスタを認証することができるという点である。更に、いくつかの実施形態の別の利点は、プライベートネットワークへのセキュアリモートアクセスを、許可された人にリーズナブルなコストで容易に提供することができるという点である。
【０３２４】
いくつかの実施形態の多くの特徴および利点は、記載された説明から明白であることから、本発明のいくつかの実施形態のそのような特徴および利点の全てが、添付クレームによってカバーされるものとする。さらに、当業者にとって、多数の修正および変更が容易に考えられるため、本発明を、例示および説明した厳密な構成およびオペレーションに限定することを意図するものではない。従って、適切な修正および等価物はすべて、本発明の範囲内にあるものとして分類される。
【図面の簡単な説明】
【０３２５】
【図１Ａ】図１Ａは、本発明の一実施形態に係る情報検索システムを示すブロック図である。
【図１Ｂ】図１Ｂは、本発明の別の実施形態に係る情報検索システムを示すブロック図である。
【図２Ａ】図２Ａは、本発明の一実施形態に係る仲介サーバを示すブロック図である。
【図２Ｂ】図２Ｂは、本発明の一実施形態に係るリモートアクセスシステムを示すブロック図である。
【図３】図３は、本発明の一実施形態に係る要求処理を示すフローチャートである。
【図４】図４は、本発明の一実施形態に係る認証処理を示すフローチャートである。
【図５】図５は、本発明の一実施形態に係るアクセス権処理を示すフローチャートである。
【図６】図６は、本発明の一実施形態に係る操作権限処理を示すフローチャートである。
【図７】図７は、本発明の一実施形態に係る詳細な外部認証処理を示すフローチャートである。
【図８Ａ】図８Ａは、本発明の一実施形態に係るファイルアクセス要求処理を示すフローチャートである。
【図８Ｂ】図８Ｂは、本発明の一実施形態に係るファイルアクセス要求処理を示すフローチャートである。
【図９Ａ】９Ａは、本発明の一実施形態に係るウェブリソース要求処理を示すフローチャートである。
【図９Ｂ】図９Ｂは、本発明の一実施形態に係るウェブリソース要求処理を示すフローチャートである。
【図９Ｃ】図９Ｃは、本発明の一実施形態に係るウェブリソース要求処理を示すフローチャートである。
【図１０】図１０は、本発明の一実施形態に係る情報検索システムを示す図である。
【図１１】図１１は、本発明の一実施形態に係るＵＲＬ修正処理を示すフローチャートである。
【図１２】図１２は、本発明の一実施形態に係るスクリプト修正処理を示すフローチャートである。
【図１３Ａ】図１３Ａは、本発明の別の実施形態に係るスクリプト修正処理を示すフローチャートである。
【図１３Ｂ】図１３Ｂは、本発明の別の実施形態に係るスクリプト修正処理を示すフローチャートである。
【図１４】図１４は、本発明の一実施形態に係るＥメール要求処理を示すフローチャートである。
【図１５】図１５は、本発明の一実施形態に係るメールオペレーション処理を示すフローチャートである。
【図１６】図１６は、本発明の一実施形態に係る認証処理を示すフローチャートである。
【図１７Ａ】図１７Ａは、本発明のいくつかの実施形態により使用できるコンピュータシステムの一例を示す図である。
【図１７Ｂ】図１７Ｂは、本発明のいくつかの実施形態により使用できるコンピュータシステムの一例を示す図である。
【図１８】図１８は、本発明の一実施形態に係るセキュアアプリケーションマネージャのいくつかの実施形態を示すブロック図である。
【図１９】図１９は、本発明の一実施形態に係るＷｉｎｓｏｃｋアプリケーションおよびＷｉｎｄｏｗｓ（登録商標）ソケットレイヤを示すブロック図である。
【図２０】図２０は、本発明の一実施形態に係るＷｉｎｓｏｃｋアプリケーションおよびＷｉｎｄｏｗｓ（登録商標）ソケットレイヤを示す別のブロック図である。
【図２１】図２１は、本発明の一実施形態に係るセキュアアプリケーションマネージャプロキシとＷｉｎｓｏｃｋアプリケーション間のキューを示すブロック図である。
【図２２】図２２は、本発明の一実施形態に係るインストールパッケージングを示すブロック図である。
【図２３】図２３は、本発明の一実施形態に係るローカルネットワーク上のクライアントコンピュータのトランスポートドライバインターフェイスおよびアプリケーションを示すブロック図である。
【図２４】図２４は、本発明の一実施形態に係るファイルシステムネットワーク接続要求を転送するための汎用オペレーティングモードを示すブロック図である。
【図２５】図２５は、本発明の一実施形態に係るファイルシステムネットワーク接続要求を転送するためのカスタムハンドラを用いたモードを示すブロック図である。
【図２６】図２６は、本発明の一実施形態に係るネットワーク接続要求を転送するためのフローチャートである。
【図２７】図２７は、本発明の別の実施形態に係るネットワーク接続要求を転送するためのフローチャートである。

【特許請求の範囲】
【請求項１】
ネットワーク通信方法であって、前記方法が、
ローカルネットワーク上のコンピュータ上でネットワーク接続要求を受信する工程と、
前記コンピュータ上のＷｉｎｄｏｗｓ（登録商標）ソケットレイヤ内に前記ネットワーク接続要求を転送する工程と、
クライアント／サーバプリケーションのクライアントアプリケーションのデータを、前記コンピュータから中間サーバに向けて送信する工程とを有し、
前記受信する工程において、前記ネットワーク接続要求は、前記クライアントアプリケーションにより開始され、前記クライアントアプリケーションは、前記コンピュータ上にあり、前記ネットワーク接続要求は、リモートネットワーク上の宛先を含み、前記クライアント／サーバプリケーションのサーバプリケーションは、前記リモートネットワーク上にあり、
前記転送する工程において、前記ネットワーク接続要求は、前記コンピュータのトランスポートサービスプロバイダを避けて転送され、前記ネットワーク接続要求は、前記リモートネットワーク内の中間サーバに転送され、
前記送信する工程において、前記クライアントアプリケーションのデータは、前記中間サーバから前記サーバプリケーションに向けて送信されるネットワーク通信方法。
【請求項２】
前記Ｗｉｎｄｏｗｓ（登録商標）ソケットレイヤが、Ｗｉｎｓｏｃｋダイナミックリンクライブラリ、Ｗｉｎｓｏｃｋ２ダイナミックリンクライブラリ、アプリケーションプログラムインターフェイス、レイヤドサービスプロバイダ、前記レイヤドサービスプロバイダのためのサービスプロバイダインターフェース、ネームスペースプロバイダ、ネームスペースプロバイダインターフェース、トランスポートサービスプロバイダインターフェース、およびトランスポートサービスプロバイダのうち少なくとも一つを含む請求項１に記載の方法。
【請求項３】
前記Ｗｉｎｄｏｗｓ（登録商標）ソケットレイヤ内に前記ネットワーク接続要求を転送することが、前記Ｗｉｎｓｏｃｋダイナミックリンクライブラリおよび前記Ｗｉｎｓｏｃｋ２ダイナミックリンクライブラリのうち少なくとも一方をフックすることにより、前記ネットワーク接続要求を転送することを含む請求項２に記載の方法。
【請求項４】
前記Ｗｉｎｄｏｗｓ（登録商標）ソケットレイヤ内に前記ネットワーク接続要求を転送することが、前記ネームスペースプロバイダおよび前記レイヤドサービスプロバイダを用いて前記ネットワーク接続要求を転送することを含む請求項２に記載の方法。
【請求項５】
前記トランスポートサービスプロバイダが、ＴＣＰ／ＩＰトランスポートサービスプロバイダを含む請求項１に記載の方法。
【請求項６】
前記方法が更に、前記クライアントアプリケーションのデータを前記中間サーバから前記サーバプリケーションに向けて送信することを含む請求項１に記載の方法。
【請求項７】
前記ネームスペースプロバイダが、前記リモートネットワーク上で、ドメインネームサービス検索に利用される請求項４に記載の方法。
【請求項８】
前記レイヤドサービスプロバイダが、前記クライアントアプリケーションのデータの前記ローカルネットワークから前記リモートネットワークへの転送に利用される請求項４に記載の方法。
【請求項９】
前記転送が、前記クライアントアプリケーションの名前、前記クライアントアプリケーションのチェックサム、前記クライアントアプリケーションのバージョン、前記宛先のサーバ、および前記宛先のポートの内の少なくとも一つに基づいて行われる請求項１に記載の方法。
【請求項１０】
前記転送が、少なくとも前記クライアントアプリケーションの名前に基づいて行われる請求項９に記載の方法。
【請求項１１】
前記転送が、少なくとも前記クライアントアプリケーションのチェックサムに基づいて行われる請求項９に記載の方法。
【請求項１２】
前記転送が、少なくとも前記クライアントアプリケーションのバージョンに基づいて行われる請求項９に記載の方法。
【請求項１３】
前記転送が、少なくとも前記宛先のサーバに基づいて行われる請求項９に記載の方法。
【請求項１４】
前記転送が、少なくとも前記宛先のポートに基づいて行われる請求項９に記載の方法。
【請求項１５】
前記転送に先立ち、前記ネットワーク要求は、ＷｉｎｓｏｃｋダイナミックリンクライブラリおよびＷｉｎｓｏｃｋ２ダイナミックリンクライブラリの少なくとも一方を介することができる請求項２に記載の方法。
【請求項１６】
前記ネットワーク接続要求は、少なくとも前記コンピュータのプロシキを介し、前記リモートネットワーク内の前記中間サーバに転送される請求項１に記載の方法。
【請求項１７】
前記クライアントアプリケーションのデータを前記中間サーバに向けて送信する前に、前記クライアントアプリケーションのデータが、前記コンピュータの少なくともローカルアドレスとローカルポートを介して送信される、請求項１に記載の方法。
【請求項１８】
前記方法が更に、前記クライアントアプリケーションと前記中間サーバとの間のセキュア接続を示すためビジュアルキューを提供することを含む請求項１に記載の方法。
【請求項１９】
前記方法が更に、前記ネームスペースプロバイダおよび前記レイヤドサービスプロバイダを前記コンピュータ上に自動的にインストールすることを含む請求項４に記載の方法。
【請求項２０】
前記方法が更に、前記ネームスペースプロバイダおよび前記レイヤドサービスプロバイダを前記コンピュータからに自動的にアンインストールすることを含む請求項４に記載の方法。
【請求項２１】
前記方法が、前記リモートネットワークへのセキュアリモートアクセスを可能にする請求項１に記載の方法。
【請求項２２】
前記コンピュータと前記中間サーバの間の通信を、セキュア・ソケット・レイヤ（ＳＳＬ）が暗号化する請求項１に記載の方法。
【請求項２３】
前記中間サーバが、前記コンピュータに代わって前記ネットワーク接続要求を行なう請求項１に記載の方法。
【請求項２４】
ネットワーク通信方法であって、前記方法が
ローカルネットワーク上のコンピュータ上でネットワーク接続要求を受信する工程と、
前記ネットワーク接続要求を、前記コンピュータ上のトランスポートドライバインターフェイスを用いて転送する工程と、
中間サーバからファイルシステムのデータを前記コンピュータで受信する工程とを有し、
前記受信する工程において、前記ネットワーク接続要求は、リモートネットワーク上のファイルシステムに対して開始され、前記ネットワーク接続要求は、前記ファイルシステムの名前を含んでおり、
前記転送する工程において、前記ネットワーク接続要求は、前記コンピュータ上のトランスポートドライバを避けて転送され、前記ネットワーク接続要求は、前記リモートネットワーク内の前記中間サーバに転送され、
前記受信する工程において、前記ファイルシステムのデータは、前記リモートネットワーク上の前記中間サーバと前記ファイルシステムの間でやりとりされるネットワーク通信方法。
【請求項２５】
前記ネットワーク接続要求の転送には更に、ネームスペースプロバイダを使用する請求項２４に記載の方法。
【請求項２６】
前記トランスポートドライバが、ＴＣＰ／ＩＰトランスポートドライバを含む請求項２４に記載の方法。
【請求項２７】
前記転送に先立ち、前記ネットワーク接続要求は、少なくとも一つのトランスポートドライバインターフェースフィルタを通過する請求項２４に記載の方法。
【請求項２８】
前記方法が更に、前記ファイルシステムのデータを、前記中間サーバと前記ファイルシステムとの間でやりとりすることを含む請求項２４に記載の方法。
【請求項２９】
前記手転送が、宛先サーバおよび宛先ポートの少なくとも一つに基づいて行なわれる請求項２４に記載の方法。
【請求項３０】
前記転送が、少なくとも前記宛先サーバに基づいて行なわれる請求項２９に記載の方法。
【請求項３１】
前記転送が、少なくとも前記宛先ポートに基づいて行なわれる請求項２９に記載の方法。
【請求項３２】
前記転送することで、ネットワークファイルシステムトラフィックをキャプチャする請求項２４に記載の方法。
【請求項３３】
前記方法が更に、前記トランスポートドライバインターフェースを前記コンピュータ上に自動的にインストールすることを含む請求項２４に記載の方法。
【請求項３４】
前記方法が更に、前記トランスポートドライバインターフェースを前記コンピュータから自動的にアンインストールすることを含む請求項３３に記載の方法。
【請求項３５】
前記方法が、前記リモートネットワークへのセキュアリモートアクセスを可能にする請求項２４に記載の方法。
【請求項３６】
前記コンピュータと前記中間サーバの間の通信を、セキュア・ソケット・レイヤ（ＳＳＬ）が暗号化する請求項２４に記載の方法。
【請求項３７】
前記中間サーバが、前記コンピュータに代わって前記ネットワーク接続要求を行なう請求項２４に記載の方法。
【請求項３８】
ネットワーク通信のためのコンピュータコードであって、前記コードが、
ローカルネットワーク上のコンピュータ上でのネットワーク接続要求の受信を実行するコードと、
前記コンピュータ上のＷｉｎｄｏｗｓ（登録商標）ソケットレイヤ内への前記ネットワーク接続要求の転送を実行するコードと、
前記コンピュータから中間サーバに向けてのクライアント／サーバプリケーションのクライアントアプリケーションのデータの送信を実行するコードとを含み、
前記受信を実行するコードにおいて、前記ネットワーク接続要求は、前記クライアントアプリケーションにより開始され、前記クライアントアプリケーションは、前記コンピュータ上にあり、前記ネットワーク接続要求は、リモートネットワーク上の宛先を含み、前記クライアント／サーバプリケーションのサーバプリケーションは、前記リモートネットワーク上にあり、
前記転送を実行するコードにおいて、前記ネットワーク接続要求は、前記コンピュータのトランスポートサービスプロバイダを避けて転送され、前記ネットワーク接続要求は、前記リモートネットワーク内の中間サーバに転送され、
前記送信を実行するコードにおいて、前記クライアントアプリケーションのデータは、前記中間サーバから前記サーバプリケーションに向けて送信されるネットワーク通信のためのコンピュータコード。
【請求項３９】
ネットワーク通信のためのコンピュータコードであって、前記コードが、
ローカルネットワーク上のコンピュータ上でのネットワーク接続要求の受信を実行するコードと、
前記コンピュータ上のトランスポートドライバインターフェイスを用いた前記ネットワーク接続要求の転送を実行するコードと、
前記中間サーバからの前記ファイルシステムのデータの前記コンピュータでの受信を実行するコードとを含み、
前記受信を実行するコードにおいて、前記ネットワーク接続要求は、リモートネットワーク上のファイルシステムに対して開始され、前記ネットワーク接続要求は、前記ファイルシステムの名前を含んでおり、
前記転送を実行するコードにおいて、前記ネットワーク接続要求は、前記コンピュータ上のトランスポートドライバを避けて転送され、前記ネットワーク接続要求は、前記リモートネットワーク内の前記中間サーバに転送され、
前記受信を実行するコードにおいて、前記ファイルシステムのデータは、前記リモートネットワーク上の前記中間サーバと前記ファイルシステムの間でやりとりされるネットワーク通信のためのコンピュータコード。

【図１Ａ】

【図１Ｂ】

【図２Ａ】

【図２Ｂ】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８Ａ】

【図８Ｂ】

【図９Ａ】

【図９Ｂ】

【図９Ｃ】

【図１０】

【図１１】

【図１２】

【図１３Ａ】

【図１３Ｂ】

【図１４】

【図１５】

【図１６】

【図１７Ａ】

【図１７Ｂ】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【公表番号】特表２００６−５２６８４３（Ｐ２００６−５２６８４３Ａ）
【公表日】平成１８年１１月２４日（２００６．１１．２４）
【国際特許分類】

物理学 (1,541,580)
- 計算；計数 (381,677)
  - 電気的デジタルデータ処理 (228,215)
    - 不正行為から計算機を保護するためのセキュリティ装置 (22,301)
      - コンピュータシステムまたはコンピュータネットワークのノードへの... (9,223)
    - メモリ，入力／出力装置または中央処理ユニットの間の情報または他... (29,400)

【出願番号】特願２００６−５０９９６６（Ｐ２００６−５０９９６６）
【出願日】平成１６年４月８日（２００４．４．８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１１３３９
【国際公開番号】ＷＯ２００４／０９２９０５
【国際公開日】平成１６年１０月２８日（２００４．１０．２８）
【出願人】（５０５３５０８４６）ジュニパー　ネットワークス，　インコーポレイテッド (5)
【Ｆターム（参考）】

[ Back to top ]

クライアントリダイレクトによるプライベートネットワークへの安全なアクセス提供方法およびシステム

メニュー

スポンサーリンク

次の公報 »

« 前の公報

クライアントリダイレクトによるプライベートネットワークへの安全なアクセス提供方法およびシステム

メニュー

スポンサー リンク

次の公報 »

« 前の公報

スポンサーリンク