JP2001117776A - ベイジアンネットワーク・トラブルシュータのためのオーサリングツール - Google Patents

Abstract

(57)【要約】 【課題】 製品（２０９、２１０）のための自動化トラ
ブルシュータの構築において、オーサを支援するオーサ
リングツールを提供することを目的とする。 【解決手段】オーサリングツールは、原因編集インター
フェース（６０）、アクション編集インターフェース
（９０）および質問編集インターフェース（１２０，１
４０）を含む。原因編集インターフェース（６０）は、
製品の障害の原因に関する情報を、オーサが原因データ
構造体に置くことを可能にする。アクション編集インタ
ーフェース（９０）は、製品の障害を直すためにとるア
クションに関する情報を、オーサがアクションデータ構
造体に置くことを可能にする。質問編集インターフェー
ス（１２０、１４０）は、製品の障害の原因を特定する
のを助けるために製品のユーザに尋ねる質問に関する情
報を、オーサが質問データ構造体に置くことを可能にす
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、製品のサポートに
関連し、ベイジアン・ネットワークのトラブルシュータ
のためのオーサリングツールに特に関連する。

【０００２】

【従来の技術】現在、顧客のシステムを診断すること
は、プリンタのメーカにとって非常に費用がかかる。

【０００３】一般に、顧客は、メーカのプリンタ通話係
員（printer call agent）に電話する。この通話係員
は、問題の解決、または原因の特定に至るトラブルシュ
ーティング（troubleshooting）のシーケンスを通じて
顧客を誘導する。この方法は、結果として高コストにな
る通話係員の関与を必要とする。

【０００４】通話係員を使用する場合、プリンタ・メー
カが多くの通話係員を雇い、顧客がプリンタのシステム
で問題を経験するときに彼らに電話する。通話係員は、
電話越しに顧客にインタビューすることによって、でき
るだけ多くの情報を集めようとする。彼が結論に達する
場合、彼は、問題を解決したか、原因を特定したか、さ
もなければ顧客側で問題の解決を試みるフィールド係員
を派遣することになる。

【０００５】通話係員を使用する欠点の１つは、費用に
ある。さらに、さまざまな通話係員によって使用される
トラブルシューティング・ステップの順序および種類に
おける整合性の問題がありうる。類似の問題に対してほ
ぼ同じ順序の同じトラブルシューティング・ステップが
顧客に与えられなければ、顧客を混乱させるかもしれな
いので問題である。また、通話係員の解決策は、限られ
た情報記録をとることしか可能ではなく、プログラムに
基づくデータ収集を統合するのは限界があり、マルチメ
ディア表現の統合にも限界がある。しかしながら、通話
係員の利用は、コンピュータベースのシステムが容易に
見つけることができない情報（例えば、顧客が数行の質
問にいらついているかどうか、顧客の経験レベル、その
他）を、通話係員が間違いなく見つけることができるの
で、通話係員と顧客との間の人と人とのコミュニケーシ
ョンの利点を提供する。

【０００６】判断ツリーを使用してプリンタ・システム
の自動診断を提供することができる。判断ツリーの方法
は、とりうるトラブルシューティングのシーケンスをい
わゆる判断ツリーとして指定する。最後のステップで顧
客によって提供される情報に基づきツリーの分岐のそれ
ぞれで、分岐のうちの１つが選択される。しかしなが
ら、判断ツリーは、限られた数のとりうるトラブルシュ
ーティングのシーケンスしか実際的な理由により提供さ
れないという意味で静的である。判断ツリーでは、顧客
が利用することができなければならない全てのシーケン
スがエンコードされなければならず、判断ツリーの大き
さは、これらのシーケンスの数において指数関数になる
ので、それらのうちの限られた数しかエンコードするこ
とができない。概してこのせいで、判断ツリーは、長い
トラブルシューティングのシーケンスを提供する。すべ
ての可能性のあるシナリオを考慮に入れることが可能な
わけではないので、実際に問題を診断する確率は、低
い。

【０００７】ケース・ベースの推論（case-based reaso
ning）も、プリンタ・システムの自動診断を提供するた
めに使用されることがある。ケース・ベースのアプロー
チは、様々な問題が見られるトラブルシューティングの
シナリオから、大量の記述的なケースを集める。次にケ
ース・ベースの推論エンジンは、現在の状況に関する情
報に基づいて、もっとも類似したケースを選択すること
ができる。もっとも類似したケースが調べられて、可能
な限り多くのケースを除外する、もっとも可能性のある
最良の次のアクションまたは質問が見つけられる。これ
は、現在の状況にもっとも合う１つのケースが判断され
るまで続けられる。

【０００８】ケース・ベースのシステムは、トラブルシ
ューティングの分野（domain）を記述するケースを集
め、これらのケースを使用し、できるだけはやく１つの
ケースに範囲を狭めるアクションおよび質問を提案す
る。ケース・ベースのシステムの質は、そのケースのデ
ータベース次第であり、これは、プリンタ・システムの
分野を十分に記述するために非常に大きくしなければな
らない。プリンタ・システムにおいて予想される構成／
ケースは、すべての変数が２進数であるとすれば、Ｎ個
の変数に対して２^Nである（８０個の変数に対して約１
０^２４）。これらのうちのケースのサブセット（subse
t）は、ケースベースシステムに役立つように十分に記
述するために非常に大きくしなければならない。このた
め、プリンタ・システムを多くの変数で最適レベルの精
度に表わすことにおいて、ケース・ベースのシステムが
うまくいくかは疑問である。

【０００９】ルール・ベースのシステム（rule-based s
ystem）も、プリンタ・システムの自動診断を提供する
ために使用されることができる。ルール・ベースのシス
テムは、それらがベイジアン・ネットワークで表わされ
ることができるので、ベイジアン・ネットワークのサブ
セットとして知覚されることができる。それらは、ベイ
ジアン・ネットワークのモデリング能力のサブセットを
有し、その信念更新方法（belief updating method）
は、ベイジアン・ネットワークのときと同じように、正
しいことが保証されているわけではない。

【００１０】ルール・ベースのシステムは、しかしなが
ら、モデルにループ（loop）がある場合に最適ではない
更新方法を有する。ループは、実際のシステムのモデル
（例えば、一般的原因、いくつかの原因を直すトラブル
シューティングのステップ、その他）において、非常に
一般的である。

【００１１】ベイジアン・ネットワークに基づく１つの
トラブルシュータは、Heckerman、D.、Breese、J. およ
びRommelse, K.の「Decision-theoretic Troubleshooti
n ,Communications of the ACM, 38:49-57」 (以下にお
いて、この文献を“Heckerman et al.（１９９５）”と
呼ぶ）によって記述される。

【００１２】ベイジアン・ネットワークは、変数間の因
果関係を表している有向非巡回グラフであり、それらの
親を与えられたとき、変数に、条件付き確率分布を関連
付ける。ベイジアン・ネットワークにおける確率の正確
な更新のための有効な方法が開発されている。例えば、
これは、Lauritzen, S. L.および Spiegelhalter, D.J.
の「Local Computations with Probabilities on Graph
ical Structures andtheir Applications to Expert Sy
stems（Journal of the Royal StatisticalSociety. Se
ries B, 50(2): 157-224 (1988)）」、並びにJensen,
F. V.、 Lauritzen, S. L.、およびOlesen, K. G.の「B
ayesian Updating in Causal Probabilistic Networks
b Local Computations（Computational Statistics Qua
rterly, 4:269-282 (1990)）」に示される。ベイジアン
・ネットワークにおける確率の正確な更新のための有効
な方法は、ＨＵＧＩＮエキスパート・システムで実施さ
れた。これは、Andersen, S. K.、Olesen, K. G.、Jens
en, F. V.、およびJensen, F.の「HUGIN - a Shell for
Building Bayesian Belief Universes for Expert Sys
tems（Proceedings of the Eleventh International Jo
int Conference on Artificial Intelligence. (198
9)）」に示される。

【００１３】ベイジアン・ネットワークは、確率理論を
使用して問題領域をモデル化する方法を提供する。問題
のベイジアン・ネットワーク表現（Bayesian network r
epresentation）は、他についての情報を与えられたと
き、変数のサブセットについての情報を提供するのに使
用することができる。ベイジアン・ネットワークは、変
数（ノード）のセットおよび有向エッジ(変数間の接続)
のセットを含む。それぞれの変数は、相互排他的な状態
のセットを有する。有向エッジ(directed edge)と共に
変数は、有向非巡回グラフ（ＤＡＧ;directed acyclic
graph）を形成する。親ｗ_１，．．．，ｗ_ｎを有する変
数ｖのそれぞれに対して、条件付き確率テーブルＰ（ｖ
｜ｗ_１，．．．，ｗ_ｎ）が規定される。ｖが親を持たな
ければ、このテーブルは、周辺確率（marginal probabi
lity）Ｐ（ｖ）に減少するのは明らかである。

【００１４】ベイジアン・ネットワークは、不確実性
（uncertainty）を有する多くの応用領域（例えば医療
診断、系統解析、計画、負債検出、ボトルネック検出、
その他）で使用されてきた。しかしながら主要な応用領
域の１つは、診断である。診断（すなわち、再び症状を
引き起こす病気／故障の原因となる基礎をなす要素）
は、ベイジアン・ネットワークのモデル化技術に向いて
いる。ベイジアン・ネットワークの正確な信念更新のた
めに現在もっとも有効な方法は、ネットワークをいわゆ
る接合ツリー（junction tree）に変換する接合ツリー
方法である。これは、Jensen, F. V.、 Lauritzen, S.
L.、およびOlesen, K. G.による「BayesianUpdating in
Causal Probabilistic Networks by Local Computatio
ns（Computational Statistics Quarterly, 4:269-282
(1990)）」に記載される。接合ツリーは、基本的に、ツ
リーが得られ（すなわち全てのループが取り除かれ
る）、クラスタ（cluster）が可能な限り小さくなるよ
うに、変数をクラスタにする。それから、このツリーに
おいて、メッセージの受渡し方式（message passing sc
heme）は、観測変数（observed variable）を与えられ
たとき、全ての非観測変数（unobserved variable）の
信念を更新することができる。ベイジアン・ネットワー
クの正確な更新は、ＮＰハード（NP-hard）である（Coo
per, G. F.による「The Computational Complexity of
Probabilistic Inference using Bayesian Belief Netw
orks（Artificial Intelligence, 42:393-405, (199
0)）」を参照）が、しかしながら、依然としてベイジア
ン・ネットワークのいくつかのクラスに対し非常に有効
である。印刷システムのためのネットワークは、数千の
変数と多くのループを含むが、かなり有効な信念更新を
有する接合ツリーに依然として変換することができる。

【００１５】文献「Heckerman et al （１９９５）」
は、ベイジアン・ネットワークに基づく順次的なトラブ
ルシューティングを実行するための方法を提示する。

【００１６】変数ｃ_１，．．．，ｃ_ｎによって表された
ｎ個のコンポーネントを有するトラブルシュートされる
装置のために、文献「Heckerman et al（１９９５）」
は、まさに１つのコンポーネントが故障していて、この
コンポーネントが問題の原因であることを要する単一故
障の仮定（single-fault assumption）に従う。現在の
状態の情報を与えられたとき、コンポーネントｃ_ｉが異
常である確率が、ｐ_ｉで表わされれば、単一欠陥の仮定
の下ではΣ_ｉ=１ ^ｎｐ_ｉ＝１になる。コンポーネントｃ
_ｉのそれぞれはＣ_ｉ ^ｏ（時間および／またはお金で計ら
れる）で表される観測のコストを有し、さらに修理のコ
ストＣ_ｉ ^ｒを有する。

【００１７】ここに記載しないなんらかの付加的な緩和
された仮定（詳しい情報のために「Heckerman et al
（１９９５）」を参照）の下では、現在の情報で更新さ
れる障害の確率をｐ_ｉとすると、もっとも高い比率ｐ_ｉ
／Ｃ_ｉ ^ｏを有するコンポーネントを観測することが常に
最適であることがわかる。その比率がコストの観測で障
害の確率のバランスをとり、もっとも高い障害の確率お
よびもっとも低いコストの観測を有するコンポーネント
を示すので、これが直感的にわかる。したがって、単一
障害の仮定の下では、最適な観測・修復シーケンスは、
下の表１に示すような方法によって与えられる。

【００１８】

【表１】

【００１９】上の表１に記載した計画において、コンポ
ーネントがステップ３において修復されれば、単一故障
の仮定から、装置が修復されるにちがいなく、トラブル
シューティングのプロセスが停止されることがわかる。
アルゴリズムは、単一故障の仮定が取り除かれれば、か
なりよく機能する。このような場合では、ステップ１
は、ステップ２、および３で得られた新しい情報を考慮
に入れ、ステップ４が、下の表２のように置き替えられ
る。

【００２０】

【表２】

【００２１】文献「Heckerman et al（１９９５）」
は、もっとも最適なトラブルシューティング・シーケン
スの予測されるコストが、サービスコール（例えば支援
のためにメーカに電話する）のコストより高いときに使
用されるサービスコール（service call）を処理するた
めの理論を紹介している。その理論は、複数の故障およ
び非ベース観測（non-base observation）でシステムを
ほぼ処理することを可能にする上記の計画に変わる。非
ベース観測は、コンポーネントではない、トラブルシュ
ーティング・プロセスのために有効な情報を潜在的に提
供する何か、の観測である。

【００２２】関連論文（Breese, J. S.およびHeckerma
n, D.による「Decision-theoretic Troubleshooting:A
Framework for Repair and Experiment」（Technical R
eportMSR-TR-96-06, (1996) Microsoft Research, Adva
nced Technology Division,Microsoft Corporation, Re
dmond, USA））において、その方法は、さらに改良さ
れ、システムにおける構成を変更して、最適なトラブル
シューティングのシーケンスのコストを潜在的に低くす
ることができる有効な情報を提供することが可能であ
る。

【００２３】

【発明が解決しようとする課題】しかしながら、文献
「Heckerman et al（１９９５）」に記述されるベイジ
アン・ネットワークに基づくトラブルシュータは、実際
には維持されない原因とアクションとの間の１対１の対
応関係を有し、質問の近視的な（１ステップの先読み
の）選択を有している。さらに、それらがたくさんある
場合、その質問の選択は、非常に遅くなる。その上、文
献「Heckerman et al（１９９５）」は、それらのトラ
ブルシュータのための知識獲得（knowledge acquisitio
n）の方法を提示しない。

【００２４】

【課題を解決するための手段】本発明の好ましい実施形
態によると、オーサリングツールは、製品のための自動
化トラブルシュータを構築することにおいてオーサを支
援する。オーサリングツールは、原因編集インターフェ
ース、アクション編集インターフェース、および質問編
集インターフェースを含む。原因編集インターフェース
は、オーサが、原因データ構造体に製品の故障原因に関
連する情報を置くことを可能にする。アクション編集イ
ンターフェースは、オーサが、製品の故障を修正するた
めに採られるアクションに関する情報を、アクションデ
ータ構造体に置くことを可能にする。質問編集インター
フェースは、製品の故障の原因を特定するのを助けるの
に製品のユーザに尋ねられる質問に関する情報を、オー
サが質問データ構造体に置くことを可能にする。

【００２５】好ましい実施形態において、オーサリング
ツールは、さらにモジュールのライブラリを含み、少な
くともモジュールの１つは、製品のコンポーネントにつ
いてのトラブルシュートの情報を含む。オーサは、製品
のために自動化トラブルシュータを構築するときに、モ
ジュール・ライブラリからモジュールを選択することが
できる。

【００２６】例えば、原因に関連する情報は、原因の名
前、原因の親、原因の説明、および故障の源である原因
の確率、のカテゴリに関連する。さらに原因に関連する
情報は、原因のカテゴリ、環境への依存性、および顧客
がこの原因の情報にアクセスすることになっていないと
いう表示、のカテゴリに関連することができる。

【００２７】例えば、アクションに関連する情報は、ア
クションの名前、アクションの説明、アクションによっ
て解決される原因、アクションが指定された原因を解決
する確率、およびアクションが情報収集のためのものか
潜在的な解決策であるかどうかの表示、のカテゴリに関
連する。例えば、アクションに関する情報は、他のアク
ションの前にそのアクションがとられるべきかどうかに
関する表示、アクションが回避方法かどうかに関する表
示、アクションに対する回答の信頼、アクションを含む
付加的なアクション、指定された質問が返答された後で
しかそのアクションが実行されることができないかどう
か、および指定された質問が返答された後でそのアクシ
ョンが実行されることができないかどうか、のカテゴリ
に関連することもできる。

【００２８】例えば、質問に関連する情報は、質問の名
前、質問の説明、回答の番号、回答の名前、および回答
のコスト、のカテゴリに関連する。質問に関する情報
は、さらに、指定された質問が返答された後でしかその
質問が実行されることができないかどうか、指定された
質問が返答された後でその質問が実行されることができ
ないかどうか、他の質問の前にその質問が尋ねられるべ
きかどうかに関する表示、およびその質問が症状質問か
または一般質問かどうか、のカテゴリに関連することも
できる。例えば、質問に関連する情報が特に症状質問に
関連する場合、さらに情報は、症状の原因、症状の原因
を条件とする質問に対する回答の確率、症状をもたらす
ことができる原因が何もないことを条件とする質問に対
する回答の確率、のカテゴリに関連することができる。
例えば、質問に関連する情報が特に一般質問に関する場
合、さらに情報は、質問に対する回答の事前確率、質問
に対する回答によって影響を受ける原因、質問に対する
回答のそれぞれを条件とする影響を受ける原因の確率、
のカテゴリに関連することができる。

【００２９】好ましい実施形態において、原因編集イン
ターフェースは、オーサが新しい原因のエントリを作成
および削除、並びに既存の原因のエントリを編集するこ
とを可能にする。アクション編集インターフェースは、
オーサが新しいアクションのエントリを作成および削
除、並びに既存のアクションのエントリを編集すること
を可能にする。質問編集インターフェースは、オーサ
が、新しい質問のエントリを作成および削除、並びに既
存の質問のエントリを編集することを可能にする。

【００３０】本発明の好ましい実施形態に従うオーサリ
ングツールは、知識獲得に必要な時間を大幅に低減させ
る。オーサリングツールは、絶対最小量の情報だけを指
定することを可能にする一連の質問を通じて、オーサが
誘導されるように構成される。オーサリングツールは、
分野の専門家が自然に、直感的に分かるようなやり方
で、その分野の情報が指定されるように構成される。オ
ーサリングツールは、ベイジアン・ネットワークの知識
を必要としないように構成される。これにより、知識獲
得（ＫＡ；knowledge acquisition）プロセスの間に、
ベイジアン・ネットワークの専門家がいる必要はない。
また、当該分野におけるエラー状態（error conditio
n）のためのトラブルシューティング・モデルの初期構
築は比較的遅いけれども、しかしながら、オーサリング
のスピードは、モジュールの再利用を通じて、その分野
におけるモジュールがたくさん作られるにつれて速くな
る。

【００３１】オーサリングツールは、以前に作られたト
ラブルシュータのすみやかな保守を可能にする。オーサ
リングツールが存在する前には、基礎をなすベイジアン
・ネットワークの直接的な操作がトラブルシュータの振
る舞いを修正するのに必要であった。しかしながら、オ
ーサリングツールがあれば、必要な変更は、目的に適し
た表現で実行されることができる。さらに、モジュール
の再利用のせいで、モジュールにおける変更は、このモ
ジュールが使用される全ての場所に伝播されることがで
きる。したがって、トラブルシュータ・モデルの保守の
ために必要な時間は、大幅に低減される。

【００３２】オーサリングツールは、ある製品から次の
製品へのすみやかな移行を可能にする。トラブルシュー
ティングの情報がモジュール態様で整理されるので、あ
る製品から次の製品にトラブルシュータを移行すること
は、変更されたモジュールだけを単純に考えることで、
速くて簡単になる。多くの製品シリーズの場合、異なる
バージョン、異なるリビジョン、および／または異なる
モデルの間の変更は、ほとんどない。必要な変更は、通
常、明確に規定されたモジュールにおいて存在する。さ
らに、製品のための初期のトラブルシューティング・モ
デルを作成するときに、次のモデルで変更する可能性の
ある情報に、印を付けることができる。したがって、こ
れらのモデルを移行するときに、オーサリングツール
は、分野の専門家による考察のために、印を付けられた
情報を表示することができる。このようにして、移行の
ために必要な時間は、モジュールにおける情報の構成お
よびモデル間の変更の可能性のある情報の印によって、
低減させることができる。

【００３３】本発明の好ましい実施形態は、知識獲得
が、その分野の知識を有する人々、すなわち分野の専門
家（domain expert）によって実行されることを可能に
する。ベイジアン・ネットワーク、トラブルシューティ
ングのアルゴリズム、その他の専門的知識は、必要では
ない。したがって、本明細書に記述するオーサリングツ
ールは、最小限の労力でトラブルシュータを生成するこ
とを可能にする。

【００３４】

【発明の実施の形態】図１は、本発明の好ましい実施形
態に従うトラブルシューティング環境の概要を示すブロ
ック図である。

【００３５】図１は、ウェブサーバ２００、顧客パーソ
ナルコンピュータ（ＰＣ）２０５、プリンタサーバ２０
９およびプリンタ２１０を示している。プリンタシステ
ム・トラブルシュータ２０１は、ウェブサーバ２００上
で走る。顧客ＰＣ２０５でユーザは、インターネット２
０２越しにトラブルシュータ（troubleshooter）２０１
にアクセスすることができる。顧客ＰＣ２０５内部のウ
ェブブラウザ２０６は、ウェブサーバ２００にアクセス
するのに使用される。トラブルシュータ２０１との顧客
の相互作用に応じて、トラブルシュータ２０１は、顧客
が実行することができるトラブルシューティング・ステ
ップのための提案（suggestion）２０３で応答する。基
本的にトラブルシュータ２０１は、人工知能を利用する
エキスパート・システム（expert system）の機能を果
たす。顧客がトラブルシュータ２０１に返す情報２０４
を提供し、この情報が提案２０３に基づく作用の結果を
トラブルシュータ２０１に知らせる。情報２０４は、顧
客がプリンタサーバ２０９から得る情報２０７および／
または顧客がプリンタ２１０から得る情報２０８を含む
ことができる。

【００３６】図２は、ウェブサーバ２００の簡略化され
たブロック図である。トラブルシュータ２０１は、ウェ
ブサーバ２００のメモリ３０１内で実行される。トラブ
ルシュータ２０１は、トラブルシューティング・モデル
の記憶のために、第２記憶装置３０３を利用する。ビデ
オ・ディスプレイ３０４は、トラブルシューティング・
プロセスを監視し、トラブルシューティング・モデルを
保守するために技術者によって使用されることができ
る。ウェブサーバ２００は、入力装置３０５（例えばキ
ーボードなど）、ＣＰＵ３０６、および顧客ＰＣ２０５
におけるウェブブラウザ２０６と通信するためのネット
ワーク・カード３０７を含む。

【００３７】図３は、トラブルシューティングのプロセ
スのコンポーネントの概要を示すブロック図である。ウ
ェブサーバ２００が示される。顧客は、顧客ＰＣ４０１
上で走るウェブブラウザ２０６を通じてウェブサーバ２
００内部のトラブルシュータ２０１（図１に示す）と通
信する。顧客は、トラブルシュータ２０１からの提案２
０３を受信し、引き換えに回答２０４を提供する。顧客
は、プリンタサーバ２０９およびプリンタ２１０を含む
プリンタ・システムにおいて動作不良を経験するとき
に、トラブルシュータ２０１を使用する。一般に、顧客
がアプリケーション４０６から印刷しようとする場合、
プリントジョブ(print job)は、最初にプリンタドライ
バ４０７に行き、次にもし利用するならばローカル・ス
プーラ４０８を経由し、それからオペレーティングシス
テム（Ｏ／Ｓ）リダイレクト４０９に行く。Ｏ／Ｓリダ
イレクト(O/S redirect)４０９は、プリントジョブがど
の進路に行くのか（すなわち、ネットワーク・ドライバ
４１０およびネットワーク・カード４１１を介してネッ
トワーク接続４１３に行くのか、またはローカルパラレ
ル接続プリンタの場合におけるローカル・ポート４１２
に行くのか）を判断するオペレーティングシステムの一
部である。プリントジョブがローカルパラレル接続プリ
ンタに行く場合、プリントジョブは、プリンタ２１０に
達する前にパラレルケーブル４１５を通る。プリントジ
ョブがネットワークプリンタに行く場合、それは、ネッ
トワーク接続４１３を通ってプリンタサーバ２０９に行
くか、または直接ネットワーク接続４１４を通ってプリ
ンタ２１０に行くかのいずれかである。直接ネットワー
ク接続４１４は、特定のプリンタ（例えばHewlett-Pack
ard Companyから入手可能なHP LaserJet 5Si）のために
利用されることがある。プリンタ２１０がプリンタサー
バ２０９によって制御されるとき、プリントジョブは、
プリンタサーバ２０９のプリンタ・キュー(printer que
ue)４２０を通る。それからプリントジョブは、プリン
タ２１０がプリンタサーバ２０９に接続される方法に依
存して、プリンタ２１０へのネットワーク接続４１７
か、またはパラレルケーブル４１８のどちらかを通じて
送られる。

【００３８】アプリケーション４０６、プリンタドライ
バ４０７、スプーラ４０８およびＯ／Ｓリダイレクト４
０９は、顧客ＰＣ２０５上のオペレーティングシステム
４０５において全て実行される。アプリケーション４０
６からプリントジョブを印刷するとき、プリントジョブ
は、システムのセットアップ（system setup）に応じ
て、プリンタ２１０に向かう途中で、上記の経路の１つ
をたどる。何か途中で間違いがあれば、これは、結果と
して出力されないか、または予想外の出力をもたらすこ
とがある。トラブルシュータ２０１は、システム内のコ
ンポーネントのテストを通じて、どのコンポーネントが
問題を引き起こしたのかを判断しようとする。

【００３９】図４は、トラブルシュータ２０１を実現す
るための知識獲得（knowledge acquisition）を実行す
るステップの概要である。知識獲得プロセスは、いわゆ
る、分野の専門家（domain expert）から、分野につい
ての十分な情報を集めることによって、トラブルシュー
ティングのモデルを構築するプロセスである。分野の専
門家は、モデル化されている分野（この場合、プリンタ
・システム）に精通している。これらの分野の専門家
は、検討中の分野の詳細な知識を有しており、構築段
階、トラブルシューティング、または製品のサポート段
階において支援した。知識獲得プロセスは、そのプロセ
スのルールおよび要求事項に精通している人によって導
かれなければならない。知識獲得プロセスに参加するこ
と、または知識獲得プロセスを導くことは、ベイジアン
・ネットワークの分野における専門知識を必要とはしな
い。説明のために、図４に開示されるステップの説明全
体を通じての例として、「薄いプリント（light prin
t）」問題を使用する。「薄いプリント」とは、予想よ
り薄い出力をプリンタから受け取るユーザの問題であ
る。

【００４０】ステップ９００において、トラブルシュー
トする課題（issue）が特定される。モデル化されてい
る問題（problem）は、特定され、正確に規定され、他
の問題から切り離される。最初に検討中の問題、および
トラブルシューティング・ツールの視聴者（audience）
を正確に規定することは、次に続く知識獲得ステップに
大きな影響をあたえるので重要である。エンドユーザが
処理することができなくて、経験豊かな修理技術者が処
理することができる原因(cause)およびステップがある
ので、視聴者の技術レベルは、原因およびステップの両
方を指定するときに重要である。これ以降では、プリン
タ・システムの初歩的な知識しか持たなくて、複雑なス
テップを実行するのに誘導される必要があるエンドユー
ザの視聴者がいると仮定する。

【００４１】ステップ９０１において、課題の原因が特
定される。このステップにおいて、分野の専門家は、検
討中の問題の原因を特定する。原因は、基本的には、問
題の原因となりうる全ての様々なコンポーネント、プロ
パティ、またはイベントである。

【００４２】非常に稀なために考えるに値しない原因
（例えばプリント問題を引き起こす仕様外の重力、また
は例えば、プリンタ・コンポーネントにおける高度に技
術的な問題などの、ユーザがどのようにしても影響を及
ぼすことができない原因）があるので、全ての原因を特
定し指定することは、通常不可能であり、必要ではな
い。このような原因は、「その他の問題（other proble
m）」と呼ばれる単一の漏れ原因（leak cause）に集め
られる。「その他の問題」は、プリンタの電源を入れな
おすことによって解決することができる「一時的問題
（temporary problem）」と、ユーザが解決することが
できない「永久的問題permanent problem」とでそれぞ
れ表される２つの副原因(subcause)を有する。

【００４３】原因を特定することの難しさの１つは、単
一の原因として原因の組をグループにするか、あるいは
原因を分離したままにしておくかを判断することにあ
る。一般的に、様々なアクションに対する原因が別々に
されていれば、アクションに対する知識獲得を行うこと
は、より簡単になる。

【００４４】例えば「薄いプリント」問題に対して、以
下の原因および副原因が表３のように特定された。

【００４５】

【表３】

【００４６】経験によると、このレベルでの原因のモデ
ル化が、プリンタ・システムの経験豊かな通話係員によ
って用いられる考え方に非常によく似ている。彼らが電
話越しにプリンタ問題をトラブルシュートするとき、彼
らは、先に述べたものと同様の原因および副原因のリス
トを念頭におく。そして顧客との会話に基づき様々な原
因の信念（belief）を絶え間なく調整する。

【００４７】ステップ９０２において、（もしあれば）
副原因が特定される。このようなカテゴリ（category）
は、たくさんの副原因を有する原因として認識される。
必ずしも原因の副原因を使用することが必要ではなく、
同じ上部のレベルに全ての副原因を持つことが十分可能
である。しかしながら、このアプローチは、しばしば上
部のレベルに非常に多くの数の原因を導くことになり、
確率の取得をより困難にする。原因を階層に系統立てる
ことは、分野の専門家が、確率を見積もる際に、１回で
より少数の原因を考えられるようにする。これにより、
より正確な情報が提供される。

【００４８】図４では、２つのレベルの原因の構造体
（cause-structure）しか示さないが、任意の多くのレ
ベルの原因および副原因がありうる。

【００４９】「薄いプリント」のための完成した原因の
階層は、下の表４に示される。

【００５０】

【表４】

【００５１】ステップ９０３において、課題のトラブル
シューティング・ステップが特定される。問題の原因の
うちのどれかを解決することができるアクション、およ
び原因に関する情報を提供することができる質問がリス
トにされる。

【００５２】問題のトラブルシューティング・ステップ
をリストにする場合、分野の専門家は、彼らが問題に直
面するときに、彼ら自身が実行するか、または顧客のた
めに提案するステップを基本的に考える。経験による
と、忘れられていたステップを時折思い出させるので、
あらかじめリストにされた原因を考慮しないで（すなわ
ち「まっさらな」心で）、ステップをリストにしはじめ
ることが有利である。それから、これらの第１のステッ
プがリストにされたときに、原因のリストを考慮して、
これらの原因を解決する可能性のある全てのステップを
追加するのが良い。

【００５３】トラブルシューティング・ステップをリス
トにする場合、想定したトラブルシュータの視聴者が実
行することのできるステップだけをリストにすべきであ
る。例えば視聴者がエンドユーザの場合、うまく実行す
るためにプリンタ・システムの高度な技術的知識を必要
とするステップを提案することは不適当である。未熟な
ユーザが実行したときに、何かを壊してしまう高い危険
性を伴うステップも存在する。これも含まれるべきでは
ない。非常に高価な必要品を要求するステップも、通常
含まれるべきではないステップである。

【００５４】分野の専門家は、ステップの大きさおよび
範囲の問題に再び直面する。単一のステップまたは一連
のステップとして同等にモデル化されることができるト
ラブルシューティングの手続き（procedure）がある。
一般的に、それは、ユーザインターフェースおよびステ
ップをどのように表わすかというステップ自身に依存す
る。もしステップが判断型のフロー図(deterministic f
low-diagram)のif-then-else構成として、うまく表され
ることができて、トラブルシュータのユーザインターフ
ェースがそのような判断型「プログラム」の実施をサポ
ートすれば、ステップは、単一のステップとしてモデル
化されるべきである。もしステップのフロー図が不確定
な／確率的な判断を含むならば、ステップは複数のステ
ップとして表されなければならない。

【００５５】２つの主カテゴリのトラブルシューティン
グ・ステップがある。それは、アクション（action）お
よび質問(question)である。第１のカテゴリ「アクショ
ン」は、ユーザがシステムにおいてなんらかの種類の介
入を実行して、アクションが問題を解決したかどうかを
トラブルシュータに報告することを必要とするステップ
である。したがって、アクションは、問題を解決するた
めの潜在的能力を有する。第２のカテゴリ「質問」は、
ユーザがおそらくは手動でシステムに介入することによ
って、問題に関連したなんらかの情報を得て、トラブル
シュータにその結果を報告することを必要とするステッ
プである。質問は、情報収集アクション(information-g
athering action)および一般質問(general question)の
２つのサブカテゴリに分類される。

【００５６】情報収集アクションは、問題を解決する潜
在的能力を持たないアクションである。それらは、単に
問題の解決に関連する情報を提供する。通常のアクショ
ンは、情報収集アクションからそれらを区別するために
解決アクション(solution action)とも呼ばれる。トラ
ブルシューティング・アルゴリズムでは、２種類のアク
ションが別々に処理されるので区別することが重要であ
る。情報収集アクションが質問として扱われることは下
でさらに説明される。これは、情報収集アクションと質
問との間にアルゴリズム的に違いがないことを意味す
る。しかしながら、その区別は、それらがアクションと
して扱われれば、分野の専門家が情報収集アクションの
ために確率を引き出すことが簡単になるので、知識獲得
の間、維持される。

【００５７】情報収集と解決アクションとの間の区別
も、明確にされるべきである。解決アクションは、問題
を解決するための潜在的能力を有するが、情報収集アク
ションは、問題を解決することができない。情報収集ア
クションは、環境に対するなんらかの変化が試される間
に、一時的に問題を取り除く潜在的能力しか有していな
い。

【００５８】一般質問は、情報収集アクションではない
残りの質問である。質問は、問題を解決する潜在的能力
を有しておらず、アクションが２つの回答（はい（役立
った）、いいえ（役立たなかった））しか持たないのと
は対照的に、いくつもの回答を持つことができる。

【００５９】問題のトラブルシューティング・ステップ
をリストにする場合、それらは、解決アクション（Ｓ
Ａ：solution action）、情報収集アクション（ＩＡ:in
formation-gather action）または質問（Ｑ:question）
のどれかに分類されなければならない。

【００６０】知識獲得プロセスにおいて、これらの説明
／定義が、この先の混乱を低減するのに役立ち、誤りを
できるだけはやく捕らえることを確実にするので、全て
のアクションおよび質問のための説明は、なるべく早め
に書かれるべきである。

【００６１】「薄いプリント」問題のために、表５のよ
うな以下のステップが特定された。

【００６２】

【表５】

【００６３】上記のステップの２、３が、情報収集アク
ションとして分類される（例えば、ステップＢの「別の
トナーカートリッジを試しなさい」）。ステップＢを実
行した後で、問題が取り除かれたとしても、依然として
問題は、解決されていない。それらしい問題の原因が特
定されたが、さらに行われるであろう調査がある。そし
て、その別のトナーカートリッジは、おそらく持ってき
た元の場所に返さなければならない。すなわち問題は、
解決されていない。これは、プリンタ・コンポーネント
を別のものに取り替えるステップに一般的に当てはまる
ことである。もしそれがうまくいけば、トラブルシュー
ティングの範囲は、かなり狭まるが、問題を完全に解決
するために実行されるだろうステップが依然として残っ
ている。

【００６４】表５のステップＦは、一定量のページが印
刷される毎に実行されなければならないプリンタ保守
（ＰＭ: printer maintenance）キットを実行すること
を提案する。ＰＭキットを実行しなければならない場
合、通常、プリンタのコントロールパネルが通知を与え
るが、必ずしもいつもではない。絶対に必要な場合にし
かＰＭキットを実行すべきではないので、ＰＭキットを
提案する前に、それがコントロールパネル上に提案され
るかどうかを尋ねるのが良い考えである。

【００６５】表５のステップＴは、データフローのどこ
かでプリントジョブが損なわれているのかどうかを判断
しようとする一連のサブ・ステップを含む大きくて複雑
なトラブルシューティングのステップであり、破損源
（source of the corruption）を特定する。基本的に、
下に説明する損なわれた出力のための全体のデータフロ
ーモデルは、ステップＴおよびそれに関連付けられた原
因のもとで適当である。

【００６６】ステップ９０４において、原因とトラブル
シューティング・ステップが、対応させられる。トラブ
ルシューティング・ステップは、それらが解決すること
ができる原因に対応させられる。さらに、質問に関連す
る原因が特定される。このステップにおいて、原因がト
ラブルシューティング・ステップに対応させられる。ア
クションは、解決することができる原因に対応させら
れ、質問は、関連する（すなわち確率に影響する）原因
に対応させられる。

【００６７】それぞれのアクション（Ａ_ｉ）のために、
Ａ_ｉの実行が原因（Ｃ_ｊ）を解決する０以外の確率があ
るかどうかが、それぞれの原因（Ｃ_ｊ）に対して考慮さ
れる。もしこれがあれば、知識獲得プロセスにおいて後
で使用するために対応が登録される。

【００６８】情報収集アクションは、解決アクションと
ほぼ同様に処理されることができる。たとえ、それらが
問題を解決することができないにしても、それらは、環
境におけるなんらかの変化を試みる間に、問題を一時的
に取り除くことができる。例えば、先の表５のステップ
Ｂにおける「別のトナーカートリッジを試しなさい」
は、上記の表４においてリストにされた副原因４ａ、４
ｂ、または４ｃが、その原因である場合、問題を無くす
ことができる。そのため、実行された時に問題を取り除
くアクションに対する原因が、情報収集アクションのた
めに登録される。

【００６９】それぞれの質問（Ｑ_ｉ）のために、Ｑ_ｉに
対する回答が、Ｃ_ｊにおける信念（belief）に直接的に
影響を及ぼすかどうか（すなわち確率を低くさせる、ま
たは高くする）が、それぞれの原因（Ｃ_ｊ）に対して考
慮される。

【００７０】質問は、トラブルシューティングのシナリ
オ、ユーザタイプ、その他についての情報を提供して、
関連するアクションを可能／不可能にするために時々使
用されるので、どのような原因の信念にもまったく影響
を及ぼさなくてもよい。これの１つの例が、あるコンポ
ーネントの種類またはメーカについての質問であり、こ
れに対する回答は、コンポーネントが、あるアクション
をサポートするかどうかを制御する。したがって、これ
らのアクションが成功する確率は、コンポーネントのメ
ーカが正しい種類のものでない場合、０になる。

【００７１】「薄いプリント」問題のためのステップと
原因との対応は、下の表６に示すようなものである。そ
れぞれのアクションまたは質問の後で、関連付けられた
原因（上記の表４に入力される）は、リストにされる。

【００７２】

【表６】

【００７３】分野の専門家によると、表６におけるトラ
ブルシューティング・ステップのＶは、原因２、５、お
よび５ｃの信念に影響を及ぼす。ＰＭキットが期限にな
っていれば、ＰＭキットによって対象にされるなんらか
の原因（すなわち、（２）用紙経路の汚れ、（５）一般
的な転写ローラー問題、（５ｃ）具体的な損耗した転写
ローラー）に高い信念がある。トラブルシューティング
のステップＹにおける質問は、症状についての情報（構
成ページ（configuration page）が薄く印刷されるかど
うか）を要求する。これは、原因１〜５、８、および１
１の症状である。これらの原因は、構成ページが印刷さ
れるときに依然として影響のあるハードウェア原因（ha
rdware cause）である。指定されなかった原因は、この
状況において影響のないソフトウェア原因（software c
ause）である。質問のための確率の取得を、さらに下に
説明する。

【００７４】ステップ９０５において、何らかの新しい
原因または副原因が特定されたかどうかを見るためのチ
ェックがなされる。例えば、これらは、原因とステップ
とを対応させるときに特定されることができる。なんら
かの新しい原因または副原因が特定されれば、ステップ
９０１に戻る。

【００７５】アクションおよび質問を、それらに関連す
る原因に対応させるとき、解決アクションのない原因、
およびどのような原因も解決することができないアクシ
ョンが発見されることがよくある。すなわち、それぞれ
見落としているアクションおよび原因が存在する。この
場合、ステップ９０１に戻る必要がある。

【００７６】ステップ９０６において、例えば原因とス
テップとを対応させるときに、なにか新しいトラブルシ
ューティング・ステップが特定されたかどうかを見るチ
ェックがなされる。もし新しいトラブルシューティング
が特定されたならば、ステップ９０３にジャンプする。

【００７７】原因およびステップは、最初のリスト化で
はたびたび忘れられる。そして、原因をステップに対応
させるときに、新しい原因およびステップがたびたび発
見される。このため、原因に対する確率を引き出す前
に、原因とステップとの対応付けを実行するのが最善で
ある。その理由は、新しい原因が発見されるたびに、こ
の引き出し（elicitation）を部分的に繰り返し実行し
なければならないからである。

【００７８】ステップ９０７において、原因および副原
因の確率が見積もられる。高い程度の確実性で、全ての
原因がリストにされて、原因および副原因が階層に構成
されているときに、原因の確率が見積もられるべきであ
る。これは、通常、下から上の方向で行われ、そのため
原因を与えられたとき、副原因の確率が最初に見積もら
れ、それから問題を与えられたとき、原因の確率が見積
もられる。

【００７９】副原因の確率が最初に見積もられる。副原
因のセットは、同じ原因の副原因のセットのそれぞれに
対して、別々に確率の引き出しが実行されるように順々
に視察される。副原因の確率は、問題が存在し（例えば
「薄いプリント」）、原因が存在する（例えば「トナー
カートリッジ問題」）と想定して引き出される。全ての
副原因の確率が引き出されたとき、問題が存在すると想
定して原因の確率が引き出される。

【００８０】経験によると、基本的に原因を表す方向
（causal direction）（副原因が原因をもたらし、原因
が問題をもたらす）に対して確率を引き出す確率引き出
しのこの方法は、問題および／または原因が存在すると
彼らに想定させて、それらの確率の基礎となる最大限の
情報を分野の専門家に提供するので、非常に有効であ
る。

【００８１】原因／副原因のセットの確率を引き出す通
常の手順は、より高いレベルの原因を与えられた原因の
ほとんどに初期の確率を与えるか、または少なくとも順
位（これが最も高い、これが次に高い、等）を与える１
人の分野の専門家に対するものである。その次に、複数
の分野の専門家が、初期の確率または順位を議論して、
議論の結果どおりに調整を行う。最終的合意に達したと
き、引き出しが終了する。

【００８２】引き出しプロセスにおいて生じる信念にお
ける差違は、分野の専門家の１人による知識の不足にほ
とんどいつも原因があり、議論を行って、分野の専門家
のどれが間違っているのかを発見する。たいていの場
合、すぐに合意に達して、これを反映するように確率が
調整される。しかしながら、時折、他の専門家と相談し
て不一致を解決する必要がある。

【００８３】確率における不一致が非常に小さい（例え
ば０．０５）場合、非常に長い議論は、しばしば不要で
あると思われ、その平均が選択される。しかしながら、
不一致が大きい場合、基礎をなす分野の構造体の共通の
理解に至ることは、将来の確率の引き出しに、この理解
が役立つこともありえるので非常に重要である。

【００８４】引き出しプロセスの間、１組の確率が、検
討中の原因のために展開される。この１組の確率は、必
ずしも常に正規化（合計で１．０）される必要があるわ
けではない。常に合計を１．０に維持しなければならな
い場合、それがプロセスをかなり遅くするので、柔軟性
を否定し、１．０と若干異なる合計を認めない理由はな
い。引き出しが完了したときに、確率を正規化すること
は容易である。

【００８５】あるプロジェクトでは、分野の専門家は、
確率の代わりにパーセンテージを引き出すことを好み、
例えば０．１の代わりに１０．０％が使用された。これ
は、０〜１の範囲と比較して０〜１００の範囲の数で作
業するほうがより簡単なので（小数がほとんどないの
で）理解できる。また、彼らがパーセントで考えること
に慣れている可能性がある。

【００８６】引き出された確立に若干の２次的な不確実
性（second-order uncertainty）が常にあることは明ら
かである。この２次的な不確実性を表す１つの標準的方
法は、その確率が、ある範囲内の信念であることを分野
の専門家が明言するような確率の範囲（probability in
terval）を使用することである。分野の専門家が特定の
範囲で合意したときに、ベイジアン・ネットワークにお
ける確率の範囲の伝播を可能とする方法がある。２次的
な不確実性を表現することは、分野の専門家が異なる確
率のために異なる大きさの確率の範囲を指定することを
可能にし、自動化トラブルシュータは、適当な不確実性
でその結論を与えることができる。

【００８７】「薄いプリント」問題のために、下の表７
のような確率（パーセントにおける）が引き出された。

【００８８】

【表７】

【００８９】ステップ９０８において、アクションおよ
び質問の確率が見積もられる。好ましい実施形態では、
２種類の質問がある。その２種類とは、原因の症状また
は影響に関係する質問、および性質上、症状または影響
とみなされない一般質問である。２種類の質問のための
知識獲得プロセスには違いがある。そのため、その確率
を引き出す前に、質問の種類を判断することが重要であ
る。この２種類の質問の間の違いを、さらに詳しく下に
述べる。

【００９０】一般質問のために、質問に関連する原因、
すなわち、質問に対する回答に応じて増減する確率を有
する原因が、前もってリストにされている。この種類の
質問のために、分野の専門家は、質問に対するそれぞれ
の回答（例えば、はい、いいえ、その他）を考えて、影
響を受ける原因の確率が新しい情報に応じてどのくらい
増減するのかを見積もる。引き出しは、原因に対するも
のとそっくりに進行する。議論によって解決しなければ
ならない理解における不一致がありうる。分野の専門家
は、質問に対する回答によって影響を受ける原因に注目
する。したがって、影響を受けない原因の確率は、専門
家によって修正されない。しかしながら、増減される確
率を有する原因があるとういう事実は、残っている確率
をそれに応じて変化させて合計を依然として１．０にす
る。直接影響を受ける確率だけを調整して、次にその残
りを、それに応じて変化させることは、全ての確率にお
ける変化を専門家に評価させることと比較すれば、より
簡単であることは明らかである。また、経験によれば、
専門家は、残りの確率をそれに応じて変化させることに
慣れている。

【００９１】「薄いプリント」問題では、質問「コント
ロールパネルでトナーが少ないのが分かりますか？」に
対する回答を与えられる場合、確率（パーセント）が下
の表８のように調整される。

【００９２】

【表８】

【００９３】したがって、プリンタのコントロールパネ
ルがトナーが少ないと告げている場合、問題の原因であ
る「トナーカートリッジ問題」の確率は、０．９に上げ
られる。副原因「トナー分布（toner distribution）」
の確率は、「トナーカートリッジ問題」の他の副原因と
比較してすでに高いので、この確率をさらに増やさない
ように判断された。

【００９４】同様に、コントロールパネルがトナーが少
ないと告げていないことが分かった場合、副原因「トナ
ー分布」の確率を０．８５から０．２５に減らすように
判断がなされた。しかしながら、たとえコントロールパ
ネルがトナーが少ないと告げていないことが分かって
も、「トナーカートリッジ問題」の全体的な確率はその
ままにするように判断された。

【００９５】また、一般質問のために、分野の専門家
は、問題に対する回答のための事前確率（prior probab
ility）を与えなければならない。専門家が一般質問の
ために矛盾のない情報を指定したかどうかを、関連づけ
られた原因の無条件確率Ｐ（Ｃ）、条件付き確率Ｐ（Ｃ
｜Ｑ）、および質問に対する事前確率Ｐ（Ｑ）を解析す
ることによって（すなわちΣ_ＱＰ（Ｃ｜Ｑ）Ｐ（Ｑ）を
Ｐ（Ｃ）と比較することによって）、どのようにチェッ
クするかが下に説明される。

【００９６】症状についての質問のために、質問に関連
する原因（当該症状をもたらす原因）は、図４に示して
上で説明したステップ９０４においてリストにされる。
ここで引き出しは、関連する原因のそれぞれのために、
原因を与えられたときの症状の確率を与えることからな
る。また、指定された原因のどれも存在しない場合に症
状が現れる確率が見積もられるべきである。

【００９７】「薄いプリント」（表５における質問Ｙ）
の問題において、「構成ページは、薄くプリントされる
か？」は、症状の質問である。確率（パーセント）は、
下の表９のように評価された。

【００９８】

【表９】

【００９９】指定された原因のどれも存在しない場合の
症状の確率は、（パーセントで）１である。

【０１００】したがって、分野の専門家の評価によれ
ば、例えば、その原因が正しくないコントロールパネル
の設定（先の表９における原因８）であれば、構成ペー
ジが薄く印刷される１．０（１００％）の確率がある。
原因が媒体、用紙経路、環境条件、その他のいずれかで
ある場合も同様である。

【０１０１】原因が「その他の問題」であれば、専門家
は、０.５の確率で、構成ページが薄くプリントされる
と評価する。この確率が１．０でない理由は、構成ペー
ジのプリントに影響しない一時的および永久的問題があ
るためである。

【０１０２】分野の専門家は、たとえ前記の指定された
原因がどれも存在しなかったとしても、構成ページが薄
くプリントされる確率を完全には除外したくなかった。
それで、彼らは、この状況のために０．０１の確率を残
した。

【０１０３】アクションのために、図４のステップ９０
４においてリストにされた原因のそれぞれを与えられた
問題を、アクションが解決する確率を判断する必要があ
る。これらの原因は、アクションが潜在的に解決するこ
とができる原因であると考えられる。

【０１０４】トラブルシューティング・アルゴリズム
は、問題についての前もって得られた情報を与えられ
た、問題を解決するアクションの確率を必要とする。そ
のため、分野の専門家は、リストにされた原因（Ｃ_ｉ）
のそれぞれのために、「Ｃ_ｉが当該問題の唯一の原因で
あると想定すると、アクションを実行することが問題を
解決する確率は、どのくらいか？」を回答しなければな
らない。

【０１０５】経験によると、この確率を見積もる場合、
正確に実行された場合にアクションが問題を解決する実
際の確率だけでなく、アクションが正確に実行される確
率など、あまりにも多くのことを考慮に入れなければな
らない。あまりに多くのものを考慮に入れて、同時に考
えなければならない場合、その結果は低品位の確率にな
る。

【０１０６】上記の引き出しを２つの確率引き出し質問
（probability elicitation question）に分ければ、見
積もりは、より高品位になるはずである。第１の確率引
き出し質問は、「Ｃ_ｉが当該問題の唯一の原因であると
想定すると、アクションを正確に実行することが問題を
解決する確率は、どのくらいか？」である。第２の確率
引き出し質問は、「Ｃ_ｉが当該問題の唯一の原因である
と想定すると、ユーザが気づかずに正しくないアクショ
ンを実行する確率は、どのくらいであるか？」である。

【０１０７】第１の確率引き出し質問に回答する場合、
分野の専門家は、アクションが正しく実行されると想定
することができ、これにより問題を解決する確率を評価
するのが簡単になる。第２の確率引き出し質問に回答す
る場合、分野の専門家は、ユーザが正しくないアクショ
ンを実行する確率を評価することに集中することができ
る。

【０１０８】気づかずに正しくないアクションをユーザ
が実行する確率を評価することは重要である。その確率
は、正しくないアクションを実行する全体的な確率では
ない。この確率は、ユーザからの正しくないフィードバ
ック（feedback）の確率を表わすのに必要とされる。正
しくないフィードバックは、ユーザが正しくないアクシ
ョンを行ったことに気づかない状況において得られる。
そのため、ユーザが正しくないアクションをしたことに
気づくケースは、確率に含まれない。このような状況で
は、ユーザは、正しくないフィードバックを入力しない
で、アクションを再び実行しようとするか、または彼が
アクションを実行することができなかったことを入力と
して与える可能性がある。

【０１０９】第１の確率引き出し質問に回答するときに
見つかった確率が、Ｐ_１で示され、第２の確率引き出し
質問に回答するときに見つかった確率が、Ｐ_２で示され
れば、原因Ｃ_ｉを与えられたとき、問題を解決するアク
ションの全体的な確率は、以下に示される。

【０１１０】

【数１】 Ｐ（Ａ＝ｙｅｓ｜Ｃ_ｉ＝ｙｅｓ）＝Ｐ_１（１−Ｐ_２）

【０１１１】経験によれば、第２の確率引き出し質問
（ユーザの応答の不正確性と呼ぶ）に回答するときに評
価される確率のばらつきは、ほとんどない。したがっ
て、不正確性のために、範囲（０−非常に低い（Ｖ
Ｌ）、１−低（Ｌ）、２−中（Ｍ）、３−高（Ｈ）、４
−非常に高い（ＶＨ））を使用して０から４の間の要素
を見積もれば十分であった。そのとき、この不正確性の
要素は、下の表１０のような確率に変換されることがで
きる。

【０１１２】

【表１０】 ＶＬ ：０ Ｌ ：２％ Ｍ ：５％ Ｈ ：１０％ ＶＨ ：２０％

【０１１３】不正確性要素の確率への変換は、分野の専
門家に対する一連の質問によって判断されることができ
る。

【０１１４】さらに、アクションの確率を評価するとき
に、しなければならない２、３の想定がある。

【０１１５】もしアクションを実行するのに必要な、な
んらかの必要条件があれば、アクションが提案されると
きに、それらが利用可能になると常に考える。したがっ
て、アクションが問題を解決する確率を評価するとき
に、必要条件の利用可能性を考慮に入れる必要はない。
必要条件の利用可能性は、ユーザがそれを実行できない
か、または実行したくないことを報告することでアクシ
ョンをスキップさせることによって処理される。

【０１１６】アクションが、疑わしいコンポーネントを
別のものに取り替えることを含む場合、新しいコンポー
ネントが故障していて同じ問題を引き起こす、わずかな
可能性がある。たとえ、この確率をしばしば無視するこ
とができるとしても、アクションが問題を解決する確率
を評価する際に考慮に入れる必要がある。もし取り替え
コンポーネントが故障していて同じ問題を引き起こせ
ば、ユーザは、アクションが役に立たなかったことをト
ラブルシューティングシステムに入力しようとする。そ
のときシステムは、取り替えコンポーネントが故障であ
りえたので、アクションが解決することができる原因を
完全に除外すべきではない。先に説明したように、解決
アクションと情報収集アクションとの間でなされた区別
がある。たとえ情報収集アクションが問題を解決するこ
とができないにしても、確率は、ほとんど同じ方法で集
められる。実際、たとえ情報収集アクションが問題を解
決することができないとしても、それらは、システム上
で実験を行って、構成を変えたときに問題が無くなるか
どうかを見る。そのとき、上記の第１の確率引き出し質
問は、若干違って尋ねられるべきである。すなわち、
「Ｃ_ｉが当該問題の唯一の原因であると想定すると、ア
クションを正確に実行することが新しい構成において問
題を無くさせる確率は、どのくらいか？」である。「薄
いプリント」問題のためのアクションの確率は、下の表
１１に示すようなものである。各アクションの後で、関
連付けられた原因、およびアクションがそれらを解決す
る確率がリストにされる。不正確性要素は、後で検討さ
れる。

【０１１７】

【表１１】

【０１１８】ステップ９０９において、アクションおよ
び質問のコストが見積もられる。

【０１１９】トラブルシューティング・アルゴリズムで
は、次に実行する最適なステップがどれかを判断するた
めに、アクションおよび質問の実行のコストを知る必要
がある。コストは、単一の要素、または複数の要素のど
ちらでも見積もられることができる。実際にはコストが
複数の有意な要素から構成されるので、これらの要素の
それぞれを別々に評価して、その要素を単一のコスト要
素に組み合わせることが、もっとも確実性があり正確な
アプローチに思われる。コストは、多くの要素から構成
される。もっとも有効であると思われる４つの要素が下
に説明される。

【０１２０】第１の要素は、時間である。すなわち、ス
テップを実行するのにかかる時間（分）である。労働
（labor）に費やされる時間は、待つことに費やされる
時間と区別される。待ち時間を労働時間より小さく重み
付け、ほとんど待つことに１０分かかるステップは、絶
え間なく労働に１０分を費やすステップに比べて、より
低いコストを与えられる。時間を見積もるとき、それは
ユーザの母集団で平均化される。あるステップを人より
速く実行することができる経験豊かなユーザがいるが、
最終的な時間の見積もりは、あらゆる種類のユーザで平
均化しなければならない。

【０１２１】第２の要素は、危険性である。すなわち、
ステップを実行するときに、何かを壊すか、または破壊
する危険性（非常に低い、低い、中、高い、または非常
に高い）である。何かを壊す高い危険性を有するステッ
プを提案する前に、最も低い危険性を有するステップを
提案するのが好ましいので、危険性は、ステップを提案
する際に非常に問題にされる。危険性は、何かを壊す危
険性の低い経験豊かなユーザと、より高い危険性を有す
る初心者の両方が存在するユーザの母集団で再び平均化
されなければならない。

【０１２２】第３の要素は、お金である。すなわち、ス
テップの必要品を購入するのに必要とされるお金の額
（非常に低い、低い、中間、高い、または非常に高い）
である。ユーザが必要な必要品の全てを持っているわけ
ではないので、それらを購入しなければならないかもし
れない可能性を有するステップがある。このようなステ
ップは、必要品のいらない類似のステップと比較してよ
り高いコストがかかる。ステップのために必要なお金の
額は、ユーザの母集団で再び平均化されなければならな
い。ユーザの種類に応じて、必要な必要品を持つユーザ
もいれば、それらを購入しなければならないユーザもい
る。

【０１２３】第４の要素は、侮辱である。すなわち、ス
テップが提示されるときにユーザが感じる侮辱の程度
（非常に低い、低い、中間、高い、または非常に高い）
である。経験豊かなユーザが初歩的なステップ（たとえ
ば、プリンタがコンセントに繋がっているかどうかのチ
ェック）を提案される場合、彼は侮辱されたと感じるか
もしれない。したがって、そのようなステップは、侮辱
的ではないステップがシーケンスにおいて先に提案され
ることを可能にするために、少しばかり高いコストを与
えられる。

【０１２４】例えばステップを実行することにおける不
便さなどのような、いくつかの他の考えられうる要素が
存在する。しかしながら、経験によれば、前記の４つの
要素しか実際には必要ではないことが判明している。ス
テップの不便さは、時間および危険性によってだけでな
く（もし不便であれば、より長い時間がかかり、より危
険性が高くなるかもしれない）、ステップをスキップす
る能力によっても部分的に考慮に入れられる。

【０１２５】コスト要素は、１つの数値に組み合わせて
トラブルシューティング・アルゴリズムに役立たせる。
これをするために、危険性、お金、および侮辱の要素を
数値に変換しなければならない。最終的に４つの要素
は、バランスをとって加算されなければならない。どの
ように、これを行うかを判断するために、多くの実験を
実行しなければならない。分野の専門家は、コスト要素
の点で異なるステップを順位付けするためにそれらを尋
ねる必要がある。そのような十分な量の実験から、換算
係数および重み付けが判断されることができる。そのよ
うな実験の１つの例は、たとえば以下のようなものであ
る。

【０１２６】問題を解決するのに同じ確率を有する２つ
のアクションのうち、あなたは第１にどちらを提案した
いですか？ Ａ_１ 時間＝２０、危険性＝中 Ａ_２ 時間＝１０、危険性＝高

【０１２７】印刷システム分野のための時間に相当する
数値への危険性要素の換算は、下記の表１２のようなも
のである。

【表１２】 非常に低い ０ 低 １ 中 ２ 高 ４ 非常に高い ８

【０１２８】その結果の数値は、９を掛けられる。すな
わち、非常に高い危険性を有する０分のステップは、非
常に低い危険性を有する７２（８×９）分のステップに
等しい。

【０１２９】時間に相当する数値へのお金の変換は、下
の表１３のようなものである。

【表１３】 非常に低い（VL） ０ 低（L） １ 中（M） ３ 高（H） １０ 非常に高い（VH） ３０

【０１３０】表１３における結果の数値は、１０を掛け
られる。すなわち、非常に高いお金要素を有する０分の
ステップは、非常に低いお金要素を有する３００分（３
０×１０）のステップに等しい。

【０１３１】侮辱要素は、印刷システムのプロジェクト
において、まれにしか使用されなかった。このため完全
な変換は規定されなかった。低の侮辱要素が指定された
とき、これは１０に変換された。

【０１３２】「薄いプリント」問題のための不正確性お
よびコスト要素は、下の表１４のようなものである（順
番に、不正確性（Ｉ）、時間（Ｔ）、危険性（Ｒ）、お
金（Ｍ）、および侮辱（Ｉ））。

【０１３３】

【表１４】

【０１３４】ステップ９１０において、特別な処理を必
要とするアクションおよび質問が特定され、対処され
る。

【０１３５】要望どおりに実行するトラブルシュータを
得るために、トラブルシューティングのモデルに対して
指定する必要があるいくつかの付加的情報がある。これ
らは、特別な処理を必要とするアクションおよび質問と
して一括して参照される。

【０１３６】このうちの１つは、初期のステップ(initi
al step)である。いくつかの問題では、後の時点でこれ
らを調査し始めることが顧客にとって失礼になるので、
初期に除外されるべきデフォルトの原因（default caus
e）がある。例えば、エラーコードが「トレー２上昇中
（tray2 lifting）」であれば、トレーが上昇するため
の十分な時間を、（しばらく時間がかかるので）ユーザ
が単に待たなかった可能性がある。したがって、ユーザ
が十分長い時間待ったかどうかを最初に尋ね、もしそう
でなければ、彼にそれを教えるのが有利である。それら
は、常に最初に強制されるべきなのでトラブルシューテ
ィングのステップの通常の選択にこれらのステップを含
む理由はない。分野の専門家は、この種のステップを特
定すべきであり、そのようなものとしてそれらをマーク
すべきである。

【０１３７】指定するもう１つの情報は、回避方法（wo
rkaround）である。そのアクションは、問題を解決する
かもしれないことを示す回避方法として分類される。し
かし、その解決策は、納得のゆくものではないかもしれ
ない（例えば、小さなジョブをプリントすることによっ
て、メモリ不足の問題を解決する）。アクションが回避
方法として分類されれば、ユーザは、（もし回避方法が
役に立てば）彼が解決策に満足しているかどうかを確認
される。

【０１３８】指定するもう１つの情報は、コンポーネン
トの取り替え（replacing component）である。アクシ
ョンがコンポーネントを別のものに取り替える場合、こ
れを登録することが重要である。これにより自動化トラ
ブルシュータ（automated troubleshooter）は、コンポ
ーネントが不適当に設置された状況を処理することがで
きる。もしコンポーネントを別なものに取り替えてうま
くいけば、最初にコンポーネントが不適当に設置された
のが原因であるかもしれない。そのためトラブルシュー
タは、これを確認するために再び古いコンポーネントを
再挿入するようにユーザを促すべきである。

【０１３９】指定するもう１つの情報は、不可逆アクシ
ョン(irreversible action)である。そのアクションが
問題を解決したけれども原因が十分に特定されなかった
場合、ユーザは、トラブルシューティングを続けたいか
どうかを問われる。彼が続けることに同意する場合、彼
は、問題が再現するように最後のアクションを元に戻さ
なければならない。実行された最後のアクションが取り
消せない（例えばＰＣの再起動、プリンタの電源を入れ
直すこと）場合、これは可能でない。そのような状況で
は、ユーザは、彼がトラブルシューティングを続けたい
かどうかを問われるべきではない（これが、不可能であ
るので）。したがって分野の専門家は、不可逆なアクシ
ョンを登録すべきである。

【０１４０】指定するもう１つ情報は、包含アクション
（included action）である。アクションは、他のアク
ションを含むことができる。例えばアクションは、プリ
ンタの電源を入れ直すことを含んでいるのが普通であ
る。そのようなアクションが実行される場合、プリンタ
の電源を再び入れ直すように後から被トラブルシュータ
（troubleshootee）に提案すべきではない。したがっ
て、分野の専門家は、アクションが他のアクションを含
むかどうかを登録すべきである。

【０１４１】指定するもう１つの情報は、特別な場合の
ステップ（special-case step）である。特別な場合
（例えば、特定の質問が特定の回答で返答された後、ま
たは特定の質問が特定の回答で返答されなかった場合）
においてしか提案されるべきではないステップがある。
例えば、印刷システム分野では、コンポーネントのメー
カが確認されたときにしか提案されないメーカ固有の特
別なアクションがある。

【０１４２】指定するもう１つの情報は、持続性（pers
istence）である。持続性は、後で実行されるアクショ
ンによって無効にされる古い観測の問題を言う。質問Ｑ
とアクションＡを有する状況がしばしばある。ここでＱ
は、システムのなんらかのプロパティのステータス（st
atus）を要求する。ステータスが所望のものでなけれ
ば、これを修正するためにアクションＡが提案される。
所望の状態にないＱの観測で、トラブルシューティング
は続けられることができない。Ｑの状態は、修正されて
トラブルシュータが有効な情報で動作することを確実に
する。Ａを実行することが特定の状態にＱを修正するよ
うな、ＱとＡの質問とアクションの対（question-actio
n pair）が存在する状況を、分野の専門家に登録させる
ことによって、この状況は、処理されることができる。
その時トラブルシュータは、Ａが実行されれば、Ｑが以
前に観測したものとは無関係に、この状態におけるＱを
自動的に修正することを知る。これは、修復の予測され
るコスト（ＥＣＲ）の演算に組み込まれないので依然と
しておおまかな解決策であることは明らかである。

【０１４３】下記に説明されるオーサリングツール（au
thoring tool）は、ある分野（例えば、印刷システム、
ネットワークシステム、その他）における専門家が、そ
の分野の知識を簡単に入力することを可能にする。この
知識から、モデル化される分野における問題をトラブル
シュートして、初心者／非専門家のユーザを助けること
ができる自動化トラブルシュータが作成される。

【０１４４】オーサリングツールは、その分野における
物理的コンポーネントに対応するモジュールに情報を整
理することによるオブジェクト指向の原理を利用する。
複数のトラブルシュータにおいて、これらのモジュール
を再利用することによって、例えば、必要な時間の削
減、整合性の増大、および保守時間の削減などの利点を
得ることができる。

【０１４５】オーサリングツールは、本質的に上に記述
される知識獲得プロセスを実施する。

【０１４６】本明細書において、オーサリングツールの
ユーザを、オーサ（author；著者）と呼ぶ。オーサリン
グツールで作成されるトラブルシュータのユーザは、被
トラブルシュータ、またはユーザと時々呼ばれる。オー
サリングツールにおいてモデル化されている問題の分野
は、当該装置、またはシステムを表す。オーサリングツ
ールにおけるトラブルシュータの内部表示は、モデルま
たはトラブルシュータの明細（ＴＳＳ：troubleshooter
specification）を表す。

【０１４７】オーサリングツールは、１つの分野におい
て１組のトラブルシュータを作成するために使用され
る。この分野のために、多くのモジュールを再利用する
ことができるような多くの重複があると考えられる。例
えば、プリンタの分野では、定着コンポーネント（fuse
r component）は、多くのエラー状態（例えばスポット
（spot）、低品位の定着（poor fusing）、その他）に
おける原因となる。その分野におけるそれぞれのエラー
状態のために、完全なトラブルシューティング・モデル
が使用される。被トラブルシュータが、経験しているエ
ラー状態を完全に特定することができて、これにより関
連したトラブルシュータが選択されることができると考
える。

【０１４８】モジュールのライブラリは、オーサリング
ツールにおいて確立される。このライブラリが成長し
て、さらに多くのモジュールが加えられるので、新しい
トラブルシューティング・モデルを作成することがより
簡単になる。

【０１４９】オーサリングツールを使用する通常のやり
方は、２、３のトラブルシューティング・モデルを最初
に作成することである。これらからライブラリにおける
最初のモジュールが、後で再利用するために作成され
る。トラブルシューティング・モデルをたくさん追加す
るほど、モジュールがさらにたくさん作成されて、既存
のモジュールが、洗練され、大きくなることができる。

【０１５０】図５は、オーサリングツールのためのメイ
ンインターフェース（main interface）５０を示す。メ
インインターフェース５０は、２つのサイドに分けられ
る。サイド５１は、トラブルシューティング・モデルと
しての機能を果たし、トラブルシューティングを編集す
るために使用される。サイド５２は、ライブラリ・モジ
ュール（library module）およびライブラリ・モジュー
ル・エディタのリストを含む。ライブラリ・モジュール
・エディタは、ライブラリ・モジュールを編集するため
に使用される。トラブルシューティング・モデル・エデ
ィタおよびライブラリ・モジュール・エディタは、ほぼ
同じ機能を有する。両方とも、新しい原因、アクショ
ン、および質問の作成と、既存の原因、アクション、お
よび質問の作成と、これら全ての確率の編集と、並びに
他のエディタからの要素のエクスポートおよびインポー
トと、を可能にする。

【０１５１】領域５３において、メインインターフェー
ス５０のトラブルシューティング・モデル・エディタ
は、新しいトラブルシューティングの明細（ＴＳＳ）の
ロード、現在のＴＳＳのクローズ、新しいＴＳＳの開
始、および後で説明されるさまざまなフォーマットにお
けるＴＳＳのセーブを可能にする。領域５４において、
メインインターフェース５０のライブラリ・モジュール
・エディタは、モジュールのセーブと、新しいモジュー
ルの作成と、モジュールの削除と、モジュール名の変更
と、すばやい検索をするための、原因、アクション、お
よび質問の全ての一覧と、並びに下記に説明される原因
のカテゴリの明細と、を可能にする。

【０１５２】オーサリングツールの構築ブロックは、ラ
イブラリ・モジュールであり、モジュールとも呼ばれ
る。モジュールは、検討中の分野における物理的コンポ
ーネントか、またはソフトウェアなどのような非常に密
接な関連がある情報の領域に対応する。好ましい実施形
態においては、モジュールは、モジュールに対応する物
理的コンポーネントを、機能するものに取り替えれば、
モジュールにおける全ての原因が解決されるように整理
される。モジュールがこのように整理されるときに最適
な再利用が可能になる。すなわち、モジュールを含むエ
ラー状態のために、モジュールにおける全ての原因が通
常使用されることができる。しかしながら、あるエラー
状態では、それらがエラーに関連づけられていないの
で、取り除かれなければならないモジュールにおける原
因がありうる。

【０１５３】モジュールは、一連の新しい原因、並びに
これらの原因に関連するアクションおよび質問を作成す
ることによって、はじめからオーサリングツールで作成
される。もう１つの方法として、モジュールは、完成し
たトラブルシューティング・モデルの部品（piece）を
インポートすることによって作成される。

【０１５４】全てのモジュールは、ライブラリに収めら
れている。検討中のそれぞれの分野（たとえば印刷シス
テム、車、その他）のために、１つのライブラリがあ
る。

【０１５５】モジュールが変更されるとき、その変更
は、モジュールが使用される全てのエラー状態に伝えら
れる。

【０１５６】新しいトラブルシューティング・モデル
は、エラー状態に影響を与えると思われる物理的コンポ
ーネント、または論理領域に対応するモジュールを最初
に組み合わせることによって、作成される。これらのモ
ジュールにおける原因およびトラブルシューティング・
ステップのいくつかは、無関係であるかもしれないの
で、取り除かれなければならない。モデルの構築が完了
したとき、オーサリングツールは、ベイジアン・ネット
ワークとして、（何らかの付加的情報と共に）それを出
力する。モジュール、原因、アクションおよび質問の構
築ブロックは、全て実行中にそれらをランダムに組み合
わせることができるように作成され、その結果が正しい
ベイジアン・ネットワークになることを保証する。この
ベイジアン・ネットワークの構築は、米国特許出願番号
第09/353,727号「AUTOMATED DIAGNOSIS OF PRINTER SYS
TEMS USING BAYESIAN NETWORKS（１９９９／７／１
４）」に記載される。その内容をここで参照して取り込
む。

【０１５７】オーサリングツールにおいて、トラブルシ
ューティング・モデルに関係する情報が指定されること
ができる。具体的には、以下のように指定されることが
できる。

【０１５８】名前：トラブルシューティング・モデルで
表示されるエラー状態の名前。 説明：それが、どのように起きるのかという何らかの情
報を含む正確なエラー状態の説明。 問題観測時間：問題が無くなったかどうかをテストする
のに費やす時間。このテストは、すべてのトラブルシュ
ーティング・ステップの後で実行されなければならな
い。そのため“どのくらい時間を費やすのか”を知るこ
とが大事である。

【０１５９】原因は、もしそれが起きれば、確実にエラ
ー状態をもたらす何らかのイベントまたはプロパティを
表している。知識獲得プロセスにおいて、原因の確率
は、分野の専門家から引き出される。オーサリングツー
ルは、ベイジアン・ネットワークの専門家の存在を必要
とすることなしに、この引き出しプロセスを処理する。

【０１６０】オーサリングツールのためのメインインタ
ーフェース５０から、新しい原因を作成して既存の原因
を編集することが可能である。原因編集インターフェー
ス６０を開いて、新しい原因を作成するか、または古い
原因を編集する。これを図６に示す。名前ボックス６１
は、オーサが原因の名前を編集することを可能にする。
副原因チェックボックス６２は、その原因が別の原因の
副原因であるかどうかを指定する。確率の引き出しを簡
単にするために、原因は、根本のそれ自身の問題、その
ときの原因、それらの副原因、その他、と共にツリーに
整理される。確率ボックス６３は、オーサが原因の確率
を編集するのを可能にする。原因の確率は、下記に説明
される原因確率エディタで指定されることもできる。

【０１６１】説明ボタン６４を選択することは、説明編
集インターフェース１６０を持ってくる。これを図１６
に示す。説明ボックス１６１において、原因の説明を与
えることができる。原因の名前は、被トラブルシュータ
が原因の性質を理解するのに十分ではない。そのような
状況では、より長い説明が有益である。説明は、それが
完成したトラブルシュータのユーザに提示されることが
できるように書かれる。ボックス１６２において、原因
についての情報をさらに与える注釈(notes)を与えるこ
とができる。これは、完成したトラブルシュータのユー
ザによって見られるべきではないトラブルシュータのオ
ーサに関連した情報のために使用される。カテゴリボタ
ン６５（図６に示す）は、後で簡単に原因を参照するた
めに原因を分類する１つまたは複数のカテゴリを、オー
サが指定したいときに選択される。このプロセスを、さ
らに下で説明する。

【０１６２】消耗品チェックボックス６６は、オーサ
が、原因が消耗品であることをマークすることを可能に
する。すなわち、顧客は、それを使い果たしたら取り替
える責任がある。これは、トラブルシュータの終了メッ
セージに関係がある。もっとも可能性の高い原因が、損
耗（worn out）か、または欠陥のある消耗品であると判
断されれば、顧客は、それを自分で取り替えなければな
らない。可能性のある原因が非消耗品のコンポーネント
であれば、顧客は、さらなる支援を求めなければならな
い。

【０１６３】自動データ収集チェックボックス６７は、
当該装置に直接問い合わせることによって、原因につい
ての決定的な情報を潜在的に得ることができることを、
オーサがマークするのを可能にする。自動データ収集
は、通常、トラブルシュータのユーザから情報を得るよ
り、ずっと効率的である。ＰＣの再起動による修復チェ
ックボックス６８は、パーソナルコンピュータ（ＰＣ）
を再起動することによって、この原因を直すことができ
ることを、オーサがマークすることを可能にする。この
情報は、トラブルシュータにおいて、ＰＣの再起動がう
まく問題を解決しないときに、どの原因がもはや有効で
ないのかを判断するのに関係する。

【０１６４】プリンタの電源を入れなおすことによる修
復チェックボックス６９は、ＰＣの電源を入れなおすこ
とによって、この原因を修正することができることを、
オーサがマークすることを可能にする。環境依存性ボッ
クス７８は、オーサがシステムにおけるコンポーネント
のバージョンまたはモデルへの原因の依存性を指定する
ことを可能にする。さらに下で論議されるように、これ
は、移行（migration）を容易にすることを目的とす
る。

【０１６５】顧客に適した名前ボックス（customer-sui
ted name box）７９は、トラブルシューティング・ツー
ルのユーザに示される原因の名前をオーサが指定するこ
とを可能にする。これは、原因の名前が顧客にとって適
していない状況において適切にすることができる。

【０１６６】原因削除ボタン７７は、オーサがトラブル
シューティング・モデルから原因を削除することを可能
にする。

【０１６７】原因の確率は、２つのやり方で引き出され
ることができる。先に述べたように、原因の確率は、原
因編集インターフェース６０を使用することによって、
１回に１つ指定されることができる。

【０１６８】原因の確率は、図７に示す原因確率編集イ
ンターフェース７０を使用することによって、より効率
的に指定されることができる。ボックス７１において、
オーサは、ツリーとして構成される原因のビューを与え
られる。オーサが原因をダブルクリックした後で、ボッ
クス７１において、この原因として同じ親を有する同じ
レベル上の原因の全て、およびそれらに関連づけられた
確率がボックス７２に示される。オーサは、それらの親
原因を与えられる（最上部のレベルの原因の場合、問題
を与えられる）これらの原因に確率を割り当てることが
できる。確率は、それらが合計で１００％になるように
割り当てられ、必要なときに正規化される。好ましい実
施形態において、原因確率編集インターフェース７０
（およびオーサリングツールにおける他の編集インター
フェース）は、分野の専門家がそれで作業することを好
むので確率の代わりにパーセンテージで作業される。

【０１６９】オーサは、原因を１つまたは複数のカテゴ
リに分類することを指定するための能力を、原因編集イ
ンターフェース６０において有する。モデル化されてい
るシステムにおける論理領域またはプロパティに対応す
るカテゴリは、モジュールの構造に反映されない。モジ
ュールは、物理的コンポーネントまたは論理領域に対応
して通常、構造化される。しかしながら、原因をグルー
プ化する他のやり方があり、これらは、カテゴリで取り
込まれることがある。

【０１７０】カテゴリ編集インターフェース８０（図８
に示す）は、新しいカテゴリを作成するか、または既存
のカテゴリを削除するのに使用される。印刷システム分
野におけるカテゴリの例は、ソフトウェア、ケーブル、
ネットワーク、ハードウェア、アクセサリ、および設定
である。カテゴリ内のすべての原因が関連するエラー状
態が存在すれば、カテゴリは、作成されるだけではな
い。カテゴリは、原因の参照を容易にするためにも作成
される。

【０１７１】本発明の好ましい実施形態では、ウィンド
ウは、ライブラリ・モジュールにおける全ての原因のリ
ストを提示する。このウィンドウは、１つまたは複数の
カテゴリを設定することを可能にし、全ての指定された
カテゴリに分類される原因が示される。この機能で、原
因を見つけることがより速くなる。

【０１７２】アクションは、問題を解決するか、または
問題を一時的に取り除く可能性を有するステップであっ
て、被トラブルシュータが実行することのできるステッ
プである。解決アクションは、問題を解決する潜在的能
力を有し、それ以上のアクションを必要としない。情報
収集アクションは、システムに何らかのテストを行うこ
とによって、問題を取り除く（それを解決することはな
いが）潜在的能力を有している。２種類のアクション
（問題の原因の何らかを解決することができるアクショ
ン、および原因に関する情報を提供することができるア
クション）の間の区別することが重要である。解決アク
ションおよび情報収集アクションは、最良の次のステッ
プを選択するために、別々に処理される。好ましい実施
形態では、情報収集アクションは、質問と同じやり方で
扱われる。

【０１７３】オーサリングツールのためのメインインタ
ーフェース５０（図５に示す）は、サイド５１またはサ
イド５２に表示するようなアクションをダブルクリック
することによって、新しいアクションの作成および既存
のアクションの編集を可能にする。これらのアクション
は、図９に示すアクション編集インターフェース９０を
開く。

【０１７４】アクション編集インターフェース９０は、
トラブルシューティング・プロセスに関するアクション
に関連する全ての知識の明細を与える。アクションの確
率は、下に記述する特別アクション確率編集インターフ
ェースで設定されることもできる。

【０１７５】ボックス９１において、アクションの名前
が指定される。ボックス９２において、アクションの種
類、すなわち、アクションが解決アクションか、または
情報収集アクションであるかのを指定する。

【０１７６】チェックボックス９３において、オーサ
は、アクションが順々に強制されるかどうかを指定する
ことができる。これは、実際のトラブルシューティング
を始める前に常に実行されるべきアクションに関連する
（例えば、環境についてのなんらかの初期の信念を確実
にするために）。オーサは、そのアクションが、第１の
アクションのうちの１つとして強制されるべきであるこ
とを指定することができ、この強制的なシーケンスにお
ける番号を、それに与えることができる。

【０１７７】回避方法チェックボックス９４において、
オーサは、アクションが回避方法であるかどうかを指定
することができる。回避方法は、長期における満足を与
えないかもしれない、問題に対する解決策を、被トラブ
ルシュータに提示する。そのため、彼は、これらのアク
ションに対するトラブルシュータの解決策に満足してい
るかどうかを尋ねられる。

【０１７８】説明ボタン９５を選択することは、説明編
集インターフェース１６０を持ってくる。これを図１６
に示す。説明ボックス１６１において、アクションの説
明を与えることができる。アクションの名前は、被トラ
ブルシュータがアクションの性質を理解するのにしばし
ば十分ではない。このような状況では、長い説明が有益
である。説明は、それが完成したトラブルシュータのユ
ーザに提示されるように書かれる。ボックス１６２にお
いて、アクションについてのさらなる情報を与える注釈
が与えられることができる。これは、完成したトラブル
シュータのユーザによって見られるべきではないトラブ
ルシュータのオーサに関する情報のために使用されるこ
とができる。

【０１７９】コスト編集ボタン９６は、図１５に示すコ
スト編集インターフェース１５０を開く。コスト編集イ
ンターフェース１５０は、アクションおよび質問のため
に使用される。コスト編集インターフェース１５０のボ
ックス１５１において、オーサは、不正確性要素を指定
することができる。不正確性要素は、被トラブルシュー
タが、気づかずに正しくないアクションを実行すること
の可能性である。

【０１８０】コスト編集インターフェース１５０を使用
して、オーサは、４つのコスト・コンポーネントを指定
することもできる。すなわち、時間、危険性（ステップ
を実行するときに何か他のものを壊す危険性）、お金、
侮辱（経験豊かな被トラブルシュータに対して侮辱的か
もしれないステップのため）である。

【０１８１】ボックス１５２において、時間は、分で測
定される数値として指定される。チェックボックス１５
３は、その時間が、待つために費やされるか、または活
動的な労働に費やされるのかを指定するために使用され
る。これは、総コストの演算においても使用される。不
正確性要素は、５つの値（非常に低い、低、中間、高、
および非常に高い）の目盛り上でスライダ（slider）１
５７を使用して指定される。危険性要素は、５つの値の
スケール上でスライダ１５４を使用して指定される。お
金要素は、５つの値のスケール上でスライダ１５５を使
用して指定される。侮辱性要素は、５つの値のスケール
上でスライダ１５６を使用して指定される。

【０１８２】図９に示すアクション編集インターフェー
ス９０において、追加情報ボタン９７の選択は、追加情
報エディタ１００を持ってくる。これを図１０に示す。
包含アクションウィンドウ１０１は、現在のアクション
に含まれる全てのアクションの明細を与える。これは、
トラブルシュータに非常に関連し、他のアクションの一
部としてすでに実行されたアクションを提案しないこと
をトラブルシュータが知る。

【０１８３】相互排他アクションウィンドウ１０２は、
現在のアクションに相反するアクションの指定を可能に
する。例えば、アクションＡが、アクションＢに相反す
るものとして指定されれば、アクションＡは、アクショ
ンＢの後で提案されることができない。そしてその逆も
同様である。

【０１８４】領域１０３において、オーサは、特定の質
問が特定の回答で返答された後でしか、アクションを提
案することができないことを指定することができる．こ
れは、アクションを提案する前に、前提条件が有効であ
る、および／または履行されていることを確実にするの
に関連する。回答と共に質問が指定されることができ
る。必要な回答として「任意（any）」を指定すること
が可能である。これは、アクションを提案する前に、質
問を尋ねなければならないことを示すが、その回答は、
重要ではない。領域１０４において、オーサは、特定の
質問が特定の回答で返答された後で、そのアクションが
提案されることができないことを指定することができ
る。回答として「任意」を指定することが再び可能であ
る。

【０１８５】領域１０５において、オーサは、アクショ
ンが実行された場合に特定の状態（回答）に修正される
質問を指定することができる。これは、基礎をなすベイ
ジアン・ネットワークにおいて、つじつまの合わない情
報を回避するのに使用されることができる。例えば、ト
ラブルシュータが質問「プリンタの電源がはいっている
か？」を提案して、回答「いいえ」を受信すれば、次の
論理的ステップは、アクション「プリンタの電源をいれ
てください」を提案することになり、この後で、最初の
質問に対する回答がもはや有効で無くなる。これは、質
問「プリンタの電源がはいっているか？」が、アクショ
ンを実行した後で、「はい」の状態に修正されなければ
ならないことを、ここで指定することによって処理する
ことができる。

【０１８６】領域１０６において、オーサは、アクショ
ンが特定のコンポーネントを動かすことを含むかどうか
を指定することができる。もしこの場合、アクション
は、不適当に設置されているこのコンポーネントの原因
を潜在的に解決する。これを指定することは、アクショ
ンが役にたつ場合コンポーネントが不適当に設置されて
いるのが原因かどうかを見るために、コンポーネントを
再びもとの場所に戻すように被トラブルシュータに頼む
ことを、トラブルシュータに知らせるので重要である。

【０１８７】環境依存性ボックス１０７は、オーサがシ
ステムにおけるコンポーネントのバージョンまたはモデ
ルへの原因の依存性を指定することを可能にする。これ
は、移行を容易にすることを目的とする。これをさらに
下に説明する。

【０１８８】チェックボックス１０８は、アクションが
プリンタの電源を入れなおすかどうかを指定するため
に、オーサによって使用される。プリンタの電源を入れ
なおすことによって解決される原因の知識と組み合わせ
た場合、これは、トラブルシュータがこれらのアクショ
ンおよび原因を正確に扱うことを可能にする。

【０１８９】チェックボックス１０９は、アクションが
パーソナルコンピュータを再起動することを含むかどう
かをオーサが指定することを可能にする。

【０１９０】チェックボックス１１９は、アクションが
不可逆な場合を指定するのに使用される。不可逆なアク
ションが問題を解決する場合、アクションを元に戻すこ
とによって問題を再現することが不可能なので、トラブ
ルシュータは、トラブルシューティングを続けたいかど
うかを被トラブルシュータに尋ねない。

【０１９１】自動データ収集チェックボックス１１８
は、当該装置に直接問い合わせることによって、アクシ
ョンについての決定的な情報が、潜在的に得られること
をオーサがマークすることを可能にする。自動データ収
集は、トラブルシュータのユーザから情報を得るのと比
較して、より効率的である。

【０１９２】図９に示すアクション編集インターフェー
ス９０において、原因解決ウィンドウ９９は、アクショ
ンによって解決される原因、およびそれらが解決される
確率の指定を可能にする。それは、新しい原因を加える
か、確率を編集するか、または原因を取り除くことが可
能である。原因解決ウィンドウ９９に表示された原因を
ダブルクリックすることは、アクション確率エディタ１
１０を持ってくる。これを図１１に示す。アクション確率
エディタ１１０は、アクションが原因を解決する確率を
編集することを可能にする。アクション確率エディタ
は、分野の専門家に質問を与えて、これらの確率を引き
出すことを履行する。すなわち、「<原因>が、<問題>の
唯一の原因であると想定するとき、<アクション>のステ
ップを正確に実行することが問題を解決する確率は、ど
のくらいか？」である。

【０１９３】図９に示すアクション編集インターフェー
ス９０において、アクション除去ボタン（remove actio
n button）９８を選択することは、オーサがトラブルシ
ューティング・モデルからアクションを取り除くことを
可能にする。

【０１９４】好ましい実施形態では、アクションの確率
は、全てのアクションの一覧を与える全体アクション確
率エディタ（global action probability）を通じて編
集されることもできる。オーサは、確率を編集したいア
クションを選択することができる。彼は、選択したい特
定の確率を、編集か、または選択することができ、アク
ションによって解決される原因の全ての確率を１回に１
つ引き出すことができる。

【０１９５】質問は、より低い解決の予測されるコスト
でアクションのシーケンスを演算するのに関連する、エ
ラー状態についての情報を提供するトラブルシューティ
ング・ステップである。２種類の質問（一般質問および
症状の質問）が存在する。一般質問は、原因の確率を再
構成するエラー状態についての情報を集める。質問を与
えられたとき、原因の条件付き確率は、これらの質問の
ために引き出される。症状の質問は、原因の症状につい
ての情報を集める。すなわち、原因を与えられたとき、
質問の条件付き確率が引き出される。オーサリングツー
ルのためのメインインターフェース５０（図５に示す）
から、両方の種類の新しい質問の作成、および既存の質
問の編集をすることが可能である。新しい質問は、メイ
ンインターフェース５０から、新しい質問ボタンを選択
することによって作成される。既存の質問を編集するこ
とは、メインインターフェース５０内のウィンドウに表
示される質問をダブルクリックすることによって成し遂
げられる。この両方の動作が対応する質問エディタを開
く。

【０１９６】一般質問編集インターフェース１２０を、
図１２に示す。ボックス１２１において、オーサは、質
問の名前を指定することができる。回答ボックス１２２
において、オーサは、回答の番号およびこれらの回答の
名前を指定することができる。

【０１９７】説明ボタン１２３を選択することは、説明
編集インターフェース１６０を持ってくる。これを図１
６に示す。説明ボックス１６１において、問題の説明
は、与えられることができる。問題の名前は、被トラブ
ルシュータが原因の性質を理解するのに十分ではない。
このような状況では、より長い説明が有益である。説明
は、それが完成したトラブルシュータのユーザに提示さ
れるように書かれる。ボックス１６２において、原因に
ついて更なる情報を与える注釈が与えられることができ
る。これは、完成したトラブルシュータのユーザによっ
て見られるべきではないトラブルシュータのオーサに関
連する情報のために使用される。

【０１９８】編集コストボタン１２４を選択すること
は、図１５に示すコスト編集インターフェース１５０を
開く。コスト編集インターフェース１５０は、アクショ
ンおよび質問のために使用され、より詳しく前で説明し
た。

【０１９９】追加情報ボタン１２５の選択は、質問用の
追加情報エディタを持ってくる。これは、図１０に示す
アクションのための追加情報エディタと類似のものであ
る。

【０２００】質問用の追加情報エディタは、「質問後の
み（only after question）」領域を含み、この領域
で、特定の質問が特定の回答で返答された後でしか質問
を尋ねることができないことをオーサが指定することが
できる。これは、質問を尋ねる前に、前提条件が有効で
ある、および／または履行されていることを確実にする
のに関連する。回答とともに質問は、指定されることが
できる。必要な回答として「任意（any）」を指定する
ことが可能である。これは、新しい質問を尋ねる前にそ
の質問を尋ねなければならないことを示すが、その回答
は重要ではない。

【０２０１】質問用の追加情報エディタは、「質問後で
はない（not after question）」領域を含み、この領域
で、オーサは、現在の質問に相反するアクションまたは
質問を指定することができる。例えば、質問Ａが質問Ｂ
に相反するとして指定されれば、次に質問Ａは、質問Ｂ
の後で提案されることができない。そしてその逆もまた
同様である。

【０２０２】質問用の追加情報エディタは、「環境への
依存性」領域を含み、この領域で、オーサは、システム
におけるコンポーネントのバージョンまたはモデルへの
質問の依存性を指定することができる。これは移行を容
易にすることを目的とする。これを、下でさらに説明す
る。

【０２０３】質問用の追加情報エディタは、自動データ
収集チェックボックスを含む。このチェックボックス
は、当該装置に直接問い合わせることによって、質問に
ついての決定的な情報を潜在的に得ることを、オーサが
マークすることを可能にする。自動データ収集は、トラ
ブルシュータのユーザから情報を得るのと比較すると、
より効率的である。

【０２０４】質問用の追加情報エディタは、「終了トラ
ブルシューティング」チェックボックスを含む。このチ
ェックボックスは、あるやり方で質問が回答された場
合、トラブルシューティング・プロセスを終了すべきで
あることをオーサが指定することを可能にする。

【０２０５】図１２に示す一般質問編集インターフェー
ス１２０は、質問が連続的に強制されるかどうかを、オ
ーサが指定することを可能にするチェックボックス１２
６も含む。これは、実際のトラブルシューティングが開
始される前に常に尋ねるべき質問に、時々関係する（例
えば、環境についての何らかの初期的な信念を確実にす
るため）。オーサは、アクションの質問が最初の質問の
うちの１つとして強制されることを指定することがで
き、この強制的シーケンスにおける番号をそれに与える
ことができる。

【０２０６】質問除去ボタン１２７は、オーサがトラブ
ルシューティング・モデルから問題を削除するのを可能
にする。

【０２０７】質問に対する回答の確率も、指定されるこ
とができる。ボタン１２８は、確率の正規化を可能にす
る。

【０２０８】質問に対してとりうる回答のそれぞれを与
えられるとき、影響を受ける原因がウィンドウ１２９に
おいて指定されることができる。影響を受ける原因のた
めに、質問に対する回答のそれぞれを与えられた原因の
条件付き確率が指定されなければならない。確率は、正
しくバランスをとられなければならない。そのため全て
の組み合せが許されるわけではない。質問の確率のバラ
ンスをとるために使用される数式上のバックグラウンド
になる情報のために、米国特許出願番号第09/353,727号
「AUTOMATED DIAGNOSIS OF PRINTER SYSTEMS USING BAY
ESIAN NETWORKS（１９９９／７／１４）」を参照する。
原因は、影響を受ける原因のリストから取り除かれるこ
とができる。

【０２０９】ウィンドウ１２９にリストにされた原因の
確率の１つがダブルクリックされれば、確率変更編集イ
ンターフェース１３０を開く。これを図１３に示す。確
率変更編集インターフェース１３０は、ボックス１３１
で原因の名前、ボックス１３２で質問の名前、ボックス
１３３で状態、およびボックス１３４で古い確率を表示
する。新しい確率は、ボックス１３５に入れられること
ができる。

【０２１０】症状の質問編集インターフェース１４０を
図１４に示す。ボックス１４１において、オーサは、質
問の名前を指定することができる。ボックス１４２にお
いて、オーサは、回答（状態）の番号、およびこれらの
回答の名前を指定することができる。

【０２１１】説明ボタン１４３の選択は、説明編集イン
ターフェース１６０を持ってくる。これを図１６に示
す。説明ボックス１６１において、質問の説明は、与え
られることができる。問題の名前は、被トラブルシュー
タが原因の性質を理解するのに十分ではなく、このよう
な状況では、より長い説明が有益である。説明は、それ
が完成されたトラブルシュータのユーザに提示されるよ
うに書かれる。ボックス１６２において、原因について
のさらなる情報を与える注釈が与えられることができ
る。これは、完成されたトラブルシュータのユーザによ
って、見られるべきではないトラブルシュータのオーサ
に関する情報のために使用されることができる。

【０２１２】編集コストボタン１４４の選択は、図１５
に示すコスト編集インターフェース１５０を開く。コス
ト編集インターフェース１５０は、アクションおよび質
問の両方のために使用され、より詳細に上で説明され
た。

【０２１３】相互排他ボタン１４４を選択することは、
オーサが現在の質問と相反するアクションまたは質問を
指定することを可能にする。例えば、質問Ａが質問Ｂと
相反するものとして指定されれば、質問Ａは、質問Ｂの
後で提案されることはできない。その逆も同様である。

【０２１４】追加情報ボタン１４５の選択は、質問のた
めの追加情報エディタを持ってくる。これは、図１０に
示すアクションのための追加情報エディタと類似のもの
である。

【０２１５】チェックボックス１４６は、問題が次々に
強制されるかどうかをオーサが指定することを可能にす
る。これは、実際のトラブルシューティングを開始する
前に、常に問われるべき質問に、時々関係する（例え
ば、環境についての何らかの初期的信念を確実にするた
め）。オーサは、アクションの質問が最初の質問のうち
の１つとして強制されることを指定することができ、こ
の強制的シーケンスにおける番号をそれに与えることが
できる。

【０２１６】質問除去ボタン１４７は、オーサがトラブ
ルシューティング・モデルから問題を削除することを可
能にする。

【０２１７】領域１４８において、原因を与えられた状
態（回答）の原因および確率が示される。質問に対する
回答に影響を持つ原因は、関連する原因のリストに加え
られるか、またはリストから取り除かれることができ
る。このリスト上の原因のそれぞれのために、原因に対
する回答のそれぞれのための条件付き確率は、原因が問
題の唯一の原因であることを与えられるとき、指定され
る。このリスト上にない原因のために、質問に対する回
答のためのデフォルトの条件付き確率は、ボックス１４
９を使用して指定されることができる。デフォルトの条
件付き確率は、実際の原因がリスト上にない場合の質問
に対する回答のそれぞれの確率である。１セットのデフ
ォルトの確率しか指定することができないので、これら
の確率は、リストにされない原因に対して同じにすべき
である。

【０２１８】上で説明したインターフェースエディタ
は、データ構造体を構築するために使用される。２つの
メインデータ構造体は、ライブラリ・データ構造体およ
び現在のトラブルシュータ・モデルである。

【０２１９】現在のトラブルシュータ・モデルは、表１
５に示すようなデータ構造体を有する。

【表１５】モデル ・ 名前 ・ 原因のリスト ・ アクションのリスト ・ 質問のリスト ・ 問題観測時間

【０２２０】ライブラリは、下の表１６に示すようなデ
ータ構造体を有する。

【表１６】ライブラリ ・ モジュールのリスト ・ カテゴリのリスト

【０２２１】モジュールは、下の表１７に示すようなモ
デルと同じ構成を持つ。

【表１７】モジュール ・ 名前 ・ 原因のリスト ・ アクションのリスト ・ 質問のリスト ・ 問題観測時間

【０２２２】原因は、下の表１８に示すようなデータ構
造体を有する。

【表１８】

【０２２３】確率は、原因それ自身と同じレベル上で他
の原因と共に正規化されて保持される。親原因が指定さ
れなければ、その原因は、原因階層の最上部に置かれ
る。親原因が指定されれば、その原因は、原因の副原因
となる。

【０２２４】アクションは、下の表１９のようなデータ
構造体を有する。

【０２２５】

【表１９】

【０２２６】原因と確率の対のリストは、アクションに
よって解決される原因のリストであり、原因を想定し
て、アクションが問題を解決することができる確率を含
む。

【０２２７】一般質問は、下の表２０に示すようなデー
タ構造体を有する。

【表２０】

【０２２８】原因、回答および確率のリストは、質問に
対してとりうる回答のそれぞれを条件とする原因のそれ
ぞれのために確率を含む。

【０２２９】症状質問は、下の表２１に示すようなデー
タ構造体を有する。

【表２１】

【０２３０】原因、回答および確率のリストは、原因の
それぞれを条件とする質問に対する各回答のための確率
を含む。

【０２３１】前述の議論は、単なる典型的な方法および
実施形態を、開示および説明している。本技術に精通す
る当業者によって、よく理解されるように、本発明は、
ここに述べられる精神および基本的特徴から逸脱するこ
となしに、他の特定の形態で実施されることができる。
したがって、本発明の開示は、請求項に述べる本発明の
範囲の実例を示すことを目的とするが、その範囲に制限
されることはない。

【０２３２】この発明は、例として次の実施形態を含
む。 （１）製品（２０９、２１０）のための自動化トラブル
シュータの構築において、オーサを支援するオーサリン
グツールであって、製品の障害の原因に関する情報を、
オーサが原因データ構造体に置くことを可能にする原因
編集インターフェース（６０）と、製品の障害を直すの
にとるアクションに関する情報を、オーサがアクション
データ構造体に置くことを可能にするアクション編集イ
ンターフェース（９０）と、製品の障害の原因を特定す
るのを助けるために製品のユーザに尋ねる質問に関する
情報を、オーサが質問データ構造体に置くことを可能に
する質問編集インターフェース（２０９、２１０）と、
を含む前記オーサリングツール。

【０２３３】（２）さらに、オーサリングツールがモジ
ュール（５２）のライブラリを含み、少なくとも１つの
モジュールが、製品（２０９、２１０）のコンポーネン
トについてのトラブルシューティングの情報を含む
（１）に記載のオーサリングツール。

【０２３４】（３）原因に関する情報が、原因の名前
（６１）、原因の親（６２）、原因の説明（６４）、お
よび故障のソースである原因の確率（６３）、のカテゴ
リに関連する上記（１）に記載のオーサリングツール。

【０２３５】（４）原因に関する情報が、さらに、原因
のカテゴリ（６５）、環境への依存性（７８）、および
顧客が、この原因に関する情報にアクセスすることにな
っていないという表示、のカテゴリに関連する（３）に
記載のオーサリングツール。

【０２３６】（５）アクションに関する情報が、アクシ
ョンの名前（９１）、アクションの説明（９５）、アク
ションによって解決される原因（９９）、指定された原
因をアクションが解決する確率（９９）、アクションが
情報収集のためのものか潜在的な解決策であるかどうか
の表示（９２）、アクションをとることのコスト（９
６）、およびアクションに対する回答の信頼、のカテゴ
リに関連する（１）に記載のオーサリングツール。

【０２３７】（６）アクションに関する情報が、さら
に、アクションが他のアクションの前に取られるべきか
どうかに関する表示、アクションが回避方法であるかど
うかに関する表示（９４）、アクションに含まれる付加
的アクション、指定された質問が回答された後でしかア
クションが実行されることができないかどうか、および
指定された質問が回答された後でアクションが実行され
ることができないかどうか、のカテゴリに関連する
（５）に記載のオーサリングツール。

【０２３８】（７）質問に関する情報が、質問の名前
（１２１，１４１）、質問の説明（１２３、１４３）、
回答の番号（１２２，１４２）、回答の名前、質問に対
する回答を見つけることのコスト（１２４，１４４）、
および質問に対する回答の信念、のカテゴリに関連する
（１）に記載のオーサリングツール。

【０２３９】（８）質問に関する情報が、さらに指定さ
れた質問が回答された後でしか、質問が実行されること
ができないかどうか、指定された質問が回答された後
で、質問が実行されることができないかどうか、他の質
問の前に、質問が尋ねられるべきかどうかに関する表
示、および質問が症状質問か、または一般質問かどう
か、のカテゴリに関連する（７）に記載のオーサリング
ツール。

【０２４０】（９）質問に関する情報が、特に症状質問
に関連して、さらに症状の原因（１４８）、症状をもた
らすことができる原因を条件とする質問に対する回答の
確率（１４８）、および症状をもたらすことができる原
因がないことを条件とする質問に対する回答の確率（１
４８）、のカテゴリに関連する（７）に記載のオーサリ
ングツール。

【０２４１】（１０）質問に関する情報が、特に一般質
問に関連して、さらに、質問に対する回答の事前の確率
（１２９）、質問に対する回答によって影響を受ける原
因（１２９）、および、質問に対する回答のそれぞれを
条件とする影響を受ける原因の確率、のカテゴリに関連
する（７）記載のオーサリングツール。

【図面の簡単な説明】

【図１】図１は、本発明の好ましい実施形態に従うトラ
ブルシューティング環境の概要を示すブロック図であ
る。

【図２】図２は、本発明の好ましい実施形態に従うウェ
ブサーバの簡略化したブロック図である。

【図３】図３は、本発明の好ましい実施形態に従う、ト
ラブルシューティング・プロセスで使用される顧客のパ
ーソナルコンピュータ内のコンポーネントの簡略化した
ブロック図である。

【図４】図４は、本発明の好ましい実施形態に従う、知
識獲得を実行するステップの概要を示すフロー図であ
る。

【図５】図５は、本発明の好ましい実施形態に従う、オ
ーサリングツールのためのメインインターフェースを示
す。

【図６】図６は、本発明の好ましい実施形態に従う、原
因の編集のためのインターフェースを示す。

【図７】図７は、本発明の好ましい実施形態に従う、原
因確率エディタのためのインターフェースを示す。

【図８】図８は、本発明の好ましい実施形態に従う、原
因カテゴリ・エディタのためのインターフェースを示
す。

【図９】図９は、本発明の好ましい実施形態に従う、ア
クション編集のためのインターフェースを示す。

【図１０】図１０は、本発明の好ましい実施形態に従
う、アクション確率エディタのためのインターフェース
を示す。

【図１１】図１１は、本発明の好ましい実施形態に従
う、一般質問エディタのためのインターフェースを示
す。

【図１２】図１２は、本発明の好ましい実施形態に従
う、確率変更エディタのためのインターフェースを示
す。

【図１３】図１３は、本発明の好ましい実施形態に従
う、症状質問エディタのためのインターフェースを示
す。

【図１４】図１４は、本発明の好ましい実施形態に従
う、説明エディタのためのインターフェースを示す。

【図１５】図１５は、本発明の好ましい実施形態に従
う、コスト・エディタのためのインターフェースを示
す。

【図１６】図１６は、本発明の好ましい実施形態に従
う、追加情報エディタのためのインターフェースを示
す。

【符号の説明】

２００ ウェブサーバ ２０１ プリンタシステム・トラブルシュータ ２０２ インターネット ２０５ 顧客パーソナルコンピュータ（ＰＣ） ２０６ ウェブブラウザ ２０９ プリンタサーバ ２１０ プリンタ

Claims (1)

【特許請求の範囲】
1. 【請求項１】製品のための自動化トラブルシュータの構
   築において、オーサを支援するオーサリングツールであ
   って、 製品の障害の原因に関する情報を、オーサが原因データ
   構造体に置くことを可能にする原因編集インターフェー
   スと、 製品の障害を直すのにとるアクションに関する情報を、
   オーサがアクションデータ構造体に置くことを可能にす
   るアクション編集インターフェースと、 製品の障害の原因を特定するのを助けるために製品のユ
   ーザに尋ねる質問に関する情報を、オーサが質問データ
   構造体に置くことを可能にする質問編集インターフェー
   スと、を含む前記オーサリングツール。