コントローラ・エリア・ネットワークにおけるマルチマスター通信
【課題】クライアントとして操作される複数のノードが特定のサーバノードに同時アクセスしてオブジェクトデータを更新するメッセージング構造を提供する。
【解決手段】メッセージＩＤ付番形式を修正することで、各クライアントノードと各サーバノード間の独特のメッセージによって各ノードペアはクライアントサーバ通信関係を確立することが可能となる。メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正され、ノードとその他の任意のノード間の通信関係次第で、各ノードはクライアントおよびサーバの両方として操作することもできる。
【解決手段】メッセージＩＤ付番形式を修正することで、各クライアントノードと各サーバノード間の独特のメッセージによって各ノードペアはクライアントサーバ通信関係を確立することが可能となる。メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正され、ノードとその他の任意のノード間の通信関係次第で、各ノードはクライアントおよびサーバの両方として操作することもできる。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、複数のノードを持つネットワーク向けの埋め込み型ネットワークメッセージング構造に関連する。本開示はより具体的には、そのノードが、選択されたノードへのクライアント及び選択されたその他のノードに対するサーバとしての役割を同時に果たしうるネットワークに関連する。
【背景技術】
【０００２】
複雑な装置の制御システムにおいては、複数の装置は装置機能の機能性を制御するために独立して作用する。病院用ベッドなどの患者支持装置において、例えば、ベッド内部の特定の機能を実施するためにさまざまなサブシステムが操作される。例えば、ドライブシステムコントローラは、さまざまなアクチュエータの操作を管理してベッドの構成要素の位置を制御する。エアマットレスコントローラは、膨張装置および弁構造の操作を管理してマットレスの操作を制御する。スケールシステムは、体重センサーの操作およびコンパニオンロジック（companion logic）を管理して、ベッド上に支持される患者の体重を決定する。場合によっては、ベッド上での患者の位置の変化によって、スケールシステムが患者の特性を決定することさえもある。また別のユーザーインターフェースシステムは、入力装置を監視し出力装置を制御して、ベッドの操作を制御するために使用者がベッドとインターフェースで接続できるようにする。
【０００３】
サブシステム間を連結するために、マスターとして知られている中央システムマネジャー（central system manager）を使用することがよく知られている。マスターは、さまざまなサブシステムからの情報を制御し、適切な情報をその他のサブシステムと共有する。単一マスター構成において、マスターは通常、タスクの履行または情報の共有のためにさまざまなサブシステムを促すメインアルゴリズムを処理する。すべての通信はマスターによって制御され開始される。
【０００４】
さまざまなサブシステムが必要に応じて直接互いに通信し合う、マスターのない制御システム（masterless control system）を使用するその他のシステムもまた知られている。マスターのないシステムにおいては、各々の情報（each piece of information）は適切な受信者に向けられた単一のメッセージで共有されうるため、通信オーバーヘッドは低減される。対照的に、マスターに基づくシステム（master based system）では、サブシステムから情報を要求する第一のメッセージと、サブシステムからマスターへの返信メッセージとが必要となる。メッセージ情報が別のサブシステムによって使用される場合、マスターは第二のサブシステムに情報を送信する必要があり、情報の共有のために三つのメッセージが必要となる。そのため、マスターのないシステムでは必要となる通信回数がより少なく、その結果として通信帯域幅も低い。
【０００５】
必要な通信帯域幅はより低いものの、マスターのない通信には課題がある。第一の課題は、第一のサブシステムはいつメッセージを送信するべきか、という問題である。メッセージは、その他のサブシステムに定期的なステータス更新を提供するために、特定の時間間隔を置いて送信されてもよい。メッセージはまた、データの変化によってデータの更新が生じるようなイベント駆動型で送信されてもよい。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本出願は、添付した請求項に詳説した特徴および／または単独または任意の組み合わせにより特許性のある主題を構成しうる下記の特徴のうち、１つ以上を開示する。
【０００７】
本開示によれば、患者支持装置用のマルチマスター通信ネットワークは、物理層、データリンク層、アプリケーション層、およびネットワーク層を含む。ネットワーク層は、複数のネットワークノードがクライアントとして同時に機能することを可能にするメッセージング構造を含む。
【０００８】
クライアント要求のためのクライアントノード識別は、メッセージ識別が単一クライアント及びサーバの組み合わせに特有のものとなるよう修正されるように、ネットワークメッセージ識別に埋め込まれてもよい。サーバ応答のためのノード識別は、メッセージ識別が単一クライアント及びサーバの組み合わせに特有のものとなるよう修正されるように、ネットワークメッセージ識別に埋め込まれてもよい。
【０００９】
特定のサーバノードからのデータを要求するために、クライアントノードによってクライアントメッセージが形成されてもよい。データが要求される対象である特定のサーバは、クライアント要求メッセージを送信したノードに向けられる特定のメッセージに応答することで、クライアント要求メッセージを送信するノードに直接応答してもよい。
【００１０】
一部の実施態様において、ユーザーインターフェースノードは、サーバ応答を行うスケールノードに向けられたクライアント要求を行う。一部の実施態様において、エアマットレスノードはサーバノードとして機能する。
【００１１】
ネットワークはさらに、外部インターフェース装置と通信するゲートウェイノードを含んでもよい。ゲートウェイノードは、外部インターフェース装置からのクエリーに応答して、ネットワーク上の別のノードにクライアント要求を行ってもよい。一部の実施態様において、外部インターフェース装置はナース通信ワークステーションである。
【００１２】
ネットワーク層は、物理層に接続されたあらゆるノードがクライアント、サーバ、およびピアとして同時に通信しうるように構成されてもよい。ネットワーク上の単一ノードは、複数のその他のノードからのクライアント要求に同時に応答してもよい。サーバ応答は複数のメッセージを含んでもよく、各々のメッセージはクライアントノードによって要求されたデータの一部を含む。
【００１３】
追加的な特徴は、上記に列挙したものおよび請求項に列挙したものを含めて、単独または他の任意の特徴（複数の特徴）と組み合わせて、特許性のある主題を構成すると考えられ、当業者にとっては、現時点で理解されている発明を遂行する最良の実施態様を例証する例示的な実施例の下記の詳細な説明を考察することにより明らかとなる。
【００１４】
詳細な説明は添付した下記の図を特に参照する。
【図面の簡単な説明】
【００１５】
【図１】患者支持装置向けネットワークの第一の実施態様の図である。
【図２】図１のネットワーク上の二つのノード間のクライアント要求およびサーバ応答の識別の図表示である。
【図３】図１のネットワーク上のノード間でのクライアントサーバ通信に使用される数値識別子の図表示である。
【図４】患者支持装置向けネットワークの別の実施態様の図表示である。
【図５】追加的なノードと外部インターフェースとをさらに含めた、図４のネットワークの図表示である。
【発明を実施するための形態】
【００１６】
図１には医療装置２２の複数ノードの通信ネットワーク２０が図示され、ノード２４、２６、２８、および３０はツイストペアバス３２に接続されている。一つの例示的な実施態様において、ＩＳＯ １１８９８で指定されるようなコントローラ・エリア・ネットワーク（ＣＡＮ）仕様２．０Ｂが、ネットワーク２０に使用される。例証として、ネットワーク２０は、ＩＳＯモデルで定義されている七つのネットワーク層のうち三つの物理層、データリンク層、およびアプリケーション層を含む。物理層はツイストペアバス３２を含む。物理層はまた、ノード２４、２６、２８、および３０の各々に存在するハードウェアを含む。ハードウェアは、バス３２と通信するためのトランシーバと、搭載ＣＡＮコントローラを有するマイクロコントローラとを含む。例示的な実施態様において、トランシーバはＰｈｉｌｉｐｓ Ｅｌｅｃｔｒｏｎｉｃｓ製のＴＪＡ１０５４ ＣＡＮトランシーバである。例示的なマイクロコントローラは、Ａｍｔｅｌ製のＴ８９Ｃ５１ＣＣ０１マイクロコントローラである。マイクロコントローラは、２０ＭＨｚ水晶などの水晶発振器に接続される。
【００１７】
アプリケーション層はＣＡＮｏｐｅｎ仕様に準拠する。ＣＡＮｏｐｅｎは、通信インターフェースおよびプロトコルソフトウェア、オブジェクトディクショナリー、およびアプリケーションプログラムインターフェースを含む、オープン標準である。通信インターフェースおよびプロトコルソフトウェアは、ＣＡＮｏｐｅｎ装置がネットワーク２０からメッセージを送受信できる手段を提供する。オブジェクトディクショナリーは、ネットワーク２０から通信されるシステム変数情報のすべてを収集したものである。アプリケーションプログラムインターフェースは、アプリケーションソフトウェアがさまざまなネットワークパラメータとどのように相互作用するかを制御する。
【００１８】
米国特許番号第７，５０６，３９０号（参照により本明細書に援用される）に記載の通り、ＣＡＮｏｐｅｎはノードのオブジェクトディクショナリーをネットワーク上のその他のノードからの新しい情報でもって更新するためのプロセスデータオブジェクト（ＰＤＯ）プロトコルを含む。このような更新は、イベント駆動型でも時間間隔をベースにしたものでもよい。そのため、二つのメッセージが同時にネットワークにアクセスするとき、ネットワークメッセージには優先順位が付けられ、優先順位のより高いメッセージが優先順位のより低いメッセージの前にネットワークへのアクセス権を得る。ネットワーク全体にわたって共有されるデータが増加すると、ネットワークの容量は次第に消費されていく。
【００１９】
ＣＡＮｏｐｅｎ実装で使用される別のデータプロトコルは、ネットワーク２０上のノード間でのクライアントサーバ関係の確立を可能にするサービスデータオブジェクト（ＳＤＯ）プロトコルである。このプロトコルは、任意のＳＤＯメッセージ交換の二種の参加者、クライアントおよびサーバ、を含む。クライアントメッセージはＳＤＯ通信のマスターであり、クライアント対応ノードによってのみ有効化される。開始されると、クライアントメッセージはサーバメッセージとして単一のスレーブノードによって受け取られる。次にサーバは、適切なアクションまたは応答によってクライアントメッセージに応答する。
【００２０】
ＳＤＯメッセージによって、ＳＤＯクライアントとＳＤＯサーバとの間でピアツーピア通信関係を確立することが可能となる。ＣＡＮｏｐｅｎ仕様で定義されるように、ＳＤＯ通信によってＳＤＯを経由して最高１２７個のノードが通信できる。ＣＡＮｏｐｅｎ仕様内でのＳＤＯ通信に使用されるメッセージ識別子（ＩＤ）は最高１２７個のノードで使用でき、下記の形式に従う。
ＳＤＯ（ｔｘ）： ０ｘ５８１−０ｘ５ＦＦ
ＳＤＯ（ｒｘ）： ０ｘ６０１−０ｘ６７Ｆ
【００２１】
ｒｘおよびｔｘの指定子は、サーバ装置の視点から参照されている。実際のオブジェクトＩＤを生成するために、ノードＩＤはベースＳＤＯメッセージＩＤに追加される。例えば、ベースＳＤＯメッセージＩＤである０ｘ５８０および０ｘ６００を特定のサーバノードと使用してもよい。ノード識別子が２のサーバノードから、ＳＤＯダウンロードは次の形式に従う。
ＳＤＯクライアントメッセージＩＤ（要求データ）： ０ｘ６０２
ＳＤＯサーバメッセージＩＤ（データ返信）： ０ｘ５８２
【００２２】
ＣＡＮｏｐｅｎプロトコルはサーバ情報のみを含むＳＤＯ形式のみを有するため、メッセージＩＤにはいかなるクライアント情報も含まれない。このような制限のため、単一クライアントのみが一時に特定のサーバノードにアクセスすることができる。一般に、ネットワーク上の一つのノードのみがマスターと指定される。
【００２３】
後述するように、場合によっては、クライアントとして操作される複数のノードが特定のサーバノードに同時アクセスしてオブジェクトデータを更新することが有利である。メッセージＩＤ付番形式を修正することで、各クライアントノードと各サーバノード間の独特のメッセージによって各ノードペアはクライアントサーバ通信関係を確立することが可能となる。このようにして、ノードとその他の任意のノード間の通信関係次第で、各ノードはクライアントおよびサーバの両方として操作することもできる。
【００２４】
ＣＡＮｏｐｅｎのＳＤＯ ＩＤ形式は１６進数での三桁を含むため、引き続きＣＡＮｏｐｅｎ適合性のあるメッセージＩＤはクライアントノードの数を８に制限し、サーバ機能性を持つ合計ノードは１５となる。例示的な実施態様において、ＳＤＯクライアントが開始するＩＤはどれも一桁目に６を含む。クライアントが開始する要求のオブジェクトＩＤの二桁目は、クライアントノードが開始するメッセージのノードＩＤから１を差し引いたものとして定義される。そのため、ノード０はクライアントノードに供給できない。クライアントが開始するメッセージのオブジェクトＩＤの三桁目は、１６進数での標的ＳＤＯサーバのノードＩＤである。
【００２５】
クライアントが開始する要求へのＳＤＯサーバ応答は、一桁目が５と識別されるオブジェクトＩＤを持つ。サーバ応答の二桁目は、標的クライアントのノードＩＤに７を足した数である。三桁メッセージＩＤの三桁目はサーバのノードＩＤである。こうして、ＳＤＯクライアント対応ノードのノードＩＤは１〜８である。非ＳＤＯクライアント対応ノードのノードＩＤは９〜Ｆである。
【００２６】
図２を参照すると、特定のメッセージのトランザクションにおいて、ノードＩＤが１のノード２４は、ノードＩＤが２のノード２６にデータを要求するクライアントメッセージを送信する。クライアント要求メッセージＩＤは６０２であり、一桁目の６はメッセージがクライアント要求であること、二桁目の０はノードから１を差し引いたノード値であること、三桁目の２は標的サーバの識別であることを示している。ノード２６からの応答メッセージＩＤには５８２のオブジェクトＩＤがあり、一桁目の５はメッセージがサーバ応答であること、二桁目の８は標的クライアントに７を足したノードＩＤであること、三桁目の２はサーバノードＩＤであることを示している。
【００２７】
図３を参照すると、さまざまなクライアントサーバ通信のオブジェクトＩＤが示されている。例示的な実施態様の四つのノードシステムにおいて、各ノードは別のノードそれぞれへクライアントとサーバとのどちらとしても作動しうる。図３の矢印はそれぞれ、クライアントノードからサーバノードに向けたクライアント要求を示している。各矢印の隣にあるテキストは、クライアント要求の三桁のオブジェクトＩＤを示し、その後にサーバ応答の三桁のオブジェクトＩＤを示している。例えば、図２に関して記載したクライアント要求およびサーバ応答のオブジェクトＩＤを、図３のノード２４からノード２６に向いた矢印の隣に示している。
【００２８】
複数のノードにわたるＳＤＯプロトコルの使用は、ＣＡＮｏｐｅｎ内部でのＰＤＯプロトコルのデータプッシュアプローチにおける必要に応じたイベント駆動型または時間間隔に基づくプッシュ型での、大量のデータの転送に必要なネットワーク帯域幅を低下させる。クライアントノードを要求することで更新されたデータが必要となる場合のみ、ＳＤＯ通信によって、ネットワーク２０上でノード２４、２６、２８、３０がデータ更新を要求することが認められる。次に、要求を行うノードは、そのノードのオブジェクトディクショナリーをそれぞれのサーバノードによって提供された情報で更新する。データは、特定の通信を構成するノード間でのみ共有される。こうして、ノード２４、２６、２８、および３０はそれぞれ、独立したオブジェクトディクショナリーを維持する。
【００２９】
例示的な実施態様において、ノード２４、２６、２８、および３０はそれぞれ、別のノードに更新を提供するためにイベント駆動型または時間間隔を置いて（timed interval basis）ＰＤＯ更新を出力してもよい。そのため、各ノードは一部の通信ではクライアント、一部の通信ではサーバ、また一部の通信ではピアとして機能してもよい。こうして、ネットワーク２０にはマスターノードが存在しないものの、少なくとも８つのノードはネットワーク２０上の別のノードからの特定のデータ転送のためのマスターとして機能してもよい。
【００３０】
図４に示す例示的な実施態様において、患者支持装置１１０は、スケールノード１２４、移動制御ノード１２６、エアマットレスノード１２８、およびユーザーインターフェースノード１３０を含むネットワーク１２０を含む。ノード１２４、１２６、１２８および１３０はバス１３２に接続されている。例証として、これらのノード１２４、１２６、１２８および１３０はそれぞれ、ＳＤＯクライアント対応ノード（SDO client enabled node）として構成されてもよい。各ノード１２４、１２６、１２８、および１３０は、ＰＤＯとして別のノードに利用できるデータでネットワーク１２０にわたるステータスの定期的な更新を提供してもよい。例えば、スケールノード１２４は、定期的な時間間隔でＰＤＯとして計算された加重値を発行する。移動制御ノード１２６は、患者支持装置１１０のさまざまな部材の位置を定期的な時間間隔で識別するＰＤＯメッセージを発行する。ユーザーインターフェースモジュール１３０は、さまざまなユーザー入力のステータスを示すＰＤＯメッセージを定期的な間隔で発行する。
【００３１】
ユーザーインターフェースノード１３０はまた、使用者がサービス情報を問い合わせるときに情報を収集するために、その他のノード１２４、１２６、および１２８にＳＤＯクライアント要求を発行する。例えば、使用者は患者支持装置１１０の頭部部分の位置の履歴の閲覧を希望することもある。ユーザーインターフェースノード１３０のオブジェクトディクショナリーに存在するその履歴情報を維持する代わりに、ユーザーインターフェースノード１３０は、使用者が履歴について要求を行うときに、関連するデータのＳＤＯ要求を移動制御ノード１２６に対して発行する。次に、移動制御ノード１２６はユーザーインターフェースノード１３０に向けられたＳＤＯ応答として履歴データを発行する。ＳＤＯ通信のために、ネットワーク１２０上でデータの転送のために必要な帯域幅は使用者がデータを要求するときだけに消費される。データが受け取られると、ユーザーインターフェースノード１３０上のアプリケーション層ソフトウェアがデータを形成し、データを示すディスプレー画像を生成する。
【００３２】
別の具体例として、使用者がスケールノード１２４によって検知された体重の履歴を閲覧したいと要求する場合、ユーザーインターフェースモジュール１３０はスケールノード１２４にＳＤＯクライアント要求を発行する。スケールノード１２４は、ユーザーインターフェースノード１３０のオブジェクトディクショナリーを更新するために要求されるデータを提供するサーバ応答ＳＤＯで返信する。場合によっては、サーバ応答ＳＤＯは、要求されたデータが単一応答メッセージの容量を超えると、複数のメッセージを介して送信することができる。
【００３３】
患者支持装置１１０はまた、図５に示すようにネットワーク１２０上のノードとして操作するために、ネットワーク１２０のバス１３２に接続されたゲートウェイノード１３４を含んでもよい。ゲートウェイノード１３４はまた、イーサネット接続１３６によって外部インターフェース１３８に接続されている。一部の実施態様において、接続１３６はイーサネット以外の無線接続またはシリアル接続として具現化されてもよい。外部インターフェース１３８は、ゲートウェイノード１３４を通して患者支持装置１１０からデータを要求してもよい。ゲートウェイノード１３４は、その他のノード１２４、１２６、１２８および１３０から情報を引き出し、情報を外部インターフェース１３８と共有してもよい。例示的な実施態様において、外部インターフェース１３８はＨｉｌｌ−Ｒｏｍ，Ｉｎｃ.（インディアナ州ベイツビル）のＮａｖｉＣａｒｅ（登録商標） Ｎｕｒｓｅ Ｃａｌｌシステムなどの病院情報システムである。
【００３４】
ＣＡＮｏｐｅｎのＳＤＯプロトコルを用いて、本明細書で開示するマルチマスターのアプローチは、大量のデータに対するＰＤＯアプローチの使用と比べて必要な帯域幅を低下させるという利点を提供し、機能ノードに対して必要な処理電力を配電し、その他のプロトコルの使用から生じる帯域幅消費を回避する。例えば、イーサネットによって使用されるキャリア検知多重アクセス衝突検出（ＣＳＭＡ／ＣＤ）方法は、衝突が検知されたときにネットワークを妨害する。妨害期間中は、ネットワーク上ではいかなる通信も発生しない。ＣＡＮｏｐｅｎによって使用される衝突防止方法は、より高い優先順位のメッセージがネットワークにアクセスできるように、優先順位別で衝突を解決する。こうして、衝突はイーサネットの場合に生じるように帯域幅を消費しない。
【００３５】
加えて、開示された方法には複数のノードがクライアント要求を行う能力を含むため、ネットワークはトークンリング方法に従う必要がない。こうして、ネットワークにアクセスする許可を待つよりも、各ノードがネットワークにアクセスして情報を引き出し、優先順位に基づいてあらゆる潜在的な衝突が解決される。
【００３６】
一定の例示的な実施態様について上記に詳細に説明してきたが、下記の請求項で説明および定義されるこの開示内容の範囲および精神で、変形や変更が存在する。
【技術分野】
【０００１】
本開示は、複数のノードを持つネットワーク向けの埋め込み型ネットワークメッセージング構造に関連する。本開示はより具体的には、そのノードが、選択されたノードへのクライアント及び選択されたその他のノードに対するサーバとしての役割を同時に果たしうるネットワークに関連する。
【背景技術】
【０００２】
複雑な装置の制御システムにおいては、複数の装置は装置機能の機能性を制御するために独立して作用する。病院用ベッドなどの患者支持装置において、例えば、ベッド内部の特定の機能を実施するためにさまざまなサブシステムが操作される。例えば、ドライブシステムコントローラは、さまざまなアクチュエータの操作を管理してベッドの構成要素の位置を制御する。エアマットレスコントローラは、膨張装置および弁構造の操作を管理してマットレスの操作を制御する。スケールシステムは、体重センサーの操作およびコンパニオンロジック（companion logic）を管理して、ベッド上に支持される患者の体重を決定する。場合によっては、ベッド上での患者の位置の変化によって、スケールシステムが患者の特性を決定することさえもある。また別のユーザーインターフェースシステムは、入力装置を監視し出力装置を制御して、ベッドの操作を制御するために使用者がベッドとインターフェースで接続できるようにする。
【０００３】
サブシステム間を連結するために、マスターとして知られている中央システムマネジャー（central system manager）を使用することがよく知られている。マスターは、さまざまなサブシステムからの情報を制御し、適切な情報をその他のサブシステムと共有する。単一マスター構成において、マスターは通常、タスクの履行または情報の共有のためにさまざまなサブシステムを促すメインアルゴリズムを処理する。すべての通信はマスターによって制御され開始される。
【０００４】
さまざまなサブシステムが必要に応じて直接互いに通信し合う、マスターのない制御システム（masterless control system）を使用するその他のシステムもまた知られている。マスターのないシステムにおいては、各々の情報（each piece of information）は適切な受信者に向けられた単一のメッセージで共有されうるため、通信オーバーヘッドは低減される。対照的に、マスターに基づくシステム（master based system）では、サブシステムから情報を要求する第一のメッセージと、サブシステムからマスターへの返信メッセージとが必要となる。メッセージ情報が別のサブシステムによって使用される場合、マスターは第二のサブシステムに情報を送信する必要があり、情報の共有のために三つのメッセージが必要となる。そのため、マスターのないシステムでは必要となる通信回数がより少なく、その結果として通信帯域幅も低い。
【０００５】
必要な通信帯域幅はより低いものの、マスターのない通信には課題がある。第一の課題は、第一のサブシステムはいつメッセージを送信するべきか、という問題である。メッセージは、その他のサブシステムに定期的なステータス更新を提供するために、特定の時間間隔を置いて送信されてもよい。メッセージはまた、データの変化によってデータの更新が生じるようなイベント駆動型で送信されてもよい。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本出願は、添付した請求項に詳説した特徴および／または単独または任意の組み合わせにより特許性のある主題を構成しうる下記の特徴のうち、１つ以上を開示する。
【０００７】
本開示によれば、患者支持装置用のマルチマスター通信ネットワークは、物理層、データリンク層、アプリケーション層、およびネットワーク層を含む。ネットワーク層は、複数のネットワークノードがクライアントとして同時に機能することを可能にするメッセージング構造を含む。
【０００８】
クライアント要求のためのクライアントノード識別は、メッセージ識別が単一クライアント及びサーバの組み合わせに特有のものとなるよう修正されるように、ネットワークメッセージ識別に埋め込まれてもよい。サーバ応答のためのノード識別は、メッセージ識別が単一クライアント及びサーバの組み合わせに特有のものとなるよう修正されるように、ネットワークメッセージ識別に埋め込まれてもよい。
【０００９】
特定のサーバノードからのデータを要求するために、クライアントノードによってクライアントメッセージが形成されてもよい。データが要求される対象である特定のサーバは、クライアント要求メッセージを送信したノードに向けられる特定のメッセージに応答することで、クライアント要求メッセージを送信するノードに直接応答してもよい。
【００１０】
一部の実施態様において、ユーザーインターフェースノードは、サーバ応答を行うスケールノードに向けられたクライアント要求を行う。一部の実施態様において、エアマットレスノードはサーバノードとして機能する。
【００１１】
ネットワークはさらに、外部インターフェース装置と通信するゲートウェイノードを含んでもよい。ゲートウェイノードは、外部インターフェース装置からのクエリーに応答して、ネットワーク上の別のノードにクライアント要求を行ってもよい。一部の実施態様において、外部インターフェース装置はナース通信ワークステーションである。
【００１２】
ネットワーク層は、物理層に接続されたあらゆるノードがクライアント、サーバ、およびピアとして同時に通信しうるように構成されてもよい。ネットワーク上の単一ノードは、複数のその他のノードからのクライアント要求に同時に応答してもよい。サーバ応答は複数のメッセージを含んでもよく、各々のメッセージはクライアントノードによって要求されたデータの一部を含む。
【００１３】
追加的な特徴は、上記に列挙したものおよび請求項に列挙したものを含めて、単独または他の任意の特徴（複数の特徴）と組み合わせて、特許性のある主題を構成すると考えられ、当業者にとっては、現時点で理解されている発明を遂行する最良の実施態様を例証する例示的な実施例の下記の詳細な説明を考察することにより明らかとなる。
【００１４】
詳細な説明は添付した下記の図を特に参照する。
【図面の簡単な説明】
【００１５】
【図１】患者支持装置向けネットワークの第一の実施態様の図である。
【図２】図１のネットワーク上の二つのノード間のクライアント要求およびサーバ応答の識別の図表示である。
【図３】図１のネットワーク上のノード間でのクライアントサーバ通信に使用される数値識別子の図表示である。
【図４】患者支持装置向けネットワークの別の実施態様の図表示である。
【図５】追加的なノードと外部インターフェースとをさらに含めた、図４のネットワークの図表示である。
【発明を実施するための形態】
【００１６】
図１には医療装置２２の複数ノードの通信ネットワーク２０が図示され、ノード２４、２６、２８、および３０はツイストペアバス３２に接続されている。一つの例示的な実施態様において、ＩＳＯ １１８９８で指定されるようなコントローラ・エリア・ネットワーク（ＣＡＮ）仕様２．０Ｂが、ネットワーク２０に使用される。例証として、ネットワーク２０は、ＩＳＯモデルで定義されている七つのネットワーク層のうち三つの物理層、データリンク層、およびアプリケーション層を含む。物理層はツイストペアバス３２を含む。物理層はまた、ノード２４、２６、２８、および３０の各々に存在するハードウェアを含む。ハードウェアは、バス３２と通信するためのトランシーバと、搭載ＣＡＮコントローラを有するマイクロコントローラとを含む。例示的な実施態様において、トランシーバはＰｈｉｌｉｐｓ Ｅｌｅｃｔｒｏｎｉｃｓ製のＴＪＡ１０５４ ＣＡＮトランシーバである。例示的なマイクロコントローラは、Ａｍｔｅｌ製のＴ８９Ｃ５１ＣＣ０１マイクロコントローラである。マイクロコントローラは、２０ＭＨｚ水晶などの水晶発振器に接続される。
【００１７】
アプリケーション層はＣＡＮｏｐｅｎ仕様に準拠する。ＣＡＮｏｐｅｎは、通信インターフェースおよびプロトコルソフトウェア、オブジェクトディクショナリー、およびアプリケーションプログラムインターフェースを含む、オープン標準である。通信インターフェースおよびプロトコルソフトウェアは、ＣＡＮｏｐｅｎ装置がネットワーク２０からメッセージを送受信できる手段を提供する。オブジェクトディクショナリーは、ネットワーク２０から通信されるシステム変数情報のすべてを収集したものである。アプリケーションプログラムインターフェースは、アプリケーションソフトウェアがさまざまなネットワークパラメータとどのように相互作用するかを制御する。
【００１８】
米国特許番号第７，５０６，３９０号（参照により本明細書に援用される）に記載の通り、ＣＡＮｏｐｅｎはノードのオブジェクトディクショナリーをネットワーク上のその他のノードからの新しい情報でもって更新するためのプロセスデータオブジェクト（ＰＤＯ）プロトコルを含む。このような更新は、イベント駆動型でも時間間隔をベースにしたものでもよい。そのため、二つのメッセージが同時にネットワークにアクセスするとき、ネットワークメッセージには優先順位が付けられ、優先順位のより高いメッセージが優先順位のより低いメッセージの前にネットワークへのアクセス権を得る。ネットワーク全体にわたって共有されるデータが増加すると、ネットワークの容量は次第に消費されていく。
【００１９】
ＣＡＮｏｐｅｎ実装で使用される別のデータプロトコルは、ネットワーク２０上のノード間でのクライアントサーバ関係の確立を可能にするサービスデータオブジェクト（ＳＤＯ）プロトコルである。このプロトコルは、任意のＳＤＯメッセージ交換の二種の参加者、クライアントおよびサーバ、を含む。クライアントメッセージはＳＤＯ通信のマスターであり、クライアント対応ノードによってのみ有効化される。開始されると、クライアントメッセージはサーバメッセージとして単一のスレーブノードによって受け取られる。次にサーバは、適切なアクションまたは応答によってクライアントメッセージに応答する。
【００２０】
ＳＤＯメッセージによって、ＳＤＯクライアントとＳＤＯサーバとの間でピアツーピア通信関係を確立することが可能となる。ＣＡＮｏｐｅｎ仕様で定義されるように、ＳＤＯ通信によってＳＤＯを経由して最高１２７個のノードが通信できる。ＣＡＮｏｐｅｎ仕様内でのＳＤＯ通信に使用されるメッセージ識別子（ＩＤ）は最高１２７個のノードで使用でき、下記の形式に従う。
ＳＤＯ（ｔｘ）： ０ｘ５８１−０ｘ５ＦＦ
ＳＤＯ（ｒｘ）： ０ｘ６０１−０ｘ６７Ｆ
【００２１】
ｒｘおよびｔｘの指定子は、サーバ装置の視点から参照されている。実際のオブジェクトＩＤを生成するために、ノードＩＤはベースＳＤＯメッセージＩＤに追加される。例えば、ベースＳＤＯメッセージＩＤである０ｘ５８０および０ｘ６００を特定のサーバノードと使用してもよい。ノード識別子が２のサーバノードから、ＳＤＯダウンロードは次の形式に従う。
ＳＤＯクライアントメッセージＩＤ（要求データ）： ０ｘ６０２
ＳＤＯサーバメッセージＩＤ（データ返信）： ０ｘ５８２
【００２２】
ＣＡＮｏｐｅｎプロトコルはサーバ情報のみを含むＳＤＯ形式のみを有するため、メッセージＩＤにはいかなるクライアント情報も含まれない。このような制限のため、単一クライアントのみが一時に特定のサーバノードにアクセスすることができる。一般に、ネットワーク上の一つのノードのみがマスターと指定される。
【００２３】
後述するように、場合によっては、クライアントとして操作される複数のノードが特定のサーバノードに同時アクセスしてオブジェクトデータを更新することが有利である。メッセージＩＤ付番形式を修正することで、各クライアントノードと各サーバノード間の独特のメッセージによって各ノードペアはクライアントサーバ通信関係を確立することが可能となる。このようにして、ノードとその他の任意のノード間の通信関係次第で、各ノードはクライアントおよびサーバの両方として操作することもできる。
【００２４】
ＣＡＮｏｐｅｎのＳＤＯ ＩＤ形式は１６進数での三桁を含むため、引き続きＣＡＮｏｐｅｎ適合性のあるメッセージＩＤはクライアントノードの数を８に制限し、サーバ機能性を持つ合計ノードは１５となる。例示的な実施態様において、ＳＤＯクライアントが開始するＩＤはどれも一桁目に６を含む。クライアントが開始する要求のオブジェクトＩＤの二桁目は、クライアントノードが開始するメッセージのノードＩＤから１を差し引いたものとして定義される。そのため、ノード０はクライアントノードに供給できない。クライアントが開始するメッセージのオブジェクトＩＤの三桁目は、１６進数での標的ＳＤＯサーバのノードＩＤである。
【００２５】
クライアントが開始する要求へのＳＤＯサーバ応答は、一桁目が５と識別されるオブジェクトＩＤを持つ。サーバ応答の二桁目は、標的クライアントのノードＩＤに７を足した数である。三桁メッセージＩＤの三桁目はサーバのノードＩＤである。こうして、ＳＤＯクライアント対応ノードのノードＩＤは１〜８である。非ＳＤＯクライアント対応ノードのノードＩＤは９〜Ｆである。
【００２６】
図２を参照すると、特定のメッセージのトランザクションにおいて、ノードＩＤが１のノード２４は、ノードＩＤが２のノード２６にデータを要求するクライアントメッセージを送信する。クライアント要求メッセージＩＤは６０２であり、一桁目の６はメッセージがクライアント要求であること、二桁目の０はノードから１を差し引いたノード値であること、三桁目の２は標的サーバの識別であることを示している。ノード２６からの応答メッセージＩＤには５８２のオブジェクトＩＤがあり、一桁目の５はメッセージがサーバ応答であること、二桁目の８は標的クライアントに７を足したノードＩＤであること、三桁目の２はサーバノードＩＤであることを示している。
【００２７】
図３を参照すると、さまざまなクライアントサーバ通信のオブジェクトＩＤが示されている。例示的な実施態様の四つのノードシステムにおいて、各ノードは別のノードそれぞれへクライアントとサーバとのどちらとしても作動しうる。図３の矢印はそれぞれ、クライアントノードからサーバノードに向けたクライアント要求を示している。各矢印の隣にあるテキストは、クライアント要求の三桁のオブジェクトＩＤを示し、その後にサーバ応答の三桁のオブジェクトＩＤを示している。例えば、図２に関して記載したクライアント要求およびサーバ応答のオブジェクトＩＤを、図３のノード２４からノード２６に向いた矢印の隣に示している。
【００２８】
複数のノードにわたるＳＤＯプロトコルの使用は、ＣＡＮｏｐｅｎ内部でのＰＤＯプロトコルのデータプッシュアプローチにおける必要に応じたイベント駆動型または時間間隔に基づくプッシュ型での、大量のデータの転送に必要なネットワーク帯域幅を低下させる。クライアントノードを要求することで更新されたデータが必要となる場合のみ、ＳＤＯ通信によって、ネットワーク２０上でノード２４、２６、２８、３０がデータ更新を要求することが認められる。次に、要求を行うノードは、そのノードのオブジェクトディクショナリーをそれぞれのサーバノードによって提供された情報で更新する。データは、特定の通信を構成するノード間でのみ共有される。こうして、ノード２４、２６、２８、および３０はそれぞれ、独立したオブジェクトディクショナリーを維持する。
【００２９】
例示的な実施態様において、ノード２４、２６、２８、および３０はそれぞれ、別のノードに更新を提供するためにイベント駆動型または時間間隔を置いて（timed interval basis）ＰＤＯ更新を出力してもよい。そのため、各ノードは一部の通信ではクライアント、一部の通信ではサーバ、また一部の通信ではピアとして機能してもよい。こうして、ネットワーク２０にはマスターノードが存在しないものの、少なくとも８つのノードはネットワーク２０上の別のノードからの特定のデータ転送のためのマスターとして機能してもよい。
【００３０】
図４に示す例示的な実施態様において、患者支持装置１１０は、スケールノード１２４、移動制御ノード１２６、エアマットレスノード１２８、およびユーザーインターフェースノード１３０を含むネットワーク１２０を含む。ノード１２４、１２６、１２８および１３０はバス１３２に接続されている。例証として、これらのノード１２４、１２６、１２８および１３０はそれぞれ、ＳＤＯクライアント対応ノード（SDO client enabled node）として構成されてもよい。各ノード１２４、１２６、１２８、および１３０は、ＰＤＯとして別のノードに利用できるデータでネットワーク１２０にわたるステータスの定期的な更新を提供してもよい。例えば、スケールノード１２４は、定期的な時間間隔でＰＤＯとして計算された加重値を発行する。移動制御ノード１２６は、患者支持装置１１０のさまざまな部材の位置を定期的な時間間隔で識別するＰＤＯメッセージを発行する。ユーザーインターフェースモジュール１３０は、さまざまなユーザー入力のステータスを示すＰＤＯメッセージを定期的な間隔で発行する。
【００３１】
ユーザーインターフェースノード１３０はまた、使用者がサービス情報を問い合わせるときに情報を収集するために、その他のノード１２４、１２６、および１２８にＳＤＯクライアント要求を発行する。例えば、使用者は患者支持装置１１０の頭部部分の位置の履歴の閲覧を希望することもある。ユーザーインターフェースノード１３０のオブジェクトディクショナリーに存在するその履歴情報を維持する代わりに、ユーザーインターフェースノード１３０は、使用者が履歴について要求を行うときに、関連するデータのＳＤＯ要求を移動制御ノード１２６に対して発行する。次に、移動制御ノード１２６はユーザーインターフェースノード１３０に向けられたＳＤＯ応答として履歴データを発行する。ＳＤＯ通信のために、ネットワーク１２０上でデータの転送のために必要な帯域幅は使用者がデータを要求するときだけに消費される。データが受け取られると、ユーザーインターフェースノード１３０上のアプリケーション層ソフトウェアがデータを形成し、データを示すディスプレー画像を生成する。
【００３２】
別の具体例として、使用者がスケールノード１２４によって検知された体重の履歴を閲覧したいと要求する場合、ユーザーインターフェースモジュール１３０はスケールノード１２４にＳＤＯクライアント要求を発行する。スケールノード１２４は、ユーザーインターフェースノード１３０のオブジェクトディクショナリーを更新するために要求されるデータを提供するサーバ応答ＳＤＯで返信する。場合によっては、サーバ応答ＳＤＯは、要求されたデータが単一応答メッセージの容量を超えると、複数のメッセージを介して送信することができる。
【００３３】
患者支持装置１１０はまた、図５に示すようにネットワーク１２０上のノードとして操作するために、ネットワーク１２０のバス１３２に接続されたゲートウェイノード１３４を含んでもよい。ゲートウェイノード１３４はまた、イーサネット接続１３６によって外部インターフェース１３８に接続されている。一部の実施態様において、接続１３６はイーサネット以外の無線接続またはシリアル接続として具現化されてもよい。外部インターフェース１３８は、ゲートウェイノード１３４を通して患者支持装置１１０からデータを要求してもよい。ゲートウェイノード１３４は、その他のノード１２４、１２６、１２８および１３０から情報を引き出し、情報を外部インターフェース１３８と共有してもよい。例示的な実施態様において、外部インターフェース１３８はＨｉｌｌ−Ｒｏｍ，Ｉｎｃ.（インディアナ州ベイツビル）のＮａｖｉＣａｒｅ（登録商標） Ｎｕｒｓｅ Ｃａｌｌシステムなどの病院情報システムである。
【００３４】
ＣＡＮｏｐｅｎのＳＤＯプロトコルを用いて、本明細書で開示するマルチマスターのアプローチは、大量のデータに対するＰＤＯアプローチの使用と比べて必要な帯域幅を低下させるという利点を提供し、機能ノードに対して必要な処理電力を配電し、その他のプロトコルの使用から生じる帯域幅消費を回避する。例えば、イーサネットによって使用されるキャリア検知多重アクセス衝突検出（ＣＳＭＡ／ＣＤ）方法は、衝突が検知されたときにネットワークを妨害する。妨害期間中は、ネットワーク上ではいかなる通信も発生しない。ＣＡＮｏｐｅｎによって使用される衝突防止方法は、より高い優先順位のメッセージがネットワークにアクセスできるように、優先順位別で衝突を解決する。こうして、衝突はイーサネットの場合に生じるように帯域幅を消費しない。
【００３５】
加えて、開示された方法には複数のノードがクライアント要求を行う能力を含むため、ネットワークはトークンリング方法に従う必要がない。こうして、ネットワークにアクセスする許可を待つよりも、各ノードがネットワークにアクセスして情報を引き出し、優先順位に基づいてあらゆる潜在的な衝突が解決される。
【００３６】
一定の例示的な実施態様について上記に詳細に説明してきたが、下記の請求項で説明および定義されるこの開示内容の範囲および精神で、変形や変更が存在する。
【特許請求の範囲】
【請求項１】
患者支持装置用のマルチマスター通信ネットワークであって、前記ネットワークが、
物理層と、
データリンク層と、
アプリケーション層と、
複数のネットワークノードがクライアントとして同時に機能することを可能にするメッセージング構造を含むネットワーク層と、
を備えるネットワーク。
【請求項２】
クライアント要求のためのクライアントノード識別が、メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正されるように、ネットワークメッセージ識別に埋め込まれたことを特徴とする、請求項１に記載のネットワーク。
【請求項３】
サーバ応答のためのノード識別が、メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正されるように、ネットワークメッセージ識別に埋め込まれたことを特徴とする、請求項２に記載のネットワーク。
【請求項４】
サーバ応答のためのノード識別が、メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正されるように、ネットワークメッセージ識別に埋め込まれたことを特徴とする、請求項１に記載のネットワーク。
【請求項５】
特定のサーバノードからのデータを要求するために、クライアントノードによってクライアントメッセージが形成されることを特徴とする、請求項１に記載のネットワーク。
【請求項６】
前記データが要求される対象である特定のサーバが、クライアント要求メッセージを送信した前記ノードに向けられる特定のメッセージに応答することで、前記クライアント要求メッセージを送信する前記ノードに直接応答することを特徴とする、請求項５に記載のネットワーク。
【請求項７】
ユーザーインターフェースノードが、サーバ応答を行うスケールノードに向けられたクライアント要求を行うことを特徴とする、請求項６に記載のネットワーク。
【請求項８】
エアマットレスノードがサーバノードとして機能することを特徴とする、請求項７に記載のネットワーク。
【請求項９】
外部インターフェース装置と通信するゲートウェイノードをさらに含み、前記ゲートウェイノードが前記外部インターフェース装置からのクエリーに応答して前記ネットワーク上でその他のノードにクライアント要求を行う、請求項６に記載のネットワーク。
【請求項１０】
前記外部インターフェース装置がナース通信ワークステーションであることを特徴とする、請求項９に記載のネットワーク。
【請求項１１】
前記ネットワーク層が、前記物理層に接続されたあらゆるノードがクライアント、サーバ、およびピアとして同時に通信しうるように構成されることを特徴とする、請求項１０に記載のネットワーク。
【請求項１２】
前記ネットワーク上の単一ノードが、複数のその他のノードからのクライアント要求に同時に応答し得ることを特徴とする、請求項１１に記載のネットワーク。
【請求項１３】
サーバ応答が複数のメッセージを含むこともあり、各々のメッセージが前記クライアントノードによって要求された前記データの一部を含むことを特徴とする、請求項１２に記載のネットワーク。
【請求項１４】
外部インターフェース装置と通信するゲートウェイノードをさらに含み、当該ゲートウェイノードが前記外部インターフェース装置からのクエリーに応答して前記ネットワーク上でその他のノードにクライアント要求を行う、請求項１に記載のネットワーク。
【請求項１５】
前記外部インターフェース装置がナース通信ワークステーションであることを特徴とする、請求項１４に記載のネットワーク。
【請求項１６】
前記ネットワーク層が、前記物理層に接続されたあらゆるノードがクライアント、サーバ、およびピアとして同時に通信しうるように構成されることを特徴とする、請求項１５に記載のネットワーク。
【請求項１７】
前記ネットワーク上の単一ノードが、複数のその他のノードからのクライアント要求に同時に応答し得ることを特徴とする、請求項１６に記載のネットワーク。
【請求項１８】
サーバ応答が複数のメッセージを含むこともあり、各々のメッセージがクライアントノードによって要求されたデータの一部を含むことを特徴とする、請求項１７に記載のネットワーク。
【請求項１９】
ユーザーインターフェースノードが、サーバ応答を行うスケールノードに向けられたクライアント要求を行うことを特徴とする、請求項１８に記載のネットワーク。
【請求項２０】
エアマットレスノードがサーバノードとして機能することを特徴とする、請求項１９に記載のネットワーク。
【請求項１】
患者支持装置用のマルチマスター通信ネットワークであって、前記ネットワークが、
物理層と、
データリンク層と、
アプリケーション層と、
複数のネットワークノードがクライアントとして同時に機能することを可能にするメッセージング構造を含むネットワーク層と、
を備えるネットワーク。
【請求項２】
クライアント要求のためのクライアントノード識別が、メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正されるように、ネットワークメッセージ識別に埋め込まれたことを特徴とする、請求項１に記載のネットワーク。
【請求項３】
サーバ応答のためのノード識別が、メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正されるように、ネットワークメッセージ識別に埋め込まれたことを特徴とする、請求項２に記載のネットワーク。
【請求項４】
サーバ応答のためのノード識別が、メッセージ識別が単一のクライアントとサーバとの組み合わせについて特有になるように修正されるように、ネットワークメッセージ識別に埋め込まれたことを特徴とする、請求項１に記載のネットワーク。
【請求項５】
特定のサーバノードからのデータを要求するために、クライアントノードによってクライアントメッセージが形成されることを特徴とする、請求項１に記載のネットワーク。
【請求項６】
前記データが要求される対象である特定のサーバが、クライアント要求メッセージを送信した前記ノードに向けられる特定のメッセージに応答することで、前記クライアント要求メッセージを送信する前記ノードに直接応答することを特徴とする、請求項５に記載のネットワーク。
【請求項７】
ユーザーインターフェースノードが、サーバ応答を行うスケールノードに向けられたクライアント要求を行うことを特徴とする、請求項６に記載のネットワーク。
【請求項８】
エアマットレスノードがサーバノードとして機能することを特徴とする、請求項７に記載のネットワーク。
【請求項９】
外部インターフェース装置と通信するゲートウェイノードをさらに含み、前記ゲートウェイノードが前記外部インターフェース装置からのクエリーに応答して前記ネットワーク上でその他のノードにクライアント要求を行う、請求項６に記載のネットワーク。
【請求項１０】
前記外部インターフェース装置がナース通信ワークステーションであることを特徴とする、請求項９に記載のネットワーク。
【請求項１１】
前記ネットワーク層が、前記物理層に接続されたあらゆるノードがクライアント、サーバ、およびピアとして同時に通信しうるように構成されることを特徴とする、請求項１０に記載のネットワーク。
【請求項１２】
前記ネットワーク上の単一ノードが、複数のその他のノードからのクライアント要求に同時に応答し得ることを特徴とする、請求項１１に記載のネットワーク。
【請求項１３】
サーバ応答が複数のメッセージを含むこともあり、各々のメッセージが前記クライアントノードによって要求された前記データの一部を含むことを特徴とする、請求項１２に記載のネットワーク。
【請求項１４】
外部インターフェース装置と通信するゲートウェイノードをさらに含み、当該ゲートウェイノードが前記外部インターフェース装置からのクエリーに応答して前記ネットワーク上でその他のノードにクライアント要求を行う、請求項１に記載のネットワーク。
【請求項１５】
前記外部インターフェース装置がナース通信ワークステーションであることを特徴とする、請求項１４に記載のネットワーク。
【請求項１６】
前記ネットワーク層が、前記物理層に接続されたあらゆるノードがクライアント、サーバ、およびピアとして同時に通信しうるように構成されることを特徴とする、請求項１５に記載のネットワーク。
【請求項１７】
前記ネットワーク上の単一ノードが、複数のその他のノードからのクライアント要求に同時に応答し得ることを特徴とする、請求項１６に記載のネットワーク。
【請求項１８】
サーバ応答が複数のメッセージを含むこともあり、各々のメッセージがクライアントノードによって要求されたデータの一部を含むことを特徴とする、請求項１７に記載のネットワーク。
【請求項１９】
ユーザーインターフェースノードが、サーバ応答を行うスケールノードに向けられたクライアント要求を行うことを特徴とする、請求項１８に記載のネットワーク。
【請求項２０】
エアマットレスノードがサーバノードとして機能することを特徴とする、請求項１９に記載のネットワーク。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１２−５４９０６（Ｐ２０１２−５４９０６Ａ）
【公開日】平成２４年３月１５日（２０１２．３．１５）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１１−１２３３９７（Ｐ２０１１−１２３３９７）
【出願日】平成２３年６月１日（２０１１．６．１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
【出願人】（５０３２７８２５６）ヒル−ロム サービシズ，インコーポレイテッド (14)
【Ｆターム（参考）】
【公開日】平成２４年３月１５日（２０１２．３．１５）
【国際特許分類】
【出願番号】特願２０１１−１２３３９７（Ｐ２０１１−１２３３９７）
【出願日】平成２３年６月１日（２０１１．６．１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
【出願人】（５０３２７８２５６）ヒル−ロム サービシズ，インコーポレイテッド (14)
【Ｆターム（参考）】
[ Back to top ]