(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0016】
以下、図面を参照して本発明の実施形態を説明する。
[第1実施形態]
図1は、本発明の第1実施形態に係る通信システム1の全体構成を示す図である。通信システム1は、通信端末10と、複数の通信端末20(20−1,20−2,20−3,20−4)と、SNSサーバ30とを備える。通信端末10は、本発明の通信端末に相当する。通信端末10は、ユーザ100により使用される。通信端末20は、ユーザ200により使用される。
図1では、通信端末20−i(ただし、1≦i≦4)を使用するユーザ200を、「ユーザ200−i」と示す。
【0017】
ユーザ100は、いずれかのユーザ200を相手として、コミュニケーションを取る。このコミュニケーションは、ユーザ100が通信端末10を、ユーザ200が通信端末20を使用することで、取ることができる。また、このコミュニケーションは、ネットワークNWを介して、取ることができる。ネットワークNWは、移動通信網、ゲートウェイ等を含む通信回線である。通信端末10は、当該コミュニケーションを取るための処理(後述するコミュニケーション処理)を行う。
【0018】
なお、本実施形態では、通信端末10、及び通信端末20は、それぞれ携帯型の通信端末で、より詳細にはスマートフォンである。ただし、通信端末10、及び通信端末20は、スマートフォン以外の携帯型の通信端末(例えば、フィーチャーフォン、通信機能を有するウェアラブル端末)、又は携帯型でない通信端末(例えば、通信機能を有する各種コンピュータ装置)であってもよい。また、
図1には、通信端末20として4台が示されているが、実際には多数存在し得る。通信端末20は、前述したコミュニケーションを取るために利用できる通信端末であればよいからである。
【0019】
SNSサーバ30は、ユーザ100とユーザ200とが、SNSを利用してコミュニケーションを取るためのサービスを提供するサーバ装置である。SNSサーバ30は、通信端末10、又は通信端末20から投稿された情報(以下「投稿情報」)を蓄積し、ネットワークNWを介してこれを公開する。投稿情報は、例えば日記又はメッセージ等で、ユーザ100、又はユーザ200により作成される。投稿情報は、文字(文章)、記号、絵文字、画像等の要素を含み得る。
【0020】
図2は、通信端末10の構成の一例を示す図である。通信端末10は、物理的には、プロセッサ11、メモリ12、ストレージ13、通信装置14、入力装置15、及び出力装置16等を含むコンピュータ装置として構成される。プロセッサ11は、バスを介してメモリ12、ストレージ13、通信装置14、入力装置15、及び出力装置16の各々と接続されている。
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニット等に読み替えることができる。通信端末10のハードウェア構成は、図に示した各装置を1つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【0021】
プロセッサ11は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ11は、周辺装置とのインターフェース、制御装置、演算装置、レジスタ等を含む中央処理装置(CPU:Central Processing Unit)で構成されてもよい。
また、プロセッサ11は、プログラム(プログラムコード)、ソフトウェアモジュールやデータを、ストレージ13及び/又は通信装置14からメモリ12に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。各種処理は、1つのプロセッサ11で実行される旨を説明してきたが、2以上のプロセッサ11により同時又は逐次に実行されてもよい。プロセッサ11は、1以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介して受信されてもよい。
【0022】
メモリ12は、コンピュータ読み取り可能な記録媒体であり、例えば、ROM(Read Only Memory)、EPROM(Erasable Programmable ROM)、EEPROM(Electrically Erasable Programmable ROM)、RAM(Random Access Memory)等の少なくとも1つで構成されてもよい。メモリ12は、レジスタ、キャッシュ、メインメモリ(主記憶装置)等と呼ばれてもよい。
【0023】
ストレージ13は、コンピュータ読み取り可能な記録媒体であり、例えば、CD−ROM(Compact Disc ROM)等の光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Blu−ray(登録商標)ディスク)、スマートカード、フラッシュメモリ(例えば、カード、スティック、キードライブ)、フロッピー(登録商標)ディスク、磁気ストリップ等の少なくとも1つで構成されてもよい。ストレージ13は、補助記憶装置と呼ばれてもよい。
【0024】
通信装置14は、無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア(送受信デバイス)であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信装置14は、通話のための通信を行う。
【0025】
入力装置15は、外部からの入力を受け付ける入力デバイス(例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサ類)である。出力装置16は、外部への出力を実施する出力デバイス(例えば、ディスプレイ、スピーカ、LEDランプ等)である。出力装置16は、表示部161を含む。表示部161は、表示面に画像を表示する。表示部161は、例えば液晶ディスプレイであるが、これ以外の表示部であってもよい。
【0026】
また、通信端末10は、マイクロプロセッサ、デジタル信号プロセッサ(DSP:Digital Signal Processor)、ASIC(Application Specific Integrated Circuit)、PLD(Programmable Logic Device)、FPGA(Field Programmable Gate Array)等のハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ11は、これらのハードウェアの少なくとも1つで実装されてもよい。
通信端末10における各機能は、プロセッサ11、メモリ12等のハードウェア上に所定のソフトウェア(プログラム)を読み込ませることで、プロセッサ11が演算を行い、通信装置14による通信や、メモリ12及びストレージ13におけるデータの読み出し及び/又は書き込みを制御することで実現される。
【0027】
次に、通信端末10のプロセッサ11の機能構成を説明する。プロセッサ11は、コミュニケーション処理部111、履歴管理部112、及びリコメンド部113を含む。
コミュニケーション処理部111は、ユーザ100とユーザ200とが、ネットワークNWを利用してコミュニケーションを取るためのコミュニケーション処理を行う。コミュニケーション処理は、ユーザ100とユーザ200との間で、意思、感情、又は思考等の情報を伝達するための処理であって、ネットワークNWを介して行われる処理である。コミュニケーション処理は、本実施形態では、通話によりコミュニケーションを取るための処理である。この場合のコミュニケーション処理は、ネットワークNWとの間に通信路を確立する処理、及び通話に係る音声データを送受信する処理等を含む。本実施形態のコミュニケーション処理は、通信端末10の発信が契機となって行われるコミュニケーション処理であるものとする。ただし、コミュニケーション処理は、相手方である通信端末20の発信、換言すると通信端末10の着信が契機となって行われるコミュニケーション処理に置き換えられてもよい。又は、本実施形態のコミュニケーション処理は、これら両方のコミュニケーション処理を含んでいてもよい。
【0028】
履歴管理部112は、ユーザ100が取ったコミュニケーションの履歴を、その相手毎(つまり、ユーザ200毎)に管理する。履歴管理部112は、ユーザ100といずれかのユーザ200とがコミュニケーションを取るたびに、そのユーザ200に関するコミュニケーションの履歴を更新する。コミュニケーションの履歴は、ストレージ13に記憶されている履歴管理DB(Data Base)131に記録される。
【0029】
図3は、履歴管理DB131の構成の一例を示す図である。履歴管理DB131は、コミュニケーションの相手毎に、コミュニケーション手段と、日時とを対応付けて記録したデータベースである。コミュニケーションの相手は、
図3には、相手の名称を用いて記されている。しかし、当該相手を一意に特定できる情報であれば、他の情報(例えば、電話番号)であってもよい。コミュニケーション手段は、コミュニケーションを取るのに用いられた手段で、本実施形態では「通話」である。日時は、コミュニケーションが取られた日時を示す。この日時は、例えば通話の開始日時又は終了日時であるが、これら以外の日時であってもよい。
図3の履歴管理DB131には、例えば、「父」(ユーザ100の父であるユーザ200−1)、「A」(友人であるユーザ200−2)、「B」(友人であるユーザ200−3)、「C」(友人であるユーザ200−4)に関するコミュニケーションの履歴が記録されている。
なお、履歴管理DB131は、携帯端末等が一般的に記憶する通話履歴を記録したデータで代用されてもよい。通話履歴には、通常、通話の相手毎に通話が行われた日時が含まれるからである。
【0030】
図2に戻り、リコメンド部113は、履歴管理部112により管理されるコミュニケーションの履歴に基づいて、閾値期間を超えてコミュニケーションを取っていない相手とのコミュニケーションを取るように、ユーザ100に対するリコメンドを行う。また、リコメンド部113は、当該相手を特定した場合に、所定の条件を満たしたタイミング(以下「リコメンドタイミング」という。)で、リコメンドを行う。即ち、閾値期間を超えてコミュニケーションを取っていない相手が特定されるタイミングと、リコメンドタイミングとは、一致するとは限らず、異なる場合がある。リコメンド部113は、本実施形態では、表示部161への画面(以下「リコメンド画面」という。)の表示により、このリコメンドを行う。リコメンドの方法は、コミュニケーションを取るべき相手をユーザ100が認識できる方法であれば、表示以外の方法(例えば、音声出力)であってもよい。
【0031】
<A:コミュニケーションが取られた際の処理>
図4は、通信端末10が、コミュニケーションが取られた際に実行する処理を示すフローチャートである。例えば、ユーザ100が、通信端末10を用いて通話をした際に、
図4の処理が実行される。
【0032】
コミュニケーション処理部111は、ユーザ100のコミュニケーションの相手を指定して、コミュニケーション処理を行う(ステップS1)。コミュニケーション処理部111は、例えば、入力装置15を用いて入力を受け付けた操作に応じて、当該相手を指定する。この操作は、例えば、電話帳データから通話の相手を選択する操作、又は電話番号を入力する操作がある。コミュニケーション処理が完了すると、履歴管理部112は、履歴管理DB131に記録されているコミュニケーション履歴を更新する(ステップS2)。具体的には、履歴管理部112は、ステップS1のコミュニケーション処理が実行された日時を、そのコミュニケーションの相手、及びコミュニケーション手段と対応付けて、履歴管理DB131に記録する。これにより、
図3に示す履歴管理DB131が構成される。
【0033】
<B:リコメンドに係る処理>
図5は、通信端末10が、コミュニケーションを取ることをユーザ100にリコメンドする際の処理を示すフローチャートである。通信端末10は、
図5に示す処理を、例えば所定の周期で、繰り返し実行する。
履歴管理部112は、履歴管理DB131に記録されているコミュニケーション履歴を取得する(ステップS11)。履歴管理部112は、ここでは、
図3に示す履歴管理DB131に示すコミュニケーション履歴を取得するものとする。
【0034】
次に、リコメンド部113は、コミュニケーション履歴に基づいて、リコメンドする相手を特定する(ステップS12)。リコメンド部113は、現在の日時と、コミュニケーション履歴が示す日時とを比較する。そして、リコメンド部113は、閾値期間を超えてコミュニケーション処理が行われていない相手を特定する。閾値期間は、例えば予め決められた固定期間で、ここでは6ヶ月であるものとする。
【0035】
次に、リコメンド部113は、ステップS12でリコメンドする相手を1以上特定したかどうかを判断する(ステップS13)。リコメンドする相手を1つも特定しなかったと判断した場合(ステップS13;NO)、リコメンド部113は
図5の処理を終了させる。最近コミュニケーションを取っていない相手がおらず、コミュニケーションを取るようにリコメンドすべき相手が存在しないからである。
【0036】
ステップS13で「YES」と判断した場合、リコメンド部113は、ステップS14の処理に進む。ここでは、「父」であるユーザ200−1との最後のコミュニケーションが「2015/6/21/19:00」であり、既に6ヶ月以上が経過しているものとする。
【0037】
次に、リコメンド部113は、ステップS12で特定した相手について、リコメンドタイミングであるかどうかを判断する(ステップS14)。リコメンドタイミングは、例えば、相手の属性に応じて決まる。相手が父である場合、父の日(6月の第3日曜日)に応じたリコメンドタイミングとなる。例えば、父の日の前日の12:00がリコメンドタイミングとなる。
なお、相手の属性は、例えば、ストレージ13に記憶された電話帳データに登録された情報に基づいて特定されるが、これ以外の方法で特定されてもよい。
【0038】
現在日時が「2016/6/18/12:00」(つまり、父の日の前日の12:00よりも前)よりも前である場合には、リコメンド部113はステップS14で「NO」と判断する。この場合、リコメンド部113は、リコメンドを行わずに、待機する(ステップS15)。
【0039】
リコメンド部113は、ステップS14で「YES」と判断した場合、ステップS16の処理に進める。具体的には、リコメンド部113は、現在日時が「2016/6/18/12:00」以降になった場合に、ステップS14で「YES」と判断する。そして、リコメンド部113は、ステップS12で特定した相手とコミュニケーションを取るように、ユーザ100に対するリコメンドを行う(ステップS16)。
【0040】
図6は、ステップS16で表示されるリコメンド画面の一例を示す図である。
図6に示すリコメンド画面には、「最近、『父』さんと連絡を取っていないようです。本日は、父の日ですから、電話を掛けてみませんか?」というメッセージが含まれる。ここにおいて、『父』は、ユーザ200−1の名称であって、履歴管理DB131に記録された相手の名称と一致する。このように、リコメンド画面には、コミュニケーションを取るべき相手を特定する情報が含まれる。更に、リコメンド画面には、「電話を掛ける」という文字列が付されたボタンB1と、「キャンセル」という文字列が付されたボタンB2とが配置されている。ユーザ100は、リコメンドされた相手であるユーザ200−1に電話を掛ける場合、ボタンB1を操作する操作を行う。この操作が行われると、コミュニケーション処理部111は、通信端末20−1に電話を掛けて通話するためのコミュニケーション処理を行う。一方、ユーザ100は、電話を掛けなくてよいと判断した場合、ボタンB2を操作する操作を行う。この操作が行われると、コミュニケーション処理部111は、コミュニケーション処理を行わずに、
図5の処理を終了させる。
【0041】
ステップS12で別の相手が特定された場合も、同様の処理が行われる。
図3には示していないが、相手がユーザ100の母である場合は、リコメンド部113は、母の日(5月の第2日曜日)に応じたリコメンドタイミングで、リコメンドを行う。即ち、リコメンド部113は、「母」とのコミュニケーションが閾値期間を超えて取られていない場合には、母の日に応じたリコメンドタイミング(例えば、母の日の前日の12:00)で、ステップS16のリコメンドを行う。
【0042】
リコメンドタイミングは、相手の属性ではなく、その相手に固有のタイミングであってもよい。例えば、相手が友人であるユーザ200−2,200−3,200−4である場合は、リコメンド部113は、その相手の誕生日をリコメンドタイミングとする。即ち、リコメンド部113は、友人とのコミュニケーションが閾値期間を超えて取られていない場合には、その友人の誕生日に応じたリコメンドタイミング(例えば、誕生日の当日の12:00)で、ステップS16のリコメンドを行う。
【0043】
このように、リコメンドタイミングは、相手にとって特別な意味のあるタイミングとすることが望ましい。かかるタイミングは、ユーザ100にとって、最近コミュニケーションを取っていない相手と積極的にコミュニケーションを取りやすいタイミングとなりやすいからである。
なお、相手の属性に応じたリコメンドタイミング、又は相手に固有のリコメンドタイミングは、通信端末10の設計又は製造段階で決められてもよいし、ユーザ100により指定されてもよい。
【0044】
以上のように、通信端末10は、コミュニケーションを取っていない期間が閾値期間を超えると直ちにリコメンドを行うとは限らず、その相手に応じたリコメンドタイミングで、リコメンドを行う。これにより、ユーザ100は、しばらくコミュニケーションを取っていない相手であっても、積極的にコミュニケーションを取りやすくなる。
【0045】
リコメンド部113は、ステップS12において、可変期間である閾値期間を超えてコミュニケーションを取っていない相手を特定してもよい。リコメンド部113は、例えば、閾値期間の長さを、相手毎のコミュニケーション履歴に応じて変化させる。例えば、ユーザ100が半年に1回しか電話を掛けないような相手と、毎日電話を掛けるような相手とでは、ユーザ100にとって“しばらく連絡していない”と感じる期間の長さは異なると考えられる。そこで、リコメンド部113は、相手毎のコミュニケーションが取られている頻度に応じて、その相手に対する閾値期間を決定する。具体的には、リコメンド部113は、過去のコミュケーションが取られた頻度が高い相手ほど当該閾値期間を短く、反対に、その頻度が低い相手ほど当該閾値期間を長くする。
これにより、通信端末10は、相手毎に的確なリコメンドタイミングで、ステップS16のリコメンドを行うことができる。
【0046】
[第2実施形態]
次に、本発明の第2実施形態を説明する。
本実施形態の通信端末は、通話以外のコミュニケーション手段を用いて、コミュニケーションを取るようリコメンドする相手を特定し、またリコメンドタイミングを決定する点で、上述した第1実施形態と相違する。本実施形態では、上述した第1実施形態と同じ符号を付した要素は、上述した第1実施形態と同等に機能する。また、上述した第1実施形態の要素と対応する要素については、符号の末尾に「A」を付して表す。
【0047】
図7は、通信端末10Aの構成の一例を示す図である。通信端末10Aの入力装置15Aは、測位部151を備える。測位部151は、通信端末10の位置を測定し、測定した位置を示す位置情報を生成する。測位部151は、例えば、GPS(Global Positioning System)方式に従って位置情報を生成する。この場合、位置情報は、緯度、及び経度の情報を含む。通信端末10Aのその余の物理的な構成は、上述した第1実施形態と同じであるものとする。
【0048】
通信端末10Aのプロセッサ11Aの機能構成を説明する。プロセッサ11Aは、コミュニケーション処理部111Aと、履歴管理部112Aと、リコメンド部113Aと、位置特定部114と、状態特定部115とを有する。
位置特定部114は、ユーザ100の位置を特定する。本実施形態では、位置特定部114は、測位部151から供給された位置情報が示す通信端末10Aの位置を、ユーザ100の位置として特定する。
【0049】
状態特定部115は、ユーザ100の状態を特定する。ユーザ100の状態は、例えば、健康の状態(例えば、風邪を引いたこと)、生活の状態(例えば、大学に入学したこと等の生活の状態の変化)である。状態特定部115は、例えば、ストレージ13に記憶された電子メール(送信済みメール、又は受信済みメール)、又はSNSサーバ30に投稿した投稿情報に基づいて、ユーザ100の状態を特定する。電子メール又は投稿情報には、ユーザ100の現在又は過去の状況等、ユーザ100の状況を把握するための情報が含まれることがあるからである。ただし、ユーザ100の状態を特定する方法は、これに限られず、更に別の方法(例えば、ユーザ100のスケジュールを示すスケジュールデータの参照)であってもよい。
【0050】
コミュニケーション処理部111Aは、コミュニケーション処理を行う。コミュニケーション処理は、本実施形態では、通話以外にも、電子メール及びSNS等の、様々なコミュニケーション手段に関する処理を含む。電子メールに係るコミュニケーション処理は、例えば、当該電子メールの作成、及び送受信等の処理を含む。SNSに係るコミュニケーション処理は、投稿情報の作成、及びネットワークNW上で投稿情報を公開するためのSNSサーバ30への投稿等の処理を含む。本実施形態のコミュニケーション処理も、通信端末10の発信が契機となって行われるコミュニケーション処理、及び相手方である通信端末20の発信、換言すると通信端末10の着信が契機となって行われるコミュニケーション処理の一方、又は両方を含む。電子メールに係るコミュニケーション処理の場合、電子メールの送信先に限られず、電子メールの送信元が、コミュニケーション処理の相手となる場合がある。
【0051】
履歴管理部112Aは、ユーザ100が取ったコミュニケーションの履歴を、その相手毎に管理する。履歴管理部112Aは、電子メールについては、その電子メールの送信先を、コミュニケーションを取った相手として特定する。履歴管理部112Aは、SNSについては、ユーザ100が作成した投稿情報の宛先となった相手、その投稿情報を閲覧した相手、又はその投稿情報に対して応答(例えば、返信)をした相手を、コミュニケーションを取った相手として特定する。履歴管理部112Aは、ユーザ100といずれかのユーザ200とがコミュニケーションを取るたびに、そのユーザ200に関するコミュニケーションの履歴を更新する。コミュニケーションの履歴は、ストレージ13に記録された履歴管理DB131Aに記録される。
【0052】
図8は、履歴管理DB131Aの構成の一例を示す図である。履歴管理DB131Aは、コミュニケーションの相手毎に、コミュニケーション手段と、日時とを対応付けて記録したデータベースである。コミュニケーションの相手、コミュニケーション手段、及び日時の各情報は、上述した第1実施形態で説明したとおりである。ただし、コミュニケーション手段として、電子メール、及びSNS等の、通話以外の手段が用いられることがある点で、上述した第1実施形態とは相違する。
【0053】
図7に戻り、リコメンド部113Aは、履歴管理部112Aにより管理されるコミュニケーションの履歴に基づいて、閾値期間を超えてコミュニケーションを取っていない相手とのコミュニケーションを取るように、ユーザ100に対するリコメンドを行う。また、リコメンド部113Aは、閾値期間を超えてコミュニケーションを取っていない相手を特定した場合に、所定の条件を満たしたタイミングで、リコメンドを行う。更に、リコメンド部113Aは、位置特定部114が特定した位置、又は状態特定部115が特定したユーザ100の状態に応じて、リコメンドする相手、又はリコメンドのタイミングを判断することがある。
【0054】
<A:コミュニケーションが取られた際の処理>
通信端末10Aが、コミュニケーションが取られた際に実行する処理は、上述した第1実施形態と大略同じである。コミュニケーション処理部111Aは、ステップS1では、ユーザ100と、ユーザ200とがコミュニケーションを取るためのコミュニケーション処理を行う。そのコミュニケーション処理が完了すると、履歴管理部112Aは、ステップS2で、履歴管理DB131Aに記録されているコミュニケーション履歴を更新する。具体的には、履歴管理部112Aは、ステップS1のコミュニケーション処理が実行された日時と、コミュニケーションの相手とを対応付けて、履歴管理DB131Aに記録する。これにより、
図8に示す履歴管理DB131Aが構成される。
【0055】
<B:リコメンドに係る処理>
本実施形態のリコメンドに係る処理として、以下の(処理例1)、(処理例2)、及び(処理例3)を説明する。
【0056】
(処理例1)
処理例1では、イベントと関連付けられた相手と閾値期間を超えてコミュニケーションが取られていない場合に、当該イベントが行われる時期に応じたタイミングで、リコメンドを行う。イベントは、例えばオリンピック又はコンサート等の催し物である。
【0057】
図9は、処理例1のリコメンドに係る処理を示すフローチャートである。通信端末10Aは、
図9に示す処理を、例えば所定の周期で、繰り返し実行する。
履歴管理部112Aは、履歴管理DB131Aに記録されているコミュニケーション履歴を取得する(ステップS21)。ステップS21では、ここでは、
図8に示す履歴管理DB131Aに応じたコミュニケーション履歴が取得されるものとする。
【0058】
次に、リコメンド部113Aは、コミュニケーション履歴、及びイベントに応じたリコメンドする相手を特定する(ステップS22)。リコメンド部113Aは、閾値期間を超えてコミュニケーション処理を実行していない相手のうち、イベントと関連付けられた相手を特定する。イベントと関連付けられた相手は、例えば、過去にユーザ100と一緒にそのイベントに参加したユーザ200である。イベントと関連付けられる相手については、例えば、電子メール又は投稿情報に基づいて特定される。また、閾値期間は、ここでは可変期間であり、具体的にはイベントに応じて決まるものとする。周期的に開催されるイベントの場合、そのイベントの開催時期に応じて閾値期間が決まる。例えば1年に1回のコンサート又はユーザ100の誕生日の場合は、閾値期間を9ヶ月、4年に1回に開催されるオリンピックの場合は、閾値期間を3年6ヶ月とする、という具合である。このように、リコメンド部113Aは、イベントの開催周期が長い場合ほど閾値期間を長くし、イベントの開催周期が短い場合ほど閾値期間を短くする。
【0059】
次に、リコメンド部113Aは、ステップS22でリコメンドする相手を1以上特定したかどうかを判断する(ステップS23)。リコメンドする相手を1つも特定しなかったと判断した場合(ステップS23;NO)、リコメンド部113Aは
図9の処理を終了させる。
【0060】
ステップS23で「YES」と判断した場合、リコメンド部113Aは、ステップS24の処理に進む。ここでは、ステップS22において、ユーザ100と前回のオリンピックに一緒に行った「A」であるユーザ200−2が特定されたとする。ユーザ200−2と最後に取られたコミュニケーションは、「2012/7/31/17:00」で、既に3年6ヶ月以上が経過している。
【0061】
次に、リコメンド部113Aは、ステップS22で特定した相手について、リコメンドタイミングであるかどうかを判断する(ステップS24)。このリコメンドタイミングは、イベント、例えばイベントの開催時期に応じて決められているものとする。イベントが「オリンピック」である場合、その開催時期(例えば初日)から6ヶ月前がリコメンドタイミングに決められているものとする。オリンピックの開催時期を「2016/8/1〜」とした場合、現在の日時が「2016/2/1」よりも前である場合には、リコメンド部113AはステップS24で「NO」と判断する。この場合、リコメンド部113Aは、リコメンドを行わずに、待機する(ステップS25)。
【0062】
リコメンド部113Aは、ステップS24で「YES」と判断した場合、ステップS26の処理に進める。具体的には、リコメンド部113Aは、現在日時が「2016/2/1」以降になった場合に、ステップS24で「YES」と判断する。そして、リコメンド部113Aは、ステップS22で特定した相手とコミュニケーションを取るように、ユーザ100に対するリコメンドを行う(ステップS26)。
【0063】
図10は、リコメンド画面の一例を示す図である。
図10に示すリコメンド画面には、「4年前のオリンピックに行った、『A』さんと最近連絡を取っていないようです。次回オリンピックが迫っています。『A』さんに電話を掛けてみませんか?」というメッセージが含まれる。更に、リコメンド画面には、「電話を掛ける」という文字列が付されたボタンB3と、「キャンセル」という文字列が付されたボタンB4とが配置されている。ユーザ100は、リコメンドの相手であるユーザ200−2に電話を掛ける場合、ボタンB3を操作する操作を行う。この操作が行われると、コミュニケーション処理部111は当該操作により指定した相手に電話を掛け、通話するためのコミュニケーション処理を行う。一方、ユーザ100は、電話を掛けなくてよいと判断した場合、ボタンB4を操作する操作を行う。この操作が行われると、コミュニケーション処理部111は、コミュニケーション処理を実行せずに、
図9の処理を終了させる。
【0064】
このように、通信端末10Aは、相手に関連付けられたイベントに応じたリコメンドタイミングで、リコメンドを行う。これにより、ユーザ100は、しばらくコミュニケーションを取っていない相手であっても、所定のイベントが開催されることを動機として、その相手とコミュニケーションを取ることができる。例えば、ユーザ100にとっては、前回のオリンピックに一緒に行った相手と、再びオリンピックに一緒に行こうと考える場合もある。このように、特定のイベントに特定の人と一緒に行き、それ以外の時期にはあまりコミュニケーションを取らないような場合に、処理例1のリコメンドは有用である。
【0065】
以上、イベントが「オリンピック」である場合について説明したが、他のイベントの場合も同様の処理が行われる。例えばイベントが1年に1回のコンサート、又は誕生日である場合は、リコメンド部113Aは、次回のコンサートの開催時期、又は誕生日に応じたリコメンドタイミングで、リコメンドを行う。
【0066】
(処理例2)
処理例2では、場所と関連付けられた相手と閾値期間を超えてコミュニケーションが取られていない場合に、当該場所をユーザ100が訪れたタイミングで、リコメンドを行う。本実施形態の場所は、例えばユーザ100の旅行先であるが、出張先でもよく、ユーザ100が訪れる理由は特に問わない。
【0067】
図11は、処理例1のリコメンドに係る処理を示すフローチャートである。通信端末10Aは、
図11に示す処理を、例えば所定の周期で、繰り返し実行する。
履歴管理部112Aは、履歴管理DB131Aに記録されているコミュニケーション履歴を取得する(ステップS31)。次に、位置特定部114は、測位部151から供給された位置情報に基づいて、ユーザ100の位置を特定する(ステップS32)。次に、リコメンド部113Aは、コミュニケーション履歴、及びユーザ100の位置に応じてリコメンドする相手を特定する(ステップS33)。具体的には、リコメンド部113Aは、閾値期間を超えてコミュニケーション処理を実行していない相手のうち、ステップS32で特定した位置と関連付けられた相手を特定する。位置(場所)に応じた相手は、例えば、過去に一緒にその場所を訪れた相手、又はその場所に住む相手(つまり、現地の人)である。当該相手については、例えば、電子メール又は投稿情報に基づいて特定される。当該閾値期間は、ここでは固定期間である。
【0068】
次に、リコメンド部113Aは、ステップS33でリコメンドする相手を1以上特定したかどうかを判断する(ステップS34)。リコメンドする相手を1つも特定しなかったと判断した場合(ステップS34;NO)、リコメンド部113Aは、
図11の処理を終了させる。
【0069】
ステップS34で「YES」と判断した場合、リコメンド部113Aは、ステップS33で特定した相手とコミュニケーションを取るように、ユーザ100に対するリコメンドを行う(ステップS35)。即ち、リコメンド部113Aは、所定の場所をユーザ100が訪れたことを条件に、リコメンドを行うことになる。
【0070】
図12は、リコメンド画面の一例を示す図である。
図12に示すリコメンド画面には、「以前にこの場所を一緒に訪れた、『B』さんと最近連絡を取っていないようです。『B』さんに電話を掛けてみませんか?」というメッセージが含まれる。即ち、コミュニケーションを取ることを促す相手の情報が、このメッセージに含まれる。更に、リコメンド画面には、「電話を掛ける」という文字列が付されたボタンB5と、「キャンセル」という文字列が付されたボタンB6とが配置されている。ボタンB5、及びボタンB6に関する通信端末10の動作は、処理例1と同じでよい。
これにより、ユーザ100は、所定の場所を訪れたときに、その場所に応じた相手と、コミュニケーションを取りやすくなる。
【0071】
本処理例2を以下のように変形してもよい。
位置特定部114は、測位部151から供給された位置情報に基づいて、コミュニケーション処理が行われた位置を特定する。そして、履歴管理部112Aは、コミュニケーション履歴として、コミュニケーション手段、及び日時に加え、当該コミュニケーション処理が行われた位置を示す位置情報を、履歴管理DB131Aに記録する。ステップS33において、リコメンド部113Aは、ステップS32で特定した位置をユーザ100が過去に訪れた際にコミュニケーションを取った相手を、履歴管理DB131Aに基づいて特定する。そして、リコメンド部113Aは、特定した当該相手とコミュニケーションを取るようにリコメンドを行う。この場合も、ユーザ100は、所定の場所を訪れたときに、その場所に応じた相手と、コミュニケーションを取りやすくなる。
【0072】
本処理例2を更に以下のように変形してもよい。
リコメンド部113Aは、スケジュールデータ、電子メール、又は投稿情報に基づいてユーザ100が訪れる場所を予測し、その予測した場所に応じた相手とコミュニケーションを取るようにリコメンドを行ってもよい。即ち、実際にユーザ100が訪れた場所でなく、ユーザ100が訪れると予測した場所に応じた相手が、リコメンドの対象となる。この場合も、ユーザ100は、所定の場所を訪れたときに、その場所に応じた相手と、コミュニケーションを取りやすくなる。この場合、位置特定部114が特定した位置を用いなくとも、リコメンド部113Aはコミュニケーションを取るべき相手を特定できる。
【0073】
(処理例3)
処理例3では、ユーザ100の状態に応じた相手と閾値期間を超えてコミュニケーションが取られていない場合に、リコメンドを行う。
図13は、処理例3のリコメンドに係る処理を示すフローチャートである。通信端末10Aは、
図13に示す処理を、例えば所定の周期で、繰り返し実行する。
履歴管理部112Aは、履歴管理DB131Aに記録されているコミュニケーション履歴を取得する(ステップS41)。次に、状態特定部115は、ユーザ100の状態を特定する(ステップS42)。状態特定部115は、ここでは、ユーザ100の健康の状態を特定するものとする。ユーザ100の状態については、例えば、電子メール又は投稿情報に基づいて特定される。
【0074】
次に、リコメンド部113Aは、コミュニケーション履歴、及びユーザ100の状態に応じて、リコメンドする相手を特定する(ステップS43)。ここでは、リコメンド部113Aは、閾値期間を超えてコミュニケーション処理を実行していない相手のうち、ユーザ100の状態に応じた相手を特定する。特定される相手は、ここでは、ユーザ100と同じ、又は関連する状態にある相手、例えば同じ病気をしたことのある相手である。当該閾値期間は、固定期間であるものとする。ユーザ100の状態と関連付けられる相手については、例えば、電子メール又は投稿情報に基づいて特定される。
【0075】
次に、リコメンド部113Aは、ステップS43でリコメンドする相手を1以上特定したかどうかを判断する(ステップS44)。リコメンドする相手を1つも特定しなかったと判断した場合(ステップS44;NO)、リコメンド部113Aは
図13の処理を終了させる。
【0076】
ステップS44で「YES」と判断した場合、リコメンド部113Aは、ステップS43で特定した相手とコミュニケーションを取るように、ユーザ100に対するリコメンドを行う(ステップS45)。即ち、リコメンド部113Aは、ユーザ100が所定の状態になったことを条件に、リコメンドを行うことになる。これにより、ユーザ100は、自身の病気に関して的確なアドバイスを受けられる相手を受けやすくなる。
なお、ユーザ100の状態が健康の状態以外の場合も、同様の処理が行われる。例えば、ユーザ100が大学に入学したのであれば、同じ大学に入学した相手(例えば、先輩、又は同級生)が、ステップS43で特定される。このように、ユーザ100の状態と同じ状態、又は関連する状態になったユーザ200が、リコメンドの相手となり得る。
【0077】
図14は、リコメンド画面の一例を示す図である。
図14に示すリコメンド画面には、「同じ病気をした『C』さんと最近連絡を取っていないようです。『C』さんに電話を掛けてみませんか?」というメッセージが含まれる。即ち、コミュニケーションを取ることを促す相手の情報が、このメッセージに含まれる。更に、リコメンド画面には、「電話を掛ける」という文字列が付されたボタンB7と、「キャンセル」という文字列が付されたボタンB8とが配置されている。ボタンB7、及びボタンB8に関する通信端末10の動作は、処理例1と同じでよい。
これにより、ユーザ100は、現在の状態に応じた相手とコミュニケーションを取りやすくなる。
【0078】
[変形例]
本発明は、上述した実施形態と異なる形態で実施してもよい。また、以下に示す変形例は、各々を組み合わせてもよい。
(変形例1)
リコメンド部113は、リコメンドを行うタイミング、即ちリコメンドタイミングとなる時間的条件を制限してもよい。例えば、リコメンド部113が電話を掛けるようにリコメンドを行うのであれば、ユーザ100が電話できるか、又は相手(ユーザ200)が電話に出やすい時刻を、リコメンドタイミングとすることが望ましい。そこで、リコメンド部113は、例えば、休日又は平日の夜等の予め決められた時刻(時間帯)をリコメンドタイミングとし、深夜等の他の時刻(時間帯)をリコメンドタイミングとしない。また、リコメンド部113は、過去のコミュケーション履歴、又はスケジューラを参照して、ユーザ100又は相手にとって望ましいリコメンドタイミングを決定してもよい。
【0079】
(変形例2)
履歴管理部112は、コミュニケーション履歴を、ユーザ100自らがしたコミュニケーションの履歴と、相手方であるユーザ200からしたコミュニケーションの履歴とを、別個に管理してもよい。例えば、相手方からしたコミュニケーションの回数が多く、ユーザ100自らがしたコミュニケーションの回数が少ない場合(例えば、相手方が親である場合)は、リコメンドしてもユーザ100がコミュニケーションを取ろうとしない可能性が高い。よって、リコメンド部113は、閾値期間を長くする、又はリコメンドしない。反対に、たまにはユーザ100自らがコミュニケーションを取るように、リコメンド部113は閾値期間を短くしてもよい。
【0080】
(変形例3)
上述した実施形態では、通信端末10は、コミュニケーションを取るべき相手に電話を掛けるように、ユーザ100に対するリコメンドを行っていた。これに代えて、通信端末10は、通話以外のコミュニケーション手段、例えば、電子メール又はSNS等を用いてコミュニケーションを取るように、ユーザ100に対するリコメンドを行ってもよい。
この場合において、通信端末10は、コミュニケーション手段毎にコミュニケーション履歴を別個に管理してリコメンドを行ってもよいし、複数のコミュニケーション手段のコミュニケーション履歴に基づいてリコメンドを行ってもよい。後者の場合、通信端末10は、例えば、閾値期間を超えたかどうかを判断するにあたり、少なくともいずれかのコミュニケーション手段でコミュニケーションが取られていれば、リコメンドしないようにしてもよい。
【0081】
(変形例4)
上述した実施形態の閾値期間が可変期間である場合、当該閾値期間は、以下の方法で決定されてもよい。例えば、リコメンド部113は、リコメンドしたのにも関わらず、ユーザ100がそのリコメンドに応じなかった場合、即ちコミュニケーションを取らなかった場合は、その回数又は頻度に応じて当該閾値期間を長くする。この閾値期間は、相手毎に決定されてもよいし、全相手共通に決定されてもよい。
【0082】
また、リコメンド部113は、リコメンドしたにも関わらず、ユーザ100がコミュニケーションを取らなかった場合は、その回数又は頻度に応じて、リコメンドを行うタイミングを変更してもよい。このリコメンドタイミングも、相手毎に決定されてもよいし、全相手共通に決定されてもよい。
【0083】
(変形例5)
上述した各変形例の構成は、上述した第2実施形態の通信端末10Aに適用されてもよい。また、上述した実施形態で説明した構成の一部が省略されてもよい。例えば、上述した第2実施形態の通信端末10Aは、処理例1、処理例2、及び処理例3のうちのいずれか一部の処理のみを実行してもよい。
【0084】
(変形例6)
本明細書で説明した各態様/実施形態は、LTE(Long Term Evolution)、LTE−A(LTE-Advanced)、SUPER 3G、IMT−Advanced、4G、5G、FRA(Future Radio Access)、W−CDMA(登録商標)、GSM(登録商標)、CDMA2000、UMB(Ultra Mobile Broadband)、IEEE 802.11(Wi−Fi)、IEEE 802.16(WiMAX)、IEEE 802.20、UWB(Ultra-WideBand)、Bluetooth(登録商標)、その他の適切なシステムを利用するシステム及び/又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【0085】
(変形例7)
本明細書で説明した各態様/実施形態の処理手順、シーケンス、フローチャート等は、矛盾のない限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【0086】
(変形例8)
入出力された情報等は特定の場所(例えば、メモリ)に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
【0087】
(変形例9)
判定は、1ビットで表される値(0か1か)によって行われてもよいし、真偽値(Boolean:true又はfalse)によって行われてもよいし、数値の比較(例えば、所定の値との比較)によって行われてもよい。
【0088】
(変形例10)
本明細書で説明した各態様/実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知(例えば、「Xであること」の通知)は、明示的に行うものに限られず、暗黙的(例えば、当該所定の情報の通知を行わない)ことによって行われてもよい。
【0089】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【0090】
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能等を意味するよう広く解釈されるべきである。また、ソフトウェア、命令等は、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線(DSL)等の有線技術及び/又は赤外線、無線及びマイクロ波等の無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び/又は無線技術は、伝送媒体の定義内に含まれる。
【0091】
本明細書で説明した情報、信号等は、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップ等は、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【0092】
なお、本明細書で説明した用語及び/又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。
【0093】
明細書で使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。
【0094】
また、本明細書で説明した情報、パラメータ等は、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。
【0095】
本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)(例えば、テーブル、データベース又は別のデータ構造での探索)、確認(ascertaining)したことを「判断」「決定」したとみなすこと等を含み得る。また、「判断」、「決定」は、受信(receiving)(例えば、情報を受信すること)、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)(例えば、メモリ中のデータにアクセスすること)したことを「判断」「決定」したとみなすこと等を含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)等したことを「判断」「決定」したとみなすことを含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなすことを含み得る。
【0096】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【0097】
「含む(including)」、「含んでいる(comprising)」、及びそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える」と同様に、包括的であることが意図される。更に、本明細書あるいは特許請求の範囲において使用されている用語「又は(or)」は、排他的論理和ではないことが意図される。
【0098】
(変形例11)
なお、上記実施の形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック(構成部)は、ハードウェア及び/又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び/又は論理的に結合した1つの装置により実現されてもよいし、物理的及び/又は論理的に分離した2つ以上の装置を直接的及び/又は間接的に(例えば、有線及び/又は無線)で接続し、これら複数の装置により実現されてもよい。