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

Abstract

(57)【要約】 【課題】 中央サービス施設（１６、２２）によって、
遠隔配置された多数の医用イメージング・システム
（２）からの運用データの定期的な収集を監視し、運用
データの収集が、データ源から受領したデータの受領頻
度及び容量に基づいて履歴的基準値から逸脱している場
合には修正処置過程を開始する方法及びシステムを提供
する。 【解決手段】 このシステムは、最も最近の受領時のデ
ータの量又は最も最近の２回のデータ受領の間の時間の
いずれかが、対策的処置を要求するような方式で変化し
たときをスキャナ単位で自動的に判定する。具体的に
は、データの容量又は受領間の時間が履歴的平均から所
定の百分率だけ逸脱していた場合には修正処置を講じ
る。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

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

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

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

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

【００１０】中央サービス施設に収集され記憶されてい
る運用データが不完全であると、顧客が要求したあらゆ
るレポートは、当然のことながらこの不完全なデータに
依存した結果を有しているため不正確になり、誤解を与
える虞がある。従って、データ収集を自動的に監視し
て、データが医用撮像装置から適正に収集されていない
場合には修正処置を講じることのできるような系統的な
方法が必要とされている。

【００１１】

【発明の概要】本発明は、遠隔配置された多数の医用イ
メージング・システムからの運用データの定期的な収集
を中央サービス施設によって監視し、運用データの収集
が、データ源から受領されるデータの受領頻度及び容量
に基づいて履歴的基準値から逸脱している場合には修正
処置過程を開始する方法及びシステムを指向している。
このシステムは、最も最近の受領時のデータの量又は最
も最近の２回のデータ受領の間の時間のいずれかが、対
策的処置を要求するような方式で変化したときをスキャ
ナ単位で自動的に判定する。

【００１２】本発明の好適実施形態によれば、中央サー
ビス施設のコンピュータが医用撮像装置から運用データ
を受領する度毎に、データを受領した時刻及び受領した
データの量をデータベースに記憶する。本書では、この
データベースを「ログ受領履歴テーブル」と呼ぶ。定期
的タスクがこのデータベースを検査して、特定のスキャ
ナから最も最近に受領したデータ・ファイルの受領日付
又は容量が、当該スキャナからの最近のデータ収集が不
成功又は不完全であったことを示しているか否かを判定
する。一つの好適実施形態によれば、この定期的タスク
は、当該スキャナからのデータ・サイズの履歴的平均
と、当該スキャナから最も最近に受領したデータ・ファ
イルのサイズとが、所定の量を超えて、例えば所定の百
分率を超えて異なっているか否かを判定する。もう一つ
の好適実施形態では、定期的タスクは、当該スキャナか
らの連続したデータ受領の間の履歴的平均時間と、当該
スキャナから最も最近に受領した２つのデータ・ファイ
ルの間の時間とが、所定の量を超えて、例えば所定の百
分率を超えて異なっているか否かを判定する。さらなる
好適実施形態によれば、定期的タスクは、最も最近に受
領したデータ・ファイルのデータ容量を履歴的平均デー
タ容量と比較すること、及び最も最近に受領した２つの
データ・ファイルの間の時間間隔をデータ受領の間の履
歴的平均時間と比較することの両方を行なう。スキャナ
の運用データのスキャナによる送信が不適当又は不完全
であることを示すような履歴的平均からの逸脱が生じて
いた場合には、中央サービス施設のコンピュータが、遠
隔配置されたスキャナを自動的に初期化し直してデータ
を送らせると共に、適当なシステム管理者に通知する。

【００１３】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００４４】一つの好適実施形態によれば、この定期的
タスクは、スキャナ単位で運用データ・ファイルの履歴
的平均（すなわち相加平均）サイズを計算して（但し、
各々のスキャナについて最も最近に受領したデータ・フ
ァイルは除いて）、次いで、各々のスキャナからのデー
タ・サイズの履歴的平均と、当該スキャナから最も最近
に受領したデータ・ファイルのサイズとが所定の量、例
えば所定の百分率を超えて（例えば、１０％を超えて）
異なっているか否かを判定する。ログ・ファイルのサイ
ズは、「ログ受領履歴テーブル」の「ファイル・サイ
ズ」フィールドから検索される。スキャナ単位での平均
ファイル・サイズは、運用サーバに組み入れられている
「管理ツール」によって「ログ・データ履歴」（後述）
に含められている。

【００４５】もう一つの好適実施形態によれば、定期的
タスクは、スキャナ単位で連続するデータ受領の間の履
歴的平均時間（例えば、日数）を計算して（但し、最も
最近に受領したデータ・ファイルは除いて）、次いで、
各々のスキャナについての連続するデータ受領の間の履
歴的平均時間が、当該スキャナから最も最近に受領した
データ・ファイルと前回のデータファイルとの間の時間
（例えば、日数）と所定の量、例えば所定の百分率を超
えて（例えば、１０％を超えて）異なっているか否かを
判定する。連続するデータ・ファイル受領の間の日数
は、「ログ受領履歴テーブル」の「最後の受領以降の日
数」フィールドから検索される。スキャナ単位での連続
するデータ受領の間の平均日数は、前述の「ログ・デー
タ履歴」に含められている。

【００４６】本発明の最も好ましい実施形態によれば、
運用サーバは、上述の定期的タスクの両方を実行する。
すなわち、運用サーバは、最も最近に受領したデータ・
ファイルのデータ容量を履歴的平均データ容量と比較す
ると共に、２つの最も最近に受領したデータ・ファイル
の間の時間間隔をデータ受領の間の履歴的平均時間と比
較する。これらのパラメータのいずれか一方に逸脱があ
ると、以下に述べる修正処置が起動される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００７８】特許請求の範囲で用いる場合には、「コン
ピュータ・システム」という用語は、単一のコンピュー
タ、サーバ若しくはデータ・プロセッサ、又は相互接続
された複数のコンピュータ、サーバ若しくはデータ・プ
ロセッサの群を包含するように広い意味で用いられてい
る。当業者であれば容易に理解されるように、２つのデ
ータ処理機能を別個のコンピュータ若しくはサーバ上で
別個のソフトウェア・モジュール若しくはコンピュータ
・プログラムとして具現化してもよいし、又は同じコン
ピュータ若しくはサーバ上で別個のソフトウェア・モジ
ュール若しくはコンピュータ・プログラムとして具現化
してもよい。特許請求の範囲で用いる場合には、「入来
ログ・ファイル」という用語は、最も最近に受領された
運用データ・ログ・ファイルを意味するものとする。

【００７９】

【表１】

【００８０】

【表２】

【００８１】

【表３】

【００８２】

【表４】

【００８３】

【表５】

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ナジャ・エス・ロビンソン アメリカ合衆国、ウィスコンシン州、メノ モニー・フォールズ、リンデン・レーン、 ダブリュー170・エヌ4953番 Ｆターム(参考） 5K048 AA05 BA34 DA02 DC04 DC07 EB10 FC01 HA01

Claims (37)

【特許請求の範囲】
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. 【請求項２８】 前記監視する工程は、 前記装置から受領した各々の入来ログ・ファイルとその
    先行するログ・ファイルとの間の日数を記憶する工程
    と、 前記装置から受領したログ・ファイルの履歴的系列にお
    いて連続するログ・ファイルの間の履歴的平均日数を算
    出する工程と、 前記装置から受領した各々の入来ログ・ファイルとその
    次に先行するログ・ファイルとの間の日数が、前記履歴
    的平均日数から少なくとも所定の量だけ逸脱しているか
    否かを判定する工程と、を含んでいる請求項２７に記載
    の方法。
29. 【請求項２９】 前記特性は、前記装置から受領した各
    々の入来ログ・ファイルのサイズである請求項２４に記
    載の方法。
30. 【請求項３０】 前記監視する工程は、 前記装置から受領した各々の入来ログ・ファイルのサイ
    ズを記憶する工程と、 前記装置から受領したログ・ファイルの履歴的系列の履
    歴的平均サイズを算出する工程と、 前記装置から受領した各々の入来ログ・ファイルのサイ
    ズが、前記履歴的平均サイズから少なくとも所定の量だ
    け逸脱しているか否かを判定する工程と、を含んでいる
    請求項２９に記載の方法。
31. 【請求項３１】 前記運用データは、前記装置を識別す
    るシステム・データと、前記装置の利用状況を記録した
    データとを含んでいる請求項２４に記載の方法。
32. 【請求項３２】 通信チャネル（１８）を介して多数の
    遠隔配置された装置（２）に接続された自動中央サービ
    ス施設（１６、２２）を備えたシステムであって、 各々の装置は、運用データを記憶して、前記装置に記憶
    されているデータ・ログ記録プログラムが作動している
    ときに該データ・ログ記録プログラムに従って前記中央
    サービス施設に対し記憶されている運用データを含むロ
    グ・ファイルを定期的に送付するようにプログラムされ
    ており、 前記中央サービス施設は、前記作動しているデータ・ロ
    グ記録プログラムに従って前記装置からログ・ファイル
    を受領する工程と、特定の装置について、入来ログ・フ
    ァイルの特性が履歴的基準値から逸脱した値を有してい
    るときを検出するように各々の入来ログ・ファイルを監
    視する工程とを実行するようにプログラムされているコ
    ンピュータ・システムを含んでいる、システム。
33. 【請求項３３】 前記特性は、同じ装置からの入来ログ
    ・ファイルの受領とその先行するログ・ファイルの受領
    との間の日数であって、各々の入来ログ・ファイルにつ
    いて且つ各々の装置について判定される請求項３２に記
    載のシステム。
34. 【請求項３４】 前記監視する工程は、 各々の装置から受領した各々の入来ログ・ファイルとそ
    の先行するログ・ファイルとの間の日数を記憶する工程
    と、 装置単位で、各々の装置から受領したログ・ファイルの
    履歴的系列において連続するログ・ファイルの間の履歴
    的平均日数を算出する工程と、 各々の装置から受領した各々の入来ログ・ファイルとそ
    の次に先行するログ・ファイルとの間の日数が、当該装
    置の履歴的平均日数から少なくとも所定の量だけ逸脱し
    ているか否かを判定する工程と、を含んでいる請求項３
    ３に記載のシステム。
35. 【請求項３５】 前記特性は、各々の装置から受領した
    各々の入来ログ・ファイルのサイズである請求項３２に
    記載のシステム。
36. 【請求項３６】 前記監視する工程は、 各々の装置から受領した各々の入来ログ・ファイルのサ
    イズを記憶する工程と、 装置単位で、各々の装置から受領したログ・ファイルの
    履歴的系列の履歴的平均サイズを算出する工程と、 各々の装置から受領した各々の入来ログ・ファイルのサ
    イズが、当該装置の履歴的平均サイズから少なくとも所
    定の量だけ逸脱しているか否かを判定する工程と、を含
    んでいる請求項３５に記載のシステム。
37. 【請求項３７】 前記運用データは、前記装置を識別す
    るシステム・データと、前記装置の利用状況を記録した
    データとを含んでいる請求項３２に記載のシステム。