JP2006185189A - ユーザ支援装置及びユーザ支援方法 - Google Patents

Abstract

【課題】 ユーザからの信頼を損なわずに、ユーザによって継続的に利用されるようにするためのユーザ支援装置及びユーザ支援方法を提供する。
【解決手段】 状態決定部１１０において、所定のイベントに対するユーザの動作の支援を行うか否かの状態（提案状態又は提案待機状態）を定める。提案状態では、推定部１０１において動作の支援内容を決定するとともに、ユーザに対して、動作の支援内容の報知（提案）を行う。一方、提案待機状態では、推定部が動作の支援内容の決定を行うものの、ユーザに対して、この動作の支援内容を報知せずに学習動作のみを行うように制御する。提案内容の精度が、所定の基準を下回った場合には提案待機状態となり、所定の基準を上回った場合には提案状態となる。また、ユーザ支援装置１００は、複数の推定戦略を実行することが可能であり、適切な推定戦略の選択が行えるように構成されている。
【選択図】 図１

Description

本発明は、ユーザの属性、嗜好、履歴、状況などの条件に応じて、ユーザに提案するための適切なコンテンツの選択や機器制御などのユーザ支援を行うユーザ支援装置及びユーザ支援方法に関する。なお、本明細書では、ユーザ支援とは、主に、ユーザが快適となること（快適性）、ユーザが安全であること（安全性）、ユーザにとって便利であること（利便性）、環境に良いこと（環境性）の４つの要因に鑑みて、ユーザの動作や行動、意思決定などの支援を行ったり、ユーザが使用している機器制御動作の支援を行ったりすることを指す。

近年、ユーザの属性、嗜好、履歴、状況などの様々なユーザ条件に応じて、情報のフィルタリングや選択を行うことによって、従来はユーザ自身によって行われていた操作や選択を自動化する推定技術が発展してきている。

この推定技術では、様々なアルゴリズムを用いた推定方法が研究されているが、推定技術全般に共通する基本的な考え方は、従来はユーザが自分で考えて行う動作を、コンピュータ処理によって支援しようとするものであり、各ユーザによってそれぞれ異なる属性、嗜好、履歴、状況などの多種多様な情報を利用して、所定の候補の中から各ユーザにとって適切な結果をコンピュータ処理によって推測するものである。

この推定技術は、非常に多岐に渡る分野において適用され得るものである。具体的には、例えば、図５に示すように、視聴用コンテンツや楽曲コンテンツなどの配信や再生時において、ユーザの嗜好や状況に適したコンテンツの推定及び提案を行うための技術分野に適用可能である。

図５は、従来の技術において、推定技術を利用したコンテンツ提供動作を模式的に示すシステム構成図である。図５に示すシステム構成において、車両５０１には、例えば、インターネットにアクセス可能な通信機能を有するとともに、ユーザに提供する適切なコンテンツの推定機能を有する車載装置が搭載されている。

車載装置は、推定機能によって、複数のコンテンツの候補の中からユーザにとって適切なコンテンツを推定するとともに、コンテンツ配信サービスを提供しているサービスプロバイダ５０２に対して、このコンテンツを要求する。この要求に応じて、サービスプロバイダ５０２は、このコンテンツを所有しているコンテンツプロバイダ５０３に対して、このコンテンツを要求し、コンテンツプロバイダ５０３からコンテンツを受信して、ユーザの車両５０１に配信する。これによって、車両５０１では、コンテンツの再生が行われて、ユーザに対して、推定結果として得られたコンテンツが提供される。

一方、推定結果は、何らかの方法によってフィードバックされることにより、推定の精度の向上が図られることが望ましい。このフィードバックの一例としては、例えば、ユーザが推定結果に対する満足度を入力することによって、推定結果及びその満足度の履歴が蓄積されるとともに、この履歴から学習動作が行われて、推定に利用される学習モデルの構築（修正）が行われる。これにより、ユーザの満足度から得られるユーザの嗜好が学習モデルに反映されて、よりユーザの嗜好に合った推定が可能となる。なお、ユーザの個人的な嗜好が反映される前（例えば、車両５０１の出荷時）には、メーカが行った一般的なユーザの嗜好調査に基づく学習モデルなどが利用される。また、本明細書では、上記のフィードバックをユーザの反応と記載することもある。ユーザの反応を取得する方法には、大きく分けて３種類の方法が存在する。第１の方法は、例えば、推定結果の提案を行うとともに、推定結果に対する満足度や、推定結果の提案に対する了承／拒絶の入力をユーザから直接取得することによって、ユーザの嗜好や行動パターンを取得する方法である。また、第２の方法は、例えば、推定結果の提案は行わないものの、ユーザの行動に関する問い合わせ（ユーザの行動そのものや、その行動によって得られた満足度などの問い合わせ）を行い、その問い合わせの結果をユーザから直接取得することによって、ユーザの嗜好や行動パターンを取得する方法である。また、第３の方法は、例えば、ユーザが行う自然な行動を監視しておき、その行動監視結果から間接的にユーザの嗜好や行動パターンを取得する方法である。

なお、ここでは、推定機能がユーザ側（車両５０１内）に実装されている例について説明したが、例えば、コンテンツ配信側（例えば、サービスプロバイダ５０２内）に実装されており、コンテンツ配信側で各ユーザの嗜好に応じたコンテンツの選択及び配信を行うようにしてもよい。

上述のような推定技術を利用したコンテンツ配信は、例えば、下記の特許文献１に開示されている。ここでは、コンテンツ配信サービスにおいて配信するコンテンツを決定する際に、ユーザのコンテンツ嗜好状況をモニタリングして、ネットワーク構成上、ユーザ端末に最も近い箇所に配置されているコンテンツ記憶手段内に、そのユーザの嗜好度が高いコンテンツを記憶させている。

また、このような推定技術は、例えば、図６に示すように、ユーザの嗜好や状況に適した機器制御の態様を決定するための技術分野にも適用可能である。図６は、従来の技術において、推定技術を利用した機器制御の態様の決定動作を模式的に示すシステム構成図である。図６に示すシステム構成において、車両６０１には、車両６０１内の機器制御（例えば、車両６０１内の空調制御や車両６０１のエンジン制御など）に関して、適切な態様を決定するための推定機能を有する車載装置が搭載されている。

この場合も図５に示す動作と同様に、車載装置は、推定機能によって、所定の機器の動作に係る適切な態様を決定して、所定の機器に対する制御を行う。また、図５に示す動作と同様に、推定結果は、何らかの方法によってフィードバックされることにより、推定の精度の向上が図られることが望ましく、例えば、上述の第１〜第３の方法のうちのいずれとして挙げた方法を用いて、ユーザの満足度を取得したり、ユーザの取った行動から満足度を推定したりすることによって、推定結果及びその満足度の履歴が蓄積されるとともに、この履歴から学習動作が行われて、ユーザの嗜好が反映されるように、推定に利用される学習モデルの構築（修正）が行われる。なお、この場合においても、ユーザの個人的な嗜好が反映される前（例えば、車両６０１の出荷時）には、メーカが行った嗜好調査（一般的なユーザの嗜好調査）に基づく学習済みデータによって構築された学習モデル（デフォルトの学習モデル）などが利用される。

なお、ここでは、主に、車両５０１、６０１に搭載された車載装置を前提として説明したが、推定技術は、一般的なコンピュータにおいて適用可能である。したがって、例えば、ユーザ支援装置は、例えば、携帯電話機やＰＣ（Personal Computer：パーソナルコンピュータ）、サーバ、情報家電などに実装可能であり、また、実装されたコンピュータの配置場所も、例えば、駅のホーム、オフィス、電車や車の車両内、街中、店舗内など様々な場所が可能であり、特に限定されるものではない。

しかしながら、ユーザ条件は複雑な情報であり、上述のようなユーザ条件に鑑みた推定結果は、必ずしもユーザが本当に求めているものと一致するとは限らない。したがって、推定結果に基づく動作（例えば、上述の例では、コンテンツの受信及び再生や、所定の機器への制御信号の出力）を行う前に、ユーザに対して、推定結果の実行が報知されるとともに、その実行許可が得られるようにすることが望ましい。

また、推定結果は、通常、ランキング（ユーザが求めている可能性の大きさを比較）によって決定されるものであり、例えば、ユーザが求めている可能性が最も高い推定結果に対して、ユーザから実行許可が得られなかった場合（すなわち、推定結果に係る動作がユーザの求める動作ではなかった場合）には、次に可能性の高い推定結果の再提案を行うようにすることが可能である。なお、一般的には、この推定結果の再提案回数は、所定の回数までに制限されるべきである。
特開２００３−３００８７号公報（段落００１８−００２４、図２）

しかしながら、推定機能による推定結果の精度の良し悪しにかかわらず、ユーザが、推定機能による推定結果の提案動作そのものを拒絶して、推定機能に係る動作を停止し、利用しなくなってしまう場合が考えられる。すなわち、推定機能による推定結果の提案に関しては、ユーザからの信頼が得られるようにする必要がある。

ここで、推定機能による推定結果の提案に関して、ユーザからの信頼が失われる例について説明する。ユーザからの信頼が失われる一例として、推定結果の精度は高いものの、その提案のタイミングが悪い場合がある。例えば、背景技術で説明したように、推定機能は、ユーザが推定結果の提案を受け入れなかった場合には、次に可能性の高い推定結果の提案を行うなど、最初に提案した推定結果は、ユーザが求めるものではなかったという結論を前提とした再提案動作を行う。しかしながら、実は、ユーザが受け入れなかった理由は、制度の悪さが原因ではなく、提案のタイミングが原因であり、別のタイミングで同一の推定結果の提案を行っていれば、ユーザは、その提案を受け入れたかもしれない可能性もある。一例としては、例えば、正午に「昼食に○○レストランの和食はいかがですか」という提案を行ったにもかかわらず、ユーザは午後１時に昼食を取るように考えており、その提案を受け入れない場合が挙げられる。このような場合に、ユーザによって最初の提案が拒否されたことを受けて、次の候補として「それでは××レストランの和食はいかがですか」という提案を行うことは的外れであり、ユーザからの信頼を損なうことになる。

また、ユーザからの信頼が失われる一例として、ユーザが受け入れられない提案を繰り返し行うことが挙げられる。ユーザは、推定結果の精度がある程度は悪いと分かっている場合でも、繰り返し精度の悪い推定結果を提案されると、いつまでたっても精度の良い推定結果が得られないと思うようになってしまい、その結果、ユーザは、推定機能への信頼をなくして、推定機能の利用自体を停止してしまう可能性がある。

また、上述のような推定機能に対するユーザからの信頼が失われてしまう状況は、特に、推定機能が、そのユーザ条件を十分に学習できていない場合に起こる可能性が高い。例えば、上述の例では、車両内のユーザ支援装置が出荷直後であり、そのユーザの嗜好などをまだ十分に学習できていないデフォルトの学習モデルに近い状態のときに、推定機能に対するユーザからの信頼が失われてしまう可能性が高い。このような推定機能がユーザの嗜好などを十分に学習できていない時期は、ユーザが推定機能を利用し始め、推定機能に対して、どのくらいの精度の推定結果が得られるのであろうかという興味を持っている時期に一致するため、ユーザが、推定機能を利用し始めた直後に、推定機能への信頼をなくしてしまう可能性は著しく高いと言える。

上記の問題に鑑みて、本発明は、ユーザからの信頼を損なわずに、ユーザによって継続的に利用されるようにするためのユーザ支援装置及びユーザ支援方法を提供することを目的とする。

上記の目的を達成するため、本発明によれば、所定のイベントに対するユーザ支援を行うために、前記ユーザ支援の支援内容を決定するユーザ支援装置であって、
前記ユーザ支援を行う提案状態及び前記ユーザ支援を行わない提案待機状態のいずれか一方の状態を決定する状態決定手段と、
前記状態決定手段によって決定された前記状態を示す情報を格納する状態格納手段と、
前記状態格納手段に、前記提案状態を示す情報が格納されている場合には、前記ユーザ支援の支援内容を決定するとともに前記ユーザ支援の支援内容の報知を行い、前記提案待機状態を示す情報が格納されている場合には、前記ユーザ支援の支援内容の決定を行うものの前記ユーザ支援の支援内容の報知を行わないように制御するユーザ支援内容決定手段とを、
有するユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、前記状態決定手段が、前記イベントごとに前記状態を決定し、前記状態格納手段が、前記イベントごとに前記状態を示す情報を格納するように構成されているユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、時間を計測する計時手段を有しており、
前記提案待機状態を示す情報が前記状態格納手段に格納されてから所定の時間以上経過している場合には、前記状態格納手段に格納されている前記提案待機状態を示す情報を、前記提案状態を示す情報に変更するように構成されているユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案状態において、報知された前記ユーザ支援の支援内容に対する前記ユーザの反応を取得することによって、前記ユーザ支援に係る精度向上を図る学習を行うように構成されているユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案状態において、報知された前記ユーザ支援の支援内容に対する前記ユーザの反応を取得して、前記ユーザの反応に基づいて前記ユーザ支援の支援内容の精度を計算し、前記精度の計算結果が所定の基準を下回った場合に、前記イベントの状態を前記提案待機状態とするように構成されているユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案待機状態において、前記イベントに対して行われた前記ユーザの行動監視結果を取得するか、あるいは前記イベントに対して行われた前記ユーザの行動に関する問い合わせを行うことによって、前記ユーザ支援に係る精度向上を図る学習を行うように構成されているユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案待機状態において、前記イベントに対して行われた前記ユーザの行動監視結果又は前記問い合わせの結果に基づいて前記ユーザ支援の支援内容の精度を計算し、前記精度の計算結果が所定の基準を超えた場合に、前記イベントの状態を前記提案状態とするように構成されているユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、前記ユーザ支援内容決定手段が、複数の推定戦略を実行することが可能なように構成されているユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、複数の前記推定戦略を順次用いて、前記ユーザ支援の支援内容を決定して報知するか、あるいは複数の前記推定戦略のうちの少なくとも２つ以上の前記推定戦略を用いて、前記ユーザ支援の支援内容を決定し、前記少なくとも２つ以上の前記推定戦略を用いて決定された前記ユーザ支援の支援内容を同時に報知するように構成されているユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案状態において、報知した前記ユーザ支援の支援内容が了承されなかった場合には、異なる前記推定戦略を用いて、再度、前記ユーザ支援の支援内容を決定して報知を行うように構成されているユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案状態において、複数の前記推定戦略のそれぞれに関する前記ユーザ支援に係る優先度を計算し、前記優先度の高い前記推定戦略を選択して前記ユーザ支援の支援内容を決定するように構成されているユーザ支援装置が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案待機状態において、複数の前記推定戦略を用いて前記ユーザ支援の支援内容を決定するとともに、複数の前記推定戦略を用いて決定された前記ユーザ支援の支援内容のそれぞれの優先度を計算し、複数の前記推定戦略の少なくとも１つに係る前記優先度が所定の基準を超えた場合には、前記イベントの状態を、前記優先度が所定の基準を超えた前記推定戦略を利用した前記ユーザ支援の支援内容の決定及び報知を行う前記提案状態とするように構成されているユーザ支援装置が提供される。

また、上記の目的を達成するため、本発明によれば、所定のイベントに対するユーザ支援を行うために、前記ユーザ支援の支援内容を決定するユーザ支援装置であって、
複数の推定戦略のそれぞれに基づいて、前記ユーザ支援の支援内容を決定するとともに前記ユーザ支援の支援内容の報知を行うユーザ支援内容提案手段を有し、
報知した前記ユーザ支援の支援内容が了承されなかった場合には、異なる前記推定戦略を用いて、再度、前記ユーザ支援の支援内容を決定して報知を行うように構成されているユーザ支援装置が提供される。

また、上記の目的を達成するため、本発明によれば、所定のイベントに対するユーザ支援を行うために、前記ユーザ支援の支援内容を決定するユーザ支援方法であって、
前記ユーザ支援を行う提案状態及び前記ユーザ支援を行わない提案待機状態のいずれか一方の状態を決定する状態決定ステップと、
前記状態決定ステップで決定された前記状態を示す情報を格納する状態格納ステップと、
前記状態格納ステップで格納された情報が前記提案状態を示す情報である場合には、前記ユーザ支援の支援内容を決定するとともに前記ユーザ支援の支援内容の報知を行い、前記状態格納ステップで格納された情報が前記提案待機状態を示す情報である場合には、前記ユーザ支援の支援内容の決定を行うものの前記ユーザ支援の支援内容の報知を行わないように制御するユーザ支援内容決定ステップとを、
有するユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、前記状態決定ステップにおいて前記イベントごとに前記状態を決定し、前記状態格納ステップにおいて前記イベントごとに前記状態を示す情報を格納するユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、前記状態格納ステップで前記提案待機状態を示す情報が格納されてから所定の時間以上経過している場合には、前記状態格納ステップで格納された前記提案待機状態を示す情報を、前記提案状態を示す情報に変更する状態変更ステップを有するユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案状態において、報知された前記ユーザ支援の支援内容に対する前記ユーザの反応を取得するユーザ反応取得ステップと、
前記ユーザ反応取得ステップで取得した前記ユーザの反応に基づいて、前記ユーザ支援に係る精度向上を図る学習を行う学習ステップを有するユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案状態において、報知された前記ユーザ支援の支援内容に対する前記ユーザの反応を取得するユーザ反応取得ステップと、
前記ユーザ反応取得ステップで取得した前記ユーザの反応に基づいて前記ユーザ支援の支援内容の精度を計算し、前記精度の計算結果が所定の基準を下回った場合に、前記イベントの状態を前記提案待機状態とする提案待機状態設定ステップとを、
有するユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案待機状態において、前記イベントに対して行われた前記ユーザの行動監視結果か、あるいは前記イベントに対して行われた前記ユーザの行動に関する問い合わせを行うユーザ行動結果取得ステップと、
前記ユーザ行動結果取得ステップで取得した前記ユーザの行動監視結果又は前記問い合わせの結果に基づいて、前記ユーザ支援に係る精度向上を図る学習を行う学習ステップを有するユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、前記ユーザ行動結果取得ステップで取得した前記ユーザの行動監視結果又は前記問い合わせの結果に基づいて、前記ユーザ支援の支援内容の精度を計算し、前記精度の計算結果が所定の基準を超えた場合に、前記イベントの状態を前記提案状態とする提案状態設定ステップを有するユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、前記ユーザ支援内容決定手段が、複数の推定戦略を実行することが可能なように構成されているユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、複数の前記推定戦略を順次用いて、前記ユーザ支援の支援内容を決定して報知するか、あるいは複数の前記推定戦略のうちの少なくとも２つ以上の前記推定戦略を用いて、前記ユーザ支援の支援内容を決定し、前記少なくとも２つ以上の前記推定戦略を用いて決定された前記ユーザ支援の支援内容を同時に報知する複数提案ステップを有するユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案状態において、前記ユーザ支援内容決定ステップで報知した前記ユーザ支援の支援内容が了承されなかった場合には、異なる前記ユーザ支援の支援内容を導出する可能性のある別の推定戦略を用いて、再度、前記ユーザ支援の支援内容を決定して報知を行う再提案ステップを有するユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案状態において、複数の前記推定戦略のそれぞれに関する前記ユーザ支援に係る優先度を計算し、前記優先度の高い前記推定戦略を選択して前記ユーザ支援の支援内容を決定する推定戦略選択ステップを有するユーザ支援方法が提供される。

さらに、本発明によれば、上記の発明に加えて、前記提案待機状態において、前記ユーザ支援内容決定ステップで異なる前記ユーザ支援の支援内容を導出する可能性のある複数の前記推定戦略を用いて前記ユーザ支援の支援内容を決定し、複数の前記推定戦略を用いて決定された前記ユーザ支援の支援内容のそれぞれの優先度を計算し、複数の前記推定戦略の少なくとも１つに係る前記優先度が所定の基準を超えた場合には、前記イベントの状態を、前記優先度が所定の基準を超えた前記推定戦略を利用した前記ユーザ支援の支援内容の決定及び報知を行う前記提案状態とする戦略別提案状態設定ステップを有するユーザ支援方法が提供される。

また、上記の目的を達成するため、本発明によれば、所定のイベントに対するユーザ支援を行うために、前記ユーザ支援の支援内容を決定するユーザ支援方法であって、
複数の推定戦略のそれぞれに基づいて、前記ユーザ支援の支援内容を決定するとともに前記ユーザ支援の支援内容の報知を行うユーザ支援内容提案ステップと、
報知した前記ユーザ支援の支援内容が了承されなかった場合には、異なる前記推定戦略を用いて、再度、前記ユーザ支援の支援内容を決定して報知を行う再提案ステップとを、 有するユーザ支援方法が提供される。

本発明に係るユーザ支援装置及びユーザ支援方法は、上記の構成を有しており、ユーザからの信頼を損なわずに、ユーザによって継続的に利用されるようになるという効果を有している。また、特に、本発明に係るユーザ支援装置及びユーザ支援方法は、各ユーザの条件が十分に把握できていない状態において、ユーザからの信頼を損なわずに、ユーザに継続的に利用させるという効果を有している。

以下、図面を参照しながら、本発明の実施の形態について説明する。なお、以下では、本発明に係るユーザ支援装置が、図５に図示されているように、通信機能を有する車載装置に実装されている場合を例に挙げながら説明するが、本発明に係るユーザ支援装置は、コンピュータによってユーザ支援を行う任意の状況に適用可能である。

まず、図１を参照しながら、本発明の実施の形態におけるユーザ支援装置の構成について説明する。図１は、本発明の実施の形態におけるユーザ支援装置の構成を示すブロック図である。なお、図１では、各機能がブロックにより模式的に図示されているが、これらの各機能は、ハードウェア又はソフトウェアによって実現されるものである。

図１に示すユーザ支援装置１００は、推定部１０１、イベント判別部１０２、状況検出部１０３、履歴格納部１０４、ユーザ嗜好格納部（ユーザモデル格納部）１０５、戦略決定部１０６、戦略アルゴリズム格納部１０７、ユーザ操作入力部１０８、推定結果出力部１０９、状態決定部１１０、状態格納部１１１、タイマ１１２を有している。

推定部１０１は、任意の推定方法によって所定のイベントに対して、任意の推定方法によって、適切な動作を行うための推定結果を演算する推定機能を有している。また、イベント判別部１０２は、何らかのイベントが発生した場合に、そのイベントが、推定及びユーザへの推定結果の提案を行うべきイベント（対象イベント）であるか否かを判別する機能を有している。なお、対象イベントとなり得るイベントは様々であり、例えば、ユーザによる所定の入力操作、所定のセンサによるユーザの動作検出、所定の時刻などにより発生するイベントが挙げられる。

また、状況検出部１０３は、上述のように、状況を検出して対象イベントを発生することが可能であるとともに、推定部１０１における推定動作において必要となり得る状況を把握するための機能を有している。なお、車載装置にユーザ支援装置が実装されている場合には、この状況検出部１０３としては、例えば、車両内の温度・湿度を検知するセンサ、車速や車両の傾き、ガソリンの残量などを検知するセンサ、車両内の乗員の人数や座席位置などを検出するセンサなどを始めとして、様々なセンサの利用が可能である。

また、履歴格納部１０４は、推定部１０１における推定動作の履歴を格納する機能を有している。具体的には、履歴格納部１０４には、推定部１０１の推定結果、ユーザ状況、ユーザが入力した情報やユーザの行動監視結果から得られる正解データと、そのときの条件などが格納される。なお、履歴格納部１０４には、ユーザの詳細な履歴が格納されてもよく、また、例えば、所定のレストランに行った回数などのように、ユーザの履歴が頻度として格納されてもよい。

また、ユーザ嗜好格納部１０５は、ユーザの嗜好に係る情報を格納する機能を有している。なお、このユーザの嗜好に係る情報は、例えば、ユーザの好きなアーティストや色などのユーザの好みを表す情報であり、あらかじめユーザから初期値として入力された嗜好情報や、実際の推定結果に対する満足度などの推定過程において徐々に学習されていく嗜好情報などである。特に、後者の学習によって把握される嗜好情報は、履歴格納部１０４に格納される履歴情報とみなすことも可能であるが、ここでは、便宜上、履歴情報と嗜好情報とを分けて説明を行う。

また、戦略決定部１０６は、対象イベントに基づいて、どの推定方法（あるいは、どの推定方法の組み合わせ）によって推定を行うかなどの戦略（推定戦略）を決定する機能を有しており、戦略アルゴリズム格納部１０７は、戦略決定部１０６によって選択される戦略に係るアルゴリズムを格納する機能を有している。なお、戦略決定部１０６によって決定される推定モデルは、所定の推定戦略に基づいて選択される。推定モデルの具体例に関しては、推定戦略の説明と共に後述する。

また、ユーザ操作入力部１０８は、ユーザが推定結果に対してフィードバックを行うための任意の入力インタフェースであり、キーボード、マウス、操作パネル、音声認識システムなどによって実現可能である。また、推定結果出力部１０９は、推定部１０１による推定結果を出力するための出力インタフェースであり、この推定結果出力部１０９から出力される推定結果は、所定の機器の動作を制御するための制御信号や、ユーザに報知される情報に加工される。

また、状態決定部１１０は、このユーザ支援装置１００における状態を決定する機能を有しており、状態格納部１１１は、状態決定部１１０によって決定された状態を格納する機能を有している。状態決定部１１０によって決定される状態には、提案状態と提案待機状態の２つの状態が存在する。提案状態は、実際に、推定部１０１が計算した推定結果をユーザに報知したり、推定部１０１が計算した推定結果に基づいて各機器の動作制御を行ったりする状態である。また、提案状態では、ユーザ支援に係る精度向上を図るための学習動作も行われる。すなわち、提案状態では、推定、提案、学習が行われる。一方、提案待機状態は、ユーザに対する報知や各機器の動作制御を行わず、精度の良い推定結果やユーザから信頼される推定結果を得るため学習動作のみを行う状態である。すなわち、提案待機状態では、推定及び学習が行われるが、提案は行われない。なお、提案待機状態では、推定及び学習が行われていることが、ユーザには分からないようにしてもよく、また、推定及び学習が行われていることを何らかの方法によってユーザに報知してもよい。また、各対象イベントに対して、提案状態及び提案待機状態のいずれか一方が設定されてもよく、また、１つ又は複数の所定の推定戦略に関しては提案状態が設定されるとともに、残りの推定戦略に関しては提案待機状態が設定されるなどのように、推定戦略ごとに提案状態又は提案待機状態が設定されてもよい。また、ユーザが、提案状態又は提案待機状態を手動で選択できるようにしてもよい。

また、タイマ１１２は、提案待機状態が設定された対象イベントに関して、その提案待機状態が設定された時刻（日時）からの経過時間を計時する機能を有している。なお、状態格納部１１１及びタイマ１１２は、具体的には、例えば、状態格納部１１１が、各対象イベントの項目に対して、提案状態及び提案待機状態のいずれか一方を示すフラグと、提案待機状態に関しては、その状態になった日時とが関連付けられた情報を保持しておく一方、タイマ１１２が通常の計時機能を有しており、提案待機状態となった日時からの経過時間が把握できるように構成することが可能である。なお、状態格納部１１１には、各対象イベントに関して、提案待機状態の継続時間も関連付けられて格納されることが望ましい。

次に、図１に示すユーザ支援装置１００によって行われる動作について説明する。図２は、本発明の実施の形態におけるユーザ支援装置の状態遷移の一例を示すフローチャートである。図２において、ユーザ支援装置１００は、何らかのイベントを受信する（ステップＳ２０１：イベント受信）。なお、イベントは、何らかの状態変化に基づいて発生する信号である。このイベントは多種多様であり、例えば、ユーザ支援装置１００が車載装置に実装されている場合には、ユーザが車両に乗車したこと、エンジンキーの挿入、ユーザによる車載装置の操作、ガソリンの残量が所定量以下になったこと、車両内の温度が所定の範囲を逸脱したこと、特定の時刻になったこと、マウスやキーボードなどの入力装置が使用されて入力があったことなどを始めとして、様々なイベントが考えられる。

ユーザ支援装置１００は、ステップＳ２０１で受信したイベントに関して、推定を行うべき対象イベントであるか否かの判断を行う（ステップＳ２０２：対象イベント？）。なお、受信したイベントが対象イベントであるか否かの判別は、例えば、ユーザ支援装置１００が、対象イベントを識別するリストなどを保持しておき、このリスト内に受信したイベントが記載されているか否かのチェックを行うことによって可能となる。

ステップＳ２０２における判別処理によって、受信したイベントが対象イベントではないと判別された場合には、特に、推定に係る動作を行う必要はなく、そのまま動作は終了となる。一方、受信したイベントが対象イベントであると判別された場合には、その対象イベントの状態が、提案状態及び提案待機状態のどちらの状態となっているかをチェックする（ステップＳ２０３：提案状態？）。ここで、ステップＳ２０３におけるチェックで、受信したイベントの状態が提案状態となっている場合には、ユーザ支援装置１００は、提案状態に係る動作を実行する（ステップＳ２０６：提案状態に係る動作）。

また、ステップＳ２０３におけるチェックで、受信したイベントの状態が提案待機状態となっている場合には、さらに、この受信したイベントが、所定の継続時間以上、提案待機状態となっているか否かを判断する（ステップＳ２０４：所定時間経過？）。そして、このステップＳ２０４において受信したイベントの提案待機状態が所定の継続時間以上経過していない場合（受信したイベントの状態が提案待機状態となってから、所定の継続時間以上経過していない場合）には、ユーザ支援装置１００は、提案待機状態に係る動作を実行し（ステップＳ２０５：提案待機状態に係る動作）、それ以外の場合には、状態決定部１１０が、このイベントの状態を提案待機状態から提案状態に変更するとともに、ユーザ支援装置１００は、提案状態に係る動作を実行する（ステップＳ２０６：提案状態に係る動作）。

なお、ステップＳ２０４における提案待機状態の継続時間は、例えば、ユーザに対して前回行った提案が了承されなかった場合に、再度、提案を行うまでの緩和時間であり、言い換えると、提案内容に関して失われたユーザの信頼が回復するまでの時間（提案に対するユーザの不信に関して、そのほとぼりが覚めるまでの時間）である。この提案待機状態の継続時間は、任意に設定可能であり、学習によって適宜定めることも可能である。また、例えば、提案内容とユーザが行った行動との差異（すなわち、間違いの程度）を検証して、間違いの程度が大きい場合には提案待機状態の継続時間を長く設定するなど、間違いの程度に応じた提案待機状態の継続時間の設定を行うことも可能である。また、ステップＳ２０４における提案待機状態の継続時間のチェックは、必ずしも行われる必要はなく、受信したイベントの状態（提案状態又は提案待機状態）に応じて、その状態に係る動作を実行するようにしてもよい。

以上のように、図２に示すフローチャートによれば、ユーザ支援装置１００は、受信したイベントが提案状態及び提案待機状態のどちらであるかを判別して、判別された状態に応じた動作を行うことが可能となる。また、所定の継続時間以上、提案待機状態となっている対象イベントに関しては、提案状態に係る動作を行うようにすることも可能となる。

続いて、受信したイベントの状態に応じてユーザ支援装置１００によって行われる提案状態に係る動作及び提案待機状態に係る動作について、図３及び図４を参照しながら説明する。

まず、図３を参照しながら、提案状態に係る動作について説明する。図３は、本発明の実施の形態における提案状態に係る動作の一例を示すフローチャートである。図３に示す提案状態に係る動作において、まず、ユーザ支援装置１００は、初期推定戦略を決定する（ステップＳ３０１：初期推定戦略を決定）。なお、この推定戦略とは、推定に利用する推定方法（推定モデル、推定アルゴリズム、推定に利用されるパラメータなど）の決定や、ユーザへの提案方法の決定、学習を行う際の学習方法（学習アルゴリズム）の決定などを指しており、ステップＳ３０１では、最初に行われる推定戦略が、初期推定戦略として決定される。なお、推定戦略に関しては、後で詳細に説明する。

次に、ユーザ支援装置１００は、推定部１０１において、受信した対象イベントに対して推定戦略に基づく推定を行って、推定結果として提案タイミングや提案内容などを決定し（ステップＳ３０２：提案タイミング、提案内容を決定）、例えば、所定の提案タイミングで所定の表示画面に表示するなどの方法によって、ユーザに対して推定結果を提案する（ステップＳ３０３：推定結果の提案）。また、推定結果の提案と同時に、ユーザが、この推定結果を受け入れるか（了承するか）否かの入力を促し、ユーザ支援装置１００は、ユーザによる推定結果の了承又は拒否の入力の待機状態となる。なお、ステップＳ３０２において、適切な提案タイミングや提案内容が存在しないと判断され、適切な提案タイミングや提案内容が決定できない場合には、推定結果の提案（後述のステップＳ３０３の処理）や履歴の蓄積（後述のステップＳ３０７の処理）を行わずに、後述のステップＳ３０８に進むことが望ましい。

このステップＳ３０３における推定結果の提案は、ユーザ支援装置１００が、ユーザによって推定結果が了承されるか否かを確認する動作であるとともに、ユーザ自身の嗜好を学習するためのフィードバック入力としても利用される。

ユーザは、ステップＳ３０３で提案された推定結果を了承するか否かの入力を行う（ステップＳ３０４：了承された？）。ユーザが推定結果を了承する旨の入力を行った場合には、その履歴を蓄積するとともに、提案内容の実行動作を開始し（ステップＳ３０５：履歴蓄積／提案内容の実行）、再び、この対象イベントに対して提案状態が設定される（ステップＳ３０６：提案状態に設定）。

一方、ステップＳ３０４において、ユーザが推定結果を了承しない旨の入力を行った場合には、その履歴を蓄積し（ステップＳ３０７：履歴蓄積）、再度、別の推定結果の提案を行うか否かを決定する。例えば、この対象イベントに対してあらかじめ設定されている所定数、又はステップＳ３０１における初期推定戦略の決定時に定めた所定数を参照し、ユーザに対して、この所定数の回数（所定の回数）だけ、推定結果の提案を行うようにする。具体的には、ユーザ支援装置１００は、所定の回数の推定戦略を試したか否かを判定し（ステップＳ３０８：所定の回数、戦略を試した？）、まだ、所定の回数だけ推定戦略を試していない場合には、別の推定戦略に変更した後（ステップＳ３０９：推定戦略変更）、再度、ステップＳ３０２に戻って、変更された推定戦略に基づく提案タイミングや提案内容の決定を行って、その推定結果の提案を行なう。なお、ステップＳ３０９における推定戦略の変更は、より良い推定結果が得られる順序（すなわち、精度の良い順序）や、処理の速い順序など、何らかの優先度パラメータ（優先度）に基づいて選択されることが望ましい。また、ここでは、推定戦略を１つずつ変更しながら、各推定戦略に基づく推定結果を順次提案するようにしているが、例えば、ステップＳ３０２で、複数の異なる推定戦略に基づいて推定を行い、ステップＳ３０３で、これらの複数の推定結果を同時にユーザに提案することも可能である。

一方、ステップＳ３０８において、所定の回数だけ戦略を試した場合には、結果的に、提案したすべての推定結果がユーザに了承されず、提案は失敗に終わる。そして、ユーザ支援装置１００は、履歴格納部１０４などに蓄積されている情報を考慮して、例えば、この対象イベントに係る失敗の頻度などを計算し（ステップＳ３１０：失敗頻度計算）、この対象イベントに係る提案が失敗に終わった頻度が所定の基準を上回ったか否かを判断する（ステップＳ３１１：基準を超えた？）。なお、ステップＳ３１１では、例えば、対象イベントに係る提案が失敗に終わった率が所定の率を超えたか否か、あるいは対象イベントに係る提案が失敗に終わった事象が所定の回数だけ連続して発生したか否かなどが参照される。

そして、例えば、対象イベントに係る提案が失敗に終わった率が所定の率を超えた場合や、対象イベントに係る提案が失敗に終わった事象が所定の回数だけ連続して発生した場合など、対象イベントに係る提案が失敗に終わった事象が所定の基準を超えた場合には、
この対象イベントに対して提案待機状態が設定される（ステップＳ３１２：提案待機状態に設定）。一方、対象イベントに係る提案が失敗に終わった事象が所定の基準を超えなかった場合には、再度、この対象イベントに対して提案状態が設定される（ステップＳ３１３：提案状態に設定）。

なお、ステップＳ３０５やステップＳ３０７で蓄積された履歴は、推定部１０１における推定の精度が向上するように、学習動作の基データとして利用されることが望ましい。この学習動作では、例えば、ユーザから直接取得した提案結果に対する満足度や、提案結果の提案に対する了承／拒絶の入力、あるいはユーザが行った行動の監視結果に基づいて、各推定戦略における推定の精度の向上を目的とした学習、複数の推定戦略の中からどの推定戦略が有効であったかを特定する学習（１つ又は複数の適切な推定戦略を求める学習）、いくつの推定戦略を用いて提案を行うかを決定するための学習、複数の推定戦略を用いて提案を行う場合の提案方法（例えば、複数の推定戦略のそれぞれの推定結果を順次提案するか、あるいは複数の推定戦略のそれぞれの推定結果を同時に提案するか）を決定するための学習、適切な提案タイミングを求める学習、提案回数（推定戦略を変更する所定の回数）の学習などが行われる。

また、上述の説明では、ステップＳ３０８において、提案回数が所定の回数となるまで提案を行う回数制限を適用しているが、例えば、所定の時間だけ提案を行う時間制限を適用することも可能である。また、ステップＳ３１０において計算される失敗頻度として、連続して失敗に終わった回数や、ある時間における失敗に終わった回数（すなわち、時間当たりの失敗頻度）、さらには、これらの回数にユーザの反応（ユーザの評価）を重み付けした情報などを採用することが可能である。また、上述の説明では、対象イベントに対して提案状態又は提案待機状態が設定されるが、この対象イベントに係る推定に用いられる推定戦略ごとに提案状態又は提案待機状態が設定されてもよい。すなわち、所定の対象イベントに対して、ある推定戦略では精度の悪い推定結果しか得られず、別の推定戦略では精度の良い推定結果が得られるような場合には、前者の推定戦略に対しては提案状態が設定され、後者の推定戦略に対しては提案待機状態が設定されるようにしてもよい。

以上のように、提案状態の場合には、所定の初期推定戦略に基づく推定結果をユーザに提案するとともに、提案が了承されなかった場合には推定戦略を変更し、再度推定を行った上で、その推定結果の再提案を行うことが可能となる。また、ユーザへの推定結果の提案が失敗に終わった場合には、過去の失敗の事象なども考慮して、再度、提案状態に設定するか、あるいは提案待機状態に設定するかの状態選択が可能となる。

次に、図４を参照しながら、提案待機状態に係る動作について説明する。図４は、本発明の実施の形態における提案待機状態に係る動作の一例を示すフローチャートである。図４に示す提案待機状態に係る動作において、まず、ユーザ支援装置１００は、提案状態と同様に、初期推定戦略を決定する（ステップＳ４０１：初期推定戦略を決定）。

次に、ユーザ支援装置１００は、推定部１０１において、受信した対象イベントに対して推定戦略に基づく推定を行って、推定結果として提案内容などを決定する（ステップＳ４０２：提案内容を決定）。なお、上述の提案状態では、ステップＳ３０３において、決定された提案内容がユーザに提案されるが、この提案待機状態では、提案内容はユーザに提案されることはない。

提案待機状態では、ユーザ支援装置１００がユーザの支援を行うことはなく、ユーザ自身が、対象イベントに係る動作を自分で決定して行う。したがって、この対象イベントに係る動作は、ユーザの行動によって行われる。ユーザ支援装置１００は、対象イベントに係るユーザの行動を監視して、このユーザの行動監視結果と、ステップＳ４０２で決定した提案内容との比較を行って（ステップＳ４０３：ユーザの行動監視結果と比較）、この推定戦略による推定結果と、ユーザの行動監視結果との一致度を判定する。この一致度は、履歴として履歴格納部１０４に蓄積される（ステップＳ４０４：履歴蓄積）。なお、ここでは、上述の第３の方法により、ユーザの行動監視を行って取得した行動監視結果を利用しているが、上述の第２の方法により、ユーザに問い合わせを行って取得した問い合わせの結果を利用することも可能である。

また、ユーザ支援装置１００は、上述のステップＳ４０２〜Ｓ４０４に係る動作を、すべての推定戦略に関して行うようにする。すなわち、すべての推定戦略を試したか否かの判定を行い（ステップＳ４０５：すべての戦略を試した？）、まだ、試していない戦略がある場合には、推定戦略を変更して（ステップＳ４０６：推定戦略変更）、この推定戦略による推定結果と、ユーザの行動監視結果との一致度の判定を行う。なお、ここでは、ユーザの行動監視結果が先に得られ、その後に各推定戦略における推定結果を算出して、両者の比較を行うように図示されているが、例えば、すべての推定戦略における推定結果を算出した後、ユーザから行動監視結果を得て両者を比較するなど、各推定戦略における推定結果の算出、及びユーザによる行動監視結果の取得の順番は、特に限定されるものではない。

続いて、上述のように取得されたすべての推定戦略における推定結果とユーザの行動監視結果との比較結果に基づいて、それぞれの推定戦略の結果集計が行われる（ステップＳ４０７：推定戦略ごとの結果集計）。ここでは、例えば、それぞれの推定戦略を用いた場合の推定結果の正解率（推定結果を提案した場合に、ユーザの動作を支援することができたか否かを示す情報）が算出される。また、さらに、各推定戦略における過去の推定結果の正解率などが参照され、各推定戦略の成功頻度の計算が行われる（ステップＳ４０８：推定戦略ごとの成功頻度計算）。

例えば、上述のステップＳ４０７では、今回の対象イベントに関し、各推定戦略の推定結果の正解率が数値化され、上述のステップＳ４０８では、各推定戦略における今回及び過去５回の推定結果を考慮した各推定戦略を利用した場合の成功頻度（例えば、今回及び過去５回の推定結果の正解率の平均値など）が計算される。

そして、ステップＳ４０８で計算された各推定戦略の成功頻度が、所定の基準値を超えたか否かが判別され（ステップＳ４０９：基準を超えた？）、成功頻度が所定の基準値を超えた推定戦略が存在する場合には、この推定戦略を利用して、ユーザの嗜好などを適切に反映した支援を行うことが可能であると判断され、ユーザに対して推定結果を実際に提案する提案状態に設定される（ステップＳ４１０：提案状態に設定）。なお、この場合、初期推定戦略として、この推定戦略が設定されることが望ましい。一方、成功頻度が所定の基準値を超えた推定戦略が存在しない場合には、この対象イベントに関して、再び、提案待機状態が設定される（ステップＳ４１１：提案待機状態に設定）。

また、ステップＳ４０４で蓄積された履歴を利用して、推定部１０１における推定の精度向上を図るための学習動作が行われる。したがって、提案待機状態では、学習動作は、主に、ユーザが行った行動の監視結果に基づいて行われる。また、ステップＳ４０８において計算される成功頻度として、連続して成功した回数や、ある時間における成功の回数（すなわち、時間当たりの成功頻度）、さらには、これらの回数にユーザの反応（ユーザの評価）を重み付けした情報などを採用することが可能である。

以上のように、提案待機状態の場合には、所定の対象イベントに対する推定を行い、この推定結果をユーザに提案せずに、この推定結果をユーザが行った操作と比較して各推定戦略を利用した推定の信頼性をチェックし、推定結果が一定の基準に達した場合に、設定を提案状態に変更することによって、ユーザに対する推定結果の提案を開始できるようにしている。

ここで、提案状態及び提案待機状態における具体的な動作例について説明する。なお、以下では、図５に示すような通信機能を有する車載装置に対するコンテンツ配信サービスを一例に挙げて説明する。

例えば、ユーザが車両の運転を開始した状態で、車載装置がコンテンツ配信サービスを利用して楽曲コンテンツを取得し、この楽曲コンテンツを車両内で再生するように設定されているものとする。このとき、例えば、車載装置におけるコンテンツ配信サービスの利用を示す信号が、対象イベントとしてユーザ支援装置１００に供給される。

この対象イベントに係る動作状態が、例えば提案状態になっている場合には、ユーザ支援装置１００は、所定の初期推定戦略に基づいて、ユーザが聴取したいと思われる楽曲コンテンツを推定し、楽曲コンテンツの曲名などをユーザに報知する。なお、このとき、複数の楽曲コンテンツのリストを報知してもよい。

ユーザが、ユーザ支援装置１００によって提案された楽曲コンテンツを了承した場合には、この楽曲コンテンツの再生が行われることになるが、ユーザが、ユーザ支援装置１００によって提案された楽曲コンテンツを了承しなかった場合には、ユーザ支援装置１００は、推定戦略を変更して、別の推定方法によって、再度、ユーザが聴取したいと思われる楽曲コンテンツの推定を行って、その推定結果をユーザに提案する。なお、図３のステップＳ３０８における参照される所定の回数が１回の場合には、再提案は行われない。

推定戦略を変更して行われた推定の結果がユーザに了承された場合には、この楽曲コンテンツの再生が行われる。なお、次回、同一の対象イベントが発生したときに、このユーザに了承された推定結果が得られた推定戦略を初期推定戦略として採用することも可能である。

一方、所定の回数だけ推定戦略を変更した場合でも、ユーザの了承が得られる推定結果を提案することができなかった場合には、再提案の動作を終了し、失敗頻度を計算して、次回、同一の対象イベントが発生したときに、ユーザに対して推定結果の提案を行う提案状態となるか、あるいは、ユーザに対して推定結果の提案を行わずに、推定の精度を高める提案待機状態となるかを決定する。なお、例えば、再提案の動作を終了した後に、ユーザが、自ら楽曲コンテンツの再生動作を行わなかった場合には、このユーザの行動に基づいて、推定結果の精度が悪かったのではなくユーザが楽曲を聴取したくなかった（すなわち、提案タイミングが悪かった）と結論付け、この結論を履歴として蓄積するとともに、学習に反映させるようにすることも可能である。

このコンテンツ配信サービスを利用した楽曲コンテンツの再生に係るイベントが、提案待機状態に設定されている場合には、各推定戦略を利用して、ユーザが聴取したいと思われる楽曲コンテンツを推定する。そして、ユーザが操作を行い、実際に楽曲コンテンツの選択及び再生を行った場合に、ユーザ操作によって選択された楽曲コンテンツと、推定によって得られた楽曲コンテンツとの比較を行って、各推定戦略を利用して楽曲コンテンツを提案した場合に、ユーザからの了承が得られたかどうかの判定を行う。そして、この判定結果に基づいて、所定の推定戦略によって、ユーザが求める楽曲コンテンツをある程度推定することが可能であるという結論が得られた場合には、この対象イベントに係る状態を提案状態に設定して、次回に同一の対象イベントが発生した場合に、その推定戦略を利用した提案を行うようにする。

次に、上述の推定戦略について説明する。推定戦略とは、推定部１０１における推定方法（あるいは、推定部１０１が利用する推定モデル）であり、本発明では、例えば、提案状態において再提案を行う場合に、推定戦略を変更したり、提案待機状態において、複数の推定戦略の中から最適な推定戦略を探索したりするようにしている。以下、推定戦略として利用可能な例について説明する。

推定戦略は、例えば、推定部１０１における推定方法や推定モデルを指すものであり、推定戦略としては、例えば、以下に説明する「ランダムな属性変更」、「探索的変更」、「確度の高い属性を固定した属性変更」、「確度の低い属性変更」、「推定モデルの変更」、「クラスタリング手法におけるクラスタの変更」などが挙げられる。すなわち、図３のステップＳ３０９や図４のステップＳ４０６における推定戦略の変更は、上記のような推定戦略を変更することによって、異なる推定戦略による推定結果の導出を図っている。

例えば、上記の「ランダムな属性変更」とは、先に使用した推定戦略で設定した属性（例えば、昼食を取るための場所を提案する場合には、和食、洋食、中華などのジャンル、１５００円未満、１５００円以上２５００円未満、２５００円以上３５００円未満、３５００円以上などの平均予算の範囲などの様々な条件）をランダムに変更する手法であり、結果的に、先の推定結果とは全く異なる推定結果の導出を可能とする手法である。

また、例えば、上記の「探索的変更」とは、属性の変更によるユーザの反応を考慮して、より良い属性変更の態様を探索しながら、属性変更を行う手法である。具体的には、例えば、順番のある属性（例えば、上記の例では、平均予算の範囲）に関して、まず、中間の値やユーザが選択する傾向の高い値（例えば、１５００円以上２５００円未満）を最初に選択して推定及び提案を行う。そして、この推定結果が了承されない場合には、続いて、どちらかの方向（例えば、１５００円未満）に外れた属性に変更して推定を行って再提案し、例えば、満足度の入力などのユーザの反応に従って、属性の変更に係る方向が適切であったか否かを判定する。この判定の結果、次に推定を行う場合には、属性の変更に係る方向を考慮して、適切な方向に属性の変更を行ったうえで、推定結果を導き出し、再提案を行うことが可能となる。

また、例えば、上記の「確度の高い属性を固定した属性変更」とは、ユーザ嗜好情報などから、変更すべきではない属性（確度の高い属性）を判別したうえで、この確度の高い属性に関しては固定し、その他の属性を変更する手法である。具体的には、再提案を行う場合、例えば、ユーザが和食を好んでいることが分かっていれば、ジャンルに関しては和食に固定したうえで、その他の属性の変更を行い、再度、推定を行う手法である。なお、変更するその他の属性に関しては、上述の「ランダムな属性変更」に係る手法、又は「探索的変更」に係る手法によって、属性変更を行ってもよい。

また、例えば、上記の「確度の低い属性変更」とは、ユーザの状況などによって大きく変更する可能性がある属性（確度の低い属性）を判別し、特に、この確度の低い属性に関して、変更を行ったうえで、再度、推定及び再提案を行う手法である。具体的には、再提案を行う場合、例えば、ユーザが食事のジャンルに関して大きく変わる傾向にある（あるいは、ほとんど気にしていない）ことが分かっていれば、ジャンルという属性を大きく変えて、再度、推定を行う手法である。なお、その他の属性に関しては、上述の「ランダムな属性変更」、「探索的変更」、「確度の高い属性を固定した属性変更」などを組み合わせて属性変更を行うことも可能である。

また、例えば、上記の「推定モデルの変更」とは、ベイジアンネットワークなどの推定モデル（ユーザモデル）を利用した推定を行う際に、再提案を行う場合に、推定モデルを変更したうえで、再度、推定を行う手法である。すなわち、この手法では、ベイジアンネットワークで利用する推定モデルの変更を行うことによって、推定で使用されるユーザ嗜好情報の変更が行われる。

また、例えば、上記の「クラスタリング手法におけるクラスタの変更」とは、推定にクラスタリング手法を利用して、より良いクラスタを探索する手法である。クラスタリング手法は、類似の傾向にある提案可能な候補を１つの集合（クラスタ）とみなす手法であり、ここでは、最初に選択した提案可能な候補に係るユーザの反応に従って、同一クラスタ内の異なる提案可能な候補を再提案するか、あるいは、別のクラスタ内の提案可能な候補を再提案するかの判断を行うようにする。

なお、提案内容は、上述の各推定戦略に限定されず、他の推定手法を推定戦略として採用することも可能である。また、本明細書では、上述の各推定戦略の変更に加えて、同一の推定戦略における態様の変更（具体的には、属性変更や、推定モデルの変更など）も推定戦略とみなすことにする。すなわち、推定戦略の変更とは、上述の各推定戦略（「ランダムな属性変更」、「探索的変更」、「確度の高い属性を固定した属性変更」、「確度の低い属性変更」、「推定モデルの変更」、「クラスタリング手法におけるクラスタの変更」）間における手法の変更、及び、各手法における属性変更や推定モデル変更、クラスタ変更などを包含するものである。すなわち、本発明では、異なる推定結果が導出される可能性がある手法の変更や属性の変更を、推定戦略の変更と呼んでいる。

また、本発明は、推定技術を利用するあらゆる技術分野に適用可能である。すなわち、本発明は、上述のようなコンテンツ配信におけるコンテンツの推薦、店舗の推薦、機器制御の態様の決定以外にも、例えば、立ち寄りポイントの推薦、画面に表示するアイコンや説明の表示態様、ユーザをサポートするヘルプ情報などの情報提供、推定結果の提案に係る表現方法、広告配信方法、エンジンやエアコンの調整、シフトのアップ・ダウンの調整、シートの位置や角度の調整、照明の照度の調整、経路の推薦、旅行プラン（ドライブプラン）の決定などにおける推定技術にも適用可能である。

以上、説明したように、本発明によれば、推定結果の提案によって動作の支援を行う際、提案内容が了承されなかった場合における再提案の様々な態様が提供される。例えば、提案内容が了承されなかった場合に、所定の時間は、再提案を行わないように制御することによって、提案に対するユーザの信頼を損なわないようにすることが可能である。また、提案が失敗に終わる回数や率が、一定の基準（一定の精度）以下となった場合には、提案を行わずに、適切な推定戦略の模索や提案内容の精度向上のための学習のみを行う提案待機状態となり、推定の精度が一定の基準に達した場合に、再度、提案状態に戻るようにすることによって、提案に対するユーザの信頼を損なわないようにすることが可能である。

本発明に係るユーザ支援装置及びユーザ支援方法は、ユーザからの信頼を損なわずに、ユーザによって継続的に利用されるようにするものであり、ユーザの属性、嗜好、履歴、状況などのユーザ条件に応じて、ユーザに提案するための適切なコンテンツの選択や機器制御などのユーザ支援を行うための技術分野に適用可能である。

本発明の実施の形態におけるユーザ支援装置の構成を示すブロック図である。 本発明の実施の形態におけるユーザ支援装置の状態遷移の一例を示すフローチャートである。 本発明の実施の形態における提案状態に係る動作の一例を示すフローチャートである。 本発明の実施の形態における提案待機状態に係る動作の一例を示すフローチャートである。 従来の技術において、推定技術を利用したコンテンツ提供動作を模式的に示すシステム構成図である。 従来の技術において、推定技術を利用した機器制御の態様の決定動作を模式的に示すシステム構成図である。

符号の説明

１００ ユーザ支援装置
１０１ 推定部
１０２ イベント判別部
１０３ 状況検出部
１０４ 履歴格納部
１０５ ユーザ嗜好格納部（ユーザモデル格納部）
１０６ 戦略決定部
１０７ 戦略アルゴリズム格納部
１０８ ユーザ操作入力部
１０９ 推定結果出力部
１１０ 状態決定部
１１１ 状態格納部
１１２ タイマ
５０１、６０１ 車両
５０２ サービスプロバイダ
５０３ コンテンツプロバイダ

Claims (26)

1. 所定のイベントに対するユーザ支援を行うために、前記ユーザ支援の支援内容を決定するユーザ支援装置であって、
   前記ユーザ支援を行う提案状態及び前記ユーザ支援を行わない提案待機状態のいずれか一方の状態を決定する状態決定手段と、
   前記状態決定手段によって決定された前記状態を示す情報を格納する状態格納手段と、
   前記状態格納手段に、前記提案状態を示す情報が格納されている場合には、前記ユーザ支援の支援内容を決定するとともに前記ユーザ支援の支援内容の報知を行い、前記提案待機状態を示す情報が格納されている場合には、前記ユーザ支援の支援内容の決定を行うものの前記ユーザ支援の支援内容の報知を行わないように制御するユーザ支援内容決定手段とを、
   有するユーザ支援装置。
2. 前記状態決定手段が、前記イベントごとに前記状態を決定し、前記状態格納手段が、前記イベントごとに前記状態を示す情報を格納するように構成されている請求項１に記載のユーザ支援装置。
3. 時間を計測する計時手段を有しており、
   前記提案待機状態を示す情報が前記状態格納手段に格納されてから所定の時間以上経過している場合には、前記状態格納手段に格納されている前記提案待機状態を示す情報を、前記提案状態を示す情報に変更するように構成されている請求項１又は２に記載のユーザ支援装置。
4. 前記提案状態において、報知された前記ユーザ支援の支援内容に対する前記ユーザの反応を取得することによって、前記ユーザ支援に係る精度向上を図る学習を行うように構成されている請求項１から３のいずれか１つに記載のユーザ支援装置。
5. 前記提案状態において、報知された前記ユーザ支援の支援内容に対する前記ユーザの反応を取得して、前記ユーザの反応に基づいて前記ユーザ支援の支援内容の精度を計算し、前記精度の計算結果が所定の基準を下回った場合に、前記イベントの状態を前記提案待機状態とするように構成されている請求項４に記載のユーザ支援装置。
6. 前記提案待機状態において、前記イベントに対して行われた前記ユーザの行動監視結果を取得するか、あるいは前記イベントに対して行われた前記ユーザの行動に関する問い合わせを行うことによって、前記ユーザ支援に係る精度向上を図る学習を行うように構成されている請求項１から５のいずれか１つに記載のユーザ支援装置。
7. 前記提案待機状態において、前記イベントに対して行われた前記ユーザの行動監視結果又は前記問い合わせの結果に基づいて前記ユーザ支援の支援内容の精度を計算し、前記精度の計算結果が所定の基準を超えた場合に、前記イベントの状態を前記提案状態とするように構成されている請求項６に記載のユーザ支援装置。
8. 前記ユーザ支援内容決定手段が、複数の推定戦略を実行することが可能なように構成されている請求項１から７のいずれか１つに記載のユーザ支援装置。
9. 複数の前記推定戦略を順次用いて、前記ユーザ支援の支援内容を決定して報知するか、あるいは複数の前記推定戦略のうちの少なくとも２つ以上の前記推定戦略を用いて、前記ユーザ支援の支援内容を決定し、前記少なくとも２つ以上の前記推定戦略を用いて決定された前記ユーザ支援の支援内容を同時に報知するように構成されている請求項８に記載のユーザ支援装置。
10. 前記提案状態において、報知した前記ユーザ支援の支援内容が了承されなかった場合には、異なる前記推定戦略を用いて、再度、前記ユーザ支援の支援内容を決定して報知を行うように構成されている請求項８に記載のユーザ支援装置。
11. 前記提案状態において、複数の前記推定戦略のそれぞれに関する前記ユーザ支援に係る優先度を計算し、前記優先度の高い前記推定戦略を選択して前記ユーザ支援の支援内容を決定するように構成されている請求項８から１０のいずれか１つに記載のユーザ支援装置。
12. 前記提案待機状態において、複数の前記推定戦略を用いて前記ユーザ支援の支援内容を決定するとともに、複数の前記推定戦略を用いて決定された前記ユーザ支援の支援内容のそれぞれの優先度を計算し、複数の前記推定戦略の少なくとも１つに係る前記優先度が所定の基準を超えた場合には、前記イベントの状態を、前記優先度が所定の基準を超えた前記推定戦略を利用した前記ユーザ支援の支援内容の決定及び報知を行う前記提案状態とするように構成されている請求項８から１１のいずれか１つに記載のユーザ支援装置。
13. 所定のイベントに対するユーザ支援を行うために、前記ユーザ支援の支援内容を決定するユーザ支援装置であって、
    複数の推定戦略のそれぞれに基づいて、前記ユーザ支援の支援内容を決定するとともに前記ユーザ支援の支援内容の報知を行うユーザ支援内容提案手段を有し、
    報知した前記ユーザ支援の支援内容が了承されなかった場合には、異なる前記推定戦略を用いて、再度、前記ユーザ支援の支援内容を決定して報知を行うように構成されているユーザ支援装置。
14. 所定のイベントに対するユーザ支援を行うために、前記ユーザ支援の支援内容を決定するユーザ支援方法であって、
    前記ユーザ支援を行う提案状態及び前記ユーザ支援を行わない提案待機状態のいずれか一方の状態を決定する状態決定ステップと、
    前記状態決定ステップで決定された前記状態を示す情報を格納する状態格納ステップと、
    前記状態格納ステップで格納された情報が前記提案状態を示す情報である場合には、前記ユーザ支援の支援内容を決定するとともに前記ユーザ支援の支援内容の報知を行い、前記状態格納ステップで格納された情報が前記提案待機状態を示す情報である場合には、前記ユーザ支援の支援内容の決定を行うものの前記ユーザ支援の支援内容の報知を行わないように制御するユーザ支援内容決定ステップとを、
    有するユーザ支援方法。
15. 前記状態決定ステップにおいて前記イベントごとに前記状態を決定し、前記状態格納ステップにおいて前記イベントごとに前記状態を示す情報を格納する請求項１４に記載のユーザ支援方法。
16. 前記状態格納ステップで前記提案待機状態を示す情報が格納されてから所定の時間以上経過している場合には、前記状態格納ステップで格納された前記提案待機状態を示す情報を、前記提案状態を示す情報に変更する状態変更ステップを有する請求項１４又は１５に記載のユーザ支援方法。
17. 前記提案状態において、報知された前記ユーザ支援の支援内容に対する前記ユーザの反応を取得するユーザ反応取得ステップと、
    前記ユーザ反応取得ステップで取得した前記ユーザの反応に基づいて、前記ユーザ支援に係る精度向上を図る学習を行う学習ステップを有する請求項１４から１６のいずれか１つに記載のユーザ支援方法。
18. 前記提案状態において、報知された前記ユーザ支援の支援内容に対する前記ユーザの反応を取得するユーザ反応取得ステップと、
    前記ユーザ反応取得ステップで取得した前記ユーザの反応に基づいて前記ユーザ支援の支援内容の精度を計算し、前記精度の計算結果が所定の基準を下回った場合に、前記イベントの状態を前記提案待機状態とする提案待機状態設定ステップとを、
    有する請求項１７に記載のユーザ支援方法。
19. 前記提案待機状態において、前記イベントに対して行われた前記ユーザの行動監視結果を取得するか、あるいは前記イベントに対して行われた前記ユーザの行動に関する問い合わせを行うユーザ行動結果取得ステップと、
    前記ユーザ行動結果取得ステップで取得した前記ユーザの行動監視結果又は前記問い合わせの結果に基づいて、前記ユーザ支援に係る精度向上を図る学習を行う学習ステップを有する請求項１４から１８のいずれか１つに記載のユーザ支援方法。
20. 前記ユーザ行動結果取得ステップで取得した前記ユーザの行動監視結果又は前記問い合わせの結果に基づいて、前記ユーザ支援の支援内容の精度を計算し、前記精度の計算結果が所定の基準を超えた場合に、前記イベントの状態を前記提案状態とする提案状態設定ステップを有する請求項１９に記載のユーザ支援方法。
21. 前記ユーザ支援内容決定手段が、複数の推定戦略を実行することが可能なように構成されている請求項１４から２０のいずれか１つに記載のユーザ支援方法。
22. 複数の前記推定戦略を順次用いて、前記ユーザ支援の支援内容を決定して報知するか、あるいは複数の前記推定戦略のうちの少なくとも２つ以上の前記推定戦略を用いて、前記ユーザ支援の支援内容を決定し、前記少なくとも２つ以上の前記推定戦略を用いて決定された前記ユーザ支援の支援内容を同時に報知する複数提案ステップを有する請求項２１に記載のユーザ支援方法。
23. 前記提案状態において、前記ユーザ支援内容決定ステップで報知した前記ユーザ支援の支援内容が了承されなかった場合には、異なる前記ユーザ支援の支援内容を導出する可能性のある別の推定戦略を用いて、再度、前記ユーザ支援の支援内容を決定して報知を行う再提案ステップを有する請求項２１に記載のユーザ支援方法。
24. 前記提案状態において、複数の前記推定戦略のそれぞれに関する前記ユーザ支援に係る優先度を計算し、前記優先度の高い前記推定戦略を選択して前記ユーザ支援の支援内容を決定する推定戦略選択ステップを有する請求項２１から２３のいずれか1つに記載のユーザ支援方法。
25. 前記提案待機状態において、前記ユーザ支援内容決定ステップで異なる前記ユーザ支援の支援内容を導出する可能性のある複数の前記推定戦略を用いて前記ユーザ支援の支援内容を決定し、複数の前記推定戦略を用いて決定された前記ユーザ支援の支援内容のそれぞれの優先度を計算し、複数の前記推定戦略の少なくとも１つに係る前記優先度が所定の基準を超えた場合には、前記イベントの状態を、前記優先度が所定の基準を超えた前記推定戦略を利用した前記ユーザ支援の支援内容の決定及び報知を行う前記提案状態とする戦略別提案状態設定ステップを有する請求項２１から２４のいずれか１つに記載のユーザ支援方法。
26. 所定のイベントに対するユーザ支援を行うために、前記ユーザ支援の支援内容を決定するユーザ支援方法であって、
    複数の推定戦略のそれぞれに基づいて、前記ユーザ支援の支援内容を決定するとともに前記ユーザ支援の支援内容の報知を行うユーザ支援内容提案ステップと、
    報知した前記ユーザ支援の支援内容が了承されなかった場合には、異なる前記推定戦略を用いて、再度、前記ユーザ支援の支援内容を決定して報知を行う再提案ステップとを、 有するユーザ支援方法。

Images