JP7078035B2 - 情報処理装置、情報処理方法、およびプログラム - Google Patents

Description

本開示は、情報処理装置、情報処理方法、およびプログラムに関する。

従来、人は色々な場面（場所や環境等）に合わせて自分の中にある複数のキャラクターを使い分けている。例えば、会社に居る時と友達と居る時、また、学校に居る時と家に居る時とでは、態度や考え方、話し方等を、自然に若しくは意識して切り替えている。

ここで、近年の情報提示技術では、システム内に仮想的なエージェントを設けて、ユーザが欲している情報をエージェントにより音声や画像で提供している。このような技術に関し、例えば下記特許文献１では、利用者の特性の変化量に応じてキャラクターの視覚的態様を徐々に変化させて表示することで、利用者が自己の嗜好や趣味の変化を直感的に理解できるようにする情報端末装置が開示されている。

特開２０１０－２０４０７０号公報

しかしながら、従来の技術では、ユーザ自身が持つ複数のキャラクターの検知や分析には行われておらず、あくまでもユーザの嗜好や趣味の変化に応じてエージェントの視覚的な態様を変化させるのみである。

また、疲労していたり多忙な場合等には、ユーザが自分で現在の場面に合った自身のキャラクターを意識したり、コントロールしたりすることが困難な場合もあった。

そこで、本開示では、より好ましいユーザのキャラクターを引き出すよう適切な情報を提示することが可能な情報処理装置、情報処理方法、およびプログラムを提案する。

本開示によれば、ユーザのキャラクターを判定し、所定のキャラクターへ変更するタイミングであるか否かを判断し、前記変更するタイミングにおいて、前記所定のキャラクターへの変更を促すトリガを出力するよう制御する制御部を備える、情報処理装置を提案する。

本開示によれば、プロセッサが、ユーザのキャラクターを判定し、所定のキャラクターへ変更するタイミングであるか否かを判断し、前記変更するタイミングにおいて、前記所定のキャラクターへの変更を促すトリガを出力するよう制御することを含む、情報処理方法を提案する。

本開示によれば、コンピュータを、ユーザのキャラクターを判定し、所定のキャラクターへ変更するタイミングであるか否かを判断し、前記変更するタイミングにおいて、前記所定のキャラクターへの変更を促すトリガを出力するよう制御する制御部として機能させるための、プログラムを提案する。

以上説明したように本開示によれば、より好ましいユーザのキャラクターを引き出すよう適切な情報を提示することが可能となる。

なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

本開示の一実施形態による情報処理システムの概要について説明する図である。 本実施形態による情報処理システムの全体構成の一例を示す図である。 本実施形態によるユーザ端末の構成の一例を示すブロック図である。 本実施形態によるサーバの構成の一例を示すブロック図である。 本実施形態によるキャラクター判定処理を示すフローチャートである。 本実施形態によるユーザの主要キャラクター情報の一例を示す図である。 本実施形態による１日の行動パターンと出現キャラクターの一例を示す図である。 本実施形態による変更トリガ出力処理を示すフローチャートである。 本実施形態による変更トリガの優先度の修正処理を示すフローチャートである。 本実施形態によるユーザによるパラメータ修正が要求された際の動作処理を示すフローチャートである。 本実施形態によるパラメータ修正の一例を示す図である。 本実施形態によるマイナーキャラクターの情報の一例を示す図である。 本実施形態によるマイナーキャラクターへの変更トリガ出力処理を示すフローチャートである。 本実施形態による複数エージェント間での変更トリガ出力処理の概要を説明する図である。 本実施形態によるユーザＡのキャラクター情報の一例を示す図である。 本実施形態によるユーザＢのキャラクター情報の一例を示す図である。 本実施形態による複数エージェント間での変更トリガ出力処理を示すシーケンス図である。 本実施形態によるキャラクターに応じて広告提示の一例を説明する図である。 本実施形態による潜在的ななりたいキャラクターへ誘導する場合について説明する図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、説明は以下の順序で行うものとする。
１．本開示の一実施形態による情報処理システムの概要
２．構成
２－１．ユーザ端末１の構成
２－２．サーバ２の構成
３．動作処理
３－１．キャラクター判定処理
３－２．変更トリガ出力処理
３－３．パラメータ修正処理
３－４．マイナーキャラクターへの変更トリガ出力処理
３－５．複数エージェント間での変更トリガ出力処理
３－６．広告
３－７．潜在的ななりたいキャラクターへの誘導
４．まとめ

＜＜１．本開示の一実施形態による情報処理システムの概要＞＞
図１は、本開示の一実施形態による情報処理システムの概要について説明する図である。図１に示すように、本実施形態による情報処理システムでは、仮想的なエージェントＶによりユーザのキャラクターを推定し、必要に応じてユーザのキャラクターを変化させるための情報を提供する。本明細書において、「キャラクター」とは、その人が場所や環境等に合わせて使い分ける態度や考え方、話し方、または行動指針等であって、広く人格や性格の一形態と言える。また、キャラクターは、生まれつき個人に備わっているもの、成長過程で身に付いたもの、その場の状況や環境に合わせて作った／作られたもの、他者から与えられたもの、システム側で与えたもの（誘導したもの）等が想定される。また、各個人は複数のキャラクターを持ち得て、それぞれのキャラクターの出現頻度は人によって異なるが、その人の出現頻度の高いキャラクターを、以下では「主要キャラクター」とも称する。

また、本明細書では、キャラクターの名称として、例えば感情を表現した名称や（「おこりんぼキャラ」「寂しがりキャラ」「泣き虫キャラ」「おとぼけキャラ」、「気難しいキャラ」など）、社会における役割やポジションを表現した名称（「ママキャラ」、「パパキャラ」、「仕事キャラ」、「事務員キャラ」、「女子高生キャラ」、「セレブキャラ」など）、またはこれらを組合せた名称（「おこりんぼママキャラ」、「ごきげん事務員キャラ」など）を一例として適宜付与している。

図１に示すように、例えばユーザが使い分けている主要キャラクターとして、９時から１７時は「仕事キャラ」、１８時から翌朝８時は「ママキャラ」、１８時から２０時は時々「ゆったりキャラ」（穏やかな気持ちでのんびりとリラックスすることを好むキャラクター）が予め把握されている場合に、エージェントＶは、ユーザの状況や環境からキャラクター変更が必要であるか否かを判断する。具体的には、図１上段に示すように、例えばユーザがため息をついて疲れた様子である場合に、いつもはママキャラになって（具体的には、少なくとも職場以外の場所（通勤経路や自宅等）で）幸せな感情でいるはずの時間帯であるがまだ仕事キャラの状態（具体的には、職場にいる状態）である場合、キャラクター変更が必要であると判断する。

キャラクターの変更が必要であると判断した場合、エージェントＶは、ユーザのキャラクターが変化するきっかけとなる情報（以下、変更トリガとも称す）をユーザに提供する。変更トリガは、例えば図１中段に示すように、ママキャラの時によく聞いている音楽や子供の声を流すと共に、「スイーツでも買って帰って、ゆっくりしよう～」といった帰宅を促す提案を行う。これにより、ユーザは仕事を切り上げて、図１下段に示すように、家のことを考えるママキャラに変化（気持ちも変化）し得る。

このように、本実施形態では、より好ましいキャラクターへの変更を促すことができる。なお、各キャラクターに、幸せを感じるキャラクター（以下、Happyキャラクターと称す）であるか否かを設定し、Happyキャラクターへの変化を優先するよう変更トリガを発動することで、結果的にユーザをより幸せな状態へ導くことができる。

ここでは一例としてエージェントがユーザの状況や状態からキャラクター変更の必要性を判断して適切な変更トリガを与えるようにしているが、本実施形態はこれに限定されず、ユーザが予め入力したスケジュールに紐付いたキャラクターへの変更を促すようにしてもよい。これにより、ユーザが望むタイミングで変更トリガを与えることができる。ユーザは、スケジュールと共に、いつどこでどのキャラクターでいたいかを入力しておいてもよい。

また、本システムにおける仮想的なエージェントＶは、ユーザ端末１（図２参照）からユーザに対して音声や音楽、映像、写真、匂い、振動等により変更トリガを与えることが可能である。ユーザ端末１は、ウェアラブルデバイス（ネックバンド型、スマートアイグラス（双眼または単眼のＡＲアイウェア）、スマートイヤフォン（例えばオープンエアーイヤホン）、スマートバンド（腕輪型）、スマートウォッチ、耳部装着型ヘッドセット、肩乗り型端末等）、スマートフォン、携帯電話端末、またはタブレット端末等が想定される。

変更トリガの出力手法はデバイスの機能によって異なる。例えば、音情報（音声、環境音、効果音など）、表示情報（表示画面に文字やエージェントの画像、写真、映像等）、振動、匂い等が考えられる。例えばメガネ型端末（ＡＲアイウエア）の場合、ＡＲ技術により空間上、または物体の上に重畳する文章、言葉、図形により変更トリガを出力してもよい。また、耳部装着型ヘッドセットやオープンエアーイヤホンの場合、他の人には聞かれないように耳元でささやく、または風を吹きかける、熱を与える等により変更トリガを出力してもよい。

また、スマートフォンやタブレット端末等の場合、表示画面の端や一部に出現する文章、言葉、図形、キャラクターにより変更トリガを与える。また、肩乗り型端末の場合、基本的には耳部装着型ヘッドセットと同様に、他の人には聞かれないように耳元でささやく、または風を吹きかける、熱を与えるといった方法と、さらに振動や重心移動、髪の毛を引っ張る等により変更トリガを与えることが可能である。

続いて、このような本実施形態による情報処理システムの全体構成について図２を参照して説明する。図２は、本実施形態による情報処理システムの全体構成の一例を示す図である。

図２に示すように、本実施形態による情報処理システムは、ユーザ端末１とサーバ２を含む。ユーザ端末１とサーバ２は、無線または有線により通信接続し、データの送受信を行い得る。例えばユーザ端末１は、周辺の基地局４からネットワーク３に接続し、ネットワーク３上のサーバ２へデータと通信接続することが可能である。また、図２に示す例では、ユーザ端末１の一例として、ネックバンド型のユーザ端末１Ａと、スマートフォンのユーザ端末１Ｂを図示している。

ユーザ端末１は、位置情報やユーザの発話音声など、キャラクター判定や変更判断に用いられるユーザ状況に関する各種情報を、サーバ２に送信する。

サーバ２は、ユーザ端末１から送信された情報に基づいて、ユーザのキャラクターの判定や、変更トリガの発動等、仮想的なエージェントとしての機能を有する。

なお、本実施形態では一例として主にサーバ２側（クラウドサーバ）で処理を行うシステム構成としているが、本開示はこれに限定されず、キャラクターの判定や変更トリガの発動といった各種処理の一部をユーザ端末１側で行うようにしたり、全てをユーザ端末１側で行うようにしてもよい。また、本実施形態による処理を複数の外部装置で行うようにしてもよいし（分散処理）、一部の処理をエッジサーバで行うようにしてもよい（エッジコンピューティング）。

以上、本開示の一実施形態による情報処理システムについて説明した。続いて、本実施形態による情報処理システムに含まれる各装置の具体的な構成について図面を参照して説明する。

＜＜２．構成＞＞
＜２－１．ユーザ端末１の構成＞
図３は、本実施形態によるユーザ端末１の構成の一例を示すブロック図である。図３に示すように、ユーザ端末１は、制御部１０、通信部１１、操作入力部１２、音声入力部１３、センサ１４、表示部１５、音声出力部１６、および記憶部１７を有する。

制御部１０は、演算処理装置および制御装置として機能し、各種プログラムに従ってユーザ端末１内の動作全般を制御する。制御部１０は、例えばＣＰＵ（Central Processing Unit）、マイクロプロセッサ等の電子回路によって実現される。また、制御部１０は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Read Only Memory）、及び適宜変化するパラメータ等を一時記憶するＲＡＭ（Random Access Memory）を含んでいてもよい。

また、本実施形態による制御部１０は、音声入力部１３により入力された音声情報や、センサ１４により検知した各種センサ情報を、通信部１１からサーバ２に送信するよう制御する。また、制御部１０は、通信部２１によりサーバ２から受信した変更トリガを、表示部１５や音声出力部１６から出力するよう制御する。

通信部１１は、有線または無線によりネットワーク３と接続し、外部装置（例えば周辺機器、ルータ、基地局、サーバ２等）とデータの送受信を行う。通信部１１は、例えば有線／無線ＬＡＮ（Local Area Network）、またはＷｉ－Ｆｉ（登録商標）、携帯通信網（ＬＴＥ（Long Term Evolution）、３Ｇ（第３世代の移動体通信方式））等により外部装置と通信接続する。

操作入力部１２は、ユーザによる操作指示を受付け、その操作内容を制御部１０に出力する。操作入力部１２は、タッチセンサ、圧力センサ、若しくは近接センサであってもよい。あるいは、操作入力部１２は、ボタン、スイッチ、およびレバーなど、物理的構成であってもよい。

音声入力部１３は、マイクロホンと、そのマイクロホンで得られた音声信号を増幅処理するマイクアンプ部と、音声信号にデジタル変換するＡ／Ｄ変換器により実現され、音声信号を制御部１０に出力する。

センサ１４は、ユーザの状況、状態、または周辺環境を検知し、検知情報を制御部１０に出力する。センサ１４は、複数のセンサ群、または複数種類のセンサであってもよい。センサ１４は、例えばモーションセンサ（加速度センサ、ジャイロセンサ、地磁気センサ等）、位置センサ（Ｗｉ－Ｆｉ（登録商標）やＢｌｕｅｔｏｏｔｈ（登録商標）等との通信に基づく屋内位置測位、またはＧＰＳ等を用いた屋外位置測位等）、生体センサ（心拍センサ、脈拍センサ、発汗センサ、体温センサ、脳波センサ、筋電センサ等）、撮像センサ（カメラ）、環境センサ（温度センサ、湿度センサ、照度センサ、雨センサ等）が挙げられる。

表示部１５は、操作画面やメニュー画面等を出力する表示装置である。この表示部１５は、例えば、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、有機ＥＬ（Electroluminescence）ディスプレイなどの表示装置であってもよい。また、本実施形態による表示部１５は、制御部１０の制御により、後述するキャラクター判定のためのユーザアンケートや、変更トリガとして映像を出力し得る。

音声出力部１６は、音声信号を再生するスピーカと、スピーカに対するアンプ回路を有する。本実施形態による音声出力部１６は、制御部１０の制御により、エージェントの音声や音楽といった変更トリガを出力する。

記憶部１７は、制御部１０の処理に用いられるプログラムや演算パラメータ等を記憶するＲＯＭ（Read Only Memory）、および適宜変化するパラメータ等を一時記憶するＲＡＭ（Random Access Memory）により実現される。

以上、本実施形態によるユーザ端末１の構成について具体的に説明した。なおユーザ端末１の構成は、図３に示す例に限定されない。例えば、変更トリガの一例として「匂い」を出力する匂い出力部をさらに有していてもよい。また、図３に示す構成の少なくとも一部が外部装置に設けられる構成であってもよい。

また、図３に示す構成の少なくとも一部を有さない構成であってもよい。例えばユーザ端末１が、図２に示すようなネックバンド型のウェアラブルデバイスにより実現される場合、表示部１５を有さない場合もある。図２に示すネックバンド型のウェアラブルデバイスは、首に掛けるタイプのスピーカ（ネックバンド型スピーカ）であって、両端部に設けられたスピーカから音が出力される。また、かかるネックバンド型スピーカに設けられたスピーカは、例えばＶＰＴ（Virtual Phones Technology）技術を用いて、音が耳元で聞こえるような聴覚効果を与えることができる。また、ネックバンド型スピーカにイヤホン（不図示）が有線／無線で接続された場合、イヤホンから音を出力し得る。イヤホンは、オープンタイプのイヤホン（耳が塞がれないタイプのイヤホン）であってもよく、この場合は周辺環境音も聞こえ易い状況にあるため日常的に装着していても比較的安全性が保たれる。

＜２－２．サーバ２の構成＞
図４は、本実施形態によるサーバ２の構成の一例を示すブロック図である。図４に示すように、サーバ２は、制御部２０、通信部２１、キャラクター情報記憶部２２ａ、およびユーザ情報記憶部２２ｂを有する。

（制御部２０）
制御部２０は、演算処理装置および制御装置として機能し、各種プログラムに従ってサーバ２内の動作全般を制御する。制御部２０は、例えばＣＰＵ（Central Processing Unit）、マイクロプロセッサ等の電子回路によって実現される。また、制御部２０は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Read Only Memory）、及び適宜変化するパラメータ等を一時記憶するＲＡＭ（Random Access Memory）を含んでいてもよい。

また、本実施形態による制御部２０は、ユーザ状況・行動認識部２０１、キャラクター判定部２０２、変更トリガ出力制御部２０３、およびユーザ情報管理部２０４としても機能する。

ユーザ状況・行動認識部２０１は、ユーザ端末１から送信されたセンサ情報や音声情報に基づいて、ユーザの状況、周辺状況（周辺環境）、および行動を認識（解析を含む）する。また、ユーザ状況・行動認識部２０１は、ユーザが予め登録したスケジュールや、ソーシャルネットワークサービスへの投稿内容（テキスト、画像、位置情報、誰といるか）に基づいて、行動認識を行うことも可能である。

キャラクター判定部２０２は、ユーザが持つキャラクターや、現在出現しているキャラクターの判定を行う。例えばキャラクター判定部２０２は、ユーザが入力した所定のアンケートの回答、ソーシャルネットワークサービスへの投稿履歴、スケジュール履歴、センサ情報に基づく行動履歴に基づいて判定する。この際、キャラクター判定部２０２は、キャラクター情報記憶部２２ａに予め登録されたキャラクター判定ルールを参照してキャラクター判定を行ってもよいし、機械学習によりユーザのキャラクターの出現状況を学習してもよい。

変更トリガ出力制御部２０３は、ユーザの現在のキャラクターを変更させるか否かを判断し、キャラクターを変更するためのきっかけとなる情報を出力するよう制御する。変更トリガは、例えばエージェント音声による何らかの情報提示や声掛け、また、他の音声や音楽、映像、写真、ユーザの過去のソーシャルネットワークサービスへの投稿履歴、匂い等が挙げられる。

ユーザ情報管理部２０４は、ユーザが持つキャラクターや、各キャラクターの出現パターン、ユーザの行動履歴など、ユーザに関する各種情報をユーザ情報記憶部２２ｂに登録して管理する。

（通信部２１）
通信部２１は、有線または無線により外部装置とデータの送受信を行う。通信部２１は、例えば有線／無線ＬＡＮ（Local Area Network）、またはＷｉ－Ｆｉ（Wireless Fidelity、登録商標）等によりネットワーク３を介してユーザ端末１と通信接続する。

（キャラクター情報記憶部２２ａ）
キャラクター情報記憶部２２ａは、キャラクターに関する各種情報を記憶する。例えば、キャラクター情報記憶部２２ａは、キャラクター判定ルールを記憶する。例えば、平日の日中に比較的同じ場所に定常的に留まっている場合、そこが学校または職場（ユーザの年齢から推定し得る）であると判断し、「仕事キャラ」または「学校キャラ」と判定するルールや、夜に比較的同じ場所に定常的に留まっている場合はそこが自宅であると推定し、さらにユーザの家族構成等から、「ママキャラ」と判定するルールが挙げられる。また、地図情報を参照し、ユーザが飲食店に友達と居る状況で、会話が盛り上がっている時には「女子会キャラ」、生体情報等からリラックスしていることが認識された場合は「ゆったりキャラ」などと判定するルールも挙げられる。また、キャラクター情報記憶部２２ａには、システム側で作成したキャラクターの情報（名称、特徴、変更トリガ情報等）も記憶されている。

（ユーザ情報記憶部２２ｂ）
ユーザ情報記憶部２２ｂは、ユーザが持つキャラクターや、各キャラクターの出現パターン、ユーザの行動履歴など、ユーザに関する各種情報を記憶する。また、ユーザの各キャラクターへの変更トリガ情報も記憶され得る。

以上、本実施形態によるサーバ２の構成について具体的に説明した。なお図４に示すサーバ２の構成は一例であって、本実施形態はこれに限定されない。例えばサーバ２の少なくとも一部の構成が外部装置にあってもよいし、制御部２０の各機能のうち少なくとも一部がユーザ端末１または通信距離が比較的ユーザ端末１に近い場所にある通信機器（例えば、いわゆるエッジサーバなど）により実現されてもよい。サーバ２が有する構成や機能を適宜分散することで、リアルタイム性の向上や処理負担の軽減、セキュリティを担保することが可能となる。

＜＜３．動作処理＞＞
続いて、本実施形態による情報処理システムの動作処理について図面を用いて具体的に説明する。

＜３－１．キャラクター判定処理＞
まず、図５を参照してキャラクター判定処理について説明する。図５は、本実施形態によるキャラクター判定処理を示すフローチャートである。

図５に示すように、まず、サーバ２は、ユーザ端末１を用いてキャラクター判定のための初期設定を行う（ステップＳ１０３）。例えばスマートフォンやタブレット端末、ＰＣ等の操作入力部１２と表示部１５を有する構成のユーザ端末１に属性入力画面やアンケート入力画面を表示させて、初期設定の情報をユーザに入力させる。入力された情報は、ユーザ端末１からサーバ２へ送信される。属性入力は、例えば性別、年代、職業、家族構成、出身地等の入力が想定される。また、アンケート（パーソナリティー診断）は、下記のような、ユーザの性格、深層心理や潜在的な望み等を分析し得る項目が想定される。

・待ち合わせの時間はきちんと守るか
・人に厳しくダメ出しをするか
・他人を卑下したり、でしゃばる事が多いか
・理想が高く、精一杯頑張るか
・世の中のルールは守る方か
・仕事が好きか
・なりたい自分は何か
・好きな場所はどこか
・よく行く場所はどこか
・好きなミュージシャン、楽曲、映画、俳優、台詞は何か
・楽しかった思い出は何か
・彼氏はいるか

また、サーバ２は、ユーザの過去のソーシャルメディアサービスへの投稿履歴（コメント、画像、友人とのやり取り）、スケジュール履歴、位置情報履歴、行動履歴等を取得し、ユーザがどのような状況においてどのような行動や発言等を行ったり、どのような感情になっているかを分析する。

このように、初期設定として取得した属性情報、アンケートの回答情報、投稿履歴、スケジュール履歴、または行動履歴等の分析結果に基づいて、ユーザが持つ１以上のキャラクター（主要キャラクター）を判定する。これにより、例えば一例として、一人のユーザが、「元気キャラ」（いつでも元気で、お祭り大好き、地元に帰った時や女子会で出現する）、「仕事キャラ」（真面目なイメージを守りつつ、組織の中でうまくやっていくバランスを重視し、自分の気持ちは出さない）、「根暗キャラ」（暗い、ネガティブな気持ち、自分の気持ちを発信できず、疲れて何もやる気が起きない）、「ちゃっかりキャラ」（したたかに、ちゃっかり、周りの人を操り、自分の利益を最優先するキャラ）といったような４つのキャラクター（人格）を持つことが判明する。

判定されたユーザのキャラクター情報は、ユーザ情報記憶部２２ｂに蓄積される。また、キャラクター判定部２０２は、ユーザのキャラクターのうち、ユーザが幸せな感情や楽しい感情になるキャラクターをＨａｐｐｙキャラクターとして設定しておいてもよい。ここで、図６に、ユーザの主要キャラクター情報の一例を示す。

図６に示すように、キャラクター情報には、一人のユーザが持つキャラクターの種類と、各キャラクターが出現する状況のパラメータ（出現時間帯や場所）が含まれる。また、上述したようにユーザが幸せな感情や楽しい感情になるキャラクターはＨａｐｐｙキャラクターとして設定される。各キャラクターが出現する状況のパラメータは、初期設定において入力された属性やアンケート回答、また、過去の投稿履歴、スケジュール情報、行動履歴、また、予め登録された判定ルール（「仕事キャラ」は職場にいる時間帯（通常、平日の９時から１７時）に出現する、など）に基づいて設定される。かかるパラメータは、次に説明する行動履歴等の蓄積に応じて適宜修正され得る。

次に、サーバ２は、初期設定である程度のキャラクターを把握した後、継続的に（例えば５分毎に）ユーザの日々の行動履歴等を蓄積していく（ステップＳ１０６）。日々の行動履歴等とは、例えば、ユーザ端末１により取得されたユーザの毎日の会話、位置情報（移動履歴）、行動履歴（いつどこでどのような行動（歩いた、走った、座った、電車に乗った等）を取っていたか）、聞いた音楽、歩いた街の環境音、スケジューラの入力情報、ソーシャルネットワークへの投稿等を、ユーザ情報記憶部２２ｂに蓄積する。

そして、一定期間（例えば１週間分）蓄積した場合（ステップＳ１０９／Ｙｅｓ）、キャラクター判定部２０２は、蓄積した情報に基づいて、ユーザの１日の行動パターンに対応するキャラクターの学習を行う（ステップＳ１１２）。蓄積および学習は定期的に繰り返され、キャラクター情報の精度が向上される。

ここで、図７に、１日の行動パターンと出現キャラクターの一例を示す。図７に示すように、ユーザは１日に複数のキャラクターを使い分けていることが分かる。例えば９時から１７時は会社（場所Ａ）で仕事キャラ、移動中は特に何のキャラクターにも属さないニュートラルキャラ、１７時半から１９時半は友人と食事会でゆったりキャラ、２０時から翌朝８時は自宅で家族と一緒にいてママキャラであることが認識される。

以上、キャラクター判定処理について具体的に説明した。なお、キャラクター判定結果をユーザに通知してユーザ自身に修正させることも可能である。また、上記アンケートを定期的に行ってキャラクター情報を補正、更新していってもよい。また、ユーザが自身で今は○○キャラと登録してもよいし、スケジューラを用いて、この時間帯は、このキャラクター、と登録してもよい。

また、ユーザが使い分けるキャラクターの状況として、主に時間と場所を挙げたが、本実施形態はこれに限定されない。例えばユーザが複数のソーシャルネットワークサービスを利用している際に、それぞれのサービス毎にキャラクターを使い分けている場合もある。そこで、キャラクター情報として、どのソーシャルネットワークサービスの際にはどのキャラクターであるかを判定し、登録することも可能である。

＜３－２．変更トリガ出力処理＞
続いて、ユーザのキャラクターを変更させるための変更トリガをどのように出力するかについて図８を参照して説明する。図８は、本実施形態による変更トリガ出力処理を示すフローチャートである。

図８に示すように、まず、サーバ２のユーザ状況・行動認識部２０１は、ユーザ端末１の音声入力部１３により入力された音声情報や、センサ１４により検知された各種センサ情報に基づいて、ユーザの状況や行動をリアルタイムに認識する（ステップＳ１２３）。例えば位置情報からユーザが会社に居ることが分かる場合は仕事中と認識し、また、位置情報および加速度センサ情報から、会社から出て駅までの道を歩いていることが分かる場合は帰宅中と認識し得る。

次に、変更トリガ出力制御部２０３は、キャラクター変更が必要であるか否かを判断する（ステップＳ１２６）。例えば、通常であれば「ママキャラ」となっている時間帯に（図７参照）、ユーザが会社に居て「仕事キャラ」になっている場合、Ｈａｐｐｙキャラ優先の基準に基づき、変更トリガ出力制御部２０３は、「ママキャラ」（少なくともいずれかのＨａｐｐｙキャラ）に変更することが必要であると判断する。また、変更トリガ出力制御部２０３は、ユーザがため息を何回もついたり（音声情報、呼吸センサ情報等により検知）、疲労している（音声情報（「疲れたなぁ」等のつぶやき）、生体センサ情報、モーションセンサ等により検知）場合に、いずれかのＨａｐｐｙキャラへの変更が必要であると判断してもよい。

そして、キャラクター変更が必要であると判断した場合（ステップＳ１２６／Ｙｅｓ）、変更トリガ出力制御部２０３は、Ｈａｐｐｙキャラへ変化するためのきっかけとなる変更トリガを出力するよう制御する（ステップＳ１２９）。変更トリガは、例えば行動の変化を促す情報の提供であって、エージェントによる提案（例えば、「スイーツでも買って帰ったら」等の少なくとも「会社」から出ることを促す提案）、Ｈａｐｐｙキャラに関連する環境音（例えば子供の声など、「ママキャラ」の環境を想起させる音声）、映像（例えば子供の写真など、「ママキャラ」の環境を想起させる音声）、匂い（例えば家の匂いなど、「ママキャラ」の環境を想起させる音声）等が想定される。

以上、本実施形態による変更トリガの出力制御について説明した。なお、上述した例では、ユーザの状況からキャラクター変更の必要性を自動的に判断しているが、本実施形態はこれに限定されず、ユーザが予め入力したスケジュールに基づいてキャラクター変更の必要性を判断してもよい。例えば仕事の予定は１７時までであって、１８時からはママキャラの時間と予定が立てられている場合に、ユーザが１８時を過ぎても仕事場に居て仕事キャラのままである場合は、キャラクター変更が必要と判断し得る。

これにより、ユーザは自分のキャラクターをエージェントの支援の元、適切にコントロールし、自分にとって、有益で、幸運、好感な関係を築く行動を無意識的に、または意図的に取ることができる。

例えば、会社に勤務している２０代の女性ユーザＡが、ある金曜日に夜９時までの会議を終えて１０時過ぎに会社を出て街を歩いている際、ユーザＡが装着しているウェアラブルデバイス（ユーザ端末１）は、ユーザの足取りや溜息、生体情報、今週のスケジュール情報、Ｗｅｂ履歴等に基づいて、ユーザＡが仕事で忙しい一週間を終え、いつもチェックしているショッピングＷＥＢサイトも見ずに重い足取りで駅までの道を歩き、ユーザＡが「仕事キャラ」から「根暗キャラ」に変化していることを認識する。

なお、ここでは一例として図４に示すサーバ２の各機能を、ユーザ端末１にダウンロードされたエージェントソフトウェア（アプリケーションプログラム）により実行されるものとする。また、ユーザＡは、スケジューラにより、今週は仕事に集中したかったためビジネスタイムはキャラクター変更トリガの出力（本実施形態によるキャラクター変更サービス）はＯＦＦに設定し（若しくは「ニュートラルキャラ」を優先設定）、金曜日の会議が終わる９時過ぎにはキャラクター変更トリガの出力を自動的にＯＮにするよう設定することも可能である。

上述したようにユーザＡが「根暗キャラ」に変化してしまっているため、ユーザ端末１は、ユーザＡが持つＨａｐｐｙキャラを検索する。例えば、ユーザＡの「地元大好きキャラ」（自身の出身地への愛が強く、気の置けない仲間（幼馴染等）に気を許している（自分を解放できる）キャラクター）がＨａｐｐｙキャラに設定されている場合、ユーザ端末１は、ユーザＡが地元に帰省して「地元大好きキャラ」になっていた際の履歴情報（地元の仲間と盛り上がった飲み会での音声、友達の笑い声、写真、動画、投稿履歴等）を検索し、変更トリガとしてユーザに提供する。例えばユーザ端末１がユーザＡの耳部に装着されたオープンエアーイヤホンの場合、地元の仲間と盛り上がった飲み会で録音した音声や友達の笑い声を、周辺の環境音（雑踏）に混ざって微かに聞こえるよう出力制御してもよい。

なおユーザ端末１がメガネ型端末の場合は、地元に帰省した際の写真を視界の邪魔にならない範囲でさっとスライドショーにして流したり、スマートフォンの場合は表示画面の端に、地元の飲み会での友達の発言を吹き出しでうっすら出したり、その時の投稿記事を出したりしてもよい。

このように、ユーザＡに、楽しくて元気だった時の自分を想起させて、本人自らＨａｐｐｙキャラに変化するよう促すことができる。

これにより、ユーザＡが「根暗キャラ」から明るい元気なキャラに変わり、例えば自主的な行動として、「明日は早く起きてやりたかった朝ヨガでもやろうかな」と考えてヨガの予約を行う。スケジュールに朝ヨガの予定が入った場合、ユーザ端末１は、キャラクター変更が成功した（効果的だった）と推定することができる。

また、ユーザＡが「根暗キャラ」から「地元大好きキャラ」に変わり、スマートフォンを取り出して地元の友達に電話したりメッセージを送ったりする。友達への連絡が行われたり、友達と会う予定がスケジュールに入った場合、ユーザ端末１は、キャラクター変更が成功した（効果的だった）と推定することができる。

＜３－３．パラメータ修正処理＞
続いて、パラメータ修正処理について図９～図１１を参照して説明する。すなわち、システムにより変更トリガを出力した際に、ユーザが自主的にとった行動や、そのあとのユーザのキャラクターに変化、ユーザの感情や状況の変化等に基づいて、どのような時にどのような変更トリガを与えたらＨａｐｐｙキャラへの変身が成功したか、また、どのような時にＨａｐｐｙキャラへの変身を促すことが正しかったかといったことを学習し、デフォルトのキャラクター情報のパラメータ（変更トリガの優先度を含む）を修正することが可能である。

（変更トリガの優先度の修正）
図９は、本実施形態による変更トリガの優先度の修正処理を示すフローチャートである。図９に示すステップＳ２０３～Ｓ２０９は、図８を参照して説明したステップＳ１２３～Ｓ１２９の処理と同様であるため、ここでの詳細な説明は省略する。

なお、本実施形態において、あるキャラクターへの変更トリガが複数ある場合に、予めデフォルトとしてその優先度を設定しておいてもよい。デフォルトの優先度は、ランダムでもよいし、ユーザの過去履歴の傾向から優先度を推定して並べてもよい。例えば以下のように優先度が設定された変更トリガがあって上位から出力する場合について説明する。

優先度の最も高い手法で変更トリガを出力した後、サーバ２の制御部２０は、キャラクター変更が成功したか否かを判断する（ステップＳ２１２）。例えば、Ｈａｐｐｙキャラクターへの変更を促す変更トリガを出力した場合、制御部２０は、ユーザの溜息が減ったか、足取りが軽くなったか、笑顔になったか、誰かと会ったり出掛けるスケジュールを入力したか、友達や恋人に連絡を取ったか、幸せを感じているか、といった、Ｈａｐｐｙ（幸せ、元気、ポジティブ）な行動変化が起きたか否かに基づいて、キャラクター変更が成功したか否かを判断し得る。また、会社から退社するなど、完全にＨａｐｐｙキャラクターに変更する前でも、脱却したい状況（場所、環境）から変化が生じた場合にも成功と判断してもよい。

次いで、キャラクター変更が成功しなかった場合（ステップＳ２１２／Ｎｏ）、変更トリガ出力制御部２０３は、次に優先度の高い変更トリガに変更し（ステップＳ２１５）、ステップＳ２０９に戻って変更トリガの出力を行う（ステップＳ２０９）。

次に、キャラクター変更が成功した場合（ステップＳ２１２／Ｙｅｓ）、変更トリガの優先度を修正する（ステップＳ２１８）。すなわち、キャラクター変更が成功した変更トリガ（手法、内容）を学習する。

例えば、「エージェントの声」ではユーザに変化がなかった場合、「音楽」での変更トリガを与え、成功した場合は下記表２のように変更トリガの優先度を変更する。

また、「音楽」でもユーザに変化がなかった場合、次の「映像」で変更トリガを与え、成功した場合は下記表３のように変更トリガの優先度を変更する。

（ユーザによるパラメータの修正）
図１０は、本実施形態によるユーザによるパラメータ修正が要求された際の動作処理を示すフローチャートである。図１０に示すように、ユーザによる明示的なキャラクター修正要求があった場合（ステップＳ２２３／Ｙｅｓ）、サーバ２の制御部２０は、ユーザの指示に従ってキャラクター判定パラメータを修正する（ステップＳ２２６）。

例えば、平日の２０時に、通常であればママキャラの時間帯であるにも関わらずユーザが社外で仕事キャラになっている場合に（例えば言葉使い、会話内容、疲労度、笑顔度等から判定され得る）、ユーザ端末１によりＨａｐｐｙキャラクターへの変更トリガが提示される。しかし、実際は上長と取引先の人と飲食中であるため、仕事キャラでいることが正しい場合、ユーザは、操作入力部１２により今は仕事キャラでいることが正しいため、パラメータの修正要求を行う。パラメータの修正内容は、ユーザが手動で入力してもよいし、ユーザ端末１側で状況を認識して自動で行ってもよい。例えば、時間帯、場所、およびユーザの周辺にいる人を認識し（カメラ、声紋、発話内容、スケジュール情報により認識可能）、パラメータを修正する。ここで、図１１に、本実施形態によるパラメータ修正の一例を示す。図１１に示すように、平日の１７時以降に、社外の飲食店で、上長と同行している場合は、仕事キャラであると設定される。これにより、平日の１７時以降に、社外の飲食店で上長と同行している場合は、「仕事キャラ」を優先することが可能となり、本システムによるキャラクター変更サービスの精度が向上する。また、ユーザとシステム（エージェント）との信頼関係、信頼度も上がる。

（キャラクターの補充）
また、ユーザは有償または無償で、自分がなりたいキャラクターの補充を行うことが可能である。入手したキャラクター情報は、ユーザ情報記憶部２２ｂに、主要キャラクターと共に蓄積される。

例えばセレブキャラクター（Ｈａｐｐｙキャラ）を入手した場合、セレブキャラクター情報として、例えば以下のような変更トリガが補充される。

セレブキャラクターの発動タイミング（時間、場所等のパラメータ）は、ユーザが自ら設定してもよい（連動するスケジューラへの入力など）。また、システム側で適宜判断するようお任せ設定にしてもよい。

＜３－４．マイナーキャラクターへの変更トリガ出力処理＞
続いて、日常の行動パターンからは滅多に検知されないレアキャラクターへの変更トリガ出力処理について説明する。初期設定におけるキャラクター判定の結果、ユーザの主要キャラに加えて、マイナーキャラクター（ある特定のシチュエーション下でのみ出現するキャラクター、普段は意図的に抑えているキャラクター）も抽出され得る。このようなマイナーキャラクターは、初期設定のアンケートや過去履歴によって把握はされるが、出現頻度が３カ月に１度というような場合は、１日の行動パターンに対応するキャラクターとして学習されず、また、ユーザ自ら意図的に抑えている場合は、連動するスケジューラにも登録されない可能性が高い。

しかし、ユーザ状況に応じて、このようなマイナーキャラクターに変化させた方がよいとシステム側で判断し、かかるキャラクターへの変更トリガを提供することも可能である。

例えば、ユーザＡのマイナーキャラの中には、普段は滅多に出さない積極的女子キャラ（特に恋愛面で積極的な行動を起こすキャラクター）がいる。例えば図１２に示すように、ユーザＡにキャラクター診断結果として自分が積極的女子キャラを持っていることが把握できたが、出現は滅多にしない。

しかし、結婚から１０年経った現在では、ユーザＡにそのキャラクターが出現することがほとんどなくなっている。ユーザＡが夫との自宅でのくつろぎのひと時、元々口数が少ない夫と、読書に没頭してしまうユーザＡとの間には会話もほとんどなく、コミュニケーション不足になってしまっている。もっと夫婦間のコミュニケーションを取りたい、デートに出掛けたり二人で幸せな時間を過ごしたいと考えたユーザＡは、本システムにおいて、積極的女子キャラへの変化を促す変更トリガを出力するよう設定する。

具体的には、例えば自宅で夫と一緒に居る時に、夫婦の会話が５分以上無いときに発動するようにしてもよいし、笑い声や笑顔が一定の時間検出されない状況で発動するようにしてもよい。以下、図１３を参照して具体的に説明する。

図１３は、マイナーキャラクターへの変更トリガ出力処理を示すフローチャートである。図１３に示すように、まず、ユーザは、マイナーキャラクターの発動条件（パラメータ）の設定を行う（ステップＳ３０３）。ユーザにより入力された発動条件は、マイナーキャラクターのパラメータとしてサーバ２のユーザ情報記憶部２２ｂに保存される。

次に、サーバ２の変更トリガ出力制御部２０３は、ユーザ端末１により取得された音声情報やセンサ情報に基づいて、マイナーキャラクターへの変更タイミングを判断し（ステップＳ３０９）、条件を満たしたタイミングで変更トリガを出力する（ステップＳ３０９）。マイナーキャラクターへの変更トリガは、例えば下記表５に示すような例が考えられるが、適宜変更可能である。

次いで、キャラクター変更が失敗した場合（ステップＳ３１２／Ｎｏ）、次に優先度の高い変更トリガに変更する（ステップＳ３１８）。

次に、キャラクター変更が成功した場合（ステップＳ３１２／Ｙｅｓ）、成功した内容で変更トリガの優先度を修正する（ステップＳ３１５）。

＜３－５．複数エージェント間での変更トリガ出力処理＞
続いて、複数エージェント間での変更トリガ出力処理について図１４～図１７を参照して説明する。

相互の承認を経て形成された所定グループメンバー間（例えば恋人同士、特定の友達グループ、家族など）で、各ユーザのキャラクター情報をエージェント間で共有し、エージェントが最適なタイミングで相手のエージェントにキャラクター変更を依頼することが可能である。

図１４は、複数エージェント間での変更トリガ出力処理の概要を説明する図である。図１４に示すように、例えばユーザＡの溜息や呟き（「電話欲しいな」「連絡無いなぁ」など）により、「寂しがりキャラ」になっていることをエージェントＶａが判定する。ユーザＡをＨａｐｐｙキャラに変更するトリガとして、恋人からの連絡であると判断した場合（変更トリガ情報）、エージェントＶａは、恋人であるユーザＢのエージェントＶｂに、ユーザＡが寂しがっているため、ユーザＢをユーザＡに連絡するようなキャラクターへの変更を依頼する（具体的にユーザＢのキャラクター情報に基づいて特定のキャラクターへの変更を依頼してもよい）。恋人ステータスは、初期設定や、スケジュール情報、ソーシャルネットワークサービスへの投稿内容等から判断され得る。ここでは恋人としたが、本実施形態はこれに限定されず、ユーザＡが一緒にいるとＨａｐｐｙな状態になる人をユーザの行動履歴等から抽出してもよい。また、共有される各ユーザのキャラクター情報の一例を図１５および図１６に示す。

図１５に示すように、例えばユーザＢのキャラクター情報として、仕事キャラ、ワイワイキャラ、アクティブキャラ、ニュートラルキャラ、デートキャラがある場合、ユーザＡへの連絡を取ると推定されるキャラクターは、デートキャラとなる。また、図１６に示すように、ユーザＡのキャラクターとしては、仕事キャラ、アクティブキャラ、ゆったりキャラ、ニュートラルキャラ、寂しがりキャラがいる。

次いで、エージェントＶｂは、暇そうにしているユーザＢに、ユーザＡとのデート写真を見せたり、ユーザＡとのデートの時の音声を流したりしてユーザＡを思い出させ、デートキャラへの変更を促す。

キャラクターの変更が成功すると、ユーザＢは、ユーザＡに連絡を取ることが期待される。ユーザＡ側としては、連絡がなくて寂しいなと思っている時に相手から連絡が来るため、まるでテレパシーのようだと嬉しく思い、Ｈａｐｐｙな気持ちになる。

以上概要を説明したが、ここでエージェントＶａ、エージェントＶｂとは、仮想的なものであって、各エージェントの動作は、サーバ２および各ユーザ端末１において行われ得る。また、図４に示すサーバ２の機能を実現するアプリケーションが、ユーザ端末１にダウンロードされている場合、ユーザ端末１単体で変更トリガ出力処理を実現することが可能である。

続いて、図１７を参照して複数エージェント間での変更トリガ出力処理について説明する。図１７は、本実施形態による複数エージェント間での変更トリガ出力処理を示すシーケンス図である。

図１７に示すように、まず、ユーザＡのユーザ端末１ａは、ユーザの呟きを認識し（ステップＳ４０３）、寂しがりキャラになっている場合（ステップＳ４０６／Ｙｅｓ）、ユーザ端末１ａは、ユーザＢのユーザ端末１ｂに対し、ユーザＡをＨａｐｐｙなキャラクターに変更させるための変更トリガをユーザＢからユーザＡに与えるよう、キャラクター変更の要求を行う（ステップＳ４０９）。

次に、ユーザＢのユーザ端末１ｂは、ユーザＢを、ユーザＡに連絡を取る（ユーザＡをＨａｐｐｙなキャラクターに変更させるための変更トリガを与える）デートキャラに変更するよう、変更トリガを出力する（ステップＳ４１２）。

＜３－６．広告＞
また、本実施形態では、ユーザのキャラクターに応じた広告を提示することも可能である。キャラクターによって金銭感覚や購入する物、使いたいサービスが異なる場合もあるため、キャラクターに合わせて最適な広告をユーザに提示することが可能である。

図１８は、本実施形態によるキャラクターに応じて広告提示の一例を説明する図である。図１８に示すように、例えば仕事キャラの場合には、英会話スクールの広告、ママキャラの場合には、子供服の広告、ゆったりキャラの場合はグルメ情報や飲食店の広告を提示し得る。また、ニュートラルキャラの場合は、全てのキャラクターに対応する広告や、ユーザ属性に応じた広告（趣味嗜好、性別、年代等に応じて、ファッション、ビューティ、スイーツ関連の広告など）、また、その時に流行っている商品やイベントの広告をランダムに提示してもよい。

また、各キャラクターが出現している際のユーザの各種履歴（時間、場所、同行者、購入履歴等）に基づいて、各キャラクター出現時におけるユーザの嗜好や傾向を分析し、キャラクターにマッチした広告を提供することも可能である。広告は、ユーザ端末１により、画像、音声、その他の方法で提供される。

また、広告提供のタイミングは、現在のキャラクターに合ったものでもよいし、次に出現することが予想されるキャラクターに合ったものでもよい。

また、ママキャラなど家計を管理しているキャラクターが出現している時に、他のキャラクター向けの広告も含めて提示してもよいし、乗り物移動が一番多いニュートラルキャラクターの時に集中的に広告を提供してもよい。

＜３－７．潜在的ななりたいキャラクターへの誘導＞
本実施形態は、過去の呟きやソーシャルネットワークサービスへの投稿内容等に基づいて、ユーザの潜在的ななりたいキャラクターを判断し、かかるキャラクターに変化するきっかけを与えることも可能である。

図１９は、潜在的ななりたいキャラクターへ誘導する場合について説明する図である。例えば、ユーザが「サーフィンをやってみたいな」と半年前に呟いたが具体的な行動を起こさず、本人も忘れてしまっているような場合を想定する。

このような場合に、図１９上段に示すように、あるときユーザがサーフィンショップの近くを歩いていることを検知すると、図１９中段に示すように、エージェントＶが、「サーフィンやってみたいってこの前言ってたね！」と発言し、図１９下段に示すように、ユーザのサーフィンへの興味を引き出させることが可能となる。変更トリガは、エージェントの音声に限定されず、ユーザの過去の呟きを再生、表示したり、サーフィンの映像を見せたりする方法であってもよい。

このように、ユーザ自身も忘れていた潜在的ななりたい自分への変更トリガも、本システムにより与えることが可能となる。

＜＜５．まとめ＞＞
上述したように、本開示の実施形態による情報処理システムでは、より好ましいユーザのキャラクターを引き出すよう適切な情報を提示することが可能となる。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本技術はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

例えば、上述したユーザ端末１、またはサーバ２に内蔵されるＣＰＵ、ＲＯＭ、およびＲＡＭ等のハードウェアに、ユーザ端末１、またはサーバ２の機能を発揮させるためのコンピュータプログラムも作成可能である。また、当該コンピュータプログラムを記憶させたコンピュータ読み取り可能な記憶媒体も提供される。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、本技術は以下のような構成も取ることができる。
（１）
ユーザのキャラクターを判定し；
所定のキャラクターへ変更するタイミングであるか否かを判断し；
前記変更するタイミングにおいて、前記所定のキャラクターへの変更を促すトリガを出力するよう制御する制御部を備える、情報処理装置。
（２）
前記制御部は、前記ユーザが持つ１以上のキャラクターの情報を参照し、現在の時間、場所、または環境に応じて、前記ユーザのキャラクターを判定する、前記（１）に記載の情報処理装置。
（３）
前記制御部は、前記ユーザが持つ１以上のキャラクターの情報を参照し、音声情報、行動認識、または生体情報の少なくともいずれかに基づいて、前記ユーザのキャラクターを判定する、前記（１）または（２）に記載の情報処理装置。
（４）
前記制御部は、時間、場所、環境、音声情報、行動認識、または生体情報の少なくいずれかに基づいて、所定のキャラクターへ変更するタイミングであるか否かを判断する、前記（１）～（３）のいずれか１項に記載の情報処理装置。
（５）
前記ユーザが持つ１以上のキャラクターには、幸せなキャラクターであるか否かの設定が行われ、
前記制御部は、ユーザを幸せなキャラクターに変化させるためのトリガを出力するよう制御する、前記（１）～（４）のいずれか１項に記載の情報処理装置。
（６）
前記制御部は、
前記ユーザが持つ１以上のキャラクターの出現時間、場所、または環境を含むキャラクター情報に基づいて、キャラクターの判定および変更タイミングの判断を行う、前記（１）～（５）のいずれか１項に記載の情報処理装置。
（７）
前記制御部は、
前記所定のキャラクターへ変更させるトリガを出力した後の前記ユーザのフィードバックに基づいて、前記ユーザが持つ１以上のキャラクターの出現時間、場所、または環境を含むキャラクター情報を修正する、前記（１）～（６）のいずれか１項に記載の情報処理装置。
（８）
前記制御部は、
前記ユーザの属性情報、アンケート回答情報、行動履歴、スケジュール履歴、音声履歴、または投稿履歴に基づいて、前記ユーザが持つ１以上のキャラクターを判定する、前記（１）～（７）のいずれか１項に記載の情報処理装置。
（９）
前記制御部は、
前記所定のキャラクターへ変更させるトリガを出力した後、前記ユーザの行動に変化がない場合、次に優先度の高いトリガを出力するよう制御する、前記（１）～（８）のいずれか１項に記載の情報処理装置。
（１０）
前記制御部は、
前記所定のキャラクターへの変更を促すトリガとして、前記ユーザに影響を与えると推定される所定の他ユーザのキャラクターを変更するよう制御する、前記（１）～（９）のいずれか１項に記載の情報処理装置。
（１１）
前記制御部は、
前記ユーザのキャラクターに応じた広告情報を提示するよう制御する、前記（１）～（１０）のいずれか１項に記載の情報処理装置。
（１２）
プロセッサが、
ユーザのキャラクターを判定し；
所定のキャラクターへ変更するタイミングであるか否かを判断し；
前記変更するタイミングにおいて、前記所定のキャラクターへの変更を促すトリガを出力するよう制御することを含む、情報処理方法。
（１３）
コンピュータを、
ユーザのキャラクターを判定し；
所定のキャラクターへ変更するタイミングであるか否かを判断し；
前記変更するタイミングにおいて、前記所定のキャラクターへの変更を促すトリガを出力するよう制御する制御部として機能させるための、プログラム。

１ ユーザ端末
２ サーバ
３ ネットワーク
４ 基地局
１０ 制御部
１１ 通信部
１２ 操作入力部
１３ 音声入力部
１４ センサ
１５ 表示部
１６ 音声出力部
１７ 記憶部
２０ 制御部
２１ 通信部
２２ａ キャラクター情報記憶部
２２ｂ ユーザ情報記憶部
２０１ ユーザ状況・行動認識部
２０２ キャラクター判定部
２０３ 変更トリガ出力制御部
２０４ ユーザ情報管理部

Claims (13)

1. ユーザのキャラクターを判定し；
   所定のキャラクターへ変更するタイミングであるか否かを判断し；
   前記変更するタイミングにおいて、前記所定のキャラクターへの変更を促すトリガとして、前記ユーザが利用するデバイスから音情報、表示情報もしくは振動情報の少なくともいずれか一つを前記ユーザに対して出力するよう制御する制御部を備える、情報処理装置。
2. 前記制御部は、前記ユーザが持つ１以上のキャラクターの情報を参照し、現在の時間、場所、または環境に応じて、前記ユーザのキャラクターを判定する、請求項１に記載の情報処理装置。
3. 前記制御部は、前記ユーザが持つ１以上のキャラクターの情報を参照し、音声情報、行動認識、または生体情報の少なくともいずれかに基づいて、前記ユーザのキャラクターを判定する、請求項１に記載の情報処理装置。
4. 前記制御部は、時間、場所、環境、音声情報、行動認識、または生体情報の少なくともいずれかに基づいて、所定のキャラクターへ変更するタイミングであるか否かを判断する、請求項１に記載の情報処理装置。
5. 前記ユーザが持つ１以上のキャラクターには、幸せなキャラクターであるか否かの設定が行われ、
   前記制御部は、ユーザを幸せなキャラクターに変化させるためのトリガを出力するよう制御する、請求項１に記載の情報処理装置。
6. 前記制御部は、
   前記ユーザが持つ１以上のキャラクターの出現時間、場所、または環境を含むキャラクター情報に基づいて、キャラクターの判定および変更タイミングの判断を行う、請求項１に記載の情報処理装置。
7. 前記制御部は、
   前記所定のキャラクターへ変更させるトリガを出力した後の前記ユーザのフィードバックに基づいて、前記ユーザが持つ１以上のキャラクターの出現時間、場所、または環境を含むキャラクター情報を修正する、請求項１に記載の情報処理装置。
8. 前記制御部は、
   前記ユーザの属性情報、アンケート回答情報、行動履歴、スケジュール履歴、音声履歴、または投稿履歴に基づいて、前記ユーザが持つ１以上のキャラクターを判定する、請求項１に記載の情報処理装置。
9. 前記制御部は、
   前記所定のキャラクターへ変更させるトリガを出力した後、前記ユーザの行動に変化がない場合、次に優先度の高いトリガを出力するよう制御する、請求項１に記載の情報処理装置。
10. 前記制御部は、
    前記所定のキャラクターへの変更を促すトリガとして、前記ユーザに影響を与えると推定される所定の他ユーザのキャラクターを変更するよう前記所定の他ユーザが利用するデバイスから音情報、表示情報もしくは振動情報の少なくともいずれか一つを前記所定の他ユーザに対して出力するよう制御する、請求項１に記載の情報処理装置。
11. 前記制御部は、
    前記ユーザのキャラクターに応じた広告情報を提示するよう制御する、請求項１～１０のいずれか１項に記載の情報処理装置。
12. プロセッサが、
    ユーザのキャラクターを判定し；
    所定のキャラクターへ変更するタイミングであるか否かを判断し；
    前記変更するタイミングにおいて、前記所定のキャラクターへの変更を促すトリガとして、前記ユーザが利用するデバイスから音情報、表示情報もしくは振動情報の少なくともいずれか一つを前記ユーザに対して出力するよう制御することを含む、情報処理方法。
13. コンピュータを、
    ユーザのキャラクターを判定し；
    所定のキャラクターへ変更するタイミングであるか否かを判断し；
    前記変更するタイミングにおいて、前記所定のキャラクターへの変更を促すトリガとして、前記ユーザが利用するデバイスから音情報、表示情報もしくは振動情報の少なくともいずれか一つを前記ユーザに対して出力するよう制御する制御部として機能させるための、プログラム。

Images