"患者支持装置用のマルチマスター通信ネットワークであって、前記ネットワークが、物理層と、データリンク層と、アプリケーション層と、複数のネットワークノードがクライアントとして同時に機能することを可能にするメッセージング構造を含むネットワーク層と、を備えるネットワーク。クライアント要求のためのクライアントノード識別が、メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正されるように、ネットワークメッセージ識別に埋め込まれたことを特徴とする、請求項1に記載のネットワーク。サーバ応答のためのノード識別が、メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正されるように、ネットワークメッセージ識別に埋め込まれたことを特徴とする、請求項2に記載のネットワーク。サーバ応答のためのノード識別が、メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正されるように、ネットワークメッセージ識別に埋め込まれたことを特徴とする、請求項1に記載のネットワーク。特定のサーバノードからのデータを要求するために、クライアントノードによってクライアントメッセージが形成されることを特徴とする、請求項1に記載のネットワーク。前記データが要求される対象である特定のサーバが、クライアント要求メッセージを送信した前記ノードに向けられる特定のメッセージに応答することで、前記クライアント要求メッセージを送信する前記ノードに直接応答することを特徴とする、請求項5に記載のネットワーク。ユーザーインターフェースノードが、サーバ応答を行うスケールノードに向けられたクライアント要求を行うことを特徴とする、請求項6に記載のネットワーク。エアマットレスノードがサーバノードとして機能することを特徴とする、請求項7に記載のネットワーク。外部インターフェース装置と通信するゲートウェイノードをさらに含み、前記ゲートウェイノードが前記外部インターフェース装置からのクエリーに応答して前記ネットワーク上でその他のノードにクライアント要求を行う、請求項6に記載のネットワーク。前記外部インターフェース装置がナース通信ワークステーションであることを特徴とする、請求項9に記載のネットワーク。前記ネットワーク層が、前記物理層に接続されたあらゆるノードがクライアント、サーバ、およびピアとして同時に通信しうるように構成されることを特徴とする、請求項10に記載のネットワーク。前記ネットワーク上の単一ノードが、複数のその他のノードからのクライアント要求に同時に応答し得ることを特徴とする、請求項11に記載のネットワーク。サーバ応答が複数のメッセージを含むこともあり、各々のメッセージが前記クライアントノードによって要求された前記データの一部を含むことを特徴とする、請求項12に記載のネットワーク。外部インターフェース装置と通信するゲートウェイノードをさらに含み、当該ゲートウェイノードが前記外部インターフェース装置からのクエリーに応答して前記ネットワーク上でその他のノードにクライアント要求を行う、請求項1に記載のネットワーク。前記外部インターフェース装置がナース通信ワークステーションであることを特徴とする、請求項14に記載のネットワーク。前記ネットワーク層が、前記物理層に接続されたあらゆるノードがクライアント、サーバ、およびピアとして同時に通信しうるように構成されることを特徴とする、請求項15に記載のネットワーク。前記ネットワーク上の単一ノードが、複数のその他のノードからのクライアント要求に同時に応答し得ることを特徴とする、請求項16に記載のネットワーク。サーバ応答が複数のメッセージを含むこともあり、各々のメッセージがクライアントノードによって要求されたデータの一部を含むことを特徴とする、請求項17に記載のネットワーク。ユーザーインターフェースノードが、サーバ応答を行うスケールノードに向けられたクライアント要求を行うことを特徴とする、請求項18に記載のネットワーク。エアマットレスノードがサーバノードとして機能することを特徴とする、請求項19に記載のネットワーク。本出願は、添付した請求項に詳説した特徴および/または単独または任意の組み合わせにより特許性のある主題を構成しうる下記の特徴のうち、1つ以上を開示する。本開示によれば、患者支持装置用のマルチマスター通信ネットワークは、物理層、データリンク層、アプリケーション層、およびネットワーク層を含む。ネットワーク層は、複数のネットワークノードがクライアントとして同時に機能することを可能にするメッセージング構造を含む。クライアント要求のためのクライアントノード識別は、メッセージ識別が単一クライアント及びサーバの組み合わせに特有のものとなるよう修正されるように、ネットワークメッセージ識別に埋め込まれてもよい。サーバ応答のためのノード識別は、メッセージ識別が単一クライアント及びサーバの組み合わせに特有のものとなるよう修正されるように、ネットワークメッセージ識別に埋め込まれてもよい。特定のサーバノードからのデータを要求するために、クライアントノードによってクライアントメッセージが形成されてもよい。データが要求される対象である特定のサーバは、クライアント要求メッセージを送信したノードに向けられる特定のメッセージに応答することで、クライアント要求メッセージを送信するノードに直接応答してもよい。一部の実施態様において、ユーザーインターフェースノードは、サーバ応答を行うスケールノードに向けられたクライアント要求を行う。一部の実施態様において、エアマットレスノードはサーバノードとして機能する。ネットワークはさらに、外部インターフェース装置と通信するゲートウェイノードを含んでもよい。ゲートウェイノードは、外部インターフェース装置からのクエリーに応答して、ネットワーク上の別のノードにクライアント要求を行ってもよい。一部の実施態様において、外部インターフェース装置はナース通信ワークステーションである。ネットワーク層は、物理層に接続されたあらゆるノードがクライアント、サーバ、およびピアとして同時に通信しうるように構成されてもよい。ネットワーク上の単一ノードは、複数のその他のノードからのクライアント要求に同時に応答してもよい。サーバ応答は複数のメッセージを含んでもよく、各々のメッセージはクライアントノードによって要求されたデータの一部を含む。追加的な特徴は、上記に列挙したものおよび請求項に列挙したものを含めて、単独または他の任意の特徴複数の特徴と組み合わせて、特許性のある主題を構成すると考えられ、当業者にとっては、現時点で理解されている発明を遂行する最良の実施態様を例証する例示的な実施例の下記の詳細な説明を考察することにより明らかとなる。詳細な説明は添付した下記の図を特に参照する。図1には医療装置22の複数ノードの通信ネットワーク20が図示され、ノード24、26、28、および30はツイストペアバス32に接続されている。一つの例示的な実施態様において、ISO11898で指定されるようなコントローラエリアネットワークCAN仕様2.0Bが、ネットワーク20に使用される。例証として、ネットワーク20は、ISOモデルで定義されている七つのネットワーク層のうち三つの物理層、データリンク層、およびアプリケーション層を含む。物理層はツイストペアバス32を含む。物理層はまた、ノード24、26、28、および30の各々に存在するハードウェアを含む。ハードウェアは、バス32と通信するためのトランシーバと、搭載CANコントローラを有するマイクロコントローラとを含む。例示的な実施態様において、トランシーバはPhilipsElectronics製のTJA1054CANトランシーバである。例示的なマイクロコントローラは、Amtel製のT89C51CC01マイクロコントローラである。マイクロコントローラは、20MHz水晶などの水晶発振器に接続される。アプリケーション層はCANopen仕様に準拠する。CANopenは、通信インターフェースおよびプロトコルソフトウェア、オブジェクトディクショナリー、およびアプリケーションプログラムインターフェースを含む、オープン標準である。通信インターフェースおよびプロトコルソフトウェアは、CANopen装置がネットワーク20からメッセージを送受信できる手段を提供する。オブジェクトディクショナリーは、ネットワーク20から通信されるシステム変数情報のすべてを収集したものである。アプリケーションプログラムインターフェースは、アプリケーションソフトウェアがさまざまなネットワークパラメータとどのように相互作用するかを制御する。米国特許番号第7,506,390号参照により本明細書に援用されるに記載の通り、CANopenはノードのオブジェクトディクショナリーをネットワーク上のその他のノードからの新しい情報でもって更新するためのプロセスデータオブジェクトPDOプロトコルを含む。このような更新は、イベント駆動型でも時間間隔をベースにしたものでもよい。そのため、二つのメッセージが同時にネットワークにアクセスするとき、ネットワークメッセージには優先順位が付けられ、優先順位のより高いメッセージが優先順位のより低いメッセージの前にネットワークへのアクセス権を得る。ネットワーク全体にわたって共有されるデータが増加すると、ネットワークの容量は次第に消費されていく。CANopen実装で使用される別のデータプロトコルは、ネットワーク20上のノード間でのクライアントサーバ関係の確立を可能にするサービスデータオブジェクトSDOプロトコルである。このプロトコルは、任意のSDOメッセージ交換の二種の参加者、クライアントおよびサーバ、を含む。クライアントメッセージはSDO通信のマスターであり、クライアント対応ノードによってのみ有効化される。開始されると、クライアントメッセージはサーバメッセージとして単一のスレーブノードによって受け取られる。次にサーバは、適切なアクションまたは応答によってクライアントメッセージに応答する。SDOメッセージによって、SDOクライアントとSDOサーバとの間でピアツーピア通信関係を確立することが可能となる。CANopen仕様で定義されるように、SDO通信によってSDOを経由して最高127個のノードが通信できる。CANopen仕様内でのSDO通信に使用されるメッセージ識別子IDは最高127個のノードで使用でき、下記の形式に従う。SDOtx:0x581-0x5FFSDOrx:0x601-0x67Frxおよびtxの指定子は、サーバ装置の視点から参照されている。実際のオブジェクトIDを生成するために、ノードIDはベースSDOメッセージIDに追加される。例えば、ベースSDOメッセージIDである0x580および0x600を特定のサーバノードと使用してもよい。ノード識別子が2のサーバノードから、SDOダウンロードは次の形式に従う。SDOクライアントメッセージID要求データ:0x602SDOサーバメッセージIDデータ返信:0x582CANopenプロトコルはサーバ情報のみを含むSDO形式のみを有するため、メッセージIDにはいかなるクライアント情報も含まれない。このような制限のため、単一クライアントのみが一時に特定のサーバノードにアクセスすることができる。一般に、ネットワーク上の一つのノードのみがマスターと指定される。後述するように、場合によっては、クライアントとして操作される複数のノードが特定のサーバノードに同時アクセスしてオブジェクトデータを更新することが有利である。メッセージID付番形式を修正することで、各クライアントノードと各サーバノード間の独特のメッセージによって各ノードペアはクライアントサーバ通信関係を確立することが可能となる。このようにして、ノードとその他の任意のノード間の通信関係次第で、各ノードはクライアントおよびサーバの両方として操作することもできる。CANopenのSDOID形式は16進数での三桁を含むため、引き続きCANopen適合性のあるメッセージIDはクライアントノードの数を8に制限し、サーバ機能性を持つ合計ノードは15となる。例示的な実施態様において、SDOクライアントが開始するIDはどれも一桁目に6を含む。クライアントが開始する要求のオブジェクトIDの二桁目は、クライアントノードが開始するメッセージのノードIDから1を差し引いたものとして定義される。そのため、ノード0はクライアントノードに供給できない。クライアントが開始するメッセージのオブジェクトIDの三桁目は、16進数での標的SDOサーバのノードIDである。クライアントが開始する要求へのSDOサーバ応答は、一桁目が5と識別されるオブジェクトIDを持つ。サーバ応答の二桁目は、標的クライアントのノードIDに7を足した数である。三桁メッセージIDの三桁目はサーバのノードIDである。こうして、SDOクライアント対応ノードのノードIDは1~8である。非SDOクライアント対応ノードのノードIDは9~Fである。図2を参照すると、特定のメッセージのトランザクションにおいて、ノードIDが1のノード24は、ノードIDが2のノード26にデータを要求するクライアントメッセージを送信する。クライアント要求メッセージIDは602であり、一桁目の6はメッセージがクライアント要求であること、二桁目の0はノードから1を差し引いたノード値であること、三桁目の2は標的サーバの識別であることを示している。ノード26からの応答メッセージIDには582のオブジェクトIDがあり、一桁目の5はメッセージがサーバ応答であること、二桁目の8は標的クライアントに7を足したノードIDであること、三桁目の2はサーバノードIDであることを示している。図3を参照すると、さまざまなクライアントサーバ通信のオブジェクトIDが示されている。例示的な実施態様の四つのノードシステムにおいて、各ノードは別のノードそれぞれへクライアントとサーバとのどちらとしても作動しうる。図3の矢印はそれぞれ、クライアントノードからサーバノードに向けたクライアント要求を示している。各矢印の隣にあるテキストは、クライアント要求の三桁のオブジェクトIDを示し、その後にサーバ応答の三桁のオブジェクトIDを示している。例えば、図2に関して記載したクライアント要求およびサーバ応答のオブジェクトIDを、図3のノード24からノード26に向いた矢印の隣に示している。複数のノードにわたるSDOプロトコルの使用は、CANopen内部でのPDOプロトコルのデータプッシュアプローチにおける必要に応じたイベント駆動型または時間間隔に基づくプッシュ型での、大量のデータの転送に必要なネットワーク帯域幅を低下させる。クライアントノードを要求することで更新されたデータが必要となる場合のみ、SDO通信によって、ネットワーク20上でノード24、26、28、30がデータ更新を要求することが認められる。次に、要求を行うノードは、そのノードのオブジェクトディクショナリーをそれぞれのサーバノードによって提供された情報で更新する。データは、特定の通信を構成するノード間でのみ共有される。こうして、ノード24、26、28、および30はそれぞれ、独立したオブジェクトディクショナリーを維持する。例示的な実施態様において、ノード24、26、28、および30はそれぞれ、別のノードに更新を提供するためにイベント駆動型または時間間隔を置いてtimedintervalbasisPDO更新を出力してもよい。そのため、各ノードは一部の通信ではクライアント、一部の通信ではサーバ、また一部の通信ではピアとして機能してもよい。こうして、ネットワーク20にはマスターノードが存在しないものの、少なくとも8つのノードはネットワーク20上の別のノードからの特定のデータ転送のためのマスターとして機能してもよい。図4に示す例示的な実施態様において、患者支持装置110は、スケールノード124、移動制御ノード126、エアマットレスノード128、およびユーザーインターフェースノード130を含むネットワーク120を含む。ノード124、126、128および130はバス132に接続されている。例証として、これらのノード124、126、128および130はそれぞれ、SDOクライアント対応ノードSDOclientenablednodeとして構成されてもよい。各ノード124、126、128、および130は、PDOとして別のノードに利用できるデータでネットワーク120にわたるステータスの定期的な更新を提供してもよい。例えば、スケールノード124は、定期的な時間間隔でPDOとして計算された加重値を発行する。移動制御ノード126は、患者支持装置110のさまざまな部材の位置を定期的な時間間隔で識別するPDOメッセージを発行する。ユーザーインターフェースモジュール130は、さまざまなユーザー入力のステータスを示すPDOメッセージを定期的な間隔で発行する。ユーザーインターフェースノード130はまた、使用者がサービス情報を問い合わせるときに情報を収集するために、その他のノード124、126、および128にSDOクライアント要求を発行する。例えば、使用者は患者支持装置110の頭部部分の位置の履歴の閲覧を希望することもある。ユーザーインターフェースノード130のオブジェクトディクショナリーに存在するその履歴情報を維持する代わりに、ユーザーインターフェースノード130は、使用者が履歴について要求を行うときに、関連するデータのSDO要求を移動制御ノード126に対して発行する。次に、移動制御ノード126はユーザーインターフェースノード130に向けられたSDO応答として履歴データを発行する。SDO通信のために、ネットワーク120上でデータの転送のために必要な帯域幅は使用者がデータを要求するときだけに消費される。データが受け取られると、ユーザーインターフェースノード130上のアプリケーション層ソフトウェアがデータを形成し、データを示すディスプレー画像を生成する。別の具体例として、使用者がスケールノード124によって検知された体重の履歴を閲覧したいと要求する場合、ユーザーインターフェースモジュール130はスケールノード124にSDOクライアント要求を発行する。スケールノード124は、ユーザーインターフェースノード130のオブジェクトディクショナリーを更新するために要求されるデータを提供するサーバ応答SDOで返信する。場合によっては、サーバ応答SDOは、要求されたデータが単一応答メッセージの容量を超えると、複数のメッセージを介して送信することができる。患者支持装置110はまた、図5に示すようにネットワーク120上のノードとして操作するために、ネットワーク120のバス132に接続されたゲートウェイノード134を含んでもよい。ゲートウェイノード134はまた、イーサネット接続136によって外部インターフェース138に接続されている。一部の実施態様において、接続136はイーサネット以外の無線接続またはシリアル接続として具現化されてもよい。外部インターフェース138は、ゲートウェイノード134を通して患者支持装置110からデータを要求してもよい。ゲートウェイノード134は、その他のノード124、126、128および130から情報を引き出し、情報を外部インターフェース138と共有してもよい。例示的な実施態様において、外部インターフェース138はHill-Rom,Incインディアナ州ベイツビルのNaviCare登録商標NurseCallシステムなどの病院情報システムである。CANopenのSDOプロトコルを用いて、本明細書で開示するマルチマスターのアプローチは、大量のデータに対するPDOアプローチの使用と比べて必要な帯域幅を低下させるという利点を提供し、機能ノードに対して必要な処理電力を配電し、その他のプロトコルの使用から生じる帯域幅消費を回避する。例えば、イーサネットによって使用されるキャリア検知多重アクセス衝突検出CSMA/CD方法は、衝突が検知されたときにネットワークを妨害する。妨害期間中は、ネットワーク上ではいかなる通信も発生しない。CANopenによって使用される衝突防止方法は、より高い優先順位のメッセージがネットワークにアクセスできるように、優先順位別で衝突を解決する。こうして、衝突はイーサネットの場合に生じるように帯域幅を消費しない。加えて、開示された方法には複数のノードがクライアント要求を行う能力を含むため、ネットワークはトークンリング方法に従う必要がない。こうして、ネットワークにアクセスする許可を待つよりも、各ノードがネットワークにアクセスして情報を引き出し、優先順位に基づいてあらゆる潜在的な衝突が解決される。一定の例示的な実施態様について上記に詳細に説明してきたが、下記の請求項で説明および定義されるこの開示内容の範囲および精神で、変形や変更が存在する。"