(57)【特許請求の範囲】
【請求項１】
接続される装置の情報を取得する装置管理部と、
前記装置管理部が取得した前記情報を履歴として記憶する履歴データベースと、
前記接続される装置の前記情報と、前記履歴データベースが記憶する前記履歴とに基づき、ユーザに提示する機能を推定する機能推定部と、
前記機能推定部により推定された前記機能に対応する利用可否の判定条件に基づき、前記機能の利用可否を判断する利用可否判定部と、
前記利用可否判定部が、前記機能推定部により推定された前記機能が利用可能であると判断した場合に、推定された前記機能をユーザに提示する出力部とを備えた
ことを特徴とする情報提供装置。
【請求項２】
前記利用可否判定部は、前記機能推定部が推定した機能に関する情報のみに基づき、利用可否を判断することを特徴とする請求項１記載の情報提供装置。
【請求項３】
前記機能推定部は、
前記ユーザの目的を推定する目的推定部と、
前記目的推定部が推定した目的に対応する機能を選定する機能選定部とを備えた
ことを特徴とする請求項１記載の情報提供装置。
【請求項４】
前記機能選定部は、目的と機能が対応づけられた機能候補テーブルに基づき、前記目的推定部が推定した前記目的に対応する前記機能を選定する
ことを特徴とする請求項３記載の情報提供装置。
【請求項５】
前記機能選定部は、前記履歴データベースが記憶している前記履歴に基づき、前記目的推定部が推定した前記目的に対応する前記機能を選定する
ことを特徴とする請求項３記載の情報提供装置。
【請求項６】
前記機能推定部は、前記推定した機能について、前記利用可否判定部が利用不可能であると判断した場合に、前記機能を利用できない旨の通知を前記出力部に出力させる
ことを特徴とする請求項１記載の情報提供装置。
【請求項７】
前記機能推定部は、前記推定した機能について、前記利用可否判定部が利用不可能であると判断した場合に、前記機能を利用できない旨の通知を前記出力部に出力させ、再度前記利用可否判定部に対して前記機能の利用可否判定を行なうよう要求し、前記利用可否判定部が、前記機能が利用可能になったと判断すると、前記機能が利用可能となった旨の通知を前記出力部に出力させる
ことを特徴とする請求項１記載の情報提供装置。
【請求項８】
コンピュータに、
接続される装置の情報を取得し、
前記接続される装置の前記情報と、前記情報を履歴として記憶する履歴データベースの前記履歴とに基づき、ユーザに提示する機能を推定し、
推定された前記機能に対応する利用可否の判定条件に基づき、前記機能の利用可否を判断し、利用可能であると判断した場合に、推定された前記機能を前記ユーザに提示する機能として出力する
処理を実行させるための情報提供プログラム。
【請求項９】
車載装置から前記車載装置に接続される装置の情報を取得する通信部と、
前記通信部が取得した前記情報を履歴として記憶する履歴データベースと、
前記通信部が取得した前記情報と、前記履歴データベースが記憶している前記履歴とに基づき、ユーザに提示する機能を推定する機能推定部と、
前記機能推定部により推定された前記機能に対応する利用可否の判定条件に基づき、前記機能の利用可否を判断する利用可否判定部とを備え、
前記利用可否判定部が前記機能を利用可能であると判断した場合に、当該機能をユーザに提示する機能とする
ことを特徴とする情報提供サーバ。
【請求項１０】
通信部が、車載装置から前記車載装置に接続される装置の情報を取得するステップと、
機能推定部が、前記通信部が取得した前記情報と、前記通信部が取得した前記情報を履歴として記憶する履歴データベースの前記履歴とに基づき、ユーザに提示する機能を推定するステップと、
利用可否判定部が、前記機能推定部により推定された前記機能に対応する利用可否の判定条件に基づき、前記機能の利用可否を判断するステップと、
出力部が、前記利用可否判定部が前記機能を利用可能であると判断した場合に、当該機能をユーザに提示するステップ
とを備えた情報提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ユーザの目的を推定し、当該操作目的を実現する機能をユーザに提供する情報提供装置に関するものである。
【背景技術】
【０００２】
従来、この種の機器としては、予め登録された機能を提供する情報提供装置がある。この情報提供装置によれば、ユーザが好む機能を予め登録し、当該登録機能をユーザが選択することで、頻繁に利用する機能を実現できる。【０００３】
例えば、特許文献１には、ユーザの目的に応じてユーザの嗜好を満足させる情報提供装置が開示されている。当該装置では、走行履歴に基づき、ある状況下におけるユーザの目的を推定する。そして、提供する可能性のある機能に関する情報を全て取得し、推定したユーザの目的に応じた走行履歴情報を取得する。その後、推定されたユーザの目的に対応する操作履歴に基づき、提供する可能性のある機能から不要な機能を削除し、提示する機能を作成している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−１０８８６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１に開示されたような従来の情報提供装置では、提供する可能性のある機能に関する情報を全て取得しており、これらの情報を取得するための処理負担への考慮はない。従って、ユーザに提供する機能候補が少ない場合や、それらのユーザに提供する機能に関する情報が少ない場合においてはこれでもよいが、提供する可能性のある機能候補が数多く存在するケースや、各機能候補に関連する情報が数多く存在するケースにおいては、それらの情報を抽出する処理や、そこから不要な情報や機能を削除する処理には、いずれも時間を要してしまうという課題があった。【０００６】
例えば、自車周辺の施設からユーザが所望する施設を提示するケースを考えてみる。自車周辺に存在するガソリンスタンドの任意の店舗ブランドを検索して取得するだけでも、多くの処理時間を要する。しかし、実際の施設種類はガソリンスタンド以外にも数多くあり、自車が進むたびに、自車周辺のそれら各施設の情報を全て取得するには、膨大な処理時間を要してしまう。
このため、時々刻々と変化する車の状況に応じて、タイミングよく機能を提示することは困難となる。【０００７】
また、特許文献１においては、提供する可能性のある機能に関する情報の中に、ユーザの目的に対応する情報が含まれていないケースへの言及がない。そのため、ユーザの目的に対応する情報が存在しないとき、どのような機能をユーザに提示するのかについては配慮されていないという課題があった。【０００８】
この発明は上記従来の課題を解決するためになされたもので、ユーザの操作目的を推定し、当該操作目的を実現する機能をユーザに提供する情報提供装置において、効率よくユーザに機能を提供する。
【課題を解決するための手段】
【０００９】
この発明に係る情報提供装置は、接続される装置の情報を取得する装置管理部と、前記装置管理部が取得した前記情報を履歴として記憶する履歴データベースと、前記接続される装置の前記情報と、前記履歴データベースが記憶する前記履歴とに基づき、ユーザに提示する機能を推定する機能推定部と、機能推定部により推定された前記機能に対応する利用可否の判定条件に基づき、前記機能の利用可否を判断する利用可否判定部と、前記利用可否判定部が、前記機能推定部により推定された前記機能が利用可能であると判断した場合に、推定された前記機能をユーザに提示する出力部とを備えたことを特徴とするものである。
【発明の効果】
【００１０】
この発明によれば、ユーザの目的を推定し、当該操作目的を実現する機能をユーザに提供する情報提供装置において、ユーザが所望する機能に関連する情報が膨大に存在する場合であっても効率的な処理が可能となり、時々刻々と変化する車両の状況の変化に応じて、タイミングよく機能を提示することができるという効果がある。
【図面の簡単な説明】
【００１１】
【図１】この発明の実施の形態１に係る情報提供装置の要部の構成を示すブロック図である。
【図２】実施の形態１に係る情報提供装置の主要な動作を説明するためのフローチャートである。
【図３】装置管理部が取得する情報の一例を示す図である。
【図４】実施の形態１の機能推定部および利用可否判定部による候補機能の選定とその利用可否判定の詳細な動作を説明するフローチャートである。
【図５】機能推定部が予め用意し記憶している機能候補のテーブルの一例を示す図である。
【図６】実施の形態１の利用可能判定部による機能候補の利用可否の判定の動作のフローチャートである。
【図７】各機能候補に対応する装置および必要情報の一例を表す図である。
【図８】各機構候補に対しての利用条件を定めた判定基準の一例を示す図である。
【図９】この発明の実施の形態２に係る情報提供装置の要部の構成を示すブロック図である。
【図１０】実施の形態２に係る情報提供装置の主要な動作を説明するためのフローチャートである。
【図１１】実施の形態２の機能選定部および利用可否判定部による候補機能の選定とその利用可否判定の詳細な動作を説明するフローチャートである。
【図１２】目的推定部から取得する推定結果の一例を示す図である。
【図１３】機能選定部が予め用意し記憶しているテーブルの一例を示す図である。
【図１４】実施の形態３の機能推定部および利用可否判定部による候補機能の選定とその利用可否判定の詳細な動作を説明するフローチャートである。
【図１５】実施の形態４の機能推定部および利用可否判定部による候補機能の選定とその利用可否判定の詳細な動作を説明するフローチャートである。
【図１６】利用不可能と判断された機能候補がその後利用可能になるかどうかを監視する動作を説明するフローチャートである。
【図１７】実施の形態５におけるナビゲーションシステムの概要を示す図である。
【発明を実施するための形態】
【００１２】
以下、この発明の実施の形態について、図面を参照しながら詳細に説明する。
実施の形態１．
図１は、この発明の実施の形態１に係る情報提供装置の要部の構成を示すブロック図である。
図１に示すように、情報提供装置は、カーナビゲーションシステムや、車両や、エアコンや、携帯電話などの装置と接続され、装置管理部１と履歴データベース２と機能推定部７と利用可否判定部５と出力部６とを備えている。
【００１３】
装置管理部１は、情報提供装置に接続されたカーナビゲーションシステムや、車両や、エアコンや、携帯電話などの装置から情報を取得し、装置の情報を管理する。また、取得した装置の情報から、装置の稼働環境等の状態が変わったことを検知する。履歴データベース２は、装置管理部１が情報提供装置に接続された装置から取得した情報を履歴として記録する。機能推定部７は、履歴データベース２の情報と、装置管理部１が接続されている装置から取得する装置の情報に基づき、その状況下においてユーザに提示すべき機能候補を選定する。利用可否判定部５は、機能推定部７が選定した機能候補の利用可否を判定する。出力部６は、確定した機能を表示画面に表示したり、音声で出力する。
【００１４】
図２は、実施の形態１に係る情報提供装置の主要な動作を説明するためのフローチャートである。
情報提供装置が動作を開始すると、装置管理部１は、接続されている装置から情報を取得する（ステップＳＴ２００）。
例えば、イグニッションやギヤなどの情報を車両から取得し、車内に設置されたカーナビゲーションから操作情報や設定された経路の情報や現在位置周辺の地図情報などを取得し、無線通信回線を通して接続された携帯電話から個人を識別する情報や電話帳などの情報を取得する。
なお、装置管理部１は、ＥＣＵ（Ｅｎｇｉｎｅ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）などの装置を介して、該ＥＣＵに接続された装置からの情報を取得するようにしてもよい。
【００１５】
ついで、装置管理部１は、ステップＳＴ２００において取得した情報を、履歴として履歴データベース２に記録する（ステップＳＴ２０１）。
図３は、装置管理部１が取得する情報の一例を示す図である。図３（Ａ）は、個々の情報に応じたデータ形式を示している。例えば、現在道路の種別は整数でＩＤ番号を付与し、１が一般道、２が国道を示している。また、ルートの有無では１があり、２がなしを示している。図３（Ｂ）は、履歴データベース２が、個々の情報の変化を記録した例である。例えば、日付の２０１３０１０１０８３０１０は２０１３年１月１日８時３０分１０秒を示している。当該時刻はエンジン始動直後であるため、各情報はＮＡとして無効値が記録されている。その後、２０１３０１０１０８３０２０（２０１３年１月１日８時３０分２０秒）に、イグニッションの状態が１となりエンジンが始動されたことが履歴として記録されている。このように時系列に沿って、各々の情報値を記録していく。
【００１６】
なお、このステップＳＴ２０１において、装置管理部１は、ステップＳＴ２００において取得した複数の情報を組み合わせて、新たな情報を生成して履歴データベース２に記録してもよい。例えば、車速とギヤの状態の情報から、車の走行状態を生成するなどである。車の走行状態は車速が０の場合に、ギヤがＰであれば１の駐車とし、ギヤがＤであれば２の停車とするといった具合である。
【００１７】
また、履歴データベース２に相当するデータべースが車両やカーナビゲーションシステムなどの装置に存在していれば、それを流用してもよい。
また、ここでは、履歴データベース２にはすでにある程度の履歴が蓄積されているものとして以下説明するが、予め一般的な情報を履歴として格納しておき、それを利用するようにしてもよい。あるいは、初期段階において履歴データベース２の履歴が十分に蓄積されていない場合は、ある程度の履歴が蓄積されるまでステップＳＴ２００〜ステップＳＴ２０１の処理を繰り返してもよい。
【００１８】
機能推定部７は、履歴データベース２の情報と、装置管理部１がステップＳＴ２００で取得した、接続されている装置の情報とに基づき、ユーザに提示すべき機能候補を推定する（ステップＳＴ２０２）。推定した機能候補は、利用可否判定部５に出力する。
具体的には、機能推定部７は、まず、履歴データベース２の情報と、装置管理部１がステップＳＴ２００で取得した装置の情報から、その状況下におけるユーザの機能候補を推定する。
【００１９】
その後、利用可否判定部５は、ステップＳＴ２０２において機能推定部７から取得した機能候補に対応する情報を装置管理部１から取得し、ステップＳＴ２０２において機能推定部７が選定した機能候補の利用可否を判定する（ステップＳＴ２０３）。具体的には、利用可否判定部５は、まず、機能推定部７から取得した機能候補に対応する情報を装置管理部１に要求する。装置管理部１は、利用可否判定部５の要求に基づき、接続された装置から必要な情報を取得し、取得した情報を利用可否判定部５に出力する。利用可否判定部５は、取得した情報に基づき、機能推定部７から取得した機能について、利用可否を判定し、その結果を機能推定部７に出力する。
【００２０】
続いて、機能推定部７は、ステップＳＴ２０３において利用可否判定部５から取得した利用可否結果に基づき、ユーザに提示すべき機能を決定し、それを出力部６に出力する（ステップＳＴ２０４）。
出力部６は、ステップＳＴ２０４において機能推定部７から取得した内容に応じて、画面表示あるいは音声で出力し（ステップＳＴ２０５）、動作は終了する。
【００２１】
図４は、機能推定部７および利用可否判定部５による候補機能の選定とその利用可否判定の詳細な動作を説明するフローチャートである。具体的には、図２のステップＳＴ２０２からステップＳＴ２０４の処理を詳しく説明したものである。
機能推定部７は、履歴データベース２の情報と、装置管理部１が取得した、接続されている装置の情報に基づき、機能候補を推定し、それらの確率を算出する（ステップＳＴ４００）。
なお、確からしさの度合いの算出には、周知の方法、例えば、ベイズの定理などの条件つき確率を用いればよいし、これに限定するものではない。
【００２２】
図５は、機能推定部７が予め用意し記憶している機能候補のテーブルの一例を示す図である。また、機能推定部７が算出した確率を付与して記載している。図５に示すように、例えば、「周辺検索、１ｋｍ以内、コンビニ」という機能候補の確率は８６％といった具合に、ユーザが所望している確率がそれぞれの機能候補に対して算出される。なお、以降の説明においては、図５で省略したＮＯ．９以降の機能候補の確率が３０％を下回る機能候補のみであるとする。
【００２３】
また、選定される機能とは、「周辺検索」という機能そのものと「１ｋｍ以内」といった機能を実行する際のパラメータを用いて表現されるケースもあるが、図５のＮＯ．６「エアコンＯＦＦ」のように、パラメータを付与しないケースも存在する。
【００２４】
図４のフローに戻る。
機能推定部７は、ステップＳＴ４００で算出した確率のうち、最も確率の高い機能候補を選定する（ステップＳＴ４０１）。例えば、図５の推定結果の例においては、「周辺検索、１ｋｍ以内、コンビニ」という機能候補の確率が８６％と最も高いため、「周辺検索、１ｋｍ以内、コンビニ」という機能候補が利用可否判定を行う対象として選ばれる。
なお、機能候補の確率が同じである場合（例えば図５の「ルート全体像表示、文字リストで表示」と「次の案内地点表示、地図で表示」）、履歴データベースの操作履歴を参照し、操作頻度が最も高い機能候補を選定するようにしてもよいし、任意の一つを選定するようにしてもよい。
【００２５】
また、ステップＳＴ４０１の処理について、後述するステップＳＴ４０４から遷移する場合は、利用可否判定を行った機能候補を除いた機能候補の中で、最も確率の高い機能候補が利用可否判定を行う対象として選択される。例えば、既に「周辺検索、１ｋｍ以内、コンビニ」という機能候補に対しての利用可否判定が行われているのであれば、次に確率の高い「ＦＭを開始、○△」という機能候補について利用可否判定を行う。
【００２６】
機能推定部７は、最も確率の高い機能候補を利用可否判定部５に出力し、選定した機能候補の利用可否判定を要求する（ステップＳＴ４０２）。
例えば、図５の例において最も確率の高かった「周辺検索、１ｋｍ以内、コンビニ」という機能候補を利用可否判定部５に出力する。
このようにすることで、最も確率の高い機能候補が利用できないケースに対応することが可能となり、ユーザに対して不適切な機能提示が行われないようにすることができる。また、全ての機能候補を判定せず、確率の高い機能候補から判定に進むため、効率的な処理が可能となる。
【００２７】
利用可否判定部５は、ステップＳＴ４０２において機能選定部４から取得した機能候補の利用可否の判定を行う（ステップＳＴ４０３）。
ここで、図６は、利用可能判定部５による機能候補の利用可否の判定の動作のフローチャートである。利用可能判定部５の動作について、図６を用いて詳細に説明する。
なお、図６は、図２のステップＳＴ２０３および図４のステップＳＴ４０３に相当し、それらの処理を詳しく説明したものである。
利用可否判定部５は、機能推定部７から判定すべき機能候補を取得する（ステップＳＴ７００）と、取得した機能候補を有する装置を特定し、装置管理部１に対して、取得した機能候補に関する情報を要求する（ステップＳＴ７０１）。
【００２８】
具体的には、利用可否判定部５は、図７に示すような、各機能候補とそれに対応する装置、および、必要な情報を定めた情報を記憶しており、この情報を参照して取得した機能候補に対応する装置と必要情報を特定し、装置管理部１に対して特定した必要情報を収集するよう要求する。
例えば、機能推定部７から取得した機能候補が「周辺検索、１ｋｍ以内、コンビニ」である場合、利用可否判定部５は、該当装置はカーナビゲーションシステムであり、必要情報は検索結果であると特定し、装置管理部１に対して、カーナビゲーションシステムに１ｋｍ以内に存在するコンビニの周辺検索結果の情報を提供するよう要求する。
【００２９】
なお、この発明に係る情報提供装置が制御する装置が１つであるならば、各機能候補に対応する必要情報だけ定めておけばよい。さらに、１つの機能が複数の装置から構成されるケースや、１つの機能に複数の必要情報が存在するような場合は、それぞれの装置とそれぞれの必要情報を定めておけばよい。
また、機能候補が常に利用可能である場合には、必要情報を「なし」としておけば良い。つまり、後述の利用可否判断に必要な情報を厳選して定めておけばよく、このようにすることで、効率的な処理が可能となる。
【００３０】
装置管理部１は、ステップＳＴ７０１において利用可否判定部５から要求された機能候補に関する情報を各該当の装置から取得し、取得した結果を利用可否判定部５に出力する（ステップＳＴ７０２）。
例えば、対象とする装置がカーナビゲーションシステムで、判定対象の機能候補が「周辺検索、１ｋｍ以内、コンビニ」である場合、装置管理部１は、ステップＳＴ７０１における利用可否判定部５からの要求に基づき、カーナビゲーションシステムに対して、１ｋｍ以内に存在するコンビニの周辺検索を要請し、検索結果の情報を利用可否判定部５に出力する。
【００３１】
他の例としては、対象とする装置がカーナビゲーションシステムで、判定対象の機能候補が「ＦＭを開始、○△」である場合、装置管理部１は、ステップＳＴ７０１における利用可否判定部５からの要求に基づき、カーナビゲーションシステムに対して、ＦＭの電波受信状態、設定されている局の状態、ＦＭのＯＮ／ＯＦＦ状態について、それらの状態がどうなっているのかを調べるよう要請し、得られた状態の情報を利用可否判定部５に出力する。
さらに他の例としては、対象とする装置が車両あるいは車両そのものを制御する装置で、判定対象の機能が「オートクルーズをＯＮにする」である場合、装置管理部１は、ステップＳＴ７０１における利用可否判定部５からの要求に基づき、車両あるいは車両を制御する装置に対して、オートクルーズの設定状態について、それがどのような状態であるのかを調べるよう要請し、得られた状態の情報を利用可否判定部５に出力する。
【００３２】
なお、この実施の形態１においては、装置管理部１を経由して該当する装置の該当する機能に関する情報を取得するようにしているが、これに限定するものではない。例えば、利用可否判定部５が該当の装置に対して直接接続し、該当の装置の該当の機能に関する情報を取得するよう構成しても同様の効果が得られる。
【００３３】
また、このステップＳＴ７０２の処理はユーザがその結果を目にするものではなく、利用可否を判定する対象の機能候補に関する情報を取得するために、内部で処理するものである。そのため、このステップＳＴ７０２の処理に要する負荷が少ないことが求められる。例えば、カーナビゲーションシステムは現在位置の算出、ルート案内、渋滞情報の更新など、カーナビゲーションシステムが行う必要のある動作を数多く処理している。一方、ユーザに提供する機能として目的地設定を扱う場合、ガソリンスタンドやコンビニやファミリーレストランや観光地など多種多様な施設に関する情報が関係する。一度にこれらの情報を全て取得しようとすれば、現在位置の算出、ルート案内、渋滞情報の更新などの処理が遅延することが想定される。
【００３４】
あるいは、機能推定に最低限必要な情報のみを取得してユーザの機能推定を行っても、その後、機能推定の結果に関連しない多種多様な施設に関する情報を全て取得するように構成しても課題となる。例えば、機能推定に必要な情報のみを取得して機能推定を行い、その結果としてコンビニに行くことが推定された後、コンビニだけではなくガソリンスタンドやファミリーレストランなどを全て取得すれば、その処理に要する負担は大きい。
【００３５】
つまり、提供する可能性のある機能候補が多くなるほど、あるいは各機能候補に関連する情報が多くなるほど、それらの情報を取得することが課題となる。そのため、この実施の形態１のように機能推定に必要な情報のみを取得してユーザの機能候補を推定するよう構成することで、処理の負担を軽減することが可能となる。
【００３６】
ステップＳＴ７０２において、装置管理部１から必要な情報を取得すると、利用可否判定部５は、装置管理部１から取得した情報について、予め用意し記憶している判定基準に基づき、該当の機能、つまり、機能推定部７が特定した機能候補の利用可否を判定する（ステップＳＴ７０３）。
図８は、各機能候補に対しての利用条件を定めた判定基準の一例を示す図である。利用可否判定部５は、ステップＳＴ７０２で装置管理部１から取得した情報について、図８に示すような判定基準に基づいてその利用可否を判定する。
【００３７】
例えば、機能候補が「周辺検索、１ｋｍ以内、コンビニ」である時に、ステップＳＴ７０２で装置管理部１から取得した情報にコンビニが存在していなければ利用不可と判断し、コンビニが存在している場合は利用可と判断する。また、機能候補が常に利用可能である場合には、当該機能候補の判定基準を「なし」としておけばよい。
なお、ここでは、判定基準を利用可否判定部５が予め記憶しているものとしているが、判定基準を、情報提供装置と接続した外部のサーバに用意し、利用可否判定部５が、外部のサーバから取得しても同様の処理は実現できる。
【００３８】
このようにすることで、推定した機能が、現在利用可能であるのか、あるいは、既に利用されているのかを確認することが可能となる。つまり、ユーザが利用可能な機能、あるいはまだ利用していない機能のみをユーザに提示することが可能となる。
逆に、推定した機能をそのままユーザに提示する場合、その状況では利用できない機能が提示されるケースが起こりえてしまう。例えば、自車位置の近くにコンビニが存在しないにも関わらず、近くのコンビニに行くことが推定され、それを実現する機能をユーザに提示する場合を考えてみる。この場合、当該機能をユーザが選択した際には、自車位置から遠方に存在するコンビニが提示されるかもしれず、ユーザの意図に合致しないものとなってしまう。あるいは、近くにはコンビニが存在しないことが、ユーザが当該機能を選択してから初めてユーザに知らされることになり得る。
【００３９】
いずれにしても、これらの例では、ユーザの利便性が損なわれてしまう。そのため、この実施の形態１のように、利用可能な機能のみが提示されることが有効となる。
なお、利用可否の判断が可能な情報を含めて、多種多様な多くの情報を、機能推定を行う前に予め抽出し、それに基づき、利用可能な機能に絞り込まれるように機能推定が行われるようにすることも考えられる。しかしこの場合、一度に多くの情報を取得する必要があり、前述した通り、処理の負担が課題となる。
【００４０】
最後に、ステップＳＴ７０４にて、利用可否判定部５は、ステップＳＴ７０３における利用可否の判定結果を機能推定部７に出力して（ステップＳＴ７０４）、取得した機能候補の利用可否の判定の処理は終了する。すなわち、図２のステップＳＴ２０３，図４におけるステップＳＴ４０３の処理が終了したことになる。
【００４１】
このように、ステップＳＴ４０３の利用可否の判定（図６のステップＳＴ７０１〜ステップＳＴ７０４）では、利用可否を判定する機能候補についてのみの所定情報を取得し、その情報が利用可否条件に合致するか検証している。
つまり、ステップＳＴ４０３（図６のステップＳＴ７０１〜ステップＳＴ７０４）では、ステップＳＴ４０１で選定した最も確率の高い機能候補に対してのみ利用可否判定を行うこととしている。
【００４２】
目的地設定機能を提供する場合を例にとれば、目的地となり得る全ての施設に関する情報を取得し、それらの利用可能であるかを検証するのではなく、提供する可能性の高い施設に絞って関連情報を取得し、利用可否を判定している。
そのため、処理負担の少ない方法であるとともに、ユーザが利用可能な機能、あるいはまだ利用していない機能のみをユーザに提示することが可能となる。
【００４３】
再び図４の説明に戻る。
ステップＳＴ４０３（図６のステップＳＴ７０１〜ステップＳＴ７０４）に続き、機能推定部７は、ステップＳＴ４０３の利用可否判定部５の判定結果を取得し、機能候補が利用可能かどうかの判定を行なう（ステップＳＴ４０４）。ステップＳＴ４０４において、「利用不可」と判定された場合（ステップＳＴ４０４の“ＮＯ”の場合）は、ステップＳＴ４０１に戻り、利用可否を判定していない機能候補のうち最も確率の高い機能候補について前述のステップＳＴ４０１〜ステップＳＴ４０３の処理を行う。一方、ステップＳＴ４０４において、「利用可」と判定された場合（ステップＳＴ４０４の“ＹＥＳ”の場合）は、ステップＳＴ４０５に進む。
【００４４】
ステップＳＴ４０４において、機能候補が利用可能であると判定すると、機能推定部７は、利用可能であると判定された機能候補を、ユーザに提示する機能として確定する（ステップＳＴ４０５）。
なお、ユーザに提供する機能を複数個提示する場合には、提示する予定の機能の数がそろうまで、前述のステップＳＴ４００〜ステップＳＴ４０５を実施すればよい。
【００４５】
ステップＳＴ４０５において、機能推定部７がユーザに提示する機能を確定すると、出力部６は、確定された機能を出力する（ステップＳＴ４０６）。具体的には、情報提供装置の画像表示部に、ユーザに確定された機能を表示する。さらに、図示しない入力部を介してユーザが、出力部６に提示された機能を選択すればよい。そして図示しないが、入力部を介してユーザが、出力部６から提示された機能を選択すればよい。
例えば、カーナビゲーションシステムやインスツルメントパネルやヘッドアップディスプレイといった情報提供装置の画像表示部に、確定した機能のうち、ユーザが所望する確率の高い上位３つの機能を表示するようにすることができる。また、その際に、音声により、当該３機能を読み上げてユーザに伝えるなどを加えてもよい。そして、ユーザが入力部を介して、ユーザが所望する機能を選択すればよい。なお、これは一例にすぎず、他の方法でユーザに確定した機能を通知するようにしてもよい。
また、情報提供装置は画像表示部を備えず、出力部６は、外部の表示装置に、画面表示データおよび音声出力データを送信するようにしてもよい。
【００４６】
なお、ここでは、情報提供装置の動作が開始すると、つまり、電源が投入されると、装置管理部１が、接続されている装置から情報を取得して情報提供する機能を選定する処理（図２のステップＳＴ２０２以降の処理）を行なう場合について説明したが、以降、装置管理部１が接続されている装置から情報を取得して、接続されている装置の状態が変わったことを検知した場合に、情報提供する機能を選定する処理（図２のステップＳＴ２０２以降の処理）を行なうようにすればよい。あるいは、任意の時間周期で処理を行なってもよい。
【００４７】
以上のように、実施の形態１によれば、情報提供装置がユーザに提供する機能候補が多い場合、あるいはそれぞれの機能候補に関する情報が膨大となる場合であっても、ユーザが所望する可能性が高い機能、かつ利用可能である機能を厳選してユーザに提供することができる。
【００４８】
つまり、ユーザに提供する機能候補が多い場合、あるいはそれぞれの機能候補に関する情報が膨大となる場合であっても、ユーザが所望する可能性の高い機能に絞って利用可否を判断しているため、効率的な処理が可能となる。これにより、時々刻々と変化する車両の状況の変化に応じて、タイミングよく機能を提示することができる。
さらに、ユーザが所望する可能性の高い機能に絞って利用可否を判断しているため、ユーザが所望する機能に関連する情報を取得するための処理負担が少なく、カーナビゲーション装置などで言えば道案内など、情報提供装置が制御する装置が本来行う動作が安定的に行えるという効果もある。
【００４９】
このように、この発明の実施の形態１に係る情報提供装置は、様々な種類の装置に適用可能であり、ユーザに提供する機能候補が多くなるほど、それぞれの機能候補に関する情報が多くなるほど有効である。また、効率的な処理としつつも、利用可能である機能を確実に提示することが可能となる。
また、後述する実施の形態においても、情報提供装置として車載情報機器を例として記載するが、これに限定するものではない。
【００５０】
実施の形態２．
図９は、この発明の実施の形態２に係る情報提供装置の要部の構成を示すブロック図である。
実施の形態１で図１に示した情報提供装置と同様の構成については重複した説明を省略する。この実施の形態２に係る情報提供装置は、実施の形態１で図１に示した情報提供装置とは、機能推定部７を備えず、目的推定部３と機能選定部４とを備える点のみが異なる。実施の形態１では、機能推定部７が機能選定を行なっていたが、この実施の形態２では、目的推定と機能選定をそれぞれ目的推定部３と機能選定部４で分けて行なう。
以下、実施の形態２における情報提供装置の動作について説明する。なお、実施の形態１と同様の動作については重複した説明を省略する。
【００５１】
図１０は実施の形態２に係る情報提供装置の主要な動作を説明するためのフローチャートである。なお、実施の形態１において図２で示したものと同様のステップについては詳細な説明を省略し、図２と異なるステップについてのみ説明する。
図１０のステップＳＴ２００〜ＳＴ２０１は、図２のステップＳＴ２００〜ステップＳＴ２０１と同様である。
目的推定部３は、履歴データベース２の情報と、装置管理部１がステップＳＴ２００で取得した、接続されている装置の情報に基づき、その状況下におけるユーザの目的候補を推定する（ステップＳＴ２０６）。なお、推定した目的候補には確率あるいは確からしさの度合いを付与する。確からしさの度合いの算出には、周知の方法、例えば、ベイズの定理などの条件つき確率を用いればよいし、これに限定するものではない。
【００５２】
機能選定部４は、目的と機能について、予め用意し、記憶している対応テーブルに基づき、ステップＳＴ２０６において目的推定部３から取得したユーザの目的候補に対応する機能候補を選定する（ステップＳＴ２０７）。そして、選定した機能候補を利用可否判定部５に出力する。なお、機能候補の選定の詳細については後述する。
【００５３】
その後、利用可否判定部５は、ステップＳＴ２０３において機能選定部４から取得した機能候補に対応する情報を装置管理部１から取得し、ステップＳＴ２０７において機能選定部４が選定した機能候補の利用可否を判定する（ステップＳＴ２０３）。具体的な処理は、図２のステップＳＴ２０３と同様である。ステップＳＴ２０３において、利用可否判定部５は、利用可否判定結果を機能選定部４に出力する。
続くステップＳＴ２０４〜ステップＳＴ２０５の処理も、図２のステップＳＴ２０４〜ステップＳＴ２０５と同様である。
【００５４】
図１１は、機能選定部４および利用可否判定部５による候補機能の選定とその利用可否判定の詳細な動作を説明するフローチャートである。具体的には、図１１のステップＳＴ２０７〜ステップＳＴ２０４の処理を詳しく説明したものである。なお、実施の形態１において図４で示したものと同様のステップについては詳細な説明を省略し、図４と異なるステップについてのみ説明する。
【００５５】
機能選定部４は、目的推定部３から推定結果の目的候補およびそれらをユーザが所望する確率を取得する（ステップＳＴ４０７）。
図１２は、目的推定部３から取得する推定結果の一例を示すもので、目的推定部３が算出したものである。ＮＯ．８以降の目的候補については割愛して示す。
図１２に示すように、目的推定部３が算出する推定結果は、情報提供装置が対象とする全てのユーザの目的候補について、例えば、「コンビニで買い物をする」という目的候補については、ユーザが所望する確率が８６％といった具合に、ユーザが所望している確率がそれぞれの目的候補に対して付与されているものである。
なお、以降の説明においては、図１２で省略したＮＯ．９以降の目的候補の確率が３０％を下回る目的候補のみであるとする。
【００５６】
機能選定部４は、ステップＳＴ４０７で取得した推定結果のうち、最も確率の高い目的候補を選定する（ステップＳＴ４０８）。例えば、図１２の推定結果の例においては、「コンビニで買い物をする」という目的候補の確率が８６％と最も高いため、「コンビニで買い物をする」という目的候補が利用可否判定を行う対象として選ばれる。
なお、後述するステップＳＴ４０４から遷移する場合は、利用可否判定を行った目的候補を除いた目的候補の中で、最も確率の高い目的候補が利用可否判定を行う対象として選択される。例えば、既に「コンビニで買い物をする」という目的候補に対しての利用可否判定が行われているのであれば、次に確率の高い「ＦＭ○△を聞く」について利用可否判定を行っていく。
【００５７】
機能選定部４は、ステップＳＴ４０８で選定した目的候補について、目的候補に対応する機能候補を、予め用意し記憶しているテーブルから抽出する（ステップＳＴ４０９）。
図１３は、機能選定部４が予め用意し記憶しているテーブルの一例を示す図である。図１３に示すように、例えば、「コンビニで買い物をする」という目的候補については、「周辺検索、１ｋｍ以内、コンビニ」という機能候補が対応付けされている。ステップＳＴ４０９において、この機能候補が抽出される。
なお、選定される機能とは、「周辺検索」という機能そのものと「１ｋｍ以内」といった機能を実行する際のパラメータを用いて表現されるケースもあるが、図１３のＮＯ．６「エアコンＯＦＦ」のように、パラメータを付与しないケースも存在する。また、目的候補と機能候補がおよそ同一となるケースがあってもよい。例えば、図１３のＮＯ．６「エアコンを切る」と「エアコンＯＦＦ」はおよそ同一のものと考えられる。
また、目的候補に対応する機能候補を予め用意したテーブルは、機能選定部４が記憶しておくのではなく、情報提供装置と接続された外部のサーバに用意され、機能選定部４が、外部のサーバからテーブルを取得しても同様の処理は実現できる。
【００５８】
また、図１３では、目的候補と対応する機能候補が１対１の関係となっている例を主に示しているが、１つの目的候補に対応する機能候補が複数存在するようにしてもよい。例えば、図１３のＮＯ．２のように、「ルートを確認する」という目的候補に対して、「ルート全体象表示、地図で表示」、「ルート全体象表示、文字リストで表示」、「次の案内地点表示、地図で表示」などの複数の機能候補を対応させてもよい。
１つの目的候補に対応する機能候補が複数存在する場合には、履歴データベース２の操作履歴を参照し、操作頻度が最も高い機能候補を選定すればよい。あるいは、複数存在する機能候補の中から、もっとも行う可能性の高い機能候補を、目的推定部３で行う処理のように、周知の方法、例えば、ベイズの定理などの条件つき確率を用いて推定して求めてもよい。
【００５９】
このように、目的推定部３と機能選定部４を設けることで、多種多様な製品に適用する際に目的推定部３を共通部分とし、機能選定部４を個別の製品に対応させることが可能となる。つまり、目的推定部３はこの発明に係る情報提供装置を適用する製品が備える機能の種類に依存せず、当該状況でユーザが所望する目的候補を推定すればよく、この発明を適用する製品に依存する機能種類の差異は機能選定部４で対応することができる。
なお、この発明に係る情報提供装置を適用する製品において、目的推定部３が出力した目的候補に対応する機能が存在しない時は、図１４に示すテーブルに対応する機能候補がないとすればよい。
このようにすることで、多種多様な製品にこの発明に係る情報提供装置を適用する際に、全てを新規に開発する必要なく、効率のよい開発が可能となる。
【００６０】
図１１のフローに戻る。
機能選定部４は、最も確率の高い目的候補に対応する機能候補を利用可否判定部５に出力し、選定した機能候補の利用可否判定を要求する（ステップＳＴ４０２）。具体的な処理は、図４のステップＳＴ４０２において、機能推定部７が行なうものと同様である。
利用可否判定部５は、ステップＳＴ４０２において機能選定部４から取得した機能候補の利用可否の判定を行う（ステップＳＴ４０３）。具体的な処理は図４のステップＳＴ４０３と同様であり、利用可否判定部５は機能選定部４から判定すべき機能候補を取得し、図６に示すフローチャートに従った処理を行なう。
ステップＳＴ４０４〜ステップＳＴ４０６の処理については、図４のステップＳＴ４０４〜ステップＳＴ４０６の処理と同様である。
【００６１】
ここで、前述した図１４において、１つの目的候補に対応する機能候補が複数存在するケースについて補足する。このケースについての動作は図示しないが、このケースで、利用可否判定の結果が「利用不可」であった場合には、ステップＳＴ４０２に進んで、他の機能候補についての利用可否を判定するようにすればよい。そして、ステップＳＴ４０８で選定した目的候補に対応する全ての機能候補についての利用可否を判定した上で、「利用可」となる機能候補が存在しなければステップＳＴ４０８に進むようにすればよい。
このようにすることで、最も確率の高い目的候補に複数の機能候補が存在すれば、その目的候補を実現する機能を提供できる可能性が高くなる。つまり、ユーザが求める機能の代替案を提供することができるため、利便性の高い機能推定が可能となる。
【００６２】
以上のように、実施の形態２によれば、より簡略化された構成とすることが可能となる。そのため、本発明を適用する製品種類や機能に変化が少ない場合においては、かえって効率的な開発が可能となる。
【００６３】
実施の形態３．
実施の形態１，２では、利用できる機能を選定して出力部６に出力するようにしていた。しかしながら、候補機能が利用不可である場合には何もしていなかった。
従来の情報提供装置においても、ある状況下においてユーザが所望すると推定した機能が、その状況下においては利用不可能である場合、利用不可能であることをユーザに伝えることが出来ない構成となっていた。一方、ユーザにとっては、それが有用な情報となるケースも存在する。つまり、ある状況下でユーザが所望している機能が利用できない状況であることを知りたいケースも存在する。
そこで、この実施の形態３では、利用できない機能があれば、その旨を出力してユーザに通知する実施の形態について説明する。
【００６４】
実施の形態３に係る情報提供装置の構成は、実施の形態１で説明したものと同様であるため重複した説明を省略する。
図１４は、実施の形態３の機能推定部７および利用可否判定部５による候補機能の選定とその利用可否判定の詳細な動作を説明するフローチャートである。
実施の形態１において図４で示したものと同様の処理については説明を省略する。この実施の形態３では、実施の形態１から、図１４のステップＳＴ４１０の動作が増えたのみである。
【００６５】
ステップＳＴ４０４において、機能推定部７が機能候補は利用可能ではないと判断した場合（ステップＳＴ４０４の“ＮＯ”の場合）、機能推定部７は、その機能候補が現在利用不可能である内容の通知を出力部６に出力する（ステップＳＴ４１０）。ただし、機能推定部７は、すでに利用中の機能であれば、通知は出力しない。例えば、既に楽曲○△を視聴しており、楽曲○△がステップＳＴ４０３において利用可能とされなくとも、この場合は出力しない。
【００６６】
なお、出力部６の出力方法については、例えば、カーナビゲーションシステムやインスツルメントパネルやヘッドアップディスプレイといった情報提供装置の画像表示部に表示するようにすればよい。また、その際に、音声により、該当の機能が利用不可能である旨を読み上げてユーザに伝えるなどを加えてもよい。なお、これは一例にすぎず、他の方法でユーザに確定した機能を通知するようにしてもよい。また、情報提供装置は画像表示部を備えず、出力部６は、外部の表示装置に、画面表示データおよび音声出力データを送信するようにしてもよい。
【００６７】
また、ここでは情報提供装置を実施の形態１で説明したものと同様の構成とするものとして説明したが、実施の形態２で説明した構成、つまり、図９に示したように目的推定部３と機能選定部４を備える構成としてもよい。その場合、図１１のステップＳＴ４０４の処理の後に上述したステップＳＴ４１０の処理を行なえばよい。
【００６８】
以上のように、この実施の形態３によれば、ある状況下でユーザが所望している機能が利用できない状況であることを知ることができ、わざわざユーザ自ら検索してしまうことを回避できるという効果がある。
【００６９】
実施の形態４．
実施の形態３では、利用できない機能である場合にその旨を通知していた。しかしながら、その後利用可能になったとしても、通知されない。そこで、この実施の形態４では、利用不可能であった機能が利用可能になった場合に、利用可能になったことを通知する実施の形態について説明する。
実施の形態４に係る情報提供装置の構成は、実施の形態１，３で説明したものと同様であるため重複した説明を省略する。
図１５は、実施の形態４の機能推定部７および利用可否判定部による候補機能の選定とその利用可否判定の詳細な動作を説明するフローチャートである。
実施の形態３において図１４で示したものと同様の処理については説明を省略する。
【００７０】
図１５のステップＳＴ４００〜ステップＳＴ４０４の処理は、図１４のステップＳＴ４００〜ステップＳＴ４０４の処理と同様である。
ステップＳＴ４０４において機能推定部７が機能候補は利用不可能であると判断した場合（ステップＳＴ４０４の“ＮＯ”の場合）、図１６に示す処理へ進む（図１５のＡ）。
図１６は、利用不可能と判断された機能候補が、その後利用可能になるかどうかを監視する動作を説明するフローチャートである。
【００７１】
まず、機能推定部７は、ステップＳＴ４０４において利用不可能であると判断した機能候補（以下、該当の機能候補とする）が、利用不可能である内容の通知を出力部６に出力する（ステップＳＴ４１０）。図１６のステップＳＴ４１０の処理は、図１４のステップＳＴ４１０の処理と同様である。
ステップＳＴ４１０において、利用不可能である内容の通知を出力すると、機能推定部７は、ステップＳＴ４０４において利用不可能であると判断した機能候補（以下、該当の機能候補とする）が利用可能であるかどうかの利用可否判定を再度利用可否判定部５に要求する（ステップＳＴ４１１）。
【００７２】
利用可否判定部５は、装置管理部１に対し該当の機能候補に関する現在の情報を要求し、取得した情報に基づいて利用可否判定を行ない（ステップＳＴ４１２）、機能推定部７は、利用可否判定部５から利用可否判定結果を取得する（ステップＳＴ４１３）。なお、ステップＳＴ４１１〜ステップＳＴ４１３の具体的な処理内容は、図１５のステップＳＴ４０２，ステップＳＴ４０３および図６を用いて説明した内容と同様である。
機能推定部７は、ステップＳＴ４１３において利用可否判定部５から判定結果を取得すると、該当の機能候補が利用可能となったかどうかを判断する（ステップＳＴ４１４）。
ステップＳＴ４１４において、利用不可能と判断された場合（ステップＳＴ４１４の“ＮＯ”の場合）、ステップＳＴ４１１に戻り、利用可能となるまでステップＳＴ４１１〜ステップＳＴ４１４の処理を繰り返す。
【００７３】
一方、ステップＳＴ４１４において、利用可能と判断された場合（ステップＳＴ４１４の“ＹＥＳ”の場合）、機能推定部７は、該当の機能候補の確率を算出する（ステップＳＴ４１５）。具体的な算出方法は、図１５のステップＳＴ４００で説明した方法と同様、周知の方法、例えば、ベイズの定理などの条件つき確率を用いる等すればよい。
機能推定部７は、ステップＳＴ４１５において算出した該当の機能候補の確率が、所定値以上であるかどうかを判定する（ステップＳＴ４１６）。つまり、利用可能になったと判断された状況下で、ユーザが行ないたいと推定される機能かどうかの判断を行なう。なお、所定値は、予め設定しておけばよい。
【００７４】
ステップＳＴ４１６において、該当の機能候補の確率が所定値以上であると判断されると（ステップＳＴ４１６の“ＹＥＳ”の場合）、機能推定部７は、該当の機能候補が利用可能になった旨の通知を出力部６に出力する。出力部６は、機能推定部７から受信した通知を出力する。なお、出力方法は、例えば、カーナビゲーションシステムやインスツルメントパネルやヘッドアップディスプレイといった情報提供装置の画像表示部に表示するようにすればよい。また、その際に、音声により、該当の機能が利用可能になった旨を読み上げてユーザに伝えるなどを加えてもよい。なお、これは一例にすぎず、他の方法でユーザに確定した機能を通知するようにしてもよい。また、情報提供装置は画像表示部を備えず、出力部６は、外部の表示装置に、画面表示データおよび音声出力データを送信するようにしてもよい。
一方、ステップＳＴ４１６において、該当の機能候補の確率が所定値以上でないと判断された場合（ステップＳＴ４１６の“ＮＯ”の場合）、ステップＳＴ４１１に戻り、以降の処理を繰り返す。
【００７５】
なお、ここでは、一旦機能候補が利用不可能であると判断されると（ステップＳＴ４０４）、該当の機能が利用可能になるまで待機する（図１６）構成としているが、これに限らず、該当の機能が利用可能になるまで待機する処理と並行して、次に確率の高い機能候補に関する処理（図１５のステップＳＴ４０１〜ステップＳＴ４０６の処理）を行なうようにしてもよい。
【００７６】
また、ここでは情報提供装置を実施の形態１で説明したものと同様の構成とするものとして説明したが、実施の形態２で説明した構成、つまり、図９に示したように目的推定部３と機能選定部４を備える構成としてもよい。その場合、図１１のステップＳＴ４０４の処理の後に上述した図１６の処理を行なえばよい。
【００７７】
以上のように、この実施の形態４によれば、利用できなかった機能が、利用できるようになったことをユーザが知ることが出来るため、今利用できない機能を覚えることや、利用できない機能が使えるようになったかを、ユーザが意識する必要がなく、利便性の高い機能推定が可能となる。
【００７８】
実施の形態５．
以上の実施の形態１〜４では、この発明における情報提供装置を、車載情報機器に適用した場合を例に説明したが、適用するのは車載情報機器に限らず、人、車両、鉄道、船舶または航空機等を含む移動体用の情報提供装置であってもよいし、ＨＥＭＳ（Ｈｏｍｅ  Ｅｎｅｒｇｙ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）や、ネットショッピング等の電子商取引、工作機械を制御する装置、医療用装置など、様々な種類の装置にも適用可能である。例えば、様々な装置が制御されるＨＥＭＳにこの発明を適用する場合を考えてみる。提示する機能の一例として、エアコンの切タイマーを設定する機能を例に説明する。この場合、時刻と操作履歴といった厳選した情報に基づき、エアコンの切タイマーを設定したいという機能候補を推定すればよい。その後、例えば、エアコンがＯＮであるか、切りタイマーが既に設定されているかといった、利用可否を判断するために最低限必要なエアコンの稼働状態を調べ、切りタイマーが利用できると判断されれば、それを提示すればよい。
【００７９】
つまり、予めエアコンの稼働状態をすべて取得してから、機能候補の推定を行うのではないため、効率的な処理が可能となる。ＨＥＭＳでは多くの装置が制御されるため、ユーザに提供する機能候補が多く、それぞれの機能候補に関する情報も多くなるため、この効果は一層高まる。
また、ナビゲーションシステムのサーバに適用してもよいし、スマートフォン、タブレットＰＣ、携帯電話等の携帯情報端末等にインストールされる情報提供システムのアプリケーション等、どのような形態のものにも適用することができる。
【００８０】
ここで、図１７は、この発明の実施の形態５におけるナビゲーションシステムの概要を示す図である。このナビゲーションシステムは、車載装置１００が、スマートフォンなどの携帯情報端末１０１およびサーバ１０２の少なくとも一方と連携して情報提供処理を行ったり、スマートフォンなどの携帯情報端末１０１およびサーバ１０２の少なくとも一方が情報提供処理を行い、車載装置１００に結果を表示させる等、様々な形態をとることができる。以下、当該ナビゲーションシステムの構成態様について説明する。
【００８１】
実施の形態１〜４では、この発明の情報提供装置の機能を、図１７に示す車載装置１００がすべて備えるものとして説明したが、この実施の形態５におけるナビゲーションシステムでは、サーバ１０２が情報提供処理を行い、その結果を車載装置１００に表示させることによりユーザに提供する場合、および、携帯情報端末１０１がサーバ１０２と連携して情報提供処理を行い、その結果を車載装置１００に表示させることによりユーザに提供する場合について説明する。
【００８２】
まず、サーバ１０２が情報提供処理を行い、その結果を車載装置１００に表示させる場合、すなわち、情報提供機能を有するサーバ１０２と連携して、車載装置１００が表示装置として機能する場合について説明する。
この構成においては、車載装置１００がサーバ１０２と直接通信するか、または、車載装置１００が携帯情報端末１０１を経由してサーバ１０２と通信する場合が考えられる。サーバ１０２は、上記実施の形態１〜４で説明した装置管理部１、履歴データベース２、目的推定部３、機能選定部４、利用可否判定部５、機能推定部７を備えた情報提供装置として機能する。また、車載装置１００は、車載装置１００に接続される装置の情報をサーバ１０２に送信する通信部と、サーバ１０２による認識結果をユーザに提供するための出力部６を少なくとも備える表示装置として機能する。
【００８３】
この場合、車載装置１００は基本的に通信機能および表示機能のみを有し、サーバ１０２による情報提供結果を受信してユーザに提供する。
すなわち、サーバ１０２が出力部６以外を備える情報提供装置であり、この情報提供装置であるサーバ１０２が、接続された装置の情報を取得して決定した機能を表示装置である車載装置１００に表示させる。
このように構成しても、実施の形態１〜４と同様な効果を得ることができる。
【００８４】
また、携帯情報端末１０１がサーバ１０２と連携して情報提供処理を行い、その結果を車載装置１００がユーザに提供する場合について説明する。
この構成においては、車載装置１００が携帯情報端末１０１を経由してサーバ１０２と通信する場合が考えられ、携帯情報端末１０１のアプリケーションが、サーバ１０２と連携して情報提供処理を行う。また、車載装置１００は、携帯情報端末１０１とサーバ１０２による結果をユーザに提供するための出力部６を少なくとも備える表示装置として機能する。
【００８５】
この場合にも、車載装置１００は基本的に通信機能および表示機能のみを有し、携帯情報端末１０１とサーバ１０２との連携による情報提供結果を受信してユーザに提供する。
すなわち、携帯情報端末１０１のアプリケーションにより、接続された装置の情報を取得して決定した機能を表示装置である車載装置１００に表示させる。
このように構成しても、実施の形態１〜４と同様な効果を得ることができる。
【００８６】
なお、本願発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。
【産業上の利用可能性】
【００８７】
この発明に係る情報提供装置は、ユーザが所望する機能に関連する情報が膨大に存在する場合であっても効率的な処理が可能となり、時々刻々と変化する車両の状況の変化に応じて、タイミングよく機能を提示することができるため、ユーザの目的を推定し、当該操作目的を実現する機能をユーザに提供する情報提供装置等に適用することができる。
【符号の説明】
【００８８】
１  装置管理部、２  履歴データベース、３  目的推定部、４  機能選定部、５  利用可否判定部、６  出力部、７  機能推定部、１０  情報管理部、１００  車載装置、１０１  携帯情報端末、１０２  サーバ。
【図１】
0005911644.tif 000002
【図２】
0005911644.tif 000003
【図３】
0005911644.tif 000004
【図４】
0005911644.tif 000005
【図５】
0005911644.tif 000006
【図６】
0005911644.tif 000007
【図７】
0005911644.tif 000008
【図８】
0005911644.tif 000009
【図９】
0005911644.tif 000010
【図１０】
0005911644.tif 000011
【図１１】
0005911644.tif 000012
【図１２】
0005911644.tif 000013
【図１３】
0005911644.tif 000014
【図１４】
0005911644.tif 000015
【図１５】
0005911644.tif 000016
【図１６】
0005911644.tif 000017
【図１７】
0005911644.tif 000018