米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> 松下電器産業株式会社

発明の名称 情報通知装置および情報通知方法
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−4781(P2007−4781A)
公開日 平成19年1月11日(2007.1.11)
出願番号 特願2006−142126(P2006−142126)
出願日 平成18年5月22日(2006.5.22)
代理人 【識別番号】100109210
【弁理士】
【氏名又は名称】新居 広守
発明者 田島 敬士 / 内藤 栄一 / 小澤 順
要約 課題
ユーザや情報提供者がルールを定めなくても、通知タイミングと通知する情報の量とを適切に制御することができる情報通知装置を提供する。

解決手段
時刻を検知する時刻検知部100と、メールの通知を行ったときのユーザの反応を検知する反応検知部7402と、検知された時刻および反応を反応履歴として蓄積する反応履歴蓄積部1803と、反応履歴に基づいて、ユーザにメールを通知することが適切であるか否かを示す通知評価値を時刻に応じて計算する通知評価値計算部110と、現在の時刻以降に受信する未来のメールの受信時刻を取得する未来メール取得部7413を有し、検知された時刻に応じて、通知情報蓄積部6707に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを通知評価値と未来のメールの受信時刻とを用いて決定する通知タイミング制御部7408とを備える。
特許請求の範囲
【請求項1】
受信した電子メールをユーザに通知する情報通知装置であって、
時刻を検知する時刻検知手段と、
前記メールの通知を行ったときの前記ユーザの反応を検知する反応検知手段と、
前記メールの通知を行ったときの前記時刻検知手段で検知された時刻および前記反応検知手段で検知された前記ユーザの反応を反応履歴として蓄積する反応履歴蓄積手段と、
前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻に応じて計算する通知評価値計算手段と、
前記ユーザに対して通知すべき、外部ネットワーク媒体から受信したメールを複数蓄積する通知情報蓄積手段と、
現在の時刻以降に外部ネットワーク媒体から受信する未来のメールの受信時刻を取得する未来メール取得部を有し、前記時刻検知手段で検知された時刻に応じて、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを、前記通知評価値計算手段で計算された前記通知評価値と前記未来のメールの受信時刻とを用いて決定する通知タイミング制御手段と、
前記通知タイミング制御手段が、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知することを決定したときに、前記所定の時刻において、前記通知情報蓄積手段に蓄積されている全てのメールを同時にユーザに通知する情報通知手段と
を備えることを特徴とする情報通知装置。
【請求項2】
前記通知タイミング制御手段は、前記時刻検知手段で検知された現在の時刻以降の前記通知評価値を用いて、前記通知情報蓄積手段に蓄積されている全てのメールを前記所定の時刻において同時に通知するか否かを決定する
ことを特徴とする請求項1記載の情報通知装置。
【請求項3】
前記所定の時刻とは現在時刻であり、
前記通知タイミング制御手段は、前記未来のメールの受信時刻が遅いほど現在時刻において通知するように決定する
ことを特徴とする請求項1記載の情報通知装置。
【請求項4】
前記通知タイミング制御手段は、前記通知情報蓄積手段に蓄積されたメールの数が多いほど現在時刻において通知するように決定する
ことを特徴とする請求項1記載の情報通知装置。
【請求項5】
前記情報通知装置は、さらに、前記通知評価値から、前記時刻検知手段で検知された時刻に応じて、同時に通知できるメールの最大数を計算する最大通知数計算手段を備え、
前記通知タイミング制御手段は、前記情報蓄積部に蓄積されたメールの数が、前記最大通知数計算手段で計算された前記時刻における前記最大数を上回った場合に、前記通知情報蓄積手段に蓄積されているメールのうち、前記最大数のメールを前記所定の時刻において同時に通知するか否かを決定する
ことを特徴とする請求項1記載の情報通知装置。
【請求項6】
前記通知タイミング制御手段は、前記通知情報蓄積手段に蓄積されたメールの数と、未来に受信するメールの数と、現在以降における前記最大通知数計算手段が算出した最大数とから、前記通知情報蓄積手段に蓄積されたメールと未来に受信するメールの全てが同時に通知できる通知時刻を算出する通知時刻算出手段を有し、前記通知時刻が遅いほど、現在時刻において通知するように決定する
ことを特徴とする請求項5記載の情報通知装置。
【請求項7】
前記情報通知装置は、さらに、
前記ユーザが送信したメールである送信メール情報を取得する送信メール取得手段と、
前記送信メール情報から前記未来のメールの受信時刻を算出するための規則である呼応受信規則を蓄積する呼応受信規則蓄積手段とを備え、
前記未来メール取得部は、前記呼応受信規則を用いて前記送信メール情報から前記未来のメールの受信時刻を算出する
ことを特徴とする請求項1記載の情報通知装置。
【請求項8】
前記送信メール情報には、宛先アドレスと送信時刻が含まれ、
前記呼応受信規則には、差出人アドレスと待ち時間が含まれ、
前記未来メール取得部は、前記送信メール情報に含まれる宛先アドレスに一致する前記差出人アドレスを持つ呼応受信規則に含まれる待ち時間と前記送信メール情報に含まれる送信時刻とから、前記未来メールの受信時刻を算出する
ことを特徴とする請求項7記載の情報通知装置。
【請求項9】
前記情報通知装置は、さらに、前記ユーザの場所を検知する場所検知手段を備え、
前記反応履歴蓄積手段は、前記メールの通知を行ったときの前記時刻検知手段で検知された時刻、前記場所検知手段で検知された場所、および前記反応検知手段で検知された前記ユーザの反応を反応履歴として蓄積し、
前記通知評価値計算手段は、前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻と前記場所とに応じて計算し、
前記通知タイミング制御手段は、前記時刻検知手段で検知された時刻と前記場所検知手段で検知された場所とに応じて、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを決定する
ことを特徴とする請求項1記載の情報通知装置。
【請求項10】
前記通知評価値計算手段は、前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記通知を行ったときのユーザの反応の確率を示す反応確率を前記通知評価値として計算し、
前記通知タイミング制御手段は、前記時刻と前記場所とに対応する通知評価値として前記通知評価値計算手段で計算された反応確率が一定の閾値以上である場合に前記通知をすると決定するとともに、現時点で即座に全てのメールを通知することに対する、前記未来のメールの受信時刻で全てのメールを通知することの利点を計算し、その利点の多いタイミングで前記通知をすると決定する
ことを特徴とする請求項9記載の情報通知装置。
【請求項11】
前記情報通知装置は、さらに、
メールを受信することができるか否かを示すメール受信状況を場所に対応づけたメール受信状況対応表を保持する手段と、
前記ユーザの将来の行動を示す時刻および場所を予測する行動予測手段とを備え、
前記未来メール取得部は、前記行動予測手段による予測に基づいて、未来のメールの受信時刻におけるユーザの位置が前記メール受信状況対応表でメールを受信することができない場所であると予測された場合に、前記行動予測手段による予測に従って、ユーザがメールを受信できる場所に移動する時刻を、前記未来のメールの受信時刻として修正する
ことを特徴とする請求項10記載の情報通知装置。
【請求項12】
受信した電子メールをユーザに通知する情報通知方法であって、
時刻を検知する時刻検知ステップと、
前記メールの通知を行ったときの前記ユーザの反応を検知する反応検知ステップと、
前記メールの通知を行ったときの前記時刻検知ステップで検知された時刻および前記反応検知ステップで検知された前記ユーザの反応を反応履歴として第1蓄積手段に蓄積する反応履歴蓄積ステップと、
前記第1蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻に応じて計算する通知評価値計算ステップと、
前記ユーザに対して通知すべき、外部ネットワーク媒体から受信したメールを第2蓄積手段に複数蓄積する通知情報蓄積ステップと、
現在の時刻以降に外部ネットワーク媒体から受信する未来のメールの受信時刻を取得し、前記時刻検知ステップで検知された時刻に応じて、前記第2蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを、前記通知評価値計算ステップで計算された前記通知評価値と前記未来のメールの受信時刻とを用いて決定する通知タイミング制御ステップと、
前記通知タイミング制御ステップが、前記第2蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知することを決定したときに、前記所定の時刻において、前記第2蓄積手段に蓄積されている全てのメールを同時にユーザに通知する情報通知ステップと
を含むことを特徴とする情報通知方法。
【請求項13】
ユーザに対して電子メールの通知を行うためのプログラムであって、
請求項12記載の情報通知方法に含まれるステップをコンピュータに実行させる
ことを特徴とするプログラム。
発明の詳細な説明
【技術分野】
【0001】
本発明は、ユーザに対して情報の通知を行う情報通知装置に関し、特に状況に応じて、適切なタイミングで受信メールを通知する技術に関するものである。
【背景技術】
【0002】
近年、携帯電話やPC(パーソナルコンピュータ)、情報家電を通じて、ユーザにニュースや広告、生活情報といった文字情報や動画情報をPUSH型で提供する装置が多くなってきている。将来的には、ユーザが携帯するモバイル装置が、ユーザに対して自発的にインタラクションを開始し、情報やサービスを提供するようになるだろう。今後、このように装置がユーザに対して自発的に情報を提供するということは、ますます一般的になってくる。
【0003】
装置がユーザに対して装置の側から情報を提供する際、外部のネットワークや情報発信基地局から受け取った情報を、即座にユーザに通知していては、ユーザに気づいてもらえないことがある。例えば、もしユーザが忙しいときに、装置がショッピング情報の通知を行ったとしても、ユーザは通知に気づかないことが多い。たとえ気づいたとしても、ユーザは嫌な思いをする。例えば、ショッピング情報はユーザが忙しいときではなく、ユーザが家から外に出かけるときなどに通知を行うと、ユーザに好まれることが多い。よって、外部から受け取った情報を即座に通知するのではなく、受け取った情報を一旦装置に記憶し、ユーザにとって通知が好ましいタイミングになったときに情報を通知する必要がある。つまり、ユーザにいつ、どのような情報を告げ知らせるか、つまり情報通知のタイミングが重要となる。
【0004】
そこで、従来、ユーザの情報閲覧行動から学習を行い、ユーザの場所や時間帯に応じて異なる情報を提供することが提案されている(例えば、非特許文献1参照。)。
【0005】
また、ユーザの情報参照状況を用いることで、時間帯に応じて提供する情報を変更することも提案されている(例えば、特許文献1参照。)。
【0006】
さらに、好ましいタイミングに情報を通知するだけではなく、通知する情報の量、例えば、携帯電話などの携帯端末においてユーザに通知するメールの数を調整することも重要である。いくら通知が好ましいタイミングとはいえ、ユーザに非常に多くのメールを一度に送られてもユーザは読みきれない場合がある。しかも読みきれるメールの数は状況によって異なる。
【0007】
そこで、従来、キーボードのストローク頻度、カーソル移動頻度、脳波から提示する情報の抽象度を変更するということがなされている(例えば、特許文献2参照。)。具体的には状況から推測したユーザの集中度が高いときには、情報の見出しのみを提示するということがなされている。
【非特許文献1】二瓶克己,茶園篤,伊東紀子:モバイル情報配信プラットフォームTPOCAST−松江観光GIS実証実験結果報告−,情報処理学会第63回全国大会,2R−3・4,2001.
【特許文献1】特開2000−099525号公報
【特許文献2】特許2697590号公報
【発明の開示】
【発明が解決しようとする課題】
【0008】
しかしながら、上記非特許文献1の技術では、情報通知のタイミングに関しては、情報提供者が予め作成したルールやユーザからの情報要求に従っている。そのために、情報提供者やユーザの負担が大きいという問題がある。
【0009】
たとえば、12時に飲食店の情報を通知するようにしたとしても、12時に昼食をとるユーザもいれば、15時に昼食をとるユーザもいる。また、23時に寝るユーザもいれば、午前3時に寝るユーザもいる。つまり、ユーザそれぞれにおいて適切な通知タイミングは異なる。情報提供者がユーザそれぞれに対して適切なルールを作成することが考えられるが、ユーザの数は莫大であり、情報提供者が個々のルールを作成することは不可能である。かといってユーザ自身が、いつどのような情報を通知されればよいかといったルールを作成することは、ユーザにとって非常に負担が大きい。
【0010】
また、上記特許文献1の技術では、状況に応じて情報の内容が変更されるものの、適切なタイミングで情報が提供されるものではないという問題がある。つまり、この従来技術は、新幹線のLED広告のように四六時中絶えず情報を表示するものであり、通知という概念が存在しない。つまり、この従来技術は、状況に応じて情報内容を変更しているだけで、装置が通知タイミングを学習し、制御しているわけではない。
【0011】
ここで、適切なタイミングで情報を提供する方法として、ユーザの履歴データを用いて、いつどのような情報を通知すればよいかを装置が自動的に推定することが考えられる。例えば、ブラウザでユーザが7時にスポーツ情報を閲覧したという履歴があったとき、ユーザが何も操作をしなくても、7時にスポーツ情報を通知すればよい。
【0012】
しかしながら、ブラウザ閲覧するといったユーザの能動的な情報要求動作の履歴だけでは、テレビの字幕による情報通知など、ユーザが受動的に情報を受け取るようなPUSH型情報提供装置の大半において適用することはできないという問題がある。また、情報要求動作が行われた時刻を通知タイミング学習に用いるだけでは、全ての時刻や情報内容を網羅できず、不十分である。例えば、ユーザが7時にスポーツ情報を要求したとすると、装置は7時に情報を通知することしかできず、ユーザからの情報要求動作がない限り、ユーザが情報を欲しがっていたとしても、8時にスポーツ情報を通知することはできない。つまり、通知する時刻や情報内容に偏りを生じてしまう。ユーザが情報を通知されたいと考えている時刻と情報内容を全て装置に学習させるためには、ユーザは全ての時刻において、その時刻で欲する全ての情報内容について、情報要求動作を行わなければならないため、手間も時間もかかる。
【0013】
また、時刻だけでは、通知すべきか否かを判別できない場合がある。例えば、同じ7時でも家にいるときは情報を通知して欲しいかもしれないが、7時に会社にいるときは仕事中で情報を通知して欲しくないかもしれない。このため、時刻に加えて場所情報も通知タイミング制御に用いる必要がある。また、7時に会社にいるときは仕事中で情報を通知して欲しくないかもしれないが、12時に会社にいるときは昼休みで情報を通知して欲しいかもしれない。つまり7時である、会社にいるという情報だけでは通知の可否が判断できず、7時に会社にいるという情報、つまり時刻と場所の組み合わせ情報が必要になる。つまり、情報通知のタイミングを装置に学習させるためには、ユーザが通知をして欲しい時刻と場所のそれぞれの組み合わせにおいて、その状況において通知して欲しい全ての情報内容について、情報を要求する必要があり、とても人の手でできるものではない。
【0014】
さらに、特許文献2では、ユーザのタスクの集中度が高いときに一つの情報について抽象度を上げるということはできているが、情報の数、具体的には、携帯端末におけるメールの数(受信しているが未閲覧の状態で蓄積されているメールの数)には対応していないという問題がある。
【0015】
実際にユーザがタスクを行っている画面上に一通のメールを提示する場合、タイトルだけ提示するか、本文も含めて提示するかはタスクの集中度によって変化できるかもしれない。しかし、携帯端末に対して一通だけメールを通知されることを好むか、十通のメールを通知されることを好むかはタスクの集中度にはよらない可能性が高い。なぜなら、一通のメールが来ることも、十通のメールが来ることも、携帯端末の振動や音、光などの通知により、ユーザのタスクを妨げられることには変わらないからである。よって、通知回数を減らすために、どこまでメールを同時に通知するか、どのタイミングでメールを同時に通知するかといったことが重要になる。そもそも、携帯端末においては、ユーザがキーボードやカーソルを動かしてなくてもタスクに集中している可能性があるため、集中度を計測することもできない。
【0016】
そこで、本発明は上記の事情に鑑みてなされたものであり、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングと通知する情報の量とを適切に制御することができる情報通知装置および情報通知方法を提供することを目的とする。
【課題を解決するための手段】
【0017】
上記目的を達成するため、本発明に係る情報通知装置は、受信した電子メールをユーザに通知する情報通知装置であって、時刻を検知する時刻検知手段と、前記メールの通知を行ったときの前記ユーザの反応を検知する反応検知手段と、前記メールの通知を行ったときの前記時刻検知手段で検知された時刻および前記反応検知手段で検知された前記ユーザの反応を反応履歴として蓄積する反応履歴蓄積手段と、前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻に応じて計算する通知評価値計算手段と、前記ユーザに対して通知すべき、外部ネットワーク媒体から受信したメールを複数蓄積する通知情報蓄積手段と、現在の時刻以降に外部ネットワーク媒体から受信する未来のメールの受信時刻を取得する未来メール取得部を有し、前記時刻検知手段で検知された時刻に応じて、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを、前記通知評価値計算手段で計算された前記通知評価値と前記未来のメールの受信時刻とを用いて決定する通知タイミング制御手段と、前記通知タイミング制御手段が、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知することを決定したときに、前記所定の時刻において、前記通知情報蓄積手段に蓄積されている全てのメールを同時にユーザに通知する情報通知手段とを備えることを特徴とする。
【0018】
また、本発明は、このような情報通知装置として実現することができるだけでなく、このような情報通知装置が備える特徴的な手段をステップとする情報通知方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、CD−ROM等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。
【発明の効果】
【0019】
本発明に係る情報通知装置および情報通知方法によれば、ユーザが特にルールを定めなくても、ユーザにとって通知が好ましいタイミングになったときに、それまでに蓄積された全てのメールが同時に通知される。
【0020】
よって、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングと通知する情報の量とが適切に制御され、ユーザは、都合のよいタイミングで、それまで蓄積された受信メールをまとめて閲覧することができる。
【0021】
また、ユーザの情報要求を用いることができないメディアにおいても、通知に対するユーザの反応履歴に基づくことで、ユーザにとって適切なタイミングに適切な量の情報が通知される。
【0022】
また、反応履歴を用いることで、いつどのような情報を通知すればよいかという通知タイミングを修正することができる。
【0023】
また、修正規則と反応履歴を用いることで、学習データが少ないときにおいても、ユーザの嫌がらないタイミングを推測し、装置の側から自発的にユーザに情報を通知することができる。
【発明を実施するための最良の形態】
【0024】
本発明に係る情報通知装置は、受信した電子メールをユーザに通知する情報通知装置であって、時刻を検知する時刻検知手段と、前記メールの通知を行ったときの前記ユーザの反応を検知する反応検知手段と、前記メールの通知を行ったときの前記時刻検知手段で検知された時刻および前記反応検知手段で検知された前記ユーザの反応を反応履歴として蓄積する反応履歴蓄積手段と、前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻に応じて計算する通知評価値計算手段と、前記ユーザに対して通知すべき、外部ネットワーク媒体から受信したメールを複数蓄積する通知情報蓄積手段と、現在の時刻以降に外部ネットワーク媒体から受信する未来のメールの受信時刻を取得する未来メール取得部を有し、前記時刻検知手段で検知された時刻に応じて、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを、前記通知評価値計算手段で計算された前記通知評価値と前記未来のメールの受信時刻とを用いて決定する通知タイミング制御手段と、前記通知タイミング制御手段が、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知することを決定したときに、前記所定の時刻において、前記通知情報蓄積手段に蓄積されている全てのメールを同時にユーザに通知する情報通知手段とを備えることを特徴とする。
【0025】
これにより、情報通知に対するユーザの反応履歴に基づいて情報通知のタイミングが決定されるとともに、蓄積された複数のメールを同時に通知するのが好ましいか否かも判断されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングと通知する情報の量とが適切に制御される。
【0026】
ここで、前記通知タイミング制御手段は、前記時刻検知手段で検知された現在の時刻以降の前記通知評価値を用いて、前記通知情報蓄積手段に蓄積されている全てのメールを前記所定の時刻において同時に通知するか否かを決定するのが好ましい。将来の時刻において通知する場合の適切度合が考慮されるからである。
【0027】
具体的には、前記所定の時刻とは現在時刻であり、前記通知タイミング制御手段は、前記未来のメールの受信時刻が遅いほど現在時刻において通知するように決定したり、前記通知タイミング制御手段は、前記通知情報蓄積手段に蓄積されたメールの数が多いほど現在時刻において通知するように決定するのが好ましい。
【0028】
また、前記情報通知装置は、さらに、前記通知評価値から、前記時刻検知手段で検知された時刻に応じて、同時に通知できるメールの最大数を計算する最大通知数計算手段を備え、前記通知タイミング制御手段は、前記情報蓄積部に蓄積されたメールの数が、前記最大通知数計算手段で計算された前記時刻における前記最大数を上回った場合に、前記通知情報蓄積手段に蓄積されているメールのうち、前記最大数のメールを前記所定の時刻において同時に通知するか否かを決定する構成としてもよい。このとき、前記通知タイミング制御手段は、前記通知情報蓄積手段に蓄積されたメールの数と、未来に受信するメールの数と、現在以降における前記最大通知数計算手段が算出した最大数とから、前記通知情報蓄積手段に蓄積されたメールと未来に受信するメールの全てが同時に通知できる通知時刻を算出する通知時刻算出手段を有し、前記通知時刻が遅いほど、現在時刻において通知するように決定するのが好ましい。
【0029】
これにより、蓄積されたメールが通知可能な最大数を超えた場合にも、通知可能な最大数を超えることなく、適切なタイミングで、まとめて受信メールを閲覧することができる。
【0030】
また、前記情報通知装置は、さらに、前記ユーザが送信したメールである送信メール情報を取得する送信メール取得手段と、前記送信メール情報から前記未来のメールの受信時刻を算出するための規則である呼応受信規則を蓄積する呼応受信規則蓄積手段とを備え、前記未来メール取得部は、前記呼応受信規則を用いて前記送信メール情報から前記未来のメールの受信時刻を算出してもよい。たとえば、前記送信メール情報には、宛先アドレスと送信時刻が含まれ、前記呼応受信規則には、差出人アドレスと待ち時間が含まれ、前記未来メール取得部は、前記送信メール情報に含まれる宛先アドレスに一致する前記差出人アドレスを持つ呼応受信規則に含まれる待ち時間と前記送信メール情報に含まれる送信時刻とから、前記未来メールの受信時刻を算出する。
【0031】
また、前記情報通知装置は、さらに、前記ユーザの場所を検知する場所検知手段を備え、前記反応履歴蓄積手段は、前記メールの通知を行ったときの前記時刻検知手段で検知された時刻、前記場所検知手段で検知された場所、および前記反応検知手段で検知された前記ユーザの反応を反応履歴として蓄積し、前記通知評価値計算手段は、前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記ユーザにメールを通知することが適切であるか否かを示す通知評価値を前記時刻と前記場所とに応じて計算し、前記通知タイミング制御手段は、前記時刻検知手段で検知された時刻と前記場所検知手段で検知された場所とに応じて、前記通知情報蓄積手段に蓄積されている全てのメールを所定の時刻において同時に通知するか否かを決定してもよい。具体的には、前記通知評価値計算手段は、前記反応履歴蓄積手段に蓄積されている前記反応履歴に基づいて、前記通知を行ったときのユーザの反応の確率を示す反応確率を前記通知評価値として計算し、前記通知タイミング制御手段は、前記時刻と前記場所とに対応する通知評価値として前記通知評価値計算手段で計算された反応確率が一定の閾値以上である場合に前記通知をすると決定するとともに、現時点で即座に全てのメールを通知することに対する、前記未来のメールの受信時刻で全てのメールを通知することの利点を計算し、その利点の多いタイミングで前記通知をすると決定する。
【0032】
これにより、時刻だけでなく、ユーザの場所をも考慮して、通知タイミングの適切度合が判断されるので、よりユーザにとって都合のよい状況で、受信メールがあったことが通知される。
【0033】
また、前記情報通知装置は、さらに、メールを受信することができるか否かを示すメール受信状況を場所に対応づけたメール受信状況対応表を保持する手段と、前記ユーザの将来の行動を示す時刻および場所を予測する行動予測手段とを備え、前記未来メール取得部は、前記行動予測手段による予測に基づいて、未来のメールの受信時刻におけるユーザの位置が前記メール受信状況対応表でメールを受信することができない場所であると予測された場合に、前記行動予測手段による予測に従って、ユーザがメールを受信できる場所に移動する時刻を、前記未来のメールの受信時刻として修正するのが好ましい。これにより、電波状況の悪い場所にいる等のために、予定された受信時刻にメールができないケースも考慮したうえで、通知タイミングが決定される。
【0034】
以下、本発明の各実施の形態について、それぞれ図面を参照しながら詳細に説明する。
【0035】
なお、本願請求項1に係る発明に最も近い実施の形態は、実施の形態11である。実施の形態11は、多くの構成要素からなるので、本明細書では、理解を容易にするために、実施の形態11の一部の構成要素からなる他の実施の形態1〜10を先に説明する。
【0036】
(実施の形態1)
まず、本発明の実施の形態1に係る情報通知装置を説明する。
【0037】
図1は、本発明の実施の形態1に係る情報通知装置の構成を示すブロック図である。
【0038】
情報通知装置は、例えば携帯電話や情報携帯端末等の機器に備えられてユーザに対して情報の通知を行うための装置であり、図1に示されるように、時刻検知部100、場所検知部101、反応検知部102、反応履歴蓄積部103、通知評価値計算部110、反応確率計算部104、修正規則蓄積部105、通知評価値修正部111、反応確率修正部106、通知情報蓄積部107、通知タイミング制御部108、および情報通知部109を備えている。
【0039】
時刻検知部100は、情報通知装置内の時計等により、現在の時刻情報を常に検知する。検知された時刻情報は、反応検知部102、反応履歴蓄積部103、通知タイミング制御部108に送られる。
【0040】
場所検知部101は、例えばGPS(Global Positioning System)装置またはICタグ等により、ユーザが存在する場所を検知する。ここで、経度、緯度の情報を検知しても良いし、「大阪」「会社」「車内」など、場所を判別するラベルを検知しても良い。また、「大阪」かつ「梅田」かつ「車内」など場所を表すラベルを複数検知しても良い。
【0041】
反応検知部102は、情報の通知に対するユーザの反応をユーザの情報通知装置に対する操作により検知する。例えば、時刻検知部100により時刻情報を取得することで、情報通知部109が通知した時刻から、ユーザが通知モダリティを止める時刻までの反応時間を反応として検知する。ここで、通知モダリティとは、通知音、バイブレーションといったユーザに通知を行う際の手段となるものである。ユーザが通知モダリティを止めなかったときは、反応なしと検知する。なお、ユーザが初めて情報通知装置を手に取る時刻までの反応時間、ユーザが情報内容を確認する時刻までの反応時間を反応として検知しても良い。
【0042】
反応履歴蓄積部103は、情報通知部109が情報の通知を行ったときに時刻検知部100で検知された時刻と、情報の通知を行ったときに場所検知部101で検知されたユーザの場所と、反応検知部102で検知されたユーザの反応を蓄積する。例えば、図2に示されるように、情報を識別する履歴ID、この情報に関する通知時刻と通知場所、反応時間の組を反応履歴として蓄積する。
【0043】
通知評価値計算部110は、反応履歴蓄積部103に蓄積されている反応履歴から、あるタイミングで通知することが適切かどうかを示す通知評価値、つまり通知タイミングに関する通知評価値を計算する。そして、通知時刻と通知場所とから構成された条件ごとの通知評価値を記録した通知評価値テーブルを作成する。通知評価値計算部110の一つとして、反応確率計算部104がある。
【0044】
反応確率計算部104は、反応履歴蓄積部103に蓄積されている反応履歴から、情報の通知を行ったときのユーザの反応の確率を示す反応確率を計算する。例えば、通知に対する反応時間が通知音、バイブなどの通知モダリティが再生される時間より短い反応履歴を「反応あり」、長い反応履歴を「反応なし」として、反応確率を計算する。つまり、通知モダリティとしてA曲が再生され、A曲の再生時間が3分であった場合、反応時間が3分未満ならば「反応あり」、3分以上ならば「反応なし」とする。ここで、反応確率とは、「反応あり」の履歴データ数を全履歴データ数で割ったものである。
【0045】
図3は反応確率テーブルを作成する例を示す図である。図3(a)において横軸は時間、縦軸は場所を示し、○は反応あり、×は反応なしを示している。図3(a)に示す例の場合、条件「時刻(11時〜13時)かつ場所(会社(デスク))」における「反応あり」の履歴データ数は3個であり、条件「時刻(11時〜13時)かつ場所(会社(デスク))」における全履歴データ数は○が3個、×が1個の4個である。よって、条件「時刻(11時〜13時)かつ場所(会社(デスク))」における反応確率は0.75(3/4)になる。反応確率計算部104は、このように場所と時刻のAND条件ごとに反応確率を計算することで、図3(b)に示されるような反応確率テーブルを作成する。なお、本実施の形態では、通知評価値テーブルとは、反応確率計算部104で作成された反応確率テーブルのことである。
【0046】
修正規則蓄積部105は、通知評価値計算部110で作成された通知評価値テーブルを更新する修正規則を蓄積する。この修正規則としては、例えば後述する、反応履歴の少ない部分を汎化した反応確率を用いて、反応履歴の少ない部分の反応確率を推定する汎化条件利用規則が存在する。
【0047】
通知評価値修正部111は、修正規則蓄積部105の修正規則を利用して、通知評価値計算部110で作成された通知評価値テーブルを修正する。通知評価値修正部111として、例えば反応確率修正部106がある。
【0048】
反応確率修正部106は、修正規則蓄積部105の修正規則を利用して、反応確率計算部104で作成された反応確率を修正する。
【0049】
汎化条件利用規則は、例えば履歴データが存在しないか、少ない条件において、条件を汎化し、汎化した条件下における反応確率を用いて、汎化前の条件下における反応確率を更新するという規則である。これにより、履歴が存在しない条件下においても通知の可否を判断することができる。
【0050】
例えば図4(a)に示されるような反応確率テーブルが存在した場合、条件「時刻(11時〜13時)かつ場所(会社(会議室))」に適合する状況において、条件を汎化し、条件「場所(会社(会議室))」を作成する。汎化した条件「場所(会議室)」における反応確率「0.0」(場所(会議室)における反応ありデータ数/場所(会議室)における履歴データ数)を用いて、汎化前の条件「時刻(11時〜13時)かつ場所(会社(デスク))」下における反応確率を更新する。例えば汎化した条件下の反応確率をそのまま用いて図4(b)に示されるように「0.0」に更新する。
【0051】
反応確率修正部106は、例えば図5(a)に示されるような反応確率テーブルに対して、このように修正規則「汎化条件利用規則」を適用して反応確率を更新し、場所に関する条件で汎化した図5(b)に示されるような反応確率テーブルを作成する。
【0052】
通知情報蓄積部107は、ユーザに対して通知する情報を蓄積する。すなわち、通知情報蓄積部107は、例えば図6に示されるように、情報を識別する「情報ID」、当該情報の発信元を表す「配信元(情報発信者)」、例えばタイトルのような当該情報内容を簡単に表す「情報ヘッダ」、当該情報内容の特徴を表す「ジャンル」、実際にユーザに伝えるべき当該情報内容の詳細を表す「情報内容」を蓄積する。情報は例えばインターネットや情報発信基地局などの外部ネットワーク媒体120から通知情報蓄積部107に提供される。ここで、外部ネットワーク媒体120から情報が提供されるのではなく、通知情報蓄積部107が予めユーザに通知すべき情報を持っていても良い。
【0053】
通知タイミング制御部108は、反応確率修正部106によって修正された反応確率テーブルを記憶する。時刻検知部100で検知された現在時刻、場所検知部101で検知された現在場所と、記憶している反応確率テーブルを用いて、通知情報蓄積部107に蓄積された情報の通知タイミングを制御し、当該情報を情報通知部109に出力する。
【0054】
具体的には、通知タイミング制御部108は、時刻検知部100で検知された現在時刻もしくは場所検知部101で検知された現在場所が変化したときに、現在の時刻と場所を条件としたときの反応確率に従って、情報を情報通知部109に出力する。例えば、図7に示されるように、現在の状況が時刻9時、場所が会社(デスク)であった場合、修正された反応確率テーブル中、条件「時刻(9時〜11時)かつ場所(会社(デスク))」に対応する反応確率「0.6」に従い、例えば0.6の確率で情報の通知を決定し、通知情報蓄積部107に蓄積された情報を情報通知部109に出力する。
【0055】
情報通知部109は、通知タイミング制御部108から入力された情報をユーザに通知する。例えば、図8に示されるように、情報通知装置を備えた携帯電話1に情報を表示させる場合、通知タイミング制御部108によって決定された通知タイミングで、携帯電話から音等によりユーザへ通知を行い、通知タイミング制御部108から出力された情報を表示する。
【0056】
次に、上記のように構成された情報通知装置の動作について説明する。
【0057】
図9は情報通知装置の動作の流れを示すフローチャートである。ここでは、通知タイミング制御部108が記憶する反応確率テーブルの初期値は装置設計者が予め定めておくものとする。なお、初期値は、ランダム値でも良いが、一般的なユーザの反応履歴から、図10に示す反応確率テーブル更新フローにより、予め理想的な反応確率テーブルを作成しておいても良い。
【0058】
通知タイミング制御部108は、現在の状況、つまり時刻検知部100で検知された現在時刻と場所検知部101で検知された現在場所を監視し、現在の状況が変化したか否かを判断する(ステップS901)。現在の状況が変化しない場合(ステップS901でNO)は、そのまま監視を続ける。
【0059】
一方、現在の状況が変化した場合(ステップS901でYES)、すなわち時刻もしくは場所の変化を検知すると、通知情報蓄積部107に蓄積された情報について、通知タイミング制御部108は、自身が記憶している反応確率テーブルを参照し、時刻検知部100で検知された現在時刻と場所検知部101で検知された現在場所を条件とした反応確率に従って、通知の可否を判断する(ステップS902)。
【0060】
そして、通知タイミング制御部108が情報の通知の可否を判断した結果、通知不可であった場合(ステップS903でNO)は、現在の状況の監視を行う(ステップS901)。一方、通知タイミング制御部108が情報の通知の可否を判断した結果、通知可であった場合(ステップS903でYES)は、通知タイミング制御部108は、通知が決定した情報を情報通知部109に出力し、情報通知部109が通知音やバイブなどの通知モダリティによって、ユーザに情報を通知する(ステップS904)。
【0061】
次に、反応確率修正部106は、通知した情報に対するユーザの反応情報を用いて、通知タイミング制御部108が記憶している反応確率テーブルを更新する(ステップS905)。詳細は後で図10のフローチャートを用いて述べる。
【0062】
そして、装置の動作を終了しない場合(ステップS906でNO)は、現在の状況の監視を行う(ステップS901)。終了する場合(ステップS906でYES)はフローを終了する。
【0063】
次に、情報通知後におけるユーザの反応を用いた反応確率テーブル更新動作を図10のフローチャートを用いて説明する。
【0064】
反応検知部102は、情報を通知したときのユーザの反応を検知する(ステップS1001)。ここで、反応検知部102は、一定時間待って、反応がなかった場合も、「反応なし」を検知したことにする。
【0065】
次に、反応検知部102は、時刻検知部100で検知された情報の通知を行った時刻から当該通知に対する反応があった時刻までの時間を計測し、情報通知を行ったときの時刻と、情報通知を行ったときに場所検知部101が検知した場所と共に、反応履歴蓄積部103に登録する(ステップS1002)。
【0066】
反応確率計算部104は、反応履歴蓄積部103に蓄積されている反応履歴から、反応確率を計算し、反応確率テーブルを生成する(ステップS1003)。次に、反応確率修正部106は、修正規則蓄積部105に蓄積されている修正規則を用いて、反応確率計算部104で生成された反応確率テーブルを修正する(ステップS1004)。そして、反応確率修正部106によって修正された反応確率テーブルによって、通知タイミング制御部108が記憶している反応確率テーブルを更新する(ステップS1005)。
【0067】
以上の動作により、ユーザの情報通知の反応履歴から、ユーザが情報を閲覧できるタイミングを制御した情報通知を実現することができるようになる。また、汎化条件利用規則を用いることにより、少ない反応履歴でも、履歴のない条件における反応確率を推定することができるため、学習が早く、局所解に陥らないという利点がある。例えば、PUSH型配信により、店やニュースなどの生活情報がユーザのGPS付き携帯に配信され、通知される装置があったとする。ユーザは自分から情報を要求しなくても、通知された情報を、都合がいい場合に見るだけで、すぐに装置がユーザの都合のいい時間にだけ通知してくれるようになる。汎化条件利用規則を使わないと、装置が通知した条件における通知の可否しかわからない。このため、装置は局所解に陥り、ユーザがそれほど都合の良くない条件で通知するようになる。例えば、13時に家にいるときに生活情報をユーザに通知したときに、ユーザの反応があったとする。すると、装置は13時に家にいるときは通知するが、12時に家にいるときは通知しない。本当は、同じ家にいるときにでも13時より12時に生活情報を通知して欲しいとユーザが思っていたとしても、局所解に陥り、13時に家にいるときにしか通知しないようになる。しかし、汎化条件利用規則を用いることで、12時に家にいるときでも装置が反応を推定して通知を行い、13時に家にいるときよりも反応確率がより高いことを知り、12時に家にいるときに通知を行うことができる。
【0068】
また、ユーザに情報を通知しても良い条件は本来、数多く存在するものである。しかし、汎化条件利用規則を用いないと、装置は局所解に陥り、装置が過去に情報を通知して反応があった条件のときしか情報を通知しないようになる。図4の反応履歴テーブルを利用して説明する。汎化条件利用規則を用いないと、反応確率が高い条件、例えば反応確率「1.0」の時刻(7時〜9時)かつ場所(家)と、反応確率「0.75」の時刻(11〜13時)かつ場所(デスク)のときしか情報を通知しないようになってしまう。しかし、例えば時刻(7時〜9時)かつ場所(デスク)の場合に情報を通知することがユーザにとって最も都合がいいかもしれない。汎化条件利用規則を用いると、時刻(7時〜9時)かつ場所(デスク)の場合においても反応確率は「0.6」と推定し、通知する。これにより、反応履歴を得て、時刻(7時〜9時)かつ場所(デスク)に通知すると反応が最も良いと学習することができる。ランダム通知により学習を行うことでは、時刻(17時〜19時)かつ場所(車)といったユーザにとって通知して欲しくないと思われる場所でも実際に通知を行ってみないと、ユーザにとって都合が悪いことを学習できない。
【0069】
(変形例1)
上記のように実施の形態1では、通知評価値計算部110は反応確率計算部104を含み、反応履歴から通知に対する反応確率を計算することにより、反応確率テーブルつまり、通知評価値テーブルを作成したが、通知タイミング制御部108が通知の判断に用いる通知評価値は反応確率でなくてもよい。
【0070】
つまり、ユーザの反応の良さに応じて反応度を計算し、反応度により反応度テーブルを作成しても良い。図11は、本発明の実施の形態1に係る情報通知装置の変形例1の構成を示すブロック図である。
【0071】
具体的には、図11に示されるように、実施の形態1における反応確率計算部104と反応確率修正部106を、反応度計算部1504と反応度修正部1506に置き換えることで実現できる。もちろん反応度も通知評価値の一つであり、通知評価値に含まれる。ここでは、通知評価値テーブルとは、反応度計算部1504で作成された反応度テーブルのことである。
【0072】
例えば、ユーザが通知に対して、同じ通知音を止める反応をしたとしても、10秒で反応したときと100秒で反応したときでは、通知タイミングの適切さが異なる。よって、反応度計算部1504は、例えば反応履歴の反応時間の平均の逆数をとることで、反応度を算出する。そして、反応度計算部1504は、時刻と場所の条件ごとに反応度を算出し、反応度テーブルを作成する。反応履歴蓄積部103に例えば図12(a)に示されるような反応履歴が蓄積されていた場合、反応度計算部1504は、図12(b)に示されるように、反応度テーブルを作成し、保存する。図12の場合、条件「時刻(7時〜9時)&場所(家)」における反応時間の平均は15秒{=(10+20)/2}である。よって反応時間の平均の逆数である1/15を反応度とする。
【0073】
反応がなかった場合は、反応時間を通知モダリティの再生時間とする。例えば、情報通知において通知音が1000秒再生される場合は、1000秒を再生時間とする。図12の場合、条件「時刻(11時〜13時)かつ場所(会議室)」における反応時間の反応度は1/1000{=1/1000}である。
【0074】
反応度修正部1506は、実施の形態1と同様に修正規則蓄積部105に蓄積された規則に従って反応度テーブルを更新する。反応履歴が図12(a)に示されるように蓄積されていた場合、図13(a)に示されるように、条件「時刻(9時〜11時)かつ場所(家)」における反応度を求めたい場合は、汎化条件利用規則を用いる。汎化した条件「場所(家)」における反応度は、条件「場所(家)」において反応時間が10秒、20秒、60秒の3つの履歴があることから、反応時間の平均30{=(10+20+60)/3}の逆数である1/30である。汎化した条件「場所(家)」における反応度1/30であることから、条件「時刻(9時〜11時)&場所(家)」における反応度は1/30となる。反応度修正部1506は、上記同様に履歴がない各条件について汎化を行い、図13(b)に示されるように、反応度テーブルを更新する。
【0075】
通知タイミング制御部1508は、反応度修正部1506が更新した反応度テーブルに従って、通知情報蓄積部に蓄積された情報の通知の可否を判断し、通知する情報を情報通知部に出力する。例えば、現在の時刻と場所に対応する反応度が反応度テーブルの反応度の平均以上であった場合、情報を情報通知部109に出力する。
【0076】
例えば、図14の場合、条件「時刻(7時〜9時)かつ場所(家)」において、反応度は1/15であり、反応度のテーブルにおける平均値、0.059{=(1/15+7×1/30+1/60+9×1/600+9×1/1000+9×1/5)/36}以上であることから、通知は可となり、情報を情報通知部109に出力する。
【0077】
これにより、反応時間が60秒と大きい「時刻(15時〜17時)かつ場所(家)」には通知を行わず、より通知タイミングが望ましいと考えられる反応時間が15秒と小さい「時刻(7時〜9時)かつ場所(家)」において通知を行うことが可能になる。
【0078】
このように、修正規則による通知評価値テーブルの修正による通知タイミング制御は、反応確率以外を通知評価値としても有効である。
【0079】
(変形例2)
なお、本実施の形態1および本実施の形態1の変形例1において、反応履歴として蓄積する情報を増やし、それにより、通知評価値テーブルの次元を増やしてもよい。これにより、よりユーザの状況に応じた通知タイミング制御が可能になる。例えば、反応履歴を蓄積する際、時刻情報を詳細化して、「曜日」、「平日or休日」、「上旬or中旬or下旬」、「年」、「月」、「季節」といった情報を用いてもよい。例えば、「曜日」情報を用いて通知評価値テーブルの次元を増やす場合、反応履歴蓄積部103は、図15に示されるように、「曜日」情報を加えて蓄積する。「曜日」情報は時刻検知部100が装置内のタイマーにより、検知する。通知評価値計算部110は、例えば図16に示されるように、曜日と時刻と場所のAND条件ごとに通知評価値を計算し、保存する。例えば図16(a)、(b)に示されるように、通知評価値として反応確率をとるとき、条件「曜日(月曜日)かつ時刻(7時〜9時)かつ場所(家)」における「反応あり」履歴データ数は2個、全履歴データ数は○が2個の計2個であることより、通知評価値は1.0(=2/2)になる。このように、実施の形態1と同様に条件ごとに通知評価値を計算するとことで、図16(c)に示されるような通知評価値テーブルを作成する。通知タイミング制御部108は、通知評価値テーブルを参照し、現在の曜日と時刻と場所に対応する通知評価値に基づいて、通知の可否を決定する。例えば、条件「曜日(月曜日)かつ時刻(7時〜9時)かつ場所(家)」における通知評価値が1.0であった場合。1.0の確率で情報を情報通知部109に出力する。
【0080】
これにより、例えば図15、16に示されるように、会社に行く前に食事をしている月曜日の朝7時の家では反応確率1.0のため情報を通知するが、ユーザが寝ていて通知に反応できない日曜日の朝7時の家では反応確率0.0のため情報を通知しないということが可能になる。
【0081】
(変形例3)
なお、実施の形態1や実施の形態1の変形例1では、通知のきっかけとなるユーザの状況の変化の種類に係わらず、通知評価値テーブルは共通のものであった。つまり通知のきっかけが時刻変化でも場所変化でも反応履歴は区別せず、通知評価値テーブルも同一のものであった。しかし、これらを区別し、場所変化、時刻変化という通知のきっかけとなった状況変化の種類によって別々に通知評価値テーブルを作成しても良い。これにより、ユーザ状況に時刻しか変化がなかったときは通知しないが、場所変化という何らかのイベントが起こった場合にのみ情報を通知するということが可能になる。今後、通知のきっかけとなったユーザの状況変化を通知開始イベントと呼ぶ。
【0082】
例えば、時刻(11時〜13時)かつ場所(会議室)に情報を通知したときの反応確率が0.5であったとする。しかし、この反応確率0.5には、時刻が11時になったことをきっかけとして情報を通知したときの反応履歴も、場所が(会議室)になったことをきっかけに情報を通知したときの反応履歴の双方とも含まれている。しかし、もしかするとユーザは会議室に入った直後だけは、会議がまだ始まっていないため情報の通知を好むが、10時からずっと会議室にいた場合は、11時にも会議中で通知を好まないかもしれない。こういった場所変化の直後だけ通知を好むといった状況も考えられる。通知開始イベントごとに通知評価値テーブルを作成することによって、会議室に前からいて時刻が11時になったときは通知しないが、時刻11時から13時の間に会議室に入ってきたときは通知をするといった処理が可能になる。
【0083】
具体的に動作を説明する。反応履歴蓄積部103は、例えば図17に示されるように、「通知開始イベント」情報を加えて履歴を蓄積する。通知評価値計算部110は、例えば、図18に示されるように、「通知開始イベント」と時刻と場所のAND条件ごとに通知評価値を計算し、保存する。図18(a)、(b)に示されるように、通知評価値として反応確率をとるとき、条件「通知開始イベント(場所変化)かつ時刻(11時〜13時)かつ場所(会議室)」における「反応あり」履歴データ数は1個、全履歴データ数は○が1個の計1個であることより、通知評価値は1.0(=1/1)になる。このように、実施の形態1と同様に条件ごとに通知評価値を計算するとことで、図18(c)、(d)に示されるような時刻変化および場所変化ごとに通知評価値テーブルを作成する。通知タイミング制御部108は、ステップS901で述べたように、現在の状況、つまり時刻検知部100が検知した現在時刻と場所検知部101が検知した現在場所を監視する。通知開始イベントである時刻か場所の変化を検知したときに、通知評価値テーブルを参照し、現在の時刻と場所と通知開始イベントに対応する通知評価値に基づいて、通知の可否を決定する。例えば、条件「通知開始イベント(場所変化)かつ時刻(11時〜13時)かつ場所(会議室)」における通知評価値が1.0であった場合。1.0の確率で情報を情報通知部109に出力する。
【0084】
これにより、例えば図17、18に示されるように、通知評価値テーブルが作成されていた場合、ユーザが会議室に以前からおり、時刻が11時になったときは反応確率が0.0のため通知しないが、時刻11時から13時の間に会議室に入ってきたときは反応確率が1.0のため通知をするといった処理が可能になる。
【0085】
上記のように実施の形態1では、反応履歴は通知があったときの場所のみを記録し、通知の可否も現在の場所によって判断していた。しかし、特に場所変化を通知開始イベントとしたときの通知反応には、ユーザが以前にいた場所情報も大きく影響する。よって、ユーザが以前にいた場所も反応履歴として蓄積し、以前の場所を追加し次元を増した通知評価値テーブルを作成することで、より場所変化に対応した通知を行うことができる。
【0086】
例えば、会社から家に帰ったときは疲れているため情報を通知されても見ないが、庭から家に戻るなど余裕があるときは情報を通知されると見るということがある。本手法を用いることで、通知開始イベント(場所変化)かつ前場所(会社)かつ場所(家)の条件の通知評価値から、会社から家に帰ったときは通知しないということが可能である。同時に、通知開始イベント(場所変化)かつ前場所(庭)かつ場所(家)の条件の通知評価値から、庭から家に戻ったときには通知するということが可能である。
【0087】
なお、ユーザが以前にいた場所は、局所無線などによってラベル付けされた場所情報のうち一番最近のものであっても良い。具体的に言うと、会社から家に帰ったとき、会社という場所情報を検知した後、ラベルの付いた場所情報を何も検知できない状況が続く。その後、家というラベルの付いた場所情報を検知した場合、会社から家に帰ってきたとする。これにより、「検知なし」というノイズを除去することができ、会社から家への場所変化を検知し、それによりタイミングを制御することができる。「検知なし」の情報を以前の場所情報として使っていた場合は、コンビニから家に帰るときも、会社から家に帰るときも前場所(検知なし)かつ場所(家)となり区別ができなくなる。
【0088】
また、ユーザが現在いる場所は、ラベルの付いた場所情報でなくても良い。具体的に言うと、「検知なし」という場所情報であっても良い。例えば会社から家に帰ったとき、会社という場所情報を検知した後、ラベルの付いた場所情報を何も検知できない状況が続く。その後、家というラベルの付いた場所情報を検知した場合、会社から家に帰ってきたとする。現在の場所情報に「検知なし」の情報を使わなかったとすると、前場所(会社」かつ場所(家)という条件しか検知できないため、もし会社を出た後すぐに通知することが好ましかったとしても、家に着くまで条件を満たさないため通知できない。しかし、現在の場所情報に「検知なし」の情報を使うことで、前場所(会社)かつ場所(検知なし)という条件により、会社を出た後すぐに情報を通知することができる。
【0089】
また、本実施の形態において、通知が開始されるイベントは時刻変化もしくは場所変化であったが、ユーザのなんらかの状態変化イベントをきっかけとして情報を通知しても良い。ユーザは仕事が終わった直後、移動する直前など、なんらかの作業の区切り、言わば一息つきたいときに情報を通知されることを好む。しかし、作業の区切りを検知することは難しい。よってユーザの状態変化、具体的には姿勢の大幅な変化を検知したときを作業の区切りとし、姿勢変化をきっかけとして、現在の時刻や場所に対応する通知評価値を計算し、通知評価値に従って通知を行う。
【0090】
これにより、通知評価値が高い時間帯の中でも、より情報通知が好まれやすいタイミング、ユーザの作業に対する集中を邪魔しないタイミングで通知を行うことができる。なお、姿勢の変化は、例えばジャイロなどの位置センサーをユーザの体につけることで入手する。例えば、ユーザに万歩計(登録商標)をつけ、ユーザの移動を検知し、ユーザの移動が止まったことをきっかけとして通知を行っても良い。
【0091】
なお、本実施の形態では、現在の時刻だけでなく、場所も考慮して通知タイミングを決定したが、本発明は、場所を考慮することを必ずしも必要としない。つまり、本実施の形態における場所検知部101等は必ずしも必須の構成要素ではない。現在時刻とユーザの反応を検知することで、適切な通知タイミングを決定することができるからである。ただし、時刻だけでなく、場所をも考慮することで、より状況に即した通知タイミングの決定が可能になるのは言うまでもない。
【0092】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0093】
(実施の形態2)
次に、本発明の実施の形態2に係る情報通知装置を説明する。
【0094】
実施の形態1における汎化条件利用規則では、汎化規則が複数適用できる場合のことを考慮していなかった。例えば汎化条件利用規則を用いる際、条件が「時刻(7時〜9時)かつ場所(会議室)」のときに、場所(会議室)という汎化条件における通知評価値は使っても、時刻(7時〜9時)という汎化条件における通知評価値は用いなかった。しかし実際は、汎化条件を複数用いる方が性能は良い。そこで、本実施の形態では、汎化条件を複数用いる場合について説明する。
【0095】
汎化規則を用いる際、汎化条件の候補が複数ある場合は次のような複数汎化条件利用規則を用いる。複数汎化条件利用規則は修正規則の一種であり、修正規則蓄積部105に蓄積される。通知評価値修正部111は蓄積された複数汎化条件利用規則も用いて、通知評価値テーブルを修正する。
【0096】
条件を汎化した場合、汎化条件は通常複数作成できる。複数の汎化条件下の通知評価値から、汎化前の条件下における通知評価値を求める規則が複数汎化条件利用規則である。例えば、図19(a)に示されるように、時刻(11時〜13時)かつ場所(会議室)における通知評価値について、汎化条件利用規則を用いて修正したい場合、複数の汎化条件の通知評価値、つまり時刻(11時〜13時)の通知評価値「0.44」と場所(会議室)の通知評価値「0.0」を用いる。例えば、以下に述べる汎化条件選択規則1を用いて、ユーザが会議室にいることがまれなことから、時刻(11時〜13時)かつ場所(会議室)における通知評価値を、例えば図19(b)に示されるように、場所(会議室)の通知評価値である「0.0」に決定する。
【0097】
複数汎化条件利用規則には、複数の汎化条件下における通知評価値の中から1つだけ選択する複数汎化条件選択規則と、複数の汎化条件下における複数の通知評価値を用いて通知評価値を修正する汎化条件合算規則とがある。
【0098】
(1)汎化条件選択規則1
汎化を行う際、複数の汎化条件のうち、条件を満たす状況が発生する頻度が低い条件下の通知評価値、例えば発生確率の低い条件下における通知評価値を用いる方が、ユーザの状況をより厳密に表している条件であるため、信頼できる。例えば、家にいることが多いユーザは、家にいるという条件が通知の可否に対してあまり影響しない。家にいるという条件下での通知評価値が高いユーザでも、家にいるからといって午前3時に情報を通知しても、ユーザは寝ていて気づかない可能性が高い。この場合、家という条件より、午前3時という条件の方が発生確率が低く、通知タイミングを決める重要な要因となる。よって、汎化を行う際は、発生確率の低い条件を優先的に用いる必要がある。
【0099】
また、履歴データ数が多い条件下における通知評価値を用いる方が、ノイズに影響されにくいため、より信頼できる。よって、汎化条件が複数ある場合、条件に対応する反応履歴のデータ数が閾値以上である汎化条件のうち、発生確率の最も低い汎化条件における通知評価値を用いる。
【0100】
具体的には、図22(b)に示されるように、通知評価値テーブルの要素となる時刻や場所からなるAND条件ごとに、条件の発生確率、つまり、ある時点にユーザが条件を満たしている確率を計算し、条件発生確率テーブルを作成することにより、これを実現する。
【0101】
条件発生確率テーブルの作成方法について説明する。
【0102】
図20は、条件発生確率テーブルを作成する装置の構成を示すブロック図である。条件発生確率テーブルは、図20に示されるように、行動履歴蓄積部2403と条件発生確率計算部2404を用いることで作成できる。
【0103】
行動履歴蓄積部2403は、場所検知部101で検知されたユーザの場所と時刻検知部100で検知された時刻と共に行動履歴として蓄積する。例えば、図21に示されるように、ユーザの場所とユーザがその場所にいた時刻範囲の組を蓄積する。
【0104】
条件発生確率計算部2404は。行動履歴蓄積部2403に蓄積された行動履歴から条件発生確率、つまりユーザの状況が、ある時点において、時刻と場所からなる条件を満たしている確率を計算する。例えば、図22に示されるように、場所と時刻のAND条件ごとに条件発生確率を計算し、条件発生確率テーブルとして保存する。例えば、図22(a)に示されるように、条件発生確率テーブルの、条件「時刻(17時〜19時)かつ場所(デスク)」における条件発生確率を計算する場合。行動履歴蓄積部2403から発生確率を求めたい条件「時刻(17時〜19時)かつ場所(デスク)」を満足する履歴を抽出する。抽出した行動履歴の時刻範囲の合計を計算し、全履歴の時刻範囲の合計で割る。図22(a)の場合、全履歴を10日間とすると、抽出した履歴の時刻範囲の合計が7.2時間(=2+1+2+0.5+0.5+1.2)であるため、0.03{=7.2/(24*10)}となる。また、条件「時刻(17時〜19時)」における条件発生確率は、抽出した行動履歴の時刻範囲2時間*10日/全履歴24時間*10日となり、0.083となる。このように、条件ごとに条件発生確率を計算することで図22(b)に示されるような条件発生確率テーブルが作成される。
【0105】
次に、条件発生確率テーブルを用いた汎化条件の選択について、具体的に説明する。
【0106】
図23は、本発明の実施の形態2に係る情報通知装置の構成を示すブロック図である。なお、図1に示す実施の形態1の情報通知装置と同様の構成については、同一の符号を付し、説明を省略する。
【0107】
情報通知装置は、図23に示されるように、実施の形態1の構成に加えて、上記にて述べた行動履歴蓄積部2403、条件発生確率計算部2404を備えている。
【0108】
通知評価値修正部6001は、修正規則蓄積部105に蓄積されている修正規則と条件発生確率計算部2404により作成された条件発生確率テーブルを用いて、汎化条件を選択する。例えば、図24に示されるように、修正規則として汎化条件利用規則を適用し、条件「時刻(11時〜13時)かつ場所(会議室)」における通知評価値を修正するとする。このとき汎化条件の候補として、時刻(11時〜13時)という汎化条件Aと場所(会議室)という汎化条件Bを比較する。汎化条件A、B共に履歴データ数は閾値以上であったとする。時刻(11時〜13時)という条件Aの発生確率は図22(b)の条件発生確率テーブルより、「0.083」である。また場所(会議室)という条件Bの発生確率は図22(b)の条件発生確率テーブルにより、「0.064」である。よって、場所(会議室)という条件の方が発生確率は低いため、図24(b)に示されるように、条件「場所(会議室)」の通知評価値、図24の場合「0.0」が選択され、条件「時刻(11時〜13時)かつ場所(会議室)」における通知評価値は「0.0」に修正される。
【0109】
これにより、条件「時刻(11時〜13時)かつ場所(会議室)」における反応履歴が存在しなかったとしても、汎化条件選択規則1を用いることで、場所(会議室)の通知評価値「0.0」を選択し、通知しないことを決定できる。実際、時刻(11時〜13時)は発生確率が大きいため、通知可の可能性と通知否の可能性の両方を含んでいる可能性が高い。
【0110】
また、7時に交通情報の通知をあまり好まない人でも、同じ7時でもガソリンスタンドにいるときには交通情報の通知を好むということも多いであろう。しかし、ガソリンスタンドで働いている人は、ガソリンスタンドにいるからといって交通情報の通知を好まないであろう。むしろ、時刻7時という条件の方が効いてくると考えられる。条件発生確率を用いるのはこのためである。
【0111】
(2)汎化条件選択規則1−1
なお、汎化条件について、予め優先順位をつけることで、用いる通知評価値を選択しても良い。通知評価値を選択するためには、基本的に通知評価値の前提となる条件の発生確率を基準として選択する方が良い。しかし、発生確率を求めるためには、条件発生確率テーブルを作成する必要があり、装置に負担がかかる。よって、装置の設計者が発生確率を予め予想し、条件に予め優先順位を設け、簡易的に実現しても良い。例えば、時刻の汎化条件と場所の汎化条件では、場所の汎化条件の方が発生確率が低いと考え、優先順位を上げる。
【0112】
(3)汎化条件選択規則1−2
また、条件発生確率計算部2404が条件の要素となる時刻や場所、通知開始イベントにそれぞれ発生確率を一定値と仮定し、時刻や場所の発生確率を掛け合わせることで簡易的に発生確率を求めても良い。これにより、行動履歴蓄積部2403を使わなくても、条件発生確率テーブルを作成できるという利点がある。このため、行動履歴が蓄積されてない学習の初期段階でも条件発生確率テーブルを利用できる。また、装置の負担が減り、行動履歴を蓄積しないため、ユーザのプライバシーに配慮できる。
【0113】
例えば、条件の要素のとりうる値の種類の数の逆数として発生確率を仮定する。例えば、時刻を2時間ごとに離散化していた場合、時刻のとりうる値の種類の数は12(2時間/24時間)である。よって1/12と仮定する。同様に場所の値の種類が4であった場合、発生確率を例えば1/4とする。また、通知開始イベントの値の種類が2であった場合発生確率を例えば1/2とする。
【0114】
図25(a)に示されるように、このとき条件「時刻(17時〜19時)」の発生確率は17時〜19時という時刻値に関わらず、1/12である。また、条件「場所(家)」の発生確率は場所の値に関わらず、1/4である。また、条件「通知開始イベント(場所変化)」の発生確率は通知開始イベントの値に関わらず、1/2である。また、条件「時刻(17時〜19時)かつ場所(家)」の発生確率は時刻要素と場所要素の積集合なので、図25(b)に示されるように、1/48(=1/12×1/4)となる。また、条件「時刻(17時〜19時)かつ通知開始イベント(場所変化)」の発生確率は時刻要素と通知開始イベント要素の積集合なので、1/24(=1/12×1/2)となる。また、条件「場所(家)かつ通知開始イベント(場所変化)」の発生確率は場所要素と通知開始イベント要素の積集合なので、1/8(=1/4×1/2)となる。条件「時刻(17時〜19時)かつ場所(家)かつ通知開始イベント(場所変化)」の発生確率は、時刻要素と場所要素と通知開始イベント要素の積集合なので、1/96(=1/12×1/4×1/2)となる。
【0115】
これにより、時刻や場所の変化の履歴を蓄積し、条件発生確率テーブルを計算しなくても、より条件発生確率が低いと思われる汎化条件を選択することができる。これにより、時刻や場所の変化の履歴が十分にたまっていない状況においても適切なタイミングで情報を通知することができる。例えば、学習の初期状態において、時刻や場所の変化の履歴は十分たまっておらず、条件発生確率テーブルが作成できない。そして発生確率1/96である時刻(17時〜19時)かつ場所(家)かつ通知開始イベント(場所変化)のときに、通知の可否を判断したいが、条件「時刻(17時〜19時)かつ場所(家)かつ通知開始イベント(場所変化)」における反応履歴がなかったとする。このとき、汎化条件下の通知評価値を用いて、通知の可否を判断する。しかし、汎化条件は「時刻(17時〜19時)」、「場所(家)」、「通知開始イベント(場所変化)」、「時刻(17時〜19時)かつ場所(家)」、「時刻(17時〜19時)かつ通知開始イベント(場所変化)」、「場所(家)かつ通知開始イベント(場所変化)」と複数あるが、条件発生確率は履歴が少ないため求められず、どの条件下の通知評価値を用いればよいのかがわからない。このとき、汎化条件選択規則1−2により、擬似的に条件発生確率を計算することにより、条件「時刻(17時〜19時)かつ場所(家)」の発生確率が1/48と最も低いことが判明し、条件「時刻(17時〜19時)かつ場所(家)」下の通知評価値に従い、通知の可否を判断することができる。
【0116】
(4)汎化条件選択規則2
また、複数の汎化条件のうち、通知評価値が特徴的なものを選択しても良い。例えば通知評価値が反応確率であり値が0から1までしかとらないとき、その中間値0.5から最も離れた通知評価値をもった汎化条件を用いる。理由は、特徴的な通知評価値を持った条件の方が、通知の好ましさに影響しているためである。例えば、「時刻(15時)」、「場所(車)」における通知の可否を制御したいが、条件「時刻(15時〜17時)かつ場所(車)」における反応履歴が存在しなかったとする。「時刻(15時〜17時)」における通知評価値が0.6であり、中間値0.5に近い。「場所(車)」における通知評価値は0.0であり、中間値0.5から遠い。このとき、「場所(車)」における通知評価値が0.0であることから通知を行わない。これにより、より通知タイミングの可否が明白である条件を優先することができるため、絶対通知して欲しくない状況では通知しないということが可能になる。
【0117】
なお、汎化条件選択規則において通知することを優先し、複数の汎化条件のうちより大きな通知評価値を持った汎化条件を選択しても良い。
【0118】
また、汎化条件選択規則において通知しないことを優先し、複数の汎化条件のうちより小さな通知評価値を持った汎化条件を選択しても良い。
【0119】
(5)汎化条件合算規則
汎化条件合算規則は、複数の汎化条件の通知評価値を用いて、汎化前の条件下における通知評価値を更新する規則である。具体的には、条件nかつm下における通知評価値を条件nの通知評価値と条件mの通知評価値を用いて求める。
【0120】
特に、条件nと条件mが互いに独立である場合、条件nかつmの通知評価値には、条件nと条件mの通知評価値が共に係わる可能性がある。よって、発生確率の低いものを選択するだけでは、現実に適合しない可能性がある。
【0121】
例えば、条件nにおける通知評価値がある程度高く、条件mも通知評価値がある程度高い場合、それらの要因が合わさって、条件nかつmではさらに通知評価値が高くなる可能性がある。逆に、条件nが通知評価値が低く、条件mも通知評価値が低い場合、それらの要因が合わさって、条件nかつmではさらに通知評価値が低くなる可能性もある。
【0122】
例えば、nを条件「時刻(15時〜17時)」、mを条件「場所(会議室)」とする。条件「時刻(15時〜17時)」の通知評価値、条件「場所(会議室)」の通知評価値が共にある程度低かったとする。条件「時刻(15時〜17時)」と条件「場所(会議室)」はそれぞれ独立の事象である。
【0123】
このとき条件「時刻(15時〜17時)かつ場所(会議室)」のときには通知評価値がさらに低くなり、絶対に情報を通知しない方が良いという可能性がある。もしかすると、時刻(15時〜17時)は仕事中の時間であり、場所(会議室)では会議中である可能性がある。時刻(15時〜17時)かつ場所(会議室)では重要な仕事の会議が開かれていて、絶対に通知しない方が良いかもしれない。このように複数の汎化条件の特徴を重ね合わせることで通知評価値を修正する。具体的には、条件の発生確率や履歴データ数によって、重みをかけて、複数汎化条件における通知評価値を足し合わせることで算出する。
【0124】
例えば、時刻(15時〜17時)の発生確率が1/12、場所(会議室)の発生確率が1/6であった場合、発生確率の比は1:2である。よって、2/3×時刻(15時)の通知評価値+1/3×場所(会議室)の通知評価値を時刻(15時)かつ場所(会議室)の通知評価値とする。
【0125】
条件「時刻(15時〜17時)かつ場所(会議室)」における通知の可否を判断したいが、反応履歴がなかったとする。このとき、条件「時刻(15時〜17時)」における通知評価値が0.6であり、条件「時刻(会議室)」における通知評価値が0であったとする。発生確率の低い条件を選択すると、条件「時刻(15時〜17時)」であり、通知評価値0.6より通知可となってしまう。しかし、場所(会議室)の通知評価値は0であり、絶対に通知をしないほうがいい可能性が高い。こういった場合、複数の条件から通知評価値を計算することで、通知評価値0.4(2/3×0.6+1/3×0)となり、通知を行わないようにできる。
【0126】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0127】
さらに、本実施の形態では、汎化規則を複数用いて通知評価値が計算され、そのような通知評価値に基づいて、通知タイミングが決定されるので、より高い精度で通知タイミングが決定される。
【0128】
(実施の形態3)
次に、本発明の実施の形態3に係る情報通知装置を説明する。
【0129】
上記のように、実施の形態1〜2における通知評価値修正規則では、より大きな概念を表すように汎化した条件における通知評価値を用いるのみであった。しかし、例えば、条件には時刻(10時〜11時)と時刻(11時〜12時)というように類似した条件がある。そこで、本実施の形態では、類似した条件における通知評価値を用いて、求める条件の通知評価値を更新する規則として近傍汎化規則、類似汎化規則を用いる場合について説明する。
【0130】
(1)近傍汎化規則
近傍汎化規則とは、近傍の条件における反応履歴データ数や通知評価値を用いて、元々の条件下における通知評価値を更新する規則である。
【0131】
近傍の条件同士ではユーザの通知に対する反応が同じようになることが多い。よって、近傍の条件下の反応履歴データを利用して通知評価値を更新する。
【0132】
例えば、図26(a)の場合、条件「時刻(9時〜11時)かつ場所(会社(デスク))」に適合する状況において、履歴データは存在せず、通知評価値は不定である。このとき近傍の条件「時刻(11時〜13時)かつ場所(会社(デスク))」下における通知評価値「0.75」を用いて、図26(b)に示されるように、条件「時刻(9時〜11時)かつ場所(会社(デスク))」における通知評価値を例えば「0.75」に更新する。
【0133】
これにより、例えば条件「時刻(9時〜11時)かつ場所(会社(デスク))」における反応履歴がわからなくても、条件「時刻(11時〜13時)かつ場所(会社(デスク))」における通知評価値が0.75であれば、時刻(9時〜11時)かつ場所(会社(デスク))において通知評価値が0.75に更新され、通知することができる。
【0134】
条件が近傍であるとは、条件に含まれる要素の値の幾つかが同じであるか似ている、もしくは距離が近いということである。条件が近傍であるとは例えば次のようなものである。
【0135】
特に、近傍汎化規則は以下に述べる実施の形態8の内容評価値テーブルによる情報内容の選択において有用である。近傍の条件同士では同じ情報内容を持つ情報を求めることが多い。
【0136】
1)条件を表す要素集合に同じ値をもつ要素が存在する場合
条件A「x1かつy1」と条件B「x1かつy3」は近傍である。この場合、条件A、Bを表す要素のうちx1が共通項として含まれるので、AとBは近傍である。例えば、条件A「時刻(11時〜13時)かつ場所(会社)かつ通知開始イベント(場所移動)」、条件B「時刻(11時〜13時)かつ場所(家)かつ通知開始イベント(場所移動)」は時刻(11時〜13時)かつ通知開始イベント(場所移動)が共通項として含まれるため近傍である。実際に、条件Aでも条件Bでも情報を通知したときに同じような反応を受けることがある。これは、共通項x1が情報通知の可否を決める重要な要素となっていることが多々あるためである。例えば、家でも会社でも11時〜13時に場所移動したときは、食事の情報を欲しがっているかもしれない。
【0137】
これにより、条件「時刻(11時〜13時)かつ場所(会社)かつ通知開始イベント(場所移動)」における反応履歴が存在しなくても条件「時刻(11時〜13時)かつ場所(家)かつ通知開始イベント(場所移動)」における通知評価値が1.0であれば、条件「時刻(11時〜13時)かつ場所(会社)かつ通知開始イベント(場所移動)」において食事情報を通知することができる。
【0138】
2)条件を表す要素に、距離が近い値を持つ要素が存在する場合
条件A「x1」と条件B「x2」(x1とx2の距離が近い)は近傍である。この場合、条件A、Bを表す要素であるx1とx2の値の距離が近かった場合、条件A、Bは近傍である。
【0139】
まず、物理的に距離が近い場合がある。つまり要素が距離の概念を持っているものである。特に本来連続値であるものが多い。例えば時刻、場所といったものが上げられる。例えば、時刻7時と時刻8時は距離が近い。実際、時刻7時の情報通知と時刻8時の情報通知は似たものになることが多い。また場所の要素で距離が近いと近傍である。例えば「経度123°45'67"、緯度100°12'34"」と「経度123°45'68"、緯度100°12'35"」は距離が物理的に近いので近傍である。
【0140】
物理的な距離が近いことの判別は、通知評価値テーブルを作成した際、テーブルの要素となる値が直接隣接しているものを近傍とする。例えば、時刻において、2時間ごとに離散化して通知評価値テーブルを作成した際、条件「時刻(7時〜9時)」と「時刻(9時〜11時)は隣接しているため、近傍である。
【0141】
場所を「ハチ公前」と「モヤイ像前」、「A町1番地」と「A町2番地」、「日本橋」と「難波」などラベル化したものでも距離が物理的に近いので近傍である。物理的距離が近いものは、ユーザがその場所で行うことも似たものとなることが多いため、物理的距離が近い条件時の情報通知の反応は実際似たものとなることが多い。例えば、ハチ公前もモアイ像前も物理的に近いため、同じ待ち合わせ場所として利用されることが多い。よって、双方とも情報を送ったときに好まれる可能性が高い。また、どのような情報を通知すべきか決定する際、物理的距離が近い場所で好まれる情報をユーザに通知すると好まれることが多い。例えば、ユーザが「日本橋」にいるときに「難波」の飲食店情報を送ったとしても、物理的に歩いて行ける距離にあるために、通知が好まれる。
【0142】
ラベルにおける物理的近傍は、ラベル自体に経度緯度情報など物理的な値を予め与えておき、その物理的な値の距離が最も近いラベルを近傍とする。例えばラベル「A地点」「B地点」「C地点」があったときに、ラベル「A地点」の近傍を知りたいとする。「A地点」と「B地点」の距離が1、「A地点」と「C地点」の距離が2だったとすると、一番近い「B地点」をA地点の近傍とする。
【0143】
3)意味的に距離が近い場合
これはx1とx2が何らかの概念において共通している、似ているということである。具体的に言うと「サッカー」と「野球」はスポーツという点で共通している。「会社」と「取引先」はユーザの働くところという点で共通している。また、東京の「秋葉原」と大阪の「日本橋」は電気街という点で共通している。「東京駅」と「羽田空港」は乗り物に乗るところという点で共通している。これらは反応履歴も似たものになる可能性が高い。例えば、21時に「サッカー」のニュースを見る人は21時に「野球」のニュースも見ることが多い。「会社」で娯楽情報を通知されるのを好まない人は「取引先」でも娯楽情報が通知されるのを好まないことが多い。「秋葉原」にいるときにPC情報を通知されるのを好む人は、「日本橋」にいるときもPC情報を通知されるのを好む。これにより、「秋葉原」でPC情報の通知を好むユーザが、「日本橋」に旅行に行ったとしてもPC情報を通知することができる。
【0144】
距離的に近いという知識や意味的に近いという知識はユーザや装置設計者、情報発信者などが装置に与えても良い。具体的には、修正規則蓄積部105に蓄積された近傍汎化規則が近傍データベースを持つことにより、実現する。近傍データベースは、図27に示されるように、情報を識別するIDと互いに近傍となる要素値を組として蓄積する。例えば、ID(001)と場所(会議室)、場所(第二会議室)を組にして保存する。これにより、通知評価値修正部111は、近傍データベースを検索し、近傍だと判明した条件を用いて、通知評価値の修正を行う。例えば、図28(a)に示されるように、通知評価値テーブルの条件「時刻(15時〜17時)かつ場所(第二会議室)」の反応履歴が存在しなかった場合、近傍データベースを検索し、図28(b)に示されるように、近傍である場所(会議室)を要素とする条件「時刻(15時〜17時)かつ場所(会議室)」の通知評価値「0.0」を用いて、場所(第二会議室)の通知評価値を「0.0」に修正する。
【0145】
特に共通項による近傍と、距離による近傍の複合である、条件A「x1かつy1」と条件B「x1かつy2」(y1とy2の距離が近い)は最も近傍であり、影響が大きい。よって、同じ場所(会議室)を要素とする条件の通知評価値を用いるときでも、時刻(15時〜17時)の共通する条件「時刻(15時〜17時)かつ場所(会議室)」の通知評価値を用いる。
【0146】
なお、通知評価値はデータ履歴の多い近傍条件下における通知評価値をそのまま用いても良いし、データ数や近傍条件との距離に応じて重みをかけてもよい。また、近傍の通知評価値が閾値以上のものは通知評価値を固定値A、閾値以下のものは固定値Bとするように、閾値を用いても良い。複数の近傍条件から通知評価値を算出しても良い。
【0147】
なお、実施の形態2で記述した複数条件利用規則は近傍汎化規則についても用いることが出来る。例えば、「時刻(15時〜17時)かつ場所(第二会議室)」の通知評価値を修正する場合、修正候補として近傍条件「時刻(15時〜17時)かつ場所(会議室)」と汎化条件「時刻(15時〜17時)」、汎化条件「場所(第二会議室)」が存在する。このときも、それぞれの条件を満たす状況が発生する頻度を用いて修正に用いる条件を選択する。例えば汎化条件選択規則1を利用して通知評価値を修正する。
【0148】
近傍条件「時刻(15時〜17時)かつ場所(会議室)」は正確には条件「時刻(15時〜17時)かつ場所(第二会議室)」を条件「時刻(15時〜17時)かつ、場所(会議室)もしくは場所(第二会議室)」と汎化したものである。この近傍汎化条件「時刻(15時〜17時)かつ、場所(会議室)もしくは場所(第二会議室)」の発生確率が0.02、汎化条件「時刻(15時〜17時)」の発生確率が0.083、汎化条件「場所(第二会議室)」の発生確率が0.04であったとすると、最も発生確率の低い近傍汎化条件「時刻(15時〜17時)かつ、場所(会議室)もしくは場所(第二会議室)」下の通知評価値を用いて通知評価値を修正する。
【0149】
4)他の要素を用いた近傍概念の生成
なお、他のセンサー値など、通知評価値テーブルの構成要素とならない他の要素によって、近傍概念を生成し、反応履歴が十分に存在しない部分について近傍条件を用いて通知評価値を修正しても良い。
【0150】
例えば平休日「(平日)もしくは(休日)」という要素をユーザのスケジュール情報などから検知できたとする。このとき、「曜日」について近傍概念を生成する。スケジュール情報により、例えば、土曜日における休日の発生確率と平日の発生確率が、日曜日における休日の発生確率と平日の発生確率に非常に近い値であったとする。また、月曜日における休日と平日の発生確率が、火曜日〜金曜日の休日と平日の発生確率に非常に近い値であったとする。このとき土曜日と日曜日は休日という要素が近い値をとるため互いに近傍である。月曜日〜金曜日もまた平日休日という要素においてそれぞれ互いに近傍である。
【0151】
近傍概念の自動生成を用いた、近傍汎化規則を用いた通知評価値テーブルの修正と通知タイミング制御について詳しく説明する。
【0152】
図29に示されるように、実施の形態1の構成に他要素検知部6501、行動履歴蓄積部6503、他要素発生確率計算部6502、近傍データベース生成部6504、近傍データベース6505、近傍汎化規則6506を加えることにより、実現する。
【0153】
他要素検知部6501は通知評価値テーブルの構成要素とならない他の要素を検知する。例えば、図29に示されるように、平休日検知部6507を持つこととする。
【0154】
平休日検知部6507は、装置内のユーザが記録したスケジュール情報やカレンダー情報から、現在が平日もしくは休日であるという情報を検知する。
【0155】
また、時刻検知部6500は、時刻と共に曜日情報を装置のタイマー等により検知することとする。
【0156】
行動履歴蓄積部6503は、場所検知部101で検知したユーザの場所と時刻検知部6500で検知した時刻と時刻検知部6500で検知した曜日と他要素検知部6501で検知した情報、例の場合平休日検知部6508で検知した平休日情報と共に行動履歴として蓄積する。例えば、図30に示されるように、ユーザの場所と曜日と平休日とユーザがそれらの条件を満たした時刻範囲の組を蓄積する。
【0157】
他要素発生確率計算部6502は。行動履歴蓄積部6503に蓄積された行動履歴から条件付き他要素発生確率、つまりユーザの状況がある条件を満たしている時点において、他要素が起こっている確率を計算する。例えば、図31に示されるように、場所、曜日、時刻ごとに、他要素(平休日)の発生確率を計算し、条件付き発生確率テーブルとして保存する。曜日(火曜日)の条件付き他要素(休日)発生確率を計算する場合、求めたい条件「曜日(火曜日)」を満たす行動履歴を全て抽出する。抽出した行動履歴から他要素(休日)を満たす行動履歴の時刻範囲の合計(24時間)を計算し、求めたい条件「曜日(火曜日)」を満たす行動履歴の時刻範囲の合計で割る。図31(a)の場合、条件「曜日(火曜日)」を満たす行動履歴の時刻範囲の合計は24時間の履歴が10個あることより、240時間である。また、条件「曜日(火曜日)かつ平休日(休日)」を満たす行動履歴の時刻範囲の合計は24時間の履歴が1個あることにより、24時間である。よって、条件「場所(火曜日)」を満たすときの他要素「平休日(休日)」の発生確率は0.1(=24/240)となる。同様に。条件「場所(火曜日)」を満たすときの他要素「平休日(平日)」の発生確率は0.9{=(24×9)/(24×10)}である。このように、条件ごとに条件付き他要素発生確率を計算することで、図31(b)、(c)、(d)に示されるような他要素発生確率テーブルが作成される。
【0158】
近傍データベース生成部6504は、他要素発生確率計算部6502で生成された他要素発生確率テーブルを用いて、他要素発生確率の類似した条件から互いに近傍となる条件の組を発見し、近傍データベース6505に格納する。
【0159】
例えば、他要素発生確率テーブルからそれぞれの発生確率の差の低い条件の組を発見する。図32に示されるように、火曜日と月曜日において近傍かどうかを判別したいとき、それぞれの発生確率の平均二乗誤差を計算する。火曜日と月曜日における平日の発生確率の二乗誤差が0.64{=(0.1−0.9)2}であり、休日の発生確率の誤差が0.64{=(0.9−0.1)2}であることから、平均二乗誤差は0.64{=(0.64+0.64)/2}となる。この平均二乗誤差を閾値と比較し、閾値より低いと近傍とする。閾値を例えば通知評価値の取りうる値の1/10である0.1としたとすると、平均二乗誤差0.64>=閾値0.1より、近傍ではない。また、火曜日と日曜日における平休日の発生確率の平均二乗誤差は{(0.1−0.05)2+(0.9−0.95)2}/2=0.0025<閾値0.1より、火曜日と日曜日は近傍と判別できる。このとき、火曜日と日曜日の組を近傍として識別するためのIDと共に、近傍データベース6505に格納する。このように、他要素発生テーブルにおける全ての条件の組について近傍を判別し、近傍と判別された条件の組を近傍データベース6505に登録する。近傍汎化規則6506は当該近傍データベース6505を保持する。
【0160】
通知評価値修正部111は、上記(1−3)と同様に、図33に示されるように、近傍データベース6505を検索し、近傍だと判明した条件を用いて、通知評価値の修正を行う。例えば、通知評価値テーブルの条件「曜日(火曜日)かつ時刻(7時〜9時)かつ場所(家)」の反応履歴が存在しなかった場合、近傍データベース6505を検索し、曜日(火曜日)の近傍である曜日(日曜日)を要素とする条件「曜日(日曜日)かつ時刻(7時〜9時)かつ場所(家)」の通知評価値「0.0」を用いて、条件「曜日(火曜日)かつ時刻(7時〜9時)かつ場所(家)」を通知評価値「0.0」に修正する。
【0161】
これにより、通知タイミング制御部1505は、反応履歴が存在しなくても、例えば、条件「曜日(火曜日)かつ時刻(7時〜9時)かつ場所(家)」において通知評価値が0.0であることより、0.0の確率で通知つまり、通知しないことを判断できる。
【0162】
近傍を自動生成することで、より汎化の精度を高めることができる。例えば、ユーザは平日には7時〜9時に家にいるときに情報通知を好むのだが、休日では、7時〜9時はまだ眠っていて情報通知を好まないとする。図33(a)に示されるように、条件「曜日(火曜日)かつ時刻(7時〜9時)かつ場所(家)」の反応履歴がなかったとき、条件「時刻(7時〜9時)かつ場所(家)」で汎化していては、平日、例えば条件「曜日(月曜日)かつ時刻(7時〜9時)かつ場所(家)」の通知評価値「1.0」に影響されてしまう。しかし、平休日情報から近傍を自動生成することで、「曜日(日曜日)かつ時刻(7時〜9時)かつ場所(家)」の通知評価値「0.0」を用いて通知しないことが判断できる。
【0163】
土日曜日が休日で月〜金曜日が平日と固定されていると、装置設計者が近傍データベースを与えておけばよいのだが、何曜日が休日になるかはユーザにより異なる。本手法により、ユーザによる平休日の違い、つまり近傍概念の違いに対処できる。
【0164】
なお、近傍データベースを作成するために、ユーザの周辺状況に関する情報を利用してもよい。具体的には、図34に示されるように、他要素検知部6501として、さらに、周辺音を検知する周辺音検知部7007を備えることにより実現できる。
【0165】
周辺音検知部7007は、ユーザの周辺の音情報について、例えば周囲の音の大きさを検知する。具体的には音の大きさを例えば「大」「小」「なし」と離散化して検知する。
これにより、行動履歴蓄積部7003においては、他要素として周辺音の項目を加えて行動履歴を蓄積する。例えば、図35に示されるように、ユーザの場所と周辺音とユーザがそれらの条件を満たした時刻範囲の組を蓄積する。
【0166】
他要素発生確率計算部7002は。行動履歴蓄積部7003に蓄積された行動履歴から条件付き周辺音発生確率、つまりユーザの状況がある条件を満たしている時点において、周辺音の各値が起こっている確率を計算する。
【0167】
同様に近傍データベース生成部6504が、条件付き周辺音発生確率により、近傍を探索することで、時刻や場所の近傍が生成される。
【0168】
これにより、本実施例においては、例えば、会議が行われ、周辺音が大きい場所「会議室」と場所「第二会議室」が近傍であることを推定し、それにより、汎化を行うことができる。
【0169】
(2)類似汎化規則
類似汎化規則とは反応履歴が類似した条件を用いて汎化を行う規則である。具体的には、例えば時刻(12時)と時刻(19時)において反応履歴が類似していた場合、時刻(12時)と時刻(19時)の条件を類似条件とし、類似した条件の反応履歴により修正を行う。
【0170】
例えば、場所(会議室)の通知評価値と場所(講堂)において、場所(会議室)かつ時刻(10時)における通知評価値と場所(講堂)かつ時刻(10時)における通知評価値が類似していたとする。類似とは通知評価値の平均二乗誤差が一定値以下であることを言う。
【0171】
10時における反応履歴が類似していることから、場所(会議室)と場所(講堂)は他の時間においても反応履歴が類似していることが推定される。このとき、時刻(13時)かつ場所(会議室)における通知評価値を時刻(13時)かつ場所(講堂)の通知評価値を用いて修正する。場所(会議室)と場所(講堂)において反応履歴が類似しているということは、通知に対して共通の要因を持っていると思われる。例えば、会議室、講堂は共に会議を行う場所であり、行う時間帯も似ている可能性が高い。よって、双方とも10時や13時に会議が行われ、通知が好まれないかもしれない。こういった場合、反応履歴の類似性から、時刻(13時)かつ場所(会議室)における通知評価値がわからなくても、時刻(13時)かつ場所(講堂)の通知評価値が0であり低ければ、時刻(13時)かつ場所(会議室)においても通知を行わないようにできる。
【0172】
類似汎化規則により、通知をより効率的に行うだけではなく、通知のタイミングを制御する要因を装置が自律的に見つけ出すことができる。例えば、会議室と講堂は通知に対して共通の特性を持っていることが検知できる。
【0173】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0174】
さらに、本実施の形態では、求める条件の通知評価値を更新する規則として近傍汎化規則、類似汎化規則が使用され、そのような通知評価値に基づいて、通知タイミングが決定されるので、より状況に即した通知タイミングが決定される。
【0175】
(実施の形態4)
次に、本発明の実施の形態4に係る情報通知装置を説明する。
【0176】
上記実施の形態1〜3における反応確率修正部では、反応履歴が得られていない条件の部分の通知評価値を反応履歴が得られている部分から推測するものであった。しかし、反応確率が得られている部分でも、履歴データ数の少ないものは信頼性が低く、通知評価値を修正する必要がある。このときに、汎化条件の通知評価値だけでなく、本来の条件下の通知評価値も利用した方が、より信頼できる通知評価値となる。そこで、本実施の形態では、これを実現するために、履歴使用規則を修正規則として用いる場合について説明する。
【0177】
通知評価値が得られている部分を他の条件についての通知評価値で修正するときに使用する規則が履歴使用規則である。通知評価値が得られている部分の通知評価値を修正する場合は、汎化した条件や近傍の条件を使用するだけでなく、元々の条件自身における通知評価値も利用して、通知評価値を更新する。基本的には、履歴データ数により重み付けを行い、足し合わせる。例えば、条件「場所(車中)かつ時間(23時)」において、履歴データ数が1であり、通知評価値が1.0であったとする。しかし、近傍汎化規則により条件「場所(車中)かつ時間(21時)」から通知評価値0が推定されたとする。このとき、履歴データ数に応じて重み付けを行う。
【0178】
例えば{条件「場所(車中)かつ時間(23時)」における履歴データ数1×重み2×通知評価値1.0+条件「場所(車中)かつ時間(21時)」における履歴データ数8×通知評価値0}/{条件「場所(車中)かつ時間(23時)」における履歴データ数1×重み2+条件「場所(車中)かつ時間(21時)」における履歴データ数8}の計算の結果、「0.2」の通知評価値とする。この例の場合、条件「場所(車中)かつ時間(23時)」にたまたま1回だけ通知に反応しただけで、実際は反応しないのが普通だったかもしれない。よって、双方から推定される通知評価値から履歴データ数によって重み付けを行うなどして推定を行う。
【0179】
これにより、条件「場所(車中)かつ時間(23時)」に反応しないのが普通だったとしても、安易に条件「場所(車中)かつ時間(23時)」の通知評価値が1.0であることから通知を行わず、履歴使用規則により、条件「場所(車中)かつ時間(21時)」における通知評価値も用いて通知評価値を更新し、通知評価値0.2から通知しないということが決定できる。
【0180】
また、条件「場所(車中)かつ時間(23時)」はいつもの飲み会帰りで別の人に運転してもらっているため、通知は好ましかったかもしれない。条件「場所(車中)かつ時間(23時)」における履歴データを用いず、汎化条件における通知評価値のみを用いていたのでは、条件「場所(車中)かつ時間(23時)」に通知することができない。しかし、本来の「場所(車中)かつ時間(23時)」における履歴データも用いることで、条件「場所(車中)かつ時間(23時)」における履歴データ数が5個まで集まり、通知評価値1.0であれば、{条件「場所(車中)かつ時間(23時)」における履歴データ数5×重み2×通知評価値1.0+条件「場所(車中)かつ時間(21時)」における履歴データ数8×通知評価値0}/{条件「場所(車中)かつ時間(23時)」における履歴データ数5×重み2+条件「場所(車中)かつ時間(21時)」における履歴データ数8}計算結果により、通知評価値0.56となり通知することができる。
【0181】
このように履歴データ数が多く信頼できる値に重み付けをすることで、ノイズを除去することができる。
【0182】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0183】
さらに、本実施の形態では、反応履歴が得られていない条件の部分の通知評価値を、汎化条件の通知評価値だけでなく、本来の条件下の通知評価値も利用して決定し、そのような、より信頼できる通知評価値に従って通知タイミングが決定されるので、よりユーザにとって好適なタイミングで情報が通知される。
【0184】
(実施の形態5)
次に、本発明の実施の形態5に係る情報通知装置を説明する。
【0185】
ところで、同時または連続的に通知する情報の数が多すぎる場合、ユーザに全部の情報を見てはもらえないという問題がある。例えば、携帯メールの場合、一度に100件メールが来たとしても、普通ほとんど見てはもらえないが、1件のメールを単独で通知された場合には見てもらえる可能性は高い。また、同じ10件のメールが来たとしても、ユーザが忙しいときには全く見ないが、暇なときには、10件のメールを全て見るかもしれない。このように状況に応じて、同時または連続的に見る情報の件数は異なると思われる。そこで、本実施の形態では、通知タイミングに加えて、同時または連続的に通知する情報の数も状況に合わせて制御する場合について説明する。
【0186】
図36は、本発明の実施の形態5に係る情報通知装置の構成を示すブロック図である。なお、図1に示す実施の形態1の情報通知装置と同様の構成については、同一の符号を付し、説明を省略する。
【0187】
情報通知装置は、図36に示されるように、実施の形態1の装置の構成に加えて、連続通知数を検知する連続通知検知部1610を備えている。
【0188】
連続通知検知部1610は、現在時点における、同時または連続的に通知された情報の数を検知する。例えば、現在までのある一定時間において通知された数を検知する。一定時間は例えばユーザが通知に反応してから、通知情報の閲覧を終了し、情報表示画面の切り替え操作をするまでにかかる平均時間である。
【0189】
通知タイミング制御部1608は、通知評価値テーブル、例えば反応確率テーブルの反応確率にしたがって、通知する情報の最大数を制御する。例えば、予め定めておいた通知数最大数(固定値)と反応確率の積を連続通知最大数とする。図37に示されるように、時刻(9時)、場所(会社(デスク))における通知タイミングを制御する場合、条件「時刻(9時)かつ場所(会社(デスク))」における反応確率は0.75である。通知最大数(固定値)を10と既定したとき、前記条件下における連続通知最大数は8(10×0.75を四捨五入)となる。よって、前記条件下における連続通知を8個までとする。例えば、通知情報蓄積部107における通知待ち情報が20個あったとする。それぞれの情報について前記条件下において通知の可否を反応確率から求めたところ、通知可であったとする。このとき通知待ち情報20個のうち8個までしか同時に通知しないようにする。このとき、20個の通知情報の中から、ランダムに8個選んでも良い。また情報発信者が予め情報に重要度を与えておき、情報の重要度が高いものから8個選んでも良い。
【0190】
なお、連続通知数を反応履歴として蓄積し、連続通知数に応じて通知タイミングを制御してもよい。具体的には、図38に示されるように、実施の形態1の装置の構成に加えて、連続通知検知部1810を備え、その情報を反応履歴蓄積部1803に蓄積することにより実現できる。
【0191】
連続通知検知部1810は、現在時点における、同時、または連続的に通知された情報の数を検知する。例えば、現在までのある一定時間において通知された数を検知する。
【0192】
反応履歴蓄積部1803は、図39に示されるように、反応履歴を蓄積する。
【0193】
例えば、履歴ID「004」のように、7:09に家で、連続通知検知部が3個の情報を検知しているとき、つまりユーザに既に過去一定時間の間で3個の情報を通知しているときに、さらに情報を通知すると、反応が一定時間なかったとする。このとき、通知時刻「7:09」、通知場所「家」、連続通知数「3」、反応時間「なし」として履歴を蓄積する。
【0194】
また、反応確率計算部1804は、時刻と場所と連続通知数を条件として、条件ごとに反応確率を計算し、時刻と場所と連続通知数の3次元反応確率テーブルを作成する。反応確率修正部1806はこの3次元反応確率テーブルを修正し、この3次元反応確率テーブルに従って、通知タイミング制御部1808は情報の通知タイミングを制御する。図39の例でいえば、条件「時刻(7時〜9時)かつ場所(家)かつ連続通知数(3)」における反応確率は履歴から0と計算される。また、条件「時刻(7時〜9時)かつ場所(家)かつ連続通知数(0)」、条件「時刻(7時〜9時)かつ場所(家)かつ連続通知数(1)」、条件「時刻(7時〜9時)かつ場所(家)かつ連続通知数(2)」における反応確率は履歴から1と計算される。このとき例えば、ユーザが時刻7時に家にいる場合において、3個目までは情報が連続的に、または同時に通知されるが、4個目は通知されない。これは、時刻7時に家にいる場合、ユーザは3個までは情報を見るが、4個目は見ないということが履歴から判断できるからである。
【0195】
これにより、各状況に応じて、ユーザは連続して何個通知されるのが好ましいかをユーザの連続反応数の履歴から判断し、連続通知数を各状況に応じて、詳細に決定することが可能になる。つまり「時刻(7時〜9時)かつ場所(家)」では3個連続で情報を通知するが、「時刻(13時〜15時)かつ場所(会議室)」では2個連続で情報を通知し、3個目は通知しないといった処理を、ユーザが普段連続して閲覧している情報の数に従って行うことが可能になる。ユーザが普段情報を1個しか見ない状況では1個しか情報を通知しないが、ユーザが普段情報を10個見る状況では10個の情報を通知するのである。
【0196】
なお、ユーザの情報閲覧時間の履歴を利用して、連続通知数を制限しても良い。情報閲覧時間は例えば、装置が情報内容の表示した時刻から装置が情報内容の表示を終了した時刻までの時間である。同じ一つのメッセージでも、文章が長く閲覧に時間がかかるものと文章が短く閲覧に時間がかからないものがある。よって、文章の長い情報は連続して通知しない、文章の短い情報は幾つか連続して通知するといった処理を行っても良い。具体的には、情報の文章の長さとユーザの閲覧時間の間の相関関数を履歴から推定し、閲覧時間が均一になるように、情報の文章の長さによって、連続的に通知する数を制限する。これにより、文章の長い情報が同時に来たため、ユーザが読むのに苦労する、文章の短い情報が一個しか来なかったため、ユーザが物足りない気分になるといった状況を回避することができる。
【0197】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0198】
さらに、本実施の形態では、通知タイミングに加えて、同時または連続的に通知する情報の数も状況に合わせて制御され、ユーザは、都合のいいタイミングで、それまで蓄積された複数の受信メールを一度に閲覧することができる。
【0199】
(実施の形態6)
次に、本発明の実施の形態6に係る情報通知装置を説明する。
【0200】
上記実施の形態1においては、通知タイミング制御部108は、現在の時刻を条件とした反応確率を用いてタイミング制御を行っている。本実施の形態では、現在の時刻以降を条件とした反応確率をタイミング制御に用いる場合について説明する。
【0201】
図40は、本発明の実施の形態6に係る情報通知装置の通知タイミング制御部の構成を示すブロック図である。なお、図1に示す実施の形態1の情報通知装置と同様の構成については、同一の符号を付し、説明を省略する。
【0202】
通知タイミング制御部2001は、図40に示されるように、場所範囲決定部2005、時刻範囲決定部2006、および通知可否判定部2007を備えている。
【0203】
場所範囲決定部2005は、現在の時刻から将来における場所範囲を決定する。つまり、現在の時刻において、どの場所に移動する可能性があるかを決定する。
【0204】
時刻範囲決定部2006は、現在の時刻から将来における時刻範囲を決定する。つまり、現在の場所において、どれだけの時間、同じ場所にいる可能性があるかを決定する。
【0205】
通知可否判定部2007は、反応確率修正部106が更新した反応確率テーブル中、場所範囲決定部2005及び時刻範囲決定部2006によって決定された範囲内の反応確率を用いることで現在における通知の可否を判定する。
【0206】
例えば図41(a)に示されるように、現在ユーザが11時に会社(デスク)にいたとする。現在時刻11時〜13時において、ユーザの未来における移動先と思われる場所範囲が「会議室」、「デスク」であったとする。例えば、場所の通知評価値テーブルにおける隣接値を移動先の候補とする。また、ユーザが移動しないと仮定できる時間を装置設計者が予め一定値として決めて置く。例えば6時間としたとする。このときに現在の反応確率が、範囲内の反応確率のうち最も高いものであったとき通知可と判断する。例えば、図41(b)に示されるように、11時かつデスクの反応確率に比べて13時かつデスクの反応確率の方が高いため、後で情報をまとめて通知した方が良いと考え、現在は通知しないということを判断する。
【0207】
ここで、場所範囲はユーザの行動履歴において、現在の場所から移動する確率が高い場所を選択しても良い。また、時刻範囲は例えば、ユーザの行動履歴から現在の場所における次に移動するまでの平均時間により決定しても良い。
【0208】
通知タイミングを決定するに当たって、次のような二つの要求項目がある。
1)できるだけユーザにとって好ましいタイミングで情報を通知したい、2)機を逃さずに情報をできるだけ多く通知したい、である。
【0209】
1)については当然である。ユーザにとって好ましいタイミングに通知しないと見てもらえない可能性があるし、ユーザに嫌がられる可能性もある。より好ましいタイミングで通知した方が、情報のユーザへの受けが良い。
【0210】
2)は特にニュースなどリアルタイム情報などが関係する。ニュースなどの情報は時間がたち、鮮度が落ちると、価値がなくなってしまう。よってできるだけ早く通知する必要がある。また、広告情報などについても、広告主はできるだけ情報をユーザに通知したい。最適なタイミングでなくとも、読んでもらえないよりは、通知した方がいい場合がある。また、ユーザにとっても、通知されるはずの情報が通知されなかったということは避けたいのは当然である。例えば、いつも楽しみにしていた短編小説情報の通知において、11回まで楽しく読んでいたのに、タイミングが合わず、12回が通知されないままとなり、そのあと13回が通知され、悔しい思いをするということはユーザにとって明らかに不利益である。
【0211】
1)と2)はトレードオフの関係にある。1)を重視し、できるだけ好ましいタイミングで通知しようと、情報通知を渋っていても、最適のタイミングの条件を、未来においてユーザが満たすとは限らない。かといって2)を重視し、情報を即時に通知していたのでは、ユーザとタイミングが合わず、見てもらえない可能性が高い。本手法は、このトレードオフの解決法の一つである。本手法により、反応確率を考慮すべき未来の範囲を限定することで、より好ましいタイミングで情報を通知することができ、通知漏れになる可能性も低くできる。本手法により、ユーザがそれほど通知を好まない状況で通知をすることも、通知すべき状況を逃して通知できなくなることも避けることができる。ユーザにより通知が好まれる状況を逃すことなく、通知を好む場所に情報を集中して通知することができる。
【0212】
なお、図42に示されるように、実施の形態1の情報通知装置の構成に加えて、ユーザの行動を予測する行動予測部2210を備えることにより、未来における時刻と場所の範囲を決定し、現在時刻以降を条件とした反応確率を用いたタイミング制御を行っても良い。
【0213】
行動予測部2210は未来におけるユーザの行動を予測する。具体的には、未来におけるユーザのいる場所の変化を予測する。例えば、図43(a)に示されるように、現在ユーザの状況が、時刻11時、場所(会社(デスク))であった場合、13時〜15時には車中、15時〜25時には家にいるというような場所の変化を予測する。
【0214】
通知タイミング制御部2208は、行動予測部2210によって予測されたユーザの場所変化し、現在だけでなく予測された未来における反応確率も用いて通知タイミングの制御を行う。例えば図43(b)の場合、現在11時にはユーザはデスクにいて反応確率は0.75である。13時には車中にいると予測され反応確率は0.0である。15時には家にいると予測され反応確率は0.7である。17時には家にいると予測され、反応確率は1.0である。19時には家にいると予測され、反応確率は0.5である。21時には家にいると予測され反応確率は0.6である。23時には、家にいると予測され、反応確率は0.3である。これらのことから、17時に反応確率が最も高く1.0であるために、情報を17時に家にいるときに通知する。
【0215】
なお、行動予測部2210は、ユーザの行動の履歴、具体的には時刻と場所の変化の履歴を用いて、時刻と場所からなる条件をユーザが満足する確率をそれぞれ計算し、条件発生確率テーブルを作成することで、行動予測を行っても良い。具体的には、ユーザは未来において条件発生確率テーブル中のそれぞれの時刻において最も確率の高い条件を満たすようにユーザは行動するとする。
【0216】
また、条件発生確率テーブルの作成法は、実施の形態2で説明したものと同様であり、条件発生確率テーブルは図20に示されるように、行動履歴蓄積部2403と条件発生確率計算部2404を用いることで作成できる。
【0217】
また、実施の形態1では、タイミング制御部は現在における通知の可否を判断していた。しかし未来の時刻の反応確率を考慮することにより、未来における通知の可否も判断できる。よって、通知情報にタイミング条件を付加し、情報通知部は現在の状況が通知情報に付加されたタイミング条件を満たしたときに、ユーザに通知するようにしても良い。このことにより、タイミング制御部の作業をサーバ側で全て行い、端末には情報通知部を持たせることでタイミング制御を簡易的に行うことも可能になる。例えば、ある情報に対して、未来行動を予測し、通知タイミングを自宅のPCがユーザの行動履歴から計算したところ、「時刻(17〜19時)かつ場所(デスク)」に通知するのが最適だったとする。このとき、情報自体に「時刻(17〜19時)かつ場所(デスク)」という通知条件を付加し、モバイル端末に入れておくと、通知タイミング計算を端末側が行うことなく、端末が「時刻(17〜19時)かつ場所(デスク)」に情報を通知することができる。このため、計算量やメモリの少ない端末においても、通知タイミングをユーザの状況にあわせて制御することができる。
【0218】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0219】
さらに、本実施の形態では、現在の時刻を条件とした反応確率だけでなく、現在の時刻以降を条件とした反応確率を用いて通知タイミングが制御されるので、より広い範囲で適切な通知タイミングが探索され、ユーザにとっての利便性が向上される。
【0220】
(実施の形態7)
次に、本発明の実施の形態7に係る情報通知装置を説明する。
【0221】
上記実施の形態1においては、通知タイミング制御部は、反応確率テーブルをそのまま通知タイミング制御に利用している。つまり、反応確率が0.8であれば、0.8の確率で通知を行っている。しかし、反応確率を、実際に通知を行う確率である通知確率に変換し、通知確率を用いて通知タイミング制御を行っても良い。つまり反応確率が0.8であったとき、例えば1.0に確率を変換し、1.0の確率で通知を行う。本実施の形態では、反応確率を通知確率に変換し、通知確率を用いて通知タイミング制御を行う場合について説明する。
【0222】
図44は、本発明の実施の形態7に係る情報通知装置の構成を示すブロック図である。なお、図1に示す実施の形態1の情報通知装置と同様の構成については、同一の符号を付し、説明を省略する。
【0223】
情報通知装置は、図44に示されるように、実施の形態1の構成に加えて、通知確率変換部2810を備えている。
【0224】
通知確率変換部2810は、反応確率修正部2806によって出力された反応確率テーブルを通知確率テーブルに変換する。変換は通知確率変換関数を用いて行う。通知確率変換関数fは、反応確率テーブル各条件下における反応確率Pを通知確率P'に変換するための関数f(P'=f(P))である。通知タイミング制御部は、反応確率テーブルではなく、通知確率変換部が修正した図45(c)に示されるような通知確率テーブルに従って、情報を通知する。
【0225】
例えば、図45(b)に示されるように、通知確率変換関数fを
P<0.5のとき、P'=0
0.5<=P<=0.7のとき、P'=P
0.7<Pのとき、P'=1
となるように決定したとする。すると、反応確率テーブルは、この通知確率変換関数fに従って変換される。例えば、条件(11時かつデスク)における通知の可否を判定の場合、図45(a)に示す条件(11時かつデスク)における反応確率は0.75であるため、通知確率変換関数fにより通知確率は1に変換される。よって、通知確率1、つまり条件(11時かつデスク)において情報を必ず通知する。
【0226】
通知確率変換関数fは広義の単調増加関数となるように決定する。つまり、Pが増加すると、P'も増加もしくは変化なしとなるようにfを決定する。これは、反応確率が高いほど、通知に適切なタイミングであるからである。
【0227】
なお、反応確率Pが閾値以下のときは通知確率P'を0となるように通知確率変換関数fを決定しても良い。反応確率が小さいときは、操作ミスや、偶然通知を好んだ場合もあり、ノイズの可能性がある。また、反応確率が小さい条件下では、そもそもユーザはその条件下ではそれほど通知して欲しいとは思っておらず、むしろ通知しない方がユーザに好まれることが多い。通知を行うということはユーザのプライバシーに介入するということであり、ユーザに負担をかけるものである。敢えて通知をしないということも重要なのである。
【0228】
また、反応確率Pが閾値以上のときは、通知確率P'が100%となるように通知確率変換関数fを決定しても良い。反応確率が100%となっていなくても、操作ミスや、偶然通知を嫌がった、通知に気づかなかったというノイズの可能性がある。また、中途半端な確率で情報を通知するより、100%で通知した方が良い場合が多々ある。例えばタイミング制御を行い、朝8時に90%の確率で連続小説を通知していたとする。ユーザはその情報を見るときもあれば、見ないときもある。しかし、今まで朝8時という条件下で通知されていた連続小説が、残りの10%のために、たまたま通知されず装置の仕様のために見逃すことがあったら、ユーザには不便である。ある程度以上の反応確率をもったものは100%で通知した方がユーザにとって便利であると考えられる。
【0229】
また、時刻や場所からなる条件の発生確率が低いものに対しては、全体的に通知確率P'を上げるように通知確率変換関数fを補正しても良い。発生確率が低い条件に関しては、条件を満たしたときにすぐ通知しないと、その条件自体が発生しにくいため、通知しようとしていた情報を全く通知できない可能性がある。これは上記実施の形態2と同様に条件発生確率テーブルを作成し、条件発生確率が装置作成者が決定した閾値より低いときに通知確率P'を上げることで回避することができる。
【0230】
例えば条件「場所変化(スキー場)」のときにスキー情報を通知したときの反応確率が60%であったとする。反応確率がそれほど高くないため、通知したとしても、ユーザは通知に気づいてくれないかもしれない。しかし、「場所変化(スキー場)」という条件がユーザにとってほとんど発生しないものだとすると、そのタイミングで通知しないとユーザにとって有益な情報である可能性があるスキー情報を永久に通知できない可能性がある。よって、そのイベントの発生確率からバイアスをかける、つまり発生確率の低さから通知確率を例えば100%にすることで、情報の通知漏れを防ぎ、ユーザに比較的好ましいタイミングで、通知することができる。
【0231】
また、通知に対して反応を返す度合いが多く、通知をそれほど好まない状況においても反応確率が高いユーザもいれば、通知に対してほとんど反応せず、通知を好む状況においても反応確率が低いユーザもいる。どのようなユーザに関してもP'の関数を同じにすると、全体的に反応確率が高いユーザは、どのような状況においても通知されてしまう。逆に、全体的に反応確率が低いユーザは、どのような状況においても通知が行われない。これを回避するために、反応確率テーブルにおける反応確率の最小値が高いユーザに対しては、全体的に反応確率Pに対する通知確率P'の値を低くするように通知確率変換関数fを調整しても良い。逆に、反応確率テーブルにおける反応確率の最大値が低いユーザに対しては、全体的に反応確率Pに対する通知確率P'の値を高くするように通知確率変換関数fを調整しても良い。
【0232】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0233】
さらに、本実施の形態では、反応確率テーブルをそのまま通知タイミング制御に利用するのではなく、反応確率を、実際に通知を行う確率である通知確率に変換し、通知確率を用いて通知タイミング制御が行われるので、ユーザの個性を反映した柔軟な情報通知装置が実現される。
【0234】
(実施の形態8)
次に、本発明の実施の形態8に係る情報通知装置を説明する。
【0235】
実施の形態1においては、情報端末によって情報が通知された場合に、通知に対するユーザの反応を検知し、履歴として蓄積している。具体的には、音等のメディアを利用して情報の通知を行い、ユーザがその通知音を止める操作により、ユーザの通知に対する反応を検知している。しかしながら、ユーザは、通知された情報の内容に応じて、その時刻、場所等の状況において、情報の内容を確認するか否かを判断する場合がある。
【0236】
そこで、本実施の形態においては、情報端末による情報の通知から、ユーザの情報の内容を確認・閲覧するまでの操作履歴を、ユーザの情報通知に対する反応履歴として検知し、その内容に応じて情報の通知タイミングを制御する場合について説明する。
【0237】
最初に、情報通知から、ユーザの情報の閲覧までの操作を図46のフローを用いて説明する。
【0238】
まず、通知すべき情報があるかどうかを調べる(ステップS3001)。通知すべき情報がない場合(ステップS3001でNO)は、通知すべき情報ができるまで待つ。一方、通知すべき情報があった場合(ステップS3001でYES)は、通知音やバイブレータなどの通知モダリティにより、通知すべき情報があることをユーザに通知する(ステップS3002)。
【0239】
次に、通知に対して反応があったかどうかを検知する(ステップS3003)。反応とは例えば、ユーザが通知音や通知バイブレータを止める動作である。反応がなかった場合(ステップS3003でNO)、ステップS3001に戻る。一方、反応があった場合(ステップS3003でYES)は、情報のヘッダを表示する(ステップS3004)。情報のヘッダとは情報内容の主題を簡単に表しているものであり、具体的に言うとタイトルである。
【0240】
次に、通知された情報の内容表示の指示がユーザからあったかどうかを検知する(ステップS3005)。例えば、ユーザが通知された情報を選択し、ボタンを押すなどの決定操作をすることで内容表示の指示が行われる。指示がなかった場合(ステップS3005でNO)は、ステップS3001に戻る。一方、指示があった場合(ステップS3005でYES)は、通知された情報の内容を表示する(ステップS3006)。
【0241】
次に、文字数により、通知された情報の内容が一画面で表示できるかどうかを調べる(ステップS3007)。表示できない場合(ステップS3007でNO)は、表示した情報内容に次のページがあることをユーザに知らせる(ステップS3008)。例えば、次ページ指示ボタンを表示する。そして、通知された情報内容の次ページ表示指示があったかどうかを検知する(ステップS3009)。なかった場合(ステップS3009でNO)は、ステップS3009に戻る。一方、指示があった場合(ステップS3009でYES)、通知された情報内容について、次ページの情報内容を表示する(ステップS3010)。その後ステップS3007に戻る。
【0242】
一方、通知された情報の内容が一画面で表示できる場合(ステップS3007でYES)は、ユーザが内容表示終了を指示したかどうかを検知する(ステップS3011)。入力がなかった場合(ステップS3011でNO)、ステップS3011に戻る。指示があった場合は、通知された情報の内容表示を終了し、フローを終了する。
【0243】
図46のフローを時系列の操作のイベントで表現したものを図47に示す。図47において、まず、装置の動作として「情報通知イベント(符号A)」が発生する。これは図46のステップS3002に対応する。その後、ユーザ操作として「通知に反応イベント」が発生する。これは図46のステップS3003に対応する。その後、装置の動作として「情報ヘッダの表示イベント」が発生する。これは図46のステップS3004に対応する。その後、ユーザ操作として、「詳細内容を表示指示イベント」が発生する。これは図46のステップS3005に対応する。その後、装置の動作として、「情報の内容を表示イベント」が発生する。これは図46のステップS3006に対応する。その後、ユーザ操作として、「詳細内容の表示終了指示イベント」が発生する。これは図46のステップS3011に対応する。その後、装置の動作として「詳細内容の表示終了」イベントが発生する。これは図46のステップS12に対応する。
【0244】
図47に示されるように、情報の通知から情報の閲覧までには、様々なイベントがあり、そのイベントの発生状況、イベント間の時間によって、情報の通知の良否と、情報の内容の良否を共に考慮した情報の通知が実現できる。
【0245】
「情報通知イベント」から「通知に反応イベント」までの反応時間を、通知評価値計算部110が使うことで、通知の良否判定に用いることができる。また「情報ヘッダの表示イベント」から「詳細内容表示指示イベント」までの反応時間を通知評価値計算部110が使うことで、通知内容の良否判定に用いることができる。通知した状況において通知内容が悪かった場合、ユーザは通知に反応したとしても、情報ヘッダを閲覧するだけで、詳細内容表示指示は行わないか、行っても反応時間が長いであろう。しかし、通知した状況において通知内容が良かった場合、ユーザは情報ヘッダを閲覧した後、詳細内容表示指示を行い、詳細内容を閲覧する。「情報ヘッダの表示イベント」から「詳細内容表示指示イベント」までの反応時間を通知内容の良否判定に用いることで、内容について評価させるなどユーザの負担をかけずに、状況に応じて通知内容を変更することができる。
【0246】
図48は、本発明の実施の形態8に係る情報通知装置の構成を示すブロック図である。
【0247】
情報通知装置は、時刻検知部100、場所検知部101、反応検知部3202、反応履歴蓄積部3203、通知評価値計算部110、内容評価値計算部3205、通知情報蓄積部107、通知タイミング制御部3208、および情報通知部109を備えている。なお、時刻検知部100、場所検知部101、通知情報蓄積部107、情報通知部109は、実施の形態1と同様の動作を行うものであるので、説明を省略する。
【0248】
反応検知部3202は、情報の通知に対する一連のユーザの反応をユーザの通知機器に対する操作により検知する。具体的には、図46のフローに示すイベントの有無と各イベント間の時間である。
【0249】
反応履歴蓄積部3203は、情報通知部109が情報の通知を行ったときに時刻検知部100で検知された時刻と、情報の通知を行ったときに場所検知部101で検知されたユーザの場所と、反応検知部3202で検知されたユーザの反応を蓄積する。実施の形態1においては、図2に示されるように、通知に対して最初に反応するまでの時間、例えば情報通知イベントから通知に反応イベントまでの時間を反応履歴として蓄積していたのに対して、本実施の形態においては、さらに、情報ヘッダの表示イベントから詳細内容表示指示イベントまでの反応時間という履歴を蓄積している。蓄積している情報の例を図49に示す。
【0250】
通知評価値計算部110は、通知に対する評価を計算する。つまり、通知を行った時刻と場所が適切であったかどうかを表す通知評価値を条件ごとに計算し、通知評価値テーブルを作成する。例えば、実施の形態1の反応確率計算部104と同様に、反応確率計算部3204が反応履歴蓄積部3203に蓄積されている反応履歴からユーザの情報通知に対する反応確率を計算し、反応確率テーブルを作成する。
【0251】
内容評価値計算部3205では、通知した情報内容に対する評価を計算する。つまり、通知を行った時刻と場所において、通知した情報内容が適切であったか否かを示す内容評価値を条件ごとに計算し、図50(b)に示されるような内容評価値テーブルを作成する。例えば、反応履歴蓄積部3203に蓄積されている反応履歴から、ユーザの情報内容に対する反応確率を計算する。例えば、情報ヘッダの表示イベントから詳細内容表示指示イベントまでの反応時間が閾値より短い反応履歴を反応あり、長い反応履歴を反応なしとして、反応確率を計算する。例えば閾値はヘッダ情報を閲覧するのにかかる最大時間として60秒とする。そして条件ごとに反応確率を計算し、内容評価値テーブルを作成する。図50は、内容評価値テーブルの作成法を表したものである。例えば、図50(a)に示されるように、通知内容がジャンル「スポーツ」である場合において、時刻(11時〜13時)かつ場所(家)において、反応あり履歴が4個あり、反応なし履歴が1個あることから、反応確率つまり内容評価値は0.8である。よって、内容評価値テーブルのジャンル「スポーツ」かつ時刻(11時〜13時)かつ場所(家)における内容評価値は0.8となる。
【0252】
通知タイミング制御部3208は、通知評価値計算部110で作成された通知評価値テーブルと内容評価値計算部3205で作成された内容評価値テーブルを記憶する。通知タイミング制御部3208は、時刻検知部100で検知された現在時刻、場所検知部101で検知された現在場所と、記憶している通知評価値テーブルおよび内容評価値テーブルを用いて、通知情報蓄積部107に蓄積された情報の通知タイミングを制御し、当該情報を情報通知部109に出力する。
【0253】
具体的には、まず現在の時刻と場所において、通知すべきかどうかについて通知評価値テーブルを用いて判断する。例えば、実施の形態1と同様に、現在の時刻と場所に対応する通知評価値つまり通知反応確率に従って、現在における情報の通知の可否を決定する。通知しないことが決定された場合、情報通知は行わない。通知することが決定された場合、現在の時刻と場所に対応する内容評価値と通知情報蓄積部107に蓄積された情報の情報内容に従って、通知する情報を決定する。例えば、通知情報蓄積部107に蓄積された情報のうち、内容評価値が最も高い情報について、内容評価値が閾値以上であるならばその情報を通知する。通知することが決定された場合における通知情報の決定法を図51を用いて説明する。図51(a)、(b)に示されるように、現在の状況が時刻(11時)、場所(家)であり、通知情報蓄積部107にジャンル「スポーツ」「経済」「食事」の情報が蓄積されていたとする。このとき、内容評価値テーブルから時刻(11時〜13時)かつ場所(家)におけるジャンル「スポーツ」「経済」「食事」の内容評価値を参照する。この場合、図51(c)に示されるように、「スポーツ」が0.8、「経済」が0.3、「食事」が0.7である。よって最も内容評価値の高い「スポーツ」の情報を通知する。
【0254】
以上のように構成された情報通知装置の動作フローを図52のフローチャートを用いて説明する。ここでは、通知タイミング制御部3208が記憶する評価値テーブルの初期値は装置設計者が予め定めておくものとする。なお、初期値は、ランダム値でも良いが、一般的なユーザの反応履歴から、図53に示す評価値テーブル更新フローにより、予め理想的な評価値テーブルを作成しておいても良い。
【0255】
通知タイミング制御部3208は、現在の状況、つまり時刻検知部100で検知された現在時刻と場所検知部101で検知された現在場所を監視し、現在の状況が変化したか否かを判断する(ステップS7201)。現在の状況が変化しない場合(ステップS901でNO)は、そのまま監視を続ける。
【0256】
一方、現在の状況が変化した場合(ステップS7201でYES)、すなわち時刻または場所の変化を検知すると、通知情報蓄積部107に蓄積されている情報について、通知タイミング制御部3208は、自身が記憶している通知評価値テーブルを参照し、時刻検知部100で検知された現在時刻と場所検知部101で検知された現在場所を条件とした通知評価値に従って、通知の可否を判断する(ステップS7202)。
【0257】
そして、通知タイミング制御部3208が情報の通知の可否を判断した結果、通知不可であった場合(ステップS7203でNO)は、現在の状況の監視を行う(ステップS7201)。一方、通知タイミング制御部108が情報の通知の可否を判断した結果、通知可であった場合(ステップS7203でYES)は、通知情報蓄積部107に蓄積されている情報について、通知タイミング制御部3208が、自身が記憶している内容評価値テーブルを参照し、時刻検知部100で検知された現在時刻と場所検知部101で検知された現在場所を条件とした内容評価値に従って、通知情報蓄積部107に蓄積された情報のうち、どの情報を通知するかを決定する(ステップS7204)。そして、通知タイミング制御部3208は、通知が決定した情報を情報通知部109に出力し、情報通知部109が通知音やバイブなどの通知モダリティによって、ユーザに情報を通知する(ステップS7205)。
【0258】
次に、通知した情報に対するユーザの反応情報を用いて、通知タイミング制御部3208が記憶している評価値テーブルを更新する(ステップS7206)。詳細は図53のフローチャートにて述べる。
【0259】
そして、装置の動作を終了しない場合(ステップS2707でNO)は、現在の状況の監視を行う(ステップS7201)。終了する場合(ステップS7207でYES)はフローを終了する。
【0260】
次に、情報通知後におけるユーザの反応を用いた評価値テーブル更新動作を図53のフローチャートを用いて説明する。
【0261】
反応検知部3202は、情報を通知したときのユーザの反応を検知する(ステップS7301)。ここで、反応検知部3202は、一定時間待って、反応がなかった場合も、「反応なし」を検知したことにする。
【0262】
次に、反応検知部3202は、時刻検知部100で検知された情報の通知を行った時刻から当該通知に対する反応があった時刻までの時間を計測し、情報通知を行ったときの時刻と、情報通知を行ったときに場所検知部101で検知された場所と共に、反応履歴蓄積部103に登録する(ステップS7302)。
【0263】
次に、情報通知部109が通知情報のヘッダ表示を行い、反応検知部3202は、通知情報のヘッダ表示に対するユーザの詳細内容表示指示反応を検知する(ステップS7303)。ここで、一定時間待って、反応がなかった場合も、「反応なし」を検知したことにする。なお、ステップS7301にて、一定時間反応がなかった場合は、通知情報のヘッダ表示を行わず、何も検知しなかったこととしてステップS7305に進んでよい。
【0264】
ユーザの反応を検知すると、反応検知部3202は、時刻検知部100で検知された通知情報のヘッダ表示を行った時刻から当該通知に対する詳細内容表示指示反応があった時刻までの時間を計測し、情報通知を行ったときの時刻と、情報通知を行ったときに場所検知部101で検知された場所と共に、反応履歴蓄積部103に登録する(ステップS7304)。
【0265】
通知評価値計算部110は、反応履歴蓄積部3203に蓄積されている反応履歴から、通知評価値を計算し、通知評価値テーブルを生成する(ステップS7305)。次に、内容評価値計算部3205は、反応履歴蓄積部3203に蓄積されている反応履歴から、内容評価値を計算し、内容評価値テーブルを生成する(ステップS7306)。
【0266】
そして、通知評価値計算部110によって作成された通知評価値テーブルと内容評価値計算部3205によって作成された内容評価値テーブルに従って、通知タイミング制御部3208が記憶している通知評価値テーブルと内容評価値テーブルを更新する(ステップS7307)。
【0267】
以上の動作の結果、情報通知に対するユーザの一連の反応履歴から。ユーザが情報を閲覧できるタイミングと情報内容を制御した情報通知を実現することができるようになる。
【0268】
なお、本実施の形態8においては評価値テーブルの修正を行っていないが、実施の形態1のように通知評価値テーブルと内容評価値評価値テーブルを修正規則により修正しても良い。具体的には図54に示されるように、実施の形態8の構成に、通知評価値修正部111、反応確率修正部106、内容評価値修正部3711、修正規則蓄積部105を追加することで実現できる。これにより、履歴の得られていない条件においても他の条件から推定を行い、通知する内容を適切に決定することができる。
【0269】
内容評価値修正部3711は、修正規則蓄積部105に蓄積された修正規則により、内容評価値計算部3205にて作成された内容評価値テーブルを修正する。修正規則については、通知評価値テーブルを修正する場合と同様に、実施の形態1、2、3、4で述べた汎化規則、履歴使用規則といった修正規則を用いることが出来る。
【0270】
例えば図55(a)に示されるような内容評価値テーブルが存在した場合、条件「時刻(9時〜11時)かつ場所(家)」に適合する状況において、条件を汎化し、図55(b)に示されるような条件「場所(家))」を作成する。汎化した条件「場所(家)」における内容評価値「0.85」(図50(a)における場所(家)の反応ありデータ数11/場所(家)における履歴データ数13)を用いて、汎化前の条件「時刻(9時〜11時)かつ場所(家)」下における内容評価値を更新する。例えば汎化した条件下の反応確率をそのまま用いて「0.85」に更新する。
【0271】
また、本実施の形態8においては、通知評価値テーブルと内容評価値テーブルの間に直接的な関連はなかったが、内容評価値テーブルの評価値によって、通知評価値テーブルの評価値を更新しても良い。具体的には、ある条件における内容評価値がある閾値以上、例えば内容評価値のとりうる値の最大値以上であった場合、その条件における通知評価値を高くする、例えば通知評価値の最大値とする。例えば、時刻(8時)かつ場所(家)において通知を行った際に通知に対する反応時間は長く、通知評価値が低かったとする。しかし、時刻(8時)かつ場所(家)におけるジャンル(天気)情報の内容評価値は非常に高かったとする。こういった場合、ユーザは忙しく通知に対してあまり良い反応はしないが、天気情報であれば閲覧するということが考えられる。しかし、通知評価値が低いため、実施の形態2では通知できなくなってしまう。内容評価値によって通知評価値を最大値とすることで時刻(8時)かつ場所(家)において天気情報を通知することができる。
【0272】
また、本実施の形態8においては、情報ヘッダ表示イベントから情報内容詳細指示イベントまでの時間によって通知内容評価値を決定している。しかし、ユーザの情報内容の閲覧時間により通知内容評価値を決定してもよい。例えば、ユーザがスポーツの情報を欲していたときは、熱心に見るため閲覧時間も長くなるであろうし、欲していないときは閲覧もおざなりになり閲覧時間は短くなる。具体的には、閲覧時間が長いものを反応あり、短いものを反応なしとして反応確率を計算する。
【0273】
これにより、情報内容のヘッダ表示と詳細表示がないメディアにおいても、情報の閲覧開始から閲覧終了までの時間を用いることにより通知内容評価値を決定でき、状況において通知内容を変更することができる。閲覧時間は例えば、図47における情報内容を表示イベント(符号E)から情報の内容表示を終了イベント(符号G)までの時間として、反応検知部3202が検知する。
【0274】
また、内容の良否に関わらず閲覧内容によって情報閲覧時間は異なると考えられる。例えば通知情報に動画や音声情報を含んでいた場合は、時間がかかり、再生時間に依存する。よって、通知情報に付随した動画や音声情報の再生時間情報によって情報閲覧時間からの通知内容評価値計算を変更しても良い。例えば、閲覧時間が再生時間以上であった場合、最後まで動画や音声を閲覧したと考え、内容評価値を上げる。逆に閲覧時間が再生時間未満であった場合、途中で閲覧をやめたか、早送りをしたと考えられるため、内容評価値を下げる。これにより、動画や音声情報が閲覧に時間がかかるため、内容評価値が高くなってしまい、ユーザが閲覧したくもないのに通知されてしまうことを防ぐことができる。
【0275】
また、情報内容によって閲覧時間は異なると考えられる。例えば、あるユーザはニュース情報を閲覧するのは10分程度かかるが、スポーツ情報を閲覧するには見出しだけ閲覧するので2分程度しかかからないかもしれない。しかし別のユーザはニュース情報を閲覧するのに10分程度かかるが、スポーツ情報を閲覧するには詳細をじっくり見るので15分程度かかるかもしれない。よって、ユーザのある情報内容についての閲覧時間履歴からピーク値を抽出し、基本閲覧時間としてもよい。例えば、ユーザのスポーツ情報の閲覧時間の履歴が10分程度に集中しており、ピーク値が10分であったとする。このとき基本閲覧時間は10分であり、閲覧時間が10分以上のときの内容評価値を上げ、10分未満のときの内容評価値を下げる。これにより、ユーザがスポーツの情報がニュースの情報より読む時間が長いからといって、毎回スポーツの情報が通知され、ニュースの情報が通知されないということを防ぎ、状況に応じて適切な内容のコンテンツが通知されるようになる。
【0276】
また、本実施の形態8においては、図47に示されるようなイベントを用いて、情報内容の詳細情報を閲覧するまでの反応時間により、内容評価値を計算している。しかしユーザは情報の詳細内容を見たあとで、内容が悪いと判断することもあるだろう。よって、図56に示されるように、情報の詳細内容を表示(符号E)し、ユーザに評価ボタンにより情報の良否を入力(符合F)させることで内容評価値を得ても良い。この場合、図57に示されるようなフローになり、ステップS3001からステップS3010までは図46と同様であり、ステップS3011、ステップS3012に換えてステップS3911のようにユーザが評価ボタンを入力したのかを判断するステップとなる。
【0277】
この場合、内容評価値計算部3205は、例えば、良ボタンが押された数を良ボタンもしくは否ボタンが押された数で割った値を内容評価値として計算する。
【0278】
また、本実施の形態8においては、図47に示されるようなイベントを用いて通知に反応するまでの時間により、通知評価値を計算している。しかし、ユーザにとって邪魔な通知音を止めるだけで情報は全く閲覧するつもりはない、つまり通知に反応はしても情報のヘッダすら閲覧しないことがある。このようなときには、通知すべきではないが、本実施の形態8ではヘッダ情報すらユーザが閲覧していないことを検知することができない。よって、図58に示されるように、「情報ヘッダの表示指示イベント(符号I)」と「情報ヘッダの表示イベント(符号C)」を導入することで。これを検知することができる。情報ヘッダの表示指示イベントの有無や通知イベントから情報ヘッダ表示指示イベントまでの時間履歴を用いることによって、通知すべきでないときを、より詳細に検知することが可能になる。具体的には、情報通知(符号A)後、情報ヘッダの表示指示イベント(符号I)がなかった場合、通知評価値を下げる。情報通知(符号A)後、情報ヘッダの表示指示イベント(符号I)があった場合、通知イベント(符号A)から情報ヘッダ指示イベント(符合I)までの時間が閾値より短かった場合は通知評価値を上げ、閾値より長かった場合は下げる。例えば、時刻(7時)かつ場所(家)で通知したときに、ユーザが通知音を止め、通知に反応したとしても、ユーザからの情報ヘッダの表示指示イベント(符号I)がなかった場合、情報を閲覧するつもりはないと推測されるため、時刻(7時)かつ場所(家)における通知評価値を下げる、具体的には反応なしとして反応確率を計算する。また、時刻(9時)かつ場所(家)で通知したときに、ユーザが通知音を止め、通知に反応し、ある時間以内にユーザからの情報ヘッダの表示指示イベント(符号I)があった場合、時刻(9時)かつ場所(家)における通知評価値を上げる、具体的には反応ありとして反応確率を計算する。これにより、同じように通知に反応したとしても、ユーザが情報を閲覧するつもりのある時刻(9時)かつ場所(家)に通知を行い、ユーザが情報を閲覧するつもりのない時刻(7時)かつ場所(家)に通知を行うことを防ぐことができる。
【0279】
また、情報通知イベント後、ユーザの情報内容閲覧イベント以前のユーザ反応を通知評価値に影響する反応、ユーザの情報内容閲覧イベント後のユーザ反応を通知内容評価値に影響するものとしても良い。例えば、情報通知イベント後、ユーザの情報内容閲覧イベント以前に、情報通知装置の電源を切った場合は、通知評価値を小さくするが、ユーザの情報内容閲覧イベント後に情報通知装置の電源を切った場合は通知内容評価値を小さくする。
【0280】
ここで、情報内容閲覧イベントとは、ヘッダ情報が閲覧できる場合は、情報のヘッダ表示イベント(符号C)であり、閲覧できない場合は情報の内容を表示イベント(符号E)である。
【0281】
例えば、9時にスポーツ情報をユーザに通知した直後にユーザが電源を切ったとする。このときスポーツという情報内容に関わらず、ユーザは情報を通知して欲しくない状況であったと考えられる。会議情報という情報内容であっても、ユーザは情報を通知して欲しくなかったであろう。通知直後であり内容閲覧前の反応から9時という状況に対しては、タイミングが悪いという評価情報が生成できる。また、11時にスポーツ情報をユーザに通知した際に、ユーザは内容を閲覧した後に電源を切ったとする。このとき、内容を閲覧したことから、情報を通知してもよい状況であったかもしれない。しかし、閲覧後電源を切ったことから、少なくともスポーツという情報を通知するには悪い状況であったと考えられる。しかし、内容閲覧を行ったことから、ユーザはその状況において何らかの内容の情報を求めており、もしかすると会議のスケジュールという内容の情報を通知するには適切な状況であった可能性もある。内容閲覧の前後の反応に分割することで、効率的に学習を進めることが可能になる。
【0282】
また、本実施の形態8においては、情報ヘッダ表示から情報内容詳細表示指示までの反応時間によって通知内容評価値を計算している。しかし、内容閲覧中のユーザの行動によって通知内容評価値を計算しても良い。例えば、情報内容が一画面で表示できなかった場合、次ページをスクロールバーや次ページ表示ボタンにより表示させる。ユーザによってスクロールバーが情報の最後まで閲覧できるように移動されてなかった場合、ユーザは情報を最後まで閲覧する意思がないと推定できるため、通知内容評価値を下げる。同様に、次ページボタンが情報の最後のページが表示されるまで押されていなかったときも、通知内容評価値を下げる。また、1ページあたりの閲覧時間が閾値より短い場合も、内容を読まずに飛ばしたと推定できるため、通知内容評価値を下げる。
【0283】
また、情報内容が動画であった場合、動画再生を途中で止めたときに通知内容評価値を下げる。また、情報内容が音声であった場合、音声の再生を途中で止めたときに通知内容評価値を下げる。
【0284】
ユーザが情報ヘッダを閲覧した後、情報内容詳細指示をすぐに行ったとしても、実際に内容を読んでみるとユーザの欲しい情報ではなく、すぐに閲覧をやめてしまうことがある。しかし、これらの技術を用いることで、より厳密に通知内容評価値を決定することができる。
【0285】
また、実施の形態1において反応履歴蓄積部にジャンル情報も蓄積し、ジャンルの次元も加えて反応確率テーブルを作成し、ジャンルと時刻と場所に対応する反応確率に従って通知を行うことで、情報内容を考慮したタイミング制御を行っても良い。
【0286】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0287】
さらに、本実施の形態では、情報端末による情報の通知からユーザの情報の内容を確認・閲覧するまでの操作履歴をユーザの情報通知に対する反応履歴として検知し、その内容に応じて情報の通知タイミングが制御されるので、反応履歴がきめ細かくなり、より高い精度で、通知タイミングが決定される。
【0288】
(実施の形態9)
次に、本発明の実施の形態9に係る情報通知装置を説明する。
【0289】
上記各実施の形態においては、反応履歴から通知してもよい状況を推測し、その状況において通知を行っているだけである。しかしながら、効率的に通知タイミングを学習するためには、どのような状況における反応履歴が必要なのかを計算し、意図的に通知を行う必要がある。
【0290】
タイミング制御において学習の目的とするところは次の二点である。1)通知評価値テーブル、内容評価値テーブルといった評価値テーブルの評価値の空欄を埋めることと、2)評価値テーブルの評価値をより特徴的な値、つまり偏りがある値にすることである。意図的に学習するとは、この2点を目的として、装置の側から自律的に通知し、履歴を得ることである。
【0291】
本実施の形態では、どのような状況における反応履歴が必要なのかを計算し、意図的に通知を行う場合について説明する。
【0292】
具体的には、図59に示されるように、学習有効値計算部4604と学習有効値計算規則蓄積部4605を加えることで実現できる。
【0293】
学習有効値計算部4604は、反応履歴蓄積部103に蓄積された履歴から、時刻や場所によって構成される条件について、どの条件下において通知するのが学習にとって有効であるかを示す学習有効値テーブルを、学習有効値計算規則蓄積部4605に蓄積された規則に従って作成する。
【0294】
学習有効値計算規則蓄積部4605は、学習有効値テーブルを作成するための規則を蓄積する。規則には、例えば、履歴数依存規則と汎化条件履歴数依存規則が存在する。
【0295】
(1)履歴数依存規則
履歴数依存規則とは、反応履歴蓄積部103に蓄積された、各条件下における反応履歴の履歴数に応じて学習有効値を変化させる規則である。基本的に履歴数の少ない条件下の学習有効値を高く、履歴数の多い条件下の学習有効値を低くする。例えば、図60の場合、時刻(11時〜13時)かつ場所(会議室)における履歴データ数は0であり閾値より少ない。このとき時刻(11時〜13時)かつ場所(会議室)における学習有効値に装置設計者が決定した規定値例えば0.3を足す。この規則により、評価値テーブルにおいて履歴が少なくて反応確率が満足に得られない条件下において優先的に通知を行い、学習を促すことができる。
【0296】
(2)汎化条件履歴数依存規則
汎化条件履歴数依存規則とは、履歴数依存規則を、学習有効値を求めたい条件における履歴数ではなく、その条件を汎化した汎化条件下における履歴数に応じて学習有効値を変化させる規則である。例えば、図61の場合、時刻(11時〜13時)かつ場所(会議室)における学習有効値を求めたい。このとき、汎化した条件、場所(会議室)における履歴数が2であり、閾値より少ない。よって、時刻(11時〜13時)かつ場所(会議室)における学習有効値に規定値に例えば0.3を足す。これにより、時刻(11時〜13時)かつ場所(会議室)において通知を行うことで、時刻(11時〜13時)かつ場所(会議室)だけでなく、場所(会議室)における履歴も得られるため、双方の評価値テーブルを埋めることができる。図61の場合、時刻(13時〜15時)かつ場所(車中)における履歴データ数はないが、場所(車中)における履歴データは十分に存在する。このため、時刻(13時〜15時)かつ場所(車中)において通知を行ったとしても時刻(13時〜15時)かつ場所(車中)の評価値テーブルしか埋めることができない。汎化条件履歴数依存規則を用いることで、時刻(11時〜13時)かつ場所(会議室)における通知を優先することができる。
【0297】
通知タイミング制御部4607は、学習有効値計算部4604が作成した学習有効値テーブルに従って、通知タイミングを制御し、通知情報を情報通知部に出力する。例えば、現在の時刻と場所を条件としたときの学習有効値に依存した確率により、通知の可否を決定する。例えば、時刻(11時〜13時)かつ場所(会議室)における学習有効値が0.3であった場合、0.3の確率で情報を通知する。
【0298】
以上のように構成された情報通知装置の動作フローを図62のフローチャートを用いて説明する。ここでは、通知タイミング制御部4607が記憶する学習有効値テーブルの初期値は装置設計者が予め定めておくものとする。なお、初期値は、ランダム値でも良いが、実施の形態1と同時に用いる場合は、一般的なユーザの反応履歴から、図10の反応確率テーブル更新フローにより、予め理想的な反応確率テーブルを作成し、それを学習有効値テーブルとしてもよい。
【0299】
ステップS901、ステップS903、ステップS904およびステップS906に関しては、実施の形態1と同様なので省略する。
【0300】
現在の状況が変化した場合(ステップS901でYES)に、すなわち時刻もしくは場所の変化を検知すると、通知情報蓄積部107に蓄積された情報について、通知タイミング制御部4607は、自身が記憶している学習有効値テーブルを参照し、時刻検知部100で検知された現在時刻と場所検知部101で検知された現在場所を条件とした学習有効値に従って、通知の可否を判断する(ステップS7502)。
【0301】
また、情報通知部109が通知音やバイブなどの通知モダリティによって、ユーザに情報を通知(ステップS904)した後、通知した情報に対するユーザの反応情報を用いて、通知タイミング制御部4607が記憶している学習有効値テーブルを更新する(ステップS7505)。詳細は図63のフローチャートにて述べる。
【0302】
情報通知後におけるユーザの反応を用いた学習有効値テーブル更新動作を図63のフローチャートを用いて説明する。
【0303】
ここで、ステップS1001、ステップS1002に関しては実施の形態1と同様なので省略する。
【0304】
反応検知部102における登録処理(ステップS1002)の後、学習有効値計算部4604は、反応履歴蓄積部103に蓄積されている反応履歴から、履歴数を計算し、履歴数テーブルを生成する(ステップS7603)。次に、学習有効値計算部4604は、学習有効値計算規則蓄積部4605に蓄積されている汎化条件履歴数依存規則により、履歴数テーブルから各汎化条件における履歴数を計算し、履歴数に応じて学習有効値を計算し、学習有効値テーブルを作成する(ステップS7604)。そして、学習有効値計算部4604は、学習有効値計算規則蓄積部4605に蓄積されている履歴数依存規則により、履歴数テーブルの各条件下における履歴数に応じて学習有効値を修正し、学習有効値テーブルを変更する(ステップS7605)。次に、学習有効値計算部4604によって作成された学習有効値テーブルによって、通知タイミング制御部4607が記憶している学習有効値テーブルを更新する(ステップS7606)。
【0305】
以上の動作により、ユーザの情報通知の反応履歴を意図的に得られるような情報通知を実現することができるようになる。
【0306】
なお、本実施の形態9における学習有効値計算規則蓄積部は、次に示す特化規則を持っていても良い。
【0307】
特化規則は、ある条件の複数の汎化条件下における評価値が中間値(0.5)など、非特徴的な値であった場合、元の条件下における学習有効値を高くする規則である。例えば図64に示されるように、時刻(11時〜13時)かつ場所(会議室)の条件下において、履歴数がほとんどなかったとする。汎化条件時刻(11時〜13時)における反応確率は0.44、汎化条件場所(会議室)における反応確率は0.55であり、反応確率の中間値0.5との差が閾値0.1以下であり非特徴的な値であるため、通知の可否がわからない。よって、より評価値テーブルを特徴的にするために、時刻(11時〜13時)かつ場所(会議室)において反応履歴を得たい。よって時刻(11時〜13時)かつ場所(会議室)における学習有効値を高くする、例えば設計者が決定した規定値0.5を加える。時刻(11時〜13時)かつ場所(会議室)において通知を行うことで、通知評価値を埋めることができるため、汎化条件では通知の可否がわからないところでも、今後判断できるようになる。
【0308】
また、本実施の形態9における学習有効値計算規則蓄積部は、次に示す条件発生確率依存規則を持っていても良い。
【0309】
条件発生確率依存規則とは、学習有効値を求めたい条件の条件自体の発生確率に応じて学習有効値を変化させる規則である。例えば場所(家)という条件の発生確率とは、情報通知装置が稼動している全時間において、ユーザが家にいる確率である。例えば時刻(9時〜11時)という条件の発生確率は2/24である。発生確率の低い条件における通知の可否は重要であり、直ちに埋めるべきである。例えば、場所(病院)における薬情報の通知の可否は重要であるが、場所(病院)という条件はほとんど発生しない。また、場所(スキー場)におけるスキー情報の通知の可否は重要であるが、場所(スキー)という条件はほとんど発生しない。その上、発生確率の低い条件は条件を満たしたときに通知を直ちに行わないと、条件を満たす状況がほとんど起こらないため、評価値テーブルをなかなか埋められなくなってしまう。
【0310】
条件発生確率依存規則では、条件発生確率が高いものは学習有効値を低く、条件発生確率が低いものは学習有効値を高くする。これにより、発生しにくい条件時に優先的に通知することになり、評価値テーブルを効率的に埋めることができる。
【0311】
具体的に図65を用いて説明する。例えば時刻8時には出社しているため、時刻(9時〜11時)かつ場所(家)という条件において条件発生確率は0.05となり、閾値より低かったとする。しかし、時刻(9時〜11時)に場所(家)にいるということは遅刻寸前であり、直ちに会社情報を通知すべきであるかもしれない。よって、通知の可否を判断すべく、直ちに履歴を得る必要がある。このため、学習有効値を高くする必要がある。
具体的には、時刻(9時〜11時)かつ場所(家)における学習有効値に規定値、例えば0.3を加える。
【0312】
これにより、条件「時刻(9時〜11時)かつ場所(家)」が発生したときに直ちに通知を行うことができるため、発生確率が低さからいつまでも「時刻(9時〜11時)かつ場所(家)」の評価値が埋まらないという現象を防ぐことができるため、次に条件「時刻(9時〜11時)かつ場所(家)」を満たしたときには会社情報を通知できるようになる。
【0313】
この規則を用いるためには、各条件における条件発生確率を計算した条件発生確率テーブルが必要である。これは、上記実施の形態2に述べたように、ユーザの行動履歴、例えば時刻と場所の変化の履歴を保存することにより、計算できる。
【0314】
また、本実施の形態9における学習有効値計算規則蓄積部は、次に示す要因推定規則を持っていても良い。
【0315】
要因推定規則とは、ある条件下における反応確率が中間値(0.5)など、非特徴的な値であった場合、その条件下において発生確率の高いイベントを通知開始イベントとするときの反応確率を高くする規則である。具体的には、各条件における場所変化、ユーザの状態変化といったイベントの発生確率テーブルを行動履歴から計算することで実現できる。
【0316】
例えば、図66に示されるように、時刻(11時〜13時)かつ場所(会議室)において反応確率が0.5であり、通知の可否がわからなかったとする。こういった場合、条件の要素である時刻や場所とは別の要因が通知に対する反応の違いに現れていると考えられる。例えば、時刻(11時〜13時)かつ場所(会議室)の間に起こったイベントよっても反応は異なると考えられる。よって、その条件時に起こったイベントを探索し、そのイベントが起こったときにのみ通知すると反応確率により特徴が出るのではないかと考えられる。つまり、その条件時における発生確率の高いイベントを通知開始イベントとして通知するように、学習有効値を高くする。図66の場合会議室に入るという場所変化イベントの起こる確率が高いことから、場所変化イベントを通知開始イベントとする学習有効値テーブルの時刻(11時〜13時)かつ場所(会議室)における学習有効値を高くする。
【0317】
これにより、会議室に入った直後は通知を好むが、その後は通知を好まないユーザがいたとしても、反応履歴から会議室に入った直後にのみ通知を行うことができる。
【0318】
通知開始イベントによって、反応確率テーブルを分割する方が反応確率はより特徴的になる。しかし、通知開始イベントそれぞれに対する反応確率テーブルを埋めるためには学習データが大量に必要になる。通知開始イベントを限定しない反応確率テーブルから、要因推定規則を用いて、学習に必要な条件を推定することで、反応確率が非特徴的な部分を効率的に特徴的な値にし、通知の可否を判断できる。
【0319】
また、本実施の形態9における学習有効値による通知タイミング制御は、上記各実施の形態と同時に用いて、通知評価値テーブルを作成する補助的な役割として用いてよい。このとき履歴数が少ない間は、学習有効値及び通知評価値によって情報が通知されるが、履歴数が増えるに従って、学習有効値が下がるため、通知評価値のみによって情報が通知されるようになる。
【0320】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0321】
さらに、本実施の形態では、どのような状況における反応履歴が必要なのかを計算し、その結果に依存して意図的に通知が行われるので、必要性の高い場合にだけ情報が通知され、利便性の高い情報通知装置が実現される。
【0322】
(実施の形態10)
次に、本発明の実施の形態10に係る情報通知装置を説明する。
【0323】
実施の形態5においては、特に携帯電話などの携帯端末におけるメールの数の制御において、より好ましいタイミングで同時に通知するメールの数を増やすように制御していた。タイミングについては、時刻や場所が変化したときのみに、通知評価値を参照し、メールを通知していた。しかし、携帯端末におけるメールにおいては、友達から食事への誘いのメールや家族からの送迎の依頼メールなど、緊急性をもったメールが多く、できるだけ早く通知することが望まれる。このため、メールを閲覧してもらえる確率の高い時刻や場所では、時刻や場所が変化したとき以外にも受信したメールをユーザに通知する必要がある。
【0324】
しかし、いくら読んでもらえるメールの数が多いからといって、メールを受信したタイミングで通知しては、メールの通知回数が多くなり、ユーザにメールを1通通知した後、ほとんど時間も経たないのに、また別の新規メールをユーザに通知してしまうといった自体を引き起こしてしまう。このように携帯端末におけるメールの通知は、音や光、振動により、ユーザのタスクを妨げてしまうため、通知回数を減らすことも必要とされる。つまりできるだけ早く通知するということと、できるだけ他のメールと同時に通知することにより、通知回数を減らすということの両方が求められる。
【0325】
これを実現するにあたって、メールを受信した後、一定時間待ち、その間に来たメールと同時にまとめて通知するという手法が考えられる。しかし、最初のメールを受信した後、必ず一定時間待たなくてはならないという問題がある。また、一定時間後は、ユーザに対してメールを通知してはいけない状況になっている可能性もある。
【0326】
よって本実施の形態では、現在以降における通知評価値及びメールの受信スケジュールを取得する。これらを取得することで、どのタイミングで、メールをまとめて同時に通知することが最適であるかを判断できるため、通知回数を減らしながら、できるだけ早くメールを通知することができる。
【0327】
図67は、本実施の形態における情報通知装置の構成図である。この情報通知装置は、ユーザに対して電子メールの通知を行う情報通知装置であって、時刻検知部100、場所検知部101、反応検知部102、反応履歴蓄積部103、通知評価値計算部110、通知情報蓄積部6707、通知タイミング制御部6708、情報通知部6709、メール蓄積部6710および受信規則蓄積部6711を備える。なお、前記実施の形態1で示した構成要素には同様の符号を付与し、説明を省略する。以下、まず各構成要素について図67、図68を用いて説明し、後に本装置の動作について説明する。
【0328】
通知情報蓄積部6707は、ユーザに対して通知するメール情報を蓄積する。すなわち、通知情報蓄積部6707は、例えば図6に示されるように、情報を識別する「情報ID」、当該情報の発信元のメールアドレスを表す「差出人アドレス」、情報の宛先のメールアドレスを表す「宛先アドレス」、端末の情報受信日時を表す「受信日時」、受信日時例えばタイトルのような当該情報内容を簡単に表す「件名」、実際にユーザに伝えるべき当該情報内容の詳細を表す「情報内容」を蓄積する。情報は、例えば、インターネットや情報発信基地局などの外部ネットワーク媒体120から通知情報蓄積部6707に提供される。ユーザに対して通知したメール情報は、通知情報蓄積部6707から削除される。
【0329】
受信規則蓄積部6711は、メールの受信スケジュールを蓄積する。メールの受信スケジュールとは、日常的に規則的に受信するメールの受信時刻のスケジュールであり、図70に示されるように、スケジュール識別のための「ID」、メールの発信元のメールアドレスを表す「差出人アドレス」、メールを受信する曜日を表す「受信曜日」、メールの主な受信時刻を表す「受信時刻」により構成されている。スケジュールは受信時刻順に並べられている。例えば、ID「001」は差出人アドレス「mailing_list@mailing_list.panasonic.jp」から受信曜日「毎日」、受信時刻「10:00」にメールを受信することを示している。特にメールマガジンなどは、そのメールを受信する曜日、時刻が決まっていることが多い。また、夜寝る前にメールを送信する人や、会社の昼休みにメールを送信する人など、メールの送信時刻が同じ時刻に決まっている人も多い。このため、規則的に受信するメールが数多く存在する。よって、予めユーザやメール配信者の手により、このようなメールの受信スケジュールを作成しておくことができる。
【0330】
通知タイミング制御部6708は、時刻検知部100で検知された現在時刻、場所検知部101で検知された現在場所と、反応確率計算部104によって計算された反応確率を用いて、通知情報蓄積部107に蓄積された情報の通知タイミングを制御し、当該情報をメール蓄積部6710に出力し、情報通知部6709に情報の到着をユーザに知らせるようにする。また、このとき、通知情報蓄積部6707に蓄積された情報を削除する。通知タイミング制御部は、図68のように、通知可能判定部6712、次メール取得部6713、次通知時刻計算部6714、利点計算部6716、通知判定部6717から構成されている。以下、それぞれについて説明する。
【0331】
通知可能判定部6712は、反応確率計算部104が計算した反応確率テーブルから、時刻検知部100、場所検知部101、次通知時刻計算部6714によって指定された時刻、場所において通知を行うことが可能であるか否かを判定する。具体的には、指定された時刻、場所における反応確率が閾値以上であった場合に通知可能、閾値未満であった場合に通知不可と判定する。閾値は、例えば0.5とする。
【0332】
次メール取得部6713は、受信規則蓄積部6711に蓄積されたメールの受信スケジュールと時刻検知部100が検知した現在時刻を用いて、次に端末が取得するメールの受信時刻を取得する未来メール取得部の一例である。例えば、図70に示されるように、メールの受信スケジュールが蓄積されていて、現在時刻が「土曜日」の「11:20」であった場合、土曜日が受信曜日に含まれるID「001」、「003」、「004」「005」…の中で、メールの受信時刻が、現在時刻「11:20」以降であり、最も現在時刻に近傍にあるID「003」の受信時刻「11:30」を次メール受信時刻として取得する。
【0333】
次通知時刻計算部6714は、次メール取得部6713が取得した次メール受信時刻から、場所検知部101が検知した現在場所において、次メール受信時刻以降で最も早く通知可能となる時刻を、通知可能判定部6712を用いて計算する。例えば、図71に示されるように、次メール受信時刻が「11:30」であり、現在の場所は「家」であり、「11:30〜11:59」まで通知不可能であり、「12:00〜12:44」まで通知可能であったとすると、次メール受信時刻以降で、最も早く通知可能となる時刻は「12:00」となる。よって、次通知可能時刻は「12:00」である。
【0334】
利点計算部6716は、次通知時刻計算部6714が算出した次通知可能時刻から、現時点で即座に全てのメールを通知することに対する、次通知可能時刻で次メールも含めて通知することの利点を計算する。ただ、各メールの受信時刻に応じて、メールが遅延することにより失われる利点は異なると思われる。そのため、通知情報蓄積部6707に蓄えられた各メール情報の受信時刻も利点計算に用いる。例えば、次通知可能時刻で次メールも含めて通知することの利点をMとし、次メールも含めて通知することにより、通知回数が一回減るために得られる利点をTとし、メールを通知するのが遅れることにより失われる利点を一通、一分につきDとし、通知情報蓄積部6707に蓄えられた各メールの受信時刻をt(分)、次通知可能時刻をN(分)とすると、具体的にMは次の式で表される。
【0335】
【数1】


【0336】
つまり、利点とは、通知回数が減ることによって得られるメリットから通知情報蓄積部6707に蓄えられた全てのメールに対する、受信時刻からの通知遅延時間によるデメリットを減算したものである。例えば、図72に示されるように、通知回数減による利点Tが100、通知遅延により失われる利点Dが1、次通知可能時刻Nが「12:00」、通知情報蓄積部6707に蓄積されたメールが3通で、受信時刻がそれぞれ「11:00」「11:10」「11:19」だったとする。すると利点Mは、「100−1{(12:00−11:00)+(12:00−11:10)+(12:00−11:19)}=−51」となり、「−51」である。
【0337】
通知判定部6717は、利点計算部6716が算出した利点から、通知情報蓄積部6707に蓄積された全メールを通知するか否かを判定する。具体的には、利点が閾値0より大きいならば、全メールを通知しないと判定し、メールを出力しない。閾値0以下ならば全メールを通知すると判定し、通知情報蓄積部のメールを全てメール蓄積部6710に出力し、情報通知部6709にメールの到着を知らせるようにする。このとき、通知情報蓄積部6707のメールを全て削除する。
【0338】
情報通知部6709は、通知判定部6717が情報を通知すると判定した場合、メールの到着をユーザに光、振動、音などで通知する。例えば、携帯端末がメール着信音を鳴らすことによりメールの到着をユーザに知らせる。
【0339】
メール蓄積部6710は、通知判定部6717が情報を通知すると判定したメールを、ユーザがいつでも閲覧可能な状態として端末内に蓄積する。例えば、メーラーの受信フォルダである。
【0340】
以下、本実施の形態10のフローチャートを、図73を用いて説明する。前記実施の形態1で示した構成要素には同様の符号を付与し、説明を省略する。まず、通知可能判定部6712が、時刻検知部100が検知した現在時刻と、場所検知部101が検知した現在場所から現在の通知可否を判定する(ステップS7301)。情報通知が不可能であった場合、ステップS7301に戻る(ステップS7302のNo)。情報通知が可能であった場合、ステップS7303に進む(ステップS7302のYes)。
【0341】
情報通知が可能であった場合、次メール取得部6713が、時刻検知部100が検知した現在時刻と受信規則蓄積部6711に蓄積された受信スケジュールに従って、次メールの受信時刻を取得する(ステップS7303)。通知可能判定部6712が、場所検知部101における次メール取得部6713が取得した次メール受信時刻以降の通知可否を判定し、その結果から、次通知時刻計算部6714は、次メール受信時刻以降の最も早い通知可能時刻を取得する(ステップS7304)。利点計算部6716は、次通知時刻計算部が算出した次メールの通知可能時刻と、通知情報蓄積部6707に蓄積されたメール情報の受信時刻から、次メールを受信した後、蓄積されたメール情報を一度に通知することの利点を算出する(ステップS7305)。
【0342】
通知判定部6717は、利点計算部6716が算出した利点から現在、通知を行うか否かを判定する(ステップS7306)。通知を行わないと判定したとき、ステップS7301に戻る(ステップS7307のNo)。通知を行うと判定したとき、ステップS7308に進む(ステップS7307のYes)。
【0343】
通知を行うと判定したとき、通知判定部6717は、通知情報蓄積部6707に蓄積された全てのメール情報をメール蓄積部6710に蓄積する(ステップS7308)。通知判定部6717は、通知情報蓄積部6707に蓄積された全てのメール情報を削除する(ステップS7309)。情報通知部6709は、メールの到着をユーザに音や光、振動などで通知する(ステップS7310)。以下実施の形態1と同様である。
【0344】
なお、本実施の形態10では、メールの受信スケジュールの受信時刻には、ばらつきが存在しなかった。しかし、実際のメールではネットワークの配送遅延や、人間の行動の不確定性により、受信時刻にばらつきがある場合が存在する。例えば、10:00〜10:30の間のどれかの時間に来るというメールも存在する。また、受信スケジュールにないメールが来る場合ももちろん存在する。こういった場合、新たにメールを受信したときに、そのメールが受信スケジュールに存在するメールであるか否か、受信スケジュールにあるメールだったとしてもどのメールなのかを特定する必要がある。図74のように、現在時刻が「11:20」であり、「11:16」にメールを一通受信していたとする。このとき、このメールが受信スケジュールID003のメールであったならば、「11:45」までにメールを受信することは予定されず、次メール受信時刻は「12:15〜20」となる。しかし、受信スケジュールID003のメールでなかったならば、「11:45」までにメールを受信する可能性が大いにあるため、次メール受信時刻は「11:20〜11:45」となる。よって受信したメールを受信スケジュールのメールと対応させることが必要である。例えば、実際受信したメールと受信スケジュールのメールで「差出人アドレス」が同一であること、メールの「件名」の文字列の一致性が高さから対応させる。
【0345】
また、本実施の形態10では、情報の内容に関わらず、次のメールと同時に出すか即時に出すかを判断していた。しかし、携帯電話の場合、友達や家族からの食事などの誘いのメールや待ち合わせのときのメールなど即座の返信を求めるいわば即時性の高い情報も存在する。よってメールの内容により、次のメールと同時に出すか即時に出すかを判断してもよい。例えば、差出人アドレスが携帯電話のアドレスになっているもの、ユーザの返信率の高い差出人アドレスからのメールについては、無条件で即時に出すようにしてもよい。また、実施の形態8と同様に内容評価値を計算し、内容評価値の高いメールについては、無条件で即時に出すようにしてもよい。
【0346】
また、本実施の形態10では、ユーザのいる場所は変化しないものとして、未来の反応確率を予測していた。しかし、場所は変化する場合があり、その変化は予測できる。よって、実施の形態6の変形例と同様に行動予測部を備えることにより場所変化を予測し、現在以降の反応確率を用いて、未来の通知の可不可を判断しても良い。
【0347】
また、本実施の形態10では、場所に関わらず端末のメール受信スケジュールは一定とした。しかし、端末の場所により、電波状況や端末の電源のON、OFFは異なり、メールを受信できない場所も存在する。よって、受信スケジュールの受信時刻にメールを受信できないこともある。そこで、携帯電話などの端末の電波状況を監視することにより、各場所に対するメール受信可能か不可能であるかの対応付けを行う。そして、実施の形態6の変形例と同様に行動予測部を備えることにより場所変化を予測し、その場所変化に対応したメール受信可能、不可能の時間区間も予測する。メール受信不可能の場合は受信スケジュールの受信時刻を次に受信可能になる時刻に変更する。
【0348】
例えば、図75に示されるように、受信スケジュールが存在し、電波状況測定などにより、場所とメールの受信状況対応表が作成されていたとする。行動予測部による予測結果は「11:00〜12:20」までユーザが会議室にいることが予測され、「12:20〜13:00」までユーザがデスクにいることが予測されていたとする。このとき、場所とメールの受信状況対応表から会議室ではメール受信不可であり、デスクでは受信可能であるため、図75に示されるように、「11:00〜12:20」まで「メール受信不可能」、「12:20〜13:00」まで「メール受信可能」と予測される。よって、受信スケジュールの「11:30」のメールと「12:15」のメールは受信不可能であると推測されるため、それぞれの受信時刻を受信可能となる「12:20」に補正する。これにより、メールを受信できない場所があったとしても、メールの受信時刻を予測することができる。
【0349】
また、本実施の形態10では、全てのメールを同時に出すか、次のメールを待つかの判定を、通知評価値を用いて、次のメールを通知できる時刻を算出することにより、判定していた。しかし、例えば、未来においても通知できることがわかっている場合、もしくは、反応履歴がないときなどは、通知評価値を計算せず、未来のメールの受信時刻のみを用いて通知するか否かを判定しても良い。このとき、受信時刻が遅いときに通知をするようにする。例えば、現在時刻と次に受信する予定のメールの受信時刻の差が閾値以上であるときに、現在蓄積されている全てのメールを通知すると判定する。
【0350】
なお、昔のメールが何時までたっても通知できなくなる可能性があるため、現在時刻ではなく、通知情報蓄積部に蓄積されたメールの受信時刻を用いても良い。例えば、通知情報蓄積部に蓄積されたメールの受信時刻と未来のメールの受信時刻の差が閾値以上のときに、現在蓄積されている全てのメールを通知すると判定する。
【0351】
また、通知情報蓄積部に蓄積されたメール数を考慮しない場合には、ユーザにメールを通知したときに、同時に大量のメールが通知される可能性がある。このため、ユーザが読みきれない場合がある。よって、通知情報蓄積部に蓄積されたメールの数を判定に用いても良い。例えば、通知情報蓄積部に蓄積されたメールの数が閾値以上のときに、現在蓄積されている全てのメールを通知すると判定する。
【0352】
また、実施の形態10では、現在通知情報蓄積部に蓄積しているメールの内容と次のメールの内容との関連に関わらず、現在メールを通知するか、次のメールを待つかを判断していた。しかし、実際は、同内容のメール、同一送信者からのメールなど関連するメールが同時にまとめて通知される方が、別の内容のメールが同時にまとめて通知されるより、好まれやすい。さらに、内容が関連した複数のメールについて時間を空けて通知されると、関連するメールを思い出さなければならないため、非常に読みづらくなる。よって、現在通知情報蓄積部に蓄積しているメールの内容と次のメールの内容との関連性を用いて、現在通知の是非を判定してもよい。関連性が高いときには、現在通知を行わず、次メール受信まで待つことで、関連するメールをまとめて通知することができる。
【0353】
図76は、現在通知情報蓄積部に蓄積しているメールの内容と次のメールの内容との関連性を用いて現在通知の是非を判定する変形例に係る情報通知装置の構成(ここでは、特徴的な構成要素である通知タイミング制御部8808の構成)を示すブロック図である。通知タイミング制御部8808以外の構成については、実施の形態10と同様である。実施の形態10で示した構成要素には同様の符号を付与し、説明を省略する。以下、まず各構成要素について図76を用いて説明し、後に本装置の動作について説明する。
【0354】
次メール取得部8813は、受信規則蓄積部6711に蓄積されたメールの受信スケジュールと時刻検知部100が検知した現在時刻を用いて、次に端末が取得するメールの受信時刻と差出人アドレスを取得する。例えば、図70のようにメールの受信スケジュールが蓄積されていて、現在時刻が「土曜日」の「11:20」であった場合、土曜日が受信曜日に含まれるID「001」、「003」、「004」「005」…の中で、メールの受信時刻が、現在時刻「11:20」以降であり、最も現在時刻に近傍にあるID「003」の受信時刻「11:30」及び差出人アドレス「syokubano_renraku@jp.panasonic.com」を次メール受信時刻として取得する。
【0355】
関連性判定部8821は、通知情報蓄積部6707に蓄積されたメールの情報と次メール取得部8813が取得したメールの情報を比較し、関連性の有無を判定する。具体的には、次メールの差出人アドレスが蓄積されたメールの差出人アドレスと一つでも一致する場合は、関連性有と判定する。例えば、図77のように通知情報蓄積部6707にメールが蓄積されており、次メール取得部8813が取得したメールの差出人アドレスが、「tuuti_taiming@jp.panasonic.com」であったとする。この差出人アドレスと通知情報蓄積部6707に蓄積されたメールの差出人アドレスを比較すると、ID「003」のメールの差出人アドレスが「tuuti_taiming@jp.panasonic.com」であり、一致するため、関係性有と判定する。実際、差出人アドレスが同じメールは、内容も関連することが多く、まとめて読んだほうがユーザにとって都合が良い場合が多い。例えば、ID003のように、「寝過ごして、見たかったテレビ見逃した・・・撮ってない?」というメールの次に同じ送信者から「ついでに、食事に行かない?」というメールが来た場合、まとめて読んだほうが、ユーザは差出人に対して返信メールをわざわざ2通出す必要はなく、1通だけ出せば良くなる。
【0356】
利点計算部8816は、次通知時刻計算部6714が算出した次通知可能時刻から、現時点で即座に全てのメールを通知することに対する、次通知可能時刻で次メールも含めて通知することの利点を計算する。通知情報蓄積部6707に蓄えられた各メール情報の受信時刻も利点計算に用いる。また、次メールが蓄積されていたメールに関連がある場合、次メールとまとめて通知することに利点が存在するため、関連性判定部8821の関連性判定結果も用いる。例えば、次通知可能時刻で次メールも含めて通知することの利点をMとし、関連性のあるメールをまとめて通知することにより得られる利点をRとし、関連性判定部8821の判定結果をr(関連性有r=1、関連性無r=0)とし、次メールも含めて通知することにより、通知回数が一回減るために得られる利点をTとし、メールを通知するのが遅れることにより、失われる利点を一通、一分につきDとし、通知情報蓄積部6707に蓄えられた各メールの受信時刻をt(分)、次通知可能時刻をN(分)とすると、具体的には、Mは次の式で表される。
【0357】
【数2】


【0358】
つまり、利点とは、関連性のあるメールをまとめて通知すること、通知回数が減ることによって得られるメリットから通知情報蓄積部6707に蓄えられた全てのメールに対する、受信時刻からの通知遅延時間によるデメリットを減算したものである。例えば、図78のように、関連性の有るメールをまとめて通知することにより得られる利点Rが100、通知回数減による利点Tが100、通知遅延により失われる利点Dが1、次通知可能時刻Nが「12:00」、通知情報蓄積部6707に蓄積されたメールが3通で、受信時刻がそれぞれ「11:00」「11:10」「11:19」であり、次メールと関連性があったとする。すると利点Mは、「1*100+100 − 1{(12:00−11:00)+( 12:00−11:10)+( 12:00−11:19)}=−51」となり、「49」である。
【0359】
このような変形例に係る情報通知装置の動作を示すフローチャートを、図79を用いて説明する。実施の形態10で示した構成要素には同様の符号を付与し、説明を省略する。本変形例の情報通知装置では、実施の形態10と同様に情報通知が可能であると判定を行った後、情報通知が可能であった場合、次メール取得部8813が、時刻検知部101が検知した現在時刻と受信規則蓄積部6711に蓄積された受信スケジュールに従って、次メールの受信時刻と差出人アドレスを取得する(ステップS8903)。通知可能判定部6712が、場所検知部101における次メール取得部8813が取得した次メール受信時刻以降の通知可否を判定し、その結果から次通知時刻計算部6714は、次メール受信時刻以降の最も早い通知可能時刻を取得する(ステップS7304)。関連性判定部8821は、通知情報蓄積部6707に蓄積されたメールの差出人アドレスと次メール取得部8813が取得したメールの差出人アドレスの情報を比較し、関連性の有無を判定する(ステップS8904)。利点計算部8816は、次通知時刻計算部が算出した次メールの通知可能時刻と、通知情報蓄積部6707に蓄積されたメール情報の受信時刻、関連性判定部8821が判定したメールの関連性から、次メールを受信した後、蓄積されたメール情報を一度に通知することの利点を算出する(ステップS8905)。以下実施の形態10と同様である。
【0360】
なお、この変形例の情報通知装置では、関連性判定部8821は、差出人アドレスの一致判定により、関連性を判定していた。しかし、差出人アドレスが違ってもメールのない様に関連性がある場合が存在する。具体的には、メンバーの誰もがメールを送信できるコミュニティのメーリングリストなどにおいて、同じメーリングリストに対するメールの場合は差出人アドレスが異なっても内容に関連性が有る場合が多い。このとき、返信先も同一であることが多く、複数のメールを受け取ったとしても一通のメールでまとめて返信をすることができる。具体的には、関連性判定部8821は、メールの返信先アドレスつまり「Reply−toアドレス」を次メールと通知情報蓄積部に蓄積されたメールで比較し、「Reply−toアドレス」が一致するときは、関係性有と判定してもよい。
【0361】
また、メールをまとめて通知する際に同内容のメールはソートして通知しても良い。つまり、差出人アドレスの順にソートをしてユーザに通知する。これにより、ユーザは同内容のメールをまとめて続けて読むことができる。
【0362】
また、メールをまとめて通知する際に、ユーザが返信を要するメールと返信を要しないメールに分類した上で通知しても良い。これにより、ユーザは返信を要しないメールをまとめて続けて読むことができる。例えば、差出人がメーリングリストの主催者のメールは返信を要しないメールだと考えられるため、差出人が友達のメールなど返信を要するメールと分類ソートした上で、通知してもよい。
【0363】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングと通知する情報の量とを適切に制御することができる情報通知装置が実現される。
【0364】
つまり、本実施の形態では、現在以降における通知評価値及びメールの受信スケジュールを取得し、どのタイミングで、メールをまとめて同時に通知することが最適であるかを判断しているため、通知回数を減らしながら、できるだけ早くメールを通知することができる。
【0365】
(実施の形態11)
次に、本発明の実施の形態11に係る情報通知装置を説明する。
【0366】
本実施の形態10では、状況による通知の可不可と受信スケジュールにあわせて、受信したメールを全て通知するか、次のメールが来るまで待つかを制御していた。しかし、実際は同じ通知が可能な状況でも、通知の好ましさは異なる。このため、実施の形態5では、状況に応じて同時に通知できるメールの最大数を制限していた。よって、通知の好ましさ、つまり同時に通知できるメールの最大数も考慮したうえで、複数のメールについて通知のタイミングと数を制御してもよい。このとき、現在受信しているメールの数が、現在通知できる最大数のメール数以下である場合は実施の形態10とほぼ同様である。しかし、現在受信しているメールの数が、現在通知できる最大数のメール数を上回る場合は問題となる。このとき、通知待ちメールを同時に全て通知できない。よって、通知回数を増やしてでも、通知できる最大数のメールを即座に通知するのか、それとも状況変化を待ち、全てのメールを通知できるタイミングで通知するのかの判断が重要となる。現在受信しているメールを全て通知できるタイミングで通知しようとしても、現在受信しているメールを全て通知できるタイミングになるまでに、さらに新しいメールを受信することもある。すると、通知待ちメール数が増加するため、結局全てのメールを同時に通知できなくなってしまう可能性もある。こういった問題には、現在受信している全てのメールについて、未来において受信するメールも含めて、全て同時に通知できるタイミングを現在時刻以降から算出し、現在通知できる最大数まで即時に通知したときに対する利点を算出することにより対処する。
【0367】
図80は、本実施の形態における情報通知装置の構成図である。この情報通知装置は、ユーザに対して電子メールの通知を行う情報通知装置であって、時刻検知部100、場所検知部101、通知評価値計算部110、通知情報蓄積部6707、情報通知部6709、メール蓄積部6710、受信規則蓄積部6711、反応検知部7402、反応履歴蓄積部1803、通知タイミング制御部7408および連続通知検知部7420を備える。前記実施の形態1、5、10で示した構成要素には同様の符号を付与し、説明を省略する。以下、まず各構成要素について図80、図81を用いて説明し、後に本装置の動作について説明する。
【0368】
反応検知部7402は、情報の通知に対するユーザの反応をユーザの情報通知装置に対する操作により検知する。例えば、通知されたメール全てについてユーザが詳細内容まで閲覧したかどうかを検知する。
【0369】
連続通知検知部7420は、現在時点における、同時に通知されたメールの数を検知する。
【0370】
最大通知数計算部7419は、反応確率計算部1804が作成した時刻と場所と連続通知数に対する3次元反応確率テーブルから時刻と場所に対する最大通知数のテーブルを作成する。最大通知数は、同時に通知することがユーザに好まれる最大のメール数であり、反応確率が閾値以上となる通知数の中で最も小さいものから1を引いた値である。つまり、「n=1,2,・・・,N」に対して「通知数nの反応確率>=閾値」がなりたつ整数Nのうち最大の数である。閾値は例えば0.5とする。図82の場合、時刻「7時〜9時」場所「家」に対する反応確率は、連続通知数「1」のとき「0.9」、連続通知数「2」のとき「1.0」、連続通知数「3」のとき「0.3」となる。初めて反応確率が閾値未満となるのは連続通知数「3」のときなので、時刻「7時〜9時」場所「家」に対する最大通知数は「2」となる。
【0371】
通知タイミング制御部7408は、時刻検知部100で検知された現在時刻、場所検知部101で検知された現在場所と、最大通知数計算部7419によって計算された最大通知数を用いて、通知情報蓄積部6707に蓄積された情報の通知タイミングと通知する情報の数を制御し、当該情報をメール蓄積部6710に出力し、情報通知部6709に情報の到着をユーザに知らせるようにする。また、このとき、通知情報蓄積部6707に蓄積された情報を削除する。通知タイミング制御部は、図81に示されるように、全通知可能判定部7412、未来メール取得部7413、全通知時刻計算部7414、利点計算部7416、通知判定部7417から構成されている。以下、それぞれについて説明する。
【0372】
全通知可能判定部7412は、最大通知数計算部が作成した最大通知数テーブルから、時刻検知部100、場所検知部101、全通知時刻計算部7414によって指定された時刻、場所において、通知情報蓄積部6707に蓄積されたメール及び未来メール取得部7413で取得したメールの全てについて同時通知を行うことが可能であるか否かを判定する。具体的には、指定された時刻、場所における通知最大数が、通知情報蓄積部6707に蓄積されたメールと未来メール取得部7413で取得したメールの数の合計以上であった場合に通知可能、合計未満であった場合に通知不可と判定する。
【0373】
未来メール取得部7413は、受信規則蓄積部6711に蓄積されたメールの受信スケジュールと時刻検知部100が検知した現在時刻、及び全通知時刻計算部7414が算出した全通知可能時刻を用いて、現在時刻から全通知可能時刻までの間に未来メール取得部が取得するメールの数を取得する。例えば、図70に示されるように、メールの受信スケジュールが蓄積されていて、現在時刻が「土曜日」の「11:20」であり、全通知可能時刻が「12:30」の場合、土曜日が受信曜日に含まれるID「001」、「003」、「004」「005」…の中で、メールの受信時刻が、現在時刻「11:20」から「12:30」の間にあるメールの合計数3を取得する。
【0374】
全通知時刻計算部7414は、時刻検知部100が検知した現在時刻から、場所検知部101が検知した現在場所において、現在時刻以降、未来メール取得部7413が取得したメールの数と通知情報蓄積部6707が取得したメールの数の合計が最も早く通知可能となる時刻を、全通知可能判定部7412を用いて計算する。通知可能時刻を一旦計算しても、通知可能時刻までに新たに受信するメールが存在する可能性があるため、未来メール取得部7413が取得したメールの数と通知情報蓄積部6707が取得したメールの数の合計が変化しなくなるまで、通知可能時刻算出を繰り返す。未来メール取得部7413が取得したメールの数と通知情報蓄積部6707が取得したメールの数とはその時点において通知情報蓄積部6707に蓄積されることが予想される待機メールの数である。
【0375】
例えば、図83に示されるように、最大通知数テーブルが作成されており、次メール受信時刻が「11:30」であり、現在の場所は「家」であり、通知情報蓄積部6707に3通のメールが蓄積されていたとする。現在時刻以降で3通全て通知できる最も早い時刻は「11:30」であるが、図83に示される受信スケジュールでは、「11:30」までに1通のメールを受信するため、待機メールは4通なる。このため、「11:30」には、最大通知数は3通であるため、全てのメールを通知できない。同様に「12:15」にも待機メールは5通となるため全てのメールを通知できない。よって、6通の待機メールを全て通知できる「12:30」が全通知可能時刻となる。
【0376】
利点計算部7416は、全通知時刻計算部7414が算出した全通知可能時刻から、現時点で即座に最大通知数のメールを通知することに対する、全通知可能時刻で全メールまとめて通知することの利点を計算する。ただ、各メールの受信時刻に応じて、メールが遅延することにより失われる利点は異なると思われる。そのため、通知情報蓄積部6707に蓄えられた各メール情報の受信時刻も利点計算に用いる。また、即座に通知したとしても最大通知数(現時点での最大通知数とは、最大通知数計算部7419が算出した最大通知数テーブルのうち、現在時刻と現在場所に対応する通知数をいう)までのメールの数しか通知できないため、利点計算には、最も古いメールから最大通知数だけのメールを利点計算に用いる。
【0377】
例えば、全通知可能時刻で通知情報蓄積部6707に蓄積された全メールまとめて通知することの利点をMとし、全メールまとめて通知することにより、通知回数が減るために得られる利点をTとし、メールを通知するのが遅れることにより、失われる利点を一通、一分につきDとし、通知情報蓄積部6707に蓄えられた各メールの受信時刻をtn(分)(nが小さいほど受信時刻は早い)、現時点での最大通知数をX、全通知可能時刻をN(分)とすると、具体的にMは次の式で表される。
【0378】
【数3】


【0379】
つまり、利点とは、通知回数が減ることによって得られるメリットから通知情報蓄積部6707に蓄えられたメールのうち即座に通知できるメールに対する、受信時刻からの通知遅延時間によるデメリットを減算したものである。例えば、図84のように、通知回数減による利点Tが100、通知遅延により失われる利点Dが1、全通知可能時刻Nが「12:30」、現時点での最大通知数を2、通知情報蓄積部6707に蓄積されたメールが3通で、受信時刻がそれぞれ「11:00」「11:10」「11:19」だったとする。すると利点Mは、「100−1{(12:30−11:00)+(12:30−11:10)=−70」となり、「−70」である。
【0380】
通知判定部7417は、利点計算部7416が算出した利点から、通知情報蓄積部6707に蓄積されたメールのうち、現時点での最大通知数だけのメールを通知するか否かを判定する。現時点での最大通知数とは最大通知数計算部7419が算出した最大通知数テーブルのうち、現在時刻と現在場所に対応する通知数である。
【0381】
具体的には、利点が閾値0より大きいならば、通知しないと判定し、メールを出力しない。閾値0以下ならば最大通知数の数だけメールを通知すると判定し、通知情報蓄積部のメールのうち、受信時刻が最も早いものから最大通知数のメールをメール蓄積部6710に出力し、情報通知部6709にメールの到着を知らせるようにする。このとき、出力した通知情報蓄積部6707のメールを削除する。
【0382】
以下、本実施の形態11のフローチャートを、図85を用いて説明する。前記実施の形態10で示した構成要素には同様の符号を付与し、説明を省略する。まず、全通知可能判定部7412が、時刻検知部100が検知した現在時刻と、場所検知部101が検知した現在場所、通知情報蓄積部6707に蓄積されたメールの数、最大通知数計算部7419が作成した最大通知数テーブルから現在の全通知可否を判定する(ステップS7901)。情報通知が全く不可能であった場合、ステップS7901に戻る(ステップS7902のNo)。情報通知が1通でも可能であった場合、ステップS7903に進む(ステップS7902のYes)。全メール通知が可能であった場合、実施の形態10と同様にステップS7303に進む(ステップS7903のYes)。全メール通知が不可能であった場合、ステップS7904に進む(ステップS7903のNo)。
【0383】
全通知時刻計算部7414は、通知情報蓄積部6707が蓄積しているメールの数と未来メール取得部7413が取得したメールの数の合計である待機メール数に対する、仮の全通知可能時刻を現在時刻、現在場所と最大通知数計算部7419が算出した最大通知数テーブルから算出する(ステップS7904)。未来メール取得部7413は、全通知時刻計算部7414が指定した仮の全通知可能時刻までに受信する予定であるメールの数を受信規則蓄積部6711から取得し、通知情報蓄積部6707に蓄積されたメールの数に加えて、待機メールの数とする(ステップS7905)。
【0384】
全通知時刻計算部7414は、待機メール数に変化があるかどうかを判定し(ステップS7906)、変化があった場合はステップS7904に戻る(ステップS7906のYes)。変化がなかった場合は、仮の全通知可能時刻を全通知可能時刻と確定し、ステップS7907に進む(ステップS7906のNo)。利点計算部7416は、通知情報蓄積部6707に蓄積されたメール情報の受信時刻と現在時刻、現在場所における最大通知数、全通知時刻計算部7414が算出した全通知可能時刻から、状況変化を待ち、蓄積されたメール情報を同時に通知することの利点を算出する(ステップS7907)。
【0385】
通知判定部7417は、利点計算部7416が算出した利点から最大通知数のメールについて、現在通知を行うか否かを判定する(ステップS7908)。通知を行わないと判定したとき、ステップS7901に戻る(ステップS7909のNo)。通知を行うと判定したとき、ステップS7910に進む(ステップS7909のYes)。通知を行うと判定したとき、通知判定部7417は、通知情報蓄積部6707に蓄積されたメールのうち、現在の最大通知数だけのメールをメール蓄積部6710に蓄積する(ステップS7910)。
【0386】
通知判定部7417は、通知情報蓄積部6707に蓄積されたメールのうち、メール蓄積部6710に蓄積したメール情報を削除する(ステップS7911)。情報通知部6709は、メールの到着をユーザに音や光、振動などで通知する(ステップS7912)。
【0387】
反応検知部102は、情報を通知したときのユーザのメールの詳細内容閲覧反応を検知する(ステップS7913)。連続通知検知部7420は、同時に通知されたメールの数(連続通知数)を検知する(ステップS7914)。反応検知部102は、時刻検知部100で検知された情報の通知を行った時刻から当該通知に対する閲覧反応があった時刻までの時間を計測し、情報通知を行ったときの時刻と、情報通知を行ったときに場所検知部101が検知した場所、連続通知検知部7420が検知した連続通知数と共に、反応履歴蓄積部1803に登録する(ステップS7915)。
【0388】
反応確率計算部1804は、反応履歴蓄積部1803に蓄積されている反応履歴から、反応確率を計算し、反応確率テーブルを生成する(ステップS7916)。最大通知数計算部7419は、反応確率計算部が算出した反応確率テーブルから最大通知数テーブルを作成する(ステップS7917)。装置の動作を終了しない場合は、ステップS7901に戻る(ステップS7918でNO)。終了する場合はフローを終了する(ステップS7918でYES)。
【0389】
なお、実施の形態10、11の通知判定処理のフローは、毎時もしくは一定時間ごとに繰り返し行っていた。しかし、毎時判定処理を行うと、電源の消費量が大きくなるという問題がある。単純に時刻や場所が変化した時やメールを受信したときに通知判定を処理を行ったのでは、不適切な処理を生じる場合がある。なぜなら、メールの場合、受信スケジュールに記述できないランダムな受信が多く、予定外のメールを受信することもある。また、受信スケジュール通りのメールが来ないこともある。そこで、時刻や場所が変化し、通知評価値が変化したときだけではなく、メールの受信時及び、メールを受信しなかったとしても受信スケジュールによるメールの受信予定時刻に通知判定処理のフローを行ってもよい。これにより、通知判定処理を毎時行わなくても良くなるため、電源の消費量を削減することができる。
【0390】
また、実施の形態10、11の通知タイミングの処理はユーザの所持する端末が行っていた。しかし、サーバが通知判定処理を行っても良い。このとき、サーバが受信したメールを蓄積しておき、通知判定処理を行い、通知すべきであると判定したときに、ユーザに複数のメールを同時に配送する。端末は受け取った複数のメールを同時に通知する。
【0391】
また、サーバが、現在時刻と、次のメールと同時に蓄積されたメールを全て通知できる通知時刻と、もしくは、全てのメールを同時に通知できる通知時刻における通知タイミングについて、実施の形態10、11と同様に比較処理を行った後、メールに通知タイミングを記述して即座に通知しても良い。端末は記述された通知タイミングでメールをユーザに通知する。記述される通知タイミングは、通知判定部が通知すると判定したときは、現在時刻である。通知判定部が通知しないと判定したときは、実施の形態10では、次のメールと同時に蓄積されたメールを全て通知できる通知時刻とである。実施の形態11では、全てのメールを同時に通知できる通知時刻である。これにより、万一、端末がサーバからのメールを受信できない電波状況の悪い状況になったとしても、ユーザにメールの受信タイミングを適切に制御できる。
【0392】
また、実施の形態11において、メールを通知するときは、受信時刻の古いメールから通知していた。しかし、差出人アドレスが一致するなど、同内容のメールはまとめて通知する方がユーザにとって都合が良い。よって、同内容のメールをまとめて通知出来るように、優先して通知しても良い。例えば、同内容のメールが存在する場合、同内容のメールの数が通知最大数を下回るときは、優先的に同内容のメール群を全て通知し、逆に上回るときは、同内容のメール群を通知せず、別のメール群のみを通知してもよい。
【0393】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングと通知する情報の量とを適切に制御することができる情報通知装置が実現される。
【0394】
さらに、本実施の形態では、現在受信しているメールの数が現在通知できる最大数のメール数を上回る場合に、現在受信している全てのメールについて、未来において受信するメールも含めて、全て同時に通知できるタイミングを現在時刻以降から算出し、現在通知できる最大数まで即時に通知したときに対する利点を算出することにより、通知できる最大数のメールを即座に通知するのか、それとも状況変化を待ち、全てのメールを通知できるタイミングで通知するのかの判断が行われてユーザに通知されるので、ユーザは、都合のよいタイミングで、複数の受信メールをまとめて閲覧することができる。
【0395】
(実施の形態12)
次に、本発明の実施の形態12に係る情報通知装置を説明する。
【0396】
実施の形態10では、メールの受信スケジュールは絶対時刻によって指定されていた。しかし、特に携帯電話のメールの場合、ユーザのメールの送信に呼応して返信メールを受信する可能性が高い。よって、ユーザがメールを送信した後、別人からメールが来たとしても、送信先から返信メールが来ることがわかっていれば、その返信メールが来たときにメールを同時に通知することができる。これにより、短い時間間隔で何度もメールの通知を受けることを防ぐことが出来る。これを実現するためには、ユーザの送信メールに呼応したメールの受信スケジュールを作成し、ユーザの送信メールを監視することによるメールの受信予測が必要である。
【0397】
図86は、本実施の形態における情報通知装置の構成図である。この情報通知装置は、ユーザに対して電子メールの通知を行う情報通知装置であって、時刻検知部100、場所検知部101、反応検知部102、反応履歴蓄積部103、通知評価値計算部110、通知情報蓄積部6707、情報通知部6709、メール蓄積部6710、通知タイミング制御部8008、呼応受信規則蓄積部8018および送信メール取得部8019を備える。なお、前記実施の形態1、5、10で示した構成要素には同様の符号を付与し、説明を省略する。以下、まず各構成要素について図86を用いて説明し、後に本装置の動作について説明する。
【0398】
呼応受信規則蓄積部8018は、ユーザのメール送信に呼応したメールの受信スケジュールを蓄積する。一般的には送信したメールの返信メールである。図87に示されるように、スケジュール識別のための「ID」、メールの発信元のメールアドレスを表す「差出人アドレス」、送信時刻から呼応したメールの受信時刻までの相対時間を表す「返信待ち時間」により構成されている。例えば、ID「001」は差出人アドレス「friend1@keitaidenwa.no.address.jp」にメールを送信したときに、「3」分後に返信メールを受信することを示している。この受信スケジュールに関しては予めユーザやメール配信者の手により、作成しておく。
【0399】
通知タイミング制御部8008は、時刻検知部100で検知された現在時刻、場所検知部101で検知された現在場所と、呼応受信規則蓄積部8018に蓄積された呼応受信規則と送信メール取得部8019から取得した送信メール情報を用いて、通知情報蓄積部6707に蓄積された情報の通知タイミングと通知する情報の数を制御し、当該情報をメール蓄積部6710に出力し、情報通知部6709に情報の到着をユーザに知らせるようにする。このとき、通知情報蓄積部6707に蓄積された情報を削除する。通知タイミング制御部は、通知可能判定部6712、呼応メール取得部8020、次メール取得部8013、次通知時刻計算部6714、利点計算部6716、通知判定部6717から構成されている。以下、それぞれについて説明する。以下、それぞれについて説明する。
【0400】
送信メール取得部8019は、メーラーの送信フォルダや、ユーザのメールサーバへの接続状況を監視することにより、ユーザが送信したメール情報を取得する。例えば、図88に示されるように、メールの送信先の宛先アドレス「friend1@keitaidenwa.no.address.jp」とメールの送信日時「11:15」などを取得する。
【0401】
呼応メール取得部8020は、呼応受信規則蓄積部8018に蓄積された呼応メールの受信スケジュールと送信メール取得部8019から取得した送信メール情報から呼応したメールの受信日時を予測する。具体的には、送信メールの「宛先アドレス」と受信スケジュールの「差出人アドレス」が一致する受信スケジュールを呼応受信規則蓄積部8018から探索し、一致するアドレスがあれば、そのIDの「返信待ち時間」を、送信メールの送信日時に加えて、呼応メールの受信日時とする。例えば、図89に示されるように、呼応受信規則蓄積部8018に受信スケジュールが蓄積され、送信メール取得部8019から宛先アドレス「friend1@keitaidenwa.no.address.jp」、送信日時「11:15」のメールと宛先アドレス「friend2@keitaidenwa.no.address.jp」、送信日時「11:16」のメールを取得したとする。
【0402】
このとき、宛先アドレス「friend1@keitaidenwa.no.address.jp」とアドレスが一致するスケジュールは、ID「001」であり、返信待ち時間は「3分」である。よって、差出人アドレス「friend1@keitaidenwa.no.address.jp」から「11:18」(11:15+3分)にメールを受信すると予測する。また、宛先アドレス「friend2@keitaidenwa.no.address.jp」とアドレスが一致するスケジュールは、ID「002」であり、返信待ち時間は「10分」である。よって、差出人アドレス「friend2@keitaidenwa.no.address.jp」から「11:26」(11:16+10分)にもメールを受信すると予測する。
【0403】
次メール取得部8013は、呼応メール取得部8020が予測した単数または複数の呼応メールの受信日時と時刻検知部100が検知した現在時刻を用いて、次に端末が取得するメールの受信時刻を取得する。具体的にはメールの受信時刻が、現在時刻以降であり、最も現在時刻の近傍にある呼応メールの受信日時を次メール受信時刻として取得する。
【0404】
以下、本実施の形態12のフローチャートを、図90を用いて説明する。前記実施の形態1、10で示した構成要素には同様の符号を付与し、説明を省略する。まず、通知可能判定部6712が、時刻検知部100が検知した現在時刻と、場所検知部101が検知した現在場所から現在の通知可否を判定する(ステップS7301)。情報通知が不可能であった場合、ステップS7301に戻る(ステップS7302のNo)。情報通知が可能であった場合、ステップS8401に進む(ステップS7302のYes)。
【0405】
情報通知が可能であった場合、送信メール取得部8019が、メーラーの送信フォルダ等からユーザが送信したメールの情報を取得する(ステップS8401)。呼応メール取得部8020は、呼応受信規則蓄積部8018に蓄積された呼応メールの受信スケジュールと送信メール取得部8019から取得した送信メール情報から呼応したメールの受信日時を予測する(ステップS8402)。次メール取得部8013は、時刻検知部100が検知した現在時刻と呼応メール取得部8020が取得したメールの受信日時に従って、次メールの受信時刻を取得する(ステップS8403)。以下実施の形態10と同様である。
【0406】
なお、本実施の形態12における呼応メールの受信スケジュールでは、差出人アドレスによって返信待ち時間が一意に決まっていた。しかし、送信から呼応メールの受信にまでにかかる返信待ち時間は状況により異なる場合がある。例えば、差出人が寝ている間に送ったメールと、起きている間に送ったメールとでは返信待ち時間は異なる。また、メールで会話をするように、相手のメールに返信を繰り返している状況では、返信待ち時間は通常より短くなる。よって、差出人アドレスだけではなく、時刻や件名によって、受信スケジュールの返信待ち時間を変更しても良い。例えば、時刻の範囲を「12:00〜13:00」と指定し、この間の返信待ち時間を例えば「5分」とする。「件名」の場合、相手のメールに対する返信を表す「Re:」が、ユーザの送信メールの「件名」の冒頭に入っている場合は、返信待ち時間を例えば「3分」とするような受信スケジュールを作成する。
【0407】
また、呼応メールの返信待ち時間に対してもばらつきが存在することが多い。よって実施の形態10の変形例1と同様に、受信メールを監視し、受信したメールの件名や差出人アドレスの一致性により、呼応メールを受信したのか、呼応メール以外のメールを受信したのかを判断しても良い。例えば、ユーザが送信したメールと受信したメールの件名が冒頭の「Re:」を除いて完全に一致したときは送信メールに対する呼応メールを受信したとする。
【0408】
また、実施の形態10、11と同様に、絶対時間による受信スケジュールの受信予測を行っても良い。このとき、新たに受信したメールが呼応メールであるか、絶対時間により予測したメールであるのか、それとも予測されなかったメールであるのかを判断し、今後の受信スケジュールを修正する必要がある。これも実施の形態10の変形例、実施の形態12の変形例と同様に差出人アドレスや件名によってメールの種類を判断する。
【0409】
また、本実施の形態12では、呼応メールはユーザの送信メールに呼応して受信していた。しかし、ユーザの送信メール以外に呼応して受信するメールも存在する。例えば、一通メールを送信したあと、連続でメールを送信する人もいる。例えば、ユーザ宛に会議の連絡メールを送信したあと、そのユーザも所属しているメーリングリストに同じ内容のメールを送信する人もいる。また、メールを書くときは連続で書くことが多いため、メールを送信した後、また別の内容のメールをすぐに送信する人もいる。また、ユーザ自身がメーリングリストから受信されたメールに返信しなくても、メーリングリストの他の加入者が返信メールを呼応して送信することもある。よって、受信メールを監視し、規則と送信先アドレスや差出人アドレスが一致したときに呼応メールの受信を予測しても良い。
【0410】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0411】
さらに、本実施の形態では、ユーザがメールを送信した後、別人からメールが来たとしても、送信先からの返信メールが来たときにそのメールが同時に通知されるので、短い時間間隔で何度もメールの通知を受けるという煩わしさが回避される。
【0412】
(実施の形態13)
次に、本発明の実施の形態13に係る情報通知装置を説明する。
【0413】
実施の形態10、11、12では、メールの受信スケジュールは予め人の手で作成していた。しかし、端末が受信メールと送信メールの履歴から自動的に作成しても良い。
【0414】
受信メールの中には、実施の形態10、11のように絶対時間によるスケジュールにより受信すると考えられるメール、実施の形態12のように、送信メール、もしくは、別の受信メールに呼応して相対時間によるスケジュールにより受信すると考えられるメール、また、それら以外の無規則で受信しているメールの3種類のメールが存在する。よって、予めそれらを分類し、それぞれについてスケジュールを作成する必要がある。
【0415】
例えば、受信したメールが「In−reply−to」ヘッダや件名の冒頭に「Re:」がついている場合は呼応受信スケジュールに対応したメールに分類する。メーリングリストからのメールでfrom欄の差出人アドレスが一つに固定されていたら絶対時間による受信スケジュールに対応したメールに分類する。逆にfrom欄の差出人アドレスは複数ある場合は、複数人で議論できるようなメーリングリストと想定されるため、呼応受信スケジュールに対応したメールに分類するといったことが考えられる。分類した後は、履歴を探索し、高頻度に受信する可能性がある時刻をスケジュールの受信時刻とすればよい。
【0416】
以上のように、本実施の形態によれば、反応履歴に基づいて情報の通知タイミングが決定されるので、ユーザや情報提供者がルールを定めなくても、いつ、どこで情報を通知するかという通知タイミングを適切に制御することができる情報通知装置が実現される。
【0417】
さらに、本実施の形態では、メールの受信スケジュールについては、端末が受信メールと送信メールの履歴から自動的に作成されるので、ユーザは、受信スケジュールを作成する煩わしい作業から解放される。
【0418】
以上、本発明に係る情報通知装置について、実施の形態1〜13に基づいて説明したが、本発明は、これらの実施の形態に限定されるものではない。実施の形態1〜13における構成要素を任意に組み合わせて実現される実施の形態や、各実施の形態に対して当業者が思いつく各種変更を施すことによって実現される実施の形態も本発明に含まれる。
【0419】
たとえば、実施の形態1〜10、12〜13における通知タイミング制御部に代えて実施の形態11の通知タイミング制御部7408を用いてもよい。これにより、いずれの実施の形態のおいても、通知評価値と未来メールの受信時刻とを用いて通知タイミングを決定する情報通知装置が実現され、広い範囲で適切な通知タイミングが探索される。
【産業上の利用可能性】
【0420】
本発明に係わる情報通知装置は、情報端末に対するユーザのインタラクション履歴により、適切なタイミングで情報を通知することが可能になり、例えば、携帯電話やPDA等の情報を提供する装置において有用である。
【図面の簡単な説明】
【0421】
【図1】本発明の実施の形態1における情報通知装置の構成を示すブロック図である。
【図2】反応履歴蓄積部に蓄積された反応履歴の例を示す図である。
【図3】反応確率計算部による、反応確率テーブルを作成する例を示す図である。
【図4】反応確率修正部が修正規則蓄積部による反応確率テーブルを修正する例を示す図である。
【図5】反応確率修正部が修正規則蓄積部に蓄積された汎化条件利用規則により反応確率計算部が作成した反応確率テーブルを修正する例を示す図である。
【図6】通知情報蓄積部に蓄積された情報の例を示す図である。
【図7】通知タイミング制御部が現在の状況から通知情報蓄積部に蓄積された情報の通知の可否を判断し、情報を出力する例を示す図である。
【図8】情報通知部が携帯電話であった場合に、情報を通知する例を示す図である。
【図9】本発明の実施の形態1における情報通知装置の反応確率テーブル更新手順を示すフローチャートである。
【図10】本発明の実施の形態1における情報通知装置の情報通知手順を示すフローチャートである。
【図11】通知評価値により評価値テーブルを作成した本発明の実施の形態1の変形例における情報通知装置の構成を示すブロック図である。
【図12】通知評価値計算部による、通知評価値テーブルを作成する例を示す図である。
【図13】通知評価値修正部が修正規則蓄積部による通知評価値テーブルを修正する例を示す図である。
【図14】通知タイミング制御部が通知評価値テーブルから通知情報蓄積部に蓄積された情報の通知の可否を判断する例を示す図である。
【図15】曜日情報を追加した本発明の実施の形態1の変形例2における通知情報蓄積部に蓄積された情報の例を示す図である。
【図16】曜日情報を追加した本発明の実施の形態1の変形例2における通知評価値計算部による、通知評価値テーブルを作成する例を示す図である。
【図17】通知開始イベント情報を追加した本発明の実施の形態1の変形例3における通知情報蓄積部に蓄積された情報の例を示す図である。
【図18】通知開始イベント情報を追加した本発明の実施の形態1の変形例3における通知評価値計算部による、通知評価値テーブルを作成する例を示す図である。
【図19】通知評価値修正部が修正規則蓄積部に蓄積された複数汎化条件利用規則により評価値計算部が作成した通知評価値テーブルを修正する例を示す図である。
【図20】条件発生確率テーブルを作成する装置の構成を示すブロック図である。
【図21】行動履歴蓄積部に蓄積された行動履歴の例を示す図である。
【図22】行動履歴蓄積部に蓄積された行動履歴から条件発生確率計算部が条件発生確率テーブルを作成する例を示す図である。
【図23】条件発生確率テーブルによる修正規則の選択を行う本発明の実施の形態2における情報通知装置の構成を示すブロック図である。
【図24】通知評価値修正部が条件発生確率テーブルと修正規則蓄積部に蓄積された汎化条件選択規則により通知評価値計算部が作成した通知評価値テーブルを修正する例を示す図である。
【図25】簡易的に条件発生確率テーブルを作成する例を示すブロック図である。
【図26】本発明の実施の形態3において、通知評価値修正部が修正規則蓄積部に蓄積された近傍汎化規則により通知評価値計算部が作成した通知評価値テーブルを修正する例を示す図である。
【図27】近傍汎化規則の使用に用いる近傍データベースの例を示す例を示す図である。
【図28】通知評価値修正部が近傍データベースと近傍汎化規則により通知評価値計算部が作成した通知評価値テーブルを修正する例を示す図である。
【図29】近傍データベースを作成し、近傍汎化規則によって修正した通知評価値により情報通知のタイミングを制御する本発明の実施の形態3のブロック図である。
【図30】行動履歴蓄積部に蓄積された行動履歴の例を示す図である。
【図31】行動履歴蓄積部に蓄積された行動履歴から他要素発生確率計算部が条件発生確率テーブルを作成する例を示す図である。
【図32】他要素発生確率計算部によって作成された他要素発生確率テーブルから近傍データベースが近傍データベースを作成する例を示す図である。
【図33】評価値修正部が近傍データベースと近傍汎化規則により通知評価値計算部が作成した通知評価値テーブルを修正する例を示す図である。
【図34】周辺音を用いて近傍データベースを作成し、近傍汎化規則によって修正した通知評価値により情報通知のタイミングを制御する本発明の実施の形態3の変形例におけるブロック図である。
【図35】周辺音を追加した行動履歴蓄積部に蓄積された行動履歴の例を示す図である。
【図36】連続通知検知部を追加した本発明の実施の形態5における情報通知装置の構成を示すブロック図である。
【図37】本発明の実施の形態5における通知タイミング制御部による連続通知数制御の例を示す図である。
【図38】連続通知数を履歴として蓄積した本発明の実施の形態5における情報通知装置の構成を示すブロック図である。
【図39】連続通知数を履歴として蓄積した本発明の実施の形態5における履歴蓄積部に蓄積された反応履歴の例を示す図である。
【図40】未来における状況も考慮して通知を行う実施の形態6における通知タイミング制御部の構成を示すブロック図である。
【図41】実施の形態6における通知タイミング制御部の動作の例を示す図である。
【図42】行動予測部により、未来における状況も考慮して通知を行う実施の形態6における情報通知装置の構成を示すブロック図である。
【図43】行動予測部を備えた実施の形態6における通知タイミング制御部の動作の例を示す図である。
【図44】通知確率変換部を追加した実施の形態7における情報通知装置の構成を示すブロック図である。
【図45】実施の形態7における通知確率変換部が反応確率テーブルから通知確率テーブルを作成する例を示すブロック図である。
【図46】実施の形態8における情報通知からユーザの情報閲覧終了までの装置の動作とユーザ操作のフローの例を示すフローチャートである。
【図47】実施の形態2における情報通知からユーザの情報閲覧終了までの装置の動作とユーザ操作のイベントの流れの例を示す図である。
【図48】実施の形態8における情報通知装置の構成を示すブロック図である。
【図49】実施の形態8における履歴蓄積部に蓄積された反応履歴の例を示す図である。
【図50】実施の形態8における内容評価値計算部が履歴蓄積部に蓄積された反応履歴から、内容評価値テーブルを作成する例を示す図である。
【図51】実施の形態8における通知タイミング制御部が現在の状況と内容評価値テーブルから情報の通知の可否を判断し、情報を出力する例を示す図である。
【図52】本発明の実施の形態8における情報通知装置の評価値テーブル更新手順を示すフローチャートである。
【図53】本発明の実施の形態8における情報通知装置の情報通知手順を示すフローチャートである。
【図54】実施の形態1のように評価値修正部を追加した実施の形態8における情報通知装置の構成を示すブロック図である。
【図55】内容評価値修正部が修正規則蓄積部に蓄積された汎化条件利用規則により内容評価値計算部が作成した内容評価値テーブルを修正する例を示す図である。
【図56】ユーザが内容の良否を入力するときの情報通知からユーザの情報閲覧終了までの装置の動作とユーザ操作のイベントの流れの例を示す図である。
【図57】ユーザが内容の良否を入力するときの情報通知からユーザの情報閲覧終了までの装置の動作とユーザ操作のフローの例を示すフローチャートである。
【図58】ユーザが情報ヘッダを表示指示するときの情報通知からユーザの情報閲覧終了までの装置の動作とユーザ操作のイベントの流れの例を示す図である。
【図59】学習を効率的に行うための通知タイミングを考慮した実施の形態9における情報通知装置の構成を示すブロック図である。
【図60】学習有効値計算が反応履歴蓄積部に蓄積された反応履歴から、学習有効値計算規則蓄積部に蓄積された履歴数依存規則により学習有効値テーブルを作成する例を示す図である。
【図61】学習有効値計算が反応履歴蓄積部に蓄積された反応履歴から、学習有効値計算規則蓄積部に蓄積された汎化条件履歴数依存規則により学習有効値テーブルを作成する例を示す図である。
【図62】本発明の実施の形態9における情報通知装置の学習有効値テーブル更新手順を示すフローチャートである。
【図63】本発明の実施の形態9における情報通知装置の情報通知手順を示すフローチャートである。
【図64】学習有効値計算が反応履歴蓄積部に蓄積された反応履歴から、学習有効値計算規則蓄積部に蓄積された特化規則により学習有効値テーブルを作成する例を示す図である。
【図65】学習有効値計算が反応履歴蓄積部に蓄積された反応履歴から、学習有効値計算規則蓄積部に蓄積された条件発生確率依存規則により学習有効値テーブルを作成する例を示す図である。
【図66】学習有効値計算が反応履歴蓄積部に蓄積された反応履歴から、学習有効値計算規則蓄積部に蓄積された要因推定規則により学習有効値テーブルを作成する例を示す図である。
【図67】本発明の実施の形態10における情報通知装置の構成を示すブロック図である。
【図68】本発明の実施の形態10における通知タイミング制御部の構成を示すブロック図である。
【図69】通知情報蓄積部に蓄積された情報の例を示す図である。
【図70】受信規則蓄積部に蓄積されたメールの受信スケジュールの例を示す図である。
【図71】次通知時刻算出部が次通知可能時刻を算出する例を示す図である。
【図72】利点計算部が利点を算出する例を示す図である。
【図73】本発明の実施の形態10における情報通知装置の動作手順を示すフローチャートである。
【図74】次通知時刻算出部が次通知可能時刻を算出する例を示す図である。
【図75】メールの受信状況を予測することにより、受信スケジュールを補正する例を示す図である。
【図76】実施の形態10の変形例における情報通知装置の通知タイミング制御部の構成を示すブロック図である。
【図77】関連性判定部が関連性を判定する例を示す図である。
【図78】利点計算部が利点を算出する例を示す図である。
【図79】実施の形態10の変形例における情報通知装置の動作手順を示すフローチャートである。
【図80】本発明の実施の形態11における情報通知装置の構成を示すブロック図である。
【図81】本発明の実施の形態11における通知タイミング制御部の構成を示すブロック図である。
【図82】最大通知数計算部が最大通知数テーブルを作成する例を示す図である。
【図83】全通知時刻算出部が全通知可能時刻を算出する例を示す図である。
【図84】利点計算部が利点を算出する例を示す図である。
【図85】本発明の実施の形態11における情報通知装置の動作手順を示すフローチャートである。
【図86】本発明の実施の形態12における情報通知装置の構成を示すブロック図である。
【図87】呼応受信規則蓄積部に蓄積されたメールの受信スケジュールの例を示す図である。
【図88】送信メール取得部が取得する送信メールの例を示す図である。
【図89】呼応メール取得部が呼応メールを取得する例を示す図である。
【図90】本発明の実施の形態12における情報通知装置の動作手順を示すフローチャートである。
【符号の説明】
【0422】
100、6500 時刻検知部
101 場所検知部
102、3202、7402 反応検知部
103、1803、3203 反応履歴蓄積部
104、1804、3204 反応確率計算部
105 修正規則蓄積部
106、1806 反応確率修正部
107、6707 通知情報蓄積部
108、1508、1608、2001、2208、2808、3208、4607、6708、7408、8008、8808 通知タイミング制御部
109、6709 情報通知部
110 通知評価値計算部
111、6001、6006 通知評価値修正部
1504 反応度計算部
1506 反応度修正部
2403、6503、7003 行動履歴蓄積部
2404 条件発生確率計算部
6501 他要素検知部
6502、7002 他要素発生確率計算部
6504 近傍データベース生成部
6505 近傍データベース
6506 近傍汎化規則
6507 平休日検知部
7007 周辺音検知部
1610、1810 連続通知検知部
2005 場所範囲決定部
2006 時刻範囲決定部
2007 通知可否判定部
2210 行動予測部
2810 通知確率変換部
3205 内容評価値計算部
3711 内容評価値修正部
4604 学習有効値計算部
4605 学習有効値計算規則蓄積部
6710 メール蓄積部
6711 受信規則蓄積部
6712 通知可能判定部
6713、8013、8813 次メール取得部
6714 次通知時刻計算部
6716、7416、8816 利点計算部
6717、7417 通知判定部
7412 全通知可能判定部
7413 未来メール取得部
7414 全通知時刻計算部
7419 最大通知数計算部
8018 呼応受信規則蓄積部
8019 送信メール取得部
8020 呼応メール予測部
8821 関連性判定部




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013