(57)【要約】【課題】利用者の意図を効率よく認識することのできるイベント管理装置、及び方法を提供する。【解決手段】イベントを取得するイベント取得部と、確認可能な事実と、確認不要な事実とを記憶する信念ＤＢと、取得したイベントに応じたプランを作成する通常・割込プラン作成部と、作成したプラン毎に、確認可能な事実及び確認不要な事実を使用してアクションを実行する通常・割込アクション実行部と、実行したアクション情報を履歴として記憶するアクション履歴ＤＢとを備え、イベント取得部がアクションの確認処理を要求する割込イベントを取得した場合に、通常・割込プラン作成部がアクション履歴ＤＢに記憶されたアクション情報で使用された確認可能な事実が適切か否かを利用者に確認する割込プランを作成し、通常・割込アクション実行部は作成された割込プランに従ってアクションを実行し、当該実行結果に応じて確認可能な事実の更新を行う。【選択図】        図５
2009015493.tif 000002
【特許請求の範囲】
【請求項１】
利用者の要求を示す通常目標情報を記憶する通常目標記憶部と、
利用者の意図したとおりに処理が行われていないことに対する利用者の反応に応じて変更可能な状況情報を示す可変状況情報と、前記利用者の反応に応じて変更を行わない状況情報を示す不変状況情報と、を記憶する状況情報記憶部と、
前記通常目標情報に応じたアクションである、前記可変状況情報と前記不変状況情報のうちいずれか一つ以上を使用して処理を行う通常アクションの実行順序を示す通常プランを作成する通常プラン作成部と、
作成された前記通常プラン毎に、前記実行順序に従って、前記通常アクションを実行する通常アクション実行部と、
実行された前記通常アクションの履歴を記憶するアクション履歴記憶部と、
前記通常アクション毎に、当該通常アクションが実行時に使用する前記可変状況情報のを対応付けたアクション対応情報を記憶するアクション情報記憶部と、
前記アクション履歴記憶部に記憶されている前記通常アクション毎に、当該通常アクションに対応付けられている前記可変状況情報を前記アクション対応情報記憶部から抽出し、抽出した前記可変状況情報が適切か否かの確認を利用者に対して要求する確認要求アクションを作成する割込プラン作成部と、
前記確認要求アクションを前記通常アクションに割り込んで実行する確認要求アクション実行部と、
実行された前記確認要求アクションにより利用者から前記可変状況情報が適切でないことを示す情報が入力された場合に、前記状況情報記憶部に記憶されている、前記確認要求アクションの確認対象である前記可変状況情報を更新する更新部と、
を備えたことを特徴とするアクション実行装置。
【請求項２】
前記アクション履歴記憶部は、前記通常アクション実行部による前記通常アクションの実行が完了した順序に従って履歴を記憶し、
前記割込プラン作成部は、さらに、前記アクション情報記憶部を参照し、新しい前記通常アクションから順に、当該通常アクションに対応付けられている前記可変状況情報の確認を要求する前記確認要求アクションを実行するように実行順序を設定すること、
を特徴とする請求項１に記載のアクション実行装置。
【請求項３】
外界を監視し、当該外界から取得した情報を解釈して状況情報を取得する外界監視部と、
前記確認要求アクション実行部が前記確認要求アクションを前記通常アクションに割り込んで実行する場合に、前記状況情報記憶部により保持している前記可変状況情報を、前記外界監視部に通知する通知部と、をさらに備え、
前記状況情報記憶部は、前記外界監視部が取得した前記状況情報を、前記可変状況情報として保持し、
前記外界監視部は、前記通知部から前記可変状況情報が通知された場合に、通知された前記可変状況情報以外の前記状況情報を取得するように、前記外界から取得した情報を解釈すること、
を特徴とする請求項１又は２に記載のアクション実行装置。
【請求項４】
前記通常アクション実行部は、前記確認要求アクション実行部が前記確認要求アクションを前記通常アクションに割り込んで実行する場合に、作成された前記通常プラン毎の前記通常アクションの実行を中断し、
前記通常プラン作成部は、前記更新部により前記可変状況情報が更新された後、前記通常アクション実行部が中断した前記通常アクションを含む前記通常プランの再作成を行い、
前記通常アクション実行部は、更新後の前記可変状況情報を使用して、再作成された前記通常プラン毎の前記通常アクションを実行すること、
を特徴とする請求項１乃至３のいずれか一つに記載のアクション実行装置。
【請求項５】
前記アクション実行部により、作成された前記通常プランの毎の全ての通常アクションの実行が終了した場合に、前記アクション履歴記憶部が記憶する前記アクション情報を削除する削除部をさらに備えることを特徴とする請求項１乃至４のいずれか一つに記載のアクション実行装置。
【請求項６】
利用者の要求を示す通常目標情報を通常目標記憶部に記憶する通常目標記憶ステップと、
利用者の意図したとおりに処理が行われていないことに対する利用者の反応に応じて変更可能な状況情報を示す可変状況情報と、前記利用者の反応に応じて変更を行わない状況情報を示す不変状況情報と、を状況情報記憶部に記憶する状況情報記憶ステップと、
前記通常目標情報に応じたアクションである、前記可変状況情報と前記不変状況情報のうちいずれか一つ以上を使用して処理を行う通常アクションの実行順序を示す通常プランを作成する通常プラン作成ステップと、
作成された前記通常プラン毎に、前記実行順序に従って、前記通常アクションを実行する通常アクション実行ステップと、
実行された前記通常アクションの履歴をアクション履歴記憶部に記憶するアクション履歴記憶ステップと、
前記通常アクション毎に、当該通常アクションが実行時に使用する前記可変状況情報を対応付けたアクション対応情報をアクション情報記憶部に記憶するアクション情報記憶ステップと、
前記アクション履歴記憶部に記憶されている前記通常アクション毎に、当該通常アクションに対応付けられている前記可変状況情報を前記アクション対応情報記憶部から抽出し、抽出した前記可変状況情報が適切か否かの確認を利用者に対して要求する確認要求アクションを作成する割込プラン作成ステップと、
前記確認要求アクションを前記通常アクションに割り込んで実行する確認要求アクション実行ステップと、
実行された前記確認要求アクションにより利用者から前記可変状況情報が適切でないことを示す情報が入力された場合に、前記状況情報記憶部に記憶されている、前記確認要求アクションの確認対象である前記可変状況情報を更新する更新ステップと、
を有することを特徴とするアクション実行方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクション実行装置、及び方法に関するものである。
【背景技術】
【０００２】
従来、音声検出技術の向上に伴い、利用者との対話をトリガーとして処理を行う様々な装置が提案されている。このような装置では、利用者が発した音声の認識処理を行うことで、利用者が当該装置に対する指示を認識することができる。そして、当該装置では、利用者からの指示を認識した後、音声出力で次の指示を促したり、処理内容等の提示を行う。このように利用者と当該装置の間で音声による対話プランが行われることになる。しかしながら、音声認識率が１００パーセントでない以上、対話プラン中に誤認識が生じることになる。
【０００３】
このような装置の対話プラン中に誤認識が生じた場合に、誤認識が生じた箇所を特定すると共に、当該誤認識の箇所を修正するのは難しい。
【０００４】
例えば、特許文献１に記載された技術では、装置と利用者との間で対話を行った後、装置の認識が誤りと判断した場合、入力毎に音声コマンドの確認を行うか、最初から音声入力するかを判断した後、いずれかの処理を行うことで誤りを訂正している。これにより誤認識が生じた場合に訂正するための労力の低減を図っている。
【０００５】
【特許文献１】特開２００４−２７１９０９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、装置が処理を行う場合、利用者に入力された指示のみならず、当該装置に格納されている情報を用いて処理を行うことが多い。特許文献１に記載された技術を適用すると、当該装置に格納されている情報についても利用者に全て確認を行うことになり、利用者の確認負担が増大するという問題がある。
【０００７】
本発明は、上記に鑑みてなされたものであって、利用者の意図を効率よく認識することのできるイベント管理装置、及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するために、本発明にかかるアクション実行装置は、利用者の要求を示す通常目標情報を記憶する通常目標記憶部と、利用者の意図したとおりに処理が行われていないことに対する利用者の反応に応じて変更可能な状況情報を示す可変状況情報と、前記利用者の反応に応じて変更を行わない状況情報を示す不変状況情報と、を記憶する状況情報記憶部と、前記通常目標情報に応じたアクションである、前記可変状況情報と前記不変状況情報のうちいずれか一つ以上を使用して処理を行う通常アクションの実行順序を示す通常プランを作成する通常プラン作成部と、作成された前記通常プラン毎に、前記実行順序に従って、前記通常アクションを実行する通常アクション実行部と、実行された前記通常アクションの履歴を記憶するアクション履歴記憶部と、前記通常アクション毎に、当該通常アクションが実行時に使用する前記可変状況情報のを対応付けたアクション対応情報を記憶するアクション情報記憶部と、前記アクション履歴記憶部に記憶されている前記通常アクション毎に、当該通常アクションに対応付けられている前記可変状況情報を前記アクション対応情報記憶部から抽出し、抽出した前記可変状況情報が適切か否かの確認を利用者に対して要求する確認要求アクションを作成する割込プラン作成部と、前記確認要求アクションを前記通常アクションに割り込んで実行する確認要求アクション実行部と、実行された前記確認要求アクションにより利用者から前記可変状況情報が適切でないことを示す情報が入力された場合に、前記状況情報記憶部に記憶されている、前記確認要求アクションの確認対象である前記可変状況情報を更新する更新部と、を備えたことを特徴とする。
【０００９】
また、本発明にかかるアクション実行方法は、利用者の要求を示す通常目標情報を通常目標記憶部に記憶する通常目標記憶ステップと、利用者の意図したとおりに処理が行われていないことに対する利用者の反応に応じて変更可能な状況情報を示す可変状況情報と、前記利用者の反応に応じて変更を行わない状況情報を示す不変状況情報と、を状況情報記憶部に記憶する状況情報記憶ステップと、前記通常目標情報に応じたアクションである、前記可変状況情報と前記不変状況情報のうちいずれか一つ以上を使用して処理を行う通常アクションの実行順序を示す通常プランを作成する通常プラン作成ステップと、作成された前記通常プラン毎に、前記実行順序に従って、前記通常アクションを実行する通常アクション実行ステップと、実行された前記通常アクションの履歴をアクション履歴記憶部に記憶するアクション履歴記憶ステップと、前記通常アクション毎に、当該通常アクションが実行時に使用する前記可変状況情報を対応付けたアクション対応情報をアクション情報記憶部に記憶するアクション情報記憶ステップと、前記アクション履歴記憶部に記憶されている前記通常アクション毎に、当該通常アクションに対応付けられている前記可変状況情報を前記アクション対応情報記憶部から抽出し、抽出した前記可変状況情報が適切か否かの確認を利用者に対して要求する確認要求アクションを作成する割込プラン作成ステップと、前記確認要求アクションを前記通常アクションに割り込んで実行する確認要求アクション実行ステップと、実行された前記確認要求アクションにより利用者から前記可変状況情報が適切でないことを示す情報が入力された場合に、前記状況情報記憶部に記憶されている、前記確認要求アクションの確認対象である前記可変状況情報を更新する更新ステップと、を有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、通常目標情報に応じて実行済のアクションに対応する可変状況情報が適切か否かを利用者に確認するプランを作成することで、利用者の意図を効率よく認識することが可能という効果を奏する。
【発明を実施するための最良の形態】
【００１１】
以下に、本発明にかかるアクション実行装置、方法の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。以下、アクション実行装置をプラン実行システムの一部に適用した例を示す。
【００１２】
（第１の実施の形態）
第１の実施の形態にかかるプラン実行システム１は、利用者との対話によりプランを作成し、作成されたプランの実行を管理する。図１に示すように、プラン実行システム１は、外界監視部１０と、イベント対応部２０と、プランニングエージェント３０と、通常・割込アクション実行部４０とを備えている。外界監視部１０、イベント対応部２０およびプランニングエージェント３０は、本実施の形態においては一つの装置内に格納されている。なお、このように一つの装置内に格納することに限定するものではなく、インターネット等で結合された複数のコンピュータ上に実装してもよい。
【００１３】
外界監視部１０は、外界環境を監視する。具体的には、外界環境として外界監視部１０の外部から得られる情報を監視する。さらに、外界監視部１０は、外界監視部１０自身に記録されている情報を参照する。そして、監視結果が予め定められている条件を満たした場合には、イベントを発行する。そして、このイベントをイベント対応部２０に通知する。ここで、イベントは、監視結果が予め定められている所定の条件を満たしていることを示す情報である。
【００１４】
外界監視部１０はまた、イベント対応部２０から通知指示を取得する。通知指示とは、外界監視部１０におけるイベント発行に関する指示である。例えば利用者から発せられた音声を検出し、利用者から所定の音声コマンドを検出した場合に、条件を満たしたと判断し、イベント対応部２０にイベントを通知する。通知指示には、この他、外界監視部１０のオンオフ、必要なイベントの種類、イベント発行のための条件、イベント発行の頻度などの情報が含まれている。
【００１５】
なお、外界監視部１０が外部から得られる情報としては、例えば、マイクから得られる音声情報、カメラから得られる画像情報等が考えられる。
【００１６】
また、内部に記録されている情報としては、音声認識に必要な音声情報、音声によるコマンド認識に必要なコマンド情報等がある。
【００１７】
イベント対応部２０は、外界監視部１０から取得した外部イベントに基づいて、次に行うべき処理内容を特定する。ここで、処理内容としては、外界監視部１０への通知指示の送信、後述するプランニングエージェント３０へのゴールの投入、およびプランニングエージェント３０の信念ＤＢ５０１の更新がある。
【００１８】
ここで、信念とは、プランニングエージェント３０に関する現在の状況を示す情報である。また、ゴールとは、実行完了したいタスクまたは達成したい状態等を示すものである。
【００１９】
さらに、イベント対応部２０は、プランニングエージェント３０からプランニングエージェント３０によるプランの実行がどのような実行状態にあるかを示す内部イベントを取得する。この場合、イベント対応部２０は内部イベントに基づいて処理内容を特定する。
【００２０】
プランニングエージェント３０は、イベント対応部２０から投入されたゴールに基づいて、複数のアクションを含むプラン群を作成する。図２に示すように、ゴールは、１又は２以上のプランを実行することで達せられるものとする。そして、各プランは、ゴールを達成するための１または２以上の処理であるアクションの実行順序を保持している。すなわち、ゴールに応じて作成されるものである。プランニングエージェント３０は、プランに含まれるアクションの実行指示を通常・割込アクション実行部４０に通知する。プランニングエージェント３０はまた、通常・割込アクション実行部４０からアクションの実行結果を受け取り、実行結果に応じてアクションの実行を管理する。また、アクションの実行状態に応じた内部イベントをイベント対応部２０に通知する。
【００２１】
通常・割込アクション実行部４０は、プランニングエージェント３０からの指示に従ってアクションを実行または中断する。そして、実行結果（成功・失敗・中断）をプランニングエージェント３０に通知する。なお、アクションは、通常アクション及び割込アクションを含むものとする。これらアクションの説明については後述する。
【００２２】
図３に示すように、イベント対応部２０は、イベントルールＤＢ３０１と、外部イベント取得部３０２と、内部イベント取得部３０４と、条件判定部３０５と、処理内容抽出部３０６と、通知部３０７とを有している。外部イベント取得部３０２は、外界監視部１０から通知された外部イベントを取得する。内部イベント取得部３０４は、プランニングエージェント３０から内部イベントを取得する。内部イベントとしては、具体的には、アクション実行の開始を示す開始イベントやアクション実行の終了を示す終了イベントがある。
【００２３】
イベントルールＤＢ３０１は、イベントルールを格納している。イベントルールにおいては、イベントと、実行条件と、処理内容とが対応付けられている。ここで、イベントとして具体的には、外界監視部１０により発行される外部イベントまたはプランニングエージェント３０により発行される内部イベントを識別するイベント識別情報が格納されている。また、実行条件とは、後述するプランニングエージェント３０が保持している信念ＤＢ５０１の事実に関する情報である。事実とは、プラン実行システム１で行われた処理の状況、又は外部の環境などの状況を示すデータとする。
【００２４】
また、外部イベントと処理内容とを対応付けたイベントルールの例としては、「利用者から音声入力された場合に、当該音声で示された目的地に移動するためのナビゲーションを開始する」など、外部イベントの処理内容を行うための条件として格納している。内部イベントと処理内容とを対応付けたイベントルールの例としては、例えば、「ナビゲーションが終了した場合に、利用者から音声による目的地の入力の受付を開始する」などがある。
【００２５】
イベントルールは、具体的には、
ｅｖｅｎｔ（Ｅ，［Ｃ１，…Ｃｎ］，［Ｒ１，…Ｒｍ］）
の形をしている。ここで、Ｅはイベント識別情報を示している。Ｃ１，…Ｃｎは、実行条件である。Ｒ１，…Ｒｍは処理内容である。
【００２６】
このイベントルールは、イベント識別情報Ｅで示されるイベントが通知されたときに、これらの実行条件Ｃ１，…Ｃｎが全て成り立っている（つまり、発火条件が成り立つ）ならば、Ｒ１から順にＲｍまでの処理を順に行うことにより、イベント処理を行うことを意味している。
【００２７】
ここで、Ｒ１，…Ｒｍはいずれも、外界監視部１０、イベント対応部２０またはプランニングエージェント３０のうちいずれかの操作である。具体的には、プランニングエージェント３０の信念ＤＢ５０１の更新、プランニングエージェント３０への割込ゴール投入、プランニングエージェント３０への通常ゴール投入、プランニングエージェント３０への割込プランチェック命令、外界監視部１０のスイッチ・オン（イベント発行の条件付き）、外界監視部１０のスイッチ・オフ、イベント要求（要求するイベントの条件付き）等がある。なお、割込ゴールとは、実行された通常アクションの確認処理を要求するために、実行中の通常アクションを中断し、優先的に達成すべきゴールであり、換言すれば割込目標情報に相当する。通常ゴールとは、利用者の要求を示すゴールであって、プランニングエージェント３０が取得した順序に従って処理すべきゴールであり、換言すれば通常目標情報に相当する。
【００２８】
図４に示すイベントルールの例では、イベントルールの符号４０１に記載された部分にイベント識別情報が設定され、符号４０２に記載された部分に実行条件が設定され、符号４０３に記載された部分に処理内容（例えば、実行するアクション）が設定されている。なお、符号４０２には実行条件が設定されていないため、符号４０１に設定されたイベントを取得した場合に、符号４０３に示された処理内容が実行される。
【００２９】
図３に戻り、条件判定部３０５は、外部イベント取得部３０２が外部イベントを取得した場合や内部イベント取得部３０４が内部イベントを取得した場合には、イベントルールＤＢ３０１のイベントルールにおいて取得したイベントに対応付けられている実行条件を抽出する。そして、後述するプランニングエージェント３０の信念ＤＢ５０１から取得した信念を参照し、現在の状況が実行条件を満たしているか否かを判断する。
【００３０】
なお、イベントルールＤＢ３０１のイベントルールは、イベントと処理内容とを対応付けていればよく、実行条件は必ずしも必須ではない。現在の状況にかかわらずイベントが発行した場合にはかならず所定の処理を行うような場合には、実行条件は不要である。この場合には、条件判定部３０５は、条件を満たすと判断すればよい。
【００３１】
処理内容抽出部３０６は、処理対象となるイベントが実行条件を満たす場合には、イベントルールＤＢ３０１においてイベントに対応付けられている処理内容を抽出する。通知部３０７は、この処理内容に応じた処理を行う。ここで、処理内容としては、例えば、外界監視部１０への指示の通知やプランニングエージェント３０へのゴール投入指示の通知などがある。
【００３２】
図５に示すように、プランニングエージェント３０は、信念ＤＢ５０１と、プラン群スタック５０３と、アクション情報ＤＢ５０４と、アクション履歴ＤＢ５０５と、通常・割込ゴール取得部５０６と、ゴールキュー５０７と、通常・割込プラン作成部５０８と、アクション管理部５１０と、内部イベント通知部５１１と、更新部５０９とを有している。通常・割込ゴール取得部５０６は、イベント対応部２０からゴール指示を取得する。ゴールキュー５０７は、通常・割込ゴール取得部５０６が取得したゴール指示に示されるゴールを格納する。
【００３３】
信念ＤＢ５０１は、アクションの実行に使用する事実を格納している。この事実が処理等の状況を示すデータである以上、信念ＤＢ５０１は換言すれば状況情報記憶部に相当する。また、格納している事実は、２種類存在する。一方は、利用者の意図したとおりに処理が行われていないことに対する利用者の反応に応じて変更を行わない、つまり、誤認識が生じた場合に利用者に対して確認不要な事実であり、換言すれば不変状況情報に相当する。他方は、利用者の反応に応じて変更可能、つまり、誤認識が生じた場合に利用者に対して確認を行うことが可能な事実であり、換言すれば可変状況情報に相当する。
【００３４】
図６に示すように、信念ＤＢ５０１は、誤認識が生じた場合に利用者に対して確認不要な事実をｂｅｌｉｅｆの括弧内に保持し、誤認識が生じた場合に利用者に対して確認を行うことが可能な事実をａｓｋａｂｌｅＢｅｌｉｅｆの括弧内に保持する。また、本実施の形態にかかる信念ＤＢ５０１では、確認不要な事実と確認を行うことが可能な事実とをまとめて保持しているが、確認可能な事実と、確認不要な事実とをそれぞれ別の記憶手段に記憶しても良い。なお、当該情報を使用した処理については後述する。
【００３５】
通常・割込プラン作成部５０８は、信念ＤＢ５０１を参照し、当該信念ＤＢ５０１に格納されている確認可能な事実と確認不要な事実とを用いて実行されるアクションの順序を含むプランを作成する。また、通常・割込プラン作成部５０８が生成するプランのうち、割込ゴールを達成するために生成されたプランを割込プラン、通常ゴールを達成するために生成されたプランを通常プランとする。
【００３６】
プラン群スタック５０３は、通常・割込プラン作成部５０８により作成されたプランを格納する。図７に示すように、プラン群スタック５０３には、ゴール毎に作成されたプラン群を格納している。そして、後述するアクション管理部５１０は、優先度の高いプラン群に従ってアクションの実行を通常・割込アクション実行部４０に指示する。
【００３７】
また、通常・割込アクション実行部４０が実行するアクションのうち、通常プランに従って実行されるアクションを通常アクション、割込プランに従って実行されるアクションを割込アクションとする。この割込アクションは、通常アクションに割り込んで実行されるアクションである。この割込アクションには、信念ＤＢ５０１に格納されている確認可能な事実に対して適切か否かの確認を行う確認要求アクションが含まれている。つまり、通常・割込アクション実行部４０は、換言すれば確認要求アクション実行部としての機能も有する。
【００３８】
なお、本実施の形態においては、通常ゴール及び割込ゴールを一つのゴールキュー５０７に格納することで、通常・割込プラン作成部５０８で通常プラン及び割込プランを作成することとした。本実施の形態は、このような構成に限定するものではなく、通常プランを作成する通常プラン作成部と、割込プランを作成する割込プラン作成部とを別の構成としても良い。この場合は通常・割込アクション実行部４０についても同様に、通常アクションを実行する通常アクション実行部と、割込のアクションを実行する割込アクション実行部とを別の構成としても良い。
【００３９】
アクション情報ＤＢ５０４は、アクション毎に、アクションの実行時に使用される事前条件と、事前条件が成立したときに行う処理が記述されたアクションルールを保持している。アクションの事前条件には、確認可能な事実及び確認不要な事実のいずれか一方以上が設定されている。これら確認可能な事実及び確認不要な事実のいずれか一方以上が信念ＤＢ５０１に適切に格納されている場合に、事前条件を満足していると判断される。なお、アクションルールは、プログラミング言語Ｐｒｏｌｏｇの形式で記述されていが、他の形式で記述しても良い。なお、当該アクションルールにおいて、英大文字で始まる英数文字列は、変数とみなされる。
【００４０】
このような事前条件の情報は、アクション情報ＤＢ５０４に記録されており、具体的には、図２１で示されるアクションルールが記録されている。ここで、アクションルールは、具体的には、
ａｃｔｉｏｎ（Ａｃｔｉｏｎ，［Ｃ１，…Ｃｎ］，［Ｅ１，…Ｅｍ］）
の形をしている。ここで、Ａｃｔｉｏｎはアクション名を示している。Ｃ１，…Ｃｎは、事前条件である。Ｅ１，…Ｅｍはアクションが行われたことに伴う事実関係の変更処理であり、信念ＤＢ５０１が保持している事実の変更処理である。つまり、アクション（Action）のn個の事前条件（Ｃ１，…，Ｃｎ）が全て成立したときに、ｍ個の事実関係（Ｅ１，…、Ｅｍ）が変更されることを示している。また、Ｅ１，…Ｅｍで示される事実関係の変更内容は、ｉｎｉｔｉａｔｅｓ（Ｆ）、ｉｎｉｔｉａｔｅｓＡｓｋａｂｌｅ（Ｆ）、又はｔｅｒｍｉｎａｔｅｓ（Ｆ）のいずれかの形式を有している。
【００４１】
ｉｎｉｔｉａｔｅｓ（Ｆ）は、利用者に確認を行う必要のない事実Ｆが成立するようになることを示し、信念ＤＢ５０１にｂｅｌｉｅｆ（Ｆ）が登録される。また、ｉｎｉｔｉａｔｅｓＡｓｋａｂｌｅ（Ｆ）は、利用者に確認可能な事実Ｆが成立するようになることを示し、信念ＤＢ５０１にａｓｋａｂｌｅＢｅｌｉｅｆ（Ｆ）が登録される。
【００４２】
ｔｅｒｍｉｎａｔｅｓ（Ｆ）は、事実Ｆが成立しなくなることを示し、ｂｅｌｉｅｆ（Ｆ）又はａｓｋａｂｌｅＢｅｌｉｅｆ（Ｆ）が信念ＤＢ５０１から削除される。
【００４３】
アクション管理部５１０は、プラン群スタック５０３に格納されているプランを読み出し、プランに含まれているアクションの実行指示を通常・割込アクション実行部４０に通知する。その後、アクション管理部５１０は、通常・割込アクション実行部４０から実行結果を受け取る。さらに、アクション管理部５１０は、実行したアクションを履歴として、アクション履歴ＤＢ５０５に登録する。また、アクション管理部５１０は、ゴールを達成した場合、当該ゴールを達成するために行ったアクションの履歴を、アクション履歴ＤＢ５０５から削除する。
【００４４】
アクション履歴ＤＢ５０５は、通常・割込アクション実行部４０が実行したアクションの履歴を記憶する。図８に示すように、アクション履歴ＤＢ５０５には、実行順にアクション履歴が格納されている。
【００４５】
図５に戻り、内部イベント通知部５１１は、アクション管理部５１０によるアクションの実行指示を通知した際にアクション開始を示す開始イベントをイベント対応部２０に通知する。また、アクション管理部５１０がアクション実行の成功を示す実行結果を受け取った際にアクション終了を示す終了イベントを通知する。なお、アクション実行の中断を示す実行結果を受け取った場合にも終了イベントを通知する。
【００４６】
更新部５０９は、アクション管理部５１０からの指示、イベント対応部２０および通常・割込アクション実行部４０からの信念更新指示にしたがい、信念ＤＢ５０１およびプラン群スタック５０３を更新する。プラン群スタック５０３を更新した結果、実行中のアクションを実行する必要がなくなった場合には、アクション管理部５１０は、アクションの中断を通常・割込アクション実行部４０に通知する。
【００４７】
次に、上述したプラン実行システム１を、カー・ナビゲーション・システムに適用した例について説明する。当該カー・ナビゲーション・システムにおいては、利用者と対話により目的地を特定し、ナビゲーションを開始する。
【００４８】
図９に示す例では、音声コマンド認識を行う外界監視部１０は、利用者の「たてやまえき」から目的地を富山地方鉄道立山線の立山駅と解釈する。また、外界監視部１０は、「とうちゃくじこく」から、目的地までの予想到着時刻をユーザは知りたいと解釈する。
【００４９】
この解釈に従い、プラン実行システム１は、ルートの作成に必要な事前条件（事実）を設定する。プラン実行システム１は、信念ＤＢ５０１に「（確認可能な事実である）目的地を立山駅」に設定する。また、プラン実行システム１は、「到着時刻を知りたい」を信念ＤＢ５０１に設定する。
【００５０】
また、ルート検索条件（例えば、一般道優先か高速優先か）は、利用者からユーザから指定されていないが、プラン実行システム１は、デフォルト設定である高速優先と判断することにする。そこで、プラン実行システム１は、「（確認可能な事実である）高速優先」を設定する。
【００５１】
その後、プラン実行システム１は、事前条件を満たした場合に「ルートを作成・表示」する。なお、「ルート検索条件」とは「高速優先」か否かとする。そして、当該処理を行ったあと、信念ＤＢ５０１には、「（確認の必要のない事実である）ルート作成済」が設定される。
【００５２】
そして、プラン実行システム１は、作成された「ルート上の注意事項を読み上げる」と共に、「到着予想時刻を読み上げる」。特に問題が生じていなければ、プラン実行システム１は、その後案内を開始する。
【００５３】
次に、上述した処理を、図１に示した構成に従って説明する。まず、外界監視部１０は、各種設定とナビゲーション開始のトリガーとなる外部イベントを、イベント対応部２０に通知する。この通知される外部イベントは、
ｃｏｍｍａｎｄ（ｎａｖｉｇａｔｅ  ｄｅｓｔｉｎａｔｉｏｎ（‘立山駅’,’富山地方鉄道立山線’)，ａｒｒｉｖａｌＴｉｍｅ（ｎｅｃｅｓｓａｒｙ），ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ），）
とする。
【００５４】
そして、イベント対応部２０は、外部イベントが通知された場合、イベントルールに従って、処理を行うことになる。図４に示したイベントルールの場合、投入された外部イベントとイベント４０１が一致するため、処理内容４０３が実行される。
【００５５】
この処理内容４０３のａｓｓｅｒｔＡｓｋａｂｌｅＦｌｕｅｎｔは、引数に設定された事実が、利用者に確認可能なものとして登録することを意味する。つまり、ａｓｓｅｒｔＡｓｋａｂｌｅＦｌｕｅｎｔ（ＰｌａｎｎｎｉｎｇＡｇｅｎｔ，Ｆ）が実行されると、プランニングエージェント３０の信念ＤＢ５０１にａｓｋａｂｌｅＢｅｌｉｅｆ（Ｆ）が登録されることになる。
【００５６】
なお、利用者に確認を行わない事実の登録にはａｓｓｅｒｔＦｌｕｅｎｔを用いる。つまり、ａｓｓｅｒｔＦｌｕｅｎｔ（ＰｌａｎｎｎｉｎｇＡｇｅｎｔ，Ｆ）が実行されると、プランニングエージェント３０の信念ＤＢ５０１にｂｅｌｉｅｆ（Ｆ）が登録されることになる。これにより、信念ＤＢ５０１に確認可能な事実と、確認を行わない事実とを区別して登録することができる。
【００５７】
そして、図４の処理内容４０３に示された処理のうち、登録処理のみ行うことで、信念ＤＢ５０１に、ｄｅｓｔｉｎａｔｉｏｎ(‘立山駅’,’富山地方鉄道立山線’)、ａｒｒｉｖａｌＴｉｍｅ（ｎｅｃｅｓｓａｒｙ）、ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）が登録される。なお、登録された信念ＤＢ５０１は、図６に示した通りとなる。これにより、図１に示すイベント対応部２０からプランニングエージェント３０への信念更新が行われた。
【００５８】
その後、図４の処理内容４０３に示された処理のうち、ａｓｓｅｒｔＧｏａｌ（ｐｌａｎｎｉｎｇＡｇｅｎｔ、ｎａｖｉｇａｔｅ）は、イベント対応部２０がプランニングエージェント３０にｎａｖｉｇａｔｅを通常ゴールとして投入することを意味する。これにより、図１に示すイベント対応部２０からプランニングエージェント３０に、ナビゲーションの実行を示すゴールの投入が行われたことになる。
【００５９】
そして、プランニングエージェント３０は、当該通常ゴールを実現する通常プランを作成する。なお、プランの作成手法は、どのような作成手法を用いても良い。この作成されたプラン群は、ゴール毎にプラン群スタック５０３にプッシュされる。
【００６０】
そして、プランニングエージェント３０により作成された通常プランに従い、図１０で示した順序でアクションを実行するように設定される。この場合、図１０で示した順序に従って、プランニングエージェント３０は、通常・割込アクション実行部４０に対して実行指示を行うことになる。これにより、図１で示したプランニングエージェント３０から通常・割込アクション実行部４０への通常アクションの実行指示が行われる。
【００６１】
図１０に示すように、プランニングエージェント３０が、通常・割込アクション実行部４０に対して、特に問題が発生無ければ、ｓｅｔｄｅｓｔｉｎａｔｉｏｎ(‘立山駅’,‘富山地方鉄道立山線’)の実行を指示し（ステップＳ１００１）、ｓｅｔＲｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）の実行を指示し（ステップＳ１００２）、ｓｅａｒｃｈＡｎｄＳｈｏｗＲｏｕｔｅの実行を指示し（ステップＳ１００３）、ｔｅｌｌＲｏｕｔｅＩｎｆｏｒｍａｔｉｏｎの実行を指示し（ステップＳ１００４）、ｔｅｌｌＡｒｒｉｖａｌＴｉｍｅの実行を指示し（ステップＳ１００５）、最後にｓｔａｒｔＮａｖｉｇａｔｉｏｎの実行を指示することで（ステップＳ１００６）、利用者に対するナビゲーションが開始され、全プランが終了する予定である。
【００６２】
まず、通常・割込アクション実行部４０は、プランニングエージェント３０から入力されたｓｅｔｄｅｓｔｉｎａｔｉｏｎ(‘立山駅’,‘富山地方鉄道立山線’)に従い、目的地を立山駅に設定する。
【００６３】
次に、通常・割込アクション実行部４０は、プランニングエージェント３０から入力されたｓｅｔＲｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）に従い、ルート検索条件を高速優先に設定する。
【００６４】
さらに、通常・割込アクション実行部４０は、プランニングエージェント３０から入力されたｓｅａｒｃｈＡｎｄＳｈｏｗＲｏｕｔｅに従い、ルートを作成・表示を行う。
【００６５】
さらに、通常・割込アクション実行部４０は、プランニングエージェント３０から入力されたｔｅｌｌＡｒｒｉｖａｌＴｉｍｅに従い、ルート上の注意事項を読み上げているものとする。そして、当該読み上げの最中に、利用者が音声で拒否反応を示したとする。この場合、図１０のステップＳ１００４で処理が中断されることになる。
【００６６】
つまり、ルート上の注意事項を読み上げているときに、利用者が拒否反応を示した場合、プラン実行システム１は、利用者がどこに不満を抱いているのか特定するための処理を優先的に行う。このための処理手順について説明する。
【００６７】
また、利用者の拒否反応とは、信念ＤＢ５０１に格納されている誤った事実に基づいてプランの作成・実行したことで、利用者の意図したとおりに処理が行われていないことに対する拒否反応とする。拒否反応は、上述したように音声認識により判定してもよいし、顔画像の解析により判定してもよいし、拒否ボタンが押されたときに、ユーザが拒否をしたと判定してもよい。
【００６８】
次に、プラン実行システム１において割り込みが生じた場合の処理手順を、図１１を用いて説明する。外界監視部１０が、利用者が拒否反応を示したことを表すイベント（ｒｅｊｅｃｔ）を、イベント対応部２０に通知する（図１１の（１））。この通知に伴い、イベント対応部２０は、利用者の意図を確認するための割込ゴールをプランニングエージェント３０に投入する（図１１の（２））。
【００６９】
このような割込ゴールを投入するためには、図１２に示すように、イベント対応部２０のイベントルールＤＢ３０１に、利用者の意図を確認するためのイベントを予め格納しておく必要がある。これにより、利用者ユーザが実行中の対話等のプランに対し拒否反応を示されたときに、利用者の意図を確認するための割込ゴールを投入することができる。
【００７０】
割込ゴールとは、プランニングエージェント３０に投入された場合に、実行中のプランを中断し、実行中のアクションも中断可能であれば中断し、優先的にプランの作成・実行が行われるゴールとする。この割込ゴールはｉｎｓｅｒｔＧｏａｌ（投入先，[条件]，[
割込ゴール名]）で定義されている。
【００７１】
つまり、図１２に示したイベントルールは、イベントｒｅｊｅｃｔが通知された場合に、割込ゴール（ｉｎｓｅｒｔＧｏａｌ）であるユーザ意図確認ゴール（ｃｈｅｃｋＩｎｔｅｎｔｉｏｎ）が、プランニングエージェント３０（ｐｌａｎｎｉｎｇＡｇｅｎｔ）に投入されることを意味している。
【００７２】
図１１に戻り、プランニングエージェント３０は、ユーザ意図確認のための割込ゴールが投入されると、通常・割込プラン作成部５０８が当該割込ゴールのための割込プランを作成して、プラン群スタック５０３に作成した割込プランを登録する。
【００７３】
この割込プランは、アクション履歴記憶ＤＢ５０５に記憶されている通常アクション毎に、アクション情報記憶部５０４及び信念ＤＢ５０１を参照して、通常アクションに対応付けられている確認可能な事実を抽出し、抽出した確認可能な事実が適切か否かの確認を利用者に対して要求する割込アクション（確認要求アクション）で構成される。
【００７４】
割込ゴールより作成された割込プランは、図１３の符号１３０１に示すように、最も高い優先度でプラン群スタック５０３に格納される。これにより、プランニングエージェント３０のアクション管理部５１０が、割込ゴールの割込プラン群を優先的に実行するよう制御を行うことになる。
【００７５】
図１１に戻り、プランニングエージェント３０のアクション管理部５１０は、通常プランの実行を中止すると共に、通常・割込アクション実行部４０に対して通常アクションの中断を指示する（図１１の（３））。その後、通常・割込アクション実行部４０から、通常アクションの中断の報告を受け付ける（図１１の（４））。これにより、実行中の通常プラン及び通常アクションが中断されたことになる。
【００７６】
そして、プランニングエージェント３０のアクション管理部５１０は、ユーザ意図確認のための割込ゴールに対する割込プランの実行を開始する。そこでプランニングエージェント３０は、図１１の（５）に示すように、ユーザへの意図確認（質問のための出力と質問に対するユーザからの入力待ち）、ユーザによる意図訂正（ユーザに訂正を促す出力と、ユーザからの訂正待ち）を順に行う。なお、この意図確認及び意図訂正の処理は、割込プランに応じて複数回行われるものとする。
【００７７】
そして、プランニングエージェント３０は、割込ゴールから作成された割込プランの実行が終了した後、中断していた通常プランの実行を再開する。なお、図１のアクション実行が中断されている間に、ユーザ意図確認のための割込ゴールから作成された割込プランが実行された場合に、信念ＤＢ５０１が更新されると、通常・割込プラン作成部５０８は、実行中プランのみならず、プラン群スタック５０３に格納されている全ての通常プラン群（中断中プラン群も含む）を更新する。
【００７８】
また、利用者の意図確認の結果を、直接またはイベント対応部２０を介して、外界監視部１０に通知することで、音声入力等の精度向上に役立てることも考えられる。
【００７９】
次に、上述した処理を行うプラン実行システム１の各構成が行う処理について説明する。まずは、イベント対応部２０が行う処理について説明する。図１４に示すように、イベント対応部２０の外部イベント取得部３０２が外部イベントを取得した場合（ステップＳ１４０１：Ｙｅｓ）、または内部イベント取得部３０４が内部イベントを取得した場合には（ステップＳ１４０２：Ｙｅｓ）、条件判定部３０５は、イベントルールＤＢ３０１を参照し、取得した外部イベントまたは内部イベントに対応付けられている実行条件を特定する（ステップＳ１４０３）。さらに、信念ＤＢ５０１に格納されている事実（確認可能な事実、確認不要な事実含む）が実行条件を満たすか否かを判定する。信念ＤＢ５０１の事実が実行条件を満たす場合には（ステップＳ１４０４：Ｙｅｓ）、処理内容抽出部３０６は、イベントルールＤＢ３０１において外部イベントまたは内部イベントに対応付けられている処理内容を抽出する（ステップＳ１４０５）。
【００８０】
次に、処理内容に応じて、通知部３０７は処理内容を実行する（ステップＳ１４０６）。具体的には、外界監視部１０へのイベント指示であった場合には、通知部３０７は、イベント指示を外界監視部１０に通知する。また、処理内容がプランニングエージェント３０へのゴール指示または信念更新であった場合には、通知部３０７は、ゴール指示または信念更新をプランニングエージェント３０に通知する。なお、同一の外部イベントや内部イベントに複数の処理内容が対応付けられていてもよい。この場合には、処理内容抽出部３０６は、最も優先順位の高い処理内容を選択することとする。
【００８１】
図１５に示すように、プランニングエージェント３０は、通知部３０７から通常ゴールを取得すると（ステップＳ１５０１）、ゴールキュー５０７にゴールが格納されているか否かを確認する。ゴールキュー５０７にゴールが格納されていない場合には（ステップＳ１５０２：Ｎｏ）、通常ゴールに対するプラン実行処理が行われる（ステップＳ１５０３）。一方、ゴールキュー５０７にゴールが格納されている場合には（ステップＳ１５０２：Ｙｅｓ）、取得した通常ゴールをプラン群スタック５０３の最後尾に格納し（ステップＳ１５０４）、処理が完了する。
【００８２】
次に、プラン群スタック５０３にゴールが存在する場合には（ステップＳ１５０５：Ｙｅｓ）、プラン群スタック５０３の先頭ゴールに対するプラン実行処理が行われる（ステップＳ１５０６）。そして、ステップＳ１５０５においてプラン群スタック５０３にゴールが存在しなくなると（ステップＳ１５０５：Ｎｏ）、処理が完了する。
【００８３】
図１５のステップＳ１５０３、Ｓ１５０６で行われるプラン実行処理においては、図１６に示すように、通常・割込プラン作成部５０８は、処理対象となるゴールに対応するプランを作成する（ステップＳ１６０１）。次に、作成または更新したプランが存在し（ステップＳ１６０２：Ｙｅｓ）、プランの実行が終了していない場合には（ステップＳ１６０３：Ｙｅｓ）、アクション管理部５１０が、プラン群スタック５０３から実行するプランを選択する（ステップＳ１６０４）。これにより、実行するアクションが特定される。
【００８４】
そして、内部イベント通知部５１１は、実行すべきアクションの開始を示す開始イベントをイベント対応部２０に通知する（ステップＳ１６０５）。
【００８５】
次に、アクション管理部５１０が、アクション情報ＤＢ５０４及び信念ＤＢ５０１を参照して、信念ＤＢ５０１に格納されている事実が、アクション情報ＤＢ５０４に格納されているアクションの事前条件を満足した場合、通常・割込アクション実行部４０に対しアクションの実行指示を通知する（ステップＳ１６０６）。次に、実行したアクションの終了を示す実行状態をイベント対応部２０に通知する（ステップＳ１６０７）。次に、更新部５０９は、アクションの実行結果（成功・失敗・中断）にしたがい信念ＤＢ５０１およびプラン群スタック５０３を更新する（ステップＳ１６０８、Ｓ１６０９）。そして、アクション管理部５１０が、実行したアクションを実行履歴として、アクション履歴ＤＢ５０５に登録する（ステップＳ１６１０）。また、割込ゴールが通知された場合、割込ゴールの処理中は待機する（ステップＳ１６１１）。割込ゴールの処理が終了した場合、又は割込ゴールの通知が無かった場合は、ステップＳ１６０２に戻る。
【００８６】
なお、ステップＳ１６０６におけるアクションの実行結果が中断になるのは、別スレッドの、外部から信念を更新された場合や、割込ゴールが投入され、実行中のアクションが中断された場合である。この場合には、ステップＳ１６０６から速やかにステップＳ１６０７に処理が移行する。
【００８７】
ステップＳ１６０３においてプラン実行が終了すると（ステップＳ１６１３：Ｙｅｓ）、プラン実行成功時の処理を行う（ステップＳ１６１３）。また、ステップＳ１６０２において作成または更新したプランが存在しない場合には（ステップＳ１６０２：Ｎｏ）、プラン実行失敗時の処理を行う（ステップＳ１６１２）。
【００８８】
そして、アクション管理部５１０は、ゴールに対応するプランのアクションの実行履歴を、アクション履歴ＤＢ５０５から削除して（ステップＳ１６１４）、処理を終了する。
【００８９】
図１７に示すようにプランニングエージェント３０は、割込ゴールを取得すると（ステップＳ１７０１）、このとき他のゴールに対応するプラン実行処理が行われているか否かを判断する（ステップＳ１７０２）。他のゴールに対応するプラン実行処理が行われていないと判断した場合（ステップＳ１７０２：Ｎｏ）、割込ゴールに対応するプラン実行処理を行う（ステップＳ１７０７）。
【００９０】
一方、プランニングエージェント３０は、他のゴールに対応するプラン実行処理が行われていると判断した場合（ステップＳ１７０２：Ｙｅｓ）、現在実行中のアクション、すなわち他のゴールを達成するためのアクションを中断する（ステップＳ１７０３）。なお、ステップＳ１７０３においてアクションが中断されると、このアクションの実行結果（中断）にしたがい、アクション実行終了を示す実行状態がイベント対応部２０に通知される（図１６のステップＳ１６０７）。次に、実行中のプランを中断するために、図１６で示される別スレッドの実行中プランの処理がステップＳ１６１１まで到達するのを待つ（ステップＳ１７０４）。
【００９１】
次に、プランニングエージェント３０は、割込ゴールに対応する割込プランを実行処理する（ステップＳ１７０５）。割込ゴールに対するプラン実行処理が終了すると、ステップＳ１７０４において中断したプランの実行を再開する（ステップＳ１７０６）。このとき、図１６で示される別スレッドにおいて、プランの実行が再開され、ステップＳ１６１１からステップＳ１６０２に処理が進む。
【００９２】
図１８に示すように、外部からの指示により信念ＤＢ５０１が更新されると（ステップＳ１８０１）、通常・割込プラン作成部５０８が、プラン群スタック５０３に実行中または中断中のプランが存在するか否かを判断する（ステップＳ１８０２）。実行中または中断中のプランが存在しないと判断した場合（ステップＳ１８０２：Ｎｏ）、このまま終了する。
【００９３】
一方、通常・割込プラン作成部５０８が、実行中または中断中のプランが存在すると判断した場合（ステップＳ１８０２：Ｙｅｓ）、信念ＤＢ５０１の更新によりこれらのプランに影響が及ぶ可能性がある。そこで、この場合には、通常・割込プラン作成部５０８が、信念更新時の実行中および中断中プラン群を、更新後の信念に基づいて修正する（ステップＳ１８０３）。
【００９４】
さらに、アクション管理部５１０が、修正後の実行中プランにおいて、実行中のアクションの実行継続をすることが無意味であると判断した場合、すなわち、実行中のアクションが信念更新後に修正された実行中プランと関連がないような場合には（ステップＳ１８０４：Ｙｅｓ）、アクション管理部５１０が、実行していたアクションの実行を中断し（ステップＳ１８０５）、処理を終了する。なお、ステップＳ１８０５においてアクションの実行を中断した直後に、別スレッドのプラン実行処理におけるアクションの実行は中断され、アクションの実行結果は中断となる。また、実行中のアクションを継続することが無意味とならない場合には（ステップＳ１８０４：Ｎｏ）、このまま終了する。
【００９５】
次に、図１７のステップＳ１７０５又はステップＳ１７０７において、ユーザの意図を確認するための割込ゴールに対する割込プランを実行する場合に、通常・割込プラン作成部５０８が割込プランを作成する処理手順について、図１９を用いて説明する。
【００９６】
まず、通常・割込プラン作成部５０８は、ゴールキュー５０７に格納されたゴールｃｈｅｃｋＩｎｔｅｎｔｉｏｎに従って、割込プランの作成を開始する。
【００９７】
そして、通常・割込プラン作成部５０８は、アクション管理部５１０が管理している中断したアクションと、アクション履歴ＤＢに記載されている各アクションの事前条件である事実を抽出する（ステップＳ１９０１）。この事前条件である事実の抽出には、アクション情報ＤＢ５０４が保持している事前条件と、信念ＤＢ５０１に格納されている事実を参照することで特定できる。
【００９８】
そして、通常・割込プラン作成部５０８は、抽出した事実のうち、ユーザに確認可能な事実のみ抽出する（ステップＳ１９０２）。
【００９９】
次に、通常・割込プラン作成部５０８は、抽出した事実毎に、ユーザに対して確認、確認結果に応じて訂正を行うプラン群を作成する（ステップＳ１９０３）。
【０１００】
そして、通常・割込プラン作成部５０８は、抽出した事実を事前条件として利用したアクションの実行順序に従って、プランを構成する各アクションの優先順位を設定する（ステップＳ１９０４）。本実施の形態では、使用したアクションが新しいものから順に事実を確認するように、プランを構成する各アクションの優先順位を設定する。
【０１０１】
次に、図１０で示した処理手順のステップＳ１００４で割込ゴールが通知された場合について説明する。
【０１０２】
まずは、ステップＳ１９０１に示したように、通常・割込プラン作成部５０８は、中断した通常アクションｔｅｌｌＲｏｕｔｅＩｎｆｏｒｍａｔｉｏｎの事前条件を、アクション情報ＤＢ５０４から確認する。そして、アクション情報ＤＢ５０４に、図２０に示す通常アクションの情報が格納されている場合、当該アクションは事前条件としてｒｏｕｔｅＦｏｕｎｄであると判断する。そして、通常・割込プラン作成部５０８は、ｒｏｕｔｅＦｏｕｎｄを、信念ＤＢ５０１で確認する。図６に示すようにｂｅｌｉｅｆ（ｒｏｕｔｅＦｏｕｎｄ）が格納されている。このため、確認不要と判断され、ステップＳ１９０２で抽出対象から除外される。
【０１０３】
次に、通常・割込プラン作成部５０８は、アクション履歴ＤＢから実行した通常アクションを取得する。図８に示したアクション履歴ＤＢからは、通常アクションｓｅａｒｃｈＡｎｄＳｈｏｗＲｏｕｔｅと、通常アクションｓｅｔＲｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）と、通常アクションｓｅｔＤｅｓｔｉｎａｔｉｏｎ（‘立山駅’，‘富山地方鉄道立山線’）とが取得できる。
【０１０４】
そこで、通常・割込プラン作成部５０８は、通常アクションｔｅｌｌＲｏｕｔｅＩｎｆｏｒｍａｔｉｏｎの直前に実行した通常アクションｓｅａｒｃｈＡｎｄＳｈｏｗＲｏｕｔｅの事前条件を、アクション履歴ＤＢ５０５から確認する。図２１に示す通常アクションの情報が格納されている場合、当該アクションは事前条件としてｄｅｓｔｉｎａｔｉｏｎＳｅｔと、ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅＳｅｔであると判断する。そして、通常・割込プラン作成部５０８は、ｄｅｓｔｉｎａｔｉｏｎＳｅｔと、ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅＳｅｔとを、信念ＤＢ５０１で確認する。この場合、信念ＤＢ５０１には、ｂｅｌｉｅｆ（ｄｅｓｔｉｎａｔｉｏｎＳｅｔ）と、ｂｅｌｉｅｆ（ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅＳｅｔ）が格納されている。このため、確認不要と判断され、ステップＳ１９０２で抽出対象から除外される。
【０１０５】
次に、通常・割込プラン作成部５０８は、通常アクションｓｅａｒｃｈＡｎｄＳｈｏｗＲｏｕｔｅの直前に実行した通常アクションｓｅｔＲｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）の事前条件を、アクション履歴ＤＢ５０５から確認する。図２２に示す通常アクションの情報が格納されている場合、当該通常アクションは事前条件としてｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（Ｐｒｅｆｅｒｅｎｃｅ）であると判断する。そして、通常・割込プラン作成部５０８は、ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（Ｐｒｅｆｅｒｅｎｃｅ）を、信念ＤＢ５０１で確認する。この場合、信念ＤＢ５０１には、図６に示すようにａｓｋａｂｌｅＢｅｌｉｅｆ（ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ））が格納されている。このため、確認必要と判断され、ステップＳ１９０２で抽出される。これにより、当該事実を利用者が確認し、誤りならば訂正が促されることになる。
【０１０６】
そして、通常・割込プラン作成部５０８は、通常アクションｓｅｔＲｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）の直前に実行した通常アクションｓｅｔＤｅｓｔｉｎａｔｉｏｎ（‘立山駅’，‘富山地方鉄道立山線’）の事前条件を、アクション履歴ＤＢ５０５から確認する。図２３に示す通常アクションの情報が格納されている場合、当該アクションは事前条件としてｄｅｓｔｉｎａｔｉｏｎ（ＰＯＩ，Ｄｅｓｃｒｉｐｔｉｏｎ）であると判断する。そして、通常・割込プラン作成部５０８は、ｄｅｓｔｉｎａｔｉｏｎ（ＰＯＩ，Ｄｅｓｃｒｉｐｔｉｏｎ）を、信念ＤＢ５０１で確認する。この場合、信念ＤＢ５０１には、図６に示すようにａｓｋａｂｌｅＢｅｌｉｅｆ（ｄｅｓｔｉｎａｔｉｏｎ（‘立山駅’，‘富山地方鉄道立山線’））が格納されている。このため、確認必要と判断され、ステップＳ１９０２で抽出される。これにより、当該事実を利用者が確認し、誤りならば訂正が促されることになる。
【０１０７】
次に、通常・割込プラン作成部５０８は、ステップＳ１９０３において、ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）、ｄｅｓｔｉｎａｔｉｏｎ（‘立山駅’，‘富山地方鉄道立山線’）の事実毎に、利用者に対して確認、確認結果に応じて訂正を行う割込プラン群を作成する。なお、これら割込プランは予め図示しないプラン・ライブラリーに用意されているものとする。
【０１０８】
そして、通常・割込プラン作成部５０８は、ステップＳ１９０４において、実行順序として、ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）の確認、確認結果に応じて訂正を行う割込プランを実行した後、ｄｅｓｔｉｎａｔｉｏｎ（‘立山駅’，‘富山地方鉄道立山線’）の確認、確認結果に応じて訂正を行う割込プランを実行するように実行順序を設定する。つまり、最近実行された通常アクションで利用された事実から順に割込プランが実行されるように、通常・割込プラン作成部５０８が、各割込プランに対して優先度を設定する（つまり、ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）に関する割込プランより、ｄｅｓｔｉｎａｔｉｏｎ（‘立山駅’，‘富山地方鉄道立山線’）に関す割込るプランの方が優先度が低く設定される）。そして、これら作成された割込プラン群は、まとめてプラン群スタック５０３に格納される。
【０１０９】
そして、アクション管理部５１０が、作成された割込プランを実行する。まず、アクション管理部５１０は、格納された割込プラン群から、ｒｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）の確認と、確認結果に応じて訂正するための割込プランを実行する。
【０１１０】
図２４に示すように、アクション管理部５１０は、割込アクションの一種である確認要求アクションｓｐｅａｋ（‘高速優先でよろしかったですか？’）の実行を、通常・割込アクション実行部４０に指示する（ステップＳ２４０１）。
【０１１１】
これにより、通常・割込アクション実行部４０は、「高速優先でよろしかったですか？」と音声出力する。その後、アクション管理部５１０は、割込アクションｗａｉｔＦｏｒＥｖｅｎｔ（ｎｏ）の実行を、通常・割込アクション実行部４０に指示する（ステップＳ２４０２）。これにより、通常・割込アクション実行部４０は、利用者からの音声入力「いいえ」を待つセンシング・アクションが実行される。
【０１１２】
この場合、図２５に示すように通常・割込アクション実行部４０は、音声入力を受け付ける外界監視部１０に、「はい」または「いいえ」の音声入力イベントを監視するように依頼する。そして、利用者が「はい」と発話した場合にはＹｅｓイベントが、「いいえ」と発話した場合にはＮｏイベントが通常・割込アクション実行部４０に通知される。
【０１１３】
図２４に戻り、通常・割込アクション実行部４０は、Ｎｏイベントが通知された場合、ｗａｉｔＦｏｒＥｖｅｎｔ（ｎｏ）の実行を成功と判断する。一方、Ｙｅｓイベントが通知された場合、ｗａｉｔＦｏｒＥｖｅｎｔ（ｎｏ）の実行は失敗と判断する。
【０１１４】
通常・割込アクション実行部４０が成功と判断した場合、つまり、高速優先でなかった場合、以下のアクションを実行する（ステップＳ２４０３）。
ｃｈａｎｇｅＧｏａｌ(ｇｅｔＰｒｅｆｅｒｅｎｃｅ(ｒｏｕｔｅ，ｅｘｃｅｐｔ（[ｈｉｇｈｗａｙ])))
【０１１５】
このｃｈａｎｇｅＧｏａｌ（Ｇ）は、ゴールをＧに変更するアクションを意味する。つまり、当該ｃｈａｎｇｅＧｏａｌ（Ｇ）が実行されると、現在のゴールのために作成されたプラン群を、プラン群スタック５０３からポップして廃棄すると共に、廃棄した各プランの実行履歴もアクション履歴ＤＢ５０５から廃棄される。そのかわりゴールをＧに変更して、Ｇを達成するために作成されたプラン群を１つにまとめて、プラン群スタック５０３にプッシュする。
【０１１６】
従って、ｃｈａｎｇｅＧｏａｌ(ｇｅｔＰｒｅｆｅｒｅｎｃｅ(ｒｏｕｔｅ，ｅｘｃｅｐｔ（[ｈｉｇｈｗａｙ])))を実行すると、ゴールを、ｇｅｔＰｒｅｆｅｒｅｎｃｅ(ｒｏｕｔｅ，ｅｘｃｅｐｔ（[ｈｉｇｈｗａｙ]))に変更し、これに伴いプラン群も変更される。
【０１１７】
利用者はルート検索条件として「高速優先」を意図していた際に、図２４で示した処理が実行された場合について説明する。この場合、プラン実行システム１から発生された「高速優先でよろしかったですか？」との質問に対し、利用者が「はい」と返答したとする。この場合、ステップＳ２４０２のｗａｉｔＦｏｒＥｖｅｎｔ（ｎｏ）が失敗したものとしてステップＳ２４０３の処理は行われない。
【０１１８】
次に、アクション管理部５１０は、格納されたプラン群から、ｄｅｓｔｉｎａｔｉｏｎ（‘立山駅’，‘富山地方鉄道立山線’）の確認と、確認結果に応じて訂正するためのプランを実行する。
【０１１９】
図２６に示すように、アクション管理部５１０は、割込アクションの一種である確認要求アクションｓｐｅａｋ（‘目的地は富山地方鉄道立山線の立山駅でよろしかったでしょうか？’）の実行を、通常・割込アクション実行部４０に指示する（ステップＳ２６０１）。
【０１２０】
これにより、通常・割込アクション実行部４０は、「目的地は富山地方鉄道立山線の立山駅でよろしかったでしょうか？」と音声出力する。その後、アクション管理部５１０は、割込アクションｗａｉｔＦｏｒＥｖｅｎｔ（ｎｏ）の実行を、通常・割込アクション実行部４０に指示する（ステップＳ２６０２）。これにより、通常・割込アクション実行部４０は、利用者からの音声入力「いいえ」を待つセンシング・アクションが実行される。また、この場合の処理は、上述した説明と同様なので説明を省略する。
【０１２１】
そして、通常・割込アクション実行部４０は、Ｎｏイベントが通知された場合、ｗａｉｔＦｏｒＥｖｅｎｔ（ｎｏ）の実行を成功と判断する。一方、Ｙｅｓイベントが通知された場合、ｗａｉｔＦｏｒＥｖｅｎｔ（ｎｏ）の実行は失敗と判断する。
【０１２２】
通常・割込アクション実行部４０が成功と判断した場合、つまり、富山地方鉄道立山線の立山駅でなかった場合、以下の割込アクションを実行する（ステップＳ２６０３）。
ｃｈａｎｇｅＧｏａｌ(ｇｅｔＤｅｓｔｉｎａｔｉｏｎ(ｅｘｃｅｐｔ（[ｄｅｓｔｉｎａｔｉｏｎ（‘立山駅’，‘富山地方鉄道立山線’）]))
【０１２３】
利用者は目的地として「ＪＲ東日本内房線館山駅」を意図していた際に、図２６で示した処理が実行された場合について説明する。この場合、プラン実行システム１から発生された「目的地は富山地方鉄道立山線の立山駅でよろしかったでしょうか？」との質問に対し、利用者が「いいえ」と返答したとする。この場合、ステップＳ２６０２のｗａｉｔＦｏｒＥｖｅｎｔ（ｎｏ）が成功したものとしてステップＳ２６０３の処理は行われる。
【０１２４】
次に、割込アクションｃｈａｎｇｅＧｏａｌ(ｇｅｔＤｅｓｔｉｎａｔｉｏｎ(ｅｘｃｅｐｔ（[ｄｅｓｔｉｎａｔｉｏｎ（‘立山駅’，‘富山地方鉄道立山線’）]))を実行することで、今までのプラン群を代替プラン群スタックからポップして廃棄し、廃棄した各プランのアクション実行履歴をアクション履歴ＤＢ５０５から廃棄する。
【０１２５】
そして、通常・割込プラン作成部５０８が、目的地を利用者に問うゴール（ｇｅｔＤｅｓｔｉｎａｔｉｏｎ（ｅｘｃｅｐｔ（［ｄｅｓｔｉｎａｔｉｏｎ（‘立山駅’,‘富山地方鉄道立山線’)]))）を達成するための割込プラン群を作成し、プラン群スタック５０３にプッシュする。
【０１２６】
これにより、アクション管理部５１０は、図２７に示された割込プランを実行する。図２７に示すように、まず、アクション管理部５１０は、通常・割込アクション実行部４０に対して、「目的地を再入力してください。」と音声発話するアクションの実行を指示する（ステップＳ２７０１）。
【０１２７】
その後、アクション管理部５１０は、通常・割込アクション実行部４０に対して、割込アクションｗａｉｔＦｏｒＥｖｅｎｔ（ｄｅｓｔｉｎａｔｉｏｎ（ＰＯＩ，Ｄｅｓｃｒｉｐｔｉｏｎ）,［ｅｘｃｅｐｔ（ｄｅｓｔｉｎａｔｉｏｎ（‘立山駅’，‘富山地方鉄道立山線’））］）の実行を指示する（ステップＳ２７０２）。
【０１２８】
この際、アクション管理部５１０は、外界監視部１０に、目的地ＰＯＩとその説明Ｄｅｓｃｒｉｐｔｉｏｎの入力イベント（ｄｅｓｔｉｎａｔｉｏｎ(ＰＯＩ，Ｄｅｓｃｒｉｐｔｉｏｎ)）を監視するように依頼する。ただし、富山地方鉄道立山線の立山駅ではないことを示す条件（ｅｘｃｅｐｔ（ｄｅｓｔｉｎａｔｉｏｎ(‘立山駅’,‘富山地方鉄道立山線’)））とすることにより、同じ誤認識が発生することを防止する。この場合の処理については後述する。
【０１２９】
その後、アクション管理部５１０は、割込アクションｒｅｔｒａｃｔＦｌｕｅｎｔ（ｄｅｓｔｉｎａｔｉｏｎ（＿，＿））の実行と（ステップＳ２７０３）、割込アクションａｓｓｅｒｔＡｓｋａｂｌｅＦｌｕｅｎｔ（ｄｅｓｔｉｎａｔｉｏｎ（ＰＯＩ，Ｄｅｓｃｒｉｐｔｉｏｎ））の実行を（ステップＳ２７０４）、通常・割込アクション実行部４０に指示する。
【０１３０】
この実行される割込アクションｒｅｔｒａｃｔＦｌｕｅｎｔ（ｄｅｓｔｉｎａｔｉｏｎ（＿，＿））は、信念ＤＢ５０１から事実ｄｅｓｔｉｎａｔｉｏｎ（＿，＿）を削除することを意味する。
【０１３１】
また、実行される割込アクションａｓｓｅｒｔＡｓｋａｂｌｅＦｌｕｅｎｔ（ｄｅｓｔｉｎａｔｉｏｎ（ＰＯＩ，Ｄｅｓｃｒｉｐｔｉｏｎ））は、信念ＤＢ５０１に確認可能な事実であるａｓｋａｂｌｅＢｅｌｉｅｆ（ＰＯＩ，Ｄｅｓｃｒｉｐｔｉｏｎ）の登録を意味する。
【０１３２】
つまり、通常・割込アクション実行部４０は、割込アクションに応じた信念更新を更新部５０９に要求する。これに従って、更新部５０９が、信念ＤＢ５０９の更新を行う。
【０１３３】
これにより、外界監視部１０から目的地ＰＯＩとその説明Ｄｅｓｃｒｉｐｔｉｏｎを取得した場合、プランニングエージェント３０及び通常・割込アクション実行部４０は、上述したアクション実行により、信念ＤＢ５０１に記録されている目的地とその説明を、新たに取得したＰＯＩとＤｅｓｃｒｉｐｔｉｏｎに置換する。
【０１３４】
これら割込アクションの実行で、割込プランの実行が終了する。そして、プラン群も含めて、プラン群スタック５０３からポップし、廃棄した各プランのアクション実行履歴をアクション履歴ＤＢ５０５から廃棄する。そして、再び元のプラン実行に戻る。
【０１３５】
次に、図２７のステップＳ２７０２で依頼された外界監視部１０の処理について、図２８を用いて説明する。まず、外界監視部１０は、ユーザ入力（例えば音声入力）の待機を行う（ステップＳ２８０１）。
【０１３６】
次に、外界監視部１０は、ユーザ入力（例えば音声入力）を受け付ける（ステップＳ２８０２）。そして、外界監視部１０は、条件（例えば、ｅｘｃｅｐｔ（ｄｅｓｔｉｎａｔｉｏｎ(‘立山駅’,‘富山地方鉄道立山線’)））に従って、前回検出した誤りと同様の内容にならないように、ユーザ入力（例えば音声入力）を解釈する（ステップＳ２８０３）。
【０１３７】
そして、外界監視部１０は、解釈した内容をセンシングの結果として、アクション管理部５１０に通知する（ステップＳ２８０４）。
【０１３８】
つまり、外界監視部１０は、利用者から再び「たてやまえき」と入力された場合でも、富山地方鉄道立山線の立山駅にならないよう解釈を行う。本処理手順では、ＪＲ東日本内房線の館山駅と解釈されたものとする。この解釈に従って、中断されていた元のプランの処理が開始される。
【０１３９】
つまり、通常・割込プラン作成部５０８は、図２９に示したプランを作成する。図２９に示すように、ｓｅｔｄｅｓｔｉｎａｔｉｏｎ(‘館山駅’,‘ＪＲ東日本内房線’)の実行で目的地の再設定は行うが、ｓｅｔＲｏｕｔｅＰｒｅｆｅｒｅｎｃｅ（ｈｉｇｈｗａｙ）の実行による高速優先設定は必要ない。
【０１４０】
そして、プランニングエージェント３０が、通常・割込アクション実行部４０に対して、通常アクションｓｅｔｄｅｓｔｉｎａｔｉｏｎ(‘館山駅’,‘ＪＲ東日本内房線’)の実行を指示し（ステップＳ２９０１）、通常アクションｓｅａｒｃｈＡｎｄＳｈｏｗＲｏｕｔｅの実行を指示し（ステップＳ２９０２）、通常アクションｔｅｌｌＲｏｕｔｅＩｎｆｏｒｍａｔｉｏｎの実行を指示し（ステップＳ２９０３）、通常アクションｔｅｌｌＡｒｒｉｖａｌＴｉｍｅの実行を指示し（ステップＳ２９０４）、最後に通常アクションｓｔａｒｔＮａｖｉｇａｔｉｏｎの実行を指示する（ステップＳ２９０５）。
【０１４１】
なお、割込みプラン実行中の中断中プランの修正方法については、従来から提案されている手法を含み、どのような手法を用いても良い。
【０１４２】
上述した実施形態にかかるプラン実行システム１によれば、信念ＤＢ５０１の利用者に確認可能な事実に限って、利用者に確認を行うためのプランを作成することで、利用者の意図を効率よく認識することが可能になる。
【０１４３】
図３０に示すように、第１の実施の形態にかかるプラン実行システム１は、ハードウェア構成として、上述した処理を行うプラン実行プログラムなどが格納されているＲＯＭ５２と、ＲＯＭ５２内のプログラムに従ってプラン実行システム１の各部を制御するＣＰＵ５１と、必要な種々のデータを記憶するＲＡＭ５３と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５７と、各部を接続するバス６２とを備えている。
【０１４４】
プラン実行プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フロッピー（登録商標）ディスク（ＦＤ）、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録されて提供されてもよい。
【０１４５】
この場合には、プログラムは、プラン実行システム１において上記記録媒体から読み出して実行することにより主記憶装置上にロードされ、上記ソフトウェア構成で説明した各部が主記憶装置上に生成されるようになっている。
【０１４６】
また、本実施の形態のプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。
【０１４７】
他の例としては、プラン実行システム１の外界監視部１０、イベント対応部２０およびプランニングエージェント３０をそれぞれ別のコンピュータ上に実装されていてもよい。この場合の外界監視部１０、イベント対応部２０およびプランニングエージェント３０のハードウェア構成は上述したハードウェア構成と同様である。
【０１４８】
以上、本発明を実施の形態を用いて説明したが、上記実施の形態に多様な変更または改良を加えることができる。
【図面の簡単な説明】
【０１４９】
【図１】第１の実施の形態にかかるプラン実行システムの全体構成を示す図である。
【図２】ゴールと、プランおよびアクションの関係を示す図である。
【図３】イベント対応部の機能構成を示すブロック図である。
【図４】イベントルールＤＢに格納されているイベントルールの一例を示した図である。
【図５】プランニングエージェントの機能構成を示すブロック図である。
【図６】信念ＤＢに格納されている事実の一例を示した図である。
【図７】プラン群スタックに格納されたプラン群の概念を説明した図である。
【図８】アクション履歴ＤＢに格納されたアクション実行履歴の一例を示した図である。
【図９】利用者との対話によりプラン実行システムが実行する処理の概念を示した図である。
【図１０】プランニングエージェントが、ナビゲーションを行うために作成したプランによる処理手順を示したフローチャートである。
【図１１】利用者の拒否反応を検出した場合にプラン実行システム内で行われる通知を示した説明図である。
【図１２】利用者の拒否反応を検出した場合に実行する処理内容が定義されているイベントルールの一例を示した図である。
【図１３】プラン群スタックに割込ゴールのプラン群を追加した概念を説明した図である。
【図１４】イベント対応部の処理を示すフローチャートである。
【図１５】通常ゴールに対するプランニングエージェントの処理を示すフローチャートである。
【図１６】プラン実行処理を示すフローチャートである。
【図１７】割込ゴールに対する処理を示すフローチャートである。
【図１８】外部から信念が更新された場合のプランニングエージェントの処理を示すフローチャートである。
【図１９】利用者に対して事実の確認等を行う割込ゴールに対応するプランを作成する処理を示すフローチャートである。
【図２０】アクション条件管理ＤＢが格納するアクション条件管理ＤＢの第１の例を示す図である。
【図２１】アクション条件管理ＤＢが格納するアクション条件管理ＤＢの第２の例を示す図である。
【図２２】アクション条件管理ＤＢが格納するアクション条件管理ＤＢの第３の例を示す図である。
【図２３】アクション条件管理ＤＢが格納するアクション条件管理ＤＢの第４の例を示す図である。
【図２４】ルート検索条件が高速優先であることを確認、確認結果に応じて訂正するプランによる処理手順を示すフローチャートである。
【図２５】外界監視部と通常・割込アクション実行部とによるイベントの送受信関係を示した図である。
【図２６】目的地が富山地方鉄道立山線の立山駅であることを確認、確認結果に応じて訂正するプランによる処理手順を示すフローチャートである。
【図２７】目的地を再入力するために作成されたプランによる処理手順を示すフローチャートである。
【図２８】外界監視部が、利用者入力からイベントを通知するまでの処理手順を示したフローチャートである。
【図２９】割込プランより中断が終了した後に再開されたプランによる処理手順を示すフローチャートである。
【図３０】第１の実施の形態にかかるプラン実行システムのハードウェア構成を示す図である。
【符号の説明】
【０１５０】
１  プラン実行システム
１０  外界監視部
２０  イベント対応部
３０  プランニングエージェント
４０  通常・割込アクション実行部
５１  ＣＰＵ
５２  ＲＯＭ
５３  ＲＡＭ
５７  通信Ｉ／Ｆ
６２  バス
３０１  イベントルールＤＢ
３０２  外部イベント取得部
３０４  内部イベント取得部
３０５  条件判定部
３０６  処理内容抽出部
３０７  通知部
５０１  信念ＤＢ
５０３  プラン群スタック
５０４  アクション条件管理ＤＢ
５０５  アクション履歴ＤＢ
５０６  ゴール取得部
５０７  ゴールキュー
５０８  通常・割込プラン作成部
５０９  更新部
５１０  アクション管理部
５１１  内部イベント通知部
【図１】
2009015493.tif 000003
【図２】
2009015493.tif 000004
【図３】
2009015493.tif 000005
【図４】
2009015493.tif 000006
【図５】
2009015493.tif 000007
【図６】
2009015493.tif 000008
【図７】
2009015493.tif 000009
【図８】
2009015493.tif 000010
【図９】
2009015493.tif 000011
【図１０】
2009015493.tif 000012
【図１１】
2009015493.tif 000013
【図１２】
2009015493.tif 000014
【図１３】
2009015493.tif 000015
【図１４】
2009015493.tif 000016
【図１５】
2009015493.tif 000017
【図１６】
2009015493.tif 000018
【図１７】
2009015493.tif 000019
【図１８】
2009015493.tif 000020
【図１９】
2009015493.tif 000021
【図２０】
2009015493.tif 000022
【図２１】
2009015493.tif 000023
【図２２】
2009015493.tif 000024
【図２３】
2009015493.tif 000025
【図２４】
2009015493.tif 000026
【図２５】
2009015493.tif 000027
【図２６】
2009015493.tif 000028
【図２７】
2009015493.tif 000029
【図２８】
2009015493.tif 000030
【図２９】
2009015493.tif 000031
【図３０】
2009015493.tif 000032