JP5177223B2 - 情報処理装置、情報処理プログラム及び方法 - Google Patents

Description

本発明は、システムを構成するリソースに関する属性情報を管理する情報処理装置、情報処理プログラム及び方法に関するものである。

情報システムを構成するハードウェア及びソフトウェアに関する情報を管理する異なる種類のデータベースを仮想統合することにより、情報システムのコンポーネントに関する全ての情報を管理するデータベースとして、ＣＭＤＢ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｄａｔａｂａｓｅ）が知られている。図２５に示すように、ＣＭＤＢは仮想統合している複数のデータベースである構成情報ＤＢ、インシデント情報ＤＢ、トラブル情報ＤＢ、リリース情報ＤＢ、変更情報ＤＢ、アプリ情報ＤＢに対して、横断的に操作を行うことを可能にするものである。これらの統合されている複数のデータベースのそれぞれは、システムを構成するリソース（機器、ソフトウェアなど）に関する属性情報であるＣＩ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｉｔｅｍ）と情報間の関連（Ｒｅｌａｔｉｏｎｓｈｉｐ）を管理するものである。

また、図２６に示すように、ＣＭＤＢは仮想統合しているデータベース毎に異なる名前、異なるローカルＩＤで管理されている同一アイテムの情報に対して、名前を統一し、仮想統合している全てのデータベースで共通に使えるユニークなＩＤで管理することにより情報の調停を行うリコンシエーション機能を有するものである。

また、ＣＩ同士の関連を示す情報であるＲｅｌａｔｉｏｎｓｈｉｐは、図２７に示すように、ＣＩ間におけるＲｅｌａｔｉｏｎｓｈｉｐの方向を示すためのｓｏｕｒｃｅ及びｔａｒｇｅｔを含む属性情報を保持するものである。

このようなＣＭＤＢにおいて、システムを構成するリソースの設定を更新する際に、更新による影響が波及する範囲を調査する影響調査が事前に行われる。この影響調査は、ＣＭＤＢで管理されている情報を検索しながら、更新予定のリソースと関連しているリソースを調査する処理である。この処理は、更新されるＣＩと関係付けられているＣＩは、更新による影響を受けるという想定の元になされる処理であり、ＣＩからＲｅｌａｔｉｏｎｓｈｉｐを辿ることで影響範囲を調査する処理である。

また、本発明の関連ある従来技術として、ネットワーク上に構成された業務システムにおいて発生したシステム障害に対して、業務影響を特定する障害影響範囲解析システム及び障害影響範囲解析方法及びプログラムが知られている（例えば、特許文献１参照）。
特開２００５−２５８５０１号公報

しかしながら、従来のＣＭＤＢにおける影響調査には、精度及び効率が悪いという問題がある。これらの問題は、上述したように更新されるＣＩと関係付けられているＣＩは変更による影響を受けるという前提の元になされる処理であることによるものである。

影響調査の精度が悪いという問題は、ＣＭＤＢが更新により影響を受けないはずのＣＩをも影響を受けると見做してしまうことにより生じる問題である。また、影響調査の効率が悪いという問題は、ＣＭＤＢがＲｅｌａｔｉｏｎｓｈｉｐで関係付けられたＣＩを全て計算することにより、更新により影響を受けないＣＩまで計算してしまい、結果として影響調査に関する計算量が多くなることにより生じる問題である。

本発明は上述した問題点を解決するためになされたものであり、システムを構成するリソースの更新による不整合が生じる可能性のある範囲を高精度且つ効率的に知ることができる情報処理装置、情報処理プログラム及び方法を提供することを目的とする。

上述した課題を解決するため、情報処理装置は、システムを構成するリソースに関する情報であるリソース情報を管理する装置であって、所定のリソース情報と他のリソース情報間に所定の条件である第１条件を設定する第１条件設定部と、前記第１条件設定部により設定された第１条件より、前記リソース情報に対する変更点を示す情報である変更点情報が基づくリソース情報に設定された第１条件を抽出する第１条件抽出部と、前記第１条件抽出部により抽出された第１条件が前記変更点情報により充足されるどうかを判定する第１条件判定部とを備える。

また、情報処理プログラムは、システムを構成するリソースに関する情報であるリソース情報を管理することができるプログラムであって、所定のリソース情報と他のリソース情報間に所定の条件である第１条件を設定する第１条件設定ステップと、前記第１条件設定ステップにより設定された第１条件より、前記リソース情報に対する変更点を示す情報である変更点情報が基づくリソース情報に設定された第１条件を抽出する第１条件抽出ステップと、前記第１条件抽出ステップにより抽出された第１条件が前記変更点情報により充足されるどうかを判定する第１条件判定ステップとをコンピュータに実行させる。

また、情報処理方法は、システムを構成するリソースに関する情報であるリソース情報を管理するための方法であって、所定のリソース情報と他のリソース情報間に所定の条件である第１条件を設定する第１条件設定ステップと、前記第１条件設定ステップにより設定された第１条件より、前記リソース情報に対する変更点を示す情報である変更点情報が基づくリソース情報に設定された第１条件を抽出する第１条件抽出ステップと、前記第１条件抽出ステップにより抽出された第１条件が前記変更点情報により充足されるどうかを判定する第１条件判定ステップとを備える。

本実施の形態に係るＣＭＤＢの構成を示すブロック図である。 仮説情報を示す図である。 制約条件情報を示す図である。 調査使用情報を示す図である。 操作実行部の動作を示すフローチャートである。 仮説管理部の動作を示すフローチャートである。 仮説“同時に変更”の作成例を示す図である。 仮説作成処理の動作を示すフローチャートである。 仮説作成処理の動作を示すフローチャートである。 仮説の作成例を示す図である。 仮説の作成例を示す図である。 仮説の作成例を示す図である。 仮説の作成例を示す図である。 仮説の作成例を示す図である。 影響調査実行部の動作を示すフローチャートである。 影響調査実行部の動作を示すフローチャートである。 制約評価処理の動作を示すフローチャートである。 変更後情報と充足不能な制約条件を持った属性に関する制約条件を示す図である。 仮説評価処理の動作を示すフローチャートである。 変更後情報と充足不能な制約条件または仮説を持った属性に関する仮説を示す図である。 検証部の動作を示すフローチャートである。 制約条件検証処理の動作を示すフローチャートである。 仮説検証処理の動作を示すフローチャートである。 制約条件管理部の動作を示すフローチャートである。 従来のＣＭＤＢの構成を示すブロック図である。 従来のリコンシリエーション機能を示す図である。 従来のＲｅｌａｔｉｏｎｓｈｉｐを示す図である。

本発明は、ＣＩ間、ＣＩ／Ｒｅｌａｔｉｏｎｓｈｉｐ間、Ｒｅｌａｔｉｏｎｓｈｉｐ間に依存関係（更新されることによって影響を及ぼす関係）がある場合、依存関係を制約条件としてＣＩ及びＲｅｌａｔｉｏｎｓｈｉｐに設定するものである。また、本発明は、更新されるリソースにより充足不能となる制約条件を辿ることによって、到達可能なＣＩ及びＲｅｌａｔｉｏｎｓｈｉｐを見つけるものである。また、本発明は、仮の制約条件としての仮説をＣＩ及びＲｅｌａｔｉｏｎｓｈｉｐに設定するものである。以下、本発明の実施の形態について図面を参照しつつ説明する。

まず、本実施の形態に係るＣＭＤＢ（情報処理装置）の構成について説明する。図１は、本実施の形態に係るＣＭＤＢの構成を示すブロック図である。また、図２は、仮説情報を示す図である。また、図３は、制約条件情報を示す図である。また、図４は、調査使用情報を示す図である。

図１に示すように、本実施の形態に係るＣＭＤＢ１０は、操作実行部１０１、データ管理部１０２、ＣＭＤＢ情報ＤＢ１０３、仮説管理部１０４（第２条件設定部）、影響調査実行部１０５（第１条件抽出部、第２条件抽出部、第１条件判定部、第２条件判定部）、検証部１０６（加算部、第１減算部、第２減算部、第１条件変更部、第２条件変更部、削除部）、制約条件管理部１０７（第１条件設定部）、仮説情報ＤＢ１０８、調査使用情報ＤＢ１０９、制約条件情報ＤＢ１１０を備える。このＣＭＤＢ１０は、接続されたクライアント端末２０の要求を受け、システムを構成するリソースに関する情報（リソース情報）を応答として返すものである。

ＣＭＤＢ１０の操作実行部１０１は、クライアント端末２０からの要求を受け付け、仮説管理部１０４、影響調査実行部１０５、検証部１０６、制約条件管理部１０７に対して要求に応じた処理を依頼するものである。また、データ管理部１０２は、ＣＭＤＢ情報ＤＢ１０３を管理するものである。また、ＣＭＤＢ情報ＤＢ１０３は、ＣＩ及びＲｅｌａｔｉｏｎｓｈｉｐを格納するものである。また、仮説管理部１０４は、仮説情報ＤＢ１０８を管理するものである。また、影響調査実行部１０５は、システムを構成するリソースのＣＩが更新されることによって充足不能となる制約条件及び仮説を調査使用情報ＤＢ１０９に登録するものである。また、検証部１０６は、仮説及び制約条件の信頼度の増減（信頼度については後述する）を行い、この信頼度により仮説の制約条件への格上げ、制約条件の仮説への格下げを行うものである。また、制約条件管理部１０７は、制約条件情報ＤＢ１１０を管理するものである。

また、仮説情報ＤＢ１０８は、仮説情報を格納するものである。この仮説情報は、図２に示すように、特定の仮説を示すＩＤである“仮説ＩＤ”、仮説の条件式を示す“仮説条件式（第２条件）”、仮説に関連するＥｎｔｉｔｙ（ＣＩ及びＲｅｌａｔｉｏｎｓｈｉｐの総称）である“関連するＥｎｔｉｔｙ”、仮説がどの程度信頼できるかを示す値である“信頼度”が対応付けられたものである。

また、制約条件情報ＤＢ１０９は、制約条件情報を格納するものである。この制約条件情報は、図３に示すように、特定の制約条件を示すＩＤである“制約条件ＩＤ”、制約条件の条件式を示す“制約条件式（第１条件）”、制約条件に関連するＥｎｔｉｔｙである“関連するＥｎｔｉｔｙ”、制約条件がどの程度信頼できるかを示す値である“信頼度”が対応付けられたものである。

また、調査使用情報ＤＢ１０９は、調査使用情報を格納するものである。この調査使用情報は、図４に示すように、影響調査依頼に対して生成されるＩＤである“調査ＩＤ”、影響調査において充足不能な制約条件ＩＤを示す“充足不能制約条件”、影響調査において充足不能な仮説ＩＤを示す“充足不能仮説”が対応付けられたものである。

次に、本実施の形態に係るＣＭＤＢの動作について説明する。まず、ＣＭＤＢの動作のうち、操作実行部の動作について説明する。図５は、操作実行部の動作を示すフローチャートである。なお、図５においては、すでにクライアント端末より処理が要求されているものとする。

まず、操作実行部１０１は、クライアント端末２０による要求が検索依頼かどうかを判断する（Ｓ１０１）。

クライアント端末２０による要求が検索依頼ではない場合（Ｓ１０１，ＮＯ）、操作実行部１０１は、クライアント端末２０による要求が変更依頼かどうかを判断する（Ｓ１０２）。

クライアント端末２０による要求が変更依頼ではない場合（Ｓ１０２，ＮＯ）、操作実行部１０１は、クライアント端末２０による要求が影響調査依頼かどうかを判断する（Ｓ１０３）。

クライアント端末２０による要求が影響調査依頼ではない場合（Ｓ１０３，ＮＯ）、操作実行部１０１は、クライアント端末２０による要求が削除依頼かどうかを判断する（Ｓ１０４）。

クライアント端末２０による要求が削除依頼である場合（Ｓ１０４，ＹＥＳ）、操作実行部１０１は、データ管理部１０２を介して、削除依頼と共に指定されたリソースに関する情報をＣＭＤＢ情報ＤＢ１０３から削除する（Ｓ１０５）。さらに、操作実行部１０１は、仮説管理部１０４に対して仮説削除依頼をすると共に、制約条件管理部１０７に対して制約削除依頼をする（Ｓ１０６）。

一方、クライアント端末２０による要求が削除依頼ではない場合（Ｓ１０４，ＮＯ）、操作実行部１０１は、要求を登録依頼とみなし、登録依頼と共に指定されたリソースに関する情報をデータ管理部１０２を介して、ＣＭＤＢ情報ＤＢ１０３に登録する（Ｓ１０７）。さらに、操作実行部１０１は、仮説管理部１０４に対して仮説生成依頼をする（Ｓ１０８）。

また、ステップＳ１０３の判断において、クライアント端末２０による要求が影響調査依頼である場合（Ｓ１０３，ＹＥＳ）、操作実行部１０１は、影響調査実行部１０５に対して影響調査依頼をする（Ｓ１０９）。

また、ステップＳ１０２の判断において、クライアント端末２０による要求が変更依頼である場合（Ｓ１０２，ＹＥＳ）、操作実行部１０１は、データ管理部１０２を介してＣＭＤＢ情報ＤＢ１０３におけるＥｎｔｉｔｙを変更する（Ｓ１１０）。さらに、操作実行部１０１は、検証部１０６に対して検証依頼をし（Ｓ１１１）、仮説管理部１０４に対して仮説生成依頼をする（Ｓ１０８）。

また、ステップＳ１０１の判断において、クライアント端末２０による要求が検索依頼である場合（Ｓ１０１，ＹＥＳ）、操作実行部１０１は、検索依頼と共に指定されたリソースに関する情報に基づいて、データ管理部１０２を介してＣＭＤＢ情報ＤＢを検索する（Ｓ１１２）。

上述したように、操作実行部１０１は、クライアント端末２０からの要求に基づいて、仮説管理部１０４、影響調査実行部１０５、検証部１０６、制約条件管理部１０７に対して処理を依頼する。

次に、仮説管理部の動作について説明する。図６は、仮説管理部の動作を示すフローチャートである。また、図７は、仮説“同時に変更”の作成例を示す図である。なお、図６において、仮説管理部は操作実行部より仮説作成依頼または仮説削除依頼を受けているものとする。

図６に示すように、まず、仮説管理部１０４は、クライアント端末２０による要求が登録依頼であるかどうかを判断する（Ｓ２０１）。

クライアント端末２０による要求が登録依頼ではない場合（Ｓ２０１，ＮＯ）、仮説管理部１０４は、クライアント端末２０による要求が削除依頼であるかどうか、つまり、操作実行部１０１から仮説削除依頼をされたかどうかを判断する（Ｓ２０２）。

クライアント端末２０による要求が削除依頼ではない場合（Ｓ２０２，ＮＯ）、仮説管理部１０４は、クライアント端末２０による要求が変更依頼であるかどうか、つまり、操作実行部１０１から仮説作成依頼をされたかどうかを判断する（Ｓ２０３）。

クライアント端末２０による要求が変更依頼である場合（Ｓ２０３，ＹＥＳ）、仮説管理部１０４は、変更されたリソースに関する情報を調べ、同時に変更されているＥｎｔｉｔｙについて、仮説“同時に変更”を作成し（Ｓ２０４、第２条件設定ステップ）、仮説情報ＤＢ１０８に登録し（Ｓ２０５）、後述する仮説作成処理を実行する（Ｓ２０６）。

ここで、図７を用いて、仮説“同時に変更”の作成について説明する。図７に示すように、ＨＤＤ容量がＨＤＤ１１及びＨＤＤ１２に基づく計算機１というＣＩが存在し、ＨＤＤ１１の容量が５００ＧＢから３００ＧＢに変更されたとする。この時、計算機１のＨＤＤ容量も８００ＧＢから６００ＧＢに変更される場合、仮説管理部１０４は、計算機１とＨＤＤ１１に関して、仮説“同時に変更”を作成する。

また、図６に示すように、ステップＳ２０３の判断において、クライアント端末２０による要求が変更依頼ではない場合（Ｓ２０３）、仮説管理部１０４は、仮説作成処理を実行する（Ｓ２０６）。

また、ステップＳ２０２の判断において、クライアント端末２０による要求が削除依頼である場合（Ｓ２０２，ＹＥＳ）、仮説管理部１０４は、仮説情報を調べ、“関連するＥｎｔｉｔｙ”が全て存在していない仮説を仮説情報から削除する（Ｓ２０７）。さらに仮説管理部１０４は、制約条件情報を調べ、“関連するＥｎｔｉｔｙ”が全て存在していない制約条件を制約条件情報から削除する（Ｓ２０８）。

また、ステップＳ２０１の判断において、クライアント端末２０による要求が登録依頼である場合（Ｓ２０１，ＹＥＳ）、仮説管理部１０４は、仮説作成処理を実行する（Ｓ２０６）。

次に、仮説管理部の仮説作成処理について説明する。図８及び図９は、仮説作成処理の動作を示すフローチャートである。なお、この仮説作成処理は、図６のフローチャートにおけるステップＳ２０６に対応する処理である。また、図１０〜図１３は、仮説の作成例を示す図である。

図８に示すように、まず、仮説管理部１０４は、マージされ、ＣＭＤＢ情報ＤＢ１０３に登録される前の情報（マージされる前の登録情報または変更情報。以降“変更情報”とする。）により、登録または変更されたＥｎｔｉｔｙ集合＜Ｅ＞を求め（Ｓ３０１）、Ｅが空かどうかを判断する（Ｓ３０２）。

Ｅが空ではない場合（Ｓ３０２，ＹＥＳ）、仮説管理部１０４は、Ｅから個別のＥｎｔｉｔｙ＜ｅ＞を取り出し（Ｓ３０３）、ｅをｓｏｕｒｃｅとするＲｅｌａｔｉｏｎｓｈｉｐ集合＜Ｓ＞を求め（Ｓ３０４）、Ｓが空かどうかを判断する（Ｓ３０５）。

Ｓが空ではない場合（Ｓ３０５，ＮＯ）、仮説管理部１０４は、Ｓに含まれるＲｅｌａｔｉｏｎｓｈｉｐのＴａｒｇｅｔ集合＜Ｔ＞を求め（Ｓ３０６）、ｅのある属性値がＴに含まれるＥｎｔｉｔｙのある属性値の総和になっているかどうかを判断する（Ｓ３０７）。

ｅのある属性値がＴに含まれるＥｎｔｉｔｙのある属性値の総和になっていない場合（Ｓ３０７，ＮＯ）、仮説管理部１０４は、図９に示すように、Ｓから個別のＲｅｌａｔｉｏｎｓｈｉｐ＜ｓ＞を取り出し（Ｓ３０８）、ｅとｓのｔａｒｇｅｔが似た属性名を持っているかどうかを部分一致により判断する（Ｓ３０９）。

ｅとｓのｔａｒｇｅｔが似た属性名を持っていない場合（Ｓ３０９，ＮＯ）、仮説管理部１０４は、ｅのＥｎｔｉｔｙ名と似た属性名をｓのｔａｒｇｅｔが持っているかどうかを部分一致により判断する（Ｓ３１０）。

ｅのＥｎｔｉｔｙ名と似た属性名をｓのｔａｒｇｅｔが持っていない場合（Ｓ３１０，ＮＯ）、仮説管理部１０４は、ｓのｔａｒｇｅｔのＥｎｔｉｔｙ名と似た属性名をｅが持っているかどうかを部分一致により判断する（Ｓ３１１）。

ｓのｔａｒｇｅｔのＥｎｔｉｔｙ名と似た属性名をｅが持っていない場合（Ｓ３１１，ＮＯ）、仮説管理部１０４は、図８に示すように、Ｓが空かどうかを判断する（Ｓ３０５）。

一方、図１０に示すように、ｓのｔａｒｇｅｔのＥｎｔｉｔｙ名と似た属性名をｅが持っている場合（Ｓ３１１，ＹＥＳ，第２条件設定ステップ）、仮説管理部１０４は、これらのＥｎｔｉｔｙ間の関係（例えば“ＨＤＤ＠計算機１＞容量＠ＨＤＤ１１”のような両Ｅｎｔｉｔｙにおける値の相等関係）を条件式として仮説を作成し（Ｓ３１２，第２条件設定ステップ）、図８に示すように、Ｓが空かどうかを判断する（Ｓ３０５）。

また、ステップＳ３１０の判断において、図１１に示すように、ｅのＥｎｔｉｔｙ名と似た属性名をｓのｔａｒｇｅｔが持っている場合（Ｓ３１０，ＹＥＳ，第２条件設定ステップ）、仮説管理部１０４は、これらのＥｎｔｉｔｙ間の関係を条件式として仮説を作成し（Ｓ３１２，第２条件設定ステップ）、図８に示すように、Ｓが空かどうかを判断する（Ｓ３０５）。

また、ステップＳ３０９の判断において、図１２に示すように、ｅとｓのｔａｒｇｅｔが似た属性名を持っている場合（Ｓ３０９，ＹＥＳ，第２条件設定ステップ）、仮説管理部１０４は、これらのＥｎｔｉｔｙ間の関係を条件式として仮説を作成し（Ｓ３１２，第２条件設定ステップ）、図８に示すように、Ｓが空かどうかを判断する（Ｓ３０２）。

また、ステップＳ３０７の判断において、図１３に示すように、ｅのある属性値がＴに含まれるＥｎｔｉｔｙのある属性値の総和になっている場合（Ｓ３０７，ＹＥＳ）、仮説管理部１０４は、これらのＥｎｔｉｔｙ間の関係（例えば、“容量＠ＨＤＤ１１＋容量＠ＨＤＤ１２＝ＨＤＤ＠計算機１”）を条件式として仮説を作成し（Ｓ３１２）、図８に示すように、Ｓが空かどうかを判断する（Ｓ３０２）。

また、仮説管理部１０４は、すでに仮説または制約条件が設定され、似た構成を持つＥｎｔｉｔｙと同様の仮説を作成しても良い。具体的には、図１４に示すように、Ｅｎｔｉｔｙの名前、ｔａｒｇｅｔの名前が部分的に一致し、Ｒｅｌａｔｉｏｎｓｈｉｐが一致している場合に、仮説管理部１０４は、これらの構成が似ていると判断する。

上述したように、Ｅｎｔｉｔｙ間の関係をトリガーとし、これらの関係を条件式とすることにより、仮説を自動的に作成することができる。また、仮説作成処理における名前が一致するか否かの判断は、どのような方法によりなされても良い。

次に、影響調査実行部の動作について説明する。図１５及び図１６は、影響調査実行部の動作を示すフローチャートである。なお、図１５及び図１６において、仮説管理部は操作実行部より影響調査依頼を受けているものとする。影響調査により、影響調査実行部は、充足不能となる仮説及び制約条件を調べる。

まず、影響調査依頼を受けた影響調査実行部１０５は、調査ＩＤを生成し（Ｓ４０１）、調査候補の情報（仮説及び制約）集合＜Ｉ＞に変更後情報（変更点情報）＜ｄ＞を加え（Ｓ４０２）、Ｉが空かどうかを判断する（Ｓ４０３）。なお、変更後情報は、影響調査依頼に付加された情報であり、ＣＩに対する変更点（具体的には変更後の属性情報）を示す情報である。

Ｉが空ではない場合（Ｓ４０３，ＮＯ）、影響調査実行部１０５は、Ｉから個別の情報＜ｉ＞を取り出し（Ｓ４０４）、調査済みの情報集合＜Ｆ＞（図４に示した調査使用情報における充足不能制約条件及び充足不能仮説）にｉが含まれるかどうかを判断する（Ｓ４０５）。

Ｆにｉが含まれない場合（Ｓ４０５，ＮＯ）、影響調査実行部１０５は、Ｆにｉを加え（Ｓ４０６）、ｉに関連する制約条件の集合＜Ｃ＞を取得し（Ｓ４０７，第１条件抽出ステップ）、図１６に示すように、Ｃが空かどうかを判断する（Ｓ４０８）。

Ｃが空ではない場合（Ｓ４０８，ＮＯ）、影響調査実行部１０５は、Ｃから個別の制約条件＜ｃ＞を取り出し（Ｓ４０９）、後述する制約評価処理を実行し（Ｓ４１０，第１条件判定ステップ）、制約条件が充足不能かどうかを判断する（Ｓ４１１）。なお、制約評価処理は制約条件が充足不能か充足可能かを判定する処理である。

制約条件が充足不能である場合（Ｓ４１１，ＹＥＳ）、影響調査実行部１０５は、ｃに関して不整合が発生するＥｎｔｉｔｙのうち、Ｆに含まれない要素をＩと調査結果＜Ｒ＞に加え（Ｓ４１２）、ＩとＲに加えた要素について、Ｃの信頼度を調査結果の信頼度＜Ｂ＞に記録する（Ｓ４１３）。さらに、影響調査実行部１０５は、ｃをＢと共に調査使用情報に登録し（Ｓ４１４）、Ｃが空かどうかを判断する（Ｓ４０８）。

一方、制約条件が充足不能ではない場合（Ｓ４１１，ＮＯ）、影響調査実行部１０５は、Ｃが空かどうかを判断する（Ｓ４０８）。

また、ステップＳ４０８の判断において、Ｃが空である場合（Ｓ４０８，ＹＥＳ）、影響調査実行部１０５は、ｉに関連する仮説の集合＜Ｈ＞を取得し（Ｓ４１５，第２条件抽出ステップ）、Ｈが空かどうかを判断する（Ｓ４１６）。

Ｈが空ではない場合（Ｓ４１６，ＮＯ）、影響調査実行部１０５は、Ｈから個別の仮説＜ｈ＞を取り出し（Ｓ４１７）、後述する仮説評価処理を実行し（Ｓ４１７，第２条件判定ステップ）、仮説が充足不能かどうかを判断する（Ｓ４１９）。なお、仮説評価処理は仮説が充足不能か充足可能かを判定する処理である。

仮説が充足可能である場合（Ｓ４１９）、影響調査実行部１０５は、ｈに関して不整合が発生するＥｎｔｉｔｙ集合のうち、Ｆに含まれない要素をＩとＲに加え（Ｓ４２０）、ＩとＲに加えた要素についてｈの信頼度をＢに記録する（Ｓ４２１）。さらに影響調査実行部１０５は、ｈを調査使用情報に登録し（Ｓ４２２）、Ｈが空かどうかを判断する（Ｓ４１６）。

一方、仮説が充足不能ではない場合（Ｓ４１９，ＮＯ）、影響調査実行部１０５は、Ｈが空かどうかを判断する（Ｓ４１６）。

また、ステップＳ４１６の判断において、Ｈが空である場合（Ｓ４１６，ＹＥＳ）、影響調査実行部１０５は、Ｉが空かどうかを判断する（Ｓ４０３）。

また、ステップＳ４０５の判断において、Ｆにｉが含まれる場合（Ｓ４０５，ＹＥＳ）、影響調査実行部１０５は、Ｉが空かどうかを判断する（Ｓ４０３）。

また、ステップＳ４０３の判断において、Ｉが空である場合（Ｓ４０３，ＹＥＳ）、影響調査実行部１０５は処理を終了する。

次に、制約評価処理について説明する。なお、この仮説作成処理は、図１６のフローチャートにおけるステップＳ４１０に対応する処理である。図１７は、制約評価処理の動作を示すフローチャートである。また、図１８は、変更後情報と充足不能な制約条件を持った属性に関する制約条件を示す図である。

図１７に示すように、まず、影響調査実行部１０５は、制約条件集合＜Ｃ＞における個別の制約条件＜ｃ＞が変更後情報＜ｄ＞に関する制約条件かどうかを判断する（Ｓ５０１）。

ｃがｄに関する制約条件である場合（Ｓ５０１，ＹＥＳ）、影響調査実行部１０５は、調査使用情報を参照してｃに関連するＥｎｔｉｔｙ集合＜Ｅ＞を取り出し（Ｓ５０２）、Ｅが空かどうかを判断する（Ｓ５０３）。

Ｅが空ではない場合（Ｓ５０３，ＮＯ）、影響調査実行部１０５は、Ｅの要素がＣＩのみかどうかを判断する（Ｓ５０４）。

Ｅの要素がＲｅｌａｔｉｏｎｓｈｉｐのみではない場合（Ｓ５０５，ＮＯ）、影響調査実行部１０５は、Ｅの各要素を使って、ｃ中の条件式を評価する（Ｓ５０６）。

一方、Ｅの要素がＲｅｌａｔｉｏｎｓｈｉｐのみである場合（Ｓ５０５，ＹＥＳ）、影響調査実行部１０５は、ＣＭＤＢ情報に登録されている全Ｒｅｌａｔｉｏｎｓｈｉｐの情報を使ってｃ中の条件式を評価する（Ｓ５０７）。

また、ステップＳ５０４において、Ｅの要素がＣＩのみである場合（Ｓ５０４，ＹＥＳ）、影響調査実行部１０５は、ＣＭＤＢ情報に登録されている全ＣＩの情報を使ってｃ中の条件式を評価する（Ｓ５０８）。

また、ステップＳ５０３において、Ｅが空である場合（Ｓ５０３，ＹＥＳ）、影響調査実行部１０５は、ＣＭＤＢ情報に登録されている全情報を使って、ｃ中の条件式を評価する（Ｓ５０９）。

また、ステップＳ５０１において、ｃがｄに関する制約条件ではない場合（Ｓ５０１，ＮＯ）、影響調査実行部１０５は、ｃがｄと充足不能な属性に関する制約条件かどうかを判断する（Ｓ５１０）。

ｃが、図１８に示すような、ｄと充足不能な属性に関する制約条件である場合（Ｓ５１０，ＹＥＳ）、影響調査実行部１０５は、ｃをｄに対して充足不能な制約条件と判定する（Ｓ５１１）。

一方、ｃがｄと充足不能な属性に関する制約条件ではない場合（Ｓ５１０，ＮＯ）、影響調査実行部１０５は、ｃをｄに対して充足可能な制約条件と判定する（Ｓ５１２）。

なお、ステップＳ５０６、Ｓ５０７、Ｓ５０８、Ｓ５０９における評価は、制約条件が充足不能か充足可能かを判定することを示すものである。このように制約条件に関連するＥｎｔｉｔｙに応じて、条件式を評価するために用いる情報を選択することにより、影響調査実行部１０５は、必要最小限な情報により制約条件を評価することができる。

また、ステップＳ５１０において、変更後の情報と充足不能な制約条件を持った属性に関する制約条件かどうかを判断することによって、変更された情報に関する制約条件以外の制約条件に対して、簡潔に評価を行うことができる。

次に、仮説評価処理について説明する。なお、この仮説評価処理は、図１６のフローチャートにおけるステップＳ４１８に対応する処理である。図１９は、仮説評価処理の動作を示すフローチャートである。また、図２０は、変更後情報と充足不能な制約条件または仮説を持った属性に関する仮説を示す図である。

図、１９に示すように、まず、影響調査実行部１０５は、仮説集合＜Ｈ＞における個別の仮説＜ｈ＞が変更情報＜ｄ＞に関する仮説かどうかを判断する（Ｓ６０１）。

ｈがｄに関する仮説である場合（Ｓ６０１，ＹＥＳ）、影響調査実行部１０５は、調査使用情報を参照してｈに関連するＥｎｔｉｔｙ集合＜Ｅ＞を取り出し（Ｓ６０２）、Ｅが空かどうかを判断する（Ｓ６０３）。

Ｅが空ではない場合（Ｓ６０３，ＮＯ）、影響調査実行部１０５は、Ｅの要素がＣＩのみかどうかを判断する（Ｓ６０４）。

Ｅの要素がＣＩのみではない場合（Ｓ６０４，ＮＯ）、影響調査実行部１０５は、Ｅの要素がＲｅｌａｔｉｏｎｓｈｉｐのみかどうかを判断する（Ｓ６０５）

Ｅの要素がＲｅｌａｔｉｏｎｓｈｉｐのみではない場合（Ｓ６０５，ＮＯ）、影響調査実行部１０５は、Ｅの各要素を使って、ｈ中の条件式を評価する（Ｓ６０６）。

一方、Ｅの要素がＲｅｌａｔｉｏｎｓｈｉｐのみである場合（Ｓ６０５，ＹＥＳ）、影響調査実行部１０５は、ＣＭＤＢ情報に登録されている全Ｒｅｌａｔｉｏｎｓｈｉｐの情報を使ってｈ中の条件式を評価する（Ｓ６０７）。

また、ステップＳ６０４において、Ｅの要素がＣＩのみである場合（Ｓ６０４，ＹＥＳ）、影響調査実行部１０５は、ＣＭＤＢ情報に登録されている全ＣＩの情報を使ってｈ中の条件式を評価する（Ｓ６０８）。

また、ステップＳ６０３において、Ｅが空である場合（Ｓ６０３，ＹＥＳ）、影響調査実行部１０５は、ＣＭＤＢ情報に登録されている全情報を使って、ｈ中の条件式を評価する（Ｓ６０９）。

また、ステップＳ６０１において、ｈがｄに関する仮説ではない場合（Ｓ６０１，ＮＯ）、影響調査実行部１０５は、ｈがｄと充足不能な制約条件または仮説を持った属性に関する仮説かどうかを判断する（Ｓ６１０）。

図２０に示すように、ｈがｄと充足不能な制約条件または仮説を持った属性に関する仮説である場合（Ｓ６１０，ＹＥＳ）、影響調査実行部１０５は、ｈをｄに対して充足不能な仮説と判定する（Ｓ６１１）。

一方、ｈがｄと充足不能な制約条件または仮説を持った属性に関する仮説ではない場合（Ｓ６１０，ＮＯ）、影響調査実行部１０５は、ｈをｄに対して充足可能な仮説と判定する（Ｓ６１２）。

なお、ステップＳ６０６、Ｓ６０７、Ｓ６０８、Ｓ６０９における評価は、仮説が充足不能か充足可能かを判定することを示すものである。このように仮説に関連するＥｎｔｉｔｙに応じて、条件式を評価するために用いる情報を選択することにより、影響調査実行部１０５は、必要最小限の処理により仮説を評価することができる。

また、変更後の情報と充足不能な制約条件または仮説を持った属性に関する仮説かどうかを判断することによって、変更された情報に関する仮説以外の仮説に対して、簡潔に評価を行うことができる。なお、充足不能な制約条件を持った属性に関する仮説かどうかを判断することによって、仮説よりもより確度の高い制約条件に基づく評価を得ることができる。

次に、検証部の動作について説明する。図２１は、検証部の動作を示すフローチャートである。なお、図２１において、検証部は操作実行部より検証依頼を受けているものとする。検証部は、検証により、仮設の制約条件への格上げ、制約条件の仮説への格下げを行う。

まず、検証部１０６は、検証依頼において調査ＩＤ＜ｉｄ＞が指定されているかどうかを判断する（Ｓ７０１）。

ｉｄが指定されていない場合（Ｓ７０１，ＮＯ）、検証部１０６は、ＣＭＤＢ情報を調べ、変更されるＥｎｔｉｔｙ＜Ｅ＞を求め（Ｓ７０２）、Ｅが空かどうかを判断する（Ｓ７０３）。

Ｅが空ではない場合（Ｓ７０３，ＮＯ）、検証部１０６は、Ｅから変更される個別のＥｎｔｉｔｙｔ＜ｅ＞を取り出し（Ｓ７０４）、仮説情報を調べ、仮説条件式が「同時に変更」であり、関連するＥｎｔｉｔｙの中にｅを含む仮説＜Ｈ＞を求め、Ｈが空かどうかを判断する（Ｓ７０６）。

Ｈが空ではない場合（Ｓ７０６，ＮＯ）、検証部１０６は、Ｈに含まれる各仮説について信頼度を上げ（Ｓ７０７，加算ステップ）、その結果としての信頼度が１００以上かどうかをそれぞれの仮説について判断する（Ｓ７０８）。

仮説の信頼度が１００以上である場合（Ｓ７０８，ＹＥＳ）、検証部１０６は、仮説を制約条件に格上げする（Ｓ７０９）。

一方、仮説の信頼度が１００に満たない場合（Ｓ７０８，ＮＯ）、検証部１０６は、Ｅが空かどうかを判断する（Ｓ７０３）。

また、ステップＳ７０６において、Ｈが空である場合（Ｓ７０６，ＹＥＳ）、検証部１０６は、Ｅが空かどうかを判断する（Ｓ７０３）。

また、ステップＳ７０３において、Ｅが空である場合（Ｓ７０３，ＹＥＳ）、検証部１０６は、処理を終了する。

また、ステップＳ７０１において、ｉｄが指定されている場合（Ｓ７０１，ＹＥＳ）、検証部１０６は、後述する制約条件検証処理を実行する（Ｓ７１０）。

次に、制約条件検証処理について説明する。図２２は、制約条件検証処理の動作を示すフローチャートである。なお、この制約条件検証処理は、図２１のフローチャートにおけるステップＳ７１０に対応する処理である。

まず、検証部１０６は、調査使用情報から検証依頼において指定された調査ＩＤ＜ｉｄ＞を持つ情報＜ｉ＞を取り出し（Ｓ８０１）、ｉが存在するかどうかを判断する（Ｓ８０２）。

ｉが存在する場合（Ｓ８０２，ＹＥＳ）、検証部１０６は、ｉ中の充足不能な制約条件Ｃを取り出し（Ｓ８０３）、Ｃに含まれる制約条件ＩＤを持つ制約条件について、変更後も充足されない制約条件＜Ｄ＞を求め（Ｓ８０４）、Ｄに含まれる各制約条件について信頼度を下げる（Ｓ８０５，第１減算ステップ）。

次に、検証部１０６は、Ｃに含まれる制約条件ＩＤを持つ制約条件について、変更後に充足される制約条件＜Ｄ＞を求め（Ｓ８０６）、Ｄに含まれる各制約条件について信頼度を上げる（Ｓ８０７）。

次に、検証部１０６は、Ｃに含まれない制約条件ＩＤを持つ制約条件について、変更後に充足されない制約条件＜Ｄ＞を求め（Ｓ８０８）、Ｄに含まれる各制約条件について信頼度を下げる（Ｓ８０９，第１減算ステップ）。

さらに、検証部１０６は、Ｃに含まれない制約条件ＩＤを持つ制約条件について、変更後も充足される制約条件＜Ｄ＞を求め（Ｓ８１０）、Ｄに含まれる各制約条件について信頼度を上げ（Ｓ８１１）、信頼度を変更した各制約条件について、信頼度が０以下かどうかを判断する（Ｓ８１２）。

信頼度が０以下である場合（Ｓ８１２，ＹＥＳ）、検証部１０６は、制約条件を仮説に格下げし（Ｓ８１３，第２条件変更ステップ）、後述する仮説検証処理を実行する（Ｓ８１４）。

一方、信頼度が０より大きい場合（Ｓ８１２，ＮＯ）、検証部１０６は、後述する仮説検証処理を実行する（Ｓ８１４）。

次に、仮説検証処理について説明する。図２３は、仮説検証処理の動作を示すフローチャートである。なお、この仮説検証処理は、図２２のフローチャートにおけるステップＳ８１４に対応する処理である。

まず、検証部１０６は、ｉ中の充足不能な仮説＜Ｈ＞を取り出し（Ｓ９０１）、Ｈに含まれる仮説ＩＤを持つ仮説について、変更後も充足されない仮説＜Ｄ＞を求め（Ｓ９０２）、Ｄに含まれる各仮説について信頼度を下げる（Ｓ９０３，第２減算ステップ）。

次に、検証部１０６は、Ｈに含まれる仮説ＩＤを持つ仮説について、変更後に充足される仮説＜Ｄ＞を求め（Ｓ９０４）、Ｄに含まれる各仮説について信頼度を上げる（Ｓ９０５，加算ステップ）。

次に、検証部１０６は、Ｈに含まれない仮説ＩＤを持つ仮説について、変更後に充足されない仮説＜Ｄ＞を求め（Ｓ９０６）、Ｄに含まれる各仮説について信頼度を下げる（Ｓ９０７，第２減算ステップ）。

さらに、検証部１０６は、Ｈに含まれない仮説ＩＤを持つ仮説について、変更後も充足される仮説＜Ｄ＞を求め（Ｓ９０８）、Ｄに含まれる各仮説について信頼度を上げ（Ｓ９０９）、信頼度を変更した各仮説について、信頼度が１００以上かどうかを判断する（Ｓ９１０）。

信頼度が１００以上ではない場合（Ｓ９１０，ＮＯ）、検証部１０６は、仮説の信頼度が０以下であるかどうかを判断する（Ｓ９１１）。

信頼度が０以下ではない場合（Ｓ９１１，ＮＯ）、検証部１０６は、処理を終了する。

一方、信頼度が０以下である場合（Ｓ９１１，ＹＥＳ）、検証部１０６は、仮説を削除する（Ｓ９１２，削除ステップ）。

また、ステップＳ９１０において、信頼度が１００以上である場合（Ｓ９１０，ＹＥＳ）、検証部１０６は、仮説を制約条件に格上げする（Ｓ９１３，第１条件変更ステップ，第１条件設定ステップ）。

上述したように、仮説及び制約条件に設定された信頼度を変更し、所定の信頼度以上の仮説を制約条件に格上げし、所定の信頼度以下の制約条件を仮説に格下げし、所定の信頼度以下の仮説を削除することによって、制約条件の信頼性を保つことができる。

次に、制約条件管理部の動作について説明する。図２４は、制約条件管理部の動作を示すフローチャートである。なお、このフローチャートにおいて、操作実行部より制約条件の登録、削除または更新依頼がなされているものとする。

まず、制約条件管理部１０７は、操作実行部１０１からの要求が制約条件の登録依頼かどうかを判断する（Ｓ１００１）。

要求が制約条件の登録依頼ではない場合（Ｓ１００１，ＮＯ）、制約条件管理部１０７は、操作実行部１０１からの要求が制約条件の削除依頼かどうかを判断する（Ｓ１００２）。

要求が制約条件の削除依頼ではない場合（Ｓ１００２，ＮＯ）、制約条件管理部１０７は、操作実行部１０１からの要求が制約条件の更新依頼かどうかを判断する（Ｓ１００３）。

要求が更新依頼ではない場合（Ｓ１００３，ＮＯ）、制約条件管理部１０７は、処理を終了する。

一方、要求が更新依頼である場合（Ｓ１００３，ＮＯ）、制約条件管理部１０７は、制約条件情報について制約条件ＩＤで指定された制約条件を、更新依頼に付加された新しい制約条件に更新する（Ｓ１００４）。

また、ステップＳ１００２の判断において、要求が削除依頼である場合（Ｓ１００２）、制約条件管理部１０７は、制約条件情報の中から制約条件ＩＤで指定された制約条件を削除する（Ｓ１００５）。

また、ステップＳ１００１の判断において、要求が登録依頼である場合（Ｓ１００１，ＮＯ）、制約条件管理部１０７は、制約条件情報の中に、登録依頼に付加された新しい制約条件を登録する（Ｓ１００６）。

上述したように、制約条件管理部１０７によれば、制約条件を手動で登録（第１条件設定ステップ）、削除、更新することができる。

また、本実施の形態に係るＣＭＤＢ１０は、クライアント端末２０からの影響調査依頼に対する調査結果の提示において、不具合が生じる可能性が生じるＥｎｔｉｔｙをその判断の根拠と共に調査ＩＤを付加し、クライアント端末２０に提示する。

また、以上の構成及び動作により、本発明はシステムを構成するリソースに関する情報の更新により不整合が生じる可能性がある範囲を高精度かつ効率的に得ることができる。

本発明は、その要旨または主要な特徴から逸脱することなく、他の様々な形で実施することができる。そのため、前述の実施の形態は、あらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には、何ら拘束されない。更に、特許請求の範囲の均等範囲に属する全ての変形、様々な改良、代替および改質は、全て本発明の範囲内のものである。

更に、情報処理装置を構成するコンピュータにおいて上述した各ステップを実行させるプログラムを、情報処理プログラムとして提供することができる。上述したプログラムは、コンピュータにより読取り可能な記録媒体に記憶させることによって、情報処理装置を構成するコンピュータに実行させることが可能となる。ここで、上記コンピュータにより読取り可能な記録媒体としては、ＲＯＭやＲＡＭ等のコンピュータに内部実装される内部記憶装置、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。

本発明によれば、システムを構成するリソースの更新による不整合が生じる可能性のある範囲を高精度且つ効率的に知ることができる。

Claims (10)

1. システムを構成するリソースに関する情報であるリソース情報を管理する情報処理装置であって、
   所定のリソース情報と他のリソース情報との間に所定の条件である第１条件を設定する第１条件設定部と、
   リソースが変更された場合、前記リソース情報に対する変更を示す情報である変更情報に基づき、前記設定された第１条件を抽出する第１条件抽出部と、
   前記変更情報が前記第１条件抽出部により抽出された第１条件を満たすか否かを判定し、前記変更情報が前記抽出された第１条件を満たさない場合、前記抽出された第１条件が設定されたリソース情報が前記変更されたリソースに関連すると判定する第１条件判定部と、
   を備える情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記リソース情報が登録または変更された場合、該リソース情報と予め関連付けられたリソース情報である関連リソース情報と登録または変更されたリソース情報である更新リソース情報との関係に基づいて、前記第１条件とは異なる条件であり、信頼度が付加された条件である第２条件を前記更新リソース情報と前記関連リソース情報間に設定する第２条件設定部と、
   前記第２条件設定部により設定された第２条件より、変更情報に基づき、前記設定された第２条件を抽出する第２条件抽出部と、
   前記変更情報が前記第２条件抽出部により抽出された第２条件を満たすか否かを判定する第２条件判定部と、
   前記第２条件判定部により前記変更情報が前記抽出された第２条件を満たすと判定された場合、前記抽出された第２条件に付加された信頼度に所定の値を加算する加算部と、
   付加された信頼度が所定の値以上である第２条件を前記第１条件とする第１条件変更部と、
   をさらに備える情報処理装置。
3. 請求項２に記載の情報処理装置において、
   前記第１条件設定部により前記所定のリソース情報に設定される第１条件は信頼度が付加されていることを特徴とし、
   前記第１条件判定部により前記変更情報が前記抽出された第１条件を満たさないと判定された場合、前記抽出された第１条件に付加された信頼度から所定の値を減算する第１減算部と、
   付加された信頼度が所定の値以下である第１条件を前記第２条件とする第２条件変更部と、
   をさらに備える情報処理装置。
4. 請求項２に記載の情報処理装置において、
   前記第２条件判定部により前記変更情報が前記抽出された第２条件を満たさないと判断された場合、前記抽出された第２条件に付加された信頼度から所定の値を減算する第２減算部と、
   付加された信頼度が所定の値以下である第２条件を削除する削除部と、
   をさらに備える情報処理装置。
5. システムを構成するリソースに関する情報であるリソース情報を管理することができる情報処理プログラムであって、
   所定のリソース情報と他のリソース情報との間に所定の条件である第１条件を設定する第１条件設定ステップと、
   リソースが変更された場合、前記リソース情報に対する変更を示す情報である変更情報に基づき、前記設定された第１条件を抽出する第１条件抽出ステップと、
   前記変更情報が前記第１条件抽出ステップにより抽出された第１条件を満たすか否かを判定し、前記変更情報が前記抽出された第１条件を満たさない場合、前記抽出された第１条件が設定されたリソース情報が前記変更されたリソースに関連すると判定する第１条件判定ステップと、
   をコンピュータに実行させる情報処理プログラム。
6. 請求項５に記載の情報処理プログラムであって、
   前記リソース情報が登録または変更された場合、該リソース情報と予め関連付けられたリソース情報である関連リソース情報と、登録または変更されたリソース情報である更新リソース情報との関係に基づいて、前記第１条件とは異なる条件であり、信頼度が付加された条件である第２条件を前記更新リソース情報と前記関連リソース情報間に設定する第２条件設定ステップと、
   前記第２条件設定ステップにより設定された第２条件より、変更情報に基づき、前記設定された第２条件を抽出する第２条件抽出ステップと、
   前記変更情報が前記第２条件抽出ステップにより抽出された第２条件を満たすか否かを判定する第２条件判定ステップと、
   前記第２条件判定ステップにより前記変更情報が前記抽出された第２条件を満たすと判定された場合、前記抽出された第２条件に付加された信頼度に所定の値を加算する加算ステップと、
   付加された信頼度が所定の値以上である第２条件を前記第１条件とする第１条件変更ステップと、
   をさらにコンピュータに実行させる情報処理プログラム。
7. 請求項６に記載の情報処理プログラムにおいて、
   前記第１条件設定ステップにより前記所定のリソース情報に設定される第１条件は信頼度が付加されていることを特徴とし、
   前記第１条件判定ステップにより前記変更情報が前記抽出された第１条件を満たさないと判定された場合、前記抽出された第１条件に付加された信頼度から所定の値を減算する第１減算ステップと、
   付加された信頼度が所定の値以下である第１条件を前記第２条件とする第２条件変更ステップと、
   をさらにコンピュータに実行させる情報処理プログラム。
8. システムを構成するリソースに関する情報であるリソース情報を管理するための情報処理方法であって、
   所定のリソース情報と他のリソース情報との間に所定の条件である第１条件を設定する第１条件設定ステップと、
   リソースが変更された場合、前記リソース情報に対する変更を示す情報である変更情報に基づき、前記設定された第１条件を抽出する第１条件抽出ステップと、
   前記変更情報が前記第１条件抽出ステップにより抽出された第１条件を満たすか否かを判定し、前記変更情報が前記抽出された第１条件を満たさない場合、前記抽出された第１条件が設定されたリソース情報が前記変更されたリソースに関連すると判定する第１条件判定ステップと、
   を備える情報処理方法。
9. 請求項８に記載の情報処理方法であって、
   前記リソース情報が登録または変更された場合、該リソース情報と予め関連付けられたリソース情報である関連リソース情報と、登録または変更されたリソース情報である更新リソース情報との関係に基づいて、前記第１条件とは異なる条件であり、信頼度が付加された条件である第２条件を前記更新リソース情報と前記関連リソース情報間に設定する第２条件設定ステップと、
   前記第２条件設定ステップにより設定された第２条件より、変更情報に基づき、前記設定された第２条件を抽出する第２条件抽出ステップと、
   前記変更情報が前記第２条件抽出ステップにより抽出された第２条件を満たすか否かを判定する第２条件判定ステップと、
   前記第２条件判定ステップにより前記変更情報が前記抽出された第２条件を満たすと判定された場合、前記抽出された第２条件に付加された信頼度に所定の値を加算する加算ステップと、
   付加された信頼度が所定の値以上である第２条件を前記第１条件とする第１条件変更ステップと、
   をさらに備える情報処理方法。
10. 請求項９に記載の情報処理方法において、
    前記第１条件設定ステップにより前記所定のリソース情報に設定される第１条件は信頼度が付加されていることを特徴とし、
    前記第１条件判定ステップにより前記変更情報が前記抽出された第１条件を満たさないと判定された場合、前記抽出された第１条件に付加された信頼度から所定の値を減算する第１減算ステップと、
    付加された信頼度が所定の値以下である第１条件を前記第２条件とする第２条件変更ステップと、
    をさらに備える情報処理方法。

Images