(57)【要約】【課題】ユーザ自身が嗜好モデルに介入してルール変更を反映させることが可能な情報処理装置、制御方法、およびプログラムを提供する。【解決手段】ユーザコンテキストに基づいてユーザの嗜好モデルを生成する生成部と、前記生成された嗜好モデルに対するユーザからの変更入力に応じて、前記嗜好モデルを変更する変更部と、を備える、情報処理装置。【選択図】図１
2016122276.tif 000002
【特許請求の範囲】
【請求項１】
ユーザコンテキストに基づいてユーザの嗜好モデルを生成する生成部と、
前記生成された嗜好モデルに対するユーザからの変更入力に応じて、前記嗜好モデルを変更する変更部と、
を備える、情報処理装置。
【請求項２】
前記情報処理装置は、
前記嗜好モデルの変更入力画面を前記ユーザに提示するよう制御する提示制御部をさらに備える、請求項１に記載の情報処理装置。
【請求項３】
前記提示制御部は、前記ユーザからの変更入力に応じて行った前記嗜好モデルの変更結果を提示する、請求項２に記載の情報処理装置。
【請求項４】
前記変更入力画面は、前記嗜好モデルの生成に用いられたユーザコンテキストの一覧を示す画面であって、
前記変更部は、前記ユーザコンテキストに対するユーザによるデータ修正を、前記嗜好モデルに反映させて変更する、請求項２に記載の情報処理装置。
【請求項５】
前記データ修正は、前記ユーザコンテキストの変更、追加、または削除を含む、請求項４に記載の情報処理装置。
【請求項６】
前記嗜好モデルは、アプリケーションの起動予測モデルであって、
前記変更入力画面は、前記ユーザコンテキストに基づく前記アプリケーションの起動予測モデルを形成する起動ログを示す画面である、請求項２に記載の情報処理装置。
【請求項７】
前記起動ログは、所定期間内における起動アプリケーション、および、起動時のユーザ情報または起動時の環境情報の少なくともいずれかを紐付けた情報である、請求項６に記載の情報処理装置。
【請求項８】
前記起動時のユーザ情報は、ユーザ行動を含む、請求項７に記載の情報処理装置。
【請求項９】
前記起動時の環境情報は、起動日時、起動場所、または起動時の天候の少なくともいずれかを含む、請求項７に記載の情報処理装置。
【請求項１０】
前記変更入力画面は、起動アプリケーション、および、起動時のユーザ情報または起動時の環境情報の少なくともいずれかを示すアイコンが所定周期で配置される、請求項６に記載の情報処理装置。
【請求項１１】
前記変更部は、前記変更入力画面に表示された前記アイコンに対するユーザによる修正操作を変更入力として受付ける、請求項１０に記載の情報処理装置。
【請求項１２】
前記修正操作は、追加操作、移動操作、または削除操作を含む、請求項１１に記載の情報処理装置。
【請求項１３】
前記提示制御部は、前記アイコンが選択された際に、当該アイコンに紐付けられているユーザコンテキストの一覧を提示する、請求項１０に記載の情報処理装置。
【請求項１４】
前記変更部は、前記ユーザコンテキストの一覧に対するデータ修正を変更入力として受け付ける、請求項１３に記載の情報処理装置。
【請求項１５】
前記データ修正は、データの変更、追加、または削除を含む、請求項１４に記載の情報処理装置。
【請求項１６】
前記変更部は、前記ユーザコンテキストに対するデータ修正として、未来のデータの入力も受付け可能である、請求項４に記載の情報処理装置。
【請求項１７】
前記提示制御部は、提示デバイスに応じた前記変更入力画面を提示する、請求項２に記載の情報処理装置。
【請求項１８】
前記ユーザコンテキストは、アプリケーションが起動された直前に起動した他のアプリケーション、アプリケーションの起動時における環境情報、ユーザ情報、周辺通信機器との接続情報、アプリケーションからの通知情報、または機器状態情報を少なくとも含む、請求項２に記載の情報処理装置。
【請求項１９】
ユーザコンテキストに基づいてユーザの嗜好モデルを生成することと、
前記生成された嗜好モデルに対するユーザからの変更入力に応じて、前記嗜好モデルを変更することと、
を含む、制御方法。
【請求項２０】
コンピュータを、
ユーザコンテキストに基づいてユーザの嗜好モデルを生成する生成部と、
前記生成された嗜好モデルに対するユーザからの変更入力に応じて、前記嗜好モデルを変更する変更部と、
として機能させるための、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置、制御方法、およびプログラムに関する。
【背景技術】
【０００２】
従来、ユーザのコンテンツ視聴履歴や購買履歴等に基づいて予測、推薦モデルを構築し、ユーザに合った情報を推薦する情報推薦システムが提案されている。
【０００３】
このようなシステムに関し、例えば下記引用文献１では、レストランやテレビ番組等のコンテンツに関連する場所、ジャンル等の属性情報を使用したユーザとのインタラクションを介して、ユーザに推薦するコンテンツの絞り込みを行うことが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−４０２６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来の情報推薦システムでは、出力結果を自分の嗜好に合わせて意図的にフィルタリングし、提示されたくないコンテンツを出力結果から排除するようにする操作に限られており、ユーザが自身の予測、推薦モデルに介入することはできなかった。
【０００６】
そこで、本開示では、ユーザ自身が嗜好モデルに介入してルール変更を反映させることが可能な情報処理装置、制御方法、およびプログラムを提案する。
【課題を解決するための手段】
【０００７】
本開示によれば、ユーザコンテキストに基づいてユーザの嗜好モデルを生成する生成部と、前記生成された嗜好モデルに対するユーザからの変更入力に応じて、前記嗜好モデルを変更する変更部と、を備える情報処理装置を提案する。
【０００８】
本開示によれば、ユーザコンテキストに基づいてユーザの嗜好モデルを生成することと
前記生成された嗜好モデルに対するユーザからの変更入力に応じて、前記嗜好モデルを変更することと、を含む制御方法を提案する。
【０００９】
本開示によれば、コンピュータを、ユーザコンテキストに基づいてユーザの嗜好モデルを生成する生成部と、前記生成された嗜好モデルに対するユーザからの変更入力に応じて、前記嗜好モデルを変更する変更部と、として機能させるためのプログラムを提案する。
【発明の効果】
【００１０】
以上説明したように本開示によれば、ユーザ自身が嗜好モデルに介入してルール変更を反映させることが可能となる。
【００１１】
なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。
【図面の簡単な説明】
【００１２】
【図１】本開示の一実施形態による情報処理システムの概要を説明する図である。
【図２】本実施形態によるサーバの構成の一例を示すブロック図である。
【図３】本実施形態によるＡＰＰ起動ログＤＢに格納されているコンテキスト情報の一例を示す図である。
【図４】本実施形態によるユーザ端末の構成の一例を示すブロック図である
【図５】本実施形態によるアプリケーション起動予測モデルの生成処理を示すフローチャートである。
【図６】本実施形態によるアプリケーション起動予測モデルの変更処理を示すフローチャートである。
【図７】本実施形態による第１のログ修正画面例を示す図である。
【図８】本実施形態による第１のログ修正画面におけるログ修正の実行について説明する図である。
【図９】本実施形態による第２のログ修正画面例の基本形態を示す図である。
【図１０】予測モデルを１日周期で示すＤａｉｌｙ−ＵＩを示す図である。
【図１１】予測モデルを１週間周期で示すＷｅｅｋｌｙ−ＵＩを示す図である。
【図１２】第２のログ修正画面の拡大・縮小操作について説明する図である。
【図１３】第２のログ修正画面におけるデータ削除操作について説明する図である。
【図１４】第２のログ修正画面における時刻のデータ変更操作について説明する図である。
【図１５】第２のログ修正画面における時刻以外のデータ変更操作について説明する図である。
【図１６】第２のログ修正画面におけるデータ追加操作について説明する図である。
【図１７】第２のログ修正画面における変更確認ボタンの表示について説明する図である。
【図１８】第２のログ修正画面における変更結果の表示について説明する図である。
【図１９】本実施形態による第３のログ修正画面について説明する図である。
【図２０】本実施形態による第３のログ修正画面の変形例について説明する図である。
【発明を実施するための形態】
【００１３】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１４】
また、説明は以下の順序で行うものとする。
１．本開示の一実施形態による情報処理システムの概要
２．基本構成
３．動作処理
４．ログ修正画面例
４−１．第１のログ修正画面例
４−２．第２のログ修正画面例
４−３．第３のログ修正画面例
５．まとめ
【００１５】
＜＜１．本開示の一実施形態による情報処理システムの概要＞＞
まず、本開示の一実施形態による情報処理システムの概要を図１に示して説明する。図１に示すように、本実施形態による情報処理システムは、ユーザが所持するユーザ端末２と、ユーザに応じた嗜好モデルの生成およびユーザからの変更入力（例えば起動ログの修正）に基づく嗜好モデルの再学習（すなわち変更）を行う情報処理装置であるサーバ１とを含む。サーバ１とユーザ端末２は、例えばネットワーク（不図示）を介して接続され得る。
【００１６】
サーバ１は、ユーザへの情報提示に用いる嗜好モデルとして、例えばアプリケーション（以下、ＡＰＰとも称す）の起動予測モデルを生成する。アプリケーションの起動予測モデルは、どのような状況においてユーザがどのアプリケーションを起動するかを予測するためのモデルであって、これを用いることで、サーバ１は、例えばユーザ端末２の操作表示部２５に表示されるホーム画面において、起動が予測されるアプリケーションのアイコンを提示することができる。
【００１７】
（背景）
ここで、従来の情報推薦システムでは、出力結果を自分の嗜好に合わせて意図的にフィルタリングし、提示されたくないコンテンツを出力結果から排除するようにする操作に限られており、ユーザが自身の予測、推薦モデルに介入することはできなかった。
【００１８】
そこで、本実施形態による情報処理システムでは、ユーザが自身の予測モデルに介入してルール変更を行えるようにすることで、よりユーザに適した予測モデルを生成することができる。
【００１９】
具体的には、例えば図１に示すように、ユーザ端末２の操作表示部２５に、予測モデルのログ修正画面（ＵＩ：ユーザインタフェース）を提示し、ユーザが直感的に自身の予測モデルを変更することができるようにする。ログ修正画面の詳細については、図７〜図２０を参照して後述する。
【００２０】
以上、本開示の一実施形態による情報処理システムの概要について説明した。なお、ユーザ端末２は、図１に示すようなスマートフォンに限定されない。例えばユーザ端末２は、タブレット端末、携帯電話端末、ＰＤＡ（Personal  Digital  Assistant）、ＰＣ（Personal  Computer）、携帯用音楽プレーヤー、携帯用ゲーム機、首掛け型ヘッドセット、またはウェアラブル端末（ＨＭＤ（Head  Mounted  Display）、スマートアイグラス、スマートバンド、スマートウォッチ、ネックレス型デバイス、Ｅａｒ型デバイス等）であってもよい。続いて、本開示の一実施形態による情報処理システムに含まれるサーバ１およびユーザ端末２の基本構成について図２〜４を参照して説明する。
【００２１】
＜＜２．基本構成＞＞
＜２−１．サーバの構成＞
図２は、本実施形態によるサーバ１の構成の一例を示すブロック図である。図２に示すように、サーバ１は、制御部１０、通信部１２、ＡＰＰ起動ログＤＢ（データベース）１３、および予測モデルＤＢ１４を有する。
【００２２】
（制御部１０）
制御部１０は、例えばＣＰＵ（Central  Processing  Unit）、ＲＯＭ（Read  Only  Memory）、ＲＡＭ（Random  Access  Memory）、不揮発性メモリ、インターフェース部を備えたマイクロコンピュータにより構成され、サーバ１の各構成を制御する。具体的には、本実施形態による制御部１０は、図２に示すように、ログ収集部１０ａ、モデル生成部１０ｂ、予測部１０ｃ、提示制御部１０ｄ、および変更部１０ｅとして機能する。
【００２３】
ログ収集部１０ａは、モデル生成部１０ｂによるアプリケーション起動予測モデルの生成に用いられるユーザコンテキストを、ユーザ端末２から収集し、起動ログとしてＡＰＰ起動ログＤＢ１３に格納する。収集するユーザコンテキストは、例えば、アプリケーションが起動された直前に起動した他のアプリケーション、アプリケーションの起動時における環境情報、ユーザ情報、周辺通信機器との接続情報、アプリケーションからの通知情報、または機器状態情報である。アプリケーションの起動時における環境情報とは、例えばアプリケーションの起動日時、起動時の天候、または場所情報（すなわち位置情報）である。また、ユーザ情報とは、例えばユーザ行動情報（すなわち行動認識情報）である。また、周辺通信機器との接続情報とは、例えば周辺Ｗｉ−Ｆｉ（登録商標）情報（すなわちＷｉ−ｆｉアクセスポイント情報）、または周辺Ｂｌｕｅｔｏｏｔｈ（登録商標）情報である。また、機器状態情報とは、ユーザ端末２の電源状態（充電状態）や、ヘッドセットの状態等である。
【００２４】
モデル生成部１０ｂは、ユーザが起動する可能性の高いアプリケーションを予測するためのモデルを、ＡＰＰ起動ログＤＢ１３に格納されたユーザコンテキスト（コンテキスト情報）を用いて生成する。例えば、モデル生成部１０ｂは、ユーザコンテキストの種別に応じた粒度でコンテキスト情報を離散化し、離散化したコンテキスト情報とアプリケーションの起動回数に基づき、下記式１に示すナイーブな確率モデルを使用してアプリケーションの予測モデルを構築する。コンテキスト情報の離散化は、例えば時刻情報であれば、１日２４時間の連続値を３０分単位または１時間単位で区切った離散値に置き替えることで実現される。なおコンテキスト情報の離散化は、上記ログ収集部１０ａで予め行い、離散化したコンテキスト情報をＡＰＰ起動ログＤＢ１３に記憶するようにしてもよい。
【００２５】
（式１）
2016122276.tif 000003
【００２６】
上記式１において、左辺はコンテキスト情報が与えられた際に予測すべきアプリケーションの確率を表し、右辺のように分解される。右辺第２項は、コンテキスト情報の条件に関わらずアプリケーションを起動した確率、すなわちアプリケーションの起動比率を表す。一方、右辺第１項は、アプリケーションが起動された際のコンテキスト情報の条件を表す。かかる右辺第１項は、例えば下記式２のようになる。
【００２７】
（式２）
2016122276.tif 000004
【００２８】
上記式２は、あるアプリケーション“ｘｘｘ”が起動した際の時刻（コンテキスト情報の一例）が１９：３０−２０：００の間であった確率を表す。上記式２における“ｆｒｅｑ”はアプリケーション“ｘｘｘ”が起動した際の時刻が１９：３０−２０：００の間であった頻度を示す。また、上記式２における“ｔｉｍｅ  ｓｌｏｔ”は全ての時刻を示す。
【００２９】
このように、モデル生成部１０ｂによるアプリケーション起動予測モデルの生成（すなわち学習）は、上記式１右辺の第１項と第２項の確率を算出することに相当し、モデル生成部１０ｂはコンテキスト情報とアプリケーションをキーとした頻度表を生成することとなる。
【００３０】
また、モデル生成部１０ｂは、生成した予測モデルを予測モデルＤＢ１４に格納する。
【００３１】
予測部１０ｃは、予測モデルＤＢ１４に格納されたユーザの予測モデルに従って、アプリケーションの起動予測を行い、予測結果をユーザ端末２に出力する。例えば、予測部１０ｃは、ユーザ端末２から現在のユーザコンテキスト（例えば時刻、曜日、直近起動アプリケーションといったコンテキスト情報）を取得した際に、全てのアプリケーションに関して対数を取った上記式１を算出して最も値が高いアプリケーションから順に起動予測結果として出力してもよい。なお対数を使用する理由としては、アプリケーションの起動頻度が０になる確率が出現した際に式１の掛け算で０にならないためであって、最大確率を判断する際に単調増加関数を掛けても確率値の大小関係に差は出ない。
【００３２】
提示制御部１０ｄは、ユーザの予測モデルをユーザ自身が変更することが可能なＵＩをユーザ端末２に提示するよう制御する機能を有する。予測モデルに介入できるＵＩは、例えば上記式１の右辺第１項の確率をユーザが修正するためのＧＵＩ（Graphical  User  Interface）であってもよい。ユーザは、当該ＧＵＩを通じて、上記式１の右辺第１項の各コンテキストを修正することが可能である。なお本実施形態による予測モデルの変更入力が可能なＵＩは、上記式１の右辺第１項の確率を修正するＧＵＩに限定されない。
【００３３】
変更部１０ｅは、提示制御部１０ｄにより提示されたＵＩに対するユーザによる変更入力（すなわち起動ログの変更、追加、または削除を含む修正）を予測モデルに反映させ、予測モデルＤＢ１４に格納されているユーザの予測モデルを変更（再学習）する機能を有する。また、変更部１０ｅは、過去の起動ログの修正の他、未来の起動ログのデータ入力（新規追加登録）を受付けることも可能である。
【００３４】
（通信部１２）
通信部１２は、無線／有線により外部装置と接続し、データの送受信を行う機能を有する。本実施形態による通信部１２は、例えばユーザ端末２と接続し、ユーザコンテキストの受信や、予測部１０ｃによる予測結果の送信、および提示制御部１０ｄの制御に従った予測モデルの変更入力が可能なＵＩ情報の送信を行う。
【００３５】
（ＡＰＰ起動ログＤＢ１３）
ＡＰＰ起動ログＤＢ１３は、ログ収集部１０ａにより収集されたアプリケーション起動ログ（すなわちコンテキスト情報）を格納する。ここで、図３に、ＡＰＰ起動ログＤＢ１３に格納されているコンテキスト情報の一例を示す。図３に示すように、例えば起動したアプリケーションに関する起動ログとして、直近に起動したアプリケーション、起動した曜日、および起動した時刻が紐付けられている。なお図３に示す時刻情報は１時間単位で離散化されている。
【００３６】
（予測モデルＤＢ１４）
予測モデルＤＢ１４は、アプリケーションの起動予測を行うための予測モデルを格納する。予測モデルは、モデル生成部１０ｂによりユーザ毎に生成され、予測モデルＤＢ１４に格納される。
【００３７】
以上、本実施形態によるサーバ１の具体的な構成について説明した。なお図２に示すサーバ１の構成は一例であって、本実施形態はこれに限定されず、例えばＡＰＰ起動ログＤＢ１３および予測モデルＤＢ１４が内部メモリではなく、ネットワーク上の外部メモリに格納されていてもよい。また、図２に示すサーバ１の一部または全ての構成がユーザ端末２に設けられていてもよい。また、モデル生成部１０ｂによる予測モデルの生成の一例として上記式１、式２を用いて説明したが、本実施形態はこれに限定されない。
【００３８】
＜２−２．ユーザ端末の構成＞
次に、ユーザ端末２の構成について図４を参照して説明する。図４は、本実施形態によるユーザ端末２の構成の一例を示すブロック図である。図４に示すように、ユーザ端末２は、制御部２０、通信部２２、現在位置計測部２３、動きセンサ２４、操作表示部２５、および記憶部２６を有する。
【００３９】
（制御部２０）
制御部２０は、例えばＣＰＵ、ＲＯＭ、ＲＡＭ、不揮発性メモリ、インターフェース部を備えたマイクロコンピュータにより構成され、ユーザ端末２の各構成を制御する。例えば制御部２０は、操作表示部２５から入力されたユーザ操作に従ってアプリケーションを起動し、操作表示部２５にアプリケーション画面を表示するよう制御する。また、制御部２０は、アプリケーションの起動ログとして、起動したアプリケーション、起動日時、起動した際の位置情報（例えば自宅、会社、学校、外等）、起動した際のユーザ行動（例えば歩いている、走っている、立っている、寝ている、座っている、自転車／自動車／電車に乗っている等）、および直前に起動したアプリケーションの情報を通信部２２からサーバ１に送信するよう制御する。
【００４０】
また、制御部２０は、サーバ１から受信した提示制御信号に基づいて、操作表示部２５にログ修正画面を表示し、ログ修正画面に対するユーザ操作を検出し、ユーザによる起動ログの修正を、変更入力情報としてサーバ１に送信するよう制御する。
【００４１】
（通信部２２）
通信部２２は、無線／有線により外部装置と接続し、データの送受信を行う機能を有する。本実施形態による通信部２２は、例えばサーバ１と接続し、制御部２０の制御に従ってアプリケーションの起動ログを送信したり、サーバ１からログ修正画面の提示制御信号を受信したりする。
【００４２】
（現在位置計測部２３）
現在位置計測部２３は、外部からの取得信号に基づいてユーザ端末２の現在位置を検知する機能を有する。具体的には、例えば現在位置計測部２３は、ＧＰＳ（Global  Positioning  System）測位部により実現され、ＧＰＳ衛星からの電波を受信して、ユーザ端末２が存在している位置を検知し、検知した位置情報を制御部２０に出力する。また、現在位置計測部２３は、ＧＰＳの他、例えばＷｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、携帯電話・ＰＨＳ・スマートフォン等との送受信、または近距離通信等により位置を検知するものであってもよい。
【００４３】
（動きセンサ２４）
動きセンサ２４は、ユーザ端末２の動きを検知する機能を有する。動きセンサ２４は、例えば３軸加速度センサ、ジャイロセンサ、地磁気センサ等により実現され、これらで検知されるデータを利用して、ユーザの行動（歩いている、走っている、立っている、寝ている、座っている、自転車／自動車／電車に乗っている等）を検知する。動きセンサ２４は、検知した行動情報を制御部２０に出力する。
【００４４】
（操作表示部２５）
操作表示部２５は、ユーザによる入力操作を検出する操作入力機能と、文字や画像その他の情報を表示する表示機能とを有する。操作表示部２５は、図１に示すようにタッチパネルディスプレイにより実現されてもよい。
【００４５】
また、操作入力機能と表示機能が別々に設けられていてもよい。この場合、操作入力機能は、例えばキーボード、テンキー、ボタン、スイッチ等により実現されてもよい。また、カメラ（不図示）を用いることでジェスチャー入力を実現することもできる。さらに、マイクロフォン（不図示）を用いることで音声入力を実現することもできる。また、操作入力機能は、複数種類の操作入力デバイスにより実現されてもよい。
【００４６】
（記憶部２６）
記憶部２６は、制御部２０による各種処理を実行するためのプログラムを格納する。また、記憶部２６は、アプリケーション起動ログを一時的に格納してもよい。
【００４７】
以上、本実施形態によるユーザ端末２の具体的な構成について説明した。なお図４に示すユーザ端末２の構成は一例であって、本実施形態はこれに限定されない。例えば、ユーザ端末２は、スピーカを備える構成により音声出力を可能としてもよいし、投影部を備える構成により画像の投影を可能としてもよい。
【００４８】
＜＜３．動作処理＞＞
続いて、本実施形態による情報処理システムの動作処理について、図５〜図６を参照して具体的に説明する。
【００４９】
図５は、本実施形態によるアプリケーション起動予測モデルの生成処理を示すフローチャートである。図５に示すように、まず、ステップＳ１０３において、サーバ１のログ収集部１０ａは、ユーザ端末２からアプリケーションの起動ログ（すなわちユーザコンテキスト）を収集する。収集された起動ログは、ＡＰＰ起動ログＤＢ１３に格納される。
【００５０】
次に、ステップＳ１０６において、モデル生成部１０ｂは、ユーザの起動ログに基づいて、アプリケーションの起動を予測する予測モデルを生成する。例えばモデル生成部１０ｂは、ユーザコンテキストに基づき、どのような状況の場合にどのアプリケーションの起動頻度が高いかを示す予測モデルを生成する。
【００５１】
次いで、ステップＳ１０９において、モデル生成部１０ｂは、生成したアプリケーション起動予測モデル予測モデルＤＢ１４に格納する。
【００５２】
続いて、上記生成した予測モデルのユーザによる変更について図６を参照して説明する。図６は、本実施形態によるアプリケーション起動予測モデルの変更処理を示すフローチャートである。
【００５３】
図６に示すように、まず、ステップＳ２０３において、ユーザ端末２の制御部２０は、ユーザによる情報提示アプリの選択に応じて、情報提示アプリケーションのＵＩを操作表示部２５に表示する。ここで、情報提示アプリケーションとは、状況に応じてユーザが起動すると予測されたアプリケーションのアイコンをホーム画面に表示するよう制御部２０に動作させるプログラムであって、通常は裏側で動作し、継続的にアプリケーション起動ログを収集する。
【００５４】
次に、ステップＳ２０６において、情報提示アプリケーションのＵＩに含まれるログ修正ボタンが選択されると、サーバ１の提示制御部１０ｄは、対象ユーザの予測モデルをユーザ自身が変更するためのログ修正画面をユーザ端末２の操作表示部２５に表示するよう制御する。ログ修正画面の具体例については後述する。
【００５５】
次いで、ステップＳ２０９において、ユーザ端末２の操作表示部２５は、ログ修正画面に対するログ修正入力操作を受け付け、ログ修正情報としてサーバ１に出力する。
【００５６】
続いて、ステップＳ２１２において、サーバ１の変更部１０ｅは、ログ修正情報をＡＰＰ起動ログＤＢ１３に反映させる。
【００５７】
次に、ステップＳ２１５において、変更部１０ｅは、修正が反映された起動ログに基づいて、予測モデルの再学習（変更）を行う。
【００５８】
そして、ステップＳ２１８において、提示制御部１０ｄは、ユーザによるログ修正により予測モデルがどのように変更されたかを示す変更結果（変更内容および変更理由）を、ユーザ端末２の操作表示部２５に提示するよう制御する。なお変更結果の表示例については後述する。
【００５９】
＜＜４．ログ修正画面例＞＞
続いて、本実施形態による予測モデルへの介入ＵＩ、すなわち予測モデルの変更を行うためのログ修正画面の具体例について、図７〜図２０を参照して説明する。
【００６０】
＜４−１．第１のログ修正画面例＞
図７は、第１のログ修正画面例を示す図である。第１のログ修正画面例は、例えば予測モデルを生成する上記式１の右辺第１項の確率をユーザが修正可能とするためのＧＵＩから形成される。
【００６１】
図７に示すように、例えばユーザ端末２の操作表示部２５に表示されるログ修正画面３０は、起動ログ（ユーザコンテキスト）の絞り込み条件を入力するためのアプリケーション名入力欄３１、コンテキストカテゴリ入力欄３２、コンテキスト値入力欄３３、検索ボタン３４、および起動ログ一覧３５を含む。各入力欄のうち少なくとも１以上に絞り込み条件を入力して検索ボタン３４をタップすることで、起動ログの絞り込みが可能となる。
【００６２】
図８は、第１のログ修正画面３０におけるログ修正の実行について説明する図である。図８左側に示すように、例えば入力欄３１にアプリケーション名「Ｇａｍｅ  Ａｐｐ」、入力欄３２にコンテキストカテゴリ「Ｔｉｍｅ  Ｏｆ  Ｄａｙ」、および入力欄３３にコンテキスト値「１３−１４」と入力して検索ボタン３４をタップすると、起動ログ一覧３５がフィルタされ、「Ｇａｍｅ  Ａｐｐ」のうち、「Ｔｉｍｅ  Ｏｆ  Ｄａｙ」の値が「１３−１４」の起動ログデータ３７が表示される。そして、ユーザは起動ログデータ３７に対して意図的に削除や変更の修正を入力し、決定ボタン３９をタップすることで変更入力を確定する。
【００６３】
例えば、実際は昼間にゲームアプリは利用しないが、昼食時にＧａｍｅ  Ａｐｐのアイコンをタップしてしまったログが残っている場合、ユーザは図８右側に示すように、意図的に該当ログを削除したり、実際にゲームアプリを利用する夜の時間帯にログを変更したりする。このように、ユーザは、ログ修正画面を通じて、上記式１の右辺第１項の各コンテキストを修正することが可能となる。
【００６４】
＜４−２．第２のログ修正画面例＞
（４−２−１．基本形態）
次に、本実施形態による第２のログ修正画面例について図９〜図１８を参照して説明する。図９は、第２のログ修正画面例の基本形態を示す図である。図９に示すように、第２のログ修正画面４０では、ユーザの起動ログに基づいて生成された予測モデルの詳細ＵＩ４１が多重円状で表現されている。図９に示す多重円は、コンテキストレイヤーであって、例えば内側から、アプリケーションレイヤー４０１、場所レイヤー４０２、天候レイヤー４０３、行動レイヤー４０４を示す。各レイヤーは、１日周期のＵＩ（Ｄａｉｌｙ−ＵＩ）の場合は１周で２４時間を示し、１週間周期のＵＩ（Ｗｅｅｋｌｙ−ＵＩ）の場合は１周で７日間を示す。また、Ｄａｉｌｙ−ＵＩ／Ｗｅｅｋｌｙ−ＵＩはユーザにより選択可能である。
【００６５】
図９に示すように、各レイヤー上には、Ａｐｐアイコンと、これに紐づくコンテキスト情報を示すユーザコンテキストアイコン（具体的には場所アイコン、天候アイコン、行動アイコン）が配置され、ユーザは、どのような状況でどのアプリケーションの起動が予測されるかを直感的に把握することができる。また、Ａｐｐアイコンと、これに紐付けられるユーザコンテキストアイコンを含むアイコン群４２は、図９に示すように、多重円と直交する直線上に並ぶよう配置される。
【００６６】
また、アプリケーションレイヤー４０１に配置されているＡｐｐアイコン４０１ａは音楽プレイヤーアプリケーションを示し、Ａｐｐアイコン４０１ｂはカメラアプリケーションを示し、Ａｐｐアイコン４０１ｃはライフログアプリケーションを示し、Ａｐｐアイコン４０１ｄは、音楽配信サービスアプリケーションを示す。また、場所レイヤー４０２に配置されている場所アイコン４０２ａは自宅に居ることを示し、場所アイコン４０２ｂは外に居ることを示し、場所アイコン４０２ｃは会社に居ることを示す。また、天候レイヤー４０３に配置されている天候アイコン４０３ａは天気が雨であることを示す。また、行動レイヤー４０４に配置されている行動アイコン４０４ａは座っていることを示し、４０４ｂは電車に乗っていることを示し、４０４ｃは歩いていることを示す。
【００６７】
（４−２−２．Ｄａｉｌｙ−ＵＩ）
次いで、予測モデルを１日周期で示すＤａｉｌｙ−ＵＩ４１ａについて図１０を参照して説明する。図１０に示すように、Ｄａｉｌｙ−ＵＩ４１ａは、１周が２４時間であって、００時００分００秒、６時００分００秒、１２時００分００秒、１８時００分００秒、２３時５９分５９秒といった表示が併せて表示されてもよい。
【００６８】
また、Ｄａｉｌｙの予測モデルを生成するために用いる起動ログの期間を指定することも可能である。例えば図１０に示す例では、画面左上の期間指定部４３に示すように、２０１４年１月１日から２０１４年１２月３１日の期間が対象となっているが、ユーザは、期間指定部４３に任意の期間を入力して変更することも可能である。
【００６９】
（４−２−３．Ｗｅｅｋｌｙ−ＵＩ）
図１１は、予測モデルを１週間周期で示すＷｅｅｋｌｙ−ＵＩ４１ｂを示す図である。図１１に示すように、Ｗｅｅｋｌｙ−ＵＩ４１ｂは、１周が１週間であって、曜日を示す表示（Ｍｏｎ、Ｔｕｅ、Ｗｅｄ、Ｔｈｕ、Ｆｒｉ、Ｓａｔ、Ｓｕｎ）が併せて表示されてもよい。
【００７０】
Ｗｅｅｋｌｙ−ＵＩ４１ｂでも同様に、期間指定部４３から対象期間を指定することが可能である。
【００７１】
（４−２−４．縮小・拡大）
図１２は、第２のログ修正画面４０の拡大・縮小操作について説明する図である。第２のログ修正画面４０は、例えばタッチパネルで形成された操作表示部２５に対して二本の指で押し広げるピンチアウト操作に応じて拡大され、二本の指で間を縮めるピンチイン操作に応じて縮小される。これにより、多重円上のアイコンを見やすくすることができる。
【００７２】
また、図１２右側に示すように第２のログ修正画面４を拡大した際には、弧の大きさに応じて時刻表示の粒度を動的に変化させてもよい。例えば、Ｄａｉｌｙ−ＵＩの場合、最も縮小した際には時間表示無し、または６時間単位で時刻を表示し、拡大した際には、１時間単位で時刻を表示する。
【００７３】
（４−２−５．データ削除）
図１３は、第２のログ修正画面４０におけるデータ削除操作について説明する図である。図１３左側に示すように、削除したい起動ログのコンテキストに対応するアイコンのいずれかを長押し（ｌｏｎｇ  ｐｒｅｓｓ）して選択すると、図１３中央に示すように、４つのアイコン群４２をセットで動かせるようになると共に、ゴミ箱アイコン４４が、長押しした個所の近くに出現する。そして、アイコン群４２をゴミ箱アイコン４４にスライドして指を離すことで、当該起動ログを削除することができる。
【００７４】
（４−２−６．データ変更）
図１４は、第２のログ修正画面４０における時刻のデータ変更操作について説明する図である。コンテキスト情報の一つである時刻を変更したい場合、図１４左側に示すように、対象の起動ログのコンテキストに対応するアイコンのいずれかを長押しして選択すると、図１４中央に示すように、４つのアイコン群４２をセットで動かせるようになる。そして、ユーザは、アイコン群４２を指定時刻にスライド移動させて指を離すことで、当該起動ログの時刻を変更することができる。
【００７５】
図１５は、第２のログ修正画面４０における時刻以外のデータ変更操作について説明する図である。図１５左側に示すように、対象の起動ログのコンテキストに対応するアイコンのいずれかをタップすると、図１５右側に示すように、コンテキスト情報一覧４５が表示される。
【００７６】
コンテキスト情報一覧４５には、アプリケーションに紐付けられたコンテキスト情報として、例えば日時、場所、行動、天候、周辺Ｗｉ−Ｆｉ情報、周辺Ｂｌｕｅｔｏｏｔｈ情報、通知、電源状態、ヘッドセット状態の情報が表示される。例えば行動情報を変更したい場合、コンテキスト情報一覧４５の「行動：座」をタップすると、行動情報一覧４５ａ（電車、車、立、歩、走、エレベータ、座）が表示されるので、ここで任意の値を選択して変更する。また、周辺Ｗｉ−Ｆｉ情報の「list」をタップすると、周辺Ｗｉ−Ｆｉ情報の値リスト４５ｂが表示されるので、ここで任意の値を選択して値を変更することができる（なお任意の値を選択して削除することも可能）。また、値リスト４５ｂは、値が多い場合、頻度で降順ソートして上位ｎ件を表示するようにしてもよい。
【００７７】
（４−２−７．データ追加）
図１６は、第２のログ修正画面４０におけるデータ追加操作について説明する図である。図１６左側に示すように、対象の起動ログのコンテキストに対応するアイコンのいずれかをダブルタップすると、図１６右側に示すように、ダブルタップしたアイコン群４２のコピーアイコン群４２ａが表示される。ユーザは、追加したコピーアイコン群４２ａに対して、上述したデータ変更操作によりコンテキスト情報を適宜修正することが可能である。
【００７８】
（４−２−８．変更入力に応じた予測モデルの変更例）
次に、予測モデルを上記式１で生成している場合において、上述した変更入力（データ削除、データ変更、データ追加）により、上記式１の右辺第１項の確率値がどのように修正されるかについて、具体例を示して説明する。
【００７９】
まず、図１３を参照して上述したように、起動ログのデータ削除を行った場合、予測モデルを生成する上記式１における右辺第１項の確率は、変更部１０ｅにより下記のように修正される。
【００８０】
例えば、昼の時間帯における各アプリケーションの起動確率（下記式３参照）が、当該時間帯にたまたま起動したゲームアプリの頻度に引っ張られた確率値となっており、昼時間帯のゲームアプリの起動ログが比較的少ない場合、ユーザは昼時間帯におけるゲームアプリの起動ログを削除する修正を行う。
【００８１】
（式３）
2016122276.tif 000005
【００８２】
この場合、上記式３に示す各アプリケーションの昼時間帯における起動確率値は、下記式４に示すように、削除したログに対応する確率値のみ減少させ、他のログに対応する確率値には影響を受けさせないようにしてもよい。
【００８３】
（式４）
2016122276.tif 000006
【００８４】
また、図１４および図１５を参照して上述したように、起動ログのデータ変更を行った場合、予測モデルを生成する上記式１における右辺第１項の確率は、変更部１０ｅにより下記のように変更される。
【００８５】
例えば、音楽アプリケーションに紐付けられたヘッドセットのＯＮ／ＯＦＦが、下記式５に示すように等確率になっている場合に、図１５に示すコンテキスト情報一覧４５において、音楽アプリケーションの起動ログ上でヘッドセットＯＦＦからＯＮに変更すると、下記式６に示すように、ヘッドセットＯＮの場合に音楽アプリケーションが予測されやすくなる。
【００８６】
（式５）
2016122276.tif 000007
【００８７】
（式６）
2016122276.tif 000008
【００８８】
また、図１６を参照して上述したように、起動ログのデータ追加を行った場合、予測モデルを生成する上記式１における右辺第１項の確率は、変更部１０ｅにより下記のように変更される。
【００８９】
例えば、Ｗｅａｔｈｅｒ  Ａｐｐに紐付けられたコンテキスト情報が天候情報のみであって、母数（Ｗｅａｔｈｅｒ  Ａｐｐ起動回数）が１５回の場合における各天候に応じたＷｅａｔｈｅｒ  Ａｐｐの起動確率値は、下記式７に示す通りである。
【００９０】
（式７）
2016122276.tif 000009
【００９１】
この場合に、Ｗｅａｔｈｅｒ  Ａｐｐに「天候：雨」を紐付けた起動ログを１００個追加した場合、下記式８に示すように、雨天時におけるＷｅａｔｈｅｒ  Ａｐｐの起動確率値が上がり、他の起動確率値が下がる。
【００９２】
（式８）
2016122276.tif 000010
【００９３】
（４−２−９．変更結果の表示）
続いて、予測モデルのユーザによる変更入力後のフィードバック、すなわち予測モデルの変更結果の表示について説明する。図１７は、第２のログ修正画面における修正確認ボタンの表示について説明する図である。図１７左側に示すように、例えば対象の起動ログのコンテキストに対応するアイコンのいずれかをタップすると、図１７中央に示すように、コンテキスト情報一覧４８が表示される。これに対して、例えばヘッドセットＯＦＦをＯＮに変更する等の修正を行うと、図１７右側に示すように、確認ボタン４９が出現する。確認ボタン４９をタップすると、ユーザが行った修正が確定し、変更部１０ｅにより修正ログがＡＰＰ起動ログＤＢ１３に反映され、予測モデルの変更が実行される。
【００９４】
図１８は、第２のログ修正画面における変更結果の表示について説明する図である。図１８に示す変更結果画面５０は、ユーザが行った変更入力により予測モデルがどのように変化したかを示す情報を表示する画面であって、例えば変更確認ボタン４９をタップした後にポップアップ表示される。
【００９５】
変更結果画面５０は、変更したコンテキスト値（例えばヘッドセットのＯＮ／ＯＦＦ）と、アプリケーション名（例えば「Ｍｕｓｉｃ  Ａｐｐ」）を明示した上で、確率値p(context｜app)が変更前とどう変わったかを、例えば対象のAppが出現し易く／し難くなったという表現で示す。図１８に示す例では、ヘッドセットの状態をＯＦＦからＯＮに変更したことで、上記式６に示すように確率値が変更したため、「この変更により、ヘッドセットの状態がＯＦＦの場合には、Ｍｕｓｉｃ  Ａｐｐが出現し難くなりました」と表示する。
【００９６】
これによりユーザは、自身が予測モデルに介入してログを修正したことにより、どのように予測モデルが変化したかを認識することができる。
【００９７】
＜４−３．第３のログ修正画面例＞
続いて、ユーザ端末２がスマートウォッチのような表示画面が比較的小さいデバイスにおけるログ修正画面の表示例について説明する。スマートウォッチのような表示画面が比較的小さいデバイスでは、図９に示すような多重円状の予測モデルの詳細ＵＩ４１を全て表示することは困難であるため、下記に説明するような第３のログ修正画面例の適用を想定する。
【００９８】
図１９は、本実施形態による第３のログ修正画面について説明する図である。例えば図１９に示すように、円状の各レイヤー（図９参照）を直線化して上下に並べた状態を仮定し、フリック操作に応じて表示画面を切り替えるようにすることで、スマートウォッチ（ユーザ端末２ｘ）でのログ修正を同様に可能とする。
【００９９】
例えば、アプリケーションレイヤー４０１、場所レイヤー４０２、天候レイヤー４０３、および行動レイヤー４０４の表示切り替えは上下のフリック動作により行われ、各レイヤーのアイコンの表示移動は左右のフリック動作により行われる。
【０１００】
具体的には、アプリケーションレイヤー４０１のＡｐｐアイコン４０１ａが、ユーザ端末２ｘの操作表示部２５ｘの画面６０に表示されている際、Ａｐｐアイコン４０１ａを左に送るよう指でフリック操作を行うことで、アプリケーションレイヤー４０１の右隣のＡｐｐアイコン４０１ｂが表示される。また、画面６０に表示されているＡｐｐアイコン４０１ａを上に送るよう指でフリック操作を行うことで、一つ下段のコンテキストレイヤー、すなわち場所レイヤー４０２に切り替えられ、場所アイコン４０２ａが表示される。
【０１０１】
なお、Ｄａｉｌｙ−ＵＩおよびＷｅｅｋｌｙ−ＵＩのどちらの周期が表示されているかは、図１９に示すようなＤａｉｌｙアイコン６２ａ、Ｗｅｅｋｌｙ６２ｂにより明示される。また、場所レイヤー４０２の右端に示す画面のように、場所アイコン４０２ｄと共に、対象となっている起動ログの期間指定部６３を表示してもよい。
【０１０２】
データの変更は、例えば表示されているアイコンをタップすることで、図１９に示すようにコンテキスト情報一覧６４が表示され、図１５を参照して説明した場合と同様にログ修正を行うことができる。また、アイコンを長押しすることで、図１９に示すようにゴミ箱アイコン４４が表示され、当該アイコンをゴミ箱アイコン４４にスライドして指を離すことで、起動ログを削除することができる。
【０１０３】
以上、ユーザ端末２がスマートウォッチのような表示画面が比較的小さいデバイスにおけるログ修正画面の表示例について説明した。なお本実施形態によるログ修正画面はこれに限定されず、例えば図２０に示すようなものであってもよい。
【０１０４】
図２０は、第３のログ修正画面の変形例について説明する図である。図２０左側に示すように、スマートウォッチ（ユーザ端末２ｘ）の操作表示部２５ｘのホーム画面６５に表示されている予測モデル設定アプリのアイコン６６を選択すると、使用頻度の高い順にアプリケーションのアイコンが表示される。
【０１０５】
次いで、ユーザがログ修正を行いたいアプリケーションのアイコン、例えばテレビアプリケーションに関する起動ログを修正したい場合、テレビアプリケーションのＡｐｐアイコン４０１ｅを選択する。次に、Ｄａｉｌｙコンテキストのログ修正またはＷｅｅｋｌｙコンテキストのログ修正のいずれかを選択する画面が表示される。ユーザは、Ｄａｉｌｙコンテキストのログ修正を行う場合はＤａｉｌｙアイコン６７をタップし、Ｗｅｅｋｌｙコンテキストのログ修正を行う場合はＷｅｅｋｌｙアイコン６８をタップする。
【０１０６】
そして、図２０右側に示すように、コンテキスト値の修正画面が表示される。当該修正画面では、ユーザが選択してきたアイコン（例えばテレビアプリケーションのＡｐｐアイコン４０１ｅおよびＷｅｅｋｌｙアイコン６８）が表示されるため、現在どのアプリケーションの起動ログを修正しているかを把握することができる。また、当該アイコンを選択することで、対応する選択画面に戻ることも可能である。
【０１０７】
図２０右側に示す例では、Ｗｅｅｋｌｙアイコン６８が選択された場合に表示される修正画面であって、１週間周期における曜日毎の対応アプリケーションの起動回数（または頻度）が表示される。ユーザは、当該起動回数をタップ操作または音声入力により修正することが可能である。
【０１０８】
（補足１）
以上、ユーザ端末２がスマートウォッチの場合における起動ログの修正画面例について具体的に説明した。なお本実施形態はこれに限定されず、例えばスマートウォッチ（ユーザ端末２ｘ）とスマートフォン（ユーザ端末２）が連携している場合に、スマートフォン側で代替してスマートウォッチにおけるアプリケーションの起動ログの修正を行うことも可能である。スマートフォン（ユーザ端末２）に対するスマートウォッチのログ修正ＵＩの呼び出しは、例えばスマートウォッチ（ユーザ端末２ｘ）側における音声入力（Voice  Command）により実現してもよいし、所定のアイコンのタップやアイコンタップ後の設定項目のタップで実現してもよい。また、スマートフォン（ユーザ端末２）におけるログ修正の結果をスマートウォッチ（ユーザ端末２ｘ）に通知してもよい。
【０１０９】
（補足２）
また、物理的な表示画面を有さないデバイスのログ修正も、当該デバイスと連携するスマートフォン（ユーザ端末２）で行うことが可能である。物理的な表示画面（具体的にはユーザがタッチ操作可能な表示部）を有さないデバイスとしては、例えばスマートアイグラス、スマートバンド、ネックレス型デバイス、Ｅａｒ型デバイス等が挙げられる。
【０１１０】
このようなデバイスのログ修正をスマートフォンで代替する場合、スマートフォンに対する各デバイスのログ修正ＵＩの呼び出しは、例えば音声入力（Voice  Command）により実現され得る。また、スマートアイグラスの場合は、ログ修正ＵＩまでの遷移（情報提示アプリアイコンの選択・起動、およびログ修正ボタンの選択）を、空中に投影された仮想ＵＩで行うようにしてもよい。
【０１１１】
＜＜５．まとめ＞＞
上述したように、本開示の実施形態による情報処理システムでは、ユーザ自身が嗜好モデルに介入してルール変更を反映させることを可能とする。
【０１１２】
上述した実施形態では、例えばアプリケーションの起動を予測する予測モデルにユーザが介入して自身の予測モデルがどのようなものかを直感的に把握し、起動ログを自分で修正することができる。また、自分が修正した予測モデルが利用されていることで、その予測結果が意図に沿わないものであってもよい、再度修正すればよく、ＵＸ（User Experience）の低下を防止することができる。
【０１１３】
また、起動ログの修正に対して、どのように予測モデルが変更されたかを示すフィードバックが表示されることで、ユーザは予測モデルの変更を確認することが可能である。
【０１１４】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本技術はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【０１１５】
例えば、上述したサーバ１、またはユーザ端末２に内蔵されるＣＰＵ、ＲＯＭ、およびＲＡＭ等のハードウェアに、サーバ１、またはユーザ端末２の機能を発揮させるためのコンピュータプログラムも作成可能である。また、当該コンピュータプログラムを記憶させたコンピュータ読み取り可能な記憶媒体も提供される。
【０１１６】
また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
【０１１７】
なお、本技術は以下のような構成も取ることができる。
（１）
ユーザコンテキストに基づいてユーザの嗜好モデルを生成する生成部と、
前記生成された嗜好モデルに対するユーザからの変更入力に応じて、前記嗜好モデルを変更する変更部と、
を備える、情報処理装置。
（２）
前記情報処理装置は、
前記嗜好モデルの変更入力画面を前記ユーザに提示するよう制御する提示制御部をさらに備える、前記（１）に記載の情報処理装置。
（３）
前記提示制御部は、前記ユーザからの変更入力に応じて行った前記嗜好モデルの変更結果を提示する、前記（２）に記載の情報処理装置。
（４）
前記変更入力画面は、前記嗜好モデルの生成に用いられたユーザコンテキストの一覧を示す画面であって、
前記変更部は、前記ユーザコンテキストに対するユーザによるデータ修正を、前記嗜好モデルに反映させて変更する、前記（２）または（３）に記載の情報処理装置。
（５）
前記データ修正は、前記ユーザコンテキストの変更、追加、または削除を含む、前記（４）に記載の情報処理装置。
（６）
前記嗜好モデルは、アプリケーションの起動予測モデルであって、
前記変更入力画面は、前記ユーザコンテキストに基づく前記アプリケーションの起動予測モデルを形成する起動ログを示す画面である、前記（２）または（３）に記載の情報処理装置。
（７）
前記起動ログは、所定期間内における起動アプリケーション、および、起動時のユーザ情報または起動時の環境情報の少なくともいずれかを紐付けた情報である、前記（６）に記載の情報処理装置。
（８）
前記起動時のユーザ情報は、ユーザ行動を含む、前記（７）に記載の情報処理装置。
（９）
前記起動時の環境情報は、起動日時、起動場所、または起動時の天候の少なくともいずれかを含む、前記（７）に記載の情報処理装置。
（１０）
前記変更入力画面は、起動アプリケーションと、起動時のユーザ情報、または起動時の環境情報を示すアイコンが所定周期で配置される、前記（６）〜（９）のいずれか１項に記載の情報処理装置。
（１１）
前記変更部は、前記変更入力画面に表示された前記アイコンに対するユーザによる修正操作を変更入力として受付ける、前記（１０）に記載の情報処理装置。
（１２）
前記修正操作は、追加操作、移動操作、または削除操作を含む、前記（１１）に記載の情報処理装置。
（１３）
前記提示制御部は、前記アイコンが選択された際に、当該アイコンに紐付けられているユーザコンテキストの一覧を提示する、前記（１０）〜（１２）のいずれか１項に記載の情報処理装置。
（１４）
前記変更部は、前記ユーザコンテキストの一覧に対するデータ修正を変更入力として受け付ける、前記（１３）に記載の情報処理装置。
（１５）
前記データ修正は、データの変更、追加、または削除を含む、前記（１４）に記載の情報処理装置。
（１６）
前記変更部は、前記ユーザコンテキストに対するデータ修正として、未来のデータの入力も受付け可能である、前記（４）〜（１５）のいずれか１項に記載の情報処理装置。
（１７）
前記提示制御部は、提示デバイスに応じた前記変更入力画面を提示する、前記（２）〜（１６）のいずれか１項に記載の情報処理装置。
（１８）
前記ユーザコンテキストは、アプリケーションが起動された直前に起動した他のアプリケーション、アプリケーションの起動時における環境情報、ユーザ情報、周辺通信機器との接続情報、アプリケーションからの通知情報、または機器状態情報を少なくとも含む、前記（２）〜（１７）に記載の情報処理装置。
（１９）
ユーザコンテキストに基づいてユーザの嗜好モデルを生成することと、
前記生成された嗜好モデルに対するユーザからの変更入力に応じて、前記嗜好モデルを変更することと、
を含む、制御方法。
（２０）
コンピュータを、
ユーザコンテキストに基づいてユーザの嗜好モデルを生成する生成部と、
前記生成された嗜好モデルに対するユーザからの変更入力に応じて、前記嗜好モデルを変更する変更部と、
として機能させるための、プログラム。
【符号の説明】
【０１１８】
１    サーバ
１０    制御部
１０ａ    ログ収集部
１０ｂ    モデル生成部
１０ｃ    予測部
１０ｄ    提示制御部
１０ｅ    変更部
１２    通信部
１３    ＡＰＰ起動ログＤＢ
１４    予測モデルＤＢ
２、２ｘ    ユーザ端末
２０    制御部
２２    通信部
２３    現在位置計測部
２４    動きセンサ
２５、２５ｘ    操作表示部
２６    記憶部
３０    第１のログ修正画面
４０    第２のログ修正画面
４１ａ    Ｄａｉｌｙ−ＵＩ
４１ｂ    Ｗｅｅｋｌｙ−ＵＩ
【図１】
2016122276.tif 000011
【図２】
2016122276.tif 000012
【図３】
2016122276.tif 000013
【図４】
2016122276.tif 000014
【図５】
2016122276.tif 000015
【図６】
2016122276.tif 000016
【図７】
2016122276.tif 000017
【図８】
2016122276.tif 000018
【図９】
2016122276.tif 000019
【図１０】
2016122276.tif 000020
【図１１】
2016122276.tif 000021
【図１２】
2016122276.tif 000022
【図１３】
2016122276.tif 000023
【図１４】
2016122276.tif 000024
【図１５】
2016122276.tif 000025
【図１６】
2016122276.tif 000026
【図１７】
2016122276.tif 000027
【図１８】
2016122276.tif 000028
【図１９】
2016122276.tif 000029
【図２０】
2016122276.tif 000030