(57)【要約】  ストリーミングビデオを送信する方法及び装置が提供される。この方法及び装置は、帯域の考慮に基づいて送信レートを動的に変更すること、ネットワークでの帯域の可用性を予測すること、又はこれらの双方を有する。【特許請求の範囲】
【請求項１】
通信リンクでストリーミングビデオを送信し；
前記ストリーミングビデオを受信し；
前記リンクでの帯域の変化を決定し；
前記帯域の変化に基づいて前記ストリーミングビデオをデコードするレートを変更することを有するビデオ通信方法。
【請求項２】
前記変更することは、前記帯域の変化がマイナスである場合に、送信のレートを低減することを更に有する、請求項１に記載の方法。
【請求項３】
前記変更することは、前記帯域の変化が最小値未満の帯域になる場合に、送信を終了することを更に有する、請求項１に記載の方法。
【請求項４】
前記変更することは：
前記ストリーミングビデオの１つより多くのビデオストリームを同時に提供し、前記ビデオストリームのそれぞれは、異なる送信レートで提供され；
前記帯域の変化に基づいて、低い送信レートで送信される他のビデオストリームに切り替えることを更に有する、請求項１に記載の方法。
【請求項５】
前記変更することは：
前記ストリーミングビデオの１つより多くのビデオストリームを同時に提供し、前記ビデオストリームのそれぞれは、異なる送信レートで提供され；
前記帯域の変化に基づいて、高い送信レートで送信される他のビデオストリームに切り替えることを更に有する、請求項１に記載の方法。
【請求項６】
前記ビデオストリームのそれぞれの選択されたポイントにインデックスを含め；
前記他のビデオストリームの次のインデックスで切り替えを行うことを更に有する、請求項４に記載の方法。
【請求項７】
ストリーミングビデオを受信し、帯域の変化に基づいて、前記ストリーミングビデオの送信レートを変更するビデオプレイヤを有する、ビデオ送信及び受信装置。
【請求項８】
前記ビデオプレイヤは、前記帯域の変化がマイナスである場合に、前記送信レートを低減する、請求項７に記載の装置。
【請求項９】
前記ビデオプレイヤは、前記ストリーミングビデオの送信を終了する、請求項７に記載の装置。
【請求項１０】
メディアサーバは、前記ストリーミングビデオの１つより多くのビデオストリームを同時に提供し、
前記ビデオストリームのそれぞれは、異なる送信レートで提供され、
前記ビデオプレイヤは、前記帯域の変化に基づいて、１つのビデオストリームを選択するように適合される、請求項７に記載の装置。
【請求項１１】
前記ビデオプレイヤは、患者情報システムの構成要素であり、
前記メディアサーバは、ホストセンタの構成要素である、請求項７に記載の装置。
【請求項１２】
通信システムにおけるビデオ通信方法であって：
第１の送信レートでメディアサーバからビデオプレイヤにパケットでストリーミングビデオを送信し；
前記送信で損失したパケット数を決定し；
前記損失したパケット数と閾値とを比較し；
前記比較に基づいて前記第１の送信レートで送信を続けること又は第２の送信レートに送信を切り替えることを有する方法。
【請求項１３】
前記第２の送信レートは、前記第１の送信レートより小さい、請求項１２に記載の方法。
【請求項１４】
前記第２の送信レートは、前記第１の送信レートより大きい、請求項１２に記載の方法。
【請求項１５】
前記ビデオプレイヤは、患者情報システムの構成要素であり、
前記メディアサーバは、ホストセンタの構成要素である、請求項１２に記載の方法。
【請求項１６】
通信システムにおけるビデオ通信方法であって：
ストリーミングビデオ通信の１つ以上のパスの帯域容量を推定し；
前記推定に基づいて、前記パスのそれぞれの送信レートを選択し；
前記選択された送信レートで各パスを通じてメディアサーバからビデオプレイヤにストリーミングビデオを送信することを有する方法。
【請求項１７】
前記推定することは：
前記システムの前記パスの静的な全体マップを蓄積し；
トラヒック輻輳が生じ得る前記マップの位置を予測することを更に有する、請求項１６に記載の方法。
【請求項１８】
前記推定することは：
前記システムの前記パスのそれぞれの予想トラヒック負荷の関数を計算することを更に有する、請求項１６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この出願は、“Interactive  Patient  Care  System”という題で2005年10月25日に出願された米国特許出願第60/730,088号（代理人整理番号001362）に関し、この優先権を主張する。この出願の開示が特に参照として取り込まれる。
【背景技術】
【０００２】
ビデオ通信は、現在の社会で遍在している。テレビのような多くの従来の表示装置に加えて、コンピュータ、携帯情報端末（PDA：personal  digital  assistant）及び携帯電話のような装置が、表示用にビデオ情報を受信するように適合されている。
【０００３】
ビデオは、しばしばインターネットプロトコル（IP：internet  protocol）を介してネットワークで配信される。しばしばIPで提供される１つの種類のビデオは、ストリーミングビデオである。ストリーミングビデオは、しばしばネットワークで送信される。例えば、ストリーミングビデオは、広帯域ネットワークで送信されてもよい。典型的には、ストリーミング媒体は、ネットワーク上でパケットで伝達される。短い量のビデオ（場合によっては1秒）が、ストリーミングビデオプレイヤのローカルにバッファされ、チャネルの変動を平均化する。ストリーミングビデオプレイヤは、しばしばローカルメモリ（RAM）のブロックであるバッファからビデオを再生する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ストリーミングビデオは、効率的な送信のために比較的大きい帯域能力を必要とし得る。ストリーミングビデオの送信機と受信機との間の媒体が必要な帯域を提供できない場合、画像の品質の劣化が生じ得る。この劣化は、例えば偽信号（artifact）及びマクロブロック（macroblocking）として明瞭になり得る。帯域の要件と帯域の可用性との間の不一致が増加すると、ビデオ劣化の深刻さが増加する。例示的に、偽信号の継続期間及び深刻さが増加し得る。
【０００５】
ストリーミングビデオの特定のサービス品質（QoS：quality  of  service）を確保する１つの手法は、ストリーミングビデオの専用のエンドポイント対エンドポイントのリンクを提供することである。このようなリンクは、指定の帯域が維持されることを確保する。専用のリンクは、ストリーミングビデオの保証QoSを提供することに有用であるが、このようなリンクの使用は、１人のユーザ又はせいぜい数人のユーザに確保される。各リンクが確立されなければならず、装置がリンク毎に必要になるため、このような取り組みのコスト及び効率は実用的ではない。
【０００６】
前述の欠点を少なくとも克服するストリーミングビデオを提供する方法及び装置の必要性が存在する。
【課題を解決するための手段】
【０００７】
例示的な実施例によれば、ビデオ通信方法は、非専用通信リンクでストリーミングビデオを送信することを有する。この方法は、ストリーミングビデオを受信し、リンクでの帯域の変化を決定することを更に有する。更に、この方法は、変化に基づいて送信のレートを変更することを有する。
【０００８】
他の例示的な実施例によれば、ビデオ送信及び受信装置は、ストリーミングビデオを送信するように適合されたメディアサーバと、ストリーミングビデオを受信するように適合されたビデオプレイヤとを有する。ビデオプレイヤとメディアサーバとの間のリンクでの帯域の変化に基づいて、ビデオプレイヤは、ストリーミングビデオの送信レートを変更するように適合される。
【０００９】
更に他の例示的な実施例によれば、通信システムにおけるビデオ通信方法は、第１の送信レートでメディアサーバからビデオプレイヤにパケットでストリーミングビデオを送信し、送信で損失したパケット数を決定し、損失したパケット数と閾値とを比較し、比較に基づいて第１の送信レートで送信を続けること又は第２の送信レートに送信を切り替えることを有する。
【００１０】
更に他の実施例によれば、通信システムにおけるビデオ通信方法は、ビデオ通信の１つ以上のパスの帯域容量を推定することを有する。この方法はまた、推定に基づいて、パスのそれぞれの送信レートを選択し、選択された送信レートで各パスを通じてメディアサーバからビデオプレイヤにストリーミングビデオを送信することを有する。
【発明を実施するための最良の形態】
【００１１】
本発明は、添付図面と共に読まれたときに、以下の詳細な説明から最も良く理解される。様々な機能は必ずしも縮尺通りに示されていないことを強調する。実際に、説明を明瞭にするために、大きさは任意に増加又は減少され得る。
【００１２】
以下の詳細な説明では、限定ではなく説明の目的で、この教示の完全な理解を提供するために、特定の詳細を開示する例示的な実施例が示される。しかし、特定の詳細を逸脱する他の実施例がここに開示されていることが、この開示の利益を有する当業者に明らかになる。更に、例示的な実施例の説明をあいまいにしないように、周知の装置、ハードウェア、ソフトウェア、方法、システム及びプロトコルの説明は省略されることがある。それにもかかわらず、当業者の範囲内にあるこのようなハードウェア、ソフトウェア、装置、方法、システム及びプロトコルが、例示的な実施例に従って使用され得る。最後に、当てはまる場合には、同様の参照符号は同様の機能を示す。
【００１３】
記載の例示的な実施例は、ストリーミングビデオが患者に提供され得る患者情報システムに関する。患者情報システムは、前述の出願に記載されるようなものでもよい。しかし、この教示は患者情報システムの用途に限定されない。このため、この教示の他の用途も考えられ、このような用途が患者情報システムに関係しない実施例で達成されてもよい。例えば、この教示の方法及び装置は、娯楽用途、医療ではない教育ビデオサービス及びビデオゲームで実施されてもよい。有利には、この教示の方法及び装置は、ネットワークの他のユーザのQoSとせいぜい最低限にしか干渉しないストリーミングビデオの通信を生じる。
【００１４】
図１は、例示的な実施例による患者情報システム100の簡略ブロック図である。システム100は、患者システム101と、サーバ102と、臨床医端末103とを有する。サーバ102及び患者システム101は、ネットワーク104を介して通信している。ネットワークと患者端末との間のリンクは、例示的に既知のインターネットプロトコル（IP）に従う。ネットワーク104は、同軸ケーブル又は光ファイバケーブルでの広帯域ネットワークでもよい。いずれの場合でも、既知の構成要素及びソフトウェアがネットワークを実現するために実装され得る。例えば、光ファイバネットワークでは、トランシーバのような装置が提供され、広帯域ケーブルネットワークでは、ケーブルモデムのような装置が提供される。
【００１５】
代替として、ネットワーク104は、無線ネットワーク又はデジタル加入者回線（XDSL：digital  subscriber  line）ネットワークでもよい。無線ネットワークは、システムのプロトコルにより指定されたインフラストラクチャを有する。例えば、無線ネットワークは、IEEE802.11又はその子孫に準拠してもよく、提案されているIEE802.22（しばしばSARS（spectrum  agile  radio  system）と呼ばれる）に準拠してもよい。XDSLネットワークは、必要なXDSLインフラストラクチャを備えた公衆電話サービス（POTS：plain  old  telephone  service）回線上に実装されてもよい。
【００１６】
臨床医端末103は、サーバ102、ネットワーク104及び患者システム101とインタフェースするために必要なプレゼンテーションレイヤソフトウェア（ユーザインタフェースソフトウェア）を有するパーソナルコンピュータでもよい。端末103は、既知のイントラネット接続（有線又は無線接続等）を通じてサーバ102に接続されてもよい。サーバ102（ホストセンタと呼ばれてもよい）及びイントラネット接続は、情報技術の当業者に周知であるため、実施例の説明をあいまいにすることを回避するために詳細には説明しない。
【００１７】
ここに記載の例示的な実施例では、説明の簡略化のために、１つの患者システム101と１つのサーバ102と１つの臨床医端末103とが図示及び記載される。しかし、患者情報システム100は、必要に応じて、複数の患者システム101と、複数のサーバ102と、複数の臨床医端末103とを有することが考えられる。
【００１８】
サーバ102は、プロセッサ105を有する。サーバ102はまた、測定サーバ106と、装置データベース112と、メディア配信サーバ108とを有する。例示的な実施例では、サーバ102は、ハードウェアとソフトウェアとファームウェアとの統合構成要素でもよい。ネットワーク104とプロセッサ105との間の通信及びネットワーク104と測定サーバ106との間の通信は、例示的にハイパーテキスト転送プロトコル（HTTP：hypertext  transfer  protocol）に従う。サーバ106-108の多くの機能は前述の出願に共通しており、前述の出願に詳細に記載されている。特定の顕著な機能がここで提供される。
【００１９】
測定サーバ106は、ネットワークを介して患者システム101から測定データを受信する。これらのデータは、臨床医による適切なアクションのため、測定サーバで分析される。測定サーバ106から取得されたデータは、SQLリンクを介してデータベース112に提供される。更に、測定サーバ106は、イントラネットを介して臨床医端末103に測定分析（例えば、レポート又は要約）を提供する。
【００２０】
メディア配信サーバ108は、ストリーミングビデオと他のフォーマットの情報とを患者情報システム101に提供する。ストリーミングビデオは、リアルタイムストリーミングプロトコル（RTSP：real  time  streaming  protocol）若しくはリアルタイムプロトコル（RTP：real  time  protocol）又はリアルタイム制御プロトコル（RTCP：real  time  control  protocol）に従ってもよい。
【００２１】
プロセッサ105は、構成サーバ109と、セットトップボックス（STB：set-top  box）サーバ110と、STBローダサーバ111とを有する。これらの構成要素の詳細は、取り込まれた前述の出願にある。
【００２２】
臨床医と患者との間で伝達される情報の敏感度により、有利には、端末103とサーバ102と患者システム101との間のリンクは安全である。特定の実施例では、接続は、仮想プライベートネットワークコンソーシアム（VPNC：virtual  private  network  consortium）による仮想プライベートネットワーク（VPN：virtual  private  network）を提供するために、暗号化及び他の既知のセキュリティ手段を有する。このように、安全なリンクが公衆アクセスリンク（電話及び同軸ケーブル回線等）を介して提供されてもよい。代替として、無線ローカルエリアネットワーク（無線LAN）又は無線広域ネットワーク（WAN）が例示的な実施例のリンクのいずれかで使用される場合、リンクで送信される情報が安全であることを確保するために既知の暗号化及びセキュリティ手段が実装されてもよい。
【００２３】
患者システム101は、前述の出願に記載のSTBでもよい制御モジュール113を有する。特に、制御モジュール113は、ビデオプレイヤと呼ばれてもよい。特定の実施例では、制御モジュール113は、メディア配信サーバ108からのストリーミングビデオを変換して表示する。制御モジュールはまた、ファームウェア114と、STBローダ115と、TVユーザインタフェース（UI：user  interface）116と、測定ゲートウェイ117とを有する。
【００２４】
ファームウェア114及びSTBローダは、メディア配信サーバ108からのストリーミングビデオをデコードするように適合される。このデコードに必要なハードウェアとソフトウェアとファームウェアとは、ストリーミングビデオの送信に使用されるプロトコルに特有である。
【００２５】
複数の測定装置118が含まれてもよいが、全てのシステムに含まれなくてもよい。測定装置は、有線又は無線リンクによりクライアントモジュール113に結合されてもよい。制御モジュールはまた、ビデオディスプレイ119に結合され、遠隔制御装置120により制御されてもよい。患者システム101の構成要素及び機能の詳細は、前述の出願に更に完全に記載されている。
【００２６】
図２は、例示的な実施例によるストリーミングビデオトラヒック制御方法のフローチャートである。この方法は、図１と共に検討されたときに最も理解される。この例示的な実施例の詳細をあいまいにすることを回避するため、共通の詳細は一般的には繰り返されない。
【００２７】
ステップ201において、患者システム101は、ストリーミングビデオを受信する。特定の実施例では、ストリーミングビデオは、メディア配信サーバ108からRTSPプロトコルに従って送信されたデジタル化ビデオパケットデータである。これらのデータのデコードは当業者に既知である。
【００２８】
ステップ202において、患者システム101は、ストリーミングビデオリンクの送信帯域の変化が生じたことを決定する。送信帯域の変化の決定は、複数の方法により実現されてもよい。例示的に、STB113のファームウェア114及びローダ115は、デコーダを有する。デコーダは、メディア配信サーバ108からのストリーミングビデオ信号に存在する偽信号の数及び深刻さを決定するように適合される。偽信号が存在する場合、メディア配信サーバ108及びネットワーク104は、現時点でデコーダの帯域を満たすことができない。従って、メディア配信サーバ108及びネットワーク104は、中断のないビデオ画像を生成するために制御モジュール113（ビデオプレイヤ）に必要なレートでデジタル化ストリーミングビデオを提供することができず、デコーダはこの障害を検出する。代替として、メディア配信サーバ113及びネットワーク104の帯域能力が増加してもよい。この場合、制御モジュール113は、容量の利用不足を検出する。
【００２９】
ステップ203において、メディア配信サーバ108は、送信レートを変更する。ストリーミングビデオの送信レートの変更は、異なる目的を実現するように達成されてもよい。１つの例示的な実施例では、STB113は、ストリーミングビデオの送信レートがネットワークの現在の容量に対して大きすぎるというメッセージをメディア配信サーバ108に提供する。このエラーメッセージで、STB113は、低いデータレートで送信するコマンドを含めてもよい。
【００３０】
特定の実施例では、メディア配信サーバ108は、ビデオの複数のストリームを同時に且つ実質的に同期して提供するように適合される。各ストリームは異なる送信レートで提供されるが、唯一のストリームが同時にSTB113に送信されてもよい。現在のストリームが現在のネットワーク容量に対して大きすぎる場合、STBからのコマンドは、指定の低い送信レートに切り替える指示を含む。更に、異なるビデオストリームは、ストリーミングビデオの特定のフレームを特定するインデックス又はマーカを有してもよい。コマンドは、低い送信レートのストリーミングビデオに切り替えるための次のマーカを特定する。切り替え時に、メディア配信サーバ108は、STB113に配信するために、選択されたストリーミングビデオをネットワーク104に送信する。
【００３１】
前述のように、STB113は、送信エラーを検出するように適合される。特定の実施例では、ビデオパケットのストリームにヘッダが提供される。ヘッダは、ストリーミングビデオの継続期間及び送信レートを有する。ストリーミングビデオのパケットが所定のデータレートで到達しない場合、又は特定のパケットがSTB113に到達しない場合、若しくはこれらの双方の場合、STB113は、送信のレートをアルゴリズム的に決定する、若しくは特定の期間に損失したパケットの数を定量化する、又はこれらの双方を行う。この決定の後に、STB113は、低い送信のレートをアルゴリズム的に決定する。
【００３２】
行われるべきアクションについての指示と共に、エラーメッセージは、メディア配信サーバ108に送信される。例示的に、アクションは、サーバ104が所定のインデックスポイントで他の同時のビデオストリームを送信するように指示することを有してもよい。代替として、アクションは、帯域能力がストリーミングビデオの送信を維持するのに不十分である場合に、サーバ104が送信を終了するように指示してもよい。
【００３３】
ステップ203の終了時に、処理はステップ201で初めから繰り返されてもよい。
【００３４】
他の利点の中でも、例示的な実施例の方法は、適切なストリーミングビデオのQoSを患者に提供することを促進する。特に、サービスが削減された場合に、容認可能であり、不十分な帯域が現在存在しない場合、ビデオは、ネットワーク103及びサーバ108が少なくとも最小の送信レートを維持することができる後の時点に視聴され得る。更に、サービスの終了は、ネットワーク104及びサーバ108の負荷を低減する。従って、ネットワーク104の他のユーザは、改善したサービスを有する。例えば、ある時間の１つのビデオストリームの終了は、完全な送信レート又は低減した送信レートでの他のビデオストリームの送信を可能にするのに十分になり得る。
【００３５】
図３は、例示的な実施例によるストリーミングビデオトラヒック制御方法のフローチャートである。この方法は、図１と共に検討されたときに最も理解される。この例示的な実施例の詳細をあいまいにすることを回避するため、共通の詳細は一般的には繰り返されない。
【００３６】
ステップ301において、メディア配信サーバ108は、メディア配信サーバ108から患者システム101に送信されたストリーミングビデオパケットのパケット損失率の指標を抽出する。パケット損失を決定する方法は、既知の方法でもよい。例示的に、受信機（例えばSTB113）からパケット損失統計を集める既知の技術は、選択されたプロトコルを介して実施されてもよい。例えば、RTP又はRTSPプロトコルは、パケットの受信機でのパケット損失統計を決定することを提供する。例示的な実施例によれば、これらのデータは、メディア配信サーバ108に提供されてもよい。
【００３７】
ステップ302において、パケット損失データは、閾値と比較される。例示的な実施例では、メディア配信サーバ108は、パケット損失データと閾値とをアルゴリズム的に比較するように適合される。特に、１つより多くの閾値が存在し、それぞれの値が特定の送信レートに対応してもよい。比較に基づいて、アルゴリズムは、特定のQoSを維持するために送信レートの何らかの変化が必要になるか否かを決定し、変化が必要な場合に、１つの閾値に最も密接に関係する送信レートを選択する。
【００３８】
例示目的で、パケット損失率の３つの閾値（T1、T2及びT3）が存在することを仮定する。T1は、最大の閾値（最低の送信レート）を表し、T3は、最低の閾値（最高の送信レート）を表す。パケット損失データがT1とT2との間であることを仮定する。（最高の送信レートに対応する）最高の送信レートを選択することは、受け入れられないQoSを生じるため、サーバは、第２の閾値T2に対応する送信レートを選択する。このように、QoSは容認可能になる。サーバ108が既にこの‘中間’データレートで送信している場合、変化は必要ない。サーバ108が高いデータレートで送信している場合、サーバ108は、中間の送信レートに送信レートを変化させる。最後に、サーバ108が低いデータレートで送信している場合、サーバ108は、高いデータレートに送信レートを変化させる。
【００３９】
例示的な実施例では、他の誤り訂正技術のパケット損失の決定が、複数の基準に基づいて実行されてもよい。例えば、決定されたパケット損失に対するサンプリング送信（sampled  transmission）が所定の時間間隔又は指定回数で実行されてもよく、選択されたデータポイントのようなデータに基づいてもよい。更に、サンプリングデータは、最近のエラーデータにより規定されてもよい。このため、最近のサンプルからのパケット損失データが閾値に近い場合、閾値レベルに到達する可能性も増加し得るため、サンプリングレートが増加してもよい。
【００４０】
ステップ303において、パケット損失値が閾値以上である場合、この方法はステップ304に進む。ステップ304において、サーバは、ステップ302の分析に基づいて他の送信レートに切り替える。ステップ303においてパケット損失値が閾値より下である場合、この方法はステップ305に進む。サーバは、同じレートでストリーミングビデオを送信し続ける。ステップ304、305の終わりに、この方法はステップ301で初めから繰り返す。
【００４１】
図４は、例示的な実施例によるストリーミングビデオ通信方法のフローチャートである。事実上動的であるこれまでに説明した方法とは異なり、この方法は、予測的である。この方法は、図１と共に検討されたときに最も理解される。この例示的な実施例の詳細をあいまいにすることを回避するため、共通の詳細は一般的には繰り返されない。特に、例示的な実施例の動的な方法と予測的な方法との双方の態様を組み込んだ、ストリーミングビデオを送信する方法及び装置の結合が考えられる。
【００４２】
ステップ401において、メディア配信サーバ108とSTB113との間の１つ以上のパスの帯域容量が推定される。一実施例では、パスでのデータトラヒックの潜在的な輻輳の静的な全体マップが決定される。他の実施例では、潜在的な輻輳は、パス毎の予想データトラヒック負荷に基づいて計算されてもよい。静的なマップ又は関数は、例示的に受信機（例えばSTB113）の位置とネットワーク情報（IPアドレス及び特定の関数呼び出し結果等）とに基づく。
【００４３】
ステップ402において、推定に基づいて、ビデオストリーム又はビデオストリームのグループの送信レート（ビットレート）が決定されてもよい。特に、推定は、パス毎のデータ送信の容量レベルを提供する。例示的に、サーバ108は、パスの負荷容量に相応した送信レートを選択する。
【００４４】
ステップ403において、ストリーミングビデオは、選択された送信レートで送信される。実施例では、ストリームの系列が、各ビデオストリームの送信時でのサーバ108とSTB113との間のパスの予想トラヒック負荷に基づいて、選択された送信レートで送信される。
【００４５】
この開示を鑑みて、ここに記載の様々な方法及び装置がハードウェア及びソフトウェアで実装され得る点に留意すべきである。更に、様々な方法及びパラメータは一例のみとして含まれており、必ずしも限定の意味で含まれているわけではない。この開示を鑑みて、当業者は、特許請求の範囲内に留まりつつ、自分の技術及びこれらの技術を実施するために必要な装置を決定する際に、この教示を実施することができる。
【図面の簡単な説明】
【００４６】
【図１】例示的な実施例による患者情報システムの簡略ブロック図
【図２】例示的な実施例による方法のフローチャート
【図３】例示的な実施例による方法のフローチャート
【図４】例示的な実施例による方法のフローチャート
【図１】
2009514303.tif 000002
【図２】
2009514303.tif 000003
【図３】
2009514303.tif 000004
【図４】
2009514303.tif 000005