JP2007533038A

JP2007533038A - モニター情報の収集方法

Info

Publication number: JP2007533038A
Application number: JP2007508557A
Authority: JP
Inventors: アレックス・ザレニン
Original assignee: リーマン・ブラザーズ・ホールディングス・インコーポレーテッド
Priority date: 2004-04-14
Filing date: 2005-04-14
Publication date: 2007-11-15
Anticipated expiration: 2025-04-14
Also published as: WO2005103915A2; WO2005103915A3; JP4620112B2; US20050235071A1; US7784064B2

Abstract

本発明は、ウィンドウズベースのコンピュータシステムに接続されたモニターに関する情報の収集方法を提供する。そしてその方法は、コンピュータが、モニタークラスの定義を決定するステップと、モニター情報提供部を生成するステップと、少なくとも１つのモニターを含むウィンドウズベースのコンピュータにモニター情報提供部をロードするステップと、前記モニター情報提供部によって、前記モニターのシリアル番号と型の情報を収集するステップと、を含むことを特徴とする。

Description

本発明は、企業システムと、アプリケーションと、ネットワークとの管理に関するものである。

本願は、2004年4月14日に米国で出願され、発明の名称を「モニター情報の収集方法」とする出願番号が60/562,068の米国仮出願の優先権を主張する。米国出願の内容はこれを引用することによって本願に組み込まれる。

情報技術の管理者が直面している重大な挑戦の１つは、益々巨大化して且つ複雑化している企業システムと、アプリケーションと、ネットワークを管理することである。これらの課題を解決して、ウィンドウズ（登録商標。以下同じ。）ベースのサーバーとデスクトップの所有者の総経費（total cost of ownership：ＴＣＯ）を減らすことを助けるため、マイクロソフト（登録商標。以下同じ。）社は、拡張性のある管理インフラであるウィンドウズ管理手段（Windows Management Instrumentation：ＷＭＩ）を開発して、ウィンドウズＯＳの一部としてこれを含めた。

ＷＭＩはウェブベースの企業管理（Web-Based Enterprise Management：ＷＢＥＭ）というマイクロソフト社の実現方法である。ＷＢＥＭは、いわば、企業環境での管理情報へのアクセスのための標準技術を開発するための業界標準である。ＷＢＥＭ標準は、システム管理の標準化団体（Distributed Management Task Force：ＤＭＴＦ）において活動している多数の会社だけではなく、マイクロソフト、ＢＭＣソフトウェア、シスコシステムズ、コンパックコンピュータ、インテル（登録商標）の協力的努力により実現されている。ＤＭＴＦによって採用されたシステム、アプリケーション、ネットワーク、装置、その他の管理された要素を表現するため、ＷＭＩはＤＭＴＦによって定義された共通の型情報（Common Information Model：ＣＩＭ）を使用する。ＷＭＩは、ウィンドウズのプラットフォームから入手可能な追加情報のＣＩＭモデルに対する拡張と同じように、ＣＩＭによって定義された管理されたオブジェクトを具備している。

前記ＷＭＩ構造は、管理インフラ（management infrastructure）とＷＭＩ提供部とから構成されている。管理インフラは、ＣＩＭオブジェクト管理部（CIM Object Manager：ＣＩＭＯＭ）とＣＩＭＯＭオブジェクト保管庫（CIMOM Object Repository）と呼ばれる管理データに対する中央記憶領域を含んでおり、前記ＣＩＭＯＭは、アプリケーションに管理データへの均一なアクセスを行う。ＷＭＩ提供部は、管理されたオブジェクトＣＩＭＯＭとの間の仲介役として機能する。ＣＩＭＯＭは、基礎的な提供部の能力に関係ない単一ＡＰＩを通して同じ一連の能力（データ検索、更新、質問、実行の方法及びイベント）を提供する、ＷＭＩベースの管理アプリケーションに特有の提供部の能力を隠蔽する。

この階層構造は、必要なだけこの構造に加えられることを、より多く提供部に許可することによって、ＷＭＩ構成の継ぎ目の無い拡張を提供する。新たな提供部に対する必要性は、新たな管理資源がコンピュータ環境の中に導入されたときに生じる。最近では、コンピュータのモニターはこれらの新たな資源の一つとなってきている。

ホストシステムの価格の急激な下落とモニター技術の進歩のために、大画面液晶表示パネルやプラズマスクリーンのようなモニターによって、一般的なコンピュータシステムにかかる大部分の費用が費やされ始めた。さらに、最近の進歩したＯＳとグラフィックカードは、そのシステムのために（いくつかの例において、８個までかそれ以上）複数のモニターの接続を許可している。このように、モニターは、社内ネットワークで追跡したりすべき必要がある重要な資源の１つになってきている。

本発明は、ウィンドウズベースのコンピュータシステムに接続されたモニターに関する情報収集の方法の提供を目的とする。モニタークラスの定義は決められ、モニター情報の提供部は生成される。モニター情報の提供部は少なくとも１つのモニターを含むウィンドウズベースのコンピュータにロードされる。そしてモニター情報の提供部はシリアル番号とモニターの型情報を収集する。

上述した一般的な記載と後述の詳細な記載の両方は、例示的で且つ説明のためのものであり、また特許請求された発明の更なる説明を目的としていることが理解されるべきである。

そこで、本発明のモニター情報の収集方法は、ウィンドウズベースのコンピュータシステムに接続されたモニターに関する情報の収集方法であって、モニタークラスの定義を設定するステップと、モニター情報提供部を生成するステップと、少なくとも１つのモニターを含むウィンドウズベースのコンピュータにモニター情報提供部をロードするステップと、前記モニター情報提供部によって、前記モニターのシリアル番号と型の情報を収集するステップと、を具備することを特徴とする。

また本発明は、前記モニターの情報を収集するステップは、コンピュータ上で拡張されたデータ識別ブロックをプラグアンドプレイして解析するステップと、前記拡張されたデータ識別ブロックのプラグアンドプレイにより、シリアル番号と型の情報を抽出するステップと、を具備することを特徴とする。

そして本発明は、登録されたスクリプトにしたがって、前記モニター情報提供部が管理インフラを利用可能とすることを特徴とする。

さらに本発明は、前記登録したスクリプトはモニター管理オブジェクトを定義し、前記モニター管理オブジェクトのインスタンス(instance）のプロパティ（property：以下、特性という）を前記モニター情報提供部と関連付けることを特徴とする。

本発明の好適な実施形態について、例えば添付図面に表すことにより、以下に詳細に説明する。各図面では、同一または同様な部分には、図面全体を通して同一の符号が用いられる。

添付図面は、発明の理解を深めるためのもので、明細書の一部に組み込まれるとともにその一部を構成し、本発明の実施例を図示し、かつ本発明の原理を明細書の記載とともに説明するためのものである。

最近のモニター（プラグアンドプレイ仕様をサポートするもの）は、型やシリアル番号をホストシステムに報告する能力がある。この情報は、モニター資源の管理や社内でのその所在の追跡にとって重要である。ＣＩＭの原型とＷＭＩ提供部の標準的セットは、このコンピュータ環境の重大な変化に対応していない。そして、取り付けられたモニターから型番やシリアル番号の情報を検索する特徴を提供しない。このように、モニターオブジェクトをＣＩＭの概念に加えることや、対応する提供部を開発することにより、ＷＭＩを拡張する必要がある。

この目的を達成するために、本発明は、ＣＩＭＯＭに不可欠なモニター情報を洗い出して、好適なＷＭＩ特性の提供部のプログラムの実現方法を提供する。本発明は、また、管理オブジェクト形式（Managed Object Format：ＭＯＦ）のスクリプトを提供し、モニター情報のクラスについてのＣＩＭの概念を拡張し、このクラスの特性（モニターの型とシリアル番号）を対応する好適な提供部と関連付ける。

本発明にしたがって、デジタルコンピュータシステム（本明細書においてＷＭＩモニター情報特性提供部（WMI Monitor Information Property Provider：ＷＭＩ−ＭＩＰＰ）と称する）は、ＭＯＦやＣＯＭ，Ｗｉｎ３２ＡＰＩをホストシステムに接続したモニター装置の発見と識別のために利用する。ＷＭＩインターフェース仕様に付随した構成要素のＣＯＭは、ＷＭＩMonitorInfoクラスのインスタンスを表している。これは、標準化された一貫した方法で、本システムに接続されたモニターに関して詳細に提供する。この管理オブジェクト形式（ＭＯＦ）の言語におけるスクリプトは、コンパイルされたとき、MonitorInfoという新しいクラスを、ＷＭＩの名前領域の中に導入し、そのクラスと当該特性提供部の間でリンクを確立する。

図１はこのＷＭＩ構造を表現している。このＷＭＩ構造は、管理インフラ１０１とＷＭＩ提供部１０２（例えばＷＭＩ−ＭＩＰＰ）を具備している。この管理インフラ１０１は、ＣＩＭオブジェクト管理部（ＣＩＭＯＭ）１０３と、このＣＩＭＯＭオブジェクト保管庫１０４として参照される、管理データに対する中央記憶領域を含む。このＣＩＭＯＭ１０３はアプリケーションに管理データへの同一のアクセスを実行させる。ＷＭＩ提供部１０２は、ＣＩＭＯＭ１０３と管理オブジェクト１０５の間の仲介者として機能する。管理オブジェクト１０５は、例えばコンピュータシステム、ハード・ドライブ、あるいはモニターである。一般的に、管理オブジェクト１０５は提供部１０２の１つが関与する項目である。一連のＷＭＩ特性ＣＯＭインターフェースとして定義されたＷＭＩＡＰＩの使用により、提供部１０２は管理オブジェクト１０５からのデータをＣＩＭＯＭ１０３に供給し、管理アプリケーション１００に代わって要求を処理し、通知イベントを生成する。

ＷＭＩ構造の構成要素間の通信は以下の記載の通りである。ある要求が、例えばあるクラスについての情報に対して、管理アプリケーション１００から作られたとき、ＣＩＭＯＭ１０３はＣＩＭオブジェクト保管庫１０４からそのクラスについての情報を検索し、要求された情報が返答される。その返答されたその情報に基づいて、ＣＩＭＯＭ１０３は、ＣＩＭオブジェクト保管庫１０４からのクラスについての情報を取得できるかどうか、又は提供部１０２の１つを照会しなければならないかどうかを決定する。もし、ＣＩＭＯＭ１０３がその提供部１０２の照会を必要とする場合は、ＣＩＭオブジェクト保管庫１０４から提供部１０２についての情報を得る。すなわち、その情報は、主に、どのようなタイプの提供部１０２か、どのように提供部１０２と通信するか、どのような特性が提供部を支援するかなどである。

このＷＭＩ仕様は、クラス、インスタンス、特性（プロパティ）の提供部のような、その管理インフラ１０１の中に組み込まれる種々の提供部を定義する。クラス提供部は、ＣＩＭＯＭオブジェクト保管庫１０４内の対応するＷＭＩ管理オブジェクト（クラス）を定義し、識別し、このクラスのインスタンスを生成する。クラス提供部は、たいてい自分自身を含んでいるか、同時に、もっとも堅固(rigid）な提供部である。、いったん実行されると、対応するクラスへの変更か、その提供部の再コーディングを必要とする。また、対応するクラスのインスタンスの特性は、他のクラスで直接使用されない。

インスタンス提供部は、予め決められたＷＭＩ管理オブジェクトのインスタンスを定義し、対応する管理オブジェクトのインスタンスと関連する値か、得られた値についてのそれらの特性を生成する。もし、オブジェクトの定義が変更された場合、インスタンス提供部のコードもまた、これに従って変更されなければならない。

ＷＭＩ特性提供部は、ある管理オブジェクトのカテゴリの特性のみを管理インフラに供給する。これらの特性はいくつかのＷＭＩ管理オブジェクトのインスタンスに、その提供部の外側でかつ独立的に、一般的にはＭＯＦスクリプトを通して、写像されるはずである。示された特性が同一である限り、通常はどんな物理的なオブジェクトに対する場合であっても、特性提供部を変更する必要はない。ただし、管理オブジェクトの定義は変更してもよい。特性は異なるクラスのインスタンスに写像しても良いが、その提供部は同一性を保持し、かつ管理インフラに役に立つ機能性を提供できる。

これらを考慮することによって、本発明の前記ＷＭＩ提供部は、開発され、特性提供部（すなわちＷＭＩ−ＭＩＰＰ）としてコード化された。特性提供部は、ＷＭＩ−ＭＩＰＰをＷＭＩ管理の枠組みの中にもたらす、対応するＭＯＦスクリプトの開発を必要としている。

図２はモニター情報特性提供部オブジェクト２００（図１で示される提供部１０２の１つ）のＣＯＭ表現を図示している。このオブジェクト２００は、二つの標準的なＣＯＭインターフェース（IUnknown２０１とIDispatch２０２）と、ＷＭＩ特性提供インターフェース（ＩＷＢＥＭPropertyProvider２０３とＩＷＢＥＭProviderInit２０４）に対して要求される二つのインターフェースと、空のＩＷＰＰＭＩインターフェース２０５とを実行する。これらのインターフェースは図３，４及び５に詳しく説明されている。

図３は、図２のＩＷＢＥＭPropertyProviderインターフェース２０３の定義を図示している。この定義はマイクロソフトのインターフェース定義言語（Microsoft Interface Definition Language：ＭＩＤＬ）でなされている。このインターフェースはGetPropertyとPutPropertyの二つの方法を定義する。これらの方法は、対応する特性提供部によって表されたその特性への読み書きアクセスを実行するために、図１の管理インフラ１０１によって呼び出される。

図４は、提供部１０２がその提供部１０２に内部データ構造を初期化する機会を与えるために実行されるときや、その提供部１０２の操作状態について管理インフラ１０１に知らせるときに、図１の管理インフラ１０１によって呼び出される、図２のＩＷＢＥＭProviderInitインターフェース２０４のＭＩＤＬ定義を図示する。

図５は、図２のＩＷＰＰＭＩインターフェース２０５のＭＩＤＬ定義を図示ずる。このインターフェースは、特性、方法、もしくはその中に定義されるイベントを持たない。それは本質的に空であり、IDispatchインターフェース２０２定義（継承を通して）を、図２のモニター情報ＣＯＭオブジェクト２００の実行の中にもたらすためにのみ使用される。

図６は、そのＣＯＭクラスのＭＩＤＬ定義を図示する。これはＷＭＩ−ＭＩＰＰオブジェクトを具現化する。定義において見られるように、ＷＭＩ−ＭＩＰＰオブジェクトは図３，４及び５に示される全部で三つのインターフェースを実装する。

図７は、そのモニターが拡張データ識別（Extend Data Identification：ＥＤＩＤ）ブロックとプラグアンドプレイするためのウィンドウレジストリのパス７００を図示する。そのブロックは、モニターのシリアル番号と型の情報を含む他の情報を加えたものである。図８は、典型的なＥＤＩＤブロックの構造を図示する。ＥＤＩＤデータブロックは１８バイトの行が１以上で構成される。各行は５バイトの記述子と１３バイトのデータ領域を持つ。この例において、シリアル番号データ領域は“００００００ＦＣ００” 記述子８０１によって、またモニター型データ領域は“００００００ＦＦ００” 記述子８０２によって識別される。もしそのデータ領域内の文字列型データが１３文字より短ければ、それはＡＳＣＩＩの改行コードである“０Ａ“（１６進数表記）によって終了される。

図９を参照すると、ＷＭＩ提供部がＣＩＭＯＭ１０３を利用可能とするために、その提供部は、ＣＩＭＯＭを識別して、ＣＩＭ保管庫内にすでにいくつか存在するか又は新しい１つの管理オブジェクトクラスと関連させなければならない。これらの機能の両方はＭＯＦコンパイラーによって実行される。これは、ＭＯＦ形式で表現され必要とされた指示語を処理する。図９で示されるそのＭＯＦスクリプトは、新しいモニター情報のクラス（MonitorInformation class）を定義する。そして新しいＷＭＩ−ＭＩＰＰを導入し、これと（図６で定義される）ＣＯＭクラスを関連させる。そしてこの提供部によって示された特性をそのモニター情報クラスのインスタンスと関連させる。図９で示される典型的なスクリプトにおいて、モニター情報クラスの二つのインスタンスのみが定義される。これは二つまでのモニターをシステムに接続するには十分である。三つ以内のモニターを取り付けたシステムにとって、このスクリプトのサンプルは、必要な数のインスタンスを定義するために拡張されることが必要である。

より好適なＷＭＩ−ＭＩＰＰの実現方法を次の通り詳細に説明する。ＷＭＩ提供部はＷＭＩ仕様のインターフェースを表すＣＯＭオブジェクトである。図２，３及び４は、ＷＭＩ−ＭＩＰＰがＷＭＩ特性提供部になるために実装する、そのＣＯＭインターフェースを詳しく説明する。標準的なＣＯＭオートメーションコンテナ（ビジュアルベーシックやエクセルなどのように）の直接的な使用と同様に、ＷＭＩ管理の枠組み内から（ＷＭＩ特性提供部として）もＷＭＩ−ＭＩＰＰをアクセス可能とするため、図５に詳しく示すように、ＷＭＩ−ＭＩＰＰオブジェクトは、IDispatchＣＯＭインターフェースから引き出される追加的なインターフェースを実装する。これはＷＭＩ−ＭＩＰＰにＣＯＭオートメーションコンテナと互換性を持たせる。

ＷＭＩ提供部が図1のＷＭＩ管理インフラ１０１によってロードされたとき、そのインフラはIWbemProviderInitを呼び出す。それは、内部データ構造を初期化する為の機会を提供部に与えるための初期化方法（図４参照）である。初期化方法であるIWbemProviderInitは、ＷＭＩ−ＭＩＰＰの実行、すなわちウィンドウズのレジストリ（つまり、コンピュータ上の階層的なハードウェアとソフトウェアの表現）を走査し、このシステムに接続された現在使用中の全てのモニターに対して順序付けられた一連の型とシリアル番号のセットを構築する。

そうして、初期化ルーチンは、図７のHKLM\System\CurrentControlSet\Enum\Display レジストリキーの下、その全てのサブキーを列挙することによって開始する。あらゆるサブキーは、モニターのクラスが少なくともそのシステムにある時間接続したことを表す。各モニタークラスのサブキー、例えばサブキー７０２の下で、サブキーのリスト、例えばサブキー７０３，７０４があり、少なくともこのシステムにある時間接続した、このクラスの個々のモニターのインスタンスに対応している。現在このシステムに接続されているこのモニターは、対応するモニターのインスタンスのサブキー７０６の下のControlサブキー７０５の存在によって識別される。

図７はさらに次のことを示している。すなわち、ＷＭＩ−ＭＩＰＰ初期化ルーチンは、サブツリーのレジストリの走査の間、現時点でアクティブなモニターのサブキーのインスタンスを確認すると、Device Parametersサブキー７０７の分析、特にＥＤＩＤ値を探すことを続ける。ＥＤＩＤ値は、もしそれが存在するならば、ＥＤＩＤデータブロック（図８参照）を表示する。すなわち、その初期化ルーチンはそのブロックを解析して、そのモニターの型とシリアル番号を検索し、発見されたモニターの型とシリアル番号の組み合わせを順序付けられたリストに加える。

レジストリ走査が完了したとき、モニターの型とシリアル番号の順序付けられたリストは作成され、初期化ルーチンは初期化が完了したことを示すフラグをセットし、初期化ルーチンに対するその後の呼び出しは無視される。

初期化が完了した後、提供部は要求に答える状態となる。可能性として存在する要求としては、IWBEMPropertyProviderインターフェース（図３参照）によって定義されるとおりに呼ばれるGetPropertyと PutProperty手段である。このIWBEMPropertyProviderのGetProperty手段は、図１に示すＷＭＩ管理インフラ１０１が接続されたモニターの特性を得ようとするときにＷＭＩ−ＭＩＰＰで呼び出される。

とりわけ、その枠組みは三つの重要な変数をIWBEMPropertyProviderに供給する。このIWBEMPropertyProviderのGetProperty手段の実装は、そのクラスの写像、インスタンスの写像、そして特性の写像である。ＷＭＩ−ＭＩＰＰにとって、最初の変数は”Monitor”であるべきである。インスタンスの写像である二番目の変数は、必要とされるモニター情報のインスタンスを識別する正の数であるべきである。例えば、単数のモニターシステムで、インスタンス写像変数に対する唯一の意味のある値は１となり、複数のモニターシステムの場合はインスタンス写像変数に対する値は１又は２となる。特性の写像である三番目の変数は、”Model”か”SerialNumber”の一方であり、検索されることが必要な特性に依存している。もし、そのクラスか特性の写像の一つの値が無効であれば、ＷＭＩ−ＭＩＰＰはＷＭＩエラーコードを返す。もし、インスタンス写像の値がそのシステムのモニターの数を超えている場合、ＷＭＩ−ＭＩＰＰはＷＭＩが見つかりませんという警告の”Not Found“を返す。

モニターの型とシリアル番号は基本的に読み込み専用属性なので、IWBEMPropertyProviderのPutProperty手段は実装されない。このようにPutPropertyが呼ばれるとき、標準的なＷＭＩエラーメッセージ”Not implemented”を返す。

ＷＭＩ−ＭＩＰＰの登録されたＭＯＦスクリプトについての詳細は次の通り示される。本発明と関連して提供されるＭＯＦスクリプトは、図９に示されるように、ＷＭＩ−ＭＩＰＰに図１に示すＷＭＩ管理インフラ１０１への利用を可能とする。そして、モニター情報ＣＩＭ管理オブジェクトを定義し、このオブジェクトの属性をＷＭＩ−ＭＩＰＰによって表される特性と関連させる。これらの目的の達成のために、このスクリプトはコンパイルユーティリティのmofcomp.exeであるＭＳＭＯＦを使用する目的のコンピュータシステムでコンパイルされる。

このＭＯＦ言語の詳しい説明はＳｔｅｍｐ，Ｇｒｅｇの”WMI Helps Those Who Help Themselves”，２００４年２月１１日，http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting02102003.asp.に記載されている。本質的にＷＭＩ−ＭＩＰＰに関するこのスクリプトの節の説明を以下に行う。
instance of _Win32Provider as $WPPMI
{
Name = “MIPP”;
ClsId = “{E6E084BE-38BB-4E55-9AA0-1783C7211FAC}”;
};
この最初の節は、ＷＭＩ管理インフラの層(fold)に、新しいＷＭＩ互換の提供部としてClsId特性の値によって識別される、ＣＯＭオブジェクトを導入する。この節におけるこのClsIdの値はＭＩＰＰＣＯＭクラス（図６参照）の定義におけるuuid値と合致する。二番目の節は以下のとおりで、特性提供部としてのこの新しい提供部を定義する。
instance of _PropertyProviderRegistration
{
Provider = $WPPMI;
SupportsPut = FALSE;
SupportsGet = TRUE;
};
三番目の節は以下の通りで、新しい管理オブジェクトのMonitorInformationクラスに、モニターの型とシリアル番号情報を記録するために定義する。
#pragma deleteclass(“MonitorInformation”, NOFAIL)
class MonitorInformation
{
[KEY] STRING InstKey;
uint32 Index;
STRING Model;
STRING SerialNumber;
};
最後の二つの節は、MonitorInformationクラスを定義し、かつこのクラスの属性をＷＭＩ−ＭＩＰＰによって表された特性とこのクラスの二つのインスタンスを関連付ける。このClassContextと、InstanceContextと、PropertyContextとの属性は、ＭＩＰＰ提供部を呼び出すGetProperyの変数であるClassMapping,InstanceMapping及びPropertyMappingの値の中に、このインフラによって写像される値を提供する。

以上、本発明を詳細に、且つその特定の態様に言及して説明してきたが、これらはこの技術分野における一つの技術にすぎないのは明らかであり、本発明の範囲から逸脱しない範囲で多様に変形できる。よって、本発明の範囲は、多様な変形をカバーし、特許請求の範囲の記載及びこれと均等な範囲に基づいて定められるべきである。

本発明の好適な実施形態に関して使われる典型的な構造の図である。本発明の好適な実施形態に関して使われる提供部オブジェクトの好適な実施形態の図である。本発明の好適な実施形態に関して使われるインターフェース定義の図である。本発明の好適な実施形態に関して使われるインターフェース定義の図である。本発明の好適な実施形態に関して使われるインターフェース定義の図である。本発明の好適な実施形態に関して使われるクラス定義の図である。本発明の好適な実施形態に関して使われる典型的なレジストリの表現である。本発明の好適な実施形態に関して使われる典型的な拡張データ識別ブロックの図である。本発明の好適な実施形態に関して使われる典型的なＭＯＦスクリプトを示す。

符号の説明

１００管理アプリケーション
１０１管理インフラ
１０２ＷＭＩ提供部
１０３ＣＩＭＯＭ
１０４ＣＩＭＯＭオブジェクト保管庫
１０５管理オブジェクト
２００モニター情報特性提供部オブジェクト
２０１ IUnknown
２０２ IDispatch
２０３ＩＷＢＥＭPropertyProvider
２０４ＩＷＢＥＭProviderInit
２０５ＩＷＰＰＭＩインターフェース
７００ウィンドウレジストリのパス
７０１，７０２，７０３，７０４，７０５，７０６，７０７サブキー
８０２記述子

Claims

ウィンドウズベースのコンピュータシステムに接続されたモニターに関する情報の収集方法であって、
（Ａ）モニタークラスの定義を設定するステップと、
（Ｂ）モニター情報提供部を生成するステップと、
（Ｃ）少なくとも１つのモニターを含むウィンドウズベースのコンピュータにモニター情報提供部をロードするステップと、
（Ｄ）前記モニター情報提供部によって、前記モニターのシリアル番号と型の情報を収集するステップと、
を具備することを特徴とする収集方法。
前記モニターの情報を収集するステップは、
（Ｅ）コンピュータ上で拡張されたデータ識別ブロックをプラグアンドプレイして解析するステップと、
（Ｆ）前記拡張されたデータ識別ブロックのプラグアンドプレイにより、シリアル番号と型の情報を抽出するステップと、
を具備することを特徴とする請求項１に記載の収集方法。
登録されたスクリプトにしたがって、前記モニター情報提供部が管理インフラを利用可能とする、ことを特徴とする請求項１に記載の収集方法。
登録されたスクリプトは、モニター管理オブジェクトを定義し、前記モニター管理オブジェクトのインスタンスの特性を前記モニター情報提供部と関連付ける、ことを特徴とする請求項１に記載の収集方法。