(57)【特許請求の範囲】
【請求項１】
クライアント識別情報をサーバのアプリケーションに提供するシステムであって、
クライアント識別情報としてのクライアントＩＰアドレスを含むクライアント通信情報を受信可能な入力と、クライアント通信情報からクライアントＩＰアドレスを含むタグ付きデータ流を発生させるタグ付加器と、タグ付きデータ流を含むサーバ通信情報をサーバに送信可能な出力とを有するインテリジェント中間装置と、
サーバ通信情報に含まれるタグ付きデータ流からクライアントＩＰアドレスを取出し、サーバのアプリケーションに提供するインターセプタとより成り、
タグ付加器は、クライアントＩＰアドレスがタグ付きデータ流の少なくとも１つのタグ付きパケットのデータ・フィールドに挿入されるようにクライアントＩＰアドレスをサーバ通信データに連結し、得られたデータをパケット化してサーバ通信情報を形成するように構成されることを特徴とするクライアント識別情報をサーバのアプリケーションに提供するシステム。
【請求項２】
インターセプタは、アプリケーションからサーバのオペレーティング・システムへ送られる、サーバ通信情報の送信元のＩＤを求める要求を含むコールを傍受し、この傍受したコールに対してサーバ通信情報の送信元のＩＤでなくてクライアントＩＰアドレスを含む応答をすることによって、クライアントＩＰアドレスをアプリケーションに提供することを特徴とする請求項１のシステム。
【請求項３】
インターセプタはさらにサーバ通信情報に含まれる通信データをアプリケーションに提供するように構成されることを特徴とする請求項１のシステム。
【請求項４】
クライアント識別情報としてのクライアントＩＰアドレスを含むクライアント通信情報を受信可能な入力と、クライアントに代わってサーバ通信情報をサーバに送信可能な出力とを有するプロキシと、
クライアント通信情報からクライアントＩＰアドレスを含むタグ付きデータ流を発生させるタグ付加器とより成り、
タグ付加器は、クライアントＩＰアドレスがタグ付きデータ流の少なくとも１つのタグ付きパケットのデータ・フィールドに挿入されるようにクライアントＩＰアドレスをサーバ通信データに連結し、得られたデータをパケット化してサーバ通信情報を形成するよう
に構成されることを特徴とするインテリジェント中間装置。
【請求項５】
請求項４のインテリジェント中間装置からクライアントＩＰアドレスを含む少なくとも１つのタグ付きパケットを有するサーバ通信情報を受信するように構成されるオペレーティング・システムと、
サーバ通信情報からのデータを受信するように構成されるアプリケーションと、
少なくとも１つのタグ付きパケットからクライアントＩＰアドレスを取出すように構成されるインターセプタとより成り、
インターセプタは、アプリケーションからサーバのオペレーティング・システムへ送られる、サーバ通信情報の送信元のＩＤを求める要求を含むコールを傍受し、この傍受したコールに対してサーバ通信情報の送信元のＩＤでなくてクライアントＩＰアドレスを含む応答をすることによって、クライアントＩＰアドレスをアプリケーションに提供することを特徴とする送信元識別サーバ。
【請求項６】
アプリケーションはウェブ・サーバである請求項５の送信元識別サーバ。
【請求項７】
アプリケーションはｅメール・サーバである請求項５の送信元識別サーバ。
【請求項８】
インテリジェント中間装置からのサーバ通信情報は暗号化セキュア・データを含む請求項５の送信元識別サーバ。
【請求項９】
インターセプタはオペレーティング・システムにローダブル・モジュールとしてインストールされる請求項５の送信元識別サーバ。
【請求項１０】
クライアント識別情報をサーバのアプリケーションに提供する方法であって、
インテリジェント中間装置により、クライアント識別情報としてのクライアントＩＰアドレスを含むクライアント通信情報を受信し、クライアント通信情報から取得したクライアントＩＰアドレスを含む少なくとも１つのタグ付きパケットを有するサーバ通信情報を発生させ、
インテリジェント中間装置により、サーバ通信情報をサーバに送信し、
インターセプタにより、サーバ通信情報内の少なくとも１つのタグ付きパケットを認識し、
インターセプタにより、少なくとも１つのタグ付きパケットからクライアントＩＰアドレスを取出し、
インターセプタにより、クライアントＩＰアドレスをサーバのアプリケーションに提供するステップより成り、
インテリジェント中間装置によりサーバ通信情報を発生させる前記ステップは、クライアントＩＰアドレスを少なくとも１つのタグ付きパケットのデータ・フィールドに挿入するステップを含むことを特徴とするクライアント識別情報をサーバのアプリケーションに提供する方法。
【請求項１１】
インターセプタによりクライアントＩＰアドレスをサーバのアプリケーションに提供する前記ステップは、
アプリケーションからサーバのオペレーティング・システムへ送られる、サーバ通信情報の送信元のＩＤを求める要求を含むコールを傍受し、
この傍受したコールに対してサーバ通信情報の送信元のＩＤでなくてクライアントＩＰアドレスを含む応答をするステップを含むことを特徴とする請求項１０の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に電子ネットワークに係り、特にクライアント識別情報をサーバのアプリケーションに提供するシステム及び方法に関する。
【背景技術】
【０００２】
多くのクライアント−サーバ・ネットワークにおいて、クライアントとサーバとは直接交信せず、少なくとも多様な中間装置を通して交信する。ウェブ・プロキシのようなあるデバイスはクライアントとのコネクションを終了させ、新たなコネクションをサーバに対して開く。中間装置がクライアントに代わってコンテンツを要求するためにサーバとの間でコネクションを確立するとき、サーバは仮に中間装置がない場合と同様な方法を用いても、その要求の最初の送信元あるいはインターネット・プロトコル（ＩＰ）アドレスのような送信元の他の属性を突き止めることができない。、サーバはその要求の直接の送信元が中間装置であると理解することが多い。
【０００３】
サーバがコンテンツを求める要求の最初の送信元、典型的にはクライアントのＩＰアドレスを知る必要がある場面がある。たとえば、サーバはクライアントのＩＰアドレスに基づいて権限付与プロセスを実行しなればならず、あるいはサーバにあるアプリケーションがマーケッティングの有効性を評価するために一意のビジター識別名としてクライアントＩＰアドレスを使用したいことがある。別の例では、サーバはクライアントが実際にある場所に応じてクライアントに送信されるコンテンツを変更したいことがある。このような場合、サーバは適切なコンテンツをクライアントに向けて送信するためクライアントのＩＰアドレスを知る必要がある。
【０００４】
サーバはまたセキュリティを目的としてクライアントＩＰアドレスを使用する。たとえば、サーバは信用が確保された或る特定のクライアントにだけ或る特定のデータを送信するように構成されるか、一定の地域または国に属するクライアントからの要求には応じないようにプログラムされることがある。しかしながら、これらのセキュリティ手段を有効にするには、サーバは最初の要求者であるそのクライアントのＩＰアドレスを知る必要がある。
【０００５】
クライアントのＩＰアドレスをサーバに知らせるために幾つかの中間装置が用いる公知技術はＨＴＴＰプロトコルのＸフォワーデッド・フォー・ヘッダ・ラインあるいは同様な目的を持つ別のヘッダを使用することである。このヘッダ・ラインは最初の送信元のＩＰアドレスを含み、また最初の送信元と中間装置との間に存在する他の中間装置のアドレスを含むことがある。この技術では、サーバのソフトウエアは多様な目的のためにこのＩＰアドレスのリストを使用するように構成されている。この技術の欠点はＨＴＴＰのような少数のプロトコルにだけ利用できる点にあり、ＦＴＰのような他のプロトコルと共に使用することができない。第２の欠点は暗号化による安全なコネクション（たとえば、ＳＳＬを使用するコネクション）の場合、プロキシは暗号に書き換えられたＨＴＴＰレベルのデータを理解するだけで、ヘッダ・ラインを適切に修正することができない。第３の欠点はヘッダが権限のないクライアントによって偽造できることである。第４の欠点は透明性の不足である。サーバのソフトウエアは、新しいヘッダを解釈し使用するため再構成または再プログラムされる必要があり、このような新しいサーバの変更は高コストとなるかまたは不可能である。
【０００６】
クライアントのＩＰアドレスをサーバに提供する別の公知技術はクライアントを知って
いるかについて中間装置に積極的に質問する要求−応答サービスである。この技術では、サーバのソフトウエアは中間装置へコネクトして、クライアントのＩＰアドレスを要求するように構成されている。この技術の欠点は要求−回答サイクルに時間がかかり、特にそのクライアントが求めるコンテンツを作成する前にサーバがクライアントのＩＰアドレスを知る必要がある場合に遅れを伴うことである。この技術のさらなる欠点は透明性の不足である。サーバはこれらの質問を開始するようにプログラムされ、回答が到着するまでの遅れに対処するように構成されなければならない。
【０００７】
クライアントＩＰアドレスをサーバに提供する別の公知技術は中間装置からサーバへアドレス情報をオフラインで転送することである。この技術は中間装置がクライアントのコネクションのログを保つのを必要とする。この技術はマーケット・リサーチの目的のためには有用であるが、権限付与の目的のためにあるいはコンテンツをクライアントの要求に合わせるためにサーバがクライアントＩＰアドレスを使用するのを許可しない。この技術の欠点はサーバデータ管理プロセスに関して透明性が不足することである。
【発明の概要】
【０００８】
本発明によると、クライアント識別情報をサーバのアプリケーションに提供するシステムであって、クライアント識別情報としてのクライアントＩＰアドレスを含むクライアント通信情報を受信可能な入力と、クライアント通信情報からクライアントＩＰアドレスを含むタグ付きデータ流を発生させるタグ付加器と、タグ付きデータ流を含むサーバ通信情報をサーバに送信可能な出力とを有するインテリジェント中間装置と、サーバ通信情報に含まれるタグ付きデータ流からクライアントＩＰアドレスを取出し、サーバのアプリケーションに提供するインターセプタとより成り、タグ付加器は、クライアントＩＰアドレスがタグ付きデータ流の少なくとも１つのタグ付きパケットのデータ・フィールドに挿入されるようにクライアントＩＰアドレスをサーバ通信データに連結し、得られたデータをパケット化してサーバ通信情報を形成するように構成されることを特徴とするクライアント識別情報をサーバのアプリケーションに提供するシステムが提供される。一実施例では、インターセプタは、アプリケーションからサーバのオペレーティング・システムへ送られる、サーバ通信情報の送信元のＩＤを求める要求を含むコールを傍受し、この傍受したコールに対してサーバ通信情報の送信元のＩＤでなくてクライアントＩＰアドレスを含む応答をすることによって、クライアントＩＰアドレスをアプリケーションに提供する。
【０００９】
本発明によると、クライアント識別情報としてのクライアントＩＰアドレスを含むクライアント通信情報を受信可能な入力と、クライアントに代わってサーバ通信情報をサーバに送信可能な出力とを有するプロキシと、クライアント通信情報からクライアントＩＰアドレスを含むタグ付きデータ流を発生させるタグ付加器とより成り、タグ付加器は、クライアントＩＰアドレスがタグ付きデータ流の少なくとも１つのタグ付きパケットのデータ・フィールドに挿入されるようにクライアントＩＰアドレスをサーバ通信データに連結し、得られたデータをパケット化してサーバ通信情報を形成するように構成されることを特徴とするインテリジェント中間装置が提供される。
【００１０】
本発明によると、クライアント識別情報をサーバのアプリケーションに提供する方法であって、インテリジェント中間装置により、クライアント識別情報としてのクライアントＩＰアドレスを含むクライアント通信情報を受信し、クライアント通信情報から取得したクライアントＩＰアドレスを含む少なくとも１つのタグ付きパケットを有するサーバ通信情報を発生させ、インテリジェント中間装置により、サーバ通信情報をサーバに送信し、インターセプタにより、サーバ通信情報内の少なくとも１つのタグ付きパケットを認識し、インターセプタにより、少なくとも１つのタグ付きパケットからクライアントＩＰアドレスを取出し、インターセプタにより、クライアントＩＰアドレスをサーバのアプリケーションに提供するステップより成り、インテリジェント中間装置によりサーバ通信情報を発生させる前記ステップは、クライアントＩＰアドレスを少なくとも１つのタグ付きパケットのデータ・フィールドに挿入するステップを含むことを特徴とするクライアント識別情報をサーバのアプリケーションに提供する方法が提供される。一実施例では、インターセプタによりクライアントＩＰアドレスをサーバのアプリケーションに提供する前記ステップは、アプリケーションからサーバのオペレーティング・システムへ送られる、サーバ通信情報の送信元のＩＤを求める要求を含むコールを傍受し、この傍受したコールに対してサーバ通信情報の送信元のＩＤでなくてクライアントＩＰアドレスを含む応答をするステップを含む。
【発明を実施するための最良の形態】
【００１１】
図１Ａは本発明に従う電子ネットワーク１００の一実施例のブロック図である。このネットワーク１００は、これに限られないが、クライアント１１０と、ネットワーク１１２と、インテリジェント中間装置１１４と、ネットワーク１１６と、送信元識別サーバ１１８とを備える。クライアント１１０は、典型的にはコンテンツを入手する要求を含むクライアント通信情報をネットワーク１１２を通してインテリジェント中間装置１１４に送信する。インテリジェント中間装置１１４はクライアント１１０からの通信情報を受信し、終了させ、その後、典型的にはコンテンツを入手する要求を含むサーバ通信情報をネットワーク１１６を経由し、別のコネクションを使用して送信元識別サーバ１１８に送信する。送信元識別サーバ１１８はその要求に従ってコンテンツを作成し、その後作成したコンテンツをインテリジェント中間装置１１４に送信する。コンテンツはこの後クライアント１１０に送信される。図１Ａの実施例では、クライアント１１０とインテリジェント中間装置１１４と送信元識別サーバ１１８とがトランスポート層およびネットワーク層においてＴＣＰ／ＩＰ（インターネット・プロトコルを使用するトランスミッション・コントロール・プロトコル）を有するプロトコル・スタックに従って通信する。インテリジェント中間装置１１４はクライアント−サーバ間に独立したコネクションを確立する、たとえばプロキシ、いずれかの形式の代用サーバ、サーバ・ロード・バランサおよびセキュア・ソケット・レイヤー（ＳＳＬ）ゲートウェイのようないずれかの形式のネットワーキング装置である。インテリジェント中間装置１１４の他の例は“ウェブ・コンテンツの高性能配信方法”の名称で出願された米国特許出願番号第０９／５３４，３２１号に記載されている。この明細書の開示は参照してここにその全体を取り入れる。
【００１２】
インテリジェント中間装置１１４はクライアント１１０の識別情報を含むように送信元識別サーバ１１８に送信されるサーバ通信情報を修正する。インテリジェント中間装置１１４はクライアント識別情報を含むように最初の通信情報データを修正し、またはクライアント識別情報を含むようにサーバ通信情報のプロトコル・ヘッダを修正し、あるいはこれの２つの組み合わせによる方法を修正する。好ましいインテリジェント中間装置１１４の具体的内容および機能は図２と共に以下に説明される。好ましい送信元識別サーバ１１８はサーバ通信情報からクライアント識別情報を取得し、その情報を適切なアプリケーションに提供する。送信元識別サーバ１１８の具体的内容および機能は図４と共に以下に説明される。
【００１３】
図１Ｂは本発明に従う電子ネットワークの１２０の別の実施例のブロック図である。このネットワークは、これに限られないが、クライアント１２２と、クライアント１２４と、クライアント１２６と、ネットワーク１２８と、インテリジェント中間装置１１４と、ネットワーク１３０と、送信元識別サーバ１１８とを備える。図１Ｂの実施例では、インテリジェント中間装置１１４はクライアント１２２、１２４、１２６のいずれか１つからネットワーク１２８を通してクライアント通信情報を受信する。クライアント通信情報の１つ１つについて、インテリジェント中間装置１１４はサーバ１３２、サーバ１３４あるいは送信元識別サーバ１１８のうち、どのサーバがコンテンツを入手する要求のような情報を受信するかをクライアントに代わって決定し、次いでサーバ通信情報がクライアント識別情報を含むべきか、否かを決定する。送信元識別サーバ１１８に向けた情報の場合、
インテリジェント中間装置１１４はクライアント識別情報を含むサーバ通信情報を作成する。サーバ１３２またはサーバ１３４に向けた情報の場合、インテリジェント中間装置１１４はサーバ１３２およびサーバ１３４が送信元識別サーバではないので、クライアント識別情報を含まないサーバ通信情報を作成する。
【００１４】
図２は本発明に従う図１Ａのインテリジェント中間装置１１４の一実施例のブロック図である。このインテリジェント中間装置１１４は、これに限られないが、プロキシ２１０と、タグ付加器２１２と、ＯＳカーネル２１４とを備える。このプロキシ２１０は送信元識別サーバ１１８用のプロキシとしての役割を果たし、送信元識別サーバ１１８に代わってコンテンツを入手する要求を受信し、応答する。インテリジェント中間装置１１４に記憶されていないかまたは送信元識別サーバ１１８から呼び出すべきコンテンツについては、プロキシ２１０は望ましいコンテンツを要求するため送信元識別サーバ１１８との間にコネクションを確立する。
【００１５】
クライアント１１０はインテリジェント中間装置１１４とのコネクションを確立し、コンテンツを入手する要求をインテリジェント中間装置１１４に送信する。このコネクションの確立にあたり、クライアント１１０はＩＰアドレスを含む識別情報をインテリジェント中間装置１１４に連絡する。（クライアントのような）ある１つのエンドポイントと（中間装置１１４のような）別のエンドポイントとの間に直接のコネクションが存在するときはいつも、エンドポイントの１つ１つが別のエンドポイントのＩＰアドレスを確認できるのがＩＰプロトコルに組み込まれた特性である。しかしながら、それを使用することで生じる、特定の手段（ＩＰヘッダ内の標準専用フィールド）はコネクション内の直接のエンドポイントとして含まれない、他のホスト機器のＩＤを記録するためには使用することができない。プロキシ２１０はクライアント１１０からのコネクションを終了し、送信元識別サーバ１１８に送信されるべきコンテンツを入手する要求を含むサーバ通信情報を作成する。タグ付加器２１２はクライアント１１０の識別情報を含むようにサーバ通信情報を修正し、タグ付きデータを生成する。この後、タグ付きデータ流を生成するためタグ付きデータはＯＳカーネル２１４によってパケット化される。クライアント識別情報を含むタグ付きデータ流を生成する技術は図３Ａおよび図３Ｂと共に以下に説明される。タグ付加器２１２はハードウエア、ソフトウエア、ファームウエアあるいはこれらを組み合わせたものとして備えることができる。ソフトウエアを含むタグ付加器の実施内容では、ソフトウエアはＯＳカーネル２１４の内部装置のネットワーク・スタック・ソフトウエアの内部、ノン・カーネル・アプリケーションの内部またはこれらの組み合わせによるものに備えることができる。インテリジェント中間装置１１４の別の実施例では、タグ付加器２１２はプロキシ２１０と１つに統合される。
【００１６】
図３Ａは本発明の好ましい実施例に従うタグ付きパケット３１０の構成図である。タグ付きパケット３１０はタグ付きデータ流に含まれるデータを保持する最初のパケットである。本実施例では、タグ付加器２１２はクライアント識別情報を最初のサーバ通信情報のデータの前部に連結し、この後得られたタグ付きデータをＯＳカーネル２１４に転送してタグ付きデータをパケット化しタグ付きデータ流を形成する。タグ付きパケット３１０は、これに限られないが、データ・リンク・ヘッダ３１２と、ＩＰオプション・フィールド（図示せず）を含むＩＰヘッダ３１４と、ＴＣＰオプション・フィールド（図示せず）を含むＴＣＰヘッダ３１６と、データ・フィールド３１８とを備える。クライアントＩＰアドレス３２０、認識パターン３２２およびチェック・サム３２４を含むクライアント識別情報はタグ付きパケット３１０のデータ・フィールド３１８に存在する。クライアントＩＰアドレス３２０はある方法、すなわち送信元識別サーバ１１８が、たとえば数字または名称を認識するように構成する方法でフォーマットされたクライアント１１０のＩＰアドレスである。フォーマッティングスキームは認識パターン３２２とチェック・サム３２４とを備えており、他のフィールド（図示せず）を備えてもよい。認識パターン３２２はタ
グ付きパケット３１０をタグ付きデータ流の一部であるパケットとして認識する際に送信元識別サーバ１１８を支援する。チェック・サム３２４はクライアント識別情報が毀損していないことを確かめる際に送信元識別サーバ１１８を支援する。
【００１７】
別の実施例では、認識パターン３２２とチェック・サム３２４とを、毀損に対してガードするために、送信元識別サーバ１１８がタグ付きパケット３１０の属するデータ流がタグを付されたものであるのを認識し、さらにクライアント識別情報を権限または信用があるエンティティにより挿入されたものと認証できるようにする暗号化署名で置き換えるか補足するようにしてもよい。本実施例では、公開鍵暗号法とディジタル署名技術とが使用される。
【００１８】
別の実施例では、認識パターン３２２およびチェック・サム３２４の一方または双方が省略される。たとえば、チェック・サム３２４は毀損の可能性が極めて小さいと見られるとき、省略してもよい。認識パターン３２２は、送信元識別サーバ１１８がクライアント識別情報を含むようにデータ流がタグを付けられていると他の方法で判定できるときは、省略してもよい。仮に、認識パターン３２２およびチェック・サム３２４の双方を省略した場合、送信元識別サーバ１１８はインテリジェント中間装置１１４のＩＰアドレスに基づいてインテリジェント中間装置１１４を認識し、かつインテリジェント中間装置１１４からのデータ流が常にクライアント識別情報を含むと仮定するように構成される。これに代えて、送信元識別サーバ１１８を、他の装置からのタグを付けないデータ流とは異なるＴＣＰ／ＩＰポートによって、インテリジェント中間装置１１４からのタグ付きデータ流を受信するように構成してもよい。
【００１９】
再び図３Ａに戻って、クライアントＩＰアドレス３２０ならびに認識パターン３２２およびチェック・サム３２４用の関連のデータ・フィールドをタグ付きデータ流のデータを保持する最初のタグ付きパケット３１０内の最初のデータとして示す。ＴＣＰ／ＩＰの断片化およびパケット化のための標準方法によれば、特に単一パケットに適合するよりも多くのクライアント識別情報があるときにはタグ付きデータ流の最初の数個のデータ保持パケットに亘ってクライアント識別情報を分散できると理解される。たとえば、タグ付きパケット３１０が、各々がクライアント識別情報の一部を含む２つの小さいパケットに断片化するネットワーク１１６内のＩＰルータを通過するようにしてもよい。これに代えて、データ・フィールド３１８はタグ付きパケット３１０の大きさに応じてクライアント識別情報と一部の最初の通信情報データとを含むようにしてもよい。
【００２０】
クライアント識別情報を含むサーバ通信情報を図３Ａの実施例に従ってパケット化してタグ付きデータ流を作成するとき、送信元識別サーバ１１８はクライアント識別情報を首尾よく取得するためには、オペレーティング・システム・カーネルの変更を必ずしも必要としない。タグ付加器２１２はクライアント識別情報を追加通信情報データとして最初の通信情報データの前のデータ流にただ書き込めばよい。最初の通信情報データの内容およびフォーマットは重要でなく、たとえばデータは暗号に変えられる。
【００２１】
図３Ｂはタグ付きパケット１３１０の別の例の構成図である。本例では、タグ付加器２１２はタグ付きデータ流を生成するためパケット化されたサーバ通信情報のプロトコル・ヘッダを修正する。タグ付きパケット１３１０は、これに限られないが、データ・リンク・ヘッダ１３１２と、ＩＰオプション・フィールド１３３０を含むＩＰヘッダ１３１３と、ＴＣＰオプション・フィールド１３３２を含むＴＣＰヘッダ１３１６と、データ・フィールド１３１８とを備える。本例では、クライアント１１０の識別情報はＩＰオプション・フィールド１３３０またはＴＣＰオプション・フィールド１３３２に挿入される。本例では、送信元識別サーバ１１８のＯＳカーネルは適切なヘッダのオプション・フィールドにあるクライアント識別情報を識別し、それを取り出すように構成されねばならない。本
例では、ＩＰオプション・フィールド１３３０またはＴＣＰオプション・フィールド１３３２に挿入されるクライアント識別情報は認識パターンおよびチェック・サムと共にクライアントＩＰアドレスとして図３Ａに示されるものに類似した方法でフォーマットされる。別の例では、この認識パターンおよびチェック・サムのどちらか一方または双方は省略してもよく、暗号化した署名または他の補助データが提供されるクライアント識別情報を信頼できる方法で確実に取得する際に送信元識別サーバ１１８を支援するために使用される。
【００２２】
タグ付きパケット１３１０の別の例では、クライアント識別情報および関係する補助データのうち、幾つかまたはその全てがＩＰオプション・フィールド１３３０以外のＩＰヘッダ１３１３内の固定フィールド、またはＴＣＰオプション・フィールド１３３２以外のＴＣＰヘッダ１３１６内の固定フィールドに書き換えられる。たとえば、ＴＣＰ“至急の”フラッグ（ＴＣＰヘッダ１３１６の追加の１６ビット）と“至急の”ポインタ（ＴＣＰヘッダ１３１６の１ビット）とは本パケットがクライアント識別情報を含むタグ付きデータ流に属することを表わし、クライアント識別情報または補助データの幾つかの部分を書き換えるように使用される。パケット・ヘッダ内の固定フィールドは送信元識別サーバ１１８がタグ付きデータ流を誤って解釈し、不正確に扱う機会がないと見極めたとき、上記方法で使用される。たとえば、ウェブ・サーバは、多くの場合、ＴＣＰ至急データを予期し、これを処理するようには設計されないが、クライアント識別情報を書き換えるような基準から外れた目的のためにそうした至急ビットおよび至急ポインタを使用することは多様なウェブの背景があるとしても、受け入れることができる。
【００２３】
図にはタグ付きパケット１３１０が１つだけ示されるが、クライアント識別情報はＩＰオプション・フィールド１３３０、ＴＣＰオプション・フィールド１３３２、インテリジェント中間装置１１４−ネットワーク１１６間のコネクションまたはノードの収容能力およびネットワーク１１６内のコネクションのサイズに応じてタグ付きパケットを数個以上に分割してもよい。
【００２４】
図４は本発明に従う図１Ａの送信元識別サーバ１１８の一実施例のブロック図である。送信元識別サーバ１１８は、これに限られないが、アプリケーション４１２と、インターセプタ４１４と、オペレーティング・システム（ＯＳ）カーネル４１６とを備える。図４では、アプリケーション４１２とインターセプタ４１４とがＯＳカーネル４１６から完全に独立するように示されるが、別の実施例では、アプリケーション４１２は、典型的にはカーネルの要素ではないが、システムが呼び出しおよび割り込みを行うような手法によってカーネルの担う仕事をする。アプリケーション４１２はインテリジェント中間装置１１４のような遠隔装置にコンテンツを提供するように構成される。アプリケーション４１２の代表的実施内容にはＨＴＴＰアプリケーションとＳＭＴＰアプリケーションとＦＴＰアプリケーションとを含む。インターセプタ４１４はインテリジェント中間装置１１４から送信される通信情報を傍受し、クライアント識別情報を含むように構成される。本送信元識別サーバ１１８の実施例では、インターセプタ４１４は図３Ａの実施例に従ってタグ付加器２１２で生成したタグ付きデータ流を認識したとき、インターセプタ４１４はそのタグ付きデータ流からクライアント識別情報を取得する。インターセプタ４１４はこの後クライアント識別情報をアプリケーション４１２に提供し、またはクライアント識別情報について質問するアプリケーション４１２の代用手段に提供する。インターセプタ４１４はまたデータ流がそれ以前タグ付加器２１２によって処理されたとき、データ流の最初の通信情報データを修復する。インターセプタ４１４はこの後修復された最初の通信情報データをアプリケーションに送信する。
【００２５】
一実施例では、インターセプタ４１４はコネクションを通して信頼できる送信元から送られるタグ付きデータ流をひたすら探す。たとえば、インテリジェント中間装置１１４は
送信元識別サーバ１１８用の公知のプロキシであり、信頼できる送信元である。別の複数のネットワーク装置（図示せず）が送信元識別サーバ１１８との間でコネクションを開いても、これらの装置が信頼できない送信元であるならば、インターセプタ４１４はこれらのコネクションを通して入ってくるパケットには目を止めない。
【００２６】
典型的サーバでは、アプリケーションがＯＳカーネルの新しいコネクション列から次に利用できるコネクションを呼ぶためＯＳカーネルを呼び出す。たとえば、アプリケーションは新しいコネクションをアプリケーションに送信する、大部分で共通のインターフェースである“アクセプト”システム・コールを呼び出す。このＯＳカーネルは処理用コネクションからのデータを検索するためアプリケーションがコネクションのＩＤ（たとえば、ソケット番号）を示してアクセプト・コールに応答する。このアプリケーションはまたコネクションを通してデータを遠隔装置、たとえばインテリジェント中間装置１１４に送信する。
【００２７】
通常、ＯＳカーネルが新しいコネクションを使ってアクセプト・コールに応答するとき、ＯＳカーネルはまた接続中の遠隔装置のＩＤ（たとえば、ＩＰアドレス）を提供する。これに代えて、アプリケーションは接続中の遠隔装置のＩＤのようなコネクションの属性を求めてＯＳカーネルに問い合わせるため明示の質問システム・コールを使用してもよい。アクセプトのようなシステム・コールまたはコネクション属性を質問するシステム・コールは、典型的にはＯＳカーネルが接続中の遠隔装置の識別情報を書き込むべきバッファのアドレスを含む。通常、ＯＳカーネルはそのシステム・コールに応答し、接続中の遠隔装置の識別情報をバッファに書き込む。ＯＳカーネルに適合するシステム・コールの特定のフォーマットはＯＳカーネルの特定の実施内容に左右される。このアクセプト・コールは、通例では使用されるが、ネットワークにアクセスし、利用するためにアプリケーションで使用されるインタフェースの単なる具体例である。
【００２８】
送信元識別サーバ１１８において、アプリケーション４１２はＯＳカーネル４１６の新しいコネクション列から次に利用できるコネクションを呼ぶためＯＳカーネル４１６を呼び出す。インターセプタ４１４はこのコールを傍受し、次に利用できるコネクションを得るためＯＳカーネルに自身のコールを送信する。いずれかの利用できるコネクションがある場合、ＯＳカーネル４１６はそのうちの１つのコネクションのＩＤと接続中の遠隔装置のＩＰアドレスとを示して応答する。インターセプタ４１４はまた“ペンディング”コネクションの内部に保存された列を有する。ここで、この列は接続中の遠隔装置のコネクションのＩＤとＩＰアドレスとを記録している。ペンディング・コネクションとは未だアプリケーション４１２に報告されないＯＳカーネル４１６でインターセプタ４１４に前もって送信されたコネクションのことである。新たに報告された新しいコネクションまたはペンディング・コネクションのどちらの場合も、インターセプタ４１４は新しいコネクションから入ってくるデータを読むためＯＳカーネル４１６への別のシステム・コールを作成する。インターセプタ４１４はデータ流がクライアント識別情報と共にタグを付されているか、否かを決定するためコネクッションを通して入ってくるデータに注視する。本実施例では、インターセプタ４１４はコネクションによってカーネルのバッファ内部のペンディング・データを精査するが、カーネルのバッファからそのペンディング・データを除かないリード・システム・コールの“ピーク”・ヴァージョンを使用する。
【００２９】
仮に、データ流がクライアント識別情報を示さず、タグも付けられず、たとえばインターセプタ４１４がデータ中の正確な位置に正しい認識パターンを見出せないと決定すれば、インターセプタ４１４はＯＳカーネル４１６から接続中の遠隔装置の新しいコネクションのＩＤとＩＰアドレスとを受信したとき、その情報を正確にアプリケーション４１２に転送する。インターセプタ４１４が入ってくるデータに適切な認識パターンまたは他の識別マーカを認識し、書き込まれたクライアント識別情報が入ってくるデータに完全な形で
存在するならば、インターセプタ４１４はＯＳカーネル４１６のペンディング・データ列からクライアント識別情報が除かれるようにリード・システム・コールのノン−ピーク・ヴァージョンを用いて入ってくるデータからクライアント識別情報を再び読み取る。インターセプタ４１４はこの後新しいコネクションのＩＤをアプリケーション４１２に転送し、ＯＳカーネル４１６から報告された接続中の遠隔装置のアドレスでなく、アプリケーション４１２が提供する取得したクライアント識別情報でバッファを満たす。インターセプタ４１４はまた内部ストレージに保存したコネクションのＩＤと取得したクライアント識別情報との間の対応関係を格納し、ノン−ペンディングとしてそのレコードに符号を付ける。
【００３０】
このコネクションのためにＯＳカーネル４１６のバッファに十分なペンディング・データがあり、インターセプタ４１４が一度にＯＳカーネル４１６から新しいコネクションを受信した場合、インターセプタ４１４はこのデータ流がタグを付されているか、否か、またはデータ流にタグが付されていてもクライアント識別情報が完全か、否かを決定するため新たなコネクションのＩＤをアプリケーション４１２には送信しないが、内部ストレージに保存された接続中の遠隔装置のコネクションのＩＤとアドレスとを記録し、ペンディングとしてそのレコードに符号を付ける。
【００３１】
アプリケーション４１２はまたコネクションの別の接続端によって遠隔装置のＩＤを要求するためＯＳカーネル４１６を呼び出す。これは“アクセプト”として次に利用できるコネクションを求める最初のコールの一部か、または独立したコールであり、ＯＳカーネル４１６の実施内容に左右される。インターセプタ４１４は遠隔装置のＩＤを求めてバッファのアドレスを含むコールを傍受する。インターセプタ４１４は提供されたコネクションのＩＤと関係のあるクライアント識別情報とによる正しい組み合わせのレコードを得るため内部記録に問い合わせる。そうしたレコードが見出された場合、インターセプタ４１４は記憶され、取得したクライアント識別情報でバッファを満たし、この情報をアプリケーション４１２に転送する。そうしたレコードが見出せない場合、インターセプタ４１４は遠隔装置のＩＤを求めてそのコールをＯＳカーネル４１６に転送し、ＯＳカーネル４１６がインテリジェント中間装置１１４のＩＤをバッファに書き込んで応答する。本実施例では、アプリケーション４１２側がそのときのコールに応じて受信する回答がインターセプタ４１４によって修正されたことを知らないので、インターセプタ４１４はクライアント識別情報をアプリケーション４１２に対して包み隠さず提供する。
【００３２】
インターセプタ４１４の別の実施例は代替的実施内容の細部を備える。ＯＳシステム・コールＡＰＩの細部基準および完全な支持が要求される程度によりインターセプタ４１４を使って傍受しなければならい多数のシステム・コールが存在する。たとえば、インターセプタ４１４がアプリケーション４１２による検索結果について受信し、タグの付かないデータをバッファに保存するように構成される場合、インターセプタ４１４はペンディング・データを読み込むためノン−ピーク・システム・コールを使用する。インターセプタ４１４の別の実施例によれば、インターセプタ４１４は読み込んでいるデータと関わりのあるシステム・コールを傍受することを必要とする場合があり、その上、インターセプタ４１４が内部ストレージから必要とするところにデータを送信する場合がある。
【００３３】
アプリケーション４１２はこの後いずれかの目的のためにバッファにあるクライアント１１０の識別情報を使用する。たとえば、アプリケーション４１２は要求に応じて適切なコンテンツを決定し、あるいは要求したコンテンツの受信に向けてクライアント１１０が許可できるか、否かを決定するためクライアント１１０のＩＤを使用する。アプリケーション４１２はまたクライアント１１０のＩＤを唯一のビジターのログに加えるようにしてもよい。
【００３４】
一実施例では、インターセプタ４１４は選択されたシステム・コールがライブラリ・コードで傍受されるようにアプリケーション４１２の始動シーケンスの中でプリロードされる共用ライブラリである。インターセプタ４１４の特定の実施内容はアプリケーション４１２で使用された特定の実施内容（たとえば、ＨＴＴＰウェブ・サーバまたはＳＭＴＰメール・サーバ）、さらにはＯＳカーネル４１６で使用された特定の実施内容（たとえば、ウィンドーズまたはリナックス）に従って各々インタフェースするように構成しなければならない。たとえば、ＯＳカーネル４１６の特定の実施内容は各々独自にフォーマットされたコールに応じて回答する。インターセプタ４１４を構成するにあたり、アプリケーション４１２およびＯＳカーネル４１６の特定の実施内容に従ってインタフェースする技術はこの技術分野では公知である。
【００３５】
本実施例に係る送信元識別サーバ１１８では、クライアント１１０のＩＤをアプリケーション４１２に提供するのにアプリケーション４１２またはＯＳカーネル４１６に合わせた変更は必要としない。これは送信元識別サーバ１１８にインターセプタ４１４を備えるように構成することを容易に可能にする。また、送信元識別サーバ１１８で受信した暗号化セキュア・データはインターセプタ４１４の機能によっては影響を受けない。別の実施例では、インターセプタ４１４の機能性がアプリケーション４１２のコードに合わせて修正して実施される。
【００３６】
クライアント識別情報が低レベル・パケット・ヘッダに埋め込まれている、図３Ｂのタグ付きパケット１３１０のようなタグ付きパケットを処理するため送信元識別サーバ１１８は、典型的にはあるカーネル・レベルのアクセスを必要とする。代替的実施例のインターセプタ４１４はアプリケーション４１２から直接システム・コールを受信するように構成される、ローダブル・カーネル・モジュールであり、この後最初のシステム・コールをＯＳカーネル４１６に転送するか、あるいは上記のようにシステム・コールを修正するか、どちらかの方法を使用する。別の実施例では、ＯＳカーネル４１６は最初のシステム・コールの実施内容がインターセプタ４１４の機能性を備えて改良されるように修正される。
【００３７】
図５は本発明の一実施例に従うクライアント識別情報を取得するための方法を示すフローチャートである。ステップ５１２において、送信元識別サーバ１１８はコネクションをインテリジェント中間装置１１４に対して確立する。ステップ５１４において、送信元識別サーバ１１８はコネクションを通してデータ流のパケットを受信することを開始する。ステップ５１６において、インターセプタ４１４はパケットがタグを付されたパケットであるか、否かを決定するため最初のパケットにあるデータを注視する。インターセプタ４１４がタグ付きパケットを認識しない場合、本発明方法はステップ５１８へと続き、インターセプタ４１４が全てのデータを修正することなく、コネクションを通してパケットからアプリケーション４１２に転送する。
【００３８】
インターセプタ４１４が少なくとも１つのタグ付きパケットを認識した場合、ステップ５２０において、インターセプタ４１４は全てのクライアント識別情報が読み取られるまで、タグ付きパケットからクライアント識別情報を取り出す。ステップ５２２において、インターセプタ４１４は残りのデータをコネクションを通してパケットからアプリケーション４１２に転送する。
【００３９】
本発明が特定の実施例に対する参照と共に上記の通り説明された。しかしながら、添付の請求の範囲に記載のような本発明の本質と範囲とから離れることなく、多様な変更および変形がなし得ることは明らかである。したがって、上述の説明と図面とは限定の意味ではなく、具体例として考慮すべきである。
【図面の簡単な説明】
【００４０】
【図１Ａ】図１Ａは本発明に従う電子ネットワークの一実施例のブロック図である。
【図１Ｂ】図１Ｂは本発明に従う電子ネットワークの他の実施例のブロック図である。
【図２】図２は本発明に従う図１Ａに示されるインテリジェント中間装置の一実施例のブロック図である。
【図３Ａ】図３Ａは本発明に従うタグ付きパケットの構成図である。
【図３Ｂ】図３Ｂはタグ付きパケットの他の例の構成図である。
【図４】図４は本発明に従う図１Ａに示される送信元識別サーバの実施例のブロック図である。
【図５】図５は本発明の一実施例に従うクライアント識別情報を取得する方法に係るフローチャートである。
【図１Ａ】
0005031574.tif 000002
【図１Ｂ】
0005031574.tif 000003
【図２】
0005031574.tif 000004
【図３Ａ】
0005031574.tif 000005
【図３Ｂ】
0005031574.tif 000006
【図４】
0005031574.tif 000007
【図５】
0005031574.tif 000008