(57)【要約】【課題】インターネット等のネットワークを介した通信の際に、ファイアウォールがあった場合でも、互いに通信が可能な通信プログラムを提供することを目的とする。【解決手段】ゲートウェイを介して通信をコンピュータ端末間で実行させる通信プログラムであって、通信元となるコンピュータ端末で送信用及び受信用のスレッドを起動し、ゲートウェイと通信元となるコンピュータ端末との間でセッションを確立し、通信先となるコンピュータ端末を、通信先となるコンピュータ端末の上位のゲートウェイによって付与された識別名によって特定することで、通信を行うＡＰＩを実装したプログラムと、通信元となるコンピュータ端末に予め具備されたアプリケーションレイヤによって指定された識別名を有する、通信先となるコンピュータ端末に対して、データの送受信をＡＰＩを実装したプログラムを介して行わせるプロキシと、を有する通信プログラムである。【選択図】  図１
2004252567.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも一以上のゲートウェイを介して通信をコンピュータ端末間で実行させるように前記コンピュータ端末を機能させる通信プログラムであって、
前記通信プログラムは、
通信元となるコンピュータ端末で送信用及び受信用のスレッドを起動し、前記ゲートウェイと前記通信元となるコンピュータ端末との間でセッションを確立し、通信先となるコンピュータ端末を、前記通信先となるコンピュータ端末の上位のゲートウェイによって付与された識別名によって特定することで、前記ゲートウェイを介して通信を行うＡＰＩを実装したプログラムと、
前記通信元となるコンピュータ端末に予め具備されたアプリケーションレイヤによって指定された識別名を有する、前記通信先となるコンピュータ端末に対して、データの送受信を前記ＡＰＩを実装したプログラムを介して行わせるプロキシと、
からなることを特徴とする通信プログラム。
【請求項２】
少なくとも一以上のゲートウェイを介して通信をコンピュータ端末間で実行させるように前記コンピュータ端末を機能させる通信プログラムであって、
前記通信プログラムは、
通信元となるコンピュータ端末で送信用及び受信用のスレッドを起動し、前記ゲートウェイと前記通信元となるコンピュータ端末との間でセッションを確立し、通信先となるコンピュータ端末を、前記通信先となるコンピュータ端末の上位のゲートウェイによって付与された識別名によって特定することで、前記ゲートウェイを介して通信を行うＡＰＩを実装したプログラムと、
前記コンピュータ端末に予め具備されたアプリケーションレイヤによって指定された通信先となるＩＰアドレスを受信し、前記ＩＰアドレスと前記識別名との対応関係を格納している対応テーブルを参照し、前記ＩＰアドレスに対応する識別名を有する前記通信先となるコンピュータ端末に対して、データの送受信を前記ＡＰＩを実装したプログラムを介して行わせるコンポーネントと、
からなることを特徴とする通信プログラム。
【請求項３】
少なくとも一以上のゲートウェイを介して通信をコンピュータ端末間で実行させるように前記コンピュータ端末を機能させる通信プログラムであって、
前記通信プログラムは、
通信元となるコンピュータ端末で送信用及び受信用のスレッドを起動し、前記ゲートウェイと前記通信元となるコンピュータ端末との間でセッションを確立し、通信先となるコンピュータ端末を、前記通信先となるコンピュータ端末の上位のゲートウェイによって付与された識別名によって特定することで、前記ゲートウェイを介して通信を行うＡＰＩを実装したプログラムと、
前記コンピュータ端末に予め具備されたアプリケーションによるプロトコルレイヤを介したリクエストを、前記通信プログラムによって予め定められたプロトコルで、前記プロトコルレイヤによって指定された識別名を有する前記他のクライアント端末に対して、前記リクエストの送受信をＡＰＩを実装したプログラムを介して行わせるプロトコルアダプタと、
からなることを特徴とする通信プログラム。
【請求項４】
少なくとも一以上のゲートウェイを介して通信をコンピュータ端末間で実行させるように前記コンピュータ端末を機能させる通信プログラムであって、
前記通信プログラムは、前記コンピュータ端末に予め具備されているアプリケーションプログラムにその一部として組み込まれており、
通信元となるコンピュータ端末で送信用及び受信用のスレッドを起動し、前記ゲートウェイと前記通信元となるコンピュータ端末との間でセッションを確立し、通信先となるコンピュータ端末を、前記通信先となるコンピュータ端末の上位のゲートウェイによって付与された識別名によって特定することで、前記アプリケーションプログラムに於けるアプリケーションレイヤによって指定された識別名を有する、前記通信先となるコンピュータ端末に対して、データの送受信を、前記ゲートウェイを介して通信を行うＡＰＩを実装したプログラム、
からなることを特徴とする通信プログラム。
【請求項５】
前記ゲートウェイは、
前記通信プログラムを用いるゲートウェイ及びクライアント端末と識別名との関係を示したゲートウェイテーブルを
有することを特徴とする請求項１から請求項４のいずれかに記載の通信プログラム。
【請求項６】
前記ゲートウェイは、
前記通信先となるコンピュータ端末の判別の際に、前記ゲートウェイテーブルを参照し、前記通信先となるコンピュータ端末が自らの下位に属するか、上位のゲートウェイに属するかの判断を行うことで、データを転送する
ことを特徴とする請求項１から請求項５のいずれかに記載の通信プログラム。
【請求項７】
前記ＡＰＩを実装したプログラムは、
前記プロキシ、前記コンポーネント又は前記プロトコルアダプタからデータを送信する際には、前記送信用のスレッドを呼び出し、前記送信用のスレッドがデータを送信し終わるまで待機し、成功か失敗かを返す
ことを特徴とする請求項１から請求項４のいずれかに記載の通信プログラム。
【請求項８】
前記ＡＰＩを実装したプログラムは、
データを受信する際には、前記受信用のスレッドを呼び出し、受信に成功したら受信済みデータを返す
ことを特徴とする請求項１から請求項４のいずれかに記載の通信プログラム。
【請求項９】
前記通信先のコンピュータ端末が、遠隔監視の監視対象となるコンピュータ端末である
ことを特徴とする請求項１から請求項８のいずれかに記載の通信プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、インターネット等のネットワークを介した通信の際に、ファイアウォールがあった場合でも、互いに通信が可能な通信プログラムに関する。
【０００２】
【従来の技術】
インターネット等のネットワークを介した通信の場合、そのセキュリティ上の問題からファイアウォールを設置し、外部から内部のネットワークに侵入する不正アクセスを防いでいる。
【０００３】
従って従来は、ネットワークを介した通信の場合、予めファイアウォールを通過することが可能なプロトコルによる通信のみしか行えないが、システムに対して、外部からアクセスが要求される場合もある。
【０００４】
例えば、外部からコンピュータ端末にアクセスする場合がその一例であり、下記の特許文献１に示す。下記の特許文献１に開示されているような、サーバの遠隔監視システムのような遠隔監視ステムを用いた場合、遠隔監視を行う管理サーバの遠隔監視の指示が、監視対象となるサーバとの間に設置されているファイアウォールによってブロックされてしまい、実質的に遠隔監視を行えないこととなる。
【０００５】
【特許文献１】
特願２００１−３２８８０２号公報
【０００６】
【発明が解決しようとする課題】
上述のように、仮に遠隔監視を行う場合には、ファイアウォールに対して、管理サーバからの遠隔監視を通過させるようにその設定を変更するか、若しくはファイアーウォールの使用を停止することとなるが、そうすると、セキュリティ上の問題が発生する。
【０００７】
又ファイアーウォール等が設置されている為、仮にファイアーウォールを通過することが許可されたとしても、外部からアクセスすることが可能なコンピュータ端末はグローバルＩＰアドレスを有するコンピュータ端末のみであり、ＬＡＮ等に接続しているローカルＩＰアドレスのみを有するコンピュータ端末までは行えない。グローバルＩＰアドレスとは、インターネットで使うことを許されたＩＰアドレスであり、ＩＰアドレスとは、ＴＣＰ／ＩＰネットワーク上で特定のコンピュータを識別する為の番号である（『アスキーデジタル用語辞典』  ｈｔｔｐ：／／ｙｏｕｇｏ．ａｓｃｉｉ２４．ｃｏｍ）。又ローカルＩＰアドレスとは、ＬＡＮ内のみで使うことを許されたＩＰアドレスである。
【０００８】
従って外部のコンピュータ端末からは、グローバルＩＰアドレスしか指定できないので、例えば遠隔監視を行わせる為には、そのコンピュータ端末にはローカルＩＰアドレスのみではなく、グローバルＩＰアドレスをも割り当てる必要がある。しかし仮にグローバルＩＰアドレスを割り当てると、外部からのアクセスが可能となる為、例えば顧客情報を有するコンピュータ端末をそのような環境下に置くことは、セキュリティ上、好ましくない為、実際には遠隔監視を行うことは、困難となる。
【０００９】
又一方で、所謂ピア・ツー・ピアでコンピュータ端末を接続するシステムも存在するが、従来は単一のプロトコルによる通信のみであって、複数のプロトコルに対応するようなものは存在していない。
【００１０】
このピア・ツー・ピアによるコンピュータ端末の接続の場合、単一のプロトコルによる接続のみであるので、複数のアプリケーションによるコンピュータ端末の接続を行いたい場合には、そのアプリケーションの数に対応するプロトコルを設ける必要があり、複数のプロトコルに対応するものが待望されている。
【００１１】
【課題を解決するための手段】
本発明者は、上記問題点に鑑み、仮にファイアーウォールが設置されていたとしても、他のコンピュータ端末との間での通信を可能とする通信プログラムを発明した。又この通信プログラムは、従来のようにグローバルＩＰアドレスのみではなく、ローカルＩＰアドレスのみを割り当てられたコンピュータ端末に対して、通信可能とすることによって、コンピュータ端末の性質上、ローカルＩＰアドレスしか割り当てられないような場合であっても、通信を可能とする。更に複数のプロトコルにも対応可能とすることも可能とせしめている。
【００１２】
請求項１の発明は、
少なくとも一以上のゲートウェイを介して通信をコンピュータ端末間で実行させるように前記コンピュータ端末を機能させる通信プログラムであって、前記通信プログラムは、通信元となるコンピュータ端末で送信用及び受信用のスレッドを起動し、前記ゲートウェイと前記通信元となるコンピュータ端末との間でセッションを確立し、通信先となるコンピュータ端末を、前記通信先となるコンピュータ端末の上位のゲートウェイによって付与された識別名によって特定することで、前記ゲートウェイを介して通信を行うＡＰＩを実装したプログラムと、前記通信元となるコンピュータ端末に予め具備されたアプリケーションレイヤによって指定された識別名を有する、前記通信先となるコンピュータ端末に対して、データの送受信を前記ＡＰＩを実装したプログラムを介して行わせるプロキシと、からなる通信プログラムである。
【００１３】
本発明によって、通信先となるコンピュータ端末との間にファイアーウォールが設置されていても、データの送受信が可能となる。
【００１４】
請求項２の発明は、
少なくとも一以上のゲートウェイを介して通信をコンピュータ端末間で実行させるように前記コンピュータ端末を機能させる通信プログラムであって、前記通信プログラムは、通信元となるコンピュータ端末で送信用及び受信用のスレッドを起動し、前記ゲートウェイと前記通信元となるコンピュータ端末との間でセッションを確立し、通信先となるコンピュータ端末を、前記通信先となるコンピュータ端末の上位のゲートウェイによって付与された識別名によって特定することで、前記ゲートウェイを介して通信を行うＡＰＩを実装したプログラムと、前記コンピュータ端末に予め具備されたアプリケーションレイヤによって指定された通信先となるＩＰアドレスを受信し、前記ＩＰアドレスと前記識別名との対応関係を格納している対応テーブルを参照し、前記ＩＰアドレスに対応する識別名を有する前記通信先となるコンピュータ端末に対して、データの送受信を前記ＡＰＩを実装したプログラムを介して行わせるコンポーネントと、からなる通信プログラムである。
【００１５】
本発明によって、アプリケーションレイヤが指定する、データの送受信先となるＩＰアドレスが、例え、ローカルＩＰアドレスであったとしても、ゲートウェイを介して識別名によってコンピュータ端末を特定することによって、データの送受信が可能となる。つまり、従来は通信を行うことが出来なかった、ＬＡＮ内のみに存在するコンピュータ端末（即ちインターネットからはアクセスできない）であっても、コンピュータ端末を特定して通信可能となる。又請求項１の場合と同様に、通信先となるコンピュータ端末との間にファイアーウォールが設置されていても、データの送受信が可能となる。
【００１６】
請求項３の発明は、
少なくとも一以上のゲートウェイを介して通信をコンピュータ端末間で実行させるように前記コンピュータ端末を機能させる通信プログラムであって、前記通信プログラムは、通信元となるコンピュータ端末で送信用及び受信用のスレッドを起動し、前記ゲートウェイと前記通信元となるコンピュータ端末との間でセッションを確立し、通信先となるコンピュータ端末を、前記通信先となるコンピュータ端末の上位のゲートウェイによって付与された識別名によって特定することで、前記ゲートウェイを介して通信を行うＡＰＩを実装したプログラムと、前記コンピュータ端末に予め具備されたアプリケーションによるプロトコルレイヤを介したリクエストを、前記通信プログラムによって予め定められたプロトコルで、前記プロトコルレイヤによって指定された識別名を有する前記他のクライアント端末に対して、前記リクエストの送受信をＡＰＩを実装したプログラムを介して行わせるプロトコルアダプタと、からなる通信プログラムである。
【００１７】
本発明によって、プロトコルレイヤが任意のプロトコルのリクエストを送信したとしても、通信プログラムによって予め定められた、クライアント端末とゲートウェイとの間のプロトコルによって送信することで、そのリクエストに対するレスポンスを得ることが可能となる。
【００１８】
請求項４の発明は、
少なくとも一以上のゲートウェイを介して通信をコンピュータ端末間で実行させるように前記コンピュータ端末を機能させる通信プログラムであって、前記通信プログラムは、前記コンピュータ端末に予め具備されているアプリケーションプログラムにその一部として組み込まれており、通信元となるコンピュータ端末で送信用及び受信用のスレッドを起動し、前記ゲートウェイと前記通信元となるコンピュータ端末との間でセッションを確立し、通信先となるコンピュータ端末を、前記通信先となるコンピュータ端末の上位のゲートウェイによって付与された識別名によって特定することで、前記アプリケーションプログラムに於けるアプリケーションレイヤによって指定された識別名を有する、前記通信先となるコンピュータ端末に対して、データの送受信を、前記ゲートウェイを介して通信を行うＡＰＩを実装したプログラム、からなる通信プログラムである。
【００１９】
請求項１の発明では、ゲートウェイを介して識別名で他のコンピュータ端末と通信を行う場合に、アプリケーションレイヤと独立してＡＰＩを実装したプログラムとプロキシとによって行っているが、本発明では、ＡＰＩを実装したプログラムをアプリケーションプログラムに直接組み込むことによって、プロキシをなくすことが可能となる。この場合、ＡＰＩを実装したプログラムはアプリケーションプログラムからは独立ではなくなるが、ライブラリの形で提供されることによってアプリケーションプログラムにスタティック又はダイナミックにリンクされることとなる。これは、直接アプリケーションプログラムにＡＰＩを実装したプログラムを組み込むことで、プロキシの機能をアプリケーションプログラムで代替することが可能となる為である。
【００２０】
請求項５の発明は、
前記ゲートウェイは、前記通信プログラムを用いるゲートウェイ及びクライアント端末と識別名との関係を示したゲートウェイテーブルを有する通信プログラムである。
【００２１】
請求項６の発明は、
前記ゲートウェイは、前記通信先となるコンピュータ端末の判別の際に、前記ゲートウェイテーブルを参照し、前記通信先となるコンピュータ端末が自らの下位に属するか、上位のゲートウェイに属するかの判断を行うことで、データを転送する通信プログラムである。
【００２２】
請求項５及び請求項６の発明によって、グローバルＩＰアドレスのみでは特定できない、ＬＡＮ内のコンピュータ端末を特定して、データの送受信が可能となる。
【００２３】
請求項７の発明は、
前記ＡＰＩを実装したプログラムは、前記プロキシ、前記コンポーネント又は前記プロトコルアダプタからデータを送信する際には、前記送信用のスレッドを呼び出し、前記送信用のスレッドがデータを送信し終わるまで待機し、成功か失敗かを返す通信プログラムである。
【００２４】
請求項８の発明は、
前記ＡＰＩを実装したプログラムは、データを受信する際には、前記受信用のスレッドを呼び出し、受信に成功したら受信済みデータを返す通信プログラムである。
【００２５】
本発明によって、データの送受信の際の通信が確実に行われる。
【００２６】
請求項９の発明は、
前記通信先のコンピュータ端末が、遠隔監視の監視対象となるコンピュータ端末である通信プログラムである。
【００２７】
本発明の通信プログラムは、汎用性があり、ファイアーウォールがコンピュータ端末間に設置された通信に於いてはどのような場合であっても使用することが出来るが、特にその効果を発揮するのが、コンピュータ端末の遠隔監視の場合である。
【００２８】
【発明の実施の形態】
本発明のシステム構成の全体概念図を図１に示す。各クライアント端末１は、自らの上位のゲートウェイ２から付与された任意の識別名を有しており、ゲートウェイ２とＴＣＰ／ＩＰによるデータの送受信が可能である。又、ゲートウェイ２は、他のゲートウェイ２又はクライアント端末１に対して任意の識別名を付与し、他のゲートウェイ２又はクライアント端末１との間でＴＣＰ／ＩＰによるデータの送受信が可能である。尚、本明細書に於いて、ゲートウェイ２とは、２つのマシンやソフトウェア、プロトコルなどを相互に変換してインターフェイスを取るものをいう（『アスキーデジタル用語辞典』  ｈｔｔｐ：／／ｙｏｕｇｏ．ａｓｃｉｉ２４．ｃｏｍ）。
【００２９】
ゲートウェイ２は、識別名とゲートウェイ２又はクライアント端末１との所在関係を示したゲートウェイテーブルを有することによって、他のゲートウェイ２又はクライアント端末１からのデータの送受信を仲介する。即ち、他のゲートウェイ２又はクライアント端末１から受信したデータを、そのデータに於いて指定された送信先の識別名をゲートウェイテーブルを参照することで、自らの下位に属するゲートウェイ２又はクライアント端末１であるのか、自らの上位のゲートウェイ２の下位に属するゲートウェイ２又はクライアント端末１であるのかを判断し、上位のゲートウェイ２、又は下位のゲートウェイ２又はクライアント端末１に対して前記受信したデータを送信する。尚、以下に於いてはその説明がない場合であっても、送受信先の判別の為にゲートウェイテーブルを参照している。
【００３０】
各ゲートウェイ２が付与する識別名は如何なるものであっても良いが、自らの下位に属するゲートウェイ２又はクライアント端末１であることを識別できることが好適である。即ち、図１に示したように、例えばゲートウェイ２の識別名が「ａｎｉｍａｌ．ｊｐ」である場合には、その下位に属するクライアント端末１の識別名は、「ｃａｔ．ａｎｉｍａｌ．ｊｐ」、「ｄｏｇ．ａｎｉｍａｌ．ｊｐ」のようになる。
【００３１】
ゲートウェイ２には、各ゲートウェイ２の最上位となるルートゲートウェイ２が存在しており、ルートゲートウェイ２には、予め識別名（図１の例では、「ｊｐ」）が付与されている。
【００３２】
クライアント端末１に於ける通信プログラムは、図６に示すように、プロキシ４とコンポーネント５とプロトコルアダプタ７とＡＰＩを実装したプログラム８とを有している。
【００３３】
ＡＰＩを実装したプログラム８は、ゲートウェイ２との間でセッションを確立し、確立したセッションによって一又は複数のゲートウェイ２を介して、通信先のクライアント端末１に対してデータの送受信を行う手段である。ＡＰＩとはＡｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅを示し、ＯＳがアプリケーションに対して公開しているプログラムインターフェイスである（『アスキーデジタル用語辞典』  ｈｔｔｐ：／／ｙｏｕｇｏ．ａｓｃｉｉ２４．ｃｏｍ）。
【００３４】
この場合、送信するデータや受信するデータは、クライアント端末上１に於いて、送信用、受信用の２本のスレッドを起動することによって行う。プロキシ４、コンポーネント５、プロトコルアダプタ７からデータを送信する場合には、ＡＰＩを実装したプログラム８の送信用のスレッドを呼び出し、送信用のスレッドがデータを送信し終わるまで待機し、成功か失敗かを返す。一方、プロキシ４、コンポーネント５、プロトコルアダプタ７がデータを受信する場合には、ＡＰＩを実装したプログラム８の受信用のスレッドを呼び出し、受信用のスレッドがデータを受信し終わるまで待機し、受信に成功したら受信済みデータを返す。
【００３５】
以上のようにデータの送受信を繰り返し、利用を完了したら、クライアント端末１のＡＰＩを実装したプログラム８は送信用のスレッド、受信用のスレッドを停止して、ログアウトする。尚、スレッドとは、プログラムの実行単位である（『アスキーデジタル用語辞典』  ｈｔｔｐ：／／ｙｏｕｇｏ．ａｓｃｉｉ２４．ｃｏｍ）。
【００３６】
プロキシ４は、各クライアント端末１に設けられたアプリケーション固有の処理を行うアプリケーションレイヤ３によって指定された、特定の識別名を有するクライアント端末１に対して、ＡＰＩを実装したプログラム８を介してデータの送受信を行う手段である。図６（ａ）にクライアント端末１に於けるアプリケーションレイヤ３とプロキシ４とＡＰＩを実装したプログラム８とのシステム構成の概念図を示す。
【００３７】
従って、プロキシ４を用いて、他のクライアント端末１とデータの送受信を行う場合には、プロキシ４に対応したアプリケーションレイヤ３が必要となる。ここで、プロキシ４に対応するとは、アプリケーションレイヤ３がプロキシ４に於けるプロトコルとその特定の識別名とを使用可能であることを意味する。
【００３８】
コンポーネント５は、上述のアプリケーションレイヤ３によって指定された、ＩＰアドレスを有するクライアント端末１に対するデータの送受信要求に基づいて、当該ＩＰアドレスに対応する識別名を抽出し、抽出した識別名を有するクライアント端末１に対して、ＡＰＩを実装したプログラム８を介してデータの送受信を行う手段である。従ってコンポーネント５は、ＩＰアドレスと識別名との対応テーブルを持っている。図６（ｂ）にクライアント端末１に於けるアプリケーションレイヤ３とコンポーネント５とＡＰＩを実装したプログラム８とのシステム構成の概念図を示す。
【００３９】
アプリケーションがプロトコルレイヤ６を介してプロトコルアダプタ７に通信をしに行く。その後、プロトコルアダプタ７がＡＰＩを実装したプログラム８を用いてゲートウェイ２を介して送信先のプロトコルアダプタ７にデータを引き渡す。図６（ｃ）にクライアント端末１に於けるアプリケーションレイヤ３とプロトコルアダプタ７とＡＰＩを実装したプログラム８とのシステム構成の概念図を示す。
【００４０】
尚、アプリケーションレイヤ３では、クライアント端末１上で何らかの処理を行うメインアプリケーションと、プロキシ４又はプロトコルアダプタ７との間で通信プロトコルによる通信を行う。アプリケーションレイヤ３とプロキシ４とで通信を行う場合には、メインアプリケーションと予め定められた独自のプロトコルを用いて通信を行う為、そのプロトコルに対応出来るようにメインアプリケーションを適宜修正する必要がある。一方アプリケーションレイヤ３がプロトコルアダプタ７と通信を行う場合には、メインアプリケーションには手を加えず、メインアプリケーションが標準的に使用するプロトコルのみを用いて透過的に通信を実行することとなる。
【００４１】
次に本発明のプロセスの流れの一例を、図２から図８のフローチャート図と図１のシステム構成の全体概念図とを用いて詳細に説明する。尚、本実施例に於いては図１に示した、クライアント端末１とゲートウェイ２からなるシステム構成であるとするが、その他のシステム構成であっても本発明を実施することは可能である。
【００４２】
まず、クライアント端末１とその上位のゲートウェイ２との間でのセッション確立を行うプロセスの流れを図２のフローチャート図を用いて説明する。
【００４３】
クライアント端末１の通信プログラムのＡＰＩを実装したプログラム８は、その上位のゲートウェイ２（このゲートウェイ２の識別名として「ａｎｉｍａｌ．ｊｐ」が、上位のゲートウェイ２（「ｊｐ」）によって予め付与されているものとする）に対して接続要求を送信する（Ｓ１００）。この際に、クライアント端末１のユーザＩＤや認証の為のパスワードを併せて送信しても良い。
【００４４】
Ｓ１００で送信された接続要求やユーザＩＤ等を受信したゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）はそれを受信し（Ｓ１１０）、正当なクライアント端末１である場合には、そのクライアント端末１に対してセッションＩＤとセッション鍵とを発行し、クライアント端末１の公開鍵で暗号化して送信する（Ｓ１２０）。
【００４５】
Ｓ１２０で送信されたセッションＩＤとセッション鍵とをクライアント端末１のＡＰＩを実装したプログラム８で受信し（Ｓ１３０）、自らの秘密鍵でセッション鍵とセッションＩＤを復号化し、セッションＩＤをセッション鍵で暗号化して、再度自らの上位のゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）に対して送信する（Ｓ１４０）。
【００４６】
尚、秘密鍵をクライアント端末１のＡＰＩを実装したプログラム８が持っていない場合には、最初に秘密鍵の発行をゲートウェイ２に秘密鍵の発行を要求し、その入手をした後に、Ｓ１００以降のセッション確立のプロセスが行われる。
【００４７】
Ｓ１４０で送信された、暗号化されたセッションＩＤをゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）は受信し（Ｓ１５０）、それを復号化し、正しければ接続ＯＫとする。この際に、クライアント端末１の識別名（例えば「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）を付与する（Ｓ１６０）。
【００４８】
Ｓ１６０で付与された識別名をクライアント端末１のＡＰＩを実装したプログラム８で受信し（Ｓ１７０）、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）とゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）との間でセッションが確立する。
【００４９】
ＡＰＩを実装したプログラム８は、クライアント端末上１に於いて、送信用、受信用の２本のスレッドを起動することによってデータの送受信を可能とする（Ｓ１７５）。即ち、プロキシ４、コンポーネント５、プロトコルアダプタ７からデータを送信する場合には、ＡＰＩを実装したプログラム８の送信用のスレッドを呼び出し、送信用のスレッドがデータを送信し終わるまで待機し、成功か失敗かを返すこととなる。一方、プロキシ４、コンポーネント５、プロトコルアダプタ７がデータを受信する場合には、ＡＰＩを実装したプログラム８の受信用のスレッドを呼び出し、受信用のスレッドがデータを受信し終わるまで待機し、受信に成功したらデータを返すこととなる（Ｓ１８０）。
【００５０】
以上のようにデータの送受信を繰り返し、利用を完了したら（Ｓ１８５）、クライアント端末１のＡＰＩを実装したプログラム８は送信用のスレッド、受信用のスレッドを停止して、ログアウトする（Ｓ１９０）。
【００５１】
ここではクライアント端末１とゲートウェイ２とのセッション確立の場合を説明したが、ゲートウェイ２同士のセッション確立の場合も同様である。
【００５２】
次に、セッション確立後に、クライアント端末１の通信プログラムに設けられたプロキシ４を用いて、他のクライアント端末１との間でデータの送受信を行う場合を、図３のフローチャート図を用いて説明する。尚、本実施例に於いては、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）から他のクライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）に対して、アプリケーションレイヤ３のデータを送信する場合を説明する。
【００５３】
アプリケーションレイヤ３のメインアプリケーションは、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）で何らかの処理を行い、ｌｏｃａｌｈｏｓｔの独自ポート番号に接続し、独自の通信プロトコルを用いてデータ転送要求をプロキシ４に送信する（Ｓ２００）。
【００５４】
アプリケーションレイヤ３から独自の通信プロトコルでデータ転送要求を受信したプロキシ４は（Ｓ２１０）、データ転送要求の中から、メインアプリケーションで指定された宛先（この場合には識別名「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）を抽出し、その宛先に対してデータを転送する（Ｓ２２０）。
【００５５】
この場合には、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のプロキシ４は、「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」に対するデータの送信要求を受信したことによって、上位のゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）に対して、ＡＰＩを実装したプログラム８を介してアプリケーションレイヤ３のデータを送信するので、Ｓ１８０に於けるＡＰＩを実装したプログラム８の送信用のスレッドを呼び出し、送信を行うこととなる。
【００５６】
ゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）は、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）からのデータを受信し、その宛先を確認する。ここで宛先が「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」であるので、ゲートウェイテーブルを参照し、自らの識別名「ａｎｉｍａｌ．ｊｐ」を宛先に含まないので、他のゲートウェイ２に存在するクライアント端末１であると判断し、上位のゲートウェイ２（「ｊｐ」）に、受信したデータを送信する。
【００５７】
ゲートウェイ２（「ｊｐ」）は、ゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）からのデータを受信し、その宛先を確認する。ここで宛先が「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」であるので、自らの識別名「ｊｐ」を宛先に含むことから、自らの下位に存在するクライアント端末１であると判断し、「ｒｉｖｅｒ．ｊｐ」の識別名を有するゲートウェイ２をゲートウェイテーブルを参照し、検索し、データを送信する。
【００５８】
ゲートウェイ２（「ｒｉｖｅｒ．ｊｐ」）は、ゲートウェイ２（「ｊｐ」）からのデータを受信し、その宛先を確認する。ここで宛先が「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」であるので、自らの識別名「ｒｉｖｅｒ．ｊｐ」を宛先に含むことから、自らの下位に存在するクライアント端末１であると判断し、「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」の識別名を有するクライアント端末１をゲートウェイテーブルを参照し、検索し、データを送信する。
【００５９】
クライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）は、ゲートウェイ２（「ｒｉｖｅｒ．ｊｐ」）からのデータを受信し、その宛先を確認する。ここで宛先が「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」であり、自らの識別名と同一であるので、自らに宛てたデータであると判断する。尚、このデータの受信の際には、Ｓ１８０の場合と同様に、クライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）のＡＰＩを実装したプログラム８が受信用のスレッドを呼び出し、受信を行う。
【００６０】
クライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）のＡＰＩを実装したプログラム８でデータを受信すると、それをクライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）のプロキシ４に対して送信し、プロキシ４が受信をすることとなる（Ｓ２３０）。
【００６１】
Ｓ２３０でデータを受信したプロキシ４は、ｌｏｃａｌｈｏｓｔ上で稼働しているアプリケーションレイヤ３に於けるメインアプリケーションと独自の通信プロトコルを介して通信を行い、そのデータを転送する（Ｓ２４０）。
【００６２】
アプリケーションレイヤ３のメインアプリケーションでデータをプロキシ４から受信すると（Ｓ２５０）、メインアプリケーションがそのデータの処理を行い、レスポンスデータが発生した場合には逆の経路を経てデータ発信元のクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）に対してレスポンスデータを返す。
【００６３】
クライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）のアプリケーションレイヤ３は、ｌｏｃａｌｈｏｓｔの独自ポート番号に接続し、独自の通信プロトコルを用いてレスポンスデータ転送要求をプロキシ４に送信する（Ｓ２６０）。
【００６４】
アプリケーションレイヤ３から独自の通信プロトコルでレスポンスデータ転送要求を受信したプロキシ４は（Ｓ２７０）、レスポンスデータ転送要求の中から、メインアプリケーションで指定された宛先（この場合には識別名「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）を抽出し、その宛先に対してレスポンスデータを転送する（Ｓ２８０）。
【００６５】
クライアント端末１のプロキシ４からのレスポンスデータは、ＡＰＩを実装したプログラム８を介して、ゲートウェイ２により上述と逆の経路を経てレスポンスデータをクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）に送信する。
【００６６】
このようにしてクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のＡＰＩを実装したプログラム８でレスポンスデータを受信すると、それをプロキシ４に対して送信し、プロキシ４はレスポンスデータを受信する（Ｓ２８５）。
【００６７】
プロキシ４はＳ２８５で受信したレスポンスデータを、ｌｏｃａｌｈｏｓｔ上で稼働しているアプリケーションレイヤ３のメインアプリケーションと独自の通信プロトコルで通信を行い、レスポンスデータの転送を行う（Ｓ２９０）。
【００６８】
このようにして転送されたレスポンスデータを、アプリケーションレイヤ３のメインアプリケーションで受信し、独自の処理を行うこととなる（Ｓ２９５）。
【００６９】
次に、セッション確立後、クライアント端末１の通信プログラムに設けられたコンポーネント５を用いて、他のクライアント端末１との間でデータの送受信を行う場合を、図４のフローチャート図を用いて説明する。尚、本実施例に於いては、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）から他のクライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）に対して、アプリケーションレイヤ３のデータを送信する場合を説明する。
【００７０】
アプリケーションレイヤ３は、ＩＰアドレスを有するクライアント端末１に対するデータの送信要求を作成する（Ｓ３００）。例えば送信先のクライアント端末１のＩＰアドレスとして、「１９２．１６８．０．２１」を指定したとする。
【００７１】
通常このＩＰアドレスに対してデータの送信要求をクライアント端末１が行った場合、送信先のＩＰアドレスがグローバルＩＰアドレスでない場合には、外部のクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）からはデータを送信することが出来ない。即ちグローバルＩＰアドレスを有するコンピュータ端末に対してのみしか、送信することが出来ない。
【００７２】
従って、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のコンポーネント５は、アプリケーションレイヤ３からＩＰアドレス「１９２．１６８．０．２１」の指定を受け、それを対応テーブルを参照し、識別名に変換する（Ｓ３１０）。ここで対応する識別名が「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」であったとする。
【００７３】
クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のコンポーネント５は、Ｓ３１０で変換した識別名「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」に対してデータを送信する為に、上位のゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）に対して、ＡＰＩを実装したプログラム８を介してアプリケーションレイヤ３のデータを送信する（Ｓ３２０）。即ちＳ１８０のＡＰＩを実装したプログラム８の送信用のスレッドを呼び出し、送信を行うこととなる。
【００７４】
ゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）は、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）からのデータを受信し（Ｓ３３０）、その宛先を確認する。ここで宛先が「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」であるので、ゲートウェイテーブルを参照し、自らの識別名「ａｎｉｍａｌ．ｊｐ」を宛先に含まないので、他のゲートウェイ２に存在するクライアント端末１であると判断し、上位のゲートウェイ２（「ｊｐ」）に、Ｓ３３０で受信したデータを送信する（Ｓ３４０）。
【００７５】
ゲートウェイ２（「ｊｐ」）は、ゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）からのデータを受信し（Ｓ３５０）、その宛先を確認する。ここで宛先が「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」であるので、自らの識別名「ｊｐ」を宛先に含むことから、自らの下位に存在するクライアント端末１であると判断し、「ｒｉｖｅｒ．ｊｐ」の識別名を有するゲートウェイ２をゲートウェイテーブルを参照し、検索し、データを送信する（Ｓ３６０）。
【００７６】
ゲートウェイ２（「ｒｉｖｅｒ．ｊｐ」）は、ゲートウェイ２（「ｊｐ」）からのデータを受信し（Ｓ３７０）、その宛先を確認する。ここで宛先が「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」であるので、自らの識別名「ｒｉｖｅｒ．ｊｐ」を宛先に含むことから、自らの下位に存在するクライアント端末１であると判断し、「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」の識別名を有するクライアント端末１をゲートウェイテーブルを参照し、検索し、データを送信する（Ｓ３８０）。
【００７７】
クライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）は、ゲートウェイ２（「ｒｉｖｅｒ．ｊｐ」）からのデータを受信し（Ｓ３９０）、その宛先を確認する。ここで宛先が「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」であり、自らの識別名と同一であるので、自らに宛てたデータであると判断する。尚、Ｓ３９０に於けるデータの受信の際には、Ｓ１８０の場合と同様に、クライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）のＡＰＩを実装したプログラム８が受信用のスレッドを呼び出し、受信を行う。
【００７８】
クライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）は、データ受信後、データに対する処理が必要な場合にはその処理を行い、逆の経路を経て、受信確認応答をクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）に送信する（Ｓ４００）。即ち、Ｓ３９０までと同様に、クライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）からゲートウェイ２を介して逆の経路を辿り、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）に受信応答確認を送信することとなる。
【００７９】
Ｓ４００で送信された受信確認応答をクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）で受信することによって（Ｓ４１０）、Ｓ３２０で送信したデータの送信が完了する。
【００８０】
以上のように、ＩＰアドレスでアプリケーションレイヤ３が送信先の指定を行ったとしても、それを識別名に変換しその識別名を有する端末に対して送信することによって、仮にアプリケーションレイヤ３の指定するＩＰアドレスがローカルＩＰアドレスであったとしても、そのクライアント端末１を指定して送信することが可能となる。
【００８１】
次に、セッション確立後、クライアント端末１の通信プログラムに設けられたプロトコルアダプタ７を用いて、他の端末との間でデータの送受信を行う場合を、図５のフローチャート図を用いて説明する。尚、本実施例に於いてはプロトコルレイヤ６としてＷＷＷブラウザを、プロトコルとしてＨＴＴＰプロトコルを、そのＨＴＴＰリクエストの送信先としてウェブサーバである場合を説明する。
【００８２】
プロトコルアダプタ７は、予めクライアント端末１のＴＣＰポート（ｌｏｃａｌｈｏｓｔ：８０）で接続待機をしておく。プロトコルアダプタ７が待機するポートは、そのプロトコルの種類に応じて適宜変更される。
【００８３】
クライアント端末１のプロトコルレイヤ６であるＷＷＷブラウザは、ウェブページを閲覧する際に、ＵＲＬにウェブサーバ名ではなく、ｌｏｃａｌｈｏｓｔを指定する。例えば、
ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｉｎｄｅｘ．ｈｔｍｌ
を指定する。
【００８４】
これによって、プロトコルレイヤ６であるＷＷＷブラウザは、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のＴＣＰポート（ｌｏｃａｌｈｏｓｔ：８０）で接続待機しているプロトコルアダプタ７に対して接続し、プロトコルアダプタ７にＨＴＴＰリクエストを送信する（Ｓ５００）。例えばＨＴＴＰリクエストとして、
ＧＥＴ  ／ｉｎｄｅｘ．ｈｔｍｌ
を送信する。
【００８５】
ＨＴＴＰリクエストを受信したクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のプロトコルアダプタ７は（Ｓ５１０）、設定ファイルに記述された本来の接続先を取得し（ここでは「ｄｏｇ．ａｎｉｍａｌ．ｊｐ」とする）、そのクライアント端末１（「ｄｏｇ．ａｎｉｍａｌ．ｊｐ」）に対して、ＡＰＩを実装したプログラム８を介してＨＴＴＰリクエストを送信する（Ｓ５２０）。クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）からクライアント端末１（「ｄｏｇ．ａｎｉｍａｌ．ｊｐ」）へのデータ送信は、図３又は図４と同様に行えば良いので説明を省略する。
【００８６】
Ｓ５２０でクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のプロトコルアダプタ７が送信したＨＴＴＰリクエストは、クライアント端末１（「ｄｏｇ．ａｎｉｍａｌ．ｊｐ」）のＡＰＩを実装したプログラム８を介して、プロトコルアダプタ７が受信し（Ｓ５３０）、当該プロトコルアダプタ７は、受信したＨＴＴＰリクエストを、自らのウェブサーバに対して送信する（Ｓ５４０）。
【００８７】
Ｓ５４０でクライアント端末１（「ｄｏｇ．ａｎｉｍａｌ．ｊｐ」）のプロトコルアダプタ７が送信したＨＴＴＰリクエストは、ウェブサーバで受信し、当該ウェブサーバは、ＨＴＴＰリクエストに対するレスポンスデータを返す（Ｓ５６０）。ここではＨＴＴＰリクエストが、「Ｇｅｔ  ／ｉｎｄｅｘ．ｈｔｍｌ」であるので、ウェブサーバのディスクから「／ｉｎｄｅｘ．ｈｔｍｌ」の内容を読み取り、レスポンスデータとして返すこととなる。
【００８８】
ウェブサーバから送信されたレスポンスデータは、クライアント端末１（「ｄｏｇ．ａｎｉｍａｌ．ｊｐ」）のプロトコルアダプタ７で受信し（Ｓ５７０）、受信したレスポンスデータを、元のクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）へ送信する（Ｓ５８０）。上述と同様に、クライアント端末１（「ｄｏｇ．ａｎｉｍａｌ．ｊｐ」）からクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）へのデータ送信は、図３又は図４と同様に行えば良いので説明を省略する。
【００８９】
クライアント端末１（「ｄｏｇ．ａｎｉｍａｌ．ｊｐ」）からＡＰＩを実装したプログラム８を介してレスポンスデータを受信したクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のプロトコルアダプタ７は（Ｓ５９０）、受信したレスポンスデータをＷＷＷブラウザに返す（Ｓ６００）。
【００９０】
クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のプロトコルレイヤ６であるＷＷＷブラウザは、プロトコルアダプタ７から受信したレスポンスデータを元に、ウェブページを表示する（Ｓ６１０）。
【００９１】
以上のようなプロセスを経ることによって、任意のプロトコルレイヤ６（例えばＷＷＷブラウザ）からのリクエストがあったとしても、それに対するレスポンスデータを所定の端末から取得することが可能となる。
【００９２】
又、ＡＰＩを実装したプログラム８とアプリケーションレイヤ３とを、図３に示したフローチャート図の場合のように、アプリケーションプログラムとは別々に設けるのではなく、そのアプリケーションプログラムに組み込んだように設計しても良い。この場合のプロセスの流れの一例を図７及び図８に示し、そのシステム構成の一例を図９に示す。アプリケーションプログラムの一例としてメッセンジャー（メッセージ送受信ソフト）である場合を説明する。ここでメッセンジャーは独立したアプリケーションプログラムであるので、完結した処理機構とユーザインターフェイスを持ち、その処理の中でユーザが相手にメッセージを送信するという操作を行った時に本実施例のメッセージデータの送受信が開始されることとなる。
【００９３】
まず、ユーザは所定の操作によってクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のメッセンジャーを起動し、初期化処理やログイン処理を行うことによって、メッセンジャーに組み込まれたＡＰＩを実装したプログラム８からゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）に対して接続要求とユーザＩＤとを送信する（Ｓ７００）。尚、この際にゲートウェイ２は、図２に示したプロセスによって上位のゲートウェイ２（「ｊｐ」）とセッションが確立していることは言うまでもない。
【００９４】
ゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）は、接続要求とユーザＩＤとをクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のメッセンジャーに組み込まれたＡＰＩを実装したプログラム８から受信し、セッションＩＤとセッション鍵を発行し、公開鍵で暗号化してクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）に対して送信する（Ｓ７２０）。
【００９５】
クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のメッセンジャーに組み込まれたＡＰＩを実装したプログラム８は、ゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）から送信されたセッションＩＤとセッション鍵とを受信し（Ｓ７３０）、秘密鍵で復号化し、セッションＩＤをセッション鍵で暗号化してゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）に送信する（Ｓ７４０）。
【００９６】
尚Ｓ１４０の場合と同様に、秘密鍵をクライアント端末１のＡＰＩを実装したプログラム８が持っていない場合には、最初に秘密鍵の発行をゲートウェイ２に秘密鍵の発行を要求し、その入手をした後に、Ｓ７００以降のセッション確立のプロセスが行われる。
【００９７】
Ｓ７４０で送信されたセッションＩＤをゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）が受信し（Ｓ７５０）、セッションＩＤを復号化し、正しければ接続ＯＫとする。この際に、クライアント端末１の識別名（例えば「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）を付与する（Ｓ７６０）。
【００９８】
Ｓ７６０で付与された識別名をクライアント端末１のＡＰＩを実装したプログラム８で受信し（Ｓ７７０）、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）とゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）との間でセッションが確立する。
【００９９】
同様にメッセージの相手先となるクライアント端末１（この場合「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」とする）のメッセンジャーも同様にゲートウェイ２（「ｒｉｖｅｒ．ｊｐ」）との間でセッションを確立しておく。この場合、送信側となるメッセンジャーのＡＰＩを実装したプログラム８は送信用関数を呼び出し、受信側となるメッセンジャーのＡＰＩを実装したプログラム８は受信用関数を呼び出す。
【０１００】
クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のメッセンジャーのアプリケーションレイヤ３に入力されたメッセージは、メッセンジャーに組み込まれたＡＰＩを実装したプログラム８が上位のゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）に送信する（Ｓ８００）。
【０１０１】
ゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）はメッセージデータを受信後（Ｓ８１０）、その宛先を確認し、自らの下位に属する宛先ではないので、上位のゲートウェイ２（「ｊｐ」）にそのメッセージデータを送信する（Ｓ８２０）。
【０１０２】
ゲートウェイ２（「ａｎｉｍａｌ．ｊｐ」）からメッセージデータを受信したゲートウェイ２（「ｊｐ」）は（Ｓ８３０）、その宛先を確認し、自らの下位に属する宛先であるので、そのゲートウェイ２（「ｒｉｖｅｒ．ｊｐ」）にメッセージデータを送信する（Ｓ８４０）。
【０１０３】
ゲートウェイ２（「ｊｐ」）からメッセージデータを受信したゲートウェイ２（「ｒｉｖｅｒ．ｊｐ」）は（Ｓ８５０）、その宛先を確認し、自らの下位に属する宛先であるので、そのクライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）にメッセージデータを送信する（Ｓ８６０）。
【０１０４】
このようにしてクライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）のメッセンジャーに組み込まれたＡＰＩを実装したプログラム８でメッセージを受信すると、それをアプリケーションレイヤ３で固有の処理を行い、この場合は画面に表示する等を行う（Ｓ８７０）。
【０１０５】
受信後、クライアント端末１（「ｃｈｉｋｕｇｏ．ｒｉｖｅｒ．ｊｐ」）のメッセンジャーに組み込まれたＡＰＩを実装したプログラム８は、受信確認応答を上述と同様に逆の経路を経てクライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）に対して送信し（Ｓ８８０）、クライアント端末１（「ｃａｔ．ａｎｉｍａｌ．ｊｐ」）のメッセンジャーに組み込まれたＡＰＩを実装したプログラム８はその受信確認応答を受信することで、正常にメッセージが送信されたことを確認できる（Ｓ８９０）。
【０１０６】
このように、図３の場合とは異なり、ＡＰＩを実装したプログラム８とアプリケーションレイヤ３とをアプリケーションプログラムに直接組み込むことによって、ＡＰＩを実装したプログラム８は関数のライブラリの形で提供され、アプリケーションプログラムにスタティック又はダイナミックにリンクされることとなる。従ってＡＰＩを実装したプログラム８はあくまでもアプリケーションプログラムの構成要素の一つであり、それ自体が独立したアプリケーションになることはない。一方で図３に示した場合では、ＡＰＩを実装したプログラム８とプロキシ３と、アプリケーションレイヤ３とは互いに独立しており、ＡＰＩを実装したプログラム８とプロキシ３とを、複数のアプリケーションレイヤ３に対応させたり、共通化を図ったりすることが可能となる。
【０１０７】
以上のように、プロキシ４、コンポーネント５、プロトコルアダプタ７等を用いることで、ゲートウェイ２を介してクライアント端末１間に張られたセッションの上を、データの送受信することによって、ファイアーウォールが設置されていたとしても、それによって妨げを受けることなく、データの送受信が可能となる。
【０１０８】
これは、上述のように、例えばコンピュータ端末の遠隔監視のような場合に有効に用いることが出来る。
【０１０９】
尚、本明細書に於いてクライアント端末１と表現しているものにはサーバを含むものであり、所謂コンピュータ端末全般を含む。従ってネットワーク機能を有する携帯電話やＰＨＳ、ＰＤＡ等であっても良い。
【０１１０】
上述のように、ＡＰＩを実装したプログラム８を介してプロキシ４、コンポーネント５、プロトコルアダプタ７等のように様々なアプリケーションを用いることが出来るので、アプリケーション固有のデータ構造に依存しないこととなる。つまり、本発明では、アプリケーション固有のデータは、単なるバイトの塊と見なして転送することとなり、その処理自体は行わない。従って、どのようなデータ構造であっても通信可能となる。
【０１１１】
又、通信先となるクライアント端末１の特定をインターネット標準のアドレス空間（ＩＰアドレス）で行うのではなく、ゲートウェイによって付与された独自の識別名で行い、独自のアドレス空間（識別名）を構築することによって、ＬＡＮ内のクライアント端末１であったとしても、通信先を特定してデータの送受信が可能となる。これによって、例えばグローバルＩＰアドレスを付与することが好ましくない顧客情報等を格納しているクライアント端末１であったとしても、その端末にグローバルＩＰアドレスを付与することなく、外部からの遠隔監視を可能とせしめる。
【０１１２】
尚、本発明を実施するにあたり本実施態様の機能を実現するソフトウェアのプログラムを記録した記憶媒体をシステムに供給し、そのシステムのコンピュータが記憶媒体に格納されたプログラムを読み出し実行することによって実現されることは当然である。
【０１１３】
この場合、記憶媒体から読み出されたプログラム自体が前記した実施態様の機能を実現することとなり、そのプログラムを記憶した記憶媒体は本発明を当然のことながら構成することになる。又プログラムの他にも、本発明は、これを実現する方法であっても良いし、ネットワークを介して送受信される搬送波であっても良いし、このプログラムを記録した装置等の如何なる物や方法であっても良い。
【０１１４】
プログラムを供給する為の記憶媒体としては、例えば磁気ディスク、ハードディスク、光ディスク、光磁気ディスク、磁気テープ、不揮発性のメモリカード等を使用することができる。
【０１１５】
又、コンピュータが読み出したプログラムを実行することにより、上述した実施態様の機能が実現されるだけではなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているオペレーティングシステムなどが実際の処理の一部又は全部を行い、その処理によって前記した実施態様の機能が実現される場合も含まれることは言うまでもない。
【０１１６】
更に、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わる不揮発性あるいは揮発性の記憶手段に書き込まれた後、そのプログラムの指示に基づき、機能拡張ボードあるいは機能拡張ユニットに備わる演算処理装置などが実際の処理の一部あるいは全部を行い、その処理により前記した実施態様の機能が実現される場合も含まれることは当然である。
【０１１７】
【発明の効果】
本発明の通信プログラムによって、仮にファイアーウォールが設置されていたとしても、他のコンピュータ端末との間での通信が可能となる。又この通信プログラムは、従来のようにグローバルＩＰアドレスのみではなく、ローカルＩＰアドレスを割り当てられたコンピュータ端末に対して、通信可能とすることによって、コンピュータ端末の性質上、ローカルＩＰアドレスしか割り当てられないような場合であっても、通信を可能とする。更に複数のプロトコルにも対応可能とすることも可能とせしめている。
【図面の簡単な説明】
【図１】本発明のシステム構成の全体概念図を示す図である。
【図２】セッション確立のプロセスの流れの一例を示すフローチャート図である。
【図３】プロキシを用いて、他のクライアント端末との間でデータの送受信を行う場合のプロセスの流れの一例を示すフローチャート図である。
【図４】コンポーネントを用いて、他のクライアント端末との間でデータの送受信を行う場合のプロセスの流れの一例を示すフローチャート図である。
【図５】プロトコルアダプタを用いて、他のクライアント端末との間でデータの送受信を行う場合のプロセスの流れの一例を示すフローチャート図である。
【図６】通信プログラムのシステム構成の概念図である。
【図７】アプリケーションに組み込んだ場合に、クライアント端末とゲートウェイとの間でセッションを確立する場合のプロセスの流れの一例を示すフローチャート図である。
【図８】アプリケーションに組み込んだ場合に、他のクライアント端末との間でデータの送受信を行う場合のプロセスの流れの一例を示すフローチャート図である。
【図９】通信プログラムの他のシステム構成の概念図である。
【符号の説明】
１：クライアント端末
２：ゲートウェイ
３：アプリケーションレイヤ
４：プロキシ
５：コンポーネント
６：プロトコルレイヤ
７：プロトコルアダプタ
８：ＡＰＩを実装したプログラム
【図１】
2004252567.tif 000003
【図２】
2004252567.tif 000004
【図３】
2004252567.tif 000005
【図４】
2004252567.tif 000006
【図５】
2004252567.tif 000007
【図６】
2004252567.tif 000008
【図７】
2004252567.tif 000009
【図８】
2004252567.tif 000010
【図９】
2004252567.tif 000011