(57)【要約】【課題】所定の期間を超えてコミュニケーションを取っていない相手とのコミュニケーションを取るように、的確なタイミングでリコメンドを行う。【解決手段】通信端末１０は、ユーザ１００とユーザ１００により指定された相手（ユーザ２００）とがネットワークＮＷを介してコミュニケーションを取るための処理（通話等）を行うと、コミュニケーションの履歴を、相手毎に管理する。通信端末１０は、コミュニケーションの履歴に基づいて、閾値期間を超えてコミュニケーションを取っていない相手とのコミュニケーションを取るように、所定の条件を満たしたタイミングで、ユーザ１００に対するリコメンドを行う。かかるタイミングは、例えば、相手の属性に応じたタイミング（例えば、相手が父である場合は父の日）、又は相手に固有のタイミング（例えば、相手の誕生日）である。【選択図】図１
2018101881.tif 000002
【特許請求の範囲】
【請求項１】
ユーザと前記ユーザにより指定された相手とがネットワークを介してコミュニケーションを取るための処理を行うコミュニケーション処理部と、
前記ユーザが取った前記コミュニケーションの履歴を、前記相手毎に管理する履歴管理部と、
前記コミュニケーションの履歴に基づいて、閾値期間を超えて前記コミュニケーションを取っていない前記相手とのコミュニケーションを取るように、所定の条件を満たしたタイミングで、前記ユーザに対するリコメンドを行うリコメンド部と
を備える通信端末。
【請求項２】
前記リコメンド部は、
前記コミュニケーションを取っていない前記相手の属性に応じたタイミング、又は当該相手に固有のタイミングで、前記リコメンドを行う
ことを特徴とする請求項１に記載の通信端末。
【請求項３】
前記リコメンド部は、
前記コミュニケーションの履歴に基づいて、前記閾値期間の長さを変化させる
ことを特徴とする請求項１又は請求項２に記載の通信端末。
【請求項４】
前記リコメンド部は、
イベントと関連付けられた前記相手について、当該イベントが行われる時期に応じたタイミングで、前記リコメンドを行う
ことを特徴とする請求項１から請求項３のいずれか１項に記載の通信端末。
【請求項５】
前記リコメンド部は、
前記ユーザの位置に応じた前記相手とのコミュニケーションを取るように、前記リコメンドを行う
ことを特徴とする請求項１から請求項４のいずれか１項に記載の通信端末。
【請求項６】
前記ユーザの状態を特定する状態特定部を備え、
前記リコメンド部は、
特定された前記ユーザの状態に応じた前記相手とのコミュニケーションを取るように、前記リコメンドを行う
ことを特徴とする請求項１から請求項５のいずれか１項に記載の通信端末。
【請求項７】
前記リコメンド部は、
前記リコメンドを行うタイミングを制限する
ことを特徴とする請求項１から請求項６のいずれか１項に記載の通信端末。
【請求項８】
前記リコメンド部は、
前記リコメンドを行った後の、当該リコメンドをした相手とのコミュニケーションの結果に応じて、前記閾値期間の長さ又は前記条件を変化させる
ことを特徴とする請求項１から請求項７のいずれか１項に記載の通信端末。
【請求項９】
ユーザと前記ユーザにより指定された相手とがネットワークを介してコミュニケーションを取るための処理を行う通信端末のコンピュータに、
前記ユーザが取った前記コミュニケーションの履歴を、前記相手毎に管理するステップと、
前記コミュニケーションの履歴に基づいて、閾値期間を超えて前記コミュニケーションを取っていない前記相手とのコミュニケーションを取るように、所定の条件を満たしたタイミングで、前記ユーザに対するリコメンドを行うステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザに対して特定の相手とコミュニケーションを取るべきことをリコメンドする技術に関する。
【背景技術】
【０００２】
電話、電子メール、ＳＮＳ（Social Networking Service）等の手段を用いて、通信端末のユーザ同士がコミュニケーションを取ることが、盛んに行われている。特許文献１〜３には、コミュニケーションを取るべき相手をユーザに認識させる技術が記載されている。具体的には、特許文献１には、携帯端末装置のメモリに記憶されている通信相手の日付情報（例えば、誕生日）と、現在の日付が一致又はその近い日付になった時に、該当する通信相手に関する情報、及びアイコンを表示することが記載されている。特許文献２には、ユーザの現在位置が「ビジネス」のエリアに属する場合には、「ビジネス」に対応するアドレス情報の表示優先度を高くし、ユーザの現在位置が「プライベート」のエリアに属する場合には、「プライベート」に対応するアドレス情報の表示優先度を高くすることが記載されている。特許文献３には、長期間連絡を取っていない相手を検索し、連絡を取る相手としてリコメンドすることが記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−３２０５６号公報
【特許文献２】特開２００５−１０９８９６号公報
【特許文献３】特開２００３−１８８９７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
最近コミュニケーションを取っていない相手とのコミュニケーションを取るように、ユーザにリコメンドする場合、そのリコメンドのタイミングによっては、ユーザが積極的にコミュニケーションを取ろうとしない場合もある。例えばリコメンドのタイミングが、ユーザにとってコミュニケーションを取る動機が乏しいタイミングであった場合、当該リコメンドが無駄になってしまう可能性がある。
そこで、本発明は、所定の期間を超えてコミュニケーションを取っていない相手とのコミュニケーションを取るように、的確なタイミングでリコメンドを行うことを目的とする。
【課題を解決するための手段】
【０００５】
上述した課題を解決するため、本発明の通信端末は、ユーザと前記ユーザにより指定された相手とがネットワークを介してコミュニケーションを取るための処理を行うコミュニケーション処理部と、前記ユーザが取った前記コミュニケーションの履歴を、前記相手毎に管理する履歴管理部と、前記コミュニケーションの履歴に基づいて、閾値期間を超えて前記コミュニケーションを取っていない前記相手とのコミュニケーションを取るように、所定の条件を満たしたタイミングで、前記ユーザに対するリコメンドを行うリコメンド部とを備える。
【０００６】
本発明の通信端末において、前記リコメンド部は、前記コミュニケーションを取っていない前記相手の属性に応じたタイミング、又は当該相手に固有のタイミングで、前記リコメンドを行ってもよい。
【０００７】
本発明の通信端末において、前記リコメンド部は、前記コミュニケーションの履歴に基づいて、前記閾値期間の長さを変化させてもよい。
【０００８】
本発明の通信端末において、前記リコメンド部は、イベントと関連付けられた前記相手について、当該イベントが行われる時期に応じたタイミングで、前記リコメンドを行ってもよい。
【０００９】
本発明の通信端末において、前記リコメンド部は、前記ユーザの位置に応じた前記相手とのコミュニケーションを取るように、前記リコメンドを行ってもよい。
【００１０】
本発明の通信端末において、前記ユーザの状態を特定する状態特定部を備え、前記リコメンド部は、特定された前記ユーザの状態に応じた前記相手とのコミュニケーションを取るように、前記リコメンドを行ってもよい。
【００１１】
本発明の通信端末において、前記リコメンド部は、前記リコメンドを行うタイミングを制限してもよい。
【００１２】
本発明の通信端末において、前記リコメンド部は、前記リコメンドを行った後の、当該リコメンドをした相手とのコミュニケーションの結果に応じて、前記閾値期間の長さ又は前記条件を変化させてもよい。
【００１３】
本発明のプログラムは、ユーザと前記ユーザにより指定された相手とがネットワークを介してコミュニケーションを取るための処理を行う通信端末のコンピュータに、前記ユーザが取った前記コミュニケーションの履歴を、前記相手毎に管理するステップと、前記コミュニケーションの履歴に基づいて、閾値期間を超えて前記コミュニケーションを取っていない前記相手とのコミュニケーションを取るように、所定の条件を満たしたタイミングで、前記ユーザに対するリコメンドを行うステップとを実行させてもよい。
【発明の効果】
【００１４】
本発明によれば、所定の期間を超えてコミュニケーションを取っていない相手とのコミュニケーションを取るように、的確なタイミングでリコメンドを行うことができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の第１実施形態に係る通信システムの全体構成を示す図。
【図２】同実施形態に係る通信端末の構成の一例を示す図。
【図３】同実施形態に係る履歴管理ＤＢの構成の一例を示す図。
【図４】同実施形態に係る通信端末が、コミュニケーションが取られた際に実行する処理を示すフローチャート。
【図５】同実施形態に係る通信端末が、コミュニケーションを取ることをユーザにリコメンドする際の処理を示すフローチャート。
【図６】同実施形態に係る表示部に表示されるリコメンド画面の一例を示す図。
【図７】本発明の第２実施形態に係る通信端末の構成の一例を示す図。
【図８】同実施形態に係る履歴管理ＤＢの構成の一例を示す図。
【図９】同実施形態に係る処理例１のリコメンドに係る処理を示すフローチャート。
【図１０】同実施形態に係る処理例１のリコメンド画面の一例を示す図。
【図１１】同実施形態に係る処理例２のリコメンドに係る処理を示すフローチャート。
【図１２】同実施形態に係る処理例２のリコメンド画面の一例を示す図。
【図１３】同実施形態に係る処理例３のリコメンドに係る処理を示すフローチャート。
【図１４】同実施形態に係る処理例３のリコメンド画面の一例を示す図。
【発明を実施するための形態】
【００１６】
以下、図面を参照して本発明の実施形態を説明する。
［第１実施形態］
図１は、本発明の第１実施形態に係る通信システム１の全体構成を示す図である。通信システム１は、通信端末１０と、複数の通信端末２０（２０−１，２０−２，２０−３，２０−４）と、ＳＮＳサーバ３０とを備える。通信端末１０は、本発明の通信端末に相当する。通信端末１０は、ユーザ１００により使用される。通信端末２０は、ユーザ２００により使用される。図１では、通信端末２０−ｉ（ただし、１≦ｉ≦４）を使用するユーザ２００を、「ユーザ２００−ｉ」と示す。
【００１７】
ユーザ１００は、いずれかのユーザ２００を相手として、コミュニケーションを取る。このコミュニケーションは、ユーザ１００が通信端末１０を、ユーザ２００が通信端末２０を使用することで、取ることができる。また、このコミュニケーションは、ネットワークＮＷを介して、取ることができる。ネットワークＮＷは、移動通信網、ゲートウェイ等を含む通信回線である。通信端末１０は、当該コミュニケーションを取るための処理（後述するコミュニケーション処理）を行う。
【００１８】
なお、本実施形態では、通信端末１０、及び通信端末２０は、それぞれ携帯型の通信端末で、より詳細にはスマートフォンである。ただし、通信端末１０、及び通信端末２０は、スマートフォン以外の携帯型の通信端末（例えば、フィーチャーフォン、通信機能を有するウェアラブル端末）、又は携帯型でない通信端末（例えば、通信機能を有する各種コンピュータ装置）であってもよい。また、図１には、通信端末２０として４台が示されているが、実際には多数存在し得る。通信端末２０は、前述したコミュニケーションを取るために利用できる通信端末であればよいからである。
【００１９】
ＳＮＳサーバ３０は、ユーザ１００とユーザ２００とが、ＳＮＳを利用してコミュニケーションを取るためのサービスを提供するサーバ装置である。ＳＮＳサーバ３０は、通信端末１０、又は通信端末２０から投稿された情報（以下「投稿情報」）を蓄積し、ネットワークＮＷを介してこれを公開する。投稿情報は、例えば日記又はメッセージ等で、ユーザ１００、又はユーザ２００により作成される。投稿情報は、文字（文章）、記号、絵文字、画像等の要素を含み得る。
【００２０】
図２は、通信端末１０の構成の一例を示す図である。通信端末１０は、物理的には、プロセッサ１１、メモリ１２、ストレージ１３、通信装置１４、入力装置１５、及び出力装置１６等を含むコンピュータ装置として構成される。プロセッサ１１は、バスを介してメモリ１２、ストレージ１３、通信装置１４、入力装置１５、及び出力装置１６の各々と接続されている。
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニット等に読み替えることができる。通信端末１０のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【００２１】
プロセッサ１１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタ等を含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。
また、プロセッサ１１は、プログラム（プログラムコード）、ソフトウェアモジュールやデータを、ストレージ１３及び／又は通信装置１４からメモリ１２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。各種処理は、１つのプロセッサ１１で実行される旨を説明してきたが、２以上のプロセッサ１１により同時又は逐次に実行されてもよい。プロセッサ１１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介して受信されてもよい。
【００２２】
メモリ１２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＲＡＭ（Random Access Memory）等の少なくとも１つで構成されてもよい。メモリ１２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）等と呼ばれてもよい。
【００２３】
ストレージ１３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Compact Disc ＲＯＭ）等の光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップ等の少なくとも１つで構成されてもよい。ストレージ１３は、補助記憶装置と呼ばれてもよい。
【００２４】
通信装置１４は、無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信装置１４は、通話のための通信を行う。
【００２５】
入力装置１５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサ類）である。出力装置１６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカ、ＬＥＤランプ等）である。出力装置１６は、表示部１６１を含む。表示部１６１は、表示面に画像を表示する。表示部１６１は、例えば液晶ディスプレイであるが、これ以外の表示部であってもよい。
【００２６】
また、通信端末１０は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１１は、これらのハードウェアの少なくとも１つで実装されてもよい。
通信端末１０における各機能は、プロセッサ１１、メモリ１２等のハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１１が演算を行い、通信装置１４による通信や、メモリ１２及びストレージ１３におけるデータの読み出し及び／又は書き込みを制御することで実現される。
【００２７】
次に、通信端末１０のプロセッサ１１の機能構成を説明する。プロセッサ１１は、コミュニケーション処理部１１１、履歴管理部１１２、及びリコメンド部１１３を含む。
コミュニケーション処理部１１１は、ユーザ１００とユーザ２００とが、ネットワークＮＷを利用してコミュニケーションを取るためのコミュニケーション処理を行う。コミュニケーション処理は、ユーザ１００とユーザ２００との間で、意思、感情、又は思考等の情報を伝達するための処理であって、ネットワークＮＷを介して行われる処理である。コミュニケーション処理は、本実施形態では、通話によりコミュニケーションを取るための処理である。この場合のコミュニケーション処理は、ネットワークＮＷとの間に通信路を確立する処理、及び通話に係る音声データを送受信する処理等を含む。本実施形態のコミュニケーション処理は、通信端末１０の発信が契機となって行われるコミュニケーション処理であるものとする。ただし、コミュニケーション処理は、相手方である通信端末２０の発信、換言すると通信端末１０の着信が契機となって行われるコミュニケーション処理に置き換えられてもよい。又は、本実施形態のコミュニケーション処理は、これら両方のコミュニケーション処理を含んでいてもよい。
【００２８】
履歴管理部１１２は、ユーザ１００が取ったコミュニケーションの履歴を、その相手毎（つまり、ユーザ２００毎）に管理する。履歴管理部１１２は、ユーザ１００といずれかのユーザ２００とがコミュニケーションを取るたびに、そのユーザ２００に関するコミュニケーションの履歴を更新する。コミュニケーションの履歴は、ストレージ１３に記憶されている履歴管理ＤＢ（Data Base）１３１に記録される。
【００２９】
図３は、履歴管理ＤＢ１３１の構成の一例を示す図である。履歴管理ＤＢ１３１は、コミュニケーションの相手毎に、コミュニケーション手段と、日時とを対応付けて記録したデータベースである。コミュニケーションの相手は、図３には、相手の名称を用いて記されている。しかし、当該相手を一意に特定できる情報であれば、他の情報（例えば、電話番号）であってもよい。コミュニケーション手段は、コミュニケーションを取るのに用いられた手段で、本実施形態では「通話」である。日時は、コミュニケーションが取られた日時を示す。この日時は、例えば通話の開始日時又は終了日時であるが、これら以外の日時であってもよい。図３の履歴管理ＤＢ１３１には、例えば、「父」（ユーザ１００の父であるユーザ２００−１）、「Ａ」（友人であるユーザ２００−２）、「Ｂ」（友人であるユーザ２００−３）、「Ｃ」（友人であるユーザ２００−４）に関するコミュニケーションの履歴が記録されている。
なお、履歴管理ＤＢ１３１は、携帯端末等が一般的に記憶する通話履歴を記録したデータで代用されてもよい。通話履歴には、通常、通話の相手毎に通話が行われた日時が含まれるからである。
【００３０】
図２に戻り、リコメンド部１１３は、履歴管理部１１２により管理されるコミュニケーションの履歴に基づいて、閾値期間を超えてコミュニケーションを取っていない相手とのコミュニケーションを取るように、ユーザ１００に対するリコメンドを行う。また、リコメンド部１１３は、当該相手を特定した場合に、所定の条件を満たしたタイミング（以下「リコメンドタイミング」という。）で、リコメンドを行う。即ち、閾値期間を超えてコミュニケーションを取っていない相手が特定されるタイミングと、リコメンドタイミングとは、一致するとは限らず、異なる場合がある。リコメンド部１１３は、本実施形態では、表示部１６１への画面（以下「リコメンド画面」という。）の表示により、このリコメンドを行う。リコメンドの方法は、コミュニケーションを取るべき相手をユーザ１００が認識できる方法であれば、表示以外の方法（例えば、音声出力）であってもよい。
【００３１】
＜Ａ：コミュニケーションが取られた際の処理＞
図４は、通信端末１０が、コミュニケーションが取られた際に実行する処理を示すフローチャートである。例えば、ユーザ１００が、通信端末１０を用いて通話をした際に、図４の処理が実行される。
【００３２】
コミュニケーション処理部１１１は、ユーザ１００のコミュニケーションの相手を指定して、コミュニケーション処理を行う（ステップＳ１）。コミュニケーション処理部１１１は、例えば、入力装置１５を用いて入力を受け付けた操作に応じて、当該相手を指定する。この操作は、例えば、電話帳データから通話の相手を選択する操作、又は電話番号を入力する操作がある。コミュニケーション処理が完了すると、履歴管理部１１２は、履歴管理ＤＢ１３１に記録されているコミュニケーション履歴を更新する（ステップＳ２）。具体的には、履歴管理部１１２は、ステップＳ１のコミュニケーション処理が実行された日時を、そのコミュニケーションの相手、及びコミュニケーション手段と対応付けて、履歴管理ＤＢ１３１に記録する。これにより、図３に示す履歴管理ＤＢ１３１が構成される。
【００３３】
＜Ｂ：リコメンドに係る処理＞
図５は、通信端末１０が、コミュニケーションを取ることをユーザ１００にリコメンドする際の処理を示すフローチャートである。通信端末１０は、図５に示す処理を、例えば所定の周期で、繰り返し実行する。
履歴管理部１１２は、履歴管理ＤＢ１３１に記録されているコミュニケーション履歴を取得する（ステップＳ１１）。履歴管理部１１２は、ここでは、図３に示す履歴管理ＤＢ１３１に示すコミュニケーション履歴を取得するものとする。
【００３４】
次に、リコメンド部１１３は、コミュニケーション履歴に基づいて、リコメンドする相手を特定する（ステップＳ１２）。リコメンド部１１３は、現在の日時と、コミュニケーション履歴が示す日時とを比較する。そして、リコメンド部１１３は、閾値期間を超えてコミュニケーション処理が行われていない相手を特定する。閾値期間は、例えば予め決められた固定期間で、ここでは６ヶ月であるものとする。
【００３５】
次に、リコメンド部１１３は、ステップＳ１２でリコメンドする相手を１以上特定したかどうかを判断する（ステップＳ１３）。リコメンドする相手を１つも特定しなかったと判断した場合（ステップＳ１３；ＮＯ）、リコメンド部１１３は図５の処理を終了させる。最近コミュニケーションを取っていない相手がおらず、コミュニケーションを取るようにリコメンドすべき相手が存在しないからである。
【００３６】
ステップＳ１３で「ＹＥＳ」と判断した場合、リコメンド部１１３は、ステップＳ１４の処理に進む。ここでは、「父」であるユーザ２００−１との最後のコミュニケーションが「２０１５／６／２１／１９：００」であり、既に６ヶ月以上が経過しているものとする。
【００３７】
次に、リコメンド部１１３は、ステップＳ１２で特定した相手について、リコメンドタイミングであるかどうかを判断する（ステップＳ１４）。リコメンドタイミングは、例えば、相手の属性に応じて決まる。相手が父である場合、父の日（６月の第３日曜日）に応じたリコメンドタイミングとなる。例えば、父の日の前日の１２：００がリコメンドタイミングとなる。
なお、相手の属性は、例えば、ストレージ１３に記憶された電話帳データに登録された情報に基づいて特定されるが、これ以外の方法で特定されてもよい。
【００３８】
現在日時が「２０１６／６／１８／１２：００」（つまり、父の日の前日の１２：００よりも前）よりも前である場合には、リコメンド部１１３はステップＳ１４で「ＮＯ」と判断する。この場合、リコメンド部１１３は、リコメンドを行わずに、待機する（ステップＳ１５）。
【００３９】
リコメンド部１１３は、ステップＳ１４で「ＹＥＳ」と判断した場合、ステップＳ１６の処理に進める。具体的には、リコメンド部１１３は、現在日時が「２０１６／６／１８／１２：００」以降になった場合に、ステップＳ１４で「ＹＥＳ」と判断する。そして、リコメンド部１１３は、ステップＳ１２で特定した相手とコミュニケーションを取るように、ユーザ１００に対するリコメンドを行う（ステップＳ１６）。
【００４０】
図６は、ステップＳ１６で表示されるリコメンド画面の一例を示す図である。図６に示すリコメンド画面には、「最近、『父』さんと連絡を取っていないようです。本日は、父の日ですから、電話を掛けてみませんか？」というメッセージが含まれる。ここにおいて、『父』は、ユーザ２００−１の名称であって、履歴管理ＤＢ１３１に記録された相手の名称と一致する。このように、リコメンド画面には、コミュニケーションを取るべき相手を特定する情報が含まれる。更に、リコメンド画面には、「電話を掛ける」という文字列が付されたボタンＢ１と、「キャンセル」という文字列が付されたボタンＢ２とが配置されている。ユーザ１００は、リコメンドされた相手であるユーザ２００−１に電話を掛ける場合、ボタンＢ１を操作する操作を行う。この操作が行われると、コミュニケーション処理部１１１は、通信端末２０−１に電話を掛けて通話するためのコミュニケーション処理を行う。一方、ユーザ１００は、電話を掛けなくてよいと判断した場合、ボタンＢ２を操作する操作を行う。この操作が行われると、コミュニケーション処理部１１１は、コミュニケーション処理を行わずに、図５の処理を終了させる。
【００４１】
ステップＳ１２で別の相手が特定された場合も、同様の処理が行われる。図３には示していないが、相手がユーザ１００の母である場合は、リコメンド部１１３は、母の日（５月の第２日曜日）に応じたリコメンドタイミングで、リコメンドを行う。即ち、リコメンド部１１３は、「母」とのコミュニケーションが閾値期間を超えて取られていない場合には、母の日に応じたリコメンドタイミング（例えば、母の日の前日の１２：００）で、ステップＳ１６のリコメンドを行う。
【００４２】
リコメンドタイミングは、相手の属性ではなく、その相手に固有のタイミングであってもよい。例えば、相手が友人であるユーザ２００−２，２００−３，２００−４である場合は、リコメンド部１１３は、その相手の誕生日をリコメンドタイミングとする。即ち、リコメンド部１１３は、友人とのコミュニケーションが閾値期間を超えて取られていない場合には、その友人の誕生日に応じたリコメンドタイミング（例えば、誕生日の当日の１２：００）で、ステップＳ１６のリコメンドを行う。
【００４３】
このように、リコメンドタイミングは、相手にとって特別な意味のあるタイミングとすることが望ましい。かかるタイミングは、ユーザ１００にとって、最近コミュニケーションを取っていない相手と積極的にコミュニケーションを取りやすいタイミングとなりやすいからである。
なお、相手の属性に応じたリコメンドタイミング、又は相手に固有のリコメンドタイミングは、通信端末１０の設計又は製造段階で決められてもよいし、ユーザ１００により指定されてもよい。
【００４４】
以上のように、通信端末１０は、コミュニケーションを取っていない期間が閾値期間を超えると直ちにリコメンドを行うとは限らず、その相手に応じたリコメンドタイミングで、リコメンドを行う。これにより、ユーザ１００は、しばらくコミュニケーションを取っていない相手であっても、積極的にコミュニケーションを取りやすくなる。
【００４５】
リコメンド部１１３は、ステップＳ１２において、可変期間である閾値期間を超えてコミュニケーションを取っていない相手を特定してもよい。リコメンド部１１３は、例えば、閾値期間の長さを、相手毎のコミュニケーション履歴に応じて変化させる。例えば、ユーザ１００が半年に１回しか電話を掛けないような相手と、毎日電話を掛けるような相手とでは、ユーザ１００にとって“しばらく連絡していない”と感じる期間の長さは異なると考えられる。そこで、リコメンド部１１３は、相手毎のコミュニケーションが取られている頻度に応じて、その相手に対する閾値期間を決定する。具体的には、リコメンド部１１３は、過去のコミュケーションが取られた頻度が高い相手ほど当該閾値期間を短く、反対に、その頻度が低い相手ほど当該閾値期間を長くする。
これにより、通信端末１０は、相手毎に的確なリコメンドタイミングで、ステップＳ１６のリコメンドを行うことができる。
【００４６】
［第２実施形態］
次に、本発明の第２実施形態を説明する。
本実施形態の通信端末は、通話以外のコミュニケーション手段を用いて、コミュニケーションを取るようリコメンドする相手を特定し、またリコメンドタイミングを決定する点で、上述した第１実施形態と相違する。本実施形態では、上述した第１実施形態と同じ符号を付した要素は、上述した第１実施形態と同等に機能する。また、上述した第１実施形態の要素と対応する要素については、符号の末尾に「Ａ」を付して表す。
【００４７】
図７は、通信端末１０Ａの構成の一例を示す図である。通信端末１０Ａの入力装置１５Ａは、測位部１５１を備える。測位部１５１は、通信端末１０の位置を測定し、測定した位置を示す位置情報を生成する。測位部１５１は、例えば、ＧＰＳ（Global Positioning System）方式に従って位置情報を生成する。この場合、位置情報は、緯度、及び経度の情報を含む。通信端末１０Ａのその余の物理的な構成は、上述した第１実施形態と同じであるものとする。
【００４８】
通信端末１０Ａのプロセッサ１１Ａの機能構成を説明する。プロセッサ１１Ａは、コミュニケーション処理部１１１Ａと、履歴管理部１１２Ａと、リコメンド部１１３Ａと、位置特定部１１４と、状態特定部１１５とを有する。
位置特定部１１４は、ユーザ１００の位置を特定する。本実施形態では、位置特定部１１４は、測位部１５１から供給された位置情報が示す通信端末１０Ａの位置を、ユーザ１００の位置として特定する。
【００４９】
状態特定部１１５は、ユーザ１００の状態を特定する。ユーザ１００の状態は、例えば、健康の状態（例えば、風邪を引いたこと）、生活の状態（例えば、大学に入学したこと等の生活の状態の変化）である。状態特定部１１５は、例えば、ストレージ１３に記憶された電子メール（送信済みメール、又は受信済みメール）、又はＳＮＳサーバ３０に投稿した投稿情報に基づいて、ユーザ１００の状態を特定する。電子メール又は投稿情報には、ユーザ１００の現在又は過去の状況等、ユーザ１００の状況を把握するための情報が含まれることがあるからである。ただし、ユーザ１００の状態を特定する方法は、これに限られず、更に別の方法（例えば、ユーザ１００のスケジュールを示すスケジュールデータの参照）であってもよい。
【００５０】
コミュニケーション処理部１１１Ａは、コミュニケーション処理を行う。コミュニケーション処理は、本実施形態では、通話以外にも、電子メール及びＳＮＳ等の、様々なコミュニケーション手段に関する処理を含む。電子メールに係るコミュニケーション処理は、例えば、当該電子メールの作成、及び送受信等の処理を含む。ＳＮＳに係るコミュニケーション処理は、投稿情報の作成、及びネットワークＮＷ上で投稿情報を公開するためのＳＮＳサーバ３０への投稿等の処理を含む。本実施形態のコミュニケーション処理も、通信端末１０の発信が契機となって行われるコミュニケーション処理、及び相手方である通信端末２０の発信、換言すると通信端末１０の着信が契機となって行われるコミュニケーション処理の一方、又は両方を含む。電子メールに係るコミュニケーション処理の場合、電子メールの送信先に限られず、電子メールの送信元が、コミュニケーション処理の相手となる場合がある。
【００５１】
履歴管理部１１２Ａは、ユーザ１００が取ったコミュニケーションの履歴を、その相手毎に管理する。履歴管理部１１２Ａは、電子メールについては、その電子メールの送信先を、コミュニケーションを取った相手として特定する。履歴管理部１１２Ａは、ＳＮＳについては、ユーザ１００が作成した投稿情報の宛先となった相手、その投稿情報を閲覧した相手、又はその投稿情報に対して応答（例えば、返信）をした相手を、コミュニケーションを取った相手として特定する。履歴管理部１１２Ａは、ユーザ１００といずれかのユーザ２００とがコミュニケーションを取るたびに、そのユーザ２００に関するコミュニケーションの履歴を更新する。コミュニケーションの履歴は、ストレージ１３に記録された履歴管理ＤＢ１３１Ａに記録される。
【００５２】
図８は、履歴管理ＤＢ１３１Ａの構成の一例を示す図である。履歴管理ＤＢ１３１Ａは、コミュニケーションの相手毎に、コミュニケーション手段と、日時とを対応付けて記録したデータベースである。コミュニケーションの相手、コミュニケーション手段、及び日時の各情報は、上述した第１実施形態で説明したとおりである。ただし、コミュニケーション手段として、電子メール、及びＳＮＳ等の、通話以外の手段が用いられることがある点で、上述した第１実施形態とは相違する。
【００５３】
図７に戻り、リコメンド部１１３Ａは、履歴管理部１１２Ａにより管理されるコミュニケーションの履歴に基づいて、閾値期間を超えてコミュニケーションを取っていない相手とのコミュニケーションを取るように、ユーザ１００に対するリコメンドを行う。また、リコメンド部１１３Ａは、閾値期間を超えてコミュニケーションを取っていない相手を特定した場合に、所定の条件を満たしたタイミングで、リコメンドを行う。更に、リコメンド部１１３Ａは、位置特定部１１４が特定した位置、又は状態特定部１１５が特定したユーザ１００の状態に応じて、リコメンドする相手、又はリコメンドのタイミングを判断することがある。
【００５４】
＜Ａ：コミュニケーションが取られた際の処理＞
通信端末１０Ａが、コミュニケーションが取られた際に実行する処理は、上述した第１実施形態と大略同じである。コミュニケーション処理部１１１Ａは、ステップＳ１では、ユーザ１００と、ユーザ２００とがコミュニケーションを取るためのコミュニケーション処理を行う。そのコミュニケーション処理が完了すると、履歴管理部１１２Ａは、ステップＳ２で、履歴管理ＤＢ１３１Ａに記録されているコミュニケーション履歴を更新する。具体的には、履歴管理部１１２Ａは、ステップＳ１のコミュニケーション処理が実行された日時と、コミュニケーションの相手とを対応付けて、履歴管理ＤＢ１３１Ａに記録する。これにより、図８に示す履歴管理ＤＢ１３１Ａが構成される。
【００５５】
＜Ｂ：リコメンドに係る処理＞
本実施形態のリコメンドに係る処理として、以下の（処理例１）、（処理例２）、及び（処理例３）を説明する。
【００５６】
（処理例１）
処理例１では、イベントと関連付けられた相手と閾値期間を超えてコミュニケーションが取られていない場合に、当該イベントが行われる時期に応じたタイミングで、リコメンドを行う。イベントは、例えばオリンピック又はコンサート等の催し物である。
【００５７】
図９は、処理例１のリコメンドに係る処理を示すフローチャートである。通信端末１０Ａは、図９に示す処理を、例えば所定の周期で、繰り返し実行する。
履歴管理部１１２Ａは、履歴管理ＤＢ１３１Ａに記録されているコミュニケーション履歴を取得する（ステップＳ２１）。ステップＳ２１では、ここでは、図８に示す履歴管理ＤＢ１３１Ａに応じたコミュニケーション履歴が取得されるものとする。
【００５８】
次に、リコメンド部１１３Ａは、コミュニケーション履歴、及びイベントに応じたリコメンドする相手を特定する（ステップＳ２２）。リコメンド部１１３Ａは、閾値期間を超えてコミュニケーション処理を実行していない相手のうち、イベントと関連付けられた相手を特定する。イベントと関連付けられた相手は、例えば、過去にユーザ１００と一緒にそのイベントに参加したユーザ２００である。イベントと関連付けられる相手については、例えば、電子メール又は投稿情報に基づいて特定される。また、閾値期間は、ここでは可変期間であり、具体的にはイベントに応じて決まるものとする。周期的に開催されるイベントの場合、そのイベントの開催時期に応じて閾値期間が決まる。例えば１年に１回のコンサート又はユーザ１００の誕生日の場合は、閾値期間を９ヶ月、４年に１回に開催されるオリンピックの場合は、閾値期間を３年６ヶ月とする、という具合である。このように、リコメンド部１１３Ａは、イベントの開催周期が長い場合ほど閾値期間を長くし、イベントの開催周期が短い場合ほど閾値期間を短くする。
【００５９】
次に、リコメンド部１１３Ａは、ステップＳ２２でリコメンドする相手を１以上特定したかどうかを判断する（ステップＳ２３）。リコメンドする相手を１つも特定しなかったと判断した場合（ステップＳ２３；ＮＯ）、リコメンド部１１３Ａは図９の処理を終了させる。
【００６０】
ステップＳ２３で「ＹＥＳ」と判断した場合、リコメンド部１１３Ａは、ステップＳ２４の処理に進む。ここでは、ステップＳ２２において、ユーザ１００と前回のオリンピックに一緒に行った「Ａ」であるユーザ２００−２が特定されたとする。ユーザ２００−２と最後に取られたコミュニケーションは、「２０１２／７／３１／１７：００」で、既に３年６ヶ月以上が経過している。
【００６１】
次に、リコメンド部１１３Ａは、ステップＳ２２で特定した相手について、リコメンドタイミングであるかどうかを判断する（ステップＳ２４）。このリコメンドタイミングは、イベント、例えばイベントの開催時期に応じて決められているものとする。イベントが「オリンピック」である場合、その開催時期（例えば初日）から６ヶ月前がリコメンドタイミングに決められているものとする。オリンピックの開催時期を「２０１６／８／１〜」とした場合、現在の日時が「２０１６／２／１」よりも前である場合には、リコメンド部１１３ＡはステップＳ２４で「ＮＯ」と判断する。この場合、リコメンド部１１３Ａは、リコメンドを行わずに、待機する（ステップＳ２５）。
【００６２】
リコメンド部１１３Ａは、ステップＳ２４で「ＹＥＳ」と判断した場合、ステップＳ２６の処理に進める。具体的には、リコメンド部１１３Ａは、現在日時が「２０１６／２／１」以降になった場合に、ステップＳ２４で「ＹＥＳ」と判断する。そして、リコメンド部１１３Ａは、ステップＳ２２で特定した相手とコミュニケーションを取るように、ユーザ１００に対するリコメンドを行う（ステップＳ２６）。
【００６３】
図１０は、リコメンド画面の一例を示す図である。図１０に示すリコメンド画面には、「４年前のオリンピックに行った、『Ａ』さんと最近連絡を取っていないようです。次回オリンピックが迫っています。『Ａ』さんに電話を掛けてみませんか？」というメッセージが含まれる。更に、リコメンド画面には、「電話を掛ける」という文字列が付されたボタンＢ３と、「キャンセル」という文字列が付されたボタンＢ４とが配置されている。ユーザ１００は、リコメンドの相手であるユーザ２００−２に電話を掛ける場合、ボタンＢ３を操作する操作を行う。この操作が行われると、コミュニケーション処理部１１１は当該操作により指定した相手に電話を掛け、通話するためのコミュニケーション処理を行う。一方、ユーザ１００は、電話を掛けなくてよいと判断した場合、ボタンＢ４を操作する操作を行う。この操作が行われると、コミュニケーション処理部１１１は、コミュニケーション処理を実行せずに、図９の処理を終了させる。
【００６４】
このように、通信端末１０Ａは、相手に関連付けられたイベントに応じたリコメンドタイミングで、リコメンドを行う。これにより、ユーザ１００は、しばらくコミュニケーションを取っていない相手であっても、所定のイベントが開催されることを動機として、その相手とコミュニケーションを取ることができる。例えば、ユーザ１００にとっては、前回のオリンピックに一緒に行った相手と、再びオリンピックに一緒に行こうと考える場合もある。このように、特定のイベントに特定の人と一緒に行き、それ以外の時期にはあまりコミュニケーションを取らないような場合に、処理例１のリコメンドは有用である。
【００６５】
以上、イベントが「オリンピック」である場合について説明したが、他のイベントの場合も同様の処理が行われる。例えばイベントが１年に１回のコンサート、又は誕生日である場合は、リコメンド部１１３Ａは、次回のコンサートの開催時期、又は誕生日に応じたリコメンドタイミングで、リコメンドを行う。
【００６６】
（処理例２）
処理例２では、場所と関連付けられた相手と閾値期間を超えてコミュニケーションが取られていない場合に、当該場所をユーザ１００が訪れたタイミングで、リコメンドを行う。本実施形態の場所は、例えばユーザ１００の旅行先であるが、出張先でもよく、ユーザ１００が訪れる理由は特に問わない。
【００６７】
図１１は、処理例１のリコメンドに係る処理を示すフローチャートである。通信端末１０Ａは、図１１に示す処理を、例えば所定の周期で、繰り返し実行する。
履歴管理部１１２Ａは、履歴管理ＤＢ１３１Ａに記録されているコミュニケーション履歴を取得する（ステップＳ３１）。次に、位置特定部１１４は、測位部１５１から供給された位置情報に基づいて、ユーザ１００の位置を特定する（ステップＳ３２）。次に、リコメンド部１１３Ａは、コミュニケーション履歴、及びユーザ１００の位置に応じてリコメンドする相手を特定する（ステップＳ３３）。具体的には、リコメンド部１１３Ａは、閾値期間を超えてコミュニケーション処理を実行していない相手のうち、ステップＳ３２で特定した位置と関連付けられた相手を特定する。位置（場所）に応じた相手は、例えば、過去に一緒にその場所を訪れた相手、又はその場所に住む相手（つまり、現地の人）である。当該相手については、例えば、電子メール又は投稿情報に基づいて特定される。当該閾値期間は、ここでは固定期間である。
【００６８】
次に、リコメンド部１１３Ａは、ステップＳ３３でリコメンドする相手を１以上特定したかどうかを判断する（ステップＳ３４）。リコメンドする相手を１つも特定しなかったと判断した場合（ステップＳ３４；ＮＯ）、リコメンド部１１３Ａは、図１１の処理を終了させる。
【００６９】
ステップＳ３４で「ＹＥＳ」と判断した場合、リコメンド部１１３Ａは、ステップＳ３３で特定した相手とコミュニケーションを取るように、ユーザ１００に対するリコメンドを行う（ステップＳ３５）。即ち、リコメンド部１１３Ａは、所定の場所をユーザ１００が訪れたことを条件に、リコメンドを行うことになる。
【００７０】
図１２は、リコメンド画面の一例を示す図である。図１２に示すリコメンド画面には、「以前にこの場所を一緒に訪れた、『Ｂ』さんと最近連絡を取っていないようです。『Ｂ』さんに電話を掛けてみませんか？」というメッセージが含まれる。即ち、コミュニケーションを取ることを促す相手の情報が、このメッセージに含まれる。更に、リコメンド画面には、「電話を掛ける」という文字列が付されたボタンＢ５と、「キャンセル」という文字列が付されたボタンＢ６とが配置されている。ボタンＢ５、及びボタンＢ６に関する通信端末１０の動作は、処理例１と同じでよい。
これにより、ユーザ１００は、所定の場所を訪れたときに、その場所に応じた相手と、コミュニケーションを取りやすくなる。
【００７１】
本処理例２を以下のように変形してもよい。
位置特定部１１４は、測位部１５１から供給された位置情報に基づいて、コミュニケーション処理が行われた位置を特定する。そして、履歴管理部１１２Ａは、コミュニケーション履歴として、コミュニケーション手段、及び日時に加え、当該コミュニケーション処理が行われた位置を示す位置情報を、履歴管理ＤＢ１３１Ａに記録する。ステップＳ３３において、リコメンド部１１３Ａは、ステップＳ３２で特定した位置をユーザ１００が過去に訪れた際にコミュニケーションを取った相手を、履歴管理ＤＢ１３１Ａに基づいて特定する。そして、リコメンド部１１３Ａは、特定した当該相手とコミュニケーションを取るようにリコメンドを行う。この場合も、ユーザ１００は、所定の場所を訪れたときに、その場所に応じた相手と、コミュニケーションを取りやすくなる。
【００７２】
本処理例２を更に以下のように変形してもよい。
リコメンド部１１３Ａは、スケジュールデータ、電子メール、又は投稿情報に基づいてユーザ１００が訪れる場所を予測し、その予測した場所に応じた相手とコミュニケーションを取るようにリコメンドを行ってもよい。即ち、実際にユーザ１００が訪れた場所でなく、ユーザ１００が訪れると予測した場所に応じた相手が、リコメンドの対象となる。この場合も、ユーザ１００は、所定の場所を訪れたときに、その場所に応じた相手と、コミュニケーションを取りやすくなる。この場合、位置特定部１１４が特定した位置を用いなくとも、リコメンド部１１３Ａはコミュニケーションを取るべき相手を特定できる。
【００７３】
（処理例３）
処理例３では、ユーザ１００の状態に応じた相手と閾値期間を超えてコミュニケーションが取られていない場合に、リコメンドを行う。
図１３は、処理例３のリコメンドに係る処理を示すフローチャートである。通信端末１０Ａは、図１３に示す処理を、例えば所定の周期で、繰り返し実行する。
履歴管理部１１２Ａは、履歴管理ＤＢ１３１Ａに記録されているコミュニケーション履歴を取得する（ステップＳ４１）。次に、状態特定部１１５は、ユーザ１００の状態を特定する（ステップＳ４２）。状態特定部１１５は、ここでは、ユーザ１００の健康の状態を特定するものとする。ユーザ１００の状態については、例えば、電子メール又は投稿情報に基づいて特定される。
【００７４】
次に、リコメンド部１１３Ａは、コミュニケーション履歴、及びユーザ１００の状態に応じて、リコメンドする相手を特定する（ステップＳ４３）。ここでは、リコメンド部１１３Ａは、閾値期間を超えてコミュニケーション処理を実行していない相手のうち、ユーザ１００の状態に応じた相手を特定する。特定される相手は、ここでは、ユーザ１００と同じ、又は関連する状態にある相手、例えば同じ病気をしたことのある相手である。当該閾値期間は、固定期間であるものとする。ユーザ１００の状態と関連付けられる相手については、例えば、電子メール又は投稿情報に基づいて特定される。
【００７５】
次に、リコメンド部１１３Ａは、ステップＳ４３でリコメンドする相手を１以上特定したかどうかを判断する（ステップＳ４４）。リコメンドする相手を１つも特定しなかったと判断した場合（ステップＳ４４；ＮＯ）、リコメンド部１１３Ａは図１３の処理を終了させる。
【００７６】
ステップＳ４４で「ＹＥＳ」と判断した場合、リコメンド部１１３Ａは、ステップＳ４３で特定した相手とコミュニケーションを取るように、ユーザ１００に対するリコメンドを行う（ステップＳ４５）。即ち、リコメンド部１１３Ａは、ユーザ１００が所定の状態になったことを条件に、リコメンドを行うことになる。これにより、ユーザ１００は、自身の病気に関して的確なアドバイスを受けられる相手を受けやすくなる。
なお、ユーザ１００の状態が健康の状態以外の場合も、同様の処理が行われる。例えば、ユーザ１００が大学に入学したのであれば、同じ大学に入学した相手（例えば、先輩、又は同級生）が、ステップＳ４３で特定される。このように、ユーザ１００の状態と同じ状態、又は関連する状態になったユーザ２００が、リコメンドの相手となり得る。
【００７７】
図１４は、リコメンド画面の一例を示す図である。図１４に示すリコメンド画面には、「同じ病気をした『Ｃ』さんと最近連絡を取っていないようです。『Ｃ』さんに電話を掛けてみませんか？」というメッセージが含まれる。即ち、コミュニケーションを取ることを促す相手の情報が、このメッセージに含まれる。更に、リコメンド画面には、「電話を掛ける」という文字列が付されたボタンＢ７と、「キャンセル」という文字列が付されたボタンＢ８とが配置されている。ボタンＢ７、及びボタンＢ８に関する通信端末１０の動作は、処理例１と同じでよい。
これにより、ユーザ１００は、現在の状態に応じた相手とコミュニケーションを取りやすくなる。
【００７８】
［変形例］
本発明は、上述した実施形態と異なる形態で実施してもよい。また、以下に示す変形例は、各々を組み合わせてもよい。
（変形例１）
リコメンド部１１３は、リコメンドを行うタイミング、即ちリコメンドタイミングとなる時間的条件を制限してもよい。例えば、リコメンド部１１３が電話を掛けるようにリコメンドを行うのであれば、ユーザ１００が電話できるか、又は相手（ユーザ２００）が電話に出やすい時刻を、リコメンドタイミングとすることが望ましい。そこで、リコメンド部１１３は、例えば、休日又は平日の夜等の予め決められた時刻（時間帯）をリコメンドタイミングとし、深夜等の他の時刻（時間帯）をリコメンドタイミングとしない。また、リコメンド部１１３は、過去のコミュケーション履歴、又はスケジューラを参照して、ユーザ１００又は相手にとって望ましいリコメンドタイミングを決定してもよい。
【００７９】
（変形例２）
履歴管理部１１２は、コミュニケーション履歴を、ユーザ１００自らがしたコミュニケーションの履歴と、相手方であるユーザ２００からしたコミュニケーションの履歴とを、別個に管理してもよい。例えば、相手方からしたコミュニケーションの回数が多く、ユーザ１００自らがしたコミュニケーションの回数が少ない場合（例えば、相手方が親である場合）は、リコメンドしてもユーザ１００がコミュニケーションを取ろうとしない可能性が高い。よって、リコメンド部１１３は、閾値期間を長くする、又はリコメンドしない。反対に、たまにはユーザ１００自らがコミュニケーションを取るように、リコメンド部１１３は閾値期間を短くしてもよい。
【００８０】
（変形例３）
上述した実施形態では、通信端末１０は、コミュニケーションを取るべき相手に電話を掛けるように、ユーザ１００に対するリコメンドを行っていた。これに代えて、通信端末１０は、通話以外のコミュニケーション手段、例えば、電子メール又はＳＮＳ等を用いてコミュニケーションを取るように、ユーザ１００に対するリコメンドを行ってもよい。
この場合において、通信端末１０は、コミュニケーション手段毎にコミュニケーション履歴を別個に管理してリコメンドを行ってもよいし、複数のコミュニケーション手段のコミュニケーション履歴に基づいてリコメンドを行ってもよい。後者の場合、通信端末１０は、例えば、閾値期間を超えたかどうかを判断するにあたり、少なくともいずれかのコミュニケーション手段でコミュニケーションが取られていれば、リコメンドしないようにしてもよい。
【００８１】
（変形例４）
上述した実施形態の閾値期間が可変期間である場合、当該閾値期間は、以下の方法で決定されてもよい。例えば、リコメンド部１１３は、リコメンドしたのにも関わらず、ユーザ１００がそのリコメンドに応じなかった場合、即ちコミュニケーションを取らなかった場合は、その回数又は頻度に応じて当該閾値期間を長くする。この閾値期間は、相手毎に決定されてもよいし、全相手共通に決定されてもよい。
【００８２】
また、リコメンド部１１３は、リコメンドしたにも関わらず、ユーザ１００がコミュニケーションを取らなかった場合は、その回数又は頻度に応じて、リコメンドを行うタイミングを変更してもよい。このリコメンドタイミングも、相手毎に決定されてもよいし、全相手共通に決定されてもよい。
【００８３】
（変形例５）
上述した各変形例の構成は、上述した第２実施形態の通信端末１０Ａに適用されてもよい。また、上述した実施形態で説明した構成の一部が省略されてもよい。例えば、上述した第２実施形態の通信端末１０Ａは、処理例１、処理例２、及び処理例３のうちのいずれか一部の処理のみを実行してもよい。
【００８４】
（変形例６）
本明細書で説明した各態様／実施形態は、ＬＴＥ（Long  Term  Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future  Radio  Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra  Mobile  Broadband）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【００８５】
（変形例７）
本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャート等は、矛盾のない限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【００８６】
（変形例８）
入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
【００８７】
（変形例９）
判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：true又はfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。
【００８８】
（変形例１０）
本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【００８９】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【００９０】
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能等を意味するよう広く解釈されるべきである。また、ソフトウェア、命令等は、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）等の有線技術及び／又は赤外線、無線及びマイクロ波等の無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。
【００９１】
本明細書で説明した情報、信号等は、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップ等は、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【００９２】
なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。
【００９３】
明細書で使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。
【００９４】
また、本明細書で説明した情報、パラメータ等は、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。
【００９５】
本明細書で使用する「判断（determining）」、「決定（determining）」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定（judging）、計算（calculating）、算出（computing）、処理（processing）、導出（deriving）、調査（investigating）、探索（looking up）（例えば、テーブル、データベース又は別のデータ構造での探索）、確認（ascertaining）したことを「判断」「決定」したとみなすこと等を含み得る。また、「判断」、「決定」は、受信（receiving）（例えば、情報を受信すること）、送信（transmitting）（例えば、情報を送信すること）、入力（input）、出力（output）、アクセス（accessing）（例えば、メモリ中のデータにアクセスすること）したことを「判断」「決定」したとみなすこと等を含み得る。また、「判断」、「決定」は、解決（resolving）、選択（selecting）、選定（choosing）、確立（establishing）、比較（comparing）等したことを「判断」「決定」したとみなすことを含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなすことを含み得る。
【００９６】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【００９７】
「含む（including）」、「含んでいる（comprising）」、及びそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える」と同様に、包括的であることが意図される。更に、本明細書あるいは特許請求の範囲において使用されている用語「又は（or）」は、排他的論理和ではないことが意図される。
【００９８】
（変形例１１）
なお、上記実施の形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。
【符号の説明】
【００９９】
１…通信システム、１０，１０Ａ，２０…通信端末、１１…プロセッサ、１１１，１１１Ａ…コミュニケーション処理部、１１２，１１２Ａ…履歴管理部、１１３，１１３Ａ…リコメンド部、１１４…位置特定部、１１５…状態特定部、１２…メモリ、１３…ストレージ、１４…通信装置、１５，１５Ａ…入力装置、１５１…測位部、１６…出力装置、１６１…表示部。
【図１】
2018101881.tif 000003
【図２】
2018101881.tif 000004
【図３】
2018101881.tif 000005
【図４】
2018101881.tif 000006
【図５】
2018101881.tif 000007
【図６】
2018101881.tif 000008
【図７】
2018101881.tif 000009
【図８】
2018101881.tif 000010
【図９】
2018101881.tif 000011
【図１０】
2018101881.tif 000012
【図１１】
2018101881.tif 000013
【図１２】
2018101881.tif 000014
【図１３】
2018101881.tif 000015
【図１４】
2018101881.tif 000016