(57)【特許請求の範囲】
【請求項１】
第１ユーザの心身状態を表す第１情報を取得する第１取得部と、
第２ユーザから前記第１ユーザに対するコミュニケーションを促進する関連情報の通知先である第２ユーザの心身状態を表す第２情報を取得する第２取得部と、
取得された前記第１情報及び取得された前記第２情報に基づいて、前記第２ユーザへ前記関連情報の通知を行うか否かを判断する判断部であって、前記第１ユーザの気分が所定の基準より悪く、かつ前記第２ユーザの気分が当該所定の基準より良いことが当該第１情報及び当該第２情報により示される場合に当該第２ユーザに当該関連情報の通知を行うと判断する処理を行う判断部と、
前記判断部により、前記第２ユーザに前記関連情報の通知を行うと判断された場合に、予め自装置に記憶されている第２ユーザの宛先に、当該関連情報の通知を送信する送信部と
を備える情報処理装置。
【請求項２】
前記第１取得部は、前記第１ユーザの音声から判定された当該第１ユーザの気分を表す情報を前記第１情報として取得し、
前記第２取得部は、前記第２ユーザの音声から判定された当該第２ユーザの気分を表す情報を前記第２情報として取得する
請求項１に記載の情報処理装置。
【請求項３】
前記送信部は、取得された前記第１情報及び取得された前記第２情報に応じて、予め自装置に記憶されている前記第１ユーザに固有の情報と、前記第１ユーザ及び前記第２ユーザで共通する情報とのいずれかを含む情報を前記関連情報として前記通知を送信する
請求項１又は２に記載の情報処理装置。
【請求項４】
前記送信部は、取得された前記第１情報及び取得された前記第２情報と、前記第２ユーザに固有の情報とに応じたタイミングで前記通知を送信する
請求項１から３のいずれか１項に記載の情報処理装置。
【請求項５】
前記第２ユーザの気分の変化の傾向を判断する傾向判断部を備え、
前記判断部は、取得された前記第１情報及び取得された前記第２情報と、判断された前記傾向とに応じて前記処理を行う
請求項１から４のいずれか１項に記載の情報処理装置。
【請求項６】
前記判断部は、取得された前記第１情報及び取得された前記第２情報と、前記第１ユーザ及び前記第２ユーザのコミュニケーション頻度とに応じて前記処理を行う
請求項１から５のいずれか１項に記載の情報処理装置。
【請求項７】
前記判断部は、取得された前記第１情報及び取得された前記第２情報と、前記第２ユーザへの前記関連情報の通知履歴とに応じて前記処理を行う
請求項１から６のいずれか１項に記載の情報処理装置。
【請求項８】
前記送信部は、複数の前記第２ユーザの各々への関連情報の通知に関する処理を行う場合に、各関連情報の種類に応じて、当該複数の第２ユーザで通知のタイミングを共通にする方法と、当該複数の第２ユーザで通知のタイミングを共通にしない方法とのいずれかの方法で前記通知を送信する
請求項１から７のいずれか１項に記載の情報処理装置。
【請求項９】
複数の前記第１ユーザがいる場合に、前記第１ユーザの属性又は前記第１情報に基づいて当該複数の第１ユーザの各々の優先順位を判断する優先順位判断部を備え、
前記送信部は、前記複数の第１ユーザのそれぞれについての前記関連情報を、各々について判断された前記優先順位に応じたタイミングで前記第２ユーザに前記通知を送信する
請求項１から８のいずれか１項に記載の情報処理装置。
【請求項１０】
前記処理には、前記第２ユーザへの通知の可否を判断する処理を含む複数の処理が含ま
れ、
前記判断部は、前記通知の可否を判断する処理については、取得された前記第１情報を用いずに行う
請求項１から９のいずれか１項に記載の情報処理装置。
【請求項１１】
１以上の情報処理装置のいずれかが、第１ユーザの心身状態を表す第１情報を取得する第１取得ステップと、
１以上の情報処理装置のいずれかが、第２ユーザから前記第１ユーザに対するコミュニケーションを促進する関連情報の通知先である第２ユーザの心身状態を表す第２情報を取得する第２取得ステップと、
１以上の情報処理装置のいずれかが、取得された前記第１情報及び取得された前記第２情報に基づいて、前記第２ユーザへ前記関連情報の通知を行うか否かを判断する判断ステップであって、前記第１ユーザの気分が所定の基準より悪く、かつ前記第２ユーザの気分が当該所定の基準より良いことが当該第１情報及び当該第２情報により示される場合に当該第２ユーザに当該関連情報の通知を行うと判断する処理を行う判断ステップと、
前記判断ステップにより、前記第２ユーザに前記関連情報の通知を行うと判断された場合に、予め自装置に記憶されている第２ユーザの宛先に、当該関連情報の通知を送信する送信ステップと
を備える情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザの気分を判定してその結果を活用する技術に関する。
【背景技術】
【０００２】
ユーザの気分を判定してその結果を活用する技術が知られている。例えば特許文献１には、問診におけるユーザからの音声回答のピッチや強さなどに基づいてユーザの精神状態を診断し、診断した精神状態が良好でなければ、健康管理ロボットが励ましの言葉をかける技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−２２５２２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ユーザの気分を判定してその結果を活用する技術は、例えば、ユーザの気分が落ち込んでいるときに気持ちを持ち直させる場面で役に立つ。しかし、特許文献１の技術のようにロボットが声をかけるよりも、人間である他のユーザが声をかけてコミュニケーションをとった方がより高い効果が期待される。
そこで、本発明は、ユーザの気分に応じて、そのユーザに対する他のユーザからのコミュニケーションを促進することを目的とする。
【課題を解決するための手段】
【０００５】
上記目的を達成するために、本発明は、第１ユーザの心身状態を表す第１情報を取得する第１取得部と、前記第１ユーザに関連する関連情報の通知先である第２ユーザの心身状態を表す第２情報を取得する第２取得部と、前記関連情報の前記第２ユーザへの通知に関する処理を、取得された前記第１情報及び取得された前記第２情報に応じて行う処理部とを備える情報処理装置を提供する。
【０００６】
また、前記第１取得部は、前記第１ユーザの音声から判定された当該第１ユーザの気分を表す情報を前記第１情報として取得し、前記第２取得部は、前記第２ユーザの音声から判定された当該第２ユーザの気分を表す情報を前記第２情報として取得してもよい。
さらに、前記処理部は、取得された前記第１情報及び取得された前記第２情報に応じて、前記第１ユーザに固有の情報と、前記第１ユーザ及び前記第２ユーザで共通する情報とのいずれかを含む情報を前記関連情報として前記処理を行ってもよい。
また、前記処理部は、取得された前記第１気分情報及び取得された前記第２気分情報と、前記第２ユーザに固有の情報とに応じたタイミングで前記第１ユーザ関連情報を通知してもよい。
【０００７】
また、前記第２ユーザの気分の変化の傾向を判断する傾向判断部を備え、前記処理部は、取得された前記第１情報及び取得された前記第２情報と、判断された前記傾向とに応じて前記処理を行ってもよい。
さらに、前記処理部は、取得された前記第１情報及び取得された前記第２情報と、前記第１ユーザ及び前記第２ユーザのコミュニケーション頻度とに応じて前記処理を行ってもよい。
【０００８】
また、前記処理部は、取得された前記第１情報及び取得された前記第２情報と、前記第２ユーザへの前記関連情報の通知履歴とに応じて前記処理を行ってもよい。
さらに、前記処理部は、複数の前記第２ユーザの各々への関連情報の通知に関する処理を行う場合に、各関連情報の種類に応じて、当該複数の第２ユーザで通知のタイミングを共通にする方法と、当該複数の第２ユーザで通知のタイミングを共通にしない方法とのいずれかの方法で前記処理を行ってもよい。
【０００９】
また、複数の前記第１ユーザがいる場合に、前記第１ユーザの属性又は前記第１情報に基づいて当該複数の第１ユーザの各々の優先順位を判断する優先順位判断部を備え、前記処理部は、前記複数の第１ユーザのそれぞれについての前記関連情報を、各々について判断された前記優先順位に応じたタイミングで前記第２ユーザに通知してもよい。
さらに、前記処理には、前記第２ユーザへの通知の可否を判断する処理を含む複数の処理が含まれ、前記処理部は、前記通知の可否を判断する処理については、取得された前記第１情報を用いずに行ってもよい。
【００１０】
また、本発明は、１以上の情報処理装置のいずれかが、第１ユーザの心身状態を表す第１情報を取得する第１取得ステップと、１以上の情報処理装置のいずれかが、前記第１ユーザに関連する関連情報の通知先である第２ユーザの心身状態を表す第２情報を取得する第２取得ステップと、１以上の情報処理装置のいずれかが、前記関連情報の前記第２ユーザへの通知に関する処理を、取得された前記第１情報及び取得された前記第２情報に応じて行う処理ステップとを備える情報処理方法を提供する。
【発明の効果】
【００１１】
本発明によれば、ユーザの気分に応じて、他のユーザからそのユーザに対するコミュニケーションを促進することができる。
【図面の簡単な説明】
【００１２】
【図１】第１実施例に係るコミュニケーション支援システムの全体構成を表す図
【図２】第１ユーザ端末のハードウェア構成を表す図
【図３】第２ユーザ端末のハードウェア構成を表す図
【図４】サーバ装置のハードウェア構成を表す図
【図５】コミュニケーション支援システムの各装置が実現する機能構成を表す図
【図６】通知判断テーブルの一例を表す図
【図７】関連情報テーブルの一例を表す図
【図８】宛先情報テーブルの一例を表す図
【図９】出力された第１ユーザ関連情報の一例を表す図
【図１０】支援処理における各装置の動作手順の一例を表す図
【図１１】第２実施例の各装置が実現する機能構成を表す図
【図１２】通知判断テーブルの一例を表す図
【図１３】関連情報テーブルの一例を表す図
【図１４】第３実施例のサーバ装置が実現する機能構成を表す図
【図１５】傾向判断テーブルの一例を表す図
【図１６】判断された気分の傾向の一例を表す図
【図１７】通知判断テーブルの一例を表す図
【図１８】関連情報テーブルの一例を表す図
【図１９】変形例のサーバ装置が実現する機能構成の一例を表す図
【図２０】傾向判断テーブルの一例を表す図
【図２１】判断された気分の変化傾向の一例を表す図
【図２２】変化履歴と判断された気分の変化傾向の一例を表す図
【図２３】変形例のサーバ装置が実現する機能構成の一例を表す図
【図２４】傾向判断テーブルの別の一例を表す図
【図２５】判断された気分の変化傾向の別の一例を表す図
【図２６】変形例の第２ユーザ端末のハードウェア構成を表す図
【図２７】変形例の各装置が実現する機能構成の一例を表す図
【図２８】通知判断テーブルの一例を表す図
【図２９】関連情報テーブルの一例を表す図
【図３０】変形例のサーバ装置が実現する機能構成の一例を表す図
【図３１】通知判断テーブルの一例を表す図
【図３２】関連情報テーブルの一例を表す図
【図３３】変形例のサーバ装置が実現する機能構成の一例を表す図
【図３４】変形例の各装置が実現する機能構成の一例を表す図
【図３５】通知判断テーブルの一例を表す図
【図３６】関連情報テーブルの一例を表す図
【図３７】変形例の各装置が実現する機能構成の一例を表す図
【図３８】変形例の各装置が実現する機能構成の一例を表す図
【発明を実施するための形態】
【００１３】
［１］第１実施例
図１は第１実施例に係るコミュニケーション支援システム１の全体構成を表す。コミュニケーション支援システム１は、自システムを利用するユーザ同士のコミュニケーションを支援するシステムである。本システムでは、ユーザの音声から気分が判定され、その判定された気分に応じたコミュニケーションの支援が行われる。コミュニケーション支援システム１は、ネットワーク２と、第１ユーザ端末１０と、第２ユーザ端末２０と、サーバ装置３０とを備える。
【００１４】
ネットワーク２は、例えば移動体通信網及びインターネット等を含み、装置同士のデータのやり取りを仲介するシステムである。ネットワーク２には、第１ユーザ端末１０及び第２ユーザ端末２０が無線（有線でもよい）で接続され、サーバ装置３０が有線で（無線でもよい）接続されている。
【００１５】
第１ユーザ端末１０及び第２ユーザ端末２０は、いずれも本システムのユーザが利用する端末であり、例えばスマートフォンやタブレット端末などの情報処理装置である。以下では、第１ユーザ端末１０を利用するユーザを「第１ユーザ」といい、第２ユーザ端末２０を利用するユーザを「第２ユーザ」という。例えば第１ユーザが部下で第２ユーザが上司という使われ方をする。
【００１６】
第１ユーザは、音声によって気分が判定されるユーザである。第１ユーザ端末１０は、第１ユーザの音声から気分を判定する処理を行う。第２ユーザは、第１ユーザとコミュニケーションがとれるように支援されるユーザである。第２ユーザ端末２０は、この支援をするための処理を行う。第２ユーザ端末２０は、例えば、第１ユーザの気分が落ち込んでいると判定されたときに、第１ユーザの趣味に関する情報を出力して、第１ユーザとコミュニケーションをとるための話題を第２ユーザに提供する。また、第２ユーザも、音声によって気分が判定される。第２ユーザ端末２０による情報の出力は、第２ユーザの気分にも応じて行われる。
【００１７】
サーバ装置３０は、上記のとおり判定された気分に応じたコミュニケーションを支援するための処理を行う情報処理装置である。サーバ装置３０は、第１ユーザの気分を表す第１気分情報と、第２ユーザの気分を表す第２気分情報とを取得する。第１気分情報は本発明の「第１情報」の一例であり、第２気分情報は本発明の「第２情報」の一例である。サーバ装置３０は、第１ユーザに関連する第１ユーザ関連情報の第２ユーザへの通知に関する通知関連処理（例えば第１ユーザ関連情報を生成する処理及び送信する処理等）を、取得した第１気分情報及び第２気分情報に応じて行う。第１ユーザ関連情報は本発明の「関連情報」の一例である。こうしてコミュニケーション支援システム１は、例えば気分が落ち込んだ第１ユーザに対して第２ユーザがコミュニケーションをとることを支援する。
【００１８】
図２は第１ユーザ端末１０のハードウェア構成を表す。第１ユーザ端末１０は、ＣＰＵ（Central Processing Unit）１１と、ＲＡＭ（Random Access Memory）１２と、ＲＯＭ（Read Only Memory）１３と、ＮＩＣ（Network Interface Card）１４と、フラッシュメモリ１５と、タッチスクリーン１６と、マイクロフォン１７とを備えるコンピュータである。ＣＰＵ１１は、ＲＡＭ１２をワークエリアとして用いてＲＯＭ１３やフラッシュメモリ１５に記憶されているプログラムを実行することで各部の動作を制御する。
【００１９】
ＮＩＣ１４は、通信回路を有し、ネットワーク２を介して外部装置と通信を行う。フラッシュメモリ１５は、ＣＰＵ１１が制御に用いるデータやプログラムを記憶している。タッチスクリーン１６は、表示手段であるディスプレイと、ディスプレイの表面に設けられたタッチパネルとを備え、画像を表示するとともに、ユーザからの操作を受け付ける。マイクロフォン１７は、周囲の音を収集し、収集した音を表す音データをＣＰＵ１１に供給する。
【００２０】
図３は第２ユーザ端末２０のハードウェア構成を表す。第２ユーザ端末２０は、ＣＰＵ２１と、ＲＡＭ２２と、ＲＯＭ２３と、ＮＩＣ２４と、フラッシュメモリ２５と、タッチスクリーン２６と、マイクロフォン２７と、スピーカ２８とを備えるコンピュータである。ＣＰＵ２１からマイクロフォン２７までは、図２に表す同名のハードウェアとそれぞれ共通するものである。スピーカ２８は、ＣＰＵ２１により制御されて音データが表す音を放出する放音手段である。
【００２１】
図４はサーバ装置３０のハードウェア構成を表す。サーバ装置３０は、ＣＰＵ３１と、ＲＡＭ３２と、ＲＯＭ３３と、ＮＩＣ３４と、ＨＤＤ（Hard Disk Drive）３５とを備えるコンピュータである。ＣＰＵ３１、ＲＡＭ３２、ＲＯＭ３３は、図２に表す同名のハードウェアとそれぞれ共通するものである。ＨＤＤ３５は、ＣＰＵ３１が制御に用いるデータやプログラムを記憶している。
【００２２】
コミュニケーション支援システム１が備える各装置のＣＰＵがプログラムを実行して各部を制御することで、以下に述べる機能が実現される。
図５はコミュニケーション支援システム１の各装置が実現する機能構成を表す。第１ユーザ端末１０は、気分判定部１０１と、気分情報送信部１０２とを備える。第２ユーザ端末２０は、気分判定部２０１と、気分情報送信部２０２と、関連情報取得部２０３と、関連情報出力部２０４とを備える。サーバ装置３０は、第１気分情報取得部３０１と、第２気分情報取得部３０２と、処理部３０３と、ユーザ固有情報記憶部３０４と、一般情報記憶部３０５とを備える。
【００２３】
第１ユーザ端末１０の気分判定部１０１は、第１ユーザの気分を判定する。気分判定部１０１は、本実施例では、第１ユーザの音声からその第１ユーザの気分を判定する。気分判定部１０１は、この判定を、例えば「Empath（登録商標）」と呼ばれる音声気分解析技術や、特開２０１３−２０６３２０号公報に記載されている技術などの公知技術を用いて音声から気分を判定する。気分判定部１０１は、本実施例では、気分をレベル１から５までの５段階で判定する。
【００２４】
例えばレベル５は絶好調、レベル４は好調、レベル３は普通、レベル２は気分が良くない、レベル１は気分が落ち込んでいることを表す。気分判定部１０１は、第１ユーザが気分を判定するための操作を行った後に音声を出すと、その音声を集音し、前述した公知技術を用いて集音した音声から第１ユーザの気分を判定する。気分判定部１０１は、その判定結果（レベルの値）を気分情報送信部１０２に供給する。
【００２５】
気分情報送信部１０２は、気分判定部１０１により判定された第１ユーザの気分を表す第１気分情報を、サーバ装置３０に送信する。第１気分情報は本発明の「第１情報」の一例である。気分情報送信部１０２は、気分判定部１０１から判定結果が供給されると、その判定結果を表す情報を第１気分情報として生成し、予め自装置に記憶されているサーバ装置３０の宛先（ＩＰ（Internet Protocol）アドレスなど）に送信する。第１気分情報は、例えば、判定結果が「３」という値であれば、「レベル３」というテキスト情報と、第１ユーザのユーザＩＤ（Identification）とを対応付けた情報である。このユーザＩＤは、コミュニケーション支援システム１において割り当てられた第１ユーザを識別する識別情報である。
【００２６】
気分情報送信部１０２により送信された第１気分情報は、サーバ装置３０が受信して第１気分情報取得部３０１に供給される。第１気分情報取得部３０１は、第１ユーザについて判定されたその第１ユーザの気分を表す第１気分情報を取得する。第１気分情報取得部３０１は本発明の「第１取得部」の一例である。第１気分情報取得部３０１は、本実施例では、第１ユーザの音声から判定されたその第１ユーザの気分を表す情報を第１気分情報として取得する。第１気分情報取得部３０１は、取得した第１気分情報を処理部３０３に供給する。
【００２７】
第２ユーザ端末２０の気分判定部２０１は、第２ユーザの気分を判定する。気分判定部２０１は、本実施例では、第２ユーザの音声からその第２ユーザの気分を判定する。気分判定部２０１は、気分の判定対象が第２ユーザであるだけで、気分判定部１０１と共通する機能である。気分判定部２０１は、判定結果（レベルの値）を気分情報送信部２０２に供給する。
【００２８】
気分情報送信部２０２は、気分判定部２０１により判定された第２ユーザの気分を表す第２気分情報を、サーバ装置３０に送信する。第２気分情報は本発明の「第２情報」の一例である。気分情報送信部２０２は、気分情報送信部１０２と共通する機能である。第２気分情報は、例えば、判定結果を表すテキスト情報と、第２ユーザのユーザＩＤとを対応付けた情報である。このユーザＩＤは、コミュニケーション支援システム１において割り当てられた第２ユーザを識別する識別情報である。
【００２９】
気分情報送信部２０２により送信された第２気分情報は、サーバ装置３０が受信して第２気分情報取得部３０２に供給される。第２気分情報取得部３０２は、第２ユーザについて判定されたその第２ユーザの気分を表す第２気分情報を取得する。第２気分情報取得部３０２は本発明の「第２取得部」の一例である。第２気分情報取得部３０２は、本実施例では、第２ユーザの音声から判定されたその第２ユーザの気分を表す第２気分情報を取得する。第２気分情報取得部３０２は、取得した第２気分情報を処理部３０３に供給する。
【００３０】
処理部３０３は、第１ユーザ関連情報の第２ユーザへの通知に関する処理である通知関連処理を、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報とに応じて行う。第１ユーザ関連情報は、例えば、上述した第１ユーザの趣味に関する情報である。処理部３０３は、通知判断部３３１と、関連情報生成部３３２と、関連情報送信部３３３とを備える。
【００３１】
通知判断部３３１は、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報とに基づいて、第２ユーザへの通知を行うか否かを判断する処理を通知関連処理として行う。通知判断部３３１は、本実施例では、第１気分情報が表す第１ユーザの気分と、第２気分情報が表す第２ユーザの気分と、通知の要否とを対応付けた通知判断テーブルを用いる。
【００３２】
図６は通知判断テーブルの一例を表す。図６の例では、「レベル３」から「レベル５」までの第１ユーザの気分には、第２ユーザの気分に関係なく「不要」という通知の要否が対応付けられている。第１ユーザの気分が「レベル２」の場合、第２ユーザの気分が「レベル１〜３」であれば通知が「不要」であり、第２ユーザの気分が「レベル４、５」であれば通知が「要」となっている。また、第１ユーザの気分が「レベル１」の場合、第２ユーザの気分が「レベル１」であれば通知が「不要」であり、第２ユーザの気分が「レベル２〜５」であれば通知が「要」となっている。
【００３３】
通知判断部３３１は、第１気分情報及び第２気分情報を受け取ると、第１気分情報が表す第１ユーザの気分と第２気分情報が表す第２ユーザの気分とに通知判断テーブルで対応付けられた通知の要否を参照し、「要」であれば通知を行うと判断し、「不要」であれば通知を行わないと判断する。通知判断部３３１は、通知を行うと判断した場合には、判断に用いた第１気分情報及び第２気分情報を関連情報生成部３３２に供給する。
【００３４】
関連情報生成部３３２は、通知判断部３３１により第２ユーザへの通知を行うと判断された場合に、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報とに応じた第１ユーザ関連情報を生成する処理を通知関連処理として行う。関連情報生成部３３２は、本実施例では、第１気分情報が表す第１ユーザの気分と、第２気分情報が表す第２ユーザの気分と、生成する第１ユーザ関連情報の種類とを対応付けた関連情報テーブルを用いる。
【００３５】
図７は関連情報テーブルの一例を表す。図７の例では、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル４、５」という組み合わせには「第１ユーザ固有情報」という第１ユーザ関連情報の種類が対応付けられ、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル２、３」という組み合わせには「共通情報」という第１ユーザ関連情報の種類が対応付けられている。また、第１ユーザの気分が「レベル２」で第２ユーザの気分が「レベル５」という組み合わせには「第１ユーザ固有情報」という第１ユーザ関連情報の種類が対応付けられ、第１ユーザの気分が「レベル２」で第２ユーザの気分が「レベル４」という組み合わせには「共通情報」という第１ユーザ関連情報の種類が対応付けられている。
【００３６】
第１ユーザ固有情報とは、第１ユーザに固有の情報であり、例えば、第１ユーザの生年月日、出身地及び趣味等を含むユーザ属性情報や、第１ユーザのスケジュールを表すスケジュール情報などである。共通情報とは、第１ユーザと第２ユーザとで共通する情報であり、例えば、天気・気温・花粉予報等に関する天気情報や、花見・海開き・紅葉等に関する季節情報、社会・政治・スポーツ等に関する報道情報などの一般的な情報である。また、第１ユーザ及び第２ユーザの各々に固有の情報のうちに互いに共通する情報があれば、それも共通情報となる。例えば出身地や趣味が共通していれば、それらのユーザ属性情報が共通情報となる。
【００３７】
関連情報生成部３３２は、第１気分情報及び第２気分情報を受け取ると、第１気分情報が表す第１ユーザの気分及び第２気分情報が表す第２ユーザの気分に関連情報テーブルで対応付けられた種類の第１ユーザ関連情報を生成する。第１ユーザ関連情報の元になる情報はユーザ固有情報記憶部３０４及び一般情報記憶部３０５に記憶されている。
【００３８】
ユーザ固有情報記憶部３０４は、コミュニケーション支援システム１を利用する各ユーザに固有の固有情報を記憶する。本システムにおいては、例えばユーザのＩＤを発行する際に、そのユーザの固有情報を登録する操作が行われている。ユーザ固有情報記憶部３０４は、登録された固有情報を発行されたユーザＩＤに対応付けて記憶する。なお、固有情報は追加や編集がされるようになっていてもよい。
【００３９】
一般情報記憶部３０５は、前述した一般的な情報である一般情報を記憶する。一般情報記憶部３０５には、例えばコミュニケーション支援システム１を提供する提供者によって定期的に一般情報が格納されている。一般情報記憶部３０５は、格納された一般情報を例えば現在の日時に対応付けて記憶する。ユーザ固有情報及び一般情報は、例えばテキスト、画像、動画、音声又はそれらの組み合わせで表された情報である。
【００４０】
関連情報生成部３３２は、第１ユーザ固有情報を第１ユーザ関連情報として生成する場合には、通知判断部３３１から供給された第１気分情報に含まれているユーザＩＤに対応付けてユーザ固有情報記憶部３０４が記憶している第１ユーザの固有情報を読み出す。関連情報生成部３３２は、こうして読み出した第１ユーザ固有情報と、第１ユーザの気分の判定結果を表す判定結果情報とを含む第１ユーザ関連情報を生成する。
【００４１】
また、関連情報生成部３３２は、共通情報を第１ユーザ関連情報として生成する場合には、例えば現在時刻から遡る一定の期間（１日や１週間など）に含まれる日時に対応付けて一般情報記憶部３０５が記憶している一般情報を読み出す（古い共通情報を用いないようにするため）。関連情報生成部３３２は、こうして読み出した一般情報と、第１ユーザの気分の判定結果を表す判定結果情報とを含む第１ユーザ関連情報を生成する。
【００４２】
また、関連情報生成部３３２は、共通情報を第１ユーザ関連情報として生成する場合には、通知判断部３３１から供給された第１気分情報に含まれているユーザＩＤに対応付けてユーザ固有情報記憶部３０４が記憶している第１ユーザの固有情報と、同じく供給された第２気分情報に含まれているユーザＩＤに対応付けてユーザ固有情報記憶部３０４が記憶している第２ユーザの固有情報を読み出す。関連情報生成部３３２は、読み出した固有情報のうち共通するものがあれば、その共通する固有情報と前述した判定結果情報とを含む第１ユーザ関連情報を生成する。
【００４３】
関連情報生成部３３２は、以上のとおり生成した第１ユーザ関連情報を、第１ユーザのユーザＩＤ（通知判断部３３１から供給された気分情報が表すユーザＩＤ）とともに関連情報送信部３３３に供給する。
【００４４】
関連情報送信部３３３は、関連情報生成部３３２により生成された第１ユーザ関連情報を第２ユーザに対応付けられた宛先に送信する処理を通知関連処理として行う。コミュニケーション支援システム１においては、ユーザのＩＤを発行する際に、そのユーザに情報を伝える際に利用可能な宛先を表す宛先情報を登録する操作が行われている。宛先情報は、例えばＩＰアドレスや電子メールアドレス、ＳＮＳ（Social Networking Service）のアカウントなどである。関連情報送信部３３３は、第１ユーザのユーザＩＤと第２ユーザの宛先情報とを対応付けた宛先情報テーブルを用いる。
【００４５】
図８は宛先情報テーブルの一例を表す。図８の例では、「ＩＤ００１」、「ＩＤ０１３」、「ＩＤ０２５」という各第１ユーザのユーザＩＤに「ｘｘｘｘｘ」、「ｙｙｙｙｙ」、「ｚｚｚｚｚ」という第２ユーザの宛先情報がそれぞれ対応付けられている。関連情報送信部３３３は、関連情報生成部３３２から供給された第１ユーザのユーザＩＤに宛先情報テーブルで対応付けられている第２ユーザの宛先情報が表す宛先に、ともに供給された第１ユーザ関連情報を送信する。
【００４６】
第２ユーザ端末２０の関連情報取得部２０３は、関連情報送信部３３３によって送信された第１ユーザ関連情報を取得する。関連情報取得部２０３は、宛先情報がＩＰアドレスであれば自装置が受信した第１ユーザ関連情報を取得し、宛先情報が電子メールアドレスであれば電子メールサーバから第１ユーザ関連情報を取得し、宛先情報がＳＮＳのアカウントであればＳＮＳサーバから第１ユーザ関連情報を取得する。関連情報取得部２０３は、取得した第１ユーザ関連情報を関連情報出力部２０４に供給する。
【００４７】
関連情報出力部２０４は、関連情報取得部２０３により取得された第１ユーザ関連情報を出力する。関連情報出力部２０４は、第１ユーザ関連情報がテキストや画像であれば自装置の表示手段（タッチスクリーン２６のディスプレイ）に出力し、第１ユーザ関連情報に動画や音が含まれていれば、それらの音を自装置の放音手段（スピーカ２８）に出力する。なお、第１ユーザ関連情報の出力先は、外部装置の表示手段や放音手段であってもよい。
【００４８】
図９は出力された第１ユーザ関連情報の一例を表す。図９の例では、第２ユーザ端末２０のタッチスクリーン２６に、「○○さんの気分がレベル１と判定されました。以下の情報を参考に声をかけてあげてください。」という第１ユーザの気分の判定結果を知らせる判定結果情報Ａ１と、生年月日、出身地、趣味を表したユーザ属性情報Ａ２と、第１ユーザのスケジュールを表したスケジュール情報Ａ３と（Ａ２、Ａ３は第１ユーザの固有情報）が第１ユーザ関連情報として表示されている。第２ユーザが上司であれば、判定結果情報Ａ１により第１ユーザである部下の気分が落ち込んでいることが分かるので、ユーザ属性情報Ａ２やスケジュール情報Ａ３の内容を話題としてその部下に話しかけることができる。
【００４９】
サーバ装置３０の処理部３０３は、以上のとおり通知の要否を判断し、通知すると判断した場合に第１ユーザ関連情報を生成及び送信することで、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報とに応じて、その第１ユーザの固有情報と、第１ユーザ及び第２ユーザで共通する共通情報のいずれかを含む第１ユーザ関連情報を第２ユーザに通知する処理を上述した通知関連処理として行う。
【００５０】
コミュニケーション支援システム１が備える各装置は、上記の構成に基づいて、第１ユーザと第２ユーザのコミュニケーションを支援する支援処理を行う。
図１０は支援処理における各装置の動作手順の一例を表す。図１０の例では、この動作手順が、第１ユーザが第１ユーザ端末１０に対して気分を判定するための操作を行い、音声を出すことを契機に開始される。
【００５１】
まず、第１ユーザ端末１０（気分判定部１０１）は、第１ユーザの音声を集音し（ステップＳ１１）、集音した音声からその第１ユーザの気分を判定する（ステップＳ１２）。次に、第１ユーザ端末１０（気分情報送信部１０２）は、ステップＳ１２において判定された第１気分を表す気分情報をサーバ装置３０に送信する（ステップＳ１３）。サーバ装置３０（第１気分情報取得部３０１）は、ステップＳ１３で送信されてきた第１気分情報を取得する（ステップＳ１４）。
【００５２】
ここで、第２ユーザが第２ユーザ端末２０に対して気分を判定するための操作を行い、音声を出すと、第２ユーザ端末２０（気分判定部２０１）は、第２ユーザの音声を集音し（ステップＳ２１）、集音した音声からその第２ユーザの気分を判定する（ステップＳ２２）。次に、第２ユーザ端末２０（気分情報送信部２０２）は、ステップＳ２２において判定された気分を表す第２気分情報をサーバ装置３０に送信する（ステップＳ２３）。サーバ装置３０（第２気分情報取得部３０２）は、ステップＳ２３で送信されてきた第２気分情報を取得する（ステップＳ２４）。
【００５３】
なお、ステップＳ１１からＳ１４までの動作と、ステップＳ２１からＳ２４までの動作とは、反対の順序で行われても（ステップＳ２１からＳ２４までが先に行われても）よいし、並行して行われてもよい。次に、サーバ装置３０（処理部３０３）は、取得された第１気分情報及び第２気分情報に基づいて通知の要否を判断する（ステップＳ３１）。図１０の例では、通知を行うことが判断されるものとする。
【００５４】
サーバ装置３０（処理部３０３）は、通知すると判断すると、第１ユーザ関連情報を生成し（ステップＳ３２）、生成した第１ユーザ関連情報を第２ユーザ端末２０に送信する（ステップＳ３３）。ステップＳ３３の送信は、電子メールサーバ経由又はＳＮＳサーバ経由で行われる場合もある。第２ユーザ端末２０（関連情報取得部２０３）は、ステップＳ３３で送信された第１ユーザ関連情報を取得する（ステップＳ３４）。そして、第２ユーザ端末２０（関連情報出力部２０４）は、ステップＳ３４で取得された第１ユーザ関連情報を例えば自装置の表示手段に出力する（ステップＳ３５）。
【００５５】
本実施例では、音声から判定された第１ユーザの気分がレベル２（気分がよくない）又はレベル１（気分が落ち込んでいる）である場合に第２ユーザに第１ユーザ関連情報が通知される。第２ユーザは、この通知により、第１ユーザの気分があまりよくない状態であるから、何か声をかけるべきタイミングであることを知ることができるし、その状態に合わせた声掛けをするという心構えをすることができる。このように、本実施例によれば、ユーザ（第１ユーザ）の気分に応じて、そのユーザ（第１ユーザ）に対する他のユーザ（第２ユーザ）からのコミュニケーションを促進することができる。
【００５６】
ただし、例えば第２ユーザの気分が落ち込んでいるときに第１ユーザ関連情報が通知されても、第２ユーザの気分が良いときに比べると、第２ユーザが第１ユーザに声掛けをしない可能性が高くなるし、声掛けをしたとしても、話題が盛り上がりにくく第１ユーザの気分を良くするという効果が期待できない。本実施例では、第２ユーザの気分が決められた状態のとき（第１ユーザの気分がレベル２なら第２ユーザの気分がレベル４以上、第１ユーザの気分がレベル１なら第２ユーザの気分がレベル２以上のとき）に通知が行われるので、第２ユーザの気分に関係なく通知が行われる場合に比べて、第１ユーザ関連情報が通知された第２ユーザが第１ユーザとコミュニケーションをとる可能性を高めることができる。
【００５７】
また、本実施例では、第２ユーザに通知される第１ユーザ関連情報に、第１ユーザ及び第２ユーザの気分によって第１ユーザ固有情報が含まれていたり、共通情報が含まれていたりする。いずれの情報も話題の材料となるので、第２ユーザに第１ユーザとのコミュニケーションのきっかけとなる話題を提供することができ、これらの情報が含まれていない場合に比べて第２ユーザが第１ユーザに声をかけやすくなる。
【００５８】
また、第１ユーザ及び第２ユーザは、各々の気分によっては、共通情報のように気軽に会話ができる話題の方が話しやすかったり、第１ユーザ固有情報のように自分又は相手との関連性が高い話題の方が話しやすかったりすることがある。本実施例では、第１ユーザ固有情報及び共通情報を第１ユーザ及び第２ユーザの気分によって使い分けることで、第２ユーザから第１ユーザへのコミュニケーションのきっかけ作りのしやすさを第１ユーザ及び第２ユーザの気分に合わせて変化させることができ、両者の気分に応じて話題にしやすい情報を第２ユーザに提供することができる。
【００５９】
［２］第２実施例
本発明の第２実施例について、以下、第１実施例と異なる点を中心に説明する。第１実施例では、第１ユーザ及び第２ユーザの気分を考慮して第１ユーザ関連情報の通知が行われたが、第２実施例では、さらに、第２ユーザに固有の情報も考慮して通知が行われる。以下では、第２ユーザのスケジュールが第２ユーザの固有情報として用いられる場合を説明する。
【００６０】
図１１は本実施例の各装置が実現する機能構成を表す。図１１では、第１ユーザ端末１０と、第２ユーザ端末２０ａと、サーバ装置３０ａとを備えるコミュニケーション支援システム１ａが表されている。第２ユーザ端末２０ａは、図５に表す各部に加え、スケジュール管理部２０５を備える。サーバ装置３０ａは、図５に表す各部に加え、スケジュール情報取得部３０６を備える。
【００６１】
スケジュール管理部２０５は、第２ユーザのスケジュールを管理する。スケジュール管理部２０５は、例えば第２ユーザが予定しているイベントの名称（イベント名）と日時とを対応付けて記憶している。スケジュール情報取得部３０６は、第２ユーザのスケジュール情報を取得する。スケジュール情報取得部３０６は、例えば現在の日付から決められた期間に予定されているイベントを表すスケジュール情報を第２ユーザ端末２０ａに要求する。スケジュール管理部２０５は、この要求を受け取ると、該当するイベントを表すスケジュール情報をサーバ装置３０ａに送信する。スケジュール情報取得部３０６は、こうして送信されてきたスケジュール情報を取得し、通知判断部３３１に供給する。
【００６２】
通知判断部３３１は、第１気分情報取得部３０１により取得された第１気分情報及び第２気分情報取得部３０２により取得された第２気分情報と、スケジュール情報取得部３０６により取得されたスケジュール情報とに応じて、第２ユーザへの通知の要否を判断する。通知判断部３３１は、本実施例では、第１ユーザの気分と、第２ユーザの気分と、スケジュール情報に含まれるイベントの種類とを対応付けた通知判断テーブルを用いる。
【００６３】
図１２は本実施例の通知判断テーブルの一例を表す。図１２の例では、「レベル３〜５」の第１ユーザの気分には、第２ユーザの気分及びイベントの種類に関係なく「不要」という通知の要否が対応付けられている。第１ユーザの気分が「レベル２」の場合、第２ユーザの気分が「レベル１〜３」であれば通知が「不要」である。一方、第２ユーザの気分が「レベル４、５」の場合、イベントの種類が「社内会議」であれば通知が「要」であり、イベントの種類が「出張、顧客訪問」であれば通知が「不要」となっている。
【００６４】
また、第１ユーザの気分が「レベル１」の場合、第２ユーザの気分が「レベル１」であれば通知が「不要」である。一方、第２ユーザの気分が「レベル２〜５」の場合、イベントの種類が「社内会議、顧客訪問」であれば通知が「要」であり、イベントの種類が「出張」であれば通知が「不要」となっている。
【００６５】
通知判断部３３１は、第１気分情報、第２気分情報及びスケジュール情報を受け取ると、第１気分情報が表す第１ユーザの気分と第２気分情報が表す第２ユーザの気分とスケジュール情報が表すイベントの種類とに通知判断テーブルで対応付けられた通知の要否を参照し、「要」であれば通知を行うと判断し、「不要」であれば通知を行わないと判断する。通知判断部３３１は、通知を行うと判断した場合には、判断に用いた第１気分情報、第２気分情報及びスケジュール情報を関連情報生成部３３２に供給する。
【００６６】
関連情報生成部３３２は、通知判断部３３１により第２ユーザへの通知を行うと判断された場合に、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報と、スケジュール情報取得部３０６により取得されたスケジュール情報とに応じた第１ユーザ関連情報を生成する。関連情報生成部３３２は、本実施例では、第１気分情報が表す第１ユーザの気分と、第２気分情報が表す第２ユーザの気分と、スケジュール情報が表すイベントの種類と、生成する第１ユーザ関連情報の種類とを対応付けた関連情報テーブルを用いる。
【００６７】
図１３は本実施例の関連情報テーブルの一例を表す。図１３の例では、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル２〜５」という組み合わせの場合、「社内会議、イベントなし」というイベントの種類に「第１ユーザ固有情報」という第１ユーザ関連情報の種類が対応付けられ、「顧客訪問」というイベントの種類に「共通情報」という第１ユーザ関連情報の種類が対応付けられている。
【００６８】
また、第１ユーザの気分が「レベル２」で第２ユーザの気分が「レベル４、５」という組み合わせの場合、「イベントなし」というイベントの種類に「第１ユーザ固有情報」という第１ユーザ関連情報の種類が対応付けられ、「社内会議」というイベントの種類に「共通情報」という第１ユーザ関連情報の種類が対応付けられている。関連情報生成部３３２は、第１気分情報、第２気分情報及びスケジュール情報を受け取ると、第１気分情報が表す第１ユーザの気分、第２気分情報が表す第２ユーザの気分及びスケジュール情報が表すイベントの種類に関連情報テーブルで対応付けられた種類の第１ユーザ関連情報を生成する。
【００６９】
処理部３０３は、以上のとおり通知の要否を判断し、通知すると判断した場合に第１ユーザ関連情報を生成及び送信する。これにより、処理部３０３は、第１気分情報取得部３０１により取得された第１気分情報及び第２気分情報取得部３０２により取得された第２気分情報と、スケジュール情報取得部３０６により取得されたスケジュール情報（本実施例における第２ユーザに固有の情報）とに応じたタイミングで上述した通知関連処理を行う。また、処理部３０３は、これらの情報（第１気分情報、第２気分情報及びスケジュール情報）に応じて、第１ユーザの固有情報と、第１ユーザ及び第２ユーザで共通する共通情報のいずれかを含む第１ユーザ関連情報を第２ユーザに通知する処理を上述した通知関連処理として行う。
【００７０】
例えば第１ユーザ関連情報が通知された第２ユーザが出張中だと、第１ユーザとのコミュニケーションをとることができないが、社内会議や顧客訪問が予定されている第２ユーザであれば、予定はあるものの第１ユーザに声掛けすることができる可能性がある。本実施例では、上記のとおり第２ユーザのスケジュールを考慮した第２ユーザへの通知が行われることで、このスケジュールを考慮しない場合に比べて、第２ユーザから第１ユーザへのコミュニケーションをより促進することができる。
【００７１】
［３］第３実施例
本発明の第３実施例について、以下、上記実施例と異なる点を中心に説明する。第２実施例では、第２ユーザのスケジュール情報に応じて通知関連処理が行われたが、第３実施例では、第２ユーザの気分の変化の傾向に応じて通知関連処理が行われる。
【００７２】
図１４は本実施例のサーバ装置３０ｂが実現する機能構成を表す。サーバ装置３０ｂは、図５に表す各部に加え、天気予報取得部３０８と、傾向判断部３０９とを備える。天気予報取得部３０８は、天気予報を取得する。天気予報取得部３０８は、例えば天気予報データを配信するサービスから天気予報データを受け取り、そのデータが表す天気予報を取得する。天気予報取得部３０８は、例えば全国の天気予報を取得し、傾向判断部３０９に供給する。また、本実施例では、第２気分情報取得部３０２が、取得した第２ユーザの気分を表す第２気分情報を傾向判断部３０９に供給する。
【００７３】
傾向判断部３０９は、第２ユーザの気分の変化の傾向（以下「変化傾向」という）を判断する。傾向判断部３０９は、本実施例では、第２ユーザの所在地における天気予報に基づいて変化傾向を判断する。サーバ装置３０ｂには、上述した第２ユーザの固有情報として例えば住所が記憶されている。傾向判断部３０９は、天気予報取得部３０８から供給された全国の天気予報から、第２ユーザの住所を含む地域の天気予報を抽出する。傾向判断部３０９は、抽出した天気予報と、天気と気分のレベルの増減値とを対応付けた傾向判断テーブルとを用いて気分の傾向を判断する。
【００７４】
図１５は傾向判断テーブルの一例を表す。図１５の例では、天気が「晴れ」だとレベルが「＋１」（つまり気分が良くなる方に変化する）、「曇り」だと「０」（つまり気分に変化はない）、「雨」だと「−１」（つまり気分が悪くなる方に変化する）であることが表されている。傾向判断部３０９は、第２気分情報取得部３０２から供給された第２気分情報が表す気分を今日の第２ユーザの気分として、抽出した天気予報が表す明日以降の天気による気分のレベルの増減を反映させたものを第２ユーザの気分の変化傾向と判断する。
【００７５】
図１６は判断された気分の変化傾向の一例を表す。図１６の例では、今日の第２ユーザの気分のレベルが「３」であり、明日以降の天気が「晴れ」、「晴れ」、「雨」、「雨」、「晴れ」となっている。傾向判断部３０９は、明日と明後日は「晴れ」なので、図１６に表す傾向判断テーブルに従い、気分のレベルをそれぞれ「＋１」して「４」、「５」と変化すると判断する。傾向判断部３０９は、３日後、４日後は「雨」なので、傾向判断テーブルに従い、気分のレベルをそれぞれ「−１」して「４」、「３」と変化すると判断し、５日後は「晴れ」なので気分のレベルを「＋１」して「４」と判断する。傾向判断部３０９は、こうして判断した気分の変化傾向を表す気分レベルの推移を通知判断部３３１に供給する。
【００７６】
通知判断部３３１は、第１気分情報取得部３０１により取得された第１気分情報及び第２気分情報取得部３０２により取得された第２気分情報と、傾向判断部３０９により判断された第２ユーザの気分の変化傾向とに基づいて、第２ユーザへの通知を行うか否かを判断する。通知判断部３３１は、本実施例では、第１ユーザの気分と、第２ユーザの気分と、気分の変化傾向と、通知の要否とを対応付けた通知判断テーブルを用いる。
【００７７】
図１７は本実施例の通知判断テーブルの一例を表す。図１７の例では、第１ユーザの気分が「レベル３〜５」なら第２ユーザの気分及び気分の変化傾向にかかわらず通知が「不要」であることが表されている。第１ユーザの気分が「レベル２」の場合は、第２ユーザの気分が「レベル１〜３」であれば「不要」だが、第２ユーザの気分が「レベル４、５」であれば、気分の変化傾向が「３日以内に１以上下降する」（気分が悪くなる傾向にあるということ）であれば通知が「不要」であり、「３日以内に１以上下降しない」（気分が悪くなる傾向にないということ）のであれば通知が「要」であることが表されている。「３日以内に１以上下降する」とは、３日後までに一度でも現在よりも１つ下のレベルに達することをいうものとする。
【００７８】
また、第１ユーザの気分が「レベル１」の場合は、第２ユーザの気分が「レベル１」であれば気分の変化傾向にかかわらず「不要」で「レベル４、５」であれば気分の変化傾向にかかわらず「要」であり、第２ユーザの気分が「レベル２、３」であれば、気分の変化傾向が「３日以内に２以上上昇する」（気分が良くなる傾向にあるということ）であれば通知が「要」であり、「３日以内に２以上上昇しない」（気分が良くなる傾向にないということ）のであれば通知が「不要」であることが表されている。
【００７９】
図１７の例では、第１ユーザの気分が落ち込んでいる状態（レベル１）では第２ユーザへの通知を行いたいが、第２ユーザの気分もよくない状態（レベル２、３）では、第２ユーザの気分が良くなる傾向にある（３日以内にレベルが２以上上昇する）場合に通知が「要」と判断される。また、第１ユーザの気分が良くない状態（レベル２）でも第２ユーザへの通知を行いたいが、第２ユーザの気分もよくない状態（レベル１〜３）では通知は「不要」と判断される。
【００８０】
また、第２ユーザの気分が良い状態（レベル４、５）でも、第２ユーザの気分が悪くなる傾向にない（３日以内にレベルが１以上下降しない）場合に通知が「要」と判断され、第２ユーザの気分が悪くなる傾向にある（３日以内にレベルが１以上下降する）場合には通知が「不要」と判断される。例えば第１ユーザの気分がレベル１であり、第２ユーザの気分及び変化傾向が図１６に表すものである場合には、通知判断部３３１は、今日の第２ユーザの気分が「レベル３」だが、２日後には「レベル５」と「３日以内に２以上上昇する」ことになっているので、通知が「要」と判断する。
【００８１】
関連情報生成部３３２は、第１気分情報取得部３０１により取得された第１気分情報及び第２気分情報取得部３０２により取得された第２気分情報と、傾向判断部３０９により判断された第２ユーザの気分の変化傾向とに応じた第１ユーザ関連情報を生成する。
図１８は本実施例の関連情報テーブルの一例を表す。図１８の例では、第１ユーザの気分が「レベル１」且つ第２ユーザの気分が「レベル４、５」であれば第２ユーザの気分の変化傾向にかかわらず「第１ユーザ固有情報」を含む第１ユーザ関連情報が通知されることが表されている。
【００８２】
また、第１ユーザの気分が「レベル１」、第２ユーザの気分が「レベル２、３」且つ第２ユーザの気分の変化傾向が「３日以内に２以上上昇する」であれば「共通情報」を含む第１ユーザ関連情報が通知され、第１ユーザの気分が「レベル２」、第２ユーザの気分が「レベル４、５」且つ第２ユーザの気分の変化傾向が「３日以内に１以上下降しない」であれば「第１ユーザ固有情報」を含む第１ユーザ関連情報が通知されることが表されている。
【００８３】
以上のとおり、処理部３０３は、第１気分情報取得部３０１により取得された第１気分情報及び第２気分情報取得部３０２により取得された第２気分情報と、傾向判断部３０９により判断された第２ユーザの気分の変化傾向とに応じて通知関連処理を行う。このように第２ユーザの気分の変化傾向にも応じて通知関連処理が行われることで、第２ユーザの現時点の気分だけを考慮する場合に比べて、第２ユーザが第１ユーザとのコミュニケーションをより良いタイミングでとることができる。また、第１ユーザ関連情報により第２ユーザに提供される話題も、第２ユーザの気分の変化の傾向に合ったものにすることができる。
【００８４】
［４］変形例
上述した各実施例はそれぞれが本発明の実施の一例に過ぎず、以下のように変形させてもよい。また、各実施例及び各変形例は、必要に応じて組み合わせて実施してもよい。
【００８５】
［４−１］気分の変化傾向の判断方法
第３実施例で述べた第２ユーザの気分の変化傾向を判断する方法は、上述したものに限らない。
図１９は本変形例のサーバ装置３０ｃが実現する機能構成の一例を表す。サーバ装置３０ｃは、図５に表す各部に加えて図１１に表すスケジュール情報取得部３０６と、図１４に表す傾向判断部３０９とを備える。
【００８６】
スケジュール情報取得部３０６は、図１１の説明で述べたように第２ユーザのスケジュール情報を取得し、傾向判断部３０９に供給する。傾向判断部３０９は、スケジュール情報取得部３０６によって取得されたスケジュール情報が表すイベント、すなわち第２ユーザのスケジュール上のイベントに基づいて変化傾向を判断する。
【００８７】
図２０は本変形例の傾向判断テーブルの一例を表す。図２０の例では、気分のレベルを「＋２」させるイベントが「ゴルフ、旅行」であり、「＋１」させるイベントが「飲み会」であり、「−１」させるイベントが「重要な会議、重要な顧客訪問」であることが表されている。また、レベルを増減させる期間が順に「１日」、「１日」、「３日」であることも表されている。例えば「重要な会議」が予定されている場合、その予定日以前の３日間に渡り気分のレベルが「−１」される。
【００８８】
傾向判断部３０９は、第２気分情報取得部３０２から供給された第２気分情報が表す気分を今日の第２ユーザの気分として、スケジュール情報取得部３０６から供給されたスケジュール情報が表すイベントによる気分のレベルの増減を反映させたものを気分の変化傾向と判断する。
図２１は判断された気分の変化傾向の一例を表す。図２１の例では、今日の第２ユーザの気分のレベルが「３」であり、３日後の「提案コンペ（重要な顧客訪問に相当）」のイベントにかけて気分のレベルが毎日「−１」されていく。また、４日後に「ゴルフ」のイベントがあるので、３日後から４日後にかけては「＋２」される。
【００８９】
その結果、気分のレベルは「３」、「２」、「１」、「１」（１が最低レベルなので−１されても「１」のままとなっている）、「３」、「３」（この例では特にイベントがない場合は増減しないものとする）というように増減する変化の変化傾向が判断される。この例によれば、イベントの影響で上下する第２ユーザの気分の変化傾向を判断することができる。
【００９０】
また、傾向判断部３０９は、第２ユーザの気分の変化履歴に基づいて変化傾向を判断してもよい。
図２２は変化履歴と判断された気分の変化傾向の一例を表す。図２２（ａ）の例では、気分の変化履歴が昨日は「４」で今日が「３」（いずれも気分のレベルの値）である場合に、傾向判断部３０９が、明日は「２」、明後日は「１」、３日後は「２」、４日後は「３」になると変化傾向を判断している。この例では、昨日から今日にかけて気分のレベルが「−１」されたので、気分レベルが「１」になるまでその減少傾向（１日にレベルが１減少）が続き、「１」になった後はその反対の増加傾向（１日にレベルが１増加）になると判断されている。
【００９１】
図２２（ｂ）の例では、気分の変化履歴が昨日は「５」で今日が「３」である場合に、傾向判断部３０９が、明日は「１」、明後日は「３」、３日後は「５」、４日後は「３」になると変化傾向を判断している。この例では、昨日から今日にかけて気分のレベルが「−２」されたので、気分レベルが「１」になるまでその減少傾向（１日にレベルが２減少）が続き、「１」になった後はその反対の増加傾向（１日にレベルが２増加）が続き、さらに「５」になった後はその反対の減少傾向（１日にレベルが２減少）になると判断されている。
【００９２】
この例によれば、自分の気分がバイオリズムのように規則的に変化するタイプのユーザであるほど、正確な変化傾向を判断することができる。なお、図２２の例では２回分の気分の判定結果が変化履歴として用いられたが、これに限らず、３回分以上の気分の判定結果が変化履歴として用いられてもよい。また、過去の変化の履歴から未来の変化傾向を判断する方法として、天候や在庫、株価など各種の予測と同じ手法が用いられてもよい。
【００９３】
また、傾向判断部３０９は、第２ユーザの属性に基づいて変化傾向を判断してもよい。
図２３は本変形例のサーバ装置３０ｄが実現する機能構成の一例を表す。サーバ装置３０ｄは、図５に表す各部に加えて、図１４に表す傾向判断部３０９と、属性情報取得部３１１とを備える。第２気分情報取得部３０２は、取得した第２気分情報を傾向判断部３０９及び属性情報取得部３１１に供給する。
【００９４】
属性情報取得部３１１は、第２ユーザの属性を表す属性情報を取得する。属性情報取得部３１１は、第２気分情報が供給されると、ユーザ固有情報記憶部３０４を参照し、第２気分情報が表す第２ユーザのユーザＩＤに対応付けられたユーザ属性を表す情報、すなわち第２ユーザの属性情報を取得する。属性情報取得部３１１は、取得した属性情報を傾向判断部３０９に供給する。
【００９５】
傾向判断部３０９は、属性情報取得部３１１が取得した属性情報を用いて第２ユーザの気分の変化傾向を判断する。変化傾向の判断に利用可能な属性としては、例えばユーザの性格が用いられる。傾向判断部３０９は、例えば理性的で落ち着いた性格のユーザであれば、気分の変化が少なく、変動の周期も長いものとして変化傾向を判断し、情熱的で感情の起伏が激しい性格のユーザであれば、気分の変化が大きく、変動の周期も短いものとして変化傾向を判断する。
【００９６】
傾向判断部３０９は、ユーザ属性と、レベル増減値と、増減期間とを対応付けた傾向判断テーブルを用いる。
図２４は本変形例の傾向判断テーブルの別の一例を表す。図２４の例では、ユーザ属性が「情熱的、感情的、激しい、・・・」である場合、レベル増減値が「２」で増減期間が「１日間」であり、ユーザ属性が「冷静、理性的、穏やか、・・・」である場合、レベル増減値が「１」で増減期間が「２日間」であることが表されている。増減期間とは、レベル増減値だけ気分のレベルが変化するのに要する期間を表す。
【００９７】
傾向判断部３０９は、取得された属性情報が表す第２ユーザの属性に傾向判断テーブルのユーザ属性の欄の言葉が含まれていれば、その言葉に対応付けられたレベル増減値と増減期間とを用いて変化傾向を判断する。
図２５は判断された気分の変化傾向の別の一例を表す。図２５の例では、ユーザ属性として情熱的な性格であることが登録されたユーザＡと、冷静な性格であることが登録されたユーザＢについて判断された変化傾向が表されている（Ａ、Ｂはいずれも第２ユーザ）。ユーザＡ、Ｂとも、気分のレベルが昨日は「４」で今日が「３」というように下がる傾向にある状態とする。
【００９８】
この場合に、傾向判断部３０９は、明日以降の気分のレベルの変化傾向を、ユーザＡについては「１」、「３」、「５」、「３」と判断し、ユーザＢについては「３」、「２」、「２」、「１」と判断している。このように、傾向判断部３０９は、同じように気分のレベルが変化しているユーザ同士であっても、ユーザ属性によって異なる変化傾向を判断する。これにより、ユーザ属性を考慮しない場合に比べて、気分が変わりやすいユーザや気分の変化が少ないユーザについての気分の変化傾向をより正確に判断することができる。
【００９９】
［４−２］第２ユーザの体調
上記の各例では第１ユーザの気分及び第２ユーザの気分を考慮した通知関連処理が行われたが、さらに、第２ユーザの体調を考慮した通知関連処理が行われてもよい。この体調は、例えば第２ユーザ端末を用いて測定される。
【０１００】
図２６は本変形例の第２ユーザ端末２０ｅのハードウェア構成を表す。第２ユーザ端末２０ｅは、図３に表すＣＰＵ２１からスピーカ２８までの各部に加え、センサ２９を備える。センサ２９は、第２ユーザの体調を表す指標となる値を測定する。体調を表す指標とは、例えば血圧や脈拍、体温、歩数などである。センサ２９は、第２ユーザ端末２０ｅに内蔵されているものであってもよいし、周辺機器（血圧等を測定するウェアラブル端末など）と連動してこれらの指標を測定するものであってもよい。
【０１０１】
図２７は本変形例の各装置が実現する機能構成の一例を表す。図２７では、本変形例に係るコミュニケーション支援システム１ｅが備える第１ユーザ端末１０と、第２ユーザ端末２０ｅと、サーバ装置３０ｅとが表されている。第２ユーザ端末２０ｅは、図５に表す各部に加え、体調指標測定部２０６と、体調情報送信部２０７とを備える。サーバ装置３０ｅは、図５に表す各部に加え、体調情報取得部３１３を備える。
【０１０２】
体調指標測定部２０６は、前述した第２ユーザの体調を表す指標となる値を測定し、その測定結果を体調情報送信部２０７に供給する。体調情報送信部２０７は、体調指標測定部２０６により測定された指標により表される第２ユーザの体調を表す体調情報をサーバ装置３０ｅに送信する。体調情報送信部２０７は、体調指標測定部２０６から測定結果が供給されると、その測定結果に基づいて体調情報を生成し、サーバ装置３０ｅに送信する。体調情報は、例えば血圧や脈拍の測定値と第２ユーザのユーザＩＤとを対応付けた情報である。
【０１０３】
送信された体調情報は、サーバ装置３０ｅが受信して体調情報取得部３１３に供給される。体調情報取得部３１３は、こうして供給された体調情報、すなわち第２ユーザの体調を表す情報を取得し、通知判断部３３１に供給する。通知判断部３３１は、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報と、体調情報取得部３１３により取得された体調情報とに基づいて、第２ユーザへの通知を行うか否かを判断する。通知判断部３３１は、第１ユーザの気分と、第２ユーザの気分と、第２ユーザの体調と、通知の要否とを対応付けた通知判断テーブルを用いてこの判断を行う。
【０１０４】
図２８は本変形例の通知判断テーブルの一例を表す。図２８の例では、第１ユーザの気分が「レベル３〜５」なら第２ユーザの気分及び第２ユーザの体調にかかわらず通知が「不要」となっている。また、第１ユーザの気分が「レベル２」で第２ユーザの気分が「レベル１〜３」の場合と、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル１」の場合も通知が「不要」である。
【０１０５】
一方、第１ユーザの気分が「レベル２」で第２ユーザの気分が「レベル４、５」の場合、第２ユーザの体調が「体温が３７度未満」であれば通知が「要」であり、「体温が３７度以上」であれば通知が「不要」となっている。また、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル２〜５」の場合、第２ユーザの体調が「体温が３８度未満」であれば通知が「要」であり、「体温が３８度以上」であれば通知が「不要」となっている。この例では、体調が悪い第２ユーザへの通知を基本的には控える一方、第１及び第２ユーザの気分の状態によっては、多少体調が悪くても第１ユーザへのコミュニケーションをとってもらうために第２ユーザへの通知が行われる。
【０１０６】
関連情報生成部３３２は、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報と、体調情報取得部３１３により取得された体調情報とに応じた第１ユーザ関連情報を生成する。
図２９は本変形例の関連情報テーブルの一例を表す。図２９の例では、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル２〜５」である場合、第２ユーザの体調が「体温が３７度以上３８度未満」であれば「共通情報」を含む第１ユーザ関連情報が通知され、「体温が３７度未満」であれば「第１ユーザ固有情報」を含む第１ユーザ関連情報が通知されることが表されている。
【０１０７】
また、第１ユーザの気分が「レベル２」、第２ユーザの気分が「レベル４、５」且つ第２ユーザの体調が「体温が３７度未満」の場合には「第１ユーザ固有情報」を含む第１ユーザ関連情報が通知されることが表されている。この例では、第２ユーザの体温が３７度未満であれば会話への集中力が保ちやすいので、第２ユーザには直接関係ないが第１ユーザが興味を持ちやすい第１ユーザの固有情報を話題として提供するが、体温が３７度以上になると熱で会話への集中が難しくなるため、第２ユーザにとっても興味を持ちやすい情報（共通の固有情報）又は気軽に会話しやすい情報（一般情報）を話題として提供している。
【０１０８】
以上のとおり、処理部３０３は、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報と、体調情報取得部３１３により取得された体調情報とに応じて通知関連処理を行う。このように第２ユーザの体調にも応じて通知関連処理が行われることで、体調を考慮しない場合に比べて、第２ユーザが無理なく第１ユーザとコミュニケーションをとることができる。
【０１０９】
［４−３］通知履歴
処理部３０３による通知において、第２ユーザへの通知の履歴が考慮されてもよい。
図３０は本変形例のサーバ装置３０ｆが実現する機能構成の一例を表す。サーバ装置３０ｆは、図５に表す各部に加え、通知履歴蓄積部３１６を備える。本変形例の関連情報送信部３３３は、第２ユーザに対応付けられた宛先に第１ユーザ関連情報を送信すると、その第２ユーザのユーザＩＤを通知履歴蓄積部３１６に供給する。
【０１１０】
通知履歴蓄積部３１６は、処理部３０３による第２ユーザへの通知の履歴を蓄積する。通知履歴蓄積部３１６は、関連情報送信部３３３から第２ユーザのユーザＩＤが供給されると、ユーザＩＤが供給された日時とそのユーザＩＤとを対応付けた通知履歴情報を記憶することで、第２ユーザへの通知履歴を蓄積する。通知判断部３３１は、第１気分情報及び第２気分情報が供給されると、通知履歴蓄積部３１６からその第２気分情報が表すユーザＩＤを含む通知履歴情報を読み出して、第１気分情報、第２気分情報及び通知履歴情報に基づいて、第２ユーザへの通知を行うか否かを判断する。
【０１１１】
図３１は本変形例の通知判断テーブルの一例を表す。図３１の例では、第１ユーザの気分が「レベル３〜５」なら第２ユーザの気分及び第２ユーザの体調にかかわらず通知が「不要」となっている。また、第１ユーザの気分が「レベル２」で第２ユーザの気分が「レベル１〜３」の場合と、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル１」の場合も通知が「不要」である。
【０１１２】
一方、第１ユーザの気分が「レベル２」で第２ユーザの気分が「レベル４、５」の場合、第２ユーザへの通知履歴（１月当たりの通知回数）が「５回／月未満」であれば通知が「要」であり、「５回／月以上」であれば通知が「不要」となっている。また、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル２〜５」の場合、第２ユーザへの通知履歴が「１０回／月未満」であれば通知が「要」であり、「１０回／月以上」であれば通知が「不要」となっている。この例では、通知回数が多すぎる第２ユーザへは通知を控えるようになっている。通知判断部３３１は読み出した通知履歴情報を第１気分情報及び第２気分情報とともに関連情報生成部３３２に供給する。
【０１１３】
関連情報生成部３３２は、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報と、通知履歴蓄積部３１６により蓄積された通知履歴情報とに応じた第１ユーザ関連情報を生成する。
図３２は本変形例の関連情報テーブルの一例を表す。図３２の例では、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル２〜５」である場合、第２ユーザへの通知履歴が「５回／月以上１０回／月未満」であれば「共通情報」を含む第１ユーザ関連情報が通知され、「５回／月未満」であれば「第１ユーザ固有情報」を含む第１ユーザ関連情報が通知されることが表されている。
【０１１４】
また、第１ユーザの気分が「レベル２」、第２ユーザの気分が「レベル４、５」且つ第２ユーザへの通知履歴が「５回／月未満」の場合には「第１ユーザ固有情報」を含む第１ユーザ関連情報が通知されることが表されている。この例では、第２ユーザへの通知履歴が５回／月未満であればまだ負担が軽いので、第２ユーザには直接関係ないが第１ユーザが興味を持ちやすい第１ユーザの固有情報を話題として提供するが、５回／月以上になると第２ユーザへの負担が重くなってくるため、第２ユーザにとっても興味を持ちやすい情報（共通の固有情報）又は気軽に会話しやすい情報（一般情報）を話題として提供している。
【０１１５】
以上のとおり、処理部３０３は、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報と、通知履歴蓄積部３１６により蓄積された通知履歴情報が表す通知履歴（第２ユーザへの通知履歴）とに応じて通知関連処理を行う。このように第２ユーザへの通知履歴にも応じて通知関連処理が行われることで、通知履歴を考慮しない場合に比べて、通知回数が多すぎて第２ユーザの負担が大きくなり過ぎること抑えることができる。なお、通知履歴情報の蓄積は外部装置（第２ユーザ端末や外部ストレージ装置など）で行われてもよい。その場合、処理部３０３は、外部装置から蓄積された通知履歴情報を取得して用いればよい。
【０１１６】
［４−４］複数の第１ユーザ及び複数の第２ユーザ
第１ユーザ及び第２ユーザの組（コミュニケーション支援システムによってコミュニケーションが支援されるユーザの組）は複数あってもよい。また、各組における第１ユーザ及び第２ユーザの人数も複数であってもよい。この場合、通知判断部３３１は、例えば互いに組となる第１ユーザのユーザＩＤと第２ユーザのユーザＩＤとを対応付けたユーザ対応テーブルを記憶しておき、供給された第１気分情報が表すユーザＩＤにそのユーザ対応テーブルにおいて対応付けられたユーザＩＤを表す第２気分情報が供給されると、それらの第１気分情報及び第２気分情報に基づいて通知の要否の判断を行う。
【０１１７】
［４−５］通知タイミング（その１）
処理部３０３は、例えば第１実施例では、組となる第１気分情報及び第２気分情報の両方が取得されたタイミングで第１ユーザ関連情報を通知したが、通知のタイミングはこれに限らない。処理部３０３は、例えば、昼休みや業務が終了する時間帯などの決められた時刻に通知を行ってもよい。
【０１１８】
他にも、処理部３０３は、例えば第１気分情報及び第２気分情報の両方が取得されたタイミングが図１１に表すスケジュール情報取得部３０６が取得したスケジュール情報により表されるイベントの時間帯である場合、その時間帯が終わった後に通知を行ってもよい。また、処理部３０３は、特定のイベント（重要な会議や顧客訪問など）についてはその時間帯を外して通知を行い、それ以外のイベント（移動やプライベートな用事など）についてはその時間帯でも通知を行うようにしてもよい。いずれの場合も、第２ユーザが第１ユーザ関連情報を見るのが難しい時間帯に通知がされることを防ぐことができる。
【０１１９】
また、処理部３０３は、複数の第２ユーザの各々への第１ユーザ関連情報の通知に関する通知関連処理を行う場合に、それら複数の第２ユーザで通知のタイミングを共通にする第１の方法を用いてもよいし、複数の第２ユーザで通知のタイミングを共通にしない第２の方法を用いてもよい。第２の方法での通知においては、複数の第２ユーザのそれぞれについてタイミングを異ならせてもよいし、複数の第２ユーザのうち第１グループと第２グループとでタイミングを異ならせてもよい。このグループは３以上あってもよいし、グループと個人とが混在していてもよい。また、第２の方法で通知しても、通常はタイミングが共通にならないが、偶然通知のタイミングが共通になる場合があってもよい。
【０１２０】
処理部３０３は、例えばユーザＡ、Ｂ、Ｃに対して、全ユーザで共通に設定された時刻になったときに通知を行ったり（第１の方法での通知）、ユーザ毎に設定された別々の時刻になったときに通知を行ったり（第２の方法での通知）する。また、処理部３０３は、第２の方法を用いる場合、各第２ユーザについて、第１気分情報及び第２気分情報の両方が取得されて揃ったとき又はそれから所定の時間が経過してから通知を行うことで、通知のタイミングを異ならせてもよい（この場合は偶然タイミングが共通することもある）。
【０１２１】
また、処理部３０３は、第１ユーザ関連情報の種類に応じて、前述した第１の方法及び第２の方法のいずれかの方法で通知関連処理を行ってもよい。処理部３０３は、例えば共通情報を含む第１ユーザ関連情報を通知する第２ユーザに対しては第１の方法で通知関連処理を行い、第１ユーザ固有情報を含む第１ユーザ関連情報を通知する第２ユーザに対しては第２の方法で通知関連処理を行う。第１及び第２気分情報に応じた第１ユーザ関連情報が生成される場合、第２ユーザによって第１ユーザ関連情報の種類が異なるので、第１の方法で通知されるグループと、第２の方法で通知されるグループとに別れることになる。
【０１２２】
なお、第１ユーザ関連情報の種類が気分情報にかかわらず固定されている場合であっても、その固定された第１ユーザ関連情報の種類に応じて第１の方法及び第２の方法のいずれかの方法で通知関連処理が行われればよい。第１の方法で通知がされると、第２の方法が用いられる場合に比べて、複数の第２ユーザが第１ユーザに声をかけようとするタイミングの間隔が広くなりやすい。反対に、第２の方法で通知がされると、第１の方法が用いられる場合に比べて、複数の第２ユーザが第１ユーザに声をかけようとするタイミングの間隔が狭くなりやすい。
【０１２３】
複数の第２ユーザで話題が重複しても、共通情報に関する話題であれば自然だが（一般情報はもちろん、第１ユーザと共通する属性は第２ユーザ毎に異なる場合があるから）、第１ユーザの属性情報に関する話題だと不自然になることがある。本変形例では、このように複数の第２ユーザが第１ユーザに声をかけるタイミングをずらした方が良い場合と、一致させても問題ない場合とで、それぞれの場合に合わせた通知を行うことができる。
【０１２４】
［４−６］通知タイミング（その２）
第２ユーザと組になる第１ユーザが複数である場合に、各々についての通知のタイミングを共通にしてもよいし、異ならせてもよい。
図３３は本変形例のサーバ装置３０ｇが実現する機能構成の一例を表す。サーバ装置３０ｇは、図５に表す各部に加え、属性情報取得部３１７と、優先順位判断部３１８とを備える。
【０１２５】
本変形例では、第１気分情報取得部３０１が、取得した第１気分情報を属性情報取得部３１７に供給する。属性情報取得部３１７は、第１ユーザの属性を表す属性情報を取得する。属性情報取得部３１７は、第１気分情報が供給されると、ユーザ固有情報記憶部３０４を参照し、第１気分情報が表す第１ユーザのユーザＩＤに対応付けられたユーザ属性を表す情報、すなわち第１ユーザの属性情報を取得する。属性情報取得部３１７は、取得した属性情報を優先順位判断部３１８に供給する。
【０１２６】
優先順位判断部３１８は、複数の第１ユーザがいる場合に、それらの第１ユーザの属性に基づいて複数の第１ユーザの各々の優先順位を判断する。優先順位判断部３１８は、例えば、図２４に表す「情熱的、感情的、激しい、・・・」等の性格で気分の変化が激しい傾向にあるユーザの優先順位を、「冷静、理性的、穏やか、・・・」等の性格で気分の変化が少ない傾向にあるユーザの優先順位よりも高くする。これ以外にも、優先順位判断部３１８は、例えば、年齢が低いユーザほど優先順位を高くしたり、内勤のユーザの優先順位を外勤のユーザの優先順位よりも高くしたりしてもよい。
【０１２７】
優先順位判断部３１８は、複数の第１ユーザのユーザＩＤと判断した優先順位を表す情報（例えば優先順位の順番）とを対応付けた優先順位情報を通知判断部３３１に供給する。通知判断部３３１は、まず、供給された優先順位情報により表される優先順位が最も高い第１ユーザについての通知の要否を判断する。通知判断部３３１は、通知が不要と判断すれば、次に優先順位が高い第１ユーザについての通知の要否を判断し、これを通知が必要と判断するまで繰り返し行う。
【０１２８】
通知判断部３３１は、通知が必要と判断すると、所定の時間が経過してから次に優先順位が高い第１ユーザについての通知の要否を判断する。このようにして、処理部３０３は、複数の第１ユーザのそれぞれについての第１ユーザ関連情報を、各第１ユーザについて判断された優先順位に応じたタイミング（この例では優先順位が高いほど早いタイミング）で第２ユーザに通知する。これにより、第２ユーザに複数の第１ユーザについての第１ユーザ関連情報の通知が集中することを避けつつ、且つ、優先順位の高い第１ユーザには早めにコミュニケーションがとられるようにすることができる。
【０１２９】
なお、前述の例では優先順位が高いほど早いタイミングで通知がされたが、これに限らず、処理部３０３は、例えば優先順位が高いほど第２ユーザが通知を見る可能性の高いタイミング（通勤時間や昼休みの時間など）で通知してもよい。この場合、優先順位が低い第１ユーザについての第１ユーザ関連情報は、第２ユーザが通知を見る可能性が低いタイミング（早朝や深夜など）で通知がされる。これにより、優先順位の高い第１ユーザについての第１ユーザ関連情報は、優先順位の低い第１ユーザについての第１ユーザ関連情報に比べてより確実に第２ユーザに見てもらうようにすることができる。
【０１３０】
なお、優先順位は他の方法で判断されてもよい。優先順位判断部３１８は、例えば、第１ユーザ関連情報の種類に基づいて複数の第１ユーザの各々の優先順位を判断する。優先順位判断部３１８は、例えば、共通情報を含む第１ユーザ関連情報が通知される第１ユーザよりも、第１ユーザ固有情報を含む第１ユーザ関連情報が通知される第１ユーザの方の優先順位を高くする。この場合、第２ユーザは、共通情報が話題として提供された第１ユーザよりも、第１ユーザ固有情報が話題として提供された第１ユーザの方と早くコミュニケーションをとることができる。
【０１３１】
また、優先順位判断部３１８は、取得された第１気分情報に基づいて優先順位を判断してもよい。この場合、優先順位判断部３１８は、例えば取得された第１気分情報が表す気分のレベルが低いほど優先順位を高くする。なお、第１気分情報に応じた第１ユーザ関連情報が生成される場合、前述した第１ユーザ関連情報の種類も第１気分情報に応じて決まることになるので、第１ユーザ関連情報の種類に基づいて優先順位を判断するということは、第１気分情報に基づいて優先順位を判断するともいえることになる。
【０１３２】
また、図１４等に表す傾向判断部３０９が第１ユーザの気分の変化傾向を判断する場合に、優先順位判断部３１８は、判断された気分の変化傾向に基づいて優先順位を判断してもよい。この場合、優先順位判断部３１８は、例えば気分が下降傾向にあるユーザほど優先順位を高くする。いずれの場合も、早めにコミュニケーションをとった方がよいユーザほど早いタイミングでその第１ユーザについての第１ユーザ関連情報が通知されるようにすることが望ましい。
【０１３３】
［４−７］コミュニケーションの頻度
第１ユーザ及び第２ユーザのコミュニケーションの頻度が利用されてもよい。
図３４は本変形例の各装置が実現する機能構成の一例を表す。図３４では、本変形例に係るコミュニケーション支援システム１ｈが備える第１ユーザ端末１０と、第２ユーザ端末２０ｈと、サーバ装置３０ｈとが表されている。第２ユーザ端末２０ｈは、図５に表す各部に加え、頻度情報蓄積部２０８と、頻度情報送信部２０９とを備える。サーバ装置３０ｈは、図５に表す各部に加え、頻度情報取得部３１９を備える。
【０１３４】
頻度情報蓄積部２０８は、第２ユーザと第１ユーザとのコミュニケーションの頻度を表す頻度情報を蓄積する。頻度情報は、例えば、第１ユーザとの電子メールの送受信の件数や、第１ユーザのＳＮＳのアカウントへの投稿数、第１ユーザとの電話の件数などによって表される。頻度情報蓄積部２０８は、例えば第１ユーザの電子メールアドレスを記憶しておき、電子メールソフトに対してそのアドレスについての電子メールの送受信の件数を定期的に要求して、その応答で供給された件数を頻度情報として蓄積する。
【０１３５】
頻度情報送信部２０９は、頻度情報蓄積部２０８に蓄積された頻度情報をサーバ装置３０ｈに送信する。サーバ装置３０ｈは、送信されてきた頻度情報を頻度情報取得部３１９に供給する。頻度情報取得部３１９は、供給された頻度情報、すなわち第２ユーザと第１ユーザとのコミュニケーションの頻度を表す情報を取得する。頻度情報取得部３１９は、取得した頻度情報を通知判断部３３１に供給する。
【０１３６】
図３５は本変形例の通知判断テーブルの一例を表す。図３５の例では、第１ユーザの気分が「レベル２」で第２ユーザの気分が「レベル４、５」の場合、コミュニケーション頻度（１週間当たりのコミュニケーション回数）が「５回／週以上」であれば通知が「要」であり、「５回／週未満」であれば通知が「不要」となっている。また、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル２〜５」の場合、コミュニケーション頻度が「１０回／週以上」であれば通知が「要」であり、「１０回／週未満」であれば通知が「不要」となっている。この例では、第１ユーザとのコミュニケーションがうまく取れる可能性が高い第２ユーザ、すなわちコミュニケーション頻度が高い第２ユーザへ通知がされるようになっている。
【０１３７】
図３６は本変形例の関連情報テーブルの一例を表す。図３６の例では、第１ユーザの気分が「レベル１」で第２ユーザの気分が「レベル２〜５」である場合、コミュニケーション頻度が「１０回／週以上」であれば「第１ユーザ固有情報」を含む第１ユーザ関連情報が通知され、「５回／週以上１０回／週未満」であれば「共通情報」を含む第１ユーザ関連情報が通知されるようになっている。また、第１ユーザの気分が「レベル２」、第２ユーザの気分が「レベル４、５」且つコミュニケーション頻度が「５回／週以上」の場合には「共通情報」を含む第１ユーザ関連情報が通知されるようになっている。
【０１３８】
この例では、コミュニケーション頻度が低い第２ユーザへは気軽に会話しやすい共通情報を話題として提供している。以上のとおり、本変形例の処理部３０３は、第１気分情報取得部３０１により取得された第１気分情報と、第２気分情報取得部３０２により取得された第２気分情報と、頻度情報取得部３１９により取得された頻度情報、すなわち第１ユーザ及び第２ユーザのコミュニケーション頻度とに応じて通知関連処理を行う。このように第１ユーザ及び第２ユーザのコミュニケーション頻度にも応じて通知関連処理が行われることで、このコミュニケーション頻度を考慮しない場合に比べて、第１ユーザ及び第２ユーザのコミュニケーションがより円滑にとられるようにすることができる。
【０１３９】
なお、コミュニケーション頻度は、図３３に表す優先順位判断部３１８による優先順位の判断に用いられてもよい。優先順位判断部３１８は、例えば、第２ユーザとのコミュニケーション頻度が高い第１ユーザほど優先順位を高く（又は低く）する。これにより、第２ユーザとのコミュニケーションが円滑にとれる第１ユーザについての第１ユーザ関連情報ほど早い（又は遅い）タイミングで通知することができる。
【０１４０】
［４−８］第２ユーザの固有情報に応じた通知関連処理
第２実施例において用いられる第２ユーザの固有情報はスケジュール情報に限らない。処理部３０３は、例えば、第２ユーザの趣味を第２ユーザの固有情報として用いてもよい。具体的には、処理部３０３は、第２ユーザの趣味が時期に関係するものである場合、その時期には第２気分情報が表す気分のレベルを増加させて（特定の値を加えたり、係数を掛けたりする）、通知の可否の判断や第１ユーザ関連情報の生成を行う。
【０１４１】
時期に関係する趣味とは、例えばスキーやスノーボード（冬に関係する趣味）、サーフィンやビーチバレー（夏に関係する趣味）である。他にも、百人一首（正月に関係する趣味）、高校野球観戦（春や夏の甲子園の時期に関係する趣味）、プロゴルフ観戦（４大メジャー開催時期に関係する趣味）などが挙げられる。これにより、ユーザが自分の趣味に打ち込めて気分が高揚しやすい時期には、その気分に合わせて通知関連処理を行うことができる。また、第２ユーザの誕生日や第２ユーザの家族の誕生日を第２ユーザの固有情報として用いてもよい。この場合、処理部３０３は、これらの誕生日の前後には第２ユーザの気分が高揚しやすいものとして、第２気分情報が表す気分のレベルを増加させて通知の可否の判断や第１ユーザ関連情報の生成を行う。
【０１４２】
他にも、例えば第２ユーザの持病を第２ユーザの固有情報として用いてもよい。この場合、処理部３０３は、持病により体調が悪い時期（例えば花粉症なら春先、関節痛なら冬など）には第２ユーザの気分が落ち込みやすいものとして、第２気分情報が表す気分のレベルを減少させて通知の可否の判断や第１ユーザ関連情報の生成を行う。いずれの場合も、第２ユーザの固有情報が表す特定の時期において上がりやすい又は下がりやすい第２ユーザの気分に合わせて通知関連処理を行うことができる。
【０１４３】
［４−９］第１ユーザ関連情報の種類
処理部３０３が通知する第１ユーザ関連情報は上述したものに限らない。例えば図９に表す判定結果情報Ａ１と固有情報（ユーザ属性情報Ａ２、スケジュール情報Ａ３）、共通情報のうちの１つでもよいし、複数を組み合わせたものでもよい。また、これらのいずれも含まない通知用の画像が第１ユーザ関連情報として通知されてもよい。この通知用の画像の表示が第１ユーザの気分が悪いと判定されたことを意味していると第２ユーザが知っていれば、第２ユーザは第１ユーザの気分が悪い状態であることを踏まえた上で第１ユーザに対して何らかのコミュニケーションをとるという行動を起こすことができる。
【０１４４】
［４−１０］第１気分情報等に応じた通知関連処理
処理部３０３は、図６に表す通知判断テーブルや図７に表す関連情報テーブルなどを用いて通知関連処理を行ったが、各テーブルの内容は上述したものに限らない。処理部３０３は、例えば図１２に表す通知判断テーブルの代わりに、第１ユーザの気分と第２ユーザの気分と通知の要否を対応付けた通知判断テーブルを複数記憶しておき、イベントの種類に応じて用いる通知判断テーブルを選択してもよい。
【０１４５】
この場合でも、処理部３０３は、第１気分情報取得部３０１により取得された第１気分情報及び第２気分情報取得部３０２により取得された第２気分情報と、スケジュール情報取得部３０６により取得されたスケジュール情報とに応じたタイミングで上述した通知関連処理を行うことになる。また、処理部３０３は、テーブルを用いずに所定のアルゴリズムを用いて通知の要否や第１ユーザ関連情報に含める情報の種類の判断などを行ってもよい。例えば、通知判断部３３１が、第１ユーザの気分のレベルが閾値未満であり第２ユーザの気分のレベルが閾値以上であれば通知を行うと判断するといった具合である。いずれの場合も、第１ユーザの気分情報や第２ユーザの気分などに応じた通知関連処理が行われるようになっていればよい。
【０１４６】
［４−１１］気分の判定方法
気分判定部１０１及び２０１は、上記の各例では、各ユーザ（第１ユーザ及び第２ユーザ）の音声から気分を判定したが、気分の判定方法はこれに限らない。気分判定部は、例えば図２６に表すセンサ２９のようなセンサが測定したユーザの血圧や脈拍、体温、歩数などの測定結果からユーザの気分を判定してもよい（例えば血圧が標準よりも高すぎたり低すぎたりすると気分が悪いと判定する）。また、気分判定部は、スマートフォンが備えるデジカメ機能で撮影されたユーザの顔を解析して気分を判定してもよい。この判定には、例えば特開２０１３−３００号公報に記載されている技術などの公知の技術が用いられればよい。
【０１４７】
［４−１２］気分情報の取得方法
気分情報の取得方法は上述したものに限らない。例えば第１ユーザ端末に第１ユーザが自分の気分を入力し、気分情報送信部１０２が入力された気分を表す第１気分情報を生成して送信することで、第１気分情報取得部３０１が第１気分情報を取得する（第２気分情報についても同じ方法で取得される）。この場合でも、上記実施例と同様に、両者の気分に応じて話題にしやすい情報を第２ユーザに提供することができる。
【０１４８】
［４−１３］通知関連処理
処理部３０３が第１気分情報及び第２気分情報に応じて行う通知関連処理は、上述したものに限らない。例えば、処理部３０３は、通知の可否を判断する処理、第１ユーザ関連情報を生成する処理、第１ユーザ関連情報を送信する処理のうちの１つ又は２つだけを、第１気分情報及び第２気分情報に応じて行い、残りの処理は両気分情報とは関係なく行ってもよいし、一方の気分情報に応じて行ってもよい。
【０１４９】
処理部３０３は、例えば、第２ユーザへの通知の可否を判断する処理については、第１気分情報取得部３０１により取得された第１気分情報を用いずに行う。この場合、処理部３０３は、例えば第２気分情報が表す第２ユーザの気分と、通知の要否とを対応付けた通知判断テーブルを用いて通知の可否を判断する。処理部３０３は、第２気分情報取得部３０２により取得された第２気分情報のみに応じて通知の可否を判断する処理を行ってもよいし、第２気分情報に加えて上述した第２ユーザの固有情報や第２ユーザの気分の変化傾向などにも応じてその処理を行ってもよい。
【０１５０】
また、処理部３０３は、通知の可否を判断せずに必ず通知するものとしてもよい。また、処理部３０３は、第１ユーザ関連情報を生成する処理の代わりに、第１ユーザ関連情報を外部装置から取得する処理や、複数の第１ユーザ関連情報から通知するものを抽出する処理を、両気分情報に応じて行ってもよい。要するに、処理部３０３は、第１ユーザ関連情報の第２ユーザへの通知に関連する処理（通知関連処理）を少なくとも１つ、第１気分情報及び第２気分情報に応じて行うものであればよい。
【０１５１】
［４−１４］各部を実現する装置
図５等に表す各機能を実現する装置は上述したものに限らない。
図３７は本変形例の各装置が実現する機能構成の一例を表す。図３７の例では、第１ユーザ端末１０と、第２ユーザ端末２０ｋとを備えるコミュニケーション支援システム１ｋが表されている。
【０１５２】
第２ユーザ端末２０ｋは、図５に表す気分判定部２０１及び関連情報出力部２０４の他に、サーバ装置３０が備えていた第１気分情報取得部３０１と、第２気分情報取得部３０２と、処理部３０３と、ユーザ固有情報記憶部３０４と、一般情報記憶部３０５とを備える。処理部３０３は、通知判断部３３１と、関連情報生成部３３２とを備える。この例では、第２ユーザ端末２０ｋが第１気分情報及び第２気分情報を取得し、両気分情報に応じた通知関連処理を行う。
【０１５３】
図３７の例以外にも、例えば図１１に表すスケジュール管理部２０５の機能をサーバ装置が実現してもよいし、第２ユーザ端末でもサーバ装置でもない他の外部装置が実現してもよい。また、第１気分情報取得部３０１、第２気分情報取得部３０２及び処理部３０３等のサーバ装置が備える各機能をサーバ装置以外の情報処理装置が実現してもよい。いずれの場合も、図５等に表す各機能を１以上の情報処理装置のいずれかが実現していればよい。
【０１５４】
［４−１５］心身状態
上記の各例では第１ユーザ及び第２ユーザの気分の状態に応じた通知関連処理が行われたが、気分ではなく、体調を含む身体の状態に応じた通知関連処理が行われてもよい。
図３８は本変形例の各装置が実現する機能構成の一例を表す。図３８の例では、第１ユーザ端末１０ｍと、第２ユーザ端末２０ｍと、サーバ装置３０ｍとを備えるコミュニケーション支援システム１ｍが表されている。
【０１５５】
第１ユーザ端末１０ｍは、心身状態判定部１０３と、心身状態情報送信部１０４とを備える。第２ユーザ端末２０ｍは、心身状態判定部２１０と、心身状態情報送信部２１１とを備える。サーバ装置３０ｍは、第１心身状態情報取得部３２１と、第２心身状態情報取得部３２２とを備える。
【０１５６】
心身状態判定部１０３は、第１ユーザの心身状態を判定する。ここでいう心身状態には、上述した気分、体調の他、病気や怪我など、心と身体のあらゆる状態が含まれる。心身状態判定部１０３は、例えば、音声から第１ユーザの気分を判定するとともに、図２６に表す体調指標測定部２０６と同様に第１ユーザの体調の指標を表す値を測定することで第１ユーザの体調を判定する。体調の判定結果は、例えば気分の判定と同様に複数段階のレベルで表される。
【０１５７】
また、心身状態判定部１０３は、病気や怪我の有無を質問する問診の画面を表示して、ユーザが病気や怪我があることを示す操作を行うと、第１ユーザが病気や怪我をしている状態であると判定する。なお、この判定は、例えばヘルスケア系のアプリで病気や怪我の状態を含むユーザ属性が自装置に記憶されていれば、そのアプリからユーザ属性を取得することで行われてもよい。心身状態判定部１０３は、こうして心身状態を判定した結果を示す情報（気分や体調を表す値やユーザ属性の情報など）を心身状態情報送信部１０４に供給する。
【０１５８】
心身状態情報送信部１０４は、気分情報送信部１０２が第１気分情報を生成したように第１心身状態情報を生成し、生成した第１心身状態情報をサーバ装置３０ｍに送信する。サーバ装置３０ｍの第１心身状態情報取得部３２１は、こうして送信されてきた第１心身状態情報を取得する。心身状態判定部２１０及び心身状態情報送信部２１１は第２ユーザに対して心身状態判定部１０３及び心身状態情報送信部１０４と同様の機能を提供し、これらの機能によりサーバ装置３０ｍに送信されてきた第２心身状態情報を第２心身状態情報取得部３２２が取得する。第１心身状態情報は本発明の「第１情報」の一例であり、第１心身状態情報取得部３２１は本発明の「第１取得部」の一例である。また、第２心身状態情報は本発明の「第２情報」の一例であり、第２心身状態情報取得部３２２は本発明の「第２取得部」の一例である。
【０１５９】
本変形例の処理部３０３は、上述した通知関連処理を、第１心身状態情報取得部３２１により取得された第１心身状態情報と、第２心身状態情報取得部３２２により取得された第２心身状態情報とに応じて行う。本変形例によれば、第１ユーザの心身状態及び第２ユーザの心身状態の両方に応じて両者で話題にしやすい情報を第２ユーザに提供することができる。
【０１６０】
［４−１６］発明のカテゴリ
本発明は、サーバ装置、第１ユーザ端末及び第２ユーザ端末のような情報処理装置の他、それらの装置を備えるコミュニケーション支援システムとして捉えられる。また、本発明は、各装置が実施する処理を実現するための情報処理方法としても捉えられるし、各装置を制御するコンピュータを機能させるためのプログラムとしても捉えられる。このプログラムは、それを記憶させた光ディスク等の記録媒体の形態で提供されてもよいし、インターネット等のネットワークを介してコンピュータにダウンロードさせ、それをインストールして利用可能にするなどの形態で提供されてもよい。
【符号の説明】
【０１６１】
１…コミュニケーション支援システム、２…ネットワーク、１０…第１ユーザ端末、２０…第２ユーザ端末、３０…サーバ装置、１０１、２０１…気分判定部、１０２、２０２…気分情報送信部、１０３、２１０…心身状態判定部、１０４、２１１…心身状態情報送信部、２０３…関連情報取得部、２０４…関連情報出力部、２０５…スケジュール管理部、２０６…体調指標測定部、２０７…体調情報送信部、２０８…頻度情報蓄積部、２０９…頻度情報送信部、３０１…第１気分情報取得部、３０２…第２気分情報取得部、３０３…処理部、３０４…ユーザ固有情報記憶部、３０５…一般情報記憶部、３０６…スケジュール情報取得部、３０８…天気予報取得部、３０９…傾向判断部、３１１、３１７…属性情報取得部、３１３…体調情報取得部、３１６…通知履歴蓄積部、３１８…優先順位判断部、３１９…頻度情報取得部、３２１…第１心身状態情報取得部、３２２…第２心身状態情報取得部、３３１…通知判断部、３３２…関連情報生成部、３３３…関連情報送信部。
【図１】
0006722482.tif 000002
【図２】
0006722482.tif 000003
【図３】
0006722482.tif 000004
【図４】
0006722482.tif 000005
【図５】
0006722482.tif 000006
【図６】
0006722482.tif 000007
【図７】
0006722482.tif 000008
【図８】
0006722482.tif 000009
【図９】
0006722482.tif 000010
【図１０】
0006722482.tif 000011
【図１１】
0006722482.tif 000012
【図１２】
0006722482.tif 000013
【図１３】
0006722482.tif 000014
【図１４】
0006722482.tif 000015
【図１５】
0006722482.tif 000016
【図１６】
0006722482.tif 000017
【図１７】
0006722482.tif 000018
【図１８】
0006722482.tif 000019
【図１９】
0006722482.tif 000020
【図２０】
0006722482.tif 000021
【図２１】
0006722482.tif 000022
【図２２】
0006722482.tif 000023
【図２３】
0006722482.tif 000024
【図２４】
0006722482.tif 000025
【図２５】
0006722482.tif 000026
【図２６】
0006722482.tif 000027
【図２７】
0006722482.tif 000028
【図２８】
0006722482.tif 000029
【図２９】
0006722482.tif 000030
【図３０】
0006722482.tif 000031
【図３１】
0006722482.tif 000032
【図３２】
0006722482.tif 000033
【図３３】
0006722482.tif 000034
【図３４】
0006722482.tif 000035
【図３５】
0006722482.tif 000036
【図３６】
0006722482.tif 000037
【図３７】
0006722482.tif 000038
【図３８】
0006722482.tif 000039