(57)【要約】本発明は、医療機器がネットワークに接続されているか否かを発見し、サーバと医療機器との間に安全な通信を確立し、医療機器と通信を行うシステムおよび方法を提供する。さらに、ネットワークに接続されたサーバと医療機器との間で、ネットワーク内での安全な通信を保証する暗号化方法を提供する。本発明は、さらに、施設内で医療機器の位置を判別するシステムおよび方法を含む。さらに、移動型システム・マネージャとして機能する移動型サーバを提供する。
2007515883.tif 000002
【特許請求の範囲】
【請求項１】
施設内の患者ケアを管理するシステムであって、
ワイヤレス・ネットワークであって、該ネットワークに接続された機器の間でデータを伝えるワイヤレス・ネットワークと、
前記ネットワークとの通信を行うワイヤレス通信機能を有する移動型サーバであって、前記ネットワークとの通信は、前記サーバの選択されたポートを介して行われ、前記サーバは、選択された間隔で前記ネットワーク上にビーコン信号を同報通信するようにプログラムされたプロセッサを有する、移動型サーバと、
前記ネットワークとの通信を行い、前記選択されたポートからの前記ビーコン信号をリスニングして、当該信号に対して状態メッセージにより応答するようにプログラムされたクライアント機器であって、前記状態メッセージは、前記サーバが前記クラアント機器との安全な通信セッションを確立する際に用いられる情報を含む、クライアント機器と、
を備え、前記状態メッセージを受信すると、前記サーバは、前記状態メッセージに含まれる情報を用いて前記クラアント機器との通信セッションを確立する、システム。
【請求項２】
請求項４に記載のシステムにおいて、前記プロセッサは、システム・マネージャ・プログラムにより構成されており、前記移動型サーバは移動型システム・マネージャとして動作する、システム。
【請求項３】
請求項１に記載のシステムにおいて、前記クラアント機器は、前記ビーコン信号をリスニングし、前記ビーコン信号が有効か否かを判断し、有効なビーコン信号に対してのみ応答するようにプログラムされている、システム。
【請求項４】
請求項１に記載のシステムにおいて、前記移動型サーバの前記ワイヤレス通信機能は選択された範囲を有し、該選択された範囲を超えて位置するクライアントは、前記移動型サーバにより同報通信された前記ビーコン信号を検出することができない、システム。
【請求項５】
請求項１に記載のシステムにおいて、前記移動型サーバは、ワイヤレス・アクセス・モジュールに接続されている、システム。
【請求項６】
請求項１に記載のシステムにおいて、前記移動型サーバの前記ワイヤレス通信機能は、前記移動サーバに一体化されている、システム。
【請求項７】
請求項１に記載のシステムにおいて、前記移動型サーバは、ケア施設を動き回るように構成されている移動プラットフォーム上に設置されている、システム。
【請求項８】
請求項７に記載のシステムにおいて、前記移動プラットフォームは、遠隔制御されたカートであり、該カートは、該カートの移動を制御するために該カートに通信された命令に応答するセンサを含む、システム。
【請求項９】
請求項１に記載のシステムにおいて、前記移動サーバはラップトップ・コンピュータである、システム。
【請求項１０】
請求項９に記載のシステムにおいて、前記ラップトップ・コンピュータは、データベースとのワイヤレス通信を行う、システム。
【請求項１１】
請求項１に記載のシステムにおいて、前記移動型サービスはＰＤＡである、システム。
【請求項１２】
請求項１１に記載のシステムにおいて、前記ＰＤＡは、データベースとのワイヤレス通信を行う、システム。
【請求項１３】
請求項１に記載のシステムにおいて、前記移動型サーバは、前記ビーコン信号を同報通信する前に、前記ビーコン信号を暗号化するようにプログラムされている、システム。
【請求項１４】
請求項１３に記載のシステムにおいて、前記クライアントは、受信した前記暗号化されたビーコン信号を復号するようにプログラムされている、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、サーバがネットワークに接続されたクライアントを発見し、発見されたクライアントとの通信セッションを開くクライアント／サーバ・ネットワーク上で用いられるシステムおよび方法に関する。より詳細には、本発明は、ネットワーク上で動作するクライアント／サーバ・システムに関し、そのシステムにおいて、サーバは特定のポートを介して、ネットワーク全体にビーコンを同報通信する。そのシステムに接続されたクライアントは、ビーコン用の特定のポート上をリスニングし、ビーコンが検出された場合、クライアントと安全な通信を開くためにサーバにより利用される情報を用いて、そのポートを介して応答する。
【背景技術】
【０００２】
高性能かつ高信頼性のコンピュータ・ネットワーク、高速かつ大容量の記憶媒体、小型のコンピュータ・プロセッサやメモリの出現に伴い、ベッドサイドの装置、実験装置および施設情報システムからの治療の提供および患者データの収集がより統合されるようになってきた。この技術により、様々な医療装置内に、コンピュータ・プロセッサまたはマイクロ・プロセッサおよびメモリが組み込まれるようになっている。通信機能が組み込まれることによって、医療装置内のプロセッサおよびメモリは、病棟、部門および施設に広がるネットワークに結合される。これらのネットワークは、様々な機関の情報システムと個々の医療機器との間での情報の交換を可能にする。医療機器は、輸液ポンプ等の治療提供機器であってもよく、ベットサイドのモニタおよび実験装置の両方を含む生命徴候測定およびデータ収集機器であってもよい。
【０００３】
治療薬物提供の複雑さが増大するにつれて、発生している問題の一つは、ミスの機会が増えていることである。エンゲルソン他（Engleson et al. ）に付与された米国特許第５，７８１，４４２号、発明の名称「データを収集し患者ケアを管理するためのシステムおよび方法（System and Method for collecting Data and Managing Patient Care ）」で説明されているシステム等、薬物ミスの頻度に対処する多くの異なるシステムが提案されており、その主題は本特許仮出願の主題であるとみなされ、本特許仮出願の主題に組み込まれ、本特許仮出願の主題の一部となる。別のシステムは、エガーズ（Eggers）による米国特許出願公開番号第２００２／０１６９６３６号、発明の名称「患者ケアを管理するためのシステムおよび方法（System and Method for Managing Patient Care ）」で説明され、その主題は本特許仮出願の主題であるとみなされ、本特許仮出願の主題に組み込まれ、本特許仮出願の主題の一部となる。
【０００４】
多くのクライアント医療機器を備えたシステムに伴って発生する問題の一つは、システム上の様々な機器のメモリを十分頻繁に更新し、機器が最新の患者情報、治療情報、規則の組合せおよび患者固有の投薬指針にアクセスできることを保守する必要があることである。最近まで、サーバはネットワークに接続された各機器にポーリングを行い、機器がネットワークに接続されているか否かを判別し、それから機器に任意の更新情報を送信する必要があった。このようなポーリングには資源および時間がかかり、ネットワーク全体の効率および速度を低下させる。
【０００５】
この問題は、医療機器が無線ネットワーク等の有線ネットワーク以外の媒体、またはインターネットを用いる場合に特に難しくなる。これらのシステムでは、個々の医療機器は、ダイヤルアップ、ケーブル、ＤＳＬまたは無線接続を用いて、無線ネットワークのアクセス・ポイントまたはインターネットを介してサーバを呼び出す。このようなシステムでは、ネットワークが基本的に、外部発信源から来る通信用の要求に広く開かれている点で、潜在的にセキュリティ上の問題がある。システムは、通信要求が安全な医療機器から来ているのか、安全でない発信源から来ているのかを判別し、安全でない発信源の場合、サーバとの通信の確立を回避しなければならない。
【０００６】
混雑した医療施設において発生する別の問題は、新たなシステム群がオンラインによってもたらされると、それらは施設内の乏しい空間を競合しなければならないことである。しかしながら、最近まで、医療機器が、遠隔に、および／または移動形態で動作し、施設内をくまなく移動し、次いで、ワイヤまたはワイヤレス・アクセス・ポイントを用いて施設ネットワークに接続することを可能にする技術は存在していたが、ネットワークに接続されたサーバは、通例、施設の一エリア内に恒久的に位置していなければならなかった。サーバがどこかに移動可能である場合であっても、そのような移動により、通常、システムをシャットダウンし、サーバとネットワークとの接続を切り、次いで、新たな位置においてサーバを再接続する必要があった。そのような再配置により、通常、ハード・ワイヤまたは光ケーブルおよびルータのような他のネットワーク資源の再配置および再構成が必要となる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
クライアント医療機器がネットワークに接続されているか否かを発見し、サーバと医療機器との間でネットワークを介して、安全な通信セッションを確立するシステムおよび方法が必要とされているが、従来は利用可能でなかった。このようなシステムは信頼性が高く、堅牢であって、サーバとクライアントとの間の通信セッションが安全であることを保証しなければならない。このようなシステムの別の利点は、ある位置から別の位置に容易に移動可能であるとともに、ワイヤレス・アクセス・ポイントを介してネットワークにアクセスすることによって施設ネットワークに接続可能な移動型サーバを提供することにある。本発明は、これらの必要性および他の必要性に対処する。
【課題を解決するための手段】
【０００８】
本発明は、一般に、ネットワークに接続された一つ以上のサーバと一つ以上のクライアントを備えたシステム内で具体化される。本発明は、一般に、どのクライアントがネットワークに接続されているかを発見し、サーバにクライアントを登録し、サーバとクライアントとの間に安全な通信を提供する方法を実現する。本発明の方法に従ってサーバとクライアントとの間に確立される通信セッションは、いかなる理由で遮断された接続であっても本質的に再確立を実現し、悪意ある、あるいは第三者のサーバのネットワークへの接続の試みを拒否するという点で特に堅牢である。
【０００９】
一態様では、本発明は、ネットワークに接続されたリモート・データ・サーバおよび一つ以上のクライアントを有する。クライアントはネットワーク・インタフェース・モジュールを介して、ネットワークに接続されている。サーバは、ネットワーク上にビーコン・メッセージを周期的に送信する。クライアントはネットワークをリスニングし、クライアントがビーコン・メッセージを受信した場合、そのビーコン・メッセージに状態応答メッセージで応答し、その結果、クライアントをサーバに登録し、サーバは安全な通信セッションを確立することができる。各メッセージは、特定の情報フィールドを有する。一実施形態では、ビーコン・メッセージは特定のポートから送信され、クライアントはそのポートからのみビーコン・メッセージを受信し、そのポートに応答するようにプログラムされている。別の実施形態では、ビーコンおよび状態応答メッセージは、ＵＤＰポート上に送信される。さらに別の実施形態では、一旦サーバが状態応答メッセージを受信すると、サーバはクライアントとのＴＣＰ／ＩＰ接続を開く。
【００１０】
さらに別の態様では、クライアントは、自身が登録されていないサーバから来る任意のビーコン・メッセージを無視するようにプログラムされている。一実施形態では、クライアントは、特定の間隔で分離されていないビーコン・メッセージを無視する。別の実施形態では、クライアントは、既に登録されたサーバからビーコン・メッセージを受信してから、特定の間隔が経過しない限り、第二サーバによって送信された任意のビーコン・メッセージを無視するようにプログラムされている。
【００１１】
別の態様では、本発明は、ネットワーク上に送信されるメッセージを暗号化し、患者のプライバシおよび他のデータを保護する方法を含んでいる。一実施形態では、メッセージはセキュリティ・ヘッダおよびフッタを用いて暗号化され、全メッセージとトランザクション・キーの排他的論理和をとることによって、メッセージのソルトを行った後、ＡＥＳブロック暗号を用いて、メッセージ全体が暗号化される。
【００１２】
本発明のさらに別の態様では、ネットワーク上のサーバとクライアントとの間の接続は、サーバが各クライアントの各終点へＴＣＰ／ＩＰ接続することによって管理される。サーバがクライアントへのＴＣＰ／ＩＰ接続を確立できるようになるだけで、クライアントは登録されていないサーバへ応答しないようになる。
【００１３】
さらに別の態様では、本発明は、施設内の移動型クライアントの位置を判別する方法を提供する。その移動型クライアントは、場合によっては、医療機器内に含まれるプロセッサである。無線接続を用いてクライアントをネットワークに接続する一実施形態では、クライアントを接続するＭＡＣアドレスの識別番号は既知であり、施設内の位置に関連付けられる。別の実施形態では、所定の期間、サーバに登録されず、その結果、「消失」と考えられるクライアントの監視リストを生成できる。監視リスト上のクライアントの一つが電源オンになるか、無線送受信機の範囲内に来ると、ＭＡＣアドレスから判別されるように、その機器のおよその位置のレポートが提供される。
【００１４】
さらに別の実施形態では、本発明は、医療機器等のクライアントの電源を切断するか、保留、待機または節電モードに配置可能なシステムおよび方法を含み、そのクライアントは特定の間隔で「起動」して、サーバに登録され、そのクライアントに接続されたデータベースの任意の更新が利用可能か否かを判別し、利用可能であれば、その更新をダウンロードするようにプログラムされている。一旦ダウンロードが完了すると、クライアントは特定の期間、別の更新を待機し、それから待機節電モードに戻るようにプログラムされている。あるいは、クライアントは、ダウンロードの完了時に、待機または節電モードに戻ることができる。別の構成では、クライアント自体は待機モードのままで、クライアントに関連するネットワーク・インタフェース・モジュールが起動するようにプログラムされている。
【００１５】
さらに別の態様では、本発明は、ワイヤレス・アクセス・ポイントを介してネットワークに接続される移動型サーバを提供することにある。移動型サーバは、ＲＤＳサーバまたは他の情報システムの全ての機能を実行するように構成されており、ネットワーク・ワイヤまたはルータに対する変更を必要とせずに、サーバをある位置から別の位置に容易に移動させることができるような移動性の利点がもたらされる。さらに、ネットワークに接続された機器に対する移動型システム管理がもたらされる。
【００１６】
本発明の他の特徴と利点は、添付図面と共に以降の詳細な説明から明らかになり、その図面は一例として発明の特徴を示している。
【発明を実施するための最良の形態】
【００１７】
以下に、本発明の好ましい実施形態を示す添付図面を参照しながら、本発明をさらに詳しく説明する。ただし、本発明は多くの異なる形態で具体化可能であり、ここで示される実施形態に限定されるものとみなすべきではない。むしろ、この開示内容が詳細で完全なものとなり、発明の範囲を当業者に十分伝えることができるように、これらの実施形態を提供する。同一の符号は、明細書全体を通して同一の構成要素を表している。
【００１８】
当業者には明らかなように、本発明は、方法、データ処理システム、またはコンピュータ・プログラム製品として具現化可能である。従って、本発明は完全なハードウェア実施形態、完全なソフトウェア実施形態、またはソフトウェアとハードウェアを組み合わせた実施形態をとることができる。さらに、本発明はコンピュータ利用可能な記憶媒体上のコンピュータ・プログラム製品の実施形態をとることができ、前記記憶媒体は内部に具現化されたコンピュータ読み取り可能なプログラム・コードを備えている。任意の適切なコンピュータ読み取り可能な媒体を用いることができる。そのような媒体は、ハードディスク、ＣＤ−ＲＯＭ、光学的記憶装置、および磁気記憶装置等を含むが、それらには限定されない。
【００１９】
本発明は、発明の一実施形態に従って、方法、装置（システム）、およびコンピュータ・プログラム製品のフロー図を参照しながら以降に説明される。当然のことながら、フロー図の各ブロック、およびブロックの組合せはコンピュータ・プログラム命令によって実施される。これらのコンピュータ・プログラム命令は、機械を構成するための汎用コンピュータ、専用コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに設けられ、コンピュータまたはプログラム可能なデータ処理装置のプロセッサを介して実行する命令は、フロー図の一つ以上のブロックに指定した機能を実現する手段を生成する。
【００２０】
これらのコンピュータ・プログラム命令はコンピュータ読み取り可能なメモリ内に格納され、コンピュータまたは他のプログラム可能なデータ処理装置を指示して、特定の方法で機能させる。コンピュータ読み取り可能なメモリ内に格納された命令は、フロー図の一つ以上のブロックで指定した機能を実現する命令手段を含む製品を構成する。
【００２１】
コンピュータ・プログラム命令は、コンピュータまたは他のプログラム可能なデータ処理装置上にロードされ、コンピュータ実装処理を行うためのコンピュータまたは他のプログラム可能な装置上で実行する一連の動作ステップを生成する。コンピュータまたは他のプログラム可能な装置上で実行する命令は、フロー図の一つ以上のブロックに指定した機能を実現するためのステップを提供する。
【００２２】
本発明は、スタンド・アロンの計算装置上で実行するシステムとして実装される。好ましくは、本発明は、クライアント／サーバ環境内のシステムとして実装される。当業者には明らかなように、クライアント・アプリケーションは、クライアントとサーバとの関係における要求プログラムである。サーバ・アプリケーションは、同一または他のコンピュータ内でクライアント・プログラムからの要求を待機し、実現するプログラムである。クライアント／サーバ環境は、インターネット等の公的ネットワーク、および「イントラネット」と呼ばれることが多い私的ネットワーク、ローカル・エリア・ネットワーク（ＬＡＮ：Local Area Network）およびワイド・エリア・ネットワーク（ＷＡＮ：Wide Area Network ）、仮想施設通信網（ＶＰＮ：Virtual Private Network ）、フレーム・リレーまたは直接電話接続を含むことができる。当然のことながら、クライアントおよびサーバ・アプリケーションを提供するコンピュータ、またはコンピュータ利用可能な媒体内に具現化されたプログラム・コードを実行するように構成した他の装置を含む、クライアント・アプリケーションまたはサーバ・アプリケーションは、様々な機能を実行する手段として動作し、本発明の様々な動作方法を実行する。
【００２３】
以下の用語および定義は、本発明の様々な態様および実施形態を十分に理解するのに役立つ。従って、これらの用語は、本発明を説明するために、以下のように示される意味を有するものとする。
【００２４】
ＡＥＳは、高度暗号化規格（Advanced Encryption Standard）を意味する。ＡＥＳは、防衛暗号規格（ＤＥＳ：Defense Encryption Standard ）用の次世代規格であり、連邦情報処理規格および国立標準技術研究所によって承認された高安全な対称ブロック暗号アルゴリズムである。
【００２５】
ＣＢＣは、暗号ブロック連鎖（Cipher Block Chaining ）を意味する。ＣＢＣはブロック暗号用の動作モードであり、平文の各ブロックは符号化前に、事前に符号化した暗号文のブロックと排他的論理和をとる。
【００２６】
ＤＨＣＰは、動的ホスト構成プロトコル（Dynamic Host Configuration Protocol ）を意味する。ＤＨＣＰは、ＩＰネットワーク上のクライアントに動的に割り当てたＩＰアドレスを提供する。
【００２７】
ＥＣＢは、電子クック・ブック（Electronic Cook Book）を意味する。ＥＣＢはブロック暗号の動作モードであり、平文の各ブロックは他の全てのブロックと別個に符号化される。
【００２８】
ＩＰは、インターネット・プロトコル（Internet Protocol ）を意味する。ＩＰは、ネットワーク・メッセージを送信するために用いられる単純なアドレス指定プロトコルである。ＩＰには多くのバージョンが存在し、本発明の様々な実施形態は任意のバージョンのＩＰ、好ましくはバージョン４（ＩＰｖ４）を用いて動作するものとする。
【００２９】
ＬＡＮは、ローカル・アクセス・ネットワーク（Local Access Network）を意味する。ＬＡＮは、私的な同質のネットワーク上に接続されたシステムの集まりである。
ＭＤ５は、ＭＤ５メッセージ・ダイジェスト・アルゴリズムを表している。ＭＤ５は、所定のデータ・セットの安全で固有の「指紋」を生成するように設計された複合ハッシュ・アルゴリズムである。
【００３０】
ＮＩＭは、ネットワーク・インタフェース・モジュール（Network Interface Module）を意味し、医療機器をＩＰネットワークに接続し、参加させる機器である。
ＲＤＳは、リモート・データ・サーバ（Remote Data Server）、一般にネットワーク上の医療機器との全ての第三者通信のプロキシとして機能する中央サーバを表している。
【００３１】
ＴＣＰは、伝送制御プロトコル（Transmission Control Protocol ）を意味する。ＴＣＰは、ネットワーク上の二つクライアントの間に、継続的で高信頼性のストリームベースのデータ接続を提供する高レベル・プロトコルである。
【００３２】
ＵＤＰは、ユーザ・データグラム・プロトコル（User Datagram Protocol）を表している。ＵＤＰは、ネットワーク上の二つのクライアントの間に、比較的低信頼性のメッセージベースの通信を提供する低レベル・プロトコルである。
【００３３】
図１は、本発明の態様を用いる患者ケア・システムの概略図である。図１において、患者ケア機器１２は、薬局管理システム３４と病院情報システム・サーバ３０を含む病院ネットワーク１０に接続されている。各要素１２，３０および３４は、伝送チャネル３２によってネットワーク１０に接続されている。伝送チャネル３２は、例えば、８０２．１１無線ローカル・エリア・ネットワーク（ＬＡＮ）等の任意の有線または無線伝送路である。本発明の一実施形態では、ネットワーク１０はさらに、病院全体の様々な部署内に配置されたコンピュータ・システムを含んでいる。例えば、図１のネットワーク１０は、受付３６、会計３８、生物医学技術部４０、実験室４２、中央備品部４４、一つ以上のユニット局コンピュータや医学的判断支援システム４８に接続されたコンピュータ・システムを選択的に含んでいる。さらに、システムは別個のリモート・データ・サーバ４９を組み込むことができ、その機能は以降で詳しく説明する。その上、リモート・データ・サーバ４９は別個のサーバとして示されているが、リモート・データ・サーバ４９の機能およびプログラムは、施設の情報システムの設計技術者が望むのであれば、例えば、病院情報システム・サーバ３０等の別のコンピュータ内に組み込まれてもよい。
【００３４】
患者ケア機器１２は好ましくは、エガーズ他（Eggers et al. ）に対する米国特許第５，７１３，８５６号で説明されているものと同様のシステムを有し、参照することによって本明細書に組み込まれる。また、本明細書で示した開示内容に従って、ポンプ、生理学的モニタ（例えば、心拍数、血圧、ＥＣＧ、ＥＥＧ、パルス酸素計、および他の患者モニタ）、治療機器、および他の薬物送出機器等の他の患者ケア機器を用いることもできる。患者ケア機器１２は好ましくは、一つ以上の機能モジュール１６，１８，２０，２２に接続されたインタフェース・ユニット１４とも呼ばれる制御モジュールを有する。インタフェース・ユニット１４は、例えばランダム・アクセス・メモリ（ＲＡＭ：Random Access Memory）５８等のメモリに接続された中央演算処理ユニット（ＣＰＵ：Central Processing Unit ）５０、およびユーザ・インタフェース機器５４、符号化データ入力機器６０、ネットワーク接続５２、および別のモジュールまたは機器と通信するための補助インタフェース６２等の一つ以上のインタフェース機器を含んでいる。インタフェース・ユニット１４はさらに好ましくは、ソフトウェアおよびデータを格納するための不揮発性主記憶ユニット５６、好ましくはハードディスク駆動装置、および上記の構成要素を相互接続するための一つ以上の内部バス６４を有するが、必ずしも必須ではない。
【００３５】
典型的な実施形態では、ユーザ・インタフェース機器５４は、ユーザに情報を表示し、画面の所定の領域を触れることによって、ユーザが情報を入力できるタッチ・スクリーンである。また、ユーザ・インタフェース機器５４は、モニタ、プリンタ、キーボード、ソフトキー、マウス、トラック・ボールやライト・ペン等、情報を表示および入力するための任意の手段を含むことができる。符号化データ入力機器６０は、好ましくはバーコード形式で印刷したデータを走査および解釈可能なバーコード・リーダである。また、データ入力機器６０は、磁気ストリップ、ＰＣＭＣＩＡスマート・カード、無線カード、メモリ・スティック、ＣＤ、ＤＶＤ、または他の任意のアナログまたはデジタル記憶媒体を読み取る機器等、コンピュータに符号化データを入力する任意の機器であってもよい。データ入力機器６０の他の例は、音声起動機器、音声認識機器または携帯型情報端末（ＰＤＡ：Personal Data Assistant ）を含んでいる。用いられるインタフェース機器の種類に応じて、ユーザ・インタフェース機器５４と符号化データ入力機器６０は、同じ機器であってもよい。また、データ入力機器６０は図１ではインタフェース・ユニット１４内に配置されるように示されているが、当業者には明らかなように、データ入力機器６０は薬局システム３４内に一体化することも、外部に配置し、ＲＳ−２３２シリアル・インタフェースまたは他の任意の適切な通信手段を介して、薬局システム３４と通信することもできる。補助インタフェース６２は好ましくはＲＳ−２３２通信インタフェースであるが、発明の範囲から逸脱することなく、プリンタ、患者モニタ、輸液ポンプまたは他の医療機器等の周辺機器と通信するための他の任意の手段を用いることもできる。また、データ入力機器６０は、モジュール１６，１８，２０および２２のような別個の機能モジュールであってもよく、適切なプログラムおよび通信プロトコルを用いて、制御部１４またはネットワーク上の他の任意のシステムと通信するように構成される。
【００３６】
ネットワーク接続５２は好ましくは、Ｔ１接続、統合サービスデジタル網（ＩＳＤＮ：Integrated Service Digital Network）接続、デジタル加入者線（ＤＳＬ：Digital Subscriber Line ）モデムまたはケーブル・モデム等の直接ネットワーク接続である。また、電話モデム、ＭＩＢシステム、ＲＳ−２３２インタフェース、補助インタフェース、光リンク、赤外線リンク、高周波リンク、マイクロ波リンク、ＷＬＡＮＳ接続または他の無線接続等を含む任意の直接または間接ネットワーク接続を用いることができるが、それらには限定されない。
【００３７】
機能モジュール１６，１８，２０，２２は、患者にケアを提供するか、あるいは患者の状態を監視する任意の機器である。図１に示したように、機能モジュール１６，１８，２０，２２のうちの少なくとも一つは、患者に薬物または他の流体を送出する静脈注射ポンプ等の輸液ポンプ・モジュールであってもよい。この説明のために、機能モジュール１６は輸液ポンプ・モジュールとする。機能モジュール１８，２０，２２は各々、輸液ポンプ、シリンジ・ポンプ、ＰＣＡポンプ、硬膜ポンプ、経腸ポンプ、血圧モニタ、パルス酸素計、ＥＫＧモニタ、ＥＥＧモニタ、心拍モニタ、頭蓋内圧モニタ等を含む任意の患者治療機器または監視機器であってもよいが、それらには限定されない。また、機能モジュール１８，２０，２２は、プリンタ、スキャナ、バーコード・リーダまたは他の任意の周辺入力機器、出力機器または入出力機器であってもよい。
【００３８】
各機能モジュール１６，１８，２０，２２はインタフェース・ユニット１４と直接または間接的に通信し、インタフェース・ユニット１４は機器１２を全体的に監視および制御する。機能モジュール１６，１８，２０，２２は、図１に示し、エガーズ他において詳しく説明されているように、インタフェース・ユニット１４の一端または両端に、直列に物理的かつ電気的に接続されている。しかし、当業者には明らかなように、インタフェース・ユニットと機能モジュールを接続する他の手段も存在し、本発明の範囲から逸脱することなく用いることができる。当然のことながら、十分なプログラム可能性および接続を提供するポンプまたは患者監視機器等の機器は、スタンド・アロン機器として動作でき、別個のインタフェース・ユニットまたは制御ユニット１４を介して接続することなく、ネットワークと直接通信できる。上記のように、一つ以上の補助インタフェース６２を介して、患者ケア機器１２に別の医療機器または周辺機器を接続することができる。
【００３９】
各機能モジュール１６，１８，２０，２２は一般に、モジュール固有部品７６、マイクロ・プロセッサ７０、揮発性メモリ７２および不揮発性メモリ７４を有し、情報を格納する。当然のことながら、図１では四つの機能モジュールが示されているが、中央制御部１４には任意の数の機器を直接または間接的に接続することができる。ここで説明した機能モジュールの種類および数は例示的なものとみなされ、決して本発明の範囲を限定するものではない。モジュール固有部品７６は、輸液ポンプ１６のポンプ機構等、特定のモジュールの動作に必要な任意の部品を含んでいる。
【００４０】
各機能モジュールは一般に、少なくともいくつかのレベルの独立した動作を可能とするが、インタフェース・ユニット１４は機器１２の全体的な動作を監視し、制御する。例えば、以降でさらに詳しく説明するように、インタフェース・ユニット１４は機能モジュール１６，１８，２０，２２にプログラム命令を提供し、各モジュールの状態を監視する。
【００４１】
患者ケア機器１２はいくつかの異なるモードまたは属性で動作可能であり、各属性は構成データベースで定義される。特定の構成データベースは、患者の場所、年齢、身体特性、または医療特性等の患者固有の情報に基づいて少なくとも部分的に選択される。医療特性は、患者の診断、治療処方、病歴、医療記録、患者ケア提供者識別番号、生理学的特性または心理学的特性等を含むが、それらには限定されない。ここで用いられるように、患者固有の情報はさらに、ケア提供者情報（例えば、医師識別番号）または病院内または病院コンピュータ・ネットワーク内での患者ケア機器１０の位置を提供する。患者ケア情報は、インタフェース機器５２，５４，６０または６２を介して入力される。例えば、薬局３４、受付３６、実験室４２等、ネットワーク１０内の任意の場所からもたらされる。
【００４２】
様々なデータ源とやり取りするデータは既存の技術を用いて、ネットワーク互換データに変換され、医療機器とネットワークとの間の情報の移動は様々な手段によって実現される。例えば、患者ケア機器１２とネットワーク１０とは、自動インタラクション、手動インタラクションまたは自動および手動のインタラクションの両方の組合せによって通信される。自動インタラクションは連続的または断続的であってもよく、直接ネットワーク接続５４（図１に示したように）を介して、またはＲＳ２３２リンク、ＭＩＢシステム、ブルートゥース（カリフォルニア州サンノゼ、Ａｍｔｅｌ社）、ＩＲリンク、ＷＬＡＮＳ、デジタル・ケーブル・システム、電話モデムまたは他の有線または無線通信手段を介して発生させてもよい。患者ケア機器１２とネットワーク１０との間の手動インタラクションは、例えば、ユーザ・インタフェース機器５４、符号化データ入力機器６０、バーコード、コンピュータ・ディスク、携帯型情報端末、メモリ・カード、またはデータを格納する他の任意の媒体を用いて、システム間でデータを間欠的または周期的、物理的に転送することを含んでいる。好ましくは、通信手段は、分散されたデータ源のできるだけ多くの点からデータに双方向にアクセスする。意志決定は、ネットワーク１０内の様々な場所で発生する。例えば、病院情報システム・サーバ３０、判断支援４８、リモート・データ・サーバ４９、病院部局またはユニット局４６、または患者ケア機器１２のそれ自体内で意志決定を行うことができるが、それらには限定されない。
【００４３】
本発明の態様を組み込んだクライアント／サーバ環境は一般に、コンピュータ・ネットワークを介して、少なくとも一つのクライアントがアクセス可能な中央サーバを含んでいる。より複雑なシステムでは、中央サーバは、例えば、イーサネット（登録商標）、無線ネットワーク、またはインターネット等のコンピュータ・ネットワークを介して、少なくとも一つのローカル・サーバによってアクセスされ、次にローカル・サーバがクライアントによってアクセスされる。ＴＣＰ／ＩＰを含むがそれには限定されない様々なコンピュータ・ネットワーク転送プロトコルは、ネットワーク上で用いられる通信プロトコルと互換性のある通信機能を備えるように構成された中央サーバ、任意のローカル・サーバ、およびクライアント機器の間での通信を可能にするために用いられる。
【００４４】
中央サーバは一般に、その上で実行するＭｉｃｒｏｓｏｆｔ（登録商標）  ＳＱＬ  Ｓｅｖｅｒアプリケーション・プログラム・バージョン６．５（ワシントン州レドモンド、Ｍｉｃｒｏｓｏｆｔ，Ｉｎｃ．から入手可能）等の中央データベースを含んでいる。中央サーバは、ローカル・サーバが最新バージョンの知識ベースを実行していることを保証し、さらに全ての患者データを格納し、システムにローカル・サーバおよびユーザを追加および削除することを含む様々な管理機能を行うことができる。中央サーバはさらに、ユーザがローカル・サーバまたはクライアント医療機器を利用可能になる前に許可を行う。上記のように、一般的な統合型システムでは、患者データは好ましくは中央サーバに格納され、それによって患者データの中央レポジトリを提供する。しかし、当然のことながら、患者データは、ローカル・サーバ、ローカル記憶媒体、または別の病院または施設のサーバや情報システム上に格納でき、必要に応じて、システムの様々な要素、つまりローカル・サーバやクライアントを介してアクセスすることができる。
【００４５】
各ローカル・サーバは一般に、地理的位置における複数のユーザにサービスを提供する。各ローカル・サーバの例は、病棟内、看護婦室、または主情報またはバックアップ情報の収集、経路指定、解析や記憶システムとして動作する現場外または離れた場所に配置したサーバを含んでいる。各ローカル・サーバは一般に、サーバ・アプリケーション、一つ以上の知識ベース、およびローカル・データベースを有する。各ローカル・サーバはさらに、適切な医療や薬物送出および処方診療に従うことを保証する一連の規則または診療基準とやり取り可能な推論システムを含むこともできる。各ローカル・サーバはさらに、本発明の動作を実行する人工知能処理を行うこともできる。ユーザがクライアントを介してログオンすると、当業者には明らかなように、好ましくは識別番号およびパスワードを介して認証される。一旦認証されると、ユーザはシステムへのアクセスが許可され、特定の管理特権が割り当てられる。また、システムの動作をプログラムし、バーコード・ラベル、ＲＦ識別タグまたは機器、または他のスマート、受動型、能動型識別機器等の、患者、ケア提供者および薬物識別機器を用いて、システムのユーザを識別し、患者を診断および治療するシステムにアクセスできるようにする。
【００４６】
各ローカル・サーバはさらに中央サーバと通信を行い、要求中のローカル・サーバ上で最新版の知識ベースおよびアプリケーションが実行中であることを確認することもできる。最新版でない場合は、要求中のローカル・サーバは、ユーザ・セッションが確立される前に、正当な最新の知識ベースやアプリケーションを中央サーバからダウンロードする。本発明のいくつかの実施形態では、データおよび人工知能処理等、最も計算上集約的作業をローカル・サーバ上で実行するが、「小型軽量クライアント」（つまり最小のハードウェアを備えた計算機器）および最適システム速度も可能であり、本発明はさらにクライアント上でデータ処理および規則処理を実行し、このようなタスクから中央システム、またはローカル・サーバを解放するシステムを含むものとする。
【００４７】
各ローカル・クライアントまたは医療機器はさらに、一般にグラフィカル・ユーザ・インタフェース（ＧＵＩ：Graphical User Interface）からなるクライアント・アプリケーション・プログラムを含んでいるが、このようなものは多くの医療機器、および中央サーバまたはローカル・サーバと通信する中間層プログラム上では不要である。クライアント・アプリケーション・プログラム用のプログラム・コードは全体的にローカル・クライアント上で実行可能であり、部分的にローカル・クライアント上で実行し、部分的に中央またはローカル・サーバ上で実行することもできる。
【００４８】
本発明の動作を実行するコンピュータ・プログラム・コードは好ましくは、例えばＪＡＶＡ（登録商標）、スモールトーク、またはＣ＋＋等のオブジェクト指向プログラム言語で作成される。しかし、本発明の動作を実行するコンピュータ・プログラム・コードは、Ｃプログラム言語等の既存の手続き型プログラム言語、Ｐｅｒｌ等のインタプリタ型スクリプト言語、Ｌｉｓｐ、ＳＭＬ、Ｆｏｒｔｈ等の関数型（または第四世代）プログラム言語で作成することもできる。ソフトウェアはさらに、ＨＬＡ−７要件に適合するように作成することもできる。
【００４９】
次に、本発明の典型的な実施形態について説明する。一般に、本発明の態様を組み込んだ医療機器はネットワーク・インタフェース・モジュール（ＮＩＭ：Network Interface Module）を備え、医療機器はネットワーク内のノードとして参加できる。簡略化のために、本発明はインターネット・プロトコル（ＩＰ：Internet Protocol ）を用いて、イーサネット・ネットワーク環境で動作するものとして説明されるが、当業者には明らかなように、本発明の概念は同様に他のネットワーク環境に適用することもでき、このような環境は本発明の範囲内にあるものとする。
【００５０】
本発明に従ってネットワーク上で動作する医療機器との直接通信は全て、リモート・データ・サーバ（ＲＤＳ：Remote Data Server）と呼ばれる中央サーバを介して実行される。本発明の態様によると、例えば輸液ポンプまたは生存徴候測定機器等の医療機器に組み込んだネットワーク・インタフェース・モジュールは、認証済みのＲＤＳに起因しない全てのネットワーク・トラフィックを無視する。本発明のＲＤＳの主な責任は、ＮＩＭを備え、ネットワーク上の全ての医療機器の場所と状態を追跡し、それらとの通信チャネルを開いたままで維持することである。
【００５１】
本発明の典型的な実施形態では、ＲＤＳがネットワーク上の医療機器を発見、接続する。それと通信する手段を含むソフトウェアおよび通信プロトコルのアーキテクチャは例えば、イーサネットＬＡＮ環境内で動作する。ＬＡＮ上の任意の二つのノードの間のデータの名目上のラウンド・トリップ・タイムは一般に１秒未満であり、ネットワーク上の各リンクは一般に少なくとも１Ｍｂｐｓの維持速度でデータを送信できる。全ネットワーク帯域幅の１０％以下が所定の時間に利用可能であれば、典型的なネットワークは効率的に稼働中であるとみなされるが、当然のことながら、無線ネットワーク環境で発生するように、ノードは間欠的ネットワーク接続を被ることがあり、このような接続の中断は重要性および持続時間の両方で大きく変化する。
【００５２】
図２は、本発明を最も簡単な実施形態で示している。この実施形態では、本発明の原理によるシステムは単一のリモート・データ・サーバ１０５と、例えば、イーサネット・ケーブル１２０等の適切な通信手段を介して、共に接続されたネットワーク・インタフェース・モジュール１１５に取り付けた単一の医療機器１１０からなる。ＲＤＳ１０５とＮＩＭ１１５との間の接続はイーサネット・ケーブル１２０によって示されているが、当業者には明らかなように、有線または無線の任意の手段を用いて、ＲＤＳ１０５とＮＩＭ１１５とを互いに通信するように配置し、それらの間に情報の流れを提供する。
【００５３】
本発明の態様に従って動作するより複雑なシステムが、図３に示されている。この実施形態では、システムは主ＲＤＳ１３０と、ルータ１４０を介してイーサネット１４５に接続されたバックアップＲＤＳ１３５を有する。イーサネット１４５を介して、ＲＤＳ１３０，１３５で通信される情報は、ルータ１５０，１５５，１６０および送受信無線アクセス・ポイント１６５，１７０，１７５を介して、医療機器１８０，１８５，１９０に通信される。上記のように、医療機器１８０，１８５および１９０はネットワーク・インタフェース・モジュールを有し、前記ネットワーク・インタフェース・モジュールは無線アクセス・ポイント１６５，１７０および１７５と情報を無線送受信するための適切な回路を含んでいる。当然のことながら、ネットワークの大きさおよび複雑さは、図３に示したものに限定されない。ただし、ネットワークの大きさや複雑さは、発見と接続に用いられるプロトコルに依存しない。
【００５４】
さらに、情報は、ルータ１９５およびファイアウォールまたはインターネット・プロキシ２００を介して、インターネットまたはイントラネット２０５等の別のシステムとやり取りされる。この方法では、第三者のシステムまたは機器は、医療機器１８０，１８５，１９０と通信できる。さらに以降で詳しく説明するように、本発明のシステムのアーキテクチャおよび動作は、ネットワーク内の情報の安全な流れを提供する。第三者の機器（図示せず）がネットワーク上の医療機器１８０，１８５，１９０との通信を希望すると、イーサネット１４５を介して、ＲＤＳ１３０または１３５等の起動中のＲＤＳにそれらの要求を送信することによって通信を行う。それから、ＲＤＳは、可能であれば、第三者の機器の代わりに、ネットワーク上の医療機器に要求を行う。第三者の機器は、そのＮＩＭを介して、ネットワーク上の医療機器と直接通信を開始することは決してない。この方法では、外部の第三者の機器はネットワーク上の医療機器との通信を起動できないので、通信セッションのセキュリティが保証される。ＲＤＳを介して開始しない第三者の要求は全て無視される。
【００５５】
アドレス指定
本発明の好ましい実施形態では、システムの接続プロトコルはＩＰ／イーサネット上で動作する。この実施形態では、システム内の各ＮＩＭには、通信を可能にするために一意的なＩＰアドレスが割り当てられる。ＩＰアドレスを静的に割り当てることもできるし、ユーザは動的アドレス割り当てのためにＤＨＣＰを用いることを選択することもできる。両方の方法が、ＮＩＭによってサポートされている。
【００５６】
冗長的サーバ
医療機器１８０，１８５および１９０との通信は全てＲＤＳを介して経路指定されるので、ＲＤＳがシステム内の最も重要な障害点となる。耐障害性を増強したいエンド・ユーザは、主ＲＤＳ１３０とバックアップＲＤＳ１３５によって図３に例示したように、そのネットワーク上に一つ以上の冗長的ＲＤＳをセットアップすることを選択できる。このような冗長性は本発明の接続プロトコルによって十分にサポートされ、冗長的サーバは一般に能動型／受動型構成でセットアップされる。
【００５７】
冗長的クラスタ内のＲＤＳ１３５等のバックアップ・リモート・データ・サーバをネットワークに直接接続し、一意的なＩＰアドレスを割り当てることも、従来から知られているように、変換ルータ（図示せず）を介して接続し、全てが同じＩＰアドレスを有するようにすることもできる。本発明を組み込んだ動作システムの接続プロトコルは、両方の構成をサポートしている。
【００５８】
負荷バランシング
複数のサブネットが存在する非常に大きなネットワークでは、冗長的クラスタを用いてサブネットを論理的グループに分割し、別個のリモート・データ・サーバを各グループに割り当てることによって、負荷バランシングを行うことができる。このようなシステム上の唯一の制限は、一つ以上のＲＤＳが単一のサブネットにサービスを提供できないことである。ＲＤＳとＮＩＭとの間の接続のセキュリティを保証するために、そのローカル・サブネット上に動作中のＲＤＳを一つ以上検出した場合、ＮＩＭは一般にＲＤＳへの応答を拒絶するようにプログラムされる。
【００５９】
図３に示したように、ネットワーク、ここではイーサネットは、医療機器と主ＲＤＳおよびバックアップＲＤＳとの間の情報の通路として機能する。イーサネットはさらに、ファイアウォールやインターネット・プロキシを介してインターネットに接続される。一般に、インターネット・アクセスおよびＲＤＳサーバ管理はどちらも、適切なルータを介してイーサネットと通信する。図のように、複数の医療機器をイーサネットに接続し、それからＲＤＳと通信することもできる。図３に示したように、医療機器は、無線アクセス・ポイントに信号を提供する適切なルータを介してイーサネットと通信する。医療機器は同報通信の信号を受信し、さらに無線アクセス・ポイント上に信号を送信し、それから所望の宛先までイーサネット上で通信できる。また、医療機器はイーサネットに有線接続し、無線アクセス・ポイントを不要にすることもできる。さらに別の方法では、ルータと無線アクセス・ポイントを単一ユニットに組み合わせることもできる。
【００６０】
ソフトウェア・アーキテクチャ
図４は、本発明のソフトウェア・アーキテクチャの典型的な実施形態を示している。図４に示したように、ＲＤＳ２５０およびＮＩＭ２５５上のソフトウェア・スタックは同じように見えるが、以降で説明するように、アプリケーション層２６０，２８０で実行するソフトウェアはかなり異なり、ＲＤＳ２５０およびＮＩＭ２５５の異なる機能を反映させることができる。ＲＤＳ２５０の発見および接続管理プロトコル層２７５と、ＮＩＭ２５５の発見および接続管理プロトコル層２９０は、アプリケーション・レベル２７５，２９５と接続レベル２６５，２９０との間のＲＤＳおよびＮＩＭシステム上のソフトウェア・スタックに適合する。ＮＩＭ２５５上では、動作プログラムの発見および接続管理層２９０は、正当なＲＤＳ２５０を備えたＮＩＭ２５５に接続された医療機器の配置および登録する役割を担う。ＲＤＳ２５０上では、発見および接続管理層２７０は、全ての動作中のＮＩＭ２５５のリストを維持する役割を担う。ＲＤＳ２５０およびＮＩＭ２５５のどちらの側も互いの間のＴＣＰ／ＩＰ接続を維持し、各アプリケーション層２７５，２９５の代わりに、それらの接続上でデータを送受信する役割を担う。
【００６１】
発見および接続管理層２７０，２９０の各々の下のＲＤＳ２５０の層２６５，２６０およびＮＩＭ２５５の２８５，２８０は標準的なＴＣＰ／ＩＰスタックを表しており、その用語は当業者には明らかであり、ＲＤＳ２５０およびＮＩＭ２５５の両方で一般に同じである。アプリケーション層２７５，２９５は、接続層２７０，２９０のインタフェースとなる任意の高レベル・ソフトウェア・プログラム・コードを含んでいる。
【００６２】
発見
ＲＤＳ２５０とＮＩＭ２５５に接続されたた機器との間で通信が発生可能になる前に、二つのシステムは互いにネットワーク上に位置し、接続を確立しなければならない。この処理は、この説明のために発見と呼ばれる。
【００６３】
ＲＤＳビーコン
本発明のシステムおよび方法を組み込んだＲＤＳ２５０が、ＮＩＭ２５５に接続された医療機器と通信を開始し、サービスを提供することを準備する際、ＲＤＳ２５０はネットワーク全体に特別な「ビーコン・メッセージ」の送信を開始する。このビーコンの目的は、様々な医療機器に接続されたＮＩＭ２５５に対して、ネットワーク上にＲＤＳ２５０が存在することを警告することにある。ビーコンは、ネットワーク上のＵＤＰ同報通信を介して、ＲＤＳ２５０がサービスを提供する各サブネット上の既知のポートに送信される。前記ネットワークはイーサネットであっても、無線ネットワークであってもよい。ＮＩＭ２５５は、通信するＲＤＳ２５０の位置の発見を開始する際、このビーコンをリスニングするようにプログラムされている。また、ＮＩＭ２５５は、ビーコン信号またはメッセージを周期的に検索するようにプログラムされていてもよい。この実施形態では、この周期的にビーコンをリスニングすることは、通信リンクが何らかの理由で消失した場合に、ＲＤＳ２５０との接続を再確立するのに役立つ。
【００６４】
この好ましい実施形態では、本発明によるＲＤＳビーコン信号またはメッセージは一般に、サービスを提供するサブネット上に一定の間隔（一般に１秒）で同報通信される。一般に、ＲＤＳ２５０はオフラインになるまで、永久にビーコン・メッセージを同報通信する。一旦接続すると、ネットワークに接続された各医療機器のＮＩＭ２５５は（様々な理由で）ビーコンをリスニングし続け、所定の期間内にビーコンを受信しなければ、ＲＤＳ２５０との接続を終了するので、ＲＤＳ２５０はビーコン・メッセージを同報通信し続ける。
【００６５】
図５は、ＲＤＳビーコン・メッセージの一実施形態のデータ形式を示している。メッセージは複数のフィールドからなり、特定のフィールドに依存して異なるデータ長を備えている。好ましくは、１バイトより長いデータ・フィールドが全てリトルエンディアン形式で格納され、この実施形態のビーコン・メッセージの全サイズは決して５１２バイトを超えないが、これより大きな有効ビーコン・メッセージを構成することもでき、このようなメッセージも本発明の範囲内にあるものとする。暗号化の追加層を適用して、さらにセキュリティを改善して送信することもできる。ビーコン・メッセージの各フィールドについては、以降で詳しく説明する。
【００６６】
メッセージＩＤ
ビーコン・メッセージの第一バイトは、メッセージＩＤである。このバイトは一定であり、ＲＤＳビーコンとしてメッセージを識別するために用いられる。
【００６７】
登録モジュロおよびキー
特定の種類のグローバル・ネットワーク障害（例えば、ルータの再起動等）は、動作中のＲＤＳ／ＮＩＭネットワーク内の通信を一時的に遮断することがある。このような遮断の影響は、影響を受けた各ＮＩＭがＲＤＳとの接続を遮断し、ＲＤＳに再登録しようとすることである。このような中断の後、一旦接続が回復すると、潜在的に数千の同時の登録要求によってＲＤＳは過負荷になることがある。従って、ビーコン・メッセージは絞り機構を有し、このような状態でのＲＤＳ上の負荷を低減する。
【００６８】
本発明の一実施形態において、図５を再び参照すると、ＮＩＭがＲＤＳから正当なビーコン・メッセージを受信すると、ＮＩＭはビーコン・メッセージの登録モジュロ・フィールド内に含まれるデータを用いて、そのＩＰアドレスのモジュロを計算する。結果がビーコン・メッセージの登録キー・フィールド内に格納された値と等しい場合、このような応答が正当であれば、ＮＩＭはＲＤＳに単一の発見応答メッセージを送信することを許可される。ＮＩＭのＩＰアドレスのモジュロがビーコン・メッセージの登録キー・フィールドと一致しない場合、ＮＩＭは沈黙したままで、応答するまで次のビーコンを待機する。一般的な好ましい実施形態では、ビーコン・メッセージの登録モジュロ・メッセージ内に格納される値は決して２未満にはならず、登録キー・フィールドに格納される値は常に登録モジュロ・フィールド内に格納される値より小さい。当業者には明らかなように、計算の基本としてＩＰアドレスを用いる必要はなく、意図した発明の範囲から逸脱することなく、機器の一意的な任意の値を用いることができる。
【００６９】
閉終点リスト
ＮＩＭとのネットワーク接続が消失すると、ＲＤＳはＮＩＭとのＴＣＰ／ＩＰ接続をタイムアウトにすることによって、ＮＩＭとの通信セッションを終わらせるようにプログラムされている。このことが発生すると、ＴＣＰ／ＩＰ接続を打ち切って閉じ、閉じたＴＣＰ／ＩＰ接続のＩＰアドレスとポート番号の形態で、ビーコン・メッセージ内に閉じたことについての通知を配置する。本発明の一実施形態では、閉通知を有する三つの固定サイズ・フィールドと二つの可変長フィールドという五つの別個のフィールドがあり、これ以降は閉終点データと呼ぶ。
【００７０】
閉終点データの第一固定長フィールドは、閉終点リスト開始オフセット・フィールドである。このフィールドは、閉終点リストを発見できるビーコン・メッセージ内のオフセット（バイト単位）を有する。このオフセットは、ビーコン・メッセージの最初から開始される。
【００７１】
閉終点データの次の固定長フィールドは、閉終点リスト入力カウント・フィールドである。このフィールドは、ビーコン・メッセージの終わりで、可変長のＩＰアドレスおよびポート番号のフィールド内に列挙される閉終点数を有する。
【００７２】
閉終点データの第三固定長フィールドは、閉終点リスト入力寿命フィールドである。このフィールドは、各閉終点が列挙される連続したビーコン・メッセージの数を有する。例えば、この値が５であり、ＴＣＰ／ＩＰ接続がＲＤＳによって閉じられた場合、次の利用可能なビーコン・メッセージ内に閉終点データを配置し、それから次の４ビーコン・メッセージの間、繰り返す。閉終点リスト入力寿命フィールドの値は、決して１未満にはならない。
【００７３】
図５に示したように、閉終点用の実際のデータは、ビーコン・メッセージの終わりで可変長フィールド内に格納される。閉終点データは、閉じられたＴＣＰ／ＩＰ接続のＩＰアドレスおよびポート番号からなる。これらの値は各々４バイトおよび２バイトの長さであるので、共にメッセージ内に配置されると位置あわせの問題が発生し得る。フィールド長を適合させるためのデータを埋め込む時間および空間の無駄を避けるために、ＩＰアドレスおよびポート番号はそれら自体のリスト内に別個に格納される。これらのリストは、その要素が互いに対応する、つまり、各リストのステップを踏む際、第一ＩＰアドレスは第一ポートと同期させ、第二アドレスは第二ポートと同期させる等というように構成される。これは、ＩＰアドレスおよびポート番号の数が常に等しいことを意味するが、いくつかの実施形態ではＩＰアドレスおよびポート番号の数が異なることも可能であるが、適切な埋め込みまたは既定値の空白は避けなければならない。
【００７４】
ビーコン間隔
図５を再び参照すると、閉終点リストの第二可変長フィールドは、ビーコン間隔フィールドである。このフィールドは、ＲＤＳがどの程度の頻度でビーコン・メッセージのパケットを送信するかを示す値を有する。一般に、この値はミリ秒単位で表され、その値が１０００（１秒）以上である場合に、プログラムが最も効率的になることを発明者は見出しているが、値が１０００未満であっても処理は許容可能なように機能するが、資源管理およびデータ・フローの点では効率的ではない。
【００７５】
時間
図５に示した三つのタイムスタンプ・フィールドは、ＲＤＳからの現在の時間および日付を含んでいる。この情報は、必要であれば、リモート機器のクロックとＲＤＳのクロックとを同期化させるために用いることができる。一般に、この実施形態では、国際化や夏時間調整等の問題を避けるために、ＵＴＣ時刻で提供される。しかし、システム全体がＵＴＣ時刻以外の標準時に従って動作中である場合、ネットワークの全ての機器に適合する限り、適切な標準時を用いることができる。
【００７６】
本発明の一実施形態では、第一タイムスタンプ・フィールド、つまりＵＴＣ年の時刻フィールドは、現在の年の１月１日の午前１２：００から経過する時間を数百秒有し、第二タイムスタンプ・フィールド、つまりＵＴＣ年フィールドは現在のＵＴＣ暦年を有する。ローカル時刻オフセット・フィールド、つまり第三タイムスタンプ・フィールドは、ローカル時刻とＵＴＣ時刻の間の違いを一般に分単位で表す符号付きの値を有する。
【００７７】
将来的なデータ
図５に示したＲＤＳメッセージ・ビーコンの領域は、「追加データ可能（将来的な改訂）」というラベルを付けて、将来的に固定サイズのフィールドをビーコン・メッセージに追加可能な空間を提供し、ビーコン・メッセージの増強または拡張を可能にする。閉終点データ・フィールドは可変長であり、ビーコン・メッセージの構文解析を行い、他の固定サイズ・フィールドにアクセスして、容易に計算を実現するために、メッセージの終わりに配置することが最善であるので、この方法でメッセージ・ビーコンを将来変更できるようにすることが望ましい。一般に、ネットワーク上の全てのＮＩＭまたは選択されたＮＩＭに生成されたソフトウェアの改訂等、特にプログラムされない限り、ＮＩＭ上で実行中のソフトウェアは余分なデータを想定し、そのデータを無視する。
【００７８】
ＮＩＭ状態応答
本発明の好ましい一実施形態では、ＮＩＭは常にメッセージの入力に対して選択されたＵＤＰポート上をリスニングし、正当なＲＤＳビーコン・メッセージであるか否かを確認するために、受信した各メッセージをチェックする。受信したメッセージが正当なＲＤＳビーコン・メッセージであり、以降でさらに詳しく説明する特定の条件に適合する場合、ＮＩＭはビーコン・メッセージを発信したＲＤＳサーバ上のＵＤＰポートにＮＩＭ状態応答メッセージを送り返すことによって、ＲＤＳビーコンに応答する。
【００７９】
図６は、ＮＩＭ状態応答メッセージの一実施形態のデータ形式を示している。ビーコン・メッセージと同様に、１バイトより大きな長さを備えた全てのデータ・フィールドは一般に、リトルエンディアン形式で格納される。一実施形態では、ＮＩＭ状態応答メッセージの全サイズは一般に５１２バイトを超えないが、５１２バイトを超える正当な状態応答メッセージを構成することもでき、このようなメッセージは本発明の範囲内にある。また、上記のＲＤＳビーコン・メッセージと同様に、状態応答メッセージに追加の暗号層を適用し、メッセージのセキュリティを拡張して送信することもできる。ＮＩＭ状態応答メッセージの各フィールドについては、以降で詳しく説明する。
【００８０】
メッセージＩＤ
図６に示したように、状態応答メッセージの第一バイトはメッセージＩＤフィールドである。このバイトは一定であり、ＮＩＭ状態応答メッセージとしてメッセージを識別するために用いられる。
【００８１】
接続済み／リスニング中終点リスト
図６に示した状態応答メッセージの実施形態の次のフィールドは、終点リスト開始オフセット・フィールドである。一般に、ＮＩＭは、例えば、ＵＳＢハブ等を介して、直ちにいくつかのクライアント機器に接続を提供できるようにプログラムされている。ＲＤＳからのアプリケーション・レベル・メッセージを処理可能なＮＩＭに取り付けた各機器は終点とみなされ、ＮＩＭによるＲＤＳへのそれ自体の専用ＴＣＰ／ＩＰ接続を与えられる。ＮＩＭが状態応答メッセージを送信したとき、それはＲＤＳが接続を生成可能なＴＣＰ／ＩＰポートのリストの形式で、利用可能な各終点のリストを有する。このリストは、現在ＲＤＳに正当な接続を有するポート、およびＲＤＳへの新しい接続を開くことができるようにビーコンをリスニング中のポートという二つのサブグループに分割されている。
【００８２】
終点リスト開始オフセット・フィールドは、状態応答メッセージ内のオフセットを表す値をバイト単位で有し、そこに終点ポート番号のリストを見つけることができ、オフセットは状態応答メッセージの最初から開始される。終点ポートのリストは単なるＴＣＰ／ＩＰポート番号のアレイであり、各入力は２バイトの長さである。一実施形態では、リストの第一部分は接続済み終点の全てのポート番号を有し、その直後にリスニング中の終点のポート番号を有する。
【００８３】
接続済み終点カウント・フィールドは、ＲＤＳへの正当な接続を現在備えている終点の数を表す値を有する。リスニング中終点カウント・フィールドは、ＲＤＳからの新しい接続のためにリスニング中の終点の数を表す値を有する。これらのフィールドの値はどちらも所定の時刻にゼロであってもよく、接続済み終点カウント・フィールドとリスニング中終点カウント・フィールドの合計は一般に２５５を決して超えないが、ＲＤＳサーバがメッセージを構文解析し、読み取ることができるように、メッセージ内の他の指標の長さを適切に調整すれば、より長いフィールドを用いることもできる。
【００８４】
将来的なデータ
ＲＤＳビーコン・メッセージと同様に、ＮＩＭ状態応答メッセージは、将来的なバージョンで利用可能な領域をメッセージ文字列内に設けることによって、固定サイズ・データ・フィールドと可変長データ・フィールドとの間で将来的に拡張することができる。状態応答メッセージのこの領域は、本発明のプロトコルの将来的な実装がメッセージ内に余分なデータを想定し、それを無視することを保証する。
【００８５】
ＮＩＭ発見フロー
図７は、本発明の発見方法の典型的な一実施形態のフローをシステム内のＮＩＭの観点から示すフロー図である。ＲＤＳのフローは一般に終点キャッシュを管理することに主に着目しているので、ＮＩＭ側の接続から発見処理を観察することが望ましい。
【００８６】
ＮＩＭが開始する際、それは選択されたポート上のビーコン・メッセージをリスニングすることによって始まる。好ましい実施形態では、ＮＩＭは一般に同じＩＰアドレスおよびポート番号から、正当なビーコン・メッセージを少なくとも５個連続的に受信し、ビーコン・メッセージ内に含まれるビーコン間隔の少なくとも７５％が各ビーコン・メッセージの間で発生するまで、ビーコン・メッセージに応答を試みないようにプログラムされている。この条件は、ＲＤＳになりすまし、ＮＩＭに取り付けられた機器の制御を得ようとする悪意あるシステムによって、ＮＩＭがだまされないようにするという点で、システムのセキュリティを改善するという利点がある。このシステムの別の利点は、ＮＩＭが重複するビーコン・メッセージを受信し、ＮＩＭとの通信を試みる別のサーバまたはサブネットを示す場合、ＮＩＭが重複するビーコン・メッセージを無視し、ＮＩＭが受信したビーコン・メッセージのサーバをいずれも登録しないことにある。
【００８７】
一旦ＮＩＭのプログラム・ロジックが正当なＲＤＳビーコン・メッセージを受信したと確信すると、ＮＩＭはビーコン・メッセージを構文解析し、ＮＩＭ状態応答メッセージをコンパイルすることによって登録処理を開始する。本発明の多くの実施形態では、ＮＩＭはビーコン・メッセージ内の登録モジュロおよびキー・フィールドをチェックし、それ自体がＲＤＳに直ちに報告可能であるか否かを判別するようにプログラムされている。直ちに応答が必要であるか、あるいはこのビーコン・メッセージをスキップし、後のビーコン・メッセージに応答するかをチェックすることは、名目上の発見速度を改善するように設計された最適化方法である。上記のように、多数のＮＩＭへのネットワーク接続が消失し、その後、回復する結果、ＲＤＳの登録要求が殺到する可能性がある場合に、この最適化ステップが役に立つ。
【００８８】
ＲＤＳビーコン・メッセージが正当であることをＮＩＭが判別すると、ＮＩＭは、ＲＤＳビーコン・メッセージを常に監視するモードになる。ビーコン閉終点リスト内にＮＩＭの終点が列挙されているか否かを確認するために、ＲＤＳから受信した各ビーコン・メッセージを検査する。列挙されているのであれば、列挙された終点のＴＣＰ／ＩＰ接続がタイムアウトになり、ＲＤＳによって閉じられたことを意味し、ＮＩＭは同じことを行い、ＲＤＳとＮＩＭとが互いに同期していることが保証される。ＮＩＭが閉終点リスト内にその終点を一つ以上備えたビーコンを見つけると常に、要求された接続を閉じた後、ＮＩＭは状態応答メッセージを送信することを必要とされる。これは、登録モジュロおよびキー・フィールドの値にかかわらず行われる。
【００８９】
ビーコン・メッセージの閉終点リスト内に終点が列挙されていない場合、ＮＩＭは登録マスクおよびキー・フィールドを調べ、ＲＤＳに変更を報告するためのウィンドウが到着しているか否かを判別する。到着していない場合、ＮＩＭは単に次のビーコン・メッセージを待機する。ＮＩＭのウィンドウが到着している場合、ＮＩＭの終点がいずれも接続されておらず、新しいＴＣＰ／ＩＰ接続をリスニング中であれば、ＮＩＭはＲＤＳに状態応答メッセージを送信する。
【００９０】
図７に示した処理をさらに詳しく説明すると、ＮＩＭはボックス４００で開始し、ＮＩＭの処理はボックス４０５で最後の既知のＲＤＳ位置をＩＰアドレスの０．０．０．０に設定し、前のビーコン発信源を０．０．０．０に設定する。ＮＩＭはさらにボックス４０５で、ビーコン・カウンタをゼロに設定し、ビーコン・タイムアウト期間を無限に設定する。ＮＩＭはさらに、ビーコン・タイムアウト期間が経過したときに起動するために、ボックス４１０でビーコン・タイマをリセットする。
【００９１】
それから、ＮＩＭはボックス４１５で、例えばＵＤＰポート３６１３（または他のいくつかの選択されたポート）上で受信すべき正当なＲＤＳビーコン・メッセージ、またはビーコン・タイマの期限切れを待機する。ＮＩＭの動作プログラムはボックス４２０で、ビーコン・タイムアウト期間内に正当なビーコン・メッセージを受信したか否かを解析する。正当なビーコン・メッセージを受信した場合、処理はボックス４２５に進み、ＮＩＭはビーコン・メッセージの発信源アドレスおよびポート番号が最後の既知のＲＤＳ位置に適合するか否かを判別する。ボックス４２０で正当なビーコン・メッセージを受信しなかった場合、処理はボックス４３０に分岐し、ＮＩＭはこのＩＰアドレス用のＮＩＭ終点接続をリセットし、ボックス４１５に戻り、受信すべき正当なＲＤＳビーコン・メッセージを待機する。
【００９２】
ボックス４２０で正当なビーコン・メッセージを受信し、ボックス４２５で発信源アドレスおよびポート番号が最後の既知のＲＤＳ位置と適合する場合、処理はボックス４３５に分岐し、ＮＩＭはこのＩＰ位置用のビーコン・メッセージの閉終点リスト内に入力があるか否かを判別する。ボックス４２５で発信源アドレスおよびポート番号が適合しない場合、処理はボックス４４０に分岐し、ＮＩＭは、このビーコン・メッセージの発信源アドレスおよびポート番号が直前に受信したビーコン・メッセージと同じであるか否かを判別する。このビーコン・メッセージの発信源アドレスおよびポート番号が直前に受信したビーコン・メッセージと同じでない場合、処理はボックス４４５に分岐し、ＮＩＭはビーコン・カウンタをゼロにリセットし、ボックス４５０でビーコン・カウンタを１だけ増加させ、ボックス４５５でビーコン・カウンタが５以上であるか否かを判別し、ビーコン・カウンタが５以上でない場合、処理は分岐して４１５に戻り、ＮＩＭは正当なＲＤＳビーコン・メッセージを待機し続ける。ボックス４５５でビーコン・カウンタが５以上であると判別されると、処理はボックス４６０に進み、ＮＩＭは最後の既知のＲＤＳ位置が０．０．０．０であるか否かを判別する。最後の既知のＲＤＳ位置が０．０．０．０でなかった場合、処理はボックス４６５に分岐し、ＮＩＭはビーコン・タイマが期限切れであるか否かを判別する。ビーコン・タイマが期限切れでなければ、処理はボックス４１５に戻り、ＮＩＭは正当なビーコン・メッセージを待機する。ボックス４６５でビーコン・タイマが期限切れであるか、あるいはボックス４６０で最後の既知のＲＤＳ位置が０．０．０．０であると判別されれば、処理はボックス４７０に分岐し、ＮＩＭは最新のビーコン・メッセージのアドレスおよびポート番号に最後の既知のＲＤＳ位置を設定し、このＩＰアドレス用の全ての終点接続をリセットする。
【００９３】
図７に示したように、それから処理はボックス４７０からボックス５０５に進み、ＮＩＭは、このユニットがＲＤＳに報告できることをシリアル番号マスク／キーが示すか否かを判別する。ＲＤＳに報告できることをシリアル番号マスク／キーが示すとＮＩＭが判別した場合、処理はボックス４８５に進み、ＮＩＭはＲＤＳに状態応答メッセージを送信し、ビーコン・タイムアウト期間を、ビーコン・メッセージのビーコン間隔値と、ビーコン・メッセージの閉終点リスト入力寿命値との積に設定し、ボックス４１０に戻り、ビーコン・タイムアウト期間が経過したときに起動するために、ビーコン・タイマをリセットし、ボックス４１５に進み、受け取るべき正当なＲＤＳビーコン・メッセージを待機する。
【００９４】
ユニットがこの時点でＲＤＳに報告できないことをシリアル番号マスク／キーが示すことをボックス５０５でＮＩＭが判別すると、処理はボックス５１０に分岐し、ＮＩＭは電源をオンにしてから、ビーコン・メッセージの状態応答メッセージが送られたか否かを判別する。ＮＩＭをオンにしてから状態応答メッセージが送られた場合、処理はボックス４９０に進み、ＮＩＭは、ビーコン・タイムアウト期間を、ビーコン・メッセージのビーコン間隔値と、ビーコン・メッセージの閉終点リスト入力寿命値との積に設定し、ボックス４１０に戻り、ビーコン・タイムアウト期間が経過したときに起動するために、ビーコン・タイマをリセットし、ボックス４１５に進み、受け取るべき正当なＲＤＳビーコン・メッセージを待機する。状態応答メッセージが送られていないことをボックス５１０でＮＩＭが判別した場合、処理はボックス４８５に分岐し、ＮＩＭは、状態応答メッセージをＲＤＳに送信し、ボックス４９０に進み、ビーコン・タイムアウト期間を、ビーコン・メッセージのビーコン間隔値と、ビーコン・メッセージの閉終点リスト入力寿命値との積に設定し、ボックス４１０に戻り、ビーコン・タイムアウト期間が経過したときに起動するために、ビーコン・タイマをリセットし、ボックス４１５に進み、受け取るべき正当なＲＤＳビーコン・メッセージを待機する。
【００９５】
ボックス４４０で、現在のビーコン・メッセージの発信源アドレスおよびポート番号が前のビーコンと同じであると判別された場合、処理はボックス４７５に進み、ＮＩＭは、同じ発信源からの最後のビーコン・メッセージから、少なくとも７５％のビーコン間隔が経過したか否かを判別する。同じ発信源からの最後のビーコン・メッセージから、少なくとも７５％のビーコン間隔が経過していない場合、処理はボックス４１５に戻り、ＮＩＭは正当なＲＤＳメッセージ・ビーコンを待機する。
【００９６】
同じ発信源からの最後のビーコン・メッセージから、少なくとも７５％のビーコン間隔が経過した場合、処理はボックス４５０に進み、ＮＩＭはビーコン・カウンタを１だけ増加させ、ボックス４５５でビーコン・カウンタが５以上であるか否かを判別し、ビーコン・カウンタが５以上でない場合、処理は分岐してボックス４１５に戻り、ＮＩＭは正当なＲＤＳビーコン・メッセージを待機し続ける。ボックス４５５でビーコン・カウンタが５以上であると判別された場合、処理はボックス４６０に進み、ＮＩＭは、最後の既知のＲＤＳ位置が０．０．０．０であるか否かを判別する。最後の既知のＲＤＳ位置が０．０．０．０でなかった場合、処理はボックス４６５に分岐し、ＮＩＭは、ビーコン・タイマが期限切れであるか否かを判別する。ビーコン・タイマが期限切れでなかった場合、処理はボックス４１５に戻り、ＮＩＭは正当なビーコン・メッセージを待機する。ボックス４６５でビーコン・タイマが期限切れであるか、ボックス４６０で最後の既知のＲＤＳ位置が０．０．０．０であると判別された場合、処理はボックス４７０に分岐し、ＮＩＭは最新のビーコン・メッセージのアドレスおよびポート番号に最後の既知のＲＤＳ位置を設定し、このＩＰアドレス用の全ての終点接続をリセットする。
【００９７】
ボックス４２５で、現在のビーコンの発信源アドレスおよびポート番号が最後の既知のＲＤＳ位置と適合すると判別された場合、処理はボックス４３５に進み、ＮＩＭは、このＩＰ位置用のビーコン・メッセージの閉終点リスト内に入力があるか否かを判別し、入力があるのであれば、ボックス４８０でこのＩＰアドレス用のビーコン・メッセージの閉終点リスト内に列挙された終点接続を全てリセットし、ボックス４８５でＲＤＳに状態応答メッセージを送信し、ボックス４９０で、ビーコン・タイムアウト期間を、ビーコン・メッセージのビーコン間隔値と、ビーコン・メッセージの閉終点リスト入力寿命値との積に設定し、ボックス４１０に戻り、ビーコン・タイムアウト期間が経過したときに起動するために、ビーコン・タイマをリセットし、ボックス４１５に進み、受け取るべき正当なＲＤＳビーコン・メッセージを待機する。
【００９８】
このＩＰアドレス用のビーコン・メッセージの閉終点リスト内に入力がないとボックス４３５で処理が判別した場合、処理はボックス５００に分岐し、ＮＩＭは全ての終点が接続されているか否かを判別する。全ての終点が接続されていた場合、処理はボックス４９０に進み、ＮＩＭは、ビーコン・タイムアウト期間を、ビーコン・メッセージのビーコン間隔値と、ビーコン・メッセージの閉終点リスト入力寿命値との積に設定し、ボックス４１０に戻り、ビーコン・タイムアウト期間が経過したときに起動するために、ビーコン・タイマをリセットし、ボックス４１５に進み、受け取るべき正当なＲＤＳビーコン・メッセージを待機する。
【００９９】
ボックス５００で全ての終点が接続されていないと判別された場合、処理はボックス５０５に分岐し、ＮＩＭは、このユニットがＲＤＳに報告できることをシリアル番号マスク／キーが示すか否かを判別する。ＮＩＭがＲＤＳに報告できることをシリアル番号マスク／キーが示すとＮＩＭが判別した場合、処理はボックス４８５に進み、ＮＩＭはＲＤＳに状態応答メッセージを送信し、ボックス４９０に進み、ビーコン・タイムアウト期間を、ビーコン・メッセージのビーコン間隔値と、ビーコン・メッセージの閉終点リスト入力寿命値との積に設定し、ボックス４１０に戻り、ビーコン・タイムアウト期間が経過したときに起動するために、ビーコン・タイマをリセットし、ボックス４１５に進み、受け取るべき正当なＲＤＳビーコン・メッセージを待機する。
【０１００】
ユニットがこの時点でＲＤＳに報告できないことをシリアル番号マスク／キーが示すことをボックス５０５でＮＩＭが判別すると、処理はボックス５１０に分岐し、ＮＩＭは電源をオンにしてから、ビーコン・メッセージ状態応答メッセージが送られたか否かを判別する。ＮＩＭをオンにしてから状態応答メッセージが送られた場合、処理はボックス４９０に進み、ＮＩＭは、ビーコン・タイムアウト期間を、ビーコン・メッセージのビーコン間隔値と、ビーコン・メッセージの閉終点リスト入力寿命値との積に設定し、ボックス４１０に戻り、ビーコン・タイムアウト期間が経過したときに起動するために、ビーコン・タイマをリセットし、ボックス４１５に進み、受け取るべき正当なＲＤＳビーコン・メッセージを待機する。ボックス５１０で、状態応答メッセージが送られていないとＮＩＭが判別した場合、処理はボックス４８５に分岐し、ＮＩＭは状態応答メッセージをＲＤＳに送信し、ボックス４９０に進み、ビーコン・タイムアウト期間を、ビーコン・メッセージのビーコン間隔値と、ビーコン・メッセージの閉終点リスト入力寿命値との積に設定し、ボックス４１０に戻り、ビーコン・タイムアウト期間が経過したときに起動するために、ビーコン・タイマをリセットし、ボックス４１５に進み、受け取るべき正当なＲＤＳビーコン・メッセージを待機する。
【０１０１】
ＵＤＰメッセージ・システムの低信頼性によって、ビーコン・パケットはときどき消失することが想定される。一般に、ＲＤＳとの接続の消失の拡大を示すように多数の連続的なパケットが消失しない限り、消失したパケットは問題にはならない。各ＲＤＳビーコン・パケットは閉終点リスト入力寿命フィールドを有し、前記フィールドはＲＤＳが所定の終点に終点閉情報を送信する連続的なビーコン・メッセージの全数を示す。ＲＤＳが送信すべき指示されたビーコン・メッセージ数に対して、十分長い時間ビーコン・メッセージを受け取らなかった場合、ＮＩＭは一般に、その接続の一つ以上がＲＤＳによって閉じられたかもしれないと仮定する。このことが生じた場合、ＮＩＭは、その接続の一つを意図的に遮断し、その次の応答ウィンドウ中にＲＤＳに報告を行うようにプログラムされている。これは、ビーコン・メッセージ内に閉終点を再送信する機会をＲＤＳに与え、ＲＤＳとＮＩＭとは再び同期できる。
【０１０２】
ＮＩＭが特定のＲＤＳを既に登録していれば、第二発信源からのＲＤＳビーコン・メッセージをいつ調べ始めても、登録されたＲＤＳからのメッセージのために、ＮＩＭは第二発信源からのビーコン・メッセージを無視する。しかし、最初のＲＤＳサーバが何らかの理由でビーコン・メッセージの送信を停止し、例えば５個のような所定の数の連続的なビーコン・メッセージを新しいＲＤＳサーバから受信した場合、ＮＩＭはその終点接続を全てリセットし、新しいサーバを登録する。これは、主ＲＤＳサーバを遮断し、バックアップＲＤＳサーバがその代わりにオンラインになった場合に、ＮＩＭがサーバを切り替えることができるので望ましい。当業者には明らかなように、本発明の実施形態は５個の連続的なビーコン・メッセージについて説明されているが、ネットワークの必要性またはシステム設計者の希望に従って、ビーコン・メッセージの数は異なっていてもよいが、本発明の範囲から逸脱することなく、新しいサーバに切り替える前に、多かれ少なかれ５個のビーコン・メッセージを受け取ることができる。
【０１０３】
図８は、ＲＤＳの発見プログラム・フローを示すブロック図である。上記のように、ＲＤＳの発見フローは主に、そのビーコン・メッセージへの応答に注意し、状態応答メッセージで受信したデータを用いて、その終点キャッシュを管理することに関し、前記状態応答メッセージはネットワークに接続されたＮＩＭから受信する。
【０１０４】
ボックス６００で開始した後、ボックス６０５でＲＤＳは、ＲＤＳビーコン・メッセージを同報通信しているＵＤＰポート上で受信すべき正当なＮＩＭ状態応答メッセージを待機する。メッセージがＵＤＰポート上で受信された場合、処理はボックス６１０に進み、ＲＤＳのプログラム・ロジックは、メッセージが正当なＮＩＭ状態応答メッセージであるか否かを判別する。メッセージが正当なＮＩＭ状態応答メッセージでない場合、処理はボックス６０５に戻り、ＲＤＳは正当な状態応答メッセージを待機し続ける。
【０１０５】
メッセージが正当な状態応答メッセージであれば、処理はボックス６１５に進み、ＲＤＳは、状態応答メッセージの「接続済みリスト」にない終点キャッシュ内の全ての入力に対して、動作中のＴＣＰ／ＩＰ接続を閉じる。これが一旦実現されると、処理はボックス６２０に進み、ＲＤＳは、状態応答メッセージ終点リストのいずれにも存在しない全ての終点について、終点キャッシュからの入力を削除する。この動作が一旦完了すると、処理はボックス６２５に進み、状態応答メッセージの「リスニング中リスト」内の全ての新しい終点について終点キャッシュに入力を追加し、それからボックス６３０に進み、状態応答メッセージの「接続済みリスト」内の事前に未知の全ての終点について、ビーコン・メッセージの「閉終点リスト」に入力を追加する。
【０１０６】
状態応答メッセージの「接続済みリスト」内の事前に未知の全ての終点について、ビーコン・メッセージの「閉終点リスト」に入力を追加した後、処理はボックス６３５に進み、ＲＤＳは接続されていない終点キャッシュ内の全ての入力に対して、ＴＣＰ／ＩＰ接続の生成を試みる。ボックス６３５の処理が完了すると、ＲＤＳはボックス６０５に戻り、受信すべき正当なＮＩＭ状態応答メッセージを待機する。
【０１０７】
接続のリセット
ＴＣＰ／ＩＰ接続がタイムアウトになると常に、接続上で打ち切り切断が行われる。接続の遮断がタイムアウト期間よりそれほど長くなければ、接続の他端のシステムに閉じたことを知らせることもできるが保証はされない。しかし、安全のために、接続の遮断は時間的に延長させ、このような通知が発生しないようにしなければならない。従って、接続が閉じた後、本発明によるシステムおよび方法はいくつかの処理を行い、二つの終点が同期状態に戻れるようにする。処理は、ＮＩＭに比べてＲＤＳでは異なり、以降で詳しく説明する。
【０１０８】
ＮＩＭ用の処理は、ＲＤＳによって用いられる処理よりいくぶん簡単である。ＮＩＭが接続をリセットすると常に、ＲＤＳビーコン・メッセージ内の登録キーをチェックした後、状態応答メッセージを送信する機会を待機するだけで、最近閉じた終点ポートが現在リスニング・モードであることを示す状態応答メッセージを送信する。ＲＤＳがこれを確認すると、その終点への接続をリセットし、新しいＴＣＰ／ＩＰ接続を生成する。ＮＩＭは、ＲＤＳが最終的にそのポートへの新しいＴＣＰ／ＩＰ接続を生成するまで、可能であれば未接続の終点を報告し続ける。
【０１０９】
ＲＤＳが接続を遮断した場合、ビーコン・メッセージ閉終点リスト内にその終点のアドレスおよびポートを配置しなければならない。閉終点情報は、閉終点リスト入力寿命値と等しい複数のビーコン・メッセージに対してリスト内に発行される。それから、ＲＤＳは、ある時点でＮＩＭが状態応答メッセージを送信すると仮定し、前記状態応答メッセージは、終点が再びリスニング・モードになり、ＮＩＭからのこのような状態応答メッセージの受信を待機することを示す。
【０１１０】
ＮＩＭが全てのビーコン・メッセージを見逃した場合、接続が回復するとすぐ、ＮＩＭのプログラム・ロジックは、ＲＤＳに報告する必要があるとそれ自体にフラグを立てる。ＮＩＭがＲＤＳに状態応答メッセージを送信することによって最終的にＲＤＳに報告する際、閉終点がなお接続済みとして列挙されていた場合、ＲＤＳは再びビーコン・メッセージの閉終点リストにその終点を配置し、ポートがリスニング・モードであるとＮＩＭが応答することを待機する。
【０１１１】
接続管理
ネットワークに接続されたＮＩＭを一旦ＲＤＳに登録すると、ＲＤＳは各ＮＩＭ上の各終点にＴＣＰ接続を生成する。これは、ＲＤＳと終点との間に大きなアプリケーション・レベルのメッセージを送出する高信頼性の手段を提供する。これは、ＲＤＳのみがＮＩＭへの接続を生成し、ＮＩＭはＲＤＳから発信されていないメッセージを無視するようにプログラムされるという点でも望ましい。さらに、ＮＩＭは登録されたＲＤＳからのメッセージのみに応答し、正当なＲＤＳサーバのふりをしようとする悪意あるサーバを含む他のサーバからのメッセージを無視する。
【０１１２】
既定値では、ＴＣＰ／ＩＰ接続があきらめ、接続の遮断を宣言するようにプログラムされる前に、ＴＣＰ／ＩＰプロトコルは、最大９分間、接続したソケット上にデータを再送信しようとする。さらに、ＴＣＰ／ＩＰプロトコルはデータ送出の消極的確認を行うだけであり、つまり、データをうまく送信できるときではなく、データを送信できないときに送信元に通知するだけである。ＲＤＳはこれよりずっと短いタイムアウトを要求し、メッセージ送信の積極的確認を供給するので、アプリケーション・メッセージを送信する際、ＴＣＰ／ＩＰ接続を介して、一般に余分なハンドシェークが行われる。
【０１１３】
メッセージ・フロー
ＴＣＰ／ＩＰ接続を介して所定の方向に、一度に一つのアプリケーション・メッセージだけが送信される。システムは、ＴＣＰ／ＩＰ接続上で、アプリケーション・レベルのタイムアウトに相当するものを実行できるので、このシリアル化はデータ・フローの制御をかなり簡略化する。ある種の待機インタフェースが望まれる場合、それは一般にアプリケーション層内に実装される。
【０１１４】
図９は、ＡとＢで識別された二つの終点間のメッセージ・フローの一例を示している。データを送信後、送信元は受信先から一般に長さ０バイトのメッセージである肯定応答を受け取るまで待機しなければならず、その後、別のデータ・メッセージの送信が可能になる。接続は双方向であるので、このフローは図１０に示したように、同時に双方向で発生できる。
【０１１５】
図１１はＴＣＰ／ＩＰ接続を介した典型的なデータ・フローを示しており、この例では送信元Ａはアプリケーション・レベルのタイムアウトを行う。第二データ・メッセージ用の肯定応答がタイムアウト期間内に到達しなかったので、終点Ａは機器間のＴＣＰ接続を強制的に閉じる。終点Ｂからの肯定応答が最終的に送信元Ａに到達した場合、ＴＣＰスタックは接続が閉じられていることを示す低レベル接続リセット・エラーで応答する。終点Ｂによって送信される別の任意のメッセージも、同じエラーを受信する。
【０１１６】
データの暗号化
悪意ある攻撃に対して機密性の高い患者データを保護し、システム全体を堅固にするために、本発明の接続プロトコルの一実施形態は、ネットワークを介して送信される全てのデータ上で暗号化を行う。説明される本発明の実施形態では暗号化は四ステップ処理であり、各ステップは異なるセキュリティ上の懸念に対処するように設計されている。
【０１１７】
図１２は、本発明の一実施形態の暗号化メッセージ７００の構造を示している。図のデータ暗号化方式の特定の実施形態はストリームデータをサポートしておらず、ＮＩＭとＲＤＳの間で送信される全てのメッセージは、所定の長さでなければならない。この実施形態は所定の長さについて説明しているが、本発明の他の実施形態は、異なる長さを備えたメッセージを暗号化可能な暗号方式を用いることを考慮し、それも本発明の意図した範囲内である。
【０１１８】
暗号化処理
図の実施形態の暗号化処理の最初のステップは、送信されるデータに複数の１０バイトを埋め込むことである。これは、最終的な暗号化ステップが１６バイトの固定ブロック・サイズの対称ブロック暗号化を用いるために必要となる。埋め込むデータは、ある定数またはランダム値に明示的に設定されなければならず、メッセージ・バッファの事前に存在するメモリ内容が埋め込み領域内にそのまま残ることは許されない。埋め込みデータは、メッセージ７００のメッセージ・データ・フィールド７０５に格納される。
【０１１９】
それから、図１２に示したように、四つのフィールド７１５，７２０，７２５および７３０を有するセキュリティ・ヘッダ７１０を各メッセージ７００に追加する。セキュリティ・ヘッダ７１０のトランザクション・キー・フィールド７１５はランダムに生成された３２ビット値を有し、その値はシステムで利用可能な最も高暗号強度の乱数発生器によって生成される。セキュリティ・ヘッダ７１０の発信源ＩＰアドレス・フィールド７２０は送信元のＩＰアドレスを有し、このフィールドは送信元を認証するためのデジタル署名として受信先によって使用される。セキュリティ・ヘッダ７１０のデータ・サイズ・フィールド７２５は、埋め込み前の元の平文メッセージのバイト数を有する。最後に、セキュリティ・ヘッダ７１０のＭＴＵサイズ・フィールド７３０は、送信元が単一のデータグラムで処理可能なバイトの最大数を有し、この実施形態では１６バイト未満には決してならない。
【０１２０】
セキュリティ・ヘッダ７１０をメッセージ７００の最初に追加した後、セキュリティ・フッタ７３５をメッセージ７００の終わりに追加する。図の実施形態のセキュリティ・フッタ７３５は、例えば、ＭＤ５メッセージ・ダイジェスト・アルゴリズムを用いて生成されたセキュリティ・ヘッダおよび埋め込みメッセージのハッシュを有する。このセキュリティ・フッタ７３５は、送信中、メッセージが改竄されたか否かを判別するために、メッセージの受信先によって使用される。
【０１２１】
メッセージ全体が一旦まとめられると、セキュリティ・ヘッダ内のトランザクション・キーと、メッセージ全体の排他的論理和とを一度に３２バイトずつとり、トランザクション・キー自体を取り除く。データを「ソルト」することは、発信源ＩＰアドレス等の連続的なメッセージの静的部分が常に同じように暗号化されないようにするために役立ち、本発明の実施形態の暗号化方法のセキュリティをさらに強化する。
【０１２２】
データをソルトした後、例えば、ＡＥＳブロック暗号化を用いて、両方のヘッダを含むメッセージ全体を共通キーで暗号化する。それから、暗号化したメッセージを所定の受信先に送信する。
【０１２３】
復号化処理
一旦メッセージを受信すると、受信先のプログラム・ロジックは正当なメッセージを受信したか否かをまず判別しなければならない。この処理は、メッセージをデータグラムベースのＵＤＰ接続で受信したか、ストリームベースのＴＣＰ接続で受信したかに応じてやや異なる。
【０１２４】
一般に、復号化は、暗号化処理の逆にすぎない。本発明の一実施形態では、ＡＥＳブロック暗号化を用いてメッセージを復号化し、それからセキュリティ・ヘッダ内で見つけたトランザクジョン・キーを用いて逆ソルトする。一旦これが完了すると、ＭＤ５メッセージ・ダイジェスト・アルゴリズムを用いて、セキュリティ・ヘッダと埋め込みデータをハッシュし、セキュリティ・フッタ内に格納したハッシュと結果を比較する。ハッシュが適合した場合、セキュリティ・ヘッダ内の発信元ＩＰアドレスをメッセージの実際の発信源に対してチェックする。それから、セキュリティ・ヘッダ内のデータ・サイズ・フィールドをチェックし、埋め込まれたメッセージ・データの実際の大きさに等しいか、多くとも１５バイト未満であるかを確認する。これらの最後の二つのチェックを通れば、データは正当であると考えられ、将来的に使用するためにメッセージから抽出される。
【０１２５】
ＴＣＰ接続では、一定期間、一度に数バイトずつ、暗号化されたメッセージをゆっくり送出できる。これ自体は欠点ではないが、ただし、ＴＣＰ接続は、メッセージの開始または終了の概念を持たない。従って、受信先は、ＴＣＰ接続上で送信される連続的なメッセージの間の境界の判別において積極的な役割を果たす。その結果、復号化処理は、ＴＣＰ接続上で用いられる場合はやや変化する。
【０１２６】
本発明の図の実施形態の方法を用いて、ＴＣＰ接続上で受信したメッセージを復号化する場合、ＡＥＳブロック暗号化を用いて最初の１６バイトを復号化し、トランザクション・キーを用いて逆ソルトし、それらが正当なセキュリティ・ヘッダを有するか否かを検査する。送信元ＩＰアドレスが適合し、データ・サイズが所定の制限内であれば、セキュリティ・ヘッダ内で指定されたサイズのメッセージを受信するまで、システムは受信すべき追加のバイトを待機し続ける。しかし、値のどちらかが不当な場合は、接続は遮断する。
【０１２７】
特定のサイズのメッセージに対して、必要なバイト数を一旦受信すると、残りのメッセージを復号化し、逆ソルトし、ＭＤ５ハッシュを確認する。確認が成功した場合、データは正当であると考えられ、ハッシュ確認が失敗した場合は、接続は遮断される。
【０１２８】
応答メッセージ内のトランザクションＩＤ
本発明の原理によると、ＵＤＰ接続上で送信されるデータだけが、ＲＤＳビーコン・メッセージおよびＮＩＭ状態応答メッセージである。さらに、状態応答メッセージはビーコン・メッセージの応答としてだけ送信され、ビーコン・メッセージ毎に一つの状態メッセージだけが送信される。同様に、ＴＣＰ接続だけがメッセージを送信し、肯定応答がそれらのメッセージに応答する。しかし、複数の応答が送信されることは決してない（例えば、複数のビーコン応答または複数の肯定応答）。このため、本発明の原理を用いる全てのメッセージ交換は、１：１要求／応答メッセージ比率であると一般的にいうことができる。
【０１２９】
メッセージのセキュリティ・ヘッダ内のトランザクションＩＤは、暗号化処理を増強するソルト値としてのみ提供されるが、これはその機能だけではない。さらに、トランザクションＩＤは、ＵＤＰおよびＴＣＰ接続の両方の上のメッセージ間を同期させる。
【０１３０】
送信される各要求は、ランダムに選択されたトランザクションＩＤを有する。しかし、応答メッセージは、それら自体のトランザクションＩＤは選択しない。その代わり、要求メッセージからのトランザクションＩＤを再利用し、それら自体のトランザクションＩＤフィールドをゼロに設定する。元の要求側が、ゼロのトランザクションＩＤを備えた応答を受信すると、データを送信および逆ソルトしようとした最新の要求からのトランザクションＩＤを用いていることがわかる。その結果、トランザクションＩＤが適合する場合だけ、データは正しく復号化される。
【０１３１】
ゼロバイトの肯定応答を受信するまで、ＴＣＰ接続上では新しいメッセージは送信されないが、この方法は、余分な確実性を提供する点で有利である。暗号化したメッセージ内のデータ・サイズがゼロであっても、セキュリティ・ヘッダ／フッタはなお適切に復号化し、正当でなければならず、そうでなければ接続は遮断される。これは、所定の要求に対して所定の肯定応答が意図するより、完全な確実性を提供する。
【０１３２】
本発明の方法は、ＵＤＰ接続を用いる場合でも、バラバラのデータグラム送出から生じるシーケンス・エラーを防止できるのでさらに有利である。ＲＤＳは各ビーコン・メッセージに対して新しいトランザクションＩＤを選択するので、トランザクションＩＤは、特定の状態応答メッセージが最新のビーコン・メッセージに対する応答であるか、あるいはネットワークによって遅延された古い応答であるかを確認する手段を提供する。
【０１３３】
ＭＴＵ発見
暗号化されたメッセージの各々の最初のセキュリティ・ヘッダ７１０（図１２）はＭＴＵサイズ・フィールド７３０を有し、システムが単一のデータグラムで処理できる最大バイト数を示す。このフィールドは常に、肯定応答メッセージを含む各メッセージ内に設定される。従って、システムはゼロバイトのデータグラムを送信し、肯定応答メッセージのＭＴＵサイズ・フィールドを調べることによって、別のシステムのＭＴＵサイズを安全に発見できる。この手順は選択可能であるが、送信元がＭＴＵサイズより大きな任意の受信メッセージを拒否できるので有利である。
【０１３４】
ＡＥＳ暗号モード
ＡＥＳブロック暗号は、電子クック・ブック（ＥＣＢ）および暗号ブロック連鎖（ＣＢＣ）モードの両方で使用される。ＣＢＣモードは、既に暗号化されたブロックからのデータを用いて、次のブロックのデータをソルトし暗号化するので、わずかであるがより安全である。このようなモードを用いる場合、暗号化されたストリームを復号化するためにストリーム全体の複製を得なければならず、特定の抜粋を絞り込むことが難しくなる。
【０１３５】
本発明の原理によると、全てのＴＣＰ接続はＡＥＳ暗号に対してＣＢＣモードを用いてセキュリティを改善するが、他のモードを用いることもでき、本発明の範囲内にあるものとする。ＣＢＣモードを用いる場合、データ・ストリームの両端が互いに同期的に開閉されるので不利ではない。しかし、ＲＤＳビーコン・メッセージと、ビーコン・メッセージに対するＮＩＭ状態応答メッセージはＵＤＰチャネル上に送信され、従って、同期化することなく送受信され、ＲＤＳが送信を開始したよりも遥か後に、ＮＩＭの電源をオンにし、ビーコン・メッセージを受信し始めることができる。このため、既に同報通信されたビーコン・メッセージ上でＮＩＭが「キャッチアップ」する方法がないので、ＵＤＰチャネルではＥＣＢモードを用いることが望ましい。
【０１３６】
本発明の別の実施形態では、医療機器はＮＩＭを有することができ、医療機器をネットワークに接続した際、ＮＩＭは周期的に「再起動」するが、それ以外では停止中または電源オフになるようにプログラムされている。この実施形態では、ＮＩＭは上記のように再起動し、ビーコン・メッセージのためにネットワークをリスニングし始める。この実施形態は、医療機器内のメモリ、または医療機器と接続した記憶媒体内に存在する様々なデータベースの更新を受信できるようにＮＩＭをネットワークに接続できるので有利であり、それは医療機器の電源をオンにする際、起動に必要な時間を短縮できる。任意の必要な更新を受信した後、ＮＩＭは電源をオフにし、「スリープモード」に戻るようにプログラムされている。ＮＩＭは、データを受信することなく、特定の時間が経過した後に電源オフにすることもでき、それは医療機器または関連装置の一つ以上のデータベースの更新が不要であることを示している。別の実施形態では、ＮＩＭは医療機器とは別個に再起動し、キャッシュまたは他のメモリ内に任意のデータ更新を格納するようにプログラムされており、医療機器が電源オンになった後、前記データを医療機器に提供できる。この実施形態は、ＮＩＭに電力を供給するだけなので、バッテリ電力を節約し、バッテリ寿命を延ばすという点で有利である。
【０１３７】
さらに別の実施形態では、本発明は、このような医療機器等の資産を配置するシステムおよび方法を提供し、それらは例えば輸液ポンプまたは生命徴候監視装置であってもよく、一般に患者の処置の過程で一つの場所から別の場所に移動される。この実施形態は、無線接続を用いて、施設ネットワークと通信する移動型医療機器を備えた施設内で特に有利である。このようなネットワークでは、移動型医療機器は、施設全体に配置した送受信機を介してネットワークと通信する。各送受信機は、ＭＡＣアドレスを用いてネットワーク上で識別される。各送受信機の位置、および各ＭＡＣアドレスの位置は、システムにとって既知になる。従って、移動型医療機器を配置したいケア提供者は、接続される機器のリストおよびＭＡＣアドレスのリストを備え、少なくとも機器が無線送受信機の領域内に配置される範囲で、機器のおよその位置を判別できる。一般に、医療施設内のこのような受信器の範囲は、およそ６フィート（１８３ｃｍ）程度である。
【０１３８】
さらに別の実施形態では、本発明は、施設内に存在することが知られているが、所定の期間、ビーコン・メッセージに応答していない機器の監視リストを確立することによって、移動型医療機器を配置するシステムおよび方法を提供する。この実施形態では、システムは、機器がオンになるか、または無線の範囲内に来たときに機器にフラグを立て、ＲＤＳによって送信されたビーコン・メッセージへの応答を開始するようにプログラムされている。それから、フラグを立てた医療機器が配置されたという報告を施設に提供できる。
【０１３９】
別の実施形態では、本発明によるシステムは、ワイヤレス・アクセス・ポイントを用いて移動型機器と通信するように構成された移動型サーバからなる。図１３に示したように、この実施形態の移動型サーバ８０５，８１０は、ＲＤＳサーバであってもよいし、あるいはデータベースまたは他の施設情報システムの制御のような別の機能を有するサーバであってもよい。このようなサーバは、通常、固定型サーバと同一または等価なソフトウェア（カーネル）を有し、移動型システム・マネージャであると考えられる。一実施形態において、移動型サーバは、図１３において番号８０５，８１０によって特定されるようなラップトップ・コンピュータ、適切に整備されたＰＤＡ、または他の移動型コンピュータ・システム上に存在する。
【０１４０】
ワイヤレス・ネットワークとの通信は、ワイヤレス・アクセス・ポイントまたはモジュールを介してなされる。そのようなワイヤレス・アクセス・ポイントまたはモジュールは、移動型サーバ８１０と一体化され、移動型サーバと操作可能に通信していてもよい、すなわち、アンテナのような適切な通信ハードウェアを用いて動きまわっていてもよい。このようなワイヤレス通信ネットワークを利用することにより、移動型サーバ８０５，８１０は、ＣＱＩデータベース８２０、ルール・データベース（図示せず）、または汎用的な情報あるいは患者固有の情報を収容する他のデータベース（図１参照）にアクセスすることができる。あるいは、移動型サーバ８０５は、分離したワイヤレス・アクセス・モジュール８１２に接続されていてもよい。このような接続は、ＵＳＢまたは他の適切な接続のような、サーバ上のポートを介してなされる。
【０１４１】
例えば、２．２ＧＨｚまたは他の適切な周波数で動作するワイヤレス・アクセス・ポイント８１５、および適切なインタフェース機器を用いることにより、移動型サーバ８０５，８１０は、移動型クライアント８２５，８３０，８３５，および８４０と双方向通信し、必要に応じて、それらの移動型クライアントを制御することができる。そのような移動型クライアントとは、例えば、適切に整備、プログラムされた輸液ポンプ８４５、または生命徴候監視機器あるいは実験室機器８５０のような他の医療機器のことである。従って、本発明の移動型サーバ８０５，８１０は、専用室や異なる場所に容易に移動させることができない固定型サーバを設ける必要性を排除する。
【０１４２】
このような移動型サーバの応用例が図１４に示されている。図１４では、そのようなシステムが手押しカート上に設置されている。この例では、本発明の原理に従って移動型サーバ９０２と通信することができる種々の医療機器９０５が、典型的な病院施設全体にわたって配置されている。図１４において、“ＰＣＵ”は、「患者ケア・ユニット（Patient Care Unit ）」を表すものとしており、輸液ポンプ、生命徴候監視機器、または他の機器のような種々の医療機器を含む。図示されているように、これらのユニットのいくつかは、患者のベッドサイド９２５、ナース・ステーション９３０、収納室９３５に配置されていてもよいし、あるいは、それらは、患者９４０に伴って施設内を移動することができる携帯型機器として構成されていてもよい。カート９００上に搭載された移動型サーバ９０２が施設内で押されていくと、そのサーバは、全ての医療機器にメッセージ・ビーコンを同報通信する。それらの医療機器とは、適切なワイヤレス・アクセス装置およびネットワーク・インタフェース・モジュール（ＮＩＭ）が装備された輸液ポンプ、複数の機器を制御する機器制御部、または生命徴候監視機器のことである。移動型サーバ９０２には、１種類以上のワイヤレス通信手段が装備されていてもよい。例えば、移動型サーバは、８０２．１１ＷＩＦＩプロトコルを利用することによりワイヤレス受信機／送信機９１０を用いて通信してもよいし、あるいは移動型サーバ９０２は、ＲＦまたはＩＲ送信機／受信機９１５を用いてもよい。当業者であれば、上述したように、任意のワイヤレス手段が利用可能であることを理解されるであろう。
【０１４３】
カート９００および移動型サーバ９０２が施設内を移動すると、移動型サーバ９０２は、ビーコン信号を送信する。そのビーコン信号は、移動型サーバ９０２のワイヤレス送信機／受信機９１０，９１５の範囲内に位置する適切なＮＩＭが装備された任意の機器によって受信され、応答される。一実施形態では、ＷＩＦＩプロトコルが使用され、その範囲は、およそ３０フィート（９１４ｃｍ）である。すなわち、移動型サーバ９０２から３０フィートの半径内の全ての機器が、ビーコン信号を受信し、それに応答して、移動型サーバ９０２との安全な通信セッションを確立することができる。その範囲は、プロトコルおよび使用されている特定のハードウェアに依存し、必要に応じて３０フィート以上にも以下にもできることを、当業者は理解されるであろう。
【０１４４】
上述したように、移動型サーバ９０２の範囲内の機器であり、現在「起動（awake ）」して動作している機器は、ビーコン信号に応答することができる。あるいは、上述したように、種々の機器のＮＩＭはビーコン信号をリスニングして、次いで、その機器を起動させることによって、その機器と移動型サーバ９０２との間でデータが交換されるようにプログラムされていてもよい。さらに別の実施形態では、ＮＩＭは、移動型サーバ９０２との通信、およびそのサーバ９０２との情報交換をその医療機器を起動させることなく行うことによって、その機器のバッテリ寿命を向上させるようにプログラムされていてもよい。
【０１４５】
本発明のいくつかの形態を示し、説明してきたが、本発明の技術思想および範囲から逸脱することなく種々の変更が可能であることも明らかであろう。従って、添付された特許請求の範囲を除くいかなるものによっても本発明が限定されることはない。
【図面の簡単な説明】
【０１４６】
【図１】本発明の様々な態様を用いる患者ケア・システムの概略図。
【図２】本発明の原理を示す簡略化されたネットワークの概略図。
【図３】本発明の原理を示す複雑なネットワークの概略図。
【図４】ソフトウェア・アーキテクチャの層を示すＲＤＳサーバおよびＮＩＭクライアントのソフトウェア・スタックの概略図であって、本発明の発見および接続管理を含むソフトウェア・スタックの概略図。
【図５】本発明の一実施形態に従って、ＲＤＳが送信するビーコン・メッセージのデータ構造を示す概略図。
【図６】本発明の一実施形態に従って、ＮＩＭが送信する状態応答メッセージのデータ構造を示す概略図。
【図７Ａ】ＮＩＭが実行する本発明の発見処理の一実施形態の論理フローを示すフロー図。
【図７Ｂ】ＮＩＭが実行する本発明の発見処理の一実施形態の論理フローを示すフロー図。
【図８】本発明の一実施形態に従って、ＲＤＳが実行するＲＤＳ発見処理の一実施形態の論理フローを示すフロー図。
【図９】ＴＣＰ接続内の要求と肯定応答のフローを示す図。
【図１０】ＴＣＰ接続内の要求と肯定応答のフローを示す図。
【図１１】ＴＣＰ接続内の要求と肯定応答のフローを示す図。
【図１２】本発明の一実施形態に従って暗号化された安全なメッセージの形式を示す図。
【図１３】ワイヤレス・アクセス・ポイントを介して施設ネットワークに接続された医療機器と通信する、ワイヤレス・アクセス・ポイントを介して施設ネットワークと通信する移動型サーバを含む、本発明の一実施形態を示す概略図。
【図１４】手押しカート上の移動型遠隔サーバを示す、病院環境における移動型サーバの応用例。
【図１】
2007515883.tif 000003
【図２】
2007515883.tif 000004
【図３】
2007515883.tif 000005
【図４】
2007515883.tif 000006
【図５】
2007515883.tif 000007
【図６】
2007515883.tif 000008
【図７Ａ】
2007515883.tif 000009
【図７Ｂ】
2007515883.tif 000010
【図８】
2007515883.tif 000011
【図９】
2007515883.tif 000012
【図１０】
2007515883.tif 000013
【図１１】
2007515883.tif 000014
【図１２】
2007515883.tif 000015
【図１３】
2007515883.tif 000016
【図１４】
2007515883.tif 000017
【国際調査報告】
2007515883.tif 000018
2007515883.tif 000019