(57)【要約】【課題】オブジェクトに制約がある場合であっても、適切なオブジェクトにサービス実行を指示することのできるオブジェクト管理装置を提供する。【解決手段】オブジェクト管理装置１０であって、オブジェクトが実行可能な処理と、当該処理を実行するための前提となるオブジェクトの状態を示す実行条件を対応付けて保持する実行条件保持手段１１０と、オブジェクトに実行させるべき処理の内容を示す実行指示を取得する実行指示取得手段１２０と、オブジェクトから当該オブジェクトの状態を示す状態情報を取得する状態情報取得手段１０４と、実行条件保持手段１１０において、実行指示に示される処理に対応付けられている実行条件と、状態情報取得手段が取得した状態情報とに基づいて、オブジェクトが実行指示に示される処理を実行可能か否かを判定する状態判定手段１３２とを備えた。【選択図】        図２
2006277120.tif 000002
【特許請求の範囲】
【請求項１】
外部から呼び出し可能なオブジェクトを管理するオブジェクト管理装置であって、
前記オブジェクトが実行可能な処理と、当該処理を実行するための前提となるオブジェクトの状態を示す実行条件を対応付けて保持する実行条件保持手段と、
前記オブジェクトに実行させるべき処理の内容を示す実行指示を取得する実行指示取得手段と、
前記オブジェクトから当該オブジェクトの状態を示す状態情報を取得する状態情報取得手段と、
前記実行条件保持手段において、前記実行指示取得手段が取得した前記実行指示に示される処理に対応付けられている前記実行条件と、前記状態情報取得手段が取得した前記状態情報とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定する状態判定手段と
を備えたことを特徴とするオブジェクト管理装置。
【請求項２】
前記オブジェクトの状態は、最小単位の状態を示す一または二以上の状態変数で示され、
前記実行条件保持手段は、前記オブジェクトの前記状態変数を含む前記実行条件を保持し、
前記状態情報取得手段は、前記状態変数を含む前記状態情報を取得し、
前記状態判定手段は、前記状態情報に含まれる前記状態変数と、前記実行条件に含まれる前記状態変数とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定することを特徴とする請求項１に記載のオブジェクト管理装置。
【請求項３】
前記状態情報に含まれる前記状態変数と、前記実行条件に含まれる前記状態変数との一致度を算出する一致度算出手段をさらに備え、
前記状態判定手段は、前記一致度算出手段が算出した前記一致度が所定の値以上である場合に前記オブジェクトが前記実行指示に示される処理を実行可能であると判定することを特徴とする請求項２に記載のオブジェクト管理装置。
【請求項４】
前記状態情報取得手段が取得した前記状態情報に含まれる前記状態変数に基づいて、当該状態変数が変化する可能性のある動的状態変数および変化する可能性のない静的状態変数のいずれであるかを特定する状態変数特定手段をさらに備え、
前記状態判定手段は、前記状態変数特定手段が特定した前記動的状態変数と、前記実行条件に含まれる前記状態変数とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定することを特徴とする請求項２に記載のオブジェクト管理装置。
【請求項５】
前記状態判定手段は、前記動的状態変数と、前記実行条件に含まれる前記状態変数とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能であると判断した場合に、さらに前記静的状態変数と、前記実行条件に含まれる前記状態変数とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定することを特徴とする請求項４に記載のオブジェクト管理装置。
【請求項６】
各状態変数の間の関係を示す状態変数間関係情報を保持する状態変数間関係情報保持手段をさらに備え、
前記状態判定手段は、前記状態変数間関係保持手段が保持する前記状態変数間関係情報により、前記状態情報取得手段が取得した前記状態情報に含まれる前記状態変数に関係付けられている他の状態変数と、前記実行条件に含まれる前記状態変数とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定することを特徴とする請求項２に記載のオブジェクト管理装置。
【請求項７】
前記状態変数間関係情報保持手段は、各状態変数の包含関係を示す前記状態変数間関係を保持することを特徴とする請求項６に記載のオブジェクト管理装置。
【請求項８】
前記状態情報取得手段が取得した前記状態情報に含まれる前記状態変数を記述論理による記述論理コンセプトに変換し、かつ前記実行条件保持手段が保持している前記実行条件に含まれる前記状態変数を前記記述論理コンセプトに変換するコンセプト変換手段をさらに備え、
前記状態判定手段は、前記コンセプト変換手段により得られた前記状態情報に対する前記記述論理コンセプトと、前記実行条件に対する前記記述論理コンセプトとに基づいて、前記オブジェクトが前記処理を実行可能か否かを判定することを特徴とする請求項６または７に記載のオブジェクト管理装置。
【請求項９】
前記実行条件保持手段は、複数のオブジェクトそれぞれに対応付けて、各オブジェクトの実行条件を保持し、
前記状態情報取得手段は、複数のオブジェクトそれぞれから前記状態情報を取得し、
前記状態判定手段は、各オブジェクトに対する前記実行条件および前記状態情報に基づいて、各オブジェクトが前記実行指示に示される処理を実行可能か否かを判定し、
前記状態判定手段が前記実行指示に示される処理を実行可能であると判定した複数のオブジェクトの中から、前記実行条件および前記実行状態に基づいて、前記実行指示に示される処理を実行させるべきオブジェクトを決定するオブジェクト決定手段をさらに備えたことを特徴とする請求項１に記載のオブジェクト管理装置。
【請求項１０】
前記オブジェクトの状態が変化する頻度を特定する変化頻度特定手段をさらに備え、
前記オブジェクト決定手段は、前記変化頻度特定手段が特定した変化の頻度に基づいて、前記実行指示に示される処理を実行させるべきオブジェクトを決定することを特徴とする請求項９に記載のオブジェクト管理装置。
【請求項１１】
前記オブジェクトの状態は、最小単位の状態を示す一または二以上の状態変数で示され、
前記実行条件保持手段は、前記オブジェクトの前記状態変数を含む前記実行条件を保持し、各状態変数に対応付けて重要度をさらに保持し、
前記オブジェクト決定手段は、前記状態情報に含まれる前記状態変数の重要度に基づいて、前記実行指示に示される処理を実行させるべきオブジェクトを決定することを特徴とする請求項９に記載のオブジェクト管理装置。
【請求項１２】
前記オブジェクト決定手段は、前記状態情報に含まれる前記状態変数と前記実行条件に含まれる前記状態変数との間の関係に基づいて、前記実行指示に示される処理を実行させるべきオブジェクトを決定することを特徴とする請求項９に記載のオブジェクト管理装置。
【請求項１３】
前記状態情報取得手段が取得した前記状態情報を保持する状態情報保持手段をさらに備え、
前記状態情報取得手段は、オブジェクトの状態情報のうち、既に前記状態情報保持手段に保持されている前記状態情報と異なる情報を取得し、
前記状態判定手段は、前記状態情報保持手段が保持している前記状態情報と、前記実行条件とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定することを特徴とする請求項１に記載のオブジェクト管理装置。
【請求項１４】
予め定められた初期状態情報を保持する状態情報保持手段と、
前記状態情報取得手段が前記状態情報を取得した場合に、前記状態情報保持手段に前記初期状態情報にかえて前記状態情報取得手段が取得した前記状態情報を保持させる登録手段と
をさらに備え、
前記状態判定手段は、前記状態情報保持手段が保持している前記状態情報と、前記実行条件とに基づいて、前記オブジェクトが前記実指示に示される処理を実行可能か否かを判定することを特徴とする請求項１に記載のオブジェクト管理装置。
【請求項１５】
外部から呼び出し可能なオブジェクトを管理するオブジェクト管理方法であって、
前記オブジェクトに実行させるべき処理の内容を示す実行指示を取得する実行指示取得ステップと、
前記オブジェクトから当該オブジェクトの状態を示す状態情報を取得する状態情報取得ステップと、
前記オブジェクトが実行可能な処理と、当該処理を実行するための前提となるオブジェクトの状態を示す実行条件を対応付けて保持する実行条件保持手段において、前記実行指示取得ステップにおいて取得した前記実行指示に示される処理に対応付けられている前記実行条件と、前記状態情報取得ステップにおいて取得した前記状態情報とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定する状態判定ステップと
を有することを特徴とするオブジェクト管理方法。
【請求項１６】
外部から呼び出し可能なオブジェクトを管理するオブジェクト管理処理をコンピュータに実行させるオブジェクト管理プログラムであって、
前記オブジェクトに実行させるべき処理の内容を示す実行指示を取得する実行指示取得ステップと、
前記オブジェクトから当該オブジェクトの状態を示す状態情報を取得する状態情報取得ステップと、
前記オブジェクトが実行可能な処理と、当該処理を実行するための前提となるオブジェクトの状態を示す実行条件を対応付けて保持する実行条件保持手段において、前記実行指示取得ステップにおいて取得した前記実行指示に示される処理に対応付けられている前記実行条件と、前記状態情報取得ステップにおいて取得した前記状態情報とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定する状態判定ステップと
を有することを特徴とするオブジェクト管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、外部から呼び出し可能なオブジェクトを管理するオブジェクト管理装置、オブジェクト管理方法およびオブジェクト管理プログラムに関するものである。
【背景技術】
【０００２】
従来から、ネットワーク上で公開されたソフトウェアプログラムのサービスを検索する装置が知られている。例えば、特許文献１には、サービス検索に必要となるプログラム言語に基づく検索条件に対し、オントロジーによる類似性判断を適用した仕組みを有するサービス情報提供装置が開示されている。
【０００３】
【特許文献１】特開２００４−１１８７２２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ハードウェアと密接に連携する機器が混在する環境における多くのソフトウェアプログラムは、一度に数多くの人にサービス提供できるように作られている。例えば、銀行サービスは同時に何万人ものアクセスを受け付けることが可能である。
【０００５】
しかしながら、センサーやロボットなどにおけるサービスの提供においては、物理的な資源の制約があるため、一度に数多くの人にサービスを提供することが困難な場合がある。例えば、ロボットにおいては、一度に一人にしか話しかけることができない。すなわち、話かけるというサービスは、複数人に同時に提供することはできない。
【０００６】
このように、センサーやロボットによるサービス提供における制約は、Ｗｅｂサービスの場合に比べて厳しい。したがって、センサー等におけるサービス提供においては、利用状況を考慮することが重要となってくる。なお、ここでいうサービスとは、各装置、プログラム等が有する機能、すなわち実行可能な処理のことである。
【０００７】
本発明は、上記に鑑みてなされたものであって、サービス提供元となるオブジェクトに制約がある場合であっても、適切なオブジェクトにサービス実行を指示することのできるオブジェクト管理装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するために、本発明は、外部から呼び出し可能なオブジェクトを管理するオブジェクト管理装置であって、前記オブジェクトが実行可能な処理と、当該処理を実行するための前提となるオブジェクトの状態を示す実行条件を対応付けて保持する実行条件保持手段と、前記オブジェクトに実行させるべき処理の内容を示す実行指示を取得する実行指示取得手段と、前記オブジェクトから当該オブジェクトの状態を示す状態情報を取得する状態情報取得手段と、前記実行条件保持手段において、前記実行指示取得手段が取得した前記実行指示に示される処理に対応付けられている前記実行条件と、前記状態情報取得手段が取得した前記状態情報とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定する状態判定手段とを備えたことを特徴とする。
【０００９】
また、本発明の他の形態は、外部から呼び出し可能なオブジェクトを管理するオブジェクト管理方法であって、前記オブジェクトに実行させるべき処理の内容を示す実行指示を取得する実行指示取得ステップと、前記オブジェクトから当該オブジェクトの状態を示す状態情報を取得する状態情報取得ステップと、前記オブジェクトが実行可能な処理と、当該処理を実行するための前提となるオブジェクトの状態を示す実行条件を対応付けて保持する実行条件保持手段において、前記実行指示取得ステップにおいて取得した前記実行指示に示される処理に対応付けられている前記実行条件と、前記状態情報取得ステップにおいて取得した前記状態情報とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定する状態判定ステップとを有することを特徴とする。
【００１０】
また、本発明の他の形態は、外部から呼び出し可能なオブジェクトを管理するオブジェクト管理処理をコンピュータに実行させるオブジェクト管理プログラムであって、前記オブジェクトに実行させるべき処理の内容を示す実行指示を取得する実行指示取得ステップと、前記オブジェクトから当該オブジェクトの状態を示す状態情報を取得する状態情報取得ステップと、前記オブジェクトが実行可能な処理と、当該処理を実行するための前提となるオブジェクトの状態を示す実行条件を対応付けて保持する実行条件保持手段において、前記実行指示取得ステップにおいて取得した前記実行指示に示される処理に対応付けられている前記実行条件と、前記状態情報取得ステップにおいて取得した前記状態情報とに基づいて、前記オブジェクトが前記実行指示に示される処理を実行可能か否かを判定する状態判定ステップとを有することを特徴とする。
【発明の効果】
【００１１】
本発明にかかるオブジェクト管理装置は、実行条件保持手段が、オブジェクトが実行可能な処理と、当該処理を実行するための前提となるオブジェクトの状態を示す実行条件を対応付けて保持し、実行指示取得手段が、オブジェクトに実行させるべき処理の内容を示す実行指示を取得し、状態情報取得手段が、オブジェクトから当該オブジェクトの状態を示す状態情報を取得し、状態判定手段が、実行条件保持手段において、実行指示取得手段が取得した実行指示に示される処理に対応付けられている実行条件と、状態情報取得手段が取得した状態情報とに基づいて、オブジェクトが実行指示に示される処理を実行可能か否かを判定する。このように、プリミティブなレベルの状態変数を利用するので、オブジェクトの種類に依存することなく各オブジェクトの状態を特定することができるという効果を奏する。すなわち、ユビキタスネットワークに繋がる機器やインターネット上のサービスのように、ヘテロジニアスなデバイス・サービス、異なるメーカー、異なる業界が混在する場合であっても、サービス提供元となる各オブジェクトの状態を適切に判定することができるという効果を奏する。
【００１２】
また、本発明にかかるオブジェクト管理方法は、実行指示取得ステップにおいて、オブジェクトに実行させるべき処理の内容を示す実行指示を取得し、状態情報取得ステップにおいて、オブジェクトから当該オブジェクトの状態を示す状態情報を取得し、状態判定ステップにおいて、オブジェクトが実行可能な処理と、当該処理を実行するための前提となるオブジェクトの状態を示す実行条件を対応付けて保持する実行条件保持手段において、実行指示取得ステップにおいて取得した実行指示に示される処理に対応付けられている実行条件と、状態情報取得ステップにおいて取得した状態情報とに基づいて、オブジェクトが実行指示に示される処理を実行可能か否かを判定する。このように、プリミティブなレベルの状態変数を利用するので、オブジェクトの種類に依存することなく各オブジェクトの状態を特定することができるという効果を奏する。すなわち、ユビキタスネットワークに繋がる機器やインターネット上のサービスのように、ヘテロジニアスなデバイス・サービス、異なるメーカー、異なる業界が混在する場合であっても、サービス提供元となる各オブジェクトの状態を適切に判定することができるという効果を奏する。
【００１３】
また、本発明にかかるオブジェクト管理プログラムは、実行指示取得ステップにおいて、オブジェクトに実行させるべき処理の内容を示す実行指示を取得し、状態情報取得ステップにおいて、オブジェクトから当該オブジェクトの状態を示す状態情報を取得し、状態判定ステップにおいて、オブジェクトが実行可能な処理と、当該処理を実行するための前提となるオブジェクトの状態を示す実行条件を対応付けて保持する実行条件保持手段において、実行指示取得ステップにおいて取得した実行指示に示される処理に対応付けられている実行条件と、状態情報取得ステップにおいて取得した状態情報とに基づいて、オブジェクトが実行指示に示される処理を実行可能か否かを判定する。このように、プリミティブなレベルの状態変数を利用するので、オブジェクトの種類に依存することなく各オブジェクトの状態を特定することができるという効果を奏する。すなわち、ユビキタスネットワークに繋がる機器やインターネット上のサービスのように、ヘテロジニアスなデバイス・サービス、異なるメーカー、異なる業界が混在する場合であっても、サービス提供元となる各オブジェクトの状態を適切に判定することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１４】
以下に、本発明にかかるオブジェクト管理装置、オブジェクト管理方法およびオブジェクト管理プログラムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【００１５】
（実施の形態１）
図１は、実施の形態１にかかるオブジェクト管理システム１の全体構成を示す図である。オブジェクト管理システム１は、オブジェクト管理装置１０と、オブジェクト管理装置１０が管理する複数のロボット２０ａ〜２０ｃを備えている。オブジェクト管理装置１０と、ロボット２０ａ〜２０ｃとは例えばネットワーク等により通信可能である。なお、本実施の形態にかかるロボットは、特許請求の範囲に記載のオブジェクトに対応する。
【００１６】
ロボット２０は、各種サービスを実行する。ここで、サービスとは、ロボット２０が実行可能な機能のことである。具体的には、所定の目的地までの移動や、音声出力などがある。
【００１７】
オブジェクト管理装置１０は、ロボット２０ａ〜２０ｃを管理する。オブジェクト管理装置１０は、所定のサービスを実行する旨を示すサービス実行指示を取得すると、３つのロボット２０ａ〜２０ｃのうちから当該サービスを実行させるべきロボットを選択する。
【００１８】
具体的には、各ロボット２０ａ〜２０ｃの状態を特定する。そして、サービスを実行可能な状態にあるロボットを選択する。選択されたロボットは、サービス実行指示にしたがい、サービスを実行する。なお、サービスを実行させるロボットは１台でもよく、また複数台でもよい。
【００１９】
図２は、オブジェクト管理装置１０の機能構成を示すブロック図である。オブジェクト管理装置１０は、サービス登録部１０２と、状態情報登録部１０４と、サービスデータベース（ＤＢ）１１０と、状態情報ＤＢ１１２と、実行指示取得部１２０と、ロボット検索部１２２と、サービス呼出条件抽出部１２４と、状態情報抽出部１２６と、コンセプト変換部１３０と、状態判定部１３２と、ロボット決定部１３４と、実行指示部１３６と、タクソノミーＤＢ１４０とを備えている。
【００２０】
サービス登録部１０２は、各ロボット２０ａ〜２０ｃからそれぞれが有するサービスと、当該サービスに対するサービス呼出条件とを取得し、サービスＤＢ１１０に登録する。ここで、サービス呼出条件とは、サービスを実行する直前に状態情報が満たすべき条件である。なお、本実施の形態にかかるサービス呼出条件は、特許請求の範囲に記載の実行条件に対応する。
【００２１】
ここで、状態情報とは、ロボットの状態を示す情報である。さらに、本実施の形態にかかる状態情報は、複数の状態変数の集合として示される。状態変数とは、例えば、ロボット２０の電源のオンオフや、ロボット２０の現在位置などロボット２０の現在の状態を示す情報である。状態変数は、プリミティブなレベルの状態変数であり、いずれのロボットも有しうる状態を示す情報である。例えば、電源がオンでありかつ現在位置がＸであることを示す状態情報は、電源がオンであるという状態変数と、現在位置がＸであるという状態変数との集合で表現される。
【００２２】
図３は、サービスＤＢ１１０のデータ構成を模式的に示す図である。本実施の形態にかかるサービスＤＢ１１０は、特許請求の範囲に記載の実行条件保持手段に対応する。
【００２３】
サービスＤＢ１１０は、オブジェクト管理装置１０が管理する対象となっている各ロボット２０ａ〜２０ｃのサービスを保持している。具体的には、サービスＤＢ１１０は、ロボットを識別するロボットＩＤに対応付けて、各ロボットが有するサービスと、サービス呼出条件とを保持している。図３に示す例においては、ロボットＩＤ「０００１」には、「move」が対応付けられている。
【００２４】
また、「move」のためのサービス呼出条件として、以下の状態変数が保持されている。
Power = On
Drive ≦ 2
ここで、「Power = On」は、パワーがオン状態にあることを示している。「Drive ≦ 2」は、ドライブの値が２以下であることを示している。なお、ここで、「Power」や、「Drive」など状態変数中のアトミックコンセプトの意味は、予め定義されているものとする。
【００２５】
すなわち、ロボットＩＤ「０００１」で識別されるロボットは移動可能であり、移動の前提として、パワーオン状態であり、かつドライブの値が２以下の状態になっていることが必要である。
【００２６】
また、ロボットＩＤ「０００２」には、同様に「move」が対応付けられている。また、「move」のためのサービス呼出条件として、以下の状態変数が保持されている。
Power = On
Drive ≦ 4
Sensor=true
ここで、「Sensor=true」は、センサーを備えていることを示している。
【００２７】
すなわち、ロボットＩＤ「０００２」で識別されるロボットは移動可能であり、移動の前提として、パワーオン状態であり、ドライブの値が４以下であり、かつセンサーを有していることが必要である。
【００２８】
なお、１つのロボットが複数のサービスを有する場合には、１つのロボットに対し、複数のサービスを対応付けて保持する。
【００２９】
再び説明を図２に戻す。状態情報登録部１０４は、各ロボット２０ａ〜２０ｃからそれぞれの状態を示す状態情報を取得し、状態情報ＤＢ１１２に登録する。図４は、状態情報ＤＢ１１２のデータ構成を模式的に示す図である。状態情報ＤＢ１１２は、ロボット識別情報に対応付けて、ロボットの状態情報を保持している。図４に示す例においては、ロボットＩＤ「０００１」に対する状態情報として以下の状態変数の集合が保持されている。
Power = On
Wheel = 2
UltraSonic = True
Speak = n/a
Location = locationX
【００３０】
ここで、「WHEEL = 2」は、車輪が２つあることを示している。「UltraSonic = True」は、赤外線センサーを備えていることを示している。「Speak = n/a」は、音声出力機能を有さないことを示している。「Location = locationX」は、現在位置がlocaionXであることを示している。
【００３１】
また、ロボットＩＤ「０００２」に対する状態情報として以下の状態変数の集合が保持されている。
StandBy = On
Legs = malfunction
Infrared = True
【００３２】
ここで、「StandBy = On」は、パワーがスタンバイ状態にあることを示している。また、「Legs = malfunction」は、足を有するが、故障中であることを示している。また、「Infrared = True」は、赤外線センサーを有することを示している。
【００３３】
さらに、状態情報ＤＢ１１２は、状態情報登録部１０４が状態情報を登録した登録日時を保持している。すなわち、状態情報ＤＢ１１２は、各ロボットの状態情報の変化頻度をさらに保持している。ここで、変化頻度とは、過去にロボットの状態が変化した回数を示す情報である。具体的には、過去において状態情報ＤＢ１１２において状態情報が変更された回数を示す情報である。
【００３４】
また、他の例としては、過去の一定期間内に状態情報が変更された回数を示す情報であってもよい。本実施の形態にかかる状態情報ＤＢ１１２は、特許請求の範囲に記載の変化頻度特定手段に対応する。
【００３５】
状態情報登録部１０４は、既に状態情報ＤＢ１１２に登録した状態情報としての状態変数集合に含まれる状態変数のうち変更のあった状態変数のみを登録すればよい。登録のない状態変数については、既に登録されている状態変数のままの状態であると判断することとする。これにより、処理効率を向上させることができる。
【００３６】
さらに、状態情報ＤＢ１１２は予め初期値を保持してもよい。そして、状態情報登録部１０４は、状態変数が状態情報ＤＢ１１２に保持されている初期値と異なる場合にのみ、異なる状態変数を登録する。状態情報ＤＢ１１２に登録のない状態変数については、初期値の状態であると判断することとする。これにより、処理効率を向上させることができる。
【００３７】
再び説明を図２に戻す。実行指示取得部１２０は、外部から所定のサービスの実行を指示するサービス実行指示を取得する。ロボット検索部１２２は、サービスＤＢ１１０を参照しつつ実行指示取得部１２０が取得したサービス実行指示に対応するサービスを有するロボットを検索する。
【００３８】
サービス呼出条件抽出部１２４は、ロボット検索部１２２が検索したロボットのサービスに対応付けてサービスＤＢ１１０に保持されているサービス呼出条件を抽出する。状態情報抽出部１２６は、ロボット検索部１２２が検索したロボットの状態情報を状態情報ＤＢ１１２から抽出する。
【００３９】
コンセプト変換部１３０は、サービス呼出条件抽出部１２４からサービス呼出条件を取得する。そして、サービス呼出条件に含まれる状態変数集合を記述論理コンセプトに変換する。コンセプト変換部１３０は、また状態情報抽出部１２６から状態情報を取得する。そして、状態情報に含まれる状態変数集合を記述論理コンセプトに変換する。
【００４０】
状態判定部１３２は、サービス呼出条件に対する記述論理コンセプトと、状態情報に対する記述論理コンセプトとに基づいて、ロボットがサービス呼出条件に合致する状態であるか否かの状態判定を行う。このとき、タクソノミーＤＢ１４０に保持されているタクソノミーを参照する。
【００４１】
図５−１および図５−２は、タクソノミーＤＢ１４０が保持しているタクソノミーを模式的に示す図である。タクソノミーとは、アトミックなコンセプト間のつながりを定義したグラフである。すなわち、状態変数間の関係を示すグラフである。なお、本実施の形態にかかるタクソノミーおよびタクソノミーＤＢ１４０は、それぞれ特許請求の範囲に記載の状態変数間関係情報および状態変数間関係情報保持手段に対応する。
【００４２】
例えば、図５−１に示すように、「Drive」は、「Wheel」を含む。さらに、「Wheel」は、「Caterpillar」を含む。このような包摂関係を示す情報がタクソノミーとしてタクソノミーＤＢ１４０に保持されている。
【００４３】
また、図５−２に示すように、「On」と「Off」とは相反する関係にある。このような、相反する関係を示す情報もタクソノミーとしてタクソノミーＤＢ１４０に保持されている。
【００４４】
このように、タクソノミーは、状態変数間の関係を規定している。したがって、状態変数どうしが一致しない場合であっても、タクソノミーを参照することにより、状態変数が実質的に一致するか否かを判定することができる。
【００４５】
例えば、サービス呼出条件として、「Power=On」が規定されているとする。一方、状態情報として、「StandBy=On」が規定されているとする。これらの状態変数は異なっている。しかし、タクソノミーにおいて、「StandBy」は、「On」に包摂されている。したがって、状態情報は、呼び出し条件に合致すると判断できる。
【００４６】
再び説明を図２に戻す。ロボット決定部１３４は、状態判定部１３２の判定結果に基づいて、サービスを実行させるロボットを決定する。実行指示部１３６は、ロボット決定部１３４が決定したロボットに対し、実行指示を送る。なお、本実施の形態にかかるロボット決定部１３４は、特許請求の範囲に記載の実行制御手段に対応する。
【００４７】
図６は、ロボット２０の機能構成を示すブロック図である。ロボット２０は、状態情報保持部２００と、状態情報登録部２０２と、サービス保持部２１０と、サービス登録部２１２と、実行指示取得部２２０と、サービス実行部２２２と備えている。
【００４８】
状態情報保持部２００は、ロボット２０の現在の状態を示す状態情報を保持する。具体的には、状態情報として状態変数集合を保持する。状態情報登録部２０２は、状態情報保持部２００が保持する状態情報としての状態変数集合をオブジェクト管理装置１０に登録する。状態情報登録部２０２は、所定の時間間隔で定期的に状態情報を登録する。
【００４９】
なお、登録のタイミングは任意であり、他の例としては、状態情報抽出部１２６が状態情報を抽出する直前にオブジェクト管理装置１０からの指示により状態情報を登録してもよい。これにより、オブジェクト管理装置１０は、ロボットを選択する直前のロボットの状態に基づいて、適切なロボットを選択することができる。
【００５０】
サービス保持部２１０は、ロボット２０が提供可能なサービスおよびサービス呼出条件を保持している。サービス登録部２１２は、サービス保持部２１０に保持されているサービスおよびサービス呼出条件をオブジェクト管理装置１０に登録する。
【００５１】
実行指示取得部２２０は、オブジェクト管理装置１０から所定のサービスのサービス実行指示を取得する。サービス実行部２２２は、実行指示取得部２２０が取得したサービス実行指示にしたがいサービスを実行する。
【００５２】
図７は、オブジェクト管理装置１０のオブジェクト管理処理を示すフローチャートである。まず、実行指示取得部１２０は外部からサービス実行指示を取得する（ステップＳ１００）。次に、ロボット検索部１２２は、サービスＤＢ１１０に格納されているデータを参照しつつ、サービス実行指示に示されるサービスを実行可能なロボットを検索する（ステップＳ１０２）。次に、ロボット検索部１２２によって特定されたロボットの状態が、サービス実行指示に示されるサービスのサービス呼出条件に合致するか否かを判定する（ステップＳ１０４）。
【００５３】
図８は、ロボットの状態判定処理（ステップＳ１０４）における詳細な処理を示すフローチャートである。サービス呼出条件抽出部１２４は、ロボット検索部１２２が検索したロボットのサービス実行指示に示されるサービスに対する、サービス呼出条件をサービスＤＢ１１０から抽出する（ステップＳ２００）。また、状態情報抽出部１２６は、ロボット検索部１２２が特定したロボットの状態情報を状態情報ＤＢ１１２から抽出する（ステップＳ２０２）。
【００５４】
次に、コンセプト変換部１３０は、サービス呼出条件抽出部１２４が抽出したサービス呼出条件をＤＬコンセプトに変換する。また、状態情報抽出部１２６が抽出した状態情報をＤＬコンセプトに変換する（ステップＳ２０４）。
【００５５】
次に、状態判定部１３２は、呼び出し条件のＤＬコンセプトと、状態変数集合のＤＬコンセプトとを比較することにより、ロボットの状態がサービス呼出条件を満たすか否かを判定する（ステップＳ２０６）。以上で、状態判定処理（ステップＳ１０４）が完了する。
【００５６】
再び説明を図７に戻す。以上の状態判定処理（ステップＳ１０４）を、ロボット検索部１２２が特定したすべてのロボットに対して行う（ステップＳ１０６，Ｙｅｓ）。
【００５７】
これにより、呼び出し条件を満たす状態にある複数のロボットが特定された場合には（ステップＳ１０８，Ｙｅｓ）、ロボット決定部１３４は、このうちから１つのロボットを選択する（ステップＳ１１０）。そして、実行指示部１３６は、ロボット決定部１３４が選択したロボットに対し、サービスの実行指示を出す（ステップＳ１１２）。以上で、オブジェクト管理処理が完了する。
【００５８】
ステップＳ１１０においては、ロボット決定部１３４は、状態情報ＤＢ１１２に格納されている変化頻度、コンセプト間の距離および状態変数の重要度に基づいてロボットを選択する。
【００５９】
具体的には、変化頻度の低いロボットを優先して選択する。頻繁に状態情報が変更されているロボットは、状態情報を取得したタイミングからの時間の経過に伴い、状態情報が既に変更されている可能性が高い。そこで、このようなロボットの優先度を低く設定する。なお、ロボット決定部１３４は、優先度の高いロボットを選択する。
【００６０】
状態情報の変更の頻度が低いロボットは、優先度が高く優先的に選択される。これにより、時間の経過に伴い、ロボットの状態が変化し、ロボットを決定したときには既にロボット呼び出し条件に合致しない状態に変更されているロボットを選択するのを避けることができる。
【００６１】
さらに、ロボット決定部１３４は、タクソノミーにおける状態変数間の距離がより近いロボットを選択する。例えば、タクソノミーＤＢ１４０において、以下に示すタクソノミーが定義されているとする。
Drive⊇Wheel⊇Caterpillar 
ここで、「Drive⊇Wheel」は、「Wheel」は、「Drive」に包摂されることを示す。また、第１ロボット２０ａの状態変数が「Wheel」、第２ロボット２０ｂが「Caterpillar」であるとする。この場合、いずれのロボットロボット２０ａ，２０ｂも「Drive」を満たす。しかし、タクソノミーにおいて、「Caterpillar」は、「Wheel」を介して「Drive」と包含関係を形成している。したがって、「Wheel」のほうが「Drive」との距離が近い。
【００６２】
この場合には、「Wheel」の状態変数を有する第１ロボット２０ａの方が状態変数間の距離が短いと判断する。距離が短いほうのロボットの優先度を高く設定する。これにより、より高い優先度が設定された第１ロボット２０ａが選択される。
【００６３】
タクソノミーにおける距離がより近い状態変数どうしは、その意味がより近い傾向にある。したがって、距離がより近い状態変数に対するロボットを選択することにより、サービス呼出条件により適した状態のロボットを選択することができる。
【００６４】
さらに、例えば、タクソノミーＤＢ１４０において、以下に示すタクソノミーが定義されているとする。
Speak⊇SpeakWithVolume⊇SpeakWithVolumeEnglishOnly
指定された状態が「Speak」であり、第１ロボット２０ａの状態変数が「SpeakWithVolumeEnglishOnly」、第２ロボット２０ｂの状態変数が「SpeakWithVolume」であるとする。この場合、いずれのロボットロボット２０ａ，２０ｂも「Speak」を満たす。しかし、状態変数間の距離は、「SpeakWithVolume」の方が指定された状態である「Speak」に近い。したがって、第２ロボット２０ｂに対し、第１ロボット２０ａに比べて高い優先度を設定し、第２ロボット２０ｂが選択される。
【００６５】
さらに、先に述べた「Drive」に関する条件と「Speak」に関する条件とが並存し、「Drive」に対する優先度は第１ロボット２０ａの方が第２ロボット２０ｂよりも高く設定され、「Speak」に対する優先度は第２ロボット２０ｂの方が第１ロボット２０ａよりも高く設定されたとする。この場合、総合すると２つのロボット２０ａ，２０ｂの優先度は等しくなる。
【００６６】
この場合には、ロボット決定部１３４は、状態変数の重要度がより高いロボットを選択する。すなわち、状態変数間の距離から同順位と判定された場合には、より重要な状態変数に対する優先度に重み付けを行うこととする。
【００６７】
具体的には、「Drive」の重要度を「Speak」の重要度よりも高く設定しておく。この場合には、２つの条件に対する優先度を総合した場合、「Drive」に対する優先度が高い第１ロボット２０ａの優先度が総合的に高くなり、第１ロボット２０ａが選択される。なお、重要度は、サービスＤＢ１１０においてサービス呼出条件として格納されている状態変数に対応付けて保持されているものとする。
【００６８】
以上のように、変更履歴、状態変数間の距離および状態変数の重要度に基づいて、より適切なロボットを選択することができる。
【００６９】
ここで、オブジェクト管理装置１０のより具体的な処理について説明する。第１ロボット２０ａが図３に示すロボットＩＤ「０００１」のサービスおよびサービス呼出条件を有しているとする。また、第２ロボット２０ｂが、図３に示すロボットＩＤ「０００２」のサービスおよびサービス呼出条件を有しているとする。さらに、第１ロボット２０ａおよび第２ロボット２０ｂの状態情報がそれぞれ図４に示すロボットＩＤ「０００１」およびロボットＩＤ「０００２」の状態情報を有しているとする。
【００７０】
このとき、実行指示取得部１２０が以下のフローの実行指示を取得したとする。
move(locationA)
pickup(objectC)
move(locationB)
この場合、ロボット検索部１２２は、サービスＤＢ１１０を参照しつつ「move(location)」をサービスとして有するロボットを検索する（ステップＳ１０２）。
【００７１】
図３に示すように、第１ロボット２０ａおよび第２ロボット２０ｂのいずれも「move(location)」をサービスとして有している。したがって、これら２つのロボット２０ａ，２０ｂが特定される。
【００７２】
次に、サービス呼出条件抽出部１２４は、図３において、第１ロボット２０ａおよび第２ロボット２０ｂそれぞれに対応付けられているサービス呼出条件を抽出する（ステップＳ２００）。また、状態情報抽出部１２６は、図４において、第１ロボット２０ａおよび第２ロボット２０ｂそれぞれに対応付けられている状態情報を抽出する（ステップＳ２０２）。次に、コンセプト変換部１３０は、これらをＤＬコンセプトに変換する（ステップＳ２０４）。
【００７３】
第１ロボット２０ａの状態情報は以下のＤＬコンセプトに変換される。
powerOn ┌┐≦2have.Wheel┌┐∃contain.(Sensor┌┐UrtraSonic)┌┐¬Speak┌┐locate(locationX)
このＤＬコンセプトは、パワーオンの状態であり、２以下のホイールを有しており、超音波センサーを少なくとも１つ有し、音声出力機能を有さず、かつ現在位置がXであることを示している。
【００７４】
第２ロボット２０ｂの状態情報は以下のＤＬコンセプトに変換される。
power.StandBy ┌┐¬have.Legs┌┐∃contain.(Sensor┌┐Infrared)
このＤＬコンセプトは、パワーがスタンバイの状態であり、かつ足を有さず、かつ赤外線センサを少なくとも１つ有していることを示している。
【００７５】
また、第１ロボット２０ａのサービス呼出条件は以下のＤＬコンセプトに変換される。
power.On ┌┐≦4have.Drive┌┐∃contain.Sensor
第２ロボット２０ｂのサービス呼出条件は以下のＤＬコンセプトに変換される。
power.On ┌┐≦2have. Drive
【００７６】
次に、状態判定部１３２は、コンセプト変換部１３０により得られたＤＬコンセプトに基づいて、各ロボットの状態が各ロボットのサービス呼出条件に合致するか否かを判定する（ステップＳ２０６）。
【００７７】
まず、第１ロボット２０ａについての判定を行う。具体的には、第１ロボット２０ａの状態情報のＤＬコンセプトを以下のように分解する。
powerOn
≦2have.Wheel
∃contain. Sensor
∃contain. UrtraSonic
¬Speak
locate(locationX)
また、第１ロボット２０ａのサービス呼出条件を以下のように分解する。
power.On
≦4have.Drive
∃contain.Sensor
【００７８】
次に、状態情報を分解して得られた各項と対になる項を、サービス呼出条件を分解して得られた項から特定する。同一番号が付されている項は、それぞれ対になる項である。
状態情報：
powerOn      ・・・（１）
≦2have.Wheel      ・・・（２）
∃contain. Sensor      ・・・（３）
∃contain. UrtraSonic
¬Speak
locate(locationX)
サービス呼出条件：
power.On      ・・・（１）
≦4have.Drive      ・・・（２）
∃contain.Sensor      ・・・（３）
（１）および（３）の項はいずれも同一の記載であり、等価である。したがって、これらのサービス呼出条件を満たすことがわかる。
【００７９】
また、（２）の項については、２以下は、４以下に包摂される。また、図５−１に示すタクソノミーにより、「Wheel」は、「Drive」に包摂される。以上より、状態情報がサービス呼出条件に包摂される関係にある。したがって、この場合もサービス呼出条件を満たす。以上より、第１ロボット２０ａは、サービス呼出条件を満たす状態にあり、呼び出し可能であると判定される。
【００８０】
次に、第２ロボット２０ｂについての判定を行う。具体的には、第２ロボット２０ｂの状態情報のＤＬコンセプトを以下のように分解する。
power.StandBy
¬have.Legs
∃contain.Sensor
∃contain.Infrared
また、第２ロボット２０ｂのサービス呼出条件を以下のように分解する。
power.On
≦2have. Drive
【００８１】
次に、状態情報とサービス呼出条件それぞれの各項から対になる項を特定する。同一番号が付されている項は、それぞれ対にある項である。
状態情報：
power.StandBy      ・・・（４）
¬have.Legs      ・・・（５）
∃contain.Sensor
∃contain.Infrared
サービス呼出条件：
power.On      ・・・（４）
≦2have. Drive       ・・・（５）
（４）の項については、図５−２に示すタクソノミーにより、「StandBy」は、「On」に包摂される関係にある。したがって、（４）のサービス呼出条件を満たしていることがわかる。また、（５）については包摂および等価のいずれも成立しない。したがって、（５）のサービス呼出条件を満たしていないことがわかる。以上より、第２ロボット２０ｂは、サービス呼出条件を満たす状態になく、呼び出し可能ではないと判定される。
【００８２】
以上の処理により、呼び出し可能なロボットは第１ロボット２０ａの１つのみに特定されたので（ステップＳ１０８，Ｎｏ）、ロボット決定部１３４は、サービスを実行させるべきロボットとして第１ロボット２０ａを選択する。そして、実行指示部１３６は、ロボット２０ａに対し、「move(locationA)」のサービスの実行を指示する（ステップＳ１１２）。
【００８３】
以上の処理により、第１ロボット２０ａに対し、「move(locationA)」のサービスの実行指示が送られる。第１ロボット２０ａは、この実行指示を受け取ったときに、サービス呼出条件を満たす状態にあるので、適切にサービスを実行することができる。
【００８４】
このように、本実施の形態によれば、記述論理を利用してロボットの状態を特定し、適切な状態にあるロボットに所定のサービスを実行させることができる。記述論理においては、論理的には、ロボットの状態判定を確実に行うことができる。また、人手によるルールなどの作成が不要であるという利点も有している。なお、記述論理の詳細については、「 The Description Logic Handbook, Cambridge University Press, 2003」に記載されている。
【００８５】
また、本実施の形態によれば、処理内容の追加変更等が行われる場合であっても、オブジェクト管理装置１０における処理内容を変更するのみでよく、ロボット自体の処理等に変更を加える必要がない。
【００８６】
図９は、実施の形態１に係るオブジェクト管理装置１０のハードウェア構成を示す図である。オブジェクト管理装置１０は、ハードウェア構成として、オブジェクト管理装置１０におけるオブジェクト管理処理を実行するオブジェクト管理プログラムなどが格納されているＲＯＭ５２と、ＲＯＭ５２内のプログラムに従ってオブジェクト管理装置１０の各部を制御するＣＰＵ５１と、オブジェクト管理装置１０の制御に必要な種々のデータを記憶するＲＡＭ５３と、ネットワークに接続して通信を行う通信I／Ｆ５７と、各部を接続するバス６２とを備えている。
【００８７】
先に述べたオブジェクト管理装置１０におけるオブジェクト管理プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フロッピー（Ｒ）ディスク（ＦＤ）、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録されて提供されてもよい。
【００８８】
この場合には、オブジェクト管理プログラムは、オブジェクト管理装置１０において上記記録媒体から読み出して実行することにより主記憶装置上にロードされ、上記ソフトウェア構成で説明した各部が主記憶装置上に生成されるようになっている。
【００８９】
また、本実施の形態のオブジェクト管理プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。
【００９０】
以上、本発明を実施の形態を用いて説明したが、上記実施の形態に多様な変更または改良を加えることができる。
【００９１】
そうした第１の変更例としては、本実施の形態においては、オブジェクト管理装置１０は、３台のロボット２０ａ〜２０ｃを管理したが、１台のロボットのみを対象としてもよい。この場合には、１台のロボットが所定のサービスを実行可能か否かを判定する。また他の例としては、オブジェクト管理装置１０は、３台以上のロボット２０を対象としてもよい。
【００９２】
また本実施の形態においては、オブジェクト管理装置１０は、ロボットを管理したが、オブジェクト管理装置１０の管理対象は、これに限定されるものではない。例えば、Ｗｅｂサーバであってもよく、また例えば、ユビキタスデバイスであってもよい。
【００９３】
また、第２の変更例としては、本実施の形態においては、オブジェクト管理装置１０は、記述論理を利用してロボットの状態情報およびサービス呼出条件に含まれる各状態変数を比較したが、比較するための手法は、これに限定されるものではない。
【００９４】
他の例としては、ルールベース推論や、ベイジアンネットワーク、ニューラルネットワーク、および一階述語論理を利用してもよい。ただし、確実に判定処理を行う観点からは記述論理が好ましい。
【００９５】
また、第３の変更例としては、状態情報ＤＢ１１２は、状態変数を動的状態変数、準動的状態変数および静的状態変数に区別して格納してもよい。図１０は、第３の変更例にかかる状態情報ＤＢ１１２のデータ構成を模式的に示す図である。
【００９６】
第３の変更例にかかる状態情報ＤＢ１１２は、ロボットＩＤに対応付けて、状態情報として、動的状態変数、準動的状態変数および静的状態変数を保持している。ここで、動的状態変数とは、アイドル状態、現在位置、ＣＰＵ負荷など逐次的に変化する状態に関する変数である。準動的状態変数とは、アーム数、センサーの有無などの頻繁には変化しない変数である。また、静的状態変数とは、メーカー名など製造後変更のない変数である。
【００９７】
そして、この場合、状態判定部１３２は、これらの状態変数に基づいて、段階的に状態を判定する。すなわち、変化する可能性の高い動的状態変数がサービス呼出条件を満たすか否かを判定する。そして、動的状態変数がサービス呼出条件を満たさない場合には、ロボットを実行対象から外す。動的状態変数がサービス呼出条件を満たす場合には、さらに準動的状態変数がサービス呼出条件を満たすか否かを判定する。そして、準動的状態変数がサービス呼出条件を満たす場合には、さらに静的状態変数がサービス呼出条件を満たすか否かを判定する。
【００９８】
このように、サービス呼出条件を満たさない可能性の高い動的状態変数から順に処理することにより、処理効率を向上させることができる。
【００９９】
なお、本例においては、状態情報登録部１０４は、ロボットから取得した状態変数をそれぞれ動的状態変数、準動的状態変数および静的状態変数として状態情報ＤＢ１１２に登録する。なお、状態情報登録部１０４が各ロボット２０ａ〜２０ｃから取得する状態情報には、動的状態変数、準動的状態変数および静的状態変数のいずれであるかを示す情報が付与されている。状態情報登録部１０４は、この付与された情報に基づいて状態変数を区別する。ここで、本例にかかる状態情報登録部１０４は、特許請求の範囲に記載の状態変数特定手段に対応する。
【０１００】
（実施の形態２）
次に、実施の形態２にかかるオブジェクト管理システム１について説明する。図１１は、実施の形態２にかかるオブジェクト管理装置１０の機能構成を示すブロック図である。図１１に示すように、オブジェクト管理装置１０は、コンセプト変換部１３０を備えない。オブジェクト管理装置１０は、コンセプト変換を行わない。そして、状態判定処理（ステップＳ１０４）においては、状態判定部１３２は、各状態変数どうしを比較することにより、状態情報がサービス呼出条件を満たすか否かを判定する。なお、本実施の形態にかかる状態判定部１３２は、特許請求の範囲に記載の一致度算出手段および状態判定手段に対応する。
【０１０１】
具体的には、例えば、ロボット２０ａの状態情報が以下の状態変数で示されるとする。
POWER = On      ・・・（１）
WHEEL = 2      ・・・（２）
ULTRA_SONIC = True
SPEAK = n/a
LOCATION = tokyo
また、サービス呼出条件が以下の状態変数で示されるとする。
POWER = On      ・・・（１）
WHEEL = 2      ・・・（２）
【０１０２】
この場合、（１）および（２）は一致する。すなわち部分的に一致する。そこで、ロボットの状態情報はサービス呼出条件を満たすと判定する。このように、各状態変数どうしを比較することにより状態情報がサービス呼出条件を満たすか否かを判定することができる。
【０１０３】
複数の状態変数のうちいくつの状態変数が一致した場合にサービス呼出条件を満たすと判定するかは予め設定しておくことができる。そして、予め設定した数の状態変数が一致する場合に、状態情報がサービス呼出条件を満たすと判断する。すなわち、一致度を予め設定しておき、実際の一致度が予め設定された値以上である場合に、状態情報がサービス呼出条件を満たすと判断する。
【０１０４】
また、同義語の関係にある状態変数を予め登録しておいてもよい。これにより、異なる状態変数であっても、同義語の関係にある場合には、一致すると判定することができる。
【０１０５】
実施の形態２にかかるオブジェクト管理システム１のこれ以外の構成および処理は、実施の形態１にかかるオブジェクト管理システム１の構成および処理と同様である。
【０１０６】
また、実施の形態１の第３の変更例において説明したように、状態情報ＤＢ１１２が動的状態変数、準動的状態変数および静的状態変数を区別して保持している場合には、状態判定部１３２は、まず動的状態変数とサービス呼出条件に含まれる状態変数とを比較する。そして、一致度が所定の値未満である場合には状態情報はサービス呼出条件に合致しないと判定する。一致度が所定の値以上である場合には、さらに準動的状態変数とサービス呼出条件に含まれる状態変数とを比較する。
【０１０７】
また他の例としては、オブジェクト管理システム１は、ロボットの状態ごとにラベル名を付与し、ラベル名に基づいてロボットの状態を特定してもよい。具体的には、オブジェクト管理装置１０の状態情報ＤＢ１１２は、状態情報として所定の状態を示すラベル名を保持する。また、サービスＤＢ１１０は、サービス呼出条件として所定の状態を示すラベル名を保持する。そして、ラベル名が一致するか否かによりロボットの状態がサービス呼出条件に合致するか否かを判定する。
【０１０８】
この場合、各ロボット２０ａ〜２０ｃの状態情報保持部２００は、ロボットの状態を示すラベル名を保持する。また、サービス保持部２１０は、サービス呼出条件として、所定の状態を示すラベル名を保持する。
【０１０９】
例えば、ロボット２０ａの現在の状態を示すラベル名が「IDOL」であるとする。また、サービス呼出条件であるラベル名が「IDOL」であるとする。この場合、各ラベル名が一致するので、サービス呼出条件を満たすと判定される。なお、各ラベル名が一致すると判定するための条件は任意に設定可能である。例えば、文字列が部分的に一致した場合には、ラベル名が一致すると判定することとしてもよい。さらに、文字列のうち所定の部分が一致した場合に、ラベル名が一致すると判定することとしてもよい。また、文字列のうち所定の割合の部分が一致した場合に、ラベル名が一致すると判定することとしてもよい。また、同義語の関係にあるラベル名を予め登録しておいてもよい。これにより異なるラベル名であっても、同義語の関係にある場合には、一致すると判定することができる。
【０１１０】
このように、ロボットの状態にラベル名を付与することにより、ラベル名に基づいて各ロボットの状態を特定することができる。
【図面の簡単な説明】
【０１１１】
【図１】実施の形態１にかかるオブジェクト管理システム１の全体構成を示す図である。
【図２】オブジェクト管理装置１０の機能構成を示すブロック図である。
【図３】サービスＤＢ１１０のデータ構成を模式的に示す図である。
【図４】状態情報ＤＢ１１２のデータ構成を模式的に示す図である。
【図５−１】タクソノミーＤＢ１４０が保持しているタクソノミーを模式的に示す図である。
【図５−２】タクソノミーＤＢ１４０が保持しているタクソノミーを模式的に示す図である。
【図６】ロボット２０の機能構成を示すブロック図である。
【図７】オブジェクト管理装置１０のオブジェクト管理処理を示すフローチャートである。
【図８】ロボットの状態判定処理（ステップＳ１０４）における詳細な処理を示すフローチャートである。
【図９】実施の形態１に係るオブジェクト管理装置１０のハードウェア構成を示す図である。
【図１０】第３の変更例にかかる状態情報ＤＢ１１２のデータ構成を模式的に示す図である。
【図１１】実施の形態２にかかるオブジェクト管理装置１０の機能構成を示すブロック図である。
【符号の説明】
【０１１２】
１  オブジェクト管理システム
１０  オブジェクト管理装置
２０ａ〜２０ｃ  ロボット
５１  ＣＰＵ
５２  ＲＯＭ
５３  ＲＡＭ
５７  通信I／Ｆ
６２  バス
１０２  サービス登録部
１０４  状態情報登録部
１１０  サービスＤＢ
１１２  状態情報ＤＢ
１２０  実行指示取得部
１２２  ロボット検索部
１２４  サービス呼出条件抽出部
１２６  状態情報抽出部
１３０  コンセプト変換部
１３２  状態判定部
１３４  ロボット決定部
１３６  実行指示部
１４０  タクソノミーＤＢ
２００  状態情報保持部
２０２  状態情報登録部
２１０  サービス保持部
２１２  サービス登録部
２２０  実行指示取得部
２２２  サービス実行部
【図１】
2006277120.tif 000003
【図２】
2006277120.tif 000004
【図３】
2006277120.tif 000005
【図４】
2006277120.tif 000006
【図５−１】
2006277120.tif 000007
【図５−２】
2006277120.tif 000008
【図６】
2006277120.tif 000009
【図７】
2006277120.tif 000010
【図８】
2006277120.tif 000011
【図９】
2006277120.tif 000012
【図１０】
2006277120.tif 000013
【図１１】
2006277120.tif 000014