(57)【要約】  複数のＭＤＲを管理するＦＣＭＤＢからＭＤＲへ情報の更新系処理を行なう情報管理装置は、管理している情報がＭＤＲの何れから来たかを示すメタ情報を記憶するメタ情報管理部と、メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っているＭＤＲを絞り込み、絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう更新系処理部とを備える。
2009122527.tif 000002
【特許請求の範囲】
【請求項１】
複数の装置構成情報管理装置を管理する仮想統合管理装置から装置構成情報管理装置へ情報の更新系処理を行なう情報管理装置であって、  管理している情報が装置構成情報管理装置の何れから来たかを示すメタ情報を記憶するメタ情報管理部と、  前記メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っている装置構成情報管理装置を絞り込み、絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう更新系処理部と、を備えた仮想統合管理装置。
【請求項２】
前記メタ情報管理部は、更新系処理の依頼である識別子の属性情報を記憶し、  前記更新系処理部は、前記属性情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っている装置構成情報管理装置を絞り込み、絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう、請求項１に記載の仮想統合管理装置。
【請求項３】
前記メタ情報管理部は、登録／更新／削除等の更新系処理の依頼を受理する装置構成情報管理装置が存在しなかった場合に、登録／更新／削除等の更新系処理の情報を一時保存する、請求項１または２に記載の仮想統合管理装置。
【請求項４】
新しい装置構成情報管理装置が前記仮想統合管理装置に登録された時、該装置構成管理装置に前記メタ情報管理部が一時保存した情報の更新系処理の依頼を行ない、当該装置構成情報管理装置が依頼を受理した場合は一時保存していた処理依頼を完了する更新系再処理部を備えた、請求項１乃至３の何れか１項に記載の仮想統合管理装置。
【請求項５】
前記更新系再処理部は、受理しなかった装置構成情報管理装置に対して再度処理依頼を行ない、当該装置構成情報管理装置が依頼を受理した場合は一時保存していた処理依頼を完了する、請求項１乃至４の何れか１項に記載の情報管理装置。
【請求項６】
複数の装置構成情報管理装置を管理する仮想統合管理装置から装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置のプログラムであって、  コンピュータに、  調和に使った情報が装置構成情報管理装置の何れにあるのかを示すメタ情報を記憶する第１ステップと、  前記メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持つ装置構成情報管理装置を絞り込む第２ステップと、  絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう第３ステップと、実行させるプログラム。
【請求項７】
複数の装置構成情報管理装置を管理する仮想統合管理装置から装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置のプログラムであって、  コンピュータに、  更新系処理の依頼である識別子の属性情報を記憶する第１ステップと、  前記属性情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っている装置構成情報管理装置を絞り込む第２ステップと、  絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう第３ステップと、を実行させるプログラム。
【請求項８】
コンピュータに、  前記第２ステップで絞込んだ結果、  該当する装置構成情報管理装置が有ると判定されたときは絞込んだ全装置構成情報管理装置に対して処理依頼を行なう第４ステップと、  該当する装置構成情報管理装置が無いと判定され、かつ何れかの装置構成情報管理装置も処理依頼を受理していないと判定されたときは、処理依頼を前記仮想統合管理装置に保存する第５ステップと、を実行させる請求項６または７に記載のプログラム。
【請求項９】
コンピュータに、  新しい装置構成情報管理装置が前記仮想統合管理装置に登録されたか否かを判定する第６ステップと、  新しく登録された装置構成情報管理装置に対し前記仮想統合管理装置に保存した処理依頼を行なう第７ステップと、を実行させる請求項８に記載のプログラム。
【請求項１０】
コンピュータに、  一定時間待ち、一定時間が経過したら絞込んだ全装置構成情報管理装置に対して前記仮想統合管理装置に保存した処理依頼を再度行なう第８ステップと、を実行させる請求項８に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は調和（Reconciliation）機能を持つ仮想統合管理装置（FCMDB: Federated Configuration Management Database）において、ＦＣＭＤＢに対して情報の更新系処理、例えば登録／更新／削除が行なわれた際に、ＦＣＭＤＢの管理対象である装置構成情報管理装置（MDR: Management Data Repository）の各々に対して効率的に更新系処理の依頼を行なう仮想統合管理装置およびそのためのプログラムに関する。
【背景技術】
【０００２】  図１はＦＣＭＤＢの基本機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。ここで、ＦＣＭＤＢとは複数のＭＤＲに格納された異種のデータベースＤＢ（Database）を仮想統合する管理システムを意味し、ＭＤＲは管理するデータベースの記憶装置を意味する。ＦＣＭＤＢ１０は仮想統合している複数のＭＤＲ１１〜１６に格納されたデータベースＤＢに対して横断的に操作を行なうことが可能である。各ＭＤＲ１１〜１６が構成情報、インシデント情報、トラブル情報、リリース情報、変更情報またはアプリケーション情報等のリソースに関する情報（CI &  Relationship）と情報間の関連（Relationship）を管理し、ＦＣＭＤＢ１０が整合化された情報を管理する。ＦＣＭＤＢ１０は外部のコンピュータまたは自身の入力デバイスを介して検索要求を受け、複数のＭＤＲ１１〜１６から検索結果を導出し応答する。なお、以降の図において「アプリケーション」は「アプリ」と略記する。【０００３】  図２はＦＣＭＤＢの調和機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。図２のＦＣＭＤＢ２０は図１のＦＣＭＤＢ１０と同一機能を有する。ＦＣＭＤＢ２０は仮想統合している複数のＭＤＲ２１〜２６に格納されたデータベースＤＢに対して横断的に操作を行なうことが可能であり、情報のリコンシリエーション機能 （調和を図る機能）を有する。ＦＣＭＤＢ２０による情報の調和機能には下記の２点がある。  第１点：データベースＤＢ毎に異なる名前（サーバ、ホスト、ノード）で管理されている同一の更新系処理の依頼（以下、アイテムと記す）アイテム２１Ａ〜２４Ａの情報を統合する。具体的には、名前を「サーバ」に統一する。  第２点：データベースＤＢ毎に異なるロ−カルＩＤ（Webserver1、192.168.10.1、hostnameX）で管理されている同一アイテム２１Ａ〜２４Ａの情報を統合する。具体的には、ＩＤを「Serial Number-XXX」に統一する。【０００４】  特許文献１には、更新を一部の主コピーを有する主データベースでのみ行ない、同期時期になったら主コピー以外の他のコピーを有する従データベースへ主データベースから更新履歴を送信し、更新履歴に従って従コピーを主コピーと同じ内容に更新することにより分散データベースの更新時間の短縮を実現する技術が開示されている。しかしながら、特許文献１に記載の発明は、更新が行なわれる情報に関連する情報を持つＭＤＲ（データベース）に対して同期時期に更新履歴を送信し、同ＭＤＲが情報を更新するが、登録／更新／削除等の更新系の処理依頼そのものを送信するものではない。【０００５】
【特許文献１】特開平6-119227号公報
【非特許文献２】http://cmdbf.org/schema/1-0-0/CMDBf%20v1.0.pdf
【発明の開示】
【発明が解決しようとする課題】
【０００６】  図３は従来技術の課題を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。従来のＦＣＭＤＢ３０は検索機能のみを提供するが、登録／更新／削除機能を提供しない。仮に、ＦＣＭＤＢ３０が仮想統合している全ＭＤＲ３１〜３３に対して登録／更新／削除等の更新系処理の依頼を個別にＭＤＲ３１〜３３に直接アクセスせずにＦＣＭＤＢ２０経由で行なう場合を想定すると、本来処理依頼を行なう必要のないＭＤＲ３２に対しても処理依頼を行ってしまう。換言すれば、処理依頼を受理する／行なうべきＭＤＲが存在しない場合に、処理依頼をどのＭＤＲ３１〜３３に対して行なえばよいのか分からないので本来処理依頼を行なう必要のないＭＤＲ３２に対して不要な処理依頼を行ってしまい、非効率的であるという問題がある。【０００７】  図４は従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系を示す図である。上記従来技術の問題を解決するには、現存するＦＣＭＤＢ４０が登録／更新／削除等の更新系処理の依頼を受けた場合に、本来処理依頼を行なう必要のないＭＤＲ４２に対しあるいは処理依頼を受理するＭＤＲが存在しない場合に全てのＭＤＲ４〜４３に対し、不要な処理依頼を行なわないようすればよい。【０００８】  それゆえ、本発明は、ＦＣＭＤＢによるＭＤＲの管理体系において、ＦＣＭＤＢ４０が登録／更新／削除等の更新系処理の依頼に対して、処理依頼を受理する／行なうべきＭＤＲが存在しない場合に対応できる、各ＭＤＲ４１〜４３に対し効率的に更新系処理を依頼できるようにする更新系処理の依頼を行う情報管理装置およびそのためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】  上記従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置には第１形態〜第５形態がある。【００１０】  第１形態の情報管理装置は、管理している情報がどこから来たかを示すメタ情報を記憶しておき、該メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っているＭＤＲを絞り込み、絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう。【００１１】  第２形態の情報管理装置は、更新系処理の依頼であるアイテムの属性情報を記憶しておき、該属性情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っているＭＤＲを絞り込み、絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう。【００１２】  第３形態の情報管理装置は、どのＭＤＲも登録／更新／削除等の更新系処理の依頼を受理しなかった場合に、ＦＣＭＤＢに登録／更新／削除等の更新系処理の情報を一時保存しておく。【００１３】  第４形態の情報管理装置は、新しいＭＤＲがＦＣＭＤＢに登録された時、当該ＭＤＲは処理依頼を受理する可能性があるので一時保存していた情報の更新系処理の依頼を行ない、当該ＭＤＲが依頼を受理した場合は一時保存していた処理依頼を完了し削除する。【００１４】  第５形態の情報管理装置は、ＭＤＲ側の状況変化（アクセス設定の変更など）により、処理依頼を受理するように状況が変化したかも知れないので受理しなかったＭＤＲに対して再度、例えば定期的に処理依頼を行ない、当該ＭＤＲが依頼を受理した場合は一時保存していた処理依頼を完了し削除する。【００１５】  第１形態に係る複数のＭＤＲを管理するＦＣＭＤＢからＭＤＲへ情報の更新系処理を行なう情報管理装置のプログラムは、  コンピュータに、  管理している情報がＭＤＲの何れから来たかを示すメタ情報を記憶する第１ステップと、  前記メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持つ処理依頼を行なうＭＤＲを絞り込む第２ステップと、  絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう第３ステップと、実行させる。【００１６】  第２〜５形態に係る情報管理装置のプログラムは、上記第２〜５形態に係る情報管理装置の処理をコンピュータに実行させる。
【発明の効果】
【００１７】  第１形態および第２形態によれば、調和に使った管理している情報の出元を記憶しておくことにより、従来技術では実現されていなかった更新系処理を依頼するＭＤＲを不可欠かつ必要最小限に留めることができる。【００１８】  第３〜５形態によれば、どのＭＤＲも処理依頼を受理しない場合や処理依頼を行なうＭＤＲが存在しない場合でも、適切なＭＤＲが現れた時に一時保存していた処理依頼を行なうことが可能となり、ＭＤＲが依頼を受理した場合はＦＣＭＤＢで管理している一時保存していた処理依頼を減らすことができる。
【図面の簡単な説明】
【００１９】
【図１】ＦＣＭＤＢの基本機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術）
【図２】ＦＣＭＤＢの調和機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術）
【図３】従来技術の課題を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術）
【図４】従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系を示す図である。
【図５】ＦＣＭＤＢによるＭＤＲの管理体系における実施形態に係る情報管理装置のブロック構成図である。
【図６】ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第１実施形態を示す図である。
【図７】ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第２実施形態を示す図である。
【図８】ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第３実施形態を示す図である。
【図９】ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第４実施形態を示す図である。
【図１０】ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第５実施形態を示す図である。
【図１１】実施形態に係る情報管理装置による処理のフローチャートである。
【符号の説明】
【００２０】  ５０    ＦＣＭＤＢ  ５１、５２、５３、５４、５５、…、５Ｎ    ＭＤＲ  ５００    CI／Relationshipメタ情報  ５０１〜５０６    Propertyメタ情報  ５１０    情報管理装置  ５１１    メタ情報管理部  ５１２    更新系処理部  ５１３    更新系再処理部  ８００、９００、１０００    未処理情報テーブル
【発明を実施するための最良の形態】
【００２１】  図５はＦＣＭＤＢによるＭＤＲの管理体系における実施形態に係る情報管理装置のブロック構成図である。図５に示す本実施形態に係る情報管理装置５１０はＦＣＭＤＢ５０内に組み込まれている。しかし、他の実施形態では情報管理装置５１０はＦＣＭＤＢ５０に通信可能に接続しＦＣＭＤＢ５０の外部に設置してもよい。本実施形態の情報管理装置５１０はＦＣＭＤＢ５０と同様、少なくとも不図示のＣＰＵ、主記憶（メモリ）、補助記憶（磁気ディスク）を備えたコンピュータ装置である。以下に記す情報は補助記憶に格納され、処理は主記憶に書込まれるプログラムにより実行される。【００２２】  図５に示すように、ＦＣＭＤＢ５０は従来の要求受付部５０１と検索処理部５０２と回答通知部５０３の他に情報管理装置５１０に設けられたメタ情報管理部５１１と更新系処理部５１２と更新系再処理部５１３とを有する。【００２３】  要求受付部５０１は検索／登録／更新／削除の依頼の要求を受け付ける。  検索処理部５０２は要求受付部５０１から検索依頼の要求を受け、ＭＤＲ５１、ＭＤＲ５２、…、ＭＤＲ５Ｎに同要求を送信し、検索結果を受信し、受信した検索結果を回答通知部５０３に送る。検索処理部５０２は検索先が見つかれば検索先の通知を、見つからなければ検索先無しの通知を、検索結果として回答通知部５０３に送る。  回答通知部５０３は検索／登録／更新／削除の依頼の要求元に依頼に対する処理結果を通知することで応答する。【００２４】  メタ情報管理部５１１はメタ情報を管理する。メタ情報は下記の３つの情報を含む。（１）CI／Relationshipメタ情報：管理している情報がどのＭＤＲから来たかを示す元情報を含むメタ情報であり、CI情報とRelationship情報とを含み、CI（Configuration Item）情報は管理している更新系処理の依頼であるアイテムを示す。Relationship情報はアイテム間の関係付けを示し各アイテムがどのＭＤＲのＤＢに格納されているかを示す。【００２５】（２）Propertyメタ情報：アイテムの属性についての情報であり、アイテムのPropertyの名前とそのアイテムがどのＭＤＲから来たかを示す元情報とを含み、Propertyの名前はアイテムのハードウェア、ソフトウェア等の属性を示し、元情報はPropertyの名前に対応する属性情報がどのＭＤＲのＤＢに格納されているかを示す。【００２６】（３）未処理情報：更新系処理の依頼が未完了であることを示す情報であり、依頼ＩＤ、CI／RelationshipＩＤ、種別、PropertyおよびValueの情報を含む。ここで、依頼ＩＤは、未完了の更新系処理の依頼を識別するための情報であり、例えば依頼の名前がこの情報である。CI／RelationshipＩＤは、CI／Relationship情報を識別するための情報である。種別は、更新系処理の依頼が登録／更新／削除の何れであるかを示す情報である。Propertyは、未完了の更新系処理の依頼のアイテムに関連付けられたアイテムのハードウェア、ソフトウェア等の属性を示す情報である。Valueは、Propertyのデータである。【００２７】  更新系処理部５１２は登録／更新／削除等の更新系処理をメタ情報管理部５１１の持つ情報を参照して行なう。  更新系再処理部５１３は更新系処理部５１２で未処理となった更新系処理をメタ情報管理部５１１の持つ情報を参照して新しいＭＤＲに対し、または先に処理依頼が��理されなかったＭＤＲに対し再度定期的に更新系処理を行なう。この処理は再度行なえば定期的に行なわなくてもよい。  以下の説明において、情報管理装置５１０はＦＣＭＤＢ５０に含められるのでＦＣＭＤＢ５０と記す。【００２８】  図６はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第１実施形態を示す図である。ＦＣＭＤＢ５０はCI及びRelationshipメタ情報を使ってＭＤＲを絞込む。【００２９】  図６に示す第１実施形態では、ＦＣＭＤＢ５０はCI／Relationshipメタ情報のテーブル５００とPropertyメタ情報のテーブル５０１〜５０６を格納している。CI／Relationshipメタ情報は、ＦＣＭＤＢに既に登録されているCI／Relationshipの識別子と元情報との対応を管理している。テーブル５００にはCI／Relationshipの識別子であるアイテムＧＩＤ１およびＧＩＤ２に関する情報が登録され、元情報の欄にはアイテムＧＩＤ１に対応してアイテムＧＩＤ１に関連する情報は、ＤＢ１のＬＩＤ１１に、ＤＢ２のＬＩＤ２１、ＤＢ３のＬＩＤ３１およびＤＢ４のＬＩＤ４１に在ることが示されている。アイテムＧＩＤ２に対しても同様であるので説明は省略する。ここで、ＬＩＤ１１、ＬＩＤ２１、ＬＩＤ３１、ＬＩＤ４１は更新系の処理が行なわれる情報である。【００３０】  アイテムＧＩＤ１は更新依頼された情報であり、更新前と更新後のアイテムＧＩＤ１を比較しても判るように、テーブル５００から関連情報Ｍｅｍｏｒｙ、ＣＰＵ、Ａｐｐ（Application）およびＥＲＲＯＲがそれぞれＬＩＤ１１、ＬＩＤ２１、ＬＩＤ３１およびＬＩＤ４１に在ることが判る。ＬＩＤ１１、ＬＩＤ２１、ＬＩＤ３１およびＬＩＤ４１はそれぞれＤＢ１のＭＤＲ５１、ＤＢ２のＭＤＲ５２、ＤＢ３のＭＤＲ５３およびＤＢ４のＭＤＲ５４に格納されているので、ＦＣＭＤＢ５０はこれらのＭＤＲ５１〜５４の４つの候補に絞り込んで更新依頼を行なう。【００３１】  ＤＢ１のＬＩＤ１１でＣＰＵの情報が、ＤＢ２のＬＩＤ２１でＭｅｍｏｒｙの情報が、ＤＢ３のＬＩＤ３１でＥＲＲＯＲの情報が、ＤＢ４のＬＩＤ４１でＡｐｐの情報が、それぞれ更新される。【００３２】  図７はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第２実施形態を示す図である。ＦＣＭＤＢ５０においてメタ情報管理部５１１はPropertyメタ情報を管理する。更新系処理部５１２はPropertyメタ情報を使ってＭＤＲを絞込む。【００３３】  図７に示す第２実施形態では、Propertyメタ情報のテーブル５０１にはアイテムのPropertyの名前の欄にはＩＤ、ＨＤＤ、Ｍｅｍｏｒｙ、ＣＰＵ、ＡｐｐおよびＥＲＲＯＲが示され、元情報の欄にはPropertyの名前ＩＤ、ＨＤＤ、Ｍｅｍｏｒｙ、ＣＰＵ、ＡｐｐおよびＥＲＲＯＲに対応して関連する情報がそれぞれどのＭＤＲのＤＢに格納されているかが示されている。例えば、ＩＤに関連する情報がＭＤＲ（ＤＢ）１のＬＩＤ１１とＭＤＲ（ＤＢ）３のＬＩＤ３１に格納されていることが示されている。【００３４】  アイテムＧＩＤ１は更新依頼された情報であり、更新前と更新後のアイテムＧＩＤ１を比較しても判るように、テーブル５０１からPropertyの名前がＣＰＵ、ＡｐｐおよびＥＲＲＯＲがアイテムＧＩＤ１において更新された情報であることが判る。したがって、ＦＣＭＤＢ５０はＣＰＵ、ＡｐｐおよびＥＲＲＯ��に対応する元情報からＭＤＲ（ＤＢ）１、ＭＤＲ（ＤＢ）２およびＭＤＲ（ＤＢ）４の３つの候補に絞り込んで更新依頼を行なう。【００３５】  図８はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第３実施形態を示す図である。【００３６】  図８に示す第３実施形態では、メタ情報管理部５１１が、関連する情報を持つＭＤＲに登録／更新／削除依頼を行ない、どのＭＤＲでも登録／更新／削除依頼が受理されなかった未処理部分を管理する。登録／更新／削除依頼の未処理部分の情報（以下、未処理情報と記す）をテーブル８００に格納する。【００３７】  未処理情報を格納するテーブル８００は、依頼ＩＤ、CI／RelationshipＩＤ、種別、PropertyおよびValueの欄を有する。依頼ＩＤの欄には未処理情報の名前ＵＤ−０００１、ＵＤ−００１２、ＵＤ−００１３が格納されている。CI／RelationshipＩＤの欄には未処理情報の名前に対応するアイテムＧＩＤ１、ＧＩＤ−１１１、ＧＩＤ−１１２が格納されている。種別の欄には登録／更新／削除が格納されている。Propertyの欄には図示のPropertyの名前ＩＤ、ＩＰＡｄｄｒ、ＵＳＥ、Ｎａｍｅが格納されている。Valueの欄にはPropertyの名前に対応するProperty（属性）値が格納されている。例えば、Propertyの名前ＳＮに対応してその属性値SerialNumber-XXXが格納されている。【００３８】  ＦＣＭＤＢ５０は、アイテムＧＩＤ１の更新での未処理情報、ＣＰＵ、ＡＰＰ、ＥＲＲＯＲを持つアイテムＧＩＤ１を依頼ＩＤ、種別、Property、Valueと共にテーブル８００に格納する。【００３９】  図９はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第４実施形態を示す図である。【００４０】  図９に示す第４実施形態では、更新系再処理部５１３は、メタ情報管理部５１１を参照して、新しいＭＤＲ５がＦＣＭＤＢに登録された時には、更新系処理部５１２がそのＭＤＲ５に対してテーブル９００に格納された完了していない登録／更新／削除の依頼を行なう。また、更新系再処理部５１３は、未処理部分がなくなった登録／更新／削除の依頼に対して、すなわち依頼が受理された場合は、テーブル９００からその依頼を削除する。図９に示す例では、依頼ＩＤがＵＤ−０００１に対し、完了していない更新の依頼を行ない、ＧＩＤ１に関連する更新依頼が受理されたのでテーブル９００からＵＤ−０００１の関連情報を削除する。【００４１】  図１０はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第５実施形態を示す図である。【００４２】  図１０に示す第５実施形態では、更新系再処理部５１３は、メタ情報管理部５１１を参照して、定期的に関連する情報を持つＭＤＲに登録／更新／削除依頼を行ない、どのＭＤＲでも登録／更新／削除の依頼が受理されなかった未処理部分を管理する。更新系処理部５１２が再度定期的に関連する情報を持つＭＤＲに登録／更新／削除依頼を行なう。この処理は再度行なえば定期的に行なわなくてもよい。また、更新系再処理部５１３は、未処理部分がなくなった登録／更新／削除依頼をテーブル１０００から削除する。【００４３】  図１０に示す例では、依頼ＩＤがＵＤ−０００１に対し、完了していない更新の依頼再度を行ない、ＧＩＤ１に関連する更新依頼が受理されたのでテーブル９００からＵＤ−０００���の関連情報を削除する。【００４４】  図１１は実施形態に係る情報管理装置による処理のフローチャートである。以下に、上述した第１実施形態〜第５実施形態に係る情報管理装置による処理を説明する。  第１実施形態では、ステップＳ１でCI／Relationshipメタ情報を使って処理依頼を行なうＭＤＲを絞込む。【００４５】  第２実施形態では、ステップＳ２でPropertyメタ情報を使って処理依頼を行なうＭＤＲを絞込む。【００４６】  第３実施形態では、以下の処理を実行する。  ステップＳ１１で絞込んだ結果、該当するＭＤＲが有るか否かをチェックし、ＹＥＳのときはステップＳ１２に進み、ＮＯのときはステップＳ１４に進む。  ステップＳ１２で絞込んだ全ＭＤＲに対して処理依頼を行ない、ステップＳ１３に進む。  ステップＳ１３で何れかのＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ１４に進む。  ステップＳ１４で処理依頼をＦＣＭＤＢに保存する。【００４７】  第４実施形態では、以下の処理を実行する。  ステップＳ２１で新しいＭＤＲがＦＣＭＤＢに登録されたか否かをチェックし、ＹＥＳのときはステップＳ２２に進み、ＮＯのときはステップＳ２３に進む。  ステップＳ２２で新しく登録されたＭＤＲに保存してある処理依頼を行なう。  ステップＳ２３で新しいＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ２１に戻る。ステップＳ２３でＹＥＳのとき、保存した処理依頼を削除してから本処理を終了する。【００４８】  第５実施形態では、以下の処理を実行する。  ステップＳ３１で一定時間待ち、一定時間が経過したらステップＳ３２に進む。  ステップＳ３２で絞込んだ全ＭＤＲに対して処理依頼を行なう。  ステップＳ３３で何れかのＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ３１に戻る。ステップＳ３３でＹＥＳのとき、保存した処理依頼を削除してから本処理を終了する。
【図１】
2009122527.tif 000003
【図２】
2009122527.tif 000004
【図３】
2009122527.tif 000005
【図４】
2009122527.tif 000006
【図５】
2009122527.tif 000007
【図６】
2009122527.tif 000008
【図７】
2009122527.tif 000009
【図８】
2009122527.tif 000010
【図９】
2009122527.tif 000011
【図１０】
2009122527.tif 000012
【図１１】
2009122527.tif 000013
【手続補正書】
【提出日】平成22年6月30日(2010.6.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数の装置構成情報管理装置を管理する仮想統合管理装置から装置構成情報管理装置へ情報の更新系処理を行なう情報管理装置であって、
管理している情報が装置構成情報管理装置の何れから来たかを示すメタ情報を記憶するメタ情報管理部と、
前記メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っている装置構成情報管理装置を絞り込み、絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう更新系処理部と、を備えた仮想統合管理装置。
【請求項２】
前記メタ情報管理部は、更新系処理の依頼である識別子の属性情報を記憶し、
前記更新系処理部は、前記属性情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っている装置構成情報管理装置を絞り込み、絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう、請求項１に記載の仮想統合管理装置。
【請求項３】
前記メタ情報管理部は、登録／更新／削除等の更新系処理の依頼を受理する装置構成情報管理装置が存在しなかった場合に、登録／更新／削除等の更新系処理の情報を一時保存する、請求項１または２に記載の仮想統合管理装置。
【請求項４】
新しい装置構成情報管理装置が前記仮想統合管理装置に登録された時、該装置構成管理装置に前記メタ情報管理部が一時保存した情報の更新系処理の依頼を行ない、当該装置構成情報管理装置が依頼を受理した場合は一時保存していた処理依頼を完了する更新系再処理部を備えた、請求項１乃至３の何れか１項に記載の仮想統合管理装置。
【請求項５】
前記更新系再処理部は、受理しなかった装置構成情報管理装置に対して再度処理依頼を行ない、当該装置構成情報管理装置が依頼を受理した場合は一時保存していた処理依頼を完了する、請求項１乃至４の何れか１項に記載の情報管理装置。
【請求項６】
複数の装置構成情報管理装置を管理する仮想統合管理装置から装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置のプログラムであって、
コンピュータに、
調和に使った情報が装置構成情報管理装置の何れにあるのかを示すメタ情報を記憶する第１手順と、
前記メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持つ装置構成情報管理装置を絞り込む第２手順と、
絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう第３手順と、を実行させるプログラム。
【請求項７】
複数の装置構成情報管理装置を管理する仮想統合管理装置から装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置のプログラムであって、
コンピュータに、
更新系処理の依頼である識別子の属性情報を記憶する第１手順と、
前記属性情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っている装置構成情報管理装置を絞り込む第２手順と、
絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう第３手順と、を実行させるプログラム。
【請求項８】
コンピュータに、
前記第２手順で絞込んだ結果、
該当する装置構成情報管理装置が有ると判定されたときは絞込んだ全装置構成情報管理装置に対して処理依頼を行なう第４手順と、
該当する装置構成情報管理装置が無いと判定され、かつ何れかの装置構成情報管理装置も処理依頼を受理していないと判定されたときは、処理依頼を前記仮想統合管理装置に保存する第５手順と、を実行させる請求項６または７に記載のプログラム。
【請求項９】
コンピュータに、
新しい装置構成情報管理装置が前記仮想統合管理装置に登録されたか否かを判定する第６手順と、
新しく登録された装置構成情報管理装置に対し前記仮想統合管理装置に保存した処理依頼を行なう第７手順と、を実行させる請求項８に記載のプログラム。
【請求項１０】
コンピュータに、
一定時間待ち、一定時間が経過したら絞込んだ全装置構成情報管理装置に対して前記仮想統合管理装置に保存した処理依頼を再度行なう第８手順と、を実行させる請求項８に記載のプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は調和（Reconciliation）機能を持つ仮想統合管理装置（FCMDB: Federated Configuration Management Database）において、ＦＣＭＤＢに対して情報の更新系処理、例えば登録／更新／削除が行なわれた際に、ＦＣＭＤＢの管理対象である装置構成情報管理装置（MDR: Management Data Repository）の各々に対して効率的に更新系処理の依頼を行なう仮想統合管理装置およびそのためのプログラムに関する。
【背景技術】
【０００２】
図１はＦＣＭＤＢの基本機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。ここで、ＦＣＭＤＢとは複数のＭＤＲに格納された異種のデータベースＤＢ（Database）を仮想統合する管理システムを意味し、ＭＤＲは管理するデータベースの記憶装置を意味する。ＦＣＭＤＢ１０は仮想統合している複数のＭＤＲ１１〜１６に格納されたデータベースＤＢに対して横断的に操作を行なうことが可能である。各ＭＤＲ１１〜１６が構成情報、インシデント情報、トラブル情報、リリース情報、変更情報またはアプリケーション情報等のリソースに関する情報（CI &  Relationship）と情報間の関連（Relationship）を管理し、ＦＣＭＤＢ１０が整合化された情報を管理する。ＦＣＭＤＢ１０は外部のコンピュータまたは自身の入力デバイスを介して検索要求を受け、複数のＭＤＲ１１〜１６から検索結果を導出し応答する。なお、以降の図において「アプリケーション」は「アプリ」と略記する。
【０００３】
図２はＦＣＭＤＢの調和機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。図２のＦＣＭＤＢ２０は図１のＦＣＭＤＢ１０と同一機能を有する。ＦＣＭＤＢ２０は仮想統合している複数のＭＤＲ２１〜２６に格納されたデータベースＤＢに対して横断的に操作を行なうことが可能であり、情報のリコンシリエーション機能 （調和を図る機能）を有する。ＦＣＭＤＢ２０による情報の調和機能には下記の２点がある。
第１点：データベースＤＢ毎に異なる名前（サーバ、ホスト、ノード）で管理されている同一の更新系処理の依頼（以下、アイテムと記す）アイテム２１Ａ〜２４Ａの情報を統合する。具体的には、名前を「サーバ」に統一する。
第２点：データベースＤＢ毎に異なるロ−カルＩＤ（Webserver1、192.168.10.1、hostnameX）で管理されている同一アイテム２１Ａ〜２４Ａの情報を統合する。具体的には、ＩＤを「Serial Number-XXX」に統一する。
【０００４】
特許文献１には、更新を一部の主コピーを有する主データベースでのみ行ない、同期時期になったら主コピー以外の他のコピーを有する従データベースへ主データベースから更新履歴を送信し、更新履歴に従って従コピーを主コピーと同じ内容に更新することにより分散データベースの更新時間の短縮を実現する技術が開示されている。しかしながら、特許文献１に記載の発明は、更新が行なわれる情報に関連する情報を持つＭＤＲ（データベース）に対して同期時期に更新履歴を送信し、同ＭＤＲが情報を更新するが、登録／更新／削除等の更新系の処理依頼そのものを送信するものではない。
【０００５】
【特許文献１】特開平６−１１９２２７号公報
【非特許文献２】http://cmdbf.org/schema/1-0-0/CMDBf%20v1.0.pdf
【発明の開示】
【発明が解決しようとする課題】
【０００６】
図３は従来技術の課題を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。従来のＦＣＭＤＢ３０は検索機能のみを提供するが、登録／更新／削除機能を提供しない。仮に、ＦＣＭＤＢ３０が仮想統合している全ＭＤＲ３１〜３３に対して登録／更新／削除等の更新系処理の依頼を個別にＭＤＲ３１〜３３に直接アクセスせずにＦＣＭＤＢ２０経由で行なう場合を想定すると、本来処理依頼を行なう必要のないＭＤＲ３２に対しても処理依頼を行ってしまう。換言すれば、処理依頼を受理する／行なうべきＭＤＲが存在しない場合に、処理依頼をどのＭＤＲ３１〜３３に対して行なえばよいのか分からないので本来処理依頼を行なう必要のないＭＤＲ３２に対して不要な処理依頼を行ってしまい、非効率的であるという問題がある。
【０００７】
図４は従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系を示す図である。上記従来技術の問題を解決するには、現存するＦＣＭＤＢ４０が登録／更新／削除等の更新系処理の依頼を受けた場合に、本来処理依頼を行なう必要のないＭＤＲ４２に対しあるいは処理依頼を受理するＭＤＲが存在しない場合に全てのＭＤＲ４〜４３に対し、不要な処理依頼を行なわないようすればよい。
【０００８】
それゆえ、本発明は、ＦＣＭＤＢによるＭＤＲの管理体系において、ＦＣＭＤＢ４０が登録／更新／削除等の更新系処理の依頼に対して、処理依頼を受理する／行なうべきＭＤＲが存在しない場合に対応できる、各ＭＤＲ４１〜４３に対し効率的に更新系処理を依頼できるようにする更新系処理の依頼を行う情報管理装置およびそのためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置には第１形態〜第５形態がある。
【００１０】
第１形態の情報管理装置は、管理している情報がどこから来たかを示すメタ情報を記憶しておき、該メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っているＭＤＲを絞り込み、絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう。
【００１１】
第２形態の情報管理装置は、更新系処理の依頼であるアイテムの属性情報を記憶しておき、該属性情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っているＭＤＲを絞り込み、絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう。
【００１２】
第３形態の情報管理装置は、どのＭＤＲも登録／更新／削除等の更新系処理の依頼を受理しなかった場合に、ＦＣＭＤＢに登録／更新／削除等の更新系処理の情報を一時保存しておく。
【００１３】
第４形態の情報管理装置は、新しいＭＤＲがＦＣＭＤＢに登録された時、当該ＭＤＲは処理依頼を受理する可能性があるので一時保存していた情報の更新系処理の依頼を行ない、当該ＭＤＲが依頼を受理した場合は一時保存していた処理依頼を完了し削除する。
【００１４】
第５形態の情報管理装置は、ＭＤＲ側の状況変化（アクセス設定の変更など）により、処理依頼を受理するように状況が変化したかも知れないので受理しなかったＭＤＲに対して再度、例えば定期的に処理依頼を行ない、当該ＭＤＲが依頼を受理した場合は一時保存していた処理依頼を完了し削除する。
【００１５】
第１形態に係る複数のＭＤＲを管理するＦＣＭＤＢからＭＤＲへ情報の更新系処理を行なう情報管理装置のプログラムは、
コンピュータに、
管理している情報がＭＤＲの何れから来たかを示すメタ情報を記憶する第１手順と、
前記メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持つ処理依頼を行なうＭＤＲを絞り込む第２手順と、
絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう第３手順と、を実行させる。
【００１６】
第２〜５形態に係る情報管理装置のプログラムは、上記第２〜５形態に係る情報管理装置の処理をコンピュータに実行させる。
【発明の効果】
【００１７】
第１形態および第２形態によれば、調和に使った管理している情報の出元を記憶しておくことにより、従来技術では実現されていなかった更新系処理を依頼するＭＤＲを不可欠かつ必要最小限に留めることができる。
【００１８】
第３〜５形態によれば、どのＭＤＲも処理依頼を受理しない場合や処理依頼を行なうＭＤＲが存在しない場合でも、適切なＭＤＲが現れた時に一時保存していた処理依頼を行なうことが可能となり、ＭＤＲが依頼を受理した場合はＦＣＭＤＢで管理している一時保存していた処理依頼を減らすことができる。
【発明を実施するための最良の形態】
【００１９】
図５はＦＣＭＤＢによるＭＤＲの管理体系における実施形態に係る情報管理装置のブロック構成図である。図５に示す本実施形態に係る情報管理装置５１０はＦＣＭＤＢ５０内に組み込まれている。しかし、他の実施形態では情報管理装置５１０はＦＣＭＤＢ５０に通信可能に接続しＦＣＭＤＢ５０の外部に設置してもよい。本実施形態の情報管理装置５１０はＦＣＭＤＢ５０と同様、少なくとも不図示のＣＰＵ、主記憶（メモリ）、補助記憶（磁気ディスク）を備えたコンピュータ装置である。以下に記す情報は補助記憶に格納され、処理は主記憶に書込まれるプログラムにより実行される。
【００２０】
図５に示すように、ＦＣＭＤＢ５０は従来の要求受付部５０１と検索処理部５０２と回答通知部５０３の他に情報管理装置５１０に設けられたメタ情報管理部５１１と更新系処理部５１２と更新系再処理部５１３とを有する。
【００２１】
要求受付部５０１は検索／登録／更新／削除の依頼の要求を受け付ける。
検索処理部５０２は要求受付部５０１から検索依頼の要求を受け、ＭＤＲ５１、ＭＤＲ５２、…、ＭＤＲ５Ｎに同要求を送信し、検索結果を受信し、受信した検索結果を回答通知部５０３に送る。検索処理部５０２は検索先が見つかれば検索先の通知を、見つからなければ検索先無しの通知を、検索結果として回答通知部５０３に送る。
回答通知部５０３は検索／登録／更新／削除の依頼の要求元に依頼に対する処理結果を通知することで応答する。
【００２２】
メタ情報管理部５１１はメタ情報を管理する。メタ情報は下記の３つの情報を含む。（１）CI／Relationshipメタ情報：管理している情報がどのＭＤＲから来たかを示す元情報を含むメタ情報であり、CI情報とRelationship情報とを含み、CI（Configuration Item）情報は管理している更新系処理の依頼であるアイテムを示す。Relationship情報はアイテム間の関係付けを示し各アイテムがどのＭＤＲのＤＢに格納されているかを示す。
【００２３】
（２）Propertyメタ情報：アイテムの属性についての情報であり、アイテムのPropertyの名前とそのアイテムがどのＭＤＲから来たかを示す元情報とを含み、Propertyの名前はアイテムのハードウェア、ソフトウェア等の属性を示し、元情報はPropertyの名前に対応する属性情報がどのＭＤＲのＤＢに格納されているかを示す。
【００２４】
（３）未処理情報：更新系処理の依頼が未完了であることを示す情報であり、依頼ＩＤ、CI／RelationshipＩＤ、種別、PropertyおよびValueの情報を含む。ここで、依頼ＩＤは、未完了の更新系処理の依頼を識別するための情報であり、例えば依頼の名前がこの情報である。CI／RelationshipＩＤは、CI／Relationship情報を識別するための情報である。種別は、更新系処理の依頼が登録／更新／削除の何れであるかを示す情報である。Propertyは、未完了の更新系処理の依頼のアイテムに関連付けられたアイテムのハードウェア、ソフトウェア等の属性を示す情報である。Valueは、Propertyのデータである。
【００２５】
更新系処理部５１２は登録／更新／削除等の更新系処理をメタ情報管理部５１１の持つ情報を参照して行なう。
更新系再処理部５１３は更新系処理部５１２で未処理となった更新系処理をメタ情報管理部５１１の持つ情報を参照して新しいＭＤＲに対し、または先に処理依頼が受理されなかったＭＤＲに対し再度定期的に更新系処理を行なう。この処理は再度行なえば定期的に行なわなくてもよい。
以下の説明において、情報管理装置５１０はＦＣＭＤＢ５０に含められるのでＦＣＭＤＢ５０と記す。
【００２６】
図６はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第１実施形態を示す図である。ＦＣＭＤＢ５０はCI及びRelationshipメタ情報を使ってＭＤＲを絞込む。
【００２７】
図６に示す第１実施形態では、ＦＣＭＤＢ５０はCI／Relationshipメタ情報のテーブル５００とPropertyメタ情報のテーブル５０１〜５０６を格納している。CI／Relationshipメタ情報は、ＦＣＭＤＢに既に登録されているCI／Relationshipの識別子と元情報との対応を管理している。テーブル５００にはCI／Relationshipの識別子であるアイテムＧＩＤ１およびＧＩＤ２に関する情報が登録され、元情報の欄にはアイテムＧＩＤ１に対応してアイテムＧＩＤ１に関連する情報は、ＤＢ１のＬＩＤ１１に、ＤＢ２のＬＩＤ２１、ＤＢ３のＬＩＤ３１およびＤＢ４のＬＩＤ４１に在ることが示されている。アイテムＧＩＤ２に対しても同様であるので説明は省略する。ここで、ＬＩＤ１１、ＬＩＤ２１、ＬＩＤ３１、ＬＩＤ４１は更新系の処理が行なわれる情報である。
【００２８】
アイテムＧＩＤ１は更新依頼された情報であり、更新前と更新後のアイテムＧＩＤ１を比較しても判るように、テーブル５００から関連情報Ｍｅｍｏｒｙ、ＣＰＵ、Ａｐｐ（Application）およびＥＲＲＯＲがそれぞれＬＩＤ１１、ＬＩＤ２１、ＬＩＤ３１およびＬＩＤ４１に在ることが判る。ＬＩＤ１１、ＬＩＤ２１、ＬＩＤ３１およびＬＩＤ４１はそれぞれＤＢ１のＭＤＲ５１、ＤＢ２のＭＤＲ５２、ＤＢ３のＭＤＲ５３およびＤＢ４のＭＤＲ５４に格納されているので、ＦＣＭＤＢ５０はこれらのＭＤＲ５１〜５４の４つの候補に絞り込んで更新依頼を行なう。
【００２９】
ＤＢ１のＬＩＤ１１でＣＰＵの情報が、ＤＢ２のＬＩＤ２１でＭｅｍｏｒｙの情報が、ＤＢ３のＬＩＤ３１でＥＲＲＯＲの情報が、ＤＢ４のＬＩＤ４１でＡｐｐの情報が、それぞれ更新される。
【００３０】
図７はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第２実施形態を示す図である。ＦＣＭＤＢ５０においてメタ情報管理部５１１はPropertyメタ情報を管理する。更新系処理部５１２はPropertyメタ情報を使ってＭＤＲを絞込む。
【００３１】
図７に示す第２実施形態では、Propertyメタ情報のテーブル５０１にはアイテムのPropertyの名前の欄にはＩＤ、ＨＤＤ、Ｍｅｍｏｒｙ、ＣＰＵ、ＡｐｐおよびＥＲＲＯＲが示され、元情報の欄にはPropertyの名前ＩＤ、ＨＤＤ、Ｍｅｍｏｒｙ、ＣＰＵ、ＡｐｐおよびＥＲＲＯＲに対応して関連する情報がそれぞれどのＭＤＲのＤＢに格納されているかが示されている。例えば、ＩＤに関連する情報がＭＤＲ（ＤＢ）１のＬＩＤ１１とＭＤＲ（ＤＢ）３のＬＩＤ３１に格納されていることが示されている。
【００３２】
アイテムＧＩＤ１は更新依頼された情報であり、更新前と更新後のアイテムＧＩＤ１を比較しても判るように、テーブル５０１からPropertyの名前がＣＰＵ、ＡｐｐおよびＥＲＲＯＲがアイテムＧＩＤ１において更新された情報であることが判る。したがって、ＦＣＭＤＢ５０はＣＰＵ、ＡｐｐおよびＥＲＲＯＲに対応する元情報からＭＤＲ（ＤＢ）１、ＭＤＲ（ＤＢ）２およびＭＤＲ（ＤＢ）４の３つの候補に絞り込んで更新依頼を行なう。
【００３３】
図８はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第３実施形態を示す図である。
【００３４】
図８に示す第３実施形態では、メタ情報管理部５１１が、関連する情報を持つＭＤＲに登録／更新／削除依頼を行ない、どのＭＤＲでも登録／更新／削除依頼が受理されなかった未処理部分を管理する。登録／更新／削除依頼の未処理部分の情報（以下、未処理情報と記す）をテーブル８００に格納する。
【００３５】
未処理情報を格納するテーブル８００は、依頼ＩＤ、CI／RelationshipＩＤ、種別、PropertyおよびValueの欄を有する。依頼ＩＤの欄には未処理情報の名前ＵＤ−０００１、ＵＤ−００１２、ＵＤ−００１３が格納されている。CI／RelationshipＩＤの欄には未処理情報の名前に対応するアイテムＧＩＤ１、ＧＩＤ−１１１、ＧＩＤ−１１２が格納されている。種別の欄には登録／更新／削除が格納されている。Propertyの欄には図示のPropertyの名前ＩＤ、ＩＰＡｄｄｒ、ＵＳＥ、Ｎａｍｅが格納されている。Valueの欄にはPropertyの名前に対応するProperty（属性）値が格納されている。例えば、Propertyの名前ＳＮに対応してその属性値SerialNumber-XXXが格納されている。
【００３６】
ＦＣＭＤＢ５０は、アイテムＧＩＤ１の更新での未処理情報、ＣＰＵ、ＡＰＰ、ＥＲＲＯＲを持つアイテムＧＩＤ１を依頼ＩＤ、種別、Property、Valueと共にテーブル８００に格納する。
【００３７】
図９はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第４実施形態を示す図である。
【００３８】
図９に示す第４実施形態では、更新系再処理部５１３は、メタ情報管理部５１１を参照して、新しいＭＤＲ５がＦＣＭＤＢに登録された時には、更新系処理部５１２がそのＭＤＲ５に対してテーブル９００に格納された完了していない登録／更新／削除の依頼を行なう。また、更新系再処理部５１３は、未処理部分がなくなった登録／更新／削除の依頼に対して、すなわち依頼が受理された場合は、テーブル９００からその依頼を削除する。図９に示す例では、依頼ＩＤがＵＤ−０００１に対し、完了していない更新の依頼を行ない、ＧＩＤ１に関連する更新依頼が受理されたのでテーブル９００からＵＤ−０００１の関連情報を削除する。
【００３９】
図１０はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第５実施形態を示す図である。
【００４０】
図１０に示す第５実施形態では、更新系再処理部５１３は、メタ情報管理部５１１を参照して、定期的に関連する情報を持つＭＤＲに登録／更新／削除依頼を行ない、どのＭＤＲでも登録／更新／削除の依頼が受理されなかった未処理部分を管理する。更新系処理部５１２が再度定期的に関連する情報を持つＭＤＲに登録／更新／削除依頼を行なう。この処理は再度行なえば定期的に行なわなくてもよい。また、更新系再処理部５１３は、未処理部分がなくなった登録／更新／削除依頼をテーブル１０００から削除する。
【００４１】
図１０に示す例では、依頼ＩＤがＵＤ−０００１に対し、完了していない更新の依頼再度を行ない、ＧＩＤ１に関連する更新依頼が受理されたのでテーブル９００からＵＤ−０００１の関連情報を削除する。
【００４２】
図１１は実施形態に係る情報管理装置による処理のフローチャートである。以下に、上述した第１実施形態〜第５実施形態に係る情報管理装置による処理を説明する。
第１実施形態では、ステップＳ１でCI／Relationshipメタ情報を使って処理依頼を行なうＭＤＲを絞込む。
【００４３】
第２実施形態では、ステップＳ２でPropertyメタ情報を使って処理依頼を行なうＭＤＲを絞込む。
【００４４】
第３実施形態では、以下の処理を実行する。
ステップＳ１１で絞込んだ結果、該当するＭＤＲが有るか否かをチェックし、ＹＥＳのときはステップＳ１２に進み、ＮＯのときはステップＳ１４に進む。
ステップＳ１２で絞込んだ全ＭＤＲに対して処理依頼を行ない、ステップＳ１３に進む。
ステップＳ１３で何れかのＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ１４に進む。
ステップＳ１４で処理依頼をＦＣＭＤＢに保存する。
【００４５】
第４実施形態では、以下の処理を実行する。
ステップＳ２１で新しいＭＤＲがＦＣＭＤＢに登録されたか否かをチェックし、ＹＥＳのときはステップＳ２２に進み、ＮＯのときはステップＳ２３に進む。
ステップＳ２２で新しく登録されたＭＤＲに保存してある処理依頼を行なう。
ステップＳ２３で新しいＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ２１に戻る。ステップＳ２３でＹＥＳのとき、保存した処理依頼を削除してから本処理を終了する。
【００４６】
第５実施形態では、以下の処理を実行する。
ステップＳ３１で一定時間待ち、一定時間が経過したらステップＳ３２に進む。
ステップＳ３２で絞込んだ全ＭＤＲに対して処理依頼を行なう。
ステップＳ３３で何れかのＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ３１に戻る。ステップＳ３３でＹＥＳのとき、保存した処理依頼を削除してから本処理を終了する。
【図面の簡単な説明】
【００４７】
【図１】ＦＣＭＤＢの基本機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術）
【図２】ＦＣＭＤＢの調和機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術）
【図３】従来技術の課題を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術）
【図４】従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系を示す図である。
【図５】ＦＣＭＤＢによるＭＤＲの管理体系における実施形態に係る情報管理装置のブロック構成図である。
【図６】ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第１実施形態を示す図である。
【図７】ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第２実施形態を示す図である。
【図８】ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第３実施形態を示す図である。
【図９】ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第４実施形態を示す図である。
【図１０】ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第５実施形態を示す図である。
【図１１】実施形態に係る情報管理装置による処理のフローチャートである。
【符号の説明】
【００４８】
５０    ＦＣＭＤＢ
５１、５２、５３、５４、５５、…、５Ｎ    ＭＤＲ
５００    CI／Relationshipメタ情報
５０１〜５０６    Propertyメタ情報
５１０    情報管理装置
５１１    メタ情報管理部
５１２    更新系処理部
５１３    更新系再処理部
８００、９００、１０００    未処理情報テーブル
【国際調査報告】
2009122527.tif 000014
2009122527.tif 000015
2009122527.tif 000016
2009122527.tif 000017