ソフトウェア管理システム
【課題】システム負荷を増大させることなく、複数の医用装置にソフトウェアを円滑に配信する。
【解決手段】ソフトウェア管理システム１は、医用装置３−１〜３−ｎとサーバ２を備える。各医用装置３−１〜３−ｎは、医用ソフトウェア３１０の動作状況を示すログ情報３２０を記録するログ記録部３２を備える。サーバ２は、障害修正用ソフトウェア２１０を格納する情報格納部２１と、各医用装置３−１〜３−ｎのログ情報３２０に基づいて、それら医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序を決定する配信順序決定部２２と、決定された配信順序に基づいて医用装置３−１〜３−ｎに障害修正用ソフトウェア２１０を配信する配信制御部２００とを備える。医用装置３−１〜３−ｎは、サーバ２から配信された障害修正用ソフトウェア２１０により医用ソフトウェア３１０をアップデートする。
【解決手段】ソフトウェア管理システム１は、医用装置３−１〜３−ｎとサーバ２を備える。各医用装置３−１〜３−ｎは、医用ソフトウェア３１０の動作状況を示すログ情報３２０を記録するログ記録部３２を備える。サーバ２は、障害修正用ソフトウェア２１０を格納する情報格納部２１と、各医用装置３−１〜３−ｎのログ情報３２０に基づいて、それら医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序を決定する配信順序決定部２２と、決定された配信順序に基づいて医用装置３−１〜３−ｎに障害修正用ソフトウェア２１０を配信する配信制御部２００とを備える。医用装置３−１〜３−ｎは、サーバ２から配信された障害修正用ソフトウェア２１０により医用ソフトウェア３１０をアップデートする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、医用装置を制御するソフトウェアに発生した障害に対処するためのソフトウェア管理システムに関するもので、特に、ソフトウェアの遠隔アップデート技術に関するものである。
【背景技術】
【０００２】
従来、一般に使用されている基本ソフトウェア（オペレーティングシステム）やアプリケーションソフトウェアに障害が発生した場合、ソフトウェア提供側のサービスエンジニアが、そのソフトウェア自身の動作状況や、障害発生時におけるメモリダンプの情報を参照しつつ障害の原因を特定し、その障害を解決するための修正用ソフトウェアや対処手順をユーザに提供していた（たとえば特許文献１参照）。
【０００３】
また、近年では、修正用ソフトウェア等のアップデート内容を広域ネットワーク上のサーバに格納しておき、そのアップデート内容を目的のクライアントに対して配信する機能、いわゆる遠隔ソフトウェアアップデート機能を有するソフトウェア管理システムが利用されるようになってきている（たとえば特許文献２参照）。
【０００４】
この遠隔ソフトウェアアップデート機能は、たとえば次のように作用する。クライアント（コンピュータ端末等）に電源が投入されると、そのクライアントからサーバに、ソフトウェアのアップデートが必要か否か確認するための信号が送信される。サーバは、この信号に基づいて確認の対象となるアップデート内容が存在するか確認する。アップデート内容が存在する場合、そのアップデート内容をクライアントに送信する。クライアントは、そのアップデート内容を受信して目的のソフトウェアのアップデートを実行する。
【０００５】
このようなシステムを利用することにより、複数のクライアントを一元的に管理できるとともに、修正用ソフトウェアの送信処理も一元化することが可能となる。現在では、広域ネットワーク上の多くのクライアントがこのシステムによってアップデートを行うようになっている。
【０００６】
このような機能を有するシステムを実際に運用する際には、修正用ソフトウェア等のアップデート内容を円滑に配信すること、そして、クライアントにて発生した障害の内容や原因を正確に特定することが重要になってくる。
【０００７】
たとえば、修正用プログラム等のアップデート内容のデータ量が多い場合や、多数のクライアントが同時に起動された場合に、サーバが行うべき処理量が増大して対応できなくなることがあり、また、ネットワーク経由でのデータ送信に時間が掛かってしまうことがある。それにより、サーバに過大な処理負荷が掛かり、また、クライアントの起動時間が長くなるといった問題が発生してしまう。したがって、このような問題を解消するために、アップデート内容のデータ量が多い場合や、多数のクライアントを配信対象とする場合であっても、アップデート内容の配信処理を円滑に行えることが望ましい。
【０００８】
現状では、負荷設計、すなわち、配信するソフトウェアのデータ量の最大サイズをあらかじめ想定し、サーバの台数を増加させて各サーバの処理負荷を軽減させたり、ネットワークの通信データの許容量を増大（ネットワーク負荷を軽減）させたりすることによって、配信処理の円滑化を図っている。
【０００９】
一方、ソフトウェア障害の内容や原因の特定については、それらを特定しない限り、ソフトウェアの適当な部分に適当な対処を施すことができないことを考慮すると、その重要性は当然である。
【００１０】
ところで、近年、各種の医用装置を制御するためのソフトウェアのアップデートについても、上記の遠隔方式で行うようになってきた。そのようなソフトウェア管理システムは、アップデートサービス提供側に設置されたサーバと、医療機関に設置された各種医用装置（クライアント）とを、インターネット等の広域ネットワーク（公衆通信網）で接続した構成を備える。
【００１１】
医用装置を制御するソフトウェアは、もし障害が発生すると、誤診や患者取り違えなどの重大な事態を引き起こす可能性を抱えている。そのため、運用前（出荷前）には、通常のオフィス用ないし個人用のソフトウェアと比較して非常に綿密なソフトウェア試験が行われている。したがって、障害の発生頻度は、他分野のソフトウェアと比べて一般に少ない。しかしながら、運用前の試験を徹底的に行ったとしても、時には想定外の障害が発生することがある。そのため、医用目的のソフトウェアに発生する障害は、非常に複雑なものとなる。
【００１２】
また、医用装置は、他の医用装置や周辺機器に接続されていることが多いため、障害の内容や原因を特定するためには、障害が発生したソフトウェアの情報だけでなく、他の医用装置や周辺機器からの割り込み処理なども解析する必要がある。また、複数のソフトウェアが同時並行的に動作している場合には、障害が発生したソフトウェアに対する他のソフトウェアとの影響についても解析しなければならない。更に、障害発生前の操作手順など、その他の要素も解析する必要がある。このように、医用目的のソフトウェアの障害の内容や原因を特定するには、障害発生前の様々なイベントを総合的に解析し、障害発生時の状況を再現してやらねばならない。
【００１３】
このように、発生する障害自体が複雑であること、更に、他のハードウェアやソフトウェアの影響を考慮する必要があることを勘案すると、医用装置のソフトウェア障害の内容や原因を正確に特定することは非常に困難である。これは、医用分野において遠隔ソフトウェアアップデートを好適に行うための一つの障壁となっている。
【００１４】
一方、多くの病院等の医療機関は、同様の時刻（午前８時〜１０時くらい）に業務を開始するため、医用装置に電源が投入される時刻が、おおよそ午前７〜９時に集中するという現状がある。そうすると、サーバは、この数時間程度の間に多くの医用装置に対応しなければならないことになる。したがって、当該数時間程度における処理負荷を達成できるように、サーバ台数を増やしたり（サーバ容量の冗長化）、ネットワークの通信データの許容量を増大させたり（ネットワーク容量の拡大）する必要がある。しかし、当該数時間程度の間以外の時間には、そのような負荷設計は明らかに過剰であり、全体として高コスト化してしまう。特に、公衆回線の許容量を増大させると、システム維持費に占める通信費の割合が大きくなり、結果として、ユーザが負担する医用装置の保守費が増加してしまう。
【００１５】
また、近年のソフトウェアは、処理実行単位や機能単位毎の複数のソフトウェアモジュールを含んで構成されているのが一般的である。医療分野においても、一つの医用装置に様々な機能を持たせるために、複数のソフトウェアモジュールを含むソフトウェアが広く用いられており、多数の医用装置に共通のソフトウェアモジュールが搭載されていることが多い。
【００１６】
このようなソフトウェアに障害が発生した場合、多数の医用装置の品質管理を均一に行うために、障害が発生したソフトウェアモジュールをアップデートするためのソフトウェアを、各医用装置に配布する必要がある。
【００１７】
一方、共通のソフトウェアモジュールを搭載していても、医用装置の種類や現場での運用形態などによって、そのソフトウェアモジュールを頻繁に利用する医療機関と、ほとんど（全く）利用しない医療機関とが存在する。障害が発生した場合、当該ソフトウェアモジュールをほとんど利用しない医療機関よりも、頻繁に利用する医療機関の方が、障害修復への緊急性が高いと思われる。しかしながら、従来のソフトウェア配信技術では、このような緊急性の違いを考慮して配信スケジュールを組むことができなかった。
【００１８】
【特許文献１】特開平５−１６５６２６号公報
【特許文献２】特開２００４−２６５３０４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１９】
本発明は、このような事情に鑑みて為されたもので、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させることなく、アップデート用のソフトウェアを複数の医用装置に円滑に配信することが可能なソフトウェア管理システムを提供することを目的とする。
【００２０】
また、本発明は、医用装置を制御するソフトウェアに障害が発生したときに、その医用装置を運用する各医療機関における障害修復の緊急性や必要性に応じて、アップデート用のソフトウェアを配信することが可能なソフトウェア管理システムを提供することを他の目的とするものである。
【００２１】
また、本発明は、医用装置を制御するソフトウェアに発生した障害の内容を的確に特定し、適当なアップデート用ソフトウェアを配信することが可能なソフトウェア管理システムを提供することを他の目的とするものである。
【課題を解決するための手段】
【００２２】
上記目的を達成するために、請求項１に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段を備え、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記記録された動作状況情報に基づいて、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２３】
また、請求項７に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、前記ソフトウェアの障害に関連する特定の処理を当該医用装置が実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを、互いに関連付けて記録する記録手段と、前記記録された前記特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして、前記ソフトウェアにおける障害の発生頻度情報を作成する発生頻度情報作成手段と、を備え、前記ソフトウェア配信サーバは、前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記発生頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記発生頻度情報作成手段により作成された発生頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、前記複数の医用装置のそれぞれから受信した前記発生頻度情報に示す前記特定処理識別情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２４】
また、請求項８に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、を備え、前記ソフトウェア配信サーバは、前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、前記複数の医用装置のそれぞれから受信した前記使用頻度情報に示す前記使用日時情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２５】
また、請求項９に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、を備え、前記ソフトウェア配信サーバは、前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、前記複数の医用装置のそれぞれから受信した前記使用頻度情報に示す前記使用時間の値を比較し、前記複数の医用装置のそれぞれに対して、前記使用時間の値の大きい医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２６】
また、請求項１２に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段と、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれについて前記記録された動作状況情報に基づいて、前記２以上の医用装置のそれぞれの前記ソフトウェアにおける障害の発生頻度を示す発生頻度情報を作成する発生頻度情報作成手段と、を備え、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記作成された前記２以上の医用装置のそれぞれの発生頻度情報に基づいて、前記複数の医用装置における前記障害の発生頻度の分布を推定する演算手段と、前記推定された前記障害の発生頻度の分布に基づいて、該分布における前記発生頻度のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、前記決定された送信開始日時に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、当該医用装置は、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２７】
また、請求項１４に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段と、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれについて前記記録された動作状況情報に基づいて、前記２以上の医用装置のそれぞれにおける前記ソフトウェアの使用頻度を示す使用頻度情報を作成する使用頻度情報作成手段と、を備え、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記作成された前記２以上の医用装置のそれぞれの使用頻度情報に基づいて、前記複数の医用装置における前記ソフトウェアの使用頻度の分布を推定する演算手段と、前記推定された前記使用頻度の分布に基づいて、該分布における前記使用頻度のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、前記決定された送信開始日時に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、当該医用装置は、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２８】
また、請求項１７に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、当該医用装置が前記ソフトウェアの障害に関連する特定の処理を実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを互いに関連付けて記録する記録手段と、前記記録された特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして、当該医用装置における前記障害の発生頻度情報を作成する発生頻度情報作成手段と、を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記発生頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記発生頻度情報作成手段により作成された発生頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、前記受信した前記発生頻度情報に基づいて、前記２以上の医用装置における前記特定処理識別情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記特定処理識別情報の個数の分布を推定する演算手段と、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記特定処理識別情報の個数の分布とに基づいて、該分布における前記特定処置識別情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された特定処理識別情報と特定処理日時情報とに基づいて前記発生頻度作成手段により作成される発生頻度情報に示す特定処理識別情報の個数の値を取得し、現在日時が、該取得された個数の値に対応する送信開始日時以降であるか判断する日時判断手段と、前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、を備え、当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２９】
また、請求項１８に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、前記受信した前記使用頻度情報に基づいて、前記２以上の医用装置における前記使用日時情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用日時情報の個数の分布を推定する演算手段と、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用日時情報の個数の分布とに基づいて、該分布における前記使用日時情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された使用日時情報に基づいて前記使用頻度作成手段により作成される使用頻度情報に示す使用日時情報の個数の値を取得し、現在日時が、該取得された個数の値に対応する送信開始日時以降であるか判断する日時判断手段と、前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、を備え、当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００３０】
また、請求項１９に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、前記受信した前記使用頻度情報に基づいて、前記２以上の医用装置における前記使用時間の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用時間の分布を推定する演算手段と、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用時間の分布とに基づいて、該分布における前記使用時間のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された使用日時情報に基づいて前記使用頻度作成手段により作成される使用頻度情報に示す使用時間の値を取得し、現在日時が、該取得された使用時間の値に対応する送信開始日時以降であるか判断する日時判断手段と、前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、を備え、当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００３１】
また、請求項２０に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、前記ソフトウェアの障害に関連する特定の処理が実行される度毎に、該特定の処理を識別する特定処理識別情報を記録する記録手段と、前記ソフトウェアに障害が発生したときに、該障害の発生日時の所定時間前から該発生日時までの間に前記記録された特定処理識別情報を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信する特定処理識別情報送信手段と、を備え、前記ソフトウェア配信サーバは、過去に前記ソフトウェアに発生した障害に関連する特定の処理の特定処理識別情報を含む障害履歴情報と、当該障害を修正するアップデート用ソフトウェアとを、互いに関連付けてあらかじめ格納する格納手段と、前記複数の医用装置のいずれかにより送信された前記特定処理識別情報を受信する受信手段と、前記受信された特定処理識別情報と同一の特定処理識別情報を含む障害履歴情報を前記格納手段から検索する検索手段と、障害履歴情報が前記検索された場合に、該検索された障害履歴情報に関連付けられたアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信する配信制御手段と、を備え、前記複数の医用装置のそれぞれは、前記配信されたアップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【発明の効果】
【００３２】
請求項１に記載のソフトウェア管理システムは、ソフトウェア配信サーバと複数の医用装置とを含んで構成され、各医用装置におけるソフトウェアの動作状況情報を記録するとともに、ソフトウェア配信サーバが、記録された動作状況情報に基づいて複数の医用装置に対するアップデート用ソフトウェアの配信順序を決定し、その決定された配信順序に基づいて複数の医用装置にアップデート用ソフトウェアを配信するように動作する。そして、各医用装置は、配信されたアップデート用ソフトウェアによってソフトウェアのアップデートを行うようになっている。
【００３３】
このようなソフトウェア管理システムによれば、複数の医用装置に対して無作為にアップデート用ソフトウェアの配信を行っていた従来の構成とは異なり、各医用装置の動作状況（たとえば障害の発生頻度やソフトウェアの使用頻度など）に応じて配信順序を決定することができるので、アップデートの緊急性や必要性の高い医用装置に対して優先的にアップデート用ソフトウェアを送信することができる。また、このような配信処理を実行することにより、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させることなく、円滑な配信処理を実現することができる。
【００３４】
請求項１２に記載のソフトウェア管理システムは、ソフトウェア配信サーバと複数の医用装置とを含んで構成され、各医用装置におけるソフトウェアの動作状況情報を記録するとともに、複数の医用装置の一部からなる２以上の医用装置の動作状況情報に基づいて、それら２以上の医用装置におけるソフトウェアにおける障害の発生頻度を示す発生頻度情報を作成するようになっている。ソフトウェア配信サーバは、その２以上の医用装置の発生頻度情報に基づいて複数の医用装置全体における障害の発生頻度の分布を推定し、その推定された分布における発生頻度の各値に対してアップデート用ソフトウェアの送信開始日時を決定し、複数の医用装置に対するアップデート用ソフトウェアの配信を行うようになっている。
【００３５】
このようなソフトウェア管理システムによれば、請求項１の発明と同様に、アップデートの緊急性や必要性の高い医用装置に対して優先的にアップデート用ソフトウェアを送信することができ、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させることなく、円滑な配信処理を実現することができる。
【００３６】
更に、このソフトウェア管理システムによれば、一部の医用装置の発生頻度情報を取得するだけで全ての医用装置に対する配信スケジュールを決定するように作用することから、配信スケジュールの決定処理を効率的に行うことができるという特有の効果が奏される。また、長期間に使用されていない医用装置がある場合など、或る医用装置から発生頻度情報を取得できないような場合であっても、配信スケジュールを有効に決定することができるという特有の効果もある。
【００３７】
請求項１４に記載のソフトウェア管理システムは、ソフトウェア配信サーバと複数の医用装置とを含んで構成され、各医用装置におけるソフトウェアの動作状況情報を記録するとともに、複数の医用装置の一部からなる２以上の医用装置の動作状況情報に基づいて、それら２以上の医用装置におけるソフトウェアの使用頻度を示す使用頻度情報を作成するようになっている。ソフトウェア配信サーバは、その２以上の医用装置の使用頻度情報に基づいて複数の医用装置全体におけるソフトウェアの使用頻度の分布を推定し、その推定された分布における使用頻度の各値に対してアップデート用ソフトウェアの送信開始日時を決定し、複数の医用装置に対するアップデート用ソフトウェアの配信を行うようになっている。
【００３８】
このようなソフトウェア管理システムによれば、請求項１２の発明と同様に、アップデートの緊急性や必要性の高い医用装置に対して優先的にアップデート用ソフトウェアを送信することができ、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させることなく、円滑な配信処理を実現することができるとともに、配信スケジュールの決定処理を効率的に行うことができ、或る医用装置から発生頻度情報を取得できないような場合であっても、配信スケジュールを有効に決定することができる。
【００３９】
請求項２０に記載のソフトウェア管理システムは、ソフトウェア配信サーバと複数の医用装置とを含んで構成され、各医用装置は、ソフトウェア障害に関連する特定の処理を識別する特定処理識別情報を記録し、障害の発生日時の所定時間前から発生日時までの間に記録された特定処理識別情報をソフトウェア配信サーバに送信するように作用する。ソフトウェア配信サーバは、過去のソフトウェア障害に対応する特定処理識別情報を含む障害履歴情報と、その障害を修正するアップデート用ソフトウェアとを互いに関連付けてあらかじめ格納している。そして、複数の医用装置のいずれかから特定処理識別情報を受信すると、その受信した特定処理識別情報と同一の特定処理識別情報を含む障害履歴情報を検索し、その検索された障害履歴情報に関連付けられたアップデート用ソフトウェアを各医用装置に配信するように作用する。
【００４０】
このようなソフトウェア管理システムによれば、医用装置のソフトウェアに発生した障害の内容を特定処理識別情報を用いて的確に特定することができるとともに、適当なアップデート用ソフトウェアを医用装置に送信して障害を効果的に修正することが可能である。
【発明を実施するための最良の形態】
【００４１】
本発明に係るソフトウェア管理システムの好適な実施の形態の一例について、図面を参照しながら詳細に説明する。以下、本発明に係るソフトウェア管理システムについて、３つの実施形態を説明する。
【００４２】
第１、２の実施形態のソフトウェア管理システムは、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させることなく、複数の医用装置に対するアップデート用ソフトウェアの配信の円滑化を図るものであり、アップデートの緊急性や必要性の高い医用装置に対して優先的にアップデート用ソフトウェアを送信することを可能とするものである。
【００４３】
一方、第３の実施形態のソフトウェア管理システムは、或る医用装置にソフトウェア障害が発生したときに、その障害の内容を的確に特定することにより、複数の医用装置に対して適当なアップデート用ソフトウェアを配信するものである。
【００４４】
なお、本発明において「ソフトウェア」とは、医用装置を制御するソフトウェア全体を表すこともあるし、また、当該ソフトウェアの一部を構成するソフトウェアモジュールを表すこともある。したがって、アップデート用ソフトウェアは、ソフトウェア全体をアップデートするものであってもよいし、その一部のソフトウェアモジュールのみをアップデートするものであってもよい。
【００４５】
〈第１の実施形態〉
図１〜図９を参照しつつ、本発明に係るソフトウェア管理システムの第１の実施形態を説明する。図１は、本システムの全体構成の一例を表すブロック図である。図２は、医用装置を制御するソフトウェアの構成の一例を表す概略図である。図３〜図５は、医用装置が記録するログ情報（動作状況情報）の一例を表す図である。図６は、このログ情報を記録する処理の一例を表すフローチャートである。図７は、ソフトウェア障害の発生頻度に基づく配信スケジュール決定処理の一例を表すフローチャートである。図８は、アップデート用ソフトウェアの配信処理の一例を表すフローチャートである。図９は、ソフトウェアの使用頻度に基づく配信スケジュール決定処理の一例を表すフローチャートである。
【００４６】
［システム構成］
図１に示すソフトウェア管理システム１は、サーバ２と、複数（ｎ台）の医用装置３−１〜３−ｎとを備えている。医用装置３−１〜３−ｎは、それぞれ異なる医療機関（病院、診療所、大学、研究所等）に設置されている。各医用装置３−１〜３−ｎは、インターネット等の広域ネットワークＮを通じて、サーバ２とデータ通信可能に設置されている。
【００４７】
図１のソフトウェア管理システム１には、サーバ２が１台しか設けられていないが、実際は、１台以上の任意の台数を設置することが可能である。
【００４８】
医用装置３−１〜３−ｎは、それぞれ同様の構成を具備している。以下、医用装置３−１（３）についてのみ詳細を説明し、他の医用装置３−２〜３−ｎについては、医用装置３に準ずるものとする。
【００４９】
［医用装置の構成］
医用装置３は、医療分野において用いられる任意の装置であって、所定のソフトウェアによる制御にしたがって動作するように構成されている。この医用装置３の具体例としては、電子カルテ管理システム、医用画像管理システム、医事会計管理システム、医用画像診断装置（Ｘ線診断装置、Ｘ線ＣＴ装置、ＭＲＩ装置等）、検像システム、読影システムなどがある。
【００５０】
医用装置３には、所定の外部装置４が接続されている。例えばＲＩＳ（Ｒａｄｉｏｌｏｇｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ：放射線科情報システム）等の医用画像管理システムを医用装置３として用いる場合、この医用画像管理システムに撮影画像を提供する医用画像診断装置などが外部装置４として設置される（逆の場合もある。）。また、医師が診察室等で使用するコンピュータなども外部装置４の一例である。なお、医用装置３に接続された外部装置４の台数は任意である。
【００５１】
さて、本実施形態の医用装置３は、図１に示すように、制御部３０、ソフトウェア記憶部３１、ログ記録部３２、送信情報作成部３３、ユーザインターフェイス（ユーザＩ／Ｆ）３４及び通信部３５を含んで構成される。
【００５２】
〔制御部〕
制御部３０は、医用装置３の各部の制御や、各種データ処理を実行する。制御部３０は、特に、ソフトウェア記憶部３１に記憶された医用ソフトウェア３１０にしたがって、各種の制御処理やデータ処理を実行する。この制御部３０は、たとえばＣＰＵやＭＰＵ等のマイクロプロセッサとＲＡＭ等のメモリを含んで構成される。なお、制御部３０の動作の詳細については、適宜後述することにする。
【００５３】
〔ソフトウェア記憶部〕
ソフトウェア記憶部３１は、本発明の「ソフトウェア記憶手段」の一例に相当するもので、医用ソフトウェア３１０を初めとする各種のソフトウェア（たとえばオペレーティングシステムや、他のアプリケーションソフトウェア）をあらかじめ記憶している。
【００５４】
医用ソフトウェア３１０は、たとえば、電子カルテ管理ソフトウェア、医用画像管理ソフトウェア、医事会計管理ソフトウェア、医用画像診断ソフトウェア、検像ソフトウェア、読影ソフトウェアなど、医用装置３の用途に応じたソフトウェアである。
【００５５】
このソフトウェア記憶部３１は、たとえばハードディスクドライブ等の不揮発性記憶装置を含んで構成される。なお、当該医療機関内のＬＡＮ等のローカルネットワークに接続されている場合、ローカルサーバ上にソフトウェアを格納しておくようにしてもよい。
【００５６】
医用ソフトウェア３１０は、医用ソフトウェア３１０の処理実行単位毎にあるいは機能単位毎に設けられた複数のソフトウェアモジュールによって構成されている。たとえば、図２に示すように、医用ソフトウェア３１０は、全体制御モジュール３１１、ＡＢＣ＿モジュール３１２、ＤＥＦ＿モジュール３１３、ＧＨＩモジュール３１４、ＪＫＬ＿モジュール３１５、ＭＮＯ＿モジュール３１６及びＰＱＲ＿モジュール３１７を有する。
【００５７】
全体制御モジュール３１１は、各モジュール３１２〜３１７の呼び出し処理や、全体制御モジュール３１１自身若しくは各モジュール３１２〜３１７が実行した処理又はユーザによる操作内容等のログを記録する処理などを行う。各モジュール３１２〜３１７は、それぞれ特有の機能を有しており、必要に応じて全体制御モジュール３１１に呼び出されて特有の処理を実行する。
【００５８】
たとえば、医用装置３がＸ線ＣＴ装置である場合、ＡＢＣ＿モジュール３１２は投影データ収集用ソフトウェアモジュール、ＤＥＦ＿モジュールは前処理用ソフトウェアモジュール、ＧＨＩ＿モジュールは再構成処理用ソフトウェアモジュール、ＪＫＬ＿モジュールは後処理用ソフトウェアモジュール、ＭＮＯ＿モジュールは画像表示制御用ソフトウェアモジュール、ＰＱＲ＿モジュールはガントリ駆動用ソフトウェアモジュール、・・・といった具合に、各モジュール３１１〜３１７は特有の機能を有している。
【００５９】
〔ログ記録部〕
ログ記録部３２は、本発明の「記録手段」の一例に相当するもので、医用ソフトウェア３１の動作状況を示すログ情報３２０（動作状況情報）を記録する。ログ記録部３２は、たとえばハードディスクドライブ等の不揮発性記憶装置を含んで構成される。
【００６０】
制御部３０は、医用ソフトウェア３１０に基づく処理を実行する度毎に、その処理を識別する（その処理の処理内容を示す）処理識別情報や、その処理を実行した日時を示す処理日時情報を、ログ情報３２０としてログ記録部３２に記録する。
【００６１】
また、制御部３０は、医用ソフトウェア３１０が使用される度毎に、その使用日時を示す使用日時情報を、ログ情報３２０としてログ記録部３２に記録する。ここで、使用日時情報を記録するタイミングは、たとえば、医用ソフトウェア３１０が起動されたタイミングや、終了されたタイミングなどとされる。
【００６２】
ここで、処理日時情報や使用日時情報として記録される「日時」は、「年、月、日、時刻」を含むものであってもよいし、「月、日、時刻」のみを含むものであってもよいし、「日、時刻」のみを含むものであってもよいし、「日」のみを含むものであってもよいし、「時刻」のみを含むものであってもよい。ここで、「時刻」は、「時、分、秒」や「時、分」からなる。情報の用途などに応じ、これらの選択肢のうちのいずれかを適宜記録する。なお、この「日時」を示す情報は、一般的なマイクロプロセッサに搭載された計時機能に基づいて取得される。
【００６３】
ログ記録部３２に記録されるログ情報３２０の一例として、図３に示す無応答ログ情報３２１、図４に示す強制終了ログ情報３２２、図５に示すデバッグログ情報３２３について説明する。各ログ情報３２１〜３２３には、ログの種類（無応答ログ、強制終了ログ、デバッグログ）を識別するログ識別情報が付されている。
【００６４】
図３に示す無応答ログ情報３２１には、医用装置３のシステムリセット処理若しくは終了処理（シャットダウン処理）の要求に対して無応答状態になったモジュールのモジュール名（「無応答モジュール名」）と、無応答状態になった日時（「ログ日時」；処理日時情報）とが、互いに関連付けられて記録される。
【００６５】
ユーザが、ユーザインターフェイス３４を操作してシステムリセットやシャットダウンを要求すると、全体制御モジュール３１１は、起動中の全てのソフトウェアモジュール（３１２〜３１７）に対して終了要求を送る。この終了要求に応答したソフトウェアモジュールは、要求に応じて終了される。一方、応答しないソフトウェアモジュールは、終了することができず、一定時間が経過してもそのまま起動されている。無応答ログ情報３１２には、この応答しないソフトウェアモジュールのモジュール名とログ日時が記録される。
【００６６】
図４に示す強制終了ログ情報３２２には、医用ソフトウェア３１０に異常動作が発生したときに強制終了されたモジュールのモジュール名（「強制終了モジュール名」）と、強制終了がなされた日時（「ログ日時」；処理日時情報）とが、互いに関連付けられて記録される。
【００６７】
通常、オペレーティングシステムは、医用ソフトウェアの３１０の動作状況を監視して、想定外のメモリ領域へのアクセスや、大量の要求コマンドやイベントの発生などの異常動作（すなわち障害の発生）を検知し、障害が発生したソフトウェアモジュールを強制的に終了させるようになっている。このようなオペレーティングシステムの機能を利用することにより、強制終了されたソフトウェアモジュールのモジュール名とログ日時とが、強制終了ログ情報３２２に記録される。なお、当該機能を有するソフトウェアモジュールを別途搭載することにより、同様の作用を実現するようにしてもよい。制御部３０は、このようなオペレーティングシステムやソフトウェアモジュールによって、医用ソフトウェア３０１に発生した障害を検知する。
【００６８】
図５に示すデバッグログ情報３２３は、発生した障害の原因を特定するために参照される情報である。このデバッグログ情報３２３には、各モジュール３１１〜３１７が実行した処理の処理内容が時系列で記録される。具体的には、各処理内容の識別コードを示す「デバッグログ」（処理内容情報）、当該処理を実行したモジュールの「モジュール名」、及び、当該処理が実行された日時を示す「ログ日時」（処理日時情報）とが、互いに関連付けられて記録される。
【００６９】
このデバッグログ情報３２３には、特に、医用ソフトウェア３１０が使用される度毎に、医用ソフトウェア３１０が起動、終了されたことを示すデバッグログとともに、起動日時や終了日時など、医用ソフトウェア３１０の使用に関連するログ日時（使用日時情報）が記録されるようになっている。
【００７０】
〔送信情報作成部〕
送信情報作成部３３は、デバッグログ情報３２３に記録されたモジュール３１１〜３１７のデバッグログのうち、所定の期間内に実行された特定の処理のデバッグログ（特定処理識別情報）の個数をカウントする。ここで、「特定の処理」は、医用ソフトウェア３１０の障害に関連する処理であり、「特定処理識別情報」は、この特定の処理を識別するデバッグログ（文字列情報）である。また、この「特定の処理」の「ログ日時」は、「特定処理日時情報」に相当する。
【００７１】
「所定の期間」及び「特定処理識別情報」は、後述のようにサーバ２から医用装置３に入力されるか（後述の確認期間情報及び障害特定情報２１２）、若しくは、少なくとも一方が医用ソフトウェア３１０にあらかじめ含まれている。送信情報作成部３３は、「所定の期間」に関連付けられ、かつ、「特定処理識別情報」に該当するデバッグログを、デバッグログ情報３２３から検索するとともに、検索されたデバッグログの個数をカウントする。このカウント結果は、当該所定の期間内における障害（上記特定の処理に関連する障害）の発生回数を表すもので、本発明の「発生頻度情報」の一例に相当する情報である。
【００７２】
また、送信情報作成部３３は、デバッグログ情報３２３に記録されたログ日時のうち、所定の期間に属する起動日時（又は終了日時）を示すログ日時の個数をカウントする。「所定の期間」は、前述のようにサーバ２から入力される。送信情報作成部３３は、入力された「所定の期間」に該当し、かつ、「起動（又は終了）」を示すデバッグログに関連付けられたログ日時を、デバッグログ情報３２３から検索するとともに、検索されたログ日時の個数をカウントする。このカウント結果は、当該所定の期間における医用ソフトウェア３１０の使用回数を表すもので、本発明の「使用頻度情報」の一例に相当する情報である。
【００７３】
また、送信情報作成部３３は、デバッグログ情報３２３に記録されたログ日時から、所定の期間に属する起動日時を示すログ日時と、終了日時を示すログ日時とをそれぞれ検索するとともに、検索されたログ日時に基づいて当該所定の期間における医用ソフトウェア３１０の使用時間（累積使用時間）を算出する。より具体的には、送信情報作成部３３は、検索されたログ日時に基づいて、医用ソフトウェア３１０の各使用毎の使用時間を算出するとともに、各使用毎の使用時間を合算することにより、当該所定の期間における累積使用時間を算出する。この算出結果は、本発明の「使用頻度情報」の一例に相当する情報である。
【００７４】
以上のように、送信情報作成部３３は、本発明の「発生頻度情報作成手段」及び「使用頻度情報作成手段」の一例として動作するものである。この送信情報作成部３３は、ＣＰＵ等をマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【００７５】
（送信情報作成処理の具体例）
送信情報作成部３３による処理の具体例を説明する。ここでは、発生頻度情報の作成処理について説明する。なお、作成の条件の一例として、次の３条件を用いる：（１）登録されたソフトウェアモジュール識別情報２１１は、「ＤＥＦ＿ＭＯＤＵＬＥ」である；（２）障害特定情報２１２は、無応答ログ情報３２１のログ識別情報と、デバッグログ“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”とを含んでいる；（３）「所定の期間」は３０日である。
【００７６】
送信情報作成部３３は、まず、障害特定情報２１２のログ識別情報に基づき、無応答ログ情報３２１を確認対象として認識するとともに、ソフトウェアモジュール識別情報２１１に基づいて、無応答ログ情報３２１からモジュール名「ＤＥＦ＿ＭＯＤＵＬＥ」を検索する。このとき、現在から３０日前までのログ日時、つまり「所定の期間」に属するログ日時に対応するモジュール名を検索する。検索された場合、そのログ日時を取得する。
【００７７】
一方、検索されない場合は、この医用装置３には、障害修正用ソフトウェア２１０により修正されるべき障害は発生していないと判断する（つまり、発生頻度情報「障害の発生頻度＝０」が作成される）。
【００７８】
たとえば図３に示す無応答ログ情報３２１には、モジュール名「ＤＥＦ＿ＭＯＤＵＬＥ」が記録されており、そのログ日時は「２００５／５／１８ ８：１１」となっている。
【００７９】
次に、障害特定情報２１２のデバッグログ“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”に一致するデバッグログを、デバッグログ情報３２３から検索する。検索されない場合、発生頻度情報「障害の発生頻度＝０」が作成される。
【００８０】
一方、検索された場合には、検索されたデバッグログのログ日時と、無応答ログ情報３２１から検索されたモジュール名のログ日時とを比較する。そして、モジュール名のログ日時よりも以前かつ一定時間以内に属するログ日時のデバッグログを検索する。検索されない場合、発生頻度情報「障害の発生頻度＝０」が作成される。また、検索された場合には、検索されたデバッグログの個数をカウントする。このカウント結果を発生頻度情報とする。なお、上記の「一定時間」は、あらかじめ設定されており、たとえば数分程度とされる。
【００８１】
たとえば図５に示すデバッグログ情報３２３には、“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”に一致するデバッグログが記録されており、そのログ日時は「２００５／５／１８ ８：１０：０３」である。ここで、上記の「一定時間」を２分とすると、無応答ログ情報３２１から検索されたモジュール名「ＤＥＦ＿ＭＯＤＵＬＥ」のログ日時は「２００５／５／１８ ８：１１」であるから、「２００５／５／１８ ８：０９」〜「２００５／５／１８ ８：１１」までの間に属するログ日時のデバッグログを検索する。図５に示す上記ログ日時は「２００５／５／１８ ８：１０：０３」であり、したがって、当該ログ日時のデバッグログ“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”は、カウントに考慮される（つまり、カウントが＋１される）。この要領で、「所定の期間（過去３０日）」以内における、特定の障害の発生頻度が求められ、そのカウント結果を発生頻度情報として使用する。
【００８２】
〔ユーザインターフェイス〕
ユーザインターフェイス３４は、ユーザが医用装置３の操作を行ったり、データの設定入力等を行ったりするための操作手段である。このユーザインターフェイス３４としては、たとえば、マウス、キーボード、トラックボール、ジョイスティック、操作パネル、タブレットなど、医用装置３の形態や用途に応じた任意の操作デバイスを用いることが可能である。
【００８３】
〔通信部〕
通信部３５は、広域ネットワークＮを通じてデータ通信を行うためのモデム等の通信機器と、外部装置４との間でデータ通信を行うためのＬＡＮカード等のネットワークアダプタとを含んで構成される。
【００８４】
［サーバの構成］
次に、サーバ２の構成について詳細に説明する。サーバ２は、本発明の「ソフトウェア配信サーバ」の一例に相当するものであり、制御部２０、情報格納部２１、配信順序決定部２２、送信開始日時決定部２３、日時判断部２４、計時部２５及び通信部２６を含んで構成されている。
【００８５】
〔制御部〕
制御部２０は、サーバ２の各部の制御や、各種データ処理を実行する。制御部２０は、特に、医用ソフトウェア３１０をアップデートするソフトウェア（障害修正用ソフトウェア２１０）を、複数の医用装置３−１〜３−ｎに配信するための処理を実行する。この制御部２０は、たとえばＣＰＵやＭＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【００８６】
制御部２０には、配信制御部２００が設けられている。この配信制御部２００は、本発明の「配信制御手段」の一例に相当するものであり、後述のようにして決定されるアップデート用ソフトウェアの配信順序に基づいて、複数の医用装置３−１〜３−ｎにアップデート用ソフトウェアを配信するように作用する。なお、これ以外の制御部２０の動作の詳細については、適宜後述することにする。
【００８７】
〔情報格納部〕
情報格納部２１は、本発明の「格納手段」の一例に相当しアップデート用ソフトウェア及びその配信処理に用いられる各種の情報を格納する。この情報格納部２１は、たとえばハードディスクドライブ等の不揮発性記憶装置を含んで構成される。
【００８８】
情報格納部２１には、障害修正用ソフトウェア２１０、ソフトウェアモジュール識別情報（ＩＤ）２１１、障害特定情報２１２、配信先リスト情報２１３が、あらかじめ格納されている。ソフトウェアモジュール識別情報２１１、障害特定情報２１２及び配信先リスト情報２１３は、それぞれ、障害修正用ソフトウェア２１０毎に生成され、その障害修正用ソフトウェア２１０に関連付けられて情報格納部２１に格納される。
【００８９】
障害修正用ソフトウェア２１０は、ソフトウェア開発者等が、医用ソフトウェア３１０に発生した障害を修正するために（若しくは、発生のおそれのある障害に対処するために）作成したソフトウェアであり、本発明の「アップデート用ソフトウェア」に相当するものである。なお、「修正」とは、障害修正用ソフトウェア２１０を用いて医用ソフトウェア３１０の全部又は一部を変更し又は入れ替えることにより、医用ソフトウェア３１０に存在していたバグやモジュール間の連係などの不都合を解消することを意味するものとする。
【００９０】
ソフトウェアモジュール識別情報２１１は、医用ソフトウェア３１０のソフトウェアモジュール３１１〜３１７（図２参照）のうち、障害修正用ソフトウェア２１０による修正対象となるものを識別する情報である。各ソフトウェアモジュール３１１〜３１７のソフトウェアモジュール識別情報２１１は、たとえば、図３〜図５に示す「モジュール名」を形成する文字列によって構成される。具体的には、たとえばＡＢＣ＿モジュール３１２のソフトウェアモジュール識別情報２１１としては、文字列「ＡＢＣ＿ＭＯＤＵＬＥ」を用いることができる。
【００９１】
障害特定情報２１２は、障害修正用ソフトウェア２１０の修正対象となる障害の種類を特定するための情報であり、また、医用ソフトウェア３１０に発生した障害の種類の特定にも使用可能な情報である。この障害特定情報２１２は、たとえば、図３〜図５のログ情報３２１〜３２３のログ識別情報（前述）と、図５のデバッグログ情報３２３における「デバッグログ」を形成する文字列（特定処理識別情報）とを含んでいる。
【００９２】
障害修正用ソフトウェア２１０の用途、すなわち、障害修正用ソフトウェア２１０により修正される障害は、ソフトウェアモジュール識別情報２１１と障害特定情報２１２とを組み合わせることにより、次のようにして特定される。
【００９３】
障害修正用ソフトウェア２１０の用途が、たとえば「“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”という情報を出力したことを原因とするＤＥＦ＿モジュール３１３の無応答状態を修正する」ことである場合、ソフトウェアモジュール識別情報２１１にはＤＥＦ＿モジュール３１３の識別情報「ＤＥＦ＿ＭＯＤＵＬＥ」が含まれる。また、障害特定情報２１２には、無応答ログ情報３２１のログ識別情報と、デバッグログ“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”とが含まれる。
【００９４】
配信先リスト情報２１３は、障害修正用ソフトウェア２１０を配信する医用装置を特定する情報として、たとえば、医用装置３−１〜３−ｎのうち配信対象に指定された医用装置の装置種別（モダリティ名、システム名、装置／システムのモデル名、ソフトウェアバージョン名）や、広域ネットワークＮにおける当該医用装置のネットワークアドレス（ＩＰアドレス等）などを含む情報である。なお、配信先リスト情報２１３により特定される配信先は、医用装置３−１〜３−ｎの全てであってもよいし、一部のみであってもよい。
【００９５】
更に、情報格納部２１には、配信順序情報２１４と送信開始日時情報２１５が格納される。配信順序情報２１４は、配信順序決定部２２により生成されて情報格納部２１に格納される。また、送信開始日時情報２１５は、送信開始日時決定部２３により生成されて情報格納部２１に格納される（それぞれ詳細は後述する）。
【００９６】
情報格納部２１には、一般に、複数の障害修正用ソフトウェア２１０が格納されている。また、これら複数の障害修正用ソフトウェア２１０のそれぞれに関連付けられたソフトウェアモジュール識別情報２１１、障害特定情報２１２及び配信先リスト情報２１３が格納されている。更に、配信スケジュールの決定後には、これら複数の障害修正用ソフトウェア２１０のそれぞれに関連付けられた配信順序情報２１４と送信開始日時情報２１５とが格納される。
【００９７】
〔配信順序決定部〕
配信順序決定部２２は、本発明の「配信スケジュール決定手段」に含まれるものであり、複数の医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序を決定するように動作する。決定された配信順序は、制御部２０により配信順序情報２１４として情報格納部２１に格納されるとともに、送信開始日時決定部２３に送られる。配信順序決定部２２は、たとえばＣＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。この配信順序決定部２２の具体的な動作内容については後述する（図７に基づく説明を参照）。
【００９８】
〔送信開始日時決定部〕
送信開始日時決定部２３は、本発明の「配信スケジュール決定手段」に含まれる「送信開始日時決定手段」の一例に相当し、配信先リスト情報２１３により配信先に指定されている複数の医用装置３−１〜３−ｎ（の一部）のそれぞれについて、障害修正用ソフトウェア２１０の送信開始日時を決定する。決定された送信開始日時は、制御部２０により、送信開始日時情報２１５として情報格納部２１に格納される。送信開始日時決定部２３は、たとえばＣＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【００９９】
ここで、「送信開始日時」とは、当該医用装置に対する障害修正用ソフトウェア２１０の送信禁止状態が解除される日時を表す。換言すると、送信開始日時とは、送信禁止状態が解除されて障害修正用ソフトウェア２１０が当該医用装置に送信される日時、あるいは、当該医用装置からの送信要求に応じて障害修正用ソフトウェア２１０を送信すること許可される日時を表している。
【０１００】
医用装置３−ｉ（ｉ＝１〜ｎ）に対する送信開始日時は、これら医用装置の装置数（ｎ）と、所定時間内に障害修正用ソフトウェア２１０を送信可能な医用装置の最大数（Ｍ）と、配信順序決定部２２により決定された配信順序とに基づいて決定される。
【０１０１】
この送信開始日時の決定処理を具体的に説明する。情報格納部２１には、サーバ２による最大送信能力を示す配信可能装置数情報が、あらかじめ格納されている（図示省略）。この配信可能装置数情報は、サーバ２が、広域ネットワークＮを通じて、所定時間内に障害修正用ソフトウェア２１０を送信することができる医用装置の装置数が記録されている。たとえば、サーバ２が１日（所定時間）に送信可能な装置数が１００装置である場合（Ｍ＝１００／日）、「配信可能装置数情報＝１００（装置／日）」が情報格納部２１に格納されている。なお、この数値は、サーバ２の情報処理能力や他の処理の処理負荷、更に広域ネットワークＮの通信データの許容量などに基づいて、計算や実測を行うことにより、あらかじめ決定される。
【０１０２】
配信先リスト情報２１３に記録された配信先の装置数が１０００装置であるとする（説明を簡略化するため、全装置数ｎ＝１０００とする）。その場合、これら１０００の医用装置３−１〜３−１０００に対して、１日１００装置ずつ、合計１０日に亘って配信を行うようにスケジュールが組まれる。
【０１０３】
一方、配信順序決定部２２により決定される配信順序は、これら１０００装置に対する配信順序を表すものである。ここでは、説明を簡略化するため、医用装置３−１、３−２、３−３、・・・、３−９９９、３−１０００に対して、当該順序で配信するものとする。
【０１０４】
送信開始日時決定部２３は、まず、配信可能装置数情報（＝１００装置／日）と、配信先の全装置数（＝１０００装置）とに基づいて、全装置への配信に必要な日数を算出する（１０００÷１００＝１０日）。なお、算出結果が整数にならない場合（つまり割り切れない場合）には、商の値の整数部分に相当する日数に、剰余部分を送信するための１日を追加するなどして、配信に要する日数を算出する。
【０１０５】
次に、送信開始日時決定部２３は、算出された配信日数にしたがって、各医用装置３−１〜３−１０００の配信開始日時を決定する。上記の例では、医用装置３−１〜３−１００の配信開始日時は、配信第１日目（の例えば午前０時）、医用装置３−１０１〜３−２００の配信開始日時は、配信第２日目（の例えば午前０時）、・・・、医用装置３−９０１〜３−１０００の配信開始日時は、配信第１０日目（の例えば午前０時）、となる。
【０１０６】
なお、配信日時を決定するためには決定時の日時が必要であるが、その情報は、たとえば後述の計時部２５から取得することができる。また、現在日時あるいは配信第１目の日付をユーザが手動設定するようにしてもよい。
【０１０７】
〔日時判断部〕
日時判断部２４は、サーバ２が医用装置から障害修正用ソフトウェア２１０の送信要求を受信したときに動作し、現在日時が、当該医用装置の送信開始日時以降であるか否か判断する。この日時判断部２４は、本発明の「日時判断手段」の一例に相当し、たとえばＣＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【０１０８】
或る医用装置から障害修正用ソフトウェア２１０の送信要求が入力されると、制御部２０は、情報格納部２１に格納された送信開始日時情報２１５から、当該医用装置の送信開始日時を検索し、日時判断部２４に送る。
【０１０９】
日時判断部２４は、まず、後述の計時部２５を参照して現在日時を取得する。次に、日時判断部２４は、現在日時と当該医用装置の送信開始日時とを比較し、現在日時が、当該医用装置の送信開始日時以降であるか否か判断する。そして、その判断結果を制御部２０に送る。
【０１１０】
〔計時部〕
計時部２５は、計時機能を有する一般的なマイクロプロセッサを含んで構成される。
【０１１１】
〔通信部〕
通信部２６は、広域ネットワークＮを通じてデータ通信を行うためのモデム等の通信機器を備えている。
【０１１２】
［システムの動作態様］
このような構成を備えるソフトウェア管理システム１の動作態様の一例について説明する。以下、ソフトウェア管理システム１の各種の動作形態を説明する。
【０１１３】
〔医用ソフトウェアの動作状況の記録処理：図６〕
まず、医用装置３による医用ソフトウェア３１０の動作状況の記録処理について、図６のフローチャートを参照しつつ説明する。
【０１１４】
まず、医用装置３の電源投入や、ユーザからの起動要求に対応して医用ソフトウェア３１０が起動されると（Ｓ１）、制御部３０が、起動されたことを示すデバッグログと、そのログ日時（起動日時）と、起動されたモジュール名とを、デバッグログ情報３２３に記録する（Ｓ２）。
【０１１５】
医用ソフトウェア３１０が各種処理を実行する度毎に、制御部３０は、当該処理に対応するログ日時、モジュール名及びデバッグログをデバッグログ情報３２３に記録する（Ｓ３）。この処理は、医用ソフトウェア３１０の使用が終了されるまで逐次行われる。
【０１１６】
医用装置３の電源が切られたり、ユーザからの終了要求が入力されたりして、医用ソフトウェア３１０の使用の終了が要求されると（Ｓ４；Ｙ）、制御部３０は、使用終了を示すデバッグログと、その日時（終了日時）と、終了されたモジュール名とを、デバッグログ情報３２３に記録する（Ｓ５）。この場合における医用ソフトウェア３１０の動作状況の記録処理は、これで終了となる。
【０１１７】
一方、医用ソフトウェア３１０の使用中に（Ｓ４；Ｎ）、障害が発生すると、制御部３０がこれを検知する（Ｓ６）。障害が発生した医用ソフトウェア３１０は、無応答状態に陥るか、或いは、ユーザや全体制御モジュール３１１やオペレーティングシステムによって強制終了される（Ｓ７）。
【０１１８】
医用ソフトウェア３１０が無応答状態になった場合（Ｓ７；無応答）、制御部３０は、無応答状態になった日時を示すログ日時と、無応答状態になったモジュール名とを、無応答ログ情報３２１に記録し（Ｓ８）、処理を終了する。
【０１１９】
一方、医用ソフトウェア３１０が強制終了された場合（Ｓ７；強制終了）、制御部３０は、強制終了された日時を示すログ日時と、強制終了されたモジュール名とを、強制終了ログ情報３２２に記録し（Ｓ９）、処理を終了する。
【０１２０】
〔障害修正用ソフトウェアの配信スケジュール決定処理（障害発生頻度）：図７〕
次に、医用ソフトウェア３１０の障害発生頻度に基づいて障害修正用ソフトウェア２１０の配信スケジュールを決定する処理について、図７のフローチャートを参照しつつ説明する。
【０１２１】
準備段階として、ソフトウェア開発者等が、新たに開発した障害修正用ソフトウェア２１０と、そのソフトウェアモジュール識別情報２１１と、障害特定情報３１２と、配信先リスト情報２１３とを、サーバ２の情報格納部２１に格納し、登録する（Ｓ１１）。その登録方法としては、メディアに記憶されたこれらの情報２１０〜２１３を、サーバ２のドライブ装置（図示せず）に挿入して読み取らせる方法や、ソフトウェア開発者の端末装置（図示せず）からサーバ２にＬＡＮ等を経由してアップロードさせる方法などの、任意の方法を適宜に用いることができる。
【０１２２】
制御部２０は、医用ソフトウェア３１０の障害発生頻度の確認を要求する要求信号と、障害特定情報２１２と、確認期間情報（図示せず）を通信部２６に送り、広域ネットワークＮを通じて、全ての医用装置３−１〜３−ｎにそれぞれ送信する（Ｓ１２）。
【０１２３】
なお、確認期間情報は、発生頻度情報や使用頻度情報や使用頻度情報を作成するときに、ログ情報３２０に記録されたログのうち、どの期間に記録されたログを確認するかを指定する情報である。この期間は、本発明の「所定の期間」に相当し、あらかじめ設定されたものである。なお、この期間を適宜に変更することも可能である。
【０１２４】
医用装置３−１〜３−ｎのそれぞれは、サーバ２からの要求信号に対応して送信情報作成部３３を動作させ、障害特定情報２１２と確認期間情報とに基づいて、障害の発生頻度情報を作成させるとともに、作成された発生頻度情報をサーバ２に送信する（Ｓ１３）。
【０１２５】
各医用装置３−１〜３−ｎからの発生頻度情報を受信すると、サーバ２の配信順序決定部２２は、これら発生頻度情報に基づいて、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序を決定する（Ｓ１４）。
【０１２６】
具体的には、配信順序決定部２２は、医用装置３−１〜３−ｎの発生頻度情報に示す特定処理識別情報の個数を比較し、個数の多い順に医用装置３−１〜３−ｎのそれぞれに順位を指定する。このとき、個数が同じ医用装置には、適宜に順位を指定することができる。この順位が、障害修正用ソフトウェア２１０を送信する順位となる。それにより、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序が決定される。決定された配信順序は、送信開始日時決定部２３に送られる。
【０１２７】
送信開始日時決定部２３は、決定された配信順序に基づき、前述の要領で、各医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の送信開始日時を決定する（Ｓ１５）。
【０１２８】
制御部２０は、ステップＳ１４で決定された配信順序を、配信順序情報２１４として情報格納部２１に格納するとともに、ステップＳ１５で決定された送信開始日時を、送信開始日時情報２１５として情報格納部２１に格納する（Ｓ１６）。このとき、配信順序情報２１４と送信開始日時情報２１５は、それぞれ、障害修正用ソフトウェア２１０に関連付けられて格納される。以上で、医用ソフトウェア３１０の障害発生頻度に基づく障害修正用ソフトウェア２１０の配信スケジュール決定処理は終了となる。
【０１２９】
〔修正用ソフトウェアの配信処理：図８〕
次に、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信処理について、図８のフローチャートを参照しつつ説明する。
【０１３０】
医用装置３は、医用ソフトウェア３１０をアップデートするソフトウェアの有無を確認し、それが有る場合にはその送信を要求する信号（送信要求信号）を、所定のタイミングでサーバ２に送信する（Ｓ２１）。このとき、送信要求信号とともに、医用装置３を識別する装置識別情報が送信される。なお、「所定のタイミング」とは、たとえば医用装置３の起動時やシャットダウン時、或いは、あらかじめ設定された時刻などとされる。
【０１３１】
サーバ２の制御部２０は、送信要求信号情報格納部２１に格納された各配信先リスト情報２１３を参照し、医用装置３が送信先に含まれているか判定することにより、アップデート用ソフトウェア（障害修正用ソフトウェア）の有無を確認する（Ｓ２２）。
【０１３２】
医用装置３に対するアップデート用ソフトウェアが無い場合には（Ｓ２３；Ｎ）、処理を終了する。このとき、アップデート用ソフトウェアが無い旨を示す信号を医用装置３に送信するようにしてもよい。
【０１３３】
一方、医用装置３に対するアップデート用ソフトウェアが有る場合（Ｓ２３；Ｙ）、制御部２０により、送信開始日時情報２１５から医用装置３の送信開始日時が選択されて日時判断部２４に送られるとともに（Ｓ２４）、計時部２５から日時判断部２４に現在日時が送られる。日時判断部２４は、この現在日時と医用装置３の送信開始日時とを比較し、現在日時が送信開始日時以降であるか否か、つまり送信開始日時を経過しか否かを判断する（Ｓ２５）。
【０１３４】
送信開始日時を経過していないと判断された場合には（Ｓ２６；Ｎ）、処理を終了する。このとき、アップデート用ソフトウェアが無い旨を示す信号を医用装置３に送信するようにしてもよい。
【０１３５】
一方、送信開始日時を経過していると判断された場合（Ｓ２６；Ｙ）、制御部２０の配信制御部２００は、情報格納部２１から障害修正用ソフトウェア２１０を読み出して通信部２６に送り、広域ネットワークＮを通じて医用装置３に送信させる（Ｓ２７）。医用装置３は、この障害修正用ソフトウェア２１０をソフトウェア記憶部３１に記憶させ、医用ソフトウェア３１のアップデートを実行する（Ｓ２８）。以上で、障害修正用ソフトウェア２１０の配信処理は終了となる。
【０１３６】
〔障害修正用ソフトウェアの配信スケジュール決定処理（使用頻度）：図９〕
次に、医用ソフトウェア３１０の使用頻度に基づいて障害修正用ソフトウェア２１０の配信スケジュールを決定する処理について、図９のフローチャートを参照しつつ説明する。この処理において使用頻度情報の作成に用いられる情報（使用日時情報）は、たとえば、図６のフローチャートに示す動作状況記録処理により記録された、医用ソフトウェア３１０の起動のログ情報（ステップＳ２）若しくは終了のログ情報（ステップＳ５、Ｓ９）である。以下、起動のログ情報に基づいて使用頻度情報を作成する場合を説明することにする。
【０１３７】
まず、障害発生頻度の場合（図７）と同様に、新たに開発した障害修正用ソフトウェア２１０と、そのソフトウェアモジュール識別情報２１１と、障害特定情報３１２と、配信先リスト情報２１３とが登録されると（Ｓ３１）、サーバ２から各医用装置３−１〜３−ｎに対し、医用ソフトウェア３１０の使用頻度の確認を要求する要求信号と、確認期間情報（図示せず）とが送信される（Ｓ３２）。
【０１３８】
各医用装置３−１〜３−ｎは、サーバ２からの要求信号に対応して送信情報作成部３３を動作させる。送信情報作成部３３は、デバッグログ情報３２３に記録されたログ日時のうち、確認期間情報に示す所定の期間に属する起動日時を示すログ日時（使用日時情報）を検索するとともに、検索されたログ日時の個数をカウントして、医用ソフトウェア３１０の使用頻度情報を作成する。各医用装置３−１〜３−ｎは、作成された使用頻度情報をサーバ２に送信する（Ｓ３３）。
【０１３９】
各医用装置３−１〜３−ｎからの使用頻度情報を受信すると、サーバ２の配信順序決定部２２は、これら使用頻度情報に基づいて、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序を決定する（Ｓ３４）。
【０１４０】
具体的には、配信順序決定部２２は、医用装置３−１〜３−ｎの使用頻度情報に示す使用日時情報（起動日時のログ情報）の個数を比較し、個数の多い順に医用装置３−１〜３−ｎのそれぞれに順位を指定する。このとき、個数が同じ医用装置には、適宜に順位を指定することができる。この順位が、障害修正用ソフトウェア２１０を送信する順位となる。それにより、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序が決定される。決定された配信順序は、送信開始日時決定部２３に送られる。
【０１４１】
送信開始日時決定部２３は、決定された配信順序に基づいて、各医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の送信開始日時を決定する（Ｓ３５）。
【０１４２】
制御部２０は、ステップＳ３４で決定された配信順序を、配信順序情報２１４として情報格納部２１に格納するとともに、ステップＳ３５で決定された送信開始日時を、送信開始日時情報２１５として情報格納部２１に格納する（Ｓ３６）。このとき、配信順序情報２１４と送信開始日時情報２１５は、それぞれ、障害修正用ソフトウェア２１０に関連付けられて格納される。以上で、医用ソフトウェア３１０の使用頻度に基づく障害修正用ソフトウェア２１０の配信スケジュール決定処理は終了となる。
【０１４３】
このように決定された配信スケジュールに基づく障害修正用ソフトウェア２１０の配信処理は、前述した図８の場合と同様にして実行される。
【０１４４】
なお、所定の期間における医用ソフトウェア３１０の累積使用時間に基づいて使用頻度情報を作成する場合については、次のような処理を実行する。まず、新たに開発した障害修正用ソフトウェア２１０等の登録（Ｓ３１）と、サーバ２から各医用装置３−１〜３−ｎへの要求信号及び確認期間情報の送信（Ｓ３２）とを、同様に行う。
【０１４５】
各医用装置３−１〜３−ｎの送信情報作成部３３は、デバッグログ情報３２３に記録されたログ日時のうち、確認期間情報に示す所定の期間に属する起動日時を示すログ日時と終了日時を示すログ日時（使用日時情報）とを検索し、各使用時における使用時間を算出する。このとき、たとえば、所定の期間に属する起動日時と終了日時を検索し、各起動日時とその次の終了日時との時間間隔を当該使用時の使用時間として算出する。そして、各使用時の使用時間を加算して、所定の期間における（累積）使用時間を算出して使用頻度情報を作成する。各医用装置３−１〜３−ｎは、作成された使用頻度情報をサーバ２に送信する（Ｓ３３）。
【０１４６】
各医用装置３−１〜３−ｎからの使用頻度情報を受信すると、サーバ２の配信順序決定部２２は、医用装置３−１〜３−ｎの使用頻度情報に示す（累積）使用時間の値を比較し、その値の大きい順に医用装置３−１〜３−ｎのそれぞれに順位を指定する。このとき、使用時間の値が同じ医用装置には、適宜に順位を指定することができる。この順位が、障害修正用ソフトウェア２１０を送信する順位となる。それにより、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序が決定される（Ｓ３４）。
【０１４７】
送信開始日時決定部２３は、決定された配信順序に基づいて、各医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の送信開始日時を決定する（Ｓ３５）。制御部２０は、ステップＳ３４で決定された配信順序を、配信順序情報２１４として情報格納部２１に格納するとともに、ステップＳ３５で決定された送信開始日時を、送信開始日時情報２１５として情報格納部２１に格納する（Ｓ３６）。以上で、医用ソフトウェア３１０の使用頻度に基づく障害修正用ソフトウェア２１０の配信スケジュール決定処理は終了となる。
【０１４８】
［作用効果］
以上のような本実施形態に係るソフトウェア管理システム１の作用及び効果について説明する。
【０１４９】
ソフトウェア管理システム１の各医用装置３−１〜３−ｎは、医用ソフトウェア３１０の動作状況を示すログ情報３２０を記録している。ここで、ログ情報３２０は、障害の発生頻度や医用ソフトウェア３１０の使用頻度を得るための基になる情報である。一方、サーバ２は、アップデート用の障害修正用ソフトウェア２１０を情報格納部２１にあらかじめ格納している。サーバ２は、配信順序決定部２２により、ログ情報３２０に基づいて医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序を決定し、その配信順序に基づいて医用装置３−１〜３−ｎにアップデート用ソフトウェアを配信する。各医用装置３−１〜３−ｎは、配信された障害修正用ソフトウェア２１０により医用ソフトウェア３１０のアップデートを行う。
【０１５０】
このように、本実施形態によれば、ログ情報３２０に基づく障害発生頻度やソフトウェア使用頻度に基づいて、アップデートの緊急性や必要性の高い医用装置に対して優先的に障害修正用ソフトウェア２１０を送信できる。したがって、従来のように複数の医用装置に対して無作為に配信を行うことがないため、配信処理の円滑化を図ることができるとともに、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を無駄に増大させる必要もない。
【０１５１】
また、各医用装置３−１〜３−ｎには、記録されたログ情報３２０に基づいて、医用ソフトウェア３１０における障害の発生頻度を示す発生頻度情報を作成する送信情報作成部３３が設けられており、サーバ２の配信順序決定部２２は、医用装置３−１〜３−ｎに対して、発生頻度情報に示す障害の発生頻度の高いものから順に送信順位を指定するようになっている。したがって、医用ソフトウェア３１０の障害の発生頻度が高く、アップデートの緊急性の高い医用装置に対して優先的に障害修正用ソフトウェア２１０を送信することができる。
【０１５２】
また、各医用装置３−１〜３−ｎの送信情報作成部３３は、記録されたログ情報３２０に基づいて、医用ソフトウェア３１０の使用頻度を示す使用頻度情報を作成することができ、サーバ２の配信順序決定部２２は、医用装置３−１〜３−ｎに対して、使用頻度情報に示す医用ソフトウェア３１０の使用頻度の高いものから順に送信順位を指定するようになっている。ここで、医用ソフトウェア３１０の使用頻度情報は、所定の期間における医用ソフトウェア３１０の使用回数又は累積使用時間を表す情報である。したがって、医用ソフトウェア３１０の障害の発生頻度が高く、アップデートの必要性の高い医用装置に対して優先的に障害修正用ソフトウェア２１０を送信することができる。
【０１５３】
また、サーバ２は、医用装置３−１〜３−ｎの装置数と、所定時間内に障害修正用ソフトウェア２１０を送信可能な医用装置の最大装置数（配信可能装置数情報）と、配信順序決定部２２が決定した配信順序とに基づいて、各医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の送信開始日時を決定することができる。それにより、配信先の数と、システムの配信能力（配信可能装置数情報）とに基づいて、効率のよい配信スケジュールを作成することができ、配信処理の円滑化を図ることができる。
【０１５４】
また、サーバ２は、修正用ソフトウェア２１０の送信を要求する送信要求信号を或る医用装置から受信したときに、その医用装置の送信開始日時が経過していない限り、その医用装置に障害修正用ソフトウェア２１０を送信しないようになっている。したがって、優先度の高い医用装置から順に、円滑に配信処理を行うことができる。
【０１５５】
［変形例］
本実施形態に係るソフトウェア管理システム１の変形例を説明する。なお、これらの変形例は、以下の実施形態に対して適宜応用することが可能である。
【０１５６】
本実施形態では、医用装置３−１〜３−ｎのそれぞれが個別にログ情報３２０を記録するようになっていたが、これら医用装置３−１〜３−ｎのログ情報３２０をまとめて記録しておくことも可能である。例えば、ログ情報３２０を記録する記録手段（ハードディスクドライブ等）をサーバ２に設けておく。そして、各医用装置３−１〜３−ｎは、処理を行う度毎に（又は定期的／不定期的に）、その処理のログ情報を、広域ネットワークＮ経由でサーバ２に送信して記録手段に記録するように構成することができる。このとき、各医用装置を識別する装置識別情報をログ情報に付加して送信する。
【０１５７】
その場合、ソフトウェア障害の発生頻度を示す発生頻度情報を作成する発生頻度情報作成手段や、ソフトウェアの使用頻度を示す使用頻度情報を作成する使用頻度情報作成手段（本実施形態では、ともに「送信情報作成部３３」）についても、サーバ２に集約することが可能である。
【０１５８】
また、本実施形態では、医用装置３からの要求に応じて障害修正用ソフトウェア２１０を配信するようになっているが、本発明はこれに限定されるものではない。たとえば、各医用装置３−１〜３−ｎに対し、その送信開始日時の到来とともに、障害修正用ソフトウェア２１０を順次配信するように構成することができる。
【０１５９】
〈第２の実施形態〉
図１０〜図１３を参照しつつ、本発明に係るソフトウェア管理システムの第２の実施形態を説明する。図１０は、本システムの全体構成の一例を表すブロック図である。図１１は、ソフトウェア障害の発生頻度に基づく配信スケジュール決定処理の一例を表すフローチャートである。図１２は、アップデート用ソフトウェアの配信処理の一例を表すフローチャートである。図１３は、ソフトウェアの使用頻度に基づく配信スケジュール決定処理の一例を表すフローチャートである。なお、第１の実施形態と同様の構成部分については、説明の重複を避けるため、同じ符号を用いることにする。
【０１６０】
第１の実施形態は、アップデート用ソフトウェアの配信対象となる全ての医用装置３−１〜３−ｎにおける医用ソフトウェアの障害発生頻度や使用頻度に基づいて配信スケジュールを決定するものであった。一方、本実施形態は、配信対象となる医用装置３−１〜３−ｎの一部における障害発生頻度や使用頻度に基づいて配信スケジュールを決定することにより、第１の実施形態と同様の効果とともに、配信スケジュール決定処理の省力化という特有の効果を奏するものである。
【０１６１】
［システム構成］
図１０に示すソフトウェア管理システム１００は、第１の実施形態と同様に、サーバ２と、複数の医用装置３−１〜３−ｎとを備えている。各医用装置３−１〜３−ｎは、広域ネットワークＮを通じて、サーバ２とデータ通信可能に設置されている。また、医用装置３（３−１）には、第１の実施形態と同様の外部装置４が接続されている。
【０１６２】
各医用装置３−１〜３−ｎは、第１の実施形態と同様の構成を有している。サーバ２は、第１の実施形態とほぼ同様であるが、構成上、演算処理部２７を備えている点が異なっている。また、本実施形態の送信開始日時決定部２３は、第１の実施形態とは異なる処理を実行して、送信開始日時情報２１６を作成する。
【０１６３】
〔演算処理部〕
サーバ２の演算処理部２７は、医用装置３−１〜３−ｎのうちの一部の医用装置からの発生頻度情報や使用頻度情報に基づいて、全医用装置３−１〜３−ｎにおける障害発生頻度や使用頻度の分布を推定する処理を行う。この演算処理部２７は、本発明の「演算手段」の一例に相当し、たとえばＣＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【０１６４】
上記の「一部の医用装置」の装置数は少なくとも２以上とされる。これら２以上の医用装置を「医用装置３（１）〜３（ｋ）」と表すことにする。ここで、ｋは、２≦ｋ≦ｎ−１を満たすあらかじめ設定された正の整数であり、たとえばｋはｎの約数（ｋ｜ｎ）とされる。以下、演算処理部２７が実行する処理をより具体的に説明する。
【０１６５】
最初に、医用ソフトウェア３１０の障害発生頻度の分布の推定処理の例を説明する。まず、演算処理部２７は、一部の医用装置３（１）〜３（ｋ）のそれぞれからの発生頻度情報に基づいて、これら医用装置３（１）〜３（ｋ）における特定処理識別情報の個数の分布を求める。すなわち、発生頻度情報は、第１の実施形態において説明したように、所定の期間内における（特定の）障害の発生回数を示す情報であり、具体的には、所定の期間にログ情報３２０に記録された特定処理識別情報の個数を示す情報である。演算処理部２７は、各医用装置３（１）〜３（ｋ）における特定処理識別情報の個数を取得し、それらを個数別に分類するとともに、各個数に対応する装置数を求める。それにより、特定処理識別情報の個数を変数（離散変数）とする、医用装置の装置数の分布（離散分布）が得られる。
【０１６６】
続いて、演算処理部２７は、この特定処理識別情報の個数毎の装置数の分布と、全医用装置３−１〜３−ｎの装置数に対する医用装置３（１）〜３（ｋ）の装置数の比率（ｋ／ｎ）とに基づいて、全医用装置３−１〜３−ｎにおける特定処理識別情報の個数の分布を推定することにより、障害の発生頻度の分布を推定する。すなわち、一部の医用装置３（１）〜３（ｋ）に関する分布における各特定処理識別情報の個数の値を、上記比率で除算することにより、全医用装置３−１〜３−ｎに関する、特定処理識別情報の個数を変数とする医用装置の装置数の分布を求める。以上が、障害発生頻度の分布の推定処理の一例である。
【０１６７】
次に、医用ソフトウェア３１０の使用頻度（使用回数）の分布の推定処理の例を説明する。まず、演算処理部２７は、一部の医用装置３（１）〜３（ｋ）のそれぞれからの使用頻度情報に基づいて、これら医用装置３（１）〜３（ｋ）における使用日時情報の個数の分布を求める。すなわち、使用頻度情報は、第１の実施形態において説明したように、所定の期間内における医用ソフトウェア３１０の使用回数を示す情報であり、具体的には、所定の期間にログ情報３２０に記録された起動処理や終了処理のデバッグログ（使用日時情報）の個数を示す情報である。演算処理部２７は、各医用装置３（１）〜３（ｋ）における使用日時情報の個数を取得し、それらを個数別に分類するとともに、各個数に対応する装置数を求める。それにより、使用日時情報の個数を変数（離散変数）とする、医用装置の装置数の分布（離散分布）が得られる。
【０１６８】
続いて、演算処理部２７は、上記障害発生頻度の場合と同様に、この使用日時情報の個数毎の装置数の分布と、全医用装置３−１〜３−ｎの装置数に対する医用装置３（１）〜３（ｋ）の装置数の比率（ｋ／ｎ）とに基づき、全医用装置３−１〜３−ｎにおける使用日時情報の個数の分布を推定することにより、医用ソフトウェア３１０の使用頻度（使用回数）の分布を推定する。以上が、使用回数に関する使用頻度の分布の推定処理の一例である。
【０１６９】
次に、医用ソフトウェア３１０の使用頻度（使用時間）の分布の推定処理の例を説明する。まず、演算処理部２７は、一部の医用装置３（１）〜３（ｋ）のそれぞれからの使用頻度情報に基づいて、これら医用装置３（１）〜３（ｋ）における使用時間の分布を求める。すなわち、使用頻度情報は、第１の実施形態において説明したように、所定の期間内における医用ソフトウェア３１０の累積使用時間を示す情報である。演算処理部２７は、各医用装置３（１）〜３（ｋ）における使用時間を取得し、それらを使用時間別に分類するとともに、各使用時間に対応する装置数を求める。それにより、使用時間を変数とする、医用装置の装置数の分布が得られる。ここで、変数となる使用時間は、たとえば四捨五入により所定の単位時間毎（１時間単位等）に設定される。
【０１７０】
続いて、演算処理部２７は、上記障害発生頻度の場合と同様に、この使用時間毎の装置数の分布と、全医用装置３−１〜３−ｎの装置数に対する医用装置３（１）〜３（ｋ）の装置数の比率（ｋ／ｎ）とに基づき、全医用装置３−１〜３−ｎにおける使用時間の分布を推定することにより、医用ソフトウェア３１０の使用頻度（使用時間）の分布を推定する。以上が、使用時間に関する使用頻度の分布の推定処理の一例である。
【０１７１】
（分布推定処理の具体例）
ここで、演算処理部２７による上記の分布推定処理の具体例を、障害発生頻度の場合を取り上げて説明する。全医用装置３−１〜３−ｎの装置数をｎ＝１０００とし、一部の医用装置３（１）〜３（ｋ）の装置数をｋ＝１００とする。
【０１７２】
演算処理部２７は、一部の医用装置３（１）〜３（１００）のそれぞれからの発生頻度情報に基づいて、これら医用装置３（１）〜３（１００）における特定処理識別情報の個数の分布を求める。この分布において、特定処理識別情報の個数＝０（障害発生無し）に対応する装置数が０であり、個数＝１〜１０に対応する装置数がそれぞれ１０であったとする。
【０１７３】
演算処理部２７は、この分布における各特定処理識別情報の個数の値を、全医用装置３−１〜３−１０００の装置数に対する医用装置３（１）〜３（１００）の装置数の比率（１００／１０００＝０．１）で除算する。それによると、特定処理識別情報の個数＝０に対応する装置数＝０、個数＝１〜１０のそれぞれに対応する装置数＝１０／０．１＝１００が得られる。これが、全医用装置３−１〜３−１０００に関する分布の推定値である。
【０１７４】
〔送信開始日時決定部〕
送信開始日時決定部２３は、演算処理部２７により推定された障害発生頻度の分布や、医用ソフトウェア３１０の使用頻度の分布に基づいて、その分布における障害発生頻度の各値や使用頻度の各値（つまり、分布における変数の各値）について、障害修正用ソフトウェア２１０の送信開始日時を決定する。決定された送信開始日時は、送信開始日時情報２１６として情報格納部２１に格納される。
【０１７５】
（送信開始日時決定処理の具体例）
送信開始日時決定部２３が実行する処理を、障害発生頻度の場合を取り上げて、より具体的に説明する。情報格納部２１には、第１の実施形態と同様に、サーバ２による最大送信能力を示す配信可能装置数情報が格納されている（たとえば、配信可能装置数情報：Ｍ＝１００（装置／日）とする。）。
【０１７６】
また、全装置数ｎ＝１０００とし、全医用装置３−１〜３−１０００が配信先に設定されているものとする。この場合、これら１０００の医用装置３−１〜３−１０００に対して、１日１００装置ずつ、合計１０日に亘って配信を行うようにスケジュールが組まれる。
【０１７７】
また、演算処理部２７により推定された全医用装置３−１〜３−１０００に関する分布として、上記具体例の分布、すなわち、特定処理識別情報の個数＝０に対応する装置数＝０、個数＝１〜１０のそれぞれに対応する装置数＝１００を用いる。
【０１７８】
送信開始日時決定部２３は、まず、配信可能装置数情報（＝１００装置／日）と、配信先の全装置数（＝１０００装置）とに基づいて、全装置への配信に必要な日数を算出する（１０００÷１００＝１０日）。なお、算出結果が整数にならない場合については、第１の実施形態と同様に取り扱うことができる。
【０１７９】
次に、送信開始日時決定部２３は、算出された配信日数（１０日）を考慮して、推定された分布における各特定処理識別情報の個数について、個数の値の大きいものに早い日時を割り当てるようにして配信開始日時を決定する。本例では、特定処理識別情報の個数＝１０の１００装置の配信開始日時を配信第１日目（の例えば午前０時）に、個数＝９の１００装置の配信開始日時を配信第２日目（の例えば午前０時）に、個数＝８の１００装置の配信開始日時を配信第３日目（の例えば午前０時）に、・・・・、個数＝２の１００装置の配信開始日時を配信第９日目（の例えば午前０時）に、個数＝１の１００装置の配信開始日時を配信第１０日目（の例えば午前０時）に、それぞれ割り当てる。
【０１８０】
このように、本実施形態の送信開始日時情報２１６は、特定処理識別情報の個数（医用ソフトウェア３１０の使用回数、累積使用時間）と、配信（開始）日とを関連付けた情報として形成される。
【０１８１】
［システムの動作態様］
このような構成を備えるソフトウェア管理システム１００の動作態様の一例について説明する。なお、医用ソフトウェア３１０の動作状況の記録処理は、第１の実施形態と同様にして実行される（図６参照）。以下、障害修正用ソフトウェア２１０の配信スケジュールの決定処理、及び、障害修正用ソフトウェア２１０の配信処理について説明する。
【０１８２】
〔障害修正用ソフトウェアの配信スケジュール決定処理（障害発生頻度）：図１１〕
まず、医用ソフトウェア３１０の障害発生頻度に基づいて障害修正用ソフトウェア２１０の配信スケジュールを決定する処理について、図１１のフローチャートを参照しつつ説明する。
【０１８３】
準備段階として、新たに開発した障害修正用ソフトウェア２１０と、そのソフトウェアモジュール識別情報２１１と、障害特定情報３１２と、配信先リスト情報２１３とを、サーバ２の情報格納部２１に格納し、登録する（Ｓ４１）。
【０１８４】
サーバ２は、医用ソフトウェア３１０の障害発生頻度の確認を要求する要求信号と、障害特定情報２１２と、確認期間情報とを、広域ネットワークＮを通じて、一部の医用装置３（１）〜３（ｋ）にそれぞれ送信する（Ｓ４２）。
【０１８５】
医用装置３（１）〜３（ｋ）のそれぞれは、この要求信号に対応して送信情報作成部３３を動作させ、障害特定情報２１２と確認期間情報とに基づいて、障害の発生頻度情報を作成させるとともに、作成された発生頻度情報をサーバ２に送信する（Ｓ４３）。
【０１８６】
各医用装置３（１）〜３（ｋ）からの発生頻度情報を受信すると、サーバ２の演算処理部２７は、これら発生頻度情報に基づき、前述の要領で、全医用装置３−１〜３−ｎにおける障害の発生頻度の分布を推定する（Ｓ４４）。
【０１８７】
送信開始日時決定部２３は、推定された分布に基づき、前述の要領で、この分布における発生頻度のそれぞれの値について、障害修正用ソフトウェア２１０の送信開始日時を決定する（Ｓ４５）。
【０１８８】
制御部２０は、決定された送信開始日時を、送信開始日時情報２１６として情報格納部２１に格納する（Ｓ４６）。このとき、送信開始日時情報２１６は、障害修正用ソフトウェア２１０に関連付けられて格納される。以上で、医用ソフトウェア３１０の障害発生頻度に基づく障害修正用ソフトウェア２１０の配信スケジュール決定処理は終了となる。
【０１８９】
〔修正用ソフトウェアの配信処理：図１２〕
次に、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信処理について、図１２のフローチャートを参照しつつ説明する。
【０１９０】
医用装置３は、所定のタイミングでサーバ２に送信要求信号を送信する（Ｓ５１）。サーバ２の制御部２０は、医用装置３を配信先とするアップデート用ソフトウェアの有無を確認する（Ｓ５２）。
【０１９１】
医用装置３に対するアップデート用ソフトウェアが無い場合には（Ｓ５３；Ｎ）、処理を終了する。このとき、アップデート用ソフトウェアが無い旨を示す信号を医用装置３に送信するようにしてもよい。
【０１９２】
一方、医用装置３に対するアップデート用ソフトウェアが有る場合（Ｓ５３；Ｙ）、サーバ２は、発生頻度情報の作成を要求する要求信号と、障害特定情報２１２と、確認期間情報とを医用装置３に送信する（Ｓ５４）。医用装置３は、要求に対応して送信情報作成部３３を動作させて発生頻度情報を作成させるとともに、作成された発生頻度情報をサーバ２に送信する（Ｓ５５）。
【０１９３】
サーバ２の制御部２０は、医用装置３からの発生頻度情報に示す特定処理識別情報の個数に対応する送信開始日時を、配信開始日時情報２１６から選択して日時判断部２４に送る（Ｓ５６）。このとき、計時部２５から日時判断部２４に現在日時が送られる。日時判断部２４は、この現在日時と送信開始日時とを比較し、現在日時が送信開始日時以降であるか否か、つまり送信開始日時を経過しか否かを判断する（Ｓ５７）。
【０１９４】
送信開始日時を経過していないと判断された場合には（Ｓ５８；Ｎ）、処理を終了する。このとき、アップデート用ソフトウェアが無い旨を示す信号を医用装置３に送信するようにしてもよい。
【０１９５】
一方、送信開始日時を経過していると判断された場合（Ｓ５８；Ｙ）、サーバ２は、情報格納部２１から障害修正用ソフトウェア２１０を読み出して医用装置３に送信する（Ｓ５９）。医用装置３は、この障害修正用ソフトウェア２１０をソフトウェア記憶部３１に記憶させ、医用ソフトウェア３１のアップデートを実行する（Ｓ６０）。以上で、障害修正用ソフトウェア２１０の配信処理は終了となる。
【０１９６】
〔障害修正用ソフトウェアの配信スケジュール決定処理（使用頻度）：図１３〕
次に、医用ソフトウェア３１０の使用頻度に基づいて障害修正用ソフトウェア２１０の配信スケジュールを決定する処理について、図１３のフローチャートを参照しつつ説明する。この処理において使用頻度情報の作成に用いられる情報（使用日時情報）は、医用ソフトウェア３１０の起動のログ情報や終了のログ情報である。以下、起動のログ情報に基づいて使用頻度情報を作成する場合を説明する。
【０１９７】
準備段階として、新たに開発した障害修正用ソフトウェア２１０等が登録される（Ｓ６１）。
【０１９８】
サーバ２は、医用ソフトウェア３１０の使用頻度の確認を要求する要求信号と確認期間情報とを、一部の医用装置３（１）〜３（ｋ）にそれぞれ送信する（Ｓ６２）。
【０１９９】
医用装置３（１）〜３（ｋ）のそれぞれは、この要求信号に対応して、使用頻度情報を作成し、サーバ２に送信する（Ｓ６３）。この使用頻度情報は、確認期間情報に示す所定の期間における医用ソフトウェア３１０の使用頻度（使用回数／使用時間）を示す情報である。
【０２００】
各医用装置３（１）〜３（ｋ）からの使用頻度情報を受信すると、サーバ２の演算処理部２７は、これら使用頻度情報に基づき、前述の要領で、全医用装置３−１〜３−ｎにおける使用頻度の分布を推定する（Ｓ６４）。
【０２０１】
送信開始日時決定部２３は、推定された分布に基づき、前述の要領で、この分布における使用頻度（使用回数／使用時間）のそれぞれの値について、障害修正用ソフトウェア２１０の送信開始日時を決定する（Ｓ６５）。
【０２０２】
制御部２０は、決定された送信開始日時を、送信開始日時情報２１６として情報格納部２１に格納する（Ｓ６６）。このとき、送信開始日時情報２１６は、障害修正用ソフトウェア２１０に関連付けられて格納される。以上で、医用ソフトウェア３１０の使用頻度に基づく障害修正用ソフトウェア２１０の配信スケジュール決定処理は終了となる。
【０２０３】
このように決定された配信スケジュールに基づく障害修正用ソフトウェア２１０の配信処理は、前述の図１２の場合と同様にして実行される。
【０２０４】
［作用効果］
本実施形態のソフトウェア管理システム１００が奏する作用効果について説明する。
【０２０５】
まず、このソフトウェア管理システム１００によれば、第１の実施形態のソフトウェア管理システム１と同様に、アップデートの緊急性や必要性の高い医用装置に対して優先的に障害修正用ソフトウェア２１０を送信できるとともに、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させなくとも、配信処理の円滑化を図ることができる。
【０２０６】
また、本実施形態に特有の効果として、修正用ソフトウェア２１０の配信スケジュール決定処理の省力化を図ることができる。すなわち、本実施形態では、全ての医用装置３−１〜３−ｎにおける発生頻度情報や使用頻度情報を用いて配信スケジュールを決定する代わりに、一部の医用装置３（１）〜３（ｋ）の発生頻度情報や使用頻度情報に基づく障害発生頻度や使用頻度の分布を用いて、全医用装置３−１〜３−ｎにおける障害発生頻度や使用頻度の分布を推定するようになっている。そして、この推定された分布に基づいて、障害発生頻度や使用頻度の値毎に、送信開始日時を決定している。このように、全医用装置３−１〜３−ｎから発生頻度情報等を収集する必要がないため、配信スケジュール決定処理を効率的に行うことができる。特に、長期間に亘り使用されていない医用装置がある場合など、或る医用装置から発生頻度情報等を取得できないような場合であっても、本実施形態によれば、配信スケジュールを有効に決定することができる。
【０２０７】
〈第３の実施形態〉
図１４、図１５を参照しつつ、本発明に係るソフトウェア管理システムの第３の実施形態を説明する。図１４は、本システムの全体構成の一例を表すブロック図である。図１５は、本システムの動作態様の一例を表すフローチャートである。なお、第１の実施形態と同様の構成部分については、同じ符号を用いて説明することにする。
【０２０８】
［システム構成］
図１４に示すソフトウェア管理システム１０００は、第１の実施形態と同様に、サーバ２と、複数の医用装置３−１〜３−ｎとを備え、更に、ソフトウェア開発者が使用する開発者端末５を備えている。また、医用装置３（３−１）には、第１の実施形態と同様の外部装置４が接続されている。
【０２０９】
開発者端末５は、サーバ２と通信可能に構成されている。その通信態様としては、ＬＡＮ等のローカルネットワークによるものであってもよいし、インターネット等の広域ネットワークによるものであってもよく、また、無線通信であってもよいし、有線通信であってもよい。開発者端末５は、画面表示機能や音声出力機能を有する任意の端末装置によって構成され、たとえば携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）やノートパソコン等の任意のモバイル端末であってもよいし、デスクトップパソコン等の設置型の任意の端末であってもよい。また、後述の報知情報を受信する専用の端末であってもよい。なお、開発者端末５の台数は、１台に限定されるものではなく、たとえばソフトウェア開発者一人ひとりに対して設けるようにしてもよい。
【０２１０】
サーバ２は、制御部２０、情報格納部２１、通信部２６及び検索部２８を含んで構成される。情報格納部２１には、障害修正用ソフトウェア２１０と障害履歴情報２１７とがあらかじめ格納されている。障害履歴情報２１７は、過去に医用ソフトウェア３１０に発生した障害の履歴を表す情報であり、その障害に関連する特定の処理の特定処理識別情報（デバッグログ）と、その障害が発生したソフトウェアモジュールのソフトウェアモジュール識別情報とを含んでいる。なお、情報格納部２１には、複数の障害履歴情報２１７と、各障害履歴情報２１７に示す障害を修正する障害修正用ソフトウェア２１０とが格納されている。対応する障害修正用ソフトウェア２１０と障害履歴情報２１７は、所定の識別情報によって互いに関連付けられている。
【０２１１】
検索部２８は、本発明の「検索手段」の一例に相当し、後述のように医用装置３からデバッグログ等が送信されたときに、そのデバッグログ等と同一のデバッグログ情報等を含む障害履歴情報２１７を情報格納部２１から検索する処理を行う。この検索部２８は、ＣＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【０２１２】
制御部２０には、配信制御部２００と報知制御部２０１とが設けられている。報知制御部２０１は、本発明の「報知制御手段」の一例に相当し、検索部２８によって障害履歴情報が検索されなかったことに対応して、所定の報知情報を開発者端末５に送信するように動作する。ここで、所定の報知情報は、たとえば「新たなソフトウェア障害が発生しました」等の文字情報や音声情報など、開発者端末５により出力可能な任意の形態の情報からなる。また、開発者端末５が、たとえば携帯電話等のバイブレーション機能を有する端末である場合には、開発者端末５の振動を報知情報として用いることも可能である。
【０２１３】
［システムの動作態様］
このような構成を備えるソフトウェア管理システム１０００の動作態様について説明する。図１５に示すフローチャートは、ソフトウェア管理システム１０００の動作態様の一例を表すものである。以下、このフローチャートを参照して説明する。
【０２１４】
医用装置３は、医用ソフトウェア３１０にしたがって処理を実行する度毎に、その処理のログ情報３２０を記録する（Ｓ７１）。医用ソフトウェア３１０の使用中に障害が発生すると、制御部３０がこれを検知する（Ｓ７２）。このとき、医用ソフトウェア３１０は、無応答状態となり、ユーザや全体制御モジュール３１１やオペレーティングシステムによって強制終了される（Ｓ７３）。
【０２１５】
全体制御モジュール３１１やオペレーティングシステムによって自動的に強制終了された場合（Ｓ７３；自動）、制御部３０は、自動で強制終了された旨のログ情報３２０を記録する（Ｓ７４）。一方、ユーザが手動で強制終了を行った場合には、手動で強制終了された旨のログ情報３２０を記録する（Ｓ７５）。
【０２１６】
医用装置３は、この障害に関するログ情報３２０をサーバ２に送信する（Ｓ７６）。このログ情報３２０には、障害発生の所定時間前から障害発生までの間に記録されたデバッグログ、各デバッグログのモジュール名（ソフトウェアモジュール識別情報）、強制終了のログ等が含まれる。
【０２１７】
サーバ２の検索部２８は、医用装置３からのログ情報３２０に含まれるデバッグログと同一のデバッグログ（特定処理識別情報）を含む障害履歴情報２１７を、情報格納部２１から検索する（Ｓ７７）。
【０２１８】
そのような障害履歴情報２１７が検索された場合（Ｓ７８；Ｙ）、検索された障害履歴情報２１７に関連付けられた障害修正用ソフトウェア２１０を特定し（Ｓ７９）、医用装置３に送信する（Ｓ８０）。医用装置３は、受信した障害修正用ソフトウェア２１０をソフトウェア格納部３１に格納し、医用ソフトウェア３１０をアップデートする（Ｓ８１）。この場合の処理は、これで終了となる。
【０２１９】
一方、障害履歴情報２１７が検索されなかった場合には（Ｓ７８；Ｎ）、報知制御部２０１が、通信部２６を制御して、所定の報知情報を開発者端末５に送信し、既存の障害修正用ソフトウェア２１０では対処できない新たな障害が発生した旨をソフトウェア開発者に通知する（Ｓ８２）。
【０２２０】
ソフトウェア開発者は、通知された報知情報を確認し、この新たな障害に対する障害修正用ソフトウェアの開発を行う（Ｓ８３）。その際、ログ情報３２０の解析などが行われる。新たに開発された障害修正用ソフトウェアは、新たな障害履歴情報とともに情報格納部２１に格納される（Ｓ８４）。以上で、この場合の処理は終了となる。なお、この新たな障害修正用ソフトウェアは、適宜のタイミングで医用装置３に送信されることとなる。
【０２２１】
［作用効果］
以上のような本実施形態に係るソフトウェア管理システム１０００によれば、次のような作用、効果が奏される。
【０２２２】
まず、このソフトウェア管理システム１０００の医用装置３は、医用ソフトウェア３１０に障害が発生したときに、その障害に関連するログ情報３２０をサーバ２に送信するようになっている。サーバ２は、医用装置３からのログ情報３２０に対応する障害履歴情報２１７を検索することにより、医用装置３に発生した障害の特定を行う。そして、検索された障害履歴情報２１７に関連付けられた障害修正用ソフトウェア２１０を医用装置３に送信して障害を修正させるように動作する。このように、ソフトウェア管理システム１０００によれば、医用ソフトウェア３１０に発生した障害の内容を的確に特定し、適当な障害修正用ソフトウェア２１０を医用装置３に送信し、障害を修正することができる。
【０２２３】
また、医用ソフトウェア３１０に発生した障害が新たな障害である場合には、この障害を修正する障害修正用ソフトウェア２は未だ開発されておらず、したがって、情報格納部２１にも格納されていない。このような場合、サーバ２は、開発者端末５に向けて報知情報を送信し、新たなソフトウェア障害が発生したことをソフトウェア開発者に通知するように作用する。それにより、ソフトウェア開発者は、新たな障害の発生を迅速に知ることができる。特に、障害修正の緊急度が高い場合などにおいて、障害修正用ソフトウェアの開発に迅速に取り掛かることができる。
【図面の簡単な説明】
【０２２４】
【図１】本発明に係るソフトウェア管理システムの第１の実施形態の構成の一例を表す概略ブロック図である。
【図２】本発明に係るソフトウェア管理システムの第１の実施形態の医用装置の動作を制御する医用ソフトウェアのソフトウェア構成の一例を表す概略図である。
【図３】本発明に係るソフトウェア管理システムの第１の実施形態の医用装置の動作状態を記録したログ情報の一例を表す図である。
【図４】本発明に係るソフトウェア管理システムの第１の実施形態の医用装置の動作状態を記録したログ情報の一例を表す図である。
【図５】本発明に係るソフトウェア管理システムの第１の実施形態の医用装置の動作状態を記録したログ情報の一例を表す図である。
【図６】本発明に係るソフトウェア管理システムの第１の実施形態の動作態様の一例を表すフローチャートである。
【図７】本発明に係るソフトウェア管理システムの第１の実施形態の動作態様の一例を表すフローチャートである。
【図８】本発明に係るソフトウェア管理システムの第１の実施形態の動作態様の一例を表すフローチャートである。
【図９】本発明に係るソフトウェア管理システムの第１の実施形態の動作態様の一例を表すフローチャートである。
【図１０】本発明に係るソフトウェア管理システムの第２の実施形態の構成の一例を表す概略ブロック図である。
【図１１】本発明に係るソフトウェア管理システムの第２の実施形態の動作態様の一例を表すフローチャートである。
【図１２】本発明に係るソフトウェア管理システムの第２の実施形態の動作態様の一例を表すフローチャートである。
【図１３】本発明に係るソフトウェア管理システムの第２の実施形態の動作態様の一例を表すフローチャートである。
【図１４】本発明に係るソフトウェア管理システムの第３の実施形態の構成の一例を表す概略ブロック図である。
【図１５】本発明に係るソフトウェア管理システムの第３の実施形態の動作態様の一例を表すフローチャートである。
【符号の説明】
【０２２５】
１、１００、１０００ ソフトウェア管理システム
２ サーバ
２０ 制御部
２００ 配信制御部
２０１ 報知制御部
２１ 情報格納部
２１０ 障害修正用ソフトウェア
２１１ ソフトウェアモジュール識別情報
２１２ 障害特定情報
２１３ 配信先リスト情報
２１４ 配信順序情報
２１５、２１６ 送信開始日時情報
２１７ 障害履歴情報
２２ 配信順序決定部
２３ 送信開始日時決定部
２４ 日時判断部
２５ 計時部
２６ 通信部
２７ 演算処理部
２８ 検索部
３、３−１〜３−ｎ 医用装置
３０ 制御部
３１ ソフトウェア記憶部
３１０ 医用ソフトウェア
３２ ログ記録部
３２０ ログ情報
３２１ 無応答ログ情報
３２２ 強制終了ログ情報
３２３ デバッグログ情報
３３ 送信情報作成部
３４ ユーザインターフェイス
３５ 通信部
４ 外部装置
５ 開発者端末
Ｎ 広域ネットワーク
【技術分野】
【０００１】
本発明は、医用装置を制御するソフトウェアに発生した障害に対処するためのソフトウェア管理システムに関するもので、特に、ソフトウェアの遠隔アップデート技術に関するものである。
【背景技術】
【０００２】
従来、一般に使用されている基本ソフトウェア（オペレーティングシステム）やアプリケーションソフトウェアに障害が発生した場合、ソフトウェア提供側のサービスエンジニアが、そのソフトウェア自身の動作状況や、障害発生時におけるメモリダンプの情報を参照しつつ障害の原因を特定し、その障害を解決するための修正用ソフトウェアや対処手順をユーザに提供していた（たとえば特許文献１参照）。
【０００３】
また、近年では、修正用ソフトウェア等のアップデート内容を広域ネットワーク上のサーバに格納しておき、そのアップデート内容を目的のクライアントに対して配信する機能、いわゆる遠隔ソフトウェアアップデート機能を有するソフトウェア管理システムが利用されるようになってきている（たとえば特許文献２参照）。
【０００４】
この遠隔ソフトウェアアップデート機能は、たとえば次のように作用する。クライアント（コンピュータ端末等）に電源が投入されると、そのクライアントからサーバに、ソフトウェアのアップデートが必要か否か確認するための信号が送信される。サーバは、この信号に基づいて確認の対象となるアップデート内容が存在するか確認する。アップデート内容が存在する場合、そのアップデート内容をクライアントに送信する。クライアントは、そのアップデート内容を受信して目的のソフトウェアのアップデートを実行する。
【０００５】
このようなシステムを利用することにより、複数のクライアントを一元的に管理できるとともに、修正用ソフトウェアの送信処理も一元化することが可能となる。現在では、広域ネットワーク上の多くのクライアントがこのシステムによってアップデートを行うようになっている。
【０００６】
このような機能を有するシステムを実際に運用する際には、修正用ソフトウェア等のアップデート内容を円滑に配信すること、そして、クライアントにて発生した障害の内容や原因を正確に特定することが重要になってくる。
【０００７】
たとえば、修正用プログラム等のアップデート内容のデータ量が多い場合や、多数のクライアントが同時に起動された場合に、サーバが行うべき処理量が増大して対応できなくなることがあり、また、ネットワーク経由でのデータ送信に時間が掛かってしまうことがある。それにより、サーバに過大な処理負荷が掛かり、また、クライアントの起動時間が長くなるといった問題が発生してしまう。したがって、このような問題を解消するために、アップデート内容のデータ量が多い場合や、多数のクライアントを配信対象とする場合であっても、アップデート内容の配信処理を円滑に行えることが望ましい。
【０００８】
現状では、負荷設計、すなわち、配信するソフトウェアのデータ量の最大サイズをあらかじめ想定し、サーバの台数を増加させて各サーバの処理負荷を軽減させたり、ネットワークの通信データの許容量を増大（ネットワーク負荷を軽減）させたりすることによって、配信処理の円滑化を図っている。
【０００９】
一方、ソフトウェア障害の内容や原因の特定については、それらを特定しない限り、ソフトウェアの適当な部分に適当な対処を施すことができないことを考慮すると、その重要性は当然である。
【００１０】
ところで、近年、各種の医用装置を制御するためのソフトウェアのアップデートについても、上記の遠隔方式で行うようになってきた。そのようなソフトウェア管理システムは、アップデートサービス提供側に設置されたサーバと、医療機関に設置された各種医用装置（クライアント）とを、インターネット等の広域ネットワーク（公衆通信網）で接続した構成を備える。
【００１１】
医用装置を制御するソフトウェアは、もし障害が発生すると、誤診や患者取り違えなどの重大な事態を引き起こす可能性を抱えている。そのため、運用前（出荷前）には、通常のオフィス用ないし個人用のソフトウェアと比較して非常に綿密なソフトウェア試験が行われている。したがって、障害の発生頻度は、他分野のソフトウェアと比べて一般に少ない。しかしながら、運用前の試験を徹底的に行ったとしても、時には想定外の障害が発生することがある。そのため、医用目的のソフトウェアに発生する障害は、非常に複雑なものとなる。
【００１２】
また、医用装置は、他の医用装置や周辺機器に接続されていることが多いため、障害の内容や原因を特定するためには、障害が発生したソフトウェアの情報だけでなく、他の医用装置や周辺機器からの割り込み処理なども解析する必要がある。また、複数のソフトウェアが同時並行的に動作している場合には、障害が発生したソフトウェアに対する他のソフトウェアとの影響についても解析しなければならない。更に、障害発生前の操作手順など、その他の要素も解析する必要がある。このように、医用目的のソフトウェアの障害の内容や原因を特定するには、障害発生前の様々なイベントを総合的に解析し、障害発生時の状況を再現してやらねばならない。
【００１３】
このように、発生する障害自体が複雑であること、更に、他のハードウェアやソフトウェアの影響を考慮する必要があることを勘案すると、医用装置のソフトウェア障害の内容や原因を正確に特定することは非常に困難である。これは、医用分野において遠隔ソフトウェアアップデートを好適に行うための一つの障壁となっている。
【００１４】
一方、多くの病院等の医療機関は、同様の時刻（午前８時〜１０時くらい）に業務を開始するため、医用装置に電源が投入される時刻が、おおよそ午前７〜９時に集中するという現状がある。そうすると、サーバは、この数時間程度の間に多くの医用装置に対応しなければならないことになる。したがって、当該数時間程度における処理負荷を達成できるように、サーバ台数を増やしたり（サーバ容量の冗長化）、ネットワークの通信データの許容量を増大させたり（ネットワーク容量の拡大）する必要がある。しかし、当該数時間程度の間以外の時間には、そのような負荷設計は明らかに過剰であり、全体として高コスト化してしまう。特に、公衆回線の許容量を増大させると、システム維持費に占める通信費の割合が大きくなり、結果として、ユーザが負担する医用装置の保守費が増加してしまう。
【００１５】
また、近年のソフトウェアは、処理実行単位や機能単位毎の複数のソフトウェアモジュールを含んで構成されているのが一般的である。医療分野においても、一つの医用装置に様々な機能を持たせるために、複数のソフトウェアモジュールを含むソフトウェアが広く用いられており、多数の医用装置に共通のソフトウェアモジュールが搭載されていることが多い。
【００１６】
このようなソフトウェアに障害が発生した場合、多数の医用装置の品質管理を均一に行うために、障害が発生したソフトウェアモジュールをアップデートするためのソフトウェアを、各医用装置に配布する必要がある。
【００１７】
一方、共通のソフトウェアモジュールを搭載していても、医用装置の種類や現場での運用形態などによって、そのソフトウェアモジュールを頻繁に利用する医療機関と、ほとんど（全く）利用しない医療機関とが存在する。障害が発生した場合、当該ソフトウェアモジュールをほとんど利用しない医療機関よりも、頻繁に利用する医療機関の方が、障害修復への緊急性が高いと思われる。しかしながら、従来のソフトウェア配信技術では、このような緊急性の違いを考慮して配信スケジュールを組むことができなかった。
【００１８】
【特許文献１】特開平５−１６５６２６号公報
【特許文献２】特開２００４−２６５３０４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１９】
本発明は、このような事情に鑑みて為されたもので、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させることなく、アップデート用のソフトウェアを複数の医用装置に円滑に配信することが可能なソフトウェア管理システムを提供することを目的とする。
【００２０】
また、本発明は、医用装置を制御するソフトウェアに障害が発生したときに、その医用装置を運用する各医療機関における障害修復の緊急性や必要性に応じて、アップデート用のソフトウェアを配信することが可能なソフトウェア管理システムを提供することを他の目的とするものである。
【００２１】
また、本発明は、医用装置を制御するソフトウェアに発生した障害の内容を的確に特定し、適当なアップデート用ソフトウェアを配信することが可能なソフトウェア管理システムを提供することを他の目的とするものである。
【課題を解決するための手段】
【００２２】
上記目的を達成するために、請求項１に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段を備え、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記記録された動作状況情報に基づいて、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２３】
また、請求項７に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、前記ソフトウェアの障害に関連する特定の処理を当該医用装置が実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを、互いに関連付けて記録する記録手段と、前記記録された前記特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして、前記ソフトウェアにおける障害の発生頻度情報を作成する発生頻度情報作成手段と、を備え、前記ソフトウェア配信サーバは、前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記発生頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記発生頻度情報作成手段により作成された発生頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、前記複数の医用装置のそれぞれから受信した前記発生頻度情報に示す前記特定処理識別情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２４】
また、請求項８に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、を備え、前記ソフトウェア配信サーバは、前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、前記複数の医用装置のそれぞれから受信した前記使用頻度情報に示す前記使用日時情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２５】
また、請求項９に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、を備え、前記ソフトウェア配信サーバは、前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、前記複数の医用装置のそれぞれから受信した前記使用頻度情報に示す前記使用時間の値を比較し、前記複数の医用装置のそれぞれに対して、前記使用時間の値の大きい医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２６】
また、請求項１２に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段と、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれについて前記記録された動作状況情報に基づいて、前記２以上の医用装置のそれぞれの前記ソフトウェアにおける障害の発生頻度を示す発生頻度情報を作成する発生頻度情報作成手段と、を備え、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記作成された前記２以上の医用装置のそれぞれの発生頻度情報に基づいて、前記複数の医用装置における前記障害の発生頻度の分布を推定する演算手段と、前記推定された前記障害の発生頻度の分布に基づいて、該分布における前記発生頻度のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、前記決定された送信開始日時に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、当該医用装置は、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２７】
また、請求項１４に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段と、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれについて前記記録された動作状況情報に基づいて、前記２以上の医用装置のそれぞれにおける前記ソフトウェアの使用頻度を示す使用頻度情報を作成する使用頻度情報作成手段と、を備え、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記作成された前記２以上の医用装置のそれぞれの使用頻度情報に基づいて、前記複数の医用装置における前記ソフトウェアの使用頻度の分布を推定する演算手段と、前記推定された前記使用頻度の分布に基づいて、該分布における前記使用頻度のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、前記決定された送信開始日時に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、を備え、当該医用装置は、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２８】
また、請求項１７に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、当該医用装置が前記ソフトウェアの障害に関連する特定の処理を実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを互いに関連付けて記録する記録手段と、前記記録された特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして、当該医用装置における前記障害の発生頻度情報を作成する発生頻度情報作成手段と、を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記発生頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記発生頻度情報作成手段により作成された発生頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、前記受信した前記発生頻度情報に基づいて、前記２以上の医用装置における前記特定処理識別情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記特定処理識別情報の個数の分布を推定する演算手段と、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記特定処理識別情報の個数の分布とに基づいて、該分布における前記特定処置識別情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された特定処理識別情報と特定処理日時情報とに基づいて前記発生頻度作成手段により作成される発生頻度情報に示す特定処理識別情報の個数の値を取得し、現在日時が、該取得された個数の値に対応する送信開始日時以降であるか判断する日時判断手段と、前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、を備え、当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００２９】
また、請求項１８に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、前記受信した前記使用頻度情報に基づいて、前記２以上の医用装置における前記使用日時情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用日時情報の個数の分布を推定する演算手段と、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用日時情報の個数の分布とに基づいて、該分布における前記使用日時情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された使用日時情報に基づいて前記使用頻度作成手段により作成される使用頻度情報に示す使用日時情報の個数の値を取得し、現在日時が、該取得された個数の値に対応する送信開始日時以降であるか判断する日時判断手段と、前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、を備え、当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００３０】
また、請求項１９に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、前記ソフトウェア配信サーバは、アップデート用ソフトウェアをあらかじめ格納する格納手段と、前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、前記受信した前記使用頻度情報に基づいて、前記２以上の医用装置における前記使用時間の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用時間の分布を推定する演算手段と、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用時間の分布とに基づいて、該分布における前記使用時間のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された使用日時情報に基づいて前記使用頻度作成手段により作成される使用頻度情報に示す使用時間の値を取得し、現在日時が、該取得された使用時間の値に対応する送信開始日時以降であるか判断する日時判断手段と、前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、を備え、当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【００３１】
また、請求項２０に記載の発明は、広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、を含むソフトウェア管理システムであって、前記複数の医用装置のそれぞれは、前記ソフトウェアの障害に関連する特定の処理が実行される度毎に、該特定の処理を識別する特定処理識別情報を記録する記録手段と、前記ソフトウェアに障害が発生したときに、該障害の発生日時の所定時間前から該発生日時までの間に前記記録された特定処理識別情報を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信する特定処理識別情報送信手段と、を備え、前記ソフトウェア配信サーバは、過去に前記ソフトウェアに発生した障害に関連する特定の処理の特定処理識別情報を含む障害履歴情報と、当該障害を修正するアップデート用ソフトウェアとを、互いに関連付けてあらかじめ格納する格納手段と、前記複数の医用装置のいずれかにより送信された前記特定処理識別情報を受信する受信手段と、前記受信された特定処理識別情報と同一の特定処理識別情報を含む障害履歴情報を前記格納手段から検索する検索手段と、障害履歴情報が前記検索された場合に、該検索された障害履歴情報に関連付けられたアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信する配信制御手段と、を備え、前記複数の医用装置のそれぞれは、前記配信されたアップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、ことを特徴とする。
【発明の効果】
【００３２】
請求項１に記載のソフトウェア管理システムは、ソフトウェア配信サーバと複数の医用装置とを含んで構成され、各医用装置におけるソフトウェアの動作状況情報を記録するとともに、ソフトウェア配信サーバが、記録された動作状況情報に基づいて複数の医用装置に対するアップデート用ソフトウェアの配信順序を決定し、その決定された配信順序に基づいて複数の医用装置にアップデート用ソフトウェアを配信するように動作する。そして、各医用装置は、配信されたアップデート用ソフトウェアによってソフトウェアのアップデートを行うようになっている。
【００３３】
このようなソフトウェア管理システムによれば、複数の医用装置に対して無作為にアップデート用ソフトウェアの配信を行っていた従来の構成とは異なり、各医用装置の動作状況（たとえば障害の発生頻度やソフトウェアの使用頻度など）に応じて配信順序を決定することができるので、アップデートの緊急性や必要性の高い医用装置に対して優先的にアップデート用ソフトウェアを送信することができる。また、このような配信処理を実行することにより、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させることなく、円滑な配信処理を実現することができる。
【００３４】
請求項１２に記載のソフトウェア管理システムは、ソフトウェア配信サーバと複数の医用装置とを含んで構成され、各医用装置におけるソフトウェアの動作状況情報を記録するとともに、複数の医用装置の一部からなる２以上の医用装置の動作状況情報に基づいて、それら２以上の医用装置におけるソフトウェアにおける障害の発生頻度を示す発生頻度情報を作成するようになっている。ソフトウェア配信サーバは、その２以上の医用装置の発生頻度情報に基づいて複数の医用装置全体における障害の発生頻度の分布を推定し、その推定された分布における発生頻度の各値に対してアップデート用ソフトウェアの送信開始日時を決定し、複数の医用装置に対するアップデート用ソフトウェアの配信を行うようになっている。
【００３５】
このようなソフトウェア管理システムによれば、請求項１の発明と同様に、アップデートの緊急性や必要性の高い医用装置に対して優先的にアップデート用ソフトウェアを送信することができ、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させることなく、円滑な配信処理を実現することができる。
【００３６】
更に、このソフトウェア管理システムによれば、一部の医用装置の発生頻度情報を取得するだけで全ての医用装置に対する配信スケジュールを決定するように作用することから、配信スケジュールの決定処理を効率的に行うことができるという特有の効果が奏される。また、長期間に使用されていない医用装置がある場合など、或る医用装置から発生頻度情報を取得できないような場合であっても、配信スケジュールを有効に決定することができるという特有の効果もある。
【００３７】
請求項１４に記載のソフトウェア管理システムは、ソフトウェア配信サーバと複数の医用装置とを含んで構成され、各医用装置におけるソフトウェアの動作状況情報を記録するとともに、複数の医用装置の一部からなる２以上の医用装置の動作状況情報に基づいて、それら２以上の医用装置におけるソフトウェアの使用頻度を示す使用頻度情報を作成するようになっている。ソフトウェア配信サーバは、その２以上の医用装置の使用頻度情報に基づいて複数の医用装置全体におけるソフトウェアの使用頻度の分布を推定し、その推定された分布における使用頻度の各値に対してアップデート用ソフトウェアの送信開始日時を決定し、複数の医用装置に対するアップデート用ソフトウェアの配信を行うようになっている。
【００３８】
このようなソフトウェア管理システムによれば、請求項１２の発明と同様に、アップデートの緊急性や必要性の高い医用装置に対して優先的にアップデート用ソフトウェアを送信することができ、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させることなく、円滑な配信処理を実現することができるとともに、配信スケジュールの決定処理を効率的に行うことができ、或る医用装置から発生頻度情報を取得できないような場合であっても、配信スケジュールを有効に決定することができる。
【００３９】
請求項２０に記載のソフトウェア管理システムは、ソフトウェア配信サーバと複数の医用装置とを含んで構成され、各医用装置は、ソフトウェア障害に関連する特定の処理を識別する特定処理識別情報を記録し、障害の発生日時の所定時間前から発生日時までの間に記録された特定処理識別情報をソフトウェア配信サーバに送信するように作用する。ソフトウェア配信サーバは、過去のソフトウェア障害に対応する特定処理識別情報を含む障害履歴情報と、その障害を修正するアップデート用ソフトウェアとを互いに関連付けてあらかじめ格納している。そして、複数の医用装置のいずれかから特定処理識別情報を受信すると、その受信した特定処理識別情報と同一の特定処理識別情報を含む障害履歴情報を検索し、その検索された障害履歴情報に関連付けられたアップデート用ソフトウェアを各医用装置に配信するように作用する。
【００４０】
このようなソフトウェア管理システムによれば、医用装置のソフトウェアに発生した障害の内容を特定処理識別情報を用いて的確に特定することができるとともに、適当なアップデート用ソフトウェアを医用装置に送信して障害を効果的に修正することが可能である。
【発明を実施するための最良の形態】
【００４１】
本発明に係るソフトウェア管理システムの好適な実施の形態の一例について、図面を参照しながら詳細に説明する。以下、本発明に係るソフトウェア管理システムについて、３つの実施形態を説明する。
【００４２】
第１、２の実施形態のソフトウェア管理システムは、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させることなく、複数の医用装置に対するアップデート用ソフトウェアの配信の円滑化を図るものであり、アップデートの緊急性や必要性の高い医用装置に対して優先的にアップデート用ソフトウェアを送信することを可能とするものである。
【００４３】
一方、第３の実施形態のソフトウェア管理システムは、或る医用装置にソフトウェア障害が発生したときに、その障害の内容を的確に特定することにより、複数の医用装置に対して適当なアップデート用ソフトウェアを配信するものである。
【００４４】
なお、本発明において「ソフトウェア」とは、医用装置を制御するソフトウェア全体を表すこともあるし、また、当該ソフトウェアの一部を構成するソフトウェアモジュールを表すこともある。したがって、アップデート用ソフトウェアは、ソフトウェア全体をアップデートするものであってもよいし、その一部のソフトウェアモジュールのみをアップデートするものであってもよい。
【００４５】
〈第１の実施形態〉
図１〜図９を参照しつつ、本発明に係るソフトウェア管理システムの第１の実施形態を説明する。図１は、本システムの全体構成の一例を表すブロック図である。図２は、医用装置を制御するソフトウェアの構成の一例を表す概略図である。図３〜図５は、医用装置が記録するログ情報（動作状況情報）の一例を表す図である。図６は、このログ情報を記録する処理の一例を表すフローチャートである。図７は、ソフトウェア障害の発生頻度に基づく配信スケジュール決定処理の一例を表すフローチャートである。図８は、アップデート用ソフトウェアの配信処理の一例を表すフローチャートである。図９は、ソフトウェアの使用頻度に基づく配信スケジュール決定処理の一例を表すフローチャートである。
【００４６】
［システム構成］
図１に示すソフトウェア管理システム１は、サーバ２と、複数（ｎ台）の医用装置３−１〜３−ｎとを備えている。医用装置３−１〜３−ｎは、それぞれ異なる医療機関（病院、診療所、大学、研究所等）に設置されている。各医用装置３−１〜３−ｎは、インターネット等の広域ネットワークＮを通じて、サーバ２とデータ通信可能に設置されている。
【００４７】
図１のソフトウェア管理システム１には、サーバ２が１台しか設けられていないが、実際は、１台以上の任意の台数を設置することが可能である。
【００４８】
医用装置３−１〜３−ｎは、それぞれ同様の構成を具備している。以下、医用装置３−１（３）についてのみ詳細を説明し、他の医用装置３−２〜３−ｎについては、医用装置３に準ずるものとする。
【００４９】
［医用装置の構成］
医用装置３は、医療分野において用いられる任意の装置であって、所定のソフトウェアによる制御にしたがって動作するように構成されている。この医用装置３の具体例としては、電子カルテ管理システム、医用画像管理システム、医事会計管理システム、医用画像診断装置（Ｘ線診断装置、Ｘ線ＣＴ装置、ＭＲＩ装置等）、検像システム、読影システムなどがある。
【００５０】
医用装置３には、所定の外部装置４が接続されている。例えばＲＩＳ（Ｒａｄｉｏｌｏｇｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ：放射線科情報システム）等の医用画像管理システムを医用装置３として用いる場合、この医用画像管理システムに撮影画像を提供する医用画像診断装置などが外部装置４として設置される（逆の場合もある。）。また、医師が診察室等で使用するコンピュータなども外部装置４の一例である。なお、医用装置３に接続された外部装置４の台数は任意である。
【００５１】
さて、本実施形態の医用装置３は、図１に示すように、制御部３０、ソフトウェア記憶部３１、ログ記録部３２、送信情報作成部３３、ユーザインターフェイス（ユーザＩ／Ｆ）３４及び通信部３５を含んで構成される。
【００５２】
〔制御部〕
制御部３０は、医用装置３の各部の制御や、各種データ処理を実行する。制御部３０は、特に、ソフトウェア記憶部３１に記憶された医用ソフトウェア３１０にしたがって、各種の制御処理やデータ処理を実行する。この制御部３０は、たとえばＣＰＵやＭＰＵ等のマイクロプロセッサとＲＡＭ等のメモリを含んで構成される。なお、制御部３０の動作の詳細については、適宜後述することにする。
【００５３】
〔ソフトウェア記憶部〕
ソフトウェア記憶部３１は、本発明の「ソフトウェア記憶手段」の一例に相当するもので、医用ソフトウェア３１０を初めとする各種のソフトウェア（たとえばオペレーティングシステムや、他のアプリケーションソフトウェア）をあらかじめ記憶している。
【００５４】
医用ソフトウェア３１０は、たとえば、電子カルテ管理ソフトウェア、医用画像管理ソフトウェア、医事会計管理ソフトウェア、医用画像診断ソフトウェア、検像ソフトウェア、読影ソフトウェアなど、医用装置３の用途に応じたソフトウェアである。
【００５５】
このソフトウェア記憶部３１は、たとえばハードディスクドライブ等の不揮発性記憶装置を含んで構成される。なお、当該医療機関内のＬＡＮ等のローカルネットワークに接続されている場合、ローカルサーバ上にソフトウェアを格納しておくようにしてもよい。
【００５６】
医用ソフトウェア３１０は、医用ソフトウェア３１０の処理実行単位毎にあるいは機能単位毎に設けられた複数のソフトウェアモジュールによって構成されている。たとえば、図２に示すように、医用ソフトウェア３１０は、全体制御モジュール３１１、ＡＢＣ＿モジュール３１２、ＤＥＦ＿モジュール３１３、ＧＨＩモジュール３１４、ＪＫＬ＿モジュール３１５、ＭＮＯ＿モジュール３１６及びＰＱＲ＿モジュール３１７を有する。
【００５７】
全体制御モジュール３１１は、各モジュール３１２〜３１７の呼び出し処理や、全体制御モジュール３１１自身若しくは各モジュール３１２〜３１７が実行した処理又はユーザによる操作内容等のログを記録する処理などを行う。各モジュール３１２〜３１７は、それぞれ特有の機能を有しており、必要に応じて全体制御モジュール３１１に呼び出されて特有の処理を実行する。
【００５８】
たとえば、医用装置３がＸ線ＣＴ装置である場合、ＡＢＣ＿モジュール３１２は投影データ収集用ソフトウェアモジュール、ＤＥＦ＿モジュールは前処理用ソフトウェアモジュール、ＧＨＩ＿モジュールは再構成処理用ソフトウェアモジュール、ＪＫＬ＿モジュールは後処理用ソフトウェアモジュール、ＭＮＯ＿モジュールは画像表示制御用ソフトウェアモジュール、ＰＱＲ＿モジュールはガントリ駆動用ソフトウェアモジュール、・・・といった具合に、各モジュール３１１〜３１７は特有の機能を有している。
【００５９】
〔ログ記録部〕
ログ記録部３２は、本発明の「記録手段」の一例に相当するもので、医用ソフトウェア３１の動作状況を示すログ情報３２０（動作状況情報）を記録する。ログ記録部３２は、たとえばハードディスクドライブ等の不揮発性記憶装置を含んで構成される。
【００６０】
制御部３０は、医用ソフトウェア３１０に基づく処理を実行する度毎に、その処理を識別する（その処理の処理内容を示す）処理識別情報や、その処理を実行した日時を示す処理日時情報を、ログ情報３２０としてログ記録部３２に記録する。
【００６１】
また、制御部３０は、医用ソフトウェア３１０が使用される度毎に、その使用日時を示す使用日時情報を、ログ情報３２０としてログ記録部３２に記録する。ここで、使用日時情報を記録するタイミングは、たとえば、医用ソフトウェア３１０が起動されたタイミングや、終了されたタイミングなどとされる。
【００６２】
ここで、処理日時情報や使用日時情報として記録される「日時」は、「年、月、日、時刻」を含むものであってもよいし、「月、日、時刻」のみを含むものであってもよいし、「日、時刻」のみを含むものであってもよいし、「日」のみを含むものであってもよいし、「時刻」のみを含むものであってもよい。ここで、「時刻」は、「時、分、秒」や「時、分」からなる。情報の用途などに応じ、これらの選択肢のうちのいずれかを適宜記録する。なお、この「日時」を示す情報は、一般的なマイクロプロセッサに搭載された計時機能に基づいて取得される。
【００６３】
ログ記録部３２に記録されるログ情報３２０の一例として、図３に示す無応答ログ情報３２１、図４に示す強制終了ログ情報３２２、図５に示すデバッグログ情報３２３について説明する。各ログ情報３２１〜３２３には、ログの種類（無応答ログ、強制終了ログ、デバッグログ）を識別するログ識別情報が付されている。
【００６４】
図３に示す無応答ログ情報３２１には、医用装置３のシステムリセット処理若しくは終了処理（シャットダウン処理）の要求に対して無応答状態になったモジュールのモジュール名（「無応答モジュール名」）と、無応答状態になった日時（「ログ日時」；処理日時情報）とが、互いに関連付けられて記録される。
【００６５】
ユーザが、ユーザインターフェイス３４を操作してシステムリセットやシャットダウンを要求すると、全体制御モジュール３１１は、起動中の全てのソフトウェアモジュール（３１２〜３１７）に対して終了要求を送る。この終了要求に応答したソフトウェアモジュールは、要求に応じて終了される。一方、応答しないソフトウェアモジュールは、終了することができず、一定時間が経過してもそのまま起動されている。無応答ログ情報３１２には、この応答しないソフトウェアモジュールのモジュール名とログ日時が記録される。
【００６６】
図４に示す強制終了ログ情報３２２には、医用ソフトウェア３１０に異常動作が発生したときに強制終了されたモジュールのモジュール名（「強制終了モジュール名」）と、強制終了がなされた日時（「ログ日時」；処理日時情報）とが、互いに関連付けられて記録される。
【００６７】
通常、オペレーティングシステムは、医用ソフトウェアの３１０の動作状況を監視して、想定外のメモリ領域へのアクセスや、大量の要求コマンドやイベントの発生などの異常動作（すなわち障害の発生）を検知し、障害が発生したソフトウェアモジュールを強制的に終了させるようになっている。このようなオペレーティングシステムの機能を利用することにより、強制終了されたソフトウェアモジュールのモジュール名とログ日時とが、強制終了ログ情報３２２に記録される。なお、当該機能を有するソフトウェアモジュールを別途搭載することにより、同様の作用を実現するようにしてもよい。制御部３０は、このようなオペレーティングシステムやソフトウェアモジュールによって、医用ソフトウェア３０１に発生した障害を検知する。
【００６８】
図５に示すデバッグログ情報３２３は、発生した障害の原因を特定するために参照される情報である。このデバッグログ情報３２３には、各モジュール３１１〜３１７が実行した処理の処理内容が時系列で記録される。具体的には、各処理内容の識別コードを示す「デバッグログ」（処理内容情報）、当該処理を実行したモジュールの「モジュール名」、及び、当該処理が実行された日時を示す「ログ日時」（処理日時情報）とが、互いに関連付けられて記録される。
【００６９】
このデバッグログ情報３２３には、特に、医用ソフトウェア３１０が使用される度毎に、医用ソフトウェア３１０が起動、終了されたことを示すデバッグログとともに、起動日時や終了日時など、医用ソフトウェア３１０の使用に関連するログ日時（使用日時情報）が記録されるようになっている。
【００７０】
〔送信情報作成部〕
送信情報作成部３３は、デバッグログ情報３２３に記録されたモジュール３１１〜３１７のデバッグログのうち、所定の期間内に実行された特定の処理のデバッグログ（特定処理識別情報）の個数をカウントする。ここで、「特定の処理」は、医用ソフトウェア３１０の障害に関連する処理であり、「特定処理識別情報」は、この特定の処理を識別するデバッグログ（文字列情報）である。また、この「特定の処理」の「ログ日時」は、「特定処理日時情報」に相当する。
【００７１】
「所定の期間」及び「特定処理識別情報」は、後述のようにサーバ２から医用装置３に入力されるか（後述の確認期間情報及び障害特定情報２１２）、若しくは、少なくとも一方が医用ソフトウェア３１０にあらかじめ含まれている。送信情報作成部３３は、「所定の期間」に関連付けられ、かつ、「特定処理識別情報」に該当するデバッグログを、デバッグログ情報３２３から検索するとともに、検索されたデバッグログの個数をカウントする。このカウント結果は、当該所定の期間内における障害（上記特定の処理に関連する障害）の発生回数を表すもので、本発明の「発生頻度情報」の一例に相当する情報である。
【００７２】
また、送信情報作成部３３は、デバッグログ情報３２３に記録されたログ日時のうち、所定の期間に属する起動日時（又は終了日時）を示すログ日時の個数をカウントする。「所定の期間」は、前述のようにサーバ２から入力される。送信情報作成部３３は、入力された「所定の期間」に該当し、かつ、「起動（又は終了）」を示すデバッグログに関連付けられたログ日時を、デバッグログ情報３２３から検索するとともに、検索されたログ日時の個数をカウントする。このカウント結果は、当該所定の期間における医用ソフトウェア３１０の使用回数を表すもので、本発明の「使用頻度情報」の一例に相当する情報である。
【００７３】
また、送信情報作成部３３は、デバッグログ情報３２３に記録されたログ日時から、所定の期間に属する起動日時を示すログ日時と、終了日時を示すログ日時とをそれぞれ検索するとともに、検索されたログ日時に基づいて当該所定の期間における医用ソフトウェア３１０の使用時間（累積使用時間）を算出する。より具体的には、送信情報作成部３３は、検索されたログ日時に基づいて、医用ソフトウェア３１０の各使用毎の使用時間を算出するとともに、各使用毎の使用時間を合算することにより、当該所定の期間における累積使用時間を算出する。この算出結果は、本発明の「使用頻度情報」の一例に相当する情報である。
【００７４】
以上のように、送信情報作成部３３は、本発明の「発生頻度情報作成手段」及び「使用頻度情報作成手段」の一例として動作するものである。この送信情報作成部３３は、ＣＰＵ等をマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【００７５】
（送信情報作成処理の具体例）
送信情報作成部３３による処理の具体例を説明する。ここでは、発生頻度情報の作成処理について説明する。なお、作成の条件の一例として、次の３条件を用いる：（１）登録されたソフトウェアモジュール識別情報２１１は、「ＤＥＦ＿ＭＯＤＵＬＥ」である；（２）障害特定情報２１２は、無応答ログ情報３２１のログ識別情報と、デバッグログ“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”とを含んでいる；（３）「所定の期間」は３０日である。
【００７６】
送信情報作成部３３は、まず、障害特定情報２１２のログ識別情報に基づき、無応答ログ情報３２１を確認対象として認識するとともに、ソフトウェアモジュール識別情報２１１に基づいて、無応答ログ情報３２１からモジュール名「ＤＥＦ＿ＭＯＤＵＬＥ」を検索する。このとき、現在から３０日前までのログ日時、つまり「所定の期間」に属するログ日時に対応するモジュール名を検索する。検索された場合、そのログ日時を取得する。
【００７７】
一方、検索されない場合は、この医用装置３には、障害修正用ソフトウェア２１０により修正されるべき障害は発生していないと判断する（つまり、発生頻度情報「障害の発生頻度＝０」が作成される）。
【００７８】
たとえば図３に示す無応答ログ情報３２１には、モジュール名「ＤＥＦ＿ＭＯＤＵＬＥ」が記録されており、そのログ日時は「２００５／５／１８ ８：１１」となっている。
【００７９】
次に、障害特定情報２１２のデバッグログ“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”に一致するデバッグログを、デバッグログ情報３２３から検索する。検索されない場合、発生頻度情報「障害の発生頻度＝０」が作成される。
【００８０】
一方、検索された場合には、検索されたデバッグログのログ日時と、無応答ログ情報３２１から検索されたモジュール名のログ日時とを比較する。そして、モジュール名のログ日時よりも以前かつ一定時間以内に属するログ日時のデバッグログを検索する。検索されない場合、発生頻度情報「障害の発生頻度＝０」が作成される。また、検索された場合には、検索されたデバッグログの個数をカウントする。このカウント結果を発生頻度情報とする。なお、上記の「一定時間」は、あらかじめ設定されており、たとえば数分程度とされる。
【００８１】
たとえば図５に示すデバッグログ情報３２３には、“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”に一致するデバッグログが記録されており、そのログ日時は「２００５／５／１８ ８：１０：０３」である。ここで、上記の「一定時間」を２分とすると、無応答ログ情報３２１から検索されたモジュール名「ＤＥＦ＿ＭＯＤＵＬＥ」のログ日時は「２００５／５／１８ ８：１１」であるから、「２００５／５／１８ ８：０９」〜「２００５／５／１８ ８：１１」までの間に属するログ日時のデバッグログを検索する。図５に示す上記ログ日時は「２００５／５／１８ ８：１０：０３」であり、したがって、当該ログ日時のデバッグログ“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”は、カウントに考慮される（つまり、カウントが＋１される）。この要領で、「所定の期間（過去３０日）」以内における、特定の障害の発生頻度が求められ、そのカウント結果を発生頻度情報として使用する。
【００８２】
〔ユーザインターフェイス〕
ユーザインターフェイス３４は、ユーザが医用装置３の操作を行ったり、データの設定入力等を行ったりするための操作手段である。このユーザインターフェイス３４としては、たとえば、マウス、キーボード、トラックボール、ジョイスティック、操作パネル、タブレットなど、医用装置３の形態や用途に応じた任意の操作デバイスを用いることが可能である。
【００８３】
〔通信部〕
通信部３５は、広域ネットワークＮを通じてデータ通信を行うためのモデム等の通信機器と、外部装置４との間でデータ通信を行うためのＬＡＮカード等のネットワークアダプタとを含んで構成される。
【００８４】
［サーバの構成］
次に、サーバ２の構成について詳細に説明する。サーバ２は、本発明の「ソフトウェア配信サーバ」の一例に相当するものであり、制御部２０、情報格納部２１、配信順序決定部２２、送信開始日時決定部２３、日時判断部２４、計時部２５及び通信部２６を含んで構成されている。
【００８５】
〔制御部〕
制御部２０は、サーバ２の各部の制御や、各種データ処理を実行する。制御部２０は、特に、医用ソフトウェア３１０をアップデートするソフトウェア（障害修正用ソフトウェア２１０）を、複数の医用装置３−１〜３−ｎに配信するための処理を実行する。この制御部２０は、たとえばＣＰＵやＭＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【００８６】
制御部２０には、配信制御部２００が設けられている。この配信制御部２００は、本発明の「配信制御手段」の一例に相当するものであり、後述のようにして決定されるアップデート用ソフトウェアの配信順序に基づいて、複数の医用装置３−１〜３−ｎにアップデート用ソフトウェアを配信するように作用する。なお、これ以外の制御部２０の動作の詳細については、適宜後述することにする。
【００８７】
〔情報格納部〕
情報格納部２１は、本発明の「格納手段」の一例に相当しアップデート用ソフトウェア及びその配信処理に用いられる各種の情報を格納する。この情報格納部２１は、たとえばハードディスクドライブ等の不揮発性記憶装置を含んで構成される。
【００８８】
情報格納部２１には、障害修正用ソフトウェア２１０、ソフトウェアモジュール識別情報（ＩＤ）２１１、障害特定情報２１２、配信先リスト情報２１３が、あらかじめ格納されている。ソフトウェアモジュール識別情報２１１、障害特定情報２１２及び配信先リスト情報２１３は、それぞれ、障害修正用ソフトウェア２１０毎に生成され、その障害修正用ソフトウェア２１０に関連付けられて情報格納部２１に格納される。
【００８９】
障害修正用ソフトウェア２１０は、ソフトウェア開発者等が、医用ソフトウェア３１０に発生した障害を修正するために（若しくは、発生のおそれのある障害に対処するために）作成したソフトウェアであり、本発明の「アップデート用ソフトウェア」に相当するものである。なお、「修正」とは、障害修正用ソフトウェア２１０を用いて医用ソフトウェア３１０の全部又は一部を変更し又は入れ替えることにより、医用ソフトウェア３１０に存在していたバグやモジュール間の連係などの不都合を解消することを意味するものとする。
【００９０】
ソフトウェアモジュール識別情報２１１は、医用ソフトウェア３１０のソフトウェアモジュール３１１〜３１７（図２参照）のうち、障害修正用ソフトウェア２１０による修正対象となるものを識別する情報である。各ソフトウェアモジュール３１１〜３１７のソフトウェアモジュール識別情報２１１は、たとえば、図３〜図５に示す「モジュール名」を形成する文字列によって構成される。具体的には、たとえばＡＢＣ＿モジュール３１２のソフトウェアモジュール識別情報２１１としては、文字列「ＡＢＣ＿ＭＯＤＵＬＥ」を用いることができる。
【００９１】
障害特定情報２１２は、障害修正用ソフトウェア２１０の修正対象となる障害の種類を特定するための情報であり、また、医用ソフトウェア３１０に発生した障害の種類の特定にも使用可能な情報である。この障害特定情報２１２は、たとえば、図３〜図５のログ情報３２１〜３２３のログ識別情報（前述）と、図５のデバッグログ情報３２３における「デバッグログ」を形成する文字列（特定処理識別情報）とを含んでいる。
【００９２】
障害修正用ソフトウェア２１０の用途、すなわち、障害修正用ソフトウェア２１０により修正される障害は、ソフトウェアモジュール識別情報２１１と障害特定情報２１２とを組み合わせることにより、次のようにして特定される。
【００９３】
障害修正用ソフトウェア２１０の用途が、たとえば「“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”という情報を出力したことを原因とするＤＥＦ＿モジュール３１３の無応答状態を修正する」ことである場合、ソフトウェアモジュール識別情報２１１にはＤＥＦ＿モジュール３１３の識別情報「ＤＥＦ＿ＭＯＤＵＬＥ」が含まれる。また、障害特定情報２１２には、無応答ログ情報３２１のログ識別情報と、デバッグログ“ＬＭＬｏｇＤｌｔ（ＩＤ＿ＦＩＬＥ＿ＬＯＧ）ｒｅｔｕｒｎ ｓｔｓ＝９９９”とが含まれる。
【００９４】
配信先リスト情報２１３は、障害修正用ソフトウェア２１０を配信する医用装置を特定する情報として、たとえば、医用装置３−１〜３−ｎのうち配信対象に指定された医用装置の装置種別（モダリティ名、システム名、装置／システムのモデル名、ソフトウェアバージョン名）や、広域ネットワークＮにおける当該医用装置のネットワークアドレス（ＩＰアドレス等）などを含む情報である。なお、配信先リスト情報２１３により特定される配信先は、医用装置３−１〜３−ｎの全てであってもよいし、一部のみであってもよい。
【００９５】
更に、情報格納部２１には、配信順序情報２１４と送信開始日時情報２１５が格納される。配信順序情報２１４は、配信順序決定部２２により生成されて情報格納部２１に格納される。また、送信開始日時情報２１５は、送信開始日時決定部２３により生成されて情報格納部２１に格納される（それぞれ詳細は後述する）。
【００９６】
情報格納部２１には、一般に、複数の障害修正用ソフトウェア２１０が格納されている。また、これら複数の障害修正用ソフトウェア２１０のそれぞれに関連付けられたソフトウェアモジュール識別情報２１１、障害特定情報２１２及び配信先リスト情報２１３が格納されている。更に、配信スケジュールの決定後には、これら複数の障害修正用ソフトウェア２１０のそれぞれに関連付けられた配信順序情報２１４と送信開始日時情報２１５とが格納される。
【００９７】
〔配信順序決定部〕
配信順序決定部２２は、本発明の「配信スケジュール決定手段」に含まれるものであり、複数の医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序を決定するように動作する。決定された配信順序は、制御部２０により配信順序情報２１４として情報格納部２１に格納されるとともに、送信開始日時決定部２３に送られる。配信順序決定部２２は、たとえばＣＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。この配信順序決定部２２の具体的な動作内容については後述する（図７に基づく説明を参照）。
【００９８】
〔送信開始日時決定部〕
送信開始日時決定部２３は、本発明の「配信スケジュール決定手段」に含まれる「送信開始日時決定手段」の一例に相当し、配信先リスト情報２１３により配信先に指定されている複数の医用装置３−１〜３−ｎ（の一部）のそれぞれについて、障害修正用ソフトウェア２１０の送信開始日時を決定する。決定された送信開始日時は、制御部２０により、送信開始日時情報２１５として情報格納部２１に格納される。送信開始日時決定部２３は、たとえばＣＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【００９９】
ここで、「送信開始日時」とは、当該医用装置に対する障害修正用ソフトウェア２１０の送信禁止状態が解除される日時を表す。換言すると、送信開始日時とは、送信禁止状態が解除されて障害修正用ソフトウェア２１０が当該医用装置に送信される日時、あるいは、当該医用装置からの送信要求に応じて障害修正用ソフトウェア２１０を送信すること許可される日時を表している。
【０１００】
医用装置３−ｉ（ｉ＝１〜ｎ）に対する送信開始日時は、これら医用装置の装置数（ｎ）と、所定時間内に障害修正用ソフトウェア２１０を送信可能な医用装置の最大数（Ｍ）と、配信順序決定部２２により決定された配信順序とに基づいて決定される。
【０１０１】
この送信開始日時の決定処理を具体的に説明する。情報格納部２１には、サーバ２による最大送信能力を示す配信可能装置数情報が、あらかじめ格納されている（図示省略）。この配信可能装置数情報は、サーバ２が、広域ネットワークＮを通じて、所定時間内に障害修正用ソフトウェア２１０を送信することができる医用装置の装置数が記録されている。たとえば、サーバ２が１日（所定時間）に送信可能な装置数が１００装置である場合（Ｍ＝１００／日）、「配信可能装置数情報＝１００（装置／日）」が情報格納部２１に格納されている。なお、この数値は、サーバ２の情報処理能力や他の処理の処理負荷、更に広域ネットワークＮの通信データの許容量などに基づいて、計算や実測を行うことにより、あらかじめ決定される。
【０１０２】
配信先リスト情報２１３に記録された配信先の装置数が１０００装置であるとする（説明を簡略化するため、全装置数ｎ＝１０００とする）。その場合、これら１０００の医用装置３−１〜３−１０００に対して、１日１００装置ずつ、合計１０日に亘って配信を行うようにスケジュールが組まれる。
【０１０３】
一方、配信順序決定部２２により決定される配信順序は、これら１０００装置に対する配信順序を表すものである。ここでは、説明を簡略化するため、医用装置３−１、３−２、３−３、・・・、３−９９９、３−１０００に対して、当該順序で配信するものとする。
【０１０４】
送信開始日時決定部２３は、まず、配信可能装置数情報（＝１００装置／日）と、配信先の全装置数（＝１０００装置）とに基づいて、全装置への配信に必要な日数を算出する（１０００÷１００＝１０日）。なお、算出結果が整数にならない場合（つまり割り切れない場合）には、商の値の整数部分に相当する日数に、剰余部分を送信するための１日を追加するなどして、配信に要する日数を算出する。
【０１０５】
次に、送信開始日時決定部２３は、算出された配信日数にしたがって、各医用装置３−１〜３−１０００の配信開始日時を決定する。上記の例では、医用装置３−１〜３−１００の配信開始日時は、配信第１日目（の例えば午前０時）、医用装置３−１０１〜３−２００の配信開始日時は、配信第２日目（の例えば午前０時）、・・・、医用装置３−９０１〜３−１０００の配信開始日時は、配信第１０日目（の例えば午前０時）、となる。
【０１０６】
なお、配信日時を決定するためには決定時の日時が必要であるが、その情報は、たとえば後述の計時部２５から取得することができる。また、現在日時あるいは配信第１目の日付をユーザが手動設定するようにしてもよい。
【０１０７】
〔日時判断部〕
日時判断部２４は、サーバ２が医用装置から障害修正用ソフトウェア２１０の送信要求を受信したときに動作し、現在日時が、当該医用装置の送信開始日時以降であるか否か判断する。この日時判断部２４は、本発明の「日時判断手段」の一例に相当し、たとえばＣＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【０１０８】
或る医用装置から障害修正用ソフトウェア２１０の送信要求が入力されると、制御部２０は、情報格納部２１に格納された送信開始日時情報２１５から、当該医用装置の送信開始日時を検索し、日時判断部２４に送る。
【０１０９】
日時判断部２４は、まず、後述の計時部２５を参照して現在日時を取得する。次に、日時判断部２４は、現在日時と当該医用装置の送信開始日時とを比較し、現在日時が、当該医用装置の送信開始日時以降であるか否か判断する。そして、その判断結果を制御部２０に送る。
【０１１０】
〔計時部〕
計時部２５は、計時機能を有する一般的なマイクロプロセッサを含んで構成される。
【０１１１】
〔通信部〕
通信部２６は、広域ネットワークＮを通じてデータ通信を行うためのモデム等の通信機器を備えている。
【０１１２】
［システムの動作態様］
このような構成を備えるソフトウェア管理システム１の動作態様の一例について説明する。以下、ソフトウェア管理システム１の各種の動作形態を説明する。
【０１１３】
〔医用ソフトウェアの動作状況の記録処理：図６〕
まず、医用装置３による医用ソフトウェア３１０の動作状況の記録処理について、図６のフローチャートを参照しつつ説明する。
【０１１４】
まず、医用装置３の電源投入や、ユーザからの起動要求に対応して医用ソフトウェア３１０が起動されると（Ｓ１）、制御部３０が、起動されたことを示すデバッグログと、そのログ日時（起動日時）と、起動されたモジュール名とを、デバッグログ情報３２３に記録する（Ｓ２）。
【０１１５】
医用ソフトウェア３１０が各種処理を実行する度毎に、制御部３０は、当該処理に対応するログ日時、モジュール名及びデバッグログをデバッグログ情報３２３に記録する（Ｓ３）。この処理は、医用ソフトウェア３１０の使用が終了されるまで逐次行われる。
【０１１６】
医用装置３の電源が切られたり、ユーザからの終了要求が入力されたりして、医用ソフトウェア３１０の使用の終了が要求されると（Ｓ４；Ｙ）、制御部３０は、使用終了を示すデバッグログと、その日時（終了日時）と、終了されたモジュール名とを、デバッグログ情報３２３に記録する（Ｓ５）。この場合における医用ソフトウェア３１０の動作状況の記録処理は、これで終了となる。
【０１１７】
一方、医用ソフトウェア３１０の使用中に（Ｓ４；Ｎ）、障害が発生すると、制御部３０がこれを検知する（Ｓ６）。障害が発生した医用ソフトウェア３１０は、無応答状態に陥るか、或いは、ユーザや全体制御モジュール３１１やオペレーティングシステムによって強制終了される（Ｓ７）。
【０１１８】
医用ソフトウェア３１０が無応答状態になった場合（Ｓ７；無応答）、制御部３０は、無応答状態になった日時を示すログ日時と、無応答状態になったモジュール名とを、無応答ログ情報３２１に記録し（Ｓ８）、処理を終了する。
【０１１９】
一方、医用ソフトウェア３１０が強制終了された場合（Ｓ７；強制終了）、制御部３０は、強制終了された日時を示すログ日時と、強制終了されたモジュール名とを、強制終了ログ情報３２２に記録し（Ｓ９）、処理を終了する。
【０１２０】
〔障害修正用ソフトウェアの配信スケジュール決定処理（障害発生頻度）：図７〕
次に、医用ソフトウェア３１０の障害発生頻度に基づいて障害修正用ソフトウェア２１０の配信スケジュールを決定する処理について、図７のフローチャートを参照しつつ説明する。
【０１２１】
準備段階として、ソフトウェア開発者等が、新たに開発した障害修正用ソフトウェア２１０と、そのソフトウェアモジュール識別情報２１１と、障害特定情報３１２と、配信先リスト情報２１３とを、サーバ２の情報格納部２１に格納し、登録する（Ｓ１１）。その登録方法としては、メディアに記憶されたこれらの情報２１０〜２１３を、サーバ２のドライブ装置（図示せず）に挿入して読み取らせる方法や、ソフトウェア開発者の端末装置（図示せず）からサーバ２にＬＡＮ等を経由してアップロードさせる方法などの、任意の方法を適宜に用いることができる。
【０１２２】
制御部２０は、医用ソフトウェア３１０の障害発生頻度の確認を要求する要求信号と、障害特定情報２１２と、確認期間情報（図示せず）を通信部２６に送り、広域ネットワークＮを通じて、全ての医用装置３−１〜３−ｎにそれぞれ送信する（Ｓ１２）。
【０１２３】
なお、確認期間情報は、発生頻度情報や使用頻度情報や使用頻度情報を作成するときに、ログ情報３２０に記録されたログのうち、どの期間に記録されたログを確認するかを指定する情報である。この期間は、本発明の「所定の期間」に相当し、あらかじめ設定されたものである。なお、この期間を適宜に変更することも可能である。
【０１２４】
医用装置３−１〜３−ｎのそれぞれは、サーバ２からの要求信号に対応して送信情報作成部３３を動作させ、障害特定情報２１２と確認期間情報とに基づいて、障害の発生頻度情報を作成させるとともに、作成された発生頻度情報をサーバ２に送信する（Ｓ１３）。
【０１２５】
各医用装置３−１〜３−ｎからの発生頻度情報を受信すると、サーバ２の配信順序決定部２２は、これら発生頻度情報に基づいて、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序を決定する（Ｓ１４）。
【０１２６】
具体的には、配信順序決定部２２は、医用装置３−１〜３−ｎの発生頻度情報に示す特定処理識別情報の個数を比較し、個数の多い順に医用装置３−１〜３−ｎのそれぞれに順位を指定する。このとき、個数が同じ医用装置には、適宜に順位を指定することができる。この順位が、障害修正用ソフトウェア２１０を送信する順位となる。それにより、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序が決定される。決定された配信順序は、送信開始日時決定部２３に送られる。
【０１２７】
送信開始日時決定部２３は、決定された配信順序に基づき、前述の要領で、各医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の送信開始日時を決定する（Ｓ１５）。
【０１２８】
制御部２０は、ステップＳ１４で決定された配信順序を、配信順序情報２１４として情報格納部２１に格納するとともに、ステップＳ１５で決定された送信開始日時を、送信開始日時情報２１５として情報格納部２１に格納する（Ｓ１６）。このとき、配信順序情報２１４と送信開始日時情報２１５は、それぞれ、障害修正用ソフトウェア２１０に関連付けられて格納される。以上で、医用ソフトウェア３１０の障害発生頻度に基づく障害修正用ソフトウェア２１０の配信スケジュール決定処理は終了となる。
【０１２９】
〔修正用ソフトウェアの配信処理：図８〕
次に、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信処理について、図８のフローチャートを参照しつつ説明する。
【０１３０】
医用装置３は、医用ソフトウェア３１０をアップデートするソフトウェアの有無を確認し、それが有る場合にはその送信を要求する信号（送信要求信号）を、所定のタイミングでサーバ２に送信する（Ｓ２１）。このとき、送信要求信号とともに、医用装置３を識別する装置識別情報が送信される。なお、「所定のタイミング」とは、たとえば医用装置３の起動時やシャットダウン時、或いは、あらかじめ設定された時刻などとされる。
【０１３１】
サーバ２の制御部２０は、送信要求信号情報格納部２１に格納された各配信先リスト情報２１３を参照し、医用装置３が送信先に含まれているか判定することにより、アップデート用ソフトウェア（障害修正用ソフトウェア）の有無を確認する（Ｓ２２）。
【０１３２】
医用装置３に対するアップデート用ソフトウェアが無い場合には（Ｓ２３；Ｎ）、処理を終了する。このとき、アップデート用ソフトウェアが無い旨を示す信号を医用装置３に送信するようにしてもよい。
【０１３３】
一方、医用装置３に対するアップデート用ソフトウェアが有る場合（Ｓ２３；Ｙ）、制御部２０により、送信開始日時情報２１５から医用装置３の送信開始日時が選択されて日時判断部２４に送られるとともに（Ｓ２４）、計時部２５から日時判断部２４に現在日時が送られる。日時判断部２４は、この現在日時と医用装置３の送信開始日時とを比較し、現在日時が送信開始日時以降であるか否か、つまり送信開始日時を経過しか否かを判断する（Ｓ２５）。
【０１３４】
送信開始日時を経過していないと判断された場合には（Ｓ２６；Ｎ）、処理を終了する。このとき、アップデート用ソフトウェアが無い旨を示す信号を医用装置３に送信するようにしてもよい。
【０１３５】
一方、送信開始日時を経過していると判断された場合（Ｓ２６；Ｙ）、制御部２０の配信制御部２００は、情報格納部２１から障害修正用ソフトウェア２１０を読み出して通信部２６に送り、広域ネットワークＮを通じて医用装置３に送信させる（Ｓ２７）。医用装置３は、この障害修正用ソフトウェア２１０をソフトウェア記憶部３１に記憶させ、医用ソフトウェア３１のアップデートを実行する（Ｓ２８）。以上で、障害修正用ソフトウェア２１０の配信処理は終了となる。
【０１３６】
〔障害修正用ソフトウェアの配信スケジュール決定処理（使用頻度）：図９〕
次に、医用ソフトウェア３１０の使用頻度に基づいて障害修正用ソフトウェア２１０の配信スケジュールを決定する処理について、図９のフローチャートを参照しつつ説明する。この処理において使用頻度情報の作成に用いられる情報（使用日時情報）は、たとえば、図６のフローチャートに示す動作状況記録処理により記録された、医用ソフトウェア３１０の起動のログ情報（ステップＳ２）若しくは終了のログ情報（ステップＳ５、Ｓ９）である。以下、起動のログ情報に基づいて使用頻度情報を作成する場合を説明することにする。
【０１３７】
まず、障害発生頻度の場合（図７）と同様に、新たに開発した障害修正用ソフトウェア２１０と、そのソフトウェアモジュール識別情報２１１と、障害特定情報３１２と、配信先リスト情報２１３とが登録されると（Ｓ３１）、サーバ２から各医用装置３−１〜３−ｎに対し、医用ソフトウェア３１０の使用頻度の確認を要求する要求信号と、確認期間情報（図示せず）とが送信される（Ｓ３２）。
【０１３８】
各医用装置３−１〜３−ｎは、サーバ２からの要求信号に対応して送信情報作成部３３を動作させる。送信情報作成部３３は、デバッグログ情報３２３に記録されたログ日時のうち、確認期間情報に示す所定の期間に属する起動日時を示すログ日時（使用日時情報）を検索するとともに、検索されたログ日時の個数をカウントして、医用ソフトウェア３１０の使用頻度情報を作成する。各医用装置３−１〜３−ｎは、作成された使用頻度情報をサーバ２に送信する（Ｓ３３）。
【０１３９】
各医用装置３−１〜３−ｎからの使用頻度情報を受信すると、サーバ２の配信順序決定部２２は、これら使用頻度情報に基づいて、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序を決定する（Ｓ３４）。
【０１４０】
具体的には、配信順序決定部２２は、医用装置３−１〜３−ｎの使用頻度情報に示す使用日時情報（起動日時のログ情報）の個数を比較し、個数の多い順に医用装置３−１〜３−ｎのそれぞれに順位を指定する。このとき、個数が同じ医用装置には、適宜に順位を指定することができる。この順位が、障害修正用ソフトウェア２１０を送信する順位となる。それにより、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序が決定される。決定された配信順序は、送信開始日時決定部２３に送られる。
【０１４１】
送信開始日時決定部２３は、決定された配信順序に基づいて、各医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の送信開始日時を決定する（Ｓ３５）。
【０１４２】
制御部２０は、ステップＳ３４で決定された配信順序を、配信順序情報２１４として情報格納部２１に格納するとともに、ステップＳ３５で決定された送信開始日時を、送信開始日時情報２１５として情報格納部２１に格納する（Ｓ３６）。このとき、配信順序情報２１４と送信開始日時情報２１５は、それぞれ、障害修正用ソフトウェア２１０に関連付けられて格納される。以上で、医用ソフトウェア３１０の使用頻度に基づく障害修正用ソフトウェア２１０の配信スケジュール決定処理は終了となる。
【０１４３】
このように決定された配信スケジュールに基づく障害修正用ソフトウェア２１０の配信処理は、前述した図８の場合と同様にして実行される。
【０１４４】
なお、所定の期間における医用ソフトウェア３１０の累積使用時間に基づいて使用頻度情報を作成する場合については、次のような処理を実行する。まず、新たに開発した障害修正用ソフトウェア２１０等の登録（Ｓ３１）と、サーバ２から各医用装置３−１〜３−ｎへの要求信号及び確認期間情報の送信（Ｓ３２）とを、同様に行う。
【０１４５】
各医用装置３−１〜３−ｎの送信情報作成部３３は、デバッグログ情報３２３に記録されたログ日時のうち、確認期間情報に示す所定の期間に属する起動日時を示すログ日時と終了日時を示すログ日時（使用日時情報）とを検索し、各使用時における使用時間を算出する。このとき、たとえば、所定の期間に属する起動日時と終了日時を検索し、各起動日時とその次の終了日時との時間間隔を当該使用時の使用時間として算出する。そして、各使用時の使用時間を加算して、所定の期間における（累積）使用時間を算出して使用頻度情報を作成する。各医用装置３−１〜３−ｎは、作成された使用頻度情報をサーバ２に送信する（Ｓ３３）。
【０１４６】
各医用装置３−１〜３−ｎからの使用頻度情報を受信すると、サーバ２の配信順序決定部２２は、医用装置３−１〜３−ｎの使用頻度情報に示す（累積）使用時間の値を比較し、その値の大きい順に医用装置３−１〜３−ｎのそれぞれに順位を指定する。このとき、使用時間の値が同じ医用装置には、適宜に順位を指定することができる。この順位が、障害修正用ソフトウェア２１０を送信する順位となる。それにより、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序が決定される（Ｓ３４）。
【０１４７】
送信開始日時決定部２３は、決定された配信順序に基づいて、各医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の送信開始日時を決定する（Ｓ３５）。制御部２０は、ステップＳ３４で決定された配信順序を、配信順序情報２１４として情報格納部２１に格納するとともに、ステップＳ３５で決定された送信開始日時を、送信開始日時情報２１５として情報格納部２１に格納する（Ｓ３６）。以上で、医用ソフトウェア３１０の使用頻度に基づく障害修正用ソフトウェア２１０の配信スケジュール決定処理は終了となる。
【０１４８】
［作用効果］
以上のような本実施形態に係るソフトウェア管理システム１の作用及び効果について説明する。
【０１４９】
ソフトウェア管理システム１の各医用装置３−１〜３−ｎは、医用ソフトウェア３１０の動作状況を示すログ情報３２０を記録している。ここで、ログ情報３２０は、障害の発生頻度や医用ソフトウェア３１０の使用頻度を得るための基になる情報である。一方、サーバ２は、アップデート用の障害修正用ソフトウェア２１０を情報格納部２１にあらかじめ格納している。サーバ２は、配信順序決定部２２により、ログ情報３２０に基づいて医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信順序を決定し、その配信順序に基づいて医用装置３−１〜３−ｎにアップデート用ソフトウェアを配信する。各医用装置３−１〜３−ｎは、配信された障害修正用ソフトウェア２１０により医用ソフトウェア３１０のアップデートを行う。
【０１５０】
このように、本実施形態によれば、ログ情報３２０に基づく障害発生頻度やソフトウェア使用頻度に基づいて、アップデートの緊急性や必要性の高い医用装置に対して優先的に障害修正用ソフトウェア２１０を送信できる。したがって、従来のように複数の医用装置に対して無作為に配信を行うことがないため、配信処理の円滑化を図ることができるとともに、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を無駄に増大させる必要もない。
【０１５１】
また、各医用装置３−１〜３−ｎには、記録されたログ情報３２０に基づいて、医用ソフトウェア３１０における障害の発生頻度を示す発生頻度情報を作成する送信情報作成部３３が設けられており、サーバ２の配信順序決定部２２は、医用装置３−１〜３−ｎに対して、発生頻度情報に示す障害の発生頻度の高いものから順に送信順位を指定するようになっている。したがって、医用ソフトウェア３１０の障害の発生頻度が高く、アップデートの緊急性の高い医用装置に対して優先的に障害修正用ソフトウェア２１０を送信することができる。
【０１５２】
また、各医用装置３−１〜３−ｎの送信情報作成部３３は、記録されたログ情報３２０に基づいて、医用ソフトウェア３１０の使用頻度を示す使用頻度情報を作成することができ、サーバ２の配信順序決定部２２は、医用装置３−１〜３−ｎに対して、使用頻度情報に示す医用ソフトウェア３１０の使用頻度の高いものから順に送信順位を指定するようになっている。ここで、医用ソフトウェア３１０の使用頻度情報は、所定の期間における医用ソフトウェア３１０の使用回数又は累積使用時間を表す情報である。したがって、医用ソフトウェア３１０の障害の発生頻度が高く、アップデートの必要性の高い医用装置に対して優先的に障害修正用ソフトウェア２１０を送信することができる。
【０１５３】
また、サーバ２は、医用装置３−１〜３−ｎの装置数と、所定時間内に障害修正用ソフトウェア２１０を送信可能な医用装置の最大装置数（配信可能装置数情報）と、配信順序決定部２２が決定した配信順序とに基づいて、各医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の送信開始日時を決定することができる。それにより、配信先の数と、システムの配信能力（配信可能装置数情報）とに基づいて、効率のよい配信スケジュールを作成することができ、配信処理の円滑化を図ることができる。
【０１５４】
また、サーバ２は、修正用ソフトウェア２１０の送信を要求する送信要求信号を或る医用装置から受信したときに、その医用装置の送信開始日時が経過していない限り、その医用装置に障害修正用ソフトウェア２１０を送信しないようになっている。したがって、優先度の高い医用装置から順に、円滑に配信処理を行うことができる。
【０１５５】
［変形例］
本実施形態に係るソフトウェア管理システム１の変形例を説明する。なお、これらの変形例は、以下の実施形態に対して適宜応用することが可能である。
【０１５６】
本実施形態では、医用装置３−１〜３−ｎのそれぞれが個別にログ情報３２０を記録するようになっていたが、これら医用装置３−１〜３−ｎのログ情報３２０をまとめて記録しておくことも可能である。例えば、ログ情報３２０を記録する記録手段（ハードディスクドライブ等）をサーバ２に設けておく。そして、各医用装置３−１〜３−ｎは、処理を行う度毎に（又は定期的／不定期的に）、その処理のログ情報を、広域ネットワークＮ経由でサーバ２に送信して記録手段に記録するように構成することができる。このとき、各医用装置を識別する装置識別情報をログ情報に付加して送信する。
【０１５７】
その場合、ソフトウェア障害の発生頻度を示す発生頻度情報を作成する発生頻度情報作成手段や、ソフトウェアの使用頻度を示す使用頻度情報を作成する使用頻度情報作成手段（本実施形態では、ともに「送信情報作成部３３」）についても、サーバ２に集約することが可能である。
【０１５８】
また、本実施形態では、医用装置３からの要求に応じて障害修正用ソフトウェア２１０を配信するようになっているが、本発明はこれに限定されるものではない。たとえば、各医用装置３−１〜３−ｎに対し、その送信開始日時の到来とともに、障害修正用ソフトウェア２１０を順次配信するように構成することができる。
【０１５９】
〈第２の実施形態〉
図１０〜図１３を参照しつつ、本発明に係るソフトウェア管理システムの第２の実施形態を説明する。図１０は、本システムの全体構成の一例を表すブロック図である。図１１は、ソフトウェア障害の発生頻度に基づく配信スケジュール決定処理の一例を表すフローチャートである。図１２は、アップデート用ソフトウェアの配信処理の一例を表すフローチャートである。図１３は、ソフトウェアの使用頻度に基づく配信スケジュール決定処理の一例を表すフローチャートである。なお、第１の実施形態と同様の構成部分については、説明の重複を避けるため、同じ符号を用いることにする。
【０１６０】
第１の実施形態は、アップデート用ソフトウェアの配信対象となる全ての医用装置３−１〜３−ｎにおける医用ソフトウェアの障害発生頻度や使用頻度に基づいて配信スケジュールを決定するものであった。一方、本実施形態は、配信対象となる医用装置３−１〜３−ｎの一部における障害発生頻度や使用頻度に基づいて配信スケジュールを決定することにより、第１の実施形態と同様の効果とともに、配信スケジュール決定処理の省力化という特有の効果を奏するものである。
【０１６１】
［システム構成］
図１０に示すソフトウェア管理システム１００は、第１の実施形態と同様に、サーバ２と、複数の医用装置３−１〜３−ｎとを備えている。各医用装置３−１〜３−ｎは、広域ネットワークＮを通じて、サーバ２とデータ通信可能に設置されている。また、医用装置３（３−１）には、第１の実施形態と同様の外部装置４が接続されている。
【０１６２】
各医用装置３−１〜３−ｎは、第１の実施形態と同様の構成を有している。サーバ２は、第１の実施形態とほぼ同様であるが、構成上、演算処理部２７を備えている点が異なっている。また、本実施形態の送信開始日時決定部２３は、第１の実施形態とは異なる処理を実行して、送信開始日時情報２１６を作成する。
【０１６３】
〔演算処理部〕
サーバ２の演算処理部２７は、医用装置３−１〜３−ｎのうちの一部の医用装置からの発生頻度情報や使用頻度情報に基づいて、全医用装置３−１〜３−ｎにおける障害発生頻度や使用頻度の分布を推定する処理を行う。この演算処理部２７は、本発明の「演算手段」の一例に相当し、たとえばＣＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【０１６４】
上記の「一部の医用装置」の装置数は少なくとも２以上とされる。これら２以上の医用装置を「医用装置３（１）〜３（ｋ）」と表すことにする。ここで、ｋは、２≦ｋ≦ｎ−１を満たすあらかじめ設定された正の整数であり、たとえばｋはｎの約数（ｋ｜ｎ）とされる。以下、演算処理部２７が実行する処理をより具体的に説明する。
【０１６５】
最初に、医用ソフトウェア３１０の障害発生頻度の分布の推定処理の例を説明する。まず、演算処理部２７は、一部の医用装置３（１）〜３（ｋ）のそれぞれからの発生頻度情報に基づいて、これら医用装置３（１）〜３（ｋ）における特定処理識別情報の個数の分布を求める。すなわち、発生頻度情報は、第１の実施形態において説明したように、所定の期間内における（特定の）障害の発生回数を示す情報であり、具体的には、所定の期間にログ情報３２０に記録された特定処理識別情報の個数を示す情報である。演算処理部２７は、各医用装置３（１）〜３（ｋ）における特定処理識別情報の個数を取得し、それらを個数別に分類するとともに、各個数に対応する装置数を求める。それにより、特定処理識別情報の個数を変数（離散変数）とする、医用装置の装置数の分布（離散分布）が得られる。
【０１６６】
続いて、演算処理部２７は、この特定処理識別情報の個数毎の装置数の分布と、全医用装置３−１〜３−ｎの装置数に対する医用装置３（１）〜３（ｋ）の装置数の比率（ｋ／ｎ）とに基づいて、全医用装置３−１〜３−ｎにおける特定処理識別情報の個数の分布を推定することにより、障害の発生頻度の分布を推定する。すなわち、一部の医用装置３（１）〜３（ｋ）に関する分布における各特定処理識別情報の個数の値を、上記比率で除算することにより、全医用装置３−１〜３−ｎに関する、特定処理識別情報の個数を変数とする医用装置の装置数の分布を求める。以上が、障害発生頻度の分布の推定処理の一例である。
【０１６７】
次に、医用ソフトウェア３１０の使用頻度（使用回数）の分布の推定処理の例を説明する。まず、演算処理部２７は、一部の医用装置３（１）〜３（ｋ）のそれぞれからの使用頻度情報に基づいて、これら医用装置３（１）〜３（ｋ）における使用日時情報の個数の分布を求める。すなわち、使用頻度情報は、第１の実施形態において説明したように、所定の期間内における医用ソフトウェア３１０の使用回数を示す情報であり、具体的には、所定の期間にログ情報３２０に記録された起動処理や終了処理のデバッグログ（使用日時情報）の個数を示す情報である。演算処理部２７は、各医用装置３（１）〜３（ｋ）における使用日時情報の個数を取得し、それらを個数別に分類するとともに、各個数に対応する装置数を求める。それにより、使用日時情報の個数を変数（離散変数）とする、医用装置の装置数の分布（離散分布）が得られる。
【０１６８】
続いて、演算処理部２７は、上記障害発生頻度の場合と同様に、この使用日時情報の個数毎の装置数の分布と、全医用装置３−１〜３−ｎの装置数に対する医用装置３（１）〜３（ｋ）の装置数の比率（ｋ／ｎ）とに基づき、全医用装置３−１〜３−ｎにおける使用日時情報の個数の分布を推定することにより、医用ソフトウェア３１０の使用頻度（使用回数）の分布を推定する。以上が、使用回数に関する使用頻度の分布の推定処理の一例である。
【０１６９】
次に、医用ソフトウェア３１０の使用頻度（使用時間）の分布の推定処理の例を説明する。まず、演算処理部２７は、一部の医用装置３（１）〜３（ｋ）のそれぞれからの使用頻度情報に基づいて、これら医用装置３（１）〜３（ｋ）における使用時間の分布を求める。すなわち、使用頻度情報は、第１の実施形態において説明したように、所定の期間内における医用ソフトウェア３１０の累積使用時間を示す情報である。演算処理部２７は、各医用装置３（１）〜３（ｋ）における使用時間を取得し、それらを使用時間別に分類するとともに、各使用時間に対応する装置数を求める。それにより、使用時間を変数とする、医用装置の装置数の分布が得られる。ここで、変数となる使用時間は、たとえば四捨五入により所定の単位時間毎（１時間単位等）に設定される。
【０１７０】
続いて、演算処理部２７は、上記障害発生頻度の場合と同様に、この使用時間毎の装置数の分布と、全医用装置３−１〜３−ｎの装置数に対する医用装置３（１）〜３（ｋ）の装置数の比率（ｋ／ｎ）とに基づき、全医用装置３−１〜３−ｎにおける使用時間の分布を推定することにより、医用ソフトウェア３１０の使用頻度（使用時間）の分布を推定する。以上が、使用時間に関する使用頻度の分布の推定処理の一例である。
【０１７１】
（分布推定処理の具体例）
ここで、演算処理部２７による上記の分布推定処理の具体例を、障害発生頻度の場合を取り上げて説明する。全医用装置３−１〜３−ｎの装置数をｎ＝１０００とし、一部の医用装置３（１）〜３（ｋ）の装置数をｋ＝１００とする。
【０１７２】
演算処理部２７は、一部の医用装置３（１）〜３（１００）のそれぞれからの発生頻度情報に基づいて、これら医用装置３（１）〜３（１００）における特定処理識別情報の個数の分布を求める。この分布において、特定処理識別情報の個数＝０（障害発生無し）に対応する装置数が０であり、個数＝１〜１０に対応する装置数がそれぞれ１０であったとする。
【０１７３】
演算処理部２７は、この分布における各特定処理識別情報の個数の値を、全医用装置３−１〜３−１０００の装置数に対する医用装置３（１）〜３（１００）の装置数の比率（１００／１０００＝０．１）で除算する。それによると、特定処理識別情報の個数＝０に対応する装置数＝０、個数＝１〜１０のそれぞれに対応する装置数＝１０／０．１＝１００が得られる。これが、全医用装置３−１〜３−１０００に関する分布の推定値である。
【０１７４】
〔送信開始日時決定部〕
送信開始日時決定部２３は、演算処理部２７により推定された障害発生頻度の分布や、医用ソフトウェア３１０の使用頻度の分布に基づいて、その分布における障害発生頻度の各値や使用頻度の各値（つまり、分布における変数の各値）について、障害修正用ソフトウェア２１０の送信開始日時を決定する。決定された送信開始日時は、送信開始日時情報２１６として情報格納部２１に格納される。
【０１７５】
（送信開始日時決定処理の具体例）
送信開始日時決定部２３が実行する処理を、障害発生頻度の場合を取り上げて、より具体的に説明する。情報格納部２１には、第１の実施形態と同様に、サーバ２による最大送信能力を示す配信可能装置数情報が格納されている（たとえば、配信可能装置数情報：Ｍ＝１００（装置／日）とする。）。
【０１７６】
また、全装置数ｎ＝１０００とし、全医用装置３−１〜３−１０００が配信先に設定されているものとする。この場合、これら１０００の医用装置３−１〜３−１０００に対して、１日１００装置ずつ、合計１０日に亘って配信を行うようにスケジュールが組まれる。
【０１７７】
また、演算処理部２７により推定された全医用装置３−１〜３−１０００に関する分布として、上記具体例の分布、すなわち、特定処理識別情報の個数＝０に対応する装置数＝０、個数＝１〜１０のそれぞれに対応する装置数＝１００を用いる。
【０１７８】
送信開始日時決定部２３は、まず、配信可能装置数情報（＝１００装置／日）と、配信先の全装置数（＝１０００装置）とに基づいて、全装置への配信に必要な日数を算出する（１０００÷１００＝１０日）。なお、算出結果が整数にならない場合については、第１の実施形態と同様に取り扱うことができる。
【０１７９】
次に、送信開始日時決定部２３は、算出された配信日数（１０日）を考慮して、推定された分布における各特定処理識別情報の個数について、個数の値の大きいものに早い日時を割り当てるようにして配信開始日時を決定する。本例では、特定処理識別情報の個数＝１０の１００装置の配信開始日時を配信第１日目（の例えば午前０時）に、個数＝９の１００装置の配信開始日時を配信第２日目（の例えば午前０時）に、個数＝８の１００装置の配信開始日時を配信第３日目（の例えば午前０時）に、・・・・、個数＝２の１００装置の配信開始日時を配信第９日目（の例えば午前０時）に、個数＝１の１００装置の配信開始日時を配信第１０日目（の例えば午前０時）に、それぞれ割り当てる。
【０１８０】
このように、本実施形態の送信開始日時情報２１６は、特定処理識別情報の個数（医用ソフトウェア３１０の使用回数、累積使用時間）と、配信（開始）日とを関連付けた情報として形成される。
【０１８１】
［システムの動作態様］
このような構成を備えるソフトウェア管理システム１００の動作態様の一例について説明する。なお、医用ソフトウェア３１０の動作状況の記録処理は、第１の実施形態と同様にして実行される（図６参照）。以下、障害修正用ソフトウェア２１０の配信スケジュールの決定処理、及び、障害修正用ソフトウェア２１０の配信処理について説明する。
【０１８２】
〔障害修正用ソフトウェアの配信スケジュール決定処理（障害発生頻度）：図１１〕
まず、医用ソフトウェア３１０の障害発生頻度に基づいて障害修正用ソフトウェア２１０の配信スケジュールを決定する処理について、図１１のフローチャートを参照しつつ説明する。
【０１８３】
準備段階として、新たに開発した障害修正用ソフトウェア２１０と、そのソフトウェアモジュール識別情報２１１と、障害特定情報３１２と、配信先リスト情報２１３とを、サーバ２の情報格納部２１に格納し、登録する（Ｓ４１）。
【０１８４】
サーバ２は、医用ソフトウェア３１０の障害発生頻度の確認を要求する要求信号と、障害特定情報２１２と、確認期間情報とを、広域ネットワークＮを通じて、一部の医用装置３（１）〜３（ｋ）にそれぞれ送信する（Ｓ４２）。
【０１８５】
医用装置３（１）〜３（ｋ）のそれぞれは、この要求信号に対応して送信情報作成部３３を動作させ、障害特定情報２１２と確認期間情報とに基づいて、障害の発生頻度情報を作成させるとともに、作成された発生頻度情報をサーバ２に送信する（Ｓ４３）。
【０１８６】
各医用装置３（１）〜３（ｋ）からの発生頻度情報を受信すると、サーバ２の演算処理部２７は、これら発生頻度情報に基づき、前述の要領で、全医用装置３−１〜３−ｎにおける障害の発生頻度の分布を推定する（Ｓ４４）。
【０１８７】
送信開始日時決定部２３は、推定された分布に基づき、前述の要領で、この分布における発生頻度のそれぞれの値について、障害修正用ソフトウェア２１０の送信開始日時を決定する（Ｓ４５）。
【０１８８】
制御部２０は、決定された送信開始日時を、送信開始日時情報２１６として情報格納部２１に格納する（Ｓ４６）。このとき、送信開始日時情報２１６は、障害修正用ソフトウェア２１０に関連付けられて格納される。以上で、医用ソフトウェア３１０の障害発生頻度に基づく障害修正用ソフトウェア２１０の配信スケジュール決定処理は終了となる。
【０１８９】
〔修正用ソフトウェアの配信処理：図１２〕
次に、医用装置３−１〜３−ｎに対する障害修正用ソフトウェア２１０の配信処理について、図１２のフローチャートを参照しつつ説明する。
【０１９０】
医用装置３は、所定のタイミングでサーバ２に送信要求信号を送信する（Ｓ５１）。サーバ２の制御部２０は、医用装置３を配信先とするアップデート用ソフトウェアの有無を確認する（Ｓ５２）。
【０１９１】
医用装置３に対するアップデート用ソフトウェアが無い場合には（Ｓ５３；Ｎ）、処理を終了する。このとき、アップデート用ソフトウェアが無い旨を示す信号を医用装置３に送信するようにしてもよい。
【０１９２】
一方、医用装置３に対するアップデート用ソフトウェアが有る場合（Ｓ５３；Ｙ）、サーバ２は、発生頻度情報の作成を要求する要求信号と、障害特定情報２１２と、確認期間情報とを医用装置３に送信する（Ｓ５４）。医用装置３は、要求に対応して送信情報作成部３３を動作させて発生頻度情報を作成させるとともに、作成された発生頻度情報をサーバ２に送信する（Ｓ５５）。
【０１９３】
サーバ２の制御部２０は、医用装置３からの発生頻度情報に示す特定処理識別情報の個数に対応する送信開始日時を、配信開始日時情報２１６から選択して日時判断部２４に送る（Ｓ５６）。このとき、計時部２５から日時判断部２４に現在日時が送られる。日時判断部２４は、この現在日時と送信開始日時とを比較し、現在日時が送信開始日時以降であるか否か、つまり送信開始日時を経過しか否かを判断する（Ｓ５７）。
【０１９４】
送信開始日時を経過していないと判断された場合には（Ｓ５８；Ｎ）、処理を終了する。このとき、アップデート用ソフトウェアが無い旨を示す信号を医用装置３に送信するようにしてもよい。
【０１９５】
一方、送信開始日時を経過していると判断された場合（Ｓ５８；Ｙ）、サーバ２は、情報格納部２１から障害修正用ソフトウェア２１０を読み出して医用装置３に送信する（Ｓ５９）。医用装置３は、この障害修正用ソフトウェア２１０をソフトウェア記憶部３１に記憶させ、医用ソフトウェア３１のアップデートを実行する（Ｓ６０）。以上で、障害修正用ソフトウェア２１０の配信処理は終了となる。
【０１９６】
〔障害修正用ソフトウェアの配信スケジュール決定処理（使用頻度）：図１３〕
次に、医用ソフトウェア３１０の使用頻度に基づいて障害修正用ソフトウェア２１０の配信スケジュールを決定する処理について、図１３のフローチャートを参照しつつ説明する。この処理において使用頻度情報の作成に用いられる情報（使用日時情報）は、医用ソフトウェア３１０の起動のログ情報や終了のログ情報である。以下、起動のログ情報に基づいて使用頻度情報を作成する場合を説明する。
【０１９７】
準備段階として、新たに開発した障害修正用ソフトウェア２１０等が登録される（Ｓ６１）。
【０１９８】
サーバ２は、医用ソフトウェア３１０の使用頻度の確認を要求する要求信号と確認期間情報とを、一部の医用装置３（１）〜３（ｋ）にそれぞれ送信する（Ｓ６２）。
【０１９９】
医用装置３（１）〜３（ｋ）のそれぞれは、この要求信号に対応して、使用頻度情報を作成し、サーバ２に送信する（Ｓ６３）。この使用頻度情報は、確認期間情報に示す所定の期間における医用ソフトウェア３１０の使用頻度（使用回数／使用時間）を示す情報である。
【０２００】
各医用装置３（１）〜３（ｋ）からの使用頻度情報を受信すると、サーバ２の演算処理部２７は、これら使用頻度情報に基づき、前述の要領で、全医用装置３−１〜３−ｎにおける使用頻度の分布を推定する（Ｓ６４）。
【０２０１】
送信開始日時決定部２３は、推定された分布に基づき、前述の要領で、この分布における使用頻度（使用回数／使用時間）のそれぞれの値について、障害修正用ソフトウェア２１０の送信開始日時を決定する（Ｓ６５）。
【０２０２】
制御部２０は、決定された送信開始日時を、送信開始日時情報２１６として情報格納部２１に格納する（Ｓ６６）。このとき、送信開始日時情報２１６は、障害修正用ソフトウェア２１０に関連付けられて格納される。以上で、医用ソフトウェア３１０の使用頻度に基づく障害修正用ソフトウェア２１０の配信スケジュール決定処理は終了となる。
【０２０３】
このように決定された配信スケジュールに基づく障害修正用ソフトウェア２１０の配信処理は、前述の図１２の場合と同様にして実行される。
【０２０４】
［作用効果］
本実施形態のソフトウェア管理システム１００が奏する作用効果について説明する。
【０２０５】
まず、このソフトウェア管理システム１００によれば、第１の実施形態のソフトウェア管理システム１と同様に、アップデートの緊急性や必要性の高い医用装置に対して優先的に障害修正用ソフトウェア２１０を送信できるとともに、サーバ容量の冗長化やネットワーク容量の拡大などのシステム負荷を増大させなくとも、配信処理の円滑化を図ることができる。
【０２０６】
また、本実施形態に特有の効果として、修正用ソフトウェア２１０の配信スケジュール決定処理の省力化を図ることができる。すなわち、本実施形態では、全ての医用装置３−１〜３−ｎにおける発生頻度情報や使用頻度情報を用いて配信スケジュールを決定する代わりに、一部の医用装置３（１）〜３（ｋ）の発生頻度情報や使用頻度情報に基づく障害発生頻度や使用頻度の分布を用いて、全医用装置３−１〜３−ｎにおける障害発生頻度や使用頻度の分布を推定するようになっている。そして、この推定された分布に基づいて、障害発生頻度や使用頻度の値毎に、送信開始日時を決定している。このように、全医用装置３−１〜３−ｎから発生頻度情報等を収集する必要がないため、配信スケジュール決定処理を効率的に行うことができる。特に、長期間に亘り使用されていない医用装置がある場合など、或る医用装置から発生頻度情報等を取得できないような場合であっても、本実施形態によれば、配信スケジュールを有効に決定することができる。
【０２０７】
〈第３の実施形態〉
図１４、図１５を参照しつつ、本発明に係るソフトウェア管理システムの第３の実施形態を説明する。図１４は、本システムの全体構成の一例を表すブロック図である。図１５は、本システムの動作態様の一例を表すフローチャートである。なお、第１の実施形態と同様の構成部分については、同じ符号を用いて説明することにする。
【０２０８】
［システム構成］
図１４に示すソフトウェア管理システム１０００は、第１の実施形態と同様に、サーバ２と、複数の医用装置３−１〜３−ｎとを備え、更に、ソフトウェア開発者が使用する開発者端末５を備えている。また、医用装置３（３−１）には、第１の実施形態と同様の外部装置４が接続されている。
【０２０９】
開発者端末５は、サーバ２と通信可能に構成されている。その通信態様としては、ＬＡＮ等のローカルネットワークによるものであってもよいし、インターネット等の広域ネットワークによるものであってもよく、また、無線通信であってもよいし、有線通信であってもよい。開発者端末５は、画面表示機能や音声出力機能を有する任意の端末装置によって構成され、たとえば携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）やノートパソコン等の任意のモバイル端末であってもよいし、デスクトップパソコン等の設置型の任意の端末であってもよい。また、後述の報知情報を受信する専用の端末であってもよい。なお、開発者端末５の台数は、１台に限定されるものではなく、たとえばソフトウェア開発者一人ひとりに対して設けるようにしてもよい。
【０２１０】
サーバ２は、制御部２０、情報格納部２１、通信部２６及び検索部２８を含んで構成される。情報格納部２１には、障害修正用ソフトウェア２１０と障害履歴情報２１７とがあらかじめ格納されている。障害履歴情報２１７は、過去に医用ソフトウェア３１０に発生した障害の履歴を表す情報であり、その障害に関連する特定の処理の特定処理識別情報（デバッグログ）と、その障害が発生したソフトウェアモジュールのソフトウェアモジュール識別情報とを含んでいる。なお、情報格納部２１には、複数の障害履歴情報２１７と、各障害履歴情報２１７に示す障害を修正する障害修正用ソフトウェア２１０とが格納されている。対応する障害修正用ソフトウェア２１０と障害履歴情報２１７は、所定の識別情報によって互いに関連付けられている。
【０２１１】
検索部２８は、本発明の「検索手段」の一例に相当し、後述のように医用装置３からデバッグログ等が送信されたときに、そのデバッグログ等と同一のデバッグログ情報等を含む障害履歴情報２１７を情報格納部２１から検索する処理を行う。この検索部２８は、ＣＰＵ等のマイクロプロセッサとＲＡＭ等のメモリとを含んで構成される。
【０２１２】
制御部２０には、配信制御部２００と報知制御部２０１とが設けられている。報知制御部２０１は、本発明の「報知制御手段」の一例に相当し、検索部２８によって障害履歴情報が検索されなかったことに対応して、所定の報知情報を開発者端末５に送信するように動作する。ここで、所定の報知情報は、たとえば「新たなソフトウェア障害が発生しました」等の文字情報や音声情報など、開発者端末５により出力可能な任意の形態の情報からなる。また、開発者端末５が、たとえば携帯電話等のバイブレーション機能を有する端末である場合には、開発者端末５の振動を報知情報として用いることも可能である。
【０２１３】
［システムの動作態様］
このような構成を備えるソフトウェア管理システム１０００の動作態様について説明する。図１５に示すフローチャートは、ソフトウェア管理システム１０００の動作態様の一例を表すものである。以下、このフローチャートを参照して説明する。
【０２１４】
医用装置３は、医用ソフトウェア３１０にしたがって処理を実行する度毎に、その処理のログ情報３２０を記録する（Ｓ７１）。医用ソフトウェア３１０の使用中に障害が発生すると、制御部３０がこれを検知する（Ｓ７２）。このとき、医用ソフトウェア３１０は、無応答状態となり、ユーザや全体制御モジュール３１１やオペレーティングシステムによって強制終了される（Ｓ７３）。
【０２１５】
全体制御モジュール３１１やオペレーティングシステムによって自動的に強制終了された場合（Ｓ７３；自動）、制御部３０は、自動で強制終了された旨のログ情報３２０を記録する（Ｓ７４）。一方、ユーザが手動で強制終了を行った場合には、手動で強制終了された旨のログ情報３２０を記録する（Ｓ７５）。
【０２１６】
医用装置３は、この障害に関するログ情報３２０をサーバ２に送信する（Ｓ７６）。このログ情報３２０には、障害発生の所定時間前から障害発生までの間に記録されたデバッグログ、各デバッグログのモジュール名（ソフトウェアモジュール識別情報）、強制終了のログ等が含まれる。
【０２１７】
サーバ２の検索部２８は、医用装置３からのログ情報３２０に含まれるデバッグログと同一のデバッグログ（特定処理識別情報）を含む障害履歴情報２１７を、情報格納部２１から検索する（Ｓ７７）。
【０２１８】
そのような障害履歴情報２１７が検索された場合（Ｓ７８；Ｙ）、検索された障害履歴情報２１７に関連付けられた障害修正用ソフトウェア２１０を特定し（Ｓ７９）、医用装置３に送信する（Ｓ８０）。医用装置３は、受信した障害修正用ソフトウェア２１０をソフトウェア格納部３１に格納し、医用ソフトウェア３１０をアップデートする（Ｓ８１）。この場合の処理は、これで終了となる。
【０２１９】
一方、障害履歴情報２１７が検索されなかった場合には（Ｓ７８；Ｎ）、報知制御部２０１が、通信部２６を制御して、所定の報知情報を開発者端末５に送信し、既存の障害修正用ソフトウェア２１０では対処できない新たな障害が発生した旨をソフトウェア開発者に通知する（Ｓ８２）。
【０２２０】
ソフトウェア開発者は、通知された報知情報を確認し、この新たな障害に対する障害修正用ソフトウェアの開発を行う（Ｓ８３）。その際、ログ情報３２０の解析などが行われる。新たに開発された障害修正用ソフトウェアは、新たな障害履歴情報とともに情報格納部２１に格納される（Ｓ８４）。以上で、この場合の処理は終了となる。なお、この新たな障害修正用ソフトウェアは、適宜のタイミングで医用装置３に送信されることとなる。
【０２２１】
［作用効果］
以上のような本実施形態に係るソフトウェア管理システム１０００によれば、次のような作用、効果が奏される。
【０２２２】
まず、このソフトウェア管理システム１０００の医用装置３は、医用ソフトウェア３１０に障害が発生したときに、その障害に関連するログ情報３２０をサーバ２に送信するようになっている。サーバ２は、医用装置３からのログ情報３２０に対応する障害履歴情報２１７を検索することにより、医用装置３に発生した障害の特定を行う。そして、検索された障害履歴情報２１７に関連付けられた障害修正用ソフトウェア２１０を医用装置３に送信して障害を修正させるように動作する。このように、ソフトウェア管理システム１０００によれば、医用ソフトウェア３１０に発生した障害の内容を的確に特定し、適当な障害修正用ソフトウェア２１０を医用装置３に送信し、障害を修正することができる。
【０２２３】
また、医用ソフトウェア３１０に発生した障害が新たな障害である場合には、この障害を修正する障害修正用ソフトウェア２は未だ開発されておらず、したがって、情報格納部２１にも格納されていない。このような場合、サーバ２は、開発者端末５に向けて報知情報を送信し、新たなソフトウェア障害が発生したことをソフトウェア開発者に通知するように作用する。それにより、ソフトウェア開発者は、新たな障害の発生を迅速に知ることができる。特に、障害修正の緊急度が高い場合などにおいて、障害修正用ソフトウェアの開発に迅速に取り掛かることができる。
【図面の簡単な説明】
【０２２４】
【図１】本発明に係るソフトウェア管理システムの第１の実施形態の構成の一例を表す概略ブロック図である。
【図２】本発明に係るソフトウェア管理システムの第１の実施形態の医用装置の動作を制御する医用ソフトウェアのソフトウェア構成の一例を表す概略図である。
【図３】本発明に係るソフトウェア管理システムの第１の実施形態の医用装置の動作状態を記録したログ情報の一例を表す図である。
【図４】本発明に係るソフトウェア管理システムの第１の実施形態の医用装置の動作状態を記録したログ情報の一例を表す図である。
【図５】本発明に係るソフトウェア管理システムの第１の実施形態の医用装置の動作状態を記録したログ情報の一例を表す図である。
【図６】本発明に係るソフトウェア管理システムの第１の実施形態の動作態様の一例を表すフローチャートである。
【図７】本発明に係るソフトウェア管理システムの第１の実施形態の動作態様の一例を表すフローチャートである。
【図８】本発明に係るソフトウェア管理システムの第１の実施形態の動作態様の一例を表すフローチャートである。
【図９】本発明に係るソフトウェア管理システムの第１の実施形態の動作態様の一例を表すフローチャートである。
【図１０】本発明に係るソフトウェア管理システムの第２の実施形態の構成の一例を表す概略ブロック図である。
【図１１】本発明に係るソフトウェア管理システムの第２の実施形態の動作態様の一例を表すフローチャートである。
【図１２】本発明に係るソフトウェア管理システムの第２の実施形態の動作態様の一例を表すフローチャートである。
【図１３】本発明に係るソフトウェア管理システムの第２の実施形態の動作態様の一例を表すフローチャートである。
【図１４】本発明に係るソフトウェア管理システムの第３の実施形態の構成の一例を表す概略ブロック図である。
【図１５】本発明に係るソフトウェア管理システムの第３の実施形態の動作態様の一例を表すフローチャートである。
【符号の説明】
【０２２５】
１、１００、１０００ ソフトウェア管理システム
２ サーバ
２０ 制御部
２００ 配信制御部
２０１ 報知制御部
２１ 情報格納部
２１０ 障害修正用ソフトウェア
２１１ ソフトウェアモジュール識別情報
２１２ 障害特定情報
２１３ 配信先リスト情報
２１４ 配信順序情報
２１５、２１６ 送信開始日時情報
２１７ 障害履歴情報
２２ 配信順序決定部
２３ 送信開始日時決定部
２４ 日時判断部
２５ 計時部
２６ 通信部
２７ 演算処理部
２８ 検索部
３、３−１〜３−ｎ 医用装置
３０ 制御部
３１ ソフトウェア記憶部
３１０ 医用ソフトウェア
３２ ログ記録部
３２０ ログ情報
３２１ 無応答ログ情報
３２２ 強制終了ログ情報
３２３ デバッグログ情報
３３ 送信情報作成部
３４ ユーザインターフェイス
３５ 通信部
４ 外部装置
５ 開発者端末
Ｎ 広域ネットワーク
【特許請求の範囲】
【請求項１】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段を備え、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記記録された動作状況情報に基づいて、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、
前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項２】
前記記録手段に記録された動作状況情報に基づいて、前記複数の医用装置のそれぞれの前記ソフトウェアにおける障害の発生頻度を示す発生頻度情報を作成する発生頻度情報作成手段を更に備え、
前記配信スケジュール決定手段は、前記複数の医用装置のそれぞれに対して、前記作成された発生頻度情報に示す障害の発生頻度の高い医用装置から順に前記配信順序を決定する、
ことを特徴とする請求項１に記載のソフトウェア管理システム。
【請求項３】
前記記録手段は、前記複数の医用装置のそれぞれについて、当該医用装置が前記ソフトウェアの障害に関連する特定の処理を実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを、前記動作状況情報として互いに関連付けて記録し、
前記発生頻度情報作成手段は、前記複数の医用装置のそれぞれについて、前記記録された前記特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして前記発生頻度情報を作成し、
前記配信スケジュール決定手段は、前記複数の医用装置のそれぞれについて前記作成された発生頻度情報に示す前記特定処理識別情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記配信順序を決定する、
ことを特徴とする請求項２に記載のソフトウェア管理システム。
【請求項４】
前記記録手段に記録された動作状況情報に基づいて、前記複数の医用装置のそれぞれにおける前記ソフトウェアの使用頻度を示す使用頻度情報を作成する使用頻度情報作成手段を更に備え、
前記配信スケジュール決定手段は、前記複数の医用装置のそれぞれに対して、前記作成された使用頻度情報に示す前記ソフトウェアの使用頻度の高い医用装置から順に前記配信順序を決定する、
ことを特徴とする請求項１に記載のソフトウェア管理システム。
【請求項５】
前記記録手段は、前記複数の医用装置のそれぞれについて、前記ソフトウェアが使用される度毎に、その使用日時を示す使用日時情報を前記動作状況情報として記録し、
前記使用頻度情報作成手段は、前記複数の医用装置のそれぞれについて、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして前記使用頻度情報を作成し、
前記配信スケジュール決定手段は、前記複数の医用装置のそれぞれについて前記作成された使用頻度情報に示す前記使用日時情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記配信順序を決定する、
ことを特徴とする請求項４に記載のソフトウェア管理システム。
【請求項６】
前記記録手段は、前記複数の医用装置のそれぞれについて、前記ソフトウェアが使用される度毎に、その使用日時を示す使用日時情報を前記動作状況情報として記録し、
前記使用頻度情報作成手段は、前記複数の医用装置のそれぞれについて、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して前記使用頻度情報を作成し、
前記配信スケジュール決定手段は、前記複数の医用装置のそれぞれについて前記作成された使用頻度情報に示す前記使用時間の値を比較し、前記複数の医用装置のそれぞれに対して、前記使用時間の値の大きい医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記配信順序を決定する、
ことを特徴とする請求項４に記載のソフトウェア管理システム。
【請求項７】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
前記ソフトウェアの障害に関連する特定の処理を当該医用装置が実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを、互いに関連付けて記録する記録手段と、
前記記録された前記特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして、前記ソフトウェアにおける障害の発生頻度情報を作成する発生頻度情報作成手段と、
を備え、
前記ソフトウェア配信サーバは、
前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記発生頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記発生頻度情報作成手段により作成された発生頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、
前記複数の医用装置のそれぞれから受信した前記発生頻度情報に示す前記特定処理識別情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、
前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項８】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、
前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、
を備え、
前記ソフトウェア配信サーバは、
前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、
前記複数の医用装置のそれぞれから受信した前記使用頻度情報に示す前記使用日時情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、
前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項９】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、
前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、
を備え、
前記ソフトウェア配信サーバは、
前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、
前記複数の医用装置のそれぞれから受信した前記使用頻度情報に示す前記使用時間の値を比較し、前記複数の医用装置のそれぞれに対して、前記使用時間の値の大きい医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、
前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項１０】
前記配信スケジュール決定手段は、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記配信スケジュール決定手段により決定された前記配信順序とに基づいて、前記複数の医用装置のそれぞれについて、当該医用装置に対する前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段を備える、
ことを特徴とする請求項１〜請求項９のいずれか一項に記載のソフトウェア管理システム。
【請求項１１】
前記複数の医用装置のそれぞれは、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、
前記ソフトウェア配信サーバは、前記複数の医用装置のいずれかにより送信された前記送信要求信号を受信したときに、現在日時が、当該医用装置の前記送信開始日時以降であるか判断する日時判断手段を更に備え、
前記配信制御手段は、前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する、
ことを特徴とする請求項１０に記載のソフトウェア管理システム。
【請求項１２】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段と、
前記複数の医用装置の一部からなる２以上の医用装置のそれぞれについて前記記録された動作状況情報に基づいて、前記２以上の医用装置のそれぞれの前記ソフトウェアにおける障害の発生頻度を示す発生頻度情報を作成する発生頻度情報作成手段と、
を備え、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記作成された前記２以上の医用装置のそれぞれの発生頻度情報に基づいて、前記複数の医用装置における前記障害の発生頻度の分布を推定する演算手段と、
前記推定された前記障害の発生頻度の分布に基づいて、該分布における前記発生頻度のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、
前記決定された送信開始日時に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
当該医用装置は、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項１３】
前記記録手段は、前記複数の医用装置のそれぞれについて、当該医用装置が前記ソフトウェアの障害に関連する特定の処理を実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを、前記動作状況情報として互いに関連付けて記録し、
前記発生頻度情報作成手段は、前記２以上の医用装置のそれぞれについて、前記記録された特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして前記発生頻度情報を作成し、
前記演算手段は、前記作成された発生頻度情報に基づいて、前記２以上の医用装置における前記特定処理識別情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記特定処理識別情報の個数の分布を推定することにより、前記発生頻度の分布を推定し、
前記送信開始日時決定手段は、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記特定処理識別情報の個数の分布とに基づいて、該分布における前記特定処置識別情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する、
ことを特徴とする請求項１２に記載のソフトウェア管理システム。
【請求項１４】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段と、
前記複数の医用装置の一部からなる２以上の医用装置のそれぞれについて前記記録された動作状況情報に基づいて、前記２以上の医用装置のそれぞれにおける前記ソフトウェアの使用頻度を示す使用頻度情報を作成する使用頻度情報作成手段と、
を備え、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記作成された前記２以上の医用装置のそれぞれの使用頻度情報に基づいて、前記複数の医用装置における前記ソフトウェアの使用頻度の分布を推定する演算手段と、
前記推定された前記使用頻度の分布に基づいて、該分布における前記使用頻度のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、
前記決定された送信開始日時に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
当該医用装置は、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項１５】
前記記録手段は、前記複数の医用装置のそれぞれについて、前記ソフトウェアが使用される度毎に、その使用日時を示す使用日時情報を前記動作状況情報として記録し、
前記使用頻度情報作成手段は、前記２以上の医用装置のそれぞれについて、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして前記使用頻度情報を作成し、
前記演算手段は、前記作成された使用頻度情報に基づいて、前記２以上の医用装置における前記使用日時情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用日時情報の個数の分布を推定することにより、前記使用頻度の分布を推定し、
前記送信開始日時決定手段は、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用日時情報の個数の分布とに基づいて、該分布における前記使用日時情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する、
ことを特徴とする請求項１４に記載のソフトウェア管理システム。
【請求項１６】
前記記録手段は、前記複数の医用装置のそれぞれについて、前記ソフトウェアが使用される度毎に、その使用日時を示す使用日時情報を前記動作状況情報として記録し、
前記使用頻度情報作成手段は、前記２以上の医用装置のそれぞれについて、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して前記使用頻度情報を作成し、
前記演算手段は、前記作成された使用頻度情報に基づいて、前記２以上の医用装置における前記使用時間の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用時間の分布を推定することにより、前記使用頻度の分布を推定し、
前記送信開始日時決定手段は、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用時間の分布とに基づいて、該分布における前記使用時間のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する、
ことを特徴とする請求項１４に記載のソフトウェア管理システム。
【請求項１７】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
当該医用装置が前記ソフトウェアの障害に関連する特定の処理を実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを互いに関連付けて記録する記録手段と、
前記記録された特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして、当該医用装置における前記障害の発生頻度情報を作成する発生頻度情報作成手段と、
を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記発生頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記発生頻度情報作成手段により作成された発生頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、
前記受信した前記発生頻度情報に基づいて、前記２以上の医用装置における前記特定処理識別情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記特定処理識別情報の個数の分布を推定する演算手段と、
前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記特定処理識別情報の個数の分布とに基づいて、該分布における前記特定処置識別情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、
前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された特定処理識別情報と特定処理日時情報とに基づいて前記発生頻度作成手段により作成される発生頻度情報に示す特定処理識別情報の個数の値を取得し、現在日時が、該取得された個数の値に対応する送信開始日時以降であるか判断する日時判断手段と、
前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、
を備え、
当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項１８】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、
前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、
を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、
前記受信した前記使用頻度情報に基づいて、前記２以上の医用装置における前記使用日時情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用日時情報の個数の分布を推定する演算手段と、
前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用日時情報の個数の分布とに基づいて、該分布における前記使用日時情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、
前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された使用日時情報に基づいて前記使用頻度作成手段により作成される使用頻度情報に示す使用日時情報の個数の値を取得し、現在日時が、該取得された個数の値に対応する送信開始日時以降であるか判断する日時判断手段と、
前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、
を備え、
当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項１９】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、
前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、
を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、
前記受信した前記使用頻度情報に基づいて、前記２以上の医用装置における前記使用時間の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用時間の分布を推定する演算手段と、
前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用時間の分布とに基づいて、該分布における前記使用時間のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、
前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された使用日時情報に基づいて前記使用頻度作成手段により作成される使用頻度情報に示す使用時間の値を取得し、現在日時が、該取得された使用時間の値に対応する送信開始日時以降であるか判断する日時判断手段と、
前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、
を備え、
当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項２０】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
前記ソフトウェアの障害に関連する特定の処理が実行される度毎に、該特定の処理を識別する特定処理識別情報を記録する記録手段と、
前記ソフトウェアに障害が発生したときに、該障害の発生日時の所定時間前から該発生日時までの間に前記記録された特定処理識別情報を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信する特定処理識別情報送信手段と、
を備え、
前記ソフトウェア配信サーバは、
過去に前記ソフトウェアに発生した障害に関連する特定の処理の特定処理識別情報を含む障害履歴情報と、当該障害を修正するアップデート用ソフトウェアとを、互いに関連付けてあらかじめ格納する格納手段と、
前記複数の医用装置のいずれかにより送信された前記特定処理識別情報を受信する受信手段と、
前記受信された特定処理識別情報と同一の特定処理識別情報を含む障害履歴情報を前記格納手段から検索する検索手段と、
障害履歴情報が前記検索された場合に、該検索された障害履歴情報に関連付けられたアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信する配信制御手段と、
を備え、
前記複数の医用装置のそれぞれは、前記配信されたアップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項２１】
アップデート用ソフトウェアの開発者により使用される開発者端末を更に備え、
前記ソフトウェア配信サーバは、前記検索手段により障害履歴情報が検索されなかった場合に、所定の報知情報を前記開発者端末に送信する報知制御手段を更に備える、
ことを特徴とする請求項２０に記載のソフトウェア管理システム。
【請求項１】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段を備え、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記記録された動作状況情報に基づいて、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、
前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項２】
前記記録手段に記録された動作状況情報に基づいて、前記複数の医用装置のそれぞれの前記ソフトウェアにおける障害の発生頻度を示す発生頻度情報を作成する発生頻度情報作成手段を更に備え、
前記配信スケジュール決定手段は、前記複数の医用装置のそれぞれに対して、前記作成された発生頻度情報に示す障害の発生頻度の高い医用装置から順に前記配信順序を決定する、
ことを特徴とする請求項１に記載のソフトウェア管理システム。
【請求項３】
前記記録手段は、前記複数の医用装置のそれぞれについて、当該医用装置が前記ソフトウェアの障害に関連する特定の処理を実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを、前記動作状況情報として互いに関連付けて記録し、
前記発生頻度情報作成手段は、前記複数の医用装置のそれぞれについて、前記記録された前記特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして前記発生頻度情報を作成し、
前記配信スケジュール決定手段は、前記複数の医用装置のそれぞれについて前記作成された発生頻度情報に示す前記特定処理識別情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記配信順序を決定する、
ことを特徴とする請求項２に記載のソフトウェア管理システム。
【請求項４】
前記記録手段に記録された動作状況情報に基づいて、前記複数の医用装置のそれぞれにおける前記ソフトウェアの使用頻度を示す使用頻度情報を作成する使用頻度情報作成手段を更に備え、
前記配信スケジュール決定手段は、前記複数の医用装置のそれぞれに対して、前記作成された使用頻度情報に示す前記ソフトウェアの使用頻度の高い医用装置から順に前記配信順序を決定する、
ことを特徴とする請求項１に記載のソフトウェア管理システム。
【請求項５】
前記記録手段は、前記複数の医用装置のそれぞれについて、前記ソフトウェアが使用される度毎に、その使用日時を示す使用日時情報を前記動作状況情報として記録し、
前記使用頻度情報作成手段は、前記複数の医用装置のそれぞれについて、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして前記使用頻度情報を作成し、
前記配信スケジュール決定手段は、前記複数の医用装置のそれぞれについて前記作成された使用頻度情報に示す前記使用日時情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記配信順序を決定する、
ことを特徴とする請求項４に記載のソフトウェア管理システム。
【請求項６】
前記記録手段は、前記複数の医用装置のそれぞれについて、前記ソフトウェアが使用される度毎に、その使用日時を示す使用日時情報を前記動作状況情報として記録し、
前記使用頻度情報作成手段は、前記複数の医用装置のそれぞれについて、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して前記使用頻度情報を作成し、
前記配信スケジュール決定手段は、前記複数の医用装置のそれぞれについて前記作成された使用頻度情報に示す前記使用時間の値を比較し、前記複数の医用装置のそれぞれに対して、前記使用時間の値の大きい医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記配信順序を決定する、
ことを特徴とする請求項４に記載のソフトウェア管理システム。
【請求項７】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
前記ソフトウェアの障害に関連する特定の処理を当該医用装置が実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを、互いに関連付けて記録する記録手段と、
前記記録された前記特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして、前記ソフトウェアにおける障害の発生頻度情報を作成する発生頻度情報作成手段と、
を備え、
前記ソフトウェア配信サーバは、
前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記発生頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記発生頻度情報作成手段により作成された発生頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、
前記複数の医用装置のそれぞれから受信した前記発生頻度情報に示す前記特定処理識別情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、
前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項８】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、
前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、
を備え、
前記ソフトウェア配信サーバは、
前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、
前記複数の医用装置のそれぞれから受信した前記使用頻度情報に示す前記使用日時情報の個数を比較し、前記複数の医用装置のそれぞれに対して、前記個数の多い医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、
前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項９】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、
前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、
を備え、
前記ソフトウェア配信サーバは、
前記アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記複数の医用装置のそれぞれから受信する受信手段と、
前記複数の医用装置のそれぞれから受信した前記使用頻度情報に示す前記使用時間の値を比較し、前記複数の医用装置のそれぞれに対して、前記使用時間の値の大きい医用装置から順に前記アップデート用ソフトウェアを送信する順位を指定することにより、前記複数の医用装置に対する前記アップデート用ソフトウェアの配信順序を決定する配信スケジュール決定手段と、
前記決定された配信順序に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
前記複数の医用装置のそれぞれは、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項１０】
前記配信スケジュール決定手段は、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記配信スケジュール決定手段により決定された前記配信順序とに基づいて、前記複数の医用装置のそれぞれについて、当該医用装置に対する前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段を備える、
ことを特徴とする請求項１〜請求項９のいずれか一項に記載のソフトウェア管理システム。
【請求項１１】
前記複数の医用装置のそれぞれは、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、
前記ソフトウェア配信サーバは、前記複数の医用装置のいずれかにより送信された前記送信要求信号を受信したときに、現在日時が、当該医用装置の前記送信開始日時以降であるか判断する日時判断手段を更に備え、
前記配信制御手段は、前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する、
ことを特徴とする請求項１０に記載のソフトウェア管理システム。
【請求項１２】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段と、
前記複数の医用装置の一部からなる２以上の医用装置のそれぞれについて前記記録された動作状況情報に基づいて、前記２以上の医用装置のそれぞれの前記ソフトウェアにおける障害の発生頻度を示す発生頻度情報を作成する発生頻度情報作成手段と、
を備え、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記作成された前記２以上の医用装置のそれぞれの発生頻度情報に基づいて、前記複数の医用装置における前記障害の発生頻度の分布を推定する演算手段と、
前記推定された前記障害の発生頻度の分布に基づいて、該分布における前記発生頻度のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、
前記決定された送信開始日時に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
当該医用装置は、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項１３】
前記記録手段は、前記複数の医用装置のそれぞれについて、当該医用装置が前記ソフトウェアの障害に関連する特定の処理を実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを、前記動作状況情報として互いに関連付けて記録し、
前記発生頻度情報作成手段は、前記２以上の医用装置のそれぞれについて、前記記録された特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして前記発生頻度情報を作成し、
前記演算手段は、前記作成された発生頻度情報に基づいて、前記２以上の医用装置における前記特定処理識別情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記特定処理識別情報の個数の分布を推定することにより、前記発生頻度の分布を推定し、
前記送信開始日時決定手段は、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記特定処理識別情報の個数の分布とに基づいて、該分布における前記特定処置識別情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する、
ことを特徴とする請求項１２に記載のソフトウェア管理システム。
【請求項１４】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれについて、前記ソフトウェアの動作状況を示す動作状況情報を記録する記録手段と、
前記複数の医用装置の一部からなる２以上の医用装置のそれぞれについて前記記録された動作状況情報に基づいて、前記２以上の医用装置のそれぞれにおける前記ソフトウェアの使用頻度を示す使用頻度情報を作成する使用頻度情報作成手段と、
を備え、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記作成された前記２以上の医用装置のそれぞれの使用頻度情報に基づいて、前記複数の医用装置における前記ソフトウェアの使用頻度の分布を推定する演算手段と、
前記推定された前記使用頻度の分布に基づいて、該分布における前記使用頻度のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、
前記決定された送信開始日時に基づいて、前記複数の医用装置に前記アップデート用ソフトウェアを配信する配信制御手段と、
を備え、
当該医用装置は、前記配信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項１５】
前記記録手段は、前記複数の医用装置のそれぞれについて、前記ソフトウェアが使用される度毎に、その使用日時を示す使用日時情報を前記動作状況情報として記録し、
前記使用頻度情報作成手段は、前記２以上の医用装置のそれぞれについて、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして前記使用頻度情報を作成し、
前記演算手段は、前記作成された使用頻度情報に基づいて、前記２以上の医用装置における前記使用日時情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用日時情報の個数の分布を推定することにより、前記使用頻度の分布を推定し、
前記送信開始日時決定手段は、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用日時情報の個数の分布とに基づいて、該分布における前記使用日時情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する、
ことを特徴とする請求項１４に記載のソフトウェア管理システム。
【請求項１６】
前記記録手段は、前記複数の医用装置のそれぞれについて、前記ソフトウェアが使用される度毎に、その使用日時を示す使用日時情報を前記動作状況情報として記録し、
前記使用頻度情報作成手段は、前記２以上の医用装置のそれぞれについて、前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して前記使用頻度情報を作成し、
前記演算手段は、前記作成された使用頻度情報に基づいて、前記２以上の医用装置における前記使用時間の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用時間の分布を推定することにより、前記使用頻度の分布を推定し、
前記送信開始日時決定手段は、前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用時間の分布とに基づいて、該分布における前記使用時間のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する、
ことを特徴とする請求項１４に記載のソフトウェア管理システム。
【請求項１７】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
当該医用装置が前記ソフトウェアの障害に関連する特定の処理を実行する度毎に、該特定の処理を識別する特定処理識別情報と、該特定の処理が実行された日時を示す特定処理日時情報とを互いに関連付けて記録する記録手段と、
前記記録された特定処理識別情報のうち、所定の期間に属する日時を示す特定処理日時情報に関連付けられた特定処理識別情報の個数をカウントして、当該医用装置における前記障害の発生頻度情報を作成する発生頻度情報作成手段と、
を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記発生頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記発生頻度情報作成手段により作成された発生頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、
前記受信した前記発生頻度情報に基づいて、前記２以上の医用装置における前記特定処理識別情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記特定処理識別情報の個数の分布を推定する演算手段と、
前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記特定処理識別情報の個数の分布とに基づいて、該分布における前記特定処置識別情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、
前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された特定処理識別情報と特定処理日時情報とに基づいて前記発生頻度作成手段により作成される発生頻度情報に示す特定処理識別情報の個数の値を取得し、現在日時が、該取得された個数の値に対応する送信開始日時以降であるか判断する日時判断手段と、
前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、
を備え、
当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項１８】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、
前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報の個数をカウントして、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、
を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、
前記受信した前記使用頻度情報に基づいて、前記２以上の医用装置における前記使用日時情報の個数の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用日時情報の個数の分布を推定する演算手段と、
前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用日時情報の個数の分布とに基づいて、該分布における前記使用日時情報の個数のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、
前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された使用日時情報に基づいて前記使用頻度作成手段により作成される使用頻度情報に示す使用日時情報の個数の値を取得し、現在日時が、該取得された個数の値に対応する送信開始日時以降であるか判断する日時判断手段と、
前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、
を備え、
当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項１９】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
当該医用装置が前記ソフトウェアを使用する度毎に、その使用日時を示す使用日時情報を記録する記録手段と、
前記記録された使用日時情報のうち、所定の期間に属する使用日時を示す使用日時情報に基づいて、当該所定の期間における前記ソフトウェアの使用時間を算出して、当該医用装置における前記ソフトウェアの使用頻度情報を作成する使用頻度情報作成手段と、
を備え、アップデート用ソフトウェアの送信を要求する送信要求信号を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信し、
前記ソフトウェア配信サーバは、
アップデート用ソフトウェアをあらかじめ格納する格納手段と、
前記使用頻度情報作成手段の動作を要求する要求信号を、前記広域ネットワークを通じて、前記複数の医用装置の一部からなる２以上の医用装置のそれぞれに送信する送信手段と、
前記送信された要求信号に対応して前記使用頻度情報作成手段により作成された使用頻度情報を、前記広域ネットワークを通じて、前記２以上の医用装置のそれぞれから受信する受信手段と、
前記受信した前記使用頻度情報に基づいて、前記２以上の医用装置における前記使用時間の分布を求めるとともに、該求められた分布と、前記複数の医用装置の装置数に対する前記２以上の医用装置の装置数の比率とに基づいて、前記複数の医用装置における前記使用時間の分布を推定する演算手段と、
前記複数の医用装置の装置数と、所定時間内にアップデート用ソフトウェアを送信可能な医用装置の最大装置数を示すあらかじめ設定された配信可能装置数情報と、前記推定された前記使用時間の分布とに基づいて、該分布における前記使用時間のそれぞれの値について、前記アップデート用ソフトウェアの送信開始日時を決定する送信開始日時決定手段と、
前記複数の医用装置のいずれかにより送信された前記送信要求信号が受信されたときに、当該医用装置の前記記録手段に記録された使用日時情報に基づいて前記使用頻度作成手段により作成される使用頻度情報に示す使用時間の値を取得し、現在日時が、該取得された使用時間の値に対応する送信開始日時以降であるか判断する日時判断手段と、
前記現在日時が前記送信開始日以降であると前記判断された場合にのみ、当該医用装置に前記アップデート用ソフトウェアを送信する配信制御手段と、
を備え、
当該医用装置は、前記送信された前記アップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項２０】
広域ネットワークにそれぞれ接続され、ソフトウェアを記憶するソフトウェア記憶手段をそれぞれに備え、該記憶されたソフトウェアによりそれぞれ制御される複数の医用装置と、
前記広域ネットワークに接続され、前記ソフトウェアに発生した障害を修正するアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信するソフトウェア配信サーバと、
を含むソフトウェア管理システムであって、
前記複数の医用装置のそれぞれは、
前記ソフトウェアの障害に関連する特定の処理が実行される度毎に、該特定の処理を識別する特定処理識別情報を記録する記録手段と、
前記ソフトウェアに障害が発生したときに、該障害の発生日時の所定時間前から該発生日時までの間に前記記録された特定処理識別情報を、前記広域ネットワークを通じて、前記ソフトウェア配信サーバに送信する特定処理識別情報送信手段と、
を備え、
前記ソフトウェア配信サーバは、
過去に前記ソフトウェアに発生した障害に関連する特定の処理の特定処理識別情報を含む障害履歴情報と、当該障害を修正するアップデート用ソフトウェアとを、互いに関連付けてあらかじめ格納する格納手段と、
前記複数の医用装置のいずれかにより送信された前記特定処理識別情報を受信する受信手段と、
前記受信された特定処理識別情報と同一の特定処理識別情報を含む障害履歴情報を前記格納手段から検索する検索手段と、
障害履歴情報が前記検索された場合に、該検索された障害履歴情報に関連付けられたアップデート用ソフトウェアを、前記広域ネットワークを通じて、前記複数の医用装置に配信する配信制御手段と、
を備え、
前記複数の医用装置のそれぞれは、前記配信されたアップデート用ソフトウェアにより前記ソフトウェアのアップデートを行う、
ことを特徴とするソフトウェア管理システム。
【請求項２１】
アップデート用ソフトウェアの開発者により使用される開発者端末を更に備え、
前記ソフトウェア配信サーバは、前記検索手段により障害履歴情報が検索されなかった場合に、所定の報知情報を前記開発者端末に送信する報知制御手段を更に備える、
ことを特徴とする請求項２０に記載のソフトウェア管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２００７−１６４３７１（Ｐ２００７−１６４３７１Ａ）
【公開日】平成１９年６月２８日（２００７．６．２８）
【国際特許分類】
【出願番号】特願２００５−３５８１５１（Ｐ２００５−３５８１５１）
【出願日】平成１７年１２月１２日（２００５．１２．１２）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（５９４１６４５４２）東芝メディカルシステムズ株式会社 (4,066)
【Ｆターム（参考）】
【公開日】平成１９年６月２８日（２００７．６．２８）
【国際特許分類】
【出願日】平成１７年１２月１２日（２００５．１２．１２）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（５９４１６４５４２）東芝メディカルシステムズ株式会社 (4,066)
【Ｆターム（参考）】
[ Back to top ]