JP2013214295A - 医用画像処理システム - Google Patents

Abstract

【課題】画像処理の予約に基づき非定常負荷の発生を予測可能とした医用画像処理システムを提供する。
【解決手段】医用画像処理システムは、予約管理部と、処理量算出部と、解析部と、依頼部と、を含んで構成される。予約管理部は、予約された画像処理の処理開始時間及び処理終了時間と、画像処理の処理対象である医用画像のデータ量とを管理する。処理量算出部は、第１のサーバーで実行される各画像処理について、当該画像処理において所定の時間幅あたりに処理される処理量を算出する。解析部は、時間幅ごとに、並列で実行される画像処理の処理量の合計を算出する。また、解析部は、算出された合計が所定の処理量以上の場合に、第１のサーバーの処理量の合計が所定の処理量未満となるように、当該時間幅中に実行される画像処理のうち少なくとも１つを、第２のサーバーに依頼する第１の画像処理として特定する。
【選択図】図１

Description

本発明の実施形態は、医用画像撮影装置により取得された医用画像の画像データを処理する医用画像処理システムの技術に関する。

医用画像撮影装置（モダリティともいう）により患者を撮影して得られる医用画像の画像データは、画像処理を施すことで表示部に画像として表示することが可能となる。医用画像撮影装置としては、例えば、超音波診断装置、Ｘ線診断装置、ＭＲＩ装置（Ｍａｇｎｅｔｉｃ Ｒｅｓｏｎａｎｃｅ Ｉｍａｇｉｎｇ）、Ｘ線ＣＴ装置等が挙げられる。このような医用画像撮影装置と、画像データに対して画像処理を施す画像処理部を備えたサーバーを含む医用画像処理システムがある。

画像データに画像処理を施すサーバーは、自身の処理能力（例えば、ＣＰＵの処理能力やメモリ等）の許容範囲で複数の画像処理を並列に実行することで、複数の画像処理の処理時間を短縮している。

一方で１台のサーバーで実行できる画像処理の処理量は、そのサーバーの処理能力により制限される。そのため、システム全体に要求される画像処理の処理量が、１台のサーバーの処理量を上回る場合には、複数のサーバーで画像処理を分担する方法が用いられる場合がある。こうすることで、各サーバーに対する処理負荷を軽減し、同時に実行可能な最大処理量を高くすることが可能となる。

複数のサーバーで画像処理を分担する場合には、撮影装置による撮影の予約数（予約された撮影の回数）の想定値や、取得される画像データのデータ量の想定値に基づき最大処理量を見積り、この最大処理量に応じて設置するサーバー数を決定する。

しかしながら、撮影の予約数や、撮影される画像データのデータ量は必ずしも一定ではない。例えば、撮影の予約が集中する時期や時間帯には、システムに要求される処理量が一時的に増大する。また、画像データのデータ量は検査の条件により異なるため、例えば、画像サイズが大きい撮影、または、撮影枚数が多い撮影を伴う検査が集中する場合には、システムで要求される処理量が一時的に増大する。従来の方法では、このような非定常時の負荷（以下、「非定常負荷」と呼ぶ）も含めて最大処理量を見積り、必要に応じてサーバーを増設していた。

しかしながら、非定常負荷の発生頻度が少ない場合には、これを想定して増設したサーバーのリソースを有効に利用できず、サーバーの増設による費用対効果が低くなる。また非定常負荷は、撮影の予約数や撮影時の条件等の不確定な要素に起因するため、正確な値をあらかじめ予測することが難しい。

特開２００９−２５８７７７号公報

この発明の実施形態は、非定常負荷の発生を予測可能とした医用画像処理システムを提供することを目的とする。

上記目的を達成するために、この実施形態の態様は、医用画像の画像データに対する画像処理を複数並列に実行する画像処理部を備えたサーバーを複数備えた医用画像処理システムである。医用画像処理システムは、予約管理部と、処理量算出部と、解析部と、依頼部と、を含んで構成される。予約管理部は、画像処理の処理予約を受けて、予約された画像処理の処理開始時間及び処理終了時間と、当該画像処理の処理対象である画像データのデータ量とを当該処理予約に基づき画像処理ごとに管理する。処理量算出部は、複数のサーバーのうち第１のサーバーで実行される各画像処理について、処理開始時間及び処理終了時間と、データ量とを基に、当該画像処理において所定の時間幅あたりに処理される処理量を算出する。解析部は、第１のサーバーで実行される画像処理の処理開始時間及び処理終了時間と、当該画像処理の処理量とに基づき、時間幅ごとに、当該時間幅中に並列で実行される画像処理の処理量の合計を算出する。また、解析部は、算出された合計が所定の処理量以上の場合に、第１のサーバーの処理量の合計が所定の処理量未満となるように、当該時間幅中に実行される画像処理のうち少なくとも１つを含む第１の画像処理を特定する。依頼部は、第１のサーバーとは異なる第２のサーバーに第１の画像処理を依頼する。

本実施形態に係る医用画像処理システムのブロック図である。 予約管理部及び解析部の詳細な構成を示したブロック図である。 画像データに対する処理の流れに着目した医用画像処理システムのブロック図である。 検査の予約を管理する予約管理テーブルの一例である。 画像処理種別と実行される処理との対応関係を管理する管理テーブルの一例である。 画像処理ごとの処理時間を管理するための管理テーブルの一例である。 画像処理の処理開始時間及び処理終了時間を管理するための処理管理テーブルの一例である。 第１の実施形態における画像処理の処理スケジュールの一例である。 負荷予測データの一例である。 負荷予測データの一例である。 第１の実施形態に係る依頼情報のデータ構造の一例を示している。 本実施形態に係る画像データのデータ構造の一例である。 補助サーバーに依頼する画像処理を特定し、その画像処理を依頼するまでの一連の動作を示したフローチャートである。 変形例１に係る依頼情報のデータ構造の一例である。 機能管理テーブルの一例である。 第２の実施形態における画像処理の処理スケジュールの一例である。 第２の実施形態における予約管理テーブルの一例である 第２の実施形態における処理管理テーブルの一例である。 第２の実施形態に係る負荷予測データの一例である。 第３の実施形態に係る負荷確認部の一例である。 第３の実施形態に係る負荷確認部の変形例である。

（第１の実施形態）
第１の実施形態に係る医用画像処理システムについて、図１〜図３を参照しながら説明する。図１に示すように、本実施形態に係る医用画像処理システムは、予約管理部１１と、処理量算出部１２と、解析部１３と、処理制御部１４と、複数の撮影部（撮影部１５Ａ及び１５Ｂ）と、画像記憶部１６と、依頼部１７と、複数のサーバー（即ち、サーバー２Ａ〜２Ｄ）と、複数の端末（端末３Ａ〜３Ｃ）とを含んで構成されている。

サーバー２Ａ〜２Ｄは、画像データに対する画像処理を実行するためのサーバーである。サーバー２Ａ〜２Ｄの詳細な構成については後述する。また、端末３Ａ〜３Ｃは、サーバー２Ａ〜２Ｄでの画像処理の結果を受けて、画像データを表示部（図示しない）に表示させるための端末ある。なお、以降では、サーバー２Ａ〜２Ｄを特に区別しない場合には、単に「サーバー２」と表記する場合がある。同様に、端末３Ａ〜３Ｃを特に区別しない場合には、単に「端末３」と表記する場合がある。

サーバー２Ａ及び２Ｂは、依頼部１７とネットワークＮ１１を介して接続されている。また、サーバー２Ａ及び２Ｂは、端末３Ａ〜３ＣとネットワークＮ１２を介して接続されている。同様に、サーバー２Ｃ及び２Ｄは、依頼部１７とネットワークＮ２１を介して接続されている。また、サーバー２Ｃ及び２Ｄは、端末３Ａ〜３ＣとネットワークＮ２２を介して接続されている。このようにサーバー２Ａ及び２Ｂと、サーバー２Ｃ及び２Ｄとが、異なるネットワークＮ１１及びＮ１２と、Ｎ２１及びＮ２２とを介して、依頼部１７及び端末３Ａ〜３Ｃと接続されている。具体的な一例として、ネットワークＮ１１及びＮ１２が、病院内の院内ネットワークを示しており、ネットワークＮ２１及びＮ２２が病院の外部の施設へのネットワークを示している。なお、上記は一例であり、ネットワークＮ１１及びＮ１２を一つのネットワークとして構築してもよい。同様に、ネットワークＮ２１及びＮ２２を一つのネットワークとして構築してもよい。また、ネットワークＮ１１及びＮ１２と、ネットワークＮ２１及びＮ２２とを区別せずに一つのネットワークとして構築してもよい。以降では、ネットワークＮ１１、Ｎ１２、Ｎ２１、及びＮ２２がそれぞれ独立して設けられているものとして説明する。

本実施形態における医用画像処理システムでは、ネットワークＮ１１及びＮ１２に接続されたサーバー２Ａ及び２Ｂをメインのサーバー（以降は、「メインサーバー」と呼ぶ場合がある）とし、ネットワークＮ２１及びＮ２２に接続されたサーバー２Ｃ及び２Ｄを補助的な役割（以降は「補助サーバー」と呼ぶ場合がある）として動作させる。具体的には、画像処理は主にメインサーバーが実行し、処理負荷が高くなりメインサーバーの処理能力を超える場合に、補助サーバーが一部の画像処理を代行する。以降では、このメインサーバー（サーバー２Ａまたは２Ｂ）の処理負荷の予測と、予測された処理負荷がメインサーバーの処理能力を超える場合に、補助サーバー（サーバー２Ｃまたは２Ｄ）に一部の画像処理を代行させる仕組みについて説明する。

撮影部１５Ａ及び１５Ｂは、画像データを撮影する医用画像撮影装置である。撮影部１５Ａ及び１５Ｂで画像データを撮影するための撮影予約は、予約管理部１１で受け付けられ管理される。また、撮影部１５Ａ及び１５Ｂの動作は、予約管理部１１で受付けられた撮影予約に基づき、処理制御部１４により制御される。予約管理部１１及び処理制御部１４については後述する。なお、以降では、撮影部１５Ａ及び１５Ｂを特に区別しない場合には、単に「撮影部１５」と表記する場合がある。撮影部１５は、撮影された画像データを依頼部１７に出力される。依頼部１７については後述する。

画像記憶部１６は、画像データを記憶する記憶部である。画像記憶部１６には、あらかじめ撮影された画像データが記憶されている。

（予約管理部１１）
ここで図２を参照する。図２に示すように、予約管理部１１は、予約受付部１１１と、処理条件特定部１１２とを含んで構成される。

（予約受付部１１１）
予約受付部１１１は、撮影部１５Ａまたは１５Ｂによる画像データの撮影に係る検査予約を操作者から受け付ける。図４は、予約受付部１１１が、検査予約を管理するための予約管理テーブルＴＢＬ１０の一例である。図４に示すように、予約管理テーブルＴＢＬ１０で管理・記憶される検査予約には、例えば、検査識別子Ｃ１１と、撮影部識別子Ｃ１２と、検査開始時間Ｃ１３と、検査終了時間Ｃ１４と、画像処理種別Ｃ１５と、画像サイズＣ１６と、枚数Ｃ１７と、返却先Ｃ１８とが情報として含まれている。予約受付部１１１は、これらの情報を予約として操作者から受け、予約管理テーブルＴＢＬ１０を作成する。検査識別子Ｃ１１は、検査を識別するための識別子であり、各検査予約は検査識別子Ｃ１１により識別される。撮影部識別子Ｃ１２は、画像データを撮影する撮影部１５の識別子（例えば撮影部１５Ａまたは１５Ｂ）を示している。また、検査開始時間Ｃ１３及び検査終了時間Ｃ１４は、その検査が開始される時間と終了予定の時間を示している。画像処理種別Ｃ１５は、画像データに対する画像処理の種別を識別するための識別子である。画像処理種別Ｃ１５の詳細については後述する。画像サイズＣ１６は、画像データに含まれる画像１枚分のサイズを示しており、このサイズにより画像１枚のデータ量が特定される。画像のサイズとしては、例えば、画像の色数（ビット数）、画像の面積（画像の幅及び高さ）等の情報を含む。枚数Ｃ１７は、画像データの枚数を表している。画像サイズＣ１６と枚数Ｃ１７とにより、画像処理の対象となる画像データのデータ量の合計が特定される。返却先Ｃ１８は、画像データの最終的な出力先を示している。例えば、撮影された画像データを画像として表示させる場合、この返却先Ｃ１８には、その画像を表示させる端末の識別子が入力される。

例えば、検査ａは、撮影部１５Ａで画像データを撮影することを示しており、時間Ｔａ１〜Ｔａ２までを検査時間としている。また、条件Ｐ１１で定義されたサイズの画像データＮａ枚に対し、種別Ｍ１１で示された画像処理を施すことを示している。

また、予約管理テーブルＴＢＬ１０は、あらかじめ撮影され画像記憶部１６に記憶された画像データに対する画像処理の予約をあわせて管理・記憶可能に構成してもよい。例えば、検査ｃは、画像記憶部１６に記憶された画像データの画像処理に関する。この場合には、予約受付部１１１は、画像処理の対象である画像データのファイル名と、画像処理種別Ｃ１５と、画像処理の処理開始時間及び処理終了時間を受け付ける。この場合、撮影部１５による撮影を伴わないため、予約受付部１１１は、検査ｃの検査予約に撮影部識別子Ｃ１２の情報を入力せず、替わりに画像データを特定するためのファイル名Ｃ１９を入力する。また、予約受付部１１１は、検査の開始時間及び終了時間の替わりに、画像処理の処理開始時間及び処理終了時間を、検査開始時間Ｃ１３及び検査終了時間Ｃ１４に入力する。画像処理の対象となる画像データは、既に、画像記憶部１６に記憶されている。そのため、予約受付部１１１は、ファイル名Ｃ１９を基に画像記憶部１６から画像データを特定し、特定された画像データから画像サイズＣ１６及び枚数Ｃ１７を読み出して予約管理テーブルＴＢＬ１０に入力する。

次に、画像処理種別Ｃ１５について、図５を参照しながら説明する。画像データに対する画像処理は、出力する画像の態様に応じて異なる処理が実行される。予約受付部１１１は、一例として、このような画像処理を種別ごとに、あらかじめ分類された情報として記憶している。このような分類は、操作者があらかじめ行っておけばよい。例えば図５は、画像処理種別Ｃ１５と実行される処理との対応関係を管理する管理テーブルＴＢＬ２０の一例である。画像データは、撮影部（具体的には、撮影部のモダリティ）によりデータの内容や、実行される画像処理の内容が異なる。そのため、予約受付部１１１は、管理テーブルＴＢＬ２０により、この対応関係を画像処理種別Ｃ１５ごとに管理・記憶している。なお、予約受付部１１１は、管理テーブルＴＢＬ２０を、後述する処理量算出部１２及び解析部１３が参照可能にしている。または、管理テーブルＴＢＬ２０を記憶する記憶部を別途設け、予約受付部１１１、処理量算出部１２、及び解析部１３が、この記憶部を参照する構成としてもよい。

図５に示すように、管理テーブルＴＢＬ２０は、画像処理種別Ｃ１５と、画像種別Ｃ２１と、処理内容Ｃ２２とを含んで構成される。画像種別Ｃ２１は、画像処理種別Ｃ１５で示された一連の画像処理が処理の対象としている画像データの種別（モダリティ）を示している。また処理内容Ｃ２２は、実行される処理の一覧が示されている。例えば画像処理種別Ｃ１５が種別Ｍ１１の画像処理は、画像種別Ｃ２１がＭＯＤ１の画像データに対し、処理１、処理２、及び処理３を実行することを示している。

予約受付部１１１は、図４に示す予約管理テーブルＴＢＬ１０を生成すると、生成された予約管理テーブルＴＢＬ１０を処理条件特定部１１２に出力する。

（処理条件特定部１１２）
処理条件特定部１１２は、予約受付部１１１から予約管理テーブルＴＢＬ１０を受ける。処理条件特定部１１２は、予約管理テーブルＴＢＬ１０を基に、予約された各検査における画像処理、即ち、予約された画像処理の処理開始時間Ｃ４１及び処理終了時間Ｃ４２を算出する（詳細は後段で説明する）。処理条件特定部１１２は、処理開始時間Ｃ４１と、処理終了時間Ｃ４２とを基に、メインサーバーとして動作するサーバー（即ち、サーバー２Ａ及び２Ｂ）ごとに、処理管理テーブルＴＢＬ４０を作成する。図７は、サーバー２Ａに予約された画像処理に関する処理管理テーブルＴＢＬ４０の一例である。なお、予約された検査ごとの画像処理を、サーバー２Ａ及び２Ｂのいずれに振り分けるかについては、例えば、画像処理種別Ｃ１５を基にあらかじめ決めておく。例えば、検査ａ〜ｄに画像処理種別Ｃ１５として設定された種別Ｍ１１、Ｍ１２、Ｍ２２、及びＭ３１は、サーバー２Ａに対応付けておき、その他（例えば、種別Ｍ２１）についてはサーバー２Ｂに対応付ける。また、画像データを撮影する撮影部１５を基にあらかじめ決めておいてもよい。以降では、サーバー２Ａの場合を例に説明する。なお、単位時間あたり処理量Ｃ４３は、後述する処理量算出部１２が算出して処理管理テーブルＴＢＬ４０に入力する。処理開始時間Ｃ４１及び処理終了時間Ｃ４２の算出方法について、画像データの撮影を伴う検査ａと、画像データの撮影を伴わない検査ｃとに分けて以下に具体的に説明する。

まず、画像データの撮影を伴う検査ａについて説明する。画像データの撮影を伴う場合、撮影部１５から撮影された画像データの出力が開始される時間から、その画像データに対する画像処理を開始することが可能である。そのため、処理条件特定部１１２は、撮影部１５が撮影を開始してから画像データの出力を開始するまでの時間Ｔ’をあらかじめ記憶しておき、検査開始時間Ｃ１３に設定された時間「Ｔａ１」と時間Ｔ’とを基に、処理開始時間Ｃ４１として時間「Ｔａ３」を算出する。なお、撮影される画像データのデータ量に応じて時間Ｔ’が異なる場合、所定のデータ量あたりの時間Ｔ’をあらかじめ記憶しておき、撮影される画像データのデータ量とあわせて、処理開始時間Ｃ４１として「Ｔａ３」を算出すればよい。なお、画像データのデータ量は、予約管理テーブルＴＢＬ１０における、画像サイズＣ１６と、枚数Ｃ１７とに基づき算出することが可能である。

また、処理条件特定部１１２は、検査終了時間Ｃ１４に設定された時間「Ｔａ２」を基に処理終了時間Ｃ４２として時間「Ｔａ４」を特定する。例えば、検査終了時間「Ｔａ２」以前に画像処理が終了している必要がある場合は、処理条件特定部１１２は、検査終了時間「Ｔａ２」から所定の時間以前の時間「Ｔａ４」を処理終了時間Ｃ４２として特定する。また、時間「Ｔａ２」を、処理終了時間Ｃ４２として特定してもよい。また、時間「Ｔａ２」から、所定時間後の時間「Ｔａ４」を処理終了時間Ｃ４２として特定してもよい。また、処理開始時間「Ｔａ３」から、サーバーでの所定の処理時間後の時間「Ｔａ４」を処理時間Ｃ４２として特定してもよい。この処理終了時間Ｃ４２の特定方法は、運用するシステムの要件に応じて適宜設定すればよい。

なお、画像データの撮影を伴わない検査ｃの場合には、検査開始時間Ｃ１３に設定された時間Ｔｃ３が処理開始時間Ｃ４１に相当し、検査終了時間Ｃ１４に設定された時間Ｔｃ４が処理終了時間Ｃ４２に相当する。

処理条件特定部１１２は、処理管理テーブルＴＢＬ４０を作成し、検査ごとに処理開始時間Ｃ４１及び処理終了時間Ｃ４２を入力したら、処理管理テーブルＴＢＬ４０を予約管理テーブルＴＢＬ１０とあわせて処理量算出部１２に出力する。

（処理量算出部１２）
処理量算出部１２は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０を処理条件特定部１１２から受ける。処理量算出部１２は、処理管理テーブルＴＢＬ４０に記憶された処理開始時間Ｃ４１及び処理終了時間Ｃ４２と、予約管理テーブルＴＢＬ１０に記憶された画像サイズＣ１６及び枚数Ｃ１７とに基づき、単位時間あたりの処理量Ｃ４３（以下、単に「処理量Ｃ４３」と呼ぶ）を算出する。処理量Ｃ４３の算出方法について、以下に具体的に説明する。

まず、処理量算出部１２は、画像サイズＣ１６を基に、画像１枚当たりのデータ量Ｃ３２を特定する。画像１枚当たりのデータ量Ｃ３２は、画像種別Ｃ２１、画像サイズＣ１６、及びその画像に対する処理Ｃ３１に応じて異なる。そのため、処理量算出部１２は、これらの対応関係を管理テーブルＴＢＬ３０としてあらかじめ記憶している。図６は、この管理テーブルの一例を示している。図６に示すように、管理テーブルＴＢＬ３０は、画像種別Ｃ２１、画像サイズＣ１６、及び処理Ｃ３１の組み合わせごとに、処理量Ｃ３２を記憶している。これらのデータ量は、例えば、所定の処理能力のサーバーに各組み合わせについてあらかじめ処理を実行させ、そのときの処理時間と、そのサーバーの処理能力とから算出すればよい。

処理量算出部１２は、予約管理テーブルＴＢＬ１０に記憶された画像処理種別Ｃ１５を基に、管理テーブルＴＢＬ２０から、画像種別Ｃ２１と、処理内容Ｃ２２とを特定する。次に、処理量算出部１２は、管理テーブルＴＢＬ３０を参照し、画像種別Ｃ２１と、画像サイズｃ１６と、を基に、処理内容Ｃ２２に含まれる処理ごとに、データ量Ｃ３２を特定する。例えば、検査ａの場合、画像種別Ｃ２１は「ＭＯＤ１」、画像サイズＣ１６は「条件Ｐ１１」となり、処理内容Ｃ２２には、「処理１」、「処理２」、及び「処理３」が含まれている。図６に示すように、画像種別Ｃ２１が「ＭＯＤ１」、かつ画像サイズＣ１６が「条件Ｐ１１」のとき、「処理１」、「処理２」、及び「処理３」の画像１枚当たりのデータ量Ｃ３２は、「Ｄ１１１」、「Ｄ１１２」、及び「Ｄ１１３」である。そのため、処理量算出部１２は、画像１枚当たりのデータ量の合計を、「Ｄ１１１」、「Ｄ１１２」、及び「Ｄ１１３」の和として算出する。

次に、処理量算出部１２は、算出された画像１枚当たりのデータ量の合計と、予約管理テーブルＴＢＬ１０に記憶された枚数Ｃ１７とに基づき、検査ごとの合計データ量を算出する。処理量算出部１２は、算出された合計データ量を、処理管理テーブルＴＢＬ４０に記憶された処理開始時間Ｃ４１から処理終了時間Ｃ４２までの時間幅で除算し、所定の単位時間あたりに処理するデータ量を「処理量」として算出する。処理量算出部１２は、算出された処理量を、処理管理テーブルＴＢＬ４０の処理量Ｃ４３に入力する。例えば、検査ａの場合、枚数Ｃ１７は「Ｎａ」、処理開始時間Ｃ４１は「Ｔａ３」、処理終了時間Ｃ４２は「Ｔａ４」、処理量Ｃ４３は「Ｄａ」となる。なお、単位時間の時間幅を「Ｔ０」とした場合、Ｄａ＝（Ｄ１１１＋Ｄ１１２＋Ｄ１１３）×Ｎａ×Ｔ０／（Ｔａ４−Ｔａ３）となる。

なお、画像処理の中には、データ量に拘らず一定の処理時間を要するものがある。その場合には、その時間を考慮して処理量Ｃ４３を算出すればよい。例えば、処理２は、データ量Ｄ１１２に対する処理に加え、一定の処理時間Ｔ２を要するとする。この場合、先の例で示した検査ａにおける処理量Ｄａは、時間幅（Ｔａ４−Ｔａ３）から処理時間Ｔ２を減算した時間幅を基に算出すればよい。即ち、Ｄａ＝（Ｄ１１１＋Ｄ１１２＋Ｄ１１３）×Ｎａ×Ｔ０／（Ｔａ４−Ｔａ３−Ｔ２）となる。

処理量算出部１２は、処理量Ｃ４３を入力した処理管理テーブルＴＢＬ４０と、予約管理テーブルＴＢＬ１０とを、解析部１３に出力する。

（解析部１３）
解析部１３は、依頼処理特定部１３１と、依頼先特定部１３２と、依頼情報作成部１３３とを含んで構成される。解析部１３は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０を処理量算出部１２から受け、これらを依頼処理特定部１３１に出力する。

（依頼処理特定部１３１）
依頼処理特定部１３１は、処理管理テーブルＴＢＬ４０を受けて、処理管理テーブルＴＢＬ４０に記憶された処理開始時間Ｃ４１、処理終了時間Ｃ４２に基づき、サーバー２Ａで実行される検査ごとの画像処理の処理スケジュールを作成する。図８は、処理管理テーブルＴＢＬ４０に基づき作成された、サーバー２Ａで実行される画像処理の処理スケジュールの一例である。なお、このとき、依頼処理特定部１３１は、図８に示すように、各検査のスケジュールに処理量Ｃ４３を関連付ける。

依頼処理特定部１３１は、サーバー２Ａで実行される各画像処理の処理量Ｃ４３を所定の時間幅ごとにそれぞれ加算し、負荷予測データを作成する。図９Ａは、負荷予測データの一例である。次に、依頼処理特定部１３１は、各画像処理の処理量Ｃ４３の合計Ｄが、所定の処理量Ｄ０以上となるか否かを判定する。図９Ａは、最も早く開始される検査ａの画像処理の処理開始時間「Ｔａ３」から、最後に終了する検査ｃの画像処理の処理終了時間「Ｔｃ４」までの間を、あらかじめ決められた単位時間幅で時間幅Ｗ１〜Ｗ１２に分割した場合の例である。なお所定の処理量Ｄ０は、許容される処理負荷の最大値として、そのサーバーの最大処理量Ｄｍａｘを超えない範囲であらかじめ設定しておく。

例えば、図９Ａにおいて、時間幅Ｗ３に実行される画像処理の処理量Ｃ４３の合計Ｄは、Ｄ＝Ｄａ＋Ｄｂ＜Ｄ０となる。また、時間幅Ｗ６に実行される画像処理の処理量Ｃ４３の合計Ｄは、Ｄ＝Ｄａ＋Ｄｂ＋Ｄｃ＋Ｄｄ≧Ｄ０となる。このように、依頼処理特定部１３１は、時間幅ごとに処理量Ｃ４３の合計Ｄを計算し、所定の処理量Ｄ０と比較する。図９Ａの例では、時間幅Ｗ５及びＷ６において処理量Ｃ４３の合計が、所定の処理量Ｄ０以上となる。

なお、必ずしもあらかじめ決められた単位時間幅で分割する必要はない。例えば、図９Ｂに示すように、並行して実行される画像処理の組み合わせが変わるタイミングで時間幅を分割してもよい。この場合、図９Ｂに示すように、Ｔａ３〜Ｔｃ４の間の時間幅を、画像処理が開始する時間Ｔｂ３、Ｔｃ３、及びＴｄ３と、画像処理が終了する時間Ｔａ４、Ｔｂ４、及びＴｄ４で分割してＷａ１〜Ｗａ７で示される時間幅を求め、これらそれぞれを時間幅とする。例えば、時間幅Ｗａ１では、検査ａの画像処理のみが実行される。また、時間幅Ｗａ４では、検査ａ〜ｄの各画像処理が並列に実行され、このとき処理量Ｃ４３の合計Ｄが所定の処理量Ｄ０以上となる。

依頼処理特定部１３１は、処理量Ｃ４３の合計が所定の処理量Ｄ０以上となる場合に、その時間幅で実行が予定されている画像処理のうち、補助サーバー（即ち、サーバー２Ｃまたは２Ｄ）に代行を依頼する画像処理を特定する。このとき、あらかじめ検査ごとに優先度の重み付けを行っておくことで、依頼処理特定部１３１は、最も優先度の低い画像処理を、補助サーバーに処理を依頼する画像処理（以降では、「依頼画像処理」と呼ぶ場合がある）として特定する。なお、検査ごとの優先度の重み付けは、予約を受け付ける際に設定するようにしてもよいし、画像処理種別Ｃ１５ごとにあらかじめ設定しておいてもよい。依頼処理特定部１３１は、処理量Ｃ４３の合計が所定の処理量Ｄ０未満となるまで、依頼画像処理を特定する。

例えば、図９Ａの場合、時間幅Ｗ５及びＷ６において処理量Ｃ４３の合計Ｄが、所定の処理量Ｄ０以上となる。そのため、依頼処理特定部１３１は、検査ａ〜ｄの各画像処理について優先度を比較し、優先度の最も低い検査ｄの画像処理を依頼画像処理として特定する。

補助サーバーに代行を依頼する画像処理を特定したら、依頼処理特定部１３１は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０を依頼先特定部１３２に送信する。このとき、依頼処理特定部１３１は、補助サーバーに依頼する特定された依頼画像処理（図９Ａの場合、検査ｄの画像処理）をあわせて依頼先特定部１３２に通知する。

（依頼先特定部１３２）
依頼先特定部１３２は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０と、依頼画像処理の通知とを受ける。依頼先特定部１３２は、補助サーバーとして動作するサーバー２Ｃ及び２Ｄのうちのいずれかを、通知された画像処理を依頼するサーバーとして特定する。このとき依頼先特定部１３２は、例えば、実行元のメインサーバーごとに依頼先の補助サーバー（以降では、単に「依頼先」と呼ぶ）をあらかじめ対応付けておくとよい。また、依頼先特定部１３２は、通知された画像処理の画像処理種別Ｃ１５ごとに依頼先をあらかじめ設定しておいてもよい。この場合、依頼先特定部１３２は、予約管理テーブルＴＢＬ１０を参照し、通知された画像処理の画像処理種別を特定する。以降では、依頼先特定部１３２は、検査ｄの画像処理の依頼先として、サーバー２Ｃを特定したものとして説明する。

依頼先特定部１３２は、特定された依頼先（サーバー２Ｃ）と、通知された依頼画像処理（検査ｄの画像処理）と、画像データの返却先Ｃ１８とを１つの組として関連付ける。なお、依頼先特定部１３２は、依頼画像処理が複数ある場合は、その依頼画像処理ごとに依頼先を特定し、依頼情報として関連付ける。依頼先特定部１３２は、作成された組と、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０とを、依頼情報作成部１３３に出力する。

以上のように、依頼処理特定部１３１及び依頼先特定部１３２は、全ての時間幅について、処理量Ｃ４３の合計Ｄの算出、合計Ｄと所定の処理量Ｄ０との比較、及び合計Ｄが処理量Ｄ０以上となる場合における依頼画像処理及び依頼先の特定を行う。

（依頼情報作成部１３３）
依頼情報作成部１３３は、依頼先特定部１３２から、依頼先、依頼画像処理、及び返却先Ｃ１８が関連付けられた組と、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０とを受ける。

依頼情報作成部１３３は、予約管理テーブルＴＢＬ１０に記憶された検査ごとに、依頼情報Ｅ１０を作成する。図１０は、依頼情報Ｅ１０のデータ構造の一例である。依頼情報Ｅ１０は、検査識別子Ｅ１１と、検査種別Ｅ１２と、重要度Ｅ１３と、処理情報Ｅ１４とを含んで構成される。依頼情報作成部１３３は、検査識別子Ｅ１１及び画像処理種別Ｅ１２には、予約管理テーブルＴＢＬ１０に記憶された検査識別子Ｃ１１及び画像処理種別Ｃ１５に記憶された情報を入力する。また、依頼情報作成部１３３は、重要度Ｅ１３に、その検査に対してあらかじめ設定された重要度を入力する。

また、処理情報Ｅ１４は、処理Ｅ１４１と、依頼先Ｅ１４２と、返却先Ｅ１４３とを１つの組として、この組が画像処理を構成する処理ごとに設けられている。例えば、検査ｄの画像処理種別は種別Ｍ３１であり、画像処理の処理内容として、「処理６」、「処理７」、及び「処理８」がこの順序で実行される。そのため、処理情報Ｅ１４には、「処理６」、「処理７」、及び「処理８」を示す情報がこの順序で入力される。依頼先Ｅ１４２は、該当する処理の実行を依頼する依頼先を示している。また、返却先Ｅ１４３は、その処理後にその画像データを返却する返却先を示している。

依頼先Ｅ１４２の設定方法は、メインサーバーで画像処理を実行する検査と、補助サーバーに画像処理を依頼する検査とで異なる。補助サーバーに依頼する画像処理については、依頼先特定部１３２から、依頼先と依頼画像処理との組として依頼情報作成部１３３に通知される。そのため、依頼情報作成部１３３は、通知されたこの組と、予約管理テーブルＴＢＬ１０とを比較し、メインサーバーで画像処理を実行する検査と、補助サーバーに画像処理を依頼する検査とに分ける。

補助サーバーに画像処理を依頼する検査の場合には、依頼情報作成部１３３は、通知された組に含まれる依頼先の情報を依頼先Ｅ１４２として入力する。

例えば、依頼先特定部１３２により通知された組により、検査ｄの画像処理をサーバー２Ｃに依頼するように設定されている。即ち、検査ｄの画像処理を構成する、「処理６」、「処理７」、及び「処理８」の一連の処理が、サーバー２Ｃに依頼されることを意味している。そのため、依頼情報作成部１３３は、一連の処理として最初に実行される「処理６」の依頼先Ｅ１４２に「サーバー２Ｃ」を設定する。また、予約管理テーブルＴＢＬ１０には、検査ｄについて、一連の処理の完了後に、「端末３Ｂ」に転送することが返却先Ｃ１８として設定されている。そのため、依頼情報作成部１３３は、一連の処理の最後に実行される「処理８」の返却先Ｅ１４３に「端末３Ｂ」を設定する。なお、依頼情報作成部１３３は、その他の依頼先Ｅ１４２及び返却先Ｅ１４３には、情報が入力されていないことを示す情報として、例えば「−（ブランク）」を入力する。

なお、図１０の例で、「処理６」、「処理７」、及び「処理８」を、それぞれ異なるサーバーで実行させることも可能である。この場合の例については、変形例１として後述する。

また、メインサーバーを示す情報は、処理管理テーブルＴＢＬ４０に関連付けられている。そのため、メインサーバーで画像処理を実行する検査（例えば、検査ａ〜ｃ）の場合には、依頼情報作成部１３３は、このメインサーバーを示す情報、即ち、「サーバー２Ａ」を示す情報を依頼先Ｅ１４２に設定する。なお、返却先Ｅ１４３の設定方法については、前述した検査ｄの場合と同様である。

依頼情報作成部１３３は、各検査の依頼情報と、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０とを処理制御部１４に出力する。

（処理制御部１４）
処理制御部１４は、依頼情報作成部１３３から、各検査の依頼情報と、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０とを受ける。処理制御部１４は、これらの情報に基づき、撮影部１５Ａ及び１５Ｂ、依頼部１７、及びサーバー２Ａ〜２Ｄの動作を制御する。なお、依頼部１７は、撮影部１５や画像記憶部１６ごとに関連付けられて設けられている。なお、依頼部１７の詳細については後述する。以下に、処理制御部１４の詳細について説明する。

処理制御部１４は、予約管理テーブルＴＢＬ１０を参照し、各検査の検査開始時間を特定する。処理制御部１４は、特定された検査開始時間にあわせて、撮影部１５Ａ及び１５Ｂに撮影の開始を指示する。

また、処理制御部１４は、予約管理テーブルＴＢＬ１０を基に、検査ごとの画像処理が出力される依頼部１７を特定する。例えば、図４に示すように、検査ｄでは撮影部１５Ｂで画像データが撮影される。そのため、処理制御部１４は、撮影部１５Ｂに関連付けて設けられた依頼部１７を特定する。

また、処理制御部１４は、処理管理テーブルＴＢＬ４０の処理開始時間Ｃ４１を参照し、各検査の画像処理が開始する時間を特定する。処理制御部１４は、各検査の依頼情報を、その検査の画像処理が開始される以前に、該当する依頼部１７にあらかじめ通知する。

また、検査ｃのように、画像記憶部１６に記憶された画像データに対する画像処理の予約については、処理制御部１４は、依頼情報とあわせて、画像処理の対象となる画像データのファイル名Ｃ１９を該当する依頼部１７に通知する。この通知を受けて、依頼部１７は、通知されたファイル名Ｃ１９を基に該当する画像データを画像記憶部１６から読み出す。

次に、処理制御部１４は、処理管理テーブルＴＢＬ４０を参照し、各画像処理の処理開始時間Ｃ４１を特定する。また、処理制御部１４は、検査ごとの依頼情報に基づき、その検査の画像処理を実行するサーバーを特定する。例えば、図７は、サーバー２Ａの処理管理テーブルＴＢＬ４０であり、このうち検査ｄの画像処理をサーバー２Ｃに依頼する。この場合には、検査ａ〜ｃの依頼情報には、処理情報Ｅ１４として、サーバー２Ａを示す情報が含まれている。同様に、検査ｄの依頼情報には、処理情報Ｅ１４として、サーバー２Ｃを示す情報が含まれている。そのため、処理制御部１４は、検査ａ〜ｃの画像処理については、処理開始時間Ｃ４１を基に、サーバー２Ａに実行を指示する。また、処理制御部１４は、検査ｄの画像処理については、サーバー２Ｃに実行を指示する。

以上のように、予約管理部１１と、処理量算出部１２と、解析部１３と、処理制御部１４とが動作することで、撮影部１５Ａ及び１５Ｂ、各依頼部１７、及びサーバー２Ａ〜２Ｄの動作が制御される。

次に、図１及び図３を参照しながら、依頼部１７、サーバー２Ａ〜２Ｄの構成について説明する。図３は、撮影部１５Ａ〜１５Ｂで撮影された画像データ、及び、画像記憶部１６に記憶された画像データが、サーバー２Ａ〜２Ｄのいずれかにより画像処理が施され、端末３に出力されるまでの流れに着目したブロック図である。

（依頼部１７）
依頼部１７は、撮影部１５及び画像記憶部１６それぞれに関連付けられて設けられている。

撮影部１５に関連付けられた依頼部１７は、撮影された画像データを撮影部１５から受ける。また、この依頼部１７は、処理制御部１４から依頼情報を受ける。

依頼部１７は、受けた依頼情報から、検査識別子Ｅ１１、検査種別Ｅ１２、重要度Ｅ１３、及び処理情報Ｅ１４を読み出し、撮影部１５から受けた画像データに付帯させる。図１１は、本実施形態に係る画像データのデータ構造の一例である。図１１に示すように、画像データは、付帯情報Ｅ５００と画像の実データＥ６００とを含んで構成されている。画像の実データＥ６００は、画像の作成元となるデータそのものである。付帯情報Ｅ５００は、その画像データの属性を示す情報が含まれている。依頼情報から読み出された検査識別子Ｅ１１、検査種別Ｅ１２、重要度Ｅ１３、及び処理情報Ｅ１４は、図１１に示すように、付帯情報Ｅ５００に入力される。

依頼部１７は、処理情報Ｅ１４に含まれる各処理の情報のうち、最初の処理の情報の依頼先Ｅ１４２の情報を読み出し、画像データを送信するサーバー２を特定する。例えば、図１１の例では、処理情報Ｅ１４の最初に定義された「処理６」の依頼先Ｅ１４２を読み出し、「サーバー２Ｃ」を特定する。依頼部１７は、特定されたサーバー２Ｃに画像データを送付する。

また、画像記憶部１６に関連付けられた依頼部１７は、処理制御部１４から、画像処理の対象となる画像データのファイル名Ｃ１９と、依頼情報とを受ける。この依頼部１７は、ファイル名Ｃ１９に該当する画像データを画像記憶部１６から読み出す。

また、依頼部１７は、受けた依頼情報から、検査識別子Ｅ１１、検査種別Ｅ１２、重要度Ｅ１３、及び処理情報Ｅ１４を読み出し、画像記憶部１６から読み出した画像データに付帯させる。以降の処理は、撮影部１５に関連付けられた依頼部１７と同様である。

なお、撮影部１５及び画像記憶部１６それぞれに関連付けられて各依頼部１７を、１つの依頼部１７としてまとめて動作させてもよい。

次に、サーバー２Ａ〜２Ｄの構成について、図１１で示した検査ｄに関する画像データがサーバー２Ｃで処理される例に説明する。

サーバー２Ｃは、画像処理部２１と、転送部２２とを含んで構成されている。

画像処理部２１は、依頼部１７から画像データを受ける。また、画像処理部２１は、処理制御部１４から画像処理の実行を指示される。

画像処理部２１は、画像処理の実行が指示されると、まず依頼部１７から受けた画像データに付帯された処理情報Ｅ１４を読み出す。次に、処理情報Ｅ１４に処理ごとに登録された依頼先Ｅ１４２を遂次読み出す。この処理において、画像処理部２１は、依頼先Ｅ１４２に自身を示す情報が含まれる第１の行を特定する。図１１の場合、サーバー２Ｃの画像処理部２１は、依頼先Ｅ１４２に「サーバー２Ｃ」が設定された「処理６」の行を第１の行として特定する。

次に、画像処理部２１は、第１の行から順に処理Ｅ１４１、依頼先Ｅ１４２、及び返却先Ｅ１４３を遂次読み出し、読み出された行の処理Ｅ１４１に設定されている処理を実行する。画像処理部２１は、この処理を返却先Ｅ１４３に情報が入力された（即ち、「−（ブランク）」以外の情報が設定された）第２の行を読み出すまで実行する。図１１の場合、「処理６」及び「処理７」の行の返却先Ｅ１４３には「−（ブランク）」が設定されており、「処理８」の返却先Ｅ１４３には「端末３Ｂ」が設定されている。そのため、画像処理部２１は、「処理６」、「処理７」、及び「処理８」をこの順で実行する。

第２の行を読み出した場合には、処理Ｅ１４１に設定されている処理を実行した後に、その処理が実行された後の画像データと返却先Ｅ１４３とを転送部２２に出力する。図１１の場合には、画像処理部２１は、「処理８」を実行後に、「処理８」が実行された後の画像データと、返却先Ｅ１４３に設定された「端末３Ｂ」を転送部２２に通知する。

転送部２２は、画像処理部２１から、画像処理後の画像データと、返却先Ｅ１４３とを受ける。転送部２２は、返却先Ｅ１４３で示された宛先に、受けた画像データを転送する。即ち、図１１に示す例の場合には、検査ｄの画像データは、サーバー２Ｃの画像処理部２１において、「処理６」、「処理７」、及び「処理８」が実行された後に、転送部２２により「端末３Ｂ」に転送される。

なお、上記では、サーバー２Ａ〜２Ｄの画像処理部２１が画像処理を開始する契機は、必ずしも処理制御部１４の指示に限定されるものではない。例えば、画像処理部２１は、依頼部１７から画像データを受信したときに、この受信をトリガとして画像処理を開始してもよい。この場合、処理制御部１４は、各サーバーに画像処理の開始を指示する必要は無い。

次に、解析部１３の動作について図１２を参照しながら説明する。図１２は、補助サーバーに依頼する画像処理を特定し、その画像処理を依頼するまでの一連の動作を示したフローチャートである。

（ステップＳ１１）
予約受付部１１１は、撮影部１５Ａまたは１５Ｂによる画像データの撮影に係る検査予約を受け付け、図４に示すような予約管理テーブルＴＢＬ１０を作成する。予約受付部１１１は、生成された予約管理テーブルＴＢＬ１０を処理条件特定部１１２に出力する。

処理条件特定部１１２は、予約受付部１１１から予約管理テーブルＴＢＬ１０を受ける。処理条件特定部１１２は、予約管理テーブルＴＢＬ１０を基に、予約された各検査における画像処理、即ち、予約された画像処理の、処理開始時間Ｃ４１と、処理終了時間Ｃ４２とを算出する。処理条件特定部１１２は、処理開始時間Ｃ４１と、処理終了時間Ｃ４２とを基に、処理管理テーブルＴＢＬ４０を作成する。処理条件特定部１１２は、作成された処理管理テーブルＴＢＬ４０を予約管理テーブルＴＢＬ１０とあわせて処理量算出部１２に出力する。

処理量算出部１２は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０を処理条件特定部１１２から受ける。処理量算出部１２は、画像サイズＣ１６を基に、画像１枚当たりのデータ量Ｃ３２を特定する。処理量算出部１２は、予約管理テーブルＴＢＬ１０に記憶された画像処理種別Ｃ１５を基に、管理テーブルＴＢＬ２０から、画像種別Ｃ２１と、処理内容Ｃ２２とを特定する。次に、処理量算出部１２は、管理テーブルＴＢＬ３０を参照し、画像種別Ｃ２１と、画像サイズＣ１６と、を基に、処理内容Ｃ２２に含まれる処理ごとに、データ量Ｃ３２を特定する。

次に、処理量算出部１２は、算出された画像１枚当たりのデータ量の合計と、予約管理テーブルＴＢＬ１０に記憶された枚数Ｃ１７とに基づき、検査ごとの合計データ量を算出する。処理量算出部１２は、算出された合計データ量を、特定された処理開始時間Ｃ４１から処理終了時間Ｃ４２までの時間幅で除算することにより、所定の単位時間あたりに処理するデータ量を処理量Ｃ４３として算出し、処理管理テーブルＴＢＬ４０に入力する。

処理量算出部１２は、処理量Ｃ４３を入力した処理管理テーブルＴＢＬ４０と、予約管理テーブルＴＢＬ１０とを、解析部１３に出力する。

（ステップＳ１２）
解析部１３は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０を処理量算出部１２から受け、これらを依頼処理特定部１３１に出力する。

依頼処理特定部１３１は、処理管理テーブルＴＢＬ４０を受けて、処理管理テーブルＴＢＬ４０に記憶された処理開始時間Ｃ４１、処理終了時間Ｃ４２に基づき、図８に示すように、サーバー２Ａで実行される検査ごとの画像処理の処理スケジュールを作成する。

依頼処理特定部１３１は、サーバー２Ａで実行される各画像処理の処理量Ｃ４３を時間幅ごとにそれぞれ加算し、図９Ａに示すような負荷予測データを作成する。

（ステップＳ１３）
次に、依頼処理特定部１３１は、時間幅ごとに処理量Ｃ４３の合計Ｄを計算し、所定の処理量Ｄ０と比較する。この比較により、依頼処理特定部１３１は、各画像処理の時間幅当たりの処理量Ｃ４３の合計Ｄが、所定の処理量Ｄ０以上となるか否かを判定する。なお所定の処理量Ｄ０は、許容される処理負荷の最大値として、そのサーバーの最大処理量Ｄｍａｘを超えない範囲であらかじめ設定しておく。

（ステップＳ１５）
処理量Ｃ４３の合計Ｄが所定の処理量Ｄ０以上となる場合に（ステップＳ１４、Ｙ）、依頼処理特定部１３１は、その時間幅で実行が予定されている画像処理のうち、補助サーバーに代行を依頼する画像処理を特定する。依頼処理特定部１３１は、処理量Ｃ４３の合計が所定の処理量Ｄ０未満となるまで、依頼画像処理を特定する。

補助サーバーに代行を依頼する画像処理を特定したら、依頼処理特定部１３１は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０を依頼先特定部１３２に送信する。このとき、依頼処理特定部１３１は、補助サーバーに依頼する特定された依頼画像処理（図９Ａの場合、検査ｄの画像処理）をあわせて依頼先特定部１３２に通知する。

（ステップＳ１６）
依頼先特定部１３２は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０と、依頼画像処理の通知とを受ける。依頼先特定部１３２は、補助サーバーとして動作するサーバー２Ｃ及び２Ｄのうちのいずれかを、通知された画像処理を依頼するサーバーとして特定する。このとき依頼先特定部１３２は、例えば、実行元のメインサーバーごとに依頼先をあらかじめ対応付けておくとよい。また、依頼先特定部１３２は、通知された画像処理の画像処理種別Ｃ１５ごとに依頼先をあらかじめ設定しておいてもよい。この場合、依頼先特定部１３２は、予約管理テーブルＴＢＬ１０を参照し、通知された画像処理の画像処理種別Ｃ１５を特定する。

なお、処理量Ｃ４３の合計Ｄが所定の処理量Ｄ０以上とならない場合に（ステップＳ１４、Ｎ）は、ステップＳ１５及び１６で示した処理を行わず次の処理に遷移する。

（ステップＳ１７）
依頼処理特定部１３１及び依頼先特定部１３２は、全ての時間幅について処理が完了していない場合（ステップＳ１７、Ｎ）には、次の時間幅についてステップＳ１３〜Ｓ１６に係る処理を実行する。

（ステップＳ１８）
全ての時間幅について処理が完了した場合に（ステップＳ１７、Ｙ）は、依頼情報作成部１３３は、予約管理テーブルＴＢＬ１０に記憶された検査ごとに、図１０に示す依頼情報Ｅ１０を作成する。依頼情報作成部１３３は、検査識別子Ｅ１１及び画像処理種別Ｅ１２には、予約管理テーブルＴＢＬ１０に記憶された検査識別子Ｃ１０及び画像処理種別Ｃ１５に記憶された情報を入力する。また、依頼情報作成部１３３は、重要度Ｅ１３に、その検査にあらかじめ設定された重要度を入力する。また、依頼情報作成部１３３は、処理Ｅ１４１と、依頼先１４２と、返却先Ｅ１４３と１つの組として、この組が画像処理を構成する処理ごとに作成し、処理情報Ｅ１４に入力する。

なお、依頼情報作成部１３３は、通知されたこの組と、予約管理テーブルＴＢＬ１０とを比較し、メインサーバーで画像処理を実行する検査と、補助サーバーに画像処理を依頼する検査とに分ける。補助サーバーに画像処理を依頼する検査の場合には、依頼情報作成部１３３は、通知された組に含まれる依頼先の情報を依頼先Ｅ１４２として入力する。メインサーバーで画像処理を実行する検査（例えば、検査ａ〜ｃ）の場合には、依頼情報作成部１３３は、このメインサーバーを示す情報を依頼先Ｅ１４２に設定する。

依頼情報作成部１３３は、各検査の依頼情報と、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０とを処理制御部１４に出力する。

（ステップＳ１９）
処理制御部１４は、予約管理テーブルＴＢＬ１０を参照し、各検査の検査開始時間を特定する。処理制御部１４は、特定された検査開始時間に基づき、撮影部１５Ａ及び１５Ｂに撮影の開始を指示する。

処理制御部１４は、予約管理テーブルＴＢＬ１０を基に、検査ごとの画像処理が出力される依頼部１７を特定する。

処理制御部１４は、処理管理テーブルＴＢＬ４０の処理開始時間Ｃ４１を参照し、各検査の画像処理が開始する時間を特定する。処理制御部１４は、各検査の依頼情報を、その検査の画像処理が開始される以前に、該当する依頼部１７にあらかじめ通知する。

（ステップＳ２０）
依頼部１７は、撮影された画像データを撮影部１５から受ける。また、この依頼部１７は、処理制御部１４から依頼情報を受ける。依頼部１７は、受けた依頼情報から、検査識別子Ｅ１１、検査種別Ｅ１２、重要度Ｅ１３、及び処理情報Ｅ１４を読み出し、撮影部１５から受けた画像データに付帯させる。

（ステップＳ２１）
依頼部１７は、処理情報Ｅ１４に含まれる各処理の情報のうち、最初の処理の情報の依頼先Ｅ１４２の情報を読み出し、画像データを送信するサーバー２Ｃを特定する。依頼部１７は、特定されたサーバー２Ｃに画像データを送付する。

以上のように本実施形態に係る医用画像処理システムでは、画像処理を実行するメインサーバーごとに、予約された画像処理について時間幅当たりの処理量の合計Ｄを時間幅ごとに算出する。そのうえで、算出された処理量の合計Ｄを所定の処理量Ｄ０と比較し、合計Ｄが処理量Ｄ０以上となる場合に、その時間幅で実行が予定されている画像処理のうち一部の実行を補助サーバーに依頼する。このような構成とすることにより、一時的に処理負荷が増大する時間帯（つまり、非定常的に負荷が増大する時間帯）と、その時間帯で実行される画像処理を特定し、特定された画像処理の一部を補助サーバーに依頼することが可能となる。この補助サーバーは、メインサーバーのように定常的に画像処理を実行する必要は無い。そのため、画像処理以外の処理を実行するサーバーを一時的に補助サーバーとして動作させたり、外部機関に設けられた補助サーバーを設けたりすることが可能となる。これにより、メインサーバーを増設することなく、非定常時の負荷に対応することが可能となる。

（変形例１）
次に、第１の実施形態の変形例として、変形例１に係る医用画像処理システムについて説明する。例えば、検査ｄの画像処理は、処理内容として「処理６」、「処理７」、及び「処理８」を含んで構成される。第１の実施形態に係る医用画像処理システムでは、検査ごとに画像処理の依頼先を特定していた。変形例１に係る医用画像処理システムは、検査ごとの画像処理を構成する処理ごとに、依頼先を設定可能に構成されている。以降では、変形例１に係る医用画像処理システムについて、第１の実施形態と異なる解析部１３の動作に着目し説明する。

依頼処理特定部１３１の動作は第１の実施形態と同様である。なお、以降では、第１の実施形態と同様に、検査ｄの画像処理が依頼画像処理として特定されたものとして説明する。

変形例１に係る依頼先特定部１３２は、各補助サーバー（即ち、サーバー２Ｃ及び２Ｄ）が実行可能な処理を管理する機能管理テーブルをあらかじめ記憶している。図１４は、機能管理テーブルの一例である。図１４に示すように、機能管理テーブルは、サーバー識別子Ｃ５１と、実行可能な処理種別Ｃ５２とを含んで構成されている。サーバー識別子Ｃ５１は、各補助サーバーを識別するための識別子である。また、実行可能な処理種別Ｃ５２には、サーバー識別子Ｃ５１で示された補助サーバーで、実行可能な処理の一覧が記憶されている。

例えば、図１４の例では、サーバー２Ｃは、「処理１」、「処理２」、「処理５」、及び「処理６」を実行可能であることを示している。同様に、サーバー２Ｄは、「処理３」、「処理４」、「処理７」、及び「処理８」を実行可能であることを示している。このような構成の場合、例えば、検査ｄの画像処理、即ち「処理６」、「処理７」、及び「処理８」をサーバー２Ｃのみで処理することは不可能である。そこで、依頼先特定部１３２は、画像処理を構成する各処理ごとに、依頼先を特定する。

まず、依頼先特定部１３２は、検査ｄの画像処理の処理内容を、図５に示した管理テーブルＴＢＬ２０を基に特定する。これにより、検査ｄの画像処理の処理内容として、「処理６」、「処理７」、及び「処理８」が特定される。

次に、依頼先特定部１３２は、特定された処理ごとに、その処理を実行可能な補助サーバーを特定する。図１４に示す構成の場合、依頼先特定部１３２は、「処理６」の依頼先として「サーバー２Ｃ」を特定し、「処理７」及び「処理８」の依頼先として「サーバー２Ｄ」を特定する。依頼先特定部１３２は、各処理とそれぞれについて特定された依頼先とを対として関連付けるとともに、これら各対と画像データの返却先Ｃ１８とを１つの組として関連付ける。依頼先特定部１３２は、作成された組と、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０とを、依頼情報作成部１３３に出力する。

（依頼情報作成部１３３）
依頼情報作成部１３３は、予約管理テーブルＴＢＬ１０に記憶された検査ごとに、依頼情報Ｅ１０を作成する。図１３は、上述した例に、検査ｄの依頼情報Ｅ１０のデータ構造を示している。依頼情報Ｅ１０のデータ構造については、第１の実施形態に係る依頼情報Ｅ１０のデータ構造と同様であるが、処理情報Ｅ１４に設定される内容が異なる。ここでは、処理情報Ｅ１４’の生成方法について着目し説明する。

依頼情報作成部１３３は、検査ｄの画像処理を構成する各処理について、実行される順に依頼先を確認する。最初に実行される「処理６」の依頼先には「サーバー２Ｃ」が設定されている。そのため、依頼情報作成部１３３は、処理Ｅ１４１に「処理６」を入力するとともに、「処理６」の依頼先Ｅ１４２に「サーバー２Ｃ」を入力する。

次に、依頼情報作成部１３３は、「処理６」の次に実行される「処理７」の依頼先を確認する。「処理７」の依頼先は「サーバー２Ｄ」であり、「処理６」とは異なる。そのため、依頼情報作成部１３３は、まず「処理６」の行の返却先Ｅ１４３に、次の処理、つまり「処理７」の依頼先である「サーバー２Ｄ」の情報を入力する。これにより、サーバー２Ｃで「処理６」が実行された後に、画像データが「サーバー２Ｄ」に転送される。また、依頼情報作成部１３３は、処理Ｅ１４１に「処理７」を入力して「処理７」の行を作成するとともに、この行の依頼先Ｅ１４２に「サーバー２Ｄ」を入力する。これにより、「サーバー２Ｄ」では、「処理７」から実行される。

次に、依頼情報作成部１３３は、「処理７」の次に実行される「処理８」の依頼先を確認する。「処理８」の依頼先は「サーバー２Ｄ」であり、「処理７」と同じである。そのため、依頼情報作成部１３３は、「処理７」の行の返却先Ｅ１４３には、情報を入力せず「−（ブランク）」とする。また、依頼情報作成部１３３は、処理Ｅ１４１に「処理８」を入力して「処理８」の行を作成する。このとき、「処理８」の行の依頼先Ｅ１４２には、情報を入力せず「−（ブランク）」とする。

なお、「処理８」以降に実行される処理は無い。そのため、依頼情報作成部１３３は、「処理８」の行の返却先Ｅ１４３に、返却先Ｃ１８として設定された「端末３Ｂ」を設定する。これにより、「サーバー２Ｄ」で「処理８」が実行された後に、画像データが「端末３Ｂ」に転送される。

以降の処理は、第１の実施形態に係る医用画像処理システムと同様である。

なお、上記では、補助サーバーのみを処理の依頼先として設定していたが、一部の処理の依頼先にメインサーバーを含めるように構成してもよい。例えば、時間幅当たりの処理負荷の合計Ｄと所定の処理量Ｄ０との比較を、検査ごとではく、画像処理を構成する処理ごとに行ってもよい。このように動作させることで、画像処理を構成する各処理のうち、一部の処理の実行のみを補助サーバーに依頼し、その処理の実行後に、メインサーバーで以降の処理を引き継ぐことも可能となる。なお、補助サーバーとメインサーバーとの間で処理の引き継ぎを行う場合には、補助サーバーとメインサーバーとをネットワークを介して接続する。

以上のように、変形例１に係る医用画像処理システムでは、検査ごとの画像処理を構成する処理ごとに依頼先が設定され、処理情報Ｅ１４’として画像データに付帯される。これにより、補助サーバーごとに実行可能な処理が異なる場合においても、検査ごとの画像処理を、複数の補助サーバーに亘って実行させることが可能となる。これにより、補助サーバーそれぞれが、全ての処理を実行可能である必要が無くなり、各補助サーバーにインストールするソフトウェアの量を少なくすることが可能となる。そのため、各補助サーバーの構築にかかる手間を軽減することが可能となり、かつ、ソフトウェアの数が制限されるため、その分の記憶領域をデータの領域として使用することが可能となる。

（第２の実施形態）
次に、第２の実施形態として、新たな予約が追加された場合における医用画像処理システムの動作について、図１５〜図１８を参照しながら、第１の実施形態と異なる部分に着目して説明する。

まず、図１５を参照する。図１５は、本実施形態における、画像処理の処理スケジュールの一例である。図１５では、サーバー２Ａに検査ａ、ｂ、及びｃの画像処理の予約されている状況で、時間Ｔｘにおいて、緊急の検査として「検査ｅ」の予約が追加された場合を示している。なお、時間Ｔｘは、図１５に示すように、検査ａ及びｂの画像処理が既に開始され、検査ｃの画像処理が開始される前の時間を示している。

（予約受付部１１１）
まず、予約受付部１１１が、検査ｅの予約を受け付ける。検査ｅとして検査内容が決まっている場合には、予約受付部１１１は、第１の実施形態と同様に予約を受け付ける。しかしながら、緊急の検査の場合には、具体的な検査内容が決まっていない場合がある。図１６は、緊急で追加された検査の予約内容含む予約管理テーブルの一例である。

図１６に示すように、緊急の検査の場合には、画像処理種別Ｃ１５、画像サイズＣ１６、及び枚数Ｃ１７のように詳細な条件が決定していない場合がある。このような場合には、予約受付部１１１は、画像データを撮影する予定の撮影部１５の撮影部識別子Ｃ１２と、検査開始時間Ｔｅ１及び検査終了時間Ｔｅ２と、返却先Ｃ１８とを検査の予約として受け付ける。予約受付部１１１は、予約管理テーブルＴＢＬ１０に、予約を受け付けた検査ｅの情報を追加する。これにより、予約管理テーブルＴＢＬ１０が更新される。

予約受付部１１１は、更新された（検査ｅの情報が追加された）予約管理テーブルＴＢＬ１０を処理条件特定部１１２に出力する。

（処理条件特定部１１２）
処理条件特定部１１２は、予約受付部１１１から予約管理テーブルＴＢＬ１０を受けると、新たに追加された検査ｅについて、画像処理の処理開始時間Ｃ４１及び処理終了時間Ｃ４２を算出する。このとき、検査ｅの情報には、画像処理種別Ｃ１５、画像サイズＣ１６、及び枚数Ｃ１７の情報が入力されていない。そのため、処理条件特定部１１２に、緊急処理用の条件を、例えば「緊急処理ｘ」の条件としてあらかじめ記憶させておく。緊急処理ｘの条件には、検査が開始されてから画像処理が開始されるまでの時間幅Ｔｘ１と、処理されるデータ量Ｄｘとが含まれる。時間幅Ｔｘ１及びデータ量Ｄｘには、過去に実施された緊急の検査の統計等から想定される値を算出して設定する。なお、緊急処理ｘの条件は、処理量算出部１２も参照する。そのため、処理条件特定部１１２は、この情報を処理量算出部１２が参照可能にしている。または、緊急処理ｘの条件を記憶する記憶部を別途設け、処理条件特定部１１２及び処理量算出部１２が、この記憶部を参照する構成としてもよい。

処理条件特定部１１２は、新たに追加された検査ｅの画像処理種別Ｃ１５、画像サイズＣ１６、及び枚数Ｃ１７の情報を参照し、これらの情報が入力されていないため、検査ｅの画像処理を「緊急処理ｘ」として特定する。なお、「緊急」である旨を示す識別子をデータとして追加し、この識別子により緊急処理であるか否かを判断してもよい。また、この場合には画像処理種別Ｃ１５、画像サイズＣ１６、及び枚数Ｃ１７の情報が入力されていてもよい。処理条件特定部１１２は、検査ｅの検査開始時間Ｃ１３に設定された「Ｔｅ１」から、「緊急処理ｘ」の条件として設定された「時間幅Ｔｘ１」経過後の時間「Ｔｅ３」を、処理開始時間Ｃ４１として算出する。また、処理条件特定部１１２は、検査終了時間Ｃ１４に設定された時間「Ｔｅ２」を基に処理終了時間Ｃ４２として時間「Ｔｅ４」を特定する。処理終了時間Ｃ４２の特定方法は第１の実施形態と同様である。

処理条件特定部１１２は、検査ａ〜ｃの予約時に既に作成されている処理管理テーブルＴＢＬ４０に、検査ｅの情報として、処理開始時間Ｃ４１及び処理終了時間Ｃ４２に特定された時間「Ｔｅ３」及び時間「Ｔｅ４」を入力する。即ち、処理管理テーブルＴＢＬ４０が更新される。

処理条件特定部１１２は、更新されたＴＢＬ４０を、予約管理テーブルＴＢＬ１０とあわせて処理量算出部１２に出力する。

（処理量算出部１２）
処理量算出部１２は、処理条件特定部１１２から予約管理テーブルＴＢＬ１０を受けると、新たに追加された検査ｅについて処理量Ｃ４３を算出する。その算出方法について、以下に具体的に説明する。

まず、処理量算出部１２は、予約管理テーブルＴＢＬ１０の中で、新たに追加された検査ｅについて、画像サイズＣ１６を参照する。このとき、検査ｅの情報には、画像処理種別Ｃ１５、画像サイズＣ１６、及び枚数Ｃ１７の情報が入力されていない。処理量算出部１２は、画像サイズＣ１６の情報が読み出せなかった場合には、その検査の画像処理を「緊急処理ｘ」として特定し、検査ごとの合計データ量を、「緊急処理ｘ」の条件として設定されたデータ量Ｄｘとして特定する。なお、画像処理種別Ｃ１５、画像サイズＣ１６、及び枚数Ｃ１７の情報が入力されている場合は、第１の実施形態と同様に検査ごとの合計データ量を算出する。

次に、処理量算出部１２は、検査ｅについて、算出された合計データ量と、処理管理テーブルＴＢＬ４０に記憶された処理開始時間Ｃ４１及び処理終了時間Ｃ４２とを基に処理量Ｃ４３を算出する。この算出方法は、第１の実施形態と同様である。算出された検査ｅの処理量Ｃ４３を「Ｄｅ」とする。処理量算出部１２は、算出された検査ｅの処理量「Ｄｅ」を、処理管理テーブルＴＢＬ４０における「検査ｅ」の行に入力する。これにより、処理管理テーブルＴＢＬ４０が更新される。

処理量算出部１２は、更新された処理管理テーブルＴＢＬ４０と、予約管理テーブルＴＢＬ１０とを、解析部１３に出力する。

（解析部１３）
解析部１３は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０を処理量算出部１２から受け、これらを依頼処理特定部１３１に出力する。

（依頼処理特定部１３１）
依頼処理特定部１３１は、処理管理テーブルＴＢＬ４０を受けて、新たに追加された検査ｅの情報を基に、サーバー２Ａで実行される検査ごとの画像処理の処理スケジュールを更新する。図１５は、検査ｅの画像処理の情報が追加された処理スケジュールを示している。

依頼処理特定部１３１は、検査ａ〜ｃの画像処理の予約を基に既に作成された負荷予測データに、検査ｅの画像処理の情報を追加する。これにより負荷予測データが更新される。図１８は、検査ｅの画像処理の追加に伴い更新された負荷予測データの一例である。

次に、依頼処理特定部１３１は、追加された検査ｅの画像処理の処理開始時間「Ｔｅ３」から処理終了時間「Ｔｅ４」までの間で、各画像処理の処理量Ｃ４３の合計Ｄが、所定の処理量Ｄ０以上となるか否かを判定する。例えば、図１８の例では、処理開始時間「Ｔｅ３」から処理終了時間「Ｔｅ４」までの間を、あらかじめ決められた単位時間幅で時間幅Ｗｂ１〜Ｗｂ７に分割している。図１８の例では、時間幅Ｗｂ１において、合計Ｄが所定の処理量Ｄ０以上となる。

依頼処理特定部１３１は、特定された時間幅Ｗｂ１において、実行が予定されている画像処理のうち、補助サーバー（即ち、サーバー２Ｃまたは２Ｄ）に代行を依頼する依頼画像処理を特定する。このとき、依頼処理特定部１３１は、あらかじめ予約されていた検査ａ〜ｃの画像処理のうち、処理が開始されていない画像処理を優先して依頼画像処理として特定する。具体的には、依頼処理特定部１３１は、時間Ｔｘと、各検査の処理開始時間Ｃ４１を比較し、時間Ｔｘ以降に開始される画像処理を特定する。例えば図１８では、時間Ｔｘにおいて、検査ａ及びｂの画像処理は既に開始されている。そのため、依頼処理特定部１３１は、検査ｃを特定する。次に、依頼処理特定部１３１は、特定された検査ｃの優先度と、新たに追加された検査ｅの優先度を比較し、優先度の低い画像処理を依頼画像処理として特定する。このとき、緊急で追加された検査（例えば、検査ｅ）は画像処理の優先度を高く設定しておくことで、この検査はメインサーバーで優先的に処理されるようになる。図１８の例では、依頼処理特定部１３１は、検査ｃの画像処理を依頼画像処理として特定する。

なお、検査ａ〜ｃの画像処理が全て開始済みの場合には、依頼処理特定部１３１は、時間幅Ｗｂ１で予定されている全ての画像処理（即ち、検査ａ〜ｃ、及びｅ）の優先度を比較し、最も優先度の低い画像処理を依頼画像処理として特定する。

補助サーバーに代行を依頼する画像処理を特定したら、依頼処理特定部１３１は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０を依頼先特定部１３２に送信する。このとき、依頼処理特定部１３１は、補助サーバーに依頼する特定された依頼画像処理（図１８の場合、検査ｃの画像処理）をあわせて依頼先特定部１３２に通知する。

（依頼先特定部１３２）
依頼先特定部１３２は、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０と、依頼画像処理の通知とを受ける。依頼先特定部１３２は、補助サーバーとして動作するサーバー２Ｃ及び２Ｄのうちのいずれかを、通知された画像処理の依頼先として特定する。この依頼先の特定に係る処理は、第１の実施形態と同様である。以降では、新たな依頼先として「サーバー２Ｃ」が特定されたものとして説明する。

依頼先特定部１３２は、特定された依頼先と、通知された依頼画像処理と、画像データの返却先Ｃ１８とを１つの組として関連付ける。依頼先特定部１３２は、作成された組と、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０とを、依頼情報作成部１３３に出力する。

（依頼情報作成部１３３）
依頼情報作成部１３３は、依頼先特定部１３２から、依頼先、依頼画像処理、及び返却先Ｃ１８が関連付けられた組と、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０とを受ける。

依頼情報作成部１３３は、依頼情報Ｅ１０が作成されていない画像処理、即ち、新たに追加された検査ｅの画像処理の依頼情報Ｅ１０を作成する。依頼情報Ｅ１０の作成方法は、第１の実施形態と同様である。

また、依頼情報作成部１３３は、依頼先特定部１３２から受けた、依頼先、依頼画像処理、及び返却先Ｃ１８の組を基に、依頼先が変更された画像処理（即ち、検査ｃの画像処理）を特定する。依頼情報作成部１３３は、特定された検査ｃの画像処理に関する依頼情報Ｅ１０の処理情報Ｅ１４を更新する。更新前の検査ｃの依頼情報Ｅ１０では、処理情報Ｅ１４に依頼先Ｅ１４２として「サーバー２Ａ」が記憶されている。依頼情報作成部１３３は、この依頼先Ｅ１４２を「サーバー２Ａ」から、新たに受けた組に依頼先として含まれる「サーバー２Ｃ」に更新する。

依頼情報作成部１３３は、作成及び更新された依頼情報と、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０とを処理制御部１４に出力する。

（処理制御部１４）
処理制御部１４は、依頼情報作成部１３３から、作成及び更新された依頼情報と、処理管理テーブルＴＢＬ４０及び予約管理テーブルＴＢＬ１０とを受ける。

処理制御部１４は、予約管理テーブルＴＢＬ１０を参照し、新たに追加された検査ｅの検査開始時間を特定する。処理制御部１４は、特定された検査開始時間にあわせて、撮影部識別子Ｃ１２で示された「撮影部１５Ａ」に撮影の開始を指示する。

また、処理制御部１４は、予約管理テーブルＴＢＬ１０を基に、作成及び更新された依頼情報Ｅ１０を通知する依頼部１７を特定する。例えば、本実施例では、処理制御部１４は、検査ｃ及びｅの依頼情報Ｅ１０を受けている。そのため、処理制御部１４は、図１６に示した予約管理テーブルＴＢＬ１０を基に、検査ｅの依頼情報Ｅ１０の通知先として、撮影部識別子Ｃ１２に記憶された「撮影部１５Ａ」を特定する。これにより、処理制御部１４は、検査ｅの依頼情報Ｅ１０の通知先として、撮影部１５Ａに関連付けて設けられた依頼部１７を特定する。なお、検査ｃについては、第１の実施形態と同様であり、処理制御部１４は、画像記憶部１６に関連付けて設けられた依頼部１７を特定する。

処理制御部１４は、処理管理テーブルＴＢＬ４０の処理開始時間Ｃ４１を参照し、検査ｃ及びｅの画像処理が開始する時間を特定する。処理制御部１４は、検査ｃ及びｅそれぞれの依頼情報を、その検査の画像処理が開始される以前に、該当する依頼部１７にあらかじめ通知する。なお、以降の処理については、第１の実施形態と同様である。

なお、依頼先特定部１３２は、サーバー２Ａ〜２Ｄの処理負荷を基に、処理負荷の低いサーバー２を依頼先として特定してもよい。この場合、サーバー２Ａ〜２Ｄに、自身の処理負荷を性能情報として通知する性能情報通知部２３を設ければよい。なお、この性能情報には、ネットワークの転送速度を示す情報を含めてもよい。ネットワークの転送速度を示す情報は、例えば、ネットワークの種別に基づき特定してもよいし、ネットワークの負荷を測定し、これに基づき算出してもよい。

依頼先特定部１３２は、サーバー２Ａ〜２Ｄの性能情報通知部２３から通知される性能情報を比較し、処理負荷の低いサーバー２を依頼先として特定することが可能となる。このように動作させることで、例えば、依頼先の候補が複数ある場合に、より処理負荷の低い方を依頼先として特定することが可能となる。

また、変形例１と同様に、本実施形態に係る医用画像処理システムにおいても、画像処理を構成する処理ごとに依頼先を設定可能としてもよい。

以上、以上のように本実施形態に係る医用画像処理システムでは、新たな予約が追加された場合においても、追加された予約を含めて、非定常的に負荷が増大する時間帯と、その時間帯で実行される画像処理を特定し、特定された画像処理の一部を補助サーバーに依頼することが可能となる。

以上のように、この発明の実施形態に係る医用画像処理システムによれば、非定常的に負荷が増大する時間帯と、その時間帯で実行される画像処理を特定し、特定された画像処理の一部を補助サーバーに依頼することが可能となる。この補助サーバーは、メインサーバーのように定常的に画像処理を実行する必要は無い。そのため、画像処理以外の処理を実行するサーバーを一時的に補助サーバーとして動作させたり、外部機関に設けられた補助サーバーを設けたりすることが可能となる。これにより、メインサーバーを増設することなく、非定常時の負荷に対応することが可能となる。

（第３の実施形態）
次に、第３の実施形態として、課金処理について説明する。ここで処理制御部１４内に負荷確認部１４０が設けられる。負荷確認部１４０は、サーバー２Ｃ−２Ｆの負荷状態から各サーバーの課金率を求め、課金率の低くなっているサーバーを選択して処理制御部１４に返す。処理制御部１４は、依頼先特定部１３２を介して選択されたサーバーに処理を依頼する。依頼先の負荷の低い時に処理を依頼すると安く課金されるので、例えば時差のある海外の病院などの最大負荷のかかる時間がずれる施設の間で、互いに処理を依頼しあい、互いに課金するためのシステムである。

負荷確認部１４０は、図１に示した処理制御部１４内の一処理機能として図１９及び図２０に図示するが、処理制御部１４の外側の別の処理部として設けてもよい。負荷確認部１４０は、処理制御部１４内にある場合でも外部にある場合でも、制御処理部１４と同様に、院外ネットワークに係るサーバー２Ｃ−２Ｆをそれぞれ監視し、その監視結果を処理制御部１４に送る。図１にサーバー２Ｃと２Ｄを示す一方、サーバー２Ｅと２Ｆは示していないが、サーバー２Ｃと２Ｄ同様、ネットワークを介して処理制御部１４に接続されており、処理制御部１４による処理の依頼の相手となっている。

まず、負荷確認部１４０は、サーバー２Ｃ−２Ｆをそれぞれ監視することにより、サーバー２Ｃ−２Ｆの負荷状態を取得する。図１９に示す例では、サーバー２Ｃの現在の負荷状態が１５％、サーバー２Ｄの現在の負荷状態が５５％、サーバー２Ｅの現在の負荷状態が７０％、サーバー２Ｆの現在の負荷状態が８５％である。

負荷確認部１４０は、上述のサーバー２Ｃ−２Ｆの現在の負荷状態を管理する監視テーブルＴＢＬ５０を備えている。監視テーブルＴＢＬ５０はさらに、課金率、処理量、課金額を含む。負荷確認部１４０は、現在の負荷状態に応じて、サーバー２Ｃ−２Ｆの課金率を確認する。課金率は、例えば監視テーブルＴＢＬ５０の例では、負荷状態が２０−５０％であれば１０、負荷状態が５０−６５％であれば１５、負荷状態が６５−８０％であれば３０、８０％を超えたら依頼拒否となっている。

この課金率は、負荷状態が上がるにしたがって上昇する値とする。上述の例のように負荷状態の範囲ごとに特定の課金率を設定してもよい。負荷状態に一定の係数を掛け合わせたものを課金率としてもよい。関数やグラフを介して課金率を設定してもよい。このように求められた課金率は処理制御部１４に送られ、処理制御部１４は、課金率にしたがって依頼先を特定する。

監視テーブルＴＢＬ５０の例では、サーバー２Ｃの課金率が最も低いので、処理制御部１４は、外部の依頼先に送る処理をすべてサーバー２Ｃに送るという判定をすることができる。その一方で１つのサーバーに送る処理量について上限を設けておくこともできる。例えば監視テーブルＴＢＬ５０の例では、上限を９０とする。この場合、処理制御部１４は、依頼すべき処理量が１１０であるとすると、最も課金率の低いサーバー２Ｃに送る処理量を上限の９０とし、残りの２０を次の課金率の低いサーバー２Ｄに送ると判定する。判定結果を依頼先特定部１３２に送り、依頼先特定部１３２は依頼処理を実行する。

その結果、負荷確認部１４０は、課金率に処理量を乗じて課金額を求める。この課金額は、負荷確認部１４０によって求められる支払の一例である。監視テーブルＴＢＬ５０の例では、サーバー２Ｃによる課金額は９００となり、サーバー２Ｄによる課金額は３００となる。サーバー２Ｅ、２Ｆには処理の依頼がされないので課金されない。

また、処理を依頼することにより、依頼先のサーバーの負荷状態が上がり、許容量を超えてしまう場合もある。その場合は負荷状態を適時に監視又は予測し、負荷状態が許容量を超える処理依頼は中止する。また、処理を依頼することにより依頼先のサーバーの負荷状態が上がり、課金率の境界値を超える場合もある。例えば依頼前は負荷状態が４８％であったが、処理を依頼することにより、負荷状態が最終的には５５％になるということもありうる。その場合には、負荷状態が５０％に達するまでの処理量には負荷状態が５０％未満の場合（この場合１０）を乗じ、負荷状態が５０％を超えたときの処理量には負荷状態が５０％以上の場合（この場合１５）を乗じるという分け方をすることができる。

一方、依頼した処理毎の最大負荷量で課金額が決まる場合もある。例えば、課金率が最も低いサーバー２Cに処理量１１０を全て依頼した場合に、サーバーCの負荷状態の最大値が５２％になるとする。この場合は処理量１１０に対し、１５が乗じられるので合計課金額は１６５０となる。このような場合は、先ほどの例のように最も課金率の低いサーバー２Ｃに送る処理量を上限の９０とすれば、サーバーCでの課金額が処理量９０に１０を乗じて９００、サーバーDでの課金額が処理量２０に１５を乗じて３００、合計１２００となり、サーバーCに処理量１１０を依頼する場合より安くなる。

以上のように構成することにより、処理の依頼量と依頼先の状況にしたがった適切な課金のもとで、適切な処理の負荷分散が可能になる。

次に、相互に依頼処理をすることにより相互に課金する例について図２０を参照して説明する。図１９を用いた例の場合は、外部のサーバーに依頼をして課金を一方的に受ける場合について説明したが、逆にサーバー２Ａ、２Ｂの処理負荷が小さく、外部のサーバー２Ｃ−２Ｆの処理負荷が大きい場合には外部から処理依頼を受けることにより、逆に課金をすることもできる。このように、ある場合には処理の依頼をして課金を受け、他の場合には処理の依頼を受けて課金をするというように、処理分担を交代することもできる。

院内ネットワークの負荷確認部１４０は、図１９を用いて説明したように、サーバー２Ｃ−２Ｆを監視しており、監視テーブルＴＢＬ５０により管理している。一方で院外ネットワークに接続されているサーバー２Ｃと２Ｄのシステム、サーバー２Ｅと２Ｆのシステムにも、それぞれ負荷確認部１５０が設けられ、監視テーブルＴＢＬ６０を備えている。それぞれのシステムの負荷確認部１５０は、サーバー２Ａと２Ｂの負荷状態を監視している。

図２０の例では、院内ネットワークのシステムは処理依頼を出していない状態なので、監視テーブルＴＢＬ５０に示す処理量も課金額もいずれも０である。この状態で院外ネットワークの負荷確認部１５０がサーバー２Ａの負荷状態１５％、サーバー２Ｂの負荷状態６０％を確認する。負荷確認部１５０は、得られた負荷状態の値からそれぞれ課金率１０％、１５％を求める。そして各システムの処理制御部（図示しない、院内ネットワークでは処理制御部１４に対応）が、課金率の低いサーバー２Ａを選択する。そして４０の処理量がサーバー２Ａによって実行され、課金額は４００となる。これらが、監視テーブルＴＢＬ６０によって管理される。

以上のように構成することにより、相互に処理を依頼することにより相互に課金することができるので、処理の負荷分散が可能になるとともに、処理の総計での負担量に偏りがある場合に、適切に課金することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載されたその均等の範囲に含まれる。

１１ 予約管理部
１１１ 予約受付部
１１２ 処理条件特定部
１２ 処理量算出部
１３ 解析部
１３１ 依頼処理特定部
１３２ 依頼先特定部
１４ 処理制御部
１５Ａ、１５Ｂ 撮影部
１６ 画像記憶部
１７ 依頼部
２Ａ、２Ｂ、２Ｃ、２Ｄ サーバー
２１ 画像処理部
２２ 転送部
３Ａ、３Ｂ、３Ｃ 端末

Claims (9)

1. 医用画像の画像データに対する画像処理を複数並列に実行する画像処理部を備えたサーバーを複数備えた医用画像処理システムであって、
   前記画像処理の処理予約を受けて、予約された前記画像処理の処理開始時間及び処理終了時間と、当該画像処理の処理対象である前記画像データのデータ量とを当該処理予約に基づき画像処理ごとに管理する予約管理部と、
   前記複数のサーバーのうち第１のサーバーで実行される各画像処理について、前記処理開始時間及び前記処理終了時間と、前記データ量とを基に、当該画像処理において所定の時間幅あたりに処理される処理量を算出する処理量算出部と、
   前記第１のサーバーで実行される前記画像処理の前記処理開始時間及び前記処理終了時間と、当該画像処理の前記処理量とに基づき、前記時間幅ごとに、当該時間幅中に並列で実行される画像処理の前記処理量の合計を算出し、算出された前記合計が所定の処理量以上の場合に、第１のサーバーの前記処理量の合計が前記所定の処理量未満となるように、当該時間幅中に実行される画像処理のうち少なくとも１つを含む第１の画像処理を特定する解析部と、
   前記第１のサーバーとは異なる第２のサーバーに前記第１の画像処理を依頼する依頼部と、
   を備えた医用画像処理システム。
2. 前記予約管理部は、操作者の指示に基づき、前記第１のサーバーで実行される前記画像処理を前記処理予約を受けた後に重み付けし、
   前記解析部は、前記重み付けに基づき前記第１の画像処理を特定することを特徴とする請求項１に記載の医用画像処理システム。
3. 被検体を撮影して前記画像データを生成する撮影部を備え、
   前記予約管理部は、前記撮影部での撮影の開始時間及び終了時間と、撮影される画像データの前記データ量とを含む検査予約を受けて、前記検査予約に含まれる前記データ量を基に当該撮影にかかる撮影時間を算出し、当該撮影の前記撮影時間、前記開始時間、及び前記終了時間を基に前記処理開始時間と前記処理終了時間とを特定することを特徴とする請求項１または請求項２に記載の医用画像処理システム。
4. あらかじめ生成された前記画像データを記憶する記憶部を備え、
   前記予約管理部は、前記記憶部に記憶された前記画像データに対する前記画像処理の前記処理開始時間及び前記処理終了時間を含む前記処理予約を受けることを特徴とする請求項１乃至請求項３のいずれかに記載の医用画像処理システム。
5. 前記第１の画像処理を前記第２のサーバーに依頼後に、前記予約管理部が、前記画像処理の前記処理予約を新たに受けた場合に、
   前記解析部は、新たに予約された当該画像処理の前記処理開始時間から前記処理終了時間までの間で、当該画像処理の前記処理量と、前記第１のサーバーで実行される各画像処理との合計を算出し、当該合計が前記所定のデータ処理量以上の場合に、当該時間幅中に実行される画像処理のうち、前記第２のサーバーに処理を依頼する少なくとも１つの第２の画像処理を特定することを特徴とする請求項１乃至請求項４のいずれかに記載の医用画像処理システム。
6. 前記複数のサーバーは、種別が異なる画像処理を実行可能なサーバー群を含み、
   前記解析部は、前記サーバー群に含まれる前記サーバーそれぞれが実行可能な前記画像処理の種別をあらかじめ記憶し、前記第１の画像処理の種別を基に、前記サーバー群の中から、当該第１の画像処理を実行可能な前記サーバーを、前記第２のサーバーとして特定することを特徴とする請求項１乃至請求項５のいずれかに記載の医用画像処理システム。
7. 前記複数のサーバーは、自身の処理負荷を前記解析部に通知する通知部をそれぞれ備えたサーバー群を含み、
   前記解析部は、前記処理負荷を基に、前記サーバー群の中から前記第２の画像処理を依頼する前記第２のサーバーを特定することを特徴とする請求項５に記載の医用画像処理システム。
8. ネットワークに接続された他のサーバーの負荷状態を監視し、前記負荷状態と前記第２のサーバーに依頼する前記第１の画像処理の処理量に基づいて、前記第１の画像処理の依頼に対する支払を求める負荷確認部をさらに備える請求項１に記載の医用画像処理システム。
9. 前記複数のサーバーは、ネットワークに接続された他のサーバーの負荷状態を監視し、前記負荷状態と前記他のサーバーに依頼する前記第１の画像処理の処理量に基づいて、前記第１の画像処理の依頼に対する支払を求める負荷確認部をそれぞれ備える請求項６に記載の医用画像処理システム。

Images