JPH05298210A - コンピュータ・システムのサービス・ネットワークへのコンピュータ・システムの自動登録 - Google Patents

Abstract

(57)【要約】 【目的】コンピュータ・システムのサービス・ネットワ
ークにあるコンピュータ・システムを自動的に登録す
る。 【構成】サービス・ネットワークが、複数のコンピュー
タ・システムを互いに接続させる。コンピュータ・シス
テムは、「サービス要求装置」（ＳＲ）、「サービス提
供装置」（ＳＰ）、または両者の混成物のいずれかであ
る。このサービス・ネットワークは、コンピュータ・シ
ステムをサービス・ネットワークに追加する登録処理に
よって構築される。すでにネットワーク内にあるＳＰ
は、そのネットワークへのＳＲの登録を開始することが
できる。さらに、ＳＲは、ネットワークへの登録の要求
を開始することができる。このような要求が開始された
場合、自動的に又は人間の介入によって承認を受けなけ
ればならない。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、データ処理の分野に関
するものである。具体的に言うと、本発明は、コンピュ
ータ・システムのサービス・ネットワークへのコンピュ
ータ・システムの自動登録を提供するものである。

【０００２】

【従来の技術】下記の同時係属の特許出願は、本出願人
に譲渡され、本出願と同日に提出され、関連している。 「コンピュータ・システム用の柔軟なサービス・ネット
ワーク」 「コンピュータ・システムのサービス・ネットワーク内
のコンピュータ・システム上の問題の解決の追跡方法」 「コンピュータ・システムのサービス・ネットワーク内
のコンピュータ・システムの問題予防方法」

【０００３】中型およびメインフレームのデータ処理シ
ステムのサービスは、データ処理業界の主要な分野であ
る。製造業者または大企業は、新システムの販売または
開発と同数の人員を、修理とサービスのために使ってい
る可能性がある。サービスには、サービス担当員、部品
目録、ソフトウェアおよび物理的設備の大規模なネット
ワークが必要である。皮肉なことに、データ処理システ
ムのサービスは、人間の労働と精神的労力に頼るところ
が大きい。

【０００４】米国特許第４６５４８５２号明細書では、
データ処理システムのより自動化された修理に向かって
１歩進んだ試みが提案されている。この特許を用いる
と、操作員が、システム自体に記憶された問題判別手順
（ＰＤＰ）を実行できるようになる。ＰＤＰはそれ自体
で、システム内にどんな構成要素が存在するかを決定
し、これらに対して試験を実行することができ、前の試
験結果を使用して次に実行すべきＰＤＰを決定できる。
また、これらのＰＤＰは、制御の設定、ケーブルの切
断、プログラムの再開などの処置を行うよう操作員に要
求することもできる。ＰＤＰは、操作員に対するメッセ
ージとして、ある処置を取るべきである、またはあるサ
ービス担当員を呼ぶべきであると推奨する問題解決策を
提案する。

【０００５】集中サービス・データ処理システムも確立
されている。たとえば、ＩＢＭ“ＲＥＴＡＩＮ”ネット
ワークが数年前から市販されている。顧客は、全国的施
設に電話し、顧客担当エンジニア（ＣＥ）または製品サ
ポート・スタッフのいずれかであるサービス担当員に、
自分のシステムの問題について話すことができる。担当
員は、顧客のシステムがどんな症状を示しているか、お
よびそのシステムにどんなハードウェアおよびソフトウ
ェアが存在するかを顧客に尋ねることによって、診断を
試みる。顧客がこれらの質問に答えると、サービス担当
員は、あるキー・ワードを端末に入力する。担当員は、
問題の特徴を十分に明らかにしたと満足したとき、この
キー・ワードを探索引数として使用して、中央システム
に記憶された１つ又は複数の問題管理データ・ベースに
アクセスする。このデータ・ベースの各エントリには、
１つ又は複数のキー・ワードと、これらのキー・ワード
に関連する問題に対して提案される解決策の解説があ
る。

【０００６】米国特許出願第１６９５１６号明細書に
は、問題を検出し、中央サービス・システムにサービス
要求を送ることのできるコンピュータ・システムが開示
されている。この中央サービス・システムは、サービス
要求を受け取り、データベースを検査して、その問題に
対する解決策が既知であるか否かを調べる。既知である
場合には、そのコンピュータ・システムに解決策に関す
る情報が自動的に送られる。

【０００７】上記の特許出願は、コンピュータ・システ
ム・サービスの分野での大きな進歩である。しかしなが
ら、この特許のコンピュータ・システムは、サービスが
必要な場合に、１つの中央サービス・システムにサービ
ス要求を送ることしかできない。さらに、この中央サー
ビス・システムは、そのデータベース内でこの問題の矯
正法を発見できない場合、サポート・センタに通知しな
ければならず、サポート・センタでは人間がこの問題を
さらに調査しなければならない。したがって、この中央
サービス・システムは、それにサービスを求めるコンピ
ュータ・システムが出会うと思われる問題の一部分しか
自動的に矯正できないはずである。現在のコンピュータ
・システムのほとんどが、複数の異なるベンダによって
製造されたハードウェアおよびソフトウェアを含むこと
を考慮にいれると、この問題はさらに大きくなる。さら
に、コンピュータ・システムは、ハードウェアおよびソ
フトウェアの構成と能力の点で根本的に異なることがあ
り得る。１つの中央サービス・システムで、それにサー
ビスを依存している何百、何千ものコンピュータ・シス
テムが出会うであろう多様な問題を適切に処理できると
は思われない。また、上記のシステムには、問題の解決
策を効率的に追跡する能力や、問題の予防策を要求しま
たは受け取る能力が欠けている。

【０００８】

【発明が解決しようとする課題】本発明の主目的は、コ
ンピュータ・システム内の問題に効率的にサービスする
ことである。

【０００９】本発明のもう１つの目的は、コンピュータ
・システムのサービス・ネットワークに、効率的に問題
にサービスさせることである。

【００１０】本発明のもう１つの目的は、コンピュータ
・システム内の問題に効率的にサービスするサービス・
ネットワークを構築することである。

【００１１】本発明のもう１つの目的は、コンピュータ
・システムのサービス・ネットワークにあるコンピュー
タ・システムを自動的に登録することである。

【００１２】

【課題を解決するための手段】上記およびその他の目的
は、本明細書に開示するサービス・ネットワークによっ
て達成される。

【００１３】サービス・ネットワークは、複数のコンピ
ュータ・システムを互いに接続させる。コンピュータ・
システムは、「サービス要求装置」（ＳＲ）、「サービ
ス提供装置」（ＳＰ）、または両者の混成物である「サ
ービス提供・要求装置」（ＳＰ／Ｒ）のいずれかであり
得る。

【００１４】このサービス・ネットワークは、コンピュ
ータ・システムをサービス・ネットワークに追加する登
録処理によって構築される。すでにネットワーク内にあ
るＳＰ（またはＳＰとして動作するＳＰ／Ｒ）は、その
ネットワークへのＳＲ（またはＳＲとして動作するＳＰ
／Ｒ）の登録を開始することができる。さらに、ＳＲ
（またはＳＲとして動作するＳＰ／Ｒ）は、ネットワー
クへの登録要求を開始することができる。このような要
求が開始された場合、その要求はそれを受け取る側の承
認を受けなければならない。この要求は、自動的に又は
人間の介入によって承認を受けることができる。

【００１５】

【実施例】

引用による合体 本発明は、次の特許および特許出願に関連しており、こ
れらはすべて、本出願人に譲渡され、引用によって本明
細書に合体される。 米国特許第４６５４８５２号明細書 米国特許出願第１２２２９３号明細書 米国特許出願第１６９５１６号明細書

【００１６】目次 Ｉ． 概要 ＩＩ． サービス・ネットワークへのコンピュータ・シ
ステムの登録 ＩＩＩ．階層的サービス・ネットワーク内での問題の解
決 ＩＶ． サービス・ネットワーク内での問題の追跡 Ｖ． サービス・ネットワーク内での問題の予防

【００１７】Ｉ．概要 本明細書の残りの部分では、１つまたは複数のコンピュ
ータ・システムからのサービスを要求するが、他のコン
ピュータ・システムに対してサービスを提供しないコン
ピュータ・システムを、「サービス要求装置」または
「ＳＲ」と呼ぶ。１つまたは複数のコンピュータ・シス
テムにサービスを提供するが、１つまたは複数のコンピ
ュータ・システムからのサービスを要求することもでき
るコンピュータ・システムは、カメレオン的な混成物と
しての役割を果たし、「サービス提供・要求装置」また
は“ＳＰ／Ｒ”と呼ばれる。どのコンピュータ・システ
ムからもサービスを要求しないが、１つまたは複数のコ
ンピュータ・システムに対してサービスを提供するコン
ピュータ・システムを、「サービス提供装置」または
“ＳＰ”と呼ぶ。

【００１８】図１は、本発明のサービス・ネットワーク
を単純化して示した図である。ＳＲ１１０は、リンク１
２０を介してＳＰ／Ｒ１３０に接続されている。ＳＰ／
Ｒ１３０は、リンク１４０を介してＳＰ１５０に接続さ
れている。好ましい実施例では、ＳＲ１１０、ＳＰ／Ｒ
１３０およびＳＰ１５０は、すべてＩＢＭ ＡＳ／４０
０中型コンピュータ・システムであるが、メインフレー
ム・コンピュータやパーソナル・コンピュータを使用す
ることも可能である。リンク１２０および１４０は、通
常は、専用回線や公衆交換電話網などの遠隔通信リンク
またはその他の搬送手段であるが、電線や光ケーブルな
どの直接リンクやローカル・エリア・ネットワークであ
ってもよい。ＳＲ１１０には、プロセッサ１１１、記憶
装置１１２および１つまたは複数の端末１１３も含まれ
る。同様に、ＳＰ／Ｒ１３０には、プロセッサ１３１、
記憶装置１３２および１つまたは複数の端末１３３が含
まれる。ＳＰ１５０には、プロセッサ１５１、記憶装置
１５２および１つまたは複数の端末１５３が含まれる。

【００１９】図２は、本発明のより複雑なサービス・ネ
ットワークを示す図である。各ＳＰ／Ｒは、通常は複数
のＳＲに接続されている。ＳＰ／Ｒは、これらのＳＲに
対するサービス提供装置として動作する。各ＳＰ／Ｒは
また、通常は複数のＳＰにも接続されている。ＳＰ／Ｒ
は、これらのＳＰに対するサービス要求装置として動作
する。

【００２０】図３は、本発明の典型的なサービス・ネッ
トワークを示す図である。ＳＲ１１０は、架空の小企業
であるピート仕出し屋（Pete’s Catering）のコンピュ
ータ・システムであると仮定しよう。ＳＲ１１０は、リ
ンク１２０を介して、架空のソフトウェア修理会社であ
るソフトウェア・フィックスイット・ショップ（TheSof
tware Fixit Shoppe）という名のＳＰ／Ｒ１３０と通信
する。ソフトウェア・フィックスイット・ショップは、
リンク１４０を介して、サムズ・スプレッドシーツ（Sa
m’s Spreadsheets）という名の架空のアプリケーショ
ン・ソフトウェア開発会社、ＳＰ１５０と通信する。ま
た、ソフトウェア・フィックスイット・ショップは、Ｓ
Ｐ／Ｒ１４６（リアリー・ビッグ・コンピュータ社（Re
ally Big Computer Company））とＳＰ１４５（ロッツ
・オブ・ワーズ社（Lot’s of Words, Inc））にも接続
されている。ＳＰ／Ｒ１４６は、さらにＳＰ１５１、Ｓ
Ｐ／Ｒ１５２およびＳＰ１５３に接続されている。ＳＰ
／Ｒ１５２は、ＳＰ／Ｒ１５４およびＳＰ１５５に接続
されている。ＳＰ／Ｒ１５４は、ＳＰ１５６、ＳＰ１５
７およびＳＰ１５８に接続されている。

【００２１】ＳＲ１１０はまた、リンク１７１を介して
ＳＰ／Ｒ１７０にも接続されている。ＳＰ／Ｒ１７０
は、ハードウェア・フィックスイット・ショップ（the
Hardware Fixit Shoppe）と称する。ＳＰ／Ｒ１７０
は、さらにＳＰ１７５、ＳＰ／Ｒ１７７、ＳＰ／Ｒ１７
８およびＳＰ／Ｒ１４６に接続されている。ＳＰ／Ｒ１
７７は、さらにＳＰ１８１に接続されている。ＳＰ／Ｒ
１７８は、さらにＳＰ１８２に接続されている。

【００２２】通常、ＳＰ／Ｒ１７０（ハードウェア・フ
ィックスイット・ショップ）とＳＰ／Ｒ１３０（ソフト
ウェア・フィックスイット・ショップ）は、ＳＲ１１０
（ピート仕出し屋）のような数百または数千ものサービ
ス要求装置にも接続されるはずであり、図３に示したよ
りも多くのＳＰまたはＳＰ／Ｒにも接続され得る。

【００２３】図３のネットワークは、このサービス・ネ
ットワークにコンピュータ・システムを追加する登録処
理によって構築される。すでにネットワーク内にあるＳ
Ｐ（またはＳＰとして動作するＳＰ／Ｒ）は、そのネッ
トワークへのＳＲ（またはＳＲとして動作するＳＰ／
Ｒ）の登録を開始することができる。さらに、ＳＲ（ま
たはＳＲとして動作するＳＰ／Ｒ）は、ネットワークへ
の登録要求を開始することができる。このような要求が
開始された場合、その要求はそれを受け取る側の承認を
受けなければならない。

【００２４】図３のネットワークが確立されると、ピー
ト仕出し屋のコンピュータ・システムは、自動的に、そ
の構成要素（ハードウェア、ソフトウェアまたはマイク
ロコード）に関する問題を検出し、この問題を記述する
サービス要求を作り、この問題を矯正する責任を負うＳ
Ｐ／Ｒ（ハードウェア・フィックスイット・ショップま
たはソフトウェア・フィックスイット・ショップのいず
れか）を選択し、そのＳＰ／Ｒにサービス要求を送る。
この問題を矯正する責任を負うＳＰ／Ｒは、このサービ
ス要求を受け取り、ピート仕出し屋がサービスを受ける
資格を有することを確認し、解決ログを検査して、そこ
にこの問題の解決策があるか否かを調べる。ある場合に
は、この問題の矯正策を記述した解決情報が、１つまた
は複数のソフトウェア構成要素、マイクロコード構成要
素、ハードウェア部品注文およびテキストによる指示あ
るいはそのいずれかと共に、このＳＲへ送られる。責任
を負うＳＰまたはＳＰ／Ｒがこの問題を矯正できない場
合には、それが接続されている他のいずれかのＳＰまた
はＳＰ／Ｒからこの問題に対する支援を受けられるか否
かを調べる。そうである場合には、そのＳＰまたはＳＰ
／Ｒに対してサービス要求を送る。この問題の矯正策が
見つかるまで、この処理が続けられる。

【００２５】たとえば、ピート仕出し屋のコンピュータ
・システムが、そのスプレッドシート・アプリケーショ
ン・プログラムの１構成要素（現場交換可能ユニット
（ＦＲＵ）、交換可能ユニット（ＲＵ）、モジュールま
たはオブジェクトとも称する）に問題を発見したと仮定
しよう。このシステムは、ソフトウェア・フィックスイ
ット・ショップがこの構成要素を矯正する責任を負って
いると判断して、サービス要求を作り、これをソフトウ
ェア・フィックスイット・ショップに送る。ソフトウェ
ア・フィックスイット・ショップのコンピュータは、ピ
ート仕出し屋がサービスを受ける資格を有することを確
認し、解決ログを検査して、この問題の決策があるか否
かを調べる。このコンピュータは、この問題の解決策を
見つけられず、それが接続されている他のいずれかのＳ
ＰまたはＳＰ／Ｒからこの構成要素に対する支援を受け
られるか否かを調べる。このコンピュータは、サムズ・
スプレッドシーツがスプレッドシート・アプリケーショ
ン構成要素に関する問題を支援していると思われること
を発見し、サムズ・スプレッドシーツにサービス要求を
送る。サムズ・スプレッドシーツのコンピュータは、こ
の要求を受け取り、その解決ログから解決策を探索し、
解決策を見つける。サムズ・スプレッドシーツのコンピ
ュータは、ソフトウェア・フィックスイット・ショップ
に解決情報を送り、ソフトウェア・フィックスイット・
ショップがこれをピートに送る。その後、サムズ・スプ
レッドシーツの解決情報が、ソフトウェア・フィックス
イット・ショップの解決ログに記憶される。この解決情
報はまた、この問題を発生させたスプレッドシート・プ
ログラムの構成要素の代わりに使用すべき交換用のソフ
トウェア構成要素を伴っている。

【００２６】サムズ・スプレッドシーツの解決情報は、
ソフトウェア・フィックスイット・ショップの解決ログ
に記憶される。これは、ソフトウェア・フィックスイッ
ト・ショップが支援する別のサービス要求装置が、同一
の問題に関するサービス要求をソフトウェア・フィック
スイット・ショップに送る場合に、ソフトウェア・フィ
ックスイット・ショップが、この問題の矯正策を要求元
に直接送ることができ、サムズ・スプレッドシーツにこ
のサービス要求を転送する必要がないことを意味する。

【００２７】この問題の解決の状況を、図３の支援ネッ
トワークのコンピュータ・システムによって監視するこ
とができる。各ＳＲ、ＳＰ／ＲおよびＳＰは、それぞれ
各問題の状況を追跡するために問題ログを内蔵してい
る。問題は、OPEN（オープン）、READY（動作可能）、P
REPARED（準備済み）、SENT（送出済み）、ANSWERED
（解答済み）、FIXED（矯正済み）、VERIFIED（確認済
み）およびCLOSED（クローズ済み）という状況を有する
ことができる。各コンピュータ・システムに存在する問
題ログによって、このネットワークの状況を容易に監視
することが可能になる。この監視活動は、一連の画面を
介して、またはこのネットワークのコンピュータ・シス
テムに結合されたコンソール上にネットワークまたはネ
ットワークの一部の絵図面を図形表示することによっ
て、ユーザが照会できる。たとえば、ソフトウェア・フ
ィックスイット・ショップにあるコンソール（ネットワ
ーク操作員が使用する特殊な端末）は、これが支援する
すべてのＳＲを図形表示することができる。サービス要
求をピート仕出し屋から受け取ると、サービス要求を受
け取ったことを示すために、ピートを表わすアイコンが
点滅しまたは色を変える。このアイコンの外観は、この
サービス要求がサムズ・スプレッドシーツに転送された
時と、解決情報をサムズ・スプレッドシーツから受け取
った時と、それがピートに送られた時に、それぞれ変化
する。

【００２８】また、あるシステムは、他のコンピュータ
・システムが支援の責任を負わない問題について他のシ
ステムに知らせるように、他のシステムに助言を送るこ
ともできる。

【００２９】本発明のサービス・ネットワーク内のコン
ピュータ・システムは、問題の予防策を実行または要求
する能力をも有する。ＳＰ（またはＳＰとして動作する
ＳＰ／Ｒ）は、それが支援する１つまたは複数のＳＲ
（またはＳＲとして動作するＳＰ／Ｒ）が有するが、ま
だ発見も報告もしていない問題に対する解決策を有する
か否かを調べることができる。そうである場合には、そ
のＳＰはそのＳＲに、１つまたは複数のソフトウェア構
成要素、マイクロコード構成要素、ハードウェア部品注
文およびテキストによる指示あるいはそのいずれかと共
に、解決情報を配布することができる。さらに、ＳＲ
（またはＳＲとして動作するＳＰ／Ｒ）は、あるＳＰ
（またはＳＰとして動作するＳＰ／Ｒ）から、支援され
るリスト中の構成要素に関する問題の既知の矯正策を要
求することができる。このＳＰは、要求元のＳＲに、支
援されるリスト中の構成要素に関連する問題の矯正策を
送る。

【００３０】たとえば、ソフトウェア・フィックスイッ
ト・ショップが、スプレッドシート・プログラムの障害
のあるソフトウェア構成要素に対する矯正策をサムズ・
スプレッドシーツから受け取った後に、それが支援する
ＳＲであって、このスプレッドシート・プログラムを有
するが、まだこの問題を報告も発見もしていない他のＳ
Ｒでの問題予防を実行したいと望んでいると仮定しよ
う。ソフトウェア・フィックスイット・ショップは、こ
のようなＳＲがどれであるかを決定し、それらのＳＲ
に、交換用のソフトウェア構成要素と共に解決情報を送
る。

【００３１】図４は、本発明の非常に複雑なサービス・
ネットワークを示す図である。コンピュータ・システム
は、複数のレベルに配列することができる。ＳＲは、１
つまたは複数のＳＰまたはＳＰ／Ｒからサービスを要求
できる。ＳＰ／Ｒは、１つまたは複数のＳＲを支援で
き、１つまたは複数のＳＰまたはＳＰ／Ｒからのサービ
スを要求できる。ＳＰは、１つまたは複数のＳＲまたは
ＳＰ／Ｒを支援できる。１対のＳＰ／Ｒ同士でも、互い
にサービスを要求できる。

【００３２】図５は、図１のＳＲ１１０をより詳細に示
す図である。図５の実行可能要素は、当該の流れ図に示
すように適切にプログラミングされ、プロセッサ１１１
によって実行される。

【００３３】オペレーティング・システム・プログラム
（ＯＳ）２１０は、どのようなタイプでもよいが、ＯＳ
／４００など、多数のプログラムを並行に実行する従来
の能力を有することが好ましい。資源マネジャ（ＲＭ）
プログラム２２０は、ハードウェア構成要素（タイプ、
モデル、通し番号）およびソフトウェア構成要素（製品
番号、リリース・レベル、導入されたプログラム一時修
正（ＰＴＦ））を識別する、重要製品データ（ＶＰＤ）
テーブル２２１からのＶＰＤ情報を管理する。このデー
タの一部は、実際には信頼性・保守性（ＲＡＳ）マネジ
ャ２４１によって収集される。ＲＭプログラムは、ＳＲ
の構成要素の相互接続を記述したトポロジ・ファイル２
２２をも管理する。

【００３４】任意の従来型アプリケーション・プログラ
ム群２３０は、ジョブ・キュー（図示せず）など何らか
の従来型の管理技法の下で、ＯＳ２１０によって実行さ
れる。ＯＳは、アプリケーション・プログラム群２３０
のうちの１ジョブとして、立ち上げ（ＩＰＬ）時にＲＭ
プログラム２２０を実行する。

【００３５】一組のサービス・ユーティリティに、本発
明が使用する要素のほとんどが含まれる。

【００３６】ＳＲのサブシステムはすべて、そのサブシ
ステムの作動中に発生するエラーを検出する、常駐型の
事象駆動式ＲＡＳユーティリティ・プログラムを有す
る。たとえば、図１ないし４の１１２などのディスク・
サブシステム内の入出力処理装置は、エラーの結果とし
てこの入出力処理装置が割込みを発行する時に割込みル
ーチンとして実行される、ＲＡＳユーティリティ２４０
を有することができる。それらは、通知可能タスクとし
て実行されることもできる。エラーが発生するのは、あ
る演算が、既知の無効な結果を生ずるか、時間切れにな
るか、開始に失敗するか、バス信号線内でスタック障害
を生ずるかなどした時である。ＲＡＳマネジャ２４１
は、顧客システムの実行中に、ＲＡＳユーティリティ２
４０によって事象駆動される。ＲＡＳマネジャ２４１
は、ＯＳ２１０の下でジョブのレベルで実行するのでは
なくて、マイクロコード内の事象駆動タスクとして実行
することが好ましい。ＲＡＳマネジャによって収集され
た生のエラー・データは、エラー・ログ２４２に保存さ
れる。このデータの一部は、後で問題ログ２４３に転送
される。各エラーから収集されたデータは、エラー・ロ
グに１エントリとして記録される。エラー・ログの各エ
ントリのフィールドには、次のものが含まれる。 ・このエラー・ログ・エントリを識別する一義的キーで
ある、システム・ログ識別子 ・障害統計（たとえば、正しいシリンダが見つかる前に
発生したシーク・エラーの回数） ・エラー発生時に関係のあった構成要素の構成（ＶＰＤ
テーブルから） ・レジスタの内容や状況ビットなど、特定のＲＡＳユー
ティリティから提供される装置状況 ・エラーの種別を識別する参照コード

【００３７】問題ログ２４３には、出会った問題ごとに
１つずつ複数のエントリが含まれる（「エラー」は、
「問題」とは異なることに注意されたい。）。問題ログ
の各エントリには、下記のフィールドが含まれる。 ・ネットワーク全体で一義的な問題識別子 ・状況情報 ・計算機情報（タイプ、通し番号、モデル、変更レベ
ル、ネットワーク識別子、制御点） ・可能性を絞るための、初期または障害発生時のＦＲＵ
リスト ・可能性を絞るための、分離ＦＲＵリスト ・可能性を絞るための、最終または修正ＦＲＵリスト ・症状列（符号化された参照番号） ・解決情報（問題の解答が与えられた時に記入） ・問題発生源のシステムの識別（ネットワーク識別子と
制御点） ・要求を送ってきたシステムの識別（ネットワーク識別
子と制御点） ・要求を送った先のシステムの識別（ネットワーク識別
子と制御点） ・実際に行なわれた問題解決活動と、その活動を行った
ものの活動記録

【００３８】問題ログのエントリは、以下の８つの状況
条件のうちの１つを有する。エントリが最初に作成され
た後には、“OPEN”。すべての適当なＰＤＰ２４６が実
行を完了した後には、“READY”。関連するサービス要
求２４９が記憶された後には、“PREPARED”。サービス
要求が、処置を求めて中央サービス・システムにこれを
送った後には、“SENT”。解決情報をＳＰまたはＳＰ／
Ｒから受け取った後には、“ANSWERED”。解決策を適用
した後には、“FIXED”。その解決情報がこの問題を解
決したことをＳＲが確認した後には、“VERIFIED”。こ
の問題に対するすべての処置が完了した後には、“CLOS
ED”。

【００３９】問題ログ・エントリのフィールドを図８に
示す。

【００４０】再び図５を参照すると、用語“ＦＲＵ”
は、文字どおり、「現場交換可能ユニット」、すなわち
故障した部品の交換用に常備される、システムの最小構
成要素を意味し、当業界で一般に使用されている用語で
ある。しかしながら、本発明では、この用語の意味は、
問題解決の最小単位を指すように拡張される。このよう
な単位は、この用語の通常の意味でのハードウェア構成
要素でもよいが、プログラム、モジュール、オブジェク
トなどのソフトウェア構成要素や、問題を解決するため
に行うべき処置を指示するメッセージでもよい。たとえ
ば、操作員に、あるスイッチをリセットするなり、通信
業者のサービス担当員を呼ぶよう指令が出ることがあ
る。

【００４１】初期ＦＲＵリストは、問題を検出したＲＡ
Ｓユーティリティ２４０によって、故障の疑いをもたれ
ている構成要素のリストである。このリストは、このＲ
ＡＳユーティリティが書き込んだエラー・ログから導き
出される。分離ＦＲＵリストは、ＰＤＰ２４６から疑わ
れている構成要素を含む。問題分析・解決（ＰＡＲ）プ
ログラム２４４によって実行されるどのＰＤＰも、問題
ログ内の分離ＦＲＵリスト・フィールドに１つまたは複
数のＦＲＵ番号を書き込むことができる。サービス提供
装置は、分離ＦＲＵリストを更新して、疑いを持たれて
いる構成要素を示す最終ＦＲＵリストを生成する。これ
ら３つのリストのそれぞれにあるＦＲＵコード番号は、
それを提供するプログラムによって、障害の確率が降順
になるように並べられる。リスト内の各項目は、それが
故障ユニットである尤度を指定した、明示的確率値をも
有する。これらの値も、各構成要素の設計者によって提
供される。問題ログ・エントリの異なるフィールドは、
異なる時点で書き込まれる。一部のフィールドではその
複数のエントリを単一のエントリに書き込むことができ
る。

【００４２】連絡データベース２０１は、顧客の氏名と
住所などの顧客に関する情報、システム問題に関連して
連絡をとるべき一人または複数の人物の氏名と電話番
号、好ましい言語のテキストによる指示などを含む。

【００４３】ＰＡＲプログラム２４４には、ＲＡＳマネ
ジャが受け取って、エラー・ログに入力した問題を分析
するためのルーチンが含まれる。ＲＡＳマネジャ２４１
がエラー・ログ２４２内で新しいエントリを生成する
時、ＰＡＲプログラム２４４は、必ずしもそうする必要
はないが、問題ログ２４３内に新しいエントリを生成す
ることができる。システム・ログ識別子、障害を識別す
る参照コード、およびエラー・ログからの構成データの
一部が、問題ログのエントリに転送される。またＰＡＲ
プログラムは、問題ログ内の参照コードに応答して、複
数のＰＤＰ２４６の間で選択を行う。手短かにいうと、
ＰＡＲプログラム２４４は、問題ログの症状フィールド
から符号化された参照番号を読み取り、問題ログから故
障ユニットのコードを読み取る。その後ＰＡＲプログラ
ム２４４は、特定のＰＤＰ２４６を選択し、これを実行
する。選択されたＰＤＰは、問題ログのエントリ内の別
のフィールドに問い合わせることができ、任意選択とし
て、顧客システムの操作員に（図１ないし４の端末１１
３上の表示を介して）さらに詳しい情報を求めたり、制
御の設定やプラグの挿入など、自動的に行うことの不可
能なある種の動作を操作員に行わせる指示を表示したり
することもできる。

【００４４】ユーザ検出問題解決（ＵＰＰＲ）プログラ
ム２４７は、ＲＡＳマネジャがエラーを検出していない
場合でも、ＳＰの操作員が問題ログのエントリを生成で
きるようにするプログラムである。これは、表示スクリ
ーンまたはパネル２４５を用いて、操作員から情報を要
求しその入力を受け取ることによって行われる。ＵＰＰ
Ｒプログラムは、操作員からのデータに応答して適当な
ＰＤＰ２４６を実行することができ、また操作員にある
処置を行うよう要求することもできる。ＵＰＰＲプログ
ラムは、ＰＤＰの結果と操作員の情報から、症状列およ
び関係する構成要素のリストを作成する。この目的のた
めに実行されるＰＤＰが、その問題を解決する場合もあ
る。その場合には、エントリは生成されない。

【００４５】システム支援機能（ＳＳＦ）プログラム２
４８は、選択された問題ログのエントリをサービス要求
２４９に変換し、これを図１ないし４のＳＰ／Ｒ１３０
などのＳＰまたはＳＰ／Ｒに送り、このＳＰまたはＳＰ
／Ｒとの対話のＳＲ端を管理する。ＳＳＦ２４８はま
た、サービス・ネットワークへの登録を要求し、問題予
防を要求し、問題の状況を追跡し、助言を処理するのに
も使用される。

【００４６】次に、図９を参照すると、サービス要求２
４９は、既知の問題を矯正するようＳＲが要求する時に
は、図９Ａに示す書式になる。第Ｖ節で詳細に説明する
ように、ある構成要素の問題予防をＳＲが要求する時に
は、サービス要求２４９は、図９Ｂに示す書式になる。
サービス要求２４９は、下記のフィールドを含む。 ・問題識別子 ・顧客データ（連絡先の人の氏名、電話番号および住
所、顧客の言語） ・問題を検出し報告した計算機の計算機情報（タイプ、
通し番号、モデル、変更レベル、ネットワーク識別子、
制御点） ・宛先識別子（任意選択。このサービス要求を転送する
先のサービス提供装置のネットワーク識別子と制御点） 既知の問題の場合には、 ・問題データ（問題ログ番号、発生の日時、重大さ、症
状列、再発フラグ） ・初期ＦＲＵおよび分離ＦＲＵのコード（すなわち、現
場交換または顧客交換が可能なハードウェアまたはソフ
トウェア構成要素の部品番号、これらの構成要素がその
問題を引き起した確率の推定値、この問題を記述するメ
ッセージのキー番号） ・テキストによる問題の記述（自動の場合は空白） 問題予防の場合には、 ・問題予防タイプ識別子 ・構成要素識別子

【００４７】再発フラグは、セットされると、同一の構
成要素で、所定の期間（たとえば３０日）内に前にも問
題が報告されたこと、およびその期間内に前にも同一の
症状が発生したことを示す。重大度コードは、その問題
がどの程度重大であると考えられるかを示す、操作員ま
たはシステムによって割り当てられる数字である。

【００４８】症状列は、問題検出とその後の問題解析の
結果から書式が再設定された、一連のコードである。

【００４９】再び図５を参照すると、解決ログ２０２
は、ＳＲ１１０の構成の変更を追跡した記録である。図
１０に示すように、解決ログ２０２は下記のフィールド
を含む。 ・ネットワーク識別子および制御点 ・構成要素識別子 ・バージョン／リリース・レベル ・解決情報（１つまたは複数の、ハードウェア、ソフト
ウェアまたはマイクロコードの構成要素を識別する） ・解決状況（上記の各構成要素ごとに） ・症状列 ・必要条件（問題予防要求に対して解決策を送るべきか
否かを示す）

【００５０】再び図５を参照すると、支援データベース
２０３は、ＳＲのコンピュータ・システムの構成要素を
支援する責任を負うＳＰまたはＳＰ／Ｒを追跡するデー
タベースである。図１２に示すように、支援データベー
ス２０３は下記のフィールドを含む。 ・構成要素識別子 ・ＳＰまたはＳＰ／Ｒのネットワーク識別子 ・制御点 ・自動導入情報 ・問題予防情報

【００５１】図５のＳＲ１１０は、リンク２７５を介し
てＳＰ／ＰまたはＳＰと通信する。

【００５２】図７は、本発明のＳＰ１５０のブロック図
である。

【００５３】問題制御プログラム２９５は、ＳＲまたは
ＳＰ／Ｒとの対話を管理し、登録要求と問題予防要求を
処理し、問題の状況を追跡し、助言を処理する。問題制
御プログラム２９５は、当該の流れ図で示されるように
適切にプログラミングされ、プロセッサ１３１または１
５１によって実行される。問題制御プログラム２９５
は、問題ログ２６１、解決ログ２６２および連絡データ
ベース２６３にアクセスする。前記のログおよびデータ
ベースはそれぞれ、図７のＳＲ１１０に関して論じたも
のと同じ書式であるが、ＳＰ１５０によって支援される
すべてのＳＰおよびＳＰ／Ｒに関する情報を含んでい
る。問題制御プログラム２９５は、リンク２７５を介し
て他のＳＰ／ＲまたはＳＲと通信する。問題制御プログ
ラム２９５は、それが支援する問題についてサービス担
当者に通知するが、リンク２８５を介して矯正すること
はできない。ＳＰ１５０はまた、第ＩＶ節で論じるよう
に、コンソールに提示される情報を制御するためのコン
ソール・バッファ２６４を有する。

【００５４】ＳＰ１５０はまた、資格データベース２７
０を有する。資格データベース２７０は、ＳＲまたはＳ
Ｐ／Ｒがどんな支援を受ける資格を有するかを追跡する
データベースである。資格データベース２７０は、図１
１に詳細に示し、下記のフィールドを含む。 ・依頼主記述データ（図１７に示すものなど） ・システムのタイプ ・システムの通し番号 ・ネットワーク識別子 ・制御点（ＳＲまたはＳＰ／Ｒを一義的に識別する） ・資格状況（登録されているか否か） ・資格を与えられた構成要素の識別子リスト

【００５５】図６は、本発明のＳＰ／Ｒ１３０のブロッ
ク図である。ＳＰ／Ｒは、すでに論じたＳＲ１１０の諸
要素を、やはりすでに論じたＳＰ１５０の諸要素と組み
合わせたものである。問題ログ２６１、解決ログ２６２
および連絡データベース２６３は、ＳＰ／Ｒ１３０が支
援するすべてのＳＲおよびＳＰ／Ｒに関する情報を含
み、問題ログ２４３、解決ログ２０２および連絡データ
ベース２０１は、ＳＰ／Ｒ１３０に関する情報のみを含
むことに留意されたい。

【００５６】ＩＩ．サービス・ネットワークへのコンピ
ュータ・システムの登録 図１３は、サービス提供装置による、サービス・ネット
ワークへのサービス要求装置の登録を示す流れ図であ
る。この流れ図は、ＳＰ／Ｒ１３０またはＳＰ１５０の
プロセッサ１３１または１５１（図１ないし４）によ
り、問題制御プログラム２９５（図６および７）によっ
て実行される。１例として、サービス・ネットワーク
が、ジョー食料品店（Joe’s Deli）、ウィリー部品店
（Willie’s Wigets）、レフティはさみ屋（Lefty’s S
cissors）という名のＳＲにサービスを提供するＳＰ／
Ｒとしてのソフトウェア・フィックスイット・ショップ
からなる（図３）と仮定しよう。ソフトウェア・フィッ
クスイット・ショップは、このサービス・ネットワーク
にピート仕出し屋をＳＲとして登録したいと考えてい
る。ブロック６０１で、ＳＰ属性を定義または変更する
必要があるかどうか検査する。これ以降の流れ図では、
“ＳＲ”は、ＳＲと、ＳＲとして動作するＳＰ／Ｒの両
方を指すものとする。また、“ＳＰ”は、ＳＰと、ＳＰ
として動作するＳＰ／Ｒの両方を指すものとする。

【００５７】ブロック６０１で肯定の答が得られた場
合、ＳＰの操作員に、図１４に示すように、変更すべき
属性情報を伴った指示メッセージが示される。図１４の
属性情報は、このＳＰが支援するすべてのＳＲ用の省略
時属性情報である。これは、図１７に示すように、特定
のＳＲに関して個別に指定変更することができる。

【００５８】ブロック６１０で、操作員がサービス要求
装置について作業したいと望むかどうか質問が出る。そ
うである場合、ブロック６１１で、図１５に示すメイン
・メニューが表示される。このメイン・メニューには、
ジョー食料品店、ウィリー部品店およびレフティはさみ
屋がすでにＳＲとしてこのネットワークに登録されてい
ることが示される。操作員は、オプション１を選択して
ピート仕出し屋を追加し、これによってブロック６２０
に肯定の回答を行い、図１６ないし２０に示される画面
が表示される。操作員は、図１６でピート仕出し屋に関
する顧客情報を入力し、図１７で省略時属性のいずれか
を変更し、図１８でピート仕出し屋がサービスを受ける
資格を有する構成要素のリストを追加する。「構成要
素」は、ハードウェア、ソフトウェアまたはマイクロコ
ードの１個または１群の交換可能ユニットとして定義さ
れる。ハードウェアの場合、構成要素は、キーボード全
体や“Ｙ”キー自体でよい。ソフトウェアの場合、構成
要素は、アプリケーション・プログラム全体、オペーレ
ティング・システム、またはそれ自体が他のプログラム
の組合せであるものも含めてその他の種類のプログラム
でよい。また、構成要素は、オブジェクトやモジュール
などプログラムの非常に小さな部分でも、それより大き
な部分であってもよい。上記の特許出願第１６９５１６
号明細書には、プログラムが階層的に配列された複数レ
ベルの交換可能ユニット（ＲＵ）からなる、ソフトウェ
ア・パッキング体系が示されている。構成要素は、ＯＣ
ＧレベルのＲＵから、ＳＦＧレベルのＲＵおよびＯＣＧ
レベルのそれに関連するＲＵ群、ＡＧレベルのＲＵおよ
び階層構造内でその下にあるすべてのＲＵまでのどれで
もよい。図１９では、操作員が、使用可能であるが現在
支援されていない構成要素のリストから、支援する構成
要素を選択することができる。図２０では、操作員が、
サービスを受ける資格を有する各構成要素に関連する言
語を指定することができる。

【００５９】所望の情報がすべてこれらの画面に入力さ
れると、ブロック６２２（図１３）で、資格データベー
ス２７０に資格エントリが記録される。ブロック６２３
で、登録要求がＳＲに送られる。制御の流れはブロック
６１０に戻り、処理すべきＳＲが他にもあるかどうかを
調べる。ない場合、このプログラムはブロック６２５で
終了する。

【００６０】図２１は、サービス要求装置による、サー
ビス・ネットワークへのサービス提供装置の登録の流れ
図である。この流れ図は、ＳＲ１１０またはＳＰ／Ｒ１
３０のプロセッサ１１１または１３１（図１ないし４）
により、ＳＳＦ２４８（図６および７）によって実行さ
れる。サービス・ネットワークの例に戻ると、ピート仕
出し屋は、現在、ソフトウェア・フィックスイット・シ
ョップから、オペレーティング・システム、スプレッド
シート・プログラム、ワード・プロセッサ、調理法デー
タベースおよびマイクロコードに関する支援を受けてい
るが、ハードウェア構成要素を支援する人物を望んでい
る。したがって、ピートは、サービス提供装置としてハ
ードウェア・フィックスイット・ショップの登録を要求
したいと考えている。ブロック６５１で、操作員がＳＰ
について作業したいと思っているかどうか質問が出る。
そうである場合、ブロック６５２で、図２２に示すメイ
ン・メニューが表示される。このメイン・メニューに
は、ソフトウェア・フィックスイット・ショップがすで
にＳＰとして登録されていることが示される。ピート
は、オプション１を選択してＳＰを追加し、これによっ
てブロック６６０に肯定の回答を行う。ブロック６６１
で、図２３および図２４に示す画面が表示されて、操作
員に情報の入力を促すプロンプトが出る。図２３Ａで
は、操作員にこのＳＰに関する連絡情報の入力を促すプ
ロンプトが出る。図２３Ｂでは、操作員にサービス属性
の入力を促すプロンプトが出る。図２４では、操作員に
支援を要求されている構成要素のリストの入力を促すプ
ロンプトが出る。

【００６１】必要な情報が与えられた後、ブロック６６
２で、支援データベース２０３のエントリが生成され
る。このエントリは、支援が要求されているが、まだ承
認されていないことを示している。ブロック６６３で、
この登録要求がＳＰに送られる。この登録要求には、要
求された構成要素のリストが、このＳＲに関する識別情
報と共に含まれる。

【００６２】ある構成要素がそのＳＰ／Ｒシステムに導
入されていないか、あるいは存在すらしない場合でも、
ＳＰ／Ｒはその構成要素の支援を要求できることに留意
されたい。ＳＰ／Ｒは、１つまたは複数のＳＲから支援
を求められることができる。サービスが要求される構成
要素は、１つまたは複数のＳＲシステムに導入すること
はできるが、登録要求の間にその構成要素に対するサー
ビスを要求するＳＰ／Ｒシステムに導入することはでき
ない。

【００６３】図２５は、図１３および２１に示した登録
処理がどのようにして承認されるかを示す図である。こ
の流れ図は、ＳＲ１１０、ＳＰ／Ｒ１３０またはＳＰ１
５０のプロセッサ１１１、１３１または１５１（図１な
いし４）により、ＳＳＦ２４８または問題制御プログラ
ム２９５（図５ないし７）によって実行される。ブロッ
ク７１０で、処理すべき登録要求があるかどうか調べ
る。そうである場合、ブロック７２１で、その要求が承
認されるかどうか尋ねる。これは、通常は、構成要素リ
ストの承認を求めるメッセージを操作員に送ることによ
って、手動で行なわれる。承認は、図１３のブロック６
２２ですでに入力された情報があるかどうか資格データ
ベースを検査するか（ＳＰがＳＲからの要求を承認する
場合）、あるいは図２１のブロック６６２ですでに入力
された情報があるかどうか支援データベースを検査する
（ＳＲがＳＰからの登録要求を承認する場合）ことによ
って、自動的に行うこともできる。たとえば、ＳＰが、
特定のＳＲと構成要素リストに関する全情報を含むエン
トリを資格データベース内にすでに準備しているが、そ
の登録状況が「未登録」である場合がある。こうなって
いる場合には、そのＳＲから受け取った一致する登録要
求を自動的に承認し、そのエントリの状況を「登録済
み」に変更することができる。

【００６４】構成要素が承認された場合、ブロック７２
２で、資格データベース２７０または支援データベース
２０３が更新され、ブロック７３０で、確認応答がＳＲ
またはＳＰに返される。ＳＲまたはＳＰは、この確認応
答を受け取り、その支援データベースまたは資格データ
ベースを、その登録要求が承認されたことを示すように
更新する。構成要素が承認されなかった場合、ブロック
７３１で拒絶応答が送られる。ＳＲまたはＳＰは、この
拒絶応答を受け取り、その支援データベースまたは資格
データベースを、これらの要素に関する支援が拒絶され
たことを示すように更新する。

【００６５】図３の例のサービス・ネットワークの残り
の部分は、上記と同様にして構築される。

【００６６】ＩＩＩ．階層的サービス・ネットワーク内
での問題の解決 図２６ないし３０は、サービス要求装置によって、また
はサービス要求装置のためにリモートでサービス提供装
置によって行われる、問題の検出、判別および報告を示
す図である。これらの流れ図は、ＳＲ１１０およびＳＰ
／Ｒ１３０のプロセッサ１１１、１３１または１５１
（図１）により、ＲＭプログラム２２０、ＵＰＰＲプロ
グラム２４７、ＰＡＲプログラム２４４、ＳＳＦ２４
８、ＲＡＳユーティリティ２４０、ＲＡＳマネジャ２４
１およびＰＤＰ２４６（図５および６）によって実行さ
れる。この考察では、リモートの問題検出と判別が行わ
れる場合、ＳＰ１５０は図６に示すＳＰ／Ｒ１３０の諸
要素を有するものと見なす。

【００６７】ブロック８０１で肯定の応答が得られた場
合には、図２７のサブルーチン９００を呼び出し、ロー
カル・システム上のエラーを探す。図２７を参照する
と、ブロック３１０で、ＯＳ２１０は、ＲＭプログラム
２２０に、ＲＡＳマネジャ２４１を使ってシステム・デ
ータを収集させる。上記の特許に記載されているよう
に、ＳＲ１１０のハードウェアおよびソフトウェアの構
成要素は、それら自体の中に、部品番号、技術変更レベ
ル、プログラム・コード・レベルその他を識別するため
に読み出すことのできる「重要製品データ」（ＶＰＤ）
を含んでいる。このデータには、システム全体または１
構成要素あるいはその両方のタイプ番号、モデル番号お
よび通し番号が含まれる。ＲＭプログラムは、各構成要
素からＶＰＤ情報を読み取り、ＶＰＤテーブルに記憶す
る。このテーブルは、システム資源マネジャ（ＳＲＭ）
データベース、または構成要素を互いに結合する方法を
記述したトポロジ・ファイルと共に記憶される。このデ
ータは、ＳＲシステムが再構成または拡張される時に実
行される従来型の構成プログラム（図示せず）から導出
できる。

【００６８】次に、ＯＳ２１０が、従来型のジョブ・キ
ューに従って（３２０）、システム・タスクを実行す
る。これらのタスクの一部は、キュー内の他のタスクと
並行して実行できる。各タスクを実行する時、ＯＳ２１
０は、実行中のタスクとシステムの状態を記述する環境
レコードを維持する（３２２）。

【００６９】この間に、破線３０２で表わすように、Ｒ
ＡＳユーティリティ２４０（図５ないし７）が、システ
ムのそれ自体の部分で実行可能になる。ブロック３３０
で、ある構成要素内でエラー状態が発生する時には、ブ
ロック３３１で適切なＲＡＳユーティリティが実行され
る。このユーティリティは、状況ビットの読取り、テス
トの実行などによってエラーの性質を判定した時、ブロ
ック３３２でエラー・ログにエントリを書き込む。エラ
ー・ログ・エントリについては、図５ないし７に関して
説明済みである。エラー・ログ・エントリから導出され
たＦＲＵリストは、関連するＦＲＵ（すなわち、ハード
ウェアまたはソフトウェアの構成要素、あるいは行うべ
き処置を指示するメッセージ・コード）が実際にそのエ
ラーを発生した確率を伴う、一連のコードである。その
後、エラー・ログのエントリを書き込んだユーティリテ
ィ・ブロック３３０に制御が戻る。あるユーティリティ
がエラー・ログのエントリを書き込んだ時、ブロック３
３３で、事象駆動ＲＡＳマネジャ２４１が実行される。

【００７０】このエラーが重大である（システムのその
部分で是正できない）場合には、ブロック３３４で、問
題ログ内に新規エントリが生成され、このレコードに、
エラー・ログから得られた初期ＦＲＵリストを含めて、
図５ないし７に関して説明したデータが書き込まれる。
診断または他の分析がまだ行なわれていないので、通
常、この初期ＦＲＵリストは、問題ログに書き込む前の
分離ＦＲＵリストよりも長い。次に、ブロック３３５
で、（システム内の従来型の言語選択ユーティリティを
使用して）メッセージにアクセスし、これを図１ないし
４の端末１１３のシステム操作員に表示する。ブロック
９３０で、サブルーチンから図２６のブロック８１０に
戻る。エラーが見つかった場合、ブロック８１０で肯定
の回答が得られ、図２８のサブルーチン１０００が呼び
出される。図２８を参照すると、ブロック１００１で、
この問題がシステムから報告されたか、それともユーザ
から報告されたかを調べる。ユーザが報告した場合に
は、端末１１３からユーザが入力したコマンドに応答し
て、直接このサブルーチンに入る。そうでない場合に
は、図２６のブロック８１０で肯定の回答を得た結果こ
のサブルーチンに入る。

【００７１】システムが検出した場合は、ブロック４１
０に制御が移り、ＰＡＲプログラム２４４が、選択され
た（または最初の）問題の初期ＦＲＵリスト内のコード
に従って、特定のＰＤＰ２４６を選択する。ブロック４
２０で、選択されたＰＤＰ２４６が実行される。ＰＤＰ
は、システムの構成データにアクセスでき、４２０に示
すように、他のＰＤＰを実行させることができる。ＰＤ
Ｐの明らかな結果は、障害確率を伴う、ＦＲＵを指定す
る１つまたは複数のコードである。ＰＤＰは、試験の結
果または操作員入力あるいはその両方によって制御され
る判断木を使用する診断ルーチンである。

【００７２】ブロック４２４で、選択されたＰＤＰによ
って実行された試験の結果が、問題ログのエントリに書
き込まれる。具体的にいうと、障害の確率がもっとも高
いＦＲＵ群を表わす参照コード群が、最後に実行される
ＰＤＰの識別子と出口点を指定するコードと共に、問題
ログ・エントリ内の分離ＦＲＵリスト・フィールドに書
き込まれる。ブロック４２５で、問題ログ・エントリ
に、顧客システムのモデルと通し番号など、その問題に
直接関連する適当なＶＰＤコードが書き込まれる。この
問題ログ・エントリの状況は、この時点で“READY”に
変化する。

【００７３】ブロック４３０で、もっとも確率の高い障
害群を分離ＦＲＵリストから選択し、これらの書式を再
設定し、ＰＤＰの識別子と出口点を示すコードを選択す
ることによって、問題ログ・エントリからの分離ＦＲＵ
リストを症状列に変換する。ブロック４３１で、図５な
いし７の連絡データベース２０１から、または操作員が
このデータベースの情報を指定変更しようと判断する場
合には操作員から、顧客情報を得る。この情報には、連
絡すべき顧客側の人物の氏名と電話番号が含まれ、この
問題の重大度コードも含まれる。このコードは、この問
題の解決の緊急性を示し、任意選択で操作員によって割
り当てられる。また、操作員は、任意選択として、この
問題のテキストによる記述を書いて、この時点でこのサ
ービス要求に含めることができる。その後、ブロック４
４０で、図５ないし７に関して説明した、図９に示す書
式に従って、実際のサービス要求を問題ログのエントリ
に書き込む（ただし、この要求がＰＡＲではなくてＵＰ
ＰＲ処理から来る場合には、ＦＲＵリストは、数値によ
る参照コードではなくて、一連のキー・ワードの形にな
る）。この時点で、この問題ログ・エントリの状況は、
“PREPARED”になる。

【００７４】ＳＲ自体が何の問題も検出していない場合
であっても、そのＳＲに問題があると操作員が判定する
可能性がある。この場合、操作員は、別のコマンドまた
は端末（図１）上の別の機能キーによって、このユーザ
が検出した問題の解決（ＵＰＰＲ）処理を選択する。

【００７５】この場合、ブロック４５０で、操作員から
ある情報を要求するパネルが選択され、表示される。ブ
ロック４５２で、入力データを受け入れ、キー・ワード
に関して操作員の応答を書式設定し、この問題のために
新規に生成された問題ログ・エントリの分離ＦＲＵリス
ト・フィールド内の症状列にそれを書き込む。ブロック
４５３で、このＵＰＰＲ処理中に発生したシステム問題
を検出する。問題が検出された場合、自動的にＰＡＲ処
理実行ブロック４２０に制御が移る。問題が検出されな
い場合は、ブロック４５３から４５４に制御が移り、こ
の問題が十分に分離されたかどうかを調べる。そうでな
い場合は、ブロック４５０に制御が戻り、前の画面に対
する応答によって生成されたキー・ワードに基づいて、
別の画面が選択される。ブロック４５０で表示されるこ
の画面は、ある処置を要求し、システムに関して質問
し、助言情報を表示することができる。ブロック４５４
で、この問題が十分に分離されたと判定された時は、ブ
ロック４３０に制御が移り、前述と同様に処理を継続す
る。

【００７６】ブロック４６０で、このサービス要求を今
送るべきか否かを判定する。この問題検出と判別の処理
が、この時点まで自動的に終わっている場合、ブロック
４６０で通常は肯定の回答が与えられる。しかし、現在
の問題ログ・エントリで識別される問題が、この時点で
解決済みである、すなわち初期ＦＲＵリストまたは分離
ＦＲＵリストからのメッセージに応答して操作員が行っ
た１つまたは複数の処置によって、顧客システムの障害
が矯正されている可能性も十分にある。この場合、操作
員は、ブロック１０１０でこの処理から出ることができ
る。また、操作員は、追加の問題を分析し、これらすべ
てを後で送るか、あるいは顧客担当エンジニアまたは製
品支援要員に直接電話をかけようと判断した場合にも、
この処理から出ることができる。その場合、このサービ
ス要求は、その状況フラグが“PREPARED”状況にセット
され、サービス・システムに送る準備ができていること
を示す状態のままで、記憶装置内に残っている。操作員
が問題解決の継続を選ぶか、または問題が自動的に検出
され、自動的に送られたと思われる場合には、ブロック
４６２で、支援データベース２８０内で、障害の疑いの
ある構成要素を支援するものと識別されるＳＰまたはＳ
Ｐ群に、サービス要求が送られる。通常、ある構成要素
を支援するのは１つのＳＰだけであるが、特定の構成要
素の場合には、複数の異なるＳＰからの支援を受けるこ
とが望ましい。ブロック４６５で、問題ログ内のエント
リを、この問題が“SENT”の状況を有することを示すよ
うに更新する。ブロック１０１０で、このサブルーチン
から図２６のブロック８２０に戻る。

【００７７】ブロック８２０で、あるＳＰ／Ｒが支援す
るＳＲに関するリモートの問題検出および判別を、その
ＳＰ／Ｒが行いたいと望むかどうか判定する。そうであ
る場合、そのＳＰ／Ｒのコンソール（図１の端末１３３
または１５３のうちで、ネットワーク操作員用に予約さ
れた特別の端末）にいる操作員は、リモートにそのＳＲ
と接続され、そのＳＲのコンピュータ・システムにサイ
ン・オンすることを許される。もちろん、この操作員が
そのＳＲのシステムにアクセスできるようになるために
は、ユーザＩＤとパスワードを与えられていなければな
らない。しかし、いったん接続されると、ＳＰ側の操作
員は、図２９および３０に示すサブルーチンを開始し
て、リモートの問題検出および判別を実行することがで
きる。

【００７８】図２９および３０は、図２７および２８に
非常に類似しているが、下記の修正が加えられている。

【００７９】ブロック１２６０（図３０）で、ＳＲ側で
タスクを実行するのに、ＳＲ側で操作員が確保できるか
どうか判定する。確保できない場合、ブロック１２６１
で提示されるパネルを修正して、ＳＲ側で操作員を必要
とするタスクを取り除く。ブロック１２２０で実行され
るＰＤＰ内で、操作員がＳＲ上に存在するか否かを判定
する。存在しない場合、このＰＤＰによって表示される
パネルがあれば、それも同様に修正される。ＳＲ側に操
作員がいないと、問題の分離が少なくなることがある。
問題が検出された場合、ブロック１２７０で、通常なら
解決ログで矯正策を検索するためにサービス要求を準備
するのに使用されるＳＲからの情報が抽出される（サー
ビス要求は不要なので、図３４Ａのブロック１６１１を
有効にスキップする）。矯正策が見つからない場合、ブ
ロック１２７５で、このＳＰ／Ｒがサービス要求装置に
なり、問題のあるＳＲのためのサービス要求を準備す
る。このＳＰ／Ｒは、ブロック１２８０で、このＳＰ／
Ｒの支援データベース内でこの構成要素を支援するもの
として示されるＳＰに、このサービス要求を送る。ブロ
ック１２９０で、このサブルーチンから図２６のブロッ
ク８３０に戻る。図２６の残りの部分については、第Ｉ
Ｖ節および第Ｖ節で論ずる。

【００８０】好ましい実施例では、リモートの問題検出
および判別を実行するのに必要なセッションは、ＡＰＰ
Ｎネットワーク内のＡＰＰＣセッション（ＬＵ ６．
２）である。ただし、専用、交換または公衆データ・ネ
ットワークなど、他の形式の既知の接続を使用すること
も可能である。

【００８１】図３３は、サービス提供装置で実行できる
機能を示す図である。この流れ図は、ＳＰ／Ｒ１３０ま
たはＳＰ１５０のプロセッサ１３１または１５１（図
１）により、問題制御プログラム２９５（図６および
７）によって実行される。ブロック１５０１で、処理す
べきサービス要求があるかどうか調べる。ある場合は、
図３４のサブルーチン１６００を呼び出す。ブロック１
６０１で、処理すべきサービス要求があるかどうか調べ
る。ある場合は、ブロック１６０２で、その資格データ
ベースを検査して、このサービス要求を送ったＳＲが、
故障を疑われている構成要素に対するサービスを受ける
資格を有するかどうか調べる。そうでない場合、ブロッ
ク１６０５で、このＳＲにエラー・メッセージが送ら
れ、ブロック１６０１に制御が戻って、次のサービス要
求を探す。ブロック１６０２で肯定の回答が得られた場
合は、ブロック１６０３で、このサービス要求を、以前
にこのＳＲから受け取ったかどうか調べる。そうである
場合は、ブロック１６０５で、このＳＲにエラー・メッ
セージが送られる。そうでない場合は、ブロック１６１
０で、問題ログ内に、サービス要求を受け取ったことを
示すエントリを作成する。ブロック１６１５で、ＳＰの
コンソールを更新する。ブロック１６１１で、解決ログ
２６２を探索して、この問題に対する可能な解決策を探
す。解決ログ２６２は、ハードウェア、ソフトウェアお
よびマイクロコードの構成要素に関する問題の解決策を
含んでいる。

【００８２】ブロック１６２０で、一致の数が、登録処
理中に指定された閾値（図１４）を超えたかどうか調べ
る。そうである場合、ブロック１６２１で、ＳＰの支援
要員にリンク２８５を介してこの問題が通知され、その
結果、適当な人間の介入を行うことができる。そうでな
い場合、ブロック１６３０で、一致が見つからなかった
かどうか尋ねる。一致が見つからなかった場合、ブロッ
ク１６３１で、別のＳＰがこの構成要素を支援している
かどうか調べる。別のＳＰがこの構成要素を支援するの
は、ａ）このサービス要求が、特定のサービス提供装置
のネットワーク識別子と制御点とを指定する宛先識別子
を含む場合、または、ｂ）別のＳＰがこの構成要素を支
援していることを支援データベースが示す場合である。
そうでない場合、ブロック１６２５で、このサービス要
求が問題予防要求（第Ｖ章で詳細に論ずる）であるかど
うか調べる。そうである場合は、未報告の問題に対する
矯正策が見つからなかったとのメッセージが、ＳＲに送
り返される。そうでない場合は、ブロック１６２１で、
ＳＰの支援要員にこの問題が通知される。ブロック１６
３１で肯定の回答が得られた場合、ブロック１６４０
で、リンク２７５を介して、支援するＳＰにこのサービ
ス要求が転送される。その後、ブロック１６４５で、こ
のサービス要求が別のＳＰに転送されたことを示すメッ
セージがＳＲに送られる。ブロック１６４６で、このＳ
Ｐ内の問題ログの状況が“SENT”に更新され、このＳＰ
のコンソールが更新される。制御の流れはブロック１６
０１に戻って、処理すべき次のサービス要求を探す。

【００８３】ブロック１６３０で否定の回答が得られた
場合、管理できる数の一致が解決ログ内で見つかってい
る。ブロック１６３３で、現在の問題の解決策を指定す
る解決情報が、このＳＰの問題ログ内に記憶される。こ
の解決情報には、下記の種類の情報のうちの１つまたは
複数が含まれる。 ・この問題を解決するためにある処置（たとえば、制御
をリセットする、ケーブルを接続し直す、通信会社のサ
ービス担当員を呼ぶなど）を行うようにとの、ＳＲ側の
操作員に対する指示 ・顧客またはサービス担当員が設置するハードウェア構
成要素を識別する部品番号のリスト ・ソフトウェアまたはマイクロコードの問題を解決する
ためのソフトウェアまたはマイクロコードの構成要素の
リスト

【００８４】ブロック１６５１で、このＳＰの問題ログ
のエントリに状況“ANSWERED”が追加される。ブロック
１６５５で、登録処理中に連絡データベースに入力され
た情報を検査して、この解決情報を自動的に送るかどう
か調べる。そうである場合は、ブロック１６５７で、Ｓ
Ｒに、その解決ログの現在のコピーをＳＰに送るよう要
求する。ＳＰの解決ログは、そのＳＰが知っているＳＲ
からのデータを含むが、ＳＰの解決ログが最新の情報を
含んでいないこともあり得る。これが起こり得るのは、
ＳＲが別のＳＰから解決情報を受け取った場合、または
ＳＲがネットワーク内にない別の供給源から構成要素を
受け取った場合である。

【００８５】ブロック１６６０で、ＳＲから送られた解
決ログをＳＰ自体の解決ログと比較して、このＳＲがす
べての解決情報をすでに受け取っているかどうか調べ
る。そうである場合は、前に送られた解決情報がこの問
題を矯正しなかったので、ブロック１６５６で、ＳＰな
らびにＳＲの支援要員にその旨を通知する。そうでない
場合、ブロック１６６２で、このＳＰ用のハードウェア
を発注し、このＳＰに交換用ソフトウェア構成要素を送
り、ＳＲ側にまだ存在しないマイクロコード構成要素を
送り、あるいはそれらのいずれかを行う。ブロック１６
６３で、すべての解決情報を問題識別子と共にＳＲに送
り、ブロック１６６５で、ＳＲに送られた解決策を反映
するようにＳＰ内の解決ログを更新する。ブロック１６
６６で、ＳＰ側のコンソールを更新し、制御の流れはブ
ロック１６０１に戻って、処理すべき他のサービス要求
を探す。ブロック１６９９で、このサブルーチンから図
３３のブロック１５０２に戻る。

【００８６】図３７は、ＳＲのＳＳＦ２４８が、ブロッ
ク１６６２および１６６３で送られる情報を受け取った
時に実行するステップを示す図である。ブロック１９２
０で、ＳＰから解決情報を受け取り、問題識別子に対応
する問題ログ内のエントリと解決ログ内とにそれを記憶
する。また、ブロック１９２０で、問題ログを検査し
て、この解決情報と共に送られた問題識別子が、別のＳ
Ｒから受け取ったサービス要求に対応するかどうか調べ
る。対応する場合には、この解決情報が、その要求を送
ったＳＲに送られる。ブロック１９２５で、問題ログ内
のエントリの状況をANSWEREDに変更する。ブロック１９
３０で、このＳＲが、ハードウェア、ソフトウェアまた
はマイクロコードの構成要素を受け取り、ブロック１９
３５で、解決ログ内の解決状況フィールドを、ハードウ
ェア、ソフトウェアまたはマイクロコードを受け取った
ことを示すように更新する。これらの構成要素は、要求
元のＳＲが存在するならば、そこに転送される。

【００８７】その後、ブロック１９５０で、この解決策
をそのコンピュータ・システムに導入すべきかどうか尋
ねる。ブロック１９５０は、即座に実行されることも、
数時間、数日あるいは数週間後に実行されることもあ
る。この判断を下す際には、人間が介入することが好ま
しいこともあり、あるいは、登録処理中に支援データベ
ース内の自動導入フィールドに入力された情報に基づい
て判断させることもできる。たとえば、ソフトウェア・
フィックスイット・ショップは、リアリー・ビッグ・コ
ンピュータ社によって支援される構成要素に対する解決
策はすべて自動的に導入するが、サムズ・スプレッドシ
ーツによって支援される構成要素についてはそうしない
と決定することができる。

【００８８】ブロック１９５０で肯定の回答が得られた
場合、ブロック１９５５で、この解決策をそのシステム
に適用し、ブロック１９６０で、状況“FIXED”を追加
して、問題ログのエントリを更新する。またブロック１
９６０で、“APPLIED”（適用済み）の状況を追加し、
解決ログ内のエントリを更新する。

【００８９】ブロック１９７０で、解決策が確認された
かどうか尋ねる。システムが試験され、サービス要求を
開始させた問題がもはや存在しなくなった時、このブロ
ックで肯定の回答が得られる。この確認処理は、図２７
の問題検出の流れ図を再開することによって自動的に行
うことができ、人間が介入して手動で行うこともでき
る。したがって、ブロック１９７０は、即座に実行する
ことも、かなりの遅延後に実行することもできる。ブロ
ック１９７０で肯定の回答を得た場合、ブロック１９７
５で、問題ログを更新して、“VERIFIED”の状況を追加
する。ブロック１９８０で、問題が確認され、ＳＰがそ
の問題ログを更新できることを、そのＳＰに通知する。
ブロック１９８５で、この問題に関連するすべての活動
が完了した時に、再度状況を“CLOSED”に更新する。

【００９０】ＩＶ．サービス・ネットワーク内での問題
の追跡 サービス・ネットワーク内のほとんどの問題は、新しい
状況が問題ログのエントリに追加されるたびに、または
サービス要求が送られ受け取られた時に、追跡すること
ができる。ＳＰは、支援を要求されたすべての問題を、
このようにして追跡することができる。しかし、それに
対する支援要求を受け取っていないＳＲ上で発生する問
題は、通常はＳＰに知られない。この追加の情報を提供
するために、「助言」を使用する。サービス・ネットワ
ーク内のどのシステムも、助言を使用して、サービス・
ネットワーク内の１つまたは複数のシステムに、サービ
ス・ネットワーク内の別のシステムに関して発生した問
題について知らせることができる。

【００９１】したがって、助言を使用して、サービス要
求を介して受け取った、サービス・ネットワーク内の他
のシステムに関する状況情報を補完することができる。

【００９２】再び図２６を参照すると、ブロック８３０
で、送るべき助言があるか否かを調べる。ある場合は、
図３１のサブルーチン１３００が呼び出される。

【００９３】ブロック１３０３で、助言メッセージを作
成する。この助言メッセージは、構成要素識別子、問題
に関するテキストによる情報または符号化された情報、
およびこの助言の送出元を識別する情報を含む。ブロッ
ク１３０４で、この助言メッセージが適当なＳＰまたは
ＳＲに送られる。これは、支援データベース２０３また
は資格データベース２７０を検査して、どのＳＰ、ＳＰ
群、ＳＲまたはＳＲ群が指定された構成要素識別子に対
する助言を支援し、あるいは助言を受け取る資格を有す
るかを調べることによって決定される。別法として、構
成要素識別子フィールドに、この助言を支援データベー
スまたは資格データベース内で参照されるすべてのＳＰ
またはＳＲに送るように指示する、特別の同報通信デー
タを含めてもよい。ブロック１３２０で、このサブルー
チンから図２６のブロック８４０に戻る。ブロック８４
０とサブルーチン１４００については、後で第Ｖ節で考
察する。

【００９４】次に、図３３を参照すると、ブロック１５
０２で、処理すべき助言があるかどうか尋ねる。ある場
合は、図３５のサブルーチン１７００が呼び出される。
ブロック１７０１で、処理すべき助言があるかどうか調
べる。ある場合は、ブロック１７７０で、受け取った助
言の性格を示すようにコンソールを更新する。ブロック
１７９０で、このサブルーチンから図３３のブロック１
５０３に戻る。図３３のブロック１５０３および１８０
０については、後で第Ｖ節で論ずる。サブルーチン１７
００は、ＳＲにコンソールがある場合には、ＳＲ内のＳ
ＳＦ２４８によっても実行されることに留意されたい。

【００９５】助言とサービス要求を、サービス・ネット
ワーク内の様々なシステム上の問題ログ、解決ログおよ
び連絡データベース内に記憶された情報と共に使用する
ことにより、分析および監視のために豊富な情報が使用
できるようになる。例として、ピート仕出し屋のピート
が、自分の調理法データベースを使用中であり、好みの
ミート・ローフの調理法を見つけられないと仮定しよ
う。彼は、図２８の流れ図を使って、ユーザから報告さ
れた問題を分離し、ブロック４４０でサービス要求を書
き込む。ブロック４６０で、調理法データベースの矯正
を支援するＳＰがソフトウェア・フィックスイット・シ
ョップであると判定され、このサービス要求がそこに送
られる。ソフトウェア・フィクスイット・ショップは、
図３４の流れ図を実行して、この問題に対する解決策
（ミート・ローフの調理法自体、すなわちソフトウェア
構成要素）をその解決ログ内で見つける。ソフトウェア
・フィクスイット・ショップは、この解決情報とミート
・ローフ調理法をピート仕出し屋に送り、問題ログを更
新する。ピートは、この調理法と解決情報を受け取り、
問題ログと解決ログを更新する。

【００９６】ピート仕出し屋側のＳＳＦ２４８は、問題
ログに含まれる情報を抽出して、操作員のために任意の
時点で任意の問題を表示する能力を有する。ミート・ロ
ーフ調理法に関する問題の回答が出た後にピート仕出し
屋の操作員に示される画面の例を、図３８および３９に
示す。図４０および４１は、ソフトウェア・フィクスイ
ット・ショップの操作員に示される、同じ問題の状況を
表示する画面の例である。

【００９７】別法として、ソフトウェア・フィックスイ
ット・ショップのコンソールを使って、このサービス・
ネットワーク全体またはその一部の状況を、図形的に監
視することも可能である。ピート仕出し屋からサービス
要求を受け取った後に、ソフトウェア・フィックスイッ
ト・ショップのコンソールがどう見えるかという画面の
例を、図４２に示す。操作員が見たいと思うネットワー
ク内の各ＳＲおよびＳＰが、画面上に表示される。ネッ
トワーク内の様々なコンピュータ・システムをアイコン
で表示し、コンピュータ・システムを表わすアイコンの
外観をネットワーク内のそのコンピュータ・システムの
状況を反映するように変化させることが好ましい。図４
２には、破線の枠で表わしたピート仕出し屋に向かう実
線が示されている。これは、未回答のサービス要求をピ
ート仕出し屋から受け取ったことを表している。図で
は、ジョー食料品店とレフティはさみ屋は、実線で実線
の枠に接続されている。これは、ジョー食料品店とレフ
ティはさみ屋のコンピュータ・システムが立ち上がって
おり、正常に実行中であることを表わしている。ウィリ
ー部品屋は、実線で接続されているが、点線の枠を有す
る。これは、以前にウィリーによって報告された問題
が、ソフトウェア・フィックスイット・ショップから回
答されたことを表わす。

【００９８】ソフトウェア・フィックスイット・ショッ
プのコンソールでは、ＳＰのうちの１つ、サムズ・スプ
レッドシーツが、星印の枠で表わされている。これは、
サムズ・スプレッドシーツから助言を受け取った直後で
あることを示す。操作員は、機能キーを押して、この助
言に関する追加情報を表示することができる。コンソー
ル上でのシステム状況の表現の選択は、設計者または操
作員による設計の選択である。コンソールがカラーと様
々な属性を支援する場合は、状況の変化を示すために、
アイコンの色を変え、点滅させ、明るくまたは暗くし、
その他の変化を行うことができる。たとえば、赤く点滅
するアイコンは、受け取ったが回答されていないサービ
ス要求を表す。

【００９９】Ｖ．サービス・ネットワーク内での問題の
予防 Ａ．サービス要求装置から要求 すでに論じたように、ＳＲは、支援されるリスト中の構
成要素に関して、問題の既知の矯正策を要求することに
よって、それ自体で問題予防を実行することができる。
図２６に示すように、ブロック８４０で、支援されるプ
ログラムに関して矯正策を要求するかどうか尋ねられ
る。そうである場合は、図３２のサブルーチン１４００
が呼び出される。ブロック１４０１で、所望の問題予防
要求の種類を定義する。ＳＲが、ＳＰに支援を要求する
全構成要素に関するすべての矯正策を受け取りたいと望
む場合、問題予防は、登録時に行うことができる。特定
の構成要素に関して周期的に問題予防を行うこともでき
る。たとえば、ピート仕出し屋は、スプレッドシート・
プログラムの変更の際に、継続的に更新を受けたいと決
定する。したがって、毎月１日に、スプレッドシート・
プログラムについて問題予防を求める要求が、ピート仕
出し屋のシステムで自動的に生成される。問題予防は、
ＳＲの操作員の要求時に、１つまたは複数の選択された
構成要素について行うこともできる。所望の問題予防要
求の種類を決定するのに必要な情報は、支援データベー
ス２０３に記憶される。

【０１００】再び図３２を参照すると、ブロック１４１
０で、問題予防を要求すべき構成要素があるかどうか尋
ねる。ある場合は、ブロック１４１４で、連絡データベ
ースから顧客情報を得、ブロック１４２０で、図９Ｂに
示されるサービス要求を書き込む。図９Ｂのサービス要
求は、このサービス要求が指定された構成要素識別子に
対する問題予防要求であることを示すフィールドを含
む。これらのフィールドは、図９Ａに示すような、既知
の問題がある時に生成されるサービス要求に関連する、
症状列およびＦＲＵリストのフィールドと入れ替わる。
ブロック１４５０で、このサービス要求を今送るかどう
か尋ねる。そうである場合は、ブロック１４６０で、支
援データベースを検査することによって、どのＳＰ
（群）がこのサービス要求に関連する構成要素を支援す
るかを判定し、このサービス要求をそのＳＰに送る。い
ずれの場合でも、制御の流れはブロック１４１０に戻
る。ブロック１４１０で、すべての問題予防要求が満足
されたと判定されると、ブロック１４９０で、このサブ
ルーチンから図２６のブロック８９０に戻る。

【０１０１】このサービス要求は、ＳＰが受け取り、前
述したように、図３４の流れ図を実行することによって
処理する。

【０１０２】Ｂ．サービス提供装置から要求 サービス提供装置は、それが支援するどのサービス要求
装置に対しても、問題予防を実行することができる。Ｓ
Ｐは、それが支援する１つまたは複数のＳＲに存在する
が、まだ発見も報告もされていない問題に対する解決策
を有するかどうか調べる。これを図３３に示す。図３３
のブロック１５０３で、ＳＰに、問題予防の実行を望む
かどうか尋ねる。そうである場合は、図３６のサブルー
チン１８００が呼び出される。ブロック１８０２で、資
格データベース２７０を探索して、ＳＲがどの構成要素
に対する矯正策を受け取る資格を有するかを調べる。ブ
ロック１８０５で、解決ログを探索して、必要条件フィ
ールド内の情報から、このＳＰが出した問題予防要求に
応答して送るのに使用できることが示される矯正策をす
べて見つける。役に立たない矯正策の不要な転送を避け
るために、問題を矯正したとＳＲが報告した（したがっ
て、“VERIFIED”の状況を有する）矯正策のみに、問題
予防を限定することが好ましいであろう。

【０１０３】ブロック１８０７で、その解決ログの現在
のコピーをＳＰに送るようＳＲに要求する。ＳＰの解決
ログは、そのＳＰが知っているＳＲからのデータを含ん
でいるが、ＳＰの解決ログが最新の情報を含んでいない
こともあり得る。これは、ＳＲが別のＳＰから解決情報
を受け取った場合、またはＳＲがネットワーク内にない
別の供給源から構成要素を受け取った場合に起こり得
る。

【０１０４】ブロック１８１０で、ＳＲから送られた解
決ログを、ＳＰ自体の解決ログと比較して、ＳＲが検出
していない、または報告していない（ＳＲの解決ログに
存在しない）解決策を探す。ブロック１８２０で、矯正
すべき未報告の問題があるかどうか調べる。

【０１０５】ある場合は、ブロック１８５０で、ハード
ウェア部品を注文し、ソフトウェア構成要素、マイクロ
コード構成要素またはテキストによる指示をＳＲに送
る。ブロック１８６０で、解決情報をＳＲに送る。ブロ
ック１８７０で、ＳＰ側の解決ログ、問題ログおよびコ
ンソールを更新し、ブロック１８２０に戻って、さらに
実行すべき問題予防を探す。ブロック１８２０で否定の
回答が得られた場合は、ブロック１８９０で、このサブ
ルーチンから図３３のブロック１５９０に戻る。ＳＲ
は、解決情報を受け取ると、前述のように図３７の流れ
図を実行する。

【０１０６】

【発明の効果】本発明によって、コンピュータ・システ
ムのサービス・ネットワークにあるコンピュータ・シス
テムを自動的に登録することが可能になる。

【図面の簡単な説明】

【図１】本発明のサービス・ネットワークを単純化して
示す図である。

【図２】本発明のより複雑なサービス・ネットワークを
示す図である。

【図３】本発明の代表的なサービス・ネットワークを示
す図である。

【図４】本発明の非常に複雑なサービス・ネットワーク
を示す図である。

【図５】本発明のサービス要求装置のブロック図であ
る。

【図６】本発明のサービス提供・要求装置のブロック図
である。

【図７】本発明のサービス提供装置のブロック図であ
る。

【図８】本発明の問題ログのエントリに含まれるフィー
ルドを示す図である。

【図９】本発明のサービス要求に含まれるフィールドを
示す図である。

【図１０】本発明の解決ログのエントリに含まれるフィ
ールドを示す図である。

【図１１】本発明の資格データベースのエントリに含ま
れるフィールドを示す図である。

【図１２】本発明の支援データベースのエントリに含ま
れるフィールドを示す図である。

【図１３】サービス提供装置による、サービス・ネット
ワークへのサービス要求装置の登録を示す流れ図であ
る。

【図１４】登録処理中に表示される画面の例を示す図で
ある。

【図１５】登録処理中に表示される画面の例を示す図で
ある。

【図１６】登録処理中に表示される画面の例を示す図で
ある。

【図１７】登録処理中に表示される画面の例を示す図で
ある。

【図１８】登録処理中に表示される画面の例を示す図で
ある。

【図１９】登録処理中に表示される画面の例を示す図で
ある。

【図２０】登録処理中に表示される画面の例を示す図で
ある。

【図２１】サービス要求装置による、サービス提供装置
のサービス・ネットワークへの登録の流れ図である。

【図２２】登録処理中に表示される画面の例である。

【図２３】登録処理中に表示される画面の例である。

【図２４】登録処理中に表示される画面の例である。

【図２５】図１３および２１に示された登録処理がどの
ようにして承認されるかを示す図である。

【図２６】サービス要求装置によって、またはサービス
要求装置のために行われる、問題の検出、判定および報
告を示す図である。

【図２７】サービス要求装置によって、またはサービス
要求装置に対して行われる、問題の検出、判定および報
告を示す図である。

【図２８】サービス要求装置によって、またはサービス
要求装置に対して行われる、問題の検出、判定および報
告を示す図である。

【図２９】サービス要求装置によって、またはサービス
要求装置に対して行われる、問題の検出、判定および報
告を示す図である。

【図３０】サービス要求装置によって、またはサービス
要求装置に対して行われる、問題の検出、判定および報
告を示す図である。

【図３１】サービス提供装置にどのようにして助言を送
るかを示す図である。

【図３２】サービス要求装置が、どのようにしてそのコ
ンピュータ・システムの支援される構成要素に対する矯
正策を要求するかを示す図である。

【図３３】サービス提供装置が実行できる機能を示す図
である。

【図３４】サービス提供装置がどのようにしてサービス
要求を処理するかを示す図である。

【図３５】サービス提供装置がどのようにして助言を処
理するかを示す図である。

【図３６】サービス提供装置が、どのようにしてサービ
ス要求装置のための問題予防策を実行するかを示す図で
ある。

【図３７】サービス要求装置が、どのようにしてサービ
ス提供装置から受け取ったデータを処理するかを示す図
である。

【図３８】問題追跡画面の例である。

【図３９】問題追跡画面の例である。

【図４０】問題追跡画面の例である。

【図４１】問題追跡画面の例である。

【図４２】問題追跡のためにコンソールに図形表示され
る画面の例である。

【符号の説明】

１１０ サービス要求装置（ＳＲ） １３０ サービス提供・要求装置（ＳＰ／Ｒ） １５０ サービス提供装置（ＳＰ） ２０１ 連絡データベース ２０２ 解決ログ ２０３ 支援データベース ２１０ オペレーティング・システム・プログラム（Ｏ
Ｓ） ２４２ エラー・ログ ２４３ 問題ログ ２４４ 問題分析・解決（ＰＡＲ）プログラム ２４６ 問題判別手順（ＰＤＰ） ２４８ システム支援ファシリティ（ＳＳＦ）プログラ
ム ２４９ サービス要求 ２６１ 問題ログ ２６２ 解決ログ ２６３ 連絡データベース ２７０ 資格データベース ２９５ 問題制御プログラム

フロントページの続き (72)発明者 ジョン・ルイス・ケーラー アメリカ合衆国55901、ミネソタ州ロチェ スター、シャレ・ドライブ・ノース・ウェ スト 967番地 (72)発明者 エリック・ドュエーン・リンドバーグ アメリカ合衆国55906、ミネソタ州ロチェ スター、リバーサイド・レーン・ノース・ イースト 2685番地 (72)発明者 マーク・アンブローズ・マッケルヴィー アメリカ合衆国55902、ミネソタ州ロチェ スター、23番ストリート・サウス・ウェス ト 114番地 (72)発明者 スティーブン・ポール・マーボッシュ アメリカ合衆国55904、ミネソタ州ロチェ スター、24番ストリート・サウス・イース ト 842番地 (72)発明者 ジェフリー・アラン・ニュートン アメリカ合衆国55901、ミネソタ州ロチェ スター、スカーバラ・レーン・ノース・イ ースト 4524番地 (72)発明者 ジョー・バリー・スカーバラ アメリカ合衆国55902、ミネソタ州ロチェ スター、ルーラル・ルート８ (72)発明者 ルース・アン・アップチャーチ アメリカ合衆国55906、ミネソタ州ロチェ スター、リッジ・コート・ノース・イース ト 1526番地 (72)発明者 サンドラ・ドロシー・ウェストリング アメリカ合衆国55901、ミネソタ州ロチェ スター、カントリー・ヴュー・コート・ノ ース・ウエスト 5904番地

Claims (6)

【特許請求の範囲】
1. 【請求項１】コンピュータ・システムのサービス・ネッ
   トワークにサービス提供装置を登録する方法であって、 前記サービス要求装置に関する連絡情報を識別するステ
   ップと、 前記サービス要求装置がサービスを受け取りたいと望む
   構成要素のリストを決定するステップと、 前記連絡情報と前記構成要素リストから、登録要求を作
   成するステップと、 前記登録要求をサービス提供装置に送るステップと、 前記サービス提供装置から登録確認通知を受け取るステ
   ップとを含む方法。
2. 【請求項２】さらに、前記登録確認通知の受け取り時
   に、支援データベースを更新するステップを含む、請求
   項１の方法。
3. 【請求項３】コンピュータ・システムのサービス・ネッ
   トワークにサービス要求装置を登録する方法であって、 前記サービス要求装置に関する連絡情報を識別するステ
   ップと、 前記連絡情報と構成要素リストから、登録要求を作成す
   るステップと、 前記登録要求を前記サービス要求装置に送るステップ
   と、 前記サービス要求装置から登録確認通知を受け取るステ
   ップと、 前記サービス要求装置がサービスを受ける資格を有する
   構成要素のリストを決定するステップとを含む方法。
4. 【請求項４】さらに、前記登録確認通知の受け取り時
   に、資格データベースを更新するステップを含む、請求
   項３の方法。
5. 【請求項５】コンピュータ・システムのサービス・ネッ
   トワークにサービス要求装置を登録する方法であって、 連絡情報と前記サービス要求装置がサービスを望む構成
   要素のリストとを含む登録要求を前記サービス要求装置
   から受け取る機械実行ステップと、 資格データベース内に以前に入力された情報に基づい
   て、前記登録要求を自動的に承認する機械実行ステップ
   と、 登録確認通知を前記サービス要求装置に送る機械実行ス
   テップとを含む方法。
6. 【請求項６】さらに、前記登録要求が承認された後に、
   前記資格データベースを更新するステップを含む、請求
   項５の方法。