JPH08227387A - 通信方法および通信システム - Google Patents

Abstract

(57)【要約】 【目的】 通信プロトコルの変更に伴い、ＯＳに組み込
むデバイスドライバを自動的に変更することができるよ
うにする。 【構成】 所定の通信プロトコルに対応したパケット
が、ディストリビュータ１にを介して、第１ドライバ記
憶部２の第１ネットワークドライバ２ａにより受信さ
れ、そのパケットのデータがプロトコルマネージャ４に
より読み出される。読み出されたデータが新しい通信プ
ロトコルに対応したデバイスドライバのオブジェクトコ
ードである場合、それを第２ドライバ記憶部３に第２ネ
ットワークドライバ３ａとして記憶し、以降、新しい通
信プロトコルに従ったパケットは、第２ネットワークド
ライバ３ａにより受信され、プロトコルマネージャ４に
よりそのデータが読み出される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、通信方法および通信シ
ステムに関し、例えば、通信プロトコルが変更される可
能性のある通信路を介して所定の情報の送受信を行う際
に用いて好適な通信方法および通信システムに関する。

【０００２】

【従来の技術】従来、端末間で、所定のデータの送受信
を行う場合、各端末には、予め、所定の通信プロトコル
に対応した所定のデバイスドライバ（ドライバソフトウ
ェア）をインストールしておく。そして、このドライバ
ソフトウェアにより、所定の通信プロトコルに従って、
端末間でデータの送受信が所定の通信路を介して行われ
る。

【０００３】従って、通信プロトコルが変更される場
合、端末の管理者は、変更後の通信プロトコルに対応し
たドライバソフトウェアを前もって入手し、通信プロト
コルの変更に合わせて、所定の時刻に、手作業によっ
て、そのドライバソフトウェアを所定の端末にインスト
ールしている。

【０００４】これにより、各端末のドライバソフトウェ
アは、変更後の通信プロトコルに対応したものに入れ替
えられ、その後、変更後の通信プロトコルにより所定の
データの送受信を行うことができる。

【０００５】

【発明が解決しようとする課題】このように、従来よ
り、通信プロトコルの変更に際しては、各端末のドライ
バソフトウェアの入れ替えを、手作業によって、各端末
毎に行わなければならず、煩わしい課題があった。

【０００６】本発明はこのような状況に鑑みてなされた
ものであり、通信プロトコルの変更に伴うドライバソフ
トウェアの入れ替え作業を、手作業によることなく各端
末が自動的に行うことができるようにするものである。

【０００７】

【課題を解決するための手段】請求項１に記載の通信方
法は、通信プロトコルに従って、端末間における所定の
パケットの送受信を制御する通信方法において、通信プ
ロトコルの所定のものに対応する所定のドライバソフト
ウェアを記憶し、端末の所定のものからのパケットを、
所定のドライバソフトウェアに供給し、端末の所定のも
のからの通信プロトコルの所定のものに対応するパケッ
トを受信し、所定のドライバソフトウェアからのパケッ
トに含まれるデータを読み出し、データが、通信プロト
コルの他の所定のものに対応する他の所定のドライバソ
フトウェアであるか否かを判定し、判定結果に従って、
データを、他の所定のドライバソフトウェアとして、所
定のドライバソフトウェアとは別に記憶し、端末の所定
のものからのパケットを、他の所定のドライバソフトウ
ェアに供給し、端末の所定のものからの通信プロトコル
の他の所定のものに対応するパケットを受信し、他の所
定のドライバソフトウェアからのパケットに含まれるデ
ータを読み出すことを特徴とする。

【０００８】また、所定のドライバソフトウェアと、他
の所定のドライバソフトウェアの双方が記憶された場合
において、端末の所定のものからの、通信プロトコルの
所定のものに対応するパケットは、所定のドライバソフ
トウェアにより受信され、端末の所定のものからの、通
信プロトコルの他の所定のものに対応するパケットは、
他の所定のドライバソフトウェアにより受信されるよう
にすることができる。

【０００９】また、通信プロトコルの他の所定のものに
対応するパケットを受信した場合、通信プロトコルの所
定のものに対応する所定のドライバソフトウェアを消去
するようにすることができる。

【００１０】請求項４に記載の通信システムは、通信プ
ロトコルに従って、端末間で所定のパケットの送受信を
行う通信システムにおいて、通信プロトコルの所定のも
のに対応する所定のドライバソフトウェアを記憶する第
１記憶手段と、端末の所定のものからのパケットを、所
定のドライバソフトウェアに供給する第１供給手段と、
所定のドライバソフトウェアにより受信された端末の所
定のものからの通信プロトコルの所定のものに対応する
パケットに含まれるデータを読み出す第１読み出し手段
と、データが、通信プロトコルの他の所定のものに対応
する他の所定のドライバソフトウェアであるか否かを判
定する判定手段と、判定結果に従って、データを、他の
所定のドライバソフトウェアとして、所定のドライバソ
フトウェアとは別に記憶する第２記憶手段と、端末の所
定のものからのパケットを、他の所定のドライバソフト
ウェアに供給する第２供給手段と、他の所定のドライバ
ソフトウェアにより受信された端末の所定のものからの
通信プロトコルの他の所定のものに対応するパケットに
含まれるデータを読み出す第２読み出し手段とを備える
ことを特徴とする。

【００１１】また、所定のドライバソフトウェアと、他
の所定のドライバソフトウェアの双方が記憶された場合
において、端末の所定のものからの、通信プロトコルの
所定のものに対応するパケットは、第１記憶手段に記憶
された所定のドライバソフトウェアにより受信され、端
末の所定のものからの、通信プロトコルの他の所定のも
のに対応するパケットは、第２記憶手段に記憶された他
の所定のドライバソフトウェアにより受信されるように
することができる。

【００１２】さらに、第２記憶手段に記憶された他の所
定のドライバソフトウェアにより、通信プロトコルの他
の所定のものに対応するパケットが受信された場合、第
１記憶手段に記憶された、通信プロトコルの所定のもの
に対応する所定のドライバソフトウェアを消去する消去
手段をさらに設けるようにすることができる。

【００１３】

【作用】請求項１または４に記載の通信方法または通信
システムにおいては、所定の通信プロトコルに対応する
所定のパケットのデータが、他の通信プロトコルに対応
するドライバソフトウェアであると判定された場合、そ
れを記憶し、それ以降、他の通信プロトコルに対応した
所定のパケットを、このドライバソフトウェアにより受
信する。従って、送信側の端末から、所定のパケットに
より、所定の通信プロトコルに対応するドライバソフト
ウェアを送信することにより、受信側の端末のドライバ
ソフトウェアを、その通信プロトコルに対応したドライ
バソフトウェアに変更することができる。

【００１４】請求項２または５に記載の通信方法または
通信システムにおいては、所定の通信プロトコルに対応
したパケットは、その通信プロトコルに対応したドライ
バソフトウェアにより受信され、他の所定の通信プロト
コルに対応したパケットは、その通信プロトコルに対応
したドライバソフトウェアにより受信される。従って、
２つの通信プロトコルのそれぞれに対応したドライバソ
フトウェアを記憶している場合、いずれの通信プロトコ
ルに対応したパケットでも受信可能なマルチプロトコル
とすることができる。

【００１５】請求項３または６に記載の通信方法または
通信システムにおいては、新しい通信プロトコルに対応
したドライバソフトウェアが記憶されると、古い通信プ
ロトコルに対応したドライバソフトウェアが消去され
る。従って、さらに新しい通信プロトコルへの変更が容
易にできる。

【００１６】

【実施例】図１は、本発明の通信方法および通信システ
ムを適用した放送システムの一実施例の構成を示すブロ
ック図である。センタ２００から、放送電波を介して送
信された所定の通信プロトコルに対応する所定のパケッ
トは、放送衛星３００を介して、端末４００に供給され
る。端末４００に供給されたパケットは、デコーダ５０
０により対応する信号に変換された後、ＯＳ（オペレー
ティングシステム）１００に供給される。

【００１７】図２に示すように、端末４００のＯＳ１０
０は、階層構造をなし、最も下の階層には、デバイスド
ライバ（ドライバソフトウェア）群が存在する。第１ド
ライバ記憶部２（第１記憶手段）に記憶されている第１
ネットワークドライバ２ａ、第２ドライバ記憶部３（第
２記憶手段）に記憶されている第２ネットワークドライ
バ３ａは、それぞれ所定のネットワークと接続するため
に用いられる。また、それ以外のデバイスドライバ（他
のドライバ）５は、例えば、ディスクドライブ、または
テープドライブ等に対応し、それらのデバイスとの間で
所定のデータの入出力を行うようになされている。この
ように、通常、デバイスドライバは、個々のハードウェ
ア毎に存在する。

【００１８】第１ネットワークドライバ２ａ、および第
２ネットワークドライバ３ａの下に位置するディストリ
ビュータ１（第１供給手段、第２供給手段）は、デバイ
スドライバが複数存在するような場合、デコーダ５００
からの信号を、第１ネットワークドライバ２ａ、および
第２ネットワークドライバ３ａにそれぞれ分配するよう
になされている。通常、現在広く市販されているＯＳの
多くは、このような構造にはなっていない。

【００１９】また、プロトコルマネージャ４（第１読み
出し手段、第２読み出し手段、判定手段、消去手段）
も、現在広く市販されているＯＳの多くには存在しない
ものである。このプロトコルマネージャ４は、後述する
ように、通信プロトコルが変更されたときに、第１ネッ
トワークドライバ２ａまたは第２ネットワークドライバ
３ａを他の所定のネットワークドライバと入れ替える処
理を行うようになされている。

【００２０】カーネル６は、現在広く使用されている一
般的なＯＳと同様に、システムコールのサポート、メモ
リ管理、およびプロセス管理等を行うようになされてい
る。このカーネル６は、第１ネットワークドライバ２ａ
または第２ネットワークドライバ３ａより供給されたデ
ータに関して、プロトコルマネージャ４を介すことによ
り、このようにネットワークドライバが複数存在するよ
うな場合でも、どのネットワークドライバから供給され
たものであるかを意識する必要がない。

【００２１】カーネル６の上位層には、アプリケーショ
ン７乃至１０が存在する。この場合、アプリケーション
にはシェルも含まれるものとする。このアプリケーショ
ンのさらに上位層において、スクリプトが走ることもあ
るが、ここではその図示及び説明は省略する。

【００２２】従って、放送衛星３００を介して受信され
たセンタ２００からの所定のパケットは、デコーダ５０
０を介して所定の信号に変換された後、まず、ディスト
リビュータ１に供給され、そこから第１ネットワークド
ライバ２ａまたは第２ネットワークドライバ３ａにそれ
ぞれ供給される。さらに、プロトコルマネージャ４を介
して、その上位層であるカーネル６に供給される。カー
ネル６に供給されたパケットは、さらにその上位層のア
プリケーション７乃至１０のいずれかに供給され、そこ
で所定の処理が施される。

【００２３】例えば、標準ネットワーク・アーキテクチ
ャとしてのＯＳＩ（Open System Interconnection）に
おいては、最下層から順に、物理レイヤ、データリンク
レイヤ、ネットワークレイヤ、トランスポートレイヤ、
セッションレイヤ、プレゼンテーションレイヤ、および
アプリケーションレイヤの７つのレイヤが定義されてい
る。

【００２４】ここでは、以下、ネットワークレイヤのア
ドレスのビット幅を変更する場合について説明する。こ
のような変更は、例えば、所定のネットワークに接続さ
れているホストの数が増え、各ホストの識別番号（Ｉ
Ｄ）を示す、パケットの中の所定の制御情報のビット数
が不足したような場合に行われることが考えられる。

【００２５】まず、ネットワークレイヤのパケットの構
造について説明する。なお、この場合、物理レイヤ、デ
ータリンクレイヤにおけるパケットの構造は、一般に用
いられているものの構造と同様であるので、その図示お
よび説明は省略する。

【００２６】また、一般的にデータリンクレイヤまでは
ハードウェアで処理されるという前提に立つものとす
る。従って、図２に示したディストリビュータ１が受け
取るパケットは、図３に示したネットワークレイヤのパ
ケットの構造を有することになる。

【００２７】図３（ａ）および図３（ｂ）は、それぞれ
ネットワークレイヤでのパケットの構造を示す図であ
り、図３（ａ）は、変更前の通信プロトコルに対応した
パケットの構造を示し、図３（ｂ）は、変更後の通信プ
ロトコルに対応したパケットの構造を示している。

【００２８】図３（ａ）において、データ部（Ｄａｔ
ａ）２６には、ヘッダ部（Ｈｅａｄｅｒ）２７が付加さ
れている。ヘッダ部２７は、バージョン（Ｖｅｒｓｉｏ
ｎ）２１、オフセット（Ｏｆｆｓｅｔ）２２、トータル
レングス（Ｔｏｔａｌ Ｌｅｎｇｔｈ）２３、ソースア
ドレス（Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ）２４、および
デスティネーションアドレス（Ｄｅｓｔｉｎａｔｉｏｎ
Ａｄｄｒｅｓｓ）２５から構成されている。

【００２９】バージョン２１は、パケットのバージョン
を示し、バージョンによって、パケットの構造が異なっ
ている。従って、例えば、図３（ａ）に示した変更前の
通信プロトコルにおけるバージョン２１と、後述する変
更後の通信プロトコルのバージョン３１は異なる値を有
している。

【００３０】また、オフセット２２は、データ部２６の
先頭までのオフセットアドレスを有し、トータルレング
ス２３は、パケット全体の長さを有している。ソースア
ドレス２４には、パケットを送信する端末（ホストコン
ピュータ）、この場合、センタ２００のアドレスが記述
されており、デスティネーションアドレス２５には、パ
ケットの送信先の端末（ホストコンピュータ）、この場
合、端末４００のアドレスが記述されている。

【００３１】一方、図３（ｂ）に示した変更後の通信プ
ロトコルに対応したパケットの構造においても、図３
（ａ）に示した変更前の通信プロトコルに対応したパケ
ットの場合と同様に、データ部（Ｄａｔａ）３６には、
ヘッダ部（Ｈｅａｄｅｒ）３７が付加されている。ヘッ
ダ部３７は、バージョン（Ｖｅｒｓｉｏｎ）３１、オフ
セット（Ｏｆｆｓｅｔ）３２、トータルレングス（Ｔｏ
ｔａｌ Ｌｅｎｇｔｈ）３３、ソースアドレス（Ｓｏｕ
ｒｃｅ Ａｄｄｒｅｓｓ）３４、およびデスティネーシ
ョンアドレス（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓ
ｓ）３５から構成されている。

【００３２】また、バージョン３１は、パケットのバー
ジョンを示し、バージョンによって、パケットの構造が
異なっている。従って、上述したように、図３（ａ）に
示した変更前の通信プロトコルにおけるパケットのバー
ジョン２１と、変更後の通信プロトコルにおけるパケッ
トのバージョン３１は異なる値を有している。

【００３３】また、オフセット３２は、データ部３６の
先頭までのオフセットアドレスを有し、トータルレング
ス３３は、パケット全体の長さを有している。ソースア
ドレス３４には、パケットを送信する端末、この場合、
センタ２００のアドレスが記述されており、デスティネ
ーションアドレス３５には、パケットの送信先の端末、
この場合、端末４００のアドレスが記述されている。

【００３４】通信プロトコルが変更される前、図３
（ａ）に示すように、ソースアドレス２４、およびデス
ティネーションアドレス２５の大きさは、それぞれ３２
ビットであるが、変更後は、図３（ｂ）に示すように、
それぞれ６４ビット（＝３２ビット×２）となってい
る。このように、通信プロトコルの変更に伴い、パケッ
トのフォーマットが変更される場合、変更後の新たな通
信プロトコルに対応したパケットを受信するためには、
変更後の新たな通信プロトコルに対応したパケットのフ
ォーマットに対応したデバイスドライバを、前もって、
ＯＳ１００に用意しておかなければならない。

【００３５】次に、図４を参照して、通信プロトコルの
変更に伴って、デバイスドライバを変更する方法につい
て説明する。図４において、横軸は時間軸を示してお
り、左から右に向かって時間が経過するものとする。最
初は変更前の通信プロトコルに対応するパケット４１乃
至４３が端末間（この場合、センタ２００と端末４００
の間）で送受信され、所定の時刻に、送信側の端末（セ
ンタ２００）から通信プロトコルの変更を要求するプロ
トコル変更要求パケット４４が送信される。このプロト
コル変更要求パケット４４には、後述するように、変更
後の新しい通信プロトコルに対応した所定のデバイスド
ライバが含まれている。

【００３６】このプロトコル変更要求パケット４４が受
信側の端末４００により受信されると、受信側の端末４
００のＯＳ１００は、このパケットに含まれるデバイス
ドライバを読み込み、それを図２の第１ドライバ記憶部
２、または第２ドライバ記憶部３のいずれかに記憶させ
る。例えば、変更前の現在の通信プロトコルに対応した
デバイスドライバが第１ドライバ記憶部２に格納されて
いる場合、変更後の新しい通信プロトコルに対応したデ
バイスドライバを第２ドライバ記憶部３に記憶させる。

【００３７】このように、第１ドライバ記憶部２に、変
更前の通信プロトコルに対応したデバイスドライバが格
納され、第２ドライバ記憶部３に、変更後の通信プロト
コルに対応したデバイスドライバが格納されるようにす
ることにより、この端末は、新旧（変更前と変更後の）
両方の通信プロトコルに対応することができる。なお、
第１ドライバ記憶部２に、変更後の通信プロトコルに対
応したデバイスドライバが格納され、第２ドライバ記憶
部３に、変更前の通信プロトコルに対応したデバイスド
ライバが格納されるようにしても、同様に、変更前と変
更後の両方の通信プロトコルに対応することができる。

【００３８】例えば、第１ドライバ記憶部２に、変更前
の通信プロトコルに対応したデバイスドライバ（第１ネ
ットワークドライバ２ａ）が格納され、第２ドライバ記
憶部３に、変更後の通信プロトコルに対応したデバイス
ドライバ（第２ネットワークドライバ３ａ）が格納され
ている場合、変更前の通信プロトコルに対応したパケッ
トが受信側の端末４００のＯＳ１００により受信される
と、ディストリビュータ１により、それが第１ドライバ
記憶部２の第１ネットワークドライバ２ａ、および第２
ドライバ記憶部３の第２ネットワークドライバ３ａにそ
れぞれ供給される。

【００３９】第１ネットワークドライバ２ａに供給され
たネットワークレイヤのパケットは、そのヘッダ部２７
のバージョン２１が読み出され、第１ネットワークドラ
イバ２ａに対応する通信プロトコルのパケットであるか
否かが判定される。この場合、第１ネットワークドライ
バ２ａは、変更前の通信プロトコルに対応したデバイス
ドライバであるので、このパケットは、第１ネットワー
クドライバ２ａに対応する変更前の通信プロトコルのパ
ケットであると判定され、データ部２６がプロトコルマ
ネージャ４に供給される。

【００４０】一方、第２ネットワークドライバ３ａにお
いても同様に、そこに供給されたネットワークレイヤの
パケットのヘッダ部２７のバージョン２１が読み出さ
れ、第２ネットワークドライバ３ａに対応する通信プロ
トコルのパケットであるか否かが判定される。この場
合、第２ネットワークドライバ３ａは、変更後の通信プ
ロトコルに対応したデバイスドライバであるので、この
パケットは、第２ネットワークドライバ３ａに対応する
変更後の通信プロトコルのパケットではないと判定さ
れ、何も処理が行われない。

【００４１】同様に、変更後の通信プロトコルに対応し
たパケットが受信側の端末のＯＳ１００により受信され
ると、ディストリビュータ１により、それが第１ネット
ワークドライバ２ａおよび第２ネットワークドライバ３
ａにそれぞれ供給される。

【００４２】第１ネットワークドライバ２ａに供給され
たパケットは、そのヘッダ部３７のバージョン３１が読
み出され、第１ネットワークドライバ２ａに対応する通
信プロトコルのパケットであるか否かが判定される。こ
の場合、第１ネットワークドライバ２ａは、変更前の通
信プロトコルに対応したデバイスドライバであるので、
このパケットは、第１ネットワークドライバ２ａに対応
する変更前の通信プロトコルのパケットではないと判定
され、何も処理が行われない。

【００４３】一方、第２ネットワークドライバ３ａにお
いても同様に、そこに供給されたパケットのヘッダ部３
７のバージョン３１が読み出され、第２ネットワークド
ライバ３ａに対応する通信プロトコルのパケットである
か否かが判定される。この場合、第２ネットワークドラ
イバ３ａは、変更後の通信プロトコルに対応したデバイ
スドライバであるので、このパケットは、第２ネットワ
ークドライバ３ａに対応する変更後の通信プロトコルの
パケットであると判定され、データ部３６がプロトコル
マネージャ４に供給される。

【００４４】このようにして、変更前および変更後の両
方の通信プロトコルに対応したパケットを受信すること
ができる（マルチプロトコル）。その後、送信側である
センタ２００は、通信路やホストコンピュータの性能な
どの不確定要素を考慮して、すぐに変更後の新しい通信
プロトコルに対応したパケットを送信するのではなく、
所定の十分な時間だけおいた後、変更後の新しい通信プ
ロトコルに対応したパケットを送信するようにする。

【００４５】即ち、図４に示すように、プロトコル変更
要求パケット４４の送信後も、所定の十分な時間だけ、
変更前の通信プロトコルに対応したパケット４５を送信
し、その後、変更後の通信プロトコルに対応したパケッ
ト４６，４７を送信するようにする。

【００４６】変更後の新しい通信プロトコルに対応した
パケットを受信した受信側の端末４００は、それ以降、
送信側（センタ２００）は変更前の古い通信プロトコル
に対応したパケットを送信しないものとみなし、変更前
の古い通信プロトコルに対応したネットワークドライバ
を消去する。いまの場合、第１ドライバ記憶部２に記憶
された第１ネットワークドライバ２ａが消去される。

【００４７】このようにして、通信プロトコルの変更に
伴って、変更後の通信プロトコルに対応するネットワー
クドライバを、自動的にＯＳ１００に組み込むことがで
きる。また、古い通信プロトコルに対応したネットワー
クドライバを、自動的にＯＳ１００から消去することが
できる。

【００４８】次に、図５を参照して、トランスポートレ
イヤのパケットの構造について説明する。トランスポー
トレイヤのパケットには、図５（ａ）および図５（ｂ）
に示すように、２種類のパケットがある。図５（ａ）
は、プロトコル変更要求パケット４４のトランスポート
レイヤの構成を示しており、図５（ｂ）は、通常のパケ
ット４１乃至４３のトランスポートレイヤの構成を示し
ている。また、これらのパケットは、図３におけるデー
タ部２６に対応している。

【００４９】プロトコル変更要求パケット４４は、ヘッ
ダ部（Ｈｅａｄｅｒ）５８と、データ部５７より構成さ
れ、ヘッダ部５８は、さらに、ソースポート（Ｓｏｕｒ
ｃｅＰｏｒｔ）５１、デスティネーションポート（Ｄｅ
ｓｔｉｎａｔｉｏｎ Ｐｏｒｔ）５２、データタイプ
（Ｄａｔａ Ｔｙｐｅ）５３、データエンドフラグ（Ｄ
ａｔａ Ｅｎｄ Ｆｌａｇ）５５、およびトータルレン
グス（Ｔｏｔａｌ Ｌｅｎｇｔｈ）５６からなる。ま
た、未使用領域（Ｒｅｓｅｒｖｅｄ）５４は、将来の拡
張のため、確保されている。

【００５０】ソースポート５１には、パケットを送信し
たプロセスのプロセス番号がセットされ、デスティネー
ションポート５２には、パケットの送信先のプロセスの
プロセス番号がセットされる。データエンドフラグ５５
には、値１または値０がセットされ、値１がセットされ
ている場合、このパケットが、いま送信している一連の
関連するパケットの最後のパケットであることを示し、
値０がセットされている場合、このパケットの後に、さ
らに関連するパケットが続くことを示す。さらに、トー
タルレングス５６は、このパケットの全長を示すように
なされている。

【００５１】また、データ部５７には、変更後の通信プ
ロトコルに対応した所定のデバイスドライバのオブジェ
クトコードがセットされるようになされている。

【００５２】通常のパケット４１乃至４３は、プロトコ
ル変更要求パケット４４の場合と同様に、ヘッダ部（Ｈ
ｅａｄｅｒ）６８と、データ部６７より構成され、ヘッ
ダ部６８は、さらに、ソースポート（Ｓｏｕｒｃｅ Ｐ
ｏｒｔ）６１、デスティネーションポート（Ｄｅｓｔｉ
ｎａｔｉｏｎ Ｐｏｒｔ）６２、データタイプ（Ｄａｔ
ａ Ｔｙｐｅ）６３、データエンドフラグ（Ｄａｔａ
Ｅｎｄ Ｆｌａｇ）６５、およびトータルレングス（Ｔ
ｏｔａｌ Ｌｅｎｇｔｈ）６６からなる。また、未使用
領域（Ｒｅｓｅｒｖｅｄ）６４は、将来の拡張のため、
確保されている。

【００５３】ソースポート６１には、パケットを送信し
たプロセスのプロセス番号がセットされ、デスティネー
ションポート６２には、パケットの送信先のプロセスの
プロセス番号がセットされる。データエンドフラグ６５
には、値１または値０がセットされ、値１がセットされ
ている場合、このパケットが、いま送信している一連の
関連するパケットの最後のパケットであることを示し、
値０がセットされている場合、このパケットの後に、さ
らに関連するパケットが続くことを示す。さらに、トー
タルレングス６６は、このパケットの全長を示すように
なされている。

【００５４】また、データ部６７には、通常のデータが
セットされるようになされている。

【００５５】パケットが、プロトコル変更要求パケット
であるか、通常のパケットであるかは、上述したヘッダ
部５８に含まれるデータタイプ５３に設定されている
値、またはヘッダ部６８に含まれるデータタイプ６３に
設定されている値により決定される。例えば、図５
（ａ）に示したプロトコル変更要求パケット４４のヘッ
ダ部５８のデータタイプ５３には、値ＦＦＦＦ（１６
進）が設定され、図５（ｂ）に示した通常のパケット４
１乃至４３などのヘッダ部６８のデータタイプ６３に
は、値０が設定されている。

【００５６】従って、パケットのヘッダ部のデータタイ
プに値ＦＦＦＦが設定されている場合、そのパケットは
プロトコル変更要求パケットであるとし、パケットのヘ
ッダ部のデータタイプに値０が設定されている場合、そ
のパケットは通常のパケットであるとすることができ
る。ここで、パケットは２種類しか存在しないので、本
来であれば、データタイプ５３またはデータタイプ６３
は、１ビットあれば十分であるが、将来の拡張のため、
１６ビット分設けるようにしている。

【００５７】上述したように、所定のパケットのヘッダ
部のデータタイプに値ＦＦＦＦがセットされている場
合、そのパケットのデータ部には、変更後の通信プロト
コルに対応する所定のデバイスドライバのオブジェクト
コードがセットされていることになる。

【００５８】次に、受信側の端末４００が、上述したプ
ロトコル変更要求パケット４４を受信し、現在、受信側
の端末４００のＯＳ１００に組み込まれているデバイス
ドライバ（ネットワークドライバ）を、新たな通信プロ
トコルに対応した所定のデバイスドライバに変更する場
合の処理について説明する。ここでは、第１ドライバ記
憶部２に記憶されている第１ネットワークドライバ２ａ
が、変更前の通信プロトコルに対応しているものとす
る。

【００５９】最初に、図２のＯＳ１００のディストリビ
ュータ１により、放送衛星３００を介して受信されたセ
ンタ２００からの所定のパケットが、第１ネットワーク
ドライバ２ａおよび第２ネットワークドライバ３ａにそ
れぞれ供給される。

【００６０】次に、第１ネットワークドライバ２ａおよ
び第２ネットワークドライバ３ａにより、ディストリビ
ュータ１より供給されたパケットのバージョンが読み出
される。そして、このバージョンに対応するネットワー
クドライバ（いまの場合、第１ネットワークドライバ２
ａ）により、ネットワークレイヤ、およびトランスポー
トレイヤにおける所定の処理が行われ、トランスポート
レイヤのパケットのデータ部５７、データタイプ５３、
およびデータエンドフラグ５５がそれぞれプロトコルマ
ネージャ４に供給される。

【００６１】次に、図５のフローチャートを参照して、
プロトコルマネージャ４の処理について説明する。最初
に、ステップＳ１において、第１ネットワークドライバ
２ａより供給されたデータ部５７、データタイプ５３、
およびデータエンドフラグ５５を読み出し、ステップＳ
２に進む。

【００６２】ステップＳ２においては、ステップＳ１に
おいて受信したデータ部５７、データタイプ５３、およ
びデータエンドフラグ５５が、新たに追加されたネット
ワークドライバからのものか否かが判定される。新たに
追加されたネットワークドライバからのものではないと
判定された場合、ステップＳ４に進む。一方、新たに追
加されたネットワークドライバからのものであると判定
された場合、ステップＳ３に進み、変更前に使用されて
いたデバイスドライバが消去される。いまの場合、まだ
新たなネットワークドライバは追加されていないので、
新たに追加されたネットワークドライバからのものでは
ないと判定されステップＳ４に進む。

【００６３】ステップＳ４においては、第１ネットワー
クドライバ２ａより供給されたデータタイプ５３から、
第１ネットワークドライバ２ａより供給されたデータ部
５７のデータが、新たな通信プロトコルに対応したネッ
トワークドライバのオブジェクトコードであるか否かが
判定される。

【００６４】即ち、データタイプに値０がセットされ、
データが通常のデータであると判定された場合、ステッ
プＳ５に進み、このデータをカーネル６に渡し、処理を
終了する。一方、データタイプに値ＦＦＦＦ（１６進
数）がセットされ、データが新たな通信プロトコルに対
応したネットワークドライバのオブジェクトコードであ
ると判定された場合、ステップＳ６に進む。いまの場
合、新たな通信プロトコルに対応したネットワークドラ
イバのオブジェクトコードであると判定され、ステップ
Ｓ６に進む。

【００６５】ステップＳ６においては、データエンドフ
ラグの値が１であるか否かが判定される。いまの場合、
データエンドフラグの値が１ではない（値０である）と
判定され、ステップＳ７に進み、今まで読み込んだオブ
ジェクトコードが、所定のバッファに格納され、処理を
終了する。

【００６６】そして、上述した処理が繰り返され、ステ
ップＳ６において、データエンドフラグ５５の値が１で
あると判定された場合、関連するパケットの受信が終了
し、新たな通信プロトコルに対応したネットワークドラ
イバのオブジェクトコードの全てが、所定のバッファに
蓄積されたものとみなされ、ステップＳ８に進む。

【００６７】ステップＳ８においては、ステップＳ７に
おいて、所定のバッファに蓄積されたオブジェクトコー
ドが読み出され、新たな通信プロトコルのネットワーク
ドライバとして、ＯＳ１００にインストールされ（この
場合、第２ドライバ記憶部３に、第２ネットワークドラ
イバ３ａが格納され）、処理を終了する。

【００６８】ＯＳ１００のネットワークドライバが、変
更後の通信プロトコルに対応したものに書き換えられた
後、所定のパケットを受信すると、上述した場合と同様
にして、ステップＳ１において、そのパケットのデータ
が読み出される。次に、ステップＳ２に進み、そのデー
タが、新たに追加されたネットワークドライバから供給
されたものか否かが判定される。いまの場合、新たに追
加されたネットワークドライバから供給されたので、新
たに追加されたネットワークドライバから供給されたも
のと判定され、ステップＳ３に進み、変更前に使用され
ていた古いネットワークドライバ、この場合第１ドライ
バ記憶部２に記憶されている第１ネットワークドライバ
２ａが消去され、ステップＳ４に進む。

【００６９】ステップＳ４においては、上述したよう
に、データタイプの値がＦＦＦＦ（１６進数）であるか
否かが判定される。いまの場合、データタイプの値がＦ
ＦＦＦではないと判定され、ステップＳ５に進み、デー
タをカーネル６に渡し、処理を終了する。

【００７０】このようにして、所定の通信路上の通信プ
ロトコルが変更された場合でも、パケットを受信する端
末側においては、端末が自動的に変更後の通信プロトコ
ルに対応した所定のデバイスドライバを端末のＯＳにイ
ンストールするようにすることができる。そして、その
後、新たにインストールされたデバイスドライバによ
り、変更後の通信プロトコルに基づいて、パケットの受
信処理が行われる。従って、端末の管理者による手作業
をなくすことが可能となる。

【００７１】なお、上記実施例においては、変更後の通
信プロトコルに対応したパケットを受信したとき、変更
前の通信プロトコルに対応したデバイスドライバを消去
するようにしたが、変更後の通信プロトコルに対応した
デバイスドライバをすぐには消去しないで、さらに通信
プロトコルが変更された場合に、古い方のデバイスドラ
イバを消去するようにすることもできる。

【００７２】また、上記実施例においては、ネットワー
クレイヤが変更される場合について説明したが、他のレ
イヤが変更される場合、或いは、複数のレイヤが変更さ
れる場合においても、上述した場合と同様の方法を適用
することが可能である。

【００７３】

【発明の効果】請求項１または４に記載の通信方法また
は通信システムによれば、所定の通信プロトコルに対応
する所定のパケットのデータが、他の通信プロトコルに
対応するドライバソフトウェアであると判定された場
合、それを記憶し、それ以降、他の通信プロトコルに対
応した所定のパケットを、このドライバソフトウェアに
より受信するようにしたので、送信側の端末から、所定
のパケットにより、所定の通信プロトコルに対応するド
ライバソフトウェアを送信することにより、受信側の端
末のドライバソフトウェアを、その通信プロトコルに対
応したドライバソフトウェアに変更することができる。
従って、通信プロトコルの変更に伴うＯＳの変更を、手
作業によることなく、ＯＳが自動的に行うようにするこ
とが可能となる。また、これにより、通信プロトコルの
変更を、より効率的に行うようにすることが可能とな
る。

【００７４】請求項２または５に記載の通信方法または
通信システムによれば、所定の通信プロトコルに対応し
たパケットは、その通信プロトコルに対応したドライバ
ソフトウェアにより受信され、他の所定の通信プロトコ
ルに対応したパケットは、その通信プロトコルに対応し
たドライバソフトウェアにより受信されるようにしたの
で、２つの通信プロトコルのそれぞれに対応したドライ
バソフトウェアを記憶している場合、いずれの通信プロ
トコルに対応したパケットでも受信可能なマルチプロト
コルとすることができる。従って、端末間の通信路や、
端末の性能等の不確定要素によらず、通信プロトコルの
変更を確実に行うようにすることが可能となる。

【００７５】請求項３または６に記載の通信方法または
通信システムによれば、新しい通信プロトコルに対応し
たドライバソフトウェアが記憶されると、古い通信プロ
トコルに対応したドライバソフトウェアが消去されるよ
うにしたので、さらに新しい通信プロトコルへの変更が
容易にできる。従って、通信プロトコルの変更に伴う処
理を効率的に行うようにすることが可能となる。

【図面の簡単な説明】

【図１】本発明の通信方法および通信システムを応用し
た放送システムの一実施例の構成を示す図である。

【図２】図１のＯＳ１００の構成を示す図である。

【図３】ネットワークレイヤにおける、変更前と変更後
のそれぞれの通信プロトコルに対応したパケットの構造
を示す図である。

【図４】ネットワークドライバが変更されるときのタイ
ムチャートである。

【図５】トランスポートレイヤにおける、プロトコル変
更要求パケットと、通常のパケットの構造を示す図であ
る。

【図６】図２のプロトコルマネージャ４により行われる
処理を説明するためのフローチャートである。

【符号の説明】

１ ディストリビュータ（第１供給手段、第２供給手
段） ２ 第１ドライバ記憶部（第１記憶手段） ３ 第２ドライバ記憶部（第２記憶手段） ４ プロトコルマネージャ（第１読み出し手段、第２読
み出し手段、判定手段、消去手段） ５ 他のドライバ ６ カーネル ７，８，９，１０ アプリケーション ２１，３１ バージョン ２２，３２ オフセット ２３，３３ トータルレングス ２４，３４ ソースアドレス ２５，３５ デスティネーションアドレス ２６，３６ データ部 ２７，３７ ヘッダ部 ４１，４２，４３，４５ 変更前のプロトコルのパケッ
ト ４４ プロトコル変更要求パケット ４６，４７ 変更後のプロトコルのパケット ５１，６１ ソースポート ５２，６２ デスティネーションポート ５３，６３ データタイプ ５４，６４ 未使用領域 ５５，６５ データエンドフラグ ５６，６６ トータルレングス ５７，６７ データ １００ ＯＳ ２００ センタ ３００ 放送衛星 ４００ 端末

Claims (6)

【特許請求の範囲】
1. 【請求項１】 通信プロトコルに従って、端末間におけ
   る所定のパケットの送受信を制御する通信方法におい
   て、 前記通信プロトコルの所定のものに対応する所定のドラ
   イバソフトウェアを記憶し、 前記端末の所定のものからの前記パケットを、前記所定
   のドライバソフトウェアに供給し、 前記端末の所定のものからの前記通信プロトコルの所定
   のものに対応する前記パケットを受信し、 前記所定のドライバソフトウェアからの前記パケットに
   含まれるデータを読み出し、 前記データが、前記通信プロトコルの他の所定のものに
   対応する他の所定のドライバソフトウェアであるか否か
   を判定し、 前記判定結果に従って、前記データを、他の所定のドラ
   イバソフトウェアとして、前記所定のドライバソフトウ
   ェアとは別に記憶し、 前記端末の所定のものからの前記パケットを、前記他の
   所定のドライバソフトウェアに供給し、 前記端末の所定のものからの前記通信プロトコルの他の
   所定のものに対応する前記パケットを受信し、 前記他の所定のドライバソフトウェアからの前記パケッ
   トに含まれるデータを読み出すことを特徴とする通信方
   法。
2. 【請求項２】 前記所定のドライバソフトウェアと、前
   記他の所定のドライバソフトウェアの双方が記憶された
   場合において、 前記端末の所定のものからの、前記通信プロトコルの所
   定のものに対応する前記パケットは、前記所定のドライ
   バソフトウェアにより受信され、 前記端末の所定のものからの、前記通信プロトコルの他
   の所定のものに対応する前記パケットは、前記他の所定
   のドライバソフトウェアにより受信されることを特徴と
   する請求項１に記載の通信方法。
3. 【請求項３】 前記通信プロトコルの他の所定のものに
   対応する前記パケットを受信した場合、前記通信プロト
   コルの所定のものに対応する前記所定のドライバソフト
   ウェアを消去することを特徴とする請求項１に記載の通
   信方法。
4. 【請求項４】 通信プロトコルに従って、端末間で所定
   のパケットの送受信を行う通信システムにおいて、 前記通信プロトコルの所定のものに対応する所定のドラ
   イバソフトウェアを記憶する第１記憶手段と、 前記端末の所定のものからの前記パケットを、前記所定
   のドライバソフトウェアに供給する第１供給手段と、 前記所定のドライバソフトウェアにより受信された前記
   端末の所定のものからの前記通信プロトコルの所定のも
   のに対応する前記パケットに含まれるデータを読み出す
   第１読み出し手段と、 前記データが、前記通信プロトコルの他の所定のものに
   対応する他の所定のドライバソフトウェアであるか否か
   を判定する判定手段と、 前記判定結果に従って、前記データを、他の所定のドラ
   イバソフトウェアとして、前記所定のドライバソフトウ
   ェアとは別に記憶する第２記憶手段と、 前記端末の所定のものからの前記パケットを、前記他の
   所定のドライバソフトウェアに供給する第２供給手段
   と、 前記他の所定のドライバソフトウェアにより受信された
   前記端末の所定のものからの前記通信プロトコルの他の
   所定のものに対応する前記パケットに含まれるデータを
   読み出す第２読み出し手段とを備えることを特徴とする
   通信システム。
5. 【請求項５】 前記所定のドライバソフトウェアと、前
   記他の所定のドライバソフトウェアの双方が記憶された
   場合において、 前記端末の所定のものからの、前記通信プロトコルの所
   定のものに対応する前記パケットは、前記第１記憶手段
   に記憶された前記所定のドライバソフトウェアにより受
   信され、 前記端末の所定のものからの、前記通信プロトコルの他
   の所定のものに対応する前記パケットは、前記第２記憶
   手段に記憶された前記他の所定のドライバソフトウェア
   により受信されることを特徴とする請求項４に記載の通
   信システム。
6. 【請求項６】 前記第２記憶手段に記憶された前記他の
   所定のドライバソフトウェアにより、前記通信プロトコ
   ルの他の所定のものに対応する前記パケットが受信され
   た場合、前記第１記憶手段に記憶された、前記通信プロ
   トコルの所定のものに対応する前記所定のドライバソフ
   トウェアを消去する消去手段をさらに備えることを特徴
   とする請求項４または５に記載の通信システム。