JP3979009B2 - 制御情報出力装置及び情報システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、個々の状況に対応させて各種機器を動作させるための制御情報を出力する制御情報出力装置及び情報システムに関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
近年、コンピュータシステムの発達に伴い、コンピュータ制御される機器は多岐に渡るようになってきた。例えばテレビジョン受像機・ビデオレコーダ・電気冷蔵庫・電気炊飯器・エアコン・オーディオ機器・ゲーム機など、家庭用電気器具のほとんどがマイコン等のコンピュータシステムを搭載しており、このコンピュータシステムにて実行されるプログラムで動作する。また、自動車内を考えても、ナビゲーション装置によるルート案内をはじめ、インターネットを用いた施設検索まで可能となっている。
【０００３】
このようなコンピュータ制御によって、生活の各部で自動化が推進され、ユーザの有効な時間利用が促進される。例えば午前７時に朝食を摂りたいと思えば、電気炊飯器の炊きあがり時刻を午前７時にセットしておくだけで、その時刻に丁度炊けるように電源が入り動作するという具合である。
【０００４】
しかしながら現状、このようなコンピュータ技術の進歩により、ユーザの有効な時間利用が促進されているとは言えない状況がある。それは、操作自体は簡単になってきているが、ユーザ自らが個々の状況に対して要求・設定などを行わなければならないためである。上述した例で言えば、炊きあがり時刻を午前７時にするように、ユーザ自らが設定を行う必要があった。つまり、いくらコンピュータシステムを搭載していると言っても、電気炊飯器自体が、ユーザに先回りして炊きあがり時刻を自動設定することはない。
【０００５】
一方、このように炊きあがり時刻が７時になるように電気炊飯器を動作させたいといったユーザ要求は種々の要因から決定できるものであり、このようなユーザ要求がある程度の確率で決定できれば、電気炊飯器に限らず、上述したような家庭電気器具を総合的に、しかも、半自動的にセットアップして使用することができる。
【０００６】
例えば特許第２６９５５４２号公報には、ユーザに関する情報を管理し、ユーザの特質に沿った情報処理を行う装置が開示されている。また、特開平７−２６１９９４号公報には、現象と行動とを対応付けてソフトウェアをカスタマイズする方法が開示されている。前者はメッセージパターンのマッチングを行うというパターン化の手法であり、後者は現象・行動を類型化するという、これもパターン化の手法である。
【０００７】
ところが、上述した例では、ユーザの操作対象となる機器が多岐に渡り、また、それら機器に対するユーザ要求が様々な要因から生じるため、公報記載の技術を適用することは困難である。ユーザ行動などのパターン化には限界があるためである。
【０００８】
本発明は、上述した問題を解決するためになされたものであり、操作対象となる機器、及び当該機器に対してユーザ要求を発生させる種々の要因を統括的に捉え、対象機器を総合的に、しかも、半自動的にセットアップして動作させるための構成を提供することを目的とする。
【０００９】
【課題を解決するための手段及び発明の効果】
上述した目的を達成するためになされた請求項１に記載の制御情報出力装置は、記憶手段に依存情報を記憶している。この依存情報は、対象機器にて実行されるアプリケーションプログラムと前記アプリケーションプログラムのそれぞれに対するユーザの要求がどの要因に依存して変化するかを示す依存性要因とを対応付けた情報である。そして、制御情報出力手段は、この依存情報に基づき、制御情報を出力する。
【００１０】
ここで「対象機器にて実行されるアプリケーションプログラム」とは、上述したような各種機器などに搭載されるアプリケーションプログラムや対象機器としてのパーソナルコンピュータ等に搭載されるアプリケーションプログラムを意味する。つまり、本発明では、対象機器をそれらに搭載されたプログラムの単位で捉えるのである。なお、対象機器がパーソナルコンピュータに相当する場合には、本装置がこのパーソナルコンピュータ内部に設けられる構成であってももちろんよい。
【００１１】
対象機器をそれらに搭載されたプログラムの単位で捉えることを、例えば電気炊飯器とビデオレコーダとが対象機器となる場合を例に挙げて説明する。このとき、電気炊飯器にＡ及びＢの２つのアプリケーションプログラムが搭載されており、ビデオレコーダにＣ〜Ｅの３つのアプリケーションプログラムが搭載されているとすれば、対象機器にて実行されるアプリケーションプログラムは、Ａ〜Ｅの５つのアプリケーションプログラムとなる。なお、アプリケーションプログラムという表現を用いたのは、コンピュータシステムの基本動作を実現するオペレーティングシステムなどのプログラムと区別する意図である。また、ここでいう「アプリケーションプログラム」には、大規模のものから、上述した家庭用電気器具に組み込まれるマイコンにて実行される、スイッチ等のハードウェアに対してオン／オフ動作などを行う小規模なものまで含まれる。
【００１２】
また、「依存性要因」は、例えば、ユーザ要因・システム要因・メディア要因の少なくとも一つを含むものとすることが考えられる（請求項２）。
ユーザ要因とは、ユーザに関連する要因であり、ユーザの置かれた環境・状況やユーザの要求・状態などに関連するものである。例えば環境・状況には、時刻、場所、仕事内容、雑音の有無といった周囲条件などが挙げられる。また例えば要求・状態には、「食べたい」、「休憩したい」といった生活ニーズ、趣味などが挙げられる。その他ユーザに関連する要因としては、ユーザの嗜好性などが考えられる。
【００１３】
システム要因とは、制御情報によって制御されるシステムに関連する要因であり、例えば次のようなものが含まれる。メモリ容量、並行して実行可能なアプリケーションプログラムの数、処理能力、動作環境をはじめ、通信を行うことを前提とし、通信条件、通信コスト、また、ディスプレイなどの表示機器を備えることを前提とし、画面サイズといった表示デバイス条件などを挙げることができる。ここで「システム」としたのは、上述した対象機器の要因だけでなく、本装置側の要因も、また対象機器を制御する制御装置が存在する場合には、その制御装置の要因をも含める意図である。
【００１４】
メディア要因とは、アプリケーションプログラムの処理対象となるメディアに関する要因である。これには、ＤＶＤ，ＣＤ−ＲＯＭといったメディアのタイプ、メディアに格納されるコンテンツに関する情報、例えばジャンル、製作者、日時、場所などが含まれる。
【００１５】
本発明では、上述したようなアプリケーションプログラムと、アプリケーションプログラムのそれぞれに対するユーザの要求がどの要因に依存して変化するかを示す依存性要因とを対応付けた依存情報を記憶しておく。例えば、上述した電気炊飯器の自動炊飯アプリケーションはユーザ要因である時刻、生活ニーズに依存するという具合である。そして、このような依存情報に基づく制御情報を出力する。より具体的には、ユーザからの指示情報または外部の状況を示す状況情報を取得し、取得した指示情報または状況情報に基づき、依存情報を参照して、対象機器の動作・設定に利用される制御情報を生成して出力する。
【００１６】
つまり、ユーザの操作対象となる様々な機器をアプリケーションの単位で捉え、これらアプリケーションプログラムと、これらアプリケーションプログラムへの要求を生じさせる各種要因との間に依存性という概念を導入した。これによって、操作対象となる機器、及び当該機器に対してユーザ要求を発生させる種々の要因を統括的に捉えることができる。そして、制御情報に基づき対象機器がそれに応じた動作を行うように構成すれば、対象機器を総合的に、しかも、半自動的にセットアップして動作させることができる。電気炊飯器の例で言えば、ユーザ要因である時刻に自動炊飯アプリケーションが依存することを示す制御情報に基づき、ユーザが炊飯時刻を一度設定した後には、その炊飯時刻を記憶しておき、ユーザが単に炊飯動作の開始を指示するだけで、炊きあがり時刻を前回の予約時刻に設定するか否かをユーザに問い合わせるように動作させることができる。
【００１７】
なお、依存情報は、アプリケーションプログラムと依存性要因とを対応付ける２次元テーブルとして記憶することが考えられる。例えば横の欄に依存性要因を記述し、縦の欄にアプリケーションプログラムを記述した２次元テーブルとして記憶するという具合である。このとき、アプリケーションプログラムと依存性要因とがクロスする欄に、依存しているか否かの情報を記述する。例えば、依存している場合には「Ｄ」を記述し、依存していない場合には空白にすることが考えられる。また、依存していることを示す「１」と依存していないことを示す「０」で記述してもよい。このような数値を用いてテーブルを記述すれば、依存情報をブール行列として計算上用いることもできる。
【００１８】
さらにまた、依存しているか否かという２値の情報だけでなく、依存度合いである依存度を表現できるようにしてもよい。例えば依存度合いが最も高い「１０」から依存していないことを示す「０」までといった多値の情報をテーブルに記述できるようにするという具合である。このようにすれば、各種の依存性要因に重み付けを行うことができ、ユーザ要求を細かく決定することができる。したがって、ユーザのフィーリングにより合った機器制御を行えることになる。
【００１９】
ところで、「依存する」という状態をどのように定義するかが問題となるが、例えば請求項３に示すようにして定義すればよい。
ここでいう依存性要因値とは、例えばユーザ要因である時刻を１日の単位で考えれば、依存性要因値は、午前０時から午後１２時までの時刻となる。また、ユーザ要因である場所を考えれば、依存性要因値は、レストラン、公園、スポーツ施設、会社、自宅、車内などという値となる。前者は連続的なものとして、後者は離散的なものとして考えることができる。
【００２０】
例えば文書作成を行うためのアプリケーションプログラムは、勤務時間内にはその要求度が高くなり、勤務時間外では要求度が低くなるという具合に、時刻という要因に対して要求度が相対的に大きく変動するという状況が考えられる。したがってこの場合、文書作成アプリケーションは、ユーザ要因である時刻に依存するものといえる。
【００２１】
要求度が依存性要因値に対して相対的に大きく変動する場合を、さらに具体的に定義すれば、例えば請求項４に示すような場合とすることが考えられる。
ここでは、要求度の変動を定量的に判断する。また、依存性要因値と要求度との対応関係である依存特性が時間経過に対して一定又は規則性を有することを条件とした。例えば１日の中で時刻に対して要求度が大きく変動するアプリケーションプログラムであっても、要求度の変動が日々異なる場合には、時間に対する依存性があるとは言えないからである。
【００２２】
なお、制御情報出力手段が依存情報に基づいて制御情報を出力することは既に述べた。
この制御情報は、依存情報そのものであることが考えられる。この場合、依存情報の一部を出力する場合も含まれる。また、依存情報に加えあるいは代え、依存性要因値と要求度との対応関係である依存特性を制御情報として出力することが考えられる。このような依存特性に基づけば、ユーザ個々に依存特性が異なる場合にも、各ユーザに合わせた細かな制御が可能となる。
【００２３】
さらに、上述した情報に加え又は代え、依存性要因リストを制御情報として出力してもよい。相対的に有効であると想定される依存性要因のリストを出力すれば、対象機器側で有効な依存性要因に基づく制御が可能となるためである。このように相対的に有効であると想定される依存性要因のリストを出力するのは、依存情報によって判断できる依存性要因であっても、周囲条件などによって依存性要因値の信頼度が低くなり、依存性要因が不適切なものとなる可能性があるためである。また、依存特性から算出される要求度が低い場合にも、有効な依存性要因ということはできない。
【００２４】
このような依存性要因リストは、依存性要因の有効度合いに応じて複数レベルに階層化して出力することが考えられる（請求項５）。
なお、相対的に有効であると想定される依存性要因は、周囲条件や要求度など応じて判断することが考えられる。また、依存性要因値を取得する依存性要因値取得手段を備える構成とし、この依存性要因値取得手段にて取得される依存性要因値に基づいて判断してもよい。例えば依存性要因値が所定の範囲内の値となっていない場合を判断するという具合である。
【００２５】
依存性要因値取得手段を備える構成を前提とすれば、依存性要因値を制御情報として出力するようにしてもよい。この依存性要因値の出力においても、上述した依存性要因リストと同様に、相対的に有効であると想定される依存性要因に対応する依存性要因値を制御情報として出力することが考えられる。
【００２６】
さらにまた、上述した情報に加え又は代え、制御情報出力手段は、相対的に実行要求の高いアプリケーションプログラム判断し、アプリケーションリストを制御情報として出力することが考えられる。このようなアプリケーションリストを出力すれば、対象機器側において、アプリケーションプログラムを迅速に起動したり、起動準備、例えばメニューの最初にそのアプリケーションプログラムに関するメニューを表示するといった制御ができる。
【００２７】
なお、このようなアプリケーションリストは、直接的なユーザ要求に基づいて作成してもよい。
具体的には、依存性要因値及び依存特性を用い依存性要因に対する要求度を求め、当該要求度に基づいて相対的に実行要求の高いアプリケーションプログラムを判断することが考えられる。要求度が所定値以上となったアプリケーションプログラムを、実行要求の高いものと判断するという具合である。このアプリケーションプログラムへの要求度は、依存性要因に対して個々に求められるものである。したがって、実行確信度に基づいて相対的に実行要求の高いアプリケーションプログラムを判断するようにしてもよい。例えば、各依存性要因に対する要求度を平均し、この平均に基づき、相対的に実行要求の高いアプリケーションプログラム判断するという具合である。
【００２８】
このようにして得られる実行確信度が相対的に高いアプリケーションプログラムは確かにユーザ要求に沿ったものである可能性が高いが、所定のアプリケーションプログラムへのユーザ要求は実行中のアプリケーションプログラムに多分に関連していることがある。したがって、記憶手段に記憶されたアプリケーションプログラム間の従属関係を参照して補正した実行確信度に基づき、相対的に実行要求の高いアプリケーションプログラムを判断する構成を採用することが好ましい。例えば文書作成アプリケーションと共に表計算アプリケーションが使用される可能性が高いという事実があれば、表計算アプリケーションが文書作成アプリケーションに従属するという従属関係を記憶しておく。このようにすれば、より適切なアプリケーションプログラムの起動・起動準備が実現される。
【００２９】
ところで、相対的に実行要求の高いアプリケーションプログラムを判断すれば、依存性要因値が確定していない依存性要因に対する要求度が推定できる。そこで、請求項６の構成を採用することが考えられる。確定した依存性要因値に対しては要求度が算出可能であるため、それら算出された要求度と同様の要求度であるとして、未知の依存性要因値を推定することができる。ここで相対的に実行要求の高いアプリケーションプログラムには、ユーザが直接的に選択したアプリケーションプログラムも含まれる。
【００３０】
なお、以上のようなアプリケーションリストは、依存性要因リストと同様に、実行要求度合いに応じて複数レベルに階層化して出力することが考えられる（請求項７）。
ところで、依存特性や依存情報は、一度作成された後は固定的な情報として用いてもよいが、ユーザからのアプリケーションプログラムの選択状況などから動的に学習されることが望ましい。
【００３１】
そこで、請求項８に示すように、依存特性を統計的に学習変更するようにするとよい。これによって、ユーザの行動パターンが変わっても、依存性要因から常に適切な要求度を算出することができる。また、制御情報出力手段は、依存特性の学習変更に応じて依存情報をも学習変更することが考えられる（請求項９）。すなわち、依存特性の変化によって、アプリケーションプログラムが依存するとされていた依存性要因に依存しなくなる可能性がある。逆に依存しないとされていた依存性要因に依存するようになる可能性がある。そこで、上述したような依存性の定義に照らし合わせ、自動的に依存情報を学習変更するようにする。これによって、情報処理装置側では、ユーザの行動パターンが変わっても、適切な処理が実行可能となる。
【００３２】
なお、制御情報出力手段は、制御情報を通信手段を介して外部装置へ出力することが考えられる（請求項１０）。また、制御情報を着脱可能な記録媒体に出力するようにしてもよい（請求項１１）。例えば小型のメモリカードなどの記録媒体に出力するという具合である。また、特に記憶容量の限られた記録媒体に出力する場合などを考えると、制御情報を符号化して出力するようにすることが望ましい。
【００３３】
以上は、制御情報出力装置の発明として説明してきたが、本発明は、上述した制御情報出力装置と、制御情報出力手段によって出力される制御情報に基づく処理を行う情報処理装置とを備えていることを特徴とする情報システムの発明として実現することもできる（請求項１２）。なお、符号化した制御情報が出力される場合、情報処理装置は、制御情報を復号化する復号化手段を備える構成とする（請求項１３）。
【００３４】
情報処理装置は、具体的に、請求項１４に示すようなサーバ装置であることが考えられる。このときは、制御情報として依存性要因リスト、依存特性などを出力する前提の下、適切な範囲でデータベース検索を行うことができる。
また、情報処理装置は、記録媒体へ出力された制御情報を読み込んで動作する対象機器であることが考えられる（請求項１５）。例えば記録媒体から制御情報を読み出して動作するテレビジョン受像機として実現されるという具合である。この場合は、ユーザ要因である時刻にテレビジョン受像機の電源オン／オフアプリケーションやチャンネル設定アプリケーションが依存するといった依存情報及び、時刻に係る依存特性を制御情報として出力する。これによってテレビジョン受像機側では、計時手段によって時刻を取得し、取得した時刻に基づいて、自動的に電源のオン／オフを行ったり、あるいは、自動的にチャンネルの切り替えを行ったりすることができる。そして、記録媒体に出力するようにすれば、別のテレビジョン受像機も、その記録媒体を差し込むことによって同様に動作させることができる。例えばユーザは自己の情報を記録媒体に記録して持参すれば、旅行先のテレビジョン受像機を自分の生活パターンに合わせて自動的に動作させるといったこともできる。
【００３５】
さらにまた、情報処理装置は、制御情報を読み込んで複数の対象機器を制御する制御装置であってもよい（請求項１６）。この制御装置は、例えば車室内などにおける対象機器としてのナビゲーション機器、オーディオ機器、検索機器、通信機器などを総合的に制御するものであることが考えられる。例えば、オーディオ機器のＣＤ再生アプリケーションが、混雑しているか否かという周囲状況に依存し、検索機器のレストラン検索アプリケーションが、時刻に依存するという制御情報が出力されるとする。このとき制御装置は、例えば、混雑時にオーディオ機器にてＣＤの自動再生を行い、昼時になったらレストラン検索が即座に行えるようにレストラン検索アプリケーションを自動的に起動するという具合に動作する。
【００３６】
また、複数の対象機器を制御情報出力装置からの制御情報で動作させることを考えると、制御情報出力装置は、複数の対象機器を操作するリモートコントロール端末（以下「リモコン」という。）であり、情報処理装置は、リモコンから送信される制御情報を読み込んで動作する対象機器であることが考えられる（請求項１７）。
【００３７】
なお、請求項１４に示したようなデータベース検索を行うシステムを考える場合、プログラムだけでなく映像データなどのコンテンツを含めて「アプリケーション」として捉え、依存情報に基づくアプリケーション検索を行うことが考えられる。
【００３８】
すなわち、請求項１８に示すように、依存情報に基づく制御情報を出力する制御情報出力装置と、出力された制御情報に基づきアプリケーションを検索するサーバ装置とを備える情報システムの発明として実現してもよい。
具体的には、上述の情報システムは、請求項１〜９のいずれかに記載の制御情報出力装置と、前記制御情報出力手段によって出力される前記制御情報を利用して、アプリケーションの検索を行う検索手段を有したサーバ装置とを備えていることを特徴とする。
例えば映像データなどのアプリケーション検索を行おうとすると、内容記述データであるメタデータを用いることが考えられるが、メタデータのデータサイズが１Ｋバイトを超えてしまう場合も存在する。したがって、検索対象が数百万件を超えるオーダーになる場合は、Ｇバイトオーダーのメタデータ通信が必要になる。さらに、ユーザ自信も数百万人を超えるとなると、通信インフラやデータベースサイトの通信トラフィック量から、現状の最高性能の計算機を持ってしてもリアルタイム処理が困難な状況が発生する。
【００３９】
これに対して、依存情報に基づくアプリケーション（コンテンツ）検索を行えば、依存性という概念によってアプリケーションやユーザ要求などを総括的にまた簡単に表現でき、しかも、データ量が抑えられるため、高速検索が可能になり、膨大な数のコンテンツが複数のデータベースサイトにわたって分散して存在する状況下においても、効率的な検索が可能になる。
【００４０】
なお、この情報システムにおける制御情報出力装置を、請求項２〜９のいずれかに示した制御情報出力装置と同様に構成できることは言うまでもない。また、このような検索処理の効率化を図るために、制御情報出力装置やサーバ装置は、依存性要因のとり得る依存性要因値を量子化できる構成としてもよい（請求項１９）。ここでいう量子化は、例えば連続的な依存性要因値としての時間情報を「朝」、「昼」、「夜」や、「春」、「夏」、「秋」、「冬」という依存性を表すのに有効な時間情報として捉えるための処理をいう。この量子化に係る情報は、例えば量子化テーブルとして用意しておくことが考えられる。
【００４１】
ところで、アプリケーション検索は具体的には次のようにして行うことが考えられる。例えば、予め定められた依存性要因にアプリケーションが依存するか否かを示すアプリ依存情報をサーバ装置が記憶しており、このアプリ依存情報に基づいて検索するという具合である（請求項２０）。ここで特に、ユーザ要求としての依存ベクトルが制御情報出力装置から出力される前提の下、アプリ依存情報に含まれる特性ベクトルとの内積演算によって検索を行うことが考えられる（請求項２１）。このようなベクトルの内積演算によって検索を行えば、検索処理に要する時間のさらなる短縮が実現できる。
【００４２】
なお、特性ベクトルは、アプリケーションの詳細データから自動生成できる構成にするとよい（請求項２２）。アプリケーションの詳細データとは、例えばアプリケーションが映像データといったコンテンツである場合、そのコンテンツに含まれるメタデータであることが考えられる。そして、このように生成された特性ベクトルは、テーブル形式などで記憶しておくことが望ましい（請求項２３）。一度生成した特性ベクトルを記憶するようにすれば、次の検索時にその特性ベクトルを再利用できるからである。
【００４３】
また、依存ベクトルや特性ベクトルは、依存の度合いである依存度も表現可能にするとよい（請求項２４）。このようにすれば、依存するか否かだけでなく、依存のレベルが判断できるため、より詳細な検索が可能になる。
このようなベクトルを用いてより詳細な検索を行うためには、依存ベクトル及び特性ベクトルの成分が、依存性要因のとり得る依存性要因値に対する依存具合を表現するようにしてもよい（請求項２５）。例えば図１５に示すように、依存性要因である時間Ｔｓに対する要求度の高まりを「０」又は「１」で表現する。そして、図中で１２月〜翌年１１月までの要求度の変化を示す「１０１０」を２進表現と考えてベクトルの成分とすれば、依存性要因に依存するか否かだけでなく、その依存具合を表現することができる。もちろん、要求度（図中の縦軸）についても多値表現すれば、より高度な検索が可能になる。
【００４４】
ただし、検索処理時間の短縮という観点からは、依存ベクトル及び特性ベクトルを、その成分が「０」又は「１」の２値で表現される依存性符号として実現することが望ましい（請求項２６）。
そしてさらに検索効率を向上させるために、上述した内積演算において、検索に係る依存性要因の中の所定要因に対する成分のみの演算を行うことが考えられる（請求項２７）。これに加え又は代え、検索に係る依存性要因に対する成分に優先順位を付けて計算し、各成分毎に予め定められた基準を満たさない場合、演算を途中で停止するようにしてもよい（請求項２８）。予め定められた基準を満たすか否かは、各成分の演算終了時に、アプリケーションの詳細データを考慮して判断するという具合である。これらの構成を採用すれば、内積演算に要する時間を短縮することができ、その結果、コンテンツ数が膨大になる場合には特に、検索効率を向上させることができる。
【００４５】
以上のように、依存性を用いた検索を行えば、高速検索に寄与できる。そして、アプリケーション（コンテンツ）の相互運用性を向上できる。つまり、別のジャンルに分類されたアプリケーションをも容易に検索することができる。例えば、カラオケ映像に類した映像を取得したいとのユーザ要求に対し、例えば広告・宣伝映像などがその検索条件にマッチして取得されるという具合である。また、アプリケーションの特性が明確に記述されていなくても、検索対象を絞り込める。さらに、アプリケーションの特性を一意的な代表値に自動的に置きかえることが困難な場合にも有効である。例えばある映像データが様々な時間帯や場所にわたるシーンで構成されている場合など、時間と場所とを自動的に代表値で記述することは難しいためである。
【００４６】
そして、このようにして絞り込まれたアプリケーションに対して、アプリケーションの詳細データに基づく２次検索を行うことが考えられる（請求項２９）。このように依存情報による１次検索で絞り込んだアプリケーションに対して２次検索を行えば、より適切な検索結果が得られると共に、検索処理全体の効率を向上させることができる。
【００４７】
なお、上述した発明は、アプリケーションを依存情報を用い表現することによって、アプリケーションの検索を効率化するものである。このように、依存性という概念でアプリケーションを捉えれば、種々のアプリケーションを普遍的に表すことができる。
【００４８】
すなわち、請求項３０に示すように、ユーザ側のアプリケーションをユーザ側依存情報によって表現し、サーバ側のアプリケーションをサーバ側依存情報で表現することが考えられる。この場合、サーバ装置は、ユーザ側とサーバ側のアプリケーションとを関連付けて動作する。
具体的には、上述の情報システムは、請求項１〜９のいずれかに記載の制御情報出力装置であって、前記依存情報のうちユーザ側で予め定められた依存性要因に依存するか否かを示すユーザ側依存情報によってユーザ側のアプリケーションを表現し、前記ユーザ側依存情報に基づき制御情報を出力する制御情報出力装置と、サーバ側で予め定められた依存性要因に依存するか否かを示すサーバ側依存情報によってサーバ側のアプリケーションを表現し、前記制御情報に基づき、前記ユーザ側のアプリケーションと前記サーバ側のアプリケーションとを関連付けて動作するサーバ装置とを備えたことを特徴とする。
【００４９】
アプリケーションは時代とともに変化し、国や文化によっても異なる。一方、相互運用性のあるデータベースは継続して使用され得る。したがってアプリケーション名でコンテンツを分類することは特定サービスを想定して作ったコンテンツ以外では困難である。しかしながら、たとえば芸能界アイドル、渋滞情報、ニュース、観光情報などを考える場合、それらを扱うアプリケーションやコンテンツに対するユーザの視点は変わりうるが、基本的な評価属性としては一定かつ普遍的なものが存在すると考えられる。
【００５０】
そこで、上述したように、ユーザ側及びサーバ側依存情報を、例えば普遍的な依存性要因で表現すれば、普遍的なアプリケーション記述を行うことができる。
このとき、上述した依存性符号でアプリケーションを表現してもよい（請求項３１）。また、次々にアップロードされる映像データであるアプリケーションに対応させてサーバ側依存情報を記憶するために、アプリケーションを特定する言語表現と前記サーバ側依存情報との対応関係テーブルを用意し、入力情報に従い、サーバ側依存情報を自動的に付加するようにしてもよい（請求項３２）。
【００５１】
【発明の実施の形態】
以下、本発明を具体化した実施例を図面を参照して説明する。
［第１実施例］
図１は、第１実施例の制御情報出力装置１の構成を示すブロック図である。
【００５２】
制御情報出力装置１は、制御部１０と、この制御部１０に接続された入力部２０、状況取得部３０、出力部４０、メモリ部５０及び表示部６０を備えている。
制御部１０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏなどを備えたいわゆるコンピュータシステムである。
【００５３】
入力部２０は、ユーザからの指示情報を入力するための構成であり、キーボードやマウス等のポインティングデバイスで構成されている。
状況取得部３０は、時々刻々変化する状況をデータとして取得するための構成である。具体的には、外部装置から送信される様々な状況情報を取得する通信デバイスとして構成したり、様々な状況情報を取得する複数のセンシングデバイスで構成したり、あるいは、その両方のデバイスで構成したりすることが考えられる。
【００５４】
出力部４０は、制御部１０にて生成される制御情報を外部出力する構成である。出力部４０から出力される制御情報は、対象機器７０の動作・設定に利用される。したがって、対象機器７０への送信を行うための通信デバイスとして構成することが考えられる。また、複数の対象機器７０を制御する制御装置７１への送信を行う通信デバイスとしてもよい。さらに、最終的に対象機器７０の動作・設定に制御情報が利用できればよいため、所定フォーマットのプロファイルとしてファイル出力する構成としても、また、記録媒体への書き込みを行う構成としてもよい。
【００５５】
メモリ部５０は、情報記憶のための構成であり、例えばハードディスク装置として実現することが考えられる。また、半導体メモリ装置として実現してもよい。このメモリ部５０には、「依存情報」としての依存性テーブル５０ａ、「依存特性」としての依存特性情報５０ｂ及び「従属関係」としての従属性テーブル５０ｃが記憶されている。
【００５６】
表示部６０は液晶やＣＲＴを用いたディスプレイ装置であり、この表示部６０によってユーザに対する情報表示がなされる。
このような構成の下、制御部１０は、入力部２０及び状況取得部３０から入力される情報に基づき、メモリ部５０に記憶された依存性テーブル５０ａ・依存特性情報５０ｂ・従属性テーブル５０ｃを参照し、対象機器７０の動作・設定に利用される制御情報を生成し出力部４０を介して出力する。
【００５７】
この制御部１０を機能ブロックで示したのが、図２である。
制御部１０にて生成される制御情報は、アプリケーション情報と依存性情報とからなっている。アプリケーション情報は、実行要求が高いアプリケーションプログラムを示すアプリケーションリストである。一方、依存性情報は、依存ベクトル、依存特性、及び依存性要因リストからなる。
【００５８】
アプリケーションリストとして具現化されるアプリケーション情報は、少なくとも状況情報、依存性テーブル５０ａ、依存特性情報５０ｂ及び従属性テーブル５０ｃに基づいて、アプリケーション情報生成ブロック１１にて作成される。少なくともとしたのは、対象機器７０に実行させるアプリケーションプログラムを入力部２０を介してユーザが選択指示できるようになっており、アプリケーションプログラムの選択指示があった場合は、このアプリケーション選択指示も考慮してアプリケーション情報が作成されるためである。一方、依存性情報は、状況情報、依存性テーブル５０ａ及び依存特性情報５０ｂに基づいて、依存性情報生成ブロック１２にて生成される。
【００５９】
アプリケーション情報生成ブロック１１、依存性情報生成ブロック１２にてそれぞれ生成されたアプリケーション情報及び依存性情報は、制御情報生成ブロック１３へ出力されて制御情報としてまとめられ、その後、符号化ブロック１４へ出力される。符号化ブロック１４では、制御情報の符号化を行う。そして、符号化された制御情報が、記録媒体、プロファイル、対象機器７０あるいは複数の対象機器７０を制御する制御装置７１などへ出力される。
【００６０】
本第１実施例の制御情報出力装置１は、このような制御情報の生成に特徴を有するものである。そこで次に制御情報生成について詳細に説明する。
まず最初に、制御情報生成にあたって参照される依存性テーブル５０ａ、依存特性情報５０ｂ及び従属性テーブル５０ｃについて説明し、さらに続けて制御情報としてのアプリケーションリスト、依存性要因リスト、依存ベクトルについて説明する。そしてその後に、制御情報生成動作の説明を行う。
【００６１】
（１）依存性テーブル
依存性テーブル５０ａは、対象機器７０にて実行される各種アプリケーションプログラムに対するユーザ要求が、どのような要因（以下「依存性要因」という。）に依存するか、という依存関係を示すテーブルである。依存性テーブル５０ａの一例を、図３に示した。図３に示した２次元の依存性テーブル５０ａは、ビデオメディアに関連するアプリケーションプログラムに係るものである。
【００６２】
（１−１）アプリケーションプログラムの記述
図３中の最も左側の欄に示されるのが、対象機器７０にて実行されるアプリケーションプログラムである。「オフィス応用」アプリケーションは、文書作成、表計算などを実現するものである。「医療記録」アプリケーションは、映像を利用して歩行具合などの医療記録を行うものである。「ビデオ編集」アプリケーションは、ビデオ映像の途中をカットしたり、映像の順番を入れ替えたりするものである。また、「テレビ電話」アプリケーションは、いわゆるテレビ電話に搭載されるものであり、通話音声と共に通話者の映像をやり取りするためのものである。「家庭用ＡＶ」アプリケーションは、ビデオレコーダなど映像関連情報を取り扱う家庭用電気器具に搭載されたものである。「電子化カタログ」アプリケーションは、いわゆるカタログショッピングを可能にするものであり、映像を用いて商品の案内・販売を行うものである。
【００６３】
図３中のハッチング部分以降のアプリケーションプログラムは、映像メディアに関連するアプリケーションプログラムの中でも特に、ナビゲーション装置や携帯情報端末に搭載されるアプリケーションプログラムである。
「ルートガイダンス」アプリケーションは、目的地を設定すると、当該目的地までの案内経路を設定してルート案内を行うものである。また、「施設案内」アプリケーションは、施設検索を行うアプリケーションプログラムであり、さらに、「天気情報」、「交通情報」、「カラオケ」、「スポーツ情報」、「ゴルフ情報」、「スキー情報」、「レストラン情報」、「ショッピング情報」、「旅行情報」、「景観情報」、「ニュース情報」、「音楽情報」、「緊急情報」のアプリケーションは、それぞれの情報を取得し、映像を利用してユーザに提示するものである。
【００６４】
（１−２）依存性要因の記述
依存性テーブル５０ａに記述される依存性要因は、大きく３つに分類できる。ユーザ要因、システム要因及びメディア要因である。
（１−２−１）ユーザ要因
ユーザ要因とは、ユーザに関連する要因であり、ユーザの置かれた環境・状況やユーザの要求・状態などに関連するものである。例えば環境・状況には、時刻、場所、仕事内容、雑音の有無といった周囲条件などが挙げられる。また例えば要求・状態には、「食べたい」、「休憩したい」といった生活ニーズ、趣味などが挙げられる。その他ユーザに関連する要因としては、ユーザの嗜好性などが考えられる。
【００６５】
このユーザ要因には、特開平１２−２００９０号公報や特開平１１−３５１９０１号公報などに開示される、本出願人の提示したプロファイルシステムにおける「ユーザの環境・状況・要求・状態」の項目が含まれる。これら公報に開示される項目は特に自動車内における要因を示しているが、本明細書中でいうユーザ要因は車内の要因に限定されるものではない。
【００６６】
（１−２−２）システム要因
システム要因とは、制御情報によって制御されるシステムに関連する要因であり、例えば次のようなものが含まれる。メモリ容量、並行して実行可能なアプリケーションプログラムの数、処理能力、動作環境をはじめ、通信を行うことを前提とし、通信条件、通信コスト、またディスプレイなどの表示機器を備えることを前提とし、画面サイズといった表示デバイス条件などを挙げることができる。
【００６７】
（１−２−３）メディア要因
メディア要因とは、アプリケーションプログラムの処理対象となるメディアに関する要因である。これには、ＤＶＤ，ＣＤ−ＲＯＭといったメディアのタイプ、メディアに格納されるコンテンツに関する情報、例えばジャンル、製作者、日時、場所などが含まれる。
【００６８】
図３に示す依存性テーブル５０ａには、ユーザ要因及びメディア要因に属する諸項目を例示した。
ユーザの環境・状況の要因には、「時刻」、「場所」、「仕事」、「周囲条件」、「周囲の人々」の項目が示されている。「周囲条件」とは、周囲が騒がしいか否か、混雑しているか否かなどの条件をいう。また、「周囲の人々」は、子供であったり、大人であったり、また、家族であったり、友人であったりという区別をいう。
【００６９】
ユーザの要求・状態の要因には、「生活ニーズ」、「フィーリング」、「面白さ」という項目が示されている。「生活ニーズ」は、上述したように「食べたい」、「休みたい」というユーザの要求に近いものであり、これに対して「フィーリング」、「面白さ」は、ユーザの状態に近いものである。例えば「疲れた」、「気分最高」といったユーザ状態がフィーリングとされ、「面白さ」は、ユーザの趣味などの情報とすることが考えられる。また、「嗜好性」の項目は、好きな番組であったり、好きな俳優であったりする。
【００７０】
メディア要因として、図３には、コンテンツに関連する項目を例示した。「時間」、「場所」、「行為者」、「製作者」、「ジャンル」の項目である。「時間」はコンテンツの再生時間等である。「場所」は、撮影場所のことである。「行為者」は、俳優であったり、医療記録などでは患者であったりする。
【００７１】
そして、このような依存性要因は、図１中に示した状況取得部３０にて取得されるデータに基づいて確定される。依存性要因がとり得る値を、以下「依存性要因値」という。
例えば、ユーザ要因の「時刻」は、時計からの信号出力に基づき、取得することが考えられる。例えば、午前０時から午後１２時までの時刻として取得されるという具合である。また、ユーザ要因の「場所」は、レストラン、公園、スポーツ施設、会社、自宅、車内といった依存性要因値をとることが考えられる。このような依存性要因値は、例えばＧＰＳ受信機により取得される位置情報と地図データとのマッチングで確定することができる。さらに、ユーザ固有の情報については、例えばプロファイルという形式で管理するようにしておき、このプロファイルを参照して確定することが可能である。このプロファイルは、制御情報出力装置１の内部に記憶する構成であってもよい。また、外部の別の装置に記憶しておき、この装置から状況取得部３０を介して取得するようにしてもよい。
【００７２】
また例えば、図３に示すメディア要因に関しては、アプリケーションプログラムの処理対象となるメディアのヘッダー情報として記録しておくことが考えられる。従来より、音楽ＣＤなどには、各曲の再生時間などが記録されている。したがって、映像メディアに所定のフォーマットで「時間」、「場所」、「行為者」、「製作者」、「ジャンル」を記録しておくことが考えられる。そして、対象機器７０側からこれらの情報を状況取得部３０を介して取得する。なお、このようなメディア要因も、プロファイルという形式で予め記録しておくようにし、プロファイルから読み出して使用するようにしてもよい。
【００７３】
（１−３）依存性の記述
そして、依存性テーブル５０ａには、各アプリケーションプログラムが、上述した依存性要因のいずれに依存するかが記述されている。図３で言えば、「Ｄ」という記述が「依存」することを示している。例えば「オフィス応用」アプリケーションは、ユーザ要因の「場所」、「仕事」、メディア要因の「時間」、「場所」、「行為者」、「製作者」、「ジャンル」に依存することが、図３より分かる。
【００７４】
（２）依存特性
依存性テーブル５０ａに示される各アプリケーションプログラムがいずれの依存性要因に依存するかという情報は、依存特性情報５０ｂに基づき決定されたものである。
【００７５】
依存特性情報５０ｂは、依存性要因のとり得る依存性要因値と、アプリケーションプログラムへのユーザの統計的な要求度（以下「要求度」という。）との対応関係を示す情報である。依存性要因値は、ユーザ要因の「時刻」であれば、午前０時から午後１２時までの時刻というような連続的な値として、一方、「場所」であれば、レストラン、公園、スポーツ施設、会社、自宅、車内といった離散的な値として確定されることは既に述べた。
【００７６】
例えば連続的な依存性要因値と要求度との対応関係を、図４に示した。ここでは、横軸に依存性要因値Ｘをとり、縦軸にアプリケーションプログラムへの要求度Ｒを示した。ここで、依存性要因値Ｘに対し、要求度Ｒが相対的に大きく変動する場合に、アプリケーションプログラムがその依存性要因に依存すると定義する。
【００７７】
具体的に本第１実施例では、次に示す▲１▼〜▲３▼の３つの条件を満たす場合を、要求度Ｒが相対的に大きく変動する場合とする。
▲１▼要求度Ｒの依存性要因値Ｘに対する最大変動幅が第１の閾値ＤＲｔｈを上回っていること
▲２▼要求度の最大値Ｒｍａｘが第２の閾値Ｒｔｈを上回っていること
▲３▼依存特性の曲線が時間に対して一定であること、あるいは、規則性が見られること
例えば図４には、２つの依存特性を示した。実線で示した記号Ａの依存特性（以下「依存特性Ａ」と記述する。）と、一点鎖線で示した記号Ｂの依存特性（以下「依存特性Ｂ」と記述する。）である。
【００７８】
依存特性Ａは、依存性要因値Ｘに対する要求度Ｒの最大変動幅がα−βとなっており、要求度Ｒの最大値Ｒｍａｘがαとなっている。したがって、図４から分かるように、α−β＞ＤＲｔｈで、かつ、α＞Ｒｔｈである。したがって依存特性Ａが時間に対して一定又は規則性を有するならば、依存特性Ａを有するアプリケーションプログラムは、その依存性要因に依存するとされる。
【００７９】
一方、依存特性Ｂは、依存性要因値Ｘに対する要求度Ｒの最大変動幅がγ−δとなっており、要求度Ｒの最大値Ｒｍａｘがγとなっている。したがって、図４から分かるように、γ−δ＜ＤＲｔｈ，γ＜Ｒｔｈである。そのため、依存特性Ｂを有するアプリケーションプログラムは、依存性要因に依存しないとされる。
【００８０】
なお、上記▲３▼の条件を設定するのは、例えば１日の中の時刻Ｘに対して要求度Ｒが大きく変動するアプリケーションプログラムであっても、要求度Ｒの変動が日々異なる場合には、時刻Ｘに対する依存性があるとは言えないからである。また、依存性要因値が離散的な値となる場合は、例えばテーブル形式で依存性要因値と要求度とを対応させることが考えられる。この場合も、上述したのと同様の方法で依存するか否かを定義できる。
【００８１】
このような依存特性情報５０ｂは、図３に示した各依存性要因と各アプリケーションプログラムとを関係付けるものであり、依存性テーブル５０ａの各升目にそれぞれ対応付けられるものである。
このような依存特性情報５０ｂが決定されれば、上述した依存性の定義を用いて、依存特性情報５０ｂから依存性テーブル５０ａが確定できる。そのため、このような依存特性情報５０ｂは、ユーザ要求を予め統計処理して記憶しておくことが考えられる。ただし、入力部２０を介してユーザからアプリケーションプログラムの選択指示を入力できる構成であるため、このアプリケーションプログラムの選択指示に基づいて学習変更するようにしてもよい。また、依存特性情報５０ｂの学習変更に伴い、依存性の定義を用い、依存性テーブル５０ａをも学習変更する構成とすることが望ましい。
【００８２】
（３）従属性テーブル
従属性テーブル５０ｃは、アプリケーションプログラム間の従属関係を示すものである。あるアプリケーションプログラムへのユーザ要求は、別のアプリケーションプログラムに関連して大きくなることがある。例えば文書作成アプリケーションと共に表計算アプリケーションが使用される可能性が高いという具合である。したがって、表計算アプリケーションが文書作成アプリケーションに従属するというような従属関係を従属性テーブル５０ｃとして記憶しておく。
【００８３】
さらに続けて制御情報としてのアプリケーションリスト、依存性要因リスト及び依存ベクトルについて説明する。
（４）アプリケーションリスト
アプリケーションリストは、実行要求の度合いに応じて階層化されたアプリケーションプログラムの一覧である。本第１実施例では以下▲１▼〜▲４▼に示す４つのレベルに階層化したアプリケーションリストを生成する。
【００８４】
▲１▼完全アプリケーションリスト（以下「Ｆ−ＡＬＳＴ」という。）
登録されているすべてのアプリケーションプログラムのリストであり、制御情報出力装置１と対象機器７０側とでアプリケーションプログラムを対照させるためのリストである。
【００８５】
▲２▼ユーザアプリケーションリスト（以下「Ｕ−ＡＬＳＴ」という。）
ユーザが要求する可能性のあるアプリケーションプログラムのリストであり、Ｆ−ＡＬＳＴのサブセットになる。
▲３▼要求アプリケーションリスト（以下「Ｒ−ＡＬＳＴ」という。）
ユーザが要求すると推定されるアプリケーションプログラムのリストであり、Ｕ−ＡＬＳＴのサブセットになる。
【００８６】
▲４▼実行アプリケーションリスト（以下「Ｅ−ＡＬＳＴ」という。）
実行が確定したアプリケーションプログラムのリストであり、Ｒ−ＡＬＳＴのサブセットになる。
（５）依存性要因リスト
依存性要因リストは、依存性要因を有効度合いに応じて階層化した依存性要因の一覧である。本第１実施例では、以下▲１▼〜▲４▼に示す４つのレベルに階層化された依存性要因リストを生成する。
【００８７】
▲１▼完全依存性要因リスト（以下「Ｆ−ＤＬＳＴ」という。）
登録されているすべての依存性要因のリストであり、制御情報出力装置１と対象機器７０側とで依存性要因を対照させるためのリストである。
▲２▼ユーザ依存性要因リスト（以下「Ｕ−ＤＬＳＴ」という。）
ユーザの要求を判定する上で必要な依存性要因のリストであり、依存性要因値が確定される可能性のある依存性要因のリストである。これは、Ｆ−ＤＬＳＴのサブセットになる。
【００８８】
▲３▼アクティブ依存性要因リスト（以下「Ａ−ＤＬＳＴ」という。）
依存性要因値の確定した依存性要因のリストであり、Ｕ−ＤＬＳＴのサブセットになる。
▲４▼最重要依存性要因リスト（以下「Ｐ−ＤＬＳＴ」という。）
実行が確定したアプリケーションプログラムに関する依存性要因を示すリストであり、最重要のリストである。これは、Ａ−ＤＬＳＴのサブセットになる。
【００８９】
（６）依存ベクトル
依存ベクトルとは、依存性テーブル５０ａを行単位で取り出したものであり、これも「依存情報」に相当する。依存ベクトルは、あるアプリケーションプログラムが、いずれの依存性要因に依存しているかを示すものである。例えば図３に示す依存性テーブル５０ａにおいて、「オフィス応用」アプリケーションの依存ベクトルは、依存を示す記号Ｄを論理値「１」で置き換え、依存しないことを示す空白欄を論理値「０」で置き換えて、依存ベクトルＤＰ＝（０，１，１，０，０，０，０，０，０，１，１，１，１，１）と表すことができる。したがって、依存ベクトルと上述したＦ−ＤＬＳＴを対照させれば、あるアプリケーションプログラムがどの依存性要因に依存しているかを判断することができる。
【００９０】
次に制御情報生成動作の説明を行う。ここでは、制御部１０にて実行される制御情報出力処理を、図５に示すフローチャートに基づいて説明する。この制御情報出力処理は、入力部２０を介した制御情報の出力指示があると実行される。なお、ここでは、依存性テーブル５０ａを模式的に示す図６及び図７を適宜参照して説明する。
【００９１】
まず最初のステップ（以下、ステップを単に記号Ｓで示す。）１００において、依存性要因値を取得する。これは、上述したような各種依存性要因の値を確定する処理である。具体的には、状況取得部３０にて取得されるデータに基づき、依存性要因値を取得する。
【００９２】
続くＳ１１０では、依存性要因の有効度合いを判断し、依存性要因値の確定を判断する。このように依存性要因の有効度合いを判断するのは、周囲条件などによって依存性要因値の信頼度が低くなり、依存性要因が不適切なものとなる可能性があるためである。例えば、依存性要因値が所定範囲内の値となっていない場合に、依存性要因値が確定していないものとする。
【００９３】
次のＳ１２０では、アプリケーションプログラムの選択指示がユーザからあったか否かを判断する。本第１実施例の制御情報出力装置１では、表示部６０を介して対象機器７０で実行可能なアプリケーションプログラムをメニュー表示する。ユーザは、このメニューからアプリケーションプログラムの選択指示を行うことができる。ここでアプリケーションプログラムの選択指示があったと判断された場合（Ｓ１２０：ＹＥＳ）、Ｓ１３０へ移行する。一方、アプリケーションプログラムの選択指示がなかったと判断された場合（Ｓ１２０：ＮＯ）、Ｓ１７０へ移行する。
【００９４】
アプリケーションプログラムの選択指示があった場合に移行するＳ１３０では、アプリケーションプログラムを選択する。この処理は、ユーザによる選択指示がなされたアプリケーションプログラムを選択し、このアプリケーションプログラムの実行確信度を「１」にセットするものである。実行確信度は、正規化された情報であり、「１」に近いほどユーザによる実行要求が高いことを示す。
【００９５】
例えば図６に示すように、アプリケーションＡｌがユーザから指示された場合、このアプリＡｌの実行確信度を「１」にする。
次のＳ１４０では、Ｓ１３０にて選択したアプリケーションプログラムが依存する依存性要因の中で依存性要因値が確定しており、さらに、その依存性要因値から算出した要求度が所定値よりも大きくなる依存性要因を、依存性テーブル５０ａ及び依存特性情報５０ｂに基づき探索する。
【００９６】
例えば図６では、依存性テーブル５０ａのアプリＡｌの行を順に探索し（探索方向を矢印Ａで示した）、依存を示す「Ｄ」が記述された依存性要因Ｘｉ，Ｘｊ，Ｘｋの中で、依存性要因値の確定した依存性要因Ｘｉ，Ｘｊを探索する。そしてさらに、依存特性情報５０ｂに基づき、依存性要因Ｘｉ，Ｘｊに対する要求度Ｒｌｉ，Ｒｌｊを算出し、それぞれの所定値Ｒ１ｔｈ，Ｒ２ｔｈと比較する。要求度Ｒｌｉ＞Ｒ１ｔｈならば、依存性要因Ｘｉを有効なものとして選択する。同様に要求度Ｒｌｊ＞Ｒ２ｔｈならば、依存性要因Ｘｊを有効なものとして選択する。なお、ここで依存性要因Ｘｉ，Ｘｊが有効なものとして選択されたとして、以下の説明を続ける。
【００９７】
続くＳ１５０では、関連アプリを選択する。この処理は、確定しており有効であると判断された依存性要因に依存するアプリケーションプログラムを、依存性テーブル５０ａに基づき、選択するものである。
例えば図６で言えば、選択された依存性要因Ｘｉ，Ｘｊに依存している関連アプリＡｍ，Ａｎを選択することになる。詳しくは、依存性要因Ｘｉの列を矢印Ｂ方向に探索し、依存を示す「Ｄ」が記述された行のアプリケーションＡｎを関連アプリとして選択する（矢印Ｅ参照）。同様に、依存性要因Ｘｊの列を矢印Ｃ方向に探索し、依存を示す「Ｄ」が記述された行のアプリケーションＡｍを関連アプリとして選択する（矢印Ｄ参照）。
【００９８】
そして次のＳ１６０では、要求度を算出する。この処理は、確定しており有効であると判断された依存性要因について、関連アプリへの要求度を算出するものである。
例えば図６では、関連アプリＡｍへの依存性要因Ｘｊに対する要求度Ｒｍｊと、関連アプリＡｎへの依存性要因Ｘｉに対する要求度Ｒｎｉを算出することになる。
【００９９】
そしてＳ１６０の処理終了後、Ｓ２００へ移行する。
一方、アプリケーションプログラムの選択指示がなかった場合に移行するＳ１７０では、確定要因を探索する。この処理は、Ｓ１１０にて依存性要因値の確定した依存性要因を依存性テーブル５０ａの中でマーキングするものである。そして、ここで探索した依存性要因を、上述した依存性要因リストの中のＡ−ＤＬＳＴに加える。
【０１００】
例えば図７では、２つの依存性要因Ｘｉ，Ｘｊが確定しているため、これらがマーキングされてＡ−ＤＬＳＴに加えられる。
続くＳ１８０では、要求度を算出する。この処理は、確定した依存性要因、すなわちＡ−ＤＬＳＴに入っている依存性要因に対する要求度を、依存特性情報５０ｂを用いて算出するものである。
【０１０１】
図７で言えば、依存性要因Ｘｉ，Ｘｊに対するアプリケーションプログラムへの要求度Ｒｌｉ，Ｒｌｊ，Ｒｍｊ，Ｒｎｉを算出する。詳しくは、依存性要因Ｘｉの列を矢印Ｇ方向に探索し、依存を示す「Ｄ」が記述された行のアプリケーションＡｌ，Ａｎに対する要求度Ｒｌｉ，Ｒｎｉを算出する。同様に、依存性要因Ｘｊの列を矢印Ｈ方向に探索し、依存を示す「Ｄ」が記述されたアプリケーションＡｌ，Ａｍに対する要求度Ｒｌｊ，Ｒｍｊを算出する。
【０１０２】
次のＳ１９０では、関連アプリを選択する。この選択は、Ｓ１８０にて算出された要求度に応じて行われる。具体的には、各要求度が、対応する所定値よりも大きいか否かで判断する。要求度が所定値を上回るアプリケーションプログラムは、上述したアプリケーションリストのＲ−ＡＬＳＴに加えられる。一方、要求度が所定値以下であれば、Ｒ−ＡＬＳＴは変更しない。
【０１０３】
図７で言えば、要求度Ｒｌｉ＞Ｒ１ｔｈ、又は、要求度Ｒｌｊ＞Ｒ２ｔｈのとき、アプリケーションＡｌが関連アプリとして選択される（矢印Ｉ参照）。また、要求度Ｒｍｊ＞Ｒ３ｔｈのとき、アプリケーションＡｍが関連アプリとして選択される（矢印Ｊ参照）。同様に、要求度Ｒｎｉ＞Ｒ４ｔｈのとき、アプリケーションＡｎが関連アプリとして選択される（矢印Ｋ参照）。なお、関連アプリとしてＡｌ，Ａｍ，Ａｎが選択されたものとして、以下の説明を続ける。
【０１０４】
そしてＳ１９０の処理終了後、Ｓ２００へ移行する。
Ｓ２００では、実行確信度を算出する。これはＳ１６０又はＳ１８０で算出した要求度に基づき算出する。例えば複数の依存性要因に対して算出された要求度を平均したものを実行確信度とすることが考えられる。具体的に示すと、例えば依存性テーブル５０ａのあるアプリケーションプログラムＡｐについての実行確信度Ｃｐは、依存性要因Ｘｑ（ｑ＝１，２，３，・・・，Ｑ）に対する要求度をＲｐｑで示し、依存性要因ＸｑにアプリケーションＡｐが依存する場合をｄｐｑ＝１とし、一方、依存しない場合をｄｐｑ＝０とすれば、次の式１で示される。
Ｃｐ ＝ （１／ＳＲ）Σ（Ｒｐｑ・ｄｐｑ） …式１
ここでＳＲ＝Σｄｐｑであり、Σは、ｑ＝１〜Ｑまでの和記号である。なお、要求度Ｒｐｑは正規化されているものとする。
【０１０５】
次のＳ２１０では、実行確信度を補正する。この処理は、上述した従属性テーブル５０ｃを用い、実行確信度を補正するものである。
アプリケーションプログラムが選択指示されている場合は（図６参照）、実行確信度が「１」となっている選択指示されたアプリＡｌへの従属関係を用い、アプリケーションプログラムが選択指示されていない場合は（図７参照）、Ｒ−ＡＬＳＴに属するアプリケーションプログラムの中で最も実行確信度の大きなアプリケーションプログラムへの従属関係を用いる。例えば図７において関連アプリＡｌの実行確信度が最も大きくなっている場合は、関連アプリＡｌへの従属関係を用いて実行確信度を補正する。
【０１０６】
続くＳ２２０では、確定していない依存性要因値を推定する。これは、実行要求が相対的に高いアプケーションを基にして、依存性要因値を推定する処理である。
例えば図６では、アプリＡｌ，関連アプリＡｍ，Ａｎの依存性要因Ｘｋに対する要求度Ｒｌｋ，Ｒｍｋ，Ｒｎｋを最初に推定する。これらアプリケーションＡｌ，Ａｍ，Ａｎへの確定した依存性要因Ｘｉ，Ｘｊに対する要求度は相対的に大きくなっているため、Ｒｌｋ，Ｒｍｋ，Ｒｎｋも相対的に大きな値、例えば対応する所定値を上回る値として推定できる。したがって、推定した要求度Ｒｌｋ，Ｒｍｋ，Ｒｎｋを満たす依存性要因値を推定でき、さらに、それら推定した依存性要因値を平均して、依存性要因Ｘｋの依存性要因値とすることが考えられる（矢印Ｆ参照）。なお、単に平均をとってもよいが、依存度合いを考慮して荷重係数を用いた平均をとってもよい。また、この荷重係数は、各アプリケーションプログラムの実行確信度で代用することができる。図７においても同様であり、関連アプリＡｌ，Ａｍ，Ａｎの依存性要因Ｘｋに対する要求度を推定して依存性要因値を推定する（矢印Ｌ参照）。
【０１０７】
この推定処理を具体的に示すと、次のようになる。すなわち、実行要求の高いアプリケーションＡｐの依存性要因Ｘｑに対する要求度Ｒｐｑが所定値Ｒｐｑｔｈを上回る（Ｒｐｑ＞Ｒｐｑｔｈ）として、各アプリケーションＡｐに対する依存性要因値ＸＥＳＴｐｑを推定する。そして、次の式２により、依存性要因値ＸＥＳＴｐｑを平均して、依存性要因Ｘｑの依存性要因値ＸＥＳＴｑを推定する。
ＸＥＳＴｑ ＝ （１／ＳＡ）Σ（ａｐ・ＸＥＳＴｐｑ） …式２
ここで、ＳＡ＝Σａｐであり、ａｐはアプリケーションＡｐに対する荷重係数、また記号Σは、ｐ＝１〜ｐｍａｘまでの和記号を示している。荷重係数ａｐは、上述したようにアプリケーションＡｐの実行確信度Ｃｐで代用してもよい。
【０１０８】
そして次のＳ２３０では、制御情報を生成する。すなわち、アプリケーション情報としてのアプリケーションリスト、依存性情報としての依存性要因リスト、依存ベクトル、依存特性を生成する。
具体的には、Ｓ２１０で補正された実行確信度に基づき、アプリケーションリストを再構成する。すなわち、実行確信度Ｃが第１の閾値Ｃ１ｔｈよりも大きい場合、その関連アプリをＥ−ＡＬＳＴに入れる。一方、実行確信度Ｃが第１の閾値Ｃ１ｔｈ以下で、かつ、第２の閾値Ｃ２ｔｈよりも大きい場合、その関連アプリをＲ−ＡＬＳＴに入れる。実行確信度Ｃが第２の閾値Ｃ２ｔｈ以下であれば、その関連アプリをＲ−ＡＬＳＴから除外する。
【０１０９】
また、依存性要因リストを再構成する。Ｓ１７０にてＡ−ＤＬＳＴに入れられた依存性要因の中でＥ−ＡＬＳＴに入れられた関連アプリに係る依存性要因をＰ−ＤＬＳＴに入れる。
さらに、Ｒ−ＡＬＳＴ，Ｅ−ＡＬＳＴに属するアプリケーションプログラムに対する依存ベクトル及び依存特性をそれぞれ、依存性テーブル５０ａ及び依存特性情報５０ｂから作成する。
【０１１０】
次のＳ２４０では、アプリケーションリスト、依存性要因リスト、依存ベクトル及び依存特性を符号化する。そして、Ｓ２５０にて、符号化した制御情報を出力する。このＳ２５０の出力処理終了後、本制御情報出力処理を終了する。
ところで、このようにして制御情報生成出力することによって、制御情報に基づき対象機器７０がそれに応じた動作を行うように構成すれば、対象機器７０を総合的に、しかも、半自動的にセットアップして動作させることができる。
【０１１１】
そこで次に、対象機器７０側で実行される対象機器側処理について、図８のフローチャートに基づき説明する。この対象機器側処理は、対象機器７０にて実行されることが考えられる。また、複数の対象機器７０を制御する制御装置７１にて実行されることが考えられる。
【０１１２】
まず最初のＳ３００において、制御情報の復号化を行う。本第１実施例では、上述したように制御情報として、アプリケーションリスト、依存性要因リスト、依存ベクトル、依存特性を符号化して出力する。したがってここでは、これらの情報を順次復号化していく。
【０１１３】
続くＳ３１０では、復号化した制御情報を読み出す。
そして次のＳ３２０ではアプリケーションの設定を行い、その後、本対象機器側処理を終了する。
Ｓ３２０におけるアプリケーションの設定には、アプリケーションプログラムに関する様々な設定処理が含まれる。したがってここで、アプリケーション設定について説明する。
【０１１４】
（７）アプリケーション設定
（７−１）アプリケーション情報による設定
アプリケーション情報としてのアプリケーションリストに基づき、ユーザ要求に合わせたアプリケーションプログラムの起動・起動準備を行う。
【０１１５】
例えば実行の確定したＥ−ＡＬＳＴに属するアプリケーションプログラムに関してはスタンバイ状態にし、ユーザが要求すると推定されるＲ−ＡＬＳＴに属するアプリケーションプログラムに関してはアクセス可能状態にする。スタンバイ状態とは、アプケーションプログラムをメモリ展開して起動しておき、即座に使用できる状態にすることをいう。また、アクセス可能状態とは、直ぐに選択起動できるように、メニューに入れたり、また、メニューの最初に表示したりすることをいう。
【０１１６】
（７−２）依存性情報による設定
依存性要因リスト、依存ベクトルに基づき、アプリケーションプログラムがどのような依存性要因に基づいて要求されているのかを判断する。さらに、依存特性によって個々の依存性要因に対する要求度を判断する。そして、ユーザ要求に合わせたカスタマイズを行う。
【０１１７】
例えば「施設検索」アプリケーションの実行確信度が高くなり、実行が確定した場合を考える。このとき、その検索アプリケーションが、「生活ニーズ」という依存性要因から要求されたのか、あるいは、ユーザの「嗜好性」という依存性要因から要求されたのかを判断する。依存性要因リスト及び依存ベクトルに基づけば、いずれの依存性要因が有効となっているかを判断できる。また、両方の依存性要因が有効である場合には、依存特性を用いて要求度を算出する。これによって、検索範囲を有効に限定できる。
【０１１８】
なお、ユーザ要求に合わせたカスタマイズには、上述したような検索条件の設定だけでなく、アプリケーションプログラムに関連する様々なものが含まれる。例えば、アプリケーションプログラムが実行される対象機器７０の設定、アプリケーションプログラムの処理対象となるメディアコンテンツの選択、さらには、アプリケーションプログラムで参照されるユーザの属性記述の最適化などが挙げられる。対象機器７０の設定には、画面表示形態などをユーザの好みに合わせて変更する設定などが考えられる。また、メディアコンテンツの選択には、例えば「家庭用ＡＶ」アプリケーションを起動するとき、ユーザからの指定がなければ、ユーザの好みのメディアコンテンツを自動的に選択して再生したりすることが一例として挙げられる。さらにまた、従来より、ＸＭＬ（eXtensible Markup Language）文書などに用いられているようなタグと属性値による項目記述を複数個組み合わせて、ダイナミックかつ階層的に構成することでユーザやメディア、システムを柔軟に記述することが提案されている。このような記述に従ってシステムは様々な知的処理を行うことが可能になる。ユーザ属性記述の最適化とは、このようなＸＭＬのタグ記述に代表される階層的属性記述を上述した制御情報を用いて最適化することを意味する。
【０１１９】
つまり、以上のことをまとめると、制御情報に基づくアプリケーション設定処理によって、対象機器７０の状況に応じた動作、アプリケーションプログラムに応じた動作が可能になる。
（８）状況に応じた動作
状況に応じた動作の代表例として、以下▲１▼〜▲５▼が考えられる。
【０１２０】
▲１▼状況に応じて、選択するアプリケーションプログラムまたは選択できるアプリケーションプログラムセットを変更する。
▲２▼状況に応じて、アプリケーションプログラムの設定パラメータを変更する。
▲３▼状況に応じて、プロファイル内の検索属性の構成を動的に変更する。
【０１２１】
▲４▼ユーザ不在のときもスケジュールに応じた準備をする。
▲５▼ユーザ不在のときもユーザの依存特性に合わせた動作をする。
（９）アプリケーションプログラムに応じた動作
アプリケーションプログラムに応じた動作の代表例として、以下▲１▼〜▲４▼が考えられる。
【０１２２】
▲１▼アプリケーションプログラムに応じて、対応する入出力デバイスと処理プログラムを選択する。
▲２▼メディア記述属性の組み合わせを変更する。
▲３▼問い合わせプロファイルにおける検索属性の組み合わせを変更する。
【０１２３】
▲４▼各属性値のデータ形式を必要に応じて変更する。
アプリケーションプログラムに応じた動作を家庭用電気器具を例に挙げ、テレビジョン受像機やエアコンなどを集中管理する場合で説明する。このとき、上述したような属性情報の変更によって、テレビが選択された場合、リモートコントロール機能を実現する設定を行い、電子番組ガイド、番組選択、音量調整、ビデオ予約、画面設定、言語設定の機能をスタンバイさせたり、エアコンが選択された場合、季節や時間帯、温度に応じて動作させたりすることができる。
【０１２４】
次に、本第１実施例の制御情報出力装置１を用いたシステムの構成例について、図９を参照して説明する。
図９（ａ）では、制御情報出力装置１としての情報端末から通信Ｉ／Ｆを介して、データベース検索を行う対象機器７０としてのサーバ装置へ制御情報を出力するシステムとして構成した。この場合、対象機器７０としてのサーバ装置は、上述したように、出力される依存性情報に基づき、効率的に検索範囲を限定して検索を行う構成にすることができる。
【０１２５】
また、図９（ｂ）では、制御情報出力装置１としての情報端末から記録媒体へ制御情報を出力する構成とした。この場合、対象機器７０は、記録媒体から制御情報を読み取り、この制御情報に基づく動作を行う。例えばユーザは自己の情報を記録媒体に記録して持参すれば、旅行先のテレビジョン受像機などの対象機器７０を自分の好みに合わせて自動的に動作させることができる。
【０１２６】
図９（ｃ）では、制御情報出力装置１としての情報端末から複数の対象機器７０を制御する制御装置７１へ制御情報を出力するシステムの例である。このようなシステムは、車両に搭載して用いることが考えられる。その場合、対象機器７０は、ナビゲーション装置をはじめとする車両搭載機器である。図９（ｄ）は、図９（ｃ）と同様に、複数の対象機器７０を制御する制御装置７１を備えるシステムであるが、制御装置７１が、記録媒体を介して制御情報を読み込んで、動作する構成である。
【０１２７】
また、図９（ｅ）では、本制御情報出力装置１をリモコンとして実現し、複数の対象機器７０へ制御情報を送信するシステムである。家庭用電気器具が対象機器７０になる場合、このようなシステムが有効である。
以上説明してきたような本第１実施例の制御情報出力装置１では、対象機器７０を対象機器７０にて実行されるアプリケーションプログラムの単位で捉え、これらアプリケーションプログラムとユーザ要求を生じさせる各種要因とに依存性という概念を導入した。具体的には、各アプリケーションプログラムと予め定められた依存性要因との間に依存特性情報５０ｂなるアプリケーションプログラムへの要求度と依存性要因値との対応関係を用意し、この対応関係を用いて、アプリケーションプログラムがいずれの依存性要因に依存するかを示す依存性テーブル５０ａを用意した。そして、状況取得部３０にて取得されるデータに基づき確定される依存性要因値を用い、依存性テーブル５０ａ及び依存特性情報５０ｂに基づいて、相対的に実行要求が高いアプリケーションプログラムを示すアプリケーションリストをアプリケーション情報として出力する。また、ユーザ要求を生じさせる依存性要因を示す依存性要因リスト、及び依存性テーブル５０ａに基づく依存ベクトル、さらには、依存特性情報５０ｂに基づく依存特性を出力する。これによって、複数の対象機器７０、及びそれら複数の対象機器７０に対してユーザ要求を発生させる種々の要因を統括的に捉え、対象機器７０を総合的に、しかも、半自動的にセットアップして動作させることができる。
【０１２８】
例えばアプリケーションリストを出力することによって、対象機器７０側でユーザ要求に応じたアプリケーションプログラムの起動・起動準備を行うことができる。
また、依存性要因リスト及び依存ベクトルを出力することによって、対象機器７０側でアプリケーションプログラムの様々なカスタマイズを行うことができる。加えて、依存性情報に含めて依存特性を出力するようにしたため、対象機器７０側で各依存性要因に対する要求度を算出することが可能であり、ユーザのフィーリングに極力合わせて対象機器７０を動作させることができる。
【０１２９】
さらにまた、本第１実施例の制御情報出力装置１では、制御情報を符号化して出力する構成とした。このため、制御情報のデータ量を抑えることができ、特に、記録媒体やプロファイルへ出力する構成に有効である。
なお、本第１実施例のメモリ部５０が「記憶手段」に相当し、入力部２０が「入力手段」に相当し、状況取得部３０が「依存性情報取得手段」に相当する。また、制御部１０が「制御情報出力手段」に相当し、図５に示した制御情報出力処理が制御情報出力手段としての処理に相当する。
【０１３０】
上記第１実施例では、依存性テーブル５０ａ（図３参照）に記述される情報は、「依存する（「Ｄ」）」又は「依存しない（空白）」という２値の情報であった。これに対して、例えば図３で示す依存性テーブル５０ａの各升目に依存度合いを示す多値の情報（依存度）を記述するようにしてもよい。例えば依存度合いが最も高い場合を「１０」とし、依存していない場合を「０」として１１段階で示すという具合である。このようにすれば、ユーザのフィーリングにより合った対象機器７０の動作が可能になるという点で有利である。依存性要因間に重み付けができるためである。
【０１３１】
この場合、アプリケーションプログラムに対する依存ベクトルＤＰは、依存性要因Ｘｑ（ｑ＝１，２，３，・・・，Ｑ）に対する依存度をｄｑとして、ＤＰ＝（ｄ１，ｄ２，ｄ３，・・・，ｄＱ）と示すことができる。さらに、この場合は、依存度がある閾値以上のもののみ符号化し、（依存性要因番号、依存度）という二項組の列、すなわち（ｉ１，ｄｉ１），（ｉ２，ｄｉ２），・・・で表現してもよい。
【０１３２】
また、上記第１実施例では、依存性情報として依存性要因リスト、依存ベクトル、依存特性を出力する構成であったが、「依存情報」としての依存ベクトルのみを出力する構成にすることもできる。この場合は、依存ベクトルと依存性要因との対応付けが対象機器７０側で可能となればよい。ただし、依存性要因リストがあれば相対的に有効な依存性要因を判断できるため、依存性要因リストを共に出力する構成がより好ましい。
【０１３３】
さらにまた、対象機器７０側で要求度を算出しないのであれば、依存特性を出力する必要はない。一方、依存特性情報５０ｂを、対象機器７０側に記憶しておき、要求度を算出することも考えられる。ユーザ間で依存特性がほぼ同様になる場合があるためである。しかし、依存特性を出力する構成とすれば、ユーザ毎の要求度を対象機器７０側で把握できるため、ユーザ毎の要求に合わせた適切な制御を実現できる点で有利である。
【０１３４】
また、確定された依存性要因値を依存性情報に含めて出力することも考えられる。このようにすれば、対象機器７０側で依存性要因値を取得する構成が必要なくなるためである。
［第２実施例］
上記第１実施例のシステム構成例を図９に示したが、図９（ａ）に示すようなサーバ装置を対象機器とする検索システムの構成例を、以下第２実施例として説明する。そして特に、本第２実施例では、依存情報を応用した検索処理を説明し、検索処理の効率化とアプリケーションの普遍化について述べる。
【０１３５】
図１０は、第２実施例の「情報システム」としての検索システムの構成を示すブロック図である。
検索システムは、「制御情報出力装置」としてのユーザ端末１００と、サーバ装置２００とを備えている。
【０１３６】
ユーザ端末１００は、制御部１１０、入力部１２０、状況取得部１３０、通信部１４０、メモリ部１５０、表示部１６０、問い合わせ情報生成部１７０、アプリケーション１８０とを有している。ユーザ端末１００の構成は、上記第１実施例の制御情報出力装置１と基本的に同様である。ここでは特に、サーバ装置２００とのデータ通信を行うための通信部１４０、検索のための問い合わせ情報を生成する問い合わせ情報生成部１７０、さらに、ユーザ端末にて実行されるアプリケーション１８０を有している。
【０１３７】
一方、サーバ装置２００は、図１中の対象機器７０に相当し、ユーザ端末と同様に構成された制御部２１０、入力部２２０、状況取得部２３０、通信部２４０、メモリ部２５０、及び情報出力部２６０を有している。そしてさらに、検索処理実行のための検索情報生成部２７０、コンテンツリスト２８１、コンテンツデータベース２８２、評価関数計算部２９０及び検索リスト記憶部２９１を有している。
【０１３８】
コンテンツデータベース２８２には、種々の映像データ、音楽データなど検索対象となるコンテンツが記憶されている。コンテンツリスト２８１は、コンテンツ検索のために利用される情報のリストである。検索情報生成部２７０は、ユーザ端末１００からの問い合わせ情報に基づき、検索処理に利用可能な検索情報を生成する。そして、この検索情報に基づく評価関数の計算を行うのが評価関数計算部２９０である。評価関数計算部２９０による計算結果に従い、検索リスト記憶部２９１に検索結果のコンテンツのリストである検索リストが記憶される。
【０１３９】
なお、各装置１００，２００の制御部１１０、２１０は、インターフェースを介したシステム制御を行い、エージェントと呼ばれる。また、依存性テーブル１５０ａ，２５０ａや依存特性情報１５０ｂ，２５０ｂなど基本構成については、上記第１実施例と同様であるため、説明を省略する。
【０１４０】
上記第１実施例では、アプリケーションプログラムを依存情報に基づいて総括的に捉え、アプリケーションプログラムを半自動的にセットアップ、動作させる構成について述べた。これを応用しプログラムに限らず映像データなどのコンテンツまでを含め「アプリケーション」という位置付けで捉えれば、コンテンツの依存性という概念によって、コンテンツを検索することができる。例えば図３示した２次元の依存性テーブル５０ａはビデオメディアに関連するアプリケーションプログラムに係るものであり、「天気情報」、「交通情報」、「カラオケ」、「スポーツ情報」、「ゴルフ情報」、「スキー情報」、「レストラン情報」、「ショッピング情報」、「旅行情報」、「景観情報」、「ニュース情報」、「音楽情報」、「緊急情報」のアプリケーションは、それぞれの情報を取得し映像を利用してユーザに提示するプログラムとしたが、これらのアプリケーションを各情報に関連する映像データ（コンテンツ）として定義することができる。
【０１４１】
次に図１１の説明図に基づき、本第２実施例における検索処理の概要を最初に説明する。
図１１において、記号Ａで示す車両に搭載されるナビゲーション装置、記号Ｂで示すパーソナルコンピュータ、そして、記号Ｃで示す携帯電話機が、それぞれユーザ端末１００に相当する。そして、これら各装置との間でデータ通信を行う記号Ｄで示したセンタ装置が、サーバ装置２００に相当する。この例は、アプリケーションとしての映像情報（コンテンツ）を検索するシステムであり、各映像情報は、映像データ本体と、映像内容の記述データであるメタデータを有している。メタデータは、例えばメディア記述形式に関する国際標準案ISO/MPEG7 において規格化が進められているものとすることが考えられる。
【０１４２】
本第２実施例は、このメタデータに依存情報を含めておき、各ユーザ端末１００からの依存情報との比較演算を行い、映像データを検索しようとするものである。この比較演算は、評価関数を用いて行われ、演算対象となるのは、依存性符号である。ここで依存性符号について説明する。
【０１４３】
（１０）依存性符号
依存性符号は、例えば図３に例示したような依存性テーブルを行単位で取り出して符号化したものであり、アプリケーションがいずれの依存性要因に依存しているかを示すものである。これは上記（６）で説明した依存ベクトルを「１」又は「０」で符号化記述したものに他ならない。また依存性要因がユーザ要因、システム要因、メディア要因に大別できることは、既に述べた（上記（１−２）参照）。本第２実施例では、ユーザ要因に対応する依存性符号の部分をユーザ依存性符号（以下「ＤＣＵ」（Dependency Code for User）と適宜記述する。）と定義し、メディア要因に対応する依存性符号の部分をメディア依存性符号（以下「ＤＣＭ」（Dependency Code for Media ）と適宜記述する。）と定義する。なお、これらＤＣＵ及びＤＣＭを区別しない場合は、単に「ＤＣ」と記述することもある。また、メディアに付された依存性符号（ＤＣ）は「ＤＣ−Ｍ」と示し、ユーザ要求として生成された依存性符号は「ＤＣ−Ｕ」と示す。また、検索エージェント、すなわちサーバ装置２００の制御部２１０にて検索用に変換された依存性符号は、ＤＣ−Ｕと区別するために、「ＤＣ−Ａ」（Ａはエージェントによる変換を意味する）と示す。図１１では、問い合わせプロファイル等の形式で送信されたＤＣ−Ｕが、検索エージェントによってＤＣ−Ａに変換され、メタデータ中のＤＣ−Ｍと比較演算される様子を示している。
【０１４４】
次に、このような依存性符号を用いた検索処理をさらに詳細に説明する。
まず検索処理を実行するサーバ２００は、映像データなどのコンテンツを作成者などが登録するためのコンテンツ登録処理を実行可能に構成されている。このコンテンツ登録処理を、図１２のフローチャートに基づき説明する。
【０１４５】
まず処理が開始されると、コンテンツ作成者による入力がなされ（Ｓ４００）、次に作成状況の情報が取得される（Ｓ４１０）。コンテンツ作成者による入力は、サーバ装置２００の入力部２２０を介してなされ、一方、作成状況情報は、状況取得部２３０を介して取得される。
【０１４６】
続くＳ４２０では、アプリケーションの識別がなされる。ここでいうアプリケーションは、図３に例示されるような「天気情報」、「交通情報」、「カラオケ」、「スポーツ情報」、「ゴルフ情報」、・・・という分類をいう。つまり、ここでは、コンテンツ作成者による入力情報や状況情報から、そのコンテンツが例えば「天気情報」であるのか「交通情報」であるのかといった識別を行う。
【０１４７】
ここで識別されたアプリケーションに基づき、依存性テーブル２５０ａが参照される（Ｓ４３０）。次に新規アプリケーションか否かが判断される（Ｓ４４０）。新規のアプリケーションであれば（Ｓ４４０：ＹＥＳ）、アプリケーション名と依存性符号を依存性テーブル２５０ａに追加し（Ｓ４５０）、その後、Ｓ４６０へ移行する。一方、新規のアプリケーションでなければ（Ｓ４４０：ＮＯ）、Ｓ４５０の処理を実行せずに、Ｓ４６０へ移行する。
【０１４８】
Ｓ４６０では依存性符号を生成して依存性テーブル２５０ａの更新を行い、その後、Ｓ４７０にて、生成した依存性符号や関連情報をコンテンツリスト２８１に追加して、本コンテンツ登録処理を終了する。
次にユーザ端末１００にて実行される問い合わせ処理について、図１３のフローチャートに基づき説明する。
【０１４９】
まず最初のＳ５００では、ユーザ入力がなされる。この処理は、ユーザ端末１００の入力部１２０を介して行われる。そして続くＳ５１０では、状況取得部１３０にて状況情報を取得する。次のＳ５２０では、必要に応じてアプリケーション１８０を起動する。
【０１５０】
その後、依存性テーブル１５０ａ、依存特性情報１５０ｂ、及び量子化テーブル１５０ｃを順に参照し（Ｓ５３０，Ｓ５４０，Ｓ５５０）、Ｓ５６０にて、依存性符号を生成する。この依存性符号がＤＣ−Ｕである。
そして、Ｓ５７０では、生成した依存性符号（ＤＣ−Ｕ）を用いて問い合わせ情報を生成し、送信する。これに対して、サーバ装置２００は、問い合わせ情報に基づく検索処理を実行し、検索結果を送信してくる。
【０１５１】
したがって次のＳ５８０では検索結果を受信し、その後、Ｓ５９０にて、検索結果の認識や表示を行い、本問い合わせ処理を終了する。
次に、サーバ装置２００における検索処理を、図１４のフローチャートに基づいて説明する。
【０１５２】
まず最初のＳ６００では、問い合わせ情報を受信する。この処理は、図１３中のＳ５７０に対応するものである。続いて量子化テーブル２５０ｃを参照し（Ｓ６１０）、検索情報生成部２７０にて検索情報を生成する（Ｓ６２０）。この検索情報には、検索用の依存性符号（ＤＣ−Ａ）が含まれる。
【０１５３】
次のＳ６３０では、検索情報がコンテンツリスト２８１にあるか否かを判断する。例えば上述したようなコンテンツ登録処理（図１２参照）によってリストへの登録がなされている場合にはコンテンツリスト２８１に依存性符号（ＤＣ−Ｍ）や関連情報などの検索情報が存在するが、コンテンツデータベース２８２の全てのコンテンツについての検索情報がコンテンツリスト２８１に存在するとは限らない。ここでコンテンツリスト２８１に検索情報があると判断された場合（Ｓ６３０：ＹＥＳ）、コンテンツリスト２８１を参照して依存性符号（ＤＣ−Ｍ）を獲得し（Ｓ６４０）、その後、Ｓ６６０へ移行する。一方、コンテンツリスト２８１に検索情報がないと判断された場合（Ｓ６３０：ＮＯ）、メタデータ解析を行って依存性符号（ＤＣ−Ｍ）を獲得し（Ｓ６５０）、その後、Ｓ６６０へ移行する。
【０１５４】
Ｓ６６０では依存性符号に基づく評価関数を計算し、その後、ある評価基準を満たすコンテンツの一覧を１次検索リストとして生成する（Ｓ６７０）。この評価関数によるコンテンツ評価については後述する。
そして、Ｓ６８０では、１次検索を完了したか否かを判断する。ここで１次検索を完了したと判断された場合（Ｓ６８０：ＹＥＳ）、メタデータによる２次検索を行い（Ｓ６９０）、最終的な検索結果としてのコンテンツ（ターゲットコンテンツ）を選択する。Ｓ７００にて検索結果を配信し、その後、本検索処理を終了する。
【０１５５】
このように本第２実施例の検索処理では、依存性符号（ＤＣ）に基づくコンテンツ評価を行うことを特徴としている。そこで次にコンテンツ評価の手法を説明する。
（１１） コンテンツの評価
（１１−１） 評価関数
ユーザ端末１００からの要求仕様をあらわす荷重ベクトルＷとサーバー装置２００に格納されるコンテンツＣｌの内容特性を表す依存特性ＳＣｌの内積演算としてコンテンツの評価関数を定義する。次の式３、式４に示す如くである。
ＪＣｌ ＝ Σ Ｗｋ・ＳＣｌｋ（Ｎｋ） …式３
Ｎｋ ＝ Ｉｎｔ（Ｘｋ／Ｑｋ） …式４
なお、ここでΣは、ｋ＝１〜Ｎまでの和記号であるとする。また、各変数は、次に示す如く定義されるものである。
【０１５６】
Ｘｋ ： ｋ番目の要因値
Ｑｋ ： ｋ番目の要因値に対する量子化係数
Ｎｋ ： ｋ番目の要因値を量子化した値
Ｃｌ ： データベース上のｌ番目のコンテンツ
ＪＣｌ ： 要因群｛Ｘ１，…，Ｘｋ｝について要求に対するコンテンツＣｌの適合性を示す評価値
Ｗｋ ： 状況（ユーザ要求、ユーザ・通信・端末・メディアの環境）に応じて切り替える荷重係数
ＳＣｌｋ（Ｎｋ）： 要因Ｘｋに関してＣｌの適合度を示す依存特性
ここでＳＣｌｋは、アプリケーションへの要求度Ｒｎに等しい。したがって、Ｒｎ（Ｘｋ）と記述してもよい。ここでＲｎ（Ｘｋ）とは、要因値Ｘｋに関するアプリケーションＡｎへの要求度である。
【０１５７】
また、要因値の量子化とは、例えば連続的な時間情報を、「朝」、「昼」、「夜」や、「春」、「夏」、「秋」、「冬」という情報として捉えるための処理をいう。この量子化に係る情報を記述したのが、ユーザ端末１００やサーバ装置２００の備える量子化テーブル１５０ｃ，２５０ｃである。
【０１５８】
（１１−２） 評価関数の簡略化
上記（１１−１）では、評価関数を一般的に示した。すなわち、荷重ベクトルＷは、各成分が多値をとり得る依存ベクトルの一般形となっている。また、ＳＣｌは、依存特性であり、依存性要因値に対する要求度の高まりを示すグラフ（図４参照）で表現できる。
【０１５９】
しかし、コンテンツの数が非常に大きい場合、例えば１００万というオーダーでコンテンツが存在する場合には、式１に示した評価関数を用いると、短時間のうちにユーザ端末１００に検索結果を返すことは困難となる。そこで、評価関数を下記のように簡略化して記述することが考えられる。
【０１６０】
▲１▼例えば荷重係数Ｗを依存性符号ｄ（上述したＤＣ−Ａ）で置き換えることが考えられる。次の式５に示す如くである。
ＪＣｌ ＝ Σ ｄｋ・ＳＣｌｋ（Ｎｋ） …式５
これによって、ｄｋは「１」又は「０」であるため、１コンテンツあたりＫ回の乗算を省くことができる。
【０１６１】
▲２▼同様に、ＳＣｌｋ（Ｎｋ）を、依存性符号ｄＣｌｋ（上述したＤＣ−Ｍ）で置き換えることが考えられる。次の式６に示す如くである。
ＪＣｌ ＝ Σ Ｗｋ・ｄＣｌｋ …式６
▲３▼もちろん、両方を依存性符号で置き換えてもよい。すなわち、次の式７に示す如くである。
ＪＣｌ ＝ Σ ｄｋ・ｄＣｌｋ …式７
▲４▼さらに、評価値ＪＣｌが「０」又は「１」の２値をとるようにすることも考えられる。次の式８に示す如くである。

なお、後述するコンテンツ評価処理では、上記式７に示す評価関数を用いた場合について説明する。
【０１６２】
（１１−３） 多値表現による依存特性の符号化
コンテンツの依存特性の記述に際して、ＳＣｌｋ（Ｎｋ）とｄＣｌｋの中間レベルの表現として、図１５のように属性要因（横軸）と要求度（縦軸）を量子化して多値表現することが考えられる。この場合、００００、１１１１以外のすべて（14種類）のケースで依存性があると判定される。ここで量子化段階が十分小さければ、多値を取りうる１個の数値ｄＣｌｋで依存特性、すなわち依存性要因値に対する要求度を符号化できる。したがって、依存性の有無のみならず問い合わせ属性の値にマッチするかどうかさえも同時に（メタデータの解析をすることなく）判定できる。その場合は、評価関数を計算する前にｄＣｌｋを復号してやればよい。例えば、図１５の依存特性を表現する符号は２値表現で「１０１０」、１０進表現で「６」であるが、評価関数計算時にはＮｋ＝Ｎ１ＴＳ（春）に対して対応する数値「０」を依存特性の値として代入する。このようにすれば、依存性があることも判定できる上に依存特性値ＳＣｌｋ（１）＝ ０も同時に得ることができ、「春らしい映像」という検索要求に対して、『依存性はあるが検索対象ではない』という２次検索結果と同等の結果を１回の評価計算で得ることができる。ここではＮｊＴＳ ＝ ０／１（ｊ＝０，１，２，３）だが、当然ながら、縦軸の要求度も多値化できる。
【０１６３】
一方この場合、上記式１の場合と同様に、コンテンツ毎に特性を定義する作業が発生するという難点がある。これに対しては、後述するように「春らしい」という言語表現を多値依存性符号ｄＣｌｋに一意的に置きかえるテーブルを定義しておけばこの作業は大幅に軽減される。
【０１６４】
（１１−４） コンテンツ評価の効率化
▲１▼優先順序付け
上記式３〜８に示した評価関数計算のΣ演算の中で、依存性要因間の優先順序付けを行う。たとえば、時間、場所、および最優先属性の要求ベクトル成分が「０」でないときは、評価関数計算を完了する以前に属性値を参照し、そこで、属性値が要求と異なっていればその時点で評価関数計算を打ち切ることが考えられる。これは特に、コンテンツの数が多い場合の検索効率向上に有効である。
【０１６５】
▲２▼範囲限定
上記式３〜８に示した評価関数計算のΣ演算の中で、状況やアプリケーションの種類に応じて計算する要因を最初から限定することが考えられる。
▲３▼ＤＣ管理テーブルを利用
ＤＣ管理テーブルとは、生成した依存性符号のテーブルである。これは図１６に示すように、一度生成された依存性符号ＤＣ−ＭをＤＣ管理テーブルに登録しておき、このＤＣ管理テーブルから依存性符号ＤＣ−Ｍをロードして検索に使用するものである。例えばＤＣ管理テーブルのデータセットは、次のように表現できる。
【０１６６】
[コンテンツ番号、アプリケーション名、依存性符号、アクセス履歴]
上述したコンテンツ登録処理によってコンテンツリスト２８１が作成され、このコンテンツリスト２８１には、依存性符号などの検索情報が記憶されることは上述した。ＤＣ管理テーブルを用いるという思想は、登録時だけではなく、メタデータ解析によって検索処理中に獲得された依存性符号（ＤＣ−Ｍ）をも登録しようというものである。したがって、ＤＣ管理テーブルは、コンテンツリスト２８１の一構成要素として位置付けることができる。
【０１６７】
次にＤＣ管理テーブルを用いた、１次検索処理と、メタデータ解析で行う２次検索処理をさらに具体的に説明する。また続けて、コンテンツ評価処理の具体例を説明する。
図１７は、ＤＣ管理テーブルを用いた１次検索処理を詳細に示すフローチャートである。この１次検索処理は、図１４中のＳ６３０〜Ｓ６８０の処理に相当するものである。
【０１６８】
まず最初のＳ８００では、ＤＣ管理テーブルがあるか否かを判断する。ＤＣ管理テーブルが既に作成されている場合には、ここで肯定判断される。ＤＣ管理テーブルがあると判断された場合（Ｓ８００：ＹＥＳ）、Ｓ８１０へ移行する。一方、ＤＣ管理テーブルがないと判断された場合（Ｓ８００：ＮＯ）、図１８のＳ８９０へ移行する。
【０１６９】
Ｓ８１０では、ＤＣ管理テーブルを参照する。これによって依存性符号（ＤＣ−Ｍ）が読み出される。
続くＳ８２０では、変数Ｊを「１」に初期化する。この変数Ｊは、検索対象となるコンテンツを計数するための変数である。
【０１７０】
次のＳ８３０では、コンテンツ評価を行う。詳しくは後述するが、ここではＤＣ−ＭとＤＣ−Ａとが比較される。
Ｓ８３０による比較処理にて検索対象とする／しないの判断がなされるため、検索対象とする場合は（Ｓ８４０：ＹＥＳ）、１次検索リストにそのコンテンツを追加し（Ｓ８５０）、Ｓ８６０へ移行する。検索対象としない場合は（Ｓ８４０：ＮＯ）、Ｓ８５０の処理を実行せず、Ｓ８６０へ移行する。
【０１７１】
Ｓ８６０では、変数Ｊが定数Ｎ１に等しいか否かを判断する。この定数Ｎ１は、ＤＣ管理テーブルに依存性符号が記憶されているコンテンツの数を示す。ここでＪ＝Ｎ１である場合（Ｓ８６０：ＹＥＳ）、Ｎ１に「１」を加えたものを変数ｋに代入して（Ｓ８７０）、図１８中のＳ８９０へ移行する。一方、Ｊ≠Ｎ１である場合（Ｓ８６０：ＮＯ）、変数Ｊをインクリメントして（Ｓ８８０）、Ｓ８３０からの処理を繰り返す。
【０１７２】
図１８のＳ８９０では、メタデータを解析することによって、ｋ番目のコンテンツの依存性符号（ＤＣ−Ｍ）を抽出する。そして続くＳ９００では、コンテンツ評価を行う。この処理は、図１７中のＳ８３０と同様のものである。したがって、検索対象とする場合は（Ｓ９１０：ＹＥＳ）、１次検索リストにそのコンテンツを追加し（Ｓ９２０）、Ｓ９３０へ移行する。一方、検索対象としない場合は（Ｓ９１０：ＮＯ）、Ｓ９２０の処理を実行せず、Ｓ９３０へ移行する。
【０１７３】
このようにしてメタデータの解析により抽出された依存性符号（ＤＣ−Ｍ）は、Ｓ９３０にてＤＣ管理テーブルへ追加される。この依存性符号（ＤＣ−Ｍ）の追加に伴い、上述した定数Ｎ１もインクリメントされる。
次のＳ９４０では、変数Ｊが定数ＮＡに等しいか否かを判断する。この定数ＮＡは、検索対象のコンテンツの総数である。ここでＪ＝ＮＡである場合（Ｓ９４０：ＹＥＳ）、すなわち、１次検索を完了した場合には、本１次検索処理を終了する。一方、Ｊ≠ＮＡである場合（Ｓ９４０：ＮＯ）、すなわち、１次検索を完了していないうちは、変数ｋ及び変数Ｊをインクリメントして（Ｓ９５０）、Ｓ８９０からの処理を繰り返す。
【０１７４】
次に、メタデータ解析による２次検索処理を具体的に説明する。
図１９は、ＤＣ管理テーブルを用いた２次検索処理を詳細に示すフローチャートである。この２次検索処理は、図１４中のＳ６９０及びＳ７００の処理に相当する。
【０１７５】
まず最初のＳ１０００では、変数ｍを「０」に初期化し、変数ｍ２を「１」に初期化する。
続くＳ１０１０ではコンテンツＣｍのメタデータＭｍをアクセスし、次のＳ１０２０では、解析の深さを決定する。そして続くＳ１０３０では、Ｓ１０２０で決定されたレベルの解析を行い、検索適合度ＲＭを算出する。このようなメタデータの解析手法には種々のものがあるが、特徴部分の説明に不要であるため、ここでの解説は割愛する。
【０１７６】
次のＳ１０４０では、検索適合度ＲＭが閾値ＲＭｔｈ以上であるか否かを判断する。ここでＲＭ≧ＲＭｔｈである場合（Ｓ１０４０：ＹＥＳ）、変数ｍ２をインクリメントし（Ｓ１０５０）、検索リストにコンテンツＣｍを追加して（Ｓ１０６０）、Ｓ１０７０へ移行する。一方、ＲＭ＜ＲＭｔｈである場合（Ｓ１０４０：ＮＯ）、Ｓ１０５０及びＳ１０６０の処理を実行せず、Ｓ１０７０へ移行する。
【０１７７】
Ｓ１０７０では、変数ｍが定数ＮＭよりも小さいか否かを判断する。この定数ＮＭは、１次検索リストに記憶されたコンテンツ数である。ここでｍ＜ＮＭである場合（Ｓ１０７０：ＹＥＳ）、すなわち１次検索リストに記憶されたコンテンツのメタデータ全てを解析をしていないうちは、変数ｍをインクリメントし（Ｓ１０８０）、Ｓ１０１０からの処理を繰り返す。一方、ｍ＝ＮＭである場合（Ｓ１０７０：ＮＯ）、すなわち１次検索リストに記憶されたコンテンツのメタデータの全てを解析している場合には、図２０中のＳ１０９０へ移行する。
【０１７８】
Ｓ１０９０からは、検索リストに追加されたコンテンツの配信に係る処理の具体例である。ここではコンテンツ毎に、要約動作の有無及び符号化方式を決定して、コンテンツに合わせた、また、ユーザ要求に合わせた配信処理を行う。
図２０のＳ１０９０では、変数ｍ３を「１」に初期化する。続くＳ１１００では、コンテンツの表示時間を計算する。ここでは映像データを検索対象にすることを前提にして、その映像データの表示時間を計算する。
【０１７９】
そして次のＳ１１１０では、指定時間内に表示可能か否かを判断する。ここで指定時間内に表示不可能な場合（Ｓ１１１０：ＮＯ）、Ｓ１１２０にて要約動作を実行し、その後、Ｓ１１３０へ移行する。一方、指定時間内に表示可能な場合（Ｓ１１１０：ＹＥＳ）、Ｓ１１２０の処理を実行せずに、Ｓ１１３０へ移行する。
【０１８０】
Ｓ１１３０では、選択されたコンテンツに合わせた符号化方式を選択する。そして次のＳ１１４０では、現在ソースの符号化方式とＳ１１３０で選択された符号化方式とが異なるか否かを判断する。ここで符号化方式が異なっていると判断された場合（Ｓ１１４０：ＹＥＳ）、符号化方式を変換し（Ｓ１１５０）、ユーザ端末１００への配信処理を行い（Ｓ１１６０）、その後、Ｓ１１７０へ移行する。一方、符号化方式が同一であると判断された場合（Ｓ１１４０：ＮＯ）、Ｓ１１５０の処理を実行せずそのまま、ユーザ端末１００への配信処理を行い（Ｓ１１６０）、その後、Ｓ１１７０へ移行する。
【０１８１】
Ｓ１１７０では、変数ｍ３が変数ｍ２よりも小さいか否かを判断する。変数ｍ２は、検索リストに記載されたコンテンツ数である。ここでｍ３＜ｍ２である場合（Ｓ１１７０：ＹＥＳ）、すなわち配信していないコンテンツがあるうちは、変数ｍ３をインクリメントして（Ｓ１１８０）、Ｓ１１００からの処理を繰り返す。一方、ｍ３＝ｍ２である場合（Ｓ１１７０：ＮＯ）、全てのコンテンツを配信した場合には、Ｓ１１９０へ移行する。
【０１８２】
Ｓ１１９０では新規に作成された項目をＤＣ管理テーブルへ記憶し、その後、本２次検索処理を終了する。
続いて、コンテンツ評価処理を、図２１のフローチャートに基づいて説明する。このコンテンツ評価処理は、図１７中のＳ８３０及び図１８中のＳ９００にてコールされるものである。
【０１８３】
まず最初のＳ１２００では、変数ＲＩＤＸに「０」を代入して初期化する。続くＳ１２１０では、変数ｉを「０」に初期化する。
続くＳ１２２０では、依存性符号（ＤＣ−Ａ）のｉ番目要素と依存性符号（ＤＣ−Ｍ）のｉ番目要素との論理積が「１」であるか否かを判断する。ここで（ＤＣ−Ａｉ）ＡＮＤ（ＤＣ−Ｍｉ）＝１である場合（Ｓ１２２０：ＹＥＳ）、Ｓ１２３０へ移行する。一方、（ＤＣ−Ａｉ）ＡＮＤ（ＤＣ−Ｍｉ）≠１である場合（Ｓ１２２０：ＮＯ）、Ｓ１２８０へ移行する。
【０１８４】
Ｓ１２３０では変数ＲＩＤＸをインクリメントする。続くＳ１２４０では、依存性符号（ＤＣ）のｉ番目要素（ＤＣｉ）は、最重要属性か否かを判断する。ＤＣｉが最重要属性であれば（Ｓ１２４０：ＹＥＳ）、この時点でメタデータを解析して属性Ａｉの値を判定し（Ｓ１２５０）、Ｓ１２６０へ移行する。一方、ＤＣｉが最重要属性でなければ（Ｓ１２４０：ＮＯ）、Ｓ１２８０へ移行する。
【０１８５】
Ｓ１２６０では、Ｓ１２５０で判定された属性Ａｉの値に基づき、検索条件に適合しているか否かを判断する。ここで検索条件に適合していると判断された場合（Ｓ１２６０：ＹＥＳ）、Ｓ１２８０へ移行する。一方、検索条件に適合していないと判断された場合（Ｓ１２６０：ＮＯ）、検索対象にしないものとして（Ｓ１２７０）、本コンテンツ評価処理を終了する。すなわち、最重要属性の属性値が要求に合致していない場合には、コンテンツ評価を途中で打ち切る。これによってコンテンツ評価の効率化が図られる。
【０１８６】
Ｓ１２８０では、変数ｉが定数Ｎに等しいか否かを判断する。この定数Ｎは、依存性要因の数である。ここでｉ＝Ｎである場合（Ｓ１２８０：ＹＥＳ）、すなわち全ての依存性要因について論理積を計算している場合には、Ｓ１３００へ移行する。一方、ｉ≠Ｎである場合（Ｓ１２８０：ＮＯ）、すなわち、論理積を計算していない依存性要因が存在する場合には、変数ｉをインクリメントして（Ｓ１２９０）、Ｓ１２２０からの処理を繰り返す。
【０１８７】
Ｓ１３００では、変数ＲＩＤＸが閾値Ｒｔｈ以上であるか否かを判断する。ここでＲＩＤＸ≧Ｒｔｈである場合（Ｓ１３００：ＹＥＳ）、検索対象にするものとして（Ｓ１３１０）、本コンテンツ評価処理を終了する。一方、ＲＩＤＸ＜Ｒｔｈである場合（Ｓ１３００：ＮＯ）、検索対象にしないものとして（Ｓ１３２０）、本コンテンツ評価処理を終了する。
【０１８８】
なお、ここで説明したコンテンツ評価処理において、次に示すようなバリエーションを考えることができる。
（ａ）上述した処理では、各成分が「０」又は「１」の値をとる依存性符号（ＤＣ−Ａ，ＤＣ−Ｍ）を用いて計算したが、上記式３に示したような荷重ベクトルＷ及び依存特性ＳＣｌを用いた計算を行ってもよい。これにより、各成分（属性）の重要性のレベルを表現できる。
【０１８９】
（ｂ）また、変数ｉをインクリメントしていくことによって１番目の成分から順に演算していたが、演算順序を変数ｉで規定するのではなく、優先順序を取り入れて、ｉ番目に演算する成分を番号Ｊ（ｉ）で規定してもよい。例えば、Ｊ（１）＝３，Ｊ（２）＝６、Ｊ（３）＝１、・・・とすれば、３番目、６番目、１番目、・・・という順序で論理演算がなされることになる。これによって重要度の高い属性を先に計算することができる。
【０１９０】
次に、以上のような処理で選択される検索対象のコンテンツを具体化し、依存性符号を用いた検索処理における本提案の有効性を示す。
（１４） コンテンツ
（１４−１） コンテンツの価値
例えばコンテンツとして映像データを例に挙げれば、サーバー装置２００側でコンテンツを表現する依存性符号（ＤＣ−Ｍ）は、次のような依存性要因に対するものとすることができる。
【０１９１】
ｄＣｌ ＝ （ｄＴｓ，ｄＸｓ，… ）
ｄＡ ： このコンテンツの価値が依存性要因Ａに依存するかどうかを示す符号。「１」ならば依存、「０」ならば依存しない。
Ｔｓ ： シーン時間。対象とするコンテンツが表すシーンの時間情報
Ｘｓ ： シーン場所。対象とするコンテンツが表すシーンの場所情報
（１４−２） 映像検索におけるコンテンツの価値
上記（１４−１）で示したような依存性符号（ＤＣ−Ｍ）が表現する映像データとしてのコンテンツ評価を行う場合、次に示すような価値判断を行うことが考えられる。
【０１９２】
例えば、＜４月１２日、田園風景＞のシーンの価値をシーンの撮影日時で判断すると、「春のシーン」として価値がある（要求に合致する）。この場合、時間に対する依存性は４月を中心とする要求度の高まりとして表現される。一方、「冬のシーン」としては価値が低い。これをグラフを用いて表現すると、図２２の如くとなる。
【０１９３】
また、＜８月、軽井沢＞のシーンの価値をシーンの撮影場所と季節で判断すると、例えば「夏の軽井沢近辺の観光地シーン」として価値がある（要求に合致する）。この場合、時間に対する依存性は８月を中心とする要求度の高まりとして表現される。これは「冬らしいシーン」や「春らしいシーン」としては価値が低い。また、場所に関する依存性は軽井沢近辺でなおかつ避暑地、観光地を彷彿とさせるスポットを中心とした要求度の高まりとして表現される。
【０１９４】
さらに、春に作られた「機械のビデオマニュアル」や「航空機内の緊急避難用具の説明映像」はいわゆる「春らしい風景」には該当しない。
これらの例において、言語表現「春らしい」は図２２に示すような依存特性Ｒ（Ｔｓ）の数値表現を高能率符号化していると考えられる。
【０１９５】
これらの例を見ると、厳密に映像検索を行うには、シーン時間といった依存性要因に依存するか否かだけでなく、依存性要因値に対する要求度の高まり具合を示す依存特性Ｒ（Ｔｓ）を各コンテンツ毎に表現しておくことが望ましい。
しかし、実際は膨大なデータベースに対してすべてそれを行うことは困難である。人間の主観では、言語表現（「春らしい」など）でパターン化されている。この言語表現はコンテンツのメタデータ中に記述可能であるが、あらゆる計算機や機器、大容量のコンテンツデータベースに対して共通に、自動的かつ高速かつ誤りなく意味を判別することは容易ではない。例えば、（春、パリ）という風景に対する要求は時間値Ｔｓに対して α＜Ｔｓ＜β という季節判定を行った後、空間座標値に対しても同様な不等式判定が必要と考えられるが、その不等式の上限、下限、成立条件をすべてのユーザ、すべてのアプリケーションに対して厳密に定義することは容易ではないからである。
【０１９６】
そこで、理想的には依存特性の数値表現や言語表現で記述されるコンテンツのメタデータを最初から深く検索するのではなく、各属性についての依存性の有無を符号表現することで1次検索の効率を高めようとするのが本提案の考え方である。例えば、図２３に示すように、シーンのアプリケーション、つまり「観光情報・ホテル情報」、「機械修理マニュアル」、「観光情報・渋滞情報」、「アイドル映像・コマーシャル」と分類できるアプリケーションが、「時間」、「場所」、「天気」というユーザ要因や、「シーン時間」、「シーン場所」、「シーンのアクター」、「シーンのフィーリング」というメディア要因に対しどのような要求度の高まりを有するかを、図２３中の各升目に示すような依存特性のグラフや言語表現で詳細に規定することは難しい。また、検索に要する時間が膨大になってしまう。そこで、これも各升目に示したが、依存する場合を「１」、依存しない場合を「０」、不定の場合を「Ｘ」とした依存性符号で価値判断を行うのである。
【０１９７】
この基本方針は、映像以外のアプリケーションにも共通して採用することができることは言うまでもない。
（１４−３） 音楽検索におけるコンテンツの価値
例えば映像検索以外の音楽検索について説明する。
【０１９８】
音楽を検索する場合は、時々刻々と変化するユーザのフィーリングへの適合性の評価が必要となる。このフィーリングへの依存性は、次のような依存性要因に基づいて考えることができる。これはフィーリングの定義として一般化することができる。
【０１９９】
Ｆｕ ： ユーザのフィーリング
｛さわやかな、楽しい、暗い、悲しい、元気な、etc.｝
Ｆｍ ： 音楽の持つフィーリング
｛静かな、激しい、ポップな、明るい、etc.｝
このような依存性要因を用い、ある音楽が検索された際のＦｕとＦｍを対応付けることで「この音楽はどういうフィーリングのユーザが好むか？」という傾向を知ることができる。
【０２００】
その他、ユーザ時間Ｔｕ、ユーザ場所Ｘｕ、アーティストＡｒなどが、音楽検索における依存性要因として考えられる。
（１４−４） コンテンツの自動分類
コンテンツの代表値を一意に決定することは困難である。しかし、依存性という概念でコンテンツを捉えれば、コンテンツの価値判断の基準となる特性を半自動的に付与することができ、例えばサイトにアップロードされるコンテンツなども分類することができる。サイト上に依存性テーブルがあれば、テーブル中の依存性符号と比較することで、関連アプリケーションを識別することもできる。
【０２０１】
例えば上述したようなコンテンツ登録処理（図１２参照）によって依存性符号を生成してコンテンツを登録することもその一例として考えられる。これと同様に、ユーザ端末１００からアップロードされるコンテンツについても自動分類する構成とすれば、データベースに蓄積されるあらゆるコンテンツを管理することが可能になる。
【０２０２】
例えば図２４に示すようなコンテンツ追加処理を実行できるようにサーバ装置２００を構成することが考えられる。
ここでは処理が開始されるとまず、アプリケーション名の入力を促す（Ｓ１４００）。アプリケーション名が入力されると、次に、依存性テーブル２５０ａに記載された代表語彙とインデックスに変換し（Ｓ１４１０）、依存性テーブル２５０ａを参照して依存性符号を獲得する（Ｓ１４２０）。例えば、アプリケーション名「店の映像情報」などが入力されると、依存性テーブル２５０ａにある「レストラン情報」という代表語彙で置き換え、これに関する依存性符号を獲得するという具合である。アプリケーション名から代表語彙・インデックスへの変換は、例えばテーブルなどの対応関係を用意して行えばよい。
【０２０３】
次のＳ１４３０では、アプリケーション名の入力が終了したか否かを判断する。ここで入力が終了したと判断されると（Ｓ１４３０：ＹＥＳ）、Ｓ１４４０へ移行する。一方、入力が終了していないうちは（Ｓ１４３０：ＮＯ）、Ｓ１４００からの処理を繰り返す。これにより、複数のアプリケーション名が入力された場合は、依存性テーブル２５０ａから複数の依存情報が参照され、新規のアプリケーションに対しても依存情報の適切な類推が可能になる。
【０２０４】
Ｓ１４４０では最終的な依存情報の生成を行い、Ｓ１４５０にてメタデータに依存情報を格納して、本コンテンツ追加処理を終了する。
次に、ナビゲーション装置などの車両情報機器としてユーザ端末１００を実現した場合の依存性符号（ＤＣ−Ｕ，ＤＣ−Ａ，ＤＣ−Ｍ）における依存性要因の具体例を説明する。
【０２０５】
図２５に示すように、ＤＣ−Ｕにおける依存性要因としては、ユーザの「名前」、「性別」、「年齢」、「住所」、「家族構成」、「仕事」、「好きな料理」、「好きな場所」、「好きな音楽」、「好きなスポーツ」、「趣味」、「メモリアルデイ」などのユーザの個人情報、「現在地」、「現在時刻」、「目的地」、「経由地」、「状況」、「現在地の天気」、「目的地の天気」、「目的」、「現在状態（フィーリングなど）」、「予測状態」、「現在要求」、「予測要求」、「温度（車内、車外、希望）」、「話題」、「走行道路（高速道路／一般道路）」、「乗員構成」などの状況情報、そして、「端末能力」、「画面サイズ」、「ビットレート」などのシステム情報が挙げられる。検索に直接的に利用されるＤＣ−Ａは、「ユーザ現在地」、「ユーザ現在時刻」、「シーン場所」、「シーン時刻」、「アクター」、「移動速度」などの依存性要因に係るものとすることが考えられる。ＤＣ−Ｍでは、「シーン場所」、「シーン時刻」といったメディア要因が依存性要因となっている。
【０２０６】
次に代表的な依存性要因とその依存性要因がとり得る依存性要因値の例を示すことによって、依存性要因に対する理解を深める。
（１５） 依存性要因と依存性要因値の例

（１６） 依存性符号の記述例
上記（１５）では、依存性要因のとり得る依存性要因値の例をまとめた。そこで次に、このような依存性要因への依存性の有無を示す依存性符号の記述例を示す。ここでは、コンテンツの依存性要因が上述したシーンの時間（Ｔｓ）、シーン場所（Ｘｓ）、アクター（Ａｓ）、フィーリング（Ｆｓ）であるものとして、様々な記述例を示す。上述したように「０」は依存していないこと、「１」は依存していること、「Ｘ」は不定であることを示すものとする。
【０２０７】
シーン１ ： 軽井沢のホテル （１，１，０，Ｘ）
これを一般化すると「観光地のホテル映像」には依存性符号（１，１，０，Ｘ）を付与できると考えられる。
シーン２ ： 機械の修理マニュアル映像 （０，０，０，０）
これを一般化すると「ビデオマニュアル類」には依存性符号（０，０，０，０）を付与できると考えられる。類似例として「航空機内の緊急災害時の対応マニュアル映像」などがある。
【０２０８】
シーン３ ： 猿投グリーンロードの状況 （１，１，０，０）
▲１▼渋滞状況としての要求度 （１，１，０，０）
▲２▼ルートガイド映像としての要求度 （０，１，０，０）
シーン４ ： 愛知健康の森までのルートガイド映像（０，１，０，０）
シーン５ ： ８月の沖縄、本○真奈美の映像 （１，１，１，Ｘ）
本○真奈美がアイドルであれば、アイドル映像の要求が高くなるという事実を前提として、主要な依存性要因はＡｓ＝１である。したがって、情報の与えられ方によっては、次のケースもありうる。要求度がシーンのアクターにのみ依存する場合は（０，０，１，Ｘ）、要求度がシーンの場所とアクターに依存する場合は（０，１，１，Ｘ）であり、要求度がシーンの時間とアクターに依存する場合（１，０，１，Ｘ）となる。
【０２０９】
シーン６ ： オモチャのコマーシャル映像 （０，０，１，１）
これは要求度がアクターおよびフィーリングに依存すると考えられるためである。
シーン７ ： スキー場の観光案内 （１，１，０，Ｘ）
依存性符号は「観光地のホテル案内」と類似する。
【０２１０】
シーン８ ： ニュース映像 （Ｘ，Ｘ，Ｘ，０）
この場合、上記４つの依存性要因は、上述した1次検索に対してあまり有効でないことが分かる。したがって、コンテンツにニュース映像などが含まれてくる場合には、別の依存性要因、例えばニュース属性などを設定する必要があると考えられる。
【０２１１】
このような依存性要因に対する依存性符号の記述がなされていることを前提とした場合、例えば上述した依存性符号（ＤＣ−Ａ）が（０，１，０，Ｘ）であるとすると、１次検索処理によって、シーン｛１，３，４，５，７｝がヒットする。また、依存性符号（ＤＣ−Ａ）が（０，０，１，Ｘ）であれば、シーン｛５，６｝がヒットする。
【０２１２】
以上のように構成された本第２実施例の検索システムの発揮する効果を説明する。なお、ここでの説明に対する理解を容易にするため、最初に従来の問題点を簡単に説明する。
インターネットにおいても顕著なように、今後膨大な数のコンテンツが複数のデータベースサイトにわたって分散して存在し、それらに対する効率的な検索手法が望まれている。特にモバイル端末においては、即座にユーザの要求に即したコンテンツが検索・配送されることが望まれる。しかるに、現状ではあらかじめ規定したサイト以外のデータベースも探索してリアルタイムかつ低コストの計算量で情報提供できるシステムはまだない。
【０２１３】
従来の検索システムで例えば映像データなどのコンテンツ検索を行おうとすると、規格化が進められているメディア記述形式に関する国際標準案ISO/MPEG7 において作成されるメタデータ（内容記述データ）を用いることができるが、メタデータのデータサイズが１Ｋバイトを超えてしまう例も存在する。したがって、端末側での検索対象が数百万件を超えるオーダーになる場合は、Ｇバイトオーダーのメタデータ通信が必要になる。さらに、ユーザ自信も数百万人を超えるとなると、通信インフラやデータベースサイトの通信トラフィック量から、現状の最高性能の計算機を持ってしてもリアルタイム処理が困難な状況が発生する。
【０２１４】
これに対して、本第２実施例では、プログラムに限らず映像データなどのコンテンツを含めた検索対象情報をアプリケーションとして総合的に捉え、依存情報によるアプリケーションの検索を提案した。
具体的には、上記第１実施例で定義した依存ベクトルの成分を「０」又は「１」で表現した依存性符号（ＤＣ）を用い、依存性符号の内積演算で評価関数を定義して１次検索を行う。つまり、代表値で記述することが困難な映像データなどのアプリケーションを依存性符号（ＤＣ）という形式で捉えるという技術思想によって、ありとあらゆるジャンルに属するコンテンツに対する迅速な検索を簡単な演算で可能にしたのである。
【０２１５】
依存性符号（ＤＣ）を用いた１次検索によれば、高速検索に寄与できる。そして、コンテンツの相互運用性を向上できる。つまり、従来は別のジャンルに分類されていたコンテンツをも容易に検索することができる。例えば、カラオケ映像を取得したいとのユーザ要求に対し、例えば広告・宣伝映像などがその検索条件にマッチして取得されるという具合である。また、コンテンツの特性が明確に記述されていなくても、検索対象を絞り込める。さらに、コンテンツの特性を一意的な代表値に自動的に置きかえることが困難な場合にも有効である。例えばある映像データが様々な時間帯や場所にわたるシーンで構成されている場合など、時間と場所とを自動的に代表値で記述することは難しいためである。
【０２１６】
また、アプリケーションを依存性要因への依存情報で捉えるようにすれば、アプリケーションの普遍的記述が達成される。これを次に説明する。
（１８） アプリケーションの普遍的記述
（１８−１） 依存性符号の獲得
たとえば撮影した映像に内容記述を付加できるカメラがあるとすれば、それは上述したような（Ｔｓ，Ｘｓ，Ａｓ，Ｆｓ）を自動的に映像音声に付与できることが望ましい。Ｔｓ，Ｘｓは自動的に取得可能である。一方、Ａｓ，Ｆｓは人手を会した入力が必要である。そこで、ユーザから自然にメタデータ作成に関する情報を聞き出すための質問対話シナリオを用意することが考えられる。例えば、コンテンツ作成時に「観光、渋滞、ルートガイド」と音声入力、キー入力、アノテーション、メニュー選択などで入力し、その後のガイダンスプログラムに従って入力していけばよい。これによって、ユーザはただエージェントからの質問に答えるだけでよく、あれこれと悩むことなく記述を半自動的に付与することができる。
【０２１７】
（１８−２） 依存情報の更新
▲１▼メディアに付与される依存情報の更新
（９７年３月２日、横浜中華街、…）という映像コンテンツＣｘに写っている一群の女性のうちの一人『田○花子』が、今をときめくアイドル歌手『本○真奈美』であることがわかった、とする。
【０２１８】
このような場合、映像コンテンツＣｘへの要求度はアクター（Ａｓ）の要因に依存するように変化すると考えられる。その場合、その依存性符号の中のアクター（Ａｓ）に関する成分は「０」から「１」に更新される。
▲２▼ユーザ要求に応じてエージェントが作成する依存情報の更新
ユーザの検索履歴や他ユーザの検索履歴に応じて上記式３や式６の荷重ベクトルＷを修正することが考えられる。
【０２１９】
（１８−３） アプリケーションの普遍的表現
アプリケーションは時代とともに変化し、国や文化によっても異なる。一方、相互運用性のあるデータベースは継続して使用され得る。したがってアプリケーション名でコンテンツを分類することは特定サービスを想定して作ったコンテンツ以外では困難である。
【０２２０】
しかしながら、たとえば芸能界アイドル、渋滞情報、ニュース、観光情報などを考える場合、それらを扱うアプリケーションやコンテンツに対するユーザの視点は変わりうるが、基本的な評価属性としては一定かつ普遍的なものが存在すると考えられる。そこで、依存情報を普遍的な依存性要因で表現し、依存性テーブルにおいて依存性要因とアプリケーションとを関連付けることにより、普遍的なアプリケーション記述ができると考えられる。
【０２２１】
（１８−４） ユーザ側のアプリケーションからの符号化
ユーザ端末１００で選択できるアプリケーション１８０の集合を
Ａｃ ＝ ｛Ａｃ１，Ａｃ２，…，ＡｃＮ｝
とする。この中からユーザがあるアプリケーションＡｃｉを選択した場合、そのアプリケーションに相当する識別情報がサーバ装置２００のコンテンツデータベース２８２にあれば、ＡｃｉとコンテンツＣｌとの対応を取ることが可能である。しかし、現実には全世界のアプリケーションを統一的にしかも長期にわたって表現するような識別情報は存在しない。そこで、アプリケーションＡｃｉを標準的なメディア属性やユーザ属性に変換するための依存性テーブル１５０ａを用い、アプリケーションを依存性符号などの依存情報で表現する。
【０２２２】
（１８−５） サーバ側のアプリケーションからの符号化
同様に、データベースに蓄えられるコンテンツの作成者は、端末ユーザの選択するアプリケーションの集合を
Ａｍ ＝ ｛Ａｍ１，Ａｍ２，…，ＡｍＭ｝
とする。この中から該当するアプリケーションＡｍｊを選択し、サーバー装置２００の依存性テーブル２５０ａを用いて登録するコンテンツに適した依存性符号でＡｍｊを表現する。これにより、ＡｃとＡｍがまったく異なるアプリケーション集合であっても、依存性符号による普遍的表現を通じて、コンテンツの相互運用性が保証され、いかなる問い合わせに対しても安定した検索動作を実行することができる。
【０２２３】
なお、ユーザ端末１００のメモリ部１５０が「記憶手段」に相当し、サーバ装置２００のメモリ部２５０が「サーバ側記憶手段」に相当する。また、制御部１１０及び問い合わせ情報生成部１７０が「制御情報出力手段」に相当し、サーバ装置２００の制御部２１０、検索情報生成部２７０及び評価関数計算部２９０が「検索手段」に相当する。
【０２２４】
また、図１４に示した検索処理の変形例を図２６に示した。図１４に示す検索処理では、評価関数計算（Ｓ６６０）の後、１次検索リストを生成し（Ｓ６７０）、１次検索を完了したと判断すると（Ｓ６８０：ＹＥＳ）、メタデータによる２次検索を行っていた（Ｓ６９０）。これに対して、図２６に示すように、評価関数計算（Ｓ１５６０）の後、１次評価をパスしたか否かを判断し（Ｓ１５７０）、パスしていれば即座に、メタデータによる２次検索を行うようにしてもよい（Ｓ１５７０：ＹＥＳ，Ｓ１５８０）。
【０２２５】
また、別の変形例を図２７及び図２８に示した。この場合、図２７に示す検索処理の前半部分は図１４に示した処理とほぼ同様であるが、２次検索を完了した後（Ｓ１７９０：ＹＥＳ）、図２８のＳ１８００へ移行し、コンテンツリスト２８１にないメタデータがあれば（Ｓ１８００：ＹＥＳ）、メタデータ解析による評価関数計算を行い（Ｓ１８２０）、ここで１次評価をパスすれば（Ｓ１８３０：ＹＥＳ）、２次検索を行う（Ｓ１８４０）。
【０２２６】
このように検索処理もコンテンツリスト２８１の構造等によって種々のバリエーションで実現することができる。
以上、本発明はこのような実施例に何等限定されるものではなく、本発明の主旨を逸脱しない範囲において種々なる形態で実施し得る。
［その他］
（イ）依存性要因について
依存性要因としてユーザ要因、システム要因、及びメディア要因が考えられることは既に述べた。そして、このような依存性要因に対する依存性要因値は、状況取得部３０，１３０，２３０で取得されるデータに基づき確定されることも、上述したところである。ここでは、さらに、依存性要因として設定される、時間依存性、空間依存性、及び場面に関する依存性についての獲得方針等についての説明を加える。
【０２２７】
（ハ−１）時間依存性
ある属性の属性値又はアプリケーションの選択された時刻を時間軸上で記録し、１日、１週間、１ヶ月、１年といった各レベルの周期で出る傾向を分析する。特に各周期で一定したスペクトルが出なければ、依存性は判定できない。スペクトルが一定以上の大きさのものは時間周期への依存性があると判断する。
【０２２８】
（ハ−２）空間依存性
ある属性の属性値又はアプリケーションの選択された空間を空間リスト上で記録する。ここで、空間リストとは、駅前、飛行機内、レストラン、自動車内、公園、オフィス、・・・といった場所のカテゴリリスト、ＧＰＳ情報などから得られる位置情報リスト、あるいは、地名リストに相当する。特定の個人に依存しない空間依存性は、多数のユーザからのプロファイルや依存性要因の計測情報を集計して容易に作成できる。これによって、場所に付随して起動されるアプリケーションを予測することができる。
【０２２９】
また、カテゴリ別の空間リストを元に集計した空間依存性を用いると、物理的に異なる未知の空間でも、すでに依存特性が獲得されているカテゴリの空間であれば、あるアプリケーションプログラムへの要求度が高いかどうかを十分な計測データが集計される以前に予測できる。
【０２３０】
（ハ−３）場面への依存性
場面への依存性は、上述した時間や空間を含む様々な状況情報の組み合わせとして定義される。上述した依存性要因には状況情報も含まれるので、依存性要因の多元的組み合わせとして場面を表現できる。ただし、ユーザのためのシステム制御の観点から見た場合、意味のある場面の数は、複数の依存性要因のランダムな組み合わせに比べて、はるかに少ないと考えられる。したがって、定型的な場面は独立した依存性要因として定義するほうが効率的である。
【０２３１】
また、このような場面への依存性は、全くブランクの状態から学習させるのではなく、予めユーザやシステム開発者の手で入力しておくほうが使いやすい。したがって現在ある場面定義に対して新たな場面の追加や修正を半自動的に行える機能が必要である。これは依存性テーブル５０ａ上で最終的に実行されたアプリケーションに対応する依存ベクトルを記録しておき、クラスタリングした後に、クラスタ中に含まれるベクトル数が多いもの（発生頻度の高い場面）を記号化して登録しておくことにより達成される。
【０２３２】
（ニ）応用例
上記第１実施例の制御情報出力装置１は、家庭用電気器具を対象機器７０とする場合を含めて説明した。また、上記第２実施例では、検索システムとしての構成を示し、ナビゲーション装置あるいは携帯情報端末としてユーザ端末１００が構成できることを示した。
【０２３３】
さらに、例えば車両内に実施例の制御情報出力装置１（ユーザ端末１００）が搭載された場合を含め、制御情報（依存情報）を用いた制御動作の応用例を以下に述べる。
（ニ−１）ユーザカスタマイズ
▲１▼ユーザの好みに応じて景観スポットのメニューを表示する。
【０２３４】
▲２▼ユーザの好みに応じたインターネットホームページを検索する。
▲３▼ユーザの生活する地域に応じた情報検索を実行する。
▲４▼ディスプレイ上で状況に応じたキー配置やメニュー構成を提供する。
（ニ−２）表示形態の制御
▲１▼時間帯でポップアップメニューを変更する。
【０２３５】
▲２▼通信する相手に応じて通信データ形式を変更する。
▲３▼運転状況、周囲環境に応じて画面構成を適応的に変更する。
（ニ−３）音声出力の制御
▲１▼交差点に近づいたり、あるいは、低速走行になったりしたときは自動的にボリュームを下げる。
【０２３６】
▲２▼状況に応じて音を鳴らさない構成を提供する。例えばコンサートホール内という状況を判断して着信音を鳴らさないという具合である。音を鳴らすというアプリケーションプログラムへの要求度は、場所への依存性が高いためである。
（ニ−４）モーダルの変更
▲１▼音声応答が不適当の場合は画像や文字で表示する。
【０２３７】
▲２▼画像や文字が不適当な場合は音声で伝達する。
▲３▼音声のみでは不十分の場合は画像・文字を同時に表示する。
▲４▼画像・文字のみで不十分な場合は音声を併用する。
（ニ−５）通信環境の適応化
例えば、上記第２実施例中で説明した図２０中のＳ１１００〜Ｓ１１６０では、検索されたコンテンツに合わせて要約動作の有無や符号化方式を決定して配信処理を行っている。データ検索の効率化を達成するには、検索面だけでなく通信面も含めて考える必要がある。つまり、通信環境の適応化を行う必要がある。
【０２３８】
▲１▼通信システムの適合性
あるコンテンツＣｌにとって最適な通信環境は依存性要因Ｘｋに依存する。したがって、例えば、ある局面（端末の移動速度、場所、チャネルビットレート）における通信システムの適合性の評価を行うことができる。具体的には、複数システムについて評価を実施し、最適なものを選択したり、単一システムについて評価を実施し、最適なパラメータを推定したりすることができる。
【０２３９】
▲２▼通信システムの選択
トンネルなどで通信が切れやすい状況では通信検索からローカルメディア検索または路車間通信などに切り替える。ここで、この通信制御アプリケーションの要求度は場所、移動速度、天候などに対して依存性が高いと判断できる。すなわち、山が多くてトンネルや斜面の影響で電波がとぎれやすい場所ではこの通信制御アプリケーションの重要性が高まる。また、場所に応じて高速ダウンロードできる基地局を移動端末に割り当てる。さらに、複数の通信路が使用可能である場合、コストテーブルに基づき、もっとも低価格の通信路を選択する。
【０２４０】
▲３▼適応通信システム概要
適応通信システムの概要を図２９に示した。
図２９には、ユーザ環境・端末環境、メディア環境、通信環境という３つの環境を統合的に判断し、制御対象を制御する適応通信システムを示した。
【０２４１】
ユーザ・端末環境には、時間、場所、移動速度、周囲の渋滞状況、予定経路、ドライバー／非ドライバーの区別、希望するアプリケーション、要求コンテンツの内容・品質、ユーザの要求コスト、要求の緊急度などが含まれる。また、メディア環境には、人気度・アクセス集中度、サイトの種類、ジャンル、映像・音楽・文字・データの区別、記述形式、データ量などが含まれる。また、通信環境には、選択可能な通信レート、トラフィックの混み具合などが含まれる。このような種々の環境に基づき、適応通信システムは、伝送時期、伝送場所、通信システム、通信レート、通信方式、通信プロトコル・暗号化手段、通信プロファイル形式、多重化方法、検索・フィルタリング・処理方式、記述方式・符号化方式を制御する。
【０２４２】
従来の技術によっては、このような種々の環境を総括的に捉えることは容易でない。ところが、依存性という概念の導入によって、３つの環境を総括的に捉えることができ、適切な通信制御が可能になるのである。これは環境と表現される種々の要因を依存性で普遍的に記述できることを意味する。そして、この環境は、本実施例で示したようなアプリケーションという概念によって具体化できるのである。
【図面の簡単な説明】
【図１】第１実施例の制御情報出力装置の構成を示すブロック図である。
【図２】制御情報出力装置における制御部の機能ブロック図である。
【図３】依存性テーブルを例示する説明図である。
【図４】依存特性を例示する説明図である。
【図５】制御情報出力処理を示すフローチャートである。
【図６】依存性テーブルに基づく探索処理を示すための説明図である。
【図７】依存性テーブルに基づく探索処理を示すための説明図である。
【図８】対象機器側処理を示すフローチャートである。
【図９】制御情報出力装置を用いたシステム構成例を示す説明図である。
【図１０】第２実施例の検索システムの構成を示すブロック図である。
【図１１】検索処理の概要を示す説明図である。
【図１２】コンテンツ登録処理を示すフローチャートである。
【図１３】問い合わせ処理を示すフローチャートである。
【図１４】検索処理を示すフローチャートである。
【図１５】依存性要因値に対応する依存具合の表現手法を示す説明図である。
【図１６】ＤＣ管理テーブルによる依存性符号の再利用を示す説明図である。
【図１７】１次検索処理の前半部分を示すフローチャートである。
【図１８】１次検索処理の後半部分を示すフローチャートである。
【図１９】２次検索処理の前半部分を示すフローチャートである。
【図２０】２次検索処理の後半部分を示すフローチャートである。
【図２１】コンテンツ評価処理を示すフローチャートである。
【図２２】シーン時間とシーンへの要求度との関係を示す説明図である。
【図２３】シーンのアプリケーションと属性との関係を示す説明図である。
【図２４】コンテンツ追加処理を示すフローチャートである。
【図２５】車両情報機器における依存性要因を例示した説明図である。
【図２６】検索処理の変形例を示すフローチャートである。
【図２７】検索処理の別変形例の前半部分を示すフローチャートである。
【図２８】検索処理の別変形例の後半部分を示すフローチャートである。
【図２９】応用例としての適応通信システムの概要を示す説明図である。
【符号の説明】
１…制御情報出力装置
１０…制御部
１１…アプリケーション情報生成ブロック
１２…依存性情報生成ブロック
１３…制御情報生成ブロック
１４…符号化ブロック
２０…入力部
３０…状況取得部
４０…出力部
５０…メモリ部
５０ａ…依存性テーブル
５０ｂ…依存特性情報
５０ｃ…従属性テーブル
６０…表示部
７０…対象機器
７１…制御装置
１００…ユーザ端末
２００…サーバ装置
１１０，２１０…制御部
１２０，２２０…入力部
１３０，２３０…状況取得部
１４０，２４０…通信部
１５０，２５０…メモリ部
１５０ａ，２５０ａ…依存性テーブル
１５０ｂ，２５０ｂ…依存特性情報
１５０ｃ，２５０ｃ…量子化テーブル
１６０…表示部
１７０…問い合わせ情報生成部
１８０…アプリケーション
２６０…情報出力部
２７０…検索情報生成部
２８１…コンテンツリスト
２８２…コンテンツデータベース
２９０…評価関数計算部
２９１…検索リスト記憶部

Claims (32)

1. 対象機器にて実行されるアプリケーションプログラムと前記アプリケーションプログラムのそれぞれに対するユーザの要求がどの要因に依存して変化するかを示す依存性要因とを対応付ける依存情報を記憶する記憶手段と、
   ユーザからの指示情報または外部の状況を示す状況情報を取得する取得手段と、
   前記取得手段によって取得された前記指示情報または前記状況情報に基づき、前記記憶手段に記憶された依存情報を参照して、前記対象機器の動作・設定に利用される制御情報を生成して出力する制御情報出力手段とを備え、
   前記依存情報は、依存の度合いである依存度も表現可能とし、前記アプリケーションプログラムと前記依存性要因とを対応付ける２次元テーブルとして前記記憶手段に記憶されており、
   前記制御情報出力手段は、次の（１）から（５）の何れかの情報を前記制御情報として出力し、このうち（５）のアプリケーションリストを前記制御情報として出力する際には、次の（６）から（１０）の何れかの情報に基づき、相対的に実行要求の高いアプリケーションプログラムを判断し、当該アプリケーションプログラムを示すアプリケーションリストを前記制御情報として、前記制御情報を符号化して出力すること
   を特徴とする制御情報出力装置。
   （１）前記依存情報
   （２）前記依存性要因が連続的又は離散的な値である依存性要因値と前記アプリケーションプログラムへのユーザの統計的な要求度合いである要求度との対応関係である依存特性
   （３）前記依存性要因の中で相対的に有効であると想定される依存性要因を示す依存性要因リスト
   （４）前記依存性要因値を取得する依存性要因値取得手段を備え、前記依存性要因値取得手段にて取得された前記依存性要因値の中の、前記相対的に有効であると想定される依存性要因に対応する依存性要因値
   （５）前記依存性要因値を取得する依存性要因値取得手段を備え、前記依存性要因値取得手段にて取得された前記依存性要因値及び前記依存特性に基づいて相対的に実行要求の高いと判断したアプリケーションプログラムを示すアプリケーションリスト
   （６）前記依存性要因値及び前記依存特性
   （７）入力手段を介して前記アプリケーションプログラムが選択指示されると、当該アプリケーションプログラムに依存する依存性要因を前記依存情報に基づき探索し、当該探索された依存性要因に対応して前記依存性要因値取得手段にて取得される依存性要因値及び前記依存特性
   （８）前記依存性要因値及び前記依存特性を用い前記依存性要因に対して求めた、前記アプリケーションプログラムへのユーザの統計的な要求度合いである要求度
   （９）前記各依存性要因に対する要求度に基づき前記アプリケーションプログラムの前記依存性要因に対して求めた実行確信度
   （１０）前記記憶手段に記憶された前記アプリケーションプログラム間の従属関係を参照して補正した前記実行確信度
2. 請求項１に記載の制御情報出力装置において、
   前記依存性要因は、ユーザに関連する要因であるユーザ要因、前記制御情報によって制御されるシステムに関連する要因であるシステム要因、又は、前記アプリケーションプログラムの処理対象となるメディアに関する要因であるメディア要因の少なくとも一つを含むものであり、
   前記ユーザ要因とは、ユーザの置かれた環境、ユーザの置かれた状況、ユーザの要求またはユーザの状態に関連する要因であり、前記ユーザの置かれた環境に関する要因としては、時刻、場所、仕事内容または雑音の有無が含まれ、前記ユーザの置かれた状況に関す る要因としては、時刻、場所、仕事内容または雑音の有無が含まれ、前記ユーザの要求に関する要因には生活ニーズまたは趣味が含まれ、前記ユーザの状態に関する要因には生活ニーズまたは趣味が含まれ、
   前記システム要因とは、前記制御情報によって制御されるシステムに関連する要因であり、その要因としては、メモリ容量、並行して実行可能なアプリケーションプログラムの数、処理能力、動作環境、通信条件、通信コスト、または表示デバイス条件が含まれ、
   前記メディア要因とは、前記アプリケーションプログラムの処理対象となるメディアに関する要因であり、その要因としては、メディアのタイプ、メディアに格納されるコンテンツに関する情報、ジャンル、製作者、日時、または、場所が含まれること
   を特徴とする制御情報出力装置。
3. 請求項１または２に記載の制御情報出力装置において、
   前記依存性要因が連続的又は離散的な値である依存性要因値をとることを前提として、前記アプリケーションプログラムへのユーザの統計的な要求度合いである要求度が前記依存性要因値に対して相対的に大きく変動する場合に、当該依存性要因に当該アプリケーションプログラムが依存すると定義したこと
   を特徴とする制御情報出力装置。
4. 請求項３に記載の制御情報出力装置において、
   前記要求度が前記依存性要因値に対して相対的に大きく変動する場合は、前記依存性要因のとり得る前記依存性要因値に対して、前記要求度の最大変動幅が第１の閾値を上回り、かつ、前記要求度の最大値が第２の閾値を上回り、かつ、前記依存性要因値と前記要求度との対応関係である依存特性が時間経過に対して一定又は規則性を有する場合であること
   を特徴とする制御情報出力装置。
5. 請求項１〜４のいずれかに記載の制御情報出力装置において、
   前記依存性要因リストは、前記依存性要因の有効度合いに応じて複数レベルに階層化されていること
   を特徴とする制御情報出力装置。
6. 請求項１〜５のいずれかに記載の制御情報出力装置において、
   前記制御情報出力手段は、前記相対的に実行要求の高いアプリケーションプログラムに対する要求度に基づき、未知の依存性要因値を推定すること
   を特徴とする制御情報出力装置。
7. 請求項１〜６のいずれかに記載の制御情報出力装置において、
   前記アプリケーションリストは、前記実行要求度合いに応じて複数レベルに階層化されていること
   を特徴とする制御情報出力装置。
8. 請求項１〜７のいずれかに記載の制御情報出力装置において、
   前記制御情報出力手段は、入力手段を介してユーザから入力されるアプリケーションプログラム選択指示に基づいて、前記依存特性を統計的に学習変更すること
   を特徴とする制御情報出力装置。
9. 請求項８に記載の制御情報出力装置において、
   前記制御情報出力手段は、前記依存特性の学習変更に応じて前記依存情報も学習変更すること
   を特徴とする制御情報出力装置。
10. 請求項１〜９のいずれかに記載の制御情報出力装置において、
    前記制御情報出力手段は、前記制御情報を外部装置へ通信手段を介して出力すること
    を特徴とする制御情報出力装置。
11. 請求項１〜１０のいずれかに記載の制御情報出力装置において、
    前記制御情報出力手段は、前記制御情報を着脱可能な記録媒体に出力すること
    を特徴とする制御情報出力装置。
12. 請求項１〜１１のいずれかに記載の制御情報出力装置と、
    前記制御情報出力手段によって出力される前記制御情報に基づく処理を行う情報処理装置とを備えていること
    を特徴とする情報システム。
13. 請求項１２に記載の情報システムにおいて、
    前記情報処理装置は、前記制御情報出力手段によって符号化された前記制御情報が出力されることを前提として、前記制御情報を復号化する復号化手段を備えていること
    を特徴とする情報システム。
14. 請求項１２又は１３に記載の情報システムにおいて、
    前記情報処理装置は、前記通信手段を介して送信される前記制御情報を利用してデータベース検索を行う前記対象機器としてのサーバ装置であること
    を特徴とする情報システム。
15. 請求項１２又は１３に記載の情報システムにおいて、
    前記情報処理装置は、記録媒体へ出力された前記制御情報を読み込んで動作する前記対象機器であること
    を特徴とする情報システム。
16. 請求項１２又は１３に記載の情報システムにおいて、
    前記情報処理装置は、前記制御情報を読み込んで前記複数の対象機器を制御する制御装置であること
    を特徴とする情報システム。
17. 請求項１２又は１３に記載の情報システムにおいて、
    前記制御情報出力装置は、複数の対象機器を操作するリモートコントロール端末であり、
    前記情報処理装置は、前記リモートコントロール端末から送信される前記制御情報を読み込んで動作する対象機器であること
    を特徴とする情報システム。
18. 請求項１〜９のいずれかに記載の制御情報出力装置と、
    前記制御情報出力手段によって出力される前記制御情報を利用して、アプリケーションの検索を行う検索手段を有したサーバ装置とを備えていること
    を特徴とする情報システム。
19. 請求項１８に記載の情報システムにおいて、
    前記制御情報出力装置又は前記サーバ装置の少なくともいずれか一方は、前記依存性要因のとり得る依存性要因値を量子化可能であること
    を特徴とする情報システム。
20. 請求項１８又は１９に記載の情報システムにおいて、
    前記サーバ装置は、前記アプリケーションが予め定められた依存性要因に依存するか否かを示すアプリ依存情報を記憶するサーバ側記憶手段を有しており、
    前記検索手段は、前記サーバ側記憶手段に記憶された前記アプリ依存情報に基づく検索を行うこと
    を特徴とする情報システム。
21. 請求項２０に記載の情報システムにおいて、
    前記制御情報には、前記依存性要因に依存するか否かを示す依存ベクトルがユーザ要求として含まれ、
    一方、前記アプリ依存情報には、検索に係る依存性要因に前記アプリケーションが依存するか否かを示す特性ベクトルが含まれており、
    前記検索手段は、前記依存ベクトルと前記特性ベクトルとの内積演算によって検索を行うこと
    を特徴とする情報システム。
22. 請求項２１に記載の情報システムにおいて、
    前記特性ベクトルは、前記アプリケーションの詳細データから生成可能としたこと
    を特徴とする情報システム。
23. 請求項２２に記載の情報システムにおいて、
    前記アプリケーションの詳細データから生成された特性ベクトルは、前記サーバ側記憶手段に追加記憶されて再利用されること
    を特徴とする情報システム。
24. 請求項２１〜２３のいずれかに記載の情報システムにおいて、
    前記依存ベクトル及び前記特性ベクトルは、依存の度合いである依存度も表現可能としたこと
    を特徴とする情報システム。
25. 請求項２１〜２４のいずれかに記載の情報システムにおいて、
    前記依存ベクトル及び前記特性ベクトルの成分は、依存性要因のとり得る依存性要因値に対する依存具合を表現可能にしたこと
    を特徴とする情報システム。
26. 請求項２１〜２３のいずれかに記載の情報システムにおいて、
    前記依存ベクトル及び前記特性ベクトルは、その成分が「０」又は「１」の２値で表現される依存性符号として実現されていること
    を特徴とする情報システム。
27. 請求項２１〜２６のいずれかに記載の情報システムにおいて、
    前記内積演算では、前記検索に係る依存性要因の中の所定要因に対する成分のみの演算を行うこと
    を特徴とする情報システム。
28. 請求項２１〜２７のいずれかに記載の情報システムにおいて、
    前記内積演算では、前記検索に係る依存性要因に対する成分に優先順位を付けて計算し、各成分毎に予め定められた基準を満たさない場合、演算を途中で停止すること
    を特徴とする情報システム。
29. 請求項２１〜２８のいずれかに記載の情報システムにおいて、
    前記検索手段は、前記内積演算による１次検索に続けて、前記アプリケーションの詳細データに基づく２次検索を行うこと
    を特徴とする情報システム。
30. 請求項１〜９のいずれかに記載の制御情報出力装置であって、前記依存情報のうちユーザ側で予め定められた依存性要因に依存するか否かを示すユーザ側依存情報によってユーザ側のアプリケーションを表現し、前記ユーザ側依存情報に基づき制御情報を出力する制御情報出力装置と、
    サーバ側で予め定められた依存性要因に依存するか否かを示すサーバ側依存情報によってサーバ側のアプリケーションを表現し、前記制御情報に基づき、前記ユーザ側のアプリケーションと前記サーバ側のアプリケーションとを関連付けて動作するサーバ装置とを備えたこと
    を特徴とする情報システム。
31. 請求項３０に記載の情報システムにおいて、
    前記ユーザ側依存情報及び前記サーバ側依存情報は、ベクトル成分が「０」又は「１」の２値で表現される依存性符号として実現されていること
    を特徴とする情報システム。
32. 請求項３０又は３１に記載の情報システムにおいて、
    前記サーバ側依存情報は、前記アプリケーションの追加時点で入力される情報を用い、アプリケーションを特定する言語表現と前記サーバ側依存情報との対応関係テーブルに基づき生成されること
    を特徴とする情報システム。

Images