JP2002157344A - 医用撮像装置の運用データ・ログ記録の自動的な作動開始及び作動停止 - Google Patents

Abstract

(57)【要約】 【課題】 中央サービス施設（１６、２２）から、遠隔
配置された医用撮像装置（２）のデータ・ログ記録機能
を、更新されたサービス契約情報の取得に応答して自動
的に作動開始及び作動停止させる方法及びシステムを提
供する。 【解決手段】 医用撮像装置が定期的なスキャナ利用状
況リポートを受領する契約下に現在あることを検出する
ために、顧客プロフィール・データ及びサービス契約デ
ータが中央施設において自動的に処理される。次いで、
スキャナ・データ・ログ記録機能が中央施設から自動的
に始動される。次いで、中央施設は、処理のために、及
び後続の利用状況リポート発行のために、作動開始した
医用撮像装置からの最初のデータ・ログ・ファイルの送
信が成功したことを確証するようにスキャナ・データ・
ログ・ファイルの受領を監視する。満了したサービス契
約の場合には、医用撮像装置のデータ・ログ記録機能は
中央施設から自動的に作動停止させられる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般的には、遠隔配
置されており利用者が運用する電子装置、例えば医療診
断に用いられる撮像装置から得られる運用データを編集
し及び／又は要約したリポートの集中型生成に関する。

【０００２】

【発明の技術的背景】診断用イメージング・システム
は、現在の健康管理施設の至る所で利用されている。か
かるシステムは、身体の状態を識別し、診断して治療す
るための重要なツールを提供しており、診断のための外
科的な介入の必要性を大幅に減じている。多くの場合に
は、担当医師又は放射線技師が、１種以上の撮像モダリ
ティを介して関連のある部位及び組織の詳細な画像によ
って従来式の検査を補完して初めて、最終的な診断及び
治療が開始する。

【０００３】現在、医用診断イメージング・システムと
して多くのモダリティが存在している。これらのモダリ
ティには、計算機式断層写真法（ＣＴ）システム、Ｘ線
システム（従来式のイメージング・システム及びディジ
タル式イメージング・システムの両方を含む）、磁気共
鳴（ＭＲ）システム、ポジトロン・エミッション断層写
真法（ＰＥＴ）システム、超音波システム及び核医学シ
ステム等がある。多くの場合に、これらのモダリティは
互いに補完し合って、特定の種別の組織、器官及び生理
系等を撮像するための広範な手法を医師に提供してい
る。健康管理施設はしばしば、単一の施設又は多数の施
設にこれらのイメージング・システムを幾つも配置して
おり、具体的な患者の必要性によって要求されると施設
の医師がかかる資源を利用できるようにしている。

【０００４】現在の医療診断イメージング・システムは
典型的には、画像データを取得すると共に、データを、
後に患者の体内の関心のある特徴の再構成画像を作成す
るように処理される有用な形態へ変換するサーキットリ
（回路要素）を含んでいる。この画像データ取得及び処
理用サーキットリを、撮像過程の一部として物理的又は
電子的な走査が生じさえすればモダリティに拘わらず
「スキャナ」と呼ぶものとする。システム及び関連する
サーキットリの特定の構成要素は、物理的原理及びデー
タ処理要求が異なるので、当然モダリティ間で大幅に異
なっている。本書では、「スキャナ」、「医用撮像装
置」及び「診断用撮像装置」なる用語は互換的に用いら
れる。

【０００５】上述した形式の医療診断システムはしばし
ば、かなりの有効寿命にわたって要求された日程の範囲
内で信頼性があり且つ理解可能な画像を生成することが
要求される。適正な動作を確実に行なわせるために、シ
ステムは高度な訓練を受けた人員によるサービスを定期
的に受けて、この人員が撮像上の問題に対処し、システ
ムを構成設定及び較正すると共に、定期的なシステム点
検及びソフトウェア更新を行なう。さらに、近年では、
サービスの提供が、契約加入施設のスキャナに直接接触
可能なサービス・センタによって補われており、施設人
員の一部を割いて介入する必要性がなくなっている。か
かる集中型サービス提供は、医師又は放射線技師が注意
を払う必要なしに診断システムを良好な動作状態に維持
することを目的としており、施設から見ると全く透明で
ある場合が多い。

【０００６】幾つかの集中型サービス提供システムで
は、コンピュータ化されたサービス・センタがネットワ
ークを介してスキャナに接触して、システム構成及び動
作状態を点検し、リポート生成用のデータを収集すると
共に、他の有用なサービス機能を果たす。かかる接触は
システム「スイープ（sweep 、システムに一時的に接触
して、必要な作用を与える動作）」時等に定期的に行な
うことができる。このシステム・スイープ時には、特定
のスキャナについて様々なシステム性能データが収集さ
れて、履歴データと共に記憶される。次いで、これらの
データを用いてシステム性能を評価して、サービス人員
の訪問を提案し又は予定に組む等を行なうことができ
る。

【０００７】かかるサービス手法は、診断システムを保
守するのに極めて有用であることが分かっているが、改
良の余地は依然としてある。スキャナとサービス・セン
タとの間の対話的相互作用（interaction ）が透明であ
るので、医療人員がサービス更新によって不必要に煩わ
されることは回避されるが、サービス・センタと施設と
の間にはある程度の対話的相互作用があることが極めて
望ましい。具体的には、対話型サービス・システムであ
れば、システム性能のリポート、注意を要する特定の事
象についてのフィードバック、並びにシステム・ライセ
ンス、ソフトウェア及び撮像プロトコルの更新等を含め
た有用な情報交換が容易になる。現状で利用可能なサー
ビス・システムはかかる対話型交換が可能である。具体
的には、異なるモダリティが対話型サービスの提供を必
要とする場合の基地としての役割を果たすプラットフォ
ームが開発されている。このプラットフォームによっ
て、中央サービス・センタが、遠隔配置されたスキャナ
と、可能性のあるサービス上の問題についての情報を交
換することができ、またこれらのスキャナにサービス提
供を行なう目的でスキャナから情報又はデータ・ログ・
ファイルを検索することが可能になる。一つの公知のプ
ラットフォームは、医師及び放射線技師が異なるモダリ
ティの様々なスキャナを運転したり、統一的な直感的な
形式を介してスキャナについてのサービス上の問題を報
告したりすることを可能にする統一的インタフェイスを
設けている。

【０００８】遠隔位置に設けられている診断設備にサー
ビス提供するための公知の統合型利用者対話型プラット
フォームは、スキャナ側のソフトウェア、ハードウェア
若しくはファームウェアにおいて構成設定されていても
よいし、又は医療施設内の様々なスキャナを結合する中
央操作者ステーションに設けられていてもよい。ユーザ
・インタフェイスによって、診断設備に対して実行され
る検査の前、途中又は後に、サービス要求を生成するこ
とが可能になる。ユーザ・インタフェイスはまた、サー
ビス・メッセージ送信、リポート生成及び検索等を可能
にする。ユーザ・インタフェイスは好ましくは、ネット
ワーク・ブラウザとして構成されており、イントラネッ
ト又はインターネット等のネットワークにスキャナ又は
中央施設制御ステーションを結合することも容易にして
いる。また、同じユーザ・インタフェイスを異なるモダ
リティのスキャナに組み入れることにより、運転人員に
よるサービス要求等をさらに容易にすることができ、運
転人員が施設の多様なインタフェイスに改めて精通する
必要がない。

【０００９】具体的には、既存の利用者対話型プラット
フォームは、遠隔施設のスキャナの運用履歴に基づくス
キャナの利用状況リポートを中央サービス・センタから
要求する能力をシステム利用者に与えている。かかる利
用状況リポートを作成するためには、これらのスキャナ
から運用データを定期的に収集することが必要である。
既存のシステムによれば、スキャナをプログラムして、
スキャナ自身の運用データをコンピュータ・メモリに収
集し、次いで、このデータを、中央施設がスキャナに入
力した予めプログラムされている予定に従って中央施設
に先行的に送信しておくようにすることができる。デー
タ・ログ記録及びリポート生成を可能にするサービス契
約によってカバーされているスキャナのみが、中央施設
に対しログ記録された運用データを送信することにな
る。中央施設は、契約によってカバーされているすべて
のスキャナからの運用データのログ・ファイルを収集し
て処理した後に、スキャナ利用状況リポートを生成する
ことができる。具体的には、病院の管理者は、広域ネッ
トワーク又はインターネットを介して、当該病院におい
て契約下にある医用撮像装置（すなわちスキャナ）につ
いて収集された運用データを編集し且つ／又は要約した
利用状況リポートをいつでも要求することができる。

【００１０】上述の既存のシステムによれば、各々のス
キャナにデータ・ログ記録プログラムが記憶されている
が、このプログラムは当該スキャナが妥当なサービス契
約によってカバーされるまで作動開始しない。同様に、
特定のスキャナをカバーしているサービス契約が満了す
ると、当該スキャナに組み入れられているデータ・ログ
記録の特徴を作動停止させる必要がある。スキャナから
の運用データの収集に関わる様々な異なるコンピュータ
系システム、すなわち契約システム、接続性提供システ
ム及びスキャナ自体、が存在している。現在、これらの
システムを共に繋いでいるのは手動の過程である。具体
的には、スキャナ上のデータ・ログ記録の特徴を始動さ
せたり停止させたりするために手動の過程が現在用いら
れている。新規のサービス契約の場合には、スキャナを
手動で作動開始させる際の遅延のため、利用状況リポー
ト発行サービスが期日に提供されないことがある。ま
た、満了したサービス契約の場合には、スキャナを手動
で作動停止させる際の遅延のため、利用状況リポート発
行サービスがサービス契約停止日を超えて何か月にもわ
たって無料で提供されることがしばしばである。

【００１１】従って、新規のサービス契約が開始したと
きにスキャナのデータ・ログ記録機能を自動的に作動開
始させ、一旦サービス契約が満了したらデータ・ログ記
録機能を同様に作動停止させることのできる運用モデル
が必要とされている。この運用モデルはまた、関連する
リポート発行過程を自動的に作動開始させ、また作動停
止させるべきである。

【００１２】

【発明の概要】本発明は、中央サービス施設から、遠隔
配置された医用撮像装置の運用データ・ログ記録機能を
自動的に作動開始及び作動停止させる方法及びシステム
を指向している。具体的には、好適実施形態は、医用撮
像装置が定期的なスキャナ利用状況リポートを受領する
契約下に現在あることを検出するために中央施設におい
て契約データを自動的に処理する工程と、中央施設から
スキャナ・データ・ログ記録機能の特徴を自動的に遠隔
から始動させる工程と、処理のために、及び後続の利用
状況リポート発行のために、作動開始した医用撮像装置
からの最初のデータ・ログ・ファイルの送信が成功した
ことを確証するように中央施設において受領されるスキ
ャナ・データ・ログ・ファイルを監視する工程とを備え
た方法を指向している。満了したサービス契約の場合に
は、医用撮像装置のデータ・ログ記録機能は中央施設か
ら自動的に作動停止させられる。

【００１３】好適実施形態の更なる側面によれば、関連
するリポート発行機能もまた、新規の又は満了するサー
ビス契約によってカバーされているスキャナでのデータ
・ログ記録機能の作動開始及び作動停止と同時に自動的
に作動開始及び作動停止させられる。リポートは、顧客
からのアクセス要求に応答して、広域ネットワーク、例
えばインターネットを介して発行される。ウェブ方式利
用状況リポートを発行するリポート・サーバは、データ
・ログ・ファイルを受領する中央サービス施設から遠隔
に配置されていてもよい。

【００１４】加えて、好適実施形態によれば、スキャナ
・データ・ログ記録機能の自動的な作動開始又は自動的
な作動停止が失敗した場合には、中央施設によって修正
処置が講じられる。中央サービス施設は、契約下にある
すべてのスキャナのデータ・ログ記録サービス状態を追
跡するリポートを生成する「管理ツール」をさらに組み
入れている。

【００１５】顧客が、スキャナからのログ記録データに
基づいてスキャナ利用状況リポートを受領するサービス
契約を結ぶ度毎に、中央サービス施設によって提供され
るあらゆる他のサービスの特徴の場合と同様に、顧客情
報及び契約明細がサービス契約データベースに登録され
る。本発明の好適実施形態によれば、この顧客プロフィ
ール情報及びサービス契約情報は、所謂「抽出出力ファ
イル」として中央のサービス契約データベースから自動
的に定期的に抽出される。「抽出出力ファイル」のレコ
ードは運用サーバによって、同じ運用サーバによってロ
ーカル・データベースに保持されている所謂「契約テー
ブル」のレコードと比較される。相違があればすべてロ
ーカル・データベースに登録され、すなわち「抽出出力
ファイル」において検出された新規レコード及び変更レ
コードが「契約テーブル」に追加される一方、「契約テ
ーブル」には見出されるが「抽出出力ファイル」には見
当たらないレコードは「契約テーブル」から除去され
る。上述の相違は、新規の契約、満了した契約、及び契
約条件の変更等を示している。ローカル・データベース
に以前に存在していなかった新たな医用撮像装置は、契
約開始日について追跡される。ローカル・データベース
に存在しているが「抽出出力ファイル」には現われない
既存の医用撮像装置は、データ・ログ記録機能を停止す
るように標識を付される。

【００１６】本発明の好適実施形態によれば、運用サー
バから自動サポート・センタ・サーバへ、スキャナを作
動開始及び作動停止させるための動作の一覧が自動的に
送付される。具体的には、自動サポート・センタ・サー
バは、特定の医用撮像装置のデータ・ログ記録機能、及
び先行的診断過程を介して自動サポート・センタ・サー
バへ運用データを返送する運用データの予定先行的送信
を起動（又は停止）させる命令を送る。自動サポート・
センタ・サーバによる作動開始の試行が失敗した場合に
は、手動介入を行なえるようにシステム管理者に自動的
に通知される。最初のスキャナ・データ・ログ・ファイ
ルが、割り当てられた予測受領日から所定の日数（例え
ば２日）以内に受領されなかった場合にも、やはり、デ
ータ・ログ記録の特徴が始動されていること、及び遠隔
のスキャナと自動サポート・センタ・サーバとの間の接
続性が失われていないことを確証する介入を行なうよう
に、システム管理者に自動的に通知される。逆に、スキ
ャナが停止された場合には、割り当てられた停止日の後
にも自動サポート・センタ・サーバにスキャナ運用デー
タが到着し続けているようであれば、システム管理者に
自動的に通知される。

【００１７】

【好適実施形態の詳細な説明】本発明は、放射線部門の
業務、処理、患者フロー及び臨床実務を支援するための
情報を提供するシステム及び方法を指向している。放射
線部門に設けられている各々のスキャナが、処理のため
に中央サーバへ運用データを送付する。収集されるデー
タは、キー部門の生産性、質、並びに患者の満足度の目
標及び課題に基づいてキーのスキャナ・パラメータを測
定するものである。収集されたデータに基づいて、中央
位置においてスキャナの利用状況レポートが生成され
る。これらのリポートには、インターネットを介して顧
客がアクセスすることができる。スキャナは、計算機式
断層写真法（ＣＴ）システム、磁気共鳴（ＭＲ）システ
ム、超音波イメージング・システム又は他の任意の形式
の計算機式医用撮像装置を包含している。

【００１８】図１に、データ及び処理の高レベルでのフ
ローを示す。各々のスキャナ２が、収集及び変換のため
に中央プロセッサ４へ運用データのログを送付する。変
換されたデータは、顧客／施設データベース６から読み
出した医療設備のプロフィール・データと共にデータ記
憶部８に記憶される。記憶されたデータは、リポート発
行システム１０へ定期的に送付される。顧客１２は、セ
キュリティ・サーバ１４に対し、有効性のある認証セキ
ュリティ因子（例えば、ＩＤ及びパスワード）を入力す
るとこれらのリポートにアクセスすることができる。セ
キュリティ・サーバは、リポート発行システム１０へ有
効性確認を送る。

【００１９】図２を参照して述べると、各々のスキャナ
２から、モデム１８、私設ネットワーク２０又は他の任
意の適当な通信チャネルを介して自動サポート・センタ
・サーバ１６によってデータが収集される。各々のスキ
ャナは、所定の運用関連データをログ記録した後に、ロ
グ記録したデータを自動サポート・センタ・サーバ１６
へ送付するようにプログラムされている。

【００２０】好ましいスキャナ出力フォーマットは、シ
ステム・データと検査データとを含んでいる。システム
・データには、新たな検査が開始したときに示された時
刻スタンプ、スキャナ・モダリティ、製品名、システム
ＩＤ（すなわち、特定の顧客の特定の位置でのスキャナ
に固有のＩＤ）、所謂固有システム番号（ＵＳＮ。時
間、位置及び所有者に拘わらないスキャナの固有キ
ー）、所謂移動位置番号（ＭＬＮ。特定の時刻のスキャ
ナの特定の位置を追跡するのに用いる）、並びに病院名
等があるがこれらに限定されない。検査データには、同
じ時刻スタンプ、検査日付、検査の開始時刻及び終了時
刻、検査番号、患者ＩＤ、患者年齢、患者性別、患者体
重、患者病歴、患者状態、放射線技師ＩＤ、担当医Ｉ
Ｄ、操作者ＩＤ、検査説明、検査データ、検査系列、並
びに検査形式等を所謂カレント・プロトコル・ターミノ
ロジ（ＣＰＴ）・コードの形態にしたものがあるがこれ
らに限定されない。スキャナは、先行的診断転送機構を
用いて自動サポート・センタ・サーバ１６へこのデータ
を転送する。先行的診断データ転送機構を実行する場合
には、スキャナはデータ・ログ記録サービスＩＤを用い
る。スキャナは、最後の転送からの時間に基づいて、又
はデータが所定のサイズ閾値に達した場合に、このデー
タを転送するようにプログラムされている。転送間の最
長時間、及びデータ・サイズ閾値は、スキャナ単位で構
成設定可能である。また、運用データが自動サポート・
センタ・サーバへ送付される時刻もスキャナ単位で構成
設定可能である。

【００２１】自動サポート・センタ・サーバ１６は、Ｕ
ＳＮ、ＭＬＮ又はこれら２つの組み合わせによってスキ
ャナ・データ・ファイルを記憶する。自動サポート・セ
ンタ・サーバ１６は、データ・ログ記録サービスＩＤと
共に送付された新たなファイルが到着した場合には必
ず、サービス提供者の内部ネットワークを介して運用サ
ーバ２２に当該ファイルを送付することにより運用サー
バ２２に通知する。自動サポート・センタ・サーバ１６
は、運用サーバ２２へデータ・ファイルを送付すること
に成功しなかった場合には、エラー・メッセージをログ
記録して、適当なシステム管理者に通知する。自動サポ
ート・センタ・サーバ１６はまた、有効性のあるサービ
ス契約に従ってログ記録データのリポートを得る認証を
受けているスキャナ・システムに対し、システム管理者
がデータ・ログ記録の特徴及び先行的診断データ転送を
遠隔からイネーブルにしたりディスエーブルにしたりで
きるようにする機構を提供している。スキャナ・サイト
が作動開始又は作動停止した場合には、自動サポート・
センタ・サーバ１６は、スキャナ・サイトの新たな状態
を運用サーバ２２に通知する。

【００２２】顧客が、契約によってカバーされているス
キャナからのログ記録データに基づいてスキャナ利用状
況リポートを受領するサービス契約を結ぶ度毎に、中央
サービス施設によって供給されるあらゆる他のサービス
の特徴の場合と同様に、顧客プロフィール情報及び契約
明細がサービス契約データベースに登録される。本発明
の好適実施形態によれば、この顧客プロフィール情報及
びサービス契約情報は、運用サーバ２２によって中央の
サービス契約データベースから自動的に定期的に抽出さ
れて、運用サーバ２２によって保持されているローカル
・データベースの顧客プロフィール情報及び契約情報の
テーブルと比較される。それぞれのファイルのレコード
の間に相違があればすべてローカル・データベースに登
録され、すなわち新規レコード及び変更レコードがロー
カル・データベースに追加される一方、満了したサービ
ス契約に対応するレコードはローカル・データベースか
ら除去される。ローカル・データベースに以前に記録さ
れていなかった新たなスキャナは、契約開始日について
追跡される。ローカル・データベースに記録されている
が満了したサービス契約によってカバーされている既存
のスキャナは、データ・ログ記録機能を停止するように
標識を付される。

【００２３】本発明の好適実施形態によれば、運用サー
バ２２から自動サポート・センタ・サーバ１６へ動作の
一覧が自動的に送付される。すると、自動サポート・セ
ンタ・サーバ１６は、特定のスキャナ２のデータ・ログ
記録機能、及び先行的診断過程を介して自動サポート・
センタ・サーバへ運用データを返送する運用データの予
定先行的送信を起動（又は停止）させる命令を送る。

【００２４】一旦、データ・ログ記録が開始してから
は、運用サーバ２２は、自動サポート・センタ・サーバ
１６からスキャナ・データをログ記録したファイルが到
着したとのメール通知を受け取ると、スキャナ・ファイ
ルの有効性を確認する。有効性確認は次の工程を含んで
いる。ファイルの「文法」（例えばＭＲ又はＣＴ）を識
別する工程、及びサービス製品についてのすべてのフィ
ールドがレコードに存在しており正しい形式となってい
ることを検証する工程。レコードが完全でなく（すなわ
ちフィールドが欠落している）又は不正確である場合に
は、レコードをログ記録して削除する。運用サーバ２２
は、スキャナ・ファイルのデータ・フィールドの値に基
づいてＣＰＴコードを生成する。運用サーバ２２はま
た、要求されたフィールドを所定のＸＭＬフォーマット
に符号化する。ファイルが処理されたら直ちに、運用サ
ーバ２２は、圧縮ＸＭＬフォーマットの処理済（すなわ
ち変換済）スキャナ・ファイルをサービス提供者の内部
ネットワークを介して作成サーバ２８へ送付する。

【００２５】運用サーバ２２はまた、どのスキャナ・サ
イトがデータを送付しているか、送られたデータの量、
及びデータを受領した時刻を記録する。運用サーバは、
保守サービス取り決め（ＭＳＡ）に関連する契約情報に
よって稼働する作動中サイト一覧／データベースを保持
している。ＭＳＡサービス契約情報は、サービス提供者
の内部ネットワークを介してＭＳＡ中間処理（staging
）サーバ２６から運用サーバによって毎日受領され
る。サーバ２６は次に、ＭＳＡ契約情報データベース２
４から契約情報を検索する。運用サーバ２２は、作動中
サイト一覧にあるスキャナ・サイトが構成設定可能な時
間を上回ってファイルを提出していなければシステム管
理者に通知する。また、運用サーバ２２は、データ受領
頻度及びデータ・ファイル・サイズの履歴をスキャナ単
位で表示するシステム管理利用目的のウェブ・ページを
提供する。

【００２６】続けて図２を参照して述べると、データ記
憶部３０は、ＸＭＬ符号化されたスキャナ・データを、
運用サーバ２２によってデータが送付されたら必ず、作
成サーバ２８から受領する。検査間時間及び検査時間等
の導出されるデータ値は作成サーバ２８によって算出さ
れ、データベース３０に記憶される。データ記憶部３０
はまた、ＸＭＬ符号化された更新された施設プロフィー
ル・データを、運用サーバ２２によってデータが送付さ
れたら必ず、作成サーバ２８から受領する。

【００２７】本発明の好適実施形態によれば、セキュリ
ティ・サーバ１４はリポート・サーバ３２から物理的に
離隔している。また、セキュリティ・サーバ・データベ
ースはリポート・サーバ・アプリケーション・データベ
ースから離隔している。すべてのリポートへの顧客のア
クセスは、インターネット３４上の所謂セキュア・ソケ
ット・レイヤ（Secure Socket Layer 、ＳＳＬ）を介し
て行なわれる。顧客は、インターネット３４を介してセ
キュリティ・サーバ１４へ利用者ＩＤ及びパスワード又
はアクセス・コードをアップロードしなければならな
い。すべての利用者パスワード及び／又はアクセス・コ
ードは暗号化される。セキュリティ・サーバ１４は、利
用者の有効性を確認し、利用者の所属資格を判定して、
アクセス特権を割り当てる。アクセス特権によって、当
該顧客のサービス契約に基づいて顧客がどのリポートを
利用できるかが決まる。セキュリティ・サーバ１４は、
有効性が確認された利用者が、リポート・サーバ３２か
ら提供されインターネット３４を介して顧客側アクセス
・ステーションへ送信される適当なリポートにアクセス
することを許可する。

【００２８】リポート・サーバ３２によって生成される
すべての利用状況リポートは、作成サーバ２８に送付さ
れたスキャナ・データに基づく。すべての図形的リポー
トが、出力の外観を変更する構成設定可能な表示オプシ
ョン（円グラフ、棒グラフ等）をサポートしている。好
ましくは、リポート・サーバ３２は、Ｗｉｎｄｏｗｓ
（登録商標）９５／98／NTプラットフォーム上でIntern
et Explorer 4.01以上、及びNetscape 4.5以上と互換性
のある利用状況リポートを発行する。クライアントが互
換性を有していなければ、メッセージを利用者に送っ
て、互換性のあるブラウザへのリンクを表示する。リポ
ート・サーバはまた、リポートのための時間軸の構成設
定可能な選択肢を提供するようにプログラムされてい
る。リポート・サーバは、傾向を示すリポート及び対基
準評価を示すリポートを生成する。

【００２９】多数のリポートのひな形がサポートされて
いる。これらのひな形は、その各々が幾つかのリポート
を含むグループにグループ分けされる。各グループへの
アクセスは、利用者アクセスに基づいたものとしてよ
い。例えば、リポート・サーバは、スタディ・ミックス
（study mix 、研究構成）、スタディ量、スタディ形式
毎の画像データ及び系列データ、スタディ・ミックス毎
の量、時刻及び曜日毎のスタディ・ミックス、スタディ
・ミックス毎の検査時刻、検査期間毎のペイシェント・
ミックス（patient mix 、患者構成）、時刻毎の検査
量、曜日毎のシステム利用状況、スタディ・ミックス毎
のＣＴ走査の処理時間、スタディ・ミックス毎の検査内
時間、検査期間、放射線技師毎の量、担当医毎の量、放
射線技師毎のＣＴ走査の処理時間、検査技師毎の検査時
間、年齢毎の患者量（男性及び女性）、担当医毎のスタ
ディ・ミックス（検査回数）、放射線技師毎のスタディ
・ミックス（検査回数）、並びに放射線技師毎の検査当
たりの系列及び画像数を示すリポートを生成し発行する
ことができる。

【００３０】本発明の好適実施形態は、患者へのサービ
ス提供のうち「検査」段階を中心とした臨床実務（スタ
ディ、ミックス）、運用管理（量、利用状況）、及び顧
客の人口統計的分析（担当医、患者年齢等）について、
重要な決定を支援する情報を放射線部門に与えるウェブ
送付式サービス製品又はサービス能力である。

【００３１】好適実施形態によるシステムは、決定支援
リポートを生成するのに二つの形式のデータすなわちス
キャナ・ログ・データ及び施設プロフィール・データを
利用する。施設プロフィール・データは、会計記録及び
データの対基準評価の目的のために保持されている。

【００３２】好適実施形態によるデータ・リポート発行
過程は、サービス契約管理過程に組み入れられている。
スキャナ利用状況リポート発行サービス契約に基づく施
設プロフィール・データが取得されて処理される。この
サービス契約情報に基づいて、スキャナ上でのデータ・
ログ記録動作を自動的に制御する機構すなわち作動開始
及び作動停止させる機構が確立される。運用サーバが、
毎日の作成時にスキャナ状態の記録を取る。ウェブ方式
ユーザ・インタフェイスを用いて、顧客、契約及びスキ
ャナ状態に関連した情報を管理する。

【００３３】インターネットを介して送信された顧客の
要求に応答して、遠隔のスキャナから中央オフィスへの
自動データ・ログ記録、及び中央オフィスによるデータ
のリポート発行を提供する各々のサービス契約は、少な
くとも次の情報を有している。（１）サービス提供者と
契約を交わした顧客名。顧客は、多数の病院から成る団
体、多数箇所に分かれた病院施設又は単一箇所の病院施
設のいずれであってもよい。（２）契約下にカバーされ
ている病院施設名。多数の病院から成る団体型の顧客で
ない場合には、施設は顧客と同じであってよい。（３）
スキャナが設置されている病院施設の詳細な住所。所番
地、都市、州、国及び郵便番号を含む。（４）契約下に
カバーされている各々の病院施設の各スキャナのシステ
ムＩＤ。（５）各々のスキャナ毎に多階層サービスのど
の階層が契約下にあるかを示す標識子。（６）各々のス
キャナ毎の契約開始日。（７）契約終了日。すべてのス
キャナで同じになる。（８）利用者契約情報。

【００３４】図３は、顧客プロフィール・データ、契約
データ及びスキャナ状態データのデータ・フローを示
す。本発明の好適実施形態によれば、中央サービス施設
の運用サーバ２２（図２を参照）は、「契約テーブル」
及び「スキャナ状態テーブル」を保持している。加え
て、運用サーバ２２は、「ログ受領履歴テーブル」を保
持するデータ・プリプロセッサ（図示されていない）を
組み入れている。これら３つのテーブルのすべてがOrac
leデータベース内に備えられている。「契約テーブル」
はデータベース３０内で毎日更新される。

【００３５】ＭＳＡ中間処理サーバ２６（図２を参照）
は、ＭＳＡ契約データベース２４のような既存のデータ
源から顧客プロフィール・データ及び契約データを抽出
するようにプログラムされている。有効性のあるスキャ
ナ利用状況リポート発行サービス契約によってカバーさ
れているあらゆるスキャナ２が「抽出出力ファイル」３
８（図３を参照）内にレコード（１又は複数）を有して
いる。一つのスキャナは、スキャナが有する多数のサー
ビス契約を反映して多数のレコードを有していてもよ
い。「抽出出力ファイル」は、ファイルが生成された日
時を含めたヘッダ行を有する。「抽出出力ファイル」の
各々の記録が、付録の表１に定義されているようなデー
タ・フィールドを有している。

【００３６】好ましくは、出力ファイルは、ファイルの
１行が１つのレコードを表わしており「｜」を区切り文
字とするフラット・ファイルである。好ましくは、ファ
イルは毎日生成される。「抽出出力ファイル」はＭＳＡ
中間処理サーバ２６に記憶されており、運用サーバ２２
によるアクセスが可能である。「抽出出力ファイル」は
毎日の更新時に上書きされてもよい。

【００３７】図２に示す好適実施形態によれば、運用サ
ーバ２２はＭＳＡ中間処理サーバ２６からスケジュー
ル、例えば毎日の所定の時刻といったスケジュールに従
ってＭＳＡ抽出ファイルを取り出す。運用サーバ２２
は、抽出ファイルを、成功するまで１時間に１回ずつ取
り出そうと試みるようにプログラムされている。運用サ
ーバは、所定の回数、例えば５回にわたってファイルの
取り出しが失敗したら「事象ログ」に「警報」を記録す
る。運用サーバはファイル名を、YYYY、MM、DDを受領日
のそれぞれ年、月、日としてScanPATH#YYYYMMDD.txt と
改める。

【００３８】好適実施形態によれば、運用サーバは、デ
ータ源から抽出されたすべての顧客プロフィール・デー
タ及び契約データを記憶する「契約テーブル」との名称
のデータベース・テーブルを保持している。「契約テー
ブル」は１つのスキャナについて１つのレコードを有し
ている。有効性のあるスキャナ利用状況リポート発行サ
ービス契約によってカバーされているあらゆるスキャナ
が「契約テーブル」内にレコード（１又は複数）を有す
る。「契約テーブル」の各々のレコードは、付録の表２
に定義されているようなデータ・フィールドを有する。
「契約テーブル」の第１キーは、「システムＩＤ」／
「契約番号」／「認知キー（Ｒｅｃ−Ｋｅｙ）」の組み
合わせである。

【００３９】運用サーバ２２はまた、「契約テーブル」
へのすべての挿入及び変更を記録する「契約監査テーブ
ル」との名称のデータベース・テーブルを保持してい
る。契約監査テーブルは、表２のフィールド１〜４１に
ついて「：旧値」及び「：新規値」のためのフィールド
を有し、また、監査レコードが挿入されたときの日時ス
タンプのためのフィールドを有している。挿入を追跡す
るために「契約テーブル」に「挿入トリガ」が設けられ
ており、「契約監査テーブル」の「：新規値」フィール
ドに、挿入されたレコードを追加できるようにしてい
る。変更を追跡するためには「契約テーブル」に「変更
トリガ」が設けられており、「契約監査テーブル」に、
変更されたレコードを「：旧値」及び「：新規値」につ
いて追加できるようにしている。表２の「監査変更要
否」の欄に「要」とマークされたいずれかのフィールド
が変更されると、「契約テーブル」は「変更トリガ」を
起動して、レコードは決定支援の特徴を有するようにな
る。

【００４０】図４に示す流れ図に従って述べると、発効
中の契約に対応する「抽出出力ファイル」の次のレコー
ドＹが運用サーバによって読み出されて（ステップ４
０）、カレントの「契約テーブル」のレコードと比較さ
れる。本発明の好適実施形態によれば、「ＭＳＡ抽出出
力ファイル」からの契約のうち次の条件の１つを満たす
ものが「契約テーブル」の「新規レコード」である（図
４のステップ５６、６０及び７４）。（１）「契約テー
ブル」に以前に存在していない「契約番号」を有する
（図４の判定ブロック５４によって決定される）。
（２）「契約テーブル」に以前に存在していない「シス
テムＩＤ」を有する（図４の判定ブロック５８によって
決定される）。（３）「契約認知キー」フィールドに値
１（将来）を有し、且つ同じ「契約番号」及び「システ
ムＩＤ」を有する「契約テーブル」からの固有のレコー
ドが見出される（図４の判定ブロック７０によって決定
される）が、このレコードは代わりに「契約認知キー」
フィールドに値０（現在）を有する（判定ブロック６２
によって決定される）。次の条件を満たす「ＭＳＡ抽出
出力ファイル」からの契約は、「契約テーブル」の「無
変更レコード」である（図４のステップ４６）。「契約
テーブル」の既存のレコードとすべてのデータ・フィー
ルドが完全に一致する（図４の判定ブロック４２によっ
て決定される）。次の条件の１つを満たす「ＭＳＡ抽出
出力ファイル」からの契約は、「契約テーブル」の「変
更レコード」である（図４のステップ５２及び６８）。
（１）同じ「契約番号」、「システムＩＤ」及び「契約
認知キー」を有する固有のレコードが「契約テーブル」
から見出されるが、少なくとも１つの他のフィールドに
ついて当該レコードと異なる値を有する（図４の判定ブ
ロック４８によって決定される）。（２）同じ「契約番
号」及び「システムＩＤ」であるが「契約認知キー」の
値が１である固有のレコードが「契約テーブル」から見
出される（図４の判定ブロック６４によって決定され
る）一方で、当該レコードは値０を有する（判定ブロッ
ク６２によって決定される）。これは、将来の契約の時
期が到来したことを表わす。最新の「ＭＳＡ抽出出力フ
ァイル」に含まれていない「契約テーブル」内のレコー
ドは、「除去レコード」である。構文解析アルゴリズム
の様々な段階（すなわち図４のブロック４４、５０、６
６及び７２）において、構文解析されているレコード内
のデータにエラーが検出された場合にエラー標識子が生
成される。

【００４１】最新の「ＭＳＡ抽出出力ファイル」から
「新規レコード」が識別されたら、「契約テーブル」に
新規レコードが追加される。「処理日」の値はカレント
のシステム日付に設定される。「契約猶予期間終了日」
の値は契約終了日から所定の日数後に設定される。「契
約状態」フィールドは値Ｌ（発効中）に設定される。
「レコード状態」フィールドは値Ａ（追加）に設定され
る。他のすべてのフィールドの値は「ＭＳＡ抽出出力フ
ァイル」からのレコードに従って設定される。

【００４２】「契約テーブル」のレコードは、「無変更
レコード」と定義された場合には次のようにして変更さ
れる。「レコード状態」フィールドの値はＮ（無変更）
に設定される。他のすべてのフィールドの値は変更され
ない。

【００４３】「契約テーブル」のレコードは、「変更レ
コード」と定義された場合には次のようにして変更され
る。「処理日」の値は変更されない。「契約猶予期間終
了日」の値は契約終了日から所定の日数後に設定され
る。「契約状態」フィールドの値は変更されない。「レ
コード状態」フィールドの値はＣ（変更）に設定され
る。他のすべてのフィールドの値は「ＭＳＡ抽出出力フ
ァイル」のレコードに従って変更される。「変更レコー
ド」は、すべてのフィールドについてのその旧値及び新
規値と共に、変更時のシステム日時と共に運用サーバに
よって「事象ログ」にログ記録される。

【００４４】「契約テーブル」のレコードは、「除去レ
コード」と識別された場合には次のようにして変更され
る。「契約状態」フィールドの値はＤ（失効）に設定さ
れる。「レコード状態」フィールドの値は、更新された
「契約テーブル」に基づいて「契約更新ファイル」（後
述）が生成された後にＲ（除去）に設定される。他のす
べてのフィールドの値は変更されない。

【００４５】以上に述べた過程から、「ＭＳＡ抽出出力
ファイル」を「構文解析」することにより「契約テーブ
ル」が生成される。本書で用いる場合には、「構文解
析」という用語は、１つのファイルの各フィールドを選
択して値を判定した後に、これらの値を他のファイルの
既存のフィールドの値と比較することを指す。好ましく
は、ＭＳＡ抽出ファイルは、運用サーバによる受領の後
に毎日構文解析される。「ＭＳＡ抽出出力ファイル」を
構文解析する前に、「契約テーブル」のあらゆるレコー
ドの「レコード状態」フィールドをＩ（初期）に設定す
る。運用サーバは、図４に示すアルゴリズムを用いてレ
コード毎にＭＳＡ抽出ファイルのレコードを構文解析す
る。「ＭＳＡ抽出出力ファイル」を構文解析した後にも
「レコード状態」フィールドに値Ｉを依然として有する
「契約テーブル」のあらゆるレコードは「除去レコー
ド」である。抽出アルゴリズムは、「ＭＳＡ抽出出力フ
ァイル」の最後のレコードが構文解析されたと判定した
ら（図４の判定ブロック７６）終了する。

【００４６】好適実施形態の更なる特徴によれば、運用
サーバ２２（図２を参照）は、作成サーバ２８がそのサ
ービス契約情報を更新するための「契約更新ファイル」
を生成する。「契約更新ファイル」は、「ＭＳＡ抽出出
力ファイル」の構文解析及び「契約テーブル」のレコー
ドに対する操作が完了した後に毎日生成される。「契約
更新ファイル」は運用サーバ２２に記憶されて、作成サ
ーバ２８からアクセスすることが可能である。「契約更
新ファイル」は、「契約テーブル」からのすべての発効
中レコード（「契約状態」が「Ｌ」）、追加レコード、
変更レコード又は除去レコード（それぞれ「レコード状
態」が「Ａ」、「Ｃ」又は「Ｒ」）から成っている。
「契約更新ファイル」には「無変更レコード」（「レコ
ード状態」が「Ｎ」）は複写されない。「契約更新ファ
イル」は好ましくは、ＸＭＬフォーマットである。レコ
ードのデータ・フィールドは「契約テーブル」から複写
される。

【００４７】また、スキャナから受領されたログ・デー
タの履歴を追跡するために、「ログ受領履歴テーブル」
との名称のデータベース・テーブルが作成されて保持さ
れる。運用サーバが受領した各々のログ・ファイルが
「ログ受領履歴テーブル」に唯一のレコードを有する。
各々のスキャナがテーブル内に多数のレコードを有して
いてもよく、この場合には、同じスキャナから多数のロ
グ・ファイルが得られていることを表わす。「ログ受領
履歴テーブル」のあらゆるレコードは、次のデータ・フ
ィールドを有する。（１）第１キーは「ＩＤ」フィール
ドであって、レコードが挿入されたときに自動生成され
る数字列である。（２）ログ・ファイルを送付するスキ
ャナの「システムＩＤ」を保持する「システムＩＤ」フ
ィールド。（３）ログ・ファイルがデータ・プリプロセ
ッサによって受領されたときの日時を有する「受領日
時」ファイル。（４）受領したログ・ファイルのサイズ
を含む「ファイル・サイズ」フィールド。（５）最後に
ファイルを受領した日付と今回のファイル受領の日付の
間の日数を保持する「最後の受領以降の日数」ファイ
ル。

【００４８】新たなログ・ファイルが受領されて処理さ
れたときに、データ・プリプロセッサによって「ログ受
領履歴テーブル」に新規レコードが追加される。「ログ
受領履歴テーブル」のレコードは、一旦追加されたら変
更も除去もされない。

【００４９】本発明の好適実施形態によれば、運用サー
バ（図２の２２）は、「ログ受領履歴テーブル」のデー
タを検査して、特定のスキャナから最も最近に受領した
データ・ファイルの受領日又は容量が、当該スキャナか
らの最近のデータ収集が不成功であった又は不完全であ
ったことを示すか否かを判定する定期的タスクを実行す
る。

【００５０】再び図２を参照して述べると、スキャナに
よるその運用データの送信が不成功又は不完全であった
場合には、運用サーバ２２は自動サポート・センタ１６
に対し、この特定のスキャナ２上でのデータ・ログ記録
の特徴及び先行的診断データ転送の特徴を初期化し直す
ように要求を送る。加えて、運用サーバ２２に組み入れ
られている「管理ツール」が、スキャナを初期化し直す
ように自動サポート・センタ１６に送られた各々の要求
毎に、日時及びスキャナの「システムＩＤ」を記録す
る。「管理ツール」はまた、適当なシステム管理者に、
識別されたスキャナからのデータ転送に不整合が生じた
ことを通知する。

【００５１】好適実施形態によれば、運用サーバはま
た、有効性のある契約を有する各々のスキャナのデータ
・ログ記録サービス状態を追跡するための「スキャナ状
態テーブル」との名称のデータベース・テーブルを保持
している。「スキャナ状態テーブル」には、将来の契約
は、該契約がカレントになるまでは一切含められない。
有効性のあるスキャナ利用状況リポート発行サービス契
約によってカバーされている各々のスキャナが「スキャ
ナ状態テーブル」に唯一の非停止（non-terminated）レ
コードを有する。図５は、スキャナ上でのデータ・ログ
記録プログラムのライフ・サイクルを示す。

【００５２】図５を参照して述べると、利用状況リポー
ト発行サービスを有するあらゆるスキャナは、そのサー
ビス・ライフ・サイクルにおいて次の境界日付を有す
る。「スキャナ始動スイープ」日は、自動サポート・セ
ンタ（図２の参照番号１６）がスキャナ上でのデータ・
ログ記録の特徴を始動させるスイープを実行する予定日
である。「スキャナ始動」日は、当該スキャナをカバー
する契約の開始日と同一でなければならない。「最初の
データ受領予測」日は、運用サーバ（図２の参照番号２
２）がスキャナから最初のログ・データ送信を受領する
ことが予測される日付である。「最後のデータ受領」日
は、運用サーバがスキャナからログ・データを受け取っ
た実際の最後の日である。「スキャナ停止スイープ」日
は、自動サポート・センタが、スキャナ上でのデータ・
ログ記録の特徴を停止させるスイープを実行する予定日
である。「スキャナ停止」日は、契約停止に続く猶予期
間の満了日と同じでなければならない。一旦、自動サポ
ート・センタの「スキャナ停止」スイープが成功した
ら、スキャナから受領されるログ・ファイルはなくな
る。

【００５３】利用状況リポート発行サービス契約によっ
てカバーされているあらゆるスキャナは、そのサービス
・ライフ・サイクルにおいて次の状態を有する。０（新
規）：スキャナは発効中のサービスを有さない、１（始
動中）：スキャナに対するサービスが始動されようとし
ている、２（作動中）：スキャナが発効中のサービスを
有する、３（停止中）：スキャナに対するサービスが停
止されようとしている、４（停止）：スキャナに対する
サービスが既に停止している。

【００５４】加えて、表２（付録参照）に示すように、
「契約テーブル」に次のデータ・フィールドが定義され
ており、スキャナ状態の境界日付の計算に用いられる。
「契約テーブル」のカレントの各々の契約毎に、「処理
日」フィールドが、運用サーバが最初に契約を処理した
日付を保持している。「契約テーブル」はまた、「契約
猶予期間終了日」フィールドを含む。サービスは、契約
終了日の直後に停止させなくてもよい。サービスは、所
定の猶予期間の間は発効したままにしておいてよい。
「契約テーブル」のカレントの各々の契約毎に、契約終
了日の後の所定の構成設定可能な時間として「猶予期間
終了日」フィールドが設定される。

【００５５】スキャナ状態の境界日付は、次のようにし
て算出される。「スイープ始動予定」日は、契約につい
ては「契約テーブル」の「処理日」及び「契約開始日」
のうち遅い方であり、スキャナについてはそのカレント
のすべての契約について最も早く予定された「スキャナ
始動」スイープ日となる。「最初のデータ受領予測」日
は最初は予定として設定され、後に、最初のデータを実
際に受領したときに更新される。「最後のデータ受領」
日は、「ログ受領履歴テーブル」に従ってスキャナにつ
いて最後のログ受領日として設定される。「スイープ停
止予定日」は、契約については「猶予期間終了日」であ
り、スキャナについてはそのカレントのすべての契約に
ついて最も遅い猶予期間終了日として設定される。「ス
キャナ状態テーブル」のあらゆるレコードは、表３（付
録参照）に定義されているようなデータ・フィールドを
有する。第１キーは「システムＩＤ」フィールドであ
る。

【００５６】運用サーバはまた、「スキャナ状態テーブ
ル」へのすべての挿入及び変更を記録する「スキャナ状
態監査テーブル」との名称のデータベース・テーブルを
保持している。スキャナ状態監査テーブルは好ましく
は、表３の第５フィールド（「最後の受領日」）を除く
すべてのフィールドの「：旧値」及び「：新規値」用の
フィールドを有している。また、監査レコードが挿入さ
れたときの日時スタンプのためのフィールドも有してい
る。挿入を追跡するために「スキャナ状態テーブル」に
「挿入トリガ」が設けられており、「スキャナ状態監査
テーブル」の「：新規値」フィールドに、挿入されたレ
コードを追加できるようにしている。変更を追跡するた
めには「スキャナ状態テーブル」に「変更トリガ」が設
けられており、「スキャナ状態監査テーブル」に、変更
されたレコードを「：旧値」及び「：新規値」について
追加できるようにしている。表３の「監査変更要否」の
欄に「要」とマークされたいずれかのフィールドが変更
されると、「スキャナ状態テーブル」は「変更トリガ」
を起動する。

【００５７】「スキャナ状態テーブル」は好ましくは、
「契約テーブル」が更新された後に毎日更新される。運
用サーバは、図６に示すように、「契約テーブル」から
のすべての「追加レコード」及び「変更レコード」を構
文解析することにより「スキャナ状態テーブル」を生成
する。このアルゴリズムは、「契約テーブル」から次の
「発効中の追加／変更レコード」を検索する（ステップ
７８）。ステップ８０において、アルゴリズムは、検索
されたレコードについて、「契約認知キー」フィールド
の値が０（カレントの契約であることを示す）であるか
１（将来の契約であることを示す）であるかを判定す
る。値が０に等しいならば、アルゴリズムは、処理され
ているレコードの「システムＩＤ」が「スキャナ状態テ
ーブル」に存在しているか否かを判定する（ステップ８
２）。「スキャナ状態テーブル」のレコード操作は、
「システムＩＤ」が「スキャナ状態テーブル」に存在し
ていない場合には新規レコードの追加（図６のステップ
８６）を、また「システムＩＤ」が「スキャナ状態テー
ブル」に存在しており且つエラーが存在していない場合
には既存のレコードの変更（図６のステップ８４）を含
んでいる。構文解析されているレコードのデータにエラ
ーが検出された場合には、エラー標識子が生成される
（ステップ８８）。アルゴリズムが、「契約テーブル」
ファイルからの最後の「追加／変更レコード」が構文解
析されたものと判定したら（図６の判定ブロック９
０）、アルゴリズムは終了する。アルゴリズムは、「契
約認知キー」の値が１に等しかった場合には、ステップ
８０からステップ９０へ直接進む。

【００５８】好適実施形態によれば、新規レコードは、
次に基づいて「スキャナ状態テーブル」に追加される。
（１）「システムＩＤ」の値が「契約テーブル」からの
レコードの「システムＩＤ」に従って設定される。
（２）「スイープ始動日」フィールドが、「契約テーブ
ル」からのレコードの「処理日」及び「契約開始日」の
うち遅い方に設定される。（３）「スイープ始動試行」
フィールドが、サービスを始動させようとするスイープ
試行の回数に設定される（既定値は０）。（４）「最初
の受領日」フィールドが、自動サポート・センタ（図２
の参照番号１６）が生成した先行的診断予定に従って設
定される。（５）「最後の受領日」フィールドの値はヌ
ルに設定される。（６）「スイープ停止日」フィールド
は、「契約テーブル」からのレコードの「契約猶予期間
終了日」に設定される。（７）「スイープ停止試行」フ
ィールドは０に設定される。（８）「契約テーブル」の
レコードの「包括範囲（room）状態」フィールドが値９
Ｘを有している場合には、「状態」フィールドの値は４
（停止）に設定される。他の場合には、値は０（新規）
に設定される。

【００５９】「スキャナ状態テーブル」の既存のレコー
ドは、次のようにして修正される。（１）「システムＩ
Ｄ」の値は変更されない。（２）「カレントの状態」フ
ィールドが値０（新規）を有する場合には、「スイープ
始動日」の値は、カレントの値と、「契約テーブル」か
らのレコードから導出される契約で予定されているスイ
ープ始動の日付とのうち近い方に変更される。「カレン
トの状態」フィールドが０（新規）以外の値を有する場
合には、値は変更されない。（３）「スイープ始動試
行」フィールドの値は変更されない。（４）「最初の受
領日」フィールドは、自動サポート・センタが生成した
先行的診断予定に従って変更される。（５）「最後の受
領日」フィールドの値は変更されない。（６）「スイー
プ停止日」フィールドの値は、カレントの値と「契約テ
ーブル」からのレコードの「契約猶予期間終了日」との
うち遅い方に変更される。（７）「スイープ停止試行」
フィールドは変更されない。（８）「契約テーブル」の
レコードの「包括範囲状態」フィールドが値９Ｘを有す
る場合には、「状態」フィールドの値は４（停止）に設
定される。他の場合には、値は変更されない。

【００６０】本発明の好適実施形態によれば、すべての
スキャナの状態は、「スキャナ状態テーブル」が「契約
テーブル」に基づいて更新された後に毎日更新される。
運用サーバは、図７に示すアルゴリズムを用いて「スキ
ャナ状態テーブル」のすべてのスキャナ・レコードの状
態を更新する。このアルゴリズムは、「スキャナ状態テ
ーブル」において次のレコードを検索する（ステップ９
２）。ステップ９４において、「ログ受領履歴テーブ
ル」に基づいて「最後の受領日」フィールドが更新され
る。ステップ９６において、アルゴリズムは、処理され
ているレコードの「状態」フィールドのカレントの値を
判定する。

【００６１】「状態」フィールドが値０（新規）を有す
る場合には、アルゴリズムは、この日が「スキャナ始動
スイープ」日として予定されているか否かを判定する
（ステップ１００）。「イエス」であるならば、スキャ
ナ状態を０から１へ変更して（ステップ１０２）、「ス
イープ始動試行」フィールドの値を１だけインクリメン
トする。他のすべてのフィールドの値は変更しない。次
いで、運用サーバ（図２の参照番号２２）は自動サポー
ト・センタ（図２の参照番号１６）へ電子メールを送っ
て、スキャナ上でのデータ・ログ記録の特徴及び先行的
診断データ転送を遠隔からイネーブルにするように自動
サポート・センタに要求する。次いで、アルゴリズム
は、処理されているレコードが「スキャナ状態テーブ
ル」の最後のレコードであるか否かを判定する（ステッ
プ１１４）。「ノー」であるならば、アルゴリズムは直
接ステップ１１４に進む。直前に処理されたレコードが
最後のレコードであれば、アルゴリズムは終了する。最
後のレコードでなければ、アルゴリズムはステップ９２
に戻って次のレコードを処理する。

【００６２】「状態」フィールドが値１（始動中）を有
する場合には、アルゴリズムは「最後の受領日」がヌル
であるか否かを判定し（ステップ９８）、「スキャナ始
動スイープ」日として今日が予定されているか否かを判
定する（ステップ１００）。「イエス」であるならば、
アルゴリズムはステップ１１４へ進む。「ノー」である
ならば、ステップ１１４に進む前にスキャナ状態を１か
ら２へ変更する（ステップ１０４）。

【００６３】「状態」フィールドが値２（作動中）を有
する場合には、アルゴリズムはこの日が「スキャナ停止
スイープ」日として予定されているか否かを判定する
（ステップ１０６）。「イエス」であるならば、スキャ
ナ状態を２から３へ変更し（ステップ１１２）、「スイ
ープ停止試行」フィールドの値を１だけインクリメント
する。他のすべてのフィールドの値は変更しない。次い
で、運用サーバ（図２の参照番号２２）は自動サポート
・センタ（図２の参照番号１６）へ電子メールを送っ
て、スキャナ上でのデータ・ログ記録の特徴及び先行的
診断データ転送を遠隔からディスエーブルにするように
自動サポート・センタに要求する。次いで、アルゴリズ
ムはステップ１１４へ進む。「ノー」であるならば、ア
ルゴリズムは直接ステップ１１４へ進む。

【００６４】「状態」フィールドが値３（停止中）を有
する場合には、アルゴリズムはこの日が「最後の受領
日」のＸ日後であるか否かを判定する（ステップ１０
８）。「イエス」であるならば、アルゴリズムはステッ
プ１１４へ進む。Ｘの値は構成設定が可能である。「イ
エス」であるならば、ステップ１１４へ進む前にスキャ
ナ状態を３から４へ変更する（ステップ１１０）。「ノ
ー」であるならば、アルゴリズムは直接ステップ１１４
へ進む。

【００６５】データ・プリプロセッサ（図２に示す運用
サーバ２２に組み込まれている）は、自動サポート・セ
ンタにスキャナ・データが送られた後に、スキャナ・デ
ータの初期処理を行なう。この初期処理（図８に示す）
は、新たなスキャナ・ファイルを定期的に点検すると共
に収集し（ステップ１１６）、ファイルが由来したスキ
ャナの形式を識別し、スキャナ・ファイルのフィールド
を検証し（ステップ１１８）、ＣＰＴコードを生成し
（ステップ１２０）、スキャナ・ファイルをＸＭＬフォ
ーマットへ変換し（ステップ１２２）、ファイルを作成
サーバへ転送することから成っている。データ・プリプ
ロセッサの動作履歴は、どのスキャナ・ファイルを処理
したか、いつ処理したか、処理にはどれ位の時間がかか
ったか、及び処理に関連するエラーがあればそのエラー
を含んでおり、ウェブ配布フォーマットでシステム管理
者が利用することが可能になっている。いずれかのスキ
ャナがファイルを送るべきときに送ってこなかったり、
処理エラーに遭遇した場合には、データ・プリプロセッ
サはシステム管理者へ通知する。

【００６６】データ・プリプロセッサは、新たなスキャ
ナ・ファイルが自動サポート・センタから到着したとき
を自動的に検出し、次いで、これらのファイルの有効性
を自動的に確認する（図８のステップ１１８）。ファイ
ルによっては、圧縮を解凍する必要がある場合もある。
データ・プリプロセッサは、ファイルの「文法」（例え
ばＭＲ又はＣＴ）を識別して、不明の文法があればエラ
ーとしてログ記録する。データ・プリプロセッサはま
た、レコード内に、問題となっているサービスを提供す
るのに必要とされるすべてのフィールドが正しい形式で
正しい範囲に存在していることを検証する。データ・プ
リプロセッサは可能な限り多くの生のスキャナ・ファイ
ルを保存しようとする。レコードが完全でなければ（す
なわち欠落したフィールドを有しているならば）、レコ
ードをログ記録して削除する。削除したレコードが他の
レコードを包含するレベルにある場合には、当該レコー
ドが包含するレコードも削除する（例えば、検査レコー
ドを削除すると、次の検査レコードまでのすべての後続
レコードが削除される）。レコード内の検査又は系列番
号が重複している場合には、後続のレコードの番号を振
り直してこれを修正する。データ・プリプロセッサはま
た、参照ドキュメントに基づいてＣＰＴコードを生成す
る。

【００６７】データ・プリプロセッサは、その動作を監
視する（ステップ１２６）と共に記録して（ステップ１
２８）、これらの動作をシステム管理者へ報告する（ス
テップ１３０）。具体的には、データ・プリプロセッサ
は、スキャナ・ファイルが自動サポート・センタから受
領された日時、及びファイルのサイズを記録し（「ログ
受領履歴テーブル」へ）、スキャナ・ファイルが処理さ
れた開始及び終了の日時を記録し（これはシステムＩＤ
を介してアクセス可能でなければならない）、また、ス
キャナ・ファイルの処理に関連したあらゆるエラーを記
録する（やはりこれもシステムＩＤを介してアクセス可
能でなければならない）。加えて、データ・プリプロセ
ッサは、データ・ログ記録及びリポート生成についてイ
ネーブルになっているすべてのスキャナを定期的に点検
して（ステップ１２４）、これらのスキャナがデータを
送付していることを検証する。この点検を行なう割合
は、構成設定可能である。データ・プリプロセッサは、
エラー状態、又は動作していないスキャナがあれば、シ
ステム管理者へ通知する。また、データ・プリプロセッ
サは、作成サーバへ転送されてきたファイルの数をログ
記録している。データ・プリプロセッサは、処理済のＸ
ＭＬファイルを処理が完了すると直ちに圧縮した後に作
成サーバ（図２の参照番号２８）へ送付する。データ・
プリプロセッサは、１日１回、作成サーバ（図２の参照
番号２８）へ「転送ログ」ファイルを送付する。データ
・プリプロセッサは、処理されたファイル数、処理時間
統計及びエラー・ログ、すなわち日、週、月及び年当た
りに処理されたファイル、並びにファイルを処理した平
均時間、最短時間及び最長時間；すべてのシステムＩＤ
及び個々のシステムＩＤについてのスキャナ・ファイル
統計すなわちシステムＩＤ当たり及びすべてのシステム
ＩＤ当たりの受領時刻；システムＩＤ当たり及びすべて
のシステムＩＤ当たりのファイル・サイズ；並びにシス
テムＩＤがデータを発行すべき予測される日付を状態と
共に示す動的ＨＴＭＬリポートを発行する。

【００６８】本発明の更なる側面によれば、運用サーバ
は、事象ログ記録及びリポート発行を含むウェブ方式の
管理ツール機能を有するようにプログラムされる。「管
理ツール」は「ログ・ファイル」（必ずしもファイル構
造でなくてもよい）を保持して、次の各動作を記録す
る。「ＭＳＡ抽出出力ファイル」の取り出しに失敗した
ときの日時；受領した「ＭＳＡ抽出出力ファイル」の日
時及びファイル・サイズ；「ＭＳＡ抽出出力ファイル」
の構文解析されたレコードの日時及び総数；抽出アルゴ
リズム及び関連する契約テーブルにおける日時及びエラ
ー状態；「契約テーブル」の「新規レコード」の日時及
び数、「無変更レコード」の数、「変更レコード」の
数、「除去レコード」の数；「契約更新ファイル」の
「新規レコード」の日時、ファイル・サイズ、数、「変
更レコード」の数及び「除去レコード」の数；作成サー
バによって送付され又は検索された「契約更新ファイ
ル」の日時及びファイル・サイズ；「新規レコード」が
「スキャナ状態テーブル」に追加された日時；「スキャ
ナ状態テーブル」の「変更レコード」の日時、及び旧値
と新規値；並びにスキャナを始動又は停止させるために
自動サポート・センタへ送付された電子メール要求の日
時、スイープの型及びシステムＩＤ。

【００６９】加えて、「管理ツール」は要求に応じて異
なるリポートを発行する。例えば、「新規顧客追跡」リ
ポートは、新たな利用状況リポート発行サービス契約に
よってカバーされているが、作成モードにはまだなって
いないすべてのスキャナを含んでいる。「スキャナ状態
テーブル」から、状態０（新規）及び１（始動中）を有
するすべてのスキャナががこの一覧に含められる。一覧
に含められた各々のスキャナ毎に、リポートは次の情報
を有する。「顧客名」、「スキャナ・システムＩＤ」、
「契約開始日」、「サービス始動日」、「スイープ始動
試行回数」、「最初のデータ受領予測日」、「状態」及
び「補助」。このリポートの一覧に含められたすべての
スキャナについて、「スキャナ・システムＩＤ」、「サ
ービス始動日」、「スイープ始動試行回数」及び「最初
のデータ受領予測日」の情報は、「スキャナ状態テーブ
ル」の「システムＩＤ」、「スイープ始動日」、「スイ
ープ始動試行」、「最初の受領日」の各フィールドから
それぞれ検索される。

【００７０】「新規顧客追跡」リポートの一覧に含めら
れたすべてのスキャナについて、「顧客名」及び「契約
開始日」の情報は、「契約テーブル」の「顧客名」及び
「契約開始日」フィールドからそれぞれ検索される。
「契約テーブル」内で多数のスキャナ利用状況リポート
発行サービス契約によってカバーされているスキャナに
ついては、すべての「契約開始日」が検索されて一覧に
含められる。

【００７１】「新規顧客追跡リポート」の一覧に含めら
れた各々のスキャナは、次の状態のうち１つを有する。
（ａ）システム日付が「最初のデータ受領予測日」より
も前である場合には、スキャナは「緑」状態を有する。
（ｂ）システム日付が「最初のデータ受領予測日」から
２日後以内である場合には、スキャナは「黄」状態を有
する。（ｃ）システム日付が「最初のデータ受領予測
日」から少なくとも２日後である場合には、スキャナは
「赤」状態を有する。

【００７２】「補助」は、「状態」が「赤」であり、且
つ「スキャナ状態テーブル」からのスキャナの「カレン
トの状態」が１（始動中）である場合にのみ利用可能で
ある。運用サーバによって補助要求が発行されたとき
に、電子メールが自動サポート・センタへ送付されて、
データ・ログ記録の特徴及び先行的診断データ転送をこ
のスキャナに対して遠隔からイネーブルにするように要
求する。「スキャナ状態テーブル」では、このスキャナ
の「スイープ始動日」フィールドがシステム日付に再設
定される。「新規顧客追跡」リポートの「最初のデータ
受領予測日」は、予定されている「サービス始動日」か
ら所定の構成設定可能な期間後に再設定される。「スイ
ープ始動試行回数」は１だけインクリメントされる。
「スイープ始動試行回数」が２よりも大きくなったとき
には手動の介入が期待される。「新規顧客追跡」リポー
トは、リポートが要求されたときにデータベースへの問
い合わせを通じて実時間で生成される。

【００７３】「管理ツール」はまた、「満了顧客追跡」
リポートを生成することができる。この追跡は、満了す
る利用状況リポート発行サービス契約によってカバーさ
れているすべてのスキャナを含んでいる。この一覧は、
「スキャナ状態テーブル」から状態３（停止中）又は状
態２（作動中）を有するが契約猶予期間内にあるすべて
のスキャナを含んでいる。一覧に含められた各々のスキ
ャナについて、「満了顧客追跡」リポートは次の情報を
有する。「顧客名」、「スキャナ・システムＩＤ」、
「契約終了日」、「サービス停止日」、「スイープ停止
試行回数」、「最後のデータ受領日」、「状態」及び
「補助」。このリポートの一覧に含められたすべてのス
キャナについて、「スキャナ・システムＩＤ」、「サー
ビス停止日」、「スイープ停止試行回数」及び「最後の
データ受領日」の情報は、「スキャナ状態テーブル」の
「システムＩＤ」、「スイープ停止日」、「スイープ停
止試行」及び「最後の受領日」の各フィールドからそれ
ぞれ検索される。このリポートの一覧に含められたすべ
てのスキャナについて、「顧客名」及び「契約終了日」
の情報は、「契約テーブル」の「顧客名」及び「契約終
了日」の各フィールドからそれぞれ検索される。「契約
テーブル」内で多数のサービス契約を有するスキャナに
ついては、すべての「契約終了日」が検索されて一覧に
含められる。

【００７４】「満了顧客追跡」リポートの一覧に含めら
れた各々のスキャナは、次の状態のうち１つを有する。
（ａ）「最後のデータ受領日」が「サービス停止日」よ
りも前である場合には、スキャナは「緑」状態を有す
る。（ｂ）「最後のデータ受領日」が「サービス停止
日」から１週間後以内である場合には、スキャナは
「黄」状態を有する。（ｃ）「最後のデータ受領日」が
「サービス停止日」から１週間後を超えている場合に
は、スキャナは「赤」状態を有する。

【００７５】「補助」は、状態が「赤」であり、且つ
「スキャナ状態テーブル」からのスキャナの「カレント
の状態」が３（停止中）である場合にのみ利用可能であ
る。補助要求が発行されたときに、運用サーバによって
電子メールが自動サポート・センタへ送付されて、デー
タ・ログ記録の特徴及び先行的診断データ転送をこのス
キャナに対して遠隔からディスエーブルにするように要
求する。「スキャナ状態テーブル」では、このスキャナ
の「スイープ停止日」フィールドがシステム日付に再設
定される。「スイープ停止試行回数」は１だけインクリ
メントされる。「スイープ停止試行回数」が２よりも大
きくなったときには手動の介入が期待される。このリポ
ートもやはり、リポートが要求されたときにデータベー
スへの問い合わせを通じて実時間で生成される。

【００７６】「管理ツール」はまた、「発効中顧客追
跡」リポートを生成することができる。この追跡は、生
成モードにあるデータ・ログ記録を有するすべてのスキ
ャナを含んでいる。この一覧は、「スキャナ状態テーブ
ル」から状態２（作動中）を有するすべてのスキャナを
含んでいる。一覧に含められた各々のスキャナについ
て、「発効中顧客追跡」リポートは次の情報を有する。
「顧客名」、「スキャナ・システムＩＤ」、「始動
日」、「最後のデータ受領日」、「次のデータ予測
日」、「最後に受領したファイルのサイズ」及び「状
態」。このリポートの一覧に含められたあらゆるスキャ
ナについて、「スキャナ・システムＩＤ」、「最後のデ
ータ受領日」及び「最後に受領したファイルのサイズ」
の情報は、「ログ受領履歴テーブル」に含まれる「シス
テムＩＤ」フィールド、最新の「受領日時」及び最新の
受領の「ファイル・サイズ」から検索され又は導出され
る。「次のデータ予測日」は、自動サポート・センタの
先行的診断予定に従って設定される。このリポートの一
覧に含められたあらゆるスキャナについて、「始動日」
情報は、「スキャナ状態テーブル」の「スイープ始動
日」フィールドから検索され、「顧客名」情報は、「契
約テーブル」の「顧客名」フィールドから検索される。

【００７７】「発効中顧客追跡」リポートの一覧に含め
られた各々のスキャナは、次の状態のうち１つを有す
る。（ａ）システム日付が「次のデータ予測日」よりも
前であり、且つ「最後に受領したファイルのサイズ」が
１５キロバイトよりも大きい場合には、スキャナは
「緑」状態を有する。（ｂ）システム日付が「次のデー
タ予測日」から２日後以内であるか、又は「最後に受領
したファイルのサイズ」が５キロバイトと１５キロバイ
トとの間にある場合には、スキャナは「黄」状態を有す
る。（ｃ）システム日付が「次のデータ予測日」から２
日後を超えているか、又は「最後に受領したファイルの
サイズ」が５Ｋよりも小さい場合には、スキャナは
「赤」状態を有する。「発効中顧客追跡」リポートは、
リポートが要求されたときにデータベースへの問い合わ
せを通じて実時間で生成される。

【００７８】「管理ツール」はまた、「ログ・データ履
歴」リポートを生成することができる。この追跡は、利
用状況リポート発行サービス契約によってカバーされて
いたことのあるすべてのスキャナを含んでいる。この一
覧は、「スキャナ状態テーブル」から状態０（新規）、
１（始動中）、２（作動中）、３（停止中）及び４（停
止）を有するすべてのスキャナを含んでいる。一覧に含
められた各々のスキャナについて、「ログ・データ履
歴」リポートは次の情報を有する。「顧客名」、「スキ
ャナ・システムＩＤ」、「始動日」、「受領ファイル
数」、「平均ファイル・サイズ」、「データ受領間の平
均日数」、「カレントの状態」及び「詳細」。このリポ
ートの一覧に含められたあらゆるスキャナについて、
「スキャナ・システムＩＤ」、「受領ファイル数」、
「平均ファイル・サイズ」及び「データ受領間の平均日
数」の情報は、「ログ受領履歴テーブル」に含まれてい
る「システムＩＤ」フィールド、この「システムＩＤ」
を有するレコード数、「ファイル・サイズ」の平均、
「最後の受領以降の日数」の平均からそれぞれ検索され
又は導出される。このリポートの一覧に含められたあら
ゆるスキャナについて、「始動日」及び「カレントの状
態」の情報は、「スキャナ状態テーブル」の「スイープ
始動日」フィールド及び「状態」フィールド（新規、始
動中、作動中、停止中又は停止）から検索され、「顧客
名」情報は、「契約テーブル」の「顧客名」フィールド
から検索される。このリポートは、リポートが要求され
たときにデータベースへの問い合わせを通じて実時間で
生成される。

【００７９】本発明は、医用撮像装置における運用デー
タ・ログ記録の自動的な作動開始及び作動停止での応用
に限定されている訳ではない。本書に開示した自動的手
法を、利用者が運用する他の形式の電子装置から中央サ
ービス施設への運用データのログ記録及び転送を作動開
始及び作動停止させるために用いることもできる。

【００８０】好適実施形態を参照して本発明を説明した
が、当業者であれば、本発明の範囲から逸脱せずに様々
な変形を施し、また好適実施形態の構成要素を均等構成
で置き換え得ることが理解されよう。加えて、本発明の
本質的な範囲から逸脱せずに、本発明の教示に合わせて
具体的な状況を適応構成するような多くの改変を施して
もよい。従って、本発明は、本発明を実施するのに想到
される最良の態様として開示された特定の実施形態に限
定されている訳ではなく、特許請求の範囲内に含まれる
すべての実施形態を包含しているものとする。

【００８１】特許請求の範囲で用いる場合には、「コン
ピュータ・システム」という用語は、単一のコンピュー
タ、サーバ若しくはデータ・プロセッサ、又は相互接続
された複数のコンピュータ、サーバ若しくはデータ・プ
ロセッサの群を包含するように広い意味で用いられてい
る。当業者であれば容易に理解されるように、２つのデ
ータ処理機能を別個のコンピュータ若しくはサーバ上で
別個のソフトウェア・モジュール若しくはコンピュータ
・プログラムとして具現化してもよいし、又は同じコン
ピュータ若しくはサーバ上で別個のソフトウェア・モジ
ュール若しくはコンピュータ・プログラムとして具現化
してもよい。特許請求の範囲で用いる場合には、「デー
タベースにレコードを追加する」との文言は、新たなレ
コードを導入すること、及び既存のレコードのフィール
ド値を新たなレコードに一致するように変更することの
両方を包含するものとする。

【００８２】

【表１】

【００８３】

【表２】

【００８４】

【表３】

【００８５】

【表４】

【００８６】

【表５】

【図面の簡単な説明】

【図１】本発明の好適実施形態による遠隔配置されたス
キャナからの運用データの流れ及び処理を示す線図であ
る。

【図２】本発明の好適実施形態によるシステムの設計構
成要素の相互作用を示すブロック図である。

【図３】本発明の好適実施形態による顧客プロフィール
・データ、契約データ及びスキャナ状態データの流れを
示す線図である。

【図４Ａ】本発明の好適実施形態に従ってそれぞれの
「契約テーブル」を生成するために各々の「抽出出力フ
ァイル」のレコードに対して運用サーバによって実行さ
れる構文解析動作を示す流れ図の一部である。

【図４Ｂ】本発明の好適実施形態に従ってそれぞれの
「契約テーブル」を生成するために各々の「抽出出力フ
ァイル」のレコードに対して運用サーバによって実行さ
れる構文解析動作を示す流れ図の残部である。

【図５】本発明の好適実施形態による遠隔スキャナのた
めのデータ・ログ記録プログラムのライフ・サイクルを
示す時間線の図である。

【図６】本発明の好適実施形態に従って「契約テーブ
ル」の「追加／変更レコード」から「スキャナ状態テー
ブル」を生成する方法の工程を示す流れ図である。

【図７Ａ】本発明の好適実施形態に従って「スキャナ状
態テーブル」に記録されているスキャナの状態を更新す
る方法の工程を示す流れ図の一部である。

【図７Ｂ】本発明の好適実施形態に従って「スキャナ状
態テーブル」に記録されているスキャナの状態を更新す
る方法の工程を示す流れ図の残部である。

【図８】本発明の好適実施形態によるデータ・プリプロ
セッサのスキャナ運用データの流れ及び処理を示す線図
である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ローレンス・エドワード・プローツ アメリカ合衆国、ウィスコンシン州、ブル ックフィールド、ウィロウ・リッジ・レー ン、16820番 (72)発明者 ジー・シュー アメリカ合衆国、ウィスコンシン州、ワー ケシャー、ナンバー59、スワルツ・ドライ ブ、1604番

Claims (28)

【特許請求の範囲】
1. 【請求項１】 それぞれの遠隔位置に設けられている多
   数の装置（２）であって、該装置の各々が識別可能であ
   り、また、データ・ログ記録機能が作動開始したときに
   は運用データをログ記録することが可能であり、前記デ
   ータ・ログ記録機能が作動停止したときには運用データ
   をログ記録することが不能になる多数の装置（２）と、 該多数の装置と連絡している中央位置に設けられている
   コンピュータ・システム（１６、２２）であって、その
   データ・ログ記録機能の状態に変更を要する装置を識別
   するレコードを含む更新されたデータベースを記憶して
   おり、前記識別された装置の前記データ・ログ記録機能
   を、前記作動開始した状態及び作動停止した状態の一方
   から前記作動開始した状態及び作動停止した状態の他方
   へ遠隔から変更する工程を実行するようにプログラムさ
   れているコンピュータ・システム（１６、２２）と、を
   備えたシステム。
2. 【請求項２】 前記コンピュータ・システムは、前記更
   新されたデータベースを保持している運用サーバ（２
   ２）と、該運用サーバからの要求に応答して、前記識別
   された装置の前記データ・ログ記録機能の状態を遠隔か
   ら変更する自動サポート・センタ・サーバ（１６）とを
   含んでいる請求項１に記載のシステム。
3. 【請求項３】 前記更新されたデータベースは、顧客プ
   ロフィール情報及びサービス契約情報を含んでいる請求
   項１に記載のシステム。
4. 【請求項４】 前記コンピュータ・システムは、新たな
   データベースのレコードと古いデータベースのレコード
   とを比較して、前記古いデータベースにおけるすべての
   データ・フィールドと完全な一致を有さない前記新たな
   データベースにおけるレコードを識別する比較する工程
   と、前記古いデータベースに前記識別されたレコードを
   追加して前記更新されたデータベースを形成する追加す
   る工程とを実行するようにさらにプログラムされている
   請求項１に記載のシステム。
5. 【請求項５】 前記比較する工程は、前記新たなデータ
   ベースのレコードと前記古いデータベースのレコードと
   を比較して、前記古いデータベースの如何なるレコード
   にも現われないサービス契約番号又は装置識別子を有す
   る前記新たなデータベースのレコードを識別する工程を
   含んでおり、前記変更する工程は前記データ・ログ記録
   機能を作動停止させることを含んでいる請求項４に記載
   のシステム。
6. 【請求項６】 前記比較する工程は、前記新たなデータ
   ベースのレコードと前記古いデータベースのレコードと
   を比較して、同じサービス契約番号及び同じ装置識別子
   を有するが、契約状態フィールドにおいて既存のサービ
   ス契約の更新を示す異なるデータを有する前記新たなデ
   ータベースのレコード及び前記古いデータベースのレコ
   ードを識別する工程を含んでおり、前記変更する工程は
   前記データ・ログ記録機能を作動開始させることを含ん
   でいる請求項４に記載のシステム。
7. 【請求項７】 前記比較する工程は、前記新たなデータ
   ベースのレコードと前記古いデータベースのレコードと
   を比較して、同じサービス契約番号及び同じ装置識別子
   を有するが、契約状態フィールドにおいて将来のサービ
   ス契約の時期が到来したことを示す異なるデータを有す
   る前記新たなデータベースのレコード及び前記古いデー
   タベースのレコードを識別する工程を含んでおり、前記
   変更する工程は前記データ・ログ記録機能を作動開始さ
   せることを含んでいる請求項４に記載のシステム。
8. 【請求項８】 前記比較する工程は、前記新たなデータ
   ベースのレコードと前記古いデータベースのレコードと
   を比較して、前記新たなデータベースに現われない前記
   古いデータベースのレコードを識別する工程を含んでお
   り、前記変更する工程は前記データ・ログ記録機能を作
   動停止させることを含んでいる請求項４に記載のシステ
   ム。
9. 【請求項９】 前記コンピュータ・システムは、監査レ
   コードから成る契約監査データベース・テーブルを保持
   するようにさらにプログラムされており、前記監査レコ
   ードの各々が、前記更新されたデータベースの挿入され
   た値又は変更された値を示すフィールドと、前記契約監
   査データベース・テーブルに監査レコードが挿入された
   ときを示す日時スタンプを含むフィールドとを含んでい
   る請求項４に記載のシステム。
10. 【請求項１０】 前記コンピュータ・システムは、前記
    更新されたデータベースに追加されるレコードを含む契
    約更新ファイルを出力するようにさらにプログラムされ
    ている請求項４に記載のシステム。
11. 【請求項１１】 前記コンピュータ・システムは、有効
    性のあるサービス契約によりカバーされておりデータ・
    ログ記録機能を要求する各々の装置についてそれぞれの
    レコードを含む装置状態データベース・テーブルを保持
    するようにさらにプログラムされており、各々のレコー
    ドが、前記データ・ログ記録機能を始動させる第一の予
    定日と前記データ・ログ記録機能を停止させる第二の予
    定日とを含んでいる請求項４に記載のシステム。
12. 【請求項１２】 前記コンピュータ・システムは、監査
    レコードから成る装置状態監査データベース・テーブル
    を保持するようにさらにプログラムされており、各々の
    監査レコードが、前記装置状態データベース・テーブル
    の挿入された値又は変更された値を示すフィールドと、
    前記装置状態監査データベース・テーブルに監査レコー
    ドが挿入されたときを示す日時スタンプを含むフィール
    ドとを含んでいる請求項１１に記載のシステム。
13. 【請求項１３】 前記コンピュータ・システムは、１日
    単位で、前記装置状態データベース・テーブルにおいて
    識別されるすべてのスキャナの状態を更新するようにさ
    らにプログラムされている請求項１１に記載のシステ
    ム。
14. 【請求項１４】 前記コンピュータ・システムは、前記
    装置状態データベース・テーブルから抽出された情報を
    含むリポートを生成するようにさらにプログラムされて
    いる請求項１１に記載のシステム。
15. 【請求項１５】 前記運用サーバは、前記自動サポート
    ・センタ・サーバに送られた各々の要求の日時及び該要
    求に関する装置識別子をログ記録するようにさらにプロ
    グラムされている請求項２に記載のシステム。
16. 【請求項１６】 通信チャネル（１８）を介して多数の
    遠隔配置されている装置（２）に接続されている自動中
    央サービス施設（１６、２２）を備えたシステムであっ
    て、 各々の装置は、該装置に記憶されているデータ・ログ記
    録プログラムが作動開始しているときには該データ・ロ
    グ記録プログラムに従って運用データをログ記録するよ
    うにプログラムされており、 前記中央サービス施設は、前記データ・ログ記録プログ
    ラムを作動開始させるべきであるとの情報の取得に応答
    して、装置においてデータ・ログ記録プログラムを遠隔
    から作動開始させる手段と、前記作動開始したデータ・
    ログ記録プログラムに従って前記装置から運用データの
    ログ・ファイルを受領する手段とを含んでいる、システ
    ム。
17. 【請求項１７】 前記中央サービス施設は、 データ・ログ記録機能を要求するサービス契約により現
    在カバーされているすべての装置を識別するのに十分な
    更新された顧客プロフィール情報及びサービス契約情報
    を含む新たなデータベースと、 データ・ログ記録機能を要求するサービス契約により以
    前にカバーされていたすべての装置を識別するのに十分
    な古い顧客プロフィール情報及びサービス契約情報を含
    む古いデータベースと、 作動開始を要求する装置を識別するために前記新たなデ
    ータベースと前記古いデータベースとを比較する手段
    （２２）と、をさらに含んでいる請求項１６に記載のシ
    ステム。
18. 【請求項１８】 通信チャネル（１８）を介して多数の
    遠隔配置されている装置（２）に接続されている自動中
    央サービス施設（１６、２２）を備えたシステムであっ
    て、 各々の装置は、該装置に記憶されているデータ・ログ記
    録プログラムが作動開始しているときには該データ・ロ
    グ記録プログラムに従って運用データをログ記録するよ
    うにプログラムされており、 前記中央サービス施設は、当該データ・ログ記録プログ
    ラムを作動停止させるべきであるとの情報の取得に応答
    して、装置においてデータ・ログ記録プログラムを遠隔
    から作動停止させる手段を含んでいる、システム。
19. 【請求項１９】 前記中央サービス施設は、 データ・ログ記録機能を要求するサービス契約により現
    在カバーされているすべての装置を識別するのに十分な
    更新された顧客プロフィール情報及びサービス契約情報
    を含む新たなデータベースと、 データ・ログ記録機能を要求するサービス契約により以
    前にカバーされていたすべての装置を識別するのに十分
    な古い顧客プロフィール情報及びサービス契約情報を含
    む古いデータベースと、 作動停止を要求する装置を識別するために前記新たなデ
    ータベースと前記古いデータベースとを比較する手段
    （２２）と、をさらに含んでいる請求項１８に記載のシ
    ステム。
20. 【請求項２０】 装置において運用データの自動的なロ
    グ記録を遠隔から作動開始させる方法であって、 運用データを記録し、データ・ログ記録機能が作動開始
    したときに該データ・ログ記録機能に従って、記憶され
    ている運用データを含むログ・ファイルを通信チャネル
    を介して中央位置へ定期的に送るように装置をプログラ
    ムする工程と、 前記データ・ログ記録機能を作動開始させるべきである
    と判定する工程と、 該判定する工程に応答して、前記通信チャネルを介して
    前記中央位置から前記装置において前記データ・ログ記
    録機能を作動開始させる工程と、を含んでいる方法。
21. 【請求項２１】 データ・ログ記録機能を要求するサー
    ビス契約により現在カバーされているすべての装置を識
    別するのに十分な更新された顧客プロフィール情報及び
    サービス契約情報を含む新たなデータベースを導入する
    工程と、 データ・ログ記録機能を要求するサービス契約により以
    前にカバーされていたすべての装置を識別するのに十分
    な古い顧客プロフィール情報及びサービス契約情報を含
    む古いデータベースを検索する工程とをさらに含んでお
    り、 前記判定する工程は、前記新たなデータベースのレコー
    ドと前記古いデータベースのレコードとを比較する工程
    を含んでいる請求項２０に記載の方法。
22. 【請求項２２】 前記比較する工程は、前記古いデータ
    ベースの如何なるレコードにも現われないサービス契約
    番号又は装置識別子を有する前記新たなデータベースの
    レコードを識別する工程を含んでいる請求項２１に記載
    の方法。
23. 【請求項２３】 前記比較する工程は、同じサービス契
    約番号及び同じ装置識別子を有するが、契約状態フィー
    ルドにおいて既存のサービス契約の更新を示す異なるデ
    ータを有する前記新たなデータベースのレコード及び前
    記古いデータベースのレコードを識別する工程を含んで
    いる請求項２１に記載の方法。
24. 【請求項２４】 前記比較する工程は、同じサービス契
    約番号及び同じ装置識別子を有するが、契約状態フィー
    ルドにおいて将来のサービス契約の時期が到来したこと
    を示す異なるデータを有する前記新たなデータベースの
    レコード及び前記古いデータベースのレコードを識別す
    る工程を含んでいる請求項２１に記載の方法。
25. 【請求項２５】 前記中央位置でのログ・ファイルの受
    領を監視して、作動開始の後から所定の時間内に、前記
    作動開始した装置からログ・ファイルを受領したことを
    確証する工程をさらに含んでいる請求項２０に記載の方
    法。
26. 【請求項２６】 装置において運用データの自動的なロ
    グ記録を遠隔から作動停止させる方法であって、 運用データを記録し、データ・ログ記録機能が作動開始
    したときに該データ・ログ記録機能に従って、記憶され
    ている運用データを含むログ・ファイルを通信チャネル
    を介して中央位置へ定期的に送るように装置をプログラ
    ムする工程と、 前記データ・ログ記録機能を作動停止させるべきである
    と判定する工程と、 該判定する工程に応答して、前記通信チャネルを介して
    前記中央位置から前記装置において前記データ・ログ記
    録機能を作動停止させる工程と、を含んでいる方法。
27. 【請求項２７】 データ・ログ記録機能を要求するサー
    ビス契約により現在カバーされているすべての装置を識
    別するのに十分な更新された顧客プロフィール情報及び
    サービス契約情報を含む新たなデータベースを導入する
    工程と、 データ・ログ記録機能を要求するサービス契約により以
    前にカバーされていたすべての装置を識別するのに十分
    な古い顧客プロフィール情報及びサービス契約情報を含
    む古いデータベースを検索する工程とをさらに含んでお
    り、 前記判定する工程は、前記新たなデータベースのレコー
    ドと前記古いデータベースのレコードとを比較する工程
    を含んでいる請求項２６に記載の方法。
28. 【請求項２８】 前記比較する工程は、前記新たなデー
    タベースに現われない前記古いデータベースのレコード
    を識別する工程を含んでいる請求項２７に記載の方法。