JP2018120474A - 情報提供装置、情報提供方法および情報提供プログラム - Google Patents

Abstract

【課題】信頼性の高いイベントを提案することができる情報提供装置、情報提供方法および情報提供プログラムを提供すること。
【解決手段】実施形態に係る情報提供装置は、取得部と、抽出部と、判定部と、提案部とを備える。取得部は、ユーザの予定に関する予定情報を取得する。抽出部は、取得部によって取得された予定情報における予定の開始時刻までに実行可能なイベントを抽出する。判定部は、取得部によって取得された予定情報における予定の種別に基づき、抽出部によって抽出されたイベントの実行が予定を実行するうえで適切であるか否かを判定する。提案部は、判定部の判定結果に基づいてユーザに対してイベントを提案する。
【選択図】図２

Description

本発明は、情報提供装置、情報提供方法および情報提供プログラムに関する。

従来、例えばユーザが登録した予定に関する予定情報に基づいてユーザに対して新たなイベントを提案する情報提供装置がある。情報提供装置は、例えば次の予定の開始時刻までに実行可能なイベントを提案する（たとえば、特許文献１参照）。

特開２０１３−２８４４号公報

しかしながら、従来の技術では、時間的に次の予定に間に合うイベントを提案しているにすぎず、次の予定に支障を来すか否かまでは考慮されていなかった。このため、従来は、次の予定に支障を来すような信頼性の低いイベントがユーザに対して提案されるおそれがあった。

本発明は、上記に鑑みてなされたものであって、信頼性の高いイベントを提案することができる情報提供装置、情報提供方法および情報提供プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る情報提供装置は、取得部と、抽出部と、判定部と、提案部とを備える。取得部は、ユーザの予定に関する予定情報を取得する。抽出部は、前記取得部によって取得された前記予定情報における前記予定の開始時刻までに実行可能なイベントを抽出する。判定部は、前記取得部によって取得された前記予定情報における前記予定の種別に基づき、前記抽出部によって抽出された前記イベントの実行が前記予定を実行するうえで適切であるか否かを判定する。提案部は、前記判定部の判定結果に基づいて前記ユーザに対して前記イベントを提案する。

本発明によれば、信頼性の高いイベントを提案することができる。

図１は、実施形態に係る情報提供方法の概要を示す図である。 図２は、実施形態に係る情報提供装置の構成を示すブロック図である。 図３は、予定情報の説明図である。 図４は、イベントリスト情報の説明図である。 図５は、対応情報の説明図である。 図６は、習慣情報の説明図である。 図７は、適切性評価の説明図である。 図８は、実施形態に係る情報提供装置が実行する提案処理の処理手順を示すフローチャートである。 図９は、変形例に係る情報提供システムの構成を示すブロック図である。

以下、添付図面を参照して、本願の開示する情報提供装置、情報提供方法および情報提供プログラムの実施形態を詳細に説明する。なお、この実施形態により本発明が限定されるものではない。

まず、図１を用いて、実施形態に係る情報提供方法の概要について説明する。図１は、実施形態に係る情報提供方法の概要を示す図である。図１には、実施形態に係る情報提供装置１の一例としてスマートフォン等の携帯端末を示している。また、情報提供装置１の画面（図１上図）には、所有者であるユーザの次の予定の開始時刻が近いことを示すリマインド画面が表示されている。

また、図１には、例えばユーザが今後実行したいイベントを含むイベントリスト情報３３を示しているが、イベントリスト情報３３の詳細については図５を用いて後述する。

実施形態に係る情報提供方法では、例えばユーザの次の予定までに実行可能なイベントをイベントリスト情報３３から抽出するとともに、抽出したイベントをユーザに対して提案することが適切であるか否かを判定し、判定結果に基づいてイベントの提案を行う。

ここで、従来の情報提供方法について説明する。従来の情報提供方法では、例えば、次の予定の開始時刻までの空き時間に実行可能なイベントを提案していた。しかしながら、従来は、時間的に次の予定に間に合うイベントを提案しているにすぎず、次の予定に支障を来すか否かまでは考慮されていなかった。

例えば、取引先との面談を控えているユーザに対して昼食を提案する場合に、イベントリスト情報の中から、餃子を食べるイベントを提案してしまい、口臭などの身だしなみを気にするユーザにとっては、イベントの提案を受け入れにくい場合があった。つまり、従来は、次の予定に支障を来すような信頼性の低いイベントがユーザに対して提案されるおそれがあった。

そこで、実施形態に係る情報提供方法では、時間的に実行可能なイベントのうち、次の予定に支障を来さないようなイベントを提案可能とした。具体的には、実施形態に係る情報提供装置１は、まず、ユーザの予定に関する予定情報３１（図２参照）を取得する（ステップＳ１）。

つづいて、実施形態に係る情報提供方法では、取得した予定情報３１における予定の開始時刻までに実行可能なイベントを抽出する（ステップＳ２）。ここでは、イベントリスト情報３３の中から「餃子を食べる」と「うどんを食べる」が抽出されたとする。

つづいて、実施形態に係る情報提供装置１は、取得した予定情報３１における予定の種別に基づき、抽出したイベントの実行が予定を実行するうえで適切であるか否かを判定する（ステップＳ３）。

例えば、次の予定の種別が面談であるため、「餃子を食べる」と「うどんを食べる」のうち、口臭が強くなる「餃子を食べる」を不適切であると判定し、口臭などの身だしなみに影響しない「うどんを食べる」を適切であると判定する。

そして、実施形態に係る情報提供装置１は、判定結果に基づいてユーザに対してイベントを提案する（ステップＳ４）。例えば、図１に示すように、情報提供装置１の画面（図１下図）に「うどんを食べる」に関するイベントの情報を表示させる。

つまり、実施形態に係る情報提供方法では、時間的に実行可能なイベントのうち、次の予定に支障を来すようなイベント（例えば「餃子を食べる」等）を提案の候補から排除する。したがって、次の予定に支障を来さないような信頼性の高いイベントをユーザに対して提案することができる。

なお、実施形態に係る情報提供装置１は、予定情報３１に含まれる考慮すべき事象（身だしなみ等）の情報と、イベントリスト情報３３に含まれるイベントの実行に伴う事象（口臭等）の情報とに基づいて判定を行うが、詳細は図３等を用いて後述する。

また、実施形態に係る情報提供装置１は、ユーザの過去の行動履歴から習慣化された行動を抽出し、習慣化された行動を上記した予定として推定しているが、かかる点については、図４を用いて後述する。

次に、図２を参照して、実施形態に係る情報提供装置１の構成について詳細に説明する。図２は、実施形態に係る情報提供装置１の構成を示すブロック図である。図２に示すように、実施形態に係る情報提供装置１は、ライフログ装置１０と、入出力装置１１とに接続される。まず、情報提供装置１以外の構成について説明する。

ライフログ装置１０は、各種センサの情報に基づいてユーザの行動や生体情報等を行動履歴情報１０１として記録する電子装置である。例えば、ライフログ装置１０は、モーションセンサからの情報に基づいてユーザの動きを検出することで、ユーザの行動を記録する。

また、例えば、ライフログ装置１０は、脈拍、呼吸、血圧、体温等の生体情報を記録することができる。さらに、ライフログ装置１０は、ＧＰＳ（Global Positioning System）衛星等からユーザの位置情報を取得し、ユーザの行動や生体情報に対応付けて記録することができる。

入出力装置１１は、例えばタッチパネルディスプレイ等の入力機能および出力機能を兼ね備えた電子装置である。入出力装置１１は、例えばユーザに提案するイベントの情報を情報提供装置１から取得し、図示しない表示部に表示する。

また、入出力装置１１は、提案したイベントに対する適切性評価を受け付けるための表示画面を表示するとともに、かかる表示画面へのユーザ操作に応じた情報を情報提供装置１へ出力するが、かかる点については、図７を用いて後述する。

次に、実施形態に係る情報提供装置１について説明する。実施形態に係る情報提供装置１は、制御部２と、記憶部３とを備える。制御部２は、取得部２１と、習慣予定推定部２２と、抽出部２３と、判定部２４と、決定部２５と、提案部２６と、受付部２７とを備える。記憶部３は、予定情報３１と、習慣情報３２と、イベントリスト情報３３と、対応情報３４と、評価情報３５とを記憶する。

ここで、情報提供装置１は、たとえば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）、入出力ポートなどを有するコンピュータや各種の回路を含む。

コンピュータのＣＰＵは、たとえば、ＲＯＭに記憶されたプログラムを読み出して実行することによって、制御部２の取得部２１、習慣予定推定部２２、抽出部２３、判定部２４、決定部２５、提案部２６および受付部２７として機能する。

また、制御部２の取得部２１、習慣予定推定部２２、抽出部２３、判定部２４、決定部２５、提案部２６および受付部２７の少なくともいずれか一つまたは全部をＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアで構成することもできる。

また、記憶部３は、たとえば、ＲＡＭやＨＤＤに対応する。ＲＡＭやＨＤＤは、予定情報３１、習慣情報３２、イベントリスト情報３３、対応情報３４、評価情報３５および各種プログラムの情報等を記憶することができる。なお、情報提供装置１は、有線や無線のネットワークで接続された他のコンピュータや可搬型記録媒体を介して上記したプログラムや各種情報を取得することとしてもよい。

ここで、図３〜図６を用いて、記憶部３が記憶する予定情報３１、習慣情報３２、イベントリスト情報３３および対応情報３４について説明する。なお、評価情報３５については後述する。

まず、図３を用いて、予定情報３１について説明する。図３は、予定情報３１の説明図である。図３には、予定情報３１の一例を示している。予定情報３１は、例えばユーザ操作によって予め登録される予定の情報である。

図３に示すように、予定情報３１には、「月日」、「予定時間」、「件名」、「内容」および「考慮事象」といった予定の種別が含まれる。「月日」は、ユーザの予定が実行される日付を示す。

「予定時間」は、予定の開始時刻から終了時刻までの予想される期間を示す。「件名」は、予定のタイトルを示す。「内容」は、予定の内容を示す。「考慮事象」は、予定を実行するうえで考慮すべき事象に関する情報（以下、「考慮情報」と記載）である。

例えば、図３に示すように、件名が「顧客デモ」の場合、考慮事象が「身だしなみ」となっている。これは、例えば商品提案を行う取引先に失礼がないように身だしなみに注意すべきであることを意味する。

つまり、「考慮事象」は、例えば、予定を実行するにあたりユーザが注意すべき点を示している。「考慮事象」は、後述する「実行事象」（図５参照）とともに判定部２４の判定基準となるが、かかる点については後述する。

また、「考慮事象」は、例えばユーザが予定を登録する際に、複数ある考慮事象の選択肢からユーザが手動で選択することで登録される。なお、考慮事象の選択肢は、予め定められた考慮事象のみであってもよく、あるいは、ユーザ自身が作成した考慮事象であってもよい。

また、「考慮事象」は、ユーザが手動で選択する場合に限らず、例えば「月日」、「予定時間」、「件名」、「内容」等に基づいて自動で作成された事象が登録されてもよい。なお、考慮事象が自動で作成される場合や、ユーザ自身によって新たな実行事象が作成された場合には、後述する対応情報３４にも作成された新たな考慮事象を反映するようにする。

なお、予定情報３１は、情報提供装置１の所有者であるユーザのみの予定が登録されることとしたが、例えば、他のユーザと予定情報３１を共有することとしてもよい。かかる点については、図９を用いて後述する。

次に、図４を用いて、習慣情報３２について説明する。図４は、習慣情報３２の説明図である。図４には、習慣情報３２の一例を示している。習慣情報３２は、後述する習慣予定推定部２２によって生成される。

図４に示すように、習慣情報３２には、「頻度」、「予定時間」、「件名」、「内容」、「考慮事象」等といった項目が含まれる。「頻度」は、習慣化された行動が過去に行われた頻度を示す。なお、「予定時間」、「件名」、「内容」、「考慮事象」の説明については、既に上述している（図３参照）ため省略する。

次に、図５を用いて、イベントリスト情報３３について説明する。図５は、イベントリスト情報３３の説明図である。図５には、イベントリスト情報３３の一例を示している。イベントリスト情報３３は、例えばユーザが実行したい（食べたいものや買いたいもの）イベントの情報を含み、ユーザ操作によって予め登録される情報である。

図５に示すように、イベントリスト情報３３には、「項目」、「内容」、「所要時間」、「ジャンル」、「実行事象」といった項目が含まれる。

「項目」は、イベントの項目名称を示す。「内容」は、イベントの内容を示す。「所要時間」は、イベントを実行する場合に要する時間を示す。「ジャンル」は、イベントの分類内容を示す。「実行事象」は、イベントの実行に伴う事象に関する情報（以下、「実行情報」と記載）を示す。

例えば、図５に示すように、イベントの項目が「餃子を食べる」の場合、実行事象が「口臭」となっている。これは、餃子を食べることで、ユーザの口臭が強くなる懸念があることを意味している。

つまり、「実行事象」とは、例えばイベントを実行することで変化するユーザの身体的または精神的状態を示す。「実行事象」は、例えばユーザがイベントを登録する際に、複数ある実行事象の選択肢からユーザが手動で選択することでイベントリスト情報３３に登録される。なお、実行事象の選択肢は、予め定められた実行事象のみであってもよく、あるいは、ユーザ自身が作成した実行事象であってもよい。

また、「実行事象」は、ユーザが手動で選択する場合に限らず、例えば「項目」、「内容」、「所要時間」、「ジャンル」等に基づいて自動で作成された事象が登録されてもよい。

なお、イベントリスト情報３３は、ユーザによって予め登録される情報としたが、例えば、図示しないサーバ装置等からイベントリスト情報３３を取得することとしてもよい。また、例えば、ユーザがやるべきことをリスト化した（いわゆるTO-DOリスト）情報をイベントリスト情報３３としてもよい。

次に、図６を用いて、対応情報３４について説明する。図６は、対応情報３４の説明図である。図６には、対応情報３４の一例を示している。対応情報３４は、例えばユーザ操作によって予め登録される情報である。

図６に示すように、対応情報３４は、「考慮事象」（図３等）および「実行事象」（図５）の対応関係を示す。例えば、図６に示すように、考慮事象の「身だしなみ」は、実行事象の「口臭」、「発汗」が対応している。

対応情報３４において、各「実行事象」をどの「考慮事象」に対応付けするかの対応関係は、例えばユーザの手動操作によって決定されるが、例えば考慮事象および実行事象の属性に基づいて自動で対応関係が決定されてもよい。

次に、制御部２について説明する。制御部２は、予定情報３１を取得することで、ユーザの予定の開始時刻までに実行可能なイベントを抽出するとともに、抽出したイベントの実行が予定を実行するうえで適切であるか否かを判定し、判定結果に基づいてユーザに対してイベントを提案する。

取得部２１は、ユーザの予定に関する予定情報３１を取得する。なお、取得部２１は、記憶部３に予め記憶された予定情報３１を取得することとしてもよいが、例えばサーバ装置１００（図９参照）から予定情報３１を取得することとしてもよい。かかる点については、図９を用いて後述する。

習慣予定推定部２２は、ユーザによって記録された過去の行動履歴である行動履歴情報１０１を取得することでユーザの習慣化された行動に関する習慣情報３２を予定として推定する。

具体的には、習慣予定推定部２２は、ライフログ装置１０に記録された行動履歴情報１０１に基づいてユーザの習慣化された行動を推定することで習慣情報３２を生成する。つまり、習慣予定推定部２２は、ユーザが過去に定期的に繰り返し行う行動を習慣化された行動として抽出し、抽出した行動をユーザの予定として推定する。

これにより、後述する提案部２６が適切なイベントを提案することで、ユーザの習慣的な行動が妨げられることなく実行可能となる。習慣予定推定部２２は、推定した予定を示す習慣情報３２を抽出部２３へ出力するとともに、記憶部３に習慣情報３２を記憶させる。

抽出部２３は、取得部２１によって取得された予定情報３１における予定の開始時刻までに実行可能なイベントを抽出する。具体的には、抽出部２３は、まず、予定情報３１または習慣情報３２から次の予定の開始時刻を取得する。

つづいて、抽出部２３は、イベントリスト情報３３の「所要時間」に基づいて次の予定の開始時刻までに実行可能なイベントを抽出する。ここでいう「開始時刻までに実行可能」とは、開始時刻通りに次の予定を行うことを指す。

つまり、抽出部２３は、例えば次の予定の場所までの移動時間等を考慮している。言い換えれば、抽出部２３は、次の予定の開始時刻までの残り時間が「所要時間」以上である場合でも、開始時刻までに次の予定の場所に到着できない可能性が高ければ抽出しない。

さらに、抽出部２３は、「ジャンル」に基づいてイベントを抽出してもよい。具体的には、抽出部２３は、現在時刻が昼食等の食事の時間帯であれば、ジャンルが「食事」のイベントを抽出する。一方、抽出部２３は、現在時刻が食事の時間帯以外であれば、ジャンルが「食事」のイベントを抽出対象から除外する。

なお、抽出部２３は、１つのイベントを抽出してもよく、あるいはユーザが選択できるように２つ以上のイベントを抽出してもよい。また、抽出部２３は、複数のイベントを組み合わせてもよい。

判定部２４は、抽出部２３によって抽出されたイベントの実行がユーザの予定を実行するうえで適切であるか否かを判定する。具体的には、判定部２４は、予定情報３１の考慮すべき事象に関する情報である考慮情報とイベントリスト情報３３のイベントの実行に伴う事象の情報である実行情報とに基づいて判定を行う。

例えば、ユーザの次の予定が１３時から「顧客デモ」（図３参照）であったとする。さらに、抽出部２３によって「餃子を食べる」と「うどんを食べる」（以下、両者を総称して抽出イベントと記載）が抽出されたとする（図５参照）。

かかる場合に、判定部２４は、対応情報３４を参照して判定を行う。具体的には、判定部２４は、対応情報３４に基づいて抽出イベントの「実行事象」と予定情報３１の「顧客デモ」における「考慮事象」とが対応しているか否かを判定する。

例えば、「餃子を食べる」の場合、実行事象である「口臭」と、考慮事象である「身だしなみ」とが対応している。つまり、判定部２４は、実行事象と考慮事象とが対応している場合、「餃子を食べる」のイベントの実行が予定を実行するうえで不適切であると判定する。

これにより、後述する提案部２６によって「餃子を食べる」のイベントがユーザに提案されないため、ユーザが「顧客デモ」の前に餃子を食べて口臭が強くなることが防止される。すなわち、次の予定に支障を来すイベントを提案対象から除外できるため、提案するイベントの信頼性を高めることができる。

また、「うどんを食べる」の場合、実行事象は無い。したがって、考慮事象である「身だしなみ」と対応しない。つまり、判定部２４は、実行事象と考慮事象とが対応していない場合、「うどんを食べる」のイベントの実行が予定を実行するうえで適切であると判定する。

なお、判定部２４によって不適切であると判定されたイベントは、提案部２６によって提案されないとしたが、複数のイベントが提案される場合には、提案の優先順位を下げて提案される場合があるが、かかる点については後述する。

また、上記では、イベントリスト情報３３の実行事象が悪影響である場合の判定部２４の判定処理について説明したが、実行事象が好影響（例えば、コーヒーブレイクによる気分のリフレッシュ等）である場合においても判定処理を行うことができる。

かかる場合、判定部２４は、好影響である実行事象と考慮事象とが対応する場合に、イベントの実行が予定を実行するうえで適切であると判定する。判定部２４は、判定結果を決定部２５および提案部２６へ出力する。

決定部２５は、抽出部２３によって複数のイベントが抽出された場合に、判定部２４の判定結果に基づいてイベント毎に提案の優先順位を決定する。具体的には、決定部２５は、判定部２４によって不適切であると判定されたイベントの優先順位を低くする。一方、決定部２５は、判定部２４によって適切であると判定されたイベントの優先順位を高くする。

これにより、複数のイベントが抽出された場合であっても、後述する提案部２６によって優先順位の高いイベントのみをユーザに対して提案できる。

また、例えば適切であると判定されたイベントがなかった場合に、優先順位の低いイベントを提案するとともに、優先順位が低い旨をユーザに対して通知することもできるため、提案するイベントの信頼性を高めることができる。

なお、決定部２５は、判定部２４によって不適切であると判定されたイベントであっても、イベントの実行事象が解消可能である場合には、優先順位を高くしてもよい。

例えば、「餃子を食べる」の場合、「○○飯店」以外に口臭が比較的強くならない他店舗（例えば、ニンニクを使用していない餃子の販売等）が存在する場合等には、決定部２５は、優先順位を高くする。なお、他店舗の情報は、例えばインターネットにおけるウェブサイトを検索することで取得可能である。

また、決定部２５は、例えば、「餃子を食べる」のイベントの時刻から次の予定の開始時刻まで所定時間（例えば３時間）以上空く場合には、優先順位を高くしてもよい。これは、一定時間経つと、餃子による口臭が軽減されるためである。

このように、イベントの実行事象が解消可能である場合に、提案の優先順位を高くすることで、様々な選択肢の提案を行うことができる。決定部２５は、決定した優先順位の情報を提案部２６へ出力する。

提案部２６は、判定部２４の判定結果に基づいてユーザに対してイベントを提案する。具体的には、提案部２６は、判定部２４によって適切であると判定されたイベントをユーザに対して提案する。一方、提案部２６は、判定部２４によって不適切であると判定されたイベントについては、提案対象から除外する。これにより、不適切なイベントが提案されることを防止することができる。

なお、提案部２６は、判定部２４によって不適切であると判定されたイベントについては、決定部２５によって決定された優先順位に基づいて提案することとしてもよい。

また、提案部２６は、過去に提案したイベントを考慮してもよい。具体的には、提案部２６は、所定の予定の前に、提案したイベントをユーザが実行したことを蓄積し、次回以降に同じ予定があった場合に、かかるイベントを優先的に提案する。

例えば、提案部２６は、次の予定が「顧客デモ」の場合に、ユーザが頻繁にうどんを食べていることを蓄積している場合には、「うどんを食べる」を優先的に提案する。

また、提案部２６は、次の予定を考慮して、イベントを提案することとしたが、例えば、前の予定も併せて考慮したイベントを提案してもよく、次の予定のさらに次の予定を考慮したイベントを提案してもよい。

また、提案部２６は、後述する受付部２７が受け付けた適切性評価に基づいてイベントを提案することができるが、かかる点については、図７を用いて後述する。

受付部２７は、提案部２６によってイベントが提案された場合に、かかるイベントに対する適切性評価をユーザから受け付ける。適切性評価とは、ユーザに対して行った提案がどの程度適切であったかを示す度合いである。ここで、図７を用いて、適切性評価について説明する。

図７は、適切性評価の説明図である。図７には、スマートフォン等の情報提供装置１に適切性評価を受け付けるための画面が表示されている。かかる画面は、例えば提案部２６による提案の所定時間後に表示される。

図７に示すように、受付部２７は、例えば、ユーザが表示された画面に対して評価点を入力し、入力された評価点を適切性評価として受け付け、評価情報３５として記憶部３に記憶させる。

そして、提案部２６は、受付部２７が受け付けた適切性評価に基づいてイベントを提案する。例えば、提案部２６は、記憶部３に記憶された評価情報３５におけるイベントの評価点が所定の点数以下である場合には、次回以降の同様の予定の際に、かかるイベントを提案の対象から除外する。

つまり、ユーザの評価を次回以降のイベントの提案にフィードバックできるため、より信頼性の高いイベントを提案することができる。

なお、受付部２７は、提案部２６によって複数のイベントが提案された場合に、イベント毎に評価点を受け付けてもよい。つまり、受付部２７は、提案された複数のイベントのうち、ユーザが実行しなかったイベントに対する適切性評価を受け付ける。

具体的には、受付部２７は、提案部２６によって提案された複数のイベントのうち、実行されたイベントをユーザ操作によって受け付けるとともに、上記した評価点を受け付ける。

かかる場合に、例えばユーザが実行しなかったイベントに対して実行しなかった理由（例えば、今回実行しなかったが、他のこういう状況では実行する等）を入力させる。このように、ユーザが実行しなかったイベントに対する適切性評価を受け付けることで、次回以降に反映されるイベントの信頼性を高めることができる。

次に、図８を用いて、実施形態に係る情報提供装置１が実行する提案処理の処理手順について説明する。図８は、実施形態に係る情報提供装置１が実行する提案処理の処理手順を示すフローチャートである。

図８に示すように、まず、取得部２１は、ユーザの予定に関する予定情報３１を取得する（ステップＳ１０１）。つづいて、抽出部２３は、予定の開始時刻までに実行可能なイベントを抽出する（ステップＳ１０２）。

つづいて、判定部２４は、取得部２１によって取得された予定情報３１における予定の種別に基づき、抽出部２３によって抽出されたイベントの実行が予定を実行するうえで適切であるか否かを判定する（ステップＳ１０３）。

決定部２５は、判定部２４によってイベントの実行が予定を実行するうえで適切であると判定された場合（ステップＳ１０３，Ｙｅｓ）、抽出されたイベントが複数であるか否かを判定する（ステップＳ１０４）。

提案部２６は、抽出されたイベントが複数ではない場合（ステップＳ１０４，Ｎｏ）、つまりイベントが１つであった場合、かかるイベントを提案し（ステップＳ１０５）、処理を終了する。

一方、ステップＳ１０３において、決定部２５は、判定部２４によってイベントの実行が予定を実行するうえで不適切であると判定された場合（ステップＳ１０３，Ｎｏ）、かかるイベントの提案の優先順位を低くすることで決定する（ステップＳ１０６）。

また、ステップＳ１０４において、抽出したイベントが複数であった場合（ステップＳ１０４，Ｙｅｓ）、イベント毎の優先順位を決定する（ステップＳ１０６）。

上述してきたように、実施形態に係る情報提供装置１は、取得部２１と、抽出部２３と、判定部２４と、提案部２６とを備える。取得部２１は、ユーザの予定に関する予定情報３１を取得する。抽出部２３は、取得部２１によって取得された予定情報３１における予定の開始時刻までに実行可能なイベントを抽出する。判定部２４は、取得部２１によって取得された予定情報３１の種別に基づき、抽出部２３によって抽出されたイベントの実行が予定を実行するうえで適切であるか否かを判定する。提案部２６は、判定部２４の判定結果に基づいてユーザに対してイベントを提案する。これにより、次の予定に支障を来すような信頼性の低いイベントがユーザに対して提案されないため、信頼性の高いイベントを提案することができる。

上述した実施形態では、情報提供装置１がスマートフォン等の携帯端末である場合について説明したが、情報提供装置１は、例えば、カーナビゲーション装置であってもよい。かかる場合、予定情報３１における予定は、設定された目的地とし、イベントリスト情報３３におけるイベントは、例えば経由地とすることができる。

また、上述した実施形態では、予定情報３１には、例えば情報提供装置１を所有しているユーザの予定のみが含まれることとしたが、例えば複数のユーザの予定情報３１を共有することとしてもよい。かかる点について図９を用いて説明する。

図９は、実施形態の変形例に係る情報提供システムＳの構成を示すブロック図である。図９に示すように、情報提供システムＳは、サーバ装置１００と、複数の情報提供装置１とを備える。複数の情報提供装置１は、それぞれ異なるユーザＵ１，Ｕ２が対応付けされている。複数の情報提供装置１は、例えば家族単位や会社単位、友人グループ単位などで区分けすることができる。

例えば、複数の情報提供装置１それぞれは、サーバ装置１００に対して予定情報３１およびイベントリスト情報３３を送信する。サーバ装置１００は、各情報提供装置１の予定情報３１およびイベントリスト情報３３を一元管理する。また、サーバ装置１００は、一元管理している予定情報３１およびイベントリスト情報３３に基づいて各情報提供装置１のユーザＵ１，Ｕ２に対してイベントを提案する。

例えば、ユーザＵ１，Ｕ２が家族である場合に、同じ時間が空いていた時に、サーバ装置１００は、各ユーザＵ１，Ｕ２に対して同じイベント（例えば食事）を提案する。このように、情報提供システムＳによれば、他のユーザＵ１，Ｕ２の予定を考慮したイベントの提案を行うことができる。

また、例えば、各ユーザＵ１，Ｕ２が実行したイベントを他のユーザＵ１，Ｕ２と共有することもできる。例えば、ユーザＵ１およびユーザＵ２のイベントリスト情報３３に「日用品の買い物」が含まれていたとする。

そして、ユーザＵ１が「日用品の買い物」を実行したとする。かかる場合に、サーバ装置１００は、他のユーザＵ２のイベントリスト情報３３の「日用品の買い物」の優先度を低くする。これにより、各ユーザＵ１，Ｕ２が同じイベントを実行することを防止できる。

さらなる効果や変形例は、当業者によって容易に導き出すことができる。このため、本発明のより広範な態様は、以上のように表しかつ記述した特定の詳細および代表的な実施形態に限定されるものではない。したがって、添付の特許請求の範囲およびその均等物によって定義される総括的な発明の概念の精神または範囲から逸脱することなく、様々な変更が可能である。

１ 情報提供装置
２ 制御部
３ 記憶部
２１ 取得部
２２ 習慣予定推定部
２３ 抽出部
２４ 判定部
２５ 決定部
２６ 提案部
２７ 受付部
３１ 予定情報
３２ 習慣情報
３３ イベントリスト情報
３４ 対応情報
３５ 評価情報

Claims (8)

1. ユーザの予定に関する予定情報を取得する取得部と、
   前記取得部によって取得された前記予定情報における前記予定の開始時刻までに実行可能なイベントを抽出する抽出部と、
   前記取得部によって取得された前記予定情報における前記予定の種別に基づき、前記抽出部によって抽出された前記イベントの実行が前記予定を実行するうえで適切であるか否かを判定する判定部と、
   前記判定部の判定結果に基づいて前記ユーザに対して前記イベントを提案する提案部と
   を備えることを特徴とする情報提供装置。
2. 前記予定情報は、
   前記予定を実行するうえで考慮すべき事象に関する考慮情報を含み、
   前記イベントは、
   前記イベントの実行に伴う事象に関する実行情報を含み、
   前記判定部は、
   前記考慮情報および前記実行情報の対応関係に基づいて判定を行うこと
   を特徴とする請求項１に記載の情報提供装置。
3. 前記ユーザによって記録された過去の行動履歴である行動履歴情報を取得することで前記ユーザの習慣化された行動に関する習慣情報を前記予定として推定する習慣予定推定部をさらに備え、
   前記抽出部は、
   前記習慣予定推定部によって推定された前記習慣情報における前記予定の開始時刻までに実行可能な前記イベントを抽出すること
   を特徴とする請求項１または２に記載の情報提供装置。
4. 前記提案部によって前記イベントが提案された場合に、当該イベントに対する適切性評価を前記ユーザから受け付ける受付部をさらに備え、
   前記提案部は、
   前記受付部が受け付けた前記適切性評価に基づいて前記イベントを提案すること
   を特徴とする請求項１〜３のいずれか一つに記載の情報提供装置。
5. 前記提案部は、
   複数の前記イベントを提案し、
   前記受付部は、
   前記複数のイベントのうち、前記ユーザが実行しなかった前記イベントに対する前記適切性評価を受け付けること
   を特徴とする請求項４に記載の情報提供装置。
6. 前記抽出部によって複数の前記イベントが抽出された場合に、前記判定部の判定結果に基づいて前記イベント毎に提案の優先順位を決定する決定部をさらに備え、
   前記決定部は、
   前記判定部によって不適切であると判定された前記イベントの前記優先順位を低くし、
   前記提案部は、
   前記決定部によって決定された前記優先順位に基づいて前記イベントを提案すること
   を特徴とする請求項１〜５のいずれか一つに記載の情報提供装置。
7. ユーザが行動する予定の情報である予定情報を取得する取得工程と、
   前記取得工程によって取得された前記予定情報における前記予定の開始時刻までに実行可能なイベントを抽出する抽出工程と、
   前記取得工程によって取得された前記予定情報における前記予定の種別に基づき、前記抽出工程によって抽出された前記イベントを前記ユーザが実行することが前記予定を実行するうえで適切であるか否かを判定する判定工程と、
   前記判定工程によって適切であると判定された場合に、前記ユーザに対して前記イベントを提案する提案工程と
   を含むことを特徴とする情報提供方法。
8. ユーザが行動する予定の情報である予定情報を取得する取得手順と、
   前記取得手順によって取得された前記予定情報における前記予定の開始時刻までに実行可能なイベントを抽出する抽出手順と、
   前記取得手順によって取得された前記予定情報における前記予定の種別に基づき、前記抽出手順によって抽出された前記イベントを前記ユーザが実行することが前記予定を実行するうえで適切であるか否かを判定する判定手順と、
   前記判定手順によって適切であると判定された場合に、前記ユーザに対して前記イベントを提案する提案手順と
   をコンピュータに実行させることを特徴とする情報提供プログラム。

Images