JP3381926B2 - 一般的なウエブ・ブラウザが複数の異なるプロトコル型のサーバをアクセスすることを可能にするための情報ハンドリング・システム - Google Patents

Description

【発明の詳細な説明】 発明の分野 本発明は、ネットワーク化された複数の情報処理シス
テムを有する情報ハンドリング・システムに係り、更に
詳細に説明すれば、クラス・ライブラリを使用してWWW
（ワールド・ワイド・ウェブ）と呼ばれるサーバ・コン
ピュータ・システム（以下「サーバ」と略記）を開発す
るためのオブジェクト指向技術に係る。本発明の背景に
関する一層詳細な説明については、以下の記述を参照さ
れたい。

発明の背景 過去２年の間、ほぼ全世界にまたがるコンピュータ・
ネットワークの集合体としてのインターネットの利用、
特にその最上部に構築したシステムの１つであるWWWの
利用が爆発的に増加した。WWWを構成する多数のページ
又は情報ファイルは、多数の異なるサーバにまたがって
分散されている。例えば、かかるページ上に格納される
情報は、或る企業の組織や、連絡先データ、製品データ
及びその企業に関係するニュース等の詳細とすることが
できる。この情報は、テキスト、グラフィック、音声及
びビデオ・データを組み合わせた形態で、クライアント
・コンピュータ・システム（以下「クライアント」と略
記）としてのユーザのコンピュータ・システムに提供す
ることができる。各ページは、URL（未入手資源ロケー
タ）によって識別される。URLは、サーバと、このサー
バ上の特定のファイル又はページの両方を指定する。単
一のサーバ上には、多数のページ又はURLが存在するこ
とがある。

WWWを利用するため、各クライアントは、グラフィカ
ル・ウェブ・ブラウザと呼ばれる小さなソフトウェア、
例えば（IBM社のOS/2の一部として提供される）WebExpl
orerや、ネットスケープ・コミュニケーション社のNavi
gatorプログラムを実行する。なお、「WebExplorer」、
「OS/2」及び「IBM」は、インターナショナル・ビジネ
ス・コーポレイションの商標であり、「Navigator」及
び「Netscape」は、ネットスケープ・コミュニケーショ
ン社の商標である。クライアントがブラウザと対話して
特定のURLを選択する場合、ブラウザは、当該URL又はペ
ージのための要求を当該URLが識別するサーバに送信す
る。サーバは、この要求に応じて、要求対象のページを
検索するとともに、その要求データを要求元のクライア
ントに返送する（クライアントとサーバとの間の対話
は、HTTP（ハイパーテキスト転送プロトコル）に従って
行われる）。次に、このページは、クライアントの画面
を通してユーザに表示される。また、クライアントは、
例えば、特定のトピックに関係するWWWページを探索す
るためのアプリケーションを立ち上げるように、サーバ
に要求することができる。

殆どのWWWページは、HTML（ハイパーテキスト・マー
クアップ言語）で書かれたプログラムに従ってフォーマ
ット化されている。このプログラムは、クライアントの
グラフィカル・ブラウザを介して表示すべきデータを保
持するほかに、ブラウザに対し当該データの表示方法を
指示するためのフォーマット化コマンドを保持する。か
くて、代表的なウェブ・ページには、テキストが含まれ
ているだけでなく、タグと呼ばれるフォーマット化コマ
ンドが埋め込まれているから、これらのコマンドを使用
して、フォントの大きさや、フォントのスタイル（例え
ば、イタリック又は太字）や、テキストのレイアウト方
法等を制御することができる。ウェブ・ブラウザは、指
定されたフォーマットに従ってテキストを表示するため
に、HTMLスクリプトの「解析」を行う。また、HTMLタグ
を使用すると、クライアントのブラウザを介してユーザ
に表示すべきグラフィック、音声及びビデオ・データの
表示形態を指示することができる。

殆どのウェブ・ページは、元のページと同一のサーバ
上に必ずしも存在しない処の、他のウェブ・ページに対
する１つ以上の参照を含んでいる。かかる参照を活動化
するには、ユーザが画面上の特定の位置を選択したり、
マウスの制御ボタンを（ダブル）クリックするのが普通
である。これらの参照又は位置は、「ハイパーリンク」
と呼ばれていて、ブラウザが特定の様式でフラグするよ
うになっている（例えば、各ハイパーリンクに関連する
テキストを、目立ちやすいカラーで表示することがあ
る）。もし、ユーザがこのハイパーリンクを選択すれ
ば、参照されたページが検索されて、現に表示されてい
るページに置き換わることになる。

HTML及びWWWに関する詳細の情報については、Douglas
McArthur,“World Wide Web and HTML",Dr Dobbs Jour
nal,December 1994,pp.18−26及びIan Graham,“The HT
ML SourceBook"（John Wiley,New York,1995）を参照さ
れたい。

HTMLを受理してこれを表示する一般的なウェブ・ブラ
ウザは、アプリケーションの開発者に対し、顕著な能力
を与える。即ち、ユーザ・インタフェースを実現するた
めにブラウザを使用すると、次の２つの利点を享受する
ことができるからである。

第1:通信プロトコル（HTTP）が埋め込まれる。

第2:ユーザ・インタフェース環境（HTML）が埋め込ま
れる。

通信とユーザ・インタフェースは、プラットフォーム
に依存する度合いが極めて高いという理由で、アプリケ
ーション開発の非常に高価な２つの分野になっている。
これらの２つの問題が存在するために、多くのアプリケ
ーションは、全てのカストマに行きわたっていない。

現在、HTTP TCP/IPとは異なる通信プロトコルを使用
して伝送を行うようにウエブ・ブラウザ／サーバは、全
く存在しない。しかしながら、設置済みの多数のコンピ
ュータは、Net BIOS、IPX及び直列回線のような、種々
の通信プロトコルを使用している。これらのコンピュー
タのユーザは、TCP/IP接続の使用を必要とせずに、ウェ
ブ・ブラウザ／サーバ技術を使用することを望む場合が
ある。この技術は、かかる制約により制限される。

この技術が特に重要となる１つの環境は、システム管
理である。効率的なシステム管理は、設置済みコンピュ
ータが大型であるか小型であるかを問わず、その動作に
とって非常に重要である。システム管理のタスクを改良
するために、これまで多数のアプリケーションが開発さ
れてきた。これらのアプリケーションが試みたことは、
これらのコンピュータのユーザ又はシステム管理者に対
し一層強力な管理能力を与えるために、不可解なハード
ウェア及びオペレーティング・システム（以下「OS」と
略記）に依存するコンピュータの監視結果及び制御手段
を抽象化し且つこれらを照合する、というものである。

最近のシステム管理ソフトウェアでは、グラフィカル
・ユーザ・インタフェース（GUI）を通して、監視結果
及び制御手段が表示及び制御されるようになっている。
本発明に即して説明すれば、これらのシステム管理アプ
リケーションは、次の２つの問題点を有している。即
ち、（１）これらのGUIは、特定のコンピュータ上で実
行するように制約されているだけでなく、制限されたプ
ロトコルを通してのみベースのシステム管理オブジェク
トと通信するように制約されており、また（２）システ
ム管理アプリケーションを他のコンピュータ又はプロト
コルに移動させるには、この新しいプラットフォーム用
のGUIを再びコード化しなければならない、ということ
である。現在の技術は、これがサポートするコンピュー
タに対してのみ、システム管理データを供給するに過ぎ
ない。従って、かかる現在の技術には、強力で且つ柔軟
なシステム管理インタフェースに対する諸障壁が存在す
る。

発明の要約 本発明が提供せんとする情報ハンドリング・システム
は、一のクライアント・コンピュータ装置が、一のサー
バ・コンピュータ装置に置かれている情報をアクセスす
ることを可能にする。前記クライアント・コンピュータ
装置は、ハイパーテキスト転送プロトコル（HTTP）を使
用して前記サーバ・コンピュータ装置と通信するための
手段と、前記サーバ・コンピュータ装置から受信される
情報をハイパーテキスト・マークアップ言語（HTML）を
使用して当該クライアント・コンピュータ装置の一のユ
ーザに供給するための手段とを含んでいる。前記情報ハ
ンドリング・システムは、その特徴的構成として、前記
クライアント及びサーバ・コンピュータ装置間に設けら
れた一のネットワークと、伝送プロトコル変換手段とを
備えている。前記ネットワークは、HTTPとは異なる一の
ネットワーク伝送プロトコルを使用するとともに、HTML
とは異なる一のネットワーク・データ・フォーマットを
使用する。他方、前記伝送プロトコル変換手段は、前記
クライアント及びサーバ・コンピュータ装置から前記ネ
ットワークを介して送信されるか又は前記ネットワーク
を介して前記クライアント及びサーバ・コンピュータ装
置によって受信されるHTML/HTTP情報を、前記ネットワ
ーク伝送プロトコル及び前記ネットワーク・データ・フ
ォーマットに変換するように機能する。

前述の要件に加えて、本発明の前記情報ハンドリング
・システムは、次の要件を満足することが好ましい。即
ち、前記クライアント・コンピュータ装置の前記情報を
供給するための手段が、特定の型のグラフィカル・ユー
ザ・インタフェースを使用し、前記クライアント・コン
ピュータ装置が、インターネットに接続され、前記ネッ
トワークが、前記インターネットと前記サーバ・コンピ
ュータ装置の間に設けられ、前記伝送プロトコル変換手
段が、一のHTMLオブジェクト及び一のHTTPオブジェクト
を含むオブジェクト指向のコンピュータ・ソフトウェア
を実行し、前記HTMLオブジェクトが、前記クライアント
・コンピュータ装置からHTML要求データを受理し且つ当
該受理済みのHTML要求データを前記ネットワーク・デー
タ・フォーマットに変換し、前記HTTPオブジェクトが、
前記クライアント及びサーバ・コンピュータ装置間でイ
ンターネット接続をオープン及び維持し、前記クライア
ント・コンピュータ装置から受信される前記HTML要求デ
ータを解析し、前記クライアント・コンピュータによっ
て使用される前記特定の型のグラフィカル・ユーザ・イ
ンタフェースの識別子を検出し、前記要求データ及び検
出済みのグラフィカル・ユーザ・インタフェースの識別
子を前記HTMLオブジェクトに伝送するとともに、HTMLデ
ータを前記ネットワーク及び前記インターネットを介し
て前記HTMLオブジェクトと前記クライアント・コンピュ
ータ装置の間で転送する、ということである。

第２の側面において、本発明が提供せんとする情報ハ
ンドリング・システム用の一のプログラム要素は、前記
情報ハンドリング・システム上で実行される際に、デー
タと（ａ）HTML及びHTTP、並びに（ｂ）少なくとも１つ
のコマンド及びHTML又はHTTPの何れとも異なるプロトコ
ルの間のマッピングを行うための一のマッピング・ブロ
ックを備えている。前記マッピング・ブロックは、一の
HTMLオブジェクト及び一のHTTPオブジェクトを有してい
る。前記HTMLオブジェクトは、URL（未入手資源ロケー
タ）及び他の要求データを受理し、受理済みの要求を内
部コマンド及びHTML又はHTTPの何れとも異なるプロトコ
ルに形成し、内部コマンド及びHTML又はHTTPの何れとも
異なるプロトコルの形式を有する応答を受理し、受理済
みの応答をHTMLに変換するとともに、当該HTMLを前記HT
TPオブジェクトに送信するように機能する。他方、前記
HTTPオブジェクトは、インターネット通信をオープン及
び維持し、前記インターネットを介してHTTP要求を受理
し、受理済みの要求を形成するURL及び関連するデータ
を解析し、当該URL、関連するデータ及びブラウザ・プ
ログラムの識別子を前記HTMLオブジェクトに伝送し、前
記HTMLオブジェクトからHTMLソースを受理するととも
に、HTMLソースをHTTPと応答して前記インターネットに
戻すように機能する。

また、本発明は、インターネット上のどこかに接続さ
れる任意のブラウザが、一のシステム管理プロトコルの
諸イベントを表示及び制御するために、一のグラフィカ
ル・ユーザ・インタフェースとして機能することを可能
にする。

図面の簡単な説明 本発明の幾つかの目的は前述の通りであるが、他の目
的は、以下の添付図面を参照して行われる後段の説明か
ら次第に明らかとなるであろう。

図1Aは、典型的なパーソナル・コンピュータ・システ
ム（以下「パーソナル・コンピュータ」と略称）の斜視
図である。

図1Bは、本発明に従った装置及び方法を実施した情報
ハンドリング・ネットワークを示す図である。

図２は、図1Aのパーソナル・コンピュータ用の統合化
プレーナ・ボードの概略ブロック図である。

図３は、図1Aのパーソナル・コンピュータ用の代替的
なプレーナ・ボードの概略ブロック図である。

図４は、図３の代替的なプレーナ・ボードに関連して
使用するプロセッサ・カードの概略ブロック図である。

図５は、本発明に従った図1Bの情報ハンドリング・ネ
ットワークを介してシステム構成情報を通信するために
取られる諸ステップの流れ図である。

図６は、図５の流れ図で取られる幾つかのステップの
一層詳細な流れ図である。

図７は、例示的フレームワーク機構のカテゴリ図であ
る。

図８〜図12は、図７の例示的フレームワーク機構のク
ラス図である。

図13は、図７〜図12の例示的フレームワーク機構のオ
ブジェクト図である。

図14A及び図14Bは、図1Bのネットワークを通して行わ
れる、本発明のシステム管理の実施例を示す図である。

図15は、図14A及び図14Bに示したマッピング・ブロッ
クの要素を示す図である。

推奨実施例の説明 以下、本発明の背景に係る技術を一層詳細に説明す
る。当該技術において高度な知識を有する読者は、以下
の背景情報に係る説明を読んでも読まなくても良いが、
この情報は本発明を理解するのに重要であるので、これ
を十分に検討することを勧める。

本発明の推奨実施例を示した添付図面を参照して本発
明を詳述するに先だち、当業者は、本発明の効果を享受
しつつ本明細書中で説明した本発明を適宜に変更又は修
正しうることを理解すべきである。従って、以下の説明
は、当業者に向けられた広範な技術的教示を開示してい
るに過ぎず、本発明の技術範囲を制限するものではない
ことを理解すべきである。

ハードウェア環境 一般のパーソナル・コンピュータ、特にIBM社のパー
ソナル・コンピュータは、現在社会の多くの分野に対し
コンピュータ能力を提供するために、広範に使用される
ようになってきた。一般に、パーソナル・コンピュータ
は、形態的には、デスク・トップ型、床置き型及び携帯
型に類別され、構成的には、システム・プロセッサを有
するシステム・ユニット、表示モニタ、キーボード、１
つ以上のディスケット駆動装置、固定ディスク記憶、オ
プションのマウス及び印刷装置を含んでいる。これらの
システムは、主として、個々のユーザ又は小グループの
ユーザに対し、独立の計算能力を与えるように設計され
ており、個人又は企業が購入しやすいように安価な価格
で提供されている。かかるパーソナル・コンピュータ
は、商標として、例えば「IBM PERSONAL COMPUTER」、
「PERSONAL COMPUTER XT」、「PERSONAL COMPUTER AT」
及び「IBM PERSONAL SYSTEM/2」（以下、IBM PC、XT、
AT及びPS/2とそれぞれ略称）を付したモデル25、30、5
0、55、57、60、65、70、80、90及び95として提供され
ている。

一般に、これらのパーソナル・コンピュータは、２つ
のファミリに分類することができる。第１のファミリ
は、「ファミリ１モデル」と呼ばれ、ATコンピュータ及
び他の「IBM互換」マシンによって代表されるバス・ア
ーキテクチャを使用する。第２のファミリは、「ファミ
リ２モデル」と呼ばれ、IBM社のPS/2モデル50〜95によ
って代表される「マイクロチャネル」バス・アーキテク
チャを使用する。ファミリ１及びファミリ２モデルが使
用するこれらのバス・アーキテクチャは、当該技術分野
では周知である。

IBM PC及びXTは、IBM社のパーソナル・コンピュータ
・ラインの最初のモデルであり、インテル社の8088プロ
セッサを使用していた。IBM社のパーソナル・コンピュ
ータに対する次の重要な変更は、ATであって、これはイ
ンテル社の80286プロセッサを使用していた。他方、PS/
2のラインは、インテル社の幾つかのプロセッサを使用
していた。即ち、モデル30は8086を使用し、モデル50及
び60は両者とも80286を、モデル70の或るバージョン及
びモデル80は80386を、モデル70の他のバージョン、モ
デル90のXP 486及びモデル95のXP 486は80486を使用
していた。これらの全てのパーソナル・コンピュータの
共通点は、インテル社のX86ファミリ・プロセッサを使
用しているということである。容易に入手可能で且つ周
知の種々のOS、例えばDOS又はOS/2は、インテル社のX86
ファミリ・プロセッサ上で動作することができる。

また、ファミリ１モデルの最も初期のパーソナル・コ
ンピュータ（例えば、IBM PC）の時点から、ソフトウ
ェアとハードウェアの互換性を維持するという目標が最
も重要であることが認識されていた。この目標を達成す
るため、「マイクロコード」と呼ばれる常駐コードの隔
離層が、ソフトウェアとハードウェアの間に設定され
た。このコードは、ユーザのアプリケーション/OSとハ
ードウェア装置の間に動作インタフェースを提供して、
ハードウェア装置の特性を考慮するという重荷からユー
ザを解放した。このコードは、最終的に基本入出力シス
テム（以下「BIOS」と略記）として開発され、これによ
りアプリケーション/OSをハードウェア装置の特性から
隔離しつつ、新しいハードウェア装置をシステムに追加
することが可能となった。BIOSが重要である所以は、こ
れによって装置ドライバが特定のハードウェア装置の特
性に依存しなくなり、しかもハードウェア装置への中間
インタフェースを有する装置ドライバを提供することが
できる、という点にある。BIOSは、パーソナル・コンピ
ュータの不可分の部分を構成していて、システム・プロ
セッサと授受すべきI/Oデータの移動を制御するもので
あるから、システム・ユニットのプレーナ・ボード上に
搭載した読み取り専用メモリ（ROM）又は消去可能読み
取り専用メモリ（EPROM）の形態で、ユーザに出荷され
ていた。例えば、当初のIBM PCにおけるBIOSは、プレ
ーナ・ボード上に搭載したROMの8Kバイトを占有してい
た。プレーナ・ボードは、ROMに加えて、システム・プ
ロセッサと、主ランダム・アクセス・メモリ（RAM）
と、このボード上で実質的に共平面状に固定された他の
構成要素を含んでいた。また、ROMは、そのパーソナル
・コンピュータをテストし且つ初期化するために使用す
る電源オン自己テスト・プログラム（以下「POST」と略
記）を保持していた。かかるROM内に常駐するコードの
集合は、「システム・ファームウェア」又は単に「ファ
ームウェア」と呼ばれるようになった。このように、フ
ァームウェアは、POST部分及びBIOS部分を含んでいた。
或る形態のBIOSは、POSTを含むように定義されていた。

パーソナル・コンピュータ・ファミリの新しいモデル
が導入される場合、そのファームウェアを更新するとと
もに、I/O装置のような新しいハードウェア装置をサポ
ートするように、これを拡張しなければならなかった。
容易に予測できるように、ファームウェアのメモリ・サ
イズは、次第に増大してきた。例えば、ATの導入ととも
に、ファームウェアは32KバイトのROMを必要とするよう
になった。また、マイクロチャネル・アーキテクチャを
使用するPS/2の導入に際し、拡張BIOS（ABIOS）と呼ば
れる処の、実質的に新しいBIOSが開発された。しかしな
がら、ソフトウェア上の互換性を維持するために、互換
BIOS（CBIOS）と呼ばれるファミリ１モデルからBIOS
を、ファミリ２モデルに含めなければならなかった。か
くて、当初のBIOSは、互換BIOS及び拡張BIOSのような２
種類以上のBIOSを含むように発展してきた。パーソナル
・コンピュータに係る現在のアーキテクチャ上の定義
は、ファームウェア用として最大128Kバイトまでのシス
テム・アドレス空間（システム・ファームウェア・アド
レス空間）を許容する。

現在では、新しい技術の継続的な開発とともに、パー
ソナル・コンピュータは一層複雑になりつつあり、また
一層頻繁に拡張されるようになっている。技術が速やか
に変わりつつあり、しかも新しいI/O装置がパーソナル
・コンピュータに追加されつつあるので、その開発サイ
クルにおいては、ファームウェアの修正及び拡張が以前
にも増して重要な問題となってきた。

マイクロチャネル・アーキテクチャの導入に際し、IB
M社は、プログラマブル・オプション・セレクト（POS）
と呼ばれる処の、新しい構成手順を提供した。POSは、
インストール及びパーソナル・コンピュータの拡張を以
前のPCよりも容易に且つ簡明に行うことを目標として、
DIPスイッチ、ジャンパ及びヘッダを使用しないでパー
ソナル・コンピュータの構成動作を行うことができるよ
うに設計されている。PS/2は、低電力のバッテリ・パッ
ク式CMOSメモリを使用して、そのハードウェア構成を記
憶することができる。この構成は、拡張装置の識別子
と、システムの残りの部分に関しこれらの拡張装置がど
のように機能するかという情報を含んでいる。マイクロ
チャネル用に設計された全ての拡張カードは、一意的な
識別番号を有する。パーソナル・コンピュータがブート
する場合、PS/2は、インストールされるオプションをそ
の不揮発性メモリ（NVRAM）内の情報と比較して、その
設定の完全性を保証するために構成上の変更を検出す
る。これらの設定ファイルは、リファレンス・ディスケ
ットを使用する構成手順の間にファイル・システム内に
自動的に取り込まれる。例えば、PS/2のモデル70及び80
用のリファレンス・ディスケットは、これらのコンピュ
ータに付属し且つシステム構成情報を格納するフロッピ
・ディスケットから成る。PS/2の構成手順は、極めて簡
単でその実行が容易であるが、そのリファレンス・ディ
スケットは、すぐに使えるように手近の場所に置いてお
かなければならない。しかしながら、最後のシステム構
成から或る期間が経過すると、リファレンス・ディスケ
ットを失ったり、どこかに置き忘れたりすることがあり
得る。従って、リファレンス・ディスケットのコピーを
直接アクセス記憶装置（DASD）上に格納しておくことが
望ましい。

本発明の譲受人に譲渡された米国特許第5128995号
は、DASDのシステム部分からリファレンス・ディスケッ
トのイメージをロードするための装置を開示している。
このDASDの保護領域には、ブート・レコード、BIOSイメ
ージ及びリファレンス・ディスケットのイメージが格納
されるようになっている。DASDの一部を保護する理由
は、BIOSの汚染及び破壊を防止する必要があるからであ
る。所定のシステム動作の間、例えばプロセッサがOSの
制御下にあるか、又はこのプロセッサが或るアプリケー
ションを実行している場合、DASD制御装置は、この保護
領域を無視するように構成される。

現在の傾向として、複数のパーソナル・コンピュータ
を互いにリンクして情報ハンドリング・ネットワーク
（例えば、LAN）を構築することが、次第に多くなって
きた。このようにすると、複数のパーソナル・コンピュ
ータが、情報を交換したり、I/O装置を共有したり、特
定のハード・ファイル又はディスケットのような特定の
DASDを利用することができるからである。典型的な情報
ネットワークは、クライアントと呼ばれる多数の情報処
理システムと、サーバと呼ばれる少なくとも１つの管理
用の情報処理システムとを含んでおり、そしてこれらの
全てのシステムは、銅線又は光ファイバ・ケーブルのよ
うな通信媒体を介して互いに接続又はネットワーク化さ
れている。サブシステム構成要素（即ち、クライアント
又はサーバ）による典型的なネットワーク通信は、トー
クン・リング又はイーサネットのような、１つ以上のネ
ットワーク通信プロトコルに従う通信アダプタを介して
行われる。更に、種々の無線又は赤外線プロトコルによ
ってサーバに接続される処の、無線式のモバイル・クラ
イアントが開発された。有線式のLANに見られる前述の
諸問題は、無線式のLANについても殆どそのまま該当す
る。

ネットワーク化情報ハンドリング・システムの主要な
利点は、複数の情報処理システム間で種々の形式の情報
を通信することができる、という能力にある。このネッ
トワーク内で通信可能な情報は、情報ハンドリング・シ
ステム自体のステータス又は構成に係る情報を含んでい
る。この構成情報は、種々の態様で（例えば、診断を行
ったり、ネットワーク化情報処理システム間で互いに構
成及び機能を通知するように）処理することができる。

従来、システム構成情報は、大型のネットワーク化シ
ステム内の障害条件を検出するために利用されていた。
例えば、IBM社のシステム390は、ネットワーク化システ
ム内の性能を実時間式に監視するように設計されてい
る。障害条件を検出すると、診断ルーチンを実行して、
この障害条件を欠陥のあるシステム構成要素として隔離
した後、検出済みの障害条件及びその診断結果を、モデ
ム及び電話回線を介して中央ステーションに通信するよ
うになっている。

一般に、かかる実時間式の障害監視及び障害通信機能
は、システムのハードウェア・アーキテクチャ、OS又は
アプリケーション内に取り込まれている。しかしなが
ら、大型のコンピュータ・ネットワーク内で実現されて
いるような実時間式の障害検出機能は、パーソナル・コ
ンピュータから構成されるような小型の情報ハンドリン
グ・システムには適していない。その一部の理由は、事
実上の業界標準となっているOS（例えば、DOS及びWINDO
W）が、大型のシステムで利用可能な障害分析及び報告
機能をサポートしていない、という点にある。一層重要
なことは、実時間式の構成監視、障害検出及び報告機能
を実現するには、パーソナル・コンピュータの現在の中
央処理能力が十分でない、ということである。

しかしながら、情報ハンドリング・ネットワークを構
成する小型の情報処理システム（例えば、パーソナル・
コンピュータ）のOS及びCPUの能力が、かかるネットワ
ークを介してシステム構成情報を実時間式に通信するこ
とをサポートしていないとしても、かかるネットワーク
を介してシステムに関係する情報を通信するという要請
が依然として存在するのである。

このような要請が取り組まれたことのある情報ハンド
リング・ネットワークとは、各々が対応するOS及び予定
のシステム構成をそれぞれ有する複数の情報処理システ
ムを備え、各情報処理システムがその対応するOSの制御
下でそれぞれ動作するように編成されているものであ
る。各情報処理システムは、そのOSをロードする前の初
期マイクロコード・ロード（以下「IML」と略記）期間
中に、予定のシステム構成に基づいてシステム構成中の
任意の変更を検出するための検出手段を含んでいる。ま
た、各情報処理システムは、OSをロードする前にシステ
ム構成中の変更を検出したことに応答して、システム構
成情報をネットワークを介して通信するための通信手段
を含んでいる。

また、この情報ハンドリング・ネットワークに含まれ
る管理用の情報処理システム（例えば、サーバ）は、こ
のネットワークを介して行われる通信を監視するための
監視手段及びこのネットワークを介して通信されるシス
テム構成情報を受信するための受信手段を有する。

システム構成情報は、システム構成中の変更がユーザ
によって開始された特定の情報処理システムを識別する
ための情報を含むことができる。管理用の情報処理シス
テムは、許可信号を供給することにより、ユーザが開始
したシステム構成の変更を許可したり又は不許可にす
る。

ここで、図面のうち特に図1Aを参照すると、そこには
図1Bの情報ハンドリング・ネットワーク150（以下「ネ
ットワーク150」と略記）内で動作可能なパーソナル・
コンピュータ100（以下「システム100」と略記）が示さ
れている。システム100は、適当なケースを有するシス
テム・ユニット102、表示モニタ104（例えば、通常のビ
デオ表示装置）、キーボード110、オプションのマウス1
12及び印刷装置114から成る。また、システム・ユニッ
ト102は、ディスケット駆動装置108及びハード・ファイ
ルとも呼ばれる固定ディスク駆動装置106を含むことが
できる。

図1Bのネットワーク150は、複数の情報処理システム1
02A及び102Bから成り、そのうちの少なくとも１つは、
図1Aのシステム100と同等の構成とすることができる。
システム120Aはサーバであり、ネットワーク150内の管
理用の情報処理システムとして動作する。他方、システ
ム102Bは、クライアントとして動作する。典型的なクラ
イアント（102B）は、サーバ102Aと同等の構成を有す
る。但し、システム102Bは、固定ディスク駆動装置106
を備えていなくてもよい（その場合、システム102Bは
「メディアレス・クライアント」と呼ばれる）。システ
ム102A及び102Bは、周知の方法で互いにネットワーク化
され、ケーブル160を介して情報ハンドリング・ネット
ワーク内で情報信号を通信する。

動作を説明すると、システム102A及び102Bの動作を制
御するためのOS（例えば、DOS又はOS/2）は、IML期間後
にロードされる。一般に、このOSが利用するBIOSは、IM
L期間後に主メモリにロードされるようになっている。B
IOSは、ハードウェア装置とOSの間のインタフェースを
提供する。これにより、プログラマ又はユーザは、特定
のハードウェア装置の動作について高度な知識を有さな
くても、そのマシンをプログラムすることができる。例
えば、BIOSディスケット・モジュールは、ディスケット
駆動装置のハードウェアについて高度な知識を有さない
プログラマが、そのディスケット駆動装置をプログラム
することを可能にする。かくて、異なる企業が設計及び
製造した多数のディスケット駆動装置をシステム100内
で使用することができる。また、IML期間中にロードさ
れるPOSTは、電源オン時にシステム・ハードウェアの自
己テストを行い、システム構成を決定するとともに、そ
のシステム構成をNVRAM内に格納する。即ち、POSTは、
予定のシステム構成を現在のシステム構成と比較するこ
とにより、システム構成上の変更を検出することができ
る。BIOS及びPOSTの詳細については、「IBM Personal S
ystem/2 and Personal Computer BIOS Interface Techn
ical Reference 1991」を参照されたい。本明細書で
は、この文献を援用する。

統合化プレーナ 図２には、システム102A又は102Bの統合化プレーナ20
0が示されている。プレーナ200の印刷回路ボード（PC
B）201上には、それぞれI/Oスロットを有する多数のI/O
バス・コネクタ232と、バス制御ユニット214の制御下で
高速のCPUローカル・バス210を介してメモリ制御ユニッ
ト256に接続されたプロセッサ202が実装されている。メ
モリ制御ユニット256は、RAM264のような主メモリに接
続されている。適当な任意のプロセッサ202（例えば、
インテル社の80386、80486等）を使用することができ
る。PCB201上に実装したシステム電源コネクタ205は、
システム100用の電力を供給するための電源ユニット
（図示せず）に接続されている。

CPUローカル・バス210（アドレス、データ及び制御部
分から成る）は、プロセッサ202、オプションの数値演
算コプロセッサ204、キャッシュ制御装置206及びキャッ
シュ・メモリ208を相互接続する。CPUローカル・バス21
0に結合したシステム・バッファ212は、システム・バス
216（アドレス、データ及び制御部分から成る）に接続
されている。システム・バス216は、システム・バッフ
ァ212とI/Oバッファ228の間に延びており、バス制御ユ
ニット214及び直接メモリ・アクセス（DMA）制御ユニッ
ト220に接続されている。DMA制御ユニット220は、中央
アービタ224及びDMA制御装置222を含んでいる。I/Oバッ
ファ228は、システム・バス216とI/Oバス230の間のイン
タフェースを提供する。システム100に対し適当なクロ
ック信号を提供するために、発信器（OSC）207が図示の
ように接続されている。推奨実施例は、当該技術分野で
周知のPS/2のマイクロチャネル・バス上で実現されてい
るが、本発明を実施するに当たって他のバス・アーキテ
クチャも同様に使用できることは、当業者には明らかで
あろう。

I/Oバス230に接続した複数のI/Oバス・コネクタは、I
/O装置又はメモリ用のアダプタ・カードを受け取るため
のI/Oスロット232を有する。図面の内容を簡潔にするた
め、図２には２つのI/Oコネクタ232が示されているに過
ぎないが、特定のシステムの要件に応じて追加のI/Oコ
ネクタを設けることができる。図示のように、１つのI/
Oコネクタは、システム（102又は102B）用のネットワー
ク通信機能を提供するための、周知のトークン・リング
式の通信アダプタ・カード231に接続されている。ネッ
トワーク通信を開始する場合、プロセッサ202は、周知
の方法で通信アダプタ・カード231を起動して、ネット
ワーク150を介してインバウンド及びアウトバウンド情
報が通信できるようにする。このため、通信アダプタ・
カード231は、ネットワーク150を介して情報を通信する
ために送信手段及び受信手段の両方を含んでいる。アー
ビトレーション・バス226は、DMA制御装置222及び中央
アービタ224をI/Oコネクタ232及びディスケット・アダ
プタ246に結合する。システム・バス216に接続したメモ
リ制御ユニット256は、メモリ制御装置258、アドレス・
マルチプレクサ260及びデータ・バッファ262を含んでお
り、RAM264によって代表されるような主メモリにも接続
されている。メモリ制御ユニット256は、プロセッサ202
からのアドレスをRAM264の特定領域にマップしたり、RA
M264の特定領域をプロセッサ202へのアドレスにマップ
するための論理手段を含んでいる。システム100は、１
メガバイトの容量を有する基本のRAM264を備えるように
図示されているが、オプションのRAM266、268及び270を
追加することもできる。

システム・バス216とプレーナI/Oバス234の間には、
バッファ218が結合されている。プレーナI/Oバス234
は、アドレス、データ及び制御部分を含んでいる。プレ
ーナI/Oバス234に沿って、多様なI/Oアダプタ及び周辺
装置が結合されている。これを例示すると、（オプショ
ンの表示モニタ104を駆動するための）表示アダプタ23
6、クロック/CMOS RAM250、NVRAM248、直列アダプタ24
0（同期アダプタ又はRS232アダプタと呼ばれることもあ
る）、並列アダプタ238、複数のタイマ252、ディスケッ
ト・アダプタ246、キーボード／マウス制御装置244、割
り込み制御装置254及びファームウェア・サブシステム2
42である。一般に、ファームウェア・サブシステム242
は、ROMを含んでいて、そこに「ステージＩ POST」と
呼ばれるPOST及びBIOSプログラムの一部を保持してい
る。以下で詳述するように、「ステージＩ POST」は、
初期の及び制限されたシステム・テストを行うために使
用され、IMLイメージとも呼ばれる「ステージII POS
T」を、ディスケット駆動装置108又は固定ディスク駆動
装置106のような外部記憶装置からロードするためのル
ーチンを含んでいる。

クロック/CMOS RAM250は、時刻を計算するために使
用する。NVRAM248は、システム構成を格納するために使
用する。即ち、NVRAM248は、システム100の現構成（例
えば、アダプタ・カードの初期データ、固定ディスク又
はディスケットの容量、主メモリの容量、等）を記述す
るための情報を保持する。構成プログラムを実行するた
びに、これらのデータがNVRAM248に格納されるようにな
っている。この構成プログラムは、PS/2に付属するリフ
ァレンス・ディスケット上に格納した、通常の構成情報
設定プログラムとすることができる。このリファレンス
・ディスケットは、診断保守又はサービス・ディスケッ
トと呼ばれることもある。この構成プログラムの目的
は、システム100の構成を特徴づける値を予め決定し且
つこれをNVRAM248に予め格納することである。NVRAM248
は、システム100の電源がオフとなってもこれらの値を
保存することができるように、バッテリ・バックアップ
を有し且つ消費電力の小さなCMOSメモリとすることがで
きる。

キーボード／マウス制御装置244には、ポートＡ 278
及びポートＢ 280が接続されている。これらのポート
Ａ及びＢは、キーボード110及びマウス112をシステム10
0に接続するために使用される。直列アダプタ240には、
直列コネクタ276が結合されている。モデム（図示せ
ず）のようなオプションの装置をこのコネクタ276を通
してシステム100に結合することができる。並列アダプ
タ238に結合した並列コネクタ274には、印刷装置114の
ような装置を接続することができる。ディスケット・ア
ダプタ246に接続したディスケット・コネクタ282は、１
つ以上のディスケット駆動装置108を接続するために使
用する。

代替的なプレーナ・ボード システム100の代替実施例に従って、統合化プレーナ2
00は、プレナー・ボード300及びプロセッサ・カード400
（図３及び図４を参照）によって置き換えられる。プロ
セッサ・カード400は、プレーナ・ボード300上に取り外
し可能に実装され、これに電気的に接続されている。図
３及び図４における構成要素のうち、図２の構成要素と
同じものには、後者と同じ参照符号が付されている。図
３を参照するに、プレーナ・ボード300のPCB301上に
は、その内部配線又は回路により相互接続された種々の
構成要素が実装（例えば、表面実装）されている。これ
らの構成要素は、適当な電気コネクタ302を含んでい
る。このコネクタ302には、プロセッサ・カード400のエ
ッジ416を差し込んで、プロセッサ・カード400をプレー
ナ・ボード300上に取り外し可能に実装し且つこれに電
気的に接続する。PCB301上に実装した複数のシングル・
インライン・メモリ・モジュール（SIMM）コネクタ306
は、システムの主メモリを形成するメモリ・バンク308
A、308Bへ接続するためのものである。PCB301上に実装
した１つ以上のI/Oバス又は拡張コネクタ232は、システ
ム100に追加又は内蔵可能な種々の拡張アダプタ又はオ
プションへ接続するためのものである。例えば、固定デ
ィスク駆動装置106は、小型コンピュータ用周辺機器イ
ンタフェース（SCSI）ディスク制御装置を有する処の、
アダプタ・カード231に接続されている。アダプタ・カ
ード231は、I/Oバス又は拡張コネクタ232に接続されて
いる。各コネクタ232は、前述のマイクロチャネル・ア
ーキテクチャに準拠した型の市販のコネクタであること
が望ましい。

また、PCB301上に実装した他の構成要素には、キーボ
ード・コネクタ278及びマウス・コネクタ280にそれぞれ
接続した割り込み制御装置254及びキーボード／マウス
制御装置244、ディスケット・コネクタ288に接続したデ
ィスケット制御装置又はアダプタ246、直列コネクタ276
及び並列コネクタ274にそれぞれ接続した直列アダプタ2
40及び並列アダプタ238がある（これらのアダプタ240及
び238は、種々のI/O装置をシステム100に接続すること
を可能にする）。POC301上に実装したシステム電源コネ
クタ205は、システム100の電力を供給するための電源ユ
ニット（図示せず）に接続されている。PCB301上に実装
したその他の構成要素には、NVRAM248、クロック/CMOS
RAM250、タイミング信号を供給するための種々の発信
器（図示せず）、回路の諸セクションを周知の方法で隔
離するためのバッファ342及び344がある。

PCB301の配線は、図示されている種々の構成要素を相
互接続し、次の３つのグループに大別される。即ち、メ
モリ・バス310（線324〜338を含む）と、チャネル・バ
ス312（アドレス・バス322、データ・バス320及び制御
バス318を含む）と、割り込み線314及び316を含むその
他の信号線である。これらのグループの全ては、コネク
タ302及び416を通して、PCB402上の対応する配線に接続
されることになる。バス312から分岐されているのは、
プレーナ機能バス319である。

プロセッサ・カード 図４には、プレーナ・ボード300上に取り外し可能に
実装すべきプロセッサ・カード400が示されている。こ
のプロセッサ・カード400のPCB401上に実装（例えば、
表面実装）した複数の構成要素は、プロセッサ202、オ
プションの数値演算コプロセッサ204、キャッシュ制御
装置206、キャッシュ・メモリ208、DMA制御ユニット22
0、バス制御ユニット214、メモリ制御ユニット256、フ
ァームウェア・サブシステム242、パリティ検査ユニッ
ト402及び404を含んでいる。プロセッサ202は、例えば
インテル社の80486のように、32ビットのデータ経路及
び32ビットのアドレス指定能力を有する高性能型である
ことが望ましい。もちろん、インテル社の80386及びそ
れと同等のプロセッサも使用することができる。残りの
構成要素は、このプロセッサとの互換性を維持するよう
に、通常の方法で選択することができる。複数のバッフ
ァ406、408、410、412及び414は、図示のように接続さ
れていて、諸回路間の選択的な隔離又は接続機能をそれ
ぞれ提供する。その目的とする処は、異なる回路を同時
に使用できるようにすることであり、１例を挙げれば、
プロセッサ202とキャッシュ・メモリ208の間でデータを
移動するのと並行して、或るI/O装置と主メモリ308A、3
08Bの間でデータを転送する、ということである。前述
の全ての構成要素は、PCB401内の印刷配線回路によっ
て、互いに電気的に接続されている。エッジ・コネクタ
416は、図３に示したプレーナ・ボード300上のエッシ・
コネクタ302に差し込み可能であり、その場合には、プ
レーナ・ボード300とプロセッサ・カード400を電気的に
且つ機械的に相互接続することができる。かくて、それ
ぞれに関連する特定の型のプロセッサを有する処の、種
々のバージョンのプロセッサ・カード400を、プレーナ
・ボード300に差し込むことができる。

PCB401の配線回路は、ローカル・バス418を含んでい
る。このローカル・バス418は、データ線420、アドレス
線422及び制御線424から成り、図４に示すように、プロ
セッサ202、オプションの数値演算コプロセッサ204、キ
ャッシュ制御装置206及びキャッシュ・メモリ208を相互
接続する。残りの回路線は、一般に、割り込み線316、
チャネル・バス線312及びメモリ・バス線310を含んでい
る。チャネル・バス線312は、制御バス線318、データ・
バス線320及びアドレス・バス線322を含んでいる。他
方、メモリ・バス線310は、多重化メモリ・アドレス線3
24及び332、メモリ・バンク308A及び308B用の行アドレ
ス・ストローブ（RAS）線328及び336、列アドレス・ス
トローブ（CAS）線138、データ・バスＡ線326及びデー
タ・バスＢ線334、パリティ検査又はECC検査を介したエ
ラー検査に使用するための線330を含んでいる。システ
ム100に対し適当なクロック信号を提供するために、発
信器207が図示のように接続されている。図２〜図４の
内容を簡潔にするため、これらの図面では、他の種々雑
多の線（例えば、リセット、接地、電源オン等）が省略
されている。

プレーナ・ボード300及びプロセッサ・カード400を有
するシステム100の通常の動作中、プロセッサ・カード4
00は、プレーナ・ボード300に電気的に及び機械的に接
続される。この場合、プロセッサ・カード40は、プレー
ナ・ボード300に対し実質的に垂直な平面内に位置する
ことが多い。

前述のように、システム・ファームウェアは、POST及
びBIOSを含んでいる。また、BIOSは、互換BIOS及び拡張
BIOSを含んでいる。POSTは、システム100の電源が最初
にオンとなるときに実行すべき１組の命令を含んでい
る。現在のシステム構成が決定される場合、POSTの実行
は、システム100の初期化にとって極めて重要である。B
IOSは、プロセッサ202とI/O装置の間のデータ及び制御
命令の転送を容易にするための１組の命令を含んでい
る。

システム102B（クライアント）がメデイアレスで、固
定ディスク駆動装置又はディスケット駆動装置を有して
いない場合、通信アダプタ・カード231を介して、リモ
ート初期プログラム・ロード（RIPL）が行われる。この
通信アダプタ・カードは、例えばコネクタ232の１つに
接続されていて、周知の方法でシステム102A（サーバ）
からOSをブートすることを可能にする。

POST内のブートストラップ・プログラムは、ブート装
置を突き止めるとともに、ブート・レコードをロードす
るように試みる。代表的なブート装置は、固定ディスク
駆動装置106又はディスケット駆動装置108であるが、メ
ディアレス・クライアントの場合には、サーバ102Aをブ
ート装置として使用する。ディスケット駆動装置108
は、その動作のためにブート又はOSのディスケット（図
示せず）を必要とする。もし、POSTが、ブート装置から
のブート・レコードを成功裏にロードすれば、POSTは、
このブート・レコードに制御を渡して、そのブートスト
ラップ・プログラムの動作を完了する。他方、ブート・
レコードがロード不能で、しかもRIPLアダプタが存在す
れば、POSTは、ブート・ソースが必要であることをユー
ザに指示する。このシステムのブートストラップ動作に
は、互換BIOSが不可欠である。互換BIOSは、固定ディス
ク駆動装置106及びディスケット駆動装置108へのアクセ
スを含む、多数のサービスを提供する。

システム102A及び102Bは、IMLと呼ばれる処の、２ス
テージのPOSTを実行する。このIMLは、当該技術分野で
は周知であり、本明細書において援用する米国特許第51
28995号に詳細に開示されている。IMLに従って、プロセ
ッサは、「ステージＩ POST」の間にファームウェア・
サブシステム242の内容をロードし、その諸コマンドを
実行して、表示装置や所定のメモリ・アドレスの如き所
定のI/O装置の最小検査を行う。その後の「ステージII
POST」の間に、プロセッサ202は、IMLイメージを使用
してシステム・テストを完了する。このIMLイメージ
は、POSTを完了し且つプロセッサ202の制御をOSに渡す
ための諸命令を含んでいる。POSTの間、現在のシステム
構成を決定した後に、予め決定され且つNVRAM248内に予
め格納されているシステム構成情報と比較する。このIM
Lイメージは、プロセッサ202に特有のものであって、記
憶装置のシステム区画内に格納される。もし、この記憶
装置がディスケット駆動装置108内のディスケットであ
れば、このシステム区画は、このディスケットの一部を
占有することになる。このシステム区画上に格納したIM
Lイメージは、POSTの一部を構成するとともに、システ
ム・ハードウェアを設定又は診断するための諸ルーチン
を保持するリファレンス・イメージの一部を構成する。
一の構成変更に起因するエラーをPOSTが検出する場合、
このリファレンス・イメージがロードされて実行され
る。また、予め定義されたキー・シーケンスに応答し
て、このリファレンス・イメージがロードされることも
ある。もし、記憶装置が固定ディスク駆動装置106であ
れば、前記のシステム区画は、重要なIMLイメージが不
注意により破壊されないように、記憶媒体の保護領域に
格納される。PS/2のモデル90及び95では、保護されたシ
ステム区画が記憶媒体の最後の領域に格納されて、３メ
ガバイトの記憶容量を占有するようになっている。

本発明によれば、ネットワーク150のシステム102A及
び102Bは、IML期間中にシステム構成中の任意の変更を
検出する際に、通信アダプタ・カード231を活動化する
ことにより、OSをロードする前に、ネットワーク150を
介して所定のシステム構成情報を同報通信する。

図５を参照するに、その流れ図500は、本発明の目的
を達成するために取られる諸動作ステップを示してい
る。システムの電源がオンになると（ブロック501）、
システムは、IML期間中にPOSTを実行する（ブロック50
2）。次に、このシステムは、システム構成の変更が試
みられたか否かを決定する。かかるシステム構成の変更
が生じ得るのは、例えば主メモリの増加又は減少のよう
なハードウェア構成が変更される場合である。或いは、
ユーザが予め定義されたキー・ストローク・シーケンス
を実行してシステム構成の変更を要求するような場合に
も、システム構成の変更がユーザから開始又は指示され
ることがある。先ず、このシステムは、IML期間中にPOS
Tを通してハードウェア構成の変更があったか否かを決
定する（ブロック503）。このような決定を行うには、
現在のシステム構成をNVRAM248に格納した予定のシステ
ム構成と比較すればよい。もし、ハードウェア構成の変
更が存在しなければ、ユーザが開始した構成の変更が存
在するか否かを決定する（ブロック504）。この決定を
行うには、周知の方法を使用して、予め定義されたキー
・ストローク・シーケンスをユーザが実行したか否かを
検出すればよい。もし、ユーザが開始した構成の変更が
存在しなければ、OSがロードされる（ブロック505）。

他方、このシステムのハードウェア構成が変更された
ことをPOSTが決定すれば（ブロック503）、所定のシス
テム構成情報を収集した後、OSをロードする前にネット
ワーク150を介してこれを通信する。かかるシステム構
成情報は、就中、１つ以上のアダプタ・カードの障害に
係るエラー・コード、NVRAM、CMOS及びBIOSデータ領
域、等の情報を含んでいる。その後、システム区画から
リファレンス・イメージをロードし且つこれを実行する
ことにより、現在のシステム構成をNVRAM248内に格納す
る。

もし、POSTの結果、ユーザが開始した構成の変更が試
みられたことが分かれば、システム区画のアクセスが許
可されているか否かを決定する（ブロック507）。も
し、許可されていなければ、システム構成情報を収集し
且つこれをネットワークを介して通信した後（ブロック
508）、OSをロードする（ブロック509）。他方、システ
ム区画のアクセスが許可されていれば（ブロック50
9）、このアクセスが、管理用の情報処理システム、即
ちサーバ102Aからの許可を必要とするか否かを決定する
（ブロック510）。もしそうでなければ、リファレンス
・イメージをロードし且つこれを実行することにより、
ユーザが変更したシステム構成を許可する。他方、シス
テム区画のアクセスがサーバ102Aからの許可を必要とし
ていれば、変更すべきシステム構成の識別子を含むシス
テム構成情報の変更要求を、通信アダプタ・カード231
を通して、サーバ102Aへ通信する（ブロック511）。も
し、サーバ102Aが許可を与えなければ、OSをロードする
（ブロック510及び505）。

図６には、図５のブロック506及び508の間に取られる
諸ステップの一層詳細な流れ図600が示されている。シ
ステム構成の変更（ハードウェアの変更又はユーザが開
始した構成の変更）を検出すると、通信アダプタ・カー
ド231を活動化する（ブロック601）。次に、このシステ
ムは、NVRAM238から予定のシステム構成を収集するため
のドライバをロードする（ブロック602）。このドライ
バは、種々の装置からこのシステムの現在のハードウェ
ア構成を収集する（ブロック603）。次に、エラーに関
係する情報、即ちハードウェア構成変更のエラー・コー
ド又はユーザ・アクセス要求情報を収集する（ブロック
604）。前述の諸ステップの間に収集した全ての情報を
フォーマット化し且つこれを通信アダプタ・カード231
を通してネットワーク150上に通信する。

サーバ102Aは、通信アダプタ・カード231を通して、
通信されたシステム構成情報を受信する。サーバ102A
は、ネットワーク150上の通信を監視するためのソフト
ウェア・ルーチンの形態であることが好ましい、監視手
段を含んでいる。前記システム構成情報を検出する場
合、サーバ102Aは、この情報を受信するとともに、これ
をDASDのような永続記憶媒体内に格納する。このような
格納情報をフォーマット化することが好ましく、また後
の処理に備えて時刻スタンプを付すことが好ましい。

ネットワーク150内の各システムは、本発明に従って
通信されるシステム構成情報を受信する機能を有する。
これらのシステムが受信した情報は、各受信システムに
対し、ネットワーク150内の他のシステムの諸機能を通
知して、これらのネットワーク機能を十分に活用するよ
うに各受信システムのハードウェアを適応させることを
可能にする。

前述の内容から明らかなように、本発明は、OS又は他
の任意のアプリケーションをロードする前に、システム
構成情報の通信機能を提供する。かくて、通常のOSを搭
載した情報処理システム（例えば、IBM互換マシン）か
ら成る情報ハンドリング・ネットワークが、この有用な
ネットワーク機能を活用することができるようになる。
また、本発明によれば、起動時であって、しかもOSをロ
ードする前に、必要に応じてシステム構成情報を通信す
ることができるので、各システムは構成の監視タスクを
実時間式に行うことから解放されることになる。

ソフトウェア環境 概要：オブジェクト指向技術 本発明は、オブジェクト指向のフレームワーク技術を
使用して、これを実現することができる。かかるフレー
ムワーク技術について十分な知識を有する当業者は、以
下の概要に係る説明をスキップしてもかまわない。しか
しながら、オブジェクト指向技術やフレームワーク技術
の知識が十分でない当業者については、本発明の利点を
理解するために、以下の概要に係る説明を十分に検討す
べきである。

オブジェクト指向技術と手続き型技術との対比 本発明は特定のオブジェクト指向技術に係るが、ここ
で最初に理解すべきは、一般に、オブジェクト指向技術
が通常の手続き型技術（プロセス型技術とも呼ばれる）
と著しく異なる、という点である。これらの技術は、両
者とも同じ問題を解決するために使用することができる
が、この問題に対する最終的な解は、常に著しく異なっ
ている。その原因は、手続き型技術の設計目標がオブジ
ェクト指向技術のそれと根本的に異なっている、という
点にある。即ち、手続き型技術の設計目標が、問題を解
決するプロセスの全体に向けられているのに対し、オブ
ジェクト指向技術の設計目標は、問題の解を与えるため
に、この問題を作業可能な１組の自律走行式エンティテ
ィ（オブジェクトと呼ばれるもの）にどのようにして分
解することができるか、ということに向けられている。
別言すれば、オブジェクト指向技術が手続き型技術と著
しく異なっている理由は、それぞれの問題が互いに協働
する１組のオブジェクトに還元され、ネストされたプロ
グラム又は手続きの階層構造に還元されるのではないか
らである。

用語「フレームワーク」 オブジェクト指向技術の専門家にとって特定の意味を
有する用語や他の表現は、時代とともに次第に発展して
きた。しかしながら、オブジェクト指向分野において最
も曖昧な定義の１つは、「フレームワーク」という用語
の定義である。なぜなら、フレームワークという用語
は、人が変わればその意味も変わってくるからである。
従って、想定した２つのフレームワーク機構の特性を比
較する場合、この比較が適性な比較対象について行われ
ていることに留意すべきである。以下の説明から明らか
なように、本明細書では、コア機能及び拡張可能な機能
を有するように設計されたオブジェクト指向機構を意味
するものとして、「フレームワーク」という用語を使用
する。コア機能とは、フレームワークの消費者による修
正の対象とはならない処の、フレームワーク機構の部分
である。他方、拡張可能な機能とは、フレームワークの
消費者によってカストマイズ及び拡張されるように明示
的に設計した処の、フレームワーク機構の部分である。

オブジェクト指向のフレームワーク機構 一般に、オブジェクト指向のフレームワーク機構は、
オブジェクト指向の解として適正に特徴づけることがで
きるが、フレームワーク機構と基本的なオブジェクト指
向の解との間には、根本的な相違点が存在する。この相
違点は、フレームワーク機構が、この解の或る側面のカ
ストマイズ及び拡張を許容し且つこれを促進するように
設計されていることに由来する。別言すれば、フレーム
ワーク機構は、問題に対する解を与えるのに留まらな
い。なぜなら、フレームワーク機構は、時間の経過とと
もに変わる個別の要件に取り組むためにカストマイズ及
び拡張可能であるという意味の、生きている解を与える
からである。もちろん、フレームワーク機構のカストマ
イズ／拡張性は、フレームワークの消費者にとって極め
て価値がある。なぜなら、フレームワークをカストマイ
ズ又は拡張するのに要するコストは、既存の解の置き換
え又はその再作業を行うのに要するコストよりもずっと
少ないからである。

従って、フレームワーク設計者（以下「設計者」と略
記）が特定の問題を解決せんとする場合、この設計者
は、単に個々のオブジェクトや、これらのオブジェクト
の相互関係を設計しているのに留まらない。この設計者
は、そのフレームワークのコア機能（即ち、フレームワ
ーク消費者による潜在的なカストマイズ及び拡張の対象
とすべきでないフレームワークの部分）及び拡張可能な
機能（即ち、潜在的なカストマイズ及び拡張の対象とす
べきフレームワークの部分）をも設計するからである。
要するに、フレームワーク機構の最終的な価値は、オブ
ジェクト設計の品質だけにあるのではなく、フレームワ
ークのどの側面がコア機能を表し且つどの側面が拡張可
能な機能を表すかということを含む、設計上の選択肢に
もある。

ZAF:例示的なフレームワーク機構 当業者には明らかなように、フレームワークの設計
は、必然的に絡み合った反復的プロセスとなるが、以下
では、簡略化したフレームワーク機構の設計上の選択肢
を例示する。当然のことながら、この例示的フレームワ
ークは、本発明の利点を理解することができるように、
フレームワーク機構を説明するための便宜上のものであ
るに過ぎない。

この設計者は、問題ドメインから諸オブジェクトを選
択することによって、或るフレームワーク機構に必要な
諸オブジェクトを決定する。問題ドメインとは、解決す
べき特定の問題の抽象的な表示である。このフレームワ
ーク機構について選択した例示的な問題ドメインは、動
物園の管理用のそれである。特定の問題は、動物園の動
物（animal）を世話し且つ給餌する際に、飼育係（zoo
keeper）を援助するための機構を設計することである。
これから例示的に説明する動物園管理用フレームワーク
（Zoo Administration Framework:以下「ZAF」と略記）
では、この設計者は、動物に関する問題ドメインを調べ
た上で、任意のZAFが飼育係と動物の間の関連を表現し
た機構（即ち、飼育係が行うべき動物の飼育方法を表現
した機構）を必然的に含んでいるのを決定することにな
ろう。また、この設計者は、動物が、檻、囲い、水槽及
び他の収容ユニット（containment unit）内で生息して
いるのを認識することになろう。従って、この設計者
は、かかるフレームワークが、これらの３つのエンティ
ティ及び関連の全てを表現した機構を包含しなければな
らない、という着想から出発することになろう。

設計プロセスから説明すると、この設計者は、カテゴ
リ図と呼ばれるものから出発する筈である。カテゴリ図
とは、高レベルの複数のフレームワーク機構が互いにど
のように関係しているかを記述するのに使用されるもの
である。図７は、ZAFのカテゴリ図である。カテゴリ図
にある各機構は、特定の機能を遂行する諸オブジェクト
のグループ化を表している。説明の便宜上、この設計者
が、ZAFを４つの高レベルの機構（即ち、管理用の機
構、飼育係の機構、動物の機構及び収容ユニットの機
構）から構成しなければならない、と決定するものと仮
定する。

管理用の機構は、動物園を管理するために、飼育係の
機構を使用するように設計されている。従って、管理用
の機構は、飼育係の機構との使用関連を有していると云
われる。

前述の如く、管理用の機構は、ZAFの全体を制御する
ための責任を有するように設計されている。従って、管
理用の機構は、飼育係の機構の動作をスケジュールする
ための責任を有する。ここで、この設計者が、管理用の
機構をZAFのコア機能として設計した、という点に留意
すべきである。つまり、管理用の機構は、潜在的なカス
トマイズ及び拡張の対象とならないように設計されてい
る。図７のカテゴリ・ボックス内の記号「Ｃ」は、かか
るコア機能を意味する。また、管理用の機構と飼育係の
機構の間の使用関連も、フレームワーク消費者による最
終的なカストマイズに利用できないように設計されてい
る。

飼育係の機構は、総じて動物の世話及び給餌について
責任を有するように設計されている。従って、飼育係の
機構は、そのタスクを遂行するために、動物の機構及び
収容ユニットの機構を使用する。しかしながら、管理用
の機構の設計と異なり、この設計者は、飼育係の機構を
拡張可能な機能として設計した。つまり、飼育係の機構
は、動物の世話及び給餌の将来の要件に取り組むため
に、フレームワーク消費者が変更及び／又は拡張するの
に使用することができるように設計されている。図７の
カテゴリ・ボックス内の記号「Ｅ」は、かかる拡張可能
な機能を意味する。

この設計者は、動物と飼育係の間の動物側の対話を表
すように、動物の機構を設計している。動物園内の動物
の総数は定期的に変動するのが普通であるから、動物の
機構は、これを反映して拡張可能な機能として設計され
ている。収容ユニットの機能は、（囲いや水槽や檻など
の）個々の収容ユニットを表すことにより、飼育係の機
構と対話する。動物の機構と同様に、収容ユニットの機
構は、将来のカストマイズ及び拡張要件を処理すること
ができるように、拡張可能な機能として設計されてい
る。ここで、飼育係、動物及び収容ユニットのそれぞれ
の機構の全てが拡張可能な機能として設計されていると
しても、これらの機構の間の関連は、ZAFのコア機能と
して設計されていることに留意されたい。別言すれば、
フレームワークの消費者（以下「ZAF消費者」と表記）
に対し飼育係、動物及び収容ユニットの機構に関する柔
軟性を与えることが望ましいとしても、これらの機構の
間の関連を、ZAF消費者が変更することを許容するのは
望ましくない、ということである。

次に、この設計者は、図７の諸機構を構成する処の、
諸クラス及び諸関連を設計することになろう。クラスと
は、１組の同様のオブジェクトの定義である。かくて、
クラスとは、これらのオブジェクトの抽象概念又はオブ
ジェクトの或る型の定義であると考えることができる。
コンピュータ・システムの観点からすれば、単一のオブ
ジェクトは、カプセル化した１組のデータ及びかかるデ
ータについてコンピュータ・システムが遂行するような
単一又は１群の動作を表す。事実、安全なコンピュータ
・システムでは、或るオブジェクトによって制御された
情報をアクセスするには、このオブジェクト自体を介し
て行わなければならない。このことが、オブジェクト内
に保持された情報がこのオブジェクトによってカプセル
化されている、と云われる所以である。

各クラス定義は、そのオブジェクトによって制御され
る情報を定義するためのデータ定義と、そのオブジェク
トが制御するデータについて諸オブジェクトによって遂
行される１つ又は１組の動作を定義するための動作定義
とから成る。別言すれば、クラス定義とは、定義された
データについて遂行される１つ又は１組の動作を定義す
ることによって、或るオブジェクトが他のオブジェクト
に対しどのように作用及び反応するかを定義するもので
ある（これらの動作は、メソッド、メソッド・プログラ
ム及び／又はメンバ＿機能と呼ばれることもある）。ま
とめて考える場合、かかる定義済みの動作及びデータ
は、そのオブジェクトの振る舞い（behaviour）と呼ば
れる。要するに、クラス定義とは、その１つ以上のメン
バ・オブジェクトの振る舞いを定義するものである。

図８は、この設計者がZAF用に設計した諸基本クラス
を示す処の、オブジェクト指向のクラス図である。各ク
ラス表示は、図７の諸機構に対するその関連を含んでい
る。例えば、飼育係のクラスは、飼育係の機構からのも
のであると表示されている。ZAFの諸基本クラスが含ん
でいるのは、動物園の管理者のクラス（管理用の機構の
一部）、飼育係のレジストリ・クラス（管理用の機構の
一部）、動物のレジストリ・クラス（飼育係の機構の一
部）、飼育係のクラス（飼育係の機構の一部）、収容ユ
ニットのレジストリ・クラス（飼育係の機構の一部）、
動物のクラス（動物の機構の一部）、収容ユニットのク
ラス（収容ユニットの機構の一部）である。

ここで、これらのクラスの間の関連は、ZAFのコア機
能として設計されているので、ZAF消費者がこれらを最
終的に変更できないことに留意されたい。

管理者のクラスは、ZAFの制御全般に責任のあるオブ
ジェクトの定義である。ここで、オブジェクト指向の全
てのクラスは、特定の問題の解を与えるように対話する
処の、複数のオブジェクトを定義することを想起された
い。しかしながら、生きている解（即ち、将来の諸要件
に取り組むようにカストマイズ及び／又は拡張可能な
解）を与えるために、それぞれのフレームワーク機構の
それぞれのオブジェクトがどのように設計されているか
を理解するには、これらのクラス定義の特性を調べるこ
とが必要である。

管理者のクラスは、飼育係のレジストリとの使用関連
を有するように設計されている。この設計者は、管理者
のクラス及びレジストリ・クラスを、ZAFのコア機能と
して設計している。なぜなら、この設計者は、ZAF消費
者が、これらのクラス定義のメンバである諸オブジェク
トの振る舞いを変更できないようにすべきであると決定
したからである。飼育係のレジストリは、飼育係のクラ
スに対し「a contains byreference」と呼ばれる関連を
有するクラスであって、飼育係のオブジェクトの全ての
収容体であるようなオブジェクトを定義する。従って、
飼育係のレジストリは、「list_zoo_keepers（）」動作
の定義を含んでいる。後述するように、この動作は、飼
育係のオブジェクトのリストを、当該リストを要求する
他のオブジェクトに与える責任を有する。

図９は、管理者のクラスの下位レベル表示である。管
理者の型の諸オブジェクトは、ZAFの制御全般について
責任を有するから、管理者のクラスは、動物園の管理に
向けられた諸タスクを遂行するために諸動作を含むよう
に設計されている。このクラス定義は、次の５つの動作
を含んでいる。

5_minute_timer（）； add/delete_animal（）； add/delete_containment_unit（）； add/delete_zoo_keeper（）； start_zoo_admin（）。

前記の「start_zoo_admin（）」動作は、ZAFを開始す
る責任を有する。即ち、ユーザ又はシステム管理者が
「start zoo_admin（）」動作と対話することにより、Z
AFを介して動物園の管理を開始する、ということであ
る。この設計者は、一旦開始されると、「5_minute_tim
er（）」動作を開始するように、「start_zoo_admi
n（）」動作を設計している。この「start_zoo_admi
n（）」動作は、飼育者の諸オブジェクトに対し、外に
出て動物を調べるように、５分ごとに命令する。「add/
delete_zoo_keeper（）」動作の責任は、ZAFのユーザと
対話することを通して、追加の飼育係を定義し（即ち、
追加の飼育係のクラス）、追加の飼育係を加え（即ち、
飼育係のオブジェクト）、飼育係のクラス及び／又はオ
ブジェクトを除去することである。明らかに、飼育係の
オブジェクトの各々は、動物園内の特定のタスクを遂行
する責任を有する。従って、ZAFのユーザの希望に応じ
て、追加のタスクを取り扱うために飼育係の定義及びオ
ブジェクトを追加したり、もはや必要でなくなった定義
又はオブジェクトを除去することができる。この柔軟性
は、飼育係の機構を拡張可能な機能として設計すること
に由来するものである。

前記の「add/delete_zoo_keeper（）」動作と同様
に、「add/delete_animal（）」動作の責任は、ユーザ
と対話することを通して、動物の追加のクラス及びオブ
ジェクトを定義し、もはや必要でなくなったクラス及び
オブジェクトを除去することである。動物園にとって
は、動物を追加したり除去することは、極めて自然であ
るからである。「add/delete_containment_unit（）」
動作の責任は、収容ユニットの新しいクラス及びオブジ
ェクトを定義するとともに、もはや必要でなくなったク
ラス及び／又はオブジェクトを除去することである。こ
の柔軟性を得るために、この設計者は、動物の機構及び
収容ユニットの機構を拡張可能な機能として設計してい
る。

再び図８を参照するに、飼育係のクラス定義は、動物
のレジストリ、動物、収容ユニットのレジストリ及び収
容ユニットのクラスとの使用関連を有する。ZAFの価値
を強化するには、飼育者、動物及び収容ユニットのクラ
スをZAF消費者がカストマイズ及び拡張できるようにす
ればよいから、これらのクラスは拡張可能な機能として
設計されている。しかしながら、動物及び収容ユニット
のレジストリ・クラスの振る舞いを変更すると、ZAFの
基本動作を混乱させることになりかねない。従って、こ
れらのクラスは、ZAFのコア機能として設計されてい
る。

図10は、飼育者のクラスのクラス図である。図10の詳
細を説明するに先立ち、図10のクラス定義が、「クラス
階層」と呼ばれる非常に簡単な配列内でランクされてい
ることを指摘しておく。或るクラス階層において最も一
般的／抽象的なクラスを表すようなクラス（例えば、飼
育者のクラス）は、この階層の基本クラスと呼ばれる。
或るクラス階層における諸クラスの配列は、最も抽象的
なものから最も具体的なもの（即ち、一般から特殊）に
移行する。一般性が比較的少ないクラス（例えば、給餌
係のクラス）は、これより一般的な１つ以上のクラス
（例えば、飼育係のクラス）からの特性を継承すると云
われる。かくして、給餌係、獣医（veterinarian）及び
温度制御係のクラス定義は、飼育係のクラスのサブクラ
スであると云われる。継承機構については、図11を参照
して以下で詳述する。

図10に示すように、飼育係のクラス定義は、「check_
animals（）」動作の単一の定義を含んでいる。また、
飼育者のクラスが、抽象クラスとしてマークされている
ことに留意されたい。抽象クラスとは、そのメンバとし
て作成されたオブジェクトを有するように設計されてお
らず、その代わりに、その諸サブクラス用の共通のイン
タフェース／プロトコルを定義するために使用される。
或るクラスが抽象クラスであると云われるのは、その少
なくとも１つの動作定義が、純粋で仮想的な動作定義で
ある場合である。かかる純粋で仮想的な動作定義を定義
する目的は、その動作のサブクラス定義用の共通のイン
タフェースを定義するためだけにある。別言すれば、実
際の振る舞い（即ち、データ及び動作）の設計は、サブ
クラス自体に任されるのである。飼育係のクラス定義の
場合は、給餌係、獣医及び温度制御係のサブクラス定義
が、飼育係のクラスに含まれている処の、純粋で仮想的
な「check_animal（）」動作定義の特定の実現体を規定
する。或る動作がゼロに等しく設定されること、この動
作は、純粋で仮想的なものとマークされることになる。

尤も、純粋で仮想的な動作定義の共通なインタフェー
スを、全てのサブクラスが尊重しなければならないこと
に留意する必要がある。即ち、要求元のオブジェクト
（クライアント・オブジェクトと呼ばれるもの）がサブ
クラスのメンバ・オブジェクト（サーバ・オブジェクト
と呼ばれるもの）を使用することが可能であり、しかも
その場合において、このサーバ・オブジェクトの特定の
サブクラスを知る必要がない、ということである。例え
ば、動物園の管理者のクラスによって定義されたオブジ
ェクトが特定のアクションの遂行を必要とする場合、こ
のオブジェクトは、常に飼育者のオブジェクトと対話す
ることになる。これらのオブジェクトに対するインタフ
ェースは抽象的に定義されたから、基本クラスの飼育係
及び「check_animal（）」動作用のサブクラス定義内に
保持された管理者のオブジェクトは、任意のサーバ・オ
ブジェクトの諸サブクラスに関する特別の知識を有する
必要がない。この結果、（管理者のオブジェクトの側に
おける）アクションの必要性を、このアクションを（飼
育係のサブクラスのオブジェクトの１つによって）実行
する方法から隔離することができる。抽象クラスの特性
を活用する（ZAFの設計と同様の）設計は、ポリモアフ
ィック（polymorphic）であると云われる。

かかるポリモアフィズム（polymorphism）がオブジェ
クト指向のフレームワーク設計にとって極めて重要であ
る理由は、アクションが実際に行われているという事実
に依存するような機構を生じさせることなしに、何かが
行われる方法（実現体と呼ばれるもの）を変更又は拡張
することが可能となるからである。別言すれば、クライ
アント・オブジェクトは、所定のオブジェクトが所定の
機能を遂行することだけを理解すれば十分であって、こ
れらの機能が実際にどのように遂行されるかを理解する
必要はないのである。この方法を使用すれば、将来の諸
要件を満足するように、適正に設計されたフレームワー
クのカストマイズ及び拡張を容易に行うことができる。

前述の通り、この設計者は、飼育係のオブジェクトが
動物のオブジェクト及び収容ユニットのオブジェクトと
対話してそれらのタスクを遂行するように、ZAFを設計
している。図11は、抽象クラスである動物のクラス階層
についてのクラス図である。動物のクラス定義は動物の
特性及び振る舞いを表現する責任を有するから、この設
計者は、この責任を反映するように抽象クラスである動
物を設計している。図示の如く、例示的な動物のクラス
定義は、データ定義の「feed_freq」、「location」及
び「temp_range」と、動作定義の「get_temp_rang
e（）」、「feed（）」、「needs_food（）」及び「vet
_visit（）」を含んでいる。

このフレームワークの全容を理解するには、各定義を
詳細に調べる必要はない。しかしながら、データ定義の
「temp_range」、並びに動作定義の「get_temp_rang
e（）」及び「feed（）」は、十分に考えられたフレー
ムワーク設計の選択肢の良い例である。

「feet（）」動作定義は、（図示されていない特定の
給餌装置を通して）動物への実際の給餌を遂行するよう
に設計されている。かかる「feed（）」動作は、純粋で
仮想的な動作である。このことは、このクラスの設計が
次のようなものであること、即ち必要な機能を遂行する
実際の機構がその諸サブクラスによって定義されること
を意味する。説明中の例では、諸サブクラスのメンバと
して作成される諸オブジェクトがそれぞれ特殊化された
ニーズを有しているので、このようにサブクラス定義に
任すことは、良い設計方法である。例えば、ZAFでは、
動物のそれぞれの型ごとに特定の給餌装置が必要となる
公算が大きいから、一般的な「feed（）」動作を定義す
ることは困難であるばかりでなく、無駄でもある。

比較のため、この設計者は、「get_temp_range（）」
動作を、純粋で仮想的な動作定義ではないように、明示
的に設計している。このことは、「get_temp_rang
e（）」動作がデフォルト動作として一般的に定義され
ていることを意味する。かくて、これは仮想的な動作で
あると見なされる。デフォルト動作は、諸サブクラスに
対し一般的な機能を与えるために使用されるものであ
る。これらのサブクラスは、単にデフォルト動作を使用
するか、或いは再定義によってデフォルト動作をカスト
マイズ又は拡張することができる。

哺乳動物は、動物のクラスのサブクラスであるから、
後者の全ての特性を継承する。これに関連して、哺乳動
物のクラスが抽象クラスとしても定義されることに留意
されたい。つまり、このクラスがそのメンバとして作成
されたサブクラスを有するように設計されていないが、
その代わりに、その諸サブクラス用の共通のインタフェ
ースを与えるように設計されている、ということであ
る。哺乳動物のサブクラスは、更に肉食動物及び草食動
物のクラスにサブクラス化される。

「feed（）」動作の定義は、それぞれのサブクラスに
任されているから、肉食動物及び草食動物のサブクラス
の各々は、「feed（）」動作のそれ自体の定義を有す
る。これが良い設計方法である所以は、肉食動物のニー
ズと草食動物のニーズがそれぞれ異なるからである。

「temp_range」データ定義は、特定の動物が自然に生
息する場所のそれと一致するような温度の範囲を定義
し、「get_temp_range（）」動作定義は、特定の動物に
対する「temp_range」を検索し且つこれを要求元のクラ
イアント・オブジェクトに戻すように設計されている。
爬虫動物のサブクラスは、それ自体の「temp_range」デ
ータ定義と、それ自体の「get_temp_range（）」動作定
義を含んでいる。ZAFは、動作定義と同様にデータ定義
が変更可能であることを記述するように、設計されてい
る。多くの爬虫動物は、夜が非常に寒く且つ日中が非常
に暑い砂漠条件下で生息しているから、爬虫動物のクラ
スに関しては、時刻及び温度情報を含むようにデフォル
トの「temp_range」定義が変更されている（図11には明
示せず）。これが良い設計方法である所以は、時刻及び
爬虫動物の収容ユニット自体の現在の温度に基づいて温
度調整を行うことができるように、ZAFが、爬虫動物の
収容ユニットを他の収容ユニットとは異なる態様で扱う
ことを可能にするからである。

図12は、収容ユニットのクラスの下位レベル表示のク
ラス図である。収容ユニットのクラスは、仮想的な動作
定義である処の、「adjust_temp（）」を含んでいる。
かかる「adjust_temp（）」動作定義は、動物園の諸収
容ユニット内の温度を（図示しない加熱及び冷却機構を
介して）実際に調整するために使用されるような、イン
タフェース及び機構の両方を定義する。

ZAFの諸オブジェクトが対話する方法 特定の問題に対する解を構成する諸オブジェクトを設
計することに加えて、この設計者は、個々のオブジェク
トがどのように対話するかということも設計しなければ
ならない。別言すれば、これらのオブジェクトは、その
設計方法を活用するように相互に関係しなければならな
い。前述のように、或るオブジェクトの定義済みの動作
がこのオブジェクト用に定義したデータを操作する方法
は、このオブジェクトの振る舞いと呼ばれる。それぞれ
のオブジェクトは、自律走行式エンティティとして特徴
づけることができるが、依然として重要なことは、各オ
ブジェクトが他のオブジェクトと相互に関係するとき
に、一貫性のある振る舞いを呈することである。なぜな
ら、オブジェクト自体が一貫性のある振る舞いを呈する
ためには、これらのオブジェクトが、他のオブジェクト
の一貫性のある振る舞いに依存することになるからであ
る。事実、一貫性のある振る舞いが非常に重要であるこ
とは、或るオブジェクトの振る舞いを、このオブジェク
トが他のオブジェクトと有する契約と呼んでいることか
らも明らかであろう。或るオブジェクトが一貫性のある
振る舞いを呈さない場合、このオブジェクトは、他のオ
ブジェクトとの契約に違反したと云われる。

第１のオブジェクトの動作が第２のオブジェクトの制
御下にあるデータのアクセスを必要とする場合、第１の
オブジェクトは、第２のオブジェクトのクライアントで
あると見なされる。第２のオブジェクトの制御下にある
データをアクセスするために、このクライアントの１つ
の動作は、第２のオブジェクトの１つの動作を呼び出し
て、このデータへのアクセスを獲得する。次に、呼び出
されたオブジェクトの１つの動作（即ち、本例の場合
は、サーバ動作）を実行して、呼び出されたオブジェク
トの制御下にあるデータをアクセス及び／又は処理す
る。

図13のオブジェクト図は、動物園の職員を援助して動
物園を運営するために、ZAFの例示的な諸オブジェクト
がどのように対話するかを示している。この全容を理解
するには、ZAFの全てのオブジェクトの対話を詳細に解
析することは必要ではない。しかしながら、諸問題を解
決するためにこれらのオブジェクトがどのように対話す
るかを一般的に理解するには、以下で説明する簡単な制
御の流れを検討するのが有用であろう。

前述の如く、オブジェクトは、特定クラスのメンバと
して作成される。従って、動物園の管理者の「Zelda」
（オブジェクト706）は、管理者のクラスのメンバ（実
際には唯一のメンバ）であるようなオブジェクトであ
る。かくて、「Zelda」のオブジェクトは、ZAFの制御全
般について責任を有する。飼育係のオブジェクトの全て
は、飼育係のレジスト・オブジェクト（オブジェクト70
0）に登録されている。従って、「Zelda」のオブジェク
トは、飼育係のレジスタ・オブジェクトの「list_zoo_k
eepers（）」動作を呼び出して（ステップ１）、現在の
飼育者のリストを獲得する。飼育係のレジスタ・オブジ
ェクトは、飼育係のレジスタ・クラスのメンバとして作
成されている。説明の便宜上、これが「Zelde」の「5_m
inute_timer（）」動作の一部として５分ごとに生ずる
ものと仮定する。次に、飼育係のレジスタ・オブジェク
トは、「keepers_list」に応答する（ステップ２）。こ
の飼育係のリストは、温度検査係の「Tina」（オブジェ
クト714）、獣医の「Vince」（オブジェクト740）、食
餌係の「Fred」（オブジェクト752）を含んでいる。飼
育係の各々は、飼育係のクラスのメンバとして作成され
ている。特に、温度検査係の「Tina」、獣医の「Vinc
e」及び食餌係の「Fred」のオブジェクトは、温度制御
係、獣医及び食餌係のサブクラスのそれぞれのメンバで
ある。「Temp（）」動作は、ポリモアフィックである。
別言すれば、オブジェクト「Tina」の「check_animals
（）」動作は、「adjust_temp（）」動作の各々がその
タスクをどのように遂行するかということに関する特殊
な知識を必要としない。従って、「check_animal
s（）」動作は、インタフェースによって単に「adjust_
temp（）」動作を呼び出すことに留まるのである。その
後は、個々の「adiust_temp（）」動作が、それらのタ
スクを適正に行うことになる。

以上で、ZAFの機構を説明したのは、これが極めて簡
単なフレームワーク機構であって、当業者がその幾つか
のフレームワーク概念を理解することを通して、本発明
の利点を十分に認識することができると考えられるから
である。これらの利点は、以下の説明を参照すれば一層
明らかとなろう。

ここで、図14A、図14B及び図15を参照して、説明を続
ける。図14A及び図14Bは、前述の文脈において、本発明
のフレームワーク（以下「管理フレームワーク」と表
記）を例示し、図15は、この管理フレームワーク内で使
用される特定のオブジェクトを例示する。図14Bは高レ
ベルのブロック図であり、図14Aは低レベルの詳細を示
す図である。図14A及び図14Bの管理フレームワークは、
以下の要素を有する。

ウェブ・ブラウザ； マッピング・ブロック； サーバ層；及び OS。

この実施例のマッピング・ブロックは、インターネッ
ト上の任意のブラウザを有する任意のユーザに対し、シ
ステム管理プロトコルのイベント監視及び制御手段を提
供する。マッピング・ブロックは、ブラウザ上で表示す
るためにプロトコル・サービスの内部データをHTMLに変
換し、HTMLとしてのユーザの入力をプロトコル・サービ
スの制御信号に変換する。

本発明のユーザは、現に市販中の任意のものでよいブ
ラウザから、システムを監視及び制御する。

マッピング・ブロックは、インターネット上のウェブ
・ブラウザに、静的形式（例えば、HTML形式）又は動的
形式（例えば、Java形式）のアプレットを供給する。こ
れらの形式又はアプレットは、システム管理プロトコル
からの監視情報を供給するか、又はシステム管理プロト
コル内でイベントを生成するための入力手段を供給す
る。

ブラウザへのユーザ入力は、このユーザが監視するこ
とを望んでいる監視対象又はこのユーザが望んでいる制
御方法を指示する。これらのユーザ入力は、前記形式又
はアプレットが与える諸命令の制御下で、ブラウザを介
して、マッピング・ブロックに返送される。マッピング
・ブロックとブラウザの間で交換すべきデータは、HTML
のような標準言語の形式を有し、HTTPプロトコルを使用
してインターネットを介して伝送される。

マッピング・ブロックは、システム管理プロトコルの
サービス層と直接的に通信する。実際、マッピング・ブ
ロックは、このサービス用のGUIになる。サーバは、イ
ンターネットを介して受信したHTMLを、サービス層に与
えられ諸コマンドに変換する。かくて、サービス層は、
OSを通して諸要求を実行する。

本発明は、DMI、SNMP、CMIP及びCMOLシステム管理プ
ロトコル用の、プラットフォーム独立のインターネット
上のブラウザを許容する。

マッピング・ブロックは、ウェブ・ブラウザからのHT
TP要求をサービス層に固有の呼び出し（コール）に変換
する処の、HTTPサーバとして設計することができる。こ
のサービス層から戻されたデータは、HTMLに変換されて
ブラウザに戻される。このようにすると、実質的にプラ
ットフォーム独立のウェブ・ブラウザから、DMI、SNM
P、CMIP、CMOL又は他の任意のシステム管理プロトコル
を管理することができる。

他の実施例として、図14A及び図14Bの管理フレームワ
ークは、次の要素を含んでいる。

HTTP要求元； マッピング・ブロック； トランスポート層；及び HTTPサーバ。

本発明のこの実施例は、マッピング・ブロックを通し
て、HTTPをトランスポート層が使用するプロトコル独立
の諸コマンドに変換するための管理フレームワークを提
供する。HTTP要求元とマッピング・ブロックの間の通信
は、２つの型のうちの何れかとすることができる。マッ
ピング・ブロックは、TCP/IPからのHTTP要求を受理し、
これをNet BIOS、IPX又は直列プロトコルを備えたトラ
ンスポート層を通して経路指定する処の、ゲートウェイ
式のHTTPサーバとすることができる。この方式によれ
ば、一般的なウェブ・ブラウザを使用して、TCP/IPに直
接に接続されていないHTTPサーバに到達することが可能
になる。TCP/IP接続を持たないコンピュータについて
は、HTTP要求元又はウェブ・ブラウザをマッピング・ブ
ロックと直接に統合化しなければならない。

本発明を実現するには、例えば、マッピング・ブロッ
クを含むようにブラウザのバックエンドに再書き込みを
行うか、又はこのブラウザによって送信されるHTTP要求
用のゲートウェイとして機能するマッピング・ブロック
を開発すればよい。

更に他の実施例として、図14A及び図14Bの管理フレー
ムワークは、次の要素を含んでいる。

ウェブ・ブラウザ； マッピング・ブロック； トランスポート層；及び システム管理ベース。

この実施例のマッピング・ブロックは、インターネッ
ト上の任意のブラウザを有する任意のユーザに対し、シ
ステム管理の監視及び制御手段を提供することを可能に
する。マッピング・ブロックは、ブラウザ上で表示する
ためにシステム管理ソフトウェアの内部データをHTMLに
変換し、HTMLとしてのユーザ入力をシステム管理ソフト
ウェアの制御信号に変換する。ウェブ・ブラウザを除く
と、この管理フレームワークの諸要素は、サーバ上で実
行することができる。本発明のユーザは、一般的な任意
のウェブ・ブラウザから、管理中の諸システムを監視及
び制御する。

マッピング・ブロックは、インターネット上のウェブ
・ブラウザに、静的形式（例えば、HTML形式）又は動的
形式（例えば、Java形式）のアプレットを供給する。こ
れらの形式又はアプレットは、管理中の諸システムから
の監視情報を供給するか、又はトランスポート層を通し
てシステム管理ベースにアクセスすることにより、管理
中の諸システムを制御するための入力手段を提供する。
ブラウザへのユーザ入力は、このユーザが監視すること
を望んでいる監視対象又はこのユーザが望んでいる制御
方法を指示する。かかるユーザ入力は、前記形式又はア
プレットが与える諸命令の制御下で、ブラウザを介し
て、マッピング・ブロックに返送される。

マッピング・ブロックとウェブ・ブラウザの間で交換
すべきデータは、HTMLのような標準言語の形式を有し、
HTTPプロトコルを使用してインターネット上に伝送され
る。

マッピング・ブロックは、トランスポート層及びシス
テム管理ベースを通して、管理中の諸システムと通信す
る。実際、マッピング・ブロックは、GUIベース・パラ
ダイムにおけるGUIになる。マッピング・ブロックは、
インターネットを介して受信したHTMLを、トランスポー
ト層に与えられるプロトコル独立の諸コマンドに変換す
る。

トランスポート層は、これらのコマンドを、Net BIO
S、TCP/IP、IPX又は直列リンクを介して、システム間で
伝送する。

システム管理ベースは、トランスポート層からのコマ
ンドを受信する。次に、システム管理ベースは、ユーザ
の諸命令を実行するか、又はコンピュータ・システム自
体からの所望の監視を要求する。

このシステム管理ベース内で利用可能な諸サービス
は、ウェブを通して本発明が制御することができるもの
である。これらのサービスを列挙すると、次の通りであ
る。

（１）システム情報ツール：当該システムのハードウェ
ア及びソフトウェア構成について包括的な情報を供給す
る。

（２）システム監視サービス：当該システムにおける測
定可能な量の監視を可能にする。これらの量を表示し、
収集し、データベースにエクスポートすることができ
る。また、警報をトリガするために、これらの量につい
て閾値を設定することができる。

（３）システム区画アクセス・サービス：或るシステム
のシステム区画の表示及び制御を可能にする。

（４）警報管理サービス：警報ログの表示、警報時に行
うべきアクションの設定、諸警報クラスをカプセル化す
る諸プロファイルの定義、警報収集手段からのプロファ
イルによる警報の要求を可能にする。

（５）セキュリティ管理サービス：或るサービス・レベ
ル上のアクセスを制限するために、ユーザ及びパスワー
ドを定義することを可能にする。

（６）ECCメモリ・サービス:ECCメモリ・エラー及び障
害についての監視及び警報を可能にする。

（７）予知式障害分析サービス：ディスク・エラー及び
障害についての監視及び警報を可能にする。

（８）システム・プロファイル・サービス：当該システ
ム上の重要な会計及びインベントリ情報の定義及び入力
を可能にする。

（９）クリティカル・ファイル・モニタ：諸ファイル内
の変更を検出するために、これらのファイルの監視及び
警報を可能にする。

（10）NetFinity直列制御：内部プロトコルによる通信
用の直列回線の定義及び設定を可能にする。

なお、「NetFinity」は、インターナショナル・ビジ
ネス・コーポレイションの商標である。

（11）RAID管理：それぞれのRAID駆動装置を制御し、RA
ID駆動装置のエラー及び障害を監視及び警報することを
可能にする。

（12）遠隔セッション・サービス：それぞれの遠隔シス
テムについて端末シェル能力を可能にする。

（13）ファイル転送サービス：ローカル・システムと遠
隔システムの間のファイル又はディレクトリの転送を可
能にする。

（14）画面ビュー・サービス：ローカル又は遠隔システ
ム上の可視画面の捕捉及び表示を可能にするとともに、
システム入力及び出力の実時間的な捕捉を可能にする。

（15）遠隔システム管理サービス：諸システム・グルー
プの定義及び保守に加えて、諸システムのステータス又
は存在についての警報を可能にする。

（16）サーバ保護サポート・システム：諸サーバ上のハ
ードウェア・モニタ（電源、温度、等）の状態について
の監視及び警報を可能にする。

（17）イベント・スケジューラ・サービス：スケジュー
ルされたサービス又はコマンドの定義及び活動化を可能
にする。

（18）電源オン・エラー検出：電源オンとシステム・ブ
ートの間に生ずるエラーの捕捉及び警報を可能にする。

（19）データベース・サポート：サービス・データをデ
ータベースに対しエクスポートするための諸パラメータ
の設定及び調整を可能にする。

（20）ソフトウェア・インベントリ：当該システム上に
導入されたソフトウェアの定義及び監視を可能にする。

（21）DMIブラウザ:DMIイベントの生成及び表示を可能
にする。

（22）報告：種々の監視サービスから生ぜられる諸報告
の定義、生成及び表示を可能にする。この報告サービス
は、種々のサービスによって与えられる実時間式のデー
タを補足する処の、履歴データの静的なベースとして機
能する。更に、これらの報告は、システム管理業務につ
いての直接の責任を負わない人々によって消費されるこ
とが多い。この目的にとって、プラットフォーム独立の
ウェブ・インタフェースを有することは、極めて有用で
ある。

HTTPサーバは、インターネットに接続されたポート上
にHTMLを受理するような、マッピング・ブロックとして
書かれている。このサーバの大部分は、公知のシステム
管理プログラム、例えばIBM社が提供する「NetFinity」
内に既に存在する各サービスへのそれぞれのGUIを書き
換えたものである。主要な相違は、ウインドウ・システ
ムと対話する代わりに、このサーバがHTMLと対話するこ
とにある。

更に、多くの強力なシステム管理能力がウェブ／ブラ
ウザ・パラダイムには自然であり、専用のGUIにおいて
は一層困難である。

マッピング・ブロックの内部構造を示す図15には、マ
ッピング・ブロック内に見いだされる諸オブジェクトが
一層詳細に示されている。図14の内容からも明らかなよ
うに、マッピング・ブロックは、ウェブ・ブラウザとイ
ンターネットを介して制御される観察中のアプリケーシ
ョンの間に存在する。マッピング・ブロックは、２つの
オブジェクト、即ちHTTPオブジェクト及びHTMLオブジェ
クトから成る。

HTTPオブジェクトは、次の事項に責任を有する。

＊ インターネット通信をオープンし且つこれを維持す
る； ＊ インターネットを介してHTTP要求を受理する； ＊ この要求を形成するURL及び他の任意のデータを解
析する； ＊ このURL、入力データ及びブラウザの識別子をHTML
オブジェクトに伝送する； ＊ このHTMLオブジェクトからHTMLソースを受理し、こ
れを要求元のブラウザに戻す。

図15に示すように、HTTPオブジェクトは、ブラウザの
型によって更にサブクラス化することができる。このよ
うにすると、HTTPオブジェクトは、HTMLフィルタとして
振る舞って、HTMLオブジェクトが戻すHTMLソースを、特
定のブラウザが一層良好に使用することができるような
ソースにメッセージ交換することになろう。図15には、
３つのブラウザが例示されている。市販の製品である
「NetScape」のような十分に機能的なブラウザにサービ
スする場合、HTTPオブジェクトは、このブラウザに転送
するHTMLに対し、如何なる変更も加えないことがある。
しかしながら、比較的に能力の低いブラウザ（例えば、
HTML1.0だけを適正に処理することができるもの）にサ
ービスする場合には、それよりも拡張されたサービスを
必要とするHTMLソース部分のフィルタ処理を行って、か
かる環境で有意に表示可能なソースに変換することにな
ろう。更に、HTTPオブジェクトは、或るコマンド行「ブ
ラウザ」を処理するように、サブクラス化することがで
きる。この場合、HTMLを端末画面上に有意に表示するた
めには、このHTMLを根本的に変更して、全てのマークア
ップを除去するとともに、適当なスペースを挿入しなけ
ればならない。

HTMLオブジェクトは、次の事項に責任を有する。

＊ URL及び他の要求データを受理する； ＊ これらの要求を理解し且つこれらの要求をアプリケ
ーションのインタフェース表示内に形成する； ＊ アプリケーションからの応答を受理する； ＊ これらの応答をHTMLに変換し、このHTMLをHTTPオブ
ジェクトに送信する。

図15に示されているように、HTMLオブジェクトは、ブ
ラウザの型によって更にサブクラス化することができ
る。HTTPオブジェクトの場合と同様に、このサブクラス
化の目的は、特定のブラウザによって最も良く理解され
るようなHTMLを生成することにある。しかしながら、HT
TPオブジェクトは、単にHTMLを入力として受け取り、HT
ML/HTML又はHTML/ASCIIフィルタとして機能するに過ぎ
ないから、入力のHTMLが表す実際のデータに対し何の意
味も与えない。これとは対照的に、HTMLオブジェクトの
ステージでは、アプリケーションとのインタフェースの
設計者は、このデータが真に何を表してるかを依然とし
て知っている。従って、この設計者は、このステージに
おけるブラウザの選択に反応し、このブラウザの識別に
応じて、このデータをHTML又はASCIIにフォーマット化
することができる。簡単な１つの例は、グラフのブラウ
ザによって要求することである。このブラウザが「NetS
cape」ブラウザであれば、HTMLオブジェクトは、GIFと
して送信されるようなグラフを生成することができよ
う。他方、このブラウザが或るコマンド行であれば、こ
のブラウザは、このグラフのASCII近似を生成すること
になろう。

本発明の実施例では、２つのオブジェクトが関与す
る。

第１のオブジェクトは、HTTPオブジェクトである。こ
のオブジェクトは、HTTP接続をカプセル化する。

そのメンバは、次の通りである。

TCP/IPソケット。

要求されたURL。

そのメソッドは、次の通りである。

get the path; get the service; get the user; get the password; get the capability; get the particular arguments。

第２のオブジェクトは、HTMLオブジェクトである。こ
のオブジェクトは、HTML/アプリケーション・インタフ
ェースをカプセル化する。

そのメンバは、次の通りである。

HTMLデータ。

そのメソッドは、次の通りである。

adding text; adding of markup; adding of browser−sepcific markup。

本発明のこの実施例は、HTTPオブジェクト及びHTMLオ
ブジェクト用の１組のクラス・ライブラリとして実現さ
れる。このHTMLオブジェクトは、特定のブラウザに固有
のマークアップ機能を提供するように、サブクラス化さ
れることになろう。本発明は、ウェブ・サーバが生成す
るHTMLを、特定のブラウザ（例えば、MVS又はVT100ブラ
ウザ）に適合させるために使用される。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ０８／５５８，６２８ (32)優先日 平成７年11月14日(1995．11．14) (33)優先権主張国 米国（ＵＳ） (31)優先権主張番号 ０８／５５８，６３１ (32)優先日 平成７年11月14日(1995．11．14) (33)優先権主張国 米国（ＵＳ） (72)発明者 リード、ベンジャミン アメリカ合衆国カリフォルニア州サン タ・クルーズ、コシュランド・ウエイ 507 (72)発明者 ウエルッチ、ステイーブン アメリカ合衆国カリフォルニア州ギルロ イ、カナダ・ロード 3330 (72)発明者 メドフォード、ミッチェル アメリカ合衆国ノースカロライナ州カリ ー、ストラスバーグ・レーン 109 (56)参考文献 特開 平７−175730（ＪＰ，Ａ) 特開 平９−101924（ＪＰ，Ａ) 佐藤豊，多目的プロキシ・サーバＤｅ ｌｅＧａｔｅの機能詳細−アクセス／経 路制御とプロトコル変換，インターフェ ース，日本，ＣＱ出版社，1995年９月１ 日，第21巻 第９号 通巻220号，ｐ. 130−146 樋口貴章，ＷＷＷの機能を拡張するＪ ａｖａとＨｏｔＪａｖａ，日経バイト, 日本，日経ＢＰ社，1995年11月１日，第 144号，ｐ．256−269 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 13/00 G06F 15/00 H04L 12/00 H04L 29/00

Claims (2)

(57)【特許請求の範囲】
1. 【請求項１】一のクライアント・コンピュータ装置が一
   のサーバ・コンピュータ装置に置かれている情報をアク
   セスすることを可能にするための情報ハンドリング・シ
   ステムであって、 前記クライアント・コンピュータ装置が、ハイパーテキ
   スト転送プロトコル（HTTP）を使用して前記サーバ・コ
   ンピュータ装置と通信するための手段及び前記サーバ・
   コンピュータ装置から受信される情報をハイパーテキス
   ト・マークアップ言語（HTML）を使用して当該クライア
   ント・コンピュータ装置の一のユーザに供給するための
   手段を含み、 更に、前記情報ハンドリング・システムが、 前記クライアント及びサーバ・コンピュータ装置間に設
   けられた一のネットワークを備え、 当該ネットワークが、HTTPとは異なる一のネットワーク
   伝送プロトコルを使用するとともに、HTMLとは異なる一
   のネットワーク・データ・フォーマットを使用するもの
   であり、 更に、前記クライアント及びサーバ・コンピュータ装置
   から前記ネットワークを介して送信されるか又は前記ネ
   ットワークを介して前記クライアント及びサーバ・コン
   ピュータ装置によって受信されるHTML/HTTP情報を、前
   記ネットワーク伝送プロトコル及び前記ネットワーク・
   データ・フォーマットに変換するための伝送プロトコル
   変換手段を備え、 前記伝送プロトコル変換手段が、オブジェクト指向のコ
   ンピュータ・ソフトウェアを実行し、 前記クライアント・コンピュータ装置が、インターネッ
   トに接続され、前記ネットワークが、前記インターネッ
   トと前記サーバ・コンピュータ装置の間に設けられ、 前記サーバ・コンピュータ装置が、一のシステム管理ソ
   フトウェア・プログラムを実行するためのシステム管理
   手段を含み、前記ネットワーク伝送プロトコルが、一の
   システム管理プロトコルであり、前記クライアント・コ
   ンピュータ装置からのHTML/HTTPデータが、前記システ
   ム管理ソフトウェア・プログラムを制御するための少な
   くとも１つのコマンドを含んでいることを特徴とする、
   情報ハンドリング・システム。
2. 【請求項２】前記システム管理ソフトウェア・プログラ
   ムが、前記クライアント及びサーバ・コンピュータ装置
   のハードウェア及びソフトウェア構成に係るデータを処
   理することを特徴とする、請求の範囲第１項記載のシス
   テム。