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

Abstract

(57)【要約】 【課題】 操作対象となる機器、及び当該機器に対して
ユーザ要求を発生させる種々の要因を統括的に捉え、対
象機器を総合的に、しかも、半自動的にセットアップし
て動作させるための構成を提供する。 【解決手段】 対象機器７０にて実行される各アプリケ
ーションと予め定められた依存性要因との間に、依存特
性情報５０ｂなる依存関係を用意する。また、この依存
関係を用い、各アプリケーションがいずれの依存性要因
に依存するかを示す依存性テーブル５０ａを用意する。
そして、状況取得部３０にて取得されるデータより確定
される依存性要因値を用い、メモリ部５０の依存性テー
ブル５０ａ及び依存特性情報５０ｂに基づいて、実行要
求の大きなアプリケーションを示すアプリケーションリ
スト、有効な依存性要因を示す依存性要因リスト、依存
ベクトル及び依存特性からなる制御情報を出力部４０か
ら出力する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、個々の状況に対応
させて各種機器を動作させるための制御情報を出力する
制御情報出力装置及び情報システムに関する。

【０００２】

【従来の技術及び発明が解決しようとする課題】近年、
コンピュータシステムの発達に伴い、コンピュータ制御
される機器は多岐に渡るようになってきた。例えばテレ
ビジョン受像機・ビデオレコーダ・電気冷蔵庫・電気炊
飯器・エアコン・オーディオ機器・ゲーム機など、家庭
用電気器具のほとんどがマイコン等のコンピュータシス
テムを搭載しており、このコンピュータシステムにて実
行されるプログラムで動作する。また、自動車内を考え
ても、ナビゲーション装置によるルート案内をはじめ、
インターネットを用いた施設検索まで可能となってい
る。

【０００３】このようなコンピュータ制御によって、生
活の各部で自動化が推進され、ユーザの有効な時間利用
が促進される。例えば午前７時に朝食を摂りたいと思え
ば、電気炊飯器の炊きあがり時刻を午前７時にセットし
ておくだけで、その時刻に丁度炊けるように電源が入り
動作するという具合である。

【０００４】しかしながら現状、このようなコンピュー
タ技術の進歩により、ユーザの有効な時間利用が促進さ
れているとは言えない状況がある。それは、操作自体は
簡単になってきているが、ユーザ自らが個々の状況に対
して要求・設定などを行わなければならないためであ
る。上述した例で言えば、炊きあがり時刻を午前７時に
するように、ユーザ自らが設定を行う必要があった。つ
まり、いくらコンピュータシステムを搭載していると言
っても、電気炊飯器自体が、ユーザに先回りして炊きあ
がり時刻を自動設定することはない。

【０００５】一方、このように炊きあがり時刻が７時に
なるように電気炊飯器を動作させたいといったユーザ要
求は種々の要因から決定できるものであり、このような
ユーザ要求がある程度の確率で決定できれば、電気炊飯
器に限らず、上述したような家庭電気器具を総合的に、
しかも、半自動的にセットアップして使用することがで
きる。

【０００６】例えば特許第２６９５５４２号公報には、
ユーザに関する情報を管理し、ユーザの特質に沿った情
報処理を行う装置が開示されている。また、特開平７−
２６１９９４号公報には、現象と行動とを対応付けてソ
フトウェアをカスタマイズする方法が開示されている。
前者はメッセージパターンのマッチングを行うというパ
ターン化の手法であり、後者は現象・行動を類型化する
という、これもパターン化の手法である。

【０００７】ところが、上述した例では、ユーザの操作
対象となる機器が多岐に渡り、また、それら機器に対す
るユーザ要求が様々な要因から生じるため、公報記載の
技術を適用することは困難である。ユーザ行動などのパ
ターン化には限界があるためである。

【０００８】本発明は、上述した問題を解決するために
なされたものであり、操作対象となる機器、及び当該機
器に対してユーザ要求を発生させる種々の要因を統括的
に捉え、対象機器を総合的に、しかも、半自動的にセッ
トアップして動作させるための構成を提供することを目
的とする。

【０００９】

【課題を解決するための手段及び発明の効果】上述した
目的を達成するためになされた請求項１に記載の制御情
報出力装置は、記憶手段に依存情報を記憶している。こ
の依存情報は、対象機器において実行されるアプリケー
ションプログラムのそれぞれが、予め定められた依存性
要因に依存するか否かを示す情報である。そして、制御
情報出力手段は、この依存情報に基づき、制御情報を出
力する。

【００１０】ここで「対象機器にて実行されるアプリケ
ーションプログラム」とは、上述したような各種機器な
どに搭載されるアプリケーションプログラムや対象機器
としてのパーソナルコンピュータ等に搭載されるアプリ
ケーションプログラムを意味する。つまり、本発明で
は、対象機器をそれらに搭載されたプログラムの単位で
捉えるのである。なお、対象機器がパーソナルコンピュ
ータに相当する場合には、本装置がこのパーソナルコン
ピュータ内部に設けられる構成であってももちろんよ
い。

【００１１】対象機器をそれらに搭載されたプログラム
の単位で捉えることを、例えば電気炊飯器とビデオレコ
ーダとが対象機器となる場合を例に挙げて説明する。こ
のとき、電気炊飯器にＡ及びＢの２つのアプリケーショ
ンプログラムが搭載されており、ビデオレコーダにＣ〜
Ｅの３つのアプリケーションプログラムが搭載されてい
るとすれば、対象機器にて実行されるアプリケーション
プログラムは、Ａ〜Ｅの５つのアプリケーションプログ
ラムとなる。なお、アプリケーションプログラムという
表現を用いたのは、コンピュータシステムの基本動作を
実現するオペレーティングシステムなどのプログラムと
区別する意図である。また、ここでいう「アプリケーシ
ョンプログラム」には、大規模のものから、上述した家
庭用電気器具に組み込まれるマイコンにて実行される、
スイッチ等のハードウェアに対してオン／オフ動作など
を行う小規模なものまで含まれる。

【００１２】また、「予め定められた依存性要因」は、
例えば、ユーザ要因・システム要因・メディア要因の少
なくとも一つを含むものとすることが考えられる（請求
項２）。ユーザ要因とは、ユーザに関連する要因であ
り、ユーザの置かれた環境・状況やユーザの要求・状態
などに関連するものである。例えば環境・状況には、時
刻、場所、仕事内容、雑音の有無といった周囲条件など
が挙げられる。また例えば要求・状態には、「食べた
い」、「休憩したい」といった生活ニーズ、趣味などが
挙げられる。その他ユーザに関連する要因としては、ユ
ーザの嗜好性などが考えられる。

【００１３】システム要因とは、制御情報によって制御
されるシステムに関連する要因であり、例えば次のよう
なものが含まれる。メモリ容量、並行して実行可能なア
プリケーションプログラムの数、処理能力、動作環境を
はじめ、通信を行うことを前提とし、通信条件、通信コ
スト、また、ディスプレイなどの表示機器を備えること
を前提とし、画面サイズといった表示デバイス条件など
を挙げることができる。ここで「システム」としたの
は、上述した対象機器の要因だけでなく、本装置側の要
因も、また対象機器を制御する制御装置が存在する場合
には、その制御装置の要因をも含める意図である。

【００１４】メディア要因とは、アプリケーションプロ
グラムの処理対象となるメディアに関する要因である。
これには、ＤＶＤ，ＣＤ−ＲＯＭといったメディアのタ
イプ、メディアに格納されるコンテンツに関する情報、
例えばジャンル、製作者、日時、場所などが含まれる。

【００１５】本発明では、上述したようなアプリケーシ
ョンプログラムのそれぞれが、このような依存性要因に
依存するか否かを依存情報として記憶しておく。例え
ば、上述した電気炊飯器の自動炊飯アプリケーションは
ユーザ要因である時刻、生活ニーズに依存するという具
合である。そして、このような依存情報に基づく制御情
報を出力する。

【００１６】つまり、ユーザの操作対象となる様々な機
器をアプリケーションの単位で捉え、これらアプリケー
ションプログラムと、これらアプリケーションプログラ
ムへの要求を生じさせる各種要因との間に依存性という
概念を導入した。これによって、操作対象となる機器、
及び当該機器に対してユーザ要求を発生させる種々の要
因を統括的に捉えることができる。そして、制御情報に
基づき対象機器がそれに応じた動作を行うように構成す
れば、対象機器を総合的に、しかも、半自動的にセット
アップして動作させることができる。電気炊飯器の例で
言えば、ユーザ要因である時刻に自動炊飯アプリケーシ
ョンが依存することを示す制御情報に基づき、ユーザが
炊飯時刻を一度設定した後には、その炊飯時刻を記憶し
ておき、ユーザが単に炊飯動作の開始を指示するだけ
で、炊きあがり時刻を前回の予約時刻に設定するか否か
をユーザに問い合わせるように動作させることができ
る。

【００１７】なお、依存情報は、アプリケーションプロ
グラムと依存性要因とを対応付ける２次元テーブルとし
て記憶することが考えられる（請求項３）。例えば横の
欄に依存性要因を記述し、縦の欄にアプリケーションプ
ログラムを記述した２次元テーブルとして記憶するとい
う具合である。このとき、アプリケーションプログラム
と依存性要因とがクロスする欄に、依存しているか否か
の情報を記述する。例えば、依存している場合には
「Ｄ」を記述し、依存していない場合には空白にするこ
とが考えられる。また、依存していることを示す「１」
と依存していないことを示す「０」で記述してもよい。
このような数値を用いてテーブルを記述すれば、依存情
報をブール行列として計算上用いることもできる。

【００１８】さらにまた、依存しているか否かという２
値の情報だけでなく、依存度合いである依存度を表現で
きるようにしてもよい（請求項４）。例えば依存度合い
が最も高い「１０」から依存していないことを示す
「０」までといった多値の情報をテーブルに記述できる
ようにするという具合である。このようにすれば、各種
の依存性要因に重み付けを行うことができ、ユーザ要求
を細かく決定することができる。したがって、ユーザの
フィーリングにより合った機器制御を行えることにな
る。

【００１９】ところで、「依存する」という状態をどの
ように定義するかが問題となるが、例えば請求項５に示
すようにして定義すればよい。ここでいう依存性要因値
とは、例えばユーザ要因である時刻を１日の単位で考え
れば、依存性要因値は、午前０時から午後１２時までの
時刻となる。また、ユーザ要因である場所を考えれば、
依存性要因値は、レストラン、公園、スポーツ施設、会
社、自宅、車内などという値となる。前者は連続的なも
のとして、後者は離散的なものとして考えることができ
る。

【００２０】例えば文書作成を行うためのアプリケーシ
ョンプログラムは、勤務時間内にはその要求度が高くな
り、勤務時間外では要求度が低くなるという具合に、時
刻という要因に対して要求度が相対的に大きく変動する
という状況が考えられる。したがってこの場合、文書作
成アプリケーションは、ユーザ要因である時刻に依存す
るものといえる。

【００２１】要求度が依存性要因値に対して相対的に大
きく変動する場合を、さらに具体的に定義すれば、例え
ば請求項６に示すような場合とすることが考えられる。
ここでは、要求度の変動を定量的に判断する。また、依
存性要因値と要求度との対応関係である依存特性が時間
経過に対して一定又は規則性を有することを条件とし
た。例えば１日の中で時刻に対して要求度が大きく変動
するアプリケーションプログラムであっても、要求度の
変動が日々異なる場合には、時間に対する依存性がある
とは言えないからである。

【００２２】なお、制御情報出力手段が依存情報に基づ
いて制御情報を出力することは既に述べた。この制御情
報は、依存情報そのものであることが考えられる（請求
項７）。この場合、依存情報の一部を出力する場合も含
まれる。また、依存情報に加えあるいは代え、依存性要
因値と要求度との対応関係である依存特性を制御情報と
して出力することが考えられる（請求項８）。このよう
な依存特性に基づけば、ユーザ個々に依存特性が異なる
場合にも、各ユーザに合わせた細かな制御が可能とな
る。

【００２３】さらに、上述した情報に加え又は代え、請
求項９に示すように依存性要因リストを制御情報として
出力してもよい。相対的に有効であると想定される依存
性要因のリストを出力すれば、対象機器側で有効な依存
性要因に基づく制御が可能となるためである。このよう
に相対的に有効であると想定される依存性要因のリスト
を出力するのは、依存情報によって判断できる依存性要
因であっても、周囲条件などによって依存性要因値の信
頼度が低くなり、依存性要因が不適切なものとなる可能
性があるためである。また、依存特性から算出される要
求度が低い場合にも、有効な依存性要因ということはで
きない。

【００２４】このような依存性要因リストは、依存性要
因の有効度合いに応じて複数レベルに階層化して出力す
ることが考えられる（請求項１０）。なお、相対的に有
効であると想定される依存性要因は、周囲条件や要求度
など応じて判断することが考えられる。また、依存性要
因値を取得する依存性要因値取得手段を備える構成とし
（請求項１１）、この依存性要因値取得手段にて取得さ
れる依存性要因値に基づいて判断してもよい。例えば依
存性要因値が所定の範囲内の値となっていない場合を判
断するという具合である。

【００２５】依存性要因値取得手段を備える構成を前提
とすれば、請求項１２に示すように、依存性要因値を制
御情報として出力するようにしてもよい。この依存性要
因値の出力においても、上述した依存性要因リストと同
様に、相対的に有効であると想定される依存性要因に対
応する依存性要因値を制御情報として出力することが考
えられる（請求項１３）。

【００２６】さらにまた、上述した情報に加え又は代
え、制御情報出力手段は、相対的に実行要求の高いアプ
リケーションプログラム判断し、アプリケーションリス
トを制御情報として出力することが考えられる（請求項
１４）。このようなアプリケーションリストを出力すれ
ば、対象機器側において、アプリケーションプログラム
を迅速に起動したり、起動準備、例えばメニューの最初
にそのアプリケーションプログラムに関するメニューを
表示するといった制御ができる。

【００２７】なお、このようなアプリケーションリスト
は、直接的なユーザ要求に基づいて作成してもよい。す
なわち、請求項１５に示す如くである。具体的には、依
存性要因値及び依存特性を用い依存性要因に対する要求
度を求め、当該要求度に基づいて相対的に実行要求の高
いアプリケーションプログラムを判断することが考えら
れる（請求項１６）。要求度が所定値以上となったアプ
リケーションプログラムを、実行要求の高いものと判断
するという具合である。このアプリケーションプログラ
ムへの要求度は、依存性要因に対して個々に求められる
ものである。したがって、請求項１７に示すように、実
行確信度に基づいて相対的に実行要求の高いアプリケー
ションプログラムを判断するようにしてもよい。例え
ば、各依存性要因に対する要求度を平均し、この平均に
基づき、相対的に実行要求の高いアプリケーションプロ
グラム判断するという具合である。

【００２８】このようにして得られる実行確信度が相対
的に高いアプリケーションプログラムは確かにユーザ要
求に沿ったものである可能性が高いが、所定のアプリケ
ーションプログラムへのユーザ要求は実行中のアプリケ
ーションプログラムに多分に関連していることがある。
したがって請求項１８に示す構成を採用することが好ま
しい。例えば文書作成アプリケーションと共に表計算ア
プリケーションが使用される可能性が高いという事実が
あれば、表計算アプリケーションが文書作成アプリケー
ションに従属するという従属関係を記憶しておく。この
ようにすれば、より適切なアプリケーションプログラム
の起動・起動準備が実現される。

【００２９】ところで、相対的に実行要求の高いアプリ
ケーションプログラムを判断すれば、依存性要因値が確
定していない依存性要因に対する要求度が推定できる。
そこで、請求項１９の構成を採用することが考えられ
る。確定した依存性要因値に対しては要求度が算出可能
であるため、それら算出された要求度と同様の要求度で
あるとして、未知の依存性要因値を推定することができ
る。ここで相対的に実行要求の高いアプリケーションプ
ログラムには、ユーザが直接的に選択したアプリケーシ
ョンプログラムも含まれる。

【００３０】なお、以上のようなアプリケーションリス
トは、依存性要因リストと同様に、実行要求度合いに応
じて複数レベルに階層化して出力することが考えられる
（請求項２０）。ところで、依存特性や依存情報は、一
度作成された後は固定的な情報として用いてもよいが、
ユーザからのアプリケーションプログラムの選択状況な
どから動的に学習されることが望ましい。

【００３１】そこで、請求項２１に示すように、依存特
性を統計的に学習変更するようにするとよい。これによ
って、ユーザの行動パターンが変わっても、依存性要因
から常に適切な要求度を算出することができる。また、
制御情報出力手段は、依存特性の学習変更に応じて依存
情報をも学習変更することが考えられる（請求項２
２）。すなわち、依存特性の変化によって、アプリケー
ションプログラムが依存するとされていた依存性要因に
依存しなくなる可能性がある。逆に依存しないとされて
いた依存性要因に依存するようになる可能性がある。そ
こで、上述したような依存性の定義に照らし合わせ、自
動的に依存情報を学習変更するようにする。これによっ
て、情報処理装置側では、ユーザの行動パターンが変わ
っても、適切な処理が実行可能となる。

【００３２】なお、制御情報出力手段は、制御情報を通
信手段を介して外部装置へ出力することが考えられる
（請求項２３）。また、制御情報を着脱可能な記録媒体
に出力するようにしてもよい（請求項２４）。例えば小
型のメモリカードなどの記録媒体に出力するという具合
である。また、特に記憶容量の限られた記録媒体に出力
する場合などを考えると、制御情報を符号化して出力す
るようにすることが望ましい（請求項２５）。

【００３３】以上は、制御情報出力装置の発明として説
明してきたが、本発明は、上述した制御情報出力装置
と、制御情報出力手段によって出力される制御情報に基
づく処理を行う情報処理装置とを備えていることを特徴
とする情報システムの発明として実現することもできる
（請求項２６）。なお、符号化した制御情報が出力され
る場合、情報処理装置は、制御情報を復号化する復号化
手段を備える構成とする（請求項２７）。

【００３４】情報処理装置は、具体的に、請求項２８に
示すようなサーバ装置であることが考えられる。このと
きは、制御情報として依存性要因リスト、依存特性など
を出力する前提の下、適切な範囲でデータベース検索を
行うことができる。また、情報処理装置は、記録媒体へ
出力された制御情報を読み込んで動作する対象機器であ
ることが考えられる（請求項２９）。例えば記録媒体か
ら制御情報を読み出して動作するテレビジョン受像機と
して実現されるという具合である。この場合は、ユーザ
要因である時刻にテレビジョン受像機の電源オン／オフ
アプリケーションやチャンネル設定アプリケーションが
依存するといった依存情報及び、時刻に係る依存特性を
制御情報として出力する。これによってテレビジョン受
像機側では、計時手段によって時刻を取得し、取得した
時刻に基づいて、自動的に電源のオン／オフを行った
り、あるいは、自動的にチャンネルの切り替えを行った
りすることができる。そして、記録媒体に出力するよう
にすれば、別のテレビジョン受像機も、その記録媒体を
差し込むことによって同様に動作させることができる。
例えばユーザは自己の情報を記録媒体に記録して持参す
れば、旅行先のテレビジョン受像機を自分の生活パター
ンに合わせて自動的に動作させるといったこともでき
る。

【００３５】さらにまた、情報処理装置は、制御情報を
読み込んで複数の対象機器を制御する制御装置であって
もよい（請求項３０）。この制御装置は、例えば車室内
などにおける対象機器としてのナビゲーション機器、オ
ーディオ機器、検索機器、通信機器などを総合的に制御
するものであることが考えられる。例えば、オーディオ
機器のＣＤ再生アプリケーションが、混雑しているか否
かという周囲状況に依存し、検索機器のレストラン検索
アプリケーションが、時刻に依存するという制御情報が
出力されるとする。このとき制御装置は、例えば、混雑
時にオーディオ機器にてＣＤの自動再生を行い、昼時に
なったらレストラン検索が即座に行えるようにレストラ
ン検索アプリケーションを自動的に起動するという具合
に動作する。

【００３６】また、複数の対象機器を制御情報出力装置
からの制御情報で動作させることを考えると、制御情報
出力装置は、複数の対象機器を操作するリモートコント
ロール端末（以下「リモコン」という。）であり、情報
処理装置は、リモコンから送信される制御情報を読み込
んで動作する対象機器であることが考えられる（請求項
３１）。

【００３７】なお、請求項２８に示したようなデータベ
ース検索を行うシステムを考える場合、プログラムだけ
でなく映像データなどのコンテンツを含めて「アプリケ
ーション」として捉え、依存情報に基づくアプリケーシ
ョン検索を行うことが考えられる。

【００３８】すなわち、請求項３２に示すように、依存
情報に基づく制御情報を出力する制御情報出力装置と、
出力された制御情報に基づきアプリケーションを検索す
るサーバ装置とを備える情報システムの発明として実現
してもよい。例えば映像データなどのアプリケーション
検索を行おうとすると、内容記述データであるメタデー
タを用いることが考えられるが、メタデータのデータサ
イズが１Ｋバイトを超えてしまう場合も存在する。した
がって、検索対象が数百万件を超えるオーダーになる場
合は、Ｇバイトオーダーのメタデータ通信が必要にな
る。さらに、ユーザ自信も数百万人を超えるとなると、
通信インフラやデータベースサイトの通信トラフィック
量から、現状の最高性能の計算機を持ってしてもリアル
タイム処理が困難な状況が発生する。

【００３９】これに対して、依存情報に基づくアプリケ
ーション（コンテンツ）検索を行えば、依存性という概
念によってアプリケーションやユーザ要求などを総括的
にまた簡単に表現でき、しかも、データ量が抑えられる
ため、高速検索が可能になり、膨大な数のコンテンツが
複数のデータベースサイトにわたって分散して存在する
状況下においても、効率的な検索が可能になる。

【００４０】なお、この情報システムにおける制御情報
出力装置を、請求項２〜２２のいずれかに示した制御情
報出力装置と同様に構成できることは言うまでもない。
また、このような検索処理の効率化を図るために、制御
情報出力装置やサーバ装置は、依存性要因のとり得る依
存性要因値を量子化できる構成としてもよい（請求項３
３）。ここでいう量子化は、例えば連続的な依存性要因
値としての時間情報を「朝」、「昼」、「夜」や、
「春」、「夏」、「秋」、「冬」という依存性を表すの
に有効な時間情報として捉えるための処理をいう。この
量子化に係る情報は、例えば量子化テーブルとして用意
しておくことが考えられる。

【００４１】ところで、アプリケーション検索は具体的
には次のようにして行うことが考えられる。例えば、予
め定められた依存性要因にアプリケーションが依存する
か否かを示すアプリ依存情報をサーバ装置が記憶してお
り、このアプリ依存情報に基づいて検索するという具合
である（請求項３４）。ここで特に、ユーザ要求として
の依存ベクトルが制御情報出力装置から出力される前提
の下、アプリ依存情報に含まれる特性ベクトルとの内積
演算によって検索を行うことが考えられる（請求項３
５）。このようなベクトルの内積演算によって検索を行
えば、検索処理に要する時間のさらなる短縮が実現でき
る。

【００４２】なお、特性ベクトルは、アプリケーション
の詳細データから自動生成できる構成にするとよい（請
求項３６）。アプリケーションの詳細データとは、例え
ばアプリケーションが映像データといったコンテンツで
ある場合、そのコンテンツに含まれるメタデータである
ことが考えられる。そして、このように生成された特性
ベクトルは、テーブル形式などで記憶しておくことが望
ましい（請求項３７）。一度生成した特性ベクトルを記
憶するようにすれば、次の検索時にその特性ベクトルを
再利用できるからである。

【００４３】また、依存ベクトルや特性ベクトルは、依
存の度合いである依存度も表現可能にするとよい（請求
項３８）。このようにすれば、依存するか否かだけでな
く、依存のレベルが判断できるため、より詳細な検索が
可能になる。このようなベクトルを用いてより詳細な検
索を行うためには、依存ベクトル及び特性ベクトルの成
分が、依存性要因のとり得る依存性要因値に対する依存
具合を表現するようにしてもよい（請求項３９）。例え
ば図１５に示すように、依存性要因である時間Ｔｓに対
する要求度の高まりを「０」又は「１」で表現する。そ
して、図中で１２月〜翌年１１月までの要求度の変化を
示す「１０１０」を２進表現と考えてベクトルの成分と
すれば、依存性要因に依存するか否かだけでなく、その
依存具合を表現することができる。もちろん、要求度
（図中の縦軸）についても多値表現すれば、より高度な
検索が可能になる。

【００４４】ただし、検索処理時間の短縮という観点か
らは、依存ベクトル及び特性ベクトルを、その成分が
「０」又は「１」の２値で表現される依存性符号として
実現することが望ましい（請求項４０）。そしてさらに
検索効率を向上させるために、上述した内積演算におい
て、検索に係る依存性要因の中の所定要因に対する成分
のみの演算を行うことが考えられる（請求項４１）。こ
れに加え又は代え、検索に係る依存性要因に対する成分
に優先順位を付けて計算し、各成分毎に予め定められた
基準を満たさない場合、演算を途中で停止するようにし
てもよい（請求項４２）。予め定められた基準を満たす
か否かは、各成分の演算終了時に、アプリケーションの
詳細データを考慮して判断するという具合である。これ
らの構成を採用すれば、内積演算に要する時間を短縮す
ることができ、その結果、コンテンツ数が膨大になる場
合には特に、検索効率を向上させることができる。

【００４５】以上のように、依存性を用いた検索を行え
ば、高速検索に寄与できる。そして、アプリケーション
（コンテンツ）の相互運用性を向上できる。つまり、別
のジャンルに分類されたアプリケーションをも容易に検
索することができる。例えば、カラオケ映像に類した映
像を取得したいとのユーザ要求に対し、例えば広告・宣
伝映像などがその検索条件にマッチして取得されるとい
う具合である。また、アプリケーションの特性が明確に
記述されていなくても、検索対象を絞り込める。さら
に、アプリケーションの特性を一意的な代表値に自動的
に置きかえることが困難な場合にも有効である。例えば
ある映像データが様々な時間帯や場所にわたるシーンで
構成されている場合など、時間と場所とを自動的に代表
値で記述することは難しいためである。

【００４６】そして、このようにして絞り込まれたアプ
リケーションに対して、アプリケーションの詳細データ
に基づく２次検索を行うことが考えられる（請求項４
３）。このように依存情報による１次検索で絞り込んだ
アプリケーションに対して２次検索を行えば、より適切
な検索結果が得られると共に、検索処理全体の効率を向
上させることができる。

【００４７】なお、上述した発明は、アプリケーション
を依存情報を用い表現することによって、アプリケーシ
ョンの検索を効率化するものである。このように、依存
性という概念でアプリケーションを捉えれば、種々のア
プリケーションを普遍的に表すことができる。

【００４８】すなわち、請求項４４に示すように、ユー
ザ側のアプリケーションをユーザ側依存情報によって表
現し、サーバ側のアプリケーションをサーバ側依存情報
で表現することが考えられる。この場合、サーバ装置
は、ユーザ側とサーバ側のアプリケーションとを関連付
けて動作する。

【００４９】アプリケーションは時代とともに変化し、
国や文化によっても異なる。一方、相互運用性のあるデ
ータベースは継続して使用され得る。したがってアプリ
ケーション名でコンテンツを分類することは特定サービ
スを想定して作ったコンテンツ以外では困難である。し
かしながら、たとえば芸能界アイドル、渋滞情報、ニュ
ース、観光情報などを考える場合、それらを扱うアプリ
ケーションやコンテンツに対するユーザの視点は変わり
うるが、基本的な評価属性としては一定かつ普遍的なも
のが存在すると考えられる。

【００５０】そこで、上述したように、ユーザ側及びサ
ーバ側依存情報を、例えば普遍的な依存性要因で表現す
れば、普遍的なアプリケーション記述を行うことができ
る。このとき、上述した依存性符号でアプリケーション
を表現してもよい（請求項４５）。また、次々にアップ
ロードされる映像データであるアプリケーションに対応
させてサーバ側依存情報を記憶するために、アプリケー
ションを特定する言語表現と前記サーバ側依存情報との
対応関係テーブルを用意し、入力情報に従い、サーバ側
依存情報を自動的に付加するようにしてもよい。

【００５１】

【発明の実施の形態】以下、本発明を具体化した実施例
を図面を参照して説明する。 ［第１実施例］図１は、第１実施例の制御情報出力装置
１の構成を示すブロック図である。

【００５２】制御情報出力装置１は、制御部１０と、こ
の制御部１０に接続された入力部２０、状況取得部３
０、出力部４０、メモリ部５０及び表示部６０を備えて
いる。制御部１０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ
などを備えたいわゆるコンピュータシステムである。

【００５３】入力部２０は、ユーザからの指示情報を入
力するための構成であり、キーボードやマウス等のポイ
ンティングデバイスで構成されている。状況取得部３０
は、時々刻々変化する状況をデータとして取得するため
の構成である。具体的には、外部装置から送信される様
々な状況情報を取得する通信デバイスとして構成した
り、様々な状況情報を取得する複数のセンシングデバイ
スで構成したり、あるいは、その両方のデバイスで構成
したりすることが考えられる。

【００５４】出力部４０は、制御部１０にて生成される
制御情報を外部出力する構成である。出力部４０から出
力される制御情報は、対象機器７０の動作・設定に利用
される。したがって、対象機器７０への送信を行うため
の通信デバイスとして構成することが考えられる。ま
た、複数の対象機器７０を制御する制御装置７１への送
信を行う通信デバイスとしてもよい。さらに、最終的に
対象機器７０の動作・設定に制御情報が利用できればよ
いため、所定フォーマットのプロファイルとしてファイ
ル出力する構成としても、また、記録媒体への書き込み
を行う構成としてもよい。

【００５５】メモリ部５０は、情報記憶のための構成で
あり、例えばハードディスク装置として実現することが
考えられる。また、半導体メモリ装置として実現しても
よい。このメモリ部５０には、「依存情報」としての依
存性テーブル５０ａ、「依存特性」としての依存特性情
報５０ｂ及び「従属関係」としての従属性テーブル５０
ｃが記憶されている。

【００５６】表示部６０は液晶やＣＲＴを用いたディス
プレイ装置であり、この表示部６０によってユーザに対
する情報表示がなされる。このような構成の下、制御部
１０は、入力部２０及び状況取得部３０から入力される
情報に基づき、メモリ部５０に記憶された依存性テーブ
ル５０ａ・依存特性情報５０ｂ・従属性テーブル５０ｃ
を参照し、対象機器７０の動作・設定に利用される制御
情報を生成し出力部４０を介して出力する。

【００５７】この制御部１０を機能ブロックで示したの
が、図２である。制御部１０にて生成される制御情報
は、アプリケーション情報と依存性情報とからなってい
る。アプリケーション情報は、実行要求が高いアプリケ
ーションプログラムを示すアプリケーションリストであ
る。一方、依存性情報は、依存ベクトル、依存特性、及
び依存性要因リストからなる。

【００５８】アプリケーションリストとして具現化され
るアプリケーション情報は、少なくとも状況情報、依存
性テーブル５０ａ、依存特性情報５０ｂ及び従属性テー
ブル５０ｃに基づいて、アプリケーション情報生成ブロ
ック１１にて作成される。少なくともとしたのは、対象
機器７０に実行させるアプリケーションプログラムを入
力部２０を介してユーザが選択指示できるようになって
おり、アプリケーションプログラムの選択指示があった
場合は、このアプリケーション選択指示も考慮してアプ
リケーション情報が作成されるためである。一方、依存
性情報は、状況情報、依存性テーブル５０ａ及び依存特
性情報５０ｂに基づいて、依存性情報生成ブロック１２
にて生成される。

【００５９】アプリケーション情報生成ブロック１１、
依存性情報生成ブロック１２にてそれぞれ生成されたア
プリケーション情報及び依存性情報は、制御情報生成ブ
ロック１３へ出力されて制御情報としてまとめられ、そ
の後、符号化ブロック１４へ出力される。符号化ブロッ
ク１４では、制御情報の符号化を行う。そして、符号化
された制御情報が、記録媒体、プロファイル、対象機器
７０あるいは複数の対象機器７０を制御する制御装置７
１などへ出力される。

【００６０】本第１実施例の制御情報出力装置１は、こ
のような制御情報の生成に特徴を有するものである。そ
こで次に制御情報生成について詳細に説明する。まず最
初に、制御情報生成にあたって参照される依存性テーブ
ル５０ａ、依存特性情報５０ｂ及び従属性テーブル５０
ｃについて説明し、さらに続けて制御情報としてのアプ
リケーションリスト、依存性要因リスト、依存ベクトル
について説明する。そしてその後に、制御情報生成動作
の説明を行う。

【００６１】（１）依存性テーブル 依存性テーブル５０ａは、対象機器７０にて実行される
各種アプリケーションプログラムに対するユーザ要求
が、どのような要因（以下「依存性要因」という。）に
依存するか、という依存関係を示すテーブルである。依
存性テーブル５０ａの一例を、図３に示した。図３に示
した２次元の依存性テーブル５０ａは、ビデオメディア
に関連するアプリケーションプログラムに係るものであ
る。

【００６２】（１−１）アプリケーションプログラムの
記述 図３中の最も左側の欄に示されるのが、対象機器７０に
て実行されるアプリケーションプログラムである。「オ
フィス応用」アプリケーションは、文書作成、表計算な
どを実現するものである。「医療記録」アプリケーショ
ンは、映像を利用して歩行具合などの医療記録を行うも
のである。「ビデオ編集」アプリケーションは、ビデオ
映像の途中をカットしたり、映像の順番を入れ替えたり
するものである。また、「テレビ電話」アプリケーショ
ンは、いわゆるテレビ電話に搭載されるものであり、通
話音声と共に通話者の映像をやり取りするためのもので
ある。「家庭用ＡＶ」アプリケーションは、ビデオレコ
ーダなど映像関連情報を取り扱う家庭用電気器具に搭載
されたものである。「電子化カタログ」アプリケーショ
ンは、いわゆるカタログショッピングを可能にするもの
であり、映像を用いて商品の案内・販売を行うものであ
る。

【００６３】図３中のハッチング部分以降のアプリケー
ションプログラムは、映像メディアに関連するアプリケ
ーションプログラムの中でも特に、ナビゲーション装置
や携帯情報端末に搭載されるアプリケーションプログラ
ムである。「ルートガイダンス」アプリケーションは、
目的地を設定すると、当該目的地までの案内経路を設定
してルート案内を行うものである。また、「施設案内」
アプリケーションは、施設検索を行うアプリケーション
プログラムであり、さらに、「天気情報」、「交通情
報」、「カラオケ」、「スポーツ情報」、「ゴルフ情
報」、「スキー情報」、「レストラン情報」、「ショッ
ピング情報」、「旅行情報」、「景観情報」、「ニュー
ス情報」、「音楽情報」、「緊急情報」のアプリケーシ
ョンは、それぞれの情報を取得し、映像を利用してユー
ザに提示するものである。

【００６４】（１−２）依存性要因の記述 依存性テーブル５０ａに記述される依存性要因は、大き
く３つに分類できる。ユーザ要因、システム要因及びメ
ディア要因である。 （１−２−１）ユーザ要因 ユーザ要因とは、ユーザに関連する要因であり、ユーザ
の置かれた環境・状況やユーザの要求・状態などに関連
するものである。例えば環境・状況には、時刻、場所、
仕事内容、雑音の有無といった周囲条件などが挙げられ
る。また例えば要求・状態には、「食べたい」、「休憩
したい」といった生活ニーズ、趣味などが挙げられる。
その他ユーザに関連する要因としては、ユーザの嗜好性
などが考えられる。

【００６５】このユーザ要因には、特開平１２−２００
９０号公報や特開平１１−３５１９０１号公報などに開
示される、本出願人の提示したプロファイルシステムに
おける「ユーザの環境・状況・要求・状態」の項目が含
まれる。これら公報に開示される項目は特に自動車内に
おける要因を示しているが、本明細書中でいうユーザ要
因は車内の要因に限定されるものではない。

【００６６】（１−２−２）システム要因 システム要因とは、制御情報によって制御されるシステ
ムに関連する要因であり、例えば次のようなものが含ま
れる。メモリ容量、並行して実行可能なアプリケーショ
ンプログラムの数、処理能力、動作環境をはじめ、通信
を行うことを前提とし、通信条件、通信コスト、またデ
ィスプレイなどの表示機器を備えることを前提とし、画
面サイズといった表示デバイス条件などを挙げることが
できる。

【００６７】（１−２−３）メディア要因 メディア要因とは、アプリケーションプログラムの処理
対象となるメディアに関する要因である。これには、Ｄ
ＶＤ，ＣＤ−ＲＯＭといったメディアのタイプ、メディ
アに格納されるコンテンツに関する情報、例えばジャン
ル、製作者、日時、場所などが含まれる。

【００６８】図３に示す依存性テーブル５０ａには、ユ
ーザ要因及びメディア要因に属する諸項目を例示した。
ユーザの環境・状況の要因には、「時刻」、「場所」、
「仕事」、「周囲条件」、「周囲の人々」の項目が示さ
れている。「周囲条件」とは、周囲が騒がしいか否か、
混雑しているか否かなどの条件をいう。また、「周囲の
人々」は、子供であったり、大人であったり、また、家
族であったり、友人であったりという区別をいう。

【００６９】ユーザの要求・状態の要因には、「生活ニ
ーズ」、「フィーリング」、「面白さ」という項目が示
されている。「生活ニーズ」は、上述したように「食べ
たい」、「休みたい」というユーザの要求に近いもので
あり、これに対して「フィーリング」、「面白さ」は、
ユーザの状態に近いものである。例えば「疲れた」、
「気分最高」といったユーザ状態がフィーリングとさ
れ、「面白さ」は、ユーザの趣味などの情報とすること
が考えられる。また、「嗜好性」の項目は、好きな番組
であったり、好きな俳優であったりする。

【００７０】メディア要因として、図３には、コンテン
ツに関連する項目を例示した。「時間」、「場所」、
「行為者」、「製作者」、「ジャンル」の項目である。
「時間」はコンテンツの再生時間等である。「場所」
は、撮影場所のことである。「行為者」は、俳優であっ
たり、医療記録などでは患者であったりする。

【００７１】そして、このような依存性要因は、図１中
に示した状況取得部３０にて取得されるデータに基づい
て確定される。依存性要因がとり得る値を、以下「依存
性要因値」という。例えば、ユーザ要因の「時刻」は、
時計からの信号出力に基づき、取得することが考えられ
る。例えば、午前０時から午後１２時までの時刻として
取得されるという具合である。また、ユーザ要因の「場
所」は、レストラン、公園、スポーツ施設、会社、自
宅、車内といった依存性要因値をとることが考えられ
る。このような依存性要因値は、例えばＧＰＳ受信機に
より取得される位置情報と地図データとのマッチングで
確定することができる。さらに、ユーザ固有の情報につ
いては、例えばプロファイルという形式で管理するよう
にしておき、このプロファイルを参照して確定すること
が可能である。このプロファイルは、制御情報出力装置
１の内部に記憶する構成であってもよい。また、外部の
別の装置に記憶しておき、この装置から状況取得部３０
を介して取得するようにしてもよい。

【００７２】また例えば、図３に示すメディア要因に関
しては、アプリケーションプログラムの処理対象となる
メディアのヘッダー情報として記録しておくことが考え
られる。従来より、音楽ＣＤなどには、各曲の再生時間
などが記録されている。したがって、映像メディアに所
定のフォーマットで「時間」、「場所」、「行為者」、
「製作者」、「ジャンル」を記録しておくことが考えら
れる。そして、対象機器７０側からこれらの情報を状況
取得部３０を介して取得する。なお、このようなメディ
ア要因も、プロファイルという形式で予め記録しておく
ようにし、プロファイルから読み出して使用するように
してもよい。

【００７３】（１−３）依存性の記述 そして、依存性テーブル５０ａには、各アプリケーショ
ンプログラムが、上述した依存性要因のいずれに依存す
るかが記述されている。図３で言えば、「Ｄ」という記
述が「依存」することを示している。例えば「オフィス
応用」アプリケーションは、ユーザ要因の「場所」、
「仕事」、メディア要因の「時間」、「場所」、「行為
者」、「製作者」、「ジャンル」に依存することが、図
３より分かる。

【００７４】（２）依存特性 依存性テーブル５０ａに示される各アプリケーションプ
ログラムがいずれの依存性要因に依存するかという情報
は、依存特性情報５０ｂに基づき決定されたものであ
る。

【００７５】依存特性情報５０ｂは、依存性要因のとり
得る依存性要因値と、アプリケーションプログラムへの
ユーザの統計的な要求度（以下「要求度」という。）と
の対応関係を示す情報である。依存性要因値は、ユーザ
要因の「時刻」であれば、午前０時から午後１２時まで
の時刻というような連続的な値として、一方、「場所」
であれば、レストラン、公園、スポーツ施設、会社、自
宅、車内といった離散的な値として確定されることは既
に述べた。

【００７６】例えば連続的な依存性要因値と要求度との
対応関係を、図４に示した。ここでは、横軸に依存性要
因値Ｘをとり、縦軸にアプリケーションプログラムへの
要求度Ｒを示した。ここで、依存性要因値Ｘに対し、要
求度Ｒが相対的に大きく変動する場合に、アプリケーシ
ョンプログラムがその依存性要因に依存すると定義す
る。

【００７７】具体的に本第１実施例では、次に示す〜
の３つの条件を満たす場合を、要求度Ｒが相対的に大
きく変動する場合とする。 要求度Ｒの依存性要因値Ｘに対する最大変動幅が第１
の閾値ＤＲｔｈを上回っていること 要求度の最大値Ｒｍａｘが第２の閾値Ｒｔｈを上回っ
ていること 依存特性の曲線が時間に対して一定であること、ある
いは、規則性が見られること 例えば図４には、２つの依存特性を示した。実線で示し
た記号Ａの依存特性（以下「依存特性Ａ」と記述す
る。）と、一点鎖線で示した記号Ｂの依存特性（以下
「依存特性Ｂ」と記述する。）である。

【００７８】依存特性Ａは、依存性要因値Ｘに対する要
求度Ｒの最大変動幅がα−βとなっており、要求度Ｒの
最大値Ｒｍａｘがαとなっている。したがって、図４か
ら分かるように、α−β＞ＤＲｔｈで、かつ、α＞Ｒｔ
ｈである。したがって依存特性Ａが時間に対して一定又
は規則性を有するならば、依存特性Ａを有するアプリケ
ーションプログラムは、その依存性要因に依存するとさ
れる。

【００７９】一方、依存特性Ｂは、依存性要因値Ｘに対
する要求度Ｒの最大変動幅がγ−δとなっており、要求
度Ｒの最大値Ｒｍａｘがγとなっている。したがって、
図４から分かるように、γ−δ＜ＤＲｔｈ，γ＜Ｒｔｈ
である。そのため、依存特性Ｂを有するアプリケーショ
ンプログラムは、依存性要因に依存しないとされる。

【００８０】なお、上記の条件を設定するのは、例え
ば１日の中の時刻Ｘに対して要求度Ｒが大きく変動する
アプリケーションプログラムであっても、要求度Ｒの変
動が日々異なる場合には、時刻Ｘに対する依存性がある
とは言えないからである。また、依存性要因値が離散的
な値となる場合は、例えばテーブル形式で依存性要因値
と要求度とを対応させることが考えられる。この場合
も、上述したのと同様の方法で依存するか否かを定義で
きる。

【００８１】このような依存特性情報５０ｂは、図３に
示した各依存性要因と各アプリケーションプログラムと
を関係付けるものであり、依存性テーブル５０ａの各升
目にそれぞれ対応付けられるものである。このような依
存特性情報５０ｂが決定されれば、上述した依存性の定
義を用いて、依存特性情報５０ｂから依存性テーブル５
０ａが確定できる。そのため、このような依存特性情報
５０ｂは、ユーザ要求を予め統計処理して記憶しておく
ことが考えられる。ただし、入力部２０を介してユーザ
からアプリケーションプログラムの選択指示を入力でき
る構成であるため、このアプリケーションプログラムの
選択指示に基づいて学習変更するようにしてもよい。ま
た、依存特性情報５０ｂの学習変更に伴い、依存性の定
義を用い、依存性テーブル５０ａをも学習変更する構成
とすることが望ましい。

【００８２】（３）従属性テーブル 従属性テーブル５０ｃは、アプリケーションプログラム
間の従属関係を示すものである。あるアプリケーション
プログラムへのユーザ要求は、別のアプリケーションプ
ログラムに関連して大きくなることがある。例えば文書
作成アプリケーションと共に表計算アプリケーションが
使用される可能性が高いという具合である。したがっ
て、表計算アプリケーションが文書作成アプリケーショ
ンに従属するというような従属関係を従属性テーブル５
０ｃとして記憶しておく。

【００８３】さらに続けて制御情報としてのアプリケー
ションリスト、依存性要因リスト及び依存ベクトルにつ
いて説明する。 （４）アプリケーションリスト アプリケーションリストは、実行要求の度合いに応じて
階層化されたアプリケーションプログラムの一覧であ
る。本第１実施例では以下〜に示す４つのレベルに
階層化したアプリケーションリストを生成する。

【００８４】完全アプリケーションリスト（以下「Ｆ
−ＡＬＳＴ」という。） 登録されているすべてのアプリケーションプログラムの
リストであり、制御情報出力装置１と対象機器７０側と
でアプリケーションプログラムを対照させるためのリス
トである。

【００８５】ユーザアプリケーションリスト（以下
「Ｕ−ＡＬＳＴ」という。） ユーザが要求する可能性のあるアプリケーションプログ
ラムのリストであり、Ｆ−ＡＬＳＴのサブセットにな
る。 要求アプリケーションリスト（以下「Ｒ−ＡＬＳＴ」
という。） ユーザが要求すると推定されるアプリケーションプログ
ラムのリストであり、Ｕ−ＡＬＳＴのサブセットにな
る。

【００８６】実行アプリケーションリスト（以下「Ｅ
−ＡＬＳＴ」という。） 実行が確定したアプリケーションプログラムのリストで
あり、Ｒ−ＡＬＳＴのサブセットになる。 （５）依存性要因リスト 依存性要因リストは、依存性要因を有効度合いに応じて
階層化した依存性要因の一覧である。本第１実施例で
は、以下〜に示す４つのレベルに階層化された依存
性要因リストを生成する。

【００８７】完全依存性要因リスト（以下「Ｆ−ＤＬ
ＳＴ」という。） 登録されているすべての依存性要因のリストであり、制
御情報出力装置１と対象機器７０側とで依存性要因を対
照させるためのリストである。 ユーザ依存性要因リスト（以下「Ｕ−ＤＬＳＴ」とい
う。） ユーザの要求を判定する上で必要な依存性要因のリスト
であり、依存性要因値が確定される可能性のある依存性
要因のリストである。これは、Ｆ−ＤＬＳＴのサブセッ
トになる。

【００８８】アクティブ依存性要因リスト（以下「Ａ
−ＤＬＳＴ」という。） 依存性要因値の確定した依存性要因のリストであり、Ｕ
−ＤＬＳＴのサブセットになる。 最重要依存性要因リスト（以下「Ｐ−ＤＬＳＴ」とい
う。） 実行が確定したアプリケーションプログラムに関する依
存性要因を示すリストであり、最重要のリストである。
これは、Ａ−ＤＬＳＴのサブセットになる。

【００８９】（６）依存ベクトル 依存ベクトルとは、依存性テーブル５０ａを行単位で取
り出したものであり、これも「依存情報」に相当する。
依存ベクトルは、あるアプリケーションプログラムが、
いずれの依存性要因に依存しているかを示すものであ
る。例えば図３に示す依存性テーブル５０ａにおいて、
「オフィス応用」アプリケーションの依存ベクトルは、
依存を示す記号Ｄを論理値「１」で置き換え、依存しな
いことを示す空白欄を論理値「０」で置き換えて、依存
ベクトルＤＰ＝（０，１，１，０，０，０，０，０，
０，１，１，１，１，１）と表すことができる。したが
って、依存ベクトルと上述したＦ−ＤＬＳＴを対照させ
れば、あるアプリケーションプログラムがどの依存性要
因に依存しているかを判断することができる。

【００９０】次に制御情報生成動作の説明を行う。ここ
では、制御部１０にて実行される制御情報出力処理を、
図５に示すフローチャートに基づいて説明する。この制
御情報出力処理は、入力部２０を介した制御情報の出力
指示があると実行される。なお、ここでは、依存性テー
ブル５０ａを模式的に示す図６及び図７を適宜参照して
説明する。

【００９１】まず最初のステップ（以下、ステップを単
に記号Ｓで示す。）１００において、依存性要因値を取
得する。これは、上述したような各種依存性要因の値を
確定する処理である。具体的には、状況取得部３０にて
取得されるデータに基づき、依存性要因値を取得する。

【００９２】続くＳ１１０では、依存性要因の有効度合
いを判断し、依存性要因値の確定を判断する。このよう
に依存性要因の有効度合いを判断するのは、周囲条件な
どによって依存性要因値の信頼度が低くなり、依存性要
因が不適切なものとなる可能性があるためである。例え
ば、依存性要因値が所定範囲内の値となっていない場合
に、依存性要因値が確定していないものとする。

【００９３】次のＳ１２０では、アプリケーションプロ
グラムの選択指示がユーザからあったか否かを判断す
る。本第１実施例の制御情報出力装置１では、表示部６
０を介して対象機器７０で実行可能なアプリケーション
プログラムをメニュー表示する。ユーザは、このメニュ
ーからアプリケーションプログラムの選択指示を行うこ
とができる。ここでアプリケーションプログラムの選択
指示があったと判断された場合（Ｓ１２０：ＹＥＳ）、
Ｓ１３０へ移行する。一方、アプリケーションプログラ
ムの選択指示がなかったと判断された場合（Ｓ１２０：
ＮＯ）、Ｓ１７０へ移行する。

【００９４】アプリケーションプログラムの選択指示が
あった場合に移行するＳ１３０では、アプリケーション
プログラムを選択する。この処理は、ユーザによる選択
指示がなされたアプリケーションプログラムを選択し、
このアプリケーションプログラムの実行確信度を「１」
にセットするものである。実行確信度は、正規化された
情報であり、「１」に近いほどユーザによる実行要求が
高いことを示す。

【００９５】例えば図６に示すように、アプリケーショ
ンＡｌがユーザから指示された場合、このアプリＡｌの
実行確信度を「１」にする。次のＳ１４０では、Ｓ１３
０にて選択したアプリケーションプログラムが依存する
依存性要因の中で依存性要因値が確定しており、さら
に、その依存性要因値から算出した要求度が所定値より
も大きくなる依存性要因を、依存性テーブル５０ａ及び
依存特性情報５０ｂに基づき探索する。

【００９６】例えば図６では、依存性テーブル５０ａの
アプリＡｌの行を順に探索し（探索方向を矢印Ａで示し
た）、依存を示す「Ｄ」が記述された依存性要因Ｘｉ，
Ｘｊ，Ｘｋの中で、依存性要因値の確定した依存性要因
Ｘｉ，Ｘｊを探索する。そしてさらに、依存特性情報５
０ｂに基づき、依存性要因Ｘｉ，Ｘｊに対する要求度Ｒ
ｌｉ，Ｒｌｊを算出し、それぞれの所定値Ｒ１ｔｈ，Ｒ
２ｔｈと比較する。要求度Ｒｌｉ＞Ｒ１ｔｈならば、依
存性要因Ｘｉを有効なものとして選択する。同様に要求
度Ｒｌｊ＞Ｒ２ｔｈならば、依存性要因Ｘｊを有効なも
のとして選択する。なお、ここで依存性要因Ｘｉ，Ｘｊ
が有効なものとして選択されたとして、以下の説明を続
ける。

【００９７】続くＳ１５０では、関連アプリを選択す
る。この処理は、確定しており有効であると判断された
依存性要因に依存するアプリケーションプログラムを、
依存性テーブル５０ａに基づき、選択するものである。
例えば図６で言えば、選択された依存性要因Ｘｉ，Ｘｊ
に依存している関連アプリＡｍ，Ａｎを選択することに
なる。詳しくは、依存性要因Ｘｉの列を矢印Ｂ方向に探
索し、依存を示す「Ｄ」が記述された行のアプリケーシ
ョンＡｎを関連アプリとして選択する（矢印Ｅ参照）。
同様に、依存性要因Ｘｊの列を矢印Ｃ方向に探索し、依
存を示す「Ｄ」が記述された行のアプリケーションＡｍ
を関連アプリとして選択する（矢印Ｄ参照）。

【００９８】そして次のＳ１６０では、要求度を算出す
る。この処理は、確定しており有効であると判断された
依存性要因について、関連アプリへの要求度を算出する
ものである。例えば図６では、関連アプリＡｍへの依存
性要因Ｘｊに対する要求度Ｒｍｊと、関連アプリＡｎへ
の依存性要因Ｘｉに対する要求度Ｒｎｉを算出すること
になる。

【００９９】そしてＳ１６０の処理終了後、Ｓ２００へ
移行する。一方、アプリケーションプログラムの選択指
示がなかった場合に移行するＳ１７０では、確定要因を
探索する。この処理は、Ｓ１１０にて依存性要因値の確
定した依存性要因を依存性テーブル５０ａの中でマーキ
ングするものである。そして、ここで探索した依存性要
因を、上述した依存性要因リストの中のＡ−ＤＬＳＴに
加える。

【０１００】例えば図７では、２つの依存性要因Ｘｉ，
Ｘｊが確定しているため、これらがマーキングされてＡ
−ＤＬＳＴに加えられる。続くＳ１８０では、要求度を
算出する。この処理は、確定した依存性要因、すなわち
Ａ−ＤＬＳＴに入っている依存性要因に対する要求度
を、依存特性情報５０ｂを用いて算出するものである。

【０１０１】図７で言えば、依存性要因Ｘｉ，Ｘｊに対
するアプリケーションプログラムへの要求度Ｒｌｉ，Ｒ
ｌｊ，Ｒｍｊ，Ｒｎｉを算出する。詳しくは、依存性要
因Ｘｉの列を矢印Ｇ方向に探索し、依存を示す「Ｄ」が
記述された行のアプリケーションＡｌ，Ａｎに対する要
求度Ｒｌｉ，Ｒｎｉを算出する。同様に、依存性要因Ｘ
ｊの列を矢印Ｈ方向に探索し、依存を示す「Ｄ」が記述
されたアプリケーションＡｌ，Ａｍに対する要求度Ｒｌ
ｊ，Ｒｍｊを算出する。

【０１０２】次のＳ１９０では、関連アプリを選択す
る。この選択は、Ｓ１８０にて算出された要求度に応じ
て行われる。具体的には、各要求度が、対応する所定値
よりも大きいか否かで判断する。要求度が所定値を上回
るアプリケーションプログラムは、上述したアプリケー
ションリストのＲ−ＡＬＳＴに加えられる。一方、要求
度が所定値以下であれば、Ｒ−ＡＬＳＴは変更しない。

【０１０３】図７で言えば、要求度Ｒｌｉ＞Ｒ１ｔｈ、
又は、要求度Ｒｌｊ＞Ｒ２ｔｈのとき、アプリケーショ
ンＡｌが関連アプリとして選択される（矢印Ｉ参照）。
また、要求度Ｒｍｊ＞Ｒ３ｔｈのとき、アプリケーショ
ンＡｍが関連アプリとして選択される（矢印Ｊ参照）。
同様に、要求度Ｒｎｉ＞Ｒ４ｔｈのとき、アプリケーシ
ョンＡｎが関連アプリとして選択される（矢印Ｋ参
照）。なお、関連アプリとしてＡｌ，Ａｍ，Ａｎが選択
されたものとして、以下の説明を続ける。

【０１０４】そしてＳ１９０の処理終了後、Ｓ２００へ
移行する。Ｓ２００では、実行確信度を算出する。これ
はＳ１６０又はＳ１８０で算出した要求度に基づき算出
する。例えば複数の依存性要因に対して算出された要求
度を平均したものを実行確信度とすることが考えられ
る。具体的に示すと、例えば依存性テーブル５０ａのあ
るアプリケーションプログラムＡｐについての実行確信
度Ｃｐは、依存性要因Ｘｑ（ｑ＝１，２，３，・・・，
Ｑ）に対する要求度をＲｐｑで示し、依存性要因Ｘｑに
アプリケーションＡｐが依存する場合をｄｐｑ＝１と
し、一方、依存しない場合をｄｐｑ＝０とすれば、次の
式１で示される。 Ｃｐ ＝ （１／ＳＲ）Σ（Ｒｐｑ・ｄｐｑ） …式１ ここでＳＲ＝Σｄｐｑであり、Σは、ｑ＝１〜Ｑまでの
和記号である。なお、要求度Ｒｐｑは正規化されている
ものとする。

【０１０５】次のＳ２１０では、実行確信度を補正す
る。この処理は、上述した従属性テーブル５０ｃを用
い、実行確信度を補正するものである。アプリケーショ
ンプログラムが選択指示されている場合は（図６参
照）、実行確信度が「１」となっている選択指示された
アプリＡｌへの従属関係を用い、アプリケーションプロ
グラムが選択指示されていない場合は（図７参照）、Ｒ
−ＡＬＳＴに属するアプリケーションプログラムの中で
最も実行確信度の大きなアプリケーションプログラムへ
の従属関係を用いる。例えば図７において関連アプリＡ
ｌの実行確信度が最も大きくなっている場合は、関連ア
プリＡｌへの従属関係を用いて実行確信度を補正する。

【０１０６】続くＳ２２０では、確定していない依存性
要因値を推定する。これは、実行要求が相対的に高いア
プケーションを基にして、依存性要因値を推定する処理
である。例えば図６では、アプリＡｌ，関連アプリＡ
ｍ，Ａｎの依存性要因Ｘｋに対する要求度Ｒｌｋ，Ｒｍ
ｋ，Ｒｎｋを最初に推定する。これらアプリケーション
Ａｌ，Ａｍ，Ａｎへの確定した依存性要因Ｘｉ，Ｘｊに
対する要求度は相対的に大きくなっているため、Ｒｌ
ｋ，Ｒｍｋ，Ｒｎｋも相対的に大きな値、例えば対応す
る所定値を上回る値として推定できる。したがって、推
定した要求度Ｒｌｋ，Ｒｍｋ，Ｒｎｋを満たす依存性要
因値を推定でき、さらに、それら推定した依存性要因値
を平均して、依存性要因Ｘｋの依存性要因値とすること
が考えられる（矢印Ｆ参照）。なお、単に平均をとって
もよいが、依存度合いを考慮して荷重係数を用いた平均
をとってもよい。また、この荷重係数は、各アプリケー
ションプログラムの実行確信度で代用することができ
る。図７においても同様であり、関連アプリＡｌ，Ａ
ｍ，Ａｎの依存性要因Ｘｋに対する要求度を推定して依
存性要因値を推定する（矢印Ｌ参照）。

【０１０７】この推定処理を具体的に示すと、次のよう
になる。すなわち、実行要求の高いアプリケーションＡ
ｐの依存性要因Ｘｑに対する要求度Ｒｐｑが所定値Ｒｐ
ｑｔｈを上回る（Ｒｐｑ＞Ｒｐｑｔｈ）として、各アプ
リケーションＡｐに対する依存性要因値ＸＥＳＴｐｑを
推定する。そして、次の式２により、依存性要因値ＸＥ
ＳＴｐｑを平均して、依存性要因Ｘｑの依存性要因値Ｘ
ＥＳＴｑを推定する。 ＸＥＳＴｑ ＝ （１／ＳＡ）Σ（ａｐ・ＸＥＳＴｐｑ） …式２ ここで、ＳＡ＝Σａｐであり、ａｐはアプリケーション
Ａｐに対する荷重係数、また記号Σは、ｐ＝１〜ｐｍａ
ｘまでの和記号を示している。荷重係数ａｐは、上述し
たようにアプリケーションＡｐの実行確信度Ｃｐで代用
してもよい。

【０１０８】そして次のＳ２３０では、制御情報を生成
する。すなわち、アプリケーション情報としてのアプリ
ケーションリスト、依存性情報としての依存性要因リス
ト、依存ベクトル、依存特性を生成する。具体的には、
Ｓ２１０で補正された実行確信度に基づき、アプリケー
ションリストを再構成する。すなわち、実行確信度Ｃが
第１の閾値Ｃ１ｔｈよりも大きい場合、その関連アプリ
をＥ−ＡＬＳＴに入れる。一方、実行確信度Ｃが第１の
閾値Ｃ１ｔｈ以下で、かつ、第２の閾値Ｃ２ｔｈよりも
大きい場合、その関連アプリをＲ−ＡＬＳＴに入れる。
実行確信度Ｃが第２の閾値Ｃ２ｔｈ以下であれば、その
関連アプリをＲ−ＡＬＳＴから除外する。

【０１０９】また、依存性要因リストを再構成する。Ｓ
１７０にてＡ−ＤＬＳＴに入れられた依存性要因の中で
Ｅ−ＡＬＳＴに入れられた関連アプリに係る依存性要因
をＰ−ＤＬＳＴに入れる。さらに、Ｒ−ＡＬＳＴ，Ｅ−
ＡＬＳＴに属するアプリケーションプログラムに対する
依存ベクトル及び依存特性をそれぞれ、依存性テーブル
５０ａ及び依存特性情報５０ｂから作成する。

【０１１０】次のＳ２４０では、アプリケーションリス
ト、依存性要因リスト、依存ベクトル及び依存特性を符
号化する。そして、Ｓ２５０にて、符号化した制御情報
を出力する。このＳ２５０の出力処理終了後、本制御情
報出力処理を終了する。ところで、このようにして制御
情報生成出力することによって、制御情報に基づき対象
機器７０がそれに応じた動作を行うように構成すれば、
対象機器７０を総合的に、しかも、半自動的にセットア
ップして動作させることができる。

【０１１１】そこで次に、対象機器７０側で実行される
対象機器側処理について、図８のフローチャートに基づ
き説明する。この対象機器側処理は、対象機器７０にて
実行されることが考えられる。また、複数の対象機器７
０を制御する制御装置７１にて実行されることが考えら
れる。

【０１１２】まず最初のＳ３００において、制御情報の
復号化を行う。本第１実施例では、上述したように制御
情報として、アプリケーションリスト、依存性要因リス
ト、依存ベクトル、依存特性を符号化して出力する。し
たがってここでは、これらの情報を順次復号化してい
く。

【０１１３】続くＳ３１０では、復号化した制御情報を
読み出す。そして次のＳ３２０ではアプリケーションの
設定を行い、その後、本対象機器側処理を終了する。Ｓ
３２０におけるアプリケーションの設定には、アプリケ
ーションプログラムに関する様々な設定処理が含まれ
る。したがってここで、アプリケーション設定について
説明する。

【０１１４】（７）アプリケーション設定 （７−１）アプリケーション情報による設定 アプリケーション情報としてのアプリケーションリスト
に基づき、ユーザ要求に合わせたアプリケーションプロ
グラムの起動・起動準備を行う。

【０１１５】例えば実行の確定したＥ−ＡＬＳＴに属す
るアプリケーションプログラムに関してはスタンバイ状
態にし、ユーザが要求すると推定されるＲ−ＡＬＳＴに
属するアプリケーションプログラムに関してはアクセス
可能状態にする。スタンバイ状態とは、アプケーション
プログラムをメモリ展開して起動しておき、即座に使用
できる状態にすることをいう。また、アクセス可能状態
とは、直ぐに選択起動できるように、メニューに入れた
り、また、メニューの最初に表示したりすることをい
う。

【０１１６】（７−２）依存性情報による設定 依存性要因リスト、依存ベクトルに基づき、アプリケー
ションプログラムがどのような依存性要因に基づいて要
求されているのかを判断する。さらに、依存特性によっ
て個々の依存性要因に対する要求度を判断する。そし
て、ユーザ要求に合わせたカスタマイズを行う。

【０１１７】例えば「施設検索」アプリケーションの実
行確信度が高くなり、実行が確定した場合を考える。こ
のとき、その検索アプリケーションが、「生活ニーズ」
という依存性要因から要求されたのか、あるいは、ユー
ザの「嗜好性」という依存性要因から要求されたのかを
判断する。依存性要因リスト及び依存ベクトルに基づけ
ば、いずれの依存性要因が有効となっているかを判断で
きる。また、両方の依存性要因が有効である場合には、
依存特性を用いて要求度を算出する。これによって、検
索範囲を有効に限定できる。

【０１１８】なお、ユーザ要求に合わせたカスタマイズ
には、上述したような検索条件の設定だけでなく、アプ
リケーションプログラムに関連する様々なものが含まれ
る。例えば、アプリケーションプログラムが実行される
対象機器７０の設定、アプリケーションプログラムの処
理対象となるメディアコンテンツの選択、さらには、ア
プリケーションプログラムで参照されるユーザの属性記
述の最適化などが挙げられる。対象機器７０の設定に
は、画面表示形態などをユーザの好みに合わせて変更す
る設定などが考えられる。また、メディアコンテンツの
選択には、例えば「家庭用ＡＶ」アプリケーションを起
動するとき、ユーザからの指定がなければ、ユーザの好
みのメディアコンテンツを自動的に選択して再生したり
することが一例として挙げられる。さらにまた、従来よ
り、ＸＭＬ（eXtensible Markup Language）文書などに
用いられているようなタグと属性値による項目記述を複
数個組み合わせて、ダイナミックかつ階層的に構成する
ことでユーザやメディア、システムを柔軟に記述するこ
とが提案されている。このような記述に従ってシステム
は様々な知的処理を行うことが可能になる。ユーザ属性
記述の最適化とは、このようなＸＭＬのタグ記述に代表
される階層的属性記述を上述した制御情報を用いて最適
化することを意味する。

【０１１９】つまり、以上のことをまとめると、制御情
報に基づくアプリケーション設定処理によって、対象機
器７０の状況に応じた動作、アプリケーションプログラ
ムに応じた動作が可能になる。 （８）状況に応じた動作 状況に応じた動作の代表例として、以下〜が考えら
れる。

【０１２０】状況に応じて、選択するアプリケーショ
ンプログラムまたは選択できるアプリケーションプログ
ラムセットを変更する。 状況に応じて、アプリケーションプログラムの設定パ
ラメータを変更する。 状況に応じて、プロファイル内の検索属性の構成を動
的に変更する。

【０１２１】ユーザ不在のときもスケジュールに応じ
た準備をする。 ユーザ不在のときもユーザの依存特性に合わせた動作
をする。 （９）アプリケーションプログラムに応じた動作 アプリケーションプログラムに応じた動作の代表例とし
て、以下〜が考えられる。

【０１２２】アプリケーションプログラムに応じて、
対応する入出力デバイスと処理プログラムを選択する。 メディア記述属性の組み合わせを変更する。 問い合わせプロファイルにおける検索属性の組み合わ
せを変更する。

【０１２３】各属性値のデータ形式を必要に応じて変
更する。アプリケーションプログラムに応じた動作を家
庭用電気器具を例に挙げ、テレビジョン受像機やエアコ
ンなどを集中管理する場合で説明する。このとき、上述
したような属性情報の変更によって、テレビが選択され
た場合、リモートコントロール機能を実現する設定を行
い、電子番組ガイド、番組選択、音量調整、ビデオ予
約、画面設定、言語設定の機能をスタンバイさせたり、
エアコンが選択された場合、季節や時間帯、温度に応じ
て動作させたりすることができる。

【０１２４】次に、本第１実施例の制御情報出力装置１
を用いたシステムの構成例について、図９を参照して説
明する。図９（ａ）では、制御情報出力装置１としての
情報端末から通信Ｉ／Ｆを介して、データベース検索を
行う対象機器７０としてのサーバ装置へ制御情報を出力
するシステムとして構成した。この場合、対象機器７０
としてのサーバ装置は、上述したように、出力される依
存性情報に基づき、効率的に検索範囲を限定して検索を
行う構成にすることができる。

【０１２５】また、図９（ｂ）では、制御情報出力装置
１としての情報端末から記録媒体へ制御情報を出力する
構成とした。この場合、対象機器７０は、記録媒体から
制御情報を読み取り、この制御情報に基づく動作を行
う。例えばユーザは自己の情報を記録媒体に記録して持
参すれば、旅行先のテレビジョン受像機などの対象機器
７０を自分の好みに合わせて自動的に動作させることが
できる。

【０１２６】図９（ｃ）では、制御情報出力装置１とし
ての情報端末から複数の対象機器７０を制御する制御装
置７１へ制御情報を出力するシステムの例である。この
ようなシステムは、車両に搭載して用いることが考えら
れる。その場合、対象機器７０は、ナビゲーション装置
をはじめとする車両搭載機器である。図９（ｄ）は、図
９（ｃ）と同様に、複数の対象機器７０を制御する制御
装置７１を備えるシステムであるが、制御装置７１が、
記録媒体を介して制御情報を読み込んで、動作する構成
である。

【０１２７】また、図９（ｅ）では、本制御情報出力装
置１をリモコンとして実現し、複数の対象機器７０へ制
御情報を送信するシステムである。家庭用電気器具が対
象機器７０になる場合、このようなシステムが有効であ
る。以上説明してきたような本第１実施例の制御情報出
力装置１では、対象機器７０を対象機器７０にて実行さ
れるアプリケーションプログラムの単位で捉え、これら
アプリケーションプログラムとユーザ要求を生じさせる
各種要因とに依存性という概念を導入した。具体的に
は、各アプリケーションプログラムと予め定められた依
存性要因との間に依存特性情報５０ｂなるアプリケーシ
ョンプログラムへの要求度と依存性要因値との対応関係
を用意し、この対応関係を用いて、アプリケーションプ
ログラムがいずれの依存性要因に依存するかを示す依存
性テーブル５０ａを用意した。そして、状況取得部３０
にて取得されるデータに基づき確定される依存性要因値
を用い、依存性テーブル５０ａ及び依存特性情報５０ｂ
に基づいて、相対的に実行要求が高いアプリケーション
プログラムを示すアプリケーションリストをアプリケー
ション情報として出力する。また、ユーザ要求を生じさ
せる依存性要因を示す依存性要因リスト、及び依存性テ
ーブル５０ａに基づく依存ベクトル、さらには、依存特
性情報５０ｂに基づく依存特性を出力する。これによっ
て、複数の対象機器７０、及びそれら複数の対象機器７
０に対してユーザ要求を発生させる種々の要因を統括的
に捉え、対象機器７０を総合的に、しかも、半自動的に
セットアップして動作させることができる。

【０１２８】例えばアプリケーションリストを出力する
ことによって、対象機器７０側でユーザ要求に応じたア
プリケーションプログラムの起動・起動準備を行うこと
ができる。また、依存性要因リスト及び依存ベクトルを
出力することによって、対象機器７０側でアプリケーシ
ョンプログラムの様々なカスタマイズを行うことができ
る。加えて、依存性情報に含めて依存特性を出力するよ
うにしたため、対象機器７０側で各依存性要因に対する
要求度を算出することが可能であり、ユーザのフィーリ
ングに極力合わせて対象機器７０を動作させることがで
きる。

【０１２９】さらにまた、本第１実施例の制御情報出力
装置１では、制御情報を符号化して出力する構成とし
た。このため、制御情報のデータ量を抑えることがで
き、特に、記録媒体やプロファイルへ出力する構成に有
効である。なお、本第１実施例のメモリ部５０が「記憶
手段」に相当し、入力部２０が「入力手段」に相当し、
状況取得部３０が「依存性情報取得手段」に相当する。
また、制御部１０が「制御情報出力手段」に相当し、図
５に示した制御情報出力処理が制御情報出力手段として
の処理に相当する。

【０１３０】上記第１実施例では、依存性テーブル５０
ａ（図３参照）に記述される情報は、「依存する
（「Ｄ」）」又は「依存しない（空白）」という２値の
情報であった。これに対して、例えば図３で示す依存性
テーブル５０ａの各升目に依存度合いを示す多値の情報
（依存度）を記述するようにしてもよい。例えば依存度
合いが最も高い場合を「１０」とし、依存していない場
合を「０」として１１段階で示すという具合である。こ
のようにすれば、ユーザのフィーリングにより合った対
象機器７０の動作が可能になるという点で有利である。
依存性要因間に重み付けができるためである。

【０１３１】この場合、アプリケーションプログラムに
対する依存ベクトルＤＰは、依存性要因Ｘｑ（ｑ＝１，
２，３，・・・，Ｑ）に対する依存度をｄｑとして、Ｄ
Ｐ＝（ｄ１，ｄ２，ｄ３，・・・，ｄＱ）と示すことが
できる。さらに、この場合は、依存度がある閾値以上の
もののみ符号化し、（依存性要因番号、依存度）という
二項組の列、すなわち（ｉ１，ｄｉ１），（ｉ２，ｄｉ
２），・・・で表現してもよい。

【０１３２】また、上記第１実施例では、依存性情報と
して依存性要因リスト、依存ベクトル、依存特性を出力
する構成であったが、「依存情報」としての依存ベクト
ルのみを出力する構成にすることもできる。この場合
は、依存ベクトルと依存性要因との対応付けが対象機器
７０側で可能となればよい。ただし、依存性要因リスト
があれば相対的に有効な依存性要因を判断できるため、
依存性要因リストを共に出力する構成がより好ましい。

【０１３３】さらにまた、対象機器７０側で要求度を算
出しないのであれば、依存特性を出力する必要はない。
一方、依存特性情報５０ｂを、対象機器７０側に記憶し
ておき、要求度を算出することも考えられる。ユーザ間
で依存特性がほぼ同様になる場合があるためである。し
かし、依存特性を出力する構成とすれば、ユーザ毎の要
求度を対象機器７０側で把握できるため、ユーザ毎の要
求に合わせた適切な制御を実現できる点で有利である。

【０１３４】また、確定された依存性要因値を依存性情
報に含めて出力することも考えられる。このようにすれ
ば、対象機器７０側で依存性要因値を取得する構成が必
要なくなるためである。 ［第２実施例］上記第１実施例のシステム構成例を図９
に示したが、図９（ａ）に示すようなサーバ装置を対象
機器とする検索システムの構成例を、以下第２実施例と
して説明する。そして特に、本第２実施例では、依存情
報を応用した検索処理を説明し、検索処理の効率化とア
プリケーションの普遍化について述べる。

【０１３５】図１０は、第２実施例の「情報システム」
としての検索システムの構成を示すブロック図である。
検索システムは、「制御情報出力装置」としてのユーザ
端末１００と、サーバ装置２００とを備えている。

【０１３６】ユーザ端末１００は、制御部１１０、入力
部１２０、状況取得部１３０、通信部１４０、メモリ部
１５０、表示部１６０、問い合わせ情報生成部１７０、
アプリケーション１８０とを有している。ユーザ端末１
００の構成は、上記第１実施例の制御情報出力装置１と
基本的に同様である。ここでは特に、サーバ装置２００
とのデータ通信を行うための通信部１４０、検索のため
の問い合わせ情報を生成する問い合わせ情報生成部１７
０、さらに、ユーザ端末にて実行されるアプリケーショ
ン１８０を有している。

【０１３７】一方、サーバ装置２００は、図１中の対象
機器７０に相当し、ユーザ端末と同様に構成された制御
部２１０、入力部２２０、状況取得部２３０、通信部２
４０、メモリ部２５０、及び情報出力部２６０を有して
いる。そしてさらに、検索処理実行のための検索情報生
成部２７０、コンテンツリスト２８１、コンテンツデー
タベース２８２、評価関数計算部２９０及び検索リスト
記憶部２９１を有している。

【０１３８】コンテンツデータベース２８２には、種々
の映像データ、音楽データなど検索対象となるコンテン
ツが記憶されている。コンテンツリスト２８１は、コン
テンツ検索のために利用される情報のリストである。検
索情報生成部２７０は、ユーザ端末１００からの問い合
わせ情報に基づき、検索処理に利用可能な検索情報を生
成する。そして、この検索情報に基づく評価関数の計算
を行うのが評価関数計算部２９０である。評価関数計算
部２９０による計算結果に従い、検索リスト記憶部２９
１に検索結果のコンテンツのリストである検索リストが
記憶される。

【０１３９】なお、各装置１００，２００の制御部１１
０、２１０は、インターフェースを介したシステム制御
を行い、エージェントと呼ばれる。また、依存性テーブ
ル１５０ａ，２５０ａや依存特性情報１５０ｂ，２５０
ｂなど基本構成については、上記第１実施例と同様であ
るため、説明を省略する。

【０１４０】上記第１実施例では、アプリケーションプ
ログラムを依存情報に基づいて総括的に捉え、アプリケ
ーションプログラムを半自動的にセットアップ、動作さ
せる構成について述べた。これを応用しプログラムに限
らず映像データなどのコンテンツまでを含め「アプリケ
ーション」という位置付けで捉えれば、コンテンツの依
存性という概念によって、コンテンツを検索することが
できる。例えば図３示した２次元の依存性テーブル５０
ａはビデオメディアに関連するアプリケーションプログ
ラムに係るものであり、「天気情報」、「交通情報」、
「カラオケ」、「スポーツ情報」、「ゴルフ情報」、
「スキー情報」、「レストラン情報」、「ショッピング
情報」、「旅行情報」、「景観情報」、「ニュース情
報」、「音楽情報」、「緊急情報」のアプリケーション
は、それぞれの情報を取得し映像を利用してユーザに提
示するプログラムとしたが、これらのアプリケーション
を各情報に関連する映像データ（コンテンツ）として定
義することができる。

【０１４１】次に図１１の説明図に基づき、本第２実施
例における検索処理の概要を最初に説明する。図１１に
おいて、記号Ａで示す車両に搭載されるナビゲーション
装置、記号Ｂで示すパーソナルコンピュータ、そして、
記号Ｃで示す携帯電話機が、それぞれユーザ端末１００
に相当する。そして、これら各装置との間でデータ通信
を行う記号Ｄで示したセンタ装置が、サーバ装置２００
に相当する。この例は、アプリケーションとしての映像
情報（コンテンツ）を検索するシステムであり、各映像
情報は、映像データ本体と、映像内容の記述データであ
るメタデータを有している。メタデータは、例えばメデ
ィア記述形式に関する国際標準案ISO/MPEG7 において規
格化が進められているものとすることが考えられる。

【０１４２】本第２実施例は、このメタデータに依存情
報を含めておき、各ユーザ端末１００からの依存情報と
の比較演算を行い、映像データを検索しようとするもの
である。この比較演算は、評価関数を用いて行われ、演
算対象となるのは、依存性符号である。ここで依存性符
号について説明する。

【０１４３】（１０）依存性符号 依存性符号は、例えば図３に例示したような依存性テー
ブルを行単位で取り出して符号化したものであり、アプ
リケーションがいずれの依存性要因に依存しているかを
示すものである。これは上記（６）で説明した依存ベク
トルを「１」又は「０」で符号化記述したものに他なら
ない。また依存性要因がユーザ要因、システム要因、メ
ディア要因に大別できることは、既に述べた（上記（１
−２）参照）。本第２実施例では、ユーザ要因に対応す
る依存性符号の部分をユーザ依存性符号（以下「ＤＣ
Ｕ」（Dependency Code for User）と適宜記述する。）
と定義し、メディア要因に対応する依存性符号の部分を
メディア依存性符号（以下「ＤＣＭ」（Dependency Cod
e for Media ）と適宜記述する。）と定義する。なお、
これらＤＣＵ及びＤＣＭを区別しない場合は、単に「Ｄ
Ｃ」と記述することもある。また、メディアに付された
依存性符号（ＤＣ）は「ＤＣ−Ｍ」と示し、ユーザ要求
として生成された依存性符号は「ＤＣ−Ｕ」と示す。ま
た、検索エージェント、すなわちサーバ装置２００の制
御部２１０にて検索用に変換された依存性符号は、ＤＣ
−Ｕと区別するために、「ＤＣ−Ａ」（Ａはエージェン
トによる変換を意味する）と示す。図１１では、問い合
わせプロファイル等の形式で送信されたＤＣ−Ｕが、検
索エージェントによってＤＣ−Ａに変換され、メタデー
タ中のＤＣ−Ｍと比較演算される様子を示している。

【０１４４】次に、このような依存性符号を用いた検索
処理をさらに詳細に説明する。まず検索処理を実行する
サーバ２００は、映像データなどのコンテンツを作成者
などが登録するためのコンテンツ登録処理を実行可能に
構成されている。このコンテンツ登録処理を、図１２の
フローチャートに基づき説明する。

【０１４５】まず処理が開始されると、コンテンツ作成
者による入力がなされ（Ｓ４００）、次に作成状況の情
報が取得される（Ｓ４１０）。コンテンツ作成者による
入力は、サーバ装置２００の入力部２２０を介してなさ
れ、一方、作成状況情報は、状況取得部２３０を介して
取得される。

【０１４６】続くＳ４２０では、アプリケーションの識
別がなされる。ここでいうアプリケーションは、図３に
例示されるような「天気情報」、「交通情報」、「カラ
オケ」、「スポーツ情報」、「ゴルフ情報」、・・・と
いう分類をいう。つまり、ここでは、コンテンツ作成者
による入力情報や状況情報から、そのコンテンツが例え
ば「天気情報」であるのか「交通情報」であるのかとい
った識別を行う。

【０１４７】ここで識別されたアプリケーションに基づ
き、依存性テーブル２５０ａが参照される（Ｓ４３
０）。次に新規アプリケーションか否かが判断される
（Ｓ４４０）。新規のアプリケーションであれば（Ｓ４
４０：ＹＥＳ）、アプリケーション名と依存性符号を依
存性テーブル２５０ａに追加し（Ｓ４５０）、その後、
Ｓ４６０へ移行する。一方、新規のアプリケーションで
なければ（Ｓ４４０：ＮＯ）、Ｓ４５０の処理を実行せ
ずに、Ｓ４６０へ移行する。

【０１４８】Ｓ４６０では依存性符号を生成して依存性
テーブル２５０ａの更新を行い、その後、Ｓ４７０に
て、生成した依存性符号や関連情報をコンテンツリスト
２８１に追加して、本コンテンツ登録処理を終了する。
次にユーザ端末１００にて実行される問い合わせ処理に
ついて、図１３のフローチャートに基づき説明する。

【０１４９】まず最初のＳ５００では、ユーザ入力がな
される。この処理は、ユーザ端末１００の入力部１２０
を介して行われる。そして続くＳ５１０では、状況取得
部１３０にて状況情報を取得する。次のＳ５２０では、
必要に応じてアプリケーション１８０を起動する。

【０１５０】その後、依存性テーブル１５０ａ、依存特
性情報１５０ｂ、及び量子化テーブル１５０ｃを順に参
照し（Ｓ５３０，Ｓ５４０，Ｓ５５０）、Ｓ５６０に
て、依存性符号を生成する。この依存性符号がＤＣ−Ｕ
である。そして、Ｓ５７０では、生成した依存性符号
（ＤＣ−Ｕ）を用いて問い合わせ情報を生成し、送信す
る。これに対して、サーバ装置２００は、問い合わせ情
報に基づく検索処理を実行し、検索結果を送信してく
る。

【０１５１】したがって次のＳ５８０では検索結果を受
信し、その後、Ｓ５９０にて、検索結果の認識や表示を
行い、本問い合わせ処理を終了する。次に、サーバ装置
２００における検索処理を、図１４のフローチャートに
基づいて説明する。

【０１５２】まず最初のＳ６００では、問い合わせ情報
を受信する。この処理は、図１３中のＳ５７０に対応す
るものである。続いて量子化テーブル２５０ｃを参照し
（Ｓ６１０）、検索情報生成部２７０にて検索情報を生
成する（Ｓ６２０）。この検索情報には、検索用の依存
性符号（ＤＣ−Ａ）が含まれる。

【０１５３】次のＳ６３０では、検索情報がコンテンツ
リスト２８１にあるか否かを判断する。例えば上述した
ようなコンテンツ登録処理（図１２参照）によってリス
トへの登録がなされている場合にはコンテンツリスト２
８１に依存性符号（ＤＣ−Ｍ）や関連情報などの検索情
報が存在するが、コンテンツデータベース２８２の全て
のコンテンツについての検索情報がコンテンツリスト２
８１に存在するとは限らない。ここでコンテンツリスト
２８１に検索情報があると判断された場合（Ｓ６３０：
ＹＥＳ）、コンテンツリスト２８１を参照して依存性符
号（ＤＣ−Ｍ）を獲得し（Ｓ６４０）、その後、Ｓ６６
０へ移行する。一方、コンテンツリスト２８１に検索情
報がないと判断された場合（Ｓ６３０：ＮＯ）、メタデ
ータ解析を行って依存性符号（ＤＣ−Ｍ）を獲得し（Ｓ
６５０）、その後、Ｓ６６０へ移行する。

【０１５４】Ｓ６６０では依存性符号に基づく評価関数
を計算し、その後、ある評価基準を満たすコンテンツの
一覧を１次検索リストとして生成する（Ｓ６７０）。こ
の評価関数によるコンテンツ評価については後述する。
そして、Ｓ６８０では、１次検索を完了したか否かを判
断する。ここで１次検索を完了したと判断された場合
（Ｓ６８０：ＹＥＳ）、メタデータによる２次検索を行
い（Ｓ６９０）、最終的な検索結果としてのコンテンツ
（ターゲットコンテンツ）を選択する。Ｓ７００にて検
索結果を配信し、その後、本検索処理を終了する。

【０１５５】このように本第２実施例の検索処理では、
依存性符号（ＤＣ）に基づくコンテンツ評価を行うこと
を特徴としている。そこで次にコンテンツ評価の手法を
説明する。 （１１） コンテンツの評価 （１１−１） 評価関数 ユーザ端末１００からの要求仕様をあらわす荷重ベクト
ルＷとサーバー装置２００に格納されるコンテンツＣｌ
の内容特性を表す依存特性ＳＣｌの内積演算としてコン
テンツの評価関数を定義する。次の式３、式４に示す如
くである。 ＪＣｌ ＝ Σ Ｗｋ・ＳＣｌｋ（Ｎｋ） …式３ Ｎｋ ＝ Ｉｎｔ（Ｘｋ／Ｑｋ） …式４ なお、ここでΣは、ｋ＝１〜Ｎまでの和記号であるとす
る。また、各変数は、次に示す如く定義されるものであ
る。

【０１５６】Ｘｋ ： ｋ番目の要因値 Ｑｋ ： ｋ番目の要因値に対する量子化係数 Ｎｋ ： ｋ番目の要因値を量子化した値 Ｃｌ ： データベース上のｌ番目のコンテンツ ＪＣｌ ： 要因群｛Ｘ１，…，Ｘｋ｝について要求に
対するコンテンツＣｌの適合性を示す評価値 Ｗｋ ： 状況（ユーザ要求、ユーザ・通信・端末・
メディアの環境）に応じて切り替える荷重係数 ＳＣｌｋ（Ｎｋ）： 要因Ｘｋに関してＣｌの適合度を
示す依存特性 ここでＳＣｌｋは、アプリケーションへの要求度Ｒｎに
等しい。したがって、Ｒｎ（Ｘｋ）と記述してもよい。
ここでＲｎ（Ｘｋ）とは、要因値Ｘｋに関するアプリケ
ーションＡｎへの要求度である。

【０１５７】また、要因値の量子化とは、例えば連続的
な時間情報を、「朝」、「昼」、「夜」や、「春」、
「夏」、「秋」、「冬」という情報として捉えるための
処理をいう。この量子化に係る情報を記述したのが、ユ
ーザ端末１００やサーバ装置２００の備える量子化テー
ブル１５０ｃ，２５０ｃである。

【０１５８】（１１−２） 評価関数の簡略化 上記（１１−１）では、評価関数を一般的に示した。す
なわち、荷重ベクトルＷは、各成分が多値をとり得る依
存ベクトルの一般形となっている。また、ＳＣｌは、依
存特性であり、依存性要因値に対する要求度の高まりを
示すグラフ（図４参照）で表現できる。

【０１５９】しかし、コンテンツの数が非常に大きい場
合、例えば１００万というオーダーでコンテンツが存在
する場合には、式１に示した評価関数を用いると、短時
間のうちにユーザ端末１００に検索結果を返すことは困
難となる。そこで、評価関数を下記のように簡略化して
記述することが考えられる。

【０１６０】例えば荷重係数Ｗを依存性符号ｄ（上述
したＤＣ−Ａ）で置き換えることが考えられる。次の式
５に示す如くである。 ＪＣｌ ＝ Σ ｄｋ・ＳＣｌｋ（Ｎｋ） …式５ これによって、ｄｋは「１」又は「０」であるため、１
コンテンツあたりＫ回の乗算を省くことができる。

【０１６１】同様に、ＳＣｌｋ（Ｎｋ）を、依存性符
号ｄＣｌｋ（上述したＤＣ−Ｍ）で置き換えることが考
えられる。次の式６に示す如くである。 ＪＣｌ ＝ Σ Ｗｋ・ｄＣｌｋ …式６ もちろん、両方を依存性符号で置き換えてもよい。す
なわち、次の式７に示す如くである。 ＪＣｌ ＝ Σ ｄｋ・ｄＣｌｋ …式７ さらに、評価値ＪＣｌが「０」又は「１」の２値をと
るようにすることも考えられる。次の式８に示す如くで
ある。 ＪＣｌ ＝ ΣＢｏｏｌｅａｎ ｄｋ・ｄＣｌｋ ＝ (d1 AND dCl1) OR (d2 AND dCl2) OR … …式８ なお、後述するコンテンツ評価処理では、上記式７に示
す評価関数を用いた場合について説明する。

【０１６２】（１１−３） 多値表現による依存特性の
符号化 コンテンツの依存特性の記述に際して、ＳＣｌｋ（Ｎ
ｋ）とｄＣｌｋの中間レベルの表現として、図１５のよ
うに属性要因（横軸）と要求度（縦軸）を量子化して多
値表現することが考えられる。この場合、００００、１
１１１以外のすべて（14種類）のケースで依存性がある
と判定される。ここで量子化段階が十分小さければ、多
値を取りうる１個の数値ｄＣｌｋで依存特性、すなわち
依存性要因値に対する要求度を符号化できる。したがっ
て、依存性の有無のみならず問い合わせ属性の値にマッ
チするかどうかさえも同時に（メタデータの解析をする
ことなく）判定できる。その場合は、評価関数を計算す
る前にｄＣｌｋを復号してやればよい。例えば、図１５
の依存特性を表現する符号は２値表現で「１０１０」、
１０進表現で「６」であるが、評価関数計算時にはＮｋ
＝Ｎ１ＴＳ（春）に対して対応する数値「０」を依存特
性の値として代入する。このようにすれば、依存性があ
ることも判定できる上に依存特性値ＳＣｌｋ（１）＝
０も同時に得ることができ、「春らしい映像」という検
索要求に対して、『依存性はあるが検索対象ではない』
という２次検索結果と同等の結果を１回の評価計算で得
ることができる。ここではＮｊＴＳ ＝ ０／１（ｊ＝
０，１，２，３）だが、当然ながら、縦軸の要求度も多
値化できる。

【０１６３】一方この場合、上記式１の場合と同様に、
コンテンツ毎に特性を定義する作業が発生するという難
点がある。これに対しては、後述するように「春らし
い」という言語表現を多値依存性符号ｄＣｌｋに一意的
に置きかえるテーブルを定義しておけばこの作業は大幅
に軽減される。

【０１６４】（１１−４） コンテンツ評価の効率化 優先順序付け 上記式３〜８に示した評価関数計算のΣ演算の中で、依
存性要因間の優先順序付けを行う。たとえば、時間、場
所、および最優先属性の要求ベクトル成分が「０」でな
いときは、評価関数計算を完了する以前に属性値を参照
し、そこで、属性値が要求と異なっていればその時点で
評価関数計算を打ち切ることが考えられる。これは特
に、コンテンツの数が多い場合の検索効率向上に有効で
ある。

【０１６５】範囲限定 上記式３〜８に示した評価関数計算のΣ演算の中で、状
況やアプリケーションの種類に応じて計算する要因を最
初から限定することが考えられる。 ＤＣ管理テーブルを利用 ＤＣ管理テーブルとは、生成した依存性符号のテーブル
である。これは図１６に示すように、一度生成された依
存性符号ＤＣ−ＭをＤＣ管理テーブルに登録しておき、
このＤＣ管理テーブルから依存性符号ＤＣ−Ｍをロード
して検索に使用するものである。例えばＤＣ管理テーブ
ルのデータセットは、次のように表現できる。

【０１６６】[コンテンツ番号、アプリケーション名、
依存性符号、アクセス履歴]上述したコンテンツ登録処
理によってコンテンツリスト２８１が作成され、このコ
ンテンツリスト２８１には、依存性符号などの検索情報
が記憶されることは上述した。ＤＣ管理テーブルを用い
るという思想は、登録時だけではなく、メタデータ解析
によって検索処理中に獲得された依存性符号（ＤＣ−
Ｍ）をも登録しようというものである。したがって、Ｄ
Ｃ管理テーブルは、コンテンツリスト２８１の一構成要
素として位置付けることができる。

【０１６７】次にＤＣ管理テーブルを用いた、１次検索
処理と、メタデータ解析で行う２次検索処理をさらに具
体的に説明する。また続けて、コンテンツ評価処理の具
体例を説明する。図１７は、ＤＣ管理テーブルを用いた
１次検索処理を詳細に示すフローチャートである。この
１次検索処理は、図１４中のＳ６３０〜Ｓ６８０の処理
に相当するものである。

【０１６８】まず最初のＳ８００では、ＤＣ管理テーブ
ルがあるか否かを判断する。ＤＣ管理テーブルが既に作
成されている場合には、ここで肯定判断される。ＤＣ管
理テーブルがあると判断された場合（Ｓ８００：ＹＥ
Ｓ）、Ｓ８１０へ移行する。一方、ＤＣ管理テーブルが
ないと判断された場合（Ｓ８００：ＮＯ）、図１８のＳ
８９０へ移行する。

【０１６９】Ｓ８１０では、ＤＣ管理テーブルを参照す
る。これによって依存性符号（ＤＣ−Ｍ）が読み出され
る。続くＳ８２０では、変数Ｊを「１」に初期化する。
この変数Ｊは、検索対象となるコンテンツを計数するた
めの変数である。

【０１７０】次のＳ８３０では、コンテンツ評価を行
う。詳しくは後述するが、ここではＤＣ−ＭとＤＣ−Ａ
とが比較される。Ｓ８３０による比較処理にて検索対象
とする／しないの判断がなされるため、検索対象とする
場合は（Ｓ８４０：ＹＥＳ）、１次検索リストにそのコ
ンテンツを追加し（Ｓ８５０）、Ｓ８６０へ移行する。
検索対象としない場合は（Ｓ８４０：ＮＯ）、Ｓ８５０
の処理を実行せず、Ｓ８６０へ移行する。

【０１７１】Ｓ８６０では、変数Ｊが定数Ｎ１に等しい
か否かを判断する。この定数Ｎ１は、ＤＣ管理テーブル
に依存性符号が記憶されているコンテンツの数を示す。
ここでＪ＝Ｎ１である場合（Ｓ８６０：ＹＥＳ）、Ｎ１
に「１」を加えたものを変数ｋに代入して（Ｓ８７
０）、図１８中のＳ８９０へ移行する。一方、Ｊ≠Ｎ１
である場合（Ｓ８６０：ＮＯ）、変数Ｊをインクリメン
トして（Ｓ８８０）、Ｓ８３０からの処理を繰り返す。

【０１７２】図１８のＳ８９０では、メタデータを解析
することによって、ｋ番目のコンテンツの依存性符号
（ＤＣ−Ｍ）を抽出する。そして続くＳ９００では、コ
ンテンツ評価を行う。この処理は、図１７中のＳ８３０
と同様のものである。したがって、検索対象とする場合
は（Ｓ９１０：ＹＥＳ）、１次検索リストにそのコンテ
ンツを追加し（Ｓ９２０）、Ｓ９３０へ移行する。一
方、検索対象としない場合は（Ｓ９１０：ＮＯ）、Ｓ９
２０の処理を実行せず、Ｓ９３０へ移行する。

【０１７３】このようにしてメタデータの解析により抽
出された依存性符号（ＤＣ−Ｍ）は、Ｓ９３０にてＤＣ
管理テーブルへ追加される。この依存性符号（ＤＣ−
Ｍ）の追加に伴い、上述した定数Ｎ１もインクリメント
される。次のＳ９４０では、変数Ｊが定数ＮＡに等しい
か否かを判断する。この定数ＮＡは、検索対象のコンテ
ンツの総数である。ここでＪ＝ＮＡである場合（Ｓ９４
０：ＹＥＳ）、すなわち、１次検索を完了した場合に
は、本１次検索処理を終了する。一方、Ｊ≠ＮＡである
場合（Ｓ９４０：ＮＯ）、すなわち、１次検索を完了し
ていないうちは、変数ｋ及び変数Ｊをインクリメントし
て（Ｓ９５０）、Ｓ８９０からの処理を繰り返す。

【０１７４】次に、メタデータ解析による２次検索処理
を具体的に説明する。図１９は、ＤＣ管理テーブルを用
いた２次検索処理を詳細に示すフローチャートである。
この２次検索処理は、図１４中のＳ６９０及びＳ７００
の処理に相当する。

【０１７５】まず最初のＳ１０００では、変数ｍを
「０」に初期化し、変数ｍ２を「１」に初期化する。続
くＳ１０１０ではコンテンツＣｍのメタデータＭｍをア
クセスし、次のＳ１０２０では、解析の深さを決定す
る。そして続くＳ１０３０では、Ｓ１０２０で決定され
たレベルの解析を行い、検索適合度ＲＭを算出する。こ
のようなメタデータの解析手法には種々のものがある
が、特徴部分の説明に不要であるため、ここでの解説は
割愛する。

【０１７６】次のＳ１０４０では、検索適合度ＲＭが閾
値ＲＭｔｈ以上であるか否かを判断する。ここでＲＭ≧
ＲＭｔｈである場合（Ｓ１０４０：ＹＥＳ）、変数ｍ２
をインクリメントし（Ｓ１０５０）、検索リストにコン
テンツＣｍを追加して（Ｓ１０６０）、Ｓ１０７０へ移
行する。一方、ＲＭ＜ＲＭｔｈである場合（Ｓ１０４
０：ＮＯ）、Ｓ１０５０及びＳ１０６０の処理を実行せ
ず、Ｓ１０７０へ移行する。

【０１７７】Ｓ１０７０では、変数ｍが定数ＮＭよりも
小さいか否かを判断する。この定数ＮＭは、１次検索リ
ストに記憶されたコンテンツ数である。ここでｍ＜ＮＭ
である場合（Ｓ１０７０：ＹＥＳ）、すなわち１次検索
リストに記憶されたコンテンツのメタデータ全てを解析
をしていないうちは、変数ｍをインクリメントし（Ｓ１
０８０）、Ｓ１０１０からの処理を繰り返す。一方、ｍ
＝ＮＭである場合（Ｓ１０７０：ＮＯ）、すなわち１次
検索リストに記憶されたコンテンツのメタデータの全て
を解析している場合には、図２０中のＳ１０９０へ移行
する。

【０１７８】Ｓ１０９０からは、検索リストに追加され
たコンテンツの配信に係る処理の具体例である。ここで
はコンテンツ毎に、要約動作の有無及び符号化方式を決
定して、コンテンツに合わせた、また、ユーザ要求に合
わせた配信処理を行う。図２０のＳ１０９０では、変数
ｍ３を「１」に初期化する。続くＳ１１００では、コン
テンツの表示時間を計算する。ここでは映像データを検
索対象にすることを前提にして、その映像データの表示
時間を計算する。

【０１７９】そして次のＳ１１１０では、指定時間内に
表示可能か否かを判断する。ここで指定時間内に表示不
可能な場合（Ｓ１１１０：ＮＯ）、Ｓ１１２０にて要約
動作を実行し、その後、Ｓ１１３０へ移行する。一方、
指定時間内に表示可能な場合（Ｓ１１１０：ＹＥＳ）、
Ｓ１１２０の処理を実行せずに、Ｓ１１３０へ移行す
る。

【０１８０】Ｓ１１３０では、選択されたコンテンツに
合わせた符号化方式を選択する。そして次のＳ１１４０
では、現在ソースの符号化方式とＳ１１３０で選択され
た符号化方式とが異なるか否かを判断する。ここで符号
化方式が異なっていると判断された場合（Ｓ１１４０：
ＹＥＳ）、符号化方式を変換し（Ｓ１１５０）、ユーザ
端末１００への配信処理を行い（Ｓ１１６０）、その
後、Ｓ１１７０へ移行する。一方、符号化方式が同一で
あると判断された場合（Ｓ１１４０：ＮＯ）、Ｓ１１５
０の処理を実行せずそのまま、ユーザ端末１００への配
信処理を行い（Ｓ１１６０）、その後、Ｓ１１７０へ移
行する。

【０１８１】Ｓ１１７０では、変数ｍ３が変数ｍ２より
も小さいか否かを判断する。変数ｍ２は、検索リストに
記載されたコンテンツ数である。ここでｍ３＜ｍ２であ
る場合（Ｓ１１７０：ＹＥＳ）、すなわち配信していな
いコンテンツがあるうちは、変数ｍ３をインクリメント
して（Ｓ１１８０）、Ｓ１１００からの処理を繰り返
す。一方、ｍ３＝ｍ２である場合（Ｓ１１７０：Ｎ
Ｏ）、全てのコンテンツを配信した場合には、Ｓ１１９
０へ移行する。

【０１８２】Ｓ１１９０では新規に作成された項目をＤ
Ｃ管理テーブルへ記憶し、その後、本２次検索処理を終
了する。続いて、コンテンツ評価処理を、図２１のフロ
ーチャートに基づいて説明する。このコンテンツ評価処
理は、図１７中のＳ８３０及び図１８中のＳ９００にて
コールされるものである。

【０１８３】まず最初のＳ１２００では、変数ＲＩＤＸ
に「０」を代入して初期化する。続くＳ１２１０では、
変数ｉを「０」に初期化する。続くＳ１２２０では、依
存性符号（ＤＣ−Ａ）のｉ番目要素と依存性符号（ＤＣ
−Ｍ）のｉ番目要素との論理積が「１」であるか否かを
判断する。ここで（ＤＣ−Ａｉ）ＡＮＤ（ＤＣ−Ｍｉ）
＝１である場合（Ｓ１２２０：ＹＥＳ）、Ｓ１２３０へ
移行する。一方、（ＤＣ−Ａｉ）ＡＮＤ（ＤＣ−Ｍｉ）
≠１である場合（Ｓ１２２０：ＮＯ）、Ｓ１２８０へ移
行する。

【０１８４】Ｓ１２３０では変数ＲＩＤＸをインクリメ
ントする。続くＳ１２４０では、依存性符号（ＤＣ）の
ｉ番目要素（ＤＣｉ）は、最重要属性か否かを判断す
る。ＤＣｉが最重要属性であれば（Ｓ１２４０：ＹＥ
Ｓ）、この時点でメタデータを解析して属性Ａｉの値を
判定し（Ｓ１２５０）、Ｓ１２６０へ移行する。一方、
ＤＣｉが最重要属性でなければ（Ｓ１２４０：ＮＯ）、
Ｓ１２８０へ移行する。

【０１８５】Ｓ１２６０では、Ｓ１２５０で判定された
属性Ａｉの値に基づき、検索条件に適合しているか否か
を判断する。ここで検索条件に適合していると判断され
た場合（Ｓ１２６０：ＹＥＳ）、Ｓ１２８０へ移行す
る。一方、検索条件に適合していないと判断された場合
（Ｓ１２６０：ＮＯ）、検索対象にしないものとして
（Ｓ１２７０）、本コンテンツ評価処理を終了する。す
なわち、最重要属性の属性値が要求に合致していない場
合には、コンテンツ評価を途中で打ち切る。これによっ
てコンテンツ評価の効率化が図られる。

【０１８６】Ｓ１２８０では、変数ｉが定数Ｎに等しい
か否かを判断する。この定数Ｎは、依存性要因の数であ
る。ここでｉ＝Ｎである場合（Ｓ１２８０：ＹＥＳ）、
すなわち全ての依存性要因について論理積を計算してい
る場合には、Ｓ１３００へ移行する。一方、ｉ≠Ｎであ
る場合（Ｓ１２８０：ＮＯ）、すなわち、論理積を計算
していない依存性要因が存在する場合には、変数ｉをイ
ンクリメントして（Ｓ１２９０）、Ｓ１２２０からの処
理を繰り返す。

【０１８７】Ｓ１３００では、変数ＲＩＤＸが閾値Ｒｔ
ｈ以上であるか否かを判断する。ここでＲＩＤＸ≧Ｒｔ
ｈである場合（Ｓ１３００：ＹＥＳ）、検索対象にする
ものとして（Ｓ１３１０）、本コンテンツ評価処理を終
了する。一方、ＲＩＤＸ＜Ｒｔｈである場合（Ｓ１３０
０：ＮＯ）、検索対象にしないものとして（Ｓ１３２
０）、本コンテンツ評価処理を終了する。

【０１８８】なお、ここで説明したコンテンツ評価処理
において、次に示すようなバリエーションを考えること
ができる。 （ａ）上述した処理では、各成分が「０」又は「１」の
値をとる依存性符号（ＤＣ−Ａ，ＤＣ−Ｍ）を用いて計
算したが、上記式３に示したような荷重ベクトルＷ及び
依存特性ＳＣｌを用いた計算を行ってもよい。これによ
り、各成分（属性）の重要性のレベルを表現できる。

【０１８９】（ｂ）また、変数ｉをインクリメントして
いくことによって１番目の成分から順に演算していた
が、演算順序を変数ｉで規定するのではなく、優先順序
を取り入れて、ｉ番目に演算する成分を番号Ｊ（ｉ）で
規定してもよい。例えば、Ｊ（１）＝３，Ｊ（２）＝
６、Ｊ（３）＝１、・・・とすれば、３番目、６番目、
１番目、・・・という順序で論理演算がなされることに
なる。これによって重要度の高い属性を先に計算するこ
とができる。

【０１９０】次に、以上のような処理で選択される検索
対象のコンテンツを具体化し、依存性符号を用いた検索
処理における本提案の有効性を示す。 （１４） コンテンツ （１４−１） コンテンツの価値 例えばコンテンツとして映像データを例に挙げれば、サ
ーバー装置２００側でコンテンツを表現する依存性符号
（ＤＣ−Ｍ）は、次のような依存性要因に対するものと
することができる。

【０１９１】 ｄＣｌ ＝ （ｄＴｓ，ｄＸｓ，… ） ｄＡ ： このコンテンツの価値が依存性要因Ａに依存
するかどうかを示す符号。「１」ならば依存、「０」な
らば依存しない。 Ｔｓ ： シーン時間。対象とするコンテンツが表すシ
ーンの時間情報 Ｘｓ ： シーン場所。対象とするコンテンツが表すシ
ーンの場所情報 （１４−２） 映像検索におけるコンテンツの価値 上記（１４−１）で示したような依存性符号（ＤＣ−
Ｍ）が表現する映像データとしてのコンテンツ評価を行
う場合、次に示すような価値判断を行うことが考えられ
る。

【０１９２】例えば、＜４月１２日、田園風景＞のシー
ンの価値をシーンの撮影日時で判断すると、「春のシー
ン」として価値がある（要求に合致する）。この場合、
時間に対する依存性は４月を中心とする要求度の高まり
として表現される。一方、「冬のシーン」としては価値
が低い。これをグラフを用いて表現すると、図２２の如
くとなる。

【０１９３】また、＜８月、軽井沢＞のシーンの価値を
シーンの撮影場所と季節で判断すると、例えば「夏の軽
井沢近辺の観光地シーン」として価値がある（要求に合
致する）。この場合、時間に対する依存性は８月を中心
とする要求度の高まりとして表現される。これは「冬ら
しいシーン」や「春らしいシーン」としては価値が低
い。また、場所に関する依存性は軽井沢近辺でなおかつ
避暑地、観光地を彷彿とさせるスポットを中心とした要
求度の高まりとして表現される。

【０１９４】さらに、春に作られた「機械のビデオマニ
ュアル」や「航空機内の緊急避難用具の説明映像」はい
わゆる「春らしい風景」には該当しない。これらの例に
おいて、言語表現「春らしい」は図２２に示すような依
存特性Ｒ（Ｔｓ）の数値表現を高能率符号化していると
考えられる。

【０１９５】これらの例を見ると、厳密に映像検索を行
うには、シーン時間といった依存性要因に依存するか否
かだけでなく、依存性要因値に対する要求度の高まり具
合を示す依存特性Ｒ（Ｔｓ）を各コンテンツ毎に表現し
ておくことが望ましい。しかし、実際は膨大なデータベ
ースに対してすべてそれを行うことは困難である。人間
の主観では、言語表現（「春らしい」など）でパターン
化されている。この言語表現はコンテンツのメタデータ
中に記述可能であるが、あらゆる計算機や機器、大容量
のコンテンツデータベースに対して共通に、自動的かつ
高速かつ誤りなく意味を判別することは容易ではない。
例えば、（春、パリ）という風景に対する要求は時間値
Ｔｓに対して α＜Ｔｓ＜β という季節判定を行った
後、空間座標値に対しても同様な不等式判定が必要と考
えられるが、その不等式の上限、下限、成立条件をすべ
てのユーザ、すべてのアプリケーションに対して厳密に
定義することは容易ではないからである。

【０１９６】そこで、理想的には依存特性の数値表現や
言語表現で記述されるコンテンツのメタデータを最初か
ら深く検索するのではなく、各属性についての依存性の
有無を符号表現することで1次検索の効率を高めようと
するのが本提案の考え方である。例えば、図２３に示す
ように、シーンのアプリケーション、つまり「観光情報
・ホテル情報」、「機械修理マニュアル」、「観光情報
・渋滞情報」、「アイドル映像・コマーシャル」と分類
できるアプリケーションが、「時間」、「場所」、「天
気」というユーザ要因や、「シーン時間」、「シーン場
所」、「シーンのアクター」、「シーンのフィーリン
グ」というメディア要因に対しどのような要求度の高ま
りを有するかを、図２３中の各升目に示すような依存特
性のグラフや言語表現で詳細に規定することは難しい。
また、検索に要する時間が膨大になってしまう。そこ
で、これも各升目に示したが、依存する場合を「１」、
依存しない場合を「０」、不定の場合を「Ｘ」とした依
存性符号で価値判断を行うのである。

【０１９７】この基本方針は、映像以外のアプリケーシ
ョンにも共通して採用することができることは言うまで
もない。 （１４−３） 音楽検索におけるコンテンツの価値 例えば映像検索以外の音楽検索について説明する。

【０１９８】音楽を検索する場合は、時々刻々と変化す
るユーザのフィーリングへの適合性の評価が必要とな
る。このフィーリングへの依存性は、次のような依存性
要因に基づいて考えることができる。これはフィーリン
グの定義として一般化することができる。

【０１９９】 Ｆｕ ： ユーザのフィーリング｛さわやかな、楽し
い、暗い、悲しい、元気な、etc.｝ Ｆｍ ： 音楽の持つフィーリング｛静かな、激しい、
ポップな、明るい、etc.｝ このような依存性要因を用い、ある音楽が検索された際
のＦｕとＦｍを対応付けることで「この音楽はどういう
フィーリングのユーザが好むか？」という傾向を知るこ
とができる。

【０２００】その他、ユーザ時間Ｔｕ、ユーザ場所Ｘ
ｕ、アーティストＡｒなどが、音楽検索における依存性
要因として考えられる。 （１４−４） コンテンツの自動分類 コンテンツの代表値を一意に決定することは困難であ
る。しかし、依存性という概念でコンテンツを捉えれ
ば、コンテンツの価値判断の基準となる特性を半自動的
に付与することができ、例えばサイトにアップロードさ
れるコンテンツなども分類することができる。サイト上
に依存性テーブルがあれば、テーブル中の依存性符号と
比較することで、関連アプリケーションを識別すること
もできる。

【０２０１】例えば上述したようなコンテンツ登録処理
（図１２参照）によって依存性符号を生成してコンテン
ツを登録することもその一例として考えられる。これと
同様に、ユーザ端末１００からアップロードされるコン
テンツについても自動分類する構成とすれば、データベ
ースに蓄積されるあらゆるコンテンツを管理することが
可能になる。

【０２０２】例えば図２４に示すようなコンテンツ追加
処理を実行できるようにサーバ装置２００を構成するこ
とが考えられる。ここでは処理が開始されるとまず、ア
プリケーション名の入力を促す（Ｓ１４００）。アプリ
ケーション名が入力されると、次に、依存性テーブル２
５０ａに記載された代表語彙とインデックスに変換し
（Ｓ１４１０）、依存性テーブル２５０ａを参照して依
存性符号を獲得する（Ｓ１４２０）。例えば、アプリケ
ーション名「店の映像情報」などが入力されると、依存
性テーブル２５０ａにある「レストラン情報」という代
表語彙で置き換え、これに関する依存性符号を獲得する
という具合である。アプリケーション名から代表語彙・
インデックスへの変換は、例えばテーブルなどの対応関
係を用意して行えばよい。

【０２０３】次のＳ１４３０では、アプリケーション名
の入力が終了したか否かを判断する。ここで入力が終了
したと判断されると（Ｓ１４３０：ＹＥＳ）、Ｓ１４４
０へ移行する。一方、入力が終了していないうちは（Ｓ
１４３０：ＮＯ）、Ｓ１４００からの処理を繰り返す。
これにより、複数のアプリケーション名が入力された場
合は、依存性テーブル２５０ａから複数の依存情報が参
照され、新規のアプリケーションに対しても依存情報の
適切な類推が可能になる。

【０２０４】Ｓ１４４０では最終的な依存情報の生成を
行い、Ｓ１４５０にてメタデータに依存情報を格納し
て、本コンテンツ追加処理を終了する。次に、ナビゲー
ション装置などの車両情報機器としてユーザ端末１００
を実現した場合の依存性符号（ＤＣ−Ｕ，ＤＣ−Ａ，Ｄ
Ｃ−Ｍ）における依存性要因の具体例を説明する。

【０２０５】図２５に示すように、ＤＣ−Ｕにおける依
存性要因としては、ユーザの「名前」、「性別」、「年
齢」、「住所」、「家族構成」、「仕事」、「好きな料
理」、「好きな場所」、「好きな音楽」、「好きなスポ
ーツ」、「趣味」、「メモリアルデイ」などのユーザの
個人情報、「現在地」、「現在時刻」、「目的地」、
「経由地」、「状況」、「現在地の天気」、「目的地の
天気」、「目的」、「現在状態（フィーリングな
ど）」、「予測状態」、「現在要求」、「予測要求」、
「温度（車内、車外、希望）」、「話題」、「走行道路
（高速道路／一般道路）」、「乗員構成」などの状況情
報、そして、「端末能力」、「画面サイズ」、「ビット
レート」などのシステム情報が挙げられる。検索に直接
的に利用されるＤＣ−Ａは、「ユーザ現在地」、「ユー
ザ現在時刻」、「シーン場所」、「シーン時刻」、「ア
クター」、「移動速度」などの依存性要因に係るものと
することが考えられる。ＤＣ−Ｍでは、「シーン場
所」、「シーン時刻」といったメディア要因が依存性要
因となっている。

【０２０６】次に代表的な依存性要因とその依存性要因
がとり得る依存性要因値の例を示すことによって、依存
性要因に対する理解を深める。 （１５） 依存性要因と依存性要因値の例 （１５−１） ユーザ要因 ・Ｔｕ ： ユーザ時間（例：２０００年１１月２９日
水曜日１４時２５分） ・Ｘｕ ： ユーザ場所（例：愛知県日進市米野木町、
名古屋駅、○○駅付近、他） ・Ｆｕ ： ユーザフィーリング（例：さわやかな、疲
れている、暑い、いらいらしている、他） ・Ｗｕ ： ユーザのいる場所の天気（例：雪、小雨、
霧、快晴、雷雨、他） （１５−２） メディア要因 ・Ｔｓ ： シーン時間（例：７月３日午後２時、春、
５年前、明日、他） ・Ｘｓ ： シーンの示す場所（例：横浜、パリ、刈谷
市昭和町付近、他） ・Ａｓ ： シーンに出てくるアクター（例：アイドル
歌手のｘｘｘ、おばあさん、総理大臣、他） ・Ｆｓ ： シーンのフィーリング（例：きれいな、激
しい、寒そうな、暖かい、混雑した、他） ・Ｗｓ ： シーンの天気（例：晴れ、台風、洪水、
雷、曇り、大雨、他） （１６） 依存性符号の記述例 上記（１５）では、依存性要因のとり得る依存性要因値
の例をまとめた。そこで次に、このような依存性要因へ
の依存性の有無を示す依存性符号の記述例を示す。ここ
では、コンテンツの依存性要因が上述したシーンの時間
（Ｔｓ）、シーン場所（Ｘｓ）、アクター（Ａｓ）、フ
ィーリング（Ｆｓ）であるものとして、様々な記述例を
示す。上述したように「０」は依存していないこと、
「１」は依存していること、「Ｘ」は不定であることを
示すものとする。

【０２０７】 シーン１ ： 軽井沢のホテル （１，１，０，Ｘ） これを一般化すると「観光地のホテル映像」には依存性
符号（１，１，０，Ｘ）を付与できると考えられる。 シーン２ ： 機械の修理マニュアル映像 （０，０，０，０） これを一般化すると「ビデオマニュアル類」には依存性
符号（０，０，０，０）を付与できると考えられる。類
似例として「航空機内の緊急災害時の対応マニュアル映
像」などがある。

【０２０８】 シーン３ ： 猿投グリーンロードの状況 （１，１，０，０） 渋滞状況としての要求度 （１，１，０，０） ルートガイド映像としての要求度 （０，１，０，０） シーン４ ： 愛知健康の森までのルートガイド映像（０，１，０，０） シーン５ ： ８月の沖縄、本○真奈美の映像 （１，１，１，Ｘ） 本○真奈美がアイドルであれば、アイドル映像の要求が
高くなるという事実を前提として、主要な依存性要因は
Ａｓ＝１である。したがって、情報の与えられ方によっ
ては、次のケースもありうる。要求度がシーンのアクタ
ーにのみ依存する場合は（０，０，１，Ｘ）、要求度が
シーンの場所とアクターに依存する場合は（０，１，
１，Ｘ）であり、要求度がシーンの時間とアクターに依
存する場合（１，０，１，Ｘ）となる。

【０２０９】 シーン６ ： オモチャのコマーシャル映像 （０，０，１，１） これは要求度がアクターおよびフィーリングに依存する
と考えられるためである。 シーン７ ： スキー場の観光案内 （１，１，０，Ｘ） 依存性符号は「観光地のホテル案内」と類似する。

【０２１０】 シーン８ ： ニュース映像 （Ｘ，Ｘ，Ｘ，０） この場合、上記４つの依存性要因は、上述した1次検索
に対してあまり有効でないことが分かる。したがって、
コンテンツにニュース映像などが含まれてくる場合に
は、別の依存性要因、例えばニュース属性などを設定す
る必要があると考えられる。

【０２１１】このような依存性要因に対する依存性符号
の記述がなされていることを前提とした場合、例えば上
述した依存性符号（ＤＣ−Ａ）が（０，１，０，Ｘ）で
あるとすると、１次検索処理によって、シーン｛１，
３，４，５，７｝がヒットする。また、依存性符号（Ｄ
Ｃ−Ａ）が（０，０，１，Ｘ）であれば、シーン｛５，
６｝がヒットする。

【０２１２】以上のように構成された本第２実施例の検
索システムの発揮する効果を説明する。なお、ここでの
説明に対する理解を容易にするため、最初に従来の問題
点を簡単に説明する。インターネットにおいても顕著な
ように、今後膨大な数のコンテンツが複数のデータベー
スサイトにわたって分散して存在し、それらに対する効
率的な検索手法が望まれている。特にモバイル端末にお
いては、即座にユーザの要求に即したコンテンツが検索
・配送されることが望まれる。しかるに、現状ではあら
かじめ規定したサイト以外のデータベースも探索してリ
アルタイムかつ低コストの計算量で情報提供できるシス
テムはまだない。

【０２１３】従来の検索システムで例えば映像データな
どのコンテンツ検索を行おうとすると、規格化が進めら
れているメディア記述形式に関する国際標準案ISO/MPEG
7 において作成されるメタデータ（内容記述データ）を
用いることができるが、メタデータのデータサイズが１
Ｋバイトを超えてしまう例も存在する。したがって、端
末側での検索対象が数百万件を超えるオーダーになる場
合は、Ｇバイトオーダーのメタデータ通信が必要にな
る。さらに、ユーザ自信も数百万人を超えるとなると、
通信インフラやデータベースサイトの通信トラフィック
量から、現状の最高性能の計算機を持ってしてもリアル
タイム処理が困難な状況が発生する。

【０２１４】これに対して、本第２実施例では、プログ
ラムに限らず映像データなどのコンテンツを含めた検索
対象情報をアプリケーションとして総合的に捉え、依存
情報によるアプリケーションの検索を提案した。具体的
には、上記第１実施例で定義した依存ベクトルの成分を
「０」又は「１」で表現した依存性符号（ＤＣ）を用
い、依存性符号の内積演算で評価関数を定義して１次検
索を行う。つまり、代表値で記述することが困難な映像
データなどのアプリケーションを依存性符号（ＤＣ）と
いう形式で捉えるという技術思想によって、ありとあら
ゆるジャンルに属するコンテンツに対する迅速な検索を
簡単な演算で可能にしたのである。

【０２１５】依存性符号（ＤＣ）を用いた１次検索によ
れば、高速検索に寄与できる。そして、コンテンツの相
互運用性を向上できる。つまり、従来は別のジャンルに
分類されていたコンテンツをも容易に検索することがで
きる。例えば、カラオケ映像を取得したいとのユーザ要
求に対し、例えば広告・宣伝映像などがその検索条件に
マッチして取得されるという具合である。また、コンテ
ンツの特性が明確に記述されていなくても、検索対象を
絞り込める。さらに、コンテンツの特性を一意的な代表
値に自動的に置きかえることが困難な場合にも有効であ
る。例えばある映像データが様々な時間帯や場所にわた
るシーンで構成されている場合など、時間と場所とを自
動的に代表値で記述することは難しいためである。

【０２１６】また、アプリケーションを依存性要因への
依存情報で捉えるようにすれば、アプリケーションの普
遍的記述が達成される。これを次に説明する。 （１８） アプリケーションの普遍的記述 （１８−１） 依存性符号の獲得 たとえば撮影した映像に内容記述を付加できるカメラが
あるとすれば、それは上述したような（Ｔｓ，Ｘｓ，Ａ
ｓ，Ｆｓ）を自動的に映像音声に付与できることが望ま
しい。Ｔｓ，Ｘｓは自動的に取得可能である。一方、Ａ
ｓ，Ｆｓは人手を会した入力が必要である。そこで、ユ
ーザから自然にメタデータ作成に関する情報を聞き出す
ための質問対話シナリオを用意することが考えられる。
例えば、コンテンツ作成時に「観光、渋滞、ルートガイ
ド」と音声入力、キー入力、アノテーション、メニュー
選択などで入力し、その後のガイダンスプログラムに従
って入力していけばよい。これによって、ユーザはただ
エージェントからの質問に答えるだけでよく、あれこれ
と悩むことなく記述を半自動的に付与することができ
る。

【０２１７】（１８−２） 依存情報の更新 メディアに付与される依存情報の更新 （９７年３月２日、横浜中華街、…）という映像コンテ
ンツＣｘに写っている一群の女性のうちの一人『田○花
子』が、今をときめくアイドル歌手『本○真奈美』であ
ることがわかった、とする。

【０２１８】このような場合、映像コンテンツＣｘへの
要求度はアクター（Ａｓ）の要因に依存するように変化
すると考えられる。その場合、その依存性符号の中のア
クター（Ａｓ）に関する成分は「０」から「１」に更新
される。 ユーザ要求に応じてエージェントが作成する依存情報
の更新 ユーザの検索履歴や他ユーザの検索履歴に応じて上記式
３や式６の荷重ベクトルＷを修正することが考えられ
る。

【０２１９】（１８−３） アプリケーションの普遍的
表現 アプリケーションは時代とともに変化し、国や文化によ
っても異なる。一方、相互運用性のあるデータベースは
継続して使用され得る。したがってアプリケーション名
でコンテンツを分類することは特定サービスを想定して
作ったコンテンツ以外では困難である。

【０２２０】しかしながら、たとえば芸能界アイドル、
渋滞情報、ニュース、観光情報などを考える場合、それ
らを扱うアプリケーションやコンテンツに対するユーザ
の視点は変わりうるが、基本的な評価属性としては一定
かつ普遍的なものが存在すると考えられる。そこで、依
存情報を普遍的な依存性要因で表現し、依存性テーブル
において依存性要因とアプリケーションとを関連付ける
ことにより、普遍的なアプリケーション記述ができると
考えられる。

【０２２１】（１８−４） ユーザ側のアプリケーショ
ンからの符号化 ユーザ端末１００で選択できるアプリケーション１８０
の集合を Ａｃ ＝ ｛Ａｃ１，Ａｃ２，…，ＡｃＮ｝ とする。この中からユーザがあるアプリケーションＡｃ
ｉを選択した場合、そのアプリケーションに相当する識
別情報がサーバ装置２００のコンテンツデータベース２
８２にあれば、ＡｃｉとコンテンツＣｌとの対応を取る
ことが可能である。しかし、現実には全世界のアプリケ
ーションを統一的にしかも長期にわたって表現するよう
な識別情報は存在しない。そこで、アプリケーションＡ
ｃｉを標準的なメディア属性やユーザ属性に変換するた
めの依存性テーブル１５０ａを用い、アプリケーション
を依存性符号などの依存情報で表現する。

【０２２２】（１８−５） サーバ側のアプリケーショ
ンからの符号化 同様に、データベースに蓄えられるコンテンツの作成者
は、端末ユーザの選択するアプリケーションの集合を Ａｍ ＝ ｛Ａｍ１，Ａｍ２，…，ＡｍＭ｝ とする。この中から該当するアプリケーションＡｍｊを
選択し、サーバー装置２００の依存性テーブル２５０ａ
を用いて登録するコンテンツに適した依存性符号でＡｍ
ｊを表現する。これにより、ＡｃとＡｍがまったく異な
るアプリケーション集合であっても、依存性符号による
普遍的表現を通じて、コンテンツの相互運用性が保証さ
れ、いかなる問い合わせに対しても安定した検索動作を
実行することができる。

【０２２３】なお、ユーザ端末１００のメモリ部１５０
が「記憶手段」に相当し、サーバ装置２００のメモリ部
２５０が「サーバ側記憶手段」に相当する。また、制御
部１１０及び問い合わせ情報生成部１７０が「制御情報
出力手段」に相当し、サーバ装置２００の制御部２１
０、検索情報生成部２７０及び評価関数計算部２９０が
「検索手段」に相当する。

【０２２４】また、図１４に示した検索処理の変形例を
図２６に示した。図１４に示す検索処理では、評価関数
計算（Ｓ６６０）の後、１次検索リストを生成し（Ｓ６
７０）、１次検索を完了したと判断すると（Ｓ６８０：
ＹＥＳ）、メタデータによる２次検索を行っていた（Ｓ
６９０）。これに対して、図２６に示すように、評価関
数計算（Ｓ１５６０）の後、１次評価をパスしたか否か
を判断し（Ｓ１５７０）、パスしていれば即座に、メタ
データによる２次検索を行うようにしてもよい（Ｓ１５
７０：ＹＥＳ，Ｓ１５８０）。

【０２２５】また、別の変形例を図２７及び図２８に示
した。この場合、図２７に示す検索処理の前半部分は図
１４に示した処理とほぼ同様であるが、２次検索を完了
した後（Ｓ１７９０：ＹＥＳ）、図２８のＳ１８００へ
移行し、コンテンツリスト２８１にないメタデータがあ
れば（Ｓ１８００：ＹＥＳ）、メタデータ解析による評
価関数計算を行い（Ｓ１８２０）、ここで１次評価をパ
スすれば（Ｓ１８３０：ＹＥＳ）、２次検索を行う（Ｓ
１８４０）。

【０２２６】このように検索処理もコンテンツリスト２
８１の構造等によって種々のバリエーションで実現する
ことができる。以上、本発明はこのような実施例に何等
限定されるものではなく、本発明の主旨を逸脱しない範
囲において種々なる形態で実施し得る。 ［その他］ （イ）依存性要因について 依存性要因としてユーザ要因、システム要因、及びメデ
ィア要因が考えられることは既に述べた。そして、この
ような依存性要因に対する依存性要因値は、状況取得部
３０，１３０，２３０で取得されるデータに基づき確定
されることも、上述したところである。ここでは、さら
に、依存性要因として設定される、時間依存性、空間依
存性、及び場面に関する依存性についての獲得方針等に
ついての説明を加える。

【０２２７】（ハ−１）時間依存性 ある属性の属性値又はアプリケーションの選択された時
刻を時間軸上で記録し、１日、１週間、１ヶ月、１年と
いった各レベルの周期で出る傾向を分析する。特に各周
期で一定したスペクトルが出なければ、依存性は判定で
きない。スペクトルが一定以上の大きさのものは時間周
期への依存性があると判断する。

【０２２８】（ハ−２）空間依存性 ある属性の属性値又はアプリケーションの選択された空
間を空間リスト上で記録する。ここで、空間リストと
は、駅前、飛行機内、レストラン、自動車内、公園、オ
フィス、・・・といった場所のカテゴリリスト、ＧＰＳ
情報などから得られる位置情報リスト、あるいは、地名
リストに相当する。特定の個人に依存しない空間依存性
は、多数のユーザからのプロファイルや依存性要因の計
測情報を集計して容易に作成できる。これによって、場
所に付随して起動されるアプリケーションを予測するこ
とができる。

【０２２９】また、カテゴリ別の空間リストを元に集計
した空間依存性を用いると、物理的に異なる未知の空間
でも、すでに依存特性が獲得されているカテゴリの空間
であれば、あるアプリケーションプログラムへの要求度
が高いかどうかを十分な計測データが集計される以前に
予測できる。

【０２３０】（ハ−３）場面への依存性 場面への依存性は、上述した時間や空間を含む様々な状
況情報の組み合わせとして定義される。上述した依存性
要因には状況情報も含まれるので、依存性要因の多元的
組み合わせとして場面を表現できる。ただし、ユーザの
ためのシステム制御の観点から見た場合、意味のある場
面の数は、複数の依存性要因のランダムな組み合わせに
比べて、はるかに少ないと考えられる。したがって、定
型的な場面は独立した依存性要因として定義するほうが
効率的である。

【０２３１】また、このような場面への依存性は、全く
ブランクの状態から学習させるのではなく、予めユーザ
やシステム開発者の手で入力しておくほうが使いやす
い。したがって現在ある場面定義に対して新たな場面の
追加や修正を半自動的に行える機能が必要である。これ
は依存性テーブル５０ａ上で最終的に実行されたアプリ
ケーションに対応する依存ベクトルを記録しておき、ク
ラスタリングした後に、クラスタ中に含まれるベクトル
数が多いもの（発生頻度の高い場面）を記号化して登録
しておくことにより達成される。

【０２３２】（ニ）応用例 上記第１実施例の制御情報出力装置１は、家庭用電気器
具を対象機器７０とする場合を含めて説明した。また、
上記第２実施例では、検索システムとしての構成を示
し、ナビゲーション装置あるいは携帯情報端末としてユ
ーザ端末１００が構成できることを示した。

【０２３３】さらに、例えば車両内に実施例の制御情報
出力装置１（ユーザ端末１００）が搭載された場合を含
め、制御情報（依存情報）を用いた制御動作の応用例を
以下に述べる。 （ニ−１）ユーザカスタマイズ ユーザの好みに応じて景観スポットのメニューを表示
する。

【０２３４】ユーザの好みに応じたインターネットホ
ームページを検索する。 ユーザの生活する地域に応じた情報検索を実行する。 ディスプレイ上で状況に応じたキー配置やメニュー構
成を提供する。 （ニ−２）表示形態の制御 時間帯でポップアップメニューを変更する。

【０２３５】通信する相手に応じて通信データ形式を
変更する。 運転状況、周囲環境に応じて画面構成を適応的に変更
する。 （ニ−３）音声出力の制御 交差点に近づいたり、あるいは、低速走行になったり
したときは自動的にボリュームを下げる。

【０２３６】状況に応じて音を鳴らさない構成を提供
する。例えばコンサートホール内という状況を判断して
着信音を鳴らさないという具合である。音を鳴らすとい
うアプリケーションプログラムへの要求度は、場所への
依存性が高いためである。 （ニ−４）モーダルの変更 音声応答が不適当の場合は画像や文字で表示する。

【０２３７】画像や文字が不適当な場合は音声で伝達
する。 音声のみでは不十分の場合は画像・文字を同時に表示
する。 画像・文字のみで不十分な場合は音声を併用する。 （ニ−５）通信環境の適応化 例えば、上記第２実施例中で説明した図２０中のＳ１１
００〜Ｓ１１６０では、検索されたコンテンツに合わせ
て要約動作の有無や符号化方式を決定して配信処理を行
っている。データ検索の効率化を達成するには、検索面
だけでなく通信面も含めて考える必要がある。つまり、
通信環境の適応化を行う必要がある。

【０２３８】通信システムの適合性 あるコンテンツＣｌにとって最適な通信環境は依存性要
因Ｘｋに依存する。したがって、例えば、ある局面（端
末の移動速度、場所、チャネルビットレート）における
通信システムの適合性の評価を行うことができる。具体
的には、複数システムについて評価を実施し、最適なも
のを選択したり、単一システムについて評価を実施し、
最適なパラメータを推定したりすることができる。

【０２３９】通信システムの選択 トンネルなどで通信が切れやすい状況では通信検索から
ローカルメディア検索または路車間通信などに切り替え
る。ここで、この通信制御アプリケーションの要求度は
場所、移動速度、天候などに対して依存性が高いと判断
できる。すなわち、山が多くてトンネルや斜面の影響で
電波がとぎれやすい場所ではこの通信制御アプリケーシ
ョンの重要性が高まる。また、場所に応じて高速ダウン
ロードできる基地局を移動端末に割り当てる。さらに、
複数の通信路が使用可能である場合、コストテーブルに
基づき、もっとも低価格の通信路を選択する。

【０２４０】適応通信システム概要 適応通信システムの概要を図２９に示した。図２９に
は、ユーザ環境・端末環境、メディア環境、通信環境と
いう３つの環境を統合的に判断し、制御対象を制御する
適応通信システムを示した。

【０２４１】ユーザ・端末環境には、時間、場所、移動
速度、周囲の渋滞状況、予定経路、ドライバー／非ドラ
イバーの区別、希望するアプリケーション、要求コンテ
ンツの内容・品質、ユーザの要求コスト、要求の緊急度
などが含まれる。また、メディア環境には、人気度・ア
クセス集中度、サイトの種類、ジャンル、映像・音楽・
文字・データの区別、記述形式、データ量などが含まれ
る。また、通信環境には、選択可能な通信レート、トラ
フィックの混み具合などが含まれる。このような種々の
環境に基づき、適応通信システムは、伝送時期、伝送場
所、通信システム、通信レート、通信方式、通信プロト
コル・暗号化手段、通信プロファイル形式、多重化方
法、検索・フィルタリング・処理方式、記述方式・符号
化方式を制御する。

【０２４２】従来の技術によっては、このような種々の
環境を総括的に捉えることは容易でない。ところが、依
存性という概念の導入によって、３つの環境を総括的に
捉えることができ、適切な通信制御が可能になるのであ
る。これは環境と表現される種々の要因を依存性で普遍
的に記述できることを意味する。そして、この環境は、
本実施例で示したようなアプリケーションという概念に
よって具体化できるのである。

【図面の簡単な説明】

【図１】第１実施例の制御情報出力装置の構成を示すブ
ロック図である。

【図２】制御情報出力装置における制御部の機能ブロッ
ク図である。

【図３】依存性テーブルを例示する説明図である。

【図４】依存特性を例示する説明図である。

【図５】制御情報出力処理を示すフローチャートであ
る。

【図６】依存性テーブルに基づく探索処理を示すための
説明図である。

【図７】依存性テーブルに基づく探索処理を示すための
説明図である。

【図８】対象機器側処理を示すフローチャートである。

【図９】制御情報出力装置を用いたシステム構成例を示
す説明図である。

【図10】第２実施例の検索システムの構成を示すブロッ
ク図である。

【図11】検索処理の概要を示す説明図である。

【図12】コンテンツ登録処理を示すフローチャートであ
る。

【図13】問い合わせ処理を示すフローチャートである。

【図14】検索処理を示すフローチャートである。

【図15】依存性要因値に対応する依存具合の表現手法を
示す説明図である。

【図16】ＤＣ管理テーブルによる依存性符号の再利用を
示す説明図である。

【図17】１次検索処理の前半部分を示すフローチャート
である。

【図18】１次検索処理の後半部分を示すフローチャート
である。

【図19】２次検索処理の前半部分を示すフローチャート
である。

【図20】２次検索処理の後半部分を示すフローチャート
である。

【図21】コンテンツ評価処理を示すフローチャートであ
る。

【図22】シーン時間とシーンへの要求度との関係を示す
説明図である。

【図23】シーンのアプリケーションと属性との関係を示
す説明図である。

【図24】コンテンツ追加処理を示すフローチャートであ
る。

【図25】車両情報機器における依存性要因を例示した説
明図である。

【図26】検索処理の変形例を示すフローチャートであ
る。

【図27】検索処理の別変形例の前半部分を示すフローチ
ャートである。

【図28】検索処理の別変形例の後半部分を示すフローチ
ャートである。

【図29】応用例としての適応通信システムの概要を示す
説明図である。

【符号の説明】

１…制御情報出力装置 １０…制御部 １１…アプリケーション情報生成ブロック １２…依存性情報生成ブロック １３…制御情報生成ブロック １４…符号化ブロック ２０…入力部 ３０…状況取得部 ４０…出力部 ５０…メモリ部 ５０ａ…依存性テーブル ５０ｂ…依存特性情報 ５０ｃ…従属性テーブル ６０…表示部 ７０…対象機器 ７１…制御装置 １００…ユーザ端末 ２００…サーバ装置 １１０，２１０…制御部 １２０，２２０…入力部 １３０，２３０…状況取得部 １４０，２４０…通信部 １５０，２５０…メモリ部 １５０ａ，２５０ａ…依存性テーブル １５０ｂ，２５０ｂ…依存特性情報 １５０ｃ，２５０ｃ…量子化テーブル １６０…表示部 １７０…問い合わせ情報生成部 １８０…アプリケーション ２６０…情報出力部 ２７０…検索情報生成部 ２８１…コンテンツリスト ２８２…コンテンツデータベース ２９０…評価関数計算部 ２９１…検索リスト記憶部

Claims (46)

【特許請求の範囲】
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. 【請求項３２】予め定められた依存性要因に依存するか
    否かを示す依存情報を記憶する記憶手段と、前記記憶手
    段に記憶された依存情報に基づき制御情報を出力する制
    御情報出力手段とを有した制御情報出力装置と、 前記制御情報出力手段によって出力される前記制御情報
    を利用して、アプリケーションの検索を行う検索手段を
    有したサーバ装置とを備えていることを特徴とする情報
    システム。
33. 【請求項３３】請求項３２に記載の情報システムにおい
    て、 前記制御情報出力装置又は前記サーバ装置の少なくとも
    いずれか一方は、前記依存性要因のとり得る依存性要因
    値を量子化可能であることを特徴とする情報システム。
34. 【請求項３４】請求項３２又は３３に記載の情報システ
    ムにおいて、 前記サーバ装置は、前記アプリケーションが予め定めら
    れた依存性要因に依存するか否かを示すアプリ依存情報
    を記憶するサーバ側記憶手段を有しており、 前記検索手段は、前記サーバ側記憶手段に記憶された前
    記アプリ依存情報に基づく検索を行うことを特徴とする
    情報システム。
35. 【請求項３５】請求項３４に記載の情報システムにおい
    て、 前記制御情報には、前記依存性要因に依存するか否かを
    示す依存ベクトルがユーザ要求として含まれ、 一方、前記アプリ依存情報には、検索に係る依存性要因
    に前記アプリケーションが依存するか否かを示す特性ベ
    クトルが含まれており、 前記検索手段は、前記依存ベクトルと前記特性ベクトル
    との内積演算によって検索を行うことを特徴とする情報
    システム。
36. 【請求項３６】請求項３５に記載の情報システムにおい
    て、 前記特性ベクトルは、前記アプリケーションの詳細デー
    タから生成可能としたことを特徴とする情報システム。
37. 【請求項３７】請求項３６に記載の情報システムにおい
    て、 前記アプリケーションの詳細データから生成された特性
    ベクトルは、前記サーバ側記憶手段に追加記憶されて再
    利用されることを特徴とする情報システム。
38. 【請求項３８】請求項３５〜３７のいずれかに記載の情
    報システムにおいて、 前記依存ベクトル及び前記特性ベクトルは、依存の度合
    いである依存度も表現可能としたことを特徴とする情報
    システム。
39. 【請求項３９】請求項３５〜３８のいずれかに記載の情
    報システムにおいて、 前記依存ベクトル及び前記特性ベクトルの成分は、依存
    性要因のとり得る依存性要因値に対する依存具合を表現
    可能にしたことを特徴とする情報システム。
40. 【請求項４０】請求項３５〜３７のいずれかに記載の情
    報システムにおいて、 前記依存ベクトル及び前記特性ベクトルは、その成分が
    「０」又は「１」の２値で表現される依存性符号として
    実現されていることを特徴とする情報システム。
41. 【請求項４１】請求項３５〜４０のいずれかに記載の情
    報システムにおいて、 前記内積演算では、前記検索に係る依存性要因の中の所
    定要因に対する成分のみの演算を行うことを特徴とする
    情報システム。
42. 【請求項４２】請求項３５〜４１のいずれかに記載の情
    報システムにおいて、 前記内積演算では、前記検索に係る依存性要因に対する
    成分に優先順位を付けて計算し、各成分毎に予め定めら
    れた基準を満たさない場合、演算を途中で停止すること
    を特徴とする情報システム。
43. 【請求項４３】請求項３５〜４２のいずれかに記載の情
    報システムにおいて、 前記検索手段は、前記内積演算による１次検索に続け
    て、前記アプリケーションの詳細データに基づく２次検
    索を行うことを特徴とする情報システム。
44. 【請求項４４】ユーザ側で予め定められた依存性要因に
    依存するか否かを示すユーザ側依存情報によってユーザ
    側のアプリケーションを表現し、前記ユーザ側依存情報
    に基づき制御情報を出力する制御情報出力装置と、 サーバ側で予め定められた依存性要因に依存するか否か
    を示すサーバ側依存情報によってサーバ側のアプリケー
    ションを表現し、前記制御情報に基づき、前記ユーザ側
    のアプリケーションと前記サーバ側のアプリケーション
    とを関連付けて動作するサーバ装置とを備えたことを特
    徴とする情報システム。
45. 【請求項４５】請求項４４に記載の情報システムにおい
    て、 前記ユーザ側依存情報及び前記サーバ側依存情報は、ベ
    クトル成分が「０」又は「１」の２値で表現される依存
    性符号として実現されていることを特徴とする情報シス
    テム。
46. 【請求項４６】請求項４４又は４５に記載の情報システ
    ムにおいて、 前記サーバ側依存情報は、前記アプリケーションの追加
    時点で入力される情報を用い、アプリケーションを特定
    する言語表現と前記サーバ側依存情報との対応関係テー
    ブルに基づき生成されることを特徴とする情報システ
    ム。