(57)【要約】【課題】  ルールの追加，変更が容易で、個人や状況に応じた適応化を動的に行うことが可能な推論システムの提供。【解決手段】  条件節に、予め設定された複数の状況属性の中のいずれか一つ又は複数に対する言語的或いは数値的な条件が記述され、従属節に、複数の要求属性の各々に対する要求度を成分とするスコアリングベクトルが記述されたルールを用いる。そして、読み込んだ状況データファイル及びユーザプロファイルの内容に基づいて、使用すべきルール群を選択する（S210〜S220）。選択したルール群から条件節を充足する全てのルールについてスコアリングベクトルを抽出し、その抽出したスコアリングベクトルを重み付け加算することで、要求ベクトルを生成する（S230〜S280）。この要求ベクトルに基づいて推論結果を生成する。【選択図】  図６
2005258588.tif 000002
【特許請求の範囲】
【請求項１】
条件節および従属節からなるIf-Then 形式で表現されたルールを用いて推論を実行する推論システムであって、
前記条件節として、予め設定された複数の状況属性の中のいずれか一つ又は複数に対する言語的或いは数値的な条件が記述されると共に、前記従属節として、予め設定された複数の要求属性の各々に対する要求度を成分とするスコアリングベクトルが記述される多数のルールからなるルール群を記憶したルール記憶手段と、
状況を把握するための状況データを取得し、該状況データに基づいて、前記ルール記憶手段に記憶されたルールの条件節の充足，非充足を判断し、該条件節が充足すると判断された全てのルールについて、該ルールの従属節を構成するスコアリングベクトルを抽出するスコアリングベクトル抽出手段と、
該スコアリングベクトル抽出手段にて抽出されたスコアリングベクトルを累積処理することで、前記状況データから総合的に把握される状況における前記要求属性の各々に対する要求度を成分とした要求ベクトルを生成する要求ベクトル生成手段と、
該要求ベクトル生成手段にて生成された要求ベクトルに基づいて、推論結果を生成する推論結果生成手段と、
を備えることを特徴とする推論システム。
【請求項２】
前記ルール記憶手段に記憶されるルール群は、前記条件節に単一の状況属性に対する言語的或いは数値的な条件が記述された一次元ルールを含むことを特徴とする請求項１に記載の推論システム。
【請求項３】
前記ルール記憶手段に記憶されるルール群は、前記条件節に複数の状況属性に対する言語的或いは数値的な条件が記述された階層的ルールを含むことを特徴とする請求項１又は２に記載の推論システム。
【請求項４】
前記ルール記憶手段には、複数のルール群が記憶され、
前記スコアリングベクトル抽出手段は、前記状況データに従って、使用するルール群の選択を行うことを特徴とする請求項１〜３のいずれかに記載の推論システム。
【請求項５】
前記要求ベクトル生成手段は、前記累積処理として、前記スコアリングベクトルの重み付け加算をすることを特徴とする請求項１〜４のいずれかに記載の推論システム。
【請求項６】
前記要求属性には、駆動可能なアプリケーションを対応づけることを特徴とする請求項１〜５のいずれかに記載の推論システム。
【請求項７】
前記要求属性には、推測されるユーザの欲求を対応づけることを特徴とする請求項１〜５のいずれかに記載の推論システム。
【請求項８】
前記要求ベクトル生成手段は、前記累積処理により得られたユーザの欲求を前記要求属性とする要求ベクトルを、駆動可能なアプリケーションを前記要求属性とする要求ベクトルに変換する属性変換手段を備えることを特徴とする請求項７に記載の推論システム。
【請求項９】
前記スコアリングベクトルは、平均的なユーザの視点に基づいて設定されていると共に、前記状況データには、個々のユーザの視点を示す視点データが少なくとも含まれ、
前記要求ベクトル生成手段は、前記累積処理により得られる要求ベクトルを、前記視点データに基づいて、ユーザの視点を反映した要求ベクトルに変換する視点変換手段を備えることを特徴とする請求項１〜８のいずれかに記載の推論システム。
【請求項１０】
前記視点変換手段は、前記要求ベクトルの変換を座標変換行列と併進ベクトルとを用いて実行することを特徴とする請求項９に記載の推論システム。
【請求項１１】
前記スコアリングベクトルの初期データは、多数ユーザの主観的判断に基づく属性値の評価を集計し、統計的に平均した結果から求められたものであることを特徴とする請求項１〜１０のいずれかに記載の推論システム。
【請求項１２】
前記スコアリングベクトルの初期データは、少数ユーザの主観的経験則を数値化したものであることを特徴とする請求項１〜１０のいずれかに記載の推論システム。
【請求項１３】
前記スコアリングベクトルの初期データを設定する初期データ設定手段を備えることを特徴とする請求項１〜１２のいずれかに記載の推論システム。
【請求項１４】
前記初期データ設定手段は、外部からの入力データ、或いは予め設定された定型的なテンプレート群の中から外部操作によって選択されたテンプレートを、前記初期データとして設定することを特徴とする請求項１３に記載の推論システム。
【請求項１５】
前記初期データ設定手段は、ユーザの嗜好が少なくとも記述されたユーザプロファイルに基づいて、推論により前記スコアリングベクトルの初期データを生成する初期データ生成手段を備えることを特徴とする請求項１３又は１４に記載の推論システム。
【請求項１６】
前記初期データ設定手段は、
前記条件節に同一の状況属性に関する条件が記述されたルール毎に、前記ルール群を複数の部分ルール群に分類し、あるルールについてスコアリングベクトルの初期データが設定された場合、該ルールと同一の部分ルール群に属する他のルールのスコアリングベクトルに、同一の初期データを転写する初期データ転写手段を備えることを特徴とする請求項１３〜１５のいずれかに記載の推論システム。
【請求項１７】
前記推論結果生成手段にて生成された推論結果に対するフィードバック情報に基づいて、当該システムの推論特性を修正する推論特性修正手段を備えることを特徴とする請求項１〜１６のいずれかに記載の推論システム。
【請求項１８】
前記フィードバック情報は、同一ユーザに関するものであることを特徴とする請求項１７に記載の推論システム。
【請求項１９】
前記フィードバック情報は、他ユーザに関するものであることを特徴とする請求項１７に記載の推論システム。
【請求項２０】
前記推論特性修正手段は、予め設定された修正条件を満たす場合に、前記推論結果生成手段が推論結果を生成する際に用いた要求ベクトル、及び該推論結果の提示を受けたユーザの応答を示す応答データを、前記フィードバック情報として用いることを特徴とする請求項１７〜１９のいずれかに記載の推論システム。
【請求項２１】
前記フィードバック情報の履歴を記憶する履歴記憶手段を備えることを特徴とする請求項２０に記載の推論システム。
【請求項２２】
前記推論特性修正手段は、前記応答データから生成される操作ベクトルと、前記フィードバック情報によって該応答データに対応付けられた要求ベクトルとの間に、予め設定されたしきい値以上の差異がある場合、或いは予め設定された一定期間内における前記フィードバック情報の履歴から、両ベクトルの間に前記しきい値以上の差異があると統計的に認められる場合に、前記修正条件を満たすものとし、該修正条件を満たした前記要求ベクトルに関わる前記ルールである対象ルールに基づいて、前記推論特性の修正を行うことをを特徴とする請求項２０又は２１に記載の推論システム。
【請求項２３】
前記推論特性修正手段は、前記対象ルールの従属節を構成するスコアリングベクトルの値を変更することで、前記推論特性を修正することを特徴とする請求項２２に記載の推論システム。
【請求項２４】
前記推論特性修正手段は、前記対象ルールの条件節を構成する言語的或いは数値的な条件を変更することで、前記推論特性を修正することを特徴とする請求項２２又は２３に記載の推論システム。
【請求項２５】
前記推論特性修正手段は、前記対象ルールの条件節を構成する言語的或いは数値的な条件を細分化した新たなルールを追加することで、前記推論特性を修正することを特徴とする請求項２２〜２４のいずれかに記載の推論システム。
【請求項２６】
前記推論特性修正手段は、前記対象ルールに基づいて新たな状況属性を設定し、該状況属性に対応するルールを追加することで、前記推論特性を修正することを特徴とする請求項２２〜２５のいずれかに記載の推論システム。
【請求項２７】
前記推論特性修正手段は、前記要求ベクトル生成手段にて前記要求ベクトルを生成する際に、前記対象ルールの従属節を構成するスコアリングベクトルに対して用いるパラメータの値を変更することで、前記推論特性を修正することを特徴とする請求項２２〜２６のいずれかに記載の推論システム。
【請求項２８】
前記スコアリングベクトル抽出手段が取得する前記状況データは、ユーザの嗜好が少なくとも記述されたユーザプロファイルを含み、
前記推論特性修正手段は、前記ユーザプロファイルの記述を追加・変更することで、前記推論特性を修正することを特徴とする請求項２２〜２７のいずれかに記載の推論システム。
【請求項２９】
前記推論結果生成手段にて生成された推論結果の提示を受けたユーザからの応答を検出する応答検出手段と、
該応答検出手段にて検出された応答が、前記推論結果を肯定するものである場合、該推論結果を得るために用いた要求ベクトルに関わるルールを強化対象ルールとし、該強化対象ルールを強化するルール強化手段と、
を備えることを特徴とする請求項１〜２８のいずれかに記載の推論システム。
【請求項３０】
前記ルール強化手段は、前記強化対象ルールの条件節について、該条件節の近傍を定義できる場合に、該近傍に含まれる条件節を有したルールも強化対象とすることを特徴とする請求項２９に記載の推論システム。
【請求項３１】
前記ルール強化手段は、前記要求ペクトル生成手段にて、前記強化対象ルールの従属節を構成するスコアリングベクトルから前記要求ベクトルを生成する際に用いるパラメータを変更することで、該強化対象ルールを強化することを特徴とする請求項２９又は３０に記載の推論システム。
【請求項３２】
前記ルール強化手段は、前記強化対象ルールの従属節を構成するスコアリングベクトルの値を増大させることで、該強化対象ルールを強化することを特徴とする請求項２９〜３１のいずれかに記載の推論システム。
【請求項３３】
条件節に、予め設定された複数の状況属性の中のいずれか一つ又は複数に対する言語的或いは数値的な条件が記述され、従属節に、予め設定された複数の要求属性の各々に対応対する要求度を成分とするスコアリングベクトルが記述された多数のルールからなるルール群の視覚的表現方法であって、
前記状況属性のうち二つを、二次元的に敷きつめられたタイル画像を個々に特定するための二次元アドレスに対応づける共に、前記要求属性のうち三つを、前記タイル画像の色を表現する３原色に対応づけることを特徴とするルール群の視覚的表現方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、If-Then 形式で表現されたルールを用いて推論を実行する推論システム、及び推論システムで使用するルール群の視覚的表現方法に関する。
【背景技術】
【０００２】
従来より、専門家の知識をルール形式（If-Then 形式）で表現し、与えられた問題に対してルールを適用することで解を求めるルールベース推論システムが知られている（例えば、非特許文献１参照）。
【０００３】
ここで、この種の推論システムにて使用されるルールの一例を（１）に示す。このルールは、与えられた状況記述に基づき、その状況記述に適合した行き先を判断する際に用いるものである。
【０００４】
IF｛（季節＝夏）AND（天気＝快晴）AND（趣味＝水泳）｝THEN｛海｝    （１）
つまり、ルールの条件節には、考慮すべき全ての属性（ここでは「季節」「天気」「趣味」）について言語的或いは数値的な条件（ここでは「夏」「快晴」「水泳」）を満足するか否かの状況記述に対する論理的な判断が記述され、ルールの従属節には、条件節に示された条件を満たす場合に、システムが下すべき一つの判断（ここでは「海」）が記述される。
【０００５】
ところで、このような推論システムの応用の一つとして、推論システムにより得られた推論結果（従属節の内容）に従い、その推論結果に対応する制御（例えば、「システムが緊急メッセージをセンターに発信する」「音楽をかける」「TVのスイッチを入れてニュースを映す」「風呂を沸かす」など）を実行する装置が知られている。
【０００６】
なお、推論システムでは、ルールの作り方によっては、与えられた状況に対して、ヒット（条件節を満足）するルールが複数存在する（即ち複数の推論結果が得られる）場合がある。このような場合に、上述の応用装置では、例えば、条件節を満足するものとし最初にヒットしたルールについてのみ制御を実行したり、ヒットした全てのルールについて、そのヒットした順に制御を実行することが考えられる。
【０００７】
しかし、この場合、妥当性の低いルールの後に、より妥当性の高いルールがヒットする可能性があり、その場合、推論システムは、必ずしも最適ではない（あるいは場合によっては誤った）判断を下したことになる。これは最適値探索問題にたとえれば、局所最適に陥ったことに相当する。
【０００８】
このような問題を回避するためには、１つの状況記述に対して１つのルールしかヒットしないようにすべてのルール群を構成する必要があった。
【非特許文献１】増渕陽二，牧野路加，佐枝三郎，垂水浩幸「戦略的決定を重視したモバイル型フィールドサービス・ワークフローシステム」情報処理学会第４３回グループウェアとネットワークサービス研究会、ＧＮ−４３−２０（２００２）
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、そのためには各ルールの条件節の論理がまったく背反（状況記述の空間を直和分割することに相当）になるように構成せねばならず、状況を完全に階層化分割して記述することが要求される。
【００１０】
図１４は、階層化したルールをテーブルに示したものであり、状況記述の属性がＮ個存在し、各属性ｉ（ｉ＝１〜Ｎ）の分解能がＭi であるとすると、論理的な組み合わせで得られる状況数、即ちルール数Ｎｓは、（２）にて表される。
【００１１】
Ｎｓ＝Ｍ1×Ｍ2×…×ＭN                                         （２）
そして、ユーザの環境，状況，要求，状態などさまざまな条件記述を、条件節に反映させようとするほど属性数Ｎが増大し、また、個々の属性についての判断精度を向上させようとするほど分解能Ｍｉが増大する。その結果、記述されるルールの数は膨大なものとなり場合によっては、実現不可能なレベルに達してしまうという問題があった。
【００１２】
また、この場合、（２）式からもわかるように、後から状況記述の属性を追加（Ｎを増加）した場合、それに伴って、膨大な数のルールを追加しなければならず、ルールの追加を簡単に行うことができないという問題もあった。
【００１３】
更に、このように考えられる全ての組み合わせ条件をルール化して逐一記述した場合、条件節に記述される条件記述の中には、顕著な特徴がないものや、現実的には起こりえないもの等が多数含まれているため、このような方法でルールを記述することは非効率であるという問題もあった。
【００１４】
なお、応用上重要と考えられるルールのみインプリメントすることで、ルール数を減らすことも考えられるが、その場合、細かい推論ができなくなるだけでなく、どのルール（属性）が重要であるか否かの判断が難しいという問題もあった。
【００１５】
本発明は、上記問題点を解決するために、ルールの追加，変更が容易で、個人や状況に応じた適応化を動的に行うことが可能な推論システムの提供を第１の目的とし、ルール群の関係を容易に把握できルールの設計などに有用なルール群の視覚的表現方法の提供を第２の目的とする。
【課題を解決するための手段】
【００１６】
上記目的を達成するためになされた本発明の推論システムは、条件節として、予め設定された複数の状況属性の中のいずれか一つ又は複数に対する言語的或いは数値的な条件が記述されると共に、従属節として、予め設定された複数の要求属性の各々に対する要求度を成分とするスコアリングベクトルが記述される多数のルールからなるルール群を記憶したルール記憶手段を備えている。
【００１７】
そして、スコアリングベクトル抽出手段が、状況を把握するための状況データを取得し、その状況データに基づいて、ルール記憶手段に記憶されたルールの条件節の充足，非充足を判断し、条件節が充足すると判断された全てのルールについて、そのルールの従属節を構成するスコアリングベクトルを抽出する。
【００１８】
すると、要求ベクトル生成手段が、スコアリングベクトル抽出手段にて抽出されたスコアリングベクトルを累積処理することで、状況データから総合的に把握される状況における要求属性の各々に対する要求度を成分とした要求ベクトルを生成し、その生成された要求ベクトルに基づいて、推論結果生成手段が推論結果を生成する。
【００１９】
つまり、ある状況設定に対して複数のルールがヒット（条件節が充足）することを許容するように、条件節を構成し、ヒットした全てのルールについて、その従属節を構成するスコアリングベクトルを重ね合わせることで、ヒットした全てのルールを反映させた要求ベクトル求め、この要求ベクトルに従って推論結果を求めている。
【００２０】
従って、本発明の推論システムによれば、複数のルールがヒットしても、局所最適に陥ることなく、ヒットしたルールを全体を見渡した最適な推論結果を得ることができる。
また、本発明の推論システムでは、状況記述が、全ての属性について一括して行われるのではなく、複数に分割されているため、条件節に用いられる状況属性（又はその組み合わせ）が異なるルール群毎に、独立の推論処理を実行することができる。
【００２１】
また、ルール群毎に条件節の記述が独立していることにより、条件節に全ての状況属性を含む従来装置と比較して、設定すべきルール数を大幅に削減することができるだけでなく、ルールの追加修正、ひいては個人や状況への動的適応を容易にすることができる。
【００２２】
また、本発明の推論システムでは、ルールの従属節をスコアリングベクトルを用いて記述することにより、個々のルールでは従属節にあいまい性を残したままで判断結果の特徴を表現することができる。
【００２３】
ところで、ルール記憶手段に記憶されるルール群は、条件節に単一の状況属性に対する言語的或いは数値的な条件が記述された一次元ルールのみから構成されていてもよいし、条件節に複数の状況属性に対する言語的或いは数値的な条件が記述された複数の階層的ルールのみから構成されていてもよいし、一次元ルールと階層的ルールといずれも含むように構成されていてもよい。
【００２４】
なお、一次元ルールは、条件節に状況属性が一つしか含まれないため、その状況属性の要求属性に対する寄与度が明確であり、ルールの生成や修正を容易に行うことができる。
一方、階層的ルールは、複数の状況属性により表される特定の論理条件に、特別な意味がある場合の記述、例えば、特殊事例や例外処理についての記述に好適である。
【００２５】
但し、階層的ルールでは、条件節に含まれる状況属性の数が増加するほど、ルールの生成や修正が難しくなるため、追加，修正，変更があまり必要とされないルールや、処理の簡単化が優先されるルールに対して適用すること、及び、条件節を構成する状況属性の数を少なくし、分解能が比較的小さい状況属性を用いることが望ましい。
【００２６】
また、本発明の推論システムでは、ルール記憶手段に複数のルール群を記憶させ、スコアリングベクトル抽出手段は、状況データに従って使用するルール群の選択を行うように構成してもよい。この場合、状況に応じたルール群のみが限定的に用いられることになるため、推論処理を適応的かつ効率的（ひいては高速）に実行できる。
【００２７】
なお、状況データとしては、ユーザプロファイル（個人情報、ユーザタイプ、自然環境、情報環境、状況、要求、状態を含む）、時間変化、場所変化（国の変化なども含む）などから得られた動的な状況限定情報を用いればよい。また、状況に応じたルール群としては、例えば、地理的な条件に基づいて分類されたルール群（日本国向け／アメリカ向け／中国向けのルール群など）、ユーザタイプに基づいて分類されたルール群（男性向け／女性向け／子供向け／大人向けのルール群など）、目的に基づいて分類されたルール群（仕事用／行楽用のルール群など）等が考えられ、その他、機能（従属節に対応）や状況分類（条件節に対応）毎にグルーピングされたものを用いればよい。
【００２８】
ところで、要求ベクトル生成手段は、累積処理として、具体的には、スコアリングベクトルの重み付け加算をすることが考えられる。
また、スコアリングベクトルの各成分を構成する要求属性には、駆動可能なアプリケーションを対応づけてもよいし、推測されるユーザの欲求を対応づけてもよい。
【００２９】
前者の場合、スコアリングベクトルを累積処理してなる要求ベクトルから、直ちに、駆動すべきアプリケーションを推論することができる。
また、後者の場合、ユーザの欲求としては、例えば、「食べたい」「スポーツしたい」「リラックスしたい」「気分転換したい」「買い物したい」「おしゃれしたい」「誰かと話したい」「どこかへ行きたい」「映画を見たい」「音楽を聴きたい」「ゲームしたい」などが考えられ、駆動すべきアプリケーションに直接対応づけるのではなく、アプリケーションに対する要求を潜在的な状態で表したものを用いればよい。
【００３０】
そして、この場合、要求ベクトル生成手段は、累積処理により得られたユーザの欲求を要求属性とする要求ベクトルを、駆動可能なアプリケーションを要求属性とする要求ベクトルに変換する属性変換手段を備えることが望ましい。
【００３１】
このような属性変換手段を備えていれば、新たなアプリケーションの追加時には、スコアリングベクトルを何ら変更する必要がなく、属性変換手段を変更するだけで追加されたアプリケーションへの対応づけを簡単に行うことができる。
【００３２】
更に、スコアリングベクトルが、平均的なユーザの視点に基づいて設定されていると共に、状況データには、個々のユーザの視点を示す視点データが少なくとも含まれている場合、要求ベクトル生成手段は、累積処理により得られる要求ベクトルを、視点データに基づいて、ユーザの視点を反映した要求ベクトルに変換する視点変換手段を備えることが望ましい。
【００３３】
この場合、ルール群（特にスコアリングベクトル）自体には、個々のユーザの特徴（視点）を反映させる必要がなく、全てのユーザに対して同じルール群を適用することができるため、ルール群が大規模化することを抑えることができる。
【００３４】
なお、視点変換手段は、具体的には、要求ベクトルの変換を座標変換行列と併進ベクトルとを用いて実行すればよい。
即ち、スコアリングベクトルは、平均的なユーザの視点に対応する共通座標系を用いて表現されていることに相当するため、このような座標変換の手法を用いることで視点変換を実現することができるのである。
【００３５】
なお、スコアリングベクトルの初期データは、例えば、多数ユーザの主観的判断に基づく属性値の評価を集計し、統計的に平均した結果から求められたものを用いることができる。なお、評価の集計方法としては、アンケート（インターネットの利用も考えられる）やプローブシステムなどを用いればよい。
【００３６】
この場合、データ収集のために膨大な手間と時間を要し、また、常識から容易に推察される断片的な経験則（例えば、「日本ではお盆、冬休み、ゴールデンウィークに交通渋滞が発生し、交通ニュースへのニーズが高まる」など）を、明示的に反映させることが比較的困難である。
【００３７】
そこで、スコアリングベクトルの初期データとして、例えば、少数ユーザ（例えばシステム開発者など）の主観的経験則（特に、上述の断片的な経験則の例に相当する代表的な局面を重点的に規則化したもの）を数値化したものを用いてもよい。
【００３８】
この場合、多くのユーザが直面するすべての局面や状況に対応したルール群を規定することは困難であるため、この少数の代表的ルール群に基づいて、未充填箇所のルール（特にスコアリングベクトル）を推論する手法を合わせて用いることが望ましい。
【００３９】
また、スコアリングベクトルの初期データは、予め設定されていてもよいが、初期データ設定手段により、設定や再設定が可能なように構成されていてもよい。
そして、初期データ設定手段は、例えば、外部からの入力データ、或いは予め設定された定型的なテンプレート群の中から外部操作によって選択されたテンプレートを、初期データとして設定することが考えられる。
【００４０】
また、初期データ設定手段は、ユーザの嗜好が少なくとも記述されたユーザプロファイルに基づいて、推論によりスコアリングベクトルの初期データを生成する初期データ生成手段を備え、この初期データ生成手段にて生成された初期データを設定するように構成してもよい。
【００４１】
なお、上述した方法、又はこれらの方法の組み合わせによって、初期データを設定するとしても、初期データ設定手段での作業量は膨大なものとなるため、全ての可能な状況（ルール）に対してスコアリングベクトルの初期データを用意することは困難である。
【００４２】
そこで、初期データ設定手段は、条件節に同一の状況属性に関する条件が記述されたルール毎に、前記ルール群を複数の部分ルール群に分類し、あるルールについてスコアリングベクトルの初期データが設定された場合、該ルールと同一の部分ルール群に属する他のルールのスコアリングベクトルに、同一の初期データを転写する初期データ転写手段を備えることが望ましい。このような初期データ転写手段によれば、部分ルール群毎に一つの初期データを設定すればよいため、初期データ設定手段にて設定すべきルールを大幅に削減することができる。
【００４３】
また、本発明の推論システムは、推論結果生成手段にて生成された推論結果に対するフィードバック情報に基づいて、推論特性修正手段が、当該システムの推論特性を修正するように構成してもよい。
【００４４】
この場合、推論特性の修正のために用いるフィードバック情報は、同一ユーザに関するものであってもよいし、他ユーザに関するものであってもよい。
なお、推論特性修正手段は、例えば、外部から修正要求が入力された場合に、推論特性を修正するように構成してもよいが、予め設定された修正条件を満たす場合に、フィードバック情報を取得し、そのフィードバック情報に基づいて推論特性を修正するように構成してもよい。この場合、フィードバック情報として、推論結果生成手段が推論結果を生成する際に用いた要求ベクトル、及び該推論結果の提示を受けたユーザの応答を示す応答データを用いることが考えられる。また、この場合、更に、フィードバック情報の履歴を、履歴記憶手段に記憶するように構成してもよい。
【００４５】
そして、推論特性修正手段は、応答データから生成される操作ベクトルと、フィードバック情報によって該応答データに対応付けられた要求ベクトルとの間に、予め設定されたしきい値以上の差異がある場合、或いは予め設定された一定期間内におけるフィードバック情報の履歴から、両ベクトルの間に予め設定されたしきい値以上の差異があると統計的に認められる場合に、修正条件を満たすものとし、この修正条件を満たした要求ベクトルに関わるルールである対象ルールに基づいて、推論特性の修正を行えばよい。
【００４６】
なお、推論特性修正手段は、推論特性を修正するために、具体的には、対象ルールの従属節を構成するスコアリングベクトルの値を変更してもよいし、対象ルールの条件節を構成する言語的或いは数値的な条件を変更してもよいし、対象ルールの条件節を構成する言語的或いは数値的な条件を細分化した新たなルールを追加してもよいし、対象ルールに基づいて新たな状況属性を設定し、この状況属性に対応するルールを追加してもよい。
【００４７】
また、推論特性修正手段は、推論特性を修正するために、要求ベクトル生成手段にて要求ベクトルを生成する際に、対象ルールの従属節を構成するスコアリングベクトルに対して用いるパラメータの値を変更してもよいし、条件節の判定に影響を与える状況データの記述、特に、ユーザの嗜好が少なくとも記述されたユーザプロファイルの記述を追加・変更してもよい。
【００４８】
また、本発明の推論システムでは、応答検出手段が、推論結果生成手段にて生成された推論結果の提示を受けたユーザからの応答を検出し、その検出された応答が、推論結果を肯定するものである場合、ルール強化手段が、その推論結果を得るために用いた要求ベクトルに関わるルールを強化対象ルールとし、該強化対象ルールを強化するように構成してもよい。なお、ここでは、「推論結果を否定する応答」がない場合も、「推論結果を肯定する応答」に含まれるものとする。
【００４９】
そして、ルール強化手段は、強化対象ルールの条件節について、該条件節の近傍を定義できる場合に、該近傍に含まれる条件節を有したルールも強化対象とするようにしてもよい。
【００５０】
但し、近傍のルールを強化する場合、その強化分を元となる強化対象ルールより抑えることが望ましい。なお、近傍とは、例えば、ルールの条件節を構成する状況属性が、元となる強化対象ルールと同様のカテゴリ（同じ部分ルール群）に含まれるもの等を挙げることができる。
【００５１】
そして、ルール強化手段は、強化対象ルールを強化するために、具体的には、要求ペクトル生成手段にて、強化対象ルールの従属節を構成するスコアリングベクトルから要求ベクトルを生成する際に用いるパラメータ（例えば、重み付け加算時に用いる重み係数）を変更してもよいし、強化対象ルールの従属節を構成するスコアリングベクトルの値を増大させてもよい。
【００５２】
このように、本発明の推論システムによれば、推論特性の修正や強化が可能とされているため、個人や状況に応じた適応化を動的に行うことができる。
次に第２の発明は、条件節に、予め設定された複数の状況属性の中のいずれか一つ又は複数に対する言語的或いは数値的な条件が記述され、従属節に、予め設定された複数の要求属性の各々に対応対する要求度を成分とするスコアリングベクトルが記述された多数のルールからなるルール群の視覚的表現方法であって、状況属性のうち二つを、二次元的に敷きつめられたタイル画像を個々に特定するための二次元アドレスに対応づける共に、要求属性のうち三つを、タイル画像の色を表現する３原色に対応づけたことを特徴とする。
【００５３】
つまり、ルールの記述にスコアリングベクトルを導入したことにより、ルール間の線形加重和処理が容易に行える
このように構成されたルール群の視覚的表現方法を用いれば、システム設計者やユーザは、タイル画像の色の分布から、ルール群の特徴（スコアリングベクトルの周期性や空間依存性など）を視覚的に把握することができる。具体的には、あるユーザのマクロ的特徴や異なるユーザ間の類似性、さらには多くのユーザに共通する統計的特徴も視覚的に把握することができる。また、このようにルール群の特徴を画像化することにより、ディスプレイ上で行う周知の画像処理方法を用いて、ルール群の編集・加工（同一ユーザ内／他ユーザ間でのルールの転写など）を容易に行うことができる。
【００５４】
更に、ルール群の表現に、ベクトル空間や画像表現を持ち込むことで、ルール群の更新履歴や、ある特定のパターンを有するルール（群）の検索や認識を容易に行うことができる。
【００５５】
なお、画像タイルを特定するための二次元アドレスには、状況属性の中でもルール設計に支配的な２条件を対応させ、残りの状況属性は、個々の画像タイルを複数の部分画像タイルで構成し、その部分画像タイルを特定するための相対アドレスに対応させるように構成してもよい。この場合、ルール群の特徴を表した単一の画像に、より多くの状況属性を反映させることができる。
【発明を実施するための最良の形態】
【００５６】
以下に本発明の実施形態を図面と共に説明する。
まず図１は、本発明が適用されたインタフェース装置１の構成を表すブロック図である。なお、本実施形態のインタフェース装置１は、自動車（車両）に搭載され、車両の乗員（主に、運転者）に対して、その車両に搭載された様々な機器等を用いた各種アプリケーション（例えば、映像表示，音楽再生，Ｗｅｂ検索，サーバ接続，音声認識など）の提供を、簡易なインタフェースによって実現するためのものである。
【００５７】
図１に示すように、本実施形態のインタフェース装置１は、アプリケーションの選択に使用する選択キー４１〜４３、及び各種指令やデータなどを外部操作によって入力するための操作キー群４４を備えた入力装置３と、各選択キー４１〜４３に対応付けられたアプリケーション名を表示するための割当アプリ表示部５１〜５３、及び提供中のアプリケーション名を表示するための提供アプリ表示部５４を備えた表示装置５と、画像を表示するためのディスプレイ７と、音声を入力するためのマイクロフォン８とに接続されている。
【００５８】
なお、操作キー群４４には、後述する処理に使用される開始キー，修正キー、及び状況データ（例えば、季節，天候，目的，目的地，情報，ユーザ状況など）の入力に使用する状況設定キーが少なくとも含まれている。
【００５９】
また、選択キー４１〜４３は、それぞれ割当アプリ表示部５１〜５３と一体に形成された押しボタンスイッチからなり、ディスプレイ７の下部に並べて配置され、車両の乗員（特に運転者）が認知し易くかつ操作し易い形状、色、大きさのものが用いられている。また、操作キー群４４及び提供アプリ表示部５４は、これら選択キー４１〜４３の近傍に配置されている。
【００６０】
また、インタフェース装置１は、車両の現在位置（現在地）の検出や経路案内などを行う周知のナビゲーション装置１１と、車内の空調を制御するエアコン装置１３と、カセットテープレコーダ，ＣＤ（コンパクトディスク）プレーヤ，ＭＤ（ミニディスク）プレーヤ，ラジオ，及びテレビなどからなるオーディオ装置１５と、周知のＶＩＣＳ（Vehicle Information and Communication System）の放送端末や、インターネットとの接続窓口であるインターネット放送端末との間で無線によりデータ通信を行う通信装置１７と、車速や加減速状態などの車両運転状態，車両内外の温度，及び雨滴の有無などを検出するための各種センサ１９と、車両のドアロック，窓ガラス（パワーウィンドウ），エンジン，及びブレーキ装置などを制御する他の制御装置（図示省略）とに接続されている。
【００６１】
なお、ナビゲーション装置１１は、車両の現在位置を検出するための周知のＧＰＳ装置や、地図データ，地名データ，施設名データなどの経路案内用データを記憶したＣＤ−ＲＯＭ、そのＣＤ−ＲＯＭからデータを読み出すためのＣＤ−ＲＯＭドライブ、及び、使用者が指令を入力するための操作キーなどを備えている。そして、ナビゲーション装置１１は、例えば、使用者から操作キーを介して、目的地と目的地までの経路案内を指示する指令とが入力されると、車両の現在位置と目的地へ至るのに最適な経路とを含む道路地図を、ディスプレイ７に表示させて経路案内を行う。
【００６２】
また、ディスプレイ７には、ナビゲーション装置１１によって経路案内用の道路地図が表示されるだけでなく、情報検索用メニューなどの様々な画像が表示され、更に、オーディオ装置１５がテレビのモードに設定されると、そのオーディオ装置１５に備えられたテレビチューナにより受信されたテレビの受信画像が表示される。
【００６３】
そして、インタフェース装置１は、ＣＰＵ，ＲＯＭ，及びＲＡＭなどからなるマイクロコンピュータを中心に構成されたシステム制御部２１と、システム制御部２１に入力装置３からの指令やデータを入力する入力インタフェース（Ｉ／Ｆ）部２３と、表示装置５を構成する各部５１〜５４の表示を制御する表示制御部２５と、ディスプレイ７の表示画面を制御する画面制御部２７と、マイクロフォン８から入力された音声信号をデジタルデータに変換してシステム制御部２１に入力する音声入力部２８と、上記ディスプレイ７，ナビゲーション装置１１，エアコン装置１３，オーディオ装置１５，通信装置１７，各種センサ１９，及び他の制御装置とシステム制御部２１とをデータ通信可能に接続する機器制御インタフェース（機器制御Ｉ／Ｆ）２９とを備えている。
【００６４】
また、インタフェース装置１には、通信装置１７によりインターネットから所望の情報を検索及び取得するために、インターネットのアドレス（インターネットアドレス）を記憶するインターネットアドレスデータベース３１と、検索制御部３３とが備えられている。そして、システム制御部２１が、検索制御部３３へ検索内容を表す検索キーワードを出力すると、検索制御部３３は、機器制御Ｉ／Ｆ２９を介し通信装置１７を動作させて、インターネット放送端末から上記検索キーワードに対応した情報を検索し、その検索結果をシステム制御部２１へ入力させる。また、インターネットアドレスデータベース３１には、検索制御部３３によって過去に用いられたインターネットアドレスが、システム制御部２１からの指令によって記憶され、検索制御部３３は、システム制御部２１から過去に入力した検索キーワードと同じ検索キーワードを受けると、インターネットアドレスデータベース３１内のインターネットアドレスを再利用する。
【００６５】
更に、インタフェース装置１には、If-Then 形式の推論ルールの条件節を記述したルールベース３５ａ、同じく推論ルールの従属節を記述したスコアリングベクトルテーブル（ＳＶＴ）３５ｂ、上記推論ルールを用いた推論結果とユーザの操作履歴とを対応づけて記述した状況記憶テーブル（ＳＭＴ）３５ｃを記憶するルール記憶部３５と、ユーザやユーザを取り巻く環境などの状況を示す状況データ（例えば、自然環境，情報環境，関心情報，ユーザ状況など）を記述した状況データファイル３７ａ、複数ユーザの個人情報を記述したユーザプロファイル３７ｂを記憶する状況データ記憶部３７とを備えている。
【００６６】
このうち、状況データファイル３７ａに記述される状況データは、ユーザの要求や行動に影響を与えるものであれば、例示されているもの以外のものを用いてもよい。また、状況データの例として挙げられている「自然環境」とは季節や天候のことであり、「情報環境」とは、各種情報を取得するための端末やネットワークに関する情報（例えば、端末機種，端末能力，ネットワーク能力など）のことである。また、「関心情報」とは、多くの人にとって重要な関心事となる情報（例えば「台風が近づいている」「ワールドカップが開催されている」など）のことである。また、ユーザ状況とは、その時々のユーザの行動（行動の目的や目的地），体調，気分などを示すものである。
【００６７】
ユーザプロファイル３７ｂに記述される個人情報は、個々のユーザの嗜好を、時間的状況（時間帯，季節，記念日など）、地理的状況、気分的状況などの様々な状況と対応付けて記憶したものである。
【００６８】
ルールベース３５ａは、図２に示すように、予め設定された状況属性の属性値毎、又は属性値の組み合わせ毎にルール番号を対応付けたテーブルである。但し、推論ルールには、条件節に状況属性が一つだけ記述される一次元ルールと、複数の状況属性が記述される階層的ルールとがあり、図２では、一次元ルールの場合の記述を（ａ）に、階層的ルールについての記述を（ｂ）に示す。
【００６９】
なお、状況属性としては、例えば「季節」「曜日」「時間帯」「目的」「目的地」「天候」などがあり、これら状況属性は、それぞれ、その状況属性に対する言語的或いは数値的な条件を表す複数の属性値（例えば、状況属性が「季節」であれば属性値は「春」「夏」「秋」「冬」）を有する。
【００７０】
また、ルールベース３５ａでは、他のものと組み合わせても重要度が大きく変化しない状況属性については、主として一次元ルールにて記述され、他のものとの組み合わせによって重要度が大きく変化する状況属性（例えば特殊事例や例外処理等を記述するもの）については、主として階層的ルールにて記述されている。しかも、ルールベース３５ａでは、一次元ルール及び階層的ルールに関わらず、個々のルール間の独立性が確保されるように構成されている。
【００７１】
更に、ルールベース３５ａには、機能（従属節に対応）や状況分類（条件節に対応）毎にグルーピングされた複数のルール群が記憶されている。
具体的には、「日本国内向け／アメリカ向け／中国向けのルール群」「男性／女性向けのルール群」「子供／大人向けのルール群」「仕事用／行楽用のルール群」などがあげられ、各ルール群は、図７の概念図に示すように、一部のルールを共有するように構成されていてもよい。
【００７２】
ＳＶＴ３５ｂは、図３（ａ）に示すように、ルールベース３５ａで規定されたルール番号Ｒｉ毎に、予め設定された要求属性の各々に対する要求度を成分とするスコアリングベクトルｖｉ、及びそのスコアリングベクトルｖｉの重要度を表す重み係数ｗｉを定義したテーブルである。
【００７３】
なお、要求属性としては、ユーザの欲求を表現したものが用いられ、例えば、「食べたい」「スポーツしたい」「リラックスしたい」「気分転換したい」「買い物したい」「おしゃれしたい」「誰かと話したい」「どこかへいきたい」「映画を見たい」「音楽を聴きたい」「ゲームしたい」などが挙げられる。
【００７４】
但し、本実施形態において、要求属性の属性値（即ち要求度）は、０〜１００の数値にて表現され、重み係数は０〜１の数値にて表現される。
また、ＳＶＴ３５ｂに記述される各スコアリングベクトルには、予め初期データが与えられており、その内容は、平均的なユーザの視点に基づいて設定されたものとされている。
【００７５】
そして、本実施形態では、一次元ルールのスコアリングベクトルについては、具体的には、多くのユーザの主観的判断に基づく属性値を、アンケート（インターネットの利用も考えられる）やプローブシステムを用いて集計し、その集計データを統計的に平均化した結果が初期データとして設定されている。
【００７６】
また、階層的ルールのスコアリングベクトルについては、ある少数の人間（システム開発者など）による主観的経験則（特定の条件の組み合わせに大きな意味がある状況の中で代表的なもの）を数値化したものが初期データとして設定されている。
【００７７】
但し、少数の人間による主観的経験則の集まりだけでは、ＳＶＴ３５ｂを構成する全てのスコアリングベクトル（多くのユーザが直面するすべての局面或いは状況を記述したルール群に対応するもの）を規定することは困難であるため、この少数の代表的な主観的経験則に基づいて、推論などの手法を用いることにより、ＳＶＴ３５ｂの未充填箇所が充填されている。
【００７８】
なお、ＳＶＴ３５ｂは、ルールベース３５ａを構成する全てのルール群に対して共通に使用するものを一つだけ備えていてもよいが、ルール群が機能毎にグルーピングされている場合は、ルール群毎に異なっていてもよく（即ち、複数のＳＶＴを備えていてもよい）、この場合、スコアリングベクトルの各成分に対応させる要求属性の種類や数（スコアリングベクトルの次元）も、ルール群毎に異なっていてもよい。
【００７９】
状況記憶テーブル（ＳＭＴ）３５ｃは、図３（ｃ）に示すように、上述の推論ルールを用いた推論処理の結果として、後述する選択キー設定処理に提供される要求ベクトル（アプリケーションベクトル）や、要求ベクトルに基づいた選択キー４１〜４３の設定に対するユーザからのフィードバック情報（アプリケーションの選択操作，選択キー４１〜４３の設定変更操作など）を、そのフィードバック情報が得られた日時と対応付けて記憶するためのテーブルである。
【００８０】
なお、ルール記憶部３５，状況データ記憶部３７と、前述したインターネットアドレスデータベース３１は、データの読み出しと書き込みとが可能な不揮発性メモリによって構成されている。
【００８１】
次に、以上のように構成されたインタフェース装置１において、システム制御部２１で実行されるメイン処理の概要を、図４に示す機能ブロック図、及び図５，６に示すフローチャートに沿って説明する。
【００８２】
なお、システム制御部２１を構成するＣＰＵは、メイン処理以外に、通信装置１７や各種センサ１９を介して収集した情報により、状況データファイル３７ａの内容を更新する状況データ更新処理等を実行する。
【００８３】
また、システム制御部２１を構成するＲＯＭには、これらメイン処理や状況データ更新処理を実行するためのプログラムの他、メイン処理内で実行するアプリケーション提供処理において必要となる処理や機器群の制御を実行するための各種アプリケーションプログラム（例えば、映像表示アプリ，音楽再生アプリ，Ｗｅｂ検索アプリ，サーバ接続アプリ，音声認識アプリなど）が格納されている。
【００８４】
図５に示すように、メイン処理が起動すると、まず、操作キー群４４の一つである開始キーが操作されたか否かを判断し（Ｓ１００）、開始キーが操作されていれば、ユーザの要求を推定する推論処理を実行する（Ｓ１１０）。
【００８５】
この推論処理では、図６に示すように、まず、状況データ記憶部３７から状況データファイル３７ａ及びユーザプロファイル３７ｂを読み込み（Ｓ２１０）、その読み込んだ内容に基づいて、ルール記憶部３５のルールベース３５ａの中から、現時点で使用すべきルール群を選択する（Ｓ２２０）。このとき、選択されたルール群に属するルールの総数をｍ個とし、以下では、これら各ルールをＲ１〜Ｒｍにて表すものとする。
【００８６】
そして、ルールの識別に用いるパラメータｉをゼロに初期化すると共に、選択されたルール群に対応するＳＶＴに基づき、ＳＶＴに記述されたスコアリングベクトルと同じＮ次元（成分数が同じ）の要求ベクトルＶを設定し、その要求ベクトルＶの各成分の値をゼロに初期化する（Ｓ２３０）。
【００８７】
その後、パラメータｉをインクリメントし（Ｓ２４０）し、Ｓ２１０にて読み込んだ内容から特定される現在状況に基づき、ルールＲｉの条件節に記述された条件が成立するか否かを判断する（Ｓ２５０）。
【００８８】
そして、ルールＲｉの条件節に記述された条件が成立する場合、ＳＶＴ３５ｂからルールＲｉのスコアリングベクトルｖｉと重み係数ｗｉを読み込み（Ｓ２６０）、（３）式に示すように、スコアリングベクトルｖｉに重み係数ｗｉを乗じたものを要求ベクトルＶに加算することで、要求ベクトルＶを更新して（Ｓ２７０）、Ｓ２８０に進む。
【００８９】
Ｖ←Ｖ＋ｗｉ＊Ｖｉ                                  （３）
一方、先のＳ２５０にて、ルールＲｉの条件節に記述された条件が成立しないと判断された場合、Ｓ２６０，Ｓ２７０を実行することなく、Ｓ２８０に進み、パラメータｉがルール総数ｍ以上（ｉ≧ｍ）であるか否かを判断し（Ｓ２８０）、ｉ≧ｍでなければ、選択したルール群の中で未処理のルールが存在するものとして、Ｓ２４０に戻って、上述の処理（Ｓ２４０〜Ｓ２７０）を繰り返す。
【００９０】
また、ｉ≧ｍであれば、選択したルール群に属する全てのルールについて上述の処理を終了したものとして、要求ベクトルＶの各成分に対応付けられた要求属性を、ユーザの欲求からアプリケーションに変換する属性変換処理を実行し（Ｓ２９０）、更に、属性変換処理が施された要求ベクトル（アプリケーションベクトル）Ｖａを、先のＳ２１０にて読み込んだユーザプロファイル３７ｂの内容に基づいて、ユーザ個人の視点が反映された要求ベクトル（アプリケーションベクトル）Ｖｐに変換する視点変換処理を実行して（Ｓ３００）、本処理を終了する。
【００９１】
つまり、Ｓ２４０〜Ｓ２７０の処理を繰り返すことにより、ヒット（条件が成立）した全てのルールのスコアリングベクトルについて重み付け加算した結果が、要求ベクトルＶとなる。
【００９２】
図８は、この処理を模式的に示した説明図である。但し、選択されたルール群が、Ｍ個の状況属性Ａ1 〜ＡM に関する一次元ルールのみからなる場合を例示したものである。
また、条件節に状況属性Ａi に関する条件のみが記載された一次元ルールを、（４）にて示すものとする。
【００９３】
Rule [Ａi,Ｃi(Ｊi), ｖi(Ｊi) ]                          （４）
Ｃi(Ｊi)：Ａi に関するルール群中のＪi 番目のルールの条件節
ｖi(Ｊi)：Ｃi(Ｊi)の成立時に獲得するスコアリングベクトル
即ち、各状況属性Ａi についての部分ルール群のそれぞれから、０又は１個のルールが選択され、選択されたルールに対応するＮ次元のスコアリングベクトルを、各座標軸Ｘ1 〜ＸN を状況属性にそれぞれ対応させたＮ次元座標上で重ね合わせることで、要求ベクトルＶが得られるのである。なお、図９は、より具体的に、状況属性として、「時間帯」「季節」「曜日」を用いた場合を例示したものである。
【００９４】
また、Ｓ２９０の属性変換処理では、各成分（要求属性）がＮ種類のユーザの欲求に対する要求度に対応付けられた要求ベクトルＶを、各成分（要求属性）がＬ種類のアプリケーション（コンテンツ）に対する要求度に対応づけられた要求ベクトル（以下では「アプリケーションベクトル」とも称する。）Ｖａに変換する。
【００９５】
アプリケーションベクトルＶａの要求属性としては、例えば「ニュース」「道路情報」「天気情報」「最寄施設情報」「地図表示」「落ち着いた音楽」などが挙げられる。
そして、アプリケーションベクトルＶａは、具体的には、累積（重み付け加算）処理により得られた要求ベクトルＶに対して、（５）に示すベクトル演算を施すことで算出される（図１０参照）。
【００９６】
Ｖａ＝ＰＶ＋ｆ                                      （５）
Ｐ：Ｎ次元ベクトルをＬ次元ベクトルに変換するＬ×Ｎ次元の変換行列
ｆ：アプリケーションベクトルＶａの統計的平均に相当するＬ次元の定数ベクトル
なお、変換行列Ｐは、例えば、共分散構造分析を用いることにより、過去の統計的データから求めることができる。共分散構造分析は、公知の手法であり、本発明の主要部とは関係がないため、ここではその説明を省略する。
【００９７】
また、Ｓ３００の視点変換処理では、アプリケーションベクトルＶａが、平均的（ニュートラル）なユーザの視点に対応する共通座標系Ｏを用いて表現されていると見なすことができるため、これをユーザの個人的な視点に対応する個人座標系に座標変換することで、視点変換を実現する。
【００９８】
この個人視点に対応する座標変換は、具体的には、Ｌ×Ｌ次元の座標変換行列ＲA とＬ次元の併進ベクトルｄA を用いて、（６）に示すベクトル演算を施すことで実現する。
Ｖｐ＝ ＲA（Ｖａ−ｄA ）                             （６）
なお、座標変換行列ＲA 及び併進ベクトルｄA  は、ユーザプロファイル３７ｂのデータとして予め設定しておけばよい。
【００９９】
例えば、簡単のため座標変換行列ＲA を単位行列Ｉとした場合、（６）は（７）にて表されることになる。
Ｖｐ＝ Ｖａ−ｄA                                        （７）
更に、アプリケーションベクトルＶａを２次元（Ｌ＝２）とし、要求属性を「ニュース」「ジャズ音楽再生」とし、アプリケーションベクトルＶａが（８）、併進ベクトルｄA が（９）で表される場合を考える。
【０１００】
Ｖａ＝（ニュースへの要求度、ジャズ音楽再生への要求度）t
＝（１００，８０）t                                 （８）
ｄA ＝（３０，−１０）t                                 （９）
（７）〜（９）に基づいて算出される座標変換後のアプリケーションベクトルＶｐは、（１０）で表される。
【０１０１】
Ｖｐ＝（７０，９０）t                                 （１０）
つまり、ある状況における「ニュースへの要求度」が、平均的なユーザにとって１００であると推測されたとしても、ユーザＡにとっては（ユーザＡの視点では）７０であり、ユーザＡは、平均的なユーザほどはニュースを要求していないことになる。一方、「ジャズ音楽再生への要求度」は、平均的なユーザにとって８０であると推測されたものが、ユーザＡにとっては９０となるため、平均的なユーザとユーザＡとでは、アプリケーションへの要求度が逆転することになる。
【０１０２】
図５に戻り、推論処理（Ｓ１１０）が終了すると、その推論結果として得られるアプリケーションベクトルＶｐに基づき、選択キー設定処理を実行して（Ｓ１２０）、Ｓ１００に戻る。
【０１０３】
この選択キー設定処理では、まず、アプリケーションベクトルＶｐの各成分に対応付けられたアプリケーション名を、成分値の大きい順、即ちユーザの要求度が高い順（以下「アプリケーション推奨順位」と称する。）に並べたアプリケーションリストを生成する。そして、アプリケーションリストの上位にある三つのアプリケーションを、選択キー４１〜４３にそれぞれ対応付けると共に、その対応付けたアプリケーションの名称又は該アプリケーションを示すラベルを、割当アプリ表示部５１〜５３に表示する。
【０１０４】
つまり、開始キーを操作すると、状況データファイルやユーザプロファイルの内容から、ユーザが要求すると推定されるアプリケーションのベスト３が選択され、選択キー４１〜４３に割り当てられる。換言すれば、インタフェース装置１が、状況に応じたアプリケーションをユーザに推奨するようにされている。
【０１０５】
次に、先のＳ１００にて、開始キーは操作されていないと判断された場合、今度は選択キー４１〜４３が操作されたか否かを判断し（Ｓ１３０）、選択キー４１〜４３が操作されていれば、操作された選択キーに対応付けられたアプリケーションを、機器制御Ｉ／Ｆ２９を介して接続された各種装置やセンサを用いて提供するアプリケーション提供処理を実行し（Ｓ１４０）、更に、アプリケーション提供処理のきっかけとなったユーザの操作（応答）を表すフィードバック情報と、Ｓ１１０の推論処理での推論結果（アプリケーションベクトルＶｐ又はＶａ、あるいは要求ベクトルＶ）とを対応づけて状況記憶テーブル３５ｃに保存する履歴保存処理を実行して（Ｓ１５０）、Ｓ１００に戻る。
【０１０６】
なお、Ｓ１４０のアプリケーション提供処理では、アプリケーションの提供を行うだけでなく、提供中のアプリケーションの名称又はそのアプリケーションを示すラベルを提供アプリ表示部５４に表示する処理を実行する。また、選択キーに特殊な操作（例えば長押し）が加えられた時には、先のＳ１２０にて作成されたアプリケーションリストに従って、操作された選択キーへのアプリケーションの対応付けを変更する処理等も実行する。
【０１０７】
また、Ｓ１５０の履歴保存処理では、アプリケーション提供処理にて選択キー４１〜４３が操作されることによるアプリケーションの提供が行われた時には、その提供したアプリケーションをフィードバック情報とし、また、選択キー４１〜４３に対応づけるアプリケーションの変更が行われた時には、その変更内容をフィードバック情報とする。
【０１０８】
また、この履歴保存処理により記憶される状況記憶テーブル３５ｃの内容（以下「操作データ」と称する。）は、別途起動される通信処理により、通信装置１７を介して外部の情報集積センターに送信される。
【０１０９】
なお、ここでは、選択キー４１〜４３のいずれかが操作された場合に、その操作された選択キーに割り当てたアプリケーションを駆動するようにされているが、選択キー４１〜４３に対するアプリケーションの割当が行われた後、直ちに、或いは予め設定された待機時間以上選択キー４１〜４３の操作がない場合に、アプリケーション推奨順位が最高位のアプリケーションの提供を自動的に行うように構成してもよい。また、このようなアプリケーションの自動提供が行われた場合も、ユーザから否定的な応答が無かった（ユーザが肯定的な応答をした）ことを示すフィードバック情報として、状況記憶テーブル３５ｃに記憶する。
【０１１０】
次に、先のＳ１３０にて、選択キー４１〜４３は操作されていないと判断された場合、今度は、予め設定された修正条件が成立したか否かを判断し（Ｓ１６０）、修正条件が成立していなければ、そのままＳ１００に戻り、修正条件が成立していれば、Ｓ１１０の推論処理における推論特性を修正する推論特性調整処理を実行して（Ｓ１７０）、Ｓ１００に戻る。
【０１１１】
なお、Ｓ１８０にて判定される修正条件は、次の（Ａ）〜（Ｄ）に示す通りである。
（Ａ）Ｓ１５０の履歴保存処理にて状況記憶テーブル３５ｃに記憶されたアプリケーションベクトルＶａ（即ち、推定された要求）と、フィードバック情報に基づいて生成される操作ベクトル（即ち、実際の要求）との間の差分（大きさ，角度など）が、予め設定されたしきい値以上である場合。
【０１１２】
（Ｂ）状況記憶テーブル３５ｃに記憶された過去一定期間以上の操作データ（アプリケーションベクトル，フィードバック情報）に基づき、統計的な判断を行った結果、（Ａ）に示す条件が顕著に認められた場合。
【０１１３】
（Ｃ）操作キー群４４を介して、ユーザが推論特性の修正要求を入力した場合。
（Ｄ）選択キー設定処理による設定に対して、ユーザから否定的な反応（即ち、割り当てられたアプリケーションを変更する操作）がなかった場合。
【０１１４】
そして、Ｓ１７０の推論特性調整処理では、（Ａ）又は（Ｂ）の修正条件が成立した場合には、アプリケーションベクトルと操作ベクトルとの間の差分が小さくなるように、そのアプリケーションベクトルＶａの生成に関わる部分の推論特性を修正する。
【０１１５】
但し、この場合、具体的には、以下の（ａ）〜（ｆ）が修正対象となる。
（ａ）スコアリングベクトルの値
（ｂ）ルールベースの記述（条件節の追加，細分化）
（ｃ）累積処理に用いるパラメータ（重み係数ｗｉ）
（ｄ）属性変換処理に用いる変換行列Ｐ、定数ベクトルｆ
（ｅ）視点変換処理に用いる座標変換行列ＲA 、併進ベクトルｄA
（ｆ）条件節の判定に用いるユーザプロファイルの記述
また、（Ｃ）の修正条件が成立した場合には、通信装置１７を介した情報集積センターとの通信により他装置で収集された操作データ群を取得し、その取得した操作データ群を用いるか、或いは状況記憶テーブル３５ｃに記憶された操作データ群を用いて、これら操作データ群に対して統計的な処理を施すことで抽出される新規ルールを、ルールベース３５ａやＳＶＴ３５ｂに追加する。
【０１１６】
また、（Ｄ）の修正条件が成立した場合には、選択キー設定処理に提供されたアプリケーションベクトルＶａの生成に関わる部分の推論特性（特に個々のルール）を強化する。この場合、上述の（ａ）（ｃ）が強化対象となる。そして、強化対象となったルール（中心ルール）の近傍を定義できる場合は、この近傍に属するルール（近傍ルール）も強化する。
【０１１７】
但し、近傍ルールについては、強化される値の増分が、中心ルールでの増分を超えることがないように、中心ルールでの増分に係数値（０〜１）を乗じたものを、その増分とするようにされている。また、近傍とは、例えば、条件節に記述される状況属性について、中心ルールに示された属性値と同一カテゴリーに属する属性値を持つルール等が考えられる。
【０１１８】
次に、先のＳ１６０にて、修正条件は成立していないと判断された場合、今度は、操作キー群４４を介してＳＶＴ３５ｂの初期データの設定要求が入力されたか否かを判断し（Ｓ１８０）、設定要求が入力されていれば、初期データ設定処理を実行して（Ｓ１９０）、Ｓ１１０に戻る。
【０１１９】
このＳ１９０の初期データ設定処理では、次の（ｉ）（ii）のいずれかを実行する。
（ｉ）操作キー群４４を操作することにより入力されたデータを、初期データとしてＳＶＴ３５ｂに格納する。但し、操作キー群４４での操作は、個々のデータを個別に設定するものであってもよいし、予め設定された定型的なテンプレート群の中から選択することで、複数のデータを一括して設定するものであってもよい。また、これらの入力の際には、予め用意された対話的支援ツールを用いることが望ましい。
【０１２０】
（ii）ユーザプロファイル３７ｂの記述内容に基づいて推論処理を行うことで生成されるデータを、初期データとしてＳＶＴ３５ｂに格納する。なお、この手法は、例えば、Ｓ３１０の視点変換を行わずに、ユーザ毎のＳＶＴを設定するシステムにおいて、すでに多くのユーザに対して実績のあるルールベース３５ａが存在している状態で、新規ユーザのＳＶＴを生成する場合等に好適である。これはルールを適応的に選択することにも相当する。
【０１２１】
更に、初期データ設定処理では、上述の手法によりルールベース３５ａに記述された全てのルール（ＳＶＴ３５ｂの全ての項目）について、スコアリングベクトルを個々に設定するには膨大な作業量を必要とするため、次のような転写処理を実行する。
【０１２２】
即ち、ある状況属性についての属性値が、いくつかのカテゴリーに分類可能な場合、その状況属性についての属性値が同一カテゴリーに属するルールからなる部分ルール群は、同じ初期データを持つものとして、その部分ルール群に属するいずれかのルールについてスコアリングベクトルが設定された場合に、その部分ルール群に属する他のルールにも、同じスコアリングベクトルを転写する。
【０１２３】
具体的には、状況属性が「目的地」である場合、目的地の記述についてのカテゴリーの一つとして「行楽地」が存在し、その「行楽地」カテゴリーには、「公園」「ガーデン」「アミューズメントパーク」「リゾート」「温泉」などが含まれるとする。そして、ルールＸとルールＹの条件節に状況属性「目的地」についての記述が存在し、その記述がルールＸでは「公園」、ルールＹでは「温泉」であり、他の状況属性についての記述が同等であると見なせるのであれば、両ルールＸ，Ｙに関するスコアリングベクトルの初期データは同じ値が設定されることになる。これはある意味で類推が実行されたことに相当する。
【０１２４】
以上説明したように、本実施形態のインタフェース装置１では、推論処理において、ある状況設定に対し複数のルールがヒットすることを許容し、しかも、ヒットした全てのルールのスコアリングベクトルを累積処理することで、推論結果を得るために必要な要求ベクトルを生成するようにされている。
【０１２５】
従って、本実施形態のインタフェース装置１によれば、複数のルールがヒットしても、局所最適に陥ることなく、ヒットしたルールを全体を見渡した最適な推論結果を得ることができる。
【０１２６】
また、本実施形態では、推論処理に複数のルール群を用い、しかもルール群毎に条件節の記述が独立したものとなるようにされているため、条件節に全ての状況属性を含む従来装置と比較して、設定すべきルール数を大幅に削減することができるだけでなく、ルールの追加修正、ひいては個人や状況への動的適応を容易にすることができる。
【０１２７】
また、本実施形態では、ルールの従属節をスコアリングベクトルを用いて記述することにより、個々のルールでは従属節にあいまい性を残したままで判断結果の特徴を表現することができるだけでなく、例外や特殊なケースに相当するルールも、簡単に追加することができる。この追加は、一次元ルールとして追加してもよいし、ある階層的ルールの中に条件分岐として追加してもよい。これらは基本ケースの持つ要求ベクトル値に対してある条件下で差分の要求ベクトルを付加することに相当する。
【０１２８】
また、本実施形態では、複数のルール群から、状況に応じたルール群を選択して使用するように構成されており、必要なルール群のみが限定的に用いられることになるため、推論処理を適応的かつ効率的（ひいては高速）に実行することができる。
【０１２９】
また、本実施形態では、スコアリングベクトルに用いる要求属性をユーザの欲求に設定し、スコアリングベクトルの累積後に属性変換処理を施すことにより、要求ベクトルＶの要求属性をユーザの欲求からアプリケーションに変換しているため、駆動可能なアプリケーションに追加，変更，削除があった場合に、スコアリングベクトルを何等変更することなく、属性変換の際に用いる変換行列Ｐを変更するだけで簡単に対応することができる。
【０１３０】
また、本実施形態では、スコアリングベクトルの要求属性の属性値を、平均的なユーザに基づいて設定し、属性変化処理後に、視点変換処理を施すことにより、アプリケーションベクトルに、ユーザの個人的な視点を反映させるようにされている。
【０１３１】
従って、ルール群（特にスコアリングベクトル）自体には、個々のユーザの特徴（視点）を反映させる必要がなく、全てのユーザに対して同じルール群を適用することができるため、ルールベース３５ａやＳＶＴ３５ｂの規模を必要最小限に抑えることができる。
【０１３２】
また、本実施形態では、初期データ設定処理の際に、全てのルールについて個々にスコアリングベクトルを設定するのではなく、ある状況属性において同じカテゴリーに属する属性値を有するルールについては、転写処理によって同じスコアリングベクトルを設定するようにされているため、初期データ設定処理での処理量を大幅に削減することができる。
【０１３３】
また、本実施形態では、推論結果やユーザからのフィードバック情報に基づいて推論特性の修正や強化を行うようにされているため、個人や状況に応じた適応化を動的に行うことができる。
【０１３４】
また、本実施形態では、階層的ルールを、目的や目的地ベースの記述を優先して判断するように構成しているため、ルールを効率良く記述することができる。即ち、ユーザ要求を推論する際には目的・目的地記述の情報が支配的であるためである。特に、目的地記述は、これを有効活用すれば、目的記述をダイレクトに端末やネットワークに残さないようにすることができるため、プライバシー保護の観点からも好ましい。
【０１３５】
ところで、初期データ設定処理において、上述の（ｉ）の処理を実現するには、初期データのテンプレート群を予め用意しておく必要がある。このテンプレート群を生成，編集するには、ルール群をディスプレイ上に視覚的に表現できることが望ましい。その際に、次のような表現方法を用いることができる。
【０１３６】
即ち、状況属性のうち二つを、二次元的に敷きつめられたタイル画像を個々に特定するための二次元アドレスに対応づける共に、要求属性のうち三つを、タイル画像の色を表現する３原色に対応づける。
【０１３７】
このように表現方法を用いれば、システム設計者やユーザは、図１３（ａ）に示すように、タイル画像の色の分布から、ルール群の特徴（スコアリングベクトルの周期性や空間依存性など）を視覚的に把握することができる。具体的には、あるユーザのマクロ的特徴や異なるユーザ間の類似性、さらには多くのユーザに共通する統計的特徴も視覚的に把握することができる。
【０１３８】
また、このようにルール群の特徴を画像化することにより、ディスプレイ上で行う周知の画像処理方法を用いて、ルール群の編集・加工（同一ユーザ内／他ユーザ間でのルールの転写など）を容易に行うことができる。つまり、ルールの記述にスコアリングベクトルを導入したことにより、ルール間の線形加重和処理が容易に行えるため、このような編集や加工、特に、図１３（ｂ）に示すようなルール群の重ね合わせ等が可能となるのである。
【０１３９】
更に、ルール群の表現に、ベクトル空間や画像表現を持ち込むことで、ルール群の更新履歴や、ある特定のパターンを有するルール（群）の検索や認識を容易に行うことができる。
【０１４０】
なお、画像タイルを特定するための二次元アドレスには、状況属性の中でもルール設計に支配的な２条件を対応させ、残りの状況属性は、個々の画像タイルを複数の部分画像タイルで構成し、その部分画像タイルを特定するための相対アドレスに対応させるように構成してもよい。この場合、ルール群の特徴を表した単一の画像に、より多くの状況属性を反映させることができる。
【０１４１】
本実施形態において、ルールベース３５ａ及びＶＳＴ３５ｂがルール記憶手段、状況記憶テーブル３５ｃが履歴記憶手段、Ｓ２３０〜Ｓ２８０がスコアリングベクトル抽出手段及び要求ベクトル生成手段、Ｓ１２０が推論結果生成手段、Ｓ２９０が属性変換手段、Ｓ３００が視点変換手段、Ｓ１９０が初期データ設定手段及び初期データ転写手段、Ｓ１７０が推論特性修正手段及びルール強化手段、Ｓ１５０が応答検出手段に相当する。
【０１４２】
以上本発明の一実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、様々な態様にて実施可能である。
例えば、上記実施形態では、階層化ルールの上位に目的記述や目的地記述の条件節を設定することで、効率的なルールの記述を可能としたが、これらを一次元ルールとして記述した場合でも同様の効果を得ることができる。例えば、｛レストラン、郵便局、銀行、会社、…｝といった目的地記述の属性がひとつ定義されていれば、情報検索やナビゲーションにおいて十分な効果を発揮することができる。時間記述を季節に着目して記述することも多元属性を一元化して効率的なルールの記述を可能とする例の一つである。
【０１４３】
また、上記実施形態では、スコアリングベクトルを累積してなる要求ベクトルＶに対して、属性変換や視点変換を施すことで、個々のユーザに適応化しているが、状況データファイルやユーザプロファイルの内容に応じたルール群の選択（Ｓ２２０）を行う際に、ＳＶＴ３５ｂの調整（スコアリングベクトルの動的な書換）も行うことで、個々のユーザに適応化するように構成してもよい。
【０１４４】
また、上記実施形態では、スコアリングベクトルに用いる要求属性をユーザの欲求に設定し、スコアリングベクトルの累積後に属性変換処理（Ｓ２９０）を施すことにより、要求ベクトルＶに用いる要求属性をアプリケーションに変換しているが、スコアリングベクトルに用いる要求属性を、最初からアプリケーションに設定し、属性変換処理（Ｓ２９０）を省略してもよい。
【０１４５】
また、上記実施形態では、属性変換を行った後に視点変換を行っているが、逆に視点変換を行った後に属性変換を行ってもよい。
また、上記実施形態では、座標変換をユーザ毎の視点変換に適用しているが、これに限らず、同一個人における動的な状況適応に対して適用してもよい。即ち、同一個人であっても、様々な状況に応じて視点が変化するため、視点変換の場合と全く同一のモデルを用いることができる。
【０１４６】
また、上記実施形態では、ＳＶＴ３５ｂとして平均的なユーザの視点に基づいて設定されたものを用いたが、ルール群の選択（Ｓ２２０）を行う際に、Ｓ２１０で取得した状況データやユーザプロファイルの内容に応じて、現在の状況やユーザに適応したものとなるように、ＳＶＴ３５ｂの設定値（初期データ）を変更するように構成してもよい。これは、Ｓ３００の視点変換処理と等価な処理であるため、このように構成した場合は、Ｓ３００の視点変換処理を省略すればよい。
【０１４７】
また、上記実施形態では、推論ルールを、ルールベース３５ａ，ＳＶＴ３５ｂを用いて記述したが、これらのようなテーブルを用いることなく、プログラミング言語で記述してもよい。この場合、条件節をIf文のネスティングで階層的に記述することになる。
【０１４８】
また、上記実施形態では、スコアリングベクトルの累積処理として、重み付け加算を行っているが、その他の累積処理を行ってもよく、その演算内容は線形でも非線形でもよい。また、上記実施形態では、ヒットするルールが検出される毎に、そのルールに対応するスコアリングベクトルを逐次累積処理するように構成されているが、ヒットしたルールのスコアリングベクトルを一時的にベクトルリストに格納し、全てのスコアリングベクトルが抽出されてから、重み係数の設定や累積処理を実行するように構成してもよい。
【０１４９】
また、上記実施形態では、属性変換処理を施すことにより、要求ベクトルＶをアプリケーションベクトルＶａに変換しているが、要求ベクトルＶとアプリケーションベクトルＶａとの間に、（５）式のような明確な関係が定義されていない場合には、図１２に示すように、要求ベクトルＶと、アプリケーションベクトルＶａとを、同一のベクトル空間で表現することが必要となる。その空間は、座標軸がユーザの欲求に対応した要求ベクトル空間でもよいし、さらに一般的な特徴空間でもよい。この場合、ユーザに関する視点変換に加えて、アプリケーションに関する視点変換も行う必要がある。具体的には、例えば、ユーザＡの視点に相当する座標系で、アプリケーションの特徴ベクトルＦ１〜ＦＬと、ユーザＡの視点の要求ベクトルＶＡとの間で、類似度計算を行い、類似度の高い順にアプリケーションの順序付けを行えばよい。
【図面の簡単な説明】
【０１５０】
【図１】実施形態のインタフェース装置の構成を示すブロック図である。
【図２】ルールベースの構成を示す説明図である。
【図３】スコアリングベクトルテーブル及び状況記憶テーブルの構成を示す説明図である。
【図４】インタフェース装置の機能ブロック図である。
【図５】システム制御部が実行するメイン処理の内容を示すフローチャートである。
【図６】推論処理の内容を示すフローチャートである。
【図７】ルール群の構成を示す模式図である。
【図８】スコアリングベクトルの累積処理の概要を示す説明図である。
【図９】累積処理の具体例を示す説明図である。
【図１０】属性変換処理の内容を示す説明図である。
【図１１】視点変換処理の内容を示す説明図である。
【図１２】視点変換処理の変形例を示す説明図である。
【図１３】ルール群の視覚的表現方法を示す説明図である。
【図１４】従来のルール構成を示す説明図である。
【符号の説明】
【０１５１】
１…インタフェース装置、３…入力装置、５…表示装置、７…ディスプレイ、８…マイクロフォン、１１…ナビゲーション装置、１３…エアコン装置、１５…オーディオ装置、１７…通信装置、２１…システム制御部、２３…入力Ｉ／Ｆ部、２５…表示制御部、２７…画面制御部、２８…音声入力部、２９…機器制御Ｉ／Ｆ、３１…インターネットアドレスデータベース、３３…検索制御部、３５…ルール記憶部、３５ａ…ルールベース、３５ｂ…スコアリングベクトルテーブル（ＳＶＴ）、３５ｃ…状況記憶テーブル（ＳＭＴ）、３７…状況データ記憶部、３７ａ…状況データファイル、３７ｂ…ユーザプロファイル、４１〜４３…選択キー、４４…操作キー群、５１〜５３…割当アプリ表示部、５４…提供アプリ表示部。
【図１】
2005258588.tif 000003
【図２】
2005258588.tif 000004
【図３】
2005258588.tif 000005
【図４】
2005258588.tif 000006
【図５】
2005258588.tif 000007
【図６】
2005258588.tif 000008
【図７】
2005258588.tif 000009
【図１４】
2005258588.tif 000010
【図８】
2005258588.tif 000011
【図９】
2005258588.tif 000012
【図１０】
2005258588.tif 000013
【図１１】
2005258588.tif 000014
【図１２】
2005258588.tif 000015
【図１３】
2005258588.tif 000016