JP2008306736A - 通信モジュール及びこの通信モジュールを備えたアプリケーションプログラム - Google Patents

Abstract

【解決課題】 ＯＳ等による特定ネットワーク環境に依存せずに、アプリケーションで特定の通信プロトコルを使用して双方向通信が行う。
【解決手段】 アプリケーションプログラムを、インターネット上のサーバを通した仮想ネットワークに接続するために、前記クライアント機器にインストールされる通信モジュールである。このモジュールは、前記アプリケーションプログラムとこのコンピュータにインストールされたオペレーションシステムのローカル通信プロトコルスタック群との間に介在し、前記アプリケーションプログラム用の仮想ネットワーク上のアドレスを保持し、かつ前記アプリケーションからの仮想ネットワーク宛のパケットをトンネリング処理して前記ローカル通信プロトコルスタックを通じて前記サーバに渡すものであり、前記ローカル通信プロトコルスタック群とは独立した、レイヤ２、３、４プロトコルスタックを備えている。
【選択図】 図１

Description

この発明は、ＩＰｖ４（Internet Protocol version 4）が普及した現状のインフラ環境の下で、比較的簡易な手段により異なるＬＡＮに属する端末同士を、インターネットを通してかつセキュリティの高い方法で双方向の通信を可能とするための、前記端末にインストールされる通信モジュールに関するものである。

一般に、インターネットを中心とした公衆ネットワークを通したサービス提供環境においては、全ての情報の価値は、クライアント側ではなく、サーバ側に集まるようになっている。

すなわち、各クライアントである端末機器は、基本的にインターネット上の情報を閲覧するための単なるビューワーにしか過ぎない。また、各クライアントはインターネット側に様々な情報の要求を発しており、インターネット側ではそのような各クライアントの情報を得ることができる。すなわち、全ての情報は、インターネット側に集められ、インターネット側からは定型的な情報が一方的に与えられるに過ぎない。このため、クライアント端末機を製造しているメーカーは付加価値が生み出しづらい状況となっている。

このような状況を変えるためには、アクセス方向を逆行させ、サーバとクライアントの立場を逆転させることが必要である。すなわち、インターネットに接続される家庭内ネットワークがある場合、インターネット側から家庭内ネットワークへのアクセスが開始され、家庭内ネットワーク側からインターネット側へサービスが提供されるような状態を作り出す必要がある。

このためには、ローカルネットワークに接続された機器のそれぞれが、インターネット側からユニークに特定できること、家庭内のルーティングの問題、セキュリティの問題を解決する必要がある。このような課題に対応し、ひとつの解決を見出せる技術として、ＩＰｖ６（Internet Protocol version 6: 第６世代インターネットプロトコル）がある。

しかしながら、現在の日本のキャリアやインターネットサービスプロバイダを取り巻く環境を鑑みると、ＩＰｖ６の普及にはかなりの時間がかかるものと考えられる。例えば、現在使用しているＩＰｖ４の機材償却に最低２年〜３年は必要であり、テスト的なサービスが行われているのみである。

今すぐにメーカーがＩＰｖ６対応ネットワークを実現するには、ＩＳＰレベルのサービスにまで手を出すしかないが、非常にコストがかかることであり、多くのメーカーにとって現実的ではない。家庭内ネットワークの事情が様々で非常に大きく異なることや、キャリアやＩＳＰによって接続の仕組みが大きく異なることもあり、これらの差を吸収して画一的なアプローチでＩＰｖ６環境を実現するための仕組みが必要である。

従来のＩＰｖ４環境下で、ＩＰｖ６ネットワークで実現されるような家庭内ネットワークとインターネットとの間の双方向のアクセスを実現しようとする場合、以下のような問題がある。

例えば、現在のＩＰｖ４環境下においては、自宅にネットワーク家電を設置する場合、自宅ネットワークを通して、インターネットに接続されたルータに繋げて使用する。このため、ネットワーク家電のＩＰアドレスは、プライベートアドレスになってしまい、自宅ネットワーク以外からはアクセスすることはできない。

そこで、従来は、自宅のネットワーク家電にアクセスするために、ネットワーク家電をコントロールする機能を有する専用のルータを使用したり、ネットワーク家電をコントロールするための情報を一度インターネット上に設置されたデータセンターに蓄積し、ネットワーク家電からポーリングを行って取りに行く必要があった。

しかし、専用のルータを使用した場合、汎用性が低くなりコストも嵩む。ポーリングを行ってコントロール情報を取りに行く場合、リアルタイムでのアクセスは行えず、ネットワークやサーバへの負荷も高くなる。

このような課題を解決するため、本出願人が２００５年５月２０日に提出した国際出願ＰＣＴ／ＪＰ２００５／９２８０号（ＷＯ２００５／１１４９２６号公報）に開示されたネットワーク接続方法及び中継装置がある（ＷＯ２００５／１１４９２６号公報は、この言及によりこの明細書に組み込まれる）。この発明によれば、プライベートネットワーク内のコンピュータシステムとインターネット上のInterServerとの間にトンネリング接続のセッションを確立することにより比較的簡易な手段により家庭内ネットワークとインターネット間の双方向の通信が可能になる。

特に、ＷＯ２００５／１１４９２６号公報に開示された中継装置のうち、クライアント機器にプログラムとしてインストールされるものとして、仮想デバイスドライバとして見えるインタフェースを有するものがあり、このような構成によれば、比較的簡易な構成によって上記通信が可能になる。しかしながら、この公報に開示された技術では、クライアント機器にインストールされたＯＳ（オペレーションシステム）を介して通信を行うため、特定のプロトコルスタックが存在しないＯＳの場合、そのプロトコルを使用した通信を行うアプリケーションを用いた通信が行えないということがある。

例えば、ＩＰｖ６プロトコルが存在しないＯＳ環境下においては、ＩＰｖ６を使用して通信を行うアプリケーションは使用できないということが考えられる。

この発明はこのような事情に鑑みてなされたもので、ＯＳ等による特定ネットワーク環境に依存せずに、アプリケーションで特定の通信プロトコルを使用して仮想ネットワークを利用した双方向通信が行える通信モジュールを提供することを目的とするものである。

上記目的を達成するため、この発明の主要な観点によれば、ローカルネットワーク上のクライアント機器にインストールされたアプリケーションプログラムを、インターネット上のサーバを通した仮想ネットワークに接続するために、前記クライアント機器にインストールされる通信モジュールであって、前記アプリケーションプログラムとこのコンピュータにインストールされたオペレーションシステムのローカル通信プロトコルスタック群との間に介在し、前記アプリケーションプログラム用の仮想ネットワーク上のアドレスを保持し、かつ前記アプリケーションからの仮想ネットワーク宛のパケットをトンネリング処理して前記ローカル通信プロトコルスタックを通じて前記サーバに渡すものであり、前記ローカル通信プロトコルスタック群とは独立した、前記アプリケーションプログラムが仮想ネットワーク通じた通信をするのに必要なプロトコルスタックを備えていることを特徴とする通信モジュールが提供される。

このような構成によれば、クライアント機器のＯＳのローカル通信プロトコルスタックとは独立した第２、３，４層のプロトコルスタックを保持しているから、ＯＳ等による特定ネットワーク環境に依存せずに通信できるネットワークアプリケーション（アプリケーションプログラム）を作成できる。すなわち、特定のプロトコルスタックが存在しないＯＳ上であっても、そのプロトコルを使用したアプリケーションソフトを実現することができる。例えば、ＩＰｖ６プロトコルが存在しないＯＳ環境下であっても、アプリケーションソフト単位でＩＰｖ６アドレスを保持し、仮想ネットワークを通した通信を行うことができる。

この発明の一の実施形態によれば、この通信モジュールは、インターネット上のサーバのグローバルアドレスを記憶しており、このサーバのグローバルアドレスに基づき、この通信モジュールとサーバとの間にトンネリング接続を確立し、前記アプリケーションプログラムからの要求パケットを捕捉し、発信元アドレスとして前記アプリケーションプログラム用の仮想ネットワークアドレスを付したものをカプセリングし、前記トンネリング接続を介して前記サーバへ送出すると共に、前記ローカル通信プロトコルスタックを通して当該通信モジュール宛パケットをディカプセリングすると共に、このディカプセリングしたパケットを前記アプリケーションプログラムに渡すものである。ここで、この通信モジュールは、インターネット上に設けられたトンネル仲介サーバに接続してこの仲介サーバから前記サーバのグローバルアドレスを受け取ることが好ましい。さらに、この通信モジュールは、前記インターネット上のサーバから前記アプリケーションプログラム用の仮想ネットワーク上のＩＰアドレス、ＭＡＣアドレスを受け取り保持するものであることが望ましい。

また、別の一実施形態によれば、この通信モジュールは、前記アプリケーションプログラムによって呼び出し可能なライブラリプログラムとして提供されることが好ましい。

さらなる他の一の実施形態によれば、この通信モジュールは初期化部を有し、この初期化部は、サーバとレイヤ２接続する場合には、前記レイヤ２，３、４プロトコルスタックのすべてを生成し、前記サーバとレイヤ３接続する場合には、レイヤ３および４プロトコルスタックを生成し、レイヤ２プロコルスタックは生成しないように構成されている。

この発明の第２の主要な観点によれば、コンピュータ上で実行され、インターネットに接続して所定の処理を実行するアプリケーションプログラムであって、通信インタフェースとして、請求項１に記載の通信モジュールを呼び出して組み込むための命令を備え、前記コンピュータとは独立したＩＰアドレスをこのアプリケーションプログラムが持つように構成されたことを特徴とするアプリケーションプログラムが提供される。

一の実施形態によれば、このアプリケーションプログラムは、インターネット上のサーバを通した仮想ネットワークに接続するＶｏｉｐプログラムである。

他の一の実施形態によれば、このアプリケーションプログラムは、クライアント機器をインターネット上のサーバを通した仮想ネットワークに接続させるプロキシであることを特徴とするアプリケーションプログラムである。

なお、この発明の更なる他の特徴と顕著な効果は次の発明を実施するための最良の形態の項に記載された実施形態及び図面を参照することによって当業者にとって理解される。

以下、この発明の一実施形態を図面を参照して説明する。

図１は、この実施形態に係るネットワーク構成の例を示したものである。

図中１は、ＩＰｖ４（第１の通信プロトコル）で通信を行う各種クライアント機器２が接続されてなるローカルネットワークである。このローカルネットワーク１は例えば各家庭に導入されたＬＡＮによって構成される。また、各クライアント機器２には、ＯＳ（オペレーションシステム）７と、この発明の通信モジュールとしての中継通信モジュール８と、通信を行うアプリケーションプログラム９（例えばインターネットブラウザ）とがインストールされている。

そして、このローカルネットワーク１は、図示しない通信キャリア／ＩＳＰを介してインターネット網４に接続されている。このインターネット網４では、ＩＰｖ４を用いて通信が行なわれるようになっている。

そして、このインターネット網４には、前記ローカルネットワーク１上のネットワーク家電２の通信を制御するＩｎｔｅｒＳｅｒｖｅｒ６（この発明の「サーバ」）が接続されている。このＩｎｔｅｒＳｅｒｖｅｒ６は、後で詳しく説明するように、前記ネットワーク家電２にインストールされたアプリケーションプログラム９と、インターネット網４上若しくは他のホーム／グローバルネットワーク１ａ上の全てのネットワーク家電２ａ、パーソナルコンピュータ２ｂ、サーバ２ｃとの間の接続を仲介する機能を有するものである。

ここで、少なくとも中継通信モジュール８とＩｎｔｅｒＳｅｒｖｅｒ６は、同じメーカー若しくは統一された規格の下に提供若しくは製造されることが意図されており、予め連動するように設計されたものである。そして、中継通信モジュール８には、後で説明するように、ＩｎｔｅｒＳｅｒｖｅｒ６から前記アプリケーションプログラム９用のＩＰｖ４での仮想プライベートアドレス／グローバルアドレスが付与され、ＩＳＰやキャリアを問わず前記ＩｎｔｅｒＳｅｒｖｅｒ６にトンネリング接続によるＴＣＰ／ＩＰセッションが確立されて通信ができるようになっている。

この発明の特徴は、仮想ネットワーク（または実ネットワーク）を、クライアント機器のＯＳを介することなく、前記アプリケーションプログラム９と結びつけることである。このために、具体的には、前記アプリケーションプログラム９自体が仮想ネットワーク（または実ネットワーク）上のＩＰｖ４若しくはＩＰｖ６アドレス、ＭＡＣアドレスを保持することができるようになっている。以下、これを可能にする構成及び動作の一実施例について説明する。

図２は、前記クライアント機器２にインストールされたＯＳ７、中継通信モジュール８及びアプリケーション９を示す機能ブロック図である。なお、この説明においては、本発明の特徴に関する構成のみ図示し説明することとし、その他、当然備えられているべき他の構成については、その図示及び説明を省略する。

図２中、ＯＳ７の部分は、カーネルに含まれるローカル通信プロトコルスタック群を示したもので、ネットワークカードを制御する物理的ネットワークアダプタ（レイヤ１、２）１１と、ルートテーブル１２と、IPレイヤ（レイヤ３）１３と、TCPレイヤ（レイヤ４）１４とが階層的に構成されている状態を示されている。

一方、前記中継通信モジュール８は、レイヤ２（Ｅｔｈｅｒｎｅｔ Ｌｉｎｋ）１５、ルートテーブル１６、レイヤ３（ＩＰレイヤ（ＩＰｖ４／ｖ６））１７，レイヤ４（ＴＣＰ／ＵＤＰレイヤ）１８の各プロトコルスタックを、ＲＦＣに準拠する形で前記ＯＳ７とは独立して備えることで、特定ネットワーク環境に依存しないアプリケーションプログラム９の作成を可能にするものである。そして、この中継通信モジュール８は、さらに、トンネリング・アプリケーション１９を有する。このトンネリング・アプリケーション１９の機能は、後で詳しく説明するが、イーサネット（登録商標）リンク層１５から受け取ったパケットをＴＣＰ−Ｏｖｅｒ−ＴＣＰ問題による輻輳、通信帯域低下を防止する処理を行って、トンネリング接続により前記ＩｎｔｅｒＳｅｒｖｅｒ６に送信するものである。なお、図中にはＳＳＬが示されているが、このＳＳＬを備えない構成であってもかまわない。

これら中継通信モジュール８を構成するソフトウエア群はライブラリとして提供され、前記アプリケーションプログラム９により適宜読み出されて、このアプリケーションプログラム９の通信インタフェースとして利用されるようになっている。このようにライブラリ化することで、各アプリケーションプログラム９の改変を最小限にすることが可能になる。

次に図２及び図３を参照してこの通信モジュール８の動作について説明する。

前記アプリケーションプログラム９が立ち上がると、このアプリケーションプログラム９の命令により、前記中継通信モジュール８がメモリに読み込まれる。すると、この中継通信モジュール８は、図３のステップＳ１に示すように、まず、前記トンネリング・アプリケーション１９が、トンネルブローカ２０に接続する。このトンネルブローカ２０は、図示しないアドレスデータベースからトンネル接続を確立する先のＩｎｔｅｒＳｅｒｖｅｒ６を選択し、前記中継通信モジュール８にこのＩｎｔｅｒＳｅｒｖｅｒ６のＩＰｖ４アドレスを通知する。このことで、この中継通信モジュール８はＩｎｔｅｒＳｅｒｖｅｒ６を識別可能になり、ユーザ認証を行った後（ステップＳ２）、ＩｎｔｅｒＳｅｒｖｅｒ６から受け取った前記アプリケーション用ＭＡＣアドレスやＩＰアドレスを用いてトンネリングセッションを確立し通信を行うことができる（ステップＳ３）。

すなわち、前記アプリケーション９が立ち上げられ、前記中継通信モジュール８がＩｎｔｅｒＳｅｒｖｅｒ６に接続すると、接続確立のための認証が行われ、これに基づいてＩｎｔｅｒＳｅｒｖｅｒ６からこの通信モジュール８に対して、前記アプリケーションプログラム９用の仮想プライベートネットワーク用のＭＡＣアドレスおよびＩＰアドレスの割り当てが行われる（このＭＡＣアドレス及びＩＰ アドレスは前記トンネルブローカ２０から割り当てられても良い）。このＭＡＣアドレス及びＩＰアドレスは、前記中継通信モジュール８によってメモリにデータとして保持される。

なお、一の実施形態によれば、ＩｎｔｅｒＳｅｒｖｅｒ６側のプログラムは、前記アプリケーションプログラム９から見た場合、仮想ネットワーク上の１つのハブ（ＨＵＢ）のように見える。すなわち、ＩｎｔｅｒＳｅｒｖｅｒ６は、グループ毎にハブを割り当てるように構成されており、本発明では、この割り当てをグループ化と呼んでいる。なお、ＩｎｔｅｒＳｅｒｖｅｒ６が複数ある場合において、同じ仮想プライベートネットワークに属するべきアプリケーションプログラム９若しくはネットワーク端末２が別々のＩｎｔｅｒＳｅｒｖｅｒ６に接続されることも考えられるが、この場合には、複数のＩｎｔｅｒＳｅｒｖｅｒ６若しくは複数のサーバプログラム（ハブサーバ）をまとめて管理するハブ・ボーンサーバ２１により、接続がルーティングされるようになっていることが好ましい。以下、このような接続をＨＵＢ接続（若しくは「レイヤー２接続」）と称する。

上記のレイヤ２接続に対して、この中継通信モジュール８は、前記ＩｎｔｅｒＳｅｒｖｅｒ６とＰＰＰ接続（若しくは「レイヤー３接続」）することもきるように構成されている。上記レイヤ２接続とレイヤ３接続の切り替えは、図２に２３で示す初期化部によって実行される。この初期化部２３は、前記アプリケーションプログラム９から渡されたレイヤ２接続かレイヤ３接続かを示す引数に基づき、初期化プロセスを実行する。この初期化プロセスでは、たとえば、この引数に応じて所定のトンネルブローカ２０およびＩｎｔｅｒＳｅｒｖｅｒ６が選択され、接続確立が行われる。また、上記初期化部２３は、上記引数に応じて、レイヤ２接続の場合には、前記レイヤ２，３、４プロトコルスタックのすべてを生成し、レイヤ３接続の場合には、レイヤ３および４プロトコルスタックを生成してレイヤ２プロコルスタックは生成しないように動作する。

また、レイヤ２接続において、ＭＡＣアドレスに関しては、本出願人が前に出願した国際出願ＰＣＴ／ＪＰ２００５／９２８０号（ＷＯ２００５／１１４９２６号公報）に開示されたネットワーク接続方法及び中継装置では、擬似的に２つのＭＡＣアドレスを用い、ＭＡＣアドレスの操作を行っていたが、本実施形態では、このような処理は不要である。

以上述べたように、国際出願ＰＣＴ／ＪＰ２００５／９２８０号では、仮想デバイスドライバとして見えるインタフェースを有するものであり、この仮想デバイスにはすべて同一のＭＡＣアドレスが割り当てられていたため、必要に応じてパケット上のＭＡＣアドレスの書き換えを行うことにより、ＭＡＣアドレスのユニーク性を確保するようにしていた。これに対して、本実施形態の中継通信モジュール８は実インタフェースと同様の 動作をするので、前記仮想イーサデバイスのようなMACアドレス書換えは不要である。 つまり、中継通信モジュール８はＩｎｔｅｒＳｅｒｖｅｒ６から取得したMACアドレスを自身にそのまま割当て、ARP要求・応答処理を実インタフェースと同じく行うものである。

すなわち、この発明によれば、前記ローカルネットワーク上のクライアント機器（ネットワーク家電２等）にインストールされたアプリケーションプログラム９を、インターネット上のサーバ（ＩｎｔｅｒＳｅｒｖｅｒ６）を通した仮想ネットワークに接続するために、前記クライアント機器にインストールされる中継通信モジュール８が提供される。この中継通信モジュール８は、前記アプリケーションプログラム９とこのコンピュータにインストールされたＯＳ７のローカル通信プロトコルスタック群（１１〜１４）との間に介在し、前記アプリケーションプログラム９用の仮想ネットワーク上のアドレスを保持し、かつ前記アプリケーションプログラム９からの仮想ネットワーク宛のパケットをトンネリング処理して前記ローカル通信プロトコルスタック（１１〜１４）を通じて前記ＩｎｔｅｒＳｅｒｖｅｒ６に渡すものである。そして、この中継通信モジュール８は、前記ローカル通信プロトコルスタック群（１１〜１４）とは独立した、前記アプリケーションプログラム９が仮想ネットワーク通じた通信をするのに必要なレイヤ２、３、４プロトコルスタック（１５〜１８）を備えている。

このような構成によれば、ＯＳ７のローカル通信プロトコルスタック（１１〜１４）とは独立したレイヤ２、３，４のプロトコルスタックを保持しているから、ＯＳ等による特定ネットワーク環境に依存せずに通信できるネットワークアプリケーション（アプリケーションプログラム９）を作成できる。すなわち、特定のプロトコルスタックが存在しないＯＳ上であっても、そのプロトコルを使用したアプリケーションソフトを実現することができる。例えば、ＩＰｖ６プロトコルが存在しないＯＳ環境下であっても、アプリケーションソフト単位でＩＰｖ６を使ったアプリケーションを作成することができるものである。

さらに言い換えると、前記アプリケーション９自体が本実施形態の中継通信モジュール８と一体となって、このクライアント機器（のインタフェース）とは独立した独自のＩＰアドレスを持つあたかも１つのデバイスとして実現できることになる。

次に、この実施形態に示された通信モジュール８およびアプリケーションプログラム９の実施例を説明する。

まず、図４に示すのは、以下の実施例１〜３における中継通信モジュール８を利用したＩＰｖ４／ＩＰｖ６アプリケーションの通信の形態である。すなわち、中継通信モジュール８はクライアントコンピュータ２上のＴＣＰ／ＩＰ（ＯＳ） を使用して、インターネット（ＩＰｖ４）を通じてＩｎｔｅｒＳｅｒｖｅｒ６に接続し、このＩｎｔｅｒＳｅｒｖｅｒ６からＩＰｖ６アドレスを取得する。ＩｎｔｅｒＳｅｒｖｅｒ６は、インターネット（ＩＰｖ４）ともう一方のインターネット（ＩＰｖ６）の中継装置として動作し、中継通信モジュール８はＩｎｔｅｒＳｅｒｖｅｒ６とトンネリングにより直接通信することでＩＰｖ６を使用することができるようになっている。したがって、クライアントコンピュータ２上にＩＰｖ６プロトコルが無い場合でも、アプリケーションプログラム９が中継通信モジュール８を使用することで、インターネット（ＩＰｖ６）上のコンテンツを保持するコンテンツサーバ２ｃに接続して通信を行うことができる。

図５に示すのは、本実施形態の中継通信モジュールを利用したＩＰｖ４／ＩＰｖ６アプリケーションプロキシを示す実施例である。

この例では、クライアント機器は、ＬＡＮ等のローカルネットワーク（ＩＰｖ４）に接続されたパーソナルコンピュータ（図にＡで示す）である。このクライアント機器Ａには、上記中継通信モジュールを備えたプロキシサーバプログラム（プロキシ）３１がインストールされている。

ユーザがこのクライアント機器Ａ上で、たとえばブラウザ３２や電子メールソフト３３を用い、このプロキシ３１に接続すると、このプロキシ３１は前記ＩｎｔｅｒＳｅｒｖｅｒ６を介した仮想ネットワークに接続する。このＩｎｔｅｒＳｅｒｖｅｒ６が、ＩＰｖ６ネットワークに接続されている場合、前記クライアント機器Ａは、このＩｎｔｅｒＳｅｒｖｅｒ６を介してＩｐｖ６ネットワークに接続できるから、ＩＰｖ６プロトコルが存在しないＯＳ環境下であっても、アプリケーションソフト（この場合はプロキシ３１）単位でＩＰｖ６アドレスを保持し、仮想ネットワークを通した通信を行うことができる。これにより、たとえばＩＰｖ６で動くサーバＢからＩＰｖ６下でしか取得できないコンテンツをダウンロード等することができる。

図６は、この実施例１におけるクライアント機器Ａ上の動作例を示す実際の画面図である。

図に３４で示すのは、ipconfig/allコマンドにより、このクライアント機器Ａのインタフェース一覧を表示させたウィンドウである。この一覧により、ＩＰｖ６プロトコルがこのクライアント機器ＡのＯＳ上にないことがわかる。

図に３５で示すのは、前記中継通信モジュールを内蔵したプロキシサーバプログラムの動作状態を示すウィンドウである。また、図に３６で示すのは、ブラウザ表示画面であり、ＩＰｖ６環下でしか閲覧することのできないコンテンツを含むサイト（www.kame.net）を表示させた状態を示すものである。ウィンドウ３５に示されるように、前記中継モジュール（プロキシ）は、この中継モジュール（プロキシ）に割り当てられたプライベートアドレスを用いて、前記ＩｎｔｅｒＳｅｒｖｅｒ６を介してwww.kame.netにアクセスしている。

前記www.kame.netでは、ＩＰｖ６で接続できた場合、サイト中の亀が動くように表示される。この図ではわかりづらいが、ブラウザ３６上の亀３７の頭がこちらを向いており、動いていることが確認できる。

前記実施形態では、アプリケーションプログラムはブラウザであったが、この実施例１では、プロキシプログラムである。このような構成によれば、ブラウザソフトを改変しなくても、プロキシの設定をするだけで、上記のような動作を得ることが可能になる。

図７は、前記プロキシアプリケーション３４がクライアント機器とは別のローカルネットワーク若しくはインターネット上の他のサーバＣに上に設けられている例である。このような構成によれば、クライアント機器Ａは、前記中継通信モジュールを備えない場合であっても、前記サーバＣのプロキシ３４を介して前記実施例１と同様に前記サーバＢからＩＰｖ６コンテンツをダウンロード等することができる。

図８は、この実施例２におけるクライアント機器Ａ上の動作例を示す実際の画面図である。

図中３７は、サーバＣ上のインタフェース一覧を表示させたウィンドウである。この一覧により、ＩＰｖ６プロトコルがこのサーバＣのＯＳ上にないことがわかる。

また、図に３８で示すのは、前記中継通信モジュールを内蔵したプロキシサーバプログラムの動作状態を示すウィンドウである。また、図に３９で示すのは、前記クライアント機器Ａ上のブラウザ表示画面であり、ＩＰｖ６環境下でしか閲覧することのできないコンテンツを含むサイト（www.kame.net）を表示させた状態を示すものである。ウィンドウ３８に示されるように、前記中継モジュール（プロキシ）は、この中継モジュール（プロキシ）に割り当てられたプライベートアドレスを用いて、前記ＩｎｔｅｒＳｅｒｖｅｒ６を介してwww.kame.netにアクセスしている。

このような構成によれば、クライアント機器に前記中継通信モジュールがインストールされていない場合であっても、上記クラインと機器にＩＰｖ６環境下でしかダウンロードできないコンテンツをダウロードすることができる。

図９は、本発明をインターネット電話等のＶｏＩＰプログラムに適用した例であり、クライアント機器の表示画面を示すものである。この実施例では、ユーザがクライアント機器Ａからインターネット上のウェブサーバＢに接続すると、このクライアント機器ＡにＶｏＩＰプログラムがウェブページとしてダウンロードされる。このＶｏＩＰプログラムＡがブラウザ３２によって実行されると、前記中継通信モジュールがこのクライアント機器Ａにインストールされ、この通信モジュールを介して前記ＩｎｔｅｒＳｅｒｖｅｒ６にトンネリング接続することによって、このＶｏＩＰプログラム（ブラウザ）に仮想ネットワーク上のＩＰアドレスが付与される。これによってこのＶｏＩＰプログラムを用いた通信を行うことができる。

ここで、図９中３７は、サーバＣ上のインタフェース一覧を表示させたウィンドウである。この一覧により、ＩＰｖ６プロトコルがこのサーバＣのＯＳ上にないことがわかる。また、図に４０で示すのが、ブラウザ３２上で実行された電話プログラムである。このプログラムには、ＯＳの通信インタフェースにかかわらず、固有のＩＰアドレスが割り付けられており前記ＩｎｔｅｒＳｅｒｖｅｒ６を介して双方向通信できるから、インターネット上でＶｏＩＰを送受信することができる。

ここで、ＶｏＩＰプログラムは、クライアントコンピュータにインストールされる電話・インスタントメッセンジャー等であるが、これに限るものではない。また、クライアント側の機器は、コンピュータに限らず、ハードウエアに組み込まれるアプリケーションであっても良い。

また、図１０は、この実施例のシステム構成をさらに詳しく図示したものであり、図１１は、このシステムによるＶｏＩＰアプリケーション間の通信確立工程を示した工程図である。

図１０中、ＩｎｔｅｒｅＳｅｒｖｅｒ６は、レイヤ３接続をサポートし、センター側システム４３との間にあって、ＳＩＰを利用したインターネット電話間、インスタントメッセンジャーシステム間の通信を制御するものである。すなわち、クライアント側のＶｏＩＰプログラム９は、ＳＩＰ等のシグナリングプロトコルと、音声等を処理するＲＴＰモジュール４２を持ち、前記センター側システム４３は、そのＳＩＰ等のシグナリングプロトコルを処理することが出来るようになっている。

２つのクライアントにそれぞれ設けられたＶｏＩＰプログラム間で音声通信を行う場合、ＲＴＰ等の音声通信は、クライアントアプリケーションのＲＴＰモジュール→クライアントの中継通信モジュール→クライアントのＯＳのＴＣＰＩＰ→ＩｎｔｅｒＳｅｒｖｅｒ→クライアントのＯＳのＴＣＰＩＰ→クライアントの中継通信モジュール→クライアントアプリケーションのＲＴＰモジュール、のような経路で処理される。

また、ＩｎｔｅｒＳｅｒｖｅｒに音声中継処理サーバを置き、音声中継処理サーバを経由する処理であっても良い。この場合の通信処理は、クライアントアプリケーションのＲＴＰモジュール→クライアントの中継通信モジュール→クライアントのＯＳのＴＣＰＩＰ→ＩｎｔｅｒＳｅｒｖｅｒ→音声中継処理サーバ→ＩｎｔｅｒＳｅｒｖｅｒ→クライアントの中継通信モジュール→クライアントアプリケーションのＲＴＰモジュールとなる。

ＳＩＰ等のプロトコルでは、クライアント側アプリケーションが、電話番号等の識別番号とＩＰアドレスの登録により、ロケーション管理（ＩＰアドレス）を行い、シグナリング時にアドレス解決をし、音声画像等のメディア通信する。よってＳＩＰ等のプロトコルでは、アドレス登録を含めたメソッドが用意される。

本発明では、この特徴を利用し、ＶｏＩＰアプリケーション９が中継通信モジュール８を包含し、電話番号等の識別番号とＩＰアドレスの管理をＩｎｔｅｒＳｅｒｖｅｒ６との間のトンネリングセッションの確立を利用して行う。

以下、この処理を、図１０および図１１を参照して詳しく説明する。

まず、図１０に示すように、前記ＩｎｔｅｒＳｅｒｖｅｒ６は、トンネル終端としての接続サーバ４４を備え、またセンター側システムとして、ＳＩＰプロキシサーバ４５、ユーザ情報管理サーバ４６、認証サーバ４７、プレゼンスサーバ４８を備えている。また、このセンター側システムは、プライベートネットワーク４９を介してＩＰアドレス管理ＤＢ５０及び外線発着信ゲートウェイ５１（及びこれを介して公衆回線網５２）に接続可能になっている。

すでに述べたように、クライアントコンピュータ２に設けられたＶｏＩＰアプリケーション９は、前記中継通信モジュール８により、ＯＳを介さずに、直接ＩｎｔｅｒＳｅｒｖｅｒ６の接続サーバ４４とトンネリング接続を実現する。このことで、このＶｏＩＰプログラム９に、仮想ネットワーク上のＩＰアドレスが割り当てられ、このＶｏＩＰプログラム９はこのＩＰアドレスを用い、前記トンネリングセッションを通して前記ＩｎｔｅｒＳｅｒｖｅｒ６のセンター側システム４３を介した音声通信が行える。

すなわち、図１１に示すように、ＶｏＩＰアプリケーションが前記中継通信モジュールにトンネリング初期化依頼を発すると（ステップＳ１）、前記中継通信モジュールは所定のブローカーサーバに接続して(ステップＳ２）、ＶｏＩＰ通信に利用するＩｎｔｅｒＳｅｒｖｅｒのＩＰアドレス（若しくはドメイン名）を受け取る(ステップＳ３）。このことで、中継通信モジュールはＩｎｔｅｒＳｅｒｖｅｒのアドレスを知ることができるから、識別番号とパスワードなどのログイン情報をもって前記ＩｎｔｅｒＳｅｒｖｅｒの接続サーバに接続し、認証サーバによる認証を受ける（ステップＳ５，Ｓ６）。認証が行われると、前記ＶｏＩＰアプリケーション（クライアント）用のＩＰアドレスの選定が行われ、これが、前記クライアントの中継通信モジュールに返される（ステップＳ７）。

このことで、中継通信モジュールは、受け取ったＩＰアドレスとＩｎｔｅｒＳｅｒｖｅｒ６のＩＰアドレスを用いて、このＩｎｔｅｒＳｅｒｖｅｒの接続サーバとの間に直接トンネリングセッションを確立する（ステップＳ８）。このトンネリングセッションが確立されると、前記ＩｎｔｅｒＳｅｒｖｅｒ６は、このクライアントのＩＰアドレスをクライアントの識別番号と関連付けて前記ＩＰアドレス管理サーバに登録する（ステップＳ９）。

このことで、トンネリング接続が確立されると共に、前記ＶｏＩｐアプリケーション９のＩＰアドレス及び識別番号が登録されて音声通信が可能になる。

すなわち、ＳＩＰプロキシサーバ等は、音声通信のＩＮＶＩＴＥを受けると（ステップＳ９）、ＩｎｔｅｒＳｅｒｖｅｒが登録したＩＰアドレス管理ＤＢを参照してシグナリング（ロケーション解決）を行うことが出来（ステップＳ１０）、ＳＩＰによる音声通信を中継することができる（ステップＳ１１）。

このような構成によれば、まず、前記ＶｏＩＰアプリケーション自体が本発明の中継通信モジュールと一体となって、このクライアント機器のインタフェースとは独立した独自のＩＰアドレスを持つあたかも１つのデバイスとして実現できることになる。さらに、ＳＩＰプロトコルで行うロケーション管理を中継通信モジュールとサーバ間で利用する上述のＩＰアドレスを利用して行うことで、通信及び管理の効率化を行える。

なお、この発明は上記一実施形態に限定されるものではなく、発明の要旨を変更しない範囲で種々変形可能である。

例えば、上記一実施形態では、前記アプリケーションプログラムは、ブラウザ、インターネット電話プログラムおよびプロキシプログラムであったが、これに限定されるものではなく、双方向通信を必要とするあらゆるアプリケーションプログラムに適用可能である。

また、上記一実施形態では、前記トンネルブローカがＩｎｔｅｒＳｅｒｖｅｒを選択するようになっていたが、各通信中継モジュールにあらかじめセットされていても良い。

また、この実施形態の通信モジュールは、１００％ユーザモードで動作する（普通ドライバのようなプログラムはカーネルモードで動く）ため、ＴＣＰ／ＩＰアプリケーションを作成することのできるＯＳなら非常に移植が簡単であり、上記一実施形態で挙げたＯＳ以外であっても、例えば、家電メーカが自社で採用している独自のＯＳや、レジスター等の業務機器に採用されているＯＳ等にも適用可能である。

この発明の一実施形態に係るネットワーク構成の例を示す図。 同じく通信中継モジュールを示す概略構成図。 同じく通信シーケンスを示すブロック図。 実施例１の概略構成を示す図 実施例１の動作状態を示すための画面図。 実施例２の概略構成を示す図 実施例２の動作状態を示すための画面図。 実施例３の概略構成を示す図 実施例３の動作状態を示すための画面図。 実施例３のシステム構成を詳しく示した図。 実施例３のＶｏＩＰアプリケーション間の通信確立工程を示した工程図。

符号の説明

１…ローカルネットワーク
２…クライアント機器
４…インターネット網
６…ＩｎｔｅｒＳｅｒｖｅｒ
７…ＯＳ
８…通信中継モジュール
１５…イーサネットリンク
１７…ＩＰレイヤ（ＩＰｖ４／ＩＰｖ６）
１８…ＴＣＰ／ＵＤＰレイヤ
１９…トンネリング・アプリケーション
２０…トンネルブローカ
３１…プロキシアプリケーション

Claims (11)

1. ローカルネットワーク上のクライアント機器にインストールされたアプリケーションプログラムを、インターネット上のサーバを通した仮想ネットワークに接続するために、前記クライアント機器にインストールされる通信モジュールであって、
   前記アプリケーションプログラムとこのコンピュータにインストールされたオペレーションシステムのローカル通信プロトコルスタック群との間に介在し、前記アプリケーションプログラム用の仮想ネットワーク上のアドレスを保持し、かつ前記アプリケーションからの仮想ネットワーク宛のパケットをトンネリング処理して前記ローカル通信プロトコルスタックを通じて前記サーバに渡すものであり、
   前記ローカル通信プロトコルスタック群とは独立した、前記アプリケーションプログラムが仮想ネットワーク通じた通信をするのに必要なプロトコルスタックを備えている
   ことを特徴とする通信モジュール。
2. 請求項１記載の通信モジュールにおいて、
   インターネット上のサーバのグローバルアドレスを記憶しており、
   このサーバのグローバルアドレスに基づき、この通信モジュールとサーバとの間にトンネリング接続を確立し、
   前記アプリケーションプログラムからの要求パケットを捕捉し、発信元アドレスとして前記アプリケーションプログラム用の仮想ネットワークアドレスを付したものをカプセリングし、前記トンネリング接続を介して前記サーバへ送出すると共に、
   前記ローカル通信プロトコルスタックを通して当該通信モジュール宛パケットをディカプセリングすると共に、このディカプセリングしたパケットを前記アプリケーションプログラムに渡す
   ことを特徴とする通信モジュール。
3. 請求項１記載の通信モジュールにおいて、
   この通信モジュールは、インターネット上に設けられたトンネル仲介サーバに接続してこの仲介サーバから前記サーバのグローバルアドレスを受け取るものである
   ことを特徴とする通信モジュール。
4. 請求項１記載の通信モジュールにおいて、
   この通信モジュールは、前記インターネット上のサーバから前記アプリケーションプログラム用の仮想ネットワーク上のＩＰアドレスを受け取り保持するものである
   ことを特徴とする通信モジュール。
5. 請求項１記載の通信モジュールにおいて、
   この通信モジュールは、前記インターネット上のサーバから前記アプリケーションプログラム用の仮想ネットワーク接続用のＭＡＣアドレスとＩＰアドレスを受け取り保持するものである
   ことを特徴とする通信モジュール。
6. 請求項１記載の通信モジュールにおいて、
   この通信モジュールは、前記アプリケーションプログラムによって呼び出し可能なライブラリプログラムとして提供されていることを特徴とする通信モジュール。
7. 請求項１記載の通信モジュールにおいて、
   初期化部を有し、この初期化部は、
   サーバとレイヤ２接続する場合には、前記レイヤ２，３、４プロトコルスタックのすべてを生成し、
   前記サーバとレイヤ３接続する場合には、レイヤ３および４プロトコルスタックを生成し、レイヤ２プロコルスタックは生成しない
   ように構成されていることを特徴とする通信モジュール。
8. コンピュータ上で実行され、インターネットに接続して所定の処理を実行するアプリケーションプログラムであって、通信インタフェースとして、請求項１に記載の通信モジュールを呼び出して組み込むための命令を備え、前記コンピュータとは独立したＩＰアドレスをこのアプリケーションプログラムが持つように構成されたことを特徴とするアプリケーションプログラム。
9. 請求項８記載のアプリケーションプログラムにおいて、
   このアプリケーションプログラムは、インターネット上のサーバを通した仮想ネットワークに接続するＶｏｉｐプログラムであることを特徴とするアプリケーションプログラム。
10. 請求項８記載のアプリケーションプログラムにおいて、
    このアプリケーションプログラムは、クライアント機器をインターネット上のサーバを通した仮想ネットワークに接続させるプロキシであることを特徴とするアプリケーションプログラム。
11. 請求項８記載のアプリケーションプログラムにおいて、
    ＶｏＩＰアプリケーションプログラムであり、ＳＩＰ等のアドレス管理を必要とするプロトコルを利用し、その際のアドレス管理をトンネリングプロトコルでのＩＰアドレス管理と共用することを特徴とするアプリケーションプログラム。

Images