(57)【要約】  本発明は、医療用デバイスにおいて、ソースアドレスがチェックコードと一緒にコード化されている送信パケットヘッダの、フォーマットサイズの削減に関する。本発明のパケットヘッダは、２のフィールド、即ちチェックコードフィールドとソースアドレスフィールドを、１のフィールドで置き換える。受信端において、受信側は、セッション記述子テーブルから送信アドレスを検索し、チェックコードを計算し、次いで送信アドレスとチェックコードを用いて同じコード化を行い、それによってパケットの認証と検証を行う。【特許請求の範囲】
【請求項１】
医療用デバイスを含む通信ネットワーク内で交換されるパケットの送信パケットヘッダのフォーマットであって、前記パケットヘッダが、ソースアドレスと一緒にコード化されたチェックコードを含むフィールドを有することを特徴とするフォーマット。
【請求項２】
前記チェックコードが巡回冗長検査（ＣＲＣ）コードを含む、請求項１に記載のフォーマット。
【請求項３】
前記ソースアドレスと前記チェックコードが、いずれかの既知の数学的アルゴリズムを用いて一緒にコード化される、請求項１に記載のフォーマット。
【請求項４】
前記ソースアドレスと前記チェックコードが、随意でハードウエア回路を用いて一緒にコード化される、請求項１に記載のフォーマット。
【請求項５】
パケットヘッダのサイズを削減するための医療用デバイスを含む通信ネットワークの通信プロトコルであって、チェックコードとソースアドレスを一緒にコード化することを特徴とする通信プロトコル。
【請求項６】
少なくとも一つの送信デバイスと少なくとも一つの受信デバイスを含み、且つ前記デバイスが医療用デバイスである通信ネットワーク内において交換されるパケットの、パケットヘッダのサイズを削減する方法であって、
−  前記送信デバイスと受信デバイスがアドレスを交換するステップ、
−  前記送信デバイスが送信パケットのチェックコードを計算するステップ、
−  前記チェックコードと送信デバイスのアドレスを一緒にコード化するステップ、及び
−  コード化した結果を前記パケットヘッダに組み込むステップ
を含むことを特徴とする方法。
【請求項７】
前記チェックコードが（ＣＲＣ）コードを含む、請求項６に記載の方法。
【請求項８】
前記コード化がいずれかの既存の数学的アルゴリズムを含む、請求項６に記載の方法。
【請求項９】
前記送信デバイスのアドレスと前記チェックコードを、随意でハードウエア回路を用いて一緒にコード化する、請求項６に記載の方法。
【請求項１０】
コンピュータで読み取り可能な内蔵式記憶媒体内に保存された、コンピュータで読み取り可能なプログラムコードを有する、パケットヘッダのサイズを削減するためのコンピュータプログラム製品であって、
−  チェックコードを計算するための、コンピュータで読み取り可能なプログラムコード手段、
−  前記チェックコードとソースコードを一緒にコード化するための、コンピュータで読み取り可能なプログラムコード手段、及び
−  パケットヘッダを用いてコード化された結果をフレーム化するための、コンピュータで読み取り可能なプログラムコード手段
を備えるコンピュータプログラム製品。
【請求項１１】
請求項１ないし１０のいずれか１項に記載のフォーマット又は方法に従って構築されたデータパケットを受信した際に受信側で実行される読み出し方法であって、
−  前記受信デバイスがそのセッション記述子テーブル内のリモートアドレスを検索するステップ、
−  受信データを使用してチェックコードを計算するステップ、
−  前記リモートアドレスを、前記計算したチェックコードと一緒にコード化するステップ、
−  前記コード化した出力と受信チェックコードとを照合するステップ、及び
−  一致しない場合に当該パケットを無視し、一致する場合に受け入れるステップ
を含む方法。
【請求項１２】
前記チェックコードを送信側と同じ方式で計算する、請求項１１に記載の方法。
【請求項１３】
前記リモートアドレスと前記チェックサムのコード化に、送信側と同じアルゴリズムを使用する、請求項１１に記載の方法。
【請求項１４】
コンピュータで読み取り可能な内蔵式記憶媒体内に保存された、コンピュータで読み取り可能なプログラムコードを有する、受信したパケットを読み出すためのコンピュータプログラム製品であって、
−  セッション記述子テーブル内でリモートアドレスを検索するための、コンピュータで読み取り可能なプログラムコード手段、
−  受信データを使用してチェックコードを計算するための、コンピュータで読み取り可能なプログラムコード手段、
−  前記リモートアドレスと前記計算されたチェックコードを一緒にコード化するための、コンピュータで読み取り可能なプログラムコード手段、
−  前記コード化された出力とチェックコードとを照合するための、コンピュータで読み取り可能なプログラムコード手段、及び
−  一致しない場合に当該パケットを無視し、一致する場合に受け入れるための、コンピュータで読み取り可能なプログラムコード手段
を含むコンピュータプログラム製品。
【発明の詳細な説明】
【発明の開示】
【０００１】
本発明は、パケット交換方式を用いるデータ通信デバイスの分野に関する。具体的には、本発明は、複数の医療用デバイス間のデータ通信に使用されるパケットヘッダのサイズとフォーマットに関する。
【０００２】
ネットワーク機能は、地理的に隔たった二つの装置／ユーザー間の情報伝達を行う。周知のネットワークとして、郵便（非電子）、電信（初期のデジタル電子ネットワーク）、電話、同報通信（テレビ、電話）、及びインターネットが挙げられる。２の当事者（人間、コンピュータなど）が効率的に通信するためには、一定のプロトコルに従う必要がある。このプロトコルは、両当事者が互いに通信するために使用するルール及びガイドラインである。
ネットワークは、ネットワーク内でのデータの伝送方式により分類することができる。最も一般的な２つの分類は、回線交換ネットワーク及びパケット交換ネットワークである。交換ネットワークは、部分的又は完全なメッシュトポロジー（即ち、ネットワーク内のノード間の部分的又は全面的接続）を有し、発信元ノードと宛先ノードとの間の接続路を互いに連結する交換機と呼ばれる特殊なネットワーク装置を使用する。
【０００３】
回線交換ネットワーク方式においては、データ伝送に先立ち、先ず、送信元と宛先の間に物理的な回線を確立する。回線が確立されると、その回線は現在の伝送専用に使用される。伝送が終了すると回線は開放され、他の通信が可能となる。
パケット交換ネットワークにおいては、先ず、メッセージをパケットと呼ばれる小さなユニットに分割し、次いでこれらのパケットを、中継交換機を介して宛先ノードに送る。パケットは、所定のネットワーク内で伝送することのできる最小のデータ単位である。各パケットヘッダは、通常、宛先ノードアドレス、ソースアドレスに加え、プロトコル指定情報、シーケンス番号、データバイト長等の他の重要な情報を含む。
【０００４】
上記二つの通信方式、即ちパケット交換ネットワークと回線交換ネットワークの比較を次表に示す。
2007529928.tif 000002
パケットは、通常以下の層により構築される：
・  アプリケーション層（ＦＴＰ、ＨＴＴＰ、ＳＭＴＰ等）
・  トランスポート層（ＴＣＰ、ＵＤＰ）
・  インターネット層（ＩＰ）
・  ネットワークアクセス層（イーサーネット、ＡＴＭ等）
【０００５】
これらの層は、異なるレベルのネットワーキングプロトコルであり、コミュニケーション層の各ペア間のプロトコルの組み合わせは、いわゆるプロトコル・スタックである。
通常、パケットはカプセル化されているので、各層は、前層からデータ（本体部分）を取得し、ヘッダをそのデータ部に付加する。これに対応して、受信端における各層は、ヘッダ部を除去してデータペイロードにアクセスし、それを次層、ないしは他の部分へ送る。
【０００６】
パケットは、ハードウエアに依存しない一様なフォーマットを有することが出来る。通常、パケットはヘッダ部とデータ部を有している。ヘッダとデータの長さは可変であるが、通常データのサイズはヘッダのサイズよりもずっと大きい。ヘッダは通常パケットを宛先に配信するために必要な全ての情報を含み、そのような情報は：
−  ソースアドレス
−  宛先アドレス
−  識別子
−  その他の制御パラメータ
等である。
ネットワーク層においてパケットの宛先を決定するデバイスをルーターと呼ぶ。ルーターはパケットのアドレスをチェックし、パケットを正しい経路に向かわせる。ルーターの役割は、異なるネットワークを物理的に接続し、１のネットワークから別のネットワークにパケットをルーティングすることである。ルーターは、宛先ノードまでの特定の経路を決め、次いでこの経路に基づいてパケットを送信する。
【０００７】
ネットワーク通信において、考慮すべき重要な点は、一般に、
−  パケットの安全性
−  データの有効性
−  パケットの認証
−  ネットワーク輻輳、トラフィック
等である。
送信側でのデータの暗号化等、データの安全性を確保する様々な方法が存在する。この場合、当然ながらデータは受信側だけが解読できるように暗号化される。
【０００８】
通常、パケットヘッダは、パケットデータを使用して計算されるチェックコードを含んでいる。受信端において、受信側はチェックコードに対する作業を行い、それにより得られた結果に基づいて、正しいコンテンツを有するパケットが到達したかどうかをチェックすることができる。このようにして、データの有効性が保証される。
パケット認証の基本的な方法では、複数の通信者間でのデータ交換に先立ち、通信者が固有アドレスを有していない場合、先ず各通信者に固有アドレスを割り当てる。次いで、各通信デバイスは、それぞれのアドレスを交換する。その後、これらデバイス間で行われる全ての通信では、データパケットの発信元（即ち、ソース）も特定される。これにより、受信側は、パケットが想定した送信者からのものであるかどうかをチェックすることができ、この場合データに関して他の処理を実行することができる。
【０００９】
受信速度よりも速くパケットが到来すると、ネットワークデバイスに輻輳が生じる。交換機には多数の入力があるので（一つの出力に振り向けられるパケット数は通常決められている）、交換機はしばしばネットワーク輻輳を引き起こす。
トラフィックとは、ネットワークを経由して流れるデータの量を意味する。過大なトラフィックは、通信の過負荷状態を生じる場合もある。これが生じると、ネットワークにアクセスするのに非常に時間が掛かる。ネットワークのトラフィック密度は、送信するパケットの数を減らすか、又はパケット内のデータ量を減らすことにより低減できる。
【００１０】
米国特許第６５１６３４４号には、割り振られていない領域のトラックをファイル内に保存することにより、ネットワークトラフィックを減少させるシステムが開示されている。このシステムは、リモートサーバ上のファイルへのアクセス要求を、ローカルコンピュータシステムで受信する。要求が読出し操作であり、リモートサーバ上のファイルの未だ割り振られていない領域を指定している場合、本システムは、リモートサーバからのヌル値のブロックを受信することなく、要求者にヌル値のブロックを返す。これにより、トラフィックの不必要な増大を回避する。書き込み要求の場合にも同様の操作が行われる。
米国特許第６６２２１７３号には、送信側と受信側が存在する通信システム内で稼動するメッセージ自動予測システムにより、トラフィックを減少させる方法が開示されている。この場合の受信側は、送信メッセージの少なくとも一部を受信して、受信したメッセージ部分から受信側が以前に受信したメッセージを特定しようとする。これが成功すると、受信側は以前受信したメッセージのチェックサムを計算し、このチェックサムを、該メッセージの残り部分の予測として送信側に送信する。送信側から予測が正しいという指示を受け取ると、受信側は、以前受信したメッセージを用いて当該メッセージを完成させる。この方法は効果的であるが、以前に受信したメッセージのバックアップデータを保存しておくために記憶容量を追加しなければならないという課題を有している。更に、計算を行うため、コンピュータリソースの必要性が増大する。
【００１１】
米国特許第６３５９８７７号には、通信システムにおけるパケット再送時のオーバーヘッドを最小にする方法及び装置が開示されている。このコンセプトは、パケットのサイズを変更することである。パケットサイズは、当該パケットが初めて送信されるときも、再送されるときも、ネットワーク内の送信速度及び／又はスループットに基づいて定めることができる。別の方法では、パケットが再送される場合、その送信速度は最初の送信速度と同じである。このような装置では、計算リソースにオーバーヘッドを必要とする全ての送信について、パケットサイズを考慮する必要がある。
欧州特許第１２６１２３０号には、ＨＥＣ（ヘッダエラー修正）の除去を可能にすることにより、オーバーヘッドを減らす方法が開示されている。しかし、この方法は、送信スタックの物理層が強力な修正機能を有している場合にのみ適用可能である。
【００１２】
米国特許第６０４１３５１号には、プロセッサ間の命令語のサイズを縮小することにより、ネットワーク輻輳を緩和する発明が開示されている。この場合のデータパケットは通常、ＭＲＵメモリキャッシュに保存されるので、同一のデータパケットである一又は複数のパケットの再送が回避される。この発明は、キャッシュメモリを別途維持する必要があり、コストの増大を招く。
国際公開第９９／２７７５１号には、データパケット内の最小バイト数で有効データを送信できる方法が開示されている。この国際公開が採用する方式は、割り当てられた符号を用いてビット及びバイトバターンを置換するものである。この方法により既存のデータペイロード部分に含まれて送信されるデータは増大するが、データペイロード部分の増大に関してヘッダのサイズを削減する処理は全く行っていない。
このため、パケットサイズがデータペイロードに関して大きな容量を有し、且つ認証並びにデータの検証に必要な全ての情報をヘッダ部自体に含む方法論が必要となる。
【００１３】
本発明の目的は、データの検証及び認証を保証するパケットヘッダのサイズを削減することにより、先行技術の問題点を克服する方法を提供することである。
本発明の別の目的は、各パケットに含まれるペイロードを高めることである。
本発明のまた別の目的は、パケット送信システムにおける通信上のオーバーヘッドを減らすこと、並びにネットワーク輻輳及びトラフィックを減らすことである。
【００１４】
先行技術の問題点を克服し、前述の目的を達成するため、本発明はパケットヘッダのサイズを削減する方法を提供する。本発明によれば、ソースアドレスをデータパケットのチェックコードと一緒にコード化することによって送信ヘッダのサイズを削減する。これは、一又は複数の数学的操作を用いて実行される。受信側は、受信データを用いてチェックコードを計算し、リモートアドレスを参照した後、同じ数学的機能を使用することによりこのチェックコードとリモートアドレスをコード化する。計算されたチェックコードが、受信されたチェックコードと一致しない場合、当該パケットは無視される。逆に、計算されたチェックコードが受信されたチェックコードと一致する場合、該パケットは受け入れられる。
【００１５】
本発明は、データの検証及び認証能力を確保しつつ、パケットのヘッダサイズを削減して各パケットのペイロードを拡大する方法を提供する。本発明のパケットヘッダは、宛先アドレス及びその他制御パラメータに加えて、ソースアドレスと一緒にコード化されたチェックコードを含むことができる一つのフィールドを有する。このフィールドは、ソースアドレスとチェックコードの代わりにパケットヘッダに組み込まれる。この方式により、パケットの正規な認証のために別個にソースアドレスを加える必要がなくなる。コード化は、既知の数学的操作を用いて行うことができる。パケットがネットワーク内の全ての受信者に対して送信されるため、ポイントツーポイント接続を有しない同報通信の分野においては、パケットヘッダのこのフィールドは生のチェックコードだけを含む。宛先アドレスは、世界的に固有のデバイスＩＤとすることができる。
本発明は、いずれのパケット交換ネットワークでも実行可能である。パケット交換ネットワークは、インターネットのような有線ネットワーク、又は無線イーサーネットのような無線ネットワークとすることができる。このネットワークは、セキュアなネットワーク、セキュアでないネットワーク、パブリックネットワーク、プライベートネットワーク、又はこれらの組み合わせとすることができる。本明細書に開示する汎用パケットフォーマットは、ファイル転送プロトコル（ＦＴＰ）、送信制御プロトコル（ＴＣＰ）、ブルートゥース等、あらゆるプロトコルに適用可能である。バス形、スター形、リング形等のネットワークトポロジー、或いは、双方向通信、単方向通信等のデータ転送形式は、本発明の使用に影響しない。本方法は、電気通信ネットワーク、及びデジタルデータを伝送する他のあらゆるネットワーク、並びにコンピュータネットワークに等しく適用可能である。
【００１６】
本発明の応用分野は多岐に亘り、図１の説明は単なる例示に過ぎず、いかなる意味でも限定的なものではない。例えば、本発明は、インターネットを介したセキュアなトランザクション、並びに医療用デバイスのネットワークに等しく効果的に適用可能であり、このような観点から以下に本発明を説明する。
国際公開第００／３２０８８号、同第０３／００５８９１号、及び同第０３／０１５８３８号は全て、このような医療用デバイス、ネットワーク、及びそれらの操作方法を、この分野における幾つかの実施例を挙げて記載している。以下に、参考のため本発明に包含するこれらの特許文献に記載のデバイスについて簡単に説明する。
【実施例】
【００１７】
図１は、国際公開第００／３２０８８号に開示の電子データマネージャを備える医療用デバイスの一実施例を示す。なお、国際公開第００／３２０８８号は、参考文献として本明細書に包含する。本図は、患者用電子データマネージャ４４０を備えるシステムを示す。患者用電子データマネージャ４４０には患者用コミュニケータ４４２が接続されており、患者用コミュニケータ４４２は、患者が必要とする時又は定期的に、患者用電子データマネージャ４４０との交信を行う。患者用コミュニケータ４４２は、ネットワーク通信システム４５０と通信を行う。本通信システムはまた、ネットワーク通信システムと通信できるユーザー用インターフェイス４８０を備えている。中央制御装置４９０は、通信ネットワークシステムとの双方向通信チャンネルである。図１はまた、患者用データマネージャ４４０からネットワークに無線送信される患者データ４４４を示す。患者はまた、ネットワークを介してデータを要求することができ、患者用コミュニケータ４４２及びデータマネージャ４４０を介してその回答を受信することもできる。更に、許可されたユーザー用コミュニケータ４８２を介して、データベースへの照会４８４を行い、その回答４８６を許可されたユーザーインターフェイス４８０で受信することができる。
本発明は、ポンプ、注射器、投薬器のような医療用デバイス、又はパケット形式で他の電子デバイスとデータ通信できるその他任意の電子デバイスに適用可能である。後者の場合、他の電子デバイスは、通信を開始するデバイスと同じ種類のデバイスとすることができる。一実施例として、医療用デバイスは、前述の電子データマネージャであってよい。
【００１８】
本明細書において、「医療用デバイス」という用語は、薬液（小さな液滴状）の個別投与量を送達するための注入型デバイス（ペン型注射器又はジェット式注入器等）、薬液を連続的に送達するための医療用ポンプ、或いは、気化した薬剤、「霧状の」薬剤又は粉末状の薬剤（インスリンが好ましい）を、個別に又は連続的に注入するための吸入器、スプレー又はこれに類する機器を意味する。医療用デバイスはまた、血糖値テスター、即ちＢＧＭ（血糖値測定デバイス）、例えば、いわゆるテスト帯を使用して血糖値を手動で測定する装置、或いは更に高度な装置、即ち血糖値を自動的に連続測定するＣＧＭ（連続血糖値測定デバイス）も含む。
米国特許第６５４０６７２号、同第６６５６１１４号、ＵＳ２００２０１０４３２、及びＵＳ２００３０３２８６８は全て、インテリジェントな医療用デバイスを開示しており、これら特許文献の内容全体を参考文献として本明細書に包含する。米国特許第５８８８４７７号（全体を参考文献として本明細書に包含する）には、インスリンの投与に使用できる頑丈な構成を有する吸入器が開示されている。Ｓｍｉｔｈ等による米国特許第５７８５０４９号（全体を参考文献として本明細書に包含する）には、粉末状薬剤の送達に適したデバイスが開示されている。
【００１９】
図２は、送信パケットのフレーム化を示す。パケットは、送信される前に、リンクヘッダとリンクトレーラによってフレームに入れられる。リンクヘッダ２０とリンクトレーラ２１はそれぞれ、パケットの始まりと終わりを表す。リンクヘッダ及びリンクトレーラはそれぞれ所定のビット配列を有しているので、受信側はパケットの初めと終わりを容易に識別することができる。トランスポートヘッダ又は送信ヘッダ２２は、ソースアドレス、宛先アドレス、及びチェックコードを含むことができる。本発明の例示的一実施形態では、トランスポートヘッダ２２のヘッダ長は１２バイトである。本発明によれば、ソースアドレスとチェックコードを一緒にコード化することにより、ヘッダサイズを削減することができる。このようなヘッダサイズの削減分は、パケットの全長を変えることなくデータペイロード２４のサイズの増加に有利に使用できるか、又は単にパケット全体のサイズ低減に使用される。
【００２０】
図３は送信用パケットヘッダを示す。本発明のパケットヘッダは、宛先アドレス３１及びその他の制御パラメータに加えてフィールド３０を有することができ、このフィールドは、ソースアドレスと一緒にコード化されたチェックコードを含むことができる。これにより、ソースアドレスを別個に付加せずに、パケットの認証を正しく行うことができる。フィールド３０は、ソースアドレスとチェックコードの代替データとしてパケットヘッダ内に配置される。コード化は、この目的専用の何らかの数学的操作によって行うことができる。パケットがネットワーク内の全てのデバイス（即ち宛先）に発信されるために特定のリンクが存在しない同報通信の場合、宛先アドレスを必要としないので、パケットヘッダ内のこのフィールドには生のチェックコードのみが含まれる。同報通信でなく、ポイントツーポイント通信の場合、即ち送信側（ソース）から受信デバイス（宛先）に情報を送る場合、宛先アドレスは、一例として、唯一の受信デバイスを指定できる固有のデバイスＩＤである。
好適な一実施形態では、チェックコードとソースアドレスの排他的論理和（ＸＯＲ）を求めるプロセスを使用して、パケットヘッダの前記追加フィールドを計算することができる。
パケットヘッダは、上記フィールドの他に、パケットのビット長、シーケンス番号、リモートポート、コード等を含むことができる。
【００２１】
図４は、発信側と受信側で本発明がどのように機能するかを示すフロー図を示す。開始点において、医療用無線デバイス１０は、パケット内にカプセル化されたデータを送信する。パケットヘッダは常套的に、送信元アドレスとチェックコードを他のフィールドと共に含むことができる。データペイロードを使用して、既知のアルゴリズムに従ってチェックコードを計算することができる。次いで、チェックコードは、ソースアドレスと共にコード化され、例えばそれらの排他的論理和を求める処理が行われる。前記排他的論理和以外の論理的／数学的操作を用いることも可能である。チェックサム及びソースアドレスはそれぞれ異なるデータ長及び／又は所定のデータ長を有することができる。これら、即ちチェックサム及びソースアドレスはまとめて送信される。受信側において、第二の医療用無線デバイス１２は、ソースアドレスを照合することなくパケットを認証することはできない。この照合に際し、セッション記述子テーブル内のリモートアドレスを検索することができる。次に、データ部を用いてチェックサムを計算する。このようにして計算されたチェックサムを、検索したリモートアドレスと共にコード化する。このようにしてコード化された出力は、受信したパケットヘッダ内の数値と一致していなければならず、一致しない場合、第二の医療用無線デバイス１２はこのパケットを受理しない。
好適な一実施形態においては、チェックコードとソースアドレスの排他的論理和を計算し、この値でソースアドレスとチェックコードを置き換える。
【００２２】
前述の方法は、ハードウエア、ソフトウェア、又は両者を組み合わせた形態のコンピュータデバイスで命令セットを実行することによって実施することができる。本発明は、前記方法の実施に種々のアブストラクションで使用されるコード体系及びコンピュータ言語に依存しない。
一般に、本発明で使用するコンピュータデバイス又は装置は、処理手段、制御ユニット、記憶手段、及び内部通信手段を有するあらゆる一般的コンピュータデバイスとすることができる。一実施例として、前記機器のいずれも、前述の医療用デバイス、即ち、ポンプ、ペン形注射器、注入器、ドーサ（ｄｏｓｅｒ）等とすることができる。
【００２３】
一実施例では、非常に単純な場合として、これらのデバイスは単一の接続を確立することができる（この場合リモートポート数は１に固定）。もっと複雑な構成では、これらのデバイスは、「ポート・ナンバー」による制御の下で、複数の接続を同時に形成することができる。
接続が確立されると、デバイスのアドレス（即ち、宛先）が交換される。１つの接続を解除し、他のデバイスと新たな接続を改めて確立することにより（他のデバイスがこの変更を「認知」することなく）、１つのデバイスが「停止」状態のセッション接続を有することがある。このような場合を次の例により説明する。デバイスＡとデバイスＢが接続している。デバイスＢは、電源が入っていないため、又は何らかの理由、例えばデバイスＢが無線通信可能領域外に位置する等の理由により通信不能である。このような場合、デバイスＡは接続を解除して、デバイスＣとの新たな接続を確立する。その後、デバイスＢに電源が入り、無線到達範囲に再び入った場合、デバイスＢは、デバイスＢが依然として有効とみなしている旧接続に基づいて、デバイスＡに対するデータの送信を開始することができる。デバイスＡは、当該パケットが、解除されたデバイスＢとの接続から発信されていることを識別する方法を持たないので、当該パケットがデバイスＣとの新しい接続から送信されたものと誤認する。このような潜在的な障害は、パケットヘッダが送信者（ソース）を指定しない場合に発生する。この問題を解決する単純な方法は、本発明に開示するように、ヘッダにソースアドレスを含めることである（その後、前述のようにコード化などを行う）。このように、本発明は使用するプロトコルのヘッダサイズを増加させることなく、ヘッダ内にソースアドレスを組み込む方法を提供する。
【００２４】
本発明の発想の背景にある理論的根拠は、最末端で使用される医療用デバイスの無線プロトコルが、前述したようにパケットのヘッダサイズを出来るだけ小さく保ちながら、高いレベルのデータ検証性と何らかの認証機構の両方を提供しなければならないということである。
接続を確立する間、二つのデバイスはソースアドレスを交換する。リンクの確立後、二つのデバイス間で行われる全ての通信（同報通信のメッセージを除く）はＣＲＣ３２を含み、ソースアドレスは、例えばフレームのＣＲＣに対して排他的論理和計算される。次いで受信側はそのセッション記述子テーブルからリモートアドレスを検索し、計算されたＣＲＣと受信したＣＲＣとが一致しなければ（記述子テーブルで検索したリモートアドレスとの排他的論理和計算を行った後で）当該フレームは無視され、逆に一致する場合は当該フレームは受け入れられて、フレーム内のデータの更なる処理が可能となる。このように、デバイスは、パケットが正しい送信者（即ちソース）から送られた場合のみ、通信回線上のパケットを受け入れる。
【００２５】
ＣＲＣ演算及びソースアドレスの検証は、当然ながら、ハードウエア並びにソフトウェア、又はこれらの組合わせを用いて行うことができる。
【図面の簡単な説明】
【００２６】
【図１】本発明の説明に使用する医療用デバイスを示す。
【図２】送信パケットを示す。
【図３】送信パケットのヘッダを示す。
【図４】本方法の機能を説明するフロー図である。
【図１】
2007529928.tif 000003
【図２】
2007529928.tif 000004
【図３】
2007529928.tif 000005
【図４】
2007529928.tif 000006
【国際調査報告】
2007529928.tif 000007
2007529928.tif 000008
2007529928.tif 000009