JP5170442B2 - 通信システム、ノード装置及びそれらに用いる通信方法 - Google Patents

Description

本発明は、通信システム、ノード装置及びそれらに用いる通信方法に関し、特にＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網において行われるトランスポート層及びネットワーク層におけるセッション（ｓｅｓｓｉｏｎ）の多重化（ｍｕｌｔｉｐｌｅｘ）に用いられるセッションの識別に関する。尚、本出願は、日本出願番号２００６−３３１４０２に基づく優先権を主張するものであり、日本出願番号２００６−３３１４０２における開示内容は引用により本出願に組み込まれる。

従来、サーバ装置やクライアント装置のノード装置で用いられるインタネットプロトコルの階層構造は、図１に示すように、アプケーション層２１０（Ａｐｐｌｉｃａｔｉｏｎ ｓｏｃｋｅｔ）と、トランスポート（Ｔｒａｎｓｐｏｒｔ）層２２０［ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）］と、ネットワーク（Ｎｅｔｗｏｒｋ）層２３０（ＩＰ）と、データリンク（Ｄａｔａ Ｌｉｎｋ）層２４０と、物理層２５０とから構成されている。

上記のノード装置からなる通信システムにおいては、そのノード装置においてＩＰ通信のセッションの多重化が行われており、このＩＰ通信のセッションを多重化して識別するには、ネットワーク層２３０のアドレス情報とトランスポート層２２０のポート情報とを用いて行われている（例えば、“ＴＣＰ Ｐｏｒｔ Ｓｅｒｖｉｃｅ Ｍｕｌｔｉｐｌｅｘｅｒ（ＴＣＰＭＵＸ）”［ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）：１０７８ Ｎｏｖｅｍｂｅｒ １９８８］（非特許文献１）参照）。

上記の階層構造において、例えば、クライアント装置からサーバ装置にアクセスが行われる場合、サーバ装置のアプケーション層２１０から提供されるサービスと、クライアント装置のアプケーション層２１０のアプリケーションとの間で設定されるセッション（Ｓｅｓｓｉｏｎ）は、宛先（サーバ装置）のポート番号及びアドレス情報と送信元（クライアント装置）のポート番号及びアドレス情報とで特定される。

上記の非特許文献１には、現在のＩＰ通信の多重化とサービス情報の提供に使われている基本的概念が述べられている。セッションの多重化とその識別には、発信元の「アドレス情報」及び「ポート情報」と、宛先の「アドレス情報」及び「ポート情報」との４つの情報が用いられている。その情報の一つでも異なれば、異なるセッションとして識別される。アドレス情報はネットワーク層２３０に属する情報であり、ポート情報はトランスポート層２２０に属する情報であるため、セッションの識別のために２つの層にわたる情報が用いられている。

一般的に、サーバ装置のポート番号としては、ウェルノウン（Ｗｅｌｌ−Ｋｎｏｗｎ）ポート番号が用いられており、クライアント装置のポート番号としては、エフェメラル（Ｅｐｈｅｍｅｒａｌ）ポート番号（セッション毎に異なる）が用いられている。

ウェルノウンポート番号は、特定の上位アプリケーションを識別するためのポート番号であり、例えば、２２番ポートにＳＳＨ（Ｓｅｃｕｒｅ ＳＨｅｌｌ）、２３番ポートにｔｅｌｎｅｔ、２５番ポートにＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、８０番ポートにＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）、１２３番ポートにＮＴＰ、５３番ポートにｄｏｍａｉｎ等というように割り当てられている。

また、エフェメラルポート番号は、クライアント装置がサーバ装置に接続している間、クライアント装置側で一時的に開設されるポートの番号であり、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）［カーネル（ｋｅｒｎｅｌ）］によって空いているポートの中から選択される。

上述した従来の多重化方法では、ネットワーク層及びトランスポート層という異なる二つの層で多重化を行うことになり、フィルタリングをはじめとして多くの機能実装の効率が悪いということに加えて、セキュリティ的に問題があり、ＩＰ通信にとって適切な方式となっていない。

例えば、ルータ／ゲートウェイ／ファイアウォール（Ｆｉｒｅｗａｌｌ）等の中間ノードにおけるセッション識別を要する処理について考えると、中間ノードでフィルタリング等の処理を行う場合、本来はネットワーク層に閉じた処理を行うだけでよい中間ノードが、トランスポート層の情報まで解析して処理しており、複雑で効率の悪い実装になっている。

また、末端ノードにおけるセッション識別を要する処理について考えると、ファイヤウォールやＩＰＳｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｕｔｙ ｐｒｏｔｏｃｏｌ）のＳＰＤ（Ｓｅｃｕｒｉｔｙ Ｐｏｌｉｃｙ ＤａｔａＢａｓｅ）の設定等は、どのセッションを対象にするかを指定する必要があるが、その設定を二つの層にわたる情報を用いて行うことになり、設定を複雑化にしているのに加え、機能実装も非効率なものになっている。

上記のウェルノウンポートを用いたサービス情報提供に関する問題としては、以下の問題がある。従来の多重化方法では、どのようなサービスが提供されているか示すものとして、サーバ（宛先）の用いるポート情報を代表情報と捉えるウェルノウンポートという方式が導入されている。この場合、サービスの本質はどのポート番号を使っているかではなく、どのようなシーケンスでどのようなプロトコルが用いられているかである。

例えば、セキュリティ対策等の目的で意図的にウェルノウンポートとは異なるポート番号でサービスを提供している例等が知られている。また、ファイアウォールを設置し、ｈｔｔｐ（ｈｙｐｅｒ ｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）通信のみの通信を許可するために、８０番や４４３番のポートのみが通過可能な設定にされているサイトが多いが、そのような環境でＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）機能を提供するために、８０番や４４３番のポートを本来の目的外であるＶＰＮ通信のために使う等ということも頻繁に行われている。これらはポート情報がサービスを代表する情報として適当ではないことを示している。

このように、従来の多重化方法では、１つのサービスを示すのに、ＩＰアドレスとポート番号情報との２つの情報が必要であり、ファイアウォール等のフィルタでＩＰアドレス及びポート番号情報の両方を扱うのは処理の複雑化を招き、ルータではネットワーク層とトランスポート層との両方を見なければならない。

また、従来の多重化方法では、ポート情報として、サーバ側の標準的なサービスに対して事前にポート番号が割り当てられている（ウェルノウンポート）ので、ＩＰアドレスが漏洩した場合、事前にポート番号が割り当てられていると、そのポート番号に対して悪意ある人物の操作する装置からの攻撃（Ａｔｔａｃｋ）が発生する可能性がある。

そこで、本発明の目的は、セッション識別の処理負荷を軽減することができる通信システム、ノード装置及びそれらに用いる通信方法を提供することにある。

本発明による通信システムは、インタネットプロトコルのトランスポート層及びネットワーク層を含むノード装置からなる通信システムであって、
前記ノード装置は、前記トランスポート層及びネットワーク層におけるセッションの識別を前記ネットワーク層における前記セッションの識別に統合して行う。

本発明による通信システムは、複数のノード装置を具備する。複数のノード装置の各々は、他のノード装置との間で送受信するデータのアドレスフィールド内の情報に基づいて、データを処理するためのアプリケーションを決定する。

本発明によるノード装置は、インタネットプロトコルのトランスポート層及びネットワーク層を含むノード装置であって、
前記トランスポート層及びネットワーク層におけるセッションの識別を前記ネットワーク層における前記セッションの識別に統合して行っている。

本発明によるノード装置は、セッションユニットと、アプリケーションユニットを具備する。セッションユニットは、他ノード装置から送信されたデータのアドレスフィールド内の情報に基づいて、受信したデータを処理するためのアプリケーションを決定する。アプリケーションユニットは、セッションユニットによって決定されたプログラムを実行することで受信したデータを処理する。

本発明による通信方法は、インタネットプロトコルのトランスポート層及びネットワーク層を含むノード装置に用いる通信方法であって、
前記ノード装置が、前記トランスポート層及びネットワーク層におけるセッションの識別を前記ネットワーク層における前記セッションの識別に統合して行っている。

本発明は、上記のような構成及び動作とすることで、通信システム及びノード装置におけるセッション識別の処理負荷を軽減することができる。

上記発明の目的、効果、特徴は、添付される図面と連携して実施の形態の記述から、より明らかになる。

図１は、従来技術によるノード装置に用いられるインタネットプロトコルの階層構造を示す図である。 図２は、本発明の一実施例によるノード装置に用いられるインタネットプロトコルの階層構造を示す図である。 図３Ａは、相互に通信を行うノード装置ががレガシー通信（第２通信モード）によってセッションを設定する場合におけるセッション及び階層構造の一例を示す模式図である。 図３Ｂは、図３Ａに示すセッションを特定する情報を示す図である。 図４Ａは、相互に通信を行うノード装置ががレガシー通信（第２通信モード）によってセッションを設定する場合におけるセッション及び階層構造の一例を示す模式図である。 図４Ｂは、図４Ａに示すセッションを特定する情報を示す図である。 図５Ａは、相互に通信を行うノード装置ががレガシー通信（第２通信モード）によってセッションを設定する場合におけるセッション及び階層構造の一例を示す模式図である。 図５Ｂは、図５Ａに示すセッションを特定する情報を示す図である。 図６Ａは、相互に通信を行うノード装置ががレガシー通信（第２通信モード）によってセッションを設定する場合におけるセッション及び階層構造の一例を示す模式図である。 図６Ｂは、図６Ａに示すセッションを特定する情報を示す図である。 図７Ａは、タイプＡにおけるセッション及び階層構造の一例を示す模式図である。 図７Ｂは、図７Ａに示すセッションを特定する情報を示す図である。 図８Ａは、タイプＡにおけるセッション及び階層構造の一例を示す模式図である。 図８Ｂは、図８Ａに示すセッションを特定する情報を示す図である。 図９Ａは、タイプＡにおけるセッション及び階層構造の一例を示す模式図である。 図９Ｂは、図９Ａに示すセッションを特定する情報を示す図である。 図１０Ａは、タイプＡにおけるセッション及び階層構造の一例を示す模式図である。 図１０Ｂは、図１０Ａに示すセッションを特定する情報を示す図である。 図１１Ａは、タイプＢにおけるセッション及び階層構造の一例を示す模式図である。 図１１Ｂは、図１１Ａに示すセッションを特定する情報を示す図である。 図１２Ａは、タイプＢにおけるセッション及び階層構造の一例を示す模式図である。 図１２Ｂは、図１２Ａに示すセッションを特定する情報を示す図である。 図１３Ａは、タイプＢにおけるセッション及び階層構造の一例を示す模式図である。 図１３Ｂは、図１３Ａに示すセッションを特定する情報を示す図である。 図１４Ａは、タイプＢにおけるセッション及び階層構造の一例を示す模式図である。 図１４Ｂは、図１４Ａに示すセッションを特定する情報を示す図である。 図１５Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図１５Ｂは、図１５Ａに示すセッションを特定する情報を示す図である。 図１６Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図１６Ｂは、図１６Ａに示すセッションを特定する情報を示す図である。 図１７Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図１７Ｂは、図１７Ａに示すセッションを特定する情報を示す図である。 図１８Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図１８Ｂは、図１８Ａに示すセッションを特定する情報を示す図である。 図１９Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図１９Ｂは、図１９Ａに示すセッションを特定する情報を示す図である。 図２０Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図２０Ｂは、図２０Ａに示すセッションを特定する情報を示す図である。 図２１Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図２１Ｂは、図２１Ａに示すセッションを特定する情報を示す図である。 図２２Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図２２Ｂは、図２２Ａに示すセッションを特定する情報を示す図である。 図２３Ａは、タイプＤにおけるセッション及び階層構造の一例を示す模式図である。 図２３Ｂは、図２３Ａに示すセッションを特定する情報を示す図である。 図２４Ａは、タイプＤにおけるセッション及び階層構造の一例を示す模式図である。 図２４Ｂは、図２４Ａに示すセッションを特定する情報を示す図である。 図２５Ａは、タイプＤにおけるセッション及び階層構造の一例を示す模式図である。 図２５Ｂは、図２５Ａに示すセッションを特定する情報を示す図である。 図２６Ａは、タイプＤにおけるセッション及び階層構造の一例を示す模式図である。 図２６Ｂは、図２６Ａに示すセッションを特定する情報を示す図である。 図２７Ａは、タイプＤにおけるセッション及び階層構造の一例を示す模式図である。 図２７Ｂは、図２７Ａに示すセッションを特定する情報を示す図である。 図２８Ａは、タイプＤにおけるセッション及び階層構造の一例を示す模式図である。 図２８Ｂは、図２８Ａに示すセッションを特定する情報を示す図である。 図２９Ａは、タイプＤにおけるセッション及び階層構造の一例を示す模式図である。 図２９Ｂは、図２９Ａに示すセッションを特定する情報を示す図である。 図３０Ａは、タイプＤにおけるセッション及び階層構造の一例を示す模式図である。 図３０Ｂは、図３０Ａに示すセッションを特定する情報を示す図である。 図３１Ａは、タイプＡにおけるセッション及び階層構造の一例を示す模式図である。 図３１Ｂは、図３１Ａに示すセッションを特定する情報を示す図である。 図３２Ａは、タイプＡにおけるセッション及び階層構造の一例を示す模式図である。 図３２Ｂは、図３２Ａに示すセッションを特定する情報を示す図である。 図３３Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図３３Ｂは、図３３Ａに示すセッションを特定する情報を示す図である。 図３４Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図３４Ｂは、図３４Ａに示すセッションを特定する情報を示す図である。 図３５Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図３５Ｂは、図３５Ａに示すセッションを特定する情報を示す図である。 図３６Ａは、タイプＣにおけるセッション及び階層構造の一例を示す模式図である。 図３６Ｂは、図３６Ａに示すセッションを特定する情報を示す図である。 図３７は、本発明による通信システムの実施例における構成を示す図である。

次に、本発明の実施例について図面を参照して説明する。図２は本発明の一実施例によるノード装置に用いられるインタネットプロトコルの階層構造を示す図である。図２は、本発明の一実施例による階層構造であるユニファイド（Ｕｎｉｆｉｅｄ）の階層構造を示している。

図１を参照して、レガシーの階層構造は、アプケーション（Ａｐｐｌｉｃａｔｉｏｎ）層２１０と、トランスポート（Ｔｒａｎｓｐｏｒｔ）層２２０と、ネットワーク（Ｎｅｔｗｏｒｋ）層２３０と、データリンク（Ｄａｔａ Ｌｉｎｋ）層２４０と、物理層２５０とからなり、トランスポート層２２０ではポート多重化［Ｐｏｒｔ ｍｕｘ（ｍｕｌｔｉｐｌｅｘ）］２２１が行われ、ネットワーク層２３０ではアドレス多重化（Ａｄｄｒｅｓｓ ｍｕｘ）２３１が行われている。

これに対し、本発明の一実施例によるユニファイドの階層構造は、図２に示すように、アプケーション層１１０と、トランスポート層１２０と、ネットワーク層１３０と、データリンク層１４０と、物理層１５０とからなっているが、トランスポート層１２０及びネットワーク層１３０におけるセッション（ｓｅｓｓｉｏｎ）の識別を、ネットワーク層１３０における識別に統合することで、セッション（ｓｅｓｓｉｏｎ）の多重化（ｍｕｘ）を、ネットワーク層１３０における多重化処理（アドレス多重化）１３１に統合している。

（構成）
図３７を参照して、本発明による通信システムの構成の実施例を説明する。、通信システムは、複数のノード装置を含む。複数のノード装置は、サービスを提供するサーバ１０と、サービスを提供するクライアント装置１１、１２を備える。ここで、サーバ１０及びクライアント装置１１、１２の数は、図３７に示す数に限定されない。サーバ１０及びクライアント装置１１、１２のそれぞれは、セッション毎にＩＰアドレスを割り当てており、従来のようなポートによるセッションの多重化は行わない。すなわち、本発明による通信方法に用いられるアドレス情報（例えばＩＰアドレス）は、通信システム内のノード装置（サーバ装置１０、クライアント装置１１、１２）を識別する機能（従来のアドレス情報に相当する機能）と、セッションを構築する通信相手（例えばアプリケーション）を識別する機能（従来技術におけるポート番号に相当する機能）とを有する。又、詳細は後述するが、本発明に係るアドレス情報は、サービスを利用するユーザを特定する機能を有しても良い。

図３７を参照して、サーバ１０の構成を説明する。サーバ１０は、記憶装置２０内のアプリケーションを実行することでサービスを提供するアプリケーションユニット２１と、他ノード（クライアント装置１１、１２のそれぞれにおけるアプリケーションユニット３１との間でセッションを確立するセッションユニット２２とを備える。又、サーバ１０は、自身を特定するためのアドレスを払い出すアドレス払出しユニット２３を更に備えることが好ましい。アプリケーションユニット２１、セッションユニット２２、及びアドレス払出しユニット２３は、２０内のプログラムを実行するＣＰＵによって実現されることが好ましい。

セッションユニット２２は、送受信するデータのアドレスフィールド内の情報（例えばＩＰアドレス）に基づいてセッションを識別する。例えば、セッションユニット２２は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ヘッダのアドレスフィールド内の情報に基づいてセッションを識別する。すなわち、セッションユニット２２は、受信したデータのアドレスフィールド内の情報（例えば宛先アドレス）に基づいて、受信したデータの宛先となるサービス（データを処理するためのアプリケーション）を決定する。又、セッションユニット２２は、クライアント装置におけるアプリケーションに対応したアドレスを宛先アドレスとして、送信データのアドレスフィールドに挿入する。

アドレス払出しユニット２３は、通信相手として許可した他ノード装置に対応するアドレス（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を、自身が提供するサービスを特定するためのアドレスとして払出すことが好ましい。これにより、サーバ装置１０は、Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅアドレスを利用したセッションを行うクライアント装置を許可された通信相手として認識できる。換言すれば、クライアント装置は、Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅアドレスを知ることなしに、当該Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅアドレスに対応するサービスを受けることができなくなる。

又、アドレス払出しユニット２３は、通信相手を特定せずにサービスを特定するアドレス（Ｇｅｎｅｒｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を払い出してもよい。

以上のように、本発明によるサーバ装置１０は、ポートフィールドを参照せず、アドレスフィールド内の情報（アドレス情報）に基づいてセッションの識別を行う。あるいは、サーバ装置１０は、ポートフィールドを参照してもポートフィールド内の情報（ポート情報）を解釈せずに、アドレス情報のみに基づいてセッション識別を行う。すなわち、本発明に係るサーバ装置１０は、セッションを多重化する際、ポート番号を用いずＩＰアドレスを用いてセッションの識別を行う。

又、サーバ装置１０は、本発明によるセッション識別方法を利用したユニファイド通信と、従来技術によるセッション識別方法を利用したレガシー通信とを選択的に利用しても構わない。ここで、本発明によるセッション識別方法（ユニファイド通信）を第１通信モード、従来技術によるセッション識別方法（レガシー通信）を第２通信モードとする。セッションユニット２２は、送受信されるデータのポートフィールド内の情報に基づいてセッション識別方法を決定する。ユニファイド通信（第１通信モード）を利用する場合、セッションユニット２２は、「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」と呼ぶ特別なポート番号をデータのポートフィールドに挿入する。例えば、このポート番号は、ユニファイド通信の際のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ヘッダのポートフィールドに挿入される。

セッション識別方法を選択的に利用する場合、セッションユニット２２は、ソケットＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）等の機能によって、受信したデータのポートフィールド内の情報（ポート情報）を取得することが好ましい。受信したデータから取得したポート情報が、「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」と呼ぶ特別なポート番号である場合、セッションユニット２２は、ユニファイド通信（第１通信モード）をセッション識別方法として選択する。一方、受信データから取得したポート情報が「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」以外のポート番号を示す場合、セッションユニット２２は、セッション識別方法としてレガシー通信（第２通信モード）を選択し、取得したポート番号に基づいてセッションを識別する。

以上のように、セッション識別方法を選択的に利用することで、サーバ装置１０は従来技術（レガシー通信）を用いたノード装置（例えばクライアント装置）との間で通信することができる。

図３７を参照して、クライアント装置１１の構成を説明する。クライアント装置１２の構成はクライアント装置１１と同様であるので、その説明を省略する。クライアント装置１１は、記憶装置３０内のアプリケーションを実行することでサービスを提供するアプリケーションユニット３１と、他ノード（例えばサーバ装置１０）におけるアプリケーションユニット２１との間でセッションを確立するセッションユニット３２とを備える。アプリケーションユニット３１、セッションユニット３２は、記憶装置内のプログラムを実行するＣＰＵによって実現されることが好ましい。

セッションユニット３２は、送受信するデータのアドレスフィールド内の情報（例えばＩＰアドレス）に基づいてセッションを識別する。例えば、セッションユニット３２は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ヘッダのアドレスフィールド内の情報に基づいてセッションを識別する。すなわち、セッションユニット３２は、受信したデータのアドレスフィールド内の情報（例えば宛先アドレス）に基づいて、受信したデータの宛先となるアプリケーション（データを処理するためのアプリケーション）を決定する。又、セッションユニット３２は、サーバ装置１０が提供するサービス（アプリケーション）に対応したアドレスを宛先アドレスとして、送信データのアドレスフィールドに挿入する。

クライアント装置１１では、ＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）の機能によって未使用のアドレス（エフェメラルアドレス）が、セッション毎に割り振られる。従来技術では、実際に通信を開始する際にＯＳから自動的にポート番号が割り振られるエフェメラルポートの機能がある。本発明によるクライアント装置１１では、この機能をポート情報からアドレス情報へ発展させることで、エフェメララルアドレスの割り振り機能を実現できる。セッションユニット３２は、エフェメラレルアドレスをソースアドレスに指定してセッションの設定を行う。又、セッションユニット３２は、セッション終了後、ソースアドレスとして指定したエフェメラルアドレスを破棄する。このため、セッションユニット３２は、セッション毎に新しいアドレスをソースアドレスとして指定することとなる。

以上のように、本発明によるクライアント装置１１は、ポートフィールドを参照せず、アドレスフィールド内の情報（アドレス情報）に基づいてセッションの識別を行う。あるいは、クライアント装置１１は、ポートフィールドを参照してもポートフィールド内の情報（ポート情報）を解釈せずに、アドレス情報のみに基づいてセッション識別を行う。すなわち、本発明に係るクライアント装置１１は、セッションを多重化する際、ポート番号を用いずＩＰアドレスを用いてセッションの識別を行うことができる。

又、クライアント装置１１は、サーバ装置１０と同様に、本発明によるセッション識別方法を利用したユニファイド通信と、従来技術によるセッション識別方法を利用したレガシー通信とを選択的に利用しても構わない。セッションユニット３２は、送受信されるデータのポートフィールド内の情報に基づいてセッション識別方法を決定する。ユニファイド通信（第１通信モード）を利用する場合、セッションユニット３２は、「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」と呼ぶ特別なポート番号をデータのポートフィールドに挿入する。

セッション識別方法を選択的に利用する場合、セッションユニット３２は、ソケットＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）等の機能によって、受信したデータのポートフィールド内の情報（ポート情報）を取得することが好ましい。受信したデータから取得したポート情報が、「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」である場合、セッションユニット３２は、ユニファイド通信（第１通信モード）をセッション識別方法として選択する。一方、受信データから取得したポート情報が「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」以外のポート番号を示す場合、セッションユニット３２は、セッション識別方法としてレガシー通信（第２通信モード）を選択し、取得したポート番号に基づいてセッションを識別する。

以上のように、セッション識別方法を選択的に利用することで、クライアント装置１１は従来技術（レガシー通信）を用いたノード装置（例えばサーバ装置）との間とも通信することができる。

本発明の一実施例では、セッション毎にＩＰアドレスを割り当てており、従来のようなポートによるセッションの多重化は行っていない。すなわち、本発明による通信システムでは、アドレス情報によってセッションを識別するため、トランスポート層でセッション識別処理を行う必要がない。このため、ノード装置（サーバ装置１０、クライアント装置１１、１２）におけるセション識別処理の負荷が軽減される。

また、本発明に係るアドレス情報（例えばＩＰアドレス）は、通信システム内のノード装置を識別する機能と、従来技術におけるポート情報に相当する機能を有する。すなわち、アドレスフィールド内に従来技術におけるポート情報に相当する情報（ポート相当情報）が挿入されているため、従来技術のようにポート番号の割り当てが不要となる。このためリゾルビング（Ｒｅｓｏｌｖｉｎｇ）が、アドレス解決のみに一元化される。

ここで、ポート相当情報（基本的に１６ｂｉｔの情報）のアドレスフィールドへの入れ方としては、例えば、そのままプレーン（ｐｌａｉｎ）な形で、暗号／ハッシュ（ｈａｓｈ）的処理を加えた形で、すかし的に入れる形で入れることができる。尚、ＩＰｖ６の場合、Ｂｌｏｃｋ ＤＡＤ（Ｄｕｐｌｉｃａｔｅ Ａｄｄｒｅｓｓ Ｄｅｔｅｃｔｉｏｎ：重複アドレス検出）に影響を与えるため、ポート相当情報は、アドレスフィールドにおけるＰｒｅｆｉｘ ｆｉｅｌｄには入れられない。このため、ＩＰｖ６が適用された通信システムでは、ポート相当情報は、Ｉｎｔｅｒｆａｃｅ ＩＤ（下位６４ｂｉｔ）の中に挿入されることが好ましい。

本発明の一実施例では、セッションを多重化する際に、セッションの識別にＩＰアドレスのみが用いられるため、ノード装置間に設けられた中間ノード装置はトランスポート層の情報を解析する必要がない。このため、通信システムへのフィルタやＩＰｓｅｃ ＳＰＤの実装・運用等を容易化（シンプル化）することができ、従来技術で生じたポート情報の問題を解決することができる。

本実施例では、ネットワーク層でのみ多重化処理を行い、送信元のアドレス情報と、宛先のアドレス情報との二つの情報だけで、ＩＰ通信セッションを識別することができるようになる。また、一般にトランスポート層のポート情報を高速に処理するための特別な技術は存在していないが、ネットワーク層には経路制御で培かったアドレス情報を高速に処理する技術が存在しており、これを利用することができる。この点おいても、本発明による通信システムは従来技術に比べ効率良くセッションを設定できる。このように、ネットワーク層の多重化技術（ルーティングテーブルの検索）の方がトランスポート層の多重化技術より優れているので、ネットワーク層の多重化処理への統合の効果が大きい。このネットワーク層の多重化処理への統合は、ルーティング（ｒｏｕｔｉｎｇ）／ルータ（ｒｏｕｔｅｒ）には全く影響がない。このため、本発明による通信システムは、従来技術を利用した通信システムの構成を大きく変更せずに、従来技術と共存することができる。

本発明によれば、アドレス情報がセッションの識別情報になるため、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）をはじめとした従来技術による情報レゾルビングの機構がセッション構築に利用され得る。このため、従来技術のようにウェルノウン（Ｗｅｌｌ−Ｋｎｏｗｎ）ポート番号に頼る仕組みからも決別することができる。また、レゾルビングの応用的利用や、どのようなアドレスを通信に用いるかを制御することによって、セキュリティ／プライバシーに配慮することが可能になる。すなわち、本発明によれば、従来技術で使用していたウェルノウンポート番号が必要がなくなるため、プライバシーを中心とした高いセキュリティ機能を提供することが可能となる。

本発明によれば、ＩＰアドレス情報がサービスの本質を代表する情報となり、無理のない最適化された仕組みとなる。このため、本発明による通信方法はＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）通信にも適用することができる。

また、基本的な機能は末端ノードだけでの対応で実現されるものであり、ルータ等の中間ノードへの影響がなく、その面でも導入が容易な構造になっている。ユニファイド通信では、レガシー通信のポート“相当”の情報を内包したアドレス情報を用いることになるため、広いアドレス空間を持つＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６）に適したアーキテクチャであることが好ましい。

また、セッションを多く扱うサーバ装置１０では、サービスの種類（ポート）の分だけアドレスを持つので、アドレス空間の広いＩＰｖ６が適している。上記のネットワーク層の多重化処理への統合は、２箇所の処理を１箇所の処理に統合するので、基本的に新たな処理が生ずることはない。しかも、トランスポート層の実装が簡単になり、Ｐｒｏｔｏｃｏｌ Ｓｔａｃｋを小さくすることができるので、小型／組込み系の通信装置への実装が楽になる。

一般に、アドレスをノード装置に割り当てても、すぐに使用することはできない。例えば、ＩＰｖ６を採用した通信システムでは、アドレスをノード装置に割り当てても、ＤＡＤ（Ｄｕｐｌｉｃａｔｅ Ａｄｄｒｅｓｓ Ｄｅｔｅｃｔｉｏｎ：重複アドレス検出）のために１秒以上待たされる。このため、本発明では、事前にＤＡＤを終えたアドレスをプール（ｐｏｏｌ）して持っている方法を取ることが好ましい。尚、１秒以上待ってもよい場合等にはこれに限定されない。

アドレスをプール（ｐｏｏｌ）して持っている方法としては、１つのアドレスに対するＤＡＤを地道に複数回繰り返してプールする方法、１つのアドレスではなく、１回のＤＡＤ手順でアドレスのブロック（ｂｌｏｃｋ）としてＤＡＤを終えてプールする方法（ＤＡＤの機能拡張）がある。

本実施例で最も重要視されるのは、既存のアプリケーションを変更することなく、レガシー実装との通信を容易に行うことができ、レガシー実装とユニファイド実装とが共存できることである。そのために、本実施例では、上記の「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」と呼ぶ特別なポート番号を導入している。このポート番号は、ユニファイド通信の際のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ヘッダのポートフィールドに用いるものであり、ソケットＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）等のポート情報が求められるところで用いる特別な番号である。

ユニファイド通信でも形式的にポートは存在しても良い。しかしながら、ユニファイド通信におけるポートは実質的意味はなく、セッションの識別には利用されない。この場合、ポートフィールドには、値として特別なポート番号「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が設定される。違う表現をすると、ポート情報（ポート番号）が「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」になっていれば、それはユニファイド通信のセッションであることを示す。

「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」として具体的にどのような値を用いるかについては、その性質（例えばサービスを識別する機能）からしてそのノード装置内に閉じればよい情報である。このため、個々の実装で決めた任意の番号を用いることができる。従来技術による実装では、「０番」が一般にエフェメラルポート機能のために予約されている。しかし、本発明によるユニファイドＭｕｌｔｉｐｌｅｘ機能はその機能を包含することができるため、「０番」を用いることも可能である。但し、ルータ等の中間ノードでユニファイド通信かどうかを判別して処理をしたいという要求に対応するためには、この番号を共用とすることが望ましい。

一般的に、レガシーの階層構造におけるクライアント装置は、エフェメラルポートを使用してサーバ装置と通信を行う。この場合、クライアント装置のポート情報やアドレスの設定方法には、ポート情報をＯＳ が設定する一般型（Ｕ−Ｔｙｐｅ）と、ポート情報をユーザが設定する例外型（Ｖ−Ｔｙｐｅ）とがある。以下では、Ｕ−Ｔｙｐｅ、Ｖ−Ｔｙｐｅそれぞれの通信システムに本発明によるユニファイド階層構造を実装する場合の改良点を説明する。

Ｕ−Ｔｙｐｅのレガシー通信システムの場合、クライアント装置では、ソケット（ｓｏｃｋｅｔ）は用意されるが、バインド（ｂｉｎｄ）は用いられない。このため、クライアント装置においてセッションが設定される際、ソース（ｓｏｕｒｃｅ）（クライアント：ｃｌｉｅｎｔ）のポートは明示的に指定されない。この場合、ソース（クライアント装置）側のポート及びアドレスの設定はＯＳによって行われる。つまりクライアント装置では、ＯＳが未使用のポートを選択し、ソースポートに動的に割り当てている（エフェメラルポートの割り当て）。この後、クライアント装置は、宛先（ｄｅｓｔｉｎａｔｉｏｎ）（サーバ：ｓｅｒｖｅｒ）のアドレス、ポートを指定して接続（ｃｏｎｎｅｃｔ）を行う。

上述のＵ−Ｔｙｐｅの通信システムに、本発明によるユニファイド階層構造を実装する場合について説明する。本発明によるクライアント装置１１、１２では、ユニファイド通信を行う際、セッションユニット３２が、ポート情報として「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」を設定し、アドレス情報として、ＯＳによって選定されたエフェメラルアドレス（ｅｐｈｅｍｅｒａｌ ａｄｄｒｅｓｓ）を設定する。したがって、Ｕ−Ｔｙｐｅの通信システムの場合、レガシー通信を行うユーザアプリケーションを変更することなく、ＯＳ（カーネル）によるエフェメラルポートの選定機能をエフェメラルアドレスの選定機能に変更するだけで、既存の通信システムにユニファイド階層構造を実装することができる。

一方、Ｖ−Ｔｙｐｅのレガシー通信システムの場合、クライアント装置は、例外的にエフェメラルポートを使用しない。この場合、クライアント装置におけるセッションの設定では、ソケットが用意され、バインド（ｂｉｎｄ）が用いられることでソースポートが明示的に設定される（同時にアドレスが指定される場合もある）。この後、クライアント装置におけるセッションの設定では、宛先のアドレス、ポートが指定され、サーバとの間の接続（ｃｏｎｎｅｃｔ）が行われる。しかしながら、この方法では、同じノード装置において、複数のユーザがが同じポートを指定した場合、エラーとなって利用することができない。

上述のＶ−Ｔｙｐｅの通信システムに、本発明によるユニファイド階層構造を実装する場合について説明する。このタイプの通信システムには、ポート番号を用いてフィルタリングやルーティングを行うノード装置（中間ノード装置）が存在する場合がある。このため、Ｖ−ｔｙｐｅの通信システムに本発明による通信システムを適用するためには、所定の制約条件を解決する必要がある。例えば、ソースポートをバインドする際に「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」を使うようにすれば、明示的にユニファイド通信を選択することが可能となる。その際、複数のプロセス（ｐｒｏｃｅｓｓ）がポート番号情報として「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」を使用してもエラーにならないように上述のユニファイド階層構造を実装する必要がある。

一般的に、レガシーの階層構造におけるサーバ装置のポート情報やアドレスの通信方法には、サーバ装置の持つ任意のアドレスに対する接続を受付ける一般型（Ｘ−Ｔｙｐｅ）と、サーバの持つ特定アドレスに対する接続のみを受付ける設定型（Ｙ−Ｔｙｐｅ）とがある。以下では、Ｘ−Ｔｙｐｅ、Ｙ−Ｔｙｐｅそれぞれの通信システムに本発明によるユニファイド階層構造を実装する場合の改良点を説明する。

Ｘ−Ｔｙｐｅのレガシー通信システムの場合、一般的に、サーバ装置側では不特定のＩＰアドレス（ＩＮＡＤＤＲ＿ＡＮＹ／ＩＮ６ＡＤＤＲ＿ＡＮＹ＿ＩＮＩＴ）待ちの場合がある。この場合、セッションの設定においては、ソケットが用意され、バインドが用いられることで明示的にサーバ装置の待ち受けのポートが指定される。ポートとしてサーバのサービスに応じたウェルノウン（ｗｅｌｌ ｋｎｏｗｎ）ポートが設定される（アプリケーションの引数や設定ファイルからバインドするポート番号情報が渡される）。この際、アドレスは誰からでもいい（ＩＮＡＤＤＲ＿ＡＮＹ／ＩＮ６ＡＤＤＲ＿ＡＮＹ＿ＩＮＩＴ）が指定される。この後に、サーバ装置は、ｌｉｓｔｅｎ、ａｃｃｅｐｔを実行する。

上述のＸ−Ｔｙｐｅの通信システムに、本発明によるユニファイド階層構造を実装する場合について説明する。バインドによってＩＮＡＤＤＲ＿ＡＮＹ／ＩＮ６ＡＤＤＲ＿ＡＮＹ＿ＩＮＩＴが指定されている場合、サーバプロセス（Ｓｅｒｖｅｒ ｐｒｏｃｅｓｓ）が開始した後にアドレスが設定されても、サーバ装置１０のアプリケーション（アプリケーションユニット２１）はそのアドレス宛ての通信でも受信することができる。この場合、セッションユニット２２は、ポート情報として「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」を使用すればよい。ユニファイド通信であれば、アドレスを明示的に指定することになるので、サーバのアプリケーションを使い方を含めて変更することなく使用することができる。

一方、Ｙ−Ｔｙｐｅのレガシー通信システムの場合、サーバ装置は特定のＩＰアドレスを待ち受ける。この場合、サーバ装置におけるセッションの設定では、ソケットが用意され、バインドが用いられて明示的にサーバの待ち受けのポートとアドレスとが指定される。ポートとしてサーバ装置のサービスに応じたウェルノウン（ｗｅｌｌ ｋｎｏｗｎ）ポートが設定される（アプリケーション層からバインドされたポート番号情報が渡される）。アドレスは特定のアドレス（アプリケーション層から）が設定される。この後に、サーバ装置は、ｌｉｓｔｅｎ、ａｃｃｅｐｔを実行する。

上述のＹ−Ｔｙｐｅの通信システムに、本発明によるユニファイド階層構造を実装する場合について説明する。この場合、サーバプロセスはアドレスが決定する前に開始することは不可能であるので、既存のサーバの起動方法は使えない。したがって、この場合には、アドレスが決まった後にプロセスの再起動を行う方法が利用されることになる。この場合、ポートは「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が設定される。ユニファイド通信であれば、アドレスを明示的に指定することになるので、ユニファイド通信を使う場合には、アプリケーションで「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」を指定することになる。サーバにおけるカーネルの実装改良はクライアントでの実装と比べると、比較的軽く、簡単である。

ここで、ＲＦＣ３０４１［Ｔ．Ｎａｒｔｅｎ，Ｒ．Ｄｒａｖｅｓ，“Ｐｒｉｖａｃｙ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ Ｓｔａｔｅｌｅｓｓ Ａｄｄｒｅｓｓ Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎ ＩＰｖ６”（Ｊａｎｕａｒｙ ２００１）］（非特許文献２）には、プライバシー強化のためにテンポラリイアドレス（Ｔｅｍｐｏｒａｒｙ Ａｄｄｒｅｓｓ）というものが定義されている。これはクライアントの発信元アドレスに用い、そのアドレス利用に寿命があり、プライバシーを強化できる点等、上記のエフェメラルアドレスによく似た機能が提供されている。

テンポラリイアドレスは、“複数”のサービスや相手に対して用いられる。そのアドレス利用開始及び終了のタイミングの定義は明瞭になっていない。そのため、極端な場合には、その寿命が切れた際に、使用途中であってもそのアドレスが無効となり、セッションが突然切れてしまうかもしれない等という潜在的問題を抱えている。

一方、本発明においてセッション毎に設定されるエフェメラルアドレスは、“単一”のサービスや相手に対して設定されることが好ましい。エフェメラルアドレスの設定方法は、エフェメラルポートの方法を踏襲したもので、セッションの開始とともに設定され、セッションの終了時に廃棄される。したがって、エフェメラルアドレスは、使用途中にアドレスが無効になり、セッションが突然切れてしまう等ということは基本的に発生しない。

テンポラリイアドレスは、比較的長い寿命を想定したものであるため、結果としてアドレスの“使いまわし”を行っており、使い捨てに徹していない仕様のため、潜在的問題を抱えている。それに対し、エフェメラルアドレスは、“使い捨て”に徹しており、テンポラリイアドレスにあるような問題がない。よって、エフェメラルアドレスは、寿命も比較的短いものになり、そのためにアタックを受けにくく、セキュリティ的視点でも良い。

また、テンポラリイアドレスは、単純な乱数を用いて生成されるため、生成したアドレス間の関連性がないため、アドレス情報だけではどのノードが生成し、保持するものであるかがわからない。よって、テンポラリイアドレスは、Ａｎｏｎｙｍｉｔｙ（匿名性）は提供されるものの、何らかの管理しようとした場合に管理することができず、結果として、扱い難い情報になっている。

それに対し、エフェメラルアドレスでは、ポート相当情報をアドレスの中に包含させる必要があり、その情報の包含のさせ方次第では、アドレス間に関連を持たせ、意味があるものにすることができる。つまり、そのアドレス生成規則を知るものにとっては、管理可能な情報になりえる。エフェメラルアドレスの場合、Ａｎｏｎｙｍｉｔｙだけではなく、Ｐｓｅｕｄｏｎｙｍｉｔｙ（同一であることが分かる匿名性）も提供可能なものになりえる。その面においても、エフェメラルアドレスは、良い方法であると考えられる。

次に、ユニファイド通信で用いるアドレスの型について説明する。ユニファイド通信で用いるアドレスの型は、クライアント側で用いるものとサーバ側で用いるものとに大きく分類される。サーバ側のアドレスはさらに２つの型に分けられ、全部で３つの型に大きく分類される。

まず、クライアント側のアドレス（Ｅｐｈｅｍｅｒａｌ Ａｄｄｒｅｓｓ）の型について述べる。このクライアント側のアドレスの型は、既存のレガシー通信で用いられている、実際に通信を開始する際にＯＳから自動的にポート番号を割り振ってもらうエフェメラルポートの機能を、ポート情報からアドレス情報へと発展させることによって、生まれたアドレスの型である。

このアドレスの型では、セッション毎に基本的に新しくなり、恒久的に用いないことによって、セキュリティが向上するのに加え、プライバシーへも配慮することができる。このアドレスの型は、既存のクライアントプログラムを全く変更することなく用いることができる。

次に、サーバ側の第１のアドレス［（Ｃｌｉｅｎｔ） Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ］の型について述べる。このサーバ側のアドレスの型は、ある通信相手からの接続のためだけ等の特定の条件のついたサービスを提供するのに用いるアドレスの型である。このアドレスの型は、ユニファイド通信で新規に導入する型のアドレスであり、その全特性を利用するには通信スタイルとしても新しいものを用いることになる。

続いて、サーバ側の第２のアドレス（Ｇｅｎｅｒｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）の型について述べる。このサーバ側のアドレスの型は、通信相手等を特定せずに不特定の相手に対してサービスを提供する場合に用いるアドレスの型である。

このアドレスの型は、従来のレガシー通信での発想や使い方を継承したもので、サービスを示す指標がポート情報からアドレス情報へ移行したことによって生まれたものである。このアドレスの型は、既存のサーバプログラムを全く変更することなく用いることができる。

本発明による通信システムでは、ポート情報に応じてレガシー通信とユニファイド通信を選択する機能を採用することも可能である。この場合、通信システム内に従来技術を利用したノード装置が混在していても、本発明によるノード装置は、セッションを識別することができる。すなわち、従来技術による通信システムの構成を変えることなく、本発明によるノード装置、あるいは通信システムを従来の通信システムに導入することができる。

次に、上述したレガシー通信とユニファイド通信との共存について述べる。尚、サーバ装置１０が提供するサービスを「Ａｘ」、クライアント装置１１、１２のアプリケーションを「Ｂｘ」、サーバ装置１０のレガシー通信におけるポートを「ａｘ」、アドレスを「ｂｘ」、サーバ装置１０のユニファイド通信におけるアドレスを「Ｃｘ」、クライアント装置１１、１２のレガシー通信におけるポートを「ｃｘ」、アドレスを「ｄｘ」、サーバ装置１０のユニファイド通信におけるアドレスを「Ｄｘ」とする。ｘは任意の整数である。

又、以下では、多重化通信の最小構成となる２つのセッションを１つのサーバ上で実現する形態を、４つのタイプ（タイプＡ、Ｂ、Ｃ、Ｄ）に分類して、本発明による通信システムにおけるレガシー通信とユニファイド通信の共存について説明する。

タイプＡ（Ｔｙｐｅ Ａ）：サーバ装置１０が１つのサービスＡ１，Ａ２を提供し、クライアント装置１１（Ｃｌｉｅｎｔ １１）が２つのアプリケーションＢ１，Ｂ２から１つのサービスＡ１，Ａ２にアクセスする場合。
タイプＢ（Ｔｙｐｅ Ｂ）：サーバ装置１０が２つのサービスＡ３，Ａ４を提供し、クライアント装置１２（Ｃｌｉｅｎｔ １２）が２つのアプリケーションＢ３，Ｂ４から２つのサービスＡ３，Ａ４にアクセスする場合。
タイプＣ（Ｔｙｐｅ Ｃ）：サーバ装置１０が１つのサービスＡ５，Ａ６を提供し、クライアント装置１１、１２（Ｃｌｉｅｎｔ １１，Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ５，Ｂ６から１つのサービスＡ５，Ａ６にアクセスする場合。
タイプＤ（Ｔｙｐｅ Ｄ）：サーバ装置１０が２つのサービスＡ７，Ａ８を提供し、クライアント装置１１、１２（Ｃｌｉｅｎｔ １１，Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ７，Ｂ８から２つのサービスＡ７，Ａ８の一方にアクセスする場合。

図３Ａ、図４Ａ、図５Ａ、図６Ａは、サーバ装置１０及びクライアント装置１１、１２がレガシー通信（第２通信モード）によってセッションを設定する場合のセッション及び階層構造の一例を示す模式図である。この場合、サーバ装置１０及びクライアント装置１１、１２は従来技術と同様な動作によりセッションを識別する。図３Ｂ、図４Ｂ、図５Ｂ、図６Ｂは、図３Ａ、図４Ａ、図５Ａ、図６Ａに示すセッションを特定する情報を示す図である。

図３Ａは、タイプＡにおいて、サーバ装置１０及びクライアント装置１１が共にレガシー通信を行う場合のセッション及び階層構造を示す模式図である。この場合、サービスＡ１とアプリケーションＢ２とのセッションは、図３Ｂに示すように、宛先ポート「ａ１」、宛先アドレス「ｂ１」、送信元ポート「ｃ２」、送信元アドレス「ｄ１」で特定される。また、サービスＡ２とアプリケーションＢ１とのセッションは、図３Ｂに示すように、宛先ポート「ａ１」、宛先アドレス「ｂ１」、送信元ポート「ｃ１」、送信元アドレス「ｄ１」で特定される。

図４Ａは、タイプＢにおいて、サーバ装置１０及びクライアント装置１１が共にレガシー通信を行う場合のセッション及び階層構造を示す模式図である。この場合、サービスＡ３とアプリケーションＢ４とのセッションは、図４Ｂに示すように、宛先ポート「ａ２」、宛先アドレス「ｂ２」、送信元ポート「ｃ４」、送信元アドレス「ｄ２」で特定される。また、サービスＡ４とアプリケーションＢ３とのセッションは、図４Ｂに示すように、宛先ポート「ａ３」、宛先アドレス「ｂ２」、送信元ポート「ｃ３」、送信元アドレス「ｄ２」で特定される。

図５Ａは、タイプＣにおいて、サーバ装置１０及びクライアント装置１１が共にレガシー通信を行う場合のセッション及び階層構造を示す模式図である。この場合、サービスＡ５とアプリケーションＢ６とのセッションは、図５Ｂに示すように、宛先ポート「ａ４」、宛先アドレス「ｂ３」、送信元ポート「ｃ６」、送信元アドレス「ｄ４」で特定される。また、サービスＡ６とアプリケーションＢ５とのセッションは、図５Ｂに示すように、宛先ポート「ａ４」、宛先アドレス「ｂ３」、送信元ポート「ｃ５」、送信元アドレス「ｄ３」で特定される。

図６Ａは、タイプＤにおいて、サーバ装置１０及びクライアント装置１１が共にレガシー通信を行う場合のセッション及び階層構造を示す模式図である。この場合、サービスＡ７とアプリケーションＢ８とのセッションは、図６Ｂに示すように、宛先ポート「ａ５」、宛先アドレス「ｂ４」、送信元ポート「ｃ８」、送信元アドレス「ｄ６」で特定される。また、サービスＡ８とアプリケーションＢ７とのセッションは、図６Ｂに示すように、宛先ポート「ａ６」、宛先アドレス「ｂ４」、送信元ポート「ｃ７」、送信元アドレス「ｄ５」で特定される。

（タイプＡにおけるレガシー通信とユニファイド通信の共存）
図７Ａ、図８Ａ、図９Ａ、図１０Ａは、タイプＡにおけるセッションの設定を、レガシー通信の階層構造と本発明の一実施例によるユニファイド通信の階層構造とを組み合わせて行う場合の一例を示す図である。図７Ｂ、図８Ｂ、図９Ｂ、図１０Ｂは、図７Ａ、図８Ａ、図９Ａ、図１０Ａに示すセッションを特定する情報を示す図である。

図７Ａは、タイプＡにおいて、サーバ装置１０及びクライアント装置１１が共にレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＡ−ＬＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＡ−ＬＬは、レガシーの階層構造のサーバ装置１０が１つのサービスＡ１，Ａ２を提供し、レガシーの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）が２つのアプリケーションＢ１，Ｂ２からアクセスする場合を示す。

タイプＡ−ＬＬの場合、サービスＡ１とアプリケーションＢ２とのセッションＡ１Ｂ２は、図７Ｂに示すように、宛先ポート「ａ１」、宛先アドレス「ｂ１」、送信元ポート「ｃ２」、送信元アドレス「ｄ１」で特定される。また、サービスＡ２とアプリケーションＢ１とのセッションＡ２Ｂ１は、図７Ｂに示すように、宛先ポート「ａ１」、宛先アドレス「ｂ１」、送信元ポート「ｃ１」、送信元アドレス「ｄ１」で特定される。

図８Ａは、タイプＡにおいて、サーバ装置１０がレガシー通信（第２通信モード）によってセッションを設定し、クライアント装置１１がユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＡ−ＬＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＡ−ＬＵは、レガシーの階層構造のサーバ装置が１つのサービスＡ１，Ａ２を提供し、ユニファイドの階層構造のクライアント装置１０（Ｃｌｉｅｎｔ １１）が２つのアプリケーションＢ１，Ｂ２からアクセスする場合を示す。

本一例のクライアント装置１１は、セッション毎（プログラムやクライアントユーザ毎）に異なるアドレスＤ１、Ｄ２（エフェメラルアドレス）を指定する。この場合、サーバ装置１０のサービスＡ１、Ａ２は、それぞれ異なるアドレスＤ２、Ｄ１を宛先アドレスとしてプログラムＢ２、Ｂ１にアクセスする。

タイプＡ−ＬＵにおけるサービスＡ１とアプリケーションＢ２とのセッションについて説明する。クライアント装置１１は、送信元ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、送信元アドレスとしてエフェメラルアドレス「Ｄ２」、宛先ポートとして「ａ１」、宛先アドレスとして「ｂ１」を指定したデータをサーバ装置１０に送信する。サーバ装置１０は、宛先ポート「ａ１」、宛先アドレス「ｂ１」を参照してデータの宛先のサービスＡ１、Ａ２を特定する。又、サーバ装置１０は、送信元ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、送信元ポートを利用せずに送信元アドレス「Ｄ２」のみでデータの送信元のアプリケーションＢ２を特定する。一方、サーバ装置１０は、送信元ポートとして「ａ１」、送信元アドレスとして「ｂ１」、宛先ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、宛先アドレスとして「Ｄ２」を指定したデータをクライアント装置１１に送信する。クライアント装置１１は、宛先ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、宛先ポートを利用せずに宛先アドレス「Ｄ２」のみでデータの宛先のアプリケーションＢ２を特定する。又、クライアント装置１１は、送信元ポート「ａ１」、送信元アドレス「ｂ１」を参照してデータの送信元のサービスＡ１、Ａ２を特定する。すなわち、タイプＡ−ＬＵにおいて、サービスＡ１とアプリケーションＢ２とのセッションは、図８Ｂに示すように、宛先ポート「ａ１」、宛先アドレス「ｂ１」、送信元アドレス「Ｄ２」で特定される。同様に、タイプＡ−ＬＵにおいて、サービスＡ２とアプリケーションＢ１とのセッションは、図８Ｂに示すように、宛先ポート「ａ１」、宛先アドレス「ｂ１」、送信元アドレス「Ｄ１」で特定される。

図９Ａは、タイプＡにおいて、サーバ装置１０がユニファイド通信（第１通信モード）によってセッションを設定し、クライアント装置１１がレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＡ−ＵＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＡ−ＵＬは、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ１，Ａ２を提供し、レガシーの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）が２つのアプリケーションＢ１，Ｂ２からアクセスする場合を示す。尚、タイプＡ−ＬＵとタイプＡ−ＵＬは実質的に同じ形態である。

本一例のサーバ装置１０は、セッション毎に異なるアドレスＣ１、Ｃ２（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。この場合、クライアント装置１１のアプリケーションＢ１、Ｂ２はそれぞれ異なるアドレスＣ２、Ｃ１を宛先アドレスとしてサービスＡ２、Ａ１にアクセスする。

タイプＡ−ＵＬにおけるサービスＡ１とアプリケーションＢ２とのセッションについて説明する。クライアント装置１１は、送信元ポートとして「ｃ２」、送信元アドレスとして「ｄ１」、宛先ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、宛先アドレスとして「Ｃ１」を指定したデータをサーバ装置１０に送信する。サーバ装置１０は、宛先ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、宛先ポートを利用せずに宛先アドレス「Ｃ１」のみでデータの宛先のサービスＡ１を特定する。又、サーバ装置１０は、送信元ポート「ｃ２」、送信元アドレス「ｄ１」を参照して送信元のサービスＢ２を特定する。一方、サーバ装置１０は、送信元ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、送信元アドレスとして「Ｃ１」、宛先ポートとして「ｄ１」、宛先アドレスとして「ｃ２」を指定したデータをクライアント装置１１に送信する。クライアント装置１１は、宛先ポート「ｃ２」、宛先アドレス「ｄ１」を参照してデータの宛先のアプリケーションＢ２を特定する。又、クライアント装置１１は、送信元ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、送信元ポートを利用せずに送信元アドレス「Ｃ１」のみでデータの送信元のサービスＡ１を特定する。すなわち、タイプＡ−ＵＬにおいて、サービスＡ１とアプリケーションＢ２とのセッションは、図９Ｂに示すように、宛先アドレス「Ｃ１」、送信元ポート「ｃ２」、送信元アドレス「ｄ１」で特定される。同様に、タイプＡ−ＵＬにおいて、サービスＡ２とアプリケーションＢ１とのセッションは、図９Ｂに示すように、宛先アドレス「Ｃ２」、送信元ポート「ｃ１」、送信元アドレス「ｄ１」で特定される。

図１０Ａは、タイプＡにおいて、サーバ装置１０及びクライアント装置１１が共にユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＡ−ＵＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＡ−ＵＵは、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ１，Ａ２を提供し、ユニファイドの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）が２つのアプリケーションＢ１，Ｂ２からアクセスする場合を示す。

本一例のサーバ装置１０は、セッション毎に異なるアドレスＣ１、Ｃ２（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。この場合、クライアント装置１１のアプリケーションＢ１、Ｂ２はそれぞれ異なるアドレスＣ２、Ｃ１を宛先アドレスとしてサービスＡ２、Ａ２にアクセスする。又、クライアント装置１１は、セッション毎（プログラムやクライアントユーザ毎）に異なるアドレスＤ１、Ｄ２（エフェメラルアドレス）を指定する。この場合、サーバ装置１０のサービスＡ１、Ａ２は、それぞれ異なるアドレスＤ２、Ｄ１を宛先アドレスとしてプログラムＢ２、Ｂ１にアクセスする。

タイプＡ−ＵＵにおけるサービスＡ１とアプリケーションＢ２とのセッションについて説明する。クライアント装置１１は、送信元ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、送信元アドレスとしてエフェメラルアドレス「Ｄ２」、宛先ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、宛先アドレスとして「Ｃ１」を指定したデータをサーバ装置１０に送信する。サーバ装置１０は、宛先ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、宛先ポートを利用せずに宛先アドレス「Ｃ１」のみでデータの宛先のサービスＡ１を特定する。又、サーバ装置１０は、送信元ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、送信元ポートを利用せずに送信元アドレス「Ｄ２」のみでデータの送信元のアプリケーションＢ２を特定する。一方、サーバ装置１０は、送信元ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、送信元アドレスとして「Ｃ１」、宛先ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、宛先アドレスとして「Ｄ２」を指定したデータをクライアント装置１１に送信する。クライアント装置１１は、宛先ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、宛先ポートを利用せずに宛先アドレス「Ｄ２」のみでデータの宛先のアプリケーションＢ２を特定する。又、クライアント装置１１は、送信元ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、送信元ポートを利用せずに送信元アドレス「Ｃ１」のみでデータの送信元のサービスＡ１を特定する。すなわち、タイプＡ−ＵＵにおいて、サービスＡ１とアプリケーションＢ２とのセッションは、図１０Ｂに示すように、宛先アドレス「Ｃ１」、送信元アドレス「Ｄ２」で特定される。同様に、タイプＡ−ＵＵにおいて、サービスＡ２とアプリケーションＢ１とのセッションは、図１０Ｂに示すように、宛先アドレス「Ｃ２」、送信元アドレス「Ｄ１」で特定される。

（タイプＢにおけるレガシー通信とユニファイド通信の共存）
図１１Ａ、図１２Ａ、図１３Ａ、図１４Ａは、タイプＢにおけるセッションの設定を、レガシー通信の階層構造と本発明の一実施例によるユニファイド通信の階層構造とを組み合わせて行う場合の一例を示す図である。図１１Ｂ、図１２Ｂ、図１３Ｂ、図１４Ｂは、図１１Ａ、図１２Ａ、図１３Ａ、図１４Ａに示すセッションを特定する情報を示す図である。

図１１Ａは、タイプＢにおいて、サーバ装置１０及びクライアント装置１２が共にレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＢ−ＬＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＢ−ＬＬは、レガシーの階層構造のサーバ装置１０が２つのサービスＡ３，Ａ４を提供し、レガシーの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）が２つのアプリケーションＢ３，Ｂ４からアクセスする場合を示す。

タイプＢ−ＬＬの場合、サービスＡ３とアプリケーションＢ４とのセッションは、図１１Ｂに示すように、宛先ポート「ａ２」、宛先アドレス「ｂ２」、送信元ポート「ｃ４」、送信元アドレス「ｄ２」で特定される。また、サービスＡ４とアプリケーションＢ３とのセッションは、図１１Ｂに示すように、宛先ポート「ａ３」、宛先アドレス「ｂ２」、送信元ポート「ｃ３」、送信元アドレス「ｄ２」で特定される。

図１２Ａは、タイプＡにおいて、サーバ装置１０がレガシー通信（第２通信モード）によってセッションを設定し、クライアント装置１２がユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＡ−ＬＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＢ−ＬＵは、レガシーの階層構造のサーバ装置１０が２つのサービスＡ３，Ａ４を提供し、ユニファイドの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）が２つのアプリケーションＢ３，Ｂ４からアクセスする場合を示す。

本一例のクライアント装置１１は、セッション毎（プログラムやクライアントユーザ毎）に異なるアドレスＤ３、Ｄ４（エフェメラルアドレス）を指定する。この場合、サーバ装置１０のサービスＡ３、Ａ４は、それぞれ異なるアドレスＤ４、Ｄ３を宛先アドレスとしてプログラムＢ４、Ｂ３にアクセスする。

タイプＢ−ＬＵにおけるサービスＡ３とアプリケーションＢ４とのセッションについて説明する。クライアント装置１２は、送信元ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、送信元アドレスとしてエフェメラルアドレス「Ｄ４」、宛先ポートとして「ａ２」、宛先アドレスとして「ｂ２」を指定したデータをサーバ装置１０に送信する。サーバ装置１０は、宛先ポート「ａ２」、宛先アドレス「ｂ２」を参照してデータの宛先のサービスＡ３を特定する。又、サーバ装置１０は、送信元ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、送信元ポートを利用せずに送信元アドレス「Ｄ３」のみでデータの送信元のアプリケーションＢ３を特定する。一方、サーバ装置１０は、送信元ポートとして「ａ２」、送信元アドレスとして「ｂ２」、宛先ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、宛先アドレスとして「Ｄ３」を指定したデータをクライアント装置１２に送信する。クライアント装置１２は、宛先ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、宛先ポートを利用せずに宛先アドレス「Ｄ３」のみでデータの宛先のアプリケーションＢ３を特定する。又、クライアント装置１２は、送信元ポート「ａ２」、送信元アドレス「ｂ２」を参照してデータの送信元のサービスＡ３を特定する。すなわち、タイプＢ−ＬＵにおいて、サービスＡ３とアプリケーションＢ４とのセッションは、図１２Ｂに示すように、宛先ポート「ａ２」、宛先アドレス「ｂ２」、送信元アドレス「Ｄ４」で特定される。同様に、タイプＢ−ＬＵにおいて、サービスＡ４とアプリケーションＢ３とのセッションは、図１２Ｂに示すように、宛先ポート「ａ３」、宛先アドレス「ｂ２」、送信元アドレス「Ｄ３」で特定される。

図１３Ａは、タイプＢにおいて、サーバ装置１０がユニファイド通信（第１通信モード）によってセッションを設定し、クライアント装置１２がレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＢ−ＵＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＢ−ＵＬは、ユニファイドの階層構造のサーバ装置１０が２つのサービスＡ３，Ａ４を提供し、レガシーの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）が２つのアプリケーションＢ３，Ｂ４からアクセスする場合を示す。尚、タイプＢ−ＬＵとタイプＢ−ＵＬは実質的に同じ形態である。

本一例のサーバ装置１０は、サービス毎（あるいはクライアントユーザ毎）に異なるアドレスＣ３、Ｃ４を指定する。

タイプＢ−ＵＬにおけるサービスＡ３とアプリケーションＢ４とのセッションについて説明する。クライアント装置１２は、送信元ポートとして「ｃ４」、送信元アドレスとして「ｄ２」、宛先ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、宛先アドレスとして「Ｃ３」を指定したデータをサーバ装置１０に送信する。サーバ装置１０は、宛先ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、宛先ポートを利用せずに宛先アドレス「Ｃ３」のみでデータの宛先のサービスＡ３を特定する。又、サーバ装置１０は、送信元ポート「ｃ４」、送信元アドレス「ｄ２」を参照して送信元のサービスＢ４を特定する。一方、サーバ装置１０は、送信元ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、送信元アドレスとして「Ｃ３」、宛先ポートとして「ｄ２」、宛先アドレスとして「ｃ４」を指定したデータをクライアント装置１２に送信する。クライアント装置１２は、宛先ポート「ｃ４」、宛先アドレス「ｄ２」を参照してデータの宛先のアプリケーションＢ４を特定する。又、クライアント装置１２は、送信元ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、送信元ポートを利用せずに送信元アドレス「Ｃ３」のみでデータの送信元のサービスＡ３を特定する。すなわち、タイプＢ−ＵＬにおいて、サービスＡ３とアプリケーションＢ４とのセッションは、図１３Ｂに示すように、宛先アドレス「Ｃ３」、送信元ポート「ｃ４」、送信元アドレス「ｄ２」で特定される。同様に、タイプＢ−ＵＬにおいて、サービスＡ４とアプリケーションＢ３とのセッションは、図１３Ｂに示すように、宛先アドレス「Ｃ４」、送信元ポート「ｃ３」、送信元アドレス「ｄ２」で特定される。

図１４Ａは、タイプＢにおいて、サーバ装置１０及びクライアント装置１２が共にユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＢ−ＵＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＢ−ＵＵは、ユニファイドの階層構造のサーバ装置１０が２つのサービスＡ３，Ａ４を提供し、ユニファイドの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）が２つのアプリケーションＢ３，Ｂ４からアクセスする場合を示している。

本一例のサーバ装置１０は、サービス毎（あるいはクライアントユーザ毎）に異なるアドレスＣ５、Ｃ６を指定する。又、クライアント装置１２は、セッション毎（プログラムやクライアントユーザ毎）に異なるアドレスＤ３、Ｄ４（エフェメレラルアドレス）を指定する。

タイプＢ−ＵＵにおけるサービスＡ３とアプリケーションＢ４とのセッションについて説明する。クライアント装置１２は、送信元ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、送信元アドレスとしてエフェメラルアドレス「Ｄ４」、宛先ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、宛先アドレスとして「Ｃ３」を指定したデータをサーバ装置１０に送信する。サーバ装置１０は、宛先ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、宛先ポートを利用せずに宛先アドレス「Ｃ３」のみでデータの宛先のサービスＡ３を特定する。又、サーバ装置１０は、送信元ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、送信元ポートを利用せずに送信元アドレス「Ｄ４」のみでデータの送信元のアプリケーションＢ４を特定する。一方、サーバ装置１０は、送信元ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、送信元アドレスとして「Ｃ３」、宛先ポートとして「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、宛先アドレスとして「Ｄ４」を指定したデータをクライアント装置１２に送信する。クライアント装置１２は、宛先ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、宛先ポートを利用せずに宛先アドレス「Ｄ４」のみでデータの宛先のアプリケーションＢ４を特定する。又、クライアント装置１１は、送信元ポートに「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」が指定されているため、送信元ポートを利用せずに送信元アドレス「Ｃ３」のみでデータの送信元のサービスＡ３を特定する。すなわち、サービスＡ３とアプリケーションＢ４とのセッションは、図１４Ｂに示すように、宛先アドレス「Ｃ３」、送信元アドレス「Ｄ４」で特定される。同様に、タイプＢ−ＵＵにおいて、サービスＡ４とアプリケーションＢ３とのセッションは、図１４Ｂに示すように、宛先アドレス「Ｃ４」、送信元アドレス「Ｄ３」で特定される。

（タイプＣにおけるレガシー通信とユニファイド通信の共存）
図１５Ａ〜図２２Ａは、タイプＣにおけるセッションの設定を、レガシー通信の階層構造と本発明の一実施例によるユニファイド通信の階層構造とを組み合わせて行う場合の一例を示す図である。図１５Ｂ〜図２２Ｂは、図１５Ａ〜図２２Ａに示すセッションを特定する情報を示す図である。

タイプＣは、タイプＡと同様に、サーバ装置１０が提供する１つのサービスが、複数（少なくとも１つ）のアプリケーションからアクセスされる形態である。このため、タイプＣにおけるサーバ装置１０とクライアント装置１１、１２のそれぞれとのセッションの設定動作は、タイプＡと同様である。以下ではタイプＣにおけるセッションを特定する要素のみをタイプ別で説明する。

図１５Ａは、タイプＣにおいて、サーバ装置１０及びクライアント装置１１１、１２の全てがレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＣ−ＬＬＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＣ−ＬＬＬは、レガシーの階層構造のサーバ装置が１つのサービスＡ５，Ａ６を提供し、レガシーの階層構造のクライアント装置１１、１２（Ｃｌｉｅｎｔ １１，Ｃｌｉｅｎｔ １２）各々が１つのアプリケーションＢ５，Ｂ６からアクセスする場合を示す。

タイプＣ−ＬＬＬの場合、サービスＡ５とアプリケーションＢ６とのセッションは、図１５Ｂに示すように、宛先ポート「ａ４」、宛先アドレス「ｂ３」、送信元ポート「ｃ６」、送信元アドレス「ｄ４」で特定される。また、サービスＡ６とアプリケーションＢ５とのセッションは、図１５Ｂに示すように、宛先ポート「ａ４」、宛先アドレス「ｂ３」、送信元ポート「ｃ５」、送信元アドレス「ｄ３」で特定される。

図１６Ａは、タイプＣにおいて、サーバ装置１０がレガシー通信（第２通信モード）によってセッションを設定し、クライアント装置１１、１２が共にユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＣ−ＬＵＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＣ−ＬＵＵは、レガシーの階層構造のサーバ装置１０が１つのサービスＡ５，Ａ６を提供し、ユニファイドの階層構造のクライアント装置１１、１２（Ｃｌｉｅｎｔ １１，Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ５，Ｂ６からアクセスする場合を示す。

タイプＣ−ＬＵＵの場合、サービスＡ５とアプリケーションＢ６とのセッションは、図１６Ｂに示すように、宛先ポート「ａ４」、宛先アドレス「ｂ３」、送信元アドレス「Ｄ６」で特定される。また、サービスＡ６とアプリケーションＢ５とのセッションは、図１６Ｂに示すように、宛先ポート「ａ４」、宛先アドレス「ｂ３」、送信元アドレス「Ｄ５」で特定される。

図１７Ａは、タイプＣにおいて、サーバ装置１０がユニファイド通信（第１通信モード）によってセッションを設定し、クライアント装置１１、１２が共にレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＣ−ＵＬＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＣ−ＵＬＬは、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ５，Ａ６を提供し、レガシーの階層構造のクライアント装置１１、１２（Ｃｌｉｅｎｔ １，Ｃｌｉｅｎｔ ２）の各々が１つのアプリケーションＢ５，Ｂ６からアクセスする場合を示す。

本一例のサーバ装置１０は、セッション毎に異なるアドレスＣ５、Ｃ６（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。この場合、クライアント装置１１のアプリケーションＢ５、クライアント装置１２のＢ６は、それぞれ異なるアドレスＣ５、Ｃ６を宛先アドレスとしてアクセスする。

タイプＣ−ＵＬＬの場合、サービスＡ５とアプリケーションＢ６とのセッションは、図１７Ｂに示すように、宛先アドレス「Ｃ５」、送信元ポート「ｃ６」、送信元アドレス「ｄ４」で特定される。また、サービスＡ６とアプリケーションＢ５とのセッションは、図１７Ｂに示すように、宛先アドレス「Ｃ６」、送信元ポート「ｃ５」、送信元アドレス「ｄ３」で特定される。

図１８Ａは、タイプＣにおいて、サーバ装置１０及びクライアント装置１１、１２が全てユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＣ−ＵＵＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＣ−ＵＵＵは、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ５，Ａ６を提供し、ユニファイドの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１，Ｃｌｉｅｎｔ １２）各々が１つのアプリケーションＢ５，Ｂ６からアクセスする場合を示す。

本一例のサーバ装置１０は、セッション毎に異なるアドレスＣ５、Ｃ６（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。この場合、クライアント装置１１のアプリケーションＢ５、クライアント装置１２のＢ６は、それぞれ異なるアドレスＣ６、Ｃ５を宛先アドレスとしてサービスＡ６、Ａ５にアクセスする。

タイプＣ−ＵＵＵの場合、サービスＡ５とアプリケーションＢ６とのセッションは、図１８Ｂに示すように、宛先アドレス「Ｃ５」、送信元アドレス「Ｄ６」で特定される。また、サービスＡ６とアプリケーションＢ５とのセッションは、図１８Ｂに示すように、宛先アドレス「Ｃ６」、送信元アドレス「Ｄ５」で特定される。

図１９Ａは、タイプＣにおいて、サーバ装置１０とクライアント装置１１がレガシー通信（第２通信モード）によってセッションを設定し、クライアント装置１２がユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＣ−ＬＬＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＣ−ＬＬＵは、レガシーの階層構造のサーバ装置１０が１つのサービスＡ５，Ａ６を提供し、レガシーの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）及びユニファイドの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ５，Ｂ６からアクセスする場合を示す。

タイプＣ−ＬＬＵの場合、サービスＡ５とアプリケーションＢ６とのセッションは、図１９Ｂに示すように、宛先ポート「ａ４」、宛先アドレス「ｂ３」、送信元アドレス「Ｄ６」で特定される。また、サービスＡ６とアプリケーションＢ５とのセッションは、図１９Ｂに示すように、宛先ポート「ａ４」、宛先アドレス「ｂ３」、送信元ポート「ｃ５」、送信元アドレス「ｄ３」で特定される。

図２０Ａは、タイプＣにおいて、サーバ装置１０とクライアント装置１２がレガシー通信（第２通信モード）によってセッションを設定し、クライアント装置１１がユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＣ−ＬＵＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＣ−ＬＵＬは、レガシーの階層構造のサーバ装置１０が１つのサービスＡ５，Ａ６を提供し、ユニファイドの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）及びレガシーの階層構造のクライアント装置（Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ５，Ｂ６からアクセスする場合を示している。尚、タイプＣ−ＬＬＵとタイプＣ−ＬＵＬは実質的に同じ形態である。

タイプＣ−ＬＵＬの場合、サービスＡ５とアプリケーションＢ６とのセッションは、図２０Ｂに示すように、宛先ポート「ａ４」、宛先アドレス「ｂ３」、送信元ポート「ｃ６」、送信元アドレス「ｄ４」で特定される。また、サービスＡ６とアプリケーションＢ５とのセッションは、図２０Ｂに示すように、宛先ポート「ａ４」、宛先アドレス「ｂ３」、送信元アドレス「Ｄ５」で特定される。

図２１Ａは、タイプＣにおいて、サーバ装置１０とクライアント装置１２がユニファイド通信（第１通信モード）によってセッションを設定し、クライアント装置１１がレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＣ−ＵＬＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＣ−ＵＬＵは、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ５，Ａ６を提供し、レガシーの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）及びユニファイドの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ５，Ｂ６からアクセスする場合を示す。

本一例のサーバ装置１０は、セッション毎に異なるアドレスＣ５、Ｃ６（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。この場合、クライアント装置１１のアプリケーションＢ５、クライアント装置１２のＢ６は、それぞれ異なるアドレスＣ６、Ｃ５を宛先アドレスとしてサービスＡ６、Ａ５にアクセスする。

タイプＣ−ＵＬＵの場合、サービスＡ５とアプリケーションＢ６とのセッションは、図２１Ａに示すように、宛先アドレス「Ｃ５」、送信元アドレス「Ｄ６」で特定される。また、サービスＡ６とアプリケーションＢ５とのセッションは、図２１Ｂに示すように、宛先アドレス「Ｃ６」、送信元ポート「ｃ５」、送信元アドレス「ｄ３」で特定される。

図２２Ａは、タイプＣにおいて、サーバ装置１０とクライアント装置１１がユニファイド通信（第１通信モード）によってセッションを設定し、クライアント装置１２がレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＣ−ＵＵＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＣ−ＵＵＬは、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ５，Ａ６を提供し、ユニファイドの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）及びレガシーの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ５，Ｂ６からアクセスする場合を示している。尚、タイプＣ−ＵＬＵとタイプＣ−ＵＵＬは実質的に同じ形態である。

タイプＣ−ＵＵＬの場合、サービスＡ５とアプリケーションＢ６とのセッションは、図２２Ｂに示すように、宛先アドレス「Ｃ５」、送信元ポート「ｃ６」、送信元アドレス「ｄ４」で特定される。また、サービスＡ６とアプリケーションＢ５とのセッションは、図２２Ｂに示すように、宛先アドレス「Ｃ６」、送信元アドレス「Ｄ５」で特定される。

（タイプＤにおけるレガシー通信とユニファイド通信の共存）
図２３Ａ〜図３０Ａは、タイプＣにおけるセッションの設定を、レガシー通信の階層構造と本発明の一実施例によるユニファイド通信の階層構造とを組み合わせて行う場合の一例を示す図である。図２３Ｂ〜図３０Ｂは、図１５Ａ〜図２２Ａに示すセッションを特定する情報を示す図である。

タイプＤは、タイプＢと同様に、サーバ装置１０が提供する複数（ここでは一例として２つ）のサービスが、複数（少なくとも１つ）のアプリケーションからアクセスされる形態である。このため、タイプＤにおけるサーバ装置１０とクライアント装置１１、１２のそれぞれとのセッションの設定動作は、タイプＢと同様である。以下ではタイプＤにおけるセッションを特定する要素のみをタイプ別で説明する。

図２３Ａは、タイプＤにおいて、サーバ装置１０及びクライアント装置１１１、１２の全てがレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＤ−ＬＬＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＤ−ＬＬＬは、レガシーの階層構造のサーバ装置１０が２つのサービスＡ７，Ａ８を提供し、レガシーの階層構造のクライアント装置１１、１２（Ｃｌｉｅｎｔ １１，Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ７，Ｂ８からアクセスする場合を示す。

タイプＤ−ＬＬＬの場合、サービスＡ７とアプリケーションＢ８とのセッションは、図２３Ｂに示すように、宛先ポート「ａ５」、宛先アドレス「ｂ４」、送信元ポート「ｃ８」、送信元アドレス「ｄ６」で特定される。また、サービスＡ８とアプリケーションＢ７とのセッションは、図２３Ｂに示すように、宛先ポート「ａ６」、宛先アドレス「ｂ４」、送信元ポート「ｃ７」、送信元アドレス「ｄ５」で特定される。

図２４Ａは、タイプＤにおいて、サーバ装置１０がレガシー通信（第２通信モード）によってセッションを設定し、クライアント装置１１、１２が共にユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＤ−ＬＵＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＤ−ＬＵＵは、レガシーの階層構造のサーバ装置１０が２つのサービスＡ７，Ａ８を提供し、ユニファイドの階層構造のクライアント装置１１、１２（Ｃｌｉｅｎｔ １，Ｃｌｉｅｎｔ ２）の各々が１つのアプリケーションＢ７，Ｂ８からアクセスする場合を示している。

タイプＤ−ＬＵＵの場合、サービスＡ７とアプリケーションＢ８とのセッションは、図２４Ｂに示すように、宛先ポート「ａ５」、宛先アドレス「ｂ４」、送信元アドレス「Ｄ８」で特定される。また、サービスＡ８とアプリケーションＢ７とのセッションは、図２４Ｂに示すように、宛先ポート「ａ６」、宛先アドレス「ｂ４」、送信元アドレス「Ｄ７」で特定される。

図２５Ａは、タイプＤにおいて、サーバ装置１０がユニファイド通信（第１通信モード）によってセッションを設定し、クライアント装置１１、１２が共にレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＤ−ＵＬＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＤ−ＵＬＬは、ユニファイドの階層構造のサーバ装置１０が２つのサービスＡ７，Ａ８を提供し、レガシーの階層構造のクライアント装置１１、１２（Ｃｌｉｅｎｔ １１，Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ７，Ｂ８からアクセスする場合を示す。

本一例のサーバ装置１０は、サービス毎（あるいはクライアントユーザ毎）に異なるアドレスＣ７、Ｃ８を指定する。

タイプＤ−ＵＬＬの場合、サービスＡ７とアプリケーションＢ８とのセッションは、図２５Ｂに示すように、宛先アドレス「Ｃ７」、送信元ポート「ｃ８」、送信元アドレス「ｄ６」で特定される。また、サービスＡ８とアプリケーションＢ７とのセッションは、図２５Ｂに示すように、宛先アドレス「Ｃ８」、送信元ポート「ｃ７」、送信元アドレス「ｄ５」で特定される。

図２６Ａは、タイプＤにおいて、サーバ装置１０及びクライアント装置１１、１２が全てユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＤ−ＵＵＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＤ−ＵＵＵは、ユニファイドの階層構造のサーバ装置１０が２つのサービスＡ７，Ａ８を提供し、ユニファイドの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１，Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ７，Ｂ８からアクセスする場合を示している。

本一例のサーバ装置１０は、サービス毎（あるいはクライアントユーザ毎）に異なるアドレスＣ３、Ｃ４を指定する。

タイプＤ−ＵＵＵの場合、サービスＡ７とアプリケーションＢ８とのセッションは、図２６Ｂに示すように、宛先アドレス「Ｃ７」、送信元アドレス「Ｄ８」で特定される。また、サービスＡ８とアプリケーションＢ７とのセッションは、図２６Ｂに示すように、宛先アドレス「Ｃ８」、送信元アドレス「Ｄ７」で特定される。

図２７Ａは、タイプＤにおいて、サーバ装置１０とクライアント装置１１がレガシー通信（第２通信モード）によってセッションを設定し、クライアント装置１２がユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＤ−ＬＬＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＤ−ＬＬＵは、レガシーの階層構造のサーバ装置１０が２つのサービスＡ７，Ａ８を提供し、レガシーの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）及びユニファイドの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ７，Ｂ８からアクセスする場合を示す。

タイプＤ−ＬＬＵの場合、サービスＡ７とアプリケーションＢ８とのセッションは、図２７Ｂに示すように、宛先ポート「ａ５」、宛先アドレス「ｂ４」、送信元アドレス「Ｄ８」で特定される。また、サービスＡ８とアプリケーションＢ７とのセッションは、図２７Ｂに示すように、宛先ポート「ａ６」、宛先アドレス「ｂ４」、送信元ポート「ｃ７」、送信元アドレス「ｄ５」で特定される。

図２８Ａは、タイプＤにおいて、サーバ装置１０とクライアント装置１２がレガシー通信（第２通信モード）によってセッションを設定し、クライアント装置１１がユニファイド通信（第１通信モード）によってセッションを設定する場合（タイプＤ−ＬＵＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＤ−ＬＵＬは、レガシーの階層構造のサーバ装置１０が２つのサービスＡ７，Ａ８を提供し、ユニファイドの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）及びレガシーの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ７，Ｂ８からアクセスする場合を示す。尚、タイプＤ−ＬＬＵとタイプＤ−ＬＵＬは実質的に同じ形態である。

タイプＤ−ＬＵＬの場合、サービスＡ７とアプリケーションＢ８とのセッションは、図２８Ｂに示すように、宛先ポート「ａ５」、宛先アドレス「ｂ４」、送信元ポート「ｃ８」、送信元アドレス「ｄ６」で特定される。また、サービスＡ８とアプリケーションＢ７とのセッションは、図２８Ｂに示すように、宛先ポート「ａ６」、宛先アドレス「ｂ４」、送信元アドレス「Ｄ７」で特定される。

図２９Ａは、タイプＤにおいて、サーバ装置１０とクライアント装置１２がユニファイド通信（第１通信モード）によってセッションを設定し、クライアント装置１１がレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＤ−ＵＬＵ）のセッション及び階層構造を示す模式図である。すなわち、タイプＤ−ＵＬＵは、ユニファイドの階層構造のサーバ装置１０が２つのサービスＡ７，Ａ８を提供し、レガシーの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）及びユニファイドの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）各々が１つのアプリケーションＢ７，Ｂ８からアクセスする場合を示す。

本一例のサーバ装置１０は、サービス毎（あるいはクライアントユーザ毎）に異なるアドレスＣ７、Ｃ８を指定する。

タイプＤ−ＵＬＵの場合、サービスＡ７とアプリケーションＢ８とのセッションは、図２９Ｂに示すように、宛先アドレス「Ｃ７」、送信元アドレス「Ｄ８」で特定される。また、サービスＡ８とアプリケーションＢ７とのセッションは、図２９Ｂに示すように、宛先アドレス「Ｃ８」、送信元ポート「ｃ７」、送信元アドレス「ｄ５」で特定される。

図３０Ａは、タイプＤにおいて、サーバ装置１０とクライアント装置１１がユニファイド通信（第１通信モード）によってセッションを設定し、クライアント装置１２がレガシー通信（第２通信モード）によってセッションを設定する場合（タイプＤ−ＵＵＬ）のセッション及び階層構造を示す模式図である。すなわち、タイプＤ−ＵＵＬは、ユニファイドの階層構造のサーバ装置１０が２つのサービスＡ７，Ａ８を提供し、ユニファイドの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）及びレガシーの階層構造のクライアント装置（Ｃｌｉｅｎｔ １２）各々が１つのアプリケーションＢ７，Ｂ８からアクセスする場合を示している。尚、タイプＤ−ＵＬＵとタイプＤ−ＵＵＬは実質的に同じ形態である。

タイプＤ−ＵＵＬの場合、サービスＡ７とアプリケーションＢ８とのセッションは、図３０Ｂに示すように、宛先アドレス「Ｃ７」、送信元ポート「ｃ８」、送信元アドレス「ｄ６」で特定される。また、サービスＡ７とアプリケーションＢ７とのセッションは、図３０Ｂに示すように、宛先アドレス「Ｃ７」、送信元アドレス「Ｄ７」で特定される。

（タイプＡにおけるレガシー通信とユニファイド通信の共存に関する他の一例）
図３１Ａは、タイプＡにおけるセッションの設定を、レガシー通信の階層構造と本発明の一実施例によるユニファイド通信の階層構造とを組み合わせて行う場合の他の一例を示す図である。図３１Ｂ、図３２Ｂは、図３１Ａ、図３２Ａに示すセッションを特定する情報を示す図である。

図３１Ａにおいて、タイプＡ−Ｕ’Ｌは、図９Ａに示す形態と同様に、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ９，Ａ１０を提供し、レガシーの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）が２つのアプリケーションＢ９，Ｂ１０からアクセスする場合を示す。図９Ａに示したサーバ装置１０は、セッション毎に異なるアドレス（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。一方、図３１Ａに示すサーバ装置１０は、全てのセッションに対し同一のアドレス（Ｇｅｎｅｒｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。この場合、クライアント装置１１のアプリケーションＢ９、Ｂ１０はそれぞれ同じアドレスＣ９を宛先アドレスとしてサービスＡ９、Ａ１０にアクセスする。

タイプＡ−Ｕ’Ｌの場合、サービスＡ９とアプリケーションＢ１０とのセッションは、図３１Ｂに示すように、宛先アドレス「Ｃ９」、送信元ポート「ｃ１０」、送信元アドレス「ｄ７」で特定される。また、サービスＡ１０とアプリケーションＢ９とのセッションは、図３１Ｂに示すように、宛先アドレス「Ｃ９」、送信元ポート「ｃ９」、送信元アドレス「ｄ７」で特定される。

図３２Ａにおいて、タイプＡ−Ｕ’Ｕは、図１０Ａに示す形態と同様に、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ９，Ａ１０を提供し、ユニファイドの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）が２つのアプリケーションＢ９，Ｂ１０からアクセスする場合を示す。図１０Ａに示したサーバ装置１０は、セッション毎に異なるアドレス（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。一方、図３２Ａに示すサーバ装置１０は、全てのセッションに対し同一のアドレス（Ｇｅｎｅｒｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。この場合、クライアント装置１１のアプリケーションＢ９、Ｂ１０はそれぞれ同じアドレスＣ９を宛先アドレスとしてサービスＡ９、Ａ１０にアクセスする。

タイプＡ−Ｕ’Ｕの場合、サービスＡ９とアプリケーションＢ１０とのセッションは、図３２Ｂに示すように、宛先アドレス「Ｃ９」、送信元ポート「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」、送信元アドレス「Ｄ１０」で特定される。また、サービスＡ１０とアプリケーションＢ９とのセッションは、図３２Ｂに示すように、宛先アドレス「Ｃ１０」、送信元アドレス「Ｄ９」で特定される。

（タイプＣにおけるレガシー通信とユニファイド通信の共存に関する他の一例）
図３３Ａ、図３４Ａは、タイプＣにおけるセッションの設定を、レガシー通信の階層構造と本発明の一実施例によるユニファイド通信の階層構造とを組み合わせて行う場合の他の一例を示す図である。図３３Ｂ、図３４Ｂは、図３３Ａ、図３４Ａに示すセッションを特定する情報を示す図である。

図３３Ａにおいて、タイプＣ−Ｕ’ＬＬは、図１７Ａに示す形態と同様に、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ１１，Ａ１２を提供し、レガシーの階層構造のクライアント装置１１、１２（Ｃｌｉｅｎｔ １１，Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ１１，Ｂ１２からアクセスする場合を示す。図１７Ａに示したサーバ装置１０は、セッション毎に異なるアドレス（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。一方、図３３Ａに示すサーバ装置１０は、全てのセッションに対し同一のアドレス（Ｇｅｎｅｒｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。この場合、クライアント装置１１のアプリケーションＢ１１、Ｂ１２はそれぞれ同じアドレスＣ１０を宛先アドレスとしてサービスＡ９、Ａ１０にアクセスする。

タイプＣ−Ｕ’ＬＬの場合、サービスＡ１１とアプリケーションＢ１２とのセッションは、図３３Ｂに示すように、宛先アドレス「Ｃ１０」、送信元ポート「ｃ１２」、送信元アドレス「ｄ９」で特定される。また、サービスＡ１２とアプリケーションＢ１１とのセッションは、図３３Ｂに示すように、宛先アドレス「Ｃ１０」、送信元ポート「ｃ１１」、送信元アドレス「ｄ８」で特定される。

図３３Ａにおいて、タイプＣ−Ｕ’ＵＵは、図１８Ａに示す形態と同様に、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ１１，Ａ１２を提供し、ユニファイドの階層構造のクライアント装置１１、１２（Ｃｌｉｅｎｔ １１，Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ１１，Ｂ１２からアクセスする場合を示す。図１８Ａに示したサーバ装置１０は、セッション毎に異なるアドレス（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。一方、図３３Ａに示すサーバ装置１０は、全てのセッションに対し同一のアドレス（Ｇｅｎｅｒｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。この場合、クライアント装置１１のアプリケーションＢ１１、クライアント装置１２のアプリケーションＢ１２はそれぞれ同じアドレスＣ１０を宛先アドレスとしてサービスＡ１１、Ａ１２にアクセスする。

タイプＣ−Ｕ’ＵＵの場合、サービスＡ１１とアプリケーションＢ１２とのセッションは、図３４Ｂに示すように、宛先アドレス「Ｃ１０」、送信元アドレス「Ｄ１２」で特定される。また、サービスＡ１２とアプリケーションＢ１１とのセッションは、図３４Ｂに示すように、宛先アドレス「Ｃ１０」、送信元アドレス「Ｄ１１」で特定される。

図３５Ａにおいて、タイプＣ−Ｕ’ＬＵは、図２１Ａに示す形態と同様に、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ１１，Ａ１２を提供し、レガシーの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）及びユニファイドの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ１１，Ｂ１２からアクセスする場合を示す。図２１Ａに示したサーバ装置１０は、セッション毎に異なるアドレス（Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。一方、図３５Ａに示すサーバ装置１０は、全てのセッションに対し同一のアドレス（Ｇｅｎｅｒｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ）を指定する。この場合、クライアント装置１１のアプリケーションＢ１１、クライアント装置１２のアプリケーションＢ１２はそれぞれ同じアドレスＣ１０を宛先アドレスとしてサービスＡ１１、Ａ１２にアクセスする。

タイプＣ−Ｕ’ＬＵの場合、サービスＡ１１とアプリケーションＢ１２とのセッションは、図３５Ｂに示すように、宛先アドレス「Ｃ１０」、送信元アドレス「Ｄ１２」で特定される。また、サービスＡ１２とアプリケーションＢ１１とのセッションは、図３５Ｂに示すように、宛先アドレス「Ｃ１０」、送信元ポート「ｃ１１」、送信元アドレス「ｄ８」で特定される。

図３６Ａにおいて、タイプＣ−Ｕ’ＵＬは、図２２Ａに示す形態と同様に、ユニファイドの階層構造のサーバ装置１０が１つのサービスＡ１１，Ａ１２を提供し、ユニファイドの階層構造のクライアント装置１１（Ｃｌｉｅｎｔ １１）及びレガシーの階層構造のクライアント装置１２（Ｃｌｉｅｎｔ １２）の各々が１つのアプリケーションＢ１１，Ｂ１２からアクセスする場合を示す。尚、タイプＣ−Ｕ’ＬＵとタイプＣ−Ｕ’ＵＬは実質的に同じ形態である。

タイプＣ−Ｕ’ＵＬの場合、サービスＡ５とアプリケーションＢ６とのセッションは、図３６Ｂに示すように、宛先アドレス「Ｃ１０」、送信元ポート「ｃ１２」、送信元アドレス「ｄ９」で特定される。また、サービスＡ１２とアプリケーションＢ１１とのセッションは、図３６Ｂに示すように、宛先アドレス「Ｃ１０」、送信元アドレス「Ｄ１１」で特定される。

（効果）
このように、サーバ装置１０及びクライアント装置１１、１２をそれぞれユニファイドの階層構造とすることで、サーバ装置が提供するサービスとクライアント装置のアプリケーションとの間のセョションは、実質的にアドレスのみで特定（識別）されることとなる。このため、トランスポート層の情報を解析する必要がなく、フィルタやＩＰｓｅｃ ＳＰＤの実装・運用等を容易化（シンプル化）することができる。従って、本発明によれば従来技術で生じたポート情報の問題を解決することができる。また、本実施例では、ウェルノウンポート番号を使用する必要がなくなるため、プライバシーを中心とした高いセキュリティ機能を提供することができる。

特定の通信相手という条件のついたサービスを示すアドレス［（Ｃｌｉｅｎｔ） Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ］、通信相手を特定せずにサービスを代表するアドレス［Ｇｅｎｅｒｉｃ Ｓｅｒｖｉｃｅ Ａｄｄｒｅｓｓ］の場合も考えられるが、その場合のセッションも、上述したタイプＡ及びタイプＣと同様に、本発明の一実施例によるユニファイドの階層構造を用いることができる。

また、上述したように、本発明の一実施例によるユニファイドの階層構造を用いるユニファイド通信と、従来のレガシーの階層構造を用いるレガシー通信とが混在して通信が行われる場合には、ユニファイド通信のポート情報の「ＬＥＧＡＣＹ＿ＣＯＭＰＡＴ」は固定であるため、レガシー通信の「アドレス情報」＋「ポート情報」とユニファイド通信の「アドレス情報」との３つの情報で済むこととなる。さらに、ユニファイド通信のみで通信が行われる場合には、宛先及び送信元（発信元）のユニファイド通信の「アドレス情報」のみの２つの情報で済むこととなる。

したがって、本発明では、セッションの識別が単一層の情報に閉じ、必要最低限な情報だけで、単純な情報管理を実現し、機能実装を効率的にすることができる。すなわち、本発明によれば、セッションの多重化とセッションの識別の効率を向上させることができる。これにより、中間ノードの実装・運用を容易化するセッションを多重化する際に、フィルタやＩＰｓｅｃ ＳＰＤの実装・運用等を容易化することができる。また、本発明では、ウェルノウンに頼った仕組みを用いることなく、必要な情報がｒｅｓｏｌｖｉｎｇによって取得することができ、セキュリティ／プライバシーに配慮することができる。さらに、本発明では、サービスの本質を代表するものがセッションの識別情報として採用される。

尚、本発明は、ユニキャスト（Ｕｎｉｃａｓｔ）通信だけでなく、エニイキャスト（Ａｎｙｃａｓｔ）通信／マルチキャスト（Ｍｕｌｔｉｃａｓｔ）通信でも利用することができ、ＴＣＰ／ＵＤＰ通信のみならず、ＩＣＭＰ通信にも対応可能である。

つまり、これまでの説明ではポート情報を伴うＴＣＰ／ＵＤＰの通信を対象としているが、ポート情報を持たないＩＣＭＰ通信の場合についても本発明を適用することができる。ＩＣＭＰにはポート情報がなく、従来の通常の発想では基本的に多重化することができないと考えられてきている。しかしながら、本発明を適用することで、サービスがＩＰアドレス情報を通して示されたものであるならば、適切なサービス指向な通信も可能であるし、同時に多重化された通信も可能となる。

本発明による通信システムは、インタネットプロトコルのトランスポート層及びネットワーク層を含むノード装置からなる通信システムである。ノード装置は、トランスポート層及びネットワーク層におけるセッションの識別を前記ネットワーク層におけるセッションの識別に統合して行う。

又、本発明によるノード装置は、トランスポート層及びネットワーク層にて行うセッションの多重化をネットワーク層における多重化に統合した統合多重化処理を実行することが好ましい。

更に、本発明によるノード装置は、セッション毎に、トランスポート層にて扱うポート番号に対応する情報を含むＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを割り当てることが好ましい。

又、本発明によるノード装置は、他のノード装置への通信においてＩＰアドレスと統合多重化処理によることを示すポート番号情報とを送信することが好ましい。

本発明によるノード装置は、重複アドレス検出済みのＩＰアドレスを記憶装置に複数蓄積し、その蓄積されたＩＰアドレスの中から選択して前記統合多重化処理にて使用することが好ましい。

すなわち、本発明の通信システムは、トランスポート層及びネットワーク層におけるセッション（ｓｅｓｓｉｏｎ）の識別をネットワーク層における識別に統合する。又、本発明の通信システムではセッション毎にＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを各ノード装置に割り当てることで、セッションを多重化（ｍｕｌｔｉｐｌｅｘ）する際に、フィルタ（Ｆｉｌｔｅｒ）やＩＰｓｅｃ ＳＰＤ（ＩＰセキュリティ・ポリシー・データベース）の実装・運用等を容易化し、従来のポート番号情報の問題を解決している。このセッションの識別がネットワーク層における識別に統合されることで、トランスポート層及びネットワーク層におけるセッションの多重化もネットワーク層における多重化に統合することが可能となる。

本発明の通信システムでは、サービスとアプリケーションとの間、あるいはアプリケーション間のセッションの多重化をネットワーク層における多重化に統合することで、ＩＰパケットのルーティグ（ｒｏｕｔｉｎｇ）やルータ（ｒｏｕｔｅｒ）に対して影響を与えることなく実現することが可能となる。この場合、ネットワーク層の多重化技術（ルーティングテーブルを引く等）の方がトランスポート層の多重化技術より優れている。

また、本発明の通信システムでは、トランスポート層及びネットワーク層の２箇所で行うセッションの多重化処理をネットワーク層の１箇所に統合するので、新たな処理が必要となることはない。但し、本発明の通信システムでは、セッション毎にＩＰアドレスを割り当てているので、インタネットプロトコルとしてはアドレス空間の広いＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ）が適している。

以上、本発明の実施の形態を詳述してきたが、具体的な構成は上記実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。

Claims (16)

1. 複数のノード装置を具備し、
   前記複数のノード装置の各々は、他のノード装置との間で送受信するデータのアドレスフィールド内の情報に基づいて、前記データを処理するためのアプリケーションを決定し、
   前記各ノード装置は、前記データのアドレスフィールド内の情報に基づいて前記アプリケーションを決定する第１通信モードと、前記データのポートフィールド内の情報に基づいて前記アプリケーションを決定する第２通信モードとを有し、
   前記各ノード装置は、前記ポートフィールド内の情報が所定の値を示す時、前記第１通信モードで前記アプリケーションを決定する
   通信システム。
2. 請求項１に記載の通信システムにおいて、
   前記各ノード装置は、セッション毎に異なるＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを用いてセッションを多重化する
   通信システム。
3. 請求項１又は２に記載の通信システムにおいて、
   前記アドレスフィールド内の情報は、前記アプリケーションを決定する情報を含むＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスである
   通信システム。
4. 請求項１から３のいずれか１項に記載の通信システムにおいて、
   受信したデータのポートフィールド内の情報に基づいて前記データを処理するためのアプリケーションを決定する従来ノード装置を更に備え、
   前記各ノードは、前記従来ノード装置との間でデータを送受信する場合、前記第２通信モードで前記アプリケーションを決定する
   通信システム。
5. 請求項１から４のいずれか１項に記載の通信システムにおいて、
   前記複数のノード装置は、サービスを提供するサーバ装置と、クライアント装置とを備え、
   前記クライアント装置は、自身のＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）によって割り振られたエフェメラルアドレスをソースアドレスとして用いて前記サービスへのセッションを確立し、前記セッションが終了すると前記エフェメラルアドレスを破棄する
   通信システム。
6. 請求項１から４のいずれか１項に記載の通信システムにおいて、
   前記複数のノード装置は、サービスを提供するサーバ装置と、クライアント装置とを備え、
   前記サーバ装置は、通信相手として許可したクライアント装置に対応するアドレスを、
   前記サービスを識別するＳｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅアドレスとして払出し、
   前記許可されたクライアント端末は、前記Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅアドレスを用いて前記サービスへのセッションを確立する
   通信システム。
7. 請求項１から６のいずれか１項に記載の通信システムにおいて、
   前記各ノード装置は、重複アドレス検出済みのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを複数蓄積し、前記蓄積されたＩＰアドレスの中から選択したＩＰアドレスを用いて、前記アプリケーションとのセッションを確立する
   通信システム。
8. 他ノード装置から送信されたデータのアドレスフィールド内の情報に基づいて、前記受信したデータを処理するためのアプリケーションを決定するセッションユニットと、
   前記セッションユニットによって決定されたプログラムを実行することで前記データを処理するアプリケーションユニットと、
   を具備し、
   前記セッションユニットは、
   受信したデータのアドレスフィールド内の情報に基づいて前記アプリケーションを決定する第１通信モードと、
   受信したデータのポートフィールド内の情報に基づいて前記アプリケーションを決定する第２通信モードと、
   を有し、
   前記セッションユニットは、前記ポートフィールド内の情報が所定の値を示す時、前記第１通信モードで前記データを処理するためのアプリケーションを決定する
   ノード装置。
9. 請求項８に記載のノード装置において、
   前記セッションユニットは、セッション毎に異なるＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを用いて、他ノード装置とのセッションを多重化する
   ノード装置。
10. 請求項８又は９に記載のノード装置において、
    前記アドレスフィールド内の情報は、アプリケーションを決定するための情報を含むＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスである
    ノード装置。
11. 請求項８から１０のいずれか１項に記載のノード装置において、
    前記セッションユニットは、ＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）によって割り振られたエフェメラルアドレスをソースアドレスとして指定して、前記他ノード装置へのセッションを確立し、前記セッションが終了すると前記エフェメラルアドレスを破棄する
    ノード装置。
12. 請求項８から１０のいずれか１項に記載のノード装置において、
    通信相手として許可した他ノード装置に対応するアドレスを、自身が提供するサービスを識別するＳｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅアドレスとして払出すアドレス払出し部を更に具備し、
    前記セッションユニットは、前記Ｓｐｅｃｉｆｉｃ Ｓｅｒｖｉｃｅアドレスを用いた他ノードからの前記サービスへの接続を許可する
    ノード装置。
13. 請求項８から１２のいずれか１項に記載のノード装置において、
    重複アドレス検出済みのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを複数蓄積した記憶装置を更に備え、
    前記セッションユニットは、前記記憶装置に蓄積されたＩＰアドレスの中から選択したＩＰアドレスを用いて、前記他ノード装置と間のセッションを確立する
    ノード装置。
14. ノード装置が、他のノード装置との間で送受信するデータのアドレスフィールド内の情報に基づいて、前記データを処理するためのアプリケーションを決定するステップと、
    前記ノード装置が、前記決定されたアプリケーションを実行して、前記他ノードとのセッションを確立するステップと、
    を具備し、
    前記アプリケーションを決定ステップは、
    ノード装置が、前記データのアドレスフィールド内の情報に基づいて、前記アプリケーションを決定する第１通信モードと、前記データのポートフィールド内の情報に基づいて前記アプリケーションを決定する第２通信モードとの一方を選択するステップを備え、
    前記ポートフィールド内の情報が所定の値を示す時、前記ノード装置は、前記第１通信モードを選択する
    通信方法。
15. 請求項１４に記載の通信方法において、
    前記セッションを確立するステップは、前記ノード装置が、セッション毎に異なるＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを用いてセッションを多重化するステップを備える
    通信方法。
16. 請求項１４又は１５に記載の通信方法において、
    前記各ノードが、重複アドレス検出するステップと、
    前記重複アドレス検出済みのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを複数蓄積するステップと、
    を更に具備し、
    前記セッションを確立するステップは、前記蓄積されたＩＰアドレスの中から選択したＩＰアドレスを用いて、前記アプリケーションとのセッションを確立するステップを備える
    通信方法。

Images