JP4605732B2 - 医用撮像装置から得られる運用データの収集の自動監視 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は一般的には、遠隔配置されており利用者が運用する電子装置、例えば医療診断に用いられる撮像装置から得られる運用データを編集し及び／又は要約したリポートの集中型生成に関する。
【０００２】
【発明の技術的背景】
診断用イメージング・システムは、現在の健康管理施設の至る所で利用されている。かかるシステムは、身体の状態を識別し、診断して治療するための重要なツールを提供しており、診断のための外科的な介入の必要性を大幅に減じている。多くの場合には、担当医師又は放射線技師が、１種以上の撮像モダリティを介して関連のある部位及び組織の詳細な画像によって従来式の検査を補完して初めて、最終的な診断及び治療が開始する。
【０００３】
現在、医用診断イメージング・システムとして多くのモダリティが存在している。これらのモダリティには、計算機式断層撮影（ＣＴ）システム、Ｘ線システム（従来式のイメージング・システム及びディジタル式イメージング・システムの両方を含む）、磁気共鳴（ＭＲ）システム、ポジトロン・エミッション断層撮影（ＰＥＴ）システム、超音波システム及び核医学システム等がある。多くの場合に、これらのモダリティは互いに補完し合って、特定の種別の組織、器官及び生理系等を撮像するための広範な手法を医師に提供している。健康管理施設はしばしば、単一の施設又は多数の施設に様々なこれらのイメージング・システムを配置しており、具体的な患者の必要性によって要求されると施設の医師がかかる資源を利用できるようにしている。
【０００４】
現在の医療診断イメージング・システムは典型的には、画像データを取得すると共に、データを、後に患者の体内の関心のある特徴の再構成画像を作成するように処理される有用な形態へ変換するサーキットリ（回路要素）を含んでいる。この画像データ取得及び処理用サーキットリを、撮像過程の一部として物理的又は電子的な走査が生じさえすればモダリティに拘わらず「スキャナ」と呼ぶものとする。システム及び関連するサーキットリの特定の構成要素は、物理的原理及びデータ処理要求が異なっているので、当然モダリティ間で大幅に異なっている。本書では、「スキャナ」、「医用撮像装置」及び「診断用撮像装置」なる用語は互換的に用いられる。
【０００５】
上述した形式の医療診断システムはしばしば、かなりの有効寿命にわたって要求された日程の範囲内で信頼性があり且つ理解可能な画像を生成することが要求される。適正な動作を確実に行なわせるために、システムは高度な訓練を受けた人員によるサービスを定期的に受けて、この人員が撮像上の問題に対処し、システムを構成設定及び較正すると共に、定期的なシステム点検及びソフトウェア更新を行なう。さらに、近年では、サービスの提供が、契約加入施設のスキャナに直接接触可能なサービス・センタによって補われており、施設人員の一部を割いて介入する必要性がなくなっている。かかる集中型サービス提供は、医師又は放射線技師が注意を払う必要なしに診断システムを良好な動作状態に維持することを目的としており、施設から見ると全く透明である場合が多い。
【０００６】
幾つかの集中型サービス提供システムでは、コンピュータ化されたサービス・センタがネットワークを介してスキャナに接触して、システム構成及び動作状態を点検し、リポート生成用のデータを収集すると共に、他の有用なサービス機能を果たす。かかる接触はシステム「スイープ(sweep) 」時等に定期的に行なうことができる。このシステム・スイープ時には、特定のスキャナについて様々なシステム性能データが収集されて、履歴データと共に記憶される。次いで、これらのデータを用いてシステム性能を評価して、サービス人員の訪問を提案し又は予定に組む等を行なうことができる。
【０００７】
かかるサービス手法は、診断システムを保守するのに極めて有用であることが分かっているが、改良の余地は依然としてある。スキャナとサービス・センタとの間の対話的相互作用（interaction）が透明であるので、医療人員がサービス更新によって不必要に煩わされることは回避されるが、サービス・センタと施設との間にはある程度の対話的相互作用があることが極めて望ましい。具体的には、対話型サービス・システムであれば、システム性能のリポート、注意を要する特定の事象についてのフィードバック、並びにシステム・ライセンス、ソフトウェア及び撮像プロトコルの更新等を含めた有用な情報交換が容易になる。現状で利用可能なサービス・システムはかかる対話型交換が可能である。具体的には、異なるモダリティが対話型サービスの提供を必要とする場合の基地としての役割を果たすプラットフォームが開発されている。このプラットフォームによって、中央サービス・センタが、遠隔配置されたスキャナと、可能性のあるサービス上の問題についての情報を交換することができ、またこれらのスキャナにサービス提供を行なう目的でスキャナから情報又はデータ・ログ・ファイルを検索することが可能になる。一つの公知のプラットフォームは、医師及び放射線技師が異なるモダリティの様々なスキャナを運転したり、統一的な直感的な形式を介してスキャナについてのサービス上の問題を報告したりすることを可能にする統一的インタフェイスを設けている。
【０００８】
遠隔位置に設けられている診断設備にサービス提供するための公知の統合型利用者対話型プラットフォームは、スキャナ側のソフトウェア、ハードウェア若しくはファームウェアにおいて構成設定されていてもよいし、又は医療施設内の様々なスキャナを結合する中央操作者ステーションに設けられていてもよい。ユーザ・インタフェイスによって、診断設備に対して実行される検査の前、途中又は後に、サービス要求を生成することが可能になる。ユーザ・インタフェイスはまた、サービス・メッセージ送信、リポート生成及び検索等を可能にする。ユーザ・インタフェイスは好ましくは、ネットワーク・ブラウザとして構成されており、イントラネット又はインターネット等のネットワークにスキャナ又は中央施設制御ステーションを結合することも容易にしている。また、同じユーザ・インタフェイスを異なるモダリティのスキャナに組み入れることにより、運転人員によるサービス要求等をさらに容易にすることができ、運転人員が施設の多様なインタフェイスに改めて精通する必要がない。
【０００９】
具体的には、既存の利用者対話型プラットフォームは、遠隔施設のスキャナの運用履歴に基づくスキャナの利用状況リポートを中央サービス・センタから要求する能力をシステム利用者に与えている。かかる利用状況リポートを作成するためには、これらのスキャナから運用データを定期的に収集することが必要である。既存のシステムによれば、スキャナをプログラムして、スキャナ自身の運用データをコンピュータ・メモリに収集し、次いで、このデータを、中央施設がスキャナに入力した予めプログラムされている予定に従って中央施設に先行的に送信しておくようにすることができる。データ・ログ記録及びリポート生成を可能にするサービス契約によってカバーされているスキャナのみが、中央施設に対しログ記録された運用データを送信することになる。中央施設は、契約によってカバーされているすべてのスキャナからの運用データのログ・ファイルを収集して処理した後に、スキャナ利用状況リポートを生成することができる。具体的には、病院の管理者は、広域ネットワーク又はインターネットを介して、当該病院において契約下にある医用撮像装置（すなわちスキャナ）について収集された運用データを編集し且つ／又は要約した利用状況リポートをいつでも要求することができる。
【００１０】
中央サービス施設に収集され記憶されている運用データが不完全であると、顧客が要求したあらゆるレポートは、当然のことながらこの不完全なデータに依存した結果を有しているため不正確になり、誤解を与える虞がある。従って、データ収集を自動的に監視して、データが医用撮像装置から適正に収集されていない場合には修正処置を講じることのできるような系統的な方法が必要とされている。
【００１１】
【発明の概要】
本発明は、遠隔配置された多数の医用イメージング・システムからの運用データの定期的な収集を中央サービス施設によって監視し、運用データの収集が、データ源から受領されるデータの受領頻度及び容量に基づいて履歴的基準値から逸脱している場合には修正処置過程を開始する方法及びシステムを指向している。このシステムは、最も最近の受領時のデータの量又は最も最近の２回のデータ受領の間の時間のいずれかが、対策的処置を要求するような方式で変化したときをスキャナ単位で自動的に判定する。
【００１２】
本発明の好適実施形態によれば、中央サービス施設のコンピュータが医用撮像装置から運用データを受領する度毎に、データを受領した時刻及び受領したデータの量をデータベースに記憶する。本書では、このデータベースを「ログ受領履歴テーブル」と呼ぶ。定期的タスクがこのデータベースを検査して、特定のスキャナから最も最近に受領したデータ・ファイルの受領日付又は容量が、当該スキャナからの最近のデータ収集が不成功又は不完全であったことを示しているか否かを判定する。一つの好適実施形態によれば、この定期的タスクは、当該スキャナからのデータ・サイズの履歴的平均と、当該スキャナから最も最近に受領したデータ・ファイルのサイズとが、所定の量を超えて、例えば所定の百分率を超えて異なっているか否かを判定する。もう一つの好適実施形態では、定期的タスクは、当該スキャナからの連続したデータ受領の間の履歴的平均時間と、当該スキャナから最も最近に受領した２つのデータ・ファイルの間の時間とが、所定の量を超えて、例えば所定の百分率を超えて異なっているか否かを判定する。さらなる好適実施形態によれば、定期的タスクは、最も最近に受領したデータ・ファイルのデータ容量を履歴的平均データ容量と比較すること、及び最も最近に受領した２つのデータ・ファイルの間の時間間隔をデータ受領の間の履歴的平均時間と比較することの両方を行なう。スキャナの運用データのスキャナによる送信が不適当又は不完全であることを示すような履歴的平均からの逸脱が生じていた場合には、中央サービス施設のコンピュータが、遠隔配置されたスキャナを自動的に初期化し直してデータを送らせると共に、適当なシステム管理者に通知する。
【００１３】
【好適実施形態の詳細な説明】
本発明は、放射線部門の業務、処理、患者フロー及び臨床実務を支援するための情報を提供するシステム及び方法を指向している。放射線部門に設けられている各々のスキャナが、処理のために中央サーバへ運用データを送付する。収集されるデータは、キー部門の生産性、質、並びに患者の満足度の目標及び課題に基づいてキーのスキャナ・パラメータを測定するものである。収集されたデータに基づいて、中央位置においてスキャナの利用状況レポートが生成される。これらのリポートには、インターネットを介して顧客がアクセスすることができる。スキャナは、計算機式断層撮影（ＣＴ）システム、磁気共鳴（ＭＲ）システム、超音波イメージング・システム又は他の任意の形式の計算機式医用撮像装置を包含している。
【００１４】
図１に、データ及び処理の高レベルでのフローを示す。各々のスキャナ２が、収集及び変換のために中央プロセッサ４へ運用データのログを送付する。変換されたデータは、顧客／施設データベース６から読み出した医療設備のプロフィール・データと共にデータ記憶部８に記憶される。記憶されたデータは、リポート発行システム１０へ定期的に送付される。顧客１２は、セキュリティ・サーバ１４に対し、有効性のある認証セキュリティ因子（例えば、ＩＤ及びパスワード）を入力するとこれらのリポートにアクセスすることができる。セキュリティ・サーバは、リポート発行システム１０へ有効性確認を送る。
【００１５】
図２を参照して述べると、各々のスキャナ２から、モデム１８、私設ネットワーク２０又は他の任意の適当な通信チャネルを介して自動サポート・センタ・サーバ１６によってデータが収集される。各々のスキャナは、所定の運用関連データをログ記録した後に、ログ記録したデータを自動サポート・センタ・サーバ１６へ送付するようにプログラムされている。
【００１６】
好ましいスキャナ出力フォーマットは、システム・データと検査データとを含んでいる。システム・データには、新たな検査が開始したときに示された時刻スタンプ、スキャナ・モダリティ、製品名、システムＩＤ（すなわち、特定の顧客の特定の位置でのスキャナに固有のＩＤ）、所謂固有システム番号（ＵＳＮ。時間、位置及び所有者に拘わらないスキャナの固有キー）、所謂移動位置番号（ＭＬＮ。特定の時刻のスキャナの特定の位置を追跡するのに用いる）、並びに病院名等があるがこれらに限定されない。検査データには、同じ時刻スタンプ、検査日付、検査の開始時刻及び終了時刻、検査番号、患者ＩＤ、患者年齢、患者性別、患者体重、患者病歴、患者状態、放射線技師ＩＤ、担当医ＩＤ、操作者ＩＤ、検査説明、検査データ、検査系列、並びに検査形式等を所謂カレント・プロトコル・ターミノロジ（ＣＰＴ）・コードの形態にしたものがあるがこれらに限定されない。スキャナは、先行的診断転送機構を用いて自動サポート・センタ・サーバ１６へこのデータを転送する。先行的診断データ転送機構を実現する場合には、スキャナはデータ・ログ記録サービスＩＤを用いる。スキャナは、最後の転送からの時間に基づいて、又はデータが所定のサイズ閾値に達した場合に、このデータを転送するようにプログラムされている。転送間の最長時間、及びデータ・サイズ閾値は、スキャナ単位で構成設定可能である。また、運用データが自動サポート・センタ・サーバへ送付される時刻もスキャナ単位で構成設定可能である。
【００１７】
自動サポート・センタ・サーバ１６は、ＵＳＮ、ＭＬＮ又はこれら２つの組み合わせによってスキャナ・データ・ファイルを記憶する。自動サポート・センタ・サーバ１６は、データ・ログ記録サービスＩＤと共に送付された新たなファイルが到着した場合には必ず、サービス提供者の内部ネットワークを介して運用サーバ２２に当該ファイルを送付することにより運用サーバ２２に通知する。自動サポート・センタ・サーバ１６は、運用サーバ２２へデータ・ファイルを送付することに成功しなかった場合には、エラー・メッセージをログ記録して、適当なシステム管理者に通知する。自動サポート・センタ・サーバ１６はまた、有効性のあるサービス契約に従ってログ記録データのリポートを得る認証を受けているスキャナ・システムに対し、システム管理者がデータ・ログ記録の特徴及び先行的診断データ転送を遠隔からイネーブルにしたりディスエーブルにしたりできるようにする機構を提供している。スキャナ・サイトが起動され又は停止された場合には、自動サポート・センタ・サーバ１６は、スキャナ・サイトの新たな状態を運用サーバ２２に通知する。
【００１８】
運用サーバ２２は、自動サポート・センタ・サーバ１６からスキャナ・データをログ記録したファイルが到着したとのメール通知を受け取ると、スキャナ・ファイルの有効性を確認する。有効性確認は次の工程を含んでいる。ファイルの「文法」（例えばＭＲ又はＣＴ）を識別する工程、及びサービス製品についてのすべてのフィールドがレコードに存在しており正しい形式となっていることを検証する工程。レコードが完全でなく（すなわちフィールドが欠落している）又は不正確である場合には、レコードをログ記録して削除する。運用サーバ２２は、スキャナ・ファイルのデータ・フィールドの値に基づいてＣＰＴコードを生成する。運用サーバ２２はまた、要求されたフィールドを所定のＸＭＬフォーマットに符号化する。ファイルが処理されたら直ちに、運用サーバ２２は、圧縮ＸＭＬフォーマットの処理済（すなわち変換済）スキャナ・ファイルをサービス提供者の内部ネットワークを介して作成サーバ２８へ送付する。
【００１９】
運用サーバ２２はまた、どのスキャナ・サイトがデータを送付しているか、送られたデータの量、及びデータを受領した時刻を記録する。運用サーバは、保守サービス取り決め（ＭＳＡ）に関連する契約情報によって稼働する作動中サイト一覧／データベースを保持している。ＭＳＡサービス契約情報は、サービス提供者の内部ネットワークを介してＭＳＡ中間処理（staging）サーバ２６から運用サーバによって毎日受領される。サーバ２６は次に、ＭＳＡ契約情報データベース２４から契約情報を検索する。運用サーバ２２は、作動中サイト一覧にあるスキャナ・サイトが構成設定可能な時間にわたってファイルを提出していなければシステム管理者に通知する。また、運用サーバ２２は、データ頻度及びサイズの履歴をスキャナ単位で表示するウェブ・ページを提供する。これはシステム管理の目的のためである。
【００２０】
データ記憶部３０は、ＸＭＬ符号化されたスキャナ・データを、運用サーバ２２によってデータが送付されたら必ず、作成サーバ２８から受領する。検査間時間及び検査時間等の導出されるデータ値は作成サーバ２８によって算出され、データベース３０に記憶される。データ記憶部３０はまた、ＸＭＬ符号化された施設プロフィール・データを、運用サーバ２２によってデータが送付されたら必ず、作成サーバ２８から受領する。
【００２１】
本発明の好適実施形態によれば、セキュリティ・サーバ１４はリポート・サーバ３２から物理的に離隔している。また、セキュリティ・サーバ・データベースはリポート・サーバ・アプリケーション・データベースから離隔している。すべてのリポートへの顧客のアクセスは、インターネット３４上の所謂セキュア・ソケット・レイヤ（Secure Socket Layer、ＳＳＬ）を介して行なわれる。顧客は、インターネット３４を介してセキュリティ・サーバ１４へ利用者ＩＤ及びパスワード又はアクセス・コードをアップロードしなければならない。すべての利用者パスワード又はアクセス・コードは暗号化される。セキュリティ・サーバ１４は、利用者の有効性を確認し、利用者の所属資格を判定して、アクセス特権を割り当てる。アクセス特権によって、当該顧客のサービス契約に基づいて顧客がどのリポートを利用できるかが決まる。セキュリティ・サーバ１４は、有効性が確認された利用者が、リポート・サーバ３２から提供されインターネット３４を介して顧客側アクセス・ステーションへ送信される適当なリポートにアクセスすることを許可する。
【００２２】
リポート・サーバ３２によって生成されるすべての利用状況リポートは、作成サーバ２８に送付されたスキャナ・データに基づく。すべての図形的リポートが、出力の外観を変更する構成設定可能な表示オプション（円グラフ、棒グラフ等）をサポートしている。好ましくは、リポート・サーバ３２は、Windows 95／98／NTプラットフォーム上でInternet Explorer 4.01以上、及びNetscape 4.5以上と互換性のある利用状況リポートを発行する。クライアントが互換性を有していなければ、メッセージを利用者に送って、互換性のあるブラウザへのリンクを表示する。リポート・サーバはまた、リポートのための時間軸の構成設定可能な選択肢を提供するようにプログラムされている。リポート・サーバは、傾向を示すリポート及び対基準評価を示すリポートを生成する。
【００２３】
多数のリポートのひな形がサポートされている。これらのひな形は、その各々が多数のリポートを含むグループにグループ分けされる。各グループへのアクセスは、利用者アクセスに基づいたものとしてよい。例えば、リポート・サーバは、スタディ・ミックス（study mix、研究構成）、スタディ量、スタディ形式毎の画像データ及び系列データ、スタディ・ミックス毎の量、時間及び曜日毎のスタディ・ミックス、スタディ・ミックス毎の検査時刻、検査期間毎のペイシェント・ミックス（patient mix、患者構成）、時刻毎の検査量、曜日毎のシステム利用状況、スタディ・ミックス毎のＣＴ走査の処理時間、スタディ・ミックス毎の検査内時間、検査期間、放射線技師毎の量、担当医毎の量、放射線技師毎のＣＴ走査の処理時間、検査技師毎の検査時間、年齢毎の患者量（男性及び女性）、担当医毎のスタディ・ミックス（検査回数）、放射線技師毎のスタディ・ミックス（検査回数）、並びに放射線技師毎の検査当たりの系列及び画像数を示すリポートを生成し発行することができる。
【００２４】
本発明の好適実施形態は、患者へのサービス提供のうち「検査」段階を中心とした臨床実務（スタディ、ミックス）、運用管理（量、利用状況）、及び顧客の人口統計的分析（担当医、患者年齢等）について、重要な決定を支援する情報を放射線部門に与えるウェブ送付式サービス製品又はサービス能力である。
【００２５】
好適実施形態によるシステムは、決定支援リポートを生成するのに二つの形式のデータすなわちスキャナ・ログ・データ及び施設プロフィール・データを利用する。施設プロフィール・データは、会計記録及びデータの対基準評価の目的のために保持されている。
【００２６】
好適実施形態によるデータ・リポート発行過程は、サービス契約管理過程に組み入れられている。スキャナ利用状況リポート発行サービス契約に基づく施設プロフィール・データが取得されて処理される。このサービス契約情報に基づいて、スキャナ上でのデータ・ログ記録動作を自動的に制御する機構すなわち起動し停止させる機構が確立される。運用サーバが、毎日の作成時にスキャナ状態の記録を取る。ウェブ方式ユーザ・インタフェイスを用いて、顧客、契約及びスキャナ状態に関連した情報を管理する。
【００２７】
インターネットを介して送信された顧客の要求に応答して、遠隔のスキャナから中央オフィスへの自動データ・ログ記録、及び中央オフィスによるデータのリポート発行を提供する各々のサービス契約は、少なくとも次の情報を有している。（１）サービス提供者と契約を交わした顧客名。顧客は、多数の病院から成る団体、多数箇所に分かれた病院施設又は単一箇所の病院施設のいずれであってもよい。（２）契約下にカバーされている病院施設名。多数の病院から成る団体型の顧客でない場合には、施設は顧客と同じであってよい。（３）スキャナが設置されている病院施設の詳細な住所。所番地、都市、州、国及び郵便番号を含む。（４）契約下にカバーされている各々の病院施設の各スキャナのシステムＩＤ。（５）各々のスキャナ毎に多階層サービスのどの階層が契約下にあるかを示す標識子。（６）各々のスキャナ毎の契約開始日。（７）契約終了日。すべてのスキャナで同じになる。（８）利用者契約情報。
【００２８】
図３は、顧客プロフィール・データ、契約データ及びスキャナ状態データのデータ・フローを示す。本発明の好適実施形態によれば、中央サービス施設の運用サーバ２２（図２を参照）は、「契約テーブル」及び「スキャナ状態テーブル」を保持している。加えて、運用サーバ２２は、「ログ受領履歴テーブル」を保持するデータ・プリプロセッサ（図示されていない）を組み入れている。これら３つのテーブルのすべてがOracleデータベース内に備えられている。「契約テーブル」はデータベース３０内で毎日更新される。
【００２９】
ＭＳＡ中間処理サーバ２６（図２を参照）は、ＭＳＡ契約データベース２４のような既存のデータ源から顧客プロフィール・データ及び契約データを抽出するようにプログラムされている。有効性のあるスキャナ利用状況リポート発行サービス契約によってカバーされているあらゆるスキャナ２が「抽出出力ファイル」３８（図３を参照）内にレコード（１又は複数）を有している。一つのスキャナは、スキャナが有する多数のサービス契約を反映して多数のレコードを有していてもよい。「抽出出力ファイル」は、ファイルが生成された日時を含めたヘッダ行を有する。「抽出出力ファイル」の各々の記録が、付録の表１に定義されているようなデータ・フィールドを有している。
【００３０】
好ましくは、出力ファイルは、ファイルの１行が１つのレコードを表わしており「｜」を区切り文字とするフラット・ファイルである。好ましくは、ファイルは毎日生成される。「抽出出力ファイル」はＭＳＡ中間処理サーバ２６に記憶されており、運用サーバ２２によるアクセスが可能である。「抽出出力ファイル」は毎日の更新時に上書きされてもよい。
【００３１】
図２に示す好適実施形態によれば、運用サーバ２２はＭＳＡ中間処理サーバ２６からスケジュール、例えば毎日の所定の時刻といったスケジュールに従ってＭＳＡ抽出ファイルを取り出す。運用サーバ２２は、抽出ファイルを、成功するまで１時間に１回ずつ取り出そうと試みるようにプログラムされている。運用サーバは、所定の回数、例えば５回にわたってファイルの取り出しが失敗したら「事象ログ」に「警報」を記録する。運用サーバはファイル名を、YYYY、MM、DDを受領日のそれぞれ年、月、日としてScanPATH#YYYYMMDD.txt と改める。
【００３２】
好適実施形態によれば、運用サーバは、データ源から抽出されたすべての顧客プロフィール・データ及び契約データを記憶する「契約テーブル」との名称のデータベース・テーブルを保持している。「契約テーブル」は１つのスキャナについて１つのレコードを有している。有効性のあるスキャナ利用状況リポート発行サービス契約によってカバーされているあらゆるスキャナが「契約テーブル」内にレコード（１又は複数）を有する。「契約テーブル」の各々のレコードは、付録の表２に定義されているようなデータ・フィールドを有する。「契約テーブル」の第１キーは、「システムＩＤ」／「契約番号」／「認知キー（Ｒｅｃ−Ｋｅｙ）」の組み合わせである。
【００３３】
運用サーバ２２はまた、「契約テーブル」への挿入及び変更のすべてを記録する「契約監査テーブル」との名称のデータベース・テーブルを保持している。契約監査テーブルは、表２のフィールド１〜４１について「：旧値」及び「：新規値」のためのフィールドを有し、また、監査レコードが挿入されたときの日時スタンプのためのフィールドを有している。挿入を追跡するために「契約テーブル」に「挿入トリガ」が設けられており、「契約監査テーブル」の「：新規値」フィールドに、挿入されたレコードを追加できるようにしている。変更を追跡するためには「契約テーブル」に「変更トリガ」が設けられており、「契約監査テーブル」に、変更されたレコードを「：旧値」及び「：新規値」について追加できるようにしている。表２の「監査変更要否」の欄に「要」とマークされたいずれかのフィールドが変更されると、「契約テーブル」は「変更トリガ」を起動して、レコードは決定支援の特徴を有するようになる。
【００３４】
図４に示す流れ図に従って述べると、発効中の契約に対応する「抽出出力ファイル」の次のレコードＹが運用サーバによって読み出されて（ステップ４０）、カレントの「契約テーブル」のレコードと比較される。本発明の好適実施形態によれば、「ＭＳＡ抽出出力ファイル」からの契約のうち次の条件の１つを満たすものが「契約テーブル」の「新規レコード」である（図４のステップ５６、６０及び７４）。（１）「契約テーブル」に以前に存在していない「契約番号」を有する（図４の判定ブロック５４によって決定される）。（２）「契約テーブル」に以前に存在していない「システムＩＤ」を有する（図４の判定ブロック５８によって決定される）。（３）「契約認知キー」フィールドに値１（将来）を有し、且つ同じ「契約番号」及び「システムＩＤ」を有する「契約テーブル」からの固有のレコードが見出される（図４の判定ブロック７０によって決定される）が、このレコードは代わりに「契約認知キー」フィールドに値０（現在）を有する（判定ブロック６２によって決定される）。次の条件を満たす「ＭＳＡ抽出出力ファイル」からの契約は、「契約テーブル」の「無変更レコード」である（図４のステップ４６）。「契約テーブル」の既存のレコードとすべてのデータ・フィールドが完全に一致する（図４の判定ブロック４２によって決定される）。次の条件の１つを満たす「ＭＳＡ抽出出力ファイル」からの契約は、「契約テーブル」の「変更レコード」である（図４のステップ５２及び６８）。（１）同じ「契約番号」、「システムＩＤ」及び「契約認知キー」を有する固有のレコードが「契約テーブル」から見出されるが、少なくとも１つの他のフィールドについて当該レコードと異なる値を有する（図４の判定ブロック４８によって決定される）。（２）同じ「契約番号」及び「システムＩＤ」であるが「契約認知キー」の値が１である固有のレコードが「契約テーブル」から見出される（図４の判定ブロック６４によって決定される）一方で、当該レコードは値０を有する（判定ブロック６２によって決定される）。これは、将来の契約の時期が到来したことを表わす。最新の「ＭＳＡ抽出出力ファイル」に含まれていない「契約テーブル」内のレコードは、「除去レコード」である。構文解析アルゴリズムの様々な段階（すなわち図４のブロック４４、５０、６６及び７２）において、構文解析されているレコード内のデータにエラーが検出された場合にエラー標識子が生成される。
【００３５】
最新の「ＭＳＡ抽出出力ファイル」から「新規レコード」が識別されたら、「契約テーブル」に新規レコードが追加される。「処理日」の値はカレントのシステム日付に設定される。「契約猶予期間終了日」の値は契約終了日から所定の日数後に設定される。「契約状態」フィールドは値Ｌ（発効中）に設定される。「レコード状態」フィールドはＡ（追加）に設定される。他のすべてのフィールドの値は「ＭＳＡ抽出出力ファイル」からのレコードに従って設定される。
【００３６】
「契約テーブル」のレコードは、「無変更レコード」と定義された場合には次のようにして変更される。「レコード状態」フィールドの値はＮ（無変更）に設定される。他のすべてのフィールドの値は変更されない。
【００３７】
「契約テーブル」のレコードは、「変更レコード」と定義された場合には次のようにして変更される。「処理日」の値は変更されない。「契約猶予期間終了日」の値は契約終了日から所定の日数後に設定される。「契約状態」フィールドの値は変更されない。「レコード状態」フィールドの値はＣ（変更）に設定される。他のすべてのフィールドの値は「ＭＳＡ抽出出力ファイル」のレコードに従って変更される。「変更レコード」は、すべてのフィールドについてのその旧値及び新規値と共に、変更時のシステム日時と共に運用サーバによって「事象ログ」にログ記録される。
【００３８】
「契約テーブル」のレコードは、「除去レコード」と識別された場合には次のようにして変更される。「契約状態」フィールドの値はＤ（失効）に設定される。「レコード状態」フィールドの値は、更新された「契約テーブル」に基づいて「契約更新ファイル」（後述）が生成された後にＲ（除去）に設定される。他のすべてのフィールドの値は変更されない。
【００３９】
以上に述べた過程から、「ＭＳＡ抽出出力ファイル」を「構文解析」することにより「契約テーブル」が生成される。本書で用いる場合には、「構文解析」という用語は、１つのファイルの各フィールドを選択して値を判定した後に、これらの値を他のファイルの既存のフィールド値と比較することを指す。好ましくは、ＭＳＡ抽出ファイルは、運用サーバによる受領の後に毎日構文解析される。「ＭＳＡ抽出出力ファイル」を構文解析する前に、「契約テーブル」のあらゆるレコードの「レコード状態」フィールドをＩ（初期）に設定する。運用サーバは、図４に示すアルゴリズムを用いることによりＭＳＡ抽出ファイルのレコードを構文解析する。「ＭＳＡ抽出出力ファイル」を構文解析した後にも「レコード状態」フィールドに値Ｉを依然として有する「契約テーブル」のあらゆるレコードは「除去レコード」である。抽出アルゴリズムは、「ＭＳＡ抽出出力ファイル」の最後のレコードが構文解析されたと判定したら（図４の判定ブロック７６）終了する。
【００４０】
好適実施形態の更なる特徴によれば、運用サーバ２２（図２を参照）は、作成サーバ２８がそのサービス契約情報を更新するための「契約更新ファイル」を生成する。「契約更新ファイル」は、「ＭＳＡ抽出出力ファイル」の構文解析及び「契約テーブル」のレコードに対する操作が完了した後に毎日生成される。「契約更新ファイル」は運用サーバ２２に記憶されて、作成サーバ２８からアクセスすることが可能である。「契約更新ファイル」は、「契約テーブル」からのすべての発効中レコード（「契約状態」が「Ｌ」）、追加レコード、変更レコード又は除去レコード（それぞれ「レコード状態」が「Ａ」、「Ｃ」又は「Ｒ」）から成っている。「契約更新ファイル」には「無変更レコード」（「レコード状態」が「Ｎ」）は複写されない。「契約更新ファイル」は好ましくは、ＸＭＬフォーマットである。レコードのデータ・フィールドは「契約テーブル」から複写される。
【００４１】
また、スキャナから受領されたログ・データの履歴を追跡するために、「ログ受領履歴テーブル」との名称のデータベース・テーブルが作成されて保持される。運用サーバが受領した各々のログ・ファイルが「ログ受領履歴テーブル」に唯一のレコードを有する。各々のスキャナがテーブル内に多数のレコードを有していてもよく、この場合には、同じスキャナから多数のログ・ファイルが得られていることを表わす。「ログ受領履歴テーブル」のあらゆるレコードは、次のデータ・フィールドを有する。（１）第１キーは「ＩＤ」フィールドであって、レコードが挿入されたときに自動生成される数字列である。（２）ログ・ファイルを送付したスキャナの「システムＩＤ」を保持する「システムＩＤ」フィールド。（３）ログ・ファイルがデータ・プリプロセッサによって受領されたときの日時を有する「受領日時」ファイル。（４）受領したログ・ファイルのサイズを含む「ファイル・サイズ」フィールド。（５）最後にファイルを受領した日付と今回のファイル受領の日付の間の日数を保持する「最後の受領以降の日数」ファイル。
【００４２】
新たなログ・ファイルが受領されて処理されたときに、データ・プリプロセッサによって「ログ受領履歴テーブル」に新規レコードが追加される。「ログ受領履歴テーブル」のレコードは、一旦追加されたら変更も除去もされない。
【００４３】
本発明の好適実施形態によれば、運用サーバ（図２の２２）は、「ログ受領履歴テーブル」のデータを検査して、特定のスキャナから最も最近に受領したデータ・ファイルの受領日又は容量が、当該スキャナからの最近のデータ収集が不成功であったか又は不完全であったことを示すか否かを判定する定期的タスクを実行している。
【００４４】
一つの好適実施形態によれば、この定期的タスクは、スキャナ単位で運用データ・ファイルの履歴的平均（すなわち相加平均）サイズを計算して（但し、各々のスキャナについて最も最近に受領したデータ・ファイルは除いて）、次いで、各々のスキャナからのデータ・サイズの履歴的平均と、当該スキャナから最も最近に受領したデータ・ファイルのサイズとが所定の量、例えば所定の百分率を超えて（例えば、１０％を超えて）異なっているか否かを判定する。ログ・ファイルのサイズは、「ログ受領履歴テーブル」の「ファイル・サイズ」フィールドから検索される。スキャナ単位での平均ファイル・サイズは、運用サーバに組み入れられている「管理ツール」によって「ログ・データ履歴」（後述）に含められている。
【００４５】
もう一つの好適実施形態によれば、定期的タスクは、スキャナ単位で連続するデータ受領の間の履歴的平均時間（例えば、日数）を計算して（但し、最も最近に受領したデータ・ファイルは除いて）、次いで、各々のスキャナについての連続するデータ受領の間の履歴的平均時間が、当該スキャナから最も最近に受領したデータ・ファイルと前回のデータファイルとの間の時間（例えば、日数）と所定の量、例えば所定の百分率を超えて（例えば、１０％を超えて）異なっているか否かを判定する。連続するデータ・ファイル受領の間の日数は、「ログ受領履歴テーブル」の「最後の受領以降の日数」フィールドから検索される。スキャナ単位での連続するデータ受領の間の平均日数は、前述の「ログ・データ履歴」に含められている。
【００４６】
本発明の最も好ましい実施形態によれば、運用サーバは、上述の定期的タスクの両方を実行する。すなわち、運用サーバは、最も最近に受領したデータ・ファイルのデータ容量を履歴的平均データ容量と比較すると共に、２つの最も最近に受領したデータ・ファイルの間の時間間隔をデータ受領の間の履歴的平均時間と比較する。これらのパラメータのいずれか一方に逸脱があると、以下に述べる修正処置が起動される。
【００４７】
再び図２を参照して述べると、スキャナによるその運用データの不成功の又は不完全な送信を示す履歴的平均からの逸脱が生じた場合には、運用サーバ２２は自動サポート・センタ１６に対し、特定のスキャナ２上でのデータ・ログ記録の特徴及び先行的診断データ転送の特徴を初期化し直すように要求を送る。加えて、運用サーバ２２に組み入れられている「管理ツール」が、スキャナを初期化し直すように自動サポート・センタ１６に送られた各々の要求毎に、日時及びスキャナの「システムＩＤ」を記録する。「管理ツール」はまた、適当なシステム管理者に、識別されたスキャナからのデータ転送に不整合が生じたことを通知する。
【００４８】
好適実施形態によれば、運用サーバはまた、有効性のある契約を有する各々のスキャナのデータ・ログ記録サービス状態を追跡するための「スキャナ状態テーブル」との名称のデータベース・テーブルを保持している。「スキャナ状態テーブル」には、将来の契約は、該契約がカレントになるまでは一切含められない。有効性のあるスキャナ利用状況リポート発行サービス契約によってカバーされている各々のスキャナの各々が「スキャナ状態テーブル」に唯一の非停止（non-terminated）レコードを有する。図５は、スキャナ上でのデータ・ログ記録プログラムのライフ・サイクルを示す。
【００４９】
図５を参照して述べると、利用状況リポート発行サービスを有するあらゆるスキャナは、そのサービス・ライフ・サイクルにおいて次の境界日付を有する。「スキャナ始動スイープ」日は、自動サポート・センタ（図２の参照番号１６）がスキャナ上でのデータ・ログ記録の特徴を始動させるスイープを実行する予定日である。「スキャナ始動」日は、当該スキャナをカバーする契約の開始日と同一でなければならない。「最初のデータ受領予測日」は、運用サーバ（図２の参照番号２２）がスキャナから最初のログ・データ送信を受領することが予測される日付である。「最後のデータ受領日」は、運用サーバがスキャナからログ・データを受け取った実際の最後の日である。「スキャナ停止スイープ」日は、自動サポート・センタが、スキャナ上でのデータ・ログ記録の特徴を停止させるスイープを実行する予定日である。「スキャナ停止」日は、契約停止に続く猶予期間の満了日と同じでなければならない。一旦、自動サポート・センタの「スキャナ停止」スイープが成功したら、スキャナから受領されるログ・ファイルはなくなる。
【００５０】
利用状況リポート発行サービス契約によってカバーされるあらゆるスキャナは、そのサービス・ライフ・サイクルにおいて次の状態を有する。０（新規）：スキャナは発効中のサービスを有さない、１（始動中）：スキャナに対するサービスが始動されようとしている、２（作動中）：スキャナが発効中のサービスを有する、３（停止中）：スキャナに対するサービスが停止されようとしている、４（停止）：スキャナに対するサービスが既に停止している。
【００５１】
加えて、表２（付録参照）に示すように、「契約テーブル」に次のデータ・フィールドが定義されており、スキャナ状態の境界日付の計算に用いられる。「契約テーブル」のカレントの各々の契約毎に、「処理日」フィールドが、運用サーバが最初に契約を処理した日付を保持している。「契約テーブル」はまた、「契約猶予期間終了日」フィールドを含む。サービスは、契約終了日の直後に停止させなくてもよい。サービスは、所定の猶予期間の間は発効したままにしておいてよい。「契約テーブル」のカレントの各々の契約毎に、契約終了日の後の所定の構成設定可能な時間として「猶予期間終了日」フィールドが設定される。
【００５２】
スキャナ状態の境界日付は、次のようにして算出される。「スイープ始動予定日」は、契約については「契約テーブル」の「処理日」及び「契約開始日」のうち遅い方であり、スキャナについてはそのカレントのすべての契約について最も早く予定された「スキャナ始動」スイープ日となる。「最初のデータ受領予測日」は最初は予定として設定され、後に、最初のデータを実際に受領したときに更新される。「最後のデータ受領日」は、「ログ受領履歴テーブル」に従ってスキャナについて最後のログ受領日として設定される。「スイープ停止予定日」は、契約については「猶予期間終了日」であり、スキャナについてはそのカレントのすべての契約について最も遅い猶予期間終了日として設定される。「スキャナ状態テーブル」のあらゆるレコードは、表３（付録参照）に定義されているようなデータ・フィールドを有する。第１キーは「システムＩＤ」フィールドである。
【００５３】
運用サーバはまた、「スキャナ状態テーブル」に対するすべての挿入及び変更を記録する「スキャナ状態監査テーブル」との名称のデータベース・テーブルを保持している。スキャナ状態監査テーブルは好ましくは、表３の第５フィールド（「最後の受領日」）を除くすべてのフィールドの「：旧値」及び「：新規値」用のフィールドを有している。また、監査レコードが挿入されたときの日時スタンプのためのフィールドも有している。挿入を追跡するために「スキャナ状態テーブル」に「挿入トリガ」が設けられており、「スキャナ状態監査テーブル」の「：新規値」フィールドに、挿入されたレコードを追加できるようにしている。変更を追跡するためには「スキャナ状態テーブル」に「変更トリガ」が設けられており、「スキャナ状態監査テーブル」に、変更されたレコードを「：旧値」及び「：新規値」について追加できるようにしている。表３の「監査変更要否」の欄に「要」とマークされたいずれかのフィールドが変更されると、「スキャナ状態テーブル」は「変更トリガ」を起動する。
【００５４】
「スキャナ状態テーブル」は好ましくは、「契約テーブル」が更新された後に毎日更新される。運用サーバは、図６に示すように、「契約テーブル」からのすべての「追加レコード」及び「変更レコード」を構文解析することにより「スキャナ状態テーブル」を生成する。このアルゴリズムは、「契約テーブル」から次の「発効中の追加／変更レコード」を検索する（ステップ７８）。ステップ８０において、アルゴリズムは、検索されたレコードについて、「契約認知キー」フィールドの値が０（カレントの契約であることを示す）であるか１（将来の契約であることを示す）であるかを判定する。値が０に等しいならば、アルゴリズムは、処理されているレコードの「システムＩＤ」が「スキャナ状態テーブル」に存在しているか否かを判定する（ステップ８２）。「スキャナ状態テーブル」のレコード操作は、「システムＩＤ」が「スキャナ状態テーブル」に存在していない場合には新規レコードの追加を（図６のステップ８６）、また「システムＩＤ」が「スキャナ状態テーブル」に存在しており且つエラーが存在していない場合には既存のレコードの変更を含んでいる（図６のステップ８４）。構文解析されているレコードのデータにエラーが検出された場合には、エラー標識子が生成される（ステップ８８）。アルゴリズムが、「契約テーブル」ファイルからの最後の「追加／変更レコード」が構文解析されたものと判定したら（図６の判定ブロック９０）、アルゴリズムは終了する。アルゴリズムは、「契約認知キー」の値が１に等しかった場合には、ステップ８０からステップ９０へ直接進む。
【００５５】
好適実施形態によれば、新規レコードは、次に基づいて「スキャナ状態テーブル」に追加される。（１）「システムＩＤ」の値が「契約テーブル」からのレコードの「システムＩＤ」に従って設定される。（２）「スイープ始動日」フィールドが、「契約テーブル」からのレコードの「処理日」及び「契約開始日」のうち遅い方に設定される。（３）「スイープ始動試行」フィールドが、サービスを始動させようとするスイープ試行の回数に設定される（既定値は０）。「最初の受領日」フィールドが、自動サポート・センタ（図２の参照番号１６）が生成した先行的診断予定に従って設定される。（５）「最後の受領日」フィールドの値はヌルに設定される。（６）「スイープ停止日」フィールドは、「契約テーブル」からのレコードの「契約猶予期間終了日」に設定される。（７）「スイープ停止試行」フィールドは０に設定される。（８）「契約テーブル」のレコードの「包括範囲（room）状態」フィールドが値９Ｘを有している場合には、「状態」フィールドの値は４（停止）に設定される。他の場合には、値は０（新規）に設定される。
【００５６】
「スキャナ状態テーブル」の既存のレコードは、次のようにして修正される。（１）「システムＩＤ」の値は変更されない。（２）「カレントの状態」フィールドが値０（新規）を有する場合には、「スイープ始動日」の値は、カレントの値と、「契約テーブル」からのレコードから導出され契約で予定されているスイープ始動の日付とのうち近い方に変更される。「カレントの状態」フィールドが０（新規）以外の値を有する場合には、値は変更されない。（３）「スイープ始動試行」フィールドの値は変更されない。（４）「最初の受領日」フィールドは、自動サポート・センタが生成した先行的診断予定に従って変更される。（５）「最後の受領日」フィールドの値は変更されない。（６）「スイープ停止日」フィールドは、カレントの値と「契約テーブル」からのレコードの「契約猶予期間終了日」とのうち遅い方に変更される。（７）「スイープ停止試行」フィールドは変更されない。（８）「契約テーブル」のレコードの「包括範囲状態」フィールドが値９Ｘを有する場合には、「状態」フィールドの値は４（停止）に設定される。他の場合には、値は変更されない。
【００５７】
本発明の好適実施形態によれば、すべてのスキャナの状態は、「スキャナ状態テーブル」が「契約テーブル」に基づいて更新された後に毎日更新される。運用サーバは、図７に示すアルゴリズムを用いて「スキャナ状態テーブル」のすべてのスキャナ・レコードの状態を更新する。このアルゴリズムは、「スキャナ状態テーブル」の次のレコードを検索する（ステップ９２）。ステップ９４において、「ログ受領履歴テーブル」に基づいて「最後の受領日」フィールドが更新される。ステップ９６において、アルゴリズムは、処理されているレコードの「状態」フィールドのカレントの値を判定する。
【００５８】
「状態」フィールドが値０（新規）を有する場合には、アルゴリズムは、この日が「スキャナ始動スイープ」日として予定されているか否かを判定する（ステップ１００）。「イエス」であるならば、スキャナ状態を０から１へ変更して（ステップ１０２）、「スイープ始動試行」フィールドの値を１だけインクリメントする。他のすべてのフィールドの値は変更しない。次いで、運用サーバ（図２の参照番号２２）は自動サポート・センタ（図２の参照番号１６）へ電子メールを送って、スキャナ上でのデータ・ログ記録の特徴及び先行的診断データ転送を遠隔からイネーブルにするように自動サポート・センタに要求する。次いで、アルゴリズムは、処理されているレコードが「スキャナ状態テーブル」の最後のレコードであるか否かを判定する（ステップ１１４）。「ノー」であるならば、アルゴリズムは直接ステップ１１４に進む。直前に処理されたレコードが最後のレコードであれば、アルゴリズムは終了する。最後のレコードでなければ、アルゴリズムはステップ９２に戻って次のレコードを処理する。
【００５９】
「状態」フィールドが値１（始動中）を有する場合には、アルゴリズムは「最後の受領日」がヌルであるか否かを判定し（ステップ９８）、「スキャナ始動スイープ」日として今日が予定されているか否かを判定する（ステップ１００）。「イエス」であるならば、アルゴリズムはステップ１１４へ進む。「ノー」であるならば、ステップ１１４に進む前にスキャナ状態を１から２へ変更する（ステップ１０４）。
【００６０】
「状態」フィールドが値２（作動中）を有する場合には、アルゴリズムはこの日が「スキャナ停止スイープ」日として予定されているか否かを判定する（ステップ１０６）。「イエス」であるならば、スキャナ状態を２から３へ変更し（ステップ１１２）、「スイープ停止試行」の値を１だけインクリメントする。他のすべてのフィールドの値は変更しない。次いで、運用サーバ（図２の参照番号２２）は自動サポート・センタ（図２の参照番号１６）へ電子メールを送って、スキャナ上でのデータ・ログ記録の特徴及び先行的診断データ転送を遠隔からディスエーブルにするように自動サポート・センタに要求する。次いで、アルゴリズムはステップ１１４へ進む。「ノー」であるならば、アルゴリズムは直接ステップ１１４へ進む。
【００６１】
「状態」フィールドが値３（停止中）を有する場合には、アルゴリズムはこの日が「最後の受領日」のＸ日後であるか否かを判定する（ステップ１０８）。「イエス」であるならば、アルゴリズムはステップ１１４へ進む。Ｘの値は構成設定が可能である。「イエス」であるならば、ステップ１１４へ進む前にスキャナ状態を３から４へ変更する（ステップ１１０）。「ノー」であるならば、アルゴリズムは直接ステップ１１４へ進む。
【００６２】
データ・プリプロセッサ（図２に示す運用サーバ２２に組み込まれている）は、自動サポート・センタにスキャナ・データが送られた後に、スキャナ・データの初期処理を行なう。この初期処理（図８に示す）は、新たなスキャナ・ファイルを定期的に点検すると共に収集し（ステップ１１６）、ファイルが由来したスキャナの形式を識別し、スキャナ・ファイルのフィールドを検証し（ステップ１１８）、ＣＰＴコードを生成し（ステップ１２０）、スキャナ・ファイルをＸＭＬフォーマットへ変換し（ステップ１２２）、ファイルを作成サーバへ転送することから成っている。データ・プリプロセッサの動作履歴は、どのスキャナ・ファイルを処理したか、いつ処理したか、処理にはどれ位の時間がかかったか、及び処理に関連するエラーがあればそのエラーを含んでおり、ウェブ配布フォーマットでシステム管理者が利用することが可能になっている。いずれかのスキャナがファイルを送るべきときに送ってこなかったり、処理エラーに遭遇した場合には、データ・プリプロセッサはシステム管理者へ通知する。
【００６３】
データ・プリプロセッサは、新たなスキャナ・ファイルが自動サポート・センタから到着したときを自動的に検出し、次いで、これらのファイルの有効性を自動的に確認する（図８のステップ１１８）。ファイルによっては、圧縮を解凍する必要がある場合もある。データ・プリプロセッサは、ファイルの「文法」（例えばＭＲ又はＣＴ）を識別して、不明の文法があればエラーとしてログ記録する。データ・プリプロセッサはまた、レコード内に、問題となっているサービスを提供するのに必要とされるすべてのフィールドが正しい形式で正しい範囲に存在していることを検証する。データ・プリプロセッサは可能な限り多くの生のスキャナ・ファイルを保存しようとする。レコードが完全でなければ（すなわち欠落したフィールドを有しているならば）、レコードをログ記録して削除する。削除したレコードが他のレコードを包含するレベルにある場合には、当該レコードが包含するレコードも削除する（例えば、検査レコードを削除すると、次の検査レコードまでのすべての後続レコードが削除される）。レコード内の検査又は系列番号が重複している場合には、後続のレコードの番号を振り直してこれを修正する。データ・プリプロセッサはまた、参照ドキュメントに基づいてＣＰＴコードを生成する。
【００６４】
データ・プリプロセッサは、その動作を監視する（ステップ１２６）と共に記録して（ステップ１２８）、これらの動作をシステム管理者へ報告する（ステップ１３０）。具体的には、データ・プリプロセッサは、スキャナ・ファイルが自動サポート・センタから受領された日時、及びファイルのサイズを記録し（「ログ受領履歴テーブル」へ）、スキャナ・ファイルが処理された開始及び終了の日時を記録し（これはシステムＩＤを介してアクセス可能でなければならない）、また、スキャナ・ファイルの処理に関連したあらゆるエラーを記録する（やはりこれもシステムＩＤを介してアクセス可能でなければならない）。加えて、データ・プリプロセッサは、データ・ログ記録及びリポート生成についてイネーブルになっているすべてのスキャナを定期的に点検して（ステップ１２４）、これらのスキャナがデータを送付していることを検証する。この点検を行なう割合は、構成設定可能である。データ・プリプロセッサは、エラー状態、又は動作していないスキャナがあれば、システム管理者へ通知する。また、データ・プリプロセッサは、作成サーバへ転送されてきたファイルの数をログ記録している。データ・プリプロセッサは、処理済のＸＭＬファイルを処理が完了すると直ちに圧縮した後に作成サーバ（図２の参照番号２８）へ送付する。データ・プリプロセッサは、１日１回、作成サーバ（図２の参照番号２８）へ「転送ログ」ファイルを送付する。データ・プリプロセッサは、処理されたファイル数、処理時間統計及びエラー・ログ、すなわち日、週、月及び年当たりに処理されたファイル、並びにファイルを処理した平均時間、最短時間及び最長時間；すべてのシステムＩＤ及び個々のシステムＩＤについてのスキャナ・ファイル統計すなわちシステムＩＤ当たり及びすべてのシステムＩＤ当たりの受領時刻；システムＩＤ当たり及びすべてのシステムＩＤ当たりのファイル・サイズ；並びにシステムＩＤがデータを発行すべき予測される日付を状態と共に示す動的ＨＴＭＬリポートを発行する。
【００６５】
本発明の更なる側面によれば、運用サーバは、事象ログ記録及びリポート発行を含むウェブ方式の管理ツール機能を有するようにプログラムされる。「管理ツール」は「ログ・ファイル」（必ずしもファイル構造でなくてもよい）を保持して、次の各動作を記録する。「ＭＳＡ抽出出力ファイル」の取り出しに失敗したときの日時；受領した「ＭＳＡ抽出出力ファイル」の日時及びファイル・サイズ；「ＭＳＡ抽出出力ファイル」の構文解析されたレコードの日時及び総数；抽出アルゴリズム及び関連する契約テーブルにおける日時及びエラー状態；「契約テーブル」の「新規レコード」の日時及び数、「無変更レコード」の数、「変更レコード」の数、「除去レコード」の数；「契約更新ファイル」の「新規レコード」の日時、ファイル・サイズ、数、「変更レコード」の数及び「除去レコード」の数；作成サーバによって送付され又は検索された「契約更新ファイル」の日時及びファイル・サイズ；「新規レコード」が「スキャナ状態テーブル」に追加された日時；「スキャナ状態テーブル」の「変更レコード」の日時、及び旧値と新規値；並びにスキャナを始動又は停止させるために自動サポート・センタへ送付された電子メールの日時、スイープの型及びシステムＩＤ。
【００６６】
加えて、「管理ツール」は要求に応じて異なるリポートを発行する。例えば、「新規顧客追跡」リポートは、新たな利用状況リポート発行サービス契約によってカバーされているが、作成モードにはまだなっていないすべてのスキャナを含んでいる。「スキャナ状態テーブル」から、状態０（新規）及び１（始動中）を有するすべてのスキャナががこの一覧に含められる。一覧に含められた各々のスキャナ毎に、リポートは次の情報を有する。「顧客名」、「スキャナ・システムＩＤ」、「契約開始日」、「サービス始動日」、「スイープ始動試行回数」、「最初のデータ受領予測日」、「状態」及び「補助」。このリポートの一覧に含められたすべてのスキャナについて、「スキャナ・システムＩＤ」、「サービス始動日」、「スイープ始動試行回数」及び「最初のデータ受領予測日」の情報は、「スキャナ状態テーブル」の「システムＩＤ」、「スイープ始動日」、「スイープ始動試行」、「最初の受領日」の各フィールドからそれぞれ検索される。
【００６７】
「新規顧客追跡」リポートの一覧に含められたすべてのスキャナについて、「顧客名」及び「契約開始日」の情報は、「契約テーブル」の「顧客名」及び「契約開始日」フィールドからそれぞれ検索される。「契約テーブル」内で多数のスキャナ利用状況リポート発行サービス契約によってカバーされるスキャナについては、すべての「契約開始日」が検索されて一覧に含められる。
【００６８】
「新規顧客追跡リポート」の一覧に含められた各々のスキャナは、次の状態のうち１つを有する。（ａ）システム日付が「最初のデータ受領予測日」よりも前である場合には、スキャナは「緑」状態を有する。（ｂ）システム日付が「最初のデータ受領予測日」から２日後以内である場合には、スキャナは「黄」状態を有する。（ｃ）システム日付が「最初のデータ受領予測日」から少なくとも２日後である場合には、スキャナは「赤」状態を有する。
【００６９】
「補助」は、「状態」が「赤」であり、且つ「スキャナ状態テーブル」からのスキャナの「カレントの状態」が１（始動中）である場合にのみ利用可能である。運用サーバによって補助要求が発行されたときに、電子メールが自動サポート・センタへ送付されて、データ・ログ記録の特徴及び先行的診断データ転送をこのスキャナに対して遠隔からイネーブルにするように要求する。「スキャナ状態テーブル」では、このスキャナの「スイープ始動日」フィールドがシステム日付に再設定される。「新規顧客追跡」リポートの「最初のデータ受領予測日」は、予定されている「サービス始動日」から所定の構成設定可能な期間後に再設定される。「スイープ始動試行回数」は１だけインクリメントされる。「スイープ始動試行回数」が２よりも大きくなったときには手動の介入が期待される。「新規顧客追跡」リポートは、リポートが要求されたときにデータベースへの問い合わせを通じて実時間で生成される。
【００７０】
「管理ツール」はまた、「満了顧客追跡」リポートを生成することができる。この追跡は、満了する利用状況リポート発行サービス契約によってカバーされているすべてのスキャナを含んでいる。この一覧は、「スキャナ状態テーブル」から状態３（停止中）又は状態２（作動中）を有するが契約猶予期間内にあるすべてのスキャナを含んでいる。一覧に含められた各々のスキャナについて、「満了顧客追跡」リポートは次の情報を有する。「顧客名」、「スキャナ・システムＩＤ」、「契約終了日」、「サービス停止日」、「スイープ停止試行回数」、「最終データ受領日」、「状態」及び「補助」。このリポートの一覧に含められたすべてのスキャナについて、「スキャナ・システムＩＤ」、「サービス停止日」、「スイープ停止試行回数」及び「最終データ受領日」の情報は、「スキャナ状態テーブル」の「システムＩＤ」、「スイープ停止日」、「スイープ停止試行」及び「最終受領日」の各フィールドからそれぞれ検索される。このリポートの一覧に含められたすべてのスキャナについて、「顧客名」及び「契約終了日」の情報は、「契約テーブル」の「顧客名」及び「契約終了日」の各フィールドからそれぞれ検索される。「契約テーブル」内で多数のサービス契約を有するスキャナについては、すべての「契約終了日」が検索されて一覧に含められる。
【００７１】
「満了顧客追跡」リポートの一覧に含められた各々のスキャナは、次の状態のうち１つを有する。（ａ）「最終データ受領日」が「サービス停止日」よりも前である場合には、スキャナは「緑」状態を有する。（ｂ）「最終データ受領日」が「サービス停止日」から１週間後以内である場合には、スキャナは「黄」状態を有する。（ｃ）「最終データ受領日」が「サービス停止日」から１週間後を超えている場合には、スキャナは「赤」状態を有する。
【００７２】
「補助」は、状態が「赤」であり、且つ「スキャナ状態テーブル」からのスキャナの「カレントの状態」が３（停止中）である場合にのみ利用可能である。補助要求が発行されたときに、運用サーバによって電子メールが自動サポート・センタへ送付されて、データ・ログ記録の特徴及び先行的診断データ転送をこのスキャナに対して遠隔からディスエーブルにするように要求する。「スキャナ状態テーブル」では、このスキャナの「スイープ停止日」フィールドがシステム日付に再設定される。「スイープ停止試行回数」は１だけインクリメントされる。「スイープ停止試行回数」が２よりも大きくなったときには手動の介入が期待される。このリポートもやはり、リポートが要求されたときにデータベースへの問い合わせを通じて実時間で生成される。
【００７３】
「管理ツール」はまた、「発効中顧客追跡」リポートを生成することができる。この追跡は、生成モードにあるデータ・ログ記録を有するすべてのスキャナを含んでいる。この一覧は、「スキャナ状態テーブル」から状態２（作動中）を有するすべてのスキャナを含んでいる。一覧に含められた各々のスキャナについて、「発効中顧客追跡」リポートは次の情報を有する。「顧客名」、「スキャナ・システムＩＤ」、「始動日」、「最終データ受領日」、「次のデータ予測日」、「最終受領ファイル・サイズ」及び「状態」。このリポートの一覧に含められたあらゆるスキャナについて、「スキャナ・システムＩＤ」、「最終データ受領日」及び「最終受領ファイル・サイズ」の情報は、「ログ受領履歴テーブル」に含まれる「システムＩＤ」フィールド、最新の「受領日時」及び最新の受領の「ファイル・サイズ」から検索され又は導出される。「次のデータ予測日」は、自動サポート・センタの先行的診断予定に従って設定される。このリポートの一覧に含められたあらゆるスキャナについて、「始動日」情報は、「スキャナ状態テーブル」の「スイープ始動日」フィールドから検索され、「顧客名」情報は、「契約テーブル」の「顧客名」フィールドから検索される。
【００７４】
「発効中顧客追跡」リポートの一覧に含められた各々のスキャナは、次の状態のうち１つを有する。（ａ）システム日付が「次のデータ予測日」よりも前であり、且つ「最終受領ファイル・サイズ」が１５キロバイトよりも大きい場合には、スキャナは「緑」状態を有する。（ｂ）システム日付が「次のデータ予測日」から２日後以内であるか、又は「最終受領ファイル・サイズ」が５キロバイトと１５キロバイトとの間にある場合には、スキャナは「黄」状態を有する。（ｃ）システム日付が「次のデータ予測日」から２日後を超えているか、又は「最終受領ファイル・サイズ」が５Ｋよりも小さい場合には、スキャナは「赤」状態を有する。「発効中顧客追跡」リポートは、リポートが要求されたときにデータベースへの問い合わせを通じて実時間で生成される。
【００７５】
「管理ツール」はまた、「ログ・データ履歴」リポートを生成することができる。この追跡は、利用状況リポート発行サービス契約によってカバーされていたことのあるすべてのスキャナを含んでいる。この一覧は、「スキャナ状態テーブル」から状態０（新規）、１（始動中）、２（作動中）、３（停止中）及び４（停止）を有するすべてのスキャナを含んでいる。一覧に含められた各々のスキャナについて、「ログ・データ履歴」リポートは次の情報を有する。「顧客名」、「スキャナ・システムＩＤ」、「始動日」、「受領ファイル数」、「平均ファイル・サイズ」、「データ受領間の平均日数」、「カレントの状態」及び「詳細」。このリポートの一覧に含められたあらゆるスキャナについて、「スキャナ・システムＩＤ」、「受領ファイル数」、「平均ファイル・サイズ」及び「データ受領間の平均日数」の情報は、「ログ受領履歴テーブル」に含まれている「システムＩＤ」フィールド、この「システムＩＤ」を有するレコード数、「ファイル・サイズ」の平均、「最終受領以降の日数」の平均からそれぞれ検索され又は導出される。このリポートの一覧に含められたあらゆるスキャナについて、「始動日」及び「カレントの状態」の情報は、「スキャナ状態テーブル」の「スイープ始動日」フィールド及び「状態」フィールド（新規、始動中、作動中、停止中又は停止）から検索され、「顧客名」情報は、「契約テーブル」の「顧客名」フィールドから検索される。このリポートは、リポートが要求されたときにデータベースへの問い合わせを通じて実時間で生成される。
【００７６】
本発明は、医用撮像装置における運用データ・ログ記録の自動監視での応用に限定されている訳ではない。本書に開示した自動監視手法を、利用者が運用する他の形式の電子装置から中央サービス施設への運用データのログ記録及び転送を監視するために用いることもできる。
【００７７】
好適実施形態を参照して本発明を説明したが、当業者であれば、本発明の範囲から逸脱せずに様々な変形を施し、また好適実施形態の構成要素を均等構成で置き換え得ることが理解されよう。加えて、本発明の本質的な範囲から逸脱せずに、本発明の教示に合わせて具体的な状況を適応構成するような多くの改変を施してもよい。従って、本発明は、本発明を実施するのに想到される最良の態様として開示された特定の実施形態に限定されている訳ではなく、特許請求の範囲内に含まれるすべての実施形態を包含しているものとする。
【００７８】
特許請求の範囲で用いる場合には、「コンピュータ・システム」という用語は、単一のコンピュータ、サーバ若しくはデータ・プロセッサ、又は相互接続された複数のコンピュータ、サーバ若しくはデータ・プロセッサの群を包含するように広い意味で用いられている。当業者であれば容易に理解されるように、２つのデータ処理機能を別個のコンピュータ若しくはサーバ上で別個のソフトウェア・モジュール若しくはコンピュータ・プログラムとして具現化してもよいし、又は同じコンピュータ若しくはサーバ上で別個のソフトウェア・モジュール若しくはコンピュータ・プログラムとして具現化してもよい。特許請求の範囲で用いる場合には、「入来ログ・ファイル」という用語は、最も最近に受領された運用データ・ログ・ファイルを意味するものとする。
【００７９】
【表１】

【００８０】
【表２】

【００８１】
【表３】

【００８２】
【表４】

【００８３】
【表５】

【図面の簡単な説明】
【図１】本発明の好適実施形態による遠隔配置されたスキャナからの運用データの流れ及び処理を示す線図である。
【図２】本発明の好適実施形態によるシステムの設計構成要素の相互作用を示すブロック図である。
【図３】本発明の好適実施形態による顧客プロフィール・データ、契約データ及びスキャナ状態データの流れを示す線図である。
【図４Ａ】本発明の好適実施形態に従ってそれぞれの「契約テーブル」を生成するために各々の「抽出出力ファイル」のレコードに対して運用サーバによって実行される構文解析動作を示す流れ図の一部である。
【図４Ｂ】本発明の好適実施形態に従ってそれぞれの「契約テーブル」を生成するために各々の「抽出出力ファイル」のレコードに対して運用サーバによって実行される構文解析動作を示す流れ図の残部である。
【図５】本発明の好適実施形態による遠隔スキャナのためのデータ・ログ記録プログラムのライフ・サイクルを示す時間線の図である。
【図６】本発明の好適実施形態に従って「契約テーブル」の「追加／変更レコード」から「スキャナ状態テーブル」を生成する方法の工程を示す流れ図である。
【図７Ａ】本発明の好適実施形態に従って「スキャナ状態テーブル」に記録されているスキャナの状態を更新する方法の工程を示す流れ図の一部である。
【図７Ｂ】本発明の好適実施形態に従って「スキャナ状態テーブル」に記録されているスキャナの状態を更新する方法の工程を示す流れ図の残部である。
【図８】本発明の好適実施形態によるデータ・プリプロセッサのスキャナ運用データの流れ及び処理を示す線図である。

Claims (10)

1. 遠隔位置に設けられ、スキャニング・モードにおいて動作時にスキャンデータを取得可能なスキャニング装置（２）と、
   中央位置に設けられているコンピュータ・システム（１６、２２）と、前記スキャニング装置と前記コンピュータ・システムとを接続する通信チャネル（１８）とを備えたシステムであって、
   前記スキャニング装置は、前記スキャニング装置を使用して実施された各々の検査に対し、検査の標識子、検査日付、検査の開始時刻及び終了時刻、検査形式を含む運用データを取得し、記憶して、データ・ログ記録機能が作動しているときに該データ・ログ記録機能に従って前記通信チャネルを介して前記コンピュータ・システムに対し記憶されている前記運用データを含むログ・ファイルを定期的に送付することが可能であり、
   前記コンピュータ・システムは、
   前記スキャニング装置において前記データ・ログ記録機能を作動させる工程と、
   該作動させられたデータ・ログ記録機能に従って前記スキャニング装置からログ・ファイルを受領する工程と、
   受領した各ログ・ファイルの特性又は受領したログ・ファイルの連続した組の特性を表すデータを生成する工程と、
   入来ログ・ファイルの特性が履歴的基準値から逸脱した値を有しているときを検出するように各々の入来ログ・ファイルの前記データを監視する工程とを実行するようにプログラムされている、システム。
2. 前記コンピュータ・システムは、前記履歴的基準値から所定の量を超えて逸脱している前記特性の値に応答して、前記通信チャネルを介して前記スキャニング装置において前記データ・ログ記録機能を初期化し直すようにさらにプログラムされている請求項１に記載のシステム。
3. 前記特性は、前記スキャニング装置から受領した各々の入来ログ・ファイルとその先行するログ・ファイルとの間の日数である請求項１に記載のシステム。
4. 前記監視する工程は、前記スキャニング装置から受領した各々の入来ログ・ファイルとその先行するログ・ファイルとの間の日数を記憶する工程を含んでおり、
   前記監視する工程は、前記スキャニング装置から受領したログ・ファイルの履歴的系列において連続するログ・ファイルの間の履歴的平均日数を算出する工程と、前記スキャニング装置から受領した各々の入来ログ・ファイルとその次に先行するログ・ファイルとの間の日数が、前記履歴的平均日数から少なくとも所定の量だけ逸脱しているか否かを判定する工程と、をさらに含んでおり、
   前記算出する工程は、前記ログ・ファイルの履歴的系列から各々の入来ログ・ファイルを除外する工程をさらに含んでいる請求項１に記載のシステム。
5. 前記特性は、前記スキャニング装置から受領した各々の入来ログ・ファイルのサイズであり、
   前記監視する工程は、前記スキャニング装置から受領した各々の入来ログ・ファイルのサイズを記憶する工程を含んでおり、
   前記監視する工程は、前記スキャニング装置から受領したログ・ファイルの履歴的系列の履歴的平均サイズを算出する工程と、前記スキャニング装置から受領した各々の入来ログ・ファイルのサイズが、前記履歴的平均サイズから少なくとも所定の量だけ逸脱しているか否かを判定する工程と、をさらに含んでおり、
   前記算出する工程は、前記ログ・ファイルの履歴的系列から各々の入来ログ・ファイルを除外する工程をさらに含んでいる請求項１に記載のシステム。
6. 前記運用データは、前記スキャニング装置を識別するシステム・データと、前記スキャニング装置の利用状況を記録したデータとを含んでいる請求項１に記載のシステム。
7. 遠隔位置に設けられ、スキャニング・モードにおいて動作時にスキャンデータを取得可能なスキャニング装置（２）と、
   中央位置に設けられているコンピュータ・システム（１６、２２）と、前記スキャニング装置と前記コンピュータ・システムとを接続する通信チャネル（１８）とを備えたシステムであって、
   前記スキャニング装置は、前記スキャニング装置を使用して実施された各々の検査に対し、検査の標識子、検査日付、検査の開始時刻及び終了時刻、検査形式を含む運用データを取得し、記憶して、データ・ログ記録機能が作動しているときに該データ・ログ記録機能に従って前記通信チャネルを介して前記コンピュータ・システムに対し記憶されている運用データを含むログ・ファイルを定期的に送付することが可能であり、
   前記コンピュータ・システムは、
   前記スキャニング装置において前記データ・ログ記録機能を作動させる工程と、
   該作動させられたデータ・ログ記録機能に従って前記スキャニング装置からログ・ファイルを受領する工程と、
   受領した各ログ・ファイルの第１の特性を表す第１のデータを生成する工程と、
   受領したログ・ファイルの連続した各組の第２の特性を表す第２のデータを生成する工程と、
   入来ログ・ファイルの第一の特性が該第一の特性の履歴的基準値から逸脱した値を有しているとき、及び入来ログ・ファイルの第二の特性が該第二の特性の履歴的基準値から逸脱した値を有しているときを検出するように各々の入来ログ・ファイルの第１及び第２のデータを監視する工程とを実行するようにプログラムされている、システム。
8. 通信チャネル（１８）を介して多数の遠隔配置されたスキャニング装置（２）に接続された自動中央サービス施設（１６、２２）を備えたシステムであって、
   各々のスキャニング装置は、スキャニング・モードにおいて動作時にスキャンデータを取得し、前記スキャニング装置を使用して実施された各々の検査に対し、検査の標識子、検査日付、検査の開始時刻及び終了時刻、検査形式を含む運用データを取得し、記憶して、前記スキャニング装置に記憶されているデータ・ログ記録プログラムが作動しているときに該データ・ログ記録プログラムに従って前記中央サービス施設に対し記憶されている運用データを含むログ・ファイルを定期的に送付するようにプログラムされており、
   前記中央サービス施設は、
   各々の装置においてそれぞれのデータ・ログ記録プログラムを作動させる手段と、
   該作動させられたデータ・ログ記録プログラムに従って前記スキャニング装置からログ・ファイルを受領する手段と、
   受領した各ログ・ファイルの特性又は受領したログ・ファイルの連続した組の特性を表すデータを生成する手段と、
   特定の装置について、入来ログ・ファイルの特性が履歴的基準値から逸脱した値を有しているときを検出するように各々の入来ログ・ファイルのデータを監視する手段とを含んでいる、システム。
9. 遠隔位置に設けられている計算機式スキャニング装置からの集中型データ収集を監視する方法であって、
   前記スキャニング装置を使用して実施された各々の検査に対し、検査の標識子、検査日付、検査の開始時刻及び終了時刻、検査形式を含む運用データを記憶し、データ・ログ記録機能が作動しているときに該データ・ログ記録機能に従って前記通信チャネルを介して中央位置に対し記憶されている運用データを含むログ・ファイルを定期的に送付するように前記スキャニング装置をプログラムする工程と、
   前記通信チャネルを介して前記中央位置から前記スキャニング装置において前記データ・ログ記録機能を作動させる工程と、
   該作動させられたデータ・ログ記録機能に従って前記通信チャネルを介して前記スキャニング装置から前記中央位置においてログ・ファイルを受領する工程と、
   受領した各ログ・ファイルの特性又は受領したログ・ファイルの連続した組の特性を表すデータを生成する工程と、
   入来ログ・ファイルの特性が履歴的基準値から逸脱した値を有しているときを検出するように前記中央位置において各々の入来ログ・ファイルのデータを監視する工程と、を含んでいる方法。
10. 通信チャネル（１８）を介して多数の遠隔配置されたスキャニング装置（２）に接続された自動中央サービス施設（１６、２２）を備えたシステムであって、各々のスキャニング装置は、スキャニング・モードにおいて動作時にスキャンデータを取得し、前記スキャニング装置を使用して実施された各々の検査に対し、検査の標識子、検査日付、検査の開始時刻及び終了時刻、検査形式を含む運用データを取得し、記憶して、前記スキャニング装置に記憶されているデータ・ログ記録プログラムが作動しているときに該データ・ログ記録プログラムに従って前記中央サービス施設に対し記憶されている運用データを含むログ・ファイルを定期的に送付するようにプログラムされており、
    前記中央サービス施設は、
    前記作動しているデータ・ログ記録プログラムに従って前記スキャニング装置からログ・ファイルを受領する工程と、
    受領した各ログ・ファイルの特性又は受領したログ・ファイルの連続した組の特性を表すデータを生成する工程と、
    特定の装置について、入来ログ・ファイルの特性が履歴的基準値から逸脱した値を有しているときを検出するように各々の入来ログ・ファイルのデータを監視する工程とを実行するようにプログラムされているコンピュータ・システムを含んでいる、システム。

Images